接続先を替える

検索が通っても、「規程がない」の意味は変わり得る

社内文書を調べるAIの検索担当を、新しい提供者へ替える。 同じ質問を送れて、回答も戻る。 ところが、新しい担当が「見つかりません」と返した理由は、規程が存在しないからではなく、利用者の権限では読めないからかもしれない。 これは接続先の交換を考えるための想定例だ。 利用者には、通信が成功したかより、調べた範囲を信じてよいかが重要になる。

A2A、MCP、OpenAPIを扱う発表や仕様は、異なる担当や道具へ接続する方法を具体化している。 6月にはA2AがLinux Foundationへ寄贈され、MCP ToolboxをIDEとデータベースにつなぐ説明例も公開された。 接続の共通化を、製品をまたぐ仕事の設計に使える材料が増えている。

本稿の結論は、接続先を交換する自由を得るには、利用者が結果を読む条件も保つ必要があるということだ。 出典のある答えと本文だけの答え、検索結果が空であることと検索に失敗したことを、同じ成功へまとめない。 共通の形式を出発点に、意味、権限、失敗の扱いまで比べたい。

共通化する対象

担当への依頼、道具の呼び出し、APIの記述は異なる

A2Aの発表は、別のエージェントの能力を見つけ、タスク、進捗、成果物をやり取りする設計を示す。 MCPは、AIアプリケーションから道具やデータへ接続するための仕組みだ。 OpenAPI 3.1.1は、HTTP APIの入力、応答、認証などを記述する形式を定める。 それぞれ、共通化する対象が違う。

検索の想定例では、文書検索を行う道具を呼ぶ構成と、別の担当へ調査を依頼して成果物を待つ構成がある。 その内部で、OpenAPIに記述した業務APIを使うことも考えられる。 三つの名前を並べても、どの文書を検索し、何を完了とするかは決まらない。 接続する相手の仕事を先に定義する必要がある。

6月23日のA2A寄贈では、仕様、SDK、開発用の道具を独立したプロジェクトへ移すと説明する。 複数の企業が規格の発展や保守へ参加する枠組みは、長く接続を使う上で意味がある。 一方、規格の管理が中立であることは、各提供者の検索結果や業務判断が同等であることの証明ではない。

道具が仕事へ入る

データベース接続は、検索からコード変更まで仕事を広げる

Google Cloudの6月4日のMCP Toolboxの説明は、新任開発者Saraが、VS Code内のClineから開発用のCloud SQL for PostgreSQLへ接続する場面を示す。 テーブルや未完了の注文を調べ、取引先のテーブルと在庫の取引先IDを追加する。 続いて、アプリケーションのモデルとInventoryDAOのテストを更新する。 データベースの構造を読む接続が、コードの変更と検証まで同じ仕事につながる例である。

資料はこの流れを説明し、短時間で終わると述べるが、同じ課題を人とAIで比較した計測ではない。 ここから読み取れる価値は、接続によって実際のデータ構造を参照し、変更する範囲を具体的に扱える点だ。 読む道具と、テーブルを変更する道具では、必要な権限も失敗した後の確認も異なる。

接続先を替えるなら、同じ道具の名前が見えるだけでは足りない。 開発用の同じデータベースを対象にしているか、読み書きできる範囲は同じか、変更後にコードとテストが整合するかを確かめたい。 共通の接続形式は、こうした比較を始めやすくする。 比較そのものを不要にするわけではない。

出力の構造と意味

同じ項目で返せても、同じ事実を返すとは限らない

MCPの6月18日版の道具仕様では、構造化した結果と、その出力形式を記述するoutputSchemaを扱う。 形式を提示する場合、サーバーはそれに合う構造化結果を返す必要があり、利用側にも検証を推奨する。 天気の例は、温度が数字であり、摂氏を使うことまで説明する。 値を受け取るプログラムが、形式を確認するための材料になる。

文書検索へ当てはめるなら、本文、出典URL、文書の版、調べた範囲を項目として定められる。 これは本稿の設計案で、MCPがすべての検索へ要求する項目ではない。 古い版だけを検索した結果と、現行の版を検索した結果は、同じ項目を持っていても判断への使い方が違う。 構造の一致と、業務上の意味の一致を分けて検証する必要がある。

OpenAPIの記述にも、応答や項目の説明を通じて業務の意味を表現できる。 ただし、同じ仕様版を使うという事実だけで、二つの提供者が同じ定義を採用したとは分からない。 接続先を交換する際は、返された値を画面へ渡す処理だけでなく、その値から何を結論付けるかも比べる。

誰の権限で読むか

接続方式が同じでも、利用者の閲覧範囲は自動では引き継がれない

MCPの6月18日版の認可仕様は、HTTPで接続する場合の認可の流れを定める。 認可機能自体は任意であり、すべてのMCP実装へ同じOAuthの仕組みを義務付けるものではない。 標準入出力でつなぐ方式では、環境から認証情報を得る設計を扱う。 どの接続方式を使うかで、確認すべき条件が異なる。

HTTPの認可仕様は、接続先が自分に対して発行されたアクセストークンかを検証するよう求める。 そのため、提供者を替えたからといって、前の接続先向けのトークンをそのまま使う設計にはできない。 接続先と認可する対象を合わせ、その利用者にどの文書が読めるかを確かめる。 共通の形式は、どの接続先にも同じ権限を与えるという意味ではない。

仕様は、無効なトークンなどの401と、権限不足などの403を分ける。 アプリケーションが両方を空の検索結果へ置き換えると、利用者は「見つからない」と「読めない」を区別できない。 何が検索対象になったかを知りたい人のために、この違いを画面まで保つ必要がある。

成功と失敗の読み方

結果を受け取れたことを、検索が成功したことへ置き換えない

MCPの道具仕様は、プロトコルのエラーと、道具の実行で起きたエラーを区別する。 後者は結果の中でisErrorを付け、APIの失敗や業務処理の誤りなどを示す。 結果を受け取れた場合でも、その内容は道具の失敗かもしれない。 利用側が結果の本文だけを読むと、この区別を落とすことになる。

冒頭の文書検索を考えると、対象範囲に該当文書がない場合、対象文書を読む権限がない場合、検索処理が止まった場合は別々に扱いたい。 これは本稿が提案する業務上の区別だ。 回答を作る担当へ渡す際にも区別を保てば、検索ができていないのに「規程はありません」と答えることを防ぐ設計になる。

長い処理では、待ち時間が過ぎた場合も、相手の仕事が終わっていない可能性がある。 検索なら再実行できる場合があるが、外部の記録を変更する仕事では、先の操作が確定したかを調べず再実行すると重複が起こり得る。 待ち時間や再試行の方針は、道具が読むだけか、変更するかに合わせて定める必要がある。

管理サービスとの組み合わせ

共通の接続と、サービスの管理を同時に使える

Responses APIの5月の更新は外部のMCPサーバーへの接続を加えた。 FoundryのDeveloper Essentialsも、A2A、MCP、OpenAPIによる接続と、管理サービスでのエージェント実行を説明する。 管理された実行環境でも、共通の接続方式を使う選択がある。

この組み合わせは、実行環境の管理を任せながら、外部の道具や担当を使う道を開く。 しかし、別の接続先へ替えたときに、出典、閲覧範囲、失敗の区別が保たれるかは、アプリケーションで検証する必要がある。 対応するプロトコルの一覧は候補選びに役立つが、仕事の交換条件を説明するには、実際に使う機能と版を確認したい。

交換の判断

同じ仕事を使って、変わる結果と保つ条件を確かめる

検索担当の交換を検証するなら、同じ文書、利用者、質問を使う。 現行の文書と古い版、閲覧できる文書とできない文書、該当文書のない質問を含める。 正常な結果だけでなく、権限不足、道具の失敗、応答待ちも比べる。 結果の見た目より、利用者が同じ条件で結論を読めるかを確認する。

差があれば、変換処理で保てる条件と、提供者の機能として保てない条件を分ける。 たとえば、出典が返らない担当へ替えるなら、後から本文の形式を整えるだけでは出典を回復できない。 同じ用途に使えると説明する範囲を狭めるか、必要な結果を返す接続先を選び直すことになる。

意味を保つ

文書の版、出典、検索対象を定義し、同じ判断へ使える結果か確かめる。

閲覧範囲を保つ

接続先の認可を確認し、読めない文書を「存在しない」と扱わない。

失敗を保つ

空の検索、権限不足、実行失敗、待機中を区別して返す。

相互運用の価値は、接続先の数だけで決まらない。 交換した後も、利用者が検索結果を同じ意味で読み、必要な判断を続けられることにある。 共通の形式を使いながら、交換前後で保つべき条件を具体化することが、将来の選択を広げる。