ブログ
•
11分で読めます
企業はエージェンティックAIを、すべてのエージェントの登録、自律性と影響範囲による階層化、実行可能なアクションの制限、重大な判断への人の関与、全ステップのログ記録によって統制しています。企業規模によって変わるのは形式化の度合いです。従業員500人規模なら責任者の指名と停止スイッチ、10,000人規模なら3つの防衛線と独立した検証が求められます。
なぜエージェンティックAIには、モデル時代のガバナンスが通用しないのか?
モデルはスコアや文章を出力し、それをどう使うかは人が判断します。エージェントは目標を受け取り、一連のステップを計画し、ツールやAPIを呼び出し、その結果を読んで再び行動します。統制の対象は、行動するための方針そのものです。
問題を生むのは次の5つの性質です。計画は非決定的であり、同じプロンプトでも実行ごとに同じツールを異なる経路で使うことがあります。エージェントは認証情報を保持するため、精度よりも権限のほうが重要になります。長い処理の連鎖の中で、どのステップも誤って見えないまま、当初の目標から逸れていくことがあります。エージェントは他のエージェントを呼び出すため、一つの障害が連鎖的に広がります。さらに、ベンダーのアップデートで基盤モデルが変わり、前四半期のテストが無効になることもあります。
OWASP GenAI Security ProjectのAgentic Security Initiativeが2025年12月9日に公開したOWASP Top 10 for Agentic Applicationsは、こうして生じる障害モードをASI01からASI10のコードで整理しています。これはOWASP Agentic Skills Top 10とは別の文書です。
コード | 名称 |
|---|---|
ASI01 | エージェントの目標乗っ取り |
ASI02 | ツールの悪用 |
ASI03 | アイデンティティと権限の悪用 |
ASI04 | エージェントのサプライチェーンの脆弱性 |
ASI05 | 予期しないコード実行 |
ASI06 | メモリとコンテキストの汚染 |
ASI07 | 安全でないエージェント間通信 |
ASI08 | 連鎖的障害 |
ASI09 | 人とエージェント間の信頼の悪用 |
ASI10 | 暴走エージェント |
Enzaiの自律型AI(エージェンティックAI)ガバナンスガイドでは、これらのリスクに対応する5つのコントロール層を解説しています。本記事では、企業規模ごとにその仕組みのどこまでが必要か、どの順序で整えるべきかを考えます。
エージェンティックAIのガバナンスに現在適用される基準とは?
シンガポールのIMDAは2026年1月22日、世界経済フォーラムでModel AI Governance Framework for Agentic AIを発表しました。このフレームワークは指針を4つの観点に整理しています。事前にリスクを評価して範囲を限定すること、人が実質的な説明責任を負うこと、技術的なコントロールとプロセスを導入すること、エンドユーザーが責任を果たせるようにすることです。法律事務所の解説によると、2026年5月20日の改訂で、事例研究、マルチエージェントとサードパーティのエージェントのリスク、そして人によるオーバーライド率のモニタリングを含む自動化バイアスに関する指針が追加されました。このフレームワークの成り立ちは、Enzaiの用語集で解説しています。
EU AI Actは技術中立的です。第3条(1)はAIシステムを「さまざまなレベルの自律性で動作するよう設計された」ものと定義しているため、エージェントもAIシステムに該当し、そのユースケースによってリスク区分が決まります。第V章に基づく汎用AIモデルの義務は、2025年8月2日から適用されています。2026年7月27日に発効したAIに関するデジタル・オムニバス(規則(EU) 2026/1744)により、附属書IIIの高リスクAIシステムに関する義務は2027年12月2日に、附属書Iの義務は2028年8月2日に延期されました。延期されなかった項目は、改定後の期限に関するEnzaiの解説で一覧にしています。
NIST Generative AI Profile(NIST AI 600-1、2024年7月)は、12のリスクカテゴリをAI RMFの4つの機能に対応付けています。自律型エージェントへの言及はセキュリティ上の脅威としての1回のみであるため、エージェント向けのフレームワークではなく、土台として扱うべきです。
自律レベルに応じて、コントロールをどう決めるべきか?
階層化すべきはモデルではなく、デプロイメントです。同じ基盤モデルが、文章作成アシスタントにも、資金を動かすエージェントにも使われ得るからです。
自律レベル | エージェントに許される範囲 | 最低限のコントロール | 承認とレビュー |
|---|---|---|---|
支援型 | データを読み取り提案する。すべてのアクションは人が実行 | 責任者を明記してインベントリに登録、プロンプトと出力のログ記録、標準的なAI利用規程 | 責任者の承認、年1回のレビュー |
監督型 | 影響の小さいアクションを実行。重大なものは実行前に人が承認 | ツールとパラメータの許可リスト、人による確認ポイントの設定、全ツール呼び出しのセッション単位のログ記録、文書化された停止手順 | ガバナンス部門が承認。基盤モデルの変更時と、少なくとも半年ごとにレビュー |
限定自律型 | 許可リストの範囲内で、アクションごとの承認なしに行動。例外時はエスカレーション | 影響の上限(金額、レコード数、可逆性)、エスカレーションのトリガー、リリース前の独立したテスト、改ざん不可能なアクションログ、テスト済みで数秒以内に作動できるキルスイッチ、アクション分布とオーバーライド率のモニタリング | 承認者と開発者を分離、四半期ごとのレビュー、適用範囲の変更時に再承認 |
完全自律型 | 幅広いツールへのアクセスを伴う、範囲の定まらないタスク | 上記すべてに加え、継続的な挙動モニタリング、マルチエージェントの再帰回数の上限、演習済みのインシデント対応計画、下位レベルでは不十分な理由の文書化 | リスク委員会または同等の機関、独立した検証、取締役会への可視化 |
従業員250人から1,000人の企業は、エージェンティックAIをどう統制しているか?
この規模の企業には第2の防衛線がなく、エージェントのためにそれを新設すべきでもありません。ここでの適切なガバナンスとは、5つのことを確実に行うことです。
すでに契約しているSaaSプラットフォーム上で作られたものも含め、すべてのエージェントを中央レジストリに登録し、責任者、目的、書き込み可能なシステム、自律レベルを記録します。軽量な申請受付を運用します。データの機密性、自律性、可逆性で階層化する1ページのフォームを用意し、リスクまたはセキュリティの担当者がレビューします。エージェントごとに説明責任を負う責任者を指名します。エージェントに実績ができるまでは、支出、顧客レコードの変更、外部への送信を伴うアクションには人の承認を必須とします。そしてキルスイッチを定義します。誰が、どのように、どれだけ速くエージェントを停止できるかを決め、本番稼働前にテストします。
この規模で不要なのは、3つの防衛線の体制、独立した検証チーム、委員会です。想定例として、カスタマーサポート、財務オペレーション、営業リサーチにエージェントを導入している従業員600人のソフトウェア企業であれば、レジストリ、フォーム、隔週のレビューで運用でき、AI責任者またはセキュリティ責任者がこれを担います。
従業員1,000人から10,000人の企業は、エージェンティックAIをどう統制しているか?
従業員が1,000人から10,000人になると、レジストリだけでは足りなくなります。ガバナンス責任者の管轄外にある複数のチームがエージェントを開発しており、そのうち少なくとも1つは規制対象の判断や顧客に関わります。
申請受付は必須になります。誰がレビューし、どのエビデンスを確認し、なぜ同意したのかを明記した承認記録がなければ、ユースケースは本番環境に進めません。設計については申請受付プロセスのガイドで解説しています。Enzaiのユースケース・イニシアチブのワークフローは、ユースケースの種類、データの機密性、自律性によって申請を階層化し、承認や却下のたびにレビュー担当者、エビデンス、根拠を記録します。
リスク階層化は2つの変数に基づきます。上の表の自律レベルと、影響範囲、つまりエージェントがアクセスできる範囲とそのアクションの可逆性です。読み取り専用のリサーチエージェントと請求システムに書き込むエージェントは、同じモデル上で動いていても統制の仕方が異なります。
ここから、開発者と承認者の分離が始まります。エージェントを開発したチームが、そのエージェントを「限定自律型」として承認すべきではありません。エビデンスの保管もそれ自体が重要になります。テスト結果、許可リスト、承認記録を、エージェントと、テストに使った基盤モデルのバージョンに紐づけて保存します。
ベンダーのエージェントも対象になります。CRM、人事プラットフォーム、サービスデスクに組み込まれたエージェントは、ベンダーの権限を持ったまま自社環境内で動作し、ベンダーは予告なくモデルを変更できます。それぞれについてAIインベントリへの登録とベンダー評価が必要です。確認すべき質問は、EnzaiのベンダーAIリスクガイドで解説しています。
従業員10,000人以上の大企業や規制業種の企業は、エージェンティックAIをどう統制しているか?
この規模、あるいは従業員数にかかわらず規制業種では、エージェンティックAIのガバナンスは、監督当局が検査できる統制環境となります。
3つの防衛線が適用されます。事業部門がエージェントを所有・運用し、第2線のリスク管理部門またはコンプライアンス部門がポリシーを定め、システムを階層化し、自律性の高いデプロイメントを承認します。内部監査はその両方を検証します。限定自律型と完全自律型のエージェントの独立した検証は第2線が担い、モデルだけでなく、許可リスト、エスカレーションルール、テストのエビデンスもレビューします。
取締役会またはリスク委員会は、本番稼働中のエージェントの数とそのレベル、エスカレーションされた例外の件数、人がエージェントの判断を覆した頻度、そしてあらゆるインシデントを把握すべきです。人によるオーバーライド率をモニタリングするというIMDAの提案は、ここで実用的な指標になります。この率がゼロまで下がるのは、エージェントが適切に振る舞っているからではなく、自動化バイアスの兆候だからです。
エビデンスは規制当局に示すことを前提に整備します。EU AI Actでは、附属書IIIの高リスクAIシステムの導入者は、必要な能力、訓練、権限を有する自然人に人による監視を割り当て(第26条)、システムが生成するログを保管しなければなりません。こうしたエビデンスは、エージェントごと、バージョンごとに存在している必要があります。
大規模な金融機関がつまずくのは、既存のモデルリスク管理です。米国でSR 26-2の対象となる銀行は、生成AIとエージェンティックAIが同ガイダンスの適用範囲から明示的に除外されていることに気づきます。一方、内部モデルの承認を受けている英国の銀行は、PRA SS1/23にそうした除外規定がないことに気づきます。現実的な解決策は、モデルリスクと同じ委員会が統括する並行したエージェンティックAIのフレームワークを設け、境界を文書化し、インベントリを一本化することです。EnzaiのエージェンティックAIガバナンスモジュールは、まさにこの層のために設計されています。監督なしで何ができるかによって各エージェントを階層化し、本番環境で許可・禁止するアクションを定義し、範囲外の試みを人のレビューに回し、エージェント同士の呼び出し関係を可視化し、コントロールをOWASP Agentic Top 10に対応付けます。
3つの規模区分で何が変わるのか?
項目 | 従業員250人から1,000人 | 従業員1,000人から10,000人 | 10,000人以上または規制業種 |
|---|---|---|---|
レジストリ | 責任者、目的、レベルを記載した中央リスト | フレームワークのマッピングとベンダーのエージェントを含むインベントリ | 監査部門と監督当局が検査する信頼できる唯一の情報源(System of Record) |
申請受付 | 1ページのフォーム、レビュー担当者1名 | 必須のワークフロー、承認の記録、レベル別のテンプレート | 第2線による承認、上位レベルは独立した検証 |
階層化の基準 | 自律性と可逆性 | 自律性と影響範囲 | 自律性、影響範囲、規制上の分類 |
人による監視 | 重大なアクションは人が承認 | レベルごとに確認ポイントを定義 | 第26条に基づき、指名され訓練を受けた監視担当者を配置。オーバーライド率をモニタリング |
職務分掌 | 責任者とレビュー担当者を分離 | 開発者と承認者を分離 | 3つの防衛線 |
エビデンス | ログを保管、承認はレジストリに記録 | テストと承認をエージェントとモデルのバージョンごとに保存 | 規制当局向けのエビデンスの記録、取締役会への報告 |
停止の仕組み | キルスイッチを定義しテスト済み | キルスイッチとエスカレーションのトリガー | インシデント対応と通知の演習を実施 |
保険業界のエージェンティックAIには、どのようなガバナンスフレームワークが必要か?
保険料の見積もり、保険金請求のトリアージ、引受判断の調整を行うエージェントは規制対象の判断を下しており、そのための枠組みはすでに4つの層で存在しています。
EU AI Actは附属書III第5項(c)において、「生命保険および健康保険における自然人に関するリスク評価および価格設定に使用されることを意図したAIシステム」を高リスクに分類しています。EU域内でこの業務を担うエージェントには、2027年12月2日から高リスクAIシステムに関する義務がすべて適用されます。それ以外については、AIガバナンスとリスク管理に関するEIOPAの意見書(EIOPA-BoS-25-360、2025年8月6日)が、禁止対象でも高リスクでもないAIシステムに既存の保険法をどう適用するかを示しています。対象はリスク管理、公平性と倫理、データガバナンス、文書化、透明性、人による監視、正確性とサイバーセキュリティであり、ソルベンシーII第41条とIDD第17条を根拠としています。
英国では、PS22/9で導入され、販売中または更新可能な商品について2023年7月31日から施行されているFCAのConsumer Dutyが、商品、価格と価値、顧客の理解、顧客サポートの4分野で良好な成果をもたらすことを企業に求めています。価格を設定したり保険金請求を処理したりするエージェントは、この4分野すべてに関わります。ここでPRA SS1/23に頼るべきではありません。これは銀行を対象とし、保険会社を除外しているからです。
米国では、2023年12月4日に採択され、その後20を超える州とコロンビア特別区が発出した保険会社によるAIシステムの利用に関するNAICモデル公報が、ガバナンス、リスク管理、サードパーティAIの監督、市場行為検査への協力を網羅した、文書化されたAISプログラムを求めています。
運用上の要点は、アクチュアリー・モデルのガバナンスとの関係です。料率算定モデルや責任準備金モデルは、すでに検証と承認を伴うアクチュアリー部門の管理下にあります。料率算定モデルをツールとして呼び出すエージェントは、そのモデルをアクチュアリーのガバナンスから外すわけではありません。その上に新たな層を加えるのであり、その層のアクションには独自のレベル、許可リスト、ログが必要です。エージェントは、規制に適合したモデルと、モデルの検証が想定していなかった裁量的なステップを組み合わせることがあるため、公平性に関するリスクは高まります。保険会社は規模を問わず、料率算定、引受、保険金請求のエージェントを、オーバーライドのデータが上位レベルを裏付けるまで「監督型」にとどめるべきです。
運用面での意味
3つの規模のいずれでも、ガバナンスチームが進める順序は同じです。違うのは深さです。
まずレジストリを構築します。ベンダー製品に組み込まれたものも含むすべてのエージェントについて、責任者、目的、ツール権限、自律レベルを、システムごとにリスクレベル、自律レベル、対応付けたフレームワーク、エビデンスを記録する単一のAIインベントリで管理します。
自律性と影響範囲で階層化し、上の表のコントロールを適用します。従業員250人から1,000人の企業ではこれがプログラムのすべてです。1,000人以上では、これが申請受付と承認ルートの起点になります。
許可リストと停止スイッチを技術的に制御します。エージェントによる請求システムへの書き込みを禁じるポリシーも、エージェントが実際に書き込めない状態になるまではコントロールとは言えません。Enzaiのエージェンティックモジュールは、許可・禁止するアクションを定義し、範囲外の試みを人のレビューに回します。
エビデンスをエージェントごと、基盤モデルのバージョンごとに保管し、継続的なAIモニタリングの一環としてオーバーライド率とアクション分布を追跡します。エージェンティックAIのフレームワークをモデルリスク管理と整合させ、保険業界ではアクチュアリーのガバナンスとも整合させます。
規制当局が挙げるであろう基準に対応付けます。まずはOWASP Agentic Top 10からです。専用プラットフォームを比較検討している場合は、EnzaiとCredo AIの比較をご覧ください。技術的なモデル評価、レッドチーミング、ドリフト検知などCredo AIが優れている点と、Enzaiがアクション層で制御する点を整理しています。
レジストリ、階層化、制御が貴社の規模でどのように連携するかについては、エージェンティックAIガバナンスに関してEnzaiチームにご相談ください。
2023年からISO 27001認証を取得、NQAによる年次監査
GDPRに沿ったデータ取り扱い
顧客データは複数リージョンのAWSでホスト
独自のAIモデルをプライベート接続で利用可能
チームが利用しているAIを見つけ出し、導入前にレビューし、適用される規制に照らして評価し、エージェントにできることを制御します。規制対象組織向けに設計されています。



