AIエージェントのツールが「検索結果はこれです」と文章を返すだけでは、次の処理で値を取り違えても気づきにくくなります。MCPの2025-11-25仕様には、戻り値の形を宣言するoutputSchemaと、構造化データを返すstructuredContentがあります。これは単なるJSON化ではなく、エージェントの判断を検証可能な契約に変える仕組みです。
文章だけの戻り値は、次工程で曖昧になる
たとえば天気ツールが「気温は22.5度、湿度は65%です」と返した場合、人には読めても、後続処理は数値・単位・項目名を文章から再解釈しなければなりません。表現が少し変わるだけで、抽出ロジックやAIの理解が揺れます。
MCP仕様では、ツール結果は従来のcontentに加えて、JSONオブジェクトをstructuredContentとして返せます。さらにoutputSchemaを定義すると、返却すべき項目・型・必須条件を事前に示せます。サーバーはそのスキーマに適合する結果を返す必要があり、クライアント側にも検証が推奨されています。
outputSchemaがつくる3段階の防波堤
1. ツール側で壊れた出力を止める
気温が数値であるべきところに文字列が入った、必須の湿度が欠けた、といった異常をスキーマ検証で検出できます。AIへ渡してから推測で補わせるのではなく、境界で止める設計です。
2. エージェントの再解釈を減らす
temperature、conditions、humidityのように項目が明示されれば、エージェントは自然文を分解し直す必要がありません。MCP仕様は、出力スキーマが型情報の提供、厳密な検証、クライアントやLLMによる解析の支援につながると説明しています。
3. 後続システムへ安全に渡す
構造が固定されていれば、集計、条件判定、別ツールへの入力を通常のプログラムで扱えます。AIの柔軟さと、決定論的なソフトウェアの厳密さを分担できます。
エラーにも「直せる情報」を返す
MCPはエラーを、リクエスト構造そのものが不正な「プロトコルエラー」と、日付や値の範囲など実行条件に問題がある「ツール実行エラー」に分けています。後者はisError: trueと、修正に使える説明を結果として返せます。クライアントがその情報をモデルへ渡せば、エージェントは引数を直して再試行できます。
「失敗しました」だけでは復旧できません。「出発日は未来の日付で指定してください」のように、次の一手が分かるエラーを返すことが重要です。
大量データは一度に返さない
構造化しても、全件を一度に返せばコンテキストを圧迫します。MCPのページネーション仕様は、一覧を小さなまとまりに分け、nextCursorで続きを取得する方式を定めています。ページサイズはサーバー側が決め、クライアントは固定値を前提にしてはいけません。
実装では、次の順番が堅実です。
- 通常は必要最小限の項目だけ返す
- 一覧はページネーションする
- 詳細は別の取得操作に分ける
- スキーマ検証に失敗した結果はAIへ渡さない
考察：AI時代のAPI契約は「意味」まで含む
従来のAPI設計では、HTTP 200でJSONが返れば成功と見なしがちでした。しかしAIエージェントでは、そのJSONを次の判断材料として使います。項目名が曖昧、型が揺れる、エラーに修正方法がない――こうした小さな不備が、数ステップ後の誤操作へつながります。
車載システムで信号の型・範囲・異常時動作をインターフェースとして決めるのと同じです。モデルの賢さで吸収するのではなく、ツール境界で正常系と異常系を定義する。これが、エージェントを長い工程で安定させる近道だと考えます。
まとめ
structuredContentで結果を機械処理しやすくするoutputSchemaで項目・型・必須条件を契約にする- 修正可能なエラー情報を返し、再試行につなげる
- 大量結果はページネーションし、コンテキストを守る
AIエージェントの信頼性は、モデルだけで決まりません。ツールの戻り値を「読める文章」から「検証できる契約」へ変えることが、地味ですが効く設計改善です。