何が起きたか

VentureBeatに掲載された分析は、現在のエンタープライズAIの作り方そのものに疑問を投げかけています。多くの企業は、社内システムを接続し、文書をチャンクに分割して埋め込みを生成し、検索パイプラインを組み、個々のAIアプリケーション向けにコンテキストを組み立てる——いわゆるコンテキストエンジニアリングを軸に構築してきました。

このやり方は、単独のアシスタントやCopilotであれば機能します。しかし記事の指摘は、それが企業の知識を「共有資産」ではなく「アプリ固有のコンテキスト」として扱ってしまう点にあります。

なぜ重要か：破綻する3つの理由

AIアプリやエージェントの数が増えるほど、別々のチームが同じ文書を処理し、別々の埋め込みとインデックスを保守し、同じ業務知識について食い違う表現を作り出します。記事はここから3つの破綻モードを挙げます。

第一に、知識が不整合になる。 企業の知識は、スキーマも業務定義も更新サイクルも異なる独立システムに分散しています。同じ製品・顧客・業務プロセスが、ドキュメント、Jiraチケット、ソースコード、CRM、メタデータの間で違う言い方、時には矛盾する言い方で記述されている。重要なのは、その情報をコンテキストに抽出しても不整合は解消されないという点です。不整合はAIアプリ側に転送されるだけで、結果としてエージェントごとに「自社の理解」が食い違っていきます。

第二に、変更の伝播が難しくなる。 アプリごとに独自のコンテキストパイプラインを持つため、下流のチャンク・埋め込み・インデックス・エージェントコンテキストがそれぞれ独立に更新されます。つまり複数のAIアプリが、同じ知識の異なるバージョンの上で動くことになります。

第三に、同じパイプラインを何度も作り直す。 重複したパイプラインは、重複した開発工数、不要なインフラコスト、そして分断された知識を生みます。

論点：これは「知識管理」の問題である

記事の核心的な組み替えは、これらをコンテキストエンジニアリングの問題ではなく知識管理（ナレッジマネジメント）の問題として捉え直したことです。構造化データについては、エンタープライズデータプラットフォームが同じ課題をすでに解いています。データを一度管理し、複数のアプリで共有する、という発想です。

提案されるのは、企業の知識を取り込み、整理し、統合し、ガバナンスをかけ、共通アーキテクチャで公開するエンタープライズ知識プラットフォーム。4層に分かれます。

  • Raw層：DBレコードと変更イベント、PDF等の文書、Confluenceページ、Jiraチケット、ソースコード、APIレスポンス、メール、画像、イベントストリームを、出自の情報ごと原本として保持する。抽出ロジックを変えた時、モデルが良くなった時、表現が壊れた時に、下流を作り直せる信頼できる基盤を保つためです。
  • Refined層：異種のソースを管理された「知識オブジェクト」に変換する。正規化しつつ、識別子・メタデータ・権限・バージョン・リネージ・原本への参照を保つ。例として、製品要求文書がdocument ID、product ID、タイトル、ソースシステム、作成者、バージョン、権限、タグ、作成日時、最終更新日時といったメタデータと本文を持つ構造化オブジェクトになる、と示されています。
  • Integrated層：システムと業務ドメインをまたいで知識をつなぎ、AIの推論に必要な業務上の関係をモデル化する（この2点が本層の目的です）。つなぎ方は、製品IDや顧客IDのような共通の業務識別子、JiraとGitのリンクのような明示的な相互参照、そして直接の関係がない場合のAIによるエンティティ解決。記事の例では、「Bulk Invoice Upload」を記述した製品要求文書、「Implement Invoice Upload API」というJiraストーリー、同じ機能を告知するリリースノートが、明示的な関係を一切持たないまま同じ業務機能を指しています。モデル化される関係はimplemented_by、contains、belongs_to、affects、depends_on——主キー・外部キーではなく、業務ワークフロー、依存、所有、影響を表す関係です。これによりAIは、エンジニアリング、プロダクト、カスタマーサポート、財務などのドメインを横断して知識をたどれるようになります。
  • Serving層：表現を2カテゴリで公開する。一度作って再利用する共有表現（SQLビュー、検索インデックス、チャンク、埋め込み、グラフモデル、API）と、統合された知識モデルから動的に組み立てるエージェント固有表現です。Product Agent、Revenue Agent、Customer Support Agentが同じ知識基盤を使いながら、それぞれの責務に応じた別のコンテキストを受け取る。図中に挙がるのはProduct Context、Revenue Context、Customer Context、Planning Context、Coding Contextです。

点をつなぐ：人間向けに作られた知識基盤の限界

なぜ今この議論が出てくるのか。記事は、現在の企業内知識システムのほとんどが「AIではなく人間のために」作られていると整理します。Confluenceのページや文書は従業員が知識を記録・共有するためのもの、Jiraは計画とコラボレーションのため、メタデータシステムはアナリストがデータ資産を理解するため。

大規模言語モデルが変えたのは、企業知識の「消費のされ方」です。機械が自然言語を理解し、文書上で推論し、これまで人間にしかできなかった形で企業知識と対話するようになった。だからこそ、企業知識を「ひとつの埋め込み」として扱うのではなく、インフラとして管理する新しいデータ基盤が要る、というのが論の運びです。

挙げられているプラットフォーム要件は4つ。知識のライフサイクル管理（増分ロード、変更の伝播、バージョン管理、全コンテキストパイプラインを作り直さない履歴推論）、ガバナンスと信頼（エンドツーエンドのリネージ、追跡可能性、権限、オーナーシップ、品質管理、原本にひもづく説明可能なAI応答）、再利用可能な知識サービス（共有の検索インデックス、埋め込み、グラフモデル、SQLビュー、API、動的なコンテキスト組み立て）、そして継続的な進化です。なお記事本文は、ストレージの独立した進化について述べる継続的進化のくだりで途中で終わっています。

💼 事業会社視点：これは自社にどう効くか

日本企業にとって、この論点は「AI導入が進んだ会社ほど痛い」タイプの問題です。部門ごとにPoCを走らせた結果、営業がSalesforce起点で、開発がJira・Git起点で、CSが問い合わせ履歴起点で、それぞれ別の埋め込みとインデックスを持つ——記事の言う「エージェントごとに自社の理解が違う」状態が、すでに多くの現場で起きています。役員が見るべき指標は「AIアプリの数」ではなく「知識パイプラインの重複数」です。

SaaS事業者は最も直撃を受けます。製品要求文書、Jiraストーリー、リリースノートが同じ機能（記事の例でいえばBulk Invoice Upload）を指しているのに関係が張られていない状態は、そのままプロダクト提案AIの誤答になります。implemented_byやaffectsといった業務関係のモデル化を、プロダクト管理の実務側の仕事として位置づけ直すべきです。

受託開発・SIerには商機とリスクが同時に来ます。「エージェントを1本作る」案件は、いずれ「知識基盤を1つ作る」案件に置き換わる。RAGパイプライン構築の単発受注に最適化した組織は、Raw〜Serving層の設計・ガバナンス（リネージ、権限、オーナーシップ）を提案できる組織に置き換えられます。ECのように商品マスタ、CRM、CS履歴が別管理になりがりな業態では、まず共通の業務識別子（製品ID・顧客ID）が全社で一意かを棚卸しすることが、どのLLMを選ぶかより先に効きます。