エージェンティックAIガバナンス：企業向け決定版ガイド

18か月の間に、エージェント型AIは研究プロトタイプから企業実装の現実へと移行しました。2025年末時点で、Gartnerは、エージェント型AI機能が2028年までに企業向けソフトウェアアプリケーションの3分の1超に組み込まれ、2024年の1％未満から増加すると予測しています。[1] SalesforceはAgentforceを発表しました。MicrosoftはCopilot Studioにエージェント・オーケストレーションを組み込みました。ServiceNow、SAP、そして数多くの企業がそれに続きました。企業にとっての問いは、AIエージェントを導入するかどうかではもはやなく、何か問題が発生する前に、エージェント型AIガバナンスを整備しているかどうかです。

その緊急性は妥当です。エージェント型AIシステムは、多くのガバナンス・フレームワークが想定していたAIとは質的に異なります。分類器はラベルを付与し、チャットボットはテキストを生成します。これに対し、エージェントは目標を追求します。すなわち、複数ステップのワークフローを計画し、ツールを選択してアクションを実行し、結果を観察し、反復します。しかも多くの場合、数十回に及ぶ意思決定を、最小限の人手介入で行います。この運用上の自律性こそが、エージェントに価値をもたらす要因です。同時に、それが統制を難しくしている要因でもあります。エージェント型AIガバナンス――自律型AIエージェントが許容可能なリスク境界内で運用されることを確保するための、方針、統制、監督メカニズムの集合――は、もはや将来の検討事項ではなく、企業にとって必須の要件です。

このガイドでは、企業向けエージェント型AIガバナンスのための実践的なフレームワークを示します。エージェント型AIシステムとは何か、そしてなぜ通常とは異なるガバナンス対応が必要なのか、既存規制がどのように適用されるのか、組織が実装すべき中核的なガバナンス統制は何か、さらに、エージェントが本来実現すべきイノベーションを阻害することなく、それらの統制をどのように運用に落とし込むかを扱います。

エージェント型AIを特異なものにする要因

「エージェント型AI」という用語は、人間の利用向けに単に出力を生成するのではなく、目標達成のために自律的な行動を取ることができるAIシステムを指します。この違いは、リスクプロファイルを根本的に変えるため、重要です。

従来型のAIシステムは、リクエスト-レスポンス型のパラダイムで動作します。ユーザーが入力を与え、システムが出力を生成し、ユーザーがそれをどう扱うかを判断します。人間は、結果に影響するあらゆる段階でループの中に残ります。エージェント型システムはこのパターンを崩します。高位の目標を受け取り、それをサブタスクに分解し、各段階を達成するためのツールを選択・呼び出し、中間結果を評価し、アプローチを調整します――しかも、各段階での人間の承認から完全自律実行まで、さまざまな程度の監督の下で行われます。

エージェント型AIを従来型システムと区別し、固有のガバナンス課題を生み出す特徴は、次の3つです。

自律的なアクション実行

エージェントは単に推奨するだけではなく、実行します。メールを送信し、コードを実行し、データベースを変更し、APIを呼び出し、ファイルを作成し、外部サービスと連携します。各アクションは、元に戻すことが困難、あるいは不可能な形で、現実世界の状態を変化させます。誤って分類された画像は修正できます。しかし、誤った宛先に送信したメール、上書きされたデータベース・レコード、誤って実行された金融取引は、単純には取り消せません。

多段階の推論連鎖

エージェントは、各ステップが前のステップの上に積み重なる長い推論連鎖の中で動作します。「この空きポジションに最適な候補者を見つける」といった単一の高位指示だけでも、どのデータベースを照会するか、どの基準に重み付けするか、どの候補者を一次選考に残すか、どのように連絡するかといった多数の中間判断を引き起こす可能性があります。単一意思決定システム向けに設計されたガバナンス・フレームワークは、この累積的な複雑性に対処しきれません。

動的なツール呼び出し

現代のエージェント・アーキテクチャでは、エージェントが実行時にツール――API、データベース、Webサービス、コードインタープリター――を発見し、呼び出すことが可能です。これらは、システムが設計または評価された時点では想定されていなかった可能性があります。これは、リスク評価とコンプライアンスにとって移り変わる対象を生み出します。月曜日のシステム能力が、金曜日には実質的に異なっている場合があり得ます。

これら3つの特徴は相互に作用します。自律的なアクション実行を行い、多段階の連鎖を通じて動作し、実行時に発見したツールを動的に呼び出すエージェントは、ガバナンス上の課題を生み出します。その課題は、単に従来型AIシステムを統制するより難しいというだけではありません。構造的に異なるのです。

既存規制の適用範囲

現在のAI規制はエージェント型システムを対象外としている――ガバナンス上の義務が発生する前に、新たな法制度が必要だ――という誤解がよく見られます。これは誤りであり、「エージェント型専用」の規制を待っている組織は、すでに施行されている法律の下で不適合となるリスクがあります。

EU AI Act

EU AI Actの第3条第1項におけるAIシステムの定義は、「さまざまなレベルの自律性で動作するよう設計され、導入後に適応性を示し得て、明示的または暗示的な目的のために、受け取った入力から、予測、コンテンツ、推奨、または物理的・仮想的環境に影響を与え得る意思決定などの出力をどのように生成するかを推論する、機械ベースのシステム」と説明しています。[2]

この定義のあらゆる要素は、無理なくエージェント型AIに当てはまります。「さまざまなレベルの自律性」は、人間主導型から完全自律型までのスペクトラムを明示的に想定しています。「暗示的な目的」――主として、目的がプロンプトとして明示されるのではなく、設計や学習によって含意されるシステムを捉えるために起草されたものではありますが――は、エージェントが高位指示を分解する際に追求する創発的なサブゴールも十分に包含し得るほど広い概念です。ただし、この解釈は、まだ執行や正式なAI Officeのガイダンスを通じて検証されていません。[3] 「意思決定」は、各段階でエージェントが行うアクション選択を捉えます。そして「物理的・仮想的環境に影響を与える」という表現は、単なる受動的な出力生成を超えて、エージェント型の振る舞いを定義する環境変化型のアクションを包含します。

同法の執行スケジュールは段階的です。許容できないリスクのAIシステムに対する禁止規定は2025年2月2日に適用開始となりました。汎用AI（GPAI）モデルに対する義務は2025年8月2日から適用されます。附属書IIIに基づく高リスク・システム義務の全体は2026年8月2日に発効します。[4] 高リスクのユースケースでエージェント型システムを展開する組織に残された準備期間は、縮小しつつあります。

エージェント型システムが、附属書IIIに列挙された高リスク・ユースケース――雇用判断、与信スコアリング、法執行、重要インフラ管理――に該当する場合、高リスク義務の全体が適用されます。これには、リスク管理システム（第9条）、データガバナンス（第10条）、技術文書（第11条）、記録保持および自動ロギング（第12条）、透明性（第13条）、人間による監督（第14条）、および正確性・堅牢性・サイバーセキュリティ要件（第15条）が含まれます。[5] 第12条は特に重要です。多段階の推論連鎖と動的なツール呼び出しの中で判断が展開するシステムでは、ロギング要件は、技術的に最も要求が高いだけでなく、運用上も最も重要な義務となります。

同法の運用枠組みは、エージェント型ユースケースに対して確かに負荷がかかります。特に、動的システムに関する適合性評価、エージェントが第三者ツールを呼び出す場合の提供者と導入者の責任分担、そして1秒あたり数十回のマイクロ意思決定を行うシステムに対して「相応」の人間監督が何を意味するのか、といった点です。[6] しかし、規制の境界は明確です。エージェント型AIシステムは同法上AIシステムであり、義務は適用されます。

GPAIモデルの義務

多くの企業向けエージェントは、Anthropic、OpenAI、Google、Metaなどの第三者が提供する汎用AIモデルの上に構築されています。EU AI Actは、第51条から第56条において、GPAIモデル提供者に対し、技術文書、著作権方針の透明性、ならびにシステミック・リスクをもたらすものとして指定されたモデルについては、敵対的テストおよびインシデント報告を含む特定の義務を課しています。[7] 2025年後半に最終化されたGPAI行動規範は、これらの義務に対するコンプライアンス経路を提供します。

企業の導入者にとって、GPAI提供者の義務と導入者の義務の相互作用は、多層的なコンプライアンス状況を生み出します。基盤モデル提供者が一部の責任を負い、導入組織が別の責任を負います。エージェント・フレームワークが、GPAIモデル、オーケストレーション層、そして第三者ツールを組み合わせて複合システムを構成する場合、バリューチェーン全体にわたる義務の割当て自体がガバナンス上の課題となります。本ガイドの後半にあるマルチステークホルダーのセクションが、まさにこの点を直接扱います。

ISO/IEC 42001

2023年12月に公表されたAIマネジメントシステムに関する国際規格は、AIマネジメントシステムを確立、実施し、継続的に改善するためのフレームワークを提供します。[8] エージェント型AIを特に扱ってはいませんが、リスク評価、人間による監督、継続的監視に関する統制は、そのまま適用可能です。ISO 42001認証を目指す組織は、AIマネジメントシステムが従来型AIアプリケーションだけでなく、自律型エージェントの展開を明示的に対象としていることを確認すべきです。

NIST AIリスク管理フレームワーク

NIST AI RMFの4つの中核機能――Govern、Map、Measure、Manage――は、エージェント型システムにも自然に拡張できる構造化されたAIリスク管理アプローチを提供します。[9] 文脈に応じたリスク評価と継続的監視を重視するこのフレームワークは、エージェント行動の動的性質を踏まえると特に重要です。生成AIリスクに関する補助文書（NIST AI 600-1）は、プロンプトインジェクションや意図しないデータ露出を含む、ツールを使用するエージェントに関連する複数のリスクを扱っています。[10] 第3条第1項に影響を与えたAIシステム定義に関しても積極的に取り組んできたOECDは、自律性レベルを一つの次元として含む分類フレームワークの開発を進めています。これは、エージェント型AIガバナンスが国際的にどのように発展していくかを形作る可能性が高い取り組みです。[11]

新たに出てきている州別・業界別要件

2026年2月に発効予定で、現在立法上の修正が審議中のColorado AI Actは、高リスクAIシステムの開発者および導入者に対し、結果に重大な影響を及ぼす判断におけるアルゴリズム差別を回避するため、相当の注意を払うことを求めています。[12] 雇用、金融、保険、住宅に関する判断を行う、または実質的に影響を与えるエージェント型システムは、明確に対象範囲に含まれます。金融サービス分野では、金融機関間のモデルリスク管理ガイダンス（連邦準備制度理事会のSR 11-7およびOCC 2011-12）が、リスク評価や意思決定に使用されるAIエージェントに適用されます。ただし、これは従来の統計モデルを前提に設計されたものであり、自律的にツールへアクセスする基盤モデルベースのエージェントには慎重な解釈が必要です。[13]

エージェント型AIガバナンス・フレームワーク

エージェント型AIの統制には、上記で概説した固有の特徴――自律的なアクション実行、多段階の推論、動的なツール呼び出し――に対応する統制が必要です。Enzaiが企業のガバナンス・チームとともに進めてきた取り組みに基づき、本稿で示すフレームワークは、これらの統制を5つの層、すなわち、自律性の分類、アクションの許可リスト化、エスカレーション・ロジック、トレーサビリティ、継続的監視に整理します。各層は、その前の層の上に構築されます。

レイヤー1：自律性の分類

すべてのエージェントに同じレベルのガバナンスが必要なわけではありません。人間によるレビューのためにメール返信案を下書きするエージェントと、金融取引を自律的に実行するエージェントとでは、リスクプロファイルが根本的に異なります。あらゆるエージェント型AIガバナンス・プログラムにおける最初のステップは、各エージェントの自律性レベルを分類し、その分類に比例した統制へとマッピングすることです。

分類は、モデル固有ではなく、ユースケース固有であるべきです。同じ基盤モデルが、ある展開ではTier 1のアシスタントを、別の展開ではTier 3の自律型エージェントを支えることがあります。ガバナンス義務はモデルではなく、展開に紐づきます。

レイヤー2：アクション許可リスト化と制約付きアクション空間

エージェント型AIに対する最も効果的な統制は、何を実行できるかを制約することです。起こり得るあらゆる障害モードを予測して防ぐことを試みる代わりに、アクションの許可リスト化は、エージェントが取り得る許容アクションの集合――呼び出し可能なツール、利用できるAPI、アクセス可能なデータ、変更可能なシステム――を定義します。

これは拒否リスト型ではなく、許可リスト型のアプローチです。既定の姿勢は、明示的に許可されていないアクションはすべて禁止する、というものです。これは、ソフトウェア・システムにおける一般的なセキュリティモデル（明示的に禁止されていないものは許可される）を反転させるものであり、エージェント型AIシステムが、設計者が想定していなかったアクションを発見し、試みる可能性があるという現実を反映しています。

実装上は、アクション境界を3つのレベルで定義します。

• ツールアクセス： エージェントが呼び出せるAPI、データベース、サービス、コード実行環境

• パラメータ制約： エージェントが各ツールに渡せる入力（たとえば、データベース照会エージェントを特定テーブルの読み取り専用操作に限定するなど）

• 影響範囲の上限： 単一アクションの影響範囲に対するしきい値（たとえば、人間の承認なしにエージェントが承認できる取引の金額上限を設定するなど）

重要な運用上の考慮点があります。ツール環境が進化するにつれて、アクションの許可リストは維持・更新しなければなりません。基盤モデル提供者がモデルの挙動を変える更新を配信した場合、あるいは新しいツールがエージェントの潜在的なアクション空間に追加された場合、許可リストは見直しと再検証が必要です。許可リストを、運用中のガバナンス資産ではなく静的な設定値として扱うことは、典型的な失敗パターンです。

レイヤー3：エスカレーション・ロジック

制約されたアクション空間の中であっても、エージェントは自らの能力や権限を超える状況に直面します。効果的なガバナンスには、事前定義されたエスカレーション経路――エージェントが自律的に継続するのではなく、人間に制御を戻さなければならない条件に関する明確なルール――が必要です。

エスカレーションのトリガーには、次のものを含めるべきです。

• 信頼度しきい値： エージェントが選択したアクションに対する信頼度が、定義したレベルを下回った場合

• 影響しきい値： 提案されたアクションが、事前定義された影響範囲の上限（財務価値、影響を受けるレコード数、不可逆性）を超える場合

• 異常検知： エージェントの振る舞いが期待されるパターンから逸脱した場合

• ドメイン境界： エージェントが、定義された範囲外のタスクまたはドメインに遭遇した場合

• 失敗条件： ツール呼び出しが失敗する、または予期しない結果を返した場合

エスカレーション機構の設計は、トリガーそのものと同じくらい重要です。エスカレーションは、エージェントにとって摩擦のないものでなければなりません（エスカレーションを行ったことでペナルティを与えるような設計パターンによって、回避するよう「誘導」されてはなりません）。また、人間にとっては実行可能でなければなりません（人間が適切な判断を下せるだけの十分な文脈を含み、エージェントの推論連鎖全体を再構築する必要がないことが必要です）。

レイヤー4：トレーサビリティと監査証跡

EU AI Act（高リスクシステムに対する第12条）に基づく規制要件も、実際のインシデント対応も、エージェント活動の包括的なロギングを求めています。[14] エージェント型システムでは、入力と出力だけでなく、推論の全連鎖、ツール呼び出し、中間結果、各ステップでの意思決定まで記録する必要があります。

エージェント型AIのための有効な監査証跡には、次の内容を記録すべきです。

• エージェントに与えられた初期目標または指示

• 各推論ステップとアクション選択の根拠

• 呼び出したツール、渡したパラメータ、受信した応答を含む、すべてのツール呼び出し

• 実行したアクションとその結果

• エスカレーション事象と人間の介入

• エージェントのアクションによって生じた環境状態の変化

• 関連する事象を結び付けるタイムスタンプとセッション識別子

これらのログは、インシデント後の調査、規制遵守、ガバナンス統制の継続的改善、そして問題発生時の責任帰属など、複数の目的を果たします。改ざんを防ぐため、改変不可能で、タイムスタンプ付きで、エージェント・システム本体とは独立して保管されるべきです。

レイヤー5：継続的監視

ポイント・イン・タイムでの評価――導入前にエージェントを評価し、その後もコンプライアンスを維持し続けると仮定すること――は、機能や挙動が動的に変化し得るシステムには不十分です。エージェント型AIガバナンスには、複数の観点にわたる継続的監視が必要です。

• パフォーマンス監視： エージェントの成果は、品質および正確性のしきい値を満たしているか

• 行動監視： エージェントの振る舞いは期待されるパターン内に収まっているか。アクション分布は時間とともに変化していないか

• コンプライアンス監視： エージェントのアクションは許可されたアクション空間内に収まっているか。エスカレーション・プロトコルは順守されているか

• 公平性監視： 個人に関する判断を行う、または影響を与えるエージェントについて、保護属性間で成果は公平か

• セキュリティ監視： エージェントは敵対的入力、プロンプトインジェクションの試み、その他の操作を受けていないか

監視はガバナンス統制にフィードバックされる必要があります。監視が異常――許可された範囲外のアクション、成果分布の変化、敵対的操作を示唆するパターン――を検知した場合、対応は可能な限り自動化され（エージェントを一時停止し、エスカレーションを発動するなど）、人間によるレビューのために記録されるべきです。

エージェントが行動したとき、誰が責任を負うのか？

エージェント型AIガバナンスにおける最も難しい側面の一つは、責任が複数の主体にまたがって分散していることです。典型的な企業向けエージェントの展開には、少なくとも4者が関与します。基盤モデル提供者（OpenAI、Anthropic、Google、Metaなど）、エージェント・フレームワークまたはオーケストレーション層（第三者プラットフォームである場合もあれば、内製である場合もあります）、導入組織、そして実行時にエージェントが呼び出すツールおよびAPIの提供者です。

EU AI Actは、提供者と導入者の間で義務を分けており、一部の規定では輸入業者および流通業者も対象としています。[15] しかし、この二分法はエージェント型のバリューチェーンにはきれいには当てはまりません。第三者の基盤モデルと、外部APIを呼び出す内製オーケストレーション層を組み合わせたエージェントの「提供者」は誰なのでしょうか。第25条は、第三者がAIシステムを変更または転用した場合に、当該第三者が提供者となり得る状況を扱っていますが、動的に構成されるシステムについては境界が依然として不明確です。[16]

この分断は、多くの組織が過小評価している基盤モデルのサプライチェーン・リスクも生み出します。モデル提供者が更新――新しいモデル・バージョン、安全フィルターの変更、挙動パターンの変更――を配信すると、以前のバージョンに対して検証されたガバナンス統制は、もはや成立しない可能性があります。アクションの許可リスト、エスカレーションのしきい値、コンプライアンス評価はいずれも、特定のモデル挙動のベースラインを前提としています。サイレントなモデル更新は、導入側に変更がなくても、それらの前提を無効化し得ます。

実践的なガバナンスは、この分断を織り込む必要があります。エージェント型AIを展開する組織は、次のことを行うべきです。

• 各エージェント展開について、すべての関係者とそのガバナンス責任を特定し、バリューチェーン全体をマッピングする

• ツールおよびAPI提供者との契約において、データ取扱い、責任、インシデント対応を明確に定める

• 明確な社内責任体制を維持する――どの部署が各エージェント展開を保有し、誰が監視責任を負い、誰に介入または停止の権限があるのかを明確にする

• 基盤モデルに対してバージョン固定と変更管理のプロセスを実装し、提供者が更新をリリースした際には再検証のトリガーを設ける

• 規制当局の監査に耐え得る形で責任分担を文書化する

エージェント型AIにおけるインシデント対応

ガバナンスは失敗を防ぐことだけではありません。発生したときに効果的に対応することでもあります。エージェント型AIシステムには、その自律的かつ多段階的な性質を踏まえたインシデント対応手順が必要です。

エージェント型AIのインシデント対応計画には、次の内容を含めるべきです。

• キルスイッチ： エージェントの実行を即時停止し、そのツールアクセスを取り消して以降のアクションを防止する機能。これは技術的に信頼性が高く（エージェントの協力に依存しない）、指定された担当者が数秒以内にアクセスできる必要があります

• ロールバック手順： 可能な範囲で、エージェントが実行したアクションを巻き戻すための事前定義手順。すべてのアクションが可逆ではないため、上記の監査証跡と影響範囲の上限は、被害を最小化するうえで極めて重要です

• 通知義務： 規制業種では、特定のエージェント障害が報告要件を発生させる場合があります。金融サービスでは、無権限取引が数時間以内の規制当局への通知を必要とすることがあります。EU AI Actの下では、高リスクAIシステムに関わる重大インシデントは、市場監視当局へ報告しなければなりません

• 根本原因分析： インシデント後の調査では、レイヤー4で取得した監査証跡を用いて、初期目標から各ツール呼び出し、意思決定、そして失敗に至るまでの全推論連鎖を追跡すべきです

インシデント対応計画は、最初の失敗の後ではなく、導入前に実施すべきです。アクション境界の侵害、エスカレーション失敗、侵害されたツール応答など、エージェント障害を想定した机上演習は、チームがプレッシャー下で効果的に対応するために必要な実践感覚を養うのに役立ちます。

エージェント型AIガバナンスの運用実装

ガバナンス・フレームワークに価値があるのは、運用実装できる場合に限られます。つまり、エージェントが実現すべきイノベーションを阻害するほどの摩擦を生じさせずに、実際に適用できることが必要です。フレームワークと実務のギャップを埋めるために、いくつかの原則が役立ちます。

エージェントのライフサイクルにガバナンスを組み込む

ガバナンスは、エージェント開発と展開と並行して進む別個の作業領域であってはなりません。開発パイプラインに組み込むべきです。すなわち、設計段階での自律性分類、開発中のアクション許可リスト化、展開前のエスカレーション・ロジックのテスト、本番環境での継続的監視です。これはセキュリティにおけるシフトレフトの考え方に相当します。ガバナンスは後付けではなく、最初から組み込むべきです。

ガバナンス統制を自動化する

手作業のガバナンス・プロセスでは、機械速度で動作するエージェントに追いつけません。アクション許可リストは、方針文書ではなく、プログラムによって強制されるべきです。エスカレーション・トリガーは、人間がログを監視することに頼るのではなく、自動的に発動すべきです。コンプライアンス・チェックはCI/CDパイプライン内の自動ゲートとして実行し、エンジニアリング・チームに、記入用のコンプライアンス・フォームではなく、明確な合否シグナルを提供すべきです。

AIインベントリにガバナンスを組み込む

すべてのエージェント型AIシステムは、中央集約型のAIインベントリに登録され、その自律性分類、許可されたアクション空間、エスカレーション・プロトコル、監視設定、責任者、基盤モデルのバージョンが記録されるべきです。このインベントリはガバナンス・プログラムの基盤です。これがなければ、組織は、どのエージェントを展開しているのか、それらに何が許可されているのか、誰が責任者なのかという基本的な問いに答えられません。

実装は実務的に順序立てる

数十のエージェントを展開する組織が、すべての展開に対して5つのガバナンス層を同時に実装することはできません。実務的な順序付けのアプローチは次のとおりです。

1. まずインベントリから始める。 見えないものは統制できません。チームが非公式に立ち上げたシャドー展開も含め、すべてのエージェント展開を把握します。

2. 自律性レベルを分類する。 各エージェントを階層にマッピングします。これにより、その後のすべての統制の比例性が決まります。

3. まずTier 3およびTier 4のエージェントにアクション許可リスト化を実装する。 これらは最も高いリスクを抱えており、制約付きアクション空間の恩恵を最も受けます。

4. 初日から監査証跡を構築する。 ロギングは、早期に実装する統制としては最も低コストであり、後から組み込むには最も高コストです。

5. 展開が成熟するにつれて、継続的監視を段階的に追加する。 まずはコンプライアンス監視（エージェントは許可リスト内にとどまっているか）から開始し、その後、行動監視と公平性監視へと拡張します。

ガバナンスを競争優位として捉える

ガバナンスを専らコンプライアンス・コストと捉える組織は、投資を抑え込み、エンジニアリング・チームの反発を招くことになります。より良い捉え方は、ガバナンスをスケールの前提条件とみなすことです。体系的な統制がなければ、組織は十分な監督を示せないため、エージェント展開は低リスク・低価値のユースケースに限定されます。ガバナンスこそが、企業を慎重な試験導入から、実質的な事業インパクトを伴う本番展開へと移行させる鍵です。

エージェント型AI規制の今後

エージェント型AIガバナンスの状況は、今後2年間で急速に進化するでしょう。CENおよびCENELECは、標準化プログラムの加速を反映して2025年6月に改定された委任を受け、Joint Technical Committee 21を通じてEU AI Actの下で調和規格を策定しています。[17] これらの規格は、高度に自律的なシステムに対する相応の人間監督がどのようなものか――制約付きアクション空間、構造化されたチェックポイント、監査証跡、介入メカニズム――を、あらゆる局面で人間をループに入れることなく定義する必要があります。

欧州委員会は、エージェント型固有のリスクが現れた場合、完全な法改正を必要とせずに、委任法を通じて附属書IIIの高リスク・ユースケース一覧を更新する権限を持っています。[18] また、委員会のガイダンスは、提供者・導入者の枠組みがエージェント型のバリューチェーンにどのように対応するか、そして実行時のツール呼び出しが第3条第23号における「実質的変更」に該当するのはいつかを明確化できます。第56条に基づく行動規範も別の手段であり、GPAIモデル層におけるエージェント特有のリスク――制御可能性の機能、ツール使用ログ、アクション空間の制約――に対処します。[19]

IAPPやOECDを含む業界団体は、自律型AIに関するガバナンス指針の整備を活発に進めています。[20] ISO/IEC JTC 1/SC 42はAI規格の42000シリーズを拡充し続けており、展開環境が成熟するにつれて、エージェント型固有の作業項目が現れても不思議ではありません。

こうした規格やガイダンスを待ってから行動する組織は、もともとそのために設計されていないエージェント展開に、後からガバナンスを組み込むことになります。これは高コストで混乱を招く作業です。より賢明なアプローチは、今すぐガバナンス基盤を構築し、規制および標準に基づく要件が具体化するにつれて適応していくことです。

エージェント型AIを統制する課題は現実のものですが、前例がないわけではありません。企業はこれまでも、アルゴリズム取引から自律走行車、ロボティック・プロセス・オートメーションに至るまで、他の複雑で自律的かつ高リスクなシステムを統制してきました。原則は同じです。リスクを分類し、アクションを制約し、エスカレーションを義務付け、トレーサビリティを維持し、継続的に監視することです。新しいのは、エージェント型AIが導入される速度と、それが企業機能の広範囲に触れていることです。

これら5つのガバナンス層を、異なる自律性レベル、ツールアクセス構成、規制義務を持つ数多くのエージェント展開にわたって実装することは、ポリシー上の課題であると同時に、インフラ上の課題でもあります。Enzaiでは、このインフラ――自律性分類やアクションの許可リスト化から、継続的監視、EU AI Act、ISO 42001、NIST AI RMFにまたがる規制コンプライアンスまで――を構築することが、当社プラットフォームが解決すべき課題です。詳細をご覧になるには、デモを予約する。

Enzaiは、抽象的な方針を実運用の監督へと移行することを支援するために設計された、先進的な企業向けAIガバナンス・プラットフォームです。当社のAIリスク管理プラットフォームは、エージェント型AIガバナンスの管理、包括的なAIインベントリの維持、EU AI Actへの準拠確保に必要な専用インフラを提供します。複雑なワークフローを自動化することで、Enzaiは、ISO 42001やNISTといった国際標準との整合性を維持しながら、企業が自信を持ってAI導入を拡大できるよう支援します。

参考文献

[1] Gartner、「Agentic AI: The Next Frontier of Enterprise AI」、2024年10月。Gartnerは、エージェント型AI機能が2028年までに企業向けソフトウェアアプリケーションの33％に採用されると予測しました。

[2] 欧州議会および理事会規則（EU）2024/1689、第3条第1項。欧州連合官報、Lシリーズ、2024年7月12日。

[3] AIシステム定義に関する欧州委員会の解釈ガイダンス（2025年公表）は追加的な文脈を提供しますが、エージェント型システムにおける創発的なサブゴール分解については特に扱っていません。

[4] 規則（EU）2024/1689、第113条〜第114条（施行および適用開始日）。

[5] 規則（EU）2024/1689、第III章第2節、第9条〜第15条。

[6] これらの運用上の負荷に関する詳細な分析については、Enzai、「EU AI Actは曲がる。しかし壊れる必要はない」、2026年3月を参照してください。

[7] 規則（EU）2024/1689、第V章、第51条〜第56条（GPAIモデル提供者の義務）。

[8] ISO/IEC 42001:2023、情報技術 ― 人工知能 ― マネジメントシステム。国際標準化機構、2023年12月。

[9] NIST、Artificial Intelligence Risk Management Framework（AI RMF 1.0）、NIST AI 100-1、2023年1月。

[10] NIST、Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile、NIST AI 600-1、2024年7月。

[11] OECD、「AIシステム分類のためのOECDフレームワーク」、OECDデジタル経済ペーパー第323号、2022年2月。OECD AI原則は2024年5月に更新されました。

[12] Colorado SB 24-205、「人工知能に関する消費者保護」、2024年5月署名。原施行日は2026年2月1日。現在、立法上の修正が審議中です。

[13] 連邦準備制度理事会理事会、SR Letter 11-7、「モデルリスク管理に関する監督指針」、2011年4月。Office of the Comptroller of the Currency、OCC 2011-12。

[14] 規則（EU）2024/1689、第12条（高リスクAIシステムに対する記録保持／自動ロギング）。

[15] 規則（EU）2024/1689、第16条（提供者の義務）および第26条（導入者の義務）。

[16] 規則（EU）2024/1689、第25条（AIバリューチェーン上のその他の当事者の義務）。

[17] 欧州委員会の標準化要請M/593（CENおよびCENELEC宛て、2025年6月改定）、CEN-CENELEC JTC 21作業計画。

[18] 規則（EU）2024/1689、第7条（附属書IIIの改正）。

[19] 規則（EU）2024/1689、第56条（GPAIモデルの行動規範）。

[20] IAPP AI Governance Center、OECD AI Policy Observatory、oecd.ai、ISO/IEC JTC 1/SC 42作業計画。