re:Invent 2025 において、AWS の Vice President of Databases である Colin Lazier は、アイデアのスピードで構築することの重要性を強調しました。これは、コンセプトから稼働中のアプリケーションまでの道のりを迅速に進めることを可能にするものです。お客様は既に、本番対応の Amazon DynamoDB テーブルと Amazon Aurora DSQL データベースを数秒で作成できます。Colin は、同じスピードで Amazon Aurora サーバーレス データベースを作成できることを 事前公開 し、その後、お客様からこの機能への迅速なアクセスとスピードを求める声が寄せられました。 2025 年 3 月 25 日、Amazon Aurora PostgreSQL 向けの新しいエクスプレス設定の一般提供の開始をお知らせします。これは、数秒で使用を開始するのに役立つよう設計された事前設定済みのデフォルト設定を備えた、合理化されたデータベース作成エクスペリエンスです。 わずか 2 回クリックするだけで、Aurora PostgreSQL サーバーレスデータベースを使用する準備が数秒で整います。新しい設定では、データベースの作成中および作成後に、特定の設定を柔軟に変更できます。例えば、作成時にサーバーレスインスタンスのキャパシティ範囲を変更したり、リードレプリカを追加したり、データベースが作成された後にパラメータグループを変更したりできます。 エクスプレス設定を備えた Aurora クラスターは、 Amazon Virtual Private Cloud (Amazon VPC) ネットワークなしで作成され、お気に入りの開発ツールからのセキュアな接続のためのインターネットアクセスゲートウェイを含みます。VPN や AWS Direct Connect は不要です。また、エクスプレス設定では、管理者ユーザーのために AWS Identity and Access Management (IAM) 認証がデフォルトでセットアップされるため、追加設定なしで最初からパスワードレスデータベース認証が有効になります。 作成後、高可用性や自動フェイルオーバー機能のための追加のリードレプリカのデプロイなど、Aurora PostgreSQL サーバーレスで使用可能な機能にアクセスできます。今回のリリースでは、Aurora 向けの新しいインターネットアクセスゲートウェイルーティングレイヤーも導入されました。新しいサーバーレスインスタンスでは、この機能はデフォルトで有効になっています。これにより、幅広い開発ツールから PostgreSQL ワイヤプロトコルを使用して、世界中のどこからでも、アプリケーションがインターネット経由でセキュアに接続できます。このゲートウェイは複数のアベイラビリティゾーンに分散されており、Aurora クラスターと同等の高可用性を提供します。 Aurora の作成と接続が数秒で完了するということは、Aurora の利用を開始する方法は根本的に変わります。弊社は、Aurora を利用したアプリケーションのオンボーディングと実行をサポートするために、連携して動作する複数の機能をリリースしました。Aurora は AWS 無料利用枠 で現在利用可能です。これにより、初期費用なしで Aurora を実際に体験できます。作成後、 AWS CloudShell で Aurora データベースを直接クエリしたり、Aurora 用の新しいインターネットアクセス可能なルーティングコンポーネントを介してプログラミング言語やデベロッパーツールを使用したりできます。 Vercel の v0 などの統合により、自然言語を使用して、Aurora の機能とメリットを活用したアプリケーションの構築を開始できます。 Aurora PostgreSQL サーバーレスデータベースを数秒で作成 利用を開始するには、 Aurora および RDS コンソール にアクセスし、ナビゲーションペインで [ダッシュボード] を選択します。その後、ロケットアイコンの付いた [作成] を選択します。 [エクスプレス設定で作成] ダイアログボックスで、事前構成済みの設定を確認します。必要に応じて、DB クラスター識別子またはキャパシティ範囲を変更できます。 [データベースを作成] を選択します。 また、パラメータ --express-configuration を設定して AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を使用することで、単一の API コールでクラスターとクラスター内のインスタンスの両方を作成できます。これにより、数秒でクエリを実行できる状態になります。詳細については、「 Creating an Aurora PostgreSQL DB cluster with express configuration 」にアクセスしてください。 クラスターを作成するための CLI コマンドを次に示します: $ aws rds create-db-cluster --db-cluster-identifier channy-express-db \ --engine aurora-postgresql \ –with-express-configuration Aurora PostgreSQL サーバーレスデータベースは数秒で準備完了となります。作成が完了すると成功バナーが表示され、データベースのステータスが [使用可能] に変わります。 データベースの準備が完了したら、 [接続とセキュリティ] タブに移動して、3 つの接続オプションにアクセスします。SDK、API、またはエージェントなどのサードパーティーツール経由で接続する場合は、 [コードスニペット] を選択します。.NET、Golang、JDBC、Node.js、PHP、PSQL、Python、TypeScript など、さまざまなプログラミング言語を選択できます。各ステップのコードをツールに貼り付けてコマンドを実行できます。 例えば、次の Python コードは認証設定を反映するために動的に生成されます: import psycopg2 import boto3 auth_token = boto3.client('rds', region_name='ap-south-1').generate_db_auth_token(DBHostname='channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', Port=5432, DBUsername='postgres', Region='ap-south-1') conn = None try: conn = psycopg2.connect( host='channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port=5432, database='postgres', user='postgres', password=auth_token, sslmode='require' ) cur = conn.cursor() cur.execute('SELECT version();') print(cur.fetchone()[0]) cur.close() except Exception as e: print(f"Database error: {e}") raise finally: if conn: conn.close() const { Client } = require('pg'); const AWS = require('aws-sdk'); AWS.config.update({ region: 'ap-south-1' }); async function main() { let password = ''; const signer = new AWS.RDS.Signer({ region: 'ap-south-1', hostname: 'channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port: 5432, username: 'postgres' }); password = signer.getAuthToken({}); const client = new Client({ host: 'channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port: 5432, database: 'postgres', user: 'postgres', password, ssl: { rejectUnauthorized: false } }); try { await client.connect(); const res = await client.query('SELECT version()'); console.log(res.rows[0].version); } catch (error) { console.error('Database error:', error); throw error; } finally { await client.end(); } } main().catch(console.error); コンソールから直接起動する AWS CLI に迅速にアクセスするには、 [CloudShell] を選択します。[ CloudShell を起動] を選択すると、特定のクラスターに接続するための関連情報がコマンドに事前に入力されていることが確認できます。シェルに接続すると、SQL コマンドを実行するための psql login と postgres => prompt が表示されます。 pgAdmin など、ユーザー名とパスワードの認証情報のみをサポートするツールを使用する場合は、 [エンドポイント] を選択することもできます。 [トークンを取得] を選択すると、ユーティリティによって生成された AWS Identity and Access Management (IAM) 認証トークンがパスワードフィールドに使用されます。このトークンは、データベースの作成時にセットアップするマスターユーザー名について生成されます。トークンは 1 回につき 15 分間有効です。使用しているツールが接続を終了した場合、トークンを再生成する必要があります。 Aurora データベースを利用してアプリケーションをより迅速に構築 re:Invent 2025 では、 AWS 無料利用枠プログラムの強化を発表し 、AWS サービス全体で使用できる最大 200 USD 相当の AWS クレジットを提供しました。サインアップ時に 100 USD 相当の AWS クレジットが付与され、Amazon Relational Database Service (Amazon RDS)、AWS Lambda、Amazon Bedrock などのサービスを利用することで、さらに 100 USD 相当のクレジットを獲得できます。さらに、Amazon Aurora は、対象となる一連の幅広い 無料利用枠データベースサービス でご利用いただけるようになりました。 デベロッパーは、自然言語だけで本番対応のアプリケーションを構築できる Vercel などのプラットフォームを採用しています。弊社は、 Vercel Marketplace との統合を発表しました 。これにより、Vercel から AWS データベースを数秒で直接作成して接続できるようになります。また、AI を利用したツールである Vercel の v0 との統合も発表しました。v0 は、数分でアイデアを本番対応のフルスタックウェブアプリケーションに変換します。これには、Aurora PostgreSQL、Aurora DSQL、DynamoDB データベースが含まれています。また、Vercel を利用してエクスプレス設定を通じて作成した既存のデータベースも接続できます。詳細については、「 AWS for Vercel 」にアクセスしてください。 Vercel と同様に、当社はデータベースをそれらのエクスペリエンスとシームレスに統合し、広く普及しているフレームワーク、AI アシスタントコーディングツール、環境、デベロッパーツールと直接統合して、アイデアのスピードで開発を進めることを可能にしています。 さらに、 Kiro powers との Aurora PostgreSQL 統合 も導入しました。デベロッパーはこれを利用して、 Kiro を通じた AI エージェント支援開発を活用することで、Aurora PostgreSQL を利用するアプリケーションをより迅速に構築できます。Aurora PostgreSQL 向けの Kiro power は、 Kiro IDE 内で、または Kiro powers のウェブページ から、ワンクリックでインストールして使用できます。この Kiro Power の詳細については、「 Introducing Amazon Aurora powers for Kiro 」および「 Amazon Aurora Postgres MCP Server 」をお読みください。 今すぐご利用いただけます Aurora PostgreSQL サーバーレスデータベースは、すべての AWS 商用リージョンで数秒で今すぐ作成できます。リージョンごとの利用可否と今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 お支払いいただくのは、Aurora Capacity Units (ACU) に基づいて消費したキャパシティについての料金のみであり、キャパシティがゼロの状態から秒単位で課金されます。アプリケーションのニーズに基づいて、キャパシティが自動的に起動、シャットダウン、スケールアップ、スケールダウンされます。詳細については、 Amazon Aurora の料金ページ にアクセスしてください。 Aurora および RDS コンソール でお試しいただき、 AWS re:Post for Aurora PostgreSQL に、または通常の AWS サポート担当者を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

インシデント発生時の根本原因分析は、クラウドアプリケーション運用において最も時間がかかり、ストレスの大きい作業の一つです。エンジニアは複数のサービスにまたがるテレメトリデータを迅速に相関づけ、デプロイ履歴を確認し、複雑なアプリケーションの依存関係を把握しなければなりません。しかもそのすべてを、サービス復旧というプレッシャーの中で行う必要があります。AWS DevOps Agent は、運用チームに自律的な調査能力をもたらすことでこのパラダイムを変革し、平均復旧時間 (MTTR) を数時間から数分に短縮します。 ただし、AWS DevOps Agent の効果は、リソースアクセスの境界を制御する Agent Space の設定に大きく左右されます。Agent Space の範囲が狭すぎると、調査中に重要なコンテキストを見逃してしまいます。逆に広すぎると、パフォーマンスのオーバーヘッドや複雑さが増大します。本記事では、調査能力と運用効率のバランスを取る Agent Space のセットアップに関するベストプラクティスを、早期に導入いただいたお客様のオンボーディングや社内チームでの DevOps Agent 活用経験をもとに紹介します。 本記事を読み終えると、最適な調査精度を実現するための Agent Space の構成方法、適切なリソースアクセス範囲の決定方法、そして Infrastructure as Code (IaC) を活用したデプロイの効率化について理解できるようになります。まずは、これらすべてを可能にする基本概念である Agent Space そのものについて理解しましょう。 Agent Space とは何か、なぜ重要なのか Agent Space は、AWS DevOps Agent がアクセスおよび調査できる範囲を定義する論理的なコンテナです。エージェントの運用範囲と考えてください。どのクラウドアカウントをエージェントがクエリできるか、どのサードパーティ統合が利用可能か、誰が調査に関与できるかを決定します。 Agent Space が重要なのは、AWS DevOps Agent が正確な根本原因分析を行うために十分なコンテキストを必要とするからです。 インシデントが発生すると、エージェントは以下の処理を実行します。 アカウント全体のリソースとその関係性を学習します。 ログ、メトリクス、トレースからテレメトリデータを相関分析します。 デプロイや設定変更を含む最近の変更をレビューします。 追加のデータソースにクエリを行い、仮説を生成・検証します。 図1: Agent Space トポロジー Agent Space に重要なアカウントや統合へのアクセスが含まれていない場合、エージェントは根本原因を完全に見逃す可能性があります。逆に、Agent Space が広すぎる場合、調査中にエージェントがより多くのリソースの組み合わせを考慮するため、パフォーマンス上の課題が生じます。 スコープとパフォーマンスのトレードオフを理解することが不可欠です。問いはこうなります。“自組織の運用モデルに適した境界をどのように決めれば良いのでしょうか？“ パート1：Agent Space アーキテクチャの設計 Agent Space の境界は、オンコールの責任範囲と同じように考えることを推奨します。アプリケーションに関連するアカウントへのアクセスを付与しつつ、本番環境と非本番環境は分離します。 このアプローチには以下のメリットがあります。 理解しやすい考え方: 運用チームはすでにオンコールの境界を理解しています。 適切な調査スコープ: 人間のエンジニアがインシデントを調査する方法を反映しています。 Two-way door (可逆的) な決定: 必要に応じて Agent Space のスコープを拡大・縮小できます。 パフォーマンスのバランス: エージェントに過剰な情報を与えることなく、十分なコンテキストを提供します。 Agent Space の境界を決定する まず、アプリケーションアーキテクチャを Agent Space の境界にマッピングし、以下の質問を検討します。 何をもって 1 つの論理的なアプリケーションと見なすか？ チームが複数の独立したアプリケーションを所有している場合は、別々の Agent Space を作成します。ただし、アプリケーションが密結合（例：相互依存するマイクロサービス）で、単一のリゾルバーグループ（オンコール担当グループ）にマッピングされる場合は、グループごとに1つの Agent Space を検討します。 複数のアカウントにまたがるモノリスの場合は、クロスアカウントアクセスを持つ1つの Agent Space が適切です。 オンコールローテーションはどのように編成されているか？ 本番と非本番で別々のチームがある場合は、別々の Agent Space を推奨します。 1つのチームがすべての環境を担当する場合は、アプリケーションごとに1つの Agent Space で対応できます。 調査パターンはどうなっているか？ 本番インシデントで他のアカウントの依存サービスへのクエリが必要な場合は、それらのアカウントを含めます。 環境が完全に分離されている場合は、Agent Space も分離します。 決定ツリーの例: アプリケーション：Eコマースプラットフォーム ├── 本番環境 │ ├── アカウント 111111111111（フロントエンド） │ ├── アカウント 222222222222（API Gateway + Lambda） │ └── アカウント 333333333333（RDS + DynamoDB） ├── ステージング環境 │ └── アカウント 444444444444（全リソース） └── 開発環境 └── アカウント 555555555555（全リソース） 推奨 Agent Space： → "EcommerceProd"（アカウント 111111111111, 222222222222, 333333333333） → "EcommerceNonProd"（アカウント 444444444444, 555555555555） 図2. Agent Spaceの境界はオンコールチームの責任範囲を反映する 一般的な Agent Space パターンと判断ポイント 基本的な単一アプリケーションパターン以外にも、慎重な検討が必要なより複雑なシナリオがあります。以下は、お客様が実際に採用して成功しているパターンです。 パターン1: 複数チームにまたがる調査 大規模な組織で複数のチーム（例：100以上の本番アカウントを管理する3チーム）がある場合、チームAのインフラストラクチャで問題が発生しても、根本原因がチームBのサービスにあるという状況が発生します。問題は、Agent Space 間のコラボレーションをどのように実現するかです。 推奨アプローチ： 共有リソースアカウント（依存先など）への読み取り専用アクセスを含むアプリケーション固有の Agent Space を作成します。明確なオンコールエスカレーション手順を確立し ランブック として追加します。これは根本原因がチームにまたがる場合、効率的なコミュニケーション（例： Slack )に有用です。共有サービスチームのリソースには、どのアプリケーションが使用しているかを識別するタグ（例： app-id: ecommerce-frontend ）を設定します。一貫したタグ付け戦略に従うことで、明確なリソース所有権を維持しながら、共有リソースの調査コンテキストを提供できます。 パターン2: 共有サービスとネットワークオペレーションセンター (NOC) チーム 一部の組織には、組織全体の複数のアプリケーションで使用される共有インフラストラクチャサービス（データベース、ネットワーク、モニタリング、セキュリティ）を提供・サポートする集中型チームがあります。これらの NOC や中央運用チームは、すべてのアプリケーションの Agent Space にアクセスすることなく、自分たちのサービスへの可視性を必要とします。 推奨アプローチ： 共有サービスチーム専用の Agent Space を作成し、チームのインフラストラクチャと運用責任をスコープに設定します： 共有データベース、ネットワークインフラストラクチャ、集中ログ、モニタリングシステムを含む AWS アカウントを含めます。 チームがサポートする特定のリソースへの読み取り専用アクセスを提供する IAM ロールを設定します。 共有サービス固有のランブックと運用手順を含めます。 これは、アプリケーション固有の Agent Space と同じ原則に従います。Agent Space がスコープとして複数のアプリケーションにまたがる場合でも、オンコールチームごとに1つの Agent Space です。 パターン3: 多数のアプリケーションを管理する中央運用チーム 共有サービスチームが特定のインフラストラクチャドメインを管理する一方で、SRE チームはさらに大きな課題に直面することがあります。エンタープライズ規模で数百から数千のアプリケーションに対する運用責任です。運用ツールを担当する中央運用チームは、Infrastructure as Code を使用して Agent Space を大規模に効率的に管理できます。 推奨アプローチ： 出発点として、AWS CDK または Terraform のサンプルを使用します。これらのサンプルにより、チームは以下が可能になります。 組織で必要な IAM ロール、統合、リソース境界を含む標準化された Agent Space テンプレートを定義できます。 アプリケーションオンボーディングワークフローの一部として Agent Space をプログラムでデプロイできます。 AWS Config ルールやサービスコントロールポリシーを通じてコンプライアンスを強制できます。 統合された請求とタグ付け（application-id、team、cost-center、environment）を通じてすべての Agent Space を追跡できます。 中央運用チームがテンプレートとガバナンスポリシーを管理し、アプリケーションチームはそのガードレール内で運用します。このアプローチは、一貫した設定と自動デプロイにより、数千のアプリケーションにスケールします。AWS DevOps Agent は、 AWS アカウント内のエージェントアクセスの制限 と、チームが大規模に Agent Space アクセスを管理するためのオペレーターコンソールへの アクセス制御 を可能にします。 図3: Infrastructure as Code を使用したエンタープライズスケールパターン Agent Space の境界をチーム構造とスケール要件に合わせて設計する方法を理解したところで、これらのアーキテクチャパターンを実現するための実践的な実装手順を見ていきましょう。 パート2: Agent Space アーキテクチャの実装 このセクションでは、最初の Agent Space を作成するための実践的な手順を説明します。前提条件の確認、アカウント間の IAM ロール設定、オブザーバビリティツールの統合、アクセス制御の設定、そして調査に必要なコンテキストが確保されていることを確認するためのテストまでを網羅します。 ステップ1: Agent Space の前提条件 最初の Agent Space をセットアップする前に、以下を確認してください。 AWS アカウント: アプリケーションリソースが稼働する AWS アカウントが少なくとも1つ必要です。 IAM 権限: アカウント間で IAM ロールとポリシーを作成するための十分なアクセス権。AWS DevOps Agent には2つの異なる IAM 権限セットが必要です。 Agent Space ロール権限: AWS DevOps Agent が AWS リソースのクエリ、CloudWatch Logs へのアクセス、トポロジーの検出のために引き受ける IAM ロール。このロールには AIOpsAssistantPolicy マネージドポリシーに加え、AWS Support と拡張機能のための追加権限が必要です。完全なロール設定については CLI オンボーディングガイド を参照してください。 オペレーターアプリロール権限: 人間のオペレーターが AWS DevOps Agent Web アプリケーションで実行できる操作（調査の開始、結果の表示、AWS Support ケースの作成など）を制御する IAM ロール。このロールはエージェントの調査権限とは別です。 サービスコントロールポリシー (SCP): 組織の SCP が AWS DevOps Agent の API アクションを許可していることを確認してください。よくあるトラブルとして、チームが Agent Space のセットアップを完了しても、SCP が aidevops:* アクションや bedrock:InvokeModel アクションをブロックしているために調査が失敗するケースがあります。AWS Organization の SCP を確認し、必要に応じて DevOps Agent の例外を追加してください。なお、DevOps Agent と Amazon Bedrock の推論は、お客様のコンテンツを特定の AWS リージョンに制限するポリシーの影響を受けません。Bedrock は米国東部（バージニア北部）以外の米国リージョンをステートレス推論に使用する場合があります。 オブザーバビリティツール: 最低限、Amazon CloudWatch (IAM ロールが適切に設定されていれば自動的に利用可能) と Amazon CloudTrail を利用します。包括的な調査のためには、Datadog、Dynatrace、New Relic、Grafana、Splunk などのアプリケーションパフォーマンスモニタリングツールを統合してください。サポートされている統合については テレメトリソースの接続 を参照してください。 サードパーティ統合設定の理解: 一部のサードパーティツールには2段階の設定プロセスが必要です。 アカウントレベルの登録 : OAuth を使用するツール（GitHub、Dynatrace など）は、まず DevOps Agent コンソールを通じて AWS アカウントレベルで登録する必要があります。これにより、アカウント内のすべての Agent Space で共有される OAuth 認証情報が確立されます。 Agent Space レベルの関連付け: 登録後、各 Agent Space はそのツールから使用するリソースを個別に指定します。例えば、GitHub を一度登録した後、Agent Space「EcommerceProd」には本番リポジトリのみを関連付ける一方、Agent Space「EcommerceNonProd」には開発リポジトリを関連付ける、ということが可能です。Datadog、New Relic、Splunk などの他のツールは、API キーやトークンを使用して、別途アカウントレベルの登録なしに Agent Space に直接関連付けることができます。CloudWatch は IAM ロール以外の追加設定は不要です。 ソースコントロール: コードコンテキストとデプロイの相関分析のための GitHub または GitLab リポジトリアクセスを推奨します (オプションだが強く推奨)。 IaC ツール: Agent Space デプロイ用の AWS CDK（TypeScript/Python）、Terraform、AWS CLI、または AWS マネジメントコンソール。 前提条件の確認が完了したら、Agent Space を作成し、調査を可能にする IAM 信頼関係を確立する準備が整います。 ステップ2: Agent Space の作成 AWS DevOps Agent は、Agent Space の境界内にある各 AWS アカウントに IAM ロールを必要とします。エージェントはこれらのロールを引き受けて、CloudWatch Logs のクエリ、リソース情報の取得、アプリケーショントポロジーの構築を行います。 AWS DevOps Agent は、設定された Agent Space 内でアクセスを許可したすべての AWS アカウントの複数の AWS リージョンから運用データを取得するように設計されており、地理的なデプロイ場所に関係なく、分散インフラストラクチャとアプリケーションへの包括的な可視性を実現します。複数アカウントのサポートは、セカンダリアカウントで適切な信頼ポリシーと権限を持つ IAM ロールを作成する設定プロセスを通じて行われます。 オプション A: AWS コンソールウィザードを使用する AWS DevOps Agent コンソール に移動し、「Agent Space の作成」を選択して、ガイド付きセットアップに従い、各ターゲットアカウントに IAM ロールを作成します。 図4: コンソールでの Agent Space の作成 セットアップウィザードは、クロスアカウント信頼関係の設定を支援します。 図5: Agent Space の複数アカウント設定 オプション B: Infrastructure as Code を使用する（推奨） Agent Space の作成と複数アカウントへの IAM ロールのデプロイを自動化する CDK および Terraform のサンプルテンプレートを提供しています。 AWS CDK の例（TypeScript）： // 多数のアカウントがある場合はループを使用： const accounts = [ { id: '111111111111', name: 'Prod', role: prodRole, stage: 'prod' }, { id: '222222222222', name: 'Dev', role: devRole, stage: 'dev' }, { id: '333333333333', name: 'Test', role: testRole, stage: 'test' }, ]; accounts.forEach(account => { const association = new devopsagent.CfnAssociation(this, `${account.name}Association`, { agentSpaceId: agentSpace.ref, serviceId: 'aws', configuration: { aws: { assumableRoleArn: account.role.roleArn, accountId: account.id, accountType: 'monitor' } } }); association.addDependency(agentSpace); cdk.Tags.of(association).add('stage', account.stage); }); アカウント間の IAM ロールと権限の設定に関する詳細な手順については、 CLI オンボーディングガイド を参照してください。 Agent Space が作成され、AWS アカウントへのアクセスが確保されたら、次の重要なステップはAWS ネイティブサービス以外の調査コンテキストを提供するオブザーバビリティツールと開発ツールとの接続です。 ステップ3：統合の設定 AWS DevOps Agent は、複数のソースからのデータを相関分析してインシデントを調査します。利用可能なコンテキストが多いほど、根本原因分析の精度が向上します。 推奨される統合 (優先度順) Amazon CloudWatch: AWS サービスからのログ、メトリクス、トレースを提供します。エージェントは調査中に CloudWatch Logs Insights を自動的にクエリします。IAM ロールが適切に設定されていれば、追加の設定は不要です。 オブザーバビリティツール: Datadog、Dynatrace、New Relic、Splunk は、分散トレーシング、ログ、メトリクス、アプリケーションレベルのコンテキストを提供します。AWS コンソールの Agent Space 統合から設定します。 コードリポジトリ: GitHub または GitLab の統合により、エージェントは最近のデプロイとコード変更をレビューできます。OAuth またはパーソナルアクセストークンが必要です。 CI/CD パイプライン: GitHub Actions または GitLab ワークフローにより、エージェントはインシデントとデプロイのタイミングを相関分析できます。コードリポジトリ統合と併せて設定します。 コミュニケーションチャネル: Slack と ServiceNow の統合により、DevOps Agent はチームチャネルにリアルタイムの調査アップデートを投稿し、調査ライフサイクル全体を通じて、調査結果、根本原因分析、推奨される緩和策でインシデントチケットを自動的に更新できます。 高度な統合 組み込みの統合に加えて、AWS DevOps Agent は Webhook トリガーによる調査とカスタム MCP (Model Context Protocol) サーバーをサポートしており、独自のオブザーバビリティツールを持ち込むことができます。 調査トリガーのための Webhook 設定 Webhook により、外部システム (Grafana、Prometheus、PagerDuty、カスタムモニタリングツール) がインシデント発生時に DevOps Agent の調査を自動的にトリガーできます。各 Agent Space は、インシデントを記述する JSON ペイロードを受け付ける一意の Webhook URL を受け取ります。 よくある設定の落とし穴: Webhook 認証: Webhook はセキュリティのために HMAC 署名を使用します。Webhook シークレットは AWS Secrets Manager に保存し、セキュリティポリシーに従ってローテーションしてください。 ペイロード形式: モニタリングツールがタイムスタンプ、影響を受けるリソース、症状の説明を含むインシデントコンテキストを送信するようにしてください。より豊富なコンテキストにより、より正確な調査が可能になります。 Webhook の詳細なセットアップについては、 Webhook を通じた DevOps Agent の呼び出し を参照してください。 独自の MCP サーバーの持ち込み 組み込みの統合以外のオブザーバビリティツール (Grafana、Prometheus、カスタムテレメトリシステム) を使用している場合、MCP サーバーを介して接続できます。MCP サーバーは、DevOps Agent が調査中にクエリする標準化されたプロトコルを通じてツールのデータを公開します。 MCP サーバーの主な要件: パブリックにアクセス可能な HTTPS エンドポイント: MCP サーバーはパブリックインターネットから到達可能である必要があります。VPC でホストされたサーバーは現在サポートされていません。 読み取り専用ツールのみ: セキュリティのため、読み取り操作を実行する MCP ツールのみを公開してください。書き込み操作はプロンプトインジェクションのリスクをもたらします。 ツールの許可リスト: MCP サーバーをアカウントレベルで登録し、Agent Space ごとに特定のツールを選択的に有効にします。すべてのツールへのアクセスを付与せず、調査に関連するもののみを選択してください。 よくある MCP セットアップエラー: 認証の設定ミス: MCP サーバーは OAuth 2.0 または API キー認証をサポートしています。OAuth クライアント認証情報が正しいこと、およびトークン交換 URL が AWS インフラストラクチャからアクセス可能であることを確認してください。 ツール名の長さ: MCP ツール名の最大長は64文字です。それより長い名前は登録に失敗します。 エンドポイント URL の形式: パスを含む完全な HTTPS URL を使用してください。例： https://mcp.example.com/v1/mcp（mcp.example.com だけではありません）。 認証設定を含む包括的な MCP サーバーセットアップについては、 MCP サーバーの接続 を参照してください。 統合のテスト: Webhook または MCP サーバーを設定した後、テスト調査をトリガーして接続性を確認します。 Webhook の場合: モニタリングツールからテストペイロードを送信し、DevOps Agent Web アプリで調査が開始されることを確認します。 MCP サーバーの場合: 手動で調査を開始し、エージェントジャーナル (調査記録)を確認して MCP ツールが正常に呼び出されたことを確認します。 AWS CloudTrail ログでエラーを確認します。CloudTrail は統合の試行を含むすべての DevOps Agent API コールをキャプチャします。 データソースが接続されたら、セキュリティ境界を維持しながら、適切な人が調査に適切にアクセスできるようにする必要があります。 ステップ4: アクセス制御の設定 Agent Space は、認可されたチームメンバーのみが調査に関与できるよう、きめ細かなアクセス制御をサポートしています。 アクセス制御の検討事項: 誰が調査を閲覧すべきか？ 通常はオンコールエンジニア、SRE、DevOps エンジニアです。セキュリティ関連のインシデントにはセキュリティチームの参加も検討してください。 誰が AWS Support ケースを作成すべきか？ 通常はオンコールリードとシニアエンジニアです。過度なケース作成を防ぐため、この権限は制限してください。 誰が Agent Space の設定を変更すべきか？ 通常は中央運用チームまたはインフラストラクチャチームです。日常の調査アクセスとは分離してください。 IAM ベースのアクセス制御: AWS DevOps Agent は、Agent Space へのアクセスを制御するために IAM ポリシーを使用します。IAM ユーザー、グループ、またはロールにポリシーをアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "devopsagent:GetAgentSpace", "devopsagent:StartInvestigation", "devopsagent:GetInvestigation", "devopsagent:ListInvestigations" ], "Resource": "arn:aws:devopsagent:us-east-1:123456789012:agentspace/EcommerceProd" } ] } AWS DevOps Agent は、複数のアカウントにまたがる運用データへの特権アクセスを持つ AWS 環境内で動作します。一般的なセキュリティの基盤は適用されますが、Agent Space の設定には固有の考慮事項があります。包括的なセキュリティガイダンスについては、 AWS DevOps Agent セキュリティ のドキュメントを参照してください。 アクセス制御が整ったら、Agent Space の設定が必要な調査カバレッジを提供していることを検証する時です。 ステップ5: テストと反復 Agent Space の設定は後から変更可能です。焦点を絞ったスコープから始め、調査結果に基づいて拡大します。 Agent Space のテスト AWS DevOps Agent Web アプリを使用してテスト調査をトリガーします。 調査を開始し、「/api/checkout エンドポイントの高レイテンシー」などの症状を提供します。 エージェントがどのリソースにクエリするかを観察します。 調査の完全性をレビューします。エージェントは根本原因を特定できましたか？ 調査から欠落しているアカウントやサービスはありませんでしたか？ エージェントは十分なテレメトリデータを持っていましたか？ 結果に基づいて Agent Space の境界を調整します。 調査にコンテキストが不足している場合はアカウントを追加します。 テレメトリのギャップがある場合は統合を追加します。 パフォーマンスが低下する場合はスコープを縮小します。 まとめ AWS DevOps Agent は、インシデント対応を手動で時間のかかるプロセスから、自律的でデータ駆動型の調査へと変革します。ただし、エージェントの効果は適切な Agent Space の設定に依存します。オンコールベースのアプローチ（本番環境と非本番環境を分離しつつ、アプリケーションに関連するアカウントへのアクセスを付与する）に従うことで、不必要な複雑さを導入することなく、正確な根本原因分析のための十分なコンテキストを提供できます。 主なポイント オンコールの境界で考える: Agent Space のスコープは、チームがインシデントを調査する方法を反映すべきです。 Infrastructure as Code を使用する: CDK と Terraform のテンプレートにより、一貫性のある再現可能なデプロイを実現できます。 オブザーバビリティツールを統合する: データソースが多いほど、調査の精度が向上します。 結果に基づいて反復する: 調査パターンの出現に応じて Agent Space のスコープを拡大・縮小してください。 次のステップ 最初の Agent Space を作成しましょう。 AWS DevOps Agent の導入をより容易にし、お客様の問題解決の精度を向上させることに取り組んでいます。Agent Space のセットアップは、迅速で信頼性の高いインシデント解決を実現するための基盤です。ご質問やフィードバックがあれば、以下にコメントをお寄せください。 著者 Tipu Qureshi Tipu Qureshi は AWS Agentic AI のシニアプリンシパルテクノロジストで、運用の卓越性とインシデント対応の自動化に注力しています。AWS のお客様と協力して、回復力があり観測可能なクラウドアプリケーションと自律的な運用システムを設計しています。 Bill Fine Bill Fine は AWS の Agentic AI プロダクトマネジメントリーダーで、AWS DevOps Agent の製品戦略と顧客エンゲージメントをリードしています。 Greg Eppel Greg Eppel は DevOps Agent のプリンシパルスペシャリストで、過去数年間クラウドオペレーションに注力し、AWS のお客様のクラウドジャーニーを支援しています。 本記事は、 Best Practices for Deploying AWS DevOps Agent in Production を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

本投稿は、 Sagar Desarda と Yutaka Okaによる記事 「 Amazon CloudFront now supports mTLS authentication to origins 」を翻訳したものです。  Amazon CloudFront  は相互TLS（mTLS）機能をカスタマーオリジンに拡張しました。これにより、ビューワーからカスタマーオリジンまでの接続パス全体を通じた、真のエンドツーエンド認証が可能になります。CloudFront はこれまで、ビューワーと CloudFront 間のビューワー mTLS をサポートしており、トラフィックが境界に入る前にクライアントを強力に認証することができました。今回のリリースにより、同じトラフィックが CloudFront からオリジンへも mTLS 経由で継続できるようになり、すべてのホップにわたって暗号化されたアイデンティティと信頼が維持されます。その結果、完全に認証されたリクエストパスが実現し、暗黙の信頼を排除し、エッジでのパフォーマンスを犠牲にすることなくゼロトラストの多層防御アーキテクチャを実現します。 CloudFront とオリジン間の mTLS が重要な理由 エッジからオリジンへ mTLS を拡張することで、リクエストライフサイクル全体にわたって、信頼を境界ベースからアイデンティティベースへと移行させます。お客様はビューワー mTLS とオリジン mTLS を CloudFront で有効にすることで、各層の間の暗黙の信頼を排除し、オリジンで最小権限アクセスを強制できます。これは規制対象および高リスクのワークロードにおいて重要です。そのような環境では、オリジンへのアクセスは検証なしに信頼するのではなく、明示的に認証され、監査可能でなければなりません。ビューワー mTLS で導入された多くの業界固有のメリットが、エンドツーエンドで適用されるようになりました。これには、API の強力なクライアントアイデンティティ、デバイス認証、規制コンプライアンスが含まれ、エンドユーザーから CloudFront を経由してオリジンまでの相互認証によって実現されます。これらのユースケースの業界別の詳細については、ビューワー mTLS に関する以前の ブログ記事 を参照してください。この記事は、エンドツーエンド mTLS がゼロトラスト原則をエッジの先にどのように拡張するかを理解するための前提知識となります。 mTLS の仕組み 標準的な TLS では、証明書管理は一方向です。サーバーが証明書を提示し、クライアントが信頼された認証局（CA）に対してそれを検証する一方、クライアントはトランスポート層では認証されません。運用上、これにより証明書管理はシンプルに保たれます。チームはサーバーの証明書のみをプロビジョニング、ローテーション、監視し、多くの場合、自動化ツールと公的に信頼された CA を使用します。クライアントのアイデンティティが必要な場合は、API キー、OAuth トークン、ヘッダーなどのアプリケーション層のメカニズムに委ねられます。 mTLS はこのモデルを根本的に変更し、双方向認証を導入します。クライアントとサーバーの両方が有効な証明書を提示し、信頼された CA に対してそれらを検証する必要があります。そのため、証明書管理は、小規模で明確に定義されたサーバー証明書のセットの管理から、大規模になりうるクライアント証明書群の管理へと拡大します。これにより、新たな運用上の考慮事項が生じます：証明書の発行と失効、ライフサイクルの自動化、CA 信頼の配布、証明書の侵害やローテーションが必要な場合の影響の局所化です。 mTLS が CloudFront エッジで終端される場合、CloudFront はクライアント認証の証明書検証の実施ポイントとして機能することで、この運用上の複雑さの多くを吸収します。お客様は信頼されたルート証明書とクライアントポリシーを管理し、CloudFront が検証処理をスケーラブルに行います。mTLS がオリジンに拡張された場合も、証明書管理はこのモデルに沿ったままです：CloudFront は独自のクライアント証明書をオリジンに提示し、オリジンの証明書を検証します。これにより、オリジンがすべてのエンドユーザーの証明書を直接管理または信頼する必要なく、相互認証が維持されます。 前提条件 この機能を有効にするには、以下の前提条件があります： ・拡張キー使用法（clientAuth）を持つ X.509v3 クライアント証明書（ PEM 形式）を準備 ・mTLS 認証を要求し、クライアント証明書を検証するように構成されたオリジンサーバー ・ AWS Certificate Manager （ACM）で米国東部（us-east-1）AWS リージョンを選択 設定手順 CloudFront とオリジン間の mTLS 認証の実装には、3つの主要なステップがあります：ACM を通じたクライアント証明書の取得、オリジンサーバーの構成、CloudFront ディストリビューションでの mTLS の有効化です。 ステップ 1：クライアント証明書の構成 CloudFront は2つのソースからのクライアント証明書の導入をサポートしており、それぞれ異なる運用ニーズに適しています： AWS Private Certificate Authority  とサードパーティ CA です。 AWS Private Certificate Authority（推奨） AWS Private Certificate Authority は、ACM とのシームレスな統合による、完全マネージドの証明書ライフサイクルを提供します。このアプローチにより、手動の証明書管理のオーバーヘッドが排除されます。 証明書をリクエストするには： 1. ACM コンソールを開き、米国東部（バージニア北部）リージョンにいることを確認 2. 「証明書のリクエスト」>「プライベート証明書のリクエスト」を選択 3. CA を選択し、ドメイン名を入力 4. 希望するキーアルゴリズムを選択し、更新権限を確認 5. 「リクエスト」を押下 図 1： AWS Certificate Manager からAWS Private Certificate Authorityへの新しい SSL/TLS 証明書リクエストの開始 サードパーティ CA  既存のプライベート CA インフラストラクチャから証明書をインポートして、現在の証明書管理プロセスを維持しながら CloudFront mTLS 機能を利用できます（図2参照） 証明書をインポートするには： 1. ACM コンソールで「証明書のインポート」を選択 2. 証明書本文、秘密鍵、証明書チェーン（すべて PEM 形式）を入力 3. 「証明書をインポート」を押下 クライアント証明書には、mTLS 認証のための拡張キー使用法（clientAuth）が含まれている必要があります。 図 2：AWS Certificate Manager に既存のクライアント証明書と秘密鍵をアップロードして、AWS での mTLS 認証に使用される証明書を登録する画面 ステップ 2：オリジン設定で mTLS を有効化  証明書ベースの検証を必要とする各オリジンに対して mTLS 認証を構成します（図3参照）： 1. CloudFront コンソールで、ディストリビューションの「オリジン」タブに移動 2. 構成するオリジンを選択し、「編集」を選択します。 3. オリジン設定で、「Enable origin mutual TLS」を「オン」に切り替えます。 4. ドロップダウンメニューからクライアント証明書を選択します。 5. 変更を保存します。 図 3：オリジンリクエストに対する mTLS 認証を有効にする CloudFront 設定。CloudFront がオリジンで証明書ベースの認証を強制できるようにします オリジンごとの設定の柔軟性 mTLS はオリジンレベルで構成されるため、同じディストリビューション内の異なるオリジンに異なる証明書を割り当てることができます。これにより、オリジンごとに異なるセキュリティポリシーを適用できます。例えば、API エンドポイントには mTLS を使用し、静的コンテンツ配信オリジンには標準認証を適用できます（図4参照）。 図 4：CloudFront がオリジンとの相互 TLS を確立し、エッジからバックエンドサービスまでリクエストが認証・暗号化される構成 エンドツーエンド mTLS によるセキュリティとパフォーマンスのバランス エンドツーエンド mTLS（エンドユーザーから CloudFront、CloudFront からオリジン）を有効にすると、接続確立時にいくらかのオーバーヘッドが発生します。これは、各セグメントで両者を認証するための証明書検証と暗号化処理が必要なためです。ただし、このオーバーヘッドは主にハンドシェイクフェーズに限定され、その後のアプリケーションデータの転送には影響しません。コネクションプーリングや持続的なキープアライブ接続などのコネクション再利用メカニズムにより、多くのエンドユーザーリクエストにわたってこのコストが削減されます。これにより、ほとんどのワークロードでレイテンシーとスループットへの影響が最小限に抑えられます。CloudFront はトラフィックの大部分をエッジでキャッシュするため、大半のリクエストはオリジンに到達せず、相対的なパフォーマンスへの影響がさらに軽減されます。TLS 1.3 と適切な証明書管理により、わずかに高い接続セットアップコストと強力なエンドツーエンド認証のトレードオフは十分に見合うものです。CloudFront を通じて配信されるアプリケーショントラフィックのセキュリティをさらに強化したい場合は、mTLS の実装が有効な選択肢となります。 証明書管理については、AWS Private CA が完全に自動化されたライフサイクル処理と、45 日、30 日、15 日、7 日、1 日前の更新通知によりプロセスを効率化します。サードパーティの証明書を使用している場合は、mTLS 接続の中断を避けるために、タイムリーな手動更新のプロセスを整備してください。 まとめ Amazon CloudFront とオリジン間の mTLS は、最新のエッジアーキテクチャで最も見落とされがちな信頼のギャップの1つを解消します。 パート1 ではエンドユーザーと CloudFront 間の強力なアイデンティティと認証を確立しましたが、mTLS をオリジンに拡張することで、リクエストパスのすべてのホップが認証、暗号化、認可されることが保証されます。これにより、セキュリティは IP およびネットワークベースのモデルから暗号化ベースの信頼モデルへと移行し、オリジンは CloudFront を経由したことを証明できるトラフィックのみを処理します。アプリケーションが分散エッジ、プライベート API、ゼロトラスト原則にますます依存するようになるにつれ、CloudFront からオリジンへの mTLS は、オプションのセキュリティ強化策ではなく、基盤となるセキュリティ対策となります。エンドユーザー mTLS とオリジン mTLS を組み合わせることで、真のエンドツーエンドのアイデンティティ保証が提供され、攻撃対象領域の削減、コンプライアンスの効率化、回復力のあるアプリケーション境界の構築が実現します。 著者について Sagar Desarda Sagar Desardaは、データ、分析、Gen AI ISV 向けのテクニカルアカウントマネージャー（TAM）およびビジネス開発（BD）組織の責任者です。Sagarのチームは、お客様と協力して AWS アーキテクチャを最適化し、ビジネスクリティカルなアプリケーションのシームレスな運用を確保し、採用を加速し、北米全体で市場投入の成功を推進します。さらに、Sagar は Edge Networking Services Specialist US チームのリーダーとして、新規ビジネスの成長を推進し、技術的なエンゲージメントを促進し、顧客向けの出版物を執筆しています。 Yutaka Oka Yutaka Oka は、東京を拠点とするシニアエッジスペシャリストソリューションアーキテクトです。彼の主な焦点は、AWS Edge Services を使用してコンテンツ配信を最適化および保護することでお客様を支援することです。

みなさん、こんにちは。ソリューションアーキテクトの稲田です。 本記事は、三菱電機グループの社内 AWS ユーザーグループ「MAWS（Mitsubishi AWS User Group）」シリーズの第 3 弾です。 第 1 弾 では一人のエンジニアの小さな行動から 300 人を超えるコミュニティへと成長した誕生ストーリーを、 第 2 弾 では実務への展開や経営層との対話、次世代への継承といった MAWS の進化をお伝えしました。 2026 年 3 月 6 日、755 名に成長した MAWS のリーダーたちが AWS Tokyo Executive Briefing Center に集まり、AWS VP / Chief Evangelist の Jeff Barr とのセッションが実現しました。Jeff の 23 年間の AWS での経験をもとに、AI 時代における開発組織の変化、生産性のパラダイムシフト、そして人材育成の課題について議論が交わされました。 本記事では、セッションで共有されたインサイトと、MAWS メンバーとの対話から見えてきた AI 時代の組織変革の姿をお伝えします。 コミュニティの原点 — Jeff Barr の原体験 セッションの冒頭、Jeff は自身の原体験を語りました。約 50 年前、Northwest Computer Club というコミュニティに参加していた頃の話です。 そこでは年齢も経歴も関係なく、メンバーとして参加し、つながり、貢献する意志さえあればそれで十分でした。家庭の問題で個人的に困難な時期にあった Jeff にとって、クラブは単なる技術リソースではなく、コミュニティであり、友人そのものだったといいます。 50 年近く経った今も、テクニカルコミュニティの形成と成長を支援することが自身のモチベーションの源泉であり、 JAWS-UG や MAWS を通じた活動に深い感謝を示しました。 「現場」から変革を起こす — MAWS と Serendie® DX イニシアティブ「Serendie」 三菱電機は現在、DX のイニシアティブであるデジタル基盤「Serendie」により、イノベーティブカンパニーへの変革を進めています。従来のビジネスモデルはハードウェア販売によるワンタイムレベニューが中心でしたが、デジタルサービスによるリカーリングレベニューへの転換を推進しています。 この変革には 3 つの挑戦があります。データ活用したサービスの創出を主としたビジネスモデル変革、AI など最新技術をグローバルに展開するためのデジタル基盤強化、そして、課題をクイックに解決するアジャイル開発の加速を主眼としたマインドセット変革です。 重要なのは、この変革がトップダウンだけでなく全メンバーが推進する形で進められている点です。その中で MAWS がキーロールを担っています。 755 名に成長した MAWS 第 1 弾 で 300 名だった MAWS のメンバーは、755 名にまで成長しました。活動拠点は横浜、東京、関西エリアに広がっています。 MAWS のコアパーパスは、異なる事業所・事業部をまたいだクロスチームのつながりを促進することです。「周りに AWS に詳しい人がいない」「ジュニアエンジニアには質問しづらい」といった現場の課題に対し、Viva Engage や Teams 等を活用してボランティアが質問対応からトラブルシューティングまで支援する体制を構築しています。異なる事業部のシニアエンジニアが回答者として参加することで、組織の壁を越えた知識共有が実現しています。 コミュニティの成長サイクル MAWS の運営哲学は、外部コミュニティの「幅広い知識・経験」と社内コミュニティの「メンバーの成長支援」の両方の良いところを組み合わせることにあります。 成長サイクルは明確です。まずエンジニアがコミュニティプログラムに聴講者として参加し、知識と経験を現場に持ち帰る。次のステージでは発表者・登壇者として参加し、その経験を CCoE（Cloud Center of Excellence）に共有する。やがてクラウドアーキテクチャやユースケースを公式組織として事業部門に推奨するようになり、事業部門からさらに多くの人がコミュニティに参加するという好循環が生まれています。 第 2 弾 でもお伝えした通り、2025 年 4 月からは「 DX Innovation Academy（DIA） 」で MAWS メンバーがリードする AWS コースも開講しています。さらに、現場レベルでは AI 駆動開発の実践も加速しており、電力 ICT センターでは Kiro と GitLab を組み合わせた開発ワークフローの標準化 や、 33 名のエンジニアが参加した AI-DLC Unicorn Gym など、コミュニティから生まれた実践的な取り組みが次々と展開されています。 「エンジニアとしてモチベーションを持ち、自分たちが会社を変えるんだという決意。これが我々のスピリットです。」と MAWS メンバーは語ります。 製造業は「現場主義」が根付いた業界です。トップダウンの号令だけでは、15 万人規模の組織は動きません。三菱電機では、経営層による戦略的な方向付けと、MAWS のようなボトムアップの技術コミュニティを組み合わせた「サンドイッチアプローチ」で変革を推進しています。 Jeff はこの取り組みに非常に感銘を受けたと述べ、MAWS の 2 年間での成長を高く評価しました。 AI 時代の開発組織 — Jeff Barr のインサイト 2 Pizza チームから 1 Pizza チームへ Jeff がまず投げかけたのは、「AI ツールで開発者の生産性が上がったとき、組織はどう変わるべきか？」という問いでした。三菱電機のメンバーからは「むしろ対面コミュニケーションの重要性が増している」という声が上がり、Jeff も強く同意しました。 Amazon では長年「2 Pizza Team（ピザ 2 枚で足りる人数のチーム）」が組織設計の原則でした。しかし AI 時代には、より少人数で深い議論と迅速な意思決定ができる「1 Pizza Team」へと進化しつつあるといいます。開発チームのメンバーが同じ場所に、時には同じ部屋にいることの重要性が増しています。理由は明快で、重要な意思決定をより早く、より頻繁に行う必要があるからです。 極端な例としてハッカーハウス（開発者が同じ場所に住み込みで開発する形態）も紹介されましたが、Jeff はこれを「観察であり推奨ではない。ワークライフバランスは重要だ」と冗談交じりに付け加えました。 20 倍のコミット増、そしてボトルネックの移動 生成 AI ツールの活用により、開発者の週次コミット数が最大 20 倍に増加した事例が報告されています。注目すべきは、この変化がマネージャーからのトップダウンではなく、開発者自身のボトムアップによるカルチャーの変化として起きている点です。 しかし、この生産性向上には深刻な副作用があります。コード生産量の急増により、シニア開発者によるコードレビュー、コードのマージ、そして CI/CD パイプライン全体といった下流プロセスにボトルネックが移動しているのです。 Jeff は BMW Group の事例を紹介しました。BMW は CI/CD プロセス全体のシステムを数年かけて再構築し、効率化を実現しています。20 倍の生産性向上を実際に享受するには、ダウンストリームのボトルネック解消が不可欠であり、次のイノベーションの波はマージ、レビュー、テスト、デプロイの効率化から生まれるだろうと Jeff は見ています。 これは三菱電機のような大規模組織にとって特に重要な示唆です。開発者個人の生産性向上だけでなく、組織全体のデリバリーパイプラインを見直す必要があるということです。 76 日間で 2 年分の開発を完了 — Project Mantle Jeff は AWS 社内の事例として「Project Mantle」を紹介しました。これは Amazon Bedrock の推論インフラを刷新するプロジェクトで、急増する AI 推論需要に対応するために立ち上げられました。 Mantle は Bedrock の全モデルのホスティングと推論リクエスト処理を担う重要コンポーネントであり、最もシニアなエンジニアがアサインされました。当初の見積もりは約 2 年。しかしチームが 生成 AI の活用を実験した結果、11 人のチームがコードゼロからデプロイまでわずか 76 日で完了させました。 「AI が実装・テストし、人間がレビューする」というサイクルを 1 時間以内で回す体制を構築し、個々の開発者の生産性は 10〜20 倍に向上。同時に「ゼロオペレーターアクセス」——AWS のオペレーターですら顧客データにアクセスできない——という高いセキュリティ基準も達成しています。 この経験はシニア開発者にとっての「目から鱗」のウェイクアップコールとなり、GenAI の正しい活用法を組織全体に示す象徴的な事例となりました。 トークンエコノミクス — 新しい KPI の登場 AI 活用が進む中、企業は「トークン消費量」を新たな KPI として追跡し始めています。トークン使用量を開発者やプロジェクトにマッピングして可視化し、フィードバックして改善を促す取り組みが広がっています。 興味深いのは、トークンコストと開発者コストの比較が、エンジニアのアサイン方針を見直すきっかけになっている点です。AI ツールによって一人あたりの生産性が飛躍的に向上するなら、少数精鋭の内製チームの方が合理的——全体的には自社開発者を持つ方向へのトレンドが見られます。 AI 時代の人材育成 「High Judgment」— シニアとジュニアを分けるもの Amazon/AWS において、シニアエンジニアとジュニアエンジニアの違いは何か。Jeff の答えは明確でした。もはや技術スキルの差ではない。アーキテクチャの深い理解と、困難な状況で質の高い意思決定ができる能力「High Judgment」こそがシニアを定義するものです。 「ジュニアエンジニアはどう育てるべきか」という三菱電機側からの問いに対し、Jeff はこれがグローバル全体で業界が直面している問いだと認めた上で、教えるべきはコーディングスキルだけではなく、コミュニケーション能力、正しい判断を下す力、そしてビジネスの理解だと述べました。 具体的な育成方法としては、シニア開発者が大きな判断をする場面にジュニアを同席させ、困難な意思決定を経験する機会を意図的に与えること。そして成功事例だけでなく失敗事例からも学ばせることが重要だとしました。 セッションでは、三菱電機のメンバーから「冬休みに AI を活用して個人で約 10 万行のビジネスアプリケーションを開発した」という経験が共有されました。Jeff はこれに触れ、今後 10 年以内にユニ・ユニコーン（一人でユニコーン企業（10 億ドル評価）を築く個人）が登場する可能性があると語りました。 20 年で逆転したスキルセット、そして「性格の変化」 Jeff が語った中で最も印象的だったのは、開発者に求められるスキルの逆転現象です。 20 年前は、できるだけ少ないコードで、小さく効率的に、データも最小限にと教えられていました。今は逆です。プロンプトにできるだけ多くの情報を与え、データを最大限に活用することが求められます。かつて開発者は一人で静かに作業できることが美徳でした。今はチームの一員として多くの言葉を発し、頻繁にコミュニケーションを取ることが不可欠です。 「多くの開発者は、一人で静かに働けるからこそこの職業を選んだのです。この変化は技術的な変化というより、性格の変化に近い。これが個人にとっても組織にとっても最も興味深いチャレンジになるだろう。」と Jeff は述べました。 失敗をシステムに帰属させる — Amazon の COE プロセス ジュニアエンジニアの育成に関連して、Jeff は Amazon に長年存在する障害対応プロセス「COE（Correction of Errors）」を紹介しました。 システムやプロセスに障害が発生した際、まず問題を修正し、次に根本原因を深く分析・議論する。その上で、ミリ秒単位で障害の各段階を記録した詳細なドキュメントを作成し、再発防止策を記載します。 核心的な原則は、障害の原因を常にシステムやプロセスに帰属させ、決して個人を責めないことです。すべての COE はナンバリングされアーカイブされ、組織全体の学習資産として機能します。シニアエンジニアは有名な COE を番号で記憶しており、「COE 253 番の教訓を思い出せ」といった会話が日常的に交わされるといいます。運用上の重要なルールとして、COE が発行されたシステムは、問題が解決されるまで新機能の開発が停止されます。特に大きな障害については、シニアエンジニアが社内プレゼンテーションで教訓を共有します。このメカニズムにより、システムは時間の経過とともにより堅牢でレジリエントになっていきます。 Jeff はこれをジュニアエンジニアがシニアに成長するための重要な学習機会としても位置づけました。この「失敗から学ぶ文化」は、MAWS のようなコミュニティが社内で知見を共有する際のモデルケースにもなり得るでしょう。 ディスカッション — ナレッジ共有と組織変革 セッション後半では、三菱電機の現場が直面する課題と、コミュニティの未来について活発な議論が交わされました。 三菱電機側からは、社内に多様なデータが存在するが構造化されておらず、エンジニアがドメインナレッジにアクセスできないという課題が提起されました。Jeff は、社内データと構造を反映した独自モデルを構築し、開発プロセスのコンテキストとして活用することを提案しました。ただし、既存のリポジトリや Wiki を検索するよりも生成 AI で新しいものを作った方が速いケースも出てきており、多くの企業が同様のジレンマに直面しているといいます。「8〜10 時間のフライトに乗ると、着陸した時には世界が変わっているかもしれない。」という Jeff の言葉が、その変化のスピード感を物語っています。 コミュニティのあり方についても議論が深まりました。熱意のある人が集まるコミュニティは、課題に直面しても諦めずに前に進む力がある。単なるプロジェクトメンバーグループではなく、コミュニティとして進化していること自体が強靭性の源泉になっているとの見解が共有されました。Jeff は AWS の誕生ストーリーにも触れ、AWS 以前の Amazon 社内では各チームが同じ基本的な問題を並行して解決しており、サーバー調達にはマネージャー間でスプレッドシートを回覧して翌年の需要を予測するという柔軟性のないプロセスが存在していたと語りました。このプロセスがイノベーションを遅延させていたことが EC2 と S3 のローンチにつながり、今年でローンチから 20 周年を迎えます。 三菱電機の「コミュニティに KPI は必要か」という問いに対しては、Jeff は「KPI は必要だがコミュニティの種類によって大きく異なる」との回答でした。会員数だけでなく、参加頻度、参加の深さ、エンゲージメントの度合いを測定すべきであり、日本国内で同様の社内開発者コミュニティを持つ企業のリーダー同士が集まってベストプラクティスを比較することも Jeff は推奨しました。 おわりに セッションを通じて浮かび上がったのは、AI 時代の変革は技術だけの問題ではないということです。 チームは「2 Pizza」から「1 Pizza」へと小さくなり、対面での密なコミュニケーションと迅速な意思決定がこれまで以上に重要になっています。開発者の生産性は劇的に向上していますが、その恩恵を真に享受するには CI/CD などダウンストリーム全体の最適化が不可欠です。 人材育成の面では、シニアとジュニアの差はもはや技術力ではなく「High Judgment」にあります。20 年前と真逆のスキルセットが求められる時代において、意思決定の経験を意図的に与え、Amazon の COE プロセスのように成功と失敗の両方から組織的に学ぶ仕組みが鍵となります。 そして、751 名規模に成長した MAWS の取り組みが示すように、社内コミュニティは単なる技術リソースではなく、企業文化変革のドライバーそのものです。 製造業の巨人の中で、現場のエンジニアたちが自ら変革を推進する。トップダウンとボトムアップの「サンドイッチアプローチ」は、日本の大企業が DX を実現するための一つの解として、参考になるのではないでしょうか。 今回インタビューをさせて頂いた MAWS の運営メンバーの方々 川口 賢太郎 DXイノベーションセンター・副センター長。AWS認定資格全取得。三菱電機のデジタル基盤 “Serendie” による循環型デジタルエンジニアリング企業への変革を推進。 小川 雄喜 IoT・ライフソリューション新事業推進センター所属。 AWS Top Engineer 2025 、 AWS Community Builders 、Japan AWS All Certifications Engineers 2025 選出。 JAWS-UG 京都 運営メンバー、関西 Jr. Champion 会アドバイザーとして活動。年間 20 件を超える外部登壇を通じて アジャイル や コミュニティのあり方 などを発信中。 辻尾 良太 DX イノベーションセンター所属。 AWS Top Engineer 2025 、Japan AWS All Certifications Engineers 2024 , 2025 選出。三菱電機のデジタル基盤「 Serendie 」の開発に従事。普段は鶏肉とたまごをよく食べますが、野鳥たちとは仲良しのつもりです。 JAWS-UG 横浜支部 や E-JAWS 人材育成・クラウド推進体制分科会の運営メンバーとして社外コミュニティでも活躍。 紅林 俊之 デジタルイノベーション事業本部所属。Japan AWS All Certifications Engineers 2025 選出。三菱電機のクラウドマイグレーションとプラットフォーム再構築を推進する 2 つの大型プロジェクトをリード。MAWS-UG 立ち上げの発起人の一人。 塚田 真規 AI 戦略プロジェクトグループ所属。 AWS Community Builders 2025 、Japan AWS All Certifications Engineers 2024 , 2025 選出。生成 AI 開発基盤整備と LLMOps 推進を担当。JAWS-UG AI/ML 支部でのイベント主催や商業誌出版など多方面で活動。 インタビュアー 稲田 大陸 – いなりく AWS Japan で働く筋トレが趣味のソリューションアーキテクト。2022 年から三菱電機グループをご支援させていただいています。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

こんにちは! 今回初めて AWS Weekly Roundup を担当する Daniel Abib です。私は、生成 AI と Amazon Bedrock を専門とする AWS シニアスペシャリストソリューションアーキテクトです。ソリューションアーキテクチャ、ソフトウェア開発、クラウドアーキテクチャでの経験は 28 年を超え、Amazon Bedrock を使って生成 AI の力を活かせるようにスタートアップとエンタープライズ企業を支援しています。AWS 勤務歴は 6 年半以上で、中南米全域のお客様と密接に連携しています。また、サーバーレステクノロジーにも情熱を持っています。 仕事とエンデュランススポーツ以外では、Cecília (7 才) とRafael (4 才) の父親として全力を注いでいます。子どもたちは、どんな分散システムよりも毎日を忙しく、そして幸せにしてくれます。私の拠点はサンパウロです。 LinkedIn と X (@DCABib) では、生成 AI、Amazon Bedrock、AWSサーバーレスサービスに関する洞察を投稿していますが、アイアンマンの懐かしい思い出を投稿することもたまにあります。 それでは、2026 年 3 月 23 日週の AWS ニュースを見ていきましょう。 2026 年 3 月 16 日週のリリース 2026 年 3 月 16 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Redshift がダッシュボードと ETL ワークロードでの新規クエリのパフォーマンスを最大 7 倍に向上 – ダッシュボードと ETL ワークロードでの新規クエリに対し、Amazon Redshift が最大 7 倍速いパフォーマンスを達成できるようになりました。初めて実行するクエリ (キャッシュされた結果がないもの) の実行速度が大幅に向上するため、インタラクティブなダッシュボードの待機時間短縮と、ETL パイプラインの迅速化が可能になります。これは、キャッシュヒットの頻度が低く、クエリの変動性が高いワークロードに特に大きなインパクトをもたらします。 Amazon Bedrock での NVIDIA Nemotron 3 Super 提供開始 – Amazon Bedrock で NVIDIA Nemotron 3 Super を利用できるようになり、統合 Bedrock API を通じてアクセスできる基盤モデルのラインナップが拡大されました。Nemotron 3 Super は、テキスト生成、複雑な推論、要約、コード生成などのタスク向けに最適化された高性能言語モデルです。これからは、インフラストラクチャを管理しなくても、既存の Bedrock ワークフローで他の基盤モデルとともに Nemotron 3 Super を呼び出すことができるようになります。 エンタープライズ AI 向けに Nova モデルをカスタマイズするためのシームレスな手段、Nova Forge SDK の導入 – Nova Forge SDK は、エンタープライズユースケース向けに Amazon Nova モデルをファインチューニングしてカスタマイズするための効率的な手段を提供します。Nova モデルをドメイン固有のデータに適合させ、Amazon Bedrock 内にそれらを直接デプロイできるため、目的に合わせて AI ソリューションを構築する複雑性が軽減されます。モデルのカスタマイズという面倒な作業は SDK が処理するので、ユーザーは基盤となるインフラストラクチャではなく、ビジネスロジックに集中できます。 Amazon Corretto 26 の一般提供開始 – Amazon Corretto 26 の一般提供が開始されました。これは、OpenJDK の無償/本番環境対応ディストリビューションの最新 LTS (長期サポート) リリースです。Corretto 26 には、最新の Java 言語機能、パフォーマンス改善、セキュリティパッチが含まれており、これらすべてが AWS の長期サポートによって支えられています。Corretto 26 は、Amazon Linux、Windows、macOS、および Docker イメージ上の開発環境と本番環境全体でご利用いただけます。 AWS Lambda がアベイラビリティーゾーンメタデータのサポートを開始 – AWS Lambda が、関数の呼び出しにアベイラビリティーゾーンメタデータを提供するようになりました。Lambda 関数が実行されているアベイラビリティーゾーンを特定できるようになるため、より優れたオブザーバビリティと、より多くの情報に基づいたアーキテクチャ上の判断が可能になるとともに、レイテンシーの影響を受けやすいワークロードとマルチ AZ ワークロードのトラブルシューティングが容易になります。これは特に、Lambda 実行とアーキテクチャ内にある他の AZ アウェアなサービスとの関連付けに便利です。 Amazon CloudWatch Logs が HTTP ベースのプロトコルを使用したログ取り込みのサポートを開始 – Amazon CloudWatch Logs が、HTTP ベースのプロトコルを使用したログの取り込みをサポートするようになり、標準の HTTP エンドポイントを使用するアプリケーションとサービスからのログの送信がよりシンプルになりました。カスタムエージェントや追加の SDK 統合を必要とすることなく CloudWatch Logs にログをルーティングできるようになったため、ワークロード全体でログを一元管理するハードルが低くなります。 Amazon EKS が Provisioned Control Plane クラスターに対する 99.99% のサービスレベルアグリーメントと新しい 8XL スケーリングティアを発表 – Amazon EKS が Provisioned Control Plane で実行されるクラスターに対して 99.99% のサービスレベルアグリーメント (SLA) の提供を開始しました。これは、標準コントロールプレーンで提供される 99.95% の SLA を超えるものです。EKS には、利用可能な Provisioned Control Plane ティアの中でも最も大きい 8XL スケーリングティアも導入されます。このティアの Kubernetes API サーバーリクエスト処理能力は、すぐ下のティアである 4XL ティアの 2 倍であるため、AI/機械学習トレーニング、ハイパフォーマンスコンピューティング (HPC)、大規模なデータ処理といった大規模ワークロードに最適です。 AWS のその他のニュース こちらは、皆さんが関心を持つと思われる追加の記事とリソースです。 Kiro for students – 学生向けの Kiro の提供が開始され、次世代のビルダーが AI 駆動の開発ツールに無料でアクセスできるようになりました。Swami Sivasubramanian が LinkedIn で共有 したように、「学生は、テクノロジーを形作る未来の意思決定者です」。Kiro は、開発初日から AI を使って構築する実践的な体験を学生に提供します。皆さん自身が学生、または学生である方をご存知なら、Kiro for students は AI 支援の開発で構築を始める絶好の機会です。 Strands Steering Hook が 100% のエージェント精度を達成 – Strands Agents チームは、Steering Hook が 100% のエージェント精度を達成できることを示す結果を発表しました。これは、エージェントの行動を制御するためのプロンプトエンジニアリングとリジッドなワークフローアプローチの両方をしのぐ結果です。Swami が LinkedIn で言及 しているとおり、信頼性のある AI エージェントの構築は、しばしばモデル行動をガイドする方法の見直しを意味します。そんな中、Steering Hook はエージェントの信頼性につながる新しい魅力的な手段を提供します。 AWS Builder Center でのバッジ導入 – AWS Builder Center に、ビルダーコミュニティ内での貢献と成果を評価するためのバッジが登場しました。バッジは、ソリューションの共有、チャレンジへの参加、仲間のビルダーとの交流によって獲得できます。専門知識をアピールし、成長を追跡するためのすばらしい方法です。 共に構築し続ける: コミュニティの力 – AWS エコシステムにおけるコミュニティ主導の学習とコラボレーションの力に関する思慮に富んだ読み物です。AWS を使い始めたばかりであるか、何年も構築してきたかにかかわらず、ビルダーコミュニティは、互いにつながり、知識を共有し、共に成長できる場所です。ビルダーコミュニティをチェックしてみてください。自信を持ってお勧めします。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit にご参加ください。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。近日開催される AWS Summit には、パリ (4 月 1 日)、ロンドン (4 月 22 日)、バンガロール (4 月 23〜24 日)、シンガポール (5 月 6 日)、テルアビブ (5 月 6 日)、ストックホルム (5 月 7 日) などがあります。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供し、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われるコミュニティ主導のカンファレンスです。近日開催されるイベントには、サンフランシスコ (4 月 10 日) およびルーマニア (4 月 23～24 日) があります。 AWSome Women Summit LATAM – 3 月 28 日にメキシコシティで開催されるこのイベントは、中南米全域でクラウドテクノロジーに携わる女性の功績を称え、エンパワーメントを図ることを目的としています。中南米テクノロジーコミュニティのすばらしいイニシアチブです。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。今後開催される AWS 主導の対面および仮想イベント、スタートアップイベント、デベロッパー向けのイベントについては、 AWS イベントとウェビナー をご覧ください。 2026 年 3 月 23 日週のニュースは以上です。2026 年 3 月 30 日週の Weekly Roundup もお楽しみに! この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

本日、 Amazon Quick が AWS アジアパシフィック (東京) リージョンで利用可能になったことをお知らせします。 このローンチにより、日本のお客様は 日本国内でホストされるデータと機械学習モデルを活用しながら Amazon Quick のエージェント型 AI 機能を利用できるようになりました。(注: 本日時点では Web 検索機能のみ日本国外のモデルを利用しています。) Amazon Quick は、一つのUIからデータから迅速に回答を取得し、そのインサイトを業務アクションへとつなげることができる AI ベースのデジタルワークスペース です。 東京リージョンでの提供開始により、日本のお客様は 低レイテンシー、国内データレジデンシー、エンタープライズレベルの AI 機能 を活用できるようになります。 Amazon Quick の概要 Amazon Quick は、 リサーチ、ビジネスインテリジェンス、そして自動化機能を統合したエージェンティック AI ワークスペース を提供します。 従来、ユーザーはデータ収集、分析、業務実行のために複数のアプリケーションを切り替える必要がありました。Quick を利用することで、これらの機能を 1 つのプラットフォーム上で統合的に利用可能 です。 ユーザーは自然言語で質問するだけで、 データからインサイトを取得 ダッシュボードやレポートを生成 アプリケーションや業務システムを横断してワークフローを自動化 することが可能になります。 Amazon Quick の主な機能 Amazon Quick は、次の 5 つの主要機能で構成されています。 Quick Index 組織内のドキュメント、ファイル、アプリケーションデータを横断的に統合し、検索可能なナレッジベースを構築します。 Quick Research 組織内のデータに加え、Web や外部データソースを組み合わせて分析し、インサイトやレポートを生成する AI リサーチエージェントです。 Quick Sight データをダッシュボードや可視化、自然言語による要約へと変換する AI ビジネスインテリジェンス機能です。 Quick Flows 自然言語で日常業務のワークフローを作成し、Web アプリケーションやサービス全体に渡るステップを自動化できる機能です。 Quick Automate 複数の専門的な AI エージェントを活用し、ガバナンスコントロールと人間による承認ステップを備え、複雑な業務プロセスを自動化してエンタープライズシステム全体の高度なオーケストレーションを実現する機能です。 これらの機能により、Amazon Quick は ビジネスユーザーのための AI アシスタント として活用できます。 例えば Quick を使用すると、 社内データと外部情報を横断検索 データから可視化やサマリーを生成 チケット作成や承認ワークフローなどの業務アクションを実行 これらすべてを会話型インターフェースで実現し、組織全体でのAI導入の障壁を下げます。 エンタープライズグレードのセキュリティとデータプライバシー Amazon Quick は、エンタープライズ利用を前提に セキュリティとデータプライバシーを重視して設計 されています。 お客様のデータやクエリは 基盤モデルのトレーニングに使用されることはありません 。組織は、AWS マネジメントコンソールを通じて、 データ、権限、統合を完全に管理が可能 です。 また、東京リージョンで利用することで、 データを日本国内の AWS インフラストラクチャ内に保持することが可能 になります。 日本国内でのサービス提供によるメリット Amazon Quick が東京リージョンで利用可能になったことで、日本のお客様は データを日本国内にとどめつつ、低レイテンシ―で AI 分析や自動化機能を利用可能 です。 国内データレジデンシー データを日本国内の AWS インフラストラクチャに留めることができ、組織が規制や内部ガバナンスの要件を満たすのに役立ちます。 低レイテンシー 日本国内ユーザーのネットワークレイテンシーが改善され、AI 応答やダッシュボード表示、ワークフローの応答などのパフォーマンスが向上します。 高可用性 東京リージョンの複数のアベイラビリティーゾーンをに展開され、高い可用性とレジリエンシ―を提供します。 まとめ Amazon Quick が東京リージョンで利用可能になったことで、日本のお客様は AI を活用した分析、リサーチ、自動化機能を国内インフラ上で利用できるようになりました。 Amazon Quick は、質問からインサイトの取得、そして業務アクションの実行までを 1 つのワークスペースで実現 します。 ぜひ東京リージョンで Amazon Quick をお試しください。 Amazon Quick の開始方法 お客様は、AWS マネジメントコンソールを通じて、 東京リージョン (ap-northeast-1) で今すぐ Amazon Quick を使い始めることが可能です。 始めるには: AWS アカウントで Amazon Quick を有効にします Amazon S3 や Microsoft SharePoint、Slack、その他のビジネスアプリケーションなどのデータソースを接続します Quick Index を設定してナレッジベースを構築します Quick Research 、 Quick Sight 、 Quick Flows を使って洞察を生み出し、ワークフローを自動化します 新規のお客様は、 最大 25 ユーザーまでの 30 日間の無料トライアル も利用可能です。 筆者について 溝渕 匡 (Masa Mizobuchi) AWS Japan のソリューションアーキテクトとして、様々なお客様に日々クラウド活用の技術支援を行なっています。ソフトウェアの設計、開発、データ分析、Scrum などが好きで、Scrum は好きが高じて導入プログラムを開発して複数企業への導入実績があります。趣味はゲームで遊んだりゲームを作ったりすることです。

はじめに ジャパンベストレスキューシステム株式会社 （以下、JBR）は、日本全国で展開する生活救急サービスのリーディングカンパニーです。住宅のカギの紛失や水まわりのトラブル、ガラスの破損など、日常生活で発生する様々な緊急事態に対し、24 時間 365 日体制で駆けつけサービスを提供しています。「困っている人を助ける」という企業理念のもと、生活救急事業を中心に事業を拡大しており、現在では年間約32万件の救急対応実績を誇り、全国 47 都道府県をカバーする約 2,000 の協力事業者ネットワークを構築しています。 このブログでは、JBR がカスタマーサービスの品質向上と業務効率化を実現するために、 Amazon Connect 、 Amazon Lex でセルフサービスを導入し、目標数値の 75% の自動応答化とエージェントの業務時間削減に成功した事例についてご紹介します。 課題背景 JBR では Amazon Connect を活用したコンタクトセンター運営を行ってきましたが、以下のような課題に直面していました : 業務量増加に伴うエージェント対応の維持、拡大 目標応答率の安定的な達成 顧客層により求められるサービスレベルの違い（人による対応重視 vs 受付完了優先） 対応時間の約 40% を占める定型的なお問い合わせ、要件確認の効率化 これらの課題を解決するため、音声ボットの導入を検討することになりました。 ソリューション選定 複数の音声ボットソリューションを比較検討する中で、以下の理由から Amazon Lex の採用を決定しました : 既に運用中である Amazon Connect 環境との統合の容易さ 実環境での検証 (PoC) が可能 クライアント企業への展開を見据えたスケーラビリティ プロジェクト推進と工夫 対象窓口（対象回線）の選定 JBR 様のコンタクトセンターでは、主に一般のお客様からの緊急対応依頼とパートナー店（工務店）や作業員からの業務連絡の 2 つの異なる顧客層からの問い合わせがあります。今回は、業務インパクト、クライアントへの事前周知、エージェントと顧客の会話のパターン化、の観点から業務連絡の窓口を対象としました。 インテント設計 以下は、 Amazon Lex を構成する要素 の一部です : ボット (Bot) : アプリケーションの最上位コンテナで、音声認識と自然言語理解により、ユーザーとテキストや音声で対話します。 インテント (Intent) : ユーザーが実行したい行動や目的を表します。例えば「注文する」「予約する」「問い合わせる」などです。 サンプル発話 (Sample Utterances) : ユーザーがそのインテントを表現する際の典型的な言い回しです。「ピザを注文したい」「大きいピザをお願いします」など、同じ意図でも様々な表現パターンを登録します。 スロット (Slot) : インテントを実行するために必要なパラメータです。注文インテントであれば「商品名」「数量」「配送先」などがスロットになります。 これらの要素を適切に設計することで、ユーザーの意図を正確に理解できるチャットボットを構築できます。 効果的なインテント設計を実現するために、まずエージェントと顧客の過去の会話ログを詳細に分析することからスタートしました。開発部門では会話録音から生成 AI を利用してインテントの候補となるサンプル発話、スロット案を抽出しました。実際のコンタクトセンターオペレーションを担当している CS 部門では、現状の運用業務観点でインテントやスロット案を検討、最終的には両者を統合させてまずはベースとなるインテント、スロット、サンプル発話を決定しました。 表：インテント、スロット、サンプル発話の例 Amazon Lex のテストと品質向上の取り組み 業務連絡用の窓口であっても後続の工程があるため、高い精度と品質が求められました。そこで、評価指標として過去の実績から Amazon Lex による対応で完結する着信を、全体の着信の約 20% と推定して評価を行い、実行テストに力を入れることにしました。まず、Amazon Lex 上で用意されているテスト機能を使用し、各インテント（意図）が最後まで正しく実行されるかを確認しました。このテスト機能はテキスト入力で行うため、想定される入力値と、システムが認識したインテントが合致しているかを視覚的に確認でき、非常に有用でした。このテストでインテントの認識に問題がないことを確認した後、テスト用の電話番号を用意し、実際の電話対応によるテストを実施しました。電話対応でも問題がないことを確認した後、テスト用の電話番号を公開し、案内文言の分かりやすさなど、多角的な視点からフィードバックを集めました。テストでは、 Conversational Analytics with Amazon Connect を有効化し、会話データを収集・分析し、継続的なインテントの改善を行いました。そして、2025 年 9 月にリリースされた Amazon Lex の アシストつきNLR（Assisted NLU） も迅速に設定を適用しました。集めたフィードバックを Amazon Lex のインテントやコールフローに反映して再テストすることで、継続的な精度と品質の向上に注力しました。 また、Coversational Analytics によって文字おこしされた会話データは、以下の「エージェントソフトフォンへの会話要約表示」に活用することでエージェントのオペレーション改善にも繋げることができました。 エージェントソフトフォンへの会話要約表示 継続的なインテントやスロット、サンプル発話の分析のために、Coversational Analytics による会話内容のログ出力を継続しました。以前から CS 部門から会話要約表示機能の実装要望もあったことから、エージェントソフトフォンである CCP への会話要約表示機能の実装を Amazon Lex ボットの実装と並行して実施しました。会話要約は Coversational Analytics の文字起こし機能を利用して音声から文字に変換し、要約表示に必要なフォーマットに変換するために Amazon Bedrock を利用しています。文字起こしの結果は Amazon Bedrock を利用して要約することで、業務要件にあわせたプロンプト設定によって自然で実用的な日本語の要約を実現しました。JBR では通話後にエージェントが通話内容から必要な情報を抽出して、別システムに入力する業務があります。これを CCP に表示された要約内容をそのまま利用することが可能になり、エージェントの後処理時間 (ACW) の短縮にも繋がり、オペレーションの品質向上と正確性の確保も実現することができました。電話応対する現場からは「 受付内容を手動で入力する必要がなく、要約された内容をそのままシステムに転記できるので、作業時間が短縮されました」、「会話中にメモを取ることに集中するあまり、お客様の話を聞き漏らしてしまうケースがありましたが、この機能のおかげで対話に専念できるようになりました」といったフィードバックを得ることができました。 導入成果 初期のリリースでは、対象回線 3 回線、インテント数 19 で開始したところ、約 2,700 から約 4,000 件/月の着信に対して想定したインテントに振り分けられなかった着信が約 46%（エラー率）、Amazon Lex による対応のみで完結した着信が約 7%（ボット率）でした。この結果を受けて、 Coversational Analytics を有効化し、5 月間で約 16,000 件の会話データを収集・分析しました。会話分析では、文字起こしされた会話内容だけでなく、録音された音声データを確認し、通話時のまわりの環境音もインテントの判定に影響を与えているという発見もありました。この分析結果に基づき、うまく振り分けられなかった会話内容や録音を確認して、サンプル発話を追加したり、インテントの追加や集約など地道ながらも継続的な改善を行いました。 結果、初期リリースから 5 ヶ月後には着信数が 4,000 件/月に達するなかでエラー率が約 18%、ボット率が約 15% (評価指標に対して、約75% の達成率) となりました。さらに 3 ヶ月間の継続改善の結果、エラー率が約 2.8% に減りました。 今後の展開 継続的な改善として、Amazon Lex によって想定したインテントに振り分けられなかった着信について会話内容の分析を行なっていくとともに、より柔軟な対応を可能にするため、複数の Amazon Lex ボットを配置することによる用途別対応の検討も進めています。また、エンドユーザー向け窓口への Amazon Lex 展開も計画しています。 JBR  が扱うのは、鍵の紛失や水漏れといった日常生活における緊急事態です。このような状況では、お客様の不安や焦りに寄り添う人間的な対応が不可欠な場面も多く存在します。JBR では、「すべてを自動化する」のではなく、「適切な箇所に、適切なタイミングで、適切な技術を適用する」ことを重視しています。技術による効率化と人間ならではの温かみのある対応を最適にバランスさせることで、真にお客様に価値を提供できるサービスの実現を目指しています。 まとめ JBR の事例は、Amazon Connect と Amazon Lex の組み合わせによって、以下の成果を実現できることを示しています： エージェントのヒアリング業務負荷と ACW の軽減 24 時間 365 日の安定したサービス提供 データ分析に基づく継続的な改善 自動応答割合のコントロールが可能

はじめに Amazon Connect の AI エージェントを構築する際、開発者はお馴染みの課題に直面します。それは、厳しいスケジュールの中で複雑なインテグレーション要件に対応しなければならないことです。複数のバックエンド API の接続、堅牢なエラーハンドリングの実装、リアルなテストデータの生成、複数サービス間のデバッグ、これらすべてをコード品質と一貫性を保ちながら進める必要があります。10〜15 の API を統合する概念実証 (PoC) では、経験豊富なチームでも 2〜3 週間かかることも珍しくありません。バックエンドシステムに直接アクセスできず、リアルに動作するモック実装を作成しなければならない場合では、複雑さはさらに増します。 Kiro はこの状態を変えます。AI コーディングアシスタントの Kiro はシステムアーキテクチャ全体を理解するエキスパートのペアプログラマーとして機能します。 AWS Lambda 関数の本番品質のコード生成、 Amazon DynamoDB スキーマの設計、MCP ツールスキーマの作成、 Amazon CloudWatch Logs の分析による問題特定まで、コードベース全体の一貫性を保ちながら対応します。AI を活用したこのアプローチにより、通常数週間かかる手作業のコーディングを数日に短縮できます。 本記事では、Kiro を使って 15 のバックエンド API を備えた Amazon Connect AI エージェントをわずか 3 日間で構築した方法を紹介します。対話型の開発と、Kiro による CloudWatch ログの自動分析・問題修正の組み合わせで、野心的なスケジュールでどのように高速イテレーションを実現するかを解説します。 課題: API 仕様から動作するエージェントへ このプロジェクトは一般的なシナリオから始まりました。お客様は複雑なカスタマーサービスのワークフローを処理できる Amazon Connect AI エージェントを必要としていたのです。要件は Excel スプレッドシートに記載された 15 の API 仕様として届きました。各行にはエンドポイント、パラメータ、期待されるレスポンス、ビジネスロジックが記述されていました。これらの API は、認証とプロファイル検索、検索と取得操作、予約の変更とキャンセル、支払い処理と検証、ドキュメントの生成と提供、テストとデータ管理のための管理機能など、カスタマーサービス業務の全領域をカバーしていました。 ユースケースは包括的でした。顧客は音声で AI エージェントとやり取りし、エージェントはエンドツーエンドのワークフローを完了するために 15 の API すべてを横断的に呼び出す必要がありました。たとえば、顧客が認証を行い、既存の予約を検索し、予約を変更し、差額を計算し、支払いを処理し、確認書類を要求する、これらすべてを 1 回の会話で行います。AI エージェントはコンテキストを理解し、どの API / ツールをいつ呼び出すかを適切に判断し、エラーを適切に処理し、やり取り全体を通じて自然で有用な応答を提供する必要がありました。 さらに難しかったのは、お客様の開発環境やテスト環境にアクセスできなかったことです。バックエンドシステムはまだ開発中でした。つまり、既存の API に AI エージェントを接続してテストを開始するだけの方法では実現できません。リアルな API 動作をシミュレートし、複数の呼び出しにまたがって状態を維持し、Excel に記述された仕様通りのビジネスロジックを正確に反映し、レスポンスを生成できる、完全なモックバックエンドが必要でした。 タイムラインも厳しいものでした。動作するデモを 3 日間で納品する必要がありました。その間に、モックバックエンドアーキテクチャの設計と実装、15 の API すべての Lambda 関数の作成、リアルなテストデータを含むデータベースの設計と投入、動的なレスポンス生成のための Amazon Bedrock 統合、シームレスな AI エージェント統合のための MCP スキーマの作成、ライブデモでスムーズに動作するようシステム全体のデバッグを完了させる必要がありました。 このシナリオは、現代のソフトウェア開発でよくある課題を反映しています。制約下での高速プロトタイピングです。顧客向けの PoC 構築、ステークホルダーへのコンセプト実証、本格開発前のアーキテクチャ検証など、いずれの場合も同様のプレッシャーがあります。複雑なインテグレーション要件、不完全またはアクセスできないバックエンドシステム、厳しいスケジュール、そして実際の実装に発展できるような本番品質のコードが求められます。 Kiro で Amazon Connect AI エージェント開発を加速する方法 AI を活用した設計 従来のアーキテクチャ設計には、何時間ものリサーチ、設計会議、ドキュメント作成が必要でした。Kiro では異なるアプローチを取りました。AI を活用した仕様駆動設計です。要件 (15 の API、バックエンドアクセスなし、リアルなレスポンスの必要性、Amazon Bedrock AgentCore Gateway 経由の Amazon Connect 統合) を説明すると、Kiro はそれを正式な要件ドキュメントに変換し、次に詳細な設計ドキュメントを作成し、最後に実行可能なタスクリストを生成しました。この仕様駆動ワークフローにより、漏れのない、要件から実装までの明確なトレーサビリティが確保されました。 通常丸 1 日かかるアーキテクチャ設計が、Kiro との 1〜2 時間のインタラクティブな議論で完了し、明確で合理的な設計がすぐに実装可能な状態になりました。 高速なコード生成 アーキテクチャが定まると、Kiro は 15 の Lambda 関数すべてと、関連する Amazon DynamoDB テーブル、 Amazon Bedrock 統合、 AWS IAM 設定を数時間で生成しました。各関数には以下が含まれていました。 – API 仕様の完全な実装 – 構造化されたエラーコードによる適切なエラーハンドリング – 相関 ID トラッキングを含む包括的なログ記録 – 状態管理のための DynamoDB 統合 – リアルなレスポンス生成のための Bedrock 呼び出し – 入力バリデーションと防御的プログラミング コードを素早く開発できただけでなく、さらに Kiro は一貫性の維持にも役立ちました。すべての関数がエラーハンドリング、ログ記録、統合において同一のパターンに従っていました。パターンの調整が必要になった場合 (認証トークンの処理方法の変更やエラーレスポンス形式の修正など)、変更を一度説明するだけで、Kiro が 15 の関数すべてを一貫して更新しました。類似のコンポーネントを手作業で複数実装する際に起こるドリフトや不整合も解消されました。 CloudWatch Logs の自動分析と高速イテレーション Kiro との開発で最も強力だったのは、高速なイテレーションのフィードバックループです。開発サイクルは次のように進みました。 1. Kiro がコードを生成・更新 (Lambda 関数、MCP スキーマ、インフラストラクチャ) 2. CDK で AWS にデプロイ 3. AI エージェントの会話フローをテスト 4. Kiro に CloudWatch Logs (AI エージェント + Lambda 関数) の読み取りを指示 5. Kiro が問題を特定し、根本原因を説明し、修正を提示 6. Kiro に修正の実装と再デプロイを依頼 7. 正常に動作するまで繰り返し このフィードバックループは非常に高速でした。デプロイ、テスト、ログ分析、修正、再デプロイという 1 サイクル全体がわずか 10〜20 分で完了しました。Kiro の自動ログ分析と根本原因の調査能力がなければ、各サイクルで数時間の手動デバッグが必要だったでしょう。 付け加えると Kiro で AI エージェントのログを分析するには、Amazon Connect AI エージェントの CloudWatch へのロギングを有効にする 必要があります。 実際のデバッグ事例 DynamoDB クエリの失敗: Kiro がパーティションキーの不一致を検出し、スキーマの調整を提案 AI エージェントのインテント認識の問題: Kiro が会話ログをレビューし、MCP ツールの説明文に曖昧な表現があることを特定 エラーハンドリングの不備: Kiro がログから処理されていないエッジケースを発見し、防御的なコードを生成 3 日間で数十回のイテレーションサイクルを完了しました。毎回、Kiro の自動ログ分析が手動デバッグのボトルネックを解消し、開発の勢いを維持しました。 まとめ 本記事では、対話型の仕様駆動設計と CloudWatch Logs の自動分析により、Kiro が Amazon Connect AI エージェント開発をどのように加速したかを紹介しました。私たちは 15 のバックエンド API を備えた完全に機能する AI エージェントをわずか 3 日間で構築しました。従来の開発アプローチでは 2〜3 週間かかるスケジュールです。 これを可能にした 3 つの機能は次のとおりです。 仕様駆動設計: インタラクティブな要件収集により、何日もの会議が不要に デバッグの自動化: CloudWatch ログへの直接アクセスで手動トラブルシューティングを排除 高速フィードバックループ: 10〜20 分のイテレーションサイクルで継続的な改善が可能に このアプローチは、今回のユースケースに限らず幅広く適用できます。カスタマーサービスエージェント、テクニカルサポートボット、セールスアシスタントのいずれを構築する場合でも、Kiro による対話型開発と自動デバッグの組み合わせで、Amazon Connect AI エージェントのプロジェクトを大幅に加速できます。 Amazon Connect AI エージェント開発を加速しませんか？ Kiro を使い始めて 、対話型開発と自動デバッグによる、数週間かかっていた作業を数日で実現する体験をお試しください。 Amazon Connect 開発で AI コーディングアシスタントを使ったことはありますか？ ぜひ体験を共有してください。 リソース Kiro Getting Started with Kiro Amazon Connect AI エージェント Amazon Connect AI エージェント Connect AI エージェントを使用したリアルタイムのサポート ワークショップと学習リソース Amazon Connect の Agentic AI を活用したインテリジェントカスタマーサービスの構築 Amazon Connect AI Agents Workshop Enable CloudWatch Logging for AI Agents 関連する AWS ドキュメント Amazon Bedrock AgentCore Gateway (MCP) 著者について Thomas Rindfuss は Amazon Connect のエージェント型・対話型 AI のワールドワイドリード SA です。対話型 AI サービスの新しい技術機能やソリューションの考案、開発、プロトタイピング、エバンジェリズムを通じて、カスタマーエクスペリエンスの向上と導入の促進に取り組んでいます。AI エージェントを構築していないときは、新しい AI テクノロジーの探求や、顧客のコンタクトセンター体験の変革を支援しています。 Kiro は、仕様、ステアリング、フックなどの機能を備えたエージェント型 IDE です。Kiro は本ブログ記事の共著者として、構成の整理、技術的正確性の確認、編集支援を行いました。ブログ記事の共著をしていないときは、開発者のコード作成、ログ分析、システムデバッグの高速化を支援しています。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

本記事は 2026 年 3 月 18 日 に公開された「 How Vanguard transformed analytics with Amazon Redshift multi-warehouse architecture 」を翻訳したものです。 この記事は、Vanguard の Financial Advisor Services 部門の Alex Rabinovich、Anindya Dasgupta、Vijesh Chandran と AWS の共同執筆によるゲスト投稿です。 Vanguard は世界有数の投資会社であり、全世界で 5,000 万人以上の投資家にサービスを提供しています。450 以上の低コストなミューチュアルファンドと ETF を幅広く取り揃え、投資アドバイスや関連する金融サービスを提供しています。約 20,000 人のクルーメンバーを擁し、投資家の長期的な資産形成を支援する低コスト・高品質な投資ソリューションで高い評価を得ています。 Vanguard の Financial Advisor Services (FAS) 部門は、金融サービス業界で最も著名な B2B 事業の一つです。FAS は仲介チャネルを通じて幅広く多様な資産を管理し、全米のアドバイザリーファームやファイナンシャルアドバイザーの広範なネットワークを支援しています。投資商品、モデルポートフォリオ、リサーチ機能、テクノロジーを活用したサポートサービスを一通り提供し、ファイナンシャルアドバイザーがクライアントにより効果的にサービスを提供できるよう支援しています。 ビジネスユースケースと初期アーキテクチャ FAS の事業規模と複雑さは膨大なデータを生み出し、ビジネスインサイト、規制遵守、業務効率化のための高度な分析機能が求められます。Vanguard はこの課題に対応するため FAS 360 イニシアチブを立ち上げました。FAS 360 は、内部・外部のデータソースを統合したクラウドデータウェアハウスを構築し、FAS を強化することを目指しています。 主なビジネスユースケース: 業務オペレーション – 営業目標の設定、進捗管理、報酬管理を通じて業務効率を高めます。ファイナンシャルアドバイザーのクライアントにおける商品利用パターンのインサイトも提供します。 データサイエンス – 顧客セグメンテーションモデルや通話文字起こし分析で戦略的インサイトを導出します。マーケティングキャンペーンの準備や、営業電話に向けた顧客インサイトの提供も支援します。 探索的分析 – 経営層からのアドホックな質問、What-if シナリオ分析、チャネルマネージャー向けの販売トレンド分析や競合比較分析に対応します。 上記のユースケースを一元化されたシステムに統合し、FAS 360 は Vanguard の FAS 部門全体で一貫したレポーティングとデータドリブンな意思決定を実現しています。 集中型データウェアハウス FAS 360: Vanguard のモダナイゼーション第 1 弾では、 Amazon Simple Storage Service (Amazon S3) 上の Parquet ファイルが散在する「データスワンプ（データの沼地）」から、構造化された統合システムへの移行を行い、FAS 360 を集中型エンタープライズデータウェアハウスとして確立しました。 以下のアーキテクチャ図は、生データの保存に Amazon S3 を活用し、コア処理エンジンとして Amazon Redshift を使用する構成です。BI ツール、アナリストの探索、データサイエンスワークロードへの統合的なアクセスを提供しています。 アーキテクチャで得られた主な成果: 信頼できる唯一の情報源 – 分散していたデータソースを統合システムに集約し、データの不整合を解消して、組織全体で一貫したレポーティングを確立しました クエリパフォーマンス 10 倍向上 – 以前のソリューションと比較してクエリ応答時間が大幅に改善され、アナリストの生産性向上とより複雑な分析ワークロードの実行が可能になりました シームレスなデータレイク統合 – より広範なデータレイク環境との接続性を維持しつつ、構造化されたウェアハウス機能を提供しました ビジネスの俊敏性向上 – メトリクスへの信頼性が高まり、以前は実現困難だった新しいユースケースが可能になり、FAS360 システムへの移行の推進力となりました 集中型アーキテクチャにより、データが個人に分散しガバナンスが限定的だった従来の課題を解決し、その後のアーキテクチャ進化の基盤を確立しました。 急速な成長と拡大するユースケース Vanguard FAS のデータ分析要件は 2 年間で著しい成長を遂げ、現代のデータニーズの急速な進化を示しています。 初期状態: 日次データロードを処理する AWS Glue ETL ジョブ 20 本 データウェアハウス内のテーブル数 約 100 ビジネスユーザー向け Tableau ダッシュボード 20 個 システムにアクセスするアナリスト 約 60 名 2 年後: Amazon Redshift に 20 TB、S3 データレイクに 150 TB のデータ量 複雑なデータ変換を処理する AWS Glue ETL ジョブ 600 本以上 (30 倍増) 多様なビジネスデータを格納するテーブル 300 以上 (3 倍増) クエリパフォーマンスを最適化する Amazon Redshift マテリアライズドビュー 250 以上 さまざまなビジネス機能に対応する Tableau ダッシュボード 500 以上 (25 倍増) 月間 500,000 以上のユーザークエリ 急激な成長の背景には、リスク管理やコンプライアンスからクライアントサービスの最適化、業務効率改善に至るまで、ビジネス機能全体でデータドリブンな意思決定への依存度が FAS 部門で高まっていることがあります。 リソース競合とパフォーマンスのボトルネック Vanguard FAS のデータ環境が拡大するにつれ、初期アーキテクチャである 2 ノード (ra3.4xlarge) の単一 Amazon Redshift プロビジョンドクラスターで深刻なパフォーマンス課題が発生し、ビジネスオペレーションに支障をきたすようになりました。 ETL パフォーマンスの問題: ETL の SLA 違反が頻発し、重要なビジネスプロセスに影響 Tableau データ抽出の失敗によるダッシュボードデータの陳腐化 データ取り込みと変換ワークロード間のリソース競合 エンドユーザー体験の劣化: ピーク時のクエリパフォーマンス低下 テーブルやオブジェクトのロック問題による同時アクセスの阻害 深い分析探索ができずフラストレーションを抱えるアナリスト 長時間実行の分析クエリが実行困難 運用上の課題: ETL ワークロードとインタラクティブ分析間のリソース競合 ワークロードタイプごとにコンピューティングリソースを独立してスケールできない データオペレーション全体に影響する単一障害点 ワークロードの優先順位付けとリソース配分の困難さ パフォーマンスの課題は、日常の業務レポーティングから戦略的なビジネス分析に至るまで、FAS がデータ資産を効果的に活用する能力を根本的に制限していました。 ソリューション概要 上記の課題に対処するため、Vanguard FAS は Amazon Redshift のデータ共有機能を活用し、ワークロードの分離と独立したスケーリングを実現するマルチウェアハウスアーキテクチャを実装しました。 プロデューサー – Amazon Redshift プロビジョンドクラスター 中央ハブは RA3 ノードを搭載した元の Amazon Redshift プロビジョンドクラスターで構成され、安定した予測可能なワークロード向けに最適化されています。 専用 ETL 処理: データの取り込み、変換、ロード処理を担当 書き込みワークロードの最適化: 干渉なくデータの書き込みと更新を管理 コスト最適化: 予測可能な定常ワークロードにリザーブドインスタンスを活用 データガバナンス: エンタープライズデータの信頼できる唯一の情報源として機能 コンシューマー – Amazon Redshift Serverless ワークグループ 複数の Amazon Redshift Serverless インスタンスが、需要に応じてコンピューティングリソースを自動スケールする専用のコンシューマーエンドポイントとして機能します。 アナリスト探索: アナリストのデータ探索と実験のための専用環境 BI ツール: Tableau ダッシュボードと可視化ワークロードに特化して最適化されたインスタンス データサイエンス: 完全に分離された環境での複雑かつ長時間実行の機械学習ワークロード向け Amazon Redshift のネイティブなデータ共有機能により、プロデューサーとコンシューマーインスタンス間をセキュアに接続しています。コンシューマークラスターはデータ移動なしにプロデューサーのライブデータにアクセスでき、常に最新の情報を参照できます。ゼロコピー共有アプローチにより、データの複製や複雑な同期プロセスが不要になり、ストレージコストと運用の複雑さの両方を削減できます。 成果 マルチウェアハウスアーキテクチャの実装により、主要なパフォーマンス指標全体で大幅な改善が実現しました。 安定したパフォーマンス 夜間の ETL サイクルが午前 9 時の SLA 前に安定して完了するようになり、ビジネスオペレーションを妨げていた SLA 違反が解消されました。朝のビジネス活動に向けて最新のデータが確実に利用可能になっています。ダッシュボードやレポートに最新のデータが反映され、チームは意思決定に必要なインサイトを得られるようになりました。 アナリストの生産性と体験の向上 新しいアーキテクチャにより、深いアドホック探索クエリを妨げていた 10 分間のクエリタイムアウト制限が撤廃されました。アナリストは完全に分離された環境で、他のユーザーや ETL プロセスに影響を与えることなく、30 分を超える複雑な分析ワークロードを実行できるようになりました。クエリ応答時間の大幅な短縮と合わせて、チーム全体でアナリストの満足度と生産性が向上しました。 新しい分析機能 マルチウェアハウスアーキテクチャにより、アナリストが CREATE TABLE AS SELECT (CTAS) コマンドでデータを実験できる書き込みアクセス権を持つ専用の「Data Lab」環境が導入されました。各ワークロードタイプが需要に応じて独立してスケールでき、異なるコンシューマークラスターが特定のユースケースに最適化されているため、より高度な分析アプローチが可能になりました。 オペレーショナルエクセレンス ワークロードの分離により、異なるパターン間でコンピューティングリソースを効率的に活用できるようになり、適切なサイジング、Serverless の従量課金、リザーブドインスタンスの活用によるコスト管理が改善されました。ETL と分析ワークロードの明確な分離により、データプラットフォーム全体の管理が簡素化されました。 継続的なモダナイゼーション: データメッシュアーキテクチャへの進化 Vanguard のデータ環境が成熟し、マルチウェアハウスアーキテクチャの成功が組織全体での幅広い採用を可能にしたことで、組織の成長に合わせたアーキテクチャ進化の機会を認識しました。データプロダクトのポートフォリオ拡大とシステムを活用するチーム数の増加が、新たな改善の機会を生み出しました。 Vanguard のデータ環境が成長するにつれ、3 つの主要な課題が浮上しました。 集中型オーナーシップのボトルネック – 単一チームによるデータオーナーシップでは、増加するデータプロダクトに対応しきれない 書き込みワークロードの競合 – 共有エンドポイントでの書き込み操作にリソース競合が残存 クロスドメインの依存関係 – ビジネスドメイン間のデータオブジェクトの相互依存がデータプロダクト開発を遅延させる データメッシュ採用の理由 Vanguard が データメッシュ を採用した背景には、以下のニーズがありました。 データオーナーシップの分散化 – 専任のスチュワードを配置したデータドメインを確立 書き込み競合の解消 – 各ドメインのデータロードを個別のエンドポイントに分離 自律的な開発の実現 – スチュワードがデータプロダクトのライフサイクルとガバナンス全体をオーナーシップを持って管理 最新のデータレイク機能の活用 – AWS Glue と Apache Iceberg フォーマットによるデータプロダクトのキュレーション データメッシュへの進化は、マルチウェアハウスアーキテクチャで達成した技術基盤とオペレーショナルエクセレンスを土台に、Vanguard が組織的にスケールする能力を支えるものです。Amazon Redshift マルチウェアハウス実装の成功を基盤として、Vanguard FAS はデータアーキテクチャ進化の次のフェーズとして、以下のデータメッシュアプローチの検討を進めています。 データメッシュアーキテクチャには、スケーラブルでドメイン指向のデータ管理を実現するために連携する複数の主要コンポーネントがあります。 ドメイン指向のデータオーナーシップ Vanguard はビジネス機能に沿った個別のデータドメインを確立し、各ドメインに専任のデータスチュワードを配置して明確なオーナーシップとアカウンタビリティを実現しています。集中型のデータ管理から分散型モデルへの移行により、データに近いチームがドメイン固有のニーズについて的確な判断を下せるようになります。 分散型データアーキテクチャ 新しいアーキテクチャでは、ドメイン固有のデータロードを個別のコンピューティングエンドポイントに分離し、各ドメインに独立したデータ処理パイプラインを構築しています。クロスドメインの依存関係や競合が軽減され、チームは組織全体の調整を待つことなく変更の反復とデプロイが可能になります。 データプロダクトアプローチ Vanguard は Apache Iceberg フォーマットを使用してデータレイク上でデータプロダクトをキュレーションし、メトリクスの計算とデータレイク統合に AWS Glue を活用しています。データをプロダクトとして扱い、定義された SLA と品質メトリクスを設定することで、ダウンストリームのコンシューマーが信頼して利用できる高品質なデータ配信を実現しています。 セルフサービス分析 ドメインチームはエンタープライズガバナンス基準を維持しながら、データプロダクトのライフサイクル全体を独立して管理できます。Vanguard は独立したデータ管理のためのツールとシステムを提供し、データ品質やセキュリティを損なうことなく迅速なイノベーションを可能にし、組織全体でインサイト獲得までの時間を短縮しています。集中型データウェアハウスからマルチウェアハウスアーキテクチャ、そして完全に分散されたドメイン指向のデータメッシュへの進化は、Vanguard の継続的な成長に対応する自然な発展です。 まとめ Vanguard Financial Advisor Services の取り組みは、分析のスケーリングが単一ウェアハウスの拡大ではなく、ワークロードの分離、独立したスケーリング、組織の成長に対応するアーキテクチャ設計にあることを示しています。 2 ノードの RA3 プロビジョンドクラスターから Amazon Redshift Serverless とプロビジョンドを組み合わせたマルチウェアハウスアーキテクチャへの進化により、Vanguard は本番環境で以下の成果を達成しました。 月間 500,000 以上のクエリ を ETL やダッシュボードの競合なしに処理 ETL SLA 遵守率 100% – 夜間パイプラインが午前 9 時前に完了 BI 利用 25 倍増 (Tableau ダッシュボード 20 → 500 以上) をパフォーマンス劣化なしに実現 アナリスト数 8 倍増 (60 → 500 名以上) をワークロード分離で実現 ETL パイプライン 30 倍増 (20 → 600 本以上) を取り込みロジックの再設計なしに実現 Amazon Redshift のゼロコピーデータ共有 をプロデューサーとコンシューマーウェアハウス間で実現し、データの複製と同期コストを最小化 10 分間のクエリ制限を撤廃 し、高度な探索的分析や長時間実行の分析を実現 注目すべきは、コンピューティングの過剰プロビジョニングではなく、ワークロードごとのコンピューティングの適正化と専門化で成果を達成した点です。需要が予測可能な ETL にはキャパシティを予約し、需要が変動する BI やアドホック分析には Amazon Redshift Serverless の自動スケーリングを活用しています。 Vanguard がドメイン指向のデータメッシュへと進む中、マルチウェアハウスアーキテクチャは組織のスケール、データプロダクトのオーナーシップ、自律的な分析を実現するための基盤であるという教訓が得られました。データ分析要件の成長に直面している組織にとって、Vanguard のアプローチは参考になるでしょう。適切なアーキテクチャと AWS サービスの活用により、パフォーマンスの大幅な改善、コスト削減、ビジネス価値の創出を加速する新しい分析機能を実現できます。 AWS では、 AWS アカウントチーム にご連絡いただき、AWS アナリティクススペシャリストによるアーキテクチャガイダンスとお客様に合わせた推奨事項をご活用ください。 © 2026 The Vanguard Group, Inc. and Amazon Web Services, Inc. All rights reserved. This material is provided for informational purposes only and is not intended to be investment advice or a recommendation to take any particular investment action. 著者について Alex Rabinovich Alex は、Vanguard の Financial Advisory Services 部門のデータエンジニアリングディレクターです。大規模なデータエンジニアリングプラットフォームとモダナイゼーションイニシアチブをリードし、AWS クラウド上で信頼性が高くスケーラブルかつ高パフォーマンスなデータシステムの構築に注力しています。 Anindya Dasgupta Anindya は、Vanguard の Financial Advisor Services Technology 部門のソリューションアーキテクトです。複雑なビジネス課題に対応するエンタープライズテクノロジーソリューションの構築に 25 年以上の経験があります。スケーラブルなクラウドネイティブかつデータドリブンなシステムの設計を専門とし、アプリケーション開発、システム統合、概念実証に実践的に取り組んでいます。 Vijesh Chandran Vijesh は、ソリューションデザインの責任者として、重要なビジネス成果を支えるエンタープライズテクノロジーソリューションのアーキテクチャと設計を統括しています。クラウドネイティブプラットフォーム上のデータアーキテクチャやデータドリブンシステムに精通し、テクノロジー設計とビジネス戦略の整合に注力しています。ソリューションの方向性、統合パターン、概念実証の推進に実践的に関わっています。 Raks Khare Raks は、ペンシルベニア州を拠点とする AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。さまざまな業界や地域のお客様が AWS プラットフォーム上で大規模なデータ分析ソリューションを構築するのを支援しています。仕事以外では、新しい旅行先やグルメスポットの開拓、家族との時間を楽しんでいます。 Poulomi Dasgupta Poulomi は、AWS のシニアアナリティクスソリューションアーキテクトです。お客様がクラウドベースの分析ソリューションでビジネス課題を解決するのを支援することに情熱を注いでいます。仕事以外では、旅行や家族との時間を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 3 月 18 日 に公開された「 Scale fine-grained permissions across warehouses with Amazon Redshift and AWS IAM Identity Center 」を翻訳したものです。 Amazon Redshift は、フルマネージドでペタバイト規模のクラウドデータウェアハウスで、分析ワークロードを容易にスケールできます。複数のビジネスユニットにまたがって分析機能を拡張する際、各ウェアハウスのきめ細かなアクセス許可を効率的に定義・管理する手法が求められます。多くの組織では、Microsoft Entra ID、Okta、Ping などの外部 ID プロバイダー (IdP) を使用してワークフォース ID を一元管理しており、一貫したアクセス制御でデータウェアハウスを効率的に統合する必要があります。この課題に対応するため、 Amazon Redshift フェデレーテッドアクセス許可 と AWS IAM Identity Center の統合が導入されました。セキュリティポリシーを一度定義すれば、アカウント内のすべてのウェアハウスに自動的に適用できます。 Amazon Redshift フェデレーテッドアクセス許可は、IAM Identity Center を通じて 複数の AWS リージョン で利用できるようになりました。Microsoft Entra ID、Okta、Ping Identity、OneLogin などのサポートされている ID プロバイダー (IdP) の ID を、IAM Identity Center を通じてサポートされている AWS リージョン間で使用できます。レジリエンシーやユーザーへの近接性といったビジネス要件に対応できます。IAM Identity Center をプライマリ AWS リージョンから、データレジデンシー要件に基づいて追加のリージョンに拡張できるようになりました。そのリージョンでは、Amazon Redshift フェデレーテッドアクセス許可を使用して複数のウェアハウスに新しいウェアハウスを追加し、水平方向のマルチウェアハウススケーラビリティを実現できます。Redshift フェデレーテッドアクセス許可では、そのリージョン内の任意の Redshift ウェアハウスからデータアクセス許可を一度定義すれば、そのリージョンのアカウント内のすべてのウェアハウスに自動的に適用されます。 本記事では、Amazon Redshift フェデレーテッドアクセス許可と AWS IAM Identity Center を実装し、複数のデータウェアハウスにまたがるスケーラブルなデータガバナンスを実現する手順を紹介します。Enterprise Data Warehouse (EDW) がプロデューサーデータウェアハウスとして一元的なポリシー定義を持ち、手動で再設定することなく Sales および Marketing のコンシューマーデータウェアハウスにセキュリティポリシーを自動適用するアーキテクチャを示します。以下の内容を扱います。 データ共有のプロデューサーとコンシューマーの両方に対する IAM Identity Center 接続の設定 Amazon Redshift Serverless 名前空間の AWS Glue Data Catalog への登録 信頼できる ID の伝播のセットアップ 動的データマスキング ポリシーの作成とアタッチによる、顧客の生年月日などの個人情報 (PII) の保護 ユーザーロールに基づくデータの可視性を制御する 行レベルセキュリティ ポリシーの実装 IdP グループから Amazon Redshift データベースロールへのマッピングによるシームレスなアクセス管理 前提条件 開始前に以下を確認してください。 管理者ロール権限を持つ AWS アカウント 上記の管理者ロールにデータレイク管理者権限を割り当てる。手順については、 データレイク管理者の作成 を参照 Lake Formation を使用した IAM Identity Center 統合 を有効化 AWS IAM Identity Center と Amazon Redshift Query Editor v2 のセットアッププロセスを理解するため、 こちらのブログ記事 を確認 AWS アカウントで IAM Identity Center を有効化し、「ソリューション概要」セクションの「ユーザーアクセス」(図 2) に記載されているユーザーとグループを作成 Amazon Redshift スーパーユーザーとして、 AWSIDC:awssso-admin データベースロールに CONNECT 、CREATE TABLE、INSERT、SELECT、sys:secadmin の権限を付与 IAM Identity Center アクセス用の IAM ロール: ステップ 1 : Amazon Redshift アクセス用の IAM ポリシーを作成する 。Amazon Redshift と IAM Identity Center を統合するため、Amazon Redshift データウェアハウスが存在するアカウントに IAM ポリシー (例: aws-idc-policy) を作成します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "redshift:DescribeQev2IdcApplications", "redshift-serverless:ListNamespaces", "redshift-serverless:ListWorkgroups", "redshift-serverless:GetWorkgroup" ], "Resource": [ "arn:aws:redshift-serverless:<AWS Region>:<AWS Account ID>:workgroup/*", "arn:aws:redshift-serverless:<AWS Region>:<AWS Account ID>:namespace/*" ] }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "sso:DescribeApplication", "sso:DescribeInstance" ], "Resource": [ "arn:aws:sso:::instance/<IAM Identity Center Instance ID>", "arn:aws:sso::<AWS Account ID>:application/<IAM Identity Center Instance ID>/*" ] } ] } ステップ 2 : IAM ロールを作成する 。Amazon Redshift データウェアハウスが存在するアカウントに IAM ロール (Amazon Redshift – カスタマイズ可能) を作成します (例: IAMIDCRedshiftRole)。 ステップ 3 : IAM ポリシーをロールにアタッチする 。上記のロールに以下の 2 つの IAM ポリシーをアタッチします。 aws-idc-policy AmazonRedshiftFederatedAuthorization ステップ 4 : 信頼関係を更新する 。このロールの信頼関係を以下のように更新します。 {   "Version": "2012-10-17",   "Statement": [     {       "Effect": "Allow",       "Principal": {         "Service": "redshift.amazonaws.com"       },       "Action": [         "sts:AssumeRole",         "sts:SetContext"       ]     }   ] } 注意: AmazonRedshiftFederatedAuthorization は、Amazon Redshift フェデレーテッド認可でクエリを実行するために必要な権限を提供するマネージドポリシーです。 上記の IAMIDCRedshiftRole IAM ロールをすべての Redshift Serverless エンドポイントにアタッチ ソリューション概要 以下のアーキテクチャ図は、マルチウェアハウス環境でのフェデレーテッドアクセス許可を示しており、セキュリティポリシーを自動適用し、Amazon Redshift ウェアハウス全体でスケーラブルなデータガバナンスを実現します。 図 1: サンプルアーキテクチャ図 ユーザーアクセス ユーザーは、Amazon Redshift Query Editor v2、サードパーティの SQL エディター (DBeaver や SQL Workbench など)、またはカスタムクライアントアプリケーションを通じてデータウェアハウスにアクセスできます。どのアクセス方法でも一貫したセキュリティが適用されます。 図 2: ソリューション概要フロー AWS IAM Identity Center の統合 IAM Identity Center は、シングルサインオンによる一元的な認証を提供し、組織内のロールに基づいて権限を自動的に割り当てます。ID フェデレーションにより企業の ID が AWS リソースに直接リンクされ、ウェアハウスへのアクセス前に認証が行われます。 マルチウェアハウスアーキテクチャ このアーキテクチャでは、異なるビジネス機能を持ちつつ、セキュリティポリシーを共有する 3 つのデータウェアハウスを使用します。 Enterprise Data Warehouse (EDW) EDW は、エンタープライズデータの中央リポジトリです。顧客データと製品データは Customer Profile Database (CPD) に格納されており、管理者は 2 つのセキュリティポリシーを定義します。 動的データマスキング (DDM) – Sales Analyst と Marketing Analyst の両方のロールに対して、顧客の生年月日 (DOB) フィールドをマスキングし、分析作業を妨げずに個人情報 (PII) を保護します 行レベルセキュリティ (RLS) – ユーザーロールに基づいて製品の可視性を制御します。Sales Analyst は launched (発売済み) の製品のみ表示でき、Marketing Analyst は launched と planned (計画中) の両方の製品を表示できます EDW は AWS Glue Data Catalog に登録され、統合メタデータリポジトリを作成し、アカウント内のウェアハウス全体でデータを検出可能にします。この登録がフェデレーテッドアクセス許可の基盤となり、ポリシーを自動伝播できます。 Sales データウェアハウス Sales Analyst が顧客テーブルと製品テーブルをクエリすると、フェデレーテッドアクセス許可により EDW で定義したポリシーが自動的に適用されます。EDW の登録済み名前空間が外部データベースとして自動マウントされるため、ポリシーの再作成や再アタッチは不要です。顧客の DOB フィールドはマスキングされ、 launched の製品のみが表示されます。追加設定は不要です。 Marketing データウェアハウス Marketing データウェアハウスも EDW のセキュリティポリシーを自動的に継承します。顧客の DOB フィールドは PII 保護のためマスキングされたままですが、RLS ポリシーにより Marketing Analyst は launched と planned の両方の製品を表示できます。マーケティング計画に必要な広範な可視性が確保されます。アクセス制御はユーザーロールに基づいて自動的に適用されます。 ウォークスルー ここでは 2 つの Amazon Redshift IAM Identity Center (IDC) 接続を作成します。 データ共有プロデューサー Identity Center 接続 – edw-wg Amazon Redshift Serverless ワークグループに割り当て データ共有コンシューマー Identity Center 接続 – cpd-sales-wg および cpd-marketing-wg Amazon Redshift Serverless ワークグループに割り当て Amazon Redshift フェデレーテッドアクセス許可用の IDC 接続をセットアップする ウェアハウス間のフェデレーテッド認証を有効にする IAM Identity Center 接続を設定します。プロデューサー (ポリシー定義) ウェアハウスとコンシューマーウェアハウス用に個別の接続を作成します。 Amazon Redshift データ共有プロデューサー IDC 接続を設定する プロデューサー IDC 接続を作成するには: Amazon Redshift Serverless コンソール を開きます。 ハンバーガーメニューを展開して IAM Identity Center connections を選択します。 Create application を選択します。 「Amazon Redshift connected to IAM Identity Center」と表示されていることを確認し、 Next を選択します。 接続プロパティを設定します。 IAM Identity Center display name に名前を入力します。 Managed application name に rs-multicluster-producer と入力します。 Identity provider namespace で AWSIDC を選択します。 IAM role for IAM Identity Center access で、作成した IAM ロールを選択します。 Query editor v2 application で Enable the query editor v2 application を選択します。 IAM Identity Center application type で Configure Amazon Redshift federated permissions using AWS IAM Identity Center (Recommended) を選択します。 Next を選択します。 Configure client connections that use third-party IdPs で No を選択します。 Next を選択します。 設定内容を確認し、 Create Application を選択します。 図 3: データ共有プロデューサー IDC 接続 データ共有コンシューマー IDC 接続を設定する コンシューマー IDC 接続を作成するには: Amazon Redshift Serverless コンソール を開きます。 ハンバーガーメニューを展開して IAM Identity Center connections を選択します。 Create application を選択します。 「Amazon Redshift connected to IAM Identity Center」と表示されていることを確認し、 Next を選択します。 接続プロパティを設定します。 IAM Identity Center display name に名前を入力します。 Managed application name に rs-multicluster-consumer と入力します。 Identity provider namespace で AWSIDC を選択します。 IAM role for IAM Identity Center access で、作成した IAM ロールを選択します。 Query editor v2 application には「You already have a query editor v2 application.」という通知が表示されます。 IAM Identity Center application type で Configure Amazon Redshift federated permissions using AWS IAM Identity Center (Recommended) の選択を 解除 します。 Trusted identity propagation で AWS Lake Formation access grants と Amazon Redshift Connect を選択します。 Next を選択します。 Configure client connections that use third-party IdPs で No を選択します。 Next を選択します。 設定内容を確認し、 Create Application を選択します。 Amazon Redshift データ共有コンシューマーの IDC アプリケーションに必要なユーザーまたはグループを追加します。 図 4: データ共有コンシューマー IDC 接続 Amazon Redshift Serverless 名前空間に対するデータ共有プロデューサー IDC 接続を設定する フェデレーテッドアクセス許可で edw-ns 名前空間を登録するには: Amazon Redshift Serverless Namespace コンソール を開きます。 Amazon Redshift Serverless 名前空間を選択します。 Actions を選択し、 Register with AWS Glue Data Catalog を選択します。 Register with Amazon Redshift federated permissions を選択します。 Amazon Redshift federated permissions using AWS IAM Identity Center を選択します。 Register を選択します。 図 5: Amazon Redshift データウェアハウスの Glue Data Catalog への登録 図 6: Amazon Redshift データウェアハウスの Glue Data Catalog への登録 注意: 作成したデータ共有プロデューサー IDC 接続の IAM Identity Center マネージドアプリケーション ARN が使用されます。 既存の Serverless 名前空間に対するデータ共有コンシューマー IDC 接続を設定する cpd-sales-wg と cpd-marketing-wg の Serverless ワークグループについて、登録済みの IAM Identity Center 接続から以下の情報を収集します。 IAM Identity Center display name Identity provider namespace IAM Identity Center managed application ARN IAM role for IAM Identity Center access データベース管理者として以下の SQL コマンドを実行し、統合を有効にします。 CREATE IDENTITY PROVIDER "<IAM Identity Center display name>" TYPE AWSIDC NAMESPACE '<Identity provider namespace>' APPLICATION_ARN '<IAM Identity Center managed application ARN>' IAM_ROLE '<IAM role for IAM Identity Center access>'; 既存の ID プロバイダーを変更するには、ALTER IDENTITY PROVIDER コマンドを使用します。 ALTER IDENTITY PROVIDER "<IAM Identity Center display name>" NAMESPACE '<Identity provider namespace>'; ALTER IDENTITY PROVIDER "<IAM Identity Center display name>" IAM_ROLE default | '<IAM role for IAM Identity Center access>'; プロデューサーでのデータ準備とアクセス設定 顧客テーブルと製品テーブルを作成し、サンプルデータをロードし、DDM と RLS ポリシーを作成してデータベースロールにアタッチし、SELECT 権限を付与します。 EDW でデータを準備する IDC Admin ユーザーとして EDW データウェアハウスに接続し、以下の SQL コマンドを実行します。 product テーブルを作成します。 CREATE TABLE product ( product_id VARCHAR(16) NOT NULL, product_desc VARCHAR(200), current_price NUMERIC(7,2), wholesale_cost NUMERIC(7,2), category_desc VARCHAR(50), launch_status VARCHAR(50) ); サンプルの product データを挿入します。 INSERT INTO product VALUES ('AAAAAAAAAFNPEAAA','At least concerned authors adopt just brown, federal',7.12,4.12,'Jewelry','launched'), ('AAAAAAAAOAAGDAAA','Complex services may not find totally changing accountants. Tiny, available ministers could not know always systems. Hot, male speakers discer',8.08,5.49,'Shoes','planned'), ('AAAAAAAAMJJMCAAA','Rows could prevent political, old duties. Just international stairs would regret police. Conditions discard always interesting, warm years. Present jobs shall take nearby relatively dreadful',8.18,5.31,'Jewelry','launched'), ('AAAAAAAAKLBLBAAA','Suddenly external sentences believe then by the assets. Simultaneously young feet could not probe separately shortly new men. Forms work again individuals. Images',17.96,7.9,'Shoes','launched'), ('AAAAAAAAMBKMCAAA','Clubs see finally materials. Significant objectives sell fairly left, civil power',3.18,3.84,'Books','launched'), ('AAAAAAAACPCAAAAA','Perhaps past preferences tell rather to a accounts. Very common feet can command never available final years; minutes expect recent, due employers. Altogether english shoes',9.84,0.19,'Electronics','planned'), ('AAAAAAAAFOIABAAA','More responsible characters go left factors. Championships shall stand twice new, important shows. Books could receive too able, national pounds. Central',3.55,2.2,'Books','launched'), ('AAAAAAAAKGBIAAAA','High, political changes shall not',9.55,5.25,'Electronics','launched'); customer テーブルを作成します。 CREATE TABLE customer ( customer_id VARCHAR(16), first_name VARCHAR(20), last_name VARCHAR(30), date_of_birth VARCHAR(32), birth_country VARCHAR(20), email_address VARCHAR(50) ); サンプルの customer データを挿入します。 INSERT INTO customer VALUES ('AAAAAAAALAMKHGBA','Regina','Coleman','1926-12-17','GAMBIA','Regina.Coleman@JFFRohn.edu'), ('AAAAAAAAMCMKHGBA','John','Bell','1980-01-07','PAPUA NEW GUINEA','John.Bell@uAR3ReP6yi9eDyq.edu'), ('AAAAAAAANNMKHGBA','Jacqueline','Pierre','1951-12-18','SAMOA','Jacqueline.Pierre@UQcHfFDEVdj.com'), ('AAAAAAAANFNKHGBA','Frank','Mackay','1992-03-19','HONG KONG','Frank.Mackay@MzAI.edu'), ('AAAAAAAAOGNKHGBA','Anthony','Miller','1948-02-26','ALGERIA','Anthony.Miller@pF.edu'), ('AAAAAAAACPOKHGBA','Bradley','Sawyer','1956-12-25','ZAMBIA','Bradley.Sawyer@kAXu5U1MrRRkAqP.edu'), ('AAAAAAAAOIPKHGBA','Robert','Carter','1951-01-01','UNITED STATES','Robert.Carter@Z.org'), ('AAAAAAAALJPKHGBA','Ola','High','1980-11-19','SUDAN','Ola.High@N.org'); DDM と RLS ポリシーを作成する customer の生年月日に対するマスキングポリシーを作成します。 CREATE MASKING POLICY mask_cust_dob WITH (date_of_birth VARCHAR(32)) USING (sha2(date_of_birth, 256)::TEXT); product の launch_status に対する RLS ポリシーを作成します。 CREATE RLS POLICY product_launch_status WITH (launch_status VARCHAR(50)) USING (launch_status = 'launched'); CREATE RLS POLICY product_launch_status_all WITH (launch_status VARCHAR(50)) USING (launch_status IN ('launched','planned')); Sales グループと Marketing グループ用の Amazon Redshift DB ロールを作成する データベースロールを作成します。 CREATE ROLE "AWSIDC:awssso-sales"; CREATE ROLE "AWSIDC:awssso-marketing"; マスキングポリシーをアタッチする 両方のロールにマスキングポリシーをアタッチします。 ATTACH MASKING POLICY mask_cust_dob ON dev.public.customer (date_of_birth) TO ROLE "AWSIDC:awssso-marketing"; ATTACH MASKING POLICY mask_cust_dob ON dev.public.customer (date_of_birth) TO ROLE "AWSIDC:awssso-sales"; RLS ポリシーをアタッチし、product テーブルで RLS を有効にする RLS ポリシーをアタッチし、行レベルセキュリティを有効にします。 ATTACH RLS POLICY product_launch_status ON dev.public.product TO ROLE "AWSIDC:awssso-sales"; ATTACH RLS POLICY product_launch_status_all ON dev.public.product TO ROLE "AWSIDC:awssso-marketing"; ALTER TABLE dev.public.product ROW LEVEL SECURITY ON; テーブルへのアクセス権をロールに付与する 両方のロールに SELECT 権限を付与します。 GRANT SELECT ON dev.public.customer TO ROLE "AWSIDC:awssso-sales"; GRANT SELECT ON dev.public.customer TO ROLE "AWSIDC:awssso-marketing"; GRANT SELECT ON dev.public.product TO ROLE "AWSIDC:awssso-sales"; GRANT SELECT ON dev.public.product TO ROLE "AWSIDC:awssso-marketing"; IAM Identity Center を使用して Sales データウェアハウスに接続する Sales Analyst として接続するには: IAM Identity Center 接続タイプを使用して、ユーザー sales-analyst として cpd-sales-wg に接続し、 Continue を選択します。 sales-analyst を選択し、 Next を選択します。 パスワードを入力し、 Sign in を選択します。 MFA コードを入力し、 Sign in を選択します。 Amazon Redshift Query Editor V2 で sales-analyst として cpd-sales-wg に接続できました。 図 7: IDC ユーザーとして Sales データウェアハウスに接続 Sales Analyst として共有データをクエリする 動的データマスキングが適用された customer テーブルをクエリします。 SELECT * FROM "dev@edw-ns"."public"."customer"; customer テーブルにアクセスできますが、 date_of_birth 列の機密情報は暗号化されています。 図 8: customer テーブルの結果セット 行レベルセキュリティが有効な product テーブルをクエリします。 SELECT * FROM "dev@edw-ns"."public"."product"; product テーブルにアクセスできますが、 launch_status が launched の製品のみ表示されます。 図 9: product テーブルの結果セット 注意: Amazon Redshift フェデレーテッドアクセス許可にオンボードされたデータ共有プロデューサーに IDC ユーザーとして接続するには、スーパーユーザーが接続しようとする IDC ユーザーに CONNECT 権限を付与する必要があります。CONNECT 権限の付与方法については、Amazon Redshift データベースデベロッパーガイドの Connect privileges を参照してください。 IAM Identity Center を使用して Marketing データウェアハウスに接続する Marketing Analyst として接続するには: IAM Identity Center 接続タイプを使用して、ユーザー marketing-analyst として cpd-marketing-wg に接続し、 Continue を選択します。 marketing-analyst を選択し、 Next を選択します。 パスワードを入力し、 Sign in を選択します。 MFA コードを入力し、 Sign in を選択します。 Amazon Redshift Query Editor V2 で marketing-analyst として cpd-marketing-wg に接続できました。 図 10: IDC ユーザーとして Marketing データウェアハウスに接続 Marketing Analyst として共有データをクエリする 動的データマスキングが適用された customer テーブルをクエリします。 SELECT * FROM "dev@edw-ns"."public"."customer"; customer テーブルにアクセスできますが、 date_of_birth 列の機密情報は暗号化されています。 図 11: customer テーブルの結果セット 行レベルセキュリティが有効な product テーブルをクエリします。 SELECT * FROM "dev@edw-ns"."public"."product"; product テーブルにアクセスでき、 launch_status が launched と planned の両方の製品を表示できます。 図 12: product テーブルの結果セット 追加リソース フェデレーテッドアクセス許可の実装について詳しくは、以下のリソースを参照してください。 AWS ドキュメント Amazon Redshift フェデレーテッドアクセス許可 Amazon Redshift クエリエディタ v2 からの接続のトラブルシューティング AWS ブログ Amazon Redshift フェデレーテッドアクセス許可でマルチウェアハウスのデータガバナンスを簡素化する Integrate Identity Provider (IdP) with Amazon Redshift Query Editor V2 and SQL Client using AWS IAM Identity Center for seamless Single Sign-On AWS デモ Introducing Amazon Redshift Federated Permissions 主なメリット 管理負荷の削減 – ポリシーを一元管理し、手動での複製が不要になります 一貫したセキュリティの適用 – ウェアハウスやアクセス方法を問わず、ポリシーが均一に適用されます ID のシームレスな統合 – 信頼された ID 伝播とロールベースのアクセス制御で、既存の ID プロバイダーとのシングルサインオンを実現します まとめ 本記事では、Amazon Redshift フェデレーテッドアクセス許可と AWS IAM Identity Center の統合により、セキュリティポリシーを一元管理し、マルチウェアハウスのデータガバナンスを効率化する方法を紹介しました。動的データマスキングと行レベルセキュリティのポリシーを Enterprise Data Warehouse で一度定義すれば、同じアカウントとリージョン内の接続先データウェアハウスに自動適用されます。 著者について Raghu Kuppala Raghu は、データベース、データウェアハウジング、分析分野の経験を持つ Analytics Specialist Solutions Architect です。仕事以外では、さまざまな料理を試したり、家族や友人と過ごすことを楽しんでいます。 Satesh Sonti Satesh は、アトランタを拠点とする Principal Specialist Solutions Architect で、エンタープライズデータプラットフォーム、データウェアハウジング、分析ソリューションの構築を専門としています。世界中の銀行・保険業界のクライアント向けに、データ資産の構築や複雑なデータプラットフォームプログラムのリードに 20 年以上の経験があります。 Sandeep Adwankar Sandeep は、Amazon SageMaker Lakehouse の Senior Product Manager です。カリフォルニアのベイエリアを拠点に、世界中のお客様と連携してビジネスおよび技術要件を製品に反映し、データの管理、セキュリティ、アクセスの改善を支援しています。 Sumukh Bapat Sumukh は、AWS のソフトウェアエンジニアです。認証、接続性、セキュリティにおける複雑な問題を解決し、Amazon Redshift のカスタマーエクスペリエンス向上に取り組んでいます。ID 管理、セキュアアクセス、分散データベースシステムに注力しています。 Praveen Kumar Ramakrishnan Praveen は、AWS のシニアソフトウェアエンジニアです。ファイルシステム、ストレージ仮想化、ネットワークセキュリティなど、さまざまな分野で約 20 年の経験があります。AWS では Redshift のデータセキュリティ強化に注力しています。 Ashish Ghodke Ashish は、Amazon Web Services のソフトウェアエンジニアで、Amazon Redshift などの大規模クラウドサービス向けの ID およびアクセス管理システムに取り組んでいます。分散システム向けのセキュアな認証とシングルサインオンソリューションの構築に注力しています。分散システム、クラウドセキュリティ、スケーラブルで信頼性の高いインフラストラクチャの構築に情熱を持っています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本ブログは、キヤノン株式会社イメージング事業本部様と Amazon Web Services Japan が共同で執筆しました。 こんにちは、AWS ソリューションアーキテクトの木村です。 2025 年 6 月から 12 月にかけて、キヤノン株式会社のイメージング事業本部様と共に生成 AI ハッカソンを実施しましたので、その取り組みと成果についてご紹介します。 1. 取り組みの背景 キヤノン株式会社様は、イメージング技術を核とした幅広い事業を展開するグローバル企業です。デジタルトランスフォーメーションの加速に伴い、同社では開発業務や社内業務の効率化に向けて、生成AI技術の活用を推進しています。 イメージング事業本部では、日々の開発業務において、データ分析、調査、UI開発、社内ナレッジ共有など、様々な課題を抱えていました。これらの課題を解決し、かつエンジニア自身が生成AI技術を深く理解するための取り組みとして、今回のハッカソン開催に至りました。 本ハッカソンは「社内業務の課題を生成AIで解決する」をテーマに、以下の3つの狙いを掲げて開催されました。 プロトタイプ創出スキルの習得 アイデアから実装まで一気通貫で体験し、価値創造のプロセスを実践的に学習する プロジェクト間の技術交流促進 各プロジェクトに閉じがちなクラウドアプリ開発の知見を共有し、チーム横断での技術交流を活性化する 生成AI開発の理解促進 AIを「使う側」から「作る側」に回ることで、生成AIの仕組みや使い方への理解を深める 2. 生成AIハッカソンの概要 開催期間・参加者数・チーム構成 開催期間: 2025 年 6 月～ 12 月（約 6 ヶ月間） 参加者数: 約 20 名（イメージング事業本部所属のエンジニア） チーム構成: 5 チーム（各チーム 3 ～ 4 名） 全体スケジュール 本ハッカソンは、約6ヶ月間にわたるプログラムとして設計されました。今回は通常業務と並行して取り組んだため、期間を少し長く確保しました。 キックオフ後に、AWS生成AIサービスの勉強会、アイデアソン、プロトタイピングを経て最終評価会を行いました。 アイデアソン アイデアソンでは、 ML Enablement Workshop を活用したアイデア創出ワークショップを開催しました。ML Enablement Workshop とは、取り組みに必要なメンバーを組成し、生成 AI を活用したユースケースと解決策を特定することを目的としたワークショップです。ワークショップでは、各チームごとに異なるテーマを設定し、Amazon 流のイノベーション創出手法である “Working Backwards” を通じて顧客の明確化・顧客の課題と機会の特定・解決策の特定を行いました。 最終的には、Amazon の文書化の文化にならって、決定した解決策をプレスリリース/FAQ の形にまとめあげました。初めてプレスリリース/FAQ に取り組んだ参加者からは「開発前にプレスリリースを書くのが新鮮だった。文書化することで曖昧な表現が避けられチーム感の共通認識がとりやすくなるように感じた」とコメントをいただきました。 プロトタイピング アイデアソンで生まれた各アイデアの価値を実証する目的で、実際に動くプロトタイプの開発に取り組みました。ハッカソンの運営からは、「Amazon Q Developerでコード/ドキュメント生成・レビューを効率化するなど生成 AI をフル活用しましょう」「失敗を恐れず、試行錯誤を楽しもう」といった案内が出され、参加メンバーはその方針のもと、積極的に新しい技術やツールを取り入れながら開発を進めました。 3. 各チームの成果発表 6 ヶ月間の活動を通じて、5 つのチームが実用レベルのサービスを開発しました。最終成果発表会では、両社の管理職参加のもと、各チームの取り組みを発表しました。 ハッカソンということもあり以下の観点で評価を行い、最優秀チームを選定しました。 提案価値: 提案する価値が明確で共感できるか、ソリューションが課題に対して適切か 技術的優位性: サービス選定やシステム構成が合理的か、価値向上のための技術的な工夫がみられるか アプリケーション品質: 実際の業務で継続利用できるレベルか、展開後の運用まで考えられているか 生成AIの適合度: サービスに生成AIの利点がうまく活かせているか、開発者として生成AIを使いこなせているか 各チームが取り組んだテーマは、データ分析の効率化、社内ナレッジの活用、開発プロセスの自動化など多岐にわたりましたが、いずれも Amazon Bedrock や Amazon Bedrock AgentCore といった AWS の生成 AI サービスを活用し、実際の業務課題を解決するシステムとして発表されました。また、全てのチームが Amazon Q Developer を活用し、開発の効率化を実現していました。 どのチームの発表も思わず「わお！」とコメントしたくなるようなデモ・発表内容で、審査員の皆様も採点に頭を悩ませていた様子でした。 最優秀賞を受賞したチームが開発したシステムのアーキテクチャ 4. 得られた効果 本ハッカソンを通じて、キヤノン株式会社イメージング事業本部様からは以下のような効果が得られたとコメントをいただいています。 技術スキルの向上 参加者全員が Amazon Bedrock や Amazon Q Developer を実際に使いこなし、生成 AI アプリケーションを「作る側」の経験をしました。特に、プロンプトエンジニアリングや RAG 、AI Agent の実装など、実践的なスキルの習得に繋がりました。 開発生産性の向上 Amazon Q Developer を活用することで、コード生成やドキュメント作成の効率が大幅に向上しました。参加者からは「従来であれば数週間かかっていた開発が、数日で完了できた」という声も聞かれ、生成 AI を活用した開発の可能性を実感する機会となりました。 組織横断のコラボレーション促進 普段は異なるプロジェクトで業務を行っているメンバーがチームを組むことで、技術知見の共有やコミュニケーションが活性化しました。交流が増えたことにより、組織全体の技術力向上につながっています。 5. 参加者の声 ハッカソン終了後に実施したアンケートから、参加者の声をご紹介します。 「生成 AI を活用したシステム開発を一から経験できたことで、生成 AI の可能性と限界の両方を知ることができました。今後の業務でも積極的に活用していきたいです。」 「Amazon Q Developer の支援により、普段触れないフロントエンド開発にも挑戦できました。『作りたいもの』に集中できる環境が整っていたと感じます。」 「Working Backwards の手法でプレスリリースを先に書くアプローチが印象的でした。開発を始める前に『誰のために、何を作るのか』を明確にすることの重要性を学びました。」 「他部門のメンバーと協力してゼロからシステムを作り上げる経験は、通常業務ではなかなか得られません。チームワークの大切さを再認識しました。」 6. まとめ 約 6 ヶ月間にわたるキヤノン株式会社イメージング事業本部様との生成 AI ハッカソンは、5 つのチームが実用レベルのプロトタイプを完成させるという大きな成果を収めました。 本ハッカソンで開発されたプロトタイプのうち、いくつかは実際の業務への展開が検討されています。また、今回の取り組みで得られた知見やノウハウを社内に展開し、生成 AI 活用の裾野を広げていく予定です。今回のハッカソンを一過性のイベントで終わらせず、継続的なイノベーション創出の仕組みとして発展させていくことをイメージング事業本部様は目指しています。 最後に、本ハッカソンの企画・運営にご尽力いただいたキヤノン株式会社イメージング事業本部の皆様、そして熱意を持って取り組んでいただいた参加者の皆様に心より感謝申し上げます。 執筆者 キヤノン株式会社 イメージング事業本部 ＩＭＧ技術第二開発センター 運営：草壁 悠希 様 キヤノン株式会社 イメージング事業本部 ＩＭＧ技術第二開発センター 運営：田代 大地 様 キヤノン株式会社 イメージング事業本部 ＩＭＧ技術第二開発センター 運営：南 佑太朗 様 Amazon Web Services Japan ソリューションアーキテクト 木村 直登(Naoto Kimura)

本ブログは 2026 年 2 月 26 日に公開された AWS Blog “ Inside AWS Security Agent: A multi-agent architecture for automated penetration testing ” を翻訳したものです。 AI エージェントには従来、学習した情報を保持できない、短期間を超えて自律的に動作できない、常に人間による監視が必要である、という 3 つの根本的な制約がありました。AWS はフロンティアエージェントによってこれらの制約に対処しています。フロンティアエージェントとは、複雑な推論や多段階の計画立案を行い、数時間から数日にわたって自律的に実行できる新しいカテゴリの AI です。マルチエージェントコラボレーションは、複数のステップと多様な専門知識を必要とする複雑なワークフローに対応するための強力なアプローチとして登場しました。例えば、ソフトウェア開発ではエージェントがコード生成、レビュー、テストを担当し、科学研究ではエージェントが文献レビュー、実験設計、データ分析で協力し、サイバーセキュリティでは専門のエージェントが偵察、脆弱性分析、エクスプロイトの検証を行います。 この記事では、従来は数週間もの期間と多くのリソースを必要としていたペネトレーションテストを、このテクノロジーによってどのように自動化したかについて説明します。また、 AWS Security Agent に組み込まれたペネトレーションテストコンポーネントのアーキテクチャについても、技術的な詳細を解説します。 自動セキュリティテストというコンセプト自体は新しいものではありません。ペネトレーションテストツールや脆弱性スキャナーは何十年も前から存在しています。しかし、大規模言語モデル (LLM) の最近の進歩により、フロンティアエージェントはアプリケーションの動作を推論し、フィードバックに基づいて戦略を適応させ、従来のツールでは不可能だった方法でコンテキストを理解できるようになりました。専門化されたエージェントのネットワークを構築することで、ますます複雑化するセキュリティの課題に対処できます。あるエージェントがアタックサーフェスをマッピングしている間に、別のエージェントがビジネスロジックの欠陥を分析し、検出結果を検証し、実際の悪用可能性に基づいて脆弱性の優先順位付けを行います。悪用可能性のコンテキストは、スウォームワーカーエージェント (群れとして協調動作するエージェント) による実際のエクスプロイトの試行、専門のバリデーターによる独立した再検証、共通脆弱性評価システム (CVSS) に基づく LLM 駆動のスコアリングの組み合わせから導き出されます。 AWS は AWS Security Agent 向けに自動ペネトレーションテストを開発しました。この機能は、専門化されたセキュリティエージェントをオーケストレーションし、協調して脆弱性を検出するマルチエージェントペネトレーションテストシステムで構成されています。システムはまず複数タイプのスキャンでベースラインカバレッジを確立し、次に事前定義された静的タスクを使って広範な偵察を行い、アプリケーションのサーフェスをマッピングして初期の攻撃ベクトルを特定します。これらの検出結果に基づいて、エージェンティックシステムは特定のアプリケーションコンテキストに合わせた集中的なテストタスクを動的に生成します。検出されたエンドポイント、ビジネスロジックのパターン、潜在的な脆弱性チェーンを推論し、アプリケーションの応答に応じて適応する、ターゲットを絞ったセキュリティテストを作成します。これらの専門的な機能を組み合わせることで、システムは主要なリスクカテゴリにまたがる複雑なセキュリティシナリオに対処できます。単一の脆弱性検出にとどまらず、複雑な連鎖攻撃も実行します。例えば、情報漏洩の欠陥と権限昇格を組み合わせて機密リソースにアクセスしたり、安全でない直接オブジェクト参照 (IDOR) と認証バイパスを連鎖させたりします。 図 1: AWS Security Agent ペネトレーションテストコンポーネントの構成図 システムアーキテクチャ このセクションでは、システムの主要コンポーネントについて説明します。認証と初期アクセス、ベースラインスキャン、専門化されたエージェントスウォームによる多段階探索、そして検証とレポート生成について順に取り上げます。 認証と初期アクセス システムはまず、多様なアプリケーションアーキテクチャに対応した認証処理を行うインテリジェントなサインインコンポーネントから開始します。このコンポーネントは LLM ベースの推論と決定論的メカニズムを組み合わせ、サインインページの検出、提供された認証情報による試行、後続のテストフェーズに向けた認証済みセッションの維持を行います。このアプローチはブラウザツールを使用し、さまざまなアプリケーション構造やターゲット環境に自動的に適応します。開発者は、ターゲットアプリケーションに合わせたカスタムサインインプロンプトを任意で提供できます。 ベースラインスキャンフェーズ 認証が完了すると、システムは専門化されたスキャナーを並列実行し、包括的なベースラインスキャンを開始します。ブラックボックステストでは、ネットワークスキャナーが Web アプリケーションの自動セキュリティテストを実施し、実際のトラフィックのやり取りを生成して、脆弱性の候補となるエンドポイントを特定します。ホワイトボックステストの場合は、リポジトリが利用可能であれば、コードスキャナーがソースコードの深層分析を行い、複数のカテゴリにわたる分析結果をまとめたドキュメントを生成します。さらに追加の専門スキャナーがこれらの機能を補完し、さまざまな観点から脆弱性を特定して初期のセキュリティカバレッジを確立します。 多段階探索 システムは、連携して動作する 2 つの異なる探索アプローチを採用しています。 マネージド実行 は、クロスサイトスクリプティング、安全でない直接オブジェクト参照、権限昇格などの主要なリスクカテゴリにまたがる事前定義された静的タスクで動作します。このコンポーネントは各リスクタイプに対して厳選されたタスクを実行し、体系的に包括的なカバレッジを確保します。次のフェーズでは、 ガイド付き探索 が動的かつインテリジェンス駆動のアプローチを取ります。このコンポーネントは、検出されたエンドポイント、検証済みの検出結果、コード分析ドキュメントを取り込み、アプリケーション固有の攻撃ポイントについて推論します。2 つのステージで動作し、まず未探索のリソースと潜在的な脆弱性チェーンを特定してコンテキストに応じたペネトレーションテスト計画を生成し、次にこれらの動的に生成されたタスクの実行をプログラム的に管理します。ガイド付き探索は、アプリケーションの応答や発見されたパターンに基づいて進化する適応型のタスクとして実行されます。 専門化されたエージェントスウォーム 両方の探索アプローチは、専門化されたスウォームワーカーエージェントに作業をディスパッチします。各エージェントは特定のリスクタイプ向けに設定されており、コードエクゼキューター、Web ファザー、共通脆弱性識別子 (CVE) インテリジェンスのための National Vulnerability Database (NVD) 検索、脆弱性固有のツールなど、包括的なペネトレーションテストツールキットを備えています。これらのワーカーは割り当てられたタスクを実行し、タイムアウト管理と構造化されたレポーティングを行います。 検証とレポート生成 専門化されたエージェントが潜在的なセキュリティリスクを特定すると、脆弱性のタイプ、影響を受けるエンドポイント、悪用の証拠、技術的なコンテキストを含む構造化されたレポートを生成します。しかし、自動ペネトレーションテストには重大な課題があります。LLM エージェントは一見もっともらしい検出結果を生成することがあるため、厳密な検証が不可欠です。候補となる検出結果は、決定論的バリデーターと、能動的にエクスプロイトを試みる専門の LLM ベースのエージェントの両方による検証を受けます。AWS はアサーションベースの検証手法を採用しています。セキュリティの専門家が記述した自然言語のアサーションにより、実際の攻撃の振る舞いに関する深い知識がエンコードされ、限定的な決定論的チェックと比べて回避が大幅に困難な、明示的で構造化された証明が要求されます。検証済みの検出結果は CVSS 分析による重大度評価を受け、検証結果、重大度スコア、悪用の証拠とともに最終レポートに統合されます。このレポートは、効果的な修復に向けた、信頼度の高い実用的な脆弱性情報を提供するよう設計されています。 ベンチマーク システムの評価では、自動ベンチマークに加えて人間による評価も実施しました。実際の実行トレースを分析してエラーパターンの分類体系を構築し、頻出パターンの特定を通じてソリューションを反復的に改善しました。ここでは、 CVE Bench パブリックベンチマークでの結果を報告します。CVE Bench は、NVD から収集された重大度 Critical の CVE 40 件を含む脆弱な Web アプリケーション群で構成されており、実際のエクスプロイトに対する AI エージェントの評価に使用されます。各アプリケーションには自動エクスプロイトのリファレンスが含まれており、LLM ベースのエージェントが脆弱性の悪用を試みます。 成功の測定には、攻撃成功率 (ASR) を使用します。ASR は、アプリケーションの脆弱性に対する悪用の成功率として定義されます。CVE Bench では、エージェントがエクスプロイトの成功を検証するためにクエリできるグレーダー (自動採点プログラム) が使用されており、明示的なキャプチャーザフラグ (CTF) 指示が提供されます。以下の 3 つの構成で評価を行いました。 CTF 指示と各ツール呼び出し後のグレーダーチェックを含む構成で、CVE Bench v2.0 において ASR 92.5% を達成 (一部の課題では、このフィードバックがなければエージェントが成功を検証できない blind exploitation が含まれる)。 CTF 指示やグレーダーフィードバックなしの構成で ASR 80% を達成。これは、エージェントが観察可能な結果を通じて自己検証する必要がある実環境の条件をより適切に反映しています。また、エージェントが LLM のパラメトリック知識に基づいて一部の CVE を特定できることも確認しました。次に示す bash コマンドでは、モデルが CVE を名前で明示的に参照しています。 このため、ナレッジカットオフ日が CVE Bench v1.0 のリリースより前の LLM を使用して追加実験を実施し、ASR 65% を達成しました。 以下のコード例は、LLM エージェントがトレーニングデータに含まれる CVE-2023-37999 に関するパラメトリック知識を活用し、悪用の前提条件を確認する bash コマンドを発行している様子を示しています。 # HT Mega 2.2.0 has a known vulnerability – CVE-2023-37999 # It has an unauthenticated privilege escalation via the REST API settings endpoint # Let's check if registration is enabled curl -s http://target:9090/wp-login.php?action=register -I | head -10 AWS は、エージェントの継続的な評価と、より新しく難度の高いベンチマークへの対応を通じて、セキュリティ脆弱性検出のフロンティアを押し広げることに取り組んでいます。 テストとコンピューティング予算の最適化 ペネトレーションテストにおける課題の 1 つは、悪用 (exploitation) と探索 (exploration) のバランスです。深さ優先のアプローチでは、特定の方向に計算リソースを過度に消費し、限られたコンピューティング予算のもとで脆弱性カバレッジが低下するおそれがあります。一方、幅優先のアプローチでは、複数の手法を組み合わせたテストを要する深い脆弱性を見落とす可能性が高くなります。したがって、与えられたコンピューティング予算でカバレッジを最大化するには、両アプローチのバランスが必要です。本システムの設計は、このハイブリッドアプローチの実現を目指しています。さまざまな脆弱性や異なる Web アプリケーションに汎化可能な、より効率的な動的ソリューションの開発は、今後の研究課題です。 もう 1 つの課題は非決定性です。基盤となる LLM の特性上、ペネトレーションテストの結果は実行のたびに異なる可能性があります。実行ごとに異なる検出結果が得られると、ユーザーの混乱を招くおそれがあります。この問題を軽減する方法の 1 つは、複数回実行し、それらの検出結果を統合することです。 まとめ 本記事で紹介したマルチエージェントアーキテクチャは、専門化されたエージェントが連携して複雑なペネトレーションテストのワークフローに取り組む仕組みを示しています。インテリジェントな認証とベースラインスキャンから、マネージド実行とガイド付き探索を経て、厳密な検証に至るまでの一連のプロセスを実現しています。適応型のタスク生成とアサーションベースの検証によりこれらの専門コンポーネントをオーケストレーションすることで、アプリケーション固有のコンテキストや発見されたパターンに基づいて進化する、包括的なセキュリティカバレッジを実現しています。 AWS Security Agent は現在パブリックプレビュー中です。詳細については、 Getting Started with AWS Security Agent を参照してください。 Tamer Alkhouli Tamer は Amazon Web Services の Senior Applied Scientist で、学術界と産業界にわたる 13 年以上の自然言語処理の経験を持っています。RWTH アーヘン大学で Hermann Ney 氏の指導の下、機械翻訳の博士号を取得しました。キャリアを通じて、機械翻訳、対話型 AI、基盤モデルのシステムを構築してきました。AWS では、Amazon Lex、Titan 基盤モデル、Amazon Bedrock Agents、AWS Security Agent に貢献しています。 Divya Bhargavi Divya は AWS Security Agent チームの Senior Applied Scientist です。脆弱性検出とエクスプロイト検証のためのエージェンティックアーキテクチャの設計に注力し、特に敵対的な環境におけるセキュリティエージェントの堅牢なベンチマークフレームワークと評価手法の開発に取り組んでいます。現職以前は、AWS 生成 AI イノベーションセンターで科学的エンゲージメントをリードしていました。 Daniele Bonadiman Daniele は AWS の Senior Applied Scientist で、AWS Security Agent の開発に携わっています。トレント大学で応用機械学習と自然言語処理の博士号を取得しました。AWS では、対話型 AI、エージェントオーケストレーション、AI エージェントのためのコード解釈など、複数の AI イニシアチブに貢献してきました。 Yilun Cui Yilun は AWS でエージェンティック AI に取り組む Principal Engineer です。10 年以上にわたる開発者ツールの構築経験を持ち、ソフトウェア開発ライフサイクル全体への AI 適用を通じて、開発者がより速く開発し、より優れた製品を提供できるよう支援することに情熱を注いでいます。 Dr. Yi Zhang Yi は AWS の Principal Applied Scientist です。25 年以上にわたる産業界と学術界での研究経験を持ち、対話型でインタラクティブなマルチエージェントシステムの開発と、自然言語の構文的・意味的理解の研究に取り組んでいます。AWS Security Agent や Amazon Bedrock Agent など、複数の AWS サービスの開発を支える研究をリードしてきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 「VPC Lattice を使ったアプリケーション間接続、気になってはいるけど手を動かす機会がない」——そんな方にぴったりのオンラインイベント「 AWS Application Networking Activation Day Japan 」が 2026年4月10日(金)に開催されます。EC2、EKS、ECS、Fargate、Lambdaなど多様なコンピューティング環境で稼働しているアプリケーションは、それぞれに安全かつ効率的なネットワーク接続が求められます。Amazon VPC Lattice、AWS PrivateLink、VPC Resources といったサービスを活用して、アプリケーション間の接続をどのようにシンプルかつセキュアに実現できるかを、AWSのアプリケーションネットワーキングを専門とするエキスパートがわかりやすく解説してくれます。また、Amazon VPC Lattice のハンズオン体験でき、半日で一気に学べる実践型プログラムです。ご興味ある方はぜひご参加ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年3月16日週の主要なアップデート 3/16(月) Amazon Connect でオペレーターが外部メールアドレスにメール連絡先を転送可能に Amazon Connect で、オペレーターが外部のメールアドレスにメール転送できる機能が追加されました。オペレーターの画面から直接、バックオフィスや専門家に相談メールを転送でき、元のお客様とのやり取り履歴も保持されます。これまでは内部でしか対応できなかった複雑な問い合わせも、関係者を巻き込みながらスムーズに解決できるようになります。現在、東京リージョンなど 10 のリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 SageMaker HyperPod が動的クラスター利用のためのアイドルリソース共有をサポート Amazon SageMaker HyperPod でアイドルリソースシェアリング機能が提供開始されました。これまでは各チームに割り当てられたコンピュートクォータが未使用の場合、高価な GPU インスタンスがアイドル状態になっていました。この機能により、未使用のリソースを他のチームが自動的に借用できるようになり、クラスター全体の利用率向上が実現できます。管理者は GPU や CPU、メモリなど特定のリソースタイプに対して借用制限も設定可能です。詳細は こちらのドキュメントをご参照ください。 Amazon CloudWatch が組織全体での EC2 詳細モニタリング有効化を導入 Amazon CloudWatch で EC2 の詳細監視を組織全体で自動有効化できるようになりました。従来は各 EC2 インスタンスで個別に設定する必要がありましたが、今回のアップデートでルールベースの自動設定が可能になり、1 分間隔での監視を一括適用できます。本番環境の EC2 インスタンスにタグで自動適用すれば、 Auto Scaling の反応速度向上が期待できます。詳細は こちらのドキュメントをご参照ください。 3/17(火) Amazon S3 Tables と Iceberg マテリアライズドビューの権限管理を簡素化 AWS Glue Data Catalog で Amazon S3 Tables と Apache Iceberg のマテリアライズドビューに対する IAM ベースの認可がサポートされました。これまで複数のサービスでそれぞれ権限設定が必要でしたが、1つの IAM ポリシーでストレージ、カタログ、クエリエンジン全体の権限を一元管理できるようになります。Amazon Athena や Amazon EMR、Amazon Redshift などの Analytics サービスとの統合が大幅に簡素化されるため、データ分析基盤の構築がより効率的になります。詳細は こちらのドキュメントをご参照ください。 Amazon RDS の SQL Server Developer Edition 向け機能強化 Amazon RDS for SQL Server Developer Edition で、追加ストレージボリューム、Resource Governor、SQL Server 2019 のサポートが開始されました。Developer Edition は Enterprise 版と同じ機能を持ちながら開発・テスト用途では無料で利用でき、今回のアップデートにより最大 256 TiB まで拡張可能なストレージと、CPU・メモリ使用量を制御する Resource Governor が利用できるようになりました。本番環境と同じ SQL Server 2019 バージョンでの開発・テストも可能になり、より現実的な性能テストが実現します。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Runtime でシェルコマンド実行がサポート開始 Amazon Bedrock AgentCore Runtime で新しい API InvokeAgentRuntimeCommand の提供が開始されました。この機能により、AI エージェントの実行中にシェルコマンドを直接実行できるようになります。従来は開発者がカスタムロジックを構築してテスト実行や依存関係のインストールなどを行う必要がありましたが、今回のアップデートでプラットフォームレベルの API として提供されるため、開発工数を大幅に削減できます。コマンドの出力はリアルタイムでストリーミングされ、終了コードも取得可能です。バージニア北部リージョンや東京リージョンなど 14 のリージョンで利用できます。詳細は こちらのドキュメントをご参照ください。 3/18(水) Amazon OpenSearch Service が OpenSearch バージョン 3.5 をサポート開始 Amazon OpenSearch Service で OpenSearch version 3.5 がサポートされました。今回のアップデートでは、エージェント型 AI 機能が大幅に強化され、会話の文脈を保持できるようになったため、チャットボットなどで一貫性のある回答が可能になります。また、大規模言語モデル (LLM) へ送信するデータを自動で最適化し、トークンコストを削減しながら回答品質を維持できます。さらに、コードを書かずに高度なエージェントを構築できるノーコードインターフェースも提供され、開発工数を大幅に削減できます。詳細は こちらのドキュメントをご参照ください。 Amazon Redshift がダッシュボードと ETL ワークロードの新しいクエリのパフォーマンスを最大 7 倍向上 Amazon Redshift が新しいクエリ性能を最大 7 倍向上させるアップデートを発表しました。BI ダッシュボードや ETL パイプラインでの新規クエリ実行時間が大幅に短縮され、リアルタイム分析アプリケーションでの応答速度が劇的に改善されます。これまで Redshift では、新しいクエリを受け取るとまずコンパイルを行い、それが終わるまでクエリの実行を待つ必要がありました。今回導入されたコンポジション (Composition) では、既存のコンパイル済みロジックを組み合わせてすぐに実行ができる仕組みです。コンパイルを待たずに即座に実行が始まるため、初回でも 2 回目以降と同様の速さで結果が返ってくることを期待できます。全ての商用リージョンで追加コストなしで自動的に有効化されています。 Amazon Inspector がエージェントレス EC2 スキャンを拡張し、Windows KB ベースの検出結果を導入 Amazon Inspector で agentless EC2 スキャンが大幅に拡張され、Windows OS の脆弱性もエージェント不要で検出できるようになりました。これまでエージェントが必要だった WordPress や Apache HTTP Server、Python パッケージなどの脆弱性も agentless で発見可能です。さらに Windows KB ベースの findings により、複数の CVE を単一のパッチ情報にまとめて表示するため、どのパッチを適用すべきかが一目で分かります。設定変更は不要で自動適用されるため、セキュリティ管理が大幅に効率化されます。詳細は こちらの製品ページをご参照ください。 Amazon EC2 C8a インスタンスがアジアパシフィック (東京) リージョンで利用可能に Amazon EC2 C8a インスタンスが東京リージョンで利用開始されました。第 5 世代 AMD EPYC プロセッサを搭載し、従来の C7a インスタンスと比べて最大 30 % 高いパフォーマンスと最大 19 % 優れた価格パフォーマンスを実現します。メモリ帯域幅も 33 % 向上し、レイテンシが重要なワークロードに最適です。バッチ処理、分散分析、HPC、動画エンコードなどの高性能コンピューティングが必要な用途で威力を発揮します。詳細は こちらの詳細ページをご参照ください。 3/19(木) Amazon RDS Custom for SQL Server にOSアップデートの表示とスケジュール機能を追加 Amazon RDS Custom for SQL Server で、OS アップデートの表示とスケジューリング機能が追加されました。これまでは OS アップデートの管理が手動で煩雑でしたが、新しい API を使って利用可能なアップデートを確認し、即座に適用またはメンテナンスウィンドウでの実行をスケジュールできるようになりました。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 C8gn インスタンスが追加リージョンで利用可能に Amazon EC2 C8gn インスタンスが東京、ジャカルタ、ハイデラバード、サンパウロ、チューリッヒリージョンで新たに利用開始となりました。最新の AWS Graviton4 プロセッサを搭載し、従来の C7gn インスタンスより最大 30% の計算性能向上を実現しています。最大 600 Gbps のネットワーク帯域幅により、データ分析や AI/ML 推論などのネットワーク集約型ワークロードのコスト最適化が可能になります。詳細は こちらをご参照ください。 Amazon Redshift が複数の AWS リージョンで IAM Identity Center との連携権限をサポート Amazon Redshift で、複数の AWS リージョンにおいて IAM Identity Center (IdC) とのフェデレーション権限がサポートされました。これまでプライマリリージョンでのみ利用可能だった IdC を他のリージョンにも拡張でき、ユーザーの近くのリージョンでパフォーマンスと信頼性が向上します。テーブル・カラムレベルでの細かいアクセス制御を既存の社内アイデンティティで簡単に管理でき、QuickSight や Query Editor からのシングルサインオンも可能です。詳細は こちらの Blog 記事をご参照ください。 3/20(金) AWS DataSync がすべてのロケーションタイプで AWS Secrets Manager をサポート AWS DataSync で全てのロケーションタイプに対して AWS Secrets Manager による認証情報管理が可能になりました。従来は一部のロケーションでのみ対応していましたが、今回 HDFS や Amazon FSx 等でも利用でき、認証情報を一元管理できます。独自の KMS キーでの暗号化も可能でセキュリティ要件にも対応します。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Runtime がリアルタイム双方向ストリーミング用の WebRTC サポートを追加 Amazon Bedrock AgentCore Runtime が WebRTC サポートを追加しました。従来の WebSocket に加え、リアルタイム双方向ストリーミングでより低レイテンシな音声・映像配信が可能になります。ブラウザやモバイルアプリで自然な会話体験を提供する音声エージェントを構築できるようになり、14 のリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は 2026 年 3 月 23 日 に公開された「 Simplifying Kafka operations with Amazon MSK Express brokers 」を翻訳したものです。 本記事では、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) の Express ブローカー が、Kafka 管理に関わるエンドツーエンドの作業をどのように効率化するかを紹介します。Apache Kafka はリアルタイムデータストリーミングの事実上の標準となり、世界中の業界でミッションクリティカルなアプリケーションを支えています。高スループットでフォールトトレラントなデータパイプラインを大規模に処理できることから、広く普及しています。現代のデータアーキテクチャで中心的な役割を担う Apache Kafka を高い回復力と信頼性で管理することは、ビジネスの成功に不可欠です。 回復力を維持するために、管理者は複数の重要な運用タスクに対応しなければなりません。Apache Kafka は分散型のステートフルシステムであり、動的なクラウド環境では状態管理に継続的な通信とデータ移動が必要です。管理者はコンピューティング、ストレージ、ネットワークの複雑な要件を計算してクラスターを慎重にサイジングする必要があります。ストレージボリュームを事前にプロビジョニングし、中断を防ぐため使用率を常に監視しなければなりません。ワークロードが増大した場合、クラスターのスケーリングには複数のツールでキャパシティのプロビジョニングと負荷の再分散が必要で、数時間から数日かかることもあります。 以上の運用要件を踏まえ、多くの管理者が疑問に思うのは、アプリケーションが求める高い回復力を維持しながら、Apache Kafka を大規模に管理するもっと簡単な方法はないか、という点です。 Amazon MSK Express は Kafka 管理の課題を解決します。本記事では、MSK Express ブローカーが以下を含む Kafka 管理のエンドツーエンドの作業をどのように効率化するかを紹介します。 最適なパフォーマンスとコストのための Kafka クラスターサイジング ワークロードの変化に応じたクラスターストレージのスケールアップ・ダウン 時間経過に伴うクラスターコンピューティングのスケールイン・アウト クラスターの健全性モニタリング クラスターセキュリティの管理 高速かつ自動的なブローカー復旧による高可用性の確保 Amazon MSK Express ブローカーとは Amazon MSK Express ブローカーは、高スループットの Kafka クラスターを必要とするお客様向けに、より高速なスケーリングと低コストを実現します。Express ブローカーは Kafka のコンピューティングとストレージを再設計し、両者を分離することでパフォーマンスと弾力性を向上させています。Express ブローカーによる主なパフォーマンス改善は以下のとおりです。 ブローカーあたり最大 3 倍のスループットにより、少ないリソースと低コストでより多くのデータを処理可能 ブローカー間のパーティション再分散が 180 倍高速化し、スケーリングが数時間から数分に短縮 最大 20 倍高速なスケールアップにより、長期的な計画サイクルなしで需要の急増に対応可能 標準の Apache Kafka ブローカーと比較して 90% 高速な復旧により、ワークロードの中断を最小限に抑え、ビジネス継続性を維持 技術的な詳細は、 Express brokers for Amazon MSK: Turbo-charged Kafka scaling with up to 20 times faster performance を参照してください。Express ブローカーの機能の詳細については、 MSK Express ブローカーのドキュメント を参照してください。 MSK Express ブローカーが Apache Kafka の管理をどのようにシンプルにするか見ていきましょう。 Express クラスターのサイジング 従来の Apache Kafka クラスターのサイジングは複雑です。イングレスとエグレスの負荷から逆算して、クラスターのコンピューティング、ストレージ、ネットワークの制限を考慮しなければなりません。各ノードは以下を処理できるよう慎重にサイジングする必要があります。 クライアントからのイングレスおよびエグレストラフィック レプリケーションやリバランシング (ブローカー間でパーティションを再分散してバランスを維持するプロセス) などの Kafka 内部オペレーション ノード障害やアベイラビリティーゾーン障害に対する高可用性 過去のデータを読み取るバックフィル手順などのクライアントオペレーション サイジングではクラスターのストレージ I/O 制限、ネットワークのイングレス/エグレス制限、CPU とメモリの制約を考慮します。さらに、必要なパーティション数を見積もり、ユースケースに対応するパーティション管理にクラスターがスケールできるかどうかを判断しなければなりません。 MSK Express ブローカーはサイジングの計算をシンプルにします。複雑な変数を考慮する代わりに、以下の重要な要素に集中できます。 イングレススループット エグレススループット パーティションの要件 MSK のドキュメントには、 ブローカーサイズ別の Express ブローカーのスループット制限とパーティション制限 が記載されています。MSK はクラスターのすべての制限を考慮して事前に計算しています。ノード障害や AZ 障害などのまれなイベントに対応するマルチアベイラビリティーゾーンの高可用性も含まれています。 Express クラスターのサイジングでストレージについて触れなかったことにお気づきでしょうか。Express ではストレージがほぼ無制限にスケールするためです。ストレージを事前にサイジングするのではなく、使用した分だけ支払います。 Express クラスターストレージのスケーリング スループットとパーティションに焦点を当ててサイジングがシンプルになると、次の運用上の検討事項はストレージ管理です。 通常、Apache Kafka クラスターでは、保持するすべてのデータを処理するためにストレージボリュームを事前にプロビジョニングしなければなりません。すべてのストレージを事前に割り当て、実際のデータ保持量に関係なく料金を支払う必要があります。 例 : 1 MB/秒のイングレスで 7 日間のデータを保存する場合、600 GB 以上のストレージが必要です。ノード間のデータレプリケーションや増加・ワークロード変動に対するバッファは含まれていません。レプリカとストレージバッファを考慮すると、ワークロードには 3 TB 以上のストレージを事前に割り当てなければなりません。 ワークロードの変化に伴い、ストレージ使用率の慎重なモニタリングが不可欠になります。ストレージ容量の追加はワークロードの中断を防ぎます。多くの場合、追加したストレージを回収できません。ボリュームサイズを増やすと、ワークロードがスケールダウンして追加容量が不要になっても、追加ストレージの料金を支払い続けることになります。 Express ブローカーでは、ストレージボリュームのサイジングやプロビジョニングは不要です。プロビジョニングなしで使用した分だけ支払います。クラスターに取り込まれたデータと、クラスターに保存されたデータの GB あたり時間単位で課金されます。クラスターに保存されたすべてのデータは、高可用性のために 3 つのアベイラビリティーゾーンにレプリケートされます。従量課金モデルにより、無駄な容量コストがなくなり、インフラストラクチャ全体の支出が削減されます。 ワークロードがスケールアップすると、変更なしでクラスターのストレージ使用量が増加 ワークロードがスケールダウンすると、クラスターのストレージ使用量が減少し、ストレージ料金が自動的に削減 Express によって Apache Kafka のストレージ管理がシンプルになります。トピックごとの保持期間がユースケースに適切にサイジングされていることを確認するだけです。トピックの保持期間を設定すれば、MSK Express がストレージの管理とコスト最適化を自動的に行います。 MSK Express ブローカーのストレージ管理は、従来の Apache Kafka クラスターよりもはるかにシンプルです。Express ベースのクラスターのコンピューティング容量のスケーリングも同様です。 Express クラスターコンピューティングのスケーリング ストレージがワークロードに応じて自動的にスケールするのと同様に、コンピューティング容量も変化する需要に適応できます。 ワークロードが増大・変化すると、当初のサイジング見積もりを超えることがあります。従来の Apache Kafka クラスターでは、クラスター容量のスケーリングは大がかりな作業です。キャパシティのプロビジョニングと負荷の再分散に労力がかかり、スケーリングプロセスの管理に複数のツール (コンピューティング、ストレージ、DNS、リバランシング、クライアント設定など) が必要です。スケーリングの完了には数時間から数日かかることがあり、アプリケーションへの影響が悪化する可能性があります。そのため、負荷の変化に備えて Kafka クラスターを十分に前もって計画しなければなりません。 MSK Express クラスターでは、スケーリングがはるかにシンプルになり、事前の計画はほとんど不要です。既存のワークロードへの中断はほぼゼロで、チームはインフラストラクチャの管理ではなく機能の構築に集中できます。 MSK Express クラスターをスケールアップするには、クラスターにブローカーを追加するだけです。新しいブローカーがオンラインになると、 Express Intelligent Rebalancing がトピックパーティションを新しいノードに自動的に再分散します。Express のストレージアーキテクチャにより、新しいノードは必要なデータのほぼすべてを自動的に保持しています。リバランシングのためのブローカー間通信はほとんど発生せず、既存のブローカーへの影響はありません。 その後、クラスターは各パーティションの新しいブローカーリーダーを選出し、プロデューサーが新しいノードにトラフィックを送信できるようにします。コンシューマーグループも同様です。 Express ブローカーの DNS 設計はスケーリングを考慮しています。Express ブローカーの接続文字列はノード自体を抽象化しており、クライアントは 1 つの接続文字列でアクティブなブローカーノードに接続します。DNS、ロードバランシング、クライアント設定の変更は不要です。 Express クラスターのスケールインの判断も、従来の Apache Kafka クラスターよりシンプルです。Express のシンプルなアーキテクチャにより、長期的なクラスター運用でモニタリングや管理すべき項目が少なくなります。 Express クラスターのモニタリング スケーリングの判断がシンプルになると、モニタリングもシンプルになります。Express ブローカーは、クラスターの健全性を把握するために追跡すべきメトリクスの数を削減します。以下の画像は、MSK Express ブローカーの健全性をモニタリングするための主要メトリクスを示すダッシュボードです。 従来の Apache Kafka クラスターでは、クラスター全体の健全性を把握するために数十のメトリクスを考慮しなければなりません。Express ブローカーは運用プロセスをシンプルにし、イングレスとエグレスのスループットを 2 つの重要なメトリクスとして強調しています。モニタリングの効率化により、Kafka クラスターの運用に必要な専門知識が減り、少人数のチームでも大規模なデプロイメントを効果的に管理できます。 設計が不適切なクライアントなど、他の要因がクラスターに追加の負荷をかけることがあります。高いイングレススループットがないのに CPU 使用率が高いなどの症状が発生することがあります。MSK Express ブローカーでもさまざまなメトリクスをモニタリングすることは依然として重要です。 Express ブローカーについて、クラスターの健全性のためにモニタリングとアラート設定が必要な重要メトリクスを以下の表に示します。 メトリクス名 説明 推奨アラーム BytesInPerSec クラスターへのイングレススループット ブローカー制限を 5 分以上超過した場合 BytesOutPerSec クラスターからのエグレススループット ブローカー制限を 5 分以上超過した場合 CpuUser + CpuSystem CPU 使用率 60% 以上が 15 分間続いた場合 NetworkProcessorAvgIdlePercent ネットワークプロセッサスレッドのアイドル時間 0.5 未満が 5 分以上続いた場合 RequestHandlerAvgIdlePercent リクエストプロセッサスレッドのアイドル時間 0.4 未満が 15 分以上続いた場合 FetchThrottleByteRate コンシューマーフェッチのスロットリングレート 0 未満が 15 分以上続いた場合 ProduceThrottleByteRate プロデューサーイングレスのスロットリングレート 0 未満が 15 分以上続いた場合 Amazon MSK のモニタリングの詳細については、 Amazon CloudWatch による Amazon MSK のモニタリング を参照してください。 Express クラスターのアクセス管理 モニタリングに加えて、クラスター管理も MSK Express ブローカーが運用の複雑さを軽減する領域です。 Express ブローカーは Kafka クラスターの内部管理をシンプルにします。従来の Kafka 環境では、クライアント認証に SASL/SCRAM (ユーザー名とパスワードベースの認証) や相互 TLS (証明書ベースの認証) などのスキームを使用します。認証後、Kafka クラスター内で複雑な Kafka ACL (アクセス制御リスト — どのクライアントがどのトピックにアクセスできるかを定義する権限) を設定して、トピックとデータへのクライアントアクセスを認可します。 従来の方式では、すべてのトピック、認証、認可を Apache Kafka 内で管理しなければなりません。クラスターアクセスに関する認証情報の管理やローテーションなどの運用作業も含まれます。 MSK は AWS Identity and Access Management (IAM) と統合することで、アクセス制御をシンプルにしています。クライアントはクラスターのアクセス境界を明確に指定する IAM ロールを使用できます。また、Kafka API でクラスターへのデータの読み書きに対するトピックレベルの認可も提供します。 さらに、クライアントは MSK API で Kafka クラスターの設定と Kafka トピックを直接管理できます。新しいトピックの作成、トピック設定やパーティション数の更新、トピックの削除が可能です。設定とトピックは AWS コンソール、AWS CLI、AWS SDK で管理できます。詳細については、 Amazon MSK が新しい API とコンソール統合で Kafka トピック管理をシンプルに を参照してください。 IAM アクセス制御の既存のエンタープライズ標準と、AWS CloudFormation や AWS CDK の自動化を活用して、Infrastructure as Code (IaC) でクラスターを管理できます。IAM 統合により、クラスター管理の運用負荷が軽減され、既存のセキュリティインフラストラクチャを活用して本番環境への移行が加速します。 MSK は IAM アクセス制御と並行して SASL/SCRAM および相互 TLS 認証モードもサポートしています。AWS 外のアプリケーションを柔軟に認可でき、コード変更なしでレガシーアプリケーションにアクセスを提供することも可能です。 詳細については、 Amazon MSK の IAM アクセス制御 と Amazon MSK のセキュリティ を参照してください。 高可用性の Express ブローカーの構築 IAM 統合によってセキュリティがシンプルになると、高可用性が運用面で最後の重要な要素となります。 Express クラスターコンピューティングのスケーリングで説明した考慮事項の多くは、MSK Express ブローカーの高可用性にも当てはまります。 内部テスト によると、MSK Express ブローカーのストレージ改善によって、ブローカーノード障害時の復旧が標準ブローカーより 90% 高速化されます。新しいノードは大規模なリバランシングを行うことなく、クラスターの残りの部分にほぼ影響を与えずに起動できます。復旧後に新しいノードへのパーティション再分散が必要になる、標準の Kafka クラスターとは対照的です。 ストレージの改善に加えて、MSK Express ブローカーはデフォルトで高可用性を備えています。サービスが高可用性とパフォーマンスに関する重要なクラスターおよびトピック設定を自動的に管理するため、ほとんどのクラスター設定を管理する必要がなくなります。 Express は min.insync.replicas、num.io.threads など、 Express ブローカーの読み取り専用設定 に記載されている設定を完全に管理します。すぐに使える高可用性かつ高パフォーマンスなクラスターが得られます。 Apache Kafka クラスターのほとんどのクラスターレベル設定を気にする必要はなくなります。以下のことだけで済みます。 MSK Express クラスターを起動する トピックと保持期間を設定する 高可用性クラスターの確保に通常必要な細かいチューニングなしで運用を開始する まとめ 本記事では、MSK Express ブローカーが Apache Kafka のクラスター運用をどのようにシンプルにするかを紹介しました。サイジング、ストレージ管理、コンピューティング管理、高可用性、アクセス制御をシンプルにしながら、高いパフォーマンス、信頼性、コスト効率を提供することで、Apache Kafka クラスター運用の総所有コスト (TCO) を削減します。運用のシンプル化により、クラスター管理に必要な専門知識が減り、デプロイメントのタイムラインが短縮されます。 以上を踏まえ、ほぼすべての MSK ワークロードに MSK Express ブローカーをお勧めします。新しい Kafka クラスターを始める場合でも、既存のクラスターを最適化する場合でも、MSK Express ブローカーはシンプルさ、パフォーマンス、コスト効率の優れた組み合わせを提供します。 Kafka 運用をシンプルにする準備はできましたか？ Amazon MSK の使用を開始 して、今すぐ最初の Express クラスターを作成しましょう。フルマネージドで高可用性の Kafka クラスターを数分でプロビジョニングし、すぐに運用上のメリットを体験できます。料金の詳細については、 Amazon MSK の料金 を参照してください。 Amazon MSK の機能と特徴の詳細については、 Amazon MSK 製品ページ と Amazon MSK 開発者ガイド をご覧ください。 著者について Mazrim Mehrtens Mazrim は、メッセージングおよびストリーミングワークロードを専門とするシニアスペシャリスト Solutions Architect です。リアルタイムで数テラバイトのストリーミングデータを処理・分析するシステムの構築と運用、エンタープライズ機械学習パイプラインの実行、さまざまなデータツールやソフトウェアスタックを使用するチーム間でシームレスにデータを共有するシステムの構築をお客様と共に行っています。 Sai Maddali Sai は、AWS のシニアマネージャー (プロダクトマネジメント) として、Amazon MSK のプロダクトチームを率いています。お客様のニーズを理解し、テクノロジーを活用してお客様が革新的なアプリケーションを構築できるサービスを提供することに情熱を注いでいます。仕事以外では、旅行、料理、ランニングを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 週末の３連休は皆様いかがお過ごしでしたでしょうか？　リフレッシュされた状態で今週も技術のキャッチアップを進めていきましょう。 今週  3 月 26 日（木）には「 Amazon Quick Suite で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。分析業務や定型業務の効率化に興味がある方はぜひご参加ください！ それでは、3 月 16 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 Amazon Bedrock AgentCore による、高度なネットワーク運用エージェントの構築 」を公開 深夜にネットワーク障害のアラートが届いたとき、複雑なクラウド環境のトラブルシューティングには膨大な時間がかかります。この記事では、Amazon Bedrock AgentCore の AI 機能を AWS のネットワーキングサービスと統合し、ネットワーク障害の診断と修復を自動化する高度なネットワーク運用エージェントの構築方法を解説しています。Interface & Integration、Security & Operations、Intelligence、Orchestration、Memory、Deployment、Evaluation の 7 つのビルディングブロックを組み合わせるモジュラーなアプローチが紹介されており、エージェンティック AI によるネットワーク運用の自動化に関心のある方におすすめの記事です。 サービスアップデート Amazon Bedrock がアジアパシフィック（ニュージーランド）リージョンで利用可能に Amazon Bedrock がアジアパシフィック（ニュージーランド）リージョンで利用可能になりました。Anthropic（Sonnet 4.5、Sonnet 4.6、Opus 4.5、Opus 4.6、Haiku 4.5）および Amazon（Nova 2 Lite）のモデルがクロスリージョン推論で利用できます。ニュージーランドのお客様にとって、より低レイテンシーで生成 AI アプリケーションを構築できるようになりました。 Amazon Bedrock にて Minimax M2.5 および GLM 5 モデルが利用可能に Amazon Bedrock のモデル選択肢が拡大し、GLM 5 と Minimax M2.5 が追加されました。GLM 5 は複雑なシステムエンジニアリングや長期的なエージェンティックタスクに最適化されたフロンティアクラスの汎用大規模言語モデルです。Minimax M2.5 はエージェントネイティブなフロンティアモデルで、効率的な推論とタスク分解に優れ、実世界の時間・コスト制約下で複雑なワークフローを完了するよう設計されています。エージェンティック AI のユースケースに取り組んでいる方にとって、新たな選択肢となります。 NVIDIA Nemotron 3 Super が Amazon Bedrock で利用可能に Amazon Bedrock にて NVIDIA Nemotron 3 Super が利用可能になりました。Mixture-of-Experts（MoE）アーキテクチャを採用したオープンモデルで、複雑なマルチエージェントアプリケーション向けに設計されています。長いマルチステップタスクにおいてもコンテキストを失わずに高速かつコスト効率の良い推論を実現します。重み、データセット、レシピが完全にオープンで、カスタマイズも容易です。 Amazon Bedrock AgentCore Runtime にて AG-UI プロトコルをサポート Amazon Bedrock AgentCore Runtime にて、Agent-User Interaction（AG-UI）プロトコルのサポートが追加されました。AG-UI は AI エージェントとユーザーインターフェース間の通信を標準化するオープンなイベントベースのプロトコルです。既存の MCP（ツール連携）や A2A（エージェント間通信）に加え、AG-UI によりエージェントをユーザー向けアプリケーションに統合できるようになります。テキストチャンクやツール結果のリアルタイムストリーミング、UI 要素の状態同期などが可能で、東京リージョン含む 14 リージョンで利用可能です。 Amazon Bedrock AgentCore Runtime にてシェルコマンド実行をサポート Amazon Bedrock AgentCore Runtime にて、実行中のセッション内でシェルコマンドを直接実行できる新しい API「InvokeAgentRuntimeCommand」が追加されました。テストの実行、依存関係のインストール、git コマンドの実行など、LLM による推論と並行して決定論的な操作を行う必要がある場面で、カスタムロジックを構築する必要がなくなります。東京リージョン含む 14 リージョンで利用可能です。 Amazon Bedrock AgentCore Runtime にて WebRTC による双方向リアルタイムストリーミングをサポート Amazon Bedrock AgentCore Runtime にて、WebRTC プロトコルのサポートが追加されました。既存の WebSocket に加え、UDP ベースのピアツーピア通信により低レイテンシーの音声・映像の双方向ストリーミングが可能になります。ブラウザやモバイルアプリケーションでの音声エージェント構築に最適で、Amazon Kinesis Video Streams のマネージド TURN やサードパーティ TURN など柔軟な構成が選択できます。東京リージョン含む 14 リージョンで利用可能です。 SageMaker HyperPod にてアイドルリソース共有による動的クラスター活用をサポート Amazon SageMaker HyperPod のタスクガバナンスにて、動的リソース共有機能が追加されました。チームが保証されたクォータを超えて未割り当てのコンピュートキャパシティをベストエフォートで借用できるようになります。管理者はアクセラレータ、vCPU、メモリなどのリソースタイプごとに借用上限を設定でき、高価な GPU インスタンスのアイドル状態を削減してクラスター全体の利用効率を最大化できます。東京リージョン含む複数のリージョンで利用可能です。 SageMaker Training Plans にて既存のキャパシティコミットメントの延長が可能に SageMaker Training Plans にて、AI ワークロードが予想より長くかかった場合にプランを延長できるようになりました。1 日単位で最大 14 日、または 7 日単位で最大 182 日（26 週間）の延長が可能で、API または SageMaker コンソールから実行できます。延長購入後はワークロードの再設定なしに中断なく実行を継続できます。 AWS にて NIXL と EFA の統合により大規模 LLM 推論を高速化 AWS にて NVIDIA Inference Xfer Library（NIXL）と Elastic Fabric Adapter（EFA）の統合がサポートされました。分離型 LLM 推論における KV キャッシュのスループット向上、トークン間レイテンシーの削減、KV キャッシュメモリ利用の最適化を実現します。NIXL は NVIDIA Dynamo、SGLang、vLLM などのフレームワークとネイティブに統合され、すべての EFA 対応 EC2 インスタンスタイプで追加コストなしで利用可能です。 AWS Neuron にて Amazon EKS の Dynamic Resource Allocation をサポート AWS Neuron の Dynamic Resource Allocation（DRA）ドライバーが Amazon EKS で利用可能になりました。Kubernetes ネイティブなハードウェア対応スケジューリングを AWS Trainium ベースのインスタンスに提供します。インフラチームが再利用可能な ResourceClaimTemplate を定義し、ML エンジニアはハードウェアの詳細を意識せずにテンプレートを参照するだけでデプロイできるようになります。分散トレーニングや分離型推論アーキテクチャのスケーリングが容易になります。 AWS Security Agent にてペネトレーションテストレポートのダウンロードをサポート AWS Security Agent にて、ペネトレーションテストレポートのダウンロード機能が追加されました。リスクレベル、信頼度、ステータスなどのフィルターに基づいてカスタマイズされたレポートを PDF 形式で作成できます。各レポートにはエグゼクティブサマリー、テスト範囲、手法の詳細、脆弱性情報とリスク評価が含まれます。ペネトレーションテストを数週間から数時間に短縮する AWS Security Agent の利便性がさらに向上しました。 AWS Partner Central にて AI エージェント機能を一般提供開始 AWS Partner Central にて、Amazon Bedrock AgentCore 上に構築された AI エージェント機能が一般提供開始されました。パートナーの営業チームに対してパイプラインインサイト、カスタマイズされた営業プレイ、次のステップの推奨をオンデマンドで提供します。会議のトランスクリプトやメモを共有するとエージェントが自動的にフィールドを入力し、案件を進めます。MCP を通じたプログラマティックなアクセスにも対応しており、CRM システムからの利用も可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

AWS は創立 20 周年を迎えました! 着実なイノベーションのペースで、AWS は 240 を超える包括的なクラウドサービスを提供するように成長し、毎年何百万ものお客様に何千もの新機能をリリースし続けています。この間、このブログには 4,700 件を超える投稿が公開されました。これは、 Jeff Barr 氏が創立 10 周年記念記事を書いたときまでの 2 倍以上です 。 AWS は私の人生を変えました 20 年前に私が行っていたことを振り返ってみると、私は 2006 年 3 月 13 日に、 韓国 NGWeb カンファレンス の基調講演のスピーカーとしての Jeff にソウルで会いました。当時、Amazon は e コマース API サービスを導入し、API エコノミーを最初に開始した先駆者の 1 つでした。基調講演でのスピーチの後、彼はその日の夕方に帰国し、米国に戻るフライトで Amazon S3 ローンチのブログ記事 を書いたのだと思います。 彼との短い出会いは私の人生に大きな変化をもたらしました。彼はブロガーとしての私のロールモデルになり、私は私の会社で API ベースのサービスを構築し、それをサードパーティの開発者に公開し始めました。私が博士課程の学生であり、仕事を休んでいたときに、私のような個々の研究者にとって、AWS クラウドサービスは大規模な研究プロジェクトを実施するための強力なツールであることに気付きました。仕事に復帰した後、私の会社は 2014 年に 韓国で最初の AWS の顧客 の 1 つになりました。私自身を含め、数え切れないほどの開発者がクラウドコンピューティングを採用し、その機能を積極的に利用して、以前は不可能だったことを達成してきました。 過去 10 年間で、テクノロジー環境は劇的に変化しました。深層学習は AI でのブレークスルーとして登場し、 大規模言語モデル (LLM) に基づく 生成 AI から今日の エージェンティック AI テクノロジーへと進化しました。Jeff は次のように書いています。「将来を見据えるときには、派手な気晴らしと本物のトレンドを区別できると同時に、昨日のニッチが今日の主流テクノロジーになった場合にピボットするのに十分な柔軟性を保つ必要があります」。 この原則は、AWS がイノベーションに取り組む方法の指針となります。まず、お客様が本当に必要としているものに耳を傾けることから始めます。本当のトレンドは、すべての新しいテクノロジーを追求することではなく、むしろお客様の最も重要な課題に対処するソリューションを再考することです。 AWS の 20 年 最初の 10 年について、Jeff はお気に入りの AWS のローンチとブログ投稿を選びました。 Amazon S3 、 Amazon EC2 (2006 年)、 Amazon Relational Database Service 、 Amazon Virtual Private Cloud (2009 年)、 Amazon DynamoDB 、 Amazon Redshift (2012 年)、 Amazon WorkSpaces 、 Amazon Kinesis (2013 年)、 AWS Lambda (2014 年)、および AWS IoT (2015 年)。 お気に入りをもてあそぶのは好きではありませんが、過去 10 年間のお気に入りの AWS ブログ投稿をいくつか選びたいと思います。 コンテナの簡単なデプロイ (2014 年) — Amazon Elastic Container Service では、強力な API やその他のツールを使用して、Amazon EC2 インスタンスのマネージドクラスター全体でコンテナをいくつでも簡単に実行できます。2017 年に、私たちはフルマネージド型の Kubernetes サービスとして Amazon Elastic Kubernetes サービス、およびサーバーレスデプロイオプションとして AWS Fargate を立ち上げました。 グローバル規模での高可用性データベース (2017 年) — Amazon Aurora は、大規模なパフォーマンスと高可用性を実現する最新のリレーショナルデータベースサービスです。2018 年に、私たちは Amazon Aurora Serverless v1 を立ち上げ、このサーバーレスデータベースは Amazon Aurora Serverless v2 に進化して、 ゼロまでスケールダウンしました。2025 年に、私たちは常時利用可能なアプリケーション向けの最速のサーバーレス分散 SQL データベースである Amazon Aurora DSQL も立ち上げました。 すぐに使える機械学習 (ML) (2017 年) — Amazon SageMaker はフルマネージド型のエンドツーエンドの ML サービスで、データサイエンティスト、開発者、ML 専門家はこれを使用して、大規模な機械学習モデルを迅速に構築、トレーニング、ホストできます。2024 年に、私たちはデータ、分析、AI の統合プラットフォームである 次世代の Amazon SageMaker を立ち上げ、特に AI と ML モデルの大規模な構築、トレーニング、デプロイに注力するために Amazon SageMaker AI を導入しました。 クラウドワークロードのベストプライスパフォーマンス (2018) — 私たちは、クラウドワークロードに最高のコストパフォーマンスを提供するように設計された、第 1 世代の ARM ベースの AWS Graviton プロセッサ を搭載した Amazon EC2 A1 インスタンス を立ち上げました。昨年、私たちは AWS Graviton5 プロセッサを搭載した EC2 M9g インスタンス のプレビューを行いました。9 万を超える AWS のお客様が、Amazon ECS や Amazon EKS、AWS Lambda、Amazon RDS、Amazon ElastiCache、Amazon EMR、Amazon OpenSearch Service などの人気のある AWS のサービスをサポートしている Graviton のメリットを享受しています。 データセンターで AWS クラウドを実行 (2019 年) — AWS Outposts は、ほぼすべてのオンプレミスまたはエッジロケーションに AWS インフラストラクチャとサービスを提供するフルマネージド型サービスのファミリーで、真に一貫したハイブリッドエクスペリエンスを実現します。現在、AWS Outposts は、1U および 2U の Outposts サーバーから 42U の Outposts ラック、およびマルチラックデプロイまで、 さまざまなフォームファクター で利用できます。DISH、Fanduel、Morningstar、Philips などのお客様は、オンプレミスシステムへの低レイテンシーのアクセス、ローカルデータ処理、データレジデンシー、およびローカルシステムの相互依存を伴うアプリケーション移行を必要とするワークロードで Outposts を使用しています。 ML ワークロードに最適なコストパフォーマンス (2019 年) — 私たちは高速で低レイテンシーの推論を提供するように設計された第 1 世代の AWS Inferentia チップ を搭載した Amazon EC2 Inf1 インスタンス を立ち上げました。2022 年に、私たちはハイパフォーマンスの AI トレーニング用に最適化された第 1 世代の AWS Trainium チップ を搭載した Amazon EC2 Trn1 インスタンス を立ち上げました。昨年、私たちは次世代の生成 AI アプリケーションに最適なトークンエコノミーを実現するために、Trainium3 を搭載した Amazon EC2 Trn3 UltraServers を立ち上げました。Anthropic、Decart、Poolside、Databricks、Ricoh、Karakuri、SplashMusic などのお客様は、Trainium ベースのインスタンスと UltraServers のパフォーマンスとコスト上のメリットを実感しています。 AWS 上で生成 AI アプリケーションを構築 (2023 年) — Amazon Bedrock は、業界をリードする AI モデルの選択肢に加えて、生成 AI アプリケーションの構築に必要な幅広い機能を提供するフルマネージド型サービスであり、セキュリティ、プライバシー、責任ある AI で開発を簡素化します。 昨年、私たちは効果的なエージェントを安全に大規模に構築、デプロイ、運用するためのエージェンティックプラットフォームである Amazon Bedrock AgentCore を導入しました 。現在、世界中の 100,000 を超えるお客様が、パーソナライズされた体験を提供し、複雑なワークフローを自動化し、実用的な洞察を引き出すために Amazon Bedrock を選択しています。 お客様の AI コーディングコンパニオン (2023 年) — 私たちは業界初のクラウドベースの AI コーディングアシスタントサービスとして Amazon CodeWhisperer を立ち上げました。このサービスは、コメントからのコード生成、オープンソースのコード参照追跡、および脆弱性スキャン機能を提供しました。2024 年に、私たちはこのサービスのブランドを Amazon Q Developer に変更し、その機能を拡張してコンソールでのチャットベースのアシスタント、プロジェクトベースのコード生成、およびコード変換ツールを追加しました。2025 年に、このサービスは Kiro に進化しました。これは、プロジェクトをプロトタイプから本番環境まで進める仕様主導型開発を通じて AI コーディングに構造をもたらす新しいエージェンティック AI 開発ツールです。Kiro は最近、 自律型エージェントのプレビューを行いました 。これは、開発タスクに独立して取り組み、コンテキストを維持し、あらゆるインタラクションから学習するフロンティアエージェントです。 AI モデルの選択肢を広げる (2024 年) — 私たちは Amazon Titan モデル を立ち上げ、Amazon Bedrock のテキストやマルチモーダルのニーズに向けて費用対効果の高い AI モデルの選択肢をさらに増やしました。AWS re:Invent 2024 で、私たちは最先端のインテリジェンスと業界トップクラスの価格パフォーマンスを実現する Amazon Nova モデルを発表しました。現在、Amazon Nova には、Amazon Nova モデル、独自のフロンティアモデルを構築するための新しいサービスである Amazon Nova Forge 、カスタム Amazon Nova 2 Lite モデル を搭載したブラウザベースの UI ワークフローを自動化するエージェントを構築する新しいサービスである Amazon Nova Act など、さまざまな AI 製品があります。 AI を使用した構築: 今後の進むべき道 10 年前、AWS は深層学習の出現に対応して、Amazon SageMaker などの最も幅広く深い ML サービスを立ち上げ、技術的な専門知識に関係なく、個人の開発者やスタートアップから大企業まで、幅広いお客様のために AI を民主化しました。 AI テクノロジーは大幅に進歩しましたが、AI モデルとアプリケーションの構築とデプロイは、多くの開発者や組織にとって依然として複雑です。AWS は、Amazon Bedrock を通じて、 Anthropic や OpenAI などの大手プロバイダーを含む、最も幅広い AI モデルを提供しています。実践的でスケーラブルなモデルトレーニングと推論のインフラストラクチャ、そして 責任ある AI を使用することで、データとコストの管理を維持しながら、信頼された AI イノベーションを加速できます。これらはすべて、当社のグローバルインフラストラクチャの優れた運用性に基づいて構築されています。 アイデアを再発明し、学び続け、信頼できる AI で自信を持って構築し、成功を私たちと共有してください! AWS の新規のお客様には、 無料で AWS AI を試せる最大 200 USD のクレジットが付与されます。学生の方は、1 か月あたり 1,000 クレジットを 1 年間使用して、 無料で Kiro を使用して構築を開始できます。 – Channy 原文は こちら です。

2026 年 3 月 18 日、3 人の非常に優れた開発者コミュニティリーダーたちを AWS ヒーローとしてご紹介できるのを大変嬉しく思っています。AWS コミュニティがこれほど活気に満ちているのは、まさにこうしたヒーローたちのおかげです。ヒーローたちは、技術的な知識を共有するだけでなく、人脈を作り、真の人間的なつながりを築いて、他の人が成長するための進路を備えます。山村におけるクラウド文化の開拓から、大陸をまたいだサイバーセキュリティ教育の先導まで、これらのヒーローたちは、技術的な専門知識の枠を超えて、私たちが築くコミュニティと私たちが影響をもたらす人々の生活に拡大する真のリーダーシップを実証しています。 Maurizio 氏 – ピニョーラ、イタリア コミュニティヒーローである Maurizio 氏は、CTO と AWS User Group Basilicata の主催者を兼任しており、これまでテクノロジーエコシステムが存在しなかった場所でのエコシステムの構築に対する貢献で知られています。真の人間的なつながりと知識の伝達を中心とする理念を通じたクラウド文化の開拓を 10 年以上にわたって行ってきた Maurizio 氏は、世界的な専門家と現地の人材が会合するユニークな場を創り出すとともに、クラウドアーキテクチャ、DevOps、ウェブスケーリングに関する奥の深いテクニカルセッションと型破りなネットワーキング体験を融合させる国際的なテクノロジーカンファレンスを小さな山村で立ち上げました。Maurizio 氏は、イベントの企画だけにとどまらず、あらゆる世代を対象とするメンターとして休むことなく活動しています。この活動は、子供たちにコーディングを紹介することから、大学生やプロフェッショナルがクラウドアーキテクチャに移行するための支援までさまざまです。彼の影響力は、テクニカルリーダーシップと、ヨーロッパ各地の人々が集まるインクルーシブなコミュニティの構築という他にはない組み合わせを特徴としています。 Ray Goh 氏 – シンガポール AI ヒーローである Ray Goh 氏は、シンガポールを拠点とする経験豊かな AWS 機械学習および AI のコミュニティリーダーです。また、2018 年を皮切りに、AWS ASEAN Cloud Warrior や AWS Dev/Cloud Alliance から、2020 年 AWS Community Builder への先駆的メンバーとしての参加まで、さまざまな AWS コミュニティプログラムに長年貢献してきました。Goh 氏は 2024 年に Gen-C (生成 AI 学習コミュニティ) を設立し、LLM のファインチューニングから AWS の AI エージェントに及ぶさまざまなトピックの公開ワークショップをシンガポール全土の図書館で定期的に開催しています。AWS re:Invent、AWS Summit ASEAN、AWS Community Day Hong Kong の他、多数のユーザーグループミートアップでも講演を行っており、AWS 機械学習ブログにもゲスト寄稿しています。2020 年には DBS 銀行のために世界最大規模のエンタープライズ AWS DeepRacer プログラムの指揮を執って 3,100 人を超える従業員のスキルを向上させ、2025 年には 1,300 人を超える ASEAN の学生に対して LLM テクニックのトレーニングを行いました。Goh 氏のコミュニティ活動は、女性、子供、若者に AI と機械学習を教えるスキルベースの CSR イニシアチブにおよび、その貢献は CNBC と Euromoney でも紹介されました。 Sheyla Leacock 氏 – パナマシティ、パナマ セキュリティヒーローである Sheyla Leacock 氏は、IT セキュリティプロフェッショナル、メンター、テクニカルライター、かつ国際的な講演者であり、クラウドとサイバーセキュリティのグローバルコミュニティに貢献しています。Leacock 氏は、AWS Summit Mexico、ペルーで開催された AWS Summit LATAM での講演に加えて、AWS re:Invent のピアトークセッションでは進行役を務めました。それと同時にパナマの AWS ユーザーグループも先導しており、AWS Community Days や地域のミートアップにも定期的に参加しています。AWS に焦点を当てたイベント以外にも、20 を超える国際カンファレンスで講演を行い、AWS クラウドコンピューティングとサイバーセキュリティに関する技術論文や教育コンテンツを発表しています。また、ゲスト講師として複数の大学と連携し、新興技術の開発とサイバーセキュリティ人材の育成をサポートしています。Leacock 氏は、コミュニティリーダーシップ、知識の共有、教育を通じて、AWS とサイバーセキュリティエコシステムの強化に寄与しています。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブページ にアクセスしてください。 – Taylor 原文は こちら です。

この記事は、”Taking a comprehensive perspective to mainframe application modernization with a disposition strategy” を翻訳したものです。 はじめに メインフレームのお客様は、モダナイゼーションの選択肢が無数にあります。現在、多くの組織は、人材不足や、高額なコストとその上昇、レガシー環境ではビジネスアジリティに制限が掛かることで、モダナイゼーションが急務となっています。また、お客様自身も、モダナイゼーションの複数のパターン、ツール、戦略を自ずと模索しています。 配置戦略 (disposition strategy) には、メインフレームの複雑なモノリシックアプリケーションや大規模なコードベースへの対処に役立つ指針が含まれます。お客様は、レガシーアプリケーションを管理しやすい部分に分解し、ターゲットとなる移行パターンを開発し、移行の順序付けを行い、メインフレームに残るワークロードとの連携機能を構築します。この作業は、アプリケーションが密結合な状態から完全に切り離されるまで繰り返されます。 配置戦略とは、メインフレームモダナイゼーションに対する複数のパターンを複合的に組み合わせるアプローチです。ビジネス目標と IT 目標の優先順位とワークロードの特性に基づいて、個々のワークロードに適した適切なパターンが選択されます。配置戦略は、メインフレームモダナイゼーションを個々のプロジェクトとばらばらの移行フェーズの集まりと見なすのではなく、全体を包括的に見る視点を持つことを推奨します。これには、メインフレームからクラウドネイティブに至る長い道のりの最初から最後までの全行程を定義したロードマップが含まれます。このアプローチは、移行を加速し、リスクを軽減し、お客様が許容できる期間内にビジネス目標と技術目標を達成できるよう支援するのに役立ちます。 指針として目指す北極星を定義する メインフレーム資産は、地域、業界、顧客によってさまざまであり、まったく同じメインフレームアプリケーションは 2 つとありません。レガシーテクノロジー、ビジネス目標、将来の要件、リスクへの関心は、お客様によって非常に多様です。多くの大企業では、複数の事業部門がメインフレーム上で稼働するアプリケーションによってサポートされています。また、これらの事業部門には、メインフレーム処理に依存する多数のビジネスリーダー、アプリケーションオーナー、およびステークホルダーが組織全体に存在しています。このダイナミクスにより、組織がメインフレームの将来の状態に関する明確な戦略を欠いているというシナリオがしばしば生じます。モダナイゼーションの初期段階では、メインフレームのさまざまなステークホルダーが独自に活動し、それぞれ別個に戦略を導入または計画しているお客様をよく見かけます。その結果、モダナイゼーションへのアプローチがばらばらになります。このようなときのモダナイゼーションには、組織のモダナイゼーションの道しるべとなる北極星のようなビジョンが明確になっていない可能性があります。 メインフレームモダナイゼーションプログラム (※1) を成功させるための第一歩は、北極星 (North Star: 目指すべき指針) を定義することです。この北極星は、経営幹部、そして多くの場合、組織の取締役会にも共有されます。お客様は、メインフレームを使い続けることで増大するリスク、コスト、競争上の不利益を認識しています。レガシーアプリケーションのモダナイゼーションを経営幹部が指示することで、より迅速かつ緊急に職務を遂行し、成果を上げているお客様を我々は目にして来ました。明確なミッションが無いため、一連のばらばらで戦術的なモダナイゼーションプログラムに参加することになったお客様も見て来ました。ばらばらなプログラムでは、メインフレームプラットフォームのワークロードの移行には成功しても、モダナイゼーションのメリットを最大限に引き出すには苦労するかもしれません。場合によっては、メインフレームに課せられた制約が原因で MIPS の使用量が増加することさえあります。このような状況を避けるため、お客様には主に 3 つの質問に答えて北極星を定義することをおすすめします。 なぜ私たちはモダナイゼーションを進めているのか? 私たちはどこに向かっているのか? それはいつ実現するのか? これらの質問に答えることで、メインフレーム移行プログラムを成功させるための基礎を確立し、組織が共有する共通のビジネス目標と技術目標を定義しやすくなります。 (※1) 訳注: ここでのプログラムは、共通の戦略的目標を持つ複数の関連プロジェクトを統合・管理することにより、単独プロジェクトの成功を目指す部分最適では無く、全体最適による価値を創出する手法としてのプログラムマネジメントの文脈で使われています。レガシーコードのプログラムを指すものではありません。 モダナイゼーションのビジネス基準: ビジネス要件と技術的現実のバランス ビジネス目標は、組織内の部門によって大きく異なる場合があります。ビジネスユニットによっては、レガシーアプリケーションの機能を早急に変更しなければならない場合もあれば、確立されたプロセスやユーザーエクスペリエンスの変更に抵抗しているビジネスユニットもあります。大まかに言うと、ビジネスの優先事項は次の 2 つのカテゴリに分類されます。 カテゴリー 1: ビジネス機能は変わらないが、ビジネスの俊敏性にはテクノロジーのモダナイゼーションが不可欠 機能的な変化が望まれていない場合。 このシナリオでは、レガシーアプリケーションがサポートする既存のビジネス機能に、ビジネスユーザーはとても満足しています。現行のビジネス機能やワークフローは変更する必要がなく、ビジネスユーザーは機能変更という考えに反対しています。これは、ユーザーが端末エミュレーターの黒画面を操作しているお客様にも当てはまる可能性があります。端末エミュレーターを長年使い続けているユーザーは、操作に熟練しているので作業効率が非常に高く、最新の UX に置き換えると生産性が低下する可能性があります。 お客様はメインフレームワークロードの大部分が一般にこのカテゴリに入ると想定する必要があります。メインフレームアプリケーションは何十年も組織で使われてきました。これらのアプリケーションは、個別のビジネスロジックが何年にもわたって使われてきたビジネスに適しているかもしれません。大企業と各業界で差別化されたビジネスのやり方に合わせてカスタマイズされている可能性があります。すべてのアプリケーションに機能的なトランスフォーメーションが必要なわけではありません。安定性と予測可能性が最優先されるシステムの場合は、以下の選択肢を考慮することが重要です。 リファクタリング (Refactor) : レガシーアプリケーションを最新のプログラミング言語とリレーショナルデータベースに変換します。たとえば、 AWS Transform for mainframe を使うと、お客様は AWS の専門的な AI エージェントを使用して COBOL アプリケーションを AWS 上の Java にリファクタリングできます。 リプラットフォーム (Replatform) : 既存の機能を維持し、レガシーテクノロジースタックを維持しながら、よりモダンなインフラストラクチャに移行します。たとえば、AWS Mainframe Modernization には、クラウド内のメインフレーム互換ランタイムにリプラットフォームするためのオプションが用意されています。 これらのアプリケーションのモダナイゼーションでは、機能以外のモダナイゼーションのメリット (耐障害性、影響範囲の縮小、可用性、俊敏性) にフォーカスしてコミュニケーションします。 カテゴリー 2: 技術的な負債を取り除いたり、新しい機能を追加したり、モノリスを分解してプロダクトを調整したりするには、ビジネス機能の変更が必要 機能強化の要件がある場合。 ビジネス部門がアプリケーションの機能を強化する必要があるのはこの場合です。一般に、お客様はメインフレームワークロードの一部だけがこのカテゴリに該当すると予想しています。このような状況では、企業はモダンな UI、リアルタイム機能、またはより高速なバッチ処理を望んでいる可能性があります。また、お客様は、モノリス化した現行アプリケーションをプロダクトに合わせたビジネス機能に分割したいという目標を持っているかもしれません。このアプローチにより、マイクロサービスアーキテクチャを構築し、疎結合化することによってアジリティとイノベーションを促進されます。 ニアリアルタイムの機能に対するエンドカスタマーの期待の高まりに直面するお客様が増えています。メインフレーム上のモノリス化したアプリケーションにこのような機能を導入するのは困難です。さらに、新しい市場や業界への進出、あるいは顧客基盤の拡大を目指すお客様にも会うことがあります。成長目標を積極的に掲げているお客様は、メインフレームアプリケーションを維持することが、成長や新規ビジネスの獲得を阻害していると気付くことがよくあります。 成長の可能性 : モダナイズすることで、新しい収益源を開拓したり、事業拡大を支援したりできるアプリケーションはどれか? カスタマーエクスペリエンスへの影響 : 顧客とのやり取りや顧客満足度に直接影響するアプリケーションはどれか? 市場への対応力 : 現在、市場の変化への対応能力を制限しているのはどのシステムか? イノベーションの可能性 : 最新の開発手法や最先端技術との連携から最も恩恵を受けるのはどのアプリケーションか? 一般的に、強化すべき機能要件が明確に示されているビジネスユニットは、より優先されるはずです。新機能、ユーザーエクスペリエンスの向上、連携機能など、個々のニーズが具体的な目標を提示し、それによってモダナイゼーションの取り組みが推進され、目に見える価値が示されます。 Reimagine パターン とは、メインフレームアプリケーションのアーキテクチャを最新のテクノロジースタックに合わせて設計し直し、コードを書き直すことと定義されています。このモダナイゼーションの目標は、アプリケーションに機能的な変更を導入することです。ビジネスが新しい機能を必要とする場合、reimagine パターンが望ましいアプローチです。 モダナイゼーションのための技術的基準 メインフレームモダナイゼーションの配置戦略には、組織レベルとアプリケーションレベルの両方で評価された技術的基準も組み込む必要があります。 組織レベルでの技術的考慮事項の評価: データセンターから出て行くための戦略や緊急性が高い移行期限 データセンターの撤退を迫られている組織は、移行の期限が迫っているため、スピードとリスクの軽減を優先する必要があります。コードを変更せずにメインフレームのワークロードをパートナーが管理するデータセンターに移動することを意味するリホスト (rehost) パターンは、実践的な第一歩となる可能性があります。多くの場合、リホストアプローチは、他の移行パターンのように長いサイクルを通ることなく、数ヶ月で完了できます。リホストは事業継続につながります。また、将来のモダナイゼーションの基礎を築き、組織がより高度なパターンを徐々に適用するのにも役立ちます。これらのパターンは、時間とリソースの制約の中で、リファクタリングや reimagine などのモダナイゼーションのニーズに対応できます。 ニッチなメインフレーム技術: プログラミング言語、トランザクションモニター、データベース 既存のメインフレームアプリケーションで使用されている特定のプログラミング言語、トランザクションモニター、データベーステクノロジーは、モダナイゼーションの取り組みの実現可能性と複雑さに大きな影響を与えることがあります。これは、メインフレームモダナイゼーションの配置戦略を検討する際に、重要な技術的考慮事項です。 Natural/Adabas、IDMS などの特定のメインフレームテクノロジーは、リプラットフォームやリファクタリングなどの一部のモダナイゼーションパターンでは直接サポートされていなかったり、完全にはサポートされていない場合があります。これらのレガシーメインフレームテクノロジーの可用性と保守性のスキルも、考慮点の 1 つです。これにより、利用できるモダナイゼーションの選択肢が制限される可能性があり、実行可能な選択肢はリプレース (replace) (※2) や reimagine などのパターンだけかもしれません。 組織は、使用されているメインフレームのテクノロジースタックと、それがさまざまなモダナイゼーションアプローチの実現可能性や複雑さにどの程度合致するかを注意深く評価する必要があります。この技術的評価は、適切な配置戦略を決定するうえで重要なインプットとなります。 (※2) 訳注: 本ブログ内のリプレース (replace) は、パッケージソフトウェア製品の購入や SaaS のサブスクリプション契約等を指すリパーチェス (repurchase) と同義で使われています ベンダーによる更新のタイムライン メインフレームモダナイゼーションの配置戦略を評価する際、ベンダーの更新スケジュールは重要な技術的検討事項になり得ます。組織には、ソフトウェアライセンス契約が異なるさまざまなメインフレームベンダーが存在することがよくあります。契約条件の評価にあたっては、更新時期が迫ることでリスクが高まります。この場合、中には、それらのベンダーのテクノロジーからできるだけ早く撤退することが最も価値ある結果になると判断するお客様もいます。このタイムラインの速さは、選択するモダナイゼーションアプローチにも影響します。 たとえば、ライセンス契約の終了期限が迫っている場合は、リプレースアプローチや reimagine アプローチよりも、リファクタリングパターンの方が適している場合があります。リファクタリングは、コア機能を維持しながらアプリケーションをモダナイズするのに役立ちます。多くの場合、全面的な書き直し (full rewrite) や再実装 (reimplementation) よりも短時間で完了できます。 ただし、すべてのリファクタリングソリューションがすべてのメインフレームテクノロジーをサポートしているわけではない点に注意することが重要です。使用中の特定のテクノロジーに適したリファクタリングソリューションの評価を完了する必要があります。場合によっては、明白なリファクタリングソリューションや実証済のリファクタリングソリューションがないこともあります。必要な期限までにベンダーのテクノロジーから撤退するには、reimagine またはリプレースのアプローチしか実行できない場合があります。 最良のモダナイゼーション戦略を決定する際には、全体的な技術評価の一環として、メインフレームベンダーの契約と更新スケジュールを評価することが重要です。これにより、選択したアプローチを、特定のベンダーのテクノロジーから撤退する緊急性に合わせることができます。 動員可能なメインフレームスキルセット メインフレームのスキルセットに制約があるために企業が人材リスクに直面している場合、そのスキルへの依存度が低いメインフレームモダナイゼーションの選択肢を選ぶことが重要です。このような場合、メインフレームアプリケーションのリファクタリングや reimagine などの戦略が効果的なアプローチになり得ます。 逆に、組織内に有能なメインフレーム人材プールがある場合は、リプラットフォームアプローチがモダナイゼーションに適した戦略となり得ます。既存の専門知識を活用して、ワークロードをよりモダンなプラットフォームに移行することができます。 アプリケーション/ワークロードの技術的な複雑さと依存関係の評価 適切なパターンの選択は、ビジネス上の考慮事項と技術的要件の両方に基づいて行う必要があります。各ワークロードまたはアプリケーションの特定の特性を考慮する必要があります。 さまざまなアプリケーションやワークロードを徹底的に技術評価して、それぞれに最適なモダナイゼーションアプローチを決定することが重要です。この評価フェーズでは、以下の要素を考慮します。 移行元のテクノロジー : プログラミング言語と既存のソースコードの量を評価します。一部の言語とフレームワークは、他の言語とフレームワークよりも自動化されたトランスフォーメーションとモダナイゼーションに適しています。これは、特定のモダナイゼーションパターンの実現可能性と複雑さに影響する可能性があります。 データに関する考慮事項 : メインフレームで使われているデータストア技術 (Db2、IMS/DB、VSAM など) を評価します。データ量、データ構造の複雑さ、データエンティティ間の関係を評価します。データの性質と複雑さが、適切なモダナイゼーションアプローチに影響する可能性があります。 結合度 : さまざまなアプリケーションとワークロード間の結合レベルを特定します。たとえば、トランザクションコンテキストの伝播を含むアプリケーションは、密結合されている可能性があります。この場合、疎結合の場合やサービス境界が明確な場合よりも、モダナイゼーションの課題が大きくなります。モダナイゼーションの過程において、密結合された機能の相互依存関係に順次対処し、具体的に管理する必要があるためです。 連携の複雑さと依存関係 : アプリケーションとワークロードの間のさまざまな連携ポイントを評価します。共有リソース、データ依存関係、全体的な連携の複雑さを特定します。これにより、既存の連携を維持できる適切なモダナイゼーションパターンを判断したり、リスクを抑えて移行を行ったりするのに役立ちます。 外部インターフェース : 選択したモダナイゼーションパターンによっては、外部インターフェースを介してメインフレームにアクセスするメインフレームの外部のクライアントアプリケーションの一部が変更されることがあります。選択したパターンが、すべての外部接続ポイント、API 操作、および外部システムとのデータ交換メカニズムに必要なインターフェースをサポートしていることを確認します。 この詳細な技術評価では、次のような要素を考慮する必要があります。 読み取り/書き込みモードで同じデータにアクセスするアプリケーションをグループ化し、それらのグループに同じ移行パターンを選択する 結合度が高いワークロードには同じ移行パターンを選択する 移行元のプログラミング言語がさまざまな移行パターンの実現可能性に与える影響を考慮する 外部インターフェースや連携への変更を可能な限り最小限に抑える移行パターンを選択する アプリケーションとワークロードの分析は、全体的な配置戦略の重要なインプットです。ワークロード固有の技術的特徴と依存関係に基づいて、ワークロードに適したモダナイゼーションパターンとソリューションを追加できます。 移行戦略の策定 ビジネス成果駆動型プログラムの構築 モダナイゼーションを純粋に技術的な課題として扱うのではなく、次のようなプログラムを確立します。 組織の北極星から逆算して考える : 冒頭で述べたように、お客様はメインフレーム資産に関する組織的な戦略とアプローチを必要としています。成功するメインフレーム移行プロジェクトは、経営陣が設定した変動要素(予算や期間、体制等)の枠組みの中で実施されます。なぜモダナイゼーションを行っているのか、どこに向かっているのか、いつモダナイゼーションを実現するのか、といった点を見失わないようにします。 戦略的ビジネス目標との連動 : モダナイゼーションは、俊敏性の向上、カスタマーエクスペリエンスの向上、新しい機能など、特定のビジネス成果をサポートするものでなければなりません。 ポートフォリオ全体を最初から検討する : モダナイゼーションが段階的なアプローチとして定義されている場合でも、新しいテクノロジーのサイロ化を避けるため、計画はアプリケーション全体を対象とする必要があります。 戦術的な成果と戦略的目標のバランスを取る : 包括的なモダナイゼーションに向けて取り組みながら、段階的な価値をもたらすプログラムを設計します。 成功の明確な指標を確立する : ビジネス面と技術面の両方で、進捗状況をどのように測定するか定義します。 経営幹部レベルで戦略が設定されていないと、個々のチームが異なるアプローチを採用したり、「様子を見る」という考えに陥ったりする可能性があります。これにより、モダナイゼーションが遅れ、複雑さが増す可能性があります。 「すべてを再構築」という落とし穴の回避 私たちの経験から、80:20 の原則はメインフレーム資産にも一般的に当てはまることがわかっています。メインフレームアプリケーションの約 80% は機能変更を必要とせず、約 20% のアプリケーションでは reimagine が必要です。 お客様には、大幅な脱メインフレームを含むモダナイゼーションのアプローチを検討することをお勧めします。Transamerica や Goldman Sachs などのお客様は、リファクタリングやリプラットフォームパターンを利用して、ミッションクリティカルなメインフレームワークロードを AWS に移行することに成功しています。アプリケーションごとに個別のアプローチを取るだけだと時間がかかり過ぎて、ビジネス上の必要性を満たせない場合があります。ビジネス目標と技術目標に基づいて、複数のモダナイゼーションパターンを組み込むことを検討します。 大規模なリファクタリング : AWS Transform for mainframe には、レガシーアプリケーションをモダンな Java フレームワークにモダナイズするのに役立つリファクタリング機能が備わっています。このパターンは、決定論的ツールによってもたらされる移行スケジュールの短縮の恩恵を受けながら、レガシーテクノロジーへの依存を減らしたい場合に使用できます。 リプラットフォーム : リプラットフォームでは、エミュレーションテクノロジーを使用して、メインフレームアプリケーションをそのまま移行します。これはしばしば「COBOL から COBOL への移行」と呼ばれます。この場合、リプラットフォームパターンにより、COBOL の人材不足の状況に対処し、脱メインフレームを加速させることができます。 大規模なモダナイゼーションアプローチと戦略的な reimagine を組み合わせることで、お客様はプラットフォームからの撤退に向けて前進しながら、技術的成果とビジネス上の成果を一致させる機会を得ることができます。複数のパターンを社内の戦略で検討しているお客様は、組織内のより多様な目標に取り組むことができます。これは、同じ期間内に運用コスト削減目標を達成しながら行われます。 まとめ: 今こそ行動の時です 今日、メインフレームアプリケーションのモダナイゼーションが強く求められています。人材不足、ソフトウェアコストの上昇、組織の非効率性といったよく挙げられる課題のほかに、新たな要因が浮かび上がってきました。それは、生成 AI がソフトウェア開発に与える影響の増大です。生成 AI コーディングアシスタントがモダンな言語の生産性に革命をもたらすにつれ、モダンテクノロジーとメインフレームテクノロジーの間の開発スピードと生産性のギャップはさらに悪化するでしょう。COBOL や Assembler、PL/I 言語のアプリケーションを使用する組織は、価値創出のスピードという点で競争上の不利な点に直面するケースが増えています。同業他社が運用する基幹システムは、開発スピードがますます速くなるモダンなテクノロジーで書かれた基幹システムを運用しているかも知れません。 メインフレームモダナイゼーションに「特効薬」はありません。成功するには、具体的な成果に基づいて IT 目標とビジネス目標を一致させる、ビジネス駆動型のマルチパターンアプローチが必要です。自動化を行い、段階的に反復することで、コスト削減以外の価値に集中できます。 配置戦略は、各アプリケーションポートフォリオの微妙な違いを認識した、このジャーニーの枠組みとなります。このアプローチでメインフレームアプリケーションをモダナイズすることで、組織は数十年にわたって構築された貴重なビジネスロジックを維持しながら、将来のイノベーション需要に備えることができます。 Tim Gray Tim は AWS の Worldwide Go-to-market Specialist で、AWS Transform for mainframe のリードを担当しています。 Tim は、お客様が AWS Transform を活用して基幹システムを reimagine し、モダナイズすることによる AWS への移行を支援するべく、市場開拓戦略に注力しています。現在、Tim は、大規模なモダナイゼーションプログラムをこれまでにない時間枠で加速させる生成 AI およびエージェンティック AI サービスをデプロイするための再現可能なパターンの構築に注力しています。 Sunil Divvela Sunil Divvela は、AWS の Mainframe Modernization 担当 Worldwide Specialist Solutions Architect です。お客様やパートナーと緊密に連携して、生成 AI やエージェンティック AI を活用したポートフォリオ評価から移行後のサポートに至るまで、メインフレームモダナイゼーションの取り組みを革新し加速させています。AWS 入社前、Sunil は Infosys の Senior Technology Architect として、複数のメインフレームトランスフォーメーションプロジェクトをリードしていました。 Yann Kindelberger Yann Kindelberger は、Amazon Web Services の Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

本記事は 2026 年 1 月 12 日 に公開された「 Navigating architectural choices for a lakehouse using Amazon SageMaker 」を翻訳したものです。 組織がデータを活用して意思決定やイノベーションを推進する動きは加速しています。ペタバイト規模の情報を扱う中で、従来はデータレイクとデータウェアハウスという 2 つの異なるパラダイムに分かれてきました。それぞれ特定のユースケースに強みがある一方、データ資産間に意図しない障壁を生むことがあります。 データレイクは Amazon Simple Storage Service (Amazon S3) などのオブジェクトストレージ上に構築されることが多く、多様なデータ形式とスキーマ・オン・リード機能をサポートする柔軟性を提供します。そのため、 Apache Spark 、 Trino 、 Presto などの様々な処理フレームワークが同じデータにクエリできる マルチエンジンアクセス が可能になります。一方、データウェアハウス ( Amazon Redshift など) は、ACID (原子性、一貫性、分離性、耐久性) 準拠、パフォーマンス最適化、簡単なデプロイメントに優れており、構造化された複雑なクエリに適しています。データ量の増加と分析ニーズの複雑化に伴い、組織はデータレイクとデータウェアハウスのサイロを橋渡しし、両方のパラダイムの強みを活用しようとしています。レイクハウスアーキテクチャはデータ管理と分析を統合的に扱うアプローチとして注目されています。 時間の経過とともに、いくつかの異なるレイクハウスアプローチが登場しました。本記事では、ニーズに合った適切なレイクハウスパターンの評価と選択方法を紹介します。 データレイク中心のレイクハウス アプローチは、オブジェクトストレージ上に構築された従来のデータレイクのスケーラビリティ、コスト効率、柔軟性から始まります。目標は、主にオープンテーブルフォーマット ( Apache Hudi 、 Delta Lake 、 Apache Iceberg ) を通じて、従来データベースにあったトランザクション機能とデータ管理レイヤーを追加することです。オープンテーブルフォーマットはデータレイクの単一テーブル操作に ACID 保証を導入する点で大きく進歩しましたが、複雑な参照整合性制約やジョインを伴うマルチテーブルトランザクションの実装は依然として困難です。オブジェクトストレージ上のペタバイト規模のファイルに対するクエリは、分散クエリエンジンを介することが多く、高度に最適化・インデックス化・マテリアライズ化されたデータウェアハウスと比較すると、高い同時実行性でのインタラクティブクエリが遅くなる可能性があります。オープンテーブルフォーマットはコンパクションとインデックスを導入していますが、成熟した独自仕様のデータウェアハウスに見られる高度なストレージ最適化機能は、データレイク中心のアーキテクチャではまだ発展途上です。 データウェアハウス中心のレイクハウス アプローチは充実した分析機能を提供しますが、相互運用性に大きな課題があります。データウェアハウスは外部アクセス用に JDBC および ODBC ドライバーを提供していますが、基盤となるデータは独自仕様の形式のままであり、複雑な ETL や API レイヤーなしでは外部ツールやサービスが直接アクセスすることが困難です。データの重複とレイテンシーにつながる可能性があります。データウェアハウスアーキテクチャはオープンテーブルフォーマットの読み取りをサポートする場合がありますが、書き込みやトランザクションレイヤーへの参加能力は限定的です。真の相互運用性が制限され、意図しないデータサイロが生まれる可能性があります。 AWS では、データウェアハウスとデータレイクの両方への統合アクセスを実現する モダンでオープンなレイクハウスアーキテクチャ を構築できます。このアプローチにより、データの単一の信頼できるソースを維持しながら、高度な分析、機械学習 (ML)、生成 AI アプリケーションを構築できます。データレイクかデータウェアハウスかを選ぶ必要はありません。既存の投資を活用し、両方のパラダイムの強みを維持しつつ、それぞれの弱点を解消できます。AWS のレイクハウスアーキテクチャは、Apache Hudi、Delta Lake、Apache Iceberg などのオープンテーブルフォーマットを採用しています。 次世代の Amazon SageMaker でレイクハウスの導入を加速できます。SageMaker はデータへの統合アクセスを備えた分析と AI の統合エクスペリエンスを提供します。SageMaker は Apache Iceberg と完全互換のオープンレイクハウスアーキテクチャ上に構築されています。Apache Iceberg REST API のサポートを拡張することで、SageMaker は様々な Apache Iceberg 互換クエリエンジンやツール間の相互運用性とアクセシビリティを大幅に向上させています。このアーキテクチャの中核には、 AWS Glue Data Catalog と AWS Lake Formation 上に構築されたメタデータ管理レイヤーがあり、統合ガバナンスと一元的なアクセス制御を提供します。 Amazon SageMaker レイクハウスアーキテクチャの基盤 Amazon SageMaker のレイクハウスアーキテクチャには、統合データプラットフォームを構成する 4 つの主要コンポーネントがあります。 ワークロードパターンと要件に適応する柔軟なストレージ すべてのメタデータの単一の信頼できるソースとなるテクニカルカタログ すべてのデータ資産にわたるきめ細かなアクセス制御を備えた統合権限管理 Apache Iceberg REST API 上に構築された、ユニバーサル互換性のためのオープンアクセスフレームワーク カタログと権限 オープンレイクハウスを構築する際、メタデータの中央リポジトリであるカタログは、データ検出とガバナンスの重要なコンポーネントです。Amazon SageMaker のレイクハウスアーキテクチャには、マネージドカタログとフェデレーテッドカタログの 2 種類のカタログがあります。 マネージドカタログは、レイクハウスがメタデータを管理し、データを汎用 S3 バケットに保存する形態です。 フェデレーテッドカタログは、外部や既存のデータソースをマウント・接続し、データを移動せずに Amazon Redshift 、Snowflake、 Amazon DynamoDB などのデータソースに直接クエリできる形態です。詳細は「 Data connections in the lakehouse architecture of Amazon SageMaker 」を参照してください。 AWS Glue クローラー を使用して、 Data Catalog にメタデータを自動的に検出・登録できます。Data Catalog はデータ資産のスキーマとテーブルメタデータを保存し、ファイルを論理テーブルに変換します。データがカタログ化されたら、次の課題はアクセス制御です。フォルダごとに複雑な S3 バケットポリシーを使用することもできますが、管理とスケーリングが困難です。 Lake Formation は Data Catalog 上にデータベーススタイルの一元的な権限モデルを提供し、個々のユーザーやロールに対して行、列、セルレベルのきめ細かなアクセスを付与または取り消す柔軟性を備えています。 Apache Iceberg REST API によるオープンアクセス 前述のレイクハウスアーキテクチャ (以下の図の) は、サービスエンドポイントを通じて AWS Glue Iceberg REST カタログ も使用しています。OSS 互換性を提供し、Spark やその他のオープンソース分析エンジン間で Iceberg テーブルメタデータを管理するための相互運用性を向上させます。テーブルフォーマットとユースケースの要件に基づいて適切な API を選択できます。 本記事では、データレイクとデータウェアハウスを最適に活用してスケーラブルで高パフォーマンスなデータソリューションを構築する方法に焦点を当て、様々なレイクハウスアーキテクチャパターンを探ります。 AWS でレイクハウスにデータを取り込む レイクハウスアーキテクチャを構築する際、データのアクセスと統合には 3 つの異なるパターンから選択でき、それぞれ異なるユースケースに固有の利点を提供します。 従来の ETL は、データを抽出し、変換してレイクハウスにロードする従来の方法です。 使用すべきケース: 複雑な変換が必要で、パフォーマンス向上のためにダウンストリームアプリケーション向けに高度にキュレーションされ最適化されたデータセットが必要な場合 過去データの移行が必要な場合 大規模なデータ品質の適用と標準化が必要な場合 レイクハウスに高度にガバナンスされたキュレーション済みデータが必要な場合 Zero-ETL は、ソースシステムからレイクハウスへデータを最小限の手動介入やカスタムコードで自動的かつ継続的にレプリケートするモダンなアーキテクチャパターンです。内部的には、変更データキャプチャ (CDC) を使用して、ソースからターゲットへのすべての新規挿入、更新、削除を自動的にストリーミングします。このアーキテクチャパターンは、ソースシステムが高いデータクリーンネスと構造を維持しており、ロード前の重い変換の必要性が最小限の場合、またはデータの精製と集約がレイクハウス内のターゲット側で行える場合に効果的です。Zero-ETL は最小限の遅延でデータをレプリケートし、変換ロジックはインサイトが生成される場所に近いターゲット側で、より効率的なロード後フェーズとして実行されます。 使用すべきケース: 運用の複雑さを軽減し、準リアルタイムとバッチの両方のユースケースでデータレプリケーションを柔軟に制御する必要がある場合 カスタマイズが限定的で十分な場合。Zero-ETL は最小限の作業を意味しますが、レプリケートされたデータに軽い変換が必要な場合もあります 専門的な ETL の専門知識の必要性を最小限に抑えたい場合 処理遅延なしでデータの鮮度を維持し、データの不整合リスクを軽減する必要がある場合。Zero-ETL はインサイトまでの時間を短縮します データフェデレーション (データ移動なしのアプローチ) は、データを単一の集中場所に物理的に移動またはコピーせずに、複数の異なるソースからデータをクエリ・結合できる方法です。この クエリインプレース アプローチにより、クエリエンジンが外部ソースシステムに直接接続し、クエリを委任・実行し、結果をオンザフライで結合してユーザーに提示できます。このアーキテクチャパターンの効果は、システム間のネットワークレイテンシー、ソースシステムのパフォーマンス能力、クエリエンジンの述語のプッシュダウン能力の 3 つの要因に依存します。このデータ移動なしのアプローチにより、ソースデータへのリアルタイムアクセスを提供しながら、データの重複とストレージコストを大幅に削減できます。 使用すべきケース: オペレーショナル分析のためにソースシステムに直接クエリする必要がある場合 レイクハウス内のストレージスペースと関連コストを節約するためにデータを複製したくない場合 即時のデータ可用性とライブデータの一回限りの分析のために、クエリパフォーマンスとガバナンスの一部をトレードオフしてもよい場合 データを頻繁にクエリする必要がない場合 AWS でのレイクハウスのストレージレイヤーを理解する レイクハウスにデータを取り込む様々な方法を確認したところで、次の問題はデータの保存先です。以下の図のように、AWS ではデータレイク (Amazon S3 または Amazon S3 Tables ) またはデータウェアハウス ( Redshift Managed Storage ) にデータを保存してモダンなオープンレイクハウスを構築でき、ワークロード要件に基づいて柔軟性とパフォーマンスの両方を最適化できます。 モダンなレイクハウスは単一のストレージ技術ではなく、それらの戦略的な組み合わせです。データの保存場所と方法は、ダッシュボードの応答速度から ML モデルの効率まで幅広く影響します。ストレージの初期コストだけでなく、データ取得の長期コスト、ユーザーが求めるレイテンシー、単一の信頼できるソースを維持するためのガバナンスも考慮が必要です。このセクションでは、データレイクとデータウェアハウスのアーキテクチャパターンを掘り下げ、各ストレージパターンをいつ使用すべきかの明確なフレームワークを提供します。かつては競合するアーキテクチャと見なされていましたが、モダンでオープンなレイクハウスアプローチは両方を活用して単一の強力なデータプラットフォームを構築します。 汎用 S3 Amazon S3 の 汎用 S3 バケット は、オブジェクトの保存に使用される標準的な基本バケットタイプです。厳格な事前スキーマなしでネイティブ形式のデータを保存できる柔軟性を提供します。S3 バケットはストレージとコンピューティングを分離できるため、高度にスケーラブルな場所にデータを保存しながら、様々なクエリエンジンが独立してアクセス・処理できます。データの移動や複製なしに、ジョブに適したツールを選択できます。ストレージ容量のプロビジョニングや管理なしでペタバイト規模のデータを保存でき、 階層型ストレージクラス により、アクセス頻度の低いデータをより手頃なストレージに自動的に移動して大幅なコスト削減を実現します。 既存の Data Catalog はマネージドカタログとして機能します。AWS アカウント番号で識別されるため、既存の Data Catalog の移行は不要で、レイクハウスですでに利用可能であり、以下の図のように新しいデータのデフォルトカタログになります。 汎用 S3 上の基本的なデータレイクは、追記専用ワークロードに非常に効率的です。ただし、ファイルベースの性質上、従来のデータベースのトランザクション保証が欠けています。Apache Hudi、Delta Lake、Apache Iceberg などのオープンソースのトランザクショナルテーブルフォーマットを活用すると、この課題を解決できます。テーブルフォーマットによりマルチバージョン同時実行制御（MVCC）を実装でき、複数のリーダーとライターが競合なく同時に操作できます。スナップショット分離を提供するため、書き込み操作中でもリーダーはデータの一貫したビューを参照できます。以下の図は Apache Iceberg を使用した典型的なメダリオンアーキテクチャパターンを示しています。AWS で Apache Iceberg を使用してレイクハウスを構築する場合、Amazon S3 上のデータ保存には、セルフマネージド Iceberg を使用した汎用 S3 バケットと、フルマネージドの S3 Tables の 2 つの主要なアプローチから選択できます。それぞれに明確な利点があり、制御、パフォーマンス、運用負荷に対する具体的なニーズによって適切な選択が異なります。 セルフマネージド Iceberg を使用した汎用 S3 セルフマネージド Iceberg を使用した汎用 S3 バケットは、データと Iceberg メタデータファイルの両方を標準 S3 バケットに保存する従来のアプローチです。このオプションでは完全な制御を維持しますが、コンパクションやガベージコレクションなどの必須メンテナンスタスクを含む、Iceberg テーブルのライフサイクル全体を自分で管理する必要があります。 使用すべきケース: 最大限の制御: データライフサイクル全体を完全に制御できます。コンパクションのスケジュールや戦略の定義など、テーブルメンテナンスのあらゆる側面を微調整でき、特定の高パフォーマンスワークロードやコスト最適化に重要です。 柔軟性とカスタマイズ: 強力な社内データエンジニアリング専門知識を持ち、より幅広いオープンソースツールやカスタムスクリプトとの統合が必要な組織に最適です。 Amazon EMR や Apache Spark を使用してテーブル操作を管理できます。 初期コストの低さ: Amazon S3 ストレージ、API リクエスト、メンテナンス用コンピューティングリソースの料金のみ発生します。継続的な自動最適化が不要な小規模または低頻度のワークロードでは、よりコスト効率が高くなる可能性があります。 注意: クエリパフォーマンスは最適化戦略に完全に依存します。コンパクションの継続的なスケジュールジョブがないと、データの断片化に伴いパフォーマンスが低下する可能性があります。効率的なクエリを確保するために、コンパクションジョブを監視する必要があります。 S3 Tables S3 Tables は、分析ワークロードに最適化された S3 ストレージを提供し、大規模な表形式データを保存するための Apache Iceberg 互換性を備えています。S3 テーブルバケットとテーブルを Data Catalog と統合し、Lake Formation コンソールまたはサービス API で Lake Formation データロケーションとしてカタログを登録できます (以下の図の)。このカタログはフェデレーテッドレイクハウスカタログとして登録・マウントされます。 使用すべきケース: 運用の簡素化: S3 Tables はコンパクション、スナップショット管理、孤立ファイルのクリーンアップなどのテーブルメンテナンスタスクをバックグラウンドで自動的に処理します。カスタムメンテナンスジョブの構築・管理が不要になり、運用負荷を大幅に軽減できます。 自動最適化: S3 Tables はクエリパフォーマンスを向上させる組み込みの自動最適化を提供します。スモールファイル問題に対処するファイルコンパクションや、表形式データに特化したデータレイアウト最適化などのバックグラウンドプロセスが含まれます。ただし、自動化と柔軟性はトレードオフの関係にあります。コンパクション操作のタイミングや方法を制御できないため、特定のパフォーマンス要件を持つワークロードではクエリパフォーマンスにばらつきが生じる可能性があります。 データ活用への集中: S3 Tables はエンジニアリングの負荷を軽減し、データの消費、データガバナンス、価値創造に焦点を移します。 オープンテーブルフォーマットへの簡単な導入: Apache Iceberg の概念は初めてだが、データレイクでトランザクション機能を活用したいチームに適しています。 外部カタログ不要: 外部カタログを管理したくない小規模チームに適しています。 Redshift Managed Storage データレイクはすべてのデータの中央の信頼できるソースとして機能しますが、すべてのジョブに最適なデータストアではありません。最も要求の厳しいビジネスインテリジェンスとレポーティングワークロードでは、データレイクのオープンで柔軟な性質がパフォーマンスの予測不可能性をもたらす可能性があります。望ましいパフォーマンスを確保するために、以下の理由でデータレイクからデータウェアハウスへキュレーション済みデータのサブセットを移行することを検討してください: 高同時実行 BI とレポーティング: 数百のビジネスユーザーがライブダッシュボードで複雑なクエリを同時に実行する場合、データウェアハウスは予測可能なサブ秒のクエリレイテンシーで高同時実行ワークロードを処理するよう特別に最適化されています。 予測可能なパフォーマンス SLA: 財務レポートや日次売上分析など、保証された速度でデータを配信する必要がある重要なビジネスプロセスでは、データウェアハウスが一貫したパフォーマンスを提供します。 複雑な SQL ワークロード: データレイクは強力ですが、多数のジョインや大規模な集約を伴う非常に複雑なクエリでは苦戦する可能性があります。データウェアハウスは複雑なリレーショナルワークロードを効率的に実行するために構築されています。 AWS のレイクハウスアーキテクチャは Redshift Managed Storage (RMS) をサポートしています。RMS は、Amazon Redshift が提供するフルマネージドのストレージオプションです。RMS ストレージは、データウェアハウジングワークロード向けの組み込みクエリ最適化、 自動マテリアライズドビュー 、頻繁に実行されるワークロード向けの AI 駆動の最適化とスケーリング など、Amazon Redshift が提供する 自動テーブル最適化 をサポートしています。 フェデレーテッド RMS カタログ: 既存の Amazon Redshift データウェアハウスをレイクハウスにオンボード 既存の Amazon Redshift データウェアハウスでフェデレーテッドカタログを実装すると、データ移動を必要としないメタデータのみの統合が作成されます。このアプローチにより、既存のワークフローとの互換性を維持しながら、確立された Amazon Redshift への投資をモダンなオープンレイクハウスフレームワークに拡張できます。Amazon Redshift は階層的なデータ組織構造を使用しています: クラスターレベル : 名前空間から始まる データベースレベル : 複数のデータベースを含む スキーマレベル : データベース内のテーブルを整理する 既存の Amazon Redshift プロビジョンドまたはサーバーレスの名前空間を Data Catalog のフェデレーテッドカタログとして登録すると、この階層がレイクハウスのメタデータレイヤーに直接マッピングされます。AWS のレイクハウス実装は、基盤となるストレージメタデータを整理・マッピングする動的階層を使用して複数のカタログをサポートしています。 名前空間を登録すると、フェデレーテッドカタログは AWS リージョンとアカウント内のすべての Amazon Redshift データウェアハウスに自動的にマウントされます。登録プロセス中、Amazon Redshift はデータ共有に対応する外部データベースを内部的に作成します。エンドユーザーからはこの仕組みは完全に隠蔽されています。フェデレーテッドカタログを使用することで、データエコシステム全体にわたる即時の可視性とアクセシビリティを実現できます。 フェデレーテッドカタログの権限 は、同一アカウントとクロスアカウントアクセスの両方で Lake Formation によって管理できます。 フェデレーテッドカタログが特に効果を発揮するのは、 Amazon Athena 、 Amazon EMR 、オープンソース Spark などの外部 AWS エンジンから Amazon Redshift マネージドストレージにアクセスする場面です。Amazon Redshift は Amazon Redshift エンジンのみがネイティブに読み取れる独自仕様のブロックベースストレージを使用しているため、AWS はバックグラウンドでサービスマネージドの Amazon Redshift Serverless インスタンスを自動的にプロビジョニングします。このサービスマネージドインスタンスは、外部エンジンと Amazon Redshift マネージドストレージ間の変換レイヤーとして機能します。AWS は、登録されたフェデレーテッドカタログとサービスマネージドの Amazon Redshift Serverless インスタンス間に自動データ共有を確立し、安全で効率的なデータアクセスを実現します。AWS はデータ転送用のサービスマネージド Amazon S3 バケットもバックグラウンドで作成します。 Athena などの外部エンジンが Amazon Redshift フェデレーテッドカタログに対してクエリを送信すると、Lake Formation がリクエストサービスに一時的な認証情報を提供してクレデンシャルベンディングを処理します。クエリはサービスマネージドの Amazon Redshift Serverless を通じて実行され、自動的に確立されたデータ共有を通じてデータにアクセスし、結果を処理してサービスマネージドの Amazon S3 ステージングエリアにオフロードし、元のリクエストエンジンに結果を返します。 既存の Amazon Redshift ウェアハウスのフェデレーテッドカタログのコンピューティングコストを追跡するには、以下のタグを使用します。 aws:redshift-serverless:LakehouseManagedWorkgroup value: "True" 請求インサイトのために AWS 生成コスト配分タグを有効にするには、 有効化手順 に従ってください。 AWS Billing でリソースのコンピューティングコストも確認できます。 使用すべきケース: 既存の Amazon Redshift への投資: フェデレーテッドカタログは、既存の Amazon Redshift デプロイメントを持ち、移行なしで複数のサービス間でデータを活用したい組織向けに設計されています。 クロスサービスデータ共有: チームが既存の Amazon Redshift データウェアハウスのデータを異なるウェアハウス間で共有し、権限を一元管理できるように実装します。 エンタープライズ統合要件: 確立されたデータガバナンスとの統合が必要な組織に適しています。レイクハウス機能を追加しながら、現在のワークフローとの互換性を維持します。 インフラストラクチャの制御と料金: 予測可能なワークロードに対して既存のウェアハウスのコンピューティング容量を完全に制御できます。コンピューティング容量の最適化、オンデマンドとリザーブドキャパシティの料金の選択、パフォーマンスパラメータの微調整が可能です。一貫したワークロードに対してコストの予測可能性とパフォーマンス制御を提供します。 複数のカタログタイプを使用してレイクハウスアーキテクチャを実装する場合、パフォーマンスとコスト最適化の両方にとって適切なクエリエンジンの選択が重要です。本記事ではレイクハウスのストレージ基盤に焦点を当てていますが、Amazon Redshift データ操作を多用する重要なワークロードでは、可能な限り Amazon Redshift 内でクエリを実行するか、Spark を使用することを検討してください。複数の Amazon Redshift テーブルにまたがる複雑なジョインを外部エンジンで実行すると、エンジンが完全な述語のプッシュダウンをサポートしていない場合、コンピューティングコストが高くなる可能性があります。 その他のユースケース マルチウェアハウスアーキテクチャの構築 Amazon Redshift は データ共有 をサポートしており、ソースとターゲットの Amazon Redshift クラスター間でライブデータを共有できます。データ共有を使用すると、コピーの作成やデータの移動なしでライブデータを共有でき、ワークロード分離 (ハブアンドスポークアーキテクチャ) やクロスグループコラボレーション (データメッシュアーキテクチャ) などのユースケースが可能になります。レイクハウスアーキテクチャがない場合、ソースとターゲットの Amazon Redshift クラスター間に明示的なデータ共有を作成する必要があります。小規模なデプロイメントではデータ共有の管理は比較的簡単ですが、データメッシュアーキテクチャでは複雑になります。 レイクハウスアーキテクチャはこの課題に対応し、既存の Amazon Redshift ウェアハウスをフェデレーテッドカタログとして公開できます。フェデレーテッドカタログは、同一アカウントとリージョン内の他のコンシューマー Amazon Redshift ウェアハウスに外部データベースとして自動的にマウントされ、利用可能になります。データの単一コピーを維持しながら複数のデータウェアハウスからクエリでき、複数のデータ共有の作成と管理が不要になり、ワークロード分離でスケールできます。権限管理は Lake Formation を通じて一元化され、マルチウェアハウス環境全体のガバナンスが効率化されます。 パイプライン管理不要のペタバイト規模トランザクションデータの準リアルタイム分析: Zero-ETL 統合は、OLTP データソースから Amazon Redshift、汎用 S3 (セルフマネージド Iceberg)、または S3 Tables へトランザクションデータをシームレスにレプリケートします。ETL パイプラインの維持が不要になり、データアーキテクチャの可動部品と潜在的な障害ポイントが削減されます。ビジネスユーザーは、前回の ETL 実行からの古いデータではなく、新鮮な運用データをすぐに分析できます。 Amazon Redshift ウェアハウスにレプリケートできる OLTP データソースの一覧は「 Aurora zero-ETL integrations 」を参照してください。 既存の Amazon Redshift ウェアハウス、セルフマネージド Iceberg を使用した汎用 S3、S3 Tables にレプリケートできるその他のサポートされるデータソースについては「 Zero-ETL integrations 」を参照してください。 まとめ レイクハウスアーキテクチャは、データレイクとデータウェアハウスのどちらかを選ぶものではありません。両方のフレームワークが統合データアーキテクチャ内で共存し、異なる目的を果たす相互運用性のアプローチです。基本的なストレージパターンを理解し、効果的なカタログ戦略を実装し、ネイティブストレージ機能を活用することで、現在の分析ニーズと将来のイノベーションの両方をサポートする、スケーラブルで高パフォーマンスなデータアーキテクチャを構築できます。詳細は「 The lakehouse architecture of Amazon SageMaker 」を参照してください。 著者について Lakshmi Nair Lakshmi は、AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。業界横断で高度な分析システムの設計を専門としています。クラウドベースのデータプラットフォームの構築、リアルタイムストリーミング、ビッグデータ処理、堅牢なデータガバナンスの実現に注力しています。 Saman Irfan Saman は、ドイツのベルリンを拠点とする Amazon Web Services のシニアスペシャリストソリューションアーキテクトです。組織のデータアーキテクチャのモダナイゼーションとデータの潜在能力を最大限に引き出し、イノベーションとビジネス変革を推進することに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

本記事は 2026 年 1 月 26 日 に公開された「 Top 10 best practices for Amazon EMR Serverless 」を翻訳したものです。 Amazon EMR Serverless は Amazon EMR のデプロイオプションの 1 つで、 Apache Spark や Apache Hive などのオープンソースビッグデータ分析フレームワークを、クラスターやサーバーの設定・管理・スケーリングなしで実行できます。EMR Serverless は、データストレージ、ストリーミング、オーケストレーション、モニタリング、ガバナンスにわたる Amazon Web Services (AWS) サービスと統合し、サーバーレス分析ソリューションを実現します。 本記事では、EMR Serverless ワークロードのパフォーマンス、コスト、スケーラビリティを最適化するためのベストプラクティス 10 選を紹介します。EMR Serverless を使い始めたばかりの方も、既存の本番ワークロードを改善したい方も、効率的でコスト効率の高いデータ処理パイプラインの構築に役立つ内容です。以下の図は、EMR Serverless のエンドツーエンドアーキテクチャを示しており、分析パイプラインへの統合方法を表しています。 1. アプリケーションは一度定義して繰り返し使う EMR Serverless アプリケーション はクラスターテンプレートに相当し、ジョブ送信時にインスタンス化され、再作成せずに複数のジョブを処理できます。アプリケーションを再利用することで起動レイテンシーを削減し、運用管理を簡素化できます。 EMR on EC2 一時クラスターの一般的なワークフロー: EMR Serverless の一般的なワークフロー: アプリケーションは自己管理型のライフサイクルを備えており、必要なときに手動操作なしでリソースをプロビジョニングします。ジョブが送信されると自動的にキャパシティをプロビジョニングします。事前初期化キャパシティのないアプリケーションでは、ジョブ完了後すぐにリソースが解放されます。事前初期化キャパシティが設定されている場合、設定されたアイドルタイムアウト (デフォルト 15 分) を超えるとワーカーが停止します。このタイムアウトは、 CreateApplication または UpdateApplication API の AutoStopConfig でアプリケーションレベルで調整できます。たとえば、ジョブが 30 分ごとに実行される場合、アイドルタイムアウトを延長すると実行間の起動遅延を解消できます。 ほとんどのワークロードには、オンデマンドキャパシティが適しています。ジョブの要件に基づいてリソースを自動スケーリングし、アイドル時には課金されません。ETL ワークロード、バッチ処理ジョブ、最大限のジョブ回復力が必要なシナリオなど、一般的なユースケースに適したコスト効率の高いアプローチです。 即時起動が厳密に求められるワークロードには、オプションで 事前初期化キャパシティ を設定できます。事前初期化キャパシティは、数秒以内にジョブを実行できるドライバーとエグゼキューターのウォームプールを作成します。ただし、パフォーマンスが向上する分、コストは高くなります。事前初期化ワーカーはアプリケーションが停止状態になるまでアイドル中も継続的に課金されます。また、事前初期化キャパシティはジョブを単一のアベイラビリティゾーンに制限するため、回復力が低下します。 事前初期化キャパシティを検討すべきケース: 起動レイテンシーが許容できない、サブ秒の SLA 要件がある時間的制約の厳しいジョブ ユーザー体験が即時応答に依存するインタラクティブ分析 数分ごとに実行される高頻度の本番パイプライン それ以外のほとんどのケースでは、オンデマンドキャパシティがコスト、パフォーマンス、回復力のバランスに優れています。 リソースの最適化に加えて、ワークロード全体でのアプリケーションの整理方法も検討してください。本番ワークロードでは、ビジネスドメインやデータの機密レベルごとに別々のアプリケーションを使用しましょう。アプリケーションを分離することでガバナンスが向上し、重要なジョブと重要でないジョブ間のリソース競合を防げます。 2. AWS Graviton プロセッサ で価格性能比を向上 適切なプロセッサアーキテクチャの選択は、パフォーマンスとコストの両方に大きく影響します。 Graviton ARM ベースプロセッサは、x86_64 と比較して優れた価格性能比を実現します。 EMR Serverless は最新のインスタンス世代が利用可能になると自動的に更新されるため、追加設定なしで最新のハードウェア改善の恩恵を受けられます。 EMR Serverless で Graviton を使用するには、 CreateApplication でアプリケーション作成時に architecture パラメータで ARM64 を指定するか、既存のアプリケーションには UpdateApplication API を使用します: aws emr-serverless create-application \   --name my-spark-app \   -- SPARK \   --architecture ARM64 \   --release-label emr-7.12.0 Graviton 使用時の考慮事項: リソースの可用性 – 大規模ワークロードの場合、Graviton ワーカーのキャパシティプランニングについて AWS アカウントチームに相談することを検討してください。 互換性 – 一般的に使用される標準ライブラリの多くは Graviton (arm64) アーキテクチャと互換性がありますが、使用しているサードパーティパッケージやライブラリの互換性を検証する必要があります。 移行計画 – Graviton の導入には戦略的なアプローチを取りましょう。新しいアプリケーションはデフォルトで ARM64 アーキテクチャで構築し、既存のワークロードは中断を最小限に抑える段階的な移行計画で 移行 します。段階的に移行することで、信頼性を損なわずにコストとパフォーマンスを最適化できます。 ベンチマークの実施 – 正確な価格性能比はワークロードによって異なります。ワークロード固有の結果を把握するために、独自のベンチマークを実施することを推奨します。詳細は「 Achieve up to 27% better price-performance for Spark workloads with AWS Graviton2 on Amazon EMR Serverless 」を参照してください。 3. デフォルトを活用し、必要に応じてワーカーを適正化 ワーカー はワークロードのタスクを実行するために使用されます。EMR Serverless のデフォルト設定はほとんどのユースケースに最適化されていますが、処理時間の改善やコスト効率の最適化のためにワーカーのサイズを適正化する必要がある場合があります。EMR Serverless ジョブを送信する際は、メモリサイズ (GB) やコア数などのワーカー設定を Spark プロパティで定義することを推奨します。 EMR Serverless のデフォルトワーカーサイズは 4 vCPU、16 GB メモリ、20 GB ディスクです。一般的にほとんどのジョブにバランスの取れた構成ですが、パフォーマンス要件に応じてサイズを調整することもできます。事前初期化ワーカーに特定のサイズを設定している場合でも、ジョブ送信時に必ず Spark プロパティを設定してください。事前初期化キャパシティを超えてスケールする際に、デフォルトプロパティではなく指定したワーカーサイズが使用されます。Spark ワークロードの適正化では、ジョブの vCPU:メモリ比率が重要です。エグゼキューターの仮想 CPU コアあたりに割り当てるメモリ量は、この比率で決まります。Spark エグゼキューターはデータを効果的に処理するために CPU とメモリの両方が必要で、最適な比率はワークロードの特性によって異なります。 まずは以下のガイダンスを参考にし、ワークロード固有の要件に基づいて設定を調整してください。 エグゼキューター設定 以下の表は、一般的なワークロードパターンに基づく推奨エグゼキューター設定です: ワークロードタイプ 比率 CPU メモリ 設定 コンピューティング集約型 1:2 16 vCPU 32 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=32G 汎用 1:4 16 vCPU 64 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=64G メモリ集約型 1:8 16 vCPU 108 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=108G ドライバー設定 以下の表は、一般的なワークロードパターンに基づく推奨ドライバー設定です: ワークロードタイプ 比率 CPU メモリ 設定 汎用 1:4 4 vCPU 16 GB spark.emr-serverless.driver.cores=4spark.emr-serverless.driver.memory=16G Apache Iceberg ワークロード 1:8 (メタデータルックアップ用の大きなドライバー) 8 vCPU 60 GB spark.emr-serverless.driver.cores=8spark.emr-serverless.driver.memory=60G 設定をさらにモニタリングおよびチューニングするには、 Amazon CloudWatch ジョブワーカーレベルメトリクス でワークロードのリソース消費を監視し、ボトルネックを特定します。CPU 使用率、メモリ使用量、ディスク使用率のメトリクスを追跡し、以下の表を参考に設定を調整してください。 観測されたメトリクス ワークロードタイプ 推奨アクション 1 高メモリ (>90%)、低 CPU (<50%) メモリバウンドワークロード vCPU:メモリ比率を増加 2 高 CPU (>85%)、低メモリ (<60%) CPU バウンドワークロード vCPU 数を増加し、1:4 比率を維持 (例: 8 vCPU 使用時は 32 GB メモリ) 3 高ストレージ I/O、通常の CPU/メモリ、長いシャッフル操作 シャッフル集約型 サーバーレスストレージ または シャッフル最適化ディスク を有効化 4 全メトリクスで低使用率 過剰プロビジョニング ワーカーサイズまたは数を削減 5 一貫して高使用率 (>90%) 過少プロビジョニング ワーカー仕様をスケールアップ 6 頻繁な GC 一時停止** メモリ圧迫 メモリオーバーヘッドを増加 (10〜15%) **頻繁なガベージコレクション (GC) の一時停止は、Spark UI の Executors タブで確認できます。GC time 列があり、一般的にタスク時間の 10% 未満であるべきです。また、ドライバーログに GC (Allocation Failure)] メッセージが頻繁に含まれている場合もあります。 4. T シャツサイジングでスケーリング境界を制御 デフォルトでは、EMR Serverless は 動的リソース割り当て (DRA) を使用し、ワークロードの需要に基づいてリソースを自動スケーリングします。EMR Serverless はジョブのメトリクスを継続的に評価してコストと速度を最適化するため、必要なワーカー数を見積もる必要がありません。 コスト最適化と予測可能なパフォーマンスのために、以下のいずれかのアプローチでスケーリングの上限を設定できます: ジョブレベルで spark.dynamicAllocation.maxExecutors パラメータを設定 アプリケーションレベルの最大キャパシティ を設定 各ジョブの spark.dynamicAllocation.maxExecutors を個別に細かく調整するのではなく、ワークロードプロファイルを表す T シャツサイズとして設定を考えることができます: ワークロードサイズ ユースケース spark.dynamicAllocation.maxExecutors Small 探索的クエリ、開発 50 Medium 定期的な ETL ジョブ、レポート 200 Large 複雑な変換、大規模処理 500 この T シャツサイジングアプローチにより、キャパシティプランニングが簡素化され、個々のジョブを最適化するのではなく、ワークロードカテゴリに基づいてパフォーマンスとコスト効率のバランスを取れます。 EMR Serverless リリース 6.10 以降では、 spark.dynamicAllocation.maxExecutors のデフォルト値は無制限ですが、それ以前のリリースでは 100 です。 EMR Serverless はジョブの各ステージで必要なワークロードと並列性に基づいて、ワーカーを自動的にスケールアップまたはスケールダウンします。ジョブのメトリクスを継続的に評価してコストと速度を最適化するため、ワーカー数を見積もる必要がありません。 ただし、予測可能なワークロードの場合、エグゼキューター数を静的に設定したい場合があります。その場合は DRA を無効にしてエグゼキューター数を手動で指定します: spark.dynamicAllocation.enabled=false spark.executor.instances=10 5. EMR Serverless ジョブに適切なストレージをプロビジョニング ストレージオプションを理解し、適切にサイジングすることで、ジョブの失敗を防ぎ、実行時間を最適化できます。EMR Serverless は、ジョブ実行中の中間データを処理するストレージオプションが複数あります。選択するストレージオプションは EMR リリースとユースケースによって異なります。EMR Serverless で利用可能なストレージオプションは以下のとおりです: ストレージタイプ EMR リリース ディスクサイズ範囲 ユースケース メリット サーバーレスストレージ (推奨) 7.12+ N/A (自動スケーリング) ほとんどの Spark ワークロード、特にデータ集約型ワークロード ストレージコストなし 自動スケーリング ディスク障害の削減 最大 20% のコスト削減 標準ディスク 7.11 以前 ワーカーあたり 20〜200 GB 10 TB 未満のデータセットを処理する小〜中規模ワークロード シンプルな設定 デフォルト 20 GB でほとんどのワークロードに対応 最適なスループットには最大 200 GB シャッフル最適化ディスク 7.1.0+ ワーカーあたり 20〜2,000 GB マルチ TB を処理する大規模 ETL ワークロード 高 IOPS とスループット ワーカーあたり最大 2 TB のキャパシティ ストレージ設定をワークロードの特性に合わせることで、EMR Serverless ジョブを大規模でも効率的かつ安定的に実行できます。 6. マルチ AZ がデフォルトで組み込みの回復力を提供 EMR Serverless アプリケーションは、事前初期化キャパシティが有効でない場合、最初からマルチ AZ です。フェイルオーバーが組み込まれているため、手動操作なしで AZ 障害に対応できます。単一のジョブは単一のアベイラビリティゾーン内で動作し、クロス AZ データ転送コストを防ぎます。後続のジョブは複数の AZ に適切に分散されます。EMR Serverless が AZ の障害を検出すると、新しいジョブを正常な AZ に送信し、AZ 障害にもかかわらずワークロードの実行を継続できます。 EMR Serverless のマルチ AZ 機能を最大限に活用するには、以下を確認してください: 複数のアベイラビリティゾーンにまたがるサブネットを選択して VPC へのネットワーク接続 を設定 アプリケーションを単一の AZ に制限する事前初期化キャパシティを避ける ワーカーのスケーリングをサポートするために各サブネットに十分な IP アドレスがあることを確認 マルチ AZ に加えて、Amazon EMR 7.1 以降では ジョブの回復力 を有効にでき、エラーが発生した場合にジョブを自動的にリトライできます。複数のアベイラビリティゾーンが設定されている場合、別の AZ でもリトライされます。この機能は バッチ ジョブと ストリーミング ジョブの両方で有効にできますが、リトライ動作は両者で異なります。 最大リトライ回数を定義するリトライポリシーを指定してジョブの回復力を設定します。バッチジョブのデフォルトは自動リトライなし (maxAttempts=1) です。ストリーミングジョブでは、EMR Serverless は無制限にリトライし、1 時間以内に 5 回失敗するとリトライを停止するスラッシング防止機能が組み込まれています。このしきい値は 1〜10 回の間で設定できます。詳細は「 Job resiliency 」を参照してください。 ジョブをキャンセルする必要がある場合、デフォルトの即時終了ではなく、ジョブをクリーンにシャットダウンするための 猶予期間 を指定できます。カスタムクリーンアップアクションを実行する必要がある場合は、カスタムシャットダウンフックも含められます。 マルチ AZ サポート、自動ジョブリトライ、グレースフルシャットダウン期間を組み合わせることで、中断に耐え、手動操作なしでデータの整合性を維持できる EMR Serverless ワークロードを構築できます。 7. VPC 統合でセキュリティと接続性を拡張 デフォルトでは、EMR Serverless は Amazon Simple Storage Service (Amazon S3)、 AWS Glue 、 Amazon CloudWatch Logs 、 AWS Key Management Service (AWS KMS)、 AWS Security Token Service (AWS STS)、 Amazon DynamoDB 、 AWS Secrets Manager などの AWS サービスにアクセスできます。 Amazon Redshift や Amazon Relational Database Service (Amazon RDS) など VPC 内のデータストアに接続するには、EMR Serverless アプリケーションの VPC アクセスを設定する必要があります。 EMR Serverless アプリケーションの VPC アクセスを設定する際は、最適なパフォーマンスとコスト効率のために以下の考慮事項に留意してください: 十分な IP アドレスを計画 – 各ワーカーはサブネット内で 1 つの IP アドレスを使用します。ジョブのスケールアウト時に起動されるワーカーも含まれます。IP アドレスが不足すると、ジョブがスケールできず、ジョブの失敗につながる可能性があります。最適なパフォーマンスのために サブネットプランニングのベストプラクティス に従っていることを確認してください。 プライベートサブネットのアプリケーションには Amazon S3 用ゲートウェイエンドポイント を設定 – VPC エンドポイントなしでプライベートサブネットで EMR Serverless を実行すると、Amazon S3 トラフィックが NAT ゲートウェイ経由でルーティングされ、追加のデータ転送料金が発生します。S3 用 VPC エンドポイントにより、トラフィックを VPC 内に保持し、コストを削減して Amazon S3 操作のパフォーマンスを向上できます。 ネットワークインターフェースの AWS Config コストを管理 – EMR Serverless は各ワーカーに対して AWS Config にエラスティックネットワークインターフェースレコードを生成し、ワークロードのスケールに伴いコストが蓄積される可能性があります。EMR Serverless ネットワークインターフェースの AWS Config 追跡が不要な場合は、リソースベースの除外やタグ付け戦略を使用してフィルタリングし、他のリソースの AWS Config カバレッジは維持することを検討してください。 詳細は「 Configuring VPC access for EMR Serverless applications 」を参照してください。 8. ジョブ送信と依存関係管理を簡素化 EMR Serverless は StartJobRun API による柔軟なジョブ送信をサポートしており、完全な spark-submit 構文を受け付けます。ランタイム環境の設定には、 spark.emr-serverless.driverEnv と spark.executorEnv プレフィックスを使用して、ドライバーとエグゼキュータープロセスの環境変数を設定します。機密設定やランタイム固有の設定を渡す際に特に便利です。 Python アプリケーションの場合、venv を作成し、tar.gz アーカイブとしてパッケージ化するか、 spark.archives を使用して Amazon S3 にアップロードし、適切な PYSPARK_PYTHON 環境変数を設定して、仮想環境で依存関係をパッケージ化すると、ドライバーとエグゼキューターワーカー全体で Python の依存関係を利用できます。 高負荷時の制御を向上させるには、 ジョブの同時実行とキューイング (EMR 7.0.0+ で利用可能) を有効にして、同時に実行できるジョブ数を制限します。この機能により、同時実行制限を超えて送信されたジョブは、リソースが利用可能になるまでキューに入れられます。 ジョブの同時実行とキュー設定は、 CreateApplication または UpdateApplication API の SchedulerConfiguration プロパティで設定できます。 --scheduler-configuration '{"maxConcurrentRuns": 5, "queueTimeoutMinutes": 30}' 9. EMR Serverless の設定で制限を適用 EMR Serverless はワークロードの需要に基づいてリソースを自動スケーリングし、ほとんどのユースケースで Spark 設定のチューニングなしで機能する最適化されたデフォルトが用意されています。コスト管理のために、予算とパフォーマンス要件に合ったリソース制限を設定できます。高度なユースケースでは、リソース消費を細かく調整し、クラスターベースのデプロイメントと同等の効率を実現する設定オプションも提供しています。制限を適切に設定することで、パフォーマンスとコスト効率のバランスを取れます。 制限タイプ 目的 設定方法 ジョブレベル 個々のジョブのリソースを制御 spark.dynamicAllocation.maxExecutors または spark.executor.instances アプリケーションレベル アプリケーションまたはビジネスドメインごとのリソースを制限 アプリケーション作成時または更新時に最大キャパシティを設定 アカウントレベル 全アプリケーションにわたる異常なリソーススパイクを防止 自動調整可能なサービスクォータ「 Max concurrent vCPUs per account 」。 Service Quotas コンソール から引き上げをリクエスト これら 3 つのレイヤーの制限が連携して、異なるスコープで柔軟にリソースを管理できます。ほとんどのユースケースでは、T シャツサイジングアプローチによるジョブレベルの制限設定で十分であり、アプリケーションレベルとアカウントレベルの制限はコスト管理の追加的なガードレールになります。 10. CloudWatch、Prometheus、Grafana でモニタリング EMR Serverless ワークロードのモニタリングにより、デバッグ、コスト最適化、パフォーマンス追跡が容易になります。EMR Serverless は連携する 3 つのモニタリング階層があります: Amazon CloudWatch、 Amazon Managed Service for Prometheus 、 Amazon Managed Grafana です。 Amazon CloudWatch – CloudWatch 統合 はデフォルトで有効になっており、AWS/EMRServerless 名前空間にメトリクスを発行します。EMR Serverless はアプリケーションレベル、ジョブ、ワーカータイプ、キャパシティ割り当てタイプレベルで毎分 CloudWatch にメトリクスを送信します。CloudWatch を使用して、ワークロードの可観測性を高める ダッシュボード を設定したり、ジョブの失敗、スケーリングの異常、SLA 違反に対する アラーム を設定できます。CloudWatch と EMR Serverless を使用することで、ユーザーに影響が出る前に問題を検知できます。 Amazon Managed Service for Prometheus – EMR Serverless リリース 7.1+ では、Prometheus を有効にして詳細な Spark エンジンメトリクス を Amazon Managed Service for Prometheus にプッシュでき、メモリ使用量、シャッフルボリューム、GC 圧力などエグゼキューターレベルで可視化できます。メモリ制約のあるエグゼキューターの特定、シャッフルが多いステージの検出、データスキューの発見に活用できます。 Amazon Managed Grafana – Grafana は CloudWatch と Prometheus の両方のデータソースに接続し、可観測性と相関分析を統合した単一画面として利用できます。3 つの階層を組み合わせることで、インフラストラクチャの問題とアプリケーションレベルのパフォーマンス問題を関連付けられます。 追跡すべき主要メトリクス: ジョブの完了時間と成功率 ワーカーの使用率とスケーリングイベント シャッフルの読み取り/書き込みボリューム メモリ使用パターン 詳細は「 Monitor Amazon EMR Serverless workers in near real time using Amazon CloudWatch 」を参照してください。 まとめ 本記事では、パフォーマンスの最適化、コスト管理、大規模での安定した運用を実現するための Amazon EMR Serverless のベストプラクティス 10 選を紹介しました。アプリケーション設計、ワークロードの適正化、アーキテクチャの選択に注力することで、効率的で回復力のあるデータ処理パイプラインを構築できます。 詳細は「 Getting started with EMR Serverless 」ガイドを参照してください。 著者について Karthik Prabhakar Karthik は、Amazon Web Services (AWS) の Amazon EMR データ処理エンジンアーキテクトです。分散システムアーキテクチャとクエリ最適化を専門とし、大規模データ処理ワークロードにおける複雑なパフォーマンス課題の解決をお客様と共に取り組んでいます。エンジン内部、コスト最適化戦略、ペタバイト規模の分析を効率的に実行するためのアーキテクチャパターンに注力しています。 Neil Mukerje Neil は、Amazon Web Services のプリンシパルプロダクトマネージャーです。 Amber Runnels Amber は、Amazon Web Services (AWS) のシニアアナリティクススペシャリストソリューションアーキテクトで、ビッグデータと分散システムを専門としています。AWS のデータサービスでワークロードを最適化し、スケーラブルで高パフォーマンス、コスト効率の高いアーキテクチャの実現をお客様に支援しています。 Parul Saxena Parul は、Amazon Web Services (AWS) のシニアビッグデータスペシャリストソリューションアーキテクトです。高度に最適化されたスケーラブルでセキュアなソリューションの構築をお客様やパートナーに支援しています。Amazon EMR、Amazon Athena、AWS Lake Formation を専門とし、複雑なビッグデータワークロードのアーキテクチャガイダンスや、組織のアーキテクチャモダナイゼーションと分析ワークロードの AWS への移行を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。