エンタープライズ AI エージェントの信頼性は文書の質に依存する

エンタープライズ AI は、主にコンテキストエンジニアリングを中心に構築されてきました。チームはエンタープライズシステムを接続し、チャンクや埋め込みベクトルを生成して検索パイプラインを構築し、個々の AI アプリケーションに必要なコンテキストを組み立てています。このアプローチは孤立したアシスタントやコパイロットにとっては機能しますが、企業知識をアプリケーション固有の文脈として扱う一方で、共有資産としての扱いがなされていないのが実情です。

組織がより多くの AI アプリケーションとエージェントを展開するにつれ、このモデルは綻び始めます。異なるチームが同じドキュメントを処理し、それぞれ別々の埋め込みベクトルやインデックスを維持することで、同一のビジネス知識に対して一貫性のない表現が生じてしまいます。今や課題は単に AI システムにコンテキストを提供することではなく、企業知識そのものを管理することにあります。

なぜエンタープライズ AI にはコンテキスト構築だけでは不十分なのか

現在のエンタープライズ AI における一般的なアプローチは、個々のアプリケーション向けにコンテキストを構築することにあります。チームはエンタープライズシステムを接続し、必要な情報を処理して、チャンクや埋め込みベクトルといった検索用の表現を生成します。そして、エージェントが実行時に必要とするコンテキストを組み立てます。これは単一のアプリケーションにとっては機能しますが、企業知識を共有資産として管理するものではありません。

組織がより多くの AI アプリケーションを展開するにつれ、このアプローチは以下の3つの理由から綻び始めます。

まず、知識の整合性が損なわれます。企業の知識は、異なるスキーマやビジネス定義、更新サイクルを持つ多数の独立したシステムに分散しています。同じ製品、顧客、あるいは業務プロセスが、文書、Jira のチケット、ソースコード、CRM システム、メタデータの間で異なって記述されたり、時には矛盾したりすることさえあります。こうした情報をコンテキストとして抽出しても不整合は解消されず、単に AI アプリケーションへと移転されるだけです。その結果、異なるエージェントが企業に対する理解をそれぞれ違えてしまうことになります。

次に、変更の伝播が困難になります。企業の知識は絶えず進化しますが、各アプリケーションは独自のコンテキストパイプラインを維持しています。文書やコード、ビジネス定義が変化するたびに、下流のチャンク、埋め込みベクトル、インデックス、そしてエージェントのコンテキストが個別に更新されるため、AI アプリケーションは同じ知識の異なるバージョンに基づいて動作してしまいます。

最後に、組織は同じ知識パイプラインを繰り返し構築しています。異なるチームが同じ企業知識を処理し、類似した埋め込みベクトルを生成し、別々のインデックスを維持し、異なるアプリケーションのために重複するコンテキストを構築します。その結果、エンジニアリング作業の二重化や不要なインフラコスト、そして断片化した知識が生じてしまいます。

これは根本的に文脈エンジニアリングの問題ではなく、知識管理の問題です。エンタープライズデータプラットフォームは、構造化データに対して同様の課題を解決しました。つまり、企業データを一度管理し、それをアプリケーション間で共有する仕組みです。エンタープライズ AI においても、同じアーキテクチャの規範が求められています。それは「知識を一度管理し、すべての AI アプリケーション向けに再利用可能な表現を公開する」共有型エンタープライズ知識プラットフォームです。

階層化されたデータおよび知識管理システム

エンタープライズ知識プラットフォームは、エンタープライズ知識におけるエンタープライズデータプラットフォームの equivalents です。ドキュメント、ソースコード、Jira チケット、メール、API、その他のエンタープライズシステムを個別の AI アプリケーションへの孤立した入力として扱うのではなく、これらを共有資産として管理します。共通アーキテクチャを通じて企業知識を取り込み、整理し、統合し、ガバナンスし、公開することで、すべての AI アプリケーションが独自の文脈を維持するのではなく、信頼できる共通の知識基盤を利用できるようにします。

これを実現するために、プラットフォームは責任範囲が明確な 4 つの層に知識管理を分離しています。まず、知識は元の形式で保存されます。次に、管理された知識オブジェクトとして正規化され、共通のエンタープライズ知識モデルへと接続されます。最後に、異なる AI アプリケーション向けに最適化された表現として公開されます。この分離により、各段階が独立して進化できる一方で、すべての下流アプリケーションに対して一貫した基盤を提供します。

このプラットフォームは、エンタープライズ知識を 4 つのレイヤーに整理します。

Raw → Refined → Integrated → Serving

「Raw」は、元の企業ソースをそのまま保持します。

「Refined」は、多様なソースを管理可能な知識オブジェクトに変換します。

「Integrated」は、システム横断の知識をつなぎ合わせ、統合されたエンタープライズ知識モデルを構築します。

「Serving」は、AI アプリケーション向けに再利用可能でエージェント固有の表現を公開します。

Raw レイヤー：ソースの保持

Raw レイヤーでは、企業システムから情報を取得しつつ、その元の形式とソースのアイデンティティを維持します。対象となるのは、データベースレコードや変更イベント、PDF やその他のドキュメント、Confluence ページ、Jira チケット、ソースコード、API 応答、メール、画像、そしてイベントストリームなどです。

このレイヤーの目的は、情報をエージェントがすぐに扱えるように整えることではありません。あくまで、プラットフォームが下流の知識を再構築できる信頼性の高いソースを維持することが狙いです。抽出ロジックの変更やモデルの改善、あるいは下流表現の破損が発生した場合でも、アプリケーション固有のコピーに依存することなく、情報を再度処理できます。

Refined レイヤー：エンタープライズ知識の正規化

Refined レイヤーでは、多様な企業ソースを管理可能な知識オブジェクトに変換します。各ソースは、そのアイデンティティ、メタデータ、権限、バージョン、系譜（リンネージ）、および元のコンテンツへの参照を保持したまま、一貫性のある表現へと正規化されます。

例えば、製品要件ドキュメントは、ドキュメント ID、製品 ID、タイトル、ソースシステム、著者、バージョン、権限、タグ、作成日時、最終更新日時などのメタデータを含む構造化された知識オブジェクトに変換されます。これには関連するコンテンツも含まれます。この表現形式により、ソースがドキュメント、Jira チケット、ソースコードリポジトリ、メール、API のいずれであっても、エンタープライズナレッジを管理するための一貫した方法を提供します。

この段階では、プラットフォームは異なるドメイン間をつなぐことを目指していません。むしろ、すべてのエンタープライズナレッジソースに対して、再利用可能でガバナンスされた表現形式を確立することを目指しています。各ソースが構造化またはセミ構造化された知識オブジェクトに正規化されれば、統合層は共通のビジネスエンティティや関係性を通じてそれらを接続できるようになります。

統合層 – エンタープライズナレッジモデルの構築

統合層は、独立した知識オブジェクトを統一されたエンタープライズナレッジモデルに変換します。その目的は二つあります。システム間およびビジネスドメインにわたるナレッジの連携と、AI が推論を行うために必要なビジネス関係性のモデリングです。

知識は、製品 ID や顧客 ID といった共通のビジネス識別子、Jira や Git リンクのような明示的なシステム間参照、あるいは直接的な関係が存在しない場合の AI によるエンティティ解決を通じて結びつけられます。例えば、「一括請求書アップロード」を記述した製品要件定義書と、「請求書アップロード API の実装」と題された Jira ストーリー、そして同じ機能を発表するリリースノートは、それらの間に明示的な関係が存在しなくても、すべてが同一のビジネス機能指している可能性があります。

一度結びつけられると、プラットフォームは「実装先」「包含」「所属」「影響」「依存」などのビジネスロジックに基づいてビジネス関係をモデル化します。これは単なるレコード間のリンクではなく、実際のビジネスがどのように稼働しているかを捉えるものです。

従来の主キーや外部キーの関係とは異なり、これらの関係はビジネスワークフロー、依存関係、所有権、そしてビジネスへの影響を記述するものです。これにより、AI はエンタープライズ全体の共通理解を用いて、エンジニアリング、プロダクト、カスタマーサポート、財務など多様なドメインにまたがる知識を追跡できるようになります。

Serving layer – AI 向けの知識公開

Serving layer（サービス層）は、多くのエンタープライズ AI アプリケーションで使われるコンテキスト層と似ていますが、管理されたエンタープライズ知識基盤の上に構築されています。この層では、エンタープライズの知識モデルを、異なる AI ワークロードに最適化された表現に変換します。これらの表現には大きく分けて 2 つのカテゴリがあります。

まず挙げられるのは、すべての AI アプリケーションに共通の知識基盤を提供する「エンタープライズ共有表現」です。具体的には、一度作成して組織全体で再利用される SQL ビュー、検索インデックス、チャンク、埋め込みベクトル、グラフモデル、API などが該当します。

2 つ目は、エージェント固有の表現です。企業知識のコピーを個別に管理するのではなく、プラットフォームは各エージェントの要件に応じて統合された知識モデルからタスク固有のコンテキストを動的に組み立てます。例えば、製品担当のエージェント、収益担当のエージェント、カスタマーサポート担当のエージェントは、すべて同じエンタープライズ知識基盤を利用しつつも、それぞれの責任範囲に合わせて異なるコンテキストを受け取ります。

図は、サービング層のハイレベルモデルを明確に定義しています：

エンタープライズ・ナレッジモデル

┌─────────────────────┴─────────────────────┐

│ │

▼ ▼

共有エンタープライズ表現 エージェント固有の表現

┌───────────────────────────────┐ ┌──────────────────────────────┐

│ SQL ビュー │ │ プロダクトコンテキスト │

│ 検索インデックス │ │ レベニューコンテキスト │

│ チャンク │ │ カスタマーコンテキスト │

│ エンベディング │ │ プランニングコンテキスト │

│ グラフ │ │ コーディングコンテキスト │

│ APIs │ │ ... │

└───────────────────────────────┘ └──────────────────────────────┘

│ │

└─────────────────────┬─────────────────────┘

│

┌────────────────────────────┼────────────────────────────┐

▼ ▼ ▼

プロダクトエージェント レベニューエージェント カスタマーエージェント

管理されたナレッジプラットフォーム：AI のデータ基盤

現在のエンタープライズ向け知識システムは、AI ではなく人間のために設計されたものがほとんどです。Confluence のページやドキュメントは社員の知識記録・共有を支援し、Jira はチームの業務計画と協働を可能にします。メタデータシステムはアナリストがデータ資産を理解する手助けをします。これらのシステムは、人間が自身の経験や知識、判断力を用いて情報を検索・解釈・関連付けるために情報を整理しています。

大規模言語モデル（LLM）は、エンタープライズ知識の消費方法を根本的に変えました。機械は今や自然言語を理解し、ドキュメントに対して推論を行い、かつて人間にしか不可能だった方法でエンタープライズ知識と対話できるようになっています。この変化には、単なる新しい AI アプリケーションの導入だけでなく、知識を単一の埋め込み（embedding）として扱うのではなく、インフラストラクチャとしてのエンタープライズ知識を管理する新たなデータ基盤が必要です。

この管理されたエンタープライズ知識プラットフォームは、AI エージェントのためのデータ基盤を提供します。組織内の知識を一貫性があり、再利用可能で、ガバナンスが効いたデータプラットフォームとして整理することで、人間中心の知識システムを AI 対応型のインフラへ変換します。

この基盤により、各 AI アプリケーションが独自にコンテキストを構築・管理するだけでは達成が困難または不可能なシステム機能が実現可能です。

• Platform capability：What it enables
• Knowledge lifecycle management：再構築なしでのインクリメンタル読み込み、変更の伝播、バージョン管理、履歴推論
• Governance and trust：ガバナンスと信頼性の確保

エンドツーエンドの系譜、追跡可能性、権限管理、所有権、品質制御、そして元のエンタープライズソースに紐づく説明可能な AI レスポンスを提供します。

再利用可能な知識サービス

検索インデックス、埋め込みベクトル、グラフモデル、SQL ビュー、API、動的な文脈構築など、各エージェントごとに再構築するのではなく、アプリケーション間で共有・再利用できる基盤を備えています。

継続的な進化

ストレージ、検索、埋め込みモデル、AI アプリケーションはそれぞれ独立して進化できますが、エージェントからのフィードバックを通じてエンタープライズ知識の継続的な改善も可能にします。

このプラットフォームは、アジェンティックシステムにおける人間を介したループや強化学習ワークフローの基盤としても機能します。AI エージェントによって生成されたフィードバックは、プラットフォームに取り込まれ、検証・ガバナンスを経てエンタープライズ知識モデルに統合され、その後、下流の AI アプリケーションへ公開されます。これにより、エンタープライズ知識を継続的に改善し、AI エージェント自体が進化できる閉じたフィードバックループが実現します。

次なる競争優位性は、エンタープライズデータ基盤にあります

2022 年末に ChatGPT 3 がリリースされて以来、業界は基礎モデル、RAG アーキテクチャ、ベクトルデータベース、埋め込み技術、MCP、マルチエージェントフレームワークなどに対して莫大な投資を行ってきました。これらの技術により、AI アプリケーションの構築と展開方法は大きく改善されました。現在、AI アプリケーションのスタックは急速に成熟しつつあります。

AI エージェントのボトルネックはもはやモデルやエージェントフレームワークそのものではありません。真の課題は、それらを支える企業データ基盤にあります。AI エージェントの能力は、消費するデータと知識の質に左右されます。より優れたモデルを導入しても、断片化された文書、一貫性のないビジネス定義、連携しないシステム、あるいは管理が行き届かない企業知識を補うことはできません。

これまであらゆるデータ駆動型システムが示してきた通り、エンタープライズ AI も同じ原則に従います。「ゴミを入れればゴミが出る（Garbage in, garbage out）」のです。

企業が今最も注力すべき投資は、AI エージェントを増やすことではなく、すべてのエージェントを支える企業知識プラットフォームを構築することです。企業知識を特定のアプリケーションの文脈として扱うのではなく、共有インフラとして捉える組織こそが、より信頼性の高い AI を構築し、新アプリケーションの開発を加速させ、同じ知識基盤を繰り返し再構築することなく、AI を全社規模でスケールさせることができます。

エンタープライズ AI における次の競争優位性は、エージェント数を増やすことからは生まれません。すべてのエージェントが依存するデータと知識の基盤をいかに整えるかにかかっています。

Shuhua Xu はリード・データエンジニアです。