本番環境への導入前にAIエージェントのプレイグラウンドを構築する
あるコーディングエージェントが、ステージングデータベースだと思い込んでクリーンアップスクリプトを実行したことがありました。しかし、それは実際には本番環境でした。そのエージェントは、誤った認証情報に対して指示通りに実行した結果、4ヶ月分の顧客注文データを削除してしまいました。
この失敗は、エージェントを避けるべき理由ではありません。プレイグラウンドを構築すべき理由なのです。
新人のエンジニアに、入社初日から本番データベースへのアクセス権を与えることはないでしょう。代わりに、ステージング環境、読み取り専用のアクセス権、そして監督下でのタスクを与えます。エージェントにも同じオンボーディングが必要です。エージェントは1分間に1,000ものアクションを実行できるため、プレイグラウンドをスキップすることの代償は1,000倍高くなります。
本物のプレイグラウンドは、次の3つのことを行う必要があります。
- エージェントに完全な意思決定ループを実行させる。
- すべての副作用が実際のシステムに及ぶのを防ぐ。
- 検証のためにすべてを記録する。
プロンプトだけをテストしてはいけません。プロンプトのテストとは、質問をして回答を読むことです。エージェントの振る舞いは、一連のツール呼び出し（tool calls）です。本当の失敗は、ツールが予期しないデータを返したとき、ループの途中で発生します。
モデルをサンドボックス化する必要はありません。エグゼキューター（実行環境）をサンドボックス化する必要があるのです。
ツール呼び出しがアクションに変わる場所に「継ぎ目（seam）」を設けてください。ライブエグゼキューターの代わりに、モックを使用するプレイグラウンド・エグゼキューターを使用します。エージェントのループ側はその違いを知る必要はありません。もしエージェントがデータベースクライアントを直接呼び出しているなら、継ぎ目も安全性も存在しないことになります。
次の3つの特定の領域をテストしてください。
- 振る舞い：エージェントは正しい順序で正しいツールを選択しているか？
- ツール呼び出し：引数は正しく、安全な範囲内か？
- 失敗モード：APIがタイムアウトしたり、不正なデータを返したりしたときに何が起こるか？
常に成功するモックでは、エージェントは何も学べません。プレイグラウンドでは、ネットワークのタイムアウトや不正な形式のデータなど、意図的に失敗を注入（inject）できるようにする必要があります。そうすることで、エージェントが賢明にリトライするか、あるいはハルシネーション（幻覚）を起こし始めるかを確認できるのです。
エージェントがコードを実行する場合は、強力な分離が必要です。信頼できないコードにはmicroVMを使用してください。単に簡単だからという理由で、単純なコンテナから始めてはいけません。安易なセットアップは、大規模なセキュリティインシデントにつながる可能性があります。
エージェントは非決定論的（non-deterministic）であることを忘れないでください。一度パスしたテストが、エージェントの信頼性を保証するわけではありません。同じタスクを何度も実行する必要があります。もしエージェントが10回中7回成功する場合、実際のユーザーの約30%に対して失敗することになります。一貫性（Consistency）こそが、最も重要な指標です。
最後に、敵対的なツール出力（adversarial tool outputs）から保護してください。エージェントはツールのデータを「指示」として扱います。悪意のあるユーザーがプロンプトインジェクションを用いてデータベースにデータを仕込み、エージェントを誘導する可能性があります。プレイグラウンドで敵対的なペイロードを投入し、エージェントをテストしてください。
「起動ボタン」ではなく、「卒業へのパス」を構築してください。
- モックと完全なサンドボックス化から始める。
- 多数の実行にわたって一貫性をテストする。
- 敵対的な入力に対してテストする。
- 本番環境を模したデータを用いたドライランモードへ移行する。
- その段階になって初めて、範囲が限定され、ゲート管理され、監視されたアクセス権を付与する。
エージェントに、安価に失敗できる場所を与えてください。そうすれば、重要な場面で正しく振る舞えるようになります。
Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh
Optional learning community: https://t.me/GyaanSetuAi