部署ごとにAIエージェントが増え、監査部門から「誰が権限を承認し、誰が止めるのか」と問われて答えに詰まっていないでしょうか。本記事では、AIエージェントのガバナンスで決めるべき6つの要素と、体制づくりから社内規程までの構築手順を、公的ガイドラインに沿って解説します。
Microsoft 365 Copilotのエージェントや、Difyで作った社内エージェントが、気づけば部署ごとに動いている。生成AIの利用ガイドラインは作ったものの、メール送信やファイル更新まで自動で行う前提には対応していない。情シスやDX推進の担当者は、このような状況で統制ルールづくりを求められがちです。
AIエージェントのガバナンスとは、エージェントの権限・責任・停止手段を組織として定め、継続的に監督する仕組みです。曖昧なまま展開すると、誤操作が起きたときに責任の所在を説明できず、統制を急に厳しくすれば現場はシャドーAIに流れます。
本記事では、従来のAIガバナンスとの違いを押さえたうえで、決めるべき6要素と6ステップの構築手順を中心に解説します。AI事業者ガイドライン第1.2版など、2026年の最新動向も整理しました。
読み終えるころには、社内規程と導入審査の叩き台を作り、経営や監査からの問いに根拠をもって答えられる状態になっているはずです。
目次
AIエージェントのガバナンスとは
AIエージェントのガバナンスを理解するには、以下の3つの観点で整理するとわかりやすくなります。
- AIエージェントのガバナンスの定義
- 従来のAIガバナンスとの違い
- セキュリティ対策や運用管理との違い
違いを押さえておくと、既存の規程に何を足せばよいかが見えてきます。
AIエージェントのガバナンスの定義
AIエージェントのガバナンスとは、エージェントに「何をどこまで任せ、誰が責任を持ち、どう止めるか」を組織として決めて監督する仕組みです。
総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」は、AIエージェントを定義しています。特定の目標を達成するために環境を感知し、自律的に行動するAIシステムという位置づけです。自律的に行動する以上、出力の正しさだけでなく、行動の範囲と責任を管理する必要があります。
具体的には、以下のような取り決めがガバナンスの対象です。
- エージェントが接続できるシステムと操作できる範囲
- 導入を承認する人と、日々の挙動に責任を持つ人
- 人間の確認を必須にする操作と、記録として残す情報
- 問題が起きたときの停止と復旧の手順
これらを文書と仕組みの両面で決めておけば、現場は迷わずエージェントを使え、管理部門は説明責任を果たせます。
従来のAIガバナンスとの違い
従来のAIガバナンスとの最大の違いは、統制の対象が「出力」から「行動」に移る点です。
ChatGPTのような対話型の生成AIでは、回答を読んだ人間が使うかどうかを判断します。一方、AIエージェントは回答を作るだけでなく、メール送信やデータ更新といった操作まで自ら実行します。
| 観点 | 従来のAIガバナンス | AIエージェントのガバナンス |
|---|---|---|
| 主な統制対象 | 出力の正確性・公平性 | 実行する操作と権限 |
| 人間の関与 | 出力を読んで人間が判断 | 人間を介さず複数の操作が連続 |
| 主なリスク | 誤情報・偏り・著作権 | 誤操作・権限の悪用・連鎖的な障害 |
| 必要な記録 | 入力と出力 | ツール呼び出し・参照データ・実行結果 |
| 止め方 | 利用をやめればよい | 実行中の処理を止める仕組みが必要 |
この違いを踏まえると、既存の生成AIガイドラインに権限・承認・停止のルールを追加することが、AIエージェントのガバナンスの出発点になります。
セキュリティ対策や運用管理との違い
AIエージェントのガバナンスは、セキュリティ対策や運用管理の上位にある「決める仕組み」です。
セキュリティ対策は、プロンプトインジェクションや情報漏えいといった脅威を技術的に防ぐ取り組みを指します。運用管理は、ログ監視や品質評価など、稼働中のエージェントを日々見守る業務です。
これに対してガバナンスは、どの脅威をどこまで許容するか、誰が運用の責任を負うかといった方針と権限を定めます。たとえば「顧客へのメール送信は課長承認を必須にする」と決めるのがガバナンスで、承認フローをシステムに実装するのがセキュリティや運用の役割です。
役割の違いを整理しておけば、情シス・法務・業務部門のどこが何を担うかで議論が空回りしにくくなります。
AIエージェントのガバナンスが今求められる3つの理由
AIエージェントのガバナンスが急いで求められている理由は以下の3つです。
- エージェントの判断がそのまま業務の実行になるから
- 責任の所在が曖昧なまま導入が広がっているから
- 国内外でエージェント向けのルール整備が進んでいるから
いずれも経営層や監査部門に必要性を説明するときの根拠として使えます。
エージェントの判断がそのまま業務の実行になるから
1つ目の理由は、AIエージェントの誤りが、人間の確認を経ずに業務上の事故になるためです。
AI事業者ガイドライン第1.2版の別添では、自律的に動くAIエージェントが人間の意図しない商品の注文やファイル削除を行う可能性を指摘しています。外部システムとの連携を通じて攻撃を受け、内部データが漏えいするおそれにも触れています。
対話型AIなら誤った回答は読んだ人が気づけますが、エージェントは誤った判断のまま次の操作へ進みます。権限が広いほど、1回の誤りがそのまま被害の大きさに直結します。
事前に任せる範囲と確認ポイントを決めておけば、誤りが起きても被害を小さく抑えられます。
責任の所在が曖昧なまま導入が広がっているから
2つ目の理由は、エージェントの作成が容易になり、管理されないエージェントが社内に増えているためです。
Microsoft Copilot StudioやDifyを使えば、業務部門の担当者でもエージェントを作れます。その結果、誰が作り、どのシステムに接続し、誰が保守しているかを情シスが把握できない状態が生まれやすくなります。
作成者が異動や退職をすると、権限を持ったまま持ち主のいないエージェントが残ります。事故が起きたとき「誰の責任か」を説明できなければ、経営や監査からの信頼を失うでしょう。
Gartnerは、エージェント型AIプロジェクトの40%超が2027年末までに中止されると予測しています。要因として挙げたのは、コストの高騰、事業価値の不明確さ、不十分なリスク管理です。責任と統制を先に設計することが、投資を無駄にしない条件といえます。
出典：Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027（Gartner）
国内外でエージェント向けのルール整備が進んでいるから
3つ目の理由は、2026年に入り、AIエージェントを名指しした公的ルールが相次いで出ているためです。
主な動きは以下のとおりです。
- 2026年1月：シンガポールがAIエージェント向けのガバナンス枠組みを公表
- 2026年3月：総務省・経済産業省がAI事業者ガイドライン第1.2版でAIエージェントへの対応を追記
- 2026年5月：EUが高リスクAIの義務の適用時期を見直す合意に到達
日本のガイドラインは法的拘束力を持ちませんが、取引先や監査法人がAI管理体制を確認する際の基準として参照されます。海外拠点や海外顧客を持つ企業は、EU AI Actへの対応も視野に入れる必要があります。
公的ルールに沿って体制を整えておけば、外部から説明を求められたときに根拠をもって回答できます。各ルールの詳細は後半の見出しで解説します。
AIエージェントのガバナンスで決めるべき6つの要素
AIエージェントのガバナンスでは、以下の6つの要素をエージェントごとに決めます。
- 自律度：どこまで任せるか
- 権限：何にアクセスさせるか
- ID：エージェントを誰に紐づけるか
- 承認：どこで人間が判断するか
- 記録：何をログに残すか
- 停止：どう止めて元に戻すか
6つのうち1つでも欠けると、事故が起きたときに原因の特定や責任の説明ができなくなります。
自律度：どこまで任せるか
最初に決めるのは、エージェントに人間の確認なしでどこまで実行させるかという自律度です。
自律度によって必要な統制の強さが変わるため、すべてのエージェントに同じルールを当てはめると、過剰か不足のどちらかになります。たとえば以下の4段階で区分すると判断しやすくなります。
- 提案のみ：下書きや候補を作り、実行は人間が行う
- 承認後に実行：人間が承認した操作だけを実行する
- 範囲内で自動実行：決められた範囲は自動で実行し、人間が事後に確認する
- 自律実行：目標だけを与え、手段の選択も任せる
導入初期は1〜2段階目から始め、実績を見ながら段階を上げるのが安全です。段階ごとに求める統制を規程に書いておけば、新しいエージェントの審査も迷わず進められます。
権限：何にアクセスさせるか
権限では、業務に必要な最小限のシステムとデータだけにアクセスさせることを原則にします。
エージェントに与えた権限は、そのまま誤操作や乗っ取りが起きたときの被害範囲になります。作成者本人の権限をそのまま流用すると、本来不要な人事データや経理システムまで触れる状態になりかねません。
決めるべき項目は以下のとおりです。
「参照中心から始め、更新・削除・外部送信は個別に審査する」と決めておくと、権限の付けすぎを防ぎながら導入を進められます。
ID：エージェントを誰に紐づけるか
IDの要素では、エージェントごとに固有のIDを発行し、責任者となる人間を紐づけます。
複数のエージェントが共通のサービスアカウントで動いていると、ログを見てもどのエージェントの操作か区別できません。人間の社員と同じように、エージェントにも「誰か」がわかる身元が必要です。
Microsoftの「Microsoft Entra Agent ID」は、エージェントに固有のIDを割り当て、スポンサーと呼ばれる責任者を設定できます。Google Cloudも、エージェントごとに固有のIDを発行する「Agent Identity」を提供しています。
責任者を紐づけておけば、作成者が異動したときに引き継ぎ先を決める運用も回せます。持ち主のいないエージェントを残さないことが、統制の土台になります。
承認：どこで人間が判断するか
承認の要素では、取り消せない操作や影響の大きい操作の前に、人間の判断を必ず挟むポイントを決めます。
すべての操作に承認を求めると、確認作業が形だけになり、エージェントを使う意味も薄れます。承認は、失敗したときに元に戻せない操作に絞るのが現実的です。
人間の承認を必須にすべき操作の例は以下のとおりです。
- 顧客や取引先など社外への送信
- 支払い・発注・契約などお金や法的効果が伴う操作
- データの削除や本番環境の設定変更
- 権限の付与や変更
承認者と承認期限まで決めておけば、承認待ちで業務が止まる事態も防げます。
記録：何をログに残すか
記録の要素では、エージェントが「何を見て、何を判断し、何を実行したか」を後から追えるログを残すことを決めます。
入力と出力だけでは、エージェントがどのツールをどの順番で呼び出したかがわかりません。事故の原因調査や監査対応には、行動の過程まで含めた記録が必要です。
残すべき項目は以下のとおりです。
- エージェントIDと、指示を出した利用者
- 参照したデータや文書
- 呼び出したツールと引数、実行結果
- 人間の承認の有無と承認者
ログには個人情報が含まれやすいため、マスキングの方法と保存期間も合わせて決めておきましょう。記録が揃っていれば、監査で問われたときに事実をもとに説明できます。
停止：どう止めて元に戻すか
停止の要素では、異常が起きたときに誰が、どの手段で、どこまで止めるかを事前に決めます。
AIエージェントは人間より速く操作を繰り返すため、異常に気づいてから止め方を考えていては被害が広がります。停止の権限を持つ人が不在で対応が遅れるケースも想定しておく必要があります。
決めておくべき項目は以下のとおりです。
- 停止を判断できる人と、その代行者
- エージェントの無効化や認証情報の失効など、止める手段
- 停止を発動する条件
- データや設定を元に戻す手順と、関係者への連絡先
停止手順を一度訓練しておけば、本番の事故でも慌てずに被害を最小限に抑えられます。
AIエージェントのガバナンス体制と役割分担
AIエージェントのガバナンス体制は、以下の4者で役割を分担して作ります。
- 経営層とAIガバナンス委員会の役割
- エージェントオーナーの役割
- 情シス・セキュリティ部門の役割
- 法務・内部監査部門の役割
情シスだけに任せると統制が技術に偏り、業務部門だけに任せるとリスク判断が甘くなるため、分担を明文化することが重要です。
経営層とAIガバナンス委員会の役割
経営層とAIガバナンス委員会は、AIエージェント活用の方針と、許容するリスクの水準を決める役割を担います。
どこまでの自律実行を認めるか、どの業務には使わないかといった判断は、部門単位では決めきれません。全社の方針として決める場がないと、部門ごとに基準がばらつきます。
AIガバナンス委員会は、情シス・法務・リスク管理・主要な業務部門の責任者で構成し、四半期ごとなど定期的に開くのが一般的です。高リスクに分類したエージェントの導入可否や、規程の改定もこの場で承認します。
経営層が委員会の決定に責任を持つ形にしておくと、現場は「会社として認められた使い方」として安心して活用できます。
エージェントオーナーの役割
エージェントオーナーとは、個々のエージェントの業務成果と日々の挙動に責任を持つ業務部門の担当者です。
エージェントがどの業務で何をすべきかを最もよく知っているのは、実際にその業務を担う部門です。作った人が責任を持つのではなく、部門として責任者を指名しておくと、異動や退職があっても管理が途切れません。
エージェントオーナーの主な役割は以下のとおりです。
- エージェントの目的と利用範囲を定義する
- 導入時のリスク評価に業務の観点から参加する
- 出力や実行結果を定期的に確認し、不具合を報告する
- 不要になったエージェントの廃止を申請する
エージェントオーナーを台帳に明記しておけば、問題が起きたときの最初の連絡先がすぐに特定できます。
情シス・セキュリティ部門の役割
情シス・セキュリティ部門は、決めたルールを技術的な仕組みとして実装し、全社のエージェントを可視化する役割を担います。
規程に「最小権限」と書いても、IDと権限の設定で担保しなければ守られません。エージェントの台帳管理、ID発行、ログ基盤、停止手段の整備は、システムを管理する部門でなければ対応できない領域です。
また、利用を認めたプラットフォーム以外で作られたエージェントを検知することも重要です。シャドーAIを見つけた場合は、禁止するだけでなく正規の申請ルートへ誘導します。
情シスが「止める部門」ではなく「安全に使える環境を用意する部門」として動くことで、現場の協力を得やすくなります。
法務・内部監査部門の役割
法務・内部監査部門は、法令や契約への適合を確認し、ルールが実際に守られているかを独立した立場で点検する役割を担います。
AIエージェントは個人情報を扱ったり、取引先と連絡を取ったりするため、個人情報保護法や業法、契約上の守秘義務に触れる場面があります。法務はこうした論点を導入審査の段階で確認します。
内部監査は、台帳とログをもとに、承認フローが形だけになっていないか、権限が放置されていないかを定期的に点検します。業務部門と情シスが「実行する側」、法務と監査が「確認する側」に分かれることで、チェックが機能します。
監査結果を委員会に報告して規程の改定につなげれば、ガバナンスを一度作って終わりにせず改善し続けられます。
AIエージェントのガバナンスを構築する6ステップ
AIエージェントのガバナンスは、以下の6ステップで構築します。
- ステップ1：社内のエージェントを棚卸しして台帳を作る
- ステップ2：自律度とリスクでエージェントを分類する
- ステップ3：社内規程と利用基準を定める
- ステップ4：承認フローとガードレールを実装する
- ステップ5：段階的に展開して挙動を監視する
- ステップ6：定期監査で規程を見直す
現状の把握を飛ばして規程から作ると、実態に合わないルールになりやすいため、順番を守って進めましょう。
ステップ1：社内のエージェントを棚卸しして台帳を作る
最初のステップは、社内で動いているAIエージェントをすべて洗い出し、台帳にまとめることです。
何体のエージェントがどこにあるかわからなければ、統制の対象も決められません。各プラットフォームの管理画面に加え、業務部門へのアンケートで、個人が作ったエージェントも拾い上げます。
台帳に記載する項目は以下のとおりです。
- エージェント名と利用目的
- エージェントオーナーと作成者
- 利用しているプラットフォームとAIモデル
- 接続先のシステムと権限の範囲
- 扱うデータの機密区分と利用者数
台帳は以降のステップすべての土台になります。新規作成時に台帳登録を必須にするルールも、このタイミングで決めておきましょう。
ステップ2：自律度とリスクでエージェントを分類する
台帳ができたら、自律度と業務への影響の大きさで、エージェントをリスク区分に分類します。
社内文書を検索して要約するだけのエージェントと、顧客に請求書を送るエージェントでは、求められる統制がまったく違います。区分を作ることで、統制の強さにメリハリをつけられます。
たとえば以下の3区分に分けると運用しやすくなります。
| 区分 | 該当するエージェントの例 | 求める統制 |
|---|---|---|
| 低リスク | 社内文書の検索・要約、議事録の下書き | 台帳登録と利用ルールの遵守 |
| 中リスク | 社内システムへの登録、社内向けメール送信 | 部門長の承認、ログの定期確認 |
| 高リスク | 社外への送信、支払い・発注、個人情報の更新 | 委員会の審査、操作ごとの人間承認、停止訓練 |
評価の観点は、自律性・権限・可逆性の3つが基本です。区分ごとの統制を決めておけば、審査にかかる時間を低リスクのエージェントでは短く、高リスクでは慎重にと使い分けられます。
ステップ3：社内規程と利用基準を定める
分類ができたら、AIエージェントの社内規程と、区分ごとの利用基準を文書化します。
既存の生成AI利用ガイドラインを全面的に作り直す必要はありません。エージェント特有の項目を追加する形で整備すると、社内の承認も得やすくなります。
社内規程に盛り込む主な項目は以下のとおりです。
- 目的と適用範囲、エージェントの定義
- 体制と役割分担、エージェントオーナーの責任
- リスク区分と区分ごとの審査・承認手続き
- 権限・承認・記録・停止に関する必須ルール
- 禁止事項と違反時の対応
- インシデント発生時の報告ルートと規程の改定手続き
規程は「禁止事項の一覧」にせず、どの条件を満たせば使ってよいかを明記することが重要です。条件が明確なら、現場は申請すれば使えると理解し、シャドーAIに流れにくくなります。
ステップ4：承認フローとガードレールを実装する
規程ができたら、ルールをシステムの設定として実装し、人の注意力に頼らない状態にします。
「社外送信の前に承認を取る」と規程に書いても、エージェントが技術的に送信できてしまえば、いずれ守られなくなります。ガードレールとは、エージェントが決められた範囲の外に出ないよう、システム側で行動を制限する仕組みです。
実装する主な仕組みは以下のとおりです。
- エージェント専用のIDと最小権限の設定
- 高リスクな操作の前に人間の承認を求めるワークフロー
- 許可していないツール呼び出しを止めるポリシー
- 行動の過程まで残すログ基盤と、即時に止める停止スイッチ
後述する各社のエージェント管理ツールを使えば、これらの多くを既存のID基盤と連携して実装できます。
ステップ5：段階的に展開して挙動を監視する
仕組みが整ったら、低リスクのエージェントと限られた部門から段階的に展開します。
AIエージェントの挙動は、テスト環境では問題がなくても、実際の業務データや想定外の指示で変わることがあります。いきなり全社に広げると、問題が起きたときの影響範囲も大きくなります。
展開の各段階では、誤った実行の件数、承認で差し戻された件数、停止の発動回数などを確認します。次の段階に進む条件を事前に決めておけば、「なんとなく広げる」状態を避けられます。
段階ごとの結果は委員会に報告し、自律度を上げてよいかの判断材料にします。実績をもとに任せる範囲を広げれば、現場と管理部門の双方が納得したうえで活用を拡大できます。
ステップ6：定期監査で規程を見直す
最後のステップは、定期的な監査で実態とルールのずれを見つけ、規程を更新し続けることです。
AIモデルの更新や新しいツールとの連携によって、同じエージェントでも挙動やリスクは変わります。公的ガイドラインも改訂が続いているため、作った時点の規程が1年後も適切とは限りません。
監査で確認する主な項目は以下のとおりです。
- 台帳に載っていないエージェントがないか
- オーナー不在や、使われていないエージェントが残っていないか
- 権限が当初の範囲から広がっていないか
- 承認が中身を確認せず通されていないか
監査の結果を規程と統制の改善に反映するサイクルを回せば、ガバナンスが形骸化せず、外部からの確認にも耐えられる体制になります。
AIエージェントの導入審査で使えるチェックリスト
新しいAIエージェントを導入するときは、6つの要素と体制に沿ったチェックリストで審査すると、確認漏れを防げます。
審査の観点が担当者ごとに違うと、同じリスクのエージェントでも承認されたりされなかったりします。チェックリストを申請書の様式にしておけば、申請する業務部門も事前に準備できます。
| 区分 | 確認項目 |
|---|---|
| 目的 | ・利用目的と対象業務が明確か ・エージェントオーナーが指名されているか |
| 自律度 | ・自律度の段階とリスク区分が決まっているか ・人間が確認するタイミングが定義されているか |
| 権限 | ・接続先と操作範囲が業務に必要な最小限か ・扱うデータの機密区分が確認されているか |
| ID | ・エージェント専用のIDが発行されているか ・共有アカウントや個人の認証情報を流用していないか |
| 承認 | ・社外送信・支払い・削除の前に人間の承認があるか ・承認者と代行者が決まっているか |
| 記録 | ・ツール呼び出しと実行結果がログに残るか ・ログの保存期間とマスキング方法が決まっているか |
| 停止 | ・停止手段と判断者が決まっているか ・データを元に戻す手順があるか |
| 法令・契約 | ・個人情報保護や業法上の論点を法務が確認したか ・利用するAIサービスの規約とデータの扱いを確認したか |
低リスクのエージェントは簡易版で審査し、高リスクのエージェントは全項目を委員会で確認するなど、区分に応じて審査の深さを変えると運用の負担を抑えられます。
審査結果と承認日を台帳に記録しておけば、監査でも導入判断の経緯をそのまま提示できます。
AIエージェントのガバナンスで参照すべきフレームワーク5つ
AIエージェントのガバナンスを設計するときに参照したいフレームワークは以下の5つです。
- AI事業者ガイドライン第1.2版
- シンガポールIMDAのエージェント向けガバナンス枠組み
- ISO/IEC 42001
- NIST AI RMF
- EU AI Act
社内規程の根拠として公的な枠組みを示せると、経営層や監査部門の承認を得やすくなります。
AI事業者ガイドライン第1.2版
国内企業がまず参照すべきなのが、総務省・経済産業省が2026年3月31日に公表した「AI事業者ガイドライン（第1.2版）」です。
第1.2版では、AIエージェントやフィジカルAIへの対応が主な更新テーマになりました。AIエージェントの定義に加え、意図しない操作や外部連携を通じた攻撃といったリスクが別添で整理されています。
対策の方向性としては、連携するツールやシステムの制限、人間の判断を介在させる仕組み、適切な権限設定、操作履歴の定期的な確認などが挙げられています。自律性が高まると人間による監視だけでは対応が難しくなる点にも触れています。
別添にはチェックリストとワークシートも用意されているため、自社の規程を作る前の点検表として活用できます。
出典：AI事業者ガイドライン（経済産業省）
シンガポールIMDAのエージェント向けガバナンス枠組み
シンガポールの情報通信メディア開発庁（IMDA）は、2026年1月22日にAIエージェントに特化したガバナンス枠組みを公表しました。名称は「Model AI Governance Framework for Agentic AI」です。
自社開発のエージェントだけでなく、他社製のエージェントを導入する組織も対象にしており、法的拘束力のない任意の枠組みです。推奨事項は以下の4つの柱で構成されています。
- リスクを事前に評価し、エージェントの行動範囲を限定する
- 人間が実質的な責任を負う体制にする
- 技術的な統制とプロセスを実装する
- 利用者自身が責任ある使い方をできるようにする
エージェントに特化した公的枠組みとして先行しているため、日本のガイドラインで足りない具体策を補う参考資料として役立ちます。
出典：Singapore Launches New Model AI Governance Framework for Agentic AI（MDDI）
ISO/IEC 42001
ISO/IEC 42001は、AIを管理する仕組みを組織として整え、第三者の認証も受けられる国際規格です。
ISO/IEC 27001などと同じマネジメントシステムの構造を持つため、情報セキュリティの認証を取得済みの企業は既存の運用に組み込みやすい規格です。社外に対して管理体制を客観的に示せる点が強みです。
国内では三菱電機が2026年10月26日、ISO/IEC 42001の認証取得を発表しました。対象はグループのAI活用を支える「AIエージェント基盤」で、認証機関はSGSジャパンです。企画・開発から運用・改善までを対象に、リスク評価、人による監督、継続的なモニタリングを行う管理の仕組みを構築したとしています。
取引先から管理体制の証明を求められる企業や、AIエージェントを顧客向けサービスに組み込む企業は、認証取得も選択肢に入れるとよいでしょう。
出典：AIマネジメントシステムの国際規格「ISO/IEC 42001」認証を取得（三菱電機）
NIST AI RMF
NIST AI RMFは、米国国立標準技術研究所（NIST）が2023年1月に公開したAIリスク管理の枠組みです。
任意で利用する枠組みで、リスク管理を以下の4つの機能に分けて整理しています。
- Govern：方針・体制・責任を定める
- Map：利用の文脈とリスクを特定する
- Measure：リスクを測定・評価する
- Manage：優先順位をつけて対処する
本記事の6ステップに当てはめると、体制づくりと規程がGovern、棚卸しと分類がMap、監視と監査がMeasureとManageに対応します。米国企業との取引が多い場合は、NIST AI RMFの用語で自社の取り組みを説明できるようにしておくと話が通じやすくなります。なお、NISTは現在このフレームワークの改訂を進めています。
出典：AI Risk Management Framework（NIST）
EU AI Act
EU AI Actは、EU域内でAIを提供・利用する事業者に法的義務を課す規則です。
AIをリスクの大きさで分類し、採用・教育・信用評価などの高リスク用途には、リスク管理・人間による監督・記録の保持などを求めます。日本企業でも、EU域内の顧客や従業員に関わる用途でAIエージェントを使う場合は対象になり得ます。
高リスクAIの義務の適用時期は、2026年5月にEU理事会と欧州議会が合意した見直しにより後ろ倒しになりました。単独で使う高リスクAIは2027年12月2日、規制対象の製品に組み込まれるAIは2028年8月2日からの適用です。
猶予ができたとはいえ、求められる統制は本記事の6要素と重なる部分が多くあります。今のうちに台帳と記録の仕組みを整えておけば、適用開始時の対応負担を軽くできます。
出典：Artificial Intelligence: Council and Parliament agree to simplify and streamline rules（EU理事会）
AIエージェントのガバナンスを支えるツール
AIエージェントのガバナンスを技術面で支える代表的なツールは以下の3つです。
- Microsoft Agent 365・Entra Agent ID
- Amazon Bedrock AgentCore
- Google Cloud Gemini Enterprise Agent Platform
自社が主に使っているクラウドやID基盤に合わせて選ぶと、既存の管理の仕組みと一体で運用できます。
Microsoft Agent 365・Entra Agent ID
Microsoft 365を全社で使う企業なら、Microsoft Agent 365とEntra Agent IDが有力な選択肢です。
Microsoft Agent 365は、IT部門やセキュリティ部門がAIエージェントを管理するためのコントロールプレーンです。社内のエージェントを一覧で把握できるレジストリを備えており、ステップ1の台帳づくりに使えます。
Microsoft Entra Agent IDは、エージェントに固有のIDを割り当て、以下のような管理を可能にします。
- 条件付きアクセスによる高リスクなエージェントのブロック
- スポンサーと呼ばれる責任者の割り当てと維持
- 展開から期限切れまでのライフサイクル管理の自動化
- 疑わしいエージェントの活動の検出と対応
Copilot Studioで作られたエージェントが多い企業は、既存のEntra IDの運用にエージェントを組み込める点が大きな利点です。
>公式サイトはこちらから
Amazon Bedrock AgentCore
AWS上でAIエージェントを開発・運用している企業には、Amazon Bedrock AgentCoreが適しています。
Amazon Bedrock AgentCoreは、エージェントを本番環境で動かすための機能群です。ガバナンスに関係する主な機能は以下のとおりです。
- AgentCore Identity：エージェントのIDとアクセス、認証を管理する
- AgentCore Policy：ツール呼び出しの前に介入し、決めた範囲とルールの中で動かす
- AgentCore Observability：本番環境のエージェントの挙動を追跡・監視する
- AgentCore Registry：エージェントやツールを一元管理し、承認の流れを組み込む
AgentCore IdentityはAmazon Cognito、Okta、Microsoft Entra IDなど既存のIDプロバイダーと連携できます。ステップ4のガードレール実装を、コードではなくポリシーとして管理できる点が特徴です。
>公式ドキュメントはこちらから
Google Cloud Gemini Enterprise Agent Platform
Google Cloudを利用している企業には、Gemini Enterprise Agent Platformのガバナンス機能が選択肢になります。
Gemini Enterprise Agent Platformは、エージェントのライフサイクル全体を管理するための基盤です。プラットフォーム管理者やセキュリティ管理者が一元的に統制できます。ガバナンスに関係する主な機能は以下のとおりです。
- Agent Identity：共有のサービスアカウントの代わりに、エージェントごとに固有のIDを発行する
- Agent Registry：エージェントの接続先を登録して管理する
- Agent Gateway：ツールやエージェントの呼び出しを実行時に制御する
- Model Armor：プロンプトやツールの応答を検査し、攻撃や機密情報の漏えいを防ぐ
明示的に許可した接続以外はすべて拒否する設計のため、最小権限の原則を初期設定から守れます。一部の機能はプレビュー段階のため、導入前に提供状況を確認しましょう。
>公式ドキュメントはこちらから
AIエージェントのガバナンスに関するよくある質問
AIエージェントのガバナンスに関する質問は以下の4つです。
- 中小企業でもAIエージェントのガバナンスは必要ですか？
- AIエージェントが起こした事故の責任は誰が負いますか？
- 生成AIの利用ガイドラインを流用できますか？
- ガバナンスを厳しくすると活用が進まなくなりませんか？
質問に対する回答を確認して、社内の体制づくりの参考にしてみてください。
中小企業でもAIエージェントのガバナンスは必要ですか？
規模に関係なく必要ですが、仕組みは簡素化して構いません。
社員数が少なくても、AIエージェントが顧客情報を扱ったり社外にメールを送ったりすれば、事故の影響は大企業と変わりません。むしろ専任の情シスがいない分、問題に気づくのが遅れやすい面があります。
委員会を設けずに経営者が承認者を兼ね、台帳は表計算ソフトで管理するといった形でも十分です。台帳・権限・承認・停止の4点だけは最初に決めておきましょう。
AIエージェントが起こした事故の責任は誰が負いますか？
社外に対しては、AIエージェントを業務に使っている企業が責任を負うと考えるべきです。
エージェントそのものは責任の主体になれないため、顧客や取引先から見れば、エージェントの誤操作は企業の行為と同じです。AIサービス提供者の責任は、利用規約で限定されているのが一般的です。
社内では、導入を承認した人、エージェントオーナー、ルールを実装した部門のどこに原因があったかを切り分けます。責任の分担を事前に規程で決めておくことで、事故後の原因究明と再発防止を速やかに進められます。
生成AIの利用ガイドラインを流用できますか？
土台としては流用できますが、エージェント特有の項目の追加が必要です。
入力禁止情報や生成物の確認ルールなど、生成AIのガイドラインの多くはエージェントにもそのまま当てはまります。一方で、エージェントが自ら操作を実行する前提のルールは含まれていないことがほとんどです。
追加すべきなのは、本記事で解説した自律度・権限・ID・承認・記録・停止の6要素と、エージェントオーナーの責任です。既存ガイドラインの別章として追記すると、社内の承認手続きも短く済みます。
ガバナンスを厳しくすると活用が進まなくなりませんか？
一律に厳しくすると活用は止まりますが、リスク区分に応じて統制の強さを変えれば両立できます。
文書の要約のような低リスクのエージェントにまで委員会の審査を求めると、現場は申請をあきらめ、管理外のツールを使い始めます。結果として、統制の効かないエージェントが増えてしまいます。
低リスクは台帳登録だけで使えるようにし、統制は高リスクの操作に集中させましょう。「この条件なら使ってよい」が明確な状態は、現場にとっても安心して使える環境になります。
AIエージェントのガバナンスは台帳と権限設計から始めよう
AIエージェントのガバナンスとは、エージェントの権限・責任・停止手段を組織として定め、監督し続ける仕組みです。自律度・権限・ID・承認・記録・停止の6要素をエージェントごとに決め、経営層・エージェントオーナー・情シス・法務と監査の4者で役割を分担します。
構築は、棚卸しと台帳づくり、リスク分類、社内規程の策定、仕組みの実装、段階的な展開、定期監査の6ステップで進めます。AI事業者ガイドライン第1.2版やシンガポールの枠組みを根拠に示せば、社内の合意も得やすくなるでしょう。
まずは社内で動いているエージェントを洗い出し、台帳に責任者と権限の範囲を書き込むところから始めてみてください。
一方で、規程と仕組みを整えても、現場の社員がリスクを理解して正しく使えなければ統制は機能しません。ガバナンスの次は、エージェントを安全に使いこなせる人材をどう育てるかが課題になります。
