AIエージェントの導入が進む一方で、最も怖いのは『判断は賢いのに、実行権限が強すぎる』状態です。調査用のエージェントがそのまま本番DB更新や外部API実行まで担う設計にすると、誤操作やプロンプトインジェクションがそのまま事故になります。だから重要なのは、モデル性能の比較より先に、どこまで読めて、どこから先は人が止められるかを設計することです。
1. まず分けるべきは『読む役』と『書く役』です
AnthropicのClaude Codeドキュメントでは、read-only permissionsが既定で、bash実行やファイル編集には明示的な承認が必要だと説明されています。さらに書き込みは起動したフォルダ配下に制限されます。ここから学べるのは、AIエージェントも最初は読むだけを標準にし、更新系は別レイヤーに切り分けるべきだということです。要件整理、ログ確認、SQL候補作成までは調査エージェント、本番反映は実行エージェント、という分離が基本になります。
実務では、調査エージェントに与えるのは閲覧権限とドラフト作成権限までに留め、DB更新やGit push、請求処理のような副作用は別のツールか別のサービスアカウントへ渡します。これだけで、誤った判断が即事故に変わる確率を大きく下げられます。『1体の万能エージェント』より『弱い権限の専門家をつなぐ』方が、本番運用では圧倒的に安全です。
2. 危険な操作は承認フローを前提に組みます
OpenAI AgentsのGuardrails and human reviewでは、編集・キャンセル・shell command・sensitive MCP actionのような副作用の前で、runをpauseし、人またはポリシーがapprove/rejectできる設計が示されています。重要なのは、承認を例外処理にしないことです。『たまに確認する』ではなく、『副作用がある操作は必ず止まる』を標準動作にします。
おすすめは、承認単位を小さくすることです。たとえばDB削除の前に、対象テーブル、件数、WHERE条件、ロールバック可否を人が読める1画面にまとめる。まとめて『全部許可』ではなく、更新系だけを別キューに送る。OpenAIのドキュメントが示す interruption と resumable state の考え方を使えば、承認待ちで止めても同じrunを後から再開できます。夜間バッチやオンコール運用でも扱いやすい設計です。
3. 監査ログは『あとで見る』ではなく設計の中心です
事故が起きたあとに必要になるのは、『どの指示で』『どのツールが』『何を実行したか』の追跡です。OpenAI Agents SDKのtracingでは、LLM generation、tool call、handoff、guardrailが記録対象です。Claude CodeのMonitoringでも、OpenTelemetry経由でmetrics、logs、tracesを外部基盤へ送れると案内されています。つまり、主要ベンダーはすでに“エージェントは観測できる前提で運用するもの”として設計しています。
最低限残したいのは、ユーザー入力、使われたツール、承認者、実行時刻、対象リソース、結果、失敗時の差し戻し理由です。さらに本番DBや請求APIの操作には trace_id や request_id を付け、アプリ側の監査ログと突合できるようにすると、原因調査が速くなります。監査ログが弱いと、AIの誤作動そのものより『何が起きたか分からない』ことが最大のリスクになります。
4. すぐ使える実装パターン
導入初期は、①read-onlyエージェント、②承認付きexecutor、③監査ログ収集の3層で始めるのが現実的です。read-onlyエージェントは提案まで、executorは承認済みジョブだけ実行、監査基盤は全イベントを保存する。加えて、削除・課金・公開・外部送信は必ず高リスク操作として分類し、権限を別アカウントに分けると事故半径を抑えられます。モデルの賢さを上げる前に、失敗しても壊れにくい構造を先に作るべきです。
AIエージェントを本番業務に入れるなら、まず権限設計と承認フロー、監査ログから整えるのが近道です。自社に合うガバナンス設計や開発体制を整理したい方は、 お問い合わせください 。