2025 年 8 月 4 日、Gartner Magic Quadrant for Strategic Cloud Platform Services (SCPS) を発表しました。Gartner が 15 年連続でリーダーとして選出している Amazon Web Services (AWS) は、最も長期にわたる Magic Quadrant のリーダーの地位を確立しています。 Gartner はこのレポートで、AWS を「実行能力」軸で再び最高位に位置付けました。当社はこれを、イノベーションを加速するための極めて幅広く奥深い機能セットと、お客様が最も重要なアプリケーションのために信頼できる比類のないセキュリティ、信頼性、パフォーマンスをお客様に提供するという、当社の継続的な取り組みが評価されたものであると考えています。 2025 Magic Quadrant for Strategic Cloud Platform Services をグラフ化した図を以下に示します。 Gartner は、AWS の強みを次のように認識しています: 最大のクラウドコミュニティ – AWS は、クラウドプロフェッショナルの強力なグローバルコミュニティを構築し、学習とエンゲージメントのための重要な機会を提供しています。 クラウドにインスピレーションを得たシリコン – AWS は、クラウドコンピューティング分野での経験を活かし、 AWS Graviton 、 AWS Inferentia 、 AWS Trainium などのカスタムシリコン設計を開発しました。これにより、ハードウェアとソフトウェアのより緊密な統合、電力効率の向上、サプライチェーンに対するより強力なコントロールが可能になります。 グローバルな規模と運用上の実行 – AWS はグローバルなクラウド市場の収益において大きなシェアを占めており、これにより、この分析に含まれる他のいくつかのプロバイダーよりも大規模かつ堅牢な統合パートナーネットワークを構築できています。これは、組織が成功裏にクラウドを導入するのに役立っています。 お客様から最も多く寄せられるフィードバックは、AWS には最大規模かつ極めてダイナミックなクラウドコミュニティがあり、世界中の何百万ものアクティブなお客様や何万ものパートナーに質問したり、学んだりすることが容易であるというものです。当社は最近、 AWS ヒーロー や AWS コミュニティビルダー と直接つながることができるコミュニティハブである AWS Builder Center を立ち上げました。また、お近くの都市で開催される AWS ユーザーグループ や AWS クラウドクラブ を詳しく確認して、参加することもできます。 さらに、 AWS Migration Acceleration Program など、さまざまな エンタープライズプログラム を通じて、エンタープライズのお客様のデジタルトランスフォーメーションの促進にも注力しています。移行とモダナイゼーションに 生成 AI を活用し、.NET、メインフレーム、VMware などのミッションクリティカルなビジネスワークロードのエンタープライズモダナイゼーションを加速するために開発された初のエージェンティック AI サービスである AWS Transform を導入しました。 詳細については、 Gartner レポート全文 をご覧ください。これには、レポートに含まれる各クラウドサービスプロバイダーの評価に使用された方法論と評価基準の概要が記載されています。このレポートは、顧客に代わってイノベーションを支援するクラウドプロバイダーを選ぶ際の指針となります。 – Channy Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価または他の認定を受けたベンダーのみを選定するようテクノロジーユーザーに助言するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、本調査に関して、明示または黙示を問わず、商品性または特定目的適合性に関する保証を含め、一切の保証を放棄します。 GARTNER は Gartner の登録商標およびサービスマークであり、Magic Quadrant は Gartner, Inc. および/またはその米国および他国の関連会社の登録商標であり、許可を得て使用されています。All rights reserved. 原文は こちら です。

10 年前、 弊社は Amazon Aurora の一般提供の開始を発表しました 。Amazon Aurora は、高性能な商用データベースのスピードと可用性、そして、オープンソースデータベースのシンプルさとコスト効率を兼ね備えたデータベースです。 Jeff が リリース時のブログ記事 で述べているように、「3 つのアベイラビリティーゾーン内で、およびこれらのアベイラビリティーゾーン全体でストレージがレプリケートされ、クォーラム書き込みによる更新モデルを備えた Amazon Aurora は、最大 64 TiB のストレージまで簡単かつ効率的にスケールしながら、高いパフォーマンスと 99.99% の可用性を実現するように設計されています」。 弊社は、10 年以上前に Aurora の開発を開始したとき、アーキテクチャに関して、データベースのあり方を永遠に変える根本的な意思決定を下しました。ストレージとコンピューティングを疎結合したのです。この斬新なアプローチにより、Aurora は、商用データベースと同等のパフォーマンスと可用性を 10 分の 1 のコストで実現できました。 これが、数十万の AWS のお客様がリレーショナルデータベースとして Aurora を選択する理由の 1 つです。 8 月 15 日は、 2025 年 8 月 21 日に開催される、Aurora データベースのイノベーション 10 周年を記念するライブストリームイベント に皆様をご招待します。 これまでの歩みを簡単に振り返る Aurora の進化を通じて、当社は 4 つのコアイノベーションテーマに注力してきました。すなわち、最優先事項としてのセキュリティ、増大するワークロードに対応するスケーラビリティ、コスト管理を改善する予測可能な料金、グローバルアプリケーションのためのマルチ リージョン 機能です。Aurora の歩みにおける重要なマイルストーンをいくつかご紹介します。 弊社は re:Invent 2014 で Aurora をプレビュー し、 2015 年 7 月に一般提供を開始 しました。リリース時には、Aurora を「コスト効率の高い新しい MySQL 互換データベースエンジン」として紹介しました。 2016 年 6 月には、 リーダーエンドポイント と クロスリージョンリードレプリカ を導入し、続いて 10 月には AWS Lambda との統合と Amazon S3 からテーブルを直接ロードする機能 を追加しました。2017 年 6 月には、データベースのクローン作成と Amazon S3 へのエクスポート機能を追加し、同年 10 月には PostgreSQL との完全な 互換性 を実現しました。 このジャーニーは、2017 年 11 月の サーバーレス プレビューにつながり、2018 年 8 月には一般提供が開始されました。2018 年 11 月には、クロスリージョンディザスタリカバリのための グローバルデータベース がリリースされました。データベース更新を簡素化する ブルー/グリーンデプロイ と、クエリパフォーマンスを改善する 最適化された読み取りインスタンス を導入しました。 2023 年には、Aurora PostgreSQL 向けに 類似性検索用の pgvector を使用したベクトル機能 と Aurora I/O-Optimized を追加し、大量の I/O が発生するアプリケーションのために、最大 40% のコスト削減と予測可能な料金を実現しました。 Amazon Redshift との Aurora ゼロ ETL 統合の提供もしました。これにより、抽出、変換、ロード (ETL) オペレーションを実行する複雑なデータパイプラインの構築と維持が不要になり、Aurora からのペタバイト規模のトランザクションデータに対して Amazon Redshift を使用してほぼリアルタイムの分析と ML を実行できるようになります。今年は、 Amazon Sagemaker との Aurora MySQL ゼロ ETL 統合も追加しました。これにより、SageMaker のレイクハウスアーキテクチャでデータにほぼリアルタイムでアクセスし、幅広い分析を実行できるようになります。 2024 年には、 Aurora PostgreSQL を Amazon Bedrock ナレッジベースのベクトルストアとして ワンクリックで簡単に選択できるようにし、サーバーレスの水平スケーリング (シャーディング) 機能である Aurora PostgreSQL Limitless Database をリリースしました。 また、お客様のためにスケーリングを簡素化するため、2020 年 9 月には、最大ストレージ容量を 128 TiB に増加し、多くのアプリケーションを単一のインスタンス内で運用できるようにしました。先月には、 最大ストレージ容量を 256 TiB に倍増 することで、スケーリングをさらに簡素化しました。事前のプロビジョニングは不要で、実際のストレージ使用量に基づく従量制料金でご利用いただけます。これにより、より多くのお客様が、複数のインスタンスを管理する複雑さなしに、高いコスト効率を維持しながら、増大するワークロードを実行できるようになります。 最近では、re:Invent 2024 において、 Amazon Aurora DSQL を発表しました。これは 2025 年 5 月に一般提供が開始されました。Aurora DSQL は、分散 SQL データベースにおける当社の最新のイノベーションを体現しており、アクティブ/アクティブの高可用性とマルチリージョンの強力な一貫性を提供します。これは、常時利用可能なアプリケーションに最適な、極めて高速のサーバーレス分散 SQL データベースであり、インフラストラクチャ管理を一切必要とせず、あらゆるワークロードの需要に合わせて容易にスケールできます。 Aurora DSQL は、ストレージとコンピューティングの分離という当社の独自のアーキテクチャ原則に基づいて構築されており、読み取り、書き込み、コンピューティング、ストレージの独立したスケーリングによってさらに強化されています。単一リージョンで 99.99%、マルチリージョンで 99.999% の可用性を提供し、すべてのリージョンレベルのエンドポイントで強力な一貫性を実現します。 また、6 月には、AI エージェントをデータソースやサービスと統合できるように、 Aurora 向けモデルコンテキストプロトコル (MCP) サーバー をリリースしました。 10 年間のイノベーションをお祝いしましょう 8 月 21 日のライブストリームイベント では、 Swami Sivasubramanian 、 Ganapathy (G2) Krishnamoorthy 、 Yan Leshinsky 、 Grant McAlister 、 Raman Mittal など、Aurora の技術リーダーや立ち上げメンバーの話を聞くことができます。クラウドデータベースにおけるコンピューティングとストレージの分離を先駆的に推進したアーキテクトから直接学び、Aurora のアーキテクチャとスケーリング機能に関する技術的なインサイトを得ることができます。Aurora のエンジニアがビジョンを共有し、お客様のために解決に取り組んでいる複雑な課題について議論するため、データベーステクノロジーの未来を垣間見ることもできます。 イベントでは、主要な特徴量の実装方法を示す実践的なデモンストレーションも提供されます。 pgvector を使用した AI 利用のアプリケーション の構築方法、新しい Aurora DSQL 料金モデルによるコスト最適化の理解、グローバルアプリケーションのためにマルチリージョンの強力な一貫性を実現する方法を学ぶことができます。 インタラクティブな形式で、Aurora のエキスパートとの質疑応答の機会も用意されているため、具体的かつ技術的な質問への回答を得ることができます。また、Aurora の新機能をお試しいただくための AWS クレジットも受け取ることができます。 エージェンティック AI にご興味をお持ちの方は、 MCP サーバー 、 Strands Agents 、 Strands Agents と Aurora DSQL の統合方法 に関するセッションが特に役立つでしょう。これらのセッションでは、データベースアクセスに対するコントロールを維持しながら、AI 機能を Aurora データベースに安全に統合する方法をご紹介します。 ミッションクリティカルなワークロードを実行している場合でも、新しいアプリケーションを構築している場合でも、これらのセッションは、最新の Aurora 特徴量の使用方法を理解するのに役立ちます。 今すぐ登録 して席を確保し、データベースイノベーションを祝うこのイベントにぜひご参加ください。 Aurora イノベーションの次の 10 年へ! – seb 原文は こちら です。

並外れた貢献と技術面でのリーダーシップが認められて AWS ヒーローに新しく加わった仲間たちを皆さんにご紹介したいと思います。さまざまな地域と専門技術を代表するこれらの情熱的な仲間たちは、優れた専門知識と AWS コミュニティ内での知識共有への献身を実証しています。AI と機械学習からサーバーレスアーキテクチャとセキュリティまで、私たちの新たなヒーローたちは、インクルーシブで魅力的なテクニカルコミュニティを育成すると同時に、幅広いクラウドイノベーションを体現しています。クラウドコンピューティングの未来の形成を支援し、次世代 AWS ビルダーのインスピレーションとなっているコミュニティリーダーを私たちと一緒に歓迎しましょう。 Kristine Armiyants 氏 – アルメニア、マシス コミュニティヒーローである Kristine Armiyants 氏は、ソフトウェアエンジニアとクラウドサポートエンジニアの両方を務めています。経営学修士を取得してから独学でソフトウェア開発を学んだ Armiyants 氏は、金融関連の経歴をテクノロジーに移行させました。AWS User Group Armenia の創設者であり、2 年半以上にわたってリーダーを務めている Armiyants 氏は、アルメニア初の AWS Community Day を企画し、参加者数を 320 人から 440 人以上に増やして、アルメニアに国際的な規模のイベントを招致するチームを率いることで現地の技術的環境を変革してきました。Armiyants 氏は、新しいユーザーグループの主催者やキャリアの浅いエンジニアを指導しながら、アルメニア語の技術記事、実践的なワークショップ、ありのままを伝えるブログシリーズを通じて、クラウド知識をより簡単に取得できるようにしています。コミュニティ構築に対する Armiyants 氏の献身的な取り組みにより、アルメニアから 5 人の新しい AWS コミュニティビルダーが誕生しました。これは、AWS コミュニティで学び、成長するためのインクルーシブなスペースの創出に対する Armiyants 氏のコミットメントを実証しています。 Nadia Reyhani 氏 – オーストラリア、パース 機械学習ヒーローである Nadia Reyhani 氏は、機械学習システムに DevOps ベストプラクティスを統合する AI Product Engineer です。かつて AWS コミュニティビルダーであった Reyhani 氏は、AWS イベントで、Amazon SageMaker と Bedrock を使用したスケーラブルな AI ソリューションの構築に関するプレゼンテーションを定期的に行っています。Women in Digital Ambassador として技術的な専門知識とアドボカシーを組み合わせる Reyhani 氏は、クラウドや AI テクノロジーにおけるマイノリティグループのためのインクルーシブなスペースを創り出しています。 Raphael Manke 氏 – ドイツ、カールスルーエ DevTools ヒーローである Raphael Manke 氏は、Dash0 で Senior Product Engineer を務めていますが、AWS re:Invent でのスケジュール作成に使用される非公式 AWS re:Invent プランナーの作成者でもあります。10 年間の AWS 経験を持つ Manke 氏は、クラウド開発を合理化するサーバーレステクノロジーと DevTools を専門としています。AWS User Group in Karlsruhe の主催者であり、以前は AWS コミュニティビルダーでもあった Manke 氏は、講演や AWS サービスチームとの直接的なコラボレーションを通じて製品の機能強化に積極的に取り組んでいます。AWS コミュニティに対する Manke 氏のコミットメントは、現地ユーザーグループのリーダーシップからサービスチームへの貴重なフィードバックの提供まで多岐にわたります。 Rowan Udell 氏 – オーストラリア、ブリスベン セキュリティヒーローである Rowan Udell 氏は、AWS Identity and Access Management (IAM) を専門とする独立系 AWS セキュリティコンサルタントです。Udell 氏は、書籍、ブログ記事、ミートアップ、ワークショップ、カンファレンスでのプレゼンテーションを通じて、AWS セキュリティの専門知識を10 年以上にわたって共有してきました。Udell 氏は多数の AWS コミュニティプログラムに参加しており、AWS コミュニティビルダーを 4 年間務め、AWS Community Day Australia 企画委員会のメンバーでもあります。Sydney Summit やその他のコミュニティミートアップを含めた AWS イベントで頻繁に講演を行っている Udell 氏は、AWS 環境をセキュア化する企業のために、複雑なセキュリティ概念をシンプルかつ実用的で運用可能なソリューションに変換することで知られています。 Sangwoon (Chris) Park 氏 – 韓国、ソウル サーバーレスヒーローである Sangwoon (Chris) Park 氏は、AI 駆動の 3D コンテンツ生成を専門とする AI スタートアップ、RECON Labs で開発を先導しています。かつて AWS コミュニティビルダーを務めていた Park 氏は、「AWS Classroom」YouTube チャンネルの作成者でもあり、サーバーレスアーキテクチャに関する実用的な知識を AWS コミュニティと共有しています。Park 氏は、毎月行われる AWS Classroom Meetup と AWS KRUG Serverless Small Group を主催しており、コミュニティイベントや教育コンテンツを通じてサーバーレステクノロジーを積極的に推進しています。 Toshal Khawale 氏 – インド、プネ コミュニティヒーローである Toshal Khawale 氏は、22 年を超えるエンジニアリングと AWS クラウドテクノロジーの専門知識を備えた熟練のテクノロジーリーダーで、クラウド知識を実証する 12 の AWS 認定を取得しています。数多くの大規模な AWS 移行と生成 AI 実装を主導してきた Khawale 氏は、PwC の Managing Director として、クラウドトランスフォーメーション、デジタルイノベーション、アプリケーションモダナイズといったイニチアチブを通じて組織を導いています。AWS コミュニティビルダーを 6 年間務めた後も、AWS User Group Pune のリーダーとしての活動を続けており、コミュニティエンゲージメントと知識共有を積極的に推進しています。Khawale 氏は、メンター、常連講演者、アドボケイトとしての役割を通じて、組織がクラウドテクノロジートレンドの最先端に立ながら AWS への投資を最大限に活かせるように支援しています。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブページ にアクセスしてください。 – Taylor 原文は こちら です。

2025年1月28日に本稿の更新が行われました: 「ユースケース3: インターネットベースのアプリケーションから AWS にデプロイされたサービスへの接続」において、各アベイラビリティーゾーン内で DNS 解決を実行する必要性が明記されました。 2025年7月24日に本稿の更新が行われました: サービスネットワーク VPC エンドポイントの IP アドレスは変更される可能性があるため、インターネット向け Elastic Load Balancer (ELB) のターゲットとしてプロキシが必要であることが明確になりました。 本稿では、Amazon VPC Lattice を活用し、AWS で最新で安全かつ耐障害性の高い企業ネットワークを構築する方法を探ります。VPC Lattice のすべての AWS コンピューティングサービスとの統合、および幅広いアプリケーションとトランスポートプロトコルのサポートを使用して、ネットワーク接続をモダン化する方法についてより深く掘り下げます。また、オンプレミス環境への VPC Lattice 接続の拡張方法についても説明し、クロスリージョンおよびハイブリッドアクセスの要件を満たす方法も紹介します。 Amazon VPC Lattice は、フルマネージド型のアプリケーションネットワーキングサービスで、サービス間通信のニーズに対してネットワーク接続やセキュリティ、モニタリングを簡素化します。VPC Lattice は現在、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Lambda に加えて、 Amazon Elastic Container Service (Amazon ECS) と AWS Fargate の組み込みサポート を提供しています。また、 HTTP や HTTPS 、 gRPC 、 TLS 、TCP などの最も一般的なタイプのサービスとプロトコルを幅広くサポートしています。VPC リソースとサービスネットワーク VPC エンドポイントのサポートにより、VPC Lattice を使用して、AWS およびオンプレミスのサービスに対して一貫性のある安全なネットワーク接続を構成することができます。 VPC Lattice は、ネットワーク接続性に加えて、信頼性の高い認証とコンテキスト固有の認可により、セキュリティ体制の向上を促進します。 AWS Identity and Access Management (AWS IAM) と統合してサービス間の認証と認可を行い、現在 AWS サービスで使用している馴染みのある認証・認可機能を提供します。これにより、豊富なトラフィック制御とエンドツーエンドの可観測性を備えた、多層防御セキュリティ戦略を実装できます。VPC Lattice の認証ポリシーを活用してワークロード間のアクセスを細かく制御し、ゼロトラストセキュリティの実装を加速することができます。 前提条件 Amazon Virtual Private Cloud (Amazon VPC) や AWS Direct Connect 、 AWS Site-to-site VPN 、 Amazon Route 53 、 AWS PrivateLink 、 AWS Cloud WAN などの AWS のネットワーキング構成に精通していることを前提としています。これらのサービスの定義に焦点を当てるのではなく、それらの機能と、ハイライトされたネットワーク接続シナリオで VPC Lattice を補完するために使用する方法について概説します。また、Amazon VPC Lattice の概念にも精通していることを前提としています。Amazon VPC Lattice の追加の背景情報については、以前の記事「 Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice 」と、 Amazon VPC Lattice 入門ガイド のリソース集を参照することをお勧めします。 ネットワーク接続シナリオ エンタープライズ向けネットワークでは、複数のトラフィックパターンのための接続基盤を提供します。これには、同一 AWS アカウントやリージョン内の VPC 間接続や、複数の AWS アカウントやリージョン間のVPC 間接続、オンプレミス環境とのハイブリッド接続、そして Amazon Relational Database Service (RDS) などの AWS マネージドサービスへの接続が含まれます。 私たちは、 AWS Well-Architected フレームワーク に沿ったベストプラクティスのアプリケーションデプロイメントオプションとして、マルチアカウントおよびマルチ VPC のアーキテクチャパターンがあると考えています。そのため、アーキテクチャ図にはアカウントの境界を示さず、すべてのリソースが複数のアカウントにわたってデプロイされていると想定しています。次に続くセクションでは、以下のアプリケーション通信のユースケースを取り上げながら、Amazon VPC Lattice を使用して企業のネットワーク接続とセキュリティをモダン化および簡素化する方法について詳しく説明します。 ユースケース1 : 単一の AWS リージョン内のアプリケーション間の接続。 ユースケース2 : AWS とオンプレミスのハイブリッド環境に展開されたアプリケーション間の接続。このユースケースでは、2つの一般的なフローで区別しています。 AWS 上のクライアントがオンプレミスにデプロイされたアプリケーションにアクセスする必要がある場合。 オンプレミス上のクライアントが AWS 上のアプリケーションにアクセスする必要がある場合。 ユースケース3 : インターネット上のアプリケーションから、AWS にデプロイされたアプリケーションへの接続。アプリケーションへのユーザーアクセスには焦点を当てません。アプリケーションへのユーザーアクセスを保護する詳細については、 AWS Verified Access を確認することをお勧めします。 ユースケース4 : 複数 AWS リージョン間でのアプリケーション間の接続。この要件は、リージョン間接続に関する2つの一般的なユースケースに由来しています。 複数リージョンに跨るクライアントが、単一のリージョンにデプロイされたアプリケーションにアクセスする必要がある場合。 クライアントが、複数リージョンにデプロイされたアプリケーションにアクセスするために、リージョン間フェイルオーバー機能を必要とする場合。フェイルオーバーは、サービス所有者またはクライアントによって制御できます。 クライアントやサービス、リソースは、HTTP や HTTPS、gRPC、TLS、TCP などの様々なサポートされたプロトコルを使用し、多様な AWS コンピューティングオプション上にデプロイされたアプリケーションの組み合わせであると考えています。 VPC Lattice の機能と新しい能力 VPC Lattice は、AWS での接続性とネットワークセキュリティを簡素化する新機能を発表しました。VPC リソースを VPC Lattice サービスネットワークに関連付けることができるようになり、AWS またはオンプレミスにデプロイされた TCP サービスやリソースへのアクセスを提供できるようになりました。また、サービスネットワーク VPC エンドポイントを使用して、オンプレミスまたはクロスリージョンからサービスネットワークへのアクセスを設定することもできます。 各新機能の詳細については前述の投稿で確認できますが、以下のセクションで概説するシナリオのネットワーク接続を設計するために使用する構成の概要は次のとおりです。 VPC Lattice サービスネットワーク を使用して、共通の接続性とセキュリティ要件を持つアプリケーションをまとめます。サービスネットワークは、VPC やアカウント間の接続性を可能にし、アプリケーション通信パターンに共通のセキュリティポリシーを適用する方法を簡素化する論理的なグルーピングメカニズムです。アカウント内でサービスネットワークを作成し、 AWS Resource Access Manager (AWS RAM) を使用することで、 AWS Organization 内外の他アカウントと共有することができます。様々なユースケースや事業部門、環境 (例：本番や開発、ステージングなど) に対して複数のサービスネットワークを持つことができます。 クライアントは、サービスネットワーク VPC アソシエーションとサービスネットワーク VPC エンドポイントを使用して、サービスネットワーク内のサービスとリソースにアクセスできます。 サービスネットワーク VPC アソシエーション (SN-A) : VPC にデプロイされたクライアントがサービスネットワークにアクセスできるようにします。サービスネットワークアソシエーションでは、関連付けられた VPC の外部からアクセスすることはできません。VPC は 1 つのサービスネットワークアソシエーションのみを持つことができます。 サービスネットワーク VPC エンドポイント (SN-E) : VPC にデプロイされたクライアントがサービスネットワークにアクセスできるようにします。また、VPC への接続性がある場合、VPC 外のクライアントも対応するサービスネットワークエンドポイントにアクセスできます。例えば、クライアントは AWS Cloud WAN や AWS Transit Gateway を通じてピア接続された VPC、あるいは AWS Direct Connect や Site-to-Site VPN を通じてオンプレミスからサービスネットワーク VPC エンドポイントにアクセスできます。サービスネットワーク VPC エンドポイントは VPC の CIDR ブロックから IP アドレスを使用します。各サービスネットワークに対して SN-E を作成することで、VPC 内で複数のサービスネットワークへの接続を設定できます。サービスネットワークエンドポイントの詳細については、 ドキュメント を確認することをお勧めします。 サービスネットワークでは、VPC Lattice サービスと VPC リソースを関連付けることができます。 VPC Lattice サービス : VPC Lattice サービス は、リスナー (プロトコルとポート番号)や、アプリケーションフローを制御するルーティングルール (例：パス、メソッド、ヘッダーベース、重み付けルーティング)、 アプリケーションインフラストラクチャを定義する 1 つ以上のターゲットグループで構成されています。サービスは様々なクライアント機能に対応するために複数のリスナーを持つことができます。サポートされているプロトコルには、HTTP や HTTPS、gRPC、TLS が含まれます。VPC Lattice サービスを作成すると、AWS RAM を使用して AWS Organization 内外のアカウントと共有することができます。複数のサービスをサービスネットワークに関連付けることができ、1 つのサービスを複数のサービスネットワークに関連付けることも可能です。 VPC リソース : リソースは IP アドレス、ドメイン名 (DNS) ターゲット、または Amazon RDS などの Amazon マネージドリソースです。リソースを他の VPC やアカウントで利用可能にするには、 リソースゲートウェイ と リソースコンフィグレーション を定義します。 リソースゲートウェイは、共有リソースにアクセスするために、リソース所有者の VPC へのイングレストラフィックポイントを提供する新しい VPC の構成概念です。VPC 内に 1 つ以上のリソースゲートウェイを持つことができます。 リソースコンフィグレーションは、共有したいリソースまたはリソースのグループを表します。VPC 内の単一のリソースゲートウェイに複数のリソースコンフィグレーションを関連付けることができます。リソースコンフィグレーションを作成したら、それをサービスネットワークに関連付けることができます。また、AWS RAM を使用して、AWS Organization 内外のアカウントとリソースコンフィグレーションを共有することもできます。 VPC Lattice を使用すると、クライアントやサービス、リソースが重複する IP アドレスを持つことができ、また異なる IP バージョン (IPv4とIPv6) をサポートすることができます。これにより、プライベート IPv4 アドレスが重複している、または不足している環境での接続が容易になり、IPv6 の導入を加速させることができます。 ユースケース1: AWS リージョン内のアプリケーション間の接続 最初に取り上げるユースケースは、VPC Lattice を使用して、AWS リージョン内の複数の VPC やアカウントにわたってデプロイされたアプリケーション間で安全な接続を提供する方法です。アプリケーションは、Amazon EC2 インスタンスや AWS Lambda 関数、Amazon ECS、Amazon EKS、AWS Fargate クラスターなど、さまざまなコンピューティングプラットフォームにわたってデプロイでき、幅広い通信プロトコルをサポートできます。図1は、AWS リージョン内のアプリケーションネットワーキングに関する高レベルアーキテクチャ図を示しています。 図1. AWS リージョン内のアプリケーションネットワーキングの高レベルアーキテクチャ AWS リージョン内でエンタープライズ向けのネットワーク接続アーキテクチャを簡素化およびモダン化するには、次の手順を実行できます。 セグメンテーションモデルに応じて、1 つ以上の VPC Lattice サービスネットワークを作成します。 アプリケーション要件に基づき、VPC Lattice サービスと VPC リソースを作成します。 VPC、サービス、リソースをそれぞれのサービスネットワークに関連付けます オプションとして、サービスネットワークとサービスに認証および認可ポリシーを設定し、アプリケーション間の通信を細かく制御します。 クライアント固有のサービスネットワークやサービス固有のサービスネットワークを作成できます。例えば、事業部門 (BU) ごとにクライアントをグループ化し、BU ごとにサービスネットワークを構成することができます。あるいは、共有サービスなどの機能別にサービスをグループ化し、専用のサービスネットワークに関連付けることもできます。アプリケーションチームは VPC Lattice サービスとリソースを作成し、サービスネットワークを所有するアカウントと共有することができます。特定のアクセス要件を満たすために、サービスとリソースを複数のサービスネットワークに関連付けることができます。セグメンテーションや運用モデルに関わらず、タグを使用して VPCやサービス、リソースをサービスネットワークに自動的に関連付けることができます。自動化のベストプラクティスの詳細については、「 Automating large scale deployments with tags for Amazon VPC Lattice 」を参照することをお勧めします。 サービスディスカバリを容易にするため、VPC Lattice はサービスとリソースのカスタムドメイン名をサポートし、定義した各 VPC Lattice サービスとリソースに対して完全修飾ドメイン名 (FQDN) を維持します。これらの FQDN を Route 53 のプライベートホストゾーン設定で活用し、クライアントがサービスとリソースを発見してアクセスできるようにすることができます。「 複数の VPC と AWS アカウントで Amazon Route 53 プロファイルを使用して DNS 管理を統合する 」を確認することをお勧めします。 図2は一般的なエンタープライズ向けアーキテクチャの例を示しています。本番環境、開発環境、共有サービス環境に特化した3つのサービスネットワークを作成し、それぞれ Prod、Dev、Shared services と名付けています。以下のように関連付けを行いました。 本番環境の VPC やサービス、リソースを Prod サービスネットワークに接続します。 開発環境の VPC やサービス、VPC リソースを Dev サービスネットワークに接続します。 共有サービスと共有 VPC リソース、およびそれらの VPC を Shared Services サービスネットワークに接続します。 共有サービスと共有 VPC リソースを Prod と Dev の両方のサービスネットワークに接続します。これは、本番アプリケーションと開発アプリケーションの両方からアクセスする必要があるためです。 図2. AWS リージョンにおける本番環境、開発環境、共有サービスのアプリケーションネットワークを含む一般的なエンタープライズ向けアーキテクチャ ユースケース2: AWS とオンプレミスにデプロイされたハイブリッド環境で展開されたサービス間の接続 ハイブリッド接続のユースケースでは、クライアントとアプリケーションを AWS とオンプレミスの両方にデプロイできます。以下の2つの一般的なアクセスパターンに対応します。 AWS にデプロイされたクライアントがオンプレミスにデプロイされたアプリケーションにアクセスする必要がある場合 オンプレミスにデプロイされたクライアントが AWS にデプロイされたアプリケーションにアクセスする必要がある場合 両方のユースケースの要件を満たすために、VPC Lattice サービスネットワーク VPC エンドポイント (AWS PrivateLink によって提供) と VPC リソースをどのように活用できるか見ていきましょう。 1. オンプレミスから AWS にデプロイされたアプリケーションへのアクセス : オンプレミス (または AWS 外) にデプロイされたクライアントの場合、AWS Direct Connect または Site-to-Site VPN を使用してオンプレミスからアクセス可能なエントリーポイント用 VPC を作成できます。この VPC 内で、サービスネットワーク VPC エンドポイントを作成し、オンプレミスのクライアントが関連する VPC Lattice サービスとリソースにアクセスできるようにすることができます。また、サービスネットワークエンドポイントのセキュリティグループを使用して、オンプレミスからのトラフィックをフィルタリングすることもできます。ハイブリッド接続には、AWS Direct Connect または AWS Site-to-Site VPN を使用できます。図 3 は、Amazon VPC Lattice サービスネットワーク VPC エンドポイントの高レベルアーキテクチャ図を示しています。 図3. オンプレミスから Amazon VPC Lattice サービスネットワーク VPC エンドポイントへのアクセス 図 4 は一般的なエンタープライズ向けアーキテクチャの例を示しています。リージョン内のすべてのサービスネットワークへのオンプレミスからのアクセスを可能にするために、「Hybrid ingress VPC」を使用しています。各サービスネットワーク (Prod や Dev、Shared Services) に対してサービスネットワークエンドポイントを構成しています。Hybrid ingress VPC へのオンプレミス接続には AWS Direct Connect を使用しました。 図4. オンプレミスから Prod や Dev、Shared Services サービスネットワークへのアクセスのためのサービスネットワークエンドポイントを持つ Hybrid ingress VPC 2. AWS からオンプレミスにデプロイされたアプリケーションへのアクセス : オンプレミス (または AWS 外) にデプロイされたアプリケーションの場合、AWS Direct Connect または Site-to-Site VPN によりオンプレミスへの接続性を持つ出口ポイント用 VPC を作成できます。この VPC でリソースゲートウェイを作成し、オンプレミスアプリケーション用のリソースコンフィグレーションを定義できます。DNS または IP アドレスでリソースを識別し、リソースコンフィグレーションをサービスネットワークに関連付けることができます。 ロードバランシングを必要とするオンプレミスアプリケーションの場合、AWS 上の egress VPC で Network Load Balancer (NLB) を使用できます。サービスネットワークからオンプレミスサービスを表す NLB へのアクセスを設定するために、各 NLB の DNS FQDN を含むリソースコンフィグレーションを定義できます。各リソースコンフィグレーションを 1 つ以上のサービスネットワークに関連付け、オンプレミスのロードバランスされたサービスへのアクセスを提供できます。図 5 は、オンプレミスアプリケーションのリソースコンフィグレーションに関する高レベルアーキテクチャ図を示しています。 図5. オンプレミスから Prod や Dev、Shared Services のサービスネットワークへのアクセスのためのサービスネットワークエンドポイントを持つ Hybrid ingress VPC 図 6 は一般的なエンタープライズ向けアーキテクチャの例を示しています。AWS Direct Connect を通じてオンプレミスのサービスとリソースにアクセスできる「Hybrid egress VPC」を使用しています。リソースゲートウェイを構成し、ロードバランシングを必要としないオンプレミスリソースを表す IP または DNS ベースのリソースコンフィグレーションを定義しました。ロードバランシングを必要とするオンプレミスアプリケーションは、Network Load Balancers (NLBs)を構成し、各 FQDN をリソースコンフィグレーションに追加しました。すべてのリソースコンフィグレーションを 3 つのサービスネットワーク (Prod や Dev、Shared Services) すべてに関連付けることを選択しました。一方で、リソースコンフィグレーションをサービスネットワークのサブセットに関連付けたり、オンプレミスにデプロイされたアプリケーション専用のサービスネットワークを作成したりすることもできます。 図6. オンプレミスアプリケーション用のリソースゲートウェイおよびリソースコンフィグレーションを備えた Hybrid egress VPC ユースケース3: インターネットベースのアプリケーションから AWS にデプロイされたサービスへの接続 インターネットからの通信ニーズに対応するため、インターネット上のアプリケーションが AWS にデプロイされたアプリケーションにアクセスする必要があります。この使用例は一般的に、AWS にデプロイされたアプリケーションのフロントエンドとして、パブリック向けロードバランサーを構成することで対処されます。このシナリオでは、VPC Lattice にて、パブリック向けロードバランサーからバックエンドターゲットへの安全な接続を提供する方法を探ります。実現するために、パブリック向けロードバランサーをデプロイするイングレスポイント用 VPC を作成し、サービスネットワーク VPC エンドポイントをロードバランサーのターゲットとして使用できます。Application Load Balancer を使用する場合、ターゲットは HTTP である必要があります。図7は、インターネットから VPC Lattice へのイングレスに関する高レベルアーキテクチャ図を示しています。 図7. VPC Lattice を介したインターネットイングレスアクセス サービスネットワーク VPC エンドポイントの IP アドレスは変更される可能性があるため、インターネット向けロードバランサーのバックエンドターゲットとしてプロキシを使用することをお勧めします。DNS ルックアップを行うプロキシは、常に最新のサービスネットワーク VPC エンドポイント の IP アドレスを取得することを保証します。VPC Lattice のインターネットイングレスのユースケースでプロキシを使用する方法の詳細については、 こちらのガイダンス をご覧ください。 図 8 は一般的なエンタープライズ向けのアーキテクチャ例を示しています。インターネットイングレス用 VPCと、インターネットクライアントからのアクセスを必要とする VPC Lattice サービスとリソース向けの VPC Lattice サービスネットワークを構成しました。Application Load Balancer と Network Load Balancers の両方を使用し、サービスネットワークの IP アドレスをターゲットとしています。また、セキュリティと運用モデルに基づき、サービスネットワークに直接インターネット接続を提供することも選択できます。サービスネットワーク内のサービスに関連付けられた IP アドレスを取得するには、各アベイラビリティゾーンでサービスネットワークエンドポイントに対してDNS 解決を実行する必要があります。これらの IP アドレスは変更される可能性があるため、定期的に DNS チェックを行うことをお勧めします。 図8. インターネット向けアプリケーションが、VPC Lattice を介し、Application Load Balancer または Network Load Balancer とサービスネットワークエンドポイントを利用し、Prod や Dev、Shared Services サービスアプリケーションにアクセス ユースケース4: 複数 AWS リージョンにわたるアプリケーション間の接続 マルチリージョンでアプリケーションを実行する用途に関わらず、クライアントがサービスやリソースに安全にアクセスでき、かつ回復力と可用性に影響を与えないことを確保することが基本的な要件です。ここでは、アプリケーションへの 2 つの一般的なリージョン間アクセスパターンについて説明します。 複数のリージョンにまたがるクライアントが、特定のリージョンにデプロイされたサービスにアクセスする必要がある場合 クライアントが、複数の AWS リージョンにデプロイされた重要なサービスにアクセスし、リージョン間のフェイルオーバー機能を必要としている場合 両方のアクセスパターンの要件を満たすために、VPC Lattice をどのように使用できるか復習しましょう。 1. 複数のリージョンにまたがるクライアントが、特定のリージョンにデプロイされたサービスにアクセスする必要がある場合 : このユースケースでは、サービスネットワーク VPC エンドポイントと、VPC ピアリングまたは AWS Cloud WAN を使用したクロスリージョン IP の接続性を活用できます。あるいは、VPC Lattice とクロスリージョン接続を可能にするインターフェイス VPC エンドポイント (AWS PrivateLink によって提供) を併用して、クライアントからサービスの場所や IP アドレッシング、フェイルオーバーの決定を抽象化することもできます。ここでは、2 番目のオプションに焦点を当てます。これを実現するには以下の手順を行います。 クロスリージョンのクライアントアクセスが必要なサービスに対して、クロスリージョンの PrivateLink インターフェース VPC エンドポイントを作成します。これにより、リージョン間通信の依存関係をより適切に追跡および管理し、それらが回復力と可用性に影響を与えないようにすることができます。 クロスリージョンの PrivateLink インターフェース VPC エンドポイントを VPC リソースとして VPC Lattice サービスネットワークに組み込みます。各クロスリージョンエンドポイントはサービスを表します。PrivateLink が管理する FQDN を使用して各エンドポイントの VPC リソースを定義し、Route 53 プライベートホストゾーンとプロファイルを使用してカスタム DNS を管理できます。 図 9 は高レベルのアーキテクチャ例を示しています。 図9. VPC Lattice サービスネットワーク VPC エンドポイントと AWS PrivateLink を使用したクロスリージョンサービスアクセス リモートリージョンのサービスネットワークにアクセスするために、サービスネットワーク VPC エンドポイントを設定し、Network Load Balancer をフロントエンドに配置します。その後、リモートリージョンに PrivateLink エンドポイントサービスと、PrivateLink エンドポイントを作成します。クロスリージョン VPC エンドポイントをサービスネットワークに取り込むには、リソースコンフィグレーションまたは VPC Lattice サービスを定義できます。AWS PrivateLink と Amazon VPC Lattice はどちらもクライアントとサービスの IP アドレスと IP バージョンを抽象化するため、すべての VPC で重複する IP スペースを使用できます。 2. 重要なサービスにアクセスし、クライアントがリージョン間のフェイルオーバー機能を必要とする場合 : 複数のリージョンにわたってデプロイされたサービスの場合の、リージョン間接続の一般的なユースケースは、フェイルオーバー状況下でリモートリージョンでクライアントトラフィックを受信できることです。VPC Lattice を使用することで、サービス所有者は以下のことが可能になります。 2つのターゲットグループを持つ VPC Lattice サービスを構成します。1つのターゲットグループはローカルリージョンのアプリケーションを表し、2つ目のターゲットグループには、リモートリージョンのサービスネットワークへのクロスリージョン接続のための AWS PrivateLink IP アドレスが含まれます。 サービスを別のリージョンにフェイルオーバーする必要がある場合、サービス所有者はターゲットグループの重みを変更できます。これにより、クライアントトラフィックをクライアントから VPC Lattice を通じて、クロスリージョンの PrivateLink エンドポイントに流すことが可能になります。 図 10 は高レベルのアーキテクチャ例を示しています。このシナリオでは、フェイルオーバーはサービス所有者によって制御されます。 図10. クロスリージョンのアクティブ-パッシブサービスアクセス構成 このオプションにより、複数リージョン間での直接的な IPv4 および IPv6 接続を設定する必要がなくなり、リージョン間の依存関係を細かく制御できるようになります。VPC Lattice は、サービスへのアクセスパターンの完全な可視性を提供し、モニタリングやサービス依存関係のマッピング作業、およびフェイルオーバー制御の簡素化を支援します。 まとめ 本稿では、Amazon VPC Lattice を活用して、モダンで安全かつ、回復力のあるエンタープライズネットワークを構築する方法を探りました。すべての AWS コンピューティングサービスとの VPC Lattice 統合、および幅広いアプリケーションおよびトランスポートプロトコルのサポートを使用して、ネットワーク接続をモダン化する方法を検討しました。また、リージョン間およびハイブリッドサービスアクセスの要件を満たすために、VPC Lattice の接続をオンプレミス環境に拡張する方法も検討しました。Amazon VPC Lattice の詳細については、 ドキュメント および Amazon VPC Lattice 入門ガイド を参照できます。 本稿は、2024年12月2日に Networking & Content Delivery で公開された “ Amazon VPC Lattice: modernize and simplify your enterprise network architectures ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

本記事は、2025 年 6 月 19 日に公開された Streamline Operational Troubleshooting with Amazon Q Developer CLI を翻訳したものです。 Amazon Q Developer は、開発者が複雑なワークフローを実行するのを支援する、最も高機能な生成 AI を活用した開発アシスタントです。Amazon Q Developer の コマンドラインインターフェイス (CLI) は、対話型 AI と AWS サービスへの直接アクセスを組み合わせることで、アプリケーションの理解、構築、運用をより効果的に行うことができます。 Amazon Q Developer CLI は、コマンドを実行して出力を分析し、ローカルマシン上で利用可能なトラブルシューティングツールとプラットフォームのベストプラクティスに基づいて、コンテキストに応じた推奨事項を提供します。 今日のクラウドネイティブ環境では、本番環境の問題のトラブルシューティングは、複数のターミナルウィンドウを切り替えたり、大量のログファイルを解析したり、数多くの AWS コンソールページを行き来したりする必要があります。このような絶え間ないコンテキストの切り替えは、問題解決を遅らせ、クラウドインフラストラクチャを管理するチームに認知負荷を加えることになります。 このブログ記事では、Amazon Q Developer CLI が対話形式のインタラクションを通じて困難なシナリオを効率化し、トラブルシューティング体験を変革する方法について見ていきます。 従来のトラブルシューティング体験 問題が発生すると、エンジニアは通常、インフラストラクチャの構成や複数のサービスにわたるログを手動で確認し、エラーパターンの分析に何時間も費やします。このプロセスでは、複数のインターフェース間の切り替え、さまざまなソースからの情報の相関付け、AWS に関する深い知識が必要です。この複雑なワークフローにより、問題解決に数時間から数日を要し、インフラストラクチャチームの負担が増加することがよくあります。 ソリューション: Amazon Q Developer CLI Amazon Q Developer CLI は、初期調査から問題解決までのトラブルシューティングプロセス全体を効率化し、シンプルな対話を通じて AWS の複雑なトラブルシューティングを取り組みやすく効率的なものにします。 Amazon Q Developer CLI の仕組み: 自然言語インターフェース: 対話形式のプロンプトを使用して AWS CLI コマンドを実行し、AWS サービスと対話します 自動検出: インフラストラクチャのマッピングと構成の分析を行います 高度なログ分析: 複数のサービスにわたるログの解析、相関付け、分析を行います 根本原因の特定: AI を活用した推論により問題を特定します ガイド付き修復: 最小限の手作業で修正を実施します 検証: ソリューションをテストし、複雑な問題をわかりやすく説明します 図 1 に示すように、Amazon Q Developer CLI の 組み込みツール の 1 つである use_aws は、AWS サービスと自然言語で対話することを可能にします。このツールは、ローカルマシンで設定された AWS CLI のアクセス許可を活用し、AWS リソースへの安全で承認されたアクセスを提供します。 図 1: Amazon Q Developer CLI のツール一覧 実際のトラブルシューティングシナリオ デモ環境のセットアップ このデモは、以下の環境構成で実施されました。 アプリケーションとインフラストラクチャのコードがローカルで利用可能 Amazon Q Developer CLI がインストール済み AWS CLI に demo-profile が設定済み 次の AWS 権限が設定済み: Amazon Elastic Container Service (ECS) 、 Amazon CloudWatch Logs 、 Application Load Balancer (ALB) および AWS Cloud Development Kit (CDK) のデプロイ プロジェクトディレクトリ内で Amazon Q Developer CLI を起動済み この環境には、必要なツールがインストールされたローカル開発マシン、適切な AWS アカウントの権限、およびターミナルアクセスが含まれています。プロジェクトディレクトリで Amazon Q Developer CLI を起動すると、関連するコードと設定ファイルにすぐにアクセスできます。 シナリオ: NGINX の 5xx エラーのトラブルシューティング このシナリオでは、図 2 の Amazon ECS Fargate にデプロイされた多層アプリケーションアーキテクチャのトラブルシューティングを示します。 Application Load Balancer (ALB) がアベイラビリティーゾーン間でトラフィックを分散 NGINX リバースプロキシサービス が受信リクエストを処理 Node.js バックエンドサービス がビジネスロジックを処理 Service Discovery が内部通信を実現 CloudWatch Logs が統合ログ管理を提供 図 2: このブログ記事で使用するアプリケーションの AWS アーキテクチャ図 従来のトラブルシューティング手順 図 2 のアーキテクチャにおいて、502 Gateway Timeout エラーが発生した場合、従来のトラブルシューティングでは以下が必要です。 ALB ターゲットグループのヘルスステータスのチェック 複数のコンソールで ECS サービスステータスの確認 異なるロググループの CloudWatch ログの分析 サービス間のエラーパターンの相関分析 インフラストラクチャコードの設定不具合のレビュー 修正の実装とデプロイ Amazon Q Developer CLI アプローチ ここでは、Amazon Q Developer CLI が体系的に処理する方法を、順を追って見てみましょう。 ステップ 1: 最初の問題報告 図 3 のスクリーンショットに示すように、アプリケーションのプロジェクトディレクトリ内で、Amazon Q Developer CLI に問題の説明として最初のプロンプトが与えられます。Amazon Q Developer が応答して、NGINX アプリケーションの 502 Gateway Timeout エラーを調査すると回答しています。 プロンプト: Our production NGINX application is experiencing 502 Gateway Timeout errors. I have checked out the application and infrastructure code locally and the AWS CLI profile 'demo-profile' is configured with access to the AWS account where the infrastructure and application is deployed to. Can you help investigate and diagnose the issue? ※訳者注: 本番環境の NGINX アプリケーションで 502 Gateway Timeout エラーが発生しています。アプリケーションとインフラストラクチャのコードをローカルに取得しており、AWS CLI プロファイル ‘demo-profile’ にはインフラストラクチャとアプリケーションがデプロイされている AWS アカウントへのアクセス権限が設定されています。この問題の調査と診断を手伝ってもらえますか？ 図 3: 問題の説明を入力した Amazon Q Developer CLI の画面 ステップ 2: 体系的なインフラストラクチャの検出 図 4 のスクリーンショットに示すように、Amazon Q Developer CLI が体系的にインフラストラクチャの検出を開始しました。最初のプロンプトにはアプリケーションが ECS でホストされているという情報は含まれていませんでしたが、Amazon Q Developer CLI はコンテキストを理解し、クラスターとその中のサービスを調べるために AWS CLI を実行します。クラスター内の両方のサービスで ECS タスクが実行されていることを確認しました。両方のサービスが正常なステータス (1/1 の希望数) を示していることから、サービスの可用性には問題がないことが判明します。 図 4: Amazon Q Developer CLI による AWS インフラストラクチャの検出 ステップ 3: 高度なログ分析 Amazon Q Developer CLI は NGINX コンテナから直近の CloudWatch ログを取得して分析し、図 5 のスクリーンショットに示すように、重要なエラーパターンを即座に特定します。Amazon Q Developer は「完璧です！問題が見つかりました。NGINX のログには、アップストリームのタイムアウトメッセージによる 504 gateway timeout が明確に示されています」と応答します。 図 5: Amazon Q Developer CLI による CloudWatch ログの分析 ステップ 4: Amazon Q Developer CLI による分析と根本原因の特定 Amazon Q Developer はバックエンドサービスのログを調査し、図 6 のスクリーンショットに示すように、バックエンドサービスのレスポンス時間と NGINX のタイムアウト設定の不一致を発見しました。 図 6: Amazon Q Developer CLI による根本原因の特定 ステップ 5: Amazon Q Developer CLI の根本原因分析 図 7 のスクリーンショットに示すように、Amazon Q Developer CLI は ECS タスク定義を調べて、設定の不一致を正確に特定します。Amazon Q Developer は以下のことを発見しました。 バックエンドサービスは response_delay=15000 (15 秒) で設定されています NGINX プロキシは proxy_read_timeout 10 秒で設定されています この不一致により、バックエンドのレスポンスが NGINX のタイムアウトしきい値を超えた場合に、504 gateway timeout エラーが発生します。 図 7: Amazon Q Developer CLI による根本原因分析と問題検出 ステップ 6: コードの自動修正 ここで Amazon Q Developer CLI の真価が発揮されます。問題の診断だけでなく、修正も実装してくれます。Amazon Q Developer CLI は ECS タスク定義の CDK コードが定義されているプロジェクト内で起動されているため、図 8 のスクリーンショットに示すように、コードの設定を特定し、修正しました。 図 8: Amazon Q Developer CLI による CDK コードの修正 ステップ 7: デプロイ 図 9 のスクリーンショットに示すように、Amazon Q Developer CLI は、最初のプロンプトで提供された ‘ demo-profile ‘ AWS CLI プロファイルを使用して、 cdk synth と cdk deploy を実行し、修正をビルドしてデプロイします。 図 9: Amazon Q Developer CLI による CDK コードのビルドとデプロイ ステップ 8: 検証 図 10 のスクリーンショットに示すように、Amazon Q Developer CLI は、デプロイが成功した後、ALB エンドポイントに curl リクエストを送信してソリューションを検証します。 図 10: Amazon Q Developer CLI による修正の検証 さらに Amazon Q Developer は、図 11 のスクリーンショットに示すように、修正がデプロイされた後にヘルスチェックエンドポイントにリクエストを送信し、すべてが正常に動作していることを検証します。 図 11: Amazon Q Developer CLI によるヘルスチェックエンドポイントの検証 Amazon Q Developer CLI が成し遂げたこと 対話形式の指示だけで、Amazon Q Developer CLI は完全なトラブルシューティングサイクルを実行しました。 インフラストラクチャの検出: ECS クラスター、サービス、依存関係を自動的にマッピング ログの相関分析: 複数のサービスにわたる多数のログエントリを分析 根本原因分析: NGINX のタイムアウト (10 秒) とバックエンドの応答遅延 (15 秒) における設定の不一致を特定 コードレベルでの診断: CDK インフラストラクチャコード内の問題のあるタイムアウト設定を発見 自動実装: NGINX のタイムアウト値を増やすためにインフラストラクチャコードを修正 エンドツーエンドのデプロイ: 完全なソリューションの構築、デプロイ、検証を実施 包括的なテスト: 修正の有効性とシステム全体の正常性を検証 Amazon Q Developer CLI は、単一の対話型インターフェイスでトラブルシューティングタスクを処理し、複数のツールや AWS CLI コマンドを使用する必要性をなくします。 まとめ Amazon Q Developer CLI は、クラウドインフラストラクチャの問題をトラブルシューティングする方法の大きな進化を示しています。自然言語理解と強力なコマンド実行機能を組み合わせることで、複雑なトラブルシューティングのワークフローを効率的で実践的な対話に変換します。NGINX の 5xx エラーや他の AWS サービスで発生する同様の問題に対処する場合でも、Amazon Q Developer CLI は、自然で直感的な対話型インターフェイスを通じて、問題の診断、修正の実装、解決策の検証を支援します。 次回トラブルシューティングの課題に直面した際は、Amazon Q Developer CLI を試してみてください。運用ワークフローにどのような変化をもたらすか、ぜひ体験してください。 Amazon Q Developer の機能と料金の詳細については、 Amazon Q Developer の製品ページ をご覧ください。 翻訳はパートナーソリューションアーキテクトの田根が担当しました。 著者について Kirankumar Chandrashekar は AWS の生成 AI スペシャリストソリューションアーキテクトで、Amazon Q Developer に注力しています。AWS クラウドサービス、DevOps、モダナイゼーション、Infrastructure as Code に関する深い専門知識を活かし、AI を活用した革新的なソリューションを通じて、お客様の開発サイクルの加速と開発者の生産性向上を支援しています。Amazon Q Developer を活用することで、チームがより迅速にアプリケーションを構築し、定型タスクを自動化して、開発ワークフローを効率化できるようにしています。 Kirankumar は、複雑なお客様の課題を解決しながら開発者の効率性向上に尽力しており、音楽、料理、旅行を趣味としています。

本記事は、2025 年 8 月 6 日に公開された Improve email deliverability with tenant management in Amazon SES を翻訳したものです。翻訳は Solutions Architect の 松岡勝也 が担当しました。 Amazon Simple Email Service (Amazon SES) は、E コマースサービスから金融機関、マーケティングテクノロジー製品プロバイダーまで、さまざまな業界で組織のメールコミュニケーションニーズの管理を支援しています。多くの企業は、自社のメール送信だけでなく、エンドユーザーに代わって、あるいは様々な事業部門にわたってメールを送信する課題に直面しています。このような マルチテナントメール送信プラクティス として知られるシナリオには、慎重なアーキテクチャの検討が必要です。例えば、マーケティングサービスが数百の小売クライアントのプロモーションメールを送信する必要がある場合や、企業の IT チームが複数の事業部門 (BU) 全体のメールコミュニケーションを管理する場合などが該当します。これらのクライアントや BU はテナントとしても識別されます。 Amazon SES でマルチテナンシーを正常に実装するために、顧客は通常、Amazon SES 内でアーキテクチャパターンを開発し、各テナントのメール送信評価を分離しながら、数千のエンドユーザーのメール送信ニーズを効率的に処理するという重要な目標を達成します。この分離は、各顧客のメール配信性能のメトリクスを保護し、あるテナントの問題が他のテナントに影響を与えることを防ぐために重要です。Amazon SES のお客様は、メール送信用の分離された設定セットを通じてマルチテナンシーを実現できますが、従来、評価管理と適用はアカウントレベルで行われていました。これに対応するため、Amazon SES は個々のテナントレベルでのテナント分離と評価管理を可能にするテナント管理機能を提供するようになりました。この新機能により、単一の Amazon SES アカウント内で複数のテナントを管理する組織は、より優れた制御と柔軟性を得られ、各テナントは独自の送信評価を個別に維持できるようになります。 この記事では、 新しくリリースされたテナント管理 機能について説明します。この機能により、個々のテナントのオンボーディングと評価を分離して管理できるようになります。この機能を使用すると、1 つの AWS アカウント内で最大 10,000 個の分離されたテナントを作成・管理できます (明示的なリクエストにより 300,000 個まで増やすことが可能)。各テナントは独立した設定と評価メトリクスを持つことができます。自動化されたテナントレベルの制御、リアルタイムモニタリング、カスタマイズ可能な送信ポリシーを通じて、これらの機能がメール配信品質をどのように維持するかについて説明します。 複数の顧客に代わってメールを送信するサービスプロバイダーであっても、複数の BU や LOB (Line of Business) を統括する企業であっても、この新機能は評価ベースの検出結果を特定し、他のテナントの評価を保護するために個々のテナントの送信を一時停止する高度なワークフローを提供します。これらの機能強化は、 Amazon SES が提供されている AWS リージョン でグローバルに利用可能で、大規模なメール配信管理における大きな進歩を表しています。 ユースケース Amazon SES のテナント管理機能を使用することで、以下のユースケースを簡単に実現できます。 異なるドメインを持つ複数の BU からの複数ブランドの導入 マーケティングとトランザクションのテナントの分離 ISV (独立系ソフトウェアベンダー) の顧客が求める、顧客ごとのメール送信の評価をサポート 設定セットを使用したドメイン管理 個々の顧客のメール送信の評価の追跡とメール送信プロセスの制御 マルチテナントメール運用の課題 メールはビジネスにとって重要なコミュニケーションチャネルです。しかし、複数のテナント (顧客や BU) に対するメール運用の管理には、これまで以下のような大きな課題がありました： 分離の不足: 適切なテナント分離がないと、1 つのテナントの不適切な送信方法が他のテナントのメール配信性能とメール評価に悪影響を及ぼし、メール送信運用全体を危険にさらす可能性がある。 可視性の制限: テナントごとのメールパフォーマンスメトリクスの理解や送信評価の独立した管理が、不可能ではないにしても困難である。 スケーラビリティの制約: 多くの組織が、ID や設定セットなどのリソースに対するアカウントレベルの制限により、メール運用のスケーリングに苦労している。 不十分な制御: テナント固有の制限や設定を行うことができないため、個々のテナントが他のテナントに影響を与えたり、割り当てられたリソースを超過したりすることを防ぐのが困難である。 複雑なモニタリング: テナントのアクティビティを監視するためのカスタムソリューションの構築は、一貫性のない非効率なワークフローにつながることが多くある。 テナント管理機能のメリット Amazon SES のテナント管理機能は、顧客や LOB ( テナント と呼ばれます) に代わって大規模なメール送信を管理する組織向けの包括的なソリューションを提供します。この機能は、Software as a Service (SaaS) プロバイダー、メールサービスプロバイダー、そして複数のクライアントや部門間でメール運用管理を行う企業にとって特に有用で、テナントごとに分離して管理することができます。 テナント管理により、組織はメールの送信フローと評価を独立して効果的に管理し、さまざまなメール運用を監視できます。この新機能により、組織による Amazon SES の使用方法が改善され、以下の主要な機能によってテナントレベルでより優れた制御と可視性を持って、複雑で多面的なメール運用を処理できるようになります。 テナントリソースと評価の分離: テナント管理により、異なる顧客やビジネスラインにわたってメールの評価を保護する、専用のリソース分離が提供されます。各テナント（顧客または LOB ）は、メールボックスプロバイダーが Amazon SES アカウント内で監視する、メール送信用 IP、ドメイン、DomainKeys Identified Mail (DKIM) 署名ヘッダー内の識別子など、独自の専用リソースセットを持ちます。テナント管理により、リソース割り当ての詳細な制御が可能になります。組織の要件に基づいて、テナント固有または共有の送信 ID を割り当てることができます。各テナントは、割り当てられたリソースへの安全なアクセスを提供する、専用の SMTP または API 認証情報を受け取ることができます。送信トラフィックを分離し、各テナントの個別の評価プロファイルを維持するテナントレベルの IP プールを設定できます。テナント管理を使用して、各テナントのメールの処理と追跡方法を定義するテナント固有の設定セットを管理できます。メールテンプレートを特定のテナントに関連付けることができ、ブランド化されたコミュニケーションが適切に分離され制御されることを確認できます。この分離により、1 つのテナントの行動が他のテナントの評価やパフォーマンスに影響を与えないようにします。テナントが配信の問題や評価の問題に遭遇した場合、これらの課題は専用リソース内に限定されます。このアプローチにより、すべてのテナント間の公平性が維持され、メール運用に対する明確な個別の責任所在が確立されます。 テナント固有のメトリクスをリアルタイムでモニタリング : 送信者の評価に直接影響を与える未加工のバウンス率や苦情率など、各テナントの具体的な評価メトリクスにアクセスできます。このシステムを使用して、詳細な追跡と分析のために、テナントにマッピングされた各設定セットを通じてテナントレベルのイベントの送信先を設定できます。これにより、各テナントの パフォーマンスを追跡 し、利用状況とコンプライアンスのメトリクスを個別に把握できる詳細なテナントレベルのイベントにアクセスできます。また、ビジネス要件に合わせて設定可能な閾値に基づいて、自動的な強制ポリシーを確立できます。テナントの評価に関する検出事項が検出された場合や、テナントのステータスが変更された場合、 Amazon EventBridge を通じてリアルタイムのアラートを受け取ることができます。 数十万のテナントまでスケール : このシステムは大規模なスケーリングに対応するように設計されており（アカウントあたり 1 万テナントから開始し、最大 30 万テナントまで増やすことが可能）、インフラストラクチャの制限を気にすることなく、ビジネスを成長させたりメール運用を拡大したりできます。数十から数十万のテナントを管理する場合でも、システムはニーズに適応します。 テナント管理ワークフローの自動化 : 新しいテナントのオンボーディング、ポリシーの適用、テナントのライフサイクル管理のための自動化プロセスを設定できます。このシステムでは、API とコンソールインターフェイスを使用してテナントの作成、変更、削除を行い、必要に応じて送信機能の一時停止や再開を柔軟に行うことができます。この自動化により、すべてのテナントに対して一貫したメール送信基準を適用する際の手動作業を削減できます。 高い配信性能を維持するための対象を絞った強制アクション : 特定のテナントに問題が発生した場合、他のテナントに影響を与えることなく、送信権限の一時停止やより厳格な評価ポリシーの適用など、正確なアクションを取ることができます。この機能により、運用全体の高い配信性能を維持することができます。 これらの機能は、総合的にメール管理機能の進歩を示しており、組織は評価とコンプライアンスを厳格に管理しながら、より高度で、スケーラブルで、信頼性の高いメールサービスをクライアントや社内部門に提供できます。 テナント管理の仕組み Amazon SES のテナント管理機能を使用して、メール送信業務を効果的にセグメント化できます。このシステムを使用すると、1 つの Amazon SES アカウント内に複数のテナントを作成でき、各テナントは独自の専用リソースを持つことができます。これらのリソースには、送信 ID、SMTP 認証情報、設定セット、専用 IP プールなどの重要なコンポーネントが含まれます。このアーキテクチャが特に柔軟なのは、IP プールや設定セットなどの共通リソースをテナント間で共有できることで、運用上の分離を維持しながら最適なリソース利用が可能になります。次の図は、上記の情報を詳しく説明しています。 前提条件 テナント管理を開始するには、以下が必要です： AWS アカウント Amazon SES で検証済みの送信元 ID (ドメインまたはメールアドレス) メール設定用の設定セット ビジネス要件に基づいたテナントの構造の明確な理解 テナント管理の設定方法と主要な考慮事項 Amazon SES でマルチテナントシステムを構築するには、IP プール、ドメイン検証、設定セットという 3 つの重要なコンポーネントを慎重に設定する必要があります。セットアップ手順に従うことで、各テナントは分離されたリソース、適切なトラッキング、モニタリング機能を持つことができます。Amazon SES の AWS Management Console または Amazon SES API を使用することで、各テナントの評価を分離しながら、高い配信性能を維持できる堅牢なメール送信インフラストラクチャを構築できます。 IP プールの設定 IP プールの設定 は、Amazon SES を使用してメール通信を送信するための基本的なステップです。マルチテナントのセットアップを開始するには、設定セットを通じて各顧客専用の専用 IP プールまたはマネージド IP プールを確立します。まず、 Amazon SES コンソール にアクセスし、 専用 IP のセクションに移動します。新しい 標準 IP プール を作成し、顧客を明確に識別できる名前を付けます。AWS Support を通じて、顧客の送信量に基づいて必要な IP アドレスの数をリクエストします。IP がプロビジョニングされたら、適切なプールに割り当てます。その後、IP プールをテナントに紐付けられた設定セットと関連付けます。IP ウォームアップについては、45 日間かけて送信量を徐々に増やす自動ウォームアップスケジュールを有効にするか、それを無効にして独自のカスタムウォームアッププランを実装するかの 2 つのオプションがあります。最適な配信率を確保するために、ウォームアップの進行状況を注意深く監視してください。 ドメイン検証プロセス IP プールの設定後、お客様の送信者識別情報を確立するためにドメインの検証を進めます。Amazon SES コンソールの「 検証済み ID 」(検証済み ID とは、Amazon SES で検証済みのドメインまたはメール ID のこと) セクションに移動し、お客様のドメイン名を使用して新しいドメイン識別情報を作成します。Amazon SES は、ドメインの DNS 設定に追加する必要がある DKIM レコードを提供します。お客様と協力して、これらのレコードを DNS 設定に正しく実装してください。検証プロセスは通常、完了までに 24～72 時間かかります。この間、Amazon SES コンソールで定期的に検証ステータスを確認し、プロセスが正常に完了することを確認してください。 テナントの認証と認可 特定の ID と設定に対するメール送信の制限に加えて、 AWS Identity and Access Management (IAM) のユーザーまたはロールのポリシーを使用して、テナントごとにメール送信権限を制限できます。以下のポリシーでは、テナントの Amazon Resource Name (ARN) が arn:aws:ses:us-east-1:111122223333:tenant/testTenant1/tn-e08a68010000a3e4c67bcd990910 、ID が arn:aws:ses:us-east-1:111122223333:identity/example.com 、設定セットが arn:aws:ses:us-east-1:111122223333:configuration-set/testTenant1. の場合にのみメール送信を許可する制限を示しています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "ses:SendRawEmail", "Resource": [ "arn:aws:ses:us-east-1:111122223333:identity/example.com", "arn:aws:ses:us-east-1:111122223333:configuration-set/TestTenant1" ], "Condition": { "StringEquals": { "ses:TenantName": "testTenant1" } } } ] } 設定セットのセットアップ 最後のステップは、トラッキングとモニタリングを管理する設定セットの作成と構成です。 まず、Amazon SES コンソールの設定セット セクションで新しい 設定セット を作成し、顧客の識別子に合わせて名前を付けます。 カスタムトラッキングドメインを設定し、開封とクリックの適切なトラッキング設定を有効にします。 この設定を、先ほど作成した IP プールにリンクします。 次に、メール配信状況を監視するためのイベントの送信先を設定します。これには Amazon CloudWatch メトリクス、 Amazon Data Firehose 、または Amazon Simple Notification Service (Amazon SNS) トピックを含めることができます。 CloudWatch では、バウンス率 (推奨しきい値: 5%) や苦情率 (推奨しきい値: 0.1%) などの重要なメトリクスに対してアラームを作成します。 これらのしきい値を超えた場合にチームに通知するシステムを設定し、配信の問題に迅速に対応できるようにします。 CLI コマンドの例 テナント管理の利用を開始するには、コンソール、 AWS Command Line Interface (AWS CLI) 、または AWS SDK を使用できます。以下は、 AWS CLI を使用してテナントを作成および設定する 基本的な例です。 以下では、テナントの作成から削除までのテナント管理手順のライフサイクルについて説明します。AWS CLI バージョン 2.28.0 以降を使用していることを確認してください。必要に応じて、 AWS CLI のインストールと更新手順 を参照してください。 新しいテナントの作成 aws sesv2 create-tenant --tenant-name testTenant1 --region us-east-1 “–region” の値はオプションです。 テナントに送信 ID (ドメインまたはメール ID) を割り当てる aws sesv2 create-tenant-resource-association --tenant-name testTenant1 --resource-arn arn:aws:ses:us-east-1:111122223333:identity/example.com テナントに設定セットを追加 aws sesv2 create-tenant-resource-association --tenant-name testTenant1 --resource-arn arn:aws:ses:us-east-1:111122223333:configuration-set/test1 ここでは、選択された設定セットにすでに IP プール が関連付けられていることを前提としています。 get-tenants または list-tenants によるテナント情報の取得 aws sesv2 get-tenant --tenant-name testTenant1 --region us-east-1 aws sesv2 list-tenants --region us-east-1 <List all the tenants with their ARN> get-tenant または list-tenants を使用して、テナントの名前、ID、ARN、作成タイムスタンプ、タグ、送信ステータスなど、特定のテナントに関する情報を取得できます。また、 list-tenants を使用してアカウントに関連付けられているすべてのテナントを一覧表示できます。 テナントのリソース一覧を表示 aws sesv2 list-tenant-resources --tenant-name testTenant1 テナントを使用してメールを送信 aws sesv2 send-email --from-email-address "sender@exanple.com" --destination "ToAddresses=recipient@example.org " --configuration-set-name test1 --content '{"Simple":{"Subject":{"Data":"Your email subject","Charset":"UTF-8"},"Body":{"Text":{"Data":"This is the plain text version.","Charset":"UTF-8"},"Html":{"Data":"<html><body><h1>This is the HTML version</h1><p>With formatted content.</p></body></html>","Charset":"UTF-8"}}}}' --tenant-name testTenant1 デフォルトで適用される標準ポリシーから厳格ポリシーへ 評価ポリシー を変更 aws sesv2 update-reputation-entity-policy --reputation-entity-type RESOURCE --reputation-entity-reference arn:aws:ses:us-east-1: 111122223333:tenant/ testTenant1/tn-145f7885b000074362bfa074ec4e1 --reputation-entity-policy arn:aws:ses:us-east-1:aws:reputation-policy/strict  テナントの送信を無効化 (テナントを一時的に無効化または一時停止) aws sesv2 update-reputation-entity-customer-managed-status —reputation-entity-type RESOURCE —reputation-entity-reference arn:aws:ses:us-east-1:111122223333:tenant/testTenant1/tn-145f7885b000074362bfa074ec4e1 —sending-status DISABLED テナントの削除 (テナントを Amazon SES アカウントから完全に削除) aws sesv2 delete-tenant --tenant-name testTenant1 SMTP を使用したメール送信 X-SES-TENANT ヘッダーは、AWS が複数のテナント間でメールを管理するために使用されます。X-SES-TENANT フィールドにテナント名を指定することができます。このアプローチにより、テナント情報に基づいてメールをより適切に整理およびルーティングすることができます。これを実装するには、SMTP を使用してメールを送信する際に X-SES-TENANT ヘッダーを追加します。以下の Python コードは、メール送信プロセスでこのヘッダーを含める方法を示しています： <Pseudo code> import smtplib from email.mime.text import MIMEText from email.mime.multipart import MIMEMultipart def send_email(smtp_server, port, username, password, from_email, to_email, subject, body, config_set=None): msg = MIMEMultipart() msg['From'] = from_email msg['To'] = to_email msg['Subject'] = subject msg['X-SES-TENANT'] = 'test1' if config_set: msg['X-SES-CONFIGURATION-SET'] = config_set msg.attach(MIMEText(body, 'plain')) with smtplib.SMTP(smtp_server, port) as server: server.starttls() server.login(username, password) server.send_message(msg) # Example usage: send_email('email-smtp.us-east-1.amazonaws.com', 587, 'YOUR_SMTP_USERNAME', 'YOUR_SMTP_PASSWORD','sender@exanple.com', 'recipient@example.org', 'Test Subject', 'Hello World', 'test1') テナントのメールイベントのフィードバックループ管理 メールイベントの受信やフィードバックの仕組みの利用は、テナントのメール送信運用を監視する上で重要です。テナント管理は、マルチテナント環境での評価管理機能を提供し、組織がテナントベース全体のメール送信運用を詳細に制御できるようにします。テナントレベルで評価に基づくポリシーを自動的に監視・適用できるため、1 つのテナントの問題のあるメール送信動作が他のテナントの配信性能に影響を与えることはありません。信頼性の問題が検出された場合、Amazon SES は影響を受けたテナントのメール送信を自動的に一時停止し、他のテナントはメール送信を妨げられることなく継続できます。組織は、配信性能の問題を早期に検出する自動化された評価検出を通じて、正確な制御メカニズムを実装できるようになりました。テナントの分離は、機械学習モデルとシグナルに基づく検出を使用して、メール送信動作の問題のあるパターンを特定します。問題が検出されると、Amazon SES は自動的に親アカウントに通知し、カスタマイズ可能なしきい値に基づいて事前に定義されたアクションをトリガーできます。この詳細な制御により、テナントレベルで問題を分離して対処しながら、メール送信インフラストラクチャ全体で高い配信性能を維持できます。 執行データとパターン 各国の法律が寄せ集めのように適用されている他のコミュニケーションチャネルとは異なり、大量メール配信は少数の大手メールサービスプロバイダーが定める要件に従う必要があります。Google、Yahoo、Microsoft などのプロバイダーが配信性能の目標を設定し、その遵守は送信者や Amazon SES などのサービスプロバイダーに委ねられています。Amazon SES は、マルチテナントプロバイダーを含む直接の顧客に対して、主要な執行シグナルを監視することを期待しています。そして、テナントが不正なメールを送信した場合、AWS の顧客が主要な執行シグナルを監視し、不正なテナントの一時停止や送信の停止などの適切な措置を取ることを想定しています。執行シグナルと信頼指標は、メールの評価管理システムにおいて不可欠な要素となります。これらのシグナルは、メール送信者の信頼性を評価するために監視する様々なデータポイントと行動を指し、これらのシグナルから導き出される信頼指標は、送信者の評価とベストプラクティスの遵守度を示す指標となります。Amazon SES は、送信前のシグナル（アカウントの審査や設定など）と送信後のシグナル（配信成功率、バウンス率、受信者の反応度など）を組み合わせて評価結果を算出します。これらの結果は、自動的な執行アクションと手動レビューに活用され、サービスが高い配信性能基準を維持しながら、不要または悪意のあるメールから受信者を保護することに役立ちます。シグナル分析と執行プロセスを継続的に改善することで、すべてのユーザーにとって信頼性が高く安全なメールエコシステムの構築を目指しています。 テナント分離と評価管理の運用 複数のテナントが SES アカウントを通じてメールを送信する場合、送信動作と評価を監視する必要があります。Amazon SES は、 評価結果 を通じて包括的な監視システムを提供し、テナントが懸念される送信パターンを示した場合に警告を通知します。これらの検出結果はダッシュボードに表示され、 Amazon EventBridge のデフォルトイベントバス を通じてイベントとして配信されるため、問題が発生した際に即座に通知を受けることができます。 メール配信管理者として、日常のモニタリングルーチンには、すべてのテナントのステータスを一目で確認できるテナント管理ダッシュボードの確認を含める必要があります。特に注意が必要なのは、低レベルと高レベルの 2 段階で示される評価結果です。これらの指標は、バウンス率や苦情率などのメトリクスが許容のしきい値を超えた場合に表示されます。 評価ポリシー を設定することで、これらのしきい値を超えた場合にテナントの送信を自動的に一時停止できます。標準的な実施（高レベルの結果で一時停止）または厳格な実施（低レベルの結果で一時停止）のオプションを選択できます。 テナントが自動または手動で一時停止された場合、その原因を調査する必要があります。評価結果には、バウンス率や苦情率の上昇など、一時停止のトリガーとなった詳細な情報が含まれています。テナントの根本的な問題に対処した後、送信を再開することができます。回復中、テナントはメトリクスが正常なレベルに戻ることを確認するためのモニタリングを行いながら、送信が可能になります。メトリクスが改善されると、テナントは自動的に通常の有効なステータスに戻ります。 利用可能なメトリクスとデータポイント これらのコアの評価メトリクスは Amazon SES によって公開され、EventBridge にルーティングできます。イベントフィードバックループにはテナント名と ID が含まれるため、テナント固有のバウンス率を追跡できます。 テナントごとの苦情率 サードパーティ別の苦情率 Spamhaus の IP リスト登録状況 メール量のパターン 継続的な管理においては、テナントのリソースと設定を完全にコントロールすることができます。必要に応じて送信 ID や設定セットの割り当てや削除、評価ポリシーの調整、懸念されるパターンを発見した場合の手動での送信の一時停止などが可能です。この自動化されたモニタリング、明確な評価シグナル、柔軟な管理ツールを組み合わせることで、個々のテナントの問題がアカウント全体の評価に影響を与えることを防ぎながら、テナントを管理することができます。重要なのは、ダッシュボードと評価結果を積極的にモニタリングし、問題が発生した際に迅速に対応することです。 まとめ お客様がテナント管理機能を活用して、メール運用を変革し、効率性を向上させ、ユーザーにより良い利用体験を提供するためにどのように活用されるのかを楽しみにしています。テナント分離を開始するには、 Amazon SES コンソール にアクセスするか、Amazon SES デベロッパーガイドの テナント をご覧ください。料金の詳細については、 Amazon SES の料金ページ でご確認いただけます。お客様のフィードバックとニーズに基づいてテナントの分離と管理を改善することに取り組んでおり、将来的にはさらに強力で柔軟なメール管理機能を提供していく予定です。Amazon SES で マルチテナント管理 を是非試してみてください。 著者について Satya S Tripathy Satyasovan Tripathy works as a Sr Specialist, Solution Architecture at AWS. He is located in Bengaluru, India, and focuses on the AWS business applictions product portfolio. He enjoys reading and travelling outside of work. Nideesh K T Nideesh is an experienced IT professional with expertise in cloud computing and technical support. Nideesh has been working in the technology industry for 9 years. In his current role as a Sr. Cloud Support Engineer, Nideesh provides technical assistance and troubleshooting for cloud infrastructure issues. Outside of work, Nideesh enjoys staying active by going to the gym, playing sports, and spending time outdoors. Tom Gilbert Tom Gilbert is a Senior Product Manager with the Amazon Simple Email Service team at AWS. Tom joined Amazon in May 2021, bringing a breadth of experience delivering enterprise solutions and scaling start-ups across industries. Outside of work, Tom is an avid sports enthusiast and enjoys spending quality time outdoors with his wife and two kids.

本記事は米国時間 8 月 15 日に公開された「 Kiro Pricing Plans Are Now Live 」を翻訳したものです。Kiro の最新情報は、 https://kiro.dev/ をご覧ください。 過去数週間にわたり、Kiro の料金に関するいくつかの重要なアップデート（ Kiro の価格更新 + ウェイトリストへの招待をまもなく開始 、 Kiro の価格設定を理解する：Spec、Vibe、使用量のトラッキング ）を共有してきました。これらのアップデートは、皆さまからのフィードバックに応える形で料金モデルを見直したものです。コミュニティの多くの方々から「プレビュー制限を超えて Kiro を使いたい」という声や、「ウェイトリストから外れて自分で Kiro を試したい」という声をいただいていました。本日（8/15）より料金プランを公開することで、すでにウェイトリストに登録している Kiro 愛用者のオンボーディングを加速し、既存ユーザーにも Kiro の利用に対するより大きなコントロールを提供できるようになります。 あなたにとっての意味 本日（8/15）以降、Amazon Q Developer サブスクリプションを持たない Google、GitHub、または AWS Builder ID アカウントでログインしたユーザーは、新しい料金モデルに移行しました。これらのアカウントは現在「無料（Free）」ティアとなっており、月 50 件の Vibe リクエストと 0 件の Spec リクエストが含まれています。 さらに、すべてのユーザーに対して 100 件の Spec リクエストと 100 件の Vibe リクエストのウェルカムボーナス を提供します。このボーナスは、新しい料金プランで最初のリクエストを行った時点から 14 日間有効です（どのティアであっても適用）。これにより、Kiro のすべての機能を体験し、自分の利用ニーズを把握するための時間を確保できます。 準備が整ったら、以下の 3 つの有料プランを選択できます。 利用状況のモニタリング 月ごとの Vibe / Spec リクエストの利用状況をプラン上限に対して確認でき、オーバー時の追加料金（有効化した場合）も追跡できます。また、サブスクリプションプランの管理も可能です。詳しくは Kiro のドキュメント をご確認ください。 プランのアップグレード アップグレードは簡単です。 Kiro のプロフィールアイコンをクリックし、「Upgrade Plan」を選択 希望のプラン（Pro、Pro+、Power）を選択 支払い情報を入力すると、新しいプランが即時に有効化 アップグレードやダウングレード、請求履歴の閲覧、支払い情報の更新はいつでも可能で、変更は即座に反映されます。 どのプランを選んでいいか分からない方は以下を参考にしてください。 初めて利用する場合： Pro を選び、オーバー分の課金を有効にして柔軟に利用しながら使用パターンを学んでください。 使用パターンが分かっている場合： 通常の月間利用に余裕を持って対応できる最小プランを選択してください。 コストを固定したい場合： 最大利用量をカバーするプランを選び、オーバー分の課金を無効化してください。利用は月の上限に達すると一時停止し、翌月にリセットされます。 重要：v0.2.13 以降にアップグレードして始めましょう 新しい使用状況ダッシュボードにアクセスし、プランを管理するには、 Kiro v0.2.13 以降にアップグレードする 必要があります。Kiro 内の設定アイコンをクリックし、「Check for updates…」を選んでください。 質問とフィードバック 詳細な料金に関する質問については、更新された料金 FAQ や ドキュメント をご覧ください。また、サブスクリプションモデルに関する最近のブログ記事（ Kiro の価格更新 + ウェイトリストへの招待をまもなく開始 、 Kiro の価格設定を理解する：Spec、Vibe、使用量のトラッキング ）も参照できます。フィードバックを共有したり質問したり、他の開発者が Kiro をどのように使っているかを知るために、 Discord コミュニティ にもぜひ参加してください。 Kiro v0.2.13 にアップデートし、使用状況ダッシュボードを確認し、自分の開発ニーズに合ったプランを選んで新しい料金体系を始めましょう。

本記事は米国時間 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;プロフェッショナルサービス本部 シニアデリバリーコンサルタントの小林が翻訳しました。 <!-- '"` -->