【AI駆動開発】AIエージェントの権限、絞ってますか？最小権限の原則超入門

はじめに

こんにちは、エンジニア5年目の嶋田です。
この記事を開いていただき、ありがとうございます！

前回、「Human-in-the-Loop（HITL）」について記事を書きました。

「取り消しがきかない・影響が広い操作は、人間の承認を挟むべき」という話をしたのですが、記事の最後にこう書いていました。

HITLの4レベル：いつ・どのタイミングで人間が関わるかの話
権限設定：エージェントにそもそも何をする権限を与えるかの話

両方を組み合わせて設計するのが実務的です。

この「権限設定」の部分、最後に一言添えただけで終わらせていました。

そこで今回は、この積み残しにしていた 「AIエージェントに、そもそもどこまでの権限を与えるべきか」 を整理します。

キーワードは 最小権限の原則（Principle of Least Privilege） です。

• できるだけ専門用語を使わずに
• 身近なたとえで
• 実務でどう考えればいいかが分かるように

まとめます。

※この記事は2026年9月時点の情報をもとにしています。
この分野は動きが速いので、正確な内容は各公式ドキュメントを確認してください。

目次

• まず全体像：なぜ権限の話が必要なのか
• 最小権限の原則とは
• 「過剰な権限」の3つのパターン
• 権限をどう区切るか
• 権限が広すぎると何が起きるか
• 現実はまだ追いついていない
• まぎらわしい用語の違い
• まとめ
• 参考文献

まず全体像：なぜ権限の話が必要なのか

細かい話に入る前に、全体像を先に見ておきます。

前回のHITL記事では、「エージェントが取り消しのきかない操作をする前に、人間の承認を挟む」という話をしました。

ただ、これはあくまで 「エージェントがその操作をできる」という前提 の話です。

そもそも、こう考えることもできます。

承認フローをどれだけ頑張って作っても、
エージェントに「決済ツール」や「削除ツール」を呼べる権限自体を渡さなければ、
そのリスクは最初から発生しない。

つまり、HITLが「実行する直前で止める」仕組みだとすると、最小権限の原則は 「そもそも実行できる範囲を狭くしておく」 仕組みです。

前回のHITLが「入口の手前の関所」だとすると、今回の権限設計は 「そもそもどの道を用意しておくか」 の話です。

ここから、それぞれを詳しく見ていきます。

最小権限の原則とは

まず「最小権限の原則」からです。

これはAI以前から、情報セキュリティの世界で昔から言われてきた考え方です。

かみ砕くと、こうなります。

最小権限の原則とは、あるタスクを完了するのに必要な権限だけを、必要な期間だけ与えること。

例えば、AIエージェントに「商品の在庫を教えて」と頼むタスクを任せるとします。

このタスクに必要なのは、商品テーブルを読み取る権限だけ です。

なのに、もしこのエージェントに「データベース管理者権限（何でも読み書き・削除できる権限）」を与えていたらどうなるでしょうか。

• 普段は問題なく動く
• でも、エージェントが勘違いをしたり、悪意のある入力に騙されたりしたとき、本来必要のなかった「削除」や「書き込み」まで実行できてしまう

これが、最小権限の原則を守らないことの怖さです。

普通に「エージェントに何でもできる権限を与える」場合との違いは、次の2点です。

観点	権限を絞らない場合	最小権限で設計した場合
普段の動作	問題なく動く（違いが見えない）	問題なく動く（違いが見えない）
トラブル時	与えられた権限の全範囲が危険にさらされる	被害が、与えていた狭い範囲にとどまる
設計の手間	楽（とりあえず全部許可すればいい）	やや手間（タスクごとに必要な権限を洗い出す）

ポイントは、「普段は違いが分からない」 という点です。最小権限の原則は、うまくいっているときには効果を実感しにくく、何かあったときに初めて効いてくる、地味だけど大事な備えです。

「過剰な権限」の3つのパターン

AIエージェントのセキュリティを整理している国際的な団体に、OWASP（オワスプ）という組織があります。Webアプリケーションのセキュリティで昔から有名な団体ですが、生成AI・LLMのリスクについても整理を出しています。

その中で、「Excessive Agency（過剰なエージェント権限）」という項目があり、次のように定義されています（OWASP GenAI Security Project「LLM06:2025 Excessive Agency」より）。

エージェントに、広すぎる権限・自律性・機能が与えられている状態を指す。

これをかみ砕くと、過剰な権限には主に3つのパターンがあるとされています。

パターン	身近な例	何が問題か
過剰な機能	読み取りだけで十分なのに、書き込み・削除の機能まで持たせている	意図しない変更・削除が起きうる
過剰な権限範囲	特定のテーブルだけで良いのに、データベース管理者権限を渡している	権限が悪用されたときの被害が全体に及ぶ
過剰な自律性	重要な操作（送金・削除など）を、確認なしに自動で実行させている	取り消しのきかない操作が、誰の承認もなく起きてしまう

このうち「過剰な自律性」は、まさに前回のHITL記事で扱ったテーマです。今回は、残りの2つ、「機能」と「権限範囲」をどう絞るか に焦点を当てます。

権限をどう区切るか

「全部の機能を許可する」だと、エージェントの良さ（柔軟に動ける）が失われません。むしろ便利です。しかし、それは同時に「何かあったときの被害範囲」を最大化しているということでもあります。

判断基準1：読み取り・書き込み・実行で分ける

一番シンプルな区切り方は、操作の種類で分けることです。

権限レベル	できること	向いているタスクの例
読み取り専用	情報を見るだけ、何も変更しない	「この関数の役割を教えて」「在庫を確認して」
書き込み可	ファイルやデータを変更できる	「コードを修正して」「ドキュメントを更新して」
実行可	コマンドを実行したり、外部に影響を及ぼせる	「テストを実行して」「メールを送って」

タスクによって、本当に必要な権限レベルは変わります。「情報を調べて」と頼んでいるだけなのに、書き込み権限まで持たせておく必要はありません。

判断基準2：前回の「不可逆性×影響範囲」を、権限設計にも使う

前回のHITL記事で、「承認ポイントをどこに置くか」を決める軸として、不可逆性（やり直しがきくか）× 影響範囲（自分だけか、他人・外部にまで及ぶか） という2軸を紹介しました。

実はこの軸は、権限そのものを設計するときにも、そのまま使えます。

操作の例	不可逆性	影響範囲	権限として渡すべきか
ファイルを読み込んで内容を確認する	低い	狭い	渡してよい
ローカルのテストコードを書き換える	低い（Git等で戻せる）	狭い	渡してよい
外部にメールを送る	高い	広い	そもそもタスクに必要か再検討する。必要なら権限を絞った上でHITLも併用する
本番データを削除する権限	高い	広い	基本的に渡さない。必要な場面が来たら、その都度・一時的に付与する

HITLでは「この操作の前で止めるかどうか」を考えましたが、権限設計では一歩手前で 「そもそもこの操作を、このエージェントに任せる必要があるか」 を考えます。

権限が広すぎると何が起きるか

権限を広く設定しすぎることの怖さは、「爆発半径（blast radius）」という考え方で説明されることがあります。これは、権限設計やインシデント対応の分野でよく使われる考え方です。

これは、爆発物の被害が及ぶ範囲をイメージした言葉です。

• 権限を絞っていない場合：一箇所への攻撃・誤動作で、与えていた権限の全範囲（全データ・全システム）が影響を受ける
• 権限を絞っている場合：同じ攻撃・誤動作が起きても、被害はその狭い範囲にとどまる

例えば、「Slackに投稿する」ためだけのエージェントに、うっかり「全チャンネルの読み書き権限」を与えてしまっていたとします。

普段は何も問題が起きません。でも、もしそのエージェントが悪意のある入力（外部から送られてきたテキストに紛れ込んだ、AIへの不正な指示など）に騙されてしまった場合、本来アクセスする必要のなかった、全チャンネルの内容まで危険にさらされる ことになります。

権限を「投稿したいチャンネルだけ」に絞っておけば、同じことが起きても、被害はそのチャンネルだけにとどまります。

これが、「普段は違いが分からないのに、何かあったときに効いてくる」と最初に書いた理由です。

現実はまだ追いついていない

ここで、実際の現状にも触れておきます。

AIエージェントとツールをつなぐ規格として、前々回の記事でMCP（Model Context Protocol）を紹介しました。

前々回の記事で「2024年11月の公開時点で約100個だったMCPサーバーが、2026年5月時点で14,000以上に急増した」と書いたように、MCPの普及スピードは非常に速いものでした。

一方で、これだけ急速に広まったからこそ、権限管理やセキュリティの整備が、普及のスピードに追いつききれていない、という指摘も見かけます。

だからこそ、便利だからと言って安易にMCPサーバーへ幅広い権限を与えず、自分たちが使う分については、最初からタスクに必要な最小限の権限だけを与える という意識を持つことが、今の段階では特に重要だと感じました。

まぎらわしい用語の違い

ここまで出てきた用語は、似ていて混同しやすいです。
違いを表で整理しておきます。

用語	ひとことで言うと	役割
最小権限の原則	必要な権限だけを、必要な期間だけ与える考え方	権限そのものを設計する
HITL	実行前に人間の承認を挟む設計	実行のタイミングを制御する
Excessive Agency（過剰なエージェント権限）	機能・権限範囲・自律性が広すぎる状態	最小権限の原則が守られていない結果
爆発半径	何かあったときに被害が及ぶ範囲	権限をどこまで絞るべきかの判断材料

もうひとつ、よく混同される 「最小権限の原則」と「HITL」の違い も触れておきます。

• 最小権限の原則：そもそも何ができるかを制限する話（入口を狭くする）
• HITL：できることを、いつ実行してよいかを制御する話（実行の直前で止める）

「そもそも決済ツールを呼べないようにする」のが最小権限の原則、「決済ツールは呼べるが、実行前に必ず人間が確認する」のがHITL、というイメージです。前回も書きましたが、両方を組み合わせて設計するのが実務的です。

まとめ

今回は、前回のHITL記事で積み残していた「AIエージェントに、そもそもどこまでの権限を与えるべきか」を整理しました。

最後に、全体をもう一度まとめます。

用語	覚え方
最小権限の原則	タスクに必要な権限だけを渡す、地味だけど大事な備え
過剰な機能・過剰な権限範囲	「読み取りで十分なのに書き込みまで」「一部でいいのに管理者権限まで」
爆発半径	権限を絞っていないと、何かあったときの被害が全範囲に及ぶ
判断軸	前回の「不可逆性×影響範囲」は、権限設計にもそのまま使える

流れとしては、

HITLは「実行の直前で止める」仕組み。
最小権限の原則は「そもそも実行できる範囲を狭くしておく」仕組み。
権限を広く与えすぎると、何かあったときの被害範囲（爆発半径）も広くなる。
MCPの普及は速いが、権限をきちんと絞る仕組みの整備はまだ発展途上。
だからこそ、使う側が最初から意識して権限を絞る必要がある。

という関係でした。

前回、「HITLの4レベル」と「権限設定」を組み合わせるのが実務的だと書きましたが、今回それぞれを別々に見てきたことで、「いつ止めるか」と「そもそも何ができるか」は、別のレイヤーの話として設計する必要がある ということが、自分の中でもはっきりしました。

この記事が、「AIエージェントに、どこまでの権限を渡すべきか」を考えるきっかけになれば嬉しいです。

参考文献

• LLM06:2025 Excessive Agency | OWASP GenAI Security Project - AIエージェントにおける「過剰な機能・過剰な権限範囲・過剰な自律性」という3パターンの整理の根拠として参照しました。
• MCP（Model Context Protocol）とは | IBM（前々回記事の参考文献、本記事と地続きの内容として再掲）
• Article 14: Human Oversight | EU Artificial Intelligence Act（前回記事の参考文献、本記事と地続きの内容として再掲）

🔥 成長と挑戦を楽しむ仲間を募集中！

スピードリンクジャパンでは、一緒に技術を楽しめる仲間を探しています！

会社の雰囲気や働く環境などをまとめていますので、ご興味のある方はぜひサイトに遊びに来てください！

👉 リクルートサイトを見る