承認は40、送信は120という想定。ツール定義を送信直前に確かめる
ツール定義が承認後に変化する参照モックで、結果報告のallowと送信前の許可を分けて確認しました。M3再実行の範囲と共同ERP試験の未実施を明示します。
AIエージェントに「40個の発注を許可する」と伝えたとして、実際のツールが呼ばれる時にも「40個」を意味するでしょうか。引数の見た目が同じでも、実行時に参照するツール定義や変換ロジックが変われば、外部システムへ届く結果は異なり得ます。この問いを私たちは、Agent Role Contracts（ARC）の宣言検査から、外部の研究者との共同ERP実験の設計議論へ持ち込みました。
きっかけは、宣言チェックだけでは分からない変化
ARCのG1チェックは、与えられたタスク・アクション・結び付け宣言が整合するかを検査します。実行直前に外部ツールの定義だけが変わった場合、同じ宣言が整合したままでも実行結果が変わり得ます。これは宣言検査の守備範囲を表す境界であり、出荷済みARCの実行時不具合を示す証拠とは別のものです。
2026年11月、私たちはARC #117でT4（tool-definition drift）の試験設計を提案しました。比較するのは、宣言検査、送信直前の認可、永続化されたERPデータの3種類の証拠です。例として「承認量40、定義変更後の結果120」という差分を使います。この40→120は検証のために提案した候補ケースであり、共同で凍結・承認された試験結果ではありません。
外部レビューで見つかった「allow」の落とし穴
Guardian参照モデルに関する実装者側の返答は、参照モックがランナーからの dispatched 報告を契機に定義ダイジェストを再検査し、強制モードでは予約を HELD にする仕組みを説明していました。このモックを確認した私たちが指摘したのは、その場合でも steps/toolCallResult の応答が allow / result recorded のままになる点です。「報告を受理した」という応答は、「ERPへ送ってよい」という許可と同じではありませんでした。
この指摘の後、参照スイートのコミット 943a495は、送信前の steps/toolCallRequest にR1の判断を移しました。Gatewayは実行直前の定義を計測し、新しい試行IDで定義ハッシュと来歴を提示します。Guardianは現在の予約・承認状態と合わせて判定し、Gatewayが転送するのは、要求IDが一致するスキーマ妥当な allow が返った場合だけです。送信前に dispatched 報告を作り出す方法や、結果報告への受理応答を許可とみなす方法とは異なります。これらは参照モデル上の測定であり、実際のERPへの送信を防いだ証明とは区別しています。
Netsujoで確認できた範囲
私たちは改訂後の参照スイートを別のM3ホストで独立に再実行しました。私たちの記録では、13ケースの動的試験、T1–T10回帰（T9は想定どおりのEXPECTED-MISS）、セルフテスト、トランスクリプト照合が成功しています。これは参照モックの挙動を再現できたという結果です。実際のPostgreSQL/ERPゲートウェイが物理的なネットワーク送信を止めたことや、共同パイロットに対する正式な独立コードQCの完了は、この結果の範囲外です。
別途、公開版ARC 1.0.1によるERP形状の合成宣言検査では、架空のパラメータでG1の結び付けを検査しました。結果は渡された宣言についてのもので、全ケースで execution_authorized:false です。Guardianの判断やERPへの永続的な効果をARCが認証したわけではありません。
三者で決めるまで、共同実験は成立しません
Netsujo側の記録によると、共同研究の相手方の研究者は、比較する2条件（C2とC3）で同じ凍結済みのツール定義変更を使うこと、権限の取得点、定義の再検査点、ERPへの効果が確定する境界を実装前に固定することに同意しました。ARC側の提案では、この3点をA1、R1、K1と呼んでいます。この同意はGitHub外での返信をNetsujoが要約したもので、凍結済みの共同合意ではありません。参照モデルの実装者側の返答は、C2を強制つきの照合、C3を宣言のみの統制に対応付け、記録するが強制しないT4bは別ラベルの追加ケースとして実行できると述べています。
共同実験として意味を持たせるには、定義の実バイトとハッシュ、認証された来歴、ケースごとに独立した操作ID・試行ID、ゲートウェイが転送しなかった記録、K1以後の独立したERP読み戻しが必要です。タイムアウトや409を受けた後にも読み戻しを行います。外部ラボのコードの再利用・改変・実行・公開の許諾は、公開リポジトリで閲覧できることから推測せず、明示的に確認します。
2026年11月10日のV0.3.2レビューの時点で、V0.3.2は検討中の提案であり、共同契約は未凍結です。新しい共同ERP実行（C0–C3）は行われていません。この区別を見える形で保つことが、今回の共同研究で守っている条件です。
実装チームに残したい設計上の質問
ツールを呼ぶ基盤では、実際に使う定義をいつ計測するか、誰がその版やハッシュを計算して認証するか、どの信号を外部送信の許可として扱うかを書き出してください。送信するゲートウェイがエージェントの自己申告だけで転送していないかを検査します。送信後は応答コードに加えて、受信側の永続的な記録を確認します。宣言の事前検査、Guardianの判断、受信側の記録は分けて報告します。
あなたのエージェント基盤では、承認後・送信前のツール定義の変更を検知できるでしょうか。 実装の経験や、既存のGatewayやIAMの設計でこのリスクを防げている例を、ARC #117でお待ちしています。
一次資料： Guardian側の回答／R1の技術レビュー／Netsujo再現記録／共同研究の現在地。Netsujo株式会社はARC（Agent Role Contracts）の開発元です。本記事の編集にはAIを利用しています。各主張の出典と範囲は上記のリンクで示しています。