8 月 5 日、 Amazon Elastic VMware Service (Amazon EVS) の一般提供開始の開始を発表します。これは、 VMware Cloud Foundation (VCF) 環境を Amazon Virtual Private Cloud (Amazon VPC) 内で直接実行できるようにする新しい AWS サービスです。Amazon EVS を利用すると、ガイド付きワークフローを使用して、わずか数時間で完全に機能する VCF 環境をデプロイできます。また、認定された Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスで VMware ワークロードを実行し、 Amazon FSx for NetApp ONTAP などの AWS サービスとシームレスに統合できます。 オンプレミスで VMware ワークロードを実行している多くの組織は、改善されたスケーラビリティ、信頼性、クラウドサービスへのアクセスから恩恵を享受するためにクラウドへの移行を望んでいますが、これらのワークロードの移行には、アプリケーションとインフラストラクチャの設定の大幅な変更が必要になることがよくあります。Amazon EVS を利用すると、お客様は、アプリケーションを再設計したり、確立されたプラクティスを変更したりすることなく、既存の VMware の専門知識とツールを引き続き使用できます。そのため、移行プロセスが簡素化されると同時に、AWS の規模、信頼性、幅広いサービスへのアクセスも提供されます。 Amazon EVS を利用すると、Amazon VPC で VMware ワークロードを直接実行できます。これにより、AWS インフラストラクチャ上にいながら、環境を完全に制御できます。オンプレミスネットワークを拡張し、IP アドレスや運用ランブックを変更することなくワークロードを移行できるため、複雑さとリスクが軽減されます。 主な機能と特徴量 Amazon EVS は、VMware ワークロードの移行と管理のエクスペリエンスを効率化するために設計された包括的な一連の機能を提供します。このサービスは、リプラットフォームやハイパーバイザーの変更を必要とせずにワークロードのシームレスな移行を可能にするため、AWS に移行しながら、既存のインフラストラクチャに対する投資を維持できます。 AWS マネジメントコンソール での直感的なガイド付きワークフローを通じて、EVS 環境を効率的にプロビジョニングおよび設定できるため、AWS へのワークロード移行の複雑さが大幅に軽減されます。 Amazon EVS を利用すると、AWS 上で実行される完全に機能する VCF 環境を数時間でデプロイできます。このプロセスにより、従来のデプロイ中に頻繁に発生する多くの手動ステップと潜在的な設定エラーが排除されます。さらに、Amazon EVS を利用すると、AWS 上の仮想化スタックを最適化できます。VCF 環境は VPC 内で実行されるため、環境と関連付けられた管理アプライアンスに対する完全なルートアクセスが付与されます。また、 Amazon FSx for NetApp ONTAP や Pure Cloud Block Store などの外部ストレージ、 Veeam Backup and Replication などのバックアップソリューションなど、サードパーティーソリューションを統合することも可能です。 このサービスでは、自己管理することも、AWS パートナーと連携して環境を構築、管理、運用することもできます。これにより、全体的な目標に合わせてアプローチを柔軟に調整できます。 新しい VCF 環境のセットアップ 組織は、新しい VCF 環境を作成する前に必要なすべての前提条件が確実に満たされているようにすることで、セットアッププロセスを合理化できます。これらの前提条件には、アクティブな AWS アカウントがあること、適切な AWS Identity and Access Management (IAM) 許可が設定されていること、十分な CIDR スペースと 2 つの Route Server エンドポイント (各エンドポイントに独自のピアがある必要があります) を備えた Amazon VPC がセットアップされていることが含まれます。さらに、お客様は、VMware Cloud Foundation ライセンスキーを用意し、i4i.metal インスタンス専用の Amazon EC2 キャパシティ予約を確保するとともに、VLAN サブネット情報の計画を準備する必要があります。 円滑なデプロイプロセスを実現するのに役立つよう、EVS ホームページからアクセスできる 開始方法ハブ を提供しているほか、 ドキュメント では包括的なガイドをご覧いただけます。これらの準備ステップに従うことで、セットアップの遅延を回避し、環境を正常に構築できます。 Amazon EVS を利用して新しい VCF 環境をセットアップするプロセスを順に見ていきましょう。 VCF ライセンスを購入する際に Broadcom によって割り当てられたサイト ID と、ライセンスキーを提供する必要があります。初期デプロイを成功させるには、少なくとも 256 コアをカバーするのに十分なライセンスを有していることを確認する必要があります。これは、少なくとも 4 つの i4i.metal インスタンス (各インスタンスは 64 個の物理コアを提供します) を意味します。 このライセンス要件は、最適なパフォーマンスを維持し、必要なインフラストラクチャ仕様を環境が満たしているようにするのに役立ちます。これらの要件を事前に確認することで、デプロイの遅延を回避し、円滑なセットアッププロセスを実現できます。 必要な詳細をすべて入力すると、ホストの詳細を指定するように求められます。これらは、VCF 環境がデプロイされる基盤となる Amazon EC2 インスタンスです。 各ホストインスタンスの詳細を入力したら、ネットワーキングと管理アプライアンスの DNS の詳細を設定する必要があります。Amazon EVS で新しい VCF 環境を作成する方法の詳細については、 こちらのドキュメント をご覧ください。 VCF 環境を作成すると、AWS コンソールを通じてすべてのホストと設定の詳細を確認できます。 知っておくべき追加情報 Amazon EVS は現在、VCF バージョン 5.2.1 をサポートしており、i4i.metal インスタンスで実行されます。今後のリリースでは、デプロイのためにより高い柔軟性が提供されるよう、VCF バージョン、ライセンスオプション、およびインスタンスタイプのサポートが拡張される予定です。 Amazon EVS は柔軟なストレージオプションを提供します。Amazon EVS のローカルインスタンスストレージは、VMware の vSAN ソリューションを利用しており、複数の ESXi ホストにまたがるローカルディスクを単一の分散データストアにプールします。ストレージをスケールするために、外部の Network File System (NFS) または iSCSI ベースのストレージソリューションを活用できます。例えば、Amazon FSx for NetApp ONTAP は、NFS データストアまたは iSCSI 経由の共有ブロックストレージとして使用するのに特によく適しています。 さらに、Amazon EVS を利用すると、オンプレミス環境を AWS に簡単に接続できます。Direct Connect 接続またはトランジットゲートウェイを終端とする VPN を使用して、オンプレミスの vSphere 環境から Amazon EVS に接続できます。また、Amazon EVS は、VLAN サブネットから VM への基盤となる接続を管理します。 AWS は、Amazon EVS によってデプロイされるすべての AWS サービスについて包括的なサポートを提供し、直接的なカスタマーサポートを提供するとともに、高度なサポートニーズについては Broadcom と連携します。お客様は、サービスを実行しているアカウントで AWS ビジネスサポート を維持する必要があります。 利用可能なリージョンと料金 Amazon EVS は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (アイルランド)、アジアパシフィック (東京) の AWS リージョン で一般提供されています。近日中に他のリージョンでもご利用いただけるようになる予定です。料金は、使用した Amazon EC2 インスタンスと AWS リソースに基づいて算出され、最低料金や初期費用はありません。 詳細については、 Amazon EVS の製品ページ にアクセスしてください。 原文は こちら です。

このブログは 2025 年 7 月 15 日に Channy Yun によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 本日、 Amazon S3 Vectors のプレビュー版を発表します。これは、ベクトルのアップロード、保存、クエリの総コストを最大 90 % 削減できる、耐久性に優れたベクトルストレージソリューションです。Amazon S3 Vectors は、大規模なベクトルデータセットの保存をネイティブにサポートし、1 秒未満のクエリパフォーマンスを実現する初めてのクラウドオブジェクトストアです。これにより、企業が AI 対応データを大規模に低コストで保存できるようになります。 ベクトル検索は、 生成 AI アプリケーションで使用されている新しい手法で、距離または類似度メトリックを使用してベクトル表現を比較することにより、特定のデータに類似したデータポイントを検索します。ベクトルは 埋め込みモデル から作成された非構造化データを数値で表現したものです。ドキュメント内のフィールドの埋め込みモデルを使用してベクトルを生成し、ベクトルを S3 Vectors に保存してセマンティック検索を行います。 S3 Vectors では、ベクトルバケットが導入されました。ベクトルバケットは、インフラストラクチャをプロビジョニングせずにベクトルデータを保存、アクセス、クエリするための専用の API セットを備えた新しいバケットタイプです。S3 ベクトルバケットを作成すると、ベクトルデータをベクトルインデックス内に整理し、データセットに対して類似検索クエリを簡単に実行できるようにします。各ベクトルバケットには最大 10,000 個のベクトルインデックスを含めることができ、各ベクトルインデックスには数千万個のベクトルを格納できます。 ベクトルインデックスを作成した後、ベクトルデータをインデックスに追加するときに、メタデータをキーと値のペアとして各ベクトルに添付して、日付、カテゴリ、ユーザー設定などの一連の条件に基づいて今後のクエリをフィルタリングすることもできます。時間の経過とともにベクトルの書き込み、更新、削除を行うと、S3 Vectors は、データセットが拡大したり進化したりしても、ベクトルストレージのコストパフォーマンスが可能な限りベストになるように、ベクトルデータを自動的に最適化します。 S3 Vectorsは、 Amazon SageMaker Unified Studio を含む Amazon Bedrock Knowledge Bases ともネイティブに統合されており、費用対効果の高い Retrieval-Augmented Generation (RAG) アプリケーションを構築できます。 Amazon OpenSearch Service との統合により、クエリ頻度の低いベクトルを S3 Vectors に保存することでストレージコストを削減でき、需要が高まったときにそれらを OpenSearch にすばやく移動したり、リアルタイムで低レイテンシーの検索操作をサポートすることができます。 S3 Vectors を使用すると、画像、動画、ドキュメント、音声ファイルなどの大量の非構造化データを表すベクトル埋め込みを経済的に保存できるようになり、セマンティック検索、類似検索、RAG、ビルドエージェントメモリなどのスケーラブルな生成 AI アプリケーションが可能になります。また、ベクトルデータベースの管理に伴う複雑さやコストをかけずに、パーソナライズされた推奨事項、自動コンテンツ分析、インテリジェントな文書処理など、さまざまな業界のユースケースをサポートするアプリケーションを構築できます。 S3 Vectors の動作 ベクトルバケットを作成するには、 Amazon S3 コンソール の左側のナビゲーションペインで Vector buckets を選択し、 Create vector bucket を選択します。 ベクトルバケット名を入力し、暗号化タイプを選択します。暗号化タイプを指定しない場合、Amazon S3 は新しいベクトルの暗号化の基本レベルとして Amazon S3 管理キー (SSE-S3) を使用してサーバー側の暗号化を適用します。 AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用してサーバー側の暗号化を選択することもできます。ベクトルバケットの管理の詳細については、Amazon S3 ユーザーガイドの S3 ベクトルバケット をご覧ください。 これで、ベクトルインデックスを作成して、作成したベクトルバケット内でベクトルデータを保存およびクエリできます。 ベクトルインデックス名と、インデックスに挿入するベクトルの次元を入力します。このインデックスに追加されるすべてのベクトルは、完全に同じ数の値を持つ必要があります。 Distance metric では、 Cosine または Euclidean を選択できます。ベクトル埋め込みを作成する場合、より正確な結果を得るには、埋め込みモデルの推奨された距離メトリックを選択してください。 Create vector index を選択すると、ベクトルの挿入、一覧表示、クエリを行うことができます。 ベクトル埋め込みをベクトルインデックスに挿入するには、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDKs 、または Amazon S3 REST API を使用できます。非構造化データ用のベクトル埋め込みを生成するには、Amazon Bedrock が提供する埋め込みモデルを使用できます。 最新の AWS Python SDK を使用している場合は、次のコード例を使用して Amazon Bedrock を使用してテキストのベクトル埋め込みを生成できます。 # Generate and print an embedding with Amazon Titan Text Embeddings V2. import boto3 import json # Create a Bedrock Runtime client in the AWS Region of your choice. bedrock = boto3 . client ( "bedrock-runtime" , region_name = "us-west-2" ) # The text strings to convert to embeddings . texts = [ "Star Wars: A farm boy joins rebels to fight an evil empire in space" , "Jurassic Park: Scientists create dinosaurs in a theme park that goes wrong" , "Finding Nemo: A father fish searches the ocean to find his lost son" ] embeddings = [ ] #Generate vector embeddings for the input texts for text in texts : body = json . dumps ( { "inputText" : text } ) # Call Bedrock's embedding API response = bedrock . invoke_model ( modelId = 'amazon.titan-embed-text-v2:0' , # Titan embedding model body = body ) # Parse response response_body = json . loads ( response [ 'body' ] . read ( ) ) embedding = response_body [ 'embedding' ] embeddings . append ( embedding ) Python これで、ベクトル埋め込みをベクトルインデックスに挿入し、クエリー埋め込みを使用してベクトルインデックスのベクトルをクエリできるようになりました。 # Create S3Vectors client s3vectors = boto3 . client ( 's3vectors' , region_name = 'us-west-2' ) # Insert vector embedding s3vectors . put_vectors ( vectorBucketName = "channy-vector-bucket" , indexName = "channy-vector-index" , vectors = [ { "key" : "v1" , "data" : { "float32" : embeddings [ 0 ] } , "metadata" : { "id" : "key1" , "source_text" : texts [ 0 ] , "genre" : "scifi" } } , { "key" : "v2" , "data" : { "float32" : embeddings [ 1 ] } , "metadata" : { "id" : "key2" , "source_text" : texts [ 1 ] , "genre" : "scifi" } } , { "key" : "v3" , "data" : { "float32" : embeddings [ 2 ] } , "metadata" : { "id" : "key3" , "source_text" : texts [ 2 ] , "genre" : "family" } } ] , ) #Create an embedding for your query input text # The text to convert to an embedding. input_text = "List the movies about adventures in space" # Create the JSON request for the model. request = json . dumps ( { "inputText" : input_text } ) # Invoke the model with the request and the model ID, e.g., Titan Text Embeddings V2. response = bedrock . invoke_model ( modelId = "amazon.titan-embed-text-v2:0" , body = request ) # Decode the model's native response body. model_response = json . loads ( response [ "body" ] . read ( ) ) # Extract and print the generated embedding and the input text token count. embedding = model_response [ "embedding" ] # Performa a similarity query. You can also optionally use a filter in your query query = s3vectors . query_vectors ( vectorBucketName = "channy-vector-bucket" , indexName = "channy-vector-index" , queryVector = { "float32" : embedding } , topK = 3 , filter = { "genre" : "scifi" } , returnDistance = True , returnMetadata = True ) results = query [ "vectors" ] print ( results ) Python ベクトルインデックスへのベクトルの挿入、ベクトルの一覧表示、クエリ、削除の詳細については、Amazon S3 ユーザーガイドの S3 ベクトルバケット と S3 ベクトルインデックス をご覧ください。さらに、S3 Vectors embed コマンドラインインターフェイス (CLI) を使用すると、Amazon Bedrock を使用してデータのベクトル埋め込みを作成し、1 つのコマンドで S3 ベクトルインデックスに保存してクエリすることができます。詳細については、 S3 Vectors Embed CLI GitHub リポジトリ を参照してください。 S3 Vectors を他の AWS サービスと統合 S3 Vectors は、Amazon Bedrock、Amazon SageMaker、Amazon OpenSearch Service などの他の AWS サービスと統合することで、ベクトル処理機能を強化し、AI ワークロード向けの包括的なソリューションを提供します。 S3 Vectors を使用して Amazon Bedrock ナレッジベースを作成 Amazon Bedrock ナレッジベースで S3 Vectors を使用すると、RAG アプリケーションのベクトルストレージのコストを簡素化および削減できます。 Amazon Bedrock コンソール でナレッジベースを作成する場合、ベクトルストアのオプションとして S3 ベクトルバケットを選択できます。 Step 3 では、 Vector store creation method を選択して S3 ベクトルバケットとベクトルインデックスを作成するか、以前に作成した既存の S3 ベクトルバケットとベクトルインデックスを選択できます。 詳細な手順については、Amazon Bedrock ユーザーガイドの Create a knowledge base by connecting to a data source in Amazon Bedrock Knowledge Bases を参照してください。 Amazon SageMaker Unified Studio を使用する Amazon Bedrock を使用して生成 AI アプリケーションを構築すると、Amazon SageMaker Unified Studio で S3 Vectors を使用してナレッジベースを作成および管理できます。SageMaker Unified Studio は次世代の Amazon SageMaker で利用でき、Amazon Bedrock ナレッジベースを使用する生成 AI アプリケーションの構築やテキスト送信など、データと AI の統合開発環境を提供します。 生成 AI アプリケーションを構築する時に、Amazon Bedrock で作成された S3 Vectors を使用してナレッジベースを選択できます。詳細については、Amazon SageMaker Unified Studio ユーザーガイドの Add a data source to your Amazon Bedrock app をご覧ください。 S3 ベクトルデータを Amazon OpenSearch サービスにエクスポートする 長期的に利用するベクトルデータを Amazon S3 にコスト効率よく保存する一方で、優先度高く利用したいベクトルを OpenSearch にエクスポートしてリアルタイムのクエリパフォーマンスを実現する階層型戦略を採用することで、コストとパフォーマンスのバランスを取ることができます。 この柔軟性により、組織は OpenSearch の高パフォーマンス (高 QPS、低遅延) を利用して、製品の推奨や不正検出などの重要なリアルタイムアプリケーションにアクセスでき、時間的制約の少ないデータを S3 Vectors に保存できます。 ベクトルインデックスをエクスポートするには、 Advanced search export を選択し、次に Amazon S3 コンソールで Export to OpenSearch を選択します。 次に、OpenSearch ベクトルエンジンに S3 ベクトルインデックスをエクスポートするためのテンプレートを含む Amazon OpenSearch サービス統合コンソール が表示されます。事前に選択した S3 ベクトルソースとサービスアクセスロールを使用して エクスポート を選択します。 これで、新しい OpenSearch Serverless コレクションを作成し、S3 ベクトルインデックスから OpenSearch k-NN インデックスにデータを移行する手順が開始されます。 左側のナビゲーションペインで Import history を選択します。S3 ベクトルインデックスのベクトルデータを OpenSearch Serverless コレクションにコピーするために作成された新しいインポートジョブが表示されます。 ステータスが Complete に変わったら、 新しい OpenSearch Serverless コレクションに接続して 、 新しい OpenSearch knn インデックスをクエリできます 。 詳細については、Amazon OpenSearch サービス開発者ガイドの Creating and managing Amazon OpenSearch Serverless collections をご覧ください。 今すぐご利用いただけます Amazon S3 Vectors 、および Amazon Bedrock、Amazon OpenSearch Service、Amazon SageMaker との統合は、現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、ヨーロッパ (フランクフルト)、およびアジアパシフィック (シドニー) の各リージョンでプレビュー段階にあります。 今すぐ Amazon S3 コンソール で S3 Vectors を試してみて、 AWS re:Post for Amazon S3 か通常の AWS サポートの連絡先を通じてフィードバックを送ってください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの黒川が担当しました。

この記事は Resolve imperfect data with advanced rule-based fuzzy matching in AWS Entity Resolution (記事公開日 : 2025 年 7 月 30 日) を翻訳したものです。 様々な業界の企業は、顧客情報を正確に把握することで、パーソナライズされた顧客体験と最適化された広告キャンペーンの提供を目指しています。しかし、断片化され、一貫性がなく、しばしば乱雑なデータセット間でレコードを確実にマッチングすることは、困難で複雑な作業です。 従来のルールベースのマッチング技術を使用して完全一致のレコードを照合しようとする組織は、名前、メールアドレス、住所のわずかな違い (例 : Jon Smith と Jonathan Smith、または 123 Main St., Apt. 4B と 123 Main Street #4B) により、重要なつながりを見逃してしまうことがあります。このようなミスマッチは、キャンペーンのパフォーマンス低下、オーディエンスリーチの制限、広告費の無駄遣いにつながる可能性があります。 これらの課題に対応するために、企業は AWS Entity Resolution を使用して、複数のアプリケーション、チャネル、データストアにまたがる関連レコードのマッチング、リンク、情報の付加を行っています。これにより、顧客をより良く理解し、エンゲージメントを高めるためのデータ品質が向上します。AWS Entity Resolution は、ルールベースのマッチングと機械学習 (ML) ベースのマッチングを含む、複数の柔軟で設定可能なマッチング技術を提供します。 ルールベースのマッチング は、複数のフィールドにわたる厳密な条件を使用して、決定論的なロジックを定義します。例えば、メールアドレスと姓でマッチングを行うようなルールを設定することができます。この手法は高い精度と完全な透明性を提供し、事前に定義されたルールによる説明可能性が重要なユースケースで特に好まれます。 機械学習ベースのマッチング は、事前に学習させたモデルを活用し、データ内のパターンを自動的に学習して、データにノイズがある場合や一貫性がない場合、あるいは主要な識別子が不足している場合でも、適切なマッチングを特定することができます。この手法は設定の手間を軽減し、様々なタイプのデータに適応できる特徴があり、決定論的なルールでは見落としてしまう可能性のあるケースでも、より高い検出率を実現します。 本日、AWS Entity Resolution で高度なルールベースファジーマッチング機能を 発表しました 。これにより、Levenshtein Distance (レーベンシュタイン距離)、Cosine Similarity (コサイン類似度)、Soundex (サウンデックス) などのファジーマッチングアルゴリズムを使用してレコードをマッチングできるようになります。 この機能は、表記の揺れや入力ミスに対する許容性を持たせることで、特別な前処理を必要とせずに、より正確で柔軟な本人確認を可能にします。マーケターにとってこれは、マッチング率の向上、パーソナライゼーションの強化、そして効果的なクロスチャネルでのターゲティングやリターゲティング、効果測定のために必要な統合的な顧客視点の構築を実現できることを意味します。 業界のユースケース 高度なルールベースファジーマッチングは、様々な業界のお客様が直面する複雑なデータ統合の課題解決に役立ちます。具体的には以下のような例があります : 広告・マーケティング分野 : 識別子が不完全であったり、わずかなズレがある場合でも、異なるデータセット間でレコードをマッチングすることで、リーチや頻度分析の精度を向上させることができます。 小売・消費財分野 : 顧客関係管理 (CRM) データ内の誤字や異なる表記を含むレコードを紐付けることができます。 金融サービス分野 : 本人確認 (KYC) の検証、不正検知、またはマーケティング目的のために、本人確認データの解決を行うことができます。 高度なルールベースファジーマッチングの概要 AWS Entity Resolution の高度なルールベースファジーマッチングは、ルールベースと機械学習ベースのアプローチの間のギャップを埋めるものです。従来の厳密なルールベースの枠組みに確率的なマッチングを導入し、ユーザーがファジーマッチングアルゴリズム (レーベンシュタイン距離やコサイン類似度など) を使用して文字列フィールドの類似度のしきい値を設定できるようにします。これにより、ルールの説明可能性とコントロール性を保ちながら、確率的マッチングの柔軟性を実現する中間的なアプローチを提供します。 AWS Entity Resolution では、以下のファジーマッチングアルゴリズムを利用できます : レーベンシュタイン距離 : タイプミスや文字の小さな編集を検出し、名前やメールアドレス、スペルミスのあるエントリーをマッチングします (例 : john@gmail.co と jon@gmail.com の比較) 。 サウンデックス : 音声的な類似性を評価し、似た発音だが異なるスペルの名前をマッチングします (例 : Mary と Marie の比較) 。 コサイン類似度 : 単語やトークンの重なりに基づいて類似性を測定します。これは会社名や、語順が異なる、または部分的に一致するフリーテキストフィールドのマッチングに使用されます (例 : Acme Inc. と Acme Corporation の比較) 。 お客様は、ノイズを含むデータや一貫性のないデータ間でより柔軟で正確なマッチングを可能にするために、アルゴリズムを使用してカスタムの類似度のしきい値を定義できるようになりました。これは、ルールベースシステムのコントロール性と、機械学習ベースの近似マッチングの適応性を組み合わせたもので、説明可能性を損なうことなくマッチング率を向上させることができます。 お客様は、関連するファジーマッチングアルゴリズムでルール条件を設定し、必要に応じて適切なしきい値を設定することができます (図 1 参照) 。 図 1 : 高度なマッチングアルゴリズム 仕組み AWS Entity Resolution の新機能をソリューションで使用するには、まず、複数のアプリケーション、チャネル、データストアにまたがるレコードがデータレイク (Amazon Simple Storage Service ( Amazon S3 ) バケット) で利用可能な状態になっていることを確認します。 AWS Glue crawler を使用して Amazon S3 のデータの内容を自動的に判別し、 AWS Glue Data Catalog 内のメタデータテーブルを更新します。 AWS Entity Resolution は、サービス内で定義したルールを使用して、データセットを適切なマッチンググループに解決します。AWS Entity Resolution からの出力は Amazon S3 バケットで利用可能です。図 2 は、このソリューションを示すハイレベルのアーキテクチャ図です。 図 2 : ハイレベルアーキテクチャ 使用例の説明 AWS Entity Resolution のファジーマッチングルールを説明するために、テストデータセットを作成しました。このデータセットは架空の顧客情報で構成されており、CSV ファイル形式で Amazon S3 バケットにアップロードされています。 図 3 : サンプルデータセット 図 3 のデータセットには 4 つの個別のエンティティが含まれています。ただし、これらの個別エンティティには、名前、住所、電話番号フィールドが変更された複数のバリエーションも含まれています。 サンプルデータの問題を解決するために、以下の手順を実行しました : AWS Entity Resolution でサンプルデータのスキーマを解決するには、まず AWS Glue crawler を使用して AWS Glue Data Catalog テーブルを作成する必要があります。このテーブルは、入力されるクリックストリームデータを保持する Amazon S3 バケットを指します。 AWS Entity Resolution 内で スキーママッピング を定義し、サービスにデータの解釈方法を指示する必要があります。 スキーママッピング作成画面で、ソースデータを表す適切な AWS Glue データベースとテーブル を選択します。この例では、”fuzzymatchingaerdemo” を含むデータベース “fuzzymatchingdemo” を使用します。このデータベースのテーブルは、サンプルデータセットを含む Amazon S3 バケットで AWS Glue crawler を実行した際に作成されました。 図 4 : スキーママッピング – セットアップ ドロップダウンから一意の ID ( Unique ID ) を選択します (図 5 参照) 。一意の ID カラムは、データの各行を個別に参照する必要があります。これはデータベースの主キーカラムのようなものと考えてください。この場合、CSV ファイル内の uniqueid がそれに該当します。 下にスクロールし、解決に必要な 入力フィールド を選択します (図 5 参照) 。この場合、address (住所) 、first_name (名) 、last_name (姓) 、phone の各カラムが選択されています。 図 5 : スキーママッピング – 入力データフィールド セットアップ 次に、選択した入力フィールドを適切なデータタイプとマッチキーにマッピングします。入力タイプ (名前、メール、住所など) を指定することで、AWS Entity Resolution に各カラムのデータの解釈方法を指示し、必要に応じてそのカラムに適用する正規化ルールを設定できます。 マッチキー は、どのフィールドが類似しているか、そしてマッチング処理中に単一のユニットとして扱う必要があるかを決定します。 図 6 : スキーママッピング – フィールドのマッピング 「 次へ 」をクリックしてグループの作成に進みます。グループとは、単一の「名前」カラムの下にある関連する入力フィールド (名と姓など) のセットです。これにより、AWS Entity Resolution はマッチングや類似度の計算時に、個別ではなくまとめて比較することができ、より正確なマッチングが可能になります。 図 7 : スキーママッピング – グループフィールド グループの設定が完了したら、「 次へ 」をクリックして確認と作成画面に進みます。 すべての設定を確認し、「 スキーママッピングの作成 」をクリックします。これによりスキーママッピングが作成されます。 スキーママッピングが作成されたら、次はマッチングワークフローを作成します。マッチングワークフローは、ソース間でレコードをマッチングおよびリンクするために必要な入力、関連するマッチング手法、ルール、または機械学習を定義するのに役立ちます。マッチングワークフローを作成するには、左側のメニューにあるワークフローのドロップダウンから「 マッチング 」を選択し、「 マッチングワークフローの作成 」をクリックします。マッチングワークフローの詳細指定画面でワークフロー名を追加します。この例では「Fuzzymatchingdemo」としています。データ入力エリアで、前のステップで作成した適切な AWS Glue データベーステーブルとスキーママッピングを選択する必要があります (図 8 参照) 。 図 8 : マッチングワークフロー マッチング手法では、「 ルールベースマッチング 」を選択し、ファジーマッチングアルゴリズムを使用するためにルールタイプとして「 Advanced-new 」を選択します。 図 9 : マッチング手法 マッチングルールセクションでは、マッチングの目的に合わせて、ドロップダウンリストからマッチングアルゴリズムと適切なしきい値を選択し、ルールと条件を定義できます (図 10 参照) 。高度なマッチングルールビルダーでは、特定のフィールドに複数のマッチングアルゴリズムを適用することができます。「OR」条件を使用して2つの異なるアルゴリズムを組み合わせることで、マッチング解決の精度を最大化することができます。例えば、「名前」属性に対してサウンデックスとコサインの両方のアルゴリズムを適用することで、異なる種類の表記のバリエーションを捉えることができます。図 11 は、サンプルデータセットの重複を効果的に排除するために使用したルールを示しています。 図 10 : ファジーマッチング手法 セットアップ 図 11 : ファジーマッチングルール 最後のステップとして、ワークフローを作成する前に、すべての設定がマッチングの要件を正確に反映しているか確認し、「 作成して実行 」をクリックします。これによりマッチングワークフローが作成され、最初の処理が開始されます。 ジョブの完了までしばらく待つと (図 12 参照) 、ジョブメトリクスに処理された入力レコードの数と生成された一意のマッチ ID の数が表示されます。出力結果は設定された Amazon S3 バケットに書き込まれます。指定された出力用 S3 の場所に移動して出力ファイルをダウンロードし、結果を分析することができます。 図 12 : ファジーマッチングのジョブメトリクス 出力データ (図 13 参照) では、出力データの各レコードに AWS Entity Resolution が割り当てた MatchID が付与されます。マッチングレコードは、MatchRule で定義された条件を満たすデータセットから重複が排除されたエントリーを表します。MatchRule フィールドは、各マッチングレコードセットの生成に適用された具体的なルールを示しています。 図 13 : ファジーマッチングワークフローの出力 このチュートリアルで示したサンプルデータセットでは、AWS Entity Resolution のファジーマッチングワークフローは、関連するレコードをグループ化する 4 つの一意のマッチキーを生成しました。マッチングワークフローは、名前、住所、電話番号フィールドにバリエーションを含むレコードの重複を正常に排除し、4 つの個別のエンティティとして解決しました。 まとめ AWS Entity Resolution の高度なルールベースファジーマッチングは、カスタムコードを書くことなく、ファジーロジックを使用して現実世界の不完全なデータをマッチングするための柔軟性を提供します。広告、小売、金融、医療など、どの分野で働いているかに関わらず、この機能はデータに隠された関係性を見つけ出すのに役立ちます。お客様は、マッチングのためのファジーロジックに対して適切なしきい値を管理および設定することができます。 これは、ルールベースシステムのコントロール性と、機械学習ベースの近似マッチングの適応性を組み合わせたバランスの取れたマッチングアプローチです。説明可能性を損なうことなく、マッチング率を向上させることができます。 開始するには、 AWS Entity Resolution コンソール にアクセスし、高度なルールベースファジーマッチングを有効にして、今すぐインテリジェントなワークフローの構築を始めるか、 AWS の担当者 に連絡して、ビジネスの加速化に向けた支援方法についてご相談ください。 追加リソース AWS Entity Resolution Resources AWS Entity Resolution と Amazon Neptune を使用して顧客の 360 度ビューを作成 AWS Entity Resolution: Match and Link Related Records from Multiple Applications and Data Stores AWS Entity Resolution Workshops 顧客の統一ビューを構築する方法 Sid Patel Sid は、AWS 応用 AI (Applied AI) ソリューション内の顧客データ・インサイトチームのプロダクトリードです。AWS Entity Resolution や Amazon Connect Customer Profiles などのサービスを通じて、顧客アイデンティティとデータ統合に注力しています。 Archna Kulkarni Archna は、金融サービスとデータ変換技術を専門とする AWS のシニアソリューションアーキテクトです。AWS に入社する前は、フォーチュン 100 の金融サービス組織でデジタルトランスフォーメーションのエグゼクティブとして働いていました。Archna は AWS Entity Resolution、AWS Clean Rooms、Amazon Connect Customer Profiles などの AWS サービスを活用して、お客様のデータ統合と変革の取り組みを支援しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

このブログは “ Amazon Aurora DSQL for gaming use cases ” を翻訳したものです。 オンラインゲーム業界は、プレイヤーが即応的で、中断のないゲームプレイ、そして地理的に分散した地域間でのゲーム状態のシームレスな同期を期待するリアルタイムでグローバルに接続されたエコシステムへと進化しています。 現代のオンラインゲームは、何百万人もの同時接続プレイヤーをサポートし、リアルタイムのゲーム内取引を処理し、リーダーボード、マッチメイキング、プレイヤーのインベントリが常に最新の状態であることを保証する必要があります。これらすべてを低レイテンシーと強力な一貫性を維持しながら実現しなければなりません。 これらの要求に応えるため、ゲームバックエンドには、簡単にスケールするだけでなく、グローバルに分散した ACID 保証、高可用性、結合や集計などのリッチなリレーショナルクエリのサポートを提供するデータベースが必要です。 既存のリレーショナルデータベースや NoSQL データベースはスケーラビリティと可用性を提供していますが、これらの機能をグローバルな一貫性とトランザクションの整合性と組み合わせると、アーキテクチャの複雑さが増すことがよくあります。 Aurora DSQL は、グローバルに接続されたゲーム向けに、マルチリージョン間の整合性を標準で備え、SQL サポート、シームレスなスケーラビリティを備えた分散型サーバーレスリレーショナルデータベースを提供することで、この状況をシンプルにします。 本記事では、 Amazon Aurora DSQL がスケーラビリティ、強力な一貫性、そしてマルチリージョン高可用性を組み込みで提供することで、リアルタイムなマルチプレイヤーインタラクションからグローバルに一貫性のあるリーダーボードまで、現代のゲームのユースケースをどのように強化するかをご紹介します。 ゲームデータベースに対する高まる要求 オンラインゲームが複雑さとグローバルな展開を拡大するにつれて、バックエンドインフラストラクチャは高い同時実行性、リアルタイムの応答性、トランザクションの整合性をサポートするように進化する必要があります。 リレーショナルデータベースや NoSQL データベースは多くのゲームのニーズ（セッション管理、キャッシング、イベントトラッキングなど）に対応し続けていますが、一部のユースケース（グローバルなゲーム状態、プレイヤーインベントリ、ゲーム内購入など）では、地理的に分散したプレイヤー間で、より強力な一貫性と広範な連携が求められます。 予測不可能な負荷に対するスケーリング – 多くのシステムでは、プレイヤーアクティビティの大規模な急増に対応するために、事前計画、手動シャーディング、またはプロビジョニングが必要であり、ライブイベントやゲームのリリース時に運用上のオーバーヘッドが発生します。 一貫性とトランザクション保証 – 結果整合性は、リーダーボードやインベントリ更新のような速いペースのシナリオで問題を引き起こす可能性があります。これらのシナリオではタイミングと精度がユーザーエクスペリエンスに直接影響します。 リージョン間の可用性 – グローバルで中断のないゲームプレイを提供するには、高可用性を維持するためのカスタムフェイルオーバー戦略と慎重なレプリケーション設計が必要になることがよくあります。 Amazon Aurora DSQL は、グローバルに分散した ACID トランザクション、高可用性、豊富な SQL サポートを単一のサーバーレスアーキテクチャで組み合わせることで、これらの進化する要件に対応します。これにより、開発者はインフラストラクチャをシンプルにしながら、スケールに応じた一貫性のある応答性の高いゲームプレイ体験を提供できます。 Amazon Aurora DSQL アーキテクチャ Amazon Aurora DSQL は、スケーラビリティ、一貫性、可用性のバランスを取るように設計されており、ゲームアプリケーション向けの最適なデータベースソリューションとして位置づけられています。この主張を裏付ける Amazon Aurora DSQL のアーキテクチャの詳細を見ていきましょう。 次のアーキテクチャ図は、Amazon Aurora DSQL マルチリージョンのアクティブ-アクティブクラスターを示しています。 設計上、Amazon Aurora DSQL は、クラスターがデプロイされているすべてのリージョンでの読み取りと書き込みの両方をサポートし、すべてのデータが強力な一貫性を保ち、完全に ACID 準拠であることを保証します。 このアーキテクチャにより、ゲーム業界はユーザーのログイン場所に関係なく、エンドユーザーに均一な体験を提供でき、プレイヤーのアクション、対戦結果、インベントリの更新をリージョン間でリアルタイムに同期することが可能になります。 次のアーキテクチャ図は、内部コンポーネントを含む Amazon Aurora DSQL シングルリージョンデータベースを示しています。 スケーラビリティの観点から、Amazon Aurora DSQL のクエリ処理レイヤー、コンピュートレイヤー、コミットレイヤー、ストレージレイヤーを含むすべてのコンポーネントは、ワークロードの需要に基づいて独立してスケールします。 これにより、ゲームはデータベースのシャーディングやインスタンスのサイズ変更の複雑な対応をせずに、ローンチ時、ライブイベント時、または季節的なアップデート時のスパイクに対応できます。 このセットアップは、単一リージョンで 99.99%、マルチリージョンで 99.999% の可用性を確保し、ゲームアプリケーション向けの信頼性の高いスケーラブルなソリューションを提供します。 Amazon Aurora DSQL アーキテクチャについて詳しく知りたい場合は、 Introducing Amazon Aurora DSQL を参照してください ゲーム向け Amazon Aurora DSQL の主な利点 Amazon Aurora DSQL は、モダンなゲームの一貫性とスケーリングのニーズに合わせたサーバーレスでクラウドネイティブなデータベースを提供します。 以下の機能により、開発者は信頼性とスケーリングを犠牲にすることなく、マルチリージョンで同期された耐障害性のあるゲーム体験を構築できます。 マルチリージョンのアクティブ-アクティブ書き込み – Amazon Aurora DSQL では、プレイヤーはマルチリージョンクラスター内のリンクされた 2 つのリージョンのいずれからでもデータの読み取りと書き込みが可能で、同時書き込みの競合解決はデータベースが処理します。これにより、プレイヤーのアクション、対戦結果、インベントリの更新をリージョン間でリアルタイムに同期できます。 スケールに対応した ACID 準拠トランザクション – 強力な一貫性により、リーダーボード、ゲーム内購入、マッチメイキングなどの重要なゲーム操作における競合状態、重複トランザクション、データ競合を防止します。 簡単なスケーリングと高可用性 – Amazon Aurora DSQL は、事実上無制限の水平スケーリングを提供し、ワークロードの需要に基づいて読み取り、書き込み、コンピューティング、ストレージを独立してスケーリングします。これにより、ゲームはローンチ時、ライブイベント時、季節的なアップデート時の大規模なスパイクに対応できます。データベースのシャーディングやインスタンスのアップグレードの複雑さなしに、単一リージョンで 99.99%、マルチリージョンで 99.999% の可用性を維持します。 PostgreSQL 互換 – ゲーム開発者は、既存の PostgreSQL インスタンスベースのデータベースを最小限の変更で Amazon Aurora DSQL 分散データベースに移行できます。 ゲーム向け Amazon Aurora DSQL の使用 Amazon Aurora DSQL がゲームバックエンドに実際の価値をもたらす方法を示すために、このセクションではゲームステート管理からリアルタイムインタラクション、リーダーボードまでの主要なユースケースを探り、Amazon Aurora DSQL がグローバル規模で信頼性の高いプレイヤー体験を提供する方法を強調します。 これらの課題はゲームに特有のものに見えるかもしれませんが、一貫性の維持、同期更新の確保、グローバルに分散したユーザー間のトラフィック処理など、より広範なシステムの問題を表しています。 ゲーム状態管理 領土制圧、ステージ解除/エリア解放、協力型のワールド進行など、永続的かつ進化し続ける世界を維持するゲームでは、一貫性と高可用性の確保が不可欠です。Amazon Aurora DSQL を使用することで、開発者はアクティブ-アクティブ機能を持つ複数の AWS リージョンにわたって、この共有されるゲーム状態を管理できます。これにより、リンクされたどのリージョンからも読み取りと書き込みの両方が可能になります。プレイヤーの移動や戦闘などのリアルタイムな操作を目的としたものではありませんが、Amazon Aurora DSQL は強力な一貫性と組み込みの競合解決機能を提供し、リージョンの障害が発生した場合でも、プレイヤーが引き起こす世界の変化が正確かつ永続的に維持されることを保証します。これにより、非同期マルチプレイヤー体験や可用性と継続性を優先するゲームに適しており、複雑なシャーディングや手動フェイルオーバーなしに、世界中のプレイヤーが統一されたゲーム世界とインタラクションできるようになります。 ゲーム内取引、ゲーム内仮想通貨、プレイヤーインベントリ ゲーム内仮想通貨やアイテムベースの報酬によって支えられる堅牢なゲーム内経済では、不正行為、アイテムの複製、購入アイテムの紛失を防ぐためにトランザクション保証が必要です。プレイヤーがアイテムを購入したり、戦利品を獲得したり、他のプレイヤーと取引したりする際、基盤となるシステムはウォレット残高とプレイヤーのインベントリを不可分かつ一貫して更新する必要があります。Amazon Aurora DSQL の ACID 準拠のトランザクションにより、これらの操作はグローバルデータベースクラスターの両方にリンクされたリージョンにおいて、高い同時実行性の下でも安全かつ確実に処理されます。 ライブイベント ライブイベントは、しばしばプレイヤーのアクティビティの急激な増加を引き起こし、データベースが増加した負荷に対応するために動的にスケールする必要があります。 Amazon Aurora DSQL のサーバーレスアーキテクチャにより、リソースをリアルタイムで自動的にスケールし、手動介入なしでトラフィックの急増に対応することができます。 その高可用性により、大規模なイベント中でも継続的な稼働時間が確保され、プレイヤーの没入感と満足度を維持し、途切れることのないスムーズなゲーム体験を提供します。 グローバルリーダーボード 競争性の高いゲームでは、プレイヤーが新しいスコアやマイルストーンを達成するたびにリアルタイムで更新されるリーダーボードが特徴となっています。Amazon Aurora DSQL のアクティブ-アクティブレプリケーションと強力な一貫性により、マルチリージョンクラスター内のリンクされた両方のリージョンでリーダーボードデータの正確性と最新性が確保されます。これにより、場所に関係なくすべてのプレイヤーが同じリーダーボード結果を見ることができ、公平な競争を促進し、プレイヤーの成果をリアルタイムに反映することでエンゲージメントを維持します。 リアルタイムプレイヤーインタラクション リアルタイムチャット、チームベースの連携、共有ワールドイベントなどのソーシャル性や協力要素を備えたゲームでは、リージョンをまたいだプレイヤー間のリアルタイムなやり取りが必要です。さらに、マッチメイキングシステムは、スキルレベル、レイテンシー、ゲームモードの好みに基づいてプレイヤーを効率的にペアリングし、公平で競争力のある対戦を確保する必要があります。Amazon Aurora DSQL のアクティブ・アクティブ分散アーキテクチャにより、メッセージの送信、チーム形成、マッチメイキングキューへの参加などのプレイヤーアクションをリージョン間でリアルタイムにレプリケーションできるため、データの不整合を最小限に抑え、グローバルなプレイヤー間のやり取りをより迅速にサポートすることができます。 Amazon Aurora DSQL のアーキテクチャは、プレイヤー間のコミュニケーション（チャット、招待、グループプレイ）を同期させ、中断のないリアルタイムのマルチプレイヤー体験を提供します。 アクティブ-アクティブ書き込みは、競合状態を防ぎ、リアルタイムデータに基づく公平なプレイヤーのペアリングを可能にすることで、グローバルに一貫したマッチングを維持します。 Amazon Aurora DSQL は自動的にスケールし、ライブイベントやピーク時のマッチメイキングリクエストの急増にも対応できます。 また、ローカルな読み取り処理と複雑なクエリにより、リアルタイムゲームロジックのための低レイテンシーな意思決定が可能になります。 インタラクションデータが増加しても、Amazon Aurora DSQL はストレージを自動的に管理し、その料金体系はプレイヤーのアクティビティが変動するゲームのコスト効率をサポートします。 組み込みの暗号化と IAM ベースのアクセス制御により、機密性の高いプレイヤーデータや仮想資産をさらに保護します。 まとめ 本稿では、Amazon Aurora DSQL がマルチリージョンのアクティブ-アクティブアーキテクチャ、ACID トランザクション、そしてサーバーレススケーラビリティを通じて、グローバルに一貫性があり、高度にスケーラブルな体験を実現することで、現代のゲームバックエンドが直面する特有の要求にどのように対応しているかをご紹介しました。 詳細については、 Amazon Aurora DSQL ドキュメント をご覧いただくか、Aurora DSQL を使用してグローバルにスケーラブルなゲームバックエンドの構築を今すぐ始めてください。 著者について Naveen Kantamneni Naveen は AWS のシニアスペシャリストソリューションアーキテクトであり、ゲーム業界のお客様がモダナイゼーションを推進し、運用効率を向上させ、世界水準のプレイヤー体験を実現できるよう支援しています。スタートアップから大規模スタジオまで、さまざまなゲーム企業の信頼できるアドバイザーとして、ビジネス課題の解決や、ミッションクリティカルなワークロードにおける AWS サービスの最適化に取り組んでいます。 Rajesh Kantamani Rajesh はシニアデータベーススペシャリストソリューションアーキテクトです。スケーラビリティ、セキュリティ、パフォーマンスに焦点を当てながら、顧客と協力して Amazon Web Services 上のデータベースソリューションの設計、移行、最適化を行っています。分散データベースに情熱を持ち、組織のデータ基盤のモダナイゼーションを後押ししています。 Raluca Constantin Raluca は AWS のシニアデータベースエンジニアで、Amazon Aurora DSQL を専門としています。彼女の 18 年にわたるデータベース分野の経験を持ち、Oracle、MySQL、PostgreSQL からクラウドネイティブソリューションまで幅広い技術に精通しています。特に、スケーラビリティ、パフォーマンス、リアルタイムデータ処理を中心に取り組んでいます。

本記事は米国時間 7 月 31 日に公開された “ Overcome development disarray with Amazon Q Developer CLI custom agents ” を翻訳したものです。 ワークフローを強化するために Model Context Protocol (MCP) の力を受け入れてきた開発者として、 Amazon Q Developer CLI にカスタムエージェント が追加されたことを心より嬉しく思います。この新しい機能は、私が信頼してきた能力を全く新しいレベルに引き上げ、異なる開発コンテキストをシームレスに管理し、簡単に切り替えることを可能にしてくれます。 前回の投稿 では、MCP サーバーが AWS サービスやデータベース、その他の重要なツールとの関わり方にどのような革命をもたらしたかについて説明しました。 Amazon Q Developer の MCP 統合によって、データベーススキーマのクエリ、インフラストラクチャにおけるデプロイの自動化、その他多くのことができるようになりました。しかし、複数のプロジェクトを掛け持ちするようになり、それぞれに独自の技術スタックや要件があるため、これらの多様な開発環境を管理するために、より構造化されたアプローチが必要であることに気づきました。 そこで、カスタムエージェントの登場です。この新しい機能により、開発段階に適したタスクのために、特定のツール、プロンプト、コンテキスト、ツール許可をまとめることで、カスタムエージェントを作成・使用することができるようになりました。 背景 私が多層ウェブアプリケーションに取り組んでいるとしましょう。このアプリケーションには、TypeScript で書かれた React フロントエンドと Python で書かれた FastAPI バックエンドがあります。チームには私の他に、Figma を使用するデザイナーとPostgreSQL データベースを管理するデータベース管理者がいます。そこには、デザイナーとデータベース管理者とのコミュニケーション方法に微妙な違いがあります。例えば、私がデザイナーと「テーブル」について議論するとき、それは HTML テーブルとそのページがどのように構成されているかを指している可能性が高いです。しかし、私がデータベース管理者と「テーブル」について議論するときは、SQL テーブルとデータの格納方法について話すことが多いです。 以前、私の環境では、 Figma Dev Mode MCP サーバー と Amazon Aurora PostgreSQL MCP サーバー の両方を設定していました。これにより、フロントエンドとバックエンドのどちらのコードでも簡単に作業できるようになりましたが、いくつかの課題も発生しました。もし私が Amazon Q Developer に「テーブルはいくつありますか？」と尋ねたら、Amazon Q Developer は私が HTML テーブルについて話しているのか SQL テーブルについて話しているのかを推測しなければならないでしょう。もし HTML に関しての質問であれば、Figma サーバーを使用すべきです。もし SQL に関しての質問であれば、Aurora サーバーを使用すべきです。これは技術的な制限ではなく、言語の制限です。私がデザイナーやデータベース管理者と話すために前提を調整しなければならないのと同じように、Amazon Q Developer も同じ調整をしなければなりません。 そこで、Amazon Q Developer CLI カスタムエージェントの登場です。カスタムエージェントを使用することで Amazon Q Developer の設定をシナリオごとに最適化することができます。私のフロントエンドとバックエンドの構成を見て、その影響を理解してみましょう。 フロントエンドエージェント 私のフロントエンドカスタムエージェントは React と Figma を使用したフロントエンドウェブ開発用に最適化されています。以下のコード例は、 ~/.aws/amazonq/agents/front-end.json に格納されている私のフロントエンドエージェントの設定です。それでは、この設定の主なセクションについて説明しましょう。 mcpServers – ここでは Figma Dev Mode MCP サーバーを設定しました。ローカルにインストールされた Figma Web Design App と通信するだけです。これは、 ~/.aws/amazonq/mcp.json に保存されていた MCP 設定を置き換えることに注意してください。 tools と allowedTools – この 2 つのセクションは関連しているため、一緒に説明します。 tools は Amazon Q Developer が利用可能なツールを定義し、 allowedTools は信頼できるツールを定義します。言い換えると、Amazon Q Developer は設定されたツールを使用することができ、 fs_read や fs_write 、 @Figma を使用するために私に許可を求める必要がありません。 @Figma は、Amazon Q Developer が許可を求めることなく、すべての Figma ツールを使用することができます。 resources – ここではコンテキストに追加するファイルを設定しました。README.md (プロジェクトフォルダに格納されている) と、React に関する私自身の設定 (プロファイルに格納されている) を含めました。詳しくは、 コンテキスト管理とプロファイル を参照してください。 hooks – リソースに加えて、フックも用意しました。このフックはコマンドを実行し、実行時にそれをコンテキストに追加します。この例では、現在の git status を追加しています。詳しくは、 コンテキストフックの使用 を参照してください。 { "description": "Optimized for front-end web development using React and Figma", "mcpServers": { "Figma": { "command": "npx", "args": [ "mcp-remote", "http://127.0.0.1:3845/sse" ] } }, "tools": ["*"], "allowedTools": [ "fs_read", "fs_write", "report_issues", "@Figma" ], "resources": [ "file://README.md", "file://~/.aws/amazonq/react-preferences.md" ], "hooks": { "agentSpawn": [ { "command": "git status" } ] } } バックエンドエージェント 私のバックエンドカスタムエージェントは Python とPostgreSQL を使用したバックエンド開発に最適化されています。以下のコード例は、 ~/.aws/amazonq/agents/back-end.json に格納されている私のバックエンドエージェントの設定です。先ほどのようにセクションを説明するのではなく、フロントエンドとバックエンドの違いに焦点を当てます。 mcpServers – ここでは Amazon Aurora PostgreSQL MCP サーバー を設定しました。これにより、Amazon Q Developer が私の開発用データベースにクエリを発行し、スキーマを知ることができます。誤ってデータベースを更新しないように、読み取り専用の接続を設定していることに注意してください。 tools と allowedTools – 今回も Amazon Q Developer ですべてのツールを使用可能にしました。しかし、信頼できるツールについては、より制限しています。Amazon Q Developer は、 fs_write や @PostgreSQL/run_query の使用許可を求める必要があります。Figma でやったように MCP サーバー全体を許可することもできますし、ここでやったように特定のツールを許可することもできます。 resources – ここでも、README.md (プロジェクトフォルダに格納されている) と Python と SQL に関する私自身の設定 (どちらも私のプロファイルに格納されている) を含めました。ここで glob パターンを使用可能なことに注意してください。例えば、 file://.amazonq/rules/**/*.md には Amazon Q Developer IDE プラグインによって作成されたルールが含まれます。 hooks – 最後にフロントエンドとバックエンド用のフックも用意しました。フロントエンドには npm run 、バックエンドには pip freeze のようにプロジェクト固有のオプションを含めることもできます。 { "description": "Optimized for back-end development with Python and PostgreSQL", "mcpServers": { "PostgreSQL": { "command": "uvx", "args": [ "awslabs.postgres-mcp-server@latest", "--resource_arn", "arn:aws:rds:us-east-1:xxxxxxxxxxxx:cluster:xxxxxx", "--secret_arn", "arn:aws:secretsmanager:us-east-1:xxxxxxxxxxxx:secret:rds!cluster-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx-xxxxxx", "--database", "dev", "--region", "us-east-1", "--readonly", "True" ] } }, "tools": ["*"], "allowedTools": [ "fs_read", "report_issues", "@PostgreSQL/get_table_schema" ], "resources": [ "file://README.md", "file://~/.aws/amazonq/python-preferences.md", "file://~/.aws/amazonq/sql-preferences.md" ], "hooks": { "agentSpawn": [ { "command": "git status" } ] } } カスタムエージェントの使用 エージェントの本当の力は、これらの異なる開発コンテキストを切り替える必要がある時に明らかになります。React と Figma で作業しているときは q chat --agent front-end を、Python と SQL で作業しているときは q chat --agen``t back-end を実行するだけです。Amazon Q Developer は私の好みに合わせて適切なエージェントを設定してくれます。 以下の画像は、Amazon Q Developer CLI における設定を見ることができます。フロントエンドエージェントには Figma という追加のツールがあり、バックエンドエージェントには PostgreSQL という追加のツールがあることに注目してください。さらに、フロントエンドエージェントは fs_write とすべての Figma ツールを信頼しますが、バックエンドエージェントは fs_write の使用許可を求め、2 つの PostgreSQL ツールのうち 1 つだけを信頼します。 同様に、フロントエンドエージェントとバックエンドエージェントのコンテキスト設定を見てみましょう。以下の画像では、フロントエンド開発用の React の設定とバックエンド開発用の Python と SQL の設定を含めています。 このように、カスタムエージェントを使用することで Amazon Q Developer CLI をタスクごとに最適化することができます。もちろん、フロントエンドとバックエンドのエージェントはただの一例です。開発やテストのエージェント、データサイエンスや分析のエージェントなどがあるかもしれません。カスタムエージェントを使用することでほとんどのタスクに対応した構成にすることができます。 おわりに Amazon Q Developer CLI カスタムエージェントは、複雑な開発環境を管理する上で重要な改善となります。開発者が異なるコンテキスト間をシームレスに切り替えられるようにすることで、異なるタスクのためにツールや権限を手動で再設定する認知的なオーバーヘッドを排除します。開発ワークフローを合理化する準備はできましたか？今すぐ Amazon Q Developer を始めましょう 。

本稿は、2025 年 8 月 5 日に AWS Migration &amp; Modernization Blog で公開された “ Run VMware your way: Amazon Elastic VMware Service is now generally available ” を翻訳したものです。 VMware 上でミッションクリティカルなワークロードを実行している企業にとって、クラウドへの移行は既存の投資を維持するか、イノベーションを受け入れるかの選択を迫られることが多くありました。本日、それが変わります。Amazon Elastic VMware Service (Amazon EVS) が 6 つの AWS リージョンで一般提供を開始し、VMware Cloud Foundation (VCF) ユーザーに AWS のスケール、柔軟性、パフォーマンス、セキュリティを提供します。 Amazon EVS が提供するもの 完全な VCF 環境を数週間ではなく数時間でデプロイ クラウド内の VMware スタックを完全にコントロール 既存の VMware スキルとツールを活用 リファクタリングなしで 200 以上の AWS サービスにアクセス ニーズに基づいてリソースを動的にスケール Amazon EVS が組織のクラウドジャーニーで直面する主要な課題にどのように対処するかを探ってみましょう。 課題 推定では、 企業ワークロードの 75% が現在もオンプレミスで稼働しており 、重要なアプリケーションが依然として VMware 上で実行されています。これらのアプリケーションは、顧客取引から製造業務まですべてを管理し、収益と顧客満足度に直接影響を与えています。これらのアプリケーションはクラウドの恩恵を受けられるはずですが、既存の複雑な依存関係や統合のため、移行が困難になっています。 これにより、お客様のような組織にとって差し迫った課題が生じています。オンプレミスのデータセンターには多額の設備投資と継続的なメンテナンスが必要であり、イノベーションのためのリソースが制限されます。一方で、ビジネスにおける俊敏性、スケーラビリティ、コスト最適化に対する要求は高まり続けています。業務を中断したり、大規模な再設計を必要とせずに、VMware ワークロードにクラウドの利点をもたらす方法が必要です。これらの課題に対処するため、VMware と AWS の長所を組み合わせたソリューションを開発しました。Amazon EVS は、VMware の移行とモダナイゼーションパスウェイの包括的なポートフォリオへの最新の追加となるもので、ワークロードをクラウドに移行し、モダナイゼーションの旅を始めるための選択肢をさらに増やします。 Amazon EVS の違い：コントロール、柔軟性、選択肢 私たちは、クラウド上で VMware を実行するためのより多くの選択肢を提供する必要性に応えるため Amazon EVS を構築しました。多くのお客様が Broadcom の VMware Cloud on AWS マネージドサービスの恩恵を受けている一方で、Amazon EVS は選択肢を拡大し、AWS ネイティブサービスならではのコントロール、選択、柔軟性を提供します。 Amazon EVS の核心は、AWS Nitro を搭載した EC2 ベアメタルインスタンス上で、Amazon Virtual Private Cloud (VPC) 内で VCF をネイティブに実行することです。完全な VCF 環境のセットアップは、ステップバイステップの設定ワークフローを使用する場合でも、自動デプロイメント機能を備えた AWS Command Line Interface (CLI) を使用する場合でも、わずか数時間で完了します。この迅速なデプロイメントにより、ワークロードを AWS に素早く移行し、老朽化したインフラストラクチャを廃止し、運用リスクを軽減し、データセンターからの撤退などの重要なタイムラインを達成することができます。このコントロールと柔軟性が組織にとってどのような実践的なメリットをもたらすのか見ていきましょう。 クラウド上でのアーキテクチャ制御と、任意のソリューションとの統合 Amazon EVS を使用すると、クラウド内の VMware ワークロードのアーキテクチャを完全に制御できます。vSphere、NSX Manager、SDDC Manager への完全な管理アクセスにより、ビジネスニーズに応じて仮想化スタックを最適化できます。このサービスは VCF 5.2.1 をサポートし、 Amazon FSx for NetApp ONTAP や Pure Cloud Block Store などの外部ストレージソリューション、あるいは Veeam Backup and Replication などのバックアップソリューションなど、すでに信頼しているアドオンやサードパーティソリューションを統合できます。 コストを最適化するための柔軟性 技術的な機能に加えて、私たちはビジネスニーズを考慮して Amazon EVS を設計しました。ライセンスと消費の柔軟性がビジネス計画にとって重要であることを理解しています。そのため、Amazon EVS では、 ライセンスポータビリティエンタイトルメントを通じて既存の VCF ライセンスを持ち込むことができ 、オンデマンド、1 年、3 年の期間を含む柔軟な消費オプションから選択できます。さらに、Amazon EVS は Migration Acceleration Program (MAP) の対象となり、移行コストの削減と AWS への移行の加速を支援します。 環境管理方法の選択肢 社内の専門知識を活用したいか、専門的なサポートが必要かに関係なく、Amazon EVS は組織のニーズに適応します。セルフマネージドによりコントロールを最大化し、既存のスキルを活用することも、マネージドサービスや移行の専門知識を提供する広範な AWS パートナーと協力することもできます。これらのパートナーには、 Pellera Technologies 、 Kyndryl 、 DXC Technology 、 Xtravirt 、 Accenture 、 AHEAD 、 Effectual 、 Presidio 、 CDW 、 富士ソフト などの業界リーダーが含まれます。 これらのパートナーは、Amazon EVS での成功を支援する実証済みの専門知識を提供します。例えば、Converge は現在、お客様向けに EVS (Elastic VMware Service) IQ Migrate サービス を提供しています。Pellera Technologies のクラウドプラットフォーム担当副社長である Rochelle Manns 氏は次のように説明しています：「Amazon EVS の機能と当社のインテリジェントサービスを組み合わせることで、複雑さや妥協なしに、AWS 上の VMware 環境の評価、移行、運用への明確な道筋を顧客に提供しています。パートナー主導のアプローチのシンプルさと、自分のペースでモダナイゼーションを進められる柔軟性を兼ね備えています。」 同様に、DXC Technology は DXC Migration and Managed Services for Amazon EVS を開始しました。DXC Technology のクラウド＆インフラストラクチャオファリング責任者である Andrew Haigh 氏は、Amazon EVS を検討しているお客様にとってのパートナーの価値を強調し、次のように述べています：「Amazon EVS の開始は、VMware の信頼できる VCF プライベートクラウドプラットフォームと革新的な AWS クラウドネイティブサービスを組み合わせた、AWS 上の企業にとって魅力的なソリューションを提供します。DXC の仮想化ワークロードの移行と運用における数十年の経験により、お客様は迅速かつ確実にクラウド導入戦略を実行し、ビジネス価値を実現することができます。」 さらに、富士ソフトのソリューション事業本部副本部長 兼 インフラ事業部事業部長執行役員である山本祥正氏は、このサービスがお客様の移行ジャーニーにどのように支援するかを強調しました：「この新たなサービスは、VMware 環境をお客様の AWS クラウドジャーニーとシームレスに統合し、インフラストラクチャの移行とモダナイゼーションを加速させる画期的なソリューションであると確信しております。富士ソフトは、Amazon EVS によって、お客様のクラウドジャーニーにおいて新たな価値創造の機会が生まれることを期待しております。」 これらの AWS パートナーと Amazon EVS 向けのソリューションについて詳しく知るには、 AWS Marketplace をご覧いただくか、AWS 担当者にお問い合わせください。 スケーラブルな企業インフラストラクチャ Amazon EVS 上で実行することで、アプリケーションは世界中の数百万ものお客様にサービスを提供している実績のあるグローバルインフラストラクチャと同じメリットを享受できます。スタートアップから Fortune 500 企業まで、組織はピーク時の需要に対応するための拡張性と、通常運用時のコスト最適化を実現するために AWS を信頼しています。ワークロードはリファクタリングやリプラットフォームなしで AWS サービスをシームレスに活用でき、移行とモダナイゼーションの過程を加速することができます。 実際のお客様の成功事例 AWS re:Invent 2024 で Amazon EVS を発表して以来、私たちは顕著なお客様の成功事例を目にしてきました。その中でも際立つ例が、200 万人以上の住民にサービスを提供するコロンビア第 3 の地方自治体である Alcaldía de Cali です。彼らの目標は、200 万人以上の住民により良いデータ駆動型の公共サービスを提供することでした。Amazon EVS を使用することで、24 時間以内に環境を展開し、移行期間中も公共サービスを中断することなく維持することができました。 この勢いは続いており、Aeroméxico や Huron Consulting Group などの組織が、私たちの公式プレスリリースで Amazon EVS への期待を表明しています。 今日から AWS へのジャーニーを開始 Amazon EVS は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド) で利用可能です。戦略的なデータセンターの撤退を計画している場合でも、運用コストの削減を検討している場合でも、クラウドイノベーションを活用する準備ができている場合でも、Amazon EVS は VCF ベースのワークロードのためのシンプルなパスを提供します。 次のステップ 詳細を学ぶ： 製品ページ 、 AWS News Blog 、 プレスリリース をご覧ください 開始する： Amazon EVS コンソール にアクセス 詳しく学ぶ： 技術ドキュメント を確認し、Amazon EVS の詳細を学習 移行とモダナイゼーションオプションを探索： AWS for VMware ページ をご覧いただき、AWS で VMware を移行・モダナイゼーションするすべてのオプションを発見 計画を開始： AWS 担当者に連絡するか、 お問い合わせ ください <!-- '"` --> Steven Jones EC2 の Commercial Applications の General Manager として、SAP、VMware、Red Hat Open Shift on AWS の製品戦略、エンジニアリング実行、カスタマーサクセスをリードしています。AWS 内のこれらのビジネス領域により、企業は最も要求の厳しいワークロードをクラウド上で実行できます。AWS で 13 年の経験を持ち、革新的なソリューションの提供、パフォーマンスのスケーリング、複数のセグメントや業界にわたる成長の推進において確かな実績があります。AWS を最もお客様中心のクラウドプラットフォーム、そしてビジネスクリティカルなワークロードを実行するための最適な場所にすることに情熱を注いでいます。AWS における SAP 技術戦略の推進役であり、ハイパースケールプラットフォーム上での SAP ワークロードの一般サポートや、大容量メモリ SAP HANA ワークロードを支えるクラウドネイティブなインフラストラクチャなど、業界初の取り組みを数多く市場に送り出してきました。また、VMware ビジネスも統括し、お客様が VMware ベースの環境をシームレスに AWS へ移行および拡張できるよう支援しています。創造的なアイデア、抽象化、システムパフォーマンスに関するスキルを活かし、お客様、パートナー、AWS に価値をもたらしています。 Bianca Velasco AWS の Product Marketing Manager として、AWS 上の VMware ベースワークロードの移行と変革に焦点を当てています。マーケティングとテクノロジーで 7 年以上の経験を持ち、複雑なテクノロジーを意味があり親しみやすいものにする物語を作ることに情熱を注いでいます。AWS 以外では、Bianca はボランティア活動、ダンス、ボルダリングを楽しんでいます。 Andy Reedy EC2 Commercial Applications の Product Management の Sr. Manager として、VMware、SAP、Red Hat OpenShift ワークロードに焦点を当てたチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェア分野で 25 年以上の経験を持ち、ビジネスクリティカルなアプリケーションの移行やモダナイズをお客様が実現できるよう支援することに情熱を注いでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

こんにちは、AWS ソリューションアーキテクトの上野です。2025年6月17日、7月4日に、AWS 主催のハッカソンイベントを開催しましたので、その取り組みについてご紹介させていただきます。本イベントは、通常のハンズオンとは異なり、短期集中型の支援を通じて実務で即活用できる機能開発を実現し、お客様のビジネスを加速させることを目指しています。 イベントの流れ 2日間のイベントを軸に進めていきます。初日となる Day 1 では、まず開発で利用する AWS サービスの基礎を学んでいただき、その後、実際に開発する機能の要件整理や設計に取り組んでいきます。AWS のエキスパートが終日同じテーブルにつき、一緒に考え、技術面でのアドバイスを提供させていただきます。 Day 1 で整理した内容を持ち帰っていただいた後は、実際の開発フェーズに入ります。開発中に疑問点や課題が出てきた際には、随時技術相談会を開催し、スムーズな開発をサポートさせていただきます。 締めくくりとなる Day 2 では、参加者の皆様に開発した機能についてご発表いただきます。技術的な工夫だけでなく、開発中の試行錯誤など、貴重な経験の共有の場となっています。 参加企業様の素晴らしい取り組み それではここからは、ご参加いただいた企業様のご登壇の様子をご紹介していきます。 株式会社クリエイティブ・ウェブ 片桐　翼 氏（写真右）、藤井　龍生 氏（写真中央）、大皿　綾馬 氏（写真左）らは、電話による問い合わせの一次対応をAIで行い、問い合わせ内容を仕分けして担当者に通知する仕組みを開発されました。システム・PCサポート・WEB サイト・EC 関連の問い合わせに対して、最初に受電した方が内容を聞いて、担当者に取り次ぐ必要があり、問い合わせる側の待ち時間および、対応をする側の工数にそれぞれ課題がありました。これらの課題を解決するためにまず、問い合わせ内容の仕分けを生成 AI で行い、適切な担当者に振り分ける機能を開発することで、一次対応する方の負荷を削減されております。また問い合わせをした方は、一度、問い合わせ内容を電話で伝えた後、担当者から折り返し電話がかかってくる仕組みのため、電話越しに長時間を待つ必要がなくなります。すでに社内ではベータ版としてリリースされており、今後は問い合わせ内容の仕分けだけではなく、AI と顧客の会話まで実現させ、一次対応の完全自動化を目指していかれるとのことです。 株式会社BTM 瀬﨑　優太朗 氏は、システムトラブルに伴う調査依頼を生成 AI と MCP サーバーの組み合わせで効率化する仕組みを開発されました。調査を行う上で、複数の関係者が存在するため、調査に必要な情報が不足している場合、再度確認を行うなどのコミュニケーションコストが多く発生している点や、調査作業として都度、状況に応じたクエリを考えてデータベースに対して実行する必要があるなどの課題があったとのことです。今回は、問い合わせ内容をもとに生成 AI が実行すべきクエリを考え、MCP サーバー連携によりデータベースにクエリを実行するという仕組みを Strands Agents を軸に開発されております。また開発においては AI コーディングエージェントも利用されており、技術的にも非常に興味深い取り組みをされております。今後はレスポンスタイムの向上と、情報不足時にチャットで聞き返えしができるようにするなど、さらにブラッシュアップをされていくとのことです。 AZAPAエンジニアリング株式会社 鬼頭　肖太 氏（写真左）、清水　凌太 氏（写真右）らは、本イベント の中で、既存の駐車場解析システムの構成をモダナイゼーションされました。映像解析処理は複数の工程に分かれており、それぞれの処理が一つのサーバーの中で順番に実行されるという構成をとられていました。しかし、工程ごとに処理の規模は異なり、必要なリソース量も変わる中で、最大規模の処理にあわせてサーバーのサイジングが必要なっていることから、コストに課題を持たれておりました。また１台のサーバーではリソースにも限度があり、処理速度にも課題が出てきている状況でもあったとのことです。今回は、一つのサーバー内で行われていたフローを AWS Step Functions に置き換えることで、工程別に必要な分だけのマシンリソースで処理を実施できる構成にモダナイゼーションされました。これによってコスト47%削減、処理速度3倍という検証結果が出ており、課題解決に向けた大きな一歩を本イベントで踏み出されたと実感いただいています。コスト面では、Lambda、スポットインスタンスを利用することでさらなる改善が見込め、処理速度とコストのパッケージに幅を持たせることが可能になりました。 まとめ 今回のイベントでも、参加された全てのお客様が、実務で使える機能を見事に開発されました。「ディスカッションを通して、アイデアの着想から掘り起こしまでできてとてもよい時間となった」、「短い時間であるからこそ集中的に開発ができた」など、うれしい声を多数いただき、本イベントがお客様のビジネスを加速させる場になっていることを改めて感じることになりました。また各企業様、それぞれまったく色の違う開発内容でありましたが、とある企業様の開発tipsが別の企業様の今後の開発効率化につながりそうであるなど、知見のシェアにもつながる素晴らしい場になったと感じています。これからもお客様のビジネスの発展により一層貢献できるよう、イベント内容の改善を重ねてまいります。

はじめに データベース技術は日々進化し、クラウド環境においてもその重要性は増す一方です。特に、AWSのデータベースサービスは昨今、多くの企業にとって不可欠なツールとなっています。こうした背景において、AWSは2025年8月から9月にかけてAWS データベースに関する学習機会をまとめて提供予定です。これらのセミナーやコンテンツを活用し、AWSのデータベースサービスについての理解を深めていただけたらと考えています。 本ブログでは、この期間に開催される注目のセミナーや、直近新たにBlackbeltとして公開した資料をご紹介します。特にAWSのデータベースサービスを最大限に活用したい方、最新の動向を把握したい方にとって、貴重な情報源となることでしょう。 それでは、具体的に見ていきましょう！ セミナーのご紹介 ■ (2025/8/25) AWS Database 開発チーム Meet-up 2025 AWSのデータベースサービス(Amazon Aurora DSQL、Amazon Aurora、AWS DynamoDB)の開発チームメンバーが登壇します。 各チームの特徴やサービスの最新アップデートに関する紹介と、質疑応答においては直接開発者にご質問いただくことが可能です。データベース技術に興味がある人、AWSデータベースサービスの詳細を知りたい人にお勧めなセミナーです。 申込先 : https://aws.amazon.com/startups/events/database-meetup-20250825 ■ (2025/9/25) MariaDB at Loft 本イベントでは、データベースパフォーマンスの最適化をテーマに、MariaDB と AWS の専門家が実践的な知見を共有します。前半の MariaDB ゲストセッションでは、データベースのベンチマーキング手法や、最新のベクトルインデックス機能など、パフォーマンスに直結する技術トピックスについて詳しく解説します。後半の AWS セッションでは、Amazon RDS を活用したマネージドデータベースへの移行戦略などをご紹介します。データベース管理者やアプリケーション開発者の方々におすすめの内容です。 申し込み先： https://aws.amazon.com/startups/events/mariadb-meetup-20250925 AWS Black Belt Online Seminar コンテンツのご紹介 ■ Amazon Aurora 概要編 Amazon Aurora は、リリース以来、10年以上にわたってAWSのマネージド型リレーショナルデータベースとして進化を続けてきました。この間、パフォーマンス最適化機能やセキュリティ強化、新しいデータベースエンジンの追加など、数多くの機能拡張が行われ、現在では世界中の多くのお客様のミッションクリティカルなワークロードを支えています。 本コンテンツでは、すでにAmazon RDSをご利用いただいているお客様向けに、改めてサービスの特長をご紹介すると共に、これからAuroraの利用をご検討されている方々に向けて、サービスの基本的な概要をわかりやすく解説しています。 Overview https://www.youtube.com/watch?v=lFvzuPVgXus 可用性 – 前半 https://www.youtube.com/watch?v=n14BOc-AgLM 可用性 – 後半 https://www.youtube.com/watch?v=tm-D7nITG_g 性能とスケーラビリティ https://www.youtube.com/watch?v=ctnpUjW97CQ コスト最適化 https://www.youtube.com/watch?v=kjdOuMyGjZQ 移行支援プログラム・サービス https://www.youtube.com/watch?v=NDFkegqRkuQ 以上は概要編になりますが、現在詳細編のリリースを準備していますので、ご期待ください！ ■ AWS Database Migration Service (DMS) AWS Database Migration Service（AWS DMS）は、データベースの移行を効率的かつ安全に行うためのAWSのマネージドサービスです。2016年の一般提供開始以来、AWS DMSは世界中の多くの企業のデータベース移行プロジェクトを成功に導いてきました。本コンテンツでは、AWS DMSの概要、主要な機能、そして効果的な活用方法について解説していきます。加えて、普段多くのお客様システムの安定稼働を支援しているAWSサポートメンバーから、実際のお客様からのお問い合わせに基づいた知見をベストプラクティスとしてご紹介しています。 既にDMSをご利用の方には新たな視点を、初めて検討される方には基礎から応用までの幅広い知識をお届けします。 DMS 概要 https://www.youtube.com/watch?v=oopjz4vu9CY DMS ベストプラクティス – 計画編 https://www.youtube.com/watch?v=teaU4tWraXE DMS ベストプラクティス – 実践編 https://www.youtube.com/watch?v=2tE9uCGrk6M DMS トラブルシューティング編 公開準備中。近々に公開予定。 以上

はじめに データベース技術は日々進化し、クラウド環境においてもその重要性は増す一方です。特に、AWSのデータベースサービスは昨今、多くの企業にとって不可欠なツールとなっています。こうした背景において、AWSは2025年8月から9月にかけてAWS データベースに関する学習機会をまとめて提供予定です。これらのセミナーやコンテンツを活用し、AWSのデータベースサービスについての理解を深めていただけたらと考えています。 本ブログでは、この期間に開催される注目のセミナーや、直近新たにBlackbeltとして公開した資料をご紹介します。特にAWSのデータベースサービスを最大限に活用したい方、最新の動向を把握したい方にとって、貴重な情報源となることでしょう。 それでは、具体的に見ていきましょう！ セミナーのご紹介 ■ (2025/8/25) AWS Database 開発チーム Meet-up 2025 AWSのデータベースサービス(Amazon Aurora DSQL、Amazon Aurora、AWS DynamoDB)の開発チームメンバーが登壇します。 各チームの特徴やサービスの最新アップデートに関する紹介と、質疑応答においては直接開発者にご質問いただくことが可能です。データベース技術に興味がある人、AWSデータベースサービスの詳細を知りたい人にお勧めなセミナーです。 申込先 : https://aws.amazon.com/startups/events/database-meetup-20250825 ■ (2025/9/25) MariaDB at Loft 本イベントでは、データベースパフォーマンスの最適化をテーマに、MariaDB と AWS の専門家が実践的な知見を共有します。前半の MariaDB ゲストセッションでは、データベースのベンチマーキング手法や、最新のベクトルインデックス機能など、パフォーマンスに直結する技術トピックスについて詳しく解説します。後半の AWS セッションでは、Amazon RDS を活用したマネージドデータベースへの移行戦略などをご紹介します。データベース管理者やアプリケーション開発者の方々におすすめの内容です。 申し込み先： https://aws.amazon.com/startups/events/mariadb-meetup-20250925 AWS Black Belt Online Seminar コンテンツのご紹介 ■ Amazon Aurora 概要編 Amazon Aurora は、リリース以来、10年以上にわたってAWSのマネージド型リレーショナルデータベースとして進化を続けてきました。この間、パフォーマンス最適化機能やセキュリティ強化、新しいデータベースエンジンの追加など、数多くの機能拡張が行われ、現在では世界中の多くのお客様のミッションクリティカルなワークロードを支えています。 本コンテンツでは、すでにAmazon RDSをご利用いただいているお客様向けに、改めてサービスの特長をご紹介すると共に、これからAuroraの利用をご検討されている方々に向けて、サービスの基本的な概要をわかりやすく解説しています。 Overview https://www.youtube.com/watch?v=lFvzuPVgXus 可用性 – 前半 https://www.youtube.com/watch?v=n14BOc-AgLM 可用性 – 後半 https://www.youtube.com/watch?v=tm-D7nITG_g 性能とスケーラビリティ https://www.youtube.com/watch?v=ctnpUjW97CQ コスト最適化 https://www.youtube.com/watch?v=kjdOuMyGjZQ 移行支援プログラム・サービス https://www.youtube.com/watch?v=NDFkegqRkuQ 以上は概要編になりますが、現在詳細編のリリースを準備していますので、ご期待ください！ ■ AWS Database Migration Service (DMS) AWS Database Migration Service（AWS DMS）は、データベースの移行を効率的かつ安全に行うためのAWSのマネージドサービスです。2016年の一般提供開始以来、AWS DMSは世界中の多くの企業のデータベース移行プロジェクトを成功に導いてきました。本コンテンツでは、AWS DMSの概要、主要な機能、そして効果的な活用方法について解説していきます。加えて、普段多くのお客様システムの安定稼働を支援しているAWSサポートメンバーから、実際のお客様からのお問い合わせに基づいた知見をベストプラクティスとしてご紹介しています。 既にDMSをご利用の方には新たな視点を、初めて検討される方には基礎から応用までの幅広い知識をお届けします。 DMS 概要 https://www.youtube.com/watch?v=oopjz4vu9CY DMS ベストプラクティス – 計画編 https://www.youtube.com/watch?v=teaU4tWraXE DMS ベストプラクティス – 実践編 https://www.youtube.com/watch?v=2tE9uCGrk6M DMS トラブルシューティング編 公開準備中。近々に公開予定。 以上

本記事は米国時間 7月 31 日に公開された「 Implementing Defense-in-Depth Security for AWS CodeBuild Pipelines 」を翻訳したものです。 最近のセキュリティ研究により、 AWS Security Bulletin AWS-2025-016 で文書化されているように、 CI/CD パイプライン設定の重要性が注目されています。この投稿では、既存のガイダンスと推奨事項を一つのガイドにまとめます。 継続的インテグレーションと継続的デプロイメント（ CI/CD ）の実践は、開発チームが効率的かつ確実にソフトウェアを提供するのに役立ちます。 AWS CodeBuild は、GitHub、GitLab、その他のソースコード管理（ SCM ）システムなどのソースコードリポジトリと統合するマネージドビルドサービスを提供します。このガイドでは GitHub の例を使用していますが、セキュリティの原則と Webhook 設定のアプローチは、サポートしている他のソースコード管理システムにも適用できます。 ただし、特定の設定には注意深い配慮が必要です。 適切なセキュリティ制御と脅威モデルの明確な理解なしに、信頼できないリポジトリのコントリビューターからの自動プルリクエストビルドを使用しないことを強く推奨します。 この設定により、信頼できないコードがリポジトリの認証情報や環境変数にアクセスできる状態でビルド環境内で実行される可能性があります。Webhook 設定は、どのリポジトリイベントがビルドをトリガーし、ビルドプロセス中にどのコードが実行されるかを決定します。 CI/CD を価値あるものにする自動化の利点を維持しながら、適切なセキュリティ境界を維持するためには、これらの設定を理解することが不可欠です。 セキュリティチームと DevOps エンジニアは、これらの実用的なアプローチを使用して、開発速度を維持しながらセキュリティ目標を満たすように AWS CodeBuild を設定できます。脅威モデルの評価、最小権限アクセス、パイプライン設定の継続的な監視を重視した、 Webhook 設定、信頼境界、実装戦略について説明します。 パイプラインのセキュリティに関する考察 責任共有モデル では、 AWS が基盤となる AWS CodeBuild インフラストラクチャのセキュリティを管理する一方で、お客様はパイプラインの設定、アクセス制御、およびビルド環境内で実行されるコードのセキュリティに責任を負います。このような共有の責任は、パイプライン自体のセキュリティを考える上で重要です。 AWS CodeBuild がプルリクエストを自動的に処理する際には、リポジトリの認証情報、環境変数、機密性の高い可能性のある情報にアクセスできる環境でコードをビルドします。これにより、パイプラインのセキュリティに関する特定の考慮事項が生じます： リポジトリアクセス: &nbsp; AWS CodeBuild プロジェクトは、ソースコードの読み取りと Webhook の作成のためにリポジトリの認証情報を必要とします。これらの認証情報は、設定に基づいて異なる特定の権限を提供します。 ビルドの実行: ビルドプロセスでは、取得したソースコードを実行します。これには、ビルドスクリプト、依存関係の定義、プルリクエストからのテストファイルなどが含まれる場合があります。 ビルド環境: &nbsp; AWS CodeBuild 環境は、ビルドプロセスに必要な環境変数、AWS 認証情報、またはその他の設定データにアクセスできる場合があります。 信頼境界の確立 効果的なパイプラインのセキュリティは、さまざまなタイプのコードのコントリビューションに対する信頼境界を明確に定義することから始まります： 内部のコントリビューター : 組織のアクセス管理プロセスを通じて検証された、リポジトリへの書き込みアクセス権を持つチームメンバー。 外部のコントリビューター : フォークされたリポジトリからプルリクエストを送信する、組織外のコントリビューター。 自動処理 : ビルドプロセスの一部として手動レビューなしで実行されるコード。 これらの信頼境界は、特定の環境の脅威モデリングの基礎となります。 内部および信頼できる環境 では、コントリビューターのフィルタリングと最小権限制御を使用して、自動化により多く依存することができます。 パブリックおよびオープンソースプロジェクト では、信頼できないコントリビューションを処理する固有のリスクがあるため、より厳格な制御が必要です。これらの環境では、より厳格なWebhookフィルタリング、包括的な承認プロセス、または後で説明するセルフホスト GitHub Actions ランナーのアプローチが有効です。 重要な原則は、特定のリスクプロファイルとコントリビューターの信頼レベルに基づいて、セキュリティ制御と開発速度の間の適切なバランスを見つけることです。これらの考慮事項を念頭に置いて、現在の AWS CodeBuild Webhook 設定を評価および設定する方法を見ていきましょう。 セキュアな Webhook の設定 Webhook は、外部イベントが AWS CodeBuild プロセスをトリガーする際に推奨されるメカニズムです。適切に設定されると、Webhook はリポジトリの変更に応答してビルドプロセスを自動化する強力で効率的な方法を提供します。ただし、不適切な Webhook 設定は、信頼できないコードが特権環境で実行されることを許可してしまい、セキュリティの脆弱性が生じる可能性があります。 Webhook 設定のセキュリティは、どのイベントがビルドをトリガーするか、それらのビルドがどのレベルのアクセス権を持つか、ビルドプロセス中にどのコードが実行されるかをどれだけ正確に理解しているかにかかっています。このセクションでは、セキュアな Webhook 設定の作成、評価、設定、および維持に対する包括的なアプローチを提供します。 現在の Webhook の設定の評価 既存の AWS CodeBuild プロジェクトを確認して、現在の Webhook 設定を理解することから始めましょう。以下の AWS CLI コマンドを使用すると、この情報を体系的に収集することができます。： # リージョン内のすべてのCodeBuild プロジェクトを一覧表示 aws codebuild list-projects --region us-west-2 # 詳細な設定情報を取得して分析 aws codebuild batch-get-projects --region us-west-2 \ --names $(aws codebuild list-projects --region us-west-2 \ --query 'projects[*]' --output text | tr '\n' ' ') これらのコマンドを実行する際は、出力の webhook セクションに特に注意してください。このセクションには、どのリポジトリイベントがビルドをトリガーするかを正確に決定する filterGroups 設定が含まれています。 現在の設定を確認する方法を理解したところで、一般的な設定パターンとそのセキュリティへの影響を見ていきましょう。 Webhook 設定パターン 一般的な Webhook の設定パターンを理解することで、潜在的なセキュリティ上の懸念点を素早く特定し、適切な改善を実装できるようになります。以下のパターンは、 Webhook の設定に対するさまざまなアプローチを表し、それぞれに特定のセキュリティへの考慮事項があります。 注: これらのパターンを利用することは推奨されません。注意が必要な設定を特定するための参考として紹介しています。 見直しが必要な設定 – プルリクエストの自動処理 { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED,PULL_REQUEST_REOPENED", "excludeMatchedPattern": false } ] ] } } この設定により、プルリクエストを作成できるコントリビューターがビルド環境でのコード実行をトリガーできるようになります。信頼できないリポジトリのコントリビューターからのプルリクエストの自動ビルドは利用しないことを強く推奨します。 即座に確認が必要な設定 – イベントフィルタリングなし { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [] } } フィルタリングを行わないので、この設定では幅広いリポジトリイベントでビルドがトリガーされる可能性があります。 推奨されるセキュアな Webhook 設定 以下の設定は、自動化の利点と適切なセキュリティ制御のバランスを取るセキュリティのベストプラクティスを表しています。これらのパターンは、CI/CD の価値である開発速度を維持しながら、セキュリティリスクを軽減するのに役立ちます。 プッシュベースのビルド（ほとんどのユースケースで推奨） プッシュベースのビルドは、リポジトリへの書き込みアクセス権を持つユーザーのみがビルドをトリガーできることを確実にします。これは、コントリビューターがリポジトリのアクセス制御メカニズムを通じてすでに検査されていることを意味します。 { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PUSH", "excludeMatchedPattern": false } ] ] } } 外部からのオープンソースコントリビューションに大きく依存している組織では、このアプローチは制限が厳しすぎる場合があります。例えば、外部のコントリビューターから毎日数十件のプルリクエストを受け取る人気のオープンソースプロジェクトでは、ビルドが実行される前に各コントリビューションを手動でマージする必要があり、コントリビューションのレビュープロセスが大幅に遅くなってしまいます。そのような場合、コントリビューターでフィルタリングされたビルドや、セルフホスト型の GitHub Actions ランナーのアプローチがより適切かもしれません。 コントリビューターによるビルドのフィルタリング（信頼できるコントリビューターのみ推奨） { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED", "excludeMatchedPattern": false }, { "type": "GITHUB_ACTOR_ACCOUNT_ID", "pattern": "^(12345678|87654321|11223344)$", "excludeMatchedPattern": false } ] ] } } この設定により、特定の信頼できるコントリビューターからのプルリクエストのビルドが可能になります。 重要: フィルタリングは GitHub のアカウント ID に適用され、リポジトリの所有権には適用されません。フォークされたリポジトリから作業するコントリビューターは、ビルド環境で実行される信頼できないコードを引き続き持ち込める可能性があります。 環境でこれらの設定を実装する前に、スムーズな移行を促進するのに役立つ以下の重要な要素を検討してください。 Webhook 設定の実装手順 以下のWebhook セキュリティ対策を実装する際は、次のようなより広範なプラクティスを考慮してください： 脅威モデリング: アプローチを選択する前に、特定のリスクプロファイルを評価します。 Infrastructure as Code : 本番環境の実装には Infrastructure as Code（IaC）ツールを使用します。 段階的な実装: 観察期間を設けて変更を段階的に実装します。 テストとロールバック: 非本番環境で最初に変更を検証します。 以下の実装アプローチは、最も制限的なものからより自動化された設定へと移行します。組織のリスク許容度と運用要件に最も適したアプローチを選択してください。 この3段階のプロセスは、セキュリティコントロールを維持しながら最も制限的なアプローチからより自動化された設定へと移行します。各ステップは前のステップに基づいて構築され、パイプラインを保護するための多層的なセキュリティ対策を作成します。 注: 以下の例は、 AWS CLI を使用して説明します。同様の設定手順は、 AWS CodeBuild のプロジェクト設定から AWS マネジメントコンソールを使用して実行することも可能です。 ステップ1: プッシュのみのビルドを設定 プッシュベースのビルドは、検証されたコントビューターのみがビルドをトリガーできることを確実にします。このアプローチは、コントリビューターがコードをプッシュする前に、リポジトリのアクセス制御メカニズムを通じてすでに検査されている必要があるため、より安全です。 プッシュイベントでのみトリガーされるように Webhook を設定します： aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PUSH", "excludeMatchedPattern": false } ] ]' ステップ2: ブランチベースのフィルタリングを実装 ブランチベースのフィルタリングは、特定のブランチへの変更に対してのみビルドがトリガーされることを確実にすることで、さらにセキュリティの層を追加します。このアプローチは、リポジトリ内のすべてのブランチが同じセキュリティ要件やリスクプロファイルを持つわけではないことを考慮しています。 例えば、 main や本番ブランチへの変更は、通常、フィーチャーブランチや開発ブランチへの変更よりも厳格なセキュリティ制御を必要とします。ブランチベースのフィルタリングを実装することで、各ブランチの重要性や公開範囲に基づいて、適切なセキュリティ対策を適用できます。 特定のブランチに対するフィルタリングを設定します： aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PUSH" }, { "type": "HEAD_REF", "pattern": "^refs/heads/(main|develop|release/.*)$" } ] ]' ステップ3: コントリビューターのフィルタリングを設定 コントリビューターフィルタリングは、信頼できるコントリビューターに対しては自動化を許可し、その他のコントリビューターに対しては手動レビューを要求することで、プルリクエストのビルドを管理できます。このアプローチは、コントリビューターごとにリスクプロファイルが異なることを考慮し、それに応じた対応を行うものです。 コントリビューターフィルタリングを実装する最初のステップは、信頼できるコントリビューターの GitHub のユーザー ID を特定することです。 信頼できるコントリビューターの GitHub ユーザー ID を取得します： curl -H "Authorization: token YOUR_GITHUB_TOKEN" \ https://api.github.com/users/trusted-username 信頼できるコントリビューターのユーザー ID を取得したら、これらのコントリビューターに対してのみ自動ビルドを許可するように Webhook のフィルタリングを設定できます： aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED" }, { "type": "GITHUB_ACTOR_ACCOUNT_ID", "pattern": "^(1234567|2345678|3456789)$" } ] ]' 重要: コントリビューターの許可リストは、チームメンバーの変更に応じて継続的なメンテナンスが必要です。バージョン管理で Webhook の設定とコントリビューターリストを管理するために、 CloudFormation の例 のような Infrastructure as Code テンプレートの使用を検討してください。 Webhook フィルタリングは、どのイベントがビルドをトリガーするかを制御することで、最初のセキュリティレイヤーを提供します。ただし、包括的なパイプラインセキュリティには、ビルドが実行時に利用可能な権限と認証情報に関する追加の制御が必要です。次のセクションでは、適切なアクセス制御と認証情報管理を通じて多層的なセキュリティを実装する方法について説明します。 アクセス制御と認証情報管理 このセクションでは、ビルドプロセスで利用可能な権限を制限し、リポジトリアクセストークンに適切に権限範囲を設定し、潜在的なセキュリティ問題を封じ込めるための分離環境を作成する具体的なアプローチについて説明します。これらのプラクティスは、自動化された CI/CD ワークフローの運用上のメリットを維持しながら、多層的なセキュリティ対策を実装するために連携して機能します。 最小権限アクセスの実装 AWS CodeBuild プロジェクトは、ビルドプロセス中に AWS リソースにアクセスするために IAM サービスロールが必要です。最小権限の原則では、各ロールは意図された機能を実行するために必要な最小限の権限のみを持つべきです。異なるタイプのビルドに対して、目的に応じた個別の IAM ロールを作成することで、ビルド環境への不正アクセスの潜在的な影響を軽減できます。 以下の例は、異なるビルドシナリオに対する最小限の IAM ロールを構造化する方法を示しています。これらの例は、特定の要件に基づいてカスタマイズし、ビルドが実際に必要とする権限のみを追加する出発点として機能します。 サービスロール設定 特定のビルドタイプに必要な権限のみを提供する最小限の IAM ロールを作成します： テスト/検証ビルドロール { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/codebuild/test-*" }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::your-test-artifacts-bucket/*" } ] } リリースビルドロール（テスト用とは別に作成） { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject" ], "Resource": "arn:aws:s3:::your-production-artifacts-bucket/*" }, { "Effect": "Allow", "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:PutImage" ], "Resource": "arn:aws:ecr:*:*:repository/your-production-repo" } ] } CodeBuild セキュリティのための IAM Access Analyzer の活用 AWS IAM Access Analyzer は、ビルド実行時の実際の CloudTrail アクティビティに基づいて、 AWS CodeBuild サービスロールの最小権限ポリシーを生成できます。これはビルドが行う特定のAWS API呼び出しを分析することで、必要な権限を予測するための推測で行う作業を排除します。 CodeBuild プロジェクトを一定期間実行した後、 Access Analyzer のポリシー生成機能を使用して最適化されたポリシーを作成します。このアプローチは、必要な権限がすぐにはわからない複雑なビルドプロセスに特に価値があります。 詳細な実装手順については、 IAM Access Analyzer のドキュメント を参照してください。 認証情報の権限範囲と送信元認証 外部からのコントリビューションを処理する際、リポジトリアクセストークンに対する最小権限の原則が重要になります。不正なユーザーが信頼できないビルドを通じてトークンにアクセスした場合、トークンが適切に権限範囲設定されていれば、ビルドプロセスに必要な権限のみに潜在的な影響を制限できます。 このリスクを軽減するために、最小限の権限で GitHub のFine-grained Personal Access Token を設定します。不適切にアクセスされた場合でも、適切な権限範囲を持つトークンは、ソースコード（プルリクエストを通じてすでにアクセス可能）の読み取りとステータスメッセージの書き込みのみが可能です。コードのプッシュ、リポジトリ設定の変更、または他のリポジトリへのアクセスはできません。 以下の権限は、外部からのプルリクエストを処理するために必要な最小限のアクセスを表し、トークンの権限範囲を必須の操作のみに制限する方法を示しています： contents:read – リポジトリソースコードへの読み取り専用アクセス（プルリクエストを通じてすでにアクセス可能） statuses:write – コミットステータスメッセージの書き込みのみ（コードや設定の変更は不可） metadata:read – 基本的なリポジトリ情報（名前、説明、公開ステータス）へのアクセス 重要: 対象リポジトリのみに制限された Fine-grained Personal Access Token を使用してください。そうしないと、ビルドプロセスに必要な範囲を超えて他のリポジトリへのアクセスを許可してしまう可能性があります。 この権限範囲を設定するアプローチにより、トークンが不適切にアクセスされた場合でも、その潜在的な影響は、すでにアクセス可能な情報の読み取りとステータスメッセージの書き込みに限定されます。このトークンは、コードのプッシュ、リポジトリ設定の変更、Webhookの作成、または他のリポジトリへのアクセスはできません。 認証情報の保存とローテーション 以下の例は、AWS Secrets Manager を使用してこれらのトークンを安全に保存および参照する方法を示しています。 AWS Secrets Manager は、自動ローテーション機能、保存時および転送時の暗号化、ビルドログや設定ファイルでトークンが公開されることを防ぐきめ細かなアクセス制御を提供します。このアプローチにより、トークンアクセスの監査証跡を維持しながら、複数の CodeBuild プロジェクト間での一元的なトークン管理も可能になります。 # Fine-grained トークンをAWS Secrets Managerに保存 aws secretsmanager create-secret \ --name "codebuild/github-pat-limited" \ --description "Limited GitHub PAT for external PR processing" \ --secret-string '{"token":"ghp_your_limited_token_here"}' # 権限範囲が設定された認証情報で CodeBuild プロジェクトを作成 aws codebuild create-project \ --name external-pr-processor \ --source '{ "type": "GITHUB", "location": "https://github.com/your-org/your-repo.git", "sourceCredentialsOverride": { "serverType": "GITHUB", "authType": "PERSONAL_ACCESS_TOKEN", "token": "{{resolve:secretsmanager:codebuild/github-pat-limited:SecretString:token}}" }, "reportBuildStatus": false }' \ --service-role arn:aws:iam::account:role/minimal-test-build-role 一元化されたストレージにより、認証情報のローテーションが可能になり、インフラストラクチャの更新が必要なハードコードされたトークンと比較して、露出期間を最小限に抑えることができます。 ビルド環境の分離 適切なビルド環境のセキュリティ管理を確立することで、パイプラインの完全性を維持できます。このアプローチの基礎となるのは、テストビルドとリリースビルドの分離を実装することです。これにより、認証情報の権限昇格を防ぎ、潜在的な不正アクセスの範囲を制限することができます。 ネットワーク分離は、もう一つの保護層です。外部コードを処理するビルド専用の VPC を、慎重に制限されたアウトバウンドアクセスを持つ専用のセキュリティグループを作成して設定します。これらのセキュリティグループは、正当な依存関係をダウンロードするための HTTPS トラフィックなど、必要な接続のみを許可し、信頼できないコードによって悪用される可能性がある不要なネットワークアクセスをブロックする必要があります。 AWS CodeBuild プロジェクトを更新し、指定されたサブネットと制限されたセキュリティグループを含む適切な VPC 設定を使い、このネットワーク分離を活用するようにします。 人によるレビューゲートを持つマルチステージパイプラインセキュリティ 複数のパイプラインステージにわたるセキュリティコントロールの実装は、特に外部からのコントリビューションを処理する際に、適切な検証と承認プロセスを提供するのに役立ちます。このアプローチは、自動スキャンと人による監視を組み合わせて、本番環境に到達する前に問題を特定します。 コード検査の統合 ビルドプロセス中に Automated Security Helper などのセキュリティツールを自動的に実行するようにビルド仕様を設定しましょう。これらのツールは、コードセキュリティ問題と依存関係の問題をスキャンし、レビュー用の詳細なレポートを生成します。 すべてのスキャンが完了できるように、問題が見つかった場合でもビルドを最後まで続行するように構成した上で、対応が必要なセキュリティ上の問題が含まれるビルドは自動的に失敗させるようにします。すべてのスキャンの成果物を保存して、セキュリティチームに承認判断のための詳細情報を提供します。 手動承認によるゲート コードが自動セキュリティスキャンに合格した後、最終検証のために人間のレビュアーを関与させる手動承認ゲートを設定します。これにより、機密性の高い環境に進む前に適切な人間によるレビューを確保できます。 このセクションで解説されたアクセス制御と認証情報管理のプラクティスは、 AWS CodeBuild のパイプラインの多層防御セキュリティを実装するための具体的で実用的なアプローチを提供します。これらの制御は連携して複数の保護層を作成し、 CI/CD による自動化を価値あるものにする運用上の利点を維持します。 代替アプローチ – GitHub Actions のセルフホステッド ランナー AWS CodeBuild の GitHub Actions セルフホステッドランナー機能は、リポジトリ認証情報をビルド環境から分離し、 AWS CodeBuild Webhook 処理の代わりに GitHub Actions の実行フレームワークを使用することで、このガイドで説明した設定の問題に対処します。 外部からのコントリビューションを自動的に処理する必要がある組織では、適切なアクセス制御でランナーを設定し、永続的なアクセスを最小限に抑えるために一時的なランナーを使用し、ランナー管理の標準的なセキュリティ対策を適用してください。 設定の詳細は、 AWS CodeBuild ドキュメント をご覧ください。追加の実装ガイダンスについては、 AWS CodeBuild Managed Self-Hosted GitHub Action Runners のブログ投稿 をご参照ください。 監視とコンプライアンス 前のセクションで説明したセキュリティコントロールは、ビルド時の保護を提供しますが、包括的な多層防御セキュリティには、パイプラインのアクティビティと設定変更への継続的な可視化が必要です。監視とコンプライアンスの追跡は、セキュリティフレームワークの最終層として機能し、設定の逸脱の検出、アクセスパターンの監査、長期的なセキュリティ体制の維持に役立ちます。 AWS CloudTrail は、AWS CodeBuild を含む AWS サービスに対して行われた API 呼び出しの詳細なログを提供します。CloudTrail ログを有効にすることで、環境内のすべてのビルド関連アクティビティの包括的な監査証跡を作成できます。 AWS Config は、AWS CodeBuild プロジェクトの構成を時系列で追跡し、プロジェクトのインベントリと設定変更の完全な履歴を提供します。これには、Webhook の変更、リソースの関係性、環境全体でのコンプライアンス追跡が含まれます。AWS Config を設定して、AWS CodeBuild プロジェクトを監視し、Webhook フィルターなどのセキュリティ上重要な設定が変更されたときに通知を受け取るようにすることができます。 詳細については、AWS CodeBuild のドキュメントにあるAWS Config のサンプル をご参照ください。 結論 AWS CodeBuild パイプラインの多層防御のセキュリティ対策を実装するには、さまざまなセキュリティ考慮事項に対処する階層化された制御が必要です。最も効果的なアプローチは、Webhook フィルタリング、アクセス制御、認証情報管理、監視を組み合わせて包括的な保護を提供することです。このガイドで説明したこれらの多層的なプラクティスを実装することで、堅牢なパイプラインセキュリティを確立しながら開発速度を維持できます。 覚えておくべき重要な原則： まず脅威モデルを評価する – 異なるプロジェクトには異なるセキュリティアプローチが必要です 異なるタイプのコントリビューター間で明確な信頼境界を確立する Webhookフィルタリングを使用してビルドがトリガーされるタイミングを制御する ビルド環境に最小権限アクセスを実装する AWS Config とCloudTrail を使用して設定を定期的に監視および監査する AWS Secrets Manager または SSM Parameter Store にシークレットを保存し、ローテーションを有効にする AWS CodeBuild は、パイプラインを価値あるものにする運用上のメリットを維持しながら、これらのセキュリティ対策を実装する柔軟性を提供します。特定のリスクプロファイルと運用要件に基づいて、このガイドの設定と軽減策を適用してください。組織のニーズが進化する中でパイプラインのセキュリティを維持するために、定期的な設定の確認と更新が役立ちます。 CI/CDセキュリティベストプラクティスを実装するための追加の実用的なガイドにご期待ください。この投稿について質問やフィードバックがある場合、最も役立つトピックの提案を含めて、 re:Post : Begimher で新しいスレッドを開始するか、 AWS サポートにお問い合わせ ください。 翻訳は、ソリューションアーキテクトの金森が担当しました。原文は こちら です。 Daniel Begimher Danielは、クラウドセキュリティ、アプリケーションセキュリティ、インシデント対応ソリューションを専門とする Global Services Security 組織のシニアセキュリティエンジニアです。AWS Security and Compliance Technical Field Community 内の Application Securityフォーカスエリア を共同リードし、すべてのAWS認定を保持し、オープンソースのコードスキャンツールである Automated Security Helper（ASH） を作成しました。

8 月 4 日週は、生成 AI 機能から基盤サービスの強化まで、さまざまなイノベーションをご紹介します。これらのアップデートは、AI を活用したアプリケーションの構築、データベースの管理、クラウドインフラストラクチャの最適化など、より高度で堅牢かつ柔軟なアプリケーションの構築に役立ちます。 7 月 28 日週のリリース 私が 7 月 28 日週に注目したリリースを以下に記載しました: Amazon DocumentDB – Amazon DocumentDB サーバーレスが利用可能になりました 。これにより、オンデマンドでフルマネージドの MongoDB API 互換のドキュメントデータベースサービスが提供されます。詳細については、 Channy の投稿 をご覧ください。 Amazon Q Developer CLI – カスタムエージェントを作成 できるようになりました。これにより、コードレビューやトラブルシューティングなどの特殊なタスクを実行する際に、より効果的に CLI エージェントをカスタマイズできます。 このブログで詳細をご覧ください 。 Amazon Bedrock Data Automation – ドキュメント処理用の DOC/DOCX ファイルと、ビデオ処理用の H.265 エンコードビデオファイルをサポート するようになりました。これにより、マルチモーダルデータ分析パイプラインの構築が容易になります。 Amazon DynamoDB – Amazon DynamoDB データモデリングのモデルコンテキストプロトコル (MCP) ツール を導入しました。これによりは、アプリケーション要件を DynamoDB データモデルに変換するための構造化された自然言語主導のワークフローが提供されます。 AWS Lambda – レスポンスストリーミングが、デフォルトの最大レスポンスペイロードサイズの 200 MB をサポートするようになりました 。これは以前の 10 倍になります。Lambda レスポンスストリーミングは、レスポンスペイロードをクライアントにプログレッシブにストリーミングして戻すアプリケーションを構築するのに役立ちます。これにより、最初のバイトまでの時間 (TTFB) パフォーマンスを短縮することで、レイテンシーの影響を受けやすいワークロードのパフォーマンスを向上させます。 AWS 用 Powertools – Powertools for AWS Lambda (Java) の v2 をご紹介します 。これは、サーバーレスのベストプラクティスを実装するのに役立ち、 AWS Well-Architected の推奨事項を直接翻訳できる開発者ツールキットです。 Amazon SNS – 3 つの追加のメッセージフィルタリング演算子 をサポートするようになりました: ワイルドカードの一致、ワイルドカード以外の一致、およびプレフィックス以外の一致。SNS が標準トピックのメッセージグループ ID もサポートするようになりました。これにより、サブスクライブされた Amazon SQS 標準キューのフェアキュー機能が有効になります。 Amazon CloudFront – オリジンのタイムアウト制御を強化する 2 つの機能を提供 するようになりました: レスポンス完了タイムアウトと、Amazon S3 オリジンのカスタムレスポンスタイムアウト値のサポート。これらの機能により、遅いオリジンや応答しないオリジンの処理方法をより細かく制御できます。 Amazon EC2 – シャットダウン状態で停止している EC2 インスタンスを強制終了 できるようになりました。 Amazon EC2 Auto Scaling – AWS Lambda 関数を EC2 Auto Scaling ライフサイクルフックの通知ターゲットとして使用 できるようになりました。例えば、これを使用して、インスタンスが待機状態になったときにカスタムアクションをトリガーできます。 Amazon SES – 単一の SES アカウント内に独立したテナントをプロビジョニング し、自動レピュテーションポリシーを適用して E メール送信を管理できるようになりました。 AWS マネジメントコンソール – コンソールナビゲーションバーのサービスメニューに AWS アプリケーションを表示 できるようになりました。このビューでは、すべてのアプリケーションを表示でき、アプリケーションを選択して、関連付けられたすべてのリソースを表示できます。 Amazon Connect – Amazon Connect UI ビルダーは、構造化されたワークフローを構築する際の複雑さを軽減するために、 ユーザーインターフェイスを更新しました 。また、 新しい UI エクスペリエンスによって予測編集が簡素化され 、計画の精度が向上しました。 連絡先コントロールパネルのユーザーインターフェイスが更新され、より直感的になりました 。Amazon Connect では、 エージェントワークスペースに新しいアクションとワークフローも導入されました 。これらのアクションは、バックグラウンドで実行されているサードパーティアプリケーションを活用しています。 AWS Clean Rooms – Clean Rooms のステータス変更に関するイベントを Amazon EventBridge に公開 するようになりました。これにより、企業とそのパートナーは互いの基盤となるデータを公開したりコピーしたりすることなく、集合データセットを分析して共同作業する方法がさらに簡素化されます。 AWS Entity Resolution – Levenshtein Distance、Cosine Similarity、および Soundex アルゴリズムを使用したルールベースのファジーマッチング を導入しました。これにより、断片化され、一貫性がなく、不完全であることが多いデータセット全体でコンシューマーレコードを解決できるようになります。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します: Amazon Strands Agents SDK: エージェントアーキテクチャとオブザーバビリティに関する技術的な詳細情報 – シングルエージェントアーキテクチャとマルチエージェントアーキテクチャを構築するためのわかりやすい概要です。 Strands Agents SDK と Tavily を使ってダイナミックなウェブリサーチエージェントを構築 – 新しいツールをいかに簡単に追加できるかを示しています。 Amazon Nova による構造化された出力: ビルダー向けガイド – デコードが制限されたネイティブツールの使用に加えて実装された優れたヒントです。 Amazon Bedrock Data Automation を使用して配布資料ノートの作成を自動化 – ウェビナーの記録を包括的な配布資料に変換するための自動化されたサーバーレスソリューションを構築するソリューションです。 Amazon Q Developer CLI と MCP を使用して、ベストプラクティスに従って最新のサーバーレスソリューションを構築 – AWS サーバーレス MCP サーバーを追加します。 Amazon Bedrock AgentCore ブラウザツールのご紹介 – AI エージェントがウェブサイトとシームレスに対話できるようにするこのツールの詳細です。 Amazon Bedrock AgentCore コードインタープリターのご紹介 – 隔離されたサンドボックス環境で AI エージェントがコードを安全に実行できるようにする完全マネージド型サービスです。 近日開催予定の AWS イベント 近日開催予定のイベントにサインアップできるように、カレンダーを確認してください: AWS re:Invent 2025 (2025 年 12 月 1 日〜5 日、Las Vegas) — AWS の主力年次カンファレンスでは、ピアツーピア学習、専門家主導のディスカッション、貴重なネットワーキングの機会を通じて、共同イノベーションを提供します。 AWS Summits – クラウドコンピューティングコミュニティが集まり、交流し、協力し、AWS について学ぶことができる無料のオンラインイベントと対面イベントに参加してください。最寄りの都市、 メキシコシティ (8 月 6 日) および ジャカルタ (8 月 7 日) で開催されるイベントにご登録ください。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18日) です。 AWS Builder Center に参加して、AWS コミュニティのビルダーを学び、構築し、交流しましょう。&nbsp;今後開催される追加の 対面イベント と デベロッパー向けのバーチャルイベント をこちらでご覧ください。 8 月 4 日週のニュースは以上です。8 月 11 日週の Weekly Roundup もお楽しみに! – Danilo 原文は こちら です。

AWS のデベロッパーアドボケイトとして、私は複数の AWS リージョン にまたがって重要なアプリケーションを運用している多くのエンタープライズ組織と協業してきました。これらの組織がしばしば共有する重要な懸念事項は、自社のリージョンフェイルオーバー戦略への信頼の欠如です。すなわち、必要なときに機能するかどうか、すべての依存関係が特定されているかどうか、チームが手順を十分に練習しているかどうかについて、自信が持てないのです。従来のアプローチでは、リージョンレベルの切り替えに向けた準備状況が不明確になることがよくあります。 8 月 1 日、 Amazon Application Recovery Controller (ARC) のリージョン切り替えを発表します。これは、組織が自信をもってリージョン切り替えを計画、練習、オーケストレートできるようにし、リージョン間のリカバリオペレーションに関する不確実性を排除する、可用性の高いフルマネージド機能です。リージョン切り替えは、AWS 上のマルチリージョンアプリケーションのリカバリをオーケストレートするのに役立ちます。ある AWS リージョンから別の AWS リージョンにアプリケーションの運用を切り替える必要がある場合に、AWS のサービスとアカウント全体でリカバリタスクを調整および自動化する一元化されたソリューションを提供します。 多くのお客様は、可用性の要件を満たすために、ビジネスクリティカルなアプリケーションを複数の AWS リージョンにデプロイしています。あるリージョンのアプリケーションに運用イベントが影響する場合、運用を別のリージョンに切り替えるには、コンピューティング、データベース、DNS など、異なる AWS サービス間で複数のステップを調整する必要があります。この調整には通常、アプリケーションの進化に合わせて定期的なテストと更新が必要となる複雑なスクリプトの作成と維持が必要です。さらに、複数のアプリケーション間でのリージョン切り替えの進行状況をオーケストレートおよび追跡し、コンプライアンスのためにリカバリが正常に完了したことについての証拠を提供するには、多くの場合、手作業によるデータ収集が必要になります。 リージョン切り替えは、リージョンレベルのデータプレーンアーキテクチャ上に構築されており、リージョン切り替えプランはアクティブ化されるリージョンから実行されます。この設計により、切り替え中に影響を受けるリージョンへの依拠が排除され、実行は切り替え元のリージョンから独立しているため、より回復力の高いリカバリプロセスが実現します。 ARC リージョン切り替えを利用したリカバリプランの構築 ARC リージョン切り替えを使用すると、リージョン間でアプリケーションを切り替えるために必要となる具体的なステップを定義するリカバリプランを作成できます。各プランには、AWS リソースに対するアクションを表す実行ブロックが含まれています。リリース時点では、リージョン切り替えは 9 種類の実行ブロックをサポートしています: ARC リージョン切り替えプラン実行ブロック – 他のリージョン切り替えプランを参照することで、複数のアプリケーションが、アクティブ化するリージョンに切り替える順序をオーケストレートすることを可能にします。 Amazon EC2 Auto Scaling 実行ブロック – ソースリージョンのキャパシティの指定された割合に合わせて、ターゲットリージョンの Amazon EC2 コンピューティングリソースをスケールします。 ARC ルーティングコントロール 実行ブロック – ルーティングコントロールの状態を変更し、DNS ヘルスチェックを使用してトラフィックをリダイレクトします。 Amazon Aurora Global Database 実行ブロック – Aurora Global Database のために、データ損失の可能性があるデータベースフェイルオーバー、またはデータ損失ゼロのスイッチオーバーを実行します。 手動承認実行ブロック – リカバリワークフローに承認チェックポイントを追加し、チームメンバーが続行する前に確認および承認できるようにします。 カスタムアクション AWS Lambda 実行ブロック – アクティブ化または非アクティブ化するリージョンで Lambda 関数を実行することで、カスタムリカバリステップを追加します。 Amazon Route 53 ヘルスチェック実行ブロック – フェイルオーバー中にアプリケーションのトラフィックをリダイレクトするリージョンを指定できるようにします。リージョン切り替えプランを実行すると、Amazon Route 53 ヘルスチェックの状態が更新され、DNS 設定に基づいてトラフィックがリダイレクトされます。 Amazon Elastic Kubernetes Service (Amazon EKS) リソーススケーリング実行ブロック – リカバリ中に、ソースリージョンのキャパシティの指定された割合に合わせて、ターゲットリージョンの Kubernetes ポッドをスケールします。 Amazon Elastic Container Service (Amazon ECS) リソーススケーリング実行ブロック – ソースリージョンのキャパシティの指定された割合に合わせて、ターゲットリージョンの ECS タスクをスケールします。 リージョン切り替えは、30 分ごとにリソース設定と AWS Identity and Access Management (IAM) の許可をチェックすることで、プランを継続的に検証します。実行中、リージョン切り替えは各ステップの進行状況をモニタリングし、詳細なログを提供します。実行ステータスは、リージョン切り替えダッシュボードと、実行の詳細ページの下部を通じて確認できます。 コストと信頼性のバランスをとるのに役立つよう、リージョン切り替えは、スタンバイリソースを柔軟に準備できる機能を提供します。リージョン切り替えのスケーリング実行ブロックを使用して、リカバリ中に宛先リージョンでターゲットとすることを希望するコンピューティングキャパシティの割合を設定できます。リカバリ中にトラフィックの急増が見込まれる重要なアプリケーションでは、100% を超えるキャパシティにスケールすることを選択できます。また、割合を低く設定すると、全体的な実行時間を短縮するのに役立ちます。ただし、スケーリング実行ブロックのいずれかを使用してもキャパシティが保証されるわけではなく、実際のリソースの可用性はリカバリ時における宛先リージョンのキャパシティに依存することにご留意ください。可能な限り最良の結果を得るために、リカバリプランを定期的にテストし、スタンバイリージョンで適切な Service Quotas を維持することをお勧めします。 ARC リージョン切り替えには、企業およびリージョン全体のリージョン切り替えプランのステータスをモニタリングするために使用できるグローバルダッシュボードが含まれています。さらに、現在のコンソールリージョン内の実行のみを表示するリージョンレベルの実行ダッシュボードがあります。このダッシュボードは、各リージョン全体で高可用性を実現するように設計されているため、運用イベント中に使用できます。 リージョン切り替えを使用すると、リージョン切り替えプランを含むアカウントとは別のアカウントでリソースをホストできます。プランが、プランをホストしているアカウントとは異なるアカウントのリソースを使用する場合、リージョン切り替えは executionRole を使用して crossAccountRole を引き継ぎ、それらのリソースにアクセスします。さらに、リージョン切り替えプランは AWS Resource Access Manager (AWS RAM) を使用して一元管理し、複数のアカウント間で共有できるため、組織全体でリカバリプランを効率的に管理できます。 仕組みを見てみましょう リージョン切り替えプランを作成および実行する方法を説明します。このデモは 3 つの部分で構成されています。まず、リージョン切り替えプランを作成します。その後、ワークフローを定義します。最後に、トリガーを設定します。 ステップ 1: プランを作成する AWS マネジメントコンソール の Application Recovery Controller のセクションに移動します。左側のナビゲーションメニューで [リージョン切り替え] を選択します。その後、 [リージョン切り替えプランを作成] を選択します。 プランに名前を付けたら、 [マルチリージョンリカバリアプローチ] (アクティブ/パッシブまたはアクティブ/アクティブ) を指定します。[アクティブ/パッシブ] モードでは、2 つのアプリケーションレプリカが 2 つのリージョンにデプロイされ、トラフィックはアクティブなリージョンにのみルーティングされます。パッシブリージョンのレプリカは、リージョン切り替えプランを実行することでアクティブ化できます。 その後、 [プライマリリージョン] と [スタンバイリージョン] を選択します。オプションで、 [必要な目標復旧時間 (RTO)] を入力できます。サービスはこの値を使用して、リージョン切り替えプランの実行にかかる時間に関するインサイトを、希望する RTO との関係で提供します。 [プラン実行 IAM ロール] を入力します。これは、実行中にリージョン切り替えが AWS サービスを呼び出すことを許可するロールです。選択したロールに、サービスによって呼び出されるための許可が付与されており、ARC が動作するために必要な最小限の一連の許可が含まれていることを確認します。詳細については、ドキュメントの IAM 許可のセクション をご覧ください。 ステップ 2: ワークフローを作成する 2 つの [プランの評価ステータス] の通知が緑色になったら、ワークフローを作成します。開始するには、 [ワークフローを構築] を選択します。 プランを使用すると、リージョン切り替え実行ブロックを使用してアプリケーションを復旧する特定のワークフローを構築できます。複数のアプリケーションまたはリソースがアクティブ化するリージョンにリカバリする順序をオーケストレートするために、順次または並行して実行される実行ブロックを含むワークフローを構築できます。プランは、特定のリージョンをアクティブ化または非アクティブ化できるようにするこれらのワークフローで構成されます。 このデモでは、グラフィカルエディタを使用してワークフローを作成します。ただし、ワークフローを JSON で定義することもできます。この形式は、オートメーションや、ワークフロー定義をソースコード管理システム (SCMS) や AWS CloudFormation などの Infrastructure as Code (IaC) ツールに保存する場合に適しています。 [ワークフロービルダー] のタイトルの横にある対応するタブを選択すると、 [設計] ビューと [コード] ビューを切り替えることができます。JSON ビューは読み取り専用です。グラフィカルエディタを使用してワークフローを設計し、JSON に相当するものをコピーして IaC プロジェクトファイルと一緒に保存しました。 リージョン切り替えは、30 分ごとに評価を開始し、リカバリ戦略を検証します。ワークフローで定義されたすべてのアクションが実行時に成功するかどうかを定期的にチェックします。このプロアクティブな検証では、アカウントおよびリージョン全体の IAM 許可やリソースの状態など、さまざまな要素を評価します。これらの依存関係を継続的にモニタリングすることで、リージョン切り替えは、リカバリプランの実行可能性を維持し、実際の切り替えオペレーションに影響が及ぶ前に潜在的な問題を特定するのに役立ちます。 ただし、テストされていないバックアップは信頼できるバックアップではないのと同様に、テストされていないリカバリプランは真に検証済みとみなすことはできません。継続的な評価は強固な基盤を提供しますが、プランの有効性を検証し、実際のリカバリ時間を把握するとともに、チームがリカバリ手順に精通しているようにするために、テストシナリオで定期的にプランを実行することを強くお勧めします。この実践的なテストは、ディザスタリカバリ戦略における信頼性を維持するために不可欠です。 ステップ 3: トリガーを作成する トリガーは、作成したワークフローをアクティブ化する条件を定義します。これは、一連の CloudWatch アラームとして表現されます。アラームベースのトリガーはオプションです。手動トリガーでリージョン切り替えを使用することもできます。 コンソールのリージョン切り替えページから、 [トリガー] タブを選択し、 [トリガーを追加] を選択します。 プランで定義した各リージョンについて、 [トリガーを追加] を選択し、リージョンをアクティブ化するトリガーを定義します。 最後に、リージョン切り替えがリージョンのアクティブ化をトリガーするために使用するアラームとその状態 ([OK] または [アラーム状態]) を選択します。 これで、リージョン切り替えを使用してリージョンを切り替えるプランの実行をテストする準備が整いました。アクティブ化するリージョン (ワークフローのターゲットリージョン) からプランを実行し、その特定のリージョンのデータプレーンを使用することが重要です。 AWS コマンドラインインターフェイス (AWS CLI) を使用してプランを実行する方法は次のとおりです: aws arc-region-switch start-plan-execution \ --plan-arn arn:aws:arc-region-switch::111122223333:plan/resource-id \ --target-region us-west-2 \ --action activate 料金と利用可能なリージョン リージョン切り替えは、すべての商用 AWS リージョンで、プランごとに 70 USD/月でご利用いただけます。各プランには最大 100 個の実行ブロックを含めることができます。また、親プランを作成して最大 25 個の子プランをオーケストレートすることもできます。 マルチリージョンリカバリソリューションの構築と維持に費やすエンジニアリングの労力を直接見てきた私は、お客様にとって、リージョン切り替えがこのプロセスの自動化にどのように役立つのかを目にするのを楽しみにしています。ARC リージョン切り替えの使用を開始するには、 ARC コンソールにアクセスして、最初のリージョン切り替えプランを作成してください 。リージョン切り替えの詳細については、 Amazon Application Recovery Controller (ARC) のドキュメント にアクセスしてください。また、マルチリージョンアプリケーションのためのリージョン切り替えの使用に関するご質問は、AWS アカウントチームまでお問い合わせください。 マルチリージョンアプリケーションの回復力を高めるためにリージョン切り替えをどのように使用しているのかについて、ぜひお聞かせください。 – seb 原文は こちら です。

教育業界において生徒一人ひとりに最適化された学習体験の提供や、教員の業務効率化が重要な課題となっています。近年の生成 AI の登場は、これらの課題に対する有効なソリューションとして期待されています。特に生成 AI を取り巻く技術は目覚ましい発展を遂げており、教育分野での活用可能性はますます拡大しています。こうした状況を踏まえて、2025 年 6 月 25 日・26 日に開催された AWS Summit Japan 2025 において生成 AI 技術を活用した教育業界向けのソリューションのデモ展示をいたしました。AI エージェントを活用した「Education AI Assistant」と、RAG を用いて個別最適な学習計画を作成する「Teaching Plan Personalizer (TP2)」の 2 つのデモを通じて、現在の生成 AI 技術が教育分野でどのような可能性を秘めているかをご紹介しました。 当日は教育業界の関係者を中心に多くの来場者の皆様にお越しいただき、熱心にご覧いただくとともに、活発な議論を交わすことができました。また教育機関での活用だけでなく、企業内研修や人材育成の観点からも高い関心をお寄せいただき、今回のデモの幅広い応用可能性を実感いたしました。 本ブログでは、Summit 会場にてご紹介したデモの詳細を解説し、現在の生成 AI 技術が個別最適な学習の実現にどのように貢献できるかを、より多くの皆様にお伝えしたいと思います。以下では、2 つのデモの展示内容について詳しくご紹介いたします。 図 1: AWS Summit Japan 2025 教育チーム出展ブースの当日の様子。 デモ展示 1 : Education AI Assistant Education AI Assistant は教員が利用するシステムを想定して開発されたデモです。主に 2 つの機能を持ち、1 つは教育ダッシュボード画面に埋め込まれた成績データ分析エージェント機能で、もう 1 つは教材作成に特化したエージェント機能です。またこれらがマルチエージェントシステムとして動作するチャット画面も実装しました。これらはいずれも AI エージェントという技術を使って実現されています。AI エージェントは単にテキストを生成するだけでなく、ツールを関連づけることでタスクに対して適切なツールを選択し自律的に考え実行をします。Education AI Assistant は教育業界の課題に対する、AI エージェントの仕組みを用いたソリューションデモとなっています。 以下では成績データ分析エージェントおよび教材作成エージェントの詳細をご紹介します。 図 2 : Education AI Assistant のアーキテクチャ図。 成績データ分析エージェント 解決したい課題 個別最適な学習を実現する上で、学習者のデータに基づいた現状の把握が欠かせません。そのため学習者の成績や学習履歴といったデータを収集することがまずは重要になります。データを集めたのちに、データを適切に分析し解釈し次のアクションに繋げてようやくデータの価値が生まれます。しかしこのようなデータ分析はスキルや経験を要する作業です。 生成 AI を活用したソリューションアプローチ 上記課題を踏まえて、今回のデモでは生成 AI を用いてデータ分析を実行する機能を実装しました。成績データの保存されたデータベースに対して生成 AI が自然言語から SQL 文を生成し、SQL クエリを実行します。AWS の生成 AI サービスである Amazon Bedrock には RAG 機能を実装するための Amazon Bedrock ナレッジベース という機能があり、自然言語から構造化データを取得する機能をサポートしています。この機能を活用することで、データ分析が可能となります。ユーザーがデータ分析を開始するボタンを押すと、AI エージェントにデータ分析に関するリクエストが送られます。AI エージェントはデータ分析のプランを立てます。そしてそれに基づきナレッジベースを使って自然言語から適切な SQL クエリを生成し実行します。十分に分析が完了するまで必要な SQL クエリの生成・実行を AI エージェントは繰り返します。こうしてデータ分析が完了すると、最後に人が読んでわかりやすい形式に文章として分析結果を生成します。（図 3） 図 3 : 成績データ分析エージェントのデモ。ユーザーはまず生徒名でデータをフィルタリングする。その後、分析を行うボタンをクリックすると AI エージェントが呼び出される。AI エージェントは自身が考えたプランに従って成績データに対し SQL 分析を実行する。最終的な分析結果が、基本情報・成績推移・強み・課題といった項目に分かれて表示される。 成績データ分析エージェントがもたらす価値 AI エージェントと自然言語クエリを組み合わせることで、SQL 文の生成やクエリの実行、さらにクエリの結果に基づいた更なるクエリの実行を生成 AI が自律的に実施します。これにより必ずしも高度なデータ分析スキルがなくとも、生徒のデータからインサイトを得ることができます。分析クエリを AI エージェントが得られた結果に基づいて考えるため、定型的な分析のフローよりも柔軟な分析が可能になります。さらに今回のデモでは、得られた結果から次に取り組むべきアクションの提案まで表示させています。データを分析し結果を解釈し次のアクションに繋げるという一連のフローをサポートする機能になっている点も本デモのポイントとなります。 アーキテクチャ・技術的詳細など 図 4 : 成績データ分析エージェントの構成。構造化 RAG のナレッジベースと、SQL 静的解析ツールのアクショングループを紐づけている。 成績データ分析エージェントの実装では、Amazon Bedrock のエージェント機能である Amazon Bedrock Agents を利用しています。また、自然言語から SQL クエリを生成する部分では構造化データに対するナレッジベースを利用しています。これはデータソースとして Amazon Redshift をサポートしているため、成績データを Amazon Redshift に保存しています。また生成されるクエリの精度を高める工夫として SQL 静的解析ツールをアクショングループとして作成しています。アクショングループとは Bedrock Agents が使えるツールのことで、実装は AWS Lambda を用いています。SQL 静的解析ツールでは、SQL の文法チェックやデータベーススキーマ（テーブル名、カラム名など）との整合性の検証を行い、実行前に SQL クエリの正確性を確保しています。これらアクショングループやナレッジベースをエージェントに紐づけることでエージェントはタスクに応じて適切なツールを選択し実行します。 発展/展望 今回のデモでは生徒の成績データを対象にデータ分析を行い、クラス全体の傾向を掴んだり個別最適な学習に活かせることをお見せしました。今回は成績データを Amazon Redshift に保存していましたが、実際には Amazon Relational Database Service (Amazon RDS) などその他のデータベースに保存されていることも考えられます。AI エージェントが利用可能なツールの情報や仕様をやり取りするプロトコルとして MCP (Model Context Protocol) があります。利用したい API や実行したいアクションを MCP Server として構築することで、AI エージェントが利用できるようになります。AWS サービスに接続するための MCP Server も公開されており、例えば Amazon Aurora や Amazon DynamoDB などのデータベースに AI エージェントがアクセスできます。このように Amazon Redshift 以外のデータソースにも自然言語クエリを実行できるツールを作成することができます。こうしたものをエージェントに紐づけることで多様なデータソースに対して分析可能な AI エージェントが実装可能です。また活用すべきデータは成績データにとどまりません。出席状況や体調に関わるデータなどもユースケースに応じては活用すべきです。他にも授業の様子など生徒の活動記録といった非構造化データも活用の余地があります。このように今後の発展として、様々な角度から生徒の状況を理解するためにさらに多様なデータを扱える AI エージェントの実現が挙げられます。 教材作成エージェント 次に Education AI Assistant のもう一つの機能である、教材作成エージェントをご紹介します。 解決したい課題 個別最適な学習を提供する上で、生徒一人ひとりに合った教材の作成は欠かせません。2025 年 6 月にデジタル庁・総務省・文部科学省・経済産業省から公開された 教育 DX ロードマップ においても子供たちを取り巻く背景として、自分らしい学びの実現に課題があると言及されています。生徒の興味関心や理解度に応じて、教材の内容や形式を柔軟に変えられることができれば個別最適学習の実現に近づきます。一方で一人ひとりに対して教材をカスタマイズすることは時間のかかる作業であり現実的とはいえません。 生成 AI を活用したソリューションアプローチ 上記の課題に対して、生成 AI を用いた教材作成機能のデモを開発しました。生成 AI を用いることで個別の要件も柔軟に教材に反映させることができます。一方で単に生成 AI に教材を作らせようとすると、知識に限界があったり計算間違いの可能性を孕んでいたりと課題があります。そこで本デモでは AI エージェントに Web 検索や計算(四則演算)のツールを組み合わせることを考えました。これにより、生成 AI が知らないトピックでも Web 検索によって知識を獲得でき、計算が必要な教材作成では計算ツールを使って正しい結果を得ることができます。さらに学習指導要領に則った教材を作成するために、学習指導要領をデータソースとした RAG 機能も組み合わせています。 図 5 : 教材作成エージェントのデモ。ここでは英語の会話の練習をテーマに設定している。また詳細な指示として、「直近 1 ヶ月の日本の行事やイベントをテーマにすること」と指示を与えている。指示が AI エージェントに送られ、AI エージェントは要件を満たす教材作成を行う。行事やイベントの情報を取得するために Web 検索をしながら英語の教材が生成されている。 教材作成エージェントがもたらす価値 教材作成エージェントを用いることで、要点を押さえつつ生徒一人ひとりに合わせた教材が作成可能です。特に教員はいくつかの入力項目を埋めるだけであとは自動的に作成されるため、カスタマイズされた教材を効率よく作成できます。また四則演算ツールは生成された問題の検算や計算問題の解答生成に活用できます。 Web 検索ツールを使うことでリアルタイムな情報やより専門的な情報にもアクセスすることができます。加えて学習指導要領の RAG と組み合わせる事で、問うべきポイントを重視した教材生成も可能になります。このように生成 AI にいくつかのツールを組み合わせることで教材の質向上にもつながっています。最後に、本デモでは出力形式を HTML のソースコードとしました。これをレンダリングすることでそのまま教材として使えるようなビジュアルでのアウトプットを可能にしています。 アーキテクチャ・技術的詳細など 図 6 : 教材作成エージェントの構成。ナレッジベースを利用した学習指導要領に対する RAG と、四則演算などのアクショングループを組み合わせている。 教材作成エージェントの実装においても、Bedrock Agents を利用して AI エージェントを構築しました。利用可能なツールとして日時取得・四則演算・Web 検索といったツールを組み合わせています。これらは AWS Lambda 上で実装され、アクショングループとしてエージェントに紐づけています。また、学習指導要領をデータソースとした RAG に関しては Amazon Simple Storage Service (Amazon S3) にデータを保存しています。ナレッジベースを利用して、ベクトル化したデータを Amazon OpenSearch Serverless に取り込んでいます。教材作成エージェントは必要に応じてナレッジベースを使ってベクトル検索を実行し、学習指導要領のコンテキストを取得し、それを基に適切な教材を生成します。 発展/展望 本デモではデータソースとして学習指導要領を用いましたが、これに加えて教科書や問題集のデータとの連携が今後の発展として考えられます。教科書と連携すれば生徒が実際に勉強した内容に沿った問題作成が可能になります。また問題集や過去問題などと連携することで類題生成も可能になり、試験対策に活用可能です。また、実際のデモではスーパーバイザーエージェントを介したデータ分析エージェントと教材作成エージェントのコラボレーションも実装しました。データ分析エージェントがデータ分析を実施して得意分野や苦手分野を把握し、結果に基づいて教材作成エージェントが得意を伸ばす教材や苦手をフォローする教材を作成する、というフローが実現できます。 デモ展示 2: Teaching Plan Personalizer (TP2) 図 7 : TP2 のデモ。生徒の習熟度や家庭環境などを選択する。その後指導計画を作成するためのプロンプトが生成される。生成されたプロンプトを確認したのちに、指導計画作成のボタンを押す。生成 AI がデータソースを参照しながら指導内容や指導の手立てを生成する。 解決したい課題 「 教育データの利活用に係る論点整理(中間まとめ)概要 」において、きめ細かい指導・支援が目的として掲げられています。教員・子供・保護者視点で個別最適化された指導や支援は理想的である一方で、教員視点で以下の課題が発生しうると考えています。 生徒ごとの状況を加味した指導・支援計画作成の負荷増大 学年、科目ごとの習熟度や家庭環境など生徒ごとにきめ細やかに対応する必要が出てくる 教員による計画の品質差異 新任と中堅教員では経験による計画内容の品質や計画作成に割く時間に差異が出る 中堅以上の教員のレビュー時間(回数)増加 個別最適化された計画ごとのチェックを中堅以上の教員が担う可能性があり現状よりレビューする時間と回数が増加する 生成 AI を活用したソリューションアプローチ (TP2) TP2 は特別支援学校向けソリューションで生徒に応じたカスタマイズ可能な UI/UX に加えて、上記の指導計画に関する課題解決のため以下のソリューションアプローチをとっています。 学習指導要領の RAG 検索により一定水準の品質を保った計画作成を支援 学習指導要領を RAG のデータソースとして利用する事で一定水準の計画内容を担保。また、学年と科目ごとのメタデータフィルタリングを利用することで関連性の高いドキュメントを検索。 Excel 及び校務データの生徒情報と RAG 検索結果を元に個別最適化された計画を生成 指導要領の内容に加えて生徒ごとの習熟度や家庭環境などの情報を追加することで個別最適化された計画を生成 AI が作成。また、計画作成だけでなく手立ての評価(確認)ポイントも提示。 一定水準の品質を保った計画生成により中堅以上の教員の負担軽減 生成 AI を活用して計画の品質を向上することで中堅教員のレビュー時間と回数を軽減。 TP2 がもたらす価値 上記のソリューションアプローチにより個別最適化された指導計画作成の効率化に加えて、計画作成にあたり根拠となった指導要領の内容も UI 上に表示されるため、指導要領の検索時間も短縮可能です。また、現場では計画の紙ベースの保管も加味しExcel ファイルのデータ表示と編集をUI実装しており、TP2 で生成された計画内容だけでなく元の内容も加筆修正可能です。 TP2 を利用する中で計画のフォーマットや記載すべきポイントなど教員ごとに生成 AI へ指示する Prompt をカスタマイズしたいニーズも視野に入れ、Prompt の内容の表示と編集可能なUI実装となっています。 アーキテクチャ・技術的詳細など 図 8 : TP2 のアーキテクチャ図。 Amazon Bedrock ナレッジベース、&nbsp; Amazon Aurora Serverless と Amazon S3 で RAG を構成しています。今回のブースデモではデータ量とコスト観点でベクトルデータベースとして Amazon Aurora Serverless を利用しましたが、TP2 は AWS Cloud Development Kit (AWS CDK) で IaC 化されておりユースケースに応じて Amazon OpenSearch Serverless をデプロイ時に選択することも可能です。 指導計画と評価の生成は Amazon Bedrock と Amazon Nova を利用しています。AWS と校務システムが連携できた場合を想定して擬似校務データベースとして Amazon DynamoDB に生徒情報を格納し、Excel 記載の学生の氏名から家庭環境などの情報を取得しています(学籍番号など一意になる情報推奨)。 フロントエンドは React を利用して、 Amazon CloudFront と Amazon S3 でシングルページアプリケーション (SPA) をデプロイしています。 発展/展望 個別最適化された計画生成の精度向上の観点では、卒業生などの蓄積された指導計画のデータソースを活用することで精度向上が期待できます。例えば、同傾向の卒業生のデータをもとに効果が高い計画を生成できる可能性があると考えます。 TP2 は個別最適化された指導計画生成に焦点を置いていますが、評価の高かった過去の計画をもとに生成 AI で作成した計画のレビューを追加実装することで中堅以上の教員の負荷軽減も可能だと考えています。 まとめ 本ブログでは AWS Summit Japan 2025 にて教育業界向けブースで展示をした 2 種類のデモについてご紹介しました。 今回ご紹介したデモが、教育業界の課題解決に役立てられれば幸いです。 最後に、本ブログでご紹介したデモに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。また会場で投影しておりました資料を こちら からダウンロードいただけます。 本ブログは、 アマゾン ウェブサービス ジャパン合同会社 パブリックセクター のソリューションアーキテクト、田村健祐、小泉秀徳が執筆しました。

あらゆる業界の役員会議室で、経営幹部は重要な疑問に直面しています。 ――AI をどのように活用すれば、コスト削減とビジネスの成長を同時に実現できるのか ? AI は、すべての顧客接点を成長のきっかけに変える、変革の機会を顧客体験の責任者に提供します。AI は、まず効果的なセルフサービスを可能にし、続いて人間の介入が必要な場合にもパーソナライズされた応答とアクション推奨でエージェントをサポートすることで、カスタマージャーニーを強化します。継続的にインタラクションを分析することで、AI は一般的な問題と成功した解決策の両方のパターンを特定し、自動化システムとエージェントガイダンスを自動的に改善します。この接続されたインテリジェンスは運用計画にまで拡張され、スタッフィングとトレーニングを最適化して、すべてのチャネルでのインタラクションごとにより賢くなる統合学習システムを構築します。重要なことに、AI は複数のインタラクション間でコンテキストを維持し、切り離された接触を継続的な会話に変換して、より深い顧客関係を構築します。このように、継続的に改善されるエクスペリエンスを通じて売上を向上させ、顧客を喜ばせることができます。 しかし、顧客体験全体にわたって AI の潜在能力を最大限に実現するためには、重要な統合の課題が立ちはだかります。多くの組織では断片的なアプローチを採用し、コンタクトセンター内でケースバイケースで AI ソリューションを実装しています。この手法は的を絞った改善をもたらしますが、互いに効果的に連携しない、切り離されたツールの寄せ集めを作り出し、統合、保守、管理のコストを増加させます。あるいは、一部の企業では AI の実装をエージェント支援などの単一領域に制限し、より広範な顧客体験を向上させる機会を逃しています。これらの断片化された戦略は、しばしば導入への不安や限定的な採用につながり、組織は予測不可能なコスト、実装の複雑さ、不確実な投資収益率への懸念により、AI に完全にコミットすることをためらいます。この慎重さは、組織がインタラクションから継続的に学習する真にインテリジェントで応答性の高いシステムを構築することを妨げています。つまり、統合の複雑さ、データサイロ、予測不可能なコストによって阻まれているといえます。 そのため、これらの課題に直接対処する次世代の Amazon Connect (Amazon Connect と無制限の AI) を私たちは発表しました。 次世代の Amazon Connect Amazon Connect は、すべてのチャネルにわたり、ファーストパーティ AI を提供し、AI の使用量ではなく基本的なチャネル使用量にのみ基づいて、将来の AI 機能が継続的に利用できるバンドル型の AI 価格設定を提供します。Amazon Connect の次世代版により、あらゆる規模の組織が、すべてのタッチポイントで AI を活用しやすくなり、コストが原因の妥協をすることなく、顧客体験の改善に集中できるようになります。Amazon Connect を選択することで、AI ジャーニーが本格的に始まり、都度、追加の意思決定、実装作業、コストを必要とせずに、AI モデル、トレーニング手法、新しいエージェント機能の継続的な改善から自動的に恩恵を受けられます。このアプローチにより、AI 導入における財務的な障壁を排除しながら、テクノロジーの進化に伴い、顧客体験を最先端に保つことができます。 Amazon Connect は AWS 上に構築されており、複数のサードパーティソリューションを必要とすることなく、お客様の環境内で AI サービスをネイティブに活用できます。Amazon Bedrock の最先端モデルを活用、コンタクトセンター全体のエクスペリエンスにシームレスに統合されます。コンタクトセンターのリーダーは、初期のセルフサービスでのやり取りからエージェントサポート、顧客の感情やトレンドを明らかにする会話分析まで、カスタマージャーニー全体を通じてこれらのネイティブ AI 機能を簡単に有効化、最適化、管理できます。この統合された製品は、セルフサービス、エージェント支援、分析などの異なる機能に対するシステムの分断という一般的な問題を解消し、すべての顧客接点を、売上向上と継続的な学習による顧客満足度向上の機会に変えます。 チャネルベースの料金体系による、カスタマーエクスペリエンス全体にわたる包括的な AI 機能 次世代の Amazon Connect は、シンプルで予測可能な料金体系を通じて AI ネイティブ機能をあらゆる規模の組織が誰でもアクセスできる環境を提供しています。組織はもはや、どのインタラクションが AI 活用に値するかについて、コストと複雑さを潜在的な利益と比較検討して困難な決定を下す必要がありません。新しいバンドル料金は AI の使用量ではなく、基盤となるチャネル使用量（音声通話時間やチャットセッションの使用量など）に直接結び付けられており、以下の機能の無制限利用が含まれているため、組織はコスト主導のトレードオフなしに、すべてのタッチポイントで AI 拡張されたカスタマーエクスペリエンスを自信を持って提供できます。 顧客によるセルフサービス : 25 以上の言語で、顧客のニーズに適応し待機時間を短縮する AI を活用したセルフサービス体験を、音声およびデジタルチャネル全体で大規模に提供します。 エージェント支援 : Amazon Q in Connect は顧客の問題を検出し、顧客情報、ナレッジリポジトリ、および Web コンテンツに基づいてパーソナライズされた応答と推奨アクションを提供します 会話分析 : 機械学習を活用した会話分析と品質管理機能により、通話とチャットのトランスクリプトを検索し、感情を分析し、問題を特定し、エージェントのパフォーマンスを監視します。SMS と電子メールについては近日公開予定です 画面記録 : 会話分析とパフォーマンス評価と組み合わせることで、スーパーバイザーは問い合わせの品質とエージェントのパフォーマンスを監視、評価、改善できます コンタクト後の要約 : AI を活用した顧客とのやり取りの要約により、エージェントのアフターコールワークを短縮します。これらの要約は通話が転送される際にコンテキストを保持し、顧客が再度電話をかけてきた際に即座に背景情報を提供し、繰り返しの質問を排除します パフォーマンス評価 : すべての顧客とのやり取りをレビューして学習し、コーチングの機会を特定し、ベストプラクティスを発見し、コンプライアンスリスクを軽減し、評価をより効率的に完了します 予測、キャパシティプランニング、スケジューリング : AI を活用した人員管理により、スプレッドシートと推測作業を排除し、リアルタイムで変化するパターンに調整しながら、スーパーバイザーの介入なしにエージェントのリクエストを自動的に処理します Amazon Connect のお客様の声 次世代の Amazon Connect に対し、業界を問わず組織からポジティブな反応をいただいています。 Amazon Connect で、6 つの地域にまたがる VMO2 のコンタクトセンターを変革し、10,000 人以上のエージェントをサポートしています。Amazon Connect の機能を使用することで、顧客のやり取りパターンを特定し、初回コンタクトでの解決率を向上させ、セルフサービスを好む顧客のデジタルのチャネルへの適合を増加させることができました。さらに、生成 AI を活用したコンタクト後の要約を実装して手作業を削減し、一貫した自動化されたプロセスを通じてコンプライアンスと品質管理を強化しています。苦情解決の迅速化、NPS スコアの向上、処理時間の短縮といった結果を達成し、同時にエージェントの効果性を向上させています。私たちのエージェントも、より力を与えられ、より効果的だと感じています。業界をリードする顧客体験を提供し、カスタマーサービスのさらなる卓越性を達成するために、Amazon Connect でさらに多くの AI 活用による可能性が広がることを楽しみにしています。 – Alan Stott 氏、Virgin Media O2 カスタマーコンタクト部門ディレクター Genpact はこの Amazon Connect のローンチと、大規模な顧客体験を革新するその能力を称賛します。AWS Premier ティアパートナーとして、私たちの戦略的コラボレーションは継続的に深まっており、Amazon Connect を活用してクライアントをエージェント AI の未来に向けて加速させることにわくわくしています。Amazon Connect 上に構築された Genpact のソリューションは、10,000 人以上のカスタマーサービスエージェントを抱える 150 社以上において、平均処理時間を最大 35% 削減し、顧客満足度スコアと初回コール解決率を向上させることが実証されています。Amazon Connect と Genpact の深い業界専門知識を組み合わせることで、私たちは共に企業により大きな価値を提供し、顧客体験を改善し、リスクを軽減することができます。 – Sameer Dewan 氏、Genpact 金融サービス担当グローバルビジネスリーダー グローバルなデジタル変革企業として、富士通は包括的な技術製品、ソリューション、サービスを提供しています。富士通の 8 つのグローバルデリバリーセンターの 1 つである富士通コスタリカでは、当社のコンタクトセンターは 5 年間、完全に Amazon Connect で運用されており、450 社以上の企業の顧客にサービスを提供する 5,000 人以上のエージェントを管理しています。私たちは、ライブエージェント支援による顧客インタラクションとセルフサービス機能、 Amazon Connect のオムニチャネルコミュニケーション、Connect の会話分析、自動評価、キャパシティプランニング、エージェントスケジューリングにより運用を大幅に改善しました。例えば、イントラデイ予測で 96% 以上の精度を実現し、パイロットプログラムでは各国固有の労働法への準拠を改善しました。また、自動化されたパフォーマンス評価により品質保証において 15% の効率向上を実現し、インタラクション中のリアルタイムな顧客感情に基づいてエージェントが行動を取れるようにすることで顧客満足度を 10% 向上させています。次世代の Amazon Connect だけが提供する機能は、AI を活用した顧客体験をグローバルに標準化し継続的に最適化するのに役立ち、 すべてのコミュニケーションチャネルにわたる、あらゆるインタラクションでの強力な機能を提供してくれることを嬉しく思います。 – Alex Sanchez 氏、富士通 グローバルオファリングテクノロジー・GDC ネットワーク責任者 DXC では、テクノロジーをシームレスに機能させ、組織が最大限の可能性を実現できるよう支援しています。Amazon Connect を活用した DXC Customer Experience は、効率性の創出、運用の最適化、顧客体験の向上により、コンタクトセンター分野に革命をもたらします。この変革により、クライアントが最も得意とすることに集中する時間が生まれ、大幅なコスト削減と高いチーム満足度につながります。次世代の Amazon Connect により AI 強化エージェント機能を拡張し、クライアントがさらに優れた成果を上げられるよう支援できることを嬉しく思います。 – Chris Drumgoole 氏、DXC Technology グローバルインフラストラクチャサービス部門プレジデント AI を活用したカスタマーエクスペリエンスのビジョン実現に向けて この次世代の Amazon Connect は、組織が AI の潜在能力を最大限に活用することを妨げてきた統合の課題と断片的なアプローチに直接対処します。AI の使用量ではなく、基盤となるチャネル使用量のみに価格を連動させ、無制限の使用と包括的な AI 機能を統合して提供することにより、Amazon Connect は、AI の採用を制限してきた散在するツールの統合、予測不可能なコスト、実装の複雑さを排除します。あらゆる規模の組織が、これまで障壁となっていた財政的制約や技術的制限なしに、カスタマーエクスペリエンス全体で AI を活用しながら、コストを削減し、自信を持ってビジネスを成長させることができるようになりました。 Amazon Connect 内で直接提供される自動更新や新機能により、お客様のコンタクトセンターは追加の実装作業を必要とすることなく、カスタマーサービステクノロジーの最先端を維持します。組織はコーディングを必要とせずに高度な AI 機能を実装でき、技術的な障壁なしに戦略的な改善を行うことができます。これにより、顧客の期待と AI テクノロジーが進化する中でも、お客様の顧客体験は継続的に改善され、将来にわたって運用を維持できます。また、技術的な統合ではなくビジネス成果に集中することができます。 AWS アカウントを登録あるいはコンソールにアクセス して、ワンクリックで次世代の Amazon Connect を開始しましょう。Amazon Connect のコア機能を引き続き使用したい組織は、そのまま使用を続けることができます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

こんにちは！AWS ISV/SaaS ソリューションアーキテクトをしているさばみそです。 2025 年 7 月 17 日に「SaaS ビジネス成功の鍵 – メトリクス設計からつなげるデータドリブンな SaaS 組織への転換」と題したイベントを AWS Startup Loft Tokyo で開催いたしました。 Software as a Service (SaaS) モデルでのビジネスが従来のパッケージ販売のモデルと比べて大きく異なる点は、ストック型で売上が積み上がり続けるという点です。この特性から、契約を獲得してからできるだけ長く使ってもらえるか、つまり LTV（Life Time Value、顧客生涯価値）をできるだけ高めることが重要です。「売ってからが始まり」であり、利用者がプロダクトから得られる価値を継続して提供する必要があります。 では、「利用者がプロダクトから得られる価値」を利用者が正しく得られているかを、どの様に判別/計測すれば良いでしょうか？ その際に必要となってくるのが、プロダクトにおけるメトリクス設計です。 本イベントでは、パッケージビジネスから SaaS ビジネスへの移行が加速する中、多くの企業が直面している SaaS プロダクトにおけるメトリクス設計と活用の課題に焦点を当て、実践的な知見を共有させていただきました。 イベント概要 近年、多くの企業様がパッケージビジネスからSaaSビジネスへと移行する中で、適切なメトリクス設計の重要性が増しています。本セミナーでは、以下のような課題に対する解決策を、実践的な内容とともにご紹介させていただきました。 SaaS ビジネス特有のメトリクスの理解 リカーリングビジネスの健全性測定 データを活用したプロダクト戦略の立案 チーム間でのKPI認識の統一 セッション紹介 ゲストセッション 小城 久美子 様：プロダクト戦略の成果を測る NSM とは？ その必要性と策定方法 [資料] 「プロダクトマネジメントのすべて」の共著者である小城久美子様より、プロダクト戦略の成果を効果的に測定する NSM（North Star Metric）について具体的な策定方法と重要なポイントが紹介されました。NSM の選定には、ビジョンや顧客価値、事業収益との連動性、AARRR（Pirate Metrics）との整合性、測定可能性など、5つの重要な基準があることを解説いただきました。特に注目すべきは、NSM の作成ステップが「価値の言語化」「価値提案の道筋整理」「NSM の選定」という 3 つの明確なフローで示されており、実践的なアプローチを学ぶことができる点です。プロダクトマネージャーやビジネス戦略担当者にとって、成果指標の設定に悩む課題を解決するヒントが詰まった、実務で即活用できる内容となっています。 お客様事例 株式会社ExaMD 牛越 洵也 様 : メトリクスで価値を可視化する データ駆動プロダクト開発の実践 [資料] 株式会社ExaMD 牛越様より、株式会社ExaMD が取り組む、データ駆動型のプロダクト開発アプローチについて、具体的な事例とともに紹介いただきました。医療分野における多彩なプロダクト展開を基に、データ分析基盤の構築からメトリクス設計、そして実際に得られた成果まで、体系的に解説されています。特に、医療という専門性の高い領域でいかにデータを活用し、プロダクトの価値を可視化していくのか、その実践的なノウハウが詰まっています。医療×テクノロジーの最前線で、データドリブンな意思決定がどのように行われ、どのような成果を生み出しているのか、プロダクト開発に携わる方必見の内容となっています。 NSM – KPI ツリー作成ワークショップ体験版 AWS 福本より、SaaS ビジネスの成功に不可欠なメトリクス設計を 1.5 時間で実践的に学べるワークショップを実施しました。エレベータピッチの作成から始まり、インプットメトリクスの洗い出し、因果関係の発見と NSM（North Star Metric）の探索、そして KPI ツリーの作成まで、段階的に理解を深められる構成となっています。特に、ユーザー価値を起点としたメトリクス設計のアプローチをとることによって、利用者がプロダクトから得られる価値と向き合うことができます。 パートナーセッション 株式会社アンチパターン ⽮ヶ崎 哲宏 様：SaaS メトリクスの取得と分析⼿法 [資料] 株式会社アンチパターン 矢ヶ崎様より、SaaS ビジネスにおける効果的なメトリクス収集と分析手法を包括的に解説をしていただきました。特に SaaS アプリケーションプレーンとコントロールプレーンにおける多様なデータポイント（行動履歴、API ログ、アクティビティログなど）の活用方法について具体的にお話しいただきました。顧客の利用状況を「幅（Breadth）」「深さ（Depth）」「頻度（Frequency）」「効率（Efficiency）」という複数の観点から分析し、データレイクから BI ツールまでの一貫した分析基盤の構築方法も紹介されています。さらに、生成 AI と MCP サーバーを組み合わせた最新の分析手法まで網羅されており、SaaS ビジネスの成長に不可欠なデータ活用の取り組みについても学んでいただける内容となっております パートナーセッション 株式会社primeNumber 坂本 竜輝 様：データカンパニーが実践する SaaS ビジネスを加速させるデータ分析 [資料] 株式会社primeNumber 坂本様より、「あらゆるデータをビジネスの力に変える」をミッションとする primeNumber が実践する、最新のデータ分析アプローチを紹介いただきました。従来の課題であったデータ出力の遅延や探索的分析の困難さを解消し、データエンジニアからビジネスリーダーまで、多様なユーザーが効果的にデータを活用できる次世代の分析基盤について解説いただいております。特に、自動スケーリングが可能でセルフサービス型の分析環境の構築方法や、運用効率の向上からイノベーション加速まで、実践的なユースケースを交えた内容となっています。 AWS で実現するデータドリブン型組織 [資料] 最後に、AWS 安達より、AWS サービスを活用した SaaS メトリクスの収集・分析基盤の構築方法と、データドリブン型組織への転換に向けたベストプラクティスを紹介させていただきました。セッションの中では、従来の手作業による CSV 分析からクラウド BI を活用した自動化された最新のデータ分析基盤への進化についても解説しました。また、AWS を活用したモダンデータアーキテクチャの実現方法や、データ推進チームの発足、チャンピオン制度の導入など、組織文化の転換に向けた具体的なステップについても紹介しました。 まとめ 本セミナーでは、SaaS ビジネスにおけるメトリクス設計の重要性から具体的な実装方法まで、包括的な内容をお届けしました。また、AWS では本イベントのような支援だけでなく、 AWS SaaS 支援プログラム を通じて、日本の SaaS ビジネスのさらなる成長のための様々な支援も行っており、 こちら からご応募いただけます。 皆様の SaaS ビジネスの成功に向けて、本セミナーの内容が少しでもお役に立てば幸いです。 このブログの著者 安達 翔平 (さばみそ) アマゾン ウェブ サービス ジャパン合同会社 ISV/SaaS ソリューションアーキテクト Web 系の自社サービス、請負開発を経験後、ISV/SaaS 領域のお客様をメインにアーキテクトしてます。 趣味は、サウナ、ロックフェス、スノーボードです。ホームサウナは、ニューウィング錦糸町です。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025年8月25日（月）19:00より、 AWS Startup Loft Tokyo にて「 AWS Database 開発チーム Meet-up 2025 」を開催いたします。Amazon Aurora DSQL、Aurora Limitless Database、DynamoDBの各開発チームよりサービスの特徴や最新のアップデート、そしてチーム構成などを直接対話しながらご説明します。通常のプレゼンテーション形式とは異なり、各セッションでは質疑応答の時間を十分に設け、参加者の皆様が開発チームと技術的な議論や意見交換ができる形式となっています。データベース技術に関心をお持ちの方、AWSデータベースサービスの詳細について知りたい方は、ぜひこの機会にご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年7月28日週の主要なアップデート 7/28(月) Amazon Connect Contact Control Panel (CCP) がリフレッシュされたデザインと操作感を提供開始 Amazon Connect の Contact Control Panel (CCP) が Cloudscape Design System を採用した新しいデザインに更新されました。コールセンターのオペレーターが使う画面の色やボタンのデザインが統一され、より直感的で使いやすくなりました。従来と同じ操作感を保ちながら視覚的に改善されているため、追加のトレーニングは最小限に抑えたうえでオペレーターの作業効率向上が期待できます。全ての AWS リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS IoT SiteWise が多変量異常検知を導入 AWS IoT SiteWise で多変量異常検知機能が一般提供開始となりました。従来は機械学習の専門知識が必要だった産業機器の異常検知が、コードを書くことなく自動化できます。タービンやコンプレッサーなどの複数のセンサーデータを同時に監視し、故障リスクを早期発見できるため、予防保全による効率化とダウンタイム削減に貢献します。バージニア北部、アイルランド、シドニーリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Connect の UI ビルダーが改良された UX/UI をリリース Amazon Connect の UI builder で新しいユーザーインターフェースが提供開始されました。Step-by-Step Guide の各ステップを作成する際の複雑さが軽減され、より直感的にワークフローを構築できるようになりました。これまでより簡単に動的データの受け渡しや、ユーザーが入力したデータの保存が可能です。カスタム変数を定義して複数のフィールドやコンポーネント間で共有できるため、管理者がエージェントや顧客向けに柔軟で強力な体験を作成しやすくなります。東京リージョンを含む 11 のリージョンで利用可能です。 7/29(火) パーティション GPU を搭載した Amazon EC2 G6f インスタンスの一般提供開始のお知らせ Amazon EC2 で G6f インスタンスが一般提供されました。NVIDIA L4 Tensor Core GPU を使った初の GPU パーティショニング機能を備えたインスタンスで、GPU を 1/8 まで分割して利用できます。従来の G6 インスタンスと比べて大幅なコスト削減が可能になり、リモートワークステーションや ML 研究、ゲームストリーミングなどの用途に最適です。東京リージョンをはじめ複数リージョンで利用開始できます。 AWS Backup が Aurora DSQL マルチリージョン復元ワークフローを改善 AWS Backup で Amazon Aurora DSQL のマルチリージョンクラスターのリストアワークフローが改善されました。従来は複数リージョンでのリストア作業が複雑でしたが、今回のアップデートにより単一リージョンからリストアを開始するだけで AWS Backup が全リージョンの処理を自動管理します。リストアの時間短縮と信頼性向上により、障害時のビジネス継続性が大幅に改善されます。詳細は こちらの Blog 記事をご参照ください。 Amazon EC2 Auto Scaling がライフサイクルフックの通知ターゲットとして AWS Lambda 関数を追加 Amazon EC2 Auto Scaling のライフサイクルフックで、AWS Lambda 関数を直接通知先として指定できるようになりました。従来は EventBridge や SNS などの中間サービスが必要でしたが、Lambda 関数を直接呼び出せるためインフラ構成がシンプルになります。例えば、スケールイン時にインスタンス終了前にログをダウンロードしたり、データベース接続を適切にクローズするなどのカスタム処理を実行できます。詳細は こちらのドキュメントをご参照ください。 7/30(水) Amazon CloudFront が新しいオリジンレスポンスタイムアウト制御を導入 Amazon CloudFront で新しいオリジンレスポンスタイムアウト制御機能が提供開始されました。従来は最初のパケットや後続パケットの待機時間のみ設定可能でしたが、今回のアップデートで全パケットとリトライを含む完全なレスポンス完了タイムアウトが設定できるようになりました。また Amazon S3 オリジンでは 30 秒のデフォルトから任意の値にカスタマイズ可能です。メディアストリーミングや API 呼び出しなどレイテンシが重要なワークロードでより細かい制御ができ、ユーザー体験の向上が期待できます。詳細は こちらの Developer Guide をご参照ください。 Database Insights が Aurora Limitless データベースのフリート監視をサポート CloudWatch Database Insights が Aurora Limitless PostgreSQL データベースのフリート監視に対応しました。これまではインスタンスレベルでの監視のみでしたが、今回のアップデートでフリート全体の健全性を統合ダッシュボードから確認できるようになりました。Aurora クラスター、RDS インスタンス、Aurora Limitless PostgreSQL データベースを１つの画面で一元管理でき、運用効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora MySQL 3.10 (MySQL 8.0.42 互換) が一般提供開始 Amazon Aurora MySQL 3.10 が一般提供開始となりました。MySQL 8.0.42 互換ではセキュリティ強化やパフォーマンス改善が行われています。最大の変更点は、ストレージ容量の上限が従来の 128 TiB から 256 TiB に倍増したことです。これにより大規模なデータベースワークロードを単一クラスター内で管理できるようになりました。また、メモリ内リレーログ最適化により、バイナリログレプリケーションの性能が向上し、コミット遅延が削減されています。全ての Aurora MySQL 対応リージョンで利用可能です。7/30(水) 7/31(木) Amazon Q Developer CLI がカスタムエージェントを発表 Amazon Q Developer CLI でカスタムエージェント機能が提供開始されました。従来は一般的な質問対応のみでしたが、今回のアップデートでコードレビューやトラブルシューティングなど専門的なタスクに特化したエージェントを作成できるようになります。設定ファイルで使用ツールや動作を定義し、プロジェクト固有の設定やチーム間での共有も可能です。開発作業の効率化とコンテキスト切り替えの削減が期待できます。詳細は こちらの Blog 記事をご参照ください。 AWS Lambda レスポンスストリーミングが 200 MB のレスポンスペイロードをサポート AWS Lambda response streaming のレスポンスペイロード上限が従来の 20 MB から 200 MB に拡大されました。これにより、リアルタイム AI チャットや Web アプリケーションで、大容量データを直接 Lambda 内で処理できるようになります。以前は大きなファイルを扱う際に S3 を経由する必要がありましたが、画像豊富な PDF や音楽ファイルなども直接ストリーミング処理が可能です。詳細は こちらのドキュメントをご参照ください。 Amazon DocumentDB Serverless が一般提供開始 Amazon DocumentDB Serverless が正式リリースされました。これは MongoDB 互換のドキュメントデータベースで、アプリケーションの需要に応じて自動でキャパシティをスケールする仕組みです。従来はピーク時の利用量を想定してキャパシティを事前設定する必要がありましたが、今回のアップデートでリソース状況に応じた柔軟な課金となり、最大 90 % のコスト削減が可能になります。特に利用量が変動するアプリケーションや、数千のデータベースを管理する SaaS 事業者に最適です。詳細は こちらの Blog 記事をご参照ください。 Amazon Q Developer が多言語サポートを拡張 Amazon Q Developer が多言語サポートを拡張し、日本語を含む 8 つの言語に対応しました。マネージメントコンソール 上で日本語を使って AWS リソースの監視や運用、トラブルシューティングができるようになります。これまで英語での対応のみであったため、言日本語と英語訳の作業が必要でしたが、今回の日本語対応において、Amazon Q Developer を効率的に運用活用できるのが大きなメリットです。詳細は こちらをご参照ください。 8/1(金) Amazon CloudWatch が OpenSearch PPL と SQL の自然言語クエリ生成機能を開始 Amazon CloudWatch Logs Insights で、自然言語を使った OpenSearch PPL と SQL のクエリ生成機能が開始されました。これまでクエリ言語の知識が必要だったログ分析が、「1時間あたりのエラー数を教えて」といった日常的な英語で簡単に実行できるようになります。生成 AI がクエリを自動作成するため、専門知識がなくてもログから素早く洞察を得られます。東京リージョンなど 10 のリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 で EC2 インスタンスの強制終了がサポートされました Amazon EC2 で、停止処理中にフリーズしたインスタンスを強制終了できる force terminate 機能が追加されました。これまで OS の凍結やハードウェア問題で shutting-down 状態から動かなくなったインスタンスは AWS サポートに依頼する必要がありましたが、この機能により自分で強制終了できるようになります。まず通常のシャットダウンを試み、失敗した場合に強制終了を実行します。これにより vCPU クォータや Elastic IP アドレスなどのリソースをすぐに回収でき、開発作業の継続性が向上します。 AWS Directory Service が Managed Microsoft AD 向け Hybrid Edition を開始 AWS Directory Service で Managed Microsoft AD の Hybrid Edition が提供開始されました。これまでオンプレミスの Active Directory を AWS に移行するには複雑な作業が必要でしたが、新機能により既存の AD ドメインを AWS クラウドに簡単に拡張できるようになります。レプリケーションやメンテナンスは AWS が自動処理し、既存のアクセス制御やグループポリシーもそのまま利用可能です。EC2 や FSx、RDS などの AWS サービスとの統合も容易で、運用負荷を大幅に削減しながらクラウド移行を進められます。詳細は こちらの Blog 記事をご参照ください。 本当に暑い日が続いておりますので、水分補給を適宜行い、体調に気をつけてお過ごしください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。8月に入り、生成AI分野の進化がますます加速する日々が続いています。特に気になっているのは、AWSが本番環境での安全かつ柔軟なエージェント運用を実現する Amazon Bedrock AgentCore や、従来難しかった大規模ベクトルデータの長期保存( S3 )とリアルタイム検索( OpenSearch )を低コストで両立する Amazon S3 Vectors × OpenSearch Service の連携強化、AWS のAIエージェントSDK「Strands Agents」などです。生成AI活用に不可欠な基盤技術や開発環境の進化も続き、国内外のユーザーやパートナーによる導入事例もどんどん増えてきており2025年後半も「責任あるAI」「安心して使える生成AI」の実現に向けて、AWSがどのような取り組みや進化を続けているのか。生成AIの最新トレンドを、今号でもぜひキャッチアップしてください。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース ブログ記事「AWS サーバレスサービスで実現するラーメン山岡家のキッチンオペレーション効率化」 株式会社丸千代山岡家様が AWS Summit Japan 2025 での展示内容をもとに、従来の厨房タイマー装置が抱えていた視認性の問題や熟練職人への依存といった課題を、AWS Fargate 、 Amazon ElastiCache Serverless 、Amazon Bedrock などのサーバレスサービスを活用してどのように解決したかを詳しく解説しています。記事では、導入によりスタッフのスキル習得期間が 500 日から 350 日に短縮され、提供時間も平均 30 秒削減されるなど、具体的な成果を示しながら、外食産業におけるデジタルトランスフォーメーションの実践例として紹介しました。さらに、Amazon Bedrock を活用した生成AI による調理順序の最適化など、より高度な機能の開発も進められています。 ブログ記事「SDV (ソフトウェア定義車両)向け AUTOSAR 開発を Amazon Q Developer で加速」 このブログでは、Amazon Q Developer が AUTOSAR (AUTomotive Open System ARchitecture: 車載ソフトウェア開発の国際標準規格) 開発をどのように効率化できるかについて説明しています。SDV (ソフトウェア定義車両) 向けの開発において、Amazon Q Developer を開発者のコーディング作業を支援する強力なAIツールとして紹介しています。具体的には、LED制御やCANメッセージ送信などの一般的な車載ソフトウェア開発のユースケースで、コードの自動生成やユニットテストの作成を効率化できます。開発者の報告によると、初期開発が25%速くなり、生産性が最大40%向上したとのことです。 ブログ記事「株式会社 BTM 様の AWS 生成 AI 活用事例：Amazon Bedrock と Strands Agents を活用したシステム調査の自動化により、調査時間を大幅短縮し運用業務の効率化を実現」 株式会社BTM様が Amazon Bedrock とオープンソース AI エージェント SDK である Strands Agents を活用してシステム調査を自動化し、業務効率を大幅に改善した事例を紹介します。複数システムの管理における調査業務や関係者間のコミュニケーションに課題を抱えていたBTM様は、生成AIと MCP（Model Context Protocol）を組み合わせたAIエージェントシステムを構築しました。このシステムでは、Slackをユーザーインターフェースとして活用し、Amazon Bedrock の Claude 4.0 Sonnet を基盤モデルとして採用し、その結果、従来半日かかっていたシステム調査時間を最短10分に短縮し、PMのトラブルシュート工数を95%削減することに成功しました。さらに、開発工数も90%削減するなど、業務効率化を実現しています。 ブログ記事「[開催報告]AWS Summit Japan 2025 生成AIエージェントハッカソン」 6月25日～26日に開催された AWS Summit Japan 2025 において「使いたおして『○○』を実現するAIエージェント爆誕祭」をテーマに、AIエージェントを徹底的に活用することで人間固有の価値や目的を明確にすることを目指したハッカソンが開催されました。全国から14チームが予選に参加し、最終的に6チームが決勝に進出しました。ほぼ全てのチームが開発に Coding Agent を活用し、短期間にも関わらず商用レベルの完成度の高いソリューションを実現していました。最優秀賞を受賞したWhiteBoxお酒同好会の「KanpAI」をはじめ、各チームが Bedrock、Lambda、Connect、RDS 等のAWSサービスを効果的に組み合わせた実装を行い、AIエージェント時代の新しい可能性を示しました。このハッカソンは、AIが開発を支援する「AIがAIを作る」時代の到来を明確に示す重要なイベントとなりました。 サービスアップデート Amazon Bedrock Data AutomationがDOC/DOCXとH.265ファイルをサポート Amazon Bedrock Data Automation (BDA) の機能が大幅に拡張され、DOC/DOCXファイルとH.265形式の動画ファイルの処理に対応するようになりました。これまではWordファイルを処理する際、一旦PDFに変換する必要がありましたが、DOC/DOCX対応により直接処理が可能となり、テキスト抽出や分析のワークフローが効率化されます。また、高圧縮・高画質なH.265形式の動画ファイルへの対応により、より効率的な動画分析が実現可能になりました。これらの新機能は、フランクフルト、ロンドン、アイルランド、ムンバイ、シドニー、米国西部（オレゴン）、米国東部（バージニア北部）の7つのリージョンで利用できます。 Amazon Bedrock が米国西部 (北カリフォルニア) リージョンで利用可能に Amazon Bedrock が、米国西部 (北カリフォルニア) リージョンで利用可能となりました。Amazon Bedrockは、1つのAPIで主要なAI企業が提供する高性能な大規模言語モデルなどを利用できる、フルマネージドサービスです。セキュリティ、プライバシー保護、責任あるAIの概念が組み込まれており、生成AIアプリケーション開発に必要な機能を幅広く提供します。 Fractional GPU搭載のAmazon EC2 G6fインスタンスが一般提供開始 NVIDIA L4 Tensor Core GPUを採用した新しいGPUインスタンス「G6f」を発表しました。最大の特徴は、GPU partitioning によりGPUリソースを8分の1単位で細かく分割して利用できる点です。これにより、フルGPUの性能が不要で余分な費用が発生していた機械学習やグラフィックス処理において、必要な分だけのリソースを確保でき、コストを最適化できます。北米、ヨーロッパ、アジアパシフィックなど、東京を含めた主要なリージョンで利用可能となっています。 Amazon Q Developer CLIがカスタムエージェントを発表 Amazon Q Developer CLIに新たにカスタムエージェント機能が追加されました。この機能により、コードレビューやトラブルシューティングなどの特定のタスクに特化したCLIエージェントをカスタマイズすることが可能になりました。開発者は設定ファイルを通じて、エージェントが使用できるツールやプロンプト、必要なコンテキストを定義できます。さらに、ファイルシステムへのアクセス権限の細かな制御や、静的・動的なコンテキストの指定も可能です。このカスタムエージェントはプロジェクト固有で設定でき、チームメンバー間で共有することも、個人の開発タスク全般で使用することも可能です。 Amazon Q Developerが多言語対応を拡大 Amazon Q Developerの言語対応を大幅に拡充しました。AWS マネジメントコンソール、AWS Console モバイルアプリ、さらにTeamsやSlackといった主要なチャットツールで、フランス語、ドイツ語、イタリア語、日本語、韓国語、中国語、スペイン語、ポルトガル語など、多数の言語に対応するようになりました。使い方は簡単で、ユーザーが希望する言語で Q Developer に問い合わせるだけでシステムが自動的に使用言語を認識し、同じ言語で応答します。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、麻辣醤にハマっています。

本記事は米国時間 8 月 1 日に公開された「 Kiro Pricing Update + Waitlist Invites Coming Soon 」を翻訳したものです。Kiro の最新情報は、 https://kiro.dev/ &nbsp;をご覧ください。 Kiro への素晴らしい関心に感謝いたします！コミュニティからのフィードバックは素晴らしく、一つのことが明確になりました。皆さんはもっと多くを望んでいます。ウェイトリストに登録しながらも待機している方々は自分自身で Kiro をテストする機会を望み、すでに Kiro を使用している方々はアクセス量をコントロールする方法をもっと求めています。そこで、この核心に迫る 2 つの更新をコミュニティに向けてお知らせします。 ウェイトリストへの招待を開始します ：来週 (8/4) から、ウェイトリストに登録された開発者の方々をオンボーディングし、より多くの方々に Kiro を直接体験する機会を提供します。 新料金プランが登場します ：初期プレビューユーザーのワークフローとニーズから学んだことに基づき、今月後半に 料金プラン を導入し、追加容量にお支払いいただくか、Kiro を無料で引き続き使用するかの選択肢を提供します。 ウェイトリストの最新情報 お待たせいたしました。間もなく招待の送信を開始いたします！来週 (8/4) から、ウェイトリストに登録された方々にサインアップコードをメールで送信します。これらのコードを使用してオンボーディングし、Kiro が提供するすべてを体験できます。今月後半に料金プランが開始されると、自動的に 2 週間の無料トライアルにアクセスでき、料金プランを決定する前に、Kiro が開発ワークフローにどのように適合するかを十分に探索する時間があります。ウェイトリストはかなり迅速に進む予定です。 料金の最新情報 プレビュー期間は、実際の使用パターンをより理解するのに役立ち、Kiro のコアアクションである Spec と Vibe に関する開発者のニーズに合わせて料金体系を構築することになりました。開発者が Spec で素晴らしいことを達成するのを見てきました。 開発者は、通常多くの Vibe 対話を必要とするタスクを効率的に完了できるようになりました。これは Kiro の重要な価値 – 開発者が要件と設計仕様を生成し、それらをタスクごとに実行して本番環境対応のコードを作成する、仕様駆動型の開発アプローチ – を示します。開発者が Kiro で構築する 2 つ目の方法は Vibe を通じてです。これは、AI エージェントとの構築に馴染みのある会話型アプローチを好む方々のためのエージェント型チャット体験です。 私たちの料金プランは、Kiro との旅のあらゆる段階で開発者とチームをサポートするように設計されています。AI の開発を始めたばかりの方も、複雑なアプリケーションを構築する大規模チームをリードしている方も、私たちの料金モデルは無料トライアルからエンタープライズレベルの使用まで、あなたの成長をサポートするように設計されています。この新しい構造は、開発者の働き方を観察することで形作られ、成長するコミュニティにとってより直感的な体験を創出しています。 主なポイントは以下の通りです。 2 週間の無料トライアル ：すべての新規ユーザーは、Vibe（50リクエスト）と Spec（100リクエスト）の両方にアクセスできる 2 週間のトライアルを受けられ、誰もが Kiro の完全な機能セットを体験できます。 新しい階層構造 ：Free、Pro（月額 20 ドル）、Pro+（月額 40 ドル）、Power（月額 200 ドル）プランを含む、より柔軟な階層システムを導入し、開発者がニーズに最も適した階層を選択できるようにします。 Vibe と Spec リクエストの個別割り当て ：開発者が Kiro の Vibe と Spec 機能を使用する異なる方法を認識し、有料プランでそれぞれに個別の割り当てを提供します。 恒久的な無料ティア ：月間 50 回の Vibe リクエストにアクセスできる無料プランを維持し、開発者がコスト障壁なしで Kiro の機能を引き続き探索できるようにします。 柔軟な超過使用への対応 ：すべての有料プランで、Vibe リクエスト 1 回あたり 0.04 ドル、Spec リクエスト 1 回あたり 0.20 ドルの追加使用が可能で、Kiro が最も必要なときに壁にぶつからないことを保証します。 Vibe リクエストには、コードの説明やバグ修正などのチャットベースの対話が含まれ、Specリクエストには、Kiro の構造化された開発ワークフロー内でのタスクの実行が含まれます。使用パターンを継続的に評価し、コミュニティにより良いサービスを提供するために制限を調整する場合がありますが、常にユーザーのニーズを優先します。 既存プレビューユーザーの皆様へ ローンチ以来、Kiro の無料プレビューに参加してくださった皆様に感謝します。GitHub や Discord でのフィードバックは、料金モデルだけでなく、Kiro の体験全体を形作る上で非常に貴重でした。この数週間、Kiro でのビルディングを楽しんでいただけたことを願っています。 今後数週間は引き続きKiroを無料で使用できます。今月後半に容量を増やすために有料プランを選択するか、無料プランを継続するかを選択する必要があります。これらのプランは、コミュニティから見られた使用パターンとフィードバックに直接基づいて設計されているため、あなたの作業方法に合った選択肢があると確信しています。 今後の展望 ウェイトリスト からユーザーのオンボーディングを開始するにあたり、すべての人にとってスムーズな移行を約束します。今後数日間で、Kiro から最大限の価値を引き出すためのオフィスアワーを開催します。(訳註 : 日本での開催は未定です) 正式リリース日の詳細については続報をお待ちください。移行に関する質問については、 料金情報と FAQ を確認するか、 Discord でコミュニティディスカッションに参加してください。皆さんが何を構築するのか楽しみにしています！

7 月 31 日、Amazon DocumentDB サーバーレスの一般提供についてお知らせします。これは Amazon DocumentDB (MongoDB 互換) の新しい設定であり、アプリケーションの需要に基づいてコンピューティングとメモリを自動的にスケールします。Amazon DocumentDB サーバーレスは、事前の契約や追加コストなしでデータベース管理を簡素化し、ピークキャパシティのプロビジョニングと比較して最大 90% のコスト削減を実現します。 Amazon DocumentDB サーバーレスでは、リードレプリカ、 パフォーマンスインサイト 、I/O 最適化、およびその他の Amazon Web Services (AWS) のサービスとの統合など、Amazon DocumentDB と同じ MongoDB 互換 API および機能を使用できます。 Amazon DocumentDB サーバーレスでは、約 2 ギビバイト (GiB) のメモリ、対応する CPU、およびネットワークの組み合わせである DocumentDB キャパシティユニット (DCU) で測定される新しいデータベース設定が導入されました。アプリケーションで実行されるデータベース操作から発生する CPU、メモリ、ネットワークなどのリソースの使用状況を継続的に追跡します。 Amazon DocumentDB サーバーレスは、データベースの可用性を損なうことなく、需要に応じて DCU を自動的にスケールアップまたはスケールダウンします。既存のクラスターでのプロビジョニンドインスタンスからサーバーレスへの切り替えは、インスタンスタイプを追加または変更するのと同じくらい簡単です。この変更にはデータの移行は必要ありません。詳細については、「 Amazon DocumentDB サーバーレスの仕組み 」を参照してください。 Amazon DocumentDB サーバーレスの主なユースケースと利点には次のものがあります。 変動するワークロード – Amazon DocumentDB サーバーレスでは、定期的なプロモーションイベント、開発およびテスト環境、使用量が急速に増加する可能性がある新しいアプリケーションなど、突然のトラフィックの急増に対応できます。また、 Amazon DocumentDB の組み込みベクトル検索 および動的に呼び出されるエージェンティック AI ワークフローを処理するためのサーバーレス適応性の恩恵を受ける エージェンティック AI アプリケーションを構築することもできます。 マルチテナントワークロード – Amazon DocumentDB サーバーレスを使用して、データベースフリート全体で個々のデータベースキャパシティを管理できます。エンタープライズアプリケーションや Software as a Service (SaaS) ベンダーのマルチテナント環境で、数百または数千のデータベースを管理する必要はありません。 多目的ワークロード – オンライントランザクション処理 (OLTP) アプリケーションなど、クエリトラフィックが定期的に急増するワークロードでは、読み取りキャパシティと書き込みキャパシティのバランスを取ることができます。クラスター内の Amazon DocumentDB サーバーレスインスタンスのプロモーション階層を指定することで、リーダーインスタンスがライターインスタンスとは独立してスケールして追加の負荷を処理できるようにクラスターを設定できます。 安定したワークロードには、Amazon DocumentDB プロビジョンドインスタンスの方が適しています。事前定義された量のメモリ、CPU パワー、および I/O 帯域幅を提供するインスタンスクラスを選択できます。プロビジョンドインスタンスを使用するときにワークロードが変化した場合は、ライターとリーダーのインスタンスクラスを手動で変更する必要があります。オプションで、サーバーレスインスタンスを既存のプロビジョンド Amazon DocumentDB クラスターにいつでも追加できます。 Amazon DocumentDB サーバーレスの動作 Amazon DocumentDB サーバーレスの使用を開始するには、 Amazon DocumentDB コンソール にアクセスしてください。左のナビゲーションペインで、[ クラスター ] と [ 作成 ] を選択します。 「 Amazon DocumentDB クラスターの作成 」ページで、「 インスタンスベースのクラスタータイプ 」を選択し、「 サーバーレス インスタンス設定」を選択します。最小キャパシティと最大キャパシティの DCU を選択できます。Amazon DocumentDB サーバーレスは Amazon DocumentDB 5.0.0 以降でサポートされており、キャパシティ範囲は 0.5～256 DCU です。 監査やパフォーマンスインサイトなどの特徴量を使用する場合は、特徴量ごとに DCU を追加することを検討してください。詳細については、 Amazon DocumentDB サーバーレススケーリング設定 をご覧ください。 サーバーレスインスタンスを既存のプロビジョンドクラスターに追加するには、プロビジョンドクラスターを選択するときに [ アクション ] メニューの [ インスタンスの追加 ] を選択します。3.6 や 4.0 などの以前のバージョンのクラスターを使用する場合は、まずクラスターをサポートされているエンジンバージョン (5.0) にアップグレードする必要があります。 [ インスタンスの追加 ] ページの [ DB インスタンスクラス ] セクションで、作成する新しいサーバーレスインスタンスごとに [ サーバーレス ] を選択します。別のインスタンスを追加するには、[ インスタンスの追加 ] を選択し、必要な新しいインスタンス数に達するまでインスタンスを追加し続けます。[ 作成 ] を選択します。 フェイルオーバー操作 を実行して、DocumentDB サーバーレスインスタンスをクラスターライターにすることができます。また、 インスタンスのクラスを変更 するか、 Amazon DocumentDB インスタンスを削除 してそれらをクラスターから削除することで、残りのプロビジョンド Amazon DocumentDB インスタンスを DocumentDB サーバーレスインスタンスに変換できます。 これで、 AWS CloudShell を使用して Amazon DocumentDB クラスターに接続できるようになりました。[ クラスターに接続 ] を選択すると、AWS CloudShell ランコマンド 画面が表示されます。[ 新しい環境名 ] に一意の名前を入力し、[ 作成して実行 ] を選択します。 プロンプトが表示されたら、Amazon DocumentDB クラスターのパスワードを入力します。Amazon DocumentDB クラスターに正常に接続されました。いくつかのクエリを実行してドキュメントデータベースの使用に慣れることができます。 詳細については、AWS ドキュメントの「 Amazon DocumentDB サーバーレスを使用するクラスターの作成 」および「 Amazon DocumentDB サーバーレスの管理 」を参照してください。 今すぐご利用いただけます Amazon DocumentDB サーバーレス は、Amazon DocumentDB 5.0 以降で、新しいクラスターと既存のクラスターの両方で利用できるようになりました。DCU 使用量の 1 秒あたりの定額料金のみをお支払いいただきます。料金の詳細とリージョンでの可用性の詳細については、 Amazon DocumentDB の料金表ページ をご覧ください。 Amazon DocumentDB コンソール でこれらの新特徴量をお試しいただき、フィードバックを AWS re:Post for Amazon DocumentDB に送信するか、通常の AWS サポート担当者を通じて送信してください。 – Channy 原文は こちら です。

※ Part1 は こちらの記事 を御覧ください 2025 年 6 月 25 日・26 日に開催された AWS Summit Japan 2025 において、鉄道業界向けの 2 つのソリューションを展示いたしました。本記事では、展示ブースの内容と来場者の皆様からいただいたご意見をご報告いたします。 展示概要 今回の展示では、鉄道業界が直面する課題に対応する 2 つのアプローチをご紹介しました。 展示内容 生成 AI エージェントによる鉄道業界の業務改善　〜鉄道 AI エージェント 〜 複数の AI エージェント連携による部門横断型の業務支援 AI エージェントと MCP を用いた業務効率支援　〜 Strands Agents と MCP を組み合わせた効率的なリサーチ業務 〜 鉄道運行制御システムのクラウド活用に向けたアプローチ IEC 61508 をはじめとした国際規格に準拠しながら、クラウドの特性を活かした実装方法の解説 鉄道連動装置を例にした具体的な実装手法のご紹介 ※ Part1 は こちらの記事 を御覧ください、この記事では Part2 からご紹介します。 2. 鉄道運行制御システムのクラウド活用アプローチ 今年の AWS Summit Japan では、社会インフラの安全性確保とクラウド活用の両立というテーマについて、鉄道連動装置を例にした具体的な実装アプローチをご紹介させていただきました。鉄道関係者の皆様はもちろん、車両/重機製造業や通信事業者、公共研究機関のお客様など多くの方々にご来訪いただき、機能安全システムのクラウド実装への高い関心を実感いたしました。 &nbsp; 本展示では、まず鉄道業界をはじめとする社会インフラ事業者が直面している課題について議論を行いました。設備の老朽化に伴う維持管理負担の増大、人口減少下での安全性維持、そして安全維持ノウハウの暗黙知化といった課題が、多くの事業者様に共通する喫緊の課題として浮かび上がっています。 &nbsp; これらの課題に対する解決策として、私たちは AWS クラウドを活用した新しいアプローチを提案いたしました。その中核となるのが、IEC 61508 をはじめとした国際規格で定められている安全性を電子装置で確保する「機能安全」の考え方を取り込み、これらの国際規格に準拠しながら、クラウドの特性を活かした実装方法について解説させていただきました。 鉄道の信号制御システムである連動装置での実装例では、3 つの重要な技術要素を組み合わせた構成をご紹介しました。第一に、異なるアベイラビリティゾーンへの論理処理機能の分散配置による空間的な冗長性の確保です。第二に、Intel、AMD、Graviton といった異なる CPU アーキテクチャの活用による設計の多様性の実現です。そして第三に、3 重系による論理演算と多数決処理による安全性確保の仕組みです。 &nbsp; また、IEC 61508 で要求される 16 フェーズの安全ライフサイクルについても、AWS サービスを活用した効率的な管理方法をご紹介しました。AWS Config による要件適合性の自動検証、Infrastructure as Code による構成管理の厳密化、AWS Fault Injection Simulator を用いた継続的な安全性検証など、具体的な実装方法について解説させていただきました。 機能安全分野での AWS クラウド実績としては、 Swift Navigation様による事例 を取り上げ、ISO 26262 認証取得において AWS クラウドを活用した具体的な成功例をお示ししました。同社は、AWS の複数のアベイラビリティゾーンを活用したフォールトトレランス設計により安全性要求に応えることに成功しています。 &nbsp; 本展示を通じて、AWS クラウド活用による運用コストの最適化、保守業務の効率化、安全技術ノウハウの体系化といった具体的なメリットをご理解いただけたのではないかと考えています。特に、従来はオンプレミス環境でしか実現できないと考えられていた高い安全性要件に対して、クラウドでも適切な設計とアプローチにより対応しうることをご説明いたしました。 私たちは、今回ご紹介した知見が他の産業分野にも波及し、社会インフラ全体のデジタルトランスフォーメーションの加速に貢献できると考えており、この分野における業界関係者の皆様からの忌憚ないご意見をいただければと考えております。 当日来訪いただいた方はもちろん、この記事でご興味を持っていただいた皆様と検討の機会がありましたら、いつでもご遠慮なく連絡いただけますと幸いです。 まとめ AWS Summit Japan 2025 での鉄道展示ブースには、2 日間で多くの皆様にご来場いただきました。マルチ AI システムは実用性の高いソリューションとして評価をいただき、鉄道運行制御システムのクラウド活用アプローチは体系的なアプローチとして関心をお寄せいただきました。 今回の展示を通じて、鉄道業界のデジタル変革に向けた具体的な道筋を示すことができました。今後も皆様のご意見を参考に、より実用的で安全性の高いソリューションの開発を進めてまいります。