この記事を読んでいる方は、すでにAI Gatewayを運用している前提で進めます。モデルへのトラフィックは振り分けられ、コストは抑えられ、本シリーズを追ってきた方ならエージェントとツールの呼び出しに Model Context Protocol (MCP) のガバナンスもかかっているはずです。AI Gatewayの導入が済んでいるのであれば、トラフィック層の課題は解決されているでしょう。

それでもAIは間違って答えを返し、利用も伸び悩みます。セキュリティレビューでは、Gatewayが答えられない質問が毎回出てきます——「このデータを見てよいと、モデルはどうやって判断しているのか」。ここに、AI Gatewayによるルーティングでは届かない領域があります。

ルーティング用のGatewayが処理するのは、AIへのリクエストをどう扱うかです。AIが何を知っているかは管理しません。業務システムに繋がっていないGatewayは、問題を解かずに下流へ押し流します。振り分けの精度をどれだけ上げても、返ってくる答えの中身までは良くなりません。

2026年のGartner Data and Analytics Summitで、アナリストのAndres Garcia-Rodeja氏はこう予測しました。MCPだけに依存するエージェント型分析プロジェクトの60%は、一貫したセマンティックレイヤーが下に無いために2028年までに失敗するだろう、というものです。MCPはコンテキストを運ぶ仕組みであって、コンテキストを生み出す仕組みではありません。

この記事では、ルーティング用のGatewayが本来解いている問題、ルーティングでは正しさを担保できない理由、企業AIにおけるコンテキストの定義、企業が依存する3種類のコンテキスト、コンテキストとルーティングの組み合わせ方、そしてコンテキストレイヤーを足すときの評価基準を、順に見ていきます。

本記事はCDataのAI Gatewayエグゼクティブ学習シリーズの第5回です。

シリーズの全記事はこちら👉AI Gatewayとは？企業のAI活用を成功させるための全8回学習シリーズ

要点

定義: AI Gatewayのコンテキストレイヤーとは、企業のSoR（Sytems of Record)から、正確で・最新で・権限でフィルタされたデータをモデルに供給するAI基盤の一部です。ルーティングがリクエストの扱い方を決めるのに対し、コンテキストレイヤーはモデルが何を知るかを決めます。

ギャップ: ルーティング用のGatewayはリクエストの経路を最適化しますが、答えを保持しているシステムには一切触れません。コンテキストレイヤーが無ければ、うまく振り分けられたリクエストでも、古い・欠けている・権限を超えた答えが返ってきます。

なぜ重要か: AIの誤答とハルシネーションは企業導入の最大の障壁として挙げられており、その多くはルーティングでは直せないデータコンテキストの失敗です。

ルーティング用のGatewayは何を解いている？

限界を語る前に、ルーティング用のGatewayが解いていることを認めておきます。ここは、しっかり解けている領域だからです。

ルーティング用のGatewayが担っているのは、次のような役割です。

• モデル選択の一元化

• レート制限とコスト管理

• ツール呼び出しの先までのユーザーID引き回し

• 監査用のトラフィック記録

• リクエスト層でのセキュリティポリシー適用

どれも実在するインフラの課題で、本シリーズで先に扱ったLLM GatewayとMCP Gatewayは、これを正しく処理します。ここから先の話は、Gatewayを持つべきでないという主張ではありません。

問題は、設計上のスコープです。ルーティング用のGatewayは、アプリケーションとモデル／ツールの間に座ります。見えるのはリクエストとレスポンスで、やることはその間の経路の最適化です。触れないのは、AIが聞かれている当のデータを保持している業務システムです。それらはルーターの完全に上流にあります。

「現在のオープンパイプラインは？」とエージェントに聞いたとします。Gatewayはこのリクエストを適切なモデルへ効率よく振り分けます。しかし、モデルがパイプラインの数字をどこから得るのか、それがいつ時点のものか、このユーザーが見てよい範囲にフィルタされているか、そもそも「パイプライン」がこのユーザーの想定どおりの意味なのか——これらはルーティングの問題ではありません。

トラフィック層としては、ルーティング層は完成しています。この記事が扱うのは、そのトラフィック層が正しく・信頼でき・コンプライアンスを満たす答えを返すために、データ層に何が存在していなければならないか、です。

なぜルーティングでは誤答が止まらない？

最適なモデルに最適な価格で振り分けても、モデルが受け取るデータが欠けている・古い・そのユーザーの権限を超えているなら、答えは間違います。ルーティングはこの3条件のどれも見られません。トラフィック層からは、どれ1つとして見えないからです。

この状態をblind router problem（盲目ルーターの問題）と呼びます。業務データのシステムに繋がっていないGatewayは、そのリクエストがどんなコンテキストを必要としているかを理解しないままリクエストを振り分けます。うまく振り分けられた間違った答えは、やはり間違った答えです。

このギャップのコストは、すでに数字で見えています。Gallagherの2026年調査（1,200社超）では、AIの誤答とハルシネーションが導入の脅威として認識される項目のトップに立ち、回答者の57%が挙げました。法務リスクやレピュテーションリスクを上回っています。Newsweekは同年、業界推計としてハルシネーションの年間コストを数百億ドル規模と報じました。

これらは主にモデルの失敗ではありません。多くはデータコンテキストの失敗であり、ルーティング層をどれだけ調整しても解けません。

現場では、この誤答は3つの形で現れます。

• そもそも届いていない: AIが関連するデータにアクセスできず、推測するか回答を断ってしまいます。

• 古いまま自信満々: 定期インデックスの複製を受け取ったまま、すでに過去のものになった情報から堂々と答えます。

• 見せすぎ: 要求したユーザーの権限を超えたデータを受け取ります。答えが正しいかどうかにかかわらず、これはガバナンスの失敗です。

どれも、ルーティングが提供しない層を必要としています。とくに3つ目の「見せすぎ」は、AIエージェントのガバナンス設計7原則で整理したガバナンス側の論点と直結していて、社内のセキュリティレビューで最初に突かれるのもこの点です。

企業AIにおける「コンテキスト」とは？

企業のAIアプリケーションにとってコンテキストとは、質問に正しく答えるためにモデルが必要とする正確で・最新で・権限でフィルタされた情報のことです。しかもその出どころは、業務の実際の状態を保持しているSoRでなければなりません。

あえてこうして言語化しておくのは、この語が緩く使われがちで、かつコンテキストを整えるのは企業においては個人で使うよりずっと難しいからです。個人むけのAIは変化のゆるやかな公開情報に答えを接地させます。企業AIが接地しなければならないのは、稼働中の業務データです。今朝更新されたCRM（顧客関係管理）のレコード、直近の倉庫同期で入った在庫数、今日時点の人員数といったものです。どれもアクセス制御されたシステムの中にあり、AIに読ませるために作られた公開インターフェースはありません。

コンテキストでないものも押さえておきましょう。システムプロンプトも、プロンプトテンプレートも、ドキュメントのインデックスも、コンテキストではありません。これらはコンテキストを届けるための手段にとどまります。夜間に更新されるRAG（検索拡張生成）インデックスは無いよりましですが、あくまで定期スナップショットです。稼働中のAIアプリケーションの多くは、自分が参照しているスナップショットが古くなったことに気づかないまま動いています。

本当の意味での企業のコンテキストは、3つの部分でできています。SoRにあるリアルタイムデータ、そのデータに業務上の意味を与えるセマンティック定義、そして両方の読み方を決めている暗黙知です。最初の2つは今の技術で扱えます。3つ目は、業界がまだ向かっている途中です。この「モデルに何を渡すか」を設計として捉える発想はコンテキストエンジニアリングの入門記事で背景から扱っていますが、ここから先はその3つを1層ずつ見ていきます。

業務データのコンテキストはどう分かれる？

業務データのコンテキストは3層に分かれます。正しさはこの3層の交点にしか存在せず、どれか1つだけでは足りません。なお、記事の冒頭で挙げた権限は独立した第4の層ではなく、3層すべてに横断してかかる要件です。順に見ていきましょう。

第1層: リアルタイムの自社データ

業務システムの中にある運用レコードを、事前に複製するのではなくリアルタイムで照会する層です。学習データや夜間インデックスから答えているアプリケーションは、常に「すでに動いてしまった後の会社」を語っています。現在のパイプライン、最新の在庫、今四半期の人員数——時間に敏感なものほど、この遅れが自信満々の誤答になります。

直し方は、取り込み頻度を上げることではなく、SoRへのリアルタイム照会です。市場もこれに気づき始めています。VentureBeatの2026年Q1調査では、リアルタイムアクセスとインデックス検索を組み合わせるハイブリッド検索の導入意向が、1四半期で10.3%から33.3%へと3倍になりました。インデックスだけのやり方が限界に当たった結果でしょう。

第2層: セマンティック定義

BIの世界で使われてきたセマンティックレイヤー（指標の計算式や定義を一か所に統一し、どのダッシュボードから見ても同じ数字が返るようにする仕組み）と混同されがちですが、ここでいうセマンティック定義はその延長にあります。項目の裏にある業務上の意味、システムをまたいだオブジェクト同士の関係、そして生のスキーマを解釈可能なものに変える合意済みの定義のことです。

リアルタイムのSalesforceデータを引けるAIでも、商談の「Amount」が予測クローズ額を指すのか、総契約額なのか、年間契約額なのかを知らなければ、正しく取得したデータを誤読します。セマンティック定義はスキーマを意味へ翻訳する層で、分析の世界ではdbtやLookML、ウェアハウスネイティブのセマンティックモデルがすでに扱っている領域です。AIがデータソースをまたいで正しく推論するには、コンテキストレイヤーが同じ定義を持ち運ぶ必要があります。この差は実測でも確認できていて、セマンティックレイヤーの有無でAI精度が98.5%と59%に分かれた検証では、同じデータを使っても定義の持ち方だけで回答品質が大きく変わりました。

第3層: 暗黙知

3つ目は暗黙知です。社内の人が自社のデータを解釈するときに使っている、明文化されていない語彙や判断のショートカットを指します。ある営業チームが有望リードをどう定義しているか、ある事業部がどの売上ラインに計上しているか、実務には存在するのにどのシステムにも書かれていない例外ルール——こうしたものが、ここに含まれます。

ここは形式化が最も難しく、業界全体でまだ開発途上です。解決済みの課題ではなく、このカテゴリが向かっている方向として捉えてください。多くの企業にとっては、最初の2層だけでも十分に大きな仕事です。

ここで大事なのは、正しさとの繋がりです。セマンティック定義のないリアルタイムデータは誤読され、権限フィルタのないリアルタイムデータと定義は、そのユーザーが見てはいけないレコードを露出させます。どの層も必要で、どの層も単独では足りません。既存システム側の権限をそのままAIへ引き継ぐ具体的な実装パターンは、既存の権限を維持して業務データをAIへ公開する方法で手順まで踏み込んで解説しています。

コンテキストとルーティングはどう組み合わせる？

ここまでの話は、コンテキストレイヤーがルーティング用のGatewayの代わりになるという意味ではありません。両者はリクエストのライフサイクル上の別々の地点で別々の問題を解いています。完成したAI基盤には両方が必要です。

ルーティングが統制するのは、どのモデルがいくらでリクエストを処理するかです。コンテキストが統制するのは、そのモデルが実行時に何を知っているかです。どちらも、もう一方の代替にはなりません。

1つのリクエストの中では、この2つは順に働きそのうえで合流します。まずルーティング層がモデルを選びます。コンテキストエンジンは、どのデータをどのシステムから取得するかを決め、要求したユーザーの権限でフィルタし、解釈可能にするセマンティック定義を添えます。どちらの判断もモデルが動く前に確定するので、モデルはルーティングの決定とコンテキストを同時に受け取ります。

ここには、見落とされがちなコストの関係もあります。クエリに必要なフィールドと行だけを、権限フィルタ済みで返すコンテキストエンジンは、モデルが処理すべきトークンのペイロードを小さくします。どのモデルにルーティングされたかに関係なく、推論コストが下がるということです。コンテキストの質とルーティングの効率は掛け算になります。

設計上の結論はシンプルです。LLM GatewayとMCP Gatewayが統制されたAIのトラフィック側の半分を担い、コンテキストエンジンがデータ側の半分を担います。片方だけでは穴が残ります。両方そろって初めて、統制されていて・正しくて・コスト効率の良いAIになります。

コンテキストレイヤーはどう選ぶ？

この層は何を基準に判断すればよいのでしょうか。内製でも購入でも問うことは同じです。ここでは機能チェックリストの形を離れて、評価基準として整理しておきます。

そもそも導入すべきタイミングかどうかも先に見ておく価値があります。要件が狭く、単一のデータソースだけで完結しているなら、専用のコンテキストレイヤーはまだ早いかもしれません。一方、複数のSaaSやオンプレシステムをまたいで複数のエージェントが同じ業務データに触れるようになったら、導入価値は明確に上がります。

内製か購入かは、自社のデータの広がりで決まります。要件が狭くて安定していて、専任のプラットフォームエンジニアリングを抱えている企業なら、この層を絞った内製で片付けるのは十分に合理的です。

一方、多数のSaaS、オンプレミスのデータベース、独自開発のアプリケーションを抱えている企業では、構築と維持の負担が、専用に作られたものを採用するコストを上回るのが通例です。「作るか買うか」の前に確かめておきたいのは、自社の規模で作るとは実際に何をやることなのか、という点です。この判断を企業規模ごとの軸に落とした整理は内製と外注を見極める3つの判断軸にまとめてあるので、社内で結論を出す前の材料としてお使いください。

CDataでは、Connect AIの中にこの基準に沿ったコンテキストレイヤーを構築しています。データソースごとのコンテキスト、データソースをまたいだ関係、そしてコンテキストの取得を組み合わせる設計です。本シリーズの次回は、この評価基準をさらに分解して扱います。実際に、AI SaaS・ノーコードプラットフォーム企業の導入事例では、標準的なインテグレーションレイヤーの欠如で遅れていたAI機能拡張が、カスタム開発の維持負担なく進められるようになっています。

AIに渡すデータを統制する

この記事で扱った3層——リアルタイムデータ・セマンティック定義・暗黙知——は、データの鮮度と意味をどう担保するかという課題です。そこに3層すべてを横断する権限の制御が加わり、いずれもモデルの手前で解く必要があります。CData Connect AIは、数百の業務データソースへ、各ユーザーの権限をデータがモデルに届く前に適用したうえで、統制されたリアルタイムアクセスを提供します。

次回の記事では、コンテキストレイヤーの評価基準をさらに詳しく——データソースのカバー範囲、スキーマの理解、セマンティックの解決、そしてデータ層での権限適用について扱います。要件をもう一歩深く知りたい方には、7 essential data requirements for agentic AIが参考になります。モデルルーティングの隣にデータアクセス層がどう収まるかは、こちらのページで整理しています。

まずは自社で使っているデータソースを1つ繋いで、権限が効いた状態でAIが答えを返すところから試してみてください。CData Connect AIの無料トライアルから始められます。

よくある質問