AIエージェントの作業範囲チェックとコード検査は何を止めるのか｜ARC×ShipRules-free 4ケース比較

AIエージェントがソースコードを変更する現場では、「許されたファイルを対象にしているか」と「変更したコードが正しいか」の二つを確認する必要があります。同じテスト結果でも、片方の問いにしか答えていないことがあります。

Netsujoが公開するAgent Role Contracts（ARC）は、実行前に宣言されたロールと作業範囲を検査します。一方、ShipRules-freeの公開スキャナーは、Godot 4のプロジェクトに残る一部のGodot 3構文を検出します。両者が違う問題を扱うなら、片方だけがFAILを返して作業を止める状況を実際に作れるはずです。本稿の「止める」は、検査がFAILを返すことを指します。実行時の書き込みを遮断する仕組みの話ではありません。

Netsujoは2026年10月26日、この問いを四つの公開fixtureで比較しました。これはメンテナーによる再現可能な合成比較です。外部企業の本番運用で安全性が上がったことを示す調査ではありません。

4ケースを同じ条件で比べる

比較にはARC v1.0.0の固定commit 9f6771056c47de971202360952af6d41941f7625と、ShipRules-freeの固定commit 8b8302e9551fb8784d7cbe7fa61eeecf127bf247を使いました。入力は公開fixtureに含まれています。

単純な成功例を一つ実行するだけでは、二つのツールともPASSを返して終わります。それでは「片方だけを導入すると何が見落とされるか」に答えられません。そこで、正常なGodot 4のファイルと許可範囲内のタスク宣言を基準に置き、変える条件を一つずつに絞りました。

②ではARCがTASK_WRITE_SCOPE_OUTSIDE_AUTHORITYを報告しました。変えたのはタスクが宣言する書き込み先だけです。実ファイルへの不正な書き込みが起き、それをARCが防いだという観測ではありません。「要求された範囲の宣言が適合しない」ことを検出した記録です。この表のスキャナー列は、①の実行結果（No Godot 3 syntax found.）をそのまま再利用しています。②のためにスキャナーを別途実行してはいません。

③では、対象が許可範囲内のためARCはPASSです。スキャナーはplayer.gdの3行目のexport var speed = 120と、6行目のyield(get_tree().create_timer(0.1), "timeout")を検出し、exit 1でFAILを返しました。確認すべきは「どちらのFAILが正しいか」ではなく、それぞれがどの入力と契約を検査したかです。

なお、ARCのPASSは実行権限を与えません。結果JSONでも、全ケースでexecution_authorized: false、runtime_enforcement: falseと記録されています。

実行結果と、まだ答えられない問い

2026年10月26日の実行記録はLinux/x64・Node.js v24.22.1で取得したものです。四つの期待結果は4/4一致し、比較プロセスの終了コードは0でした。ソースのPR #76は、四つのホスト型CIジョブの成功と、メンテナーが手配した読み取り専用の自動ソースレビュー（AIレビュアー）のPASSを経てマージされました。

自動実行時間は約421.8ミリ秒、ケースごとのスキャナー所要時間は約29〜33ミリ秒でした。いずれもこの端末とfixtureでの観測値です。人が環境を準備した時間ではなく、一般的な性能比較にも使えません。

確認できたのは、公開fixtureとメンテナーの実行・検証範囲です。ShipRulesの有料版フック、CIの非公開部分、ARCによる実ランタイム権限の強制、実行者の本人認証、本番での実行権限、顧客での導入成功は比較していません。Issue #75には、ShipRules側の担当者が四つのケースの分け方を有用と受け止め、内容を確認する意向を示した記録があります。ただし2026年11月2日時点で、相手による追試・採用判断は完了していません。外部の実利用として加算できる件数は0です。

このため、次の問いには今回の比較から答えられません。

• 本番のAIエージェントが別ファイルを書き込もうとした際、ARCが阻止するのか。実際の権限強制には実行基盤のIAMやサンドボックスが必要で、ARCの宣言検査はその代わりになりません。
• 既存のアクセス制御やCIより、新しい失敗をどれだけ見つけるのか。
• 担当者のレビュー時間が実際に短縮され、導入の手間に見合うのか。

PASSの数だけから運用の費用対効果を見積もることはできません。

導入判断には、自社で使っている検査を先に並べる

チームに既にCIや権限管理があるなら、ARCを加える前に「どの検査を、いつ、誰が受け取るか」を表にすることを勧めます。今回の二つの検査については、次のように考えられます。

• 実行前：ロール・タスク・要求範囲の宣言が整合しているか。
• コード検査：変更されたファイルに特定の構文上の不適合がないか。
• 実行境界：許可された主体が実際にその操作を行えるか。これはIAM、サンドボックス、実行基盤などの責任です。
• 実行後：本当にその範囲だけが変わり、必要なテストと独立レビューを通ったか。実際のdiffやCI等の証拠が必要です。

どれか一つの検査がすべてを担うと誤解すると、検査の外側にある失敗が見えなくなります。一方、既存の仕組みが同じ矛盾を既に十分に検査しているなら、ARCを増やしても追加価値は小さいかもしれません。

判断材料を集めるなら、実運用のタスクを一つ選び、既存の検査だけでも同じ問題を検出できるかを並べてください。そのうえで、導入準備の人手、誤拒否、レビューのやり直し、二つ目の実タスクで同じ宣言を再利用できたかを記録します。ARCを残す理由が見つからなければ導入しない、という結論も正当です。

自分の環境で再現する

実験READMEでは、ARCとShipRules-freeのcommitを固定しています。コードが更新されると、同じコマンドを実行したつもりでも検査結果が変わり得るためです。ShipRulesの公開スキャナーのSHA-256 58b650402c321d69cdeddc3b71abcb55ad882585a9bdad00929b1f545c61b8d7も記録されています。実行スクリプトは、誤ったcommit、変更された追跡対象ファイル、スキャナーのハッシュ不一致を拒否します。

本番リポジトリではなく、別々のチェックアウトで試してください。

git clone https://github.com/suirindo/agent-role-contracts.git arc-kit
git clone --branch v1.0.0 --depth 1 https://github.com/suirindo/agent-role-contracts.git arc-v1
git clone https://github.com/otctrading101/shiprules-free.git shiprules-free
git -C shiprules-free checkout 8b8302e9551fb8784d7cbe7fa61eeecf127bf247
node arc-kit/experiments/external-evaluation/shiprules-free/run-comparison.mjs \
  --arc-v1 arc-v1 --shiprules shiprules-free

必要な環境はGit、Bash、Node.js 22.5以上です。紹介した実測はメンテナーが取得したLinux/x64の記録で、読者の環境での成功を保証するものではありません。

追試と結果の共有先

再現できた場合も、うまくいかなかった場合も、結果はARC Issue #75に残してください。実行環境、固定したcommit、既存CIとの差、導入の手間、誤拒否を併記いただくと、次の評価に使えます。

関連記事： ARCのPASSが保証すること・しないことは単体チェッカーの範囲を扱います。本稿は、別種類の検査を同一条件で比較した実験に限定しました。