Askhub
資料請求 お問い合わせ
お問い合わせ

ナレッジ

AIエージェントは誰の権限で動くのか｜ID・代理実行・社内検索の落とし穴

「本人の権限で動きます」だけでは足りない

「AIは本人の権限で動くので、本人が見られないものは見えません」
AIの導入を社内に諮るとき、多くの方がこう説明していると思います。

正しい出発点です。
でも、それだけでは情シスの審査に答えきれないと、私たちは考えています。

たとえば、経営企画が過去の経営会議の資料や社内規程をAIに探させ、要点をまとめさせたい。
管理部門が、月末に各部の実績を集める集計を、AIに夜のうちに回させたい。

こうした相談には、情シスからほぼ必ず3つの問いが返ってきます。
AIは誰の権限で動くのか。人がいない定期実行や、外部のAIから呼ばれたときも同じか。
AIの操作と人の操作を、記録でどう見分けるのか。
社内検索で、人事評価や役員向けの資料が回答に混ざらないか。

「本人の権限で」は、どれにも答えきれません。
本人が控えていた操作まで、AIはできてしまいます。記録では、人とAIの区別がつきません。本人の権限が実態より広ければ、AIはその分まで拾います。

では、どうすればよいか。
私たちの答えは、3つです。AIを本人より狭く動かす。AIの操作を人の操作と区別して記録する。鍵（認証情報）をAIに見せない。
この3つがそろえば、「誰の権限で、誰がやったのか」を情シスにも監査にも説明できます。

AIエージェントの権限管理とは、AIが誰の代わりに、どの範囲まで操作してよいかを、人とは別に決めて記録することです。

まずは、なぜ本人の権限そのままでは広すぎるのかから考えます。

人は使わないだけ。AIは全部使う

経理の担当者は、請求書を書き換える権限を持っています。
それでも、入金のない請求書を「消込済」にはしません。業務の知識と社内規程が、行動を権限より狭くとどめているからです。

しかも本人の権限は、たいてい仕事より広いものです。異動前の部署のフォルダが、そのまま残っていたりします。
人は使わないだけですが、AIは使えるものをすべて使います。

OWASP（国際的なセキュリティ団体）も、2025年12月に公開したAIエージェント向けのリスク一覧で、これを主なリスクの一つに挙げています。AIに人の権限をそのまま貸すことです。
AIが自分のIDを持たず、利用者のログイン状態を借りる。記録上は本人の操作に見える。以前の作業で得た許可を、別の利用者の依頼でも使い回す。権限の低い側の依頼を、高い側がそのまま実行する。最後のものは「混乱した代理人」と呼ばれます。

同じ一覧は、作業に必要な分だけの自律性と権限を与える「最小の主体性」を基本に据えています。対策は、AIごとに管理されたIDを持たせること。作業ごとに、短い時間だけ使える狭い許可を出すことです。

そこで私たちは、AIが実際にできることを「実効の権限」として決めます。
本人の権限と、その経路に許した上限の重なりのことです。本人は書き込めても、外部のAI経由では読むだけ、という形です。
画面からの本人の操作は、本人の権限そのまま。会話のAIは、結びつけた業務の範囲だけ。外部のAIは、管理者が許した範囲だけ。

ここで大事なのは、判定を1か所にまとめることです。
経路ごとに判定の仕組みを別々に作ると、どれかに抜けが生まれます。入口で「誰の代わりか」と「上限」に置き換え、その先は同じ判定を通します。

実効の権限 · 4つの経路と1つの判定
4つの経路の違いは入口で「誰の代わりか」と「上限」に置き換えられ、許すかどうかは同じ1か所の判定で決まります。

ただ、狭く動かしても、記録で見分けられなければ説明はできません。

記録には「AIがやった」と残す

AIが本人のアカウントでそのまま操作すると、記録には本人の名前しか残りません。
集計表の数字が書き換わっていたとします。本人とAIのどちらが、どの指示で直したのか。誰が承認したのか。
これに答えられなければ、監査でも調査でも行き詰まります。

だから、監査で聞かれる問いから逆算して残す項目を決めます。
誰の代わりに動いたか。本人か、会話の持ち主か、定期実行を設定した人か。
実際に操作したのはどのAIで、どの会話・どの実行か。外部からなら、どのアプリか。
その経路に許していた上限。読むだけか、書き込めるか。
入力と根拠と結果。つまり、判断ログです。
そして、承認した人と、その承認がどの経路から来たか。

最後の「どの経路から」は見落としがちです。
承認はメールやチャットからもできます。経路が残っていれば、転送されたメールを別の人が押した場合も検証できます。
記録をAIが書き換えられない形で保つ方法は、AIエージェントの監視と停止で扱います。

AIに専用のIDを与える考え方は、大手のプラットフォームでも採られ始めています。記録上の主体は利用者、実行したのはAIとして分けて残す形です（例：Microsoft Entra Agent ID。2026年10月時点）。
まずは、使う製品の記録に上の項目が残るかを確かめてください。

記録の形が決まったら、次は経路ごとの決め方です。
画面以外の経路は、「誰の代わりか」の決め方がそれぞれ違います。

経路ごとに「誰の代わりか」を決める

外部のAIからつなぐとき

手元の生成AIから社内システムを呼ぶ方法として、MCP（AIと外部のツールをつなぐ公開仕様）が広がっています。
ただ、仕様が決めるのは許可の受け渡しまでです。その利用者が何をしてよいかは、業務システムの側が決めます。

だから、外部のAIからつなぐときも、管理者が許したアプリだけ、許した範囲だけにします。
社員が手元のAIに、社内システムへの接続を勝手に同意してしまうこともあります。社員のIDを管理する仕組み（IdP）で、利用者の同意を制限し、管理者の承認を必須にもできます。

AI同士の依頼

問い合わせ対応のAIが、支払いを扱うAIに「この口座に返金して」と依頼したとします。
受けた側が自分の権限でそのまま実行すれば、本来は許されない操作が通ってしまいます。

依頼を受けた側は、依頼元のAIではなく、大元の利用者の権限で判定し直します。
そのために、依頼には「誰の代わりか」を添えて渡します。

月末の定期集計と、承認後の再開

人がいない処理は、共通の管理者アカウントや、設定者の古い許可で動かしがちです。
すると、設定者が異動・退職しても動き続けます。

月末の集計なら、「誰の代わりか」を設定した担当者に固定します。
そして、毎月の実行のたびに、その時点の権限で判定し直します。
担当者が異動して集計対象の部署を見られなくなれば、AIもその部署のデータを集めなくなります。外部のAIへの委任も、IDが無効になったときに一緒に失効させます。

全社の集計のように、特定の利用者がいない処理もあります。その場合は共通のIDも選択肢です。
ただし、そのAI専用のIDにして範囲を絞り、責任者を決めます。人の代わりに動く処理には使いません。

経路の話でいちばん気になるのは、おそらく社内検索だと思います。

社内検索は、検索する前に絞る

社内検索AIは、文書を検索し、その内容をもとに回答を作ります（RAGと呼ばれる仕組みです）。
権限の確認が抜けると、人事の評価資料や役員会の資料が拾われ、要約されて回答に混ざります。

OWASPのLLMアプリ向けリスク一覧（2026年8月公開）も、検索の仕組みの弱点をリスクの一つに挙げています。対策は、権限を理解する検索とデータの分割です。
この記事の時点で調べた範囲では、これによる漏えいとして公表された事故は見当たりませんでした。
ただ、起きても気づきにくい。そして、大手ベンダー自身が導入前の備えを案内しています。

漏れる原因は、2つに分かれます。

1つ目は、仕組みの問題です。権限を確かめる位置が遅い。
全社の文書をまとめて検索し、AIに渡す前に権限で絞る作りでは、絞り込みの漏れがそのまま回答に混ざります。
安心なのは、検索を始める前に、利用者の権限で検索の範囲を決める作りです。

社内検索で権限を確かめる位置 · 後で絞るか、前で決めるか
左は取り除きに漏れがあれば回答に混ざり、右は見られない文書がそもそも検索されません。元の共有しすぎは、どちらでも残ります。

2つ目は、元の権限の問題です。共有しすぎ。
言葉にすると当たり前に聞こえます。でも、仕組みが正しくても、ここは残ります。
「全社員」に共有された人事のフォルダがあれば、AIはそれを正しく拾うからです。

マイクロソフトも、Microsoft 365 Copilotは利用者が少なくとも閲覧できるデータだけを表示すると明記しています。
そのうえで、SharePointの既定の共有設定はもっとも緩いと書いています。共有しすぎを見つける報告や、サイトを検索から外す機能も、導入前の備えとして案内しています。

米国のIT情報サイトPetriは、こんな例を挙げています。技術的には開けるが、一度も開いたことのない賞与の表。それが「給与の傾向をまとめて」という依頼で、要約に出てくる。
人は探さなければ見つけません。
AIは、探すことが仕事です。

だから、共有設定の棚卸しは、仕組みとは別の仕事として進めます。
「全社員」への共有。匿名リンク。持ち主のいないフォルダ。これらを洗い出し、人事・経営・法務などの文書は、棚卸しが終わるまで検索対象から外しておきます。
棚卸しが終わった領域から順に加えていけば、最初から全社で始めなくても効果は出せます。

見せる範囲を絞ったら、残るのは鍵です。

鍵は「使える」けれど「知らない」

AIが外部のサービスを使うには、APIキーやトークンといった鍵が要ります。
よくある置き場所は3つあり、どれも見つかる前提で考える必要があります。

AIへの内部の指示文。指示文は、引き出されることがあります。「教えないで」と書いても、守られる保証はありません。
公開しているアプリの中。アプリを解析されれば、鍵は取り出されます。
AIが動く環境の設定ファイル。AIが書いたコードや、乗っ取られたAIが鍵を読み出し、外へ送れます（プロンプトインジェクションとは？防げない前提の対策と確認8項目）。

OWASPの2026年版も、指示文に埋め込まれた資格情報を「見つかるもの」として扱っています。秘密を置かないこと、認可の唯一の手段にしないことを求めています。
日本でも、JPCERT/CC（日本のセキュリティ対応の調整機関）が2026年10月15日に、連続不正アクセス事案の調査を公表しました。APIの認証に使う秘密鍵や、有効期間の長い認証情報を、アプリに埋め込まないよう求めています（相次ぐ不正アクセスはなぜ止まらない？原因と今すぐ確かめる8項目）。

原則はシンプルです。
AIは鍵を「使える」。でも、値は「知らない」。
鍵は基盤やシークレット管理の仕組みが預かり、AIには作業ごとに短い時間だけ使える許可を渡します。AIが任意のコードを実行する環境の守り方は、プロンプトインジェクションとは？の記事で扱います。

ここまでの話には、1つの共通点があります。

許すかどうかは、AIの外で決める

許すかどうかの判定を、AI自身にさせないことです。
プログラムが、自分の権限を強制する仕組みを迂回したり、改ざんしたりできてはならない。情報セキュリティで古くから言われてきた原則です。

社員のIDを管理する仕組み（Entra ID、Oktaなど）は、「誰が何者か」と「どのアプリに委任できるか」を決めます。
でも、「この文書を検索に含めてよいか」を判定するのはアプリです。
実際には、IDの管理とアプリの中での判定を組み合わせて使います。統制を置く場所の選び方はAIエージェントの権限設計で整理しています。

では、どこから手を付ければよいでしょうか。

最初は、経路を書き出すところから

最初の一歩は、経路の洗い出しです。
画面、定期実行、外部のAI、AI同士。それぞれで「誰の代わりに動くか」を書き出します。書けない経路があれば、それが最初の課題です。

次に、経路ごとの上限を狭く決めます。外部のAIは読むだけ。書き込みは、業務操作と承認を通す。
業務操作は、「入金を消し込む」のような記録を変える操作の単位です（AIエージェントの権限設計）。実績を見て広げる方法は、AIエージェントの承認はどの粒度で？承認疲れと自動承認ルールで扱います。

社内検索は、棚卸しが終わった領域から対象に加えます。
そして、記録の見本を用意しておきます。1件の操作を記録だけで辿れる実例。異動・退職のあとに、許可が失効した記録。これを見せられれば、情シスとの話は早く進むはずです。

もちろん、運用に残る仕事もあります。
元の権限の棚卸しは、定期的な仕事になります。どの外部アプリに何を許すかは会社の判断で、AIごとに責任者を決めておきます。記録を読む監視はAIエージェントの監視と停止、責任の分け方はAIエージェントの責任は誰が負う？システムと運用の責任分界で扱います。

導入がスムーズに進みやすいAIの選び方

次の基準を満たすAIなら、情シスへの説明が短く済み、導入がスムーズに進みやすくなります。

  • 誰の代わりに動いたかと、どのAIかを分けて記録する
  • 社内検索は、検索の前に利用者が見てよい範囲に絞る
  • 定期実行は、実行のたびにその時点の権限で判定し直す
  • AIから鍵の値が見えない

導入審査の準備の全体は、AIエージェントの導入審査をスムーズに通すには？推進担当の準備と選び方にまとめています。

情シスに説明するときの要点

  • AIができることは「本人の権限」と「その経路に許した上限」の重なりで、本人より広くはなりません
  • AIの操作は人の操作と区別して記録され、誰の代わりに、どのAIが、誰の承認で動いたかを辿れます
  • 社内検索は検索の前に見てよい範囲に絞り、人事・経営の資料は共有設定の棚卸しが終わるまで対象外にします
  • 月末の定期集計などは実行のたびに権限を判定し直すので、担当者の異動・退職にも追随します
  • 鍵はAIに見せず、AIは鍵の値を知らないまま使います

狭く始めれば、任せる範囲は広げられる

「本人の権限で動きます」は、出発点にすぎません。
AIは、使えるものをすべて使うからです。

だから、本人より狭く動かす。人の操作と区別して記録する。定期実行は、そのたびに権限を判定し直す。
社内検索は検索の前に範囲を決め、鍵はAIに値を知らせない。

始めるのは、棚卸しの済んだ領域の社内検索や、読み取りと集計だけの定期実行からで十分です。
「誰の権限で、誰がやったか」を説明できる形さえ作れば、AIに任せる範囲は、実績に合わせて広げていけます。
私たちは、そう確信しています。

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

AIを誰かの代わりに動かすとき気になるのは、使う経路によって権限が広がらないか、乗っ取られたAIが「誰の代わりか」まですり替えないか、の2点です。Askhubでは、画面からの操作も、会話のAIも、外部のAIツールからの呼び出しも、「誰の代わりに・どの範囲で」という同じ形に置き換えます。そのうえで、サーバー側の同じ判定を通します。AIが誰の代わりにどの範囲で動いているかはサーバーが決めて封をし、AIの側からは書き換えられません。社内文書の検索でも、検索の前に、その人が見てよい文書に範囲を絞ります。ログインはMicrosoft Entra IDなどのシングルサインオンに対応し、接続元のIPアドレスもワークスペースごとに制限できます。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連する機能：外部ツール連携、ナレッジ検索（RAG）

ナレッジの記事をもっと見る