本稿は、2025 年 7 月 14 日に AWS Migration & Modernization Blog で公開された “ Using Export for vCenter with AWS Transform ” を翻訳したものです。 Export for vCenter は、AWS Transform for VMware で利用するために vCenter からインベントリデータをエクスポートする、新しい AWS オープンソース Python プロジェクトです。Export for vCenter は、AWS Transform for VMware および AWS Transform Assessments が必要とするデータのみを取得します。データは RVTools 形式と一致する列を持つ CSV 形式でエクスポートされます。 Export for vCenter は、以下のようなお客様からのフィードバックにお応えするために用意されました： vCenter インベントリを取得するために Windows 実行ファイルをインストールしたくない Python はアプリケーションセキュリティによって承認されているが、RVTools については承認を待つ必要がある vCenter Server に対してどの API 呼び出しが実行されているかを把握したい vCenter インベントリを取得するために Windows クライアントを使用したくない どの仮想マシンの情報がエクスポートされるかを簡単に制御したい 必要最小限の情報のみを確実にエクスポートしたい どのような理由であれ、AWS Transform 用に vCenter からインベントリデータをエクスポートするために、Export for vCenter を利用できます。 使用開始 このプロジェクトは現在、 Export for vCenter GitHub リポジトリで利用できます。セットアップ手順と実行手順が  README に記載されています。プロジェクトを実行できるようになるまで数分しかかかりません。 図 1 に示すように、正規表現に基づいて仮想マシンをスキップすることができます。 図 1 – 仮想マシン スキップリストファイル vm-skip-list.txt 以下は実行中のスクリプトの例です。 図 2 – vCenter 用エクスポートの実行 スクリプトは ‘vcexport.zip’ という名前のファイルを出力します。zip 内のファイル名は RVTools で CSV エクスポートした場合と一致します。CSV の総数とその中の列は、RVTools エクスポートのサブセットです。AWS Transform で必要とするデータのみがエクスポートされます。 図 3 – Export for vCenter によってエクスポートされた CSV ファイル AWS Transform for VMware がエクスポートしたデータを RVTools Export として検出した例です。 図 4 – AWS Transformへのインポートが成功 クリーンアップ 環境変数を削除するため、ターミナルセッションを終了します 任意 – エクスポートファイルである vcexport.zip を削除します 任意 – 今後新しいエクスポートを実行する予定がない場合は、プロジェクトフォルダ全体を削除します 結論 Export for vCenter は、vCenter からのデータエクスポートを行うための代替ツールを提供する AWS のオープンソースプロジェクトです。このブログでは、スクリプトの機能を簡単に紹介しました。AWS Transform for VMware および AWS Transform Assessments において、RVTools の代替として使用できます。主な利点は以下の通りです： AWS Transform が必要とするデータフィールドのみがエクスポートされます 正規表現を使用して仮想マシンをフィルタリングできます ソースコードを実行ファイル形式にコンパイルする必要がありません Windows クライアントは必要ありません 実際にお試しいただくには、 Export for vCenter GitHub リポジトリをご確認ください。 Patrick Kremer インフラストラクチャのマイグレーションとモダナイゼーションに特化したシニアスペシャリストソリューションアーキテクトです。2022 年に AWS に入社し、20 年間の VMware での経験を活かして、お客様の AWS ソリューションへの移行を支援しています。AWS Solutions Architect Professional の認定を取得しており、教育とブログ執筆に情熱を注いでいます。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。

わずか数年で、 基盤モデル (FM) は、ユーザーのプロンプトに応じてコンテンツを直接作成するために使用されるものから、現在では AI エージェント を強化するものへと進化しました。AI エージェントは、限定的な人間による監視を使用しながら、ユーザーが定義した目標の達成を目指して、FM を使用して推論、計画、実行、学習、適応する新しいクラスのソフトウェアアプリケーションです。エージェンティック AI のこの新しい波は、エージェントが他のツールやシステムと接続する方法を簡素化する、 Model Context Protocol (MCP) や Agent2Agent (A2A) などの標準化されたプロトコルの登場によって可能となりました。 実際、複雑なタスクを確実に実行できる AI エージェントの構築は、 CrewAI 、 LangGraph 、 Strands Agents などのオープンソースフレームワークのおかげで、ますます容易になっています。しかし、有望な概念実証から、数千のユーザーに合わせてスケールできる本番対応のエージェントへと移行するには、大きな課題があります。 デベロッパーや AI エンジニアは、エージェントの中核的な機能に注力する代わりに、セッション管理、ID コントロール、メモリシステム、オブザーバビリティのために基盤インフラストラクチャの構築に数か月間を費やし、同時にセキュリティとコンプライアンスをサポートしなければなりません。 7 月 16 日、 Amazon Bedrock AgentCore のプレビューを発表しました。これは、デベロッパーが Amazon Bedrock または他の場所でホストされているあらゆるフレームワークとモデルを使用して、AI エージェントを大規模、迅速、安全にデプロイおよび運用するのに役立つ、包括的な一連のエンタープライズグレードのサービスです。 より具体的に、7 月 16 日に発表した内容を次に示します: AgentCore Runtime – セッション分離を備え、サンドボックス化された低レイテンシーのサーバーレス環境を提供し、人気のオープンソースフレームワーク、ツール、モデルを含むあらゆるエージェントフレームワークをサポートし、マルチモーダルワークロードと長時間実行エージェントを処理します。 AgentCore Memory – セッションと長期メモリを管理し、エージェントが過去のインタラクションから学習するのをサポートしつつ、モデルに関連コンテキストを提供します。 AgentCore Observability – メタデータのタグ付け、カスタムスコアリング、軌跡の検査、トラブルシューティング/デバッグフィルターを使用して、エージェント実行のステップバイステップのビジュアライゼーションを提供します。 AgentCore Identity – AI エージェントが、ユーザーに代わって、または事前に認可されたユーザーの同意を得てエージェント自身によって、AWS サービス、および GitHub、Salesforce、Slack などのサードパーティーツールやサービスに安全にアクセスできるようにします。 AgentCore Gateway – 既存の API と AWS Lambda 関数をエージェント対応ツールに変換し、MCP などのプロトコルやランタイム検出にわたる統合アクセスを提供します。 AgentCore Browser – エージェントのウェブオートメーションワークフローをスケールするためのマネージドウェブブラウザインスタンスを提供します。 AgentCore Code Interpreter – エージェントが生成したコードを実行するための独立した環境を提供します。 これらのサービスは個別に使用でき、連携するように最適化されているため、デベロッパーはコンポーネントをつなぎ合わせるために時間を費やす必要がありません。AgentCore はオープンソースまたはカスタム AI エージェントフレームワークと連携できるため、チームはエンタープライズレベルの機能を利用しながら、好みのツールを維持する柔軟性を得ることができます。これらのサービスを既存のコードに統合するために、デベロッパーは AgentCore SDK を使用できます。 AgentCore Runtime を使用して、 AWS Marketplace から事前構築済みのエージェントとエージェントツールを検索、購入、実行できるようになりました。わずか数行のコードで、エージェントは AgentCore Gateway を使用して AWS Marketplace で入手できる API ベースのエージェントやツールに安全に接続できるため、コンプライアンスとコントロールを維持しながら、複雑なワークフローを実行するのに役立ちます。 AgentCore は煩雑なインフラストラクチャ作業と運用上の複雑さを排除するため、開発チームは画期的なエージェントソリューションをより迅速に市場に投入できます。 これが実際にどのように機能するのかを見てみましょう。サービスについては、使用していく中でさらに情報を共有します。 Amazon Bedrock AgentCore を使用して本番対応のカスタマーサポートアシスタントをデプロイする (プレビュー) 顧客から E メールで問い合わせがあった場合、返信には時間がかかります。カスタマーサポートは、E メールの正当性を確認し、顧客関係管理 (CRM) システムで実際の顧客を特定して、注文を確認し、製品固有のナレッジベースを使用して回答の準備に必要な情報を見つける必要があります。 AI エージェントは、内部システムに接続し、セマンティックデータソースを使用してコンテキスト情報を取得して、サポートチームのために返信案を作成することで、これらの作業を簡素化できます。このユースケースでは、Strands Agents を使用してシンプルなプロトタイプを構築しました。簡潔さのため、およびシナリオを検証するため、内部ツールは Python 関数を使用してシミュレーションされています。 デベロッパーと話をすると、多くの企業で、さまざまなユースケースをカバーする同様のプロトタイプが構築されていることがわかります。これらのプロトタイプを企業のリーダーシップにデモンストレーションし、進めることについて確認してもらった後、開発チームは本番への移行方法を定義し、セキュリティ、パフォーマンス、可用性、スケーラビリティに関する一般的な要件を満たす必要があります。ここで AgentCore が役立ちます。 ステップ 1 – AgentCore Runtime を使用してクラウドにデプロイする AgentCore Runtime は、AI エージェントを安全にデプロイ、実行、スケールするための新しいサービスです。各ユーザーセッションが独自の保護された環境で実行されるように分離を提供することで、データ漏えいを防止するのに役立ちます。これは、機密データを扱うアプリケーションにとって重要な要件です。 さまざまなセキュリティ体制に対応するために、エージェントはさまざまなネットワーク構成を使用できます: サンドボックス – 許可リストに登録された AWS サービスとのみ通信するため。 パブリック – マネージドインターネットアクセスを使用して実行するため。 VPC のみ (近日リリース予定) – このオプションでは、お客様の VPC でホストされているリソース、または AWS PrivateLink エンドポイント経由で接続されているリソースにアクセスできます。 エージェントをクラウドにデプロイし、AgentCore Runtime を使用して安全なサーバーレスエンドポイントを取得するために、AgentCore SDK を使用してプロトタイプに数行のコードを追加し、次を実行します: AgentCore SDK をインポートする。 AgentCore アプリケーションを作成する。 エージェントを呼び出すエントリポイントとなる関数を指定する。 別のエージェントフレームワークまたはカスタムエージェントフレームワークを使用する場合は、エントリポイント関数内のエージェント呼び出しを置き換えます。 プロトタイプのコードを次に示します。AgentCore Runtime を使用するために追加した 3 行は、先頭にコメントが付いているものです。 from strands import Agent, tool from strands_tools import calculator, current_time # Genesis SDK をインポートします from bedrock_agentcore.runtime import BedrockAgentCoreApp WELCOME_MESSAGE = """ Welcome to the Customer Support Assistant! How can I help you today? """ SYSTEM_PROMPT = """ You are an helpful customer support assistant. When provided with a customer email, gather all necessary info and prepare the response email. When asked about an order, look for it and tell the full description and date of the order to the customer. Don't mention the customer ID in your reply. """ @tool def get_customer_id(email_address: str): if email_address == "me@example.net": return { "customer_id": 123 } else: return { "message": "customer not found" } @tool def get_orders(customer_id: int): if customer_id == 123: return [{ "order_id": 1234, "items": [ "smartphone", "smartphone USB-C charger", "smartphone black cover"], "date": "20250607" }] else: return { "message": "no order found" } @tool def get_knowledge_base_info(topic: str): kb_info = [] if "smartphone" in topic: if "cover" in topic: kb_info.append("To put on the cover, insert the bottom first, then push from the back up to the top.") kb_info.append("To remove the cover, push the top and bottom of the cover at the same time.") if "charger" in topic: kb_info.append("Input: 100-240V AC, 50/60Hz") kb_info.append("Includes US/UK/EU plug adapters") if len(kb_info) > 0: return kb_info else: return { "message": "no info found" } # AgentCore アプリケーションを作成します app = BedrockAgentCoreApp() agent = Agent( system_prompt=SYSTEM_PROMPT, tools=[calculator, current_time, get_customer_id, get_orders, get_knowledge_base_info] ) # エージェントを呼び出すエントリポイント関数を指定します @app.entrypoint def invoke(payload, context: RequestContext): """Handler for agent invocation""" user_message = payload.get( "prompt", "No prompt found in input, please guide customer to create a json payload with prompt key" ) result = agent(user_message) return {"result": result.message} if __name__ == "__main__": app.run() AgentCore SDK とスターターツールキットを Python 仮想環境にインストールします: pip install bedrock-agentcore bedrock-agentcore-starter-toolkit 仮想環境をアクティブ化すると、スターターツールキットによって提供される AgentCore コマンドラインインターフェイス (CLI) にアクセスできるようになります。 まず、 agentcore configure --entrypoint my_agent.py -er <IAM_ROLE_ARN> を使用してエージェントを設定し、エージェントが引き受ける AWS Identity and Access Management (IAM) ロールを渡します。この場合、エージェントは、モデルを呼び出すために Amazon Bedrock にアクセスできる必要があります。このロールは、 Amazon Simple Storage Service (Amazon S3) バケットや Amazon DynamoDB テーブルなど、エージェントが使用する他の AWS リソースへのアクセスを付与できます。 agentcore launch --local を使用してエージェントをローカルで起動します。ローカルで実行している場合は、 agentcore invoke --local <PAYLOAD> を使用してエージェントとインタラクションできます。ペイロードはエントリポイント関数に渡されます。呼び出しの JSON 構文はエントリポイント関数で定義されていることにご留意ください。この場合、JSON ペイロードで prompt を検索しますが、ユースケースに応じて異なる構文を使用することもできます。 ローカルテストで問題がなければ、 genesis launch を使用してクラウドにデプロイします。 デプロイが成功し、エンドポイントが作成されたら、 agentcore status を使用してエンドポイントのステータスを確認し、 agentcore invoke <PAYLOAD> を使用してエンドポイントを呼び出します。例えば、呼び出しでカスタマーサポートリクエストを渡します: agentcore invoke '{"prompt": "From: me@example.net – Hi, I bought a smartphone from your store.I am traveling to Europe next week, will I be able to use the charger? Also, I struggle to remove the cover.Thanks, Danilo"}' ステップ 2 – コンテキストのメモリを有効にする エージェントが AgentCore Runtime にデプロイされた後、新しい呼び出しで使用できるようにコンテキストを永続化する必要があります。AgentCore Memory を追加し、その短期メモリ機能を使用してセッションコンテキストを維持します。 まず、会話用のメモリクライアントとメモリストアを作成します: from bedrock_agentcore.memory import MemoryClient memory_client = MemoryClient(region_name="us-east-1") memory = memory_client.create_memory_and_wait( name="CustomerSupport", description="Customer support conversations" ) これで、 create_event を使用して、エージェントのインタラクションを短期メモリに保存できるようになりました: memory_client.create_event( memory_id=memory.get("id"), # メモリストアを識別します actor_id="user-123", # ユーザーを識別します session_id="session-456", # セッションを識別します messages=[ ("Hi, ...", "USER"), ("I'm sorry to hear that...", "ASSISTANT"), ("get_orders(customer_id='123')", "TOOL"), . . . ] ) list_events を使用して、会話の最新のターンを短期メモリからロードできます: conversations = memory_client.list_events( memory_id=memory.get("id"), # メモリストアを識別します actor_id="user-123", # ユーザーを識別します session_id="session-456", # セッションを識別します max_results=5 # 取得する最新のターンの数 ) この機能により、エージェントは長時間のセッションでもコンテキストを維持できます。ただし、ユーザーが新しいセッションで戻ってくると、会話は空白の状態から始まります。エージェントは、長期メモリを使用して、複数のインタラクションにわたるインサイトを保持することで、ユーザーエクスペリエンスをパーソナライズできます。 会話からメモリを抽出するために、ユーザーの好み、要約、セマンティックメモリ (事実を取得するため) 用の組み込み AgentCore Memory ポリシーを使用するか、または特殊なニーズに合わせてカスタムポリシーを作成できます。データは、データセグメンテーション用の名前空間ベースのストレージを使用して暗号化された上で保存されます。 以前のメモリストア作成コードを変更し、セマンティックメモリ戦略を渡すことで長期保存機能を含めます。なお、既存のメモリストアを更新して戦略を追加することができます。その場合、新しい戦略はより新しいイベントに適用されます。 memory = memory_client.create_memory_and_wait( name="CustomerSupport", description="Customer support conversations", strategies=[{ "semanticMemoryStrategy": { "name": "semanticFacts", "namespaces": ["/facts/{actorId}"] } }] ) メモリストアのために長期メモリが設定された後、 create_event を呼び出すと、それらの戦略が自動的に適用され、会話から情報が抽出されます。その後、セマンティッククエリを使用して、会話から抽出されたメモリを取得できます: memories = memory_client.retrieve_memories( memory_id=memory.get("id"), namespace="/facts/user-123", query="smartphone model" ) このように、エージェントが CRM の範囲外にある顧客の好みや事実を記憶し、この情報を使用して返信を改善するようにすることで、ユーザーエクスペリエンスを迅速に改善できます。 ステップ 3 – ID およびアクセスコントロールを追加する 適切な ID コントロールがない場合、エージェントから内部ツールへのアクセスは常に同じアクセスレベルを使用します。セキュリティ要件を満たすために、AgentCore Identity を統合し、ユーザーまたはエージェントの ID コンテキストにスコープ設定されたアクセスコントロールをエージェントが使用できるようにします。 ID クライアントをセットアップし、ワークロード ID を作成します。これは、AgentCore Identity システム内でエージェントを表す一意の識別子です: from bedrock_agentcore.services.identity import IdentityClient identity_client = IdentityClient("us-east-1") workload_identity = identity_client.create_workload_identity(name="my-agent") その後、認証情報プロバイダーを設定します。例: google_provider = identity_client.create_oauth2_credential_provider( { "name": "google-workspace", "credentialProviderVendor": "GoogleOauth2", "oauth2ProviderConfigInput": { "googleOauth2ProviderConfig": { "clientId": "your-google-client-id", "clientSecret": "your-google-client-secret", } }, } ) perplexity_provider = identity_client.create_api_key_credential_provider( { "name": "perplexity-ai", "apiKey": "perplexity-api-key" } ) アクティビティを実行するためにアクセストークンを必要とする関数に対して、 @requires_access_token Python デコレーターを追加できます (プロバイダー名、スコープなどを渡します)。 このアプローチを使用することで、エージェントは、会社の既存の ID インフラストラクチャを通じて ID を検証し、個別の認証済み ID として動作するとともに、スコープ設定された許可を使用して動作して、複数の ID プロバイダー ( Amazon Cognito 、 Okta 、 Microsoft Entra ID など) や、AWS およびサードパーティーのツールやサービス (Slack、GitHub、Salesforce など) を含むサービス境界を統合できます。 エンドユーザーおよびエージェントビルダーエクスペリエンスを合理化しながら、堅牢かつ安全なアクセスコントロールを提供するために、AgentCore Identity は、ユーザーのトークンを保存し、エージェントが安全に取得できるようにする安全なトークンボールトを実装します。 OAuth 2.0 互換のツールおよびサービスでは、まず、エージェントがユーザーに代わってアクションを実行するための同意をユーザーが付与すると、AgentCore Identity はツールによって発行されたユーザーのトークンを収集してボールトに保存し、エージェントの OAuth クライアント認証情報も安全に保管します。エージェントは独自の ID で動作し、ユーザーによって呼び出されると、必要に応じてこれらのトークンにアクセスできるため、ユーザーの同意を頻繁に得る必要性が軽減されます。 ユーザートークンが失効すると、AgentCore Identity はユーザーに対して新しい認可プロンプトをトリガーし、更新されたユーザートークンをエージェントが取得できるようにします。API キーを使用するツールでも、AgentCore Identity はこれらのキーを安全に保管し、必要に応じてそれらのキーを取得するための制御されたアクセスをエージェントに付与します。この安全な保管により、堅牢なアクセスコントロールを維持しながら、ユーザーエクスペリエンスを効率化できるため、エージェントはさまざまなツールやサービスで効率的に動作できます。 ステップ 4 – AgentCore Gateway を使用してエージェント機能を拡張する これまで、すべての内部ツールはコード内でシミュレートされていました。Strands Agents を含む多くのエージェントフレームワークは、リモートツールに接続するため MCP をネイティブにサポートしています。MCP インターフェイスを介して内部システム (CRM や注文管理など) にアクセスするために、私は AgentCore Gateway を使用します。 AgentCore Gateway を使用すると、エージェントは、 Smithy モデル、Lambda 関数、内部 API、および OpenAPI 仕様を使用するサードパーティープロバイダーを使用して AWS サービスにアクセスできます。同サービスは、着信リクエストとターゲットリソースに対する発信接続の両方のために安全なアクセスコントロールを実現することを目的として、二重認証モデルを採用しています。Lambda 関数は、外部システム (特に標準 API がないアプリケーションや、情報を取得するために複数のステップを実行する必要があるアプリケーション) を統合するために使用できます。 AgentCore Gateway は、認証、認可、スロットリング、カスタムリクエスト/レスポンス変換 (基盤となる API 形式に合わせるため)、マルチテナンシー、ツール選択など、同サービスがなければほとんどのお客様が独自に構築しなければならないであろう分野横断的な機能を簡単に使用できるようにします。 ツール選択機能は、特定のエージェントのタスクに最も適したツールを見つけるのに役立ちます。AgentCore Gateway は、これらすべてのツールにわたって統一された MCP インターフェイスを提供し、AgentCore Identity を使用して、AWS サービスのように OAuth を標準でサポートしていないツールに OAuth インターフェイスを提供します。 ステップ 5 – AgentCore Code Interpreter および Browser ツールを使用して機能を追加する 顧客のリクエストに回答するために、カスタマーサポートエージェントは、計算を実行する必要があります。これを簡素化するために、AgentCode SDK を使用して AgentCore Code Interpreter に対するアクセスを追加します。 同様に、エージェントによって必要とされる一部の統合は、プログラムで呼び出せる API を実装しておらず、ウェブインターフェイスを通じてアクセスする必要があります。エージェントがこれらのウェブサイトを自律的にナビゲートできるように、AgentCore Browser に対するアクセスを付与します。 ステップ 6 – オブザーバビリティを使用して可視性を得る エージェントが本番に移行したので、そのアクティビティとパフォーマンスについての可視性が必要です。AgentCore は、デベロッパーが本番でエージェントのパフォーマンスを効果的にデバッグ、監査、モニタリングするのに役立つよう、強化されたオブザーバビリティを提供します。セッション数、レイテンシー、期間、トークン使用量、エラー率、コンポーネントレベルのレイテンシーとエラーの内訳など、重要な運用メトリクスを追跡するためのダッシュボードが組み込まれています。また、AgentCore は、エンドツーエンドのトレースだけでなく、ツールの呼び出し、メモリなど、エージェントワークフローの各ステップをキャプチャする「スパン」もキャプチャして視覚化することで、エージェントの動作を可視化します。 このサービスが提供する組み込みダッシュボードは、パフォーマンスのボトルネックを明らかにし、特定のインタラクションが失敗し得る理由を特定するのに役立ちます。これにより、継続的な改善が可能になり、問題が発生した場合の平均検出時間 (MTTD) と平均是正時間 (MTTR) を短縮できます。 AgentCore は、エージェントのテレメトリデータを、 Amazon CloudWatch 、 Datadog 、 LangSmith 、 Langfuse などの既存のオブザーバビリティプラットフォームと統合するのに役立つよう、 OpenTelemetry をサポートしています。 ステップ 7 – まとめ このジャーニーを通じて、ローカルプロトタイプを本番対応システムに変革しました。AgentCore のモジュール型アプローチを採用することで、既存のエージェントコードを維持しながら、基本的なデプロイから、高度なメモリ、ID 管理、ツール統合まで、エンタープライズ要件を段階的に実装できました。 知っておくべきこと Amazon Bedrock AgentCore は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、および欧州 (フランクフルト) において、プレビューでご利用いただけます。AgentCore サービスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK を通じて、または AgentCore SDK を介してご利用いただけます。 AgentCore サービスは、2025 年 9 月 16 日まで無料でお試しいただけます。AgentCore の使用の一環として使用される追加の AWS サービスには、標準の AWS 料金が適用されます (例えば、AgentCore Observability については CloudWatch の料金が適用されます)。2025 年 9 月 17 日より、AWS は AgentCore サービスの使用料金を このページに基づいて 請求します。 構築しようとしているのが、カスタマーサポートエージェント、ワークフローオートメーション、AI を使用した革新的なエクスペリエンスのいずれであっても、AgentCore は、プロトタイプから本番に自信をもって移行するために必要な基盤を提供します。 詳細を確認し、本番対応エージェントのデプロイを開始するには、 AgentCore ドキュメント にアクセスしてください。コード例と統合ガイドについては、 AgentCore サンプル GitHub リポジトリ をご覧ください。 フィードバックを提供したり、ユースケースについて議論したりするために、 AgentCore Preview Discord サーバー にぜひご参加ください。皆様からのご意見をお待ちしております! – Danilo 原文は こちら です。

本稿は、2024 年 8 月 22 日に AWS DevOps & Developer Productivity Blog で公開された “ Use AWS CloudFormation Git sync to configure resources in customer accounts ” を翻訳したものです。 AWS パートナーは、お客様のアカウントにクロスアカウントロールなどのリソースを作成する必要があることが多くあります。これらのリソースを一貫して プロビジョニングするのに適した選択肢は、 AWS CloudFormation です。これは、JSON または YAML で記述されたテンプレートファイルでアーキテクチャを指定できる Infrastructure as Code (IaC) サービスです。また、CloudFormation には StackSets という機能があり、複数のリージョンとアカウントに並列でリソースをデプロイできます。この機能は、 マルチアカウント戦略 を採用するお客様にとって非常に価値があります。 パートナーにとっての課題は、テンプレートをお客様に提供する適切な手法を選択し、変更や追加が必要になった際にデプロイされたリソースを更新する方法を決めることです。CloudFormation では、 クイック作成リンク を使ってテンプレートに基づいてスタックを 1 クリックで起動できる簡単な体験を提供していますが、後日スタックを自動的に更新する方法は提供していません。この記事では、 CloudFormation Git 同期 機能を使用して、パートナー定義のリソースをアカウントにデプロイする際に、お客様に最大限の制御と柔軟性を与える方法について説明します。 CloudFormation Git 同期を使用すると、Git リポジトリへの接続を構成し、選択したブランチの変更を監視できます。テンプレートファイルに変更をプッシュするたびに、スタックのデプロイが自動的に行われます。これは、 AWS CodePipeline のようなサービスを使用して完全な CI/CD パイプラインを設定するよりも簡単で強力な自動化機能です。Git リポジトリを運用する際の一般的な方法として、オリジナルのリポジトリをフォークすることがあります。フォークとは、オリジナルのリポジトリのコピーを自身のGitアカウントに作成することです。この自身のフォーク先リポジトリは完全に自分でコントロールできます。フォーク先リポジトリで、ソースコードを変更したり、オリジナルのリポジトリ(アップストリームリポジトリ)から変更を取り込んでマージしたりと、柔軟に対応できます。 パートナーのリポジトリ、お客様のフォークされたリポジトリ、そしてGit同期が有効になったスタック 上の図では、左側に AWS パートナーの Git リポジトリが表されています。このリポジトリには、パートナーが最新バージョンの CloudFormation テンプレートを保持しています。お客様アカウントで必要なリソースの要件が変わるにつれて、このテンプレートも変更される可能性があります。中央には、テンプレートのコピーを保持するお客様のフォークされたリポジトリがあります。お客様はテンプレートをカスタマイズできます。また、パートナーからのアップストリームの変更をフェッチおよびマージすることもできます。これは、自分が所有するアカウントでリソースが作成または変更されるときに、細かな制御と内部レビューを行いたいお客様にとって重要な考慮事項です。右側はお客様アカウントで、リソースがプロビジョニングされる場所です。 AWS CodeConnections を介して Git 同期が構成された CloudFormation スタックは、フォークされたリポジトリにマージされた変更をすべて自動的にデプロイします。 GitHub の公開リポジトリをフォークした場合、たとえプライベートの GitHub Organization 内であっても、その仕様上公開されたままになることに注意してください。そのため、環境ファイルやアクセスキーなどの機密情報は、フォークされたリポジトリや公開リポジトリにコミットしないでください。 別の一般的なシナリオは、一度に複数のお客様アカウントでリソースを作成することです。多くのお客様が マルチアカウント戦略 を採用しており、これにはワークロードの分離、アカウントサービスクォータの枯渇からの保護、セキュリティ境界の範囲設定などの利点があります。一部のアーキテクチャでは、マイクロサービスごとに (開発、ステージング、プロダクション) の標準的なアカウントセットが必要とされ、数百または数千のアカウントを運用するお客様もあります。CloudFormation StackSets はこの問題を解決します。CloudFormation テンプレートに StackSets を記述し、デプロイ先のアカウントまたは組織単位を構成すると、CloudFormation サービスがターゲットのアカウントまたはリージョンごとに一貫してリソースをインストールする作業を行います。StackSetsは CloudFormation テンプレートで AWS::CloudFormation::StackSet リソースタイプを使用して定義できるため、同じ Git 同期ソリューションをこのシナリオで使用できます。 お客様のフォークされたリポジトリと、複数のアカウントにデプロイされる StackSets 上の図では、右側のアカウントは任意の数にスケールでき、それらのアカウント内で複数のリージョンにデプロイすることもできます。お客様が AWS Organizations を使用してそれらのアカウントを管理している場合、設定はより簡単になり、新しく追加されたアカウントにはスタックで定義されたリソースが自動的に展開されます。パートナーが元のソーステンプレートを変更すると、お客様は同じフェッチとマージのプロセスに従って自動 Git 同期デプロイを開始できます。このようなデプロイで Git 同期を使用する場合は、 TemplateBody パラメータを使用して子スタックのコンテンツを親テンプレートに埋め込む必要があることに注意してください。（訳者注: 通常、AWS::CloudFormation::Stack リソースの TemplateURL プロパティを使い S3 などに保存した子テンプレートを参照できますが、Git 同期を利用する場合は、CloudFormation が Git リポジトリのファイルをテンプレートとして直接取得することはできないため、 TemplateBody パラメータを使用して親テンプレートの中に子テンプレートの内容を埋め込む必要があります。） 結論 この投稿では、パートナーとお客様が協力してお客様のアカウント内にリソースをインストールおよび構成する便利で制御可能なアーキテクチャオプションを紹介しました。AWS CloudFormation Git 同期と CloudFormation StackSets を併用することで、Git をオペレーションコントロールの基盤として利用し、スケーラブルかつ一貫した方法で更新をロールアウトできます。 Eric Z. Beard Eric は AWS の CloudFormation チームのメンバーで、ソフトウェアエンジニア、ソリューションアーキテクト、デベロッパーアドボケイトとしての豊富な経験を持っています。DevOps や Infrastructure as Code、コンプライアンス、セキュリティーなどのトピックについて、AWS re:Invent などのイベントで頻繁に講演しています。お客様のクラウドアプリケーション設計をサポートしていない時は、テニスコートやジム、ヨガスタジオ、あるいはアメリカ西海岸の自然の中を散歩しています。 翻訳は Partner Sales Solutions Architect 福井 敦が担当しました。

コンタクトセンターの運営において、問題が発生する前に顧客と連絡を取ることで、潜在的な問題に対処したいという要求が高まっています。顧客のニーズを予測し、積極的にそれを満たすことで、企業は顧客の不満や離脱を防ぎ、顧客ロイヤルティを向上させ、最終的に収益を増加させることを目指しています。 しかし、そのような効果を発揮するためには、積極的なコミュニケーションがパーソナライズされ、魅力的で、すべてのタッチポイントで連携していなければなりません。現在、コンタクトセンターの管理者は、ターゲットとなる顧客、オーディエンスを決定するための材料として、データアナリストがオフラインクエリで取得する顧客属性や顧客の好みの情報に依存していることがよくあります。しかし、顧客データは通常、組織でサイロ化されていたり、アプリケーション、エンゲージメントチャネル全体に分散しています。そのため、積極的なコミュニケーションは断片的になったり、コストがかかったり、スケールが困難になる可能性があります。 Amazon Connect Customer Profiles は、70 を超える潜在的なデータソースからエンドカスタマーのデータを集約して統合し、カスタマージャーニー全体でカスタマイズされたエクスペリエンス向上のために使用できます。また Amazon Connect Outbound Campaign では、 Amazon Connect Customer Profiles 属性を使用して、リアルタイムセグメンテーションを作成し、メッセージをパーソナライズ できます。 つまり、 Amazon Connect により、企業は規模に応じたパーソナライズされたオムニチャネルキャンペーンを簡単に作成できるようになりました。例えば、あらゆる種類の企業に共通する以下のようなユースケースです。 顧客体験を向上させるために積極的に顧客に連絡するユースケース : 支払いのリマインド 今後の予約に関するヒント オンボーディングの手順 潜在的なサービス問題を防ぐために積極的に顧客に連絡するユースケース : 製品のリコール サービス停止の通知 ネガティブな体験をした可能性のある顧客への連絡: 遅延したフライトの再予約 返金の提案 顧客体験へのフィードバック依頼 コンバージョン促進のための顧客への連絡 : カゴ落ち 住宅ローン / クレジットカードに関する問い合わせ 有望なリードへの連絡 / 問い合わせ Amazon Connect Outbound Campaign は、ビジネスユーザーにとって使いやすいキャンペーンの設計と管理機能、オムニチャネルオーケストレーション (SMS、メール、音声 ) 、メッセージテンプレート管理、および Amazon Connect 管理コンソールからキャンペーンとコンバージョンメトリクスを表示する分析ダッシュボードを提供します。ターゲットとなる顧客セグメント、メッセージテンプレート、チャネル、スケジュールを定義することで、企業は音声、SMS、メールチャネルを通じてキャンペーンを迅速に作成し開始できます。この機能により、現在一般的な IT 部門に依存した複数のツール間でカスタム統合の構築や設定なく、コミュニケーションを統合できるようになります。 キャンペーンパフォーマンスメトリクスを分析するために、コンタクトセンターの管理者は Amazon Connect キャンペーン分析ダッシュボード を活用して、キャンペーンの配信状況、応答率、通話の結果（例：顧客が応答、留守番電話、話し中、目標達成 ) に関する洞察を得て、応答率とエージェント効率を向上させる機会を特定できます。以前は、お客様は複数のソースから API をつなぎ合わせてカスタムダッシュボードを構築しており、 IT リソースが必要でした。分析ダッシュボードにより、これらのメトリクスはすべて 1 つの場所で利用できます。 このブログ記事では、架空の企業 AnyCompany が計算属性を使用して独自のビジネスロジックを定義し、Amazon Connect Customer Profiles データを実用的なデータポイントに変換する方法を紹介します。これらのデータポイントは、注文履歴データに基づくインバウンドの応答メッセージや、リアルタイムでターゲットを絞った顧客セグメントを使用する アウトバウンドキャンペーン など、顧客体験をパーソナライズするために使用できます。 ソリューションの概要 : 実施するステップの概要は次の通りです。 Amazon Connect Customer Profiles の有効化 計算属性の作成 計算属性を使った Amazon Connect のフロー作成 セグメントの作成 セグメントへの連絡 キャンペーンの作成 前提条件 この手順を実行するためには、以下の項目の準備が必要です : AWS アカウント Amazon Connect インスタンス 手順 ステップ 1: 計算属性の作成 AWS マネジメントコンソール にサインインします 検索欄で、Key Management Service を検索し、 Key Management Service をクリックします 図 1: Key Management Service の検索 キーの作成 をクリックし、カスタマー管理型のキーを作成します キーを設定 セクションでは、デフォルトのまま 次へ をクリックします。 ラベルを追加 セクションでは、エイリアスとして、 Customerprofilekey を設定し、 次へ をクリックします。キー管理、使用のアクセス許可はスキップし、 確認 ステップに移ります。最後に、 完了 をクリックし、KMS キーを作成します 図 2: キーの設定の確認 サービス検索欄で Amazon Connect と入力し、 Amazon Connect をクリックします 図 3: Amazon Connect の検索 Amazon Connect インスタンスのページで、左側のナビゲーションメニューから、 お客様のプロフィール をクリックします Customer Profiles を有効化 ボタンをクリックし、ドメイン名に amazon-connect-customerprofile と入力、プロファイルの作成と自動関連付けで、 プロファイルの自動関連付けのみ を選択、暗号化のセクションで、 Customerprofilekey を選択し、最後に Customer Profiles を有効化 をクリックします 図 4: Customer Profiles の有効化 図 5: 暗号化キーの選択 サービス検索欄で、S3 と入力し、 S3 をクリックします。 バケットを作成 をクリックし、任意のバケット名を設定し、その他はデフォルトのままとし、 バケットを作成 をクリックしてバケットを作成します 以下の CSV ファイルをローカルにダウンロードします 10_Customer_Profiles.csv 10_Orders.csv ダウンロードした 10_Customer_Profiles.csv をローカルコンピューターのエクセルなどで開き、最初の行の PhoneNumber の値を自分の携帯電話の番号等に変更します。国コードを表す数字を含めてください。それ以外の行はそのままにして、ファイルを保存します 10_Customer_Profiles.csv と 10_Orders.csv をステップ 8 で作成した S3 バケットにアップロードします Amazon Connect インスタンスの お客様のプロフィール 画面に戻ります データソースの統合タブで、 データソース統合を追加 をクリックします 図 6: データソース統合を追加 データソースで、 S3 を選択します。バケットの詳細で、 S3 を参照 をクリックし、 Step 8 で作成したバケットを選択、 10_Customer_profiles.csv のファイルを選んで、 選択 を押します。 取り込み開始日 はそのままにし、 次へ をクリックします 図 7: データソースで S3 を選択 マッピング方法の項目で、 マッピングを自動生成 を選択し、マッピングの詳細（マッピング名や説明）はそのままで、 次へ をクリックします 図 8: マッピング方法の選択 マッピングを確認してカスタマイズ セクションで、生成 AI により、CSV ファイルのフィールドをもとにしたマッピングが表示されます 図 9: マッピングを確認してカスタマイズ 次へをクリックし、 データソース統合を追加 をクリックします。最初は、統合のステータスは、 保留中 になります。データが Customer Profiles のドメインに追加されると、ステータスは アクティブ に変わります。このプロセス全体には 5-10 分程度の時間がかかります 統合のステータスが アクティブ になったら、ページを更新し、 プロファイルメトリクス の プロファイルの合計数 が 10 になっていることを確認します 図 10: プロファイルメトリクス データソースの統合タブから、 データソース統合を追加 をクリックします 図 11: データソース統合 データソースで、 S3 を選択します。バケットの詳細で、 S3 を参照 をクリックし、 Step 8 で作成したバケットを選択、 10_Orders.csv のファイルを選んで、 選択 を押します。 取り込み開始日 はそのままにし、 次へ をクリックします 図 12: 接続の設定 マッピング方法の項目で、 マッピングを自動生成 を選択し、マッピングの詳細（マッピング名や説明）はそのままで、 次へ をクリックします 図 13: データのマッピング マッピングを確認してカスタマイズ セクションで、生成 AI により、CSV ファイルのフィールドをもとにしたマッピングが表示されます 図 14: マッピングの確認とカスタマイズ AccountNumber の行のアクション列の縦の３つの点をクリックし、プロパティを追加、プロファイルキーと選択します。ポップアップが表示されるので、 キー名 に AccountNumber と入力、 保存 をクリックします 図 15: プロパティを追加からプロファイルキーを選択 次へ をクリックし、 データソース統合を追加 をクリックします。最初は、統合のステータスは、 保留中 になります。データが Customer Profiles のドメインに追加されると、ステータスは アクティブ に変わります。このプロセス全体に 5-10 分程度の時間がかかります Amazon Connect インスタンスのページで、 アクセス URL をクリックし、インスタンスにログインします Amazon Connect コンソールで左側のメニューから、ルーティングの中の キュー をクリックします 図 16: キューを選択 キューを追加 をクリック 名前フィールドに Priority Queue と入力し、オペレーション時間欄では、 Basic Hours を選択、保存をクリックします 27-28 を繰り返し、同様に Standard Queue を作成します Amazon Connect コンソールの左メニューから、お客様のプロファイルの 計算属性 をクリックします 図 17: 計算属性を選択 属性から _orders_total_price_sum を探して選択します 編集ボタンをクリックし、時間範囲の開始を 100 に設定します。ユースケースに合わせて更新してかまいません 保存 をクリックします 図 18: order total price の属性の編集 属性から _orders_count を探してクリックします 編集ボタンをクリックし、時間範囲の開始を 100 に設定します。ユースケースに合わせて更新してかまいません 保存 をクリックします 図 19: orders count 属性の編集 ステップ 2: 計算属性を使った Amazon Connect フローの作成 カスタム計算属性機能をテストするために、Amazon Connect フローを作成します。以下に概説するシナリオでは、ステップ 1 で作成されたカスタム計算属性を活用して、情報に基づいたビジネス判断を促進するフローを設計します。このフローは、顧客の注文履歴の詳細な分析に基づいて、着信した顧客のコールを異なるキューに動的にルーティングします。 顧客が 5 件を超える注文を行い、これらの注文の合計金額が 1000 USD を超える場合、システムはこの顧客を優良顧客として認識します。このような場合、フローは通話をプレミアムサポートとハンドリングの提供を目的とした、 Priority Queue に誘導します 逆に、お客様が上記の条件を満たさない場合、つまり注文数が 5 回未満または注文総額が 1000 USD 未満のいずれかの場合、通話は Standard Queue にルーティングされます。このキューは一般的なお問い合わせを処理し、標準的なカスタマーサービスを提供するよう設定されています このルーティング戦略を実装することで、優良顧客が優先的な対応を受けられるようにし、顧客の全体的なサービス体験を向上させます。このアプローチは、主要なデータポイントを活用してコールルーティングに関するリアルタイムの決定を行うことで、よりパーソナライズされた効果的なカスタマーサービスを可能にします。 図 20: 計算属性を使ったフロー 上記のフローを こちら からダウンロードできます。 ステップ 3: セグメントの作成 セグメントをキャンペーンやフローで使用することで、エンゲージメントする特定の顧客グループを特定し、パーソナライズされた体験を作成できます。セグメントは Customer Profiles からの顧客データを使用して、一致する顧客を見つけます。外部ソースからデータを取り込むには、組織の管理者にお問い合わせください。セグメントは、顧客データの変更に応じて顧客を追加または削除するよう動的に更新されます。計算属性を含む顧客属性は、セグメント条件を構築するためのフィルターとして使用されます。フィルターとして使用する前に、まず計算属性を作成する必要があります。 Amazon Connect コンソールで、左側のメニューで、お客様のプロファイルの下にある 顧客セグメント オプションをクリックしてください 図 21: 顧客セグメントを選択 セグメントを作成 ボタンを押して新たなセグメントを作成します 名前フィールドに Priority Customers と入力します オーディエンスグループ 1 のセクションで、 Customer Profiles のすべてのプロファイル が選択された状態にします オーディエンスフィルターの欄で、 + フィルター をクリックし、属性で Count of orders を検索、選択します。演算子に 次より大きい を選択し、値に5を入力します 推定オーディエンス 欄にどれだけのプロファイルがこの条件に一致するか表示されます セグメントを作成 ボタンをクリックします 図 22: セグメントの作成 ステップ 4: 作成したセグメントへの連絡 音声を通じて顧客にアプローチする際に使用できるフローを作成します。以下のサンプルフローには Call Progress Detection が含まれており、通話状態（応答、留守番電話、話中等）を検知し、その場合は通話をエージェントにルーティングします。ボイスメールが検知された場合、フローは顧客にメッセージを残します。 図 23: 通話進捗検知を含むアウトバウンドフロー 上記のフローは こちら からダウンロードできます。 ステップ 5: キャンペーンの作成 訳注: 翻訳時点で Amazon Connect の Outbound Campaign による発信を行うためには上限値の緩和が必要です。Outbound Campaign に関するクォータは ドキュメント を確認してください。 また、Outbound Campaign による発信先と発信元のリージョンの制限については、 こちら を確認してください。 左側のメニューから、 アウトバウンドキャンペーン を選択します 図 24: アウトバウンドキャンペーンを選択 キャンペーンを作成 をクリックします 図 25: キャンペーンを作成 キャンペーン名に Priority Customer Campaign と入力します 顧客セグメントとして、ステップ 3 で作成したセグメント Priority Customers を選択します 図 26: キャンペーン名とセグメントの設定 コミュニケーションから、 エージェント支援音声 を選択します。なお、このチャンネルでは予測的、進歩的のダイヤルモードが選択できます。進歩的モードを使用する場合、エージェントが利用可能な時にのみ顧客への通話が行われます。予測的モードでは、エージェントの稼働率が優先されます コンタクトフロー の欄で、ステップ 4 で作成したフロー Outbound With Call Progress Detection を選択します キュー欄で、通話に応答するエージェントのキューを選択します 発信元の電話番号 で、顧客が電話を受ける際に通知される番号を選択します ダイヤルモード で 進歩的 を選択します 通話分類を有効にする にチェックを入れます プロンプト待ちを有効にする にチェックを入れます 図 27: 配信モード、コンタクトフロー、キュー、発信元の電話番号、ダイヤルモードを選択した画面 次へ をクリックします コミュニケーション数の制限を設定します。この項目により、顧客が合計何回このキャンペーンの連絡を受けるか制限できます。また、全体の合計の制限がデフォルトでは適用されます キャンペーンの制限を設定 を選択し、 制限 を 3 、 頻度 を 5 に設定します。これは、顧客が 5 日ごとに 合計 3 回まで連絡を受けることを意味します 制限をさらに追加し、制限を 6 、頻度を 14 に設定します。これにより、顧客が 2 週間( 14 日)ごとに合計 6 回まで連絡を受けることになります 再試行ルール を有効にし、画像のように任意のルールを追加します。これにより、同じチャネルを使用して連絡を再試行したり、SMS や email を使用したりできます。例えば、番号が無効な場合は、代わりに顧客に email を送信できます 図 28: 再試行ルールの追加 再試行ルールを指定します。この例では、通話が切断された場合、回線が混雑している場合、またはボイスメールに到達した場合に、顧客に再度電話をかけます。電話番号が無効な場合は、メールが送信されます。通話に応答がない場合は、SMS が送信されます。 訳注:SMS やメールを設定するには、SMS テンプレートやメールアドレスの設定が別途必要です 次へ をクリックします このセクションでは、キャンペーンを実行する時間帯を指定します。除外すべき日がある場合も設定できます。そして、キャンペーンに特定のタイムゾーンを使用するか、顧客のタイムゾーンを利用するかを指定します。 受信者のローカルタイムゾーン を選択してください 図 29: 受信者のタイムゾーンを追加 アクティブなコミュニケーション時間 の下で、 + 日数 ボタンをクリックし、キャンペーンを実行する時間帯を指定してください。複製のアイコンをクリックすることで、他の日を素早く追加できます 図 30: コミュニケーション時間の追加 コミュニケーション時間の例外 の + 例外 ボタンをクリックし、キャンペーンを行いたくない日があれば設定します 次へ をクリックします 図 31: キャンペーンの確認と公開 設定したキャンペーンを確認します 公開 をクリックします 今すぐ開始 を選択します 図 32: キャンペーンを今すぐ開始するか、開始時間を予約するか選択する画面 有効期限・時刻 を設定します 公開 をクリックします 優先顧客に音声通話を行い、応答された通話をエージェントにルーティングするキャンペーンが作成されました。通話が放棄されたり、話し中や留守番電話に到達した場合、15 分後に再試行されます。通話が未応答の場合、SMS が送信されます。電話番号が無効な場合、メールが送信されます。 クリーンアップ Amazon Connect コンソールで、左側のメニューからお客様のプロファイルの下にある 顧客セグメント をクリックしてください Priority Customers セグメントを選択し、 削除 をクリックします。ポップアップウィンドウで 確認 と入力し、 削除 をクリックします ステップ 2 で作成した Amazon_Connect_Contact_Flow を削除します 次のキューを削除します: Priority Queue および Standard Queue キャンペーン Priority Customer Campaign を削除します フロー Outbound with Call Progress Detection を削除します 10_Customer_profiles と 10_Orders 用に作成されたデータソース統合を削除します Customer Profiles ドメイン を削除します KMS キー を削除します S3 バケットを削除します まとめ このブログでは、AnyCompany 社が Amazon Connect Customer Profiles を効果的に活用して、個々の顧客の注文履歴などの生の顧客データを実用的なデータポイントに変換する方法を紹介しました。これにより、AnyCompany 社は受信キューから始まる顧客向けの自動化されたエクスペリエンスをパーソナライズすることができました。さらに、Amazon Connect Customer Profiles で作成されたセグメントを活用して、高度にターゲット化された Amazon Connect のアウトバウンドキャンペーン を構築し、異なる顧客グループの特定のニーズや好みに合わせたメッセージングを可能にしました。その結果、AnyCompany 社 の顧客は有意義にエンゲージメントされ、全体的なエクスペリエンスが向上しました。 統合された顧客データと、カスタムロジックおよびオーディエンスセグメンテーションの統合により、企業は様々なタッチポイントでパーソナライズされたインタラクションを提供できるようになります。競争の激しい市場において、Amazon Connect は顧客理解を深めるだけでなく、より適切なタイミングで状況に応じた顧客対応(顧客エンゲージメント)を実現します。Amazon Connect Customer Profiles についてさらに詳しく学ぶには、「 How to build unified customer profiles with Amazon Connect 」を読むか、「 How Choice Hotels has used Customer Profiles to build unified traveler profiles 」をご覧ください。Amazon Connect Outbound Campaigns についてさらに詳しく学ぶには、 こちら をご覧ください。 筆者紹介 Nimish Amlathe は、ワシントン州シアトルを拠点とする Amazon Web Services のプロダクトリードです。AWS では、Amazon Connect、AWS Clean Rooms、AWS Entity Resolution、Amazon Personalize など、顧客データ、機械学習、顧客エンゲージメントに関わるチームと協力しています。仕事以外では、地元のコメディクラブで彼を見かけることが多いでしょう。 Abhishek Pandey は、テキサス州ヒューストンを拠点とする Amazon Web Services のシニアソリューションアーキテクトです。Abhishek は、さまざまな業界でビジネスイノベーションをサポートする創造的なソリューションの設計に情熱を注いでいます。仕事以外では、家族や友人と過ごすことを愛しています。 Asher Bramwell は、ワシントン州シアトルを拠点とする Amazon Web Services のシニアスペシャリストソリューションアーキテクトです。 Baswaraj Thota は、Amazon Web Services のシニアソリューションアーキテクトです。Baswaraj は、多くの異なる業界、組織で洗練された、スケーラブルで安全なソリューションの実装を支援してきました。仕事以外では、クリケットをプレイしたり、ジョギングしたり、旅行することを愛しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本記事は、2025 年 4 月 30 日に Networking & Content Delivery で公開された Visualizing network performance of your AWS Cloud workloads with Network Flow Monitor を翻訳したものです。 AWS は 2024 年 12 月 1 日の re:Invent にて、Network Flow Monitor の提供を発表しました。これは AWS マネージドサービス全体のネットワークパフォーマンスをモニターする Amazon CloudWatch Network Monitoring の新機能です。Network Flow Monitor を使用すると、コンピュートリソース ( Amazon Elastic Compute Cloud(Amazon EC2) や Amazon Elastic Kubernetes Service(Amazon EKS) ) と Amazon S3 や Amazon DynamoDB などの AWS サービス間、および AWS インフラストラクチャ間とのネットワークトラフィックをほぼリアルタイムで可視化できます。収集されたデータはクラウド環境のトラブルシューティング時間を短縮し、アプリケーションのネットワーク問題をより迅速に特定と解決することに役立ちます。 クラウドネットワークにおけるオブザーバビリティの課題 アプリケーションのレイテンシーが大きい場合、クラウド環境でもオンプレミス環境でも、ネットワーク障害が最初に疑われることがよくあります。既に多くの方がご存知かもしれませんが、従来のネットワークモニタリングツールでは、 AWS ネットワークインフラストラクチャと AWS マネージドサービス間のネットワークパフォーマンスの可視性能に限り、提供されます。そのためトラブルシューティングの時間が長くなり、平均検出時間 (MTTD) と平均復旧時間 (MTTR) の両方に悪影響を及ぼす可能性があります。 CloudWatch パフォーマンスモニタリング機能 Network Flow Monitor を使用すると、次の図に示すように CloudWatch はネットワークモニタリングと アプリケーションパフォーマンスモニタリング (APM) の両方に、広範囲なオブザーバビリティサービスを提供できるようになります。 図 1. CloudWatch アプリケーションパフォーマンスモニタリングとネットワークモニタリング機能 Network Flow Monitor は、軽量なエージェントをリソースにインストールすることで、実際のワークロードトラフィックからパフォーマンスメトリクスを直接収集し、ほぼリアルタイムのモニタリングを行います。Network Flow Monitor は、データ転送、再送信、再送信タイムアウト、ラウンドトリップ時間などの重要なネットワークメトリクスを記録します。 さらに、フローモニターの優れた特徴として、ネットワークヘルスインジケーター (NHI) があります。 NHI は、ネットワークの低下が AWS インフラストラクチャに起因した問題かどうかを判断することができます。 ネットワークのレイテンシーが発生した場合、インジケーターが原因特定に役立つため、トラブルシューティングをより効率的に行うことができます。 CloudWatch ネットワークモニタリングは、他にもネットワークパフォーマンス機能を提供しています。詳細については、 Internet Monitor の使用 または Network Synthetic Monitor の使用 のユーザーガイドをご参照ください。 次のセクションでは、Network Flow Monitor を使用したネットワークパフォーマンスを可視化する方法について、具体的なシナリオを交えて解説します。 モニタリングシナリオの例 このセクションでは AWS Transit Gateway に接続し、同じリージョン内の異なる VPC に配置している 2 つの EC2 インスタンスの構成例を見ていきます。 現在 ( ※ 2025 年 7 月 18 日時点 )、Network Flow Monitor はクロスリージョンをサポートしておりません。 この例ではネットワークパフォーマンスデータを提供するために、VPC 1 の EC2 インスタンス test-instance-1 にエージェントをインストールしました。さらに、VPC 2 の EC2 インスタンス test-instance-2 に Apache Web サーバーを構築し、次の図に示すように httpd サービスを有効にしました。次のセクションでは、エージェントのインストール方法について詳しく解説します。 図 2. Network Flow Monitor の VPC 間ネットワークモニタリング設定例 アクティブモニタリングソリューションとは異なり、Network Flow Monitor はワークロード間の実際のユーザートラフィックを分析する継続的なパッシブ・モニタリングを提供します。次の図に示すように、エージェントをインストールした test-instance-1 から、Apache Webサーバーの test-instance-2 へのテストトラフィックを送信しました。 図 3. VPC 1 のインスタンスと VPC 2 の Web サーバー間の HTTP トラフィックフローのデータをエージェントが収集 エージェントは、TCP コネクションのペイロードにアクセスできません。エージェントは Linux カーネルから bpf_sock_ops 構造体のみを受け取ります。この構造体は、ローカルとリモートの IP アドレス、ローカルとリモートの TCP ポート、さらにカウンターとラウンドトリップタイムを提供します。 Network Flow Monitor のセットアップ このセクションでは、シナリオ例に沿って、Network Flow Monitor のセットアップ手順を説明します。 ネットワークフローのパフォーマンスメトリクスを表示するために Network Flow Monitor を次のように設定します： Network Flow Monitor を有効化 Network Flow Monitor エージェントをインストール ワークロードインサイトでネットワークフローの確認 1 つ以上のフローモニターを作成 ステップ 1：Network Flow Monitor を有効にする Network Flow Monitor を使用する前に、CloudWatch へのデータ送信とネットワーク接続をマッピングするために必要な権限を有効にします。コンソールで初めて Network Flow Monitor にアクセスすると、次の図で示すように、本機能を有効にするように求められます。 図 4. Network Flow Monitor の有効化 Network Flow Monitor を有効にすると権限が設定され、モニタリングスコープが作成されます。現在 ( ※ 2025 年 7 月 18 日 時点)、モニタリングスコープはサインインしている AWS アカウントが対象です。詳細については、 Network Flow Monitor を有効にする を参照してください。機能の有効化は、リージョン内で初めて使用した時のみ必要となります。 Network Flow Monitor がアカウントに必要なサービスリンクロールの使用許可を付与し、AWS アカウントのモニタリング範囲を設定するまで、しばらく待ちます。 (最大30分) ステップ 2：Network Flow Monitor エージェントのインストール インスタンスにエージェントをインストールする際、エージェントが Network Flow Monitor のバックエンドにデータを送信できるように、アクセス権限を設定する必要があります。このデータによって、ネットワークパフォーマンスのモニターができるようになります。インスタンスで使用できる Linux バージョンには特定の要件があり、 Amazon CloudWatch のユーザーガイド に記載されています。 エージェントは EC2 インスタンス、セルフマネージド Kubernetes インスタンス、または Amazon EKS にインストールできます。本記事では、AWS ユーザーガイドの EC2 インスタンスのエージェントをインストールして管理する に記載されている手順に従います。Kubernetes や Amazon EKS でのエージェントのインストールについては、 インスタンスに Network Flow Monitor エージェントをインストールする を参照してください。 正しいアクセス権限を設定するには、次の図に示すようにエージェントを実行している EC2 インスタンスに、 CloudWatchNetworkFlowMonitorAgentPublishPolicy ポリシーがアタッチされたロールを使用する必要があります。 図 5. ターゲットインスタンスのロールに Network Flow Monitor ポリシーをアタッチ EC2 インスタンスにエージェントをインストールする前に、アクセス権限を追加することを推奨します。インスタンスにロールがない場合は新しいロールを作成し、前述のポリシーをアタッチしてください。 次に、インスタンスにエージェントをインストールします。エージェントのインストールには、 AWS Systems Manager の機能である AWS Systems Manager Agent を使用します。エージェントのインストールを開始する前に、各インスタンスで Systems Manager Agent が実行されていることを確認してください。詳細については、 「SSM Agent」の使用 を参照してください。 EC2 インスタンスにエージェントをインストールするには、以下の手順を実行します： コンソールで、AWS Systems Manager コンソールを開きます。 Node Tools の下で、 Distributor を選択します。 Owned by Amazon セクションで、Network Flow Monitor ソフトウェアパッケージ AmazonCloudWatchNetworkFlowMonitorAgent を検索します。 パッケージを選択し、次の図に示すように Install one time または Install on a schedule を選択します。 図 6. Systems Manager で、ネットワークフローモニターエージェントパッケージを選択 エージェントをインストールする EC2 インスタンスを選択します。この例では、次の図に示すように、 test-instance-1 のみを選択します。ただし、複数のインスタンスにエージェントをインストールする場合は、タグやリソースグループに基づいてインスタンスを選択する方法が効率的です。 図 7. Systems Manager で、エージェントをインストールするインスタンスを選択 最後に、 Run を選択してエージェントのインストールを開始します。 インストールが正常に完了すると、次の図に示すようなコマンドステータスメッセージが表示されます。 図 8. ターゲットインスタンスへのエージェントインストールの成功 ステップ 3：Workload insights でネットワークフローを確認 Network Flow Monitor を有効にしてエージェントをインストールすると、パフォーマンスデータを確認できます。ワークロードの傾向やトラフィックパターンを把握するために、まずコンソールの可視化から始めることをお勧めします。 CloudWatch コンソールで、 Network Monitoring の下にある Flow monitors を選択します。次に、 Workload insights タブで、Top contributors のネットワークフローを確認し、より詳細にモニタリングしたいフローを特定することができます。この情報は次の図に示しており、詳細については、 ワークロードインサイトを使用してネットワークフローを評価する を参照してください。 図 9. CloudWatch のネットワークフローデータ 特定のネットワークフローを詳しく分析するには、次の2つの方法でモニターを作成できます。 Top contributors でネットワークフローを選択し、 Create monitor を選択します。またはステップ 4 記載手順の Create monitor を選択し、ネットワークフローをモニターするローカルリソースとリモートリソースを個別に指定することもできます。 ステップ 4：フローモニターの作成 モニターの作成を開始するには、次の図に示すように、Network Flow Monitor コンソールで Create monitor を選択します。 図 10. Network Flow Monitor でモニターを作成 モニターを作成する際は、設定の一時保存ができないため、すべての手順を一度に完了することをお勧めします。 モニター作成フローの手順に沿って進めてください。この例では、モニターに以下の情報を提供します。 Monitor name には、次の図に示すように monitor-ap-northeast-1c-1a と入力します。 図 11. フローモニターの名前を指定 Local resources では、監視するネットワークフローのタイプを指定し、それぞれに具体的なオプションを選択します。Network Flow Monitor がサポートするローカルリソースの種類は、サブネット、VPC、またはアベイラビリティーゾーンです。この例では、次の図に示すように、インスタンスが存在するサブネット flowmonitor-subnet-ap-northeast-1c を選択します。 図 12. フローモニターに 1 つ以上のローカルリソースを選択 Remote resources については、 Everywhere または  Select remote resources を選択します。 Everywhere を選択すると、選択したローカルリソースから送信するすべてのネットワークフローがモニターに含まれます。それ以外の場合は、モニターする特定のリモートリソースを選択できます。このオプションでは、サブネット、VPC、アベイラビリティーゾーン (AZ)、または Amazon S3 や DynamoDB などの AWS サービスの中から、1 つ以上のリソースを選択できます。 この例では次の図に示すように、Web サーバーをホストするリモートリソースとして1つのサブネット flowmonitor-subnet-ap-northeast-1a を指定します。ローカルリソースとリモートリソースをそれぞれ 1 つずつ選択すると、モニターは 2 つのリソース間のネットワークフロー情報をモニターできるようになります。 図 13. フローモニターのリモートリソースを選択 Next を選択し、モニターの設定を確認します。 Create monitor を選択します。 モニターを作成した後、Network Flow Monitor がデータの収集と集計を開始するまで最大 30 分待ちます Network Flow Monitor メトリクスの可視化 モニターを作成すると、Network Flow Monitor はエンドツーエンドのパフォーマンスメトリクスと、ネットワーク低下の問題に関するネットワークヘルスインジケーターの表示を開始します。モニターの情報は Network Flow Monitor コンソールで可視化できます。また、AWS/NetworkFlowMonitor というカスタム名前空間の CloudWatch メトリクスでも確認できます。 この例では、Network Flow Monitor コンソールで、 Monitors のパフォーマンスデータを確認します。モニタータブで、次の図に示すように monitor-ap-northeast-1c-1a というモニターを選択します。 図 14. フローモニターでパフォーマンスデータを表示 モニターのネットワークフローの全体概要を把握するには、次の図に示すように Overview タブを確認します。 図 15. モニターの概要タブでパフォーマンスメトリクスを可視化 次に、 Historical explorer タブに移動して、モニター対象のネットワークフローのより詳細なメトリクスを確認します。例えば、パフォーマンスが低下した場合、トポロジー機能はネットワークパス内のすべてのコンポーネントを、サービスアイコンとリソース ID とともに表示します。次の図に示すように、この可視化は指定時間の中で、各パフォーマンスメトリクスと特定フローの情報を調査し、問題解決に役立てることができます。 図 16. 低下問題のネットワークフロートポロジーの可視化 リソースのクリーンアップ Network Flow Monitor の評価を終えた後は、速やかにすべてのテストモニターと暫定リソースを削除してください。 効率的なリソース管理を行うことで、不必要な支出を避けることができます。 まとめ 本記事では、Amazon CloudWatch ネットワークモニタリングの新しいオブザーバビリティ機能である Network Flow Monitor を紹介しました。本機能により、コンピューティングインスタンスと AWS サービス間のワークロードのネットワークパフォーマンスをほぼリアルタイムで可視化できます。また、フローモニターが提供する様々なメトリクスと情報を使用することで、クラウドワークロードのネットワークパフォーマンス低下を迅速に分析対処し、トラブルシューティングの時間を最小限に抑えることができます。 Network Flow Monitor の詳細はこちら Network Flow Monitor の利点について概要を説明しました。 詳細は以下の追加情報をご確認ください： 料金の詳細については、 CloudWatch の料金表ページ をご覧ください。 フローモニターは現在 ( ※ 2025 年 7 月 18 日 時点) 17 の AWS リージョンで利用可能です。利用可能な一覧については、 ユーザーガイド を参照してください。 Network Flow Monitor の詳細と技術的なガイダンスについては、 ユーザーガイド を参照してください。 翻訳はテクニカルアカウントマネージャーの安藤 彰が担当しました。

2025 年 7 月 17 日に 「商用データベースを AWS で活用する」 と題したセミナーを開催しました。現在商用データベース ( Oracle, SQL Server, IBM Db2 )を利用中だが、まだ AWS を触ったことがない、もしくは移行を検討しているという方向けのセミナーで、最初に AWS を利用するメリットといった基本をご説明し、その後は 3 種類の商用データベースを AWS 上で稼働させる際のサービス選択のポイントや注意点について説明するという内容でした。ご参加いただきました皆様には、改めて御礼申し上げます。 タイミングが合わず参加できなかった方向けに、このセミナーの内容をオンデマンド（録画）での配信を本日より開始いたしました。本ブログでセッションの内容を簡単に紹介しますので、これを参考に視聴いただければと思います。また、 視聴後アンケート（リンク先の概要に記載）に回答いただけますと資料のダウンロードが可能 になりますので、ぜひアンケートにも回答いただけますと幸いです。 オンデマンド視聴は こちらのURL より可能 です。 セッション紹介 AWS の DB 関連基本サービスの説明と、活用パターン アマゾン ウェブ サービス ジャパン合同会社　Yukki (髙橋 敏行) 本セッションでは、AWS 上で商用データベースを稼働させる検討をする上で必要になる AWS クラウドの基本概念と特徴をご説明しました。 AWS グローバルインフラストラクチャーを活かした設計や、マネージドサービスを使うことによる運用負荷の低減、およびセキュリティなどをご説明した後に、 AWS のデータベースサービス概要やデータベース移行と運用を支えるサービスも合わせてご説明しています。 Oracle Database on AWS アマゾン ウェブ サービス ジャパン合同会社　矢木 覚 Oracle データベースを AWS 上で稼働させる選択肢としては、RDS for Oracle に加え、先日米国で一般提供が開始になりました Oracle Database @ AWS があります。本セッションではこの2つのサービスについて概要説明に加え、 Oracle ライセンスの AWS 上での取り扱いや可用性の考え方について説明しています。 SQL Server on AWS アマゾン ウェブ サービス ジャパン合同会社　沢田 吉伯 AWS はクラウドの中で最も多くの Microsoft Windows が稼働する環境です。このセッションでは、マイクロソフトテクノロジーを AWS 上で活用するための基本知識に加え、SQL Server を AWS 上で稼働させる際の選択肢や、 AlwaysOn の利用方法、ライセンスの考え方をご説明しています。 IBM Db2 on AWS アマゾン ウェブ サービス ジャパン合同会社　山根 英彦 IBM ミドルウェアの多くは、 AWS 上で稼働させることが許可されています。本セッションでは IBM ライセンスの基本的な考え方に加えて、Amazon RDS for Db2 の機能概要、および既存 IBM Db2 からのデータ移行ツールや事例について説明しています。 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

金融業界の若手エンジニアの皆さん、こんにちは！ 「AWS JumpStart に参加したいけれど、ついていけるか不安…」 「同じ業界の仲間と一緒に学習したい」 「金融特有の規制要件も含めて理解したい」 そんなお悩みを解決するのが AWS JumpStart Zero For FSI です。 AWS JumpStart Zero For FSI は、金融業界の若手エンジニアの皆様を対象とした、AWS JumpStart 本編への準備イベントです。同じ業界の仲間と一緒に学習することで、より効率的で楽しい準備ができることを目指しています。AWS JumpStartって何？という方は こちらの記事 をご覧ください。 AWS JumpStart Zero For FSI とは イベント概要 AWS JumpStart Zero For FSI は、8月27日、28日 に開催される AWS JumpStart に参加予定の金融業界の若手エンジニアを対象としています。本イベントに参加することで、AWS JumpStart の予習や共に学習する仲間作りができます。 開催詳細： 開催日時： 8月22日（金）14:00-20:00 構成： 14:00-18:00（座学/グループワーク）、18:00-20:00（懇親会） 場所： 〒141-0021 東京都品川区上大崎3丁目1-1 目黒セントラルスクエア 17F AWS Startup Loft Tokyo 対象： 金融業界の若手エンジニア（1-5年目）で AWS JumpStart を受講予定の方 主な目的 AWS JumpStart を全力で楽しめる基礎知識の獲得 AWS JumpStart 本編で必要となる基礎知識を、同じ業界の仲間と一緒に楽しく学習します。 金融業界特有の課題と解決方法の理解 実際の金融機関におけるクラウド活用事例を通じて、業界特有の課題や解決方法を学びます。 同じ業界のエンジニアとの仲間作り 金融業界の若手エンジニア同士のネットワーキングを通じて、継続的な学びとキャリア成長のチャンスを得ます。 プログラム内容 ① クラウド基礎概念の理解 クラウドコンピューティングの基本概念について、オンプレミスとの違いやビジネスメリットを中心に解説します。特に金融業界でのクラウド活用トレンドを理解することができます。 セッション内では簡単なグループワークを実施し、自己紹介とともにクラウドへの期待や不安を共有することで、他の参加者と人脈を広げながら、クラウドについての理解を深める機会を得られます。 ②アーキテクチャホワイトボーディング AWS JumpStart 本編で実際に行うホワイトボーディングを体験していただきます。グループワークを通じて、アーキテクチャ設計の基本的な考え方を学び、本編への準備を行います。同じ業界の仲間と一緒に取り組むことで、より理解が深まることを期待しています。 ③ 金融業界でのクラウド活用実践 実際の金融機関におけるクラウド移行事例を紹介し、規制・コンプライアンス要件への具体的な対応方法を解説します。単なる事例紹介にとどまらず、参加者同士のディスカッションを通じて各社の課題や取り組みを共有し、実践的な知見の交換ができます。また、金融xクラウドで実際に働くAWS社員の声もお聞きいただき、金融業界でのキャリア形成のヒントを得て頂けます。 ④ 懇親会・ネットワーキング 他の参加者や AWS 若手メンバーと交流できる機会を通じて、クラウド業界での人脈を広げることができます。質問しやすい関係性が生まれ、今後の JumpStart 本編でより実践的な知識を深めることができます。さらに、この繋がりを活かして長期的なコミュニティ活動に参加することで、継続的な学びとキャリア成長のチャンスを得ることができます。 申し込み方法 こちらのページからお申し込みください。 お申し込みはお早めに！ まとめ 金融業界におけるクラウドネイティブ人材の育成は、デジタル変革を推進する上で重要な要素となっています。AWS JumpStart Zero For FSI では、同じ業界の仲間と一緒に学習することで、充実した準備ができる環境を提供します。 運営メンバー一同、金融業界の皆様により良い学習体験をお届けするべく準備を進めておりますので、ぜひとも参加をご検討ください。 よくある質問 Q: AWS の知識が全くないのですが、参加できますか？ A: はい、初心者の方を対象としたイベントです。安心してご参加ください。 Q: 他社の方との交流に不安があります A: 同じ業界の若手エンジニア同士、お互いに学び合う雰囲気を大切にしています！グループワークではアイスブレイクなども行いますので、ぜひ安心してご参加ください！ Q: AWS JumpStart とは別のイベントですか？ A: はい。AWS JumpStart とは別のイベントです。AWS JumpStartにご参加いただくための予習イベントとしてご用意しています。 Q: AWS JumpStart Zero For FSI に参加しなくても AWS JumpStart に参加できますか？ A: もちろん可能です。難易度や業界が異なる場合、AWS JumpStart のみにお申し込みください。 Q: 上の質問とは逆に、AWS JumpStart に参加しなくても、AWS JumpStart Zero For FSI に参加できますか？ A: はい。内容はAWS JumpStart にご参加を前提にしていますが、単体でのご参加も可能です。 Q: AWS JumpStart 自体への申し込みはどうすればいいですか？ A: こちらの記事 からご参加ください。 Q: AWS JumpStart をすでに申し込んでいます。どうすればいいでしょうか？ A: AWS JumpStart Zero For FSI は AWS JumpStart を補完する予習イベントです。ぜひこちらのイベントもご参加ください。 Q: 入社6年目でも参加できますか？ A: 本イベントは入社1～5年目の方を主な対象としておりますが、AWS初学者で、フレッシュな気持ちを持つ方であれば参加可能です。 Q: オンラインで参加は可能ですか？ A: 本イベントは現地開催のみです（※Jump Start本編はオンラインです。） Q: 参加費はいくらですか？ A: 参加費はかかりません。 関連リンク AWS JumpStart 2025 本編の詳細 運営チーム / ブログ著者 菅原 太樹 (Taiki Sugawara) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト 2024年に新卒で入社した 2 年目 SA。主に保険業界のお客様を担当しています。 好きなサービスは AWS Step Functions。自分の役職名を Step Functions Evangelist にしようとしたら却下されました。 X: @taikis_tech LinkedIn: https://www.linkedin.com/in/taikis/ 広恵 幸輝 (Kohki Hiroe) アマゾンウェブサービスジャパン合同会社 金融事業統括本部 アカウントエグゼクティブ グローバル金融機関・保険グループを担当するアカウントエグゼクティブ。 クラウドを通じたビジネス革新から、Amazon.comとの戦略的協業まで、お客様のデジタルジャーニーを包括的にサポート。 LinkedIn: https://www.linkedin.com/in/kohkih/ 佐藤 真也 (Shinya Sato) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト AWS の Storage サービス全般が好きで、AWS Black Belt Online Seminar の動画をよく更新しています。普段は保険業界のお客様を担当しています。 原 崚真 (Ryoma Hara) アマゾンウェブサービスジャパン合同会社　金融事業統括本部　地域金融西日本営業部　アカウントマネージャー アカウントマネージャーとして地域金融機関様と一部のSIer様を担当しています。 お客様のクラウドジャーニーをご支援するべく、日々活動しています。 LinkedIn はこちら 宮本 雅勝 (Masakatsu Miyamoto) アマゾンウェブサービスジャパン合同会社 カスタマーソリューションマネージメント本部 カスタマーソリューションマネージャー 金融機関のお客様のクラウドジャーニーを伴走的にご支援しております。 技術のみでなく非技術領域も含めて多岐に渡ってサポートします。 LinkedIn: https://www.linkedin.com/in/masakatsumiya/

「AWS の学習を継続したいけど、なかなかモチベーションが続かない…」「同じ AWS 初学者同士交流を深めたい」「技術的な知見を共有できる場所が欲しい」こんな悩みを持たれたことはありませんか？ 2021 年の開始以来、4,000人以上の仲間を送り出してきた AWS JumpStart に、待望の “Next Stage” が誕生しました。その名も「AWS JumpStart Next」です！ AWS JumpStart Next は学びと交流をテーマにした AWS JumpStart 参加者限定のプログラムです。2025 年 6 月 3 日、記念すべき第 1 回イベントを開催しました。会場には 2021 年から 2025 年まで、総勢 60 名以上の AWS JumpStart 卒業生が集まり、まるで同窓会のような賑やかな雰囲気の中、AI コーディングエージェントの最新トレンドから、先輩たちのリアルな現場経験まで、技術と人とが織りなす特別な空間が生まれました。 このブログでは、イベントの見どころや参加者の生の声をお届けしながら、AWS JumpStart Next が目指す繋がりの場をご紹介していきます。 AWS JumpStart Next は今後も定期的な開催を予定しており、今年は秋ごろに AWS JumpStart Next #2 を計画中です。メール等で配信される開催情報をぜひチェックしてみてください！まだ AWS JumpStart に参加したことがないという方は 8/27(水)-28(木)、10/23(木)-24(金) にも開催予定なのでこちらの ブログ からぜひご登録ください。 1. AWS JumpStart Next とは？ AWS JumpStart Next は、AWS JumpStart 卒業生限定の特別なプログラムです。 AWS JumpStart での学びを終えた後、「もっと深く学びたい」「仲間とのつながりを維持したい」「経験を共有したい」という皆さんの声から生まれました。 このプログラムの特徴は、大きく3つです。 1: 継続的な学びのきっかけ 最新技術のキャッチアップや実践的なグループワークなど、楽しみながら学び続けられる環境をご提供します。 2: 同期との絆を深める場 AWS JumpStart で築いた仲間との絆をさらに深めるとともに、参加年の枠を超えた新しい繋がりの場をご提供します。卒業生同士のつながりを促す Fun 要素を取り入れたコンテンツや、軽食を交えながらの懇親会を実施します。 3: 登壇機会の提供 技術的な知見や現場での AWS 活用経験を共有する場として、誰でも登壇にチャレンジできる機会をご用意しています。実際、今回ご登壇いただいた 3 名の卒業生の皆さんにとって外部に登壇するのは初めての挑戦でした。 2. AWS JumpStart Next #1 2025 年 6 月 3 日、AWS JumpStart Next の記念すべき第 1 回イベント「AWS JumpStart Next #1」を開催しました。本ブログではコンテンツの概要や参加者の声など、イベントのリアルな様子をお届けいたします。 【イベント詳細】 日時：2025 年 6 月 3 日（火）19:00～21:30 会場： AWS Startup Loft Tokyo （東京都品川区） 参加費：無料 対象：過去 AWS JumpStart にご参加いただいた皆様 3. AWS JumpStart Next #1 ハイライト AWS JumpStart Next の初回イベントは、クイズ大会から始まり懇親会まで、参加者同士の交流と技術的な学びが織り交ぜられた充実したプログラムとなりました。各セッションが高い評価を得ており、特にクイズ大会と卒業生 LT は参加者から高い支持が得られました。 オープニング イベントは、AWS JumpStart と今回の AWS JumpStart Next の位置づけについての説明からスタート。参加者同士がこれからのセッションを通じてより深く AWS の知識を得るとともに、同じ AWS 学習者としてのコミュニティを形成することをお伝えしました。 クイズ大会 最初のアイスブレイクとして実施された AWS に関するクイズ大会では、AWS の豆知識や AWS JumpStart の復習など幅広いクイズに参加者が挑戦しました。基礎知識から応用まで様々な問題が出題され、会場は大いに盛り上がりました。初対面の参加者同士も自然と会話が生まれ、その後のセッションでもリラックスした雰囲気が続きました。 AWS 社員による AI コーディングエージェントの最新トレンド紹介 AWS 社員から、Amazon Q Developer を中心とした AI コーディングエージェントの最新動向について紹介しました。実際のデモを通して機能のイメージを掴むことができ、コーディングだけでなく運用タスクでの活用例も紹介されました。さらに MCP の紹介など、AI を活用したより効率的な開発・運用方法について具体的な事例を交えた説明に、参加者は熱心に耳を傾けていました。 卒業生 LT（ライトニングトーク） イベントのハイライトとなったのが、過去の AWS JumpStart 卒業生による LT（ライトニングトーク）セッションです。3 名の卒業生が、JumpStart 後の AWS 活用事例や学びの継続方法、キャリアへの影響などについて発表を行いました。「卒業生の LT が本格的で刺激になった」というコメントが多く寄せられており、JumpStart で学んだことがその後のキャリアでどのように活かされているかを知る貴重な機会となりました。 登壇者と発表内容： 株式会社ネットケアサービス 飯村 淳平 様 タイトル：JumpStart での学びとこれから 株式会社インティメート・マージャー 木村 直人 様 タイトル：自社のアーキテクチャを１から考えてみたら自分の成長を実感できた エキサイト株式会社 山縣 寿樹 様 タイトル：エキサイトブログにおけるAzure→AWSへの移行とIaCの取り組み 各セッションについてグループワーク 後半は参加者同士で AI コーディングエージェントについて議論するグループワークを実施。AI ツールをどのように活用すれば業務が効率化できるか、実際の使用シーンや課題について意見を交換しました。普段は一人で悩みがちな技術的な課題も、様々なバックグラウンドを持つ参加者との対話を通じて新しい視点が得られる貴重な機会となりました。 懇親会と記念撮影 イベントの締めくくりには、参加者全員での記念撮影と軽食を囲んでの懇親会が行われました。特に AWS JumpStart ロゴ入りのスパムおにぎりが大好評で、参加者の間で話題となりました。 懇親会は大いに盛り上がり、参加者全員が積極的にコミュニケーションを取っており、オフラインならではの結束感が生まれたように感じました。「普段接点がない AWS 社員と直接話せる貴重な機会だった」との声もあり、AWS 社員や卒業生との交流を深め、人脈を広げる場となりました。 4. 参加者の声 イベント全体の満足度は非常に高く、参加者の大多数が次回の参加に意欲を見せてくださいました。アンケートからいただいた参加者からのフィードバックをいくつか紹介します： 「最高のイベントでした！」 「卒業生の LT が本格的で刺激になった」 「卒業生 LT が聞けた点はよかったです！」 また SNS では多くの方との交流ができて嬉しかったという声も挙がっていました。 アンケートでは、次回希望するコンテンツとしてハンズオンやディスカッション形式の勉強会が人気でした。これらの声を参考に、次回のイベント内容をさらに充実させていきます！ 5. 今後の展望 次回 AWS JumpStart Next #2 開催予告 AWS JumpStart Next は今回のイベントを皮切りに、継続的に開催していく予定です。今回よりもさらに熱量の高いイベントにすべく、次回も対面での開催を予定しています！ イベント後には多くの参加者から「次は自分も登壇したい」という熱意あふれる声をいただきました。この声に応え、AWS JumpStart Next #2 では、より多くの方々に登壇の機会をご提供できるよう検討を進めております。 具体的な開催日程や内容については AWS JumpStart 参加者向けにメール等でお知らせいたします。 JAWS-UG とのコラボレーション JAWS-UG（AWS User Group – Japan）とは日本全国にある AWS ユーザーによるコミュニティです。JAWS-UG では現場で AWS を活用されているかたが多く、様々な勉強会や交流イベントなどを開催しています。AWS JumpStart Next では今後 JAWS-UG とのコラボレーション企画も検討中です。 こちら から各地域やテーマごとの支部を探すことができますので、ぜひ JAWS-UG にも参加してみてください！ 6. まとめ AWS JumpStart 卒業生が集まるオンサイトイベント AWS JumpStart Next #1 は、参加者同士の技術交流と人的ネットワークの形成という目的を十分に達成し、多くの参加者から高い評価をいただきました。特に AWS JumpStart 卒業生による LT セッションは、AWS 学習の継続的な価値と可能性を示すものとして、参加者に大きな刺激を与えました。 技術と人のつながりが生まれる場所としての AWS JumpStart Next は、これからも AWS を学ぶコミュニティの発展に寄与していきたいと考えています。 このイベント開催にあたり、貴重な体験談をご共有いただいた卒業生発表者の皆様、そして何より積極的に参加いただいたすべての参加者の皆様のおかげで、素晴らしいイベントとなりました。 次回の AWS JumpStart Next #2 でお会いできることを楽しみにしています！ このブログの著者 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ソリューションアーキテクト 菊地 晏南 三浦 信二

6月 24 日と 25 日の 2 日間にわたり、幕張メッセにおいて 14 回目となる AWS Summit Japan が開催され、会場では約 3 万人の方々にご参加いただきました。本イベントでは 90 のセッションと 174 のブース展示が行われ、AWS の最新情報が共有されました。 物流業担当チームでは「倉庫 x OCR x 生成 AI エージェント」と題したデモ展示を行いました。この展示は物流業のみならず、製造業や小売業など倉庫業務に関心をもつ多くの方々にご来場いただき、生成AIによる OCR 読み取りの高精度さや生成AI エージェントを活用した業務高度化について大きな反響をいただきました。本ブログでは、展示内容とそれに使用されたサービスやアーキテクチャについて解説いたします。 背景：物流業界の課題 物流業界では、倉庫における手書き帳票処理が大きな課題となっています。作業スタッフの負担増大により、配送遅延や間違いが多発しており、業務効率化が急務となっています。このような状況を踏まえ、「生成AI を基幹システムとどう連携させるか」「生成AI をどのように業務改善に活用するか」という課題に対する一つの解決策として、今回のデモを企画しました。 デモの全体像 今回のデモでは、倉庫内の手書き帳票業務を対象に、生成AIを活用した OCR 機能とシステム連携による業務効率化ソリューションを紹介しました。以下がその主な特徴です。 1. 生成AIによる高精度な帳票読み取り（OCR） さまざまな帳票レイアウトや手書き文字も高精度で認識 事前に帳票テンプレートを登録・学習させる必要がなく、初見の帳票でも構造を理解して情報を抽出 Anthropic Claude 3.7 Sonnet を活用した高度なテキスト認識能力 2. 生成AIエージェントによる自律的なシステム連携 帳票から読み取った情報をもとに、必要な処理を自律的に判断 抽出情報に基づき、適切なシステムと連携する処理を実行 Anthropic Claude 3.5 Haiku を活用したインテリジェントなワークフロー制御 アーキテクチャ構成 デモのアーキテクチャは以下のような構成になっています。 データ取得 ：ハンディターミナル/タブレットで撮影した帳票イメージをAmazon S3 に保存 OCR 処理 ：AWS Lambdaが起動し、Amazon Bedrock 上の Anthropic Claude 3.7 Sonnet を呼び出して帳票をデジタル化し、抽出されたデータを Amazon DynamoDB に保存 システム連携 ：Amazon Bedrock上の生成AIエージェント（Anthropic Claude 3.5 Haiku）が Amazon DynamoDB の情報を読み取り、連携先の基幹システムを適切に呼び出し 情報可視化 ：基幹システムの情報を BI として Amazon QuickSight で可視化 このシステムにより、手書き帳票のデジタル化から基幹システムとの連携までをシームレスに実現しています。また、Amazon API Gateway、Amazon Cognito、Amazon QuickSightなども活用し、セキュアで使いやすいインターフェースを提供しています。 デモのシナリオを順を追って説明します。 ①データ取得 倉庫内の作業員がハンディターミナルやタブレットを使用してデモアプリケーションから手書き帳票を撮影します。 撮影された画像データは、Amazon API Gatewayを経由してAmazon S3バケットに保存されます。作業員は特別な訓練なしに、簡単な操作で帳票をデジタル化するプロセスを開始できます。これにより、従来は手作業で行っていた帳票の仕分けや管理作業が大幅に効率化されます。 ②OCR処理 生成AI以前の従来の OCR でも画像からデジタルなテキストデータを抽出することは可能でしたが、そのテキストに意味的な解釈を加えるためにはアプリケーション側の工夫が必要でした。例えば、今回の例のように帳票を扱うようなOCRシステムを構築する場合、帳票のテンプレートごとにどこにどのようなデータがあるかという意味的な解釈をシステムに組み込む必要があるため、帳票数が増えるとシステム管理にかかる工数が増大する問題がありました。 生成AIを活用することでこの問題を大幅に軽減できます。Amazon Bedrock にはテキストに加えて画像や音声をインプット情報として処理できるマルチモーダルな生成AIモデルがあります。こうしたモデルに対して、以下のようなプロンプトを画像とともに与えることで、高度なOCR処理を実現できます。 あなたは倉庫管理システムのOCR専門アシスタントです。この画像を分析し、発注指示書かどうかを判定し、情報を抽出して下さい。 ## 判定基準 発注指示書の特徴： - 依頼者情報（名前、住所、電話番号） - 出荷先情報（名前、住所） - 商品リスト（品番、品名、数量） - 「発注」「出荷指示」「納品」等のキーワード ## 出力形式 ### 発注指示書の場合 以下のJSON形式で出力（説明文は不要）： json { "sender_name": "依頼者名", "sender_address": "依頼者住所", "sender_phone": "依頼者電話番号", "recipient_name": "出荷先名", "recipient_address": "出荷先住所", "notes": "備考・特記事項", "shipment_items": [ { "product_code": "品番", "product_name": "品名", "item_count": 数量（数値`）` } ] } ### 発注指示書でない場合 json { "document_type": "other", "content": "読み取った内容をマークダウン形式で記載" } ## 注意事項 - 情報が不明・読み取れない場合は空文字列（""）またはnullを使用 - 数量は必ず数値型で出力 - 日付は可能な限りYYYY-MM-DD形式に変換 - 曖昧な文字は文脈から推測して補完 - JSONの構文エラーがないよう注意 画像を分析して適切な形式で出力してください。 今回のデモ展示では Amazon S3 に帳票画像が保存されると、AWS Lambda がトリガーされ上記のようなプロンプトを使った OCR 処理が開始されます。今回はモデルとして Anthropic Claude 3.7 Sonnet を使用しています。参考までにサンプルのインプットと出力結果を以下に示します。 { "sender_name": "クイックファッション", "sender_address": "141-0021 東京都品川区上大崎4丁目 5-10", "sender_phone": "012-3456-7890", "recipient_name": "クイックファッション墨田倉庫", "recipient_address": "130-0025 東京都墨田区千歳1丁目 5-17", "notes": "第一希望: 5月27日 16時～18時\n第二希望: 5月28日 18時～20時", "shipment_items": [ { "product_code": "A-10606", "product_name": "コンフォートスニーカー", "item_count": 35 }, { "product_code": "G-05011", "product_name": "クロップドワイドパンツ", "item_count": 20 }, { "product_code": "F-20221", "product_name": "くつろぎスウェット", "item_count": 45 } ] } { "sender_name": "セカンドモータース", "sender_address": "〒272-0127 千葉県市川市塩浜2丁目 13-1", "sender_phone": "012-3456-7890", "recipient_name": "セカンドモーターズ 新砂倉庫", "recipient_address": "〒136-0075 東京都江東区新砂3丁目 2-9", "notes": "", "shipment_items": [ { "product_code": "B-101", "product_name": "エクストリームグリップ", "item_count": 63 }, { "product_code": "F-001", "product_name": "冬タイヤセット1", "item_count": 25 }, { "product_code": "F-001", "product_name": "冬タイヤセット1", "item_count": 20 }, { "product_code": "C-0101", "product_name": "Navi Pro", "item_count": 22 } ] } 上記のサンプル画像を比較していただくと、テンプレートが全く異なることがわかります。この異なるテンプレートに対して、単一のプロンプトで想定通りのテキストを抽出できています。最初から倉庫管理システムに登録するために必要なデータ形式として出力されている点も運用上効率的です。 ブース対応の中でコストと認識精度に関する質問を多く頂きました。コストに関しては上記サンプルを OCR した際のInputトークンが 1,900、Output トークンが 400 でした。2025 年 7 月現在の米国リージョンの Anthropic Claude 3.5 Sonnet の単価 で計算すると0.0117 USDとなり、為替にもよりますが1回のOCRあたり1～2円程度のコストになります。 精度に関しては、上記サンプルで確認できる通り撮影状況が良ければ手書き文字であっても高精度で認識が可能です。一方で撮影状況や手書き文字自体によって思うような精度が出ないケースもあり、100 %に近い精度が求められるケースではそのまま導入することは難しい場合もあります。そのような場合には、前処理で OCR 処理がしやすいように画像を加工したり、OCR 処理後のデータを人目で確認させるような Human in the loop の設計とすることで、全体としての認識精度向上に取り組むことができます。今回のデモでは取得したデータをそのまま Amazon DynamoDB に保存しています。 ③システム連携 Amazon DynamoDB に保存された構造化データは、Amazon Bedrock 上の生成AI エージェントによって処理されます。この生成AIエージェントは、抽出された情報を分析し、どのような処理が必要かを自律的に判断します。最終回答が得られるまでReasoning (考察) + Acting (実行)と繰り返す手法を React と呼びます。この React の具体例として、商品の出荷指示であれば在庫管理システムへの連携、返品処理であれば返品管理システムへの連携など、適切な基幹システムを自動的に選択して必要な API を呼び出すといったことができます。 また、Amazon Bedrock のエージェント機能には Multi-agent collaboration があり、エージェントは他のコラボレーターエージェントにタスクを委任できます。具体的には、Supervisor エージェントがまずタスクを処理し、その後各社専用エージェントにタスクを委任することで、異なる基幹システムに対して適切なデータ形式で情報を連携させることが可能です。今回のデモでは OCR 処理した商品情報を Amazon Aurora に登録する AWS Lambda 処理を呼び出しています。 このインテリジェントなシステム連携により、従来は人間が判断して手作業で行っていた複数システム間の連携作業が自動化され、処理時間の短縮とヒューマンエラーの削減を実現します。 ④情報可視化 倉庫側の在庫や出荷状況を確認する仕組みとして Amazon QuickSight を利用しています。Amazon QuickSight は様々な業界やユースケースで利用可能なビジネスインテリジェンスツールです。デモでは商品毎の在庫数等をダッシュボードで表現しました。Amazon QuickSight はマルチデバイスに対応しているため、常設のモニタに KPI を投影したり、倉庫内を頻繁に移動する社員がモバイルデバイスで状況を確認したりと、幅広い活用が可能です。このようにダッシュボードを利用し、在庫切れリスクの早期発見、適正在庫数の維持、需要予測と備蓄計画の立案に活用いただけます。 また、Amazon QuickSight の大きな魅力はデータソースの選択肢が豊富なことです。AWS サービスである Amazon S3 や Amazon Redshift はもちろん、リレーショナルデータベースの Oracle や PostgreSQL、SaaS のデータプラットフォームである Snowflake など、様々なデータソースをサポートしています。今回は WMS の リレーショナルデータベースである Amazon Aurora をデータソースとして参照し、データベース内の入庫情報と出庫情報を基に、リアルタイムで在庫状況をダッシュボード上に表示しています。 期待される効果 このソリューションを導入することで、以下のような効果が期待できます。 業務効率の大幅な向上 ：手書き帳票の処理時間短縮と人的ミスの削減 システム連携の自動化 ：生成AIエージェントによる適切なシステム連携の自動判断 柔軟な対応力 ：様々な帳票フォーマットに対応可能な OCR 能力 導入の容易さ ：テンプレート登録不要で、すぐに活用可能 補足：Amazon Q Developer デモアプリケーションは、すべて Amazon Q Developer を活用して開発されました。従来のアプリケーション開発では、設計から実装まで多くの手作業によるコーディングが必要でしたが、今回のデモアプリケーションでは開発プロセスそのものも生成AIを活用して効率化しています。 Amazon Q Developer は、コード生成、コード変換、バグ修正、コードレビューなどの機能を提供する開発者向けの生成AIアシスタントです。今回のデモアプリケーション開発では、以下のような形で活用しました。 アーキテクチャ設計支援 : システム要件から最適なAWSサービス構成を提案 コード自動生成 : AWS Lambda 関数、API Gateway 設定、DynamoDB 操作など、必要なコンポーネントのコードを自然言語による指示から生成 プロンプトエンジニアリング : OCR 処理やエージェント連携のための最適なプロンプトを設計・改善 デバッグ支援 : 開発中に発生した問題の迅速な特定と修正案の提示・改修 これにより、従来であれば数週間かかるような開発工程が数日で完了し、開発者はビジネスロジックの設計や全体アーキテクチャの最適化に集中することができました。また、生成AI を活用したアプリケーション開発の経験が少ないチームメンバーでも、Amazon Q Developer のガイダンスに従うことで、高品質なコードを短時間で実装することができました。 このように、今回のデモは「生成AI による業務効率化」を示すだけでなく、「生成AI による開発効率化」も同時に実証する取り組みとなりました。物流業同様にソフトウェア開発も人手不足が深刻化しており、開発コストも高騰しています。このような状況で継続的な物流DXを推進するためにAmazon Q Developerを有効に活用することで、開発者の生産性向上と、より複雑な業務課題に対応するソリューションの迅速な開発が可能になります。 まとめ AWS Summit Japan 2025 で展示した「倉庫 x OCR x 生成 AI エージェント」は、物流業界が抱える手書き帳票処理の課題に対して、生成AIを活用した革新的な解決策を提案しています。生成AI を OCR として活用するだけでなく、システム連携のインテリジェンスとしても活用することで、業務プロセス全体の効率化を実現します。 物流業界は2024 年問題をはじめとする様々な課題に直面していますが、今回のデモで示したように、生成AI の活用によって、デジタルに詳しくない作業員でも簡単に業務を遂行できるようになり、生産性の向上が期待できます。物流が抱える課題の解決に向けて、生成AI の活用を検討してみてはいかがでしょうか。 このブログは、ソリューションアーキテクト 横山、宇加治、山本、駒野 が担当しました。

このブログは 2025 年 6 月 26 日 に Dave Jaskie、 Gekai Zou、 Aamir Khan、 Anshu Prabhat によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 お客様から Amazon WorkSpaces Personal に接続するために AWS PrivateLink を活用する方法についてよくお問い合わせをいただきます。 PrivateLink は、インターネットゲートウェイ、 NAT デバイス、 VPN 設定などの従来のネットワークコンポーネントを必要とせずに、安全でプライベートな接続を確立するシームレスな方法を提供します。このアプローチは、ネットワークアーキテクチャを簡素化するだけでなく、攻撃対象領域を大幅に削減し、すべてのデータトラフィックを AWS ネットワーク内で安全に保つことでセキュリティを強化します。このブログでは、 PrivateLink を WorkSpaces と統合するプロセスを段階的にガイドし、お客様の環境でこれらの利点を活用できるよう支援します。 前提条件と制限事項 WorkSpaces の PrivateLink は現在、ストリーミングトラフィックでサポートされています。 WorkSpaces の 前提条件と制限事項 の詳細については、 管理者ガイド を確認してください。 PrivateLink を設定するには、まずセキュリティグループを設定し、 VPC エンドポイントを作成し、最後に VPC エンドポイントを使用するように WorkSpace ディレクトリを設定する必要があります。 ステップ 1: セキュリティグループの作成 このステップでは、 WorkSpaces クライアントが作成する VPC エンドポイントと通信できるセキュリティグループを作成します。 Amazon EC2 コンソール のナビゲーションペインで、 ネットワーク & セキュリティ 、次に セキュリティグループ に移動します。 セキュリティグループの作成 を選択します。 基本的な詳細 で、以下を入力します： セキュリティグループ名 – セキュリティグループを識別する一意の名前を入力します。 説明 – セキュリティグループの目的を説明するテキストを入力します。 VPC – VPC エンドポイントがある VPC を選択します。 インバウンドルール に移動し、 ルールの追加 を選択して TCP トラフィック用のインバウンドルールを作成します。 以下を入力します： タイプ – カスタム TCP を選択します。 ポート範囲 – 次のポート番号を入力します： 443 、 4195 ソースタイプ – カスタムを選択します。 ソース – ユーザーが VPC エンドポイントに接続するプライベート IP CIDR 範囲または他のセキュリティグループ ID を入力します。 IPv4 アドレスソースからのインバウンドトラフィックのみを許可するようにしてください。 各 CIDR 範囲またはセキュリティグループに対してステップ 4 と 5 を繰り返します。 インバウンドルール に移動し、 ルールの追加 を選択して UDP トラフィック用のインバウンドルールを作成します。 以下を入力します： タイプ – カスタム UDP を選択します。 ポート範囲 – 次のポート番号を入力します： 443 、 4195 ソースタイプ – カスタムを選択します。 ソース – ステップ 5 で入力したのと同じプライベート IP CIDR 範囲またはセキュリティグループ ID を入力します。 各 CIDR 範囲またはセキュリティグループに対してステップ 7 と 8 を繰り返します。 セキュリティグループの作成 を選択します。 ステップ 2: VPC エンドポイントの作成 Amazon VPC では、 VPC エンドポイントを使用して VPC をサポートされている AWS サービスに接続できます。この例では、 WorkSpaces ユーザーが WorkSpaces からストリーミングできるように Amazon VPC を設定します。 Amazon VPC コンソール を開きます。 ナビゲーションペインで、 エンドポイント 、次に エンドポイントの作成 に移動します。 エンドポイントの作成 を選択します。 以下を確認します： サービスカテゴリ – AWS サービスが選択されていることを確認します。 サービス名 – com.amazonaws. Region .prod.highlander を選択します。 VPC – インターフェースエンドポイントを作成する VPC を選択します。VPC エンドポイントにアクセス可能なネットワーク環境であれば、 WorkSpaces リソースがある VPC とは異なる VPC を選択できます。 プライベート DNS 名を有効にする – チェックボックスが選択されています。ユーザーがネットワークプロキシを使用してストリーミングインスタンスにアクセスする場合は、プライベートエンドポイントに関連付けられたドメインと DNS 名でプロキシキャッシュを無効にします。 VPC エンドポイント DNS 名はプロキシを通過できるようにする必要があります。 DNS レコード IP タイプ – IPv4 を選択します。デュアルスタックと IPv6 DNS レコード IP タイプは現在サポートされていません。デュアルスタックまたは IPv6 が選択されている場合、 VPC エンドポイントを使用して WorkSpaces からストリーミングできません。 サブネット – VPC エンドポイントを作成するサブネット（アベイラビリティーゾーン）を選択します。少なくとも 2 つのサブネットを選択することをお勧めします。 IP アドレスタイプ – IPv4 を選択します。 セキュリティグループパネル – 先ほど作成したセキュリティグループを選択します。 （オプション） タグ パネルで、 1 つ以上のタグを作成できます。 エンドポイントの作成 を選択します。 エンドポイントが使用可能になると、ステータス列の値が利用可能に変わります。 ステップ 3: VPC エンドポイントを使用するように WorkSpaces ディレクトリを設定する ストリーミング用に作成した VPC エンドポイントを使用するように WorkSpaces ディレクトリを設定する必要があります。 VPC エンドポイントと同じ AWS リージョンで WorkSpaces コンソール を開きます。 ナビゲーションペイン で、 ディレクトリ を選択し、 使用する ディレクトリ を選択します。 VPC エンドポイントセクション に移動し、 編集 を選択します。 VPC エンドポイントの編集ダイアログボックス で、 ストリーミングエンドポイント の下で、作成した VPC エンドポイントを選択します。 オプションで 、 PCoIP WorkSpaces を使用するユーザーがインターネットからストリーミングできるようにすることを有効にする ことができます。 有効にすると、ユーザーはパブリックインターネット経由で PCoIP WorkSpaces からストリーミングできるようになります。そうでなければ、 PCoIP WorkSpaces はストリーミングに VPC エンドポイントの使用をサポートしていないため、ディレクトリ内の PCoIP WorkSpaces にアクセスできなくなります。 保存 を選択します。 新しいストリーミングセッションのトラフィックは、この VPC エンドポイント経由でルーティングされます。ただし、現在のストリーミングセッションのトラフィックは、以前に指定されたエンドポイント経由でルーティングされ続けます。 まとめ この投稿では、 Amazon WorkSpaces Personal を PrivateLink で設定する方法について説明しました。 PrivateLink の詳細については、製品ページをご確認ください。ご質問がございましたら、 AWS サポートチームまでお問い合わせください。 End User Compute の新機能の最新情報については、 AWS の新機能をチェックし、 YouTube プレイリストもぜひご覧ください。

本記事は、2025 年 4 月 24 日に公開された “ How to use data from the AWS Open Data program in Amazon Bedrock ” を翻訳したものです。翻訳はソリューションアーキテクトの秋山が担当しました。 AWS オープンデータスポンサーシッププログラム は、価値の高いデータセットをクラウド上でホストすることでデータ取得の障壁を排除し、研究者やアナリストがデータ管理ではなく、発見とイノベーションに集中できるようにします。データが Amazon Web Services (AWS) で共有されると、誰でも Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Athena 、 AWS Lambda 、 Amazon EMR などの幅広いコンピューティングおよびデータ分析プロダクトを使用して、データを分析し、その上にサービスを構築することができます。AWS は Registry of Open Data on AWS を通じて、AWS 上で公開されているデータセットのカタログを提供しています。このレジストリには、政府データ、科学研究、ライフサイエンス、気候、衛星画像、地理空間、ゲノムデータなど、650 以上のデータセットが一般に公開されています。 米国海洋大気庁 (NOAA) をはじめとする多くの政府機関が、AWS オープンデータスポンサーシッププログラムに参加しています。NOAA は NOAA オープンデータ配信 (NODD) プログラム を通じてデータを一般に公開しています。 AWS 上のすべての NODD データセットを閲覧 することができます。このチュートリアルでは、NODD プログラムの NOAA データを使用して、お客様が Amazon Bedrock で AWS オープンデータを通じて利用可能なデータをどのように活用できるかをご紹介します。 この投稿では、 Amazon Bedrock Knowledge Bases を使用して、AWS のオープンデータレジストリにある NOAA データセットを活用する方法について説明します。Amazon Bedrock Knowledge Bases を使用することで、プライベートおよびパブリックのデータソースからコンテキスト情報を 基盤モデル (FM) とエージェントに提供し、より関連性が高く、正確で、カスタマイズされた応答を実現できます。特に NOAA のグローバル歴史気候ネットワーク (GHCN) を使用することで、SQL コマンドや一般的なデータ検索ツールに慣れていないユーザーでも、降水量や積雪深などの情報にアクセスできるようになります。チャットベースのアシスタントを通じて、技術的な知識を持たない意思決定者でも、高度な技術データに理解しやすい形式でアクセスできるようになりました。 ソリューションの概要 この投稿は 2 つのパートに分かれています。パート 1 では、少数のファイルのみを使用するため、大きなコストをかけることなく機能を試すことができます。パート 2 では、データセット全体を使用して機能の全体像を把握できますが、コストも高くなります。追加コストの発生を防ぐため、作業が完了後はナレッジベースとベクトルストアを削除することをお勧めします。 NOAA Global Historical Climatology Network (GHCN) データセットをナレッジベースとして使用します。このデータセットには、米国全土の観測所からの気温と積雪深の測定値が含まれています。このデータセットは、AWS のオープンデータレジストリにある公開 Amazon Simple Storage Service (Amazon S3) バケット内の CSV ファイルとテキストファイルのセットとして提供されています。 前提条件 このソリューションを実行するには、以下の前提条件が必要です： 関連するサービスへのアクセス権限を持つ AWS アカウントへのアクセス AWS Management Console の基本的な知識 パート 1: ソリューションの概要 AWS のオープンデータレジストリから始めましょう: Registry of Open Data on AWS のウェブサイトで、以下のスクリーンショットに示すように、 Search datasets バーに GHCN と入力します。 図 1. Registry of Open Data on AWS の検索データセットボックスに GHCN を入力した状態 NOAA Global Historical Climatology Network Daily (GHCN-D) データセットを選択してレジストリページを開きます。 Browse Bucket リンクを右クリックして新しいウィンドウで開きます。このリンクをクリックすると、NOAA GHCN パブリックバケット内の現在のすべてのファイルとフォルダのリストが表示されます。 図 2. noaa-ghcn-pds バケットの AWS S3 Explorer ビュー csv/ フォルダを開き、次に by_year/ フォルダを開きます。GHCN のデータが 1750 年まで遡って用意されていることを確認できます。まず、利用可能なデータを確認するために、最も古いファイルのいくつかを見てみましょう。 1763.csv と 1764.csv ファイルを選択してダウンロードします。 ページの下部までスクロールし、 Next を選択します。データの最後のページに到達するまで Next を選択し続けます。この記事の執筆時点では、ページ 6 に 2012 年から 2025 年までのデータがあります。 2023.csv と 2024.csv もダウンロードします。 1763.csv と 1764.csv ファイルから始めて、それぞれのファイルをアプリケーションで開いてデータを確認します。 ファイルとデータ形式 データセットをナレッジベースとして検討する際には、ファイルのフォーマットとそのデータの内容が重要です。ナレッジベースに対して質問を投げかけ、適切な回答を得るためには、ファイルの内容とその参照方法を理解する必要があります。 例えば、1763.csv の GHCN データには、ID、DATE、ELEMENT、DATA_VALUE という列があります。この最初の 4 つの列が、この投稿の残りの部分の焦点となります。NOAA は open-data-docs リポジトリで各列のドキュメントを提供しています。NOAA のドキュメントによると、最初の列は観測所 ID (ID) です。DATE 列の日付は YYYYMMDD 形式で、例えば 17630127 は 1763 年 1 月 27 日を意味します。ELEMENT 列には、最高気温 (TMAX)、最低気温 (TMIN)、積雪深 (SNWD)、降水量 (PRCP) が含まれています。DATA_VALUE は ELEMENT の実際の値です。 ファイルをローカルで表示すると、観測所 (ID) ITE00100554 の 17630131 (1763 年 1 月 31 日) の最高気温が 9 であったことが、次のスクリーンショットのように確認できます。 図 3. ID ITE00100554の1763年1月31日の最高気温が9である1763.csvのスクリーンショット プライベート S3 バケットの作成 1763.csv と 1764.csv を使用してナレッジベースを作成するには、以下の手順に従ってください： Amazon S3 コンソール で、 バケットを作成 を選択し、バケット名を YOURNAME -ghcn-1763-1764 とします。 YOURNAME の部分は、バケット名を一意にするためにあなたの姓名などに置き換えてください。ページ内の他の設定はすべてデフォルトのままにして、ページ下部の バケットを作成 を選択します。 バケットが作成されたら、それを選択してバケットの内容を表示します（空の状態です）。 1763.csv と 1764.csv ファイルをバケットにドラッグ＆ドロップし、 アップロード を選択します。以下のスクリーンショットのように、両方のファイルがバケットにコピーされるまで待ちます。 または、アップロードボタンを使用します。1763.csv と 1764.csv ファイルをドラッグ＆ドロップするか、 ファイルを追加 を選択して追加できます。 アップロード を選択し、以下のスクリーンショットのように両方のファイルがバケットにコピーされるまで待ちます。 図 4. 1764.csv と 1763.csv を Files and folders にアップロードしたスクリーンショット 1760 年代のナレッジベース プライベートバケット内のデータを使用して、最初のナレッジベースを作成します。Amazon Bedrock の FM を使用するには、まずアクセス権限のリクエストが必要です。アクセス権限のリクエストとナレッジベースの作成には、以下の手順に従ってください： Amazon Bedrock コンソール の左側のナビゲーションペインで、 Configure and learn  の下にある モデルアクセス を選択します。 モデルアクセス ページで、 モデルアクセスを変更 を選択します。 Titan Text G1 – Premier 、 Titan Embeddings G1 – Text 、 Titan Text Embeddings V2、 Nova Pro、Nova Lite  の横にあるチェックボックスを選択し、 次へ を選択した後、 送信 を選択してこれらのモデルへのアクセスをリクエストします。 Build  の下で、 ナレッジベース  を選択します。 作成 を選択し、 ベクトルストアを含むナレッジベース を選択します。このウォークスルーでは、 Amazon OpenSearch Serverless を使用するベクトルストアを使用しますが、Amazon Bedrock ユーザーガイドの Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases で他のオプションも確認できます。 ナレッジベースに YOURNAME -GHCN-1763-1764 という名前を付けます。 YOURNAME をあなたの名前に置き換えてください。ページの残りの部分はデフォルトのままにして、 次へ を選択します。 データソース  で、以下を変更します： データソースの場所 は、 この AWS アカウント  のままにします。 S3 URI で、 S3 を参照  を選択し、先ほど作成した YOURNAME -ghcn-1763-1764 バケットを選択します。 ページの残りの部分はデフォルトのままにして、 次へ  をクリックします。 ここで使用する Embeddings モデルを選択する必要があるので、 モデルを選択  をクリックし、 Titan Text Embeddings V2 を選択して、 適用 をクリックします。 ページの残りの部分はデフォルトのままにして、 次へ を選択します。 選択内容を確認し、準備ができたら ナレッジベースを作成 を選択します。 Amazon OpenSearch Serverless でベクトルデータベースを準備するには数分かかります。このチュートリアルで使用する少量のデータであっても、Amazon OpenSearch Serverless コレクションにはコストが発生することに注意してください。コストを監視するために、 Cost Explorer の予算やアラーム を設定することをお勧めします。 ベクトルデータベースが作成されると、「Amazon OpenSearch Serverless ベクトルデータベースの準備が完了しました」という通知を受け取り、ナレッジベースが作成されます。この時点では空のベクトルストアができているので、データを投入する必要があります。そのためには、データを同期する必要があります： 以下のスクリーンショットに示すように、 データソース で作成したデータソースを選択します。 図 5. 選択したデータソースと同期する準備ができた GHCN-1763-1764 ナレッジベース ベクトルストアにデータの追加を開始するには、 同期 を選択します。プライベートバケットには 2 つのファイルしかないため、数分で完了するはずです。 2 つのファイルの内容をいくつか把握しているため、ローカルでファイルを開いて、答えがわかっている質問をすることができます。これにより、ナレッジベースがファイル内のデータを使用していること、およびそのデータを正しく使用していることを確認できます。ナレッジベースをテストするには、以下の手順に従ってください： テストに使用するモデルを選択するには、 ナレッジベースをテスト の下で モデルを選択 を選択します。 Nova Lite を選択し、 適用 を選択します。同様の回答を返す他のモデルも利用可能です。 ナレッジベースに質問するには、 プロンプトを記述 ボックスに以下をペーストし、 Run を選択します。 What was the TMAX on 17630131? 先ほど示したように、ファイルから答えは 9 であることがわかっています。ナレッジベースは以下の回答を提供します： The TMAX on 17630131 was 9 degrees ナレッジベースがどのように回答を導き出したかを確認するには、 詳細 > を選択します。メタデータには、Amazon Bedrock が回答を形成するために情報を見つけたファイル (source-uri) が表示されます。 ソースチャンク  には使用された実際のデータチャンクが表示され、以下のようになります： , ITE00100554,17630124,TMIN,10,,,E, ITE00100554,17630125,TMAX,24,,,E, ITE00100554,17630125,TMIN,-2,,,E, ITE00100554,17630126,TMAX,6,,,E, ITE00100554,17630126,TMIN,-22,,,E, ITE00100554,17630127,TMAX,1,,,E, ITE00100554,17630127,TMIN,-27,,,E, ITE00100554,17630128,TMAX,-5,,,E, ITE00100554,17630128,TMIN,-33,,,E ITE00100554,17630129,TMAX,-1,,,E, ITE00100554,17630129,TMIN,-29,,,E, ITE00100554,17630130,TMAX,4,,,E, ITE00100554,17630130,TMIN,-16,,,E, ITE00100554,17630131,TMAX,9,,,E, ITE00100554,17630131,TMIN,-21,,,E, ITE00100554,17630201,TMAX,19,,,E, ITE00100554,17630201,TMIN,-11,,,E, ITE00100554,17630202,TMAX,28,,,E, ITE00100554,17630202,TMIN,-2,,,E, 上記でハイライトされているように、以下のチャンクが私たちの回答です。 ITE00100554, 17630131, TMAX,9,,,E, ナレッジベースが情報をどのように解析し、回答を導き出すかを理解するために、いくつかの質問を試してみてください。 クリーンアップ 今後の料金の発生を防ぐため、作業が完了したらナレッジベースを削除する必要があります。ナレッジベースを削除するには： Amazon Bedrock コンソールの Build  で、 ナレッジベース を選択し、 YOURNAME -GHCN-1763-1764 ナレッジベースを選択します。 ナレッジベース作成時の詳細設定でベクトルストアを保持することを選択した場合、ナレッジベースを削除する前に Amazon OpenSearch のインデックス名を確認する必要があります。 ベクトルデータベース までスクロールし、 コレクション ARN をメモしてください： arn:aws:aoss:REGION:AWSACCOUNTID:collection/ UUID で、 UUID は ea50z3iuyaavwy8bymq4 のようなコレクションの一意の識別子になります 新しいタブまたはブラウザウィンドウで OpenSearch Service コンソールを開き、 Serverless の下にある Collections を選択し、このチュートリアルで作成したコレクションを選択して開きます。 コレクション ARN が、ベクトルデータベース用に受け取った Amazon Resource Name (ARN) と一致することを確認します。 arn:aws:aoss:REGION:AWSACCOUNTID:collection/ UUID ベクトルデータベースを削除するには、 コレクションを削除  を選択し、ダイアログボックスに 確認 と入力します。 Amazon Bedrock タブに戻り、ナレッジベースの削除の最後のステップを完了します。 削除  を選択し、ウィンドウに 削除 と入力します。 図 6. GHCN-1763-1764 のナレッジベースを削除 パート 2: ソリューションの詳細 このセクションでは、パート 1 で学んだ内容を活用して、Registry of Open Data のデータセットを使用したナレッジベースを直接利用することができます。ファイルをコピーする代わりに、Amazon Bedrock にパブリックバケットを直接指定します。以下の手順に従ってください： Registry of Open Data on AWS で、 Search datasets バーに GHCN と入力します。 レジストリページを開くために NOAA Global Historical Climatology Network Daily (GHCN-D) データセット を選択します。 このページにある Amazon Simple Notification Service (Amazon SNS) トピックに注目してください： arn:aws:sns:us-east-1:123901341784:NewGHCNObject アカウント ID の部分 ( 123901341784 ) を選択し、後でアカウント ID が必要になるため、このウィンドウを別のタブで開いたままにしておきます。 Browse Bucket リンクを右クリックして新しいウィンドウで開きます。このリンクをクリックすると、NOAA GHCN パブリックバケット内の現在のすべてのファイルとフォルダの一覧が表示されます。 このウォークスルーでは、データセット全体のサブセットのみを使用するために、ナレッジベースを特定のフォルダに制限する必要があります。これにより、このデモで発生するコストを抑えることができます。このデータセットをテストや開発以外の目的で使用する場合は、バケット全体を使用することをお勧めします。 NOAA は GHCN データのパフォーマンス改善に取り組んでおり、プレフィックス (またはフォルダ) が変更される可能性があることにご注意ください。 パート 1 と同様に、 csv/ フォルダ、次に by_year/ フォルダを開きます。ただし、今回は by_year フォルダ全体を使用します。バケット名とフォルダパスは次のようになります： s3://noaa-ghcn-pds/csv/by_year/ ウィンドウの右下にある番号付きのリンクを使用して、バケット内の最後のエントリに移動します。この記事の執筆時点では、 6 を選択すると、2012-2025.csv の年のファイルが表示されます。 2024.csv と 2023.csv を選択してダウンロードし、後で使用するために保存します。これらのファイルを使用して、最初にナレッジベースへのクエリを実行します。 GHCN 年次ナレッジベース パブリック AWS Open Data バケットのデータを使用して、新しいナレッジベースを作成します。パブリック AWS Open Data バケットから新しいデータでナレッジベースを更新したい場合は、 同期  コマンドを使用して更新できます。 Amazon Bedrock コンソールで、 作成 を選択し、 ベクトルストアを含むナレッジベース を選択します。 ナレッジベースに YOURNAME -GHCN-by-year という名前を付けます。 YOURNAME はあなたの名前に置き換えてください。ページの残りの部分はデフォルトのままにして、 次へ を選択します。 Data source で、以下の変更を行います： Data source location を Other AWS account に変更します。 Account ID に 123901341784 を入力します。 S3 URI に s3://noaa-ghcn-pds/csv/by_year/ を入力します。 ページの残りの部分はデフォルトのままにして、 次へ を選択します。 埋め込みモデルを選択するには、 モデルを選択 を選択し、 Titan Text Embeddings V2 を選択して、 適用 を選択します。 ページの残りの部分はデフォルトのままにして、 次へ を選択します。 選択内容を確認し、準備ができたら ナレッジベースを作成 を選択します。 Amazon OpenSearch Serverless でベクトルデータベースを準備するには数分かかります。Amazon OpenSearch Serverless コレクションには料金が発生します。この例では、パブリックの GHCN バケットにある数百のファイルを使用しています。コストを監視するために、 Cost Explorer の予算やアラーム を設定することをお勧めします。 ベクトルデータベースが作成されると、「Amazon OpenSearch Serverless ベクトルデータベースの準備が完了しました」という通知が表示され、ナレッジベースが作成されます。この時点では空のベクトルストアができているので、データを投入する必要があります。そのためには、データを同期する必要があります： 以下のスクリーンショットに示すように、 Data source で作成したデータソースを選択します。 図 8. 選択したデータソースと同期準備が完了した GHCN-by-year ナレッジベース ベクトルストアへのデータ追加を開始するには、 同期 を選択します。すべてのファイルをベクトルストアにパースするには数時間かかる場合があります。同期の完了を待つ間に、ナレッジベースの同期が完了した後にどのような質問ができるかを確認するため、いくつかのファイルをダウンロードすることができます。 同期が完了したら、以下の手順でナレッジベースをテストしてください： Amazon Bedrock コンソールで、 Build  の下にある ナレッジベース を選択し、 YOURNAME -GHCN-by-year ナレッジベースを選択します。 ナレッジベースをテスト で、テストに使用するモデルを選択するために モデルを選択 を選択します。 Nova Lite を選択し、 適用 を選択します。 これで質問の準備が整いました。以下にいくつかの例を示します： 質問： What was ASN00007139 TMAX in 17500301? 回答: The TMAX value for ASN00007139 on 17500301 is 424 ボットからの応答の横にある Show details > リンクに注目してください。このリンクを選択すると、応答の生成に使用されたファイルのチャンクを確認できます。 以下のような一般的な質問もできます： 質問: What types of data are in this knowledge base? 回答: Based on the retrieved results, the knowledge base contains data related to precipitation (PRCP), maximum temperature (TMAX), and minimum temperature (TMIN) データの内容と、ナレッジベースでの使用方法がわかったので、データセット全体に対して以下のような質問ができます: 質問: What was highest SNWD recorded for US1AKFN0032? 回答: The highest SNWD recorded for US1AKFN0032 is 559.0 この値は、アラスカ州フェアバンクスの積雪深を示しています。 NOAA GHCN ドキュメント を使用して最寄りの観測所を見つけ、どのような値が得られるか確認してみましょう！必要に応じて、コストを節約するために作業が完了したらナレッジベースを削除することもできます。 クリーンアップ 今後の料金の発生を防ぐため、作業が完了したらナレッジベースを削除する必要があります。ナレッジベースを削除するには： Amazon Bedrock コンソールで、 Build  の下にある ナレッジベース を選択し、 YOURNAME - GHCN-by-year ナレッジベースを選択します。 ナレッジベース作成時の詳細設定でベクトルストアを保持することを選択した場合、ナレッジベースを削除する前に Amazon OpenSearch Serverless のインデックス名を確認する必要があります。 ベクトルデータベース までスクロールし、 コレクション ARN をメモしてください。 arn:aws:aoss:REGION:AWSACCOUNTID:collection/ UUID で、 UUID は ea50z3iuyaavwy8bymq4 のようなコレクションの一意の識別子になります 新しいタブまたはブラウザウィンドウで Amazon OpenSearch Service コンソールを開き、 Serverless の下にある Collections を選択し、このチュートリアルの一部として作成したコレクションを開きます。 ベクトルデータベースで確認した コレクション ARN と、 コレクション ARN が一致することを確認します。 arn:aws:aoss:REGION:AWSACCOUNTID:collection/ UUID ベクトルデータベースを削除するには コレクションを削除  を選択し、ダイアログボックスに 確認 と入力します。 Amazon Bedrock タブに戻り、ナレッジベースの削除の最後のステップを完了します。 削除  を選択し、ウィンドウに 削除 と入力します。 まとめ NOAA のデータ配信プログラムは、5 つの重要な目的のために環境データを共有しています。第一に、気象予報、緊急対応、海事・航空分野における輸送の安全性に関する重要な情報を提供します。第二に、科学者が気候研究、環境分析、トレンドモデリングを実施できるようにします。第三に、農業の収穫計画の支援、漁船団の航路最適化、観光事業の気象条件への適応など、産業全体の経済的意思決定をサポートします。第四に、公共データへのアクセスに関する連邦政府の要件を満たし、機関間の連携を強化します。第五に、気象モニタリングと環境研究の共有を通じて国際的なパートナーシップを支援します。このプログラムは、公的資金で収集された環境データは科学の発展と社会の利益のために自由に利用できなければならないという基本原則に基づいて運営されています。 AWS のオープンデータレジストリには、基盤モデルに追加のコンテキストを提供するために使用できる、650 以上のパブリックデータセットが含まれています。Amazon Bedrock は、AWS のオープンデータレジストリにあるパブリックデータセットの使用をサポートするようになったため、データセットのコピーを維持する必要がなくなりました。次のプロジェクトで使用できるデータセットがあるかどうか、レジストリをご確認ください。 リソース Amazon Bedrock ユーザーガイドの データをナレッジベースに変換する Amazon Bedrock ユーザーガイドの Amazon Bedrock でサポートされているデータ型 AWS のオープンデータについて詳しく学ぶ AWS のオープンデータレジストリでデータを探す Amazon Sustainability Data Initiative について詳しく学ぶ Chris Stoner Chris は AWS オープンデータチームのオープン環境・地理空間データ責任者です。以前は、 AWS Ground Station の主任プロダクトマネージャーとして、宇宙関連顧客向けの「サービスとしてのアンテナ」の開発を担当していました。また、アラスカ衛星施設 (ASF) 分散型アクティブアーカイブセンター (DAAC) で NASA の契約社員として働き、クラウド上での Sentinel-1 および NISAR ミッションのアーキテクチャを開発していました。Chris はマサチューセッツ大学アマースト校で MBA を、マサチューセッツ大学ローウェル校で IT 学士号を取得しています。技術系学術論文の著者であり、複数の特許を保有しています。

ここ、英国にも夏がやってきました! でも私は夏がちょっと苦手です。多くの人とは違い、外出時に「輝かしい太陽」を浴びることにそれほど熱心ではありません。とはいえ、夏は換気の良い快適な部屋でくつろぐための最高の口実になりますし、コーディングや最新の AWS リリースのキュレーションに集中して、皆様にハイライトをお届けすることができます。 また、7 月 13 日は日中 AWS Developers Podcast のエピソードを録画していたので、暑さから逃れることができました。このエピソードでは、素晴らしい Sebastien Stormaq と Tiffany Souterre からゲーム開発についてインタビューを受けました。まだご覧になっていない場合は、ぜひご視聴ください。このポッドキャストのエピソードは、AWS はもちろんお客様やコミュニティメンバーからの興味深い教訓やインサイトが満載です。リラックスした会話の中で、ストーリーや専門知識が共有されています。 さて、7 月 7 日週にリリースされた新しいサービスや製品を発見する準備はできていますか?  ハイライトをご紹介します。 AWS Builder Center AWS ビルダーとコミュニティメンバーのための新しいホームができました! AWS Builder Center は、クラウドビルダーがつながり、知識を共有し、リソースにアクセスして AWS ジャーニーを強化できる、新しい場所です。このプラットフォームにより、ユーザーはシングル Builder ID サインインを使用して、コミュニティプログラムへの参加、トレンドトピックの発見、AWS Skill Builder コースへのアクセス、技術的な課題への参加などを行うことができます。 私が個人的に最も楽しみにしている機能の 1 つが ウィッシュリスト です。要望書を作成して AWS の製品やサービスを改善する方法を直接 AWS に伝えたり、自分やチームの役に立つと思われる独創的なアイデアを共有したりできるようになりました。また、既存の要望を閲覧して賛成票を投じ、優先すべきだと思う提案をサポートすることもできます。AWS チームはこのウィッシュリストに注意を払います。関心を集めている要望は、検討される可能性があります! ニュースブログ投稿を読んで、 最もエキサイティングな機能のいくつかを簡単に確認 するか、 AWS Builder Center にアクセスし探索してみましょう。 AI AI の世界は、物事を行ったり生産性を高めたりするための新しくてエキサイティングな方法を提供することで、急速に変化し続け、私たちの世界を変え続けています。私が注目した先週のリリースを 2 つご紹介します。 AWS マネジメントコンソールの Amazon Q チャットで AWS サービスデータのクエリが可能に – Amazon Q Developer は、S3、DynamoDB、CloudWatch などの AWS サービス全体に保存されているデータに対して、AWS コンソール、Slack、Microsoft Teams、AWS コンソールモバイルアプリケーションから直接自然言語クエリを実行できるようにすることで、機能を拡張します。この機能強化により、ユーザーは会話型インターフェースからサービスデータにアクセスして分析できるようになり、アクセス制御は IAM 許可を通じて管理されるため、クラウドの管理とトラブルシューティングが合理化されます。 AI 支援トラブルシューティング用の Amazon CloudWatch サーバーと Application Signals MCP サーバー – AWS は、新しい 2 つのモデルコンテキストプロトコル (MCP) サーバーである CloudWatch MCP と Application Signals MCP をリリースしました。これにより、AI エージェントはオブザーバビリティデータを活用し、会話型インターフェイスを通じて自動トラブルシューティングを行うことができます。これらのオープンソースサーバーにより、AI アシスタントは AWS 環境全体のメトリクス、アラーム、ログ、トレース、サービスヘルスデータを分析できるようになるため、開発者が複数の AWS コンソールを手動で操作しなくても、インシデント対応と根本原因分析を合理化できます。 Oracle Database@AWS 7 月 13 日、Andy Jassy が Oracle Database@AWS を構築するための Oracle とのパートナーシップを発表したようです。Oracle Database@AWS は、AWS データセンター内の Exadata インフラストラクチャ上で Oracle データベースを直接実行し、AWS と Oracle の統一されたエクスペリエンスを提供する共同提供サービスです。先週、 Oracle Database@AWS は一般公開リリースで重要なマイルストーンに達しました 。現在、米国東部 (バージニア北部) および米国西部 (オレゴン) リージョンで利用することができ、今後さらに世界の 20 のリージョンに拡大する予定です。 さらに、 VPC Lattice は Oracle Database@AWS のサポートを追加 し、VPC とオンプレミス環境のアプリケーションと Oracle データベースネットワークとのシームレスな接続を実現しました。この統合によりネットワーク管理が簡素化され、複雑なネットワーク設定を必要とすることなく Oracle Database@AWS から Amazon S3 や Amazon Redshift などの AWS サービスに安全にアクセスできるようになります。 つまり、Oracle データベースのワークロードの移行を考えているなら、Oracle Database@AWS を検討する絶好の機会です。最小限の変更で、素晴らしい道を切り開くことができるからです。 その他のハイライト その他にも、多くの方が喜ぶと思われるリリースをいくつかご紹介します。 AWS Config が 12 種類の新しいリソースタイプのサポートを開始 – AWS Config では、BackupGateway、CloudFront、EntityResolution、Bedrock などのサービス全体で 12 種類の新しいリソースタイプのサポートを開始し、モニタリング機能が拡張されました。すべてのリソースタイプで記録を有効にしている場合、これらの追加は自動的に追跡され、AWS リソースの発見、評価、監査の能力が向上します。 Amazon SageMaker Studio が Visual Studio Code からのリモート接続のサポートを開始 – Amazon SageMaker Studio は Visual Studio Code からのリモート接続のサポートを開始しました。これにより、開発者は SageMaker のスケーラブルなコンピューティングリソースを AI 開発に活用しながら、使い慣れた VS Code セットアップを使用できるようになりました。 AWS Network Firewall: すべてのリージョンでネイティブ AWS Transit Gateway をサポート – AWS Network Firewall では、サポートされているすべてのリージョンで AWS Transit Gateway とのネイティブ統合が可能になり、VPC とオンプレミスネットワーク間の直接接続とトラフィック検査の簡素化が実現されました。この統合により、専用の VPC サブネットとルートテーブルを管理する必要がなくなるとともに、マルチ AZ の冗長性が提供され、セキュリティと信頼性が向上します。 AWS の今後のイベント AWS Summit New York – これは間違いなく視聴すべきイベントです! 定員に達したため、登録は締め切られましたが、 すべての発表とリリースをライブで視聴 できます! ネタバレするつもりはありませんが、エキサイティングな内容が多く含まれていますので、ぜひチェックしてください。 AWS Gen AI Lofts – AWS Gen AI Lofts は、生成 AI への取り組みを探求したい、または発展させたいと考えている開発者やビジネスリーダーを対象に、ハンズオンワークショップ、エキスパートによるガイダンス、ネットワーキングの機会を提供する、複数日にわたるイベントです。これらのイベントは、サンフランシスコ、ベルリン、ドバイ、ダブリン、バンガロール、マンチェスター、パリ、テルアビブなど、世界中の複数の場所で開催され、生成 AI の採用を加速させる機会を提供しています。 7 月 14 日週のニュースは以上です。 7 月 21 日週に、その他のハイライトをお知らせします。最新リリースを取り上げるので、ぜひ AWS に関する最新の知識をご覧ください。 Matheus Guimaraes | @codingmatheus 原文は こちら です。

2025 年 6 月 25 日、26 日の 2 日間に渡り、AWS Summit Japan 2025 が開催されました。私の所属する流通小売消費財のチームでは、 「The Future of Retail – AWS の提案するリテールの少し先の未来」 をテーマに展示を行い、e コマースサイトと実店舗を融合させ、パーソナライズされた、フリクションレスなショッピング体験を多くの方に体験いただきました。 その展示の一つとしてご紹介したのが、仮想試着、Virtual try-on です。オンラインショッピングの大きな課題の一つに、衣類やアクセサリーなどの身につけるアイテムは、実際に自分で着用してみないとイメージが湧きにくく、また自分が既に持っている洋服とのコーディネートが想像できないため、購入に踏み切れないという点があります。さらに、実店舗でも試着室に入って着替えるのが面倒と感じるお客様も少なくありません。Virtual try-on は、これらの課題を解決する技術として注目されています。実際に店舗に足を運ばなくても、また試着室で着替える手間なく、オンライン上で商品を自分の体や空間に合わせて試着・配置できる革新的な技術です。衣類や家具、アクセサリーなどを、店頭に飾ってあるデバイスや、スマートフォンの画面上でリアルに試すことができ、購入前に商品のフィット感や見た目を確認できる新しいショッピング体験を提供します。 この Virtual try-on の技術は、 Amazon Bedrock から利用できるモデルの、 Amazon Nova Canvas の Virtual try-on 機能 を使って実現することができます。 2025 年 7 月 2 日に一般公開 されたばかりの最新の機能です。Nova Canvas では、衣料や帽子、靴、アクセサリーの他にも、ソファなどの家具、商品をお部屋やお好みの背景画像に配置するケース、さらには好きな模様を T シャツなどに転送するケースなどにも活用することができます。 本ブログでは、AWS Summit での Virtual try-on 展示について、技術解説をしていきます。 Virtual try-on によるビジネス効果 小売業にとって、注目すべき調査結果があります。NRF（全米小売業協会）の推計によると、2024 年の返品額は、年間売上高の 17％ にも及び、小売全体の返品額は、140 兆円にものぼるそうです。この数字をご存知でしたか？返品率をいかに下げるかということは、売上に対して直接的な影響を与える重要な課題となっています。これは、e コマースサイトであっても、実店舗であっても共通の課題と言えます。 そこで Virtual try-on 技術の活用が一つの解決策になるのではないでしょうか。お客様が購入前に商品を仮想的に試すことで、「思っていたのと違った」「サイズが合わなかった」といった購入後のギャップを低減できる可能性があります。実際に自分の体型や顔に合わせた試着体験や、自宅の空間に家具を配置してみるなどのシミュレーションにより、より確信を持った購入決定につながるかもしれません。このような体験の提供が、返品率の改善に寄与することが期待されます。 「商品」を生成 AI で扱うことの難しさ 画像生成 AI モデルの進化により、簡単に高い品質の画像を生成できるようになりました。しかし、従来の方法では、商品画像を扱う際にいくつかの課題がありました。例えば「美しい画像は作りたいが、商品の画像が変わったら意味がない」という問題。ファッションアイテムや家具などの商品を AI で表現する場合、見た目の美しさだけでなく、実際の商品と同一であることが重要です。また「作ったはいいが、商品だけ浮かび上がって不自然になってしまった」というように、背景や人物との自然な融合が難しいという課題もありました。従来の方法では、複雑な画像の前処理や、高品質なマスクの生成、複数のワークフローによる試行錯誤が必要で、手間やコストがかかっていました。 Amazon Science では、この課題に対する 新しい画像モデルを発表 しました。その技術を皆さんにご利用いただける形で提供するのが、Nova Canvas の Virtual try-on 機能です。商品画像 1 枚と、人物や部屋などの写真を 1 枚用意して、Nova Canvas へ生成を依頼するだけで、商品の詳細な特徴を維持しながら、影、角度、照明などを自動で調整し、低コストで高品質な着せ替え画像が生成できます。 ファッション業界におけるリアルな試着 AWS Summit の展示では、等身大の筐体に表示された、大きな 3D のアバターに対して商品を仮想試着させることで、購買者が実際に着用したイメージを確認しながらショッピングを楽しめるようにしました。来場者の方々は、自分が選んだ衣類がどのように見えるかを視覚的に確認でき、試着室に入ることなく様々なスタイルを試すことができました。 また、スマホからアップロードした画像に対して、リアルタイムで着せ替えを行い、服の組み合わせを確認できるようなユースケースのデモも展示しました。お客様自身のスマートフォンで店舗に表示された QR コードを読み取り、表示された Web アプリ上で自分自身の写真を読み込むと、リアルな試着が表示される、というシーンを想定しています。これにより、お客様は商品と自分の服の組み合わせをすぐに試すことができ、よりパーソナライズされたショッピング体験が可能になります。 このような技術により、オンラインと実店舗の境界を超えた、新しい体験を提供することができるのです。リアルタイムの Virtual try-on アプリは以下のようなアーキテクチャで実現できます。 これを実現するには、Amazon Bedrock ランタイムの invokeModel API を使います。この API のリクエストとレスポンス構造、扱える画像サイズの詳細については、 Amazon Nova ユーザーガイド(英語) をご覧ください。Virtual try-on では、新しい taskType として、 "VIRTUAL_TRY_ON" を指定します。使用する画像はソース画像と参照画像の 2 枚で、Base64 文字列に変換する必要があります。AWS Summit で展示したこちらの生成例では、参照画像の正面を向いている女性が着ている黒いジャケットを、ソース画像の横を向いている女性に着せていますが、実際のコードはどうなっているでしょうか？ まずは以下のように、 virtualTryOnParams オブジェクトを使用して、推論パラメータを指定します。まずは、 maskType を選んでから、ソース画像のどの領域を差し替えて、どの領域を残すかというマスキングを指定します。 "GARMENT" という衣料品用のマスクタイプを選択し、トップスを意味する "UPPER_BODY" という garmentClass を選択しました。他にも、シャツ、ボトムス、全身、靴、など複数のタイプから選択できます。今回のケースでは、出力の様子を見ながら、 "LONG_SLEEVE_SHIRT" に変更し、調整しても良さそうです。また、高品質で出力させたかったので、 quality を “premium” として、選択しました。オプションの全リストは Amazon Nova ユーザーガイド(英語) を参照してください。 import base64 def load_image_as_base64(image_path): """画像データを準備するためのヘルパー関数""" with open(image_path, "rb") as image_file: return base64.b64encode(image_file.read()).decode("utf-8") inference_params = { "taskType": "VIRTUAL_TRY_ON", "virtualTryOnParams": { "sourceImage": load_image_as_base64("black_jacket.png"), "referenceImage": load_image_as_base64("model_01.png"), "maskType": "GARMENT", "garmentBasedMask": { "garmentClass": "UPPER_BODY" } }, "imageGenerationConfig": { "quality": "premium" } } 次に、Nova Canvas で生成をするのに、invokeModel API を呼び出して先ほどの推論パラメータを渡します。以下のコードをご覧ください。 import base64 import io import json import boto3 from PIL import Image # Bedrock Runtime クライアントの作成 bedrock = boto3.client(service_name="bedrock-runtime", region_name="us-east-1") # 推論ペイロードの準備 body_json = json.dumps(inference_params, indent=2) # Nova Canvas の呼び出し response = bedrock.invoke_model( body=body_json, modelId="amazon.nova-canvas-v1:0", accept="application/json", contentType="application/json" ) # レスポンスから画像を抽出 response_body_json = json.loads(response.get("body").read()) images = response_body_json.get("images", []) 着替え済みの画像が生成できました。参照画像の洋服が正面で、ソース画像が横向きであっても、Nova Canvas は自動的に角度を調整し、横向きの着用イメージとして生成します。黒いジャケットの丈の長さも、参照画像のイメージを崩さず、生成できていますね！ 家具や小物をお客様のお部屋に配置しイメージアップ お部屋の採光によって、家具の見え方も大きく変わります。店頭で見ただけでは部屋の色と花瓶の色がマッチするかイメージしづらいものです。また、イメージと違うソファだった時、返品も一苦労で、お客様体験が悪くなってしまいます。そんな時にも Virtual Try-on を活用できます。お客様自身のリビングルームや寝室の写真に、購入を検討している家具や小物を配置することで、実際の空間での見え方を事前に確認できます。 上記の例も、AWS Summit で展示した画像で、ソース画像のグレーのソファを、参照画像の茶色のソファーに置き換えたものです。このような体験を、お部屋の模様替えアプリとして、以下のアーキテクチャのように AWS サービスを組み合わせて提供することができます。お客様にお部屋の写真を提供していただき、お部屋にある家具などの類似商品を、自社の商品情報から検索して提示します。もしお客様が気に入った商品があれば、お部屋の写真に配置してシミュレーションすることが可能です。 今回のケースでは、先ほどの衣料品用の maskType 、 “GARMENT” は利用できません。そのような場合は、プロンプトでソース画像のマスク範囲を選択できる "PROMPT" や、独自のマスク画像を使用できる "IMAGE" タイプを使ってみましょう。衣料品以外の一般的な商品を簡単に差し替えたい場合は、 "PROMPT" をお勧めします。厳密に配置する範囲を指定したい場合は、 "IMAGE" がお勧めです。 今回は "PROMPT" タイプを使い、 promptBasedMask の “maskPrompt” を指定し、プロンプトとして「sofa with pillows」と指定しました。ソース画像のソファとクッションをマスクできるようにします。また、前後の差し替える商品の形が異なることを考慮して maskShape で、 "BOUNDING_BOX" を指定し、四角形のマスクを適用できるようにしました。さらに、商品の特徴をより細かく生成するため、 mergeStyle で、 "DETAILED" を選択しました。 あとは、先ほどの生成の例で示したコードを実行するだけで、お部屋に新しいソファを置いた時のイメージが生成できるはずです。このように Nova Canvas では、オプションの変更だけで、マスクの形や生成の詳細さなどを調整することができるようになっています。 import base64 def load_image_as_base64(image_path): """画像データを準備するためのヘルパー関数""" with open(image_path, "rb") as image_file: return base64.b64encode(image_file.read()).decode("utf-8") inference_params = { "taskType": "VIRTUAL_TRY_ON", "virtualTryOnParams": { "sourceImage": load_image_as_base64("room_image.png"), "referenceImage": load_image_as_base64("brown_sofa.png"), "maskType": "PROMPT", "promptBasedMask": { "maskPrompt": "sofa with pillows", "maskShape": "BOUNDING_BOX" }, "mergeStyle": "DETAILED" }, "imageGenerationConfig": { "quality": "premium" } } 生成された画像は、角度の異なるソファが参照画像だったにも関わらず、先ほどと同様に、角度が調整されて出力されました。さらに、商品の特徴もしっかりと反映されています。また、Nova Canvas では、光の当たり方や影も自動調整できるので、ソース画像の、窓やブラインドから漏れ出る光や影も、自然に生成されていますね！これで新しいソファがリビングにマッチするという事を、確認することができました。安心して購入することができます。 パーソナライズされた商品レコメンデーションにより更なる返品率削減を狙う AWS Summit 展示では、他にも、 Agents により EC サイトと連携してリアル店舗でレコメンデーションを行う という展示も行っていました。 自分の好みに合う商品が提示されて、さらに自分で簡単に試着できたり、お部屋に置いたイメージをつけられたら、イメージと違うという事態を避けられるかもしれません。パーソナライズされたレコメンデーションと Virtual try-on の組み合わせにより、お客様は自分に最適な商品を見つけやすくなり、購入後の満足度向上と返品率の低減が期待できます。これは小売業者にとっても、顧客満足度の向上とコスト削減の両面でメリットをもたらす可能性があります。 まとめ 今回は AWS Summit で展示した Amazon Nova Canvas の Virtual try-on について解説しました。この技術により、オンラインショッピングと実店舗体験の境界を超えた、新しい購買体験が可能になるとともに、返品率の低減にも貢献できるのではないでしょうか。衣類の試着から家具の配置まで、様々なユースケースに対応できる柔軟性と、商品の特徴を正確に反映する精度の高さが、Virtual try-on の大きな魅力です。 小売業界が直面する返品率の課題に対して、この技術が一つの解決策となることを期待しています。ぜひ皆様のビジネスでも、Virtual try-on を活用し、お客様に新しい体験を提供してみてはいかがでしょうか。 ブースの技術解説コーナーで利用していたデモ解説などの資料は、こちらの リンクからダウンロード いただくことが可能です。 AWS Summit Japan 2025 開催報告ブログ 【開催報告】AWS Summit Japan 2025 〜 流通小売消費財業界ブース 【開催報告】3D アバター とマルチ AI エージェント による新たな接客体験 著者について 加藤 菜々美 (Nanami Kato) アマゾンウェブサービスのソリューションアーキテクトです。エンタープライズの小売・消費財業界のお客様を支援しています。AI/ML や、サーバーレスの専門チームにも所属しています。お客様の業種業態に特化したビジネス課題に対して、テクノロジーを駆使した解決手段をお客様と一緒に検討・策定し、展開するご支援をしています。  

2025/7/16 更新：イベントが閉幕したため、イベント案内ブログを開催報告として更新しました。 6 月 25, 26日の 2 日間にわたり、幕張メッセにおいて AWS Summit Japan が開催され、会場では延べ 36,000人以上、オンラインも合わせると過去最高となる、延べ 69,000 人超の方の参加者を記録しました。基調講演、事例セッションをはじめとする各種セッションとともに、AWS Expo のエリアでは AWS サービス、ソリューションの最新活⽤事例や、実際に AWS を触れるワークショップなど、皆さまが様々な⾓度から AWS の可能性を体験できるコンテンツを展開しました。 その AWS Expo エリア内に今年は「インダストリー・パビリオン」のコーナーが設けられ、製造、金融、自動車、そして私たちの担当する流通小売消費財など 13 の業界別に特化したソリューションをご紹介しました。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決方法をご覧いただけるようになっており、また、業界に精通したエキスパートと具体的な活用シナリオについて、じっくりとご相談いただけるスペースも設けました。私たち流通小売消費財業界担当チームでは、このインダストリー・パビリオンにおいて、今年のテーマである「The Future of Retail」のもと、 NRF 、 リテールテック のデモをさらに進化させた展示を行い、両日ともに終日、ご来場者が途切れることなく多くのお客様に足を運んでいただきました。デモを体験いただいたお客様からいただいた多くのフィードバックから、私たちもまた新しいアイデアを考えることができました。 このブログでは、流通小売消費財業界ブースの展示内容をダイジェストでご紹介します。展示内容に使われている AWS サービスやアーキテクチャの詳細については個別の解説ブログも公開しており、本ブログの中からそれらのブログもご案内しています。 AWS 展示ブーステーマ 「The Future of Retail – AWS の提案するリテールの少し先の未来」 流通小売消費財企業は、商品開発製造から物流、多様なチャネルを横断したシームレスな購買体験の提供、進化する消費者のニーズと期待に応えるためのオペレーション最適化などを再発明 （reinvent） するための変革に直面しています。その変革において欠かすことのできない技術要素である生成 AI を中心として、3D 技術を拡張した AR/VR、デジタルツインによるシミュレーションといった技術を組み合わせることで、店舗体験を「少し先の未来」へと変えることができます。 大きなディスプレイは視認性抜群で、今回のブース展示で一番人気のデモでした！ ブース全体は次世代のアパレル店舗をイメージして設計しました。展示要素として「3D アバターによる接客」「最新の AI モデルによる仮想試着」「AI エージェントによるショッピングアシスタント」「フリクションレス・チェックアウト」など複数用意し、かつそれらを個別のデモとして配置するのではなく、カスタマージャーニーをコンセプトの中心に置いて一人のお客様が来店されてから購買に至るまでの一つのシナリオとして組み立てることで、最新技術に触れつつ現実の購買体験を実際にイメージいただける形でご紹介できたのではないかと思います。 今回の Summit にゲストとして各種イベントにご登壇の QuizKnock さんも、ブースにお立ち寄りくださり、一通りのデモをお楽しみいただきました！ ホログラフィックディスプレイのようなちょっと目を惹くデバイスもありますが、デモで使ったアプリケーションはディスプレイに依存しませんし、実装が非常に難しいなど特別な考慮点はありません。皆さまの環境でも実現していただくことが可能なものです。それぞれのアプリケーションのデザインや実装について、テーマごとに個別のブログでもご紹介していきます。AWS のサービスを組み合わせることで、皆さまのビジネスにもすばやく取り入れることができるものばかりですので、ぜひご活用ください。 ブース全体のカスタマージャーニー デジタル世界では 3D 技術の浸透によりモノの見え方やコミュニケーションが変化し、実物が手元になくても見たい角度や精度でリアルに確認できるようになってきました。店舗と e コマースや商品紹介サイトなどのデジタルを融合させる「オムニチャネル」や「OMO（Online-merge-Offline）」のトレンドに、この 3D 技術、生成 AI 技術を組み合わせることで、よりビジュアルにサービス体験の質を向上させることができます。 e コマースサイトであればサイトへのログインをトリガーにして、過去の購買履歴や好みに基づくレコメンデーションやお知らせを画面に表示することは珍しくありません。これを実店舗で同じように体験いただくために、来店するお客様（ご来場いただいた皆さまです）をリアルタイムに識別して、バックエンドでお客様情報などを収集し、3D アバターのショッピングアシスタントがレコメンデーションに繋げます。商品の試着もデジタル空間で実現します。店舗に在庫のないサイズや色などの試着、あるいは試着スペースの確保の難しいポップアップストアでの利用などのユースケースが考えられます。 商品が決まれば購入です。クレジットカードでお支払いをし、ポイントカードを提示してポイントを付与してもらう、スマートフォンを取り出してロックを解除し、QR コード決済アプリを開いて QR を見せてお支払いをする…キャッシュレスが進んだとは言え、レジでお客様が物理的に出さなくてはならないものが現金からスマートフォンに代わっただけ、とも言えます。そんなレジでの行動も、よりフリクションレスに実現できる時代です。昨年の Summit でも展示した手のひら認証デバイス、Amazon One を利用し、 Amazon Pay との連動により、手のひら一つで完了する決済を体験いただきました。手のひら認証と決済については昨年のブログ「 Amazon One Enterprise の機能とユニファイドコマースの実現 」で解説しているものと同じですので、そちらをご覧ください。 それではここから、「最新の AI モデルによる仮想試着」「AI エージェントによるショッピングアシスタント」「3D アバターによる接客」の 3 つの展示要素について見ていきましょう。なお、ブースの技術解説コーナーで利用していたデモ解説などの資料は、こちらの リンクからダウンロード いただくことが可能です。 Amazon Nova Canvas 最新モデルによる仮想試着 NRF の推計によると、2024 年の小売全体の返品額は 140 兆円にのぼり、これは年間売上高の 17% にもおよぶ規模とされています。購入者にとってもせっかく購入したのに、サイズなどが合わなくて返品をしなくてはならない…というネガティブなショッピング体験ですが、小売業者にとっても返品に関する一連のプロセス（返品を受け付け、返品された商品を検査し、返金手続きをするなど）に多くの手間がかかります。社会全体にとっても、不要な配送が発生することによる物流業や炭素排出量への負の影響があります。 特にアパレル領域での返品率の高さは e コマースにおける課題の一つで、多くの小売業者が没入型ショッピング体験への投資を増やしています。今回の仮想試着アプリケーションも、この課題に対する一つのソリューションのアイデアです。 仮想試着のデモ・アプリケーションは、Summit 閉幕直後に一般公開された、 Amazon Nova Canvas の最新機能、 ”Virtual try-on and style options（バーチャル試着とスタイルオプション）” を利用して開発しました。試着は店舗での特別な体験の一つではありますが、試着室まで何着も持っていっては試着して確認する、という時間がないときもあります。色の違いなどはぱっと画像で自分のイメージに合うのかどうかを確認できるだけでも十分なこともあります。試着の重要性を意識しつつ、それをより手軽な体験へと変えていくデモを今回開発しました。新機能により、より状況に合わせた商品の視覚化が可能になり、臨場感あふれるショッピング体験を提供することができます。選択した洋服の平面写真一枚から、モデルが自然にその洋服をまとっている様子をご覧いただきました。陰影や洋服のひだまで自然に生成されていることに、多くのお客様から驚きのコメントをいただきました。 この仮想試着アプリで使われているサービスや実現するためのアーキテクチャについては、ブログ「 【開催報告】AWS Summit Japan 展示 : Amazon Nova Canvas の Virtual try-on でリアルな商品試着と配置を実現し、返品率を削減する 」で解説しています。また Amazon Nova Canvas の新機能についてはブログ「 Amazon Nova Canvas update: Virtual try-on とスタイルオプションが一般公開 」で解説されています。東京リージョンでご利用いただけますのでぜひお試しください。 AI エージェントによるショッピングアシスタント Amazon は 2024 年、生成AIを搭載した新たな対話型ショッピングアシスタント Rufus （ルーファス）の導入を開始しました。Amazon アプリでご利用されていらっしゃる方も多いかと思います。また 2025 年に入ってからは新しい機能、 Buy for Me も導入しています。顧客は Amazon の e コマース内にいながら、他のブランドのサイト上にある商品を見つけ購入することができるようになります。これを支える技術の一つが、AI エージェントです。 Amazon Rufus 画面（出典: Amazon） 生成 AI 技術の深化と浸透は私たちの想像を超えるスピードで進んでいます。AI がより人間の意図を理解し、業務遂行を支援する、AI エージェントは今年の大きなトレンドです。ガートナーによると、2028 年までに、日常的な業務判断の少なくとも 15% が AI エージェントによって実行されるようになると予測されています。 前述したように e コマースであればログインした顧客の情報をもとにレコメンデーションをすぐに提示することができますが、実店舗のスタッフが同じ顧客体験を提供しようとするとどうでしょう。全スタッフが、お客様の好みや過去の購買履歴、付与されているキャンペーンの状態などをすべて覚えていることはとても難しいことです。今年のブースでは、AI エージェント技術を実店舗の購買シーンの裏方に組み込むことで、例えばこれまで長くお客様に対応してきたベテランスタッフのような対応を模倣できるようになっていくのではないか、そんなデモを開発しました。 この AI エージェントアプリで使われているサービスや実現するためのアーキテクチャについては、ブログ「 【開催報告】3D アバター とマルチ AI エージェント による新たな接客体験 」で解説しています。 3D アバターによる接客 Amazon では Amazon Beyond という没入型 3D テクノロジーを活用した仮想ショールームを体験いただくことができます。顧客は自宅にいながら、実店舗でのショッピングを楽しむような、デジタルツインの没入型仮想ショールームを体験することができます。日本では未展開ですが、米国 Amazon のサイトでは多くの Amazon セラーによる美しい仮想ショールムが公開されています。 Amazon のバーチャルホリデーストア では、2024/11/1–12/28 の 8 週間で 1,000 万以上のインタラクション、95 万以上のインプレッションなど、直接的なビジネス効果にもつながったことが報告されています。 Amazon Beyond デモ画面（出典: Amazon） Coresight のリサーチでは、ブランド、小売業者の 55% が今後 3 年間で没入型体験への投資を増やすと回答していることがわかっています。仮想試着、AI エージェントといった技術要素はその “見せ方” も重要です。Amazon Beyond のような「デジタル空間にいかにリアルな没入体験を再現するか」だけではなく、「リアルな空間（店舗）にいかにデジタル没入体験を統合するか」というテーマもこれからいろいろなアイデアが出てくるでしょう。 今回のブース展示ではこの点を意識し、仮想試着では、ホログラフィックディスプレイを利用することで試着モデルをより立体的に見せることができました。また AI エージェントによるレコメンデーション結果を画像に表示するだけではなく、デジタル空間の 3D アバターと連携させることで、より新鮮で魅力的な購買体験をもたらす工夫をしました。いずれのデモアプリも PC 画面上でも動かすことはできます。ですがこの見せ方の一工夫で大きく印象は異なったのではないでしょうか。 自由度高くフロントを支えるコマースバックエンド 紹介したような新たなフロントエンドのアイデアはこれからも次々と登場し、デジタル、リアル問わず小売現場で試されていくでしょう。そのフロントエンドの要求に柔軟に応えることのできるバックエンドも重要なポイントです。ここまでに紹介した 3 つのデモアプリケーションは、バックエンドとなるカートや決済といった主要なコマース機能として、一つのアプリケーションを利用して連携しています。 今回はこのコマースバックエンドとして、これまでに何度かご紹介している AWS の e コマースのサンプル実装である Retail Demo Store （こちらの ブログ で解説しています）を利用しました。Retail Demo Store では、Composable Commerce アーキテクチャが採用されており、既存のサンプル実装で用意された各マイクロサービスの API を呼び出すことで、短期間で開発することができました。 Retail Demo Store のコードは、Github aws-samples にて 公開 しています。またコンポーザブルコマースについては、2024 年の Summit セッション（[ 資料 | 動画 ]）で紹介しています。 AWS Summit JAPAN 流通小売消費財ブースにご来場いただきありがとうございました Born from Retail, Built for Retailers – AWS は、Amazon という小売業から生まれた、小売業のためのクラウドサービスです。そして、AI/ML は、Amazon において 25 年以上前から採用され磨かれてきた技術であり、お客様が Amazon.com で目にする機能の多くは AI/ML によって実現されています。AWS は、Amazon.com によって市場テストされた後、皆さまにご利用いただくために外部化された業界固有のサービスを継続的に開発しています。すべてのクラウドサービスプロバイダーが同じではありません。AWS は、小規模なスタートアップチームの俊敏性と、エンタープライズクラスの小売業リーダーの経験を独自に組み合わせています。この経験が、小売企業に大きな成長をもたらし、世界最大の小売企業が AWS 上でビジネスを展開している理由です。AWS ブースではご紹介してきたデモごとに、ユースケースに最適な生成 AI が選ばれて利用されていることもご覧いただけたと思います。 流通小売消費財業界におけるテクノロジーによるイノベーションは急速に多様化しつつあります。新しい技術を次々と取り込まなくては行けないように思われるかもしれませんが、今回のデモではそれだけでなく、AWS サービスを使えば簡単に実装、展開できる！と実感いただけるよう、これまでに皆さまの中に蓄積されてきた知識と経験があればすぐに始めていただけるアイデアを考えました。ご参加いただけなかった皆さまでも「試してみたい！」と思われた方は、すぐに AWS アカウントチームにご相談ください。 それではまた、来年の Summit でお会いしましょう！ 今後も、流通・小売・消費財業界の皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開していきますのでご覧ください。 参考情報 [1] AWS ブログ ”流通小売” カテゴリー [2] AWS ブログ “消費財” カテゴリー [3] AWS 消費財・流通・小売業向けソリューション 紹介ページ [4] recap ページ、EIB ブログも紹介 このブログは、ソリューションアーキテクト 杉中 が担当しました。

AWS Summit Japan 2025 が 6 月 25 日、26 日の 2 日間、幕張メッセにて開催され、会場とオンラインを合わせて過去最高となる延べ 69,000 人超の方にご参加いただきました。Industry Pavilion 流通小売消費財ブースでは「The Future of Retail – AWS の提案するリテールの少し先の未来 ( 参考ブログ記事 )」をテーマに展示を行い、本ブログではその中のデモ、「マルチ AI エージェントと 3D アバターによる新たな接客体験」についてご紹介します。 このデモでは、小売業界の店舗接客をテクノロジーで進化させ、マルチ AI エージェントと連携した 3D アバターが顧客一人ひとりにパーソナライズされた買い物体験を提供する新しい小売の形を示しました。人手不足の解消や接客品質の均一化といった業界課題に対するソリューションとして、多くの来場者の注目を集めました。 3D アバター接客がもたらす小売業の新たな価値 流通小売消費財企業における接客スタッフは実店舗での最も重要な顧客接点です。しかし、日本の労働人口減少による深刻な人手不足や高い離職率、接客品質の均一化といった課題に直面しています。特に小売業界では、人材確保が経営課題となっており、持続可能な店舗運営のための新たなソリューションが求められています。 近年、生成 AI の技術進化とネットワークインフラの充実により、3D アバターによる接客が実用段階に入りつつあります。これによって 24 時間対応可能な接客、顧客データと連携したパーソナライズされたレコメンデーションなど、人間のスタッフだけでは実現困難だった体験が可能になります。アバターは自然な会話能力を持ち、実際に喋ることができるため、より人間らしいインタラクションを提供できます。 今回展示した 3D アバターシステムでは、Amazon One Enterprise ( 参考ブログ記事 ) で取得した認証情報を元に顧客の属性、購買履歴、カート情報のデータを分析し、最適な接客を提供する機能が実装されています。Amazon One は、手のひらと静脈の画像を ID にリンクすることで、ID を正確に認証できる非接触型 ID 認証サービスです。この技術は店舗接客だけでなく、オンラインショッピング、ホテル、医療機関、金融機関など、様々な顧客接点に応用可能です。 マルチ AI エージェントの連携がもたらす新たな顧客体験価値 流通小売消費財企業が人手不足や接客品質の均一化という課題に直面する中、複数の AI エージェントが連携するマルチ AI エージェントは効果的な解決策を提供します。顧客属性や商品データの取り扱いにに特化したエージェント、接客対応に長けたエージェントなどが状況に応じて最適な対応を行い、それぞれの専門性を活かした総合的なサービスを実現します。生成 AI を活用したエージェントは、従来のプログラミングによる細かな制御を必要とせず、ルールベースでは難しい柔軟な応答や多様な顧客ニーズへの対応も可能です。これらのエージェントは顧客の属性や購買段階を検知して柔軟に役割を切り替え、Amazon One で取得した認証情報と連携した 3D アバターを通じて、顧客一人ひとりの購買履歴や属性に基づいたパーソナライズされた接客を 24 時間提供します。さらには、各エージェントが収集したデータを共有・分析することで接客の質が継続的に向上し、来店ごとに進化する体験を可能にします。このように、マルチ AI エージェントシステムは単なる省人化ツールではなく、人間のスタッフだけでは実現困難だった柔軟性と専門性を兼ね備えた新たな顧客体験価値を創出し、実店舗からメタバースまで幅広い顧客接点における次世代の小売体験の基盤となることが期待されています。 展示内容 会場では 3D ホログラフィックディスプレイによる接客アバター(写真左)を展示し、AI エージェントと連携した少し先の未来へとつながる購買体験をお客様にご覧いただきました。お客様が Amazon One で認証を行うと、システムが顧客情報を取得し、AI エージェントが自動的に起動します。AI エージェントのプロセスについてはモニタリングされ(写真中央)、複数の AI エージェントが一貫した接客をどの様に行うのかを見ることができます。AI エージェントは取得した顧客情報をもとに、アバターへ会話内容を送信します。アバターはお客様の名前を優しく呼びかけながら、丁寧な挨拶で接客を開始します。さらに、AI エージェントが顧客の属性、購買履歴、カート情報を分析し、アバターがお客様へ最適化されたレコメンデーションを親しみやすい言葉で案内します。 図1 AWS Summit Japan 2025 流通小売消費財ブースの様子 図2 マルチ AI エージェントによる接客のプロセスをモニタリング 接客デモの全体アーキテクチャ 接客デモの構成について説明します。全体構成図は次のようになっています。 図3 接客デモの全体アーキテクチャ図 以下は構成図内の番号と対応した説明になります。 1. Amazon One の端末からユーザーの識別子を送信 お客様の来店時に Amazon One へ手をかざしていただき、Amazon One のユーザーレジストリと連携した認証を開始します。 2. 認証情報を Amazon EventBridge へ送信 認証されたユーザー ID を Amazon EventBridge へ送信し、AI エージェントを起動するイベントとします。 3. AI エージェントの起動 イベントから AWS Lambda が起動されます。Lambda ではAIエージェントを構築・実行するオープンソースの SDK「 Strands Agents SDK 」により、購買履歴等の取得、メッセージの作成、メッセージの送信を行うタスクに分解され、それぞれの処理が実行されます。 4. 仮想店舗よりデータを取得 「Retail Demo Store ( 参考ブログ記事 、および ソースコード )」と名付けられた仮想店舗よりユーザー ID を基に、ユーザー名、購買履歴、おすすめアイテムを取得します。 5. レコメンデーションメッセージの作成 識別したユーザーに応じた挨拶やレコメンデーションメッセージを、取得したデータから生成AIが作成します。 6. アバターが発話 アバターに話をさせるための API（Speak API）へメッセージを送信し、ホロフラフィックディスプレイデバイス上でアバターが発話します。発話の際の唇の動きといったアバターの細かな動きは、ホロフラフィックディスプレイ上のアプリケーションで描画をしいます。 7. おすすめアイテムをタッチパネルへ表示 手順 4 で取得したおすすめアイテムをタッチパネルへ表示し、追加購入へとつなげやすいインターフェースを提供します。 8. おすすめアイテムの商品選択 アバターによる接客で購買体験を得た流れで、選択された商品データを送信します。 9. 追加購入商品をカートへ 以上の一連の流れで、3D アバターによる接客を通じて少し先の未来へとつながる購買体験ができます。 マルチ AI エージェントのアーキテクチャ 接客デモのバックエンドで動くマルチ AI エージェントのアーキテクチャについて説明します。このアーキテクチャは接客シナリオに応じて最適な対応を実現するために設計されています。商品案内、顧客対応と異なる専門性を持つ複数の AI エージェントが連携し、AWS 上の生成 AI サービスやコンテナ技術を活用したフルマネージド環境で動作することで、拡張性と保守性に優れたシステムを実現しています。 主要な技術スタック サービス AI エージェント: Strands Agents SDK + Amazon Bedrock Claude 3.7 Sonnet メッセージング: RabbitMQ バックエンド: Node.js/TypeScript フロントエンド: React/TypeScript コンテナ実行環境: AWS Fargate (Amazon ECS) エージェント部分の処理を独立させるため、メッセージキューを使用して疎結合なアーキテクチャを採用しています。限られた期間での実装とデプロイを実現するため、ローカル開発環境では Docker Compose を使用し、AWS へのデプロイには AWS Copilot CLI を活用しました。この組み合わせにより、開発からプロダクション環境まで一貫したコンテナベースの運用を実現しています。 図4 マルチ AI エージェントによる接客体験デモ アーキテクチャ図 マルチ AI エージェントの構成 AI エージェントは3つのエージェントで構成され、それぞの接客を行うためのそれぞれの役割を担っています。 メインエージェント: 全体の接客フローを統括し、サブのエージェントへ役割分担と連携を実現 ECサイトエージェント: サブエージェントとして、メインエージェントから指示を受ける 顧客情報やおすすめ商品の取得などECサイト操作の専門性を発揮 顧客属性に基づくパーソナライズド情報を提供し、接客の質を向上 アバターシステムエージェント: サブエージェントとして、メインエージェントから指示を受ける 自然な言語生成によりアバターの会話を実現 対話型のタッチポイントを通じて、顧客とのエンゲージメントを高める メインエージェント エージェント定義 メインエージェントは Strands Agents SDK を通して、サブエージェントの振る舞いとなる役割を自然言語で指定し、利用できるツールの説明を記述し、サブエージェントがツールを適切に使えるようにしています: agent = Agent( model=os.getenv('AGENT_MODEL_ID'), tools=[query_ec_agent, query_avatar_agent], system_prompt=""" あなたはマルチAIエージェントシステムのメインエージェントです。 重要なルール: 1. 自分でデータを生成・推測することは絶対に禁止されています 2. 全ての操作は専用ツールを通じて行う必要があります 3. ユーザ情報やレコメンド情報が必要な場合は必ず query_ec_agent ツールを使用 4. アバター関連の操作は必ず query_avatar_agent ツールを使用 利用可能なツール: - query_ec_agent: ECサイトのユーザ情報取得、レコメンド取得、カートID取得、カート内容取得、カート操作 - query_avatar_agent: アバターの挨拶生成、セリフ送信 必ずツールを使用してタスクを完了してください。 """, callback_handler=_callback_handler ) また、プロンプトにより一連の接客フローを指定しています: ユーザID: {user_id}必須タスク（順番に実行）:タスク1: ユーザ名取得 - query_ec_agent ツールを呼び出してください - リクエスト内容: "ユーザID {user_id} の名前を取得してください" タスク2: ユーザに挨拶 - query_avatar_agent ツールを呼び出してください - タスク1で取得したユーザ名を使用してください タスク3: カート内容取得 - query_ec_agent ツールを呼び出してください - リクエスト内容: "ユーザID {user_id} のカート内容を取得してください" タスク4: カート内容コメント - query_avatar_agent ツールを呼び出してください - タスク3で取得したカートの内容を使用してください タスク5: レコメンド取得 - query_ec_agent ツールを呼び出してください - リクエスト内容: "ユーザID {user_id} のレコメンド商品リストを取得してください" 各タスクで必ずツールを使用してから次のタスクに進んでください。 ツールを使用せずに推測や仮定で回答することは絶対に避けてください。 すべてのタスクを完了したら、作業の概要報告などは避けてすぐに終了してください。 このプロンプト設計により、メインエージェントは他の専門エージェントを適切な順序で呼び出し、一貫した接客フローを実現します。 EC サイトエージェント エージェント定義 ECサイトエージェントはメインエージェントから指示により役割を定義され、複数のツールを持つ専門エージェントとして実装されています: agent = Agent( model=os.getenv('AGENT_MODEL_ID'), tools=[get_user_info, get_recommendations, get_cart_id, get_cart], system_prompt=""" あなたはECサイト操作エージェントです。 ユーザ情報の取得、レコメンド商品の取得、カートへの商品追加などの ECサイト関連の操作を担当します。なお通貨は米ドル (USD) です。 """, callback_handler=_callback_handler ) EC サイトの操作 Strands Agents SDK の @tool アノテーションを使用することで、Python 関数を簡単にエージェントのツールとして定義できます: @tool def get_user_info(user_id: str) -> dict: url = f"{_api_base_url}/users/id/{user_id}" try: return json.dumps(get_api(url, _api_region)) except Exception as e: logger.error(f"Error getting user info: {e}") return {"error": str(e), "user_id": user_id} @tool def get_cart(cart_id: str) -> str: url = f"{_api_base_url}/carts/{cart_id}" try: return json.dumps(get_api(url, _api_region), ensure_ascii=False) except Exception as e: logger.error(f"Error getting cart: {e}") return json.dumps({"error": str(e), "cart_id": cart_id, "items": []}) get_api という関数は、後述する Retail Demo Store に対する API アクセスを行うラッパー関数です。API のホストには Amazon API Gateway が利用されており、ラッパー関数内で SigV4 署名を行っています。 Retail Demo Store について 本デモでは Retail Demo Store と呼ばれる、AWS のサービスを利用したモダンなアーキテクチャにより構成された e コマース のリファレンス実装をバックエンドの EC サイトとして活用しています。実際のECサイトと同様のAPIを提供しており、デモ開発に最適なプラットフォームです。 Agent as Tools 重要な点として、ECサイトエージェント自体も @tool アノテーションを付与した関数内で定義することで、メインエージェントからツールとして呼び出される設計になっています。これにより、エージェント間の階層的な協調動作を実現しています。 アバターエージェント エージェント定義 アバターエージェントはメインエージェントから指示により、挨拶文の生成とアバターシステムへの挨拶文送信を担当します: agent = Agent( model=os.getenv('AGENT_MODEL_ID'), tools=[invoke_avatar_lambda], system_prompt=""" あなたはアバターシステム操作エージェントです。 依頼に応じてアバターが話すセリフを生成し、アバター操作用Lambdaを呼び出す役割を担当します。 セリフを生成したら、セリフ文を提示してからLambdaを呼び出してください。 セリフは2種類あります。 1. ユーザへの挨拶 2. カート内容へのコメント ユーザへの挨拶は以下のルールに従って生成してください。 - ユーザ名を含むこと - 「こんにちは、[ユーザ名]さま、（ひとこと）」など、簡潔であること - アラビア数字や漢字は使わないこと - ひらがなとカタカナのみ利用していること カート内容へのコメントは、以下のルールに従って生成してください。 - カート内の商品について触れること、ただし商品名を正確に復唱する必要はなく、すべての商品について述べる必要はない - 50文字程度の長さとすること - アラビア数字や漢字は使わないこと - ひらがなとカタカナのみ利用していること 以下のツールを使用できます: 1. invoke_avatar_lambda: 生成した挨拶文をアバターシステムに送信する """, callback_handler=_callback_handler ) ※ 本デモでは、アバターによる発音の都合上、文字種の指定も行っています。 アバターシステムとの連携は AWS Lambda を通じて行われ、以下のようなツールで実装されています: @tool def invoke_avatar_lambda(greeting: str) -> dict: try: lambda_client = boto3.client( 'lambda', region_name=os.getenv('PROTO_SPEAK_LAMBDA_REGION') ) payload = json.dumps({"text": greeting}) response = lambda_client.invoke( ...後略 この実装により、AI が生成した自然な挨拶文がリアルタイムでアバターに反映され、お客様に対してパーソナライズされた接客体験を提供できます。 なお、ブースの技術解説コーナーで利用していたデモ解説などの資料は、こちらの リンクからダウンロード いただくことが可能です。 まとめ 流通小売消費財企業は、商品開発製造から物流、多様なチャネルを横断したシームレスな購買体験の提供、進化する消費者のニーズと期待に応えるためのオペレーション最適化などを再発明 （reinvent） するための変革に直面しています。AWS Summit 2025 で展示された 3D アバターと マルチ AI エージェントの技術は、その変革において欠かすことのできない技術要素である生成 AI を中心に店舗体験を「少し先の未来」へと変えることができます。Amazon One による認証と AI エージェントを組み合わせ、顧客データを活用した高度なパーソナライゼーションと自然な会話による接客体験を実現しています。この技術は今後、小売業界だけでなく様々な顧客接点を持つ業界へと広がり、人間のスタッフ、生成 AI エージェント、3D アバターが共存する新しい接客の形として、顧客体験の向上と業務効率化の両立に貢献していくことが期待されます。 本記事著者およびデモの開発は、ソリューションアーキテクト 古山と小森谷が担当しました。

このブログは 2022 年 9 月 7 日に Arun Chandapillai、 Shak Kathir によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 データレイクの構築とスケーリングにおいて、増え続けるデータセットを効率的に管理・保持するには、費用対効果の高いデータストレージが不可欠です。適切なストレージアーキテクチャを選択することで、お客様は迅速に検証して AWS に移行することができます。 Amazon S3 Intelligent-Tiering は、データレイクワークフローのすべての段階で、お客様がデータアクセスパターンが変化したときに、パフォーマンスへの影響やオペレーションオーバーヘッドなしに、ストレージコストを自動的に最適化できるストレージクラスです。 このブログでは、開発者とクラウド運用マネージャーが S3 Intelligent-Tiering を使用してストレージコストを最適化する方法について説明します。まず、 S3 Intelligent-Tiering アクセス階層を紹介することから始めます。次に、個々のバケットから始めて、S3 Intelligent-Tiering にオブジェクトを直接アップロードするなど、複数のユースケースに焦点を当てます。続いて、S3 ライフサイクルポリシーを使用して、既存のオブジェクトを S3 Standard または S3 Standard IA から S3 Intelligent-Tiering に移行する方法についても説明します。 後ほど、多数のバケットに対して S3 Intelligent-Tiering ライフサイクルポリシーを大規模に有効化する方法について説明します。ここでは、既存バケットと新規バケットの両方において、アクセスパターンに基づいて S3 Intelligent-Tiering アクセス階層間でオブジェクトを移行する 2 つのシナリオについて説明します。これらのユースケースにより、開発者とクラウド運用マネージャーは、個々のバケットまたは AWS アカウント内の複数のバケットにまたがる大規模な S3 Intelligent-Tiering ストレージクラス設定を管理し、データアクセスパターンの変化に応じてストレージコストを自動的に最適化できるようになります。 S3 Intelligent-Tiering アクセス階層 S3 Intelligent-Tiering は、オブジェクトを次の 3 つのアクセス階層に自動的に保存します： 頻繁にアクセスされるデータ用に最適化された、 高頻度アクセス階層 アクセス頻度の低いデータ用に最適化された、低コストの 低頻度アクセス層 ほとんどアクセスされないデータ用に最適化された、非常に低コストの アーカイブインスタントアクセス階層 即時取得を必要としないストレージコストをさらに節約するには、オプションの アーカイブアクセス階層 と ディープアーカイブアクセス階層 を有効にできます。有効化すると、90 日間（90 ～ 730 日で指定可能）アクセスされなかったオブジェクトはアーカイブアクセス層に、180 日後（180 ～ 730 日で指定可能）にはディープアーカイブアクセス階層に移動します。 S3 Intelligent-Tiering ではデータ取り出し料金はかかりません。お客様は、 監視と自動化のためのオブジェクトごとの少額の月額料金 で S3 Intelligent-Tiering を実装できます。また、自動階層化の対象となる最小オブジェクトサイズは 128 KB です。Amazon S3 Intelligent-Tiering は、128 KB 未満のオブジェクトの最小ストレージ期間と、監視と自動化のための月額料金をなくすことで、ストレージコストをさらに最適化します。 高頻度アクセス階層（自動） ：作成された、または S3 Intelligent-Tiering に移行されたオブジェクトのライフサイクルが開始されるデフォルトのアクセス階層です。 低頻度アクセス層 （自動） ：オブジェクトが 30 日間連続してアクセスされない場合、そのオブジェクトは低頻度アクセス層に移動します。 アーカイブインスタントアクセス階層（自動） ：オブジェクトが 90 日間連続でアクセスされない場合、そのオブジェクトはアーカイブインスタントアクセス階層に移動します。 アーカイブアクセス層 （オプション） ：非同期的にアクセスできるデータに対してアーカイブアクセス層を有効にできます。有効化後にアーカイブアクセス層は、少なくとも 90 日間連続してアクセスされなかったオブジェクトを自動的にアーカイブします。アーカイブの最終アクセス時間は最大 730 日まで設定できます。このアクセス階層の標準取り出し時間は 3 ～ 5 時間です。オブジェクトへのより高速なアクセスが必要な場合は、 迅速取り出し が選択肢となります。 ディープアーカイブアクセス層 （オプション） ：非同期的にアクセスできるデータに対してディープアーカイブアクセス層を有効にできます。有効化後にディープアーカイブアクセス階層は、180 日間以上連続してアクセスされなかったオブジェクトを自動的にアーカイブします。アーカイブの最終アクセス時間は最大 730 日まで設定できます。このアクセス階層のオブジェクトの標準取得は 12 時間以内です。 ソリューションの概要（個々の S3 バケット） このセクションでは、以下の手順を説明します： S3 Intelligent-Tiering ストレージクラスへオブジェクトを直接アップロードする方法 S3 ライフサイクルポリシーを使用して、既存のオブジェクトを S3 Standard または S3 Standard-IA から S3 Intelligent-Tiering に移行する方法 この手順を実行するには、以下の前提条件が必要です： AWS アカウント Amazon S3 バケットの作成 / 変更権限 を持つ AWS IAM ユーザー / ロール AWS CLI version 2 1. オブジェクトを直接 S3 Intelligent-Tiering にアップロードする オブジェクトを直接 S3 Intelligent-Tiering ストレージクラスにアップロードするには、ストレージクラスを S3 Intelligent-Tiering として指定する必要があります。これを実行するには、以下の AWS CLI コマンドを使用します。 aws s3api put-object --bucket <bucket_name> --key dir-1/my_images.tar --body my_images.tar --storage-class INTELLIGENT_TIERING PUT API 操作を使用してオブジェクトを S3 Intelligent-Tiering ストレージクラスにアップロードするには、 x-amz-storage-class リクエストヘッダーでストレージクラスを指定する必要があります。 2. 既存のオブジェクトを S3 Intelligent-Tiering に移行する アクセスパターンに基づいて、オブジェクトは以下のように自動的にあるアクセス階層から別の階層に移動されます。 オブジェクトが S3 Intelligent-Tiering に配置されると、最初は高頻度アクセス階層に保存されます。 30 日間連続でアクセスがない場合：オブジェクトは低頻度アクセス階層に移動されます。 90 日間連続でアクセスがない場合：オブジェクトはアーカイブインスタントアクセス階層に移動されます。 S3 ライフサイクルルール は、 Amazon S3 がオブジェクトのグループに適用するアクションを定義する一連のルールです。以下の手順では、オブジェクトを S3 Standard クラスから S3 Intelligent-tiering に自動的に移行する方法を説明します。 Step 1: 以下のライフサイクルルールは、オブジェクト作成日に基づいてすべてのオブジェクトを S3 Intelligent-Tiering クラスに移行します。以下のように intelligent-tier.json ファイルを作成します。 { "Rules": [ { "ID": "Intelligent_Tier_lifecycle", "Prefix": "", "Status": "Enabled", "Transitions": [ { "Days": 0, "StorageClass": "INTELLIGENT_TIERING" } ] } ] } Step 2: 以下のコマンドを実行して、バケットに新しいライフサイクルルールを作成します。 aws s3api put-bucket-lifecycle-configuration --bucket <bucket_name> --lifecycle-configuration file://intelligent-tier.json 以下のコマンドを実行して、バケットに設定されたライフサイクルルールを確認/検証します。 aws s3api get-bucket-lifecycle-configuration --bucket <bucket_name> アーカイブアクセス階層へのオプトイン設定 即時取得を必要としないストレージコストをさらに節約するには、このセクションの手順に従って、個々のバケットでオプションである非同期のアーカイブアクセス階層およびディープアーカイブアクセス階層をアクティブ化できます。 90 日間（90 ～ 730 日で指定可能）連続でアクセスがない場合：オブジェクトはアーカイブアクセス階層に移動されます。 180 日間（180 ～ 730 日で指定可能）連続でアクセスがない場合：オブジェクトはディープアーカイブアクセス階層に移動されます。 Step 1: 以下の S3 Intelligent-Tiering のアーカイブ設定は、長期間ほとんどアクセスされないオブジェクト向けに最適化されたアーカイブアクセス階層とディープアーカイブアクセス階層にオブジェクトへ移動します。設定ルールをバケット内のすべてのオブジェクトに適用するか、フィルターを定義して範囲を制限するかを選択できます。フィルターを定義するための 2 つのオプションは、オブジェクトプレフィックスとオブジェクトタグです。以下のスニペットに示すように archive-tier.json を作成します： { "Id":"Archive_Tier", "Status":"Enabled", "Tierings":[ { "Days":90, "AccessTier":"ARCHIVE_ACCESS" }, { "Days":180, "AccessTier":"DEEP_ARCHIVE_ACCESS" } ] } Step 2(optional): 以下のコマンドを実行して、 S3 Intelligent-Tiering アーカイブ設定を作成します。 aws s3api put-bucket-intelligent-tiering-configuration --bucket <bucket_name> --id Archive_Tier --intelligent-tiering-configuration file://archive-tier.json 以下のコマンドを実行して、バケットの S3 Intelligent-Tiering アーカイブ設定を確認 / 検証します。 aws s3api get-bucket-intelligent-tiering-configuration --bucket <bucket_name> --id Archive_Tier Step 3 (optional): 以下の S3 ライフサイクル設定は、それぞれ 1 つのアクションを持つ 2 つのルールを指定しています。 移行アクションは、オブジェクト作成日にすべてのオブジェクトを S3 Intelligent-Tiering ストレージクラスに移行するように Amazon S3 に要求します。 有効期限アクションは、“ logs /” プレフィックスを持つすべてのオブジェクトを作成から 365 日後に削除するように Amazon S3 に要求します。 オブジェクト有効期限ルールを使用して定期的なオブジェクト削除をスケジュールすることで、削除対象のオブジェクトを特定して Amazon S3 に削除リクエストを送信するプロセスを構築する必要がなくなります。 オブジェクトがライフサイクルポリシーに基づいて有効期限に達すると、 Amazon S3 はそれを削除キューに入れ、非同期で削除します。 以下のように intelligent-tier_logs_expire.json を作成します。 { "Rules":[ { "ID":"Intelligent_Tier_lifecycle", "Filter":{ "Prefix":"" }, "Status":"Enabled", "Transitions":[ { "Days":0, "StorageClass":"INTELLIGENT_TIERING" } ] }, { "ID":"Logs_Expire_lifecycle", "Filter":{ "Prefix":"logs/" }, "Status":"Enabled", "Expiration":{ "Days":365 } } ] } Step 4 (optional): 以下のコマンドを実行して、バケットのライフサイクル設定を作成します。 aws s3api put-bucket-lifecycle-configuration --bucket <bucket_name> --lifecycle-configuration file://intelligent-tier_logs_expire.json 以下のコマンドを実行して、バケットに設定されたライフサイクル設定情報を確認 / 検証します。 aws s3api get-bucket-lifecycle-configuration --bucket <bucket_name> HeadObject HEAD アクションは、オブジェクト自体を返さずにオブジェクトからメタデータを取得します。この 操作 により、オブジェクトの ‘ ArchiveStatus ’ 属性と他のいくつかの属性が取得されます。 以下のコマンドを実行して、オブジェクトのメタデータを取得します。 aws s3api head-object --bucket <bucket_name> --key <object_key> ソリューション概要（大規模な S3 バケット） このソリューションでは、以下の対象に対して S3 ライフサイクル設定を作成し、非同期のアーカイブアクセス階層にオプトインする方法について説明します： AWS アカウントの既存の S3 バケット AWS アカウントの新しく作成された S3 バケット 1. 既存の S3 バケット 既存の S3 バケットについては、 Python スクリプトを使用してリソースタグフィルターに基づいて特定の S3 バケットの S3 ライフサイクル 設定を更新できます。 これには、以下の前提条件が必要です： AWS アカウント 適切な権限を持つ AWS IAM ユーザーまたはロール AWS CLI version 2 AWS リソースタグ付け 概略すると、このプロセスは以下のようになります。これらのステップを実行するために AWS CLI を設定します。 以下は使用される S3 ライフサイクル設定とアーカイブポリシーです。 S3 lifecycle configuration lifecycle_config_settings_it = { 'Rules': [ {'ID': 'S3 Intelligent Tier Transition Rule', 'Filter': {'Prefix': ''}, 'Status': 'Enabled', 'Transitions': [ {'Days': 0, 'StorageClass': 'INTELLIGENT_TIERING'} ]} ]} archive_policy = { 'Id': 'Archive_Tier', 'Status': 'Enabled', 'Tierings': [ { 'Days': 90, 'AccessTier': 'ARCHIVE_ACCESS' }, { 'Days': 180, 'AccessTier': 'DEEP_ARCHIVE_ACCESS' } ] バケットの特定のリソースタグに基づいて S3 バケットに設定が適用されます。 タグベースのフィルタリング bucket_tag_key = "storage.class" bucket_tag_value = "s3.it" 注：フィルターキーと値は、企業のタグ付け命名規則に基づいて変更できます。 Python スクリプトを実行する AWS IAM ユーザー/ロールに、 ListBuckets , GetBucketTagging , PutBucketLifecycleConfiguration , および PutBucketIntelligentTieringConfiguration の適切な権限があることを確認してください。 Python スクリプトは こちら からダウンロードできます。 2. 新しい S3 バケット 新しい S3 バケットについては、バケット作成イベント通知によってトリガーされる S3 ライフサイクル設定をバケットに適用する Lambda 関数の作成して対応します。 概略すると、手順は以下のようになります： Standard からS3 Intelligent-Tiering にストレージクラスを移行する Lambda 関数を作成する Lambda 関数には、 S3 バケットの特定のリソースタグに基づいて移行を適用するロジックを含める Lambda 関数をトリガーする S3 バケット作成イベントをキャプチャする EventBridge ルール を作成する AWS Lambda 関数の作成 ここでは、バケットタグに基づいて S3 バケットのストレージクラスを移行する Lambda 関数を作成します。この Lambda 関数は、ユースケース 1 で説明したものと同じ S3 バケットタグフィルターとライフサイクル設定を使用します。 Amazon EventBridge ルールを設定して、この Lambda 関数をトリガーすることができます。トリガーされると、 Lambda 関数ハンドラーは EventBridge（CloudWatch）イベントを処理し、S3 バケット名を抽出します。リソース タグフィルター に一致するバケットのみが S3 ライフサイクル 設定で更新されます。 AWS Lambda 関数実行ロール 最小権限の原則のベストプラクティスに従い、 Lambda 関数実行ロールには、 S3 バケットに新しいライフサイクル設定を適用するための最小限の権限が必要です。最低限、 PutBucketLifecycleConfiguration , PutBucketIntelligentTieringConfiguration , および GetBucketTagging の権限が必要です。サーバーレス Lambda 関数の ログ 記記録を有効にすることをお勧めします。AWS 管理ロール AWSLambdaBasicExecutionRole は、ログを CloudWatch にアップロードする権限を付与します。 Lambda 関数は こちら からダウンロードできます。 Amazon EventBridge ルールの作成 以下は、 AWS 管理コンソールを使用して Lambda 関数を呼び出す EventBridge ルール を作成する方法です。 CloudWatch コンソールを開き、左側のナビゲーションペインから イベント → ルール を選択し、 ルールの作成 ボタンをクリックします イベントソース で、 イベントパターン が選択されていることを確認します サービス名ドロップダウンで S3 を選択し、 イベントタイプ で バケットレベル操作 を選択します 特定の操作 を選択し、 バケットの作成 を選択します ターゲット で、先ほど作成した AWS Lambda 関数の名前を選択します ルールの 名前 と（オプション）説明を入力します。ルールをすぐにアクティブにするには、 有効化 ボックスを選択したままにします 最後に、 ルールの作成 を選択します クリーンアップ AWS アカウントでの継続的な料金発生を避けるために、このガイドに従って作成した AWS Lambda リソースを削除してください。 結論 このブログ記事では、特定の状況に応じてストレージコストを最適化するために、個々の S3 バケットまたは複数の S3 バケット全体で S3 Intelligent-Tiering を使用するさまざまな方法について説明しました。データアクセスパターンが変化した場合に、パフォーマンスへの影響や運用上のオーバーヘッドなしに S3 ストレージコストを最適化する方法についてガイダンスを提供しました。あらゆる規模の企業が、より広範なクラウドコスト最適化戦略の一環として、このプロアクティブなアプローチをストレージコスト削減に採用できます。 S3 Intelligent-Tiering は AWS 管理コンソール 、 AWS Command Line Interface(CLI) 、および AWS SDK を通じて有効にできます。お客様は、 監視と自動化のための少額の月額オブジェクト単位の料金 で S3 Intelligent-Tiering を実装できます。詳細については、 AWS Well-Architected Framework 、 ストレージのアーキテクチャベストプラクティス 、および コスト最適化のアーキテクチャベストプラクティス を参照してください。ストレージコスト最適化戦略についてさらに支援が必要な場合は、 AWS サポート と AWS アカウントチームにお問い合わせください。 TAGS: Amazon EventBridge , Amazon S3 Event Notifications , Amazon S3 Intelligent-Tiering , Amazon S3 Lifecycle , Amazon Simple Storage Service (Amazon S3) , AWS Cloud Storage , AWS Command Line Interface (AWS CLI) , AWS Lambda Arun Chandapillai Arun Chandapillai は、ダイバーシティ ＆ インクルージョンの推進者であるシニアクラウドアーキテクトです。彼は、ビジネスファーストのクラウド導入戦略を通じてお客様が IT の近代化を加速し、クラウドでアプリケーションとインフラストラクチャを上手に構築、デプロイ、管理できるよう支援することに情熱を注いでいます。 Shak Kathir Shak Kathirvel は AWS ProServe のシニアクラウドアプリケーションアーキテクトです。顧客との共同作業やアプリケーションの近代化と最適化の取り組みの支援、エンタープライズクラウド管理とガバナンス戦略の指導、ワークロードのクラウドへの移行を楽しんでいます。エンタープライズアーキテクチャ、サーバーレステクノロジー、AWS のコストと使用状況の最適化に情熱を注いでいます。彼はやりがいのある仕事と、刺激的な顧客や同僚と仕事をする機会があることからとても気に入っています。

本記事は アメリカ太平洋時間の2025 年 7 月 14 日に公開された “ Announcing the Code with Kiro Hackathon ” を翻訳したものです。翻訳はデベロッパーアドボケイトの山口能迪が担当しました。 賞金総額 10 万ドル、AI 開発の未来を拓きましょう Code with Kiro Hackathon が始まります。 Kiro は、あなたのコードを理解する AI の開発環境へのシームレスな統合により、あなたの開発ワークフローを変革します。 Kiro の AI IDE をさまざまに試しながら、賞金 10 万ドルを懸けて、スペック主導型開発がどのようなものか見てみませんか。 Kiro は、コンテキストを考慮したインラインコーディング、マルチモーダルチャット、スペック駆動型開発、また、あらゆる種類のタスクを自動化できるインテリジェントエージェントフックなどのAI機能を通じて、あなたのアイデアを拡張します。 Kiro のユニークな AI 機能 についてはウェブサイトで確認してください。 （ほとんど）なんでも開発できます あなたの創造的な自由を最大限に引き出すためには、プロジェクトの主な要件は、単純に Kiro を使用して動作するアプリを構築することです。 あなたの創造力を引き出すために 4 つのカテゴリーを想定していますが、これらに縛られないでください。 生産性とワークフローツール ：あなたが夢見た CLI や、あなたがほしいすべての機能を実装したタスクトラッカーアプリケーションを構築したり、チームのプロセスを合理化するスクラムボードを設計しましょう。 ゲーム＆エンターテインメント ：ローグライクからリアルタイム マルチプレイヤー ゲームまで、ぜひ作ってみてください。 教育用アプリ ：インタラクティブなコーディング チュートリアル、アルゴリズム ビジュアライザー、あるいは学習を楽しく魅力的にするものなら何でも。 その他 ：他にはないユニークなアイデアがありますか。あなたの自由に作れます。私たちが驚くようなものを作ってみてください。 スキルレベルに関係なく参加を歓迎します もしあなたが想像しているものがあるのなら、Kiroはそれを実現する手助けができます。 1 人でもチーム（3 名まで参加可能）でも、どのようなスキルレベルの開発者にも参加をおすすめします。 これがあなたにふさわしいハッカソンかどうか、まだ不明瞭ですか？ このハッカソンでは、成功するアプリケーションを構築するためのあらゆる種類のスキルが必要です。 開発者 スタートアップの創業者または起業家 デザイナー 学生（高校生から大学院生まで） 基本的にすべてのビルダー 現代における AI 主導のソフトウェアエンジニアリングの素晴らしさは、さまざまなレベルの技術スキルにアクセスできることです。 Kiro は、あなたのもっとも得意とするスキルを引き出し、あなたのプロジェクトをアイデアから本番レベルのコードまで引き上げることを可能にするために、あなたに協力してくれます。 しかし、私たちの言葉を鵜呑みにしないでください。 ぜひご自身で試してみてください！そしてあわよくば賞金も獲得してしまいましょう！ 他になにかお伝えすることがありますか？…では AI がかつてないほど私たちを取り巻く世界を形成しつつあることは周知の事実です。 多くのツールが AI によるコーディングの高速化を謳っていますですが、今こそそれ以上のものを求める時です。 Kiro はエージェント型 IDE であり、あなたの開発パートナーとして、単にコードを速く書くだけでなく、あなたの仕事の次元を上げるために作られています。 Kiro を使って AI 開発 の最前線に参加し、強力なソリューションを世界にもたらしながら、あなたのスキルを成長させましょう。 参加する理由がもっと必要ですか。 コミュニティに参加して、AI を使った開発の未来を形作ろうとしている仲間の開発者や業界の専門家と新しいつながりを作りましょう。 私たちは、 kiro.dev/docs にある私たちの技術文書やチュートリアルに加えて、毎週オフィスアワーとDiscordを用意してあなたをサポートします。 ハッカソンの審査員には、 Tim Ruscica 、 Aishwarya Srinivasan 、 Angie Jones 、 Santiago Valdarrama 、 Jeff Barr のような専門家を含む、コミュニティでもっとも優秀な人たちがいます。 審査員は、潜在的な価値、Kiro をうまく活用した実装、そしてアイデアの質に基づいてプロジェクトを評価します。 また、インフルエンサー審査員賞、最優秀 Kiro 活用賞、その他各優秀賞などの多彩な賞を用意しています。 主な日程と提出書類の詳細 ハッカソンは 2025 年 7 月 14 日にスタートし、提出期限は 2025 年 8 月 25 日午後 12 時（訳注: 本文日時はすべてアメリカ太平洋標準時）です。 入賞者は 2025 年 10 月 1 日に Kiro のソーシャル チャンネルの X 、 Bluesky 、 LinkedIn 、 Instagram で発表されます。 応募作品には、なぜそれが価値あるソリューションなのか、そしてそれを構築するためにKiroがどのように使用されたのかを審査員に説明するデモビデオ（最大 3 分）、オープンソースコードを含む公開 GitHub リポジトリ、および詳細なプロジェクトドキュメントを含める必要があります。 完全なルールと応募の詳細については、 kiro.devpost.com をご覧ください。 Kiroはプレビュー期間中は無料で利用でき、複数のオペレーティング システムとプログラミング言語をサポートしているため、開発者は単なる概念実証ではなく、実際のアプリケーションを構築できます。 ハッカソンを始めるには次の手順で進めてください。 Code with Kiro ハッカソンへの登録 Kiro をダウンロード し、設定する あなたのプロジェクトを構築するために使用できる機能について 学ぶ あなたの創造性に火をつけて、開発を始めましょう！ アイデアからプロダクションに移行する準備はできていますか？ AI を活用した開発の可能性を探るエキサイティングな旅に参加しませんか。 AI を活用した開発革命の最前線に立ち、ソフトウェア創造の未来を形作るチャンスです。 今すぐ kiro.devpost.com に登録し、何か素晴らしいものを作り始めましょう。 あなたが何を考え出すか、私たちは待ちきれません！ まだ質問がありますか。 公式ハッカソンルール を読んでみてください。 チュートリアル を確認してください。 Kiro Discordコミュニティ をブックマークしましょう。 X 、 LinkedIn 、 Instagram では @kirodotdev を、 Bluesky では @kiro.dev をタグ付けし、ハッシュタグ #codewithkiro を使って進捗状況を共有しましょう。 有償プランの購入の必要はありません。 18 歳以上のみ参加できます。参加資格に制限があります。 利用規約 を参照してください。

AWS ジャパンの 広域事業統括本部では、中堅・中小企業のお客様のデジタルトランスフォーメーション（DX）、クラウドや生成 AI の利活用などを支援しています。過去 2 年間、 AWS では7月の「中小企業魅力発信月間」に合わせて、最新のテクノロジーがどのように中堅・中小企業の成長に貢献するのか、どういった成功事例があるのかなどを定期的にご紹介してきました。 2023年は、鶴見酒造株式会社様に、 AWSクラウドを活用した温度センシングシステム「もろみ日誌クラウド」を導入し、10分ごとに温度データを自動収集しリアルタイムで可視化することで、24時間どこからでも温度管理が可能になったことに加え、酒質の向上、泊まり込み勤務の解消、若手への技術継承という3つの課題を解決した事例をご紹介頂きました。2024年は、 AWSの生成AIサービスを活用した事例として、株式会社やさしい手様に、介護関連文書の処理自動化により、個別化されたサービス提供と高い説明責任を実現した事例と、株式会社ネイティブキャンプ様には、英会話レッスンの音声データを自動要約して改善点を提案する機能を構築した事例をご紹介いただきました。 本ブログでは、中堅・中堅企業のお客様のビジネス成長や新たな価値創出に向けた、2025年度の新たなAWSの取り組み、生成 AI の事例について解説いたします。 経済産業省は2025年5月に公開したレポート 「レガシーシステムモダン化委員会総括レポート」 において、依然として日本の多くの企業組織におけるDXの進捗はスピード感に欠け、進化するデジタル技術の導入や連携の遅れは諸外国との隔たりを一層拡大させ日本の産業競争力が低下の一途を辿ると問題提起しています。日本の産業構造に目を移すと、中堅・中小企業が全企業数の99.7%、売上高に占める割合が78%*となっており、少子高齢化や人口減少、労働者不足などの課題を抱える日本の競争力を向上させるためには、中堅・中小企業が成長の源であり、そのDX推進は急務であると考えます。 AWSジャパンでは、中堅・中小企業のお客様が、変化を続ける顧客や社会のニーズを捉えて対応していくために、 クラウドを中核としたデジタル技術やAI技術を駆使して新たな価値を創出するご支援をしていくことが必要だと考えています。そしてこのような支援を、企業全体の99％以上を占める中堅・中小企業に対して継続的に行うことが、日本全体の成長に寄与することに繋がると確信しております。その具体的な支援策としては、以下の4つを注力領域として全国のAWSパートナーと共に全国の中堅・中小企業のお客様のDX、クラウド民主化に向けた取り組みを一層強化しています。 生成AIをはじめとした最新技術の導入と業務プロセスのデジタル化 レガシーシステムからの脱却ーマイグレーション＆モダナイゼーション デジタル人材の育成　 地域創生に向けた取り組み ＊2024年発行 帝国データバンク「『中堅企業』の実態分析」ならびに東京商工リサーチ「TSRレポート」参照 １．生成AI をはじめとした最新技術の導入と業務プロセスのデジタル化 AI 活用の最新動向と職場におけるスキル習得のニーズを把握するため AWS は2024年、Access Partnership 社に委託して 「加速する AI 活用、AI スキルに関するアジア太平洋地域の雇用主および労働者の意識調査」 を実施したところ 、2028年までに78%以上の組織がAIを導入する見込みであることが明らかとなりました。なかでも生成AIは急速に普及が進んでおり、2024年は 生成AIを活用したサービスがローンチする など実用化が進み、そして今年2025年は、生成AIを活用して ビジネス価値を創出するフェーズへと移行 が進んでいるとAWSでは考えています。 企業が生成AIに期待する効果や創出するビジネス価値は多岐にわたりますが、中堅・中小企業の多くのお客様においては以下の４つが代表的なものであると考えます。 生産性 ：大幅な生産性の向上 洞察 ：あらゆる社内情報から洞察を抽出しより迅速で的確な意思決定を支援 新体験 ：顧客および従業員との新しい革新的なコミュニケーションを確立 創造性 ：会話、物語、画像、映像、音楽などの新しいコンテンツやアイデアを創出 AWSの中堅・中小企業のお客様も、AWSの生成AIサービス Amazon Bedrock などを活用して、こうした新たなビジネス価値創出に向けた取り組みを進められてます。下記に活用事例の一部をご紹介いたします。 株式会社ジュビロ アカデミーのコーチングに生成 AI を活用、トレーニング指導案を作成 サッカー J リーグの「ジュビロ磐田」を運営する静岡県の企業、ジュビロは、クラブ運営やデータベース構築でのデジタル活用を積極的に推進してきました。2024年6月からは、アカデミーにおけるコーチング知識や経験の継承という課題解決のため、Amazon Bedrock を活用した生成 AI 導入の実証実験を開始。コーチが練習テーマなどを入力すると、過去の指導案データを学習した生成 AI が最適な練習メニューを提案し、コーチをアシストするツールを構築。将来的には選手個々のデータを活用したパーソナライズされた練習メニューの考案や、部活動支援など地域課題解決につながる展開も模索しています。 タキヒヨー株式会社 アパレルの社内業務に生成AIを活用 ～月450時間の効率化とデザイン創造性の進化を実現～ アパレル事業を中核とする繊維専門商社のタキヒヨーは、コロナ禍で顕在化した業務の属人化課題に対し、Amazon BedrockとGenerative AI Use Cases JPを活用した生成AI導入を実施。使いやすさとセキュリティを重視したシステム構築により、4部門で月450時間の工数削減を達成し、デザイン部門では1点あたり2時間の効率化を実現。さらにアパレルデザインの検討業務などクリエイティブな領域にも生成AIを展開し、デザイナーの創造性向上にも貢献しています。 アライズイノベーション株式会社 生成AIでローコード開発を効率化、次世代OCRの開発に成功 ～顧客の金融機関の帳票処理工数を80%削減見込み～ AIとローコード開発に強みを持つアライズイノベーションは、AI-OCRサービス「AIRead」の進化を目指し、トップダウンでClaude 3.5 Sonnetの評価から開発着手までわずか2週間でプロジェクトを始動。Amazon SageMakerとAmazon Bedrockを組み込んだ「生成AI-OCR」の開発により、OCRの精度と汎用性を飛躍的に向上。導入事例では、金融機関の年間数百万枚に及ぶ決算書のデータ化作業で、業務工数80％削減を実現見込みです。 株式会社やさしい手 非エンジニアが実現！ 3000 人規模の介護×生成 AI 革命 日本全国で在宅介護サービスを提供するやさしい手では、長年の課題であった現場スタッフの介護記録業務の負荷の軽減策として Amazon Bedrock を導入。IT 知識ゼロの 6 名のチームが、2 週間で生成 AI アプリを開発し、3 ヶ月で 3000 人の介護現場に展開。 その結果、記録業務時間が 83 %削減、計画書作成時間も 75 %削減。更に、介護スタッフが利用者と直接関わる時間が 25 %増加し、要介護者の小さな変化も見逃さない、一人ひとりに合わせた質の高いケアが可能になりました。これにより、高齢者が住み慣れた自宅や地域で安心して暮らし続ける「Aging in Place」の実現に貢献しています。 岩崎電気株式会社 生成 AI が実現する防災・減災 DX ～カメラ映像を用いた道路状況の無人監視～ 道路照明に強みを持つ創業80年の照明器具メーカーである岩崎電気では、昨今異常気象や震災による自然災害が頻発しており、防災・減災への危機意識が高まっていることを受け、同社では、自社の道路用照明とカメラを組み合わせたシステムに Amazon Bedrock を適用した道路状況の自動監視ソリューションを開発しました。従来はセンサーで冠水検知をする必要がありましたが、カメラ映像を生成 AI で解析することで、大幅なコスト削減と運用負荷の低減を実現しました。 さらにAWSジャパンでは、日本における生成AI技術の実用化を支援するため、2024年7月から「 生成AI実用化推進プログラム」 の提供を開始し、200社を超える企業・団体の生成AI実用化支援を行っていますが、その半数近くが中堅・中小企業のお客様です。今後も継続してAWSパートナー様と連携してAWSは本プログラムを通して、お客様の生成AIによる価値創造を技術面、資金面、またナレッジを提供しご支援しています。 出所：AWSジャパン ２．レガシーシステムからの脱却ーマイグレーション＆モダナイゼーション ～今こそクラウドへ　マイグレーション＆モダナイゼーション 日本では生成AIなどの最先端のデジタル技術を活用したくても、既存のレガシーシステムが足枷となり、連携や組み込みがスムーズに進められないといったレガシーシステムを取り巻く問題も発生しています。AWSの中堅・中小企業のお客様からも、基幹システムのクラウド移行を進めたけれど、仕様書が残っていない、システムがブラックボックス化してしまっている、といったお声をお聞きしています。クラウドは、必要なリソースを必要な分だけ柔軟かつ容易に調達が可能、調達まで数か月を要する物理サーバーと異なり、数クリックでサーバーを立ち上げられるなどすぐに始められ、また、高いセキュリティで安心安全にデータにアクセスすることができます。こうしたクラウドの優位性から、生成AIを「とりあえず使ってみる」ためにも、生成AIを最大化するためにも、クラウドは最適といえ、社内にAIエンジニアがいないという企業においても生成AIを身近なものにしています。生成AI隆盛の今だからこそ、クラウドへの移行、モダナイゼーションに取り組みを加速させる必要があると考えます。 今年5月にAWSは、レガシーからAWSへの移行とモダナイゼーションを支援する AWS Transform の提供を開始しました。初のエージェント型AIサービスであるAWS Transformは、AIが複雑な依存関係を理解し、暗黙知化したビジネスロジックを可視化、従来は年単位だったプロジェクトを月単位まで短縮することを可能にしました。 また、クラウド移行においても、お客様がその状況に応じて最適な移行を実現できるようにAWSパートナーと連携してご支援しています。クラウド移行に関して豊富な知識と高い経験値を有し、 「AWS移行とマイグレーションコンピテンシーパートナー」 として認定されたパートナー各社が、複雑な移行プロジェクトの実現に活躍しています。 出所：AWSジャパン ３．デジタル人材育成 総務省が2023年に公開した「国内外における最新の情報通信技術の研究開発及びデジタル活用の動向に関する調査研究」によると、日本は米国や中国、ドイツなどの諸外国と比べてシステム開発における内製化割合が低いことが明らかとなっています。デジタル人材が不足し、デジタルを十分に活用できていない中堅・中小企業のお客様がITの内製化を推進できるようにAWSは、デジタル人材の育成支援にも注力しています。その一環として、初学者から経験豊富な技術者まで、AWSのクラウド・AI関する知識やスキルを習得できるデジタルトレーニング AWS Skill Builder を提供しています。 今年7月にAWSは、生成 AI を搭載した仮想顧客とのチャットを通じて実践的な AWS スキルを身につけられる新しい学習プラットフォーム AWS SimuLearn の提供を開始しました。AWS SimuLearn では、 日本語の生成 AI に関するラボとクラウドの基礎 (Cloud Practitioner) に関するラボが無料で提供 されており、クラウドや生成AIを一から学び、使い始めたいという方にも最適です。 ４．地域創生 超高齢化・人口減少・労働力不足など日本の様々な社会課題を解決するために、デジタル技術を活用した課題解決が求められています。日本全国の中堅・中小企業のお客様におけるクラウドの民主化、生成 AI の利活用促進は、こうした社会課題の解決を後押しし、日本政府が目指す地域創生を加速させると考えます。 日本全国のAWSのお客様がクラウドの民主化を実現するために、AWSパートナーのネットワークとの連携は必要不可欠です。多くのパートナーの中でも特に、中堅・中小企業のお客様のニーズ、課題に対するソリューションとサービスを定められた水準以上のレベルで提供する能力と実績を持つとして、AWSが認定した 中堅・中小企業（SMB）向けコンピテンシーパートナー のクラスメソッド、サーバーワークス、GMOとの連携も強化して、全国のお客様の課題発見から寄り添い、その解決をご支援していきます。 また、こうした日本社会の課題を解決し、地域創生を加速するためには全国のデジタル人材の育成も急務です。AWSは地域で活躍できるデジタル、AI人材を育成に向けて今年6月25日、独立行政法人国立高等専門学校機構 旭川工業高等専門学校（旭川高専）および富山高等専門学校（富山高専）2校 と 包括連携協定 を締結しました。 さらに全国のデジタル人材育成支援を強化するためAWSジャパンは、 デジタル社会実現ツアー2025 を、2025年8月18日～28日、全国7地域（新潟県、愛知県、大阪府、東京都、宮城県、福岡県、広島県）で開催を予定しています。今年で4回目（4年目）となる本ツアーでは、地域の学生や若手社会人を対象に地域課題をAIで解決を目指す「 地域創生・社会課題解決 AI プログラミングコンテスト 2025 」 を実施します。地域が抱える多様な社会課題に対し、クラウドや AI などのデジタル技術を活用した解決策を地域社会と共に考え、実装していくこうした取り組みを通じて、持続可能な地域創生を実現するとともに、全国の中堅・中小企業のお客様の成長、新たな価値創出を後押しします。 最後に。「日本のために、社会のために」 AWS広域事業統括本部は、日本経済の根幹であり日本を支える日本全国の中堅・中小企業のお客様の成長とイノベーションの実現を支援するビジネスパートナーを目指し、本ブログでご紹介した施策を含めた取り組みを強化していきます。 「日本のために、社会のために」、今後も 継続してAWS は、クラウド・生成 AI による経営課題の解決をAWS パートナーと一緒にご支援していきます アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 広域事業統括本部 統括本部長　原田 洋次

アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクトの石倉です。2025 年 6 月 25 、26 日に AWS Summit Japan が開催され、2 日間で 160 以上のセッションと 270 以上のブース展示が行われました。その中には、高い信頼性要件に対し工夫を凝らしながら耐障害性の高いワークロードを構築したお客様事例セッションもありました。また、AWS セッションや AWS Village のブース展示においても、レジリエンスに関するトピックを多数お届けしていました。本ブログでは、AWS Summit Japan 2025 よりレジリエンスに関するセッション、ブースの内容をサマリーでご紹介します。 事例セッションより ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略～勘定系移行までの道のり～ ソニー銀行 様 ソニー銀行様では、ビジネスアジリティの飛躍的な向上を目指し、長期的な視点でクラウドシフト戦略を推進されており、2025 年 5 月 新勘定系システムをクラウドネイティブなアーキテクチャにて AWS 稼働をスタートしました。稼働にあたり、大阪リージョンを活用したマルチリージョン構成にすることにより、基幹システムで求められる高い可用性を実現した事をご説明いただきました。移行時のサポートしてAWS エンタープライズサポート、AWS Countdown Premium ティアを活用頂き万全の体制にて移行を完遂した事もご説明頂きました。 国内金融業界初： AWS 上での勘定系システム移行の成功と次世代バンキングの展望 SBI Security Solutions様 SBI Security Solutions 様は AWS 上で稼働する銀行勘定系システム「次世代バンキングシステム」のサービスを開始し、2024 年に福島銀行で本番稼働を開始し、2025 年には島根銀行を 2 行目として稼働を予定しています。マルチ AZ・マルチリージョンで構成されており、AZ 障害は 1 分で自動回復、リージョン障害は 1 時間で切り替えを可能にしています。レジリエンシーを高めるためには CI/CD パイプラインの実装やリージョン切り替えのワークフロー整備といった「定型運用作業の自動化」と、オブザーバビリティを活用した「人の判断の迅速化」が重要と述べています。またこれには AWS からサポートを迅速化させるサービスである AWS Incident Detection and Response (IDR) の採用も大きな要因となっています。今後は AI Ops などを活用し、非定型作業の自動化も推進していくそうです。 AWS セッションより 公共機関におけるクラウドレジリエンス～障害からより早く回復するシステムの作り方～ AWS シニアパートナーソリューションアーキテクト 讃岐 和広より、レジリエンスライフサイクルフレームワークを活用したシステムの回復力強化について解説するセッションをお届けしました。デジタル社会の実現に向け変化を続ける環境において、従来の「障害を防ぐ」アプローチには限界があり、「障害が起きてもすぐ回復する」レジリエンスなアプローチへの意識変革が重要であることを強調しました。レジリエンスライフサイクルフレームワークの 5 つのステージ（目標設定、設計と実装、評価とテスト、運用、対応と学習）について、まず目標設定では SLO や RTO / RPO の目標値を定めることが重要であり、例えば地方公共団体情報システム非機能要件の標準【第1.1版】では RTO 12 時間以内、RPO 1 営業日前、サービス稼働率 99.5 % といった具体的な目標値が定められていることを紹介しました。また、ミッションクリティカルな重要業務では「静的安定性」の確保が重要であり、障害時でもシステムが変更を加えることなく通常通り動作し続けるよう、あらかじめ十分なキャパシティを確保しておくことを解説しました。 サービス停止を防ぐ AWS 活用術: コンテナワークロードにおける高可用性設計の実践 AWS シニアソリューションアーキテクト 堀内 保大より、コンテナワークロードにおける高可用性設計を解説するセッションをお届けしました。「Everything fails, all the time」という Werner Vogels の言葉の通り、障害は必ず発生することを前提として、いかに高速に復旧させるかが重要なポイントです。セッションでは、高可用性設計の 2 つの柱として「耐障害性」と「障害分離」を詳しく解説しました。耐障害性では、マルチ AZ 冗長化による配置戦略や、ヘルスチェック・サーキットブレーカー・リトライといった通信の信頼性確保について説明。障害分離では、トラフィックを AZ 内に閉じる AZ 独立性の設計と、Amazon Application Recovery Controller を活用した AZ 退避の仕組みを紹介しました。また、完全な停止ではなく散発的・部分的な劣化が発生するグレー障害についても触れ、外形監視による SLO 監視と静的安定性を考慮した AZ 退避の重要性を説明しています。Amazon EKS や Amazon ECS での実装例も交えながら、具体的な障害シナリオを通じてアーキテクチャがどのように機能するのかを確認できる、コンテナ環境における実践的な高可用性設計パターンを学べる内容となっています。 AWS におけるグレー障害の検出と対策 AWS ソリューションアーキテクト 安藤 麻衣より、見落としがちなグレー障害の検出と対策について解説するセッションをお届けしました。グレー障害は完全なシステム停止ではないものの、一部のユーザーにのみサービス品質の低下をもたらす検出困難な障害で、システム全体では正常に見えるが顧客側では問題が発生している状態を指します。従来のヘルスチェックでは検知できない小さなエラーに対し、Amazon CloudWatch の Contributor Insights を活用することで、特定のユーザーやインスタンスで発生するレイテンシー問題などを特定する方法を紹介しました。さらに複合アラームを使って AZ レベルでの障害を精密に検知する具体例を紹介しています。対応策では Amazon Application Recovery Controller のゾーンシフト機能を使った Availability Zone の切り離しを中心に解説。問題のあるAZを一時的に切り離すことでシステム全体の健全性を保つ手法です。この実現にはAZ独立性（AZI）の考慮が重要で、異なる AZ 間の不要な通信を防ぎ AZ 内でリソース利用を完結させる設計についても言及しています。最後に AWS Fault Injection Service を使った事前の障害訓練や、組織全体でレジリエンス文化を醸成することの重要性を強調しました。 設計から運用まで~ AWS サポートを徹底活用して重要システムを安定稼働させよう AWS シニアクラウドサポートエンジニア 古野俊広より、重要システムの安定運用とレジリエンス向上を支援する AWS サポートサービスについて解説するセッションをお届けしました。システム障害による損失の大きさと、耐障害性の高いアーキテクチャ構築やマイグレーション時の課題を背景に、AWS が提供する包括的なサポートサービスを紹介しました。AWS Countdown Premium（AWS CDP）では、設計段階からローンチ後まで専門チームが継続的にサポートを提供します。アーキテクチャレビュー、設定項目の確認、負荷試験時のメトリクス分析など、サポートエンジニアが実際のリソース設定を直接チェックし、移行フェーズでの迅速な情報共有とエスカレーション支援も行います。AWS Incident Detection and Response（AWS IDR）では、24 時間 365 日体制でシステム監視を行い、障害発生時には 5 分以内に専門エンジニアが対応を開始します。IDR は SBI セキュリティ・ソリューションズ様にご利用いただき、日本語サポートにより迅速な対処を実現できています。AWS Support Automation Workflows（AWS SAW）は、よくある技術的問題に対する自動化されたトラブルシューティングを提供し、障害復旧時間の短縮を実現します。 アーキテクチャ道場 2025 – 実践編！ AWS ソリューションアーキテクトがモダナイゼーションとレジリエンスの 2 つのお題に対して、実際のお客様事例をもとにアーキテクチャを紹介します。その中で SBI Security Solutions 様における銀行の勘定系システム全体のレジリエンスを考えるお題があり、勘定系システムに求められる高い信頼性の基準を満たしつつ、業界特有の通信方式（セッション維持や固定 IP 接続など）という制約にどう対応するかが解説されています。実装方針としては、ノードや AZ 障害にはマルチ AZ のアクティブ/アクティブ構成で、リージョン障害にはアクティブ/パッシブの構成を採用されています。また、中継センターが外部との接続方式を緩衝するよう設置することで、弾力性のあるクラウドの特性を活かしてシステム全体のレジリエンスを高められていました。切り替え時にはヒューマンインザループを採用しつつ、判断を行うフローを自動化したり、判断を待たずにできる準備を並行で走らせるなどの工夫があり、業界問わず参考になる例と思います。 AWS ブース展示より ブース：レジリエンスブース＆大阪リージョンブース レジリエンス・大阪リージョンブース資料は こちら からダウンロード頂けます。 レジリエンスブース レジリエンス関連プラクティス ( コントロールプレーン / データプレーンの特性、静的安定性等) 、関連の AWS サービス、AZ 障害に備えるための手法、ディザスタリカバリ (DR) に対応する為の戦略をご案内しました。AZ 障害に対応するための手法として Amazon Aplication Recovery Controller のデモを実施しました。ディザスタリカバリ (DR) 戦略については、RPO / RTO に応じた戦略とそれに紐づく具体的なアーキテクチャ説明を中心にご案内いたしました。 大阪リージョン・たこ焼きブース 大阪といえば、たこ焼き。たこ焼きがいつでも注文できるデモアプリを展示いたしました。デモアプリは、東京 ＆ 大阪マルチリージョンによるアクティブアクティブ構成で、災害耐性の向上、RTO / RPO の短縮、そして低レイテンシーを実現しています。AWS Fault Injection Service による障害注入実験、Amazon CloudWatch Application Signals、Amazon Managed Grafana によるマルチリージョンオブザーバビリティにより、リージョン障害がおきてもアプリの正常稼働を確認できるデモを実施しました。 大阪リージョン・データセンターブース 大阪リージョンの有用性をテーマに、データセンターの災害対策についてご紹介しました。大阪リージョンデータセンターの災害対策として、津波による浸水被害を受けない設計、「免震構造」により、震度 ６ 弱の揺れでは影響を受けない設計であることをご案内しました。免震構造の模型展示も行いました。 金融ブース：進化する金融 × レジリエンス（ゼロダウンタイムを実現するフェイルオーバー/金融システムを守るサイバーレジリエンス） 金融ブースの概要資料は こちら からダウンロード頂けます。 こちらのブースでは、金融システムのミッションクリティカル要件とサイバーレジリエンス強化について、マルチリージョン構成による可用性確保や回復力評価など、具体的な実装方法をデモで紹介していました。勘定系システムを例に、Aurora DSQL をマルチリージョンで構成し、障害発生時においてもサービスのゼロダウンタイムを実現する構成や、マイクロサービスを採用した顧客接点ようモバイルアプリを例にした障害状況に応じた挙動の振る舞いを意識したアーキテクチャパターンをご紹介しました。サイバーレジリエンス強化については、クラウドとオンプレ環境両方におけるバックアップデータ保護やフォレンジック環境の構築、および復旧フローについて具体的な実装例とともにご紹介しました。主に、AWS Backup や Amazon S3 を用いたVault Lock の機能でバックアップデータを保護しつつ、Logically air-gapped vault でリージョンや AWS アカウントを跨いだデータ隔離を行うことで攻撃者からのバックアップデータ侵害を防ぐアーキテクチャとしています。 Chaos Kitty で楽しくインシデント対応の基本を学ぼう！ Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、インシデント対応の体験学習ができるソリューションです。Web 3 層の Web アプリケーションに異常を注入し、異常を修正するまでのタイムを競うことで、ゲーム感覚でインシデント対応の体験が行うことができます。今までの Chaos Kitty は IoT 機器での操作を前提としており、実際に皆様の環境でお試しいただくにはハードルが高いところがありました。今回はアーキテクチャを一部改修し、AWS CDK を活用した IaC 化を行うことで IoT 機器なしでも簡単にデプロイ可能となりました。さらに Amazon CloudWatch Application Signals を使った標準的なダッシュボードを使い、サービスとして重要な指標を取得して可視化できるようにしています。また、生成 AI を利用した障害分析効率化を図る AIOps を体感いただくために、AWS Japan の Solutions Architect が開発した障害分析ソリューション Failure Analysis Assistant (FA2) との連携も可能になっています。 まとめ 障害へのアプローチとして、障害は起こる事を前提し、早く復旧するためのアプローチ（レジリエンス、回復力）を検討頂く事が重要です。今回の Summit では、このプラクティスを踏襲、実践するためのヒントが多く確認できる内容となっておりました。特に勘定系といったミッションクリティカルなシステムの AWS 稼働事例、復旧を短縮するための AWS サービス、サポートサービスの活用が確認できる内容になっておりました。これからミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド移行を検討頂いている皆様に少しでも参考になれば幸いです。 著者 石倉 徹 パートナー技術統括本部 シニアパートナーソリューションアーキテクト 安藤 麻衣 ストラテジックインダストリー技術本部通信第三ソリューション部 ソリューションアーキテクト 河角 修 フィナンシャルサービスインダストリー技術本部 銀行ソリューション部 ソリューションアーキテクト

はじめに 企業は、開発者の生産性向上、アプリケーションの高速開発、レガシーコードの保守負担軽減を支援する方法を模索しています。Amazon Q Developer は、企業がカスタマイズされた SAP 環境に関連する技術的負債を解消し、新機能をより迅速に提供できるように支援する生成 AI サービスです。このブログでは、Amazon Q Developer が SAP 開発者の生産性向上とイノベーションの加速にどのように役立つかについて説明します。 SAP は、世界中の数千の企業のビジネスを支えるミッションクリティカルな基幹業務システムです。長年にわたり、多くの企業は自社固有の要件を満たすために SAP をカスタマイズしてきました。これらのカスタマイゼーションを実現するために、SAP の ABAP プログラミング言語を利用して、必要なビジネス機能のプログラムを追加開発してきました。 ABAP プログラムは企業が SAP をビジネスに適応させるために作成されましたが、これにより SAP 環境の運用やアップグレードの難易度が高くなります。また、数十年前に書かれた複雑な ABAP コードについて、ドキュメントが不足していたり、元の開発者が退職していたりするという事はよくあることです。現在、これらの企業がクラウドへの移行、S/4HANA へのアップグレード、SAP 推奨するクリーンコア戦略（コア SAP アプリケーションで変更をせず要件を満たすために SAP の機能拡張する）の採用を検討する中で、レガシーコードは多くの課題を抱えています。 Amazon Q Developer による SAP モダナイゼーションの簡素化 Amazon Q Developer は、企業がレガシーコードの課題を克服し、より高速で低コストな SAP アップグレードを可能にします。これにより、規制遵守、セキュリティパッチ適用、新しいソフトウェア機能の採用が簡素化されます。Amazon Q Developer は、レガシー ABAP コードの機能仕様と技術仕様の両方のドキュメントが生成でき、貴重な時間を節約できます。 Amazon Q Developer は、従来の SAP ABAP、SAP ABAP RESTful Application Programming Model (RAP)、SAP Cloud Application Programming Model (CAP) を含む、SAP プログラミングフレームワーク全体で使用可能です。Amazon Q Developer は VS Code、Eclipse、その他複数の IDE 拡張で利用できます。Amazon Q developer の Eclipse バージョンは、近い将来、すべての ABAP オブジェクトタイプに対して完全に機能するようになる予定です。 他のプログラミング言語 (Java、Python) で Amazon Q Developer を使用しているお客様から、開発者の生産性が最大 40％ 向上し、さまざまな開発タスクが最大80％加速されたとの報告がありました。ABAP 開発に関して、既に SAP のお客様 (およびパートナー様) から同様のベネフィットを得られているという声を聞き始めています。 Zappos.com のエンタープライズシステム担当シニアディレクターである Saul Dave 氏は次のように述べています。 Amazon Q Developer will be a game-changer for our ABAP development and application support teams. この後、Amazon Q Developer が SAP 開発者の生産性をどのように向上させるかを示す4つのユースケースについて詳しく説明します。 ABAP コードの生成 BTP および Fiori アプリケーションの生成 テストケースの生成 レガシー ABAP コードのドキュメント生成 ユースケース #1：ABAP コードの生成 Amazon Q Developer は、自然言語プロンプトを解釈してコードを作成できます。この例では、注文番号と顧客番号でフィルタリングする機能を含む、オープン中の販売注文を表示する ABAP コードが生成されます。開発者は、Amazon Q Developer に次のプロンプトを入力してコードを作成しました。 “Generate an ABAP report named zhprp_sales_order_overview, showing list of open sales orders, filter either by order number or customer number (sold-to-party). Include: Sales order number, Sold-to-party, Order Creation date, Line Item number, Material Number, Ordered quantity, Confirmed Quantity. Order the records by sales order number. Display the output in ALV format.” 以下の短いビデオは、プロンプトの入力と生成されたコードの出力を示しています。Amazon Q Developer チャットウィンドウは画面の右側にあります。生成されたコードが SAP 内で正常に実行されることも確認できました。 ユースケース #2：Fiori および BTP のコード生成 Amazon Q Developer を使用して完全な Fiori アプリケーションを開発することを説明します。この例では、単一のプロンプトを使用して、CDS ビュー、OData インターフェース、UI を含むフロントエンドとバックエンドコンポーネントを作成するプロセスのステップを進めます。使用されるプロンプトは次のとおりです。 “Provide me with all the things I need to do to create a fiori application for the sales order(create, update, delete) and then you can handhold me while I am creating each step. In addition to that I want to have a class to insert dummy data and test classes for my cds view for TDD. Amazon Q Developer は階層化されたアプローチに従い、必要なテーブル構造が作成されるデータベース層から始まります。その後、 CDS 層に移り、基盤となるデータベーステーブルを抽象化しながらデータのビジネスに使うためのビューを提供するルート CDS ビューが定義されます。ビジネス層では、Amazon Q Developer はビヘイビア実装とテストクラスを含む CDS ビューのビヘイビア定義の生成を支援します。サービス層では、OData V2 公開のためのサービス定義とバインディングの作成が含まれ、Fiori アプリケーションとバックエンドとのコミュニケーションが可能になります。UI 層では、Amazon Q Developer はメタデータ拡張を使用した UI アノテーションを支援します。その後、開発の次のロードマップが提案され、manifest.json、サービスバインディング、アクティベーション、パブリッシングの作成が含まれます。最終ステップでは、カスタムコントローラーアクションと HTML UI5 コンポーネントが作成され、完全な Fiori アプリケーションを生成します。 ユースケース #3：単体テストケースの生成 Amazon Q Developer は、ドキュメント不足や元の開発者が居なくなった場合に、既存のコードのテストクラスを作成することを支援します。ユーザーは単純にコードを Q のインラインチャットに貼り付けるだけで、包括的なテストシナリオが自動的に分析・生成されます。生成されたコードの構文エラーは、Q のインラインチャット機能を通じてワンクリック実装で迅速に修正できます。生成されたテストクラスは SAP システムですぐに利用でき、必要に応じて微調整できます。 “Generate unit test class for public methods ”Provide the your class logic/details here” この機能により、開発者は複数の反復後でもビジネスロジックを簡単にテストでき、手動テストにかかる工数を節約できます。 ユースケース #4：レガシーABAPコードのドキュメント生成 次の例では、Amazon Q Developer が ABAP コードを分析し、チャットウィンドウのカスタムテンプレートに基づいてドキュメントを自動生成します。このユースケースは既存のコードと新しく作成されたコードの両方に適切できます。生成後に、ドキュメントは PDF やWord ドキュメントに簡単に変換できます。Amazon Q Developer は、重要な情報を理解し、一貫したフォーマット標準を維持しながらドキュメント作成プロセスを行います。この例では、次のプロンプトを使用しました。 “Generate a technical documentation of the above ABAP code. Make sure to provide highly detailed documentation, clearly explaining the action performed each of the components using following pointers as template: 1. Class/Program name 2. Class/Program Overview 3. Technical Specifications 3.1 Data Structure 3.2 Selection Screen (If provided) 4. Main Components 4.1 Subroutines/Methods 5. Test Implementation (If provided) 5.1 Test Methods 5.2 Test Setup 6. Technical Dependencies 7. Error Handling 8. Performance Considerations このユースケースは、企業はカスタムオブジェクトから影響を受けるビジネスプロセスを簡単に理解し、文書化できます。これにより移行とカレッジトランスファーのプロセスに役立ちます。 上記のユースケースからわかるように、Amazon Q Developer は SAP 開発者の手作業を削減する強力な機能を提供し、顧客がビジネスプロセスをより迅速にモダナイズできるように支援します。私たちは、お客様がこれらの機能を活用し続けることを期待しております。 料金体系 Amazon Q Developer 無料ティアから始めることができます。これは月 50 回のチャットインタラクション、月 5 回のソフトウェア開発支援、月最大 1,000 行のコード変換を提供します。Pro プランは無料プランのすべての機能に加えて、ユーザーとポリシーを管理するエンタープライズアクセス制御機能、提案を改善するために Amazon Q Developer で独自のコードをベースにしたカスタマイズ機能、高度な機能のために高い使用リミットを提供します。 詳細な価格プランはこちらをクリック してご確認ください。 今すぐレガシー SAP コードをモダナイズしましょう Amazon Q Developer のセットアップに関するステップバイステップの手順については、この ワークショップ をご参考ください。今後、これらやその他の SAP での活用シナリオのデモや詳細な解説をするビデオをYoutubeに公開する予定なので、ご確認ください。Amazon Q Developer の詳細については、 ドキュメント でご確認ください。レガシー SAP コードのモダナイゼーションに関する相談は、私たちのチームにお問い合わせください。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。