24件PASSが示す範囲。AAEの外部議論で変わった検証報告

「24 pass、0 fail、0 skipped」。一見すると、すべてが終わったように見える数字です。私たちは、外部のエージェント認可プロファイル向けに以前記録したクロスランのレポートを公式チェッカーで検査したとき、この数値を実際に確認しました。ただし、誰が受信側を実装し、その日に何を実行し、何が独立に検証されたかは、この数字からは読み取れません。この区別をめぐる公開の議論は、相手プロジェクトの報告形式の具体的な改善と、Agent Role Contracts（ARC）側のフォローアップ課題につながりました。

比較の始まり：ARCとAAEの異なる役割

GitHubのA2A仕様提案 #2391では、提案者らが、エージェント間の委任権限を受信側で確認するAAE（Agent Authorization Envelope）プロファイルを議論していました。ARCが実行前に与えられた宣言の整合性を検査するのに対し、AAE側の受信者は実際に届いた要求に対する認可判断と、要求内容のダイジェストを記録します。両者は、同じPASSという言葉だけで比較できる関係にはありません。

提案者からARCメンテナーへの依頼は、固定されたケースセットでのクロスランでした。この依頼をきっかけに、事前宣言の検査、認可プロファイルを適用する受信者、その先で起きる外部操作を、別々に記録する必要がより明確になりました。

11月6日に確かめたのは「既存レポートの妥当性」

私たちが2026年11月6日に実行したのは、固定commit 08f41146… の公式 python -m aae_a2a.crossrun check です。対象は、以前にローカルで記録した合成オフライン受信者の結果レポートでした。コマンドは valid (24 pass, 0 fail, 0 skipped) と終了コード0を返し、24ケース・26回の提示を検査しました。この段階で受信者を新たに走らせたわけではなく、外部のA2A実装との相互接続も実行していません。原記録には、評価時刻の固定値、対象（audience）、合成データという範囲、レポートのハッシュを残しています。

さらに、私たちの受信者実装は、プロファイル本文だけを見て一から書いた「クリーンルーム実装」と主張できるものではありません。参照ソースの知見を用いたローカル実装でした。独立コードQC、実際のA2A相互接続、第三者の公式クロスラン登録は、いずれも未実施・未提出として区別しました。こうした未実施の表示は、次に必要な証拠を示す点で、PASS件数と同じくらい役に立ちます。

外部からの指摘が、報告フォーマットを変えた

A2A Issue #2391での提案者の指摘は具体的でした。結果表に「24 pass」と書くだけでは、受信者がプロファイル本文だけから実装されたのか、参照ソースを利用したのかが分かりません。私たちは自分たちの実行の来歴を明示し、独立した相互運用として提示しないよう返答しました。

その後、提案者は結果ファイルと公開クロスラン表に必須項目 receiver_provenance を追加しました。値は clean_room、reference_informed、unknown のいずれかです。この項目がない結果ファイルをチェッカーは受け付けません。別の第三者による実行が最初の第三者ランとして掲載され、参照ソースの知見を用いた私たちの未提出レポートは、私たちの希望どおり掲載されていません。

これは公開の技術対話から生まれた具体的な成果です。報告のなかで、実装の来歴が結果件数の隣に見えるようになりました。ただし、これはAAE側の報告契約の改善です。ARCの性能優位や新しい導入実績を示すものではありません。

ARCで防ぎたい報告の省略：結果の段階を書かない短い要約

この経験を受けて、私たちはARC #119を起票しました。評価サマリーだけを読んでも、実装の来歴、オフラインかライブかの実行範囲、どの段階を実行したか、独立検証の有無、元の記録へのリンク、未実施（NOT_RUN）の項目が分かるようにする課題です。2026年11月8日時点では未着手の課題であり、実装済みの機能ではありません。

こうした形式にすると、検証の次の一手が明確になります。「PASS」が指しているのは、宣言の検査でしょうか。レポートの検査でしょうか。受信者でしょうか。外部で観測された操作でしょうか。レポートの検査にとどまるなら、次に必要なのは受信者の独立レビューや、別環境での相互接続です。業務上の効果を主張するなら、受信側の永続的な記録と、元の承認内容との対応が必要になります。

OSSの評価報告に入れたい5項目

最後の「継続価値」は、ARC自身にとっても未解決です。ARC #47では10件の実ワークフローでの検証を目標にしていますが、私たちは合成デモの成功や自社の再現実験を外部採用に数えません。人がかけた手間、既存の対策に加わる効果、2件目の異なる実タスクについての証拠が、まだ必要です。

信頼できる評価に必要なのは、大きな合計値よりも、その数字で確かめたことと、まだ確かめていないことを、別のエンジニアが判断できる状態だと考えています。ARC #37では、初回利用の感想、うまくいかなかった点、既存の対策で十分だった例を募集しています。

一次資料： ARC #105の実行記録／A2A #2391での報告形式の改訂／ARC #119のフォローアップ／ARC #47の導入評価。Netsujoは、本記事で扱うOSS「Agent Role Contracts（ARC）」の開発元です。本文の作成と編集にAIを使用しています。本記事は、ARCの第三者による独立検証や商用導入の実績を示すものではありません。