複雑なデータ取得システムを開発する手間をかけることなく、正確かつ最新の情報を提供する AI アプリケーションを構築することを想像してみてください。10 月 28 日は、 Amazon Bedrock の Nova モデル向けの新しい組み込みツールである Web Grounding の一般提供が開始されたことを皆さんにお知らせします。 Web Grounding は、ターンキー 検索拡張生成 (RAG) オプションを開発者に提供します。このオプションは、Amazon Nova 基盤モデル がプロンプトの内容に基づいて関連する最新情報をいつ取得して組み込むのかをインテリジェントに判断できるようにします。これは、ハルシネーションの削減と精度の向上を目的とするもので、引用されたパブリックソースをコンテキストとして組み込むことでモデル出力をグラウンディングするために役立ちます。 開発者が Web Grounding を使うべき状況 開発者は、最新の事実情報にアクセスする必要があるアプリケーションや、十分な引用が行われた応答を提供する必要があるアプリケーションを構築するときに Web Grounding の使用を検討すべきです。この機能は特に、製品やサービスに関する最新情報を提供する知識ベースのチャットアシスタントや、事実確認やソース検証が必要になるコンテンツ生成ツールといったさまざまなアプリケーションで真価を発揮します。また、複数の最新ソースからの情報を合成する必要があるリサーチアシスタントや、精度と検証可能性が極めて重要なカスタマーサポートアプリケーションにも最適です。 Web Grounding は、AI アプリケーションのハルシネーションを低減する必要があるときや、ユースケースで透明性のあるソース属性が必要になるときに特に便利です。Web Grounding は情報の取得と統合を自動的に処理するため、複雑な RAG 実装の管理ではなく、アプリケーションの構築に集中したい開発者のための効率的なソリューションです。 使用の開始 Web Grounding は、推論時における情報の取得と処理を実行するために、サポートされている Amazon Nova モデルとシームレスに統合します。これは、複雑な RAG パイプラインを構築して維持する必要をなくすとともに、情報の取得元を実証するソース属性も提供します。 Web Grounding を有効にした状態で、Python を使用して Amazon Bedrock Converse API を呼び出す Nova Premier に質問する例を見てみましょう。 まず、通常の方法で AWS SDK for Python (Boto3) を使用して Amazon Bedrock クライアントを作成しました。これには、グッドプラクティスとしてセッションを使用しています。セッションは、設定をグループ化して再利用可能にするために役立ちます。次に、BedrockRuntimeClient を作成します。 try: session = boto3.Session(region_name='us-east-1') client = session.client( 'bedrock-runtime') それから、Amazon Bedrock Converse API ペイロードを準備します。ここでは、「role」パラメータが「user」(AI 生成応答の場合は「assistant」になります) に設定されており、メッセージがアプリケーションのユーザーからのものであることを示しています。 このデモでは、「現在の AWS リージョンとそれらの場所を教えてください」という質問を選びました。 この質問は、応答に最新の情報が必要になることから意図的に選択しました。これは、Amazon Nova が最新の知識が必要であると判断したときにどのように Web Grounding を使用して検索を自動的に呼び出すのかを実証するために役立ちます。 # Prepare the conversation in the format expected by Bedrock question = "What are the current AWS regions and their locations?" conversation = [ { "role": "user", # Indicates this message is from the user "content": [{"text": question}], # The actual question text } ] まず、Web Grounding を使用しなかった場合の出力を見てみましょう。Amazon Bedrock Converse API を呼び出します。 # Make the API call to Bedrock model_id = "us.amazon.nova-premier-v1:0" response = client.converse( modelId=model_id, # Which AI model to use messages=conversation, # The conversation history (just our question in this case) ) print(response['output']['message']['content'][0]['text']) 現在のすべての AWS リージョン とそれらの場所のリストが返されます。 今度は、Web Grounding を使ってみましょう。Amazon Bedrock Converse API に同じような呼び出しを行いますが、今回はモデルが利用できるツールの 1 つとして nova_grounding を宣言しています。 model_id = "us.amazon.nova-premier-v1:0" response = client.converse( modelId=model_id, messages=conversation, toolConfig= { "tools":[ { "systemTool": { "name": "nova_grounding" # Enables the model to search real-time information } } ] } ) 応答の処理後、モデルが Web Grounding を使用して最新情報にアクセスしたことを確認できます。出力には、思考過程を辿り、外部ソースを自動的にクエリした箇所を確認するために使用できる推論トレースが含まれています。これらの外部コールからの応答の内容は [HIDDEN] として表示されています。これは、AI システムにおける標準的な慣行で、機密情報を保護するとともに、出力サイズの管理にも役立ちます。 さらに、出力には Web Grounding がクエリしたソースに関する情報が含まれた CitationsContent オブジェクトもあります。 最後に AWS リージョンのリストを確認でき、「これらは世界中の最新かつアクティブな AWS リージョンです」というメッセージで終わっています。 Web Grounding は、最小限の労力で AI アプリケーションの信頼性と最新性を向上させることにおける大きな進歩です。正確かつ最新の情報を提供する必要があるカスタマーサービスチャットアシスタントを構築している、複数ソースからの情報を分析して合成するリサーチアプリケーションを開発している、または目的地や宿泊施設に関する最新の詳細情報を提供する旅行アプリケーションを作成しているかに関わらず、Web Grounding は、簡単に設定して使用できる便利なターンキーソリューションで、より正確で関連性の高い応答をユーザーに提供できるようにしてくれます。 知っておくべきこと Amazon Nova Web Grounding は、10 月 28 日から米国東部 (バージニア北部) でご利用いただけます。Web Grounding は、米国東部 (オハイオ) と米国西部 (オレゴン) でも近日リリース予定です。 Web Grounding には追加料金が発生します。詳細については、 Amazon Bedrock の料金ページ をご覧ください。 現在、Web Grounding を使用できるのは Nova Premier のみですが、他の Nova モデルのサポートも近々追加される予定です。 Amazon Nova を使用したことがない場合や、さらに深く掘り下げたいとお考えの場合は、自分のペースで進めることができるこちらのオンライン ワークショップ をお試しください。このワークショップでは、テキスト、画像、動画の処理のために Amazon Nova 基盤モデルと関連特徴量を効率的に使用する方法を実践的な演習を通じて学ぶことができます。 Matheus Guimaraes | @codingmatheus 原文は こちら です。

10 月 27 日週、私は AWS Shenzhen Community Day で Jeff Barr に会いました。Jeff は、世界中のビルダーが生成 AI でどのように実験しているかについて語り、これからもアイデアを実際のプロトタイプに落とし込んでいくように現地の開発者を励ましました。セッション終了後も多くの参加者がその場に残り、モデルのグラウンディングと評価、生成 AI を実際のアプリケーションに組み込む方法について話し合いました。 コミュニティビルダーたちは、Kiro をテーマにしたクリエイティブなデモ、AI 駆動の IoT プロジェクト、学生主導の実験を紹介しました。生成 AI イノベーションに対する共通の好奇心と意気込みを通じてつながる新しい開発者、学生、そして年来の Amazon Web Services (AWS) コミュニティリーダーを見ることができ、とても良い刺激になりました。 世界で最も強力なオペレーショナル AI スーパーコンピュータの 1 つである Project Rainier がオンラインになりました。Anthropic との密接なコラボレーションを通じて AWS が構築した Project Rainier は、高帯域幅、低レイテンシーのモデルトレーニングを極めて大規模に実現するために設計された新しい Amazon Elastic Compute (Amazon EC2) UltraServer と EC2 UltraCluster のアーキテクチャを使用して、 AWS がカスタム設計した Trainium2 チップ 約 50 万個をサービスに導入します。 Anthropic は Project Rainier で Claude のトレーニングと推論を既に行っており、2025 年末までに直接使用と Amazon Bedrock の全体で 100 万個を超える Trainium2 チップにスケールする予定です。アーキテクチャの詳細、デプロイに関するインサイト、UltraServer オンライン化の舞台裏動画については、「 AWS activates Project Rainier 」で発表の全文をお読みください。 11 月 3 日週のリリース 私が 10 月 27 日週注目したリリースをご紹介します。 Amazon Nova – 引用ベースのウェブ検索をリアルタイムで行うための新しい組み込みツールとして Web Grounding が追加されました。また、統合されたクロスモーダルベクトルを生成することで 検索拡張生成 (RAG) とセマンティック検索の精度を向上させる最新鋭のモデル、 Multimodal Embeddings も導入されました。どちらの機能も Amazon Bedrock でご利用いただけます。 Amazon Bedrock – TwelveLabs の Marengo Embed 3.0 が、動画、画像、音声、テキストの全体でロングフォームの動画ネイティブなマルチモーダル埋め込みに利用できるようになり、ドメイン精度も向上しました。 Stabability AI Image Services に、高解像度アップスケーリング、アウトペインティング、制御されたバリエーションのための Outpaint、Fast Upscale、Conservative Upscale、Creative Upscale の 4 つの新しいツールが追加されました。 Model Context Protocol (MCP) Proxy for AWS – SigV4 認証を使用して MCP クライアントを AWS がホストするリモート MCP サーバーに接続するクライアント側プロキシとしての一般提供が開始されました。Amazon Q Developer CLI、Kiro、Cursor、Strands Agents といったツールと連動し、読み取り専用モード、再試行ロジック、ロギングなどの安全制御を提供します。MCP Proxy for AWS はオープンソースです。 AWS GitHub リポジトリ にアクセスしてインストールや設定のオプションを確認し、リモート AWS MCP サーバーへの接続を開始できます。 Amazon Elastic Container Service (Amazon ECS) – 組み込みのリニアデプロイ戦略とカナリアデプロイ戦略 のサポートが開始されました。これらは、段階的なトラフィックシフト、小規模な本番環境スライスを使用したカナリアテスト、安全なロールバックのためのデプロイベイク時間、Amazon CloudWatch アラームベースの自動ロールバックといった機能を提供します。 Amazon DocumentDB – Amazon DocumentDB 5.0 に 新たなクエリプランナー が追加されました。このプランナーは、より的確なインデックスプランと、 $neq 、 $nin 、ネストされた $elementMatch のサポートによってクエリパフォーマンスを最大 10 倍高速化し、クラスターパラメータグループ経由でダウンタイムなしで有効化できます。 Amazon Elastic Block Store (Amazon EBS) – CloudWatch の新しいボリューム別メトリクス である VolumeAvgiOps と VolumeAvgThroughput を使用して、AWS Nitro ベースのインスタンスにアタッチされた EBS ボリュームの平均 IOPS とスループットを分単位で把握できるようになりました。これらのメトリクスは、パフォーマンス傾向を監視し、ボトルネックをトラブルシューティングして、プロビジョニングされたキャパシティを最適化するために役立ちます。 Amazon Kinesis Data Streams – 最大 10 MiB の個別レコード を送信できるようになりました。これは以前の上限の 10 倍で、より大規模な IoT、変更データキャプチャ、AI 生成のペイロードのサポートに役立ちます。 Amazon SageMaker – Unified Studio の検索結果が 追加の検索コンテキスト を提供するようになりました。このコンテキストは、一致するメタデータフィールドやランク付けの理論的根拠を提供して、データ検出における透明性と関連性を向上させます。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS VAMS と 4D Pipeline を用いた本番環境対応の 3D パイプラインの構築 – AWS Visual Asset Management System (VAMS) と 4D Pipeline を使用してスケーラブルなクラウドベースの 3D アセットパイプラインを作成するためのリファレンスアーキテクチャで、インジェスト、検証、共同レビュー、ゲーム全体での配信、視覚効果 (VFX)、デジタルツインをサポートします。 Amazon Location Service が新しい API キー制限を導入 – バンドル ID を使用するきめ細かなセキュリティポリシーを作成して、特定のモバイルアプリケーションへの API アクセスを制限できるようになりました。これは、ロケーションベースのワークロード全体でアクセスコントロールを向上させ、アプリケーションレベルのセキュリティを強化します。 AWS Clean Rooms が高度な SQL 設定をリリース – Spark プロパティとコンピューティングサイズのランタイムカスタム化に加えて、大規模な分析クエリのより迅速でコスト効率性に優れた処理のためのテーブルキャッシュをサポートする、Spark SQL ワークロードのためのパフォーマンス強化です。 AWS Serverless MCP Server がイベントソースマッピング (ESM) ツールを追加 – AWS Lambda イベントソースマッピングの設定、パフォーマンス調整、トラブルシューティングをサポートするイベント駆動のサーバーレスアプリケーション向けの機能で、AWS サーバーレスアプリケーションモデル (AWS SAM) テンプレートの生成と診断インサイトが含まれます。 AWS IoT Greengrass が AI エージェントコンテキストパックをリリース – クラウドに接続されたエッジアプリケーションのための開発アクセラレーターです。すぐさま使用できる指示、例、テンプレートを提供することで、チームがより迅速なソフトウェアの作成、テスト、フリート全体でのデプロイのために Amazon Q などの生成 AI ツールを統合できるようにします。エージェントコンテキストパックは、 GitHub リポジトリ でオープンソースとして利用できます。 AWS Step Functions が新しいメトリクスダッシュボードを導入 – 単一のコンソール内で、標準ワークフローと express ワークフローの使用状況、請求、パフォーマンスのメトリクスをステートマシンレベルで確認できるようになりました。これは、分散型アプリケーションの可視性を向上させ、トラブルシューティングを容易にします。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Builder Loft – エキスパートセッションから学び、ハンズオンワークショップに参加して、AI や新興テクノロジーを検証するとともに、他のビルダーとのコラボレーションを通じてアイデアを加速させることができる、米国サンフランシスコのコミュニティテクノロジースペースです。 開催予定のセッション を閲覧して、関心のあるイベントにぜひご参加ください。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスに参加しましょう。日程は、 香港 (11 月 2 日)、 アブジャ (11 月 8 日)、 カメルーン (11 月 8 日)、 スペイン (11 月 15 日) です。 AWS Skills Center Seattle 4 周年記念イベント – 11 月 20 日に開催される、基調講演、専門家パネル、採用担当者によるインサイト、抽選会、仮想参加オプションなどが盛りだくさんの無料公開イベントです。 AWS Builder Center に参加して、AWS コミュニティのビルダーを学び、構築し、交流しましょう。こちらで 近日開催予定の対面イベント 、 開発者に焦点を当てたイベント 、 スタートアップ向けのイベント をご覧ください。 11 月 3 日週のニュースは以上です。11 月 10 日週にお届けする次回の Weekly Roundup もお楽しみに! – Betty 原文は こちら です。

10 月 28 日、エージェンティック 検索拡張生成 (RAG) およびセマンティック検索アプリケーション向けの最先端のマルチモーダル埋め込みモデルである Amazon Nova Multimodal Embeddings をご紹介します。このモデルは Amazon Bedrock でご利用いただけます。これは、テキスト、ドキュメント、画像、動画、音声を単一のモデルを通じてサポートし、極めて高い精度のクロスモーダル検索を可能にする初の統合埋め込みモデルです。 埋め込みモデルは、テキスト、画像、音声の入力を、 埋め込み と呼ばれる数値表現に変換します。これらの埋め込みは、AI システムが比較、検索、分析できるように入力の意味を捉え、セマンティック検索や RAG などのユースケースを強化します。 組織は、テキスト、画像、ドキュメント、動画、音声コンテンツに分散している、増大し続ける非構造化データからインサイトを引き出すソリューションをますます求めています。例えば、組織には、製品の画像、インフォグラフィックとテキストを含むパンフレット、ユーザーがアップロードした動画クリップなどが存在する場合があります。埋め込みモデルは非構造化データから価値を引き出すことができますが、従来のモデルは通常、1 つのコンテンツタイプを処理するように特化しています。この制限により、お客様は、複雑なクロスモーダル埋め込みソリューションを構築するか、または単一のコンテンツタイプに特化したユースケースに制限せざるを得なくなります。また、この問題は、テキストと画像がインターリーブされたドキュメントや、ビジュアル、音声、テキスト要素を含む動画など、混合モーダルのコンテンツタイプにも当てはまります。これらのコンテンツタイプでは、既存のモデルでは、クロスモーダル関係を効果的に捉えることが困難です。 Nova Multimodal Embeddings は、混合モーダルコンテンツ間のクロスモーダル検索、参照画像を使った検索、ビジュアルドキュメントの取得などのユースケースにおいて、テキスト、ドキュメント、画像、動画、音声のための統合セマンティック空間をサポートします。 Amazon Nova Multimodal Embeddings のパフォーマンスの評価 幅広いベンチマークでモデルを評価した結果、次の表に示すとおり、すぐに活用できる極めて優れた精度を実現しました。 Nova Multimodal Embeddings は、最大 8K トークンのコンテキスト長、最大 200 言語のテキストをサポートし、同期および非同期 API を介して入力を受け付けます。さらに、セグメンテーション (「チャンキング」とも呼ばれます) をサポートし、長文のテキスト、動画、音声コンテンツを扱いやすいセグメントにパーティショニングし、各部分の埋め込みを生成します。最後に、このモデルは 4 つの出力埋め込みディメンションを提供します。これらの埋め込みディメンションは、 Matryoshka Representation Learning (MRL) を使用してトレーニングされており、精度の変動を最小限に抑えながら、低レイテンシーのエンドツーエンド検索を可能にします。 実際に新しいモデルをどのように使用できるのかを見てみましょう。 Amazon Nova Multimodal Embeddings の使用 Nova Multimodal Embeddings の開始方法は、 Amazon Bedrock の他のモデル と同じパターンに従います。このモデルは、テキスト、ドキュメント、画像、動画、または音声を入力として受け入れ、セマンティック検索、類似度比較、または RAG に使用できる数値埋め込みを返します。 ここでは、 AWS SDK for Python (Boto3) を使用して、さまざまなコンテンツタイプから埋め込みを作成し、後で取得できるように保存する方法を示す実用的な例を示します。簡潔にするために、埋め込みの保存と検索には、あらゆる規模のベクトルの保存とクエリをネイティブにサポートするコスト最適化ストレージである Amazon S3 Vectors を使用します。 まずは基本、すなわち、テキストを埋め込みに変換することから始めましょう。この例では、シンプルなテキスト記述を、その意味論的意味を捉えた数値表現に変換する方法を示します。これらの埋め込みは、後でドキュメント、画像、動画、音声からの埋め込みと比較することで、関連コンテンツを見つけることができます。 コードを理解しやすくするために、一度に示すのはスクリプトの一部にとどめます。完全なスクリプトはこのウォークスルーの最後に含まれています。 import json import base64 import time import boto3 MODEL_ID = "amazon.nova-2-multimodal-embeddings-v1:0" EMBEDDING_DIMENSION = 3072 # Amazon Bedrock ランタイムクライアントを初期化します bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") print(f"Generating text embedding with {MODEL_ID} ...") # 埋め込むテキスト text = "Amazon Nova is a multimodal foundation model" # 埋め込みを作成します request_body = { "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": text}, }, } response = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=MODEL_ID, contentType="application/json", ) # 埋め込みを抽出します response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] print(f"Generated embedding with {len(embedding)} dimensions") 次に、スクリプトと同じフォルダにある photo.jpg ファイルを使用して、同じ埋め込み空間でビジュアルコンテンツを処理します。これは、マルチモーダリティの力を示しています。Nova Multimodal Embeddings は、テキストとビジュアルの両方のコンテキストを単一の埋め込みに取り込むことができ、ドキュメントをより深く理解できるようにします。 Nova Multimodal Embeddings は、使用方法に合わせて最適化された埋め込みを生成できます。検索または取得のユースケースのためにインデックスを作成する場合、 embeddingPurpose を GENERIC_INDEX に設定できます。クエリステップでは、取得する項目のタイプに応じて embeddingPurpose を設定できます。例えば、ドキュメントを取得する場合、 embeddingPurpose を DOCUMENT_RETRIEVAL に設定できます。 # 画像を読み取ってエンコードします print(f"Generating image embedding with {MODEL_ID} ...") with open("photo.jpg", "rb") as f: image_bytes = base64.b64encode(f.read()).decode("utf-8") # 埋め込みを作成します request_body = { "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "image": { "format": "jpeg", "source": {"bytes": image_bytes} }, }, } response = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=MODEL_ID, contentType="application/json", ) # 埋め込みを抽出します response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] print(f"Generated embedding with {len(embedding)} dimensions") 動画コンテンツの処理には、非同期 API を使用します。これは、 Base64 としてエンコードされたときに 25 MB を超える動画の要件です。まず、同じ AWS リージョン 内の S3 バケットにローカル動画をアップロードします。 aws s3 cp presentation.mp4 s3://my-video-bucket/videos/ この例では、動画ファイルのビジュアルと音声の両方のコンポーネントから埋め込み情報を抽出する方法を示します。セグメンテーション特徴量により、長い動画が扱いやすいチャンクに分割されるため、何時間にも及ぶコンテンツを効率的に検索できます。 # Amazon S3 クライアントを初期化します s3 = boto3.client("s3", region_name="us-east-1") print(f"Generating video embedding with {MODEL_ID} ...") # Amazon S3 URI S3_VIDEO_URI = "s3://my-video-bucket/videos/presentation.mp4" S3_EMBEDDING_DESTINATION_URI = "s3://my-embedding-destination-bucket/embeddings-output/" # 音声付き動画の非同期埋め込みジョブを作成します model_input = { "taskType": "SEGMENTED_EMBEDDING", "segmentedEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "video": { "format": "mp4", "embeddingMode": "AUDIO_VIDEO_COMBINED", "source": { "s3Location": {"uri": S3_VIDEO_URI} }, "segmentationConfig": { "durationSeconds": 15 # 15 秒単位のチャンクにセグメント化します }, }, }, } response = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={ "s3OutputDataConfig": { "s3Uri": S3_EMBEDDING_DESTINATION_URI } }, ) invocation_arn = response["invocationArn"] print(f"Async job started: {invocation_arn}") # ジョブが完了するまでポーリングします print("\nPolling for job completion...") while True: job = bedrock_runtime.get_async_invoke(invocationArn=invocation_arn) status = job["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(15) # ジョブが正常に完了したかどうかをチェックします if status == "Completed": output_s3_uri = job["outputDataConfig"]["s3OutputDataConfig"]["s3Uri"] print(f"\nSuccess! Embeddings at: {output_s3_uri}") # S3 URI を解析してバケットとプレフィックスを取得します s3_uri_parts = output_s3_uri[5:].split("/", 1) # プレフィックス「s3://」を削除します bucket = s3_uri_parts[0] prefix = s3_uri_parts[1] if len(s3_uri_parts) > 1 else "" # AUDIO_VIDEO_COMBINED モードは、embedding-audio-video.jsonl に出力します # output_s3_uri には既にジョブ ID が含まれているため、ファイル名を付加するだけです embeddings_key = f"{prefix}/embedding-audio-video.jsonl".lstrip("/") print(f"Reading embeddings from: s3://{bucket}/{embeddings_key}") # JSONL ファイルを読み取って解析します response = s3.get_object(Bucket=bucket, Key=embeddings_key) content = response['Body'].read().decode('utf-8') embeddings = [] for line in content.strip().split('\n'): if line: embeddings.append(json.loads(line)) print(f"\nFound {len(embeddings)} video segments:") for i, segment in enumerate(embeddings): print(f" Segment {i}: {segment.get('startTime', 0):.1f}s - {segment.get('endTime', 0):.1f}s") print(f" Embedding dimension: {len(segment.get('embedding', []))}") else: print(f"\nJob failed: {job.get('failureMessage', 'Unknown error')}") 埋め込みを生成したら、それらを効率的に保存および検索するための場所が必要です。この例では、大規模な類似性検索に必要となるインフラストラクチャを提供する Amazon S3 Vectors を使用してベクトルストアをセットアップする方法を示します。これは、意味論的に類似したコンテンツが自然にクラスター化される、検索可能なインデックスを作成するものと考えてください。インデックスに埋め込みを追加する際、メタデータを使用して元の形式とインデックスの作成対象のコンテンツを指定します。 # Amazon S3 Vectors クライアントを初期化します s3vectors = boto3.client("s3vectors", region_name="us-east-1") # 設定 VECTOR_BUCKET = "my-vector-store" INDEX_NAME = "embeddings" # ベクトルバケットとインデックスを作成します (存在していない場合) try: s3vectors.get_vector_bucket(vectorBucketName=VECTOR_BUCKET) print(f"Vector bucket {VECTOR_BUCKET} already exists") except s3vectors.exceptions.NotFoundException: s3vectors.create_vector_bucket(vectorBucketName=VECTOR_BUCKET) print(f"Created vector bucket: {VECTOR_BUCKET}") try: s3vectors.get_index(vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME) print(f"Vector index {INDEX_NAME} already exists") except s3vectors.exceptions.NotFoundException: s3vectors.create_index( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, dimension=EMBEDDING_DIMENSION, dataType="float32", distanceMetric="cosine" ) print(f"Created index: {INDEX_NAME}") texts = [ "Machine learning on AWS", "Amazon Bedrock provides foundation models", "S3 Vectors enables semantic search" ] print(f"\nGenerating embeddings for {len(texts)} texts...") # Amazon Nova を使用して各テキストの埋め込みを生成します vectors = [] for text in texts: response = bedrock_runtime.invoke_model( body=json.dumps({ "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": text} } }), modelId=MODEL_ID, accept="application/json", contentType="application/json" ) response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] vectors.append({ "key": f"text:{text[:50]}", # 一意の識別子 "data": {"float32": embedding}, "metadata": {"type": "text", "content": text} }) print(f" ✓ Generated embedding for: {text}") # 1 回の呼び出しで、保存するすべてのベクトルを追加します s3vectors.put_vectors( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, vectors=vectors ) print(f"\nSuccessfully added {len(vectors)} vectors to the store in one put_vectors call!") この最後の例では、単一のクエリでさまざまなコンテンツタイプを検索し、テキスト、画像、動画、音声のいずれから生成されたかにかかわらず、最も類似したコンテンツを見つける機能を示します。距離スコアは、結果が元のクエリとどの程度関連しているのかを理解するのに役立ちます。 # クエリするテキスト query_text = "foundation models" print(f"\nGenerating embeddings for query '{query_text}' ...") # 埋め込みを生成します response = bedrock_runtime.invoke_model( body=json.dumps({ "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_RETRIEVAL", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": query_text} } }), modelId=MODEL_ID, accept="application/json", contentType="application/json" ) response_body = json.loads(response["body"].read()) query_embedding = response_body["embeddings"][0]["embedding"] print(f"Searching for similar embeddings...\n") # 最も類似した上位 5 つのベクトルを検索します response = s3vectors.query_vectors( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, queryVector={"float32": query_embedding}, topK=5, returnDistance=True, returnMetadata=True ) # 結果を表示します print(f"Found {len(response['vectors'])} results:\n") for i, result in enumerate(response["vectors"], 1): print(f"{i}. {result['key']}") print(f" Distance: {result['distance']:.4f}") if result.get("metadata"): print(f" Metadata: {result['metadata']}") print() クロスモーダル検索は、マルチモーダル埋め込みの重要な利点の 1 つです。クロスモーダル検索を使用すると、テキストでクエリして、関連する画像を見つけることができます。また、テキストの説明を使用して動画を検索したり、特定のトピックに一致する音声クリップを見つけたり、ビジュアルとテキストのコンテンツに基づいてドキュメントを検出したりすることもできます。ご参考までに、これまでの例をすべてまとめた完全なスクリプトをこちらに示します: import json import base64 import time import boto3 MODEL_ID = "amazon.nova-2-multimodal-embeddings-v1:0" EMBEDDING_DIMENSION = 3072 # Amazon Bedrock ランタイムクライアントを初期化します bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") print(f"Generating text embedding with {MODEL_ID} ...") # 埋め込むテキスト text = "Amazon Nova is a multimodal foundation model" # 埋め込みを作成します request_body = { "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": text}, }, } response = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=MODEL_ID, contentType="application/json", ) # 埋め込みを抽出します response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] print(f"Generated embedding with {len(embedding)} dimensions") # 画像を読み取ってエンコードします print(f"Generating image embedding with {MODEL_ID} ...") with open("photo.jpg", "rb") as f: image_bytes = base64.b64encode(f.read()).decode("utf-8") # 埋め込みを作成します request_body = { "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "image": { "format": "jpeg", "source": {"bytes": image_bytes} }, }, } response = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=MODEL_ID, contentType="application/json", ) # 埋め込みを抽出します response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] print(f"Generated embedding with {len(embedding)} dimensions") # Amazon S3 クライアントを初期化します s3 = boto3.client("s3", region_name="us-east-1") print(f"Generating video embedding with {MODEL_ID} ...") # Amazon S3 URI S3_VIDEO_URI = "s3://my-video-bucket/videos/presentation.mp4" # Amazon S3 出力バケットと場所 S3_EMBEDDING_DESTINATION_URI = "s3://my-video-bucket/embeddings-output/" # 音声付き動画の非同期埋め込みジョブを作成します model_input = { "taskType": "SEGMENTED_EMBEDDING", "segmentedEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "video": { "format": "mp4", "embeddingMode": "AUDIO_VIDEO_COMBINED", "source": { "s3Location": {"uri": S3_VIDEO_URI} }, "segmentationConfig": { "durationSeconds": 15 # 15 秒単位のチャンクにセグメント化します }, }, }, } response = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={ "s3OutputDataConfig": { "s3Uri": S3_EMBEDDING_DESTINATION_URI } }, ) invocation_arn = response["invocationArn"] print(f"Async job started: {invocation_arn}") # ジョブが完了するまでポーリングします print("\nPolling for job completion...") while True: job = bedrock_runtime.get_async_invoke(invocationArn=invocation_arn) status = job["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(15) # ジョブが正常に完了したかどうかをチェックします if status == "Completed": output_s3_uri = job["outputDataConfig"]["s3OutputDataConfig"]["s3Uri"] print(f"\nSuccess! Embeddings at: {output_s3_uri}") # S3 URI を解析してバケットとプレフィックスを取得します s3_uri_parts = output_s3_uri[5:].split("/", 1) # プレフィックス「s3://」を削除します bucket = s3_uri_parts[0] prefix = s3_uri_parts[1] if len(s3_uri_parts) > 1 else "" # AUDIO_VIDEO_COMBINED モードは、embedding-audio-video.jsonl に出力します # output_s3_uri には既にジョブ ID が含まれているため、ファイル名を付加するだけです embeddings_key = f"{prefix}/embedding-audio-video.jsonl".lstrip("/") print(f"Reading embeddings from: s3://{bucket}/{embeddings_key}") # JSONL ファイルを読み取って解析します response = s3.get_object(Bucket=bucket, Key=embeddings_key) content = response['Body'].read().decode('utf-8') embeddings = [] for line in content.strip().split('\n'): if line: embeddings.append(json.loads(line)) print(f"\nFound {len(embeddings)} video segments:") for i, segment in enumerate(embeddings): print(f" Segment {i}: {segment.get('startTime', 0):.1f}s - {segment.get('endTime', 0):.1f}s") print(f" Embedding dimension: {len(segment.get('embedding', []))}") else: print(f"\nJob failed: {job.get('failureMessage', 'Unknown error')}") # Amazon S3 Vectors クライアントを初期化します s3vectors = boto3.client("s3vectors", region_name="us-east-1") # 設定 VECTOR_BUCKET = "my-vector-store" INDEX_NAME = "embeddings" # ベクトルバケットとインデックスを作成します (存在していない場合) try: s3vectors.get_vector_bucket(vectorBucketName=VECTOR_BUCKET) print(f"Vector bucket {VECTOR_BUCKET} already exists") except s3vectors.exceptions.NotFoundException: s3vectors.create_vector_bucket(vectorBucketName=VECTOR_BUCKET) print(f"Created vector bucket: {VECTOR_BUCKET}") try: s3vectors.get_index(vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME) print(f"Vector index {INDEX_NAME} already exists") except s3vectors.exceptions.NotFoundException: s3vectors.create_index( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, dimension=EMBEDDING_DIMENSION, dataType="float32", distanceMetric="cosine" ) print(f"Created index: {INDEX_NAME}") texts = [ "Machine learning on AWS", "Amazon Bedrock provides foundation models", "S3 Vectors enables semantic search" ] print(f"\nGenerating embeddings for {len(texts)} texts...") # Amazon Nova を使用して各テキストの埋め込みを生成します vectors = [] for text in texts: response = bedrock_runtime.invoke_model( body=json.dumps({ "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": text} } }), modelId=MODEL_ID, accept="application/json", contentType="application/json" ) response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] vectors.append({ "key": f"text:{text[:50]}", # 一意の識別子 "data": {"float32": embedding}, "metadata": {"type": "text", "content": text} }) print(f" ✓ Generated embedding for: {text}") # 1 回の呼び出しで、保存するすべてのベクトルを追加します s3vectors.put_vectors( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, vectors=vectors ) print(f"\nSuccessfully added {len(vectors)} vectors to the store in one put_vectors call!") # クエリするテキスト query_text = "foundation models" print(f"\nGenerating embeddings for query '{query_text}' ...") # 埋め込みを生成します response = bedrock_runtime.invoke_model( body=json.dumps({ "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_RETRIEVAL", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": query_text} } }), modelId=MODEL_ID, accept="application/json", contentType="application/json" ) response_body = json.loads(response["body"].read()) query_embedding = response_body["embeddings"][0]["embedding"] print(f"Searching for similar embeddings...\n") # 最も類似した上位 5 つのベクトルを検索します response = s3vectors.query_vectors( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, queryVector={"float32": query_embedding}, topK=5, returnDistance=True, returnMetadata=True ) # 結果を表示します print(f"Found {len(response['vectors'])} results:\n") for i, result in enumerate(response["vectors"], 1): print(f"{i}. {result['key']}") print(f" Distance: {result['distance']:.4f}") if result.get("metadata"): print(f" Metadata: {result['metadata']}") print() 本番アプリケーションでは、埋め込みは任意のベクトルデータベースに保存できます。 Amazon OpenSearch Service は、リリース時に Nova Multimodal Embeddings とのネイティブ統合を提供しているため、スケーラブルな検索アプリケーションを簡単に構築できます。前の例で示したように、 Amazon S3 Vectors を使用すると、アプリケーションデータを使用して埋め込みを簡単に保存およびクエリできます。 知っておくべきこと Nova Multimodal Embeddings は、3,072、1,024、384、256 の 4 つの出力ディメンションオプションを提供します。ディメンションが大きいほど詳細な表現が得られますが、より多くのストレージと計算が必要になります。ディメンションが小さいほど、検索パフォーマンスとリソース効率の実用的なバランスを実現できます。この柔軟性は、特定のアプリケーションとコスト要件に合わせて最適化するのに役立ちます。 このモデルは、かなり長いコンテキストを処理できます。テキスト入力では、一度に最大 8,192 トークンを処理できます。動画と音声の入力は最大 30 秒のセグメントをサポートし、モデルはより長いファイルをセグメント化できます。このセグメンテーション機能は、特に大容量のメディアファイルを扱う際に役立ちます。モデルはファイルを扱いやすいサイズに分割し、各セグメントの埋め込みを作成します。 このモデルには、Amazon Bedrock に組み込まれた責任ある AI の機能が含まれています。埋め込み用に送信されたコンテンツは、Amazon Bedrock のコンテンツセーフティフィルターを通過します。また、モデルには、バイアスを低減するための公平性対策が含まれています。 コード例で説明されているように、このモデルは同期 API と非同期 API の両方を通じて呼び出すことができます。同期 API は、検索インターフェイスでのユーザークエリの処理など、即時の応答が必要なリアルタイムアプリケーションに適しています。非同期 API は、レイテンシーの影響が小さいワークロードをより効率的に処理するため、動画などの大容量コンテンツの処理に適しています。 利用可能なリージョンと料金 Amazon Nova Multimodal Embeddings は、米国東部 (バージニア北部) の AWS リージョン の Amazon Bedrock で本日よりご利用いただけます。料金の詳細については、 Amazon Bedrock の料金ページ にアクセスしてください。 詳しくは、包括的なドキュメントについては「 Amazon Nova ユーザーガイド 」、実用的なコード例については GitHub の Amazon Nova モデルクックブック をご覧ください。 Amazon Q Developer や Kiro などの AI を利用したアシスタントをソフトウェア開発に使用している場合は、AI アシスタントが AWS のサービスやリソースとインタラクションするのに役立つように AWS API MCP サーバー をセットアップしたり、最新のドキュメント、コードサンプル、AWS API と CloudFormation リソースのリージョンレベルの可用性に関するナレッジを提供するために AWS Knowledge MCP サーバー をセットアップしたりできます。 今すぐ Nova Multimodal Embeddings を使用してマルチモーダル AI を利用したアプリケーションの構築を開始し、 AWS re:Post for Amazon Bedrock または通常の AWS サポートの連絡先を通じてフィードバックをぜひお寄せください。 – Danilo 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いきなりですが、「お祭り」のご案内です！11月5日(水)にコスト最適化の最新アップデートや生成AIを活用したメソッドを学ぶ「 AWS 秋のCost Optimization祭り 2025 」が、そして 11月6日(木) は生成 AI を使ったAWS オブザーバビリティの最新動向を学ぶ「 AWS 秋のオブザーバビリティ祭り 2025 」が開催されます。両日とも AWS Startup Loft Tokyo で 19:00 から開始予定です。 だんだん寒くなってきましたが、秋夜にアツい２日間を過ごしてみるのはいかがでしょうか？ AWS のコスト最適化や可観測性に課題をお持ちの方も、ただただ興味があるという方も、ぜひ参加してみてください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年10月27日週の主要なアップデート 10/27(月) Amazon SageMaker が検索結果に追加の検索コンテキストを追加 Amazon SageMaker Unified Studio の検索機能が大幅に改善されました。これまで検索結果がなぜ表示されるのか分からず、関連性を判断するのに時間がかかっていましたが、今回のアップデートでメタデータのどの部分がクエリにマッチしたかが視覚的に分かるようになりました。名前、説明、用語集、スキーマなどの各フィールドでマッチした箇所がハイライト表示され、説明パネルで詳細も確認できます。これにより、データ発見の効率が向上し、不要なアセットを開かずに関連性を素早く判断できるようになります。詳細は こちらのドキュメントをご参照ください。 Amazon Redshift Serverless が AWS アジアパシフィック (大阪) およびアジアパシフィック (マレーシア) リージョンで利用可能になりました Amazon Redshift Serverless が大阪リージョンとマレーシアリージョンで利用可能になりました。データウェアハウスクラスターの管理が不要で、データ分析を数秒で開始できます。従来は事前にノードタイプやクラスター設定を決める必要がありましたが、今回のサービスでは自動的にキャパシティを調整し、使った分だけの従量課金となります。Query Editor V2 ですぐにクエリを実行でき、データアナリストや開発者が手軽に分析環境を構築できるようになりました。詳細は こちらの機能ページをご参照ください。 Amazon ECS マネージドインスタンス が全ての商用 AWS リージョンで利用可能になりました Amazon ECS マネージドインスタンスが全商用リージョンで利用可能になりました。このサービスは ECS において EC2 を利用時に、EC2 のインフラストラクチャ管理を AWS に任せつつ、全機能へのアクセスを提供するよう設計された、新しいフルマネージドのオプションです。これまで東京リージョンを含む６つのリージョンで利用可能でしたが、今回のアップデートで大阪リージョンを含むすべての商用リージョンで利用することできるようになりました。Amazon ECS マネージドインスタンスの詳細は こちらの Blog 記事をご参照ください。 10/28(火) AWS Resource Explorer が 47 の追加リソースタイプをサポート AWS Resource Explorer が 47 の新しいリソースタイプに対応し、Amazon Bedrock や AWS Shield、AWS Glue などのリソースも検索できるようになりました。これまで個別のサービスコンソールでしか確認できなかったリソースを、Resource Explorer で一括検索できるため、複数のサービスを利用している環境でのリソース管理が大幅に効率化されます。詳細は こちらのドキュメントをご参照ください。 Amazon Nova マルチモーダル埋め込みの発表 Amazon Nova Multimodal Embeddings が一般提供開始されました。これまではテキスト、画像、動画、音声それぞれに専用のモデルが必要でしたが、今回の新モデルでは単一モデルですべてのコンテンツタイプを処理できます。動画アーカイブから複雑な検索クエリでコンテンツを探したり、顧客の質問に基づいて関連商品画像を見つけるなど、クロスモーダルな検索が可能になります。バージニア北部リージョンの Amazon Bedrock で利用できます。詳細は こちらの Blog 記事をご参照ください。 Amazon Kinesis Data Streams が 10 倍大きなレコードサイズをサポート Amazon Kinesis Data Streams のレコードサイズ上限が従来の 1 MiB から 10 MiB に 10 倍拡大されました。これまで大きなデータを扱う際は別の処理パイプラインが必要でしたが、今回のアップデートにより IoT データ分析や AI ワークロードなどで間欠的に発生する大容量データも単一のストリームで処理できるようになり、運用負荷が大幅に軽減されます。詳細は こちらのドキュメントをご参照ください。 10/29(水) Web Grounding: Amazon Nova モデルで正確な AI アプリケーションを構築 Amazon Nova モデルの新機能 Web Grounding が一般提供開始されました。この機能により、Amazon Nova モデルが Web 上の最新情報を自動で取得し、その情報を引用付きで回答に活用するAIアプリケーションの構築が可能となります。従来の AI モデルでは古い学習データに基づく回答や不正確な内容 (ハルシネーション) が課題でしたが、Web Grounding を使うことでリアルタイムの正確な情報に基づいた回答が可能になります。現在 Nova Premier で利用でき、バージニア北部、オハイオ、オレゴンリージョンで提供中です。詳細は こちらの Blog 記事をご参照ください。 Amazon S3 がコピー操作に条件付き書き込み機能を追加 Amazon S3 のコピー操作で条件付き書き込み機能が利用できるようになりました。複数のユーザーが同じオブジェクトに同時アクセスする際、意図しない上書きを防げます。if-match や if-none-match ヘッダーを使用することで、コピー先にオブジェクトが存在するかや内容が変更されているかを事前チェック可能です。全リージョンで追加料金なしで利用でき、従来必要だったクライアント側の調整処理が不要になります。詳細は こちらのドキュメントをご参照ください。 Amazon EBS が EBS ボリュームの追加パフォーマンス監視メトリクスを導入 Amazon EBS で新しい CloudWatch メトリクス VolumeAvgIOPS と VolumeAvgThroughput が追加されました。これにより EBS ボリュームの平均 IOPS と平均スループットを 1 分間隔で監視できるようになり、パフォーマンスのトレンド分析やボトルネックの特定が簡単になります。従来は詳細なパフォーマンス監視が困難でしたが、これらのメトリクスを使ってダッシュボード作成やアラーム設定も可能です。EC2 Nitro インスタンスに接続された全ての EBS ボリュームで無料利用できます。詳細は こちらのドキュメントをご参照ください。 10/30(木) Amazon Managed Service for Prometheus が異常検知機能を追加 Amazon Managed Service for Prometheus にアノマリー検知機能が追加されました。機械学習により時系列データの異常を自動検知し、従来は手動で監視していた異常値を自動で発見できるようになります。システムの性能低下やエラー急増などを早期発見でき、運用負荷を大幅に軽減します。検知結果は Grafana で可視化でき、アラート設定も可能です。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Browser が Web Bot Auth (プレビュー) で CAPTCHA を削減 Amazon Bedrock AgentCore Browser で Web Bot Auth (プレビュー) が利用可能になりました。この機能により、AI エージェントがウェブサイトを自動操作する際の CAPTCHA による中断を大幅に減らせます。従来は AI エージェントが人間による手動介入を必要とする場面が多くありましたが、Web Bot Auth により AI エージェントが信頼できる存在として認識され、スムーズな自動化ワークフローを実現できます。詳細は こちらの Blog 記事をご参照ください。 AWS Backup が AWS リージョンとアカウント間でのデータベーススナップショットの単一アクションコピー機能を追加 AWS Backup で、データベースのスナップショットを異なるリージョンやアカウントに 1 回の操作でコピーできるようになりました。従来は 2 段階の手順が必要でしたが、この機能により RDS、Aurora、Neptune、DocumentDB のスナップショットを直接コピー可能です。ランサムウェア攻撃やリージョン障害から保護でき、中間コピーのコストも削減されます。詳細は こちらのドキュメントをご参照ください。 Amazon ECS で Linear デプロイメントとCanary デプロイメントの組み込みサポートを開始 Amazon ECS で Linear(線形)と Canary デプロイメント戦略が利用できるようになりました。従来の Blue/Green デプロイメントに加えて、より柔軟なデプロイメント方法が選択可能です。Linear(線形) デプロイメントでは段階的にトラフィックをシフト (例: 10% ずつ) し、各段階で動作確認できます。Canary デプロイメントでは少量のトラフィックを新バージョンに向けて検証後、残りのトラフィックを移行します。CloudWatch アラームと連携した自動ロールバック機能により、問題発生時の迅速な対応が可能です。詳細は こちらのドキュメントをご参照ください。 10/31(金) Amazon VPC IPAM がプレフィックスリストの更新を自動化 Amazon VPC IPAM で、プレフィックスリストの更新を自動化する prefix list resolver (PLR) 機能が追加されました。これまで VPC や サブネット の IP アドレス範囲が変更されるたびに、手動でプレフィックスリストを更新する必要がありましたが、PLR により自動同期が可能になります。ルートテーブルやセキュリティグループで参照するプレフィックスリストが、ビジネスルールに基づいて自動更新されるため、運用負荷が大幅に軽減されます。全リージョンで利用可能です。 詳細はこちらのドキュメントをご参照ください。 AWS 向け Model Context Protocol (MCP) Proxy が一般提供開始 AWS が Model Context Protocol (MCP) Proxy for AWS の一般提供を開始しました。これにより、AI 開発ツール (Amazon Q Developer CLI や Cursor など) から AWS SigV4 認証を使って AWS のリソースに安全にアクセスできるようになります。例えば S3 バケットや RDS テーブルなどの AWS サービスを AI エージェントから直接操作可能です。読み取り専用モードやリトライ機能などの安全機能も搭載しており、開発者は安心して AI ワークフローに AWS サービスを組み込めます。詳細は こちらの GitHub リポジトリをご参照ください。 AWS PrivateLink が AWS サービスのクロスリージョン接続をサポート AWS PrivateLink がクロスリージョン接続に対応しました。これまで Interface VPC エンドポイントは同一リージョン内の AWS サービスにしか接続できませんでしたが、今回のアップデートにより他リージョンの Amazon S3 や Route 53、ECR などに VPC ピアリングやパブリックインターネットを経由せずプライベート接続が可能になります。データレジデンシー要件を満たしつつ、グローバルなプライベートネットワーク構築に活用できます。詳細は こちらのドキュメントをご参照ください。 今年の AWS re:Invent まであと約１ヶ月と迫ってきました。おそらく開催前の 11 月も多くのサービスアップデートが発表されると思いますので、情報の準備体操をお願いします！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。11月が始まり、心の中ではre:invent へのカウントダウンを始めました。今年は何が発表されるのでしょうか。。。！？ そして毎年おなじみAWS Japanから提供する re:invent 速報を今年も開催いたします。ぜひ こちらのページ より事前登録をお願いいたします。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、10 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。先週はBedrock上で利用することができる新モデルやモデル向けツールの発表が多数ありました。 さまざまなニュース AWS 生成 AI 国内事例ブログ: 仰星監査法人様の AWS 生成 AI 活用事例 ：株式会社 Sapeet 様支援のもと、Dify を用いて生成 AI アプリを構築し、機微な情報を扱えるセキュアな環境でクライアント情報の収集・環境分析調査時間の 87% 削減を実現 仰星監査法人様は、株式上場 (IPO) 支援業務やファイナンシャルアドバイザリーサービスなどの各種サービスを提供する法人です。監査業務では、クライアント情報の収集や環境分析に多くの時間を要し、業務効率化が課題となっていました。この課題を解決するため、株式会社Sapeet様の支援のもと、Amazon Bedrock や Difyを採用し、生成AIアプリケーションを構築しました。機微な情報を扱えるセキュアな環境を実現しながら、クライアント情報の収集・環境分析調査時間の87%削減という大きな成果を上げています。 AWS 生成 AI 国内事例ブログ: ロジカル・アーツ株式会社様の AWS 生成 AI 事例「コールセンター業務の効率化と品質向上を実現する生成 AI コンタクトセンター」 従来のコールセンター業務では、オペレーターの対応品質のばらつきや、問い合わせ対応の効率化が課題となっていました。これらの課題を解決するため、ロジカル・アーツ株式会社様は Amazon Bedrockを活用した生成AIコンタクトセンターソリューションを構築しました。生成AIにより、リアルタイムでのオペレーター支援、自動応答の生成、通話内容の要約などが可能になり、顧客対応の効率化と品質の均一化を実現しています。特に、生成 AI による会話リアルタイム文字起こしと会話議事録生成機能により、エージェントのアフターコールワーク（ACW）時間が 75% 削減され、従来 20 分かかっていた作業が 5 分で完了できるようになりました。この時間短縮により、電話対応件数が 100% 増加し、従来 20 人で対応していた業務量を 10 人で処理できるようになったことで、人的リソースの最適化を実現しました。今後は、さらなる機能拡張を通じて、コールセンター業務の更なる高度化を目指しています。 ブログ記事「 AWS 金融リファレンスアーキテクチャ日本版 2025 (v1.6) アップデート 」を公開 AWS 金融リファレンスアーキテクチャ日本版がバージョン1.6にアップデートされました。この記事では、金融機関がAWS上でセキュアかつスケーラブルなシステムを構築するためのベストプラクティスとアーキテクチャパターンを紹介しています。今回のアップデートでは、生成AIを活用した金融サービスの実装パターンや、最新のセキュリティ要件への対応方法が追加されています。金融業界特有の規制要件に対応しながら、生成AIを活用する際の参考アーキテクチャとして活用いただけます。 ブログ記事「 エージェントステアリングと MCP を使って Kiro に新しいスキルを教える方法 」を公開 この記事では、Kiro における2つの重要な新機能を紹介しています。1つ目は「エージェントステアリング」で、エージェントの動作をより細かく制御し、特定のタスクに最適化できるようになりました。2つ目は「Model Context Protocol (MCP)」のサポートで、外部ツールやデータソースとの統合が容易になります。記事では、これらの機能を使ってKiroに独自ライブラリを理解させ、連携する例を通じて、エージェント開発の新しいアプローチを解説しています。開発者がAIエージェントをより効果的に活用するための参考になる内容です。 サービスアップデート AWS Marketplace、AIエージェントとツールの価格モデルの柔軟性を提供 AWS Marketplaceは、AIエージェントとツールに対して柔軟な価格モデル、簡素化された認証、効率化されたデプロイメントを提供開始しました。Amazon Bedrock AgentCore Runtimeコンテナに対する契約ベースおよび使用量ベースの価格設定が可能になり、顧客は自社のビジネスモデルに最適な価格体系を選択できます。また、認証プロセスが簡素化され、デプロイメントの複雑さが軽減されることで、AIエージェントソリューションの導入がより容易になります。これにより、ISVはAIエージェントソリューションをより柔軟に提供でき、顧客は自社のニーズに合わせた選択が可能になります。 Amazon Bedrock AgentCore Browser、Web Bot Authで CHAPCHA を削減（プレビュー） Amazon Bedrock AgentCore BrowserがWeb Bot Authをサポートし、AIエージェントが大規模にウェブサイトと対話する際の CHAPCHA による中断を削減できるようになりました（プレビュー）。従来、AIエージェントがウェブサイトにアクセスする際、ボット検出システムによってCHAPCHA認証を求められることが多く、自動化の妨げとなっていました。Akamai Technologies、Cloudflare、HUMAN Securityなどの主要なセキュリティプロバイダーとの連携により、正当なAIエージェントのアクセスを効率的に検証し、CHAPCHAの表示を削減します。これにより、AIエージェントによるウェブ自動化がよりスムーズに実行できるようになります。 TwelveLabs Pegasus 1.2モデルが3つの追加AWSリージョンで利用可能に TwelveLabsの動画理解モデルPegasus 1.2が、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（フランクフルト）の3つの追加AWSリージョンで利用可能になりました。Pegasus 1.2は、動画コンテンツの分析、検索、要約などを高精度で実行できる動画理解AIモデルです。これにより、より多くのリージョンで動画分析ソリューションを構築できるようになり、レイテンシーの削減やデータレジデンシー要件への対応が容易になります。 TwelveLabs Marengo Embed 3.0、Amazon Bedrockで高度な動画理解を実現 TwelveLabsのMarengo Embed 3.0がAmazon Bedrockで利用可能になりました。このモデルは、動画、画像、音声、テキストを単一の表現空間に統合する動画ネイティブマルチモーダル埋め込み機能を提供します。最大4時間の動画と音声コンテンツを処理でき、スポーツ分析の改善や36言語へのグローバル多言語サポートが含まれています。 Amazon Nova Multimodal Embeddingsを発表 Amazon Nova Multimodal Embeddingsの一般提供が開始されました。テキスト、ドキュメント、画像、動画、音声を単一のモデルでサポートする統合埋め込みモデルで、クロスモーダル検索を実現します。最大8Kトークンの入力と最大30秒の動画/音声セグメントをサポートしています。 Stability AI Image Services、Amazon Bedrockで4つの新しい画像編集ツールを追加 Amazon Bedrock で利用することができる Stability AI Image Services に4つの新しい画像編集ツール（Outpaint、Fast Upscale、Conservative Upscale、Creative Upscale）を追加しました。これらのツールにより、クリエイターはワークフローをより細かく制御でき、コンセプトを完成品に効率的に変換できます。  Amazon NovaモデルでWeb Grounding機能が一般提供開始 Amazon Novaモデル向けの新しい組み込みツール「Web Grounding」の一般提供が開始されました。Web Groundingは、公開されている情報を引用付きで取得し、応答のコンテキストとして組み込むことができるツールです。開発者は、現在のリアルタイム情報を使用したRAGソリューションを実装でき、ハルシネーションを削減できます。 Model Context Protocol (MCP) Proxy for AWSが一般提供開始 Model Context Protocol (MCP) Proxy for AWSの一般提供が開始されました。MCPは、AIアプリケーションがコンテキスト情報を標準化された方法で共有するためのオープンプロトコルです。このプロキシにより、MCPクライアントがAWS SigV4認証を使用してリモートのAWSホスト型MCPサーバーに安全に接続できるようになります。Amazon Q Developer CLI、Kiro、Cursorなどの人気のエージェント型AI開発ツールをサポートしており、読み取り専用モードなどの安全制御機能を備えています。これにより、開発者はAIエージェントと外部システムの統合をより安全かつ容易に実現できます。 AWS IoT Greengrass開発者向けAIエージェントコンテキストパックを発表 AWS IoT Greengrass開発者向けのAIエージェントコンテキストパックが発表されました。このコンテキストパックは、AIエージェントがIoT Greengrassの開発タスクを支援するために必要な情報を提供します。開発者は、AIエージェントを活用してIoTアプリケーションの開発、デバッグ、最適化をより効率的に行うことができます。 AWS Serverless MCP Server、AWS Lambda Event Source Mapping (ESM) ツールをサポート AWS Serverless Model Context Protocol (MCP) Serverが、AWS Lambda Event Source Mapping (ESM) 用の専用ツールをサポートするようになりました。これらのツールは、開発者がイベント駆動型サーバーレスアプリケーションのセットアップ、最適化、トラブルシューティングを効率化します。 AI/ML/HPCインスタンスタイプ向け Capacity Reservation Topology API を発表 Capacity Reservation Topology APIが、AI/ML/HPCワークロード向けのインスタンスタイプをサポートしました。このAPIにより、大規模な生成AIモデルのトレーニングや推論に必要な計算リソースを、最適なネットワークトポロジーで予約できます。特に、複数のGPUインスタンス間の高速通信が必要な分散学習において、パフォーマンスの向上が期待できます。 Amazon SageMaker、検索コンテキスト機能を追加 Amazon SageMakerに検索コンテキスト機能が追加されました。この機能により、機械学習モデルの開発過程で、関連する実験、モデル、データセットを効率的に検索し、コンテキストを把握できるようになります。大規模なML開発プロジェクトにおいて、過去の実験結果や関連リソースを素早く見つけることができ、開発効率が向上します。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見たアニメは「光が死んだ夏」です。

2025年10月7日、大規模分散アプリケーションの監視を簡素化する Amazon CloudWatch Application Signals の強化機能を新たに発表できることを嬉しく思います。CloudWatch Application Signals の アプリケーションマップ の改善により、サービスの検出、及びグループ化をサービスの関係性を元に自動的に行える様になりました。また、ビジネスの観点に合わせたカスタムグループもサポートします。最新のサービスデプロイ時間を確認し、 サービスレベル指標 （SLI）違反等の問題に関する自動監査結果を評価できるようになりました。 主な機能と特徴 CloudWatch Application Signals のアプリケーションマップは、サービスレベル目標（SLO）や健全性指標などの運用シグナルを表示します。コンテキストに応じたトラブルシューティングドロワーにより、標準メトリクス、最新のデプロイステータス、実用的なインサイトに即座にアクセスできます。より詳細な分析のために、包括的なトラブルシューティング用にカスタマイズされたアプリケーション固有のダッシュボードにシームレスに移行できます。この統合された体験により、チームは根本原因をより迅速に特定し、平均解決時間を短縮できます。 即座に利用可能 AWSアカウント で Application Signals がすでに有効になっている場合、これらの新機能を使い始めるために追加の設定は必要ありません。Application Signals を有効にするには、 アカウントで Application Signals を有効にする を参照して、Application Signals がサービスを検出するために必要な権限を付与する必要があります。ご自身のアプリケーションに実装する前にサンプルアプリで CloudWatch Application Signals を試す際には、この AWS ドキュメント の手順に従ってください。 根本原因分析 DevOps エンジニアは、アプリケーションマップを使用してインシデント発生時に根本原因を迅速に特定できます。サービスが高いエラー率を示している場合、影響を受けたノードをクリックすると、トラブルシューティングドロワーにメトリクス、最近のデプロイ、依存関係の健全性が表示されます。エンジニアは、メトリクス、最新のデプロイ、SLI違反などの問題に関する監査結果を確認できます。 図1. サービス このトラブルシューティングプロセスをさらに効率化するために、生成AI搭載アシスタントである CloudWatch Investigations がシステムのテレメトリをスキャンし、問題に関連する関連データと提案を即座に表示します。Application Signals は CloudWatch Investigations と統合されており、サービスダッシュボードから 調査 を開始できます。 図2. 調査 CloudWatch Application Signals のアプリケーションマップは、標準グループ化を通じてサービスの探索とトラブルシューティングを簡素化します。デフォルトでは、サービスはダウンストリームの依存関係に基づいて自動的にグループ化されます。 グループの管理 を使用して、ビジネス要件と運用上の優先順位に基づいてサービスを整理するための独自のカスタムグループを定義できます。フィルターは、デプロイの変更、SLI違反、または Amazon Elastic Kubernetes Service（Amazon EKS）、Amazon Elastic Container Service（Amazon ECS）、AWS Lambda などのコンピューティングプラットフォームに焦点を当てるのに役立ちます。「View insights」機能は、サービスの健全性、変更履歴、メトリクスを表示します。ダッシュボードには、リソース分析と属性フィルタリングのビューが含まれており、根本原因分析を複数の観点から開始することができます。 図3. アプリケーションマップ まとめ このリリースにより、AWS上の大規模分散アプリケーションを監視およびトラブルシューティングできるようになります。サービスとアプリケーションの依存関係を自動的にグループ化し、コンテキストに応じた運用インサイトを提供することで、カスタムダッシュボードの維持負担を排除し、運用メンテナンス時間を削減します。アプリケーションの複雑さが増し続ける中、AWSのアプリケーション中心のオブザーバビリティアプローチは、チームが大規模で信頼性が高くパフォーマンスの高いサービスを維持するために必要な可視性とツールを提供します。 それでは、探索を始めましょう。 バーチャルツアー ：Application Signals がアプリケーションをどのように可視化し、トラブルシューティングを改善し、監視を変革するかを直接体験したいですか？ 独自の環境をセットアップすることなく、この インタラクティブ なバーチャルツアーをご利用ください。 デモのスケジュール ：AWSアカウントチームに連絡して、アプリケーション監視体験をどのように変革できるかをご確認ください。 AWSオブザーバビリティを始める ：包括的な監視を実装してオブザーバビリティの基盤を強化し、効果的な分析に必要なデータを確実にキャプチャできるようにします。 オブザーバビリティワークショップ ：AWSがアプリケーションのオブザーバビリティを実現するために提供する幅広いツールセットのハンズオン体験を探索してください。 TAGS: Amazon CloudWatch , Application Performance Monitoring , observability Arun Chandapillai Arun Chandapillaiは、ダイバーシティ＆インクルージョンのチャンピオンであるシニアクラウドアーキテクトです。彼は、ビジネスファーストのクラウド導入戦略を通じてお客様のIT近代化を加速し、クラウドでアプリケーションとインフラストラクチャを成功裏に構築、デプロイ、管理することを支援することに情熱を注いでいます。Arunは自動車愛好家であり、熱心なスピーカーであり、「与えたものが（返って）得られる」と信じる慈善家です。 Siva Guruvareddiar Siva Guruvareddiarは、AWSのシニアソリューションアーキテクトであり、お客様が高可用性システムを設計することを支援することに情熱を注いでいます。彼は、マイクロサービス、コンテナ化、可観測性、サービスメッシュ領域、およびクラウド移行を使用してプラットフォームインフラストラクチャと内部アーキテクチャをモダナイズすることにより、クラウドネイティブ導入の取り組みを加速することを支援しています。LinkedIn： linkedin.com/in/sguruvar Mitun Lahiri CloudWatch Application Signals のソフトウェア開発マネージャー 本記事は、 Amazon CloudWatch Application Signals new enhancements for application monitoring を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

AWS X-Ray 用の SDK と Daemon は2026年2月25日にメンテナンスモードに入り、2027年2月25日にサポート終了となります。OpenTelemetry ベースの計装ソリューションへ移行することで、AWS 内でアプリケーションのトレースを継続して生成できます。 AWS X-Ray 用の X-Ray SDK と Daemon を使用している既存のアプリケーションは、意図された通りに機能し続けます。ただし、2026年2月25日から2027年2月25日の間、X-Ray SDK とDaemon は重要なバグ修正とセキュリティアップデートのみ対応され、新機能をサポートするための更新は行われません。例えば、SDK は追加のライブラリ計装や既存のライブラリ計装の機能強化は対応されません。 以下の表は、X-Ray SDK と Daemon のライフサイクルの各フェーズにおけるサポートレベルの概要を示しています。 SDK ライフサイクルフェーズ 開始日 終了日 サポートレベル 一般提供 N/A 2026年2月25日 この段階では、SDK と Daemon は完全にサポートされます。AWSは、バグ修正とセキュリティ修正を含む定期的な SDK / Daemon リリースを提供します。 メンテナンスモード 2026年2月25日 2027年2月25日 AWS は、重要なバグ修正とセキュリティ問題への対応を目的とした SDK と Daemon のリリースのみを行います。SDK / Daemon は新機能の拡張を受け取ることはありません。 サポート終了 2027年2月25日 N/A SDK と Daemon は、今後アップデートやリリースを受け取ることはありません。以前に公開されたリリースは、パブリックパッケージマネージャーを通じて引き続き利用可能であり、コードは GitHub 上に残ります。 AWS X-Ray は、アプリケーショントレースとオブザーバビリティの主要な計装標準として OpenTelemetry に移行しています。アプリケーションからトレースを生成して AWS X-Ray に送信するために、OpenTelemetry ベースの計装ソリューションへの移行をお勧めします。コンソールでの体験は従来と同じままです。 OpenTelemetry は、トレーシング計装とオブザーバビリティのための業界全体のオープンソース標準であり、IT チームにテレメトリデータの収集とルーティングのための標準化されたプロトコルとツールを提供します。メトリクス、ログ、トレースなどのアプリケーションテレメトリデータを計装、生成、収集し、分析と洞察のためにモニタリングプラットフォームにエクスポートするための統一されたフォーマットを提供します。これにより、より迅速な機能開発と、業界全体で一貫したより広範なツールと統合のセットが実現されます。OpenTelemetry 計装ソリューションは、フレームワークとライブラリの計装、より多くの言語サポート、およびゼロコード計装機能に対してより幅広いサポートを提供します。 移行を支援するために、AWS X-Ray ドキュメントで移行ガイダンスと例を見つけることができます。 https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-migration.html Amazon CloudWatch において、AWS Distro for OpenTelemetry (ADOT) やネイティブな OpenTelemetry に移行すると、アプリケーションヘルスモニタリングの強化のための CloudWatch Application Signals や、アプリケーションのトランザクションスパンへの完全な可視性を提供する Transaction Search などの強力なツールにアクセスできるようになります。 OpenTelemetryについてさらに学び、OpenTelemetry を活用する AWS CloudWatch のより多くのソフトウェアソリューションを活用するには、以下のリソースを参照してください。 Amazon CloudWatch with OpenTelemetry では、OpenTelemetry を使用してアプリケーションで CloudWatch を使用する方法を説明し、 Application Signals や Transaction Search などの強力なツールを有効にする方法を説明しています。 X-Ray 計測から OpenTelemetry 計測への移行 では、 AWS Distro for OpenTelemetry (ADOT) または OpenTelemetry SDK の使用に切り替える方法の例を説明しています。 OpenTelemetry の公式ドキュメントでは、OpenTelemetry の使用に関するすべてのノウハウを説明しています。 フィードバック サポートが必要な場合やフィードバックがある場合は、AWS サポートまでお問い合わせください。 https://aws.amazon.com/jp/contact-us/ また、GitHub ( Java , Python , JavaScript , .NET , Go , Ruby ) でディスカッションやissueを開くこともできます。AWS X-Ray SDKs と Daemon for AWS X-Ray をご利用いただき、ありがとうございました。 Jonathan Lee Jonathan Leeは、AWS の AWS Application Observability のソフトウェア開発エンジニアです。彼は、アップストリームと AWS Distro of OpenTelemetry の両方でオープンソースに貢献しています。 Naina Thangaraj Naina Thangaraj は AWS Batch のシニアプロダクトマネージャーであり、AWS の Advanced Computing and Simulation 組織で働いています。彼女のバックグラウンドはバイオインフォマティクスで、AWS に入社する前は、ヘルスケアとライフサイエンス業界で働いていました。 本記事は、 Announcing AWS X-Ray SDKs/Daemon End-of-Support and OpenTelemetry Migration を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

※ この投稿はお客様に寄稿いただいた記事です。 本稿では株式会社 NTTドコモ（以下、ドコモ）の主要な Web サービス提供基盤である『 POPLAR 』において、 Amazon Q Developer 活用により開発効率向上を実現した取り組みについて、全 2 回に分けてご紹介します。 第1回：NTT ドコモの Web サービス基盤『 POPLAR 』開発における Amazon Q Developer 活用 (本記事) 第2回： Amazon Q Developer 活用をプロジェクト全体へ拡げた取り組み 1.はじめに 『 POPLAR 』は、ドコモの主要Webサービスを提供する基盤であり、現在、30以上の Web サービスを提供しています。 AWS を利用することで、各種 Web サービスをユーザトラヒック変動に柔軟に対応可能なアーキテクチャとして構築しました。さらに、新規 Web サービス提供時の開発期間短縮を実現しています。 また、アプリケーションのアーキテクチャを AWS Lambda や AWS Fargate といったマネージドサービスを活用したアーキテクチャへ進化させることで、開発・運用の最適化を進めています。 さらに、複数の Web サービスを同時並行で短期間に開発・改善するため、マネージドサービスの活用に加え、アーキテクチャモデルの標準化にも取り組んでいます。アーキテクチャモデルの標準化には AWS CDK を活用し、類似機能ごとにアーキテクチャをモデル化しています。複数の開発案件でアーキテクチャモデルを共用することで、開発効率の大幅な向上を実現してきました。 また、我々は AWS が提供するソフトウェア開発生成 AI アシスタントである Amazon Q Developer に注目し、プロジェクト全体で Amazon Q Developer を開発者の教師役として有効活用するべく日々取り組んでいます。 図1. POPLAR アーキテクチャ標準化の取り組み 2.開発における課題 移り変わりの激しい市場動向に対応するために、ドコモが提供する各種 Web サービスにおいても、”速さ”と”品質”を維持したサービス改善が要求されます。POPLAR では、標準化したアーキテクチャモデルを用いて、複数の Web サービスに対して短期間且つ同時並行で機能開発を進めています。 一方で、サービス改善に関する開発を進める過程において、以下の様な課題を抱えています。 課題①　開発の大部分を占める既存機能の改修案件において、既存機能の知見やノウハウの有無が開発生産性に与える影響が大きく、既存機能の知見及びノウハウの習得は開発遂行の上で必要条件となります。一方で、5 年以上の基盤運用実績から提供機能数も多くなり、既存機能の知見及びノウハウ継承には、大きな労力が掛かります。 課題②　開発要員のローテーションの際には、交代要員の立ち上がり期間を十分に確保しつつ、既存開発者からの様々な支援を必要とします。一例をあげると、交代要員が本プロジェクトの開発に必要な技術的スキル、既存機能の知見及びノウハウを習得して貰うために、一定期間、既存開発要員が教育へ大きな労力とを掛ける必要があります。 課題③　障害時にサービス影響のある機能も担っており、開発において相応の品質を求められます。開発者にはアプリケーションからインフラまで幅広い技術的知識が必要となりますが、その技術的要件を全て満たした開発者は市場でも数少なく、大半の開発者は開発遂行にあたって技術的知識の不足部分に対するプロジェクトからの技術的支援を必要とします。 これらの課題を解決し、各種サービスからの改善要求を満たした開発を安定的に実施するためには、以下の仕組みが必要となります。 既存機能およびノウハウについて、労力(時間)をかけずに効率的に継承できる仕組み 不足する技術スキルを短期間で習得できるよう支援・補完する仕組み これらの課題を解決するために、我々は、AWS が提供するソフトウェア開発生成 AI アシスタントである Amazon Q Developer を開発者の教師役としてプロジェクト全体で活用しています。 3. Amazon Q Developerを活用した開発の取り組み POPLAR の開発プロジェクトにおいては、全体で 50 名以上の開発者が携わっています。これらの開発者は Amazon Q Developer Pro サブスクリプションを日常的に利用しています。さらに、プロジェクトに携わる開発者が Amazon Q Developer を有効活用するために、環境準備を支援する設定ガイド、開発時の Amazon Q Developer を活用する方法をまとめたガイドラインを整備する等、POPLAR の開発プロジェクト全体で利用促進を図りました。 また、 Amazon Q Developer から有益な支援を得るために、以下のようなコンテクストを Amazon Q Developer に与える工夫も実施しています。 今までの開発で積み上げてきた既存ソースコード  標準化したアーキテクチャモデル  開発ルールをまとめた設定ファイル AWS が提供する MCP サーバ これらの営みにより、標準化したアーキテクチャモデル等、POPLAR の既存の仕組みや AWSド キュメントに記載された仕様を踏まえた Amazon Q Developer からの支援を実現しています。 図2. Amazon Q Developer の利用条件・環境について 4. Amazon Q Developer による開発効率向上への寄与 Amazon Q Developer の活用は、学習用途で開発者がノウハウや技術的知識を吸収するだけに留まりません。 開発者の教師役として、 Amazon Q Developer に開発ドキュメントを読み込んで貰い仕様調査に協力して貰う、 Amazon Q Developer を壁打ち役として仕様検討を手伝って貰う、または、 Amazon Q Developer に改修コードを提案して貰う等、各開発工程においても幅広く支援を受けることが可能です。 既存機能の改修を前提とした開発において Amazon Q Developer を最大限活用することで、影響調査、設計及び設計とコーディング（自動コーディング）といった開発工程において生産性の向上が見込めることも確認しました。 特に、既存機能の改修においては、既存ソースコードを Amazon Q Developer に対するインプット情報として活用することにより、 Amazon Q Developer との最小限のやり取りで高い精度のアウトプットが得ることができ、 Amazon Q Developer を活用しない従来の開発手法と比べて各開発工程において開発品質向上及び開発期間の短縮を確認できています。 また、開発プロジェクトへの所属期間が短く、既存機能への知見も多くない開発要員が Amazon Q Developer を活用することで、習熟期間の短縮、開発期間の短縮及び開発品質の向上等の高い支援効果が得られることも確認しました。 5.まとめ 第一回の事例では、ドコモの主要な Web サービス提供基盤である『 POPLAR 』における Amazon Q Developer の活用方法及び開発者の教師役として Amazon Q Developer を活用することの有用性についてご紹介しました。 開発ノウハウの継承や開発生産性向上に取り組む皆様の参考にしていただければ幸いです。 次回は以下をご紹介します。 Amazon Q Developer 活用をプロジェクト全体へ拡げた取り組み 著者について 株式会社 NTTドコモ 情報システム部 デジタルデザイン担当 担当部長 深谷 治男 ( Haruo Fukaya ) 担当課長 小柴 辰久 ( Tatsuhisa Koshiba ) 主査 川口 晃平 ( Kouhei Kawaguchi )  

はじめに AWS では、データコラボレーションサービスの提供を超えて、様々な業界の企業間でのデータコラボレーションを加速できるような機会創出にも力をいれています。2025 年 9 月、スマートニュース/AWS共催で広告・マーケティング領域におけるデータコラボレーションワークショップを開催しましたので、ワークショップの開催背景と当日の内容をご紹介いたします。 スマートニュース株式会社が提供する「SmartNews」では、日本最大級のユーザー数を誇るニュースアプリとして多様なユーザーの興味関心データを保有している他、「SmartNews Ads」の広告パフォーマンスデータも保有しています。一方で、データコラボレーションの実現には、セキュリティやプライバシー保護、異業種間でのデータ活用ノウハウの共有という課題がありました。 これらの課題に対応するため、AWSとスマートニュース は共同でワークショップを企画しました。「小売・EC」「メディア」「データ・リサーチ」「航空」等の業界 6 社からお集まりいただき、データコラボレーションのユースケースやAWS Clean Rooms を活用したセキュアなデータ連携の方法について議論しました。さらに、各社が保有するデータ資産を活かした具体的なアクションプランを策定できる場を提供することを目指しました。 開催概要 アジェンダ： 開会のご挨拶 / 参加企業ご紹介 SmartNews のソリューションのご紹介 AWS コラボレーションテクノロジーのご紹介 テーブル別ディスカッション Next Step のご案内 / 閉会のご挨拶 懇親会 前半をセミナー、後半をディスカッションと分けて開催いたしました。後半のディスカッションでは、各企業ごとにデータコラボレーションする際の協業内容について議論を行いました。 データコラボレーションの基本 データコラボレーションとは 本ワークショップのメインテーマであるデータコラボレーションについてご説明します。データコラボレーションとは複数の組織が保有するデータを安全かつ効果的に共有・統合・分析し、単独では得られない洞察や価値を生み出す取り組みです。例えば、メディア企業と小売業が匿名化された顧客データをコラボレーションすることで、より精緻なマーケティング戦略の立案や広告効果測定の高度化が可能になります。重要なのは、各組織のデータプライバシーとセキュリティを維持しながら、必要な情報のみを共有することです。これにより、安全性を確保しつつデータの価値を最大化することができます。 なぜ今データコラボレーションが注目されているのか データコラボレーションの注目が高まっている背景には、デジタル化の加速、消費者行動の複雑化、個人情報を含むデータの保護に関する規制環境の整備があります。さらに 1st party data (自社で直接収集したデータ) の重要性が増していることも大きな要因です。サードパーティ Cookie の廃止や個人情報保護の厳格化に伴い、企業は自社の顧客データをより効果的に活用し、同時に他社のデータと安全に連携する必要性が高まっています。このデータ活用と連携が、企業の競争優位性を生み出す鍵となっています。実際、多くのグローバル企業がデータコラボレーション強化を推進しており、日本においても今後のビジネス戦略において重要な役割を果たすことが予想されます。   各セッションのハイライト SmartNews のソリューションのご紹介 スマートニュース株式会社 執行役員 日本広告事業責任者 兼 社長室長 西出 拓氏 スマートニュース 西出氏より、SmartNews の広告ソリューションと今後のデータ活用の展望についてご紹介いただきました。SmartNews は日本最大級のユーザー数を誇るニュースアプリとして、老若男女・地域問わず日常利用されており、「SmartNews Ads」についてもリーチから、想起、理解、利用意向、初回/継続購買までフルファネルでご提供する広告ソリューションを展開しています。 データソリューションの領域では、AWS Clean Roomsを活用して、広告パフォーマンスデータに加えて、ユーザー属性や閲読行動を活用したソリューションを開発中である旨を説明されました。今回のワークショップを通じて、参加企業の皆様との協業により、ブランドリフト調査や効果測定などの領域で新たな価値創造を目指していきたいとのことでした。 AWS のコラボレーションテクノロジー アマゾン ウェブ サービス ジャパン 合同会社 シニアソリューションアーキテクト 石見和也 AWS  Japan 石見より、データコラボレーションを AWS 上で実現する方法についてご説明を行いました。まずはデータコラボレーションを支える AWS Clean Rooms というマネージドサービスについてご紹介しました。主な特徴として、セキュアなデータ共有、SQL を用いた柔軟な分析環境、実行する SQL の制御機能、緻密なアクセス制御、大規模データセットに対するスケーラビリティがあります。このサービスにより、企業は自社データを保護しつつ、連携先企業とのデータコラボレーションを実現し、新たなビジネス機会を創出できます。これに加えて新機能で企業間で類似セグメントの作成を支援する AWS Clean Rooms ML、名寄せのサービスである AWS Entity Resolution のご説明をいたしました。 テーブル別ディスカッション ワークショップのメインとなったテーブル別ディスカッションでは、具体的なデータコラボレーションのユースケースについて活発な議論が交わされました。参加企業の皆様には事前に各社のデータ資産や活用課題を伺った上で、実践的なユースケースを準備したことで、より深い議論が可能となりました。 あるテーブルでは、意識データとニュース閲覧データを組み合わせた広告セグメントの説明性向上について話し合われ、ブランドリフト層の深いインサイト可視化やインターゲット率の証明に注目が集まりました。別のテーブルでは、会員データや購買データとの連携による効果測定の高度化が議論され、データクリーンルームを活用した安全なデータ突合の可能性が探られました。さらに別のテーブルでは、位置情報データを活用した来店計測やブランドリフト調査について、具体的な協業の進め方が検討されました。 お客様の声 本ワークショップは、広告・マーケティング領域におけるデータコラボレーションの可能性を探る貴重な機会となりました。参加企業の皆様からは、「昨今の潮流を踏まえて何ができるか色々議論できて良い機会だった」「ビジネスの協業の可能性を、テクノロジーの観点でも裏付けしながら議論を進めることができた」「具体的な提案打ち合わせではなく、複数社でオープンディスカッションができる機会というのが新鮮で予想していなかった協業の可能性が見えた」といった前向きな声を多数いただきました。ワークショップ後も、各社との具体的な協業に向けた議論が継続しており、データコラボレーションに対する高い期待が伺えます。 おわりに 本ワークショップを通じて、データコラボレーションによる新たな広告・マーケティングソリューション創出の大きな可能性と、参加企業の皆様の熱意を肌で感じることができました。ここに改めて、ご参加いただいた企業の皆様、そして共催である スマートニュース社の皆様に心より感謝申し上げます。AWS は、今後もこの様なデータコラボレーションを推進する取り組みのご支援や、皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、ソリューションアーキテクト石見が担当しました。

本ブログは、 仰星監査法人 と 株式会社 Sapeet 、 Amazon Web Services Japan が共同で執筆しました。 仰星監査法人 (以下：仰星) は、1990 年設立の監査・保証業務をはじめとする株式上場 (IPO) 支援業務やファイナンシャルアドバイザリーサービスなどの各種サービスを提供する法人です。本ブログでは株式会社 Sapeet (以下：Sapeet) が開発・導入を支援した、仰星での社内生成 AI 基盤の概要とその中でどのように AWS のサービス群が活用されているかを紹介します。 課題と背景 仰星では監査業界の構造変化が日々すすむなか、監査現場におけるチームメンバーの支援やクライアントからの複雑な要求に高いレベルで応えていくために、業務効率化が急務となっていました。その生産性向上を目指した取り組みを始めるにあたり、生成 AI の活用が候補となりましたが、導入に向けていくつかの課題が浮上しました。主な課題は以下の通りとなります。 機密性の高い情報やデータを、セキュリティ面で万全な環境下で取り扱うこと 投資対効果を重視し、特定の業務領域に焦点を絞って効率的に導入・活用すること スピード感を持って検証を行い、その成果を迅速に実運用へとつなげること これらの課題に対し、より実用的で効果的な生成 AI 活用の基盤づくりが求められていました。 ソリューションの概要 そのような課題がある状況で生成 AI の活用検証にあたり、 Dify を用いた生成 AI 環境を AWS 上で構築いただくこととなりました。Sapeet が開発パートナーとして、以下の要素を考慮し、Amazon Bedrock や Dify といったサービスを選定・活用しました。 すでに Amazon WorkSpaces をはじめ AWS の利用が進んでいたこと AWS のサービス群の幅広さによるアプリケーション開発の自由度と効率性の両立 機微なデータをセキュアな環境内で取り扱えること Dify を活用し、PoC フェーズでの高速開発からセキュアな環境でのセルフホストまで一貫して実現できること 今回の生成 AI アプリケーションでは、主に監査業務における固有リスク要因の洗い出し作業を効率化することを目的としています。これまで Web での情報収集・記事チェック・資料保存・アウトプット作成などの単純ながらも時間を要する作業を生成 AI 側で対応することで、時間短縮だけでなく、人間では見落としがちな新しい視点も獲得することに成功しています。 図 1: 社内業務担当者の生成 AI アプリケーション利用イメージ 今回の開発においては、Dify を用いることでノーコード / ローコードで生成 AI のワークフローを作成し、短時間でプロジェクトのスモールスタートを切ることができました。 また、Amazon WorkSpaces を利用することで重要な社内データをインターネットから隔離され閉域で安全に AWS に展開された VDI 環境に接続・利用を限定することができ、セキュアな環境での作業を可能としています。 Amazon Bedrock のモデルでは、データをモデルの再学習に利用せず、サードパーティにも渡されないことを明言していることも安心して利用できる材料のひとつとなっています。 以下の図 2 が仰星監査法人　生成 AI 基盤のアーキテクチャーの概要になります。 図 2: 仰星監査法人 生成 AI 基盤のシステム構成 開発におけるユーザー企業と開発企業の連携の重要性 今回の開発において、開発をリードした Sapeet が仰星の実際の業務プロセスを理解し、ワークショップでも現場の公認会計士を巻き込んでプロジェクトを遂行したことが、実ユーザーが使いやすいアプリケーションを作るにあたっての成功要因のひとつとなりました。 導入までの 5 か月間の期間の使い方として、最初の１か月で監査業務の理解とデータ確認を仰星・Sapeet 両社で行ったのち、MVP 作成後は週次でアップデートを重ねていきました。特にプロンプトの作りこみについては実業務の担当者に協力を得ながら専門知識を反映させつつ共同開発をしたことで業務に利活用できるレベルに精度を上昇させることに成功しています。今回の開発をリードした Sapeet の村上 AI ソリューション事業部プロジェクトマネージャーは以下のように語ります。「お客様から言われたことをただ実装して結果だけ見てもらうのみでは、真に業務活用に足りうる生成AIアプリケーションを作ることはできないと考えています。業務内容を我々自身が深い部分まで理解する姿勢と、仰星様にも生成 AI で実現している中身を理解してもらった上で意見をいただくことで、お互いが持っているものを出し合って一緒に作り上げることができました」 導入効果と今後の展開 5 か月の開発を経て導入された今回の生成 AI アプリケーションを活用することで、当該作業時間を 87% 削減することに成功し、投資に対する回収の期間もすでに見通しが立つ状況となりました。また、生成 AI 側では情報収集・分析を行い、人間で最終的な監査リスクの判断を行うことで役割分担を明確化しつつ、網羅的な分析が可能になったと仰星の金子理事・情報管理室長は語ります。「生成AIを用いることで、これまで以上に情報量が圧倒的に増加し、新たな視点でのリスク要因発見にもつながっています。今後、暗黙知を形式知化していくための道筋が見えてきました。」 また、導入後のアンケートにおいて、スタッフからパートナーまで職位に関係なく「生成 AI 活用による業務効率化の可能性が高い」という評価を得られたことも今後の活用領域拡大に向けてポジティブな判断材料となりました。 現在仰星では今回の会計士業務に関連する生成AI基盤だけでなく、各種 SaaS サービスも用いた AI の活用を推進しています。「クラウドの良さであるスピード感を生かせたと感じています。社内での生成 AI に対する理解と親近感も向上したという手ごたえも感じているので、さらにその活用範囲を高める動きをしていきます」と将来のさらなる社内生成 AI 推進に高い意欲をのぞかせています。 今後の展開としては、この生成 AI アプリケーションを通じて組織にナレッジが蓄積し、集合知として更なる監査業務の効率化・品質向上に活用することで、組織全体の「ナレッジ循環」の仕組みを構築していきます。 まとめ 本ブログでは 、仰星で導入したクライアント情報収集・環境分析アプリの紹介とその中で Dify や Amazon Bedrock、Amazon WorkSpaces がどのように活用されているかを紹介しました。 これらを利用することによってみなさまの AWS 上のワークロードに生成 AI を活用した機能を容易に組み込めます。本ブログが生成 AI を活用されている皆様の参考になりましたら幸いです。

「金融リファレンスアーキテクチャ日本版」は、金融システムで求められるセキュリティと可用性に関するベストプラクティスを提供するフレームワークとして 2022 年 10 月に正式版として発表し、多くのお客様にご利用いただいております。この度、皆様からいただいたご意見およびクラウド活用の広がりを踏まえて新たなコンテンツを追加した 2025版 (Version 1.6) を公開しました。 2025版(v1.6)の全体像 AWS 金融リファレンスアーキテクチャ日本版の最新フレームワークは下図の通りです。 新たにサイバーレジリエンスとマイクロサービスアプリケーションに関するワークロードを追加しました。既存コンテンツについては、勘定系ワークロードのレジリエンス機能の強化やコンタクトセンター(顧客チャネル)ワークロードへの生成 AI 機能の追加を行っています。加えて、特定の金融ユースケースでのアーキテクチャ上の重要ポイントを詳細解説する“ユーザ事例”コンテンツを新設しました。2025年中にさらに生成AI ワークロードの追加、Well-Architected Framework の FSI Lens for FISC の更改、保険ユーザ事例の追加を予定しています。ご期待ください。 以下はアップデートの概要です。詳細は各ワークロードの解説ブログをご確認ください。 2025版(v1.6)のアップデート詳細 サイバーレジリエンスワークロードを新規公開 サイバー攻撃に対しては、攻撃を受けても迅速にシステムを復旧し事業を継続する ”サイバーイベントリカバリ” が重要です。そのために準備しておくためのリファレンスアーキテクチャーを公開しました。詳細は解説ブログ: サイバーレジリエンス:サイバーイベントリカバリの実装 をご覧ください。 イベントドリブンな金融モダンアプリケーション実装を公開 高い可用性とスケーラビリティを求められるミッションクリティカルなアプリケーションをモダンなマイクロサービスアーキテクチャで実装する事例が増えています。今回、モバイルバンキング題材にしたリファレンスアーキテクチャーとサンプルアプリケーションを公開しました。詳細は解説ブログ: イベントドリブンな金融モダンアプリケーション実装を公開 をご覧ください。 ミッションクリティカルワークロード(勘定系) でマルチリージョンの回復力と可観測性を強化 ミッションクリティカルなオンライントランザクションシステムのリファレンスである勘定系システムに大きく3つの Update を行いました。 外形監視と組み合わせたリージョン切り替え/切り戻しの完全自動化 Amazon CloudWatch Application Signals によるマイクロサービスのオブザーバビリティ強化 Amazon Aurora DSQL による ディザスタリカバリ における RTO を短縮する実装例 詳細は解説ブログ: レジリエンスライフサイクルで進化する – ミッションクリティカル[勘定系] ワークロード をご覧ください。 コンタクトセンター (顧客チャネル) ワークロードに生成 AI 機能を追加 Amazon Connect によるコンタクトセンターのリファレンスアーキテクチャに、通話のライブ文字起こし機能、生成 AI を利用した通話チェックと要約機能を追加しました。他にも、ウェブ通話、Amazon Q in Connect の AI アシスタント （下図参照）を追加し、あらゆるチャネルでのカスタマーエクスペリエンスを向上策として使っていただく事ができます。 こちら からすぐにデプロイして試していただく事が出来ます。 金融ユーザ事例の解説コンテンツ を新設 AWS を実際にご利用いただいている国内外の金融機関のお客様事例をベースに、より具体的なシステムアーキテクチャを紹介しています。こちらでは、業務およびシステム特性に最適化したアーキテクチャとその考慮ポイントに重点をおいて解説しています。 [証券] 資本市場 Order Management System (OMS) [決済] クレジットカード イシュアシステム おわりに 金融リファレンスアーキテクチャ日本版の全てのコンテンツは GitHub リポジトリから利用できます。フィードバックや質問については Issue として GitHub サイト上に登録いただけますし、執筆者に直接ご連絡頂いても構いません。ご利用される皆様からのニーズや意見に基づいて今後の改善方針を決めていきたいと考えておりますので、ご質問やフィードバックをお待ちしております。 本ブログ記事は、AWS のソリューションアーキテクトである 深森 広英 が執筆いたしました。

「 金融リファレンスアーキテクチャ日本版 」は、金融で求められるセキュリティと可用性に関するベストプラクティスを提供するフレームワークとして 2022 年 10 月に正式版として発表し、多くのお客様にご利用いただいております。この度、モダンアーキテクチャのサンプルとして、オンラインバンキングアプリケーションのユースケースを公開しました。本ブログ記事では、オンラインバンキングアプリケーションのユースケースを解説いたします。 ユースケースの紹介 本ユースケースは、モバイルバンキングアプリケーションを題材として、口座開設、残高照会、振込処理の主要機能を各種業務を取り扱うシステムサンプルを提供しています。 今回のリファレンスアーキテクチャでは、分散システムにおける整合性担保の観点で、イベントソーシングパターンを採用しています。金融業界を対象に作成していますが、それに限らず様々な業界のシステムに応用できる汎用的なものとなっています。 金融システムにおけるマイクロサービスアーキテクチャのメリット マイクロサービスアーキテクチャでは各サービスが独立して動作するため、一つのサービスで障害が発生しても他のサービスは正常に稼働し続けることができます。これにより障害の影響範囲を局所化でき、システム全体の可用性を向上させることが可能になります。また、負荷の高いサービスのみを個別にスケールアウトできるため、リソースの効率的な活用とコスト最適化を実現できます。 マイクロサービスとモノリシックなシステムにはそれぞれ異なる特性があり、レジリエンスの観点での詳細な比較や考慮すべきポイントについては、 金融システムにおけるマイクロサービスアーキテクチャのメリット をご参照ください。 リファレンスアーキテクチャの解説 口座開設、振込の二つの処理は非同期処理として利用者からのリクエストを受け付けたのち、AWS Lambda、Amazon Simple Queue Service (Amazon SQS)、Amazon EventBridge を使用し、状態変更を Amazon DynamoDB に変更履歴（監査証跡）イベントとして保管するイベントソーシングの形で実装されています。勘定系 API を呼び出す際の一貫性を担保するため、トランザクションアウトボックスを採用し、AWS Lambda の内部には再実行の仕組みを組み込んでいます。 本リファレンスアーキテクチャでは、以下 三つのスタックに分けて実装されています。 OnlineBankingAppFrontendStack: React SPA によるフロントエンド OnlineBankingAppBackendStack: AWS Lambda + Amazon DynamoDB によるマイクロサービス群 TemporaryCoreBankingSystemStack: 勘定系システムの API を擬似的に作成したバンキングシステム 詳細なアーキテクチャ構成、提供 API、実装の詳細については、 リファレンスアーキテクチャの解説 をご参照ください。 イベントソーシングとは イベ ントソーシングとは、アプリケーションの状態を一連のイベントとして保存するアーキテクチャパターンです。最新状態のみを保持する手法とは異なり、すべての変更をイベントとして記録することで、完全な監査証跡を提供します。金融サービスにおいては、規制遵守と透明性の要件を満たすために特に有効で、取引履歴の完全な追跡が可能になります。これにより例えばアプリケーションの問題による不整合や、インフラ障害が起きた際に単なるデータのバックアップではなく、システム全体の状態を正確に復元することが可能にします。 加えて、Command Query Responsibility Segregation（CQRS）の設計パターンと組み合わせることで、スケーラビリティの向上を容易にします。CQRS とはコマンド（書き込み）とクエリ（読み取り）の責任を分離するパターンで、それぞれの処理を最適化できる利点があります。更新用と参照用で異なるデータモデルとデータストアを使用することで読み書きを分離し、参照処理に特化したデータ構造により高速な検索が可能になります。 イベントソーシング、CQRS 以外にも、Saga パターン、トランザクションアウトボックスパターンなど、分散システムにおける様々なデザインパターンについては、 分散システムにおけるデザインパターン をご参照ください。 おわりに 金融リファレンスアーキテクチャ日本版の全てのコンテンツとコードは、パブリックの GitHub リポジトリ から参照でき、Git リポジトリとしてローカル環境にクローンすることもできます。フィードバックや質問については  Issue として GitHub サイト上に登録いただけます。また、執筆者に直接ご連絡頂いても構いません。ご利用される皆様からのニーズや意見に基づいて今後の改善方針を決めていきたいと考えておりますので、ご質問やフィードバックをお待ちしております。 本ブログ記事は、AWS のソリューションアーキテクトである根本裕規、山下翔平、池田優が執筆いたしました。

Amazon Redshift は、完全マネージド型のペタバイト規模のクラウドデータウェアハウスサービスです。Amazon Redshift を使用することで、ペタバイト規模の構造化データおよび半構造化データに対して複雑なクエリを迅速かつ効率的に実行でき、他の AWS サービスとシームレスに統合できます。 Amazon Redshift Serverless は、データウェアハウスインフラストラクチャのセットアップ、管理、スケーリングを行うことなく、数秒で分析を実行およびスケーリングできるようサポートします。要求の厳しいワークロードに対して高速なパフォーマンスを提供するために、データウェアハウスの容量を自動的にプロビジョニングし、基盤となるリソースをインテリジェントにスケーリングします。また、使用したコンピューティング容量に対してのみ料金をお支払いいただきます。さらに、 Amazon Redshift マネージドストレージ を使用することで、ストレージとコンピューティングを個別にスケーリングし、使用したストレージに対してのみ料金をお支払いいただくことで、データウェアハウスをさらに最適化できます。 Amazon Redshift dense compute (DC2) インスタンスから Amazon Redshift Serverless へデータウェアハウスをアップグレードすることでこれらの利点が得られ、ユーザーエクスペリエンスの向上と運用の簡素化を実現し、より効率的でスケーラブルなデータ分析ソリューションを提供します。 この記事では、DC2 インスタンスから Amazon Redshift Serverless へのアップグレードプロセスをご紹介します。以下の内容を取り上げます： 現在のセットアップの評価とアップグレードの適否の判断 アップグレードの計画と準備 アップグレードプロセスのステップバイステップの手順 アップグレード後の最適化とベストプラクティス Amazon Redshift Serverless にアップグレードする理由 Amazon Redshift Serverless を使用することで、データウェアハウスインフラストラクチャを管理することなく、分析を実行およびスケールできます。DC2 インスタンスから Amazon Redshift Serverless にアップグレードすると、次のようなメリットが得られます。 運用の簡素化 ：コンピュートクラスターのセットアップ、チューニング、管理を必要とせずに、データにアクセスして分析できます。 自動パフォーマンス最適化 ： 自動スケーリング と AI 主導のスケーリングおよび最適化 により、要求の厳しい変動の激しいワークロードに対して一貫した高パフォーマンスと簡素化された運用を実現します。 従量課金制 ：柔軟な料金体系により、アクティブな使用時のみ課金され、使用した分だけ支払います。 オンラインメンテナンス ：Amazon Redshift Serverless は、メンテナンスウィンドウを必要とせずにシステムの更新とパッチを自動的に管理し、データウェアハウスのシームレスな運用を支援します。 ストレージとコンピュートの分離 ：Amazon Redshift マネージドストレージにより、コンピュートとストレージを個別にスケーリングして支払うことで、コストを管理できます。 新機能へのアクセス ： データ共有への書き込み 、 Redshift ストリーミングの取り込み 、 ゼロ ETL 、 その他の機能 を含む高度な機能を使用できます。 サイジングガイダンス DC2 から Amazon Redshift Serverless へアップグレードするには、サイズの同等性を理解する必要があります。次の表は、DC2 ノードタイプからアップグレードする際の推奨サイジング構成を示しています。 Redshift Processing Unit (RPU) 構成の可用性は AWS リージョンによって異なることに注意してください。 既存のノードタイプ 既存のノード数 Amazon Redshift Serverless へのアップグレード DC2.large 1–4 4 RPU から開始 DC2.large 5–7 8 RPU から開始 DC2.large 8–32 DC2.large の 8 ノードごとに 8 RPU を追加 DC2.8xlarge 2–32 ノードごとに 16 RPU を追加（最大 1,024 RPU まで） これらのサイジング見積もりは、Amazon Redshift Serverless を最大限に活用できるよう調整された柔軟な出発点を提供します。お客様のニーズに最適な構成は、コストとパフォーマンスの望ましいバランスや、ワークロードの特定のレイテンシーとスループット要件などの要因によって異なります。特定の要件に基づいてサイジングをさらに最適化するには、以下のアプローチを使用します。 ワークロードの事前テスト ：Amazon Redshift Serverless に移行する前に、非本番環境でワークロードのパフォーマンス要件を評価します。 Amazon Redshift Test Drive ユーティリティ は、さまざまなサーバーレス構成で本番ワークロードをシミュレートすることで、このプロセスを簡素化します。結果を使用して、パフォーマンスとコストの最適なバランスを特定し、構成について情報に基づいた決定を下すことができます。DC2からServerless へのアップグレードでTest Drive ユーティリティを使用するためのステップバイステップのガイダンスについては、 Amazon Redshift Migration Workshop を参照してください。移行前にこれらのパフォーマンステストを実行することで、本番環境にデプロイする前に構成に必要な調整を特定できます。 本番環境での監視 ：ワークロードをデプロイした後、典型的なワークロードを表す期間にわたってパフォーマンスとリソース使用率を注意深く監視します。 監視メトリクス に基づいて、パフォーマンスとコストの最適なバランスを達成するために、必要に応じてリソースをスケールアップまたはスケールダウンできます。 AI 主導のスケーリングと最適化 ：ワークロードのニーズに合わせて Amazon Redshift Serverless を自動的にサイジングするために、AI 主導のスケーリングと最適化を備えた Amazon Redshift Serverless の使用を検討してください。 本番前のテストと継続的な本番環境のモニタリングを組み合わせたサイジング検証への体系的なアプローチにより、Amazon Redshift Serverless の構成がワークロードに適合していることを確実にできます。 Amazon Redshift Serverless へのアップグレード Amazon Redshift Serverless にアップグレードするには、次の図に示すように、スナップショット復元を使用して Amazon Redshift から Amazon Redshift Serverless に直接移行できます。スナップショット復元では、ユーザーとその関連する権限、設定、スキーマ構造に加えて、データとオブジェクトが復元されます。移行にスナップショット復元を使用することで、本番環境の Amazon Redshift DC2 クラスターに影響を与えることなく、ターゲットの Amazon Redshift Serverless ウェアハウスを検証できます。また、スナップショット復元を使用して、Amazon Redshift DC2 ワークロードを異なるリージョンやアベイラビリティーゾーンに移行することもできます。 スナップショット復元を使用した移行の前提条件 名前空間を持つ Amazon Redshift Serverless ワークグループを作成します。詳細については、 名前空間を伴うワークグループの作成 を参照してください。 Amazon Redshift Serverless はデフォルトで暗号化されています。Amazon Redshift Serverless は、組織のセキュリティポリシーに準拠できるよう、 名前空間の AWS KMS キーの変更 もサポートしています。 復元しようとしている Amazon Redshift Serverless 名前空間が Amazon Redshift Serverless ワークグループに関連付けられていることを確認します。 プロビジョニングされた Amazon Redshift クラスターから Amazon Redshift Serverless に復元するには、 AWS Identity and Access Management (IAM) ユーザーまたはロールに次の権限が必要です： redshift-serverless:RestoreFromSnapshot 、 CreateNamespace 、および CreateWorkgroup 。詳細については、 Amazon Redshift Serverless の復元 を参照してください。 コンソールを使用したアップグレード スナップショット復元方式を使用して DC2 クラスターを Amazon Redshift Serverless にアップグレードするには、Amazon Redshift の AWS マネジメントコンソールで以下の手順を実行します。 Redshift コンソールで、ナビゲーションペインの [ クラスター ] を選択します。クラスターを選択し、[ メンテナンス ] を選択します。 [ スナップショットを作成 ] を選択して、既存の Amazon Redshift プロビジョンドクラスターの手動スナップショットを作成します。 スナップショット識別子を入力し、スナップショット保持期間を選択してから、[ スナップショットを作成 ] を選択します。 リストから Amazon Redshift Serverless に復元するスナップショットを選択し、[ スナップショットを復元 ] を選択してから [ サーバーレス名前空間への復元 ] を選択します。 [ 名前空間を選択 ] で、ドロップダウンリストからターゲットのサーバーレス名前空間を選択し、[ 復元 ]を選択します。 復元にかかる時間はデータ量によって異なります。 復元が完了したら、 Amazon Redshift Query Editor v2 または任意の SQL クライアントを使用して Amazon Redshift Serverless ワークスペースに接続し、データ移行を確認します。 詳細については、 プロビジョニングされたクラスターのスナップショットを作成する を参照してください。 AWS CLI を使用したアップグレード AWS Command Line Interface (AWS CLI) で以下の手順を使用して、スナップショット復元方式により DC2 クラスターを Amazon Redshift Serverless にアップグレードします。 ソースクラスターからスナップショットを作成します: aws redshift create-cluster-snapshot --cluster-identifier <your-dc2-cluster-id> --snapshot-identifier <your-snapshot-name> スナップショットが存在することを確認します: aws redshift describe-cluster-snapshots --snapshot-identifier <your-snapshot-name> スナップショットを Amazon Redshift Serverless 名前空間に復元します: aws redshift-serverless restore-from-snapshot --snapshot-arn "arn:aws:redshift:<your-region>:<your-account-number>:snapshot:<source-cluster-id>/<your-snapshot-name>" --namespace-name <your-serverless-namespace> --workgroup-name <your-serverless-workgroup> --region <your-region> 詳細については、 AWS CLI を使用したクラスタースナップショットからの復元 を参照してください。 Amazon Redshift Serverlessへのアップグレードのベストプラクティス Amazon Redshift から Amazon Redshift Serverless へのアップグレード時に推奨されるベストプラクティスは以下の通りです。 アップグレード前 : サイジングガイダンス を使用して、適切なターゲット構成を決定します。 Amazon Redshift Test Drive を使用して概念実証 (POC) を実行し、ターゲット構成を検証します。 CNAME の使用を検討します。正規名 (CNAME) レコードは、Amazon Redshift クラスターのエンドポイントのエイリアスを作成するために使用できる DNS レコードの一種です。 インターリーブソートキーを使用している場合、プロビジョニングされたクラスターのスナップショットをサーバーレス名前空間に復元すると、Amazon Redshift は自動的にそれらを複合キーに変換します。詳細については、 Amazon Redshift Serverless を使用する際の考慮事項 を参照してください。 Amazon Redshift Serverless の一部の概念と機能は、Amazon Redshift プロビジョニングデータウェアハウスの対応する機能とは異なります。これには、システムテーブルとビュー、監査ログ、エンドポイント名の違いが含まれます。これらの違いの完全なリストについては、 Amazon Redshift Serverless と Amazon Redshift プロビジョニングデータウェアハウスの比較 を参照してください。 Amazon EventBridge を使用した Amazon Redshift Serverless のイベント通知 を購読し、移行プロセス中のイベントの通知を受け取ります。 アップグレード後 : 既存の接続を更新 : Amazon Redshift Serverless に移行すると、新しいエンドポイントが作成されます。ビジネスインテリジェンスやその他のレポートツールへの既存の接続を更新してください。 可観測性と監視 : システムビューを使用するデータ監視ツールがある場合は、オープンまたは空のトランザクションがないことを確認してください。ベストプラクティスとして、トランザクションを終了することが重要です。オープントランザクションを終了またはロールバックしない場合、Amazon Redshift Serverless はそれらのトランザクションに対して RPU を使い続けます。 アクセス : dbUser および dbGroups での IAM 認証を使用する場合、アプリケーションは GetCredentials API を使用してデータベースにアクセスできます。詳細については、 IAM を使用した接続 を参照してください。 システムビュー : Amazon Redshift Serverless で利用可能な 統合システムビュー のリストを確認してください。 ワークロードの性質、または Amazon Redshift Serverless 使用時の考慮事項 に記載されている考慮事項のいずれかにより、ワークロードが Amazon Redshift Serverless に適していない場合は、 RA3 サイジングガイダンス に従って Amazon Redshift RA3 インスタンスにアップグレードします。 コスト面の考慮事項 このセクションでは、Amazon Redshift Serverless のコストを理解し、管理するための情報を提供します。 予測可能な使用パターンがある場合は、事前に 容量を予約 することでサーバーレスコンピューティングのコストを削減できます。 Amazon Redshift Serverless は、ワークロードに基づいて自動的に容量を調整します。 最大 RPU 制限 を設定することで、システムがスケールアップできる上限を設定し、コストを管理できます。 Amazon Redshift Serverless はコンピューティングユニットとしてRPUを使用します。デフォルトでは 128 RPU から開始しますが、特定のワークロードニーズと SLA 要件に合わせて、ベース RPU を 4 から 1,024 RPU の範囲で調整できます。詳細については、 Amazon Redshift Serverless の請求 を参照してください。 Amazon Redshift Serverless は、30 分ごと、またはノードあたり 5 GBのデータ変更が発生した場合のいずれか早い方で、自動的にリカバリポイントを作成します。リカバリポイント間の最小間隔は 15 分です。すべてのリカバリポイントは、デフォルトで 24 時間保持されます。 より長期間バックアップを保持する必要がある場合は、手動バックアップを作成できます。手動バックアップには追加の ストレージコスト が発生します。 Amazon Redshift Serverless の AI 主導スケーリングと最適化により、シンプルなスライダーでコンピューティングリソースを簡単に調整し、予算とパフォーマンスニーズのバランスを取ることで、コストを削減できます。 クリーンアップ 今後の料金が発生しないようにするには、前提条件の手順の一部として作成した Amazon Redshift Serverless インスタンスまたはプロビジョニングされたデータウェアハウスクラスターを削除してください。詳細については、 ワークグループの削除 および クラスターのシャットダウンと削除 を参照してください。 結論 この投稿では、Amazon Redshift DC2 インスタンスを Amazon Redshift Serverless にアップグレードするメリットに加えて、アップグレードのための様々なオプションといくつかのベストプラクティスについて説明しました。アップグレードを実施する前に、対象となる Amazon Redshift Serverless の構成を決定し、テスト環境および開発環境で Amazon Redshift Test Drive ユーティリティを使用して検証することが重要です。 この投稿のガイダンスを実装して、今すぐ Amazon Redshift Serverless へのアップグレードを始めましょう。ご質問がある場合やサポートが必要な場合は、アーキテクチャおよび設計のガイダンス、さらに概念実証や実装のサポートについて、AWS サポートにお問い合わせください。 著者について Nita Shah Nita は、ニューヨークを拠点とする AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。彼女は 20 年以上にわたってデータウェアハウスソリューションを構築しており、Amazon Redshift を専門としています。顧客がエンタープライズ規模の適切に設計されたアナリティクスおよび意思決定支援プラットフォームを設計・構築することを支援することに注力しています。 Ricardo Serafim Ricardo は AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。2007 年以来、企業のデータウェアハウスソリューションを支援してきました。 Bryan Cottle Bryan は Amazon Web Services のシニアテクニカルプロダクトマネージャーです。彼は分析データベースに情熱を注いでおり、特に Amazon Redshift を専門としています。そこでは、顧客のコスト最適化、価格戦略のナビゲート、データベース移行の成功支援を行っています。 Sémir Naffati Sémir は、フランス・パリを拠点とする AWS のシニアワールドワイドスペシャリストソリューションアーキテクトです。データとアナリティクスにおける 25 年以上の経験を持ち、エンタープライズ顧客の複雑なクラウド変革を支援することを専門としています。彼の専門知識は、レガシーデータベースシステム(Oracle、SQL Server)から最新のクラウドネイティブアーキテクチャ(Redshift、Iceberg)およびAIサービスまで幅広く及びます。顧客が最も困難なデータ課題を解決し、スケーラブルでコスト効率の高いソリューションを構築できるよう支援することに情熱を注いでいます。 翻訳は、ソリューションアーキテクトの駒野が担当しました。 原文 はこちらです。

本記事は 2025 年 10 月 23 日に公開された Brian Beach による “Teaching Kiro new tricks with agent steering and MCP” を翻訳したものです。 はじめに 過去 3 年間、私は数百の顧客がソフトウェア開発に AI ツールを採用するのを支援してきました。これらの顧客の多くは、独自のライブラリ、ツール、さらにはドメイン固有言語（DSL）を開発しています。ワークフロー自動化言語、設定構文、ルールエンジンなど、これらのカスタマイズはビジネス運営の基盤となっています。しかし、AI コーディングアシスタントにこれらの独自ライブラリを理解させ、連携させたい場合はどうすればよいでしょうか？ この記事では、AI エージェントおよび開発環境である Kiro に、MathJSON というライブラリを理解させる方法を探ります。MathJSON はこのデモンストレーションのために作成された架空のライブラリですが、企業が日常的に使用するワークフロー言語、設定システム、専門的な表記法の代理として機能します。この記事全体を通して、 ステアリング と Model Context Protocol（MCP） について説明し、これらを組み合わせて Kiro に新しいスキルを教える方法を紹介します。 MathJSON との出会い この記事では、MathJSON を使用します。これは、適切な数学用語を使用する JSON ベースの数式表現言語です。MathJSON はこの記事のために作成されたものであり、実際のアプリケーションでの使用は推奨しないことに注意してください。以下が興味深い点です。 主な特徴 構造化された数式表現のための JSON ベースの構文 適切な数学用語 (加数、被減数、被乗数など) 複雑な計算のための ネストされた式 豊富な関数ライブラリ (三角関数、対数、定数) ファイル拡張子 : .math 式の例 { "multiplication": { "multiplicand": {"pi": {}}, "multiplier": { "pow": { "base": {"variable": "env:RADIUS"}, "exponent": 2 } } } } この例は、環境変数として渡された半径に対する円の面積を計算します。 pi * radius^2 ステアリングファイルで Kiro をガイドする ステアリングは、マークダウンファイルを通じてプロジェクトに関する永続的な知識を Kiro に提供します。これらのファイルは .kiro/steering/ に保存され、ワークスペース内のすべてのインタラクションにコンテキストと指示を提供します。ステアリングファイルには、コーディング標準、プロジェクト構造などが含まれます。 最初に思いつくのは、MathJSON のドキュメントをステアリングフォルダに追加することかもしれません。私はまさにそれを行い、 function_reference.md ファイルをステアリングフォルダに追加しました。これは良いスタートですが、いくつかの問題があります。第一に、ドキュメントは人間向けに書かれています。その結果、冗長で繰り返しが多くなります。第二に、Kiro が従うべき具体的なベストプラクティスが欠けています。第三に、プロジェクトフォルダにコピーされたドキュメントは必然的に古くなります。これらの問題とその対処方法を見ていきましょう。 ステアリングファイルの洗練 克服したい最初の問題は、ドキュメントの冗長性です。 当然ながら、適切なドキュメントが存在することを前提としています。もしない場合は、Kiro が生成を手伝ってくれます。 人間向けに作成されたドキュメントは、ステアリングファイルに含めるには冗長すぎることがよくあります。MathJSON はこの記事のために作成したシンプルなプロジェクトですが、それでも 6 つのマークダウンファイルにわたって 3500 行以上のドキュメントがあります。これは、Kiro とのすべての会話に追加するには情報が多すぎます。 幸いなことに、Kiro はステアリングファイルを洗練してくれます。Kiro でステアリングファイルを開き、 Refine ボタンを選択するだけです。Kiro はファイルを読み取り、最適化してくれます。 Kiro が行った変更の 1 つを見てみましょう。元のドキュメントでは、加算は次のように説明されています。 ## 算術演算 ### 加算 適切な数学用語を使用して2つの数値の加算を実行します。 **構文:** ```json { "addition": { "addend1": , "addend2": } } ``` **パラメータ:** - `addend1` (number|expression): 加算する最初の数値 - `addend2` (number|expression): 加算する2番目の数値 **戻り値:** 2つの加数の合計 **数式:** addend1 + addend2 = sum **例:** ```json // 単純な加算 { "addition": { "addend1": 15, "addend2": 25 } } // 結果: 40 // ネストされた式を使用した加算 { "addition": { "addend1": { "multiplication": { "multiplicand": 3, "multiplier": 4 } }, "addend2": 8 } } // 結果: 20 (12 + 8) ``` Kiro はこれを洗練し、1 行に置き換えました。ネストされた式などの詳細は、洗練されたファイルで一度だけカバーされ、各操作の例で繰り返されることはありません。したがって、ここで繰り返す必要はありません。 ### 算術演算 - `addition`: `{addend1, addend2}` - 基本的な加算 全体として、これは素晴らしいスタートです。ステアリングファイルは 3,500 行から 102 行に削減されました。他に何もしない場合でも、refine オプションを使用してステアリングファイルを最適化してください。ただし、さらに改善を続けることができます。 ベストプラクティスの定義 克服したい次の問題は、ドキュメントの具体性です。ユーザードキュメントは広範囲にわたる傾向があります。ライブラリや言語を使用できるすべての方法をカバーすることに焦点を当てています。しかし、ステアリングファイルは指針を持つべきです。Kiro が MathJSON を どのように使用できるか を伝えるのではなく、Kiro が どのように使用すべきか を正確に伝えたいのです。 Kiro は前のセクションでドキュメントを洗練したときにベストプラクティスの定義を開始しました。しかし、追加のルールを加えます。具体的には、Kiro が書くすべてのコードを検証およびテストすることを望んでいます。そこで、いくつかの新しいベストプラクティスを追加します。 5. **リテラルよりも定数**: 精度のために`3.14159`の代わりに`{"pi": {}}`を使用 6. **コードを検証**: `mathjson`がローカルにインストールされていると仮定します。`*.math`ファイルを作成または編集するときは、リントとテストを行います。 ステアリングファイルには、コマンドラインツールの使用方法に関する指示がすでに含まれていることに注意してください。それを繰り返すのではなく、Kiro にいつ使用するかを指示しています。ステアリングファイルは形になり始めていますが、時間の経過とともにどのように最新の状態を保つのでしょうか？ 知識を最新の状態に保つ 克服したい最初の問題は、ドキュメントの鮮度です。時間の経過とともに、MathJSON は進化し、変化していきます。たとえば、最近三角関数のサポートを追加しました。ステアリングファイルで維持しなければならないコピーではなく、Kiro が元のドキュメントにアクセスできることを望んでいます。ここで Model Context Protocol（MCP）の出番です。 MathJSON の場合、GitHub リポジトリが信頼できる情報源です。したがって、GitHub 用の MCP サーバーを設定しました。これで、Kiro は必要なときに最新のドキュメントを読むことができます。GitHub は単なる例であることに注意してください。GitLab、Confluence などにドキュメントを保管している場合、それらにも MCP サーバーがある可能性があります。 Kiro が GitHub のドキュメントに直接アクセスできるようになったので、ステアリングファイルを削除したくなるかもしれません。しかし、実際には両方が必要であることがわかりました。Kiro に 2 つの数値を足し算する関数を作成 するように依頼したとします。そのプロンプトには、MathJSON を使用することや、MathJSON のドキュメントが GitHub に保存されていることを示すものは何もありません。Kiro は MathJSON ではなく Python で関数を書く可能性が高いです。ステアリングファイルは、Kiro が点と点を結ぶのに役立ちます。 次の例では、MathJSON を使用していることと、ドキュメントが GitHub で利用可能であることを Kiro に伝えるためにステアリングファイルを更新したことがわかります。さらに、GitHub の MCP サーバーを使用してドキュメントにアクセスするように Kiro に指示しました。 # MathJSON DSL 概要 このプロジェクトは、数式のためのドメイン固有言語である MathJSON を使用しています。MathJSON は、JSON 構文を使用して数式を表現および操作する構造化された方法を提供します。 ## 主要なドキュメント参照 完全な MathJSON ドキュメントは、YOUR_ORG_NAME/mathjson リポジトリで利用できます。これらのファイルにアクセスするには、GitHub MCP サーバーを使用してください。 - **メインドキュメント**: owner="sampleorg", repo="mathjson", path="README.md"で`mcp_github_get_file_contents`を使用 - **関数リファレンス**: owner="sampleorg", repo="mathjson", path="function_reference.md"で`mcp_github_get_file_contents`を使用 - **構文リファレンス**: owner="sampleorg", repo="mathjson", path="syntax_reference.md"で`mcp_github_get_file_contents`を使用 - **例**: owner="sampleorg", repo="mathjson", path="examples.md"で`mcp_github_get_file_contents`を使用 - **環境変数**: owner="sampleorg", repo="mathjson", path="ENVIRONMENT_VARIABLES.md"で`mcp_github_get_file_contents`を使用 - **トラブルシューティング**: owner="sampleorg", repo="mathjson", path="TROUBLESHOOTING_VARIABLES.md"で`mcp_github_get_file_contents`を使用 特定のファイルへの参照を提供していることに注意してください。これはパフォーマンスの最適化です。リポジトリへの参照だけを提供した場合、Kiro はリポジトリを探索してファイルを読むのに時間がかかりすぎます。また、GitHub は理想的なドキュメントリポジトリではないことも指摘しておきたいと思います。Kiro は、ドキュメントをトピックにチャンク化し、それらのチャンクをベクトルデータベースに保存することで恩恵を受けるでしょう。これにより、Kiro は必要なドキュメントの部分だけにアクセスできます。ただし、この記事は少し長くなっているので、そのトピックは別の記事に残しておきます。 Kiro に知識の更新を依頼する この時点で、私のステアリングファイルは主にドキュメントへのポインタとして機能しています。ただし、ベストプラクティスセクションとともに、ステアリングファイルにいくつかの高レベルのドキュメントがまだあります。さらに重要なことに、定期的にステアリングファイルを更新するように Kiro に依頼しています。Kiro が間違いを犯したり、問題に遭遇したりするたびに、問題がまだコンテキストにある間に更新を行うように Kiro に依頼します。 次の例では、Kiro が環境変数のフォーマットの問題に取り組んでいるのがわかります。リンターが問題を特定すると、Kiro は MCP サーバーを使用してドキュメントを読み、エラーを修正します。 Kiro がこれらの問題に取り組むにつれて、新しいスキルを学びます。ただし、その新しい知識は会話の期間中のみ保持されます。したがって、Kiro は将来のセッションで同じ間違いを犯す可能性があります。これは、ステアリングファイルを更新するように Kiro に依頼する絶好の機会です。 MathJSON の環境変数の構文について学んだ後、Kiro はステアリングファイルに次のセクションを追加しました。 ## 環境変数のベストプラクティス ### 変数構文 - 環境変数には`{"variable": "env:VARIABLE_NAME"}`構文を使用 - 変数名は文字またはアンダースコアで始まり、英数字とアンダースコアのみを含む必要があります - `PRINCIPAL`、`ANNUAL_RATE`、`LOAN_TERM_YEARS`のような説明的な名前を使用 時間の経過とともに、Kiro はガイダンスを洗練し続け、私の DSL に関する知識を拡大し、書くコードを改善していきます。 すべてをまとめる 数回の反復の後、Kiro は MathJSON を作成する準備ができています。住宅ローンの過払いをモデル化する関数を作成するように Kiro に依頼します。 元金、金利、過払い額を入力として受け取り、ローンの期間中の節約額を返す住宅ローン過払いをモデル化する関数を作成してください。 Kiro は私のために MathJSON を生成する準備ができました。以下は、住宅ローン過払い計算のために Kiro が生成した MathJSON です。 { "multiplication": { "multiplicand": {"variable": "env:OVERPAYMENT_AMOUNT"}, "multiplier": { "subtraction": { "minuend": { "multiplication": { "multiplicand": {"variable": "env:LOAN_TERM_YEARS"}, "multiplier": 12 } }, "subtrahend": { "division": { "dividend": { "log": { "value": { "subtraction": { "minuend": 1, "subtrahend": { "division": { "dividend": { "multiplication": { "multiplicand": {"variable": "env:OVERPAYMENT_AMOUNT"}, "multiplier": { "division": { "dividend": {"variable": "env:ANNUAL_RATE"}, "divisor": 12 } } } }, "divisor": {"variable": "env:PRINCIPAL"} } } } }, "base": { "addition": { "addend1": 1, "addend2": { "division": { "dividend": {"variable": "env:ANNUAL_RATE"}, "divisor": 12 } } } } } }, "divisor": { "log": { "value": { "addition": { "addend1": 1, "addend2": { "division": { "dividend": {"variable": "env:ANNUAL_RATE"}, "divisor": 12 } } } } } } } } } } } } そしてもちろん、Kiro はステアリングファイルで定義されたベストプラクティスに従って、書いたコードをリントおよびテストし、コードが構文的に正しいことを検証します。 結論 MathJSON のようなカスタムライブラリを理解し、それと連携するように Kiro を教えることは、ステアリングファイルと Model Context Protocol を組み合わせる力を示しています。この記事で概説されたアプローチ（ドキュメントの洗練、明確なベストプラクティスの確立、最新の知識のための MCP の活用）に従うことで、カスタムライブラリ、言語、ツールと連携するように Kiro へ教えることができます。 Kiro を始めましょう 。

バージニア北部 (us-east-1) リージョンでサービスを使用している多くのユーザーにとって、10 月 27 日週は多くの課題からスタートしました。月曜日、DNS 設定の問題により、DynamoDB およびその他のいくつかのサービスに影響を及ぼすサービスの中断が発生しました。この問題は完全に解決しました。詳細については 公式概要 でご覧いただけます。開発者と緊密に連携している私は、これらのインシデントがお客様のアプリケーションやユーザーにどれほど混乱をもたらす可能性があるかを承知しています。チームはこのイベントから、今後のサービス改善に役立つ貴重な教訓を得ました。 10 月 20 日週のリリース もっと明るい話をしましょう。10 月 20 日週のリリースやアップデートのうち、皆様が興味関心を持ちそうなものをいくつかご紹介します。 AWS RTB Fabric の一般公開 – 広告テクノロジーに携わっている方は、リアルタイム入札ワークロード用のフルマネージドサービスである AWS RTB Fabric に興味があるはずです。瞬時の広告オークションに不可欠な 1 桁ミリ秒のレイテンシーを実現するプライベートかつ高性能のネットワークを介して、SSP、DSP、パブリッシャーなどの AdTech パートナーを接続します。このサービスは、事前契約なしの標準のクラウドソリューションと比較して、ネットワークコストを最大 80% 削減します。また、トラフィックの最適化、入札効率の向上、入札応答率の増加を実現する 3 つのモジュールが組み込まれています。AWS RTB Fabric は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポールと東京)、欧州 (フランクフルトとアイルランド) でご利用いただけます。 Customer Carbon Footprint Tool が Scope 3 の排出量 データへの対応を開始 – クラウドの使用による環境への影響をより包括的に把握できるようになりました。AWS Customer Carbon Footprint Tool (CCFT) は、温室効果ガスプロトコルで定義されている 3 つの業界標準排出スコープすべてへの対応を開始しました。今回の更新では、サーバーの製造、AWS 施設への電力供給、データセンターへの機器の輸送によるライフサイクルでの二酸化炭素の影響を対象とする Scope 3 の排出量とともに、Scope 1 の天然ガスと冷媒が追加されました。2022 年 1 月までさかのぼる履歴データを使用して、時間の経過に伴う進捗状況を追跡し、持続可能性の目標を達成するためのクラウド戦略について情報に基づいた意思決定を行うことができます。CCFT ダッシュボードまたは AWS Billing and Cost Management データエクスポートからデータにアクセスしてください。 その他のアップデート こちらは、私が興味深いと感じたプロジェクト、ブログ記事、ニュースです。 AWS Secret-West Region が 利用可能に – AWS は、米国西部に 2 つ目の Secret Region を開設しました。このリージョンでは、米国秘密のセキュリティ分類レベルでミッションクリティカルなワークロードを処理できます。この新しいリージョンでは、遅延の影響を受けやすいワークロードのパフォーマンスが向上し、インテリジェンスコミュニティと国防総省のミッションを地理的に分離することでマルチリージョンの耐障害性が提供されます。このインフラストラクチャの特徴は、セキュリティにおいて Intelligence Community Directive の要件に準拠するように設計、構築、認定、運用されているデータセンターとネットワークアーキテクチャです。 Amazon CloudWatch がインシデントレポートの生成を開始 – CloudWatch の調査では、エグゼクティブサマリー、イベントのタイムライン、影響評価、実行可能な推奨事項を含む包括的なインシデントレポートを自動的に生成できるようになりました。この特徴量は、テレメトリデータを収集して調査アクションと関連付け、チームがパターンを特定し、構造化されたインシデント後の分析を通じて予防策を実施することを支援します。 Amazon Connect で E メールビューがスレッド化 – Amazon Connect E メールでは、やり取りがスレッド形式で表示されるようになり、エージェントが応答を作成するときに以前の会話コンテキストが自動的に含まれるようになりました。これらの機能強化により、エージェントとお客様の両方がインタラクション全体でコンテキストと継続性を維持しやすくなり、より自然で親しみやすい E メールエクスペリエンスが実現します。 Amazon EC2 I8g インスタンスがその他のリージョンに拡大 – ストレージ最適化 I8g インスタンスは、欧州 (ロンドン)、アジアパシフィック (シンガポール)、アジアパシフィック (東京) でご利用いただけるようになりました。AWS Graviton4 プロセッサと第 3 世代 AWS Nitro SSD を搭載したこれらのインスタンスは、前世代の I4g インスタンスと比較して、コンピューティングパフォーマンスが最大 60%、TB あたりのリアルタイムストレージパフォーマンスが 65% 向上し、ストレージ I/O レイテンシーが最大 50% 削減されます。 AWS Location Service が強化されたマップスタイル作成を追加 – 開発者は GetStyleDescriptor API を使用して、地形の視覚化、等高線、リアルタイムの交通オーバーレイ、交通機関固有のルーティングの詳細を組み込むことができるようになりました。新しいスタイル作成パラメータにより、屋外ナビゲーションから物流計画まで、特定の用途に合わせた地図を作成できます。 CloudWatch Synthetics がマルチチェック Canary を導入 – カスタムスクリプトなしで JSON 設定を使用して、最大 10 種類のモニタリングステップを 1 つの Canary にまとめられるようになりました。マルチチェックブループリントは、認証、DNS 検証、SSL 証明書モニタリング、TCP ポートチェックで HTTP エンドポイントをサポートしているため、API モニタリングの費用対効果が高まります。 Amazon S3 Tables が CloudTrail イベントの生成を開始 – S3 テーブルは、コンパクションやスナップショットの有効期限などの自動メンテナンス操作用に AWS CloudTrail イベントをログに記録するようになりました。これにより、組織は S3 Tables が自動的に実行するメンテナンスアクティビティを監査して、クエリのパフォーマンスを向上させ、運用コストを削減することができます。 AWS Lambda が非同期呼び出しのペイロードサイズを 1 MB に増加 – Lambda は、すべての AWS 商用および GovCloud (米国) リージョンで、非同期呼び出しの最大ペイロードサイズを 256 KB から 4 倍にあたる 1 MB に増やしました。この拡張により、包括的なデータを単一のイベントに含めることができるため、複雑なデータチャンクや外部ストレージソリューションが不要になり、アーキテクチャが合理化されます。大規模な言語モデルのプロンプト、詳細なテレメトリシグナル、複雑な ML 出力構造、完全なユーザープロファイルなどのユースケースのサポートが強化されています。この更新は、Lambda API による非同期呼び出し、または S3、CloudWatch、SNS、EventBridge、Step Functions などのサービスからのプッシュベースのイベントに適用されます。料金は、最初の 256 KB については 1 回のリクエスト料金のままですが、それ以降は 64 KB チャンクごとに 1 回の追加料金がかかります。 近日開催予定の AWS イベント 今後のイベントをチェックして、ぜひご登録ください。 AWS re:Invent 2025 (2025 年 12 月 1〜5 日、米国ラスベガス) – 毎年恒例の AWS フラッグシップカンファレンスは、ピアツーピアの学習、専門家主導のディスカッション、貴重なネットワーキング機会を通じてコラボレーション型のイノベーションを実現します。現在登録受け付け中です。 AWS Builder Center に参加して、AWS コミュニティで AWS ビルダーとともに学び、構築し、交流しましょう。お住まいの地域で今後開催される対面イベントとデベロッパー向けのバーチャルイベントをご覧ください。 10 月 27 日週のニュースは以上です。11 月 3 日週の Weekly Roundup もお楽しみに! – Micah 原文は こちら です。

10 月 23 日、リアルタイム入札 (RTB) 広告ワークロード専用に構築されたフルマネージドサービスである AWS RTB Fabric が発表されました。このサービスは、アドテクノロジー (AdTech) 企業が Amazon Ads 、 GumGum 、 Kargo 、 MobileFuse 、 Sovrn 、 TripleLift 、 Viant 、 Yieldmo などのサプライパートナーやデマンドパートナーにシームレスに接続して、一貫的な 10 ミリ秒未満のパフォーマンスを備え、ネットワーキングコストが標準のネットワーキングコストよりも最大 80% 低い Amazon Web Services (AWS) でレイテンシーの影響を受けやすい大容量の RTB ワークロードを実行するために役立ちます。 AWS RTB Fabric は、RTB ワークロードとパートナー統合専用の高性能ネットワーク環境を提供し、コロケーションされたオンプレミスインフラストラクチャや事前の契約は必要ありません。以下の図は、RTB Fabric のおおまかなアーキテクチャを示しています。 AWS RTB Fabric にはモジュールも含まれています。これは、お客様がセキュアな方法で独自のアプリケーションやパートナーアプリケーションをリアルタイム入札に使用されるコンピューティング環境に取り込めるようにする機能です。モジュールは、コンテナ化されたアプリケーションと、トランザクション効率と入札効果を高めることができる 基盤モデル (FM) をサポートします。リリース時点での AWS RTB Fabric には、トラフィック管理の最適化、入札効率の改善、入札レスポンス率の向上のためのモジュールが含まれています。これらはすべて、一貫した低レイテンシーでの実行のために、サービス内でインライン実行されます。 プログラマティック広告の成長は、RTB ワークロードをサポートするための低レイテンシーでコスト効率性に優れたインフラストラクチャに対するニーズを生み出しました。AdTech 企業は、パブリッシャー、サプライサイドプラットフォーム (SSP)、デマンドサイドプラットフォーム (DSP) の全体で 1 秒あたり何百万もの入札リクエストを処理します。RTB オークションのほとんどは 200〜300 ミリ秒内に完了しなければならず、複数のパートナー間での OpenRTB リクエストとレスポンスの確実かつ高速なやり取りが必要となるため、これらのワークロードはレイテンシーの影響を非常に受けやすくなります。多くの企業は、主要パートナー近隣のコロケーションデータセンターにインフラストラクチャをデプロイすることでこの課題に対処してきましたが、レイテンシーは削減されても、運用上の複雑性が増し、プロビジョニングサイクルが長期化して、コストが高くなります。伸縮性を得てスケールするためにクラウドインフラストラクチャを活用する企業もありますが、この場合は複雑なプロビジョニング、パートナー固有の接続性、コスト効率性を実現するための長期的なコミットメントといった課題にしばしば直面します。こうしたギャップは、運用オーバーヘッドを増やし、俊敏性を妨げます。AWS RTB Fabric は、RTB ワークロード向けに構築されたマネージド型のプライベートネットワークを提供することでこれらの課題を解決します。このプライベートネットワークは、コロケーションの維持やカスタムネットワーク設定といった負担を課すことなく、一貫したパフォーマンスを実現し、パートナーのオンボーディングを簡素化して、予測可能なコスト効率を実現します。 主な機能 AWS RTB Fabric は、RTB ワークロードを大規模に実行するためのマネージド型基盤を導入します。このサービスでは、次の主要機能が提供されます。 AdTech パートナーへの簡素化された接続 – RTB Fabric ゲートウェイを登録すると、選択したパートナーと共有できるセキュアなエンドポイントをサービスが自動的に生成します。AWS RTB Fabric API を使用することで、さまざまな環境で RTB トラフィックをセキュアに交換するための、最適化されたプライベート接続を作成できます。オンプレミスやサードパーティのクラウド環境で業務を行っているパートナーなど、RTB Fabric を使用していないパートナーと接続には、外部リンクも利用できます。このアプローチは、統合時間を短縮し、AdTech 参加者間のコラボレーションを簡素化します。 低レイテンシーの広告トランザクションのための専用ネットワーク – AWS RTB Fabric は、OpenRTB 通信向けに最適化されたマネージド型の高性能ネットワークレイヤーを提供します。SSP、DSP、パブリッシャーなどのアドテック参加者は、一貫的な 10 ミリ秒未満のレイテンシーを実現する高速なプライベートリンク経由で接続されます。AWS RTB Fabric は、予測可能なパフォーマンスを維持し、ネットワーキングコストを削減するためにルーティングパスを自動的に最適化するので、手動でのピアリングや設定は不要です。 RTB エコノミクスに即した料金モデル – AWS RTB Fabric は、プログラマティック広告エコノミクスに合わせて設計されたトランザクションベースの料金モデルを使用しています。お客様には 10 億トランザクションごとに料金が請求されるため、アドエクスチェンジ、SSP、DSP の運営方法に応じた予測可能なインフラストラクチャコストを実現できます。 組み込みのトラフィック管理モジュール – AWS RTB Fabric には、AdTech ワークロードを効率的かつ確実に運用するために役立つ設定可能なモジュールが含まれています。Rate Limiter、OpenRTB Filter、Error Masking などのモジュールを使用することで、ネットワークパス内で直接リクエスト量を制御し、メッセージ形式を検証して、レスポンス処理を管理できます。これらのモジュールは AWS RTB Fabric 環境内でインライン実行され、アプリケーションレベルのレイテンシーを増加させることなくネットワーク速度のパフォーマンスを維持します。すべての設定は AWS RTB Fabric API 経由で管理されるため、ワークロードの拡大に合わせてルールをプログラム的に定義および更新できます。 使用の開始 AWS RTB Fabric での構築は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS CloudFormation や Terraform などの Infrastructure-as-Code (IaC) ツールを使用して今すぐ開始できます。 AWS RTB Fabric コンソール の ダッシュボード にあるように、コンソールは RTB ゲートウェイとリンクを表示して管理するための視覚的なエントリポイントを提供します。 AWS CLI を使用して、ゲートウェイの設定、リンクの作成、トラフィックの管理をプログラム的に行うことも可能です。私が AWS RTB Fabric での構築を始めたときは、ゲートウェイの作成から、リンクのセットアップ、トラフィックの監視まで、あらゆる設定を AWS CLI を使って行いました。セットアップは私の Amazon Virtual Private Cloud (Amazon VPC) エンドポイント内で実行され、ワークロードを接続する低レイテンシーインフラストラクチャは AWS が管理しました。 はじめに、入札リクエストを送信するための リクエスタゲートウェイ と、入札レスポンスを受信して処理するための レスポンダーゲートウェイ を作成しました。これらのゲートウェイは、AWS RTB Fabric 内のセキュアな通信ポイントとして機能します。 # Create a requester gateway with required parameters aws rtbfabric create-requester-gateway \ --description "My RTB requester gateway" \ --vpc-id vpc-12345678 \ --subnet-ids subnet-abc12345 subnet-def67890 \ --security-group-ids sg-12345678 \ --client-token "unique-client-token-123" # Create a responder gateway with required parameters aws rtbfabric create-responder-gateway \ --description "My RTB responder gateway" \ --vpc-id vpc-01f345ad6524a6d7 \ --subnet-ids subnet-abc12345 subnet-def67890 \ --security-group-ids sg-12345678 \ --dns-name responder.example.com \ --port 443 \ --protocol HTTPS 両方のゲートウェイがアクティブになったら、リクエスタからレスポンダへのリンクを作成して、OpenRTB トラフィック用の低レイテンシーのプライベート通信パスを確立しました。ルーティングと負荷分散はリンクが自動的に処理します。 # Requester account creating a link from requester gateway to a responder gateway aws rtbfabric create-link \ --gateway-id rtb-gw-requester123 \ --peer-gateway-id rtb-gw-responder456 \ --log-settings '{"applicationLogs:{"sampling":"errorLog":10.0,"filterLog":10.0}}' # Responder account accepting a link from requester gateway to responder gateway aws rtbfabfic accept-link \ --gateway-id rtb-gw-responder456 \ --link-id link-reqtoresplink789 \ --log-settings '{"applicationLogs:{"sampling":"errorLog":10.0,"filterLog":10.0}}' また、 外部リンク を使用して外部パートナーとの接続も行いました。これらのリンクは、同一のレイテンシーとセキュリティ特性を維持しながら、RTB ワークロードをオンプレミス環境またはサードパーティ環境に拡張します。 # Create an inbound external link endpoint for an external partner to send bid requests to aws rtbfabric create-inbound-external-link \ --gateway-id rtb-gw-responder456 # Create an outbound external link for sending bid requests to an external partner aws rtbfabric create-outbound-external-link \ --gateway-id rtb-gw-requester123 \ --public-endpoint "https://my-external-partner-responder.com" トラフィックを効率的に管理するために、データパスにモジュールを直接追加しました。Rate Limiter モジュールはリクエスト量を制御し、OpenRTB Filter はメッセージ形式のネットワーク速度での検証をインラインで行います。 # Attach a rate limiting module aws rtbfabric update-link-module-flow \ --gateway-id rtb-gw-responder456 \ --link-id link-toresponder789 \ --modules '{"name":"RateLimiter":"moduleParameters":{"rateLimiter":{"tps":10000}}}' 最後に、スループット、レイテンシー、モジュールパフォーマンスを監視するために Amazon CloudWatch を使用し、監査と最適化のために Amazon Simple Storage Service (Amazon S3) にログをエクスポートしました。 すべての設定は、AWS CloudFormation または Terraform を使用して自動化することもでき、複数の環境全体で繰り返し可能な一貫したデプロイが可能になります。RTB Fabric を使用すると、AWS が AdTech パートナー全体で予測可能な 10 ミリ秒未満のパフォーマンスを維持してくれるので、私は入札ロジックの最適化に集中できました。 詳細については、「 AWS RTB Fabric User Guide 」を参照してください。 今すぐご利用いただけます AWS RTB Fabric は、10 月 23 日から米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド) の各 AWS リージョン でご利用いただけます。 AWS RTB Fabric は、AdTech 業界の変化するニーズに対応するために絶えず進化しています。このサービスは、高度なアプリケーションのセキュアな統合と、リアルタイム入札ワークフローにおける AI 駆動の最適化をサポートするように機能を拡張します。これは、お客様が AWS での運用を簡素化し、パフォーマンスを向上させるために役立ちます。AWS RTB Fabric の詳細については、 AWS RTB Fabric ページ をご覧ください。 – Betty 原文は こちら です。

本記事は、2025 年 10 月 16 日に公開された “ Launch phase steps for successful launches on Amazon GameLift Servers ” を翻訳したものです。翻訳は Solutions Architect の西坂信哉が担当しました。 ゲームが急激にヒットした場合に備え、最初から成功に向けた準備をしておくことが重要です。本記事では、 Amazon GameLift Servers でマルチプレイヤーゲームを立ち上げる際に考慮すべき重要な点について説明します。ゲームのローンチの 2-3 ヶ月前に必要な作業に焦点を当てます。これは、ゲームの本番ローンチだけでなく、オープンベータ、アーリーアクセス、あるいは実際のプレイヤーが参加する他のマイルストーンも含まれます。 ゲームローンチに向けた最終計画の 5 つの重要な領域について説明します。 ゲームローンチに関するアンケートに記入し、サービスのクォータ (制限値) を引き上げます 本番環境のフリートをセットアップします 負荷テストを実施し、クリティカルパスをテストします API スロットリングを監視します 新しいゲームサーバーバージョンを本番環境にデプロイする際は、Blue/Green デプロイメントを使用します 1 – 起動に関するアンケートの記入とクォータの引き上げ オープンベータ、アーリーアクセス、そして最終的な本番ローンチなどのマイルストーンを実現するための重要なポイントの 1 つは、必要に応じてサービスのクォータを引き上げることです。Amazon GameLift Servers のデフォルトのサービスクォータは、開発初期の段階で意図せずスケールアウトしてしまうことからアカウントを保護するために設定されています。プレイヤーのサポートを本格的に開始する準備が整ったら、プレイヤーの負荷をサポートするために必要なインフラストラクチャを提供できるよう、より高いクォータが必要になる場合があります。 Launch Questionnaire は、 Amazon GameLift Servers コンソール の左側メニューの Resources から Prepare to launch を選択すると確認できます。このアンケートでは、選択したインスタンスタイプのインスタンス制限と、Amazon GameLift Servers API のスロットリング制限の両方について説明しています。 アンケートに記入する際の重要なポイントは以下の通りです: ローンチの 2-3 ヶ月前を目安に早めに実施してください。 ベータ版やプライベートプレビューもローンチの一種であることを忘れないでください。そのためにもクォータの引き上げが必要です。次のマイルストーンに向けて、アンケートの新しいバージョンをいつでも提出できます。 マルチロケーションフリートには、ホームリージョンと追加のロケーションがあります。フリートの ホームリージョン を定義し、選択したホームリージョンに対して各 ロケーション のクォータ引き上げを要求することを忘れないでください。ロケーション固有のインスタンス制限は、各ホームリージョンごとに個別に設定されます。 使用している Amazon GameLift Servers API を正確に確認し、予想されるピーク時のリクエストレートに合わせてクォータの引き上げを要求してください。 Describe API は一般的に各プレイヤーのリクエストごとに呼び出すようには設計されていないため、ゲームセッション作成フローでの使用は避けてください。これらの API を呼び出す必要がある場合は、 Host persistent world games on Amazon GameLift Servers で説明されているように、中央管理的な方法で実装できます。 必要なすべての Amazon Web Services (AWS) アカウントに対してクォータの引き上げを要求するようにしてください。これには、本番環境、テスト環境、および負荷テスト用のアカウントが含まれる場合があります。 アンケートを送信する際は、担当の AWS アカウントチームがいる場合、全員が同じ情報を共有できるよう、メールに AWS アカウントチームを追加するようにしてください。 図 1 は、Amazon GameLift Servers コンソールで Launch Questionnaire を見つける場所を示しています。 図 1: Amazon GameLift Servers の Launch Questionnaire 2 – 本番環境フリートの設定 Amazon GameLift Servers の本番環境のフリートは、開発環境のフリートとは異なる設定にすることをお勧めします。 主な考慮事項: Game Scaling Protection Policy を Full Protection に設定します。これにより、フリートがスケールダウンする際に、実行中のゲームセッションが保護されます。 Target-based Auto-scaling policy を有効にし、ローンチ日に向けて十分なバッファ (30-50% までが目安) を確保してください。トラフィックが安定した後で、この値を減らすことができます。 各リージョンに個別のフリートを設定するのではなく、マルチロケーションフリートを使用してください。グローバルなフリートのリソースを一元的に表示でき、運用の複雑さが軽減されるため、運用が大幅に効率化されます。 レイテンシーの目標とプレイヤー人口を考慮し、それに応じてロケーションを選択してください。レイテンシーの低い FPS ゲームでは、通常、各大陸エリアに複数のロケーションが必要です。比較的レイテンシシビアではないゲームでは、より少ないロケーション数で対応でき、運用も効率化できます。クライアント側でレイテンシーを測定するには、 Amazon GameLift が提供する UDP ping ビーコン を使用できます。 各ロケーションのスケーリング設定 ( min と max ) を設定し、各ロケーションで健全なベースライン (min) と、突発的な需要の増加に対応できる余裕 (max) を確保してください。 ローンチ日には、各ロケーションの最小値を、初期トラフィックのピークに対応できる十分な基準値に設定して、事前にスケールアウトすることをお勧めします。トラフィックパターンが安定した後は、この値を低く設定することもできますが、初期ローンチ時のピークに備えておくことが重要です。 複数のインスタンスタイプを使用してゲームサーバーをホストできる機能により、予期せぬプレイヤー負荷に対する準備を確認してください。これは例えば、選択したインスタンスファミリーの .large と .xlarge のバリエーション、または同じインスタンスファミリー内の異なるインスタンスファミリーや世代を使用することができます。ほとんどのゲームでは複数のフリートをホストする必要はありませんが、大規模な環境では、マルチフリート戦略をオプションとして持つことで、必要な容量を確保することができます。 図 2 は、2 つのマルチロケーションフリートが同じ Amazon GameLift Servers Queue に登録されている様子を示しています。1 つ目のフリートは C6i.large インスタンスタイプを使用し、ゲームの起動に対応するためにスケールアウトされています。2 つ目のフリートは C5.large インスタンスタイプを使用し、スケールアウトされていません。両方のインスタンスタイプの制限は、本番トラフィックを処理するために Launch Questionnaire で引き上げられています。いずれかのロケーションで C6i.large の可用性が低下するという稀なケースでは、バックアップフリートにより異なるインスタンスタイプでスケールアウトし、プレイヤーへのサービスを継続できます。バックアップフリートには、C6i.xlarge など、C6i ファミリーの別のインスタンスサイズを使用することもできます。 図 2:大規模なスケーリングに向けたマルチロケーションフリートの利用 3 – 負荷テストとクリティカルパスのテスト 負荷テストは、インフラストラクチャのボトルネックを明らかにするために重要です。これは、ローンチの準備における最も重要なステップの 1 つです。 特に Amazon GameLift Servers の場合、負荷テストでは以下のような問題が浮き彫りになります： インスタンス制限緩和の不足 API クォータ (各 API に個別に適用) ゲームサーバーが通信するバックエンドシステムなどの依存関係の問題 実際のトラフィックパターンを再現した大規模な負荷テストを実施することで、これらの問題が表面化します。これは、高い同時ユーザー数で発生するように、すべてのロケーションでセッション配置リクエストを段階的に増やし、すべてのシステムが期待通りに動作することを確認することを意味します。 ゼロから 5 分間で 50 万の同時ユーザーまでスケールアウトするテストは、紙の上では良いテストに見えますが、実際のトラフィックパターンを反映していない可能性があります。現実的なパターンでテストすることで、期待値を過度に高めすぎないようにすることができます。通常、ピークまでの増加は、より長い期間 (通常は数時間) にわたって発生します。過去のゲームのデータや、 SteamDB などのツールを使用して、ローンチ時の一般的なトラフィックパターンを確認することができます。 負荷テストを実施するには、主に 2 つの方法があります。 フリートのスケーリングとセッション配置のテストは、 StartGameSessionPlacement などの API を直接呼び出すことで実行できます。比較的少数の実際のクライアントで、Python や Bash スクリプトを使用して実行できます。これは、API とインスタンスの制限、およびスケーリング設定の優れたスモークテストとなります。 ゲームサーバーに加えてバックエンドサービスも含めた、重要なシナリオ全体をテストします。このアプローチには、実際のアカウント作成とゲームへのログイン、およびバックエンドを使用したマッチメイキングやセッション配置のリクエストが含まれます。これは、バックエンドのボトルネックもテストする、より包括的な負荷テストのアプローチです。このテストは、( AWS Fargate コンテナで実行される) ゲームのヘッドレスボットクライアントを使用するか、クライアントにできるだけ近い動作をするスクリプトを使用して実行することをお勧めします。 完全なテストを実施する際は、クライアントがゲームサーバーに接続し、通常のプレイヤーと同様に移動やその他のアクションを送信してゲームをプレイすることもできるのが理想的です。これにより、ゲームサーバーのパフォーマンスもストレステストされます。また、クライアントがセッションをプレイし、次のセッションに接続するためにログアウトする際の、現実的なセッション時間とゲームセッションのローテーションのテストにも役立ちます。 これらのテストを正しくモニタリングするには、このブログシリーズの第 1 回 Amazon GameLift Servers でローンチを成功させるためのステップ：開発フェーズ のモニタリング、ロギング、アラームのセクションで説明したアプローチを使用してください。さらに、Amazon GameLift Servers API からのエラーやスロットリング、および自社やサードパーティが管理するその他のサービスやコンポーネントからのエラーやスロットリングも追跡する必要があります。これについては、セクション 4「API スロットリングのモニタリング」で詳しく説明します。 Werner Vogels (Amazon の CTO) が述べているように、「障害は当たり前のことであり、すべてのものは最終的に障害を起こします」。重要なシナリオが、あらゆる依存関係 (Steam、コンソールログイン、データベースなど) の障害を適切に処理できることを確認する必要があります。また、内部障害からの復旧が確実にできることも確認する必要があります。これにより、ローンチ日のあらゆる予期せぬ事態に備えることができます。 図 3 は、AWS Fargate 上でロードテストクライアントをサービスとしてホストする例を示しています。このサービスは複数の Amazon ECS タスクを実行し、各タスクは最大 10 個の個別のクライアントコンテナをホストできます。ロードテストクライアントは、複数の AWS リージョンにまたがって実行でき、レイテンシーとプレイヤーの位置がゲーム体験にどのように影響するかをテストできます。クライアントは、実際のゲームクライアントのスクリプト化されたヘッドレスバージョン、またはゲームクライアントとして動作するスクリプトのいずれかを使用できます。 図 3: 重要なシナリオを負荷試験する 4 – API スロットリングのモニタリング 負荷テスト中、Amazon GameLift Servers API の呼び出しが デフォルトのプロビジョニング制限 を超えると、スロットリングエラーが発生する可能性があります。スロットリングされた呼び出しを特定し対応することは、運用の安定性、可用性、そしてシームレスなプレイヤーエクスペリエンスを確保する上で重要です。 AWS CloudTrail は、Amazon GameLift Servers の包括的な API イベント追跡機能を提供し、すべての API 使用状況を監視および監査できます。 CloudTrail を以下の用途で効果的に使用できます: Amazon GameLift Servers API のアクティビティを追跡 スロットリングを特定 CloudWatch のカスタムメトリクスにアラームを設定 予想されるピーク時のリクエストレートに合わせてクォータの引き上げを運用チームに通知 CloudTrail レコードに適用される eventSource が gamelift.amazonaws.com で、以下のいずれかの errorCode または errorMessage が適用されるスロットリングを監視します。 errorCode が ThrottlingException の場合 errorCode が RequestLimitExceeded の場合 errorMessage が RateExceeded の場合 運用の可視性を確保するため、CloudTrail で新しい証跡を作成し、CloudWatch Logs を有効にします。CloudWatch Logs にログを書き込むための適切な AWS Identity and Access Management (IAM) のアクセス許可 があることを確認してください。Amazon GameLift イベントを取得するために CloudWatch のロググループ を指定します。設定が完了すると、すべての Amazon GameLift Servers API コールと関連するスロットリングエラーを CloudWatch Logs で確認できるようになります。 CloudWatch Logs で、CloudTrail がログを書き込むために使用するロググループを選択し、スロットリングのパターンを特定するためのカスタムメトリクスフィルターを作成します。 namespace を割り当て、スロットリングが発生するたびにインクリメントされるカスタムメトリクスを正常に作成する必要があります。 以下はフィルターパターンの例です。 { ($.eventSource = "gamelift.amazonaws.com") && ($.errorCode = "ThrottlingException") } カスタムメトリクスを設定したら、スロットリングのしきい値を監視するための CloudWatch アラームを設定します。例えば、5 分間に 10 件以上のスロットリングリクエストが発生した場合にアラームを発生させます。作成したアラームを Amazon SNS トピックにアタッチし、運用チームにメール、ショートメッセージサービス (SMS)、またはチャット通知を送信します。これにより、運用チームは API の使用状況を確認し、適切なアクションを取ることができます。 クォータの緩和をリクエストする前にスロットリングを最小限に抑えるには： Amazon GameLift Servers API 呼び出しに対して エクスポネンシャルバックオフ を実装します Amazon GameLift Servers API から大規模なデータセットを取得する際は、ページネーションとフィルタリングを使用します フリート情報などの頻繁にアクセスされるデータをキャッシュして、API 呼び出しの繰り返しを避けます 可能な場合は操作をバッチ処理して、API 呼び出しの頻度を減らします 5 – 本番環境における新しいゲームサーバーバージョンには Blue/Green デプロイを使う 本番環境に移行した後、特に初期の段階では、ゲームサーバーに比較的頻繁にパッチを適用する必要があります。また、ゲームに機能や改善を加えていく中で、継続的なパッチ適用も必要になります。Amazon GameLift Servers でのアップデートには、 Blue/Green デプロイメント が推奨されます。 このアプローチでは、新しいゲームサーバービルドまたはコンテナイメージを使用して、完全に新しい本番フリートをセットアップします。新しいフリートの準備が整い、モニタリングの状態が良好であることを確認したら、いくつかのゲームセッションでスモークテストを実施する追加ステップを設けることができます。その後、Amazon GameLift Servers Queue の設定を変更して、ゲームセッション配置要求を古いフリートから新しいフリートにルーティングすることで、運用中のアップデートを実行できます。新しいバージョンで新規セッションが作成され始めますが、古いフリート上で実行中のセッションは中断されることなく継続できます。 ※訳注 : Blue/Green デプロイメントでは、Blue と Green の環境が同時に起動する時間帯において、通常時の倍近くの数のインスタンスを起動する必要があり得ます。インスタンスの制限の緩和申請においてはその点を加味した数を申請ください。 すべてが問題なく見える場合は、全てのセッションが完全に終了（ドレイン）した後で古いフリートを終了できます。以前のバージョンにロールバックする必要がある場合は、キューのターゲットを切り替えることで古いバージョンに戻すことができます。これは Blue/Green デプロイメントの主要なメリットの 1 つです。 セッション配置にキューを使用しない場合、エイリアスリソースを同様の方法で使用できます。Amazon GameLift Servers Toolkit には、このアプローチの実装方法を示す Python スクリプトが用意 されています。 図 4 は、キューの背後にあるフリートを新しいものに置き換え、以前のフリートで古いセッションをドレインする Blue/Green デプロイメントを示しています。 図 4: Blue/Green デプロイメント まとめ Amazon GameLift Servers での本番環境のローンチを成功させるために、サービスクォータをスケールアウトする方法について説明しました。次に、本番環境のフリートを設定する際の重要な考慮事項について説明しました。また、負荷テストがローンチの準備にどのように役立つか、そして負荷テストを実施する一般的な方法についても説明しました。最後に、本番環境での運用中のサーバーバージョンの更新を管理するのに Blue/Green デプロイメントがどのように役立つかについて説明しました。 このシリーズでは、Amazon GameLift Servers でのゲームローンチを成功させるために、運用面とアーキテクチャ面での準備に関する幅広い側面を取り上げました。マルチプレイヤーゲームサーバーのホスティングには、Amazon GameLift Servers をぜひご利用ください。ビジネスの加速に向けた支援について詳しく知りたい場合は、 AWS の担当者 までお問い合わせください。 参考資料 Preparing your game for launch Amazon GameLift achieves 100 million concurrently connected users per game Host persistent world games on Amazon GameLift Servers Juho Jantunen Juho Jantunen は、AWS for Games チームのワールドワイドプリンシパルソリューションアーキテクトとして、ゲームバックエンドとゲームサーバーホスティングソリューションに注力しています。ゲーム業界とクラウドテクノロジーのバックグラウンドを持ち、数百万人のプレイヤーを抱える複数のタイトルにおいて、AWS 上でゲームバックエンドの構築と運用を行ってきました。 Sushil Ranganathan Sushil Ranganathan は、Amazon Web Services のシニアテクニカルアカウントマネージャーです。12 年以上の業界経験を持ち、戦略的産業のお客様が AWS クラウド上でエンタープライズ規模のソリューションを構築・運用できるよう支援することに情熱を注いでいます。

本投稿は、Suchindranath Hegde と Mahesh Kansara と Balaji Baskar による記事 「 Understanding resource distribution and performance analysis using AWS DMS enhanced monitoring 」を翻訳したものです。 AWS Database Migration Service (AWS DMS) を使用する際、レプリケーションの遅延、タスクの停滞、リソースのボトルネックが発生する可能性があります。そのため、根本原因を迅速に特定することが重要になる場合があります。 AWS DMS は Amazon CloudWatch メトリクスを提供していますが、時には複数のタスクにわたって情報を関連付ける必要があります。統合されたビューがないと、問題解決が遅れる可能性があります。ここで 拡張モニタリングダッシュボード が価値ある機能となります。 拡張モニタリングダッシュボードは、データベース移行タスクとレプリケーションインスタンスの重要なメトリクスを可視化する包括的なモニタリングツールです。タスクとレプリケーションインスタンスという 2 つの主要な ビュー を提供し、直感的な画面とウィジェットを通じて、さまざまなパフォーマンスメトリクス、リソース使用率、ステータス情報を表示します。 この AWS DMS の画面は、追加コストなしで利用できます。 この投稿では、拡張モニタリングダッシュボードをどのように使用できるかがわかるようないくつかのユースケースについて紹介します。 拡張モニタリングダッシュボードの概要 このセクションでは、拡張モニタリングダッシュボードで利用可能な様々なビューの内訳を説明します。 次のスクリーンショットでは、 us-east-1 AWS リージョンで構成されたリソースの数と、 CloudWatch Alerms および Service Health のセクションを確認できます。 また、タスクステータスセクションを見て、タスクのステータスの内訳を確認することもできます。 さらに、以下のスクリーンショットに示すように、ログストリームにアクセスすることで CloudWatch ログを詳細に調査できます。 次のセクションでは、顧客とのやり取りに基づいたユースケースを紹介し、拡張モニタリングダッシュボードの使用方法を説明します。 リソース配分の分析を理解する 各タスクを専用のレプリケーションインスタンスで実行することも、単一のレプリケーションインスタンスで複数の AWS DMS タスクを実行することもできます。様々なタスク設定やカスタマイズがマイグレーションにどのように影響するかを理解することは、AWS DMS レプリケーションがワークロードを処理できるように適切にプロビジョニングされていることを確認するのに役立ちます。拡張モニタリングダッシュボードを使用すると、様々な AWS DMS タスク間のメモリ配分を理解し、 タスクの移動 をして別のレプリケーションインスタンスにワークロードを分散させるか、タスクを変更してワークロードを統合するかを選択できます。 これを説明するために、dms.r6i.large の レプリケーションインスタンス を起動し、 既存のデータを移行し、継続的な変更をレプリケートする (訳者注 : 新しいナビゲーションの場合 「移行および複製」) オプションを使用して、異なるタスク設定を持つ 3 つの AWS DMS タスクを 作成 しました。 次のスクリーンショットは、タスク dmstaskflcdc が他の 2 つのタスクと比較してより多くのメモリを消費していることを示しています。この情報を基に、タスク dmstaskflcdc を専用のレプリケーションインスタンスに移動するか、同じインスタンスクラスでより多くのタスクを実行することを前提にして基盤となるレプリケーションインスタンスをスケールアップするか、を判断することができます。 パフォーマンスのトラブルシューティング CloudWatch メトリクスを比較する際、移行中の問題点を理解し、トラブルシューティングをするためにウィジェットを追加できます。 これを説明するために、 Amazon Relational Database Service (Amazon RDS) for SQL Server から Amazon Kinesis へ データ変更のレプリケーション (訳者注 : 新しいナビゲーションの場合 「複製のみ」)  オプションを使用して AWS DMS タスクを作成しました。 タスクの実行中に、ソースにデータを挿入したところ、CloudWatch ログに次のようなメッセージが表示されました： 2025-04-01T20:45:32 [SORTER ]W: Reading from source is paused temporarily to enhance performance and avoid storage being full on replication instance. Total storage used by swap files exceeded the limit 1048576000 bytes, please consider checking target latency この警告は、ターゲットがソースでのデータの取り込み速度に追いつけていないことを示しています。 これをより深く理解するために、 タスクメトリクス に関連するウィジェット ( CDCLatencyTarget 、 CDCLatencySource 、 CDCChangesDiskTarget ) を追加して、変更が AWS DMS レプリケーションインスタンスの基盤となるストレージに蓄積され、コミットを待っている状態であることを確認することができます。 考えられる原因の 1 つは、Kinesis Streams に十分なシャードがプロビジョニングされていなかったことです。 Kinesis のシャード数を増やすと、再びほぼリアルタイムにレプリケーションされることが確認できます。 パフォーマンスのベンチマーク さまざまなタスクにわたってベンチマークを実行し、指標を比較して、変化がパフォーマンスに反映されているかどうかを確認できます。たとえば、次の例は、RDS for SQL Server インスタンスのテーブルから  Amazon Aurora PostgreSQL 互換エディション のクラスターに 6,000 万レコードを移行する際の、フルロード移行に関係する CloudWatch メトリクスを示しています。 2 つのタスクを比較しました：デフォルト設定の dmsfullloadtest と、 MaxFullLoadSubTasks を 16 に設定した dmsfullloadtest-2 です。 これにより、 MaxFullLoadSubTasks 設定がフルロード中のスループットにどのような影響を与えるかを理解することができます。 次のスクリーンショットは、デフォルト設定で dmsfullloadtest タスクが 1 秒あたり 235,722 行のスループットを達成したことを示しています。 しかし、 dmsfullloadtest-2 タスクの MaxFullLoadSubTasks 数を 16 に増やすと、スループットは 515,599 行/秒に大幅に向上しました。 このベンチマークのエクササイズでは、AWS DMS 構成を最適化してフルロードで移行中のパフォーマンスを最大化するのに役立つ、強化されたモニタリングダッシュボードの価値を示しています。 まとめ この投稿では、拡張モニタリングを使用できるいくつかのユースケースについて説明しました。拡張モニタリングを使用することで、既存の AWS DMS モニタリング設定を補完し、モニタリングをより適切に制御し、タスクとレプリケーションインスタンスのモニタリングに関する重要なメトリクスの可視性を得ることができます。 詳細については、 拡張モニタリングダッシュボード をご参照ください。 著者について Suchindranath Hegde Suchindranath は Amazon Web Services のシニアデータ移行スペシャリストソリューションアーキテクトです。彼はお客様と協力して、AWS DMS を使用した AWS へのデータ移行に関するガイダンスと技術支援を提供しています。 Mahesh Kansara Mahesh は Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発チームやエンジニアリングチームと緊密に連携して、移行およびレプリケーションサービスを改善しています。また、お客様と協力して、データベースや分析のさまざまなプロジェクトに関するガイダンスや技術支援を行い、AWS を使用する際のソリューションの価値向上を支援しています。 Balaji Baskar Balaji は、AWS DMS チームのシニアデータベースエンジニアを務めています。この役職では、お客様と緊密に連携して、オンプレミスのワークロードを AWS クラウドに移行しやすくするための専門的な技術指導を行っています。Balaji は、顧客に対する責任だけでなく、品質と機能の両方の向上に重点を置いて、AWS データ移行製品の改善に大きく貢献しています。

本投稿は、Sushant Deshmukh と Alex Anto Kizhakeyyepunnil Joyと Sanyam Jain による記事 「 AWS DMS implementation guide: Building resilient database migrations through testing, monitoring, and SOPs 」を翻訳したものです。 AWS Database Migration Service (AWS DMS) は、データベースの移行とレプリケーションを簡素化し、お客様にマネージドソリューションを提供します。多数のエンタープライズ導入事例から、事前にデータベース移行計画に時間を費やすことで大きな見返りがあることがわかっています。網羅的なセットアップ戦略を採用する組織は、一貫して障害が少なく、より良い移行結果を達成しています。 この投稿では、初期セットアップ段階から AWS DMS の実装を最適化するための事前対策を紹介します。戦略的な計画とアーキテクチャに対する深い洞察力を活用することで、組織はレプリケーションの信頼性を向上させ、パフォーマンスを改善し、一般的な落とし穴を回避することができます。 以下の主要な分野における戦略とベストプラクティスを探ります： 概念実証 (PoC) の計画と実施 体系的な障害テストの実装 標準作業手順書 (SOP) の作成 モニタリングとアラート AWS Well-Architected フレームワーク の原則の適用 PoC の計画と実施 PoC を実施することで、環境の問題を早期に発見し、修正することができます。また、全体的な移行時間とリソースの必要性を見積もるために使用できる情報を作成するのにも役立ちます。 PoCを成功させるための大まかな手順は次のとおりです: 適切な AWS DMS レプリケーションインスタンス、タスク、エンドポイントを使用してテスト環境を計画し、デプロイします。リソースの計画とプロビジョニングの詳細については、 AWS Database Migration Service のベストプラクティス を参照してください。 本番環境に近いワークロードを使用します。様々な問題を発見できる可能性を高めるために、本番環境にできるだけ近い環境をシミュレートすることが不可欠です。 次のセクションの表で説明されているシナリオに基づいて、障害テストを実行します。 PoC 中に発生するリソース使用率とボトルネックを追跡し、それに応じてリソースの計画とデプロイメントを見直します。 観察結果を文書化し、ビジネス成果と比較して移行評価を実施します。これには、移行活動と継続的なビジネス運用の両方について、移行復旧時間とアプリケーションのサービスレベルアグリーメント（ SLA ）の評価が含まれます。これらの移行および運用要件が満たされない場合は、ビジネスニーズに合わせて計画フェーズを見直してください。 体系的な障害テストの実装 すべてのシステムは、その堅牢性に関係なく、障害やダウンタイムが発生する可能性があります。重要なワークロードを実行する組織にとって、事業継続性を維持し、SLA を満たすためには、積極的な計画が不可欠です。このセクションでは、明確な復旧プロトコルを確立し、システム障害時のオペレーションへの影響を最小限に抑える SOP を開発するための戦略的枠組みを提供します。 AWS DMS を実装する場合、耐障害性のあるシステムを構築するには、潜在的な障害点を理解することが重要になります。次の表は、AWS DMS レプリケーションシステムで発生する一般的な障害シナリオの概要を示しており、テスト戦略の基礎となります。包括的ですが、特定のアーキテクチャ、コンプライアンス要件、ビジネス目標に基づいてこれらのシナリオを拡張して、環境内の潜在的な障害モードを完全にカバーすることをお勧めします。 障害ポイント ダウンタイムの可能性があるシナリオ テスト 潜在的な緩和戦略 ソースおよびターゲットデータベース 高 CPU、メモリ制約などのデータベースサーバーのパフォーマンスボトルネック sysbench などのベンチマークツールを使用して、データベースサーバーに高負荷をシミュレートします。 AWS DMS がサポートするエンジンに対して、ソースとしてリードレプリカを使用して読み取り専用データベースノードをプロビジョニングできます。詳細については、 データ移行のソース を参照してください。また、データベースリソースをスケールアップし、データベースパラメータを最適化することもできます。 権限不足によるデータアクセスの問題 権限が少ない AWS DMS 用のデータベースユーザーを使用します。 最小権限の原則に従ってデータベースユーザーを作成します。それぞれのデータベースエンジンに対する DMS が必要とする権限については、AWS DMS ソースエンドポイントの ドキュメント を参照してください。 データベースのフェイルオーバー（プライマリまたはスタンバイ設定を使用している場合） プライマリノードからセカンダリノードへのデータベースフェイルオーバーを実行します。 フェイルオーバー後に AWS DMS が古いプライマリに接続しようとする状況では、動作は Time to Live (TTL) に依存します。TTL が更新された後にタスクを再起動する必要があります。 Amazon Aurora ライターエンドポイントに接続しようとすると、接続がリーダーインスタンスにリダイレクトされるのはなぜですか？ を参照してください。 データベースのシャットダウンまたは障害 進行中の DMS レプリケーションでデータベースを停止します。 SOP 作成のために DMS タスクの動作を記録し、データベースの問題を修正した後にタスクを再開します。 トランザクションログの利用不可 タスクがオフラインまたは遅延している場合に、保持期間の短いログをパージします。 SOP 作成のために DMS タスクの観察結果を記録し、トランザクションログを利用可能にした後にタスクを再開するか、ログが利用できない場合は新しいフルロードを実行します。 スキーマ、テーブル、インデックス、パーティション、データ型などの構造的変更の実行 関連するテーブル変更に対して異なるデータ定義言語 (DDL) ステートメントを実行します。 サポートされている DDL ステートメント のリストと タスク設定 を参照してください。 ネットワーク障害（ソースとターゲットに適用） ネットワーク、DNS、SSL 障害を含む接続の問題 AWS DMS セキュリティグループからソース IP を削除するか、iptables を変更します。DMS エンドポイントから証明書を削除します。MTU （最大伝送単位）の値を変更します。 AWS DMS エンドポイント接続障害 のトラブルシューティングと Amazon RDS への接続の問題 を参照してください。 パケットロス Linux システムでトラフィック制御 (tc) コマンドを使用するか、AWS Fault Injection Simulator (FIS) を使用します。 AWS DMS 診断サポート AMI を使用したデータベース移行中のネットワーク問題のトラブルシューティング と AWS DMS 診断サポート AMI の使用 を参照してください。 AWS DMS の障害 シングル AZ レプリケーションインスタンスの再起動 AWS DMS レプリケーションインスタンスを再起動します。 DMS は、レプリケーションインスタンスの再起動後に自動的にタスクを再開します。 進行中のレプリケーション中のフェイルオーバーを伴うマルチ AZ レプリケーションインスタンスの再起動 「計画的フェイルオーバーで再起動しますか？」オプションを選択して、AWS DMS レプリケーションインスタンスを再起動します。 DMS は、レプリケーションインスタンスのマルチ AZ フェイルオーバー後に自動的にタスクを再開します。 EBS のストレージフル AWS DMS ログによるストレージ不足につながる複数のログコンポーネントの詳細デバッグログを有効にします。 ストレージ容量が 80 ％ に達したときにアラートを設定し、DMS レプリケーションインスタンスに関連付けられたストレージボリュームをスケールアップします。詳細については、 AWS DMS レプリケーション DB インスタンスがストレージ不足の状態になるのはなぜですか？ を参照してください。 メンテナンスウィンドウ中の変更の適用 ダウンタイムを伴う DMS レプリケーションインスタンスの構成を変更し、「次の予定されたメンテナンスウィンドウ中に適用」オプションを選択します。 DMS は、メンテナンス実施後に自動的にタスクを再開します。 レプリケーションインスタンスのリソース競合（高 CPU、メモリ競合、ベースラインより高い IOPS ） 小規模な DMS レプリケーションインスタンスで MaxFullLoadSubTasks の値を高く設定した複数の DMS タスクを作成します。 モニタリングとアラートのセクションで説明されているように、重要な CloudWatch メトリクスに対するモニタリングとアラートを設定します。インスタンスクラスをスケールアップするか、タスクを新しいレプリケーションインスタンスに移動できます。 DMS レプリケーションインスタンスのバージョンアップグレード DMS レプリケーションインスタンスのバージョンをアップグレードします。DMS は古い DMS バージョンを廃止するため、ユーザーはレプリケーションインスタンスのバージョンをアップグレードする必要があります。詳細については、 AWS DMS リリースノート を参照してください。 この活動に関連するダウンタイムを最小限に抑えるために、徹底的な PoC を実施することをお勧めします。PoC テストの後、最新の DMS バージョンで実行される新しいレプリケーションインスタンスを作成し、変更データキャプチャ (CDC) の遅延が 0 または最小の低ピーク時間帯にすべてのタスクを移動することができます。詳細については、 タスクの移動 を参照してください。また、 ビジネスへの影響を最小限に抑えるためにタスクを移動して AWS DMS でサイドバイサイドアップグレードを実行する も参照できます。 データの問題 データの重複 フルロードのみのタスクを 2 回実行します。1 回目はタスクを途中で停止し、2 回目は「何もしない」構成でターゲットテーブル準備モードでタスクを実行します。 サポートされているデータベースエンジンに対して DMS 検証を使用します。検証で不一致が報告された場合は、正確なエラーに基づいて調査する必要があります。問題を緩和するために、フルロードタスクを作成するか、特定のテーブルに対してテーブルのリロード（利用可能な場合）を実行し、その後、進行中のレプリケーションタスクを作成してバックフィルを実行できます。 データ損失 ターゲットにトリガーを作成して、ランダムなレコードを削除または切り捨てます。 このような種類の問題を避けるために、DMS 検証の使用をお勧めします。テーブルまたはタスクのリロードを実行するか、影響を受けたテーブルの新しいデータロードを実行するために新しいフルロードと変更データキャプチャタスクを作成できます。 テーブルエラー DMS タスクが開始される前に、テーブルに対する排他的アクセスロックを取得するか、サポートされていないデータ型を使用します。 これは、DMS でサポートされていない機能または構成が原因で発生する可能性があります。正確なエラーに基づいて調査が必要です。詳細については、 AWS DMS タスクがエラー状態になるのはなぜですか？ を参照してください。 遅延の問題 レプリケーションインスタンスでのスワップファイルの蓄積 変更の多い長時間実行トランザクションを開始し、CloudWatch メトリクス これらのシナリオを体系的にテストし、結果を文書化することで、組織は一般的な障害モードと固有の障害モードの両方に対応する堅牢な復旧手順を開発できます。このプロアクティブなアプローチは、システムの信頼性を維持するだけでなく、問題が発生した際に運用チームが対処するための明確なプロトコルを提供します。 標準作業手順書 (SOP) の作成 障害テストのシナリオでは、各問題がレプリケーションシステムに与える影響を注意深く文書化してください。この文書化は、チームが AWS DMS の実装を管理する際に信頼できる、カスタマイズされた SOPを 作成するための基礎となります。当社の障害テストフレームワークで概説されている緩和戦略は、これらの手順を開発するための優れた出発点として役立ちます。 最初の SOP は、PoC テストの初期段階で明らかになります。これらの手順は、運用経験を積み、新しいシナリオに遭遇するにつれて、定期的な更新と改善が必要な生きたドキュメントとして考える必要があります。データベース移行は動的な性質を持っているため、システムの動作や新たな課題に対する理解とともに、SOP も進化することを意味します。 複雑な移行シナリオの対処に関する追加のガイダンスについては、AWS DMS 移行のデバッグに関する包括的な 3 部構成のブログシリーズをご覧いただくことをお勧めします。これらのリソースは、既存の SOP でカバーされていない状況でも、体系的なトラブルシューティングのアプローチを開発するのに役立つ貴重な洞察を提供します。これらの詳細なガイドは以下で見つけることができます： AWS DMS 移行のデバッグ：問題が発生した場合の対処方法 (パート 1) AWS DMS 移行のデバッグ：問題が発生した場合の対処方法 (パート 2) AWS DMS 移行のデバッグ：問題が発生した場合の対処方法 (パート 3) これらの手順を文書化し、テストすることで、組織は特に重大な障害イベント時に、レプリケーションシステムが SLA を満たす能力を正確に測定し、検証することができます。このプロアクティブなアプローチは、災害復旧戦略における潜在的なボトルネックや改善点を特定するのに役立ち、最終的にデータレプリケーションアーキテクチャの耐障害性と信頼性を強化します。 AWS DMS を使用してデータレプリケーション戦略を設計する際は、サービスの利用不可や、データの不一致を含むシナリオに対する包括的な緊急時対応計画を確立することが極めて重要です。ビジネスの RTO と RPO を徹底的に評価し、それに基づいて SOP を策定する必要があります。この戦略的な計画は、ビジネス継続性を促進するだけでなく、障害シナリオ時のレプリケーションシステムの実際のパフォーマンス指標に関する貴重なインサイトを提供します。 モニタリングとアラート AWS DMS の効果を最大化するには、モニタリングとレポート機能に対する戦略的なアプローチが必要です。堅牢なモニタリングフレームワークは、シームレスなレプリケーション操作を維持し、移行プロセス全体でデータの整合性を促進するために不可欠です。 初期設定時に適切なアラートを構成することで、レプリケーションタスクのリアルタイムな可視性が得られ、異常に対して迅速に対応できるようになります。これらのモニタリング機能は早期警告システムとして機能し、データベース移行インフラストラクチャの健全性と効率性の維持に役立ちます。 プロアクティブな監視とアラートの実装により、運用の信頼性が向上し、リソースの使用状況とパフォーマンスパターンに関するインサイトが得られます。この体系的なアプローチにより、データに基づいた意思決定が可能になり、移行ライフサイクル全体を通じて最適なレプリケーションパフォーマンスを維持できます。 AWS DMS は、以下のモニタリング機能を提供します： Amazon CloudWatch メトリクス – これらのメトリクスは AWS DMS によって自動的に収集され、ユーザーは個々のタスクやレプリケーションインスタンスレベルでのリソース使用状況や関連メトリクスのインサイトを得ることができます。AWS DMS で利用可能なすべてのメトリクスのリストについては、 AWS Database Migration Service メトリクス を参照してください。 AWS DMS CloudWatch ログと Time Travel ログ – AWS DMS はエラーログを生成し、ユーザーが各コンポーネントに設定したログレベルに基づいてそれらを収集します。詳細については、 AWS DMS タスクログの表示と管理 を参照してください。CloudWatch ログが有効な場合、AWS DMS はデフォルトで コンテキストログ も有効にします。さらに、DMS にはレプリケーションタスクのデバッグを支援する Time Travel ログ機能があります。Time Travel ログの詳細については、 Time Travel タスク設定 を参照してください。Time Travel ログの使用に関するベストプラクティスについては、 Time Travel を使用したレプリケーションタスクのトラブルシューティング を参照してください。 タスクとテーブルのステータス – AWS DMS は、タスクとテーブルの状態を報告するためのニアリアルタイムのダッシュボードを提供します。タスクステータスの詳細なリストについては、 タスクステータス を参照してください。テーブルの状態については、 タスク中のテーブル状態 を参照してください。 AWS CloudTrail ログ – AWS DMS は AWS CloudTrail と統合されています。CloudTrail は、ユーザー、ロール、または AWS サービスが AWS DMS で実行したアクションの記録を提供するサービスです。CloudTrail は、AWS DMS コンソールからの呼び出しや AWS DMS API オペレーションへのコード呼び出しを含む、AWS DMS のすべての API 呼び出しをイベントとしてキャプチャします。CloudTrail の設定に関する詳細については、 AWS CloudTrail ユーザーガイド を参照してください。 モニタリングダッシュボード – 拡張モニタリングダッシュボードは、モニタリングタスクとレプリケーションインスタンスに関連する重要なメトリクスの包括的な可視性を提供します。追跡したい特定のリソースのメトリクスをフィルタリング、集計、視覚化できます。このダッシュボードは、データポイントのサンプリング時間を変更することなく、既存の CloudWatch メトリクスを直接公開してリソースのパフォーマンスを監視します。詳細については、 拡張モニタリングダッシュボードの概要 を参照してください。 重要なメトリクスとログイベントに CloudWatch アラームを設定し、システム全体の障害に発展する前に潜在的な問題を事前に特定することをお勧めします。この基本的なモニタリングアプローチは出発点として機能しますが、特定のユースケース要件とビジネス目標に基づいてモニタリング戦略を拡張することが不可欠です。 メトリクスタイプ メトリクス名 改善策 ホストメトリクス CPU 使用率 リソースの競合が DMS タスクのパフォーマンスに影響を与えるため、これらのメトリクスにアラームを設定してオペレーターに警告することをお勧めします。ホストのリソース制限に基づいて、CPU とメモリの競合がある場合は DMS インスタンスクラスをアップグレードするか、ストレージが少ない場合やベースライン IOPS がスロットリングされている場合はストレージを増やす必要があります。適切なレプリケーションインスタンスの選択方法の詳細については、 レプリケーションインスタンスの最適なサイズの選択 を参照してください。 空きメモリ スワップ使用量 空きストレージ容量 書き込み IOPS 読み取り IOPS レプリケーションタスクメトリクス CDC ソースレイテンシー SLA 要件に基づいて、レイテンシーメトリクスのアラームしきい値を設定できます。DMS では、レイテンシーは複数の理由で発生する可能性があります。トラブルシューティングと SOP の作成については、 AWS Database Migration Service のレイテンシー問題のトラブルシューティング を参照してください。 CDC ターゲットレイテンシー レプリケーションインスタンスの DMS イベント 設定変更 これらはそれぞれ、関連する異なるイベントを持つカテゴリです。要件に基づいて特定のイベントに通知を設定できます。これらのイベントの詳細なリストと説明については、 SNS 通知用の AWS DMS イベントカテゴリとイベントメッセージ を参照してください。 作成 削除 メンテナンス ストレージ不足 フェイルオーバー 障害 レプリケーションタスクの DMS イベント 障害 状態変更 作成 削除 利用可能なメトリクスの完全なリストについては、AWS DMS ユーザーガイドの AWS Database Migration Service メトリクス を参照してください。 Amazon EventBridge を使用して AWS DMS イベントが発生した際に通知を提供したり、 Amazon Simple Notification Service （ Amazon SNS ）を使用して重要なイベントのアラートを作成したりすることができます。DMS における EventBridge イベントの詳細については、 EventBridge イベントユーザーガイド を参照してください。AWS DMS での Amazon SNS の使用に関する詳細については、 Amazon SNS イベントユーザーガイド を参照してください。 CloudWatch アラームの設定に加えて、メトリクスフィルターを使用して AWS DMS CloudWatch エラーログに基づくカスタムアラートを作成できます。これらのカスタムアラートの実装に関する詳細な段階的ガイドについては、 Amazon CloudWatch Logs からカスタム AWS DMS エラーに関するアラートを送信する というタイトルのブログ記事を参照してください。このリソースは、カスタムエラー監視機能を強化するための包括的な手順を提供しています。 AWS Well-Architected Framework の原則の適用 AWS Well-Architected Framework は、クラウド上でシステムを構築する際の意思決定の長所と短所を理解するのに役立ちます。フレームワークの 6 つの柱は、信頼性、セキュリティ、優れた運用効率、コストの最適化、持続可能なシステムを設計・運用するためのアーキテクチャのベストプラクティスを教えてくれます。 AWS Well-Architected Tool を使用すると、 AWS マネジメントコンソール で無料で利用可能で、各柱に対する一連の質問に答えることで、これらのベストプラクティスに照らしてワークロードをレビューできます。 クラウドアーキテクチャに関するより専門的なガイダンスとベストプラクティス (リファレンスアーキテクチャのデプロイメント、図解、ホワイトペーパーなど) については、 AWS アーキテクチャセンター を参照してください。 まとめ この投稿では、耐障害性のある AWS DMS 実装を構築するための包括的なフレームワークを紹介しました。このガイドの有効性は、その実装の深さと特定の環境への適応の深さに直接相関しています。組織では、このガイドの各セクションを徹底的に見直して、独自のユースケースに合わせてカスタマイズされた移行戦略を開発するための基礎として活用することを強くお勧めします。 これらの推奨事項を慎重に評価し、移行計画プロセスに組み込むことで、AWS DMS を使用するための包括的で信頼性の高いアプローチを策定できます。これにより、長期的なデータ移動戦略の成功を促進することができます。 追加のサポートとリソースについては、 AWS DMS ドキュメント をご覧いただくか、 AWS サポート にお問い合わせください。 著者について Sanyam Jain は、AWS Database Migration Service チームのデータベースエンジニアです。お客様と緊密に連携し、オンプレミスのワークロードを AWS クラウドに移行するための技術的なガイダンスを提供しています。さらに、AWS データ移行製品の品質と機能の向上において重要な役割を果たしています。 Sushant Deshmukh は、グローバルシステムインテグレーターを担当するシニアパートナーソリューションアーキテクトです。AWS 上で高可用性、スケーラブル、レジリエント、そして安全なアーキテクチャを設計することに情熱を注いでいます。AWS の顧客やパートナーが、アプリケーションを AWS クラウドに成功裏に移行し、モダナイズするのを支援しています。仕事以外では、新しい場所や料理を探索する旅行、バレーボール、そして家族や友人との質の高い時間を過ごすことを楽しんでいます。 Alex Anto は、Amazon Web Services の Amazon Database Migration Accelerator チームに所属するデータ移行スペシャリストソリューションアーキテクトです。 Amazon DMA アドバイザーとして、AWS のお客様がオンプレミスのデータを AWS クラウドデータベースソリューションに移行するのを支援しています。

概要 サイバーレジリエンスとは、サイバー攻撃を受けることを前提として、攻撃を予防し、検知し、対応し、復旧する能力を総合的に高めることです。従来の「攻撃を防ぐことに主眼を置く」という考え方に加えて、「攻撃を受けても事業を継続し、迅速に復旧する」という考え方も求められています。 特に可用性に影響を与えるランサムウェア攻撃や DDoS 攻撃といったサイバーイベントに対する防御や復旧策は、実装が急務とされています。 昨今のこのような状況を踏まえ、この度、金融リファレンスアーキテクチャの新たなユースケースを提供いたします。金融機関におけるサイバーイベントからの迅速な復旧について、具体的なアーキテクチャと実装サンプルをセットでご紹介します。 https://github.com/aws-samples/baseline-environment-on-aws-for-financial-services-institute/tree/main/doc/reference-arc-cyber-resilience 市場背景 サイバー脅威の高度化・複雑化 近年、金融機関を標的としたサイバー攻撃は急速に高度化・複雑化しており、従来のセキュリティ対策だけでは十分に対応できない状況となっています。特に以下のような脅威が顕在化しています： ランサムウェア攻撃の急増 : 金融機関のシステムを暗号化し、身代金を要求する攻撃が急増。業務停止による甚大な影響 DDoS 攻撃の大規模化 : 分散型サービス拒否攻撃による可用性への脅威。顧客サービスの停止リスク サイバーレジリエンス要件の明確化 このような脅威の高度化を受け、各種ガイドラインでサイバーレジリエンスの要件が明確化されています。 サイバーレジリエンスに関して、 NIST が公開した SP 800-160 Vol.2 では、サイバーレジリエンスを理解し適用するのに役立つフレームワークや、システムライフサイクルで実装するためのエンジニアリング観点の考慮事項が提示されています。 また、金融庁は「 金融分野におけるサイバーセキュリティに関するガイドライン 」を策定し、セキュリティリスクの特定からインシデント対応、復旧に至るまでの包括的な枠組みを提示しています。 特に本リファレンスアーキテクチャに関連する要件として、同ガイドラインでは以下の項目を基本的な対応事項として定義しており、これらの要件を満たすアーキテクチャの実装が求められています。 データ保護 (金融庁ガイドラインより抜粋) バックアップに関する規程整備 システム及び情報の重要度に応じたバックアップ要件 バックアップデータの隔離と保護 整合性の検証 復旧テストの実施 ランサムウェア攻撃への対応 バックアップの期間や頻度を検討する 改ざん耐性バックアップシステムの利用 組織内ネットワークから切り離した複数の環境での保管や媒体等へのバックアップ サイバーインシデント対応 (金融庁ガイドラインより抜粋) 初動対応 インシデントの検知 封じ込め 実施の判断を行う権限者を明確にし、証拠保全との優先度を考慮した上で、被害防止のための通信の遮断・システム停止を判断する バックアップからの復旧 バックアップデータの改ざん検出 マルウェア感染への対応 従来の災害復旧とサイバーイベント復旧の違い 従来のバックアップ・リカバリーでは、以下の災害を想定した対策が中心でした。 自然災害: 洪水、地震、竜巻など 人為的災害: 火災、停電、テロ攻撃など しかし、この戦略ではランサムウェア攻撃には十分ではありません。 主な課題 感染データの拡散リスク: 感染したデータがバックアップにコピーされるリスク 横展開攻撃のリスク: メインデータセンターの感染がセカンダリサイトに数秒で拡散するリスク サイバー攻撃対応に必要な要件 サイバー攻撃を想定した環境では、以下の対応が必要です： 感染データの隔離: 感染したデータを保管しない データの不変性: バックアップデータを攻撃者によって改ざんされないよう保護する クリーンな復旧: 感染したデータから復旧しない 実装アプローチ これを実現するため、以下の対策を実装する必要があります： データボールト（隔離されたバックアップ環境）の構築 : 本番環境・インターネットから物理的・論理的に分離されたバックアップ専用環境 限定的な接続性の実装 : ネットワーク制御・アクセス制御による最小限の接続のみを許可 独立した復旧環境の準備 : メインデータセンターが感染している可能性を考慮し、本番環境とは完全に別の環境でシステムを復旧 サイバーイベントリカバリーの実装例 こうした要件をもとに、本リファレンスアーキテクチャでの実装例について紹介します。 1. バックアップの取得 一つ目の機能はバックアップの取得です。ランサムウェア攻撃などのサイバー脅威からデータを確実に保護するため、AWS Backup Logically Air-gapped Vault を活用し、論理的に隔離されたデータバンカーアカウントへバックアップを自動コピーします。論理的な隔離とは、厳格なアクセス制御と不変性の仕組みによって、バックアップデータに対する操作（読み取り、変更、削除）を不可能にし、管理者権限を持つユーザーや攻撃者でさえも、指定した保持期間中は変更・削除できないよう制御することを意味します。 バックアップ作業は2段階で実施されます：①データバンカーアカウントでの AWS Backup Logically Air-gapped Vault 作成とアクセス許可設定、②ワークロードアカウントからの自動コピー設定。これにより本番環境とは完全に分離された環境でバックアップが保護されます。 2. リストア 二つ目の機能はリストアです。ランサムウェア感染を考慮し、バックアップデータを論理的に隔離した上で、本番とは完全に別の環境での復旧を想定しています。 復旧作業は3段階で実施されます：①Resource Access Manager (RAM) 共有設定、②データベース復旧、③ワークロード再接続。セキュリティと効率性のバランスを考慮し、重要な判断は手動、定型作業は自動化することで、ヒューマンエラーを最小限に抑えながら迅速な復旧を実現します。 3. 自動隔離 三つ目の機能は自動隔離です。環境内に脅威が発生した際、対象システムを隔離することで、影響範囲を最小限に留めることができます。本サイバーレジリエンス機能における自動隔離では以下の実装を提供しています。 Amazon GuardDuty で重大度が Critical の脅威が検出された際、そのイベントから隔離用 Lambda 関数を実行し、勘定系ワークロードが存在するサブネットの Network ACL との関連付けを隔離用の ACL に変更します。Network ACL の変更が完了すると、Amazon SNS でセキュリティ管理者にメールで通知します。 実装詳細は  GitHub リポジトリ をご確認ください。 まとめ 金融機関を取り巻くサイバー脅威の高度化・複雑化が進む中、特にランサムウェア攻撃やDDoS攻撃といった可用性への脅威には、「攻撃を受けても事業を継続し、迅速に復旧する」サイバーレジリエンスの考え方が不可欠です。 本リファレンスアーキテクチャでは、以下の3つの主要機能を実装しています： 論理的に隔離されたバックアップ : AWS Backup Logically Air-gapped Vault を活用し、本番環境から完全に分離されたデータバンカーアカウントでバックアップを保護 クリーンな環境での復旧 : 本番環境での感染リスクを考慮し、別環境でのリストア機能を提供 自動隔離による被害拡大防止 : Amazon GuardDuty と連携した自動隔離機能により、脅威検出時の迅速な封じ込めを実現 このリファレンスアーキテクチャを活用し、より堅牢なサイバーレジリエンス体制の構築に取り組まれることを願っています。また、より良い金融リファレンスアーキテクチャの発展に向けて、皆様からのフィードバックもお待ちしております。 本ブログ記事は、AWS のソリューションアーキテクト 河角 修、佐藤 航大、小宮山 裕樹 が執筆いたしました。