AIエージェントのガバナンスとは？権限設計と監査ログで暴走を防ぐ実装手順

AIエージェントのガバナンスとは？従来のAIガバナンスと何が違う？

AIエージェントのガバナンスとは、AIが自分の判断で行う「行動」を、権限と記録によって管理する仕組みです。

これまでのAIガバナンスは、生成AIの出力が正確か、偏りがないか、著作権を侵していないかといった「出力の品質」を主に扱ってきました。AIエージェントは違います。LLMが計画を立て、ツールを呼び出し、社内システムやSaaSを実際に操作します。そのため、ガバナンスの対象が「何を言ったか」から「何をしたか」へ広がります。

管理する対象が「出力」から「行動」へ移る

従来の生成AIは、人が出力を確認してから使えば済みました。AIエージェントは、人が確認する前に外部システムを操作してしまいます。

チャット型の生成AIでは、誤った回答があっても人が読んだ時点で止められました。AIエージェントは、メール送信、チケット更新、データベースへの書き込み、決済APIの呼び出しまでを一連の流れで実行します。誤りが表に出たときには、すでに処理が終わっていることがあります。現場では「レビューの関所」がどこにあるのかを先に決めておかないと、PoCの段階で想定外の書き込みが起きる例が少なくありません。

「誰が実行したか」がわかりにくくなる

AIエージェントは人の代わりに動くため、操作ログに残る実行者と、実際に責任を負う人が一致しない問題が起きます。

たとえば、ある社員のアカウント権限を借りて動くAIエージェントが顧客データを更新した場合、ログには社員本人の操作として記録されます。後から調べても、人が操作したのかAIエージェントが操作したのか区別できません。この問題に対応するため、Microsoftは2025年5月に「Microsoft Entra Agent ID」を発表するなど、AIエージェントに専用のIDを持たせる流れが出てきています。ガバナンスの最初の一歩は、AIエージェントを「人とは別の、識別できる主体」として扱うことだと考えられます。

AIエージェントにはどんなリスクがある？

主なリスクは、権限が広すぎること、外部入力による乗っ取り、連鎖的な誤動作、そして後から追跡できないことの4つにまとめられます。

権限が広すぎると被害が大きくなる

AIエージェントの被害の大きさは、モデルの精度よりも、与えた権限の広さで決まる部分が大きいといえます。

OWASPの「Top 10 for LLM Applications 2025」は、このリスクを「LLM06: Excessive Agency（過剰な主体性）」としてまとめています。原因は次の3つに分けて説明されています。

1. 必要以上の機能を持つこと（Excessive Functionality）
2. 必要以上の権限を持つこと（Excessive Permissions）
3. 必要以上の自律性を持つこと（Excessive Autonomy）

実務では「読み取りだけのつもりが、接続したAPIキーに書き込み権限まで付いていた」というように、ツール側の権限設定が原因になることがよくあります。モデルを評価するのと同じくらい、接続先の権限を見直すことが重要です。

外部からの指示による乗っ取りと、誤動作の連鎖

AIエージェントは外部の文書やWebの情報を読み込むため、そこに仕込まれた指示によって行動を乗っ取られるおそれがあります。

この攻撃は「間接プロンプトインジェクション」と呼ばれます。受信したメールや参照したWebページに「この内容を外部に送信せよ」といった指示が埋め込まれていると、LLMがそれを正規の指示と取り違えることがあります。RAGで社内文書を検索する構成でも、文書の中身が信頼できるとは限りません。

さらに、複数のAIエージェントが連携する構成では、1つのエージェントの誤りが次のエージェントへの入力となり、誤りが広がる恐れがあります。モデル側の対策だけでは防ぎきれないため、「外部入力を含む処理では、書き込み系のツールを使わせない」など、構成の段階で防ぐ方法が現実的です。

AIエージェントのガバナンスはどんな階層で設計する？

ガバナンスは「方針」「権限」「実行時の制御」「監査」の4階層に分けて設計すると、抜け漏れを防ぎやすくなります。

権限設計は最小権限とエージェント専用IDが基本

権限設計の基本は、AIエージェントごとに専用のIDを発行し、業務に必要な最小限のツールとデータだけを許可することです。

具体的には、次の点を確認します。

• 人のアカウントを使い回さず、AIエージェント専用のサービスアカウントやIDを発行する
• 使えるツールを許可リストで明示する（「禁止リスト」方式は抜けが出やすい）
• 読み取りと書き込みでツールやAPIキーを分ける
• アクセストークンは有効期限を短くし、作業ごとに範囲を絞る
• AnthropicがAIエージェントとツールの接続方式として2024年11月に公開したMCP（Model Context Protocol）を使う場合も、MCPサーバーごとに公開するツールを制限する

接続の仕組みが標準化されるほど、ツールをつなぐ作業は簡単になります。そのぶん「つなげるから全部つなぐ」という状態になりやすい点には注意が必要です。

実行時の制御は、リスクの高さに応じて人の承認を挟む

すべての操作に人の承認を求めると現場が回らなくなります。リスクの高さで段階を分け、高リスクの操作だけを承認制にするのが実用的です。

あわせて、1回の作業あたりのツール呼び出し回数の上限、API利用料の上限、全体をすぐに止められる停止スイッチを用意しておくと、誤動作が連鎖したときの被害を抑えられます。

監査ログは「入力・判断・行動・結果」をひと続きで残す

監査ログは、ツールを実行した記録だけでは足りません。何を受け取り、どう判断し、何をして、どうなったかをひと続きで追える形で残します。

ログには個人情報や機密情報が含まれやすいため、マスキング、保存期間、閲覧権限もあわせて決めておく必要があります。現場の感覚では、ログを取ること自体よりも「誰がいつ見返すのか」を決めていないために形だけになる失敗のほうが多いようです。

AIエージェントのガバナンスはどう導入する？

導入は、棚卸し、リスク分類、権限設計、ログ整備、段階的な拡大の5ステップで進めるのが現実的です。

1. 棚卸し：社内で使われている、または検討中のAIエージェントと、その接続先システムを一覧にする
2. リスク分類：業務への影響とデータの機密度から、リスクを低・中・高・最高に分ける
3. 権限設計：専用IDを発行し、ツールの許可リストを作り、承認が必要な操作を決める
4. ログ整備：監査ログの項目、保管場所、見直しの頻度を決める
5. 段階的な拡大：読み取り専用から始め、運用実績を確認しながら書き込み権限を広げる

まず社内のAIエージェントを棚卸しする

最初にやるべきなのは規程づくりではなく、社内でどのAIエージェントが何につながっているかを把握することです。

SaaSに組み込まれたAIエージェント機能や、ノーコードツールで現場が自分で作ったワークフローなど、情報システム部門が把握していない「シャドーAIエージェント」が見つかることは珍しくありません。棚卸しの表には、少なくとも次の項目を入れます。

• 名前
• 担当部門
• 使っているモデル
• 接続しているシステム
• 権限
• 責任者

この表が、その後のリスク分類と監査の基礎になります。

小さく始め、権限を段階的に広げる

最初から広い権限を与えず、読み取り専用で始めて、運用の実績を確認しながら権限を広げる方法が安全です。

最初の段階では「調べる・まとめる・下書きを作る」までをAIエージェントに任せ、最後の実行は人が行います。一定期間ログを見直して、誤った判断の傾向や承認で差し戻した割合を確認できてから、中リスクの操作を自動化する、という順番で進めます。権限を広げる判断の基準を事前に文書にしておくと、「便利だからなんとなく広げた」という事態を防げます。ただし、適切な期間や基準は業務によって異なるため、各社の状況に合わせた調整が必要です。

国内外のガイドラインはAIエージェントをどう扱っている？

国内外の主要なガイドラインは、AIを人の監督下に置くことを前提に、責任の分担と記録の保存を求めている点で共通しています。

国内：AI事業者ガイドラインとAI推進法が土台になる

国内では、総務省と経済産業省の「AI事業者ガイドライン」が実務の土台です。AIエージェントについても、このガイドラインの責任分担の考え方を当てはめるのが基本になります。

AI事業者ガイドラインは、関係者を「AI開発者」「AI提供者」「AI利用者」の3つに分け、それぞれが取り組むべき事項を整理しています。AIエージェントを社内に導入する企業は、多くの場合「AI利用者」にあたります。ただし、自社で組み立てて社内外に提供するなら「AI提供者」の立場も持ちます。拘束力のないソフトローですが、取引先から確認を求められる場面は増えています。改訂のたびにAIエージェントに関する記述が拡充されているため、最新版を確認することをおすすめします。2025年5月に成立したAI推進法は、事業者への罰則を中心とした規制法ではなく、国の推進体制を定める法律です。

海外：EU AI Actは監督と記録、シンガポールはAIエージェント専用の枠組み

海外では、EU AI Actが高リスクAIに人による監督とログの保存を義務づけています。シンガポールはAIエージェントに特化した枠組みを公表しています。

EU AI Actは2024年8月に発効し、禁止されるAIの規定は2025年2月から、汎用AIモデルの義務は2025年8月から適用されています。高リスクAIに関する義務については、2025年11月に欧州委員会が「デジタル・オムニバス」で適用時期の延期を提案しています。EU域内で事業を行う企業は最新の状況を確認する必要があります。NIST AI RMFとISO/IEC 42001はAIエージェント専用ではありませんが、本記事の4階層（方針・権限・実行時の制御・監査）を組織の管理の仕組みに組み込む際の参照先として使えます。シンガポールIMDAの枠組みは、AIエージェントのリスク評価、人の責任の明確化、技術的な制御、利用者への説明責任といった観点を整理しています。社内規程の項目を洗い出す際のチェックリストとして役立つでしょう。

ガイドラインに共通するメッセージは「AIに任せても、責任は人に残る」ということです。権限設計と監査ログは、その責任を果たせる状態を技術的に支える手段だといえます。

主な参照資料：OWASP「Top 10 for LLM Applications 2025」、総務省・経済産業省「AI事業者ガイドライン」、欧州連合「AI Act（Regulation (EU) 2024/1689）」、NIST「AI Risk Management Framework 1.0」「NIST AI 600-1」、ISO/IEC 42001:2023、シンガポールIMDA「Model AI Governance Framework for Agentic AI」

姉妹メディアの関連記事