「検査にPASSした」は「安全に運用できる」ではない｜Agent Role Contractsの実例から営業表現をつくる

AIエージェントの検証結果を提案書に入れるとき、短く魅力的に書こうとすると危険な省略が起こります。例えば「権限の逸脱を防ぎます」。その一文が、実行前に宣言された権限とタスクの矛盾を検出したという結果から導かれたものなら、実行時の強制まで保証したように読まれかねません。

この境界はNetsujoの公開OSS Agent Role Contractsで具体的に確かめられます。以下は公開ソース、テストコード、過去のCIログに基づく表現の組み立て例であり、実在の顧客向け資料に誤った主張を書いたという逸話ではありません。

まず実際の検査対象を一つに絞る

2026年10月15日のソース・スナップショット `966e3c2`には、スターターのデモ実装と二つのタスク入力があります。役割の宣言では、実装担当が書き込める範囲をsrc/**、レビュー担当をread-onlyとしています。

デモの公開READMEにはPASS → FAIL (expected) → PASSという期待される表示が載っています。今回は実機で最新版のコマンドを再実行していないため、上の表を今回の新規実測と呼びません。一方、2026年9月30日の公開CIには、当時のコミットでスターターの範囲外タスクを拒否するテストが成功し、Ubuntu/Node 24の対象ジョブでは198件成功・失敗0件だったログがあります。このCIは2026年10月15日のソース全体の再検証結果ではありません。

ここまで区別して初めて、「確認した」の主語と範囲が決まります。

なぜ宣言検査を選び、それでも安全保証にしないのか

AIへ「src以外を編集しないで」と自然言語で頼むだけでは、次に渡されたタスクがルールと矛盾していることを機械的な診断コードとして残せません。Agent Role Contractsは、実行前の宣言をデータとして照合し、その矛盾を検出できるようにする選択です。

ただし、デモは実ファイルを開かず、エージェントも起動しません。Quick Startの注意書きも、実行許可、本人認証、ファイルシステムの書込強制を別責任としています。役割名が別でも、独立した人物や実行主体がレビューした証明にはなりません。

もし顧客が知りたいのが「本番環境で機密ファイルが書き換えられないこと」なら、宣言検査のPASSは必要な証拠の一部分にすぎません。実行時に書込を拒否する仕組み、そのログ、本人認証、異常時の停止、レビューの独立性を追加で検証する必要があります。

提案書の一文をどう直すか

これは編集用の仮想Before/Afterで、過去に提出した営業資料の引用ではありません。

営業資料に全ログを貼る必要はありません。本文にはこの限定表現を置き、裏付けとしてソースの固定コミット、入力JSON、検査コード、実行日時付きのログへリンクします。その版で実行したログがなければ、ソースの期待値と実測を混ぜないことが条件です。

次のPoCを、宣伝文句ではなく受入条件から設計する

顧客が求めるのが実行時の保護なら、次のPoCでは「対象のエージェント」「試す禁止操作」「誰の権限で実行するか」「OS/実行基盤が実際に拒否した記録」「レビューと終了の証拠」を受入条件として先に合意します。期待する結果が出なかった場合も、その失敗を残します。

この公開例から得られる教訓は、成功を小さく言い換えることではありません。検査が答えた問いを正確に示せば、次に何を試すべきかが分かることです。

「PASS」が示す範囲を整理した既存記事は検査の意味をより詳しく扱っています。こちらの記事は、技術結果をBtoBの提案表現とPoCの受入条件へ移すときの判断に絞りました。技術検証の設計相談はお問い合わせから受け付けています。