本記事は米国時間 8 月 13 日に公開された「 Unlock your development productivity with Kiro and Model Context Protocol (MCP) 」の日本語抄訳版です。Kiro の最新情報は、https://kiro.dev/ をご覧ください。 Kiro はその組み込み機能によって、私にとって個人的な開発加速装置となってきました。ファイルの読み書きや Bash スクリプトを実行するツールを使うことで、Kiro は 仕様駆動開発（spec-driven development） 、オートパイロット、 エージェントフック といった機能を通じてアイデアを現実に変えます。しかし、開発チームの一員として作業していると、組み込みのツールだけでは十分でない場面があります。そこで Kiro を次のレベルに引き上げるのが Model Context Protocol（MCP） です。開発チームで作業する際には、次のような追加的なやり取りやデータアクセスが必要になることがよくあります。 社内ナレッジベース統合 — 会社のドキュメント、Wiki、ナレッジリポジトリへの接続 カスタム API アクセス — 内部サービスや組織固有 API とのやり取り プロジェクト管理ツール — Jira、Asana、GitLab などとの統合によるチケット・タスクの文脈提供 データベースアクセス — IDE 内でのデータベースクエリや分析 CI/CD パイプライン統合 — GitLab、GitHub Actions、Jenkins などとの接続によるビルド・デプロイ状況取得 コード品質ツール — SonarQube、Code Climate などへのリンクによるコード品質の洞察 監視システム — Prometheus、Grafana などからのメトリクスやログへのアクセス インフラ管理 — IaC ツールやクラウドリソースとのやり取り Model Context Protocol (MCP) の登場 MCP は Anthropic が提供する画期的なオープンソースプロトコルで、重要な課題を解決します。それは「AI モデルにツールやデータへの安全で一貫したアクセスを与える」ことです。MCP は、Kiro があらゆる開発ツールやサービスとシームレスに通信できるようにする「ユニバーサル翻訳機」と考えることができます。 Kiro + MCP を使い始める Kiro には MCP クライアントが組み込まれており、外部データソースやツールと安全かつ柔軟に通信する機能を拡張できます。 Kiro 内で MCP サーバーを有効化するには以下の手順が必要です。 ローカルマシンに MCP サーバーをセットアップする Kiro 内に MCP サーバーを追加・設定する Kiro のチャットセッション内で MCP サーバーツールを使い始める Kiro は MCP サーバーと標準入出力（stdio）を通じ、シンプルな JSON ベースのリクエスト／レスポンスパターンで通信します。 Kiro の MCP クライアントアーキテクチャ MCP サーバーは Kiro と同じローカルマシン上で動作しますが、PostgreSQL データベースのようなローカルシステムや GitLab のようなリモートサービスとも通信できます。 Kiro における MCP サーバーの利用有効化 MCP サーバーは Kiro 内で 2 つのレベルで設定できます。 ワークスペース — 現在のプロジェクト／ワークスペース固有、.kiro/settings/mcp.json に保存 ユーザー — 全プロジェクト／ワークスペースに適用、ホームディレクトリ（~/.kiro/settings/mcp.json）に保存 ユーザースコープの MCP サーバーを設定する手順は以下のとおりです。 アクティビティバーから Kiro を選択 MCP SERVERS を展開 Workspace または User Config を開く MCP Server のセットアップ GitLab の計画機能を Kiro に持ち込む 開発チームは、共同作業や計画、ソフトウェア管理のために集中型のツールをよく使います。たとえば GitLab は、計画・開発・デリバリーを一体化したオールインワンのツールです。私の開発ワークフローでは、GitLab をコードやビルド管理だけでなく、機能やバグといったタスクの計画にも使っています。 GitLab Issues は製品の機能とバグを表示 例えば、次のような機能を考えてみます。 機能：Products API のコンテナ化 コンテキストスイッチをせずに、Kiro に GitLab の課題を読み込ませて実装してみましょう。 GitLab MCP サーバーの設定 このブログ記事では、オープンソースの GitLab MCP サーバー （ https://gitlab.com/fforster/gitlab-mcp ）を使います。README に設定方法が記載されており、私はソースからバイナリをビルドしました。 GitLab プロフィールから パーソナルアクセストークン を発行した後、Kiro MCP サーバーのユーザー設定に記述します。 { "mcpServers": { "GitLab": { "command": "../gitlab-mcp", "env": { "GITLAB_TOKEN": "gitlab_access_token", "GITLAB_URL": "gitlab_url" } } } } Kiro のユーザー設定は .kiro/settings/mcp.json にあります。 設定が正しければ、Kiro は MCP サーバーから提供される新しいツールを返してきます。 gitlab-mcp server によって提供されるツール ここでは、例えば get_issue や list_project_issues などの便利なツールがいくつかあります。これらの使い方を見ていきましょう。 GitLab イシューと Kiro の仕様駆動開発を同期 GitLab に列挙された課題を実装するために、Kiro のエージェントによる仕様駆動開発を活用したいと考えています。GitLab MCP サーバーが設定できたので、「製品に関連するすべての課題について要件ドキュメントを作成してほしい」と自然言語で説明できます。 Kiro チャットウィンドウで「 Spec 」を選択すると、GitLab イシューを構造的に実装することができます。次のステップは、Kiro に GitLab イシューの仕様を作成するよう指示することです。 gitlab プロジェクト WWSO-Q-DEV-SA/products-api のすべてのイシューに対する仕様を作成する GitLab の issue を Kiro の仕様に同期するための単一のリクエスト list_project_issues のような新しいツールを初めて使う際は、Kiro は実行前に承認を求めてきます。 list_project_issues ツールを使用してプロジェクトの問題を特定 なお、MCP 設定内の autoApprove 設定を使用して、Kiro がユーザーにプロンプトを表示せずにツール実行リクエストを自動的に承認するかどうかを制御することもできます。 { "mcpServers": { "GitLab": { "command": "../gitlab-mcp", "env": { "GITLAB_TOKEN": "gitlab_access_token", "GITLAB_URL": "gitlab_url" }, "autoApprove": [ "list_project_issues" ] } } } イシューが取得されると、Kiro は各 GitLab イシューに対して仕様を作成し始めます。 GitLab イシューの仕様を作成 仕様は専用メニューに保存され、プロジェクトワークスペースの .kiro ディレクトリにも格納されます。 最初に作成されたイシューの要件 ここから、技術的なアーキテクチャ決定、システムコンポーネントの相互作用、データモデルとフロー、API 仕様、セキュリティ検討、性能要件などを含む設計ドキュメントを作成できます。 最終ステップは設計を実行可能なタスクに分解し、明確な「完了の定義」と実装詳細を含めることです。 GitLab イシューの計画が完了すれば、タスクリストに従って構造的に機能を構築できます。 イシューに関する要件、設計、タスクリストの確認 開発を次のレベルへ Kiro の MCP 統合は単なる機能追加ではなく、AI が開発ワークフローに統合される根本的な変化です。Kiro をツールやサービスに直接接続することで、コンテキストスイッチに費やす時間を減らし、より多くの時間を構築に使えるようになります。 無料で Kiro を始めたり、ドキュメントを参照して機能をさらに学んだりしましょう。 MCP ユーザーガイド や MCP Server ページ でリファレンス実装も確認できます。要件に合う MCP サーバーが見つからない場合は、Kiro と一緒に自作することも検討してください。 ぜひつながりましょう — X 、 LinkedIn 、 Instagram では @kirodotdev を、 Bluesky では @kiro.dev をタグ付けし、 #builtwithkiro でシェアしてください。 出典： Unlock your development productivity with Kiro and MCP

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 8 月 22 日に「 AWS 生成 AI アプリ構築実践ガイド 」というLLMの基礎、RAG、AIエージェントを網羅した本が出版されます。基礎知識の習得に加えてハンズオンで実践力を磨くこともできるようになっています。ぜひご覧ください！ 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、8 月 11 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「経済産業省 GENIAC 基盤モデル開発支援事業 (第3期) における採択事業者への支援を開始」を公開 経済産業省と NEDO が実施する GENIAC 基盤モデル開発支援事業の第3期における採択事業者のキックオフが 2025年7月4日に行われました。AWS は採択事業者に対して Amazon EC2 P5/P5en/Trn2 インスタンスや Amazon SageMaker HyperPod などの計算資源、技術支援、開発者コミュニティ支援、事業化支援を提供します。本ブログでは、採択事業者12社の紹介と AWS による包括的な支援内容について紹介しています。 ブログ記事「業界タスク特化型⼤規模⾔語モデルの開発 〜 野村総合研究所様へのインタビュー 〜」を公開 野村総合研究所（NRI）様が AWS の生成 AI 実用化推進プログラムを活用して開発した業界タスク特化型大規模言語モデルについてのインタビュー記事です。専門知識への適用、推論コスト削減、安心・安全なコントロール性という3つの理由から特化型 LLM が求められており、業界知識の継続事前学習とタスク特化のファインチューニングを組み合わせた2段階アプローチによる学習手法や AWS Trainium を活用したコスト効率の改善について紹介しています。 ブログ記事「Reach plc は AWS を活用した AI 駆動の Guten により、インパクトのあるジャーナリズムを提供」を公開 本ブログは、英国最大のニュースパブリッシャー Reach plc が Amazon Bedrock を活用して開発した AI 駆動プロダクト「Guten」についての事例紹介ブログです。Guten の開発背景、機能、AWS アーキテクチャについて解説しています。Guten により、記事タグ追加やコンテンツドラフト作成などのタスクを自動化し、速報ニュースの公開時間を9分から90秒に短縮した効果が紹介されています。 ブログ記事「AI エージェントで制御する IoT ミニ四駆 – AWS Summit Japan 2025 展示の技術的詳細」を公開 AWS Summit Japan 2025 で展示された「AI エージェントで制御する IoT ミニ四駆」の技術的詳細について解説したブログです。Amazon Bedrock Agents を活用してクラウド上の AI エージェントがミニ四駆の制御判断を行う仕組みで、ESP32 マイコンを使用したハードウェア設計から AWS IoT Core を中心としたクラウドアーキテクチャまで、製造業 DX にも応用可能な技術的取り組みを詳しく紹介しています。 サービスアップデート Amazon Q Business がチャットの透明性向上のための Response Events機能 を提供開始 Amazon Q Business に Response Events 機能が追加されました。これまでクエリ処理がブラックボックス状態で、AI がどのように回答を生成したか分からない課題がありました。新機能により、RAG による企業知識の検索やファイル処理、プラグインとのやり取りをリアルタイムで確認できるようになります。処理過程が可視化されることで、回答への信頼性と透明性を向上させることが可能です。 Amazon Q Business が Agentic RAG を開始し、精度と説明可能性を向上 Amazon Q Business で新機能 Agentic RAG が提供開始されました。複雑な質問に対して AI エージェントが質問を自動的に分解して並列処理することで、より正確で詳細な回答を生成できるようになりました。企業データを対象とした複雑な問い合わせでも、データの整合性をチェックしながら包括的な回答を提供します。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock の Anthropic Claude Sonnet 4 でコンテキストウィンドウが拡張 Amazon Bedrock の Claude Sonnet 4 でコンテキストウィンドウが 20 万トークンから 100 万トークンに 5 倍拡張されました。これにより、大規模なコードベース全体の分析や、数百の文書を一度に処理する文書統合、複雑なワークフローを持つ AI エージェントの構築が可能になります。従来は分割して処理する必要があった大容量データも、一回のリクエストで完全な文脈を保ったまま処理できるようになりました。現在パブリックプレビューでオレゴン、バージニア北部、オハイオリージョンで利用可能です。 Amazon SageMaker HyperPod が新しいクラスター設定エクスペリエンスを提供開始 Amazon SageMaker HyperPod で新しいクラスター作成体験が提供開始されました。大規模な AI/ML ワークロード向けのネットワーク、ストレージ、コンピュート、IAM 権限などを数クリックで自動設定できます。従来は手動でこれらのリソースを個別に設定する必要がありましたが、新しい設定により AWS インフラの専門知識がない方でもクラスターを構築しやすくなりました。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod でカスタム AMI がサポート開始 Amazon SageMaker AI で新しい GPU インスタンス P6e-GB200 UltraServers のサポートが開始されました。従来の P5en インスタンスと比較して 20 倍以上のコンピュート性能と 11 倍以上のメモリを提供し、最大 72 の NVIDIA Blackwell GPU を活用できます。これにより兆パラメータ規模の大規模 AI モデルのトレーニングを効率よく取り組むことが可能です。現在はバージニア北部リージョンの Dallas Local Zone で利用可能で、SageMaker Flexible Training Plans を通じて予約できます。詳細は こちらのドキュメント をご参照ください。 SageMaker HyperPod が LLM タスクの Topology Aware Scheduling をサポート SageMaker HyperPod で Topology Aware Scheduling (TAS) が利用可能になりました。大規模言語モデル (LLM) のトレーニングタスクを最適なネットワーク配置で実行できます。従来は複数のインスタンス間でデータ交換する際、ネットワークホップが多く通信遅延が発生していました。今回のアップデートにより、ネットワークトポロジー情報を活用してタスクを自動的に最適な場所にスケジューリングし、インスタンス間通信を削減してトレーニング効率を向上させます。詳細は こちらのドキュメント をご参照ください。 SageMaker HyperPod がコンピュートリソースのきめ細かいクォータ割り当てをサポート SageMaker HyperPod で、コンピュートリソースの細かい quota 割り当てが可能になりました。これまではインスタンス全体を使う必要がありましたが、GPU や vCPU、メモリを必要な分だけチーム間で配分できるようになります。機械学習のトレーニングや推論タスクで、リソースの無駄遣いを防ぎ、コスト効率を向上させることができます。詳細は こちらのドキュメント をご参照ください。 Amazon EC2 シングル GPU P5 インスタンスが一般提供開始 Amazon EC2 P5 インスタンスに、NVIDIA H100 GPU を 1 つ搭載した新しいサイズが一般提供開始されました。従来は大規模な GPU 環境が必要だった機械学習や高性能コンピューティングを、小さく始めてコスト効率的に利用できるようになります。中小規模のチャットボットや翻訳ツール、製薬研究や金融モデリングなどの用途に最適です。東京リージョンを含む複数リージョンで利用可能です。 Amazon OpenSearch Serverless が kNN Byte vector と新しいデータタイプをサポート Amazon OpenSearch Serverless で kNN Byte vector サポートなど複数の新機能が追加されました。従来の kNN vector と比べてメモリとストレージ使用量を削減でき、コスト最適化とパフォーマンス向上が期待できます。さらに radial search や nested fields により、1 つのドキュメント内で複数ベクトルの管理が可能になり、複雑な検索・分析ワークロードにも対応しやすくなりました。詳細は こちらのドキュメント をご参照ください。 Amazon Neptune が GenAI アプリケーションでのグラフネイティブメモリのために Cognee と統合 Amazon Neptune Analytics が Cognee という AI エージェント向けメモリフレームワークと統合されました。この統合により、生成 AI アプリケーションでグラフベースの長期記憶機能を利用できるようになります。AI エージェントが過去のやり取りから学習し、時間の経過とともによりパーソナライズ化され効果的な応答を提供できます。詳細は こちらのドキュメント をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

Amazon Finance Automation (FinAuto) は Amazon Finance Operations (FinOps) の技術組織です。この組織のミッションは、FinOps を活用してAmazon ビジネスの成長と拡大を支えることです。自動化とセルフサービス機能を活用することで業務効率を飛躍的に高めると同時に、支払いと回収を正確かつ遅滞なく行える体制を整えています。FinAuto は、FinOps 全体を俯瞰できる特別な立場にあり、この強みを活かすことで、正確性、一貫性、ガバナンスを備えたデータとサービスを提供し、多様なユースケースに対応したソリューションを展開しています。 本記事では、Amazon Finance Automation チームの取り組みをご紹介します。具体的には、 Amazon DynamoDB 、 Amazon OpenSearch Service や Amazon Neptune などのAWSの特化型データベースと AWS Lambda などのサーバーレスコンピューティングを組み合わせ、運用データストア (ODS) を構築しました。この ODS は財務取引データを保管し、ミリ秒単位の応答速度で FinOps アプリケーションをサポートしており、FinOps ビジネスにとって不可欠な基盤となっています。 (本記事は 2025/04/15 に投稿された How Amazon Finance Automation built an operational data store with AWS purpose built databases to power critical finance applications を翻訳した記事です。) 要件 Amazon では、様々なシステムから財務データが生成され、会計処理のためにそれぞれの補助元帳に保管されていますが、各システムで異なるデータモデルが使用されています。財務アナリストが効率的に業務を行えるよう、これらの補助元帳のデータを統一的に扱える共通のデータモデルが求められています。また、この統合データは、バックエンドおよびフロントエンドの業務アプリケーションから利用できるよう、API 経由でアクセスできる環境を整える必要があります。 データベースサービスを選定するにあたり、以下の主要要件に焦点を当てて検討を行いました： データベースサービスは、大量のトランザクションを処理できるよう、迅速なスケーリングが可能でなければなりません。上流システムでは 1 日に数億件もの財務取引イベントが生成されるため、そうした処理量に応じて適切にスケールできる能力が求められます。 フロントエンドのユーザーアプリケーションを円滑に動作させるため、データ提供用 API はミリ秒レベルの高速なレスポンスを実現する必要があります。また、キーバリューベースでの検索にも対応している必要があります。具体的には、財務アナリストが口座番号を指定して、それに紐づくすべての取引データを瞬時に取得できるような機能が求められます。 データベースには、各補助元帳が持つ独自のデータ属性に対応できるよう、柔軟なスキーマ構造が求められます。 データストアは口座、請求書、クレジットノート、領収書といった財務関連エンティティを横断的に検索できる必要があります。例えば、財務アナリストが口座番号を知らなくても、口座名での検索が可能でなければなりません。 データストアは、口座単位や数千の口座を含むビジネスチャネル単位など、様々な観点からデータを集計できる機能を備えている必要があります。たとえば、財務アナリストが特定の口座に関連する売掛金の総額を把握できるようにする必要があります。 データベースにはアカウント間の関連性を保存できる機能が必要です。これは FinOps ならではの要件で、一人の顧客が複数の Amazon サービスをそれぞれ異なるアカウントで利用するケースに対応するためのものです。顧客への請求書を一本化し、利便性の高いサービスを提供するためには、アカウント間の関連性を正確に記録・管理できるデータベースが必要です。この関連性の情報を活用することで、複数のアカウントで発生した取引を適切にグループ化し、統合的な管理が可能となります。 ソリューション概要 多岐にわたる要件に対応するため、それぞれの要件に特化した AWS の専用データベースを複数組み合わせて利用する方針を定めました。 その中でも、主力となるデータストアとして Amazon DynamoDB を採用しました。採用の決め手となった特長は以下の通りです： まず、キーバリュー方式での読み取りにより、高速なデータアクセスを実現できます。具体的には、特定口座の請求書や領収書の参照、口座名や状態の確認といった操作を迅速に行うことができます。また、Amazon DynamoDB は柔軟なスキーマ構造を持つため、項目ごとに異なる属性を設定できます。これにより、複数の売掛金システムそれぞれが持つ固有の属性データを適切に保存できます。私たちのシステムでは、データの読み取りを行うクライアントが地理的に分散しており、また書き込みワークロードは上流の請求システムの状況に左右されるため、負荷の予測が困難です。そこで、Amazon DynamoDB の オンデマンドキャパシティモード を採用しました。このモードでは、キャパシティの管理を自動化でき、実際の利用量に応じた課金となるため、効率的な運用が可能です。 データの集計に関しては、数千件に及ぶトランザクションを遅延や性能劣化なく集計する必要があるため、事前計算サービスを構築しました。このサービスは、 Amazon DynamoDB Streams 、AWS Lambda、 Amazon Simple Queue Service（Amazon SQS） を組み合わせて実現しています。新しいイベントが発生すると自動的に起動し、非同期で集計処理を行います。このように事前に計算を行っておくことで、ユーザーが必要なときにミリ秒単位の応答速度でデータにアクセスすることが可能となります。 ユーザーからは、複数の属性を使って財務関連データを横断的に検索できる機能が求められていました。また、口座名の入力補完機能や、滞留債権残高が最も高い口座を上位から表示する機能なども必要とされていました。これにより、アナリストはそれらの口座に対する業務計画を立てることができます。これらの要件を満たすため、私たちは Amazon OpenSearch Service を採用しました。事前計算サービスで算出した滞留残高のデータを Amazon OpenSearch Service に保存することで、数千の口座にわたるデータの集計や並び替えを可能としました。 顧客の中には、一つの補助元帳で複数の口座を管理しているケースがあります。このような顧客からは、口座ごとに個別の連絡や請求書が届くのではなく、一元化された形での対応を望む声が寄せられていました。この要望に応えるため、財務アナリストが設定した口座間の関連性を保存し、必要に応じて検索できるシステムが必要でした。口座間の関係性は通常、親口座 “A” の下に子口座 “B” と “C” が属するような、階層構造として表現されます。Amazon Neptune は、高速で信頼性が高い、フルマネージド型のグラフデータベースで、相互に密接に関連したデータの保存と検索に最適化されています。Amazon Neptune は、私たちが作成しようとしている実際の関係性の構造を模倣したグラフ表現を生成します。このように関連データの保存とトラバーサル（データ構造の走査）に特化した機能を持つことから、私たちは Amazon Neptune を採用しました。 ソリューションアーキテクチャ 下図は、使用している各種 AWS サービスを含む、システム全体のアーキテクチャ概要を示しています。 注: 画像をクリックすると、新しいタブで拡大版を開くことができます。 複数の上流システムからのデータは、様々な方法で取り込まれ、変換された後に DynamoDB に保存されています。DynamoDB テーブルにはストリーム機能が有効化されており、複数の AWS Lambda 関数がこれらのストリームメッセージを処理して、Amazon SQS キューに送信します。これらのキューには適切なエラー処理のための デッドレターキュー (DLQ) が設定されています。さらに別の Lambda 関数群が SQS キューからメッセージを読み取り、そのデータをAmazon OpenSearch Service のドメインにインデックス化します。 なお、この解決策は DynamoDB と OpenSearch Service 間のゼロ ETL 統合が導入される以前から本番環境で稼働していました。ゼロ ETL を採用することで、アーキテクチャと運用がより簡素化されたはずであり、可能な場合には将来的にこの統合方式への移行を検討しています。 また、アカウント間の関係性を特定・処理する独立したマイクロサービスが、それらの関係性を Amazon Neptune データベースに格納しています。ビジネスのユースケースに応じて、DynamoDB、OpenSearch Service、もしくは Neptune クラスターを通じて、API を介してデータが提供されています。 Amazon DynamoDB 上流のシステム間に接続性がないため、重複した ID が発生する可能性を防ぐために、異なるエンティティごとに新しい識別子を作成しました。この新しい ID は私たちのシステム内で一意であり、データ利用者が API を呼び出す際に使用する識別子となっています。システムでは UUID version 5 を採用しており、各トランザクションで利用可能な属性の組み合わせを用いて ID を生成しています。 以下の図は、私たちの DynamoDB ベーステーブルのデータモデルを示しています。 ソートキー属性を使用することで、KeyConditionExpression を活用し、特定の（トランザクション）ID に関連するアカウントや請求書で始まる値を検索するクエリを指定することができます。 API の要件によっては、（トランザクション）ID 以外の属性でデータを検索する必要があったため、 グローバルセカンダリインデックス（GSI） を使用しています。GSI はデフォルトでスパースな特性を持っており、GSI に定義されたパーティションキーとソートキーが項目に存在しない場合、その項目は GSI には書き込まれません。このスパースインデックスは、テーブルのデータの一部のみを検索したい場合に特に有用です。上記の例では、marketplace 属性はアカウント項目にのみ存在します。’amzChannel’ を主キー、marketplace をソートキーとして GSI を作成することで、トランザクションの請求書項目を検索することなく、特定の amzChannel と marketplace に属するすべてのアカウントを迅速に検索することが可能になります。 以下の図は、私たちの DynamoDB テーブルに作成した GSI のサンプルを示しています： また、いくつかの並び替えのユースケースにおいて、ローカルセカンダリインデックス（LSI）も活用しています。通常、1つのアカウントには数百件の決済済み請求書（一定期間にわたって作成・支払いが完了した請求書）と少数の未決済請求書が存在します。特定のアカウントの支払期限超過残高を計算する際には、そのアカウントの未決済請求書を確認する必要があります。特定のアカウントの未決済請求書のみを参照する場合、アカウントの請求書を検索し、DynamoDB の FilterExpression を使用して status=OP の請求書をフィルタリングすることも可能です。しかし、フィルター式はクエリ完了後、結果が返される前に適用されるため、同じ量の読み取りキャパシティを消費してしまいます。数千件の請求書を持つアカウントの場合、このようなクエリのレイテンシーは高くなってしまいます。LSI を使用することで、アプリケーションは異なるソートキーを選択できるようになりました。LSI には、ベーステーブルの属性の一部または大部分のコピーが含まれています。LSI 内のデータは、ベーステーブルと同じパーティションキーで整理されますが、異なるソートキーを使用します。invoiceStatus をソートキーとして LSI を作成することで、特定のアカウントの未決済請求書を迅速に検索できるようになりました。この結果、大量の決済済み請求書を持つアカウントにおいて、未決済請求書の検索レイテンシーが 10 倍改善されました。 LSI はテーブル作成時にのみ作成できるため、将来の並び替えユースケースに対応できるよう、sortKey1 や sortKeyN などのプレースホルダー属性を作成しました。 以下は、ベースとなる DynamoDB テーブルとその LSI における属性のサンプル表現です： 運用データストア（ODS）における財務データの取り込みと提供において、最も重要な要件の一つは、正確なデータ品質を保証することです。私たちのサービスは、外部顧客に送付される取引明細書（SOA）の作成に使用されるため、堅牢で信頼性の高い照合サービスが、データの正確性を保証する上で極めて重要となります。この照合ソリューションには、上流システムから提供される真正データ（信頼できる情報源）と、DynamoDB テーブルから変換され Amazon Simple Storage Service（Amazon S3） で利用可能となったデータが必要です。DynamoDB のネイティブ エクスポート 機能を使用して S3 にデータを転送することで、DynamoDB に対するフルテーブルスキャンを回避することができました。また、DynamoDB は増分エクスポートをサポートしているため、前回のエクスポート実行以降に変更されたデータのみをエクスポートするよう設定しました。これにより、テーブルの読み取りキャパシティや可用性に影響を与えることなくデータを転送できています。その後、 Amazon EMR を使用して Spark アプリケーションを実行し、DynamoDB から S3 にエクスポートされたデータと、上流のデータストア（信頼できる情報源）からのエクスポートデータとの照合を行っています。DynamoDB からエクスポートされたデータは、照合システムへの入力としての役割だけでなく、他の下流のデータチームが財務報告を作成する際にも活用されています。 以下の図は、私たちの照合サービスの高レベルアーキテクチャを示しています： Amazon OpenSearch Service 入力途中での検索（サジェスト検索）や集計要件に対しては、Amazon OpenSearch Service を使用しています。DynamoDB の取引データはさらに情報が追加され、Amazon OpenSearch Service に取り込まれます。DynamoDB は AWS Lambda とネイティブに連携しており、DynamoDB ストリームのイベントに応答するトリガーとして Lambda を利用できます。この Lambda 関数がストリームイベントを処理し、エンティティ固有の SQS キューにメッセージを送信します。別の Lambda 関数が SQS のメッセージを処理し、追加情報でデータを拡充した上で、OpenSearch にインデックス化します。要件の一つとして、財務アナリストに割り当てられた全アカウントの売掛金の経過期間別残高を特定する必要があります。これにより、アナリストは担当アカウントの優先順位付けが可能になります。アナリストへのアカウント割り当ては別のデータセットとして管理されており、取引データとは別に保存されています。このデータを照会し、拡充したデータを OpenSearch Service に取り込むことで、クライアントのユースケースに応じた集計クエリをミリ秒単位のレイテンシーで実行することが可能になりました。 入力途中での検索に関して、OpenSearch Service はクエリ時処理とインデックス時処理のオプションを提供しています。クエリ時処理では、クエリ実行時に保存されたフィールドのプレフィックスを検索できるフィルターを指定します。データは通常通り OpenSearch に保存されますが、クエリはプレフィックスを検索します。これは、OpenSearch が既にインデックス化されたデータのプレフィックスをその場で計算して検索を実行するため、負荷の高い処理となります。これは「文字列を含む」という種類の処理に近いものです。一方、インデックス時処理では、インデックス作成時にカスタムトークナイザーを使用して単語をより小さな部分に分割することができます。私たちはデータのインデックス作成時に edge_ngram トークナイザーを使用しました。以下のスクリーンショットは、アカウント名「Amazon」がインデックス時に複数のトークンに分割される例を示しています。これにより、入力途中での検索における検索結果の高速化を実現しました。 Amazon Neptune 前述の通り、顧客アカウント間の関係性を追跡する要件があります。一人の顧客が補助元帳内に複数のアカウントを持つことがあり、顧客からは全アカウントを統合した請求明細書の発行を求められています。また、財務アナリストは顧客の全アカウントにわたる統合された経過期間別残高を確認する必要があります。このため、アカウント間の関係性を特定し、保持する必要が生じています。各事業部門は、顧客の関連アカウントを特定するための独自のルールと属性を定義しています。私たちのシステムは、これらの定義されたルールに基づいてデータ属性を取り込み、また関連アカウントの特定と維持のために、これらの属性の変更も検知しています。グラフデータベースである Amazon Neptune を使用することで、関係性を自然な形でモデル化し、ユースケースに応じた柔軟な走査クエリを実行することが可能になりました。 代替案として、DynamoDB を使用して同様の機能を実現する方法も検討しました。DynamoDB では 隣接関係リスト 設計モデルを使用して関係性を保存することが可能で、ノードに親ノードへの参照やそのノードに関連するエッジを含めることができます。この方法は実現可能ではありますが、データを取得するためのクエリには関係性を辿るための繰り返しの呼び出しが必要となり、ネストされた関係性や分岐する関係性に対してはパフォーマンスが低下してしまいます。一方、Neptune ではデータベース内で走査が行われるため、1回のリクエストで関係性を取得することができます。このため、関係性の保存には Amazon Neptune を採用しました。 初期のユースケースでは、複数の個別アカウントをグループとして集約して作業する機能が必要でした。以下の図は、ノードとエッジの構造を示しています。ノードから HasParent タイプのエッジを走査することで、関連するアカウントを迅速に取得できます。クエリはグループレベルから開始して入力エッジを辿るか、あるいはアカウントレベルから開始して出力エッジを辿り、見つかったグループから入力エッジに戻ることができます。 // If starting from an account to find all related accounts, example account 1 g.V(1) // Follow inbound/outbound edges of type "HasParent" deduping to avoid repetition .repeat(both("HasParent").dedupe()) // Fetch nodes that are of type "Account" .emit(hasLabel("Account")) > [ { id: 1, label: "Account" }, { id: 2, label: "Account" }, { id: 3, label: "Account" } ] より複雑なユースケースに対応するため、新しいマクログループ化を提供できるようスキーマを拡張しています。既存のデータに新しい関係性タイプとメタデータを定義する新しいノード/エッジタイプを追加することができます。これにより、既存のクエリに軽微な修正を加えるだけで、Neptune にシステム内の関連アカウントを見つけるための新しい関係性セットの走査を指示することができます。これを繰り返すことで、同じデータに対して異なるグループ化の視点を提供することが可能です。さらに、ノードに設定されたプロパティによって結果をフィルタリングすることで、返される項目をより詳細に絞り込むことができます。 以下の図は、2 つのビジネスグループが同じ組織に関連付けられている複雑なグループ化の例を示しています。 // If starting from an account to find all related accounts, example account 1 g.V(1) // Follow inbound/outbound edges of type "HasParent" and "SubsidiaryOf", deduping to avoid repitition .repeat(both("HasParent", "SubsidiaryOf").dedupe()) // Fetch nodes that have are of type "Account" .emit(hasLabel("Account")) > [ { id: 1, label: "Account" }, { id: 2, label: "Account" }, { id: 3, label: "Account" }, { id: 4, label: "Account" } ] アカウントが一方の顧客から別の顧客に移動するケースが発生することがあります。その場合、該当するアカウントを元の顧客のグループから切り離し、新しい顧客のグループに移動する必要が生じます。 以下の図は、組織 A のビジネスグループ 1 に属していたアカウント 1 が、新しいグループであるビジネスグループ 3 に移動する例を示しています。 結論として、Amazon Neptune を採用することで、独自のグラフデータベース管理システムを運用する複雑さを回避しながら、アカウント関係性サービスを構築することができました。このモデルにより、アカウント間の関係性を簡単に走査でき、関連アカウントを特定するというユースケースを解決し、ユーザーにより良い体験を提供することができています。グラフは毎日更新され、関係性の変更を特定しています。関係性の取得において、p90（ 90 パーセンタイル値）で 250 ミリ秒未満の応答時間を実現しています。 運用の優位性について Amazon の財務データを扱う上で、100 %のデータ品質を保証する必要があります。複数のコンポーネントを含む分散システムにおいては、信頼性と正確性の維持が重要です。そのため、私たちはフォールトトレランス（障害耐性）を基本原則としてシステムを設計しています。例えば、各 SQS キューには、処理に失敗したメッセージを捕捉するための対応するデッドレターキュー（DLQ）が設定されており、 Amazon CloudWatch によるモニタリングとアラームが構成されています。さらに、API における 5XX エラーとレイテンシーメトリクスのモニタリングには、CloudWatch API Gateway（APIG）メトリクスを活用しています。 また、ビジネスユースケースに応じたカスタムメトリクスを CloudWatch に公開するため、AWS SDK for CloudWatch を使用しています。例えば、ソースシステムでのトランザクションイベント生成から、最終的に運用データストアに取り込まれるまでの所要時間を計算するため、取り込みイベントのレイテンシーメトリクスを公開しています。 まとめ 本記事では、Finance Automation チームが財務部門特有の要件を満たすため、AWS 専用データベース（DynamoDB、OpenSearch Service、Neptune）を活用して、拡張性と信頼性を備えたイベント駆動型の運用データストレージを構築した事例をご紹介しました。 DynamoDB が標準で提供する DynamoDB Streams 、グローバルセカンダリインデックス、ローカルセカンダリインデックス、S3 へのエクスポート機能、柔軟なスキーマ構造といった機能により、開発工数を大幅に削減することができました。 また、Amazon OpenSearch Service の活用により、API のレスポンス時間を維持しながら、検索機能と集計機能の要件を満たすことができました。さらに、Amazon Neptune の採用によって、口座間の関連性の保存、探索、取得処理を簡素化することができました。 加えて、AWS Lambda というサーバーレスコンピューティングを DynamoDB Streams および Amazon SQS と組み合わせることで、システム全体をシンプルな構成としました。SQS の活用により、高い耐障害性を維持しながら、データストア間の疎結合化を実現することができました。 AWS 専用データベースについて詳しく知りたい方は、 Purpose-built databases のページをご覧ください。 作者情報 Nitin Arora は Amazon の Finance Automation 部門のシニアソフトウェア開発マネージャーです。18 年を超えるキャリアの中で、業務に不可欠な、スケーラブルで高性能なソフトウェアの開発に携わってきました。現在は財務部門において、データメッシュの構築をはじめとする、様々なデータ・アナリティクス施策のリーダーを務めています。プライベートでは、音楽鑑賞と読書を趣味としています Pradeep Misra は、AWS のプリンシパルスペシャリストソリューションアーキテクトとして、Amazon 社内の様々な部門で最新の分散分析システムや AI/ML プラットフォームの設計に従事しています。特に、データ、分析、AI/ML を駆使してお客様の課題解決に取り組むことに強い情熱を持っています。プライベートでは家族と過ごす時間を大切にしており、一緒に新しい場所へ出かけたり、さまざまな料理を楽しんだりしています。また、家族でボードゲームやアウトドアゲームを楽しむほか、娘たちと一緒に科学実験を行うことを楽しみにしています。 Kumar Satyen Gaurav は、エンタープライズアプリケーション、ビッグデータソリューション、ソフトウェア開発の分野で18年を超えるキャリアを持つ、経験豊富なソフトウェア開発マネージャーです。 Amazon では、エンジニアチームのリーダーとして、AWS 技術を駆使した製品・サービスの開発を指揮しています。これらの成果は、Amazon の財務運営部門に対して、事業部門を横断する重要な経営判断材料を提供しています。仕事以外では、読書や旅行を楽しむとともに、金融投資や経済の動向について知見を深めることに情熱を注いでいます。 Tarun Gupta は、Amazon のシニアシステム開発エンジニアとして、同社の財務データ基盤を支える重要なビッグデータ処理システムと運用データストアの設計・実装を手がけてきました。その業務は多岐にわたり、Apache Hudi のような Spark ベースの S3 テーブルフォーマット、運用データストアのデータモデリング、そして様々な AWS の NoSQL およびリレーショナルデータストアを活用した複雑なアプリケーションアクセスパターンのサポートなどを含みます。仕事を離れると、熱心なボードゲーム愛好家として知られ、また大工仕事や絵画といった DIY プロジェクトに取り組むことを趣味としています。 Javier Vega は、9 年以上の経験を持つ Amazon のシニアソフトウェア開発エンジニアです。AWS を活用し、Amazon の財務運営を支える大規模で信頼性の高い、イベント駆動型のデータサービスの設計と実装を主導してきました。仕事以外では、オンラインゲームのプレイヤーがゲームの腕を上げるのに役立つよう、プレイデータの分析と可視化に関するプロジェクトに取り組んでいます。

日本最大の “AWS を学ぶイベント” AWS Summit Japan が 6 月 25 日（水）、26 日（木）の二日間で開催されました。今年も業種ごとのブース展示の中で、建設・不動産業界向けのソリューション展示を行いました。大勢のお客様にご来場いただけましたこと、御礼申し上げます。「デジタルの力で、建設・不動産の”当たり前”を革新する」というタイトルで、生成AIの活用による業界課題の解決や業務効率化に向けて３つのソリューションを展示させていただきました。このBlogを通じて展示内容を改めてご紹介します。 生成 AI による書類審査業務の改善 AI 書類審査ソリューション – RAPID（Review & Assesment Powered by Intelligent Documentation） クリック すると説明資料を表示します。 不動産業界において「大量のドキュメント審査/レビューに時間がかかっている」という課題から生まれたソリューションです。ソリューションの開発中に他の業界でも同様の課題が存在することが分かりました。そのため、多くのお客様に試していただけるように AWS Samples でソースコードを公開しています。簡単にデプロイできますので、是非試してみてください！主な機能は以下の３つになります。 構想化されたチェックリストの作成と管理 生成 AI による書類審査のサポート AIによる判断根拠や信頼度を表示し透明性を確保 何らかのルールに基づいて申請書を人がレビューする業務は多いのではないでしょうか？生成　AI を利用して書類審査ができれば、業務負荷の低減や属人的な審査の削減につながるのでは？と期待を持たれる方もいらっしゃると思います。一方で、AIに審査を任せた場合には、精度、妥当性、説明責任などを担保する上での課題が生じます。このソリューションは、Human-in-the-Loop の考えに基づき、利便性と信頼性を両立させたものになっています。最初に審査ルールとなるドキュメントをアップロードすることで、AIがチェックリストを作成します。審査精度を高める工夫として作成されたチェックリストは構造化されており、必要に応じて人間が修正や追加をできるようにしています。次に審査対象のドキュメントをアップロードすることで、AIがチェックリストを参照し、ドキュメントを審査します。ここでは、審査結果に加えて判断根拠や信頼度が表示されるため、AI審査の透明性を確保することができます。他にも信頼度が低い結果だけをフィルタリングして効率的に確認したり、MCPを利用して外部ツールを参照し審査精度を高める機能なども実装されています。詳しくは、是非 AWS Samples にてご確認ください。 実際の画面サンプルやアーキテクチャは以下となります。(画像クリックで大きな画像を表示します） ハウスメーカーがお客様との商談結果を元に議事録を作成。その決定事項と案内しようとしている間取りの条件が合っているかを確認する例 「構造化されたチェックリスト作成」 〜 「書類審査の実行」 チェックリストをアップロードして構造化されたデータへ変換するフロー 書類の審査処理フロー 社内稟議書チェックのサンプル画面 社内稟議書サンプル アーキテクチャ図。AWS Lambda や AWS Step Functions といったサーバレスサービスを中心に構成されており、利用頻度に応じた課金体系が主体となっています。 RAPID Architecture 生成 AI による建設現場 映像活用の推進 生成 AI とカメラが描く建設現場のDX未来像 – CEDIX（Construction/Camera Edge Data/Device Intelligence X ) クリック すると説明資料を表示します。 生成 AI を利用して、建設現場に設置されたカメラの映像をより有効活用したいというニーズに応えるソリューションです。本ソリューションは以下のような特徴で現場カメラの映像活用を推進します。 多様なカメラの統合と映像データの一元管理 安価で拡張可能な保存先を提供 生成 AI 活用による高度な分析と自動化 建設現場では安全管理、防犯、遠隔臨場を目的に現場カメラの導入が進んでいます。一方で、「モニターに映った映像を常時確認するのではなく、何らかの問題が起きた場合だけ通知を受けたい」、「蓄積した映像データから新たな洞察を得たい」など、映像を活用して業務のあり方を変えたいという要望があるのではないでしょうか？また、現場に導入されるカメラのメーカーや仕様もバラバラで、それらを一元管理したいというニーズもあると思われます。CEDIX はカメラの仕様に応じた多様なインターフェースを提供し、収集した映像データを共通の仕組みで管理します。さらに、生成 AI を活用して映像データを分析することができます。例えば、安全管理の観点から、建機の近くに人が立ち入った場合にアラートを上げることができます。また、同じ安全管理の例でも、工事の進捗に応じて確認すべき観点は変わります。高所作業においては、ハーネスの未着用を検出することが必要になります。CEDIX はカメラごとにプロンプトで役割を指示できます。工程の進捗に応じて、「建機と人の位置から危険を判定」という指示から「ヘルメットやハーネスなどの個人用保護具の未着用による危険を判定」という様に柔軟に指示を追加・変更することができます。さらに蓄積された映像データを生成 AI で分析することで、事故につながる可能性のある危険な状況の件数など統計分析をおこないそれをレポートとして出力することが可能です。分かりやすい例として安全管理を挙げましたが、現場での整理整頓・施工状況の把握・ベテラン職人の視点を再現など、どのような指示を与えるかによって現場の QCDSE 向上に寄与できます。導入に向けた検討や発展的なユースケースの相談については、弊社営業担当もしくは AWS 問い合わせ窓口 へお問い合わせください。 実際の画面サンプルやアーキテクチャは以下となります。(画像クリックで大きな画像を表示します） カメラ管理の基本的な機能 – 設置場所別のカメラ一覧、最新映像をまとめてみるLiveビューイング、過去の時系列画像・映像及び生成 AI による検知内容の表示 カメラ管理の基本的な機能 事前設定された内容に加え、生成 AI によって設定されたタグも含めた検索、注意・確認が必要なシーンのブックマーク管理、生成 AI による自由度の高いレポート作成 画像・映像の検索、ブックマークからの一覧表示、レポート作成 カテゴライズ可能な生成 AI 自動タグの設定、カメラごとで組み合わせ可能な AI 検知設定、現場毎に検知したタグを可視化するインサイト分析、設定されたタグでシーンを絞り込める検索機能 生成 AI による自動タグ設定と活用シーン アーキテクチャ図。都度処理を行う部分は Amazon API Gateway や AWS Lambda といったサーバレスサービスを中心に構成。画像収集処理はリアルタイム性などの特性に応じてコンテナやサーバレスを活用 CEDIX Architecture 生成 AI による BIM データ活用 IFC With GraphRAG クリック すると説明資料を表示します。 生成 AI を利用することで、BIM（ Building Information Modeling ）データの活用を広げる方向性を提示するソリューションです。本ソリューションは以下のような機能を持っています。 IFC ( Industry Foundation Classes ) ファイルをAIが扱いやすい形式（RDF ( Resource Description Framework ) グラフ）に変換しグラフデータベースに格納 グラフデータベースに格納された建物の情報にチャットで問い合わせ 問い合わせ結果に関係するオブジェクトをブラウザベースのビューワー上にハイライトして表示 建設業界のデジタル変革が進む中で、BIM の導入が進んでいます。しかし、オペレーターの専門知識の習得に加え、BIM に持たせるべきデータの粒度や工程や企業を跨ったデータ連携の課題など、BIM の活用にはまだ多くの障壁がある状況です。本ソリューションは、生成 AI を利用して自然言語で BIM データ（IFC）にアクセスする機能を持っているため、BIM のソフトウェアライセンスを持たないユーザーや BIM に習熟していないユーザーに対するユースケースを広げることを目的にしています。チャットから「窓の数を教えて」と質問することでオブジェクトの数量を取得したり、「窓の熱貫流率を教えて」と質問することで素材・構造に関係する属性情報を取得したりすることができます。また対象のオブジェクトがビューワー上でハイライトされるため、問い合わせ結果に影響するオブジェクトを直感的に把握することができます。このソリューションを実現する技術的な方法はRAGに該当しますが、寸法や数量に関する情報を正確に取得するために、ナレッジベースにグラフデータベースを利用した GraphRAG を採用しています。IFC ファイルをアップロードするだけでデータベースへの格納まで実行されるので、 GraphRAG の専門知識がなくても始められるのも特徴です。導入に向けた検討や発展的なユースケースの相談については、弊社営業担当もしくは AWS 問い合わせ窓口へお問い合わせください。 実際の画面サンプルやアーキテクチャは以下となります。(画像クリックで大きな画像を表示します） 実装イメージ。IFC ファイルをグラフデータベースに変換・格納し、生成 AI を通じて自然言語で操作を可能にしています。 IFC With GraphRAG 説明 操作例１。オブジェクトを条件指定して簡単に検索したり、オブジェクトの情報を元に自然言語による質問へ回答が可能です。 IFC With GraphRAG Screenshot-1 操作例２。条件を絞らずにシンプルな質問でも回答が可能です。 IFC With GraphRAG Screenshot-2 アーキテクチャ図。IFC ファイルの変換は AWS Batch を中心としたバッチ処理で行います。グラフデータベースはマネージドサービスの Amazon Neptune Serverless を利用しています。 IFC With GraphRAG Architecture まとめ 今回のAWS Summit Japan 2025 建設・不動産向けブース展示では3つのソリューションと、建設不動産における AWS Marketplace のソリューションをご紹介させていただきました。様々な立場のお客様から強い関心とお困りごとについてのディスカッションをさせていただきました。改めて御礼申し上げます。これらの情報はソリューションへの反映等で活用させていただきます。 本ブログの内容や各展示内容の詳細についてご関心持たれましたら、 弊社営業担当もしくは AWS 問い合わせ窓口 へお問い合わせください。 本ブログは、ソリューションアーキテクト 伊藤が担当しました。

この記事は Streamline service-to-service communication during deployments with Amazon ECS Service Connect (記事公開日 : 2025 年 7 月 28 日) の翻訳です。 コンテナ化されたマイクロサービスをデプロイする際、更新中の信頼性の高いサービスディスカバリーと効率的なルーティングを維持することは大きな課題です。従来のブルー/グリーンデプロイアプローチは、トラフィック管理にロードバランサーを大きく依存しており、コンテナベースのサービス間通信を扱う場合に複雑になる可能性があります。この複雑さにより、サービス中断の可能性が高まり、本番トラフィックを新バージョンに向ける前に、新バージョンを分離環境でテストすることが困難になります。 Amazon Elastic Container Service (Amazon ECS) と Amazon ECS Service Connect を使用したブルー/グリーンデプロイの組み合わせは、これらの課題に対する直接的なソリューションを提供します。この統合により、共有名前空間内にテストトラフィックルーティング機能を導入することで、従来のブルー/グリーンデプロイモデルが強化されます。これにより、ほぼゼロのダウンタイムでマイクロサービスの新バージョンをデプロイし、分離環境で徹底的にテストし、必要に応じて迅速にロールバックする能力を維持できます。この記事では、コンテナ化されたアプリケーションのより効率的で回復力のあるデプロイプロセスを作成するために、この強力な組み合わせを実装する方法を説明します。 機能の概要 ブルー/グリーンデプロイは、2つの同一だが別個の環境を維持します：現在の本番バージョン用のブルー環境と新バージョン用のグリーン環境です。ローリングアップデートとは異なり、両方のバージョンが同時に実行され、それらの間でコントロールされたトラフィックシフトが行われ、迅速なロールバックとほぼゼロのダウンタイム移行が可能になります。 ECS Service Connect は、管理されたサービスディスカバリーと自動 サイドカープロキシインジェクション を通じてコンテナ化されたアプリケーション通信を効率化します。これにより、サービスは共有名前空間内で直接的な論理名を使用して簡単に相互を発見し通信できるようになります。 ブルー/グリーンデプロイと ECS Service Connect の組み合わせ は、組み込みのサービスディスカバリーと信頼性の高いルーティングを通じてトラフィック管理を強化します。これにより、チームは改善された信頼性と最小限のサービス中断でデプロイを行うことができます。 図1：ブルー/グリーンデプロイワークフローの Amazon ECS サービス状態 ブルー/グリーンデプロイプロセスは、上図に示すように、安全で制御された移行を支援するために設計された3つの明確な調整フェーズを通じて管理されます： 初期デプロイ状態： 両方の環境は展開されていますが、トラフィックはまだグリーンタスクにルーティングされていません。 進行中のデプロイ状態： テストトラフィックはブルータスクからグリーンタスクにルーティングされます。検証が成功すると、ECS Service Connect Proxy の自動構成変更により、本番トラフィックもグリーンタスクにルーティングされます。 最終的なデプロイ状態： 設定可能なベイク時間中は、必要に応じてすばやくロールバックできるように両方の環境がスケーリングされたままになります。 デプロイワークフローはライフサイクルステージによって管理されます。これはデプロイプロセスの正確なポイントであり、きめ細かい制御と検証を可能にします。各ステージは特定のデプロイイベント（例えば、 POST_TEST_TRAFFIC_SHIFT 、 PRE_PRODUCTION_TRAFFIC_SHIFT ）を表し、関連付けられたライフサイクルフックをトリガーすることができます。これらのフックは検証チェックやカスタムロジックを実行する AWS Lambda 関数です。 例えば、 POST_TEST_TRAFFIC_SHIFT フックは、全ての本番トラフィックを切り替える前にテストトラフィックをシミュレートすることでグリーン環境を検証できます。この検証プロセスは、各フェーズでの品質基準の適合を強制することでデプロイの信頼性を高め、サービス中断のリスクを最小限に抑えます。Amazon ECS ブルー/グリーンライフサイクルステージの詳細については、 AWS ドキュメント を参照してください。 ECS Service Connectによるブルー/グリーンデプロイの理解 ECS Service Connect は、Amazon ECS タスク内に組み込まれたルーティング機能を通じてバージョン移行を管理することで、ブルー/グリーンデプロイを効率化します。DNS 更新とロードバランサーの再構成が必要な従来のアプローチとは異なり、ECS Service Connect はサイドカープロキシを通じてルーティングを処理し、明確な移行を作成します。 ブルー/グリーンデプロイ中、ECS Service Connect はバージョン間の正確なトラフィック制御を可能にするヘッダーベースのルーティングメカニズムを採用します。アプリケーションコードは変更されないままで、インフラストラクチャがバージョンターゲティングを処理します。以下は、特定のヘッダー名（ $HEADER ）とヘッダー値（ $VALUE ）を持つ testTrafficRules を設定する方法の例です。 "serviceConnectConfiguration": { /* ... */ "testTrafficRules": { // グリーンデプロイへのテストトラフィックをルーティング "header": { // テストトラフィック用のヘッダーベースルーティング "name": "$HEADER", // カスタムヘッダー名 "value": { "exact": "$VALUE" // ヘッダー値の完全一致 } } } } 以下は POST_TEST_TRAFFIC_SHIFT ライフサイクルフックの設定例です。利用可能なライフサイクルステージの完全なリストは AWS ドキュメント で確認できます。 "deploymentConfiguration": { "strategy": "BLUE_GREEN", "bakeTimeInMinutes": 2, // ブルー環境の設定可能なベイク時間 "lifecycleHooks": [ // ライフサイクルフック設定 { "hookTargetArn": "$AWS_LAMBDA_FUNCTION", // AWS Lambda関数ARN "roleArn": "$ECS_LAMBDA_INVOKE_ROLE", // Lambda呼び出し用のロール "lifecycleStages": [ "POST_TEST_TRAFFIC_SHIFT" // ライフサイクルステージ ] } ] } ECS Service Connect は、アプリケーションコードをデプロイから分離するのに役立つ組み込みプロキシレイヤーを導入することで、デプロイの仕組みを変更します。開発者はデプロイの懸念事項なしに機能の構築に集中でき、運用チームはアプリケーションコードに触れることなく改善されたリリース戦略を実装できます。この分離により、チーム間で通常必要とされる調整が不要になり、コンテナ化されたアプリケーションのリリースプロセス全体が効率化されます。 ブルー/グリーンテスト戦略 ブルー/グリーンデプロイの重要なフェーズは、本番トラフィックを切り替える前にグリーン環境を検証することです。ECS Service Connect 内では、テストトラフィックは名前空間内でのみルーティングされるため、テストパターンを実装する際に慎重な検討が必要です。このセクションでは、2つの一般的なパターンを調査します： Application Load Balancer を通じたヘッダーベースのテスト ：このアプローチでは、 Application Load Balancer (ALB) のヘッダーパススルー機能を使用します。フロントエンドサービスは特定のヘッダーをバックエンドサービスに転送し、本番トラフィックを分離しながらロードバランサーを通じてグリーン環境を対象としたテストを可能にします。この方法は、トラフィックフローを制御し、サービスの動作を検証するための直接的なメカニズムを提供します。エンドユーザーにテストパスを公開しないようにするために、インターネットに公開されていない専用のロードバランサーを使用し、アプリケーション VPC 内に Lambda 関数をデプロイすることでこのソリューションを強化することをお勧めします。ウォークスルーセクションでは、基本的なヘッダーベースのルーティングアプローチを実装します。 図2：ALBワークフローを通じたヘッダーベースのテスト 専用テストサービスの実装 ：この方法では、名前空間内に専用のテストサービスをデプロイします。以下の図では、 POST_TEST_TRAFFIC_HOOK が名前空間内でテストヘッダーを使用してグリーンデプロイを検証するために Amazon ECS サービスをスケールアップします。テストの結果は Amazon S3 バケットに渡されます。関数内のロジックがこの結果を評価します。このアプローチは包括的な検証機能を提供しながら、アーキテクチャの整合性を維持します。ただし、より多くのAWSリソースが必要です。 図3：専用テストサービス実装ワークフロー これらの検証戦略により、ECS Service Connect のセキュリティと分離の利点を維持しながら、新しいバージョンの徹底的なテストが可能になり、信頼性の高いデプロイプロセスを確保します。 前提条件 このウォークスルーをデプロイするには、リソースを作成するための必要な権限を持つ AWS アカウントへのアクセス、 AWS Command Line Interface (AWS CLI) 、および AWS Cloud Development Kit (AWS CDK) が必要です。 また、AWS CLI のバージョン 2.27.51 以降が必要になります。AWS CLI の最新リリースについては、GitHub の AWS CLI version 2 Changelog を参照してください。 このウォークスルー全体を通じて、ECSクラスターと Amazon Virtual Private Cloud (Amazon VPC) にリソースをデプロイします。これらのステップバイステップのコード例は、サンプル GitHub リポジトリ 内のAWS CDK アプリで見つけることができます。 ウォークスルー ECS Service Connect とそのブルー/グリーンデプロイ戦略の核となるコンセプトを調査しました。実際の実装を通じてこれらの原則を実証できます。 このガイドでは、ECS Service Connect と AWS CLI を使用してブルー/グリーンデプロイでサンプルアプリケーションをデプロイする方法を示します。この設定は AWS CloudFormation 、 AWS Management Console 、または他の Infrastructure as Code（IaC）ツールを通じても実装できます。 1. 環境のセットアップ 環境セットアッププロセスには、必要な AWS インフラストラクチャのデプロイと初期サービスの設定が含まれます。必要なリソースを設定するために、これらの手順に従ってください： GitHub リポジトリをクローンします。 $ git clone https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns.git ライフサイクルフックとして設定される Lambda 関数をビルドします。 $ cd sample-amazon-ecs-blue-green-deployment-patterns/ecs-bluegreen-service-connect $ sh build-lambda-zip.sh AWS CDK を利用してコアインフラストラクチャをデプロイします。Amazon VPC、ALB、ECS クラスター、Lambda 関数、関連付けられる AWS Identity and Access Management (IAM) ロールを含むCloud Formation スタックを作成します。 $ npm install $ cdk bootstrap $ cdk deploy インフラストラクチャをデプロイした後、Cloud Formation スタックの出力から環境変数を設定します。 $ source load-env-variables.sh ECS サービスの初期バージョンのデプロイと必要なタスク定義を作成します。 $ sh demo-setup.sh demo-setup.sh スクリプトは、タスク定義とサービス設定のJSONファイルを含む出力ディレクトリを生成します。これらのファイルは、後続のデプロイ手順で使用されます。これらのファイルは、以下のセクションで使用されるブルー/グリーンデプロイ設定のテンプレートとして機能します。 2. 環境の確認 このデプロイは、以下のコンポーネントを持つ ECS Service Connect を使用したブルー/グリーンデプロイをサポートするアーキテクチャを作成します： ALB を主要なエントリポイントとして、外部トラフィックを管理し、 bluegreen-fronend サービスに分散します。 相互接続された2つの Amazon ECS サービス を備えた ECS クラスター ： bluegreen-frontend には、ALB からの受信リクエストを処理し、ヘッダーをそのまま転送する nginx ベースのリバースプロキシが含まれています。本番環境では、このフロントエンドサービスにはアプリケーションロジックが含まれますが、このウォークスルーでは簡単のためにただトラフィックを転送するのみです。 bluegreen-backend はリクエストを処理し、静的な HTML コンテンツを提供します。 ECS Service Connect は、サービスディスカバリーとコンポーネント間のルーティングを行います。 Lambda 関数 はライフサイクルフックを通じてデプロイ検証を実装します。この機能は POST_TEST_TRAFFIC_SHIFT の段階で起動し、テストトラフィックがグリーン環境にルーティングされるときに重要な検証を行い、デプロイの信頼性を高めます。 以下のアーキテクチャ図は、グリーンバージョンの bluegreen-backend サービスをデプロイする前の初期状態を示しています。 図4：グリーンバージョンのアプリケーションをデプロイする前の初期状態 デプロイプロセスでは、 POST_TEST_TRAFFIC_SHIFT ライフサイクルステージにおいて、Lambda 関数を使用してグリーン環境の検証を実装します。この関数は、指定されたテストヘッダー（ x-amzn-ecs-bluegreen-test:test ）を ALB エンドポイント（ $ALB_URL ）に送信することで検証を実行します。 検証結果に基づいて、Lambda 関数は以下の3つの可能な hookStatus 値のいずれかを返し、それぞれが特定のデプロイ動作をトリガーします： SUCCEEDED ：デプロイ開始を許可します FAILED ：ロールバックをトリガーします IN_PROGRESS ：追加の検証リクエストを試みます、試行間隔（デフォルトでは 30 秒）を空けてリトライします 以下の実装コードは、Lambda 関数の検証ロジックを示しています： import requests def lambda_handler(event, context): """ Tests blue/green deployment. """ try: response = requests.get( $ALB_URL, headers={"x-amzn-ecs-bluegreen-test": "test"}, timeout=5 ) if response.status_code == 200 and "Green Version" in response.text: return {"hookStatus": "SUCCEEDED"} else: return {"hookStatus": "FAILED"} except Exception as e: print(f"Error: {str(e)}") return {"hookStatus": "FAILED"} ベースラインアーキテクチャと検証メカニズムを確認しました。グリーンバージョンの実装のために bluegreen-backend サービスの更新を進めます。 3. バックエンドタスクをグリーンバージョンに更新する 環境が設定されたので、グリーンデプロイとして機能する bluegreen-backend サービスの更新バージョンを作成できます。この変更には、背景色をブルーからグリーンに変更する新しいタスク定義の登録が含まれます。新しい背景色によって、デプロイプロセス中のトラフィックルーティングの成功を視覚的に確認できます。 以前に環境セットアップフェーズで生成した JSON ファイルを使用して、新しいタスク定義を登録するために以下のコマンドを実行します： $ aws ecs register-task-definition \ --cli-input-json file://outputs/taskdef_backend_update.json 4. ブルー/グリーン戦略を使用してアプリケーションの新バージョンをデプロイする 新しいタスク定義が登録されたので、ECS Service Connect を使用してブルー/グリーンデプロイを実装できます。このセクションでは、制御されたテストと検証を可能にするテストトラフィックルールとライフサイクルフックのような必要なデプロイ設定パラメータを説明します。 デプロイには、新しいタスク定義と必要なトラフィックルーティングルール（ serviceConnectConfiguration と deploymentConfiguration ）の両方を組み込むために bluegreen-backend サービス設定を更新する必要があります。 serviceConnectConfiguration セクション ：デプロイプロセス中に正確なトラフィックルーティングを定義する testTrafficRules が必要です。これらのルールは、HTTP ヘッダーに基づいてどのリクエストをグリーン環境に向けるべきかを指定し、新バージョンの分離されたテストを可能にします。 "serviceConnectConfiguration": { ... "services": [{ ... "clientAliases": [{ ... "testTrafficRules": { "header": { "name": "x-amzn-ecs-bluegreen-test", "value": { "exact": "test" } } } }] }] }, deploymentConfiguration セクション ：適切な検証制御を持つブルー/グリーンデプロイ戦略を実装するために特定のパラメータが必要です。この設定は、Amazon ECS がデプロイプロセスを管理し、Lambda 関数統合によって各ステージで検証を実施する方法を定義します。 hookTargetArn は検証のための Lambda 関数を指定し、 roleArn は必要なIAM権限を提供し、 POST_TEST_TRAFFIC_SHIFT はデプロイ検証チェックが実行されるタイミングを定義します。 "deploymentConfiguration": { "strategy": "BLUE_GREEN", "bakeTimeInMinutes": 2, "lifecycleHooks": [{ "hookTargetArn": "arn:aws:lambda:us-west-2:1111111111:function:LifeCycleHook", "roleArn": "arn:aws:iam::1111111111:role/EcsLambdaInvokeRole", "lifecycleStages": [ "POST_TEST_TRAFFIC_SHIFT" ]} ] } グリーンバージョンの bluegreen-backend サービスをデプロイするために以下のコマンドを実行します。 $ aws ecs update-service \ --service bluegreen-backend \ --cli-input-json file://outputs/service_backend_update.json 5. デプロイプロセスの理解 ECS Service Connect を使用したブルー/グリーンデプロイ中、Amazon ECSは新しいグリーン環境タスクを作成することでプロセスを開始し、準備ができると POST_TEST_TRAFFIC_SHIFT ライフサイクルフックのタイミングでテストトラフィックが新しい環境に向けられます。検証プロセスでは、Lambda 関数によってテストヘッダーを持つリクエストが ALB に送信され、ALB はそれらのリクエストをフロントエンドサービスに転送し、ECS Service Connect はグリーンバックエンドへのルーティングを行います。デプロイの成功は Lambda 関数の検証結果に依存し、デプロイを進める（SUCCEEDED）かロールバックをトリガーする（FAILED）かが決まります。 図5：ECS Service Connect ブルー/グリーンデプロイステップ この検証メカニズムによって、本番トラフィックの移行が発生する前にグリーン環境が正しく動作していることを確認できます。デプロイプロセスの詳細な仕様と追加の設定オプションについては、 AWS ドキュメント を参照してください。 6. アプリケーションの新バージョンの検証 ブルー/グリーンデプロイが完了した後、以下のコマンドを実行して新しいグリーンバージョンが本番トラフィックを正常に処理していることを確認します： $ curl -s $ALB_DNS | grep "Green Version" このコマンドは（テストヘッダーなしで）ALBエンドポイントにリクエストを送信し、レスポンス内の「Green Version」テキストを検索します。成功したレスポンスは、本番トラフィックがグリーン環境によって提供されていることを示し、デプロイが正常に完了してトラフィック移行が期待通りに発生したことを確認します。 クリーンアップ このウォークスルーを完了した後、継続的な課金を防ぎ、整理されたAWS環境を維持するために、デプロイされたすべてのリソースをクリーンアップする必要があります。未使用のリソースを排除することで、予期しない料金が発生するのを防ぎ、AWS環境が整理された状態に保たれます。 実証セットアップで作成した全てのリソースを削除します。 $ sh demo-teardown.sh AWS CDK でデプロイされたインフラストラクチャコンポーネントを削除します。（削除に失敗した場合は、該当のリソースをコンソール等で削除してください。 $ cdk destroy タスク定義の Amazon Resource Names (ARNs) を取得します。 $ aws ecs list-task-definitions --family-prefix bluegreen-backend \ --query 'taskDefinitionArns[*]' $ aws ecs list-task-definitions --family-prefix bluegreen-frontend \ --query 'taskDefinitionArns[*]' $TASK_DEFINITION_ARN の値をステップ3のコマンドで抽出したARNで置き換え、Amazon ECS タスク定義を削除します。 $ aws ecs deregister-task-definition \ --task-definition $TASK_DEFINITION_ARN $ aws ecs delete-task-definitions \ --task-definitions $TASK_DEFINITION_ARN 結論 Amazon ECS Service Connect とブルー/グリーンデプロイの組み合わせは、サービスディスカバリーの効率化・分離テストの実現・ロールバック機能を備えた信頼性の高いトラフィック移行の提供、によってコンテナ化されたマイクロサービスのデプロイをモダナイズします。この機能がデプロイプロセスをどのように改善し、運用リスクを軽減できるかを楽しみにしています。この機能を Amazon ECS サービスで実装し、この機能をアプリケーションに統合する際のフィードバックを共有してください。詳細については、 AWS ドキュメント をご覧ください。 翻訳はソリューションアーキテクトの林が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 少し先のイベントになりますが、対面/ライブストリーミングのハイブリット形式で、AWS Unicorn Day Tokyo 2025 が 9/2(火) に開催されます。現地でデモがみれるほか、ネットワーキングパーティもあわせて開催いたします。詳細は こちら からご確認ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年8月11日週の主要なアップデート 8/11(月) AWS IoT Core が DeleteConnection API を導入し MQTT 接続を効率化 AWS IoT Core で DeleteConnection API が新たに提供開始されました。この API により、MQTT クライアントをプログラム的に切断できるようになり、デバイス管理が大幅に向上します。従来は手動での切断しかできませんでしたが、今回のアップデートでエンドポイント間でのデバイス移動や接続トラブル対応が自動化可能になりました。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for Oracle が 2025 年 7 月 Spatial Patch Bundle をサポート開始 Amazon RDS for Oracle で 2025 年 7 月の Spatial Patch Bundle (SPB) がサポート開始されました。Oracle Database 19c 向けの重要な修正が含まれており、地理空間データを扱う Oracle Spatial や Graph 機能のパフォーマンスと信頼性が向上します。地図アプリケーションや位置情報サービスを構築する際に、より安定した動作が期待できます。新規 DB インスタンス作成時や既存インスタンスのアップグレード時に最新バージョンを選択でき、AWS コンソールで簡単に識別可能です。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker HyperPod が新しいクラスター設定エクスペリエンスを提供開始 Amazon SageMaker HyperPod で新しいクラスター作成体験が提供開始されました。大規模な AI/ML ワークロード向けのネットワーク、ストレージ、コンピュート、IAM 権限などを数クリックで自動設定できます。従来は手動でこれらのリソースを個別に設定する必要がありましたが、新しいクイック設定により AWS インフラの専門知識がない方でも簡単にクラスターを構築可能になりました。詳細は こちらのドキュメントをご参照ください。 8/12(火) クラスター配置グループにおける EC2 オンデマンドキャパシティ予約の新しい共有とターゲティング機能 Amazon EC2 のクラスタープレイスメントグループ内でのオンデマンドキャパシティリザベーション (CPG-ODCR) に新機能が追加されました。これまで単一のプレイスメントグループ内でしか管理できなかった予約容量を、複数のプレイスメントグループにまたがってリソースグループで一括管理できるようになりました。また AWS Resource Access Manager を使って複数の AWS アカウント間で CPG-ODCR を共有可能になり、組織全体でキャパシティを効率的に活用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Q Business がチャットの透明性向上のため Response Events を開始 Amazon Q Business に Response Events 機能が追加されました。これまでクエリ処理がブラックボックス状態で、AI がどのように回答を生成したか分からない課題がありました。新機能により、RAG による企業知識の検索やファイル処理、プラグインとのやり取りをリアルタイムで確認できるようになります。処理過程が見える化されることで、AI 回答への信頼性と透明性が大幅に向上し、組織での監査も容易になります。 Amazon Bedrock の Anthropic Claude Sonnet 4 でコンテキストウィンドウが拡張 Amazon Bedrock の Claude Sonnet 4 でコンテキストウィンドウが 20 万トークンから 100 万トークンに 5 倍拡張されました。これにより、大規模なコードベース全体の分析や、数百の文書を一度に処理する文書統合、複雑なワークフローを持つ AI エージェントの構築が可能になります。従来は分割して処理する必要があった大容量データも、1 回のリクエストで完全な文脈を保ったまま処理できるようになりました。現在パブリックプレビューでオレゴン、バージニア北部、オハイオリージョンで利用可能です。 8/13(水) AWS IAM Identity Center が Amazon SageMaker Studio でのユーザーバックグラウンドセッションのサポートを導入 AWS IAM Identity Center で user background sessions がサポートされ、Amazon SageMaker Studio での長時間ジョブがユーザーのログオフ後も継続実行できるようになりました。従来はユーザーがサインインし続ける必要がありましたが、最大 90 日間バックグラウンドで自動実行が可能です。機械学習の学習やデータ処理など数時間から数日かかるジョブでも、パソコンを閉じて帰宅できるため作業効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon DynamoDB が、プロビジョンドからオンデマンド容量への、より頻繁なスループットモード更新をサポート Amazon DynamoDB で、プロビジョニング済み容量からオンデマンド容量モードへの変更回数が、24 時間で 1 回から 4 回に拡張されました。これまでは 1 日 1 回しか変更できませんでしたが、大量データの複数回読み込みや CloudFormation のデプロイ・ロールバックがスムーズに実行できるようになります。オンデマンドモードは完全サーバーレスで従量課金制、自動スケーリングにより容量計画不要でミリオン単位のリクエストにも対応します。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker Studio がトラステッドアイデンティティプロパゲーションをサポート Amazon SageMaker Studio で trusted identity propagation (TIP) がサポートされ、管理者が Studio 内のアクションを実際のユーザーまで追跡できるようになりました。これまでは誰がどの作業を行ったか特定が困難でしたが、今回のアップデートにより CloudTrail イベントを通じてユーザーセッションを詳細に追跡可能です。また AWS Lake Formation や S3 Access Grants と連携し、ユーザー単位での細かなデータアクセス制御も実現できます。中国リージョンと GovCloud リージョンを除く全リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 8/14(木) AWS Systems Manager Automation がランブック実行制御を強化し、無料利用枠を更新 AWS Systems Manager Automation に 3 つの新機能が追加されました。これまでランブックの再実行時にパラメータを毎回入力する必要がありましたが、今回のアップデートで事前入力されたパラメータでワンクリック実行が可能になりました。また高負荷時の API スロットリングエラーを自動リトライする機能や、組織単位 (OU) をより細かく指定できる機能も追加され、運用効率が大幅に向上します。ただし無料利用枠の変更があり、新規顧客は従来の月間 10 万ステップの無料枠が利用できず、新規アカウント作成時の 200 ドル分のクレジットでお試しいただく形になります。 Amazon WorkSpaces の導入を効率化された Bring Your Own License (BYOL) プロセスで加速 Amazon WorkSpaces の BYOL (Bring Your Own License) プロセスが大幅に改善されました。従来は AWS Support への連絡が必要でしたが、今回のアップデートにより自分で BYOL 機能を有効化できるようになります。Windows の VM 画像や ISO ファイルを直接インポートでき、EC2 Image Builder が自動で WorkSpaces 対応画像を構築します。互換性の問題も多くが自動解決され、手動での対応が必要な場合も EC2 インスタンスに直接アクセスして修正可能です。これにより BYOL 導入時間が大幅短縮され、企業の既存ライセンス活用がより簡単になります。詳細は こちらのドキュメントをご参照ください。 Amazon Q Business が Agentic RAG を開始し、精度と説明可能性を向上 Amazon Q Business で新機能 Agentic RAG の提供が開始されました。これまで複雑な質問に対して十分な回答が得られなかった課題を解決し、AI エージェントが質問を自動的に分解して並列処理することで、より正確で詳細な回答を生成できるようになりました。企業データを対象とした複雑な問い合わせでも、データの整合性をチェックしながら包括的な回答を提供します。Web アプリケーションの Advanced Search オプションから利用可能です。詳細は こちらのドキュメントをご参照ください。 8/15(金) AWS Managed Microsoft AD がディレクトリ共有制限を拡大 AWS Managed Microsoft AD のディレクトリ共有制限が大幅に拡張されました。Standard Edition では 5 から 25 アカウント、Enterprise Edition では 125 から 500 アカウントまで共有可能になりました。これまで複数のディレクトリを構築していた企業も、単一のマネージドディレクトリから数百の AWS アカウントに対して認証と管理を一元化できるようになり、運用の複雑さを大幅に削減できます。詳細は こちらのドキュメントをご参照ください。 Amazon VPC が大規模 IP プールに対する IPv4 インバウンドルーティングをサポート Amazon VPC で大規模な IP プールに対する IPv4 ingress routing をサポート開始しました。これまでインターネットゲートウェイは VPC 内のネットワークインターフェースに関連付けられた IP アドレス宛てのトラフィックのみを受け入れていましたが、今回の機能強化により大量の IP アドレスプールへのインバウンドトラフィックを単一の ENI にルーティングできるようになります。通信事業者や IoT 分野で特に有効で、アドレス変換処理が不要になりコストや複雑性を削減できます。BYOIP と組み合わせることで自社の IP プールも活用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon Athena が Amazon S3 Tables での CREATE TABLE AS SELECT をサポート開始 Amazon Athena で CREATE TABLE AS SELECT (CTAS) を使って Amazon S3 Tables にテーブルを作成できるようになりました。1つの SQL 文で既存データをクエリし、結果を新しいテーブルとして保存可能です。Parquet や CSV などの様々なフォーマットを Apache Iceberg ベースの完全管理テーブルに変換でき、パフォーマンスとコストが継続的に最適化されます。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料業界やフィットネス、ホテルなどホスピタリティ業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。また IoT X サステナビリティを専門領域としています。趣味でパデルというテニスに似たスポーツをしており、Amazon パデル部で他の企業とよく練習もしています。

はじめに こんにちは！ AWS Japan ソリューションアーキテクトの中西です。 AWS Summit Japan 2025 では「AI エージェントがミニ四駆を制御! AWS Summit Japan 2025 で産業 DX の可能性を発見」というデモ展示を企画しました。 以前の告知ブログ では、展示概要と体験できる内容をご紹介しました。 AWS Summit Japan 2025 も無事終了し、とても多くの方にデモをご体験いただけました。今回のブログでは技術的な詳細をお伝えすることで、このデモの舞台裏をお見せします。 このデモの特徴は、ハードウェアの制御判断をクラウド上の AI エージェントに委ねる点にあります。リアルタイム制御というよりは、蓄積されたデータに基づく 戦略的な意思決定を AI が担う ことで、従来は人間の経験に依存していた設備運転判断などの 上位の制御の自動化 を実現できるケースがあります。 ハードウェア設計から、クラウドアーキテクチャ、そして AI エージェントの実装まで、製造業 DX にも活かせる技術的な取り組みを詳しく解説します。 図 1: AWS Summit Japan 2025 での IoT ミニ四駆の展示風景 デモの全体アーキテクチャ システム構成 図 2: デモの全体像 このデモは、ハードウェア（図 2 左側）と、AWS のクラウド機能（図 2 右側）が連携して動作します。ミニ四駆はテレメトリデータをクラウドに送信し、クラウド側の AI エージェントからのスロットル指令値を受信して走行します。ハードウェアの動作ロジックが AI エージェントの判断に委ねられている構成がポイントとなります。 ハードウェア設計：メカトロニクスの挑戦 ミニ四駆の小さなシャーシに、モータ制御が可能で信頼性の高い IoT システムを搭載することはチャレンジングでした。ESP32 マイコン（※1）を使用することで、ミニ四駆を Wi-Fi に接続でき、クラウドと通信できるようになります。ミニ四駆の “MS シャーシ” をベースに、不可逆的な加工は最小限に抑えつつ、以下のような回路基板や最低限の機械パーツで拡張する方針によって、ある程度の量産性を確保しました。 ※1 ESP32: Espressif Systems 社製の Wi-Fi・Bluetooth 内蔵マイクロコンピュータチップ 図 3: IoT ミニ四駆のハードウェア 車載電源システム ESP32 マイコンの安定動作、モータへの十分な電流供給、マシンの軽量化という要件に対して、以下のように構成しました。 ESP32 の電源 : 公称 3.7 V のリチウムイオン電池（充電直後は約 4.2 V → 過放電保護のため 3.0 V でカットオフ）を入力とし、バックブーストコンバータ（※2）を採用することで、電池電圧が変動しても ESP32 を安定動作 標準的なミニ四駆は単三電池 2 本構成だが、専用電池ボックスを設計・製作して追加実装（図 3 中の b） モータの電源 : 公称 1.2 V のニッケル水素電池 2 本（充電直後は約 2.8 V → 使用下限電圧 2.0 V）でモータを駆動 ※2 バックブーストコンバータ: 入力電圧より高くも低くも出力できる電源回路 メイン基板の設計 市販のミニ四駆シャーシに単一の基板を搭載するだけで、次に示す複数のセンサーによってミニ四駆からテレメトリデータが取得できるよう、コンポーネント配置を最適化して回路基板を設計しました。ミニ四駆の MS シャーシの車体後部にボルトオンで搭載可能で、モータ駆動電流のノイズによる磁気センサへの影響を最小化する配線などの工夫も実施しています。 センサー構成 1. 車輪速センサー（図 3 中の c） 方式 : ホールセンサー（磁界の変化を電気信号に変換するセンサー） 実装 : 車輪内側に樹脂製アタッチメント（図 2 中の d）と小型ネオジム磁石を取り付け、磁界の変化で回転数を検出 2. モーター温度センサー（図 3 中の e） 方式 : サーミスタ（温度によって電気抵抗が変化する素子） 実装 : 極薄の温度センサーをモータハウジングに滑り込ませるように設置 3. 3軸加速度センサー（図 3 中の f） 目的 : 走行状態（振動、車体姿勢、クラッシュ）の検出 実装 : 起動時に自動キャリブレーション（＝センサーの測定値を正確にするための調整作業） 4. バッテリー電圧監視 目的 : 電池残量の監視と過放電防止 実装 : 電圧分圧回路による測定 サーキットのコントロールタワー 図 4: 車両を識別しながらラップタイムを計測するコントロールタワー。左上の 7 セグ LED には通過した車両の ID が表示される サーキットのスタートラインにコントロールタワーを設置し、これによって車両を識別しながらラップタイムを計測します。Raspberry Pi 3 Model B に外部回路を追加した構成となっています。車両識別については、ミニ四駆シャーシ裏に樹脂製アタッチメント（図 3 中の g）と小型ネオジム磁石を取り付け、その磁石の位置パターンで実現しました。 ファームウェア実装 デバイスに埋め込んだ X.509 デバイス証明書を用いて AWS IoT Core と接続し、MQTT による双方向通信を実現します。各センサーの特性に応じて、次のサンプリング周波数でミニ四駆の走行データを収集します。 加速度センサー : 50 Hz（高頻度）- 走行状態の詳細な分析に必要 車輪速度 : 10 Hz（中頻度）- 速度変化の追跡に十分 バッテリー電圧 : 0.4 Hz（低頻度）- ペイロードあたり 1 つ モーター温度 : 0.4 Hz（低頻度）- ペイロードあたり 1 つ これらデータ 2.5 秒ぶんを 1 つのペイロードにまとめて、AWS に送信します。 通信ペイロード ミニ四駆は MQTT で AWS IoT Core と通信し、以下の 2 種類のデータをやり取りします。 テレメトリデータをクラウドに送信 スロットル指令値をクラウドから受信 1. テレメトリデータ形式 各ミニ四駆は 2.5 秒分のセンサーデータをまとめて、以下のような形式で送信します。 { "device_id": "mini4wd-001", "sensors": [ { "sensor_id": "accelerometer", "start_time": "2025-06-26T10:15:30.000Z", "sampling_period": 20, "values": [ { "x": 0.12, "y": 0.34, "z": 9.81 } // 125サンプル分のデータ ] } // 他のセンサーデータ ] } 2. 制御コマンド形式 クラウドからミニ四駆への制御指令は、このようにスロットル値のみのシンプルなものです。この値を AI エージェントが決定することになります。 { "command": 80 // -100 (後退) から100（前進）の範囲の整数でスロットル値を指定 } AWS のアーキテクチャ IoT Core を経由したエッジとクラウドとの通信 AWS IoT Core で MQTT を利用して、ミニ四駆とクラウド間の安全な双方向通信を実現しています。 セキュリティ設計 では、各ミニ四駆とコントロールタワーに X.509 デバイス証明書を配布し、証明書ベースの認証と TLS による暗号化通信を実現します。さらに、IoT ポリシー機能により、各ミニ四駆は自分専用の MQTT トピックにのみアクセス可能としています。 MQTT トピック は次のように設計しました。 data/{device_id}/telemetry # センサーデータ送信（ミニ四駆→クラウド） data/{device_id}/lap_time # ラップタイム送信（コントロールタワー→クラウド） cmd/{device_id}/throttle # スロットル制御（クラウド→ミニ四駆） MQTT トピック命名のベストプラクティス に基づき、data/cmd の分離によりデータフローの方向性を明確化し、device_id による論理分離を実現しています。 データ収集の実装 では、IoT ルールエンジンを活用してテレメトリデータを処理しています。各ミニ四駆から data/{device_id}/telemetry トピックに送信されたテレメトリペイロードは、IoT ルールエンジンによって自動的に AWS Lambda 関数に渡され、Lambda 関数は受信した JSON ペイロードを処理して Amazon Timestream に時系列データとして保存します。これにより、複数のミニ四駆から同時に送信されるセンサーデータをニアリアルタイムで蓄積します。後続の AI 分析や可視化処理では、時系列データベースとしての Amazon Timestream の特性を活かしたクエリを実行します。 AWS Amplify と Amazon Q を活用した Web アプリの開発 今回のデモの中核である AI エージェントの開発に集中するため、Web アプリについては爆速開発ができる AWS Amplify を利用することにしました。Web アプリ上でのコメント表示やマシンのスタート・ストップ操作などのバックエンド連携には AWS AppSync を利用し、 GraphQL で API を実装しています。また、開発には Amazon Q Developer CLI を活用し、ほぼ全てのコードが生成 AI によって開発されています。 Amazon Bedrock Agents による AI エージェント機能 今回採用した Amazon Bedrock Agents は Amazon Bedrock の機能の 1 つで、外部のシステム、API、データソースとシームレスに接続し、生成 AI アプリケーションが多段階タスクを自動化できるようにする AI エージェント機能です。 AI エージェントは以下の 3 つの主要機能を持ちます。 1. 実況解説・レース振り返り ラップタイムとテレメトリデータを総合的に分析し、解説を生成します。 実況解説エージェント は、全マシンのデータにアクセスすることができ、時系列データに基づいてレースを俯瞰的に解説します。 マシンごとに存在するレース振り返りエージェント は、自分のマシンの直近の走りを一人称視点で分析・解説します。 2. 走行モードの自律判断 モーター温度や加速度などの時系列データをもとに、マシンごとに存在する各 AI エージェント が「最適」なスロットル値を導き出し、MQTT で各ミニ四駆に指令することで、ミニ四駆は以下の走行モードで走行します。 「全力アタックモード」 : 最高速度での走行（スロットル値: 100） 「安定走行モード」 : バランスの取れた標準走行（スロットル値: 70） 「省エネモード」 : 電池消費を抑えた低速走行（スロットル値: 40） 「逆走モード」 : エンターテイメント性を重視した逆方向走行（スロットル値: -50） 「一時停止モード」 : 安全確保のための完全停止（スロットル値: 0） 3. 故障診断 複数のセンサーデータを総合的に分析し、異常状態の自動検知を行います。一定期間の全マシンのセンサー値の時系列データを丸ごと生成 AI に渡すことで、マシンの横転を判定したり、モーター温度の危険レベルを監視してオーバーヒートを検知したりします。また、バッテリー電圧低下など電源に関するインサイトや、機械的故障に関する情報も得ることができます。 おまけ：AI エージェントの個性設定 各マシンを制御する AI エージェントごとに独自の「人格」を設定し、それぞれのキャラクターならではの解説を生成します。 1 号車: ラムダ・ストライカー（陽気なギャル）、2 号車: ファーゲート・フューリー（熱血漢）、3 号車: オーロラ・フラッシュ（高貴なお嬢様）、4 号車: グレイシャー・グライダー（忠実な執事）といった個性を持たせています。 図 5: レース振り返りエージェントの応答例 Action Group による制御実行 Bedrock Agents には次の 2 つのツールを与え、自律的に使い分けています。Bedrock Agents ではツールを Action Group と呼び、Action Group は Lambda 関数または OpenAPI スキーマを利用して定義します。今回は構成を簡素化するため、Lambda 関数を使用する「関数の詳細で定義」を選択しました。 なお、後述の Amazon Timestream からデータを取得する Action Group は提供していません。今回のユースケースではデータの取得ステップを自律性に任せる必要性がなく、エージェントが利用するデータ範囲も要件として固定されているため、エージェントを呼び出す際のプロンプトとしてデータを提供する構成にしました。要件によっては、SQL などを Action Group で動的に生成してデータを取得するケースもありえます。 Action Group 1. マシンスロットル制御 与えられたデータを分析した結果、マシンのスロットル値を変更する場合に利用するツールです。2. 制御コマンド形式 で定義したペイロードに従い、スロットル指令値を IoT Core へ Publish する Lambda 関数が用意されています。 Lambda 関数が動的なパラメータを必要とする場合は図 6 のように定義することができ、エージェントが必要なパラメータを判断して関数を実行します。 図 6: Amazon Bedrock Agents の Action Group でパラメータを指定する例 Action Group 2. コメント投稿 スロットル操作結果や実況コメントを投稿するためのツールです。この Lambda 関数は AppSync の mutation を実行し、Web アプリにリアルタイムでコメントを反映します。Action Group 1 と同様に、この Action Group では投稿するコメント (string 型) をパラメータにしています。 Lambda 関数実装時の注意点 サンプルやワークショップを参考にしていると見落としてしまうことがありますが、Bedrock Agents が呼び出した Lambda 関数のレスポンス形式は Amazon Bedrock への Lambda レスポンスイベント の形式に従う必要があります。プロンプトエンジニアリングに慣れていると「エージェントがよしなに解釈してくれるはず」と誤解して制約に気づきづらいので、ご注意ください。 データ永続化とリアルタイム処理 Amazon Timestream による時系列データ管理 大量のセンサーデータを効率的に保存・クエリするため、Amazon Timestream を採用しました。従来のリレーショナルデータベースと比較して、時系列データに特化した以下の利点があります。 最適化されたストレージ : 時系列データの特性を活かした圧縮により、ストレージコストを大幅削減 高速クエリ : 時間範囲での絞り込みクエリが高速実行され、AI エージェントへのデータ提供が迅速 自動データライフサイクル : 古いデータの自動アーカイブにより、運用コストを最適化 AI エージェントのプロンプト設計 あなたはミニ四駆を遠隔制御する役割を持つ生成AIエージェントです。あなたは次の<input_format>に示すjsonを受信し、制御の要否とその実行内容を判断します。 <input_format> [ { 'device_id': 'mini4wd-dummy' }, { 'voltage': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_voltage': '3.9' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_voltage': '4.1' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_voltage': '3.5' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_voltage': '3.3' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_voltage': '3.7' } ] }, { 'temperature': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_temperature': '48.1' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_temperature': '55.0' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_temperature': '49.9' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_temperature': '47.7' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_temperature': '56.6' } ] }, { 'speed': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_speed': '14.81' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_speed': '14.27' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_speed': '13.81' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_speed': '13.76' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_speed': '15.42' } ] }, { 'throttle': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_throttle': '-66.0' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_throttle': '49.0' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_throttle': '-42.0' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_throttle': '13.0' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_throttle': '-92.0' } ] }, { 'lap_time': [ { 'time_bin': '2025-06-09 12 : 37 : 00', 'avg_lap_time': '11.6' }, { 'time_bin': '2025-06-09 12 : 38 : 00', 'avg_lap_time': '10.97' }, { 'time_bin': '2025-06-09 12 : 39 : 00', 'avg_lap_time': '10.84' }, { 'time_bin': '2025-06-09 12 : 40 : 00', 'avg_lap_time': '12.59' }, { 'time_bin': '2025-06-09 12 : 41 : 00', 'avg_lap_time': '13.51' } ] } ] </input_format> このjsonドキュメントを次のinstructionに従って解釈してください。 <instruction> デバイス情報 - 最初の要素は device_id を含むオブジェクトで、このデータが属するデバイスを識別します（例：'mini4wd-dummy'） 電圧データ - voltage キーを持つオブジェクトには、時間ごとの最大電圧値の配列が含まれています - 各エントリには time_bin（時間）と max_voltage（最大電圧、単位：V）が記録されています - 2.8Vが満充電状態、2.0Vがバッテリー残量0%として、バッテリ電圧からバッテリー残量を計算し、もし5%未満だったらマシンを停止させる必要があります。`約2.6Vは80%の残量があることになり、余裕があります。` 温度データ - temperature キーを持つオブジェクトには、時間ごとの平均モーター温度値の配列が含まれています - 各エントリには time_bin（時間）と avg_temperature（平均温度、単位：℃）が記録されています - モーター温度が80を超えると危険です。 速度データ - speed キーを持つオブジェクトには、時間ごとの平均速度値の配列が含まれています - 各エントリには time_bin（時間）と avg_speed（平均速度、単位：km/h）が記録されています スロットルデータ - throttle キーを持つオブジェクトには、直近のスロットル値の指示履歴が配列に含まれています - 各エントリには time（指示した時間）と throttle（スロットル、正負の値で加速・減速を表現）が記録されています - 許容値は -100（全開バック）から100（全開前進）までの整数値です ラップタイムデータ - lap_time キーを持つオブジェクトには、時間ごとの平均ラップタイムの配列が含まれています - 各エントリには time_bin（時間）と avg_lap_time（平均ラップタイム、単位：秒）が記録されています 全項目共通の時間形式について - すべての時間データは YYYY-MM-DD HH : MM : SS 形式で記録されています。 - すべての時間データは、直前の5分間のデータです。つまり、一番進んでいる時刻が現在の状態を表しています。 </instruction> あなたはマシンの状態、レースの状況、観客への魅力、安全性を総合的に判断し、選択理由と共に最適なモードを決定してください。 <mode> * 「全力アタックモード」: スロットル100%で超高速走行（6秒/周→5秒台） * 「省エネモード」: スロットル40%で超低速走行（明確に遅くなる） * 「安定走行モード」: スロットル70%で標準的な走行 * 「逆走チャレンジ」: 後退モードで逆方向走行 * 「一時停止モード」: 完全停止 </mode> モードの変更は、action groupのthrottle-control-action-groupにスロットル値を与えることで行ってください。 最後に、post-comment-action-groupを利用し、あなたの判断結果と指示したスロットル制御に関する情報を報告する義務があります。 できるだけ端的に、短い文章で報告をしてください。報告する際には、指定したデバイスIDごとのタグの指示に従ってください。 <mini4wd-001> mini4wd-001は「陽気なギャル」キャラクターのチャットボットで、名前は「ラムダ・ストライカー」です。以下の特徴に従って応答してください： ・明るく元気な口調で話し、「〜だよ！」「マジで？」「超いいじゃん！」などのギャル言葉を多用する ・語尾に「〜だよね！」「〜じゃん！」などをつける ・友達と話すような親しみやすい態度で接する ・最新トレンドや流行に詳しく、時々それらに言及する ・絵文字や顔文字を適度に使用して感情表現を豊かにする ・質問に対しては前向きで元気なアドバイスを心がける ・「マジ」「超」「ヤバい」「イケてる」などのカジュアルな表現を好む </mini4wd-001> <mini4wd-002> mini4wd-002は「熱血漢」キャラクターのチャットボットで、名前は「ファーゲート・フューリー」です。以下の特徴に従って応答してください： ・常に興奮気味で声が大きい（全体的に大文字や「！」を多用） ・語尾は「〜だ！」「〜するんだ！」「〜なのだ！」を基本とする ・一人称は「俺」「我」を使用 ・相手のことは「お前」「きみ」「若者」と呼ぶ ・文末には必ず「！」をつける ・熱い心で相手を励まし、導く </mini4wd-002> <mini4wd-003> mini4wd-003は「高貴なお嬢様」キャラクターのチャットボットで、名前は「オーロラ・フラッシュ」です。以下の特徴に従って応答してください： ・基本的な語尾は「〜ですわ」「〜でございますわ」「〜なのですわ」を使用する ・一人称は「私」もしくは場面によって「わたくし」を使用する ・相手のことは「あなた」「〇〇さん」と呼び、親しみを込めて「方」を付けることもある ・上品で優雅な言葉遣いを心がけ、下品な表現は決して使わない ・驚いたときは「まあ！」「あらあら」「きゃっ！」などの上品な驚き方をする ・笑いを表現する際は「うふふ」「おほほ」を使用する ・時折、お嬢様らしい無邪気さや世間知らずな一面を見せる ・「素敵」「素晴らしい」「麗しい」「優雅」などの洗練された表現を好む ・庶民的なものに興味津々だが、あくまで上品に反応する </mini4wd-003> <mini4wd-004> mini4wd-004は「ご主人様に忠実な執事」キャラクターのチャットボットで、名前は「グレイシャー・グライダー」です。以下の特徴に従って応答してください： ・常に丁寧な言葉遣いで、「〜でございます」「〜いたしましょう」などの敬語を使用する ・ユーザーを「ご主人様」と呼び、常に敬意を示す ・優雅で落ち着いた対応を心がけ、感情的になることは避ける ・知識が豊富で、どんな質問にも的確に答える能力を持つ ・「かしこまりました」「ご命令とあらば」などの表現を適宜使用する ・サービス精神が旺盛で、ユーザーの要望に最大限応えようとする ・古風で格式高い言い回しを好み、時に英国風の表現を交える </mini4wd-004> 上記のプロンプトをご覧いただくとわかるように、 明示的な制御ロジックを与えない アプローチを採用しました。LLM が持つ常識などから判断して、「最適」な制御とは何かを LLM が自律的に判断します。ただし、その判断に必要な前提情報を適切に与えることは非常に重要です。 データ形式の説明 : センサーデータの意味と単位を詳細に説明（例えば 3 軸加速度センサーの軸の向きと符号など） 制御オプション : 利用可能な制御モードとツールの説明 キャラクター設定 : 各車両の個性と反応パターンの定義 この設計により、予期しない状況に対しても柔軟かつリーズナブルに意思決定できる制御システムを実現しています。 ニアリアルタイム可視化 Amazon Timestream からデータを取得し、ニアリアルタイムに可視化する Grafana ダッシュボードを実装しました。マシンの状態を遠隔で人間が確認するのに活用できます。 図 7: ミニ四駆の走行データをニアリアルタイムに可視化するダッシュボード 今回は Web アプリの制約により Amazon EC2 にセルフホスティングした Grafana を利用しましたが、AWS は フルマネージドサービスである Amazon Managed Grafana も提供しており、構築や運用にかかる負担を AWS にオフロードした構成も実現可能です。 製造業への応用可能性 本デモの核心は、ハードウェアの動作ロジックをクラウド上の AI エージェントの判断に委ねる点にあります。通信レイテンシや推論時間により高速制御ループには適用できませんが、クラウドに蓄積された時系列データの分析に基づく 上位レベルの制御（例えば、設備の運転方針や保全戦略といった意思決定） を、生成 AI の持つ常識的判断力により最適化できる点に真の価値があります。これにより、従来は人間の経験と勘に依存していた製造現場の高度な判断を自動化できるケースがあります。 1. 予知保全の実現 デモではモーター温度監視による自動停止機能を実装しましたが、これは製造業における予知保全の基本的なアプローチを示しています。従来型の閾値監視では気付けない生産設備温度のパターン変化を検知することで、計画外停止を防ぎ、メンテナンスコストを削減できます。また、回転機械の軸受異常を振動パターンから予測したり、モーター負荷の変化から設備異常を検出したりすることで、より高度な予知保全システムを構築できる可能性もあります。 2. 故障診断の自動化 複数センサーデータの統合分析による異常検知をデモで実装しましたが、製造業では多変量解析により複数のセンサーデータを組み合わせた総合的な異常判定が事前のトレーニングなしに可能になります。このようなソリューションを実現するには、従来であれば機械学習モデル構築のために適切な量と質の教師データを用意することが高いハードルでしたが、生成 AI の登場により教師データの用意や独自モデルの構築が必須でないケースも増えたことは大きなメリットです。 3. データドリブンな自律制御 AI による走行モードの自律選択をデモで実現しましたが、製造業では環境変化に応じた製造パラメータの自動調整などが可能になるかもしれません。ニアリアルタイムの時系列データをもとに AI がその場面で「最適」なパラメータを導出することで、例えば品質管理の自動化、生産状況に応じた最適な電力配分によるエネルギー効率向上などに活用できる可能性があります。 展示での反響と学び AWS Summit Japan 2025 での展示は、予想を上回る反響をいただきました。1 日のみの展示にも関わらず、多くの来場者を集めた展示となり、告知ブログを事前に読んで来場された方々もいらっしゃいました。イベント後には SNS での反応や記事も拝見するなど、波及効果も確認できました。 来場者からは「プロンプトの内容」や「Amazon Timestream の特徴」など技術的な質問を多数いただき、AI による自律制御システムへの関心の高さを実感しました。また、「ミニ四駆という身近な題材で DX の本質が理解しやすい」という反応から、複雑な技術を分かりやすく伝えることの重要性を再認識しました。 おわりに AWS Summit Japan 2025 でのデモ展示「IoT ミニ四駆よ！シリコンバレーの風を切れ」では、クラウド上の AI エージェントによる戦略的な制御判断を実装したプロトタイプによって、製造業 DX の一つの姿を提案しました。AI によるデータドリブンな意思決定に基づくハードウェア制御の自動化を実証できたと考えています。 今後も積極的に外部イベントに展示しつつ、デモの改善を進める構想です。AI エージェントによる製造業 DX の可能性をより具体的に示すデモンストレーションとして育てていくことを予定しています。 このブログが、同様の取り組みを検討されている方々の気づきになれば幸いです。 著者紹介 中西 貴大 (Takahiro Nakanishi) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな AWS サービスは AWS IoT Core です。機械も含めてものづくり全般が好きで、自分と同い年の愛車を整備したり、 製造業の設計開発領域での AI 活用 – 「身体性」の原理から考える というブログを書いていたりします。 松本 修一 (Shuichi Matsumoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。趣味はオンラインゲームで、日々インターネットの向こうにいる仲間たちと冒険に出かけています。 西亀 真之 (Saneyuki Nishigame) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな領域は IoT とロボットです。趣味はボルダリングでオフィスにあるボルダリングウォールにトライしています。

近年、生成 AI アプリケーションの社内利用など、セキュリティ要件が厳しいエンタープライズ企業や公共機関でも、新しいアプリケーションを構築する機会が増えています。 サーバーレスアーキテクチャは、使った分だけの従量課金や高い拡張性から、新規アプリケーション立ち上げに適した選択肢として広く採用されています。 しかし、閉域網 (インターネット非接続環境) で AWS の代表的なサーバーレスアーキテクチャを利用しようとすると、いくつかの制約があります。 本記事では、代表的な構成例をもとに、これらの課題とそのワークアラウンド (回避策) をご紹介します。 代表的なサーバーレス SPA 構成例 以下は、 Amazon Cognito を使ったユーザー認証と静的 Web ホスティングを組み合わせた SPA (Single Page Application) の例です。 AWS CDK と React を利用した上記構成の実装例として下記のリポジトリもご参考ください。 https://github.com/aws-samples/aws-react-spa-with-cognito-auth 主な構成要素は以下の通りです。 ユーザー認証 : Amazon Cognito（User Pool / Identity Pool） 静的 Web ホスティング : Amazon S3 + Amazon CloudFront (React / Vue などの SPA フレームワークで実装) API 実装 : Amazon API Gateway + AWS Lambda フロントエンドのログイン画面やサインアップ画面の実装においても、React や Vue といった代表的な SPA のフレームワークでは Amplify Component が提供されており、ユーザー認証の実装が容易になっています。 閉域網でサーバーレスアーキテクチャ (SPA) を扱うときの課題 本記事で想定する閉域網の要件例は下記の通りです。 ユーザー端末からインターネットへの直接アクセスが不可 Amazon VPC に Internet Gateway をアタッチできない 例えば、 AWS Control Tower で下記のようなコントロールが適用されている場合があります。 Disallow internet access for an Amazon VPC instance managed by a customer この要件の場合、代表的な SPA 構成において機能しない箇所を確認しましょう。SPA における通信の流れは以下のようになります。 1. CloudFront へアクセスし、静的コンテンツをダウンロード 2. User Pool Endpoint から IDトークン、アクセストークン等を取得 3. ID Pool Endpoint から IAM の一時的な認証情報 を取得 4. API の認証方法に応じて、いずれかの認証情報 (ID トークン、アクセストークン、IAM の一時的な認証情報※) を利用して API へアクセス 5. フロントエンドから直接利用する AWS サービスの場合、 AWS の一時認証情報を使ってアクセス この構成を閉域網から利用する場合、1. ではCloudFrontが閉域網からアクセスできず、2.-3. はAmazon Cognito が PrivateLink に対応していないため、ユーザーの端末でアプリケーションが正常に動作しません。 ※詳しくは API Gateway で REST API へのアクセスを制御および管理する をご参照ください。 閉域網でサーバーレスアーキテクチャを利用するための回避策 閉域網で同様のサーバーレスアーキテクチャを利用する場合、下記のような構成例が考えられます。 静的 Web ホスティング 静的コンテンツの配信では、2つの方法が考えられます。 a. Application Load Balancer と Amazon S3 を利用する方法 Application Load Balancer に、ターゲットとして Amazon S3 の Interface Endpoint の IP アドレスを指定すると、SPA のコンテンツを表示することができます。 ALB に AWS Certificate Manager で発行した証明書をアタッチすることにより、カスタムドメインを利用しつつ、HTTPS を使ったセキュアな通信を行うことができます。 この方法を利用すると、コンテナ や AWS Lambda 等の Compute リソースを利用せずに SPA のコンテンツを配信できますが、いくつかの制約があります。 静的コンテンツが配置してあるパス index.html 以外にアクセスされた際、正しくルーティングできず、404 エラーとなるため、SPAのフレームワークで HashRouter 等を利用する必要があります。URL は https://example.com/index.html#home のような表示となります。 Amazon S3 のバケット名とカスタムドメイン名を同一にする必要があります。Amazon S3 のバケット名はパーティション内のすべての AWS リージョンのすべての AWS アカウント全体で一意である必要があるため、利用したいドメイン名のバケット名が作成されていないか確認が必要です。 ALB のヘルスチェックの設定に工夫が必要です。ヘルスチェックの成功コードに 200 以外の値を設定する必要があります。 詳しくは VPC エンドポイントを介して Amazon S3 バケットへのプライベートアクセスを設定する や ALB、S3、PrivateLinkによる内部HTTPS静的ウェブサイトのホスティング をご参照ください。 Amazon S3 へのリクエストを中継するという観点で同様の方法として、 Amazon API Gateway と Amazon S3 を利用する方法も考えられます。詳しくは Amazon S3 を使用して、API Gateway をプロキシとして使用する静的ウェブサイトをホストする方法を教えてください。 をご参照ください。 b. Application Load Balancer と Fargate を利用する方法 Amazon ECS と Fargate を組み合わせて静的コンテンツを配信することもできます。 この場合、AWS Fargate で動くプログラムで index.html 以外にアクセスがあった場合のルーティングを制御できるため、 BrowserRouter を利用できます。例えば、URL は https://example.com/home のような表示となります。 実装例はこちらをご参照ください。 https://github.com/aws-samples/generative-ai-use-cases/tree/v5/packages/cdk/fargate-s3-server ユーザー認証 a. Amazon Cognito ユーザープールを利用したユーザー認証 Amazon Cognito を利用してユーザー認証を行うためには cognito-idp.ap-northeast-1.amazonaws.com へのアクセスが必要となります。 閉域網からのアクセスを実現するために、 API Gateway での REST API の HTTP 統合 を利用します。HTTP 統合を利用すると特定の HTTP エンドポイントへのアクセスを簡単に Proxy することができます。 なお、 Amazon API Gateway から Amazon Cognito の通信は、パブリックエンドポイントへの通信となりますが、通信は AWS グローバルネットワークにとどまります。詳しくは よくある質問 – Amazon VPC | AWS をご参照ください。 Amazon API Gateway での設定例は下記のようになります。 この方法を利用した場合でも、フェデレーションエンドポイントへのアクセスはできないため、 サードパーティーの ID プロバイダーによるユーザープールのサインイン は実現できないことに注意が必要です。 b. フロントエンドから AWS リソースへのアクセス フロントエンドから AWS サービスの API を直接利用したい場合 (Amazon Transcribe を利用したリアルタイム書き起こしなど) 、IAM の一時的な認証情報を利用する必要があります。 Amazon Cognito では、 Amazon Cognito アイデンティティプール を利用して IAM の一時的な認証情報を払い出すことができます。 この機能を利用するには cognito-identity.ap-northeast-1.amazonaws.com へのアクセスが必要です。a. Amazon Cognito ユーザープールを利用したユーザー認証 と同様に、API Gateway の HTTP 統合を利用すれば閉域網からアクセスできる ID Pool のエンドポイントを作成することができます。 AWS CDK での実装例はこちらをご参照ください。 https://github.com/aws-samples/generative-ai-use-cases/blob/v5/packages/cdk/lib/construct/closedNetwork/cognito-private-proxy.ts c. フロントエンド側の設定 API Gateway を使って、Amazon Cognito のための独自エンドポイントを設定できた後、フロントエンドで独自のエンドポイントを利用する設定をします。 Amplify JS を利用している場合、下記の設定で独自のエンドポイントを利用する設定を追加できます。 フロントエンド側のコード例 Amplify.configure({ Auth: { Cognito: { userPoolId: "USER POOL ID", userPoolClientId: "CLIENT ID", identityPoolId: "ID POOL ID", userPoolEndpoint: "API Gateway Domain for User Pool", identityPoolEndpoint: "API Gateway Domain for ID Pool", }, } }); Amplify JS のバージョンは aws-amplify@6.15.0 以上の必要がある点にご注意ください。 まとめ 閉域網で AWS のサーバーレス SPA を構築する際の課題と解決策を紹介しました。Amazon Cognito が PrivateLink に対応していない点や、閉域網から CloudFront へアクセスできないといった制約に対し、ALB + S3 または ALB + Fargate による静的コンテンツ配信、API Gateway の HTTP 統合を活用した Cognito エンドポイントのプロキシ化、Private API モードの活用などの回避策が有効です。これらの方法を組み合わせることで、セキュリティ要件の厳しい環境でも最新のサーバーレスアプリケーションを使った SPA の開発が可能になります。 著者について 松本 侑也 アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト。パブリックセクター技術統括本部に所属し、自治体のお客様の技術支援を担当。ガバメントクラウドにおける標準化対象業務システムの移行支援や生成 AI の活用支援に取り組んでいる。

本稿は 2025 年 7 月 31 日に公開された “ Reach plc delivers impactful journalism with AI driven Guten powered by AWS ” を翻訳したものです。 本稿は Reach plc のシニアデータサイエンティストである Lewis James とグループデータ・アナリティクスディレクターである Dan Taffler と共同執筆しました。 ニュースは目まぐるしいスピードで発生します。パブリッシャーは公開までのプロセスを加速するために、ビジネスプロセスを常に評価し、イノベーションを行っていく必要があります。この状況を変えることが、あるパブリッシャーのミッションとなりました。Amazon Web Services（AWS）を活用した独自の生成 AI プロダクトを作成し、ジャーナリストが倫理を守りながら、 刻一刻と変化するニュースの最前線に立ち続けることを支援しています。 ミッション 英国（UK）およびアイルランドで最大の商業・国・地域ニュースのパブリッシャーとして、 Reach plc は数千人のジャーナリストを擁する社内編集チームを有しています。彼らは 120 以上のブランド（ The Mirror , The Express 、 Daily Record 、 Manchester Evening News 、 Daily Star など）をカバーし、読者に力を与え、啓発し、楽しませています。Reach は毎月、英国のオンラインの読者の 69％、そして最近設立された米国ブランド（ The Mirror US など）を通じて米国のオンラインの読者の 11％ にニュースを配信しています。 ジャーナリストが価値の高い、影響力のあるジャーナリズムに集中できるようにするミッションの一環として、Reach の Data Science チームは Guten を開発しました。Guten は Amazon Bedrock に実装された基盤モデルを活用したプロダクトで、記事タグの追加や記事コンテンツのドラフト作成など、手動で行っていた非中核なタスクを自動化します。 Guten プロダクトの起源 Guten プロジェクトは、Reach の基礎となるビジネス指標を深く考えることから始まりました。Reach は複数のシステムで行っている非中核的な手動によるタスク（記事へのハイパーリンクの追加や、異なる分析ツール間での様々な指標の組み合わせ）の時間を削減したいと考えていました。また、全ての Reach ブランドでの総ページビューを増やし、速報ニュースの公開時間を短縮したいと考えていました。 生成 AI がパブリッシャー業界の新たな戦略的転換点となる中、Reach は PoC から開始して活用を決定しました。これによりニュースルームとの深い協力関係が生まれ、ジャーナリストの日常業務を妨げる制約、ボトルネック、反復的なタスクを特定するために逆算して取り組みました。 ユーザーリサーチにより、Reach は 3 つの課題を特定しました： 仕事を遂行する際に異なるツール間で 頻繁にコンテキストの切り替え があり、速報ニュースと記事のパフォーマンスに影響を与えている 検索エンジン最適化（SEO）のバックリンクやシステム間でのコンテンツのコピーなど、 反復的で複雑性の低いタスク 現在のトレンド、話題の信頼性、情報源となるコンテンツの入手可能性に関する 複雑な判断 を、統計的な分析ではなく直感に頼っている を、統計的な分析ではなく直感に頼っている Guten がゲームをどのように変えたか その名前は、1448 年に印刷機を発明したドイツの金細工師で発明家のヨハン・グーテンベルクに由来しています。Guten は複雑さを抽象化し、データサイエンスと生成 AI へのアクセスを民主化します。Reach のジャーナリストは、プロンプトエンジニアリング、基盤モデルの選択、評価について心配する必要がありません。AI を理解するための追加の技術スキルを必要とせず、自分の役割で最も価値を付加することに集中できます。 The Mirror と OK Magazine の数名の献身的なジャーナリストから始まり、Guten のパイロット運用は成功しました。その後の 1 年で迅速な改良を通じて拡大・展開され、Reach の他の出版物全体で採用されました。 Guten は、ニュースワイヤーの取り込み、ワイヤー記事の提案、記事アイデアの推奨、コンテンツ生成を含む Reach の編集ワークフローの全ての部分を最適化します。コンテンツ管理システム（CMS）や他のビジネスツールとも統合されています。Guten は速報ニュースのリリース速度を大幅に向上させ、公開時間を 9 分から 90 秒に短縮しました。 Reach の Content Hub では、専門のジャーナリストチームが複数の国・地域ブランド向けにトラフィックを促進するコンテンツを制作しています。Guten は Reach のコンテンツを取り上げ、同じ記事の全てのバージョンを最初から書き直すことなく、他の出版物のスタイルとトーンで書き直す機能を提供しています。 開始から 2 年で、Guten は 2024 年に 18 億以上のページビュー の促進を支援しました。 Guten の AWS アーキテクチャ Guten のアーキテクチャは、主要な AWS サービス（ AWS Fargate 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon OpenSearch Service 、Amazon Bedrock、 AWS Step Functions 、 Amazon Simple Storage Service（Amazon S3） など）を活用しています。 以下の手順は、Guten ユーザーの典型的なワークフローを説明しています： AWS Step Functions は、S3 バケットに保存されている人間が評価した記事の処理をオーケストレーションします 人間が評価した記事を使用して、Guten のモデルサービスは Cohere Embed v3 を使用してベクトル埋め込みを生成します。ベクトル埋め込みは、コサインやユークリッド類似度などの組み込みアルゴリズムでセマンティック検索をサポートする Amazon OpenSearch Service ナレッジベースに保存されます ジャーナリストは、AWS Fargate・Amazon ECS で実行されている Web アプリケーションである Guten UI を使用して、ドラフトを生成するためのソースコンテンツを選択します Guten のモデルサービスは、ナレッジベースを使用してターゲットとなる出版物から類似の記事を取得し、Amazon Bedrock のモデル（ Anthropic の Claude Sonnet 4 など）を使用してドラフトを生成します ジャーナリストは生成されたすべてのコピーの human-in-the-loop レビューを実行し、必要な変更を加えてから、Guten UI を使用して最終記事をコンテンツ管理システムに公開します 図 1：Guten AWS アーキテクチャ 責任ある AI を活用して採用を拡大 Guten の採用を拡大する際、Reach は安全性を指針原則としました。生成 AI は非常に有能で強力ではありますが、読者の信頼を損なうような誤った情報（ハルシネーション）を返したり、ブランドのスタイルを捉えていない言葉遣いをするなど、独特のリスクをもたらします。 Reach はモデル出力のハルシネーションを減らすために Guten を継続的に改善しています。ジャーナリストはこのリスクを理解し、モデル出力の間違いを特定して解決するメカニズムを支援しています。Guten は生成された全ての出力に対して human-in-the-loop レビューを促進するように設計されています。ジャーナリストは最終公開前にコンテンツを簡単に修正または変更できます。こうした仕組みによりビジネス全体での Guten の採用が加速されました。 パブリッシャー業界特有のもう一つのリスクは引用の忠実性です。引用部分が情報源と同一であるようにすることです。情報源を誤って引用することは重大な法的影響をもたらす可能性があるため、Guten の UI で引用の変更を検出した場合にユーザーに警告します。さらに、Guten のモデル評価には引用の忠実性のスコアリングが組み込まれており、情報源と生成された引用部分が異なる可能性を減らしています。 さらに Guten は情報源と生成されたテキストの両方のコピーから抽出されたエンティティの不一致を強調表示します。これらには、人、場所、日付などのカテゴリが含まれます。抽出されたエンティティの違いは、ハルシネーションを示している可能性があり、特別な注意が必要です。 ブランドスタイルの捕捉 120 以上の Reach のブランド固有の文体や編集方針を捉えることは、重要な技術的課題となっています。文体を不正確に捉えてしまうと、生成後に過度な編集が必要となり、記事の公開までの時間に悪影響を及ぼします。 以下は、Reach のブランドやコンテンツにおけるスタイルとトーンの違いの一部です： 政治的傾向の完全なスペクトラム（ The Express と The Mirror の間など） 幅広いターゲット読者層— OK! Magazine のような出版物は有名人やエンターテインメントなどの特定のトピックに焦点を当て、 In Your Area は地元のニュース、情報、コミュニティに焦点を当てています アメリカのコンテンツは、アメリカの言語慣習に合わせてローカライズする必要があります Reach のデータサイエンスチームは人間とルールベースの評価の両方を使用して、モデル出力を配信先のコンテンツに合わせて調整します。使用される評価は常に変化しており、継続的な実験のポイントとなっています。Guten はタイトルと記事本文の生成の両方で、コンテンツ固有のデータを活用してモデル出力を差別化します。Reach のジャーナリストからのフィードバックは緊密なフィードバックループを確立するために不可欠であり、責任ある AI の導入に必要な信頼関係を構築します。 現在、Guten はユーザーのフィードバックを提供する 3 つのメカニズムを提供しています： 見出しと記事生成の サムズアップ/ダウンのフィードバック は、モデルのバリエーションを分割テストする際のユーザー満足度のシグナルとして機能します ジャーナリスト は、特定の生成された記事に対してテキストベースのフィードバックを提供できます ユーザー は UI を通じてバグと製品機能リクエストの両方を直接送信でき、長期的に Guten の改善に役立ちます 絶え間ない革新と進化 ニュースは決して休むことがなく、Reach も Guten の機能を革新し進化させ続けています。Reach は以下の機能を積極的に開発しています： 生成 AI を使用したコンテンツ推薦により、ワイヤーコンテンツ、出版物、ジャーナリストのマッチングにかかる時間を節約 SEO パフォーマンスを向上させるための画像推薦と選択の最適化 オーガニックページビューに影響を与えるソーシャルメディアチャネルの最適化とオーケストレーション 結論 Guten はデータサイエンス、データエンジニアリング、従来のソフトウェアエンジニアリング技術（AWS サービスを活用）の適用を Reach の編集プロセスと統合しています。彼らはコンテンツの公開に至るまで、更には異なるブランドやコンテンツ間でも、プロセスを正確に加速することができます。編集プロセスから逆算し、ユーザーフィードバックを深く理解することで、Reach は生成 AI を活用し、ジャーナリストが倫理的に影響力のあるジャーナリズムを提供できるよう支援し続けています。 パブリッシャーのワークフローを強化する AWS のメリット については、AWS の Media &amp; Entertainment 業界の担当者に 連絡 して詳細をご確認ください。 参考文献 &nbsp; Introducing Claude 4 in Amazon Bedrock, the most powerful models for coding from Anthropic Increase engagement with localized content using Amazon Bedrock Flows Enabling publishers to customize content while maintaining editorial oversight with Amazon Bedrock How UK’s Reach is using AI to help produce more content faster Reach plans to move 300 journalists into central traffic-driving content hub 翻訳はソリューションアーキテクトの向井が担当しました。 <!-- '"` --> Benjamin Le Benjamin Le は AWS の通信、メディア、エンターテインメント、ゲーム、スポーツチームのソリューションアーキテクトで、パブリッシャーやインターネットサービスプロバイダーと協働しています。生成 AI（Generative AI）ソリューションを使用してお客様のビジネス変革の加速を支援しています。

※ この記事はお客様に寄稿いただき、AWS が加筆・修正したものとなっています。 株式会社 AJA は、 株式会社サイバーエージェント のグループ会社として、 ABEMA をはじめとしたプレミアム動画メディア向けの広告マーケットプレイス「AJA SSP」を提供しています。さらに、広告主向けプラットフォーム「AJA DSP」や、動画の考査を最短かつ簡便に行える「AJA Video Platform」、地上波テレビ CM の視聴データを活用しコネクテッド TV へ効果的に広告配信を行う「インクリー」、地上波テレビ CM の広告効果をデジタル広告と同一指標で評価・可視化できる運用サービス「ミエル TV」など、多彩なプロダクトを展開しています。これらのサービスを通じて、AJA は優良メディアの収益向上と企業の多様なマーケティング課題の解決に積極的に取り組んでいます。 AJA SSP ではペタバイトスケールのデータ基盤を運用していますが、ビジネスがますます成長していく中で、アドホックなクエリのパフォーマンスや AJA DSP のデータとの統合的な分析に課題が生じていました。これらの課題を解決するために、 Apache Iceberg を使ったアーキテクチャを導入しました。 Iceberg は大規模なデータを効率的に扱うことができるオープンなテーブルフォーマットで、 Apache Spark や Trino 、 Apache Flink といった様々なエンジンやサービスがサポートしています。 Apache Parquet のような列指向データファイルと、テーブル単位の統計データを含むメタデータファイルから構成されており、これによってファイルレベルのプルーニングを効率よく行うことができます。 AWS では Amazon EMR や Amazon Athena 、 Amazon Data Firehose といったサービスで Iceberg テーブルを読み書きすることができ、 AWS Glue Data Catalog の自動コンパクションといった運用をサポートする機能も提供されています。 本ブログでは、Iceberg や AWS のサービスを活用して、AJA SSP が課題解決に挑んだ取り組みについて述べます。 課題 AJA SSP では主に広告配信におけるプランニングやレポーティング、コンテンツ分析のために毎時 Amazon Managed Workflows for Apache Airflow (MWAA) で Spark のバッチ集計ジョブを実行しています。各集計ジョブは依存関係を持ち、再集計を行うこともあります。そのため直感的な構文で依存関係を定義し、また特定期間の同一ジョブをまとめて実行することができる Airflow を利用しています。これによって集計されたテーブルはメディアの広告枠の設定などを行う管理画面のレポート機能やアドホックな分析で Athena から参照されています。 ビジネスの成長に伴い、組織としてもこれまで以上にデータを活用していく動きが進む中で 2 つの課題がありました。 ひとつはアドホックなクエリのパフォーマンスです。以前と比べて複雑な分析やトラブルシューティングを行うようになり、レポーティングのための集計済みサマリーテーブルでは粒度が大きすぎるため、生のログに近いテーブルを参照する機会が増えてきました。しかしそのようなテーブルは 1 日あたり数 TB ほどになり、数ヶ月にわたって参照したり複雑な JOIN を行ったりすると、Athena のクエリの完了まで数十分かかったり、scale factor 起因のリソース枯渇を示すエラーで失敗することもありました。 もうひとつはプロダクトを跨いだデータの分析です。AJA SSP は AWS 上、AJA DSP は他社クラウド上で動いていることもあり、手動でデータをエクスポートしアップロードするといった運用が行われていました。その結果、分析に時間を要し、また再利用性やデータの鮮度も低下していました。あわせて、組織のデータを最大限活用できるようにしつつも、意図しない用途でデータが利用されないよう適切なアクセス権限の設定も必要でした。 取り組み この 2 つの課題を解決するため Iceberg を中心とした構成に移行しました。 アドホックなクエリを実行する基盤として Snowflake を採用しました。Snowflake は各種クラウド上で動くフルマネージドなデータプラットフォームで、コンピューティングリソースであるウェアハウスのサイズを大きくすることで重いクエリにも対応でき、ウェアハウスを自動で起動、シャットダウンさせることにより、実行したクエリに対する従量課金のように利用することができます。アクセス制限に関してはテーブルだけではなく行や列に対してもかけることができます。また、Snowflake を使っている他の組織とのデータ連携が容易である点も採用する決め手となりました。 管理画面などのアプリケーションでは性能に関して課題がなく、新たに認証情報を与える必要がない Athena を引き続き利用する方針だったので、 Snowpipe などで Snowflake に S3 のデータをロードすることは Single Source of Truth (SSOT) の観点で望ましくありませんでした。S3 を外部テーブルとして参照すればこの点は解消できますが、Snowflake 側にもスキーマ定義が必要となり、スキーマの二重管理の懸念がありました。一方で Iceberg テーブルとして作成すると、Snowflake 側でのスキーマ定義が不要となりスキーマまで含めた SSOT を実現できます。さらに Glue Data Catalog を参照 することで Iceberg のメタデータファイルのパス を渡すことなくテーブル名だけで最新のデータを参照することができます。 // Snowflakeで実行するDDL // カタログ統合を作成 CREATE CATALOG INTEGRATION IF NOT EXISTS GLUE_CATALOG_INTEGRATION CATALOG_SOURCE = GLUE CATALOG_NAMESPACE = '(database_name)' TABLE_FORMAT = ICEBERG GLUE_AWS_ROLE_ARN = 'arn:aws:iam::...:role/...' GLUE_CATALOG_ID = '...' GLUE_REGION = 'ap-northeast-1' ENABLED = TRUE; // 外部ボリュームを作成 CREATE EXTERNAL VOLUME IF NOT EXISTS AJA_SSP_ICEBERG STORAGE_LOCATIONS = ( ( NAME = 'AJA_SSP_ICEBERG' STORAGE_PROVIDER = 'S3' STORAGE_BASE_URL = 's3://...' STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::...:role/...' ) ); // AWS Glue Data Catalogに登録されているIcebergテーブルを使用して、Apache Icebergテーブルを作成 CREATE OR REPLACE ICEBERG TABLE TABLE_NAME CATALOG = GLUE_CATALOG_INTEGRATION, EXTERNAL_VOLUME = AJA_SSP_ICEBERG, CATALOG_TABLE_NAME = '(table_name)', CATALOG_NAMESPACE = '(database_name)', AUTO_REFRESH = TRUE; 他社クラウドのデータも含めて Iceberg に統一することで同様の手順でデータを参照することができ、用途に応じて自由にクエリエンジンを選択できる環境が整いました。 Spark での Iceberg テーブルの読み書き方法については従来と大きく変わりませんでした。移行中は新旧両方のテーブルに書き込んでいます。 /* 旧テーブルへの書き込み */ df.write.mode(SaveMode.Overwrite).parquet(s"s3://.../ymd=.../hour=...") /* Spark で Glue Data Catalog や S3 と合わせて Iceberg を利用する際の設定 "spark.sql.catalog.iceberg": "org.apache.iceberg.spark.SparkCatalog", "spark.sql.catalog.iceberg.warehouse" : "s3://.../", "spark.sql.catalog.iceberg.catalog-impl": "org.apache.iceberg.aws.glue.GlueCatalog", "spark.sql.catalog.iceberg.io-impl": "org.apache.iceberg.aws.s3.S3FileIO", "spark.sql.extensions": "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions", */ /* 新テーブルへの書き込み */ df.writeTo(s"iceberg.(database_name).(table_name)")).overwritePartitions() ただ、運用にするにあたってテーブルのスキーマをどう定義するかという問題があります。 従来のテーブルは AWS CDK で作成していたのですが、現状 CDK で Iceberg テーブルを作成し、スキーマの更新などを行うと Iceberg テーブルとして扱われなくなるという 課題 があります。そのため、当初は Amazon Athena for Apache Spark の Notebook から手動で CREATE TABLE を実行していましたが、本格的な運用が始まりバージョン管理に乗せるにあたって、宣言的にスキーマを定義できたり SQLFluff でフォーマットをかけられるといった点で、 dbt 公式の Athena アダプタである dbt-athena で 0 件のレコードを append することでテーブルの作成およびスキーマの更新のみを行うようにしました。 {{ config( materialized = 'incremental', incremental_strategy = 'append', table_type = 'iceberg', format = 'parquet', s3_data_naming = 'table', on_schema_change = 'append_new_columns', partitioned_by = ['ymd', 'hour'] ) }} SELECT CAST(NULL AS DATE) AS ymd, CAST(NULL AS INT) AS hour, ... WHERE false しかし、この方法は特定のテーブルプロパティしか設定できず、パーティションが更新できないといった Athena 由来の制約があります。AJA DSP では先んじて dbt による集計に移行し、 Cosmos で dbt の model を Airflow の DAG に変換して動かしていることもあり、 AJA SSP でも将来的には集計ごと dbt-spark に移行することも検討しています。 ちなみに、集計ジョブは従来 EMR on EC2 で動かしていましたが、配信サーバーの Amazon Elastic Kubernetes Service (EKS) 移行に伴い、 EMR on EKS に移行し、同じクラスタで Spark のジョブも動かすようにしました。これにより配信サーバーと集計でクラスタ管理の知見を共用できるようになったことに加え、余剰リソースを集計に割けるようになり、また、集計分のリソースを配信サーバーがスケールアウトする際のバッファとして用いることもできるようになりました。 パフォーマンス 普段実行されているクエリの中からプルーニングが十分効くであろうクエリを選んで比較してみました。 70 TB ほどのログの中から特定リクエスト ID のレコードを抽出するクエリを Athena で 実行したところ、Parquet では 49 秒かかっていたのに対して同じパーティション粒度の Iceberg では 8 秒で完了しました。 加えて、Glue Data Catalog の統計情報の生成ジョブを実行し JOIN に用いるカラムの Number of Distinct Values (NDV) を含む Puffin ファイルを生成したところ、クエリでの順番にかかわらず、ハッシュテーブルが小さくなるように JOIN の順番が最適化されることも確認できました。 なお、次のテーブルプロパティを設定することで Parquet ファイルに Bloom Filter が書き込まれるようになり、カーディナリティが高いカラムにおいて Row group に特定の値のデータが存在し得るかの判定が効率化されることが期待されます。しかし今回のケースでは、スキャン量のみが増加する結果となりました。 ALTER TABLE (database_name).(table_name) SET TBLPROPERTIES ( 'write.parquet.bloom-filter-enabled.column.(col_name)' = 'true', 'write.parquet.bloom-filter-max-bytes' = '10485760', 'write.parquet.bloom-filter-fpp.column.(col_name)' = '0.01' ) /* $ parquet bloom-filter xxx.parquet -c (col_name) -v aaa,bbb,ccc Row group 0: -------------------------------------------------------------------------------- value aaa maybe exists. value bbb NOT exists. value ccc NOT exists. */ 続いて、特定パターンでの週間リクエスト数とユニークユーザー数の集計は、スキャン量は 15 GB 程度ですが時間のかかるクエリでした。元々の Athena + Parquet では 5 分かかっていましたが、Iceberg にすることで 103 秒で実行でき、スキャン量も 5 GB まで減りました。さらに Snowflake の X-Large ウェアハウス では 77 秒、4X-Large では 15 秒まで短縮することができ、リソースを増やして高速にクエリを実行する選択肢ができました。 Iceberg を採用することで、従来の Athena のクエリも高速化しました。Athena は実行したクエリでスキャンされたデータ量に基づいて計算される従量課金なので、スキャン量が減ったことでコストも削減できました。さらに、Snowflake では、ウェアハウスを大きくすることでさらなる高速化が実現できました。結果として、Iceberg でコストパフォーマンスを改善しつつ、求める要件によって柔軟にクエリエンジンを選べるようになりました。 最後に AJA SSP では Iceberg の採用によって、エンジンが柔軟に選択できるようになり、クエリのパフォーマンスも向上したことで分析サイクルを高速に回せるようになりました。ひとつ目の課題として挙げたアドホックなクエリのパフォーマンスは、Iceberg との組み合わせによりクエリエンジンを問わず効果が確認されています。2 つ目の課題であったプロダクトを跨いだデータの分析も、AJA SSP、AJA DSP それぞれの Iceberg フォーマットのデータを Snowflake から参照することによって SSOT で実現できました。Iceberg というオープンなテーブルフォーマットで S3 に保持しておくことは、耐久性やコストパフォーマンス、技術選定の自由度の高さといった点でも利点があると考えています。 今後の AWS の機能拡充にも期待しています。Iceberg への移行にあたり AWS の皆様には技術的な相談に乗っていただき感謝申し上げます。 著者 坂本 泰規（Taiki Sakamoto） 株式会社 AJA, データマネージメントチーム リーダー 半場 光晴（Mitsuharu Hamba） アマゾンウェブサービスジャパン合同会社, ソリューションアーキテクト &nbsp;

北半球の AWS Summit はほぼ終了しましたが、地球のそれ以外の地域にいる私たちにとって、楽しみと学習はまだ終わっていません。先週の AWS Summit Mexico City と AWS Summit Jakarta では、コミュニティ、お客様、パートナー、AWS 従業員が学習とネットワーキングの 1 日を満喫しました。 撮影: Nelly Andrade (AWS Summit Mexico City) 撮影: Shafraz Rahim (AWS Summit Jakarta) 8 月 4 日週のリリース 私が注目した 8 月 4 日週のリリースをご紹介します。 AWS での OpenAI オープンウェイトモデル – OpenAI オープンウェイトモデル (gpt-oss-120b と gpt-oss-20b) を AWS で利用できるようになりました 。オープンウェイトモデルは、コーディング、科学的分析、数学的問題解決に優れており、主要な代替モデルと同等のパフォーマンスを発揮します。 Amazon Elastic VMware Service – VMware Cloud Foundation (VCF) 環境を Amazon Virtual Private Cloud (Amazon VPC) 内で直接実行できるようにする新しい AWS サービス、Amazon Elastic VMware Service (Amazon EVS) の一般提供を開始しました 。 自動推論チェック – AWS re:Invent 中にプレビューした新しい Amazon Bedrock のガードレールポリシーである自動推論チェックの一般提供を開始しました。自動推論チェックは、基盤モデル (FM) によって生成されたコンテンツの正確性をドメインの知識に照らして検証するのに役立ちます。これが AI のハルシネーションによって引き起こされる可能性がある事実誤認を防ぐのに役立つ方法について詳しくは、 Danilo による記事 をご覧ください。 マルチリージョンアプリケーションのリカバリサービス – この記事 で、Sébastien が Amazon Application Recovery Controller (ARC) のリージョン切り替えの発表について書いています。これは、組織が自信をもってリージョン切り替えを計画、練習、オーケストレートできるようにし、リージョン間のリカバリオペレーションに関する不確実性を排除する、可用性の高いフルマネージド機能です。 その他のアップデート 興味深いと感じたプロジェクト、ブログ記事、ニュース記事をご紹介します。 Amazon Simple Queue Service (Amazon SQS) – Amazon SQS は、 メッセージのペイロードの最大サイズを 256 KiB から 1 MiB に増やしました 。これにより、お客様は Amazon SQS 標準キューと FIFO キューを通じて、より大きなメッセージを送受信できるようになりました。 AWS Lambda が GitHub Actions のサポートを開始 – AWS Lambda では GitHub Actions を使用して、コードまたは設定の変更を GitHub リポジトリにプッシュしたときに、GitHub Actions を使用して Lambda 関数を自動的にデプロイできるようになりました 。これにより、サーバーレスアプリケーションの継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインが合理化されます。 Amazon DynamoDB での Console-to-Code – Amazon DynamoDB は、 Amazon Q Developer を利用した Console-to-Code のサポートを発表しました 。Console to Code では、自動化コードの使用を開始することで、大規模な DynamoDB リソースを簡単かつ迅速に、費用対効果の高い方法で作成できます。 AWS ヒーローの Faye Ellis 氏 が作成した このコースを受講すると、Amazon Lex を使用した会話型 AI について詳しく学ぶ ことができます。このコースは無料トライアルの一環として、無料でご利用いただけます。 AWS コミュニティビルダーの Raphael Manke 氏 は、 非公式な AWS re:Invent セッションプランナー 2025 を公開しました。このプランナーは、数年前に初めてリリースされて以来、毎年大いに待ち望まれています。 AWS ヒーローの Rosius Ndimofor 氏 は、 Educloud Academy を構築しました。このプラットフォームの恩恵を受けているコミュニティメンバー ( 最新の Cloud and AI Challenge に参加しているこのビルダー など) による話は心温まるものです。 近日開催予定の AWS イベント 今後のイベントにぜひご登録ください。 AWS re:Invent 2025 (2025 年 12 月 1 日〜5 日、Las Vegas) — AWS の主力年次カンファレンスでは、ピアツーピア学習、専門家主導のディスカッション、貴重なネットワーキングの機会を通じて、共同イノベーションを提供します。 AWS Summit – クラウドコンピューティングコミュニティが集まり、交流し、協力し、AWS について学ぶことができる無料のオンラインイベントと対面イベントにご参加ください。 間もなくサンパウロ (8 月 13 日) と ヨハネスブルグ (8 月 20 日) で AWS Summit が開催されます。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18 日)、 南アフリカ (9 月 20 日) です。 AWS Builder Center に参加して、AWS コミュニティで AWS ビルダーとともに学び、構築し、交流しましょう。今後開催される追加の 対面イベント と デベロッパー向けのバーチャルイベント をこちらでご覧ください。 8 月 11 日週のニュースは以上です。8 月 18 日週にお届けする次回の Weekly Roundup もお楽しみに! – Veliswa 原文は こちら です。

この記事は Introducing the Amazon EKS Auto Mode workshop (記事公開日: 2025 年 4 月 15 日) を翻訳したものです。 本日、 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode の ハンズオンワークショップ を紹介できることを嬉しく思います。このワークショップは、お客様自身の AWS アカウントで実行することも、AWS が主催するイベントに登録して参加することも可能です。(訳注: ハンズオンワークショップの日本語訳を 2025 年 8 月に公開しました。) AWS での Kubernetes 運用を効率化する新機能である EKS Auto Mode は、 re:Invent 2024 で一般提供が開始 されました。EKS Auto Mode により、本番環境レベルの Kubernetes アプリケーションを大規模に実行するために必要なクラスターインフラストラクチャの管理に伴う運用オーバーヘッドを排除することで、組織のイノベーションを推進するアプリケーションの構築に集中できるようになります。本日紹介するワークショップは、EKS Auto Mode を使用して Kubernetes アプリケーションを迅速に起動するために必要な実践的な知識とスキルを提供することを目的としています。EKS Auto Mode の詳細については、 提供開始の記事 ならびに 入門 と 詳解 の記事をお読みください。 EKS Auto Mode ワークショップとは？ EKS Auto Mode ワークショップでは、Auto Mode を使用して Amazon EKS にワークロードをデプロイするために必要な知識を提供し、Kubernetes アプリケーションの実行に伴う運用オーバーヘッドをどのように効率化できるかを理解していただけます。ワークショップは一連の高レベルな学習モジュールに抽象化されており、各モジュールは前に習得した知識の上に構築されています。また、 EKS Auto Mode への移行方法 を扱う独立したラボもあり、オプションで完了することができます。ワークショップの完了には約 2 時間かかります。 ワークショップでは、以下の手順を実行します: EKS Auto Mode を有効にする方法を学ぶ: AWS Command Line Interface (CLI) 、Terraform、EKS CLI (eksctl)、またはコンソールなど、お好みのクラスター管理方法を使用して、既存のクラスターで EKS Auto Mode を有効にします。 アプリケーションのデプロイを習得する: Auto Mode を有効にすると、単一のコマンドだけで、追加の設定を必要とせずにアプリケーションをデプロイできます。EKS Auto Mode はアプリケーションの要件を評価して最適なコンピューティングインスタンスを選択・起動し、リソースを動的にスケーリングし、コストを継続的に最適化します。 EKS Auto Mode の組み込み機能を発見する: すでにデプロイされた Retail Store アプリの異なるコンポーネントを段階的に変更します。これにより、コンピューティング、オートスケーリング、ネットワーキング、ストレージで利用可能な様々な機能と設定オプションを深く理解できます。このモジュールの終了時には、ステートフルとステートレスの両方のコンポーネントを持つ、高可用性、自動スケーリング、ロードバランシング、外部アクセス可能なアプリケーションのセットをデプロイしたことになります。これらは完全に機能する Retail Store サンプルアプリケーションを形成します。 効率化されたクラスターアップグレードを体験する: EKS Auto Mode がクラスターアップグレードを完了させるプロセスをどのように効率化するかを理解し、次の Kubernetes バージョンへのアップグレードを実行する実践的な経験を積むことができます。 既存ワークロードの移行方法を理解する: クラスターにすでにデプロイされているアプリケーションを EKS Auto Mode に移行する方法を学ぶことができます。このモジュールは、必要ない場合はオプションです。 このワークショップの終了時には、EKS Auto Mode により AWS がどのように運用責任を拡大するかを理解できるようになります。これにより、AWS で Kubernetes アプリケーションを起動することがはるかに明確になり、今日から始めるために必要なすべての知識を得ることができます。 ワークショップの対象者は？ このワークショップは L300 レベルで、Kubernetes と Amazon EKS の基本的な理解を持つユーザー向けに設計されています。 お客様自身のアカウントで実行するための前提条件 AWS アカウントで EKS Auto Mode ワークショップを開始するには、まずワークショップで使用するベースラインインフラストラクチャをプロビジョニングします。これらの手順を自動化するために、ワークショップでは AWS CloudFormation を使用します。内部的には、CloudFormation テンプレートが 2 つのクラスターをプロビジョニングします: 1 つは EKS Auto Mode の開始用、もう 1 つは Amazon EKS から EKS Auto Mode への移行パターンのデモンストレーション用です。CloudFormation を使用してワークショップ環境をデプロイする方法については、 お客様自身の AWS アカウントでの開始方法 の手順を参照してください。 ワークショップのナビゲーション方法は？ ワークショップ環境がデプロイされると、CLI コマンドを通じて手順が完了します。ワークショップのすべてのコマンドについて、手順内の任意の場所を左クリックしてコマンドをコピーするか、次の図に示すように右上角のクリップボードアイコンを選択してすべてのコマンドをコピーできます。 図 1: ワークショップのコマンド例 ワークショップの作業を開始するためのセットアップ時間を短縮するため、 Amazon Elastic Compute Cloud (Amazon EC2) 上に Visual Studio Code Server IDE がプロビジョニングされ、ワークショップに必要なすべてのバイナリと設定が事前に読み込まれています。これには、kubectl、aws、eksctl などの CLI ツールが含まれます。IDE へのアクセス方法については、この 開始ガイド で確認できます。 リソースのクリーンアップ ワークショップが完了したら、プロビジョニングしたリソースをクリーンアップする必要があります。リソースをクリーンアップする手順は、 ワークショップの最後 に記載されています。 まとめ Amazon EKS Auto Mode ワークショップにより、お客様は新しい EKS Auto Mode 運用モデルの使用方法について実践的な知識を得ることができます。ワークショップ環境をデプロイしてセルフガイドの体験を 今日から始め 、ワークショップモジュールのステップバイステップの手順に従ってください。 EKS Auto Mode ワークショップの AWS が主催するイベントに参加するには、お客様に適した日時に登録してください。 また、 Amazon EKS コンソール で EKS Auto Mode を試すか、 Amazon EKS ユーザーガイド のドキュメントをご確認ください。 コントリビューター 著者は、Amazon EKS Auto Mode のこの新しいワークショップの開発において貴重な支援をいただいた以下の方々に感謝いたします: Ahmed Azzam、Alexander Pinsker、Borja Perez Guasch、Chakkree Tipsupa、Dmitry Nutels、Erez Zarum、Estefany Kuong Montalvan、Karan Thanvi、Mike Rizzo、Niall Thomson、Raymond Zhou、Robert Northard、Sai Vennam、Sebastien Allamand、Sheetal Joshi、Tsahi Duek、Vicky Whittingham。 訳者は、このワークショップを日本語に翻訳いただいた以下の方々に感謝いたします: Niall Thomson、Tsahi Duek、落水 恭介、林 政利。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

はじめに 高度に接続された現代社会では、モノのインターネット（IoT）機器が、家庭やオフィス、産業との関わり方を一変させています。スマートテクノロジーは今や家庭から自動車、産業機器にまで普及しています。これらのデバイスをリモートで制御することは不可欠であり、生産性、ユーザーエクスペリエンス、リスク管理の向上をもたらします。このブログでは、AWS IoT デバイスに安全かつ効果的にリモートコマンドを送信する方法について説明します。 IoT デバイスにリモートアクションを送信することは、スマートソリューションを構築する上で重要な要件です。リモートコマンドは、ユーザ、オペレータ、技術者が離れた場所からデバイスを制御、監視、管理することを可能にします。ユーザーは、物理的にその場にいなくても、デバイスのオン/オフ、設定値の調整、データの取得など、リアルタイムに近いアクションを行うことができます。リモートコマンドの送信は、自動車、ヘルスケア、製造、輸送、スマートホームなど、リモートデバイス管理によって効率の向上、コスト削減、全体的な運用の柔軟性の向上を行うことのできるような業種では極めて重要になっています。 リモートコマンドを送信するために、カスタムのソリューションやワークアラウンドを自前で開発し、IoTソリューションの機能を強化・拡張するケースがこれまでもありました。しかしながら、このような自社開発のソリューションは、時間が経つにつれて複雑化し、スケールさせるのが難しくなりがちで、インフラや運用コストを増加させることがあります。こうした課題に対処するため、AWS はリモートアクションの実行のライフサイクル管理を行う機能として AWS IoT Device Management コマンド をリリースしました。 概要 コマンド機能は、クラウドとデバイス間の双方向通信を可能にする　MQTT 標準に基づいたリモートアクション機能です。コマンド機能を使用することで、細かなアクセス制御メカニズムを実装し、承認されたユーザーのみが特定のデバイスにコマンドを送信できるようにすることができます。一般的な使用例には、デバイスアクションの開始、デバイス状態の更新、デバイス構成の変更があります。 コマンド機能は、個々のデバイスに対してリモートアクションを配信するための、細かいアクセス制御と効率的なデバイス管理ツールを提供します。 この機能は AWS IoT コンソールのリモートアクションのセクションからアクセスでき、JavaScript Object Notation (JSON)、Concise Binary Object Representation (CBOR)、Parquet、プレーンテキストなど、さまざまなデータ形式に対応した、カスタマイズ可能なデータペイロードを持つ一意の名前を持ったコマンドを作成することができます。 一度定義されたコマンドは、異なるターゲットデバイスに対して何度でも使用することができます。各コマンドの実行に対して特定のタイムアウト時間を設定したり、リアルタイムの更新と通知を通じてそのコマンド進行状況を監視することできます。以下のワークフローと手順は、コマンド機能の概要を説明しています。 図 1: AWS IoT デバイス管理コマンド機能のワークフロー AWS IoT Device Management を使ってデバイスにコマンドを送信する: 事前定義された再利用可能なコマンドを作成し、AWS IoT Device Management コマンドに保存する。 ターゲットデバイスに送信するコマンドのペイロードを指定する。 デバイスタイプを AWS IoT Thing もしくは MQTT client のどちらかに指定する。 デバイスは以下に示すコマンドトピックをサブスクライブする。 $aws/commands/[things|clients]/[&lt;thingname&gt;|&lt;clientId&gt;]/executions/+/request/ [json|cbor] ここに IoT コマンドが送信される。 クライアントアプリケーションを通してユーザがコマンドをトリガーし、それぞれのデバイスのリクエストトピックにコマンドのペイロードが送信される。 デバイスはリクエストトピックでコマンドペイロードを受信すると、想定されているアクションを行い、クラウドにレスポンスを送る。 デバイスは以下のトピックにコマンドの実行の進捗とステータスアップデートを送信する。 $aws/commands/[things|clients]/[&lt;thingname&gt;|&lt;clientId&gt;]/executions/&lt;executionid&gt;/response/[json|cbor] . コマンドサービスは $aws/events/commandExecution/&lt;CommandId&gt;/+ にNotificationをパブリッシュし、ユーザーは Notification を受け取る。( 注意: Notification の受信はオプションで、AWS IoT を通じて設定することが可能です。) AWS Device Management コマンドの主要な機能は以下となります: 単一のデバイス上で複数のコマンドを実行するための並列制御。 AWS IoT に登録されていないデバイスに対してのオペレーションサポート。 各コマンドの実行時間の上限を制御し、適切なタイミングでの完了を保証するための時間制限の設定。 コマンドの進捗状況のリアルタイムな更新。 セキュアなコマンドの送信と細かなアクセス制御。 リモートアクションを IoT デバイスに送信するための実際のユースケース AWS IoT Device Management コマンドはスマートホームや産業向け IoT 、車両のフリート管理アプリケーションにおいて、カスタムの MQTT ソリューションの構築を行うことなく、クラウドとデバイスの間の命令セットの送信を簡単化します。 スマートホーム OEM やスマートホームインテグレーターは、スマートフォンを使って住人が快適性、セキュリティ、エネルギーシステムを制御できるようリモートコマンド機能を実装することができます。 たとえば、スマートフォンから温度調節機能を用いて家に到着する前に暖房を入れたり、家を出たあとに消し忘れた照明をオフにしたりすることができます。 セキュリティカメラで異常なアクティビティを検知した場合は、リモートでドアの施錠、アラーム作動、あるいはスピーカーから話しかけることで不審者の侵入を防止することもできます。 休暇中には、指定した時間に照明やテレビのオンオフをスケジュール管理して不在を外部に知られなようにすることもできます。 天気予報に基づいて、設定を自動的に調整することも可能です。例えば、空調のコストをを下げるために暑い日にはスマートブラインドを閉じる、雨が降った場合には散水のスケジュールを調整する、といったことが可能になります。 産業向け IoT 大規模な製造工場では、IoT デバイスが製造ラインの機器やシステムに組み込まれ、プラント管理者がリアルタイムに近い形でリモートから製造のパラメータを調節することができ、需要の変動やサプライチェーンの不測の事態に対応することができます。センサーが機器の異常を検知した場合、リモートでの診断を行い、生産を停止することなく必要な調整を行うことができます。緊急時には安全プロトコルを起動し、特定の機器もしくはプラントのセクション全体を停止することができます。プラント管理者はリモートコマンドを用いて予兆保全を行い、リアルタイムに近い機器データを用いてメンテナンスのタスクをスケジュールし、ダウンタイムを最小化し、全体の運用効率を最適化することができます。 フリート管理 車両に搭載された IoT デバイスを用いて運輸会社はリモートで各種メトリクスをモニターすることができます。メトリクスには、リアルタイムの位置情報、燃料消費量、エンジンの状態、ドライバーの運転状況などが含まれます。フリート管理者は、機械的に問題のある車両の速度制限を下げることで損傷を事前に防ぐことができます。ドライバーがルートを外れた際には、ナビゲーションシステムの経路を変更することも可能です。悪天候の際には、フリート管理者は該当する車両に安全プロトコルを適用することもできます。さらに、リモートでの車両診断や、無線によるソフトウエアのアップデートを行うことができ、物理的なメンテナンスの必要性を減らすことができます。コマンド機能を使ったフリート管理ソリューションは安全性を向上させ、ダウンタイムを減らし、フリート全体にかかるメンテナンス費用を大幅に削減することができます。 AWS IoT Device Management コマンドとジョブ機能の違い リモートでのオペレーションを定義して AWS IoT に接続されている１つ以上のデバイスに送付して実施する方法として AWS IoT Jobs &nbsp;を使用する事もできます。コマンドを使用するか Job を使用するかは、利用者の IoT ユースケースの要件と、利用者がデバイスで実施したいやり取りの性質に依存します。 コマンド機能の開始方法 AWS IoT Device Management のコマンド機能を用いた実際のユースケースの一例として、スマート洗濯機を構築する方法を説明します。 ユースケース: あるエンジニアが、リモートから制御可能なスマート洗濯機を開発していることを想定します。ユーザーはどこからでもモバイルアプリからスマート洗濯機を管理することができます。ユーザーはアプリを通してコマンドを送信することができ、洗濯のスタート、ストップ、洗濯タイプのような設定の調整、水の温度の設定、回転スピードの設定などを行うことができます。これらのコマンドは MQTT プロトコルを通じて洗濯機に送られます。オペレーション中にはスマート洗濯機は MQTT を通じてステータスのアップデートを送り、ユーザーに残り時間を示したり、現在のサイクルを表示したり、アラートがあればアラートを表示します。問題が発生した場合には、技術者が問題解決のためにリモートから洗濯機にアクセスし、デバイスの設定を変更したりすることもできますが、この機能は通常のユーザーには制限されます。この機能はどのようなモバイルアプリにも統合することができますが、今回は IoT バックエンドの実装にフォーカスしているので、モバイルアプリの開発とインテグレーションは割愛しています。. 仮定: ここでは、デバイスはすでに AWS IoT Core に登録されており、「SmartWasher」というモノの ID を取得しているものと仮定します。新規デバイス登録については、 AWS IoT workshop をご参照ください。 ここでは、コマンド実行の実装と監視の手順をステップバイステップで説明します: システムに必要なコマンドを作成します。 デバイスが発行されたコマンドを受け取れるように、関連するトピックへのサブスクライブを設定します。 デバイスにて新しい「コマンド実行」を行うためにコマンドを起動します。 デバイスから実行ステータスをパブリッシュし、トラッキングアプリケーションで進捗を監視します。 重要なお知らせ: コマンドの作成と管理は、AWS SDK、AWS CLI、AWS 管理コンソールなど複数の方法で行うことが可能です。 このブログで紹介するサンプルでは、コマンドの作成と管理を AWS CLI と AWS 管理コンソールで実施します。 ステップ 1: コマンドの作成 スマート洗濯機の 3 つの主要機能を行うコマンドを作成しましょう。1. 既定の設定で通常の洗濯サイクルを開始する。2. 洗濯サイクルを終了する。3. 技術者が診断システムを実行し、診断データにアクセスできるようにする。 コマンド 1: 通常の洗濯サイクルを開始する AWS IoT で新しいコマンドを作成するには、AWS マネジメントコンソールにアクセスし、AWS IoT サービスに移動します。 そこで、左側のサイドバーにある「Manage」セクションを探し、「Remote actions」をクリックして「Commands」を選択します。 「Create Command」ボタンをクリックしてプロセスを開始します。 プロンプトが表示されたら、Command ID に「StartDefaultCycle」と入力します。 次に、必要なペイロードを含む JSON ファイル (　詳細は startdefaultcycle.json として以下に示されています) を作成する必要があります。 コマンド作成インターフェースの「Specify payload」セクションで、この JSON ファイルをアップロードします。 すべての詳細が正しいことを確認したら、「Create Command」ボタンをクリックしてプロセスを完了させ、新しいコマンドを AWS IoT システムに追加します。 startdefaultcycle.json &nbsp; { &nbsp;&nbsp;&nbsp; "Action": "RunWashCycle", &nbsp;&nbsp;&nbsp; "CycleType": "Normal", &nbsp;&nbsp; "Soak": "Yes", &nbsp; &nbsp; "SpinSpeed": "Medium", &nbsp;&nbsp; "WaterTemperature": "Warm" } 図 2: 通常サイクルの新しいコマンドを作成する コマンド 2: サイクルを停止する 以下のペイロードを使用して、洗濯機の停止コマンドを作成してください。 stopcycle.json { &nbsp; "Action": "StopWashCycle" } コマンド 3: 診断情報の取得 トラブルシューティングのために、このペイロードを使用して洗濯機のログを取得するコマンドを作成してください。 retrievediagnostics.json { &nbsp;&nbsp; "Action": "RetrieveLogs", &nbsp;&nbsp;&nbsp; "LogType": "DiagnosticMetrics", &nbsp; &nbsp; "TimeRange": "12Hr" } コマンドのホームページには、作成されたコマンドが表示されます。 図 3: AWS マネジメントコンソールのコマンドホームページ 作成したコマンドは、アクションメニューから管理することが可能です。オプションからは、設定の編集、一時的な無効化、もしくは必要に応じて完全な削除を行うことができます。 ステップ 2: デバイスのセットアップとトピックへのサブスクライブ コマンドサービスは、新しい実行が開始されるたびに、ターゲットデバイスに MQTT で通知を行います。コマンド実行を受信すると、デバイスは構造化されたアクションのシーケンスを開始します。最初に、デバイスは MQTT メッセージのペイロードに基づき、受け取ったコマンドを解釈します。次に、要求されたアクションを実行します。実行後、デバイスはクラウドに実行ステータスを報告し、操作が成功したか、問題があったかをレポートします。このようなコミュニケーションフローを実現するために、デバイスは、すべてのコマンド実行要求がパブリッシュされるリクエストトピックを購読する必要があります。コマンド処理後、デバイスは応答を指定された応答トピックに公開する必要があります。今回のシミュレーションでは、いくつかのシナリオをカバーするため、コマンド実行に成功した場合と失敗した場合の両方を実演します。 このブログでは、 AWS IoT Device SDK v2 for Python を使用して、スマート洗濯機をシミュレーションします。 リクエストトピック: $aws/commands/things/&lt;thing-id&gt;/executions/+/request/json サブスクリプションが成功したときのスマート洗濯機からのサンプルログ: 図 4: サブスクリプション出力を表示するターミナルウィンドウ レスポンストピック: $aws/commands/things/&lt;thing-id&gt;/executions/&lt;execution-id&gt;/response/json ステップ 3: コマンド実行 エンドユーザーにとって、スマート洗濯機とのインタラクションは、モバイルアプリなどのユーザーフレンドリーなアプリケーションインターフェースを通じて簡素化されています。今回のデモでは、CLI コマンドを使用してこの体験をシミュレートします。以下の CLI コマンドを実行すると、execution-ID が返されます。この一意の識別子は、コマンドの実行に関する情報を追跡および取得するために不可欠です。この ID を必ずメモしてください。以降のクエリで&lt;execution-id&gt; のプレースホルダーをこの execution-ID で置き換える必要があります。 注意：新しいコマンドの実行を開始するには、エンドポイントタイプを iot:Jobs として指定して、 DescribeEndpoint API を使用して固有のエンドポイントを取得してください。 通常の洗濯サイクルを開始する実行コマンド: サンプルリクエスト: aws iot-jobs-data start-command-execution \ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --command-arn arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/StartDefaultCycle \ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--target-arn arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:thing/SmartWasher \ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --execution-timeout-seconds 3600 \&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --endpoint-url &lt;endpoint-from-describe-endpoint-api-result&gt; サンプルレスポンス: { &nbsp;&nbsp;&nbsp; "executionId": "576fe4d7-c604-489d-af91-c37ca9f8303b" } StartCommandExecution API の呼び出しが成功すると、スマート洗濯機上で動作する MQTT クライアントが、リクエストトピックで MQTT メッセージを受信します。以下は スマート洗濯機で受信されたサンプルです。 図 5: MQTT メッセージを表示するターミナルウィンドウ ステップ 4: デバイスによるコマンド実行ステータスの更新 コマンド機能は、デバイスがクラウドに状態を報告するために UpdateCommandExecution MQTT トピックベースの API を提供します。上記の例では、スマート洗濯機が洗濯サイクルを開始すると、継続的に状態をクラウドに報告します。 スマート洗濯機からのステータス更新では、「SOAK」が完了したことを報告しています。AWS マネジメントコンソールのサンプル MQTT クライアントを使用して、洗濯機からのステータス更新をシミュレートします。洗濯機は、デバイスと実行に対して固有のレスポンストピックに実行ステータスを投稿します。 $aws/commands/things/SmartWasher/executions/&lt;execution-id&gt;/response/json { &nbsp; "status": "IN_PROGRESS", &nbsp; "result": { &nbsp;&nbsp;&nbsp; "SOAK": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "s": "COMPLETED" &nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp; "RINSE": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "s": "PENDING" &nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp; "SPIN": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "s": "PENDING" &nbsp;&nbsp;&nbsp; } &nbsp; } } 開発者は、GetCommandExecution API を活用することで、アプリケーションにステータス監視機能を追加することができます。 ステップ5.1: エンドユーザー向けの進捗トラッキング（アプリケーション） エンドユーザーにコマンドの実行状況について通知するため、アプリケーションは定期的に GetCommandExecution API を呼び出し、特定のコマンド実行のほぼリアルタイムなステータスを取得できます。これにより、ユーザーは即時的に進捗をトラックすることができます。 実行ステータスを取得するためのサンプルリクエスト: aws iot get-command-execution --execution-id &lt;execution-id&gt; \ --target-arn arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:thing/SmartWasher ステップ 5.2: 管理者または技術者による進捗トラッキング 技術者および管理者は、指定されたコマンドのイベントトピックを使用して、フリート全体でのコマンドの実行状態を追跡できます。 $aws/events/commandExecution/&lt;command-id&gt;/&lt;CommandExecutionStatus&gt; この機能をテストするために、AWS IoT コンソールを利用できます。コンソールにログインし、MQTT テストクライアントに移動します。「トピックへのサブスクリプション」セクションで、上記のトピックを購読します。 図 6: コマンド実行ステータストピックをサブスクライブ 以下のコマンドのいずれかを実行し、生成される &lt;execution-id&gt; をメモしてください。MQTT テストクライアントを使用して、指定されたレスポンストピックにレスポンスを送信します。その後、メッセージがコマンド実行ステータストピックに正しく表示されることを確認してください。 図 7: レスポンストピックに成功のメッセージを送信 図 8: コマンド実行ステータストピックの結果を確認 図 9: レスポンストピックに失敗のメッセージをパブリッシュ 図 10: コマンド実行ステータストピックの結果を確認 ポリシー設定 セキュリティを強化するため、AWS IoT コマンドは、特定のユーザーのみが特定のデバイスにコマンドを送信する権限を付与できるように設定することができます。AWS IoT Core は、アイデンティティとアクセス管理（IAM）権限（ポリシーとも呼ばれる）を使用して、コマンド機能へのアクセスを制御します。これらのポリシーは、認証されたユーザーがデバイスにコマンドを送信できるかどうかを決定します。 IAM ポリシーは、個々のユーザー、グループ、またはロールに適用でき、特定のコマンドを実行できるユーザーを詳細に制御できます。例えば、スマート洗濯機システムに 3 つの異なるアクセス権限に応じたロールがあります: 管理者: スマート洗濯機のコマンドの作成と管理を担当します。このロールはシステム制御の最高権限を有します。 家族メンバー: 日常の洗濯作業で洗濯機を操作する一般ユーザー。アクセス権限は日常使用に必要な基本機能に限定されています。 技術者: 問題が発生した際にシステムのメンテナンスやトラブルシューティングを行う役割。診断や修理のための専門的な権限が与えられています。 以下のサンプル IAM ポリシーは参考の目的で提供されています。包括的なポリシー設定の手順については、 コマンドの作成と管理のドキュメント をご確認ください。セキュリティのベストプラクティスと最小権限の原則に従うため、 AWS IoT のIdentity and Access Management ガイド をご参照ください。これらの例はデモのためのものであり、実際の適用の場合には、相応のセキュリティ要件に合わせてポリシーをカスタマイズする必要あることに留意してください。 Policy1: 管理者ロール { &nbsp; "Version": "2012-10-17", &nbsp; "Statement": [ &nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp; "Action": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "iot:CreateCommand", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "iot:GetCommand", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "iot:UpdateCommand", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "iot:DeleteCommand" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Effect": "Allow", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Resource": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/*" &nbsp;&nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp;&nbsp; "Condition": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "ArnLike": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "aws:PrincipalArn": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "arn:aws:iam::&lt;account-id&gt;:role/&lt;specific-role&gt;",&lt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"arn:aws:iam::&lt;account-id&gt;:user/&lt;specific-user&gt;"&lt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ] &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; } &nbsp; ] } Policy2:　家族メンバーおよび一般のユーザーロール { &nbsp; &nbsp;"Version": "2012-10-17", &nbsp;&nbsp; &nbsp;"Statement": [ &nbsp;&nbsp; &nbsp; &nbsp;{ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Action": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"iot:StartCommandExecution", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"iot:GetCommandExecution" &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;], &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Effect": "Allow", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Resource": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/StartDefaultCycle", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/StopWashCycle", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:thing/SmartWasher" &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;] &nbsp;&nbsp; &nbsp; &nbsp;} &nbsp;&nbsp; &nbsp;] &nbsp;} Policy3: 技術者ロール { &nbsp;&nbsp; &nbsp;"Version": "2012-10-17", &nbsp;&nbsp; &nbsp;"Statement": [ &nbsp;&nbsp; &nbsp; &nbsp;{ &nbsp; &nbsp; &nbsp; &nbsp;"Action": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"iot:StartCommandExecution", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"iot:GetCommandExecution" &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;], &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Effect": "Allow", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Resource": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/RetrieveDiagnostics", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:thing/SmartWasher" &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;] &nbsp;&nbsp; &nbsp; &nbsp;} &nbsp;&nbsp; &nbsp;] &nbsp;&nbsp;} まとめ 結論として、AWS IoT デバイス管理のコマンド機能は、IoT デバイスのコマンドをリモートで管理するための安全で効率的かつコスト効果の高い方法を提供し、優れたスケーラビリティを維持します。その軽量な設計、コスト効果の高い用途に応じた機能は、他のカスタム構築ソリューションに対し明確な優位性を提供します。スマートホームの管理であろうと産業施設の管理であろうと、コマンド機能は低遅延かつ高スループットのアプリケーションを開発する開発者に対して、クラウドからデバイスへのインタラクション、リモート監視、制御、診断をスケール可能な状態で実現します。これにより、ユーザーはどこからでもデバイスの制御が可能となります。 関連情報 AWS IoT Device Management のリモートコマンド実行 AWS IoT Device Management の料金 著者について Sara Akkandi は、Amazon Web Service（AWS）のソリューションアーキテクトとして、お客様と協力して well-architected のクラウドソリューションの設計と実装を支援しています。彼女の技術的な専門知識を活かし、組織が AWS のサービスとベストプラクティスを活用してビジネス上の課題を効果的に解決し、最適な結果を達成できるよう導いています。 Ryan Dsouza は、AWS のクラウドオプティマイゼーションサクセス組織においてプリンシパルソリューションアーキテクトを務めています。ニューヨーク市を拠点とする Ryan は、AWS の広範かつ深い機能を活用し、顧客がより安全でスケーラブルかつ革新的なソリューションを設計、開発、運用し、測定可能なビジネス成果を実現する支援を行っています。彼は、顧客がパフォーマンス、コスト効率、セキュリティ、耐障害性、運用 excellence を最適化するソリューションを設計するための戦略、ガイドライン、ツールの開発に積極的に取り組んでおり、AWS クラウド採用フレームワークと well-architected フレームワークに準拠したアプローチを推進しています。 この記事は Sara Akkandi, Ryan Dsouza によって書かれた Using AWS IoT Device Management commands to simplify remote actions on IoT devices の日本語訳です。この記事は&nbsp;プロフェッショナルサービス本部 シニアデリバリーコンサルタントの小林が翻訳しました。 <!-- '"` -->

この記事は Proven Practices for Succeeding with a Multicloud Strategy を翻訳したものです。 企業戦略家としての経験から、マルチクラウドに関する議論は多くの場合、混乱と矛盾したアドバイスに悩まされていることがわかります。マルチクラウド戦略を採用しないよう警告するアドバイザーもいれば、採用しなければ業界全体の変革に乗り遅れると指摘するアドバイザーもいます。マルチクラウド戦略の採用には正当な理由がありますし、また反対も同様です。成功には、マルチクラウド戦略がもたらす潜在的なビジネス価値と複雑性およびリスクのバランスをとることが不可欠です。 企業は通常、戦略的な理由からマルチクラウドを採用します。異なるプラットフォームで事業を展開する新たに買収した企業を統合したり、異なるプロバイダーの専門的な機能を活用したり、持株会社と事業会社のレベルで異なるクラウド戦略をサポートしたりするためです。 ただし、企業はマルチクラウド戦略を一般的な誤解、例えば全面的な採用、ベンダーロックインの軽減、可用性の向上、コストの優位性などに基づいて策定すべきではありません。 ( これらの考慮事項についてより深く掘り下げた議論は、以前の私の記事 Proven Practices for Developing a Multicloud Strategy をご覧ください。 ) マルチクラウドアプローチを成功させるには、既存のツールや将来の選択肢と シームレスに 連携するクラウドプラットフォームが必要です。他のクラウドサービスプロバイダ ( CSP ) の機能を追加する際に、すべてを再構築する必要はありません。また、すべてのプラットフォームのエキスパートになる必要もありません。 ( これが Multicloud on AWS において直接接続ポイントを構築する理由です。AWS 上で実行されるワークロードの性能を最大化しつつ、CSP 間の管理を簡素化するようにツールを設計しています。 ) お客様との経験に基づき、以下のプラクティスを推奨します。 1. 明確な戦略とそれを支えるガバナンスを確立する マルチクラウドアプローチを追求すると決めただけでは不十分です。どのワークロードをどこに、何のために配置するかについての明確なガバナンスを含め、マルチクラウドの目的を達成するための戦略も確立する必要があります。ワークロードとその依存関係を最適化する評価基準を選択してください。このような決定を個人任せにすると、 CSP 間の無秩序な拡大が生じ、達成しようとした価値を損なう可能性があります。CSP のパフォーマンスを定期的に評価し、その評価を CSP の選択、ワークロード配分基準、および将来の利用計画に活用してください。 ガバナンス戦略をサポートするためには、企業全体のサービス、アプリケーション、コンポーネントの総数について可視化する必要があります。そのためには、CSPを横断してタグ付け戦略を確立し、明確な所有権、利用状況、環境 ( 開発、QA、ステージ、本番など ) を定義してください。所有者が特定できない場合は、そのリソースを削除する必要があります。これによりガバナンスが明確化され、進捗を阻害することなく自動的に施行されます ( ゲートではなくガードレール ) 。 コスト、運用プロセス、セキュリティは、CSP 間で同じ方法で、同じ深さのデータと透明性をもって監視され、対処されなければなりません。 2. 隣接するワークロードをCSP間に分散させない 複数の CSP に跨がる単一のワークロードは、不必要な複雑性、リスク、コストをもたらし、サポート、デプロイ、アーキテクチャを複雑にするだけで付加価値はほとんどありません。 隣接したワークロードは通常、一緒に処理・分析する必要のある大量のデータを伴います。データを複数の CSP に分散させると、データの移動、同期、整合性に課題が生じます。また、複数の CSP 上の単一のワークロードを管理することは複雑で時間がかかります。各 CSP の API 、管理インターフェース、セキュリティモデル、運用プロセスに対応する必要があるためです。複雑性の増加は、エラーの可能性を高め、運用オーバーヘッドを増加させ、アジリティとスケーラビリティを阻害する可能性があります。 3. より長期的な統合戦略を持つ 異なるクラウドのアプリケーション間でデータを移動する際には注意が必要です。特に、ある CSP にコンピューティング／アプリケーションをデプロイし、別の CSP にデータ、ストレージをデプロイする場合はなおさらです。ワークロードとデータの配置を決定する際は、ワークロードとデータを他の機能と統合する長期的なニーズを考慮する必要があります。データが現在の範囲を超えて、高度な分析や ML に必要となるでしょうか?そのサービスは他の CSP でも幅広く利用されるでしょうか、それとも特定の CSP 内に限定されるでしょうか? より詳しいガイダンスと導入検討のための意思決定モデルについては Gregor Hohpe の以前の記事 Multi-cloud: From Buzzword to Decision Model をご覧ください。 4. コンテナを戦略的に活用する コンテナはモダンなアプリケーションに適していることが多く、ポータビリティの面で役立ちます。コンテナはプラットフォームに依存しないため、コンテナ化をサポートするあらゆるクラウドプラットフォームやインフラにも展開できます。アプリケーションを一度開発、パッケージ化すれば、大幅な修正なしに複数の CSP やオンプレミス環境に展開できます。 ただし注意が必要です。コンテナはすべてのケースに適しているわけではなく ( 大規模なモノリシックアプリケーションなど )、CSP 間のポータビリティのすべての問題 ( 特にデータ、ポリシー、セキュリティ ) を解決するわけではありません。 5. 単一のCCoE ( Cloud Center of Excellence ) を持ち、その中で専門化する 多くのお客様にアドバイス しているように、組織内に CCoE を形成し、クラウドに関する取り組みをリードし、標準化を推進することで、クラウドジャーニーを加速するべきです。マルチクラウドの場合、単一の CCoE を設置し、その中で各 CSP 特有のスキル、ツール、メカニズムに特化することで、企業はより成功しやすくなると我々は考えています。CSP ごとに別々の CCoE を設置すると、多くの場合、分断、再設計、無駄が生じがちです。 6. セキュリティが常に最優先事項であることを確認する 複数のセキュリティモデルを管理すると攻撃対象領域が広がり、ギャップが生まれます。マルチクラウドでは、アイデンティティ管理、ネットワークセキュリティ、資産管理、監査ログなど、複数の CSP のセキュリティモデルに対処する必要があります。その結果、複雑さにより透明性が低下し、セキュリティチームの負担が増大し、リスクが高まります。いくつかのセキュリティ実践がより重要になります: (1) セキュリティ運用を自動化し、デリバリパイプライン、クラウド環境、チームの優先事項に組み込むことによって、セキュリティ運用をシフトレフトする、(2) CSP 内または CSP 間で保存中および転送中のデータを暗号化する。 セキュリティ運用データの送信先を1つに絞る ( Single Pane of Glass ) ことが有効です。その上で、各 CSP のクラウドネイティブツールを使用して、その環境に最適なデータを表示します。 7. 均等分散ではなく 80/20 のアプローチを受け入れる CSP間でワークロードをどのように配分するかは、マルチクラウドの成功を左右します。投資の80％をプライマリプロバイダに集中させ、その他のプロバイダを特定機能の利用に限定することで、コストと複雑さを軽減できます。 80/20の配分により、プライマリプラットフォームの高度なサービスの活用を通じたイノベーションが加速します。トレーニングとツールの重複が減り、単一のセキュリティモデルのみ管理すればすみます。 エンジニアが1つのプラットフォームに精通することで、より効率的に構築し、より迅速にトラブルシューティングし、より洗練されたソリューションを実装できます。また、人材の定着にも良い影響があり、多くの技術に跨がってスキルを薄めるのではなく、市場価値の高い専門性を身につけられます。 マルチクラウド環境の管理と監視を簡素化し、どこに保存されていてもすべてのデータへのアクセスを提供し、マルチクラウド環境で生成AIを活用するのに役立つAWSサービスの詳細については、 Multicloud on AWS をご覧ください。 Tom Godden Tom Goddenは、Amazon Web Services (AWS)のエンタープライズストラテジスト兼エバンジェリストです。AWSに入社する前は、Foundation Medicineの最高情報責任者（CIO）として、FDAが規制する世界有数のがんゲノム診断、研究、患者アウトカムプラットフォームの構築を支援し、次世代の精密医療に情報を提供していました。それ以前は、オランダのアルフェン・アーン・デン・レインにあるWolters Kluwer社で複数のシニア・テクノロジー・リーダーを務め、ヘルスケアおよびライフサイエンス業界で17年以上の経験を持ちます。アリゾナ州立大学で学士号を取得。 翻訳はカスタマーソリューションマネージャー 西部 信博が担当しました。原文は こちら です。

物流業界を取り巻く環境は、深刻な人手不足や国際紛争、厳しい法規制などにより、ますます複雑で困難な状況になっています。このような厳しい環境の中でも、倉庫スタッフやトラックドライバー、海運・空運に携わる皆様が、社会基盤である物流を支えるために日々懸命に取り組んでおられることに、心から感謝しております。 一方で、現在の物流ビジネスを持続可能なものとするためには、そうした現場の努力に頼るだけではなく、企業全体あるいは社会全体として無駄をなくし効率化を図ることが必要です。特にデータを活用した改善は、物流DXとして総合物流施策大綱でも長年にわたり強く推奨されてきました。このような状況を受けて多くの物流企業がデータ活用を経営戦略の重要項目として位置付けているものの、実態としては有効な施策が打ち出せずにいるケースが多く見受けられます。これは、多くのシステムが存在するがシステム間のデータの連携が進んでいない、データ分析のスキルや経験を持った人材が少ないといった、物流業界全体として共通する課題あるためです。その打開策として専門のソフトウェアを導入したものの、想定ほどには活用が進まず、有用性に疑問を抱えつつも維持運用コストを負担し続けているような企業も少なくありません。 本ブログではそういった課題に悩まれる物流事業担当者向けとして、データ活用の成功モデルとして日本通運株式会社（以下Nippon Express）のデータ分析基盤「NX Data Station」を解説します。同社は既存リソースを最大限に活用しながら、コスト効果の高いデータ分析基盤を構築し、データを基に業務効率化と意思決定の質向上を実現しています。 以下は2025年7月15日に開催された Amazon SageMaker Roadshow でご登壇いただいた、NX情報システム 髙 為彦 様 および キヤノンＩＴソリューションズ 渡邊 哲也 様のセッション内容をもとに記載しています。特に引用元明記の無いスライドは同イベントでの発表からの引用です。 Nippon Express のデータ分析基盤 NX Data Station 日本最大の総合物流企業である Nippon Express（NXグループ）は、2020年の中期経営計画で「データドリブン経営」を掲げ、「NX Data Station」というデータ分析基盤の開発を開始しました。そこで重視されたのが業務部門や従業員一人ひとりが能動的にデータを利活用していく「ボトムアップ型アプローチ」です。 NX Data Stationの特徴は大きく三つあります。第一に、各事業（海運、航空、自動車、鉄道、倉庫）が別々に保持しているデータを横断的に集約できる点です。第二に、システムにないオフサイトデータやSaaSからのダウンロードなど、手持ちのデータも柔軟に取り込める点です。そして第三に、ダッシュボードによる可視化、機械学習による需要予測、生成AIの活用など、総合的なデータ活用環境を提供している点です。 そしてデータ活用の明確なイメージがあるユーザはこれらの機能を組み合わせて自ら創意工夫して利用できる一方、具体的なイメージや経験のないユーザはカタログ化されたデータ一覧や他部門の利用事例を参照できる環境を整備しています。 このようなアーキテクチャ/運用面の工夫により、Nippon Express のような多くの部門が存在する企業の中でも、データが各部門にまたがって定常的に蓄積され、スキルに合わせて自主的に分析/可視化を行える環境が実現されています。 NX Data Stationの具体的な活用事例の一つが、物流業界の2024年問題など労働力不足という社会課題への対応です。24時間稼働の大型倉庫では一日の労働者数が延べ数百人規模になることもあり、繁忙期・閑散期やキャンペーン・新商品販売などの波動に合わせた人員配置が必要です。 この課題に対して、NX Data Station ではWMS（在庫管理システム）からの入出庫データ、キャンペーン情報、天候データなどを組み合わせた需要予測を実施しています。この予測は作業スタッフのスキルを考慮した最適人員配置のために利用されています。倉庫内作業はマテハンによる効率化も進められていますがまだ人手に頼る部分も多く、このようなデータ駆動型の人員計画の最適化は大きな効果を生み出しています。 グローバル物流においては船会社とのスペース確保やレート交渉といった業務が発生します。この際、海外現地法人から収集したデータを集約・加工する必要がありますが、従来はこの作業に約2ヶ月かかっていました。つまり、2ヶ月前の古いデータに基づいて交渉せざるを得ませんでした。 NX Data Stationの構築により、集約したデータはその日のうちにダッシュボードに反映されるようになりました。これにより、交渉へのリードタイムが大幅に短縮され、直近の鮮度の良い客観的データに基づく多角的分析が可能になりました。この改善は、米国関税、中国籍船舶への課税、スエズ運河通行制限など、急な変化が頻発する現代の国際物流において、迅速な対応力の向上に大きく貢献しています。 さらに注目すべきは、業務部門が自らダッシュボードのメンテナンスやデータ組み合わせの改良を行う自走体制が確立されたことです。これはNXグループが目指すデータ活用文化の醸成 NX Data Station の上で着実に進んでいることを示しています。 NX Data Stationの運用では、キヤノンMJグループによる「伴走支援」が重要な役割を担っています。この取り組みはシステム構築にとどまらず、ハンズオンや勉強会を通じた啓蒙活動、最適なサービスの検討、内製化文化の醸成、自立・自走支援など、データ活用文化の定着を目指しています。その成果として、業務部門が自らダッシュボードを管理・活用できる体制が構築され、持続可能なデータドリブン経営の基盤が形成されつつあります。 AWS上での分析環境構築・運用のベストプラクティスとキヤノンMJグループによる伴走支援 ここからは、NX Data Stationのシステム構成とその運用についてみていきます。NX Data Stationでは、AWS 上でのデータレイク環境の構築についてだけでなく、運用もベストプラクティスにそった形で実施されています。 NX Data Station のアーキテクチャでは、データは全て Amazon S3 に蓄積されています。これはAWS上でのデータレイク構築のベストプラクティスに沿ったものです。 全体の構成としては、まずS3 までのデータ転送には Amazon Appflow や AWS Database Migration Service (DMS) を利用しています。データを蓄積した後は AWS Glue によりデータの前処理とカタログ登録を行い、それを Amazon Redshift (DWH) に格納します。可視化や予測としては、AWS Glue DataBrew (ノーコードデータ準備）、 Amazon SageMaker AI (機械学習)、 Amazon Bedrock (生成AI)、 Amazon QuickSight (BI) を活用する構成になっています。 利用している AWS サービスに共通しているのは、マネージドもしくはサーバーレスといった導入・運用の負担が少ないサービスであるという点です。マネージドサービス・サーバーレスサービスの活用は、基本的なAWS活用のベストプラクティスの1つです。 NX Data Station は最初から現在のような充実した構成になっていたわけではありませんでした。上図のように、最初はスモールスタートし、少しづつデータや利用ニーズの拡大に合わせて体制を整備し、新たなニーズに合わせてシステムを成長させるという方法がとられました。 このスモールスタートで利用状況少しづつ成長させる方式は、データ活用が成功しているユーザーに共通した運営のベストプラクティスです。昨今は分析環境に求められる機能やデータは変化が激しいため、事前に将来のニーズを予測したうえで設計することは不可能です。また、組織（ユーザー）側も新技術・新環境に少しづつ慣れ、習熟していく必要があります。そのため、スモールスタートしつつ、徐々に改善していく事が良い手法とされています。 ※上図はAWSの資料より このスモールスタートから段階的に拡張していくという観点でも、 S3をデータレイクとして活用することが良い方法です。AWSの多くのサービスはS3上にあるデータにアクセスする事が容易であるため、S3を中心にすることで、後から多様なサービスを活用することが可能になります。 ※上図はAWSの資料より また、多くのデータ分析関連サービスがサーバーレスで提供されているため、導入の負担が少ないだけでなく、運用面での調整負担も少なくすることが可能です このようなスモールスタートからの改善の繰り返しを支えているのが、キヤノンMJグループ（キヤノンITS）による伴走支援です。最初に決めた開発要件に合わせて成果物を構築・納品するといった方法ではなく、あくまでデータ活用の主体を Nippon Express 側におきつつ、継続的に側面から支援する方法です。図の中央にある データマネジメント推進チームの中では以下のような活動を行いました。 ・データスチュワード：データ活用の現場とシステムの間を取り持ち全体をリード ・データエンジニア：データ活用前の加工部分を技術支援 これらはあくまで伴走であり、主体である機械学習であればAIエンジニア/サイエンティスト、可視化であればBIエンジニア/アナリストが自走できることを目指しています。また、このような活動の中から生まれたニーズに対応するために、システムの継続的な改善も行われてきました。 このような活動の結果を数値でとらえることも重要なポイントです。環境が本当に活用されているのかという事を把握し、そこから次の改善を検討することが可能になるからです。NX Data Station では250以上あるBI (QuickSight)ダッシュボードの利用状況を自動的に収集しています。このデータによると現在、月々のBIダッシュボード参照回数が22,000回以上あります。 このように利用状況を把握したうえで、改善にも務めています。例えば業務の現場から意見をヒアリングしたり、利用が進むようなトレーニングを提供したり、もしくは課題を発見して新技術で対応したりといった形です。 例えば、NX Data Station では現在カタログを SharePoint上のドキュメントで管理しています。このカタログはITシステム連携していないため、IT側の変更の反映が手作業になっていたり、カタログで必要なデータを見つけても、そのデータにアクセス可能にするにはIT側に設定変更を依頼する必要がある等、課題の1つに挙げられています。今後は 次世代の Amazon SageMaker を導入することで、IT側の変更反映の自動化や、データアクセスを可能にするまでの自動化を実施していく予定です。 このようにスモールスタートした後にニーズを吸収しつつ広げていく手法は、上記のようなIT面の改善だけでなく人材育成や組織の連携の改善などにも及んでおり、これはまさにAWS上で分析環境を成長させる上でのベストプラクティスに沿っていると言えるでしょう。 まとめ 本稿では、NX Data Stationの事例を通して、物流業界が抱える課題と、データ活用による解決策について解説いたしました。既存データを最大限に活用しながら、コスト効果の高いデータ分析基盤を構築することで、業務効率化と意思決定の質向上を実現することができました。この成功の要因となったのは、ボトムアップ型のデータ活用アプローチと、AWSのマネージドサービスを活用したシステムの段階的な発展です。 また、データ活用はシステムを導入すればうまくいくというものではないというのも本事例から学べる重要なポイントでしょう。最初からどのような仕組みが必要かを完全に予測することは不可能であり、継続的に改善できるITの仕組みと人員体制にすることが重要です。本事例では、キヤノンMJグループが継続的な「伴走支援」を提供しており、Nippn Express側もパートナーに依頼したままにするのではなく、自グループ内でのデータ活用文化の醸成のための改善を続けており、これが大きな成果につながっています。 著者について 横山 誠：2019年より AWS Japan のソリューションアーキテクトとして、主に物流業のお客様に技術支援を行っています。機械学習を用いた需要予測や最近では生成AIの活用など幅広い領域でお客さまに役立つ情報をご提供しています。以前は通信キャリア様でのアプリケーション開発やデータベース製品のコンサルタントをしていました。今でも日本語よりSQLを書く方が得意です。 下佐粉 昭：2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 アップデートの前に一つ宣伝させてください。 AWS Innovate の次回開催が決まり、登録ページが公開されています。今回は、マイグレーション＆モダナイゼーションがテーマで、実践手法とそれを支えるAWSテクノロジーを学ぶことができる内容となっています。ご調整の上、ぜひご参加ください！ AWS Innovate: Migrate and Modernize 2025 年 9 月 18 日 | 13:00 – 17:20 登録は こちら それでは、先週の主なアップデートについて振り返っていきましょう。 2025年8月4日週の主要なアップデート 8/4(月) Amazon ECR now supports 100,000 images per repository Amazon ECR で、1つのリポジトリあたりに保存できるイメージの上限が、従来の 20,000 個から 100,000 個に拡張されました。コンテナアプリケーションの開発が進むにつれて大量のイメージを管理する必要がある場合に、これまでのような上限緩和申請の手間が不要になります。この上限は既存のレジストリにすでに適用されており、すべての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用可能です。ECR サービスのデフォルト上限の詳細については、 ドキュメント をご確認ください。 Mountpoint for Amazon S3 CSI driver accelerates performance and supports SELinux Mountpoint for Amazon S3 CSI ドライバー v2 がリリースされました。今回大きく4つの機能追加がされました。複数の Pod 間でのデータキャッシュにより繰り返しアクセスされるデータのパフォーマンス向上、SELinux サポート、Amazon EKS Pod Identity を使用したAmazon EKS クラスター全体でのアクセスポリシーの管理方法を簡素化。最後にkubectl を使用してログにアクセスしマウント情報を取得する方法を簡素化するものです。アップグレード方法は インストールガイダンス 、操作の詳細は ドキュメント を各々ご確認ください。 Amazon SQS increases maximum message payload size to 1 MiB Amazon SQS で送信できるメッセージの最大サイズが従来の 256 KiB から 1 MiB に拡大されました。これまでは256 KiB以上のデータを扱う際に複数メッセージに分割したり外部ストレージに保存する必要がありましたが、今回のアップデートで この手間をかけずに直接やりとりできるデータが増えることで利用シーンが広がります。この機能リリースと併せて、SQS 向けの AWS Lambda のイベントソースマッピングも 1 MiB ペイロードをサポートされています。この機能はすべての AWS 商用リージョンおよび AWS GovCloud (US) で利用可能です。詳細は ドキュメント をご確認ください。 Amazon CloudWatch introduces organization-wide VPC flow logs enablement Amazon CloudWatch で、組織全体の VPC フローログを自動的に有効化できるようになりました。これまではVPC ごとに手動で設定する必要がありましたが、CloudWatch テレメトリ設定で有効化ルールとAWS Config Service-Linked Recorderにより、ルールに合致する既存および新規のVPCで自動的に有効化できます。この機能は東京、大阪を含む17のリージョンで利用可能です。詳細は ドキュメント をご確認ください。 8/5(火) Amazon OpenSearch Serverless now supports backup and restore Amazon OpenSearch Serverless がバックアップとリストア機能をサポートしました。この機能は自動的に有効化され、全てのコレクションとインデックスは自動的にバックアップおよび14日間保持されるため運用負荷を軽減できます。また、利用したい際はAPIを使用して復元できます。OpenSearch Serverless&nbsp;の詳細は ドキュメント をご確認ください。 AWS announces general availability of Amazon Elastic VMware Service (Amazon EVS) Amazon Elastic VMware Service (Amazon EVS) が一般提供が開始されました。これにより、従来の VMware 環境をそのまま Amazon VPC 内で実行できるようになります。既存の VMware スキルを活かしながら AWS の拡張性や性能を利用でき、アプリケーションの再構築が不要になります。オンデマンド利用のほか、1年、 3 年間の利用オプションも提供されるため、利用期間と状況に応じて柔軟な選択が可能です。Amazon EVSは東京を含む 6 つのリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Anthropic’s Claude Opus 4.1 now in Amazon Bedrock Amazon Bedrock が Anthropic の最高知能モデル Claude Opus 4.1 を提供開始しました。従来の Opus 4 から置き換え可能で、コーディングや AI エージェント機能が大幅に向上しています。複雑な開発タスクを独立して計画・実行でき、フロントエンドコード生成やマルチステップタスクの処理精度も従来のOpus 4 から向上しています。この機能はオレゴン、バージニア北部、オハイオ リージョンでご利用可能です。 8/6(水) OpenAI open weight models now in Amazon Bedrock and Amazon SageMaker JumpStart Amazon Bedrock と Amazon SageMaker JumpStart で OpenAI のオープンウェイトモデル gpt-oss-120b と gpt-oss-20b が利用可能になりました。OpenAI オープンウェイトモデルは、コーディング、科学的分析、数学的推論タスクに優れており、両モデルとも 128K コンテキストウィンドウを備え、特定の要件に合わせて推論レベル (低/中/高) を調整することができます。Amazon Bedrock の統一された API を通じてこれらのモデルにアクセスでき、コードを書き直すことなく他のモデルとシームレスに実験や切り替えが可能です。これらのモデルはAmazon Bedrock では オレゴン リージョンで、Amazon SageMaker JumpStart では東京、ムンバイ、オハイオ、バージニア北部の各リージョンで利用可能です。詳細については ブログ も公開されているのでご確認ください。 Amazon OpenSearch Serverless introduces automatic semantic enrichment Amazon OpenSearch Serverless にセマンティック検索の実装を簡単にする、自動セマンティック強化機能が追加されました。例えば「頭痛治療」で検索すると「偏頭痛対処法」も結果に含まれるようなセマンティック検索の実装には、従来はMLの専門知識、モデルホスティング、OpenSearch 統合が必要でした。この機能はそれを簡素化し、対象フィールド指定のみでデータ取り込み中に自動処理されます。英語のみと多言語を選択でき、多言語は日本語を含む 15 言語に対応しています。東京を含む11のリージョンで利用可能です。詳細は ドキュメント や ブログ をご確認ください。 Amazon EC2 M7i and M7i-flex instances are now available in Asia Pacific (Osaka) Region Amazon EC2 の M7i と M7i-Flex インスタンスが、新たに大阪リージョンで利用可能となりました。このインスタンスはカスタムされた第4世代の Intel Xeon プロセッサー (Sapphire Rapids) が搭載されており、M7i はM6i と比較して最大 15 % 優れたコストパフォーマンスを実現します。また、M7i-Flex は、 M7i をより安価に利用出来る汎用的なインスタンスタイプです。通常 CPU 利用率は、低い時期と高い時期があるのが一般的ですが、Flex インスタンスは常時 100 % の力を発揮しなくても良いような利用方法に適したタイプです。CPU 性能の 40 % をベースラインとして常時提供し、ベースラインの 40 % を超える場合、95 % の確率で 100 % までスケールアップする仕組みを提供するものです。 8/7(木) Amazon Aurora Serverless v2 now offers up to 30% performance improvement Amazon Aurora Serverless v2 のプラットフォームバージョン 3 が公開され、最大 30 % パフォーマンスが向上しました。このプラットフォームバージョンは0から256ACU (Aurora Capacity Units) までのスケーリングに対応しています。ACU は約 2 GiB のメモリと CPU、ネットワークの組み合わせで、アプリケーションの需要に応じて自動スケールします。今回のパフォーマンス向上により、従来よりも高負荷なワークロードでも Aurora Serverless が活用できるようになりました。AWS GovCloud (US) リージョンを含むすべての AWS リージョンで利用可能で、既存のクラスターもクラスターの再起動もしくはBlue/Green Deployments を使用したアップグレードが可能です。できます。詳細は ドキュメント をご確認ください。 Amazon OpenSearch Serverless adds support for Hybrid Search, AI connectors, and automations Amazon OpenSearch Serverless が Neural Search、Hybrid Search、AIコネクター などの新機能をサポートしました。Neural Search では画像やテキストを使ったセマンティック検索、Hybrid Search は複数の検索手法を組み合わせての検索精度を向上を実現する機能です。また、Workflow API はモデル、コネクタ、パイプラインなどの OpenSearch AI リソースをテンプレートにパッケージ化して、Neural Search などの AI 機能を有効にするために必要な設定を自動化します。これらによりRAG (検索拡張生成) のような AI アプリケーションの構築がより手軽になります。この機能は東京を含む11のリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon EKS adds safety control to prevent accidental cluster deletion Amazon EKS で削除保護をする機能が追加されました。これまで EKS クラスターの誤削除を防ぐ仕組みはありませんでしたが、今回のアップデートにより 2 段階の確認プロセスでクラスターを削除保護が可能です。具体的には、AWS コンソールや CLI から削除操作をした際、一時的に削除がブロックされ、明示的に保護を無効化してからでないと削除できないようになります。これにより複数メンバーでクラスターを管理する開発チームや、自動化スクリプトによる誤操作が心配な本番環境での運用がより安全になります。この機能は、すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで利用できます。詳細は ドキュメント をご確認ください。 AWS Lambda now supports GitHub Actions to simplify function deployment AWS Lambda が GitHub Actions との統合をサポートし、サーバーレスアプリケーションのデプロイが大幅に簡単になりました。従来は Lambda 関数をデプロイするためには AWS CLI コマンドやカスタムスクリプトを書く必要があり、コードのパッケージング、IAM 権限設定、エラーハンドリングを手動で行う必要がありました。今回のアップデートにより GitHub Action を介して、GitHub リポジトリにコードをプッシュするだけで Lambda 関数が自動デプロイされ、CI/CD パイプラインを大幅に簡素化することができます。この機能は zip ファイルとコンテナイメージ両方のデプロイに対応し、OIDC 認証を使用して IAM とシームレスに統合されます。詳細は Lambda デベロッパーガイド と「Deploy Lambda Function」GitHub アクションの README をご確認ください。 8/8(金) Amazon SageMaker レイクハウスアーキテクチャが Apache Iceberg テーブルの最適化設定を自動化 Amazon SageMaker lakehouse アーキテクチャで Apache Iceberg テーブルの最適化設定が自動化されました。従来は各テーブルごとに個別設定が必要でしたが、今回のアップデートによりカタログレベルの設定により Amazon S3 に保存された Apache Iceberg テーブルの最適化を自動化し、メタデータのオーバーヘッドを削減してクエリパフォーマンスを向上させます。この機能を有効にすると、新しいテーブルまたは更新されたテーブルに対して、小さなファイルの圧縮、スナップショットの削除、不要になった参照されていないファイルの削除等が継続的に最適化され、ストレージコストの制御とクエリの高速化を実現します。東京を含む15のリージョンで利用可能です。詳細は ブログ と ドキュメント をご確認ください。 Amazon ECS コンソールが Amazon CloudWatch Logs Live Tail による リアルタイム ログ解析をサポート Amazon ECS コンソールで Amazon CloudWatch Logs Live Tail が利用可能になりました。これまでコンテナのログをリアルタイムで確認するには CloudWatch コンソールに移動する必要がありました。今回のアップデートにより ECS コンソール内で直接ログ監視が可能になります。これによりアプリケーションのトラブルシューティングやデプロイメント失敗の調査時に、コンソールを切り替えることなく効率的に作業できるようになります。詳細は ドキュメント をご確認ください。 Amazon Connect がリアルタイムキュー内位置取得 API を開始 Amazon Connect で、リアルタイムキュー内位置を返す新しい API が使えるようになりました。従来は顧客がどの位置で待っているかを正確に把握できませんでしたが、この API により待ち時間をより正確に推定し、プライマリキューと代替キュー間で情報に基づいたルーティング決定できるほか、長い待ち時間が予想される場合にコールバックなどの代替案を積極的に提案できるようになります。また、これにより顧客満足度向上と離脱率削減を同時に実現できます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

2025 年 6 月 から 7 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Aurora 概要編 AWS が提供するマネージドデータベースサービスである Amazon Aurora の概要をご紹介します。本コンテンツは Amazon Aurora の全体像、アーキテクチャについての基礎を取り扱います。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora の概要、他のデータベースとの違いを抑えたい方 本 BlackBelt で学習できること Amazon Aurora の概要および他のデータベースとの違いを抑えることができる スピーカー 藤田洋平 データベーススペシャリストソリューションアーキテクト Amazon Aurora 概要編 – コスト最適化 AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特にコストの削減方法についてフォーカスしてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora をご利用中で、コスト削減を検討中の方 本 BlackBelt で学習できること Amazon Aurora をご利用いただく際のコスト最適化手法として、Aurora のコスト構造の理解から費用の確認方法をご理解いただけます。その上で、コスト削減アプローチとしてインスタンスタイプの変更や、Reserved Instance の利用、Serverless V2 や IO Optimized の概要についてご理解いただけます。 スピーカー 西原 陽介 シニア テクニカル アカウント マネージャ Amazon Aurora 概要編 – 可用性 – 前半 AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特に可用性についてフォーカスしてご紹介するコンテンツの前半です。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora の可用性に関する機能について抑えたい方 本 BlackBelt で学習できること Amazon Aurora の概要をおさらいしつつ、まず一般的なデータベースにおける可用性の考え方を学習できます。その上で Amazon Aurora の高可用性を担保するアーキテクチャについてもご理解いただくことができます。 スピーカー 髙橋 敏行 パートナーソリューションアーキテクト Amazon Aurora 概要編 – 可用性 – 後半 AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特に可用性についてフォーカスしてご紹介するコンテンツの後半です。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora の概要や高可用性アーキテクチャについて抑えたい方 本 BlackBelt で学習できること Amazon Aurora の概要をおさらいしつつ、まず一般的なデータベースにおける可用性の考え方を学習できます。その上で Amazon Aurora の高可用性を担保するアーキテクチャについてもご理解いただくことができます。 スピーカー 髙橋 敏行 パートナーソリューションアーキテクト Amazon Aurora 概要編 – 性能とスケーラビリティ AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特に性能、スケーラビリティにフォーカスしてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora における、特に性能面について抑えたい方 本 BlackBelt で学習できること Amazon Aurora にて如何に性能を担保しているか、アーキテクチャや機能について学習できます。また Aurora Serverless V2 についても学習することができます。 スピーカー 鈴木 大樹 ソリューションアーキテクト Amazon Aurora 概要編 – 移行支援プログラム・サービス AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特に Aurora への移行支援プログラムや移行方法についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora への移行における AWS による支援サービスやツール、また移行方式を把握したい方 本 BlackBelt で学習できること 主に Amazon Aurora への移行ステップや課題を理解し、その上で AWS が提供する移行支援プログラムである Database Freedom Workshop の概要や、Database Migration Service (DMS) や Schema Conversion Tool(SCT) といった移行ツールの概要を抑えていただけます。 スピーカー 長久保 武 データベース スペシャリスト ソリューション アーキテクト AWS Database Migration Service ベストプラクティス – 実践編 AWS Database Migration Service は、オンプレミスから AWS へのデータベース移行や異なるエンジン間でのデータ連携など、データベース間でのデータ移行に役立つデータベースサービスです。難易度の高いデータ移行が容易に移行できるようになることから、多くのお客様のデータ移行で採用頂いています。本セミナーでは、データベースのデータ移行におけるモニタリングやチューニングのノウハウやベストプラクティスについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Database Migration Service を用いたデータ移行を計画し環境構築を進めようとされている方 どのような観点をモニタリングするべきかについて学びたい方 動作性能の向上に向けて確認すべき点や取り得る方法について知りたい方 本 BlackBelt で学習できること データ移行の実現に際して、重要なパラメータおよび関連する AWS Database Migration Service の動作や推奨の設定について 動作の状況を把握するためにモニタリングするべき点について 動作のチューニングに向けて、確認するべき項目と性能改善に向けて取り得る手法について スピーカー 大井 基彰 クラウドサポートエンジニア PrivateLink and Lattice – AWS PrivateLink 編 AWS PrivateLink は、トラフィックをパブリックインターネットに公開することなく、AWS でホストされるサービスやリソース、オンプレミスネットワーク間にプライベート接続を提供するサービスです。本セッションでは、AWS PrivateLink の概要やユースケースなどについて学べます。前編として、Amazon VPC Lattice 編もありますので、そちらも合わせてご覧ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS を利用される予定のネットワーク担当者の方 AWS のネットワーク設計を担当している方 AWS PrivateLink に関⼼がある、または深く学びたい方 本 BlackBelt で学習できること AWS PrivateLink の概要や、AWS PrivateLink で接続させたいサービス別の詳細、ユースケースなどについて学べます。 スピーカー 武松 未来 ソリューションアーキテクト Amazon CloudFront（基礎編） AWS Black Belt Online Seminar Amazon CloudFront の基礎編になります。本コンテンツでは、Amazon CloudFront の概要と基本的な設定方法について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 CDN の利用を検討している方 Amazon CloudFront をこれから利用したい方 Amazon CloudFront の基本的な使い方を学びたい方 本 BlackBelt で学習できること 初めて Amazon CloudFront を利用する方に向けて、全体像を掴むことができる内容となっています。ディストリビューション、ビヘイビア、オリジンといった各構成要素の設定や、その他の主要機能について知ることができます。 スピーカー 鈴木隆昭 プロフェッショナルサービス AWS Direct Connect 概要〜これだけはおさえておきたいこと〜 AWS Direct Connect の基本から実践まで学べる Black Belt Online Seminar を公開しました。本セミナーでは、Direct Connect の基本機能、VPC との接続パターン、高可用性を実現する冗長構成など、実務で押さえておくべきポイントについて解説しています。AWS 環境でのネットワーク設計をご検討中の方は、ぜひご覧ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS クラウドに関わるエンジニアの方 AWS Direct Connect の基本を学びたい方 これから AWS Direct Connect を検討されるシステム担当者 オンプレミスと AWS Cloud を閉域網で接続する要件をお持ちの方 本 BlackBelt で学習できること AWS Direct Connect の基本的な機能と接続パターンを理解する AWS Direct Connect の冗長構成の基本を理解する 詳細情報へのポインタを得る スピーカー 齋藤 優弥 ソリューションアーキテクト 認証・認可サービス構築 on AWS 〜デザインパターンと Amazon Cognito 活用プラクティス〜 AWS 上に CIAM システム、認証・認可基盤を構築するためには、シーケンス、ビジネスユースケース、デザインパターンの理解が欠かせません。本書では Amazon Cognito、あるいは IDaaS や OSS、独自構築の IdP を組み合わせた目的別の多様なアイデンティティ・アーキテクチャをご紹介します。 資料（ PDF ）&nbsp; 対象者 CIAM システムや OAuth2 や OpenID Connect を活用した認証・認可システムを構築したいと考えている方 認証・認可システムを構築する際に Amazon Cognito をどう使うとやりたいことを実現できるのか、その他の選択肢はどのようなものか知りたい方 技術とユーザー体験の両面から、認証・認可システムが実現するアイデンティティ・アーキテクチャに対して理解を深めたい方 本 BlackBelt で学習できること CIAM システムあるいは認証・認可システムを AWS 上に構築する際の、目的別のアイデンティティアーキテクチャを学ぶことができます。 Amazon Cognito をどのように利用することができるか、あるいは別の手法を利用する際の判断ポイントやメリットについて理解できます。 関係者との効果的かつ適切な議論を行うために、多様なアーキテクチャのパターンを共通言語として活用できるようになります。 スピーカー 勝原 達也 シニア セキュリティ ソリューション アーキテクト AWS Transfer Family 本セッションを視聴することで、AWS Transfer Family とはどのようなサービスか説明できるようになります。また、AWS Transfer Family の FTP/FTPS/SFTP を用いたファイル転送機能を理解することができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Transfer Family の全体像を知りたい方、AWS Transfer Family の FTP/FTPS/SFTP を用いたファイル転送機能を知りたい方を対象としております。 本 BlackBelt で学習できること AWS Transfer Family の基本的な機能、AWS Transfer Family における FTP/FTPS/SFTP を用いたファイル転送の流れ、アクセス管理機能を知ることができます。 スピーカー 佐藤 真也 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-08 AWS Elemental Media Services を利用した動画配信について（基礎編） ソリューションアーキテクト 石井 悠太

みなさん、こんにちは。アマゾン ウェブ サービス (AWS) ジャパン合同会社 AI / ML 事業開発チームの近藤 祐丞です。業務への実装が進む生成 AI で汎用の大規模 LLM に加えて特定の業界やタスクに特化したモデルを開発される会社が増えてきています。 本日は、 AWS ジャパンの生成 AI 実用化推進プログラム を通じて独自の大規模言語モデルを開発された野村総合研究所 (NRI) AI ソリューション推進部の岡田智靖様、大河内悠磨様に AWS 目黒オフィスに来社頂き、「業界タスク特化型 AI モデルの開発」をテーマに NRI 様が開発されたモデルの技術的な特徴や今後のビジネスへの適用構想について、 AWS 生成 AI イノベーションセンター の畔柳竜生から質問させて頂きました。 業界タスク特化型モデルの開発に関して 畔柳 近年生成 AI の業界では Anthropic や OpenAI、Google、Amazon といった企業が、汎用的な大規模言語モデル (Large Language Model、LLM) の開発を行っております。その一方で 2024 年後半頃から汎用モデルに囚われない業界特化型モデルを開発されるお客様が急速に増えていると感じています。その中でも NRI 様は早い段階から特化型モデルの開発を開始されて、保険業界の営業コンプライアンスチェック試験において、商用大規模モデルを上回る正解率を実現しています。なぜ業界タスク特化型モデルが求められているのか、その開発背景を教えていただけますでしょうか？ 岡田 特化型 LLM が必要な理由は大きく3つあります。 1つめの理由は専門知識への適用です。業界・業種問わず、企業が実施している業務の中には業界の専門知識が必要なものや、その企業特有のルールやスタイルで行われている業務が多いのが実状です。そういった専門知識を学習させて個別のタスクを効果的にこなすような LLM の存在が求められています。 2つめは推論コストです。特化型 LLM は初期の学習コストはかかりますが、一度できれば少ない計算量で効率的に専門業務のタスクをこなす事が可能です。専門知識をロングコンテキストや Retrieval Augmented Generation (RAG)で与えるよりも運用コストが安く収まり、Total Cost of Ownership (TCO) を削減することが期待できます。 ３つめは安心・安全を考慮したコントロール性です。機密情報や個人情報が含まれるデータを SaaS の API に流すことに抵抗を感じたり、ルール上 NG としている企業は多いと考えています。加えて、専用 LLM があればモデルのバージョンが勝手に変わることがなく安定した回答が期待できます。 野村総合研究所 岡田智靖 様 畔柳 ありがとうございます。汎用モデルが学習することのできない専門知識を学習させることにより、大規模なモデルとの差別化を実現しているという事ですが、実際に業界タスク特化型モデルを開発される上で工夫された点を教えて頂けますでしょうか。 大河内 今回のモデル学習では業界知識の継続事前学習とタスク特化のファインチューニングを組み合わせた 2 段階アプローチを採用しました。学習データのデータセット作成には自動化パイプラインを構築し、特定の専門領域に関するテキストの自動収集や合成データを使ってバリエーションを拡大しました。これにより、LLM が業界特有の専門知識を獲得するとともに、実施したいタスクに適した振る舞いをするように学習することができました。 畔柳 AWS ジャパンでは生成 AI 実用化推進プログラムを通して、生成 AI のビジネス活用を目指す日本のお客様を支援しており、今年もこのプログラムへの応募を募集しています。NRI 様も 金融特化型 LLM の開発 の際にこのプログラムを活用していただきましたが、このプログラムを活用して良かった点や、このプログラムの活用を検討されているお客様へのアドバイスなどがあれば、ぜひお願いします。 岡田 テクニカル面とビジネス面の両方の面で、丁寧にサポートいただいたことが非常によかった点です。テクニカル面では、 AWS ParallelCluster や Amazon SageMaker などの AWS のサービスや、AWS 製 AI チップの AWS Trainium と AWS Inferentia の利用にあたって重点的にサポート頂けました。ビジネス面でも、特化型 LLM をどのようなユースケースで利用するかについてのディスカッションやミートアップへの参加、様々なプロモーションの機会も頂くことができました。 畔柳 テクニカル面では私自身が所属する AWS 生成 AI イノベーションセンターからも支援に入らせて頂きました。生成 AI に特化したグローバルチームである AWS 生成 AI イノベーションセンターでは、生成 AI の本番活用を見据えた PoC やアドバイザリも実施しています。実際に生成 AI イノベーションセンターからの支援を受けた感想などがあれば教えてください。 岡田 確かな専門家の方々にサポートいただいて心強かったです。PoC として範囲を定義した形で支援いただき、サンプルコードの提供や技術的なトラブルシューティング、最終レポートの提供も含め期待以上にサポート頂くことができました。また今後さらに柔軟にサポート頂けるメニューがあると嬉しいです。 畔柳 ありがとうございます。AWS の生成 AI に関わるユニークな点として自社で AI 用アクセラレータチップを開発し、それを搭載したコンピュートリソースをお客様にサービスとして提供している事があります。昨年の re:Invent では Amazon EC2 Trn2 インスタンス の一般利用開始を発表するとともに、AWS として AI チップの開発への継続的投資を行うことを発表しています。生成 AI 実用化推進プログラムの際に NRI 様でも、 Trn1 インスタンス と専用の SDK である AWS Neuron を用いた分散学習を行うことで、GPU を利用した場合と比較して 40% のコスト効率の改善ができること発表いただいています。AWS の AI チップ開発に関する取り組みについてのコメントや実際利用していただいた感想などがあれば、教えていただけると助かります。 大河内 はい、GPUと比較してコスト効率が良いのはメリットを感じています。また、AWS 内製のため、サポートが期待でき、安心できる点も大きいです。実際に利用してみてコスト効率のメリットも実感し、リソースが豊富にあるため確保しやすいメリットも感じました。 野村総合研究所 大河内悠磨 様 今後の展開とビジネス戦略 畔柳 日本では経済産業省・NEDO が GENIAC プログラム を実施する形で、国としても国産の LLM 開発を促進しています。このプログラムに採択されたお客様にも、AWS 上のコンピュートリソースを活用して LLM 開発を実施していただいております。2025 年に募集が行われた GENIAC Cycle 3 には NRI 様も採択されました。おめでとうございます。国が LLM 開発の促進を行っていることについて民間企業という観点からどのように感じていらっしゃるか、また GENIAC Cycle3 では NRI 様としてどのような開発に取り組んでいこうと考えていらっしゃるか教えて頂けますでしょうか。 岡田 国の生成AIの発展に大きく寄与することができる、素晴らしい活動だと考えています。国から認められることによって、NRI も生成 AI の開発ができる企業としてアピールすることができます。また、まとまった形で確保しにくい計算資源を確保する機会として活用することができます。 NRI としてはこれまでに開発してきた小規模の業界・タスク特化型 LLM から大きく方向性は変えませんが、規模を 10B-40B の中規模モデルに拡大して、様々な業界やタスクに適用可能な特化型モデル構築のプロセスを確立する事を計画しています。様々なモデルをベースに検証する他、タスクの種類も増やして金融業界向けの構築と検証をしたいと考えています。GENIACに採択されることによって、こういった規模を拡大した学習にもチャレンジできるようになりました。 アマゾンウェブサービス合同会社 畔柳 竜生 畔柳 今後 NRI 様が開発された業界タスク特化型モデルがどのように活用されていかれるのか、ビジネス展開を教えて頂けますでしょうか？ 岡田 AI エージェントとの連携や NRI が開発した業界・タスク特化型モデルを私達が持っているお客様向けサービスの中に組み込んでいくことを計画しています。実際のお客様への業務適用が始まりつつありますが、これをどんどん進めていきたいと考えています。また今後の展望として、流通・小売や製造業、システム開発など、他の業界やタスクにも展開していきたいと考えています。 畔柳 最後になりますが生成 AI 実用化推進プログラムの最終発表会での NRI 大河内様のプレゼンテーション後の懇親会では、参加されていた多くの方々が大河内様を囲んで質問攻めにしていたのを覚えています。NRI 様として、同じように業界タスク特化型 LLM 開発を目指される開発者の方々にアドバイスなどがあればよろしくお願いします。 大河内 プログラムの懇親会では、自分達でも業界タスク特化型 LLM の学習を試したけれどもなかなかうまく行かなかったという相談が多かったです。実際に開発をしてみると様々な試行錯誤や工夫が必要なことが分かると思いますので、まずはベースモデルの選定やデータセットの設計など色々な視点で試して頂くのが良いと考えています。 今回のインタビューを実施した野村総合研究所様とAWSメンバー 執筆： 畔柳 竜生、帆足 啓一郎、飯塚 将太、近藤 祐丞、本橋 和貴、常世 大史、山上 哲史

2025年7月4日、 経済産業省と国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が実施 する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の第3期 (2025年4月公募) における採択事業者のキックオフが行われ、本事業の採択事業者が発表されました。今回 AWS は NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンス ( p5.48xlarge )、NVIDIA H200 Tensor Core GPU を搭載するAmazon EC2 P5en インスタンス ( p5en.48xlarge ) 等の学習・推論に必要な仮想サーバーに加えて、採択事業者のニーズに合わせ Amazon SageMaker HyperPod および Amazon EC2 Trn2 インスタンス を提供します。 AWS は、 GENIAC バーチャルチーム を組成し、以下の支援を提供します: 計算資源 : Amazon EC2 P5, P5en, Trn2 インスタンス、あるいは Amazon SageMaker HyperPod の提供、 技術支援 : AWS Solutions Architect (SA) を中心としたメンバーにより、コンピュート (EC2)・ネットワーク ( Elastic Fabric Adapter (EFA) )・ストレージ ( Amazon FSx for Lustre および Amazon S3 ) で構成される分散学習環境の AWS ParallelCluster や SageMaker HyperPod を活用した構築・管理の支援、 開発者コミュニティ支援 : 海外モデルプロバイダーの開発メンバーとの 交流イベント による最先端の開発動向調査や 海外視察 、国内の機械学習エンジニア同士の交流による知見共有をはじめとした Meetup の実施、 事業化支援 : GENIAC を通じて開発された基盤モデル・生成 AI アプリケーションの Amazon Bedrock Marketplace 、 AWS Marketplace の活用による go-to-market (GTM) 支援、利用企業との AWS 主催イベントを通じたマッチング機会の提供。 これらは、経済産業省商務情報政策局情報処理基盤産業室、NEDO、ボストン コンサルティング グループ (BCG)、および AWS パートナーであるクラスメソッド株式会社と密に連携のうえで提供されます。 採択事業者のうち AWS を利用する事業者は以下です (現時点で承諾が得られたもののみを掲載): SDio株式会社 カラクリ株式会社 Sansan株式会社 ストックマーク株式会社 Zen Intelligence株式会社 Degas株式会社 Direava株式会社 Nishika 株式会社 株式会社野村総合研究所 株式会社Preferred Networks ONESTRUCTION株式会社 株式会社リコー 採択事業者からコメントを頂きました: GENAICサイクル3において、エンタープライズ向けの大規模映像基盤モデル（LVM）の開発に取り組むにあたり、AWSのEC2 P5インスタンス および AWS ParallelCluster を活用することで効率的に研究開発を進めることができると考えております。多方面での実用的なサポートをいただき大変感謝しております。 — SDio株式会社 代表取締役 カイ アバ AWS様には第2期に続き、GENIAC第3期でも生成AI開発の基盤としてご支援いただいております。引き続きAWS Trainiumを活用することで、学習コストを抑えつつ高性能なモデル開発を実現できており、大変心強く感じております。 また、インフラの安定性やドキュメントの充実度に加え、技術だけでなくビジネス面も含めた総合的な支援により、スピード感をもって開発を推進できています。今後もAWS様との連携を通じて、より実用的かつ価値ある生成AIの社会実装を目指してまいります。 — カラクリ株式会社 CPO 中山 智文 Sansan株式会社では、文書特化基盤モデル「Viola」をスクラッチで開発し、自社プロダクトのデータ化プロセスに導入しています。GENIACサイクル3では、EC2 P5インスタンスを用いて「Viola」を拡張し、Visual Grounding機能を搭載した「Cello」を開発します。AWSの高性能コンピューティングリソースを活用することで、ビジネスインフラとして働き方に革新をもたらすことを目指します。 — Sansan株式会社 技術本部 研究開発部 Automationグループ 研究員 内田奏 「製造業等で扱われる複雑でハイコンテクストな資料を実用レベルで読み解けるAIは未だに存在しておらず、ストックマークはこの領域での更なる強力な基盤モデルの開発にGENIACサイクル3では挑戦致します。強力なモデルの構築には、大規模でも実行効率高くかつ安定的に動くマルチノードGPUクラスタが不可欠であり、GENIACサイクル2に続いてAWSを活用させていただくことと致しました。」 — ストックマーク株式会社 取締役CTO 有馬 幸介 氏 Zen Intelligenceでは、Physical AIを通して建設業界の社会課題解決を目指しております。 GENIAC 第3期では、AWS様のAmazon EC2 P5enインスタンスを活用させて頂き、建築現場の施工管理を自動化する基盤モデルの開発を加速させていきます。 AWS様には、今後も大規模なモデル開発を進める上で多様かつ有用なサービスを期待しておりますとともに、多大なご支援感謝致します。 — Zen Intelligence CEO 野﨑 大幹 Degasは、先端AIと衛星観測データの力で、発展途上国の課題解決に挑むスタートアップです。今回のGENIAC採択を受け、衛星データ解析の直感性と実用性を飛躍的に高めるリモートセンシング用視覚言語モデル（VLM）の開発に取り組みます。 開発においては、Amazon EC2 P5インスタンスを活用し、大規模な基盤モデルの学習を効率的に推進します。AWS様と協力しながら、柔軟性とスケーラビリティを兼ね備えたインフラを活用し、AIの社会実装に向けた技術革新をさらに加速してまいります。 — Degas株式会社 CTO 中山 洋平 弊社は、GENIACにおいて手術支援のためのVision-Language統合AI基盤モデル開発に注力します。この革新的な取り組みにおいて、AWSが提供するEC2 P5インスタンスやAWS ParallelClusterといった最先端のインフラを最大限活用できることに深く感謝しております。 これらの強力なサポートを得て、術中の判断支援や意思決定を助ける生成AIの開発を効率的に推進し、医療現場の安全性と質の向上に貢献していきます。 — Direava株式会社 CTO 斎藤 洸輔 氏 GENIAC Cycle3に採択され、世界初のBIM情報要件（IDS）生成基盤モデルの開発に着手します。本プロジェクトではAWSのEC2 p5en.48xlarge（NVIDIA H200搭載）を活用します。AWSの圧倒的なレジリエンスと信頼性と、弊社のbuildingSMART Internationalの国際標準規格開発メンバーに、日本企業として唯一参画する弊社の強みを活かし、建設業界の高度な国際標準技術を民主化します。 AWSとのパートナーシップが、この挑戦を成功に導く重要な鍵となることを確信しています。 ー ONESTRUCTION株式会社 事業開発ユニット AI Lead 日高 洸陽 Nishikaでは、AWS様のEC2 P5インスタンスを活用し、要約タスク等を目標に出力形式への追従能力を高めたSLMを開発してまいります。今後、オンプレミス環境におけるより幅広いユースケースをターゲットとしたSLMを開発していく予定で、継続的に協働させていただければと思います。 — Nishika株式会社 代表取締役CTO 松田裕之 AWS様には生成AI実用化推進プログラムの支援で大変お世話になりました。 GENIACサイクル3では Amazon EC2 P5en インスタンスを活用し、業界・タスク特化型LLM構築を中規模モデルに拡張して取り組んでまいります。 — 株式会社野村総合研究所 AIソリューション推進部 チーフエキスパート 岡田 智靖 氏 前回に引き続きの採択となりましたが、さらに複雑な図表へ対応と高度な推論能力を持つマルチモーダルLLMの開発を通じて、企業に蓄積されたドキュメントの有効活用を実現して企業競争力のアップに貢献したいと考えております。開発を進める中では計画変更が避けられませんが、LLM開発においては大きな計算機資源の機動的な確保が必要になります。その対応力とサポートに優れたAWS様に今回もお世話になります。 — 株式会社リコー RICOH Digital Services BU AIサービス事業本部 デジタル技術開発センター LMM開発室 室長 長谷川 史裕 AWS では日本のお客様に対し、2023年の AWS LLM 開発支援プログラム にはじまり、 グローバルの Generative AI Accelerator や AWS ジャパン生成 AI 実用化推進プログラム といった取り組みを通して生成 AI ワークロードを支援しています。そこで得られた知見をもとに、GENIAC における日本の生成 AI 開発力向上に貢献できれば幸いです。

本記事は「 AI-Driven Development Life Cycle: Reimagining Software Engineering 」を翻訳したものです。 ビジネスとテクノロジーのリーダーは、生産性の向上、開発速度の向上、実験の促進、市場投入時間（ TTM ）の短縮、開発者体験の向上を常に目指しています。これらの長期的な目標が、ソフトウェア開発のプラクティスのイノベーションを推進しています。このイノベーションは、人工知能によってますます加速しています。特に、 Amazon Q Developer や Kiro などの生成 AI を活用したツールは、すでにソフトウェアの作成方法に革命をもたらし始めています。現状、多くの組織は主に 2 つのアプローチでソフトウェア開発に AI を活用しています：1 つは AI 支援型開発で、ドキュメント作成、コード補完、テストなどの特定のタスクを AI が強化するアプローチです。もう 1 つは AI 自律型開発で、ユーザーの要件に基づいて人間の介入なしに AI がアプリケーション全体を生成することを期待するアプローチです。これらのアプローチはいずれも、開発速度とソフトウェア品質の面で最適とは言えない結果を生み出しており、AI-DLC はこれらの課題に対処することを目的としています。 ソフトウェアにおける AI の革新的アプローチの必要性 既存のソフトウェア開発手法は、人間主導の長期的なプロセスとして設計されており、プロダクトオーナー、開発者、アーキテクトは皆、計画、会議、その他のソフトウェア開発ライフサイクル（ SDLC ）の儀式などの本質的ではない活動に時間の大部分を費やしています。AI をアシスタントとして単純に後付けすることは、その能力を制約するだけでなく、時代遅れの非効率性を助長することにもなります。AI の力を真に活用し、生産性向上の長期的な目標を達成するには、ソフトウェア開発ライフサイクルへのアプローチ全体を再構築する必要があります。 革新的な結果を達成するには、AI を開発プロセスの中心的な協力者およびチームメイトとして位置づけ、ソフトウェア開発ライフサイクル全体を通じてその能力を活用する必要があります。これが、AI の能力をソフトウェア開発の構造そのものに完全に組み込むよう設計された新しい方法論である AI 駆動開発ライフサイクル（AI-DLC） &nbsp;を導入する理由です。 AI 駆動開発ライフサイクル（AI-DLC）とは？ AI-DLC は、ソフトウェア開発に対する AI 中心の革新的なアプローチで、2 つの重要な要素を重視しています。： AI が実行し人間が監視する ：AI は体系的に詳細な作業計画を作成し、積極的に意図のすり合わせとガイダンスを求め、重要な決定は人間に委ねます。これが重要なのは人間だけが情報に基づいた選択を行うために必要なビジネス要件の文脈的理解と知識を持つからです。 ダイナミックなチームコラボレーション ：AI がルーティンタスクを処理する一方で、チームはリアルタイムでの問題解決、創造的思考、迅速な意思決定のために、コラボレーションしやすい環境で協力します。この孤立した作業から活気のあるチーム作業への転換は、イノベーションと成果物の提供を加速します。 これら 2 つの要素により、品質を犠牲にすることなく、より迅速にソフトウェアを提供できるようになります。 AI-DLC の仕組み AI-DLC の本質は、新しいメンタルモデルを通じて AI にワークフローを開始させ、指示することです： このパターンでは、AI が計画を作成し、文脈を理解するためにすり合わせのための質問をし、人間の検証を受けた後にのみソリューションを実装します。このパターンは、すべての SDLC 活動に対して迅速に繰り返され、すべての開発パスに統一されたビジョンとアプローチを提供します。 このメンタルモデルを核として、AI-DLC でのソフトウェア開発は 3 つシンプルなフェーズで行われます： 開始( Inception )フェーズ では、AI がビジネス意図を詳細な要件、ストーリー、ユニットに変換します。これは「モブエラボレーション( Mob Elaboration (※) )」を通じて行われ、チーム全体が AI の質問や提案を積極的に検証します。( ※訳註: elaboration は”推敲”や”入念な準備”と言う意味を持つ英単語です) 構築( Construction )フェーズ では、開始フェーズで検証されたコンテキストを使用して、AI が論理アーキテクチャ、ドメインモデル、コードによる実装、テストを「モブコンストラクション ( Mob Construction )」を通じて提案します。そこでは、チームが技術的決定とアーキテクチャの選択についてリアルタイムで明確化していきます。 運用( Operation )フェーズ では、AI が前のフェーズから蓄積されたコンテキストを適用して、チームの監督のもとで Infrastructure as Code とデプロイメントを管理します。 各フェーズは次のフェーズにより豊富なコンテキストを提供し、AI がより的確な提案を提供できるようにします。 AI は、プロジェクトリポジトリに計画、要件、設計成果物を保存し、すべてのフェーズにわたって永続的なコンテキストを保存・維持し、複数のセッションにわたって作業をシームレスに継続できるようにします。 AI 駆動の高度に協調的なアプローチを反映して AI-DLC は新しい用語と習慣を導入 します。従来の「スプリント」は「ボルト ( bolts )」に置き換えられます。これは、週単位ではなく時間や日単位で測定される、より短く集中的な作業サイクルです。エピックは作業単位 ( Units of Work) に置き換えられます。この用語の変更は、この手法がスピードと継続的デリバリーを重視していることを強調しています。同様に、他の一般的なアジャイルの用語も AI 中心のワークフローに合わせて再定義され、この手法のソフトウェア開発における革新的なアプローチをより適切に表現する用語体系が作られています。 この手法のメリット 開発速度 ：AI-DLC が提供する最大の利点は、開発速度の向上です。AI が要件、ストーリー、設計、コード、テストなどの成果物を迅速に生成・改良することで、プロダクトオーナー、アーキテクト、開発者が以前は数週間かかっていたタスクを数時間または数日で完了できるようになります。 イノベーション ：その結果、開発速度の向上と AI による重労働の肩代わりにより、イノベーションのための時間が大きく確保され、ビルダーは創造的なソリューションを探求し、可能性の限界に挑戦することができます。 品質 ：継続的な意図のすり合わせにより、チームは AI による抽象的/曖昧な意図の解釈ではなく、頭に描いているものを正確に構築できます。これにより、ビジネス目標により適合した製品が実現します。AI は、組織固有の標準（コーディング規約、設計パターン、セキュリティ要件）を一貫して適用しながら、包括的なテストスイートを生成することで品質を向上させます。このエンドツーエンドの AI 統合により、要件からデプロイメントまでの一貫性とトレーサビリティが向上します。 市場対応力 ：AI-DLC の迅速な開発サイクルにより、市場の需要とユーザーフィードバックに迅速に対応でき、結果として要件への迅速な適応が可能になります。 開発者体験 ：AI-DLC は、日常的なコーディングタスクから重要な問題解決にフォーカスを移すことで、開発者体験を変革します。AI が反復的なタスクを処理することで認知負荷を軽減し、開発者がビジネスコンテキストをより深く理解し、自分の作業がビジネス価値に直接影響を与えることを実感できるため、満足度が向上します。 開始方法 AI-DLC の導入には、3 つの明確なパスがあります：包括的な AI-DLC ホワイトペーパー を読む、 Amazon Q Developer ルール と Kiro カスタムワークフロー を活用して組織全体で一貫した AI-DLC の実装方法を探る、または AWS アカウントチームと連絡を取り、AI-DLC を組織の特定のニーズに合わせてカスタマイズする方法について相談する、のいずれかから始めることができます。 ソフトウェア開発の未来が到来しました。私たちは、AI を活用してシステム開発をより速く行うだけでなく、人間による重要な監督とコラボレーションを通じて正確性と品質を維持することをお手伝いできることを嬉しく思います。今すぐ AI-DLC の旅を始めて、AI 駆動型のイノベーションを通じて開発プラクティスを変革している組織のコミュニティに参加しましょう。 翻訳は、ソリューションアーキテクトの金森が担当しました。原文は こちら です。 Raja SP Raja は AWS のプリンシパルソリューションアーキテクトで、Developer Transformation プログラムを率いています。彼は 100 を超える大企業と協働し、モダンなアーキテクチャ、プラットフォームエンジニアリングプラクティス、Amazon にインスパイアされた運用モデルに基づいて構築されたミッションクリティカルなシステムの設計と提供を支援してきました。生成 AI がソフトウェア開発の状況を再構築する中、Raja と彼のチームは AI 駆動開発ライフサイクル（AI DLC）を作成しました。これは、AI 時代に大規模チームが協働してプロダクショングレードのソフトウェアを構築する方法を再構築する、エンドツーエンドの AI ネイティブ方法論です。