AIエージェントの「自律性」は、モデルではなく権限設計で決まる
AIエージェントは、文章を書くだけでなく、ツールを呼び出して業務を実行する。誤りは文章ではなく行動として現れる。どこまで任せ、どこで止めるかは、モデルの賢さでは決まらない。経営が決め、権限とログと承認の仕組みとして実装するものだ。
この記事の要点
- エージェントの主なリスクは、過剰な権限と、外部の文書に仕込まれた指示による乗っ取りである
- 任せる範囲は、操作の「取り消しやすさ」と「影響範囲」で決める
- 統制はプロンプトではなく、ID・ネットワーク・承認・ログというモデルの外側に置く
リスクは「書く」から「動く」へ移った
これまでの生成AIは、人が出力を読んでから使うものだった。誤りがあっても、人の確認が最後の防波堤になった。エージェントは違う。メールを送り、データを更新し、発注をかける。人の確認を待たずに、次の手を打つように設計される。
OWASPが公開しているLLMアプリケーションの主要リスク一覧（OWASP Top 10 for LLM Applications）にも、「過剰な権限（Excessive Agency）」が挙げられている。必要以上の機能・権限・自律性を持たせることそのものが、脆弱性になるという考え方だ。
もう一つのリスクは、間接的なプロンプトインジェクションである。エージェントが読むWebページ、メール、添付文書に指示が紛れ込んでいると、エージェントはそれを命令として実行しうる。特に「非公開データへのアクセス」「信頼できない外部コンテンツへの接触」「外部への送信手段」の3つを同じエージェントが持つと、情報漏えいの経路が完成してしまう。この組み合わせは、セキュリティ研究者のSimon Willisonが「lethal trifecta」として整理している。私たちは設計の段階で、この3つを一つのエージェントに同時に持たせないことを原則にしている。
どちらのリスクも、モデルを賢くしてもなくならない。止める仕組みは、モデルの外側に作る必要がある。
任せる範囲は「取り消しやすさ × 影響範囲」で決める
「この業務をAIに任せてよいか」という問いは、大きすぎて答えられない。操作ごとに、取り消せるか、影響はどこまで及ぶかを問えば、任せ方は自然に決まる。
- 取り消せる・影響が局所的：自律的に実行させ、事後にログで確認する。例は下書き作成、社内文書の検索。
- 取り消せる・影響が広い：自律実行に監視を組み合わせ、レート制限と予算上限を設ける。例は多数のレコードへのタグ付け。
- 取り消せない・影響が局所的：実行前に人が承認する。根拠と差分を添えて承認を依頼する。例は個別の外部送信、発注。
- 取り消せない・影響が広い：エージェントに権限を持たせない。人が実行するか、二者承認にする。例は本番データの削除、大口の支払い。
この図をどこで線引きするかは、業務と会社のリスク許容度による。だから開発チームだけでは決められず、経営の判断が要る。ここで注意したいのは、すべてを承認制にしないことだ。承認依頼が多すぎると、人は中身を見ずに押すようになり、承認は形だけになる。取り消せない操作に絞って初めて、承認は意味を持つ。
経営が決めるべき4つのこと
- 責任の境界：上の図の4つの領域に、自社の操作を振り分けて文書にする。金額や件数の閾値もここで決める
- AIの関与の開示：AIが関わった成果物や判断には、その旨と根拠の来歴を残す。社外には表示を、社内には参照できる記録を用意する
- 導入の目的：人員削減ではなく業務の再設計として定義し、従業員を設計に参加させる。現場が信頼しない仕組みは、結局使われない
- 検証の義務：「問題は起きていないはずだ」ではなく、「問題が起きていないことを証拠で示せる」状態を求める。言葉のガバナンスから、証拠のガバナンスへ移る
実装：統制をモデルの外側に置く
経営の決定は、システムの制約として実装して初めて効力を持つ。私たちがエージェントを設計するときに確認するのは、次の5つの層だ。
| 層 | 実装の要点 | 防ぐもの |
| 目標 | ステップ数・時間・トークン・金額の上限と、「達成できない」という正規の終了状態を仕様に書く | 目標達成を優先した迂回や暴走 |
| IDと権限 | エージェントごとに専用のIDを発行する。ツール単位のスコープと数分で失効するトークンを使い、人の認証情報は貸さない | 過剰な権限、権限の横流し |
| ツール | 接続するツールは許可リスト制。読み取りと書き込みを別のツールに分け、引数はスキーマで検証する | 想定外の操作、不正な引数 |
| 実行環境 | 隔離された環境で動かし、外向きの通信は既定で遮断する。許可した宛先だけをプロキシ経由で通す | 情報の持ち出し、外部への不正アクセス |
| 観測と責任 | 観察→判断→ツール呼び出し→結果を、一つのトレースとして記録する。不可逆な操作は、差分と根拠を添えて人の承認に回す | 事故の見落とし、説明責任の空白 |
ログは、OpenTelemetryの生成AI向けセマンティック規約のような標準の形式で残すとよい。既存の監視基盤にそのまま載せられ、監査や事故調査のときに「なぜその操作をしたのか」をたどれる。
プロンプトでの「お願い」は、統制ではない
「データを削除しないでください」とシステムプロンプトに書いても、それは統制にはならない。外部の文書に仕込まれた指示で上書きされうるし、モデルが目標達成を優先して無視することもある。削除権限を与えないことが統制である。
プロンプトは振る舞いを「導く」もの、権限と実行環境は振る舞いを「制約する」ものとして、役割を分けて設計する。
だから、経営のテーマになる
モデルの性能差は縮まっている。これから差がつくのは、「どこまで任せ、どこで止めるか」を自社の言葉で決め、それを権限とログと承認で実装できた組織だ。証拠を積み上げながら任せる範囲を広げられる企業ほど、AIエージェントの恩恵を大きく受けられる。