AIエージェント（自律的にツールを呼び出しタスクを実行するAIシステム）を本番導入する際、その品質をどう検証するかは非機能要件の設計課題です。テキストの応答内容だけを見て「良さそうだから合格」と判定する評価方法には、見落とされがちな弱点があります。CI/CDパイプライン（コード変更を自動的にテスト・配備する仕組み）にエージェントの評価を組み込もうとしているエンジニアや、QAプロセスの設計を担当している方に向けて、この弱点と対策を整理します。
あるケースでは、営業パイプラインの評価額を尋ねられたエージェントが、自信満々に整形された数値を返しました。評価スクリプトはPASSと判定しています。ところが実際にはエージェントはデータに一切アクセスせず、数値を推測していました。この事象は、テキストベースの評価（LLM-as-a-judgeと呼ばれる、別のLLMが応答文を採点する手法を含む）が抱える構造的な問題を示しています。
なぜテキスト評価だけでは足りないのか
従来のチャットボット評価は「応答の文章が適切か」を判定すれば十分でした。会話が完結した時点でタスクも完了しているからです。
しかし現代のエージェントはツール呼び出し（外部APIやデータベース操作を実行する機能）を通じてシステムの状態を変更します。在庫を動かしたり、レコードを更新したり、外部システムに副作用を及ぼしたりします。
ここで問題になるのは、応答の文章と実際の処理結果が一致するとは限らない点です。パイプラインの美しい要約文を書きながら、案件のステージ更新を一件も実行していないエージェントは、テキスト評価では検出できません。障害は本番環境で初めて発覚することになります。
エージェント検証は大きく3段階に分けて考えられます。
- ユニットテスト: コードが仕様通り動くか
- プロンプト評価: 応答の文章が妥当に見えるか
- 状態検証: エージェントの行動によって世界（システムの状態）が正しく変化したか
最初の2段階は多くの開発現場で既に実施されています。抜け落ちやすいのが3段階目、つまり「実際に何をしたか」を検証する仕組みです。
状態検証の仕組み：Siloの設計を分解する
この3段階目に特化したオープンソースツールがSilo（MITライセンス、TypeScript製、ローカル完結型）です。npmパッケージとして配布されており、@burn0/siloという名前で提供されています。
Siloの設計思想は「エージェントに世界の状態を直接見せない」という点にあります。エージェントに渡されるのはタスクの指示文、ツールのスキーマ定義、そしてツール呼び出しの結果（複製されたデータ）のみです。何かを知りたければ必ずツールを呼ぶ必要があり、これは本番環境の制約と同じ構造です。
採点も同じ原則の逆方向で行われます。タスクが合格するのは「世界の状態が正しく変化したから」であり、「エージェントが正しい言葉を使ったから」ではありません。冒頭の推測エージェントの例をSiloで実行すると、ツール呼び出しゼロ・チェック未達で明確に失敗判定になります。自信のある文体には一切加点されません。
この検証を成立させている設計ルールが2つあります。
1つ目は時刻のシミュレーション化です。state.nowのみが時計として扱われ、Date.now()は一切参照されません。これにより火曜日に実行したテストが金曜日でも同一の結果を再現できます。これはテストの再現性（同じ条件なら同じ結果が得られる性質）を担保する基本設計です。
2つ目は実行記録の完全性です。各実行はtrace.jsonl（全イベントの追記専用ログ）、result.json（チェック結果・報酬値・ツールエラー）、state-diff.json（状態変化の差分）、run.json（タスク・検証器・実行時間）という4種類のファイルを残します。特にresult.jsonとstate-diff.jsonにはタイムスタンプや実行IDが含まれないため、2回の実行結果を比較すれば差分は純粋な挙動変化だと判断できます。これは回帰テスト（変更によって既存機能が壊れていないか確認するテスト）のオラクル（正解判定の基準）として機能します。
導入判断のための比較軸
既存のエージェント評価手法と比較すると、Siloが埋めている領域が見えてきます。
| 手法 | 検証対象 | 非決定性への対応 |
|---|---|---|
| LLM-as-a-judge | 応答文の品質 | 判定自体が確率的でブレる |
| E2Eテスト（本番類似環境） | 実際の副作用 | 外部依存が多く再現性が低い |
| Silo（シミュレーション環境） | 状態変化と決定的な合否 | --runsオプションで分布を可視化 |
エージェントの出力が実行のたびに変わる非決定性の問題には、--runs 5のように複数回実行するオプションで対応します。1回のたまたま成功したログをスクリーンショットに撮って安心する代わりに、実際の成功率の分布を確認できます。これはSREの領域で言うところの「たまたま動いた」を排除するアプローチに近いものです。
今日確認できること
導入を検討する場合、まず環境要件を確認してください。Node.js 22以上と、package.jsonに"type": "module"の指定が必要です。
セットアップは次の手順で試せます。
npm i @burn0/silo
npx @burn0/silo init demo --template crm
npx @burn0/silo env validate --env demoCRMテンプレートを使うと、9個のデータコレクション・6個のタスク・42個のツール・6個の検証器から成る、小規模で把握しやすいB2B営業パイプラインのシミュレーション環境がローカルに構築されます。もう一つ用意されているERPテンプレートは185個のツールと意図的に汚したシードデータ（受領額を超える請求書、古い銀行情報での失敗した支払いなど）を含む、より複雑な検証向けです。
自作のエージェントを検証する際は、デフォルトエクスポートされた関数であれば任意のフレームワークで動作します。
npx @burn0/silo run --env demo --task TASK-004 --agent ./silo.agent.js実行後は.silo/runs/配下に保存されるログを確認し、result.jsonのチェック項目・報酬値・ツール呼び出し回数を見ることで、応答文ではなく実際の挙動を検証できます。
導入前に確認すべき点として、v0.4.0時点では開発初期段階にあり、破壊的変更が今後発生する可能性がメンテナーから明言されています。本番のCI/CDパイプラインに組み込む場合は、バージョン固定とアップグレード時の回帰確認を運用ルールに含めておく判断が必要です。
まとめ
AIエージェントを本番システムに組み込む際、テキスト応答だけを評価対象にすると、実際の副作用の欠落や誤動作を見逃すリスクが残ります。
状態検証という第3の評価レイヤーを、既存のユニットテスト・プロンプト評価に追加する形で検討する価値があります。まずはnpx @burn0/silo init demo --template crmでローカル環境を作り、既存エージェントを1タスクだけ流してみるところから始められます。
導入を判断する際は、検証対象システムの副作用の重大度（在庫操作や決済処理など取り返しのつかない操作を含むか）と、v0.4.0という早期バージョンであることのリスクを天秤にかけて決める視点が欠かせません。