こんにちは、ひろかずです。
生成AIエージェントの統制について、各団体がドキュメントを出していますが、12社で結成されたBlueprint AllianceからもAIエージェントを統制するための共通アーキテクチャを推進する4つの質問と6つの原則が公開されました。
これらがどういうものであり、どう使えそうかを紐解きましたので、共有します。
忙しい人向けの要約
- 2026年9月22日、OktaはOktaneカンファレンスで、AWS・CrowdStrike・Databricks・Docker・Google Cloud・Lovable・Proofpoint・Salesforce・ServiceNow・Wiz・Zscalerとともに、AIエージェントを統制するための共通アーキテクチャを推進する「Blueprint Alliance」の結成を発表しました。
- 中核は6原則（エージェントを第一級のIDとして扱う、タスク単位のアクセス、委任の追跡可能性、実行時の継続監視、即時かつ可逆な封じ込め、AIの速度に適応するガバナンス）と、「Where are my agents? / What can they do? / What are they doing? / How do I respond?」の4つの質問です。
- ただしアライアンスが出したのは製品ではなく共同執筆の参照アーキテクチャであり、MCP・OCSF・SSF・CAEPを使ったベンダー間の信号連携は構築・検証が進行中の段階です。検証結果と参照統合は「今後定期的に公開する」という表明にとどまっています。
- 創設メンバーの一覧にMicrosoft（Entra）とモデルベンダー（OpenAI・Anthropic）は含まれていません。Entra中心の企業は、この参照アーキテクチャがそのまま自社に降ってくる前提で待つべきではありません。
- このブログの主張：今日やるべきは製品選定ではなく、「4つの質問」を自社のエージェント棚卸しの監査フレームとして採用することです。標準の完成を待つ理由はありません。
何が起きているの？
2026年9月22日、Oktaは年次カンファレンスOktaneで、Blueprint Allianceの結成を発表しました。創設メンバーはOktaに加えAWS、CrowdStrike、Databricks、Docker、Google Cloud、Lovable、Proofpoint、Salesforce、ServiceNow、Wiz、Zscalerの計12社で、GE AppliancesとWorld Central Kitchenが戦略アドバイザーとして参加します。
発表の中身は製品ではなく、参照アーキテクチャ文書
アライアンスが公開したのは製品ではなく、創設メンバーが共同執筆したホワイトペーパー「Governing Agentic Execution」です。Oktaが2026年3月15日に公開した「secure agentic enterprise」のblueprintを、12社共同のオープンなマルチベンダー参照アーキテクチャへ拡張した文書です。3月版が掲げた質問は「Where are my agents? / What can they connect to? / What can they do?」の3つでした。今回の参照アーキテクチャは「Where are my agents? / What can they do? / What are they doing? / How do I respond?（どう対応するか）」の4問構成に再編され、実行時の監視と、インシデント対応・復旧までを扱う内容になりました。
創設メンバーが合意する6原則
- すべてのエージェントを第一級のIDとして扱う。
- アクセスは常設権限ではなくタスク単位に絞る。
- 委任は追跡可能にする。
- 実行時挙動を継続監視する。
- 封じ込めは即時かつ可逆にする。
- ガバナンスはAIの進化速度に適応させる。
相互運用面の表明
各社はMCP（Model Context Protocol）、OCSF、SSF（Shared Signals Framework）、CAEPという既存のオープン標準を横断した信号連携を構築・検証中で、共同の相互運用結果と参照統合を定期的に公開すると表明しています。公開は今後の予定であり、検証済みの結果はまだ出ていません。
同日、Okta自身も自社実装の新機能を発表
Oktaは同日、Okta for AI Agentsの新機能群を発表しました。機能と提供状況は、プレスリリースのAvailability欄に明記されています。
| 機能 | 何をする機能か | 提供状況 | 出典 |
|---|---|---|---|
| Agent SSO（Cross App Access） | エージェントやアプリが他アプリのデータを使う際のOAuth同意をエンドユーザーから管理コンソール側に移し、ID-JAG（Identity Assertion JWT Authorization Grant）のトークン交換でアクセストークンを発行する。SSO契約のorgで構成できる | GA（2026年9月22日時点） | Cross App Access 設定ガイド／製品紹介ページ |
| Agent-to-Agent Connections | エージェント同士の呼び出しを、カスタム認可サーバーに登録したルールで許可判定する。リクエストごとにスコープ付きで自動失効するトークンを発行し、どのエージェントが誰を呼んだかの委任連鎖をトークンとSystem Logに記録する | GA（2026年9月22日時点） | Agent-to-agent connections ドキュメント |
| Resource Access Certifications | Access Certificationsのキャンペーンで、AIエージェントのリソース接続とユーザーのエージェント利用権限を定期的に審査し、キャンペーンの設定に応じて不要な権限を自動で是正する（エージェント関連の審査はOkta for AI Agents契約が前提） | GA（2026年9月22日時点） | Access Certifications ドキュメント |
| Agent Gateway | エージェントとツール呼び出しの間に入り、実行時にポリシーを適用して全てのやり取りをログする | Q3にGA予定 | Okta PR |
| Shadow AI Agent Discovery for Endpoints | 従業員端末上で動く未管理のエージェントを検出する | Q3にGA予定 | Okta PR |
| Configuration Designer | エージェントとリソースの接続を視覚的に設計し、スコープと監査性を確保する | Q4にGA予定 | Okta PR |
| Kill SwitchのAgent Gateway拡張 | 侵害されたエージェントの有効トークンをすべて失効させ、進行中のセッションを遮断する | Q4にGA予定 | Okta PR |
Oktaはこれらを「blueprintへのOktaの貢献」と位置づけています。アライアンスの中立的な枠組みと、Oktaの商用実装が同じ日に並んだ構図です。
なぜ情報システム・セキュリティ担当者に関係するの？
AIエージェントは人間の意図を受けて自分で実行計画を組み、複数の企業システムのAPIを呼び出し、サブエージェントを生成しながら動きます。導入を決めるのは業務部門や開発チームであり、契約済みSaaSのアップデートで機能として増えるものもあります。それでも、認証基盤・エンドポイント・ログを預かるのは情シスとセキュリティ部門です。単一ベンダーの管理画面では全体が見えないため、「社内でエージェントは何体動いているのか」「誰の権限で何を実行したのか」を説明する役回りは、結局この2部門に集まります。
今回の発表の実務上の価値
その散らばりを測る物差しが、主要ベンダー12社の合意文書として公開された点です。これまでエージェント統制は、各社の製品説明か個社の経験則で語るしかありませんでした。ID・クラウド・セキュリティの主要ベンダーが同じ6原則に合意した文書は、社内の稟議・監査対応・ベンダー評価で引用できる外部根拠になります。
4つの質問は、そのまま自社への問いになる
自社にエージェントは何体いて、それぞれ何ができて、いま何をしていて、暴走したときに誰がどう止めるのか。答えられない質問を明らかにし、対応するのが次の四半期の作業項目です。台帳が部分的なら棚卸しの範囲を広げる、停止手順が文書化されていなければエージェント1体を対象にトークン失効から再承認までを実際に試して手順を起こす。質問がそのままタスクに変換できる形になっているため、製品を買う前に着手できます。
注意すべき点が2つ
- 1つ目はベンダー間の信号連携がまだ完成していないことです。相互運用は構築・検証の途中で、結果と参照統合の公開は今後定期的に行うとされています。
- 2つ目は、Microsoftの不在です。Entraは多くの企業が認証基盤として使うIDサービスですが、アライアンスに参加しておらず、創設メンバー中のID専業ベンダーはOkta 1社、モデルベンダーのOpenAI・Anthropicも不参加です。
よくある誤解
誤解1：「業界標準ができたので、対応製品が出るまで待てばよい」
blueprint自身が、6原則のうちタスク単位の動的な権限付与と、複数ホップにまたがる委任の完全な追跡を「現時点のツーリングでは到達目標（aspirational）」と認めています。待っていても、台帳とオーナー割り当てとオフボーディングは誰も代わりにやってくれません。
誤解2：「Blueprint Alliance＝Oktaの新製品発表」
枠組みと商用実装は別物です。Oktaの新機能はGA・Q3・Q4に分かれて出荷されるため、「blueprint準拠」を謳う機能でも、自社テナントとライセンスで利用可否を個別に確認する必要があります。
誤解3：「うちはEntra中心だから関係ない」
参加ベンダーの製品を使っていなくても、4つの質問と6原則はベンダー非依存の設計原則として機能します。むしろEntra中心の組織ほど、Microsoftの実装がこの参照アーキテクチャと揃う保証がない分、自前の監査フレームを先に固める必要があります。
誤解4：「エージェントの発見はネットワーク監視だけで足りる」
blueprintは検出ポイントとして、クラウド基盤・ネットワーク出口・エンドポイント・ブラウザ・MDM・IoT/OT・メールとコラボレーショントラフィックまでを列挙しています。ユーザーの代理でメールやカレンダーを操作するエージェントは、ブラウザ通信の監視だけでは見えません。
実務で問題になりやすいポイント
以下3点が決まっていないことによる、台帳の形骸化
- エージェントを作れるのは誰か。
- どのテナント・どのリージョンで動かしてよいか。
- オーナーが異動・退職したら誰が止めるのか。
人間向けに構築したゼロトラスト基盤に、エージェントがそのまま乗らない
人間の条件付きアクセスは端末とセッションを前提にしますが、エージェントは委任元の人間がログオフした後も動き続けます。blueprintは、エージェントを「どこで動くか」で二つに分け、統制のかけ方を変えるよう整理しています。この切り分けは、自社の統制設計にそのまま流用できます。
| 区分 | 具体例 | blueprintが求める扱い | 自社での統制手段 |
|---|---|---|---|
| ホスト型（サーバー・クラウド上で稼働） | 業務システムに組み込んだ内製AIエージェント、SaaS付属エージェント、パイロット中の内製ツール | 従業員やサービスアカウントと同じ厳密さでプロビジョニング・認証・デプロビジョニングし、パイロットを含む全てを統制の枠内に置く | ID基盤（IdP）でのID登録とオーナー割り当て、短命トークン発行、JML連動の停止・剥奪 |
| ローカル型（従業員の端末上で実行） | 個人が導入したデスクトップ型AIツール、ブラウザ拡張、ローカル実行のコーディングエージェント | ディレクトリ登録ではなく、エンドポイントでの封じ込めで扱う | EDR・MDM・ブラウザ管理による検出と実行制御、端末隔離 |
見落とされがちな論点：監視の法的制約にも触れるというblueprintの指摘
blueprintは、発見・監視はプライバシー・雇用・労働・労使協議・データ保護の各規制に適合させ、透明性・比例性・データ最小化を確保すべきとしています。ブラウザセッションやメールフローの検査を伴うシャドーAI検出を有効化する前に、日本企業であれば個人情報保護法と就業規則・労使間の取り決めの確認が要ります。ここを飛ばすと、セキュリティ施策そのものが社内で止まります。
技術的・運用的な確認ポイント
4つの質問を、確認項目に分解します。
| 質問 | 確認すること | 具体的な打ち手 |
|---|---|---|
| Where are my agents?（発見と台帳） | 内製・SaaS付属・サードパーティ・ローカル導入のエージェントが1つの台帳に乗っているか | 各エージェントに責任者となる人間のオーナーを割り当てる。統制された実行経路の外で動くものにシャドーAIの印を付ける |
| What can they do?（権限） | 長期APIキーや人間からの借用クレデンシャルで動いていないか | IDに紐づく短命トークンへ置き換える。JML（入退社・異動）プロセスにエージェントのスコープ・オーナー・モデルバージョンを組み込む |
| What are they doing?（実行時） | MCPサーバーやスキルレジストリを無検査で信用していないか | レジストリ由来のツール定義を呼び出し前にスキャンし、エージェントコード・コンテナイメージ・モデル重みの来歴（SLSA attestationを含む）を本番投入前に検証する |
| How do I respond?（対応）―今回の追加分 | 止める手段と、戻す手順が文書化されているか | レート制限・トークン失効・セッション終了・ネットワーク隔離による限定的封じ込めと、再証明（re-attestation）・段階的再登録による復旧を定める |
対応方針の比較表
| 方針 | 向いている組織 | 利点 | リスク・限界 |
|---|---|---|---|
| 4つの質問を内部監査フレームとして即採用 | すべての組織 | 製品購入不要で今日から開始できる。ベンダー非依存 | 台帳整備の工数は自社負担 |
| Okta実装（Okta for AI Agents）で先行 | Okta利用中でエージェント本番導入が近い組織 | Agent SSO等はGA済み。短命トークン化を早期に実現 | Agent Gateway・Kill Switch拡張はQ3/Q4待ち。機能ごとのGA確認が必須 |
| Entra中心で独自に原則を実装 | Microsoft 365 / Entra中心の組織 | 既存投資を活用できる | Microsoftはアライアンス不参加で、参照アーキテクチャとの整合は保証されない |
| 相互運用標準（SSF/CAEP連携）の成熟を待つ | エージェント導入自体が当面ない組織 | 手戻りが少ない | 検証済み結果は未公表。その間もシャドーAIエージェントは増える |
見直し時のチェックリスト
- 内製・SaaS付属・サードパーティ・ローカル実行を含むエージェント台帳があり、各エージェントに人間のオーナーが割り当てられている
- エージェントの長期APIキー・借用クレデンシャルを棚卸しし、短命トークンへの置き換え計画がある
- オーナーの退職・異動時にエージェントを停止・再割り当てするフローが入退社・異動プロセスに組み込まれている
- MCPサーバー・スキルレジストリを信頼できない入力として扱い、利用前スキャンの手順がある
- エージェントのトークン失効・セッション終了・隔離の手順が文書化され、リハーサル済みである
- 封じ込め後の再承認・再登録手順が決まっている
- エンドポイント・ブラウザ・メールフロー監視の導入前に、プライバシー・労務面の確認を済ませている
- 「blueprint準拠」を謳うベンダー機能について、自社テナントでのGA状況とライセンス条件を個別確認している
経営層・監査部門への説明ポイント
経営層向けの説明ポイント
「ID・クラウド・セキュリティの主要12社が、AIエージェントを従業員と同じ厳密さで管理すべき対象だと公式に合意したため、自社もエージェントの台帳・オーナー・停止手順の整備を今期の経営課題として扱う必要があります」。この一文で伝わります。
ただし経営層が知りたいのは、発表の中身ではなく「なぜ自社が」「なぜ今なのか」です。次の表にて説明します。
| 問い | 説明の要旨 |
|---|---|
| なぜ自社に関係するのか | 生成AIエージェントは情シスの購買判断を経ず、業務部門の導入や契約済みSaaSのアップデートで社内に増える。それでも、社外に説明する責任は会社側に残る |
| なぜ今必要なのか | 生成AIエージェントは認証情報を持ち、委任した人間がログオフした後も動き続ける。台帳と停止手順がないまま数が増えれば、事故時に「何がどこまで触れたか」を特定できない。後からの棚卸しは、増えた分だけコストが上がる |
| なぜ製品購入ではないのか | ベンダー間の連携は構築・検証の途中で、製品の選択肢と価格は今後変わる。先に固めるべきは、どの製品を選んでも必要になる台帳と運用ルールである |
| 売上にどう影響するのか | 短期の受注には影響しない。差が出るのは、顧客データを操作する業務や基幹業務に生成AIエージェントを組み入れる段階から。台帳・オーナー・停止手順が揃っていれば、社内審査や取引先の調査票に答えながら導入を進められる。揃っていなければ、導入自体を見送るか、事故時に安全側へ倒して業務システムごと止めることになる。その分だけ、AI活用による売上寄与が先送りになる |
| 外部からはどこまで求められているのか | エージェントの台帳提出を一律に求める規制は、現時点ではない。ただしISO/IEC 42001は2023年12月に発行済みで、EU AI Actは高リスクAIの利用者（deployer）側にも人的監督とログ保存を課しており、Annex IIIの高リスクAIへの適用は2027年12月2日からである。要求が来る前にある程度進めておくことで、対応の遅れを抑えられる。 |
投資判断の説明では、順序を明確にすべきです。いま予算をつけるべきは高価なAIセキュリティ製品ではなく、台帳整備とオーナー制度とオフボーディングの運用です。製品側の相互運用はまだ検証中であり、来年には選択肢と価格が変わっている可能性が高いです。
監査部門向けの説明ポイント
4つの質問がそのまま監査項目の骨格になります。エージェントの網羅的な台帳、権限の妥当性、実行時の証跡、停止と復旧の手順。この4点は、既存のIT全般統制の言葉で説明できます。
実務担当者が次に取るべき対応ステップ
- 【今週】4つの質問を自社に問う。答えられない質問を特定し、ギャップとして記録する
- 【2週間以内】エージェント台帳の初版を作る。IdPのアプリ連携、SaaS管理コンソール、クラウド課金、CASB/SWGログを突き合わせ、オーナー・接続先・クレデンシャル種別を1枚にする
- 【1か月以内】停止手順を生成AIエージェント単位でリハーサルする。トークン失効・セッション終了で何が巻き添えになるかを確認し、再承認手順を文書化する
- 【四半期内】長期APIキーの短命トークン化計画と、JMLプロセスへのエージェント組み込みを設計する
- 【継続】アライアンスが公開予定の相互運用検証結果と、利用中ベンダーの機能GA状況を追跡する
まとめ
Blueprint Allianceが示したのは、完成した標準ではなく、業界が向かう方向と、今の製品ではまだ実現できていない部分の両方です。システムによる連携は待つしかありませんが、台帳と停止手順の整理は今から始められます。今週、自社の環境に4つの質問を問いかけてみてください。答えられなかった質問が、そのまま次の四半期の作業計画になります。
この記事が誰かの助けになれば嬉しいです。
FAQ
Q1. Blueprint Allianceとは何ですか？
A. 2026年9月22日にOktaがOktaneカンファレンスで発表した、AIエージェントを安全に統制するためのオープンなマルチベンダー参照アーキテクチャを推進する業界連合です。創設メンバーはOkta、AWS、CrowdStrike、Databricks、Docker、Google Cloud、Lovable、Proofpoint、Salesforce、ServiceNow、Wiz、Zscalerの12社です。
Q2. Blueprint Allianceは製品ですか？
A. 製品ではありません。成果物は共同執筆された参照アーキテクチャ文書で、ベンダー間の相互運用検証と参照実装は今後公開される予定です。
Q3. 「4つの質問」とは何ですか？
A. Where are my agents?（エージェントはどこにいるか）、What can they do?（何ができるか）、What are they doing?（何をしているか）、How do I respond?（どう対応するか）の4問です。2026年3月版blueprintの3問（Where are my agents? / What can they connect to? / What can they do?）から、実行時の監視と、インシデント対応・復旧を扱う質問を含む4問構成に再編されました。
Q4. Microsoftは参加していますか？
A. 参加していません。創設メンバーの中でID専業ベンダーはOkta 1社であり、OpenAIやAnthropicなどのモデルベンダーも不参加です。
Q5. 相互運用にはどの標準が使われますか？
A. MCP（Model Context Protocol）、OCSF、SSF（Shared Signals Framework）、CAEPの4標準を横断した信号連携を各社が構築・検証中で、ホワイトペーパーではHTTP Message Signatures（RFC 9421）も検証対象に挙げられています。
Q6. Oktaを使っていない企業にも意味がありますか？
A. あります。6原則と4つの質問はベンダー非依存の設計原則であり、エージェント台帳・オーナー制度・停止手順の整備はどのID基盤でも実行できます。
Q7. 何から始めるべきですか？
A. エージェント台帳の作成です。内製・SaaS付属・サードパーティ・ローカル実行のエージェントを洗い出し、各エージェントに人間のオーナーを割り当てることが、4つの質問すべての前提になります。
