AIエージェントの権限管理。禁止・要承認・信頼範囲の3層で決める

AIエージェントの権限管理を考えるとき、最初に浮かぶのは「AIが何かを実行する前に、毎回人が確認すれば安全だ」という発想だと思います。

ただ、AIが自分でファイルを操作し、外部のサービスにつながって作業を進める場面が増えるほど、毎回の承認はかえって統制を弱くしていきます。
今回は特定の製品の設定手順ではなく、組織としての権限の決め方を整理します。
対象にするのは、コーディング支援や自動化フロー、広告媒体とのMCP接続のように、種類の違うエージェントに共通する考え方です。
軸になるのは、絶対にやらせない操作、必ず人を挟む操作、信頼してよい範囲の3層を、情シスが決めて配る考え方です。

毎回の承認は、回数が増えるほど効かなくなる

毎回確認する統制が弱くなる理由は、「承認疲れ」で説明できます。
何十回も確認を求められると、人は中身を読まずに流れ作業で許可を押すようになります。
Claude Codeの自動モードについてAnthropicが公開したデータでは、ユーザーは提示された確認の97%を承認していました。
1,053人のテスターによる検証では、危険なコマンドを人が見抜けたのは13.6%にとどまり、自動で判定する仕組みのほうは89%を止めています。

しかも人が見抜ける割合は、当初の17%から、50回の確認を過ぎると5%まで下がっていました。
判定する仕組みのほうは、回数が増えても止める割合が変わっていません。
提供元自身による検証なので第三者の評価ではない点は踏まえておく必要がありますが、人の確認が回数とともに劣化する傾向は押さえておきたいところです。

判断できない人に承認させても、統制にはならない

承認疲れがいちばん強く出るのは、AIの利用が非エンジニアに広がっていく場面です。

コマンドの危険性を自分で判断できない人は、「これを実行していいですか？」と聞かれても、判断する材料を持っていません。
結果として内容を吟味せずに許可を押し続けることになり、97%という数字は、まさにこの状態を表しています。
これまでは、危険な操作を止める最後の砦が「現場のユーザーが承認画面で判断すること」でした。
その役割は、製品側に組み込まれた判定の仕組みへと移りつつあり、AIを使う人が増える組織ほど、この変化の意味は大きくなります。

汎用的な危険は製品に任せ、自社固有の事情は情シスが渡す

とはいえ、製品側の仕組みに任せれば何も設定しなくてよいわけではありません。
製品が見ているのは、タスクの範囲を超えた操作や、外部に情報を持ち出そうとする操作のように、どの会社にも共通する危険です。
自社の本番データベースの接続情報がどのファイルにあるか、といった自社固有の事情までは知りません。
また、初期状態では作業中のフォルダなど限られた範囲しか信頼しないので、何も設定しないままだと、社内のストレージへの書き込みまで止まる場面が出てきます。

一言でいうと、汎用的な危険は製品に任せ、自社固有の事情は情シスが設定として渡す役割分担に切り替えます。
情シスの役割は「使わせない」ではなく、枠を決めて配ることに変わります。

1層目｜誰が頼んでも実行させない操作を決めておく

最初の層は、会社として越えられては困る一線です。
「本番環境に触らない」「この経路でデータを外に出さない」のような禁止は、製品の汎用的な判断では守られないので、組織の設定として明示します。
この層に入れた操作は、ユーザーが「これをやって」と明示的に指示しても実行されません。

注意したいのは、「絶対にやらせない」と「なるべくやらせない」が別物だという点です。
個人が自分の設定で足した許可が、組織側の緩やかな禁止を上回ることがあります。
絶対に越えさせたくない線は、必ずこの1層目に入れておきます。

2層目｜外に出る瞬間と公開の直前にだけ人を挟む

次の層は、自動で進めつつ、要所だけは必ず人が確認する操作です。
外部への反映や公開に近い操作をここに入れておくと、普段の作業は止めずに、外に出る瞬間だけ人が見る運用にできます。
全部を止めるか全部を任せるかの二択にしなくて済むのが、この層を置く意味です。

同じ考え方は、ほかの製品にも入ってきています。
Google Workspace Studioでは、外部にデータを共有するステップで利用者の確認を必須にできるようになりました。
広告の分野でも、MetaのMCP経由で作成した広告は既定で一時停止の状態になり、人が有効化しない限り配信されない設計になっています。
現場から「自動で進むのは不安だ」という声が上がったときも、この2層目を厚くすれば折り合いをつけられます。

3層目｜自社の「信頼してよい範囲」を教えておく

最後の層は、製品が初期状態では知らない、自社の正常な業務の範囲です。
自社のソース管理、社内のドメイン、業務で使うクラウドストレージ、社内システムなどを登録しておくと、それらへの操作は外部への持ち出しと判断されなくなります。
ここを空けたままだと社内の正常な業務まで止まり、「このエージェントは使いものにならない」という評価になりかねません。
最初から完璧に埋める必要はなく、止められた場面を見ながら足していけば十分です。

つなぐ先ごとに、AIから何ができるかも確認しておきます。
広告媒体の公式MCPでは、Meta・TikTok・Amazonが読み書きに対応している一方、Googleは読み取りのみです。
同じ「MCP接続」でも、つなぐ先によって書き込める範囲が違います。

全社の設定は情シスが持ち、プロジェクトの作法は現場が書く

3層を決めたら、どこに置くかと、誰が書くかも決めておきます。
会社として配る設定は、組織向けの管理設定に置きます。
プロジェクトの中の設定ファイルから信頼範囲を読み込まない製品があるのは、紛れ込んだ設定で勝手に許可を広げられないようにするためです。
一方で、プロジェクトごとの作法は現場が方針ファイルに書く、という分担にすると、全社の枠と現場の事情を両立できます。

あわせて確認したいのが、すでに動いているものの扱いです。
Workspace Studioでは、新しい統制機能の中核が新規作成したフローにのみ適用され、既存のフローは管理画面に出てこないので、今のうちに棚卸しが要ります。
もうひとつ、組織としてまとめて設定を配れるのはチーム向け・法人向けのプランで、個人プランのまま業務に使われていると、情シスには統制をかける手段がありません。

ローカルの開発環境で緩めてよい範囲の決め方は内製環境の権限設定をどう整えるか。安全と速度を両立させる、使い始めの設定はClaude Codeを社内で使い始める。初期設定と安全設計にまとめています。

自社固有の線引きを一緒に決める

どの操作を1層目に入れ、どこで人を挟むかは、扱っているデータや業務の流れによって答えが変わります。
私たちのAI導入支援でも、ガイドラインの策定とあわせて、エージェントに渡す禁止と承認の範囲を情シスの方と一緒に決めています。
現場から自動化の相談が増え始めているなら、枠を先に決める材料にしていただけると思います。

統制の強さは、承認の回数ではなく枠の置き方で決まる

AIエージェントの権限管理は、人が毎回確認する形から、枠を決めて配る形へと切り替わっています。
汎用的な危険は製品に任せ、絶対にやらせない操作、外に出る瞬間の確認、信頼してよい範囲の3層を、情シスが自社の事情に合わせて決めます。

ガイドライン全体の中でエージェントの扱いをどう書くかは、生成AIの社内ルールの作り方。ガイドラインの項目サンプルと守れる環境の項目立てに沿って足していくと整理しやすくなります。
最初の一歩は、社内でエージェントを使っているのが誰で、今どのプランとどの設定で動いているのかを一覧にするところです。