7 月 16 日、 ニューヨーク市で開催された AWS Summit で、エージェンティック AI 担当 AWS VP の Swami Sivasubramanian が、本番環境ですぐに使える AI エージェントをお客様が大規模に提供できるようにする方法について、基調講演を行いました。イベントでの主な発表を以下のとおりご紹介します。 Amazon Bedrock AgentCore のご紹介: あらゆる規模の AI エージェントを安全にデプロイして運用 (プレビュー) Amazon Bedrock AgentCore を使用すると、エンタープライズグレードのセキュリティを備えた AI エージェントの迅速なデプロイとスケーリングが可能になります。メモリ管理、ID 制御、ツール統合が提供されているため、オープンソースのフレームワークや基盤モデルを使用しながら、開発を効率化できます。 Amazon SageMaker AI での Amazon Nova カスタマイズの発表 AWS では、モデルトレーニングのすべての段階で SageMaker AI を使用して、Amazon Nova 基盤モデルを広範囲にカスタマイズできるようになりました。すぐに使える SageMaker レシピとして利用できるこれらの機能により、お客様はトレーニング前とトレーニング後の両方で Nova 理解モデルを適応させることができます。これには、業界全体のビジネス固有の要件により適切に対応するための微調整レシピや調整レシピも含まれます。 AWS 無料利用枠の更新: 新規のお客様は最大 200 USD のクレジットを使用した AWS の利用開始が可能に AWS は無料利用枠プログラムを強化し、新規ユーザー向けに最大 200 ドルのクレジットを用意しています。サインアップ時に 100 USD、Amazon EC2、Amazon Bedrock、AWS Budgets などのサービスでアクティビティを完了すると、さらに 100 ドルを獲得できます。 TwelveLabs の動画理解モデルが Amazon Bedrock で利用可能に TwelveLabs の動画理解モデルを Amazon Bedrock で利用できるようになりました。これにより、お客様は動画の検索、シーンの分類、コンテンツの要約、インサイトの抽出を、正確かつ確実に行うことができます。 Amazon S3 メタデータがすべての S3 オブジェクトのメタデータのサポートを開始 Amazon S3 Metadata では、ライブインベントリテーブルとジャーナルテーブルを通じて S3 バケット内のすべてのオブジェクトを包括的に可視化できるようになりました。これにより、変更から 1 時間以内の自動更新を使用して、既存のオブジェクトと新しいオブジェクトの両方を SQL ベースで分析できるようになりました。 Amazon S3 Vectors のご紹介: 大規模なネイティブベクトルサポートを備えた初のクラウドストレージ (プレビュー) Amazon S3 Vectors は、大規模なベクトルの保存とクエリをネイティブサポートする新しいクラウドオブジェクトストアです。従来のアプローチと比較して最大 90% のコスト削減を実現すると同時に、Amazon Bedrock ナレッジベース、SageMaker、AI アプリケーション用 OpenSearch とシームレスに統合できます。 Amazon SageMaker の新機能で、データからインサイトへのパスを合理化 Amazon SageMaker は、ダッシュボードの作成、ガバナンス、共有のための Amazon QuickSight 統合、ドキュメントとメディアファイルをカタログ化するための Amazon S3 非構造化データ統合、Lakehouse からの自動データオンボーディングという 3 つの新機能を導入しました。これらの機能は、構造化データと非構造化データの管理、視覚化、ガバナンスを単一のエクスペリエンスに統合することで、データサイロを排除します。 新しい Amazon EventBridge ログ記録で、イベントドリブンのアプリケーションをモニタリングおよびデバッグ Amazon EventBridge では、包括的なイベントライフサイクル追跡を提供する強化されたログ記録機能が提供されるようになりました。これにより、イベントが公開されたとき、ルールと照合されたとき、サブスクライバーに配信されたとき、または障害が発生したときを示す詳細なログを使用して、ユーザーがイベントドリブンのアプリケーションを監視およびトラブルシューティングできるようになります。 Amazon EKS がクラスターあたり 10 万ノードをサポートし、超大規模な AI/ML ワークロードを実現 Amazon EKS は現在、クラスターあたり 100,000 ノードまで拡張可能で、最大 160 万台の AWS Trainium アクセラレーターまたは 80 万個の NVIDIA GPU を使用して大規模な AI/ML ワークロードを実現しています。これにより、組織は Kubernetes との互換性と既存のツール統合を維持しながら、大規模な AI モデルのトレーニングと実行を効率的に行うことができます。 原文は こちら です。

本記事は米国時間 7 月 16 日に公開された「 AWS announces new innovations for building AI agents at AWS Summit New York 2025 」の日本語抄訳版です。 Amazon Bedrock AgentCore に加え、AWS Marketplace の新たなカテゴリーとAgentic AI開発の後押しに向けた1億米ドルの投資を発表 主なポイント： Amazon Bedrock AgentCore により、企業・組織は AgentCore の7つのコアサービスを活用し、安全な AI エージェントをエンタープライズ規模で導入・運用することが可能に AWS Marketplace の新カテゴリー追加により、企業・組織は有力プロバイダーによる AI エージェントやツールを簡単に見つけ、調達し、導入することが可能に 生成AIイノベーションセンター に 1 億米ドルを追加投資し、Agentic AI の開発・展開のさらなる加速を支援 Amazon Nova の新たなカスタマゼーション機能により、企業・組織のニーズにあった精度と柔軟性を実現 アマゾン ウェブ サービス（AWS）はこれまで、クラウドコンピューティングにおけるセキュリティ、信頼性、データプライバシーの基準を築いてきました。AWS は今回、AI エージェントの構築を支援する新たな機能とツールの発表により、同じ原則を Agentic AI にも適用します。お客様はこれにより、AWS の堅牢なテクノロジー基盤の上に AI エージェントを構築できるようになります。なかでも、Amazon Bedrock AgentCore は、お客様による高機能な AI エージェントのセキュアかつスケーラブルな導入・運用を支援するものです。 AWSで Agentic AI を統括するバイスプレジデントであるスワミ・シバスブラニアン（Swami Sivasubramanian） は AWS Summit New York の基調講演に登壇し、 AWS における Agentic AI 戦略 の要点を説明しました。AI エージェントは AI を活用して推論・計画・適応し、タスクを完了する自律的なソフトウェアシステムであり、あらゆる業界でイノベーションを加速させ、生産性を大きく向上させると述べました。 シバスブラニアンは次のように述べています。「これは複数の点で地殻変動のような大きな変化です。ソフトウェアの構築方法が根本から変わり、その展開・運用においても多くの新しい課題が浮上してきています。そして最も大きな影響として、ソフトウェアと世界との関わり方、そして私たちとソフトウェアの関係そのものが変わります」 Amazon Bedrock AgentCore で AI エージェントを大規模に展開・運用 AgentCore は高性能な AI エージェントを導入・運用するための、包括的なサービス群です。あらゆるAIフレームワークやモデルをご利用いただけます。 AI エージェントの導入を進めるなか、企業・組織は重要な課題に直面しています。それは、セキュリティ、信頼性、ガバナンスといったエンタープライズレベルの基準を満たしながら、デジタルの境界を越えて自律的に動作するシステムを構築することです。 AgentCore は、AI エージェントにおける概念実証（PoC）から本番運用に至るまでの重要なギャップを開発者が乗り越えるのを支援します。プロトタイプから、数百万ものエンドユーザーに対応できる拡張性の高いアプリケーションへと移行するための、多様な組み合わせが可能なソリューション群を提供します。Itaú Unibanco、Innovaccer、Boomi、Epsilon、Box といった AWS のお客様がすでに AgentCore を使った開発を始めています。 Amazon Bedrock AgentCore の主なサービス： AgentCore Runtime — エージェントには安全性を確保しつつ、変動するワークロードにも対応できる柔軟な実行環境が必要です。AgentCore Runtime は、低遅延でインタラクティブなエクスペリエンスと、業界最長となる最大8時間の複雑な非同期ワークロードの処理をサポートします。また、すべてのセッションを完全に分離可能な、唯一のフレームワーク非依存のサービスです。 AgentCore Memory — 人間が短期記憶と長期記憶の両方を活用するように、エージェントも効率的に動作するためには複雑なメモリ基盤が必要です。AgentCore Memory は、業界トップクラスの精度で短期記憶と長期記憶を提供し、開発者がコンテキストを理解するエージェントをより簡単に構築できるようにします。 AgentCore Identity — エージェントがユーザーのリクエストを実行するには、適切な認証を通じてツールやリソースへ安全にアクセスできる必要があります。AgentCore Identity は、Amazon Cognito、Microsoft Entra ID、Okta などユーザー認証とアクセスコントロールを一元管理を支援する、既存の アイデンティティ（ID） プロバイダーと連携し、シームレスかつ安全なエージェント認証を実現します。 AgentCore Gateway — AI エージェントが実世界のタスクを実行するには、多様なツールへのアクセスが欠かせません。AgentCore Gateway は、API、Lambda 関数、既存のサービスをエージェント対応のツールへ簡単に変換できる仕組みに加え、エージェントがツールを安全に発見・利用できる手段を提供します。 AgentCore Code Interpreter — AI エージェントが複雑な計算を実行、推論を検証し、データを処理し、ビジュアルを生成するためには、サンドボックス環境でコードを安全に記述・実行できる必要があります。AgentCore Code Interpreter を使えば、開発者は特定のインスタンスタイプやセッション設定を指定して、安全なコード実行環境を用意し、セキュリティ要件に対応することが可能です。 AgentCore Browser Tool — AgentCore Browser Tool は、モデルに依存しない高速かつ安全なクラウドベースのブラウザで、AI エージェントがフォーム入力やウェブサイトの操作といったタスクを大規模に実行できるようにします。 AgentCore Observability — 本番環境でのパフォーマンスを確保するには、エージェントのあらゆる動作を追跡・記録できることが重要です。AgentCore Observability は Amazon CloudWatch を基盤とし、主要なメトリクスに関するテレメトリーや組み込みダッシュボードを通じて、開発者にリアルタイムの可視性を提供します。また、既存のオブザーバビリティツールとも統合可能です。 企業のAIエージェント活用をよりシンプルにするAWS Marketplace 新カテゴリー シバスブラニアンは AWS Summit New Yorkで、 AWS Marketplace の新カテゴリー「AIエージェントとツール」の追加を発表しました。これにより、お客様は有力プロバイダーが提供する AI エージェントやツールを簡単に見つけ、調達し、導入・管理できるようになります。 AWS Marketplace の「AIエージェントとツール」カテゴリーを使えば、お客様は AI エージェントソリューションやツールをワンストップで検索・購入でき、AI 活用の取り組みを迅速に進めることができます。このカテゴリーを活用することで、すぐに統合できるツールを使って開発を加速できるだけでなく、エージェントの構築・運用・スケーリングを専門とする AWS プロフェッショナルサービスと連携しながら、AI 戦略を前進させることも可能です。 AWS 生成AIイノベーションセンターへの追加投資を発表 お客様による自律的な Agentic AI システムの開発を加速するため、AWS は 生成 AI イノベーションセンター に 2 回目となる 1 億米ドルの追加投資を行うことを 発表 しました。これは、過去 2 年間にわたって世界中の数千社に及ぶお客様を支援し、生産性の向上や顧客体験の変革を後押ししてきた実績を踏まえたものです。 例えば、 Warner Bros. Discovery Sports Europe は、Amazon Bedrock、Anthropic の Claude 3.5、その他の AWS サービスを活用し、自転車レースの実況担当者が素早く過去の記録などを調べることができる AI ソリューションを開発しました。また BMW は、2,300 万台以上に達するコネクテッドカーに対するネットワーク障害の診断方法を一新する AI ソリューションを AWS 上に構築しました。Syngenta や AstraZeneca といった企業も、Agentic AI によって業務に大きな変化をもたらしています。 AWS 生成AIイノベーションセンターには、AI サイエンティスト、ストラテジスト、エンジニアからなるグローバルチームが在籍しており、企業をはじめとするお客様やパートナーと直接連携しながら、AI 実装における最も複雑な課題の解決に取り組んでいます。 AWS Summit New York のその他の発表 Amazon Nova の新しいカスタマイズ機能：より高精度で柔軟なモデルの構築が可能に Amazon SageMaker AI 上で動作する Amazon Nova に 新たなカスタマイズ機能 が追加され、SageMaker HyperPod のサポートも加わりました。これにより、お客様は Nova を自社のニーズにさらに合わせて最適化できるようになります。また、 Nova Act SDK の 強化 を通じて、精度向上に加え、セキュリティやアクセス制御が拡張されました。これにより、開発者はウェブブラウザ上で確実に動作するエージェントを構築できるようになります。 Amazon S3 Vectors を発表 Amazon S3 Vectors は、AI ワークロードをサポートする初のクラウドオブジェクトストレージです。Amazon S3 Vectors により、お客様は従来の方法と比較し、ベクトルの保存とクエリのコストを最大 90% 削減できます。大規模なベクトルデータセットを保存・活用して AI を強化したり、S3 データのセマンティック検索において、コストパフォーマンスの高いソリューションを提供します。Amazon Bedrock Knowledge Bases や OpenSearch Service と連携し、検索拡張生成（RAG）やベクトル検索の運用を効率化・低コスト化します。 Kiro：プロトタイプからプロダクションまでを橋渡し Kiro は、AI エージェントを活用したソフトウェア開発に取り組む開発者向けの新しい IDE（統合開発環境）です。開発体験をシンプルにし、AI エージェントとのコラボレーションをより身近なものにします。Kiro を使えば、vibe coding だけでなく、Kiroスペックや Kiroフック といった機能を活用して、エージェントと一緒に詳細な設計を進めたり、テストの実行やドキュメント生成などのタスクを自動で実行するワークフローを起動したりできます。 Agentic な世界での構築を後押しする新たな MCP リソース Model Context Protocol（MCP） は、エージェントがデータソースやツール、メモリバンクなどに接続するための新たな標準仕様です。今回発表した ローカル AWS API MCP サーバー は、AWS の API 全体に関する知識を完全に備えており、開発者が AWS と連携しながら vibe coding を行えるようにします。これにより、あらゆるソフトウェアアシスタントが AWS に精通することがより簡単になります。さらに、2つ目のリソースとして提供される AWS Knowledge MCP サーバー は、AWS のドキュメントに関する包括的な知識を常に最新の状態で保持した MCP で、完全にマネージドかつ継続的に更新され、任意の MCP クライアントからリモートで利用可能です。 TwelveLabs の AI モデルが Amazon Bedrock で利用可能に TwelveLabsの AIモデル は、映像・音声・テキストを同時に処理することで、動画ライブラリを検索可能で活用しやすい資産へと変換します。お客様は自然言語のプロンプトを使って、目的のコンテンツを瞬時に見つけ、アクションをとることができるようになります。これらすべてが、AWS のセキュリティ、プライバシー、パフォーマンスのもとで提供されます。AWS は TwelveLabs のモデルを提供する初のクラウドプロバイダーです。 AWS と Meta がスタートアップ支援で連携 AWS と Meta は、Metaの基盤モデルである Llama を活用したAI アプリケーション構築を支援 するため、米国のスタートアップ 30 社を対象に、1 社あたり最大 20 万ドル分の AWS クレジットと、Meta および AWS の専門家による技術サポートを提供します。この 6 か月間のプログラムへの参加応募は、2025年8月8日までです。Llama モデルを使った最先端の AI アプリケーション開発を後押しすることで、AI イノベーションを加速させます。 Strands 1.0 により、AI エージェント同士の連携がより簡単に AWS は、オープンソース SDK Strands Agents のアップデートも発表しました。これは、複数の AI エージェントが連携して複雑な課題を解決するシステムを、これまでにないほど簡単に構築できる開発者向けツールです。従来は数か月かかっていた複雑な技術作業を、わずか数時間のプロセスに短縮できるため、企業はカスタマーサービス、データ分析、その他の高度なタスクを担う協調型 AI アシスタントのグループを構築しやすくなります。 ゲーミフィケーションで AI スキルを習得できる「AWS AI League」 AWS は、開発者が 生成AI を使って実世界の課題に挑戦しながら、組織内でのイノベーションに不可欠なスキルを習得できる「 AWS AI League 」を開始しました。このプログラムでは、開発者がファインチューニング、モデルのカスタマイズ、プロンプトエンジニアリングなどを実践的に学ぶため、最大 200 万ドル分の AWS クレジットを提供します。上位入賞者には、AWS re:Invent への全額負担の招待旅行や賞金が贈られます。 AWS、AI 時代のキャリアに備える若手人材育成に 300 万米ドルを投資 AWS は、6,600 以上の AWS Academy 加盟校の学生に対し、AWS Skill Builder の有料トレーニングコンテンツと AWS 認定試験の受験バウチャーを無償で提供し、AI 時代に求められるスキルの習得を支援します。また、Academy に属さない学生や新卒者も、将来有望なキャリア分野に関する調査レポートや、それにもとづくAWS Skill Builder 上の無料学習プランを活用してキャリア形成に活かすことができます。AWSは、初年度にグローバルで270万人の学生及び新卒者の参画を目標としています。

合併と買収 (M&A) は、事業を拡大し、製品ラインを多様化し、新しい市場を開拓する機会を組織にもたらします。ただし、旧来の IT システムの統合、厳しい規制への準拠、事業継続性の維持など、そこにはさまざまな課題が伴います。リソースの重複を排除し、プロセスを最適化して運用の一貫性を実現するのと同時に、コストを管理および最適化することは、合併を完了したり M&A 活動を行ったりした後にビジネス価値を最大化する上で、極めて重要な役割を果たします。 このブログ記事では、AWS Organizations を利用したM&A 後の AWS リソースとコストの最適化と管理に関するベストプラクティスと考慮事項について説明します。また、 Amazon S3 Storage Lens 、 AWS Compute Optimizer 、 AWS Cost Optimization Hub (コスト最適化ハブ) など、AWS Organizations が統合しているさまざまなコスト最適化サービスや分析サービスを紹介し、活用します。 前提条件 AWS Organizations 、 AWS Control Tower 、および AWS でのマルチアカウント設定 を理解していること その M&A に関連する買収元企業と買収先企業の両方について、AWS Organizations で設定されている organization (※訳注：一般的な意味での “組織” と区別するために本記事では “organization” と表記します) の構造を理解していること 合併元 organization からメイン organization へのアカウントの移行が完了していること ベストプラクティスと推奨事項 合併後の organization で適用可能なタグを評価し、リソースをグループ化してコストの一元管理を行う 合併後は、新たに合併されたビジネス内でタグを調整する戦略を立て、 Resource Groups を利用してプロジェクトや環境、コストセンターなどの特定の基準に基づいてAWS リソースの論理的なコレクションを作成する必要があります。それにより、アップデートの適用、アプリケーションのアップグレード、ネットワーク設定の調整などの一括アクションを実行でき、それと同時にリソース全体のコストを容易に追跡・管理することができます。また、コスト要因の特定、予算の設定、リソース使用の最適化も行えるため、最終的に AWS における潜在的なコスト削減につながる可能性もあります。 包括的な可視性を得るには、AWS Organizations を使用して一元化された”請求とコスト管理” のフレームワークを確立してください。AWS 上で実行されているアプリケーションがあり、リソースが EC2 インスタンス、RDS データベース、S3 バケットなどの複数のサービスに分散している場合を想定してみましょう。このアプリケーション用のリソースグループを作成し、すべてのリソースをグループ化することができます。これにより、グループ内のすべてのリソースの合計コストを確認できるようになり、 コストの集中箇所の特定 や、使用パターンの分析、実際の需要に基づいたリソースのサイズ適正化などを行うことが容易になります。また、利用できていないリソースや過剰な支出を削減することもできます。 例えば、リザーブドインスタンスやスポットインスタンスなどのコスト最適化戦略を グループ全体に適用して、コスト削減を最大化 することができます。AWS Resource Groups を使用して、リソースグループと呼ばれるキャパシティ予約の論理的なコレクションを作成できます。また、属性 (インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン) が異なるキャパシティ予約を 1 つのリソースグループに含めることもできます。キャパシティ予約のリソースグループを作成すると、個々のキャパシティ予約ではなく、キャパシティ予約のグループにインスタンスを割り当てることができます。キャパシティ予約のグループをターゲットとするインスタンスは、グループ内の任意のキャパシティ予約のうち属性 (インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン) が一致し、かつ他のインスタンスに割り当てられておらず利用可能なものとマッチングされます。 費用を正確に追跡するために、コストセンターを設けて、すべての AWS リソースに 一貫したコスト配分タグを実装 してください。例として、A 社と B 社が合併した後、「Project Alpha」と「Project Bravo」というワークロードが重複している各社のプロジェクトについて、コストの可視化を維持しながら AWS 環境を統合する必要がある場合を考えてみましょう。 コスト配分タグは以下のシナリオで役に立ちます: ”Project“, ”Environment“, ”CostCenter“, ”Application“, ”Department“ などの統一されたタグ構造を定義します。 リソースを移行し、統一された構造に従ってタグ付けをし直します。例えば、“Project Alpha” リソースには “Project=Alpha”, “Environment=Production”, “CostCenter=IT” のようにタグ付けし、“Project Bravo” リソースには “Project=Bravo”, “Environment=Live”, “Department=Engineering” のようにタグ付けします。 重複しているワークロードを識別し、両方のプロジェクト名でタグ付けします。例えば、共有データベースリソースには “Project=Alpha”, “Project=Bravo”, “Environment=Production”, “CostCenter=IT”, “Department=Engineering” のようにタグ付けします。 AWS Cost Explorer を使用して、さまざまなタグの組み合わせに基づいてコストレポートを生成します。これにより、共有コストを含め、各プロジェクト、環境、コストセンター、または部門に関連するコストを可視化できます。 共有リソースへの比例配分を含め、それぞれのプロジェクト、コストセンター、または部門に正確にコストを帰属させるコスト配分モデルまたはチャージバックモデルを実装します。 合併後の organization におけるリソースの重複を特定および削減する organization が合併する際、クラウド環境間で重複が発生し、無駄な支出につながることがよくあります。包括的なレビューを行うことで、リソースの余剰を明らかにし、最適な統合を実現することができます。 まず AWS Organizations で有効にした AWS Cost Optimization Hub (コスト最適化ハブ) を活用して、合併後の事業体全体の AWS コスト最適化推奨事項の特定、フィルタリング、集計から始めることをお勧めします。それにより、リソースのサイズ適正化、アイドル状態のリソースの削除、Savings Plans、およびリザーブドインスタンスに関する推奨事項が得られます。図 1 に示すように、Cost Optimization Hub を使用することで、合併後の organization 全体で推奨されるコスト最適化と統合された調査結果を 1 つのダッシュボードで確認することができます。そこで推定される節約額は、AWS アカウント、AWS リージョン、リソースタイプなどでフィルタリングして集計することができます。 自動化された推奨事項がニーズに合わず、コスト最適化分析を自分で行いたい場合は、AWS Organizations と統合された AWS Cost Explorer を利用することで organization 全体の推奨事項を可視化することができます。 図 1: Cost Optimization Hub (コスト最適化ハブ) で毎月の節約額を見積もる エンタープライズサポート のお客様の場合、 AWS Trusted Advisor からの最適化に関する更なる推奨事項も確認いただけます。Trusted Advisor は、図 2 に示すように、十分に活用されていないリソース、アイドル状態のロードバランサー、その他のコスト削減の可能性がある領域を特定するのに役立ちます。 organization 全体で AWS Trusted Advisor を有効 にし、 推奨事項を含むレポートを作成する ことをお勧めします。より規範的なガイダンスやベストプラクティスについては、ブログ記事「 AWS Trusted Advisor による運用上の優秀性の継続的な最適化 」をご覧ください。 図 2: AWS Trusted Advisor はコスト最適化のチェックの特定に有用 AWS Config は、AWS アカウント内のリソースの設定と関係性を評価、監査、確認することができます。このサービスは コスト最適化にも使用 できます。特定の Amazon Relational Database Service (Amazon RDS) インスタンスがアカウントにデプロイされた場合にアラートを受け取ることができるシナリオを考えてみましょう。必要以上に大きなインスタンスタイプを使用されている場合、特定のアカウントに予期せぬコストが発生する可能性があります。これに対処するには、AWS Config にカスタムルールを実装し、データベースインスタンスを監視してアラートを提供することでコストを最適化できます。 合併後のビジネスニーズに合わせてコンピューティングコストを最適化する AWS Compute Optimizer は、AWS Organizations を通じて管理されている複数のアカウントにわたって EC2 インスタンスを適切なサイズにするための推奨事項を提供することで、M&A 後のコストを最適化するのに役立ちます。ワークロードパターンを分析し、パフォーマンス要件を満たしながらコストを削減できるインスタンスタイプを提案します。Organizations でアカウントを統合し、Compute Optimizer の推奨事項を活用することで、十分に活用されていないインスタンスやサイズが大きすぎるインスタンスを特定して排除し、統合後の組織のコンピューティングリソース全体でコスト削減につなげることができます。 図 3: AWS Compute Optimizer – 動作の仕組み Compute Optimizer コンソールから Compute Optimizer を AWS Organizations と統合します。これにより、Compute Optimizer はサービスに必要なリソースの作成などの必要な設定を実行できるようになります。 AWS Compute Optimizer の使用を開始するには、Compute Optimizer コンソールを使用して メンバーアカウントを Compute Optimizer の委任管理者として指定 します。委任管理者アカウントを使用して、organization 内のすべてのアカウントのリソース最適化の機会を特定するように Compute Optimizer を設定します。詳細については、「 AWS Compute Optimizer の開始方法 」を参照してください。コンテナワークロードを扱う場合は、 organization 内の複数アカウント間での分割コスト配分データ (SCAD) を活用することができます。 ワークロードとインフラストラクチャが増えるにつれて、リザーブドインスタンスを利用してコストを削減したり、使用量に応じた階層型料金によるメリットを活用したりできる機会が増えます。適切なリザーブドインスタンス (RI) の構成を決定するには、使用パターンを分析することが重要です。両方の organization の既存の RI コミットメントを評価し、M&A 後の環境への適用可能性を評価します。使用パターンやインフラストラクチャの要件の変更に合わせて RI を必要に応じて変更または移管することで、RI の使用率を高め、コストを削減できます。 統合的なデータアーカイブとストレージの戦略を策定する M&A のトランザクションが終わったら、両 organization のストレージ使用状況を見直し、コスト削減の機会を見極めましょう。統合プロセス中または統合プロセス後のデータ保持とコンプライアンス要件を管理するためのデータアーカイブおよびストレージ戦略を策定します。 Amazon S3 Storage Lens は、オブジェクトストレージの使用状況やアクティビティの傾向を organization 全体で可視化し、コストを最適化してデータ保護のベストプラクティスを適用するための実行可能な推奨事項を提示します。S3 Storage Lens は、組織内の数百、数千ものアカウントにわたるオブジェクトストレージの使用状況とアクティビティを単一のビューで提供し、ドリルダウンして複数の集計レベルでインサイトを得ることができる初めてのクラウドストレージ分析ソリューションです。S3 Storage Lens を使用すると、そのバケット内のオブジェクトへのアクセスが頻繁ではない “コールド S3 バケット” を識別できます。図 4 に示すように、アカウント、リージョン、バケット、またはプレフィックスに基づいてフィルターを追加することで、詳細なインサイトを可視化できます。 Amazon S3 Glacier や Amazon S3 オブジェクトライフサイクルポリシー などの AWS ストレージサービスを活用することで、データアーカイブとライフサイクル管理を自動化し、時間の経過とともにストレージコストを削減することができます。 図 4: Amazon S3 Storage Lens では、organization 内のすべての S3 バケットにわたるオブジェクトストレージの使用状況とアクティビティを一元的に確認可能 バックアップポリシーとデータ保持の効率的かつ一元的なデータ管理を行うには、 AWS Backup の AWS Organizations との統合を有効化 してください 。これは、合併後の organization の複数の AWS アカウントとサービスにわたるバックアップとデータ保護を一元管理するための、費用対効果の高いソリューションを提供するものです。詳細については、「 AWS Backup のコストを最適化する 」を参照してください。 ネットワークインフラストラクチャの重複箇所を特定し解消する M&A では、しばしば異なる IT インフラストラクチャを統合する必要がある場合があり、それによって重複や非効率性が生じる可能性があります。これらのトランザクションには通常、ハイブリッドネットワークが含まれます。M&A の後に AWS でのデータ転送やネットワークのコストの最適化を怠ると、多額の不要な支出が発生する可能性があります。データ転送とネットワークの最適化の手法を活用することで、最終的には M&A による財務上のメリットと相乗効果を最大限に引き出すことができます。 M&A において、新規アカウントを既存の AWS Organizations 構造に統合する際には、IT インフラストラクチャの統合と、データ転送やネットワークなどの関連コストの最適化が重要となります。主なステップには、リージョン別のデータ転送パターンの特定および統合、データ転送料金を削減するための AWS PrivateLink や Resource Access Manager の活用、一元的な VPC 接続管理のための AWS Transit Gateway の利用などがあります。 AWS Data Exports と Amazon QuickSight による一元的なコストモニタリングにより、統合された請求データの可視化が可能になります。AWS Organizations 内で サービスコントロールポリシー (SCP) を実装することで、統合されたアカウント全体にコスト最適化プラクティスを強制的に適用できる一方、 AWS コスト配分タグ を使用することで、特定のビジネスユニットやプロジェクトにコストを分類し配分することが可能です。 統合フェーズでのネットワーク最適化の推奨事項の詳細については、 AWS ネットワーク最適化のブログ投稿 を参照してください。 サポートおよびライセンスにかかるコストを管理する 適切なサポート計画を立てることで、コストの削減、リスクの軽減、事業継続性の確保、合併後の事業体のより円滑な管理の促進が可能になります。そのために エンタープライズサポートプラン へアップグレードをお勧めします。このプランでは、AWS コスト最適化の専門家によるサポートを受けることができるようになります。そこでは AWS のアーキテクチャや使用パターンのレビューを通して、リソースの最適化やインスタンスのサイズ適正化、リザーブドインスタンスの活用、費用対効果の高いサービスやアーキテクチャの採用などについて、カスタマイズされた推奨事項が提供されます。 エンタープライズサポートの大きな利点は、organization 全体を対象としていることです。organization 全体でエンタープライズサポートプランを契約すると、追加または招待したすべてのアカウントに自動的に同じレベルのサポートが継承されます。これによりプロセスが合理化され、合併時に各アカウントに個別のサポートプランを付与する必要がなくなります。ただし、この機能は現在一部のリージョンのお客様のみが利用可能であり、お客様のエンタープライズ契約にはそのための必要な条項が含まれている必要があります。この機能を有効にする資格や、サポートプランに関する追加情報についてはテクニカルアカウントマネージャーにお問い合わせください。 AWS License Manager を使用することで、ソフトウェアライセンスの管理やライセンスコストの調整が可能になります。AWS Organizations と AWS License Manager を統合することで、organization 全体のライセンスを可視化できます。合併後の事業体全体のソフトウェアライセンスを一元的に可視化できるため、M&A の際のライセンスコストの最適化に役立ちます。図 5 は AWS License Manager がどのようにライセンスの追跡、プール化、再配布を可能にするかを示しており、これによりコンプライアンスを確保しながら重複購入を回避して、大幅なコスト削減につなげることができます。 図 5: AWS License Manager ダッシュボードは AWS およびオンプレミス環境全体にわたる Microsoft、SAP、Oracle、IBM などのベンダーからのソフトウェアライセンスの概要を提供 ソフトウェア調達を効率化し、重複するライセンスを排除し、合併後の事業体全体で統合された可視性を確保するために、organization 全体で AWS Private Marketplace を有効にすることをお勧めします。これにより、中央集権的なガバナンス、コスト管理、および効率的なソフトウェア配布が可能になり、M&A の際にスムーズな移行を可能としつつ、コスト削減を実現することができます。 M&A 成功後に継続的にコストを監視し最適化する M&A 後は、自組織の環境内のコストを継続的に監視することが極めて重要です。これは通常、当組織が最大限の最適化のためのスコープと機会を持ち、環境内での効率性を向上させる立場にあるためです。プロアクティブなコスト監視と最適化のプラクティスを確立し、進化するビジネスニーズとコスト要因に基づいてリソースの使用量を継続的にレビューして調整します。定期的にコスト最適化レビューを実施して、不要または十分に活用されていないリソースを特定して排除するように計画してください。これには、インスタンスのサイズ適正化、未使用リソースの削除、費用対効果の高い価格モデル (リザーブドインスタンス、スポットインスタンスなど) の活用などが含まれます。 合併後の organization の複数のアカウントで Amazon CloudWatch メトリクスをモニタリングすることで、CPU/メモリの使用量が低く、ダウンサイジングや終了が可能な、十分に活用されていないリソースを確認できます。使用パターンに基づいてリソースを起動および停止することで、アイドル状態のリソースのコストを削減できます。 AWS Budgets と AWS Cost Anomaly Detection をセットアップして、データ転送やネットワーキングに関連する潜在的なコスト急増や異常が発生したときにアラートや通知を受け取るようにしてください。AWS Lambda 関数を使用してアイドル状態のリソースを自動的に停止または終了する自動最適化を実装してください。また、需要に基づいてリソース容量を動的に調整する AWS Auto Scaling の使用も検討してください。 コスト管理プロセスと手順を文書化する M&A を通じて得たコスト管理のプロセス、手順、および得られた教訓を文書化して、組織の知識を把握し、統合後の組織への知識移転を促進してください。統合後のコストを効果的に管理できるように、コスト管理のベストプラクティス、ツール、プロセスについてステークホルダーにトレーニングとサポートを提供してください。これにより、コスト意識の文化が育まれ、M&A 移行期間中の効果的なコラボレーションが可能になります。 社内に知識共有プラットフォームがある場合は、そこにプロセスを文書化してください。また、エンタープライズサポートプランに加入している場合は、フルマネージド型の安全なプライベート空間である AWS re:Post Private を活用して、組織固有のクラウドコミュニティを構築し、独自の知識リソースへのアクセスを提供することもできます。 AWS re:Post Private は、信頼できる AWS 技術コンテンツを一元化し、プライベートな議論の場を提供します。これにより、チームが社内チーム間および AWS と連携する方法を改善して、技術的な障壁を取り除いたり、イノベーションを加速させたり、クラウドでのより効率的なスケーリングを実現したりできるようになります。 サービスを AWS Organizations と統合してボリュームディスカウントを利用する このブログ記事で説明されているサービスは、サービスのコンソールまたは API 操作 / CLI コマンドなどを使用して AWS Organizations 上で有効化することができます。これにより、必要なリソースの作成など、organization に必要なすべての初期化ステップを AWS サービスが実行できるようになります。 合併する organization のアカウントを合併後の organization に統合したら、organization 内のすべてのアカウントの使用量を合算することで、 ボリュームディスカウント 、リザーブドインスタンス割引、および Savings Plans を共有できます。請求の観点からは、AWS は organization 内のすべてのアカウントをあたかも 1 つのアカウントのように扱います。 Amazon Simple Storage Service (Amazon S3) などの一部のサービスには、特定の使用量に応じたボリューム料金階層があり、サービスの使用量が増えるほど料金が低くなります。一括請求により、AWS はすべてのアカウントの使用量を合算して適用するボリューム料金階層を判定し、可能な限り全体的な料金を低く抑えます。その後、AWS は各アカウントの使用量に基づいて全体のボリュームディスカウントの一部を各メンバーアカウントに割り当てます。 たとえば、Bob の一括請求には、Bob 自身のアカウントと Susan のアカウントの両方が含まれているとします。Bob のアカウントは管理アカウントなので、Bob は自分自身と Susan の両方の料金を支払います。Bob はその月に 8 TB のデータを転送し、Susan は 4 TB のデータを転送します。 この例では、AWS は最初の 10 TB のデータ転送に対して GB あたり $0.17、次の 40 TB に対して GB あたり $0.13 を請求します。これは、TB あたりに換算すると最初の 10 TB については $174.08 (= 0.17 × 1,024)、次の 40 TB については $133.12 (= 0.13 × 1,024) に相当します。なお、1 TB = 1,024 GB である点に注意してください。 Bob と Susan が使用した 12 TB については、Bob の管理アカウントに ($174.08 × 10 TB) + ($133.12 × 2 TB) = $1,740.80 + $266.24 = $2,007.04 が請求されます。 一括請求を階層化することのメリットがなければ、AWS は Bob と Susan の使用量に対してそれぞれ TB あたり $174.08 を請求することになり 、合計で $2,088.96 となっていたはずです。 3 つの AWS アカウントがあり、S3 ストレージとしてアカウント A は 10 TB、アカウント B は 15 TB、アカウント C は 20 TB を使用しているものとします。個別のアカウントの場合、それぞれのストレージ階層に基づいて個別に請求されます。これらのアカウントを AWS Organizations を使用している organization に統合すると、45 TB (10 TB + 15 TB + 20 TB) のストレージ使用量の合計が organization レベルで集計されます。この 45 TB の使用量は上位のストレージ階層に該当する可能性が高く、その場合個別アカウントの料金階層と比較して GB あたりの料金が低くなります。 AWS Organizations を通じてこのボリュームディスカウントを利用することで、特に organization 内の複数の AWS アカウントに大量のストレージ要件が分散している場合に、S3 ストレージ全体のコストを大幅に削減することができます。 まとめ このブログ記事で紹介したベストプラクティスを導入することで、組織はリソース利用を最適化し、コストを効果的に管理し、財務リスクを最小限に抑え、合併・買収 (M&A) の活動に関わるすべての関係者にとって統合を成功させることができます。ワーナーブラザーズ・ディスカバリーが AWS Organizations サービスやその他の統合サービスをどのように活用して買収を成功させたかを理解するには「 Improving Mergers and Acquisitions Using AWS Organizations with Warner Bros. Discovery 」をご覧ください。 AWS コストのレビュー、可視化、最適化に対して AWS の推奨事項と支援を最大限に活用するには、このブログ記事で取り上げているコスト最適化ハブ、S3 Storage Lens、Compute Optimizer などのサービスを AWS Organizations と統合してください。分散化された柔軟な管理を実現するために、AWS Organizations と統合されたサービスの委任管理者としてメンバーアカウントを指定することを検討してください。AWS Organizations と統合可能なサービスのリストを確認するには、 AWS Organizations で使用できる AWS サービス をご覧ください。 M&A を進めている中で organization の統合に関するベストプラクティスのガイダンスをお探しの場合は「 AWS Organizations のアカウント評価 」と、 アカウントの効果的な移行に関する 3 部構成のブログ投稿シリーズ を参照してください。さらに詳細な情報については「 Choosing an AWS cost management strategy 」と「 Starting your Cloud Financial Management journey: Cost savings 」をご覧ください。 著者について Nikhil Anand Nikhil Anandは、ロンドンを拠点とする AWS のシニアソリューションアーキテクトです。主にUKI (英国・アイルランド) 地域の中小規模 (SMB) および金融サービス機関 (FSI) のお客様を担当しており、セキュリティ、コンプライアンス、移行の分野でのバックグラウンドを持っています。また、お客様の移行プロセスにおける M&A トランザクションのアドバイザーとしても活動し、お客様の AWS クラウドでの構築とモダナイズを支援しています。仕事を離れると、スポーツに情熱を注ぎ、日々のトレーニングを欠かさず続けることを信条としています。 Nivedita Tripathi Nivedita Tripathi は AWS Organizations の GTM 担当シニアプロダクトマネージャーです。セキュリティとガバナンスのベストプラクティスを活用しながら、複数のアカウントにわたるクラウドインフラストラクチャの構築とスケーリングにおいてお客様を支援することに注力しています。テクノロジーへの深い情熱の一方で、 音楽を楽しみ、世界各地を旅し、家族と大切な時間を過ごすことを何よりの喜びとしています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

By Kazuki Nagasawa, Cloud Support Engineer – AWS Support Engineering By Kensuke Fukumoto, Solutions Architect – AWS ISV/SaaS 近年、大規模言語モデル（LLM）の台頭により、様々な産業分野で AI の導入が加速しています。しかし、LLM の能力をさらに拡張し、最新の情報やドメイン固有の知識を効果的に活用するには、外部データソースとの統合が不可欠です。この課題に対する効果的なアプローチとして、Retrieval Augmented Generation（RAG）が注目を集めています。 RAG は、ユーザーの入力に基づいて既存の知識ベースや文書から関連情報を検索し、この情報を LLM の入力に組み込むことで、より正確で文脈に適した応答を生成する手法です。この技術は、製品開発における技術文書の活用から、カスタマーサポートでの FAQ 応答、さらには最新データに基づく意思決定支援システムまで、幅広いアプリケーションで実装されています。 RAG の実装は、Software as a Service（SaaS）プロバイダーとその利用者（テナント）の両方に大きな価値をもたらします。 SaaS プロバイダーは、単一のコードベースから複数のテナントにサービスを提供するためにマルチテナントアーキテクチャーを使用できます。テナントがサービスを利用するにつれて、適切なアクセス制御とデータ分離によって保護されながら、データが蓄積されていきます。このような環境で LLM を使用した AI 機能を実装する際、RAG により各テナントの固有データを使用してパーソナライズされた AI サービスを提供することが可能になります。 カスタマーサービスコールセンター SaaS を例に考えてみましょう。各テナントの過去の問い合わせ記録、FAQ、製品マニュアルは、テナント固有の知識ベースとして蓄積されます。RAG システムを実装することで、LLM はこれらのテナント固有のデータソースを参照して、各テナントのコンテキストに関連する適切な応答を生成できます。これにより、汎用的な AI アシスタントでは不可能な、テナント固有のビジネス知識を組み込んだ高精度なインタラクションが可能になります。RAG は、SaaS におけるパーソナライズされた AI 体験を提供する重要なコンポーネントとして、サービスの差別化と価値向上に貢献します。 しかし、RAG を通じてテナント固有のデータを使用する場合、セキュリティとプライバシーの観点で技術的な課題があります。主な懸念は、テナント間のデータ分離を維持し、意図しないデータ漏洩やクロステナントアクセスを防ぐセキュアなアーキテクチャの実装です。マルチテナント環境では、データセキュリティの実装が SaaS プロバイダーの信頼性と競争優位性に重大な影響を与えます。 Amazon Bedrock Knowledge Bases により、より簡単に RAG を実装できます。ベクトルデータベースとして OpenSearch を使用する場合、 Amazon OpenSearch Service または Amazon OpenSearch Serverless の 2 つの選択肢があります。マルチテナント環境を構築する際、各選択肢には異なる特徴と権限モデルがあります： Amazon OpenSearch Serverless： メタデータフィルタリング により、ベクトルデータベースからの検索結果をテナント別にフィルタリングできます（詳細は Multi-tenant RAG with Amazon Bedrock Knowledge Bases を参照） この権限モデルでは、データの作成や更新などの書き込み操作に対する権限を分離できません Amazon OpenSearch Service： Fine-grained access control （FGAC）が利用可能です ナレッジベースにアタッチされた単一の AWS Identity and Access Management （IAM）ロールを通じたアクセスとなるため、権限分離に FGAC を使用することが困難です この記事では、JSON Web Token（JWT）と FGAC の組み合わせ、およびテナントリソースルーティングを使用したテナント分離パターンを紹介します。前述の権限モデルの制限により FGAC の目標を達成できない場合は、この記事のソリューションを使用できます。このソリューションは、ベクトルデータベースとして OpenSearch Service、オーケストレーションレイヤーとして AWS Lambda を使用して実装されています。 次のセクションでは、OpenSearch Service における JWT と FGAC を使用したテナント分離の具体的な実装と、これによってセキュアなマルチテナント RAG 環境がどのように実現されるかを探ります。 OpenSearch Service におけるマルチテナントデータ分離での JWT の有効性 Amazon OpenSearch Service にマルチテナント SaaS のデータを格納する で紹介されているように、OpenSearch Service では、マルチテナントデータを管理する分離レベルとして、ドメインレベルの分離、インデックスレベルの分離、ドキュメントレベルの分離と複数の方法があります。 インデックスレベルとドキュメントレベルでのアクセス権限分離を実装するには、OpenSearch Security プラグインでサポートされている FGAC を使用できます。 OpenSearch Service では、IAM アイデンティティを OpenSearch ロールにマッピングすることで、きめ細かなアクセス制御を実現できます。これにより、各 IAM アイデンティティに対して OpenSearch での詳細な権限設定が可能になります。しかし、このアプローチには重大なスケーラビリティの課題があります。テナント数の増加に伴い、必要な IAM ユーザーやロールの数も増加し、AWS サービスクォータの制限に達する可能性があります。また、多数の IAM エンティティの管理は運用の複雑さを招きます。 動的に生成される IAM ポリシー でこの課題自体は克服できる可能性がありますが、動的に生成された各ポリシーは単一の IAM ロールにアタッチされます。単一の IAM ロールは単一の OpenSearch ロールにマッピングできますが、適切な分離のためにはテナントごとに IAM ロールと動的ポリシーが必要となり、多数のエンティティを管理する同様の運用上の複雑さが生じます。 この記事では代替アプローチを提供し、マルチテナント環境でのデータ分離とアクセス制御を実装するための自己完結型トークンである JWT の有効性に焦点を当てます。JWT を使用することで、以下の利点が得られます： 動的なテナント識別 – JWT ペイロードには、テナントを識別するための属性情報（テナントコンテキスト）を含めることができます。これにより、システムはリクエストごとにテナントを動的に識別し、このコンテキストを後続のリソースやサービスに渡すことができます。 OpenSearch における FGAC との統合 – FGAC は、JWT 内の属性情報を直接使用してロールマッピングを行うことができます。これにより、JWT 内のテナント ID などの情報に基づいて、特定のインデックスやドキュメントへのアクセス権限をマッピングできます。 JWT と FGAC を組み合わせることで、OpenSearch Service を使用したマルチテナント RAG 環境において、セキュアで柔軟かつスケーラブルなデータ分離とアクセス制御が実現されます。次のセクションでは、この概念を実際のシステムに適用するための具体的な実装詳細と技術的考慮事項を探ります。 ソリューション概要 RAG では、LLM の出力を拡張するために使用される関連文書などのデータは、埋め込み言語モデルによってベクトル化され、ベクトルデータベースにインデックスされます。自然言語でのユーザーの質問は、埋め込みモデルを使用してベクトルに変換され、ベクトルデータベースで検索されます。ベクトル検索によって取得されたデータは、出力を拡張するためのコンテキストとして LLM に渡されます。以下の図は、ソリューションアーキテクチャを示しています。 このソリューションでは、RAG におけるナレッジソースを格納するベクトルデータストアとして OpenSearch Service を使用します。フローは以下の通りです： 各テナントの RAG アプリケーションユーザーは、 Amazon Cognito ユーザープール のユーザーとして作成され、フロントエンドへのログイン時にテナント ID 情報でエンリッチされた JWT を受け取ります。各ユーザーのテナント情報は Amazon DynamoDB に格納されており、ユーザー認証時に トークン生成前 Lambda トリガー によって JWT に追加されます。 ユーザーがフロントエンドでチャットを開始すると、ユーザークエリは JWT とともに Amazon API Gateway を通じて Lambda 関数に渡されます。 ユーザークエリは、Amazon Bedrock で利用可能なテキスト埋め込みモデルと連携してベクトル化されます。 検索用のドメインとインデックス情報を DynamoDB から取得します。 OpenSearch Service でベクトル検索を実行し、インデックスからクエリに関連する情報を取得します。 取得された情報をコンテキストとしてプロンプトに追加し、Amazon Bedrock で利用可能な LLM に渡して応答を生成します。 このソリューションで注目すべき点は、OpenSearch Service でのテナントデータ分離と各テナントのデータへのルーティングに JWT を使用することです。OpenSearch Service で利用可能な FGAC を使用して各データセットへのアクセス権限を分離し、JWT に追加されたテナント ID 情報を使用してアプリケーションユーザーと分離された権限セットをマッピングします。このソリューションでは、お客様の要件に合わせて、データ分離の粒度に対して 3 つの異なるパターンを提供しています。また、JWT からのテナント ID 情報とデータの場所（ドメイン、インデックス）のマッピングを DynamoDB で定義することで、ルーティングも可能になります。 ユーザーがドキュメントを追加する際は、ファイルを Amazon Simple Storage Service （Amazon S3）にアップロードし、メタデータを DynamoDB 上の管理テーブルに書き込みます。OpenSearch Service にデータを格納する際は、ベクトル化のために Ingest pipelines でテキスト埋め込みモデル（Amazon Bedrock）が呼び出されます。ドキュメントの作成、更新、削除では、リクエストに JWT が付与されているため、テナントの識別が可能です。 このソリューションは、 AWS Cloud Development Kit （AWS CDK）を使用して実装されています。詳細については、 GitHub リポジトリ を参照してください。ソリューションのデプロイ手順は、リポジトリの README ファイルに含まれています。 前提条件 このソリューションを試すには、以下の前提条件が必要です： AWS アカウント AWS CDK の実行に必要な IAM アクセス権限 フロントエンド実行環境：node.js と npm のインストールが必要 AWS CDK が設定済みである必要があります。詳細については、 チュートリアル: 最初の AWS CDK アプリを作成する を参照してください Amazon Bedrock で使用するモデルへのアクセスが設定されている必要があります。このソリューションでは、Anthropic の Claude 3.5 Sonnet v2 と Amazon Titan Text Embedding V2 を使用します。詳細については、 Add or remove access to Amazon Bedrock foundation models を参照してください アーキテクチャ図に示されているリソースに加えて、AWS CDK デプロイにより以下のリソースと設定が AWS CloudFormation カスタムリソースとして作成されます： Amazon Cognito ユーザープール： tenant-a、tenant-b、tenant-c、tenant-d のユーザー DynamoDB テーブル： ユーザーとテナントのマッピング テナントと OpenSearch 接続先およびインデックスのマッピング OpenSearch Service ドメイン： JWT 認証設定 ベクトル埋め込み用 Ingest pipelines 各テナント用 FGAC ロールとロールマッピング k-NN インデックス Amazon Cognito によるユーザー認証と JWT 生成 このソリューションでは、RAG アプリケーションのユーザー認証に Amazon Cognito ユーザープールを使用します。Amazon Cognito ユーザープールは認証時に JWT を発行します。OpenSearch Service の FGAC では JWT 認証がサポートされているため、ユーザープールから発行されるパブリックキーを OpenSearch Service ドメインに登録することで、Amazon Cognito ユーザープールで認証されたユーザーからのアクセスを許可できます。また、FGAC によるテナントデータアクセス権限分離では、JWT ペイロードに追加できる属性を使用した認可が実行されます。これを実現するため、Amazon Cognito ユーザープールにトークン生成前 Lambda トリガーを設定し、DynamoDB に格納された各ユーザーのテナント ID 情報を取得してトークンに追加します。取得された JWT はフロントエンドで保持され、バックエンドへのリクエストに使用されます。DynamoDB には、ユーザー ID（sub）とテナント ID のマッピングが以下のように格納されています： { "pk": { "S": "membership#<Cognito user ID (sub)>" }, "sk": { "S": "tenant#tenant-a" } } Amazon Cognito でマルチテナント認証を実装するパターンは複数存在しますが、この実装では DynamoDB でのユーザー-テナントマッピングを持つ単一ユーザープールを使用しています。本番環境では追加の考慮事項が必要です。詳細については、 マルチテナントアプリケーションのベストプラクティス を参照してください。 JWT を使用したテナントデータへのリクエストルーティング テナントごとにリソースが分離されるマルチテナントアーキテクチャでは、テナントからのリクエストを適切なリソースにルーティングすることが不可欠です。テナントルーティング戦略の詳細については、 AWS における SaaS アプリケーションのテナントルーティング戦略 を参照してください。このソリューションでは、OpenSearch Service へのルーティングに、この記事で説明されているデータドリブンルーティングに類似したアプローチを使用します。 DynamoDB テーブルには、テナント ID、対象 OpenSearch Service ドメイン、インデックスのマッピング情報が以下のように格納されています： { "pk": { "S": "tenant#tenant-a" }, "sk": { "S": "os_config" }, "os_host": { "S": "<Amazon OpenSearch Service domain endpoint>" }, "os_index": { "S": "tenant-a-index" }, "rag_role": { "S": "tenant-a_role" } } フロントエンドから API Gateway を通じて Lambda 関数に送信される HTTP リクエストの Authorization ヘッダーから JWT を取得します。JWT を解析して取得されるテナント ID を使用してルーティング情報を取得し、ルーティング先を決定します。また、JWT は次のセクションで説明するように、OpenSearch へのリクエストの認証情報としても使用されます。 OpenSearch Service におけるマルチテナントデータ位置とアクセス権限の分離 OpenSearch Service におけるマルチテナントデータ分離戦略には、ドメインレベル、インデックスレベル、ドキュメントレベルの分離という 3 種類の分離パターンと、これらを組み合わせたハイブリッドモデルがあります。このソリューションでは、テナントデータへのアクセス権限制御に FGAC を使用し、テナントごとに専用のロールを作成します。 テナントユーザーと FGAC テナントロールのマッピングは、バックエンドロールを通じて実装されます。OpenSearch Service で利用可能な JWT 認証 では、JWT ペイロード内でバックエンドロールとリンクする属性を Roles key として指定できます。以下のスクリーンショットは、このドメイン設定を示しています。 JWT ペイロードには、以下のように tenant_id 属性が含まれています： "tenant_id": "tenant-a" この属性を OpenSearch JWT 認証の Roles key として設定し、以下のようにロールをマッピングすることで、テナントユーザーと FGAC ロールがリンクされます： { "tenant-a_role": { "backend_roles": [ "tenant-a" ] } } 以下のスクリーンショットは、OpenSearch Dashboards での FGAC におけるテナントロールマッピングの例を示しています。 このソリューションのサンプルでは、tenant-a、tenant-b、tenant-c、tenant-d の 4 つのテナントを提供し、3 つの分離方法すべてを試すことができます。以下の図は、このアーキテクチャを示しています。 各ロールには、対応するテナントデータのみにアクセスできる権限が割り当てられます。このセクションでは、JWT と FGAC を使用して 3 つの分離方法それぞれを実装する方法を紹介します： ドメインレベルの分離 – 各テナントに個別の OpenSearch Service ドメインを割り当てます。この分離パターンではドメインが各テナント専用であるため、ドメイン内でのデータ分離は必要ありません。そのため、FGAC ロールはインデックス全体へのアクセス権限を付与します。以下のコードは、インデックスへのアクセス権限を付与する FGAC ロール定義の index_permissions の一部です： "index_permissions": [ { "index_patterns": [ "*" ], インデックスレベルの分離 – 複数のテナントが OpenSearch Service ドメインを共有し、各テナントに個別のインデックスを割り当てます。各テナントは自分のインデックスのみにアクセスできる必要があるため、FGAC ロールの index_permissions は以下のように設定されます（tenant-b の例）： "index_permissions": [ { "index_patterns": [ "tenant-b-index*" ] ドキュメントレベルの分離 – 複数のテナントが OpenSearch Service ドメインとインデックスを共有し、インデックス内のテナントデータのアクセス権限分離に FGAC のドキュメントレベルセキュリティを使用します。各インデックスにはテナント ID 情報を格納するフィールドが含まれ、そのフィールドに対してドキュメントレベルセキュリティクエリが設定されます。以下のコードは、tenant-c と tenant-d がインデックスを共有する構成で、tenant-c が自分のデータのみにアクセスできる FGAC ロールの index_permissions の一部です： "index_permissions": [ { "index_patterns": [ "tenant-cd-shared-index*" ], "dls": """{"bool": {"must": {"match": {"tenant_id": "tenant-c"}}}}""", 以下のスクリーンショットは、FGAC ロールにおけるドキュメントレベル分離のためのインデックス権限の例を示しています。 考慮事項 この記事の実装では、DynamoDB テーブルと S3 バケットをテナント間で共有するモデルを使用しています。本番環境での使用では、 Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB と Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3 で紹介されているパーティショニングモデルを検討し、要件に基づいて最適なモデルを決定してください。 また、各リソースへのアクセス権限を制限する追加のレイヤーとして、 IAM ポリシーの動的生成 を使用できます。 クリーンアップ 予期しない料金を避けるため、リソースが不要になった場合は削除することをお勧めします。リソースは AWS CDK で作成されているため、cdk destroy コマンドを実行して削除します。この操作により、Amazon S3 にアップロードされたドキュメントも削除されます。 結論 この記事では、マルチテナント RAG において OpenSearch Service をベクトルデータストアとして使用し、JWT と FGAC を使用してデータ分離とルーティングを実現するソリューションを紹介しました。 このソリューションでは、JWT と FGAC の組み合わせを使用して厳密なテナントデータアクセス分離とルーティングを実装するため、OpenSearch Service の使用が必要です。執筆時点では、Amazon Bedrock Knowledge Bases は OpenSearch Service への JWT ベースのアクセスを使用できないため、RAG アプリケーションは独立して実装されています。 マルチテナント RAG の使用は SaaS 企業にとって重要であり、データ分離の厳密さ、管理の容易さ、コストなどの要件によって戦略は異なります。このソリューションでは複数の分離モデルを実装しているため、要件に基づいて選択できます。 マルチテナント RAG 実装に関するその他のソリューションや情報については、以下のリソースを参照してください： Multi-tenant RAG with Amazon Bedrock Knowledge Bases Build a multi-tenant generative AI environment for your enterprise on AWS Self-managed multi-tenant vector search with Amazon Aurora PostgreSQL Multi-tenant vector search with Amazon Aurora PostgreSQL and Amazon Bedrock Knowledge Bases 翻訳はソリューションアーキテクトの福本が担当しました。 著者について Kazuki Nagasawa は、Amazon Web Services のクラウドサポートエンジニアです。Amazon OpenSearch Service を専門とし、お客様の技術的な課題解決に注力しています。プライベートでは、様々な種類のウイスキーを探求したり、新しいラーメン店を発見したりすることを楽しんでいます。 Kensuke Fukumoto は、Amazon Web Services のシニアソリューションアーキテクトです。ISV や SaaS プロバイダーのアプリケーションモダナイゼーションと SaaS モデルへの移行支援に情熱を注いでいます。プライベートでは、バイクに乗ることやサウナに行くことを楽しんでいます。  

こんにちは、ソリューションアーキテクトの宇佐美です。 2025年7月15日に開催された「Neuron Community – Vol.2」の様子をレポートします。 このイベントは、「Neuron Community」の協力のもと開催しました。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。「Neuron Community」は、ユーザー間で AWS Trainium / AWS Inferentia / AWS Neuron の知見共有を促進する場として発足しました。 「Neuron Community」は、主に Discord を使用して運営されています。興味を持っていただいた方は、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq オープニングセッション 常世 大史 （Amazon Web Services Japan G.K.） 資料： Discord 上の Neuron Community 内で公開 しています。 オープニングでは、AWS 内で Trainium と Inferentia を開発している部門、Annapurna Labs 所属の常世より、Neuron Community の立ち上げ経緯と初回イベント「 Neuron Community – Day One 」の振り返り、さらに2025年6月25日・26日に開催された AWS Summit Japan 2025 を Trainium、Inferentia、Neuron の視点から振り返りました。AWS Summit Japanでは、AWS が独自開発を行っている Trainium、Inferentia 等のチップおよび搭載モジュールの実物展示や、Amazon EC2 Trn2 UltraServers の実物大パネル展示を実施したことを紹介しました。 また、 Discord 上で立ち上がった Neuron Community についても改めて紹介しました。Neuron Community は2025年7月19日現在、56名が参加する規模へと成長しています。ユーザー同士が気軽に交流・議論できる場を目指して、コミュニティのさらなる発展を呼びかけました。 ライトニングトーク 清丸 寛一氏（国立情報学研究所）「日本語 LLM の対決の舞台「LLM-jp Chatbot Arena」を支える技術」 資料： Discord 上の Neuron Community 内で公開 していただいています。 国立情報学研究所の清丸氏からは、「日本語 LLM の対決の舞台「LLM-jp Chatbot Arena」を支える技術」と題して、大規模言語モデル (LLM : Large Language Model) を利用したサービス「 LLM-jp Chatbot Arena 」でどのように AWS Trainium を利用しているかについて紹介していただきました。LLM-jp Chatbot Arena は、2つの日本語 LLM の応答を同時に比較し、優れた方に投票できるプラットフォームです。投票の結果は、LLM の改善のために役立てることができます。 LLM-jp Chatbot Arena では、モデルに応じてインスタンスを使い分けており、一番大きなサイズである LLM-jp-3 172B モデル では、Amazon EC2 Trn1 インスタンス (trn1.32xlarge) を推論サーバーとして採用しているとのことです。Amazon EC2 インスタンスタイプは、運用コストを下げることを狙いとして選択されており、GPU ベースの p4d.24xlarge インスタンスと比較した場合、メモリサイズは約 80% になるものの、コストが 約 60% に抑えられる点を評価していただきました。 また、LLM-jp Chatbot Arena のアーキテクチャについても説明していただき、UI サーバーに Gradio 、リクエストルーターに LiteLLM 、 推論サーバーに vLLM を利用しているとのことでした。 Amazon EC2 Trn1 インスタンスを利用した感想は「 想像以上にふつうに動く 」とのことで、チャットボットとして十分な速度で、数ヶ月間止まることなく安定して動作したということです。一方、いくつかの注意点も共有していただき、「 公式の最新ドキュメント 」を参照することが重要というアドバイスをいただきました。 セッションの後の質疑応答も大いに盛り上がっていたのが印象的でした。 吉川 幸弘（Amazon Web Services Japan G.K.）「AWS Summit Japan 2025 デモ再演 ~Inferentia/Trainium で徳得を詰め！推論コスパシミュレーション~」 最後のセッションでは、SA の吉川から AWS Summit Japan 2025 の AWS Builders’ Fair Booth で展示していたデモを再演しました。デモの内容は vLLM に対して大量に推論リクエストを送信し、そのトークン対コストを可視化するというものです。 具体的には以下のようなアーキテクチャで、inf2.24xlarge の EC2 インスタンス 1 台に Llama 3 8B モデルをデプロイして 384 リクエストを同時に送り続け、レスポンスが完了したら次のリクエストを送り続けるインスタンス泣かせなデモアプリケーションです。 以下の写真は実際のデモの様子です。 写真内で投影されているブラウザ内の吹き出しは、それぞれがストリームレスポンスしている AWS Inferentia2 からのレスポンスです。この写真では 9 つの吹き出ししか見えていませんが、実際には 384 の吹き出しがあり、ブラウザのスクロールバーをスクロールすると同様の吹き出しが 384 個ズラっと並んでいます。ちなみに同時処理数を 384 としている背景は TP (tensor parallel size) を 8、 batch size を 128 に設定してモデルを動かす Amazon ECS タスク 3 つを内部に Neuron コアを 24 個持った inf2.48xlarge 1 台で動作させているため、128 batch size × 3 tasks で 384 同時処理にしています。batch size を 128 としていること自体もレイテンシーとスループットが個人的な主観で良さそうだと思ったパラメータがこの設定だっただけで、アクセラレータデバイスのメモリ上これが限界というわけではないというのも面白い部分です。 このデモでは、 Neuronx patterns Construct Library という Inferentia2 / Trainium1 で LLM を簡単に動かすための AWS CDK Construct Library (AWS の Infrastructure as Code Module) を使用しています。このライブラリは、LLM の サーバーを Infrastructure as Code として管理したい方のために、吉川が個人の OSS として開発・公開しているもので、Application Load Balancer と Amazon ECS on EC2 部分の構築に利用しています。 AWS Inferentia2 ハンズオン 「〜推論サーバーを立ち上げてみよう〜」 資料： Discord 上の Neuron Community 内で公開 しています。 イベント後半では、AWS Summit Japan 2025 のセッション「GPU 以外の選択肢！開発チームが徹底解説、効率的な AI 基盤の作り方」の内容を基に、AWS Inferentia2 の実践的なハンズオンを実施しました。参加者の皆様には、以下の2つの推論サーバー構築手順を体験していただきました： Amazon EC2 Inf2 インスタンス (inf2.xlarge) 上で vLLM を利用し、 Llama 3.2 マルチモーダルモデル をデプロイ Amazon SageMaker AI  上で Hugging Face TGI コンテナを利用し、 Qwen 2.5 モデル を簡単にデプロイ ライトニングトークでの活発な質疑応答の結果、ハンズオンの時間が予定より短くなりましたが、Amazon EC2 Inf2 インスタンス上で推論サーバーを立ち上げる手順は理解していただけたかと思います。 使用した日本語のハンズオンコンテンツは Neuron Community で公開 していますので、本イベントに参加できなかった方も、ぜひご自身のペースでお試しください。セルフペースでのハンズオン実施中に困ったことがあれば、コミュニティメンバーに気軽に質問できるのも、ユーザーコミュニティならではの強みですね。 さいごに 第2回目の Neuron Community も、ユーザーの皆さまからたいへん興味深い発表をしていただき、大いに盛り上がりました。質疑応答が盛り上がりすぎて時間が足りなくなったのは、次回への反省点です。 この機会に、Discord の AWS Neuron Community に参加してくれた方も、たくさんいらっしゃったようです。第3回目の Neuron Community も、Discord を中心に募集や告知を行っていきます。興味を持っていただいた方は、ぜひ、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。 染谷 謙太郎 (Someya Kentaro) 通信のお客様を担当するソリューションアーキテクトです。 通信のお客様のクラウド活用を支援しています。 吉川 幸弘(Yoshikawa Yukihiro) デジタルコンテンツを扱うお客様を担当するソリューションアーキテクトです。 AWS CDK に関する知見を活かし、お客様が簡単に AWS リソースを管理できるように取り組んでいます。

この記事は Under the hood: Amazon EKS ultra scale clusters (記事公開日: 2025 年 7 月 16 日) を翻訳したものです。 本日、 Amazon Elastic Kubernetes Service (Amazon EKS) は最大 10 万台のノードをサポートするクラスターの提供を発表しました。 Amazon EC2 の新世代高速コンピューティングインスタンスタイプを活用することで、これは単一の Kubernetes クラスターで 160 万個の AWS Trainium チップまたは 80 万個の NVIDIA GPU を実現することを意味します。これにより、最先端のモデルトレーニング、ファインチューニング、エージェント推論などの超大規模人工知能 (AI) および機械学習 (ML) ワークロードが可能になります。現在 Amazon EKS を直接利用しているお客様だけでなく、EKS をコンピュートレイヤーとして活用する Amazon SageMaker HyperPod with EKS などの他の AI/ML サービスにもこれらの改善が拡張され、AWS の超大規模コンピューティング能力全体を向上させます。 お客様からは、トレーニングジョブのコンテナ化や Kubeflow などのオペレーター、Karpenter のようなプロジェクトを通じたリソースプロビジョニングとライフサイクルの合理化、プラグ可能なスケジューリング戦略のサポート、そして豊富なクラウドネイティブツールのエコシステムへのアクセスが、AI/ML 領域での成功に不可欠であることが明確に示されています。Kubernetes は、強力で拡張可能な API モデルと堅牢なコンテナオーケストレーション機能により、アクセラレーテッドワークロードの迅速なスケーリングと信頼性の高い実行を可能にする重要な要素として注目されています。複数の技術革新、アーキテクチャの改善、オープンソースでのコラボレーションを通じて、Amazon EKS は Kubernetes に完全に準拠しながら、超大規模向けの次世代クラスターコントロールプレーンとデータプレーンを構築しました。 AWS では、結合度が低く水平方向にスケーラブルな汎用アプリケーションを実行するお客様に対して、成長を維持するための戦略として セルベースのアーキテクチャ に従うことを推奨しています。しかし、最先端の AI/ML モデルの開発には、低遅延で高帯域幅の通信を備えた単一の統合システムとして連携する数千のアクセラレーターが必要です。これらを単一のクラスター内で実行することには、いくつかの重要な利点があります。まず、大規模な事前トレーニングからファインチューニング、バッチ推論まで、多様なジョブを実行するための共有されたキャパシティプールを通じて使用率を高めることでコンピューティングコストを削減します。これらのジョブを別々のクラスターに分割すると、キャパシティの断片化や再マッピングの遅延により使用率が低下する可能性があります。次に、巨大なジョブを複数のクラスターに分割すると、スケジューリング、検出、修復などの一元化された操作が複雑になります。代わりに単一のクラスターで実行することで、クラスター間の調整オーバーヘッドを排除し、全体的な信頼性とパフォーマンスを向上させることができます。第三に、ML フレームワークは、グローバルなクラスタービューで実行することを前提としているため、分割クラスターモードでは常にうまく機能するとは限りません。これらが時間の経過とともにマルチクラスターモデルに進化する一方で、私たちはお客様が今日イノベーションを起こせるようにすることが重要だと考えています。 技術的詳細 Kubernetes のコアクラスターアーキテクチャは ここ に示される通りです。Amazon EKS はその上に特定のインフラストラクチャとソフトウェア構成、クラスター管理プレーン、そしてお客様により進んだ AWS 統合を提供するコンポーネント・サービスを構築しています。Kubernetes データストア (etcd) と API サーバーはクラスターの中核を形成し、超大規模を実現する重要な要素です。これに続いて、クラスター全体の操作やノードのローカルな操作を実行する様々なコントローラーがあります。アドオンは、クラスター内で実行されるアプリケーションのサービスディスカバリー、テレメトリ、認証情報の提供などの拡張機能を提供します。アクセラレーテッドワークロードには、ノード管理とモニタリングのためのデバイスプラグインやデーモンなど、広範なアドオンが必要です。クラスター領域の外では、Amazon EKS 管理プレーンの様々なサービスが継続的にすべてのクラスターのセキュリティ確保、スケーリング、更新を行っています。この取り組みの一環として、私たちはこれらすべてのコンポーネントとサービスが 10 万台のノード規模でシームレスに動作するように設計し、継続的な統合テストを通じて継続的に検証しています。詳細を見ていきましょう。 次世代データストア etcd は強力な一貫性を持つ分散キーバリューデータベースで、Kubernetes API のストレージバックエンドを提供します。内部的には、 Raft コンセンサスアルゴリズムを使用して、すべてのクラスターメンバー間で一貫性のあるレプリケーションされた トランザクションログ を維持します。各メンバーはログのコピーを保持し、クラスターメンバーの過半数（またはクォーラム）がそのログに永続化した後にのみ、特定のトランザクションがローカルデータベースの状態に適用されます。etcd の管理とスケーリングは大きな負担であり、私たちはすでにこれをお客様から抽象化しています。私たちは etcd アーキテクチャに複数のイノベーションを導入し、Kubernetes に完全に準拠しながら、次世代のクラスターパフォーマンスをお客様に提供しています。私たちはオープンソースの etcd プロジェクトの成功に引き続き投資し、確かな etcd コアだけがこのような進歩への道を開くことができると信じています。 コンセンサスのオフロード: 根本的な変更を通じて、Amazon EKS は etcd のコンセンサスバックエンドを Raft ベースの実装から Journal にオフロードしました。Journal は AWS で 10 年以上にわたって構築してきた内部コンポーネントで、マルチ アベイラビリティゾーン (AZ) の耐久性と高可用性を備えた超高速の順序付きデータレプリケーションを提供します。コンセンサスを Journal にオフロードすることで、クォーラム要件に縛られることなく etcd レプリカを自由にスケールでき、ピアツーピア通信の必要性を排除しました。様々な回復力の向上に加えて、この新しいモデルは Journal の堅牢な I/O 最適化データプレーンを通じて、お客様に優れた予測可能な読み取りと書き込みの Kubernetes API パフォーマンスを提供します。 インメモリデータベース: etcd の耐久性は、基本的には基盤となるトランザクションログの耐久性によって決まります。なぜなら、ログによってデータベースが過去のスナップショットから復元できるようになるからです。Journal がログの耐久性を担当するため、私たちはもう一つの重要なアーキテクチャの進歩を可能にしました。etcd の マルチバージョン同時実行制御 (MVCC) レイヤーを永続化するバックエンドである BoltDB を、ネットワーク接続型の Amazon Elastic Block Store ボリュームから tmpfs を使用した完全なインメモリストレージに移行しました。これにより、より高い読み取りと書き込みのスループット、予測可能なレイテンシー、より高速なメンテナンス操作という形で桁違いのパフォーマンス向上が実現します。さらに、障害時の平均復旧時間 (MTTR) を低く保ちながら、サポートされる最大データベースサイズを 20 GB に倍増しました。 パーティション化されたキースペース: Kubernetes はネイティブに etcd クラスターをリソースタイプごとにパーティション化することをサポートしており、異なるタイプのキーの間でのシリアライズ可能なトランザクションを必要としません。etcd 自体は単純化のために現在キースペースのパーティション化をネイティブにサポートしていませんが、超大規模クラスターは、ホットなリソースタイプを別々の etcd クラスターに分割することで大きな恩恵を受けます。最適なパーティション化スキームにより、Amazon EKS は長年にわたって Kubernetes 向けに進化してきた etcd の豊富な API セマンティクスを引き続き使用しながら、書き込みスループットを最大 5 倍に向上させました。私たちの新しいアーキテクチャは動的な再パーティション化を可能にしますが、適切に割り当てられた静的なパーティションが 10 万台のノード規模をサポートするのに十分であることがわかりました。これらの改善は、超大規模向けの機能が有効化された新しい EKS クラスターでのみ利用可能です。 図 1. 再構築前後の Amazon EKS etcd サーバー 極限のスループットを持つ API サーバー Amazon EKS の Kubernetes API サーバーは現在、垂直方向と水平方向に自由にスケールでき、これは様々な利用のシグナルに応じて読み取りスループットと watch のファンアウトを増加させるために既に使用している戦略です。一方、書き込みスループットは主に etcd によって決定され、そこでの改善についてはすでに説明しました。以下では、Amazon EKS クラスターの Kubernetes v1.33 以降で提供される超大規模を可能にするための更なる強化について説明します。 API サーバーとウェブフックのチューニング: 大規模なトラフィックパターン、特にアクセラレーテッドワークロードでは、リソース効率とスケーラビリティのトレードオフを調整する方法で API サーバーと重要なウェブフックをチューニングすることが非常に適しています。リクエストタイムアウト、再試行戦略、並列処理、スロットリングルール、HTTP 接続の存続時間、ガベージコレクション、etcd クライアント設定など、様々な構成を慎重にチューニングすることで最適なパフォーマンスを達成しました。このようなチューニングはほとんどのワークロードには有益ではありませんが、数万ノードでのスループットとクラスターの信頼性向上には非常に効果的です。 キャッシュからの整合性のある読み取り: Kubernetes v1.31 では、 キャッシュからの強力な整合性のある読み取り が導入され、読み取りトラフィックの大部分を etcd から API サーバーにオフロードできるようになりました。以前は、ラベルやフィールドベースのフィルタリングを必要とする読み取り（例えば、Kubelet がノードに割り当てられた Pod を list する場合）では、API サーバーがまず etcd から全コレクションを list して、その後メモリ内でフィルタリングを実行してクライアントにレスポンスを送信していました。新しいメカニズムは etcd とのキャッシュの鮮度を追跡し、最新の場合は API サーバーのキャッシュから直接読み取りを提供します。サーバー側の CPU 使用率を 30% 削減し、list リクエストを 3 倍高速化することで、大幅な読み取りスループットの向上が明らかになりました。超大規模テストの一環として、ページ分割された読み取りを行うクライアントが v1.33 で不必要に etcd にフォールバックしていることを 発見 し、v1.33.3 でこれを修正して、大量のリクエストが同時に発生するシナリオでのクラスターの安定性を回復させました。 大規模コレクションの効率的な読み取り: 大規模クラスターには大量オブジェクトのコレクションが伴います。これらを効率的に list することは、reconciliation loop を開始する前に全コレクションをフェッチする必要がある Kubernetes コントローラーの前提条件です。例えば、Anthropic はジョブスケジューラーでこれを必要としていました。Kubernetes v1.33 で有効化された list レスポンスのストリーミング 機能は、コレクション全体を一度にバッファリングするのではなく、コレクション内のアイテムを段階的にエンコード・送信することで、メモリ効率を向上させ、それによって API サーバーの list リクエストの同時実行性 (約 8 倍) を改善しました。 カスタムリソースのバイナリエンコーディング: Kubernetes カスタムリソース (CR) は、トレーニングジョブ、パイプライン、推論サービスをモデル化するために Kubeflow などの ML フレームワークで広く使用されています。これらのリソースは、非効率な JSON エンコーディングのため、大規模にそれらを保存、処理、クライアントに送信する際にサーバー側で大きなオーバーヘッドが生じます。Kubernetes v1.32 でアルファ版の機能として導入された Concise Binary Object Representation (CBOR) エンコーディング は、より効率的な代替手段を提供します。バイナリエンコーディングを使用してペイロードサイズとシリアル化のオーバーヘッドを最大 25% 削減し、CR の処理を高速化・低コスト化します。これは、AI/ML のお客様が一般的に使用するノードデーモンなど、高スループットで高カーディナリティの CR クライアントにも利点があります。この機能は現在、アップストリームではデフォルトで有効になっていないことに注意してください。私たちはパフォーマンスをベンチマークして、ベータ版への昇格を支援しています。 超高速クラスターコントローラー クラスタースコープで動作するコントローラーは通常、集中的なクラスター操作（Pod のスケジューリングなど）を実行するためにリソースのグローバルビューを維持する必要があります。高可用性のために複製されていますが、多くの場合、競合を避けるために「リーダー」レプリカのみが実際の作業を行っています。クラスターが大きくなるほど、メモリに保持する状態が大きくなり、依存関係の TPS が増加し、大量の決定を下す必要があります。ほとんどのコントローラーは、複数のワーカースレッドとロックセーフなワークキューを通じて、受信した作業を並列に処理できます。十分なリソースがあれば、コントローラーが達成するスループットは多くの場合、ワーカーの並列性または依存関係のレート制限によって制限されます。これらを改善することで、多くの Kubernetes および EKS コントローラーのスループットを向上させました。しかし、超大規模を達成するには、これを超えてコントローラーのアーキテクチャを改善する必要がありました。 ロックの競合を最小化: Kubernetes コントローラーは Informer パターンを広く使用しています。これは、リソースのローカルなインメモリキャッシュを維持し、変更が発生したときに登録されたハンドラーに通知することで、Kubernetes リソースの変更を効率的に追跡して対応するメカニズムです。変更自体は、Kubernetes API サーバーとの長時間実行される watch の接続を通じて配信されます。コントローラーのワーカースレッドが大規模な list を実行すると、共有された Informer のキャッシュで高い読み取りと書き込みのロック競合が発生し、受信イベントの処理が遅延し、キューの滞留、高いメモリ使用量、最終的には輻輳崩壊などの様々な二次的な影響を引き起こすことを観察しました。私たちはこの問題についてアップストリームで 広範な調査 を行い、大規模な list リクエストを最適化するインデックスを追加することで、いくつかの主要なコントローラーを修正しました。さらに、 バッチ処理 により、変更率の高いシナリオでのイベント処理スループットを最大 10 倍向上させました。これらの改善をアップストリームに継続的に貢献しています。 スケジューリングの最適化: お客様は現在、独自のスケジューラーを導入し、デフォルトの Kubernetes スケジューラー (KS) の代わりに、または併用して使用できます。特定の AI/ML ワークロードは、ギャングスケジューリングとプリエンプションを効率的に実行するジョブスケジューラーの恩恵を受けます。しかし、KS は Kubernetes の DaemonSet、Deployment、Job、StatefulSet に一般的に使用される最も汎用的なスケジューラーであり続けています。ほとんどのコントローラーとは異なり、KS は正確性を満たすために Pod を直列に処理するため、そのスループットは本質的にレイテンシーに制約されています。大規模クラスターでは、評価するノードが多いため、このレイテンシーが悪化します。しかし、ワークロードに基づいてスケジューラープラグインを慎重に調整し、ノードのフィルタリングとスコアリングのパラメータを最適化することで、10 万台のノード規模でも一貫して 毎秒 500 Pod という高いスループットを達成しました。 Karpenter の強化 Karpenter は、Kubernetes のための柔軟で高性能なノードライフサイクル管理プロジェクトで、AWS が主導しています。Pod のスケジューリングニーズに基づいて適切なサイズのノードを自動的にプロビジョニングし、使用率の低いノードを統合することで、お客様がクラスターを効率的にスケールしてコストを最適化するのに役立ちます。お客様は多くの場合、汎用ワークロードとアクセラレーテッドワークロードを同じクラスターで実行し、Karpenter でコンピュートを統一的に管理したいと考えています。しかし、いくつかの制限により、超大規模 AI/ML ワークロードに理想的に適合しませんでした。私たちはこれらの問題を解決するために Karpenter を進化させました。 超大規模のための保証されたキャパシティ: ML トレーニングジョブは特定のパターンでバッチ処理されることがよくあります。Karpenter のリアクティブなプロビジョニングモデルはこれを予測せず、大規模なジョブが同時に到着したときにプロビジョニングの遅延を引き起こす可能性があります。この問題に対処するために、静的キャパシティのサポートを導入しました。静的ノードプールを使用することで、お客様はクラスター内の最小限のノードセットを一貫して作成および維持でき、それによって長期間実行される AI/ML ワークロードのためのキャパシティを保証できます。また、NodeClass API で EC2 Capacity Blocks for ML のサポートも追加しました。キャパシティブロックは、モデルトレーニング、ファインチューニング、実験の実行、推論需要の急増に備えるのに理想的です。Karpenter は、他のキャパシティタイプにフォールバックする前に、静的キャパシティをプロビジョニングする際にキャパシティブロックの使用を優先します。これらの変更はまもなくアップストリームに反映される予定です。 アクセラレーテッドコンピュートの自動修復: アクセラレーターの故障は稀ですが、発生すると AI/ML ワークロードに混乱をもたらす可能性があります。健全性の低下を検出するために EKS ノードモニタリングエージェント と Karpenter の ノード修復 機能を使用することで、お客様は必要に応じて異常なノードの自動交換を実行できます。同様に、お客様は Amazon EKS 最適化アクセラレーテッド AMI などのコンピュート構成の更新を推進するためにドリフト機能を活用できます。私たちは Karpenter の様々なコントローラーを並列化して、スケール時のパフォーマンスを向上させました。さらに、テスト中にメモリ割り当てや依存する API の非効率な呼び出しによるいくつかのボトルネックを発見しました。リソース使用量を最適化し、冗長な API 呼び出しを排除し、適切な操作をバッチ処理するために、これらのコードパスを最適化しました。これらの変更はすべて、超大規模でのノード修復とドリフトのレイテンシーの改善に役立ち、アップストリームで利用可能になっています。 クラスターネットワークのスケーリング Amazon EKS は Kubernetes Pod のネイティブ VPC ネットワーキングをサポートし、オーバーレイネットワークのオーバーヘッドを回避します。また、 カスタムサブネット 、 セキュリティグループ 、アクセラレーテッドワークロード向けの Elastic Fabric Adapter (EFA) サポートなどの進んだネットワーク統合も可能にします。お客様は、トラフィックを処理するロードバランサーとバックエンド Pod 間のネットワークホップを排除することで、アプリケーションの高いパフォーマンスを実現できます。以下の機能強化により、超大規模 AI/ML 機能がさらに向上しました。 IP 割り当てからウォームプレフィックスへの移行: クラスタースケールが大きくなるにつれて、 Network Address Usage (NAU) メトリクスを計画する必要があります。各 NAU ユニットは VPC のサイズを表す合計に貢献し、VPC は最大 256,000 NAU、または別の VPC とピアリングされている場合は 512,000 NAU をサポートできます。デフォルトでは、各 Pod は現在クラスター VPC から個別の IP アドレスを取得します。IP アドレスと IP プレフィックス はプレフィックスサイズに関係なく単一の NAU ユニットとしてカウントされるため、超大規模クラスターでアドレス管理に プレフィックスモード を使用するように Amazon VPC CNI を構成しました。さらに、プレフィックスの割り当ては、Amazon VPC CNI がノード起動後にノードからローカルにネットワークメタデータを検出する形で、Karpenter によってインスタンス起動パスで直接行われました。これらの改善により、10 万台のノード用の単一の VPC でネットワークを合理化しながら、ノードの起動速度を最大 3 倍に高速化することができました。 ネットワークパフォーマンスの最大化: 巨大なペタバイト規模のデータセットでトレーニングする場合、ネットワーク帯域幅がボトルネックになる可能性があります。超大規模 AI/ML ワークロードでは、 Amazon S3 から膨大なデータをクラスターにプルする必要がよくあります。データを待つ間にアクセラレーターがアイドル状態になるのを避けるために、ストレージレイヤーとノード間の高帯域幅データ転送が必要です。デフォルトでは、Amazon VPC CNI は Pod に割り当てられた Elastic Network Interface (ENI) に対して 1 つの ネットワークカード を選択します。このネットワークカードは、Pod のすべての送受信トラフィックを処理します。複数のネットワークカードをサポートする高速コンピューティングインスタンスタイプでは、追加のネットワークカードに Pod ENI を作成するプラグインサポートを有効にしました。これにより、Pod のネットワーク帯域幅容量（100 GB/s 以上）とパケットレート性能が向上し、それによってアクセラレーターの使用率も向上しました。 高速コンテナイメージプル 超大規模 AI/ML ワークロードでは、PyTorch トレーニング、TensorFlow ノートブック、SageMaker ディストリビューションなど、5 GB を超える大規模なコンテナイメージを使用する傾向があることを観察しました。コンテナイメージのダウンロードと展開の速度は、ワークロードの準備において重要な要素です。私たちは Seekable OCI (SOCI) 高速プル を導入し、ダウンロードと展開の並列処理を可能にしました。SOCI 高速プルは大きなレイヤーをチャンクでダウンロードし、このステップをより速く完了させます。次に、Trn2 ならびに P5e と P6 インスタンスタイプの両方でサポートされている高い Elastic Block Store (EBS) IOPS (260k) とスループット (10 GB/s) を活用して、展開時間を短縮しました。各レイヤーが完了するのを待ってから次のレイヤーを開始するのではなく、複数のレイヤーを同時に解凍して処理できる並列展開を導入しました。私たちのテストでは、デフォルトと比較して全体的なイメージのダウンロードと展開が最大 2 倍高速化されることが示されています。さらに、ワーカーノード VPC に Amazon S3 VPC エンドポイントを作成し、アベイラビリティゾーンあたり 100 GB/s の帯域幅を保証しました。これにより、コンテナイメージレイヤーのダウンロード中に十分なスループットが確保され、ノードの準備が大幅に高速化されました。 規模のテスト 私たちのテスト方法の重要な原則は、お客様と緊密に協力し、お客様のニーズから逆算して作業することです。これは、実際の超大規模 AI/ML ワークロードと、それらの成功を可能にする統合を模倣することを意味します。これには、大規模な分散事前トレーニングジョブから複数の同時ファインチューニングまたは蒸留ジョブ、高スループット推論の提供まで、幅広いワークロードをカバーする必要がありました。アクセラレーテッドインフラストラクチャを活用するには、クラスターがコンピュート・ネットワーク・ストレージ用の様々なデバイスプラグインを実行し、 Amazon ECR 、 Amazon FSx 、 Amazon S3 などの重要な AWS サービスを利用する必要もあります。さらに、AI/ML のお客様は一般的に、ヘルスモニタリング（ EKS ノードモニタリングエージェント ）、テレメトリ（ Amazon CloudWatch エージェント 、 NVIDIA DCGM サーバー ）、アプリケーション認証情報（ EKS Pod Identity エージェント ）、イメージキャッシュのためのノードエージェントをインストールします。広範なテストを通じて、これらすべてのコア機能が 10 万台のノードでシームレスにスケールし、信頼性高く動作することを検証しました。 ノードライフサイクル まず、Karpenter を使用して、ノードプールとインスタンスタイプの組み合わせで 10 万台の Amazon EC2 インスタンスを起動しました。これは 50 分で完了し、1 分あたり 2000 の準備完了ノードがクラスターに参加するレートでした。次に、新しい AMI にすべてのノードを更新する ドリフト を実行しました。これはお客様にとって一般的な Day-2 オペレーションです。Karpenter はノードの Disruption Budget を尊重しながら、約 4 時間でクラスター全体をドリフトさせることができました。最後に、Karpenter ですべてのノードを 70 分でスケールダウンしました。以下のグラフは、それぞれプロビジョニング、ドリフト、終了のタイムラインを示しています。 図 2. 10 万台のノードプロビジョニングのタイムライン 図 3. Karpenter によるドリフトのタイムライン 図 4. ノード終了のタイムライン ワークロードテスト 私たちのテストは 3 つのシナリオをカバーしました。すべての 10 万台のノードで実行される大規模な事前トレーニングジョブ、それぞれ 1 万台のノードを使用する 10 の並列ファインチューニングジョブ、そして 7 万台のノードでファインチューニングジョブを実行し、3 万台のノードで大規模推論を提供する混合モードのワークロードです。Amazon ECR からプルした vLLM モデルサーバーと Amazon FSx からロードされたモデルの重みを使用して、Meta Llama-3.2-1B-Instruct で推論を提供するために LeaderWorkerSet を使用しました。最大 10 万個の異種の AI Pod を実行するクラスターを観察してください。 図 5. 10 万台のノードで実行される AI/ML テストシナリオ クラスターがこれらのワークロードを処理する際、高い Kubernetes API の読み取りスループット (左) と書き込みスループット (右) が問題なく提供されます。 図 6. 高スループットの読み取りと書き込みリクエスト そして、p99 API レイテンシーは、get と write (左) の 1 秒と list (右) の 30 秒という Kubernetes SLO ターゲット 内に十分収まっています。 図 7. SLO ターゲット内の Kubernetes API リクエストレイテンシー クラスターには 10 万台のノードと 90 万個の Pod を含む 1000 万個以上の Kubernetes オブジェクト (左) と、パーティション全体で 32 GB に達する集約された etcd データベースサイズ (右) が含まれています。 図 8. 1000 万個以上のオブジェクトを持つ 32 GB の etcd データベース Kubernetes スケジューラーは一貫して毎秒最大 500 Pod のスループット (左) を提供し、クラスターコントローラーは短いワークキューの待ち行列 (右) を維持しながら処理に対応できました。 図 9. 毎秒 500 Pod のスケジューラースループットと短いコントローラーワークキューの待ち行列 クラスターの回復力 クラスターの回復力をテストするために、1000 ノードにわたって健全性の低下を誘発し、EKS ノードモニタリングエージェントがそれらを検出して異常としてマークし、Karpenter がそれらを健全な新しいノードに置き換えるノード自動修復を実行するまでの時間を測定しました。全体として、劣化した 1000 ノードすべてが 5 分以内に健全な新しいノードに置き換えられました (左)。また、150 万 QPS でクラスター DNS クエリを引き起こしました。 EKS CoreDNS オートスケーラー が Deployment のレプリカを 4000 にスケールすることで、p99 クエリレイテンシーは 1 秒未満に保たれました (右)。 図 10. 1000 ノード障害と 150 万 QPS DNS クエリに対するクラスターの回復力 まとめ Amazon EKS の 10 万台のノードクラスターのサポートは、超大規模 AI/ML インフラストラクチャにおける画期的な進歩を表しており、お客様は単一の統合システムで最大 160 万個の AWS Trainium チップまたは 80 万個の NVIDIA GPU をデプロイできるようになりました。etcd コンセンサスを AWS のマルチ AZ の Journal システムにオフロードするなどの一連のアーキテクチャ改善と様々な最適化により、Kubernetes に完全に準拠しながら桁違いのパフォーマンス向上を達成しました。これらのイノベーションは、Anthropic のようなお客様が最先端のモデルトレーニングと推論ワークロードを大規模で実行できるようにするだけでなく、Amazon SageMaker HyperPod などの Amazon のより広範な AI/ML サービス基盤も強化します。生成 AI が計算要件の限界を押し上げ続ける中、私たちは前例のない信頼性、パフォーマンス、規模で次世代のアクセラレーテッドワークロードをサポートする準備ができています。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本記事は、2025 年 7 月 21 日に公開された Optimizing vector search using Amazon S3 Vectors and Amazon OpenSearch Service を翻訳したものです。翻訳は Solutions Architect の 深見 が担当しました。 注: 2025 年 7 月 22 日現在、Amazon S3 Vectorsと Amazon OpenSearch Service の統合機能はプレビューリリースであり、今後変更される可能性があります。 ベクトル埋め込み と類似度検索機能の進歩に伴い、データの保存と検索方法が急速に進化しています。ベクトル検索は、生成 AI やエージェント AI などの最新のアプリケーションにとって不可欠なものとなっています。しかし、大規模なベクトルデータを管理することは大きな課題があります。組織は、数百万または数十億ものベクトル埋め込みを保存して検索する際、レイテンシー、コスト、精度のトレードオフに悩まされることが多くあります。従来のソリューションでは、大規模なインフラストラクチャの管理が必要になるか、データ量が増えるにつれて非常に高額なコストがかかります。 私たちは、 Amazon Simple Storage Service (Amazon S3) Vectors と Amazon OpenSearch Service の 2 つの統合機能のパブリックプレビューを公開しました。これにより、ベクトル埋め込みをより柔軟に格納および検索することができるようになります。 コスト最適化されたベクトルストレージ : OpenSearch Service マネージドクラスターは、マネージドサービスの S3 Vectors を使用してコスト最適化されたベクトル格納を行います。この統合により、レイテンシーの増加を許容してでもコストを抑えつつ、高度な OpenSearch の機能 (ハイブリッド検索、高度なフィルタリング、地理フィルタリングなど) を利用したい OpenSearch のワークロードをサポートします。 S3 Vectors からのワンクリックエクスポート : S3 ベクトルインデックスから OpenSearch Serverless コレクションへのワンクリックエクスポートにより、高パフォーマンスのベクトル検索が可能になります。S3 Vectors 上にベクトルストアを構築されたお客様は、より高速なクエリパフォーマンスを得るために OpenSearch を利用できるメリットがあります。 これらの統合を利用することで、頻繁にクエリされないベクトルを S3 Vectors に保持し、ハイブリッド検索や集計などの高度な検索機能を必要とするようなレイテンシの制約が最も高い操作には OpenSearch を使用することで、ベクトルワークロードを賢く分散させ、コスト、レイテンシー、精度を最適化できます。さらに、OpenSearch のパフォーマンスチューニング機能 (量子化、k 近傍 (knn) アルゴリズム、メソッド固有のパラメータ) は、コストや精度をほとんど妥協することなく、パフォーマンスを向上させるのに役立ちます。 この投稿では、ベクトル検索の実装に柔軟なオプションを提供しながら、このシームレスなインテグレーションについて説明します。コスト最適化されたベクトル格納のために、OpenSearch Service マネージドクラスターで新しい S3 Vectors エンジンタイプを使用する方法と、高パフォーマンスのシナリオで 10ms という低レイテンシーの持続的なクエリが必要な場合に、S3 Vectors から OpenSearch Serverless コレクションへのワンクリックエクスポートを使用する方法を学びます。この投稿の最後には、パフォーマンス、コスト、スケーラビリティの具体的な要件に基づいて、適切なインテグレーションパターンを選択して実装する方法がわかります。 サービスの概要 Amazon S3 Vectors は、およそ 1 秒以内のベクトル検索機能をネイティブでサポートする初めてのクラウドオブジェクトストアで、インフラストラクチャ管理は不要です。Amazon S3 の簡単さ、耐久性、可用性、コスト効率性に、ネイティブのベクトル検索機能を組み合わせたものです。ベクトル埋め込みを直接 S3 に保存して検索できます。Amazon OpenSearch Service は、ベクトルワークロードに対してマネージドクラスターと サーバーレスコレクションの 2 つの補完的なデプロイメントオプションを提供しています。どちらも Amazon OpenSearch の強力なベクトル検索と検索機能を活用しますが、それぞれが異なるシナリオに適しています。OpenSearch ユーザーにとって、S3 Vectors と Amazon OpenSearch Service の統合により、ベクトル検索アーキテクチャを最適化する前例のない柔軟性が得られます。リアルタイムアプリケーションに超高速のクエリパフォーマンスが必要な場合も、大規模なベクトルデータセットに低コストのストレージが必要な場合も、この統合により、特定のユースケースに最適なアプローチを選択できます。 ベクトル格納オプションの理解 OpenSearch Service は、さまざまなユースケースに最適化された、ベクトル埋め込みを格納および検索するための複数のオプションを提供しています。Lucene エンジン (OpenSearch のネイティブ検索ライブラリ) は、 Hierarchical Navigable Small World (HNSW) 手法を実装しており、効率的なフィルタリング機能と OpenSearch のコア機能との強力な統合を提供します。さらなる最適化オプションが必要なワークロードの場合、 Faiss エンジン (Facebook AI Similarity Search) は、 HNSW と IVF (Inverted File Index) の両方の手法 の実装に加えて、ベクトル圧縮の機能を提供します。HNSW はベクトル間の接続の階層的なグラフ構造を作成し、検索時の効率的なナビゲーションを可能にします。一方、IVF はベクトルをクラスター化し、クエリ時に関連するサブセットのみを検索します。S3 エンジンタイプの導入により、Amazon S3 の耐久性とスケーラビリティを活用しながら、およそ 1 秒以内のクエリパフォーマンスを維持できる、コスト効率の高いオプションが利用可能になりました。このように多様なオプションから、パフォーマンス、コスト、精度に関する特定の要件に基づいて最適なアプローチを選択できます。たとえば、アプリケーションが 50 ms 未満のクエリレスポンスと効率的なフィルタリングを必要とする場合、Faiss の HNSW 実装が最適な選択肢です。一方、ストレージコストを最適化しながら妥当なパフォーマンスを維持する必要がある場合は、新しい S3 エンジンタイプがより適切でしょう。 ソリューションの概要 この投稿では、2 つの主要な統合パターンについて説明します。 OpenSearch Service マネージドクラスターをマネージドサービスの S3 Vectors と使用して、ベクトルストレージのコストを最適化する OpenSearch Service ドメインを既に使用しており、およそ 1 秒以内のクエリパフォーマンスを維持しながらコストを最適化したいお客様向けに、新しい Amazon S3 エンジンタイプが魅力的なソリューションを提供します。OpenSearch Service は、Amazon S3 でのベクトル格納、データ取得、キャッシュ最適化を自動的に管理するため、運用オーバーヘッドがなくなります。 S3 ベクトルインデックスから OpenSearch Serverless コレクションへのワンクリックエクスポートにより、高性能なベクトル検索が可能に より高速なクエリパフォーマンスが必要なユースケースでは、S3 ベクトルインデックスからベクトルデータを OpenSearch Serverless コレクションに移行できます。この方法は、リアルタイムのレスポンスタイムが必要なアプリケーションに最適で、 Amazon OpenSearch Serverless の利点を得られます。これには、高度なクエリ機能とフィルタ、自動スケーリングと高可用性、管理の手間がかからないことが含まれます。エクスポートプロセスでは、スキーママッピング、ベクトルデータ転送、インデックス最適化、接続設定が自動的に処理されます。 次の図は、Amazon OpenSearch Service と S3 Vectors の間の 2 つの統合パターンを示しています。 前提条件 始める前に、次の項目について確認してください。 AWS アカウント Amazon S3 と Amazon OpenSearch Service へのアクセス権 OpenSearch Service ドメイン (１ 番目の統合パターンの場合) S3 ベクトルに格納されたベクトルデータ (2 番目の統合パターンの場合) 統合パターン 1 : S3 Vectors を使用した OpenSearch Service マネージドクラスター このパターンを実装するには: OpenSearch バージョン 2.19 で OR1 インスタンス を使用して OpenSearch Service ドメインを作成 します。 OpenSearch Service ドメインを作成する際、 Advanced features セクションで Enable S3 Vectors as an engine option を選択します。 OpenSearch Dashboards にサインイン し、 Dev tools を開きます。次に、knn インデックスを作成し、 engine として s3vector を指定します。 PUT my-first-s3vector-index { "settings": { "index": { "knn": true } }, "mappings": { "properties": { "my_vector1": { "type": "knn_vector", "dimension": 2, "space_type": "l2", "method": { "engine": "s3vector" } }, "price": { "type": "float" } } } } ベクトルを Bulk API を使ってインデクシングします: POST _bulk { "index": { "_index": "my-first-s3vector-index", "_id": "1" } } { "my_vector1": [2.5, 3.5], "price": 7.1 } { "index": { "_index": "my-first-s3vector-index", "_id": "3" } } { "my_vector1": [3.5, 4.5], "price": 12.9 } { "index": { "_index": "my-first-s3vector-index", "_id": "4" } } { "my_vector1": [5.5, 6.5], "price": 1.2 } { "index": { "_index": "my-first-s3vector-index", "_id": "5" } } { "my_vector1": [4.5, 5.5], "price": 3.7 } { "index": { "_index": "my-first-s3vector-index", "_id": "6" } } { "my_vector1": [1.5, 2.5], "price": 12.2 } 通常どおり knn クエリを実行します: GET my-first-s3vector-index/_search { "size": 2, "query": { "knn": { "my_vector1": { "vector": [2.5, 3.5], "k": 2 } } } } 次のアニメーションは、上記の手順 2 から 4 を示しています。 統合パターン 2 : S3 ベクトルインデックスを OpenSearch Serverless にエクスポート このパターンを実装するには: Amazon S3 の AWS マネジメントコンソールに移動し、S3 Vector Bucket を選択します。 エクスポートしたいベクトルインデックスを選択します。 Advanced search export の下にある Export to OpenSearch を選択してください。 または、次のようにすることもできます。 OpenSearch Service コンソールに移動します。 ナビゲーションペインから Integrations を選択します。 ここに Import S3 vectors to OpenSearch vector engine – preview という新しい統合テンプレートが表示されます。 Import S3 vector index を選択してください。 次に、 Export S3 vector index to OpenSearch vector engine テンプレートが事前に選択され、S3 ベクトルインデックスの Amazon リソースネーム (ARN) が事前に入力された Amazon OpenSearch Service 統合コンソールに移動します。 必要な権限 を持つ既存のロールを選択するか、新しいサービスロールを作成してください。 下にスクロールして Export を選択し、新しい OpenSearch Serverless コレクションを作成し、S3 ベクトルインデックスからデータを OpenSearch knn インデックスにコピーする手順を開始します。 OpenSearch Service コンソールの インポート履歴 ページに移動します。ここで、S3 ベクトルインデックスを OpenSearch サーバーレス knn インデックスに移行するために作成された新しいジョブが表示されます。ステータスが In Progress から Complete に変わったら、 新しい OpenSearch サーバーレスコレクションに接続 し、 新しい OpenSearch knn インデックスをクエリ できます。 次のアニメーションは、新しい OpenSearch サーバーレスコレクションに接続し、Dev ツールを使用して新しい OpenSearch knn インデックスをクエリする方法を示しています。 クリーンアップ 継続的な課金を避けるには: パターン 1 の場合: S3 Vectors を使用する OpenSearch インデックスを削除 します。 不要になった場合は、 OpenSearch Service マネージドクラスターを削除 します。 パターン 2 の場合: OpenSearch Service コンソールの Import history セクションからインポートタスクを削除します。このタスクを削除すると、インポートタスクによって自動的に作成された OpenSearch ベクトルコレクションと OpenSearch 取り込みパイプラインの両方が削除されます。 結論 Amazon S3 Vectors と Amazon OpenSearch Service の革新的な統合は、ベクトル検索技術の変革的な到達点を示し、企業に前例のない柔軟性とコスト効率を提供します。この強力な組み合わせは、それぞれのサービスの長所を兼ね備えています。Amazon S3 の高い耐久性とコスト効率が、OpenSearch の高度な AI 検索機能とシームレスに融合しています。企業は今や、ベクトル検索ソリューションを数十億ものベクトルまでスケールアップできるようになり、レイテンシー、コスト、精度を制御できるようになりました。OpenSearch Service を使って 10ms という極めて高速なクエリ性能を優先するか、S3 Vectors を使ってコスト最適化された秒未満の優れた性能を実現するか、OpenSearch で高度な検索機能を実装するかに応じて、この統合はお客様のニーズに合った完璧なソリューションを提供します。OpenSearch マネージドクラスターで S3 Vectors エンジンを試し、S3 ベクトルインデックスから OpenSearch Serverless への 1 クリックエクスポートをテストすることで、今すぐ始めることをお勧めします。 詳細については、以下をご覧ください。 Amazon S3 Vectors のドキュメント Amazon OpenSearch Service のドキュメント OpenSearch Service と Amazon S3 Vectors の統合 Amazon OpenSearch Service ベクトルデータベースのブログ 著者について Sohaib Katariwala は、シカゴに拠点を置く Amazon OpenSearch Service を専門とする AWS のシニアスペシャリストソリューションアーキテクトです。彼の関心は、データとアナリティクス全般にあります。特に、顧客が AI を活用してデータ戦略を立て、現代の課題を解決することを支援することに情熱を注いでいます。 Mark Twomey は、ストレージとデータ管理に特化した AWS のシニアソリューションアーキテクトです。適切なタイミングで適切な場所に適切なコストでデータを配置できるよう、お客様と協力することを楽しんでいます。アイルランド在住の Mark は、田舎を散歩したり、映画を観たり、本を読むことが好きです。 Sorabh Hamirwasia は、OpenSearch プロジェクトで働く AWS のシニアソフトウェアエンジニアです。主な関心事は、コスト最適化された高性能な分散システムの構築です。 Pallavi Priyadarshini は、Amazon OpenSearch Service の Senior Engineering Manager で、検索、セキュリティ、リリース、ダッシュボードの高性能でスケーラブルなテクノロジーの開発を主導しています。 Bobby Mohammed は、AWS の Principal Product Manager で、検索、GenAI、Agentic AI の製品イニシアチブを主導しています。以前は、SageMaker プラットフォームでのデータ、分析、ML 機能、Intel での深層学習トレーニングと推論製品など、機械学習のフルライフサイクルにわたる製品に携わっていました。

7 月 17 日、 AWS Lambda の 2 つの重要な機能強化、すなわち、コンソールと IDE の統合、およびリモートデバッグを発表します。これにより、デベロッパーは、ローカル開発環境でサーバーレスアプリケーションを構築したり、デバッグしたりするのがこれまで以上に容易になります。これらの新機能は、2024 年後半にリリースされた 強化されたコンソール内編集エクスペリエンス や 改善されたローカル統合開発環境 (IDE) エクスペリエンス など、Lambda 開発エクスペリエンスに対する最近の改善に基づいています。 サーバーレスアプリケーションを構築する際、デベロッパーは通常、ワークフローを合理化するために、ローカル開発環境のセットアップとクラウドデバッグ機能という 2 つの領域に重点的に取り組みます。デベロッパーはコンソールから IDE に関数を持ち込むことができますが、このプロセスをより効率的にする方法を模索しています。さらに、関数はクラウド内のさまざまな AWS サービスとインタラクションするため、デベロッパーは、開発サイクルで早めに問題を特定して解決するための、強化されたデバッグ機能を求めています。この機能を使用することで、ローカルエミュレーションへの依拠を減らし、開発ワークフローを最適化するのに役立ちます。 コンソールと IDE の統合 1 つ目の課題に対処するため、コンソールと IDE の統合を導入します。これにより、 AWS マネジメントコンソール から Visual Studio Code (VS Code) へのワークフローが効率化されます。この新機能は、 [Visual Studio Code で開く] ボタンを Lambda コンソールに追加します。これにより、デベロッパーは、ブラウザで関数を表示した後、迅速に IDE で編集できるようになるため、ローカル開発環境のための時間のかかるセットアッププロセスが不要になります。 コンソールと IDE の統合により、セットアッププロセスが自動的に処理され、VS Code のインストールと AWS Toolkit for VS Code の確認が行われます。すべてを既に設定済みのデベロッパーの場合、このボタンを選択するとすぐに VS Code で関数コードが開くため、編集を続行して、数秒で変更を Lambda にデプロイできます。VS Code がインストールされていない場合、デベロッパーはダウンロードページにリダイレクトされ、AWS Toolkit がない場合はインストールを促すメッセージが表示されます。 コンソールと IDE の統合を使用するには、新しい関数を作成した後に表示される [開始方法] のポップアップ、または既存の Lambda 関数の [コード] タブのいずれかで、 [VS Code で開く] ボタンを見つけます。このボタンを選択すると、VS Code が自動的に開きます (必要に応じて AWS Toolkit がインストールされます)。コンソール環境とは異なり、統合ターミナルを備えた完全な開発環境にアクセスできるようになりました。これは、パッケージの管理 (npm install、pip install)、テストの実行、リンターやフォーマッターなどの開発ツールの使用が必要なデベロッパーにとって大きな改善です。コードを編集したり、新しいファイル/フォルダを追加したりできます。変更を加えると、自動デプロイプロンプトがトリガーされます。デプロイを選択すると、AWS Toolkit は自動的に関数を AWS アカウントにデプロイします。 リモートデバッグ デベロッパーが IDE に関数を用意すると、リモートデバッグを使用して、AWS アカウントにデプロイされた Lambda 関数を VS Code から直接デバッグできます。リモートデバッグの主な利点は、他の AWS サービスと統合しながら、デベロッパーがクラウドで実行されている関数をデバッグできるようにするということです。これにより、開発の迅速化と信頼性の向上を実現できます。 リモートデバッグを使用すると、デベロッパーは、 Amazon Virtual Private Cloud (VPC) リソースと AWS Identity and Access Management (AWS IAM) ロールへの完全なアクセスを使用して関数をデバッグできるため、ローカル開発とクラウド実行の間のギャップが解消されます。例えば、VPC 内の Amazon Relational Database Service (Amazon RDS) データベースとインタラクションする Lambda 関数をデバッグする場合、デベロッパーは、本番と一致しない可能性のあるローカル環境のセットアップに時間を費やすのではなく、クラウドで実行されている関数の 実行環境 を数秒以内にデバッグできるようになりました。 リモートデバッグの使用を開始するのは簡単です。デベロッパーは VS Code で Lambda 関数を選択し、数秒でデバッグを有効にすることができます。AWS Toolkit for VS Code は、関数コードを自動的にダウンロードし、安全なデバッグ接続を確立して、ブレークポイント設定を有効にします。デバッグが完了すると、AWS Toolkit for VS Code はデバッグ設定を自動的にクリーンアップし、本番トラフィックへの影響を防ぎます。 試してみましょう リモートデバッグを試してみるために、Python で記述された基本的な「hello world」サンプル関数を使用して開始することにしました。この関数は、以前に AWS Lambda 用に AWS マネジメントコンソール を使用して作成したものです。AWS Toolkit for VS Code を使用すると、 [エクスプローラー] ペインで関数に移動できます。関数の上にマウスを移動して右クリック (Windows の場合は Ctrl キーを押しながらクリック) すると、コードがローカルマシンにダウンロードされ、IDE で編集できるようになります。ファイルを保存すると、最新の変更を Lambda にデプロイするかどうかをたずねられます。 ここから再生アイコンを選択すると、関数の [リモート呼び出し設定] ページが開きます。このダイアログに [リモートデバッグ] オプションが表示されるので、関数ハンドラーコードのローカルコピーをポイントするように設定します。 [リモート呼び出し] を選択する前に、左側の、コードを一時停止して検査する任意の場所でブレークポイントを設定できます。 コードは呼び出されるとクラウドで実行され、VS Code でステータスをリアルタイムでモニタリングできます。次のスクリーンショットでは、print ステートメントにブレークポイントが設定されているのがわかります。関数はコードのこの位置で実行を一時停止し、ローカル変数の値などを検査してから、次のブレークポイントに進んだり、コードを 1 行ずつステップインしたりできます。 ここでは、コードをステップインすることを選択しました。コードを 1 行ずつ実行していくと、IDE の左側にコンテキストとローカル変数およびグローバル変数が表示されます。さらに、IDE の下部にある [出力] タブでログを追跡できます。ステップスルーする中で、関数の実行によるログメッセージや出力メッセージがリアルタイムで表示されます。 強化された開発ワークフロー これらの新機能は連携して動作し、より効率的な開発エクスペリエンスを実現します。デベロッパーはコンソールから開発を開始し、コンソールと IDE の統合を使用して VS Code に迅速に移行して、リモートデバッグを使用してクラウドで実行されている関数をデバッグできます。このワークフローにより、複数のツールや環境を切り替える必要がなくなります。これは、デベロッパーが問題をより迅速に特定して修正するのに役立ちます。 今すぐご利用いただけます これらの新機能は、AWS Toolkit for VS Code (v3.69.0 以降) がインストールされた AWS マネジメントコンソールと VS Code を通じて利用を開始できます。コンソールと IDE の統合は、AWS GovCloud (米国) リージョンを除く、Lambda が利用可能なすべての商用 AWS リージョン でご利用いただけます。詳細については、 Lambda および AWS Toolkit for VS Code のドキュメントをご覧ください。リモートデバッグ機能の詳細 (利用可能な AWS リージョンなど) については、 AWS Toolkit for VS Code および Lambda のドキュメントにアクセスしてください。 コンソールと IDE の統合およびリモートデバッグは追加コストなしでご利用いただけます。リモートデバッグでお支払いいただくのは、デバッグセッションにおける標準の Lambda 実行コストのみです。リモートデバッグは、リリース時点では Python、Node.js、Java ランタイムをサポートし、将来的には他のランタイムにもサポートを拡大する予定です。 これらの機能強化は、サーバーレス開発エクスペリエンスの簡素化に向けた大きな前進であり、デベロッパーはこれまで以上に効率的に Lambda 関数を構築およびデバッグできるようになります。 原文は こちら です。

2018 年以来、 AWS DeepRacer は世界中で 560,000 人超のビルダーを魅了し、デベロッパーが競争的なエクスペリエンスを通じて学び、成長できることを実証してきました。本日、当社は AWS Artificial Intelligence (AI) League により拡張して、 生成 AI 時代に乗り出します。 これは他に類を見ない競争的なエクスペリエンスです。スキルレベルにかかわらず、生成 AI を深く探求し、仲間と競い合い、魅力的かつ競争的なエクスペリエンスを通じて実際のビジネス課題を解決するソリューションを構築するチャンスです。 AWS AI League では、お客様の組織がプライベートトーナメントを開催します。このトーナメントでは、チームが協力して、実用的な AI スキルを用いて実際のビジネスユースケースを解決するために競い合います。参加者は効果的なプロンプトを作成し、モデルをファインチューニングしながら、ビジネスに関連する強力な生成 AI ソリューションを構築します。競争を通じて、参加者のソリューションは、精度とレイテンシーに基づいてパフォーマンスを追跡するリアルタイムのリーダーボード上で、リファレンス標準に照らして評価されます。 AWS AI League エクスペリエンスは、AWS のエキスパートが主導する 2 時間のハンズオンワークショップから始まります。その後、自分のペースで実験し、最後はゲームショー形式のグランドフィナーレで、参加者がビジネス課題を解決する、生成 AI を用いて生み出した成果を披露します。組織は半日以内に独自の AWS AI League をセットアップできます。スケーラブルな設計により、効率的なタイムラインを維持しながら、500～5,000 人の従業員をサポートできます。 最大 200 万 USD 相当の AWS クレジット と、 AWS re:Invent 2025 での 25,000 USD の賞金総額によって支えられるこのプログラムは、実際のビジネス課題を解決するユニークな機会を提供します。 AWS AI League は、組織における生成 AI 機能の開発方法を変革します AWS AI League は、ハンズオンのスキル開発、ドメインの専門知識、ゲーミフィケーションを組み合わせることで、組織における生成 AI 機能の開発方法を変革します。このアプローチは、あらゆるスキルレベルのユーザーのために、AI 学習をアクセシブルかつ魅力的なものにします。チームは、実際の組織のニーズを反映した業界固有の課題を通じて連携します。各課題では、実際のビジネス要件を反映したリファレンスデータセットと評価基準が提供されます。 カスタマイズ可能な業界固有の課題 – 特定のビジネスコンテキストに合わせて競争をカスタマイズできます。ヘルスケアチームは患者の退院サマリーの作成に取り組み、金融サービスは不正検出に注力し、メディア企業はコンテンツ作成ソリューションを開発します。 統合 AWS AI スタックエクスペリエンス – 参加者は、 Amazon SageMaker AI 、 Amazon Bedrock 、 Amazon Nova などの AWS の AI および ML ツールを実際に体験できます。これらのツールは、 Amazon SageMaker Unified Studio からアクセスできます。チームは、組織の AWS アカウント内の、コスト管理された安全な環境で作業します。 リアルタイムのパフォーマンス追跡 – リーダーボードは、競争を通じて、提出されたものを既存のベンチマークとリファレンス標準に照らして評価し、正確性と速度に関する即時のフィードバックを提供するため、チームはソリューションをイテレーションして改善できます。最終ラウンドでは、このスコアリングにはエキスパートによる評価が含まれます。ドメインのエキスパートとライブオーディエンスがリアルタイムで投票に参加し、実際のビジネス課題を最も効果的に解決する AI ソリューションを決定します。 AWS AI League は、2 つの基礎的な競争トラックを提供します: Prompt Sage – The Ultimate Prompt Battle – 画期的なソリューションを実現する完璧な AI プロンプトの作成を競います。金融詐欺の検出からヘルスケアワークフローの合理化まで、ゼロショット学習と思考の連鎖推論を用いてリーダーボードの上位を目指す参加者にとって、あらゆる単語が重要です。 Tune Whiz – The Model Mastery Showdown – 汎用 AI モデルを業界固有の強力なモデルへと磨き上げ、その能力を高めます。参加者は、ドメインの専門知識と専門的な質問を武器に、ビジネス言語を流暢に話すモデルをファインチューニングします。圧倒的なパフォーマンス、驚異的な効率性、コスト最適化の完璧なバランスを実現した参加者が勝利を手にします。 生成 AI は進化を続けており、AWS AI League ではこれらのトラックに加えて、定期的に新しいチャレンジやフォーマットを導入していく予定です。 今すぐご利用いただけます 始める準備はできていますか? 組織は、 AWS AI League ページ を通じて申し込むことで、プライベートコンテストを開催できます。個人デベロッパーは、 AWS Summits や AWS re:Invent で開催されるパブリックコンテストに参加できます。 追記: AWS でのブログ記事の執筆は、常にチームとしての取り組みです。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。この件に関して、技術的なガイダンスと専門知識を活用して惜しみなくご支援いただいた Natasya Idries 氏に感謝申し上げます。このご支援のおかげで、この概要を包括的にまとめることができました。 –  Eli 原文は こちら です。

コンテナは開発チームがアプリケーションをパッケージ化およびデプロイする方法に革命をもたらしましたが、これらのチームは、デプロイリスクを軽減するためにリリースを注意深くモニタリングしたり、カスタムツールを構築したりする必要があり、これがリリース速度の低下につながっています。大規模な開発では、開発チームはビジネスのためのイノベーションではなく、差別化につながらないデプロイツールの構築とメンテナンスに貴重なサイクルを費やしています。 7 月 17 日より、 Amazon Elastic Container Service (Amazon ECS) に組み込まれているブルー/グリーンデプロイ機能を使用して、アプリケーションのデプロイをより安全かつ一貫性のあるものにすることができます。この新機能により、カスタムデプロイツールを構築する必要がなくなり、ロールバック機能を使用してソフトウェアアップデートをより頻繁にリリースすることについての自信がつきます。 Amazon ECS コンソールで組み込みのブルー/グリーンデプロイ機能を有効にする方法を次に示します。 既存の「ブルー」環境でライブトラフィックを引き続き処理しながら、新しい「グリーン」アプリケーション環境を作成します。グリーン環境を徹底的にモニタリングおよびテストした後、ライブトラフィックをブルーからグリーンにルーティングします。この機能により、Amazon ECS は、コンテナ化されたアプリケーションのデプロイをより安全で信頼性の高いものにする組み込み機能を提供するようになりました。 アプリケーショントラフィックをブルー環境からグリーン環境にシフトすることで、ブルー/グリーンデプロイがどのように機能するかを説明する図を以下に示します。詳細については、 Amazon ECS ブルー/グリーンサービスデプロイのワークフロー のページをご覧ください。 Amazon ECS は、本番トラフィックをルーティングする前に合成トラフィックを使用して新しいバージョンを検証するためのイベントフックを提供しながら、このワークフロー全体をオーケストレートします。エンドユーザーに公開する前に本番環境で新しいソフトウェアバージョンを検証し、問題が発生した場合にはほぼ瞬時にロールバックできます。この機能は Amazon ECS に直接組み込まれているため、カスタムツールを構築することなく、設定を更新するだけでこれらの安全対策を追加できます。 開始方法 ECS サービスのブルー/グリーンデプロイを設定して使用する方法を示すデモをご紹介します。その前に、 AWS Identity and Access Management (IAM) ロールの設定など、いくつかのセットアップステップを完了する必要があります。IAM ロールは、「 Required resources for Amazon ECS blue/green deployments 」ドキュメントページに記載されています。 このデモでは、リスクを最小限に抑えるために、ブルー/グリーン戦略を使用してアプリケーションの新しいバージョンをデプロイします。まず、ブルー/グリーンデプロイを使用するように ECS サービスを設定する必要があります。これは、ECS コンソールや AWS コマンドラインインターフェイス (AWS CLI) を通じて、または Infrastructure as Code を使用して行うことができます。 Amazon ECS コンソールを使用して、新しいサービスを作成し、通常どおりに設定します: [デプロイオプション] セクションで、 [デプロイコントローラータイプ] として [ECS] を選択し、 [デプロイ戦略] として [ブルー/グリーン] を選択します。 [ベイク時間] とは、本番トラフィックがグリーンにシフトした後、ブルーへの即時ロールバックが可能になるまでの時間です。ベイク時間が経過すると、ブルータスクは削除されます。 また、デプロイライフサイクルフックも導入されます。これらは、デプロイワークフローを拡張するために使用できるイベントドリブンのメカニズムです。デプロイライフサイクルフックとして使用する AWS Lambda 関数を選択できます。Lambda 関数は必要なビジネスロジックを実行できますが、フックステータスを返す必要があります。 Amazon ECS は、ブルー/グリーンデプロイ中に次のライフサイクルフックをサポートします。各ステージの詳細については、 デプロイライフサイクルステージ のページをご覧ください。 スケールアップ前 スケールアップ後 本番トラフィックシフト テストトラフィックシフト 本番トラフィックシフト後 テストトラフィックシフト後 私のアプリケーションでは、テストトラフィックシフトが完了し、グリーンサービスがすべてのテストトラフィックを処理するようになったときにテストしたいと考えています。エンドユーザートラフィックはないため、このステージでロールバックしてもユーザーに影響はありません。そのため、まずは自分の Lambda 関数を使用してテストできるので、 [テストトラフィックシフト後] が私のユースケースに適しています。 少しコンテキストを変えて、デプロイの続行を許可する前にそのデプロイを検証するために使用する Lambda 関数に注目してみましょう。デプロイライフサイクルフックとしての Lambda 関数では、合成テスト、別の API の呼び出し、メトリクスのクエリなど、あらゆるビジネスロジックを実行できます。 Lambda 関数内では、 hookStatus を返す必要があります。 hookStatus が SUCCESSFUL の場合、プロセスは次のステップに進みます。ステータスが FAILED の場合、ブルーデプロイにロールバックします。 IN_PROGRESS の場合、Amazon ECS は 30 秒後に Lambda 関数を再試行します。 次の例では、アプリケーションのテストスイートの一部としてファイルアップロードを実行する Lambda 関数を使用して検証をセットアップしました。 import json import urllib3 import logging import base64 import os # ログ記録を設定します logger = logging.getLogger() logger.setLevel(logging.DEBUG) # HTTP クライアントを初期化します http = urllib3.PoolManager() def lambda_handler(event, context): """ Validation hook that tests the green environment with file upload """ logger.info(f"Event: {json.dumps(event)}") logger.info(f"Context: {context}") try: # 実際のシナリオでは、テストエンドポイント URL を作成します test_endpoint = os.getenv("APP_URL") # アップロード用のテストファイルを作成します test_file_content = "This is a test file for deployment validation" test_file_data = test_file_content.encode('utf-8') # ファイルアップロード用のマルチパートフォームデータを準備します fields = { 'file': ('test.txt', test_file_data, 'text/plain'), 'description': 'Deployment validation test file' } # ファイルアップロードを含む POST リクエストを /process エンドポイントに送信します response = http.request( 'POST', test_endpoint, fields=fields, timeout=30 ) logger.info(f"POST /process response status: {response.status}") # レスポンスに OK ステータスコード (200～299 の範囲) が含まれているかどうかを確認します if 200 <= response.status < 300: logger.info("File upload test passed - received OK status code") return { "hookStatus": "SUCCEEDED" } else: logger.error(f"File upload test failed - status code: {response.status}") return { "hookStatus": "FAILED" } except Exception as error: logger.error(f"File upload test failed: {str(error)}") return { "hookStatus": "FAILED" } デプロイがフックに関連付けられたライフサイクルステージに達すると、Amazon ECS は、デプロイコンテキストを使用して Lambda 関数を自動的に呼び出します。この検証関数は、グリーンリビジョンに対して包括的なテスト (アプリケーションの正常性のチェック、統合テストの実行、パフォーマンスメトリクスの検証など) を実行できます。その後、関数は、デプロイを続行するか、中止するかを ECS に知らせます。 また、私はブルー/グリーンデプロイ戦略を選択したため、ロードバランサーおよび/または Amazon ECS Service Connect を設定する必要があります。 [ロードバランシング] セクションで、 [Application Load Balancer] を選択します。 [リスナー] セクションで、ポート 80 の既存のリスナーを使用し、2 つの [ターゲットグループ] を選択します。 この設定に問題がなければ、サービスを作成し、ECS が新しいサービスをプロビジョニングするのを待ちます。 ブルー/グリーンデプロイのテスト 次に、ブルー/グリーンデプロイをテストします。このテストでは、テストトラフィックシフトが完了した後、Amazon ECS は Lambda 関数をトリガーします。この場合、私の Lambda 関数はアプリケーションへのファイルアップロードを実行するため FAILED を返しますが、私のアプリケーションにはこの機能がありません。 サービスを更新し、ブルー/グリーンデプロイ機能が失敗を検出した場合にはロールバックしてくれるので安心して [新しいデプロイの強制] にチェックを入れます。タスク定義は変更していませんが、引き続き新しいデプロイをトリガーする必要があるため、このオプションを選択します。 このステージでは、ブルー環境とグリーン環境の両方が実行中であり、グリーンリビジョンがすべてのテストトラフィックを処理しています。一方、Lambda 関数の Amazon CloudWatch Logs に基づいて、デプロイライフサイクルフックが想定どおりに機能し、次のペイロードが出力されていることも確認できます: [INFO] 2025-07-10T13:15:39.018Z 67d9b03e-12da-4fab-920d-9887d264308e Event: { "executionDetails": { "testTrafficWeights": {}, "productionTrafficWeights": {}, "serviceArn": "arn:aws:ecs:us-west-2:123:service/EcsBlueGreenCluster/nginxBGservice", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123:service-revision/EcsBlueGreenCluster/nginxBGservice/9386398427419951854" }, "executionId": "a635edb5-a66b-4f44-bf3f-fcee4b3641a5", "lifecycleStage": "POST_TEST_TRAFFIC_SHIFT", "resourceArn": "arn:aws:ecs:us-west-2:123:service-deployment/EcsBlueGreenCluster/nginxBGservice/TFX5sH9q9XDboDTOv0rIt" } 想定どおり、私の AWS Lambda 関数はテストの実行に失敗したため、 hookStatus として FAILED を返します。 [ERROR] 2025-07-10T13:18:43.392Z 67d9b03e-12da-4fab-920d-9887d264308e File upload test failed: HTTPConnectionPool(host='xyz.us-west-2.elb.amazonaws.com', port=80): Max retries exceeded with url: / (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f8036273a80>, 'Connection to xyz.us-west-2.elb.amazonaws.com timed out. (connect timeout=30)')) 検証が正常に完了しなかったため、Amazon ECS は、以前の機能するデプロイバージョンであるブルーバージョンへのロールバックを試みます。 [イベント] セクションの ECS イベントを通じてこのプロセスをモニタリングでき、デプロイの進行状況を詳細に確認できます。 Amazon ECS は、デプロイを以前の機能するバージョンに正常にロールバックします。ブルーリビジョンは実行中のままとなり、本番トラフィックを受信できる準備が整っているため、ロールバックはほぼ瞬時に行われます。このプロセス中は、本番トラフィックが新しいアプリケーションバージョンにシフトすることはないため、エンドユーザーへの影響はありません。ECS がテストトラフィックを元の安定したバージョンにロールバックするだけです。これにより、従来のローリングデプロイに伴う一般的なデプロイのダウンタイムが排除されます。 また、ロールバックのステータスは [前回のデプロイ] セクションで確認できます。 テスト全体を通じて、ブルー/グリーンデプロイ戦略が一貫した予測可能な動作を提供することがわかりました。さらに、デプロイライフサイクルフックにより、デプロイの動作をより柔軟に制御できます。各サービスリビジョンは、タスク定義、ロードバランサーの設定、Service Connect の設定など、イミュータブルな設定を維持します。これは、ロールバックによって、以前実行されていたのとまったく同じ環境が復元されることを意味します。 知っておくべき追加情報 いくつかの留意点を次に示します: 料金 – ブルー/グリーンデプロイ機能は、追加料金なしで Amazon ECS に含まれます。お支払いいただくのは、デプロイプロセス中に使用されたコンピューティングリソースについての料金のみです。 利用可能なリージョン – この機能は、すべての商用 AWS リージョンでご利用いただけます。 Amazon ECS コンソール で Amazon ECS サービスの設定を更新して、ブルー/グリーンデプロイの使用を開始しましょう。 よいデプロイを! – Donnie 原文は こちら です。

はじめに 2025 年 6 月 26 日に AWS Summit Japan 2025 の AWS Builders’ Fair にて、カメラと重量センサーを活用した新しいスマート廃棄物管理ソリューションを展示しました。これは、過去に AWS Blog で紹介されたソリューションを基に、日本の食品を取り扱う企業が直面する課題に合わせて改良を加えたものです。 特に外食企業やスーパーマーケットでは、「何が」「どこで」「どれくらい」廃棄されているかの把握が重要な課題となっています。従来の手作業による管理では多大な労力が必要でしたが、本ソリューションでは生成 AI 技術の活用により、事前の学習データを用意することなく廃棄物の自動認識が可能になりました。 これにより、企業はデータに基づいて仕入れ量を最適化し食品廃棄を削減できます。そして、事業コストの抑制と同時にフードロス削減という社会課題の解決への貢献にもつながります。まさに、経験や勘に頼った従来の管理手法から、IoT と AI 技術を活用したデータドリブンな管理へ変化する挑戦といえます。 本ブログでは、Summit 展示での展示内容や検出精度、コストについて詳しく紹介します。さらに、お客様から寄せられた貴重なフィードバックを基に、本ソリューションの実用化に向けた展望について考察していきます。 図1 : 当日の展示の様子 事前準備 本ソリューションでは、IoT デバイスゲートウェイとして Raspberry Pi を使用し、廃棄物の重量を測定する重量センサーと、ゴミを落としたときに廃棄物の静止写真を撮る WEB カメラを使用します。展示ソリューションには以下の機器が使われました。 Raspberry Pi： Raspberry Pi 3 Model b+ 重量センサー： Gravity – HX711搭載I2C重量センサキット 1Kg WEB カメラ： Kensington W2050 Pro 1080p HX711 重量センサーを ドキュメント に沿って組み立てた後、Raspberry Pi と I2C 接続します。また、WEB カメラは USB 経由で Raspberry Pi に接続します。Raspberry Pi には最新バージョンの Raspberry Pi OS をインストールします。さらに、このソリューションでは、Raspberry Pi 上で AWS IoT Greengrass を構成し、 AWS IoT Core へ接続します。 デモで体験できることとアーキテクチャ このデモでは、AI と IoT などの技術を活用することで、ゴミ箱に何がどれくらい廃棄されたのかを可視化できるようになります。これまで把握しづらかったフードロスの実態を、目で見て理解できる第一歩を体験していただけます。 図2 : ゴミ箱に廃棄されたものを判定し、ダッシュボードに表示される様子 このデモは、以下に示す AWS サービスとセンサー類によって構築されています。 図3 : スマートゴミ箱デモのアーキテクチャ 1. IoT デバイスによる自動検知とデータ送信 重量変化をトリガーとした自動撮影システム デバイス上では、カスタムアプリケーションが重量の変化（±10g）を常時監視しています。廃棄物がゴミ箱に投入されると、重量センサーが変化を検知し、自動的にカメラがトリガーされる仕組みです。この自動化により、従来の手動撮影では困難だった「廃棄の瞬間を逃さない記録」が可能になります。重量をトリガーにすることで、写真を撮影する手間なくクラウド上にデータを送れることが大きな利点です。 セキュアなクラウド連携 重量データは MQTT チャネルを介して AWS IoT Core に送信され、同時に撮影された廃棄物の画像は AWS IoT Greengrass Stream manager を使用して Amazon S3 バケットにアップロードされます。 AWS IoT ロールエイリアス により、AWS IoT Core 以外のサービス（S3など）にも安全にアクセスできます。この仕組みでは、IAM アクセスキーやシークレットキーをデバイスに個別に埋め込む必要がなく、デバイス証明書による統一的な認証管理が可能です。また、デバイス上で動作するコンポーネントは、AWS IoT Greengrass のクラウド経由でのデプロイ機能により、リモートでの管理・更新が可能です。デバイスのスクリプトやソフトウェアをクラウドから一元的にアップデート・管理できるため、運用コストの削減と迅速な機能改善が実現されます。 2. 生成 AI を用いてごみの種別を判定 AWS IoT Core 経由で送られてきたスマートゴミ箱の中の画像は、Amazon S3 に格納されます。 AWS Lambda は撮影された画像を取得し、 Amazon Bedrock を用いてゴミ箱の中に入っているものを判定します。 図4 : Amazon Bedrock を利用して捨てられたゴミを判定するイメージ Anthropic の Claude Sonnet 3.7 を搭載した Amazon Bedrock は、最新のものとひとつ前の撮影画像から、画像の差分を認識し、新しく捨てられたごみの名称と、ごみの種別を出力します。 従来の画像判定モデルでは、新しい種類の画像を認識するためには追加の学習データを用いた再トレーニングが必要とされていました。しかしながら、大規模言語モデル （LLM） は、膨大な量のデータを事前学習しており、そのような追加学習の必要性が大幅に軽減されています。そのため、今回のデモで用いたモデルについても追加学習をすることなく実施しました。 画像のパス、ごみの名称とセンサーデータなどのテレメトリデータは、 Amazon Timestream for LiveAnalytics に格納されます。なお、Amazon Timestream for LiveAnalytics は 2025 年5 月時点で新規受付を終了しているため、Amazon Timestream for InfluxDB や Amazon DynamoDB 等の利用をご検討ください。 3. ダッシュボード上にリアルタイムで可視化 図5 : ダッシュボード Amazon Timestream に蓄積されたレコードは、 Amazon Managed Grafana 上のダッシュボードで可視化されます。データに更新されると、最新の画像とレコードがダッシュボード上に即座に反映されます。廃棄物管理ダッシュボードでは、リアルタイムで取得された画像やレコードを表示するダッシュボードの他に、過去のレコードを集計・分析して表示する機能も実装しています。これにより、長期的なトレンド分析や、他店舗の廃棄物量との比較が容易になります。 結果 AWS Summit Japan 2025 でのスマート廃棄物管理の展示では、約 9 時間の連続稼働で 162 件、149 kg の廃棄物を処理し、認識精度 88.4% を達成しました。AI と IoT 技術の組み合わせにより、従来見えなかった食品廃棄の実態をリアルタイムで可視化することで実用化への可能性を検証できました。 試行回数と検出精度 ＊精度は検出方法や対象物により大きく異なります。本文ではモデル自体の精度ではなく、検出手法の精度についての結果と考察を目的としていることにご留意ください。 展示期間中の約 9 時間で 162 件の廃棄イベントを検知しました。このうち、手や関係のない物が写り込んだ 12 件を除いた 150 件（92.0%）を評価の対象としました。 画像認識における精度評価は以下のように行いました： 全て正しく判定できた場合：100% 部分的に正しく判定できた場合：判定できた割合 まったく判定できなかった場合：0% 150件の分析結果から、以下のことが分かりました： 1. 1つずつゴミを捨てたケース（138 件、全体の 92.0%） 全て正しく判定した割合は 86.2% でした。部分的に正しく判定したケースも含めると 89.9% となりました 「ペットボトル」「バナナ」「りんご」などの個別の食品は特に高い精度で判定できました 2. 複数のゴミを同時に捨てたケース（12件、全体の 8.0%） 部分的に正しく判定したケースも含めた精度は 70.8% で、全て正しく判定した割合は 33.3% でした 全てのゴミを正確に判定することは難しく、一部のゴミを見逃すことがありました この結果から、1 つずつゴミを捨てた場合は高い精度で判定できることが分かりました。一方で、複数のゴミを同時に捨てた場合は精度が約 19% 低下することも判明しました。 コスト 展示での費用実績を分析すると、初期コストとしてハードウェアデバイスの費用が ￥ 23,318、162 件の廃棄処理に対してクラウド利用料が $ 19.2 発生しました。それぞれの内訳は下記の表で示します。 本ソリューションを複数店舗、複数ゴミ箱に展開する際には、設置するゴミ箱の数に応じて初期費用が、処理する廃棄物の件数に応じてクラウド利用料が増加します。 展示日1日間のクラウド利用料（サービス別） サービス コスト Amazon Timestream $16.80 Amazon Bedrock $2.20 その他サービス $0.20 合計 $19.20 初期コスト 品目 金額 Raspberry Pi ¥12,980 重量センサー ¥5,358 WEB カメラ ¥4,980 合計 ¥23,318 お客様からの声 本展示では、多くの来場者から貴重なフィードバックをいただきました。業界を超えた幅広い分野からの反響があり、食品廃棄問題の重要性と本ソリューションの可能性を再確認することができました。 外食産業からの声 外食チェーン企業の方々からは、「現在は廃棄するゴミを重量計にのせて手書きで記録しており、自治体ごとに分類が異なるため管理が大変」というご意見をいただきました。特に粗利を最大化するために在庫の最適化を極力進めたいというニーズがあり、本ソリューションの価値を感じていただけました。 また、実用化に向けた具体的な改善提案として、「手が塞がっていることが多いので音声で上書きできる機能」や「自治体ごとに異なる分類表を読み込ませ、LLM が検出した廃棄物をどのゴミ箱に捨てるべきか正しくガイドする機能」へのニーズが挙げられました。 ホテル業界からは、「ビュッフェではある程度の食品廃棄は許容されるが、過剰な廃棄は問題になっている」という課題が共有されました。 他業界への応用可能性 展示では外食産業だけでなく、様々な業界からの関心が寄せられました。 工場現場では「部品などの画像分析」や「廃棄物管理の自動化」への応用可能性が指摘されました。ある製造業の来場者からは「ゴミの手動分別をした後にリサイクルや廃品回収で買い取ってもらっているが、ルールが複雑なので自動化していきたい」という具体的なニーズをお聞きしました。 建設業界でも「木材・建材の廃棄量は問題になっている」とのコメントがあり、本ソリューションの応用範囲の広さを実感しました。 コンサルティング企業の方からは、「産業用廃棄物の分類は法律でも決まっていて分類が大変。特に外国人労働者にとってはハードルが高い」という課題をお聞きしました。「正しいゴミ箱を教えてくれるのか、入れたら自動で分類してくれるのか、知識がなくても分類できるようになるのをアシストしてくれると嬉しい」という具体的なニーズが示されました。 改善提案 実用化に向けた改善提案としては、以下のような声が寄せられました。 一度に複数のゴミを捨てた時の判定精度向上：「一気にゴミを捨てた時に判定できないのは不便」 コスト削減：「デバイス代が高くつくのはコスト面から厳しい。例えば一店舗に複数のゴミ箱を置いて、一台のカメラで判別することはできないか？」 家庭用への応用：「自治体ごとのルールを読んでくれて、家のゴミ分別を自動でやってくれるようにしてほしい」「ゴミ箱に入れてほしくないもの（例えば燃えるゴミ入れに電池が入る等）が廃棄されるとアラートが飛んでほしい」 これらのフィードバックは、本ソリューションの実用化に向けた貴重な示唆となりました。特に、自治体ごとに異なる廃棄物分類ルールへの対応や、複数物体の同時判定精度の向上は、今後の開発における重要な課題として認識しています。今後は、これらのフィードバックを活かし、より実用的で幅広い業界に適用可能なソリューションへと発展させていきたいと考えています。 まとめ AWS Summit Japan 2025 で AI と IoT 技術を組み合わせたスマート廃棄物管理ソリューションを展示しました。 約9時間の連続稼働で 162 件の廃棄物を処理し、88.4% の認識精度を達成しました。特に注目すべきは、事前の学習データなしで生成 AI（Amazon Bedrock）により多様な廃棄物を自動認識できた点です。また、サーバレスアーキテクチャにより、インフラ管理が不要で処理量に応じた従量課金を実現できました。 展示では外食産業を中心に、製造業、建設業、ホテル業界など幅広い分野から関心が寄せられ、「自治体ごとの分類ルール対応」「音声修正機能」「複数ゴミ箱の一元管理」など具体的な改善提案をいただきました。多くの方に関心を持っていただけたことを嬉しく思います。 本ソリューションは従来の「経験と勘」に頼った廃棄物管理から「データドリブン」な管理への転換を可能にし、企業の収益性向上と環境負荷軽減を同時に実現する可能性を示しました。今後は複数物体同時判定の精度向上、コスト最適化、業界特化機能の開発、スケーラビリティの向上に取り組み、持続可能な社会の実現に貢献していきます。 このブログは、ソリューションアーキテクトTei、大久保、本田、古山、寺山 が執筆しました。

7 月 16 日、 Amazon SageMaker AI の Amazon Nova 向けのカスタマイズ機能 スイートを発表しました。お客様は、事前トレーニング、教師ありファインチューニング、アライメントなど、モデルトレーニングライフサイクル全体にわたって、Nova Micro、Nova Lite、Nova Pro をカスタマイズできるようになりました。これらの手法は、すぐに使用できる Amazon SageMaker レシピとして提供され、 Amazon Bedrock にシームレスにデプロイされ、オンデマンド推論とプロビジョンドスループット推論の両方をサポートします。 Amazon Nova 基盤モデル は、さまざまな業界における多様な生成 AI ユースケースをサポートします。お客様は、デプロイをスケールする中で、独自の知識、ワークフロー、ブランド要件を反映したモデルが必要になります。プロンプト最適化と 検索拡張生成 (RAG) は、汎用基盤モデルをアプリケーションに統合するのに適していますが、ビジネスクリティカルなワークフローでは、特定の精度、コスト、レイテンシー要件を満たすためにモデルのカスタマイズが必要です。 適切なカスタマイズ手法の選択 Amazon Nova モデルは、1) 教師ありファインチューニング、2) アライメント、3) 継続的な事前トレーニング、4) 知識蒸留など、幅広いカスタマイズ手法をサポートしています。最適な選択は、目標、ユースケースの複雑さ、データとコンピューティングリソースの可用性によって異なります。また、複数の手法を組み合わせることで、パフォーマンス、コスト、柔軟性の最適な組み合わせで、目的の結果を達成することもできます。 教師ありファインチューニング (SFT) は、対象のタスクとドメインに固有の入出力ペアのトレーニングデータセットを使用して、モデルパラメータをカスタマイズします。データ量とコストに関する考慮事項に基づいて、次の 2 つの実装アプローチから選択します: パラメータ効率の高いファインチューニング (PEFT) – LoRA (Low-Rank Adaptation) などの軽量アダプターレイヤーを通じて、モデルパラメータのサブセットのみを更新します。フルファインチューニングと比較して、より迅速なトレーニングと、より低いコンピューティングコストを提供します。PEFT 対応の Nova モデルは Amazon Bedrock にインポートされ、オンデマンド推論を使用して呼び出されます。 フルファインチューニング (FFT) – モデルのすべてのパラメータを更新し、大規模なトレーニングデータセット (数万件のレコード) がある場合に最適です。FFT を通じてカスタマイズされた Nova モデルも Amazon Bedrock にインポートし、プロビジョンドスループットを使用した推論のために呼び出すことができます。 アライメント は、企業ブランドやカスタマーエクスペリエンスの要件など、製品固有のニーズや振る舞いに関する望ましい選好にモデル出力を導きます。これらの選好は、実証例やポリシーなど、複数の方法でエンコードできます。Nova モデルは、2 つの選好アライメント手法をサポートしています: 直接選好最適化 (DPO) – 好ましい/好ましくない応答ペアを使用して、モデル出力をチューニングする簡単な方法を提供します。DPO は、比較ベースの選好から学習し、トーンやスタイルなどの主観的な要件に合わせて出力を最適化します。DPO は、パラメータ効率の高いバージョンとフルモデル更新バージョンの両方を提供します。パラメータ効率の高いバージョンは、オンデマンド推論をサポートします。 近似ポリシー最適化 (PPO) – 強化学習を用いて、有用性、安全性、エンゲージメントなどの望ましい報酬を最適化することで、モデルの振る舞いを強化します。報酬モデルは出力にスコアを付けることで最適化をガイドし、モデルが以前に学習した能力を維持しながら効果的な振る舞いを学習するのをサポートします。 継続的事前トレーニング (CPT) は、社内文書、トランスクリプト、ビジネス固有のコンテンツなど、大量のラベルなし所有データを用いた自己教師あり学習を通じて、基本的なモデルの知識を拡張します。CPT に続いて、SFT と、DPO または PPO を通じたアライメントを実施することで、アプリケーションに合わせて Nova モデルを包括的にカスタマイズできます。 知識蒸留 は、大規模な「教師」モデルから、小規模でより高速かつコスト効率の高い「生徒」モデルへと知識を伝えます。蒸留は、お客様が十分な参照入出力サンプルを有しておらず、より強力なモデルを活用してトレーニングデータを拡張できるシナリオで役立ちます。このプロセスにより、特定のユースケース向けの教師レベルの精度と、生徒レベルの費用対効果と速度を備えた、カスタマイズされたモデルが作成されます。 さまざまなモダリティとデプロイオプションで使用できるカスタマイズ手法をまとめた表を次に示します。各手法は、実装要件に応じて、特定のトレーニングおよび推論機能を提供します。 レシピ モダリティ トレーニング 推論 Amazon Bedrock Amazon SageMaker Amazon Bedrock オンデマンド Amazon Bedrock プロビジョンドスループット 教師ありファインチューニング テキスト、画像、動画 パラメータ効率の高いファインチューニング (PEFT) フルファインチューニング 直接選好最適化 (DPO) テキスト、画像、動画 パラメータ効率の高い DPO フルモデル DPO 近似ポリシー最適化 (PPO) テキストのみ 継続的な事前トレーニング  テキストのみ 蒸留 テキストのみ Cosine AI、Massachusetts Institute of Technology (MIT) Computer Science and Artificial Intelligence Laboratory (CSAIL)、Volkswagen、Amazon Customer Service、Amazon Catalog Systems Service などのアーリーアクセスのお客様は、既に Amazon Nova のカスタマイズ機能を成功裏に使用しています。 Nova モデルのカスタマイズの実際の仕組み 以下では、既存の選好データセットに対して直接選好最適化を用いて Nova Micro モデルをカスタマイズする例について説明します。これを実行するために、 Amazon SageMaker Studio を使用できます。 Amazon SageMaker AI コンソール で SageMaker Studio を起動し、 [JumpStart] を選択します。これは、基盤モデル、組み込みアルゴリズム、事前構築済みの ML ソリューションを備えた機械学習 (ML) ハブであり、数回クリックするだけでデプロイできます。 その後、 [Nova Micro] を選択し、 [トレーニング] を選択します。Nova Micro は、Nova モデルファミリーの中で最も低い推論あたりのコストで最も低レイテンシーで応答を提供するテキストのみのモデルです。 次に、 [ファインチューニング] レシピを選択して、ラベル付きデータでモデルをトレーニングし、特定のタスクのパフォーマンスを強化して、望ましい振る舞いになるよう調整できます。 [直接選好最適化] を選択すると、好みに合わせてモデル出力を簡単にチューニングできます。 [サンプルノートブックを開く] を選択すると、レシピを実行する環境オプションが 2 つあります。すなわち、SageMaker トレーニングジョブまたは SageMaker Hyperpod のいずれかです: クラスターを作成し、JupyterLab スペースを選択してサンプルノートブックでモデルをトレーニングする必要がない場合は、 [SageMaker トレーニングジョブ でレシピを実行] を選択します。 あるいは、反復的なトレーニングプロセスのために最適化された永続的なクラスター環境が必要な場合は、 [SageMaker HyperPod でレシピを実行] を選択します。このような Nova モデルのトレーニングに必要な、特殊な分離された環境を提供するために、少なくとも 1 つの制限付きインスタンスグループ (RIG) を持つ HyperPod EKS クラスターを選択できます。その後、JupyterLabSpace を選択し、 [サンプルノートブックを開く] を選択します。 このノートブックは、SageMaker Nova モデルとレシピを使用して SageMaker HyperPod ジョブを作成し、推論のためにデプロイするためのエンドツーエンドのチュートリアルを提供します。SageMaker HyperPod レシピを使用することで、最適化されたトレーニングジョブのために、複雑な設定を合理化し、データセットをシームレスに統合できます。 SageMaker Studio では、SageMaker HyperPod ジョブが正常に作成されたことを確認し、その後の進捗状況をモニタリングできます。 ジョブが完了したら、ベンチマークレシピを使用して、カスタマイズされたモデルがエージェントタスクでより優れたパフォーマンスを発揮するかどうかを評価できます。 包括的なドキュメントと追加の実装例については、 GitHub で SageMaker HyperPod レシピリポジトリにアクセスしてください。 当社は、お客様からのフィードバックと新たな ML トレンドに基づいてレシピを引き続き拡張し、AI モデルのカスタマイズを成功させるために必要なツールをお客様に提供していきます。 利用可能なリージョンと開始方法 Amazon SageMaker AI での Amazon Nova のレシピは、米国東部 (バージニア北部) でご利用いただけます。この機能の詳細については、 Amazon Nova のカスタマイズのウェブページ と「 Amazon Nova ユーザーガイド 」にアクセスしてください。使用を開始するには、 Amazon SageMaker AI コンソール をご利用ください。 – Betty 原文は こちら です。

この記事は「 Introducing AWS Serverless MCP Server: AI-powered development for modern applications 」をソリューションアーキテクトの松本が翻訳したものです。 最新のアプリケーション開発では、ソフトウェアの構築とデプロイをより迅速かつ効率的に行う方法が求められています。過去 10 年間で、サーバーレスコンピューティングはソフトウェア開発における変革的なアプローチとして台頭し、開発者が基盤となるインフラストラクチャを管理することなくアプリケーションの構築に集中できるようになりました。開発者が AWS でのサーバーレス  を使用してアプリケーションを構築する際、適切なサービスの選択、ベストプラクティスの理解、実装パターンについてのガイダンスを求め、このパラダイムを最大限に活用しようとします。 本日、AWS はオープンソースの AWS Serverless Model Context Protocol (MCP) Server を発表しました。これは AI 支援とサーバーレス専門知識を組み合わせ、開発者が最新のアプリケーションを構築する方法を強化するツールです。Serverless MCP Server は、サーバーレス開発に特化したコンテキストガイダンスを提供し、開発者がアーキテクチャ、実装、デプロイに関する情報に基づいた決定を行えるよう支援します。 この記事では、 Serverless MCP Server が AI コーディングアシスタントと連携してサーバーレス開発を効率化する方法について説明します。このソリューションを使用してサーバーレス開発ワークフローを加速し、堅牢で高性能なアプリケーションをより効率的に構築する方法を学びましょう。 概要   サーバーレスコンピューティングにより、開発チームは運用効率を向上させながら市場投入までの時間を大幅に短縮できます。開発者はビジネス価値の創出に集中でき、AWS サービスが自動的にスケーリング、可用性、インフラストラクチャのメンテナンスを処理します。 AWS Lambda は、イベントに応じてコードを実行するシームレスなコンピュートサービスを提供し、1 日数リクエストから 1 秒あたり数千リクエストまで瞬時にスケールします。200 以上の AWS サービスとの統合により、Lambda は開発者が Amazon API Gateway 、 Amazon S3 、 Amazon DynamoDB などからのトリガーを使用して高度なアプリケーションを構築できるようにします。データ処理パイプライン、リアルタイムストリーム処理、Web アプリケーションのいずれを構築する場合でも、Lambda は一般的なプログラミング言語と開発フレームワークをサポートし、開発チームがサーバーレスパラダイムを採用しながら既存のスキルを活用できるよう支援します。 MCP Server MCP は、AI エージェントが外部ツールやデータソースと対話するためのオープンプロトコルです。AI アシスタントが外部システムによって提供される様々な機能を発見、理解、使用する方法を定義します。このプロトコルにより、AI モデルは標準化されたインターフェースを通じてリアルタイム情報にアクセスし、特定のタスクを実行することで、自身のトレーニングデータを超えた機能を拡張できます。 MCP サーバーは、 Amazon Q Developer 、 Cline 、 Cursor などの AI アシスタントが MCP クライアントを介して使用できるツール、リソース、コンテキスト情報を提供することで、このプロトコルを実装します。これらは知識の架け橋として機能し、AI アシスタントにクラウドアーキテクチャと実装に関する情報に基づいた決定を行うために必要な追加コンテキストを提供します。これは特に、開発者が複数のサービス、イベントパターン、統合ポイントを操作してスケーラブルで高性能なアプリケーションを構築するサーバーレスアプリケーションにとって価値があります。 AWS は現在、 AWS Lambda Tool MCP Server を提供しており、これにより AI モデルはコード変更なしに既存の Lambda 関数と MCP ツールとして直接対話できます。この MCP サーバーは MCP クライアントと Lambda 関数の間の橋渡しとして機能し、AI アシスタントが Lambda 関数にアクセスして呼び出すことを可能にします。 Serverless MCP Server 本日発表されたオープンソースの AWS Serverless MCP は、サーバーレスパターン、ベストプラクティス、AWS サービスに関する包括的な知識を AI コーディングアシスタントに提供することで、サーバーレス開発体験を強化します。この MCP サーバーはインテリジェントなコンパニオンとして機能し、初期設計からデプロイまでのアプリケーション開発ライフサイクル全体を通じて開発者をガイドし、各段階でコンテキストに応じた支援を提供します。 新しい Serverless MCP サーバーは、サーバーレス開発の多くの領域をカバーするツールを提供します。初期計画とセットアップフェーズでは、MCP サーバーは開発者が AWS Serverless Application Model (AWS SAM) テンプレートを使用して新しいプロジェクトを初期化し、適切な Lambda ランタイムを選択し、プロジェクトの依存関係をセットアップするのを支援します。これにより、開発者は適切な構成と構造を持つ新しいサーバーレスアプリケーションを迅速に立ち上げることができます。 開発が進むにつれて、MCP サーバーはサーバーレスアプリケーションの構築とデプロイを支援します。ローカルテスト、デプロイアーティファクトの構築、デプロイの管理のためのツールを提供します。Web アプリケーションについては、MCP サーバーはバックエンド、フロントエンド、またはフルスタックアプリケーションのデプロイとカスタムドメインのセットアップに特化したサポートを提供します。 MCP サーバーはまた、包括的な可観測性ツールを通じて運用の優秀性を強調し、開発者がアプリケーションのパフォーマンスを効果的に監視し、問題をトラブルシューティングするのを支援します。開発プロセス全体を通じて、サーバーは Infrastracture as a Code (IaC) の決定、Lambda 固有のベストプラクティス、 Lambda Event Source Mappings (ESM) のイベントスキーマに関するコンテキストガイダンスを提供します。 Serverless MCP Server の実際の動作 Serverless MCP Server の機能を実証するために、サーバーレスアプリケーションの作成、デプロイ、トラブルシューティングのシナリオを通じて説明します。 前提条件とインストール 開始するには、 GitHub または Python Package Index (PyPi) から AWS Serverless MCP Server をダウンロードし、インストール手順に従います。この MCP サーバーは、Q Developer、Cursor、Cline などの任意の AI コーディングアシスタントで使用できます。この記事のウォークスルー例では Cline を使用しています。 MCP クライアント構成に次のコードを追加します。Serverless MCP Server はデフォルトで  default AWS プロファイルを使用します。別のプロファイルを使用する場合は AWS_PROFILE に値を指定します。同様に、 AWS リージョン とログレベルの値も必要に応じて調整してください。 { "mcpServers": { "awslabs.aws-serverless-mcp": { "command": "uvx", "args": [ "awslabs.aws-serverless-mcp-server@latest" ], "env": { "AWS_PROFILE": " your-aws-profile ", "AWS_REGION": "us-east-1", "FASTMCP_LOG_LEVEL": "ERROR" } } } } Code Serverless MCP Server には、安全で制御された開発を確保するための組み込みガードレールが含まれています。デフォルトでは、MCP サーバーは読み取り専用モードで動作し、変更を加えないアクションのみを許可します。この安全第一のアプローチにより、アプリケーションやインフラストラクチャに意図しない変更を防ぎながら、サーバーレス機能とアーキテクチャパターンを探索できます。また、サーバーはデフォルトで Amazon CloudWatch Logs へのアクセスを制限し、機密性の高い運用データが AI アシスタントに公開されないよう保護します。 開発ニーズが進化するにつれて、これらのセキュリティデフォルトを選択的に上書きできます。 --allow-write フラグはデプロイや更新などのタスクのための変更操作を有効にし、 --allow-sensitive-data-access はデバッグとトラブルシューティングのために CloudWatch Logs へのアクセスを提供します。これらの権限は必要な場合にのみ、適切な開発コンテキストで有効にすることを検討してください。 サーバーレスアプリケーションの作成とデプロイ To-Do リスト Web アプリケーションを構築したいとします。AI アシスタントに次のようにプロンプトを出します。 新しいワークスペースで To-Do リスト Web アプリケーションを構築したいと思います。To-Do の追加、一覧表示、削除を行いたいです。AWS Lambda はこれに適した選択肢でしょうか？ エージェントは get_lambda_guidance_tool を使用して、ユースケースと推測されるイベントソース（この場合は API Gateway）に基づいたカスタマイズされたガイダンスを受け取ります。次に、アプリケーションを AWS にデプロイする方法についてより詳しく理解したいと思います。 後でアプリケーションを AWS にデプロイしたいと思います。どのインフラストラクチャ・アズ・コードツールが最適でしょうか？ AWS SAM や AWS Cloud Development Kit (AWS CDK) など、関数を AWS にデプロイするいくつかの方法があります。モデルは推奨を行う前に詳細情報を取得することを選択します。Serverless MCP Server から get_iac_guidance_tool を選択します。 Serverless MCP Server は、 AWS Serverless Application Model Command Line Interface (AWS SAM CLI) との対話や、バックエンド、フロントエンド、またはフルスタックアプリケーションなどのアプリケーションベースのブループリントのデプロイにも役立ちます。 デプロイの前に、関数が正しく動作することを確認するためにローカルでテストします。 デプロイする前に Lambda 関数をローカルでテストしたいと思います。SAM プロジェクトから「TodoFunction」を GET リクエストで呼び出すことはできますか？ アプリケーションが動作することを確認したので、バックエンドロジックを AWS にデプロイしたいと思います。そこで、エージェントにアプリを展開するよう促します。エージェントは deploy_webapp ツールを選択し、バックエンド deploymentType を含むアプリをデプロイするための引数をツールに提供します。このツールは AWS Lambda Web Adapter フレームワークを使用しており、追加の Web アダプターなしで Express や Next.js などの標準的な Web フレームワークで書かれたアプリケーションを簡単にデプロイできます。 エージェントはデプロイのステータスを確認して、正常に完了することを確認することもできます。 これでアプリケーションは AWS にデプロイされ、トラフィックを処理する準備ができました。 サーバーレスアプリケーションのトラブルシューティング Serverless MCP Server は、Lambda 関数のテストとトラブルシューティングもサポートしています。問題の特定と修正において AI アシスタントに貴重なコンテキストを提供します。例えば、エージェントを使用してアプリケーションに問題がないか確認できます。 To-Do アプリのログとメトリクスを確認して、問題がないか調べてください モデルはログとメトリクスを分析し、メモリ割り当ての調整などの推奨事項を提供できます。 Serverless MCP Server ツールは、アシスタントが問題を特定し推奨事項を生成するために必要な追加コンテキストを提供します。 この例での分析と推奨事項は次のとおりです： ログ分析 To-Do アプリの 3 つの Lambda 関数すべてのログをチェックし、特にエラーを探しました： • ListTodosFunction ：エラーは検出されませんでした • AddTodoFunction ：エラーは検出されませんでした • DeleteTodoFunction ：エラーは検出されませんでした すべての関数は正常に動作しており、成功した実行があり、エラーログはありません。 パフォーマンスメトリクス Lambda 関数のパフォーマンス • メモリ使用量は割り当てられた 512 MB のうち 100～106 MB（約 20% の使用率）で妥当です • ウォームスタートの実行時間は速く、85～195 ms の範囲です • スロットリングやメモリ不足のエラーは検出されませんでした • ログに関数エラーや例外はありません API Gateway メトリクス • 総リクエスト数：11 件のリクエストが記録されました • 平均レイテンシー：797 ms • P95 レイテンシー：3364 ms（高い） • 4XX エラー：0（クライアントエラーなし） • 5XX エラー：1（サーバーエラーが 1 件検出されました） 特定された問題 ログ分析ではエラーは見つかりませんでしたが、メトリクスは 1 つの潜在的な問題を示しています： API Gateway での 1 件の 5XX エラー ：API Gateway ログに 1 件のサーバーサイドエラーが記録されています。Lambda 関数のログに対応するエラーがないため、これは以下に関連している可能性があります： • タイムアウト（API Gateway の応答に時間がかかりすぎている） • API Gateway と Lambda 間の統合の問題 • 一時的なネットワークの問題 比較的高い P95 レイテンシー ：95 パーセンタイルのレイテンシーが 3364 ms と平均と比較してかなり高いです。これは一部のリクエストの完了に大幅に時間がかかっていることを示唆しています。 推奨事項 5XX エラー率が再発するかどうかを監視します。 エラーパスのエッジにより詳細なログ記録を実装することを検討します。 高い P95 レイテンシーの原因を調査します。コールドスタート、ペイロードサイズ、またはネットワークレイテンシーが原因として考えられます。 より詳細な履歴的なレイテンシーとエラーメトリクスのために API Gateway と Lambda のパフォーマンスダッシュボードを有効にすることを検討します。 トラフィックが増加しても性能が健全であることを確認するために、メモリと実行時間のメトリクスの監視を継続します。 Serverless MCP Server がサポートする機能 Serverless MCP Server はいくつかの MCP ツールを提供しており、これらは 4 つのカテゴリに分類できます。 サーバーレスアプリケーションのライフサイクル sam_init_tool ：選択したランタイムと依存関係を持つ新しい AWS SAM プロジェクトを初期化します。 sam_build_tool ：AWS SAM CLI を使用してサーバーレスアプリケーションをビルドし、デプロイアーティファクトを準備します。 sam_deploy_tool ：サーバーレスアプリケーションを AWS にデプロイし、アーティファクトのアップロードとスタックの作成を管理します。 sam_local_invoke_tool ：カスタムイベントと環境でテストするために Lambda 関数をローカルで呼び出します。 Web アプリケーションのデプロイと管理 deploy_webapp_tool ：Lambda Web Adapter を使用して、バックエンド、フロントエンド、またはフルスタック Web アプリケーションを Lambda にデプロイします。 update_frontend_tool ：フロントエンドアセットを更新し、オプションで Amazon CloudFront キャッシュを無効化します。 configure_domain_tool ：証明書と DNS セットアップを含むカスタムドメインを構成します。 可観測性 sam_logs_tool ：ログを取得し、フィルタリングと時間範囲の選択をサポートします。 get_metrics_tool ：指定されたメトリクスを取得します。 ガイダンス、IaC テンプレート、デプロイヘルプ get_iac_guidance_tool ：IaC ツールの選択に関するガイダンスを提供します。 get_lambda_guidance_tool ：特定のランタイムとユースケースに Lambda を使用する場合のアドバイスを提供します。 get_lambda_event_schemas_tool ：Lambda 統合のイベントスキーマを返します。 get_serverless_templates_tool ：さまざまなサーバーレスアプリケーションタイプの AWS SAM テンプレート例を提供します。 deployment_help_tool ：デプロイに関するヘルプとステータス情報を提供します。 deploy_serverless_app_help_tool ：Lambda へのサーバーレスアプリケーションのデプロイに関する指示を提供します。 ツールとリソースの完全なリストについては、Serverless MCP Server の ドキュメント をご覧ください。 ベストプラクティスと考慮事項 AWS Serverless MCP Server でサーバーレスアプリケーションを構築する際は、まず AI 支援のガイダンスを使用してアーキテクチャの決定を行うことから始めましょう。開発全体を通じて、サービスの選択、イベントパターン、インフラストラクチャ設計に関する情報に基づいた決定を行うためにガイダンスツールを使用します。AWS にデプロイする前に、Serverless MCP Server のローカルテスト機能を使用してアプリケーションの動作を検証します。このアプローチは、アプリケーションが AWS のベストプラクティスに沿っていることを確認するのに役立ちます。 本番環境で実行されているアプリケーションを確実に運用するには、堅牢な監視と可観測性が不可欠です。デプロイの監視とログ記録およびメトリクスのセットアップには、Serverless MCP Server ツールを使用します。これにより、アプリケーションのパフォーマンスを追跡し、潜在的な問題を迅速に特定するのに役立ちます。 結論 オープンソースの AWS Serverless MCP Server は、開発ライフサイクル全体を通じて AI 支援のガイダンスを提供することで、サーバーレスアプリケーション開発を効率化します。AI 支援とサーバーレス専門知識を組み合わせることで、開発者はより効率的にアプリケーションを構築およびデプロイできるようになります。Serverless MCP Server のツールセットは、初期化から可観測性まで、完全な開発プロセスをサポートし、開発者が AWS のベストプラクティスを実装するのを支援します。 組織がサーバーレスコンピューティングを採用し続けるにつれて、開発を効率化し、提供を加速するツールはますます価値が高まります。AWS は、サーバーレスアプリケーションを構築する開発者向けの MCP サーバーのコレクションを拡大し、顧客のフィードバックと新たなサーバーレス開発パターンに基づいて既存のツールを改良し続けます。 開始するには、 GitHub リポジトリ にアクセスし、 ドキュメント を探索してください。GitHub リポジトリを通じて経験や提案を共有し、MCP サーバーの機能を改善し、AI 支援のサーバーレス開発の未来を形作るのに役立ててください。 サーバーレス学習リソースの詳細については、 Serverless Land をご覧ください。

この記事は「 Enhance productivity with Amazon Bedrock Agents and Powertools for AWS Lambda 」をソリューションアーキテクトの松本が翻訳したものです。 公共部門は、生産性とサービス提供を向上させるための革新的なソリューションを必要とする独自の課題に直面しています。大規模言語モデル (LLM) はさまざまなアプリケーションで大きな可能性を示していますが、その真価は、最新データ、時間、天気、速報イベントなどのリアルタイム情報にアクセスできるときに発揮されます。この能力は、効果的な公共部門の計画と意思決定に不可欠です。しかし、LLM だけでは、特に動的でタイムセンシティブな業務を管理する公共機関にとって、タイムリーで関連性の高いインサイトを提供するには不十分かもしれません。 学習内容 この記事では、以下について説明します。 公共部門機関が直面する主な課題と、リアルタイムデータアクセスが重要である理由 Amazon Bedrock Agents と Powertools for AWS Lambda がこれらの課題にどのように対応するか 公共部門における実用的なアプリケーションを示す実際のユースケース 技術的な実装の詳細とベストプラクティス 主な課題とリアルタイムデータの必要性 公共部門の業務に LLM を実装する際、公共機関は人工知能 (AI) を効果的に活用する能力を制限するいくつかの重要な課題に直面します。リアルタイムデータへのアクセスが限られていると、LLM が最新かつ実用的なインサイトを提供できなくなり、既存システムとの統合の難しさや厳格なコンプライアンス要件がさらに実装を複雑にします。 リアルタイムデータアクセスは、タイムリーな情報が重要な状況での違いを生む優先対応において特に重要です。また、決定が最新の情報に基づいていることを確保するポリシーコンプライアンスや、公共機関がリソースを最も必要とされる場所に効率的に振り向けるのに役立つリソース配分にも同様に重要です。 Amazon Bedrock Agents と Powertools for AWS Lambda の紹介 これらの課題に対処するために、シームレスに連携する 2 つの強力なツールを活用できます。 Amazon Bedrock Agents は、組み込みのビジネスロジックを持つ AWS Lambda 関数を呼び出すための機能呼び出しを利用します。これにより、外部 API へのアクセスとさまざまなデータソースとの統合が可能になり、API を介した公共機関間のコミュニケーションとデータ共有が促進されます。 サーバーレスのベストプラクティスを実装する開発者ツールキットである Powertools for AWS Lambda (Python) と組み合わせることで、公共機関は高いセキュリティとコンプライアンス基準を維持しながら、開発速度を大幅に向上させることができます。 公共部門における実際のアプリケーション Amazon Bedrock Agents と Powertools for AWS Lambda が、実用的な例を通じて公共機関の業務をどのように改善するかを見てみましょう。 天気予報プロンプト ユースケースの説明 : 州の農業部門は、効果的な害虫駆除と環境への影響を最小限に抑えるために、天気予報に基づいて農薬散布スケジュールを計画する必要があります。 ユーザー : シアトル (ワシントン州) の今後 72 時間の予想降水量はどれくらいですか？ エージェント : シアトル (ワシントン州) の今後 72 時間の予想降水量は 0.5 インチです。 コンプライアンス文書取得プロンプト ユースケースの説明: 公共機関の IT 部門は、公共機関が使用するクラウドサービスが連邦セキュリティ基準を満たしていることを確認するために、最新の FedRAMP コンプライアンス文書を必要としています。 ユーザー: AWS に最近の FedRAMP コンプライアンス文書はありますか？ エージェント: AWS からの最近の FedRAMP コンプライアンス文書をいくつか紹介します… 労働力計画プロンプト ユースケースの説明: 州の雇用機関は、求職者の就職を支援し、地域の熟練労働力を確保するために、IT スペシャリスト向けの最新の求人情報を提供する必要があります。 ユーザー: ワシントン DC から 100 マイル以内の「IT スペシャリスト」の求人を一覧表示してください。 エージェント: ワシントン DC から 100 マイル以内の「IT スペシャリスト」の求人をいくつか紹介します… 主要なアプリケーション分野 データと分析業務 公共機関はリアルタイムデータ分析を活用して、実績に基づく政策決定とリソース配分の最適化を推進できます。この基盤により、より応答性が高く効率的な行政サービスが可能になり、運用コストも削減されます。 以下を通じて政策決定とリソース配分を強化します。 将来の計画のためのリアルタイムの国勢調査と人口統計分析 政策評価のための経済指標モニタリング 自動化された財務報告とデータ取得 既存のデータ管理システムとの統合 運用とコンプライアンス管理 統合されたモニタリングとレポート機能を備えた複雑な運用ワークフローの合理化により、規制コンプライアンスを維持しながら効率性を高め、運用リスクを軽減します。 以下の自動化を通じて運用効率を向上させます。 リアルタイムの航空状況更新とモニタリング AWS Artifact を介した AWS コンプライアンス文書管理 日付/時間の計算と検証プロセス 規制コンプライアンスの追跡とレポート 環境とインフラストラクチャ管理 包括的なモニタリングとデータ駆動型のインサイトを通じて、環境とインフラストラクチャの管理を改善します。このアプローチにより、公共機関は変化を予測し、迅速に対応し、重要なインフラストラクチャをより効果的に維持できるようになります。 以下を含む重要な環境データをモニタリングおよび分析します。 地震活動と地震追跡 正確な位置情報サービスとマッピング 天気予報と悪天候警報 インフラストラクチャの状態とメンテナンススケジューリング 労働力と公衆衛生 リアルタイムデータ分析とトレンドモニタリングを通じて、公衆衛生と労働力の決定を向上させます。このデータ駆動型アプローチにより、正確なヘルスケア計画と戦略的リソース展開が可能になります。 以下によりリソース管理を最適化します。 リアルタイムの労働力可用性追跡 求人市場トレンド分析 公衆衛生データモニタリング 人口健康指標 ソリューションアーキテクチャ コンポーネント Amazon Bedrock LLM : 応答生成に使用される大規模言語モデル。 Amazon Bedrock Agent : ユーザーがソリューションと対話するためのオーケストレーションとタスク分析のインターフェース。 AWS Lambda と Powertools for AWS Lambda (Python) : データ取得と処理のロジックを含む Lambda 関数。 Amazon Bedrock Agent アクショングループ : エージェントが実行するアクションを管理します。 エージェントビジネスロジック : エージェントがユーザークエリを処理するために従う特定のロジックとルール。 Amazon Bedrock Knowledge Base : ポリシー文書、コンプライアンス文書、ビジネス文書を含むリポジトリ。 OpenAPI スキーマ : エージェントが呼び出せる API 操作を定義します。 公共機関 API エンドポイント : 公共機関固有のデータとサービスへのアクセスを提供します。 Amazon Bedrock Guardrails: セキュリティとコンプライアンスポリシーを適用するメカニズム。 基本的な相互作用   ユーザープロンプト: AWS Lambda クライアントが Amazon Bedrock Agent にプロンプトを送信します。   エージェント処理: エージェントは高度な推論を使用してタスクを論理的な順序に分解します。リクエストを満たすために必要な API と対話し、進行するか追加情報を収集するかを決定します。   ガードレール評価: 入力プロンプトが設定されたガードレールに対してコンプライアンスをチェックされます。入力が評価に失敗した場合、ブロックメッセージが返され、プロセスは終了します。   データ取得と実行: 入力がガードレール評価に合格した場合、エージェントは関連する Lambda 関数を呼び出し、タスクを完了するために必要に応じて Knowledge Base にクエリを実行します。   応答生成: タスクの完了後、エージェントは応答を作成します。この応答はコンプライアンスのためにガードレールに対してチェックされます。応答が評価に失敗した場合、ブロックメッセージで上書きされるか、機密情報がマスクされます。   ユーザー応答: コンプライアンスに準拠した応答が AWS Lambda クライアントに返されます。 図 1. この記事で説明するソリューションのアーキテクチャ図。主要なコンポーネントは Amazon Bedrock、AWS Lambda、および Powertools for AWS Lambda です。 このアーキテクチャをさらに詳しく調べるために、これらのコンポーネントが実用的な実装でどのように連携するかを示す Lambda 関数の例を見てみましょう。 技術的な実装 以下は、Powertools for AWS Lambda を使用して天気データを取得する Lambda 関数の実装例です。 # Powertools for AWS のロギングとトレースを初期化 logger = Logger ( ) tracer = Tracer ( service = "WeatherForecastAgent" ) # BedrockAgentResolver は Lambda と Bedrock Agent の統合を処理 app = BedrockAgentResolver ( ) # Bedrock Agent の天気予報呼び出し用のエンドポイントを定義 @app . get ( "/forecast" , description = "Retrieve current weather forecast at a station." ) @tracer . capture_method def get_weather ( station_id : str = Query ( . . . , description = "The id of the weather observation station." ) ) - > dict : # API 呼び出しをログに記録 logger . info ( f"Retrieving weather data for station: { station_id } " ) # 気象観測所の最新の観測データを取得 base_url = "https://<your-api-endpoint>" url = f" { base_url } / { station_id } /observations/latest" response = requests . get ( url , timeout = 30 ) response . raise_for_status ( ) # API レスポンスを解析 data = response . json ( ) # 天気情報を抽出 temperature = data [ 'properties' ] [ 'temperature' ] [ 'value' ] description = data [ 'properties' ] [ 'textDescription' ] # 取得したデータをログに記録 logger . info ( f"Weather for station { station_id } : Temp: { temperature } , Desc: { description } " ) # X-Ray アノテーションをトレースフィルタリング用に追加 tracer . put_annotation ( key = "station_id" , value = f" { station_id } " ) return { "statusCode" : 200 , "body" : data } # ロギングとトレースを使用したメイン Lambda ハンドラー @logger . inject_lambda_context ( log_event = True ) @tracer . capture_lambda_handler def lambda_handler ( event : dict , context : LambdaContext ) - > dict : return app . resolve ( event , context ) if __name__ == "__main__" : # Bedrock Agent 設定用の OpenAPI スキーマを出力 print ( app . get_openapi_json_schema ( ) ) Python この例では: Powertools for AWS Lambda の Logger と Tracer により、関数の実行の包括的な可観測性がロギングとトレースを通じて可能になります。 BedrockAgentResolver は Amazon Bedrock Agent と Lambda 関数間のルーティングを処理し、合理化された API 統合を提供します。 構造化ロギングと AWS X-Ray アノテーションが実装され、API 呼び出しを追跡し、詳細なトレース分析を可能にします。 Powertools は OpenAPI スキーマを生成する機能を提供し、開発者は Bedrock Agent のセットアップ中に API インターフェースを定義するために使用できます。 次の図は、Amazon Bedrock Agent とのサンプル対話を示しており、エージェントがユーザープロンプトを処理し、リアルタイムデータを取得する方法を示しています。エージェントが外部 API と統合し、タイムリーな応答を生成する能力は、公共部門の生産性とサービス提供を向上させる上で重要です。 図 2. Amazon Bedrock Agent の呼び出し例。 包括的な可観測性を確保するため、サンプル Lambda 関数は Amazon CloudWatch をロギングに使用しています。CloudWatch は関数の実行に関する詳細なログイベントを取得し、開発者が問題を診断しパフォーマンスを監視するのに役立ちます。 図 3. Amazon CloudWatch ログイベントの例。 可観測性をさらに強化するために、Lambda 関数は分散トレース用に AWS X-Ray と統合されています。X-Ray は関数の実行の視覚的なマップを提供し、開発者がシステム全体でリクエストの流れを追跡し、ボトルネックを特定し、パフォーマンスを最適化することを可能にします。 図 4. AWS X-Ray トレースマップの例。 この例は、Amazon Bedrock Agents と統合された Powertools for AWS Lambda のいくつかの付加価値機能を強調しています。組み込みの可観測性、自動スキーマ生成、標準化されたエラー処理の組み合わせにより、開発サイクルが加速し、本番環境レベルの信頼性が維持されます。これらの機能により、開発チームは AI 対応アプリケーションを自信を持って迅速にプロトタイプ作成し、デプロイすることができます。 結論 Amazon Bedrock Agents と Powertools for AWS Lambda を活用することで、公共機関は生成 AI と LLM の可能性を最大限に引き出し、イノベーションを推進し、市民へのサービス提供を改善することができます。これらのツールは、リアルタイムデータへのアクセスを可能にすることで LLM の機能を強化し、開発者の速度を大幅に向上させます。これにより、公共機関はインフラストラクチャの複雑さに対処するのではなく、市民に価値を提供することに集中できます。結果として、より機敏で応答性が高く、効果的な公共部門が実現し、構成員のニーズをより良く満たすことができます。 次のステップ このブログの技術的なソリューションを確認するには、この投稿の GitHub リポジトリ をご覧ください。さらなる読み物とリソースについては、以下のリンクをご覧ください。 リソース Powertools for AWS Lambda (Python) Amazon Bedrock Agents Amazon Bedrock のマルチエージェントコラボレーション機能の紹介 (プレビュー)

7 月 15 日より、 Amazon EventBridge の拡張ログ記録機能を使用して、包括的なログでイベントドリブンのアプリケーションをモニタリングおよびデバッグできます。これらの新しい機能強化は、イベントフローのモニタリングとトラブルシューティングの方法を改善するのに役立ちます。 Amazon EventBridge コンソール でこの新しい機能を見つける方法は次のとおりです: 新しいオブザーバビリティ機能は、包括的なイベントライフサイクル追跡を提供することで、マイクロサービスとイベントドリブンのアーキテクチャのモニタリングの課題に対処します。EventBridge は、ルールに一致したイベントが発行されたり、サブスクライバーに配信されたり、失敗して再試行されたりするたびに、詳細なログエントリを生成するようになりました。 成功、失敗、ステータスコードに関する詳細情報により、イベントの進行状況全体を可視化できるため、問題の特定と診断が容易になります。以前は何時間もかかっていた試行錯誤によるデバッグが、詳細なイベントライフサイクル追跡と組み込みのクエリツールにより、数分で完了するようになりました。 Amazon EventBridge の拡張オブザーバビリティの使用 Amazon EventBridge のログ記録機能をご紹介するデモをご覧ください。 既存のイベントバス、または新しいカスタムイベントバスを作成する際に、ログ記録を有効にすることができます。まず、EventBridge コンソールに移動し、左側のナビゲーションペインで [イベントバス] を選択します。 [カスタムイベントバス] で、 [イベントバスを作成] を選択します。 この新しい機能は、 [ログ] セクションに表示されます。 [ログの保存先] を設定するには、 Amazon CloudWatch Logs 、 Amazon Data Firehose ストリーム、 Amazon Simple Storage Service (Amazon S3) の 3 つのオプションがあります。ログをデータレイクにストリーミングする場合は、Amazon Kinesis Data Firehose ストリームを選択します。 イベントバスにカスタマーマネージドキー (CMK) が指定されている 場合、ログは転送中に TLS で、および保管中に暗号化されます。CloudWatch Logs はカスタマーマネージドキーをサポートし、Data Firehose はダウンストリームの宛先のためにサーバー側の暗号化を提供します。 このデモでは、 [CloudWatch ログ] と [S3 ログ] を選択します。 また、 [ログレベル] を [エラー]、[情報]、[トレース] から選択することもできます。ペイロードを確認する必要があるため、 [トレース] を選択し、 [実行データを含める] を選択します。ペイロードデータのログ記録には機密情報が含まれる場合があり、この設定は選択したすべてのログの保存先に適用されるため、注意が必要です。その後、 [CloudWatch ロググループ] と [S3 ログ] のそれぞれに 1 つずつ、合計で 2 つの保存先を設定します。そして、 [作成] を選択します。 ログ記録が有効になったら、テストイベントの発行を開始して、ログ記録の動作を観察できます。 最初のシナリオでは、 AWS Lambda 関数を構築し、この Lambda 関数をターゲットとして設定しました。 [イベントを送信] を選択して、イベントバスに移動し、サンプルイベントを送信します。 使用するペイロードを次に示します: { "Source": "ecommerce.orders", "DetailType": "Order Placed", "Detail": { "orderId": "12345", "customerId": "cust-789", "amount": 99.99, "items": [ { "productId": "prod-456", "quantity": 2, "price": 49.99 } ] } } サンプルイベントを送信すると、S3 バケットでログが使用可能になっていることがわかります。 また、Amazon CloudWatch ログにログエントリが表示されているのがわかります。ログには、 EVENT_RECEIPT から SUCCESS までのイベントライフサイクルが表示されます。イベントのライフサイクル全体の詳細については、TBD:DOC_PAGE をご覧ください。 それでは、これらのログを評価してみましょう。簡潔にするために、いくつかのログのみを含めることとし、読みやすくするために編集しています。イベントをトリガーした際のログを次に示します: { "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging", "message_timestamp_ms": 1751608776896, "event_bus_name": "demo-logging", // REDACTED FOR BREVITY // "message_type": "EVENT_RECEIPT", "log_level": "TRACE", "details": { "caller_account_id": "123", "source_time_ms": 1751608775000, "source": "ecommerce.orders", "detail_type": "Order Placed", "resources": [], "event_detail": "REDACTED FOR BREVITY" } } イベントが正常に呼び出された際のログを次に示します: { "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging", "message_timestamp_ms": 1751608777091, "event_bus_name": "demo-logging", // REDACTED FOR BREVITY // "message_type": "INVOCATION_SUCCESS", "log_level": "INFO", "details": { // REDACTED FOR BREVITY // "total_attempts": 1, "final_invocation_status": "SUCCESS", "ingestion_to_start_latency_ms": 105, "ingestion_to_complete_latency_ms": 183, "ingestion_to_success_latency_ms": 183, "target_duration_ms": 53, "target_response_body": "<REDACTED FOR BREVITY>", "http_status_code": 202 } } 追加のログエントリには、トラブルシューティングを容易にするリッチなメタデータが含まれています。例えば、イベントが成功した場合、イベントの開始から完了までのレイテンシータイミング、ターゲットが処理を完了するまでの期間、HTTP ステータスコードを確認できます。 完全なイベントライフサイクル追跡による失敗のデバッグ EventBridge のログ記録の利点は、問題が発生したときに明らかになります。失敗のシナリオをテストするために、Lambda 関数の許可を意図的に誤って設定し、適切な許可のない別の Lambda 関数をポイントするようにルールを変更します。 許可が不足しているため、試行は永続的な失敗で終わりました。ログには、 FIRST 試行が NO_PERMISSIONS ステータスで終わったことが示されています。 { "message_type": "INVOCATION_ATTEMPT_PERMANENT_FAILURE", "log_level": "ERROR", "details": { "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed", "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123", "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail", "attempt_type": "FIRST", "attempt_count": 1, "invocation_status": "NO_PERMISSIONS", "target_duration_ms": 25, "target_response_body": "{\"requestId\":\"a4bdfdc9-4806-4f3e-9961-31559cb2db62\",\"errorCode\":\"AccessDeniedException\",\"errorType\":\"Client\",\"errorMessage\":\"User: arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123:function:demo-evb-fail because no identity-based policy allows the lambda:InvokeFunction action\",\"statusCode\":403}", "http_status_code": 403 } } 最後のログエントリには、タイミングメトリクスと正確なエラーメッセージとともに、完全な失敗の概要が示されています。 { "message_type": "INVOCATION_FAILURE", "log_level": "ERROR", "details": { "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed", "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123", "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail", "total_attempts": 1, "final_invocation_status": "NO_PERMISSIONS", "ingestion_to_start_latency_ms": 62, "ingestion_to_complete_latency_ms": 114, "target_duration_ms": 25, "http_status_code": 403 }, "error": { "http_status_code": 403, "error_message": "User: arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123:function:demo-evb-fail because no identity-based policy allows the lambda:InvokeFunction action", "aws_service": "AWSLambda", "request_id": "a4bdfdc9-4806-4f3e-9961-31559cb2db62" } } ログは、ボトルネックを特定するのに役立つ詳細なパフォーマンスメトリクスを提供します。 ingestion_to_start_latency_ms: 62 はイベントの取り込みから呼び出しを開始するまでの時間を示し、 ingestion_to_complete_latency_ms: 114 は取り込みから完了までの合計時間を表します。さらに、 target_duration_ms: 25 は、ターゲットサービスの応答にかかった時間を示しており、EventBridge の処理時間とターゲットサービスのパフォーマンスを区別するのに役立ちます。 エラーメッセージには、失敗したアクション ( lambda:InvokeFunction アクション )、失敗した理由 ( ID ベースのポリシーでアクションが許可されていない )、関係するロール ( Amazon_EventBridge_Invoke_Lambda_1428392416 )、影響を受けた特定のリソース (Lambda 関数の Amazon リソースネーム (ARN) で示されます) が明確に記載されています。 EventBridge のログ記録機能を使用した API の宛先のデバッグ EventBridge のログ記録機能が特に役立つと思われるユースケースの 1 つは、API の宛先に関する問題のデバッグです。 EventBridge API の宛先 は、イベントバスルールまたはパイプのターゲットとして呼び出すことができる HTTPS エンドポイントです。HTTPS エンドポイントは、HTTPS 呼び出しを使用して、イベントバスから、外部システム、Software as a Service (SaaS) アプリケーション、またはサードパーティー API にイベントをルーティングするのに役立ちます。これらは接続を使用して認証と認証情報を処理します。これにより、イベントドリブンのアーキテクチャを HTTPS ベースのサービスと簡単に統合できます。 API の宛先は、外部の HTTPS エンドポイントにイベントを送信するためによく使用されますが、外部エンドポイントからのエラーのデバッグの失敗は課題となる場合があります。これらの問題は通常、エンドポイントの認証要件の変更や、変更された認証情報に起因します。 このデバッグ機能のデモを行うため、意図的に、接続リソースで誤った認証情報を使用して API の宛先を設定しました。 この誤って設定されたエンドポイントにイベントを送信すると、拡張ログ記録でこの失敗の根本原因が示されます。 { "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging", "message_timestamp_ms": 1750344097251, "event_bus_name": "demo-logging", //REDACTED FOR BREVITY//, "message_type": "INVOCATION_FAILURE", "log_level": "ERROR", "details": { //REDACTED FOR BREVITY//, "total_attempts": 1, "final_invocation_status": "SDK_CLIENT_ERROR", "ingestion_to_start_latency_ms": 135, "ingestion_to_complete_latency_ms": 549, "target_duration_ms": 327, "target_response_body": "", "http_status_code": 400 }, "error": { "http_status_code": 400, "error_message": "Unable to invoke ApiDestination endpoint: The request failed because the credentials included for the connection are not authorized for the API destination." } } ログによって失敗の概要がすぐにわかります。target_arn はこれが API の宛先に関係していることを示し、 final_invocation_status は SDK_CLIENT_ERROR を示していて、 http_status_code は 400 です。これは、クライアント側の問題を示しています。最も重要なのは、 error_message が次のように明示的に示しているということです: ApiDestination エンドポイントを呼び出すことができません: 接続のために含まれた認証情報が API の宛先について認可されていないため、リクエストは失敗しました。 この完全なログシーケンスは、デバッグに関する役立つインサイトを提供してくれます。なぜなら、イベントの受信から、取り込み、ルールのマッチング、呼び出しの試行まで、EventBridge を通じてイベントがどのように移動したのかを正確に把握できるからです。この詳細度により、推測作業が排除され、問題の根本原因を直接特定できます。 知っておくべき追加情報 いくつかの留意点を次に示します: アーキテクチャサポート – ログ記録は、カスタムイベントバス、パートナーイベントソース、HTTPS エンドポイントの API の宛先など、すべての EventBridge 機能で機能します。 パフォーマンスへの影響 – ログ記録は非同期で実行されるため、イベント処理のレイテンシーやスループットに測定可能な影響はありません。 料金 – ログの保存と配信には、Amazon S3、Amazon CloudWatch Logs、または Amazon Data Firehose の標準料金がかかります。EventBridge のログ記録自体には追加料金はかかりません。詳細については、 Amazon EventBridge の料金ページ にアクセスしてください。 可用性 – Amazon EventBridge のログ記録機能は、EventBridge がサポートされているすべての AWS リージョンでご利用いただけます。 ドキュメント – 詳細については、 Amazon EventBridge のモニタリングとデバッグに関するドキュメント をご覧ください。 Amazon EventBridge のログ記録機能の使用を開始するには、 EventBridge コンソール にアクセスし、イベントバスでのログ記録を有効にしてください。 構築がうまくいきますように! –  Donnie 原文は こちら です。

本稿は、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 の詳細と技術的なガイダンスについては、 ユーザーガイド を参照してください。 翻訳はテクニカルアカウントマネージャーの安藤 彰が担当しました。