AIエージェント安全運用ガイド — 権限・秘密情報・レビューゲートの設計

AIコーディングエージェントは、ファイルの読み書き、コマンドの実行、外部サービスへの接続までを人間の代わりに行います。便利さと引き換えに、「うっかり」の規模も大きくなります。この講義では、個人開発の現場で実際に起きた失敗の型をもとに、事故を起こしにくい運用の設計を全5章で整理します。

難しいセキュリティ理論は扱いません。「何を許可し、何を止め、どこで人間が見るか」という運用の話に絞って、今日から真似できる形で進めます。

まず、AIエージェントを使う開発で、なぜ従来と違う種類の事故が起きるのかを理解します。

作業の主体が「人」から「人＋エージェント」に変わった

従来のミスは、人が手で1つずつ操作する速度でしか起きませんでした。エージェントは同じ指示を数十ファイルに一気に適用できます。良い指示なら生産性が上がり、曖昧な指示なら被害も一気に広がります。速度が上がったぶん、止める仕組みを先に用意する必要があります。

よくある事故の型

実際に繰り返し起きているのは、次のような型です。

• 意図しないファイルの削除・上書き（対象範囲を伝えていなかった）
• 秘密情報がコードやログに混ざったまま公開された
• 「動いたので」と差分を読まずに取り込み、あとで壊れていたことに気づく
• 一時的な回避策（チェックの無効化など）がそのまま本番に残った

どれも技術的に高度な攻撃ではなく、運用の穴から起きています。

安全運用の3本柱

この講義では対策を3つの柱にまとめます。権限の最小化（できることを絞る）、秘密情報の分離（漏れても被害を限定する）、レビューゲート（人間が見る地点を固定する）です。どれか1つでは足りず、3つが重なって初めて「うっかり」が事故になる前に止まります。

失敗を前提に設計する

「注意深く使えば大丈夫」という前提は、疲れている日や締め切り前に必ず崩れます。人の注意力に頼らず、間違えても被害が小さく、すぐ戻せる状態を先に作る。これが安全運用の基本姿勢です。

第1章のまとめ

エージェントは速度と範囲を拡大する。だからこそ、権限・秘密情報・レビューゲートの3本柱を、注意力ではなく仕組みとして用意する。次章から1本ずつ具体化します。

エージェントに「できること」を絞る設計です。許可の与え方ひとつで、事故の最大被害が決まります。

許可リストで考える

「危険な操作を禁止する」より「必要な操作だけ許可する」ほうが漏れが出ません。読み取り・検索は広く許可し、書き込みは作業ディレクトリに限定し、削除やネットワーク送信、パッケージの追加は毎回確認にする。この3段階が基本の型です。

作業範囲を先に宣言する

依頼文の冒頭で、触ってよいディレクトリと触ってはいけないファイルを明示します。「設定ファイルと本番用の環境変数は変更しない」「テストはこのフォルダにだけ追加する」のように書くと、エージェントの提案がその範囲に収まりやすくなります。

実行前確認とサンドボックス

コマンド実行を伴う操作は、実行前に内容を見せてもらう設定にします。加えて、試したい変更は本番とは別の作業用ブランチや使い捨ての環境で行うと、失敗しても戻すコストがほぼゼロになります。

自動承認を使う条件

すべてを毎回確認していては速度の利点が消えます。自動承認は「戻せる」「範囲が閉じている」「テストで検知できる」の3条件がそろった作業に限定し、それ以外は人が承認する。条件を文章にしておくと、迷いが減ります。

第2章のまとめ

許可リスト、作業範囲の宣言、実行前確認、条件付き自動承認。権限の設計は「最大被害を小さくする」ための投資です。

鍵・パスワード・トークンといった秘密情報は、漏れた瞬間に被害が確定します。混ざらない、残らない、漏れても止められる設計を確認します。

コードに書かない・環境変数に置く

秘密情報はソースコードに直接書かず、環境変数や専用の管理サービスから読み込みます。起動時に必要な値がそろっているかを検証し、無ければ即座に止まる作りにしておくと、設定漏れが本番で静かに壊れる事故を防げます。

エージェントに渡す情報を選ぶ

エージェントに設定ファイルやログを読ませるとき、秘密情報が含まれていないかを先に確認します。除外設定を使って、環境変数ファイルや認証情報のディレクトリを最初から読み取り対象から外しておくのが確実です。

ログと画面に出さない

デバッグ中に「とりあえず全部出力」した結果、トークンがログや共有画面に残る事故が繰り返されています。秘密情報は出力時に伏せ字にする、ログの保存先を絞る、スクリーンショットを共有する前に確認する。地味ですが効果の大きい習慣です。

漏れたときのために回転できるようにしておく

鍵は「いつでも作り直せる」状態にしておきます。漏えいの疑いが出たら、原因調査より先に鍵を無効化して新しい鍵に切り替える。手順を書いておけば、深夜でも迷わず動けます。

第3章のまとめ

秘密情報は分離し、読ませず、出さず、回転できるようにする。この4点で、漏えいの確率と被害の両方が下がります。

人間が必ず見る地点を固定します。ゲートは「毎回全部読む」ではなく、「どこを、どの順で、何を基準に見るか」を決めることです。

差分は必ず人が読む

エージェントの出力は、適用前に差分として読みます。ポイントは3つ。想定した範囲に収まっているか、依頼していない変更が混ざっていないか、削除や設定変更が含まれていないか。この3点だけでも、事故の大半は入口で止まります。

テストを通過条件にする

「動いた」ではなく「テストが通った」を取り込みの条件にします。既存のテストを壊していないこと、新しい振る舞いにテストが追加されていることを確認します。テストが無い箇所への変更は、先にテストを書かせてから本体を変える順序が安全です。

失敗したら止まる（フェイルクローズド）

判定に迷う状況では「通す」ではなく「止める」側に倒します。認証の確認に失敗したら拒否する、チェックが実行できなかったら未合格とみなす。一時的に無効化したチェックは、期限と担当を書いた記録を残し、必ず戻します。

小さく出して早く戻せるようにする

1回の変更を小さく保つほど、レビューは速く、問題の切り分けも簡単になります。意味のある単位でコミットを分け、前の状態に戻す手順を確認してから公開する。これだけで「戻せない」事故がほぼ消えます。

第4章のまとめ

差分を人が読む、テストを通過条件にする、迷ったら止める、小さく出して戻せるようにする。ゲートは面倒な儀式ではなく、速度を維持するための安全装置です。

どれだけ備えても、事故はいつか起きます。起きたときに慌てないための手順を最後に整理します。

まず止める・広げない

異常に気づいたら、原因を探す前に影響を止めます。自動実行を停止する、公開を取り下げる、疑わしい鍵を無効化する。数分の判断で被害の大きさが変わります。

記録を残す

何が、いつ、どの操作で起きたかを時系列で書き残します。エージェントのやり取りのログ、実行したコマンド、変更した差分。記録があると原因の切り分けが速くなり、再発防止策も具体的になります。

切り分けと復旧

再現手順を作り、最小の条件で再現できる状態にしてから直します。復旧は「元に戻す」が最優先で、改善は後回し。戻したあとにテストを実行し、正常に戻ったことを確認してから次に進みます。

再発防止を仕組みに入れる

「気をつける」で終わらせず、権限の設定・除外リスト・テスト・チェックのどこかに対策を組み込みます。同じ型の事故が2回起きたら、それは運用の設計に穴がある合図です。

第5章のまとめ

止める、記録する、切り分けて戻す、仕組みに入れる。この順番を守れば、事故は「学びの機会」に変わります。

この講義で扱った差分レビューとテストの考え方は、特別講義「AIコーディングエージェント実践完全ガイド」の指示・分割・レビューの型と地続きです。あわせてご覧ください。

実際に手を動かしながら学びたい方は、全12週のシラバスで学習の全体像を確認できます（無料で読めます。成果や収益をお約束するものではありません）。

講義で扱ったテーマを、公式ドキュメントや公的機関の資料で確かめたいときの入口です。

• least privilege（NIST CSRC 用語集）：最小権限の原則の定義
• シークレットスキャンについて（GitHub Docs）：リポジトリに紛れ込んだ鍵を検出する仕組み
• OWASP Top 10 for LLM Applications：エージェントに権限を渡すときに想定すべきリスクの一覧

この特別講義は無料で視聴できる総集編です。関連する内容を実際に手を動かしながら学びたい方は、全12週のシラバスで学習の全体像を確認できます（無料で読めます。成果や収益をお約束するものではありません）。先行案内はこちら。