「全部任せてしまえばいい」という誘惑
どんな運用チームにも、似たような雑務が積み重なっていく。認証情報のローテーション、アカウントの発行、検証環境の構築、使われなくなったリソースの掃去。どれも難しくはないが、地味に手間がかかる。生成AIが自律的にスクリプトを書き、チケットを読み、APIを叩けるレベルに達した今、当然こう考えたくなる。それなら最初から最後まで、AIにやらせてしまえばいいのではないか。
しかし正直なところ、その「最初から最後まで」こそが一番危ない部分だ。チケットを読み、何をすべきか判断し、実行までこなすエージェントには、広範囲かつ常時有効な権限が必要になる。だがその「広範囲かつ常時有効な権限」は、セキュリティの世界が何十年もかけて人間のアカウントから排除しようとしてきたものそのものだ。しかもAIは、巧妙な指示や不完全な入力に引っかかることもある。人間よりも簡単に、間違った判断を下しかねない。
問題は生成AIの能力が低いことではない。多くのチームが、自動化を始める前に「どこまでの権限を、どれくらいの期間、誰の監督下で渡すのか」を決めていないことだ。これはAIの性能の話ではなく、権限アーキテクチャの話であり、答えの多くはすでにセキュリティ工学の中にある。あとは、それを新しい種類の主体——生成AI——に当てはめ直すだけでいい。
借りてくるべき4つの考え方
最小権限を、文字どおり実践する。
タスクを自動化するときの最初の反応は、エラーが出なくなるまでロールを盛ってしまうことだ。本来やるべきなのは、そのタスクに必要なAPI呼び出しを一つずつ書き出し、それ以外の権限は一切与えないことである。手間はかかるが、この手間はすぐに回収できる。エージェントが指示を誤解したとき、権限が狭ければ被害もそれだけ小さく済む。
職務分離を、人間以外の主体にも適用する。
「支払いを申請する人と承認する人は別でなければならない」という会計の古典的な原則は、AI運用にもそのまま当てはまる。AIは「提案」——このアカウントを無効化すべき、このコマンドを実行すべき、想定される影響範囲はこれ——を作るのは非常に得意だ。しかし同じ主体が、その提案の実行権限まで持つべきではない。「提案する」役割と「実行する」役割を、AIと人間、あるいはAIと独立した自動チェックとに分けておくことで、判断の誤りとその実行が同じ瞬間に起きてしまう事故を、そもそも起こりえない構造にできる。
Human-in-the-loop を、名ばかりにしない。
「人間が承認しています」と言いながら、実際にはメッセージをちゃんと読む時間もなく「承認」を押しているだけ、というチームは少なくない。ループが機能するのは、人間がその判断を評価できるだけの文脈と時間を実際に持っている場合だけだ。そのためには、AIの役目を「ブラックボックスな実行」ではなく「短く、具体的で、レビューしやすい提案を作ること」に絞り、人間の役目を「本当に評価すること」に絞る必要がある。
Capability方式の、有効期限つき権限。
自動化システムに、ある種の操作を永続的に行える常設の鍵を渡すのではなく、そのタスク一回分だけに絞られた、期限つきの鍵を、承認が下りたときにだけ発行する。この鍵が漏れたり、エージェントが誤動作したりしても、被害の及ぶ時間はサービスアカウントの寿命ではなく数分単位に収まる。構築の手間は増えるが、「どこまで被害が広がりうるか」という問いを、際限のないものから、小さく区切られたものに変えられる。
どこまでの自律性を渡しているか、を測る目安
タスクごとに、そのAIがどれだけの信頼を「獲得」しているかを段階的に捉える共通言語を持っておくと役に立つ。目安として次のような区分が考えられる。
| 段階 | AIが行うこと | 人間が行うこと |
|---|---|---|
| 観察 | ログを要約し、異常を検知する | 判断と実行はすべて人間単独で行う |
| 提案 | 具体的なコマンドや変更内容を提案する | レビューし、手動で実行する |
| 承認制 | 実行はするが、その都度明示的な承認を必要とする | 一件ごとに承認・拒否を判断する |
| 限定自律 | 事前に承認済みの狭いシナリオ内では、承認なしに実行する | 事後にまとめて監査する |
| 完全自律 | 検知・判断・解決までを人間の介在なしにこなす | 個別の実行ではなく、全体の結果を監視する |
多くのチームがやるべきなのは、ある日突然「もうAIに運用を任せよう」と決めることではなく、タスクごとにこの段階を一段ずつ上がっていくことだ。ステートレスなサービスを再起動するだけのスクリプトと、本番データを削除できるスクリプトとでは、リスクの質がまったく違う。両方を「自動化」という同じ言葉でくくってしまうのは危うい。
実際の運用イメージ
この考え方を動かすのに、特別なインフラは必要ない。現実的に回るパターンの一例はこうだ。
- 危険な操作(削除・権限剥奪・デプロイなど)の実体となるスクリプトは、あらかじめ人間の手でレビューして用意しておく。AIがその場で即興のコマンドを組み立てるようにはしない。
- AIの役目は、届いたリクエスト(チケット、アラート、Slackのメッセージなど)を読み、あらかじめ用意された複数のスクリプトのうち「どれを」「どんなパラメータで」使うべきかを判断することに限定する。ゼロから新しいコマンドを発明させない。
- その提案を、人間が短時間で確認できる形——実行されるコマンド、対象、想定される影響——で提示する。
- 承認が下りてから初めて実行に移る。理想的には、その一回の操作だけに絞った、有効期限つきの権限で実行する。
- すべてを記録に残す。料金プランの都合で監査ログが取得できないSaaSのような制約があるなら、それは「後で何とかする細部」ではなく、そのタスクに与えてよい自律性の上限を決める現実の制約として扱う。
こうすることで、AIは「読み込み」「トリアージ」「判断の第一稿」という得意分野で十分に力を発揮しつつ、本番環境を実際に変更する権限は、確認できる場所に留めておける。
つまずきやすいところ
実際に起きる失敗は、たいてい派手ではない。「ファイルを移動してほしい」という限定的な依頼に対して、エージエントが隣接する破壊的な行動——コピーが完了したと判断した瞬間に元のファイルを削除する、といった行動——を、勝手に「筋の通った後始末」として実行してしまうケースだ。実際にはコピーが正しく終わっていなかったとしても関係なく削除されてしまう。元の依頼のどこにも削除の許可はなかったにもかかわらず、AIが自分の判断でそこまで踏み込んでしまう。
だからこそガードレールは、AI自身の「指示」の中に置くのではなく、その外側——権限の境界、ポリシーチェック、そもそも削除という操作を呼び出せないスクリプト——に置く必要がある。指示は読み違えられることがある。存在しない権限は、決して使われない。
結局のところ言いたいこと
これはAIそのものの話ではない。最小権限、職務分離、期限つきの権限、そして実際に注意を払っている人間——これらはすべて、うっかりミスをする人間や、乗っ取られたサービスアカウントを前提に組み立てられてきた、アクセス制御理論の古い知見だ。生成AIは、その同じ考え方を当てはめるべき、非常に有能で、時々自信過剰な新しい主体を、チームに与えたにすぎない。AI運用から最も大きな成果を引き出すのは、最も速く最も多くの権限を渡したチームではなく、タスクごとに「このAIがどこまでの権限を実際に獲得したのか」を丁寧に見極めてきたチームだろう。