AIコーディングエージェントを本番環境の運用に組み込み始めたインフラ担当者、SREに向けた内容です。OpenAIのCodex（コード生成・修正を自動で行うAIエージェント製品）は2024年5月29日の更新で、Windows上の「computer use（画面を見てクリックやキー入力を行う機能）」に対応しました。エージェントがIDE（統合開発環境）の外に出て、ブラウザやターミナル、アプリのGUIまで直接操作できるようになった点が、運用監視の観点では新しいリスクになります。
これまでのAIコーディングツールは、コードを生成してdiff（差分）を返すだけの存在でした。実行はエンジニアが手元で行い、変な挙動があれば人間がすぐ気づいて止められます。ところがcomputer use対応のエージェントは、アプリを起動し、ボタンを押し、ターミナルでコマンドを叩き、結果を見て次の操作を決める、という一連の動作を自律的に繰り返します。この「操作の連鎖」が監視の設計を変える必要がある理由です。
何が起きるか
エージェントが「observe（観察）→ diagnose（診断）→ change（変更）→ verify（検証）」のループを自律的に回すようになると、1回の指示から発生するアクション数が桁違いに増えます。従来はエンジニアが1コマンドずつ叩いていた作業が、エージェント任せだと数十〜数百の操作が連続で走ります。
影響が出やすいのは次のような場面です。
- ローカルの検証環境で動かしていたはずが、環境変数や接続先の設定ミスでステージングや本番のリソースに触れてしまう
- 診断のために叩いたシェルコマンドが、意図せずファイルを削除したりプロセスを再起動したりする
- リモート操作（別端末からエージェントの作業を監督する機能）中に、監督者が離席している間に想定外の操作が連続実行される
- ログイン済みのブラウザセッションを使って、テスト目的のはずが実データを含む画面を操作してしまう
これらはコード品質の問題ではなく、実行環境と権限設計の問題です。従来のコードレビューやCIのテストゲートでは検知できません。
なぜ起きるか
原因を分解すると、3つの層に分けられます。
1つ目は権限のスコープが広すぎることです。エージェントがcomputer useでOS操作を行う場合、そのホストマシン上でエージェントが持つ権限は、基本的にログインユーザーと同等になります。開発用の踏み台サーバーで動かしているつもりでも、そのユーザーが本番DBの接続情報やクラウドのCLIクレデンシャルにアクセスできる状態なら、エージェントも同じものにアクセスできてしまいます。
2つ目は監督のタイミングがずれることです。リモート操作により、エージェントは人間が画面を見ていない間も作業を継続できます。これは「supervisory cadence（監督型の作業リズム）」と呼ばれる新しい働き方で、生産性は上がりますが、判断が必要な分岐点で人間が不在だと、エージェントは自分の判断で次のステップに進みます。承認フローが弱いと、ここで想定外の操作が実行されます。
3つ目は可観測性の設計が追いついていないことです。従来の監視は「アプリケーションのメトリクス」「サーバーのリソース」「デプロイのログ」を見る設計です。しかしエージェントが起こす障害は「なぜこのコマンドが実行されたか」という操作の意図と文脈に起因します。通常のAPMツール（アプリケーション性能監視ツール）やインフラメトリクスだけでは、この文脈を追えません。
自分のプロジェクトが該当するか確認する方法
まず、開発環境でAIコーディングエージェントにシェル実行権限やブラウザ操作権限を与えているかを確認します。
# エージェントを実行しているユーザーの権限範囲を確認
whoami
id
sudo -l
# クラウドCLIの認証情報がホスト上に残っていないか確認
aws configure list
gcloud auth list
kubectl config view --minifyこれらのコマンドで本番環境のクレデンシャルやkubeconfig（Kubernetesクラスタへの接続設定）が同じホスト上に見えるなら、エージェントの操作範囲がそこまで及ぶ可能性があります。
次に、エージェントの実行ログが残る設定になっているかを確認します。CodexやCursorなど各種エージェントツールには、実行したコマンドやクリック操作を記録するオプションがあります。設定ファイル（例: .codex/config.yaml や各ツールのセッション設定）に監査ログ（audit log）の出力先が指定されているか確認しましょう。ログが標準出力に流れるだけで永続化されていない場合、障害発生時に「何が起きたか」を後から追えません。
最後に、承認フロー（human-in-the-loopの確認ステップ）が有効化されているかを確認します。多くのエージェントツールは、破壊的な操作（ファイル削除、外部への書き込み、本番相当の環境への接続など）の前に確認を挟む設定を持っています。この設定が無効化・省略されていないか、チームのエージェント運用ポリシーを一度見直す価値があります。
対策の手順
1. 実行環境をサンドボックス化する: エージェントの作業ホストを、本番クレデンシャルにアクセスできないコンテナやVMに隔離します。Docker等でネットワークを制限し、本番DB・本番APIへの経路を物理的に遮断するのが確実です。
2. 監査ログを外部に集約する: エージェントのコマンド実行・API呼び出しをホスト内のログだけに頼らず、Datadog、CloudWatch Logs、Elasticsearchなど外部の集約基盤に転送します。「いつ・誰が・どのエージェントセッションで・何を実行したか」を後から検索できる状態にしておきます。
3. 破壊的操作にゲートを設ける: rm、kubectl delete、terraform destroy のような不可逆コマンドは、エージェントが直接実行できないようにラップし、人間の承認を挟むワークフローにします。CI/CDのapproval gate（承認ゲート）と同じ考え方です。
4. リモート操作の監督間隔を決める: 離席中にエージェントを走らせる場合でも、決定的な分岐（デプロイ、削除、外部通知の送信など）では必ず一時停止して人間の確認を挟む設定にします。監督が完全に不在になる時間帯を作らないことが要点です。
5. 障害時のロールバック手順を用意する: エージェントの操作が原因の障害は、通常のデプロイロールバックとは異なる場合があります。設定ファイルの変更、DBへの書き込み、外部サービスへのリクエストなど、コード変更以外の副作用が発生していないかを含めて確認できるチェックリストを事前に用意しておきます。
確認しておきたいこと
AIエージェントが「コードを書く道具」から「コンピュータを操作する道具」に変わったことで、運用監視の対象もコードからシステム全体の操作履歴に広がりました。
- エージェントの実行権限が本番環境のクレデンシャルと分離されているか
- 操作ログが外部基盤に集約され、後から追跡できる状態か
- 破壊的な操作の前に人間の承認ゲートが機能しているか
- 離席中の監督体制で分岐判断が放置されていないか
これらをまず自分のチームの設定で確認し、抜けている部分から順に手を入れていくのが現実的な進め方です。