AIエージェント（指示を受けて自律的に作業を進めるAI）の活用が広がっています。メールを読んで返信案を作り、社内システムからデータを取り出し、資料をまとめて関係者に共有する。まるで新しい社員が一人増えたかのような働きぶりです。しかし、AIエージェントは社員ではありません。入社手続きもなければ退職もなく、深夜も休日も動き続けます。この「社員のように働くが、社員ではない」存在が、情報管理の足元を静かに揺るがし始めています。
多くの会社のID管理（社員一人ひとりにアカウントを発行し、入社時に権限を与え、退職時に消す仕組み）は、「アカウントの持ち主は人間である」という前提の上に設計されてきました。AIエージェントの普及は、この前提そのものを崩します。本記事では、何が変わるのか、経営として何を指示すべきかを整理します。
非人間のIDが増殖する
AIエージェントが業務システムに接続するには、人間と同じようにアカウントや接続用の鍵（APIキーなど、システムにアクセスするための認証情報）が必要です。問題はその数です。エージェントごと、任せるタスクごと、接続先のシステムごとに別々の鍵が発行されるため、活用が本格化した会社では、人間の社員数の数倍から数十倍もの「非人間のID」が生まれえます。
人間のアカウントであれば、入社と退職という節目で必ず見直しが入ります。ところがエージェントの鍵には節目がありません。試験的に作ったエージェントがそのまま放置され、担当者が異動しても鍵だけが生き続ける。誰も把握していない鍵は、いつか必ず事故の入口になります。実際、クラウド環境の情報漏えいでは、棚卸しされないまま放置された認証情報が起点となる例が繰り返し報告されてきました。数が増えるほど、この「忘れられた鍵」も増えていきます。
さらに現場では、手間を省くために複数のエージェントで一つの鍵を使い回す運用も起こりがちです。これは二重に危険です。事故が起きたとき、どのエージェントの動きだったのかを切り分けられなくなり、かといって鍵を失効させれば、その鍵に相乗りしていた業務が一斉に止まります。「一エージェント一鍵」を原則にし、共有をやめさせるだけでも、事故対応の難易度は大きく下がります。
「とりあえず全部」という過剰権限の誘惑
エージェントを作る現場には、ある誘惑があります。権限を細かく絞ると設定や動作確認に手間がかかるため、「とりあえず全部アクセスできるようにすれば動く」という作り方です。開発のスピードだけを見れば合理的に見えますが、セキュリティの視点では最悪の選択です。しかも一度広く与えた権限は、業務が乗ってしまうと後から絞りにくくなります。最初の設計が、そのまま数年先のリスクの形を決めるのです。
なぜなら、エージェントが乗っ取られたときの被害範囲は、そのエージェントが持っていた権限の範囲とぴったり一致するからです。前回解説したプロンプトインジェクション（外部の文章に仕込まれた指示でAIの動作をすり替える攻撃）を思い出してください。攻撃が成立するかどうかと、成立したときに何が起きるかは、別の問題です。攻撃のリスクと権限の広さは掛け算の関係にあります。どれほど入口の対策を固めても、全部にアクセスできるエージェントが一度すり替えられれば、被害も「全部」に及びます。逆に、権限が狭ければ、同じ攻撃を受けても被害は限定されます。
最小権限と期限の原則
対策の原則はシンプルです。第一に最小権限（その目的に必要な範囲だけの権限を与えること）。経費精算を処理するエージェントに、人事評価の情報まで読ませる必要はありません。第二に期限。プロジェクトのために発行した鍵は、期限を最初から決めておき、終わったら失効させる。第三に棚卸し。使われていない鍵や過剰な権限を定期的に洗い出し、回収する。
お気づきの通り、これは人間の権限管理とまったく同じ原則です。新しい理屈は何もありません。違いはただ一つ、数です。数十人分の権限なら台帳と手作業で管理できますが、数百、数千の鍵を人手で棚卸しし続けるのは現実的ではありません。原則は同じでも、数が一桁二桁変われば、自動化の仕組みが必須になります。発行・失効・棚卸しを自動で回す仕組みへの投資判断が必要になる。これが、従来のID管理の延長では足りなくなるという意味です。
実務のコツは、権限をエージェントごとに個別設計するのではなく、「役割」の型で用意しておくことです。たとえば、読むだけの型は、社内規程やFAQに答える問い合わせ対応ボット（閲覧権限のみ）。下書きを作る型は、議事録の要約案やメールの返信案を作るアシスタント（作成まではするが、送信や確定は人間が行う）。限定実行の型は、経費精算の一次チェックや定型レポートの自動送信のように、あらかじめ絞った範囲の操作までを担うエージェントです。あらかじめこうした型を決めておけば、新しいエージェントを作るときも「どの型に当てはまるか」から審査を始められるため、ゼロから議論する必要がなくなり、審査も速くなります。型に収まらない要求だけを、例外として個別に検討すればよいのです。
取り返しのつかない操作には人間の承認を
権限の絞り込みとあわせて考えるべきなのが、「承認ゲート」の設計です。送金、データの削除、社外への公開。こうした取り返しのつかない操作は、どれほど優秀なエージェントであっても、実行の直前に人間の確認を挟む設計にすべきです。エージェントが下準備までを整え、最後のひと押しだけを人間が判断する。この形なら、自動化の恩恵と歯止めを両立できます。
重要なのは、どの操作にゲートを置くかは技術の問題ではなく、業務の問題だということです。いくら以上の送金に承認を求めるか。どの範囲のデータなら自動での修正を許すか。これは業務の重みとリスクを知っている側にしか決められません。承認ゲートの設計は、技術部門に丸投げできない経営マターです。すべてに承認を求めれば自動化した意味がなくなり、何も求めなければ事故のときに止める場所がありません。この線引きこそ、経営が引き受けるべき判断です。
経営としての初動 ― まず「一覧はあるか」と聞く
明日からできる初動は、一つの問いから始まります。「うちのAIエージェントに付与している権限の一覧はあるか」。この問いに即答できる会社は、まだ多くありません。そして答えられないこと自体が、現状のリスクの大きさをそのまま示しています。
進め方は三段階です。第一に棚卸し。どのエージェントが、どのシステムに、どんな権限でつながっているかを一覧にする。第二に回収。使われていない鍵と、目的に対して過剰な権限を削る。第三にルール化。新しい鍵の発行に申請と承認の手続きを設け、必ず期限を付ける。いずれも大きな投資の前に着手でき、一覧を作るだけでも危ない箇所は浮かび上がります。
あわせて、この仕事の持ち主を一人決めてください。エージェントの権限は、AIを推進する部門と情報システム部門の間に落ちやすいテーマです。推進側は動かすことに、システム側は人間のアカウントに意識が向き、非人間のIDが宙に浮く。棚卸しの期限と報告先を決め、責任者を指名する。ここまでが経営の指示であり、それだけで現場は動き始めます。
そして権限の問題は、エージェントが「何とつながるか」という問題と表裏一体です。次回は、AIが外部のツールやサービスと接続することで生まれるツール接続のサプライチェーンのリスクを取り上げます。
DSB Consultingでは、AIエージェント導入に伴う権限の棚卸しから、発行ルール・承認ゲートの設計まで、経営目線での体制づくりを支援しています。自社のエージェントがどんな権限を持っているか把握できていないと感じたら、無料相談をご利用ください。