G-gen の佐々木です。当記事では、Cloud Run サービスに https://<サブドメイン>.cloud.run 形式の短い URL を割り当てる機能、 カスタム URL （Custom URLs）について解説します。 概要 Cloud Run とは カスタム URL とは ドメインマッピングとの違い カスタム URL の基本 仕組み 命名規則 文字と長さの規則 サブドメインの一意性 使用できない単語 認証 ID トークンの検査 カスタムオーディエンス 設定の有無による応答の違い 制限事項 注意点 上り（内向き）を制限したサービス 削除したサブドメインは第三者が取得できる サービスを削除してもマッピングは残る 反映には時間がかかる 料金 設定手順 事前準備 新規サービスへの割り当て 既存サービスへのマッピング カスタムオーディエンスの設定 カスタム URL の削除 別のサービスへの移動 動作確認 カスタム URL へのアクセス デフォルト URL の無効化 audience ごとの認証結果 サービスを削除した場合 概要 Cloud Run とは Cloud Run は、Google Cloud のサーバーレスなコンテナ実行サービスです。HTTP リクエストを処理する サービス （service）をデプロイすると、サービスごとに HTTPS のエンドポイントが自動で割り当てられます。 当記事では、この自動で割り当てられる URL を デフォルト URL と呼びます。デフォルト URL は、サービス名、プロジェクト番号、リージョンから決まる run.app ドメインの URL です。 参考 : HTTPS リクエストで呼び出す - 決定論的 URL Cloud Run の基本については、以下の記事を参照してください。 blog.g-gen.co.jp カスタム URL とは カスタム URL （Custom URLs）は、Cloud Run サービスに https://<サブドメイン>.cloud.run 形式の URL を割り当てる機能です。サブドメインの部分はユーザーが指定します。 URL の種類 形式 デフォルト URL https://<サービス名>-<プロジェクト番号>.<リージョン>.run.app カスタム URL https://<サブドメイン>.cloud.run 参考 : カスタム URL を作成する カスタム URL の使用に当たり、独自ドメインの取得、DNS レコードの設定、ロードバランサの構築はいずれも不要で、コマンド1つで URL を割り当てられます。サービスを短く覚えやすい URL で共有したい場面で使用できます。 Cloud Run のカスタム URL には、以下の特徴があります。 https://<サブドメイン>.cloud.run という短い形式の URL をサービスに割り当てられる デフォルト URL と同様に、どこからでもアクセスできる 新しいリビジョンをデプロイせずに、URL の割り当てや解除、別のサービスへの割り当て直しができる 1つのサービスに複数のカスタム URL を割り当てられる 2026年10月現在、カスタム URL は Preview 公開の機能です。Preview 段階の機能は、サポートが限定される場合や、一般公開（GA）までに仕様が変わる可能性があるため、本番環境での使用は推奨されません。 参考 : Preview版のサービスを使うとはどういうことなのか - G-gen Tech Blog ドメインマッピングとの違い Cloud Run ではカスタム URL とは別に、独自ドメインをサービスに割り当てる ドメインマッピング という機能があります。カスタム URL は、gcloud CLI ではドメインマッピングと同じコマンドで操作しますが、性質は異なります。 カスタム URL は、Google が管理する cloud.run ドメインのサブドメインを使用します。ドメインマッピングの設定に必要なドメインの所有権確認や DNS レコードの設定は、カスタム URL では不要です。 比較項目 カスタム URL ドメインマッピング URL のドメイン cloud.run （Google が管理） ユーザー独自のドメイン ドメインの所有権確認 不要 必要 DNS レコードの設定 不要 必要 TLS 証明書 発行を待つ必要がない マッピング後に自動発行（通常15分程度、最大24時間） 提供ステータス Preview 公開 Preview 公開 なお、ドメインマッピングには、東京リージョン（asia-northeast1）などで呼び出しのレイテンシが非常に大きくなる既知の問題があり、2026年10月現在も解消されていません。 本番環境で独自ドメインを使用したい場合は、グローバル外部アプリケーションロードバランサを使用する方法が推奨されています。 参考 : カスタム ドメインのマッピング 参考 : Cloud Run の既知の問題 - 一部のリージョンからの呼び出し時にカスタム ドメインでリクエスト レイテンシが増加する カスタム URL の基本 仕組み カスタム URL は、サブドメインとサービスを対応付ける マッピング として管理されます。マッピングはサービスとは独立したリソースです。 そのため、マッピングの作成や削除では、サービスの新しいリビジョンは作成されません。1つのサービスに複数のマッピングを作成することもできます。 サブドメインは Google Cloud 全体で一意ですが、マッピング自体はサービスと同じリージョンに作成されるリージョンリソースです。 1つのサービスに複数のマッピングを作成できる cloud.run ドメインは未使用のサブドメインを含めてワイルドカードで名前解決され、TLS 証明書も *.cloud.run のワイルドカード証明書が使用されます。 そのため、マッピングごとに DNS の反映や証明書の発行を待つ必要がありません。ただし、マッピングの作成後、リクエストが安定してサービスに届くまでには時間がかかります。この点は注意点の節で説明します。 命名規則 文字と長さの規則 サブドメインは、以下の規則に従って指定します。 長さは6〜63文字 使用できる文字は小文字の英数字とハイフン 先頭と末尾は小文字の英数字 規則に違反するサブドメインを指定すると、以下のエラーになります。 # 5文字のサブドメインを指定した場合 $ gcloud beta run domain-mappings create \ --service = my-service-b \ --region = asia-northeast1 \ --project =< プロジェクトID > \ --domain = sshun.cloud.run ----- 出力例 ----- ERROR: ( gcloud.beta.run.domain-mappings.create ) INVALID_ARGUMENT: metadata.name: The subdomain ' sshun ' cannot be used as a valid custom URL. It must be 6-63 characters long, start and end with a lowercase alphanumeric character, and can only contain lowercase alphanumeric characters and hyphens. - ' @type ' : type .googleapis.com/google.rpc.BadRequest fieldViolations: - description: The subdomain ' sshun ' cannot be used as a valid custom URL. It must be 6-63 characters long, start and end with a lowercase alphanumeric character, and can only contain lowercase alphanumeric characters and hyphens. field: metadata.name 検証では、大文字を含むサブドメインも作成できました。ただし、小文字のサブドメインとは別のマッピングとして登録され、2つのマッピングが併存する状態になります。URL のホスト名は大文字と小文字を区別しないため、サブドメインは小文字で指定してください。 参考 : カスタム URL を作成する - 制限事項 サブドメインの一意性 サブドメインは Google Cloud 全体で一意です。すでに使用されているサブドメインを指定すると、以下のエラーになります。 # 別のプロジェクトで使用中のサブドメインを指定した場合 $ gcloud beta run domain-mappings create \ --service = hello \ --region = asia-northeast1 \ --project =< 別のプロジェクトID > \ --domain =< サブドメイン > .cloud.run ----- 出力例 ----- ERROR: ( gcloud.beta.run.domain-mappings.create ) Domain mapping to [< サブドメイン > .cloud.run ] already exists in this region. メッセージには「in this region」とありますが、他のリージョンや他のプロジェクトで使用中の場合も同じメッセージが表示されます。リージョンを変えても解決しないため、別のサブドメインを指定します。 使用できない単語 一部のサブドメインは使用が制限されています。2026年10月現在、制限対象の一覧は公式ドキュメントに記載されていません。 検証では、ハイフンで区切った単語のいずれかが特定の単語と一致する場合に、以下のエラーになりました。 # 末尾の単語が lb のサブドメインを指定した場合 $ gcloud beta run domain-mappings create \ --region = asia-northeast1 \ --project =< プロジェクトID > \ --service = my-service-c \ --domain = sasashun-ingress-lb.cloud.run ----- 出力例 ----- ERROR: ( gcloud.beta.run.domain-mappings.create ) INVALID_ARGUMENT: metadata.name: The subdomain ' sasashun-ingress-lb ' contains the prohibited term ' lb ' and cannot be used in Cloud Run custom URL. - ' @type ' : type .googleapis.com/google.rpc.BadRequest fieldViolations: - description: The subdomain ' sasashun-ingress-lb ' contains the prohibited term ' lb ' and cannot be used in Cloud Run custom URL. field: metadata.name 検証で拒否された単語は google 、 youtube 、 gemini 、 internal 、 lb 、 admin 、 www 、 auth の8つです。Google の製品名だけでなく、環境や用途を表す一般的な単語も含まれます。 一方、 internal2 のように単語が完全には一致しない場合や、ハイフンで区切らずに他の文字列と連結した場合は作成できました。ここに挙げた単語は検証で確認できた例であり、制限対象のすべてではありません。 参考 : カスタム URL を作成する - 制限事項 認証 ID トークンの検査 カスタム URL 経由のリクエストにも、デフォルト URL と同じくサービスの IAM 認証が適用されます。認証が必要なサービスでは、呼び出し元は Google が署名した ID トークンをリクエストに付与します。認証が必要なサービスは、受け取った ID トークンを2段階で検査します。 まず、トークンの宛先を示す audience （ aud クレーム）がサービス宛てかを確認します。次に、トークンの主体がサービスを呼び出す権限（Cloud Run 起動元、 roles/run.invoker ）を持つかを IAM で確認します。 audience が一致しない場合の応答は 401 です。トークンがない場合や、トークンの主体に権限がない場合の応答は 403 です。カスタム URL が関係するのは、前者の audience の検査だけです。 参考 : サービス間認証 カスタムオーディエンス Cloud Run がサービス宛てと判定する audience は、サービスのデフォルト URL です。サービス側で受け入れる audience の値を追加する設定を、Cloud Run では カスタムオーディエンス と呼びます。 カスタム URL をマッピングしても、カスタム URL が自動で audience として受け入れられることはありません。以下は、Cloud Run や Compute Engine 上で動作する呼び出し元が、メタデータサーバーから audience を指定して ID トークンを取得する例です。 # audience にデフォルト URL を指定して ID トークンを取得 $ curl -s -H " Metadata-Flavor: Google " \ " http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://<サービス名>-<プロジェクト番号>.<リージョン>.run.app " # audience にカスタム URL を指定して ID トークンを取得 $ curl -s -H " Metadata-Flavor: Google " \ " http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://<サブドメイン>.cloud.run " 1つ目のコマンドで取得したトークンは、カスタムオーディエンスを設定しなくても、カスタム URL 経由の呼び出しに使用できます。 2つ目のコマンドで取得したトークンは、カスタムオーディエンスを設定していないサービスでは使用できません。audience がサービス宛てと判定されず、応答は 401 になります。 このトークンを使用するには、サービスに https://<サブドメイン>.cloud.run をカスタムオーディエンスとして設定します。 カスタムオーディエンスが必要になるのは、呼び出し元が audience にカスタム URL を指定する場合です。 Cloud Scheduler や Pub/Sub の push サブスクリプションのように、呼び出し先の URL をそのまま audience にするサービスから、カスタム URL 宛てに呼び出す構成が典型です。 参考 : サービスにカスタム オーディエンスを設定する 設定の有無による応答の違い サービスの認証設定、ID トークンの audience、カスタムオーディエンスの組み合わせごとに、カスタム URL を呼び出した結果を整理すると以下のとおりです。 サービスの認証設定 ID トークンの audience カスタムオーディエンス 応答 未認証アクセスを許可 トークンなし 設定の有無に無関係 200 認証が必要 トークンなし 設定の有無に無関係 403 認証が必要 デフォルト URL 設定の有無に無関係 200 認証が必要 カスタム URL 設定なし 401 認証が必要 カスタム URL カスタム URL を設定 200 カスタムオーディエンスの設定で結果が変わるのは、表の下2行だけです。サービス側の設定手順は、「カスタムオーディエンスの設定」の節で説明します。 制限事項 2026年10月現在、カスタム URL には以下の制限事項があります。 デフォルトでは、1つのプロジェクトにマッピングできるドメインは最大50件 カスタム URL だけを一時的に無効化することはできず、トラフィックの提供を止めるにはマッピングを削除する 上り（内向き）の設定を「内部」または「内部と Cloud Load Balancing」に制限しているサービスではサポートされない Terraform はサポートされない 不正利用の防止や商標の保護などを理由に、Google がサブドメインを取り消す、または再割り当てする場合がある なお、カスタム URL はデフォルト URL から独立しています。サービスのデフォルト URL を無効化しても、カスタム URL は引き続き使用できます。 参考 : カスタム URL を作成する - 制限事項 参考 : Cloud Run のネットワーク上り（内向き）を制限する - デフォルトの URL を無効にする 注意点 上り（内向き）を制限したサービス 上り（内向き）を「内部」または「内部と Cloud Load Balancing」に制限しているサービスは、カスタム URL をサポートしていません。 検証では、上り（内向き）を「内部」に制限したサービスに対しても、マッピングの作成はエラーにならず、マッピングの状態も正常と表示されました。しかし、インターネットからカスタム URL にアクセスすると 404 が返ります。 設定が成功したように見えても、インターネットからはアクセスできない状態になります。このようなサービスでは、カスタム URL を使用せず、デフォルト URL を使用してください。 参考 : Cloud Run のネットワーク上り（内向き）を制限する 削除したサブドメインは第三者が取得できる マッピングを削除すると、そのサブドメインは即座に他のユーザーが取得できる状態になります。 第三者に同じサブドメインを取得されると、以前の URL を知っている利用者が第三者のサービスにアクセスするおそれがあります。一度設定したマッピングの削除には、このリスクが伴います。削除は必要な場合に限り、削除と再作成を繰り返す運用は避けてください。 参考 : カスタム URL を作成する - カスタム URL を削除する サービスを削除してもマッピングは残る マッピング済みのサービスを削除しても、マッピングは自動では削除されません。サブドメインは占有されたままになり、プロジェクトあたりの上限も消費し続けます。 検証では、残ったマッピングは、同じ名前のサービスを再度デプロイすると新しいサービスへルーティングされました。意図しないサービスがカスタム URL で公開されないよう、不要になったマッピングは明示的に削除することを推奨します。 反映には時間がかかる 公式ドキュメントでは、既知の問題として、マッピングの作成後に完全に動作するまで数秒かかる場合があるとされています。 検証では、作成から約2分間は、正常な応答と 404 が混在しました。別のサービスへ移動した場合も、移動前のサービスがしばらく応答を続けます。詳細は動作確認の章で示します。 参考 : カスタム URL を作成する - 既知の問題 料金 2026年10月現在、カスタム URL の使用に追加の料金はかかりません。サービスの実行にかかる料金は、カスタム URL の有無で変わりません。 設定手順 事前準備 以降では、gcloud CLI でカスタム URL の割り当て、確認、削除、移動を行います。コンソールでも同等の操作が可能で、サービスの作成フォームやドメインマッピングのページからカスタム URL を追加できます。 検証は東京リージョン（asia-northeast1）で行いました。gcloud CLI のバージョンは以下のとおりです。 # gcloud CLI のバージョンを確認 $ gcloud version ----- 出力例 ----- Google Cloud SDK 587 . 0 . 0 beta 2026 . 09 . 25 // 省略 core 2026 . 09 . 25 // 省略 2026年10月現在、カスタム URL の操作には gcloud beta run コマンドを使用します。 gcloud CLI のバージョンが古い場合、 --domain に .cloud.run のサブドメインを指定すると以下のエラーになります。 # 古いバージョンの gcloud CLI でカスタム URL を指定した場合 $ gcloud beta run domain-mappings create \ --service = my-service-a \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- ERROR: ( gcloud.beta.run.domain-mappings.create ) The provided domain does not appear to be verified for the current account. To verify it, run: $ gcloud domains verify < サブドメイン > .cloud.run Once verified, try this command again. Currently verified domains: * < 所有権を確認済みのドメイン > メッセージはドメインの所有権確認を案内していますが、 cloud.run は Google が管理するドメインであり、ユーザーが所有権を確認することはできません。このエラーが表示された場合は、 gcloud components update コマンドで gcloud CLI を更新します。 マッピングはリージョンリソースのため、操作時にはリージョンの指定が必要です。gcloud CLI の run/region プロパティを設定していない環境で --region を省略すると、 You must specify a region. というエラーになります。 当記事のコマンドは、すべて --region を指定しています。 マッピングを作成、更新、削除するユーザーには、プロジェクトレベルで Cloud Run 管理者（ roles/run.admin ）が必要です。 参考 : カスタム URL を作成する - 必要なロール 新規サービスへの割り当て gcloud beta run deploy コマンドの --domain に <サブドメイン>.cloud.run を指定すると、サービスのデプロイと同時にカスタム URL を割り当てられます。 コンテナイメージには、Google が提供するサンプルイメージ us-docker.pkg.dev/cloudrun/container/hello:latest を使用しました。 # カスタム URL を指定してサービスをデプロイ $ gcloud beta run deploy my-service-a \ --image = us-docker.pkg.dev/cloudrun/container/hello:latest \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Allow unauthenticated invocations to [ my-service -a] ( y/N ) ? Deploying container to Cloud Run service [ my-service -a] in project [< プロジェクトID >] region [ asia-northeast1 ] Deploying new service... Creating Revision................................................................done Creating domain mapping................................................done Routing traffic...done Creating domain mapping...done Done. Service [ my-service -a] revision [ my-service-a-00001-fmh ] has been deployed and is serving 100 percent of traffic. Service URL: https://my-service-a- < プロジェクト番号 > .asia-northeast1.run.app Proxy locally with: gcloud run services proxy my-service-a --region asia-northeast1 --project < プロジェクトID > 出力の Creating domain mapping の行が、カスタム URL のマッピングの作成を示しています。 Service URL にはデフォルト URL のみが表示され、カスタム URL は表示されません。 作成されたマッピングは、 gcloud beta run domain-mappings list コマンドで一覧表示できます。複数のリージョンにサービスがある場合は、リージョンごとに実行します。 # リージョン内のマッピングを一覧表示 $ gcloud beta run domain-mappings list --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- DOMAIN SERVICE REGION ✔ < サブドメイン > .cloud.run my-service-a asia-northeast1 マッピングの詳細は gcloud beta run domain-mappings describe コマンドで表示します。 # マッピングの詳細を表示 $ gcloud beta run domain-mappings describe \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- apiVersion: domains.cloudrun.com/v1 kind: DomainMapping // 省略 spec: routeName: my-service-a status: conditions: - lastTransitionTime: ' 2026-09-30T06:27:48.748572Z ' status: ' True ' type: Ready - lastTransitionTime: ' 2026-09-30T06:27:48.748572Z ' status: ' True ' type: DomainRoutable mappedRouteName: my-service-a observedGeneration: 1 参考 : gcloud beta run deploy 既存サービスへのマッピング 既存のサービスにカスタム URL をマッピングするには、 gcloud beta run domain-mappings create コマンドを使用します。 --service にサービス名、 --domain に <サブドメイン>.cloud.run を指定します。 # 既存のサービスにカスタム URL をマッピング $ gcloud beta run domain-mappings create \ --service = my-service-a \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Creating...... .............done. サブドメインを変えて同じコマンドを繰り返すと、1つのサービスに複数のカスタム URL をマッピングできます。 参考 : gcloud beta run domain-mappings create カスタムオーディエンスの設定 audience にカスタム URL を指定した ID トークンを受け入れるには、サービスにカスタムオーディエンスを設定します。 カスタムオーディエンスの値は、トークンの audience と文字列として完全一致で照合されます。 https:// の有無や末尾のスラッシュが異なるだけでも一致しません。 たとえば <サブドメイン>.cloud.run のようにスキーム（ https:// ）なしの値を設定した場合、受け入れられるのは audience が <サブドメイン>.cloud.run のトークンだけです。 audience に https://<サブドメイン>.cloud.run を指定したトークンは 401 になります。 呼び出し元が audience に指定する値は、呼び出し先の URL 全体（ https:// 付き）であるのが通例です。そのため当記事では、 https://<サブドメイン>.cloud.run をカスタムオーディエンスとして設定します。 以下は、カスタム URL をマッピング済みで認証が必要なサービス my-service-b に設定する例です。 # サービスにカスタムオーディエンスを追加 $ gcloud beta run services update my-service-b \ --add-custom-audiences = https:// < サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Deploying... Creating Revision.............................................................done Routing traffic.....done Done. Service [ my-service -b] revision [ my-service-b-00003-fbp ] has been deployed and is serving 100 percent of traffic. Service URL: https://my-service-b- < プロジェクト番号 > .asia-northeast1.run.app Proxy locally with: gcloud run services proxy my-service-b --region asia-northeast1 --project < プロジェクトID > マッピングの作成や削除とは異なり、カスタムオーディエンスの設定では新しいリビジョンが作成されます。 呼び出し元では、ここで設定した値と同じ文字列を audience に指定して ID トークンを取得します。Cloud Scheduler や Pub/Sub の push サブスクリプションのように、audience を設定項目として持つサービスでは、同じ値を設定します。 参考 : カスタム URL を作成する - カスタム オーディエンスで保護する カスタム URL の削除 カスタム URL を削除するには、 gcloud beta run domain-mappings delete コマンドを使用します。 # カスタム URL のマッピングを削除 $ gcloud beta run domain-mappings delete \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > \ --quiet ----- 出力例 ----- Deleting [< サブドメイン > .cloud.run ] ... ..............done. Mappings to [< サブドメイン > .cloud.run ] now have been deleted. 前述のとおり、削除したサブドメインは即座に他のユーザーが取得できる状態になります。今後も使用する可能性があるサブドメインは、削除せずに保持してください。 参考 : gcloud beta run domain-mappings delete 別のサービスへの移動 カスタム URL のマッピング先を直接変更するコマンドはありません。カスタム URL を別のサービスへ移動するには、マッピングを削除してから、移動先のサービスを指定して同じサブドメインのマッピングを作成し直します。 # 削除したサブドメインを、移動先のサービスにマッピング $ gcloud beta run domain-mappings create \ --service = my-service-b \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Creating...... ...........done. 削除から再作成までの間は、サブドメインが解放された状態になります。第三者に取得されないよう、削除と再作成は続けて実行します。 動作確認 カスタム URL へのアクセス カスタム URL をマッピングしたサービスを、カスタム URL 経由で呼び出します。サービスは認証が必要な設定のため、実行ユーザーの ID トークンをリクエストに付与します。 # ID トークンを付けてカスタム URL を呼び出し、ステータスコードを表示 $ curl -s -o /dev/null -w ' %{http_code}\n ' \ -H " Authorization: Bearer $( gcloud auth print-identity-token ) " \ https:// < サブドメイン > .cloud.run/ ----- 出力例 ----- 200 ただし、マッピングの作成直後は 404 が返る場合があります。以下は、マッピングの作成直後から2秒間隔でカスタム URL を呼び出した結果です（時刻は UTC）。マッピングの作成が完了した時刻は 06:29:47 です。 # ID トークンを取得 $ TOKEN = $( gcloud auth print-identity-token ) # 2秒間隔でカスタム URL を呼び出し、時刻とステータスコードを表示 $ for n in $( seq 1 75 ) ; do STATUS = $( curl -s -o /dev/null -w ' %{http_code} ' \ -H " Authorization: Bearer $TOKEN " \ https:// < サブドメイン > .cloud.run/ ) echo " $( date -u +%H:%M:%S ) $STATUS " sleep 2 done ----- 出力例 ----- 06:29:49 404 06:29:51 404 06:29:53 404 06:29:55 404 06:29:57 404 06:29:59 404 06:30:02 200 06:30:04 200 06:30:06 200 06:30:08 200 06:30:10 200 06:30:12 404 06:30:14 200 06:30:16 200 06:30:19 200 06:30:21 404 06:30:23 200 06:30:25 200 06:30:27 404 06:30:29 404 06:30:31 200 // 省略 最初の 200 は作成完了の15秒後に返りましたが、その後も 200 と 404 が混在しました。最後の 404 は作成完了の111秒後で、それ以降はすべて 200 でした。 この 404 は、未使用のサブドメインにアクセスした場合と同じ応答です。マッピングの作成後は、2分程度待ってから動作を確認してください。 別のサービスへ移動した場合は、切り替えがさらに不連続になります。検証では、マッピングの削除後も約10秒間は移動前のサービスが応答しました。 再作成後の約2分間は、移動前のサービスの応答、移動先のサービスの応答、404 が混在しました。移動前のサービスの応答は、削除の約6分後にも1回観測しています。 カスタム URL の移動は、切り替えの瞬間を制御できません。移動前と移動先のどちらのサービスが応答しても問題のない状態で実施してください。 デフォルト URL の無効化 カスタム URL をマッピングしたサービスのデフォルト URL を無効化し、カスタム URL だけで呼び出せることを確認します。デフォルト URL は、 gcloud run services update コマンドの --no-default-url で無効化します。 # サービスのデフォルト URL を無効化 $ gcloud run services update my-service-a \ --no-default-url \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Updating... Done. Service [ my-service -a] has been updated. 無効化の前後で、ID トークンを付けて各 URL を呼び出した結果は以下のとおりです。 呼び出し先 無効化前 無効化後 デフォルト URL 200 404 カスタム URL 200 200 デフォルト URL を無効化した後も、カスタム URL は引き続き使用できます。デフォルト URL を元に戻すには --default-url を指定します。 参考 : Cloud Run のネットワーク上り（内向き）を制限する - デフォルトの URL を無効にする audience ごとの認証結果 認証が必要なサービス my-service-b に対して、audience の異なる ID トークンでカスタム URL を呼び出し、カスタムオーディエンスの設定による違いを確認します。 audience を指定した ID トークンは、サービスアカウントの権限借用で発行します。ユーザーアカウントの ID トークンは audience を指定できないためです。サービスアカウントには、サービスレベルで Cloud Run 起動元（ roles/run.invoker ）を付与しています。 以下は、カスタムオーディエンスを設定していない状態で、audience にカスタム URL を指定したトークンを使用した例です。 # audience を指定して ID トークンを発行 $ TOKEN = $( gcloud auth print-identity-token \ --impersonate-service-account =< サービスアカウントのメールアドレス > \ --audiences = https:// < サブドメイン > .cloud.run ) # ID トークンを付けてカスタム URL を呼び出し、ステータスコードを表示 $ curl -s -o /dev/null -w ' %{http_code}\n ' \ -H " Authorization: Bearer $TOKEN " \ https:// < サブドメイン > .cloud.run/ ----- 出力例 ----- 401 カスタムオーディエンスの設定前後で、3種類の audience で呼び出した結果は以下のとおりです。 トークンの audience カスタムオーディエンス設定なし https://<サブドメイン>.cloud.run を設定 デフォルト URL 200 200 https://<サブドメイン>.cloud.run 401 200 https://<サブドメイン>.cloud.run/ 401 401 末尾にスラッシュを付けた audience は、設定後も 401 です。カスタムオーディエンスの値と、呼び出し元が指定する audience は、末尾のスラッシュの有無まで一致させる必要があります。 audience が一致しない場合の応答は以下のとおりです。 # audience が一致しない ID トークンで呼び出した場合 $ curl -si -H " Authorization: Bearer $TOKEN " https:// < サブドメイン > .cloud.run/ ----- 出力例 ----- HTTP/ 2 401 www-authenticate: Bearer error = " invalid_token " error_description = " The access token could not be verified " // 省略 サービスを削除した場合 カスタム URL をマッピング済みのサービス my-service-d を削除し、マッピングの状態を確認します。サービスの削除後にマッピングを一覧表示すると、マッピングは残っており、先頭の記号が X に変わっています。 # サービスの削除後にマッピングを一覧表示 $ gcloud beta run domain-mappings list --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- DOMAIN SERVICE REGION // 省略 X < サブドメイン > .cloud.run my-service-d asia-northeast1 この状態でカスタム URL にアクセスすると 404 が返ります。 残ったマッピングのサブドメインを、他のサービスや他のプロジェクトから指定しても、使用中のエラーになります。サブドメインを解放するには、マッピングを明示的に削除する必要があります。 続けて、同じ名前のサービスを再度デプロイすると、残っていたマッピングは新しいサービスへルーティングされ、カスタム URL は再デプロイの直後から 200 を返しました。 サービスを削除するときは、マッピングも合わせて削除するか、保持する場合は同じ名前のサービスが意図せず公開されないよう管理してください。 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は時計と007(映画)がマイブーム Follow @sasashun0805

この記事は 2026 年 8 月 4 日に公開された Guidance for an AI-Powered Studio on AWS を翻訳したものです。 生成 AI は、スタジオのプレミアムコンテンツ制作のあり方を根本から書き換えつつあります。映画品質の画像、動画、音声、3D アセットを生成できるモデルは日々更新されており、それらがもたらすクリエイティブな可能性には期待が高まるばかりです。具体的には、制作期間の短縮、予算内でできることの拡大、アーティストの創造性の解放、そして従来は資金面で実現困難だったストーリーの制作が可能になります。しかし、AI は高品質なコンテンツを自動的に生成する魔法のボタンではありません。AI は、熟練したストーリーテラーが活用することで、より速く、より高品質で、よりコスト効率の良いアウトプットの創出を支援し得る、非常に効率的なツールなのです。しかし、たとえ巧みに使いこなしたとしても、「モデルにはこれができる」と「制作チームがこれを納品できる」との間にはギャップがあり、まさにそこが不明瞭になりやすいポイントです。 AI モデルによるコンテンツ制作は日々容易になっていますが、依然として困難は残ります。どのモデルがどのアセットを作ったかの追跡、タスクの適切なモデルへのルーティング、ソースフッテージ (撮影素材) と生成メディアを共有カタログへの取り込み、予算の超過を伴わないクリエイティブな変更の反映、自社 IP を使った独自モデルの学習、そしてすべてのフレームに追跡可能かつ人間が関与した系譜 (リネージ、コンテンツの来歴) を残すこと——課題は尽きません。これらは制作インフラの課題であり、Amazon Web Services (AWS) はスタジオがクリエイティブな作業に集中できるよう、それらを解決するためのマネージドなビルディングブロックを提供します。 Amazon Web Services は、スタジオがクリエイティブな作業に集中できるよう、 これらの制作インフラの課題を解決するためのマネージドなビルディングブロックを提供します。 本ガイダンスでは、AI-Powered Studio (AI を活用したスタジオ)というコンセプトを紹介します。これは、上記の課題に対処するために設計されたプラットフォームアーキテクチャです。このアーキテクチャは、AI 生成コンテンツから価値を引き出すために必要な 5 つのコアな役割を軸に構成されています。 5 つの C Consistency (一貫性) — キャラクターやブランドにおいて、複数のショット、シーン、番組にわたって同じ見た目を安定して再現・制作できることが求められます。あるカメラアングルから別のアングルに切り替わっても、キャラクターや小道具の連続性を保つことは、視聴者の没入感を損なわないために不可欠です。 Context (コンテキスト) — キャラクターやブランドの一貫性は、一枚のビジュアルが生成される前の段階にあるアイデアやデザインから生まれます。すべてはストーリーから始まるのであって、画像単体からではありません。コンテキストこそが、一貫性を築くための土台です。 Control (コントロール) — フレームの他の部分に影響を与えることなく、正確かつ的を絞った編集ができる能力です。ひとつのオブジェクトを変更するだけでショット全体が再構築されてしまうようでは、アーティストはクリエイティブの主導権を失い、ワークフローは遅く予測不能なものになります。 Compliance (コンプライアンス) — 制作で使用するツールや IP が法的にクリアされていることを保証するには、AI のスピードに対応できるようプロセスの改善が必要です。さらに、IP 所有権の要件を満たすために、コンテンツの来歴を厳密に追跡できるよう拡張しなければなりません。 Cost (コスト) — AI によるコンテンツ生成が従来の方法よりコストがかかるなら、導入するビジネス上の理由はありません。スタジオには、予期しない請求額に膨張しないよう、明確なコスト可視性と支出コントロールが必要です。 本ガイダンスにおけるすべてのアーキテクチャの決定は、これらの役割を果たすためのものです。続くセクションでは、モデル非依存のルーティング、ビジュアル一貫性の手法、構造化されたコンテキスト、来歴の記録、そして統一アセットカタログが、それぞれどのようにこれらの役割の実現に貢献するかを説明します。 AI 対応スタジオが直面する共通の課題 AI 制作は本質的にマルチモデルであり、モジュール型のオーケストレーションが必要 — 最高の動画モデルが最高の画像モデルとは限らず、最高の画像モデルが最高の音声モデルとも限りません。しかもこの状況は常に変化しています。商用 SaaS とオープンソースソリューション間の競争環境 (どちらも頻繁にリーダーシップの入れ替えが発生) は、画期的な機能がすぐにコモディティ化することを意味し、単一のツールに長期的にコミットすることはリスクを伴います。この流動性ゆえに、スタジオは「どのモデルが最良か」という問いに事前に答えようとするよりも、アーティストがその時々で最適なモデルを活用できるようにする方法に注力すべきです。本ガイダンスは、クリエイティブチームがプロバイダーを横断して最適なモデルにアクセスし、パイプラインを書き換えることなく必要に応じてモデルを切り替えるプロセスを効率化する仕組みを提示します。 ML プラットフォームチームなしでの独自モデルの学習 — キャラクターデザイン、環境、モーションスタイルなどのスタジオ独自の IP でモデルをファインチューニングすることは、汎用モデルでは実現できないビジュアルの一貫性を保持することで大きな価値を生みます。しかし、ファインチューニングされたモデルをクリエイターの手に届けるまでの技術的ハードルは高く、GPU 基盤、ML エンジニアリングの専門知識、バージョニング、サービングパイプラインが必要です。クリエイティブワークは本質的に反復的であるため、これは一回限りの英雄的な取り組みであってはなりません。再現可能なセルフサービスの仕組みでなければなりません。アーティストは、チケットを発行したり ML-Ops チームを待つことなく、ファインチューニングをトリガーし、結果を検証し、再学習し、更新されたモデルをデプロイできる必要があります。現状、このワークフローを構築するのは複雑なエンジニアリングプロジェクトです。だからこそ、ファインチューニングはアクセスしやすく使いやすいものでなければならず、AI-Powered Studio はそれをすぐに使える状態で提供する必要があります。 アセットの来歴 (プロベナンス) 管理はデリバリーゲート — スタジオは、AI の使用が自社制作物の著作権が認められなくなるのではないかと懸念しており、コンテンツの来歴を追跡するため、すべてのアセットに対して改ざん不可能な制作履歴の記録 (どのモデル、どのパラメータ、どの入力リファレンス、どの人的修正が行われたか) を強制する手段を模索しています。現状、こうした記録は存在しないか、場当たり的に管理されているに過ぎません。スタジオに必要なのは、事後に再構成するのではなく、アーティストの作業中に自動的かつ強制的に記録が行われる仕組みです。来歴管理が手動プロセスであればスケールしません。クリエイティブプロセスに内在していなければならないのです。だからこそ、制作の一部として来歴を扱うガバナンスレイヤーが不可欠です。 コンテンツのアクセシビリティ — 実写制作では、セットで撮影されたフッテージ (デイリーズ／ラッシュ、プレート／実写撮影素材、リファレンスフレーム／基準フレーム) が生成され、下流の AI ワークフローがそれを活用する必要があります。プレートのライティングに合った新しい環境を生成したり、AI キャラクターを実写シーンに合成したりするには、そのフッテージにアクセスできなければなりません。ソース素材が生成出力とは異なるシステムにある場合、アーティストはカタログの照合やファイルの移動に時間を浪費し、制作に充てる時間が失われます。だからこそ、安全でアクセス可能な場所にコンテンツを集中させることがプロセスの基盤となる必要があるのです。 プロダクションスケールでのワークフロー管理 — 1 つの番組は 1 つの生成リクエストではなく、映画、シーズン、エピソード、部門、レビューサイクルにまたがる数百から数千のリクエストによって作られます。スタジオには構造化されたプロジェクト状態、ロールバック付きバージョニング、依存関係追跡、承認チェーンが必要です。生成レイヤーはこれらのシステムの外側に存在するのではなく、それらに接続されるべきです。これが、ワークフローの各ステップが同一のマネージドプラットフォームを経由すべき理由です。 AI 支援制作の反復的な性質 — クリエイティブプロセスは本質的に反復的です。1 回の生成で納品可能なアウトプットが得られると期待すべきではありません。AI を活用した制作現場からのフィードバックによると、チームは 1 ショットあたり平均 2 〜 10 個の異なる AI モデルを利用しています。複数回の処理、複数のモデル、複数回の生成はコンテンツ制作プロセスの一部です。だからこそ、プラットフォームはこの反復をネイティブにサポートする必要があります。処理をまたいだバージョンの追跡、ある処理は画像モデルに通し次の処理は動画モデルに通すといった柔軟なルーティング、そして手作業の記録管理に頼ることなくすべての来歴を一貫して維持できる仕組みが求められます。 これらの課題は複合的です。モデルルーティングを解決しても来歴管理が未解決であれば、制作スピードは上がってもマネタイズできないリスクを抱えます。モデルの学習を解決してもアセット管理を解決しなければ、ファインチューニング済みモデルが生成したアウトプットを誰も見つけられません。最大の価値は、これらを単一のプラットフォーム上で、差別化に繋がらない運用負荷なしにスケールするインフラの上でまとめて解決することにあります。 AI-Powered Studio：コンセプチュアルアーキテクチャ AI-Powered Studio の中核は、 Amazon API Gateway 、 AWS Lambda 、 Amazon DynamoDB などのサービスを活用したサーバーレスのオーケストレーションアプリケーションです。クリエイターや管理チームがアプリケーションにアクセスできるようにする Web UI レイヤーが構築されていること、またモデル呼び出しを処理する推論エンジンレイヤーが利用可能であることを前提としています。このアーキテクチャを特徴づけるのは、生成 AI 制作特有の要求に踏み込んでいる点です。具体的には、複数のモデルバックエンドへのルーティング、学習と推論の疎結合な受け渡し、そしてドキュメントの欠如が納品の障壁にならないよう来歴を自動的に記録する仕組みです。以降のセクションでは、これらの設計判断について詳しく説明します。 図 1: AWS 上の AI-Powered Studio のリファレンスアーキテクチャ 設定によるモデル非依存のルーティング AI-Powered Studio は、ルーティングレイヤーで2つの目的を果たします。第一に、異なるモデルバックエンドに対してアーティストやパイプラインがやり取りの方法を統一する、共通の API サーフェスとのインターフェースを提供します。モデルへのアクセスは Amazon Bedrock 経由、サードパーティ API 経由、またはセルフホストのエンドポイント経由のいずれでも可能です。プラットフォームが認証方式、パラメータ仕様、出力形式の違いを吸収するため、あるプロバイダーから別のプロバイダーへの切り替えにあたって、その上に構築されたクリエイティブツールを変更する必要はありません。第二に、最適なモデルが明確なタスクタイプに対してはオプションの自動ルーティング (例：テキスト分析は常に LLM にルーティング) を可能にしつつ、クリエイティブな判断が重要な場合にはアーティストがモデルを明示的に選択することも可能にします。どちらの動作もアプリケーションコードではなく設定により制御できます。 AWS AppConfig を使用すれば、モデルごとのランタイム設定 (パラメータ、エンドポイントターゲット、選択ロジック) をマネージド設定として保持でき、コード変更なしにデプロイし、問題が発生した場合は安全にロールバックできます。これはガバナンスの仕組みでもあります。プロダクションリーダーシップに、クリエイティブの速度を制限することなく、モデルの利用可否、許容されるパラメータ、ルーティングタスクの可視性と制御を提供します。 これにより、モデルの切り替えは開発リリースではなく、設定のデプロイで実現できます。カタログへの新モデルの追加、特定のタスクタイプの任意のモデルへのルーティング、手動選択用の新モデルの有効化は、スプリント単位ではなく当日中に実装できます。モデルリリースのペースを考えると、先月の最先端を使うか今月の最先端を使うかは大きな差になり得ます。一般的な実装では、ルーティングは以下の 3 種類のバックエンドに分岐します。 Foundation language models (基盤言語モデル) — スクリプトをシーンに分解し、ショットを記述するために使用されます。Amazon Bedrockは単一の API を通じて高性能な基盤モデル (FM) の選択肢を提供するため、プラットフォームは GPU インフラのプロビジョニングや管理を行うことなく、タスクに最適な基盤モデルにアクセスできます。Amazon Bedrock はリクエスト量に応じて弾力的にスケールするため、開発中の少数のスクリプト分解からエピソード制作の繁忙期における数千件の処理まで、キャパシティプランニング、リザーブドインスタンス、スプリント間のアイドル GPU なしに対応できます。 画像、動画、音声、3D 生成 — AWS パートナーやモデルアグリゲーター (例：fal.ai) を通じて、統一された API 呼び出しで生成モデルにアクセスできます。生成された出力は顧客の Amazon Simple Storage Service (Amazon S3) バケットに直接書き込まれるため、他のすべてのアセットと同じ下流のアセットパスに合流します。 セルフホストモデル — AWS は、 Amazon Elastic Compute Cloud (EC2) 、 Amazon SageMaker 、 AWS Deadline Cloud など、GPU ベースのインフラ上でオープンソースおよびカスタムモデルをホストする複数の方法を提供しています。Deadline Cloud はバッチコンピューティングおよびレンダリング管理を簡素化するフルマネージドサービスであり、スタジオ固有の IP でファインチューニングされたモデルをマネージド GPU 上で推論実行することが可能です。この手法は、学習データとモデルをスタジオの管理下に置く必要があるタスクに適しています。ComfyUI などの業界標準ソフトウェアは、EC2 インスタンス や Amazon Elastic Kubernetes Service (EKS) コンテナにデプロイでき、アプリケーションレイヤー (アーティストインターフェース) またはコンテンツ生成サービスオーケストレーターとして機能し、プロフェッショナルチームにきめ細かい制御を提供します。 図 2: バックエンドの生成タスクに利用可能な複数のモデルを表示する、モデル選択・ルーティングインターフェースの例 ビジュアル一貫性の実現：ファインチューニングとリファレンスコンディショニング 制作における生成物は、確立されたクリエイティブビジョンと一貫していなければなりません。承認済みのキャラクターデザイン、環境のスタイル、モーション言語と、すべてのショットで一致している必要があります。事前学習済みモデルでこの一貫性を実現する主要な手法は 2 つあり、よく設計された AI-Powered Studio は、どちらか一方を優位に位置づけるのではなく、補完的なワークフローの選択肢として両方をサポートすべきです。 Low-Rank Adaptations (LoRA) によるファインチューニング は、軽量なモデル特化の学習を行い、モデルに対象の分散的な概念を与えるアーティファクトを生成します。優れたアイデンティティ LoRA とは、モデルが単に開始画像を参照するのではなく、対象の完全な 3D アイデンティティを内在化していることを意味し、これにより新しいポーズ、ライティング条件、構図にわたって一貫した生成が可能になります。トレードオフとして、ファインチューニングにはこれらのアーティファクトを生成・バージョン管理するための初期コンピュートリソース、時間、ML オペレーションの専門知識が必要です。Amazon SageMaker AI がトレーニングインフラを管理し、生成された LoRA アーティファクトをバージョン管理されたアセットとして Amazon S3 に保存します。SageMaker AI や Deadline Cloud などの AWS コンピュートサービスが、これらのアーティファクトを使用したオンデマンド推論を可能にします。 リファレンスコンディショニング は、推論時にリファレンスとなるビジュアルや画像をモデルに渡す手法です。リファレンスコンディショニングは、画像生成・動画生成の両方において一貫性を実現する補完的なアプローチを提供します。モデルに対象を学習させるのではなく、アーティストが承認済みのリファレンス画像をアセットカタログから取得し、プロンプトとともに生成モデルに渡します。メリットとしては、初期コストの低減 (学習が不要)、本番投入までの時間短縮、完全な監査可能性 (すべての入力画像が来歴管理チェーンで追跡可能)、そしてモデルが学習した近似値ではなく実際のリファレンスを見ているため、繰り返し登場するキャラクターやオブジェクトに対してより正確なディテールの再現が期待できる点が挙げられます。トレードオフとしては、リファレンスコンディショニングは生成リクエストごとにより多くのコンピュートリソースを消費します。モデルが各呼び出し時にリファレンス画像を処理する必要があるためです。対照的に、LoRA ベースの生成はトレーニング完了後の推論あたりのリソース消費が大幅に少なくなります。 Video Retrieval-Augmented Generation (v-RAG) と呼ばれるもう一つのオプションは、動画固有の手法で、Retrieval-Augmented Generation (RAG) を使用してインデックス化されたコンテンツからモデルが自動的にリファレンスビジュアルを選択し、推論時に生成モデルに渡します。 実際の運用では、ファインチューニングとリファレンスコンディショニングのどちらを選ぶかは、技術的な優劣ではなく、クリエイティブワークフロー上の判断です。数百ショットに登場する主要キャラクターには LoRA を使い (トレーニングコストを償却)、登場頻度の低いサブ要素にはリファレンスコンディショニングを使うプロダクションもあるでしょう。監査可能性のメリットから v-RAG を主に活用するケースもあるかもしれません。AI-Powered Studio は両方をシームレスにサポートすべきです。ファインチューニングの ML オペレーションの複雑さを使いやすいインターフェースの背後に抽象化し (アーティストが MLOps チームなしでも LoRA を作成できるように)、同時にアセットカタログと統合された堅牢なリファレンス画像検索パイプラインも提供する。プラットフォームがこの判断をクリエイティブな選択にするのです。​ ショット一貫性のための構造化コンテキスト 構造化されたシーンコンテキストは、ビジュアル一貫性のアプローチが正しいロケーション、正しい衣装、正しい小道具、正しいライティングの下で成果物を生成することを保証します。アセット、環境、キャラクターのビジュアル一貫性にとどまらず、シーン内のショット一貫性 (アングル、ライティング、ビジュアルランゲージなど) を実現するには、コンテキストを最優先の設計課題として構造的なアプローチで扱う必要があります。本ガイダンスでは、構造化された分解によるアプローチを推奨します。スクリプトまたはストーリーから始め、それをシーンに、さらにショットに分解します。各シーンについて、関連するロケーション、キャラクター、小道具を特定します。これらの要素はそれぞれ、システム内の再利用可能なコンテキストオブジェクトとなり、リファレンス画像、テキスト記述、制約条件を備え、それらが関わるすべての生成リクエストに情報を提供します。 この階層の各レイヤーにはリファレンス素材が必要です。キャラクターには、外見、衣装、ヘアスタイル、歩き方、仕草、表情の幅といった側面をカバーする詳細なビジュアル・テキスト記述が必要な場合があります。小道具には、サイズ、重さ、素材、スタイルなどの記述が求められます (例：「緑色の金属製シャベル、ハンドル約 24 インチ」)。ロケーションには、ライティングリファレンス、カラーパレット、空間的な位置関係が必要です。このコンテキストが精密かつ構造化されているほど、それを共有するすべてのショットにわたって生成物の一貫性が高まります。ビジュアルリファレンスの作成は、スクリプトから詳細を抽出し画像を自動生成することで自動化できるケースもあります。一方で、アーティストやデザイナーがプラットフォーム内でこれらの詳細を定義し、画像生成を主導するインプットを行うケースもあります。どちらの方法を使うかはクリエイティブな判断であり、堅牢なプラットフォームは両方の方法をサポートすべきです。 コンテキストがプラットフォーム内で決定・記録されれば、ショット、シーン、エピソード、さらにはシーズンをまたいだ一貫性の確保がより容易になります。すべての生成リクエストが関連するコンテキストを自動的に継承します。「シーン 4 のショット 12」に対するリクエストは、そのシーンのロケーション記述、登場するキャラクター (ビジュアルおよび行動に関する完全な記述を含む)、関連する小道具を自動的に取得し、アーティストがそれらを再指定する必要はありません。 AI-Powered Studio のアーキテクチャは、3 つのレイヤーすべてをサポートします。学習されたビジュアルアイデンティティのためのモデルカスタマイゼーション、根拠のあるディテール精度を実現するためのリファレンス検索、そして物語と環境の一貫性のための構造化されたプロジェクト状態管理です。 ワークフローの副産物として取得される来歴 すべてのアセットがどのように作られたか (どのモデル、どの入力、誰の編集) を正確に把握しておくことは、納品時に重要です。この詳細な記録は、法務・コンプライアンス担当チームに対し、契約上のコンプライアンスと利用可能性を評価するために必要な情報を提供します。本アーキテクチャは、その記録を作業の副産物として自動的に生成するものであり、アーティストが締め切りのプレッシャーの中で忘れたり省いたりしがちな、独立した工程にはしません。これこそが、コンテンツの来歴とコンテンツの主権が存在する場所であり、すなわち、自社の制作が承認されたツールを用い、追跡可能なプロセスに従ったことを証明できる能力に他なりません。 本アーキテクチャは、生成時に自動的に取得される不変の来歴証跡を DynamoDB に保存します。すべてのアセット記録は、その完全な系譜を保持します。すなわち、どのモデルを、どのバージョンで、どのパラメータで、どの入力参照をもとに用い、どの人間による修正が適用されたか、です。このメタデータは生成時、つまり API 呼び出しの時点で付与され、個別のロギング工程を必要としません。来歴がクリエイティブ・ワークフローの副産物であり手作業によって後から再構築されるものではないため、専任の人員を割くことなく 1 シーズンにわたる数千点のアセットへとスケールし、クリエイターに追加の時間や労力を求めることもありません。 エージェントは、来歴が適切に取得・記録され、一貫してセキュアに保たれることを担保する優れた手段です。Amazon Bedrock AgentCore では、エージェントにその目的と振る舞いを定義する指示を与え、次に特定のツールやリソースへと接続します。これにより、単一のエージェントが、システム間に独自のコードを用意することなく、自社のランドスケープ全体を横断して推論できるようになります。同時に AgentCore では、エージェントが実行できる内容を制約するガードレールとポリシーを設定できます。その結果として得られるのは、スタック全体にわたって作業をオーケストレーションできるだけの能力を備えながらも、明示的に許可したアクションとデータのみに限定されたエージェントです。 図 3: 生成アセットの監査証跡 (モデル、パラメータ、入力リファレンス、人間による編集) を示す来歴 (プロベナンス) と系譜 (リネージ) のビュー ソースフッテージと生成アウトプットのための統合アセットカタログ AI 生成は、ソース素材を直接参照できるときに最も効果を発揮します。「このプレートの照明に合わせて新しいカメラアングルを生成する」といったリクエストでは、そのプレートがメタデータを備えた第一級のアセットであり、生成物と同じインターフェースで検索でき、同じ識別子でアドレス指定できる必要があります。統合カタログは複数の原則を同時に満たします。すなわち、参照素材をあらゆる生成リクエストからアクセス可能にすることで一貫性を実現し、アセットをそれが属するシーンやプロジェクトに紐付けることでコンテキストを提供し、さらにソースフッテージと派生物とのあいだの系譜を維持しつつ、どのアセットが利用承認済みかを制御することで、コンプライアンスを支えます。 本アーキテクチャは、ソースフッテージと生成メディアを単一のアセット管理サービスに格納します。オンセットのフッテージは専用の Amazon S3 インジェストバケットにアップロードされ、そこでハンドラが識別子とカメラメタデータを、生成物が格納されるのと同じ DynamoDB ベースのカタログに登録します。「シーン12、テイク 3」を検索するアーティストは、オリジナルのプレート、AI が生成した背景差し替え、合成結果、そしてバージョン管理されたすべてのイテレーションを一か所で見つけることができ、そのすべてにわたって共通の系譜が保たれています。 ゼロから構築することなく本番運用品質のアセット管理レイヤーを求めるスタジオ向けには、AWS パートナーが、このパターンへの API レベルでの統合を提供するアセット管理ソリューションを提供しています。 デジタルコンテンツ制作ツール (DCC ツール) との統合 従来のコンテンツ制作ワークフローは、Maya、Blender、Houdini、Cinema 4D、Nuke、DaVinci Resolve、Adobe Creative Suite をはじめとする、業界標準のデジタルコンテンツ制作 (DCC) ツールに依存しています。アーティストはこれらの環境において長年にわたる身体化された技能と専門性を培っており、ツールを捨てて新しいインターフェースへの乗り換えを強いるような AI プラットフォームは、導入を遅らせ、クリエイティブなアウトプットを制限する摩擦を生み出します。AI-Powered Studio はこれらの環境と統合し、エージェントを人間のメンバーと並ぶ協働的なクリエイティブチームの一員として扱うことで、それらの価値をさらに引き出します。 既存のコンテンツ制作ツールの多くは、現在では Model Context Protocol (MCP) をサポートするか、エージェント的な連携を可能にする堅牢な API を備えています。開発者が従来のコーディングと GUI ベースのツールを組み合わせられるのと同じように、スタジオプラットフォーム上の AI エージェントは、アーティストが使い慣れた環境のなかで彼らと並んで作業できます。エージェントは Blender や Houdini の中に直接プロジェクト構造、シーン、アセット階層を構築したり、完成した作業をプラットフォームのカタログへ取り込んだりでき、アーティストは GUI を通じて指示やフィードバックを与えます。ディレクターがシーンを自然言語で記述すると、プラットフォームがそれを複数のモデルにまたがる生成タスクへと分解し、出来上がったアセットを、アーティストが仕上げられる状態の DCC プロジェクトファイルへと送り込む——しかもアーティストがファイルを手動でダウンロード・リネーム・インポートする必要は一切ない、といったことも可能になります。同様に、アーティストが使い慣れたツールで自身の作業を完了してプラットフォームへエクスポートし直すと、統合レイヤーがそのハンドオフを来歴チェーンの一部として自動的に記録します。この系譜記録は、作業が AI 生成と従来のアーティストの手仕事とのあいだを流動的に行き来する場合でも、制作の各構成要素がどのように作られたかを反映します。 プラットフォームを構築するビジネスケース 専用の AI コンテンツ制作プラットフォームを構築することは一つの投資であり、しかも時間とともに複利的に価値を増していく投資です。個々の SaaS ツールは生成という課題をうまく解決しており、その多くは一貫性のためのインフラ、プロジェクトの文脈的な状態管理、きめ細かなクリエイティブ制御を、それぞれの境界の内側で提供しています。プラットフォームというアプローチは、その土台の上に立ち、これらの機能を単一のワークフローへと結びつけることで、コンプライアンス、来歴追跡、コストガバナンスを、後付けではなくネイティブな機能として実現します。その結果として得られるのは、クリエイティブな野心とともに成長していくシステムであり、タスクに最適なツールを統合する柔軟性を与えつつ、インフラを自ら所有することによってのみ得られる一貫性と制御を維持できるのです。 コスト： AI を活用したコンテンツ制作を模索している組織は、特定のワークフロー、とりわけプリビジュアライゼーション、コンセプトアート、環境生成、反復的なアセット開発において、測定可能なコスト削減を報告しています。しかしそうした削減は、コストが可視化され、制御可能である場合にのみ実現します。アーティストが計算コストへのフィードバックなしに反復を重ねる「暴走する再生成 (runaway regeneration)」は、AI が約束する削減効果を蝕みかねません。プラットフォームは、コストの透明性を提供しなければなりません。すなわち、生成にどれだけのコストがかかるかをプロジェクト単位・モデル単位・タスク単位で可視化し、スタジオが十分な情報に基づいてクリエイティブ上・予算上の意思決定を行えるようにする必要があります。専用プラットフォームへの先行投資はコストセンターではなく、コスト規律を保ちながら削減効果を獲得し、持続させるための仕組みなのです。 複利的に積み上がる効率性の向上： 純粋な生成コストにとどまらず、統合プラットフォームは、ばらばらのツールをつなぎ合わせることに伴う「統合税」を取り除きます。すなわち、インターフェース間のコンテキストスイッチ、モデルの出力と制作パイプラインとのあいだの手作業による受け渡し、重複したアセット管理、そしてベンダーが API を更新するたびに壊れる独自の統合を保守するために費やされるエンジニアリング時間、といったものです。これらの非効率性は、いずれも実際の労働コストを伴います。専用プラットフォームは、こうした問題を永続的に回避し続けるのではなく、構造的に取り除きます。 コンプライアンス： 自ら制御するプラットフォーム上でコンテンツが生成され、来歴が自動的に副産物として取得されることで、法務・コンプライアンス担当チームに対して、すべてのアセットがどのように作られたかについての完全な可視性を提供できます。プラットフォームは人間の意思決定を記録し、系譜を辿り、すべてのソースを文書化します。この透明性により、チームは第三者の SaaS 利用規約に依存することなくコンプライアンスを評価できるようになります。 コントロール： AI が生成したコンテンツが制作パイプラインに入ってくるにつれ、スタジオは、どのモデルを使うか、それらをどのようにパラメータ設定するか、そしてどのようなコンテンツを生成するかについて、中央集権的な制御を必要とします。専用プラットフォームは、それぞれ独自のアクセスモデルと利用規約を持つ、ばらばらの SaaS サブスクリプションの寄せ集めにガバナンスを後付けしようとするのではなく、そうした制御の面 (監査証跡、モデルの承認、利用ポリシー、ガードレール) をネイティブに提供します。 モデルの移り変わりに対する将来への備え： 生成 AI の市場は急速に変化しており、今日の有力なベンダーが、一年のうちに買収されたり、提供終了になったり、他に追い抜かれたりする可能性があります。自ら所有するプラットフォームであれば、自社のワークフロー、学習データ、来歴記録、アセットカタログは、どの単一モデルの盛衰にも左右されずに存続します。その時々で最良のワークフローを採用しつつ、それに縛られることがなくなるのです。 ISV のツールには価値がある、置き換えるのではなく統合する： ここまで述べてきたプラットフォーム構築の議論は、Runway、Luma、fal.ai、ComfyUI といった専門的な生成 AI サービスの価値を少しも損なうものではありません。これらのツールは、自らの領域において際立って優れています。画像・動画・3D 生成の最先端を押し広げており、個々のスタジオには到底再現できない規模でモデル研究に多額の投資を行っています。AI-Powered Studio は、複数のプラットフォームを互いに結びつけ、それらすべてに対して同時にガバナンスを提供するレイヤーです。これらの ISV の多くは堅牢な API と連携ポイントを提供しており、それらを自社のプラットフォームに組み込むことで、プラットフォームの能力はさらに広がります。すなわち、彼らの最高水準の生成能力を、来歴管理、ガバナンス、アセットカタログで包み込み、その成果を一か所に集約して手にすることができるのです。プラットフォームはこれらのツールと競合するものではありません。むしろ、それらを本番制作で使えるようになる理由そのものなのです。 この能力を今のうちに築いておくスタジオは、より多くのコンテンツを、より高い品質で、従来の何分の一かのコストで制作できる立場に立てます。しかも、作品を実際に世に送り出すために欠かせない一貫性・文脈理解・コントロール・コンプライアンス・コスト管理をきちんと備えた形で実現できるのです。 はじめるには ここまで説明してきたアーキテクチャは、一般提供されている AWS サービスを使用しており、そのパターンは、AI を制作プロセスに組み込んでコンテンツを生み出すあらゆるスタジオに適用できます。唯一の決まった実装方法があるわけではありません。最適な道のりは、チームの技術的な習熟度、制作規模、そしてスケジュールによって異なります。 ＜カスタム構築プラットフォーム＞ AWS およびパートナーは、メディア & エンターテインメントと ML エンジニアリングの豊富な経験を持ち、ランディングゾーンのセットアップから本番デプロイメントまで、ワークフローに合わせたカスタムプラットフォームの設計と構築をサポートできます。 AWS Professional Services AWS Systems Integrator Partners ＜マネージドプラットフォーム＞ AWS パートナーは、これと同じ AWS サービス上に構築されたフルマネージドのソリューションも提供しています。協働型のワークスペースとモデルに依存しない生成機能をすぐに使える製品として手に入れられるため、クリエイティブな作業そのものに集中できます。 これらのパートナーとの連携に関する推奨や支援、あるいはプラットフォーム構築に向けた追加のガイダンスについては、担当の AWS アカウントチームにお問い合わせください。 多くのスタジオは、上記の両方のアプローチを組み合わせています。すなわち、進行中の制作をすばやく前進させるためにマネージドプラットフォームを採用しつつ、時間をかけて独自の構成要素 (カスタムモデルや特注のワークフロー) に投資していく、という進め方です。 まとめ 生成 AI を取り巻く状況はめまぐるしく動いています。モデルは絶えず進化し、新しいプロバイダーが次々と現れ、クリエイティブチームはエンジニアリングの開発サイクルを待つことなく、すばやく導入したいと望んでいます。本ガイダンスで示すアーキテクチャパターンは、生成 AI をビジネス上の有効な選択肢たらしめる諸原則をしっかりと堅持しながら、そのスピードを御しやすいものにします。すなわち——あらゆるフレームにわたってブランドアイデンティティを保つ Consistency (一貫性) 、すべての生成を構造化されたクリエイティブな意図に根づかせる Context (コンテキスト) 、アウトプットに対するきめ細かな権限をアーティストに与える Control (コントロール） 、来歴を追跡し、承認されたツールの使用を保証する Compliance (コンプライアンス) 、そして AI を暴走する支出ではなく経済的に成り立つものに保つ Cost (コスト) 規律 です。モデルの差し替えをリリースではなく設定変更で行い、クラスターを運用することなく自社の IP で学習させ、余計なプロセスを足すことなく生成された全フレームを追跡可能に保ち、アーティストがソースフッテージと AI の生成物を同じ場所で見つけられるようにする——そのすべてが、これら 5 つの目標のために機能します。 AI-Powered Studio は一つの概念的なアーキテクチャであり、単一の製品ではありません。ここで述べたパターンは、AWS 上で AI を使った制作に乗り出す準備ができたあらゆるチームが利用でき、AWS パートナーがそこへ到達するお手伝いをします。これらの構成要素をどのように組み上げるかは、スタジオごとに固有のものになります——どのモデルへルーティングするか、アセットカタログをどのように構成するか、納品要件がどの程度の来歴の粒度を求めるか、といった点です。原則は共有されるものです。しかし、その実装はあなた自身のものなのです。 参考リンク Amazon Bedrock Amazon SageMaker AI AWS Deadline Cloud Amazon EventBridge AWS AppConfig Amazon API Gateway WebSocket APIs Amazon DynamoDB Policy in Amazon Bedrock AgentCore 寄稿者 Brandon Lindauer, Senior Specialist Solutions Architect, Media & Entertainment Sean Wallitsch, Senior Specialist Solutions Architect, Visual Computing Scott Cler, Senior Industry Specialist, Media & Entertainment Stephen Oliver, Senior Industry Specialist, Media & Entertainment Lee Millstein, Principle GTM Specialist, Media & Entertainment Zach Willner, Senior Partner Solutions Architect, Media & Entertainment Jason O’Malley, Senior Partner Solutions Architect, Media & Entertainment Dan Hawks, Principle Partner Development Specialist, Media & Entertainment ​ AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本記事は、 Guidance for an AI-Powered Studio on AWS を翻訳したものです。翻訳は Solutions Architect の王、金目が担当しました。 ​

本ブログは 2026 年 8 月 26 日に公開された AWS Blog “ Detecting multi-stage attacks on AWS: A guide to cross-service signal correlation ” を翻訳したものです。 1 つのセキュリティサービスから届くアラート単体でわかるのは、何かが起きたという事実だけです。そのシグナルを他のサービスのアクティビティやお客様のビジネスコンテキストと合わせて読み解くことで、それが多段階攻撃の一部かどうかを判断できます。 次のような短い一連の流れを考えてみましょう。あるアイデンティティが、これまで使用したことのない送信元アドレスから GetCallerIdentity を呼び出します。数分以内に、同じアイデンティティが複数のサービスにわたって List 呼び出しと Describe 呼び出しを集中的に実行し、その一部が AccessDenied で失敗します。その直後、先週登録されたばかりのドメインに向けて、大量のデータが環境外へ送出されます。 Amazon GuardDuty は、なじみのない送信元からの偵察など、この流れの一部を Recon:IAMUser/* や Discovery:S3/* などの検出結果タイプで既に検出している可能性があります。各要素を相関付けることで、お客様のビジネスコンテキストと結び付いた一連の流れの全体像を把握できます。これにより、検出結果を 1 件ずつトリアージするのではなく、全体として対処できるようになります。 この記事は、 Amazon Web Services (AWS) の検出サービスを運用しており、自身の環境に固有のパターンをとらえたいセキュリティエンジニアとセキュリティオペレーションチームを対象としています。AWS の検出機能とビジネスコンテキストがどのように組み合わさるのか、そしてそのコンテキストを活用した相関分析をどのように構築するのかを説明します。例はいずれも Amazon CloudWatch Logs Insights で実行できるので、すぐに試せます。最後のセクションでは、これらを自動化されたパイプラインへ発展させる方法も説明します。これらのクエリの前提条件は、この記事の後半のウォークスルーに記載しています。 AWS の検出サービスから始める まずは AWS の検出サービスを活用しましょう。これらのサービスは多くのお客様に共通する脅威をカバーしており、この記事の内容もすべてこれらを基盤としています。 Amazon GuardDuty は、 AWS CloudTrail 、 Amazon Virtual Private Cloud (Amazon VPC) フローログ、DNS クエリログ、 Amazon Simple Storage Service (Amazon S3) データイベントなどのアクティビティを分析し、追加設定なしで信頼度の高い検出結果を生成します。 Amazon Detective (リソースと検出結果の関係を可視化するセキュリティ調査サービス) を使用すると、サービスやアカウントをまたいだグラフベースのコンテキストで検出結果を調査できます。 AWS Security Hub は、セキュリティの検出結果を集約し、優先順位付けされた単一のダッシュボードに表示します。 Amazon Security Lake は、セキュリティデータを専用のデータレイクに一元化し、長期的な分析に向けて Open Cybersecurity Schema Framework (OCSF) 形式で保存します。 Amazon Inspector (ワークロードのソフトウェアの脆弱性をスキャンする脆弱性管理サービス) は、脆弱性データをワークロードのコンテキストと相関付けます。 独自の仕組みを構築する前に、これらのサービスを有効にしてチューニングしてください。ここでいうチューニングとは、環境に合わせて感度を調整して誤検知を減らすこと、各サービスが監視するデータソースを選択すること、既知の正常なパターンに対する検出結果を抑制することを指します。 GuardDuty が多段階攻撃を自動的に相関付ける 手作業で何かを構築する前に、GuardDuty が既に何をしてくれるのかを確認しましょう。 Amazon GuardDuty 拡張脅威検出 は、 AWS CloudTrail 、Amazon S3 データイベント、Runtime Monitoring、 Amazon Elastic Kubernetes Service (Amazon EKS) の監査ログなど、複数のデータソースにわたるシグナルを相関付けます。そして多段階のパターンを検出すると、重大度が「重大」の攻撃シーケンス検出結果を 1 つ発行します。認証情報の侵害に続くデータ持ち出し (エクスフィルトレーション) などのシーケンスを認識し、それらを MITRE ATT&CK の戦術にマッピングしたうえで、タイムラインと修復ガイダンスを添付します。現在 GuardDuty を有効にしている場合、GuardDuty 拡張脅威検出はデフォルトで既に有効になっており、クエリを作成する必要はありません。GuardDuty の料金の適用方法の詳細については、「 Amazon GuardDuty の料金 」を参照してください。 冒頭の例で示した認証情報の侵害シーケンスは、まさに GuardDuty 拡張脅威検出が検出対象とする普遍的なパターンです。このようなパターンの検出は GuardDuty 拡張脅威検出に任せてください。攻撃シーケンス検出結果は GuardDuty コンソールで他の検出結果と並んで表示され、他の検出結果と同じように Security Hub や対応ワークフローにルーティングされます。 GuardDuty が対処するのは、どのアカウントでも同じように見える脅威です。一方で GuardDuty には、ある操作がお客様のアカウントでは不審だと判断するためのコンテキストがありません。そのコンテキストを提供するのがお客様の役割です。 ビジネスコンテキストを追加する ビジネスコンテキストとは、お客様の環境についてお客様だけが知っている情報です。例えば、どのバケットに機密データが保存されているか、どのプリンシパルがどのリソースにアクセスする正当な理由を持っているか、ポリシーでどのロールチェーンが許可されているか、本番環境の変更ウィンドウがいつかといった情報です。GuardDuty 拡張脅威検出は多くのお客様に共通するパターンから学習しますが、こうした環境固有の問いには答えられません。これらを相関分析として表現することで、お客様の環境に合わせてチューニングされた検出レイヤーを追加できます。以下の 4 つのパターンでは、こうした事実をそれぞれ 1 つずつクエリに落とし込みます。 これらのクエリは、AWS マネジメントコンソールで CloudWatch を開き、 [ログ] 、 [ログのインサイト] の順に選択して、 CloudWatch Logs Insights のクエリ言語 で実行します。ほとんどのクエリは、 証跡の配信先 である CloudWatch Logs ロググループから CloudTrail イベントを読み取ります。証跡の出力先が Amazon S3 のみの場合は、証跡に CloudWatch Logs への配信を追加するか、 Amazon Athena (SQL を使用して Amazon S3 のデータを分析するサーバーレスのクエリサービス) で同等のクエリを実行してください。 注 : この記事のクエリとコードでは、プレースホルダー値を使用しています。実行前に、 your-sensitive-bucket (S3 バケット名)、 your-key-id (AWS KMS キー ID)、 region (us-east-1 などの AWS リージョン)、 account-id (12 桁の AWS アカウント ID)、 aws-cloudtrail-logs-my-trail (CloudTrail ロググループ名) を実際の値に置き換えてください。 マルチアカウント環境についても補足しておきます。 AWS Organizations では、 組織の証跡 がすべてのアカウントのイベントを 1 つのロググループに配信します。そのため、これらのクエリはそのまま機能しますが、複数アカウントにまたがる結果が返されます。アカウント単位で確認するには、 recipientAccountId でフィルタリングしてください。組織の証跡を使用していない場合は、アカウントごとにクエリを実行するか、 Amazon Security Lake を一元的なクエリの基盤として使用してください。 AWS サービスにマッピングした攻撃チェーン 多段階攻撃は 5 つのフェーズを経て進行し、フェーズごとに異なるサービスにシグナルが残ります。これらのシグナルは、次の 3 つのログソースに現れます。アカウント内の API アクティビティを記録する CloudTrail、ネットワーク接続のメタデータをキャプチャする Amazon VPC フローログ、そして VPC からの DNS クエリを記録する Amazon Route 53 Resolver クエリログです。 初期アクセス – 盗まれた認証情報が環境内で使用されます。CloudTrail には、なじみのない送信元からの GetCallerIdentity 、 GetSessionToken 、または AssumeRole が記録されます。 探索 – 脅威アクターは List 、 Describe 、 Get の呼び出しでリソースを列挙します。その際、多くの場合 AccessDenied レスポンスが発生します。 権限昇格 – 脅威アクターはロールを連鎖させたり、ポリシーを編集したりします。CloudTrail には、 AssumeRole のシーケンス、 PutRolePolicy 、または CreateAccessKey が記録されます。 ラテラルムーブメント (横展開) – 脅威アクターはアカウントや AWS リージョンをまたいで移動し、普段使われていない場所でロールを引き受けたり、リソースを作成したりします。 データ持ち出し – 大規模な GetObject 呼び出し、VPC フローログに記録される大量のアウトバウンド転送、Route 53 Resolver クエリログに記録される最近登録されたドメインへの DNS クエリを通じて、データが持ち出されます。 図 1 は、5 つの攻撃フェーズと、各フェーズを記録する AWS のログソースとの対応を示しています。 図 1: AWS サービスにマッピングした攻撃チェーン GuardDuty 拡張脅威検出は、このチェーン全体を対象に普遍的なパターンを監視します。以下の 4 つのパターンでは、そこにお客様ならではの観点、つまりビジネスコンテキストを追加します。 パターン 1: 想定外のプリンシパルによる機密データへのアクセス この検出を支えるのは、データ分類と通常のアクセスパターンです。例えば、あるバケットには顧客記録が、別のバケットには公開ウェブアセットが保存されているとします。お客様は、機密性の高い顧客記録を読み取る正当な理由があるプリンシパルがどれかを把握しています。その知識をルールとして組み込むと、一見ありふれた読み取りが、追跡すべき事象に変わります。 ここでは 3 つのシグナルが重なり合います。CloudTrail には、機密として分類したバケットに対する大量の GetObject が記録されます。そのプリンシパルは、このバケットの読み取りが想定されるプリンシパルのリストに含まれていません。さらに、VPC フローログには同じ時間枠内に同じ送信元からの大量のアウトバウンド転送が記録され、DNS クエリログには最近登録された宛先ドメインが記録されます。これらが組み合わさることで、潜在的な脅威が存在するという確信度が高まります。 CloudTrail の管理イベントには GetObject は記録されません。 GetObject をキャプチャするには、対象のバケットで CloudTrail データイベントを有効にする 必要があります。該当するバケットでデータイベントが有効になっていなかったために、 GetObject を見逃しているチームは少なくありません。 次のクエリは、機密バケットに対する大量の読み取りをプリンシパル別にグループ化して表示します。CloudTrail ロググループを選択した状態で、CloudWatch Logs Insights で実行してください。 fields @timestamp, userIdentity.arn, requestParameters.bucketName | filter eventSource = "s3.amazonaws.com" and eventName = "GetObject" | filter requestParameters.bucketName = "your-sensitive-bucket" | stats count(*) as objectReads, count_distinct(requestParameters.key) as distinctObjects by userIdentity.arn, bin(10m) | filter objectReads > 100 | sort objectReads desc しきい値の 100 はプレースホルダーです。通常時の 1 週間分のアクティビティに対してクエリを実行し、そのバケットの読み取り回数の 95 パーセンタイルを求めて、それを上回る値をしきい値に設定してください。次に、クエリが返した各プリンシパルを、読み取りが想定されるプリンシパルのリストと照合します。リストに含まれていないプリンシパルが大量に読み取っている場合、それが調査すべき結果です。 裏付けを取るには、対応するアウトバウンド転送を探します。ロググループの選択を VPC フローログのロググループに切り替えて、次のクエリを実行してください。 fields @timestamp, srcAddr, dstAddr, bytes | filter action = "ACCEPT" # exclude RFC 1918 private ranges so only external destinations remain | filter dstAddr not like /^10\./ and dstAddr not like /^192\.168\./ and dstAddr not like /^172\.(1[6-9]|2[0-9]|3[0-1])\./ | stats sum(bytes) as totalBytes by srcAddr, dstAddr, bin(10m) | filter totalBytes > 1000000000 | sort totalBytes desc Amazon S3 のクエリはプリンシパルを返しますが、フローログのクエリは IP アドレスを対象とするため、プリンシパルを IP アドレスに変換する必要があります。この変換の詳細は、この記事の後半の実践例で説明します。 レポート用バケットを 1 日中読み取っている分析ロールを想像してみてください。ある日の午後、このロールがレポート用バケットではなく顧客記録バケットから 1,000 個のオブジェクトを読み取ったとします。GuardDuty は反応しません。認証済みのロールが有効な GetObject 呼び出しを行うこと自体は、他の環境では不審とみなされないからです。一方、お客様のクエリはこれを検出します。そのロールが、このバケットの読み取りが想定されるプリンシパルのリストに含まれていないからです。お客様が適用した分類こそが、何も起きていないように見える状況をシグナルに変えるのです。 図 2 は、CloudTrail に記録された機密バケットからの大量の読み取り、VPC フローログに記録された大量のアウトバウンド転送、Route 53 Resolver ログに記録された登録されて間もないドメインの名前解決を示しています。 図 2: 単一の時間枠内で重なり合い、データ持ち出しを示す 3 つのシグナル パターン 2: アクセスポリシーを逸脱するロールチェーン ビルドのために 1 つ目のロールを引き受け、続いてリリースのために 2 つ目のロールを引き受けるデプロイを想像してみてください。あるプリンシパルにとって、この 2 ホップの AssumeRole チェーンは日常的なものですが、別のプリンシパルにとってはポリシー違反になります。このパターンの前提となるのは、組織が許可するチェーン、つまり信頼トポロジーです。その知識をクエリに組み込みましょう。 このパターンでは、次の 3 つの条件を満たすものを検出します。 CloudTrail に、短い時間枠内で同じ送信元からの複数の AssumeRole 呼び出しが記録されている チェーンが CreateAccessKey 、 PutRolePolicy 、 AttachUserPolicy などのセキュリティ上重要なアクションで終わる 起点となるアイデンティティが、ポリシー上、そのチェーンを実行する主体として想定されていない CloudWatch Logs Insights で CloudTrail ロググループを選択し、2 ホップ以上のチェーンを抽出する次のクエリを実行してください。 fields @timestamp, userIdentity.arn, requestParameters.roleArn, sourceIPAddress | filter eventName = "AssumeRole" | stats count(*) as assumeCount, count_distinct(requestParameters.roleArn) as rolesAssumed by sourceIPAddress, bin(5m) | filter assumeCount >= 2 and rolesAssumed >= 2 | sort assumeCount desc チェーンは最小で 2 ホップです。環境内でロールを頻繁に連鎖させている場合は、カウントを引き上げてください。デプロイパイプラインは 1 時間に複数のロールを引き受けることが多く、AWS Security Hub などの AWS サービスプリンシパルも同様です。パイプラインロールや既知の AWS サービスプリンシパルなど、複数のロールを引き受けることが想定されるアイデンティティは除外してください。残ったものが調査対象です。例えば、人が通常とは異なる時間帯に複数のロールを引き受け、最終的に新しいアクセスキーを作成しているケースなどです。この区別はデータとして管理してください。つまり、正常とみなすアイデンティティとアクションをリスト化し、そのリストから外れるチェーンを確認します。 パターン 3: キーを所有するワークロード以外で使用される暗号化キー ここでのシグナルは、リソースの所有関係です。特定の AWS Key Management Service (AWS KMS) キーはワークロードの暗号化キーを作成および管理するもので、1 つのキーは決済サービスなど 1 つのワークロード専用であるべきです。キーに対する Decrypt 呼び出しは有効かつ認可された API アクションなので、呼び出し自体に不審な点はありません。別のプリンシパルによるこのキーの使用を、改めて確認すべき事象に変えるのは、お客様が定めた所有ルールです。 このパターンは、1 つのワークロードに限定されたカスタマーマネージドキーにのみ適用されます。AWS マネージドキー ( alias/aws/* ) や、意図的に複数のサービス間で共有しているカスタマーマネージドキーには適用されません。このルールをデプロイする前に、キーポリシーの Principal ブロックで、キーが単一のワークロード向けであることを確認してください。 次の 2 つの条件がそろう場合は、不正使用の可能性があります。 CloudTrail に、1 つのワークロードに関連付けられたキーに対する Decrypt または GenerateDataKey の呼び出しが記録されている 呼び出し元のプリンシパルが、そのワークロードを所有するロールではない CloudTrail ロググループに対して次のクエリを実行し、特定のキーに対して API を呼び出したプリンシパルを一覧表示します。 fields @timestamp, userIdentity.arn, eventName | filter eventSource = "kms.amazonaws.com" | filter eventName in ["Decrypt", "GenerateDataKey", "Encrypt"] | filter resources.0.ARN = "arn:aws:kms:region:account-id:key/your-key-id" | stats count(*) as keyUses by userIdentity.arn, eventName | sort keyUses desc 返された結果を、想定している 1 つのワークロードロールと比較してください。そのキーを使用する想定外のプリンシパルが見つかれば、それがシグナルです。キーの不正使用はデータ窃取の初期段階に見られる行動であり、この相関分析では、所有関係を把握しているお客様にしか検出できないアクティビティをとらえられます。 決済データベースを暗号化しているキーを例に考えてみましょう。通常の運用では決済サービスのロールがこのキーに対して API を呼び出し、それ以外のロールが呼び出すことはないはずです。開発者ロールや新しく作成されたロールがこのキーに対して Decrypt を実行した場合、呼び出しは成功し、単独で見れば通常の操作にしか見えません。これを問題として扱う根拠は、お客様が頭の中で把握している所有ルールであり、このクエリはそれを明文化したものです。 パターン 4: 変更ウィンドウ外での特権アクション まずクエリを確認し、そのうえで意味を読み解いていきましょう。 fields @timestamp, userIdentity.arn, eventName, sourceIPAddress | filter eventName in ["PutRolePolicy", "AttachRolePolicy", "CreateAccessKey", "AuthorizeSecurityGroupIngress", "PutBucketPolicy"] | stats count(*) as sensitiveChanges by userIdentity.arn, eventName, sourceIPAddress | sort sensitiveChanges desc このクエリは CloudTrail ロググループに対して実行します。スケジュール実行する際は対象期間を業務時間外に絞り込み、変更ウィンドウ外のアクティビティだけが返されるようにします。ここで何を正常とみなすかは、お客様の変更プロセスによって決まります。本番環境のセキュリティやアイデンティティに関する変更は、定められた時間帯にパイプラインを通じて、既知のアクターによって実行されます。午前 2 時にコンソールから行われたポリシー変更が、パイプラインではなく人によるものであれば、こうした想定には当てはまりません。シグナルとなるのは、 PutRolePolicy や AuthorizeSecurityGroupIngress などのセキュリティ上重要な変更が、ウィンドウ外に、パイプラインロールではなく人によって行われた場合です。 想定されるアクターは除外してください。例えば、デプロイパイプラインロール、パッチ自動化ロール、 AWS CloudFormation や AWS Systems Manager などの AWS サービスプリンシパルです。残るのは、プロセス外で行われた特権的な変更です。これは攻撃者がアクセスを永続化するために行う行動であると同時に、お客様自身の変更管理の規律に照らして起こるべきではない事象でもあります。 パイプラインは、平日の午後に毎日実行されるデプロイの中でセキュリティグループルールを開放することがあります。一方、週末の深夜に人がセキュリティグループルールを開放する場合は、同じ API コールでも意味がまったく異なります。両者を区別するのは、スケジュールとアクターという、どちらもお客様が定義する事実です。 最初の相関ルールを構築する 以下のウォークスルーでは、パターン 1 を例に、最初から最後までの実装手順を示します。他の 3 つのパターンも、それぞれのクエリを用いて同じ設計に従います。 前提条件 このウォークスルーのクエリに必要なデータを取得するには、以下の前提条件を満たす必要があります。開始する前に、それぞれを確認してください。 管理イベントを CloudWatch Logs ロググループに記録する CloudTrail 証跡があること 機密性の高い S3 バケットで CloudTrail データイベントが有効になっていること GuardDuty が有効で、保護プランと拡張脅威検出も有効になっていること VPC フローログ が本番 VPC で有効になっていること Amazon Route 53 Resolver クエリログ記録 が有効になっていること CloudTrail、GuardDuty、VPC フローログ、Route 53 Resolver クエリログ記録は、相関分析で結び付ける生のシグナルを提供します。これらが有効になっていない場合、この記事のクエリは空の結果を返します。 ステップ 1: バケットと、その読み取りが想定されるプリンシパルを記録する 監視対象とする機密バケットを 1 つ選び、そのバケットの読み取りを許可されたプリンシパルを書き留めます。このリストは、バージョン管理された設定ファイルや Amazon DynamoDB テーブル (マネージド NoSQL データベース) など、自動化の仕組みからアクセスできる場所に保存してください。 { "customer-records-prod": [ "arn:aws:iam::123456789012:role/AnalyticsPipeline", "arn:aws:iam::123456789012:role/ComplianceAudit" ], "financial-data-archive": [ "arn:aws:iam::123456789012:role/FinanceReporting" ] } この例では、わかりやすさを優先してリストをハードコードしています。本番環境では、再デプロイせずに更新できるように、DynamoDB テーブルや Parameter Store からリストを読み込んでください。 ステップ 2: しきい値を設定する前にベースラインを把握する 通常時の 1 週間分のアクティビティに対してパターン 1 のクエリを実行します。そのバケットの読み取り回数の 95 パーセンタイルを求め、それより大きい値をアラートのしきい値として使用します。このステップを踏むことで、正当な大量アクセスが後で誤検知を引き起こすのを防げます。 ステップ 5 で関数を設定する際に、この値を THRESHOLD_READS 環境変数に設定します。 ステップ 3: アクセスクエリを実行する CloudWatch コンソールで、次の操作を行います。 [ログ] 、 [ログのインサイト] の順に選択します。 [ロググループの選択] ドロップダウンで、CloudTrail ロググループを選択します。 時間範囲を [3h] (過去 3 時間) に設定します。 クエリエディタにパターン 1 のクエリを貼り付けます。 your-sensitive-bucket をバケット名に置き換えます。 [クエリの実行] を選択します。 結果テーブルに表示されたプリンシパルを確認します。 各プリンシパルを、ステップ 1 で記録した読み取りが想定されるプリンシパルのリストと照合し、リストに含まれていないものにフラグを付けます。 各結果にはプリンシパルが含まれています。ステップ 4 では、このプリンシパルを IP アドレスに変換します。 ステップ 4: ネットワークアクティビティと相関付ける CloudTrail は AWS Identity and Access Management (IAM) プリンシパル単位でアクションを記録し、VPC フローログは IP アドレス単位でトラフィックを記録します。2 つのシグナルを結び付けるには、プリンシパルを対応する IP アドレスに変換します。 ロールが Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにアタッチされている場合、 userIdentity.principalId フィールドのコロンの後ろにインスタンス ID が含まれます。形式は AROAEXAMPLE:i-1234567890abcdef0 です。このインスタンス ID をコピーし、プライベート IP アドレスを調べます。 aws ec2 describe-instances \ --instance-ids i-1234567890abcdef0 \ --query "Reservations[0].Instances[0].PrivateIpAddress" \ --output text 他のコンピューティングタイプでは方法が異なります。VPC に接続された AWS Lambda 関数は、サブネット内の Elastic Network Interface を経由してトラフィックを送信するため、それらのインターフェイスのアドレスで相関付けます。 Amazon Elastic Container Service (Amazon ECS) タスクの場合、ネットワークインターフェイスはタスクメタデータに記録されます。インスタンスを伴わない通常のロール引き受けセッションの場合は、CloudTrail の sourceIPAddress フィールドに呼び出し元のアドレスが既に記録されているため、それを使って直接相関付けます。 パターン 1 のフローログのクエリを実行し、 srcAddr をそのアドレスでフィルタリングして、Amazon S3 の読み取りタイムスタンプから 10 分以内の範囲に絞り込みます。一致する結果があれば、同じ時間枠内に、同じ送信元が機密データの読み取りと大量の外部転送の両方を行っていることになります。CloudTrail イベントが CloudWatch Logs に到達するのは API コールの 5～15 分後なので、クエリ時刻ではなく eventTime で相関付けてください。また、クエリのルックバック期間は相関付けの時間枠よりも広く取ります。例えば、30～60 分前までさかのぼってクエリを実行しつつ、相関付けは 10 分間の eventTime の時間枠で行います。ステップ 3 と 4 は手動による検証で、ステップ 5 でこれらを自動化します。 図 2 では、DNS の名前解決が 3 つ目の裏付けシグナルとして示されています。このウォークスルーで実装するのは、CloudTrail と VPC フローログの相関分析です。DNS を追加するには、同じ run_query() のパターンを Route 53 Resolver クエリログのロググループに適用してください。 ステップ 5: チェックを自動化する クエリを Lambda 関数 (サーバーを管理せずにコードを実行できるサーバーレスコンピューティング) に移行し、結果を通知チャネルに送信して、定期的に実行されるようにスケジュールを設定します。以下のサブ手順を順に実行してください。 通知チャネルを作成するには Amazon Simple Notification Service (Amazon SNS) コンソールを開きます。Amazon SNS は、サブスクライバーに通知を配信するマネージドメッセージングサービスです。 ナビゲーションペインで、 [トピック] を選択します。 [トピックの作成] を選択します。 [タイプ] で [スタンダード] を選択します。 [名前] に security-correlation-alerts と入力します。 [トピックの作成] を選択します。 トピックの詳細ページの上部に表示されるトピックの Amazon リソースネーム (ARN) を書き留めておきます。この ARN は関数で使用します。 [サブスクリプションの作成] を選択します。 [プロトコル] で [E メール] を選択します。 [エンドポイント] に、 E メール アドレスまたはインシデント管理のエンドポイントを入力します。 [サブスクリプションの作成] を選択し、AWS から届く E メール でサブスクリプションを確認します。 EventBridge Scheduler の実行ロールを作成するには スケジュールには関数を呼び出すためのロールが必要です。また、そのロールの信頼ポリシーには、ロールの利用をお客様が所有するスケジュールに限定する条件が必要です。これらの条件がないと、スケジューラサービスにアクセスできる別のアカウントが、理論上このロールを呼び出せてしまいます。これは「 混乱した代理問題 」として知られる不正使用の一種です。 1. scheduler-trust-policy.json という名前の信頼ポリシーファイルを作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "scheduler.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "ACCOUNT-ID" }, "ArnLike": { "aws:SourceArn": "arn:aws:scheduler:REGION:ACCOUNT-ID:schedule/*/s3-access-correlation-hourly" } } } ] } 2. ロールを作成し、関数を呼び出すためのアクセス許可をアタッチします。このロールで指定した関数以外を呼び出せないように、 Resource は特定の関数 ARN に限定してください。 aws iam create-role \ --role-name EventBridgeSchedulerRole \ --assume-role-policy-document file://scheduler-trust-policy.json aws iam put-role-policy \ --role-name EventBridgeSchedulerRole \ --policy-name LambdaInvokePolicy \ --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:REGION:ACCOUNT-ID:function:CorrelationFunction" } ] }' 関数を作成すると、Lambda によって実行ロールが自動的に作成されます。この関数に必要なアクセス許可は、後の手順でそのロールにアタッチします。 相関関数をデプロイするには Lambda コンソール を開きます。 [関数の作成] を選択します。 [関数名] に CorrelationFunction と入力します。 [ランタイム] で、最新の Python ランタイムを選択します。 [関数の作成] を選択します。 [コード] タブで、デフォルトのコードを次の関数に置き換え、 [デプロイ] を選択します。 import os import time import logging import boto3 from botocore.exceptions import ClientError logger = logging.getLogger() logger.setLevel(logging.INFO) logs = boto3.client("logs") sns = boto3.client("sns") ec2 = boto3.client("ec2") CLOUDTRAIL_LOG_GROUP = os.environ["CLOUDTRAIL_LOG_GROUP"] FLOWLOGS_LOG_GROUP = os.environ["FLOWLOGS_LOG_GROUP"] SNS_TOPIC = os.environ["SNS_TOPIC_ARN"] BUCKET = os.environ["SENSITIVE_BUCKET"] THRESHOLD = int(os.environ.get("THRESHOLD_READS", "100")) # Expected readers per bucket EXPECTED_READERS = { "customer-records-prod": [ "arn:aws:iam::123456789012:role/AnalyticsPipeline", "arn:aws:iam::123456789012:role/ComplianceAudit", ], } def run_query(log_group, query, start, end): """Start a Logs Insights query and wait for it to finish.""" started = logs.start_query( logGroupName=log_group, startTime=start, endTime=end, queryString=query, ) query_id = started["queryId"] while True: outcome = logs.get_query_results(queryId=query_id) if outcome["status"] in ("Complete", "Failed", "Cancelled"): break time.sleep(1) if outcome["status"] != "Complete": raise RuntimeError(f"Query did not complete: {outcome['status']}") return [{f["field"]: f["value"] for f in row} for row in outcome["results"]] def private_ip_for_principal(principal_id): """Resolve an EC2 instance role principalId to its private IP.""" if ":" not in principal_id: return None instance_id = principal_id.split(":", 1)[1] if not instance_id.startswith("i-"): return None reservations = ec2.describe_instances(InstanceIds=[instance_id]) for reservation in reservations["Reservations"]: for instance in reservation["Instances"]: return instance.get("PrivateIpAddress") return None def egress_bytes(src_addr, start, end): """Sum external egress bytes for one source address.""" query = f""" fields srcAddr, dstAddr, bytes | filter action = "ACCEPT" and srcAddr = "{src_addr}" | filter dstAddr not like /^10\\./ and dstAddr not like /^192\\.168\\./ and dstAddr not like /^172\\.(1[6-9]|2[0-9]|3[0-1])\\./ | stats sum(bytes) as totalBytes """ rows = run_query(FLOWLOGS_LOG_GROUP, query, start, end) if rows and rows[0].get("totalBytes"): return int(rows[0]["totalBytes"]) return 0 def lambda_handler(event, context): try: # 1-hour lookback absorbs CloudTrail's 5-15 min delivery latency; # correlation happens on eventTime via 10-min bins in the query below. end = int(time.time()) start = end - 3600 # 1 hour lookback allowed = EXPECTED_READERS.get(BUCKET, []) access_query = f""" fields userIdentity.arn, userIdentity.principalId | filter eventSource = "s3.amazonaws.com" and eventName = "GetObject" | filter requestParameters.bucketName = "{BUCKET}" | stats count(*) as objectReads by userIdentity.arn, userIdentity.principalId, bin(10m) | filter objectReads > {THRESHOLD} """ for row in run_query(CLOUDTRAIL_LOG_GROUP, access_query, start, end): principal = row.get("userIdentity.arn") if not principal or principal in allowed: continue message = ( f"Principal {principal} read {row.get('objectReads')} " f"objects from {BUCKET}." ) ip = private_ip_for_principal(row.get("userIdentity.principalId", "")) if ip and egress_bytes(ip, start, end) > 1_000_000_000: message += ( f" The same source ({ip}) also sent a large volume of " f"data to external destinations in the same window." ) sns.publish( TopicArn=SNS_TOPIC, Subject="Unexpected S3 access detected", Message=message, ) except ClientError as error: logger.error(f"AWS API error: {error}") raise except Exception as error: logger.error(f"Unexpected error: {error}") raise finally: logger.info("Correlation check completed") [設定] タブで [一般設定] を選択し、 [編集] を選択します。 [タイムアウト] を 5 分 (300 秒) に設定します。 CloudWatch Logs Insights のクエリは非同期で実行され、大規模なロググループでは 30～60 秒かかることがあります。 [保存] を選択します。 [設定] タブで [環境変数] を選択し、 [編集] を選択して、 CLOUDTRAIL_LOG_GROUP 、 FLOWLOGS_LOG_GROUP 、 SNS_TOPIC_ARN 、 SENSITIVE_BUCKET 、 THRESHOLD_READS を追加します。 [設定] タブで [アクセス権限] を選択し、実行ロールを開いて、次の最小権限のポリシーをアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["logs:StartQuery", "logs:GetQueryResults"], "Resource": [ "arn:aws:logs:REGION:ACCOUNT-ID:log-group:aws-cloudtrail-logs-my-trail:*", "arn:aws:logs:REGION:ACCOUNT-ID:log-group:vpc-flow-logs:*" ] }, { "Effect": "Allow", "Action": "ec2:DescribeInstances", "Resource": "*" }, { "Effect": "Allow", "Action": "sns:Publish", "Resource": "arn:aws:sns:REGION:ACCOUNT-ID:security-correlation-alerts" } ] } REGION 、 ACCOUNT-ID 、およびロググループ名を実際の値に置き換えてください。 ec2:DescribeInstances アクションはリソースレベルのアクセス許可をサポートしていないため、このステートメントには Resource: "*" が必要です。その他のステートメントは、特定の ARN に限定しています。 自動実行をスケジュールするには Amazon EventBridge (イベントを使用してアプリケーションを接続するサーバーレスのイベントバス) は、スケジュールに従ってターゲットを実行できます。先ほど作成したロールを使用して、コマンドラインからスケジュールを作成します。 aws scheduler create-schedule \ --name s3-access-correlation-hourly \ --schedule-expression "rate(1 hour)" \ --target "Arn=arn:aws:lambda:REGION:ACCOUNT-ID:function:CorrelationFunction,RoleArn=arn:aws:iam::ACCOUNT-ID:role/EventBridgeSchedulerRole" \ --flexible-time-window "Mode=OFF" ステップ 6: エンリッチメント用のコンテキストを追加する (オプション) エンリッチメントは独立したシグナルを追加することでトリアージの時間を短縮しますが、相関分析の動作に必須ではありません。なお、このステップではコストが発生します。地理位置情報プロバイダーに API コールの料金を支払う必要があるほか、Lambda の実行時間が延びる分、Lambda の料金も増加します。IP の地理位置情報を追加するには、地理位置情報 API にサインアップし、次の関数をコードに追加して、ハンドラーが IP を解決する箇所で呼び出します。 import urllib.request import json def geo_context(ip_address): """Enrich an IP address with geolocation data from your provider.""" try: url = f"https://your-geolocation-api.example/json/{ip_address}" with urllib.request.urlopen(url, timeout=5) as response: data = json.load(response) return { "country": data.get("country_name"), "city": data.get("city"), "org": data.get("org"), } except Exception as error: logger.warning(f"Geolocation lookup failed for {ip_address}: {error}") return None ハンドラーのループ内で ip を解決した後に、アラートに位置情報を追加します。 if ip: geo = geo_context(ip) if geo: message += ( f" Source location: {geo['city']}, " f"{geo['country']} ({geo['org']})." ) ステップ 7: 追加のパターンとアカウントへ拡張する 相関ルールのライブラリが大きくなってきたら、EventBridge、Lambda、 AWS Step Functions (複数のサービスをワークフローとして連携させるサーバーレスのオーケストレーションサービス) を使用してロジックを自動化されたパイプラインに移行し、相関分析の結果を Security Hub の検出結果と並べて表示します。大規模なサービス横断の相関分析には、CloudWatch の統合データおよびテレメトリ機能を活用できます。この機能では、セキュリティとコンプライアンスのデータを OCSF 形式に変換し、CloudTrail、VPC フローログ、DNS ログなどのソースを 1 つのインターフェイスからクエリできます。長期的な分析には、Security Lake と Athena の組み合わせが有力な選択肢です。保持期間とクエリの要件に合ったクエリ基盤を選択してください。 図 3 は、EventBridge、Lambda、Step Functions、AWS Security Hub などの AWS サービスで構築した相関分析パイプラインを示しています。このパイプラインでは、データソースからスケジュールされたクエリとエンリッチメントを経て、自動対応と一元的な可視性の確保へとつながります。 図 3: AWS サービスで構築した相関分析パイプライン まとめ この記事では、GuardDuty 拡張脅威検出にビジネスコンテキストを重ね合わせ、お客様の環境に固有の攻撃をとらえる 4 つの相関分析パターンを紹介しました。どの相関分析を構築する場合にも共通する原則がいくつかあります。 アイデンティティが主要な相関キー: 同じプリンシパルを複数のサービスにわたって追跡します。 時間枠が重要 (ただし、攻撃の種類によって異なる): 自動化された高速なシーケンスでは、数分以内に発生したイベントは通常関連しています。この記事で使用した 10 分間のビンは、そのようなパターンに適しています。一方、時間をかけて行われる偵察や手動の偵察は数時間から数日にわたることがあるため、自動化されたパターンとは異なり、じっくりと進められるパターンの場合は、時間枠を広げてください。 コンテキストはお客様が追加するもの: データ分類、通常のアクセスパターン、リソースの所有関係、変更ウィンドウは、お客様が検出に加えるシグナルです。 1 つのルールから始める: 適切にチューニングされた 1 つの相関分析のほうが、相関付けられていない大量のアラートよりも、重要なアクティビティを的確にとらえられます。 GuardDuty 拡張脅威検出は、多くのお客様に共通する多段階のパターンに対処します。この記事の相関分析は、お客様のビジネスコンテキストでしか提供できないレイヤーを追加するものです。今週まず 1 つのパターンから始めてお客様自身のトラフィックで検証し、信頼性を確認できたら次のパターンを追加してください。 参考資料 Amazon GuardDuty 拡張脅威検出 – GuardDuty が多段階攻撃のパターンを自動的に相関付ける仕組み CloudWatch Logs Insights のクエリ構文 – この記事で使用しているクエリ言語のリファレンス AWS CloudTrail によるデータイベントのログ記録 – パターンが依存する Amazon S3 データイベントを有効にする CloudWatch Logs への CloudTrail イベントの送信 – クエリ可能なロググループに証跡を配信する 組織の証跡の作成 – AWS Organizations 内のすべてのアカウントのイベントを単一のロググループに配信する VPC フローログ – ネットワークトラフィックのシグナルに関するフィールドリファレンス Amazon Route 53 Resolver クエリログ記録 – 裏付けに使用する DNS シグナルをキャプチャする MITRE ATT&CK – 攻撃の戦術と手法に関する業界フレームワーク Open Cybersecurity Schema Framework (OCSF) – Security Lake が使用するスキーマ   Nisha Kashyap Nisha Kashyap は AWS の Senior Support Security Engineer です。脅威検出とセキュリティ運用を担当しています。お客様がセキュリティイベントを調査し、複数の AWS サービスにまたがるシグナルを結び付けてお客様自身の環境を反映した検出の仕組みを構築できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。