AIエージェント・ガバナンスの共通設計 ― 製品を選ぶ前に決めるべき、五つの層と三つの統制

製品を選ぶ前に決めるべき、五つの層と三つの統制

技術シリーズ「AIエージェント・ガバナンス」第1回／全5回（共通設計編）｜読了時間 約16分
対象読者：CIO・DX推進リーダー・情報システム部門長・エンタープライズアーキテクト・リスク管理／内部監査部門

1. 問いは「どう作るか」から「どう統制するか」へ

企業のAIをめぐる問いは、この1年で大きく変わりました。かつては「AIエージェントをどう作るか」が問われていましたが、いまは「すでに動いているエージェントを、どう統制するか」が問われています。

IBMは2026年5月のThink 2026で、大企業は2026年末までに1,600体を超えるAIエージェントを展開する見込みだと示しました。同社によれば、経営層の約7割が、既存のAIガバナンスの不備がAI変革の足かせになっていると答えています。デロイトの調査（State of AI in the Enterprise 2026）でも、エージェントについて成熟したガバナンスの仕組みを持つ企業は21%にとどまります（いずれも見込み値や自己申告を含む調査結果です）。エージェントは人手では追えない速さで増えており、統制が追いついていないのが実情です。

国の動きも同じ方向を指しています。総務省・経済産業省は2026年3月の「AI事業者ガイドライン（第1.2版）」でAIエージェントを定義し、権限の設定や人間の判断の介在など、エージェント固有の留意点を示しました（第6節）。

本稿では、この統制を特定の製品から切り離し、構造として整理します。第2〜4回でSnowflake・Microsoft・Databricksがこの構造をどう実装しているかを層ごとに確かめ、第5回で複数の基盤をまたぐ統制と、導入のロードマップをまとめます。

2. なぜエージェントには新しい層が必要なのか

従来の業務アプリケーションは受動的でした。人が判断して操作し、システムはその指示を実行するだけです。そのため、統制の対象は二つで足りていました。誰が使うか（利用者の統制）と、どのデータに触れるか（データの統制）です。

AIエージェントは、この前提を変えます。依頼の意図を解釈し、計画を立て、ツールを呼び出し、複数のシステムをまたいで実際に行動します。参照だけでなく、外部システムへの書き込みも行います。利用者とデータを統制するだけでは、自ら行動するエージェントそのものは統制できません。必要なのは、二つの統制のあいだに入る三つ目の層、すなわちエージェント自身を統制する層です。

具体的な場面で考えてみます。ある自動車部品メーカーで「調達エージェント」が動いているとします。仕入先から届く見積もりを読み、在庫と受注を照合し、必要に応じて発注書を起票する、購買担当者にとって便利なエージェントです。ところが、このエージェントが購買担当者のアカウントを借りて動いていたらどうなるでしょうか。参照だけのはずが原価テーブルを書き換え、与信枠を超える発注をかけ、しかもその操作が誰の権限で行われたのかを、後から追うことができません。悪意がなくても、過剰な初期設定が一つあるだけで、事故は瞬時に起こり得ます。本稿では、この調達エージェントを最後まで例にとり、各層がどこで、何によって止めるのかを確かめていきます。

なお、エージェントが「何を知るか」の統制（知識層の新鮮さ・権限・来歴）は、別連載「エンタープライズ・ナレッジ・インテリジェンス」の第8回で扱いました。本シリーズは、エージェントが「何をするか」の統制を扱います。

3. 三社は異なる出発点から、近い構造に行き着いた

2026年、主要なデータ／AIプラットフォームは相次いでエージェントを統制する機能を投入しました。注目すべきは、出発点の異なる三社が、近い骨格にたどり着いていることです（2026年10月時点）。

• Snowflakeは6月の年次カンファレンスで、エージェント1体ごとに検証済みの身元を与える「Agent Identity」を発表し、7月までに一般提供としました。統制された文脈層「Horizon Context」や、Trust CenterでのAIセキュリティ態勢の管理とあわせて、統制の基盤と位置づけています。7月には、買収したMCP基盤Natomaを土台とする「Cortex AI Gateway」を公表しました。他社製のエージェントも含めて、モデルやツールへのアクセスと利用量を一元的に統制する構想です。9月にプレビュー提供が始まり、現時点ではモデル利用の統制が中心です。
• Microsoftは5月に一般提供を始めた「Agent 365」で、エージェントを従業員のように扱う考え方をとりました。Entra Agent IDによる固有の身元、Purviewによるデータの統制と監査、Defenderによる脅威検知、そして各エージェントに責任者（スポンサー）を割り当てるライフサイクル管理です。エージェントの台帳はAgent 365に集約され、5月には、スポンサーの異動や退職の際に責任を自動で引き継ぐ仕組みも一般提供となりました。ゲートウェイと利用量の統制は、AzureのAIゲートウェイ（Azure API Management、Microsoft Foundry）が担います。8月には、EntraでMCPサーバーへの接続を制御する「MCP Firewall」のプレビューも始まりました。
• Databricksは4月に、ゲートウェイをUnity Catalogに統合しました（現在の名称は「Unity Gateway」、旧称Unity AI Gateway）。6月の年次カンファレンスでは、統制の対象をデータからモデル・エージェント・MCPサービス・スキルへと広げています。Unity Gatewayは8月に一般提供となり、行動ごとに許可・拒否・承認要求を定める「サービスポリシー」（発表時の名称は Contextual Service Policies）はベータ版として提供されています。

製品名も設計思想も異なります。それでも、固有の身元、統制されたデータと文脈、ツールへのアクセス制御、継続的な監視という骨格は共通しており、ゲートウェイを軸に利用量やコストまで統制する方向でも足並みがそろってきました。出発点の異なる三社が近い構造に至ったことは、これらの層が一時的な製品トレンドではなく、問題の構造に根ざしていることを強く示唆しています。

機能の差は残りますが、層の設計を先に決めておけば、どの基盤も同じ物差しで評価できます。したがって、ガバナンスを理由に基盤を乗り換える必要はありません。いま動いている基盤の上で層を設計することが先決です。この考え方は、SAPやSalesforceなど、業務SaaSに組み込まれたエージェントにもそのまま当てはまります。

4. 共通構造 ― 五つの層と三つの横断的統制

共通構造は、ガバナンスを適用する五つの層と、五つの層すべてにまたがって働く三つの横断的統制から成ります（図1）。層の番号は、設計で決めていく順序（前提となる条件から、最も守るべき操作へ）を表します。動作時の順序はこれと異なり、まず③の身元が確定し、そのうえで②のデータ統制と④の権限が評価されます。

① 境界・所在 ― どこで動かすか

データとモデルがどこに置かれ、推論がどこで行われるかを決める層です。リージョン、クラウド、推論処理を国外へ出してよいかどうかがこれにあたり、以降のすべての層の前提になります。日本企業にとって見落とせないのが、日本語を正しく扱える多言語の埋め込みモデルを、国内リージョンで使えるかどうかです。使いたいモデルが国内で提供されていなければ推論が国外へ出ることになり、後からモデルを替えると全文書の再ベクトル化が必要になります。海外拠点を持つ企業は、拠点ごとのデータ所在の要件もここで整理します。

調達エージェントでは： 仕入先から届く見積もりを、どのリージョンで、どのモデルで読むかを最初に決めます。ここで国外での処理を許していれば、以降の権限設計は前提から崩れます。

② データと文脈 ― 何を知ってよいか

カタログ、機密度の分類、マスキング、行レベルの制御といった、データに付く統制の層です。エージェントの理解を支える意味（セマンティック）の層もここに含みます。目指す原則は「デフォルト拒否」です。ただし、多くの基盤の既定値は許可寄りです。利用者の代理で動くエージェントは、過去に共有しすぎたファイルも含め、その利用者が閲覧できるものをすべて参照できます。既定値の確認と、過剰な共有の解消が最初の作業になります。

この層は、回答の精度も左右します。Snowflakeが自社の評価として公表した結果では、業務の文脈（セマンティックモデル）を組み込んだ仕組みで、自然言語からSQLへの変換の正答率が90%を超え、単一のプロンプトでLLMに生成させた場合の約2倍になりました。その文脈は、組織がデータに与えてきた意味構造（オントロジー）と、データ統合の積み上げから生まれます。当社が支援したある大手自動車メーカーでも、8,500万件を超える顧客データを一つの統合データベースにまとめています。エージェントに渡せる文脈の質は、こうした整備の上に立ちます。

調達エージェントでは： 仕入先の価格表を「社外秘」、原価テーブルを「最重要機密」と分類し、エージェントには必要な列だけが、必要な粒度で見えるようにします。

③ 身元 ― 誰として動くか

エージェントに、人から借りた認証情報や共有キーの代わりに、1体ごとの固有の身元（ID）を与えます。そうすれば、行動を独立して監査し、権限を独立して付与・剥奪できます。

ただし、固有の身元を持つことは、利用者と無関係に自分の権限で動くことと同じではありません。エージェントの動き方は二つあります。利用者の依頼を受けてその代理として動く場合（代理アクセス、On-Behalf-Of）と、定期処理のようにエージェント自身の権限で動く場合です。代理で動くときは、エージェントと依頼した利用者の両方の身元を引き継ぎ、実際に使える権限を、利用者の権限とエージェントに許された範囲の重なりに限ります。こうしておけば、権限の弱い利用者がエージェントを踏み台にして、本来触れられないデータに届くことを防げます。

調達エージェントでは： 購買担当者のアカウントは流用させず、「調達エージェント」という固有のIDを発行します。担当者の依頼で動くときは、担当者とエージェントの権限が重なる範囲だけを使います。記録には「どのエージェントが」「誰の依頼で」の両方が残るため、事故が起きても「誰の権限で」に一行で答えられます。

④ 権限とツール ― 何を、どこまで使ってよいか

②がデータに付く統制だとすれば、④は、身元ごとに何をしてよいかを決める統制です。目的に応じた権限だけを与え、呼び出してよいツールやMCPサーバーを許可リストで明示します。許可リストに加える前には、提供元とツールの説明文を確認し、版を固定します。外部システムへのアクセスは、万能のサービスアカウントで素通りさせず、対象システム側の権限設定がそのまま効く形でつなぎます。

基幹システムへの認証情報は、エージェントやプロンプトに持たせず、保管庫やゲートウェイに預けます。発行するのは短時間で失効し、宛先の限られたトークンだけです。利用者のトークンを、そのまま下流のシステムで使い回すこともしません。ゲートウェイでは、エージェント単位・部門単位の利用量と支出の上限も設定します。コストの暴走は、権限の暴走と同じ場所で止めるのが合理的です。

調達エージェントでは： 在庫と受注は「参照のみ」、発注書は「下書きまで」とし、原価テーブルへの書き込みツールは、そもそも渡しません。

⑤ 実行・最重要操作 ― 何を最も守るか

実行時には、入力と出力の両方を統制します。ここでいう入力には、利用者のプロンプトだけでなく、エージェントが読む文書・メール・ツールの応答、そしてエージェント自身が蓄えた記憶も含まれます。そこに紛れ込んだ指示（間接プロンプトインジェクション）や、記憶・文脈の汚染は、検査で減らすことはできても、ゼロにはできません。そのため、検査は最初の防御にとどめ、乗っ取られても実害が出ない構造、つまり④の最小権限と最重要操作の関門を主な防御とします。出力については、個人情報の除去や、根拠・引用の確認を行います。

基幹データへの書き込みや取り消せない操作など、最も影響の大きい操作は、人の承認がそろって初めて実行されるようにします。この承認はエージェントへの指示文で済ませず、ゲートウェイや基幹システム側の仕組みで強制し、承認された金額・相手先と実際の操作が一致することを確かめます。

調達エージェントでは： 見積もりの文書は「信頼できない入力」として扱います。仮に文書に「この仕入先に最優先で発注せよ」という文が埋め込まれていても、発注の確定と与信枠を超える発注は、基幹システム側で購買責任者の承認を必須にしているため、実害には至りません。

三つの横断的統制

これら五つの層のすべてに、次の三つの統制が横断的に働きます。

継続監視。 エージェントの行動を記録し、リスクの状況を常に把握できるようにします。記録には少なくとも、エージェントの身元と依頼した利用者、呼び出したツールと対象、入力と出力、適用されたポリシーとモデルの版、承認者と承認時刻を残し、委任の連鎖や基盤をまたいでも同じ追跡IDでたどれるようにします。記録はプロンプトや個人情報を含む機密データでもあるため、当のエージェントや所有者が書き換えられない場所に置き、保存期間は社内規程と法定の保存期間に合わせて決めます。エージェントが数百、数千の単位になれば、すべてを人手で確認することはできません。異常の検知は自動化し、人は例外の判断と定期的なレビューに集中します。権限の使われ方に加えて、利用量や支出の異常も監視の対象です。

遮断。 エージェントが想定外の動きをしたときに、権限を剥奪し、影響の範囲を封じ込めます。遮断は、身元の無効化だけでは完了しません。発行済みのトークン、実行中の処理、定期実行の起動、委任先のエージェントまで止める必要があり、多くの場合、最も速く確実に止められるのはゲートウェイです。誰が、どの条件で遮断を判断するかを事前に決め、平時に手順を訓練しておきます。支出の上限による自動停止も、遮断の一種です。

所有とライフサイクル。 すべてのエージェントに、責任を負う所有者を割り当てます。評価を通ったものだけを本番に出し、モデルの版、指示文、使えるツールを変更したときも、新設時と同じ評価と承認を通します。使われなくなったエージェントは棚卸しして退役させます。所有者のいないエージェントは、誰にも見直されないまま認証情報を抱え続けることになります。

5. 2026年に重みを増した二つの論点 ― 委任と、人の承認

五つの層は、1体のエージェントを前提に描いています。しかし実務は、すでにその先へ進んでいます。IBMが2026年6月に公表した調査では、組織が前年に経験したAIエージェント関連のインシデントは平均54件（回答企業の自己申告）で、重大なもののうち33%がシステムの連鎖的な障害でした。

エージェントからエージェントへの委任。 調達エージェントが、見積もりの比較を「分析エージェント」に、仕入先への連絡を「メールエージェント」に依頼するような多段の構成では、二つの問題が生じます。

一つは、権限の伝わり方です。依頼を受けた側が依頼元より広い権限で動けば、③と④の設計は簡単にすり抜けられます。原則は、委任の各段で権限が狭まることです。依頼を受けた側が実際に使えるのは、最初の利用者、依頼元のエージェント、自分自身の権限が重なる範囲だけです。たとえばメールエージェントに社外送信の権限があっても、原価を見られない利用者の依頼で、原価を社外へ送ってはなりません。依頼の連鎖をたどっても最初の利用者と途中のすべてのエージェントの身元が追えるよう、身元の連鎖をトークンに載せて引き継ぎます（OAuthのトークン交換などが代表的な方式です）。

もう一つは、不具合の連鎖です。1体のエージェントの判断ミスが次のエージェントの入力となり、連鎖的に増幅していきます。人工知能基本計画（第Ⅱ期）が挙げる「不具合の連鎖による大規模障害」は、こうした多段の構成で典型的に起こり得るものです。そのため遮断は、個々のエージェントだけでなく、委任の連鎖全体に対して効かせる必要があります。

人の承認を形骸化させない。 ⑤では、最重要操作に人の承認を組み込みました。一方でAI事業者ガイドライン（第1.2版）は、人がAIの判断を過度に信頼し、自らの確認を怠ってしまう「自動化バイアス」への懸念を挙げています。毎日数百件の承認依頼が届けば、人は中身を見ずに承認するようになります。承認が形骸化した時点で、最重要操作の守りは失われます。

対策は、承認の対象を、件数でなく影響の大きさで絞ることです。取り消せる操作は自律実行に任せ、取り消せない操作、金額の大きい操作、マスタや財務データの変更だけを人の承認に回します。自律実行に任せる操作にも件数・金額・頻度の上限を設け、上限に達したら自動で止めます。そのうえで承認者には、判断に必要な根拠（なぜその発注なのか、どの見積もりと比較したのか）を一画面で示します。承認の範囲は、社内の職務権限規程と対応づけておきます。

6. 法令・ガイドラインと五つの層の対応

日本企業にとって、ガバナンスの設計は法令やガイドラインへの対応と切り離せません。主なものを、五つの層との対応で整理します（図2）。この対応は設計の目安であり、個別の適合判断ではありません。詳しい対応表は第5回で扱います。

• AI法（人工知能関連技術の研究開発及び活用の推進に関する法律、2025年9月全面施行）： 罰則のない推進法で、事業者には国の施策への協力などの責務を定めています。人工知能基本計画は、この法律に基づいて策定されています。AI事業者ガイドラインは同法の施行に先立って策定されたソフトローで、同法に基づく「適正性確保に関する指針」（2025年12月、人工知能戦略本部決定）とあわせて参照されます。
• AI事業者ガイドライン（第1.2版、総務省・経済産業省、2026年3月）： AIエージェントを「特定の目標を達成するために、環境を感知し自律的に行動するAIシステム」と定義しています。別添で示された、連携するツールのホワイトリスト方式による制限、業務に必要な最小限の権限、重要度に応じた人間の判断の介在、ログの管理と定期的な確認は、それぞれ④、③（間接）、⑤、継続監視に対応します。法的拘束力はありませんが、状況に合わせて見直し続ける「アジャイル・ガバナンス」を求めています。自社でエージェントを構築する企業は、利用者としてだけでなく、提供者としての役割も負い得る点に注意が必要です。
• 人工知能基本計画（第Ⅱ期、2026年7月14日閣議決定）： エージェント型AIの登場に伴うリスクとして、不具合の連鎖による大規模障害や、責任の所在の曖昧化を挙げています。企業側では、委任の設計と、所有とライフサイクル（所有者を必ず置く）が備えになります。
• 内部統制報告制度（J-SOX）： 調達・発注のように財務報告に関わる業務でエージェントが動く場合、その権限設定・変更管理・記録は、IT全般統制や業務処理統制の評価対象になり得ます。③④⑤と継続監視の設計は、そのまま監査証跡の設計でもあります。
• EU AI法： 2026年7月に発効した改正（デジタル・オムニバス）により、高リスクAIの義務のうち、附属書III（雇用や信用評価などの用途）は2027年12月、附属書I（医療機器や玩具など、製品への組み込み）は2028年8月へ延期されました。一方、AIと対話していることの開示などを求める第50条の透明性義務は、2026年8月から適用されています。EU域内の取引先や利用者とやり取りするエージェント（たとえば仕入先へのメール）は、開示の要否を確認しておく必要があります。
• OWASP「Top 10 for Agentic Applications」： エージェント固有の脅威を整理した、国際的に参照されるコミュニティ主導のリストです。「目標の乗っ取り」は⑤の入力検査と④の最小権限に、「ツールの悪用」と「サプライチェーンの脆弱性」は④に、「身元と権限の悪用」は③に対応します。「想定外のコード実行」は①での実行環境の分離に、「記憶と文脈の汚染」は②と⑤に、「エージェント間通信の不備」は委任の設計に対応します。「人間とエージェントの信頼の悪用」は⑤の承認設計に、「連鎖的な障害」は遮断に、「不正なエージェント」は継続監視と所有に、おおむね対応します。

7. ガバナンスを運用する ― レバー・周期・役割分担

調達エージェントを導入して半年が経ったとします。購買担当者は異動し、仕入先は入れ替わり、与信枠の基準も改定されました。導入時に正しかった権限が、いまも正しいとは限りません。

各層には、調整できる設定、つまり「レバー」があります。境界をどこに引くか。既定の権限をどこまで絞るか。どのツールを許可リストに載せるか。何を承認に回すか。どの頻度で見直すか。これらの多くは、一度設定した後も、組織の状況に合わせて動かしていくものです。エージェントのガバナンスとは、このレバーを調整し続ける運用のことです。

レバーの操作には、三つの周期があります。調達エージェントに当てはめると、次のようになります。

• 一度だけ（基盤の有効化）： 推論の所在、全社共通のガードレール、既定権限の最小化、共有の認証情報の廃止。調達エージェントを動かす前に、全社で一度決めます。
• エージェントごと（新設のたび）： 固有の身元の発行、所有者の割り当て、権限とツールの絞り込み、出力の統制、本番前の評価。調達エージェントでは、購買部門長を所有者とし、発注の確定を承認の対象に指定します。
• 継続的に（常時）： 権限がなお妥当かの再確認、異常の検知、必要時の遮断。担当者の異動や与信枠の改定は、権限を見直すきっかけとして扱います。

誰がどの層を持つか。 レバーを動かす担当が決まっていなければ、運用は止まります。一つの目安は、次の分担です。

• 情報システム部門： ①境界・所在、③身元、④のゲートウェイと全社共通のガードレール。エージェント台帳の管理者。
• 事業部門（エージェントの所有者）： 個々のエージェントの目的、権限の範囲、承認者の指名。四半期ごとの権限の再確認。
• 情報セキュリティ部門： 継続監視と遮断。遮断の判断権限を誰が持つかを、事前に決めておきます。
• リスク管理部門： ⑤の承認の範囲と金額基準の確認、記録と例外の定期的なレビュー。
• 内部監査部門： 台帳・権限・変更管理・記録の保全が、設計どおり機能しているかの独立した評価。

所有者、権限の管理者、記録のレビュー担当は、別の人が担うことが望まれます。所有者を事業部門に置いても、台帳と遮断は全社で一つに保つことが、基盤をまたいで統制を効かせる前提になります。なお、承認者の工数や台帳の維持にも、継続的なコストがかかります。新しいエージェントを承認する時点で、その運用コストも見込んでおきます。

主要な基盤は、固有の身元、細かな権限制御、ゲートウェイ、記録、緊急停止といった部品をそろえました。しかし、部品をそろえることと、設計することは別です。どの層のレバーを、いつ、どちらへ動かすかを決めるのは、組織自身です。

8. よくある誤解

誤解： 「プラットフォームのガバナンス機能を有効にすれば、統制は完成する」

実際： 機能を有効にしても、どのエージェントに、どの権限を、誰の責任で与えるかは決まりません。さらに、多くの企業では、Microsoft 365上のエージェント、SnowflakeやDatabricks上のエージェント、業務SaaSに組み込まれたエージェントが併存しています。統制が基盤ごとに分かれていれば、その継ぎ目が抜け穴になります。基盤をまたいで一つの設計を通す方法は、第5回で取り上げます。

誤解： 「既存のID管理とアクセス制御で、エージェントも十分に統制できる」

実際： 既存の仕組みは、人の利用を前提にしています。人から借りた認証情報で動くエージェントは、誰の権限で何をしたかを独立して追えません（③）。代理アクセスの扱いや委任の連鎖も、人を前提とした設計では想定されていません。

誤解： 「PoC段階のエージェントは本番ではないので、統制は後回しでよい」

実際： 検証用に付けた広い権限や共有キーは、そのまま本番に持ち込まれがちです。台帳への登録と所有者の割り当ては、PoCの時点から始めます。

9. 明日から始める三つのこと

1. エージェント台帳をつくる。 社内で動いているエージェントを、所有者、身元の種類（固有ID・人のアカウント・共有キー）、権限、接続先、記録の保存先とともに一覧にします。IBMがThink 2026で示したところでは、AIの最新かつ完全な台帳を維持している組織は18%にとどまります。情報システム部門が把握していないエージェントが見つかるのは、たいていこの段階です。（担当：情報システム部門／目安：4週間）
2. 人のアカウントを借りて動くエージェントをなくす。 台帳の「身元の種類」の欄で、個人のアカウントや共有キーで動いているものを特定し、固有のIDへの切り替え計画を立てます。（担当：情報システム部門と各所有者／目安：12週間以内に切り替え計画を確定）
3. 人の承認が必要な操作を線引きする。 基幹データへの書き込み、社外への送信、金額の確定、データの削除を洗い出し、承認が必要な範囲を職務権限規程と対応づけて決めます。（担当：事業部門とリスク管理部門／目安：8週間）

10. まとめ

エージェントの時代に差を生むのは、エージェントの数でも、選んだプラットフォームでもありません。ガバナンスを最初から層として設計し、各層のレバーを組織の変化に合わせて調整し続け、その全体を継続監視で支えているかどうかです。統制は、エージェント活用のブレーキにはなりません。層が適切に設計されていれば、より多くの業務を、より速く、安心してエージェントに任せられるようになります。

次回の第2回では、Snowflakeを取り上げます。データの近くでエージェントを統制する考え方を五つの層に沿って整理し、具体的な設定と既定値の落とし穴まで掘り下げます。

関連記事

• ガバナンスと評価 ― 使い続けるための土台（エンタープライズ・ナレッジ・インテリジェンス 第8回）
• 知識を使う ― アシスタント・エージェント・分析（同 第7回）
• なぜ生成AIの時代に、オントロジーの重要性が増すのか

関連ソリューション・サービス： KOVA®（エンタープライズAI運用基盤）／データインテリジェンス＆AI／AI・生成AIサービス

Cubastionは、日本で事業を営む企業のために、AIエージェント・ガバナンスの層を設計し、各プラットフォームの統制の部品を、自社の業務・地域・言語に合ったひとつの設計へと組み立てて、運用まで支援します。

用語集

• AIエージェント： 特定の目標を達成するために、環境を感知し自律的に行動するAIシステム（AI事業者ガイドライン（第1.2版）の定義）。
• 横断的統制： 五つの層すべてにまたがって働く統制。継続監視、遮断、所有とライフサイクルの三つ。
• 代理アクセス（On-Behalf-Of）： エージェントが利用者の依頼を受け、その代理として動くこと。実際に使える権限は、利用者とエージェントの権限の重なりに限る。
• 委任： エージェントが別のエージェントに仕事を依頼すること。権限の伝わり方と、不具合の連鎖が論点になる。
• MCP（Model Context Protocol）： エージェントが外部のツールやデータに接続するための共通の取り決め。
• ゲートウェイ： エージェントとモデル・ツールのあいだに立ち、アクセス、ポリシー、利用量を一元的に統制する中継点。
• 間接プロンプトインジェクション： エージェントが読む文書やツールの応答に紛れ込ませた指示で、エージェントの行動を乗っ取る攻撃。
• 最小権限： 目的の達成に必要な最小限の権限だけを与える原則。
• デフォルト拒否： 明示的に許可したもの以外は、すべて許可しない原則。
• 所在（レジデンシー）： データや推論処理が物理的に置かれる国・地域。
• 追跡ID： 一つの依頼を、委任の連鎖や基盤をまたいでたどるための共通の識別子。
• 自動化バイアス： 人がAIの判断を過度に信頼し、自らの確認を怠ってしまう傾向。

出典

• IBM「Think 2026 recap」（2026年5月）、IBM Institute for Business Value「CIO・CTO調査」（2026年6月8日）
• Deloitte「State of AI in the Enterprise 2026」
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」2026年3月31日
• 内閣府「人工知能基本計画」2026年7月14日閣議決定、「AI法」、「適正性確保に関する指針」（2025年12月、人工知能戦略本部決定）
• EU AI法 デジタル・オムニバス（Regulation (EU) 2026/1744、2026年7月27日発効）：Lewis Silkin解説、Gibson Dunn解説
• OWASP GenAI Security Project「Top 10 for Agentic Applications」（2025年12月）
• Snowflake「Summit 2026 発表」（2026年6月2日）、「Cortex AI Gateway 発表」（7月28日）、「同 プレビュー」（9月15日）、「Cortex Analystの評価」
• Microsoft「Agent 365 一般提供」（2026年5月1日）、「What’s new in Microsoft Entra: June 2026」、「Entra MCP Firewall（プレビュー）」、「Microsoft FoundryのAIゲートウェイ」
• Databricks「Unity Gateway」（2026年4月）、「Data + AI Summit 2026」、「リリースノート」
• 当社の公開事例：データインテリジェンス＆AI

製品名・機能名は各社のものです。提供形態（一般提供・プレビュー・ベータ）と対象地域は時期によって異なります。本稿の情報は2026年10月時点のものです。