AIエージェントを安全に使うための権限と確認

執筆:石田 誠更新 2026-11-12最終確認 2026-11-12出典 4件図解 2点

この記事の結論

AIエージェントは、持たせる道具・権限・自律性を必要な分だけに絞り、取り消しにくい操作の前に人の承認を入れ、権限の判断をAIではなく連携先のシステムの側で行うと、安全に使いやすくなります。

自社の「基盤とセキュリティ」の準備度は?10問・約3分で確かめる(無料・登録不要)

AIエージェントは、指示を受けてメールの下書き、表の更新、社内システムの検索などを自分で進める仕組みです。便利な一方で、AIが誤った判断をしたときに、実際の操作まで進んでしまうおそれがあります。この記事では、海外の専門団体と国内の公的機関の資料をもとに、権限と確認の決め方を整理します。

この記事でわかること

  • AIエージェントで事故が起きる仕組みと、3つの原因
  • 権限を絞り、人の承認を入れる具体的な手順
  • 記録と見直しで、運用を続ける方法

AIエージェントでは、何が起きやすいのですか?

アプリケーションのセキュリティの専門団体OWASPは、大規模言語モデル(LLM)を使う仕組みの主なリスクの一つに「過剰な権限(Excessive Agency)」を挙げています。AIが予想外の出力や、あいまいな出力、細工された出力を返したときに、それをもとに害のある操作をしてしまう問題です。

原因は、AIの事実と異なる出力(ハルシネーション)でも、細工した文章で指示を上書きする攻撃(プロンプトインジェクション)でもかまいません。影響の大きさは、AIがどのシステムに手を伸ばせるかで決まります。

OWASPは、この問題の原因を次の3つに分けています。

原因内容例
道具が多すぎる必要のない機能までAIが使える読むだけでよいのに、書き込み・削除の機能もつながっている
権限が広すぎる連携先で必要以上の操作が許されている参照だけでよいのに、管理者の権限で接続している
自律性が高すぎる影響の大きい操作を、人の確認なしに実行できる社外へのメール送信を、承認なしで行える

AIエージェントの事故の大きさを左右する3つの原因

過剰な権限の問題予想外・あいまい・細工された出力をもとに、害のある操作をしてしまう
=
道具が多すぎる必要のない機能までAIが使える
権限が広すぎる連携先で必要以上の操作が許されている
自律性が高すぎる影響の大きい操作を、人の確認なしに実行できる

影響の大きさは、AIがどのシステムに手を伸ばせるかで決まります。3つを必要な分だけに絞ることが対策の出発点です。

IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの3位に「AIの利用をめぐるサイバーリスク」が入っています。AIエージェントは、こうしたリスクが実際の操作につながりやすい使い方といえます。

権限は、どのように絞ればよいですか?

OWASPと総務省の資料が挙げる対策をもとに、権限を絞る手順をまとめます。

① つなぐ道具を必要なものだけにします。 業務に使わない機能や連携先は外します。何でもできる汎用の道具(コマンドを自由に実行できる機能など)より、目的を絞った道具を選びます。

② 連携先での権限を最小限にします。 データベースを参照するだけなら、読み取り専用の権限で接続します。総務省のガイドラインの別添も、AIと連携して操作を実行する仕組み(オーケストレーター)を管理者の権限ではなく最小の権限で動かすことや、データベースの権限を必要な操作に限ることを挙げています。

③ 利用者本人の権限の範囲で動かします。 AIエージェントが誰の代わりに動いているかをはっきりさせ、その人に許された範囲を超えないようにします。共用の強い権限のアカウントは避けます。

④ 権限の判断を、連携先のシステムで行います。 OWASPは、操作を許すかどうかの判断をAIに任せず、連携先のシステムの側で行うこと(完全な仲介)を挙げています。「この操作はしないで」とAIに指示するだけでは、止める仕組みになりません。

IPAの「AIセキュリティ短信 2026年9月号」も、統制はプロンプトではなく道具を呼び出す層で強制すべきとする指針や、道具の呼び出しを原則として拒否し、必要なものだけを許す設計を紹介しています。同じ号では、MCP(AIと外部のシステムをつなぐ共通の仕組み)による接続を無制限に許可している企業が約14%あるとする海外の調査も紹介されています。接続先は必要なものだけに絞っておくと安心です。

人の承認は、どこに入れればよいですか?

OWASPは、影響の大きい操作の前に人の承認を求めること(ヒューマン・イン・ザ・ループ)を対策に挙げています。総務省のガイドラインの別添も、実行のたびに利用者の承認を求める方法に触れています。

すべてに承認を入れると、使う意味が薄れます。次のように、操作の影響で分けて決めるのが目安です。

操作の種類例扱いの目安
読むだけ社内資料の検索、要約任せる。参照できる範囲は絞る
下書きをつくるメール・提案書の下書き任せる。送る前に人が確かめる
取り消しにくい送金、データの削除、社外への送信、権限の変更実行の前に人が承認する

操作の影響で分ける、人の承認の入れ方(目安)

  • 読むだけ社内資料の検索・要約は任せる。参照できる範囲は絞る
  • 下書きをつくるメール・提案書の下書きは任せる。送る前に人が確かめる
  • 取り消しにくい送金・データの削除・社外への送信・権限の変更は、実行の前に人が承認する

すべてに承認を入れると、使う意味が薄れます。承認する人が内容を確かめられるよう、宛先・金額・対象のデータを示す設定にしておくと安心です。

承認する人が内容を確かめられるように、AIが何をしようとしているのか(宛先、金額、対象のデータ)を承認の画面に示す設定にしておくと安心です。

AIに読ませる情報には、何を気をつければよいですか?

AIエージェントは、メールやWebページ、共有フォルダの文書を読みながら作業を進めます。その中に細工した指示が隠されていると、AIが意図しない操作をすることがあります(間接プロンプトインジェクション)。

IPAの「AIセキュリティ短信」は、読み込んだ内容に由来する値を使う道具の呼び出しを制限することや、一つの入力ではなく一連の流れで不審な動きを見つけることを挙げる報告を紹介しています。社外から届く情報を読ませる使い方では、読ませた後にできる操作を少なくしておくと、被害を抑えやすくなります。

記録と見直しは、どのように続ければよいですか?

OWASPは、記録(ログ)、監視、回数の上限は過剰な権限の問題そのものを防ぐものではないものの、被害を抑えられるとしています。次の点を運用に組み込みます。

① 記録を残します。 AIエージェントが、いつ、誰の依頼で、どの道具を使い、何をしたかを残します。

② つないでいる先の一覧をつくります。 コネクタ(接続先)や、AIに渡したAPIキー(システムにつなぐための鍵)を一覧にし、使っていないものは外します。IPAの「AIセキュリティ短信」も、接続の棚卸しや、事故の際に資格情報を無効にすることを挙げる報告を紹介しています。

③ 止め方を決めておきます。 おかしな動きを見つけたときに、誰がどの手順でAIエージェントを止め、鍵を無効にするかを決めておきます。

④ 定期的に見直します。 記録を見て、使われていない権限は外し、承認が形だけになっていないかを確かめます。

チェックリスト

関連するひな形・ガイド・用語

よくあるご質問

QAIへの指示(プロンプト)で「削除はしないこと」と書いておけば十分ですか?

A指示だけに頼るのは避けたほうが安心です。AIは誤った出力や、細工された文章による指示の上書きを受けることがあります。削除をさせたくない場合は、そもそも削除の権限を渡さない、連携先のシステムの側で拒否する、といった仕組みで止めるのが基本です。

Q人の承認を入れると、AIエージェントを使う意味が薄れませんか?

Aすべての操作に承認を入れる必要はありません。読むだけの操作は任せ、送金・削除・社外への送信のような取り消しにくい操作に絞って承認を入れると、手間を抑えながら安全性を高められます。運用の記録を見て、承認の範囲を見直していきます。

QAIエージェント専用のアカウントは必要ですか?

A社員の管理者アカウントをそのまま使わせるより、用途ごとに権限を絞ったアカウントや、利用者本人の権限の範囲で動く設定を用意するほうが、誰が何をしたかを追いやすくなります。使っている製品で選べる方式を確かめて決めます。

QMCPで社内のシステムにつなぐときの注意点は何ですか?

Aつなぐ先(コネクタ)を必要なものだけに絞り、一覧にして定期的に見直します。IPAの「AIセキュリティ短信」は、接続コネクタの棚卸しを対策に挙げる報告や、MCPによる接続を無制限に許可している企業が約14%あるとする海外の調査を紹介しています。

この記事に出てくる用語

「基盤とセキュリティ」のほかの記事

この柱の解説 →

出典

  1. OWASP Top 10 for LLM Applications 2025「LLM06:2025 Excessive Agency」
  2. 総務省「AIのセキュリティ確保のための技術的対策に係るガイドライン 別添(付属資料)」(令和8年3月)
  3. 独立行政法人情報処理推進機構(IPA)「AIセキュリティ短信 2026年9月号(公開版)」
  4. IPA「情報セキュリティ10大脅威 2026」(プレスリリース、2026年1月29日)

最終確認日:2026-11-12

次の一歩