情シスはAIエージェントに、どこまで権限を渡すか

AIエージェントに本番の権限を求められたら、人のアカウントを貸さず、エージェント専用の実行アカウントを作って、処理ごとに要る段階だけを付けます。段階は「読むだけ／自分の作業場所に書く／共有・基幹に書く／社外へ送る・削除・支払い」の4つで、上の2段には人の承認を挟みます。そのうえで期限と操作の記録を付け、使われない権限は外します。

エージェントの権限は、処理ごとに4段階で決める

AIエージェントに渡す権限は、専用の実行アカウントに、処理ごとに4段階のどこまで要るかで付け、上の2段は人の承認を挟みます。4段階の中身は次のとおりです。

1. 読むだけ：ファイルやデータベース、メールを読み、結果を人に返す
2. 自分の作業場所に書く：エージェント専用のフォルダや下書きの欄にだけ書く
3. 共有・基幹に書く：部署の共有ファイルや、会計・販売・在庫などの基幹システムを更新する
4. 社外へ送る・削除・支払い：メールで社外へ送る、データを消す、注文や支払いをする

4段階の境目は公的な基準で決まっているものではなく、運用のための整理です。自社の事情で動かして構いません。ただ、社外への送信・削除・支払いを最上段に置くことだけは残してください。

段階を処理ごとに分けるのは、最小特権の考え方に沿わせるためです。AWS は IAM の推奨として、タスクの実行に必要なアクセス許可だけを付与するよう勧めています。IPA の「中小企業の情報セキュリティ対策ガイドライン 第4.0版」も、IDは発行から削除までを管理し、必要最小限の割り当てにするよう求めています。

上の2段に人の承認を挟むのは、間違えたときに元へ戻しにくいからです。総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」の別添は、この点を具体的に挙げています。エージェントが自律的な動作の中で、意図しない商品の注文やファイル削除を行う可能性があるとしています。

同じ別添は、外部と連携するエージェントが攻撃で操作され、内部データが意図せず外部に送信されるおそれにも触れています。

下の2段は、誤りがあっても人の目に入るまで外へ出ません。読んだ結果も、作業場所に置いた下書きも、人が見てから使うからです。そもそもどの仕事をエージェントに任せるかが決まっていなければ、AIエージェントにどこまで仕事を任せられるかを整理した記事で、任せる仕事を先に選んでください。

エージェント1つに、まとめて権限を付けない

1つのエージェントは、たいてい複数の処理をこなします。問い合わせを読み、返信の下書きを作り、顧客台帳の対応履歴を更新する、という具合です。エージェント単位で権限を付けると、いちばん重い処理に合わせた権限が、読むだけで済む処理にも付いてしまいます。

処理ごとに段階を付けておけば、重い処理だけを承認つきに分けられます。製品の側で処理ごとに分けられない場合は、処理ごとに実行アカウントを分けるか、重い処理だけを人の操作に残します。

なぜ人のアカウントを貸してはいけないのか

人のユーザーは、幅広いリソースに届く1つのIDを持っています。そのアカウントを貸すと、その人が触れるものすべてがエージェントの届く範囲になり、記録の上でも人の操作と区別できません。Microsoft も Entra のワークロードIDの説明で、人のIDとソフトウェアに割り当てるIDを分けて扱っています。

貸したアカウントで困るのは、範囲の広さだけではありません。誤った削除が起きたとき、本人が消したのかエージェントが消したのかを記録から切り分けられません。本人が異動や退職でアカウントを止めると、エージェントも一緒に止まります。逆に、エージェントを動かすために人のアカウントを残し続けることにもなります。

IPA のガイドラインは、共有IDはなるべく使わず、使う場合は利用者を特定できる仕組みを整えるよう求めています。人とエージェントが1つのアカウントで動く状態は、この共有IDと同じ形です。

専用アカウントにしても、届く範囲を広く取れば同じことが起きます。Google Workspace のドメイン全体の委任は、利用者の同意なしに、利用者のデータへアクセスする権限をアプリに与える強力な機能です。Google は委任の前に、アプリやサービスアカウントのアクセスの範囲（スコープ）が適切に制限されているか確かめるよう求めています。

専用アカウントは、作成から取り消しまで台帳で追う

Microsoft は、ワークロードIDがいつ作られ、いつ取り消されるかを追うのは難しいとしています。人のアカウントなら入社と退職で棚卸しできますが、エージェントの実行アカウントには、その節目がありません。

そこで、作った時点で台帳に1行を足します。書く欄は、アカウント名・動かすエージェント・受け持つ処理・付けた段階・社内の責任者・作成日・期限・次の見直し日です。責任者は開発会社の担当者ではなく、社内でそのエージェントを使う部署の人にしておくと、契約が終わったあとも行方が残ります。

どの処理を、どの段階に置けばいいか

調べる・要約するは読むだけ、下書きは自分の作業場所に書くまで、社内の記録の更新は共有・基幹に書く段で承認つき、社外への送信・削除・支払いは最上段で毎回承認です。業界をまたいでよくある事務の処理を、1行ずつ当てると次のようになります。

読むだけで済むかは、結果を誰が使うかで見分けます。エージェントの出した結果を人が読んで使うなら、エージェント自身は何も書き換えなくて足ります。要約・調べもの・突き合わせのチェックは、たいていこの段に収まります。

どの段に置くか迷う処理は、上の段に置いて始めます。承認を挟んで動かし、操作の記録を見て、承認者が一度も止めなかった処理だけを次の見直しで下げます。下の段から始めて事故のあとに上げるより、戻すべき操作が少なく済みます。

管理者権限を求められたら、処理に分けて返す

仮に、開発会社から「請求書の下書きを作るエージェントに、会計システムの管理者権限を付けてほしい」と頼まれた場合を考えます。返す前に、エージェントがする操作を1つずつ書き出してもらいます。

書き出すと、取引先と品目を読むのは段階1、下書きを作るのは段階2、発行と送付は段階4です。管理者権限が要る操作はありません。返事は「会計は読み取りと下書きの作成まで。発行と送付は担当者が行う」になります。

会計システムの側で下書きだけを許す権限が作れないなら、エージェントの結果はシステムの外の専用フォルダに置き、登録は人が行う形にします。製品の都合で広い権限しか作れないことは、広い権限を渡す理由にはなりません。

決めた段階は、どの仕組みで守らせるか

決めた段階は、エージェントの側の設定と、つなぐ先のアカウント管理の両方で守らせます。片方だけだと、設定を変えられた日や、別の道具から同じアカウントを使われた日に段階が崩れます。主な仕組みで権限を絞れる場所は次のとおりです。

Claude Code は、権限ルール・モード・管理ポリシーで、アクセスして実行できる内容を制御します。ルールは deny・ask・allow の順に評価されるため、削除を deny に置けば、別のところで allow を足されても削除は通りません。

plan モードでは、ファイルを読み取り、読み取り専用のコマンドで調べますが、ソースファイルは編集しません。確認を飛ばすモードについては、損害を起こせないコンテナや VM などの隔離した環境でだけ使うよう、公式が求めています。管理者が配る管理設定は、利用者やプロジェクトの設定で上書きできません。

AWS は、ワークロードが AWS にアクセスするときに IAM ロールの一時的な資格情報を使うことを必須とするよう勧めています。長く使える鍵をエージェントに持たせるより、段階ごとに分けたロールを処理のたびに引き受けさせる形のほうが、期限も付けやすくなります。

RPA型の自動化アカウントも考え方は同じです。ロボット用の専用アカウントを作り、つなぐ先の基幹システムの側で、そのアカウントに付ける権限を段階に合わせて限ります。画面を操作する型でも、権限を決めるのは操作されるシステムの側です。

設定の手順は、各社の公式資料で確かめてください。どの製品も仕組みが改定されることがあるので、表の行は導入のたびに最新の資料と突き合わせます。

渡した後は、期限と記録で権限を見直す

権限を渡した後は何を見直すか。期限と見直し日を台帳に書き、使われない権限と認証情報を定期的に外し、操作の記録で誰の承認か追えるかを確かめます。

AWS は、未使用のユーザー・ロール・アクセス許可・認証情報を定期的に確認して削除するよう勧めています。IPA のガイドラインも、アクセス権限の運用や利用状況を監視する仕組みを整えるよう求めています。

権限を渡す前には、次の5項目を確かめます。1つでも答えられなければ、その時点では渡しません。

1. 専用の実行アカウントか。人のアカウントや共有IDで動かしていないか
2. 付ける権限が、判断表でその処理に付けた段階を超えていないか
3. 上の2段の処理に、誰がどの操作の前に承認するかが決まっているか
4. 台帳に期限と次の見直し日が書いてあるか
5. 操作の記録が残り、どの操作が誰の承認で動いたかを後から追えるか

見直しの日には、記録を見て一度も使われていない権限を外します。処理が増えたときは、増えた処理だけを判断表に足して段階を付け、エージェント全体の権限を広げる形にはしません。

社内の決まりにする順番は、エージェントがする処理の書き出し、判断表での段階づけ、専用アカウントの作成、承認の置き場所、台帳への記入、の順です。決めた段階を開発会社に示し、契約の前に確かめておく質問は、AIエージェントの開発会社を見積の前に何を聞いて選ぶかを整理した記事にあります。

エージェントが個人情報を読む処理や、実行アカウントの管理を開発会社に任せる場合の扱いは、情シスだけで決めずに、法務や個人情報の担当に確かめてください。

公開日：2026年10月