見える自動化で暴走を防ぐエージェント監督術
AIエージェントに作業を任せるのは便利だが、「勝手にファイルを消した」「意図しないAPIを叩いた」という事故が怖い。結論から言うと、暴走を防ぐ最短ルートは「権限を絞る」ことではなく、実行の可視化と停止手段をセットで用意することだ。
権限を最小化するのはもちろん大事だが、それだけでは「何が起きているか分からないまま、許可された範囲で想定外の動作をする」という事態は防げない。まずは何をしているか見えるようにして、危なければ止められる状態を作る。この「見える自動化」の考え方と具体的な実装パターンを整理した。
なぜ「見える」が先なのか
OWASPはLLMエージェントの主要リスクとして「過剰な自律性（Excessive Agency）」を挙げている。必要以上の機能・権限・自律性を与えると、何か問題が起きたときの被害範囲が広がるという整理だ。
これに対する一般的な対策は「最小権限」だが、実務では難しい場面も多い。たとえばコード生成エージェントにファイル書き込み権限を与えないわけにはいかないし、データ分析エージェントにはDBへのアクセスが必要だ。権限を絞りすぎると、そもそもエージェントを使う意味がなくなる。
だから「何をやっているか見えるようにして、まずければ止める」というアプローチが現実的になる。
監督の4ステップ
見える自動化を実装するパターンは、以下の4段階で考えると整理しやすい。
1. トレースで因果を追えるようにする
最初にやるべきは、エージェントの実行ログを取ること。入力→判断→ツール実行→出力という流れが後から追えれば、何か問題が起きたときに原因を特定できる。
LangChainのドキュメントでは、本番環境での監視・評価の前提として「トレース」の重要性が強調されている。エージェントがどのツールを、どんな引数で呼んだのか。その結果を受けて次に何を判断したのか。この因果関係が見えないと、改善のしようがない。
ログの粒度はプロジェクトによるが、最低でも「どのツールを呼んだか」「何を入力して何が返ってきたか」は記録しておきたい。
2. ガードレールで入口・出口を守る
OpenAI Agents SDKには「Guardrails」という仕組みがある。入力（ユーザーからのリクエスト）と出力（エージェントの最終回答）それぞれにチェック処理を挟み、条件に引っかかったら実行を止める。
具体的には、ガードレール関数がtripwireTriggered: trueを返すと、InputGuardrailTripwireTriggeredなどの例外が発生して処理が停止する。「このワードが含まれていたら止める」「この形式の出力はブロック」といったルールを事前に設定しておける。
面白いのは、軽量なモデルで先にチェックして、問題なければ本番のモデルに渡すという使い方ができる点だ。高コストな推論を走らせる前にフィルタリングできるので、コスト削減にもなる。
3. 危険な操作は承認フローを挟む
ガードレールは自動で止めるが、「条件次第ではOKにしたい」ケースもある。そこで使えるのがHuman-in-the-loopだ。
OpenAI Agents SDKでは、ツールにneedsApproval: trueを設定すると、そのツールを呼び出す前に実行が一時停止する。人間が内容を確認して承認すれば再開、拒否すれば停止という流れになる。
全部のツールに承認を求めるとエージェントを使う意味がなくなるので、「ファイル削除」「本番環境へのデプロイ」「外部APIへの書き込み」など、取り消しが難しい操作だけに絞るのがコツだ。判定関数を渡せば「金額が○円以上なら承認必須」といった条件分岐もできる。
4. 評価で継続的に改善する
ここまでの仕組みで「止められる自動化」はできた。あとは運用しながら改善していくフェーズになる。
LLMを使った自動評価（LLM-as-judge）は大量のトレースを捌けるが、万能ではない。LangChainのドキュメントでは、以下の制約が挙げられている。
- 遅延: 評価自体に数秒かかる場合がある
- コスト: 全件評価すると費用がかさむ
- 精度: アプリ固有の「良さ」を正しく判定できるとは限らない
- ドリフト: 評価基準自体がズレていく可能性
対策として推奨されているのは「自動評価＋定期的な人手レビュー」の併用だ。コスト面では、全件ではなくトラフィックの10〜20%をサンプリングして評価するのが現実的な目安として示されている。
向いているケース・向いていないケース
この監督術が特に効果を発揮するのは、以下のような状況だ。
- エージェントに外部リソース（ファイル、DB、API）へのアクセス権を与えている
- 一度の実行で複数のツールを連続で呼ぶワークフローがある
- 本番環境や顧客データを扱う可能性がある
逆に、単発のテキスト生成だけで完結するような使い方なら、ここまでの仕組みは大げさだ。入力と出力だけ見ていれば十分で、途中のツール実行を監視する必要がない。
また、リアルタイム性が求められる用途では、承認フローがボトルネックになる。チャットボットで毎回人間の承認を待つわけにはいかないので、そういう場合はガードレールによる自動ブロックをメインにして、承認フローは使わない設計になる。
セキュリティ・コンプライアンスは別途確認を
ここまで書いた内容は技術的な仕組みの話だ。実際に導入する際は、自社のセキュリティポリシーや法務・コンプライアンスの観点からの確認が必要になる。OWASPの整理は参考になるが、最終的な判断は組織ごとに異なる。特に顧客データや決済に関わる処理をエージェントに任せる場合は、担当部署と相談してから進めてほしい。
エージェントの便利さと安全性は、トレードオフではなく両立できる。見えるようにして、止められるようにする。このシンプルな原則を押さえておけば、「便利だけど怖い」から「便利で、何かあっても対処できる」に変わる。