Agentの能力契約を検証する

Agentが能力を公開していることと、その能力を利用者の期待どおりに実行できることは別です。能力契約の検証では、宣言、入出力schema、protocolと版、認証・認可、呼出し状態、業務上の効果を分けて確認します。同じ名前のskillやtool、同じJSON構造だけから、取消、重複実行、失敗、完了の意味まで同じと推定しません。

A2A v1.0.1のAgent Cardは、interfaceとprotocol版、capabilities、skill、入出力media等を記述します。skillは能力を説明する概念であり、宣言文が業務の正確な実行を証明するわけではありません[S1]。署名があるcardでも、署名対象の完全性と、宣言した仕事が安全・正確にできることは別の検証です。

MCP 2025-06-18のTools仕様には、toolのschema、結果content、tool実行errorとprotocol errorの区別が示されています[S2]。また2026-07-28版のcancellation文書は、進行中requestの取消が、既に処理が完了した時点へ到着する場合を扱っています[S3]。ここでは異なる版の文書を全実装の共通仕様へ混ぜず、対象が採用する版を契約に固定します。

Pactの公式資料は、consumer側の期待を実装に対するprovider verificationと組み合わせ、その結果を共有する契約検証を説明しています[S4]。schemaから作ったファイルだけで双方の実装互換性が証明されたことにはなりません。この考え方をagent連携にも適用しますが、Pactを使うだけで生成結果の品質や外部効果の正しさが保証されるとは主張しません。

この層分けは提案する検証モデルです。toolのread-onlyなどの注記があっても、適用先の権限と実際の操作を確認します。自然言語の説明と機械的なschemaが矛盾する場合、実行時に都合のよい方だけを選びません。

consumerは、自分が依存する条件を具体化します。例えば「顧客IDを指定して現在の契約状態を読み、変更しない」という能力なら、対象tenant、取得時点、存在しないID、権限不足、部分応答、schema上のnull、古いcache、外部書込みの不存在を別の条件にします。これは例示する契約であり、特定の実APIで確認した挙動ではありません。

provider側では、固定した状態と入力を用いて実装へrequestを送り、consumerが必要とする応答・error・副作用を確認します。mockが返す期待値を同じmockへ照合するだけでは、providerの実装検証になりません。外部serviceへの接続をmockにした場合も、SDKの送信内容を確認したのか、実serverの認可や効果まで確認したのかを区別します。

正常系に加え、unsupported capability、protocol版の不一致、認証不成立、権限のないresource、無効な引数、依存serviceの停止、timeout、部分応答、重複requestを確認します。protocolとして受理されたことと、toolの業務処理が成功したことを同じsuccessへ潰しません。

取消では、要求を送る前、受理後、効果の適用後、結果配信前を区別します。処理が完了してから取消が届く場合には、その効果の結果を調べる必要があります。request取消と、長時間task・provider側jobの取消が同じ手順や同じ保証を持つとは仮定しません。外部操作の結果が不明なら、即座に再実行する前に対象の状態と操作IDを照合します。

streamingでは、途中の引数や部分contentを最終結果として適用しません。完了・失敗・取消・未完了を判別し、関連するIDを保持します。接続が切れてもjobが残る構成では、そのjobを追跡する契約が必要です。clientのtimeoutを外部job停止の証明にしません。

生成を含む能力は、応答文の完全一致だけでは検証しにくい場合があります。構造、必須情報、禁止された効果、根拠の対応、業務上の許容条件を分けます。意味評価が必要な部分は、入力集合、評価基準、評価者、試行条件とばらつきを残します。評価用LLMがPASSと言ったことを、権限や外部結果の代わりにしません。

回数や合格率の閾値は、業務影響と母集団に応じて決めます。本項では普遍的な数値を指定しません。少数の例で良い結果が出ても、全言語、全media、全modelへ同じ能力を宣言しません。画像、音声、文書などでは、schemaが通ることに加え、内容の欠落や順序・引用元の保持も確認します。

契約と結果には、consumer/provider、agent/model、protocol、SDK/adapter、card/schema、tool実装、policy、評価集合の版を結び付けます。宣言が変わらなくても、実装、model、権限、backendが変われば依存する検証を再実施します。cardのhash一致だけで実効状態が同じと判断しません。

失敗した契約がどのconsumerへ影響するかを追跡し、影響しない検証まで毎回全面的にやり直さず、依存関係に基づいて再検証します。逆に宣言・schemaだけの変更と決めつけて意味的変更を見逃さないよう、変更理由と実装差分を記録します。配布や切替前には、実際に組み合わされる版の検証結果を照合します。

契約マニフェストにはcapability ID、宣言のhash、対象interface、protocol版、schema、認可条件、外部効果、正常・異常系、状態遷移、期待readback、検証環境と結果locatorを持たせます。consumer側の期待とprovider側の実装検査を区別し、生成品質の評価と機械的な不変条件も別に管理します。

本RUNではA2A/MCP server、Pact provider、実LLMを接続した契約試験を実行していません。ここに示した試験項目は実装・監査へ渡す設計であり、特定agentの適合証明ではありません。

主な失敗は、skill名一致を意味一致とすること、宣言から生成したschema検査だけで実装をPASSすること、errorを通常contentへ変換すること、timeout後の重複効果、途中streamの適用、取消後の結果未照合、版を特定しない検証結果の流用です。低権限の検証を管理者権限の本番経路へ一般化することも避けます。

capability宣言とschemaは発見・事前検査に有用です。ただし、それぞれの仕様に準拠した実装でも、業務目的に対する同等性は別に評価する必要があります。contract testingも、契約に含めていない条件や観測していない外部serviceの効果を保証しません。宣言・実装・意味・運用のどこまで確認したかを明記します。

対象agentと実装版、採用protocolのrelease状態・拡張、SDKによる変換、consumerの実依存、権限と副作用、非決定性の許容値、長時間・streaming・multimodalの実挙動、独立した運用事故は未確認です。複数protocolやproviderの完全互換性を主張しません。

「指定したconsumer/providerの版と入力・状態について、宣言・構造・呼出し・効果の契約を検証した」とします。「同じtool名とschemaなので、同じ能力として交換できる」とは記述しません。

実行対象の版、認可、error/取消の意味、部分結果、外部効果のreadbackが不明な場合は、その能力を適合済み・意味的に同等と宣言しません。

EA-500-R1-20261013と継続Doc 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewUのEA-500節を継承。2026-10-18に一次資料を再確認。A2A v1.0.1、MCPの指定版、Pactの実装検証を別の証拠として扱いました。

• [S1] A2A v1.0.1 specification、AgentCard / AgentSkill / AgentInterface: https://a2a-protocol.org/v1.0.1/specification/
• [S2] MCP 2025-06-18 Tools、schemaとerror handling。全採用環境の最新版とは扱わない: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
• [S3] MCP author repository、2026-07-28 cancellation文書。対象実装の対応とrelease状態は別途照合: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/basic/patterns/cancellation.mdx
• [S4] Pact How Pact works / Verifying Pacts、consumer期待とprovider実装の検証: https://docs.pact.io/getting_started/how_pact_works ; https://docs.pact.io/provider