AIエージェントの信頼を、公開議論から検証する。ARCで見直した3つの条件
公開フィードバックを受け、ARCで見直した権限の出所、証拠の帰属、結果不明時の再実行条件を整理します。文書設計、限定実装、未検証の境界を一次資料で確かめます。
AIエージェントを業務につなぐとき、宣言の検査が通ったあとに何を確かめるか。Agent Role Contracts（ARC）の公開議論では、この問いが設計を変えています。見直したのは、権限の出所、証拠が属する対象、結果不明時の再実行という3つの条件です。
2026年10月27日時点の記録をたどります。外部から寄せられた指摘や報告、設計への反映、限定された試作、独立した受入を分けて読むための記事です。ARCを既存の制御に追加する価値は、引き続き検証する仮説です。
公開議論を、受入条件の変更として残す
PR #83では、公開フィードバック7件と設計判断を対応付けました。統合されたコミットは 2bae232b5d62221b468dc6d58228da8faf85e82f。変更は ARCHITECTURE.md、ASSURANCE.md、FEEDBACK_INTEGRATION_DESIGN.md、INTEGRATION.md の4文書です。この統合によって、新しい実行時機能が出荷されたわけではありません。
固定コミットの設計文書は、公開対話を設計判断へ結びつけた記録です。対応表には、権限付与の出所、実効権限の比較、設定負担、既存の役割台帳からの生成、結果の確定と再試行、承認時点からの依頼変更などが並びます。ここでは、その後の具体的な試験案も含めて3つに整理します。後続のIssueやコメントの提案まで、PR #83で実装されたと数えることはできません。
現在の宣言検査を確かめたい方は、PASSが示す範囲の記事を参照してください。実務評価の手順と公開の経緯は、評価キットのニュースにまとめています。
条件1：宣言と、権限の出所・実際の制限を別々に確かめる
外部の指摘
Srinathとの公開対話では、次に確かめる問いが、実行を認める権限付与（grant）はどこから来るのか、という点へ進みました。設計文書が参照する別の評価者の比較では、ARCの宣言がPASSでも、ホストの実効権限一覧には過剰な権限が見つかったと報告されています。これは外部報告であり、実際の実行制限の独立検証とは区別します。
見直した条件
設計では、元になる承認・ポリシーの版、発行者が権限を与えられる主体か、現在の実行環境が持つ権限を、それぞれ確かめる条件を置きました。既存の正本となる役割台帳があるなら、そこから再現可能に宣言を生成し、もう一つ手作業の権限台帳を増やさない方針です。生成できない制約は黙って捨てず、関係する実行の受入を保留します。
検証状況
maintainerによるstdio MCPの限定比較では、合成6行で、独自のタスク検査と同じ情報を持つホスト側ポリシーが同じ結果になったと報告されています。限定実装の結果であって、実際のエージェント実行環境全体の受入ではありません。重複した結果を、ARC独自の強制力として紹介することはできません。
Issue #85は、実際の書き込み制限を調べる試験設計です。架空データだけの作業領域と保護対象のsentinelファイルを用意し、拒否ログ、実際の処理開始、ファイルの変更を別々に観測します。制限を試す前後には、許可された対照操作を観測できることも確認します。拒否ログがあっても実変更があれば矛盾として残し、観測が欠ける・古い・不完全なら結果はUNKNOWNです。
DEVに公開したsentinel試験手順も、実行結果を含まない提案です。同一アカウントの別プロセスだけで改ざん耐性のある観測を証明したことにはならず、前後のハッシュ一致だけでは途中の書き込みと復元を除外できません。第三者製品の脆弱性や、マシン全体の隔離を確認したという主張はしていません。
条件2：遅れて届いた証拠を、元の対象へ結びつける
外部の指摘
Zeoliteの公開議論を受けた比較案は、同じクライアントのまま対象が変わる場面を扱います。文書Aの観測を始めたあとでBへ移動し、Aの結果が遅れて届く場合です。クライアントIDや見えている文字が同じでも、その証拠でBの完了を確定してよいかは別に判断する必要があります。
見直した条件
この提案では、証拠に元の文書世代や依頼の個体を結びつけます。Aの証拠はAの記録として残し、BにはBを裏づける観測を要求します。承認後に依頼を置き換えた場合の鮮度確認に加えて、実行後に戻ってくる証拠の帰属も確かめる、という見直しです。
検証状況
この比較は未実行です。提案上の期待結果は、Aの遅延証拠が届いてもBの完了をUNKNOWNのまま保つこと。Bに対応する証拠が後から届けば、Aの履歴を書き換えずにBへ帰属させます。世代の情報や観測範囲が不足する場合は、不確かさを残します。
既存の相関制御だけの場合とARCを加えた場合へ、同じ記録と信頼できる入力を渡して比べる予定です。既存制御ですでに正しく帰属できる結果も残します。この案によって、新しい認証源や安定APIが追加されたわけではありません。
条件3：結果の読戻しと、もう一度実行する権限を分ける
外部の報告
Issue #69の公開コメントは、投稿APIが404を返した一方、スレッドを読み直すとコメントが存在したという外部の自己報告を扱っています。著者表示の照合は名前の不一致で不明のままだったとされています。報告者の実装を独立して再現した結果ではありません。
見直した条件
設計では、処理開始、相手側の受信、応答、効果の完了、証拠の確定を分けます。エラー応答だけで「何も起きなかった」と決めると、同じ効果を重ねるおそれがあります。証拠を追記して結果を確定する処理そのものに、再実行の許可や使い切った権限の復活を持たせない条件を置きました。
再試行は、現在の承認・対象・入力を確かめ、新しい一回限りの権限付与を受ける別の判断です。元の論理的な操作の識別は保ちます。さらに、未実行だったと判断できる十分な独立証拠、または相手側の照合・重複排除の契約によって安全に繰り返せる条件が必要です。どちらも確かめられなければ再試行を保留します。
検証状況
架空の投稿ストアを使う比較案は未実行です。「効果は1件確認できた」「著者の本人性はUNKNOWN」を別々に記録し、本人性が不明だからという理由で再投稿しないことを期待結果としています。読戻しが欠ける・古い・別対象だった場合も、効果ゼロや完了へ読み替えません。
この設計で目指すのは、一回の権限付与につきローカルの開始を高々一回にすることです。外部へのexactly-once配送を証明するものではありません。人の承認も、前の効果が起きていないことの証拠にはなりません。
残る受入：実行環境での検証と、人にとっての価値
次の実装判断はN0です。協力する実行環境の管理者と、検証できる承認・ポリシーの正本を定め、実行環境・アダプター・設定・主体・実効権限の出所を固定する条件です。N0の実行環境での受入は未達です。 実行環境の正式な受入に、MCP通信だけの試験結果を代用することはできません。
N6も残っています。同じポリシー情報と観測を与えた既存制御との比較に加え、別々の実業務2件で、人の設定・保守・レビュー時間、有用な検出、誤った拒否、継続するか外すかの判断を測る条件は未達です。 人工的に入れた異常を、自然に起きた有用な発見として数えず、台本どおりの再実行を自発的な再利用とも数えません。
公開報告、設計済み、限定実装済み、独立検証済みは、それぞれ必要な証拠が違います。今回の3条件について、独立した実行環境での受入を完了したとは扱いません。対話への参加やレビューの申し出も、採用・推薦の実績に数えません。文書の統合から形式証明や安全保証を導くこともできません。
ARCの追加価値を確かめるには、既存制御だけで十分だったという結果も保存する必要があります。保守の負担が増え、判断が良くならなければ、統合を止める選択も残します。公開議論を続ける理由は、賛同の件数より、この判断に必要な条件と証拠を具体的にするところにあります。
現在の宣言検査と評価の入口は、ARCの製品ページから確認できます。導入を検討する際は、対象の業務で何が足りず、追加した検査がどの判断を改善するのかを、既存制御との比較で確かめてください。