AIエージェントが依頼の意図を読み取り、呼び出すツールも正しく選べていても、kintoneのアプリから顧客レコードを取る段階や基幹システムから請求データを取得する段階で、処理が止まったまま返ってこなかったりエラーで終わったりします。

質問した本人には見る権限のないレコードまで返ってくることもあります。Salesforceの顧客情報でも、共有フォルダのExcelでも、同じことは起こりえます。

こうした場面でうまくいくかどうかを決めるのは、モデルの性能ではなく、エージェントとデータソースをつなぐ「接続」の設計です。課題になりうるのは、どう認証するか、どのプロトコルでつなぐか、依頼した人の権限がリクエスト時に適用されるか、の3点です。では、その際の設計では何をどう決めればよいのでしょうか。この記事では、接続を設計する3つの型と、その選び方を整理します。

従来のAPI連携と何が違う？

従来のAPI連携は、呼び出し元と呼び出す順序が決まっていて、結果は人が確認するという前提で作られてきました。エージェントでの連携は違います。AIが依頼文をどう読んだかに応じて、どのシステムをどんな引数で呼ぶかを実行時に決めます。そのため、使うプロトコル・認証の方法・権限の受け渡し方をどう設計するかが、AIエージェントの連携アーキテクチャの中身になります。

データレイヤーは、この不確実さを引き受ける役割を担います。そのためデータレイヤーには、セキュリティに穴を開けないことと、データソースの追加やエージェントのフレームワークの変更のたびに連携を作り直さずに済むことの、両方が求められます。

AIエージェントのデータ連携は何で構成される？

AIエージェントのアーキテクチャは、大きく5つの層に分けて考えられます。この記事が扱うのは、このうち「ツール・データへの接続」と「認証・ID」の層です。

PoCではモデルとオーケストレーションに注目が集まりがちですが、本番で止まりやすいのは接続とIDの層です。以降は、この2つの層の設計を見ていきます。

個別のAPI連携ではなぜ行き詰まる？

答えは、エージェントの数が増えた時点で保守と統制が追いつかなくなるからです。ポイントツーポイントのAPI連携は、5つのシステムを1つのアプリケーションが決まった順序で呼ぶ程度なら問題なく動きます。ところが、リクエストごとに次の呼び先を自分で決めるエージェントが十数個に増えると、保守の問題に変わります。

接続を1本足すたびに、認証・エラー処理・監視を個別に用意しなければなりません。いくつかのチームがそれぞれエージェントをつなぎ始めると、全体像を把握している人もいなくなります。

AnthropicもModel Context Protocol（MCP）を発表した際に、同じ点を指摘しています。これまではデータソースごとに個別の実装が必要で、つながるシステムが増えるほど拡張もセキュリティの確保も難しくなっていました。MCPは、この乱立を、どのエージェントとどのデータソースでも共通に話せる1つのプロトコルに置き換えました。

Gartnerのシニアディレクターアナリストは、AIエージェントのプロジェクトの40%超が2027年末までに中止されると予測しています。理由として挙げられているのは、コストの高騰・ビジネス価値の不明確さ・リスク管理の不備です。この予測の原因を分析したForbesの記事は、プロジェクトを止めるのは連携・データアクセス・説明責任にかかわる作業の後回しだと指摘しています。

モデルの実力を見極める段階に進む前に、プロジェクトが止まってしまうという指摘です。

では、日本の現場ではどうでしょうか。弊社では、商談の場でPoC（概念実証）までは進んだのに本番に移せないという話をよく伺います。足踏みの理由として挙がるのは、モデルの精度よりも社内のデータにどうつなぐかと、セキュリティ審査や稟議を通せるかという点です。情シスが少人数で運用している企業では、エージェントごとに接続を作り込む余力もありません。

エージェントに使わせたいデータはどこにある？

日本の現場では、エージェントに使わせたいデータがクラウドSaaSの外にも散らばっています。SalesforceやNetSuiteのようなクラウドSaaSを接続先の例に挙げる解説がほとんどですが、実際の置き場所はもっと多様です。

• kintone：国内で広く使われているSaaSです。部門ごとに作ったアプリに、案件・顧客・申請などの業務データが入っています。

• Excel：共有フォルダなどにファイルとして置かれ、集計表や台帳として人の手で更新されています。

• 基幹システム：販売・会計・在庫のデータは、オンプレミスで動いていることも少なくありません。

• クラウドのCRM・SFA：Salesforceなど、APIで外からアクセスできる業務システムです。

接続先ごとに、認証の方式もデータの鮮度も権限の持ち方も違います。そのため、接続の設計は「クラウドのAPIにつながるか」だけでは決まりません。次に紹介する3つの型を選ぶ前に、自社のデータがどこにあるかを棚卸ししておくと判断が早くなります。

3つの接続パターンはどう選ぶ？

目の前の課題を解ける最も単純な型から始めるのが基本で、実際に制約にぶつかったときだけ次の型を足します。本番運用されているエージェントの設計には、繰り返し現れる型が3つあります。すべての接続を1つの統制された窓口に通す型、データを複製せずにフェデレーションとプッシュダウンで取りに行く型、マルチエージェント向けの接続基盤（エージェントメッシュ）の3つです。どれも、エージェントのフレームワークやモデルを入れ替えても使い続けられる設計です。

エージェント自身の設計と、この3つの型の関係

ここで扱う3つの型は、エージェントが推論をどう組み立てるかという内部の設計ではありません。業務システムにどう届くかを決める外側の設計です。単一エージェントでもマルチエージェントでも、接続の設計は別に必要になります。どちらの構成にするかの考え方は、パターン3で触れます。

3つを最初から全部そろえる必要はありません。状況ごとに、まず検討する型は次のとおりです。

では、パターンごとに順に見ていきましょう。

パターン1：MCPの窓口を1つにまとめて統制する

統制されたMCPの窓口とは、背後のLLMが何であれ、すべてのエージェントがアクセス制御付きの1つのインターフェースを通して業務データやツールに届く構成です。エージェントごとに別々のコネクタを作る代わりに、窓口を1つに絞ります。

これを可能にしているのが、オープン標準のMCPです。AnthropicがデータソースとAIツールを安全に双方向でつなぐために発表したプロトコルで、現在はLinux Foundation傘下のAgentic AI Foundationに移管されています。特定のベンダーに左右されない、中立な標準として運営されているということです。MCPの仕様や基本的な仕組みから確認したい場合は、MCPとは？APIの仕様から紐解くMCP入門が参考になります。

この型を採るのは、2つ以上のエージェント、または2社以上のモデルプロバイダーが同じデータソースを使うようになったときです。エージェントとデータソースの組み合わせごとに個別の連携を作っていると、3つ目のエージェントや2社目のLLMが加わった時点で破綻します。

実際に、AIプラットフォームを提供するある企業は、共通のMCPベースの窓口で業務システムへの接続方法をそろえ、データ連携にかかる期間を数人月から1週間未満に縮めました（テクノロジー（AI SaaS）の導入事例）。

情シスにとって大事なのは、認証を既存の仕組みに任せられる点です。リモートのMCPサーバーは、すでに運用している認可サーバーに本人確認を任せる設計です。新しいID基盤を立てずに、Microsoft Entra IDなど社内で使っているIdP（IDプロバイダー）の延長で統制できます。

CData Connect AIは、この型の実例です。数百の業務データソースを1つの統制されたMCPインターフェースで公開し、OAuth/SAMLによるIDパススルーとユーザー単位のアクセス制御を、接続の時点で適用します。

パターン2：複製せずにフェデレーションとプッシュダウンで取りに行く

データフェデレーションは、複数の異なるデータソースから、事前にコピーや移動をせずに、1つのインターフェースを通してリアルタイムにデータを取り出す方式です（IBMの解説による定義）。エージェントにとっては、最新の値を本番システムに聞きに行くか、前夜にコピーした値で答えるか、の違いになります。

フェデレーションを実用的な速さにするのがプッシュダウンです。フィルタ・列の絞り込み・集計を、データを別の場所に移してからではなく、データソース側で実行します。動くデータの量が減り、処理時間も短くなります。エージェントにとっては、必要な行だけが返ってくるぶん、トークンの消費も抑えられます。

限界もあります。性質の大きく異なるデータソースをまたぐ複雑な結合や、データソース側が対応していない関数を使う場合です。このときはプッシュダウンが効かず、遅い処理に切り替わることがあります。

リアルタイムのフェデレーションとバッチのレプリケーションは、優劣ではなく用途で使い分けるものです。

エージェントがその場で最新の受注状況を確かめるならフェデレーションが向いています。DWHに集めた大量のデータを分析するなら、CData Syncのようなレプリケーションです。両方を組み合わせる構成も現実的です。フェデレーションを使えば、レプリケーションのパイプラインを先に用意しなくても、エージェントはリアルタイムの業務データに届きます。

パターン3：マルチエージェントになったらエージェントメッシュを検討する

エージェントメッシュは、エージェント同士やエージェントとツールの間のやりとりすべてについて、セキュリティ・可観測性・ディスカバリー・ガバナンスを担う接続基盤です。Solo.ioは、これをMCPやAgent2Agent（A2A）のようなプロトコルの下で動くレイヤーと位置づけています。

MCPとA2Aが決めているのは、エージェント同士がメッセージをどう交換するかです。メッシュは、これらのプロトコルが扱わないID・テレメトリ・アクセスのスコープを補います。メッシュがないと、エージェント間でIDがそろわず、テレメトリの共有もアクセスの範囲もばらばらになります。

検討するのは、マルチエージェント構成が複数のチーム・環境・フレームワークにまたがり、MCPやA2Aの進化に合わせて動き続ける必要が出てきたときです。その前に、単一エージェント＋MCPで足りるのか、A2Aで複数のエージェントを協調させるべきかを決めておくと遠回りせずに済みます。A2Aの位置づけとMCPとの関係は、GoogleのA2Aプロトコルとは何か - MCPとの関係とCData製品が果たす役割で整理しています。

3つの型に共通する設計上の注意点

• エージェントに広すぎる権限を持たせない：サービスアカウントの権限ではなく、依頼したユーザーの権限で動かします。

• 途中で失敗する前提で設計する：データソースの応答遅延や一時的なエラーに備え、タイムアウトと再試行の方針を決めておきます。

• 窓口を1つにする場合は可用性を確認する：すべてのエージェントが通る入口になるため、停止したときの影響範囲を事前に把握しておきます。

本番前に確認すべき3つのチェックポイントは？

確認すべきなのは、IDパススルー・CRUD（作成・読み取り・更新・削除）の制限・監査ログの3つです。ID・アクセス・監査のチェックポイントは、アーキテクチャのどの部分よりも本番前に抜けやすい項目です。先に挙げたGartnerの予測と、その原因を分析したForbesの記事も、この抜けが中止の背景にあるとみています。セキュリティ審査や稟議の場でも、説明を求められやすい論点です。

最初に確認したいのはIDパススルーです。エージェントが誰かの代わりにデータを取りに行くなら、エージェント自身のサービスアカウントの権限ではなく、依頼した本人の権限でリクエストする必要があります。監査ログについては、社内のSIEM（セキュリティ情報イベント管理）に送って既存のセキュリティ監視に組み込めるかも確認しておきましょう。

Connect AIは、接続の時点でIDパススルーとユーザー単位のアクセス制御を適用します。返ってくるデータを決めるのはユーザーがもともと持っている権限で、エージェントのサービスアカウントにどれだけ広い権限があっても関係ありません。依頼した本人が見てよい範囲を超えてエージェントがデータを見てしまう穴を、ここでふさぎます。kintone MCPコネクタでユーザーごとの認証が使えるようになった点は、kintone MCPコネクタのPer User Authentication対応で紹介しています。

コラム：エージェントの認証方式とMCPの認可仕様
エージェントの認証には2つの方式があります。エージェント自身のサービスIDで認証する方式（client_credentials）と、ユーザーから委任されたIDで動く方式（PKCE付きのauthorization_code）です。誰かの代わりにデータを取りに行くなら、後者で本人の権限を運ぶ必要があります。エージェントのID管理をOAuthの観点から整理した記事「AIエージェントのID管理を簡素化｜OAuth活用術」も参考になります。
MCPの認可仕様は、すでに運用しているOAuth 2.1の認可サーバーに認証を任せる前提で作られています。ディスカバリーはProtected Resource Metadataで標準化されています。audienceの検証によって、リモートのMCPサーバーを既存のIdPにひも付けられます。HTTPで動くリモートMCPサーバーには、OAuth 2.1とPKCE（必須）の実装が求められています。

ガバナンスの考え方については、AIエージェントのデータガバナンスの4つの柱で、実装を担うIT部門向けにより詳しく整理されています。セキュリティ審査に備えて設計の観点を押さえたい場合は、AIエージェントのセキュリティはどう守る？ガバナンス設計の7つの原則も併せてご覧ください。

データレイヤーはどう選ぶ？

判断の軸は、フレームワークやLLMを替えてもデータレイヤーを作り直さずに済むかどうかです。データレイヤーは、その上に載るエージェントのフレームワークより長く使われるのが普通です。このインフラはエージェント型コントロールプレーン、最近ではAI Gatewayとも呼ばれます。チームが使うエージェントのフレームワークを外側から包む、ガバナンスと接続のレイヤーです。

選ぶときは、来年フレームワークを乗り換えたり、新しいLLMプロバイダーを足したりした場面を想像してみてください。データレイヤーを作り直す必要があるのか、それとも新しいフレームワークを同じ統制された窓口に向けるだけでそのまま動き続けるのかを見極めましょう。後者であれば、そのデータレイヤーは長く使えます。

導入を決める前に確認したいのは、次の点です。

• 統制下でつなげるデータソースの数

• kintone・Excel・オンプレミスの基幹システムなど、自社のデータの置き場所に届くか

• MCPに加えて、OAuth 2.1とPKCEに対応しているか

• すでに運用しているIdPと連携できるか

• 全件を取り込んでから絞るのではなく、リクエストをデータソース側にプッシュダウンできるか

接続で止まらないエージェント基盤をつくる

CData Connect AI Gatewayは、この記事で取り上げた統制されたMCPの窓口を、数百の業務データソースに対して提供します。OAuth/SAMLによるIDパススルーとユーザー単位のアクセス制御は、先ほどの3つのチェックポイントに沿って適用されます。

オープン標準の上で動くため、エージェントのフレームワークやモデルプロバイダーを替えても、データレイヤーはそのまま使い続けられます。

まずはCData Connect AIの無料トライアルで、チームで使っている身近なデータソースとの接続から試してみてください。

よくある質問