本記事は、2025 年 6 月 2 日に公開された Best practices for upgrading Amazon MWAA V1.x to V2.x を翻訳したものです。翻訳はプロフェッショナルサービスの佐藤が担当しました。 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は、データ駆動型の意思決定をする組織にとって重要な基盤となっています。複雑なデータパイプラインを管理するためのスケーラブルなソリューションとして、Amazon MWAA は AWS サービスとオンプレミスのシステム間でシームレスなオーケストレーションを実現します。AWS がインフラストラクチャを管理していますが、お客様は責任共有モデルに従って Amazon MWAA 環境の更新を慎重に計画し実行する必要があります。最新の Amazon MWAA バージョンへのアップグレードにより、重要なセキュリティパッチを通じたセキュリティの強化や、DAG の解析の高速化とデータベース負荷軽減による性能の向上など、大きなメリットが得られます。また、エコシステムの互換性を維持しながら高度な機能を使用でき、AWS からの優先的なサポートを受けることができます。アップグレードを成功させるカギは、適切なソリューションを選択し、体系的な実装アプローチに従うことにあります。 この記事では、Amazon MWAA 環境のアップグレードのベストプラクティスを紹介し、最新バージョンへのシームレスな移行のためのステップバイステップガイドを提供します。 ソリューションの概要 Amazon MWAA は 2 つの主要なアップグレードソリューションを提供します。 インプレースアップグレード – この方法は、計画的なシステム停止時間が認められる場合に最適です。既存のインフラストラクチャに直接新しいバージョンをデプロイします。Amazon MWAA では、Apache Airflow バージョン 2.x 以降を実行している環境でインプレースアップグレードがサポートされています。バージョン 1.10.z 以前を実行している場合、これらのバージョンではインプレースアップグレードをサポートしていないため、新しい環境を作成してリソースを移行する必要があります。 カットオーバーアップグレード – この方法は、稼働中のシステムへの影響を最小限に抑えるのに役立ちます。対象のバージョンで新しい Amazon MWAA 環境を作成し、古い環境から新しい環境に移行します。 各ソリューションは、データの整合性とシステムの信頼性を維持しながらアップグレードを支援する、異なるアプローチを提供します。 インプレースアップグレード インプレースアップグレードは、アップグレードプロセスのためのメンテナンスウィンドウをスケジュールできる環境に適しています。このウィンドウ中、Amazon MWAA はワークフローの履歴を保持します。この方法は、計画的なシステム停止時間が認められる場合に最適です。これにより、履歴データが維持され、わかりやすいアップグレードプロセスが提供されます。また、この方法には、プロビジョニング中に問題が発生した場合のロールバック機能も含まれています。また、新しい環境を作成する必要がないため、リソースの使用も少なくて済みます。 AWS マネージメントコンソール で、1 回の操作でインプレースアップグレードを実行できます。このプロセスでは、多くのアップグレード手順を代わりに実行してくれるため、運用の手間を削減できます。 アップグレードプロセス中は、新しいタスクのスケジュールや実行はできません。Amazon MWAA はアップグレードプロセスを自動的に制御し、安全性を確保するための仕組みを組み込んでいます。プロビジョニングフェーズで問題が発生した場合、サービスは以前の安定バージョンへの復元を試みます。 インプレースアップグレードを開始する前に、DAG の互換性の問題がアップグレードプロセスに影響を与える可能性があるため、ターゲットバージョンとの DAG の互換性をテストすることをお勧めします。アップグレードを開始する前に、 Amazon MWAA ローカルランナー (注) を使用して DAG の互換性をテストできます。アップグレードは、コンソールで 新しいバージョンを指定 するか、 AWS Command Line Interface (AWS CLI) を使用して開始できます。以下は、AWS CLI を使用した Amazon MWAA アップグレードコマンドの例です： aws mwaa update-environment --name <value> --airflow-version <value> 注: Apache Airflow バージョン 2.9 以降では、Amazon MWAA の本番環境で使用されている Docker イメージがオープンソース化されています。MWAAと同一の環境でテストを行う場合は、 aws-mwaa-docker-images の使用を推奨します。ただし、MWAA ローカルランナーも引き続き、 MWAA でサポートされているすべての Apache Airflow バージョンでテストやパッケージング要件の確認に使用することができます。 次の図は、Amazon MWAA のインプレースアップグレードのワークフローと状態を示しています。 詳細については、 Amazon MWAA でのインプレースバージョンアップグレードの紹介 をご参照ください。 カットオーバーアップグレード カットオーバーアップグレードは、ダウンタイムを最小限に抑える必要がある場合の代替ソリューションを提供しますが、より多くの手動ステップと運用計画が必要です。このアプローチでは、新しい Amazon MWAA 環境を作成し、メタデータを移行し、環境間の移行を管理します。この方法は、アップグレードプロセスをより柔軟に管理できますが、インプレースアップグレードと比較して、より多くの計画と実行の労力が必要になります。 この方法は、複雑なワークフローを持つ環境で効果的に機能します。特にバージョンアップグレードと共に大きな変更を計画している場合に適しています。このアプローチにはいくつかの利点があります。本番環境のダウンタイムを最小限に抑え、環境を切り替える前に包括的なテストを実施し、必要に応じて元の環境に戻すことができます。また、移行中に設定を確認して更新することもできます。 カットオーバーアプローチについて、以下の点を考慮してください。2 つの環境を同時に実行する場合、両方の環境の料金が発生します。各 Amazon MWAA 環境の料金は、以下の要素に依存します： 環境の稼働時間 (秒単位の精度で 1 時間ごとに課金) 環境サイズ ワーカーの自動スケーリング容量 スケジューラー容量 AWS は、自動スケーリングされた追加のワーカーのコストを個別に計算します。 AWS Pricing Calculator を使用して、特定の構成のコストを見積もることができます。 既存環境と新しい環境を並行して稼働させる際のデータの重複や破損を防ぐため、べき等な DAG の実装を推奨します。Airflow スケジューラは、新しい環境で一部のメタデータテーブル (dag、dag_tag、dag_code) を自動的に設定します。ただし、以下の追加のメタデータコンポーネントの移行を計画する必要があります： DAG 実行履歴 Variables (変数) Slot pool の設定 SLA 違反の記録 XCom データ ジョブ記録 ログテーブル ダウンタイムを最小限に抑えることを優先し、追加の運用上の複雑性に対応できる場合は、このアプローチを選択できます。 カットオーバーアップグレードプロセスは、新しい環境の作成、新しい環境への移行、アップグレードの実行という 3 つの主要なステップで構成されています。以下の図は、全体のワークフローを示しています。 以下のセクションでは、カットオーバーアップグレードを実行するための主要なステップについて説明します。 前提条件 アップグレードプロセスを開始する前に、以下の手順を実行してください： Airflow のリリースノート と Amazon Managed Workflows for Apache Airflow の Apache Airflow バージョン を確認してください。 現在の環境設定とメタデータをバックアップしてください。 mwaa-dr PyPI パッケージを使用して、メタデータを Amazon Simple Storage Service (Amazon S3) バケットに保存するバックアップ DAG を作成し実行できます。詳細については、 Amazon MWAA での DAG の操作 をご覧ください。 DAG の互換性をテストしてください。 Amazon MWAA ローカルランナー 、または オープンソースイメージリポジトリ を使用して、DAG、requirements、プラグインを検証できます。 互換性テスト用のテスト環境を作成してください。ガイダンスについては、 Python 依存関係を管理するための Amazon MWAA のベストプラクティス をご覧ください。 新しい環境の作成 新しい環境を作成するには、以下の手順を実行してください。 AWS CLI を使用して、新しい環境設定のテンプレートを生成します： aws mwaa create-environment --generate-cli-skeleton > <new-env-name>.json 生成された JSON ファイルを変更します： バックアップファイル <env-name>.json から <new-env-name>.json に設定をコピーします。 環境名を更新します。 既存の環境から AirflowVersion パラメータの値を維持します。 必要に応じて他の設定パラメータを確認し更新します。 新しい環境を作成します: aws mwaa create-environment --cli-input-json <content of new-env-name.json> 新しい環境への移行 元の環境を新しい環境に移行するには、以下の手順を実行してください： mwaa-dr PyPI パッケージを使用して、リストア DAG を作成し実行します。 このプロセスでは、S3 バックアップバケットからメタデータを新しい環境にコピーします。 新しい環境に、元の環境から期待されるメタデータが含まれていることを確認します。 アップグレードの実行 バージョンアップグレードを実行するには、以下の手順を実施してください。 環境をアップグレードします: aws mwaa update-environment --name <new-env-name> --airflow-version <target-version> アップグレードのモニタリングをします: コンソールで環境のステータスを追跡します。 エラーメッセージや警告がないかモニタリングします。 環境が AVAILABLE に到達することを確認します。 移行のタイミングは慎重に計画してください。アップグレードの最中に元の環境でワークフローを動かし続けると、新旧の環境でワークフローの情報 (メタデータ) が食い違ってしまう恐れがあります。 クリーンアップ モニタリングを通じてアップグレードされた環境の安定性を確認した後、クリーンアップ作業を開始できます: AWS CLI コマンドを使用して、元の Amazon MWAA 環境を削除します: aws mwaa delete-environment --name <old-env-name> S3 バケットから未使用のバックアップデータを削除し、アップグレード用に作成した一時的な AWS Identity and Access Management (IAM) ロールとポリシーを削除し、DNS やルーティング設定を更新することで、関連リソースをクリーンアップします。 リソースを削除する前に、組織のバックアップ保持ポリシーに従い、コンプライアンス要件に必要なバックアップデータを維持し、アップグレード中に行った設定変更をドキュメント化してください。 このアプローチにより、テストの機会を確保しながら、必要に応じて元の環境に戻ることができる、制御されたアップグレードを実行できます。 モニタリングと検証 Amazon CloudWatch メトリクスを使用して、DAG 処理メトリクスとスケジューラーのハートビートに焦点を当てながら、アップグレードの進行状況を追跡できます。環境は、アップグレードプロセス中に UPDATING や CREATING などのいくつかの状態に移行します。環境が AVAILABLE 状態になったら、検証を開始できます。システムのアクセス性の確認、重要なワークフローの操作のテスト、外部接続の検証を行うことをお勧めします。詳細なモニタリングのガイドについては、 Amazon Managed Workflows for Apache Airflow のモニタリングとメトリクス をご参照ください。 主な考慮事項 インフラストラクチャ・アズ・コード (IaC) のプラクティスを活用して、環境管理の一貫性と再現可能なデプロイメントをサポートすることを検討してください。データを保護するため、 mwaa-dr を使用してアクティビティの少ない時間帯にメタデータのバックアップをスケジュールしてください。ワークフローを設計する際は、潜在的な中断に対処するためにべき等性のあるパイプラインを実装し、設定と依存関係のドキュメントを維持してください。 まとめ Amazon MWAA の効果的なアップグレードは、運用要件に合ったアプローチを選択することから始まります。インプレースアップグレードまたはカットオーバーアップグレードのいずれを選択する場合でも、入念な準備とテストにより、制御された移行を実現できます。利用可能なツール、モニタリング機能、推奨プラクティスを活用することで、ワークフローの運用を維持しながら、最新の Amazon MWAA 機能へのアップグレードを実現できます。 Amazon MWAA の詳細とコード例については、 Amazon MWAA ユーザーガイド と Amazon MWAA サンプルの GitHub リポジトリ を参照してください。 Apache、Apache Airflow、および Airflow は、米国および/またはその他の国における Apache Software Foundation の登録商標または商標です。 著者について Anurag Srivastava は、Amazon Web Services (AWS) のシニアビッグデータクラウドエンジニアとして、Amazon MWAA を専門に担当しています。 AWS 上でスケーラブルなデータパイプラインとワークフロー自動化ソリューションの構築に関して、お客様を支援することに熱心に取り組んでいます。 Sriharsh Adari は、Amazon Web Services (AWS) のシニアソリューションアーキテクトとして、ビジネス成果を起点として、AWS 上で革新的なソリューションを開発するお客様を支援しています。 長年にわたり、様々な業界のお客様のデータプラットフォーム変革を支援してきました。 テクノロジー戦略、データ分析、データサイエンスが主な専門分野です。 余暇にはスポーツを楽しみ、テレビ番組を一気見したり、タブラを演奏したりしています。 Venu Thangalapally は、シカゴを拠点とする AWS のシニアソリューションアーキテクトで、クラウドアーキテクチャ、データとアナリティクス、コンテナ、アプリケーションのモダナイゼーションに関する深い専門知識を持っています。 金融サービス業界のお客様と協力して、ビジネス目標を、測定可能な価値を提供する安全でスケーラブルかつコンプライアンスに準拠したクラウドソリューションに変換しています。 Venu は、テクノロジーを活用してイノベーションと運用効率の向上を推進することに情熱を注いでいます。 仕事以外では、家族と過ごすこと、読書、長距離散歩を楽しんでいます。 Chandan Rupakheti は AWS のシニアソリューションアーキテクトです。 AWS では、アナリティクス、サーバーレス、AdTech サービスが重なり合う領域を主な専門としています。 情熱的な技術リーダー、研究者、メンターとして、クラウドにおける革新的なソリューションの構築に長けています。 プライベートでは、家族や友人と過ごすことや、音楽を聴いたり演奏したりすることを楽しんでいます。

正直に言うと、私はまだ ニューヨークの AWS Summit からから立ち直れておらず、 Amazon Bedrock AgentCore (プレビュー) や Amazon Simple Storage Service (S3) Vectors などのリリースでレベルアップするために最善を尽くしています。学ぶべき新しいことがたくさんあります！ 一方、信頼性とオブザーバビリティに焦点を当てた AWS ビルダーにとっては、エキサイティングな週でした。最も注目すべき発表は、マルチテナントアーキテクチャにおける最も根深い課題の 1 つである「ノイジーネイバー」問題に取り組む Amazon SQS フェアキューでした。あるテナントのメッセージ処理が共有インフラストラクチャを圧迫し、他のテナントに影響を与えた経験があるなら、この機能によってアプリケーション間でよりバランスの取れたメッセージ分散が可能になることをご理解いただけるでしょう。 AI の面でも、AWS は Amazon CloudWatch 生成 AI オブザーバビリティのプレビューリリースにより、オブザーバビリティ機能を引き続き強化しています。これにより、AI を活用した分析情報が監視ワークフローに直接取り込まれ、インフラストラクチャとアプリケーションのパフォーマンスパターンを新しい方法で理解できるようになります。また、 Amazon Connect の環境を管理している人にとっては、メッセージテンプレートの添付用に AWS CloudFormation を追加することで、さまざまな環境にわたって E メールキャンペーンのアセットをプログラム的にデプロイして管理することが容易になります。 7 月 21 日週のリリース Amazon SQS フェアキュー — AWS は、マルチテナントシステムにおける「ノイジーネイバー」問題を軽減し、共有インフラストラクチャ全体でよりバランスの取れたメッセージ処理とアプリケーションの耐障害性の向上を実現するために、Amazon SQS フェアキューを導入しました。 Amazon CloudWatch 生成 AI オブザーバビリティ (プレビュー) — AWS は、Amazon CloudWatch 生成 AI オブザーバビリティのプレビューを開始しました。これにより、ユーザーは高度なモニタリングと分析機能を通じて、クラウドインフラストラクチャとアプリケーションのパフォーマンスについて AI を活用した洞察を得ることができます。 Amazon Connect CloudFormation のメッセージテンプレート添付ファイルのサポート — AWS は、Outbound Campaign のメッセージテンプレート添付ファイル用の AWS CloudFormation のサポートを導入することで Amazon Connect の機能を拡張し、顧客がさまざまな環境にわたって E メールキャンペーンの添付ファイルをプログラムで管理および展開できるようにしました。 Amazon Connect 予測編集 — Amazon Connect では、新しい予測編集 UI が導入されました。これにより、コンタクトセンターのプランナーは、特定の日付範囲、キュー、チャネルにわたる予測をパーセンテージまたは正確な値で迅速に調整できるため、より迅速な人員計画が可能になります。 Amazon ElastiCache のブルームフィルタ — Amazon ElastiCache は、Valkey のバージョン 8.1 でブルームフィルタをサポートするようになりました。これにより、従来のセットと比較して 98% 以上のメモリ効率で、アイテムがセット内にあるかどうかをすばやく確認できるスペース効率の高い方法が提供されます。 Amazon EC2 Skip OS Shutdown Option — AWS は、インスタンスを停止または終了するときにオペレーティングシステムの正常なシャットダウンをスキップできる Amazon EC2 の新しいオプションを導入しました。これにより、アプリケーションの回復とインスタンスの状態遷移が高速化されます。 AWS Healthomics Git リポジトリ統合 — AWS Healthomics では、ワークフロー作成のための Git リポジトリの直接統合がサポートされるようになりました。これにより、研究者は、バージョン管理と再現性を実現しながら、GitHub、GitLab、Bitbucket のリポジトリからワークフロー定義をシームレスに取得できるようになりました。 AWS Organizations Tag Policies Wildcard Support — AWS Organizations は、タグポリシーでワイルドカードステートメント (ALL_SUPPORTED) をサポートできるようになりました。これにより、ユーザーは、特定の AWS サービスでサポートされているすべてのリソースタイプに 1 行でタグ付けルールを適用できるようになり、ポリシーの作成が簡素化され、複雑さが軽減されます。 注目のブログ IAM アクセスキーを超えて: 最新の認証アプローチ — AWS では、従来の IAM アクセスキーからより安全な認証方法に移行することを推奨しています。これにより、ID 管理への最新のより堅牢なアプローチを活用することで、認証情報の漏洩や不正アクセスのリスクを軽減できます。 近日開催予定の AWS イベント AWS re:Invent 2025 (2025 年 12 月 1 日〜 5 日、Las Vegas) — AWS の主力年次カンファレンスでは、ピアツーピア学習、専門家主導のディスカッション、貴重なネットワーキングの機会を通じて、共同イノベーションを提供します。 AWS Summits – クラウドコンピューティングコミュニティが集まり、交流し、協力し、AWS について学ぶことができる無料のオンラインイベントと対面イベントに参加しましょう。最寄りの都市、 メキシコシティ (8 月 6 日) および ジャカルタ (8 月 7 日) で開催されるイベントにご登録ください。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 シンガポール (8 月 2 日)、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18日) です。 原文は こちら です。

はじめに IoT カメラの活用は、監視、防犯、産業機器のモニタリング、スマートシティ、リテール分析など、さまざまな分野で急速に広がっています。それに伴い、カメラ映像をクラウドや AI と連携させるための接続方式や構成も多様化しており、用途に応じた最適なアーキテクチャの選定がますます重要になっています。 近年、クラウドコンピューティングの進化やエッジ AI の普及により、映像データの処理方法にも変化が見られます。従来は、すべての映像をクラウドに送って解析するのが一般的でしたが、最近ではエッジデバイス側でリアルタイムに処理し、必要な結果だけをクラウドに送信する方式も徐々に広がりつつあります。これにより、リアルタイム性の向上、ネットワーク帯域の節約、ストレージコストの削減といったメリットが期待できます。 こうした処理方式の多様化により、カメラの接続方式やデータ処理の設計においては、単なる映像の記録・送信にとどまらず、リアルタイム性、スケーラビリティ、コスト効率、セキュリティといった複数の要素を総合的に考慮することが求められます。システム全体の価値を最大化するためには、これらの要素のバランスをとったアーキテクチャ設計が重要です。 IoT カメラと AWS IoT の接続パターン IoT カメラのAWS IoTとの連携方法は、主に以下の図の4つのパターンが考えられます。 図1: IoT カメラと AWS IoT 連携の接続パターン ①は複数のカメラをエッジゲートウェイなどで集約する従来からの方法、②はカメラから Amazon Kinesis Video Streams へプロデューサーライブラリを使って直接接続する方法、③は①のゲートウェイをクラウドでホストし、VPNを使ってカメラに接続する方法、④はカメラでの推論結果を AWS IoT Core へ送信する方法です。ここで②と④はゲートウェイなどの中継装置を使わず、カメラ単体で実現可能なことからスモールスタートしやすく、オンサイトでのメンテナンス性が高く、コスト効率もよい方法といえます。一方で、Amazon Kinesis Video Streams プロデューサーライブラリのインストール機能やエッジ推論機能などカメラ側に高度な機能が必要になります。 i-PRO moducaと KVS Connect i-PRO 株式会社が提供するモジュールカメラ moduca は、豊富な選択肢があるハードウェア・モジュールを自由に組み合わせ、目的や用途に応じてBTO（Build To Order）ができるカメラです。moduca ではi-PRO 株式会社が提供する AI アプリケーションやユーザが作成した任意のカスタムアプリケーションを moduca の UNIX ベースの OS 上で動作させることができます。 図2: i-PRO モジュールカメラ（moduca） KVS Connect は富士ソフト株式会社が開発している moduca のカスタムアプリケーションで、 Amazon Kinesis Video Streams プロデューサーライブラリ を含めて moduca 向けにビルドされています。KVS Connect を使うとmoduca から Amazon Kinesis Video Streams へのビデオ送信を簡単に始めることができます 。 ここからは moduca と KVS Connect を例に、最近広まりつつある IoT カメラと AWS IoT をゲートウェイを介さずに直接接続するパターンについて説明します。 IoT カメラから Amazon Kinesis Video Streams への直接接続 ②の接続構成では AWS 上で Amazon Kinesis Video Streams の ストリームを作成し 、moduca に KVS Connect をインストールして設定します。さらに AWS IoT Core の 認証情報プロバイダー を設定することで、KVS Connect は AWS IoT Core またはユーザーの管理する認証局が発行する X.509 クライアント証明書 を使用して Amazon Kinesis Video Streams への接続を認証・認可することができます。 ユーザーは富士ソフト株式会社より KVS Connect を入手し、moduca の Web 画面 からインストール・設定を行います。 図3：moduca カスタムアプリケーションの設定画面 図4：KVS Connect の設定画面 IoT カメラでのエッジ推論と推論結果の AWS IoT Core への送信 ④の接続構成は moduca のカスタムアプリケーションを作成することで実現することができます。ユーザーは i-PRO 社の Development Partner Portal からダウンロードした i-PRO SDK を活用して任意のカメラアプリケーションを構築することができます。例えば Yolo8 を使った物体検知 と AWS IoT Device SDK を使った MQTT による AWS IoT Core との連携により AWS IoT と連携したエッジ推論と通知を行うアプリケーションを構築することができます。 クラウド録画とエッジ AI のアーキテクチャ例 ここまで見てきた内容を考慮して、クラウド録画とエッジAIを実現するシステム全体のアーキテクチャ例を紹介します。IoT カメラ、カメラアプリケーション、AWS のマネージドサービスを組み合わせることで 、IoT カメラから直接 Amazon Kinesis Video Streams へのクラウド録画を行いながら、カメラアプリでの動体検知に基づくリアルタイムアラートや検知イベントの検索など、ユースケースに合わせたシンプルな IoT カメラソリューションを End-to-End に構築することが可能になります。さらにクラウド上で画像を Amazon Bedrock の生成 AI モデルに解析させて、画像のコンテキストを分析させるなど、高度な推論を行うアプリケーションへ発展させることも可能です。 図5：クラウド録画とエッジ AI のアーキテクチャ例 まとめ 本記事では、カメラのクラウド接続パターンの中から、特にカメラ単体で実現できる方法を2つ紹介しました。1つ目は、Amazon Kinesis Video Stream プロデューサーライブラリを利用したクラウド録画、2つ目は、カメラでの推論結果を AWS IoT Core へ送信する方法で、いずれも moduca とKVS Connect を活用した具体例をもとに解説しました。 カメラの高度な機能と AWS のマネージドサービスを活用することで、カメラの接続をシンプルに実現でき、ユーザーは映像データを活用した AI 分析や高度なソリューション開発により多くの時間を割くことが可能になります。用途に応じた最適なアーキテクチャを選択し、AWS とカメラの活用をさらに広げていく参考になればと思います。 著者紹介 高橋 秀明　 i-PRO株式会社　シニアバイスプレジデント AI/IoTカメラとソフトウェアを「産業のビルディングブロック」として提供し、各業界のチェンジリーダーが生産性向上に挑戦できる環境を構築しています。柔軟なシステム設計を可能にするソリューションを通じて、社会と産業の進化に貢献します。 福嶋 征己　 富士ソフト株式会社 カメラソリューション担当として、カメラ×AIシステムの提案、開発・構築を行っています。最近では、Amazon Bedrock Agentsを活用したサービスの構想を進めており、生成AIをどのように活用できるかを検討しています。週末は一眼レフカメラを片手に、風景や子供の写真を撮影して過ごしています。 井上 昌幸　 アマゾンウェブサービスジャパン合同会社　IoT Specialist Solutions Architect Internet of Things と Robotics 界隈で面白い事を探しながら、今日もこつこつリアルな世界とクラウドを繋いでいます。あなたのとっておきのアイデアを AWS と一緒にカタチにしましょう。

はじめに 6月25日～26日に開催されたAWS Summit Japan 2025において、「生成AIエージェントハッカソン」を実施いたしました。本ハッカソンは、AI時代における人と技術の新しい関係性を探求する画期的なイベントとなりました。多くの参加者の皆様、審査員の皆様、そして関係者の皆様のご協力により、素晴らしいイベントを開催することができました。本ブログでは、その詳細な開催報告をお届けします。 ハッカソンの主旨とテーマ テーマ：「使いたおして『○○』を実現するAIエージェント爆誕祭」 今回のハッカソンは、従来の「AIをどう活用するか」という問いから一歩進んで、「AIエージェントを限界まで使い倒すことで、人は何を実現したいのか」という本質的な問いに向き合うことをテーマとしました。 背景と狙い 生成AIが私たちの仕事や生活に欠かせないものとなる中、AIエージェントの進化により「人は何をすべきか」という問いがより切実になってきています。本ハッカソンは、参加者がAIエージェントを徹底的に活用することで、それでも残る人間固有の価値や目的を明確にすることを狙いとしました。 参加者の皆様には「○○」の部分に、AIエージェントを使い倒すことで実現したい目的を設定していただき、その実現に向けたソリューションの開発に挑戦していただきました。 より詳しいテーマと背景については こちら から ハッカソン開催ステップ 1. 募集〜参加確定〜予選まで 5月1日：QuizKnock伊沢拓司氏 / 鶴崎修功氏をゲストにお招きした「 ユースケース開発ワークショップ 」をオンライン開催　（ワークショップの動画は こちら から） 5月16日：採択1４チーム確定  （採択チーム一覧はこちらから 5月20日〜6月20日：採択チーム向けメンタリング実施 2. 予選（6月25日@ホテルニューオータニ幕張） 8分間のプレゼンテーション AWS審査員による審査により6チームが決勝進出 予選 3. 決勝（6月26日 @AWS Summit Japan Expoステージ会場） 7分間のプレゼンテーション 審査員による最終審査 表彰式 審査について 本ハッカソンでは、以下の観点で審査を実施しました： 有用性 ユースケースの明確さ（対応する機会） アプリケーションの品質 創造性 AI エージェントにより ○○ が実現できるか / AI エージェントが使いたおされることで○○が持続的に実現されるか プレゼンテーション（決勝のみ） なお、本ハッカソンの決勝では、多様な専門性を持つ2名の外部審査員を含む以下4名の審査員によって審査が行われました。 [審査員] 鶴崎修功氏（QuizKnock） 安野貴博氏（AIエンジニア/参議院議員） 山口能迪（AWS Developer Advocate） 松本鋼治（AWS シニア事業開発マネジャー） 予選について 予選では、全国から多数のエントリーをいただきました。各チームには事前にユースケースを提出していただき、それを判断材料として厳正な審査を行い、14チームを決勝進出チームとして採択いたしました。 予選は決勝の前日にあたるAWS Summit Japan初日の6月25日に、ホテルニューオータニ幕張で開催されました。採択された14チーム全てが8分間のプレゼンテーションを行い、6名のAWSの審査員による厳正な審査が実施されました。 予選会場では、各チームが開発期間中に磨き上げた作品を熱心に発表し、質疑応答では審査員から技術的な詳細や実装の工夫、今後の展開可能性について鋭い質問が投げかけられました。ここでの評価を経て、最終的に6チームが翌日の決勝戦への切符を手にしました。 参加チームが設定した「○○」は実に多様で、日常生活の課題解決から専門的な業務支援、新しいコミュニケーションの形まで、参加者の豊富な発想力と問題意識が反映されていました。フリマ販売の自動化、創作活動の支援、農業ビジネスのアシスト、家電と人、家電同士の対話、プロジェクトの円滑な引継ぎ、k8s技術学習の促進、引っ越し後の生活シミュレーション、思考の構造化、金融リテラシー向上、育児支援、組織エンゲージメント向上、ペット飼育サポート、レシピ動画を活用した映える献立作成など、AIエージェントを活用して実現したい目的の幅広さが印象的でした。 各チームのプレゼンテーション動画は こちら から 決勝について 決勝戦は、AWS Summit Japan 2025の会場である幕張メッセのAWS Summit Japan Expoステージで公開形式で実施されました。予選は非公開で行われましたが、決勝では多くのAWS Summit来場者の皆様に決勝進出6チームの発表をご覧いただくことができました。 決勝のナビゲーターには、QuizKnockの伊沢拓司氏とフリーキャスターの吉﨑智宏氏が登場し、巧みな進行で会場の熱気を最高潮に導いてくれました。両氏の絶妙な掛け合いと各チームへの的確なコメントにより、見どころもわかりやすく伝えられ、会場全体が一体となって各チームの発表を応援する雰囲気が醸成されました。 QuizKnock 伊沢氏、鶴崎氏、AIエンジニア安野氏が登場する決勝の動画は こちら から 各チームとも「使いたおして『○○』を実現するAIエージェント」というテーマを体現した、素晴らしい作品を発表しました。全てのチームに共通して言えることは、ユースケースやアーキテクチャーの素晴らしさもさることながら、洗練されたUIを兼ね備えていたということです。 AIエージェント時代の可能性について考える貴重な機会となりました。各チームの発表後には審査員との質疑応答も行われ、技術的な詳細や今後の展開について活発な議論が交わされました。 vvvv 審査員を務めるQuizKnock 鶴崎氏（左）、安野氏（右） 決勝の会場のようす ナビゲーターのQuizKnock 伊沢氏（右）、フリーキャスターの吉﨑氏（左） 審査員からの総評 各審査員から入賞チームに対して以下のようなコメントをいただきました。 最優秀賞：WhiteBoxお酒同好会「KanpAI」への評価 AWS松本氏：「『交流』ということにユースケースをフォーカスし、そこに紐づく打ち手を徹底してAI Agentを駆使して作りこんだ点が優勝へとつながった。コネクトを利用した電話かけにトライし、今後の改善についても触れていた点も加点要素。更に開発までAIで取り組んだということも加点要素となった」 AWS山口：「本物の製品のようで驚いた。飲み会以外に旅行などユースケースの広がりもある。継続性もユーザーに対するフィードバック設計が良い」 安野氏：「完成度が高い！！１ヶ月で作ったと思えないUIの完成度。」 鶴崎氏：「『これもやってくれるんだ！』ということの連続で個人的には1位です。使い倒している感じがありますね。」 優勝チーム WhiteBox お酒同好会 準優勝：チームぶち上げ「プロジェクト引継ぎAI」への評価 安野氏：「課題の選定と解決策がうまくマッチしていた。引継ぎでいつも苦労するので将来性高い。」 鶴崎氏：「プロジェクトを俯瞰できている人がいなくなるということが引継ぎの難しさだと思うので、AIが俯瞰役を担ってくれるのは非常にいいですね。」 準優勝チーム　チームぶち上げ 第3位：かっぱときゅうりと味噌「おそとびより」への評価 AWS山口：「子供がいる家庭向けにはかなりうれしい。似た手法で様々なユースケースに対応できそう。今後の展望も継続性が見られる」 安野氏：「子育て世代の悩みの解像度が高そう。プロトタイプを触ってもらいながら改善を重ねられていたのもGood.」 鶴崎氏：「子育てという、AIが技術の入りづらそうな分野へアプローチが良いですね。より直感的、誰でもすぐに使えるようになれば相当いいと思います。」 三位チーム かっぱときゅうりと味噌 その他注目チームへの評価 電通デジタル アドバンストクリエイティブ＆AIチーム「Clip Ninja」 　鶴崎氏：「『練習できる』のが魅力的に思えました。プレゼン資料がやや見づらいなと思ったので、プレゼン資料も助けてくれるといいと思いました。」 デストロイヤーズ　「KOPR」 鶴崎氏：「Kubernetes素人、ゲーム好きの私としてはぜひ遊んでみたいです。公開をお待ちしております！」 BAE-RECIPE 　鶴崎氏：「アプリ画面が非常に使いやすそうで、ユーザーフレンドリーでいいと思います。確かにYouTubeとかのレシピ、作ったことがないですね。」 審査員の皆様からは、技術的な完成度だけでなく、ユースケースの明確さ、継続利用の設計、プレゼンテーションの質など、多角的な観点から詳細なフィードバックをいただきました。 まとめ 今回の「AWS Summit Japan 2025 生成AIエージェントハッカソン」は、１ヶ月弱の短い期間にも関わらず、高い完成度をもつ作品が多数登場しました。この完成度の高さのもたらした大きな要因は生成AIにあると言ってもよいでしょう。 技術的な評価と成果 参加者の皆様が創り出したソリューションは、AIエージェントの技術的な可能性を大きく押し広げるものでした。特に今回のハッカソンで特筆すべきは、採択チームにアンケートを実施したところ、ほぼ全てのチームが開発にCoding Agentを使用していたという事実です。 この結果、これまでのハッカソンでは考えられないほどの完成度の高さを全作品で実現することができました。特にUIについては、ハッカソンのような短期間では実装し切れないことが多いにも関わらず、非常に洗練されたUIが各チームで実現されていました。これは、AIを活用した開発がもたらす生産性向上の具体的な証左と言えるでしょう。 技術的な評価ポイントとしては以下が挙げられます： マルチモーダルAIの活用：テキスト、音声、画像を組み合わせた自然な対話インターフェースの実現 外部システム連携：API連携やWeb scraping、データベース活用による実用的なソリューション構築 継続学習とフィードバック機能：ユーザーの使用パターンから学習し、継続的に改善されるシステム設計 AWS各種サービスの効果的な活用：Claude、Lambda、Connect、RDS等のAWSサービスを適材適所で組み合わせた実装 商用レベルのUI/UX：Coding Agentの支援により、短期間で実用レベルの直感的で使いやすいインターフェースを実現 特に最優秀賞のWhiteBoxお酒同好会チームが1ヶ月という短期間で商用レベルのUIと機能を実現したことは、Coding Agentをはじめとする現在のAI開発支援ツールの威力を示す象徴的な事例となりました。このような**「AIがAIを作る」時代の到来**を明確に示したハッカソンとなったことも、大きな意義の一つです。 今後への期待 今回のハッカソンで示されたのは、AIエージェントが単なる効率化ツールではなく、人間の可能性を拡張し、より豊かな生活を実現するパートナーとしての役割です。参加者の皆様が描いた未来像は、技術と人間が協働して創り出す、より創造的で充実した社会の姿を表しています。 さらに、本ハッカソン後の7月には、新たなAI コーディング環境「Kiro」が発表されました。これにより、AIを活用したアプリ開発がより身近に、より便利になっています。今回のハッカソンでCoding エージェントが示した可能性は、Kiroのような新しいツールによってさらに拡張され、より多くの方々がAIアプリケーション開発に参加できる環境が整いつつあります。 私たちは、今回のハッカソン参加者の皆様をはじめ、すべてのデベロッパーの皆様に、ぜひこれからもAWSを活用して、これまでできなかった何かを実現するアプリを作って欲しいと心から願っています。AIの力を借りることで、アイデアから実装までの距離は確実に短くなっており、誰もが自分の想像力を形にできる時代が到来しています。 AWSは今後も、お客様が最も大切にしていることの実現を支援するため、技術革新と価値創造の両面から取り組みを続けてまいります。今回のハッカソンで生まれたアイデアや議論が、より充実したAI時代の仕事・生活の実現につながることを期待しています。 最後に、本ハッカソンにご参加いただいた全ての皆様、審査員としてご協力いただいたQuizKnock鶴崎修功氏、安野貴博氏、ナビゲーターとしてご登壇いただいたQuizKnock 伊沢拓司氏、吉﨑智宏氏、そして開催にご協力いただいた関係者の皆様に心より感謝申し上げます。

本ブログは、株式会社 IMAGICA Lab. と Amazon Web Services Japan が共同で執筆しました。 データ転送サービスの現状 近年、大容量データをクラウドに移行するニーズが急速に高まっています。一方で、回線の帯域やセキュリティ、人員不足などの課題からスムーズな移行が難しいケースも少なくありません。IMAGICA Lab. では、こうしたお客様の課題解決を支援するソリューションとして、「IMAGICA Cloud Connect」の活用を提案しています。 「IMAGICA Cloud Connect」とは IMAGICA Cloud Connect は、データのアップロードを代行するサービスです。専用ネットワーク回線を活用し、特に AWS へのデータ移行においては、 AWS Direct Connect によるセキュアな通信環境を構築しています。これにより、1 週間で約 40TB 〜 50TB のデータ移行が可能です。 また、データ移行に使用する「可搬用デバイス」のレンタルサービスも提供しています。最小 1TB 〜 最大  57 TB の SSD、NAS を取り揃え、利用時期の 3 か月前から予約が可能です。輸送時には暗号化や物理的なセキュリティ対策も徹底し、安全性を最大限に確保しています。 サービス詳細やご利用料金等は 公式サイト よりご確認いただけます。 IMAGICA Cloud Connect のワークフロー STEP1．現在の環境から可搬用デバイスのコピー（お客様にて実施） 可搬用デバイスにお客様ご自身で AWS にアップロードしたいデータを格納いただきます。 IMAGICA Lab. では可搬用デバイスのレンタルサービスも提供しており、ラインアップは 1TB 〜 57TB の SSD・NAS があり、利用時期の 3 か月前から予約が可能です。 STEP2．可搬用デバイスの輸送 データ格納後の可搬用デバイスは、セキュリティを担保した特輸便を利用し、IMAGICA Cloud Connect 拠点まで安全に輸送されます。 セキュリティ面ではほかにも、デバイスの暗号化 / パスワードロック、鍵付きのハードケースの使用、開封防止シールの使用など、ソフトウェアとハードウェアの両面で安全性を追及しています。 STEP3．IMAGICA Lab.   にてアップロードを実行 IMAGICA Cloud Connect 拠点に到着した可搬用デバイスは、セキュリティカードを持った関係者のみが入室できるスペースで保管、アップロードを実施します。 データ転送の起点となる IMAGICA Cloud Connect 拠点と Direct Connect Location の間は、インターネットとは繋がらない閉域網で接続しています。AWS 環境には、IMAGICA Lab. が所有する AWS Direct Connect を用いて専用線で接続しています。 STEP4．データ確認、作業終了 データが正しく移行されていることをお客様にて確認いただき、作業は完了です。 デバイスレンタルサービスをご利用いただいている場合、デバイス内のデータ消去を行います。 なお、消去方式に関しては研究所レベルの復元ツールでも復元不可能とされている「Purge レベル」での処理を行います。お客様のご要望によっては物理破壊も対応可能です。 アーキテクチャ ■   インフラの検討 IMAGICA Cloud Connect に対しては、オンプレミス上で管理している自社データを Amazon S3 などに移行したいお客様からのご依頼機会が多数あります。 お客様のデータは個人情報や企業の機密情報など、極めて重要度が高く、また秘匿性も高いものが多い傾向にあります。 そのため、そのようなデータを移行するには、でき得る限り外部との接点を持たないような環境にする必要がありました。 そこで、お客様の重要なデータを安全に、かつ安心して Amazon S3 などに格納するために、もっとも重要な要素のひとつであるネットワークインフラの整備を行いました。 ■   データの経路 このネットワークインフラを通るデータの経路もそのひとつです。 パブリック接続経由で Amazon S3 にアップロードする場合にも、通信経路としては AWS のグローバルネットワーク内に閉じますが、さらなるセキュリティ向上を図るため、プライベート接続で AWS PrivateLink のエンドポイントを経由し、お客様の Amazon S3 バケットに到達する経路を構築しました。 ■   データ転送には   AWS DataSync これらのセキュリティを担保したネットワークインフラとデータ経路を基盤とし、お客様の重要なデータを IMAGICA Cloud Connect 拠点からお客様の Amazon S3 に対して高速に、安全に、かつ確実な転送を実現してくれる AWS DataSync を採用しております。 AWS DataSync は、データのコピー前とコピー後のチェックサムを照合し、データの転送が確実に行われていることがわかる証跡レポートを残し、データ転送を行います。 このように IMAGICA Cloud Connect は、お客様の重要なデータを安全、安心、確実に、短期間で Amazon S3 に転送するために、お客様に代わってデータアップロードを代行するサービスです。今後、さまざまなお客様にご利用いただけるようサービス拡充して参ります。 今後の展望 ・回線帯域の増強 ・ Amazon EFS などへのデータアップロード ・ AWS Data Transfer Terminal との協業 まとめ 本ブログでは、株式会社IMAGICA Lab. で提供しているデータ転送サービスの紹介と、その中でどのように AWS サービスを活用しているのかを紹介しました。Direct Connect、PrivateLink、DataSync を組み合わせることで、安心してデータをアップロードいただけます。本ブログがデータの転送方法を検討されている皆様の参考になりましたら幸いです。 著者について 橋本　秀三（Hashimoto Shuzo） 株式会社IMAGICA Lab. CM制作部 テクニカルグループ 映像業界に入りインターネット動画配信の黎明期や、デジタルシネマ普及初期を経験。映像のトランスコード、各種配信サービスローンチの技術サポート、システム開発案件の支援など映像/IT技術サービスに永く携わる。 伊藤　純子（Ito Junko） 株式会社IMAGICA Lab. CM 営業部 テクニカルプロデュースグループ 2013年、前身の株式会社IMAGICAに入社。クラウドを利用した映像データ管理サービスの販売や、スケジュール管理サービスの開発要件定義・企画などを担当。過去メディアのデータ化・マイグレーション作業のコーディネートも行う。 濵野 栞（Hamano Shiori） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト コンテンツプロダクション分野を得意とし、メディア・エンターテインメント業界のお客様に技術的な支援を行う。

本ブログは株式会社 BTM 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの伊勢田 氷琴です。 昨今、多くのお客様から生成 AI を活用した業務効率化についてご相談いただくようになりました。特に、複数のシステムを管理する企業様においては、システム調査や障害対応における関係者間のコミュニケーションコストが大きな課題となっています。 DX 推進事業や IT エンジニアリングサービスを展開する 株式会社 BTM 様 は、自社構築システム調査に対する頻繁な問い合わせ対応と、これに伴って関係者間で発生するコミュニケーションコストの課題を解決するため、 Amazon Bedrock を活用した AI エージェントシステムを構築されました。本記事では、生成 AI と MCP（Model Context Protocol）を組み合わせた革新的なシステム調査自動化の取り組みについてご紹介します。 お客様の状況と課題 株式会社 BTM 様は、従業員数 196 名（2025 年 2 月末時点）の企業として、DX 推進事業と IT エンジニアリングサービスを中核事業とされています。IT エンジニアリングサービスでは、ソフトウェアやシステムの開発に関するサービスを提供し、経験豊富なエンジニアが技術力をもとにお客様の課題解決を行っています。また、DX ソリューションサービスでは、コンサルティングからシステムやIT インフラの設計・構築・運用まで一気通貫でご支援されています。 多数のシステムを管理するシステム運用者として、BTM 様は深刻な課題に直面していました。システム調査を行う際、営業チーム、アプリチーム、インフラチーム、業務部門など多くの関係者とのやり取りが発生し、多大なコミュニケーションコストが生じるというものです。 具体的には、同じ説明を繰り返す必要がある、人によって回答が食い違う、情報が集約されない、必要な情報が揃わない、違うチームへ情報を渡す際に整理が必要になるといった問題が現場では日常的に発生していました。結果的にラウンドが異なる関係者間の情報連携に多大な工数がかかり、迅速な調査を実施しづらい状況でした。 さらに、システム管理者や担当エンジニアが複数のプロジェクトやシステムを担当する場合もあり、限られた時間の中でシステム調査に多くの工数を割きづらいという制約もありました。従来のシステム調査では 1 時間から半日を要しており、1 日に 5 件程度発生する調査依頼に対して、営業担当から詳細をやり取りし、結果を書面で返答するという手間のかかるプロセスが必要でした。 解決策の検討 これらの課題を解決するため、BTM 様は生成 AI を活用したシステム調査の自動化に着目されました。特に、非エンジニアからの問い合わせを生成 AI と MCP を使って自動で調査する仕組みの構築を検討されました。 AWS サービス、特に Amazon Bedrock の採用を決定された理由は、その高い性能と日本語対応の充実にあります。また、オープンソース AI エージェント SDK である Strands Agents を活用することで、わずか数行のコードで AI エージェントを構築・実行できる点も大きな魅力でした。 Strands Agents は、シンプルなエージェントのユースケースから複雑なものまで、そしてローカル開発から本番環境でのデプロイまで対応することができ、実際に AWS の複数チームでも既に Amazon Q Developer 、 AWS Glue 、VPC Reachability Analyzer などの本番環境で AI エージェント基盤として利用されている実績があります。 実装の詳細 BTM 様は、Strands Agents を MCP サーバーと LLM を結びつける基盤として活用されました。MCP とは、生成 AI がツールと連携する方法を標準化したプロトコルであり、MCP サーバーはそのツールに接続するためのサーバーです。MCP サーバーを使用することで生成 AI がツールとしてデータベースへのアクセス API を利用したり、インターネット検索 API を利用できるようになります。 システム構成は以下のようになっています。ユーザーインターフェースとして Slack を活用し、バックエンドには Amazon API Gateway 、 AWS Lambda を使用しました。AI エージェントには Strands Agents を採用し、AWS Lambda に strands モジュールを実装されました。 将来的には、非同期の呼び出しに対応するために、Amazon SQS と Amazon SNS を利用してキューイングすることも検討されています。 AI エージェントの具体的な実装方法については、次のようにしました。まずエラーや障害データ、ログ等が格納されている Amazon Aurora および Amazon DynamoDB 、 Amazon CloudWatch に対してアクセスを可能にする MCP サーバーをコンテナとして Amazon ECS on Fargate でホストします。そして、これらの MCP サーバーを Strands Agents にツールとして渡しました。このようにすることで、AI エージェントは自分が持つツールとその役割を認識し、ユーザーからのリクエストに応じてツールを使い分けながら必要な情報を集め、ユーザーにフィードバックすることが可能となります。 実際のアプリケーションログでは、ユーザからのリクエスト内容を踏まえて、エージェントがどのデータベースにどのようなクエリを発行し、データをクエリした結果を元に回答内容を生成する様子が確認できます。また、日本語に対応した Amazon Bedrock Guardrails を利用して、関係のない問い合わせをブロックする機能も導入されました。 使用している 基盤モデル は Claude 4.0 Sonnet で、高い精度での日本語対応と複雑な推論能力を活用されています。 導入効果 このシステムの導入により、BTM 様は劇的な効果を実現されました。最も顕著な成果は、従来半日を要していたシステム調査時間を最短で10分ほどに短縮したことです。これにより、エンジニアはより本質的な開発業務に集中できるようになりました。さらに、関係者間で必要になる冗長なコミュニケーションが不要となることで、PM のトラブルシュート工数を95%削減しました。 定性的な改善としては、日本語対応した Guardrails を利用し、無関係な問い合わせを効果的にブロックできるようになりました。さらに、開発 AI エージェントの OSS である Cline とそのバックエンドに Amazon Bedrock を使うことで、プロジェクト開始時の開発工数の見積もり40時間に対して、実開発時間を5時間に短縮し、全体で90%の工数を削減することに成功しました。 今後の展開 BTM 様は、今回構築したシステムを同じ悩みを抱えている企業様へ展開していきたいと考えられています。システム調査の自動化という共通課題を持つ企業に対して、この革新的なソリューションを提供することで、業界全体の効率化に貢献したいという意欲を示されています。 お客様の声 株式会社 BTM クラウドインフラ事業部 部長補佐 瀬﨑 優太朗 様からは、以下のようなコメントをいただいています。 「Amazon BedrockでAIエージェントを構築する事で、半日かかっていたシステム調査時間を10分に削減。システム運用保守業務上、ユーザーへの問い合わせ対応が迅速化しました。」 まとめ BTM 様の取り組みは、生成 AI と MCP を組み合わせた革新的なシステム調査自動化の事例として、多くの企業にとって参考になるものです。Amazon Bedrock と Strands Agents を活用することで、従来の手作業による調査プロセスを大幅に効率化し、エンジニアがより価値の高い業務に集中できる環境を実現されました。 このような生成 AI エージェントを活用した業務効率化の取り組みは、今後ますます重要になってくると考えられます。BTM 様の成功事例が、同様の課題を抱える企業様の参考となれば幸いです。 株式会社BTM：瀬崎 優太朗様（右） Amazon Web Services Japan : アカウントマネージャー 浜崎佳子（左）、ソリューションアーキテクト 伊勢田 氷琴（中央）

自動車業界は、車両がメカ主体のシステムから高度なコンピューティングプラットフォームへと進化する中で、大きな変革期を迎えています。この進化の中心にあるのが、SDV (ソフトウェア定義車両) であり、ソフトウェア機能が業界のイノベーションと差別化を牽引し続けています。現代の車両には、安全システムからドライバー支援、インフォテインメント機能まで、複数の電子制御ユニット（ ECU ）にわたって1億行ものコードが含まれています。 自動車システムにおけるハードウェアとソフトウェアの関係性の管理は、特に安全性、セキュリティ、および AUTOSAR （AUTomotive Open System ARchitecture: 車載ソフトウェア開発の国際標準規格 ）などの業界標準への適合性を確保する際に課題となります。 AUTOSAR は 車載組込みソフトウェア の標準化の基盤として機能し、ソフトウェアアーキテクチャ、通信プロトコル、開発手法を包括的なフレームワークとして提供しています。自動車メーカーは AUTOSAR 標準に準拠することで、厳格な機能安全要件を満たしながら、システムの相互運用性と拡張性を確保することができます。 これらの課題に対応するため、 Amazon Q Developer は、一般的な統合開発環境（ IDE ）および Amazon Web Services, Inc. (AWS) Management Console と連携する AI 駆動の専門的なコーディング支援ツールを提供しています。このツールは、コードスニペットの生成と説明、文脈に応じたドキュメンテーションの提供、コードの提案、リファクタリングと最適化の支援、デバッグとトラブルシューティングのサポート、そして C 、 C++ 、 Python を含む様々なプログラミング言語のサポートを通じて、自動車ソフトウェア開発者を支援します。顧客からは、 初期開発が 25% 速く なり、 開発者の生産性が最大 40% 向上 したとの報告があります。 このブログでは、自動車ソフトウェア開発者が Amazon Q Developer を使用して AUTOSAR classic の C/C++ コードを生成する方法について、実践的な例を示します。さらに、 AUTOSAR ソフトウェアコンポーネントを定義する XML （ eXtensible Markup Language ：拡張可能なマークアップ言語）モデルの作成を効率化するための Python の活用方法を探り、業界標準を維持しながら自動車ソフトウェア開発のワークフローを加速する方法をご紹介します。 前提条件： このブログで説明されているデモを自身の IDE で実行するには、以下を確認してください： インストールガイドに従って、お好みの IDE に Amazon Q Developer プラグインをインストールする。 個人のコンピュータに Python と C のプログラミング環境をセットアップする。 **Amazon Q Developer は AWS アカウントがなくても利用可能で、無料利用枠に含まれています。 Amazon Q Developer ライセンスのアップグレードに関心のあるお客様は、 こちら で詳細をご確認いただけます。 重要な注意点として、 Amazon Q Developer のコード生成は、ユーザー定義の標準への準拠を保証するものではなく、開発者は生成されたコードを確認し検証する必要があります。また、生成 AI の非決定論的な性質により、 Amazon Q Developer は以下の例で示すものとは異なる結果を生成する可能性があります。なお、以下のコード例は本番環境での使用を想定したものではありませんのでご注意ください。 AUTOSAR classic ソフトウェア開発の加速化 – ソリューション概要 Amazon Q Developer が開発者をどのように支援できるかを示すため、以下の3つの簡単な例を説明します： ユースケース 1 – AUTOSAR の C/C++ を使った、 LED の点滅とユニットテストの生成 ユースケース 2 – AUTOSAR の C/C++ を使った、ECU から CAN メッセージの送信 ユースケース 3 – AUTOSAR の Python を使ったパッケージコンポーネントを定義 これらの例は、 AUTOSAR の開発における一般的かつ初心者にも分かりやすいユースケースを示しています。学習目的で簡略化されていますが、実際の自動車アプリケーションに直接対応しています。例えば、 LED の制御は、周囲光センサーに基づく自動ヘッドライト点灯などの量産車の照明システムで見られる論理パターンと類似しています。 CAN メッセージングの例は、トランスミッション ECU からメーター表示への速度情報の送信など、車両データの伝送方法を示しています。 ユースケース 1 – AUTOSAR の C/C++ で LED の点滅とテストケースおよびユニットテストの生成 まず、 Amazon Q Developer のインラインコード補完と推奨機能が、機能的なコードと対応するユニットテストを自動的に生成することで、ソフトウェア開発者の AUTOSAR 開発をどのように効率化できるかを実証します。基本的な LED 点滅アプリケーションを例として使用し、このツールが AUTOSAR タスクを作成し、機能を検証するためのユニットテストを生成する方法を示します。 始めるには、「前提条件」セクションで説明したように、 Amazon Q Developer プラグイン をインストールしたIDEを開きます。 Amazon Q Developer で認証 した後、プロジェクトで「 examplec1.c 」という新しい C ファイルを作成し、以下のサンプルコードをコピーします。このコードには、 AUTOSAR 基盤の LED 点滅アプリケーションに必要なヘッダーと LED ピン設定が含まれており、 Amazon Q Developer に生成すべきコードの種類とユースケースのコンテキストを提供します。 サンプルコードの開始： #include "Dio.h" /* AUTOSAR DIO (Digital Input/Output) module header */ #include "Os.h" /* AUTOSAR OS (Operating System) module header */ /* AUTOSAR RTE (Runtime Environment) generated headers */ #include "Rte_Main.h" /* LED pin configuration */ #define LED_PIN 0x01U これで基本的な LED ピン設定のセットアップができたので、 Amazon Q Developer を使用して LED を点滅させる AUTOSAR タスクを作成しましょう。 IDE で、前のステップで example1.c ファイルにコピーしたサンプルコードの下の新しい行に以下のコメントをコピーしてください（図 1 に示すとおり）。 サンプルコメント： /* Create an AUTOSAR task for a LED blinking */ カーソルをこのコメントの末尾に置いて Enter キーを押してください。 Amazon Q Developer はこのコメントを解釈し、 LED 点滅タスクに適した AUTOSAR 準拠のコードを生成します。 **注意 ： Amazon Q Developer は非決定論的であり、以下に示す推奨コードと同じものが生成されるという保証はありません** 図 1 ： Amazon Q Developer を使用して LED 点滅タスクの生成を支援 コード推奨を受け入れるには、 Tab キーを使用します。すると、ファイルは以下のコードのようになります： 更新されたサンプルコード： #include "Dio.h" /* AUTOSAR DIO (Digital Input/Output) module header */ #include "Os.h" /* AUTOSAR OS (Operating System) module header */ /* AUTOSAR RTE (Runtime Environment) generated headers */ #include "Rte_Main.h" /* LED pin configuration */ #define LED_PIN 0x01U /* Create an AUTOSAR task for a LED blinking*/ TASK(LedBlinkTask) { static boolean led_state = FALSE; /* Toggle LED state */ led_state = !led_state; /* Set LED pin state */ Dio_WriteChannel(LED_PIN, led_state); } これで AUTOSAR タスクが定義できましたので、次に必要なモジュールを初期化し、 LED 点滅タスクの周期実行をセットアップするメイン関数を作成する必要があります。適切なコードの生成のため、以下のコメントを Amazon Q Developer に入力してください： サンプルコメント： /* Create the AUTOSAR main function */ 上記と同様に、コメントの末尾にカーソルを置いて Enter キーを押すことで、 Amazon Q Developer のインラインコード補完を起動します。 図 2 ：メイン関数の開発 図 2 に示されているように、 Amazon Q Developer は開発者のレビュー用に必要な AUTOSAR の初期化とスケジューリングコードを正常に生成しました。メイン関数には、 AUTOSAR を初期化するための StartOS() 、 LEDBlinkTask との統合、そして LED 点滅用の 500ms タイマーの設定が含まれています。 更新されたサンプルコード： #include "Dio.h" /* AUTOSAR DIO (Digital Input/Output) module header */ #include "Os.h" /* AUTOSAR OS (Operating System) module header */ /* AUTOSAR RTE (Runtime Environment) generated headers */ #include "Rte_Main.h" /* LED pin configuration */ #define LED_PIN 0x01U /* Create an AUTOSAR task for a LED blinking*/ TASK(LedBlinkTask) { static boolean led_state = FALSE; /* Toggle LED state */ led_state = !led_state; /* Set LED pin state */ Dio_WriteChannel(LED_PIN, led_state); } /* Create the AUTOSAR main function */ MAIN(void) { /* Initialize AUTOSAR modules */ StartOS(MainOsInstConst); /* Create periodic task for LED blinking */ GetTaskID(&LedBlinkTaskId); SetRelAlarm(LedBlinkTaskId, 500, 500); /* 500ms period */ return 0; } わずか数分で、シンプルなインラインコメントを使用して、 Amazon Q Developer で LED 点滅タスクの AUTOSAR コードを生成することができました。この例は、 Amazon Q Developer がワークスペースのコンテキストに基づいてタスクを自動化することで、自動車ソフトウェア開発を加速できることを示しています。現代のソフトウェア定義車両（ SDV ）には、ハザードライトからダッシュボードインジケーターまで、数多くの LED が搭載されています。それぞれが特定のタイミングとパターンを必要とし、自動車メーカーが満たさなければならない厳格な安全基準に準拠する必要があります。 Amazon Q Developer は、コードを生成することで自動車メーカーのソフトウェア開発を加速し、反復的なタスクを削減しながら迅速なプロトタイピングを可能にし、 AUTOSAR 標準を維持することを支援します。 テストケースの作成 Amazon Q Developer のもう一つの価値ある機能は、ユニットテストを生成する能力です。これにより、ソフトウェア開発者はコードが必要な仕様を満たし、エッジケースを効果的に処理することを確認できます。この機能を実証するために、先ほど生成した LED 点滅コードを基に、包括的なユニットテストを作成します。このプロセスでは、 LEDBlinkTask とメイン関数の両方をカバーします。この機能を活用するために、 Amazon Q Developer のチャット機能 を使用します。これにより、より対話的でコンテキストを意識したコード生成が可能になります。既存のコードとテスト要件を Amazon Q Developer に提供することで、様々なシナリオやエッジケースをカバーする関連性の高いユニットテストを迅速に生成することができます。 Amazon Q Developer のチャット機能を使用するには、前のステップで生成したコードを選択して右クリックします。ドロップダウンメニューから、図 3 に示すように Amazon Q → Send to prompt を選択します。 図 3 ： Amazon Q Developer チャットへのコード送信 チャットで以下のプロンプトを入力して Enter を押します： Create unit test cases for the functions in this file 図 4 ： Amazon Q Developer チャットで生成されたテストケース Amazon Q Developer は、 LedBlinkTask とメイン関数のテストケースを生成することができます。以下は、 Amazon Q Developer が生成したメイン関数のテストケースとユニットテストの更新されたコードです： Generate AUTOSAR classic code which will make the ECU send a CAN message with the 4th bit set to 1 when the voltage on pin 1 drops ユースケース 2 – ECU から CAN メッセージの送信 この例では、 Amazon Q Developer を使用して、現代の車両で電気部品の健全性を監視するために一般的に必要とされる電圧監視システムを作成します。具体的には、定期的にピンの電圧を確認し、レベルが閾値を下回った場合に Controller Area Network （ CAN ）メッセージを送信する AUTOSAR C コードを生成します。この種の機能は、電気部品の健全性を監視し、潜在的な問題を検出するために自動車システムで一般的に使用されています。 新しい Amazon Q Developer チャットウィンドウを開き、以下のプロンプトを入力してください（別の方法として、 AWS Command Line Interface (CLI) を使用することもできます）： 図 5 ：新しいチャットウィンドウを開き、 Amazon Q にプロンプト入力 シンプルなプロンプトを使用するだけで、 Amazon Q Develope rは電圧監視のための完全な AUTOSAR classic アプリケーションを生成します。サンプルコードは必要ありません。生成されたコードは、ピンの監視から CAN メッセージの送信まですべてを処理し、 Amazon Q Developer の AUTOSAR アーキテクチャと自動車システムに関する深い理解を示しています。以下のコード構造をご覧ください： 図 6 ： Amazon Q Developer チャットで生成されたコード 新しい C ファイルを作成し、コードを コピー・ペースト してください： /* Include necessary AUTOSAR headers */ #include "Std_Types.h" #include "Can.h" #include "CanIf.h" #include "Com.h" #include "Dio.h" #include "Adc.h" /* Define constants */ #define PIN_1_ADC_CHANNEL 0 #define VOLTAGE_THRESHOLD 2000 // Assuming 2V threshold, adjust as needed #define CAN_MESSAGE_ID 0x100 #define CAN_MESSAGE_DLC 1 /* Global variables */ static uint8 g_canMessageData = 0x00; static boolean g_voltageDropDetected = FALSE; /* Function prototypes */ void InitializeModules(void); void CheckVoltage(void); void SendCanMessage(void); /* Main function */ void MainFunction(void) { InitializeModules(); while(1) { CheckVoltage(); if (g_voltageDropDetected) { SendCanMessage(); } } } /* Initialize required modules */ void InitializeModules(void) { /* Initialize ADC */ Adc_Init(NULL); /* Initialize CAN */ Can_Init(NULL); CanIf_Init(NULL); Com_Init(NULL); } /* Check voltage on pin 1 */ void CheckVoltage(void) { Adc_ValueGroupType adcResult; /* Start ADC conversion */ Adc_StartGroupConversion(PIN_1_ADC_CHANNEL); /* Wait for conversion to complete */ while (Adc_GetGroupStatus(PIN_1_ADC_CHANNEL) == ADC_BUSY) {} /* Read ADC result */ Adc_ReadGroup(PIN_1_ADC_CHANNEL, &adcResult); /* Check if voltage has dropped below threshold */ if (adcResult < VOLTAGE_THRESHOLD) { g_voltageDropDetected = TRUE; } else { g_voltageDropDetected = FALSE; } } /* Send CAN message with 4th bit set to 1 */ void SendCanMessage(void) { PduInfoType pduInfo; /* Set the 4th bit (index 3) to 1 */ g_canMessageData |= (1 << 3); /* Prepare PDU info */ pduInfo.SduDataPtr = &g_canMessageData; pduInfo.SduLength = CAN_MESSAGE_DLC; /* Send CAN message */ Com_SendSignal(CAN_MESSAGE_ID, &pduInfo); } Amazon Q Developer が生成したコードを確認すると、変数定義、メイン関数、電圧確認と CAN メッセージ送信のための専用関数を含む包括的な構造が見られます。この例は、 Amazon Q Developer がコード推奨を提供することで、自動車ソフトウェア開発者のイノベーションを促進できることを示しています。このコードは本番環境での使用準備が整っているわけではなく、ユニットテスト、不正な応答のチェックなど、開発者による調整が必要ですが、開発者に強固な起点を提供します。これにより、初期開発時間を大幅に削減し、自動車ソフトウェア開発チームが特定の車両要件に合わせたカスタマイズと最適化に集中できるよう支援します。 ユースケース 3 – AUTOSAR の Python でのパッケージコンポーネント定義 最後のユースケースでは、 Python を使用した AUTOSAR XML ファイルの作成における Amazon Q Developer の活用を探ります。これらの XML ファイルは、 AUTOSAR Classic コンポーネントの構成要素を定義するため重要です。 ‘os’ と ‘autosar.xml’ ライブラリをインポートする簡単な Python スクリプトから始めて、 Amazon Q Developer が AUTOSAR コンポーネントの設定という煩雑なプロセスの自動化をどのように支援できるかを実証します。サンプルコードには “ AUTOSAR” リポジトリ を使用します。 Amazon Q Developer をインストールした IDE で新しい Python ファイルを開きます。必要な Python ライブラリをインポートすることから始めましょう： サンプルコード： import os import autosar.xml 次に、以下のサンプルコメントを使用して、 AUTOSAR ワークスペースとパッケージを作成することでコードのエントリーポイントを作成できます。 サンプルコメント： # Create workspace and packages 前のユースケースと同様に、上記のコメントをコピーして Enter を押し、 Amazon Q Developer のコード提案を確認します。 Tab を押して、提案されたコードを採用してください。 図 7 ： uint8 基本型定義のためのコメント部分を Amazon Q が補完 更新されたサンプルコード： import os import autosar.xml # Create workspace and packages ws = autosar.xml.Workspace() ワークスペースのセットアップが完了したので、コードを以下のように更新します： import os import autosar.xml # Create workspace and packages ws = autosar.xml.Workspace() # Create a package map with parameters base types and implementation data types ws.create_package_map({"BaseTypes": "DataTypes/BaseTypes", "ImplementationDataTypes": "DataTypes/ImplementationDataTypes"}) print(ws.get_package("BaseTypes").name) このコードにより、基本型と実装データ型のパッケージマップを作成しました。残りの機能の開発を加速するため、基本型を出力表示しています。これにより Amazon Q Developer が既存コードのパターンを学習し、実装データ型の新しい出力文を自動補完できるようになります。 図 8 ： Amazon Q Developer が前のコードから学習し、 uint8 基本型定義のコメント部分を補完することで、反復的なタスクとプロセスを加速化 更新されたサンプルコード： import os import autosar.xml # Create workspace and packages ws = autosar.xml.Workspace() # Create a package map with parameters base types and implementation data types ws.create_package_map({"BaseTypes": "DataTypes/BaseTypes", "ImplementationDataTypes": "DataTypes/ImplementationDataTypes"}) print(ws.get_package("BaseTypes").name) print(ws.get_package("ImplementationDataTypes").name) この例は、デモンストレーション目的で簡略化されていますが、 Amazon Q Developer が Python での AUTOSAR XML ファイル作成を自動車ソフトウェア開発者にとってどのように効率化できるかを示しています。特に注目すべきは、 Amazon Q Developer のパターン認識能力です。既存のコードから学習することで、 Amazon Q Developer は類似の操作に対して適切な提案を行い、開発時間を大幅に削減できます。本番環境での使用にはさらなる拡張が必要ですが、 Amazon Q Developer が AUTOSAR コンポーネント設定という複雑なプロセスの効率化をどのように支援できるかを示しています。 クリーンアップ Amazon Q Developer には、毎月最大 50 回までの IDE 操作が可能な無料利用枠があります。このデモンストレーションは無料枠の制限内ですが、今回作成したものをクリーンアップする場合は、以下の手順に従ってください： お使いの IDE で作成したファイルを削除 お使いの IDE の手順に従って Amazon Q Developer 拡張機能をアンインストール 結論 このブログ記事では、 Amazon Q Developer が AI 駆動のコード推奨機能を通じて、自動車メーカーのソフトウェア開発プロセスをどのように加速できるかを探りました。実践的な例として、3 つの主要アプローチを実証しました： (a) インラインコメントを使用した AUTOSAR コードの生成支援、 (b) Amazon Q チャットを使用した包括的なユニットテストの作成、 (c) Python での AUTOSAR パッケージコンポーネントの定義です。これらの例は Amazon Q Developer の開発時間削減における強力な機能を示していますが、生成されたコードは本番環境での使用前に徹底的なレビューとカスタマイズが必要であることを忘れないことが重要です。 Amazon Q Developer は開発サイクルを加速し、反復的なコーディング作業を削減する知的なアシスタントとして機能しますが、専門的なソフトウェア開発者の判断と自動車業界のベストプラクティスを補完するものであり、置き換えるものではありません。 Amazon Q Developer の詳細については、 Amazon Q Developer 入門ページ をご覧いただくか、 AWS チームまで お問い合わ せください。 このブログの翻訳はソリューションアーキテクトのショーン・セーヒーが担当しました。原文は「 Helping Accelerate AUTOSAR development for Software Defined Vehicles with Amazon Q Developer 」です。

はじめに 本ブログは、株式会社丸千代山岡家と Amazon Web Services Japan が共同で執筆しました。 みなさま、こんにちは。AWS ソリューションアーキテクトの本田・大久保です。 株式会社丸千代山岡家 様(以下、山岡家) では、 券売機から注文情報が自動的に厨房のタブレットに連携され調理が開始できるタイマーアプリとして「ゆで麺タイマー」を 2019 年より開発し、従業員の早期戦力化や体験向上といった課題解決にアプローチしています。 2025 年 6 月 25 日 ~ 6 月 26 日に幕張メッセで開催された AWS Summit Japan 2025 では、ラーメン山岡家様のブースにて、経営企画室 副室長 テクニカルエンジニアの田中様より、実際の店舗運用で活用されているゆで麺タイマーの仕組みをご紹介いただきました。会場では、来場者が直接ゆで麺タイマーの操作を体験できるデモも実施され、多くの方々から高い評価をいただきました。 本記事は、AWS Summit Japan 2025 での山岡家様ブース展示内容をもとに再構成したものとなります。 図1 : AWS Summit Japan 2025 での展示の様子 ラーメン山岡家とは 株式会社丸千代山岡家は、北海道を本社とするラーメン専門店「ラーメン山岡家」を運営する企業です。山岡家では、 好みに応じてラーメンをカスタマイズできるサービスと、豊富なサイドメニューが人気を博し、 東日本の主要幹線道路沿いを中心に 150 店鋪以上を展開しています。 山岡家における「麺あげオペレーション」の課題 麺の調理を担当する「麺あげ」は、調理の中でも重要なオペレーションです。山岡家では、顧客好みの固さにオーダーすることができ、調理の際にはメニューごとに麺の種類を使い分けています。従来の「麺あげ」オペレーションでは、厨房機器メーカー製の業務用タイマー装置を各店舗に設置して運用していました。しかし、このタイマーは実際の麺の位置と画面上のタイマーの表示位置が一致しておらず、視認性に課題がありました。また、熟練した職人の技術に依存する部分も多く、スタッフの育成やオペレーションの標準化に時間がかかっていました。こうした機器は店舗ごとの設置環境の差異も大きく、保守や管理の負荷が高いだけでなく、新しい機能の迅速な追加やシステムのアップデートが困難でした。その結果、繁忙時間帯の最適な注文対応や業務効率化にも限界がありました。 これらの課題を解決するため、クラウドベースのソリューションとして AWS を採用しました。AWS のサーバーレスサービスを活用することで、現場ごとの機器管理やインフラ運用の負担を大幅に軽減しつつ、高い可用性や柔軟なスケーリングを実現できます。また、AWS の各種サービスを組み合わせてシステムを構築することで、機能の追加や変更を段階的かつ迅速に行えるようになりました。例えば、まずは基本的なタイマー機能からスタートし、後から調理順序の自動最適化やデータ分析など、現場のニーズに応じて柔軟に機能拡張していくことができます。 AWS アーキテクチャ概要 図2 : ゆで麺タイマーのアーキテクチャ 受付処理（ AWS Fargate for Amazon ECS ） : AWS のサーバレスサービスである AWS Fargate を中核とし、コンテナ化されたアプリケーションが構築されています。券売機からの注文リクエストを受信し、Amazon ElastiCache Serverless へ保存します。 データ保存と転送（ Amazon ElastiCache Serverless for Redis ） : 注文データをインメモリで高速に保存し、Redis Stream を通じて最適化処理へとデータを転送します。Redis を採用した理由としては、厨房の業務のスピード感に対応できる高速なレスポンス性能が求められていたことと、麺を茹でるまでの約 10 分間だけデータを保持できれば要件を満たせることが挙げられます。また、 クラスターモード の利用によって単一障害点が軽減されることも採用の理由の一つです。加えて、Redis が OSS（オープンソースソフトウェア）であり、豊富な技術情報やコミュニティサポートを利用できるため、開発・運用面での情報収集が容易に行える環境が整っていることもメリットと感じています。 Snowflake は、トランザクションログの格納とマスタ管理の 2 つの用途で利用しています。オーダー履歴、調理履歴、障害発生の有無といった券売機の状態を Snowflake に格納しています。調理履歴を分析・モデル化することで業務最適化を目指しています。また、全店舗の調理基準を本部で一元管理できるよう、Snowflake をマスタデータの管理にも利用しています。本部の担当者は、店舗やメニュー、麺の情報を Salesforce でメンテナンスしており、Salesforce 上のデータは Datacloud 経由で Snowflake に取り込まれています。さらに、このデータは定期的に Redis にも同期して運用しています。 最適化処理（AWS Fargate for Amazon ECS + Amazon Bedrock ） : 最適化処理用の Fargate コンテナが Amazon Bedrock の生成 AI モデルに問い合わせ、店舗の状況や注文内容に基づいた調理順序を決定します。 タブレットアプリ（AWS Fargate for Amazon ECS） : UI は React で構築され、 Amazon CloudFront にデプロイされています。複数台のタブレットを利用することがあるので、注文情報・調理状態・最適化済み調理順序など、全ての状態をバックエンドで保持し、変更が検知されると、リアルタイムで対象店舗の全てのタブレットアプリに送信されます。 サーバーレスサービスを最大限活用することで、コストを抑えつつスモールスタートできる柔軟性を評価して開発をスタートしました。さらに、AWS Fargate や Amazon ElastiCache Serverless といったサーバレスサービスを多く採用することによってインフラ管理の負担を大幅に軽減しながら、高い可用性とスケーラビリティを実現しています。これにより、ビジネスロジックやユーザー体験の向上に集中して開発に取り組むことが可能になりました。また、Amazon Bedrock の活用により生成 AI を使った調理順序の最適化にも取り組んでいます。 ゆで麺タイマー導入による効果 ゆで麺タイマーの導入により、以下のような効果が得られました： 従業員の早期戦力化 : 前述したように、従来システムでは視認性の問題や熟練職人への依存といった課題により、スタッフの育成やオペレーションの標準化に時間がかかっていました。しかし、ゆで麺タイマーの導入したことで、直感的な UI/UX により、新人スタッフでも短期間で「麺あげ」業務を習得できるようになりました。従来は約 500 日かかっていたスキルの習得期間が 350 日程度に短縮され、スタッフの早期戦力化に大きく貢献しています。 図3 : キッチン業務習得までの所要日数 オペレーション効率の向上: 券売機からの注文情報が自動的にタイマーアプリに連携されることで、手作業による入力ミスが削減されました。調理の正確性が向上し、顧客がオーダーする好みの固さでの提供する精度向上にも寄与しています。 また、ゆで麺タイマーは店舗内のオペレーション体制の最適化において重要な役割を果たしています。山岡家の店舗あたりの来客数は年々増加傾向にあり、2025 年には 1 店舗あたり月間 15,000 人を突破しました。このような状況下でも店舗側のオペレーションがボトルネックとなり、顧客対応が滞る事態を未然に防ぐ役割を果たしています。ゆで麺タイマーの導入により、1 杯のラーメンあたりの提供時間が平均 30 秒削減され、来客数の増加に対しても顧客満足度を維持しながら安定したサービスを提供できています。 図4 : 店舗あたりの月間来客数 紙ベース運用からデジタル化によるコスト削減へ： 現在、券売機から受けた注文内容は、厨房のキッチンプリンタに連携され自動で印刷される仕組みとなっています。しかし、これは厨房で調理する順序通りになっておらず、ホールで受けた麺の茹で加減のオーダーも含まれていないこともあって、積極的には活用されていませんでした。これからは直接注文情報がキッチンのゆで麺タイマーに連携され、調理順に沿って並び替えられて表示されます。キッチンプリンタの廃止によって、ロール紙コスト 600 万/年の削減が実現される見込みです。 成功のポイントと今後の展望 図5 : ゆで麺タイマー開発プロジェクトの時系列 ゆで麺タイマープロジェクトの成功には、いくつかの要因がありました。最も重要だったのは現場主導の開発アプローチです。プロトタイプとして試作したシステムを現場のスタッフに試験的に使用してもらい、「本州と北海道では、同じ麺でもゆで時間が異なる」「キッチンスタッフが利用する上で、操作しやすく遠くからの視認性が高い UI/UX が良い」といったフィードバックを反映させながら機能改善することで、現場のニーズに即したシステムを構築できました。開発期間中は、システムをリリースして現場の意見をもらい、そのフィードバックを反映させた改良版を約 2 週間ごとにリリースするというサイクルを何度も繰り返しました。このような定期的なフィードバックループを通して継続的に改善を重ねることで、使いやすさと実用性を両立することができました。 技術面では、AWS のサーバレスサービスの採用が大きな成功要因となりました。AWS Fargate や Amazon ElastiCache Serverless などを活用することで、インフラ管理の負担を軽減し、開発リソースをビジネス価値の創出に集中させることができました。 今後の展望として、調理順序最適化機能のさらなる改良も進めています。現在、Amazon Bedrock を活用した生成 AI による調理順序最適化を試験的に導入しており、従来のアルゴリズム開発と比較して実装のハードルが大幅に低減されました。この生成 AI アプローチにより、熟練スタッフの経験や知識をシステムに組み込むことができ、全店舗で均一かつ高品質なサービスを提供できるようになりました。将来的には「お子様ラーメンは早めに提供する」「ラーメンと餃子のセットなど、複数のメニューを一緒に提供する」といった指示を自然言語で行える柔軟な拡張も計画しています。 おわりに 山岡家のゆで麺タイマーは、AWS のサーバレスサービスを活用することで、従来の課題を解決し、従業員の早期戦力化と顧客満足度の向上を実現しました。外食産業におけるデジタルトランスフォーメーションは、単なる業務効率化だけでなく、従業員体験と顧客体験の両方を向上させる重要な取り組みです。今後も山岡家では、AWS の最新技術を活用しながら、さらなるデジタル化を推進し、従業員と顧客の双方にとって価値のあるサービスを提供していきます。 著者について 田中 陽里 株式会社丸千代山岡家 経営企画室 副室長 2023 年より現職。外食産業における DX を推進し、ゆで麺タイマーの企画から開発、導入までを主導。 好きな AWS サービスは Amazon Elastic Container Service です。 大久保 裕太 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっています。IoT 領域が得意で、好きな AWS サービスは AWS IoT Core。 本田 光来 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっています。サーバーレス領域が得意で、好きな AWS サービスは AWS Lambda です。

本ブログは株式会社トライト様と Amazon Web Services Japan 合同会社が共同で執筆しました。 みなさん、こんにちは。Amazon Web Services（以下 AWS）アカウントマネージャーの竹中です 。 株式会社トライト（以下 トライト）様において、顧客体験を起点としたサービス企画・開発の強化とイノベーション創出・意思決定の迅速化を目指す取り組みの一環として、AWS 主催の「体験版 Working Backwards セッション」を東京・大阪の2拠点で計4回開催しました。保育士、看護師、介護職、歯科衛生士向けキャリア支援サービスを担当する約55名の多様な職種の皆様にご参加いただき、顧客中心の発想やチームビルディング、実践的なアイデア創出を体験していただきました。ワークショップの満足度は94.5%と高く、今後のサービス開発・改善活動に向けた大きな一歩となりました。 この記事では、トライト様にご参加いただいたセッションの模様についてご紹介させていただきます。 トライト様について トライト様は、医療福祉を中心とした、社会的ニーズの高い専門職向けの人材サービスとデジタルソリューションを展開し、求職者と事業者をつなぐ重要な役割を担っています。また、近年では医療福祉現場の業務効率化や生産性向上を目的に、ソフトウェアやデジタルツールの提供、AI・DX 推進支援などを行っています。このような事業の成長とともに、サービスやプロダクトの企画・開発において、より一層「お客様体験」を起点とした価値創出が求められるようになりました。 本セッションを開催するにあたり、トライト様からは以下のような課題とご期待を頂戴しました。 顧客視点の価値の明確化への課題感 ：サービス設計において事業成果を優先しがちになり、顧客視点での価値の創出が十分に注力しきれていない課題。本セッションを通じ、お客様の本質的な課題から逆算して考えるプロセスを体験し、顧客中心の発想を組織に根付かせたいという強いご要望がありました。 多職種間のコミュニケーションと相互理解の促進 ：サービスに関わる多様な役割間でのコミュニケーションや相互理解が不足しているという課題。ワークショップを通じて、実際のサービスデザインさながらのチームビルディングを実現したいという期待が寄せられていました。 イノベーション創出と意思決定スピードの向上 ：変化の激しいビジネス環境において、新規サービスの企画や既存サービスの改善にスピード感やイノベーションが不足している課題。普段の業務を離れ、フラットな場で本質的に価値あるアイデアをスピーディーに議論・具体化する実践的な方法論を体験したい思いがありました。 体験版 Working Backwards セッションについて Amazonの「Working Backwards」とは、「お客様は誰ですか？」 から始まる5つの質問を通じて、本当に必要なサービスを企画・開発していく手法です。具体的には、最初にプレスリリース（以下 PR）を書くことで、これからつくるプロダクトやサービスを明確にします。この PR 文章と FAQ （よくある質問）を通じ、顧客起点のサービス価値について深く考えます。 今回実施した「体験版 Working Backwards セッション」は、お客様を中心とした創造的課題解決アプローチのエッセンスを簡易に体験いただくワークショップです。個人ワークを中心とした約2.5時間のマイクロ版と、個人ワーク・グループワークの両方を行う約4時間のミニ版セッションがありますが、今回は前述のチームビルディングの課題に取り組むため、グループワークを含むミニ版をご選択いただきました。 セッションは具体的には以下の流れで進行しました。 セッションテーマの設定。今回は事前に「インターネット上で、転職活動を行う特定業界の求職者様のストレスフリーな転職体験の向上」と合意 「お客様は誰か」「どんな課題をどう解決するか」を個人で考え、グループで議論しつつ定義 初期のアイデアを深掘りし、解決策を考え、それらを盛り込んだ PR 文案を作成 グループ間で PR 文をレビューし、アイデアを更に発展させるためのディスカッション このプロセスを通じて、参加者はお客様中心のサービスデザインや、課題から考える逆算思考を体感し、実際の業務への応用イメージを膨らませることができました。 体験版 Working Backwards セッションのワーク内容 実施効果と参加者の声 体験セッションを東京会場と大阪会場で各2回ずつ、計55名のトライト社員様にご参加いただきました。参加者の職種はビジネスエキスパート、CRM、デザイン、マーケティング、開発、企画など多岐にわたり、管理職の方も含まれました。また、東京第2回セッションでは、AWS のプレミアティアサービスパートナーである株式会社サーバーワークス様に開催のご協力をいただきましたこと、この場を借りて御礼申し上げます。 ワークショップ中議論の模様 全4回のワークショップ終了後のアンケート（1 ~ 5の5段階で満足度を評価）では、参加者の94.5%が「4」または「5」と高い満足度を示しました。以下にセッションご参加者様の声の一部をご紹介します。 「お客様に対する解像度を上げることがより良いサービスを作れることにつながる」ということを実感しました。4時間があっという間に経ちました（開発）  複数の職種のメンバーが介してサービスについて検討するという機会は多くないので、とても新鮮でしたし必要な事だと強く感じました（マーケティング）  ペルソナから課題、解決サービスまでをかなり作り込んだつもりでしたが、第三者の視点では指摘箇所が沢山あると気付きました。改めて顧客視点で考える大切さと、その密度の重要性を感じました（マーケティング） 業務では数日間煮詰めて考えるようなことを短時間でスピード感もって出来たので、プロトタイプ作成などで活かせそうです（開発） ご紹介した意見以外にも、顧客を中心とした課題から逆算することの意義や、多様なフィードバックを取り入れつつアジャイルにアイデアを改善するプロセスに関心を持ったといったお声を多数頂戴しました。 また、ワークの途中で生成 AI を取り入れたことにより、文章作成効率を向上して更に深い議論に発展できたことや、生成 AI の利用方法そのものを理解できたといった副次的なメリットも感じていただけました。 全4回のセッションを通じ、トライト事務局の通地 浩樹氏からは「弊社 UXD 本部開発部の部門重点目標である『組織横断的な協働による顧客への価値提供』の実現を目的とし、ワーキングバックワーズを実施いたしました。本取り組みではサービス全体を見据え、多様な役割の方々との協働による思考の機会を得ることができ、各部署からも好評を得る有意義なワークショップとなりました。ご参加・ご支援賜りました皆様に、心より御礼申し上げます。」とコメントを頂戴しています。 今後も AWS は、トライト様のビジネス成長とイノベーション推進に貢献できるよう、パートナー企業様と連携しながらご支援を続けてまいります。 本記事公開時点では、体験版Working Backwardsセッションは招待制のイベントとなります。AWS側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください。    

みなさん、こんにちは。製造業のお客様を中心に技術支援をしているソリューションアーキテクトの塚井です。 2025 年 6 月 25 日・26 日に開催された AWS Summit Japan にご来場いただいた皆さま、誠に有難うございました。 本ブログでは、当日会場にお越しいただけなかった方に向けて、AWS Village の Industry Zone 内にある製造ブース「産業データファブリック (IDF) 」でご紹介した内容をお届けします。 製造エリア全体の見どころを紹介した Blog は こちら で紹介されていますので、ご参照ください。 産業データの活用はなぜ難しいのか？ 産業データの活用が難しい理由はさまざまですが、私たちがお客様からよく伺う主な理由をご紹介します。例えば、データが各工場の機器ごとに分散しており、十分に共有されていないことがあります。また、アクセスできたとしてもデータの統合が困難であったり、分析を行うためのドメイン知識を持つデータサイエンティストが不足していたりする場合もあります。 産業データファブリック(IDF)の活用はなぜ難しいのか？ 産業データファブリック (IDF) のソリューションフレームワークは、各種デバイスやアプリケーション、製造システムからのデータの収集・保存・コンテキスト化・活用に関わる作業を軽減し、費用対効果の高いユースケース開発に集中できるよう支援します。こうしたフレームワークを活用することで、以下のような効果が期待できます。 散在するデータを集約し、価値を引き出すことができる 価値のあるユースケースの実現までの時間を短縮できる データへのアクセスが簡素化される セキュリティやガバナンスを標準化できる コンテキスト化については、後ほど具体例で紹介します。 産業データファブリック (IDF) の構造 基盤構築だけにフォーカスするのではなく、価値のあるユースケースから逆算して考えることが重要です。データの収集や統合はソリューションによって簡易化できますが、その活動に意味を持たせるのはユースケースの存在です。 そのため、最初のユースケースを開発する段階でスモールスタートができ、将来的な横展開にも対応できるアーキテクチャを選定することが大切です。このアーキテクチャを支えるのが、AWS やパートナーのソリューションと活用しやすいデータフォーマットです。パートナーでは、日立製作所が国内で初めて IDF のパートナーに認定されました。 産業データのコンテキスト化の構造例 産業データ活用の進め方 最後に進め方についてですが、まず ROI (投資対効果) の高いユースケースを選定し、初期段階ではデータの収集と統合から着手します。 その後、段階的にライン単位から工場全体、さらに組織全体へと展開していきます。 デモ内容のご紹介 こうした IDF のコンセプトやどのような価値をもたらすのかをイメージしていただくために、デモを展示しました。 ① 工場生産ラインの可視化 e-Bike の生産ラインをイメージとした仮装工場からデータを生成して、IDF のフレームワークに沿ってデータを収集〜保存〜コンテキスト化〜活用しています。 データソースとしては、注文を管理する ERP、実行する MES、生産設備の各機材を実現しています。 ② Amazon QuickSight で製造データを分析 製造のデータを分析しやすい標準的なフォーマットに加工して、 Amazon Q in QuickSight によってチャットから自然言語で分析を行うことにより、Amazon Q in QuickSight によってチャットから自然言語で分析を行うことにより、データ活用を加速します。 ③ Amazon DataZone でデータを共有 生データ、または加工されたデータをカタログとして Amazon DataZone で共有できます。他部門がそのデータに SUBSCRIBE することで、簡単に分析や ML の開発に活用できます。 まとめ 最後にここまで紹介した内容をまとめます。 産業データファブリック (IDF) は製造業のお客様のデータ活用を促進するためのフレームワークです。 データ活用はスモールスタートで始めますが、最終系を描いておく必要があります。 最初のユースケースが大事で、ROI を考慮した選定が必要です。 IDF は AWS のサービスやパートナーソリューションを組み合わせてお客様の要件を実現します。 会期中は、両日合わせて本ブースに多くのお客様にお越しいただきました。ご来場頂いたお客様からは、製造データの活用に取り組む中でさまざまな課題を抱えていることを実感しました。 産業データファブリック (IDF) が、そうした課題解決の一助となれば幸いです。 著者紹介 塚井 知之 (Tomoyuki Tsukai) アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 外資系のハードウェアベンダー、ソフトウェアベンダーを経て、2019 年に AWS Japan に入社。現在はエンタープライズ技術本部でソリュー ションアーキテクトとして活動中。製造業のお客様を担当し、AWS に纏わるさまざまな技術支援を行っています。趣味は車中泊と DIY です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 ところで、AWS Builders Online というイベントがまもなく開催されるのですが、参加されたことはありますでしょうか。最新の生成 AI サービスから実践的なデータ分析手法まで、ビジネスですぐに活用できる知識を得られるところや、実務で直面する課題に対する具体的な解決策を学べるようになっており、初学者の方にはおすすめのイベントとなっています。イベント登録は こちら から可能となっています。オンラインで参加可能ですので、熱い夏は自宅で AWS 学習に時間を費やしてみるのもよいかもしれませんね。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年7月21日週の主要なアップデート   7/21(月) Amazon Braket が IQM の新しい 54 量子ビット量子プロセッサを追加 Amazon Braket で IQM の新しい 54 量子ビット量子プロセッサ「Emerald」が利用可能になりました。Emerald は超伝導技術を使った最新の量子コンピューティングデバイスで、従来より高い精度で量子アルゴリズムの研究・実験が可能です。Braket SDK や Qiskit などの人気フレームワークで量子プログラムを構築でき、量子機械学習や最適化問題の解決に活用できます。ストックホルムリージョンから利用でき、研究機関向けには AWS クレジットプログラムも提供されています。詳細は こちらの Blog 記事をご参照ください。 Amazon Connect が外部音声コネクタの日単位料金を発表 Amazon Connect の外部音声コネクタが 1 日 100 ドルの日次課金になりました。従来は、1コネクタあたり月額 3,100 ドルだったところが、細かい単位での課金が可能になり、コスト管理がしやすくなります。このコネクタには 2 種類あり、転送コネクタは既存の音声システムと Amazon Connect を連携させ、分析コネクタは他システムの音声データを Contact Lens で分析できます。既存のコールセンターシステムを活用しながら Amazon Connect の AI 機能を利用したい企業にとって便利な機能です。詳細は こちらのドキュメントをご参照ください。 Amazon SQS がマルチテナントワークロード向けのフェアキューを導入 Amazon SQS で fair queues (フェアキュー) 機能が提供開始されました。従来、マルチテナント環境で一つのテナントが大量メッセージを送信すると他のテナントの処理が遅延する問題がありましたが、この機能により各テナントの処理時間を公平に保てます。メッセージ送信時にメッセージグループ ID を指定するだけで利用でき、既存システムへの影響なく導入可能です。SaaS アプリや複数リソースのイベント処理に特に有効で、全商用リージョンで利用できます。詳細は こちらの Blog 記事をご参照ください。 7/22(火) Amazon MQ が RabbitMQ 向けに Graviton3 ベースの M7g インスタンスをサポート開始 Amazon MQ の RabbitMQ で新しい Graviton3 ベースの M7g インスタンスが利用可能になりました。従来の M5 インスタンスと比較して最大 50% のワークロード容量向上と最大 85% のスループット改善を実現します。M7g.medium から M7g.16xlarge まで幅広いサイズを選択でき、評価用途から本格的な本番環境まで対応可能です。また既存の M5 ブローカーからのインプレースアップグレードにも対応しており、ダウンタイムを最小限に抑えて性能向上を図れる点が魅力です。詳細は こちらのドキュメントをご参照ください。 AWS Audit Manager がコンプライアンスインサイト向上のためエビデンス収集を強化 AWS Audit Manager が 14 の標準フレームワークを更新し、エビデンス収集機能を強化しました。SOC 2 や PCI DSS v4.0 などの主要フレームワークでエビデンスの関連性が向上し、コンプライアンス検証がより効率的になります。多くの顧客で検出結果の数が最適化され、関連コストの削減も期待できます。6 月 6 日以降に作成したアセスメントは自動的に更新版が適用されますが、それ以前のものは新規作成が必要です。詳細は こちらのドキュメントをご参照ください。 Amazon Timestream for InfluxDB が 24xlarge メモリ最適化インスタンスをサポート開始 Amazon Timestream for InfluxDB で 24xlarge メモリ最適化インスタンスが利用可能になりました。96 vCPU、768 GiB のメモリ、最大 40 Gbps のネットワーク帯域幅を提供し、大規模な時系列データベースワークロードに対応できます。産業用テレメトリー、IoT 分析、金融取引プラットフォームなど、高速な応答時間が求められる用途に最適です。東京リージョンを含む複数のリージョンで利用でき、コンソール、CLI、SDK、CloudFormation から簡単にプロビジョニングできます。 7/23(水) Amazon RDS for PostgreSQL と Amazon Redshift のゼロ ETL 統合が一般提供開始 Amazon RDS for PostgreSQL と Amazon Redshift の zero-ETL 統合が一般提供開始されました。従来は複雑なデータパイプラインを構築する必要がありましたが、この機能により PostgreSQL のデータがほぼリアルタイムで Redshift に自動レプリケーションされ、すぐに分析できるようになります。複数の統合作成やデータフィルタリング、CloudFormation での自動化も可能で、データ分析の効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for Oracle と Amazon Redshift のゼロ ETL 統合 Amazon RDS for Oracle と Amazon Redshift の zero-ETL 統合機能が提供開始されました。従来は複雑な ETL パイプラインを構築する必要がありましたが、この機能により Oracle データベースに書き込まれたデータが数秒で Redshift に自動レプリケーションされます。これにより、ペタバイト規模のトランザクションデータをリアルタイムに近い形で分析や機械学習に活用できるようになります。特定のテーブルやデータベースを選択してレプリケーションでき、Oracle Database 19c で利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS IoT SiteWise Query API が高度な SQL サポートと ODBC ドライバを追加 AWS IoT SiteWise Query API が大幅に強化され、高度な SQL 機能と ODBC ドライバーが追加されました。これまで複雑だった工業データの分析が簡単になり、文字列操作や集約関数、日時計算などの高度な SQL 操作が可能です。さらに ODBC ドライバーにより Tableau や Power BI、Excel との直接連携も実現し、カスタム開発なしでデータ可視化やレポート作成ができます。東京リージョンを含む 9 つのリージョンで利用可能で、工業データから迅速にビジネス洞察を得られるようになりました。詳細は こちらのドキュメントをご参照ください。 7/24(木) Amazon CloudWatch が IPv6 サポートを追加 Amazon CloudWatch が IPv6 サポートを開始しました。これまで IPv4 のみだったメトリクス取得やアラーム、ダッシュボード機能が IPv6 でも利用可能になります。IPv4 と IPv6 両方に対応するデュアルスタック環境で CloudWatch を運用でき、アドレス枯渇の心配がなく、IPv6 ネイティブなアプリケーションのモニタリングが簡単になります。詳細は こちらのドキュメントをご参照ください。 AWS Glue が Microsoft Dynamics 365 をデータソースとしてサポート開始 AWS Glue で Microsoft Dynamics 365 のネイティブコネクターが利用可能になりました。これまで複雑だった ERP や CRM システムからのデータ抽出が簡単になり、ETL ジョブの構築時間を大幅に短縮できます。企業の販売データや顧客情報を AWS のデータ分析基盤に効率的に統合でき、より包括的なビジネス分析が可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon ElastiCache での Bloom フィルターサポートの発表 Amazon ElastiCache で Bloom filter が利用可能になりました。これまでキャッシュ内のアイテム存在確認には Set データ型を使用していましたが、Bloom filter を使うことで 98% 以上のメモリ効率化を実現できます。確率的データ構造により高速な存在チェックが可能で、大量データの重複判定やキャッシュ効率向上に効果的です。全リージョンで追加コストなしで利用できます。詳細は こちらのドキュメントをご参照ください。 7/25(金) AWS HealthOmics がワークフロー作成のためのサードパーティ Git リポジトリサポートを導入 AWS HealthOmics で Git リポジトリ連携機能が追加されました。GitHub、GitLab、Bitbucket からワークフロー定義を直接取得でき、従来必要だった手動ステージングが不要になります。バージョン管理と再現性が向上し、既存の開発プロセスを維持しながら効率的に活用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Connect が メッセージテンプレート添付ファイル向けの AWS CloudFormation をサポート開始 Amazon Connect の Outbound Campaign で利用するメッセージテンプレートの添付ファイル (画像やドキュメント) が AWS CloudFormation で管理できるようになりました。これまで手動で作成・管理していた添付ファイルを、コードで自動化して複数環境 (本番・テスト・ステージング) に一貫してデプロイできます。メール配信キャンペーンでの画像添付などがより効率的になり、インフラ管理の負担軽減とヒューマンエラー削減が期待できます。詳細は こちらのドキュメントをご参照ください。 Amazon Connect が予測編集 UI を開始 Amazon Connect で予測編集 UI が新登場し、コールセンターのプランナーが予測調整を簡単に行えるようになりました。従来は複雑だった予測値の変更が、新しい UI で直感的に操作可能になります。マーケティングキャンペーン期間中に火曜・水曜の 12 時から 14 時の予測を 15% 増加させるなど、具体的な日時・キュー・チャネルを指定した調整ができます。需要変動への迅速な対応と計画精度の向上を実現し、エージェントスケジューリング機能が利用可能な全リージョンで提供開始されました。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

双方向コミュニケーションは強固な関係構築の礎となります。リアクティブなカスタマーサポートもあらゆる種類の組織にとって重要ですが、プロアクティブな顧客へのアプローチによってカスタマーエクスペリエンスをさらに向上させることができます。しかし、組織は適切なメッセージを、適切な人に、適切なタイミングで送信する必要があります。 Amazon Connect のイノベーション により、組織は個々の顧客ニーズに合わせたターゲット型コミュニケーションを開始できます。 Amazon Connect Customer Profiles からのデータを活用することで、企業は今や顧客、オーディエンスをセグメント化し、 Amazon Connect Outbound Campaigns によりパーソナライズされたメッセージを作成して、事前に顧客とコミュニケーションを取り、信頼とロイヤルティを育み、大切な顧客との永続的な絆を築くことができます。 プロアクティブなコミュニケーションにおける従来の課題 今日、効果的なプロアクティブコミュニケーション戦略の実装を目指す企業は、数多くの課題に直面しています。組織は多くの場合、複数のシステムからのデータを組み合わせてターゲットとなる顧客セグメントを作成し、そのプロセスは IT や保守運用チームに依存しています。このプロセスは時間がかかるだけでなく、古いデータを生成する可能性があり、アウトバウンドコミュニケーションのルールやキャンペーンを頻繁に変更する必要を生じさせます。運用のスケーリングは困難になり、最新の顧客情報へのアクセスも限られているため、パーソナライゼーションの質が損なわれます。 Amazon Connect による動的でパーソナライズされた顧客エンゲージメント Amazon Connect を使えば、企業は、プロアクティブなパーソナライズされたコミュニケーションの提供、そして売上成長の促進やカスタマーサービスへの問い合わせを未然に防ぐことができます。組織は、 Amazon Connect Customer Profiles で、生成 AI を活用して、さまざまなデータソースから顧客データを簡単に集約、統合された顧客レコードを作成できます。70 種類以上のデータソースから顧客データをリアルタイムにプロファイルに組み合わせることもできます。 Amazon Connect Outbound Campaigns の機能と組み合わせ、組織は Amazon Connect Customer Profiles の属性をアウトバウンドキャンペーンのセグメントで使用でき、これらは動的に最新の状態に保たれます。 顧客セグメント、チャネル、スケジュールを定義すれば、Amazon Connect の管理コンソールから直接、チャネルをまたいだキャンペーンをすばやく作成および起動できます。これにはメッセージングのテンプレート管理が含まれます。セグメンテーションに使用されるのと同じ動的属性を使用して、 アウトバウンドキャンペーン のメッセージ自体をパーソナライズすることもでき、 Amazon Connect Customer Profiles は、組織全体の顧客ライフサイクルを支援する最新の顧客情報の拡張可能な情報源となります。 さらに、企業は継続的に顧客データと洞察を確認し、改善したいと考えているでしょう。 Amazon Connect Outbound Campaigns は、キャンペーンのパフォーマンスをリアルタイムで表示します。これには、キャンペーンの配信状況、応答率、または通話の結果（例：本人応答、留守番電話、話中・ビジー、目的完了）が含まれます。以前は、顧客はエンドツーエンドのパフォーマンスメトリクスを取得するために、データを組み合わせてカスタムダッシュボードを構築するための技術リソースが必要でした。現在は、これらのメトリクスを 1 か所で利用可能です。 様々なユースケースでの活用 これらの機能により、ビジネスユーザーは技術的な担当者に依存したり、複数のツール間でカスタム統合を構築・設定することなく、コミュニケーションを調整できるようになります。これらの機能はすべて Amazon Connect の Web コンソール内で利用でき、組織がターゲットを絞ったタイムリーなアウトバウンドコミュニケーションを提供するのに役立ちます。 サービスの予約確認、支払いの督促、またはカスタマージャーニーにおけるタッチポイントなどのユースケースで Amazon Connect は組織が一貫したコミュニケーションを維持し、価値ある関係を育成することを支援します。組織は今や、スケールできるパーソナライズされたオムニチャネルキャンペーンを簡単に作成できます。このようなコミュニケーションにより、特別オファーの案内やかご落ち・カート離脱のリマインドなど、マーケティング機会にも発展させることができます。 Amazon Connect Outbound Campaigns の料金は、アウトバウンドコミュニケーションの数と使用されるチャネルに基づいています。Customer Profiles と Outbound Campaigns を使用することで、企業は適切なタイミングで顧客にエンゲージし、プロアクティブでパーソナライズされたアウトリーチを通じて、より深く意味のある関係を育むことができます。 Amazon Connect でのプロアクティブコミュニケーションに関する技術ブログ で、開始方法について詳しく学びましょう。 Amazon Connect Outbound Campaigns と Customer Profiles を使用して、適切なタイミングで複数のチャネルを通じて適切な顧客と動的にエンゲージしましょう。詳細については、 お問い合わせ ください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 先日は AWS Summit New York 2025 で 多くの AI エージェント関連サービスやプログラムが発表 されましたね。お客様から期待の声を多くいただいたのと同時に、私自身も非常にワクワクしました。 7/30（水）に 「 Amazon Q CLI でゲームを作ろうキャンペーンの報告と最新情報 update & Kiro のご紹介 」というイベントが予定されています。AI エージェントの最新情報が聞けるイベントとなってますのでご興味のある方はぜひご参加ください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、7 月 21 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。ニュースが中心の週となっています。 さまざまなニュース AWS Summit New York関連のニュース ブログ記事「AWS、AWS Summit New York 2025 にて AI エージェント構築に向けた新たなイノベーションを発表」を公開 AWS Summit New York 2025 にて AI エージェント関連の新しいサービスやプログラムがいくつか発表されました。本ブログでは、Amazon Bedrock AgentCore、AWS Marketplace の新カテゴリー、生成AIイノベーションセンターへの追加投資、Amazon Nova の新しいカスタマイズ機能など、Summit で発表された代表的な内容をまとめて紹介しています。 ブログ記事「Amazon Bedrock AgentCore のご紹介: AI エージェントをあらゆる規模で安全にデプロイおよび運用する (プレビュー)」を公開 Amazon Bedrock AgentCore（プレビュー）が発表されました。Amazon Bedrock AgentCore は、AI エージェントをあらゆる規模で安全にデプロイおよび運用するためのプラットフォームです。本ブログでは、AgentCore Runtime、Memory、Observability、Identity、Gateway、Browser、Code Interpreter の7つのコンポーネントの詳細と、Strands Agents を使用したカスタマーサポートアシスタントの実装例を解説しています。各機能の理解に向けては AgentCore サンプル GitHub リポジトリ  での体験がおすすめです！ ブログ記事「Amazon SageMaker AI での Amazon Nova のカスタマイズの発表」を公開 Amazon SageMaker AI で Amazon Nova のカスタマイズ機能が発表されました。Amazon Nova Micro、Nova Lite、Nova Pro を継続事前学習、教師ありファインチューニング、アライメントなどの手法を使ってカスタマイズできます。本ブログでは、各カスタマイズ手法の概要や、 Amazon SageMaker Studio 上で直接選好最適化を用いて Nova Micro モデルをカスタマイズする例について説明しています。 ブログ記事「TwelveLabs の動画理解モデルが Amazon Bedrock で利用可能に」を公開 TwelveLabs の動画理解モデル Marengo（動画埋め込みモデル）と Pegasus（動画言語モデル）が Amazon Bedrock で利用可能になりました。「試合の最初のタッチダウンを見せて」のような自然言語による動画検索や、タイトル、要約、章、ハイライトなどの説明テキスト生成が可能になります。本ブログでは、これらのモデルの機能とAmazon Bedrock での TwelveLabs モデルの開始方法ついて紹介しています。 ブログ記事「AWS AI League: 新しい究極の AI 対決で学習し、イノベーションを起こし、競い合う」を公開 AWS AI League という競い合いながら学ぶ、新しい生成 AI 学習プログラムが開始されました。組織がプライベートトーナメントを開催し、チームが協力して実際のビジネス課題を解決する AI ソリューションを構築します。本ブログでは、プログラムの構成や申し込み方法について説明しています。 ブログ記事「Amazon S3 Vectors と Amazon OpenSearch Service によるベクトル検索の最適化」を公開 本ブログでは、Amazon S3 Vectors と Amazon OpenSearch Service の統合機能（プレビュー）について解説しています。大規模なベクトル埋め込みを保存・検索する際のレイテンシー、コスト、精度のトレードオフという課題を解決するために、頻繁にクエリされないベクトルをS3 Vectorsに保持し、ハイブリッド検索や集計などの高度な検索機能にはOpenSearchを使用する最適化手法について説明しています。既存のベクトル検索システムの最適化を検討している方は是非ご覧ください。 その他のニュース ブログ記事「AWS Price List が自然言語でアップグレードされました：AWS Pricing MCP サーバーの紹介」を公開 AWS Price List が自然言語でアップグレードされ、AWS Pricing MCP サーバーがオープンソースツールとしてリリースされました。Model Context Protocol（MCP）を通じて、「us-west-2 で 3 つの m5.large インスタンスを実行するコストは？」のような自然言語による料金問い合わせが可能になりました。本ブログでは、240 を超える AWS サービスの複雑な料金情報を AI アシスタントとの会話で簡単に取得できる方法について説明しています。 ブログ記事「AWS Transform での Export for vCenter の使用」を公開 Export for vCenter という新しい AWS オープンソース Python プロジェクトが発表されました。AWS Transform for VMware で利用するために vCenter からインベントリデータをエクスポートするツールです。RVTools の代替手段として開発され、AWS Transform が必要とするデータのみを取得します。本ブログでは、セットアップ手順と実行手順ついて解説しています。 ブログ記事「AWS Serverless MCP Server の紹介：AI を活用してモダンアプリケーションを開発する」を公開 AWS Serverless MCP Server は、サーバーレス開発に特化したコンテキストガイダンスを提供し、開発者がアーキテクチャ、実装、デプロイに関する情報に基づいた決定を行えるよう支援するソリューションです。本ブログでは、Serverless MCP Server の概要と設定方法、サーバーレスアプリケーションの作成をテーマにした実際の動作イメージについて説明しています。 ブログ記事「JWT を使用した Amazon Bedrock と Amazon OpenSearch Service による SaaS 向けマルチテナント RAG 実装」を公開 本ブログでは、JWT と Fine-Grained Access Control（FGAC）を使用した Amazon Bedrock と Amazon OpenSearch Service による SaaS 向けマルチテナント RAG の実装方法について解説しています。厳密なテナントデータアクセス分離が必要なケースにおいては、ぜひ本文にあるアーキテクチャを参考にしてみてください。 ブログ記事「AWS Summit Japan 2025 で次世代のフードマネジメントに挑戦！ AI と IoT で実現する スマート廃棄物管理」を公開 本ブログでは、AWS Summit Japan 2025 の Builders Fair で展示された、AI と IoT を活用したスマート廃棄物管理システムについて報告しています。ゴミ箱に何がどれくらい廃棄されたのかを可視化する展示内容となっており、展示期間中の約 9 時間で 162件、149kgの廃棄物を処理し、認識精度88.4%を達成しました。Amazon Bedrock、AWS IoT Core、Amazon Timestream for LiveAnalytics などを使ったアーキテクチャが記載されています。 ブログ記事「AWS Cloud Quest に無料でプレイ可能な「生成 AI プラクティショナー」ロール追加 ＆ 全ロールが日本語化されました」を公開 AWS Cloud Quest に「生成 AI プラクティショナー」ロールが追加され、全ロールが日本語化されました。既存の「Cloud Practitioner」ロールに加えて合計20チャレンジ分の実際のAWSアカウントを使用した演習環境が無料で利用できるようになりました。ぜひ「 AWS Skill Builder 」に登録しお試しください。 ブログ記事「【開催報告】Neuron Community – Vol.2」を公開 本ブログでは、2025 年 7 月 15 日に開催された「Neuron Community – Vol.2」の様子をレポートしています。オープニングでは Discord上のNeuron Community の成長について、ライトニングトークでは国立情報学研究所様による「LLM-jp Chatbot Arena」での Amazon EC2 Trn1 インスタンス活用事例について発表された様子が紹介されています。 サービスアップデート Amazon EC2 P6-B200 インスタンスが米国東部 (バージニア北部) で利用可能になりました Amazon EC2 で新しい P6-B200 インスタンスが米国東部 (バージニア北部) リージョンで利用開始されました。NVIDIA Blackwell GPU を 8 基搭載し、従来の P5en インスタンスと比較して最大 2 倍の性能を実現します。AI モデルの学習や推論処理において、より高速で効率的な処理が可能になり、大規模な機械学習プロジェクトでの計算時間の短縮が期待できます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

7 月 21 日、ホーチミン市からシンガポールに戻る途中に記事を書いています。すばらしい一週間だったと思っていたところなので、少し振り返ってみたいと思います。7 月 21 日週、私は初めて Corne キーボードを試し、水準を確実に引き上げている講演者たちと一緒に AWS Summit Jakarta のリハーサルを終えてから、ベトナムに移動して AWS Community Day Vietnam にテクニカル基調講演の講演者として参加しました。このエネルギッシュな会合では、複数のテクニカルトラックとネットワーキングセッションを通じて、何百人ものクラウドプラクティショナーと AWS 愛好家が知識を共有しました。 私が行ったのは、「Reinvent perspective as modern developers」というタイトルの基調講演で、 サーバーレス や コンテナ の他、 Amazon Q Developer と Kiro を使用して知識習得時間を短縮し、生産性を高める方法についてお話ししました。数人の AWS コミュニティビルダーやコミュニティ開発者と話し合う機会もあり、Amazon Q Developer を実際に使用してアプリケーション構築の課題にどのように対処したのかを共有してくれました。クラウド開発ジャーニーにおける大幅な生産性向上と知識習得の円滑化を強調した人も幾人かいました。 シンガポールに戻るにあたり、私はおいしい cà phê sữa đá (アイスミルクコーヒー) の思い出だけでなく、この活気に満ちたクラウドイノベーターのコミュニティから得た新鮮な視点やインスピレーションも持ち返っています。 Kiro の紹介 先週のハイライトの 1 つは、何と言っても Kiro です。Kiro は、AI エージェントと連携するための簡素化された開発者エクスペリエンスを通じて、コンセプトから本番環境の実現を支援する AI IDE です。Kiro は、適切な計画と明瞭性を用いてプロトタイプを本番環境システムに移行させるために役立つ spec (スペック) や hook (フック) といった機能で「バイブコーディング」のさらに先を進みます。 ウェイティングリストに登録 して、提供開始時に通知を受け取りましょう。 7 月 14 日週の AWS リリース その他のニュースには、ニューヨークで開催された AWS Summit があり、ここでいくつかのサービスがリリースされました。こちらは、私が注目したいくつかのリリースです。 AWS Lambda のコンソールと IDE の統合機能やリモートデバッグ機能でサーバーレス開発を簡素化 – AWS Lambda で、ブラウザから Visual Studio Code への開発者ワークフローを合理化する、コンソールと IDE の統合機能とリモートデバッグ機能の提供が開始されました。これらの機能強化により、時間のかかるコンテキストの切り替えが不要になるとともに、開発者が好みの IDE 環境で Lambda 関数を直接デバッグできるようになります。 Amazon ECS の新しい組み込みブルー/グリーンデプロイで安全なソフトウェアリリースを迅速化 – Amazon ECS で、コンテナ化されたアプリケーションデプロイの安全性と一貫性を向上させる、組み込みブルー/グリーンデプロイの提供が開始されました。この機能により、カスタムデプロイツールを構築する必要がなくなると同時に、ロールバック機能やデプロイライフサイクルフックを使用することで、自信を持ってソフトウェアアップデートをリリースできます。 Amazon Bedrock AgentCore の紹介: AI エージェントをあらゆる規模でセキュアにデプロイして運用 – Amazon Bedrock AgentCore は包括的な一連のエンタープライズグレードサービスで、開発者が任意のフレームワークとモデルを使用して AI エージェントの大規模なデプロイをすばやく安全に行えるようにします。AgentCore Runtime、Memory、Observability、Identity、Gateway、Browser、および Code Interpreter の各サービスが含まれており、これらが連携してインフラストラクチャの複雑性を解消します。 AWS 無料利用枠の更新: 新規のお客様は最大 200 USD のクレジットで AWS の使用を開始し、検証できます – AWS 無料利用枠で、新規のお客様に最大 200 USD の AWS クレジットを付与する強化特典が提供されるようになりました。サインアップ時に 100 USD を受け取り、EC2、RDS、Lambda、Bedrock、AWS Budgets を使ったアクティビティを完了すると、さらに 100 USD を獲得できるため、コストを発生させずに AWS サービスを簡単に検証できるようになります。 Amazon EventBridge の新しいログ記録でイベントドリブンのアプリケーションを監視してデバッグ – Amazon EventBridge で、強化されたログ記録機能の提供が開始されました。この機能は、成功、失敗、ステータスコードに関する詳細情報を伴う包括的なイベントライフサイクル追跡を実現します。この新しいオブザーバビリティ機能は、イベントジャーニーの全体を可視化することで、マイクロサービスとイベントドリブンアーキテクチャの監視における課題に対処します。 Amazon S3 Vectors の紹介: 大規模なネイティブベクトルサポートを備えた初のクラウドストレージ – Amazon S3 Vectors は、耐久性を備えた専用ベクトルストレージソリューションで、ベクトルのアップロード、保存、クエリにかかるコストの総額を最大 90% 削減できます。Amazon S3 Vectors は、大規模なベクトルデータセットを保存し、AI アプリケーションに 1 秒未満のクエリパフォーマンスを提供するためのネイティブサポートを備えた初のクラウドオブジェクトストアです。 Amazon EKS が、クラスターあたり 10 万個のノードをサポートする超大規模な AI/ML ワークロードを実現 – Amazon EKS が、単一のクラスター内で最大 10 万個のワーカーノードをサポートするようになりました。このため、お客様は最大 160 万個の AWS Trainium アクセラレーターまたは 80 万個の NVIDIA GPU にスケールアップできます。この業界トップクラスのスケール機能により、お客様は Kubernetes 適合性と使い慣れた開発者エクスペリエンスを維持しながら、1 兆パラメータモデルをトレーニングし、AGI 開発を進展させることができます。 AWS Builder Center より もしまだご存知なければ、AWS は先日 AWS Builder Center と統合された community.aws をローンチしました。こちらは、私のおすすめ記事です。 How I Optimized My AWS Bill by Deleting My Account (Corey Quinn 著) – AWS コスト最適化戦略と、請求金額を削減するために検討することもあり得る強硬手段に関する、ユーモアとインサイトにあふれた見解です。 How to setup MCP with UV in Python the right way (Du’An Lightfoot 著) – 最適な開発ワークフローのために、Python で UV パッケージマネージャーを使用して Model Context Protocol (MCP) をセットアップする実践ガイドです。 Extending My Blog with Translations by Amazon Nova (Jimmy Dahlqvist 著) – ブログ記事に翻訳機能を追加する Amazon Nova の機能を利用して、世界中の読者にリーチする方法を学びましょう。 How I used Amazon Q CLI to fix Amazon Q CLI error “Amazon Q is having trouble responding right now” (Matias Kreder 著) – Amazon Q CLI を使用して Amazon Q 独自のエラーを解決する方法を実証する実践的なトラブルシューティングガイドで、AI 支援のデバッグの力を明らかにします。 近日開催される AWS イベント カレンダーを確認して、今後の AWS や AWS コミュニティのイベントにサインアップしましょう。 AWS re:Invent – 今すぐ登録して、一足先に最適な学習パスを選択し、移動手段と宿泊先を予約して、皆さんのチームとともに学び、つながり、楽しみましょう。若手のプロフェッショナルならば、 All Builders Welcome Grant プログラム に申し込むこともできます。このプログラムは、経済的な障壁を取り除き、クラウドテクノロジーへの多様な道のりを創り出すように設計されています。 AWS Builders Online Series – 太平洋時間帯の地域を拠点としているならば、AWS でワークロードを構築、移行、デプロイするために役立つ基本的な AWS 概念やアーキテクチャ上のベストプラクティスを学び、実践的なデモに参加することができます。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。台北 (7 月 29 日)、 メキシコシティ (8 月 6 日)、 ジャカルタ (6 月 26～27 日) など、最寄りの都市で開催されるイベントにご登録ください。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 シンガポール (8 月 2 日)、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18日) です。 今後開催されるすべての AWS 主導の対面イベント と 開発者向けの仮想イベント をご覧いただけます。 7 月 21 日週のニュースは以上です。7 月 28 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Donnie この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ビルダー ID に参加: builder.aws.com で AWS Builder ジャーニーを始めましょう 原文は こちら です。

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 が計算要件の限界を押し上げ続ける中、私たちは前例のない信頼性、パフォーマンス、規模で次世代のアクセラレーテッドワークロードをサポートする準備ができています。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。