自律的に動くAIエージェントに社内システムの権限をどこまで渡すか。最小権限の原則、読み取り専用から始める段階設計、危険操作の承認ゲート、監査ログの残し方を、権限マトリクスの例とともに情シス・セキュリティ担当向けに整理します。
AIエージェントを社内で動かし始めると、多くの情シス・セキュリティ担当がまず不安に感じるのは「勝手に何かを消したり、外部に送ったりしないか」という点だと思います。この不安は感覚的なものではなく、権限設計の観点から見ると理にかなった懸念だと考えられます。というのも、エージェントの事故の多くは、モデルが悪意を持ったからではなく、与えられた権限が広すぎたために、誤解や誤生成がそのまま実行されてしまうという構造から生まれるからです。
従来のシステム連携では、処理は人間が書いた手続きに沿って決まった範囲でしか動きませんでした。ところが自律的に動くエージェントは、状況に応じて「次に何をするか」を自分で選びます。この柔軟性が価値である一方、選択肢の中に「本番データの削除」「外部への送信」「設定の書き換え」といった危険な操作が含まれていれば、判断を一つ誤っただけで取り返しのつかない結果につながる可能性があります。つまり、エージェントに渡した権限の集合が、そのまま「起こりうる最悪の事故の範囲」になると考えたほうがよいということです。
導入初期にありがちなのが、検証を早く進めたい一心で、社内の主要システムに管理者相当のアクセスキーをエージェントへ渡してしまうパターンです。人間の担当者にはあれほど慎重に権限を絞っているのに、エージェントに対しては「試すだけだから」と広い権限を一括で付与してしまう——この非対称が、後から見ると最も危ういポイントになりがちだと考えられます。試験環境ならまだしも、そのまま本番につないだ状態で放置されると、リスクが積み上がっていきます。
エージェント設計の議論は、つい「何ができるか（能力）」に集中しがちです。しかしセキュリティ設計として先に決めるべきは「何をさせないか（境界）」のほうだと考えます。能力は後から足せますが、一度広げた権限で起きた事故は後から取り消せません。人間の従業員に対して職務分掌とアクセス権を設計するのと同じ発想を、エージェントという新しい「実行主体」に対しても適用する必要があると考えられます。この考え方の土台には、社内AIエージェント全体のリスクをどう捉えるかという視点があり、社内AIエージェントのガバナンスとリスク管理の観点と合わせて設計すると整理しやすいはずです。
本記事では、情シス・セキュリティ担当が「エージェントに与える権限の設計基準」を自社で作れるように、(1)最小権限の原則をエージェントにどう当てはめるか、(2)読み取り専用から始める段階設計、(3)危険操作の承認ゲート、(4)監査ログの残し方、(5)具体的な権限マトリクスの例、という順で整理します。特定の製品やクラウドサービスに依存しない、設計の考え方を中心に述べます。個別の実装は自社の環境と現物で検証することを前提としてお読みください。
最小権限（least privilege）は情報セキュリティの古典的な原則で、「各主体には、その職務を果たすのに必要最小限の権限だけを与える」という考え方です。人間のアカウント設計では広く使われてきた原則ですが、AIエージェントに対しては、むしろ人間以上に厳格に適用すべきだと考えられます。理由は、エージェントが人間より速く・大量に・休みなく操作を実行できるからです。誤った操作も同じ速度で拡大しうるため、権限の絞り込みが事故の上限を決める最も効果的なレバーになります。
権限設計の初期値は「原則すべて拒否、必要なものだけ明示的に許可（deny by default）」に置くことをおすすめします。逆に「原則許可、危ないものだけ止める」という設計にすると、想定していなかった操作経路が抜け穴として残りやすく、事故のたびに個別対応を積み増すことになりがちです。最初は不便に感じても、「本当に必要な操作」がタスクの中で明らかになった時点で一つずつ許可を足していくほうが、結果として統制の効いた状態を保ちやすいと考えられます。
エージェントごとに権限を個別付与すると、数が増えたときに誰が何をできるのか把握できなくなります。人間のアカウント管理と同様に、「請求書処理エージェント」「社内問い合わせ応答エージェント」といった役割単位で権限セットを定義し、そのロールをエージェントに割り当てる形にすると、棚卸しや権限見直しがしやすくなります。ロールを分けておけば、あるエージェントで問題が起きたときに、そのロールだけを即座に停止・縮小するといった対応も取りやすくなります。
最小権限を実装するうえで最も効くのが、読み取り権限と書き込み権限を別のものとして扱うことだと考えます。多くの業務タスクは「情報を集めて要約・提案する」までで価値の大半が出ており、実際にシステムを更新する部分は全体のごく一部です。読み取りだけでもかなりの範囲を任せられるケースは多く、書き込みは慎重に、承認を挟んで段階的に開放していくのが現実的だと考えられます。この分離が、次章で述べる段階設計の土台になります。
権限は「そのシステムにアクセスできる／できない」の二値だけでなく、対象範囲まで含めて絞ると精度が上がります。たとえば顧客データベースへの読み取りでも、特定部門の担当分だけ、直近◯か月分だけ、特定のカラム（列）だけ、といった形でスコープを限定できると、仮に誤動作しても影響範囲が閉じます。どの情報にアクセスさせてよいか自体の線引きは、生成AIに入れてよい情報・いけない情報の線引きの考え方とも重なる部分が多く、権限スコープと入力ルールをセットで設計すると一貫性が出ると考えられます。
いきなり本番の書き込み権限を渡すのではなく、権限を段階的に開放していく設計が現実的だと考えられます。ここでは一例として、4つのフェーズに分けた昇格モデルを示します。各フェーズには「できること」だけでなく「次に進むための条件（昇格条件）」と「必要な監査ログ」をひも付けておくことが要点です。フェーズは自社の業務リスクに合わせて増減させて構いません。
最初の段階では、エージェントに一切の実行権限を渡さず、「こうすればよい」という提案文やドラフトを出させるだけにとどめます。生成された内容はすべて人間が確認し、実際の操作は人間が手で行います。この段階は一見遠回りに見えますが、エージェントがどんな判断をしがちか、どこで誤りやすいかを実データで観察できる貴重な期間になります。ここで蓄積した「エージェントの癖」の理解が、後の権限開放の判断材料になります。
提案の質が安定してきたら、社内ナレッジ基盤やデータ集約基盤に対する読み取り権限を付与します。エージェントが自分で必要な情報を取りに行けるようになるため、提案の精度と自動化の範囲が一気に広がります。この段階でも書き込みは一切許可しません。読み取り対象のスコープ（部門・期間・列）は前章の考え方で絞り込み、「どのデータを何回参照したか」をログに残せる状態にしておきます。多くの業務では、このフェーズだけで実用的な価値が得られるケースも少なくないと考えられます。
次に、影響が限定的で復旧しやすい書き込み操作だけを開放します。たとえば、下書きの作成、社内メモの追記、ステータスのタグ付け、通知の下書き送信（人が最終送信）などです。判断基準は「間違えても容易に取り消せるか」「外部や本番の基幹データに不可逆な影響を与えないか」です。この段階では、書き込みのたびに変更前後の差分をログへ残し、誰でも後から追えるようにしておくことをおすすめします。
本番データの更新・削除、外部への送信、金銭に関わる操作、権限設定の変更といった危険操作は、最後の段階で、かつ必ず人間の承認ゲートを挟む形でのみ開放します。この段階に至っても「無条件の自動実行」は避け、実行の直前に人が内容を確認して承認する運用を基本にすべきだと考えられます。どの操作を承認必須にするか、誰が承認するかは、次章の承認ゲート設計で具体化します。任せる範囲と承認ポイントの切り分けについては、AIエージェントに任せる範囲と人の承認ポイントの設計も合わせて参照すると、フェーズ間の線引きがより具体的になるはずです。
各フェーズ間の昇格を、担当者の感覚や現場の要望だけで決めないことが大切だと考えます。「フェーズ1で◯週間、重大な誤りゼロ」「読み取りログのレビューを実施済み」といった客観的な条件を先に決めておき、それを満たしたら次へ進む、という運用にすると、権限拡大の判断に一貫性が生まれます。逆に問題が起きたら一段階戻す（降格する）ルートも用意しておくと、暴走の芽を早期に摘みやすくなります。
段階設計の最終盤で鍵になるのが、危険操作に対する承認ゲート（human-in-the-loop）です。承認ゲートとは、エージェントが特定の操作を実行しようとしたときに処理を一時停止し、人間が内容を確認して「実行してよい／だめ」を判断する仕組みです。設計の要点は「何を止めるか」「誰が承認するか」「承認そのものをどう記録するか」の三点だと考えられます。
すべての操作に承認を求めると運用が回らなくなり、逆に承認が形骸化します。承認必須にすべきは、(1)取り消しが難しい不可逆な操作（削除・確定・送信）、(2)影響範囲が広い操作（一括更新・設定変更）、(3)外部や金銭に関わる操作、に絞るのが現実的だと考えます。逆に、下書き作成や読み取りのような可逆・低影響の操作まで承認を挟むと、人の負荷ばかり増えて効果が薄れます。分類の基準を明文化し、どの操作がどのカテゴリに入るかを一覧化しておくとよいでしょう。
承認のかけ方には、(a)危険操作は毎回人が承認する、(b)一定の条件（金額・件数・対象範囲）以内なら自動、それを超えたら承認、という二段構えがあります。導入初期は(a)を基本にし、運用が安定してデータが溜まってきたら、明らかに安全と確認できた範囲だけ(b)へ緩めていく、という進め方が無難だと考えられます。閾値（しきい値）は自社の業務リスクに合わせて設定し、定期的に見直すことをおすすめします。
承認者は、その操作について本来責任を持つ人であるべきです。エージェントが介在しても、金銭処理は経理の承認権限者、データ削除はデータ管理責任者、という既存の職務分掌を崩さないことが重要だと考えます。エージェント導入を機に「とりあえず情シスが全部承認」としてしまうと、業務内容を理解していない人が形式的に承認するだけになり、ゲートの意味が薄れます。承認は業務を分かっている人に、というのが原則です。
承認依頼が多すぎると、人は内容をよく見ずに承認するようになります。これは承認ゲートを設けても事故が防げなくなる、実務上よくある落とし穴です。対策としては、承認が必要な操作を前述のとおり本当に危険なものに絞ること、承認画面に「何を・どのデータに対して・なぜ実行しようとしているか」を分かりやすく提示すること、承認の頻度をモニタリングして多すぎる場合は設計を見直すこと、が挙げられます。承認は数を絞ってこそ機能すると考えられます。
「誰が・いつ・何を承認したか」も監査ログに残すべき対象です。承認記録がないと、事故が起きたときに「なぜこの操作が通ったのか」を後から検証できません。承認ゲートは止める仕組みであると同時に、責任の所在を明確にする記録の仕組みでもある、と捉えると設計がぶれにくくなると考えられます。
最小権限と承認ゲートで事故の範囲を絞ったうえで、それでも何かが起きたときに「何が起きたのか」を正確に再構成できることが、統制の最後の砦になります。それを担うのが監査ログです。エージェントの監査ログは、単なる動作記録ではなく、「後から第三者が経緯を追える」ことを目的に設計する必要があると考えられます。
最低限記録したいのは、いつ（タイムスタンプ）、どのエージェント／ロールが、どのシステムに対して、どの操作を、どんな入力・パラメータで実行し、その結果どうなったか、です。加えて、その操作を引き起こした指示（プロンプトやトリガー）と、承認が必要な操作であれば承認者と承認時刻も残します。読み取りについても「どのデータにアクセスしたか」を記録できると、情報漏えいの調査時に役立ちます。要は、ログだけを見れば一連の流れを再現できる状態を目指します。
監査ログは、記録した本人（エージェントやその運用者）が後から書き換えられない場所に保存することが望ましいと考えます。エージェント自身にログの削除・編集権限を与えないのは当然として、ログの保存先は業務システムとは分離し、書き込み専用に近い形で蓄積するのが理想です。保存期間も、社内規程や関連法令・ガイドラインを踏まえてあらかじめ決めておくとよいでしょう。ログ管理と監査の全体設計については、生成AI利用ログの管理と監査で扱う考え方が、エージェントのログ設計にもそのまま応用できると考えられます。
ログは蓄積するだけでは意味がなく、定期的にレビューして初めて統制として機能します。すべてを人が見るのは現実的でないため、異常なパターン（想定外のシステムへのアクセス、深夜の大量操作、承認なしの書き込み試行など）を検知したらアラートを上げる仕組みと、定期的なサンプリングレビューを組み合わせるのが現実的だと考えられます。「取っているが誰も見ていないログ」は、事故が起きてから初めて開かれることになりがちです。
詳細なログを残すほど調査はしやすくなりますが、ログ自体に個人情報や機微情報が含まれると、今度はログの保護が新たな課題になります。ログには必要な範囲だけを記録し、機微な入力値はマスキングや参照IDへの置き換えを検討するなど、「調査に必要な粒度」と「秘匿すべき情報の保護」のバランスを取る設計が求められると考えられます。ここは自社のデータ分類ルールと突き合わせて詰めることをおすすめします。
ここまでの原則を、情シス・セキュリティ担当が実際に使える形に落とし込むのが権限マトリクスです。権限マトリクスとは、「どのロールのエージェントが」「どのシステムに」「どの操作を」「承認あり／なしで」実行できるかを一覧化した表です。以下に、考え方が伝わるように簡略化した例を示します。数値や社名を含まない、構造の例としてご覧ください。
まず縦軸に「エージェントのロール」、横軸に「対象システム×操作種別」を置きます。操作種別は、読み取り（R）／低リスク書き込み（W-low）／危険操作（W-high）の三段階に分けると扱いやすいと考えます。各セルには「不可」「可（自動）」「可（承認必須）」のいずれかを記入します。空欄（不可）を初期値にして、必要なところだけ埋めていくのが最小権限の実装そのものです。
権限マトリクスは一度作って終わりではなく、フェーズ昇格・降格、新しいエージェントの追加、事故を受けた見直しのたびに更新する、生きた文書として運用することをおすすめします。定期的な権限棚卸し（誰が何をできる状態か）の基準表としても機能します。マトリクスがあることで、「このエージェントはなぜこの権限を持っているのか」を後から説明できる状態になり、監査対応や責任分界の議論もしやすくなると考えられます。
マトリクスを埋める前に、そもそも自社にとって「絶対に触られたくないシステム・データ」は何かを洗い出しておくことが土台になります。基幹の受発注、顧客の個人情報、金銭処理、権限設定——こうした守る対象を先に明確にしておくと、どこに承認ゲートを厚く置くべきかが自然と決まります。権限設計は技術論に見えて、実は「何を守りたいか」という業務・経営の意思決定と地続きだと考えられます。
最後に、ここまで述べた権限設計を自社に根づかせるための進め方を整理します。ポイントは、完璧な基準を机上で作り込もうとせず、小さく始めて現物で検証しながら育てることだと考えます。エージェントの挙動もツール側の仕様も変化が速い領域であり、一度決めた基準を固定するより、見直しの仕組みごと設計するほうが実態に合うと考えられます。
権限設計は、認証・アクセス制御といった技術面と、職務分掌・承認責任といった業務面の両方をまたぎます。情シス・セキュリティだけで閉じず、実際にエージェントを使う業務部門と一緒に「どの操作を任せてよいか」を詰めることで、現場で形骸化しない基準になると考えられます。ツール固有の設定（権限の付け方や課金・仕様の細部）は変わり得るため、最新は各サービスの公式情報を確認しながら進めることをおすすめします。
私たちNsightは、産業用の画像検査・VLMの領域で、元キーエンス画像処理事業部出身の技術者の現場知見をもとに「まず現物で確かめる」ことを重視してきました。検査という、誤りが即座に不良流出や過検出につながる領域で培ったこの規律は、AIエージェントの権限設計にも通じると考えています。すなわち、カタログ上の理屈だけで安全性を判断せず、自社の実データ・実業務でエージェントを小さく動かし、ログと承認記録を見ながら権限を一段ずつ確かめていく——この地道な検証こそが、暴走を防ぐ最も確実な道だと考えます。社内AIエージェント基盤の権限設計や段階導入について、自社の状況に合わせて一緒に検証したいという場合は、お気軽にご相談ください。設計基準は、机上ではなく現場で育てるものだと考えています。
初期値は「原則すべて拒否、必要なものだけ許可」に置き、実運用では読み取り専用から始めることをおすすめします。多くの業務は情報を集めて提案するまでで価値の大半が出るため、書き込み権限は挙動を観察しながら段階的に開放するのが現実的だと考えられます。いきなり管理者相当の権限を渡すのは、事故の上限を自ら広げる行為になりがちです。
すべてにかけると承認が形骸化し、逆に事故を招きます。承認必須にすべきは、取り消しが難しい不可逆な操作、影響範囲の広い操作、外部や金銭に関わる操作に絞るのが現実的です。可逆・低影響の操作は自動実行とし、承認は本当に危険なものだけに集中させることで、承認する人が内容をきちんと確認できる状態を保てると考えられます。
いつ・どのエージェントが・どのシステムに・どの操作を・どんな入力で実行し・結果どうなったか、という5W1Hを揃えるのが基本です。加えて、操作のきっかけとなった指示と、承認が必要な操作なら承認者・承認時刻も残します。ログだけを見れば一連の流れを再現できる状態を目指し、エージェント自身が書き換えられない場所に保存することが望ましいと考えられます。
情シス・セキュリティが主導しつつ、実際にエージェントを使う業務部門と一緒に作ることをおすすめします。どの操作を任せてよいか、誰が承認責任を持つべきかは業務を理解していないと判断できないためです。技術面（アクセス制御）と業務面（職務分掌）の両方をまたぐ設計なので、片方だけで作ると現場で形骸化しやすいと考えられます。
まず「絶対に触られたくないシステム・データ」を洗い出し、その上で提案のみ、または読み取り専用の範囲に限定した業務でエージェントを試すのがおすすめです。ログを取りながら挙動を観察し、エージェントが誤りやすい箇所を把握してから、権限マトリクスと承認ゲートを作り込む——この順序だと、実態に合った基準を無理なく育てられると考えられます。
最小権限・段階設計・承認ゲート・監査ログ——自社の業務とシステムに合わせた権限設計の基準づくりを、小さな検証から一緒に進めます。元キーエンス画像処理事業部出身の技術者の現場知見を踏まえ、机上ではなく現物で確かめる進め方をご提案します。
権限設計について相談する