AIエージェントの権限設計とは？読み取り・書き込み・承認の分け方

先に要点

AIエージェントの権限設計では、`読める`、`下書きできる`、`書き込める`、`削除できる`、`承認後だけ実行できる` を分けます。
最初から広い管理者権限を渡すのではなく、読み取り専用から始め、必要な操作だけ段階的に足す方が安全です。
DB更新、本番反映、外部送信、課金、権限変更、削除は、原則として人間承認や強いガードレールを置きます。

AIエージェントにツールやAPIを渡すと、調査、コード修正、チケット作成、デプロイ確認、通知まで自動化しやすくなります。
ただし、便利さの裏側で一番効いてくるのが権限設計です。

人間なら これは本番だから触らない この顧客には送らない と空気を読める場面でも、AIエージェントは与えられた目的とツールから合理的に見える操作を選びます。
そのため、プロンプトに注意書きを書くだけではなく、そもそも危険な操作をできない権限にしておくことが重要です。

この記事では、AIエージェントの権限設計を、読み取り、書き込み、承認付き操作の分け方から実務目線で整理します。
本番操作全体の前提は AIエージェントに本番操作を任せる前に決めること｜権限・承認・ログ設計のチェックリストもあわせて読むとつながりやすいです。

まず結論：権限は「操作の種類」で分ける

AIエージェントの権限は、担当者名や便利なツール名だけで分けると粗くなりがちです。
実務では、操作の種類で分ける方が安全です。

権限の段階	できること	向いている用途	注意点
読み取り	ログ、設定、ドキュメント、チケット、メトリクスを見る	調査、要約、原因候補の整理	機密情報や個人情報を読ませすぎない
下書き	PR、SQL案、返信案、作業手順を作る	人間レビュー前提の作業	下書きと送信を同じ権限にしない
書き込み	チケット作成、ラベル変更、検証環境への反映	低リスクな更新や検証作業	対象範囲、件数、環境を制限する
承認付き実行	本番DB更新、本番デプロイ、外部送信、課金変更	影響が大きい操作	承認者が判断できる差分と戻し方を出す
禁止	認証情報の表示、権限昇格、無制限削除、監査ログ削除	AIに任せない領域	プロンプトではなく権限やコードで止める

この分け方をすると、AIに何を任せるか を感覚ではなく操作単位で決められます。

読み取り権限：最初に渡しやすいが、油断しない

AIエージェントの導入は、読み取り専用から始めるのが現実的です。
ログ、ドキュメント、チケット、設定ファイル、監視メトリクスを読ませるだけでも、調査や整理はかなり進みます。

読み取り権限で任せやすい作業は次です。

障害ログの要約
変更履歴の確認
チケットや問い合わせの分類
ドキュメント検索
設定差分の説明
デプロイ履歴とエラー発生時刻の照合
監視アラートの一次整理

ただし、読み取りなら何でも安全というわけではありません。
本番ログには、メールアドレス、IPアドレス、認証エラー、顧客ID、内部URL、トークンの断片が含まれることがあります。

読み取り権限でも、次は確認します。

個人情報を読めるか
認証情報やシークレットが混ざるか
顧客ごとのデータを横断できるか
本番ログを外部AIサービスへ送ってよい契約か
読んだ内容が会話ログやトレースに残るか

書き込みできないから安全 ではなく、読める情報の機密度も権限設計の対象です。

下書き権限：AIに作らせ、人が出す

AIエージェントの権限設計で使いやすいのが、下書き権限です。
AIには作らせるが、送信や反映は人間が行う形です。

たとえば次のような作業です。

SQLの修正案を作る
Pull Requestを作る
障害報告の草稿を作る
顧客への返信案を作る
デプロイ手順を作る
Terraformや設定ファイルの変更案を作る

この段階では、AIエージェントはまだ本番へ直接影響を与えません。
ただし、下書きの中身に危険な操作が含まれることはあります。

たとえば、AIが 古いデータを削除するSQL を提案した場合、実行していなくてもレビュー対象としては高リスクです。
そのため、下書き権限でも、削除、権限変更、外部送信、課金変更が含まれる案にはラベルや警告を付けると実務で扱いやすくなります。

書き込み権限：低リスク操作から限定的に許可する

書き込み権限を渡すと、AIエージェントは便利になります。
チケットを起票する、タグを付ける、検証環境へデプロイする、社内メモを更新する、といった作業を自動化できます。

一方で、書き込みには副作用があります。
小さな書き込みでも、間違った相手に通知する、不要なチケットを大量作成する、ステータスを勝手に変える、検証環境を壊す、といった問題が起きます。

書き込み権限を渡すなら、次を決めます。

どの環境に書き込めるか
どのリソースに書き込めるか
1回で何件まで処理できるか
どの字段や状態を変更できるか
失敗時に再試行してよいか
外部通知が発生するか
書き込み結果をどう確認するか

おすすめは、書き込み権限を 低リスクで戻しやすいもの から渡すことです。
たとえば、社内チケットの下書き作成や検証環境のラベル更新は比較的始めやすい一方、本番DB更新や権限変更は別扱いにします。

承認付き操作：危険な書き込みは途中で止める

AIエージェントにすべてを自動実行させる必要はありません。
むしろ、危険な操作の直前で止める設計が重要です。

OpenAI Agents SDK の Human-in-the-loop では、承認が必要な tool 呼び出しで実行を中断し、承認または拒否後に再開できる流れが説明されています。
この考え方は、特定のSDKに限らず、AIエージェントの実務設計でもかなり重要です。

承認付きにしたい操作は次です。

操作	承認が必要な理由	承認者に見せる情報
本番DB更新	データ破壊や顧客影響が起きる	SQL、対象件数、バックアップ、戻し方
本番デプロイ	サービス全体に影響する	差分、テスト結果、影響範囲、ロールバック手順
外部送信	顧客や取引先へ誤送信する可能性がある	宛先、本文、添付、送信理由
課金・契約変更	金銭や契約状態に影響する	対象顧客、金額、変更前後、根拠
権限変更	不正アクセスや権限過多につながる	対象ユーザー、付与権限、期限、理由
削除	取り消しにくいことが多い	対象、件数、復元可否、代替案

承認は はい / いいえ だけでは足りません。
承認者が判断できる材料を出し、その内容を監査ログとして残す必要があります。

承認ログの設計は AIエージェントの承認ログには何を残すべき？後から説明できる記録設計で詳しく整理しています。

ツール単位ではなく「操作単位」で権限を分ける

よくある失敗は、ツール単位で権限を考えることです。

たとえば、GitHubツールを渡す と言っても、その中にはリポジトリ検索、Issue閲覧、Issue作成、ブランチ作成、PR作成、マージ、Secrets参照など、まったくリスクの違う操作が含まれます。
同じように、DBツール や クラウドツール も、読み取りと削除では危険度がまったく違います。

そのため、権限設計では次のように分けます。

read_logs
read_tickets
draft_sql
create_ticket
deploy_staging
request_production_deploy
execute_approved_sql
send_internal_notification
send_external_email_requires_approval

ツール名や関数名にリスクが見えるようにすると、AIエージェントにも人間にも分かりやすくなります。
特に MCP サーバーをつなぐ場合は、サーバー全体で何ができるかだけでなく、個々のツールが読み取りなのか、書き込みなのか、承認付きなのかを確認します。

ロールごとに渡す権限を変える

AIエージェントが複数いる場合は、全員に同じ権限を渡さない方がよいです。
役割ごとに必要な権限は違います。

エージェントの役割	渡しやすい権限	渡さない方がよい権限
調査エージェント	ログ読み取り、ドキュメント検索、メトリクス参照	本番更新、外部送信、権限変更
実装エージェント	リポジトリ読み取り、ブランチ作成、PR作成	本番デプロイ、シークレット参照
運用エージェント	監視確認、検証環境操作、承認済み手順の実行	無制限のクラウド管理権限
通知エージェント	社内通知、文面下書き	顧客への自動送信、添付ファイル送信
管理エージェント	承認状態の確認、ログ集約、進行管理	現場ツールの強権限をまとめて持つこと

これは RBAC の考え方にも近いです。
人間の社内システムでも、閲覧者、編集者、承認者、管理者を分けるように、AIエージェントにも役割ごとの権限を持たせます。

よくある権限設計の失敗

失敗例1：読み取り専用のつもりで管理者APIキーを渡す

AIには 読むだけ と指示していても、APIキーが管理者権限なら書き込みも削除もできる状態です。
この場合、実際の制御はプロンプト頼みになります。

対策は、読み取り専用のAPIキー、読み取り専用DBユーザー、限定スコープのトークンを用意することです。

失敗例2：本番と検証の権限を同じにする

検証環境でうまく動いたからといって、本番でも同じ権限を渡すと危険です。
本番環境では、承認、ログ、対象制限、ロールバック確認を追加します。

失敗例3：外部送信を軽く見る

Slackの社内通知と、顧客へのメール送信は別物です。
外部送信は、誤送信、機密情報の混入、法務・契約上の問題につながるため、下書きと送信を分けた方が安全です。

失敗例4：削除権限を「便利だから」で渡す

削除は便利ですが、戻せない場合があります。
AIエージェントには、削除ではなく 削除候補の一覧作成 や 無効化案の作成 までを任せ、実行は承認付きにする方が現実的です。

実務チェックリスト

AIエージェントの権限設計では、次を確認します。

読み取り、下書き、書き込み、削除、承認付き実行を分けた
本番環境と検証環境の認証情報を分けた
読み取り専用で足りる作業に書き込み権限を渡していない
外部送信、課金、権限変更、削除は承認付きにした
ツール名や関数名でリスクが分かる
1回の実行件数や対象範囲を制限した
承認者が差分、対象、影響範囲、戻し方を見られる
実行ログと承認ログを残す
認証情報や個人情報をログに残しすぎない
権限エラー時に別経路で突破しない停止条件を置いた

このチェックを通すだけでも、AIエージェントの事故リスクはかなり下げられます。

まとめ

AIエージェントの権限設計では、何でもできるAI を作るのではなく、必要なことだけできるAI を作ることが大事です。
読み取り、下書き、書き込み、承認付き実行、禁止操作を分けると、便利さと安全性のバランスを取りやすくなります。

特に本番DB更新、本番デプロイ、外部送信、課金、権限変更、削除は、AIの判断だけで進めず、人間承認、監査ログ、停止条件を組み合わせる方が安全です。
権限設計は地味ですが、AIエージェントを実務で使うほど効いてくる土台です。

関連して、ツールを渡しすぎる問題は AIエージェントにツールを渡しすぎると何が起きる？選択ミス・コスト・権限リスクを整理、承認点の置き方は人間承認をどこで入れるべき？AIエージェントの承認設計を整理で整理しています。
まずは読み取り専用から始め、効果とリスクを見ながら段階的に権限を広げるのが、現実的な進め方です。

参考

OpenAI Agents SDK: Human-in-the-loop
OpenAI Agents SDK: Tools
OpenAI Agents SDK: Guardrails
OpenAI Agents SDK: Model context protocol

AIエージェントの権限設計とは？読み取り・書き込み・承認を分ける実務チェック