AWS Security HubのAIインベントリ機能、検証結果と導入時のポイント

はじめに

今回は、2026年7月14日に発表されたAWS Security HubのAIインベントリ機能について説明します。

同機能は、組織内で利用されているAmazon BedrockやSageMakerなどのマネージドAIサービスに加え、EC2やECR上で稼働する自ホスト型のAIワークロードまでを自動的に検出し、一覧化するものです。シャドーAI対策やAIガバナンスの第一歩として、中央のセキュリティチームが組織全体のAI利用状況を把握できるようになる、実務上有用なアップデートかと思います。

同機能の基本的な検出方式やコンソール操作については、すでに他のブログ記事等で単一アカウント環境を対象に詳しく紹介されています。本稿では、本連載のテーマであるOrganizationsを利用したマルチアカウント環境に絞り、委任管理者アカウントから組織全体のAI資産がどのように集約表示されるのかを実機で確認します。

なお、AIインベントリは新しい統合Security Hubの機能であり、実際にOrganizations環境で使い始めるには、まずこの新しい統合Security Hub自体をマルチアカウント環境に導入する必要があります。本稿では、AIインベントリの検証そのものに加えて、その過程で遭遇した導入時の実務的なポイントもあわせて紹介します。

AIインベントリとは

AIインベントリは、新しい統合Security Hubが検出したAI/ML関連リソースを一覧化する機能です。この新しい統合Security Hubは、AWSのAPI（EnableSecurityHubV2など）やドキュメントのURL上で「Security Hub v2」と呼称されているため、本稿でも以降この呼び方を使用します。ただし、コンソールや発表文では単に「Security Hub」と表記されることが多く、正式な名称ではない点にご留意ください。

公式ドキュメントによると、検出方式はマネージド（Managed）と自ホスト（Self-hosted）の2種類に分類されます。

自ホストは、さらに以下の4つのリソースタイプに分類されます。

自ホスト型の検出では、SBOM等の複数のシグナルを組み合わせた確信度ベースの判定が行われており、しきい値を満たしたリソースのみがインベントリに表示される仕様です。AIインベントリはSecurity Hubの基本機能に含まれており、追加費用なく利用できます。

なお、上記の表にある「Inspectorの拡張スキャンモード」について、本稿の検証では単にInspectorのEC2スキャンを有効化するだけでは不十分で、Inspectorの「EC2スキャンのアップグレード」（Inspector VMスキャナーを使用するハイブリッドモード）まで行って初めて自ホスト型AIが検出されました。詳しくは後述の「自ホスト型AIが検出されない場合のトラブルシューティング」で説明します。

従来のSecurity Hub CSPMとの違い

第23回でSecurity Hub CSPMポリシーを紹介しましたが、今回のAIインベントリは、2025年12月のre:Inventで発表された新しい統合Security Hub（Security Hub v2）の機能です。以前からOrganizations環境で利用されてきたSecurity Hub CSPMとは別のプラットフォームである点に注意が必要です。

管理アカウントでSecurity Hubのコンソールにアクセスすると、次の画像のように「以前は Security Hub と呼ばれていたものが、Security Hub CSPM になりました。」という案内が表示されます。サイドメニューでも、GuardDutyやAmazon Inspector、Macieと並んで「Security Hub CSPM」が「検出エンジン」の一つとして表示されており、従来のSecurity Hub CSPMが新しい統合Security Hubにシグナルを提供する検出エンジンの一つという位置づけに変わったことがわかります。

• 

Security Hub v2とSecurity Hub CSPMは同一アカウント・同一リージョンで併用が可能です。委任管理者の扱いについては、公式ドキュメントに以下のような記載があります。

• 組織管理アカウント自身は、CSPMの委任管理者にはなれますが、v2の委任管理者にはなれません。v2では必ず別のAWSアカウントを委任管理者として指定する必要があります。
• 組織管理アカウントがすでにCSPMの委任管理者を設定済みの場合、そのアカウントが自動的にv2の委任管理者としても扱われます。この場合、v2側で委任管理者として指定できるのはそのアカウントのみです。
• CSPM側またはv2側のいずれかのコンソール・APIで委任管理者を解除すると、もう一方の委任管理者も連動して解除されます。

つまり、すでにCSPMの委任管理者を設定済みの環境では、v2のためにあらためて委任管理者を指定し直す必要はありません。一方で、v2を利用するには、後述の委任管理者ポリシーを別途作成する必要があります。

Organizationsへの信頼されたアクセス（trusted access）についても、公式ドキュメントのv2の委任管理者設定手順にはこれを有効化する操作が記載されておらず、CSPM有効化時にすでに許可されている場合はv2のために改めて有効化する必要はないと考えられます。後述する本稿の検証環境でも、Organizationsの「サービス」画面でSecurity Hubへの信頼されたアクセスは検証前から有効になっており、v2の利用にあたって新たに有効化する操作は行いませんでした。

検証環境

本稿では、下記のような構成で検証を行いました。

• 

管理アカウントとは別に委任管理者アカウントを設定し、その配下のメンバーアカウントにAI資産を配置した状態で、委任管理者アカウントからどのように見えるかを確認しています。委任管理者アカウント自体にはAI資産を配置していないため、委任管理者のAIインベントリ画面に表示されるAI資産は、すべてメンバーアカウント側で検出されたものになります。

メンバーアカウントに配置するAI資産としては、マネージド型・自ホスト型それぞれ最小コストで用意できるものを選びました。マネージド型は、当初Amazon Bedrockの基盤モデルをオンデマンドで呼び出す想定だったのですが、後述のとおりこれだけではAIインベントリに検出されないことがわかったため、検証用に最小コストのBedrock Guardrailを1つ作成しました（Guardrailは作成しただけでは追加料金がかかりません）。自ホスト型は、EC2インスタンス上でOllama（小型モデル）を稼働させて用意しました。

本稿の検証環境では、Security Hub CSPMの委任管理者を設定済みでした。下記のとおり、AWS Organizationsの「サービス」画面を確認すると、Security Hubへの信頼されたアクセスは過去に実施した設定が引き継がれており、すでに有効化されていました。

• 

このため、公式ドキュメント公式ドキュメントに記載のとおり、v2でも同じアカウントがそのまま委任管理者として扱われる状態でした。

管理アカウントでの操作

それでは、管理アカウントでの操作について説明します。前述のとおり、CSPMの委任管理者を設定済みの環境では、Organizationsへの信頼されたアクセスやv2の委任管理者指定について、あらためて操作を行う必要はありませんでした。

（1）Security Hub v2のコンソール（https://console.aws.amazon.com/securityhub/v2/home）にアクセスし、ナビゲーションペインから「一般」を選択します。CSPMの委任管理者が未設定の環境では、ここで「設定」を選択し、委任管理者に指定するAWSアカウントの12桁のアカウントIDを入力・保存します。

• 

（2）本稿の検証環境ではCSPMの委任管理者を設定済みだったため、「一般」画面の「委任された管理者」欄には、名前・アカウントID・Eメール・組織IDといった委任管理者アカウントの情報がすでに表示されていました。ここで改めてアカウントを指定する操作は不要でした。

• 

（3）ただし、同じ画面の上部と「委任された管理者に関するポリシー」欄には、「委任された管理者に Security Hub を管理するために必要な権限がありません。委任ポリシーを更新して、委任された管理者に Security Hub の組織ポリシーを設定する権限を付与します。」という警告が表示されていました。委任管理者アカウント自体は自動的に認識される一方で、Security Hubの組織ポリシーを管理するための権限（委任管理者ポリシー）については、別途確認が必要という状態のようでした。

• 

第33回で解説したとおり、委任管理者アカウントに対する委任ポリシーはサービスごとに別文書ではなく1つのJSON文書に統合されています。本稿の検証環境でも、第28回で紹介したInspectorポリシーの導入時などに追加された既存のステートメントがすでにアタッチされた状態でしたが、それでも上記の警告が表示されていました。

（4）「ポリシーの更新」ボタンをクリックします。

• 

Security Hubが提案するポリシーの内容を確認する画面が表示されます。

• 

筆者の環境では、ここで提示された提案ポリシーの内容は、すでにアタッチされていた既存の委任ポリシーと完全に同一でした。つまり、必要な権限自体はすでにそろっていたことになります。

（5）それでも画面の案内に従って保存したところ、警告表示は解消されました。

• 

必要な権限自体はすでにそろっていたにもかかわらず警告が表示されていたことから、Security Hub側の権限チェックがなんらかの理由で一時的に古い状態を参照していたか、画面表示の更新にタイムラグがあったと考えられます。本稿執筆時点でのSecurity Hub v2はGAから間もないこともあり、こうした表示上の不整合が起こることもあるようです。同様の警告が表示された場合は、まず「ポリシーの更新」を実行してみることをおすすめします。

委任管理者アカウントでの操作

次に、委任管理者アカウントでの操作に移ります。なお、ここで登場する設定カタログの「ポリシー」「デプロイ」は、前段の「委任管理者ポリシー」（委任管理者アカウントにSecurity HubやOrganizationsの操作権限を与えるリソースベースポリシー）とは別物です。こちらは、Security Hubの各種機能を組織全体に強制するための設定を指します。

（1）委任管理者アカウントにサインインし、Security Hub v2のコンソール（https://console.aws.amazon.com/securityhub/v2/home）を開きます。委任管理者アカウントでは、サイドメニューに管理アカウントには表示されない「管理」セクションが追加されており、その配下からも「設定」にアクセスできます

• 

（2）「一般」ページを開き、「委任された管理者」欄を確認します。管理アカウントの操作で確認したのと同じ内容が表示されますが、委任管理者アカウント自身でこの画面を開いた場合は、アカウントIDの横に「（このアカウント）」というタグが表示されるため、自アカウントが組織の委任管理者であることを確認できます。

• 

（3）サイドメニューの「管理」から「設定」を開きます。「設定済みポリシー」タブでは、この時点ではまだ何もポリシーが設定されておらず、「ポリシーなし」と表示されていました。

• 

（4）「設定」ボタンをクリックすると、「設定カタログ」タブが開きます。組織全体に対して機能を一括設定するためのカタログが用意されており、「Security Hub（必須機能とその他の機能）」「GuardDutyによる脅威分析」「Security Hub CSPMによる体制管理」「Amazon Inspectorによる脆弱性管理」などが並んでいました。今回は推奨マークが付いている「Security Hub（必須機能とその他の機能）」の「Security Hubの設定」ボタンを選択します。

• 

（5）ステップ1「Security Hubの設定」画面で、ポリシー名（本稿ではSecurityHubV2-AllFeatures-Workloads）を入力し、「セキュリティ機能」で「すべての機能を有効にする」を選択します。これにより、セキュリティ管理に加えて、Amazon Security Hub CSPMによる体制管理、Amazon GuardDutyによる脅威分析、Amazon Inspectorによる脆弱性管理までまとめて有効化される内容になっていました。

• 

（6）「アカウントの選択」では、検証環境の都合上「特定の組織単位とアカウント」を選択し、「組織内で選択」からWorkloads OUのみにチェックを入れました。「リージョンの選択」では「有効または無効にするリージョンを指定する」を選択し、「特定のリージョンを有効化する」でap-northeast-1（東京）とap-northeast-3（大阪）を指定しました。全社的に導入する場合は「すべての組織単位とアカウント」を選択することになるかと思います。

• 

• 

（7）ステップ2「クロスリージョン集約の設定」（オプション）が表示されます。ホームリージョンとしてAsia Pacific（Tokyo）- ap-northeast-1を選択し、リンクされたリージョンとしてAsia Pacific（Osaka）- ap-northeast-3にチェックを入れて、「次へ」をクリックします。

• 

• 

（8）ステップ3「確認して適用」画面が表示されます。ここで、選択した「Security Hub（必須機能とその他の機能）」は、内部的に以下の4つのポリシー・デプロイに分割されて適用されることがわかります。

継続的に組織へ強制する設定は「ポリシー」、その時点で一度だけ実行される設定は「デプロイ」として明確に区別されているようです。内容を確認し、「適用」をクリックします。

• 

• 

（9）ところが、「適用」をクリックしたところ、以下のエラーが表示されました。

クロスリージョン設定の更新中にエラーが発生しました Security Hub V2 is not enabled for {委任管理者アカウントID}

「設定ステータス」を確認すると、セキュリティ管理・脆弱性管理・脅威分析（GuardDuty）は「設定済み」となった一方、体制管理（Security Hub CSPM）は「設定に失敗しました」という状態でした。「設定済みポリシー」タブにも、ポリシータイプの2件（セキュリティ管理・脆弱性管理）のみが表示されています。

• 

エラーメッセージにある{委任管理者アカウントID}は、委任管理者アカウント自身のアカウントIDでした。つまり、委任管理者アカウントとして組織全体にSecurity Hubの機能をデプロイする操作はできるものの、委任管理者アカウント自身ではSecurity Hub v2が有効化されていなかったために、ホームリージョンを自身に設定するクロスリージョン集約の更新と、Security Hub CSPMのデプロイが失敗しました。委任管理者に指定されることと、そのアカウント自身でSecurity Hub v2を有効化することは別の操作である、という点に注意が必要です。

（10）そこで、委任管理者アカウント自身でもSecurity Hub v2を有効化します。Security Hubのトップページに戻ると、先ほどのエラーバナーとともに「新しいSecurity Hubをお試しください」という案内が表示されているので、「使用を開始」をクリックします。

• 

「Security Hubの有効化」画面が表示され、セキュリティ管理・Amazon Security Hub CSPMによる体制管理・Amazon GuardDutyによる脅威分析・Amazon Inspectorによる脆弱性管理のすべてにチェックが入った状態になっていました。なお、この画面には「Security Hub とその機能は、現在のリージョン（ap-northeast-1）でのみ有効になります。追加のリージョンやアカウントに拡張するには、オンボーディング後に設定ポリシーを使用してください。」と案内されており、ここでの有効化はあくまで委任管理者アカウント自身・現在のリージョンに閉じたものであることがわかります。「Security Hub の有効化」をクリックします。

• 

（11）有効化が完了すると、Security Hubの「概要」ダッシュボードに切り替わります。サイドメニューには新たに「インベントリ」という項目が追加され、その配下に「AIインベントリ」のメニューが表示されるようになりました。

• 

• 

（12）改めて手順3～9のポリシー設定をやり直すため、いったん前回作成したポリシーを削除し、「設定済みポリシー」タブが「ポリシーなし」の状態に戻ったことを確認しました。

• 

（13）同じ内容（ポリシー名SecurityHubV2-AllFeatures-Workloads、すべての機能を有効にする、対象はWorkloads OU、リージョンはap-northeast-1・ap-northeast-3）で再度設定し直したところ、今度は「体制管理」（Security Hub CSPM）の欄に「2リージョンでの設定が失敗しました」と表示されました。エラーの詳細を開くと、以下のように表示されていました。

エラーの詳細 Account {WorkloadアカウントID} is managed by a configuration policy ap-northeast-3, ap-northeast-1

セキュリティ管理・脆弱性管理・脅威分析（GuardDuty）は問題なく設定済みとなった一方、体制管理（Security Hub CSPM）のみがこのエラーで失敗しました。

• 

このエラーの原因は、Workloads OU配下のメンバーアカウントが、すでに別のSecurity Hub CSPMの設定ポリシー（configuration policy）によって集中管理（centrally managed）されていたことでした。第23回で紹介したように、Security Hub CSPMには組織全体を一元管理する「中央設定（central configuration）」という仕組みがあります。公式ドキュメントの「Configuration policy association」の定義によれば、設定ポリシーとアカウント・OUとの関連付けは、別の設定が適用または継承されるまで維持されるとされており、1つのアカウント・OUが同時に複数の設定ポリシーに関連付けられることは想定されていないと考えられます。

今回のWorkloadsアカウントは、すでに第23回で構築したCSPMの設定ポリシーに関連付けられていたため、Security Hub v2側から新たに「体制管理」のデプロイ（内部的にはSecurity Hub CSPMの設定ポリシーを作成・関連付けする処理）を行おうとしても、二重に関連付けることができずエラーになったと考えられます。

つまり、すでにSecurity Hub CSPMの中央設定でアカウント・OUを管理している環境で、Security Hub v2の「すべての機能を有効にする」からまとめて体制管理をデプロイしようとすると、既存のCSPM設定ポリシーとの二重関連付けエラーが起こりえます。

このような環境では、Security Hub v2の設定カタログで「体制管理」を個別に選ばず、既存のCSPM設定ポリシー側でそのまま管理を続ける（Security Hub v2側では対象から外す）といった整理が必要になりそうです。マネージド型AIリソースの検出自体はSecurity Hub CSPMの有効化有無に関係なく機能するため、AIインベントリの検証を進めるうえでは、この体制管理のエラーは無視して先に進んでも支障はありませんでした。

機能確認

委任管理者アカウントのAIインベントリページを開き、委任管理者アカウント自体には配置していないAI資産、すなわちメンバーアカウント（Workloadアカウント）側のAI資産が表示されることを確認します。マネージド型については、Bedrock Guardrailを作成してから時間を置いて確認したところ、無事に検出されました。

一方、自ホスト型（Ollamaを稼働させたEC2インスタンス）については、Amazon Inspectorのスキャンが成功した状態でも、しばらく経ってもAIインベントリに検出されませんでした。この点については次項で詳しく説明します。

AIインベントリページでは、アカウントID・リソースタイプ・検出方式・モデルIDなどでグルーピングやフィルタリングが可能です。実際に「トップ10アカウント」のクイックフィルターにも、WorkloadsアカウントのアカウントIDと検出件数が表示されており、委任管理者アカウントからメンバーアカウントのAI資産をアカウント単位で把握できることが確認できました。今回はメンバーアカウントが1つのみのため一覧としてはシンプルですが、メンバーアカウントが増えた場合も同じ画面でアカウント単位の内訳を把握できる点は変わりません。

• 

自ホスト型AIが検出されない場合のトラブルシューティング

自ホスト型AIリソースが検出されない状態が続いたため調査を進めたところ、対象EC2インスタンスは従来のエージェントベーススキャン（Inspector SSM Plugin）を使用しており、AI資産の検出に必要なVMスキャンが実施されていないことがわかりました。AI資産の検出には、Inspector VMスキャナーを使用したEC2スキャンのアップグレードが必要です。

委任管理者アカウント（Inspectorの委任管理者アカウントでもあります）で、以下の手順でEC2スキャンをアップグレードします。

（1）Amazon Inspectorのコンソールで「設定」→「スキャン設定」（仮想マシンタブ）を開きます。「Inspector EC2 スキャンをアップグレード」というバナーが表示されており、この時点のスキャンモードは「エージェントベース」でした。「アップグレードを開始する」をクリックします。

• 

（2）確認モーダルが表示されます。「スキャンモードを選択」では、推奨（デフォルトで選択済み）の「ハイブリッドモードにアップグレード」を選択したまま「確認」をクリックします。ハイブリッドモードでは、SSM管理下のEC2インスタンスにはエージェントベースのスキャン（アップグレード後はInspector VMスキャナーを使用）が、SSM管理外のインスタンスにはEBSスナップショットを使うエージェントレススキャンが使用されます。

• 

重要： このアップグレードは組織に対する一度限りの決定です。モーダルにも「EC2スキャンのアップグレードなしでは、アカウントを元の状態に戻すことはできません。」と明記されており、この設定はOrganizations内のすべてのアカウントに適用されます。実施前に影響範囲を確認してください。

（3）「リクエストが成功しました。スキャンモードの更新がスケジュールされています。」というバナーが表示され、スキャンモードは一時的に「への更新は保留中です ハイブリッド」という表示になります。

• 

（4）しばらく待つと、スキャンモードが正式に「ハイブリッド」に切り替わります。

• 

（5）AWS Systems Managerの「ステートマネージャー」→「関連付け」を確認すると、InspectorVmScannerDistributor-do-not-deleteという関連付けが作成されており、Inspector VMスキャナーが対象EC2インスタンスへ自動的にインストール・更新されます。

（6）この関連付けが対象インスタンスに対して成功すると、Security HubのAIインベントリに自ホスト型AI資産が反映されます。本稿の検証環境でも、しばらく待った後に確認したところ、「合計AIアセット」が6件（セルフホスト1件、マネージド5件）となり、リソースタイプにSelfHosted::AI::InferenceEndpointが1件追加されているのを確認できました。

• 

公式ドキュメントによると、Inspector VMスキャナーはデフォルトで3時間ごとに実行されます。初回のエージェント配布・スキャン・Security Hub側での取り込みまでを考慮すると、反映までに数時間程度かかることを見込んでおくとよいでしょう。それでも表示されない場合は、以下を確認してください。

• InspectorVmScannerDistributor-do-not-deleteの対象EC2インスタンスに対する実行結果が成功していること
• 対象EC2インスタンスがSystems Managerの管理対象ノードとして「Online」であること
• 自ホスト型AIのソフトウェア（本稿ではOllama）がVMスキャナー有効化後も対象EC2インスタンス上で稼働していること
• Inspector・Security Hub・EC2インスタンスが同じリージョンであること

自アカウントの範囲でしか確認できないメンバーアカウント側の画面とは異なり、委任管理者アカウントからは自身が管理するメンバーアカウントのAI資産を横断的に把握できます。この管理アカウント・委任管理者アカウント・メンバーアカウントという権限構造を踏まえたうえでAIインベントリを運用できる点が、Organizations環境ならではのポイントだと言えるでしょう。多数のメンバーアカウントを抱える共通基盤の運営者にとって、メンバーアカウントが増えても同じ委任管理者の画面から一元的に把握できる点は、シャドーAI対策の足がかりとして有用かと思います。

課題・注意点

最後に、本稿の検証で見えてきた課題や注意点を、AIインベントリ自体の話と、Security Hub v2の導入に関する話に分けて紹介します。

AIインベントリ利用時の注意点

（1）マネージド型AIの検出は、AWS Configが追跡しているBedrockのリソース（Guardrail、カスタムモデル、プロビジョンドスループット、Agent、Knowledge Baseなど）が対象です。Amazon Bedrockの基盤モデルをInvokeModelなどでオンデマンド呼び出ししているだけでは、永続的なリソースが作成されないためAWS Config側に何も記録されず、AIインベントリにも表示されません。オンデマンド呼び出しのみでBedrockを利用している環境では、Guardrail等の永続的なリソースを何も作成していない限り、AIインベントリ上は「AI利用なし」に見えてしまう可能性がある点にご注意ください。

（2）自ホスト型AIの検出には、Amazon InspectorのEC2スキャンを「ハイブリッドモード」（Inspector VMスキャナーを使用）にアップグレードしておく必要があります。これは、aws inspector2 get-ec2-deep-inspection-configurationなどで確認できる従来の「仮想マシンの詳細検査（ディープインスペクション）」とは別の設定であり、両者は名称が似ているため混同しやすい点にご注意ください。詳しい手順は前述の「自ホスト型AIが検出されない場合のトラブルシューティング」を参照してください。なお、このアップグレードはOrganizations全体に対する一度限りの設定であり、元に戻すことはできません。

（3）自ホスト型AIの検出は、本稿執筆時点ではEC2インスタンスとECRイメージのみが対象です。LambdaやFargate、EKSのマネージド型コンピューティングから外部AI APIを呼び出しているケースは検出対象外となるため、これらのサービスを多用している環境では、検出結果がAI利用実態の一部にとどまる可能性がある点にご注意ください。

（4）Security Hubでは、脆弱性や設定不備などリソースごとのセキュリティ上の懸念点は「Findings」として通知されます。しかし自ホスト型AIリソースについては、本稿執筆時点ではこのFindingsが生成されません。つまり、AIインベントリによって自ホスト型AIリソースの存在は把握できても、そのリソースにセキュリティ上の問題があるかどうかまでは通知されないということです。Findingsが確認できるのはマネージド型AIリソースのみのため、自ホスト型AIを多用している環境では、インベントリで存在を把握したうえで、脆弱性診断などは別途実施する必要がある点にご注意ください。

Security Hub v2導入時の注意点

（1）Security Hub CSPMの委任管理者とv2の委任管理者は連動しており、v2だけを別のアカウントに指定することはできません。CSPMの委任管理者を解除すると、v2の委任管理者も連動して解除される点にもご注意ください。すでにCSPMの委任管理者アカウントの運用が固まっている環境では、そのままv2でも同じアカウントを使う前提で運用を設計するとよいでしょう。

（2）すでにSecurity Hub CSPMの中央設定（第23回参照）でアカウントやOUを集中管理している環境では、Security Hub v2の設定カタログから「すべての機能を有効にする」で体制管理までまとめてデプロイしようとすると、既存のCSPM設定ポリシーとの二重関連付けエラーになることがあります。委任管理者アカウントでの操作の手順で述べたとおり、この場合は体制管理を個別対象から外し、CSPM側の中央設定をそのまま使い続けるといった整理が必要です。

おわりに

今回はAWS Security HubのAIインベントリ機能について、Organizations環境における委任管理者アカウントからの集約表示を中心に説明しました。マネージド型・自ホスト型それぞれの検出方式には制約もありますが、組織全体のAI利用状況を一元的に把握できる仕組みが標準機能として提供された意義は大きいかと思います。本稿が、マルチアカウント環境におけるAIガバナンスの第一歩の参考になれば幸いです。