AIエージェントを本番業務に入れるとき、最初に設計すべきなのはモデル選定より権限境界です。2026年時点では、OpenAI Agents SDKのhuman-in-the-loop、ChatGPT Workspace Agentsの書き込み承認、Claude Codeの権限設定やAuto modeのように、主要な実行環境が『ツール実行を止めて確認し、状態を保存して再開する』前提へ寄っています。つまり、エージェントは自由に動かすものではなく、読める範囲、書ける範囲、人が止める範囲を最初から分けて運用するものです。
1. まず分けるべきは『読む役』と『書く役』です
安全な構成では、調査・要約・候補作成を行うread-only agentと、DB更新・外部送信・課金・公開を実行するexecutorを分けます。read-only側には検索、ログ閲覧、ナレッジ参照だけを許可し、executor側は承認済みジョブだけを処理します。この分離がないと、プロンプトインジェクションで『確認しただけ』のつもりが本番データ変更まで進む事故が起きます。
権限はユーザー単位だけでなく、ツール単位、環境単位、データ分類単位で切るのが現実的です。たとえば本番DBはSELECTのみ、ステージングはUPDATE可、メール送信は下書きまで、公開APIはdry-run必須、というように、行動ごとの許可を細かくします。サービスアカウントも共用せず、エージェント用の低権限アカウントを発行し、監査ログで人間の操作と区別できるようにします。
2. 危険な操作は承認フローを前提に組みます
OpenAI Agents SDKのhuman-in-the-loopでは、承認が必要なtool callで実行を中断し、承認または却下したあとに同じ状態から再開する設計が示されています。重要なのは、承認を『気が向いたときの確認』にしないことです。削除、送信、公開、課金、権限変更、本番DB更新、個人情報の外部転送は、例外なく承認キューへ送るルールにします。
承認画面では、エージェントの説明文よりも実行差分を優先します。SQLなら対象テーブル、WHERE条件、想定件数、変更前後のサンプル、ロールバック方法を表示します。メールなら宛先、件名、本文差分、添付、送信元を見せます。『なぜ必要か』より『何が変わるか』を読めるようにすると、承認疲れを減らし、誤承認も減らせます。
3. 監査ログは『あとで見る』ではなく設計の中心です
監査ログには、ユーザー入力、モデル出力、選択されたツール、実行パラメータ、承認者、承認時刻、実行結果、失敗理由、trace_idを残します。OpenAI Agentsのtracingや、Claude CodeのOpenTelemetry連携のように、エージェント運用は生成、tool call、handoff、guardrailを観測する方向へ進んでいます。アプリ側の監査ログと突合できるIDを付けることが、障害調査と内部統制の要になります。
ログは『全部保存する』だけでは足りません。検索できる構造、保持期間、改ざん耐性、個人情報のマスキング、緊急時の閲覧権限まで決めておきます。特に外部送信やDB更新は、承認記録と実行ログが一対一で結び付く必要があります。事故時に“AIがやったらしい”で止まる組織は、原因を切り分けられず再発防止もできません。
4. すぐ使える実装パターン
最小構成は、read-only agent、approval queue、executor、audit storeの4点です。read-only agentは提案まで、approval queueは高リスク操作を保留、executorは承認済みpayloadだけを実行、audit storeは全イベントを保存します。さらにdry-run、差分表示、ロールバック手順、権限別サービスアカウントを足すと、小さなチームでも本番導入しやすくなります。
運用初期は、すべての書き込みを人間承認にしてログを集め、数週間後に『常に承認される低リスク操作』だけ自動化するのがおすすめです。逆に、削除、支払い、公開、外部送信、権限昇格は最後まで高リスク扱いにします。モデルが賢くなるほど、実行権限の設計が甘いシステムは危険になります。
AIエージェントを本番業務に入れるなら、権限分離、承認フロー、監査ログを先に整えるのが近道です。自社に合うガバナンス設計や開発体制を整理したい方は、 お問い合わせください 。
