本ブログは 2024 年 11 月 5 日に公開された AWS Blog「 Amazon Inspector suppression rules best practices for AWS Organizations 」を翻訳したものです。原文公開後のサービスアップデートを訳注として補足しています。 脆弱性管理は、ネットワーク、アプリケーション、インフラストラクチャのセキュリティに不可欠な要素であり、その目的は、機密データやインフラストラクチャが意図せずアクセスされたり露出したりすることから組織を保護することです。脆弱性管理の一環として、組織は通常、どの脆弱性が最大のリスクをもたらすかを判断するためのリスク評価を実施し、ビジネス目標や全体的な戦略への影響を評価し、関連する規制要件を精査します。 この記事では、 AWS Organizations 内のアカウント全体で脆弱性に適切な優先順位を付けるための仕組みの使い方を説明します。お客様の環境における Amazon Inspector の検出結果にリスクベースで優先順位を付けられるよう、リソースにタグを適用する方法を紹介します。また、重要度の低い検出結果を大規模に抑制するための、Amazon Inspector の抑制ルールの活用に関するベストプラクティスも解説します。さらに、継続的な脆弱性管理の文化を醸成するための取り組みについても取り上げます。 Amazon Inspector による脆弱性管理 Amazon Inspector は、 Amazon Web Services (AWS) のワークロードに対して、ソフトウェアの脆弱性や意図しないネットワークへの露出を継続的にスキャンする脆弱性管理サービスです。Amazon Inspector は、実行中の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Container Registry (Amazon ECR) 内のコンテナイメージ、および AWS Lambda 関数を自動的に検出してスキャンします。 Amazon Inspector は、ソフトウェアの脆弱性や意図しないネットワークへの露出を発見すると、 検出結果 を作成します。検出結果は、脆弱性を説明し、影響を受けるリソースを特定し、脆弱性の重要度を評価して、修復のガイダンスを提供します。Amazon Inspector で 抑制ルール を作成すると、重要度の低い検出結果を抑制し、優先度の高い検出結果に集中できます。 AWS Organizations における脆弱性管理のベストプラクティス AWS Organizations の組織内で数千件におよぶ脆弱性の検出結果に対処しやすくするために、このセクションで説明するベストプラクティスの活用をお勧めします。 ベストプラクティス 1: 委任管理者を設定する Amazon Inspector を使用すると、組織内の複数の AWS アカウントの脆弱性スキャンを管理できます。そのためには、AWS Organizations の管理アカウントが、いずれかのアカウントを Amazon Inspector の委任管理者アカウントとして指定する必要があります。委任管理者アカウントは、Amazon Inspector のデプロイを一元的に制御できるため、AWS Organizations 内の複数のアカウント全体で、セキュリティモニタリングタスクをより効率的かつ効果的に管理できます。これらのタスクには、メンバーアカウントのスキャンのアクティブ化や非アクティブ化、AWS リージョンごとの検出結果の集約、組織全体の集約された検出結果データの表示、抑制ルールの作成と管理が含まれます。 Amazon Inspector はリージョンごとのサービスであるため、Amazon Inspector を使用する各 AWS リージョンで、委任管理者の指定、メンバーアカウントの追加、スキャンタイプのアクティブ化を行う必要があります。委任管理者アカウントを設定する際は、以下の点に注意してください。 委任管理者は、組織内のアカウントの Center for Internet Security (CIS) スキャン設定を作成および管理できます。ただし、メンバーアカウントが作成したスキャン設定は対象外です。 マルチアカウント設定では、組織全体のスキャンモード設定を行えるのは委任管理者のみです。 Amazon Inspector を使用すると、組織全体の Amazon EC2 インスタンスに対して、OS レベルの CIS 設定ベンチマークに基づいたオンデマンドかつ対象を絞った評価を実行できます。 訳注: 2025 年 11 月より、AWS Organizations の Amazon Inspector ポリシーによる組織全体の管理がサポートされました。このポリシーを使用すると、組織内の全アカウント (新規追加アカウントを含む)、組織単位 (OU)、または個別のアカウントに対してスキャンタイプを自動的に有効化し、メンバーアカウントによる意図しない変更を防止できます。本文の委任管理者による管理と併用でき、ポリシーがスキャンタイプの有効化を制御し、委任管理者はスキャンモードなどの詳細設定を引き続き管理します。 ベストプラクティス 2: 抑制ルールで検出結果を大規模に管理する すべてのアカウントの検出結果には、個別の共通脆弱性識別子 (CVE) や Amazon リソースネーム (ARN) が数千件含まれている可能性があります。そのため、適切な抑制ルールを使ってこれらの検出結果を大規模に管理することが、脆弱性管理を成功させる鍵となります。 抑制ルール とは、フィルター属性と値のペアで構成される条件のセットで、指定した条件に一致する新しい検出結果を自動的にアーカイブすることで、検出結果をフィルタリングするために使用します。 抑制ルールを作成 して、対応する予定のない脆弱性を除外することで、最も重要な検出結果に優先順位を付けることができます。抑制ルールは検出結果自体に影響を与えず、Amazon Inspector による検出結果の生成を妨げることもありません。抑制ルールは検出結果のリストをフィルタリングするためだけに使用されます。これにより、検出結果の確認と優先順位付けが容易になります。 抑制ルールで使用できる便利なフィルターには、 [リソースタグ] 、 [リソースタイプ] 、 [重要度] 、 [脆弱性 ID] 、 [Amazon Inspector スコア] があります。例えば、重要度レベル (Critical、High、Medium、Low、Informational、Untriaged) に基づいて検出結果を分類できます。Amazon Inspector が各検出結果の重要度をどのように決定するかについては、「 Amazon Inspector の検出結果の重要度レベルについて 」を参照してください。 Amazon Inspector では、脆弱性、アカウント、インスタンスなどのさまざまなカテゴリで検出結果を絞り込んで確認できます。Amazon Inspector の [すべての検出結果] ページで CVE ID を選択すると、図 1 に示すように、影響を受けるリソースと個々の AWS アカウント ID の詳細を表示できます。これは、抑制ルールで使用するフィルター条件を選択する際に役立ちます。 図 1: Amazon Inspector の検出結果と重要度レベル 抑制ルールは組織レベルで管理します。設定したルールはすべてのメンバーアカウントに適用されます。Amazon Inspector が抑制ルールに一致する新しい検出結果を生成すると、その検出結果のステータスは自動的に [抑制済み] に設定されます。抑制ルールの条件に一致する検出結果は、デフォルトでは検出結果のリストに表示されません。そのため、抑制された検出結果はサービスクォータに影響しません。メンバーアカウントは、委任管理者から抑制ルールを継承します。委任管理者アカウントで作成できる抑制ルールはリージョンあたり 500 ルールで、これは引き上げられない上限 (ハードリミット) です。 組織内のメンバーアカウントは、抑制ルールを作成または管理できないことに注意してください。抑制ルールを作成および管理できるのは、スタンドアロンアカウントと Amazon Inspector の委任管理者のみです。したがって、組織内に自身の抑制ルールを個別に管理する必要があるメンバーアカウントがある場合は、そのアカウントの所有者が自分のアカウントで Amazon Inspector を個別にアクティブ化する必要があります。 ベストプラクティス 3: Amazon Inspector スコアに基づいて検出結果を抑制する 対応に割ける時間は限られており、特に大規模な組織ではセキュリティ脆弱性の検出結果の量が膨大になる可能性があります。そのため、組織に最大のリスクをもたらす脆弱性を迅速に特定して対応できる仕組みが必要です。 検出結果を抑制する手軽なアプローチの 1 つは、 Amazon Inspector スコア を使用することです。Amazon Inspector は、脆弱性に対する National Vulnerability Database (NVD) の共通脆弱性評価システム (CVSS) 基本スコアを構成するセキュリティメトリクスを検査し、お客様のコンピューティング環境に応じて調整したうえで、脆弱性の重要度を反映した 1～10 の数値スコアを生成します。 NVD/CVSS スコアは、攻撃の複雑さ、悪用コードの成熟度、必要な権限などのセキュリティメトリクスを組み合わせたものですが、リスクの尺度ではありません。 検出結果を過度に抑制しないよう注意してください。検出結果を過度に抑制すると、対策されていないセキュリティリスクにアプリケーションやシステムを意図せずさらしてしまう可能性があります。抑制ルールを適用する際は、慎重かつ節度あるアプローチを維持することが重要です。各検出結果の実際のリスクプロファイルを継続的に可視化しておくことは、プロアクティブで包括的な脆弱性管理に不可欠です。 ベストプラクティス 4: タグを使用してリスクベースの優先順位付けを可能にする スケーラブルな脆弱性管理ソリューションを実現するには、アカウント横断でリソースに適切にタグを付ける戦略を持つことが重要です。 脆弱性に優先順位を付けるには、まず各リソースのリスクレベルを理解して評価し、適切にタグを付けられるようにする必要があります。適切なタグ付けにより、 リスクベースの優先順位付け が可能になります。つまり、検出結果を評価する際に、リソースのリスクレベル、脆弱性の重要度、組織の環境に対する脆弱性の影響などの要素を考慮することで、重大な脆弱性に最初に集中できます。これは当たり前の推奨事項のように思えるかもしれませんが、その重要性は決して見過ごせません。クラウドでは、構築したすべてのものを把握し、保護する必要があります。潜在的なセキュリティイベントの影響とリスク経路を理解するために、資産のマッピングでは、資産間の関係性も併せて洗い出す必要があります。 クラウドリソースの問題を修復する際の優先度は、リソースの露出レベルによって決まります。一般的に、パブリックサブネット内のリソースはプライベートサブネット内のリソースよりも優先すべきです。同様に、本番環境で実行されているリソースは、開発環境やテスト環境のリソースよりも優先すべきです。 優先順位付けは、ファイアウォールルール、 AWS Identity and Access Management (IAM) ポリシー、サービスコントロールポリシー、セキュリティグループなどの要素にも左右されます。さまざまなポートやプロトコルを通じてインターネットに広く公開されているリソースは、厳格なアクセス制限があるリソースと比べて、サービス拒否 (DoS)、分散型サービス拒否 (DDoS)、スプーフィング、マルウェア、ランサムウェアなどの問題が発生する可能性が高くなります。 ベストプラクティス 5: 適切なリソースタグに基づいて抑制ルールを作成する 複雑なマルチアカウント環境では、リソース ID、サブネット ID、VPC ID を使用して抑制ルールを一元管理することは困難な場合があります。これらの値は個々のアカウントに固有であり、新しいデプロイや変更に伴って時間とともに変化するためです。その結果、抑制ルールを最新の状態に保つことが難しくなります。ここでは、タグに基づくリスクベースの優先順位付け (ベストプラクティス 4) と Amazon Inspector スコアを活用して、検出結果を効果的に管理し、優先順位を付け、追跡する方法を説明します。 以下は、脆弱性管理を目的として組織内の AWS クラウドリソース全体で使用できる、タグ付け戦略の推奨例です。 EnvironmentName, RiskExposureScore このタグ付け戦略により、環境全体で抑制ルールを通じた優先順位付けを行い、対応を後回しにする、あるいは対応対象外とすべき検出結果を除外し、優先度の高い検出結果に集中できます。また、リスク要因が異なる環境ごとに、個別のルールを作成することもできます。例えば、リスク露出レベルが低く、非本番環境にあり、重要度レベルが Informational、Untriaged、Low、または Medium であるリソースの検出結果を抑制するといったことが考えられます。さらに、レポートの作成やエクスポート時に [リソースタグ] フィールドを活用して、想定内の検出結果を除外することもできます。 以下の表では、Prod、Dev、Sandbox という 3 つの主要なアカウント区分を持つ AWS クラウド環境の例を示しています。想定されるリスク、露出レベル、ワークロードの重要性に基づいて、異なる重要度レベルの検出結果を抑制しています。この例では、RiskExposureScore の 1、2、3 をそれぞれ低、中、高に相当するものとして使用しています。つまり、RiskExposureScore 1 は、機密性が低い、またはインターネットへの露出がほとんどないワークロードに使用します。一方 RiskExposureScore 3 は、機密性が高い、または重要なワークロードのうち、インターネットに露出している、保護が不十分である、あるいは設定やサイバーハイジーン (cyber hygiene) の不備によりセキュリティリスクが高い可能性があるものに使用します。 EnvironmentName RiskExposureScore 重要度 抑制対象 Prod 1 Medium、Low、Informational、Untriaged はい Prod 2 Low、Informational、Untriaged はい Prod 3 Informational、Untriaged はい Dev 1、2 Medium、Low、Informational、Untriaged はい Dev 3 Low、Informational、Untriaged はい Sandbox 1、2 Critical、High、Medium、Low、Informational、Untriaged はい Sandbox 3 High、Medium、Low、Informational、Untriaged はい この例では、Prod および Dev アカウントのリソースについては重要度が High または Critical である脆弱性の検出結果を残す一方で、その他のリソースについてはリスク露出レベルに応じて異なる抑制ルールを定義しています。また、Sandbox アカウントには重要なワークロードがないため、脆弱性の検出結果の大部分を抑制するようにしています。この例をモデルとして、環境全体で抑制ルールを設定し、ニーズに応じて脆弱性の検出結果に優先順位を付けることができます。さらに、修復作業を進めながら抑制ルールを見直し、修正、再評価できることも覚えておいてください。これらを継続的なプロセスとして行うことがベストプラクティスです。 ベストプラクティス 6: Amazon Inspector を AWS Security Hub と統合する Amazon Inspector を AWS Security Hub と 統合 すると、Amazon Inspector から Security Hub に検出結果を送信できます。Security Hub は、これらの検出結果をお客様のセキュリティポスチャの分析に含めることができます。抑制ルールに一致する Amazon Inspector の検出結果は自動的に抑制され、Security Hub コンソールには表示されません。 訳注: 本記事の AWS Security Hub は、2025 年に AWS Security Hub CSPM (Cloud Security Posture Management) へ名称変更されたサービスを指します。現在「AWS Security Hub」は、リスクの優先順位付けなどの機能を備えた別の新サービスの名称として使われているため、コンソールやドキュメントを参照する際はご注意ください。 ベストプラクティス 7: 抑制ルールを定期的に再評価する セキュリティポスチャを最新に保ち、健全なクラウド環境を維持する鍵は、脅威の状況の変化に合わせて脆弱性管理のアプローチを見直し、適応させ続けることです。ここでは、重点的に取り組むべきプラクティスをいくつか紹介します。 脆弱性の検出結果を抑制しているルールを定期的に見直し、再評価してください。脆弱性と脅威は常に進化しているため、以前に抑制したものを再度有効にする必要が生じるかもしれません。 脆弱性管理を静的な手順ではなく、継続的で反復的なプロセスとして捉えてください。新たなリスクにリアルタイムで対処するために、セキュリティコントロールを定期的に評価し、更新し、適応させてください。 初期の修復だけでなく、継続的なモニタリングと対応も重視してください。脆弱性はライフサイクル全体を通じて包括的に対処する必要があります。 セキュリティを意識し、迅速に対応する文化を組織全体で醸成してください。全員が継続的に脆弱性の特定と軽減に取り組むことが求められます。 脆弱性管理プログラムが、関連するコンプライアンス要件や規制要件 (例えば PCI-DSS 、 HIPAA 、 NIST CSF ) に準拠していることを確認してください。 まとめ この記事では、抑制ルールを使用し、リスクベースの優先順位付けを適用することで、組織の AWS インフラストラクチャ全体で Amazon Inspector の検出結果に大規模かつ効果的に優先順位を付ける方法を紹介しました。また、Amazon Inspector の検出結果の修復に優先順位を付けるための効果的な戦略として、リソースのタグ付けを活用する方法についても説明しました。Amazon Inspector に関連するその他のブログ記事については、Amazon Web Services ブログの Amazon Inspector カテゴリ を参照してください。 Mojgan Toth Mojgan は AWS の Senior Technical Account Manager です。公共部門のお客様に対して、戦略的な技術ガイダンス、ソリューション、AWS クラウドのベストプラクティスを積極的に提供しています。Well-Architected Framework に基づいたソリューションを組み立てることが大好きです。仕事以外では、料理や絵画、そして家族、特に 3 人の幼い息子たちと過ごす時間を楽しんでいます。息子たちはサイクリングやハイキングなどのアウトドアアクティビティが大好きです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 1 月 26 日に公開された AWS Blog “ Export a Software Bill of Materials using Amazon Inspector ” を翻訳したものです。 Amazon Inspector は、 Amazon Web Services (AWS) ワークロードのソフトウェアの脆弱性と意図しないネットワークの露出を継続的にスキャンする、自動化された脆弱性管理サービスです。Amazon Inspector の機能が拡張され、 Windows EC2 インスタンス を除く、Amazon Inspector がモニタリングするサポート対象リソースの統合された ソフトウェア部品表 (SBOM) をエクスポートできるようになりました。 訳注: 本記事公開後の 2026 年 2 月 28 日より、エージェントレス方式でスキャンされる Windows EC2 インスタンスの SBOM エクスポートがサポートされました。エージェントベース方式の Windows EC2 インスタンスは引き続き対象外です。詳細は「 Amazon Inspector による SBOM のエクスポート 」を参照してください。 お客様からは、Amazon Inspector がモニタリングするリソースから収集したソフトウェアアプリケーションのインベントリを追加で提供してほしいというご要望をいただいていました。これにより、現在の Amazon Inspector の検出結果に関連する可能性のあるソフトウェアサプライチェーンやセキュリティ上の脅威を追跡できるようになります。SBOM を生成すると、最も頻繁に使用しているパッケージや、組織全体に影響を及ぼす可能性のある関連する脆弱性など、ソフトウェアサプライチェーンの詳細を可視化する重要なセキュリティ情報が得られます。 このブログ記事では、組織全体で Amazon Inspector がモニタリングするリソースの統合された SBOM を、 CycloneDx や SPDX といった業界標準形式でエクスポートする手順を紹介します。また、 Amazon Athena を使用して SBOM アーティファクトを分析するためのアプローチと、そこから得られる洞察についても共有します。 概要 SBOM は、ソフトウェアコンポーネントを構成する要素のリストを含む、ネストされたインベントリとして定義されます。セキュリティチームは、Amazon Inspector の AWS マネジメントコンソールにあるリソースカバレッジページから、組織全体の統合された SBOM を Amazon Simple Storage Service (Amazon S3) にエクスポートできます。 CycloneDx や SPDX の業界標準形式を使用することで、SBOM から得られる洞察をもとに、組織全体でどのソフトウェアパッケージを更新する必要があるか、他に選択肢がない場合はどのパッケージを廃止するかといった意思決定を行えます。個々のアプリケーションエンジニアやセキュリティエンジニアは、コンソールまたはアプリケーションプログラミングインターフェイス (API) の SBOM エクスポートワークフローの中で、特定のアカウント、リソースタイプ、リソース ID、タグ、またはこれらの組み合わせによるフィルターを適用して、単一のリソースやリソースグループの SBOM をエクスポートすることもできます。 SBOM のエクスポート Amazon Inspector の SBOM レポートを S3 バケットにエクスポートするには、SBOM レポートのエクスポート先となる AWS リージョンにバケットを作成して設定する必要があります。Amazon Inspector のみがバケットに新しいオブジェクトを配置できるように、 バケットのアクセス許可を設定 する必要があります。これにより、他の AWS サービスやユーザーがバケットにオブジェクトを追加できないようにします。 各 SBOM レポートは S3 バケットに保存され、指定したエクスポート形式に応じて Cyclonedx_1_4 (Json) または Spdx_2_3-compatible (Json) という名前が付けられます。また、 S3 イベント通知 を使用して、新しい SBOM レポートがエクスポートされたことを各運用チームに通知することもできます。 Amazon Inspector では、SBOM レポートの暗号化に AWS Key Management Service (AWS KMS) キーを使用する必要があります。このキーはカスタマーマネージドの対称暗号化 AWS KMS キーであり、SBOM レポートの保存用に設定した S3 バケットと同じリージョンにある必要があります。SBOM レポート用の新しい AWS KMS キーには、Amazon Inspector がキーを使用できるようアクセス許可を付与する キーポリシー を設定する必要があります (図 1 を参照)。 図 1: Amazon Inspector の SBOM エクスポート 訳注: 現在は、バージョン範囲指定などにより特定の名前・バージョンに解決できないパッケージ (未解決ハッシュ) も SBOM エクスポートに含まれるようになりました。これらのパッケージは脆弱性スキャンの対象にはなりませんが、ハッシュ値がエクスポートされたコンポーネント一覧に記録されます。 前提条件のデプロイ 提供されている AWS CloudFormation テンプレートは S3 バケットを作成し、Amazon Inspector が SBOM レポートオブジェクトをそのバケットにエクスポートできるようにするバケットポリシーを関連付けます。このテンプレートは、SBOM レポートのエクスポートに使用する新しい AWS KMS キーも作成し、Amazon Inspector サービスにキーを使用するアクセス許可を付与します。 エクスポートは、 Amazon Inspector の委任された管理者アカウント または Amazon Inspector の管理者アカウント自体から開始できます。これにより、S3 バケットには Amazon Inspector のメンバーアカウントのレポートが格納されます。同じリージョンにデプロイされた Amazon Inspector から SBOM レポートをエクスポートするには、CloudFormation テンプレートがその AWS アカウントとリージョン内にデプロイされていることを確認してください。複数のアカウントで Amazon Inspector を有効にしている場合は、Amazon Inspector が有効になっている各リージョンに CloudFormation スタックをデプロイする必要があります。 CloudFormation テンプレートをデプロイするには 次の Launch Stack ボタンを選択して、アカウントで CloudFormation スタックを起動します。 テンプレートのスタック名とパラメータ ( MyKMSKeyName と MyS3BucketName ) を確認します。S3 バケット名は一意である必要がある点に注意してください。 [次へ] を選択して、スタックのオプションを確認します。 次のページに進み、 [送信] を選択します。CloudFormation スタックのデプロイには 1～2 分かかります。 CloudFormation スタックのデプロイが正常に完了したら、スタックによって作成された S3 バケットと AWS KMS キーを使用して SBOM レポートをエクスポートできます。 SBOM レポートのエクスポート セットアップが完了したら、SBOM レポートを S3 バケットにエクスポートできます。 コンソールから SBOM レポートをエクスポートするには S3 バケットと AWS KMS キーを作成したのと同じリージョンの Amazon Inspector コンソールに移動します。 ナビゲーションペインから [SBOMs] を選択します。 フィルターを追加 して、リソースの特定のサブセットのレポートを作成します。フィルターを指定しない場合は、アクティブでサポート対象のすべてのリソースの SBOM がエクスポートされます。 希望するエクスポートファイルタイプを選択します。オプションは Cyclonedx_1_4 (Json) または Spdx_2_3-compatible (Json) です。 CloudFormation テンプレートの出力セクションにある S3 バケット URI を入力し、作成した AWS KMS キーを入力します。 [エクスポート] を選択します。エクスポートするアーティファクトの数に応じて、完了までに 3～5 分かかることがあります。 図 2: SBOM エクスポートの設定 エクスポートが完了すると、すべての SBOM アーティファクトが S3 バケットに格納されます。S3 バケットから SBOM アーティファクトをダウンロードすることも、 Amazon S3 Select を使用して標準 SQL クエリでオブジェクトからデータのサブセットを取得することもでき、柔軟に活用できます。 図 3: Amazon S3 Select 訳注: Amazon S3 Select は新規のお客様には提供されていません (すでにご利用のお客様は引き続き利用できます)。同等の処理には、本記事で後述する Amazon Athena の利用を検討してください。 また、 Amazon Athena を使用して高度なクエリを実行したり、 Amazon QuickSight を使用してダッシュボードを作成したりすることで、洞察を得たり傾向を把握したりすることもできます。 クエリと可視化 Athena を使用すると、S3 バケットに保存されている生データに対して SQL クエリを実行できます。Amazon Inspector のレポートは S3 バケットにエクスポートされます。「 AWS Glue クローラーの追加 」のチュートリアルに従って、テーブルを作成しデータをクエリできます。 AWS Glue が S3 データをクロールできるようにするには、AWS Glue クローラーのチュートリアルに記載されているロールを AWS KMS キーのアクセス許可に追加して、AWS Glue が S3 データを復号できるようにする必要があります。 以下は、ユースケースに合わせて更新できるポリシー JSON の例です。AWS アカウント ID の <111122223333> と S3 バケット名の <DOC-EXAMPLE-BUCKET-111122223333> は、必ずお客様自身の情報に置き換えてください。 { "Sid": "Allow the AWS Glue crawler usage of the KMS key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: <111122223333> :role/service-role/AWSGlueServiceRole-S3InspectorSBOMReports" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey*" ], "Resource": "arn:aws:s3::: <DOC-EXAMPLE-BUCKET-111122223333> " }, 注: AWS Glue 用に作成されたロールには、クローラーを作成するために、レポートのエクスポート先である S3 バケットを読み取るアクセス許可も必要です。AWS Glue の AWS Identity and Access Management (IAM) ロールによって、クローラーの実行と Amazon S3 データストアへのアクセスが許可されます。 AWS Glue データカタログを構築した後は、クローラーをスケジュール実行するように設定することで、S3 バケットにエクスポートされる最新の Amazon Inspector の SBOM マニフェストを常に反映した状態に保つことができます。 さらに、クローラーによって追加されたテーブルに移動し、Athena でデータを表示できます。Athena を使用すると、Amazon Inspector のレポートに対してクエリを実行し、環境に関連する出力データを生成できます。生成される SBOM レポートのスキーマは、レポート内の特定のリソース ( Amazon Elastic Compute Cloud (Amazon EC2) 、 AWS Lambda 、 Amazon Elastic Container Registry (Amazon ECR) ) によって異なります。そのため、スキーマに応じて、レポートから情報を取得する Athena の SQL クエリを作成できます。 以下は、SBOM レポート内のリソースについて上位 10 件の脆弱性を特定する Athena クエリの例です。レポートに含まれる CVE (共通脆弱性識別子) を使用して、CVE の影響を受ける個々のコンポーネントを一覧表示できます。 SELECT account, vuln.id as vuln_id, count(*) as vuln_count FROM <Insert_table_name>, UNNEST(Inset_table_name.vulnerabilities)as t(vuln) GROUP BY account, vuln.id ORDER BY vuln_count DESC LIMIT 10; 以下の Athena クエリの例では、上位 10 件のオペレーティングシステム (OS) を、リソースタイプおよびその数とともに特定できます。 SELECT resource, metadata.component.name as os_name, count(*) as os_count FROM <Insert_table_name> WHERE resource = 'AWS_LAMBDA_FUNCTION' GROUP BY resource, metadata.component.name ORDER BY os_count DESC LIMIT 10; 重大な脆弱性を持つパッケージがあり、そのパッケージがプライマリパッケージとして使用されているのか、依存関係として追加されているのかを知りたい場合は、以下の Athena のサンプルクエリを使用して、アプリケーション内のパッケージを確認できます。この例では、Log4j パッケージを検索しています。結果として account ID 、 resource type 、 package_name 、 package_count が返されます。 SELECT account, resource, comp.name as package_name, count(*) as package_count FROM <Insert_Table _name>, UNNEST(<Insert_Table_name>.components) as t(comp) WHERE comp.name = 'Log4j' GROUP BY account, comp.name, resource ORDER BY package_count DESC LIMIT 10 ; 注: サンプルの Athena クエリは、SBOM エクスポートレポートのスキーマに応じてカスタマイズする必要があります。 このソリューションをさらに拡張するには、 Amazon QuickSight を使用して AWS Glue テーブルに接続し、データを可視化するダッシュボードを作成できます。 訳注: Amazon QuickSight は 2025 年 10 月に Amazon Quick Suite へ進化 し、現在は Amazon Quick として提供されています (BI 機能は Quick Sight コンポーネントとして存続し、既存の API や連携は変更なく動作します)。また、本記事の発展形として、Lambda と Amazon EventBridge によるエクスポートの自動化からダッシュボードでの可視化までを実装した「 Enhance container software supply chain visibility through SBOM export with Amazon Inspector and QuickSight 」も公開されています。 まとめ Amazon Inspector の新しい SBOM 生成機能は、複数レベルの依存関係にわたるソフトウェアパッケージのリストを提供することで、ソフトウェアサプライチェーンの可視性を向上させます。また、SBOM を使用して各ソフトウェアパッケージのライセンス情報をモニタリングし、組織内の潜在的なライセンス違反を特定することで、潜在的な法的リスクの回避にも役立ちます。 SBOM エクスポートの最も重要なメリットは、業界の規制や標準への準拠を支援できることです。業界標準の形式 (SPDX と CycloneDX) を提供し、他のツール、システム、サービス (Nexus IQ や WhiteSource など) との容易な統合を可能にすることで、インシデント対応プロセスの効率化、セキュリティ評価の正確性と速度の向上、規制要件へのコンプライアンスの維持を実現できます。 これらのメリットに加えて、SBOM エクスポート機能は、リソース内で検出された OS パッケージやソフトウェアライブラリの把握にも役立ち、業界の規制や標準への準拠をさらに強化します。   この記事で共有した情報に関するご質問がある場合は、 Amazon Inspector re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせ ください。 Varun Sharma Varun は、セキュリティのマントを誇らしげにまとう AWS クラウドセキュリティエンジニアです。Amazon Cognito と IAM の謎を解き明かす才能を持ち、これらのサービスの頼れる専門家です。クラウドのセキュリティ確保の手を休めているときは、セキュリティペネトレーションテストの世界に没頭しています。そして画面から離れているときは、気分を切り替えて、カメラのレンズを通して自然の美しさを捉えています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは、AWS ソリューションアーキテクトの秦です 現在、AI コーディングエージェントの活用が広がり、コーディングの生産性は大きく向上しています。 筆者がとある開発部門で、AI コーディングエージェントの導入を支援するプロジェクトに参加したところ、個人利用の段階では成果が出ていたものの、複数チームへの展開を始めたところでいくつかの課題に直面しました。 本記事では、そのチーム展開の際に直面した課題に対して私たちが実際に行ったアプローチと、そこから得られた学びを共有します。 なお、本記事は、特定のプロジェクトでの経験談であり、すべての組織にそのまま当てはまるとは考えていませんが、これから AI 駆動開発をチームに広げようとしている開発リーダーやアーキテクトの方の参考になれば幸いです。 チーム展開で直面した課題 まず、要点を整理すると、AI コーディングエージェントのチーム展開を始めるうえで見えてきた課題は次の 4 つに集約されました。 出力品質が個人のプロンプトの書き方に依存し、ばらつく 組織で決めた開発プロセス（分析 → 設計 → 実装 → テストなど）のステップに従わないケースがある うまく使えているメンバーの工夫が他のメンバーに共有されない レビューやセキュリティ検証が仕組みとして組み込まれていない 原因を追うと、いずれもエージェントが「チームのやり方」を知らないまま動いていることに行き着きました。 そのため、ルール・プロセス・品質基準をファイルとして整備してエージェントに読ませ、検証で得た学びをルールに還元する取り組みを段階的に進めました。 実装には Kiro を使いましたが、同種の機能があれば他のツールでも構成は再現できると考えています。 なお、ルールを書けばエージェントが必ず従うわけではなく、コンテキストが長いとルールが埋もれる、指示が矛盾すると挙動が不安定になる、といった課題が残ります。 ルール化できる範囲を仕組みで担保する、というのが今回のポイントです。 検討のステップ 検討時には、重要な前提があります。 一度に完成させることはできない ということです。全ルール・全プロセス・全ナレッジを最初から適用しようとすると、書く側も使う側も破綻します。 そこで、整備の進め方を以下のように考えてみました。 あくまで一例として捉えていただければと思います。また、各ステップを整備すると次の問題が見えてくるという構造になっています。 段階 内容 ステップ 1 ルールの明文化 ステップ 2 知識の分割と役割の分離 ステップ 3 ワークフローの構造化と棚卸し ステップ 4 品質ゲートの組み込み ステップ 5 学習ループと組織展開 ステップ 1: ルールの明文化 展開初期は、各メンバーがプロンプトで毎回規約を指示しており、書き忘れた項目はエージェントが自己流で埋めるということも多いかと思います。 そこで、毎回伝えていたルールを Steering のファイルに固定し、全セッションに読み込ませ、既存のコーディング規約から違反頻度の高い項目を抜粋し、技術スタック、禁止事項、完了の定義を加えた形を作ります。 完了の定義は重要で、基準を渡さないと、エージェントはコンパイルが通った時点で「完了しました」と報告し、テストを省略することがあります。 「ビルド成功、単体テスト全パス、Lint エラーゼロ」のように判定可能な形で書くようにすると指示が明確になります。 一方、ビルドコマンドの手順だけを並べただけでは、エージェントが基準を理解せずコマンドを実行するだけになる場合があるため、「何を実行するか」と「何をもって完了とするか」は両方定義しておくと安心です。 ステップ 2: 知識の分割と役割の分離 ルールが育つとコンテキストの肥大化が問題になります。ルールを足したのに守られないルールが増えるというケースがあるため、常時読ませるファイルは禁止・必須ルールだけに絞り、詳細なパターン解説やコード例は必要なときだけ読み込まれる Skills に移します。 もう一つは実装とレビューの分離です。同じエージェントに両方させると「問題なし」で返ってくることが多く、レビュー専用のサブエージェントを分けました。 ただし、ルールに書いてあっても AI レビューが見逃すことがあり、確実に検出したい項目はレビュー側のチェックリストにも重ねて載せています。 委譲はメインエージェントからの一方向のみとし、差し戻しは例えば同一タスク 2 回まで、超えたら人間に渡す運用にします。 ステップ 3: ワークフローの構造化と棚卸し タスク単位は安定しても、設計を飛ばして実装が始まる、テスト省略のまま完了になるというケースがあり、メインエージェントを「自分では実装しないオーケストレーター」とし、指示書にフェーズ順序と完了条件を明記して、満たさなければ次に進めない構成にしました。 セッションをまたぐ引き継ぎには、合否フラグ付きのフィーチャーリストと進捗ログをファイルで残し、開始時に読ませます。 棚卸しに使った 4 象限 この時点で、整備が場当たり的にならないように全体像の棚卸しするために、タイミング軸（事前/事後）× 読者軸（人間/AI）の 4 象限で成果物を分類してみました。 事前（やる前に決める） 事後（やった後に確認する） 人間が読む A. ガイドドキュメント ・方式設計書 ・テスト仕様書 ・リリース手順書　等 B. 記録・承認 ・テスト結果報告書 ・レビュー記録　等 AI が読む C. ルール・パターン定義 ・ steering ・ skills ・ agents 　等 D. 自動検証ツール ・静的解析 ・AI レビュー ・品質ゲート　等 分類してみると、ステップ 1〜2 で作ったものは C 象限（AI が事前に読むルール）に集中しがちで、A・B 象限は従来の開発プロセスの資産がそのまま残っている一方、D 象限（AI の出力を事後に機械検証する仕組み）は追加整備が必要な状況でした。 D はルールが守られたかを確認する整備になっていて、これが次の品質ゲートに取り組むきっかけになります。 また、A・B 象限の成果物は残り続けますが、人間がどの粒度で読むかは変わってきます。実際、テスト結果は AI が要約したものを人間が確認する形に移りつつあります。 変わらなかったのは、承認の責任がプロセスのどこにあるかであるため、この観点を整備の判断軸にしています。 ステップ 4: 品質ゲートの組み込み ステップ 1 が基準の「宣言」だとすると、ステップ 4 はその「守り」です。この二つが対になって初めてエージェントの環境整備が機能します。そのために品質ゲートを検討します。品質ゲートは次の 2 点がポイントです。 合否判定可能な完了条件 : 「ビルド成功」「静的解析の指摘ゼロ」など、機械的に Yes/No が決まる条件を事前に合意する 不合格なら進めない構造 : 条件を満たさない限り次フェーズに進めない関門を仕組みとして置く 実装は、ビルド・カバレッジ・静的解析・AI レビューを一括実行するゲート用サブエージェントを定義し、タスク完了時にオーケストレーターから呼び出す形にして、不合格ならタスクは未完了に戻ります。 既存の CI で検証できる項目は同じコマンドをゲートからローカルで実行して再利用し、ブラウザ操作での E2E テストや AWS リソースの検証など、CI に乗っていない検証だけを Model Context Protocol (MCP) による外部ツール連携で追加しました。ゲートを新規に作るというより、既存の検証資産を関門として組み込み直す作業が中心になるかと思います。 また、ゲートに入れる項目は機械判定できるものに限定しました。要件の妥当性のような項目まで入れると、判定が安定せず外す可能性があります。 UX の良し悪しなど熟練者の判断に依存する項目は人間レビューに残し、ゲートは「機械で落とせる不合格を先に落とし、人間のレビューを設計判断に集中させる前処理」と位置づけました。 4 象限でいえば、D 象限を埋めた上で、B 象限の人間の承認は残す、という分担です。 また、整備の効果測定には「評価セット」を用意しました。チームで頻出するタスクの指示文（既存画面への項目追加、API エンドポイントの新設など）を数個固定したテスト問題集のようなもので、同じ指示を複数回実行し、品質ゲートをすべて通過した割合を成功率として記録します。 AI の出力は同じ指示でも毎回変わるため、1 回の試行では整備の効果を判断できないからです。ルール変更の前後でこの成功率を比較することで、「なんとなく良くなった」ではなく数値で改善を確認できるようにしました。 ステップ 5: 学習ループと組織展開 また、環境整備する上で得た学びとして、レビューで繰り返し指摘されるパターンを記録し、汎用的なものは Steering や Skills に「昇格」させるという営みも重要です。 この記録と昇格のトリガーには Hooks を使い、セッション終了時に、開発者が入力した修正指示を自動的に学習候補として記録し、後から Steering / Skills への昇格を判断する運用です。 同時に、モデルの進化に応じて効きの薄くなったルールを削る「棚卸し」も行います。ルールは積み上げるだけでなく、不要になった補助輪を外す運用も含みます。できれば数か月に一度の再評価が目安です。 まとめ 本記事では、AI コーディングエージェントをチームに展開する際に直面した課題と、それに対して私たちが行った環境整備をご紹介しました。 チーム展開で見えてきた課題は、出力品質のばらつき、開発プロセスの不徹底、工夫の属人化、検証の仕組みの不在の 4 つでした。 いずれもエージェントが「チームのやり方」を知らないまま動いていることが原因であり、ルール・プロセス・品質基準をファイルとして整備してエージェントに読ませ、得られた学びをルールに還元する、という取り組みを段階的に進めました。 整備は一度に完成させるのではなく、ルールの明文化から始めて、知識の分割と役割の分離、ワークフローの構造化、品質ゲートの組み込み、学習ループの構築へと、各ステップで見えてきた課題に応じて進めています。本文で挙げた各ステップの症状は、チームの整備がどこまで進んでいるかを見極める手がかりにもなるかと思います。 特定のプロジェクトでの経験談ではありますが、これから AI 駆動開発をチームに広げようとしている方の参考になれば幸いです。 著者のプロフィール 秦 将之 ソリューションアーキテクトとして、お客様の AWS 導入と活用のご支援を担当しています。開発プロセスの改善や自動化が好きで、最近は Kiro Crew を使った開発ワークフローを試しています。 堀 貴裕 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業やシステムインテグレーターのお客様のご支援を中心に活動しています。最近は Kiro を使ったお客様の業務変革支援に邁進中です。 参考 Kiro Documentation: https://kiro.dev/docs/

本ブログは、コニカミノルタ株式会社と Amazon Web Services Japan が共同で執筆しました。 はじめに 2026 年 6 月 25 日、26 日に幕張メッセで開催された AWS Summit Japan 2026 で、コニカミノルタ株式会社 ( 以下、コニカミノルタ ) は「Amazon Bedrock による自然言語駆動型自律実験」を展示しました。自然言語の指示を AI が構造化し、カメラで実験台の状態を確認しながらロボットアームを動かし、結果を電子実験ノートへ戻すデモです。生成 AI、ロボティクス、記録基盤を一つの流れにつなぎ、Physical AI による「未来の実験室」の可能性を紹介しました（図 1）。 図 1 展示した実機デモ。 Amazon Bedrock  とロボティクスを組み合わせ、「未来の実験室」の可能性を示しました。 1. 研究開発と「未来の実験室」 コニカミノルタは、光学・画像・材料・微細加工の技術を幅広い事業で培ってきました。研究開発では、実験内容を次の判断へつなげる記録も重要です。電子実験ノートと社内ナレッジ共有基盤に、生成 AI の要約・通知を組み合わせ、記録を検索・再利用しやすくしています（図 2）。今回の展示は、この基盤を実験の指示と実行まで広げる試みです。 図 2 電子実験ノートの記録を生成 AI が要約・通知する仕組み。 2. Materials Informatics (MI) を支えるハイスループット実験 MI には十分な実験データが必要です。しかし材料開発は、高粘度材料や粉体、多段工程などを扱うため、既製の自動化設備を適用しにくい場合があります。 「未来の実験室」では、目的別に設計するハイスループット（HT）実験でデータを増やし、MI や生成 AI で次の判断を支援します。記録、実行、解析を循環させ、開発を加速します（図 3）。 図 3 「未来の実験室」の構想。生成 AI とロボットの連携により、発案、計画、実行を支援します。 3. 展示したデモ 来場者が電子実験ノートに「緑色を作ってください」などと入力すると、システムが複数のカラーフィルムから必要なものを選び、ロボットアームが重ね合わせて目標色へ近づけます。カメラが実験台を撮影し、Amazon Bedrock 上の基盤モデルが自然言語と画像からフィルムの種類と順番を判断します。ロボットアームは指定された操作を実行し、その結果を次の判断に利用します。 色づくりは短時間で仕組みを理解できる展示用タスクですが、人が目的を伝え、AI が状態を見て操作を選び、ロボットが実行する閉ループ実験の最小構成になっています。 発展例として、pH の値を見ながら溶液を加え、目標値まで調整する動画も紹介しました。将来は試薬調整、測定、分析、記録へ広げます。 図 4 システム構成。電子実験ノートの指示を Amazon Bedrock が解釈し、Worker PC を介してロボットアームを動かします。 4. 自然言語を安全に物理操作へつなぐ 安全性、再現性、監査性を確保するため、LLM が座標や動作列を直接生成せず、自然言語を構造化された中間表現へ変換します。例えば「緑色を作ってください」という指示を、目標色、利用可能なフィルム、操作候補、停止条件などに分解し、JSON 形式で出力します。座標制御やアクション列は、人が設計した決定論的な制御層が担います（図 5）。 図 5 自然言語から座標データまでの流れ。LLM は構造化と関数選択を担い、後段を検証可能な処理にしています。 存在しない対象や実現できない色を指定された場合は、無理に操作せず停止します。Physical AI では、動作性能だけでなく、止まるべき場面で確実に止まる設計が重要です。 5. 軽量モデルで動かせた理由 Amazon Bedrock 上の Claude Haiku 系モデルを使用しました。LLM の役割を自然言語と画像の解釈、中間表現への変換に絞り、物理制御を決定論的ロジックへ分けることで、軽量モデルでも速度とコストを両立しました。 6. 来場者の反応と開発 製造、化学、通信、商社、メディア、SIer など幅広い業界の方にご覧いただき、自然言語の指示でロボットが動く様子に関心が集まりました。 技術者から特に多かったのは、「LLM が生成した JSON を制御関数や座標へどう変換するか？」という質問です。AI の判断範囲と機器制御の境界に、実装上の本質があることを共有できました。座標を直接指定する試作から、Stack、Pick、Place、Remove などの操作をカプセル化。ここまでを 2 ヶ月ほどで実装し、開発には Kiro CLI をフル活用しました。 7. 研究開発基盤への展開 この展示を Physical AI と呼ぶのは、AI が現実の状態を観察し、目標との差を判断して物理操作を行うためです。ただし、目指すのは一過性のロボットデモではありません。 実験の指示、条件、操作、結果、ログを電子実験ノートへ戻し、検索・追跡できる形で残すことが重要です。再利用可能な記録が、次の仮説検証、品質確認、知財化や論文化を支えます。 自然言語の実験意図を Amazon Bedrock で構造化し、物理操作へつなぎ、結果を記録へ戻す。この循環により、実験室を知識、データ、実行が連携する研究開発基盤へ変えていきます。コニカミノルタには、産業機器のハードウェア技術、光学・画像・材料の知見、クラウド人財、研究開発現場があります。記録、再現性、品質、知財まで横断して設計できる点が強みです。 8. 今後の展望 今後は、複数のロボットアーム、搬送ロボット、電子天秤、ピペット、pH メーター、分注機、測定装置などとの連携を検討します。自動化自体を目的にせず、HT 化する実験と蓄積するデータの粒度を設計します。装置、材料、データサイエンス、クラウド、現場運用を横断し、実験をデータ駆動型へ変えます。 実運用では、判断と結果を検証できるログが不可欠です。安全性、品質、知財、監査性を考慮し、AI、ロボット、人が担う範囲と、記録する情報を明確にします。 まとめ 今回の展示は、自然言語で書かれた実験意図を生成 AI が構造化し、ロボットの物理操作へ変換し、結果を実験記録へ戻す最小構成を示したものです。 生成 AI の価値はチャット画面の中だけにとどまりません。記録、クラウド、AI、ロボティクスがつながることで、実験室は知識を蓄え、その知識から次のデータを生み出すシステムへ変わります。 コニカミノルタと AWS は、今後も対話と実装を重ね、生成 AI とクラウドが研究開発にもたらす可能性を探っていきます。 図 6 AWS Summit Japan 2026 で展示を担当したコニカミノルタメンバー。 執筆者 コニカミノルタ株式会社 技術開発本部 データサイエンスセンター データジェネレーション部 野場 考策 技術開発本部 データサイエンスセンター データジェネレーション部 室田 和敏 技術開発本部 デバイス技術開発センター マテリアルサイエンス部 成毛 章容 アマゾンウェブサービスジャパン合同会社 ハイテク&ヘルスケア事業本部 アカウントマネージャー 池田 拓生 ソリューションアーキテクト 森下 裕介

モノやサービスが生まれる現場では、開発から運用に至るさまざまなフェーズで、日々多くのデータが生まれています。かつてのモノづくりの現場では、「製品が世に出たら、お客様がどう使っているかは見えづらい」ことが当たり前でしたが、この前提は変化しつつあり、現在はモノやサービスがリリースされた後も、さまざまなシグナルを得られる時代になりました。顧客管理や売上の履歴、お客様からの問い合わせ、レビュー、デバイスが送信する稼働メトリクスなど…。これらのデータから得られるシグナルを速やかにキャッチして改善につなげていくことが、モノ・サービスの競争力を高め、企業価値を成長させる大きな要素になりうるでしょう。 しかし現実には、これらのデータを活用し、開発サイクルへシームレスにつなげられている組織は、まだ多くありません。データは集まっている、だがそれらを活用しきれていない、といったお声はよくいただきます。 本記事では、どうすればリリース後のデータを活用し、得られたインサイトを次の開発サイクルに適用できるのかを掘り下げ、誰もが体験可能なサンプルシナリオとともに紹介します。 なぜ運用データは次の開発につながらないのか 図 ：運用フェーズにおけるデータ活用イメージ リリース後に集まるデータを製品の改善に活かそうとするとき、多くの組織が共通して行き当たるのが、二つの「サイロ」に関する課題です。 一つ目は、 サイロ化されたデータに関する課題 です。納品実績は営業部門に、問い合わせ履歴はサポート部門に、稼働データは保守部門に、製品仕様は開発部門にと、データは複数のドメインに分散しています。製品の問題解決や顧客要望に応える必要性が顕在化したとしても、担当者は自部門のデータにしかアクセスできず、全体像を見渡せないまま、調査の方向性を定めることすら難しいのが実情です。 二つ目は、 サイロ化された人材に関する課題 です。意味のある分析を行うためには、データを扱う技術、製品の知識、現場の実情という複数領域の知識が必要とされることも多いでしょう。しかしながら、多くの組織において、横断的な知識を備えた人材が存在することは稀です。真の課題にたどり着くために、複数のステークホルダーを集めて議論を重ねるケースも多いと思います。もちろんそれは有益であるものの、どうしても結論にたどり着くまでに時間がかかってしまい、スピーディーな解決につながりづらいことも多いと考えられます。 これら 2 つのサイロを乗り越え、日々集まるデータを改善サイクルの起点に変えていくには、次のような仕組みが鍵になるはずです。 さまざまな場所に分散するデータを、仮想的に一つにまとめて扱える仕組み 構造化・非構造化を問わず、用途に応じて多様なデータを分析対象にできる仕組み データとその分析結果を、組織共通の資産として共有できる仕組み 分析の専門家でなくても自然言語で問いを立てられ、誰が使っても一定品質の調査結果を得られる仕組み 指示されたデータの加工や集計を行うだけでなく、自ら問題を分析し、仮説を立ててデータで検証を進められる仕組み 分析結果を、次のアクションにつながる形で他システムへ連携できる仕組み Agentic AI アシスタント Amazon Quick によるデータと人のサイロの解決 これらの仕組みは、Agentic AI アシスタント Amazon Quick で実現可能です。Amazon Quick は、タスクの自動化・データ分析・Web アプリ構築・リサーチといった作業を、専門知識なしで一元的に行うことができるサービスです。 本来、AI エージェントを自前で動かすには、設備・電源・ネットワーク・サーバーなどのインフラ管理に加えて、モデルの選定やエージェントの実装、ガードレールの整備まで多くの手間が伴います。Amazon Quick はこれらをフルマネージドで引き受け、利用者はコードを書くことなくエージェントを設計・活用でき、ガードレール機能も組み込みで利用できます。さらに、入力したデータは自社の管理下に保たれ、基盤モデルの学習に使われることもありません。AWS のインフラストラクチャー自体もセキュアに運用されており、利用者は安心して分析に集中できます。 以下に、Amazon Quick の全体像を示します。 図 ：Amazon Quick 全体像 Amazon Quick では、 Quick Spaces （以下 Spaces ）という仮想的なデータコンテナを作成できます。Spaces には、さまざまな場所（AWS 上のストレージサービスやデータベースサービスのほか、外部 SaaS、オンプレミスのデータベースやファイルサーバーなど）にある構造化データおよび非構造化データを仮想的にまとめます。これによって、データサイロを排除し情報探索を効率化することができます。 Amazon Quick の Quick Chat （以下 Chat ）は、データの探索、分析、アクションの実行を支援する対話型のアシスタントです。前述の Spaces と Chat は簡単な手順で接続でき、そうすると Chat は Spaces にあるリソースを使って回答、タスク遂行を行います。このとき Chat は、指示されたデータの加工や集計をこなすだけではありません。与えられたゴールに向けて、自ら分析の計画を立て、仮説の立案とデータによる検証を繰り返しながら、結論へと近づいていきます。Spaces にタスク遂行に必要なデータが集約されていれば、Chat の裏にある Agentic AI はタスクに関連するデータだけで結果を生成するため、ユーザーは関連性の高い回答を得られます。また、Chat にはエージェントの振る舞いを自然言語の指示としてあらかじめ定義できる機能（ カスタムチャットエージェント ）があります。ここに優秀なアナリストの思考手順を思考ルールとして仕込んでおくことで、誰が使っても一定以上の品質の調査やアクションを実行できるようになります。分析結果はチケット管理システムなどの外部ツールへ連携できます。このように、データを扱う技術・製品知識・現場の実情という複数領域の知識が一人に揃わなくても、Agentic AI がその隙間を埋めることで、人材のサイロを越えた分析が可能になります。 アニメーション ：Quick Chat を活用したデータの深堀り分析 製品改善サイクルのサンプルシナリオ 製造業の業務での活用イメージを明確にするために、一つの「モノ」の開発サイクルを例に、具体的なシナリオを辿ってみましょう。 あなたは、空調機器（HVAC）メーカーの品質マネージャーである、と想像してください。あなたは、製品の品質を向上することに責務を負っていますが、製品の内部仕様に熟知しているわけではありません。そのような状況で、「ある時点から『冷房が効かない』という問い合わせが急増している」という情報を得ました。あなたはこれに対処する必要があります。 あなたはまず、その事実を確認するために、Quick Chat を使って「問い合わせの傾向を分析してください」と依頼します。すると、Agentic AI は、裏で接続されたお問い合わせデータと顧客管理台帳を参照し、問い合わせ傾向の事実を確認します。 続いて、「なぜそれが起こったのでしょうか。仮説を立ててください」と依頼して、Agentic AI に根本原因の仮説を立てさせます。さらに、稼働データ、ソフトウェアのバージョン、製品仕様書…など、接続されたデータを行ったり来たりしながら仮説を検証させます。最終的に、あなたが Agentic AI の力を借りながら、複数の根拠を元にして問題の原因にたどり着くことができます。 特定した根本原因を解決する方法はいくつか考えられるはずです。それらを遂行するためには、これまでの分析の経緯と必要な対策を他部門に連携する必要があります。この連携のためのチケット情報を Agentic AI が生成し、他部門が利用するシステムへの連携を支援します。チーム間の情報連携は一般的に手間がかかりますが、カスタムチャットエージェントに情報連携のルールをあらかじめ定義しておけば、そのルールに沿って情報が受け渡されるため、開発チームはすぐに内容を確認し、改善に着手することが可能です。 このように、あなたは Amazon Quick 上の Agentic AI を活用して、モノに関わって生まれるさまざまなデータを製品価値の向上に活用し、製品の開発サイクル全体をシームレスに形成することができました。 ワークショップで体験する 本ブログでご紹介したとおり、Amazon Quick を活用して、製品・サービスの改善サイクルを作ることが可能です。これを擬似的に体験できるワークショップを用意しています。 Accelerating Smart Product SDLC with AI Agent Workshop このワークショップは、ソフトウェア開発における、計画、開発、テスト、リリース、運用、の各フェーズを体験できる合計 5 つの Lab で構成されています。本ブログで紹介した運用フェーズにおけるデータ活用は、Lab 5 で体験できます。Lab 1 から Lab 4 では、計画からリリースまでのいわゆる製品開発の工程を体験できます。こちらの内容の詳細については、 Accelerating Smart Product SDLC with AI Agent Workshop のご紹介 をぜひご覧ください。Lab 5 だけ体験することも、5 つの Lab のうちいくつかをピックアップして体験することも可能です。 まとめ モノやサービスはリリースして終わりではなく、運用の中で生まれるデータこそが次の開発の起点になります。しかし多くの組織では、データと人材の 2 つのサイロがその活用を阻んでいます。Amazon Quick を使えば、分散するデータを Spaces でひとつにまとめ、Chat によって誰もが自然言語で横断的な分析を行い、その結果を開発チームへのアクションにシームレスにつなげられます。まずはワークショップで、運用データが開発サイクルへとつながる体験をお試しください。 ご質問や、自社での適用に関するご相談は、担当のソリューションアーキテクトまたは AWS へのお問い合わせ までお寄せください。 関連ブログ Accelerating Smart Product SDLC with AI Agent Workshop のご紹介

本ブログは 2026 年 8 月 6 日に公開された AWS Blog “ Automate certificates with ACME support in AWS Certificate Manager ” を翻訳したものです。 大規模な TLS 証明書の管理は、運用上の最大の懸念事項の 1 つであるとお客様からお聞きしています。 Certification Authority Browser Forum (CA/Browser Forum) は、パブリック証明書の最大有効期間の段階的な短縮を義務付けました。2027 年 3 月までに、最大有効期間は 100 日に短縮されます。2029 年 3 月までには 47 日となります。証明書を 1,000 件管理している組織にとって、最終段階への移行は、毎日およそ 30 件の更新イベントが発生することを意味します。このペースでの証明書の更新と、更新された証明書のローテーションは、手作業やチケットベースのワークフローで大規模に維持できるものではありません。 AWS は先日、 AWS Certificate Manager (ACM) における Automated Certificate Management Environment (ACME) プロトコルのサポートを発表しました。今回のリリースにより、certbot、cert-manager、acme.sh、win-acme などの人気のあるオープンソースツールをはじめ、チームが既に使い慣れている ACME クライアントを使用して、インフラストラクチャのパブリック証明書の発行と更新を自動化できます。サードパーティの認証機関 (CA) を利用しているお客様は、最小限の設定変更で、既存の ACME 互換クライアントの接続先を現在の CA から ACM に切り替えることができます。これは、 Amazon Web Services (AWS) 上、オンプレミス、ハイブリッド環境のいずれで実行している場合でも同様です。ACME を通じて作成された証明書は ACM に登録されるため、証明書インベントリ全体を統合的に把握できます。 この記事では、この機能の仕組み、開始方法、そして証明書の発行を大規模に管理するためのコントロールとベストプラクティスについて説明します。 背景 ACME は、ドメイン所有権の検証と証明書の発行のプロセスを自動化するオープンソースプロトコルであり、証明書自動化の標準的な仕組みとなっています。ACM は、 Elastic Load Balancing (ELB) 、 Amazon CloudFront 、 Amazon API Gateway などの AWS 統合サービスに対して、マネージド型の証明書発行と更新を長らく提供してきました。しかし多くのお客様は、データセンター内で管理するサーバー、Kubernetes クラスター、モノのインターネット (IoT) フリート、ハイブリッド環境など、独自のインフラストラクチャの証明書も自動化する必要があります。これまで、そうしたお客様は外部プロバイダーに頼らざるを得ませんでした。今回のリリースにより、AWS が管理する証明書エンドポイントと標準の ACME プロトコルを使用して、ACM の自動化モデルをそうしたインフラストラクチャにも適用できるようになります。 仕組み この機能では、一元的にプロビジョニングおよび管理される新しいリソースタイプである ACME エンドポイントが導入されます。各エンドポイントは、一意の ACME ディレクトリ URL と AWS Identity and Access Management (IAM) ベースのアクセスコントロールを持つ AWS リソースです。ACM の API または AWS マネジメントコンソールを通じてエンドポイントを作成および管理し、既存の ACME クライアントの接続先をエンドポイント URL に設定します。エンドポイントを通じて発行された証明書は自動的に ACM に登録され、 RequestCertificate および ImportCertificate API コールで作成された証明書と並んで証明書インベントリに表示されます。 このアーキテクチャは 2 つのプレーンに分かれています。コントロールプレーンでは、PKI 管理者が ACM の API を使用して ACME エンドポイントを作成し、そのエンドポイントが証明書を発行できるドメインを事前承認し、外部アカウントバインディング (EAB) 認証情報を生成します。データプレーンでは、ACME クライアントが EAB 認証情報を使用してエンドポイントに登録し、管理者が既に検証済みのドメインに対して証明書をリクエストします。このアーキテクチャによって、お客様は証明書の発行をスケールできるようになります。各クライアントがリクエストのたびにドメイン所有権を証明するのではなく、適切な ACM アクセス許可を持つプリンシパル (通常は PKI 管理者) がエンドポイントレベルで一度だけドメインを検証するため、アプリケーション所有者は証明書を取得するために DNS の認証情報を必要としません。 データプレーンではさらに、EAB がエンドポイントへのクライアントアクセスを制御します。各 EAB は、ACME クライアントが実行できる証明書操作を制御する IAM ロールにバインドされており、ACM で生成した認証情報は認可された ACME クライアントに配布されます。あるエンドポイントに対して認可された ACME クライアントは、別のエンドポイントを使用できません。これにより、環境間にセキュリティ境界が作られます。例えば、開発用エンドポイントに対して認可されたクライアントは、本番用エンドポイントから証明書を取得できません。 図 1 は、ACM を通じた ACME リクエストのフローを示しています。ACME クライアントは、EAB 認証情報を使用して ACME エンドポイントに対して認証を行います。エンドポイントは、証明書のオーダーを発行のために Amazon Trust Services にルーティングします。発行された証明書は ACM インベントリに登録され、 Amazon EventBridge と AWS CloudTrail によって、有効期限のアラートと監査ログが提供されます。 図 1: ACME のアーキテクチャとワークフロー 開始方法 ACM の新しい ACME 機能は簡単に始められます。以下の手順に従って、ACME で発行する最初の証明書を作成してください。 前提条件 ACM リソースを作成および管理するアクセス許可を持つ AWS アカウント インフラストラクチャにインストール済みの ACME クライアント (Certbot、cert-manager、acme.sh など) デバイスにインストール済みの AWS コマンドラインインターフェイス (AWS CLI) (コンソールでの同等の手順については、こちらのブログ記事「 AWS Certificate Manager の ACME サポートを使用してパブリック TLS 証明書の発行を自動化 」を参照してください) 証明書を発行するドメインの Amazon Route 53 ホストゾーン、または DNS プロバイダーで CNAME レコードを作成できる環境 ステップ 1: ACME エンドポイントを作成する ACME クライアントを ACM で使用する前に、ACME エンドポイントを作成する必要があります。このエンドポイントは、ACME クライアントが証明書のリクエストに使用する URL を提供します。 AWS CLI から以下のコマンドを実行して、ACME エンドポイントを作成します。 aws acm create-acme-endpoint \ --authorization-behavior PRE_APPROVED \ --certificate-authority '{"PublicCertificateAuthority":{"AllowedKeyAlgorithms":["EC_prime256v1"]}}' レスポンスからエンドポイントの Amazon リソースネーム (ARN) をメモします。 {"AcmeEndpointArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555"} 以下のコマンドを実行してエンドポイント URL を取得します。ARN の部分は作成したエンドポイントの ARN に置き換えてください。 aws acm describe-acme-endpoint \ --acme-endpoint-arn arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555 出力される ACME の EndpointUrl を保存します。 { "AcmeEndpoint": { "AcmeEndpointArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555", "EndpointUrl": "https://acm-acme-enroll.<region>.api.aws/6666666-7777-8888-9999-000000000000/directory", "Status": "ACTIVE", "AuthorizationBehavior": "PRE_APPROVED", "Contact": "REQUIRED", "CertificateAuthority": { "PublicCertificateAuthority": { "AllowedKeyAlgorithms": [ "EC_prime256v1" ] } }, "CreatedAt": "2026-07-14T18:23:58.876000-04:00", "UpdatedAt": "2026-07-14T18:23:58.876000-04:00" } } ステップ 2: ドメインを事前承認する ACME クライアントが証明書をリクエストできるようにする前に、管理者がエンドポイントレベルで一度だけ DNS を使用してドメインを検証します。 DomainScope を使用して、許可する証明書パターンを正確に制御します。 ExactDomain のみを有効にすると、クライアントはその特定の名前に限定されます。 Subdomains を有効にすると、 api.example.com のような名前が許可されます。 Wildcards を有効にすると、 *.example.com が許可されます。 スコープを無効のままにしておくと、それ以外の点では有効な ACME リクエストがそのパターンを要求したとしても、完全にブロックされます。本番用エンドポイントでは、よりセキュリティを強化した構成とするために、 ExactDomain と Subdomains のみを有効にし、 Wildcards は無効のままにしておくことを検討してください。 aws acm create-acme-domain-validation \ --acme-endpoint-arn arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555 \ --domain-name example.com \ --prevalidation-options '{"DnsPrevalidation":{"DomainScope":{"ExactDomain":"ENABLED","Subdomains":"ENABLED","Wildcards":"DISABLED"},"HostedZoneId":"Z1234567890ABC"}}' ドメインが Route 53 でホストされている場合、 HostedZoneId を指定すると、ACM が必要な CNAME レコードを自動的に作成します。ドメインが他の場所でホストされている場合は、この指定を省略し、提供される CNAME レコードを DNS プロバイダーで手動で作成してください。レコードが作成されると、通常は数秒以内に検証が完了します。 以下のレスポンスが返されます。 { "AcmeDomainValidationArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/1111111-2222-3333-4444-555555555555/acme-domain-validation/6666666-8888-9999-0000-11111111111" } ステップ 3: EAB 認証情報を生成する EAB 認証情報は、ACME クライアントをエンドポイントに対して認証するために使用されます。セキュリティ境界を維持するため、クライアントまたは環境ごとに一意の認証情報を生成してください。 以下のコマンドを実行して EAB 認証情報を生成します。有効期限は組織のリスクプロファイルに合わせて調整してください。 aws acm create-acme-external-account-binding \ --acme-endpoint-arn arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000 \ --role-arn arn:aws:iam::111122223333:role/AcmeIssuanceRole \ --expiration '{"Value": 7, "Type": "DAYS"}' コマンドが正常に実行された際のレスポンスをメモします。 { "ExternalAccountBinding": { "AcmeExternalAccountBindingArn": "arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000/acme-external-account-binding/1234567-1234-1234-1234-123456789012", "AcmeEndpointArn": "arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000", "RoleArn": "arn:aws:iam::123456789012:role/service-role/AcmAcmeIssuanceRole-XXXXXXXX", "ExpiresAt": "2026-07-21T18:47:50.641000-04:00" } } 以下のコマンドを実行して認証情報を取得します。これらの値は、次のステップで ACME クライアントの設定に必要になります。 aws acm get-acme-external-account-binding-credentials \ --acme-external-account-binding-arn arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000/acme-external-account-binding/22222222-2222-2222-2222-222222222222 次のステップのために KeyId と MacKey を保存します。 { "KeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "MacKey": "xxxxxxxx-xxxxxxxxxx-xxxxxxxxxxxxxxx" } ステップ 4: ACME クライアントを設定する エンドポイント URL と EAB 認証情報が準備できたら、使用する ACME クライアントを設定できます。以下は、人気のある 2 つのクライアントの設定例です。なお、サーバー情報には、ステップ 1 の手順 4 で EndpointUrl として取得した値を使用します。 acme.sh: acme.sh --issue --server https://acm-acme-enroll.us-east-1.api.aws/123457-1234-1234-123456789012/directory \ --eab-kid <KeyId> --eab-hmac-key <MacKey> \ --email <EMAIL> \ -d <DOMAIN> \ --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please Certbot: certbot certonly --standalone --non-interactive --agree-tos \ --email <EMAIL> \ --server https://acm-acme-enroll.us-east-1.api.aws/1234567-1234-1234-123456789012/directory \ --eab-kid <KeyId> \ --eab-hmac-key <MacKey> \ -d <DOMAIN> 最初の登録が完了すると、以降の更新は ACME クライアントが処理します。 エンタープライズ向けのコントロール ACME に対応した他のサービスでも証明書は取得できますが、証明書環境をスケールする必要があるお客様に対して、同等のコントロールとガバナンスは提供されません。組織全体のリスクを軽減するために、以下のコントロールが利用できます。 ドメイン検証 多数のドメインを管理しているお客様から、ドメイン空間全体にわたって不正な証明書の発行を防ぐ方法が必要だという声をいただいています。ドメイン検証によって、これを制御できるようになります。検証する各ドメインに対して、そのドメインで発行を許可する証明書パターンを、 ExactDomain 、 Subdomains 、 Wildcards の中から有効にします。例えば、 internal.example.com を検証して Wildcards のみを有効にした場合、ACME クライアントは *.internal.example.com をリクエストできますが、 internal.example.com 自体や api.internal.example.com のリクエストは拒否されます。この制御は、リクエストが ACM の認証機関に到達する前にエンドポイントレベルで適用されます。また、1 つのエンドポイントの下で複数のドメインを、それぞれ独自のスコープで検証できます。 証明書の一元的な可視化 ACME エンドポイントを通じて発行された証明書は ACM に登録されます。 aws acm list-certificates コマンドを使用して、発行されたすべての証明書を確認できます。 IAM による認可、CloudTrail による監査ログとオブザーバビリティ エンドポイントの管理操作は IAM を通じて認可され、CloudTrail に記録されます。IAM ポリシーを使用して、どのプリンシパルがエンドポイントの作成、EAB 認証情報の生成、ドメイン制約の管理を行えるかを制御できます。 ベストプラクティス ACME 証明書を初めて導入するお客様は、組織に合わせて以下のベストプラクティスを検討してください。 組織や環境の境界に合わせてエンドポイントを分割する エンドポイントは、大規模な組織にとって有用な分離の手段として機能します。大企業は、全社で 1 つのエンドポイントを共有するのではなく、組織の境界 (事業部門、子会社、環境) ごとに 1 つのエンドポイントを作成できます。各エンドポイントは独自の事前承認済みドメインと独自の EAB セットを持つため、ある事業部門で認証情報が侵害されても、それを使って別の事業部門の証明書を取得することはできません。 ただし、この分割方針は運用上のオーバーヘッドとのバランスも考慮して判断してください。妥当な出発点は、事業部門内で環境 (開発、ステージング、本番) ごとに 1 つのエンドポイントを作成し、コンプライアンスや組織上の要件がある場合にのみ、事業部門ごとのエンドポイントへ拡張することです。 EAB 認証情報を安全に管理する エンドポイントの有効な KeyId と MacKey を持っている人は誰でも、そのエンドポイントで事前承認済みの任意のドメインの証明書を取得できます。そのため、これらの認証情報はアクセスキーと同様に取り扱う必要があります。 可能な限り MacKey をハードコーディングせず、 AWS Secrets Manager などのシークレットストアを使用します。エンドポイントの使用を認可した ACME クライアントにのみ配布してください。 EAB の有効期限を許容できるレベルに設定します。EAB は長期間有効な認証情報をサポートしていますが、すべてのシナリオで有効期間が極端に長い EAB が必要なわけではありません。 各 EAB のロールを作成する際は、最小権限の考え方に従います。すべてのバインディングでロールを共有するのではなく、EAB ごとにロールを作成することで、AWS 環境におけるリスクの軽減に役立ちます。 CloudTrail で CreateAcmeExternalAccountBinding コールと GetAcmeExternalAccountBindingCredentials コールを個別に監査します。実際のキーマテリアルの取得は、バインディングの作成とは別の API コールであるため、取得イベントに対するアラートは、バインディング作成のみの場合よりも、実際の認証情報の配布を示す強いシグナルになります。 実行時に EAB をクライアントに関連付ける方法を自動化する 複数の ACME クライアントで 1 つのバインディングを共有するのではなく、クライアントまたは環境ごとに一意の EAB 認証情報を生成してください。複数のエンドポイントへとスケールする段階になったら、運用上の労力を軽減するために、以下のパターンから必要なものを取り入れてください。 各 EAB とそれにバインドされた IAM ロールに、所属するクライアント (チーム、アプリケーション、環境) にちなんだ名前を付けます。これにより、スプレッドシートと照合しなくても、 DescribeAcmeExternalAccountBinding の出力だけでバインディングの用途が明確になります。 各クライアントの KeyId と MacKey を、そのクライアントに限定されたシークレットパス (例えば、チームと環境ごとの Secrets Manager のパス) に保存し、クライアントのプロビジョニングパイプラインが自身の認証情報を取得できるようにします。 Kubernetes では、チーム間で 1 つの共有 issuer を使用するのではなく、EAB ごとに 1 つの ClusterIssuer または名前空間スコープの Issuer を使用します。これにより、クライアントと EAB の関連付けがクラスター設定で明示的になり、他のチームに影響を与えずに特定のチームのアクセスを取り消すことができます。 一時的なインフラストラクチャ (ビルドエージェント、オートスケールされるフリート) の場合、一度きりの手動での受け渡しではなく、Infrastructure as Code または継続的インテグレーションおよびデプロイ (CI/CD) パイプラインの一部として EAB 認証情報をプロビジョニングします。これにより、認証情報のライフサイクルがインフラストラクチャのライフサイクルに追従します。 ACME のデプロイをモニタリングする ACME の強みは自動化にあり、組織は ACME の使用状況に異常がないかモニタリングする必要があります。 成功だけでなく、発行の失敗に対してもアラームを設定します。証明書の有効期間が 47 日になると、更新が気付かないうちに失敗した場合に対応できる時間は、有効期間の長い証明書で得られていた数か月の猶予に比べて、はるかに短くなります。 更新の自動化に依存する前にテストします。CA/Browser Forum の短縮された有効期間により、更新失敗が組織の業務を中断させる事態になる前に、非本番のエンドポイントに対して手動更新を強制実行し、クライアント、モニタリング、オンコールのランブックが期待どおりに動作することを確認してください。 提供リージョンと料金 AWS Certificate Manager の ACME サポートは、本日 (2026 年 8 月 6 日) からすべての商用 AWS リージョンで利用可能です。また、AWS GovCloud (US)、中国リージョン、 AWS European Sovereign Cloud の各 パーティション でも後日利用可能になる予定です。ACME の料金の詳細については、「 ACM の料金ページ 」を参照してください。 まとめ 証明書の有効期間の段階的な短縮は、自動化なしに簡単に解決できるものではありません。ACM の ACME サポートは、標準プロトコルと標準ツールを通じてその自動化を提供しながら、セキュリティチームが ACM で頼りにしている可視性とガバナンスのコントロールを維持します。 開始するには、「 AWS Certificate Manager のドキュメント 」を参照するか、「 開始方法ガイド 」に沿って進めてください。 Anthony Harvey Anthony は、AWS のワールドワイド公共部門グループのシニアセキュリティスペシャリストソリューションアーキテクトです。AWS に入社する前は、地方自治体で 5 年間、最高情報セキュリティ責任者を務めていました。公共部門での経験から、少ないリソースでより多くを実現する方法を見出すことに情熱を持ち、その考え方を活かしてお客様のセキュリティの取り組みを支援しています。 Chandan Kundapur Chandan は、AWS Certificate Manager (ACM) チームのプリンシパルプロダクトマネージャーです。15 年以上のサイバーセキュリティの経験を持ち、PKI 製品戦略の推進に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 8 月 18 日に公開された AWS Blog “ Security Hub Extended adds Supply Chain Security as its tenth category ” を翻訳したものです。 今年 2 月以降、AWS は AWS Security Hub Extended を、9 カテゴリにわたる厳選された 14 パートナーから、10 カテゴリ 23 パートナーへと拡大してきました。今月の Black Hat では、そのうち 14 パートナーが Amazon Web Services (AWS) ブースでライブデモを実施しました。4 パートナーがシアタートークを行い、10 パートナーが SecurityLive のストリーミング配信で紹介されました。また、AWS のリーダーシップとパートナー企業の経営陣が一堂に会し、今後の計画を話し合うパートナーレセプションも開催しました。これらの企業は、AWS とともに、そして次第にパートナー同士でも、エンジニアリングと市場開拓 (GTM) に本格的に投資しています。このモデルが、パートナーが日々接しているお客様から支持されているからです。ブースで最も多く寄せられた質問は、サプライチェーンセキュリティはいつ提供されるのか、というものでした。 その提供が始まりました。サプライチェーンセキュリティはカテゴリとして最も多くのお問い合わせをいただいているため、今回はこの話題を中心にお伝えします。 サプライチェーンセキュリティ: お客様が求め続けてきたカテゴリ ソフトウェアサプライチェーンのリスクは、セキュリティチームの懸念事項から、取締役会レベルの議題へと変わりました。SolarWinds の事例は、ビルドシステムが侵害されると何が起きるかを明らかにしました。Log4j の事例は、たった 1 つの推移的依存関係の脆弱性が世界規模で何を引き起こすかを示しました。xz utils のバックドアの事例は、メンテナーを侵害する攻撃が何年もかけて実行される執拗さを浮き彫りにしました。それぞれが同じ問題の異なる側面を示しており、そのペースは加速しています。攻撃者は、企業が知らず知らずのうちに信頼しているオープンソースパッケージこそが、企業への近道であることを知っています。 Black Hat で話をしたすべてのお客様が、この問題をリスク登録簿に載せていました。しかし、その多くはまだ解決策を運用に落とし込めていませんでした。運用化には、個別のデプロイ、新しい契約、新しいコンソール、そしてセキュリティチームが優先順位を上げられない統合作業が必要だったからです。AWS が取り除こうとしているのは、まさにこうした導入の手間です。 Security Hub Extended では、厳選されたパートナーとして Chainguard と Socket によるサプライチェーンセキュリティの提供を開始しました。サプライチェーンセキュリティは、Extended の他のすべてと同じモデルを採用しています。すべてのオファリングが従量制料金で、請求は 1 つにまとまり、長期契約は必須ではありません。これまでどおりの調達プロセスを継続したい企業向けには、Security Hub Extended のプライベートオファーも利用できます。プライベートオファーは、一定期間の利用をコミットする契約で、より大きな割引が適用され、複数パートナーへの支出を単一の AWS 請求に集約でき、契約期間を通じて月払いと年払いのどちらの支払いオプションも選択できます。お客様の購買プロセスに合った方法を選択できます。 Chainguard の役割 Chainguard は、強化・検証されたビルドプロセスでソースから再ビルドしたオープンソースの依存関係を提供します。これにより、お客様の環境に入ってくるものは、マルウェアに強く、来歴 (プロベナンス) に裏付けられたものになります。 同社の調査 によると、ソースからの再ビルドを行っていれば、既知の悪意あるパッケージの 98% が本番環境に到達するのを防げたとされています。ソースを検証できないものは、Chainguard のリポジトリに一切登録されません。これが、パブリックレジストリと開発者の間のフィルターとなります。 Socket の役割 Socket は、オープンソースパッケージの実際の挙動を分析し、インストール時点で悪意ある依存関係をブロックします。数日から数週間後に CVE (Common Vulnerabilities and Exposures) が公開されるのを待つのではありません。パッケージがお客様の環境に入り込もうとしたその瞬間に、Socket はデータベースの情報ではなくパッケージの挙動そのものに基づいて検知します。さらに、到達可能性分析によって、どの脆弱性がお客様のコードから悪用可能かがわかるため、チームがノイズに埋もれることがありません。料金は、チェックする個別のパッケージ数に基づき、ビルドの実行回数には依存しません。 2 社が連携して機能する理由 Chainguard と Socket を組み合わせることで、重要な 2 つの問いに対応できます。 取り込むものを信頼できるか 悪意あるコンポーネントがアプリケーションに組み込まれる前に阻止できるか Chainguard はコードが構築される基盤の保護を支援し、Socket はそこに取り込むパッケージを保護します。両者は、クラウドでもオンプレミスでも、デプロイ先を問わずソフトウェアサプライチェーンの保護に役立ちます。Security Hub Extended を通じて両方を有効化すると、その検出結果は OCSF (Open Cybersecurity Schema Framework) 形式で他のすべての情報とともに Security Hub に流れ込みます。これにより、サプライチェーンのリスクは、エンドポイント、アイデンティティ、クラウドの各シグナルと並べて相関付けられ、優先順位付けされます。そこから、すでに統合済みの下流ツールへとルーティングされるため、開発者が現在使っているパイプラインにそのまま適合します。 23 パートナー、10 カテゴリ。お客様の要望に基づいて構築 Security Hub Extended のすべてのパートナーは、お客様がその機能を必要としていると伝えてくれたこと、そしてその特定のソリューションがすでにお客様のもとで機能していたことを理由に参加しています。脅威の状況が進化するためカテゴリを追加し、それらの問題をうまく解決している企業をお客様が教えてくれるためパートナーを追加しています。目標はシンプルです。すでにお持ちの AWS との取引関係を通じて、同業他社がすでに成果を上げているセキュリティソリューションの導入を簡素化することです。 現在の対象領域は、エンドポイント、アイデンティティ、E メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティオペレーション、そして新たにサプライチェーンに及びます。23 の厳選されたパートナーは、7AI、Britive、Chainguard、CrowdStrike、Cyera、Island、LayerX、Native Security、Noma、Okta、Oligo、Opti、Palo Alto Networks、Proofpoint、SailPoint、SentinelOne、Socket、Splunk、Sublime、Upwind、Varonis、Zenity、Zscaler です。 AWS が現在注力しているのは、統合を深化させ、有効化にかかる手間を減らすことで、これらのソリューションが個別にではなく連携して機能するようにすることです。そこにこそ、価値が相乗的に高まっていきます。 今後の取り組み ここまで説明してきたことはすべて、販売モデルが機能していることの表れです。つまり、お客様が期待どおりの柔軟性のもとで、AWS との単一の取引関係を通じてベストオブブリードのセキュリティを購入しているということです。しかし、より大きなビジョンは、これらのツールを単に購入しやすくするだけでなく、組み合わせて使うことで実際に効果が高まる統合レイヤーです。 最も注力している統合は、クロスパートナーの相関付けです。エンドポイントソリューション、アイデンティティソリューション、クラウドソリューションからのシグナルを、相互に関連付けられていない 3 つのアラートではなく、1 つのエクスポージャーと 1 つの攻撃パスにまとめます。これと並行して、有効化、デプロイ、統合にかかる手間を大幅に減らし、お客様がサブスクライブしてから価値を実感するまでの時間を数週間ではなく数時間にすることに取り組んでいます。この 2 つの取り組みにより、お客様がすでに信頼している厳選されたソリューションは、個別に使うよりも連携させることで、より大きな成果をもたらします。 これが、AWS がパートナーとともに今まさに加速している取り組みです。re:Invent に向けて、さらに詳しい情報をお届けする予定です。 利用できるオファリングを確認する 本番環境でオープンソースソフトウェアを運用していて、まだサプライチェーンの可視性を確保できていない場合は、そこから始めてください。今すぐ Security Hub コンソールから Chainguard と Socket を有効化できます。複数のセキュリティベンダーとの関係を管理していて、Security Hub Extended による統合がどのようなものかを知りたい場合は、AWS アカウントチームにご相談ください。すべてのパートナーの料金は 料金ページ に公開されており、営業担当への問い合わせは不要です。また、すでにセキュリティ態勢管理と脅威検出に Security Hub を使用している場合、Extended プランは現在お使いのコンソールでそのまま利用できます。 これはまだ始まりにすぎません。 Michael Fuller Michael は AWS に 16 年間在籍し、11 年にわたって AWS セキュリティサービスのプロダクトを率いてきました。業界歴は 29 年で、IBM、Cisco、Amazon においてプロダクトマネジメント、事業開発、ソフトウェア開発のさまざまな役職を歴任してきました。アリゾナ大学でコンピュータ工学の理学士号を、ワシントン大学で MBA を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

物流業界では、貿易関連書類の作成・照合作業に多大な時間を要しています。情報を入手した後にシステムへ取り込み、別の書類を作成するといった煩雑な作業が日常的に発生し、さらに間違いがないかを一つ一つ確認する必要があります。深刻な人手不足が進む中、こうした業務を効率化しつつ品質を維持することは、物流事業者にとって喫緊の課題です。 本ブログでは、1938年の創業以来グローバルな国際物流を手掛けてきた株式会社日新（以下、日新）が、AWS 上で構築した「オプティマAI」プラットフォームについてご紹介します。オプティマAI は「人とAIの協働」をコンセプトに、物流業務における判断支援と業務効率化を実現するソリューションです。 以下は 2026年6月に開催された AWS Summit Japan 2026 での日新ブース展示内容をもとに記載しています。 日新について 日新は「サプライチェーン ロジスティクス プロバイダー」として、陸海空すべての輸送手段や倉庫・保管業務を組み合わせ、世界各地にワンストップの物流サービスを提供しています。「世界の人々に感動を運び、地球を笑顔で満たす」というパーパスのもと、国際輸送、国内輸送、倉庫・保管、引越、展示会輸送など幅広い事業を展開し、グローバルネットワークを活かした物流ソリューションを提供しています。 オプティマAI の全体像 オプティマAI は、物流業務における「人とAIの協働」を実現するプラットフォームです。AI が最適な判断を支援し、AI が可能な処理は AI が担当し、さらに AI 同士がコミュニケーションを行う ── その上で人が最終判断を行うという、人間中心のAI活用を目指しています。 最終的なビジョンとして、顧客側のAIと日新側のAIが API や MCP（Model Context Protocol）を介して連携し、サプライチェーン全体を横断した業務最適化を実現する構想です。発注支援・適正在庫予測、スケジュール予測、通関支援、倉庫・輸送効率化、見積り・書類チェック、混載効率化といった機能を、顧客と日新が共有ダッシュボード上で一元管理し、AIの作業進捗を確認しながら人間が最終判断を行います。さらに、顧客のSCMや物流を支援するアプリを、オプティマAI上でアジャイル共同開発することで、個社の要件にも柔軟に対応します。 図1: オプティマAI 全体イメージ オプティマAI は AWS 上に構築されています。Amazon Bedrock による生成AI・RAG 機能、Amazon OpenSearch Service による高速検索、AWS Lambda によるイベント駆動処理など、マネージドサービスを組み合わせることで、インフラ運用の負荷を最小化しながらAI機能の迅速な開発・拡張を可能にしています。サーバーレスアーキテクチャの採用により、スモールスタートから段階的にスケールアウトできる点も、物流DXの段階的推進にとって大きな利点です。 オプティマAI は以下の機能群で構成されています。 オプティマHS（税番採番AI） ：HS コード分類業務を AI が支援 オプティマAI-OCR（貿易書類AI） ：貿易書類の照合・チェック業務を AI が支援 オプティマ分析予測 / オプティマGATE ：物流特化型の分析・予測AI（開発中） 以降では、現在実用化が進んでいるオプティマHS とオプティマAI-OCR について詳しくご紹介します。 オプティマHS：税番採番AI HS コード分類はなぜ難しいのか 物流における通関業務では、輸出入品に対して適切な HS コード（税番）を判定する必要があります。HS コードは国際条約に基づく品目分類番号で、関税率の決定や貿易統計に利用される極めて重要なものです。 しかし、HS コード分類は非常に難易度の高い作業です。HS 品目表には「部分品」や「附属品」の明確な定義がほとんどなく、同じ部品でも材料や形状、用途によって分類先が変わります。機械類は複数の部分品から構成され、その部分品がさらに別の部分品で構成されるという多層構造を持ち、さらに一つの部品が複数の機械に共通して使われることも珍しくありません。加えて、品目表の通則や部注・類注の除外規定など多層的なルールを正しく適用する必要があり、担当者には深い専門知識と経験が求められます。 こうした難しさから、HS コード分類は長年にわたりベテラン担当者の知識に依存してきました。人手不足が深刻化する物流業界において、この属人的な業務をいかに効率化し品質を維持するかが大きな課題です。 オプティマHS による AI 支援 オプティマHS は、この税番判定作業を AI が支援するシステムです。具体的には以下の流れで動作します： RAG（検索拡張生成）による知識活用 ：実行関税率表、輸出統計品目表、社内規程・ルール、社内ノウハウを検索し、関連情報を取得 過去実績による類推 ：類似の製品情報に対する過去の判定実績から税番候補を類推 画像・WEB チェック ：製品画像やウェブ情報も参照して判断の精度を向上 税番候補と根拠の提示 ：AI が税番候補を根拠とともに提示し、担当者の判断を支援 図2: オプティマHS（税番採番AI）の処理フロー 重要なのは、AIが最終判断を下すのではなく、あくまで「人が最終判断」を行う設計になっている点です。AIは候補と判断材料を提示し、専門知識を持つ担当者がそれを確認して最終決定を行います。 今後は、荷主様からの質問回答や商品マスター・カタログ等の情報も取り込み、さらに精度の高い支援を実現する予定です。 AWS の活用ポイント ：オプティマHS では、 Amazon Bedrock を活用した RAG アーキテクチャにより、実行関税率表や社内ノウハウといった大量の専門知識を効率的に検索・活用しています。また、 Amazon OpenSearch Service による高速なベクトル検索で、過去実績からの類推を高精度かつ低レイテンシで実現しています。これにより、HS コード分類のような専門性の高い業務に対しても、最新の生成AI技術を迅速に適用することが可能になりました。 オプティマAI-OCR：貿易書類AI 貿易業務では、インボイス、パッキングリスト、船荷証券（B/L）、輸出申告書、船積依頼書など、一つの取引に対して多数の書類が発生します。これらの書類はそれぞれ異なるフォーマットで作成され、荷主、船会社、航空会社、通関業者など複数の関係者から異なるタイミングで届きます。担当者は、これらの書類間で品名・数量・金額・重量・仕向地などの情報が一致しているかを一つ一つ目視で照合し、不整合があれば関係者に確認を取る必要があります。書類の枚数が多いほどチェック箇所は掛け算で増え、かつ一つのミスが通関の遅延や追徴課税につながりうるため、正確さと速度の両立が常に求められる業務です。 オプティマAI-OCR は、この書類照合業務を AI が支援するシステムです： AI-OCR によるデジタル化 ：貿易書類（インボイス、輸出申告書、船積依頼書）を AI-OCR でデータ化 AI による書類照合・正誤チェック ：デジタル化された情報を AI が照合し、正誤チェックを実施 リコメンド表示 ：チェック結果と推奨事項を画面に表示し、担当者の作業をサポート 図3: オプティマAI-OCR（貿易書類AI）の処理フロー さらに将来的には、AI エージェントによるドキュメント生成、基幹システムとの連携、上流・下流工程の自動化も視野に入れています。「AI 機能の提供ではなく、日常業務に AI を取り込む」という思想のもと、業務プロセスそのものに AI を組み込んでいます。 AWS の活用ポイント ：AI-OCR のモデル推論には Amazon SageMaker AI を活用し、多様な書類フォーマットに対応したモデルのトレーニングとデプロイを効率的に行っています。デジタル化後の照合ロジックにはAmazon Bedrockの生成AI機能を活用し、書類間の不整合を文脈を考慮して検出します。また、 AWS Lambda によるイベント駆動型のパイプラインにより、書類が取り込まれたタイミングで自動的に処理が開始される仕組みを実現しています。 AWS 上のアーキテクチャと活用メリット オプティマAI は AWS 上に構築されており、主に以下のサービスを活用しています： Amazon Bedrock ：RAG による知識検索と生成AI機能の基盤。税番判定の類推や書類照合のロジックに活用 Amazon OpenSearch Service ：大量の貿易書類データや過去実績のベクトル検索・全文検索に活用 Amazon SageMaker AI ：AI-OCR モデルのトレーニングと推論に活用 AWS Lambda ：イベント駆動型の処理パイプラインを実現 Amazon S3 ：書類データ、学習データ、モデルアーティファクトの保管 Amazon DynamoDB ：過去実績やルール情報の高速アクセス AWS を採用したメリット 1. スモールスタートから段階的に拡張できるアーキテクチャ オプティマAIは2024年の実証実験から開始し、2025年に実用基盤、2026年以降にAI間連携へと段階的に発展させる戦略をとっています。開発プロセスにおいても、業務担当者との密なすり合わせとプロトタイピングによる有用性の確認を繰り返しながら、実際の業務に即した形でAI機能を磨き上げてきました。AWSのサーバーレス・マネージドサービスを活用することで、初期投資を抑えつつ、こうしたアジャイルな開発サイクルを支える柔軟な基盤を実現しています。プロトタイプから本番環境への移行もスムーズに行え、利用量の拡大に応じてシームレスにスケールアウトすることが可能です。 2. 生成AIの迅速な導入と進化への追従 Amazon Bedrock により、最新の基盤モデル（Claude、Amazon Nova 等）をAPIベースで即座に利用できます。モデルの進化に伴い、HS コード分類の精度向上や書類照合の品質改善が期待でき、インフラ側の変更なしに最新モデルへの切り替えが可能です。物流業界のように業務要件が多様で変化し続ける領域において、AI の進化を即座に取り込める柔軟性は大きな競争優位となります。 3. 運用負荷の最小化 マネージドサービスの活用により、サーバーの管理やスケーリング、パッチ適用といったインフラ運用の負荷を AWS に任せることができます。日新の DX 推進チームは、インフラ運用ではなく、物流業務に精通した AI アプリケーションの開発と改善に集中できています。 4. セキュリティとコンプライアンス 貿易書類や通関情報など機密性の高いデータを扱うため、セキュリティは最重要要件です。AWSのセキュリティ機能（VPCによるネットワーク分離、IAMによる細粒度なアクセス制御、暗号化機能など）により、エンタープライズレベルのセキュリティを確保しています。 「人とAIの協働」という設計思想 オプティマAI の最大の特徴は、「AI が人に取って代わる」のではなく「人と AI が協働する」という設計思想にあります。 物流業務、特に通関や貿易書類処理は、法規制への準拠や例外処理が頻繁に発生する領域です。こうした業務では AI が100%の精度で自動化することは現実的ではなく、むしろ AI が候補案と根拠を提示し、人間の専門家が最終判断を行うハイブリッド型のアプローチが有効です。 このアプローチにより、以下の効果が期待されます： 生産性の向上 ：担当者が煩雑な調査・照合作業から解放され、より高度な判断業務に専念できる 品質の維持・向上 ：AI による一貫したチェックにより、ヒューマンエラーを低減 ノウハウの継承 ：ベテラン担当者の暗黙知を AI に学習させることで、組織知として保存・活用 まとめ 本ブログでは、日新のオプティマAI プラットフォームを通じて、物流業界における AI 活用の実践例をご紹介しました。 「人とAIの協働」をコンセプトに、税番採番AI（オプティマHS）、貿易書類AI（オプティマAI-OCR）、物流特化AI（オプティマ分析予測・GATE）を実用化し、さらにAI同士が仕事を進める次世代プラットフォームへと段階的に発展させる戦略は、物流DXを推進する上で示唆に富むアプローチです。 AWS のマネージドサービスを活用することで、スモールスタートから始めて段階的に拡張し、生成AIの進化を即座に取り込みながら、運用負荷を最小限に抑える ── この構成は、物流業界のように多様な業務プロセスを持つ企業がAIを本格活用する際の効果的なパターンと言えるでしょう。 今後、AI エージェント間の連携や MCP の活用により、顧客と日新のシステムがより密接に連携し、サプライチェーン全体の最適化が進むことが期待されます。

本記事は 2026 年 8 月 18 日 に公開された「 Fresher insights, faster decisions: talabat’s near-real-time analytics across AWS and Google Cloud 」を翻訳したものです。 talabat は、中東・北アフリカ (MENA) 地域をリードする日常生活アプリです。レストランや小売店の幅広い選択肢から、食品、食料品、その他の日用品を手軽に注文でき、パーソナライズされた体験を提供しています。2004 年にクウェートで創業した talabat は、アラブ首長国連邦、オマーン、カタール、バーレーン、ヨルダン、イラク、エジプトに事業を拡大し、2025 年 12 月時点で月間アクティブユーザー 700 万人以上にサービスを提供しています。本社はアラブ首長国連邦のドバイにあり、2024 年 12 月にはドバイ金融市場 (DFM) で新規株式公開 (IPO) を完了しました。Delivery Hero SE の子会社として、グローバルな知見を活かしてサービス向上と事業拡大に取り組んでいます。パートナーとライダーのネットワークを通じて、顧客が必要なものを必要なときに届ける、地域全体の日常の利便性を支えています。 本記事では、talabat がハイブリッドなマルチクラウドレイクハウスを構築し、ストリーミングデータの Apache Iceberg コピーを AWS 上に一元的に保持しながら、 Google Cloud Platform (GCP) からガバナンスの効いたニアリアルタイム分析を実現した方法を紹介します。 talabat におけるデータ データは talabat のビジネスの中枢です。顧客が「注文」ボタンを押した瞬間からドアベルが鳴るまで、システムは瞬時にデータドリブンな意思決定を行い、価格設定、配車、ルーティング、注文の不正検知をリアルタイムで最適化しています。長年にわたり、talabat のアプリケーションは 2 つのパブリッククラウドにまたがる環境へと成長しました。トランザクションおよびオペレーション基盤は AWS 上で成熟し、エンジニアリングチームがサービスを構築・運用しています。一方、多数のアナリスト、データサイエンティスト、分析エンジニアリングパイプラインは Google Cloud Platform のウェアハウスである Google BigQuery を標準としています。 どちらへの投資も深く、どちらも価値を生み出しています。戦略的な問いは「どちらのクラウドに統合するか」ではなく「両者の境界をまたいでデータをどうスムーズに流すか」でした。この前提がアーキテクチャ全体を形作っています。課題はクラウド間だけでなくリージョン間にも及びます。AWS サービスは EU リージョンでホストされ、GCP のデータは US リージョンにあります。 次の図は、AWS 上のオペレーションプレーンと GCP 上の分析プレーンの間における talabat のデータフローを示しています。 図 1: AWS 上のオペレーションプレーンと Google Cloud 上の分析プレーン間のデータフロー これまでデータエンジニアリングチームは、2 つのクラウド間のデータ移動をオーケストレーションしており、AWS から GCP へ、EU から US への物理的なデータ移動が必須でした。従来の ETL (抽出、変換、ロード) ツールやフレームワークでの移動は、複数のホップを経てデータの遅延と重複を引き起こしていました。具体的には、 Amazon Relational Database Service (Amazon RDS) から Amazon Simple Storage Service (Amazon S3) EU AWS リージョンへ、Amazon S3 EU から Amazon S3 US リージョンへ、そして最終的に Amazon S3 US から BigQuery US への移動です。 各ホップはコピーであり、コピーのたびにリスクが積み重なりました。障害点の増加、レイテンシーの累積、冗長なコンピューティングとストレージ、型の忠実性、そして最も重要なのはクロスリージョンおよびクロスクラウドのデータ転送料（エグレスコスト）です。 要するに、従来の設計は自ら作り出した問題、すなわち BigQuery がデータを読めるようにデータを移動するという問題の解決に、コスト、レイテンシー、信頼性の代償を払っていました。典型的なデータウェアハウスのボトルネックです。代わりにオープンデータレイクを使えないか？使えます。しかし分析の利用は BigQuery に集中しており、オープンソースのデータレイク層を通じたアクセスが制限されています。そこで再設計は逆の前提から始めました。AWS にコピーを 1 つ保持し、BigQuery にそのままの場所で読み取らせる。本記事の残りで説明するのは、この talabat のレイクハウスです。 課題 オペレーションシステムは、注文ライフサイクルの変更、ベンダー、メニュー、ロジスティクスやライダーのシグナル、決済情報といったビジネスイベントを継続的にストリームとして発行し、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 上の Apache Kafka にパブリッシュしています。これらのイベントは Protocol Buffers でエンコードされ、 Confluent Schema Registry に登録された後方互換スキーマで管理されているため、プロデューサーとコンシューマーが安全に進化できます。 分析側の要件は、簡単に述べられるものの実現は困難です。イベントを正しい型で、生成から数分以内にクエリ可能にし、各チームが既に使っているツールからクエリできるようにすることです。 2 つのクラウドを持つことを技術的負債と見なしがちですが、talabat のようなリアルタイムビジネスにとっては単に地形であり、それぞれの側に本来の強みがあります。 イベント基盤は AWS 上にある。トランザクションおよびストリーミングシステムが Amazon MSK にパブリッシュしている。これらのイベントを最も低レイテンシーかつ低リスクに参照・処理できるのは、同じ AWS リージョン内、イベント基盤のすぐ隣です。 分析基盤は Google Cloud 上にある。何千もの下流のモデルやダッシュボード、そしてそれらを構築する人々が、BigQuery をクエリサーフェスとして前提としています。 どちらか一方に統合するには数年規模のマイグレーションが必要であり、片方のユーザーグループにとっては大幅な機能後退を意味します。単にインジェストと分析の間の継ぎ目を取り除くためだけに。データエンジニアは、その継ぎ目を排除するのではなく設計することに決めました。設計目標は一文にまとまります。データの物理コピーを AWS に 1 つ保持し、両方のクラウドからネイティブに読み取れるようにする。ハイブリッドデータレイクハウスにより、「どちらのクラウドか」という問いはアーキテクチャ上の分岐ではなくアクセスパスの選択肢になります。 最初に試したこと: ホットパス上のクロスクラウド書き込み 最初の試みでは、最終的に採用したフローとは逆のアプローチを取りました。Raw (Bronze とも呼ばれる) レイヤーのデータを AWS から直接 Google Cloud Storage 上の BigQuery マネージド Iceberg テーブルに書き込みました。理論上、最大の参照者基盤に最も近い場所にデータが配置されます。しかし実際には、常時稼働のストリーミングパスでクラウドをまたいで書き込むことで、長期的に許容できない問題が生じました。 インジェストパスにおけるクロスクラウド依存。マイクロバッチのたびに、リモートクラウドの書き込み API の可用性とレイテンシーに結合していました。 ストリーミング書き込み API の障害がインジェスト障害として顕在化。リモート書き込みが脆弱なリンクとなり、読み取り側の問題が書き込み側の障害に転化しました。障害を吸収する場所としては最悪です。 プレビュー段階の機能が物理レイアウトを制約。特定のパーティショニング動作や機能が一般提供されておらず、コストとパフォーマンスのためのデータ編成が制限されていました。 教訓は明確でした。書き込みパスはシフトレフトすべきです。書き込みパスは短く、ローカルで、シンプルであるべきです。クロスクラウドの課題は読み取りパスに属し、読み取り専用、キャッシュ可能、リトライ可能であり、インジェストに影響しません。この再構成が、現在稼働しているアーキテクチャに直結しました。 BigQuery が AWS 上のデータを読み取る方法の選択 フローを反転させ (Raw データは AWS 上、読み取りは Google Cloud から)、BigQuery が物理的に AWS 上にあるテーブルを読み取る 3 つの方法を評価しました。4 つの基準に照らして評価しました。 データ移動なし。 オープンテーブルフォーマット。 ガバナンス可能な信頼モデル。 最小限の運用面。 アプローチ 評価 Google Cloud Storage へのクロスクラウド書き込み Bronze を Google Cloud Storage 上の BigQuery マネージド Iceberg に書き込み続ける方法。前述の理由で却下しました。インジェストのホットパスにクロスクラウド依存とクロスリージョンレイテンシーが生じるためです。 BigQuery Omni BigQuery Omni のマネージドなクロスクラウドコンピュートを通じて AWS 上のデータをクエリする方法。読み取り専用の Bronze レイヤーに対して必要以上のマネージド面と制約が生じ、カタログと信頼モデルを直接制御したかったため不採用としました。 Lakehouse フェデレーテッド Apache Iceberg REST カタログ (IAM 認証) BigQuery が Amazon S3 Tables (マネージド Apache Iceberg テーブルを提供する Amazon S3 の機能) 内のデータを、AWS Glue Data Catalog のメタデータを同期するフェデレーテッドカタログを通じて読み取る方法。アクセスはクロスクラウド IAM 信頼で認証されます。4 つの基準をすべて満たしたため、この方法を選択しました。 決め手となったのは、Raw データが AWS から出ないこと、フォーマットがオープンな Apache Iceberg であること ( Amazon Athena 、Spark、Iceberg 互換エンジンが同じテーブルを読める)、そしてクロスクラウドの関係が定期的なコピージョブではなくアイデンティティと信頼として表現されることです。 Amazon S3 Tables を選んだ理由 AWS 上に単一の Iceberg コピーを保持するアーキテクチャが決まった後、スケーラブルな Iceberg に特化したストレージレイヤーが必要でした。Amazon S3 Tables は運用面を追加せずに要件を満たしました。テーブルメンテナンス (コンパクション、スナップショット期限切れ、未参照ファイル削除) はサービスマネージドポリシーとして自動実行され、テーブル数に比例して増える外部オーケストレーションジョブが不要です。同様に重要な点として、各テーブルが Amazon Resource Name (ARN) でアドレス指定可能なリソースです。IAM ポリシーで個別テーブルへのアクセスを許可・拒否でき、他の AWS リソースに適用するのと同じ最小権限モデルが使えます。また、 AWS CloudTrail がすべてのアクセス判定を記録します。信頼境界が IAM のみで表現されるクロスクラウド設計では、テーブルがファーストクラスの IAM リソースであることは利便性ではなく前提条件です。S3 Tables により、マネージド Iceberg ハウスキーピングときめ細かく監査可能なアクセス制御が単一の構成で実現し、エンジニアリングチームはストレージ層の実装ではなくストリーミングロジックに集中できました。 ソリューション概要 システムは、オープンテーブルフォーマットで接続される 2 つの部分で構成されています。 AWS 上の短くローカルな書き込みパス。 BigQuery がデータを参照できるようにする読み取り専用のクロスクラウドハンドシェイク。 唯一の信頼できるソース (Single Source of Truth) は、Amazon S3 Tables 内の Apache Iceberg データです。すべてのコンシューマーがこの 1 つの物理コピーを読み取ります。 次の図は、イベントインジェストからストレージ、参照経路までのエンドツーエンドアーキテクチャを示しています。 図 2: イベントインジェストからストレージ、参照経路までのエンドツーエンドアーキテクチャ 書き込みパス: 短く、ローカルで、信頼性が高い Kafka トピックごとに 1 つの Amazon EMR Serverless Spark Structured Streaming ジョブ (プリベイクされた Docker イメージ、ARM64/Graviton 上の emr-7.13.0 ) を、Amazon MSK と同じ AWS リージョン (eu-west-2) で実行しています。コンピュートをイベント基盤と同じ場所に配置することで、マイクロバッチあたりのデータ転送量を最小化し、コストとレイテンシーを削減しています。各ジョブは Spark の foreachBatch オペレーションをトリガー間隔約 1〜5 分、at-least-once デリバリーで実行します。各マイクロバッチは 5 つのステップを実行します。 Kafka から コンシューム する。 登録済みスキーマを使用して Protocol Buffers を デコード する。 ターゲットの Iceberg スキーマに 変換 する。 Amazon S3 Tables 内の Iceberg テーブルに 追記 する。 オフセットを コミット する。 このサイクルが中断なく繰り返されます。 このパスは AWS のみで完結します。クロスクラウド依存はなく、意図的なクロスリージョンホップが 1 つだけあります。コンピュートは欧州 (ロンドン) リージョン (eu-west-2)、ストレージは米国東部 (バージニア北部) リージョン (us-east-1) です。標準の AWS リージョン間データ転送コストが発生しますが、これは BigQuery からのクロスクラウド読み取りが同一リージョン内に収まるようにするための意図的な選択です。 不正レコードはストリームをブロックしません。専用のデッドレターキュー (DLQ) テーブル ( <table>_dlq ) が別の S3 Tables バケットに配置され、生のペイロード ( raw_value_b64 ) と skip_reason が保存されます。暗黙のドロップは発生しません。DLQ テーブルは Lakehouse を通じて AWS Glue Data Catalog に登録されているため、エンジニアは Amazon Athena または BigQuery から障害を検査できます。 この時点から、Amazon S3 Tables が信頼できるソースとなります。 核心: クロスクラウドハンドシェイク ここが設計の中核です。BigQuery は Lakehouse フェデレーテッド Apache Iceberg REST カタログ を通じて S3 Tables の Iceberg データを読み取ります。Google Cloud 側の読み取り専用カタログが AWS 上のテーブルを参照する仕組みです。3 つのメカニズムで実現しています。 オープンなカタログ契約 (Iceberg REST) 。 Amazon S3 Tables は Apache Iceberg REST カタログ インターフェースを公開し、 Google Lakehouse も同じ標準を使用します。双方が Iceberg のオンディスクフォーマットと REST カタログプロトコルに合意しているため、変換レイヤーもデータコピーも不要です。BigQuery は Athena や Spark が読み取るのと同一の Iceberg データファイルを読み取ります。 Google Cloud 側では単一の Lakehouse フェデレーテッドカタログ です。アナリストにはテーブルが talabat-data.s3tables-glue.catalog.orders として表示されます。 クロスクラウドのアイデンティティと信頼 (IAM と OIDC) 。 Lakehouse カタログは、Google マネージドのサービス ID (Lakehouse REST カタログサービスアカウント) として AWS に認証します。 AWS Identity and Access Management (IAM) ロールが accounts.google.com との OpenID Connect (OIDC) フェデレーションを通じてこのサービス ID を信頼し、 sts:AssumeRoleWithWebIdentity でサービスアカウントの数値 ID をロールの信頼ポリシーにピン留めしています。S3 Tables Iceberg エンドポイントへのリクエストは SigV4 署名されます。他の AWS SDK が使用するのと同じ AWS リクエスト署名スキームで、S3 Tables サービスにスコープされています。つまり、ハンドシェイクはプロプライエタリなコネクターではなく、信頼された外部 ID が実行する標準の AWS リクエスト署名です。 信頼は AWS 側で Infrastructure as Code (IaC) としてコード化されており、最小権限が付与され、いつでも取り消し可能です。次の図は認証シーケンスを示しています。 図 3: Lakehouse カタログと AWS IAM 間のクロスクラウド認証シーケンス この信頼関係のステップバイステップのウォークスルー (IAM ロールの作成、トークンのオーディエンスとサブジェクトの検証、信頼ポリシーへの Lakehouse サービスアカウント ID のピン留め) については、 Create and manage AWS Glue federated datasets および Set up cross-cloud Lakehouse for AWS Glue を参照してください。 メタデータ同期 (約 5 分間隔のリフレッシュ) 。 フェデレーテッドカタログは、S3 Tables のフロントとなる AWS Glue Data Catalog からテーブルメタデータを定期的に同期します。新しく作成されたテーブルや新データは、短いリフレッシュサイクル (約 300 秒) で BigQuery から参照可能になります。読み取りはライブの Iceberg データに対して行われ、同期されるのはカタログポインターのみです。 結果として、AWS 上で一度書き込まれたテーブルは BigQuery で通常のカタログオブジェクトとして表示され、標準 SQL でクエリできます。一方で、バイトは AWS から出ず、フォーマットはオープンなままです。 Infrastructure as Code: クロスクラウド信頼面 以下のセクションでは、アーキテクチャ図に示した認証ハンドシェイクを説明します。Lakehouse カタログサービスアカウントが Google OIDC JSON Web Token (JWT) を提示し、AWS が IAM OIDC プロバイダーを通じて検証し、読み取り専用の S3 Tables アクセスにスコープされた短期間の認証情報を返します。 Google を信頼された ID プロバイダーとして登録する。Lakehouse カタログのサービスアカウントにスコープされます。 resource "aws_iam_openid_connect_provider" "google" { url = "https://accounts.google.com" client_id_list = [var.lakehouse_sa_audience] #Lakehouse REST-catalog serviceaccount } 信頼を特定の ID に限定する。ここがセキュリティの核心です。ロールは、サブジェクトがサービスアカウントに一致する Google 署名トークンを通じてのみ引き受け可能です。sub クレームの条件が他のすべてのプリンシパルを排除します。 data "aws_iam_policy_document" "trust" { statement { actions = ["sts:AssumeRoleWithWebIdentity"] principals { type = "Federated" identifiers = [aws_iam_openid_connect_provider.google.arn] } condition { test = "StringEquals" variable = "accounts.google.com:sub" values = [var.lakehouse_sa_subject_id] # nobody else can assume the role } } } resource "aws_iam_role" "lakehouse_read" { name = "bq-lakehouse-read" assume_role_policy = data.aws_iam_policy_document.trust.json max_session_duration = 43200 # 12-hour sessions, then re-issued } 読み取り専用の最小権限を付与する。引き受けたロールには、AWS Glue を通じたカタログメタデータの読み取りと S3 Tables を通じた Iceberg データへのアクセスに必要な権限のみが含まれ、IAM ポリシーで保護され、書き込み可能なものはありません。 statement { actions = [ "glue:Get*", "s3tables:GetTable", "s3tables:GetTableData", "s3tables:ListTables", "s3tables:ListTableBuckets", "s3tables:GetTableMetadataLocation", "s3tables:ListNamespaces", "s3tables:GetNamespace","s3tables:GetTableBucket" ] resources = [var.s3tables_bucket_arn, "${var.s3tables_bucket_arn}/*"] } Google 側のカタログをこのロールに紐付ける。Lakehouse フェデレーテッドカタログ自体はパイプラインとは別に事前作成 (一回限りの gcloud コマンド) され、前述のロールに紐づけられるため、すべての読み取りが信頼された ID を提示します。AWS キーが Google Cloud に存在することはありません。 gcloud iceberg catalogs create s3tables-glue \ --federated-catalog-type=GLUE --glue-aws-region=us-east-1 \ --glue-aws-role-arn=arn:aws:iam::<account>:role/bq-lakehouse-read これら 4 つのステップがハンドシェイクの全体像です。信頼された発行者、サービスアカウントのみが引き受けられるロール、最小権限の読み取り許可、そしてそのロールにバインドされたカタログです。 運用上の教訓: メタデータをファーストクラスの関心事として扱う オープンなフェデレーテッドカタログをクラウド間で運用する中で、テーブルメタデータをファーストクラスの運用上の関心事として扱うことの重要性を学びました。具体的には以下を意味します。 スナップショット保持 : Iceberg のスナップショット保持期間を短く設定し、テーブルごとのメタデータをコンパクトに保ち、確実に同期できるようにする。 コンパクション : S3 Tables 組み込みのメンテナンス設定を通じて、テーブルメンテナンス (コンパクションとスナップショット期限切れ) を統一的なサービスマネージドポリシーとして標準化する。 スキーマ進化 : Protobuf スキーマが進化 (後方互換の追加) すると、Spark ジョブが S3 Tables 内の Iceberg スキーマにカラムを追加・削除する。フェデレーテッドカタログは次の同期サイクルで変更を検出し、BigQuery は手動介入なしに変更を反映する。 設定方法さえ分かってしまえば小さく明確な設定項目にすぎませんが、カタログが正常に動作するか、時間とともにずれていくかの分かれ目です。 データ参照はエンジンの選択であり、コピーの選択ではない ソースがライブになった後、同一の Iceberg テーブルに 1 つの物理データセットから 3 つの方法でアクセスできます。 BigQuery ユーザー は標準 SQL でクエリし、Google Cloud ウェアハウスの他のデータと結合できる。 インフラエンジニア はアドホック確認や継続的インテグレーション (CI) バリデーションのために Amazon Athena で同じクエリを実行できる。 データサイエンティスト は BigQuery や Athena を経由せず、Spark で直接テーブルを読み取れる。 夜間エクスポートを待つ必要はなく、3 つの異なるコピーを照合する必要もありません。コピーは 1 つだけです。 パフォーマンスとコストへの影響 定性的なメリットは既に明らかです。 ニアリアルタイム分析のための数分レベルの鮮度を持つ Raw データ。従来アーキテクチャのレイテンシーはデータ量の問題ではなく設計上の制約でした。インジェスト自体は 5 分間隔で実行されていましたが、下流の 1 時間バッチジョブがエンドツーエンドの鮮度を 60〜90 分に制限していました。カタログフェデレーションにより、同じデータが生成から数分以内にクエリ可能になります。イベントの 95% が 5 分以内、レイテンシーに敏感なミッションクリティカルなワークロードでは 100% をカバーするようにパイプラインを調整する選択肢もあります。 S3 Tables に 1 つのストレージコピー、3 つのコンピュートエンジン。BigQuery、Athena、Spark またはその他の Iceberg 互換エンジンが Amazon S3 Tables 内の単一の物理 Iceberg データセットを読み取り、ストレージの重複とコピー同期に伴う照合コストを回避します。 ホットパスでのクロスクラウドエグレスなし。インジェストは AWS 内で完結します。唯一のクロスクラウドトラフィックは読み取り時のメタデータ同期とクエリ読み取りであり、継続的な書き込みストリームではありません。月次の AWS および Google Cloud データ転送料金、オーケストレーションオーバーヘッド、多層 ETL ワークフローコスト、ストレージバックアップ料金の内部比較に基づき、talabat は同等のデータボリュームでデータ移動コストを約 40% 削減しました。比較は継続的レプリケーションパイプラインの削除前後の 2 か月間にわたり、月間数百テラバイトの反復的なクロスリージョンおよびクロスクラウドデータ転送を排除しました。 オープンテーブルフォーマット、ロックインなし。Raw の Bronze データレイヤーが Amazon S3 Tables 内の Apache Iceberg であるため、データは特定のクエリエンジンやクラウドに囲い込まれません。新しいコンシューマーはエクスポートを要求する代わりに、Iceberg 対応のインターフェースで接続するだけです。 ガバナンス可能なクロスクラウドアクセス。クロスクラウドの境界は、常時稼働のデータパイプラインではなく、IAM 信頼関係 (最小権限、監査可能、取り消し可能) で保護されています。BigQuery 内のエンドユーザーアクセス制御は、GCP のネイティブなロールベースアクセス制御 (RBAC) とフェデレーテッドカタログのきめ細かなアクセス制御で別途管理されます。 今後の拡張 今後は、残りの高価値イベントストリームとバッチストアをハイブリッドな単一設定パターンに取り込み、ソースカバレッジを拡大する予定です。エンドツーエンドの鮮度目標とその周辺のオブザーバビリティ (バッチレベルのメトリクス、デッドレター監視、カタログ同期の正常性) を形式化しています。テーブル数が増加してもクロスクラウドカタログが高速かつ信頼性の高い状態を維持できるよう、スナップショット保持とコンパクションの調整を続けます。より広い観点では、Bronze レイヤーを超えた新しいデータセットについても「一度書き込み、任意のエンジンで読み取り」をデフォルトにし、クラウド間の接続基盤としてオープンテーブルフォーマットをさらに活用していく方針です。 まとめ 2 つのクラウドを使うことは、マイグレーションすべき問題として捉えられがちですが、talabat にとっては単に地形です。イベント基盤は AWS が中心であり、分析コミュニティは BigQuery で活動しています。Apache Iceberg を搭載した Amazon S3 Tables を AWS 上の唯一の信頼できるソースとし、クロスクラウド IAM 信頼で保護された Lakehouse フェデレーテッド Iceberg REST カタログを通じて BigQuery に読み取り専用で参照させることで、2 つのクラウドという制約を数分以内にエンジンが読み取れる単一のガバナンスされたデータセットに変えました。書き込みパスは短く、ローカルで、信頼性が高いままです。クロスクラウドの課題は、あるべき場所、すなわち読み取りパスに存在し、データ移動ではなくオープン標準とアイデンティティで表現されています。 これがハンドシェイクです。AWS 上にデータのコピーを 1 つ、オープンなカタログ契約、そしてクラウドの境界を越えてデータを読み取るための署名された、信頼された、取り消し可能なアイデンティティです。 本記事では BigQuery から AWS 上のデータを読み取ることに焦点を当てました。他のシステムから AWS Glue Data Catalog へのカタログフェデレーションを含む、より広範なマルチクラウド Lakehouse パターンについては、 Multi-cloud Lakehouse architecture on AWS for agentic AI を参照してください。 著者について Harish Ramesh Harish は、talabat の Staff Data Engineer です。小売、ヘルスケア、メディア、物流、ホスピタリティ、FMCG など幅広い業種で大規模データプロダクトを構築してきた経験を持ち、talabat でデータプラットフォームの構築と管理に注力しています。 Raghunandana Krishna Murthy Sanur Raghu は、talabat における Data Engineering and Machine Learning Platform の Senior Manager です。データおよび機械学習プラットフォームのアプリケーションとインフラストラクチャを開発するチームのリードを専門としています。 Lakshmi Nair Lakshmi は、AWS の Principal Analytics Specialist Solutions Architect です。業界横断で高度な分析システムの設計を専門とし、クラウドベースのデータプラットフォームの構築、リアルタイムストリーミング、ビッグデータ処理、データガバナンスの確立に注力しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

はじめに 株式会社セガは、家庭用ゲーム機、PC、スマートフォン向けゲームの企画・開発・販売・運営を軸に、各種コンテンツや商品を全世界へ届けています。同社では、比較的新しい技術も積極的に取り入れる文化のもと、複数タイトルで AWS を活用してきました。 本記事では、同社が開発・運用する『ソニックランブル パーティ』のバックエンドに Amazon DynamoDB と Amazon ElastiCache Serverless for Valkey を採用した経緯・技術的な工夫・得られた効果を、開発チームの声を交えて紹介します。 ※本画像は株式会社セガの許諾を得て掲載しています 『ソニックランブル パーティ』は、Dr.エッグマンが作り出したおもちゃの世界で、「ソニック」シリーズの人気キャラクターたちがスリリングな障害物コースや競技アリーナで競い合うマルチプレイパーティーゲームです。スマートフォンと PC のクロスプレイに対応し、2024 年初頭に一部地域でソフトローンチを行い、2025 年 11 月にグローバルローンチを迎えました。 解決したかった課題 グローバルに展開する Games as a Service（GaaS）のバックエンドを、少人数のチームで開発・運用できるようにすること。これが本タイトルの大前提であり、データベース選定でも最優先の要件でした。マネージドサービスを最大限活用し、インフラ運用の負荷を極力排除する方針のもと、データベースには次のような要件がありました。 グローバル規模でスムーズにスケールできること ：需要が読みにくいグローバル展開では、トラフィックの伸びに安定して追従できることが必要でした。Amazon Aurora では、API サーバーを増やすほど、各サーバーが保持するコネクションプールの分だけ DB への接続数が積み上がり、DB の接続数の上限が API サーバーのスケールの制約になりやすい構造がありました。 リソースのサイジング・管理からの解放 ：ストレージ容量・CPU 性能のサイジングや、ユーザー分割（シャーディング）に伴う複数クラスターの運用といった、リソースを自分たちで管理し続ける作業そのものをなくし、キャパシティを気にせず開発に集中したいという要望がありました。 データ量が増えても安定したレイテンシー ：数千万人規模のデータを持っても、応答性能（レイテンシー）が変わらないことが求められました。 稼働の波・スパイクへの対応 ：ローンチ時のトラフィックが読みにくく、また「最初は大きく構え、後から縮小できるようにしておきたい」というゲーム業界特有の事情に、無駄なく追従できることが重要でした。 なぜ DynamoDB / ElastiCache Serverless for Valkey を選んだのか DynamoDB 採用の決め手 複数のデータベース／クラウドサービスを比較検討したうえで、DynamoDB を採用しました。前述の課題を踏まえ、次の点が決め手となりました。 サーバーレスで、実質無制限のスケーラビリティを持つこと メンテナンスウィンドウやバージョン管理を意識せず、運用し続けられること 接続数・ストレージ・CPU といったリソース管理から解放されること ElastiCache Serverless for Valkey 採用の決め手 メインデータベースである DynamoDB への読み取り負荷を抑え、レイテンシーとコストを最適化するために、インメモリのキャッシュ／データストアとして ElastiCache を採用しました。ElastiCache は当初 Redis OSS エンジンのノードベース構成で構築を開始し、その後 Redis OSS 互換の Valkey エンジンによる Serverless 構成へ移行しました。Serverless を選んだ決め手は次の点です。 ノードベースのクラスターモードで必要だったシャードやクラスターの構成・管理から解放され、少人数チームでも運用できること 「立ち上げ時は大きく構え、ローンチ後は規模に合わせて縮小・最適化していく」というゲーム特有の需要変動にキャパシティが自動で追従し、過剰なリソースを抱えずに済むこと 冗長化構成を自分たちで設計・管理しなくても、高可用性が標準で備わること アーキテクチャ概要 主要なコンポーネントと役割は次の通りです。 Amazon DynamoDB（メインデータベース） ：主要なゲームデータを格納する永続データストア。ユーザーデータ（プロフィール・所持アイテム・進行状況等）とログデータ（行動ログ）を、基本的にシングルテーブル設計で管理しています。 Amazon ElastiCache Serverless for Valkey（キャッシュ／リーダーボード） ：ユーザーデータのキャッシュ、マッチメイキング処理の作業データ、リーダーボード（Sorted Set）などに利用。用途別に汎用の Common とリーダーボード専用の Ranking の 2 つに分けています。 Amazon ECS on EC2（API サーバー） ：API・マッチメイク・行動ログ集計加工の各アプリを配置しています。 Amazon EKS Auto Mode + Agones ：専用ゲームサーバーを管理しています。なおこちらの詳細は別記事 「株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon EKS Auto Mode × Agones 活用事例」 にてご紹介しています。 技術的に工夫した点 1. シングルテーブル設計とキー設計 チームはこれまでリレーショナルデータベース（RDB）の Aurora が中心で、DynamoDB の知見はほぼゼロからのスタートでした。DynamoDB は RDB のように join や任意条件での柔軟なクエリができません。RDB でもインデックス設計は行いますが、DynamoDB では、想定するアクセスパターンに合わせてキーや GSI（グローバルセカンダリインデックス）、データを非正規化してどう持つかまで含めて先に設計する必要があり、アクセスパターンがデータモデルそのものを規定します。本タイトルはユーザーデータ・アカウント・フレンド・ギルド（クルー）・ランキングなどエンティティが多く、かつ各エンティティに複数の検索軸（ユーザー ID・アカウント ID・フレンドコードなど）が必要でした。 そこで、全エンティティを 1 つのテーブルに集約するシングルテーブル設計を採用しました。各アイテムのキーに「エンティティ名」の接頭辞を付けて名前空間を分離し、検索軸は汎用的な GSI をエンティティ横断で使い回す設計としています。 たとえばアカウントデータのキー設計は次のようになっています。 キー 型（命名ルール） 具体例 用途 PK {エンティティ名}#U{ユーザーID} AccountDataEntity#U0001 ユーザー ID で引く（基本アクセス） GSI1 {エンティティ名}#A{アカウントID} AccountDataEntity#A5555 アカウント ID で検索 GSI2 {エンティティ名}#F{フレンドコード} AccountDataEntity#F9999 フレンドコードで検索 GSI3 {エンティティ名}#T{引き継ぎID} AccountDataEntity#T1234 引き継ぎ ID で検索 ※「具体例」は実際の値のイメージです。 参照時は、同じ GSI に対してエンティティ名付きのキーを指定するだけです。たとえば GSI1 は、アカウント検索にもギルド（クルー）検索にも同じ 1 本を使い回します。 例 1：アカウント ID 5555 のアカウントを引く Query (index = Gsi1, P1 = "AccountDataEntity#A5555" ) 例 2：同じ GSI1 で、今度はギルド（クルー）”Dragons” を引く Query (index = Gsi1, P1 = "CrewEntity#Dragons" ) このように、少数の汎用 GSI をエンティティ横断で使い回すことで、インデックスの本数を抑えつつ、多様な検索軸に対応できます。RDB 中心だったチームにとっても、移行そのものは想定より円滑に進みました。一方で、GSI を使いこなせるようになるまでには数か月を要し、負荷試験時に GSI のキャパシティ不足に気づきにくいといった学習コストもありました。 2. トランザクションを使わず楽観ロック中心の設計 コストと性能を考慮し、トランザクションは採用せず、楽観ロック中心の設計としました。実装には、AWS SDK のオブジェクト永続化モデルが備えるバージョン属性による楽観ロックを利用し、必要な場面では SkipVersionCheck（バージョンチェックの無効化）を使い分けられるよう、データアクセス層を設計しています。 一方、ギルド（クルー）機能のように複数ユーザーが同一データを同時に更新する機能では整合性の担保が重要になるため、そうした箇所では Valkey によるロックを用いて競合を防いでいます。 3. リーダーボードのホットキー対策 ランキングは、ElastiCache（Sorted Set）でライブに集計・配信する一方、スコアはユーザーデータとして DynamoDB にも永続化しています。この DynamoDB 側のランキング用 GSI では、同一のランキング（単一のパーティションキー）に多数のプレイヤーの書き込みが集中し、特定のパーティションがホットになりやすいという課題がありました。 そこで、ランキング用 GSI のパーティションキーにユーザー ID の下 4 桁によるシャード分割（P1 = …#Shard{ユーザーID下4桁}）を導入し、書き込みを複数のパーティションに分散しています。ランキング全体の参照時は、集計タスクで各シャードを集約する構成です。 一方、キャッシュ側の ElastiCache Serverless にも同種の考慮が必要でした。ElastiCache Serverless は常にクラスターモードで動作するため、同一スロット制約を踏まえ、マルチキー操作は関連するキーを同一ハッシュスロットに寄せる（ハッシュタグを使う）キー設計が求められます。その分キーが偏る（ホットスロット化）リスクもあるため、トレードオフを意識する必要があります。本タイトルでも、設計当初にこの点を意識しておくとよいという気づきがありました。 4. グローバルローンチの急なトラフィックへの対策 2025 年 11 月のグローバルローンチは、トラフィックが読みにくい最大の山場でした。事前の暖機（ウォームアップ）として、次の対応を行いました。 DynamoDB ：Warm Throughput を利用し、マネジメントコンソールから必要なスループットを引き上げるだけで暖機が完了しました。手動でのプロビジョンドスループット調整（引き上げ後にオンデマンドへ戻す運用）と比べ、手間を大きく削減できました。 ElastiCache Serverless ：ローンチ前に最低 ECPU を設定するだけで事前に暖機できました。ローンチ後は通常運用に戻すのみで、キャパシティ調整の手間は最小限で済みました。 結果として、読みにくい急なスパイクにも問題なく追従できました。 AWS の技術支援 本タイトルの設計・実装にあたっては、AWS の技術支援プログラムである DynamoDB Immersion Day と、DynamoDB DCAD（Database Clinic in A Day）を通じて、数日間にわたる DynamoDB の勉強会・ハンズオンを実施しました。あわせて、Solutions Architect による設計相談・アーキテクチャレビュー・キー設計レビューも行っています。 特に効果が大きかったのは、次の点でした。 勉強会に社内の複数部署が参加したことで、「シングルテーブル設計」について複数の視点から比較・議論でき、設計の方向性を確かめられたこと 「TTL は設定時刻に必ず消えるわけではない」といった実運用上の注意点を事前に把握でき、誤った設計・運用のままサービスインすることを回避できたこと 実運用でのスケールの仕組みを聞けたことで、運用イメージを持てたこと 開発・運用面で得られた効果 開発・運用負荷を軽減し少人数運用を実現 現在、データベースを含むバックエンドを実質 1 名で開発・運用・保守できています。キャパシティ設計が不要なため、少人数でもアプリケーション開発に集中できています。 さらに、パーティショニングやシャーディングが透過的に扱えることで、開発環境と本番環境で構成を変えずに運用できる（dev/prod parity）点も大きなメリットでした。過去のプロジェクトで Aurora を利用していた際は、書き込み負荷を 1 クラスターで捌ききれず、ユーザー単位で複数クラスターにシャーディングしていました。どのクラスターにアクセスするかはアプリケーション側の振り分け（ディスパッチ）処理で制御していましたが、開発環境ではコスト都合で本番と同じクラスター構成を再現できないため、この振り分けを開発と本番で作り分ける必要がありました。一方、DynamoDB のパーティショニングや ElastiCache のシャーディングは透過的に行われ、キャパシティやシャード数の管理も不要です。そのため、アプリケーションはクラスターへの振り分けや分割を一切意識する必要がなく、同じコード・同じテーブル設計・キャッシュ構成が開発から本番までそのまま動作します。サーバーレスのため開発環境をコストのために縮小する必要もなく、本番との構成差が生じないことから、「開発で確認したものが本番でもそのまま通用する」状態になりました。 DynamoDB 移行後は、アラートが来たときを除いてほとんど監視画面を見る必要がなくなり、DB 周りの日常的な運用がほぼなくなりました。Aurora 利用時に気を配っていた、大規模テーブルのパーティション運用や肥大化に伴うパフォーマンス劣化への対処、API サーバーのスケール時のコネクション数（コネクションプール）といった懸念からも解放されています。 性能面の効果 DynamoDB のレイテンシーは、全 DynamoDB API の平均で 10 ミリ秒以下（CloudWatch の DynamoDB レイテンシー値）で安定しています。データ量が増えても応答性能が変わらないため、一貫して低いレイテンシーを維持できています。複雑なクエリを組まない（組む必要のない）設計になっていることも、クエリが重くなりにくい要因の 1 つです。 ElastiCache for Valkey については、従来利用してきた Redis と遜色ない性能を維持できています。頻繁に参照されるユーザーデータやランキングを ElastiCache でキャッシュすることで、低レイテンシーで応答しつつ、DynamoDB への読み取りアクセスも抑えられています。アクティブ・上位ユーザーほど参照頻度が高いため、限られたキャッシュ量でも高いヒット率が得られ、効率よく読み取り負荷を軽減できています。 コスト面の効果 最も実感しているのは、運用・管理まで含めたトータルでのコストメリットです。DynamoDB では、クラスター分割した Aurora での試算と比べて、開発・ステージング・QA 環境あわせて 95%、本番環境で 40〜50% のコストを削減できています。また、インフラの利用料金そのものに加え、これまで DB の運用・管理にかけていたコストまで含めて、負担が大きく下がりました。 ElastiCache Serverless については、開発環境ではノード構成と比べて大幅に低コストで運用できています。本番環境でも、スパイクに備えた過剰なプロビジョニングやリザーブドノードの事前購入が不要になり、負荷が読みにくいなかで容量を先に見込んで確保する必要がなくなりました。 可用性・耐障害性 最初のローンチ以降、無停止で安定稼働しており、サービスに影響するような障害は発生していません。 さいごに 『ソニックランブル パーティ』で得られたこうした成果を踏まえ、DynamoDB と Valkey は今後、部門の標準アーキテクチャとして後続タイトルでも採用していく予定です。なお、ElastiCache for Valkey を Serverless とノードベースのどちらで構成するかは、リザーブドノードの活用可否を踏まえて各プロジェクトで選択できるようにしています。 株式会社セガ 第4オンライン研究開発プログラム部 副部長の上園 政雄氏は、次のように話しています。 「DynamoDB と ElastiCache Serverless for Valkey は、少人数でグローバル展開を支えるうえで欠かせない基盤になりました。今後のタイトルでも標準的なアーキテクチャとして活用していきたいと考えています。」 株式会社セガ 第4オンライン研究開発プログラム部 副部長 上園 政雄 氏

本記事は、株式会社セガとアマゾンウェブサービスジャパンが共同で執筆しています。 はじめに 株式会社セガは、家庭用ゲーム機、PC、スマートフォン向けゲームの企画・開発・販売・運営を軸に、各種コンテンツや商品を全世界へ届けています。同社では、比較的新しい技術も積極的に取り入れる文化のもと、複数タイトルで AWS を活用してきました。 本事例の対象は、同社が開発・運用する『ソニックランブル パーティ』の専用ゲームサーバー基盤です。『ソニックランブル パーティ』は、Dr.エッグマンが作り出したおもちゃの世界で、「ソニック」シリーズの人気キャラクターたちがスリリングな障害物コースや競技アリーナで競い合うマルチプレイパーティーゲームです。スマートフォンとPCのクロスプレイに対応し、2024 年に一部地域でソフトローンチを行い、2025 年 11 月にグローバルローンチを迎えました。 ※本画像は株式会社セガの許諾を得て掲載しています 本記事では、この専用ゲームサーバー基盤で、ゲームサーバーのオーケストレーションに Agones を用い、その基盤に Amazon EKS (Elastic Kubernetes Service) Auto Mode を採用した経緯と効果を、お客様の声を交えて紹介します。 EKS Auto Mode の採用により、開発環境では「ゼロインスタンス運用」によるコスト削減を実現、本番環境ではグローバルローンチ以降、インフラ起因の停止はなく安定稼働を続けています。加えてその運用負荷削減効果により、運用が軌道に乗ってからは API サーバーやデータベースも含めた全環境を 1 名のエンジニアで運用できています。 解決したかった課題 グローバルに展開するマルチプレイヤーゲームの専用ゲームサーバー基盤を、少人数のチームで開発・運用することが、本プロジェクトの大きな前提でした。マネージドサービスを活用する観点では Amazon GameLift Servers も選択肢ですが、選定当時はコンテナに未対応だったことに加え、技術のオープン性も重視した背景から、本プロジェクトでは Agones によるセルフホストを選択しました。Agones はオープンソースの専用ゲームサーバーホスティング製品で、Amazon EKS 上で利用でき、専用ゲームサーバーの構成を簡素化できます。しかし Kubernetes 基盤の運用は避けられず、Agones の運用には次のような負荷が存在します。 ノード管理・Amazon Machine Images (AMI) 更新： ノードのプロビジョニング、AMI のバージョン管理とセキュリティパッチ適用のための更新作業 スケーリング設計： 需要変化に対してノードを迅速にスケールアウト・スケールインさせる仕組みの構築と運用 各種アドオンのバージョン管理： AWS Load Balancer Controller や kube-proxy 等のバージョンアップ対応 かつ本タイトルでは API サーバーに Amazon Elastic Container Service (ECS) を採用しており、Agones のためだけに Kubernetes の運用負荷を抱えるという課題がありました。 なぜ Agones on EKS Auto Mode を選んだのか 上記の課題の解決のため、Agones の基盤に Amazon EKS Auto Mode を採用しました。Amazon EKS Auto Mode は、2024 年 12 月の AWS re:Invent で一般提供が開始された機能で、Kubernetes クラスタのコンピューティング・ストレージ・ネットワーキングの管理を自動化します。Karpenter をベースとしたノード管理、Bottlerocket による最適化された OS、各種アドオンのマネージド管理により、ノード管理・AMI 更新・スケーリング・アドオンのバージョン管理が AWS の責任範囲となり、専用ゲームサーバー基盤の運用をシンプルにできる点が決め手でした。 アーキテクチャ概要 なお、本タイトルのデータベースに関する事例の詳細については、別記事 “ 株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon DynamoDB / Amazon ElastiCache Serverless for Valkey 活用事例 ” にて紹介しています。 安定運用を実現するための設計 専用ゲームサーバーという特性上、EKS Auto Mode の採用における最大の検討事項は、 EKS Auto Mode によるノードの自動中断と、Agones のゲームサーバーライフサイクル管理の競合 でした。 EKS Auto Mode は、コスト最適化のための集約 (Consolidation)、設定変更や AMI 更新への追従 (Drift)、一定期間経過したノードの入れ替え (Expiration) など、様々な理由でノードを自動的に中断します。中断時には対象ノード上の Pod へ終了シグナル (SIGTERM) が発行されるため、対策をしないとプレイ中のゲームサーバーが強制終了されるリスクがありました。専用ゲームサーバーには「プレイ中のゲームセッションを中断させない」という強い制約があるため、この競合の解消が採用の鍵でした。 本プロジェクトでは、AWS の技術支援を受けながら、次の設計パターンを組み合わせてこの課題を解決しました。 猶予期間の設計： ノードが強制削除されるまでの猶予 ( terminationGracePeriod ) と、Pod が終了しきるまでの猶予 ( terminationGracePeriodSeconds ) を、ゲームの最大持続時間より長く設定します。ノード中断が発生してもプレイ中のゲームが終わるまで待ってから安全に停止できます。 シグナルハンドリングの実装： ゲームサーバーアプリが終了シグナルを受け取ったとき、進行中のゲームは終了を待ってから停止し、待機中のサーバーは新規割り当てをブロックして速やかに退去します。 ノード自動最適化の有効化 ( spec.eviction.safe: Always )： Agones のデフォルト設定はノードの退去をすべてブロックし、EKS Auto Mode のコスト最適化やセキュリティパッチ適用を妨げます。この設定を変更することで、上記の猶予期間とシグナルハンドリングでプレイ中のゲームを守りつつ、EKS Auto Mode の自動最適化を活かします。 NodePool の分離： 特性の異なる Agones のコントローラ系とゲームサーバー本体を別々のノードグループ (NodePool) に配置し、それぞれに適した猶予期間等を設定します。 可用性の確保： ゲームサーバーの割り当てを担うコンポーネント (agones-allocator 等) に PodDisruptionBudget (PDB) を設定し、ノード中断時にも機能を維持します。 これらの設計により、EKS Auto Mode の運用自動化のメリットを享受しながら、プレイ中のゲームを守る安定運用を実現しています。各設定の具体的な内容は、別記事 “ Amazon EKS Auto Mode 上で Agones を安定稼働させる設計のポイント “で実装例を交えて解説しています。 導入して得られた効果 コスト：「ゼロインスタンス運用」により開発環境コストを大幅に削減 長期間の開発、目的別に多数の環境を維持する必要性、といった背景から、開発環境のコストは無視できません。本タイトルでは、EKS Auto Mode への移行により実現された Karpenter の高速スケーリングを活かし、開発者がいない時間帯は ゲームサーバーが起動するノードを 0 台にし、マッチメイキング中に起動する「ゼロインスタンス運用」を実現しました。これにより、常時起動が必要ない開発環境の EKS ノードのコストを大幅に削減しました。 運用：日常的な運用作業からの解放 EKS Auto Mode への移行で、ノード管理や AMI 管理といった作業の大部分を任せることができ、EKS の運用設計における考慮事項を大きく減らせたとともに、運用工数も削減できました。例えばセキュリティパッチ適用のための AMI 更新作業では、通常は担当者のアサイン、スケジュール調整、影響確認、適用計画の作成、適用実施と、多くの場合に一週間以上かける作業が、本タイトルではほぼ対応不要と判断できています。またノードプールを yaml で定義・管理できるため、kubectl を中心とした kubernetes 標準の運用フローに統一できました。ノードプールの追加・変更もコードベースで管理できるため、設定変更や構成管理が容易になり、運用性・保守性の向上につながったと感じでいます。グローバルローンチ後は、一定期間 3 名体制で運用整備し、その後はAPI サーバーやデータベースも含めた全環境を 1 名のエンジニアで運用できています。 パフォーマンス：迅速なスケールイン・アウトでリソース利用効率向上 EKS Auto Mode はノードのスケールアウト・スケールインともに応答性が高く、Pod 需要の変化に対してクラスタが迅速に追従できました。その結果、ゲームサーバーがリソース不足で待機する時間を短縮できただけでなく、需要減少時には不要なノードも速やかに解放されるため、リソース利用効率も向上しました。また、本タイトルで独自に実装した Pod AutoScaler とも高い親和性を示し、Pod の需要変化に応じたスケーリング戦略をインフラ側へ迅速に反映でき、ピーク時の応答性と平常時の効率性を高いレベルで両立できています。 可用性：本番環境でもスムーズに移行、グローバルローンチ後も無停止で安定稼働 本タイトルでは、2024 年 12 月の一般提供開始と同時に EKS Auto Mode の検証を開始し、2025 年 1 月に開発環境へ、同年 3 月にはソフトローンチ済みの本番環境への導入が完了と、わずか 4 ヶ月でスムーズな移行を実現できました。2025 年 11 月のグローバルローンチ以降、専用ゲームサーバー基盤は安定稼働しており、インフラ起因のサービス影響のある障害は発生していません。 AWS による支援について EKS Auto Mode と Agones の共存における安定運用のための設計にあたっては、AWS の SA (ソリューションアーキテクト) が支援しました。株式会社セガの担当者は、「EKS Auto Mode 導入時は既に一部地域でソフトローンチ済みで、運用中の環境に手を入れるリスクもありましたが、AWS 社員と直接密にやり取りできる形で随時技術支援をいただきながら進めることができ、対応も早く、安心して進めることができました」と語っています。 今後の展望 EKS Auto Mode と Agones を組み合わせた設計・本番運用は世界的にも先進的な取り組み事例となりました。本アーキテクチャは今後、部門のスタンダードアーキテクチャとして後続タイトルでも主要な選択肢となる見込みです。 まとめ 株式会社セガは『ソニックランブル パーティ』の専用ゲームサーバー基盤で利用する Agones を動作させる基盤として Amazon EKS Auto Mode を採用しました。Agones の柔軟性を活かしつつ EKS Auto Mode で運用管理をシンプルにすることで、グローバル規模のタイトルの少人数チームでの安定運用とコスト最適化を両立しました。 株式会社セガ 第 4 オンライン研究開発プログラム部の穂園氏・松崎氏は、次のように振り返っています。 「以前はノードや AMI の管理、スケーリング設定に常に気を配っていましたが、EKS Auto Mode への移行後は日々の運用からほぼ解放されました。インフラを気にせず開発に向き合えるようになったことが、何よりの変化です。」 著者 穂園 智哉 株式会社セガ 第 4 オンライン研究開発プログラム部 松崎 大 株式会社セガ 第 4 オンライン研究開発プログラム部 西坂 信哉 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト

本記事は 2026 年 8 月 18 日 に公開された「 Characterizing SQL*Net latency in your application for Oracle Database@AWS migrations 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、AWS データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャを利用できるサービスです。ODB@AWS は、Amazon Virtual Private Cloud (Amazon VPC) 内で稼働する Amazon Elastic Compute Cloud (Amazon EC2)、 Amazon Elastic Container Service (Amazon ECS)、 Amazon Elastic Kubernetes Service (Amazon EKS) などの AWS サービスとの間で、低レイテンシーのネットワーク接続を提供します。アプリケーションホストと Exadata 間の SQL*Net トラフィックは ODB Peering を経由し、Amazon VPC と ODB ネットワーク間でプライベートにルーティングされます。 本記事では、データベースとアプリケーションのワークロードを ODB@AWS へ移行する準備を進めるための手法を紹介します。この手法を使うと、オンプレミスのワークロードが SQL*Net レイテンシーに敏感かどうかを評価し、 ODB@AWS のマルチクラウドアーキテクチャ で増える SQL*Net レイテンシーの影響を把握できます。さらに、ODB@AWS の移行候補となるワークロードにおける接続とデプロイの考慮事項も解説します。 ODB@AWS 移行で SQL*Net レイテンシーの評価が重要な理由 ODB@AWS への移行では、ワークロードが SQL*Net レイテンシーの増加に敏感かどうかが重要な検討ポイントになります。極めて短時間 (データベース処理時間がサブミリ秒) で、頻繁 (毎秒数千回の実行) に、かつ少数のセッションに集中して実行される SQL 文を含むワークロードは、SQL*Net ラウンドトリップレイテンシーが数百マイクロ秒増えるだけでも影響を受け、アプリケーションパフォーマンスに直接響く可能性があります。本記事の手法を使えば、アプリケーションのワークロードがこの 3 つの特性を持つかどうかを判断し、該当する場合は移行前に影響を定量化できます。 1 つの原則は常に成り立ちます。クライアントネットワークのレイテンシーが下がってアプリケーションパフォーマンスが悪化することはありませんが、必ず改善するわけでもありません。Oracle は SQL*Net のラウンドトリップを減らすためのガイダンスを何十年も前から公開しています。ストアドプロシージャ、配列フェッチ、バルク処理は、処理をサーバー側に移したりまとめて実行したりすることで、クライアントとサーバー間のラウンドトリップ回数を削減します。Oracle 自身の Net Services ドキュメントにも次の記述があります。 「ネットワークを越えるラウンドトリップの回数を減らすようアプリケーションをチューニングすることが、ネットワークパフォーマンスを改善する最善の方法です。」 ただし、そうした最適化を施しても SQL*Net レイテンシーに強く影響されるモジュールがアプリケーションに残っている場合は、本手法で移行前にレイテンシー感度を特定し、定量化できます。 手法の概要 本手法は Oracle の標準的なパフォーマンスツール (Automatic Workload Repository (AWR)、Active Session History、SQL Trace) を使い、次の 3 つのフェーズで構成されます。 フェーズ 1: AWR スクリーニングで候補となる SQL 文を特定する。 フェーズ 2: フェーズ 1 で挙がった候補の SQL 文を SQL Execution Session Density (SESD) で検証する。 フェーズ 3: SQL Trace と Client Request Elapsed Time (CRET) の分析で SQL*Net レイテンシーへの感度を把握する。 手法の詳細 Client Request Elapsed Time (CRET) とは 本手法は、Oracle のアイドル待機イベントを SQL*Net レイテンシー感度の主要な計測手段に使う新しいアプローチです。対象となるアイドル待機は SQL*Net message from client (SNMFC) です。連続する 2 つの SNMFC 待機に挟まれた区間を、本記事では Client Request Elapsed Time (CRET) イベントと呼びます。 クライアントアプリケーションから SQL*Net 経由でデータベースインスタンスに送られる SQL リクエストは、いずれも次の 3 段階のタイムラインをたどります。 クライアント時間 + クライアントからサーバーへのネットワーク時間: クライアントアプリケーションは前回の結果を処理し (またはアイドル状態のままとなり)、次の SQL リクエストを SQL*Net 経由でデータベースサーバーへ送信します。クライアント時間には、計算処理、ウェブ層とのやり取り、GUI アプリケーションが人間の入力を待つようなアイドル時間が含まれます。この段階の間、データベースセッションはずっと次のリクエストの到着を待つ SNMFC 待機の状態にあります。 データベース処理時間: データベースサーバーがリクエストを受け取り、処理し、応答を準備します。 サーバーからクライアントへのネットワーク時間: データベースサーバーが結果セットまたは完了コードを SQL*Net 経由でクライアントアプリケーションへ送信します。送信直後、データベースセッションは再び SNMFC 待機に入ります。 段階 1 と段階 3 の合計が非データベース時間 (Non-Database Time) です。段階 2 は完全にデータベース内部の処理であり、SQL*Net のクライアントネットワークレイテンシーとは無関係です。 CRET = Database Time + Client Time + SQL*Net RTT 図 1: クライアントリクエストのタイムライン。連続する 2 つの message from client 待機が 1 つの CRET イベントを挟む CRET 手法の紹介 ここからは CRET 手法を、フェーズ 1 (AWR スクリーニング)、フェーズ 2 (SQL Execution Session Density)、フェーズ 3 (SQL Trace と CRET 分析) の 3 つに分けて詳しく見ていきます。 フェーズ 1: AWR スクリーニング (候補となる SQL 文の特定) まず、レイテンシーに敏感と思われるアプリケーション処理が動いていた期間を含む AWR レポートを用意し、ヘッダーに記載された経過時間を確認します。たとえば次の図は、30 分間を対象とした AWR レポートのヘッダーセクションです。 図 2: 30 分間のスナップショット期間を示す AWR レポートのヘッダー スクリーニングの目的は、頻繁かつ短時間で実行される SQL 文、つまり毎秒数千回実行されデータベース処理時間がマイクロ秒レベルの SQL 文を特定することです。SQL Ordered by Executions セクションを開き、上位の各 SQL 文について毎秒あたりの実行回数 (総実行回数 ÷ AWR の経過時間 (秒)) と平均データベース処理時間 (総経過時間 ÷ 実行回数) を計算します。データベース処理時間がサブミリ秒で、かつ毎秒数千回実行されている SQL 文がレイテンシー感度の候補です。処理時間が数ミリ秒に及ぶ SQL 文は、1 回の実行あたりのデータベース処理時間が、増加分のネットワーク時間を大きく上回るため、一般に SQL*Net レイテンシーの増加を許容できます。 フェーズ 1 スクリーニングの例 実際の例を見てみます。360 分 (21,600 秒) を対象とした AWR レポートに SQL Ordered by Executions セクションが含まれています。次のスクリーンショットはそのセクションの上位 5 行で、続く表は各行のフェーズ 1 分析結果です。 図 3: 実行回数の多い上位 5 つの SQL 文を示す AWR の SQL ordered by executions セクション SQL_ID 経過時間 (秒) 実行回数 実行回数/秒 平均 DB 時間 評価 …f243rp 10,966 112,622,398 5,214/秒 97 µs 候補。フェーズ 2 へ進む。 …t4xvug 9,809 97,577,695 4,517/秒 101 µs 候補。フェーズ 2 へ進む。 …r5tj7z 15,302 57,889,149 2,680/秒 264 µs 候補。フェーズ 2 へ進む。 …r8qyvu 13,509 40,966,821 1,897/秒 330 µs 候補。フェーズ 2 へ進む。 …9uyp0z 18,471 24,081,444 1,115/秒 767 µs 候補の可能性あり。DB 処理時間はミリ秒に近づいているが、まだサブミリ秒。フェーズ 2 へ進む。 フェーズ 2: SQL Execution Session Density (SESD) フェーズ 1 では AWR を使い、短時間かつ頻繁に実行される候補の SQL 文を特定します。ただし、SQL Ordered by Executions セクションの実行回数は全セッションを合算したインスタンス全体の集計値です。その実行が 1 セッションによるものか 1,000 セッションによるものかは、AWR からはわかりません。フェーズ 3 に進む前に、候補の SQL 文が 1 つ、あるいはごく少数のセッションから実行されていることを確認します。 考え方はシンプルです。1 回の実行にデータベース処理時間 100µs を要する SQL 文の場合、1 つのセッションが毎秒 10,000 回実行するケースと、100 セッションがそれぞれ毎秒 100 回実行するケースは、AWR 上では区別できません。レイテンシーに敏感なのは前者だけです。少数のセッションに実行が集中している状態は High SESD で、フェーズ 3 の分析対象になります。多数のセッションに実行が分散している状態は Low SESD で、フェーズ 3 は不要です。 SESD は、該当する SQL_ID を実行していたセッションのユニーク数を Active Session History に問い合わせる、 V$SQL の USERS_EXECUTING 列を参照する、あるいはアプリケーションの動作を把握しているアプリケーションオーナーに確認する、といった方法で判断できます。High SESD ならフェーズ 3 の分析に進み、Low SESD なら進みません。 SQL Execution Session Density の詳細 先のフェーズ 1 の AWR に出てきた SQL_ID 52cn24qf243rp は、毎秒 5,214 回実行され、平均データベース処理時間は 97µs でした。SESD を評価した結果、この SQL_ID を実行しているセッションがわずか 5 つだったとします。各セッションは毎秒およそ 1,043 回の実行を担うことになり、CRET サイクル 1 回あたりの実行予算は約 959µs です (1,043 × 959µs = 1,000,000µs = 1 秒)。CRET サイクル時間が 959µs と短いため、SQL*Net レイテンシーの変化が相対的なパフォーマンスに大きく影響しかねません。その影響を評価するのがフェーズ 3 です。この SQL 文はフェーズ 3 の分析に最適な候補と言えます。逆に、同じ毎秒 5,214 回の実行が 200 セッションに分散していれば、各セッションの実行間隔はおよそ 38ms となり、フェーズ 3 の分析は不要です。 フェーズ 3: SQL Trace と CRET 分析 ここまでで、フェーズ 1 のスクリーニングで短時間かつ頻繁に実行される SQL 文を特定し、フェーズ 2 の SESD 分析でその実行がごく少数のセッションに集中していることを確認しました。残る作業は、対象セッションの 1 つをトレースし、CRET イベントの分析で実際のレイテンシー感度を定量化することです。 SQL Trace の有効化 候補の SQL 文を実行中のセッションを特定し、待機イベント付きでトレースを有効にします。 EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => &sid, serial_num => &serial#, waits => TRUE, binds => FALSE); 実行の代表的なサンプルが取得できるよう、十分な時間トレースを継続します。トレースが終わったら無効にします。 EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(session_id => &sid, serial_num => &serial#); CRET パラグラフ: 実例 次の図は、SQL Trace ファイルから抜き出した実際の CRET パラグラフです。連続する 2 つの SNMFC 待機 (赤くハイライトされた部分) がパラグラフを挟んでいます。 図 4: 連続する 2 つの message from client 待機をハイライトした SQL Trace の抜粋 CRET の継続時間は、2 つの SNMFC が示す tim= の差分で、1,297,258,033,879 から 1,297,258,032,801 を引いた 1,078µs です。後ろの SNMFC が示す ela= 値 (947µs) が、この CRET サイクルにおける非データベース時間に相当します。CRET の継続時間から非データベース時間を引くとデータベース時間が求まり、1,078 から 947 を引いた 131µs となります。 CRET 分析ツール 次の 4 つの AWK ワンライナーが CRET 分析ツールを構成します。いずれも処理対象のトレースファイル名を第 1 引数として受け取り、実行には gawk(1) が必要です。ワンライナーは SQL Trace ファイルを直接処理するため、Oracle のクライアントソフトウェアは不要です。4 つのワンライナーが出力する内容は次のとおりです。 ワンライナー 1 — CRET サマリー: 総経過時間、CRET 数、CRET レート (CRET/秒)。 ワンライナー 2 — SNMFC 経過時間のパーセンタイル: 非データベース時間の分布 (Min、P50、P90、P99、Max)。 ワンライナー 3 — CRET 経過時間のパーセンタイル: ラウンドトリップ全体の時間分布 (Min、P50、P90、P99、Max)。 ワンライナー 4 — レイテンシー影響の予測: SQL*Net RTT が 100µs、150µs、200µs 増えた場合の実行時間の増加予測。 ワンライナー 1 — CRET サマリー grep -i 'message from client' $1 | gawk '{p=match($0,/tim=[0-9]+/); t=substr($0,p+4,RLENGTH-4)+0; if(NR==1) s=t; e=t; n++} END{el=(e-s)/1000000; print sprintf("CRET Analysis | Elapsed: %.1f sec (%.2f min) | CRETs: %d | Rate: %.2f/sec", el, el/60, n-1, (n-1)/el)}' ワンライナー 2 — SNMFC 経過時間のパーセンタイル grep -i 'message from client' $1 | gawk '{p=match($0,/ela= *[0-9]+/); v=substr($0,p,RLENGTH); sub(/ela= */,"",v); val=v+0; if(NR==1) mn=val; if(val<mn) mn=val; a[NR]=val} END{n=asort(a); p50=a[int(n*0.5+0.5)];p90=a[int(n*0.9+0.5)];p99=a[int(n*0.99+0.5)]; mx=a[n]; print sprintf("SNMFC Elapsed (us): Min: %d | P50: %d | P90: %d | P99: %d | Max: %d", mn, p50, p90, p99, mx)}' ワンライナー 3 — CRET 経過時間のパーセンタイル grep -i 'message from client' $1 | gawk '{p=match($0,/tim=[0-9]+/); t=substr($0,p+4,RLENGTH-4)+0; if(NR>1){d=t-prev; if(NR==2) mn=d; if(d<mn) mn=d; c[NR-1]=d} prev=t} END{n=asort(c);p50=c[int(n*0.5+0.5)]; p90=c[int(n*0.9+0.5)];p99=c[int(n*0.99+0.5)]; mx=c[n]; print sprintf("CRET Elapsed (us): Min: %d | P50: %d | P90: %d | P99: %d | Max: %d", mn, p50, p90, p99, mx)}' ワンライナー 4 — レイテンシー影響の予測 grep -i 'message from client' $1 | gawk '{p=match($0,/tim=[0-9]+/); t=substr($0,p+4,RLENGTH-4)+0; if(NR==1) s=t; e=t; n++}END{crets=n-1; el=(e-s);print sprintf("Latency Impact: +100us: +%.0fs (+%.1f%%) | +150us: +%.0fs (+%.1f%%) | +200us: +%.0fs (+%.1f%%)", crets*100/1000000, (crets*100/el)*100,crets*150/1000000, (crets*150/el)*100,crets*200/1000000, (crets*200/el)*100)}' 実践例: CRET 分析の出力 次のスクリーンショットは、クライアント側の実行パターンがまったく異なる 2 つのトレースファイル (いずれも CRET イベント 10,000 件) に対して、4 つのワンライナーを実行した例です。一方はタイトループ、もう一方はリクエストの合間にクライアント側の処理待ちが大きく入るパターンです。ワンライナーの出力から、それぞれのパターンのレイテンシー感度が定量的にわかります。 図 5: タイトループのトレースとクライアント遅延のトレースに対する 4 つの CRET ワンライナーの出力 クライアントがタイトループするトレース (ora_196424.trc) このトレースの対象期間は 7.0 秒で、10,000 件の CRET は平均で毎秒 1,430 件でした。1 秒を 1,430 で割ると、単一セッションの実行予算は 699µs になります。SNMFC の P50 である 665µs が非データベース時間で、ここには SQL*Net RTT とクライアント時間の両方が含まれます。単一セッションの実行予算 699µs のうち 665µs を非データベース時間が占めており、SQL*Net RTT を追加する余地はほぼありません。ワンライナー 4 の出力によると、たとえば SQL*Net RTT に 150µs を加えた場合、経過時間 7 秒に対して 2 秒 (+21.5%) 増えます。この SQL 文を処理しているセッションは、SQL*Net RTT レイテンシーの目立った増加を許容できません。 クライアント遅延のあるトレース (ora_255365.trc) このトレースには 1,557.7 秒の間に生成された 10,000 件の CRET が含まれ、平均は毎秒 6.42 件です。ただしセッションの実行パターンはバースト的で、この平均値は実態を表していません。SNMFC の P99 が 4.17 秒であることから、数秒単位のアイドル期間が短時間の集中的な処理の合間に挟まっており、毎秒平均は実行の密度を測る指標として意味を持たないとわかります。1 秒を 6.42 で割ると、単一セッションの実行予算は CRET 1 回あたり約 156ms になります。SNMFC の P50 である 888µs (0.888ms) が非データベース時間で、SQL*Net RTT とクライアント時間の両方を含みます。156ms の実行予算に対して非データベース時間は 1ms 未満しか占めておらず、SQL*Net RTT の増加は問題になりません。ワンライナー 4 の出力によると、たとえば 10,000 件の CRET イベントそれぞれに SQL*Net RTT を 200µs 追加しても、26 分のトレースに対する増加はわずか 2 秒です。経過時間の増加率は 0.1% です。 CRET 分析: 両者の比較 指標 例 A: タイトループ (敏感) 例 B: クライアント遅延 (許容) CRET 総数 10,000 10,000 CRET レート 1,430.06 / 秒 6.42 / 秒 SNMFC P50 (非 DB 時間) 665µs 888µs SNMFC P99 (非 DB 時間) 902µs 4,171,289µs (4.17 秒) CRET P50 (ラウンドトリップ) 683µs 1,041µs CRET P99 (ラウンドトリップ) 923µs 4,171,440µs (4.17 秒) 総経過時間 7.0 秒 (0.12 分) 1,557.7 秒 (25.96 分) +150µs RTT の影響 +2 秒 (+21.5%) +2 秒 (+0.1%) 評価 SQL*Net RTT レイテンシーの増加を許容できない SQL*Net RTT レイテンシーの増加を許容できる 全体の流れ Client Request Elapsed Time (CRET) 手法は、3 つのフェーズで段階的に絞り込むスクリーニングプロセスです。フェーズ 1 では AWR を使い、データベース処理時間がサブミリ秒で実行頻度の高い SQL 文を特定します。フェーズ 2 では SQL Execution Session Density (SESD) を評価し、実行が 1 つまたはごく少数のセッションに集中しているかを判断します。多数のセッションに分散していれば、その SQL 文は対象外です。集中している場合はフェーズ 3 に進み、High SESD のセッションをトレースしたうえで、トレースファイルに対して CRET 分析ツールを実行し、SQL*Net RTT がさまざまな幅で増加した場合の実行時間への影響を予測します。 結果の解釈 本手法では、SQL*Net レイテンシーの増加が実行時間に与える影響を予測します。移行の判断にあたっては、次の枠組みを出発点にしてください。 予測される影響 分類 ガイダンス < 5% 許容 (Tolerant) ワークロードは低い SQL*Net レイテンシーを必要としません。ODB@AWS に適しています。 5% – 10% 境界 (Borderline) アプリケーションオーナーとの協議が必要です。判断の前に、移行先リージョンでの実際の ODB@AWS RTT を測定してください。 > 10% 敏感 (Sensitive) 明確なパフォーマンス低下が見込まれます。RTT の測定、緩和策の検討、アーキテクチャの見直しが必要です。 ODB@AWS 移行候補における接続とデプロイの考慮事項 次のステップに沿って進めれば、ワークロードの適合性を評価し、ODB@AWS で SQL*Net レイテンシーを可能な限り低く抑えられます。 まず CRET 手法でワークロードをスクリーニングする。アーキテクチャを決める前に、少なくともフェーズ 1 (AWR スクリーニング) を実施し、高速かつ高頻度で、少数のセッションに集中している (High SESD) SQL 文を特定します。この分析によって、ワークロードが ODB@AWS デプロイの有力候補なのか、先にアプリケーション層の最適化が必要なのかを判断できます。 アプリケーション層を同一の場所に配置し、直接 ODB Peering を確立する。レイテンシーに敏感なアプリケーションコンポーネントは、ODB ネットワークと同じアベイラビリティゾーンにデプロイし、AZ 間のレイテンシーによる負荷を排除します。アプリケーションの VPC と ODB ネットワークの間には直接 ODB Peering を確立します。直接 Peering により、AWS Transit Gateway や AWS Cloud WAN を経由せず、Exadata データベースまでの最短のネットワーク経路が得られます。接続パターンの詳細は「 Oracle Database@AWS ネットワーク接続パターンの実装 」を参照してください。 ODB@AWS 高性能ネットワーキング を有効にし、レイテンシーを検証する。 ODB@AWS 高性能ネットワーキング を有効にすると、同一アベイラビリティゾーン内のアプリケーション層 (EC2、ECS、EKS) と ODB@AWS データベースの間で 安定したサブミリ秒の SQL*Net ラウンドトリップレイテンシー を実現できます。高性能ネットワーキングは、自動的にプロビジョニングされる EC2 プレイスメントグループを使い、アプリケーションインスタンスを Exadata インフラストラクチャの物理的に近い位置に配置します。追加料金はかかりません。測定と検証の手順は「 Oracle Database@AWS の高性能ネットワーキング入門 」の「Measuring Network Latency」セクションを参照してください。 まとめ 本記事では、ワークロードの SQL*Net レイテンシー特性が ODB@AWS のマルチクラウドデプロイアーキテクチャに適合するかどうかを段階的に判断する手法として、CRET 手法を紹介しました。高速かつ高頻度で、少数のセッションに集中して実行される SQL 文を分析すれば、移行前に SQL*Net レイテンシーへの感度を把握できます。 CRET の評価でレイテンシーに敏感と判明したワークロードについては、ODB@AWS アーキテクチャを候補から外す前に、配列フェッチ、バルク処理、ストアドプロシージャを使って SQL*Net のラウンドトリップを減らすことを検討してください。 著者について Sameer Malik Sameer は、AWS のプリンシパル Solutions Architect として、エンタープライズデータベースとクラウドデータプラットフォームのモダナイゼーションを担当しています。Oracle、Exadata、PostgreSQL、Amazon Aurora、Amazon RDS に精通し、複雑なデータベース環境を、最新のアプリケーションや AI を支えるスケーラブルで回復力の高いプラットフォームへと変革する取り組みを支援しています。 Kevin Closson Kevin は、AWS の RDS Commercial Engines グループに所属するプリンシパルデータベースエンジニアです。データベースプラットフォームのパフォーマンスに精通し、Amazon RDS を含むさまざまなプラットフォームの I/O 性能テストに広く使われている SLOB (Silly Little Oracle Benchmark) ツールの作成者です。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 25 日から 26 日に幕張メッセで開催された AWS Summit Japan 2026 の開催報告です。AWS for Industries Zone に出展した株式会社 SUMCO のブース展示 「Amazon Redshift × 生成 AI で挑む 半導体ウェーハメーカーの DX」 の内容を、SUMCO と AWS が共同で振り返ります。 図 1: AWS Summit Japan 2026 の SUMCO ブース。実物の 300mm シリコンウェーハとともに、生成 AI を活用したデータ分析の取り組みと AWS 基盤のアーキテクチャを展示した。 SUMCO と半導体を支えるシリコンウェーハ SUMCO は半導体デバイスの基板材料となるシリコンウェーハの製造・販売を手がける企業です。社名は「Silicon United Manufacturing Corporation」に由来します。スマートフォンや自動車、データセンターに至るまで、あらゆる半導体デバイスの起点となる素材がシリコンウェーハであり、その品質は半導体の進化を根底から支えています。 シリコンウェーハは珪石から多結晶シリコンを精製し、単結晶を引き上げてインゴットとし、スライシング・ラッピング・ポリッシング・洗浄といった多数の工程を経て、鏡面ウェーハとして出荷されます。この一連の製造プロセスの各工程で、製造装置・検査装置から膨大なデータが生成されます。 図 2: SUMCO のデータ活用。各工程の検査情報・経路情報・製造装置の稼働情報を Amazon Redshift に集約し、データの意味を解釈してシリコンウェーハの状態を推定する。 背景と課題：ビッグデータを“価値”に変えるために SUMCO が目指すのは、単一工程内の改善にとどまらず、製造装置・検査装置から生じる膨大なデータ、つまりビッグデータを収集・解析することで複数工程をまたいだ改善を実現することです。前工程が後工程に与える影響を把握し、工程間の装置の組み合わせまで見据えて最適化することで、より高精度・高品質なシリコンウェーハの製造につなげます。 一方でビッグデータを実際の価値へと変えていくには乗り越えるべきテーマがありました。分析を担う人材と製造現場とでは、得意とする領域が異なります。データ分析の専門人材であるデータサイエンティストは分析手法に、製造現場は工程や品質の知見に、それぞれ強みを持ちます。この双方の強みを結びつけ、限られた専門人材だけに頼るのではなく、現場を含む組織全体でデータを活用できる状態をつくることが取り組みの出発点です。 取り組み：3 つの要素で組織のデータ活用を底上げする AWS Summit での展示は、SUMCO のデータ活用を次の 3 つの要素でご紹介しました。セキュアな基盤という土台と、その上で動く RedPulse・SynchroFabAI という 2 つのデータ活用の取り組みです。RedPulse と SynchroFabAI はいずれも SUMCO が開発した仕組みの名称です。 A. 基盤 セキュアな AWS 環境。製造データをクラウドで安全に扱うための土台 B. RedPulse 大量データの加工・比較を支えるデータ処理の仕組み C. SynchroFabAI 生成 AI で自然言語によるデータ解析を行う取り組み 図 3: データ分析基盤の全体像。SynchroFabAI（生成 AI アプリ）と RedPulse（データパイプライン＋データ処理）が、Amazon Redshift を中核とする基盤とともに構成される。 A. 基盤：製造データを安全にクラウドで活用する 製造データをクラウドで安全に活用するための土台となるのが、AWS 上に構築されたセキュアな基盤です。半導体業界はセキュリティ要件が厳しく、製造データをクラウドで扱うこと自体が挑戦的な取り組みであるため、その土台には堅牢なガバナンスが不可欠でした。 SUMCO の AWS 基盤は工場と AWS を安全につなぎ、用途ごとにアカウントを分離した構成をとっています（図 4）。この基盤はネットワーク統制と権限統制の 2 つの観点で運用されています。 ネットワーク統制（閉域網の構築） AWS 環境からインターネットへの直接通信を禁止 AWS Direct Connect を用いたオンプレミスと AWS 間の専用ネットワーク接続 権限統制 AWS Identity and Access Management (IAM) による必要最小限の権限付与 AWS Organizations のサービスコントロールポリシー (SCP) による組織全体への予防的統制 AWS 環境に対して社内 IP アドレス以外からのアクセスを制限 図 4: AWS 基盤の全体構成。Organization・User・DWH のアカウントを分離し、AWS Transit Gateway で接続。工場からは AWS Direct Connect 経由で取り込み、DWH アカウントの Amazon S3・Amazon Redshift にデータを集約する。 運用から、社内向けシステムの企画・ソリューション提供へ SUMCO 社内の AWS チームの役割は基盤の運用にとどまりません。IAM の最小権限設計や AWS サービスの払い出し、社内向けの AWS サポート・教育を担いながら、さらに AWS の技術を使った社内向けシステムの企画から、現場へのソリューション提供までへと取り組みを広げています。この社内 AWS チームの活動が、次に紹介する 2 つのデータ活用の取り組みを支えています。 図 5: SUMCO 社内 AWS チームの取り組み。基盤構築・運用・教育を土台に、社内向けシステムの企画とソリューション提供へと役割を広げている。 B. RedPulse：データ加工の知見を組織で共有する RedPulse は大量データの加工・比較を支えるデータパイプラインとデータ処理の仕組みです。製造装置が生成する製造中の時系列データを抽出し、複数の装置や時間帯といった条件で比較できます。これまで熟練者の経験に根ざしていたデータ加工の手順を仕組み化し、誰もが同じ手順で大量データを扱えるようにすることで、分析の入口となる作業を組織の共有資産にします。 図 6: RedPulse。製造中の時系列データを抽出し、複数の装置・時間の条件で比較できる。 実装面では、工場から取り込んだデータを Amazon Simple Storage Service (Amazon S3) に CSV / Parquet 形式で格納します。その後 AWS Lambda や Amazon Elastic Container Service (Amazon ECS) でデータパイプラインを通じた処理を実行し、 Amazon Redshift を中核とするデータ分析基盤に集約しています。 図 7: RedPulse のアーキテクチャ。工場のデータを Amazon S3 に格納し、AWS Lambda・Amazon ECS でデータパイプラインとデータ処理を行い、Amazon Redshift に集約する。 RedPulse で取得・整形した時系列データは、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析へとつながります。RedPulse は、こうしたデータ分析業務を支える役割を担っています。 C. SynchroFabAI：生成 AI で意味づけ・分析の知見を組織で共有する SynchroFabAI は生成 AI を活用して自然言語でビッグデータを解析する取り組みで、本記事執筆時点では PoC 段階です。データの意味を説明し、分析手法を提案・実行することで、分析の専門人材でなくても自然言語での対話だけでデータ分析を進められることを目指しています。 図 8: SynchroFabAI。自然言語での問いかけに対し、AI がデータの意味を説明し、分析手法を提案・実行する。 実装面では、オンプレミス環境に配置した AI エージェントの Cline が Amazon ECS 上に構築した Model Context Protocol (MCP) サーバーを介して、AWS 上の Amazon Redshift のデータソースを参照します。Cline の推論においては、 Amazon Bedrock で大規模言語モデルを利用します。Cline の振る舞いは Rules や Skills、および分析手法を記述した参照ファイルによって制御しています。 図 9: SynchroFabAI の実装。オンプレミスの Cline から、MCP を介して AWS 上の Amazon Bedrock・Amazon Redshift を利用する。 SynchroFabAI では、AI に持たせる知識の設計、すなわち製造現場の知見のうち何を、どのような形式で AI に渡すかの見極めを工夫しています。大量データへのクエリ生成を助ける専門用語集や、データと製品状態を紐づけるためのカタログ情報を AI に与え、「異常状態の推測」や「因果関係の推測」といった役割を担わせます。本 PoC では、データ・意味づけ・分析での解釈・AI の振る舞いという各層について、AI にどこまでの役割を担わせられるか、そしてデータと製品状態の紐づけや分析手法の選択・結果解釈の妥当性を検証しています（図 10）。こうして確立した意味づけ・分析の知見を仕組みに蓄積し、組織全体で共有・再利用していくことを目指しています。 図 10: SynchroFabAI へのデータ分析フローの実装。データ・意味づけ・分析での解釈・AI の振る舞いの各層について、AI に担わせる役割と、PoC で検証している内容を対応づけている。 “RedPulse では、Amazon Redshift の処理性能を引き出すことを念頭に SQL を作成・チューニングすることで、これまで時間を要していた大量データの集計が現実的な時間で回るようになり、Amazon Redshift のパワーを強く実感しました。SynchroFabAI では、生成 AI がデータの意味づけまで踏み込んで担う点が新鮮であり、集計や可視化の先にある「解釈」の領域にまで仕組みを広げられることは、現場のデータ活用の裾野を大きく広げると感じています。加えて、SynchroFabAI の設計にあたっては、専門用語集やカタログ情報として生成 AI に渡す知識の設計、そして意味づけ・分析手法の提案までを AI に担わせ、結果の妥当性の確認は人が担うという役割分担を、データサイエンティストと議論を重ねながら形にしていきました。実装側の視点だけでは辿り着けない分析の観点や知識に触れられたこの設計の過程こそ、本取り組みならではの面白さだったと感じています。” ― 株式会社 SUMCO AI推進本部 ICT推進部 荒木 亮 氏 今後の展望：データ活用を一部の専門人材から組織全体の力へ SUMCO の取り組みは単なる分析ツールの導入にとどまりません。多品種生産という SUMCO の事業価値を支えるには、品種・工程に合わせた分析やアプリケーションが必要になります。データ加工の知見である RedPulse と、意味づけ・分析の知見である SynchroFabAI を組織の共有資産としていくことで、限られた専門人材への依存を減らし、現場を含む組織全体のデータ活用の底上げを図ります。 セキュアな AWS 環境という土台の上に、データ基盤の確立、そして生成 AI の活用へと、SUMCO は着実に歩みを進めてきました。この積み重ねの先に、現場を含む組織全体でデータを活かせる状態の実現を見据えています。 “データは当社の競争力の源泉であり、それを一部の専門人材だけでなく組織全体で活用できるようにすることは、多品種生産を強みとする当社にとって不可欠な変革です。今回の取り組みは、その第一歩として大きな手応えを感じています。セキュアな基盤の上で現場と分析をつなぎ、変化に素早く対応できる組織へ。AWS とともに、この歩みをさらに加速させていきます。” ― 株式会社 SUMCO AI推進本部 ICT推進部 部長 武富 太志 氏 おわりに AWS Summit Japan 2026 の SUMCO ブースでは、実物のシリコンウェーハとともにデータ活用の取り組みを紹介しました。厳しいセキュリティ要件のもとで製造データをクラウドと生成 AI で活用する SUMCO の挑戦は、同じ課題に向き合う製造業の皆さまにとって、参考となる点があるのではないかと考えています。 SUMCO と AWS は、これからもデータ活用 DX の歩みをともに進めてまいります。本記事が、製造業におけるデータと生成 AI の活用を検討されている皆さまの一助となれば幸いです。 図 11: AWS Summit Japan 2026 の SUMCO ブースにて。展示を支えた SUMCO の皆さまと、AWS メンバー。 執筆者について 武富 太志 株式会社SUMCO AI推進本部 ICT推進部 / 部長 「データを、現場の力に変える」をテーマに、工場で生まれる膨大なデータをAIやクラウドで活用し、ものづくりの現場をスマートにする取り組みを率いる。難しいIT技術を社員が使いこなせるよう教育にも力を注ぎ、「一部の専門家だけでなく、全員でデータを使いこなせる会社」を目指して日々奮闘中。 荒木 亮 株式会社SUMCO AI推進本部 ICT推進部 半導体業界において、製造装置の制御技術と工場のデータ基盤、双方の実務領域にエンジニアとして関わってきた。SUMCOでは製造現場の知見をシステムとして具現化することで、ITを軸とした自動化とデータ活用に取り組んでいる。社内ではいつの間にか「万屋（よろずや）」と呼ばれるようになり、静かに受け入れつつも、熱量に限ってはその肩書きが窮屈らしい。 大森 敬太 株式会社SUMCO ウェーハ技術部 プロセス企画課 / データサイエンティスト 2021年にSUMCOへ入社後、ICT部門に配属。SEとしてIT知識を習得しながら、製造現場の見える化推進に取り組む。その後、システム開発やデータ分析業務など幅広いICT関連業務を経験。2023年よりデータサイエンス課に配属。現在、データサイエンス分野の博士後期課程に社会人博士として在学中。製造現場とデータ分析をつなぐ役割を担い、組織全体のデータ活用推進に取り組んでいる。 酒井 賢 アマゾン ウェブ サービス ジャパン合同会社 ハイテク＆ヘルスケア・ライフサイエンス部 / シニアソリューションアーキテクト IT 業界で 20 年以上の実務経験を持つソリューションアーキテクト。2020 年の AWS 入社後、製造業を中心にさまざまな業種の企業を支援し、現在は半導体業界を専門としている。企業がクラウドソリューションを計画・実装し、AWS 上で安全かつ高性能で柔軟な費用対効果の高い環境を構築することへの支援に注力している。

Amazon Bedrock は、Anthropic や OpenAI をはじめとする主要モデルからオープンウェイトモデルまで、幅広いモデルの選択肢を提供しています。アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）は 2026 年 7 月 28 日、東京・赤坂インターシティコンファレンスにて「AWS Bedrock LLM Day Japan」を開催しました。AWS Summit New York City で発表された最新アップデートをいち早くお届けするとともに、Amazon Bedrock で実験段階から本番運用へとスケールしているお客様 5 社の事例、AWS パートナー各社によるソリューション紹介とデモ展示（パートナー Expo）を通じて、本番環境対応のソリューションへ進むための次のステップをお届けしました。 イベントは 2 部構成で、前半は全参加者向けに最新アップデートとお客様事例を、後半はサービス詳細を掘り下げる Tech Session と、パートナー企業様が生成 AI のビジネス価値を紹介する Business Session を 2 会場で並行開催しました。本記事では、その模様をレポートします。 開会のご挨拶 イベントの冒頭では、AWS ジャパン AIML 事業開発マネージャー 井形 健太郎が開会の挨拶を行い、本イベントの狙いと一日の流れを案内しました。 AWS Keynote と最新アップデート 基調講演には、WW Bedrock & AgentCore GTM Director の Eugene Kawamoto が登壇しました。AWS に 13 年以上在籍し、日本で最初のビジネス開発担当者として東京でキャリアをスタートした Eugene は、冒頭で本日の主題として「モデルの柔軟性」「高セキュリティなプラットフォーム」「エージェントの大規模な構築」の 3 領域を提示しました。 Amazon Bedrock は現在、世界中で 12.5 万を超えるお客様の生成 AI を支え、100 を超えるモデルをサポートしています。直近では本年 4 月の OpenAI との戦略的パートナーシップを受けて GPT-5.5 / GPT-5.4 / Codex が利用可能になり、Anthropic の次世代モデル Claude Fable 5 も一般提供が開始されました。最高水準のオープンウェイトモデルがフロンティアモデルに肩を並べつつある点にも触れています。 基盤面では、AWS PrivateLink による閉域接続と Zero Data Retention（データ非保持）の原則に加え、新しい推論プラットフォーム Project Mantle を紹介しました。障害時もオペレーターが環境にアクセスしない「ゼロオペレーターアクセス」、統合キャパシティプールによる高いデフォルトクォータ、東京を含むアジアパシフィック 4 リージョンでの稼働とリージョン特化エンドポイント、リクエストを 3 つの優先度レーンに割り当てるサービスティアが特長です。 エージェントについては「本番稼働は依然として難しい」と切り出しました。多くのチームがエージェントのロジックではなく認証やメモリ、ガバナンスの構築に何か月も費やしており、「エージェントが本番で動いていない 1 か月は、組織の勢いを積み上げられない 1 か月」だと述べました。これに応える Amazon Bedrock AgentCore では、直近 6 か月でエージェントの実行タスク数が 15 倍に増加。鍵となるのは「ハーネス」で、モデルが「脳」、AgentCore の各コンポーネントが「身体」だとすれば、その身体をうまく使う仕組みがハーネスにあたります。AWS Summit New York City で一般提供を開始した AgentCore harnessにより、数回の API 呼び出しでアイデアから本番まで数分に短縮できるようになりました。 最後のテーマは「データ、コンテキストがすべて」です。優秀な新入社員でも社内のプロセスを知らなければ活躍が難しいのと同じだと Eugene は説明しました。公開データについては Amazon の Web 検索を AgentCore の Web Search として、社内データについては取り込み・解析・検索をマネージドで担う Amazon Bedrock Managed Knowledge Base として提供（いずれも一般提供開始）。さらに構造化・非構造化を横断する AWS Context（近日提供予定）も紹介し、「今日の限界を、明日の境界として受け入れるな」という言葉で講演を締めくくりました。 お客様事例 続いて、Amazon Bedrock で生成 AI を本番運用へとスケールさせているお客様 5 社にご登壇いただきました。 日本電気株式会社 コーポレート IT AI プラットフォーム統括部 ディレクター 野口 忠則 氏は、「Anthropic 協業の舞台裏」として、Claude Cowork on Bedrock を 2 週間で本番構築した経緯を共有しました。AWS から Amazon Bedrock 経由でも利用可能になるとの情報提供を受けたのは、全社展開を決めていた 6 月 1 日のわずか 3 週間前。国内のデータ所在要件を満たせるのが Amazon Bedrock 経由だけであり、利用者が作成したスキル等を後から移行できないため、初日を逃すと切り替えが実質不可能になることが決断の理由でした。 最大の難所は、リリース 1 週間前の金曜夜に判明した MCP 経由のシステム間認可の不具合です。深夜まで調査しても自社メンバーだけでは解決できず、AWS サポートへ緊急扱いでエスカレーションし、土曜の朝から調査を開始。「6 月 1 日のリリースは無理だと思った」という状況から、担当営業と AWS 側エンジニアの全力支援で日曜夕方には原因を特定できたと振り返りました。接続先の SaaS が OAuth 2.0 / DCR に対応しているとは限らない点は、自社の認可中継サーバーで対応しています。 結果として、一般提供前のサービスの早期適用で 2 週間・12 万人規模の本番展開を完遂し、国内大手 IT ベンダー初の先行事例となりました。7 月 27 日時点の利用者は 9,700 名です。成功のポイントは、組織の後押しと許容、大規模システムを支える推進力、そしてリファレンスがない中でもベンダーとともに問題を 1 つずつ検証・改善する One Team 体制の 3 点でした。 丸紅株式会社 バリュークリエーションオフィス 事業成長支援課 芹川 武尊 氏（写真上）と Digital Experts 株式会社 仲吉 朝洋 氏（写真下）は、AgentCore runtime 上で本番運用している 2 つのエージェントを紹介しました。1 つは「VCO Agent」で、チャットに指示するだけで AI がコードの作成・実行まで行い、データ分析からドキュメント生成、定型業務のスキル化と共有までをプログラミング不要で現場の非エンジニアに届けます。総合商社では機密区分やアクセス権が業務ごとに異なるため、機密データを社外に出さず本人の権限の範囲内で処理することが前提条件でした。4 月 1 日の開発開始から 9 日で初回利用、16 週後には利用者 619 名・直近週 1,647 件・ユーザー作成スキル 285 個に達しています。 もう 1 つは、企業名を入力するだけで市場調査から情報収集・数値分析・レポート出力までを実行する競合分析エージェントです。1 社あたり数分 × 競合企業数のため全体で 1 時間弱かかることもあり、サーバーレスで最大 8 時間の連続実行を完走できることが採用の決め手になりました。いずれも AWS Lambda やコンテナ基盤と比較のうえ、セッションごとの microVM 割り当てと JWT / IAM の標準サポートを理由に AgentCore runtime を選定。「本番化の鍵は、モデルの選定より安全な実行環境の設計」というのが 2 つの運用から得た結論でした。 ファストドクター株式会社 オンライン本部 プロダクト部 部長 / リードアーキテクト 加藤 倫弘 氏は、医療事務 AI による自動化を「PoC から本番への筋道」として共有しました。1 件の診察は数十ステップが直列に処理されますが、AI を入れたのはそのうち 1 ステップだけ。医療証を見てどの公費制度かを特定する工程で、医療事務が 1 件 2〜5 分かけており、自治体ごとに様式も運用も異なるためルールベースでは最後まで解けなかった「難所」でした。実行基盤に AgentCore runtime、フレームワークに Strands Agents を採用し、書いたのは業務手順とツールだけだったためプロトタイプは 1 日で動いたといいます。 本番化のコツは 3 点。精度を上げるのは AI 以外の作り込みであること（前処理は決定的なコードでやり切り、マニュアル照合だけを AI に任せる）、出力の型を先に決めて確信度が低い案件は止めて人へ回す「間違えても大丈夫な構造」を先に作ること、そして評価とダークローンチを経て約 1 週間の全件チェックを挟んで本番運用に移す段階的なリリースです。「間違えない AI を作ろうとすると、永遠に本番に出せない。構造で受け止める」という考え方が根底にあります。 株式会社リクルート プロダクト開発統括室 プロダクトディベロップメント室 VP 片岡 歩 氏は、「Chat から Agent へ — その転換を、6000 人全員に」をテーマに、社員 1,500 名とパートナー 4,500 名の計 6,000 名にエージェント型 AI 環境を届ける共通基盤を紹介しました。Claude Code のランチャーから LiteLLM を経由し、Amazon Bedrock 上のクローズドモデルと自社 GPU サーバー上のオープンウェイトモデルの双方を扱える構成です。チャット型は現行の業務フローがベースのため生産性改善は 10〜20% ですが、エージェント型は業務プロセスそのものに編み込まれ、リードタイムを 1/10、1/20 に変える。だからこそ部分導入では効かず、「全員が使えることが必要条件」だと語りました。 課題は、パートナーや非エンジニアも含めて全員が使える環境をつくることと、想定外のトークン利用によるコスト爆発を防ぐことの、半ば矛盾した 2 つ。オープンウェイトモデルによるコストの固定費化と、LiteLLM で月間上限に達したら利用不可にする制御で対応し、勉強会や非エンジニア向け GUI ランチャーで利用を促進。登録ユーザー数は 3,000 人に達しました。AI-DLC を適用したある事例では 120 人月規模の案件を 3 名・20 営業日で完了し、コストで 97.5%、リードタイムで 84% の削減となっています。 jinjer 株式会社 プロダクト開発部 VPoT 玄 章夫 氏は、AgentCore を本番導入して直面した壁とその越え方を共有しました。分断されていた勤怠・休暇・人事労務のサービスを、チャットの共通窓口から横断利用できる AI アシスタントを開発。基盤を自前で作らずプロダクト開発に集中するため、Runtime・Memory・Identity・Observability を標準提供する AgentCore を選定し、自前構築見積り 2 か月に対して実績 1 か月と、約 1 か月の期間短縮を実現しました。 一方で 2 つの壁に直面します。1 つはパフォーマンスで、設定への知見不足からメモリ処理が想定以上に実行され、レスポンス遅延を招いていました。プロファイリングと TTFB 計測でボトルネックを特定し、メモリ書き込みを一括化することで書き込み時間を 70% 短縮。「マネージドサービスでも、設定や実行方式の理解が重要」というのが学びです。もう 1 つの LLM コストは、Strands Agents の採用、共通プロンプトのキャッシュ（入力トークンコストを 70% 削減）、小型モデルやルールベースへの振り分け、入出力サイズの最適化で対応。「LLM コストはモデル単価だけでは決まらない」として、システム全体での最適化が必要だと述べました。 後半セッション①：Tech Session Tech Session では、AWS のスペシャリストソリューションアーキテクトが最新モデル活用とエージェント構築基盤を解説しました。 AWS ジャパンの Sr. AI Specialist SA 石見 和也は「Claude on AWS」として、単に Amazon Bedrock で Claude が使えるという話を超え、多様なアーキテクチャパターンが立ち上がっていることを解説しました。AWS が提供する Claude のソリューションは、包括的な生成AIプラットフォームである Amazon Bedrock、Anthropic ネイティブな API 群を AWS の認証・監査・支払いと組み合わせて使える Claude Platform on AWS、ClaudeのEnterprise PlanをAWS Marketplace上での契約・支払いに集約する形の 3 つがあります。さらに、Claude Agent SDK を AgentCore runtime 上で動作させる方法や、Claude Platform on AWS経由でClaude Managed Agentsを利用しつつ、Lambda MicroVM 経由で AWS にアクセスする方法など、クラウド上でエージェントを長時間動作させる際のアーキテクチャも紹介しました。 AWS ジャパン Senior AI Solution Architect 菊田 遥平は、AWS が提供する OpenAI の最新アップデートを解説しました。Amazon Bedrock では GPT-5.4,5.5,5.6 と ChatGPT Work / Codex が利用可能になっており、GPT モデルは bedrock-mantle エンドポイント経由・Responses API 形式で提供されます。従来のモデルや API 形式とは Zero Data Retention に関わるサーバー側のデータ保持の仕組みが異なるので、利点と注意点について紹介しました。現時点では機能差分も存在し、テキスト出力のみであること、Cross Region Inference（CRIS）に未対応で US リージョンに限られること、コンテキスト長が 272K トークンであること（発表後に GPT-5.6 で 1M コンテキスト長に対応 https://aws.amazon.com/about-aws/whats-new/2026/08/gpt-sol-terra-luna-long-context-bedrock/ ）を説明しました。そのうえで、セキュリティやガバナンス、請求の統合、技術的なサポートといった AWS の利点に価値を感じるお客様には、ぜひ Amazon Bedrock 経由で OpenAI の機能を使ってほしいと呼びかけました。 AWS ジャパンの AI Specialist SA 鯨田 連也は、AWS Summit New York City で提起された「エージェントには適切なコンテキストが必要」「エージェントの構築自体が難しい」という 2 つの課題について、AgentCore がどのように解決するのかを、キーノートより一歩踏み込んで解説しました。前者のコンテキストの課題に対しては、Amazon Bedrock Managed Knowledge Base から、ユーザーごとに検索可能な文書を制御する ACL、ドキュメント種別を問わず自動でパースとチャンキングを行う Smart Parsing、複雑なクエリを分解して複数のナレッジベースを並列検索する Agentic Retrieve Stream API などの機能を紹介しました。あわせて、Amazon 独自の検索スタックにより Zero Data Egress で検索できる Web Search Tool on AgentCore も取り上げました。後者のエージェント構築の課題に対しては、モデル・ツール・スキル・メモリ・ファイルシステムを設定するだけで、ノーコードでエージェントを構築できる AgentCore harness の機能や利用方法について示しました。 後半セッション②： Business Session ビジネストラックでは「業務プロセス自動化」「業界特化型」「セキュリティ」という 3 つのテーマで構成され、それぞれのテーマで 3 社が異なるアプローチから同じ課題に挑みました。全登壇を貫いていたのは、「PoC で終わらせず、本番環境で安全に動かす」という一貫した問題意識です。コスト、工数、統制のそれぞれで定量的な効果が示され、生成 AI を「現場で使い続けられる形」にする実践知が共有されました。本ブログでは、テーマごとに登壇 3 社をまとめてご紹介します。 テーマ①：業務プロセス自動化 「AI エージェントで業務を自動化したいが、コストが読めない」「ノーコードで始めたいが品質が担保できない」「マルチエージェントは概念としては理解できるが、実際どう動くのか」 ―　本テーマでは、3 社がそれぞれ異なるアプローチでこの課題に回答しました。 KDDI アイレット 平野 健介 氏 サーバーワークス 久保 賢二 氏 ナレッジコミュニケーション 横内 俊宏 氏 トップバッターの KDDI アイレット は、企業や組織の AI 活用を促進する「AI Chat for Business」の運用知見をもとに、ID 定額モデルの固定費課題を実利用量のみ課金する トークン従量課金モデル で解決し、100 名以上の利用でコスト最大半額程度に低減できる可能性を提示。続く サーバーワークス は、Amazon Bedrock AgentCore の Agent Skills を活用した「Paperwork Agent」で、複雑な申請書様式を「教える」だけで作成時間を 20 分から 5 分へ約 75%削減 。締めくくりの ナレッジコミュニケーション は「AI は人で動かす」をテーマに、評価軸ごとにエージェントを分離した課題発見型のマルチ AI エージェント（ミルボン様事例）を、PoC 1 か月・実装 3 か月で立ち上げた実践知を共有しました。 テーマ②：業界特化型 建設と製造 ― 日本の基幹産業が抱える「人手不足」「属人化」「紙文化」に、AI エージェントはどう応えるのか。3 社がそれぞれの「現場」で実証した解決策を共有しました。 アジアクエスト 菊池 啓介 氏 シーイーシー（CEC） 青山 貴哉 氏 富士ソフト 吉田 祐史 氏 アジアクエスト は建設業界向けの 3 つの AI ソリューション（定型書類の自動作成、AI チャットによる BIM ソフト「Revit」操作、2D 図面の AI 3D モデル変換）で業界の DX を加速。 シーイーシー（CEC） は、FA/製造現場のドメイン知識を活かした設備保全 AI エージェントで、設備停止による 年間 4,500 万円規模の損失 に対し平均復旧時間 40%短縮を目標に属人化を解消。 富士ソフト は AI カメラ×Amazon Bedrock の「VisionAI Navi」で、Nova Lite （Claude 比約 1/8）/ Qwen3 VL （約 1/5）/ Claude Sonnet 5 を用途で使い分け、PoC 20 万円〜の低コストでコストと精度を両立します。 テーマ③：セキュリティ AI エージェントを PoC から本番に昇格させるとき、最大の壁は「セキュリティと統制」です。暴走、データ漏洩、監査不能 ― 本テーマでは、3 社がそれぞれ異なるレイヤーからこの課題に挑みました。 Aokumo Norihiro Takachi 氏 SCSK 渡辺 大介 氏 NRI（野村総合研究所） 北條 学男 氏 Aokumo は、J-SOX / FISC 環境で 1,200 以上の本番アクションを安全に実行する「Governed Execution OS」で、4 つの統制を「構造」として組み込み MTTR 73%削減 ・J-SOX 監査証跡を 3 分以内に出力（SBI グループ様で監査サイクルを数か月→18 日に短縮）。 SCSK は「本番投入、最悪のシナリオ」を防ぐ実行・統制・データの 3 層構成「Agentic AI プラットフォーム」を提示。 NRI （野村総合研究所） は、OWASP 脅威 17 項目の 71%が入出力監視だけでは検知困難と示し、プロアクティブ脆弱性診断とトレースログ分析基盤「AgentTrase」で内部を可視化する継続的な診断・監視を実現します。 クロージング クロージングは Tech Session と Business Session の 2 会場でそれぞれ行いました。 Tech Session では AWS ジャパン Sr. GTM Specialist AI/ML 樋口 亮太より、Business Session では AWS ジャパン Partner AI Specialist 井上　陽治より、AI 市場が 2030 年まで約 24 倍に成長すると言われる中で「導入した後、いかに価値を最大化するか」が本日のメインテーマであったと振り返りました。そして登壇内容から共通して見えてきた価値最大化の鍵として、モデルの柔軟性、セキュアなプラットフォーム、エージェントの構築の 3 点を挙げました。 次のステップとして、320 社以上のお客様にご参加いただいている「AWS ジャパン 生成 AI 実用化推進プログラム」を案内。あわせて、2026 年 8 月末に AWS ジャパン本社（麻布台ヒルズ）で開催予定の「生成 AI Frontier Meetup」を紹介しました。 パートナー Expo とネットワーキングの様子 セッション終了後は、ご登壇いただいたパートナー企業様の展示ブースで各社のソリューションを体験いただけるパートナー Expo とネットワーキングを実施しました。軽食・ドリンクをご用意し、休憩時間も含めて参加者とパートナー、AWS メンバーが自由に交流できる場としました。会場では各ブースを巡る「ブーススタンプラリー」も実施し、多くの参加者にパートナー各社のデモをご覧いただきました。AWS のメンバーも待機し、セッションの内容や個別の技術相談にその場でお答えしました。 おわりに 本イベントでは、最新のサービスアップデートから、本番運用へとスケールさせているお客様の事例、パートナー各社が現場で積み上げた実装と統制の知見までを一日でお届けしました。共通して見えてきたのは、生成 AI の議論の焦点が「何ができるか」から「どう本番で動かし続けるか」へ移っているということです。AWS ジャパンは、今後もモデルの選択肢とエージェント構築基盤の拡充、そして技術支援を通じて、お客様の生成 AI の本番活用と価値創出に貢献してまいります。 イベント当日投影いたしました、資料はこちらよりダウンロードいただけます。 AWS より投影の資料： AWS Bedrock LLM Day Japan AWS セッション資料 パートナー企業様より投影の資料： AWS Bedrock LLM Day Japan Partner Session

本ブログは 2026 年 8 月 13 日に公開された AWS Blog “ AWS Certificate Manager will discontinue email validation to prove domain validation for certificates ” を翻訳したものです。 本日 (2026 年 8 月 13 日)、 AWS Certificate Manager (ACM) が 2027 年 9 月 30 日までに E メール検証済みパブリック証明書のサポートを終了することを発表します。ACM のパブリック証明書で E メール検証を使用している場合は、この日付より前に DNS 検証への移行が必要です。この変更は、 Certification Authority/Browser (CA/B) フォーラム による E メールベースのドメイン検証の業界全体での廃止に合わせたものであり、フォーラムが定める 2028 年 3 月の期限に先立ち、移行のために丸 1 年の期間を確保できるようにしています。 このブログ記事では、この変更の理由とタイムライン、そして証明書を DNS 検証に移行するための手順を紹介します。 背景 CA/B フォーラムは、パブリックに信頼される証明書についてブラウザと認証機関 (CA) が従うべき標準を定めています。2025 年 11 月、CA/B フォーラムは 2028 年 3 月 15 日をもって E メールベースのドメイン検証のサポートを終了することを決議しました。この日付以降は、どの認証機関が発行したかにかかわらず、E メールで検証された証明書はブラウザから信頼されなくなります。 ACM は CA/B フォーラムの要件に合わせ、2027 年 9 月 30 日までに E メール検証を廃止します。この ACM のタイムラインにより、お客様は CA/B フォーラムの最終期限を迎える前に、1 年間かけて移行を進めることができます。 変更のタイムライン 現在 ACM からリクエストした証明書で E メール検証を使用している場合は、以下の重要な日付に注意してください。 2027 年 1 月 1 日 : ACM は新しい AWS リージョンでの E メール検証の提供を終了します。 2027 年 3 月 31 日 : ACM はすべてのリージョンで、新規の証明書リクエストに対する E メール検証の提供を終了します。 2027 年 9 月 30 日 : ACM はすべてのリージョンで、E メール検証を使用する既存の証明書の更新を終了します。 2028 年 3 月 15 日 : CA/B フォーラムの規定により、パブリック認証機関は E メールベースのドメイン検証を使用して、パブリックに信頼される証明書を発行または更新できなくなります。この日付より前に発行された証明書は、有効期限が切れるまで有効です。 既存の E メール検証済み証明書を確認する ACM が発行したパブリック証明書をお持ちの場合は、ACM の AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、E メール検証済みの証明書があるかどうかを確認できます。 ACM コンソールを使用して E メール検証済み証明書を特定する コンソールで以下の手順を実行して、E メール検証済み証明書を見つけます。 ACM コンソール を開きます。 フィルターで [Validation method] = [Email] (検証方法 = E メール) および [Type] = [Amazon Issued] (タイプ = Amazon 発行) を選択すると、E メール検証済み証明書の一覧が表示されます。 ここに表示された証明書は、E メール検証済みのパブリック証明書であり、2027 年 9 月 30 日までに移行する必要があります。 図 1: すべてのパブリック E メール検証済み証明書の一覧 AWS CLI を使用して E メール検証済み証明書を特定する 以下のコマンドを使用して、E メール検証済み証明書を見つけます。 # Discover email validated public certificates region="${1:-us-east-1}" aws acm list-certificates --region "$region" \ --query "CertificateSummaryList[?Type=='AMAZON_ISSUED'].CertificateArn" --output text | tr '\t' '\n' | while read -r arn; do aws acm describe-certificate --region "$region" --certificate-arn "$arn" \ --query 'Certificate.[DomainName,Type,DomainValidationOptions[0].ValidationMethod]' \ --output text done | awk -F'\t' '$3 == "EMAIL"' | column -t Usage: chmod +x list-email-validated-certs.sh ./list-email-validated-certs.sh # default region, us-east-1 ./list-email-validated-certs.sh us-west-2 # another region 既存の E メール検証済み証明書を移行する この移行を支援するため、ACM は UpdateCertificateOptions API を更新し、証明書を置き換えることなく、検証方法を E メールから DNS に切り替えられるようにします。これにより、証明書の Amazon リソースネーム (ARN) は変わらず、その証明書を参照している AWS リソースへの変更も不要です。 証明書を DNS 検証に更新すると、ACM は DNS 設定に追加する CNAME レコードを提供します。このレコードは 72 時間以内に追加する必要があります。この期間中、証明書は E メール検証のまま通常どおり機能し続けます。72 時間以内に DNS を更新しなかった場合でも、証明書は E メール検証のまま有効な状態を維持するため、準備ができた時点で再試行できます。DNS 検証が完了すると、ACM は有効期限が切れる前に証明書を自動的に更新するようになり、それ以上の手作業は不要です。ACM が中断なく証明書を最新の状態に保てるように、2027 年 9 月 30 日までに移行を完了することをお勧めします。 コンソールを使用して移行するには 更新が必要な証明書を特定したら、その証明書を開き、ページ上部の [ Update validation method ] (検証方法を更新) を選択します。 図 2: E メール検証済みパブリック証明書を表示した際の DNS 検証プロンプト 更新が開始されると、証明書ページの上部に [ View DNS records ] (DNS レコードを表示) というフラッシュバーが表示されます。 図 3: 検証方法の更新後に DNS 検証レコードを表示 フラッシュバーの [ View DNS records ] (DNS レコードを表示) を選択するとダイアログボックスが開き、他の DNS プロバイダーにエクスポートするための CNAME レコードの CSV ファイルをダウンロードできます。 図 4: ダイアログボックスから DNS 検証情報を取得 Route 53 をご利用の場合は、[ Create records in Route 53 ] (Route 53 でレコードを作成) を使用すると、ワンクリックで検証を実行できます。 図 5: Route 53 に DNS 検証レコードを作成 AWS CLI を使用して移行するには AWS CLI を使用して証明書を更新する手順については、 E メール検証から DNS 検証への移行に関するユーザーガイド を参照してください。 E メール検証の提供終了後の代替手段 ACM は今後、新しい証明書に対して 2 つの検証方法をサポートします。 DNS 検証 – DNS 設定に CNAME レコードを追加します。レコードが維持されている限り、ACM は DNS 検証済み証明書を自動的に更新します。ほとんどのユースケースでこの方法をお勧めします。 Amazon CloudFront 向けの HTTP 検証 – ACM が提供する一意のトークンを、ドメイン上の well-known URL パスでホストします。この方法は、 Amazon CloudFront で使用する証明書に限り利用できます。 どちらの方法も、E メール検証で必要だった手動の承認ステップが不要になり、ACM が証明書を自動的に更新できるようになります。 まとめ E メール検証の廃止と新しい UpdateCertificateOptions API の活用により、業界標準の進化に合わせて、証明書の信頼性とアプリケーションの安定した稼働を維持できます。更新された UpdateCertificateOptions API を使えば、この移行は簡単に行えます。証明書を置き換えずに検証方法を切り替えて DNS レコードを追加すれば、それ以降の更新は ACM が自動的に処理する仕組みになっています。 移行に関するご質問やサポートが必要な場合は、 AWS サポート にお問い合わせいただくか、 AWS re:Post の ACM フォーラム で新しいスレッドを作成してください。 Adam Aboudi Adam は AWS Certificate Manager チームの Senior Technical Product Manager です。お客様が証明書のライフサイクル管理を簡素化し、AWS 環境全体で強固なセキュリティポスチャを維持できるよう支援することに注力しています。 Poojil Tripathi Poojil は、テキサス州オースティンを拠点とする AWS の Solutions Architect です。AWS のお客様と協力して、あらゆる種類のワークロードに対する安全なアーキテクチャの設計を支援しています。「誰も見ていないかのように踊り、誰もが見ているかのように暗号化しましょう」というのが Poojil からのメッセージです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに AWS では、データコラボレーションサービスの提供を超えて、様々な業界の企業間でのデータコラボレーションを加速できるような機会創出にも力をいれています。2026 年 6 月 10 日、新潟市の共創型イノベーション施設 NINNO ROOM F にて、第四北越銀行と第四北越ITソリューションズ 、AWS の共催で、新潟県における地域産業のデータコラボレーションワークショップを開催しました。新潟を代表する食品・製造・小売・物流・スポーツ・メディアなど多様な産業の企業が一堂に会し、AWS Clean Rooms を活用したデータ連携の可能性について、熱い議論が交わされました。本記事では、ワークショップの開催背景と当日の内容をご紹介いたします。 新潟県は食品・製造・小売・物流・スポーツ・メディアなど多様な産業が集積する地域です。これらの産業が保有するデータを安全に連携することで、地域経済の活性化や新たなビジネス機会の創出が期待されています。一方で、異業種間のデータ活用には、セキュリティやプライバシー保護の観点から技術的なハードルが存在します。 この課題を解決するため、AWS は第四北越銀行、第四北越ITソリューションズと共同でワークショップを企画しました。「食×エンタメ」「ものづくり」「健康・医療×自治体サービス」「モノ・流通・小売り」の 4 つのテーマでテーブルを構成し、各業界の企業が AWS Clean Rooms を活用したデータコラボレーションのユースケースを議論する場を提供しました。 開催概要 項目 内容 開催日 2026年6月10日（水）13:30〜17:00 会場 NINNO ROOM F （新潟県新潟市）— 地域の共創を促進するコラボレーション型イノベーション施設 共催 第四北越銀行 / 第四北越ITソリューションズ / アマゾン ウェブ サービス ジャパン 参加企業 11社・1自治体・1大学 / 32名 AWS事務局 14名 合計参加者 46名 参加企業・団体（すべて新潟県に本社を構える企業） 製造業（6社）、流通小売業（3社）、物流・運輸業（1社）、自治体、AWS パートナー3社、第四北越銀行（共催） アジェンダ 第四北越銀行　常務取締役　石坂様：開会のご挨拶 AWS南：新潟県とAWSのこれまでの取り組み 新潟県 創業・イノベーション推進課 課長　藤田様：「県内産業の攻めのDXとAI活用支援」 新潟大学 山崎教授 ：新潟大学におけるAI研究の取り組み AWS松本：AWS コラボレーションテクノロジーのご紹介 テーブル別ディスカッション（4グループ） BSNアイネット　上席執行役員　坂田様：ワークショップ総括 第四北越ＩＴソリューションズ　代表取締役社長　原様： 閉会のご挨拶 懇親会 前半をセミナー、後半をディスカッションと分けて開催いたしました。後半のディスカッションでは、4つのテーマごとに分かれたテーブルで、各企業が実際にデータコラボレーションする際のユースケースと協業内容について議論を行いました。 データコラボレーションとは 本ワークショップのメインテーマであるデータコラボレーションと、それを支える AWS のサービスについてご説明します。データコラボレーションとは、複数の組織が保有するデータを安全かつ効果的に共有・統合・分析し、単独では得られない洞察や価値を生み出す取り組みです。例えば、小売業とメディア企業が匿名化された顧客データをコラボレーションすることで、より精緻なマーケティング戦略の立案や新サービスの開発が可能になります。重要なのは、各組織のデータプライバシーとセキュリティを維持しながら、必要な情報のみを共有することです。これにより、安全性を確保しつつデータの価値を最大化することができます。 なぜ今データコラボレーションが注目されているのか データコラボレーションの注目が高まっている背景には、デジタル化の加速、消費者行動の複雑化、個人情報を含むデータの保護に関する規制環境の整備があります。さらに 1st party data (自社で直接収集したデータ) の重要性が増していることも大きな要因です。サードパーティ Cookie の廃止や個人情報保護の厳格化に伴い、企業は自社の顧客データをより効果的に活用し、同時に他社のデータと安全に連携する必要性が高まっています。このデータ活用と連携が、企業の競争優位性を生み出す鍵となっています。 各セッションのハイライト 第四北越銀行 常務取締役　石坂様のオープニング 第四北越銀行　常務取締役　石坂様よりオープニングスピーチを頂戴し、本ワークショップへの期待と新潟経済活性化への思いをお話いただきました。 新潟県とＡＷＳの取り組みのご紹介 アマゾン ウェブ サービス ジャパン合同会社 新潟県アンバサダーの南より、これまで産学官金の連携を通じて行ってきた新潟県とＡＷＳの取り組みをご紹介しました。 新潟県 創業・イノベーション推進課のご講演 新潟県 創業・イノベーション推進課 藤田課長より、新潟県における産業のDX推進の取り組みとAI活用を促進するための事業について講演いただきました。 新潟大学 基調講演 新潟大学 山崎教授より、新潟大学におけるAI研究の取り組みについてご講演いただきました。 AWS のコラボレーションテクノロジー アマゾン ウェブ サービス ジャパン合同会社 松本鋼治より、データコラボレーションを AWS 上で実現する方法についてご説明を行いました。まずはデータコラボレーションを支える AWS Clean Rooms というマネージドサービスについてご紹介しました。 テーブル別ディスカッション ワークショップのメインとなったテーブル別ディスカッションでは、4つのグループに分かれ、AWSのファシリテートのもと、具体的なデータコラボレーションのユースケースについて活発な議論が交わされました。 また、新潟県に本社を構えるAWSパートナー3社がテックサポーターとして、各テーブルの議論を技術面でフォローしました。 G1: 食×エンタメ × B2C  ：製造業、小売り業、スポーツ、メディア企業などが参加　テックサポーター：第四北越ITソリューションズ G2: ものづくり ：製造業4社および小売り業が参加　テックサポーター：BSNアイネット G3: 健康・医療×自治体サービス 自治体、大学、ヘルスケアサービス企業が参加　テックサポーター：フラー G4: モノ・流通・小売り 流通、小売り、製造、メディア企業新が参加　テックサポーター：フラー 総括 ワークショップの総括をBSNアイネット　上席執行役員の坂田様より賜り、各テーブルで生まれたコラボレーションのアイデアや、本ワークショップがデータ活用に関して、じっくり考える機会になったことへのお褒めの言葉をいただきました。 また坂田様からは新潟県でAI活用推進のための各種取り組みをご紹介いただきました。 閉会のご挨拶 最後に閉会のご挨拶を第四北越ITソリューションズ　代表取締役社長　原様より賜り、ワークショップ本編は終了いたしました。 お客様の声 本ワークショップを通じて、参加企業の皆様からは、以下のような声をいただいております。 「製造業においてはデータ共有は難しいテーマだと感じていましたが、議論を進める中で物流をはじめとした共通の課題があることが分かり、大変有意義な意見交換ができました。今後、課題解決に向けていい方向へ発展していくことを期待しています」 — 製造業ご参加企業様 「普段話をしないような企業様や議題について、じっくりお話できてよかったです」 — 物流業ご参加企業様 「県内企業間で何ができるのか、様々な視点で考える良い機会でした」 — 小売業ご参加企業様 「データ活用について、特に地域貢献・地方創生へ繋がるアイデアが発生し議論を深めることができたのは、本イベントならではの体験と感じました」 — パートナー企業様 おわりに 本ワークショップを通じて、新潟県の多様な産業におけるデータコラボレーションの大きな可能性と、参加企業の皆様の熱意を肌で感じることができました。ここに改めて、ご参加いただいた企業・団体の皆様、そして共催である第四北越銀行、第四北越ITソリューションズの皆様に心より感謝申し上げます。AWS は、今後もこの様なデータコラボレーションを推進する取り組みのご支援や、皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、戦略事業開発本部　シニア事業開発マネージャー　飯島が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 Kiro が公開から 1 周年を迎えました。 1 年間の歩みを振り返る記事 では、最初の 5 日間で 10 万人以上が Kiro IDE を試したことや、IDE、CLI、Web、Mobile へと利用環境が広がったことが紹介されています。パートナーによる 100 以上の curated powers に加えて、コミュニティから 15,000 以上の独自 power も生まれました。2 年目の展開にも期待が膨らみます。 それでは、8 月 10 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ＪＣＲファーマ株式会社様、コーディング未経験の研究者が数日で機械学習解析を完遂 ＪＣＲファーマ株式会社様は、希少疾病などの治療薬を研究開発する製薬企業です。研究部門では、機械学習解析に必要なプログラミング技術の習得が課題でした。そこで、既存の AWS ガバナンスを活かし、推論先を東京・大阪リージョンに限定した Amazon Bedrock 経由の Claude Code 環境を約 10 日で整備しました。その結果、3 か月以上を見込んでいた技術習得を経ず、コーディング未経験の研究者が数日で実装から分析まで完遂。Active Directory 移行の調査・設計も、通常は外部委託で数週間かかるところを 2 日で内製しました。今後は社内データのセマンティック化と活用基盤を整備し、対象部門を広げる計画です。 ブログ記事「「聞くだけで、必要な情報が集まる」航空オペレーション基盤を Kiro で実現する」を公開 架空の航空データ 38 GB、約 29 万ファイルを使い、Amazon S3 に集約したデータを Amazon Bedrock Knowledge Bases と AgentCore Gateway で横断検索するリファレンス実装です。複数システムの確認に 30 分以上かかる想定業務を、自然言語で数秒以内に検索できる構成として示しています。12 のサブシステムと 79 の仕様ファイルを Kiro のスペック駆動開発で構築しており、複雑な業務基盤へ AI 開発を取り入れる際の参考になります。 ブログ記事「Kiro でライフサイエンス研究を加速する: 100 以上のオープンソースデータベースへの統合 AI インターフェース」を公開 Kiro power と 24 のドメイン特化 MCP サーバーを組み合わせ、NCBI、ClinVar、UniProt、PDB など 100 以上のデータベースとツールを自然言語から横断利用する「Kiro for Life Sciences」の紹介です。API や認証、データ形式の違いを Kiro が吸収し、複数データベースへの問い合わせと結果の統合を一度の会話で進めます。研究者やバイオインフォマティシャンは、具体的な導入手順まで確認できます。 ブログ記事「【開催報告】ISV SaaS 事業者向け 8 社合同 AI-DLC Unicorn Gym」を公開 ISV / SaaS 事業者 8 社、計 54 名が自社プロダクトの実テーマを持ち込み、Kiro や Claude Code で AI 駆動開発ライフサイクルを 2 日間実践したレポートです。8 チーム中 6 社がデモ可能な状態まで実装し、あるチームでは従来 1 か月以上かかっていた要件定義を 2 日間で完了しました。体感した平均工数削減率は 67.1%。AI の速度を活かしながら、人が判断へ集中する開発プロセスを考える材料になります。 ブログ記事「Motorway が Strands と AgentCore で構築した AI エージェント評価パイプラインの紹介」を公開 英国の中古車マーケットプレイス Motorway が、Strands Agents SDK と Amazon Bedrock AgentCore で構築したエージェント評価基盤を解説しています。ビルド時にはツール使用、推論、出力品質を 3 層で評価し、本番環境では AgentCore Evaluations で継続的に監視します。その結果、ツール選択の正確さは 87% から 98%へ、月次インシデントは 12 件から 2 件へ改善しました。サンプルリポジトリも公開されており、品質ゲートを設計する際の出発点になります。 ブログ記事「1 年間の経験。45 億行のコード。160 万時間の節約。そして私たちが学んだこと。」を公開 AWS Transform の一般提供開始から 1 年間の成果と、モダナイゼーションで得た知見をまとめた記事です。45 億行を超えるコードを処理し、数十万台のサーバーを移行して、お客様の作業時間を 160 万時間以上削減しました。MCP サーバー、Kiro powers、コーディングエージェントとの連携や、Kiro が生成仕様を引き継ぐメインフレーム刷新も紹介されています。継続的なモダナイゼーションを検討する方はぜひご覧ください。 ブログ記事「AWS が Anthropic および OpenAI と協業し、AWS Continuum を開発者ワークフローに統合します」を公開 コード脆弱性を検出・優先順位付け・検証・修復する AWS Continuum for code vulnerabilities が、Claude Code、OpenAI Codex、Kiro の開発ワークフローへ統合されます。AWS 環境の IAM ポリシーやネットワーク構成も踏まえて検出結果を検証し、文脈付きの修正情報をコーディングアシスタントへ返す仕組みです。Continuum はプレビュー提供中で、各開発環境との統合は近日提供予定です。 ブログ記事「AWS が Agent Plugins をサポート: ポータブルなエージェント拡張のためのオープン標準」を公開 Agent Plugins 1.0.0 は、Agent Skills と MCP サーバーを一度パッケージ化し、Kiro、VS Code、Cursor などの対応クライアントへ配布するためのオープン仕様です。AWS は設立メンバーとして仕様を支援し、 Kiro powers でも対応を順次展開 しています。既存の power はそのまま利用でき、標準形式のプラグインを power としてインストールできるため、クライアントごとの再パッケージ化を減らせます。 ブログ記事「AWS DevOps Agent と Kiro CLI によるインシデント修正の自動化」を公開 AWS DevOps Agent による原因調査と修正計画を、AWS CodeBuild 上でヘッドレス実行する Kiro CLI へ渡す、イベント駆動型の修正パイプラインを紹介しています。Kiro CLI が steering に従って対象を絞った変更を行い、pull request を作成。人は変更をレビューして承認します。調査からコード修正までを自動化しつつ、人の承認を残した自動修正パターンを具体的に示しています。 サービスアップデート OpenAI のサイバーセキュリティモデル Daybreak Red / Blue が Amazon Bedrock で利用可能に OpenAI のサイバー防御向けモデル Daybreak Blue と Daybreak Red が、対象のお客様向けに Amazon Bedrock で提供されました。Blue は脆弱性検出、検知エンジニアリング、インシデント対応などの防御業務向け。Red は、認可された脆弱性研究やエクスプロイト再現、緩和策の開発といった高度な用途向けです。米国東部（オハイオ）リージョンで利用でき、OpenAI の Daybreak access への登録と AWS でのアクセス申請が必要です。 Amazon Bedrock の IAM プリンシパル別コスト配分が bedrock-mantle に対応 bedrock-mantle エンドポイントの推論コストを、IAM ユーザーやロールに付けたタグで配分できるようになりました。チーム、プロジェクト、アプリケーションなどの単位で、AWS Cost Explorer や CUR 2.0 から利用額を分析できます。次世代推論エンジンを共用する組織でも、利用主体ごとのコストを追跡しやすくなります。bedrock-mantle が提供されているすべての AWS リージョンが対象です。 視覚認識・エージェント環境・マルチモーダル推論の 3 モデルが SageMaker JumpStart に追加 LocateAnything-3B、Qwen-AgentWorld-35B-A3B、Qwen3.5-122B-A10B が Amazon SageMaker JumpStart で利用可能になりました。画像内の物体位置特定、7 種類の操作ドメインにまたがるエージェント環境シミュレーション、262K コンテキストを備えた大規模マルチモーダル推論という、異なる用途をカバーします。専門的なモデルを AWS アカウントへ数回のクリックでデプロイできます。 長時間コーディング・効率的推論・複雑文書 OCR の 3 モデルが SageMaker JumpStart に追加 GLM-5.2 FP8、NVIDIA-Nemotron-Nano-12B-v2、GLM-OCR が Amazon SageMaker JumpStart に加わりました。GLM-5.2 FP8 は 100 万トークンのコンテキストで長時間のエンジニアリング作業を支援します。Nemotron-Nano は 12B のコンパクトな構成で推論スループットを高め、GLM-OCR は表や数式を含む文書を Markdown、JSON、LaTeX として再構築します。コーディングから文書処理まで幅広い選択肢が増えました。 セマンティックキャッシュ・コード推論・多言語 OCR の 3 モデルが SageMaker JumpStart に追加 langcache-embed-v3-small、Mellum2-12B-A2.5B-Thinking、LightOnOCR-2-1B が Amazon SageMaker JumpStart で利用可能になりました。意味的に同じ問い合わせを検出して LLM 呼び出しを減らす埋め込み、コードに特化した MoE 推論、多言語文書を直接テキスト化する軽量 OCR を提供します。推論コストや応答時間を抑えたい本番ワークロードで、用途に合ったモデルを選びやすくなります。 画像生成の軽量デコーダーと Gemma 4 が SageMaker JumpStart に追加 FLUX.2-small-decoder と gemma-4-12B-it が Amazon SageMaker JumpStart に追加されました。FLUX.2-small-decoder は、画質をほぼ維持しながらデコードを約 1.4 倍高速化し、VRAM 使用量を標準デコーダーの約 71% に抑えます。gemma-4-12B-it はテキスト、画像、音声を扱い、関数呼び出しとエージェントワークフローにも対応。限られたメモリでマルチモーダル処理を動かしたい場合にも選択肢が広がります。 生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。3 つのコースから選べて、AWS クレジットの付与や技術支援も用意されています。ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 お盆も明け、まだまだ暑い日が続きますが、いかがお過ごしでしょうか。休暇中に溜まったアップデートを一気にキャッチアップされている方も多いかもしれませんね。 さて、生成AI開発の現場に身を置いていると、ここ最近「作る」こと自体のハードルがどんどん下がっているのを実感します。エージェントに任せられる作業が増え、これまで手作業だったコード生成やドキュメント作成、分析までもが数クリックで動き出す──そんな時代になってきました。一方で、便利になればなるほど「誰が・何に・どれだけ使っているか」を把握し、安全に統制する仕組みの重要性も増しています。今週は、まさにその「開発を加速させる機能」と「安心して使うためのガバナンス機能」が両輪で登場した、バランスの良い一週間でした。 それでは、2026年8月10日週の主要なアップデートを見ていきましょう。 2026年8月10日週の主要なアップデート 8/10(月) AWS Identity and Access Management が account access manager によるワークフォースユーザーへの IAM ロール割り当てを提供開始 AWS IAM に account access manager という新機能が追加されました。これまで、AWS アカウントへのワークフォースアクセスを付与するお客様は、2 つの代替的なアクセス管理アプローチのいずれかを使用できました。1 つは、各 AWS アカウントにユーザーを個別にフェデレーションし、各 AWS アカウント内の IAM ロールを使用してユーザーアクセス許可を細かく定義する方法です。もう 1 つは、IAM Identity Center を通じてユーザーを 1 回のみフェデレーションし、AWS マネージドアクセス許可セットを調整してプロビジョニングすることで、アクセスを一元的に管理する方法です。 本機能によりこの二つを両立できるようになりました。追加料金なしで、デフォルト有効の AWS 商用リージョンすべてで利用できます。 8/11(火) AWS Glue が AWS コンソールから SageMaker Unified Studio へのワンクリックアクセスを追加 AWS Glue コンソールから Amazon SageMaker Unified Studio をワンクリックで開けるようになりました。Glue コンソールでカタログテーブルを閲覧したり ETL ジョブを構築したりしているユーザーが、同じ IAM ロールのまま Unified Studio に移動し、データのクエリ、データ品質チェック、パイプライン構築、SageMaker Notebooks での分析を開始できます。今回の対応により、S3 Tables、Athena、EMR、Redshift、Glue の 5 つのコンソールから Unified Studio へ直接アクセスできるようになりました。未セットアップのユーザー向けには、IAM コンソールへ移動せずに必要な IAM ポリシーを作成・設定できるインライン権限パネルが提供されます。SageMaker Unified Studio が利用可能な全 15 リージョンで提供されます。 AWS Secrets Manager が Jenkins と SonarQube の managed external secrets 対応を追加 AWS Secrets Manager の managed external secrets に、Jenkins API Token と SonarQube Token が追加されました。これにより、Lambda 関数によるカスタムローテーションコードを書かずに、AWS コンソールからこれらのサードパーティ認証情報を自動ローテーションできます。Jenkins では新トークンの動作検証後に旧トークンを失効させるため、CI/CD ジョブを中断せずにローテーションできます。SonarQube では User Token、Global Analysis Token、Project Analysis Token の 3 種類に対応します。managed external secrets 自体は 2025 年 11 月に Salesforce、Snowflake、BigID の 3 パートナーで開始された機能で、追加料金なしで利用できます。 Amazon Bedrock が IAM プリンシパルによるコスト配分を bedrock-mantle エンドポイントに拡張 Amazon Bedrock の IAM プリンシパル (IAM ユーザーおよびロール) 単位のコスト配分機能が、`bedrock-runtime` エンドポイントに加えて `bedrock-mantle` エンドポイントでも利用できるようになりました。`bedrock-mantle` は OpenAI 互換の Responses API / Chat Completions API や Anthropic Messages API を提供する推論エンドポイントです。IAM ユーザーやロールに team、project、cost center などのタグを付与してコスト配分タグとして有効化すると、AWS Cost Explorer や CUR 2.0 で `bedrock-mantle` 経由の推論コストをユーザー、チーム、プロジェクト単位で分析できます。呼び出し元の識別 (IAM プリンシパル ARN の記録) はタグなしでも自動で行われ、アプリケーションコードの変更は不要です。 8/12(水) Amazon Quick が Microsoft Purview によるデータ損失防止に対応 Amazon Quick が Microsoft Purview と統合し、データ損失防止 (DLP) ポリシーを Quick 環境全体に適用できるようになりました。Microsoft Purview で定義済みの秘密度ラベル (例: Public、Confidential、Highly Confidential) を Quick が読み取り、chat、spaces、knowledge bases の 3 つの機能でファイル共有を制御します。ラベルごとに Block、Warn、Allow の 3 種類の強制アクションを設定でき、Microsoft 365 で運用中のガバナンスポリシーを追加ツールなしで Quick に拡張できます。Amazon Quick の agentic capabilities が利用できるすべての AWS リージョンで提供されます。 Amazon Quick のカスタム権限にデフォルト拒否 (deny by default) を追加 Amazon Quick のカスタム権限プロファイルに、ガバナンス設定として deny by default (デフォルト拒否) が追加されました。従来は Quick が新しい AI 機能をリリースすると、全ユーザーが即座に利用可能になり、管理者はリリース後に個別に制限する必要がありました。本機能を有効にすると、指定したカテゴリ (現時点では `AI` カテゴリのみ) に属する機能は、将来リリースされる新機能を含めてすべて自動的に拒否され、管理者が明示的に許可した機能だけがユーザーに提供されます。金融のモデルリスク管理 (MRM) やヘルスケアのコンプライアンス審査など、AI 機能の事前評価が必須の組織に向けた機能です。Amazon Quick が利用可能なすべての AWS リージョンで提供されます。 AWS IAM がロールマネージャーを提供、IAM ロールを自動でセットアップ可能に AWS は新機能ロールマネージャーの一般提供を発表しました。サポート対象のサービスコンソールでリソースを作成する際、必要な IAM ロールを AWS マネージドのロールテンプレートから自動作成、または既存の一致するロールを再利用します。ローンチ時点で AWS Lambda、Amazon EventBridge など 6 つのサービスコンソールに対応します。作成されるロールは通常の IAM ロールとして扱え、いつでも機能を無効化して IAM Access Analyzer で最小権限に絞り込めます。AWS GovCloud (US) と中国リージョンを除く全リージョンで利用できます。 Amazon Quick がユーザー単位のリソース制限に対応 Amazon Quick で、管理者がユーザー単位の index storage (インデックスストレージ) と agent hours (エージェント時間) の上限を設定できるようになりました。再利用可能な「limit profile」を作成し、ユーザー・ロール・アカウントの 3 レベルで割り当てられます。Quick の index storage は支払いアカウント単位でプールされるため、従来は 1 人のヘビーユーザーが共有容量を使い切り、$5/GB/月 の超過課金が発生する可能性がありました。本機能により、超過課金の抑止とサブスクリプション枠の配分管理ができます。Professional および Enterprise プランで、Quick のエージェント機能が利用できる全リージョンで提供されます。 Amazon Quick が共有に対する承認ポリシーをサポート Amazon Quick に、アセット共有時の承認ワークフローを強制する「承認ポリシー」機能が追加されました。管理者がポリシーを作成すると、対象ユーザーがナレッジベース、スペース、カスタムチャットエージェントを共有する際に、指定した承認者グループによるレビューと承認が必須になります。承認者はアセットの中身を実際に確認してから承認・却下でき、Submit / Approve / Deny / Revoke の全イベントが AWS CloudTrail に記録されます。機密データを扱う組織が、共有操作を統制・監査可能にするためのガバナンス機能です。 8/13(木) Amazon S3 がアクセス拒否エラーメッセージにポリシーの詳細情報を追加 Amazon S3 は、HTTP 403 Access Denied エラーメッセージに、拒否の原因となった IAM および AWS Organizations ポリシーの ARN を含めるようになりました。対象は同一アカウントまたは同一 Organization 内からのリクエストで、明示的拒否 (explicit deny) の場合に SCP、RCP、アイデンティティベースポリシー、セッションポリシー、Permissions Boundary の 5 種類のポリシー ARN が表示されます。従来はポリシータイプと拒否理由までしか分からず、同タイプのポリシーが複数存在する場合は 1 つずつ確認する必要がありましたが、今後はエラーメッセージから原因となったポリシーを直接特定できます。AWS GovCloud (US) リージョンと中国リージョンを含む全リージョンで利用できます。 AWS Certificate Manager が E メール検証から DNS 検証への切り替えに対応 AWS Certificate Manager (ACM) は、既存のパブリック TLS 証明書のドメイン検証方法を、証明書の再発行や ARN の変更なしに E メール検証から DNS 検証へ切り替えられるようになりました。背景には、CA/B Forum が 2025 年 11 月に決定した、2028 年 3 月 15 日付けのメール検証廃止があります。ACM は 2027 年 3 月 31 日に E メール検証証明書の新規発行を停止し、2027 年 9 月 30 日に更新も停止します。ARN が変わらないため、ロードバランサーや CI/CD パイプラインの既存の参照を修正せずに移行できます。ACM 証明書が利用可能なすべての AWS リージョンで利用できます。 Amazon Quick Microsoft 365 extensions が一般提供開始 Amazon Quick の Microsoft 365 extensions (Excel、PowerPoint、Word、Outlook) が 一般提供開始されました。各 Office アプリのサイドパネルから Quick のエージェントを呼び出し、ドキュメントのレッドライン、財務モデル構築、テンプレート準拠のスライド作成、受信トレイ管理などのタスクをアプリ内で直接実行できます。Quick Sight ダッシュボードや Salesforce などの企業データソースを参照した成果物作成に対応し、Plus (月額 20 USD/ユーザー) 以上のプランで追加ライセンスなしで利用できます。Word/Excel/PowerPoint は管理者設定なしで利用開始できますが、Outlook のフル機能には Microsoft Graph API のテナント全体の管理者同意が必要です。 AWS Client VPN が CLI、管理コントロール、接続の高速化に対応 AWS Client VPN のデスクトップクライアントが v6.0.x として再構築されました。新たに CLI (`aws-vpn-client`) が追加され、GUI と同等の全機能をコマンドラインから操作できます。これにより VPN 接続を CI/CD や IaC などの自動化ワークフローに組み込めます。また、企業向け管理コントロールにより、プロファイルのユーザー単位のスコープ設定、デバイス上の全ユーザー向けグローバルプロファイル、エンドユーザーのプロファイル管理権限の制御ができるようになりました。クライアントは OpenVPN3 ベースに再構築され、接続確立時間が改善されています。既存の Client VPN エンドポイントとの後方互換性は維持されており、エンドポイント側の変更は不要です。追加料金はありません。 8/14(金) AWS Billing and Cost Management が Managed Dashboards を発表 AWS Billing and Cost Management (BCM) Dashboards に、AWS が事前構成・保守する読み取り専用ダッシュボード「Managed Dashboards」が追加されました。Cost Overview & Trends、Compute、Database、Reservations、Savings Plans の 5 種類が提供され、自分のアカウントデータが最初から反映された状態でダッシュボード一覧に表示されるため、設定作業なしでコスト分析を開始できます。任意のダッシュボードを複製して編集可能なカスタムコピーを作成でき、PDF / CSV でのエクスポートにも対応します。全ての商用 AWS リージョンで追加料金なしで利用できます。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

みなさん、こんにちは。ソリューションアーキテクトの松永です。8 月に入り各地で猛暑が続いていますね。工場の現場では熱中症対策に神経を使う時期かと思います。少し先の話になりますが、年末の AWS re:Invent 2026 は 11 月 30 日から 12 月 4 日の開催で、早期割引の申し込み期限は 8 月 25 日です。夏のうちに社内調整を始めておくとちょうど良いタイミングかもしれません！今月は Amazon 自身のロボティクスの最前線をピックアップトピックとしてお届けしつつ、7 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 ピックアップトピック – Amazon のロボティクスに学ぶ、現場で動く AI 製造業のお客様と自動化についてお話ししていると、「どこまでロボットに任せられるのか」「導入した後に現場が使い続けられるのか」という 2 つの問いに行き着きます。実はこの 2 つは、Amazon 自身がフルフィルメントセンターという巨大な現場で向き合ってきた問いでもあります。今月は Amazon のロボティクスの取り組みを題材に、この問いへのヒントを 2 つの視点から探ってみます。 ロボットは「見る」から「感じる」「言葉で指示される」へ Amazon は 2012 年の Kiva Systems 買収以降、 100 万台を超えるロボット を配備してきました。注目したいのは台数ではなく、指示の与え方が進化してきた点です。搬送ロボットの Proteus は、床の符号マーカーに頼らずセンサーで周囲を認識して自律航行するため、人の立ち入りを制限したエリアを設けずに、人と同じ空間で 400 kg 近いカートを運べます。 2025 年に発表された Vulcan は、Amazon 初の触覚を持つロボットです。力覚フィードバックセンサーで押し付ける力を把握し、商品を壊さない範囲で棚の中をかき分けます。平均 10 点が詰まった棚から、対象品目の約 75% を従業員と同等の速度で扱えるとのことです。この能力は、シミュレーションではなく 実世界の接触データ で学習させて獲得されました。 そして 次世代の Proteus では、 自然言語で指示できる ようになりました。技術コマンドやプログラミングは不要で、優先順位や経路はロボット側が判断します（欧州展開は 2027 年上期予定）。土台にあるのはデータ基盤で、フリート全体を賢くする生成 AI 基盤モデル DeepFleet とオペレーター向けの agentic AI モデル Project Eluna も統合されています。 多品種少量で段取り替えが多い現場では、再プログラミングのコストが自動化の投資回収を難しくしてきました。ティーチングやラダーロジックではなく自然言語が操作インターフェースになる流れは、この構造そのものを変える可能性があります。 自動化の設計に、役割分担と人材投資まで含める もう 1 つの視点は、自動化を人の仕事の変化と一体で設計している点です。Vulcan が担うのは保管品目の約 75% で、残りは人に引き継ぎます。対象も脚立が必要だった約 8 フィートの上段と床付近で、人はエルゴノミクス上望ましい power zone の作業に集中できます。100% 自動化を目指さず、機械に任せる範囲を先に決める割り切りが導入の現実性を担保しています。協働型の搬送システム STARK は現場従業員の改善アイデアから生まれ、2027 年までに欧州 15 拠点への拡大が予定されています。 さらに 欧州での一連の発表 では、拠点の近代化に €10 billion 超という設備投資と、25,000 名の増員、Career Choice への 2030 年までの $1 billion のコミットがセットで語られています。対象分野にはメカトロニクスが明示されており、ロボット導入が保全・信頼性エンジニアという職種を必要とする実態と整合します。設備投資額と人材投資額を同時に示すアプローチは、労働力不足と技能継承を抱える日本の製造業が自動化を社内に説明する際のフレームとして参考になるのではないでしょうか。 直近で開催予定のイベント 9/4 – 9/8 IFA 2026 ヨーロッパ最大のコンシューマーエレクトロニクスの展示会が、ベルリンの Messe Berlin で開催されます。Amazon も Hub 27 にブースを出展予定です。 9/14 – 9/19 IMTS 2026 — International Manufacturing Technology Show 北米最大の工作機械の展示会が、シカゴの McCormick Place で開催されます。AWS もブースを出展予定です。会期中には、量子コンピューティングと製造業をテーマにした AWS 主催イベント「 Beyond AI: Quantum Meets Manufacturing — An IMTS Evening Reception 」も開催されます。 10/13 – 10/16 CEATEC 2026 10 月 13 日（火）から 16 日（金）まで幕張メッセで開催されます。主催は電子情報技術産業協会（JEITA）で、今年のテーマは「Transformation – 企業が、産業が、そして社会が変わる -」です。 AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。 ぜひブースにお立ち寄りください。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントが米国ネバダ州ラスベガスで開催されます。2,200 を超えるセッションが予定され、そのうち約 70% がインタラクティブな形式です。早期割引価格 $1,299（通常 $2,499）の申し込みは 8 月 25 日 23:59 PDT までですので、お早めにご確認ください！ 製造関連ブログのご紹介 7/1 Reduce P&ID analysis time by 80% with hybrid AI maintenance planning PDF の P&ID（配管計装図）から機器とタグを検出し、Amazon Neptune のグラフで依存関係を表現して保全影響を推論する構成です。パイロットでは計画時間を最大 80% 削減できたとのことで、図面資産の活用を検討されている方の参考になります。 7/6 東海旅客鉄道株式会社：超電導リニアの電気設備保守を支える IoT プラットフォームの構築 ※本記事は「事例のご紹介」でご紹介します。 7/15 【開催報告】AWS Summit Japan 2026 — AI エージェントで危機対応：小売×消費財の混乱を AI と人が即座に解決 サプライチェーンの外乱に対し、AI エージェントが影響分析と代替案提示を行い、人の承認を経て実行まで回すデモの実装解説です。分析専用と実行専用でサブエージェントを分ける設計は、現場でエージェントに実行を任せる際の指針になります。 7/16 AI で変える鉄道保全と、「クローズド」を読み解くクラウド設計 — AWS Summit Japan 2026 展示ブース開催報告 異常検知から調査、対応計画の提示、作業指示書の出力までを 4 ステップで実装した保全プラットフォームの報告です。「クローズドは必ずしも安全ではない」という後半の論点は、製造業の OT セキュリティ設計にそのまま読み替えられます。 7/17 ナレッジグラフと IoT データによる生産ラインのボトルネック分析 〜AI エージェントのための製造データの構造化〜 設備やサプライヤーの関係を Amazon Neptune のグラフに、サイクルタイムなどの変動値を AWS IoT SiteWise に分離する設計の解説です。ISA-95 との対応表もあり、データモデル設計の出発点として参考になります。 7/22 AWS Japan Summit 2026 スマートマシンデモ ー自律診断とリアルタイム安全監視ー 展示報告 建設機械のフリート遠隔監視を題材に、予知保全の 3 つのアプローチを比較しています。異常スコアで終わらず原因推定と対処指示まで生成するエージェントの挙動と、人と AI の役割分担の考え方をご覧いただけます。 7/24 ISA/IEC 62443 を踏まえた AWS での OT とクラウドの接続設計 産業用制御システムのセキュリティ規格を踏まえ、OT ネットワークとクラウドの接続方法を解説しています。工場データの収集を始める方にも、既存構成を監査対応の観点で見直したい方にも実務的な内容です。 事例のご紹介 7/6 東海旅客鉄道株式会社：超電導リニアの電気設備保守を支える IoT プラットフォームの構築 東海旅客鉄道株式会社（JR 東海）との共著記事です。山梨リニア実験線の電気設備で状態監視保全を実現するため、AWS 上に IoT プラットフォームを段階的に構築した事例です。AWS IoT Greengrass のコンポーネントがメーター値の読み取りや動作音の特徴量抽出、異常推論をエッジで実行し、クラウドには集計値と推論結果のみを送信します。学習からモデル配信までを Amazon SageMaker Pipelines と AWS Step Functions で自動化し、MLOps を IoT 運用に統合している点が秀逸です。設置環境が多様な拠点を抱える工場やプラントの保全高度化に参考になります。 製造関連の主要なサービスアップデート 7/20 KNFSD File Cache（プレビュー） AWS 上に高速な NFS キャッシュを構築するオープンソースソリューションです。オンプレミスの NFS エクスポートをマウントして AWS 内に再エクスポートし、頻繁に読むデータをメモリとローカル NVMe にキャッシュします。解析モデルがオンプレミスに残ったままでも CAE をクラウドにバーストできます。 7/23 Amazon Bedrock AgentCore のトレースとログが単一のロググループに統合 従来は分散していたトレースとイベントログが、エージェント単位の単一ロググループに統合されました。エージェントごとに IAM ポリシーとカスタマー管理キーによる暗号化を適用できます。プロンプトに図面や品質データが含まれるケースで鍵と権限を絞れるようになりました。 7/23 AWS Parallel Computing Service がノードライフサイクルアクションに対応 CAE や CFD の実行基盤として使われる Slurm ベースのマネージドサービスで、計算ノードのライフサイクルの任意の時点でカスタムスクリプトを自動実行できるようになりました。共有ストレージのマウントやライセンスサーバーへの接続を、独自 AMI に作り込まずに宣言的に構成できます。 7/24 Claude Opus 5 が Amazon Bedrock で利用可能に 長時間のエージェント処理を想定したモデルで、Bedrock 上ではゼロデータリテンションが既定で有効です。図面や仕様書の解析に適しており、設計情報を扱う際の社内審査を通しやすくする要素になります。同じ 7 月には OpenAI GPT-5.6 系モデルの値下げ も発表されました。 7/27 Amazon Neptune がタグベースアクセス制御（TBAC）に対応 リソースタグと IAM プリンシパルタグを条件に使い、グラフデータベースのデータプレーン操作を制御できるようになりました。クラスターの ARN を列挙せずにアクセス境界を運用できるため、BOM グラフを事業部別・拠点別に分離して運用する際のガバナンス手段になります。 7/27 AWS Glue Data Quality が異常検知とカタログへの結果書き込みに対応 しきい値のルールを書かずに、機械学習による時系列予測で「一意な値の急減」や「行数のスパイク」を検出できるようになりました。結果は Data Catalog に書き戻して SQL で照会できます。あわせて 分布統計への対応 も発表され、品質監査の証跡づくりに活用できます。 7/31 Context Ontology Accelerator が一般提供開始 今月の一番の注目です。企業の業務を機械可読なオントロジーとしてモデル化するオープンソースで、AI が起案し現場の専門家が承認したうえで、W3C 標準のナレッジグラフとして自社で保有します。付属の MCP サーバー経由で任意のエージェントから参照でき、Amazon Neptune と Amazon OpenSearch Serverless で構成されます。設備・工程・品質規格の定義が PLM や MES に散在する状況は多くの現場で共通の課題です。回答根拠がグラフとして追跡できるため、PoC で止まりがちだった工場の AI エージェントを監査可能な形で本番に載せる道筋になります。 最後まで読んでいただきありがとうございました。今月はロボットが「感じる」「言葉を理解する」ようになる話と、企業の業務知識を機械可読なグラフとして持つ話をお届けしました。現実世界で動く AI にはそれを支える文脈のデータが必要という点で、この 2 つは同じ方向を向いているように思います。来月も 月刊 AWS 製造ブログ をよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 松永 充弘 (Mitsuhiro Matsunaga) シニア ソリューションアーキテクト 製造業のお客様を担当するソリューションアーキテクトです。クラウド × データ × AI でお客様のビジネスを支援しています。前職では製造業にて、機器の IoT 化、AI 活用を担当していました。

本記事は 2026 年 3 月 23 日 に公開された「 Extract data from Amazon Aurora MySQL to Amazon S3 Tables in Apache Iceberg format 」を翻訳したものです。 Amazon Aurora MySQL-Compatible Edition でデータを管理していて、分析や機械学習 (ML)、サービス横断のクエリに活用できるモダンなレイクハウス形式で利用可能にしたい、という方は多いのではないでしょうか。 組織では分析の実行、ML モデルの構築、複数ソースのデータの結合が必要になることがよくあります。こうしたワークロードはリソースを大量に消費し、トランザクションデータベースで直接実行するのは現実的ではありません。Aurora MySQL のデータを Amazon S3 Tables に Apache Iceberg 形式で抽出すれば、本番データベースのパフォーマンスに影響を与えずに分析クエリをオフロードでき、分析に最適化されたフルマネージドの Iceberg テーブルストアにデータを保存できます。オープンな Apache Iceberg 標準に基づく Amazon Simple Storage Service (Amazon S3) Tables のデータは、 Amazon Athena 、 Amazon Redshift Spectrum 、 Apache Spark などのエンジンから追加のデータコピーなしでクエリできます。さらに、データレイクに既に存在する他のデータセットとリレーショナルデータを組み合わせることで、より充実したクロスドメインのインサイトを得られます。 Apache Iceberg と Amazon S3 Tables Apache Iceberg は、ACID トランザクション、スキーマの進化、タイムトラベル機能を提供する、広く採用されているオープンテーブル形式です。複数のエンジンが同一データセットに対して同時に処理できるため、オープンレイクハウスアーキテクチャの構築で広く選ばれています。 Amazon S3 Tables は、分析ワークロード向けに設計された専用のフルマネージド Apache Iceberg テーブルストアです。セルフマネージドの Iceberg テーブルと比較して、クエリパフォーマンスが最大 3 倍、1 秒あたりのトランザクション数が最大 10 倍に向上します。また、データの自動コンパクションと参照されていないファイルの自動削除により、ストレージとパフォーマンスが最適化されます。 本記事では、 Amazon Aurora MySQL Serverless v2 からテーブルを抽出し、 AWS Glue を使って Amazon S3 Tables に Apache Iceberg 形式で書き込む、エンドツーエンドの自動化ソリューションの構築方法を紹介します。インフラ全体を 1 つの AWS CloudFormation スタックでデプロイします。 課題 AWS は Amazon Aurora から Amazon Redshift や Amazon SageMaker AI へのゼロ ETL 統合を提供しており、分析や機械学習ワークロード向けにシームレスなデータフローを実現しています。 しかし、Amazon Aurora と Amazon S3 Tables 間にはまだネイティブな ゼロ ETL 統合がありません。そのため、レイクハウスアーキテクチャに Amazon S3 Tables を活用しようとする組織は、以下のような課題に直面します。 Amazon Aurora からデータを抽出し Apache Iceberg 形式に変換する ETL パイプラインの構築 プライベートサブネットの Amazon Aurora データベースにアクセスするための AWS Glue ジョブのネットワークとセキュリティの設定 ソースデータベース、ETL パイプライン、ターゲットテーブルストアのプロビジョニングの調整 ネイティブな自動化なしでのエンドツーエンドワークフローの管理 ソリューション概要 このソリューションでは、Amazon Aurora MySQL Serverless v2 のリレーショナルデータベーステーブルを AWS Glue 5.0 で Amazon S3 Tables に Apache Iceberg 形式で抽出する処理を自動化します。すぐに試せるように CloudFormation テンプレートを用意しています。このテンプレートでインフラのプロビジョニング、サンプルデータのロード、ETL パイプラインの設定がすべて完了します。独自のシナリオに合わせてテンプレートをカスタマイズできます。 サンプルデータ このソリューションでは TICKIT サンプルデータベース を使用します。Amazon Redshift のドキュメントで使われているよく知られたデータセットで、架空のチケット販売システムを 7 つの相互関連テーブル (users、venue、category、date、event、listing、sales) でモデル化しています。データセットは Amazon Redshift 入門ガイド に記載のとおり、一般公開されています。 ソリューションのフロー 前述のアーキテクチャ図に示したソリューションのフローは以下のとおりです。 AWS Lambda 関数が TICKIT サンプルデータセット (Amazon Redshift ドキュメントで使用されている架空のチケット販売システム) をパブリックな Amazon S3 バケットからステージング用 S3 バケットにダウンロードします。 2 番目の Lambda 関数が PyMySQL (Python の MySQL クライアントライブラリ) を使用し、 LOAD DATA LOCAL INFILE でステージング済みデータファイルを Aurora MySQL Serverless v2 データベースにロードします。 AWS Glue ジョブがネイティブな MySQL 接続で Aurora MySQL から 7 つの TICKIT テーブルを読み取り、SigV4 認証を使って S3 Tables REST カタログエンドポイント経由で Amazon S3 Tables に Apache Iceberg 形式で書き込みます。 移行されたデータは Amazon Athena で S3 Tables に対してクエリできます。 このソリューションは以下の主要コンポーネントで構成されます。 TICKIT サンプルデータセット (users、venue、category、date、event、listing、sales テーブル) を格納するソースリレーショナルデータベースとしての Amazon Aurora MySQL Serverless v2 Aurora MySQL データベースの認証情報を安全に保存する AWS Secrets Manager パブリックな redshift-downloads S3 バケットからダウンロードした TICKIT サンプルデータファイルのステージング用 Amazon S3 バケット PyMySQL を使って Aurora MySQL にデータをロードする AWS Lambda 関数 Aurora MySQL からテーブルを読み取り S3 Tables に Apache Iceberg 形式で書き込む AWS Glue 5.0 ジョブ (PySpark) 移行された Iceberg テーブルのターゲットストレージとしての Amazon S3 Tables プライベートサブネットと Amazon S3、S3 Tables、AWS Glue、Secrets Manager、AWS Security Token Service (AWS STS)、CloudWatch Logs、CloudFormation 用の VPC エンドポイントを備えた Amazon VPC このアーキテクチャの主な利点は以下のとおりです。 完全自動化されたセットアップ: 1 つの CloudFormation スタックでインフラのプロビジョニング、サンプルデータのロード、ETL パイプラインの設定が完了します。 サーバーレスでコスト効率に優れた構成: Aurora MySQL Serverless v2 と AWS Glue はどちらも需要に応じてスケールし、アイドル時のコストを最小限に抑えます。 Apache Iceberg テーブル形式: データは Apache Iceberg 形式で保存され、ACID トランザクション、スキーマの進化、タイムトラベルクエリが利用できます。 ネットワーク分離と認証情報管理: リソースはプライベートサブネット内で VPC エンドポイント経由で動作し、データベース認証情報は AWS Secrets Manager で管理されます。 拡張可能なパターン: 同じアプローチを他のリレーショナルデータベース (PostgreSQL、SQL Server) や AWS Glue がサポートする他のターゲット形式にも適用できます。 前提条件 この手順を進めるには AWS アカウントが必要です。まだ AWS アカウント をお持ちでない場合は作成してください。CloudFormation スタックのデプロイには約 30〜45 分 かかり、 Amazon S3 Tables 、 AWS CloudFormation 、 Apache Iceberg 、 AWS Glue 、 Amazon Aurora に関する基本的な知識が必要です。このソリューションは AWS のコストが発生します。主なコスト要因は AWS Glue ETL ジョブの実行 (DPU 時間あたりの課金、データ量に比例) と Amazon S3 Tables のストレージおよびリクエスト料金です。不要になったらリソースをクリーンアップしてください。 CloudFormation パラメータ CloudFormation スタックのデプロイ前に以下のパラメータを設定できます。 パラメータ 説明 デフォルト値 必須 S3TableBucketName 作成する (既存のものを使用する場合はその) S3 Tables バケット名 はい DatabaseName Aurora MySQL の初期データベース名 tickit いいえ MasterUsername Aurora MySQL のマスターユーザー名 admin いいえ VpcCidr VPC の CIDR ブロック 10.1.0.0/16 いいえ S3TableNamespace S3 Tables の Namespace tickit いいえ 実装ウォークスルー 以下の手順で実装を進めます。ゼロからエンドツーエンドのソリューションをデプロイしてテストする手順です。すでに一部のコンポーネントを実行している場合は、該当するステップに進んでください。ソリューション全体は aws-samples リポジトリの sample-to-write-aurora-mysql-to-s3tables-using-glue も参照できます。 ステップ 1: CloudFormation スタックのデプロイ CloudFormation テンプレート scripts/aurora-mysql-to-s3tables-stack.yaml を AWS マネジメントコンソールまたは AWS Command Line Interface (AWS CLI) でデプロイします。S3 Tables バケット名を指定すると、スタックが自動的に作成します (既存のバケットがある場合はそれを使用します)。 AWS マネジメントコンソール(推奨)でデプロイする場合、AWS CloudFormation コンソールに移動して CloudFormation テンプレートを使用します。AWS CLI でデプロイする場合は、まずテンプレートを S3 バケットにアップロードします (テンプレートはインライン ‐‐template-body の 51,200 バイト制限を超えるため)。その後スタックを作成します。 # Upload the template to S3 aws s3 cp scripts/aurora-mysql-to-s3tables-stack.yaml \ s3://<your-s3-bucket>/aurora-mysql-to-s3tables-stack.yaml \ --region <your-region> # Create the stack using the S3 template URL aws cloudformation create-stack \ --stack-name aurora-mysql-tickit-stack \ --template-url https://<your-s3-bucket>.s3.<your-region>.amazonaws.com/aurora-mysql-to-s3tables-stack.yaml \ --parameters \ ParameterKey=S3TableBucketName,ParameterValue=<your-s3-table-bucket-name> \ --capabilities CAPABILITY_NAMED_IAM \ --region <your-region> スタックは以下を自動的に実行します。 S3 Tables バケットの作成 (既存の場合はそのまま使用) プライベートサブネットと VPC エンドポイントを含む VPC の作成 Aurora MySQL Serverless v2 クラスターのプロビジョニング パブリックな Amazon S3 バケットから TICKIT サンプルデータのダウンロード PyMySQL を使った Lambda 関数による Aurora MySQL へのサンプルデータのロード S3 Tables に Iceberg 形式でデータを移行する Glue ジョブの作成 注記: S3 Tables バケットはスタック削除時にも保持され、データが保護されます。 ステップ 2: Aurora MySQL データの確認 CloudFormation スタックから AuroraClusterEndpoint、DatabaseName、SecretArn の値を取得してメモします。Amazon Aurora コンソールの Query Editor に移動し、CloudFormation スタックの値を入力して接続できます。 Amazon Aurora DB クラスターへの接続 で好みの方法を選択することもできます。 AWS CLI でスタック出力を取得するには以下を実行します。 aws cloudformation describe-stacks --stack-name aurora-mysql-tickit-stack --region <your-region> --query "Stacks[0].Outputs" 次の SQL コマンドでデータロードを確認します。 -- Verify if the tables are created SELECT * FROM information_schema.tables WHERE table_schema = 'tickit'; -- Verify if the data is loaded SELECT 'users' AS table_name, COUNT(*) AS record_count FROM tickit.users UNION ALL SELECT 'venue', COUNT(*) FROM tickit.venue UNION ALL SELECT 'category', COUNT(*) FROM tickit.category UNION ALL SELECT 'date', COUNT(*) FROM tickit.date UNION ALL SELECT 'event', COUNT(*) FROM tickit.event UNION ALL SELECT 'listing', COUNT(*) FROM tickit.listing UNION ALL SELECT 'sales', COUNT(*) FROM tickit.sales; ステップ 3: Glue ジョブの実行 AWS Glue コンソールに移動し、左パネルの Data Integration and ETL から ETL jobs を選択します。AWS Glue ジョブ mysql-tickit-to-iceberg-job を選択して Run job をクリックし実行を開始します。AWS CLI で ETL ジョブを開始することもできます。 aws glue start-job-run --job-name mysql-tickit-to-iceberg-job --region <your-region> AWS Glue ジョブは 7 つの TICKIT テーブルそれぞれに対して以下の処理を実行します。 ネイティブな MySQL Glue 接続で Aurora MySQL からテーブルを読み取り Spark DataFrame に変換 USING ICEBERG 句を指定した CREATE TABLE IF NOT EXISTS で S3 Tables Namespace に Iceberg テーブルを作成 INSERT INTO (テーブルが既に存在する場合は INSERT OVERWRITE) でデータを挿入 レコード数の検証とサンプルデータの表示 ステップ 4: 結果の確認 AWS Glue ジョブの完了後、Amazon S3 コンソールに移動して S3 Table バケットにテーブルが作成されたことを確認します。Buckets の Table buckets を選択し、S3 Table バケットを選びます。AWS CLI でも確認できます。 aws s3tables list-tables \ --table-bucket-arn arn:aws:s3tables:<your-region>:<your-account-id>:bucket/<your-s3-table-bucket-name> \ --namespace tickit \ --region <your-region> tickit Namespace のテーブルを選択し、 Preview をクリックしてデータを確認します。 Amazon Athena で移行されたテーブルに対してクエリを実行し、データを検証することもできます。 リソースのクリーンアップ 不要になったリソースは忘れずにクリーンアップし、不必要な料金の発生を防いでください。 CloudFormation コンソールでスタックを検索し、 Delete を選択します。AWS CLI でも削除できます。 aws cloudformation delete-stack --stack-name aurora-mysql-tickit-stack --region <your-region> S3 Tables バケットはデフォルトで保持されます。削除する場合は Amazon S3 コンソールまたは AWS CLI で Table バケットを個別に削除してください。ステージング用 S3 バケットはスタック削除時に自動的に空にされて削除されます。 aws s3tables delete-table-bucket --table-bucket-arn arn:aws:s3tables:<your-region>:<your-account-id>:bucket/<your-s3-table-bucket-name> --region <your-region> まとめ 本記事では、Amazon Aurora MySQL Serverless v2 からデータを抽出し、AWS Glue 5.0 を使って Amazon S3 Tables に Apache Iceberg 形式で書き込む方法を紹介しました。AWS Glue のネイティブな Iceberg サポートと S3 Tables REST カタログエンドポイントを活用することで、リレーショナルデータベースとモダンなレイクハウスストレージ形式の間のギャップを埋められます。CloudFormation でパイプライン全体を自動化することで、複数環境へのセットアップと展開を迅速に行えます。 AWS Glue と Amazon S3 Tables は今後も進化を続けるため、この自動化された移行パターンを維持しながら将来の機能強化を活用できます。 ご質問やご提案がありましたら、コメントをお寄せください。 著者について Kunal Ghosh Kunal は、AWS のシニアソリューションアーキテクトです。生成 AI、分析、データサイエンス、機械学習を活用した効率的で効果的なソリューション構築に情熱を注いでいます。家族との時間のほか、読書、水泳、サイクリング、映画鑑賞が趣味です。 Arghya Banerjee Arghya は、サンフランシスコ・ベイエリアの AWS シニアソリューションアーキテクトです。お客様の AWS Cloud 導入と活用を支援しています。ビッグデータ、データレイク、ストリーミングおよびバッチ分析サービス、生成 AI テクノロジーを専門としています。 Indranil Banerjee Indranil は、サンフランシスコ・ベイエリアの AWS シニアソリューションアーキテクトです。ハイテクおよび半導体セクターのお客様が AWS Cloud を使用してビジネス課題を解決するのを支援しています。レガシーモダナイゼーションと移行、分析プラットフォームの構築、生成 AI などの最先端テクノロジーの導入支援を専門としています。 Vipan Kumar Vipan は、AWS のシニアソリューションアーキテクトです。戦略的なお客様を担当しています。機械学習と生成 AI に豊富な経験を持ち、アプリケーション開発のバックグラウンドを活かして、クラウド向けエンタープライズアプリケーションの設計と構築に情熱を注いでいます。 この記事は、Solutions Architect の Shinya Sugiyama が翻訳を担当しました。