AWSは2026年7月14日、Security HubのAIインベントリ機能を発表した。この機能は、組織内で利用されているAmazon BedrockやSageMakerなどのマネージドAIサービスに加え、EC2やECR上で稼働する自ホスト型のAIワークロードまでを自動的に検出し、一覧化する。シャドーAI対策やAIガバナンスの第一歩として、中央のセキュリティチームが組織全体のAI利用状況を把握できるようになる。
AIインベントリの検出方式
AIインベントリは、新しい統合Security Hub（Security Hub v2）が検出したAI/ML関連リソースを一覧化する機能だ。検出方式はマネージドと自ホストの2種類に分類される。
マネージド型は、Amazon Bedrock、Bedrock AgentCore、Amazon SageMakerの一部リソースが対象で、AWS Configの構成アイテムから検出される。追加設定は不要で、Security Hubの有効化のみで機能する。
自ホスト型は、EC2インスタンスおよびECRイメージ上で稼働するモデル・推論エンドポイント・エージェント、およびEC2から呼び出される外部AIサービスのドメインが対象だ。Amazon InspectorのSBOM分析とGuardDutyのDNSアクティビティから検出される。自ホスト型はさらに、モデル（Hugging Face、Ollama）、推論エンドポイント（vLLM、Ollama、TorchServe、Tritonなど）、エージェント（OpenClaw）、外部エンドポイント（OpenAIやAnthropicなどのドメイン）の4つのリソースタイプに分類される。
自ホスト型の検出では、SBOM等の複数のシグナルを組み合わせた確信度ベースの判定が行われており、しきい値を満たしたリソースのみがインベントリに表示される。AIインベントリはSecurity Hubの基本機能に含まれており、追加費用なく利用できる。
Organizations環境での検証
本稿では、管理アカウントとは別に委任管理者アカウントを設定し、その配下のメンバーアカウントにAI資産を配置した状態で、委任管理者アカウントからどのように見えるかを確認した。委任管理者アカウント自体にはAI資産を配置していないため、表示されるAI資産はすべてメンバーアカウント側で検出されたものになる。
メンバーアカウントには、マネージド型として最小コストのBedrock Guardrailを1つ作成し、自ホスト型としてEC2インスタンス上でOllama（小型モデル）を稼働させた。検証環境では、Security Hub CSPMの委任管理者を設定済みで、Organizationsへの信頼されたアクセスも有効だったため、v2でも同じアカウントがそのまま委任管理者として扱われた。
管理アカウントでの操作では、CSPMの委任管理者が設定済みの環境ではv2の委任管理者指定を改めて行う必要はなかった。ただし、「委任された管理者に関するポリシー」欄に警告が表示されたため、「ポリシーの更新」を実行したところ、警告は解消された。必要な権限自体はすでにそろっていたにもかかわらず警告が表示されていたことから、権限チェックが一時的に古い状態を参照していたか、画面表示の更新にタイムラグがあったと考えられる。
委任管理者アカウントでの操作では、設定カタログから「Security Hub（必須機能とその他の機能）」を選択し、ポリシー名を入力して「すべての機能を有効にする」を選択した。対象はWorkloads OU、リージョンはap-northeast-1（東京）とap-northeast-3（大阪）を指定した。ステップ3で「適用」をクリックしたところ、クロスリージョン設定の更新中にエラーが発生した。エラーメッセージには「Security Hub V2 is not enabled for {委任管理者アカウントID}」と表示され、委任管理者アカウント自身でSecurity Hub v2が有効化されていなかったことが原因だった。
委任管理者アカウント自身でSecurity Hub v2を有効化した後、再度ポリシーを設定し直したところ、今度は「体制管理」（Security Hub CSPM）の欄に「2リージョンでの設定が失敗しました」と表示された。エラーの詳細には「Account {WorkloadアカウントID} is managed by a configuration policy」と表示され、Workloads OU配下のメンバーアカウントがすでに別のSecurity Hub CSPMの設定ポリシーによって集中管理されていたことが原因だった。1つのアカウント・OUが同時に複数の設定ポリシーに関連付けられることは想定されていないため、二重に関連付けることができずエラーになったと考えられる。
機能確認とトラブルシューティング
委任管理者アカウントのAIインベントリページを開くと、メンバーアカウント側のAI資産が表示されることを確認した。マネージド型のBedrock Guardrailは無事に検出されたが、自ホスト型のOllamaはしばらく経っても検出されなかった。
調査の結果、対象EC2インスタンスは従来のエージェントベーススキャン（Inspector SSM Plugin）を使用しており、AI資産の検出に必要なVMスキャンが実施されていないことがわかった。AI資産の検出には、Inspector VMスキャナーを使用したEC2スキャンのアップグレードが必要だ。委任管理者アカウントで「EC2スキャンをアップグレード」を実行し、ハイブリッドモードにアップグレードしたところ、しばらく待った後にAIインベントリに自ホスト型AI資産が反映された。合計AIアセットは6件（セルフホスト1件、マネージド5件）となり、リソースタイプにSelfHosted::AI::InferenceEndpointが1件追加された。
このアップグレードはOrganizations全体に対する一度限りの決定であり、元に戻すことはできない。モーダルにも「EC2スキャンのアップグレードなしでは、アカウントを元の状態に戻すことはできません。」と明記されている。
課題と注意点
AIインベントリ利用時の注意点として、まずマネージド型AIの検出はAWS Configが追跡しているBedrockのリソース（Guardrail、カスタムモデル、プロビジョンドスループット、Agent、Knowledge Baseなど）が対象であり、基盤モデルをオンデマンド呼び出ししているだけでは検出されない点が挙げられる。次に、自ホスト型AIの検出にはInspectorのEC2スキャンをハイブリッドモードにアップグレードしておく必要があり、これは従来の「ディープインスペクション」とは別の設定だ。また、自ホスト型AIの検出は現時点ではEC2とECRのみが対象で、LambdaやFargate、EKSから外部AI APIを呼び出しているケースは検出対象外となる。さらに、自ホスト型AIリソースについてはFindingsが生成されないため、セキュリティ上の問題の有無は別途確認する必要がある。
Security Hub v2導入時の注意点として、CSPMの委任管理者とv2の委任管理者は連動しており、v2だけを別のアカウントに指定することはできない。また、すでにCSPMの中央設定でアカウントやOUを管理している環境では、v2の設定カタログから「すべての機能を有効にする」で体制管理までまとめてデプロイしようとすると、既存のCSPM設定ポリシーとの二重関連付けエラーになることがある。この場合は体制管理を個別対象から外し、CSPM側の中央設定をそのまま使い続けるといった整理が必要だ。
AIインベントリは、マネージド型・自ホスト型それぞれの検出方式に制約はあるものの、組織全体のAI利用状況を一元的に把握できる仕組みが標準機能として提供された点で意義が大きい。多数のメンバーアカウントを抱える環境では、委任管理者の画面から一元的に把握できる点がシャドーAI対策の足がかりとして有用だ。
