9月16日、Microsoftが「Your AI coding agent evaluation is only as good as its sandbox」と題した記事を公開した。AIコーディングエージェントの評価スコアがサンドボックスの設計次第で無意味になりうるという実践的な落とし穴と、その対処法について詳しく紹介されている。
なぜ今、エージェント評価の信頼性が問われるのか
AIエージェントの実用化が加速するなか、「どのベンチマークでスコアが高いか」を購入・採用判断の根拠にする動きが広がっている。しかし評価スコアの前提条件、とりわけテスト環境（サンドボックス）の設計が精度に直結するという認識は、まだ業界に十分浸透していない。SWE-benchをはじめとするコーディングエージェント向けベンチマークの普及とともに、「スコアが高い＝実力がある」という短絡的な解釈へのリスクも高まっている。本記事はその盲点を、Microsoftの実験を通じて具体的に示している。
「正しい答え」が評価を無効にする
AIコーディングエージェントの評価で「合格」が出ても、それが何を証明しているかは別の問題だ。エージェントは質問に答える際、モデルの内部知識を使う場合もあれば、プロンプトや実行環境から情報を拾い上げる場合もある。最終的な答えが正しくても、どの経路で得たかによって、その評価の意味はまったく変わる。
記事の著者はこの問題を、Vallyを使ってモデルの知識を検証する実験で体験した。VallyはMicrosoftが開発したAIエージェント向けの評価フレームワークで、タスク定義・実行・スコアリングを一元管理できる。検証対象はDev Proxy（APIモックや開発支援を行うMicrosoftのツール）の各バージョンに関するモデルの事前知識だ。モデルが「知識カットオフ」と自己申告している時期と実際の知識を比較したかったが、エージェントがネット検索できる状態では比較自体が成立しない。
そこでWebツールとcurlによるネットワークアクセスをブロックした。一見、情報の境界は閉じられたように見えた。
サンドボックスの穴：ファイルシステムが全部しゃべる
結果は予想外だった。エージェントは最新バージョンのDev Proxyに関する詳細な質問も次々と「合格」した。合格率だけ見れば「モデルはDev Proxyの最新動作を理解しており、知識カットオフを超えて推論できる」という好ましい結論が引き出せてしまう。
しかしエージェントの行動ログ（トラジェクトリ）を確認すると、まったく異なる経路が記録されていた。
最初にcommand -v devproxyがブロックされると、エージェントは次を試した：
which devproxy
この呼び出しは許可されており、実行ファイルのパスとともにソースコードのチェックアウト先ディレクトリが露出した。エージェントはそのパスに対してrg（ripgrep）を実行し、リポジトリ内のv0.29.2タグを直接検査。実装の詳細を読み取って正確な回答を生成した。
これは「Dev Proxyの動作に関する優れた調査型の回答」だが、「モデルが事前に持っていた知識」の証拠ではまったくない。Webアクセスを1つ塞いでも、ローカルのファイルシステムと開発ツールが別の経路として機能していた。
この一連の挙動が示すのは、エージェントはブロックされたツール呼び出しを障害として扱い、残った能力で同じ情報に到達しようとするという点だ。個別のdenyルールで構成したサンドボックスは、常にその探索力に遅れをとる。
情報の境界を基準にサンドボックスを設計する
ツールの制限リストを増やしていくアプローチには限界がある。ツールは情報へのルートに過ぎないからだ。記事が提示する考え方はシンプルだ：「エージェントが持つすべての能力を通じて、どんな情報を得られるか？」を基準に境界を定める。
具体的な方針として記事が挙げているのは以下だ：
- ファイルシステムへのアクセスをワークスペース境界で統一的に制限する（個別コマンドごとのルールではなく）
- ホストマシンから製品インストールや無関係なソースコードを取り除く
- パスやインストール済みソフトウェアが露出する環境変数を最小化する
- シェルコマンドと接続ツールに同じ制限を適用する
境界の内容は測定目的によって変わる。リポジトリレベルのコーディング能力を測るなら、ワークスペース内のソースを読むことは正当だ。しかしそのソースが「答え」を含んでいるなら、知識評価としては汚染源になる。禁止ツールの普遍的なリストは存在しない。何が正当かは問いの内容に依存する。
トラジェクトリのレビューを評価の一部にする
合格スコアだけを見ることの危うさは、最終的な答えがモデルの内部知識から来たのか環境からの検索で来たのかを区別できない点にある。記事は以下のチェックリストを推奨している：
- 測定したい能力とエージェントが使ってよい情報を最初に定義する
- 意図したフィクスチャ（テスト用データ）だけを含むクリーンなワークスペースから各ランを開始する
- 評価内容に関連する単語が漏れないよう、中立的なワークスペースパスを使う
- 内部知識を測る場合は外部知識ソースを制限する
- ファイルシステムアクセスをワークスペース境界で統一的に適用する
- すべての利用可能なツールに同等の制限を適用する
- 予想外の合格とその背後にあるトラジェクトリを精査する
- エージェントが発見した各ルートに回帰プローブを追加して再評価を実行する
特に「モデルの知識カットオフ近傍での予想外の合格」は要注意だ。環境からの検索がそれをもっともらしく見せている可能性がある。合格を証拠として扱う前に、仮説として調査すべきだ。
サンドボックスがベンチマークの有効性を決める。 スコアが信頼できるのは、エージェントがどのようにしてその答えに到達したかを説明できる場合だけだ。そうでなければ、スコアが示しているのはモデルの能力ではなく、評価者のマシン環境かもしれない。
詳細はYour AI coding agent evaluation is only as good as its sandboxを参照していただきたい。
