このブログは、第一三共株式会社 スマートリサーチ第二研究所と QSimulate による共著です。 はじめに 第一三共株式会社 (以下、第一三共) では D4 を活用し、DMTA サイクル (Design-Make-Test-Analyze) の中で Structure Based Drug Design (SBDD) 及び親和性予測を通じた創薬効率化を推進している。 創薬研究の高度化に伴い、親和性予測の精度向上はますます重要な課題となっている。Free Energy Perturbation (FEP) の活用に加え、より正確なエネルギー関数の導入が求められており、特に今後複雑化が見込まれる化学モダリティにおいては、従来の FEP では対応が困難であった非古典的相互作用や共有結合系の親和性予測を高い精度で実施できる技術が不可欠である。こうした背景のもと、QSimulate との国内外での面談を通じ、同社が有する量子化学 (QM) を組み込んだ FEP 計算技術 (QM-FEP) を評価した。同社は、創薬研究に求められる実用的なスループットを確保しながら、クラウド環境を活用した計算コストの最適化にも取り組んでいる。計算精度と速度を高い水準で両立する同社の技術は我々のニーズに合致するものと判断した。 QSimulate の紹介、特長 QSimulate は創薬研究を加速するためのシミュレーション技術を開発するボストン発のスタートアップであり、ノースウェスタン大学教授であった CEO 塩崎亨らにより 2018 年に設立された。独自の量子化学計算技術を駆使することで、世界で唯一 QM に基づく FEP を商用プロダクト QUELO として展開している。QUELO は QM 力場と独自の AI 力場を併用することにより、従来の標的に対する高精度・高スループットとともに、金属配位性リガンドのような非古典的相互作用や共有結合系での高精度な結合親和性予測も可能にした。QUELO の機能強化や精度改善を目指して、現在はボストン、バークレー、ベルギー、東京の四拠点を中心とした国際チームで開発を推進している。 QUELO はコストパフォーマンスの優れた Amazon Elastic Compute Cloud (Amazon EC2) G7e や G6e インスタンス上で効率的に動作するように、単精度と倍精度を組み合わせた独自の混合精度アルゴリズムを採用している。従来の量子化学計算と比べて約 1,000 倍の高速化を達成し、タンパク質・リガンド複合体の量子化学計算が 1 スナップショットあたりミリ秒単位で処理可能となった。これまで数ヶ月かかっていたシミュレーション時間を数時間へと短縮、計算コストも 100 〜 1,000 分の 1 に削減することで、QM-FEP による創薬研究を現実的なものにした。 図 1: QUELO プラットフォームの図 QUELO は AWS ParallelCluster 上に展開され、 AWS CloudFormation を使った迅速なデプロイと簡易な運用を実現している。Amazon EC2 のオンデマンドインスタンスとスポットインスタンスを使い分けることで、状況に応じた弾力的な計算リソースの確保が可能である。またデータ基盤には Amazon Relational Database Service (Amazon RDS)、ストレージには Amazon Simple Storage Service (Amazon S3) を採用することで、データの堅牢性とアクセス利便性を確保している。さらに知的財産保護のため、ウェブアプリケーションを保護する AWS WAF など、AWS の豊富なセキュリティ機能を全面に活かした安全な環境を提供している。 図 2: AWS 上に展開された QUELO のアーキテクチャ図。QUELO は AWS ParallelCluster、Amazon EC2、Amazon RDS、 AWS Lambda 、Amazon S3、AWS WAF などの様々な AWS の機能を活用しています。 QSimulate の評価 (既存課題の貢献など) QUELO の技術導入により、従来の課題解決に向けた成果が得られてきている。QM 力場を活用した計算では良好な予測精度が確認され、さらに同社独自の AI 力場を組み合わせることで、計算精度と計算速度の両立が実現されている。 クラウド環境の活用においては、通常時はスポットインスタンス、緊急時はオンデマンドインスタンスを使い分けることで、現場のニーズに応じた柔軟な計算実行が可能であることが確認された。AI 力場の適用では計算時間の短縮を、QM 力場の適用では従来手法では対応が困難であった非古典的相互作用への対応をそれぞれ実現した。 既に複数の創薬プログラム・標的に活用しており、実際のプロジェクトにおいて新規ケモタイプ創出にも貢献した。今後、共有結合系において Warhead の比較が必要な場面での親和性予測についても、技術革新によってさらなる精度の向上と適応範囲拡大を期待している。 まとめ 創薬研究において、化合物候補を迅速に高活性な群へと絞り込むことは、効率化を行う上で必須なプロセスである。QSimulate 技術の活用は、QM 力場による高い予測精度と、 AI 力場およびクラウド環境を組み合わせた計算速度の向上を同時に実現できることが示され、本課題に対する有効な解決策の一つといえる。 今後は、本技術を複数創薬プロジェクトへ適用し、さらに推進していく予定である。計算精度・速度の両立がもたらす恩恵を享受し、創薬サイクルの加速と成功確率の向上に継続的に貢献していきたい。 おわりに 本ブログでご紹介した第一三共株式会社と QSimulate の取り組みや関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について 第一三共株式会社 岡田 晃季 (Akitoshi Okada) スマートリサーチ第二研究所 第三グループ シニアサイエンティスト: 創薬効率化に向けた、計算化学/機械学習による活性/物性予測を担当。「計算とはいつも二手三手先を考えて行うものだ…」と言えるようになりたい。 森友 紋子 (Ayako Moritomo) スマートリサーチ第二研究所 第三グループ プリンシパルサイエンティスト: 計算化学の活用を通じた創薬研究効率化実現を目指しています。仕事においても私生活においても、まず状況を整理したうえで効率を重視して行動するタイプで、息抜きは読書とピアノです。 芹沢 貴之 (Takayuki Serizawa) スマートリサーチ第二研究所 第三グループ長: マルチモダリティインフォマティクスの推進を基軸とする業務変革推進、研究効率化に興味があります。スポーツ観戦が好きですが種目がドッジボールからバレーボールと陸上に代わりました。 QSimulate 塩崎 亨 (Toru Shiozaki) QSimulate CEO: 創薬におけるコンピュータ・シミュレーションの新しいあり方を提案するために QSimulate をボストンで起業。前職ではノースウェスタン大学化学科で研究室を運営。最近庭いじりにはまっています。 井本 翔 (Sho Imoto) QSimulate Japan, Chief Scientist: 計算化学による研究開発加速をできるように、デプロイ支援から技術指導まで包括的なサポートを目指しています。元々は水泳をやっていましたが、最近は陸上進出を果たしマラソンにも熱中しています。 アマゾン ウェブ サービス ジャパン合同会社 中島 丈博 (Takehiro Nakajima) ハイテク & ヘルスケア・ライフサイエンス部 シニアソリューションアーキテクト: ヘルスケア・ライフサイエンスのお客様を中心にクラウド利用の技術支援をしており、ユースケースの紹介やお客様のご要望を具現化するための活動をしています。週末は旅の予定に思いを巡らせています。

こんにちは、ソリューションアーキテクトの松永です。 本記事では、 2026 年 6 月 25 日（木）と 26 日（金）の 2 日間、幕張メッセで開催される AWS Summit Japan 2026 のブース予告をお届けします。製造業に関する展示は AWS Expo 内の AWS for Industries です。このブログでは、その中から「生産ラインの未来」と題して AI エージェントが生産ラインのボトルネックを検知し改善までつなげるテーマについてご紹介します。製造業関連の全ブース紹介は こちらのブログ記事 をご覧ください。 このブースで体験できること 突然の増産指示、サプライチェーンの途絶、設備の予期せぬ故障——製造現場では、こうした外部環境の変化に即座に対応しなければなりません。しかし現実には「何が影響を受けるのか」を把握するだけでも、ERP・MES など複数システムを手作業で横断確認する必要があり、原因特定から改善策の立案、そして生産ラインの設計書を参照しながら生産プログラムを改修・検証するプロセスまでを含めると、熟練者でも数時間を要します。さらに、生産ラインの変更は大きな意思決定を伴い、スピード感を持った対応が難しいのが実情です。このブースでは、そんな課題を AI エージェントがどう解決するかを実演します。ナレッジグラフと IoT リアルタイムデータを活用し、影響分析→ボトルネック検出→改善策提案→生産ラインの制御方法の変更案の生成までを、 AI エージェントで一気通貫に行うデモを体験いただけます。 このブースの注目ポイント 会社の工場 → 生産ライン → 設備 → 部品 → サプライヤーの関係をナレッジグラフ（オントロジーマップ）で構造的に可視化し、 AI エージェントが活用しやすいデータ構造を事前に準備します 生産ラインをデジタルツイン化し、各工程のサイクルタイム vs タクトタイムを比較することで、ボトルネック発生時の要因特定を容易にします 生産ラインの動作を制御する PLC プログラムの変更案まで実装します 従来は熟練者が数時間かけていた「原因分析 → 対策立案 → 実装案作成」をエージェントとの会話だけで体験いただけます カメラ映像のような非構造化データも AI エージェントが活用できることで、よりマルチモーダルに工場の状況の変化点を監視できるようになります デモの概要 外部環境の変化として、需要の増加をAIエージェントが検知します ダッシュボード上で増産する手立てがないか AI エージェントに相談します AI エージェント が社内に今の生産ラインの稼働状況と蓄積されたデータを確認し、生産工程のボトルネックを検出します AI エージェントが工程設計書を参照し工程の一部をスキップすることを提案します AI エージェントは提案するだけでなく、該当の生産設備の PLC プログラムを改修します カメラの映像も活用することでセンサーデータではわからない生産ラインの異常を検知します 改修したプログラムを生産ラインに直接反映するのではなく、ソフトウェア定義型ファクトリーが用意したシミュレーション環境と連携し、PLC プログラムの事前検証をします 検査を終えたら生産ラインに PLC プログラムを反映します （生産ラインのオントロジーマップ） （デジタルツインと AI エージェントの動作） 使用している AWS サービス Amazon Neptune ：BOP・BOM・在庫・生産オーダー・設備・サプライヤーの関係をナレッジグラフとして格納し、影響範囲の調査に利用 AWS IoT SiteWise ：設備のリアルタイム稼働データ（サイクルタイム等）を収集・構造化 Amazon Bedrock , Amazon Bedrock Knowledge Bases ：工程設計書・PLC コーディング規約の参照 Amazon Bedrock AgentCore ：AI エージェントの推論基盤 Amazon Kinesis Video Streams ：工場に設置されたカメラ画像の利用 AWS IoT Greengrass ：工場に設置されたセンサー・カメラをクラウドに接続するために利用 アーキテクチャ 下記の図がデモのアーキテクチャです。エッジ側では IoT SiteWise が設備の稼働データをリアルタイムに収集し、クラウド側では Neptune にナレッジグラフ、DynamoDB に生産管理データを格納しています。 AI エージェント（Amazon Bedrock AgentCore）がこれらのデータソースと Bedrock Knowledge Bases（工程設計書・ PLC コーディング規約）を横断的に参照し、ユーザーの質問に対して根拠のある回答を生成します。 （アーキテクチャ図） このブログから、需要の増加のような外的環境の変化に対して AI エージェントが自律的に生産ラインを最適化する新しい工場の姿に興味を持って頂けますと幸いです。 AWS Summit の現地ではデモも公開しておりますので、ぜひ体験しに来てください。 著者について 松永 充弘 (Mitsuhiro Matsunaga) シニア ソリューションアーキテクト 製造業のお客様を担当するソリューションアーキテクトです。クラウド × データ × AI でお客様のビジネスを支援しています。前職では製造業にて、機器の IoT 化、AI 活用を担当していました。 新澤 雅治 (Masaharu Niizawa) IoT Specialist Solutions Architect 製造業、 IT 企業 を経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。

はじめに SILS/HILS（Software/Hardware-in-the-Loop Simulation）などを用いたECU開発において、dSPACE ControlDeskは欠かせないツールです。計測・キャリブレーション・レイアウト設計など多彩な機能を備える一方で、dSPACE ControlDeskの操作は複雑であり、習得のためには時間を要します。また、自動化する場合はさらにAPIの知識やPythonコーディングが求められます。 本記事では、AWS上に構築したMCP（Model Context Protocol）サーバとAgentic IDE「Kiro」を組み合わせ、ControlDeskの操作を自然言語で実現するアプローチをご紹介します。MCPとは、AIがdSPACE ControlDeskが提供するAPIのような外部のツールやデータソースに動的に接続するためのオープンプロトコルです。 課題：ControlDesk操作の自動化に立ちはだかる壁 ControlDeskはGUIベースの操作が基本ですが、繰り返し作業やプロジェクト横断での設定変更を効率化するにはCLI (Command Line Interface)からアクセス可能なAPIによる自動化が有効です。しかし、実際にAPIを活用するには以下のようなハードルがあります。 ControlDesk APIは多岐にわたり（Status Control、Recording、Platform/Devices操作、Variables Access、Signal Editor、Instrument Script等）、目的のAPIを探すだけでも時間がかかる カスタム計器（Selection BoxやPush Buttonの組み合わせ）にInstrument Scriptを埋め込むような高度な設定は、さらに専門知識が求められる つまり、「やりたいことは明確だが、それを実現するために、どのAPIをどう組み合わせて使えば良いのかを調べるだけで、非常に長い時間を要する」という状況が生まれがちです。 ソリューション：Kiro × MCP Server による自然言語オートメーション 本記事では、上記の課題を解決するために、Agentic IDE「Kiro」とMCPサーバを組み合わせ、自然言語の指示から適切なControlDesk APIを呼び出すPythonコードを自動生成するアプローチを提案します。このアプローチにより、ユーザーはAPIの仕様を調べることなく、対話的にControlDeskの操作を進めることができます。 以下にアーキテクチャと処理フローを示します。 図1：Kiro × MCP Server × ControlDesk のアーキテクチャ概要 コンポーネント 役割 Kiro（Agentic IDE） ユーザーの意図を解釈し、MCPサーバと連携してコードを生成 MCP Server（AWS EC2上） ControlDeskのAPIマニュアル・サンプルコードをナレッジとして保持。チーム共有・常時稼働を目的にクラウド上に配置 Amazon S3 ControlDeskのドキュメントおよびサンプルコードを保持 ControlDesk 生成されたAPIコードにより操作が実行される 処理フロー ユーザーが自然言語で指示を入力（例：「Time Plotterを左上に配置して、スロットル変数を紐づけて」） KiroがMCPサーバに問い合わせ、関連するAPIドキュメントやサンプルコードを取得 取得した情報をもとに、ControlDesk APIを呼び出すPythonコードを生成 生成されたコードをユーザーが確認・実行し、ControlDeskの操作を自動化 図2：Kiro から ControlDesk を自然言語で操作するデモの様子 MCPサーバのナレッジ構築と活用の可能性 MCPサーバの価値は、ControlDeskに関するナレッジを構造化して保持し、AIが適切なAPIコードを生成するための情報源となる点にあります。 ControlDesk APIの探索とナレッジ化 ControlDesk APIはPython（COM経由）で利用でき、付属ドキュメントや公開サンプルコードからその使い方を学ぶことができます。 今回のPoCでは、以下の情報源をMCPサーバのナレッジとして活用しました。 ControlDeskに付属するAPIリファレンス（ヘルプドキュメント） dSPACE社が公開しているサンプルスクリプト 実際のプロジェクトで試行錯誤しながら蓄積した操作手順やコードスニペット 今後、より精度の高いコード生成を実現するためには、以下のような情報源をさらに整理・格納していくことが考えられます。 ControlDesk APIの全カテゴリ（Status Control、Recording、Layout Management等）の体系的なドキュメント dSPACEコミュニティやFAQで公開されているユースケース別のコード例 実プロジェクトで蓄積したベストプラクティスやトラブルシューティング記録 dSPACEドキュメント利用に関する注意事項 dSPACE社のドキュメント利用ガイドラインでは、ドキュメントの内容をAIモデルの学習データとして使用することは許可されていません。本ブログのワークフローを実施する際は、以下のいずれかの条件を満たしてください： Kiroを AWS IAM Identity Center または外部IDプロバイダー経由で利用する （コンテンツがサービス改善に使用されません） または データ共有のopt-out設定を行う （ 手順はこちら ） 詳細は Kiro FAQ: Does Kiro use my content to train any models? をご参照ください。 なお、Kiroにドキュメントを参照させてMCPサーバを構築する（コード生成の参考情報として利用する）といった用途は許容されています。 ナレッジの充実度に応じて、自然言語で「GoOnlineして計測を開始して」と伝えるだけで、裏側で適切なAPIが呼び出されるような体験を実現できる可能性があります。 活用例：レイアウト操作の自然言語化 ControlDeskのレイアウト操作をAPIで自動化するには、計器の種類・名前・配置座標・サイズ・紐づける変数パスなど、多くのパラメータを正確に指定する必要があります。従来はAPIの仕様を理解したうえでPythonコードを記述していました。 # 従来：APIの仕様を理解してコードを記述 cd_instruments = Application.LayoutManagement.Layouts[layout_name].Instruments cd_instruments.Add(instrument_type, instrument_name, x, y, width, height) cd_instrument = cd_instruments[instrument_name] cd_instrument.MainVariable = variable_path MCPサーバにControlDeskのAPI情報が十分に蓄積されていれば、Kiroを通じて自然言語からこうしたコードを生成できるようになります。 「Time Plotterをレイアウトの左上に配置して、スロットル変数を紐づけて」 → Kiro が MCPサーバのナレッジを参照し、API コードを自動生成 # Kiroが自然言語から自動生成するコードのイメージ Application.LayoutManagement.Layouts["MyLayout"].Instruments.Add( "Time Plotter", "ThrottlePlotter", 0, 0, 400, 300 ) plotter = Application.LayoutManagement.Layouts["MyLayout"].Instruments["ThrottlePlotter"] plotter.ActivePlot.ActiveYAxis.Signals.Add() plotter.ActivePlot.ActiveYAxis.Signals.Item(0).MainVariable = \ "Platform()://Model Root/Throttle_act_pos" このように、MCPサーバに蓄積するナレッジの質と量が、自然言語オートメーションの精度を左右する重要な要素となります。 さらなる可能性：計器カスタマイズへの展開 ControlDeskでは、計器にPythonスクリプト（Instrument Script）を埋め込むことで、高度なカスタマイズも可能です。たとえば、 GoOnline （シミュレーションプラットフォームとの接続を確立し、リアルタイムでの変数モニタリングやパラメータ変更を可能にする操作）や GoOffline （接続を切断し、安全にプロジェクト設定を変更できる状態に戻す操作）の切り替え、レコーダーの動的選択といった、ControlDesk固有の制御フローをスクリプト化できます。 こうした設定にはAPIの深い理解が求められますが、MCPサーバの作り込み次第では「レコーダーを動的に切り替えられる計測ボタンを作って」といった自然言語からスクリプトの雛形を生成することも将来的に視野に入ります。 メリットと付加価値 API知識不要で操作可能 自然言語で意図を伝えるだけで適切なコードが生成されるため、新しいメンバーのオンボーディングコストを大幅に削減できます。 設計書・仕様書の同時生成 Kiroはコード生成と合わせて、レイアウト構成や変数マッピングをMarkdown形式の設計書として出力できます。テスト仕様書の作成にも応用可能です。 チーム全体の生産性向上 MCPサーバにナレッジを蓄積・共有することで、個人の暗黙知がチーム全体の資産になります。 対応デバイスの幅広さ ControlDesk APIはVEOS、SCALEXIO、MicroAutoBox II/IIIなど主要なdSPACEプラットフォームに対応しており、MCPサーバ経由でこれらすべてを自然言語で操作できます。 まとめと今後の展望 ControlDeskは計測・キャリブレーション・レイアウト設計・Instrument Scriptなど、ECU開発に必要な機能を豊富に備えた強力なツールです。しかし、その機能の豊富さゆえに使いこなす難度が高く、APIの複雑さが障壁となり、豊富な機能のポテンシャルを引き出せないまま運用されるケースが多く見られました。 Kiro × MCP Serverの組み合わせは、この状況を変える可能性を持っています。自然言語でやりたいことを伝えるだけで、適切なAPIが呼び出される体験を実現できます。 従来手動にて作成していたレイアウトが自然言語で実現可能に ControlDeskの公開ドキュメントやサンプルAPIを活用し、MCPサーバのナレッジとして構造化 カスタム計器やInstrument Scriptのような高度な設定も、自然言語からの生成が視野に 一方で、各機能のAPIをMCPのToolとして最適に定義するには、dSPACE社の豊富な開発経験に基づくノウハウが不可欠です。今後はdSPACE社との協業を通じてToolの最適化を進めるとともに、ControlDeskに限らず他のdSPACEツールへの横展開や、テスト自動化パイプラインとの統合など、生成AI × MCPの可能性はさらに広がっていくと考えています。 著者について 衣笠 昭弘 AWSのシニアソリューションアーキテクトとして、製造業(自動車)のお客様のクラウド活用をご支援しています。2020年にProfessional ServicesのコンサルタントとしてAWSに入社し製造業・電力など様々なエンタープライズのお客様のクラウド基盤構築のご支援に従事し、2025年より現職。  

あなたがグローバルな e コマースプラットフォームを運営していると想像してみてください。北米、ヨーロッパ、アジア太平洋地域に 200 万人のアクティブユーザーが分散しています。今日はブラックフライデー。注文が毎秒 5,000 リクエストの勢いで流れてきています。お客様は、自分がどこにいようと、舞台裏で何が起ころうと、シームレスな体験を期待しています。 グローバル規模でビジネスを運営するということは、予期しない事態に備えなければならないということです。ある AWS リージョンでイベントが発生し、ワークロードが劣化状態で稼働することもあり得るため、データレイヤーはそのときに備えておく必要があります。多くの組織にとって、これが Amazon DynamoDB グローバルテーブル を採用する理由です。 DynamoDB グローバルテーブルは、複数の AWS リージョンとアカウントにまたがるフルマネージドのアクティブ-アクティブレプリケーションを提供します。しかし、マルチリージョンレプリケーションを持っているだけでは話の半分にすぎません。残りの半分は、問題が起きる「前」にインフラが準備できていることを把握しておくことです。 これは DynamoDB グローバルテーブルのベストプラクティスに関するシリーズのパート 1 です。特に明記がない限り、本記事ではデフォルトのレプリケーションモードである マルチリージョン結果整合性 (multi-Region eventual consistency) (MREC) のグローバルテーブルについて議論します。ガイダンスが異なる場合は マルチリージョン強整合性 (multi-Region strong consistency) (MRSC) について明示的に言及します。本記事では準備に焦点を当てます。レプリケーションの仕組み、レジリエンスポスチャの理解、そしてコントロールされたフェイルオーバーと慌てふためく対応を分ける運用上の基盤づくりについて説明します。 パート 2 では、フェイルオーバー戦略と、午前 2 時にアラートが鳴ったときに何をすべきかを取り上げます。 グローバルテーブルのレプリケーションの仕組み 準備について話す前に、まずグローバルテーブルがどのようにデータをレプリケートするかについての共通理解を確立しておきましょう。DynamoDB グローバルテーブルはアクティブ-アクティブアーキテクチャを使用します。すべてのリージョンのすべてのレプリカテーブルが読み取りと書き込みの両方を受け付けることができます。あるリージョンに項目を書き込むと、DynamoDB はその変更を他のすべてのレプリカリージョンにレプリケートします。レプリケーションがどのように機能するかは、使用する整合性モードによって異なります。 MREC レプリケーション デフォルトのマルチリージョン結果整合性 (MREC) モデルでは、書き込みは非同期にレプリケートされます。このモデルにはレジリエンスの計画に直接影響を与えるいくつかの特性があります。第一に、MREC は項目レベルのタイムスタンプに基づく Last-writer-wins (最後の書き込みが勝つ) の競合解決戦略を採用しています。同じ項目が 2 つのリージョンでほぼ同時に更新された場合、最新のタイムスタンプを持つ書き込みが優先されます。 第二に、通常の状況下では、変更は通常 1 秒以内にリージョン間でレプリケートされますが、項目サイズ、書き込み量、レプリカ間の物理的距離によって変動する可能性があります。 第三に、レプリカリージョンからの読み取りは、他のリージョンで行われた書き込みに対して結果整合性を持ちます。eu-west-1 での読み取りは、us-east-1 で発生したばかりの書き込みを即座に反映しない場合があります。このモデルにより各リージョンで低レイテンシのローカル読み書きが可能になりますが、結果整合性モデルはレジリエンス戦略の計画方法、特にデータ損失許容度に直接影響を与えます。 MRSC レプリケーション マルチリージョン強整合性 (MRSC) では、書き込みは同期的にレプリケートされます。書き込み操作が成功レスポンスを返す前に、項目変更は少なくとも 1 つの他のリージョンに同期的にレプリケートされます。 MREC の Last-writer-wins アプローチとは異なり、MRSC での書き込みは任意のリージョンからの最新の書き込みに対して評価され、異なるリージョンから同じ項目への同時書き込みは競合を引き起こす可能性があります。MRSC は任意のアクティブリージョンからの強整合性のある読み取り (ConsistentRead=true を設定) をサポートし、読み取りが常に最新のコミット済み書き込みを反映するという確信を提供します。デフォルトは引き続き結果整合性のある読み取りです。 グローバルテーブルでの RPO と RTO の理解 フェイルオーバー時のレジリエンスポスチャを定義する 2 つのメトリクスがあります。 目標復旧地点 (Recovery Point Objective, RPO) はどれだけのデータ損失を許容できるかを時間ウィンドウで表します。RPO が 1 秒であれば、最大で直近 1 秒間の書き込みの損失を許容できることを意味します。 目標復旧時間 (Recovery Time Objective, RTO) はアプリケーションがどれだけ速く回復しなければならないかを表します。RTO が 60 秒であれば、ユーザーは障害発生から 1 分以内に通常の状態に戻れる必要があることを意味します。 マルチリージョン結果整合性 (MREC) MREC では、書き込みはソースリージョンで受理された後、他のリージョンに非同期でレプリケートされます。それらの書き込みがフェイルオーバー先のリージョンに到達する前に障害が発生した場合、フェイルオーバー後に一部の最近の書き込みが失われる可能性があります。RPO の観点から、MREC はゼロ RPO を提供しません。確認された書き込みが障害発生時にまだ転送中である可能性があるためです。 ReplicationLatency Amazon CloudWatch メトリクスはレプリケーションの健全性を監視するのに役立ちますが、フェイルオーバー時のデータ損失の正確な指標ではなく、方向性のシグナルとして扱うべきです。多くのワークロードにとって、これは許容可能なトレードオフです。 マルチリージョン強整合性 (MRSC) MRSC グローバルテーブルレプリカでの項目変更は、書き込み操作が成功レスポンスを返す前に少なくとも 1 つの他のリージョンに同期的にレプリケートされます。これは MRSC がゼロ RPO を提供することを意味します。フェイルオーバー時にコミット済みの書き込みが失われることはありません。MRSC は 2 つの構成をサポートします。3 つのアクティブリージョン、または 2 つのアクティブリージョンとレプリケーションには参加するが読み取りや書き込みは処理しない witness リージョン、です。 トレードオフはレイテンシです。同期的なクロスリージョンレプリケーションは、すべての書き込みに往復時間を追加します。小さな RPO ウィンドウを許容できるレイテンシ重視のワークロードには、MREC が依然として正しい選択です。ゼロデータ損失が交渉の余地のない要件であるワークロード、つまり金融取引、在庫システム、規制コンプライアンスシナリオには MRSC を推奨します。 MREC を使用するか MRSC を使用するかにかかわらず、RTO は選択するフェイルオーバー戦略に完全に依存します。本シリーズの パート 2 で、3 つの主要なアプローチとその RTO の特性を取り上げます。 モニタリングとオブザーバビリティ 何かが間違っていることを知らなければ、混乱に効果的に対応することはできません。モニタリングは準備の基盤であり、インシデントが発生するずっと前に注意を払う必要があります。 ReplicationLatency ReplicationLatency CloudWatch メトリクスは MREC グローバルテーブルで利用可能で、項目があるリージョンから別のリージョンにレプリケートされる時間 (ミリ秒単位) を追跡します。これはレプリケーションの健全性の主要な指標であり、結果整合性モデルにおける RPO の最良の代理指標です。 ReplicationLatency メトリクスはリージョンペアごとに発行されます。グローバルテーブルが us-east-1、us-west-2、eu-west-1 にレプリカを持つ場合、us-east-1 の CloudWatch には 2 つの別々の ReplicationLatency メトリクスが表示されます。1 つは us-west-2 へのレプリケーション用、もう 1 つは eu-west-1 へのレプリケーション用です。各ペアに対して独立して アラームを設定 してください。レイテンシはリージョン間の物理的距離によって大きく異なるためです。 このメトリクスに対して 2 つのしきい値でアラームを設定することを推奨します。3,000 ms を 5 分以上持続する場合の警告と、5,000 ms を 3 分以上持続する場合のクリティカルアラームです。これらは出発点であり、ワークロードのベースラインに基づいてチューニングすることを推奨します。警告により、状況が緊急になる前にチームが調査する時間を得られます。レプリケーションレイテンシの上昇は必ずしもリージョン障害によって引き起こされるわけではないことに注意してください。キャパシティ不足によるスロットリングの持続もレプリケーションラグを増加させる可能性があるため、リージョンの問題があると結論付ける前に、ReplicationLatency と並行してテーブルのスロットリングメトリクスを調査してください。 リージョン障害中でもレプリカは ACTIVE ステータスを示すことができることに注意してください。レプリカステータスだけでは不十分です。レプリケーションレイテンシのモニタリングが、必要なリアルタイムシグナルを提供します。 このメトリクスは MRSC では利用できません。MRSC グローバルテーブルでは、強整合性のある読み書き API 呼び出しのレイテンシを監視してリージョンの健全性を評価します。これらの操作のレイテンシ上昇やタイムアウトは、潜在的なリージョン障害を示します。 SystemErrors SystemErrors CloudWatch メトリクスは、DynamoDB から HTTP 500 エラーが返されたリクエスト数を追跡します。通常の運用中でも時折システムエラーは発生し得ますが、持続的な増加は劣化の強い指標です。 適切なアラームしきい値はスループットによって異なります。毎秒 100 万リクエストを処理するテーブルは、毎秒 5 リクエストを処理するテーブルよりも自然に多くの一過性のシステムエラーを見るため、絶対的なエラー数だけでは意味がありません。代わりに、 SystemErrors の総リクエストに対する割合でアラームを設定することを推奨します。5 分間で持続的なエラー率が 0.5% を超える場合の警告と、3 分間で 1% を超える場合のクリティカルアラームが妥当な出発点ですが、ワークロードのベースラインに基づいてこれらのしきい値をチューニングすべきです。一過性のシステムエラーは珍しくなく、必ずしもリージョンの問題を示すわけではないため、しきい値は寛容にすべきです。探しているのはエラー上昇の「パターン」であり、 ReplicationLatency の上昇など他のシグナルと組み合わさって、対応すべき劣化の状況を描き出すものです。 MREC では、 ReplicationLatency アラームと組み合わせると、 SystemErrors はリージョンの健全性に対する 2 番目の独立したシグナルを提供します。MRSC では、 SystemErrors と強整合性のある読み書きのレイテンシが主な健全性指標として機能します。 これは、自動フェイルオーバーの決定を駆動する 複合アラーム (composite alarms) を構築する際に特に有用です。これはパート 2 で取り上げるトピックです。 Synthetic canaries 最も予防的なモニタリングのために、クロスリージョンレプリケーションを継続的に検証する synthetic canary をデプロイしましょう。これらの canary は既知の項目をソースリージョンに書き込み、その項目が現れるまでターゲットリージョンをポーリングし、アプリケーションの観点から実際のエンドツーエンドのレプリケーション時間を計測します。次の Python スクリプトは、項目を書き込み、ターゲットリージョンでポーリングし、計測されたラグをカスタム CloudWatch メトリクスとして公開する基本的なレプリケーション canary を示しています。 import time import uuid from datetime import datetime, timezone import boto3 def replication_canary(source_region, target_regions, table_name): source = boto3.resource("dynamodb", region_name=source_region) cloudwatch = boto3.client("cloudwatch", region_name=source_region) canary_id = str(uuid.uuid4()) write_time = datetime.now(timezone.utc) ttl_value = int(write_time.timestamp()) + 86400 # Write to source Region source.Table(table_name).put_item(Item={ "PK": "CANARY", "SK": canary_id, "written_at": write_time.isoformat(), "ttl": ttl_value, }) # Poll each target Region independently pending = {r: boto3.resource("dynamodb", region_name=r) for r in target_regions} results = {} for attempt in range(10): time.sleep(1) for region, client in list(pending.items()): response = client.Table(table_name).get_item( Key={"PK": "CANARY", "SK": canary_id} ) if "Item" in response: lag = (datetime.now(timezone.utc) - write_time).total_seconds() results[region] = lag del pending[region] if not pending: break for region in pending: results[region] = None return results これにより、CloudWatch メトリクスとは独立した、ニアリアルタイムのアプリケーションレベルでのレプリケーションヘルスのビューが得られます。これは、ダッシュボードよりも先に何か問題があることを教えてくれる種類のシグナルです。canary 項目が時間とともに蓄積するのを防ぐため、テーブルで Time to Live (TTL) を有効にし、各 canary 項目に TTL 属性を含めてください。 重要な考慮事項は、モニタリングインフラがどこで実行されるかです。canary、アラーム、フェイルオーバー判断ロジックがすべてプライマリリージョンで実行されている場合、そのリージョンが障害状態のときに利用できなくなります。まさに最も必要なときに動作しないのです。synthetic canary と複合アラームを別のリージョンからデプロイし、障害のあるリージョン自体に依存することなく障害を検出して対応できるようにしましょう。 ワークロードの依存関係をマッピングする DynamoDB はワークロードが依存する唯一のサービスであることはほとんどありません。自信を持ってフェイルオーバーする前に、依存関係の完全なセットを理解する必要があります。コンピュート、ネットワーキング、認証、キャッシング、メッセージング、その他アプリケーションが必要とするあらゆるサービスです。各依存関係はフェイルオーバーリージョンで利用可能で、正しく構成されている必要があります。アプリケーションが到達できなければ、健全な DynamoDB レプリカは役に立ちません。これらの依存関係をフェイルオーバーランブックの一部として文書化し、 GameDay の際に検証してください。 レプリカが健全であることを確認する 別のリージョンにアプリケーションをフェイルオーバーする前に、そのリージョンがトラフィックを受け入れる準備ができていることを確認する必要があります。レプリカテーブルが ACTIVE 状態であることを定期的に確認する習慣をつけましょう。 aws dynamodb describe-table \ --table-name YourGlobalTableName \ --region us-west-2 出力で、 TableStatus が ACTIVE であることと、 Replicas 配列の各エントリで ReplicaStatus: ACTIVE が表示されていることを確認してください。レプリカが CREATING 、 UPDATING 、 REPLICATION_NOT_AUTHORIZED 、または INACCESSIBLE_ENCRYPTION_CREDENTIALS などの異なる状態にある場合、フェイルオーバーターゲットとして機能する準備ができていません。レプリカが非アクティブな状態にある「理由」を理解することが重要です。たとえば、 UPDATING 状態は進行中の設定同期またはスケーリングイベントを示している可能性があり、原因によって対処方法は異なります。 フェイルオーバーリージョンでキャパシティが準備できていることを確認する キャパシティモードと Auto Scaling を掘り下げる前に、すべてのレプリカリージョンで AWS Service Quotas が一貫していることを確認してください。プライマリより低い DynamoDB クォータを持つリージョンは、キャパシティ構成が正しくてもフェイルオーバー時のボトルネックになる可能性があります。予想されるピークイベントの十分前にこれらのクォータを確認して揃えてください。 私たちが目にする最も一般的なギャップの 1 つは、通常の読み取りトラフィックに対してプロビジョニングされたフェイルオーバーリージョンです。これは定常状態でのコスト面の改善として合理的です。しかし、プライマリリージョンが障害になり、そのレプリカがリダイレクトされたトラフィックを突然吸収する必要が生じると、数秒でスロットリングに到達します。 グローバルテーブルでは、すべてのレプリカが通常のレプリケーションの一部としてすでに本番の書き込みトラフィック全体を処理していることを理解することが重要です。懸念は主に読み取りキャパシティに関するものです。アプリケーションがすべての読み取りをフェイルオーバーリージョンに移すなら、そのリージョンはそれに応じてプロビジョニングされている必要があります。 テーブルがオンデマンドキャパシティモードを使用している場合、キャパシティが自動的にスケールするため、より良い状況にあります。しかし、プロビジョニングキャパシティモードを使用している場合は、必要になる前にフェイルオーバーリージョンが本番レベルのトラフィックを処理できることを確認する必要があります。 確認すべき重要なメトリクスは現在プロビジョニングされているものではなく、Auto Scaling の上限が許容するものです。現在のプロビジョニングキャパシティは、最近のトラフィックに基づいて Auto Scaling が落ち着いた状態を反映しており、いつでも変わる可能性があります。フェイルオーバーの準備にとって重要なのは、Auto Scaling が本番トラフィックを吸収するのに十分な高さまでスケール「できる」かどうかです。Auto Scaling 構成を確認してください。 aws dynamodb describe-table-replica-auto-scaling \ --table-name YourGlobalTableName \ --region us-west-2 出力で、フェイルオーバーリージョンの読み取りおよび書き込みキャパシティの MinimumUnits と MaximumUnits を確認してください。 MaximumUnits がプライマリリージョンのピークプロビジョニングキャパシティより低い場合、フェイルオーバー時に Auto Scaling が天井に到達し、スロットリングが発生します。 状況に応じて、これに対処する 2 つのアプローチがあります。 計画されたイベントまたは予想されるリスク期間の場合 、フェイルオーバーリージョンの MinimumUnits を一時的にプライマリリージョンの現在のプロビジョニングキャパシティに合わせて引き上げます。これによりキャパシティが事前にウォームアップされ、急激なトラフィック急増に Auto Scaling が反応するのを数分待つのではなく、フェイルオーバー時に即座に利用可能になります。イベント後に下げ戻すことができます。 継続的な準備の場合 、すべてのレプリカリージョン全体で MaximumUnits が一貫しており、本番の負荷を完全に処理できるほど十分に高いことを確認してください。こうすれば、事前にウォームアップしなくても、Auto Scaling にスケールアップする余地があります。 グローバルテーブルでは、これらの境界を調整するには DynamoDB の Auto Scaling API ( UpdateTable API や AWS Application Auto Scaling API を直接使用するのではなく) を使用してください。 UpdateTable を通じてスループットに行われた更新は Auto Scaling によって上書きされる可能性があります。次のコマンドが推奨アプローチを示しています。 aws dynamodb update-table-replica-auto-scaling \ --table-name YourGlobalTableName \ --replica-updates '[ { "RegionName": "us-west-2", "ReplicaProvisionedReadCapacityAutoScalingUpdate": { "MinimumUnits": 5000, "MaximumUnits": 40000, "AutoScalingDisabled": false, "ScalingPolicyUpdate": { "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0 } } } } ]' グローバルテーブルは Auto Scaling 設定を含む特定の設定をレプリカ間で同期します。これは、非プライマリリージョンの読み取りキャパシティを下げるカスタム Auto Scaling ポリシーを作成していない限り、読み取りキャパシティ設定も同期されることを意味します。キャパシティ戦略を計画する際には、この動作に注意してください。 計画されたイベントの前にオンデマンドモードへの切り替えを検討してください。これによりすべてのレプリカが同一のキャパシティ動作を持つようになり、高ストレスインシデント中にリージョン間で Auto Scaling を管理する必要がなくなります。 障害中はコントロールプレーン操作を避ける これは重要であり、しばしば見落とされます。リージョン障害中は次のことを避けてください。 テーブルに構造的変更を加えない グローバルセカンダリインデックス (Global Secondary Index) を追加または削除しない グローバルテーブルレプリカを追加または削除しない キャパシティモードを変更しない (プロビジョニングとオンデマンドの間の切り替え) テーブルタグや TTL 設定を更新しない これらはレプリカ間の調整を必要とするコントロールプレーン操作です。グローバルテーブルはデフォルトですべてのレプリカ間で設定を同期するため、レプリカの 1 つにアクセスできない場合は設定変更が許可されません。これらはすべてのレプリカが健全である場合にのみ行えます。データプレーン操作 (読み書き) は、健全なリージョンへのフェイルオーバー後に安全であり期待されています。しかし、構造的変更は全クリアまで待つべきです。これが、インシデント中にリソースを作成または変更しようとするのではなく、障害が発生する前にスタンバイインフラストラクチャを完全に構成して準備しておくことがベストプラクティスである理由です。 イベント前チェックリストとランブックを構築する レジリエンスポスチャを強化するには、フェイルオーバー手順を文書化したフェイルオーバーランブックを作成することを推奨します。これにはフェイルオーバーをいつ開始するかについての事前決定したしきい値と基準が含まれます。フェイルオーバーの判断は最終的にビジネス上の判断であり、各お客様の要件とリスク許容度に固有のものです。これらの判断を午前 2 時のインシデント中ではなく事前に行っておくことが、準備されたチームと反応的なチームを分けるものです。 そのランブックの一部として、計画されたイベント、ピークトラフィック期間、または AWS が AWS Health Dashboard を通じて潜在的な障害を伝える際にレビューする、イベント前チェックリストを維持してください。 影響を受けるリージョンにレプリカを持つすべてのグローバルテーブルを特定する 代替リージョンのレプリカステータス ( ACTIVE 状態) を確認する ReplicationLatency メトリクスを確認してレプリケーションが最新であることを確認する ターゲットリージョンでプロビジョニングキャパシティまたはオンデマンドモードが適切であることを確認する レプリカリージョン間でサービスクォータが一貫していることを確認する DynamoDB テーブルの CloudWatch アラームをレビューする 現在のアプリケーションエンドポイント構成を文書化する 運用チームが利用可能で、フェイルオーバーランブックに精通していることを確認する ステークホルダーとのコミュニケーションチャネルを確立する これはオーバーヘッドのように思えるかもしれませんが、航空会社のパイロットがどれほど経験豊富であっても、すべての離陸前にプリフライトチェックリストを実行することを考えてください。チェックリストはパイロットが飛行方法を知らないからではなく、ステップが省略されるのは高ストレス状況で起こるからこそ存在します。同じ原則がここに適用されます。実際のインシデント中に、このリストがすでに完了していることが、5 分のフェイルオーバーと 45 分の慌ただしい対応の違いになり得ます。 よくある準備の落とし穴 最善の意図があっても、準備中にチームを油断させる罠があります。 負荷時のレプリケーションラグスパイク 高い書き込みボリューム時 (フラッシュセールやバッチインポートを考えてください) には、レプリケーションレイテンシが通常のサブセカンドの範囲を超えてスパイクする可能性があります。これらのスパイク中に障害が発生すると、RPO ウィンドウは予想より大きくなります。これはレジリエンス戦略が壊れていることを意味するものではありませんが、それを認識する必要があることを意味します。ピークトラフィック期間中に ReplicationLatency CloudWatch メトリクスを綿密に監視し、これらのスパイクを RPO 計算に織り込んでください。負荷に関係なくビジネスがハードなゼロ RPO 保証を必要とする場合、DynamoDB マルチリージョン強整合性 (MRSC) が答えです。 キャパシティプランニングの失敗 フェイルオーバーリージョンが通常の読み取りトラフィック向けにプロビジョニングされていて、突然本番の読み取りトラフィック全体を処理しなければならなくなった場合、スロットリングに到達します。Auto Scaling は役立ちますが、反応するのに数分かかり、突然のフェイルオーバーサージには遅すぎます。レプリカテーブルにオンデマンドキャパシティモードを使用するか、すべてのリージョンのプロビジョニングキャパシティが常に本番の負荷を完全に処理できることを確認してください。フェイルオーバーリージョンで高いキャパシティを維持するには実際のコストがかかり、適切なバランスはワークロードとリスク許容度に依存します。レプリカテーブルにオンデマンドキャパシティモードの使用を検討してください。これは過剰プロビジョニングを維持する必要なく自動的にスケールします。プロビジョニングモードを使用する場合、定常状態で MinimumUnits が低く設定されていても、Auto Scaling の MaximumUnits が本番の負荷を完全に処理できることを確認してください。重要なのは、フェイルオーバーリージョンが必要なときに需要に応えてスケールできることであり、常にフルキャパシティで稼働していることではありません。 フェイルオーバーをテストしない フェイルオーバーは火災訓練のようなものです。練習したことがなければ、本番でスムーズに実行できません。リージョン障害をシミュレートしてフェイルオーバーランブックを練習する GameDay を定期的に実施してください。 AWS Fault Injection Service (FIS) を使用して障害を注入し、レジリエンスポスチャを継続的にテストできます。実際のインシデントが強制する前に、自動化、ドキュメント、チームの準備のギャップを特定してください。私たちは、GameDay 中にフェイルオーバーリージョンのセキュリティグループがアプリケーションの DynamoDB への接続をブロックしていることを発見したお客様と仕事をしたことがあります。何ヶ月も気づかれなかった構成のドリフトです。土曜日の夜の障害中にではなく、火曜日の午後にそれを見つけるほうがよいでしょう。 より一般的に、アドバイスはフェイルオーバー戦略は定期的に実行される必要があるということです。これらを確認するだけでは不十分です。フェイルオーバーは何らかの定期的な間隔で実行する必要があります。 まとめ DynamoDB グローバルテーブルでリージョン障害に備えることは、複数のリージョンにレプリカを持つことだけではありません。レプリケーションモデルを理解し、RPO と RTO の要件を知り、レプリケーションの健全性を継続的に監視し、重要なときに決断的に行動するための運用上の筋力を構築することについてです。 単一リージョン障害後でもデータは引き続き利用可能です。それがグローバルテーブルの約束です。しかし、復旧の速度とスムーズさは、今日行う準備に完全に依存します。 このシリーズの パート 2 では、フェイルオーバー戦略そのものを取り上げます。Amazon Route 53 を使った DNS ベースのフェイルオーバー、アプリケーションレベルのサーキットブレーカー、Amazon Route 53 Application Recovery Controller (ARC) です。各アプローチのトレードオフ、実装の詳細、運用上の考慮事項を順を追って説明します。 さらに学ぶには DynamoDB グローバルテーブルを今日運用しているなら、まず CloudWatch で ReplicationLatency メトリクスを確認することから始めてください。アラームを設定していない場合、今すぐ作成してください。次に、フェイルオーバーリージョンで describe-table-replica-auto-scaling を実行し、 MaximumUnits をプライマリリージョンのピークトラフィックと比較してください。ギャップがある場合、次のピークイベント前に解消してください。 フェイルオーバーランブックがまだない場合、本記事のチェックリストを出発点として使用してください。ワークロードでフェイルオーバーをトリガーするしきい値を書き留め、チームにレビューしてもらい、テストするための GameDay をスケジュールしてください。 AWS Fault Injection Service は制御された方法でリージョン障害をシミュレートするのに役立ちます。 グローバルテーブルの構成と設計の詳細については、 DynamoDB グローバルテーブルのベストプラクティス と AWS Well-Architected フレームワークの 信頼性の柱 (Reliability Pillar) を参照してください。ワークロードでゼロ RPO が要件である場合、 マルチリージョン強整合性 (multi-Region strong consistency) (MRSC) を検討してください。 パート 2 では、3 つのフェイルオーバー戦略でこの準備を実践します。 本記事は 2026 年 05 月 20 日 に公開された “Best practices for Amazon DynamoDB Global Tables – Part 1: Operational readiness” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/best-practices-for-amazon-dynamodb-global-tables-part-1-operational-readiness/ 著者について Lee Hannigan Lee はアイルランドを拠点とする AWS DynamoDB チームのシニアデータベースエンジニアです。データモデリング、分散システム、開発者ツールにわたる 7 年間の経験を持ち、スケールで構築するお客様にとって DynamoDB をよりアクセスしやすいものにすることに焦点を当てています。 Shiladitya Mandal Shiladitya は AWS DynamoDB チームのソフトウェア開発マネージャーで、Data Movement グループを率いています。Amazon に 10 年以上在籍し、分散システムの構築とスケーリングに従事してきました。シアトルを拠点とする Shiladitya は、グローバルテーブルやその他のクロスリージョン機能を支える DynamoDB のレプリケーションおよびデータ移動機能に焦点を当てています。

本記事は、2026 年 4 月 21 日に Networking & Content Delivery で公開された Automated network incident response with AWS DevOps Agent を翻訳したものです。翻訳は Technical Account Manager の由原が担当しました。 ※AWS DevOps Agent が日本語をサポートしていることに伴い、 aws-samples GitHub リポジトリ のコードを用いた再現検証を行った結果をもとに 一部内容を変更しています。 オンコールのエンジニアが深夜 2 時に呼び出しを受けたことを想像してください。 呼び出しの内容は Workload Account 内の決済サービスが、Shared Services Account 内の共有データベースに到達できなくなったというものでした。 Amazon CloudWatch アラームは 8 分前に通知されていました。オンコールエンジニアはまず、原因の切り分けのために2 つのアカウントにまたがるルートテーブル、 Amazon Virtual Private Cloud (Amazon VPC) のアタッチメントの状態、両側の セキュリティグループ ルール、 ネットワーク ACL 、そして DNS における名前解決ログを確認していきます。 確認から1 時間後、根本原因は、その日の夕方に行われたネットワーク移行の際に、 AWS Transit Gateway のルートテーブルの関連付けが誤ったルートテーブルに切り替えられていたことだと原因を特定しました。この原因により、他のすべてのスポークは問題なく動作し続けている一方で、2 つの VPC 間のトラフィックだけが気付かれないまま破棄された結果決済サービスと共有データベース間の通信に失敗するようになったというものです。 AWS DevOps Agent を用いることで、調査プロセス全体を自動化することができ、このような問題を解決することが可能になります。DevOps Agent は Webhook を介して CloudWatch アラートを受信することができ、メトリクス、ログ、ネットワークフローデータ、API 変更履歴の相関分析を開始することができます。その後、DevOps Agent は即座に実行可能な修正策とともに根本原因分析を提供し、手動で相関分析に費やしていた 1 時間を、自動化された分析によって数分に短縮することが可能です。 この記事では、CloudWatch モニタリングを DevOps Agent と統合して、ネットワーク障害に対するインシデント対応を自動化する方法を紹介します。 この記事では、一般的な 4 つのシナリオとして、セキュリティグループの設定ミス、NAT Gateway のルーティング問題、VPC エンドポイントポリシーの制限、インターフェイスエンドポイントのサブネット問題を取り上げていきます。ご自身のアカウントにデプロイして手順を実施できる CloudFormation テンプレートを用いて、各シナリオで DevOps Agent がどのように自動的に調査を行い、人による承認を伴う修復プランを生成するかを紹介します。さらに、複数アカウントにまたがる複雑なシナリオとして、Transit Gateway のルートテーブルの設定ミスによりアカウント間の VPC 通信がブロックされるケースを取り上げ、DevOps Agent がエンタープライズ環境にもスケールできることを紹介します。 シミュレートされたワークロードアプリケーションのフルスタックは aws-samples GitHub リポジトリ で入手可能です。 紹介用にシミュレートされたワークロードの概要 DevOps Agent の自動インシデントレスポンス機能を紹介するため、シミュレーションされたワークロードを使用します。このワークロードは、Application Load Balancer (ALB) の背後に Amazon Elastic Compute Cloud (Amazon EC2) 上で動作する Node.js サービスが配置されています。このアプリケーションは、ループでヘルスチェックを実行し、ステータスダッシュボードに結果を表示します。 このアプリケーションは、シンプルさと分かりやすさのため 4 種類のリソースへの接続の確認を行うようになっています。 Amazon RDS インスタンスへのデータベース接続性 (5 秒ごと)。 NAT Gateway 経由でのアウトバウンドインターネット到達性 (15 秒ごと)。 VPC ゲートウェイエンドポイント経由での Amazon Simple Storage Service (Amazon S3) バケットへのアクセス (10 秒ごと)。 インターフェイス VPC エンドポイント経由での Amazon Bedrock へのアクセス (60 秒ごと)。 チェックが失敗すると、アプリケーションは Amazon CloudWatch カスタムメトリクスを発行し、アラームをトリガーするようになっています。スタック全体は、単一の AWS CloudFormation テンプレートからデプロイすることが可能です。図 1 は、シミュレートされたワークロードのアーキテクチャ図を示しています。 図 1: ALB、プライベートサブネット内の EC2 インスタンス、RDS、S3 ゲートウェイエンドポイント、インターフェイス VPC エンドポイント、NAT ゲートウェイ、およびアラームパイプラインで構成される、シミュレートされたワークロードのアーキテクチャ シミュレーションされたワークロードと DevOps Agent でできることを理解したところで、環境のセットアップとシナリオの実行手順を見ていきましょう。 AWS CloudFormation を使用したシミュレーションワークロードのデプロイ GitHub リポジトリ から CloudFormation テンプレートをダウンロードし、 us-east-1 リージョンで AWS CloudFormation コンソール を開きます。 スタックの作成 を選択し、 新しいリソースを使用 (標準) を選択。 テンプレートファイルのアップロード を選択し、ダウンロードしたファイルをアップロードして 次へ を選択。 スタック名を入力し、IAM に関するチェックボックスに同意し、 送信 を選択。 CloudFormation のデプロイが完了したら、CloudFormation コンソールの Outputs タブに移動してください。そこで、シミュレーションされたワークロードアプリケーションのステータスページにアクセスするためのリンクを確認できます。ステータスページでは、アプリケーションが正常に動作していることが表示され、緑色の 「Connected」 ボックスによってすべてのチェックが成功していることが確認できます。 図 2: シミュレートされたワークロードアプリケーションのステータスページ シミュレーションワークロードアプリケーションが実行されたら、AWS DevOps Agent をセットアップします。DevOps Agent Space を作成し、Webhook 統合を設定して、接続性の確認を行います。セットアップが完了したら、設定変更によってアプリケーションの一部に障害が発生する 4 つのネットワーキングシナリオを確認し、DevOps Agent がそれらを自動的に診断する様子を見ていきます。 AWS DevOps Agent のセットアップ DevOps Agent Space を作成。 DevOps Agent Webhook を設定。 Webhook を作成し CSV ファイルをダウンロードした後、AWS コンソール (us-east-1 リージョン) の AWS Secrets Manager に移動し、シークレット devops-agent-sample-app-webhook-credentials を見つけて、CSV ファイルの Webhook URL とシークレットで 2 つの値を更新。 次に進む前に、Webhook をテストして連携が機能していることを確認。 AWS コンソールで Lambda を開き、関数 devops-agent-sample-app-DevOpsAgent-Webhook を見つけて、 Test タブを選択。 TestAlarm という名前の新しいテストイベントを、以下の JSON で作成。 {   "Records": [     {       "Sns": {         "Message": "{\"AlarmName\":\"TEST-webhook-verification\",\"AlarmDescription\":\"[[TEST]] This is a webhook integration test - not a real incident. No investigation needed.\",\"NewStateValue\":\"ALARM\",\"NewStateReason\":\"[[TEST]] Manual test to verify webhook connectivity from Lambda to DevOps Agent. Safe to ignore.\",\"Region\":\"us-east-1\"}"       }     }   ] } Save をクリックし、次に Test をクリックします。以下が返されることを確認。 {   "statusCode": 200,   "body": "{\"message\": \"DevOps Agent investigation triggered\", \"alarmName\": \"TEST-webhook-verification\", \"webhookStatus\": 200}" } DevOps Agent Web アプリで、 CloudWatch Alarm: TEST-webhook-verification という名前のテスト調査が Incident タブに表示されることを確認。 次の図 3 は、この特定のテスト出力が DevOps Agent Web App でどのように表示されるかを示しています。 図 3: 手動でトリガーされた DevOps エージェントの実行結果。Webhook 連携が機能していることを確認しています アラームパイプラインの仕組み：障害発生から調査まで すべての障害は、DevOps Agent まで同じ経路をたどるようにしています。アプリケーションは Amazon CloudWatch にカスタムメトリクスを発行し、CloudWatch アラームはそのメトリクスを評価、ALARM 状態に遷移します。アラームは Amazon SNS トピックに通知されます。Amazon SNS は AWS Lambda 関数を呼び出し、この関数は AWS Secrets Manager から Webhook の認証情報を読み取り、インシデントのペイロードを構築し、HMAC SHA-256 で署名した上で DevOps Agent の Webhook に POST します。DevOps Agent は署名を検証し、調査を開始します。このパイプラインは図 4 に示されています。 図 4: アラームパイプライン 図 5 は、シミュレートされたワークロードアプリケーションを監視するために構成された 4 つの CloudWatch アラームを示しています。 図 5: CloudWatch アラーム Amazon SNS を Amazon CloudWatch と AWS Lambda の間に配置しているのには、3 つの理由があります。 まず、Lambda がスロットリングされた場合に配信を再試行できること (デッドレターキューのサポートあり)、次に、アラームに手を加えずに追加のサブスクライバー (メール、チャットツール、インシデント管理システム) にファンアウトできること、そして、クロスアカウントでの発行をサポートしているため、複数アカウントからのアラームを単一の運用パイプラインに集約できることです。 シナリオ 1: セキュリティグループルールの削除によりデータベースがダウン データベースのセキュリティグループ ( devops-agent-sample-app-DB-SG ) は、アプリケーションのセキュリティグループ ( devops-agent-sample-app-App-SG ) からの MySQL トラフィック (ポート 3306) のインバウンド通信を許可しています。次の図 6 は、このインバウンドルールが削除される様子を示しています。 図 6: セキュリティグループのインバウンドルールが削除される様子 インバウンドルールを削除すると、アプリケーションは数秒以内にデータベースへの接続を失います。セキュリティグループは、どのルールにも一致しないパケットを何も通知せずに破棄するため、アプリケーションの接続試行には応答がなく、タイムアウトします (ステータスダッシュボードに ETIMEDOUT が表示されます)。他の 3 つのチェック (外部接続、S3、Bedrock) はポート 3306 を使用しないため、緑色のままです。 図 7: シミュレーションされたワークロードのアプリケーションステータスページ DevOps Agent は DatabaseConnectionFailures アラームを受信し、調査を行います: RDS インスタンスの正常性を確認 – データベースは利用可能だが、接続数がゼロであることを報告していることを確認。 CloudTrail ログを検索 – RevokeSecurityGroupIngress API コールを発見し、誰がいつ実行したか (アラームが発生する 1 分 30 秒前) を特定。 リソースの関係性をマッピング – トポロジーを使用して、EC2 から RDS への接続依存関係を特定。 根本原因を特定 – データベースセキュリティグループでポート 3306 上のアプリケーションセキュリティグループからのトラフィックを許可していたインバウンドルールが削除されており、データベース自体は正常な状態を維持していたものの、すべての MySQL 接続が即座にブロックされていたことが判明。 図 8 と図 9 に、調査のタイムラインと根本原因のタブを示しています。根本原因を確認した後、問題を解決する方法を確認するための対応計画を生成できます。図 10 は、セキュリティグループを修正するために必要な手順 (AWS CLI コマンド) を記載した対応計画を示しています。 図 8: DevOps Agent の調査タイムライン 図 9: DevOps Agent による根本原因分析 図 10: DevOps Agent から提示された影響緩和策 修正が適用されると、シミュレートされたワークロードアプリケーションのページでは、データベース接続のステータスが緑色の Connected 状態で表示されます。 シナリオ 2: NAT ゲートウェイルートが削除され、アウトバウンドインターネット接続が失われる プライベートルートテーブル ( devops-agent-sample-app-Private-RT ) には、VPC 外へのすべてのトラフィックを NAT Gateway に送信するデフォルトルートがあります。次の図 11 は、ルートが削除される様子を示しています。 図 11: プライベートルートテーブルからデフォルトルートを削除 誰かがこのルートを削除した場合、アプリケーションはパブリックインターネットに到達できなくなります。本環境では、データベース、Amazon S3 、 Amazon Bedrock への疎通性は、パブリックインターネットへの接続性に依存しない設計となっているため、赤く表示されるのは外部接続チェックのみです。 図 12: シミュレートされたワークロードアプリケーションのステータスページ DevOps Agent は ExternalConnectivityFailures アラームを受信し、調査を行います: プライベートルートテーブルを確認 – NAT Gateway を指すデフォルトルート (0.0.0.0/0) が欠落していることを特定。 NAT Gateway の正常性を確認 – NAT Gateway 自体が正常であり、キャパシティの問題やエラーがないことを検証。 CloudTrail ログを検索 – DeleteRoute API コールを見つけ、誰がいつ実行したかを特定。 リソース関係のマッピング – トポロジーを使用して、EC2 から NAT Gateway への依存関係を特定。 根本原因を特定 – プライベートルートテーブルからデフォルトルートが削除されており、EC2 インスタンスがインターネット宛てのトラフィックのルーティングパスを持たない状態になっている。 図 13 と図 14 に、調査のタイムラインと根本原因のタブを示します。根本原因を確認した後、対応策を生成して問題の解決方法を確認できます。図 15 は、NAT ゲートウェイルートを復元するために必要な手順（ AWS CLI コマンド）を詳細に示した対応策です。 図 13: DevOps Agent による調査のタイムライン 図 14: DevOps Agent の根本原因 図 15: DevOps Agent による移行計画 修正が適用されると、シミュレートされたワークロードアプリケーションのページでは、外部接続のステータスが緑色の Reachable 状態で表示されます。 シナリオ 3: VPC エンドポイントポリシーによる S3 バケットアクセスの制限 S3 VPC ゲートウェイエンドポイント ( devops-agent-sample-app-S3-Endpoint ) には、5 つすべてのアプリケーションバケットへのアクセスを許可するポリシーが設定されています。次の図 16 は、VPC エンドポイントポリシーの変更内容を示しています。 図 16: VPC エンドポイントポリシーの変更 誰かがこのポリシーを編集して 5 つのバケットのうち 3 つだけを許可するように変更すると、他の 2 つは AccessDenied を返し始めます。これは多くの人を最も混乱させるシナリオです。なぜなら、 AWS Identity and Access Management (IAM) ポリシーは依然として 5 つすべてへのアクセスを許可しているからです。Gateway Endpoint を経由する Amazon S3 トラフィックでは、3 つのポリシー層すべてで許可されている必要があります。3 つのポリシー層とは IAM、バケットポリシー、そしてエンドポイントポリシーです。これらのいずれかの層がリクエストを拒否すると、Access Denied (HTTP 403 Forbidden) エラーが返されます。 それ以外のすべての項目は引き続き動作します: データベースが機能します (VPC ローカルルートで接続可能)。 Amazon Bedrock が機能します (インターフェイスエンドポイントが ENI をサブネット内に直接配置)。 インターネットへのアウトバウンド接続が機能します (NAT ゲートウェイのルートが維持されている)。 S3 バケットのアクセスチェックのみが赤くなります。 図 17: シミュレートされたワークロードアプリケーションのステータスページ DevOps Agent は S3AccessFailures アラームを受信し、調査を行います。 ポリシーレイヤーを比較 – エンドポイントポリシーを、IAM アクセス許可およびアプリがアクセスしようとしているバケットと照合して検査を実行。 ブロックしているレイヤーを特定 – エンドポイントポリシーがアクセスを制限していると判断。 CloudTrail ログを検索 – ModifyVpcEndpoint API 呼び出しを見つけ、ポリシーを変更した人物と時刻を特定。 リソースの関係をマッピング – トポロジを使用して、EC2 と S3 ゲートウェイエンドポイント間の依存関係を特定。 根本原因を特定 – VPC エンドポイントポリシーが、アプリケーションの 5 つのバケットのうち 3 つのみへのアクセスを許可するように変更されており、残り 2 つのバケットへのアクセスがブロックされていたことを特定。 図 18 と図 19 には、調査タイムラインと根本原因のタブが表示されています。根本原因を確認した後、問題を解決する方法を確認するための修復プランを生成できます。図 20 には、5 つの S3 バケットすべてへのアクセスを復元するために必要な手順 (AWS CLI コマンド) を詳述した修復プランが示されています。 図 18: DevOps Agent の調査タイムライン 図 19: DevOps Agent が特定した根本原因 図 20: DevOps Agent の移行計画 修正が適用されると、シミュレーションされたワークロードアプリケーションページには、S3 Bucket Access のステータスが緑色の All Accessible 状態として表示されます。 シナリオ 4: Bedrock インターフェイスエンドポイントからサブネットを削除し、AI 機能が動作しなくなる Bedrock Runtime インターフェイスエンドポイント ( devops-agent-sample-app-Bedrock-Endpoint ) は、2 つのプライベートサブネットに ENI を作成しています。プライベート DNS は、 bedrock-runtime.us-east-1.amazonaws.com でそれらの ENI の IP アドレスを解決します。次の図 21 は、サブネット関連付けの削除を示しています。 図 21: インターフェイス VPC エンドポイントに関連付けられたサブネットの変更 2 つのサブネットの関連付けを両方とも削除すると、ENI は削除されます。エンドポイント自体は引き続き存在し、プライベート DNS もホスト名をエンドポイントに解決し続けますが、トラフィックを処理するものが何もなくなります。このシナリオは手動で発見するのが特に難しいもので、リクエストが応答なしでタイムアウトしているにもかかわらず、コンソール上ではエンドポイントが「利用可能 (Available)」と表示されたままになるからです。 ここで 2 種類のエンドポイントタイプの違いについて触れておきます。VPC ゲートウェイエンドポイント (Amazon S3、Amazon DynamoDB) はルートテーブルのエントリとエンドポイントポリシーを介して動作するため、そこで設定ミスがあると「Access Denied (HTTP 403 Forbidden)」エラーを返します。インターフェイス VPC エンドポイント (Amazon Bedrock やその他多くの AWS サービス) は、サブネット内にある、独自のセキュリティグループを持つ ENI を介して動作するため、それらの ENI が削除されると、代わりに接続タイムアウトが発生します。しかし、データベースは引き続き動作し (VPC ローカルルート)、Amazon S3 も引き続き動作し (VPC ゲートウェイエンドポイントには独自のルートテーブルエントリがある)、アウトバウンドのインターネット接続も引き続き動作します (NAT ゲートウェイのルートは維持されている)。赤く表示されるのは、Bedrock AI のチェックだけです。 図 22: シミュレートされたワークロードのアプリケーションステータスページ DevOps Agent は BedrockAccessFailures アラームを受信し、調査を開始します： エンドポイント設定を確認 – インターフェイス VPC エンドポイントにサブネットの関連付けがゼロであることを検出。 CloudTrail ログを検索 – ModifyVpcEndpoint API コールを検出し、誰がいつサブネットの関連付けを削除したかを特定。 リソースの関係をマッピング – トポロジーを使用して、EC2 から Bedrock インターフェイス VPC エンドポイントへの依存関係を特定。 根本原因を特定 – Bedrock Runtime インターフェイス VPC エンドポイントから両方のサブネット関連付けが削除されたため、トラフィックを処理する ENI が削除された一方で、エンドポイント自体は「Available」状態のまま。 図 23 と図 24 は調査タイムラインと根本原因のタブを表示しています。根本原因を確認した後、問題を解決する方法を確認するために緩和策を生成できます。図 25 は、Bedrock Runtime Interface VPC Endpoint を復元するために必要な手順 (AWS CLI コマンド) を詳述した緩和策を示しています。 図 23: DevOps Agent の調査タイムライン 図 24: DevOps Agent が特定した根本原因 図 25: DevOps Agent の移行計画 修正が適用されると、シミュレートされたワークロードアプリケーションのページで、Bedrock AI のステータスが緑色の Connected 状態として表示されます。 応用編: 複雑なネットワークシナリオ 本投稿の 4 つのシナリオではネットワーキングの基礎的な概念を扱っていますが、実際の本番環境はより複雑です。冒頭のシナリオを思い出してください。ネットワーク移行中に AWS Transit Gateway のルートテーブルの関連付けが誤ったテーブルに切り替えられたことで、Workload Account の決済サービスが Shared Services Account の共有データベースに到達できなくなり、2 つの VPC 間のすべてのトラフィックが遮断されました。以下の図はその構成を示しています。 図 26: DevOps Agent マルチアカウント構成図 マルチアカウントアクセスを設定すると、DevOps Agent は複数のリージョンとアカウントにまたがる運用データを取得でき、前述の 4 つのシンプルなケースと同じ方法で問題を調査できます。両方のアカウントにまたがる Transit Gateway のトポロジーをマッピングし、関連付けと伝播状態についてルートテーブルをチェックし、どの関連付けが誤ったテーブルを指しているかを特定します。対処プランでは、どのアタッチメントで、どのルートテーブルを再関連付けすべきかを正確に示します。 図 27 は、両アカウントにおける Transit Gateway ルートテーブルの関連付けが誤っていることを特定した根本原因分析を示しています。図 28 は、アタッチメントに正しいルートテーブルを再関連付けするために必要な手順 (AWS CLI コマンド) を詳述した修正計画を示しています。 図 27: DevOps Agent が特定した根本原因 図 28: DevOps Agent の移行プラン その他の考慮事項 本番環境では、1 つのインフラストラクチャ変更で複数のアラームが同時に発報することがあります。例えば、NAT Gateway のルートを削除すると、それらのサービスもアウトバウンドアクセスに依存している場合、外部接続、Amazon S3、Amazon Bedrock のアラームが同時にトリガーされる可能性があります。AWS Lambda 関数に相関ロジックを追加する (例えば、 Amazon DynamoDB に 60 秒のウィンドウでアラームをバッファリングし、アプリケーション単位でグループ化する) ことで、重複した調査が積み重なることを防げます。 この構成における Amazon SNS トピックにはサブスクライバーが 1 つ (Webhook Lambda 関数) ありますが、アラーム定義を変更することなく、メール、 Amazon SQS 、または HTTP サブスクライバーを追加できます。既に CloudWatch アラームと SNS トピックを使用して監視やアラートを運用している場合、Webhook Lambda をそのトピックの追加サブスクライバーとして登録することで、既存のツールを妨げることなく DevOps Agent で状況を把握できるようになります。マルチアカウント環境では、他のアカウントにある Amazon CloudWatch アラームから集約用の Amazon SNS トピックに直接パブリッシュすることで、DevOps Agent への単一のパイプラインを構築できます。 ここで改めて強調しておきたいのは、DevOps Agent は緩和計画の案を作成しますが、AWS 環境に対して自動的に変更を加えることはありません。修復手順の実行には、引き続き人間による操作が必要です。 セットアップ時に接続したサードパーティツールおよびデータソースは、調査時にも適用されます: テレメトリソース を接続すると、DevOps Agent は根本原因分析の一環としてメトリクスやトレースを取得可能に。 CI/CD パイプライン を接続すると、最近のデプロイメントと障害発生のタイムラインを関連付けることが可能に。 MCP サーバー を設定することで、内部 API、ランブックデータベース、または任意のカスタムデータソースを Model Context Protocol 経由で利用可能に。DevOps Agent は、調査中にそのデータが関連する場合にこれらのツールを呼び出します。 クリーンアップ すべてのリソースを削除するには、 スタックの削除 に従ってください。 スタックを削除すると、VPC、サブネット、ルートテーブル、セキュリティグループ、エンドポイント、EC2 インスタンス、RDS、ALB、SNS トピック、Lambda 関数、IAM ロールを含むすべてのリソースが削除されます。 まとめ 本投稿では、AWS DevOps Agent が障害を自動的に調査し、修復計画を生成する 4 つのネットワーキングシナリオをご紹介しました。 これにより、手動でのログ相関作業に何時間もかけることなく、数分以内に明確で実行可能な根本原因分析とすぐに実行できる修正策をチームに提供できます。各シナリオでは異なるトラブルシューティングパターンを示しているため、同じアプローチを皆様の環境にも適用できます。 DevOps Agent が VPC Flow Logs と CloudTrail の API 変更を関連付けて削除されたセキュリティグループルールを見つけ、ルートテーブル設定をマッピングして不足している NAT Gateway ルートを特定し、複数層のポリシーを比較して S3 Gateway Endpoint の制限を切り分け、エンドポイントの利用可否の状態を識別して Interface Endpoint のサブネット削除を検出する様子をご覧いただきました。これらの基本的なシナリオにとどまらず、DevOps Agent はマルチアカウントアクセス、サードパーティのオブザーバビリティ統合、カスタム MCP サーバーを備えた複雑な環境にも対応できます。 AWS DevOps Agent の開始方法 ガイドに従って、今すぐインシデント対応の自動化を始めましょう。 著者について Salman Ahmed Salman は AWS のシニアテクニカルアカウントマネージャーです。AWS ソリューションの設計、実装、サポートを通じてお客様を導くことを専門としています。ネットワーキングの専門知識と新しい技術を探求する意欲を組み合わせて、組織のクラウドジャーニーを成功へと導いています。仕事以外では、写真撮影、旅行、お気に入りのスポーツチームの観戦を楽しんでいます。 Ankush Goyal Ankush は AWS エンタープライズサポートのシニアテクニカルアカウントマネージャーであり、旅行およびホスピタリティ業界のお客様がクラウドインフラストラクチャを最適化するお手伝いを専門としています。20 年以上の IT 経験を持ち、AWS ネットワーキングサービスを活用して運用効率とクラウド導入を促進することに注力しています。Ankush は、インパクトのあるソリューションを提供し、お客様がクラウド運用を効率化できるよう支援することに情熱を注いでいます。

本記事は 2026 年 5 月 12 日に公開された Ankit Sharma による “ Specs just got faster (and smarter) ” を翻訳したものです。 仕様駆動開発を導入したとき、Spec フローは最初こそ少し時間がかかるかもしれないが、最終的にはより高品質な実装をもたらすと考えていました。しかし時間が経つにつれ、「構造と品質は遅さを意味する」という前提自体を問い直すようになりました。 たとえば、10 個のタスクを持つ Feature Spec があるとします。そのうち 6 つは独立しています。異なるエンドポイント、異なるファイル、共有状態なし。それでも Kiro は順番に 1 つずつ実行します。あるいは、スコープ・制約・エッジケースをすでに明確に把握している機能であれば、現在のステップごとの承認フローは問題の規模に対してプロセスが多すぎると感じることもあります。逆のケースも起こります。一見シンプルに見える機能のプロンプトに、多くの未記述の前提や曖昧さが含まれており、実装を間違った方向に導いてしまうことがあります。事前の小さな確認が、実装時間（とトークン！）を大幅に節約できます。本日、Kiro IDE にこれらの問題を解決する改善を導入します。Spec フローをより速く開始し、より速く実装し、最初から正しい解決策を得られるようになります。必要なところではスピードを、重要なところでは深さを得られるようになりました。 タスクの並列実行 Spec で「Run all Tasks」をクリックすると、Kiro はタスクリストを分析し、同時に実行できるタスクを特定するようになりました。タスクリストの多くは真に逐次的ではありません。依存関係があります。タスク 2 とタスク 3 がどちらもタスク 1 に依存しているとしても、互いには依存していないことがあります。順番に実行するのは時間の無駄です。Kiro はタスクリストから依存グラフを構築し、同じファイルに書き込むタスク、以前のタスクのコードをテストするタスク、真に独立しているタスクを識別します。同じファイルを扱うタスクは並列実行されません。セットアップやインフラ作業が最初に実行されます。テストはそれが検証するコードの後に実行されます。それ以外はすべて同時に実行され、同時実行されるウェーブ (wave) にグループ化されます。各タスクは独立したコンテキストで実行されるため、タスク間で状態が漏洩することはありません。タスクが失敗しても、他のタスクは実行を続けます。どれが成功し、どれが注意を要するかを確認できます。以前の作業に依存するタスクは引き続き順番を待ちます。並列実行のために設定は不要です。「Run all Tasks」をクリックすれば、Kiro が残りを処理します。独立したタスクが複数ある Spec では、すぐに違いを実感できるでしょう。私たちの経験では、大きな Spec の実装時間が 1 時間超から約 4 分の 1 に短縮されるケースも見られています。 Quick Plan モードで Spec を高速化 標準の Spec フローには 3 つのフェーズがあります。要件、設計、タスクです。次のフェーズに進む前にそれぞれを承認します。これは未知の領域を探索するときに価値を発揮します。しかし、スコープを明確に把握している、よく理解された機能の場合、Quick Plan モードを使うと正確さを犠牲にせず速く進められます。 プロンプトに基づいて、Kiro は事前に確認事項（スコープ、制約、エッジケース）を質問し、要件・設計・タスクを一度に自動生成します。質問する前に、Kiro はワークスペースをスキャンして言語・フレームワーク・プロジェクト構造を検出し、質問をあなたのスタックに特化したものにします。質問は 4 つの軸を対象とします。スコープと制約、説明の曖昧さ、実装の分岐点、機能の方向性に関する決定です。タスクリストが完成したら、すぐにビルドに取りかかれます。成果物は引き続き作成・保存され、エージェントが実行時に使用します。後から確認・編集することも可能です。タスクの変更を依頼した場合は、タスクのみが再生成されます。設計を調整した場合は、設計とタスクが再構築されます。スコープを変更した場合は、要件からパイプライン全体が再実行されます。Kiro は影響を受ける部分のみを再生成します。 Kiro は実装中、spec の成果物を信頼できる唯一の情報源 (single source of truth) として使用します。これにより、Kiro が行うすべての判断は、文書化された要件や設計上の選択に基づいて追跡できるようになります。Quick Plan は同じ成果に向かうより速いパスであり、構造をスキップするショートカットではありません。 要件分析：ひと通り読むだけでは見逃すものを捕捉する 要件には、一目では気づきにくい微妙な問題が含まれることがあります。たとえば、個々に見ると問題なさそうな2つの要件が、組み合わせてみると同時には満たせない場合があります。 また、読む人によって解釈が分かれ、異なる実装につながってしまう曖昧な表現が含まれていることもあります。 さらに、誰もが「当然そうだろう」と思い込んでいるものの、実際には明文化されていない前提が、後になって問題になることもあります。 Kiro がプロンプトに基づいて要件を生成した後、「Analyze Requirements」を選択すると、ニューロシンボリック AI (Neurosymbolic AI) を活用した深い分析を開始できます。ニューロシンボリック AI は LLM と自動推論を組み合わせ、どちらか単独では実現できないことを達成します。Kiro は曖昧さや矛盾を発見次第（修正案とともに）提示します。それにより、確信を持って設計・実装フェーズに進めます。 曖昧さの検出。 Kiro は各要件の複数の解釈をサンプリングし、異なる開発者が異なる意味に取り得る箇所を見つけます。「レコードを削除する」とは、物理削除を意味するのか、論理削除を意味するのか？Kiro が真の曖昧さを発見した場合、「どちらの意味を意図していましたか？」といった、シンプルな 2 択の質問として提示します。 論理分析。 Kiro は自動推論を使って、要件が整合しているか（2 つの要件が矛盾していないか）を検証し、要件が何も言及していないギャップを見つけます。これは LLM が矛盾の可能性を推測するのではなく、数学的論理を使ってどんな実装も両方のルールを同時に満たせないことを証明するものです。 内部の仕組みを詳しく知りたい場合は、 要件分析の詳細解説 をご覧ください。 必要なところではスピードを、重要なところでは深さを この 3 つの新機能により、Spec はより速くスマートになります。Quick Plan モードは生成を高速化します。並列タスク実行は実装を高速化します。要件分析は、ひと通り読むだけでは見逃す問題を捕捉します。構造はソフトウェアをより良くするものであり、プロセスを遅くするものであってはなりません。今やその両方を実現します。 Quick Plan、並列タスク実行、要件分析は現在利用可能です。 Kiro Spec を使い始める 。 翻訳は Solutions Architect の吉村が担当いたしました。

この投稿は、 Amazon DynamoDB グローバルテーブルのベストプラクティスに関するシリーズのパート 3 です。 パート 1 では、リージョン障害に向けてアプリケーションをどのように準備するかについて議論しました。 パート 2 では、リージョン障害時のフェイルオーバー戦略について取り上げました。 この投稿では、 AWS Fault Injection Service (AWS FIS) を使用して、 DynamoDB グローバルテーブル に対する制御された実験を実行することで、アプリケーションがリージョン障害を期待どおりに処理することを検証する方法を紹介します。AWS FIS は両者で動作が異なるため、 マルチリージョン強整合性 (multi-Region strong consistency) (MRSC) と マルチリージョン結果整合性 (multi-Region eventually consistent) (MREC) の両方のグローバルテーブルを取り上げます。 レジリエントなマルチリージョンアプリケーションを構築するには、2 つの異なる課題があります。それは、障害を想定して設計することと、設計が機能することを証明することです。本シリーズの最初の 2 つのパートでは設計について扱いました。この投稿では証明について扱います。 AWS Fault Injection Service AWS Fault Injection Service は、特定の条件が満たされた場合に実験を自動的にロールバックまたは停止するなど、AWS ワークロード上で実験を実行するためにチームが必要とする制御とガードレールを提供します。 実験テンプレート (experiment templates) を定義して、対象とするリソース、注入する障害、実験の期間を指定します。AWS FIS は、定義された影響しきい値を超えた場合に実験を自動的に停止する停止条件を含む、ビルトインされた安全ガードレールとともに障害注入を処理します。 なぜ AWS FIS でテストするのか DynamoDB グローバルテーブルは、MRSC でも MREC でも、高可用性を備えたマルチリージョンレプリケーションを提供します。定常状態のレプリケーションでは、レプリケーションが中断されたときにアプリケーションがどのように動作するかは分かりません。次のような疑問は、テストなしでは答えるのが困難です。 リージョン障害時に DynamoDB がエラーを返した場合、アプリケーションはフェイルオーバーするのか、それともクラッシュするのか? アプリケーションは、フェイルオーバーアクションが必要となる障害を早期に検出できるか? フェイルオーバーメカニズムは、目標復旧時間 (RTO) 内にトラフィックをシフトできるか? 障害が解決した後、復旧したリージョンで DynamoDB レプリケーションがまだキャッチアップ中である可能性があります。アプリケーションは手動介入なしで復旧するか? AWS FIS の実験により、推測ではなく証拠をもってこれらの質問に答えることができます。 MRSC グローバルテーブルでの AWS FIS 実験の仕組み MRSC グローバルテーブルに対して aws:dynamodb:global-table-pause-replication アクションを使用して AWS FIS 実験を実行すると、実験リージョンと他のすべてのリージョン間のレプリケーションが一時停止されます。例えば、米国西部 (オレゴン) (us-west-2)、米国東部 (バージニア北部) (us-east-1)、米国東部 (オハイオ) (us-east-2) にレプリカを持つ MRSC グローバルテーブルを考えてみましょう。us-east-2 を実験リージョンとして実験を実行すると、us-east-2 への出入りのレプリケーションが影響を受け、us-west-2 と us-east-1 は通常の動作を継続します。 実験中、隔離されたレプリカは操作の種類に応じて異なる動作をします。 結果整合性のある読み込み (Eventually consistent reads) – 許可され、隔離されたレプリカに対して引き続き機能します。 強整合性のある読み込み (Strongly consistent reads) – クロスリージョンの合意に到達できないため、HTTP 500 エラーを返します。 書き込み (Writes) – クロスリージョンレプリケーションが一時停止されているため、HTTP 500 エラーを返します。 コントロールプレーンアクション ( UpdateTable など) – すべてのレプリカリージョンで、テーブル全体にわたってブロックされます。 これらの誘発エラーは、専用の Amazon CloudWatch メトリクス FaultInjectionServiceInducedErrors によって追跡されます。このメトリクスは、実験中および実験後のキャッチアップ期間中に返されたシミュレートされた HTTP 500 エラーをカウントし、 TableName と Operation で分解されます。これらの誘発エラーは、 SystemErrors メトリクスも同じカウントでインクリメントするため、 SystemErrors に対する既存のアラームは実験中に発火することに注意してください。 FaultInjectionServiceInducedErrors メトリクスは、実験誘発エラーと有機的なサービスの問題を区別するのに役立ちます。 MRSC 実験のための IAM 権限 MRSC 実験では aws:dynamodb:global-table-pause-replication アクションが使用され、 dynamodb:InjectError IAM 権限が必要です。この権限は特定のテーブル ARN にスコープを設定できないため、 Resource: "*" で付与する必要があります。実験ロールには、リソースポリシーを管理するための権限 (AWS FIS によってセットアップとテアダウンに内部的に使用されます) と、タグでテーブルを対象とする場合は tag:GetResources も必要です。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBTableActions", "Effect": "Allow", "Action": [ "dynamodb:PutResourcePolicy", "dynamodb:DeleteResourcePolicy", "dynamodb:GetResourcePolicy", "dynamodb:DescribeTable" ], "Resource": [ "arn:aws:dynamodb:*:111122223333:table/my-mrsc-table", "arn:aws:dynamodb:*:111122223333:table/my-mrsc-table/*" ] }, { "Sid": "DynamoDBInjectError", "Effect": "Allow", "Action": "dynamodb:InjectError", "Resource": "*" }, { "Sid": "TagLookup", "Effect": "Allow", "Action": "tag:GetResources", "Resource": "*" } ] } MREC グローバルテーブルでの AWS FIS の動作 MREC グローバルテーブルの場合、AWS FIS はリソースポリシーベースのアプローチを使用します。MREC テーブルに対して同じ aws:dynamodb:global-table-pause-replication アクションを実行すると、AWS FIS は、DynamoDB レプリケーション サービスにリンクされたロール (service-linked role) (SLR) がレプリケーション操作を実行することをブロックする deny ステートメントをテーブルのリソースポリシーに動的にアタッチします。具体的には: レプリケーション SLR に対して GetItem 、 PutItem 、 UpdateItem 、 DeleteItem 、 DescribeTable 、 UpdateTable 、 Scan 、 DescribeTimeToLive 、 UpdateTimeToLive をブロックする deny ステートメントがテーブルポリシーに追加されます。 レプリケーション SLR に対して GetRecords 、 DescribeStream 、 GetShardIterator をブロックする deny ステートメントがストリームポリシーに追加されます。 両方のステートメントには、実験の予想終了時刻のためのビルトインされた安全メカニズムを提供する、時間制限付きの DateLessThan 条件が含まれています。 MRSC との重要な違い: アプリケーションはエラーを認識しません。読み込みと書き込みは、すべてのリージョンでローカルに成功し続けます。停止するのはバックグラウンドのレプリケーションです。あるリージョンでの書き込みが他のリージョンに伝播されなくなり、他のリージョンからの書き込みも隔離されたリージョンに伝播されません。これは以下を意味します。 アプリケーションはユーザーの観点からは通常通り機能し続けます。 実験中に書き込まれたデータはリージョン間で乖離します。 ReplicationLatency CloudWatch メトリクスは出力されなくなります。 実験が終了すると、AWS FIS は deny ステートメントを削除し、レプリケーションがキャッチアップします。 対象テーブルにまだリソースポリシーがない場合、AWS FIS は実験期間中にポリシーを作成し、実験が完了すると削除します。テーブルにすでにリソースポリシーがある場合、AWS FIS は deny ステートメントのみを挿入し、最後に削除して、既存のポリシーをそのまま残します。 MREC 実験のための IAM 権限 MREC 実験はリソースポリシーベースのメカニズムを使用し、 dynamodb:InjectError 権限を必要としません: { "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBActions", "Effect": "Allow", "Action": [ "dynamodb:PutResourcePolicy", "dynamodb:DeleteResourcePolicy", "dynamodb:GetResourcePolicy", "dynamodb:DescribeTable" ], "Resource": [ "arn:aws:dynamodb:*:111122223333:table/my-mrec-table", "arn:aws:dynamodb:*:111122223333:table/my-mrec-table/*" ] }, { "Sid": "TagLookup", "Effect": "Allow", "Action": "tag:GetResources", "Resource": "*" } ] } 前提条件 開始する前に、以下を確認してください。 複数のリージョンにレプリカを持つ DynamoDB グローバルテーブル (MRSC または MREC)。このウォークスルーでは、us-west-2 (プライマリ)、us-east-1、us-east-2 にある MRSC テーブルを使用します。 AWS FIS 実験用の IAM ロール。 AWS Command Line Interface (AWS CLI) v2 がインストールされ、設定されていること。 CloudWatch ダッシュボードまたは監視ソリューションが整っていること。それなしでは、実験の影響を測定できません。 重要: AWS FIS は実際の AWS リソースに対して実際のアクションを実行します。これが初めての AWS FIS 実験の場合は、本番前環境またはテスト環境で開始することを強く推奨します。本番テーブルに対して実行する前に、実験設計と監視に対する自信を構築してください。 ステップ 1: 定常状態を定義する 実験を作成する前に、アプリケーションにとって「正常」がどのようなものか、また実験中の期待される状態を定義します。 例: 「us-east-2 でレプリケーションが 10 分間一時停止された場合、アプリケーションは 30 秒以内に us-west-2 にフェイルオーバーするので、エンドユーザーが認識するエラー率は 0.1% を超えてはならない。」 「us-east-2 で強整合性のある読み込みが失敗した場合、アプリケーションは結果整合性のある読み込みにフォールバックし、そのリージョンの読み込み操作の p99 レイテンシを 50ms 以下に維持する必要がある。」 ベースラインを確立するために、通常運用中の以下のメトリクスを少なくとも 24 時間記録します。 操作ごとの SuccessfulRequestLatency (p50、p99)。 SystemErrors (合計)。ゼロに近い値であるべきです。 アプリケーションレベルのエラー率とレイテンシメトリクス。 これらのベースラインを実験中および実験後の同じメトリクスと比較し、基準を評価します。 ステップ 2: AWS FIS 実験ロールを作成する AWS FIS がグローバルテーブルに対して実験を実行するために引き受けることができる IAM ロールを作成します。このロールには、リソースポリシーを管理する権限 (AWS FIS によって内部的に使用されます) と、MRSC テーブル固有の dynamodb:InjectError 権限が必要です。 dynamodb:InjectError には Resource: "*" が必要であることに注意してください。特定のテーブル ARN にスコープすることはできません。 実験ロールポリシー: { "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBTableActions", "Effect": "Allow", "Action": [ "dynamodb:PutResourcePolicy", "dynamodb:DeleteResourcePolicy", "dynamodb:GetResourcePolicy", "dynamodb:DescribeTable" ], "Resource": [ "arn:aws:dynamodb:*:111122223333:table/my-mrsc-table", "arn:aws:dynamodb:*:111122223333:table/my-mrsc-table/*" ] }, { "Sid": "DynamoDBInjectError", "Effect": "Allow", "Action": "dynamodb:InjectError", "Resource": "*" } ] } 信頼ポリシー: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "fis.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ステップ 3: 実験テンプレートを作成する 以下のコマンドは、レプリケーションを 10 分間一時停止する実験テンプレートを作成します。停止条件である CloudWatch アラームに注目してください。アプリケーションのエラー率が許容しきい値を超えた場合に、実験を自動的に停止します。 aws fis create-experiment-template \ --description "MRSC replication pause - 10 minute resilience test" \ --targets '{ "myGlobalTable": { "resourceType": "aws:dynamodb:global-table", "resourceArns": [ "arn:aws:dynamodb:us-east-2:111122223333:table/my-mrsc-table" ], "selectionMode": "ALL" } }' \ --actions '{ "pauseReplication": { "actionId": "aws:dynamodb:global-table-pause-replication", "parameters": { "duration": "PT10M" }, "targets": { "Tables": "myGlobalTable" } } }' \ --stop-conditions '[{ "source": "aws:cloudwatch:alarm", "value": "arn:aws:cloudwatch:us-east-2:111122223333:alarm:MRSC-Critical-Error-Rate" }]' \ --role-arn "arn:aws:iam::111122223333:role/FIS-DynamoDB-Experiment-Role" ARN の代わりにタグでテーブルを対象にすることもでき、これは共通のタグ (例えば Environment: staging ) を共有する複数のテーブル間で実験を実行したい場合に便利です。これを行うには、対象定義の resourceArns を resourceTags に置き換えます: "myGlobalTable": { "resourceType": "aws:dynamodb:global-table", "resourceTags": { "Environment": "staging" }, "selectionMode": "ALL" } ステップ 4: 実験を実行する 実験を開始します: aws fis start-experiment \ --experiment-template-id EXT1234567890abcdef0 実験ステータスを監視します: aws fis get-experiment \ --id EXP1234567890abcdef0 実験が実行されている間、CloudWatch ダッシュボードと、隔離されたリージョンだけでなくすべてのレプリカリージョンでのアプリケーションの動作を観察します。 実験中: MRSC テーブルの場合: FaultInjectionServiceInducedErrors は、隔離されたリージョン内で誘発された 500 エラーの安定したカウントを操作 ( GetItem 、 PutItem 、 Query など) ごとに表示するはずです。 SystemErrors は同じカウントだけ増加します。このメトリクスに対する既存のアラームが発火します。 結果整合性のある読み込みは、隔離されたリージョンで成功し続けるはずです。これを操作でフィルタリングされた SuccessfulRequestLatency の SampleCount で確認します。 隔離されたリージョン内の強整合性のある読み込みと書き込みは、HTTP 500 エラーを返すはずです。 健全なリージョンは通常通り動作し続けるはずです。これらのリージョンで SuccessfulRequestLatency で確認します。 リージョナルフェイルオーバーが設定されている場合 (例えば、Amazon Route 53 ヘルスチェックを通じて)、トラフィックが目標 RTO 内に健全なリージョンにシフトすることを確認します。 MREC テーブルの場合: アプリケーションはすべてのリージョンで通常通り動作を続ける必要があります。読み込みと書き込みはローカルで成功します。 健全なリージョン間の ReplicationLatency を監視して、それらが互いの間でレプリケーションを継続していることを確認します。 実験リージョンへの ReplicationLatency メトリクスは出力されなくなります。 アプリケーションログにエラーが表示されないはずです。レプリケーションの一時停止はアプリケーションには見えません。 実験終了後: MRSC テーブルの場合: DynamoDB がレプリケーションを再開して収束する間、 FaultInjectionServiceInducedErrors はキャッチアップ期間中に短時間継続する可能性があります。 SuccessfulRequestLatency の SampleCount は、以前に隔離されていたリージョンで実験前のレベルに回復するはずです。 クライアントが再接続する際のリトライストームについて ThrottledRequests を観察します。 MREC テーブルの場合: 実験リージョンへの ReplicationLatency メトリクスが出力を開始し、レプリケーションのバックログが排出されるにつれて減少するはずです。 実験中に健全なリージョンに書き込まれたデータが、以前に隔離されていたリージョンで読み取れるようになっており、その逆も同様であることを確認します。 両方のテーブルタイプの場合: アプリケーションが手動介入なしで定常状態に戻ることを確認します。 コントロールプレーン操作が再び成功するはずです。 ステップ 5: 結果を評価する 実験後、ステップ 1 で定義した基準に戻り、収集したデータと照らし合わせて評価します。次の質問をしてください。 アプリケーションは 500 エラーを適切に処理したか? アプリケーションログで未処理の例外を確認します。エラーがエンドユーザーに伝播した場合は、SDK のリトライ設定を調整するか、サーキットブレーカーを使用したアプリケーションレベルのリトライロジックを追加することを検討してください。 結果整合性のある読み込みは有用なフォールバックを提供したか? 実験中、結果整合性のある読み込みは隔離されたレプリカに対して動作し続けました。アプリケーションが特定の操作で古い読み込みを許容できる場合は、強整合性のある読み込みが 500 エラーを返したときに ConsistentRead=True から ConsistentRead=False に切り替えるフォールバックの実装を検討してください。これにより、トラフィックを健全なリージョンにシフトしている間、リージョン障害中に部分的な可用性を維持できます。 フェイルオーバーメカニズムは作動したか? Route 53 ヘルスチェックまたはカスタムフェイルオーバーメカニズムを使用している場合は、最初の誘発エラーからトラフィックシフトまでの時間を測定します。これを目標復旧時間 (RTO) と比較します。 アラートは発火したか? エラーメトリクスに対する CloudWatch アラームがある場合は、期待されるタイムフレーム内にトリガーされたことを確認します。MRSC テーブルでは、AWS FIS によって誘発されるエラーは FaultInjectionServiceInducedErrors メトリクスと SystemErrors メトリクスの両方を同じカウントでインクリメントすることに注意してください。これは、 SystemErrors に対する既存のアラームが AWS FIS 実験中に発火することを意味します。AWS FIS 誘発エラーと有機的なエラーを区別したい場合は、 FaultInjectionServiceInducedErrors メトリクスを使用します。エラーソースに関係なくエンドユーザーへの影響を捕捉するため、アプリケーションレベルのエラー率にもアラームを作成することを検討してください。 復旧はクリーンに完了したか? 実験後、アプリケーションが手動介入なしで通常運用に戻ったことを確認します。実験中の書き込みから生じた可能性のあるデータの不整合を確認します。 結果が評価基準と一致しなかった場合、それは成功した実験です。お客様に影響を与える前に、レジリエンスのギャップを特定したことになります。 ベストプラクティス DynamoDB グローバルテーブルに対して AWS FIS 実験を実行するお客様と協力した経験に基づいて、以下を推奨します。 小さく始めて、反復し、自動化する。 テスト環境内の単一テーブルに対して短い実験 (10〜15 分) から始めます。自信を構築するにつれて、期間を増やし、ステージング環境でテストし、最終的にはチームが観察できる営業時間中に本番環境で実験を実行します。ベースラインが確立されたら、実験テンプレートを保存して定期的に実行します。多くのチームは、AWS FIS 実験を月次または四半期ごとの運用準備レビューに組み込んでいます。レジリエンスは一度限りの達成ではありません。アプリケーションが進化するにつれて、継続的な検証が必要です。 実際のリスクに合わせて実験を設計する。 過去のインシデントとニアミスを確認し、最初にテストする障害シナリオを優先します。仮定 (「リトライロジックが 500 を処理することに自信がある」) に挑戦する実験は、しばしば最も価値のある発見をもたらします。DynamoDB レプリケーションの一時停止と、他の AWS サービスに対する他の AWS FIS アクションを組み合わせて、より現実的な障害シナリオをテストするシナリオベースのテストを検討してください。例えば、 クロスリージョン接続シナリオ (Cross-Region Connectivity scenario) は、アプリケーションネットワークトラフィック、S3、DynamoDB、その他のサービスをブロックします。 キャッチアップを含む復旧フェーズを監視する。 実験が終了したからといって観察を止めないでください。DynamoDB がレプリケーションを再開し、保留中の書き込みを処理する実験後のキャッチアップ期間は、アプリケーションの復旧ロジックの問題を明らかにする可能性があります。 FaultInjectionServiceInducedErrors メトリクスは、この期間中のエラーも追跡します。実験を成功と宣言する前に、アプリケーションが手動介入なしで定常状態に戻ることを確認します。 FIS 実験ロギングを有効にする: 実験ロギング (experiment logging) を有効にして、実験の実行中に詳細な情報を収集します。実験ロギングはデフォルトで無効になっていることに注意してください。 まとめ このシリーズの パート 1 と パート 2 では、DynamoDB グローバルテーブルを使用したリージョナルレジリエンス向けのアプリケーション設計について取り上げました。この投稿では、 AWS Fault Injection Service を使用してその設計を検証する方法について説明しました。MRSC テーブルの場合、FIS は実際の障害時にアプリケーションが見るのと同じ HTTP 500 エラーを生成します。MREC テーブルの場合、FIS はバックグラウンドレプリケーションを一時停止します。単一のテーブルと短い期間から始めて、自信を得るにつれて範囲を拡大することをお勧めします。実験を安全にスコープすることに関する詳細は FIS 計画ガイド を、さらなる詳細は DynamoDB 開発者ガイドの 障害注入テスト (Fault Injection Testing) を参照してください。 本記事は 2026 年 05 月 20 日 に公開された “Best practices for Amazon DynamoDB Global Tables – Part 3: Validating regional resilience with AWS Fault Injection Service” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/best-practices-for-amazon-dynamodb-global-tables-part-3-validating-regional-resilience-with-aws-fault-injection-service/ 著者について Lee Hannigan Lee はアイルランドを拠点とする AWS DynamoDB チームのシニアデータベースエンジニアです。データモデリング、分散システム、開発者ツーリングにわたる 7 年の経験を持ち、大規模に構築するお客様にとって DynamoDB をよりアクセスしやすくすることに焦点を当てています。 Shiladitya Mandal Shiladitya は、AWS DynamoDB チームのソフトウェア開発マネージャーで、データムーブメントグループを率いています。Amazon に 10 年以上在籍し、分散システムの構築とスケーリングに取り組んできました。シアトルを拠点とする Shiladitya は、グローバルテーブルやその他のクロスリージョン機能を支える DynamoDB のレプリケーションおよびデータムーブメント機能に焦点を当てています。  

このシリーズの パート 1 では、 Amazon DynamoDB グローバルテーブルによるリージョナルレジリエンスの基礎、つまりレプリケーションの仕組み、ワークロードにおける RPO と RTO の意味、そして制御されたフェイルオーバーと混乱状態のフェイルオーバーを分ける運用準備について取り上げました。 パート 3 では、AWS Fault Injection Service (FIS) を使用してフェイルオーバー戦略を検証する方法を紹介します。 時刻は午前 2 時。ページャーが鳴りました。あるリージョンでサービスに障害が発生しており、アプリケーションは別のリージョンからトラフィックの提供を開始しなければなりません。 本投稿では、DynamoDB グローバルテーブルにおける 2 つの主要なフェイルオーバー戦略、それらのトレードオフ、およびフェイルオーバーの最中と後で認識すべき運用上の考慮事項について取り上げます。 フェイルオーバー戦略 中心となる問いはシンプルです。あるリージョンでサービスに障害が発生したとき、アプリケーションはどのようにして別のリージョンの使用を開始するのか? これには 2 つの主要なアプローチがあり、それぞれ異なる RTO 特性と運用上の複雑さを持ちます。どちらのアプローチも、フェイルオーバーの判断材料として、パート 1 で確立した監視シグナル、特に ReplicationLatency 、 SystemErrors 、合成カナリアに依存しています。 戦略 1: Amazon Route 53 Application Recovery Controller (ARC) 協調的なマルチサービスのフェイルオーバーが必要なミッションクリティカルなワークロードには、 Amazon Route 53 Application Recovery Controller (ARC) が最も堅牢なソリューションを提供します。ARC はマルチリージョンのリカバリのために専用に設計されており、そのアーキテクチャは、リージョン全体に障害が発生した場合でも、フェイルオーバー時に依存するコンポーネント自体が高可用性を持つように設計されています。 ARC のマルチリージョンリカバリ機能は、連携して動作するいくつかのコアコンポーネントを中心に構築されています。 Region switch (推奨) Region switch は、複数の AWS アカウントにまたがる大規模で複雑なリカバリタスクをオーケストレートするための ARC の推奨機能です。Region switch は、リカバリを完了するために並列または順次に実行されるワークフローと実行ブロックを含むプランの概念を中心に構築されています。 Region switch プランは手動でトリガーすることも、 Amazon CloudWatch アラームに関連付けて自動化することもできます。例えば、プライマリリージョンにおけるアプリケーションの 5xx エラー率、DynamoDB の SystemErrors 、 ReplicationLatency 、 SuccessfulRequestLatency を監視する 複合アラーム を設定できます。複合アラームが ALARM 状態になると、Region switch がリカバリプランを自動的に実行し、定義した順序で DynamoDB トラフィック、コンピューティングリソース、依存サービスのフェイルオーバーを協調させます。 Region switch は、アクティブ-パッシブ (フェイルオーバーとフェイルバック) およびアクティブ-アクティブ (シフトアウェイとリターン) の両方の構成をサポートし、リカバリプロセスをリアルタイムに可視化するダッシュボードを提供します。 ARC を採用するほとんどのチームにとって、Region switch は適切な出発点となります。マルチサービスのフェイルオーバーに必要な協調と自動化を提供しつつ、インシデント発生時に必要となる手作業のステップを削減します。 Routing controls Routing controls は、クライアントトラフィックをあるリージョナルレプリカから別のレプリカへリダイレクトするために使用できる、シンプルなオン/オフのスイッチです。各 routing control は Amazon Route 53 ヘルスチェックに関連付けられており、それは各リージョンでアプリケーションのフロントに配置された DNS フェイルオーバーレコードに紐付けられています。routing control を On から Off に切り替えると、Route 53 は対応するヘルスチェックを unhealthy としてマークし、DNS フェイルオーバーがトラフィックを健全なリージョンへリダイレクトします。 routing controls の背後にある重要な設計判断は、それらが専用クラスター内の 5 つのリージョナルエンドポイントにわたってホストされている、極めて信頼性の高いデータプレーン上で動作することです。これは、フェイルオーバー元のリージョンが完全に利用不可能であっても、routing control の状態を更新できることを意味します。 AWS は、実際のインシデント時に routing control の状態を更新するためにデータプレーン API を使用すること 、および 5 つのクラスターエンドポイントのいずれかをランダムに選択し、5 つすべてに対するリトライロジックを使用することを推奨しています。 Safety rules Safety rules は、ストレスの高いインシデント中に危険な routing control の状態変更を防ぐガードレールです。例えば、すべてのリージョンが同時に無効化されることを防ぐルールや、少なくとも 1 つのリージョンが常にアクティブであることを必須とするルールを定義できます。チームがプレッシャー下で迅速な判断を下している午前 2 時のインシデント中、safety rules はオペレーターのミスに対するバックストップとして機能します。safety rule が、あなたが正しいと判断した更新をブロックした場合、それを上書きすることはできますが、上書きは明示的かつ監査可能です。 Readiness checks Readiness checks は、AWS リソースクォータ、キャパシティ設定、ネットワークルーティングポリシーなどを監査して、リージョンをまたいでアプリケーションのリソースを継続的に監視します。その目的は、スタンバイレプリカが構成とキャパシティの面で本番レプリカと一致していることを継続的に検証することです。フェイルオーバー先のリージョンの DynamoDB テーブルが本番より低いプロビジョニング済みキャパシティを持っていたり、 Amazon Virtual Private Cloud (Amazon VPC) エンドポイントが欠落していたりすると、readiness checks はフェイルオーバーを必要とする前にそのドリフトを表面化させます。readiness checks は継続的な監視のために設計されており、アクティブなインシデント中にフェイルオーバーをトリガーするためのものではないことに注意することが重要です。 RTO とトレードオフ ARC を使用した場合の RTO は、DNS TTL の伝播次第で数秒から数分の範囲です。Routing control の状態変更は数秒以内に有効になり、Route 53 は対応するヘルスチェックを healthy または unhealthy として直ちにマークします。ただし、クライアントは依然として DNS の変更を取得する必要があるため、実効的な RTO は TTL 設定に依存します (60〜120 秒を推奨)。他のフェイルオーバーアプローチに対する ARC の主要な利点は、フェイルオーバーメカニズム自体の信頼性です。極めて信頼性の高いデータプレーンにより、リージョン全体に障害が発生してもフェイルオーバーを実行できる上、safety rules がプレッシャー下でのオペレーターのミスを防ぎます。 ARC では、アプリケーションのモデリング (recovery groups、cells、readiness checks の定義)、routing controls と safety rules の構成、災害復旧タスク専用の長期 IAM 認証情報の維持に対する事前投資が必要です。AWS は、これらの認証情報を、ID プロバイダーに障害が発生してもアクセス可能となるよう、通常のフェデレーテッドアクセスとは別に、オンプレミスの物理金庫または仮想ボールトに保管することを推奨しています。この投資は、プレッシャー下で初めてフェイルオーバーを実行しなければならない時、ガードレールがオペレーターのミスを防ぐことで報われます。 運用上の推奨プラクティス ARC のドキュメントから、強調すべきいくつかの運用上の推奨プラクティスを取り上げます。 フェイルオーバーに関与するレコードの DNS TTL を 60 秒または 120 秒に設定する。 ARC コントロールプレーンが利用不可能でもアクセスできるよう、5 つのリージョナル クラスターエンドポイントと routing control ARN をブックマークまたはハードコードする。 クライアントがエンドポイントに接続し続ける時間を制限する (Application Load Balancer のデフォルトの keepalive 3,600 秒は高速なリカバリには長すぎるため、300 秒への削減を検討)。 ARC で定期的にフェイルオーバーをテストし、構造がスタックの正しいリソースに揃っていることを確認する。 成熟した運用プラクティスを持ち、厳しい RTO SLA を持つミッションクリティカルなワークロードを扱うチームにとって、ARC は適切なツールです。 戦略 2: Amazon Route 53 を使用した DNS ベースのフェイルオーバー よりシンプルな出発点を求めるチームには、Route 53 が障害のあるリージョンからトラフィックをルーティングするためのアプローチを提供します。 Amazon API Gateway 、 Elastic Load Balancing (ELB)、またはカスタムヘルスチェックエンドポイントなど、リージョナルアプリケーションエンドポイントを監視するように Route 53 ヘルスチェックを構成します。次に、フェイルオーバーのルーティングポリシーを使用して、Route 53 が通常状態ではプライマリリージョンにトラフィックを向け、ヘルスチェックが失敗するとセカンダリリージョンに自動的にルーティングするようにします。両方のリージョンにグローバルテーブルレプリカが存在するため、セカンダリリージョンは即座に読み取りを提供し、書き込みを受け付けることができます。 このアプローチを、単純なエンドポイントの到達可能性ではなく、実際のアプリケーションの健全性シグナルに反応させるには、CloudWatch アラームを監視する Route 53 ヘルスチェックを使用できます。例えば、API Gateway の 5XXError 率が連続する 3 つの 1 分間の評価期間にわたって 5% を超えた場合や、DynamoDB の SystemErrors メトリクスが一定期間ゼロを超えた場合に発火する CloudWatch アラームを作成できます。次に、 CLOUDWATCH_METRIC タイプを使用してそのアラームを Route 53 ヘルスチェックに関連付けます。アラームが ALARM 状態に入ると、Route 53 はヘルスチェックを unhealthy としてマークし、DNS フェイルオーバーを自動的にトリガーします。 これにより、TCP 接続が成功するかどうかだけでなく、アプリケーションにとって実際に重要な健全性シグナルによって駆動される自動フェイルオーバーが実現します。複数の CloudWatch アラームを 複合アラーム に組み合わせて、複数の条件が同時に満たされた場合のみフェイルオーバーをトリガーできるため、誤検知のリスクを低減できます。例えば、 5xx エラー率の上昇、DynamoDB の SystemErrors の増加、 ReplicationLatency の持続的なスパイクのすべてを必要とする複合アラームは、単一のシグナルだけよりも信頼性が高くなります。 RTO に関する考慮事項 このアプローチの RTO は複数の要因に依存します。CloudWatch アラーム自体は、評価期間と datapoints-to-alarm の構成によって、評価して発火するまでに数分かかることがあります。アラームが発火すると、DNS TTL の伝播が追加の遅延を加えます。低い TTL (一般的には 60 秒) を使用していても、クライアント側の DNS キャッシュとリゾルバーキャッシュが実際のフェイルオーバー時間を延長する可能性があります。一部のクライアントやリゾルバーは TTL をまったく尊重しない場合があり、その場合トラフィックの一部は予想よりも長く障害のあるリージョンに到達し続ける可能性があります。実際には、アラーム評価、DNS 伝播、クライアントキャッシュを考慮すると、エンドツーエンドのフェイルオーバー時間は数分になると想定してください。 このアプローチは、数分間のサービス低下が許容できるシンプルなアーキテクチャや、最小限のアプリケーションコード変更でマネージドかつインフラレベルのソリューションを希望するチームに適しています。ヘルスチェックがエンドポイントの到達可能性だけでなく、実際のアプリケーション機能を検証することを確認し、DNS TTL を実用上可能な限り低く設定してください。 アプローチの比較 項目 Route 53 ARC DNS ベース (Route 53) RTO 数秒から数分 数分 複雑さ 高 低 アプリケーションの変更 最小限 (インフラ) なし/最小限 協調 マルチサービス 単一サービス 適している用途 ミッションクリティカルなワークロード シンプルなアーキテクチャ ミッションクリティカルなワークロードの場合、Region switch をプライマリのフェイルオーバーメカニズムとして使用し、ARC から始めることをお勧めします。レジリエンスの取り組みの初期段階にあるチームにとって、Route 53 を使用した DNS ベースのフェイルオーバーは現実的な出発点であり、要件が成熟するにつれて ARC へと進化させていくことができます。 フェイルオーバー中および後に予想されること 堅実なフェイルオーバー戦略があっても、備えておくべき運用上の現実があります。 フェイルオーバー後の古いデータの読み取り 結果整合性モデル (MREC) でフェイルオーバーした直後、アプリケーションは、障害のあるリージョンからの最新の書き込みをまだ受け取っていない項目を新しいリージョンから読み取る場合があります。これは結果整合性モデルの本質的な結果であり、レプリケーションラグのために最新の状態をまだ反映していない可能性のあるレコードを、アプリケーションは処理できなければなりません。 操作を冪等になるように設計し、項目にバージョン属性を含め、MRSC を使用していない限りリージョン間の強整合性を仮定しないでください。例えば、アプリケーションが注文を処理し、その直後にフェイルオーバー先のリージョンから読み戻した場合、読み取りが古いデータを返す可能性があります。バージョンチェックや条件付き書き込みは、古い状態に対して動作することを防ぎます。 コンフリクト解決の意外な結果 ラストライターウィンズはほとんどの場合うまく機能しますが、同時書き込みでは予期しない結果を生むことがあります。2 つのリージョンが同じ項目属性を同時に更新すると、一方の書き込みは静かに「失われ」ます。ほとんどのワークロードでは、書き込み間隔が秒単位であり最新の値が正しい値であるため、これは問題ありません。しかし、金融元帳や在庫カウンターなど、すべての書き込みが重要なワークロードの場合は、より慎重になる必要があります。条件付き書き込みの使用、同じ項目に対するクロスリージョンのコンフリクトを避けるためのデータモデルの設計、またはコンフリクトウィンドウを完全に排除するための MRSC の使用を検討してください。 フェイルオーバー後の高いレプリケーションレイテンシ リージョンが復旧した後、混乱中に蓄積された書き込みのバックログによって引き起こされる、上昇したレプリケーションレイテンシが見られる場合があります。パート 1 の ReplicationLatency アラームと合成カナリアがこれを追跡するのに役立ちます。メトリクスを監視し、バックログがドレインするのを待ちます。レイテンシが 5 分を超え、低下傾向にない場合は、 AWS Support にお問い合わせください。 ターゲットリージョンでのスロットリング ターゲットリージョンで ThrottlingException エラーが発生した場合、原因はほぼ常にリダイレクトされたトラフィックに対する読み取りキャパシティの不足です。オンデマンドテーブルの場合、これらのエラーはキャパシティが自動スケールするにつれて一時的なものであるはずです。プロビジョニング済みテーブルの場合は、パート 1 で説明したように DynamoDB Auto Scaling API を使用してプロビジョニング済みキャパシティを直ちに増やしてください。これがキャパシティを事前に準備することが非常に重要である理由です。 接続の失敗 アプリケーションがターゲットリージョンに接続できない場合は、IAM ポリシーがターゲットリージョンでの DynamoDB アクセスを許可していることを確認してください。プライベート接続のために Amazon VPC エンドポイント を使用している場合は、エンドポイントがフェイルオーバーリージョンにも構成されていることを確認してください。セキュリティグループとネットワーク ACL ルールは、実際のフェイルオーバー時にのみ表面化する接続失敗のもう 1 つの一般的な原因です。 データの不整合 フェイルオーバー後にデータの不整合を観察した場合、これは結果整合性モデルを使用している場合の予想される動作です。障害のあるリージョンからの処理中の書き込みは、混乱前にレプリケートされていなかった可能性があります。アプリケーションレベルの整合性チェックを実装し、バージョン番号を伴う条件付き書き込みを使用し、即時の整合性を仮定するのではなく、正しい状態に収束するようにアプリケーションを設計してください。 まとめ DynamoDB グローバルテーブルでのフェイルオーバーは、複数のリージョンにレプリカを持つことだけが重要なのではありません。ワークロードに適したフェイルオーバー戦略を選び、トレードオフを理解し、いざという時に実行できる運用上の自信を構築することが重要です。 Route 53 ARC は、ミッションクリティカルなワークロードに最も堅牢で協調的なフェイルオーバーを提供し、Region switch がサービスをまたぐリカバリをオーケストレートする推奨メカニズムです。極めて信頼性の高いデータプレーンにより、リージョナルな障害中であってもフェイルオーバーメカニズム自体が利用可能であり続けます。 Route 53 を使用した DNS ベースのフェイルオーバーは、最小限のアプリケーション変更でよりシンプルな出発点を提供しますが、アラーム評価と DNS 伝播を考慮するとエンドツーエンドのフェイルオーバー時間は数分になります。データ損失ゼロを必要とするワークロードの場合、MRSC は RPO を完全に排除します。 どの戦略を選んでも、メカニズムと同じくらい準備が重要です。まだの場合は、このシリーズの パート 1 から始めて、インフラストラクチャの準備が整っていることを確認してください。次に、 パート 3 の FIS 実験のウォークスルーを使用して、エンドツーエンドのフェイルオーバーを検証してください。 始めましょう 次のステップは、現在の状況によって異なります。フェイルオーバーメカニズムがまったくない場合は、Route 53 を使用した DNS ベースのフェイルオーバーから始めてください。 SystemErrors と ReplicationLatency を監視する複合 CloudWatch アラームによって支えられたヘルスチェックを、フェイルオーバーのルーティングポリシーと組み合わせます。すでに DNS ベースのフェイルオーバーがある場合は、Route 53 Application Recovery Controller に移行し、Region switch プランを構成してください。 いずれにしても、フェイルオーバーが機能するかどうかをインシデントが起きるまで確認しないでください。 AWS Fault Injection Service を使用して GameDay をスケジュールし、リージョナルな混乱をシミュレートしてエンドツーエンドのフェイルオーバーを実行してください。MRSC と MREC の両方の構成を含む、DynamoDB グローバルテーブルに対する FIS 実験の実行に関するステップバイステップガイドについては、このシリーズの パート 3 を参照してください。 パート 1 で説明した監視とキャパシティの準備をまだ設定していない場合は、まずそこから始めてください。これがなければ何も機能しません。 より深いガイダンスについては、 DynamoDB グローバルテーブルの使用 と AWS Well-Architected Framework の信頼性の柱 をご覧ください。 本記事は 2026 年 05 月 20 日 に公開された “Best practices for Amazon DynamoDB Global Tables – Part 2: Failover strategies” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/best-practices-for-amazon-dynamodb-global-tables-part-2-failover-strategies/ 著者について Lee Hannigan Lee は、アイルランドを拠点とする AWS DynamoDB チームのシニアデータベースエンジニアです。データモデリング、分散システム、開発者向けツーリングにわたる 7 年の経験を持ち、大規模に構築する顧客にとって DynamoDB をより利用しやすくすることに注力しています。 Shiladitya Mandal Shiladitya は、AWS DynamoDB チームのソフトウェア開発マネージャーで、Data Movement グループを率いています。Amazon に 10 年以上在籍し、分散システムの構築とスケーリングに携わってきました。シアトルを拠点とする Shiladitya は、グローバルテーブルやその他のクロスリージョン機能を支える DynamoDB のレプリケーションおよびデータムーブメント機能に注力しています。

本ブログは、KDDI株式会社 高山 伸也 氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 位置情報データを活用した商圏分析は、小売・飲食・観光業界において出店計画や集客戦略の意思決定に広く活用されています。今回は、 KDDI株式会社 （以下、KDDI）が提供する位置情報ビッグデータ分析サービス「KDDI Location Analyzer（以下、KLA）」の新機能開発事例をご紹介します。特に Amazon Redshift Data Sharing 機能を活用することで、既存機能への影響を抑えながら新機能を追加するアーキテクチャを実現しています。 導入背景 KDDI Location Analyzer とは KDDI は au の携帯電話ネットワークから取得した GPS 位置情報データを活用した商圏分析サービス「 KDDI Location Analyzer 」を 2019 年 6 月にサービス開始しました。位置情報統計データ・GIS データを統合し、125m メッシュ単位・町丁目単位での高精度な商圏分析を実現しています。サービス開始から約7年間でのべ 1,000 以上の民間企業・自治体に利用されており、小売・飲食業界の店舗出店戦略から観光業界・地方公共団体まで幅広い分野で活用されています。インフラには、位置情報というセンシティブなデータを扱う上で KDDI 社内で利用が認定されたクラウド環境として AWS を採用しています。 新機能開発の背景 観光需要の回復と新たなニーズ 観光需要の回復を背景に、地域の魅力創出や商圏の最適化に向けたデータ活用の重要性が高まっています。行政や企業においては、定量的な人流データに基づく政策・戦略立案がこれまで以上に求められるようになりました。 特に、観光地や商業エリアでは、単なる来訪者数の把握にとどまらず、以下のようなニーズが顕在化していました。 来訪前後の行動パターンの把握・分析 宿泊エリアの分析 店舗間の回遊構造の可視化 携帯電話の GPS 位置情報は時系列でトレースできることが最大のメリットです。既存ユーザーからも「この強みをもっと活用した機能が欲しい」という要望が寄せられており、それが今回の新機能開発の直接的なきっかけとなりました。 新機能「観光動態・店舗間回遊の可視化機能」 これらのニーズに応えるため、KDDI は KLA の国内居住者版に以下の3つの新機能を追加しました。 （1）前後立ち寄り分析 都道府県・市区町村、またはジオフェンスで指定した施設に対し、「どこから来訪し、次にどこへ向かったのか」を可視化します。前後時間帯指定スライダー（最大前後 180 分）を動かすことで時系列の変遷を確認でき、スライダーの操作に応じてヒートマップや滞在者数グラフが即座に更新されます。 来訪者区分：全体 or 都道府県外 or 市区町村外（施設選択時） 集計期間： 1 日〜1 カ月、時間帯： 5 時〜29 時（30 分単位） 属性：性年代・居住者・勤務者・来街者 集計結果：周辺滞在者数グラフ（最大前後 180 分）、立ち寄り地滞在者数リスト（町丁目・市区町村・都道府県） 活用シーン：域内の観光ルート立案、店舗販促・品揃えやメニュー開発 「前後立ち寄り分析」操作画面 （2）宿泊地分析 指定した市区町村に来訪した旅行者の宿泊エリアを可視化します。 来訪者区分：旅行者 集計期間： 1 日〜 1 カ月、日にち区分：期間全体・日〜木・金・土・祝休前日 属性：性年代 集計結果：旅行者数グラフ（性年代×日にち区分、宿泊・日帰り）、宿泊施設タイプ別施設数・部屋数（市区町村別）、宿泊地ランキングリスト（市区町村×日にち区分） 活用シーン：地域の宿泊供給と旅行者ニーズを総合的に分析 「宿泊地分析」操作画面 （3）発地分析 特定期間に指定した目的地（都道府県・市区町村）へ来訪した人の出発地*を可視化します。 *：来訪前日の宿泊地または居住地（深夜滞在地） 来訪者区分：全体 or 旅行者 集計期間： 1 日〜 1 カ月、時間帯： 5 時〜 29 時（30 分単位）、日にち区分：期間全体・平日・祝休日 属性：性年代・居住者・勤務者・来街者 集計結果：発地別来訪者数グラフ（性年代・居住地別）、日にち区分別来訪者数グラフ（市区町村別）、発地別来訪者数リスト（都道府県・市区町村×日にち区分） 活用シーン：観光プロモーション施策の検討、経済圏としての強み弱みの把握とサービス改善 「発地分析」操作画面 システムアーキテクチャ 全体構成 KLA のインフラは AWS 上に構築されており、以下のような構成となっています。 KLAのアーキテクチャ ワークロードは既存機能と新機能で処理フローが異なります。 既存機能では、ユーザーのリクエストを Amazon ECS Fargate 上の Web サーバが受け取り、Amazon Redshift Serverless（既存機能の集計基盤）に直接クエリを発行して結果を返却するシンプルな同期処理です。 新機能の回遊分析は、複数地点間の時系列データを処理するため、クエリ1件あたりの実行時間が集計対象地域や集計条件によって数分程度に及ぶ重い処理です。RPU を上げることでクエリ実行時間を短縮できる可能性はありますが、KLA ではコストと UX のバランスを取った設定のもと、同期処理ではユーザーを長時間待たせてしまうため非同期処理を採用しています。Web サーバがリクエストを受け取ると Amazon SQS にメッセージを送信し、AWS Lambda がそれを受けて複数の AWS Fargate タスクを並列起動します。各タスクが Redshift にクエリを発行し、処理結果を Amazon Aurora に格納します。アプリケーションが定期的に Aurora を参照して結果をユーザーに返す非同期構成です。SQS でキューイングすることで、Fargate タスクの起動から結果の Aurora への格納までの一連の集計処理を統一的に管理しています。ユーザーには「集計中」ダイアログを表示することで処理中のタイムラグを意識させない UX を実現しています。 Amazon Redshift Data Sharing の活用 新機能の開発にあたり、2 つの課題がありました。 1 つ目はワークロード分離です。既存機能は同期処理で応答を返せるクエリである一方、新機能の回遊分析は前述の通り数分程度かかる重いクエリです。同一ワークグループで動かすと互いの処理が干渉するリスクがあるため、ワークグループを分離する必要がありました。なお、Amazon Redshift Serverless には AI 主導のスケーリングと最適化機能 があり、ワークロードパターンを機械学習で予測してクエリ実行前にコンピュートリソースを自動最適化することで、バースト的な高負荷クエリが他のクエリに影響を与えないよう対応できます。一方、ベースとなる RPU やサービス要件、クエリ特性、実行周期などが定常的に大きく異なるワークロードを扱う場合には、ワークグループを分離する構成も有効な選択肢となります。 2 つ目はテーブル設計です。新機能の回遊分析では、複数地点間の時系列データを効率的に処理するため、既存テーブルとは異なるソートキーを持つマートテーブルを新たに作成する必要がありました。まずマテリアライズドビュー（MV）の活用を検討しましたが、KLA が扱う位置情報データは約7年4か月分・数十 TB 規模で今後も増加し続けるため、初回作成に 1 日以上かかるという課題がありました。また、日次データ連携でデータが追加されるたびにリフレッシュが必要となる負荷に加え、ユーザーがエリア・期間・属性を自由に組み合わせて指定するサービス特性上、クエリパターンごとに MV を作り分けると管理が煩雑になることも懸念されました。今回の KLA のデータ規模とサービス特性には MV は適合しないと判断し、新機能のクエリパターンに最適化したソートキーを持つマートテーブルとして作成する方針を選択しました。 しかし、ワークグループを分離した上で新機能用ワークグループにもテーブルを持つ構成にすると、日次データ連携や VACUUM・ANALYZE などのテーブル管理を両方のワークグループで行う必要が生じます。この課題を解決する手段として Amazon Redshift Data Sharing を採用しました。 Data Sharing とは、データをコピーや移動することなく、異なるワークグループ・クラスター・AWS アカウント間でライブデータへの即時アクセスを可能にする機能です。データを保有する側をプロデューサー、参照する側をコンシューマーと呼び、プロデューサーが datashare（共有単位）を作成してデータベース・スキーマ・テーブル・ビューなどを公開します。コンシューマーはその datashare に接続することで、データの実体を持たずに直接クエリを実行できます。 KLA での具体的な構成は以下の通りです。プロデューサー側の既存機能ワークグループに、従来機能用と新機能用の2種類のテーブルを作成し、新機能用テーブルを Data Sharing でコンシューマー側に公開しています。コンシューマー側の新機能ワークグループはデータを持たずにこのテーブルをリアルタイムで参照するだけで済み、テーブル管理はプロデューサー側に集約されます。これにより、ワークロード分離とテーブルの一元管理を両立しています。 今後の展望 新機能のリリースに先立ち実施したユーザー向け説明会では、「前後立ち寄り機能はまさに欲しかった機能」「活用イメージが湧きやすい」といった声が寄せられ、特に民間企業からの期待が高まっています。 運用改善とさらなるパフォーマンス向上 現在も継続的な改善に取り組んでいます。 パフォーマンスの継続的な改善： 現在の構成では、プロデューサーワークグループ上でクエリ実行と VACUUM・ANALYZE などのメンテナンス処理が同時に行われるため、数十 TB 規模のデータを扱う KLA では両者が干渉するケースがあります。なお、VACUUM・ANALYZE は現在定期バッチで対応しており、Redshift のオートノミクス（自動実行）機能は利用していません。2026 年 2 月に Amazon Redshift のオートノミクス機能が強化され、 自動バキューム・自動分析などのメンテナンス処理に追加コンピューティングを割り当てることで、ユーザーワークロードへの影響を抑えながら自動実行できるようになりました 。VACUUM・ANALYZE の自動実行については、日次データ連携との実行タイミングの兼ね合いも考慮しながら、追加コンピューティング割り当て機能の活用も含めて引き続き検討を進めていく予定です。 メンテナンス作業の効率化： ⼤規模なデータ追加やテーブル変更など、Redshift に⼤きな変更が必要な場合では、サービス提供を止める時間を最小限に食い止めるため、短時間でメンテナンス作業を終わらせる必要があります。Redshift へのデータ投⼊所要時間を考慮すると、事前にスナップショットから新規 Redshift を復元して変更を加えておき、その短時間のサービス停止中に、Redshift を切り替えるという運⽤を現在取っていますが、この⽅法では、新規 namespace を作成するたびに datashare の参照先をコンシューマー側で、⼿動で変更し直す作業が発生します。2026 年 3 月、Amazon Redshift Serverless に スナップショットから同一 namespace にリストアした際に datashare のパーミッションが自動で維持される機能 が追加されました。新規 namespace への復元ではなく既存の namespace への上書きリストアに運用を切り替えることで、コンシューマー側の手動変更作業を解消できる可能性があり、今後検討を進めていく予定です。 まとめ KDDI による本取り組みは、位置情報ビッグデータ分析における Amazon Redshift Data Sharing の実用的な活用事例です。既存機能と新機能でワークロード特性が根本的に異なるという課題に対し、Data Sharing を活用してコンピューティングを分離することで、ワークグループ間のデータコピーなしに各機能に最適化したテーブル設計とリソース配分を実現しました。 従来の公的統計データでは把握できなかった「人の動き」を、GPS 位置情報データと AWS のスケーラブルな分析基盤を組み合わせることで可視化し、観光施策や商圏戦略の高度化に貢献しています。今後の展開と成果に注目していきたいと思います。 著者 高山 伸也 KDDI株式会社 パーソナル事業統括本部 システム開発本部 プラットフォームビジネス部 安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト  

本日 AWS は、 AWS FinOps Agent  のパブリックプレビューを発表します。これは、コスト異常を調査して根本原因を特定し、組織全体のエンジニアに対して、すでに使っているツールの中でコストに関する質問に回答する、エージェント型 AI ソリューションです。 FinOps（financial operations の略）は、財務・エンジニアリング・ビジネスの各チームを結びつけ、財務上の責任を共有し、コスト・スピード・品質の間でデータに基づくトレードオフを行うことを通じて、クラウド投資のビジネス価値を最大化するものです。FinOps は、ダッシュボード主導の定期的なレビューから、エンジニアリング・財務・FinOps の各チームが一緒に運用する継続的なワークフローへと移行しつつあります。その移行には、専門的なコストの知見、多数のアカウントとワークロードにまたがる規模での実行、そしてエンジニアリングチームがすでに使っているツールとの統合が必要です。AWS FinOps Agent は、これらそれぞれに対応するよう設計されています。エンジニアリング・財務・FinOps のプラクティショナーに専門的なコストの知見をもたらし、チームが Jira や Slack ですでに行っている方法にも適合します。また、定期的なスケジュール、異常が検出されたとき、またはエンジニアからコストに関する質問があったときなど、作業に必要な頻度で実行されます。本エージェントは  AWS Cost Explorer 、 AWS Cost Anomaly Detection 、 AWS Cost Optimization Hub 、 AWS Compute Optimizer を活用するため、その回答には、中央の FinOps チームが依拠しているのと同じデータが反映されます。 Workday、AVIV Group、Convera、Mitre 10 などの初期のお客様は、AWS FinOps Agent を使用して、クラウド財務管理をリアクティブな月次レビューから、スケジュールされたイベント駆動型の運用へと移行しています。これは、コスト異常が積み重なる前に調査し、コストに関する回答をエンジニアに直接届けているということです。 コスト異常を今までより迅速に調査する チームがコスト異常を早く調査できれば、その異常が、新しいワークロードの成長のようなポジティブなビジネスシグナルを反映しているのか、それとも環境を最適化する機会を反映しているのかを、より早く判断できます。 Cost Anomaly Detection のアラートは、何らか変更があったことを知らせます。AWS FinOps Agent はその次のステップを自動的に実行します。コストの変化を AWS CloudTrail イベント（AWS 環境全体で誰がいつ何を変更したかの記録）と関連付けて、急増の原因となった変化を特定し、考えられる根本原因と責任者を含む調査概要を作成します（図 1 参照）。オプションで、エージェントは Jira チケットを開くか、Slack チャンネルに投稿して調査結果を伝えることができます（図 2 参照）。これにより、リソースを所有するエンジニアはコンテキストを理解し、次に何をすべきかを決めることができます。エージェントを最も重要なことに集中させるために、自動化プロンプトにフィルターを含めることができます。たとえば、特定の金額のしきい値を超える異常のみを調査して、チームの注意を最もインパクトの大きい変更に集中させることができます。 図 1 – FinOps Agent によるコスト異常の調査 図 2 – FinOps Agent の Slack チャンネルメッセージ コストの回答をすべてのエンジニアに AWS FinOps Agent を使用すると、エンジニアは自然言語でコストに関して質問し、実際のコストと使用状況データに基づいた回答を得ることができます（図 3 参照）。エンジニアは、「なぜ AWS コストが先月上がったのですか？」と聞くと、コストの変化、要因となったサービスおよびその背後にある使用量の要因を特定した回答を得ることができます。エージェントを組織に合わせて調整するために、アカウントとオーナーのマッピング、チーム定義、タグ付け規則、レビュー頻度などのコンテキストファイルをアップロードできます。エージェントはこのコンテキストを利用して、質問を組織の用語で解釈できます。たとえば、「チーム X のコストはいくらですか？」という質問をそのチームが所有する特定のアカウントに紐づけて回答します。エンジニアは必要なときにすぐ答えを得られ、FinOps チームはその時間を戦略的な仕事に費やすことができます。 図 3 – 自然言語によるコストに関する質問  パブリックプレビューで提供されるもの パブリックプレビューには以下が含まれます。 イベントトリガーによるコスト異常調査。 AWS Cost Anomaly Detection イベントを監視し、統合された調査レポートを作成して、Jira または Slack に配信するようにエージェントを設定できます。 自然言語でのコスト問い合わせ。 ワークロードについてコストに関する質問をして、コストと使用状況のデータに基づいた回答を得られます。 定期的なコストレポート。ダウンロード可能なプレゼンテーション用の HTML、PDF、または PPT フォーマットで、定期的なコストレポート（日次、週次、月次など）をスケジュールできます。 最適化の機会を 1 か所で。 AWS Cost Optimization Hub と AWS Compute Optimizer から推奨事項を取得し、それらを Jira チケットにまとめて、エンジニアリングチームがすでに使用しているツールで作業を引き受けられるようにできます。 コンテキストファイルとメモリ。 組織特有のコンテキストファイルをアップロードできます。エージェントはそれらを回答に適用し、セッションを跨いでコンテキストを記憶できます。 始め方 AWS FinOps Agent は、本日よりパブリックプレビューでご利用いただけます。設定方法は次のとおりです。 最初のエージェントを作成する方法 エージェントを作成。 AWS マネジメントコンソールにサインインし、US East（バージニア北部）（us-east-1）リージョンに切り替え、AWS FinOps Agent コンソールページを開いて、最初のエージェントを作成します（図 4 参照） 図 4 – エージェントを作成する ワンクリックによる IAM ロールの設定。 エージェントがコスト、使用状況、運用データを読み取るために使用するカスタマーマネージドのロールをプロビジョニングします。 Jira と Slack の接続（オプション）。 エージェントがチケットを作成し、メッセージを投稿できるように、Jira のスペース キーと Slack チャンネルを設定します。 エージェントが作成されたことの確認。 AWS FinOps Agent コンソールでエージェントの設定を確認してください。 ウェブアプリケーションを開く。 AWS FinOps Agent コンソールのページから、エージェントのウェブアプリケーションを開いて操作を開始します。 コンテキストのアップロード（オプション）。 ウェブアプリケーションで、アカウントとオーナーのマッピングと組織特有の指示（既知の例外、優先順位付けルール、レビュー頻度など）を追加します。 クエリの実行。 自然言語で尋ねます。たとえば、「先月のコスト要因の上位 10 件をリストアップし、リージョン別にグループ化してください」や「データプラットフォームアカウントで 1,000 ドルを超えるコスト異常を調査し、根本原因を記載した Jira チケットを作成してください」などです。 イベントトリガーのコスト異常検知自動化の設定。 エージェントに「AWS Cost Anomaly Detection イベントを監視し、それぞれの異常の根本原因を調査し、その結果を #finops-anomalies Slack チャンネルに投稿してください」のように依頼してください。この時点から、手動のトリアージなしに異常が調査され、チャンネルに投稿されます。 カスタマーサクセスストーリー 初期のお客様は、AWS FinOps Agent を使用して、継続的な運用として定期的なコストレビュー、コスト異常への対応、そしてエンジニアのフォロースルーを行っています。 Workday Workday は、人事、財務、IT 向けのエンタープライズ AI プラットフォームです。AI プラットフォームインフラストラクチャチームは Workday の AI プラットフォームを AWS で運用しています。 私たちの AI プラットフォームは多数の AWS アカウントにまたがっており、チームの時間を奪っていることが 2 つあります。予算の問題になる前にコストの外れ値を追跡することと、リーダーシップがレビューする月次コストレポートを作成することです。AWS FinOps Agent は、AWS 環境において両方を 1 か所で行うのに役立ちます。対処するために必要なコンテキストとともに潜在的なコスト異常を明らかにし、手作業でまとめていた傾向と支出ビューを生成します。以前はチームが毎月何時間もかけて手動でダッシュボード作業を行っていたことが、今では自然言語のインターフェースから始められます。異常検知と報告が 1 か所にまとめられているおかげで、エージェントは単なる保守ツールではなく、すぐにクラウド運用の中核的な部分になりました。 Serjesh Sharma, Manager, Software Development Engineering、Workday. Mitre 10 Mitre 10 はニュージーランド最大のホームセンター小売業者です。そのプラットフォームエンジニアリングチームは、会社の小売テクノロジーを支える AWS プラットフォームの構築と運用を担当すると同時に、クラウドコストの可視化とガバナンスの管理も担当しています。 私たちのプラットフォームエンジニアリングチームは、2 つの役割を果たしています。私たちは、他のチームがアプリケーションを実行する共有 AWS プラットフォームを構築して運用しています。また、クラウド支出の管理方法についても責任を負っています。これまで、定期的なコストレビュー、異常調査、最適化チェックは、信頼性向上や改善作業と直接競合していました。 AWS FinOps Agent が私たちにもたらすことは、コスト調査とレビューのワークフローを一度定義するだけで、それらの確認作業がバックグラウンドで継続的に実行されることです。異常の特定、未使用のリソースの発見、定期的なコストインサイトの準備などの活動は、もはや誰かがそれを実行することを覚えているかどうかにかかっていません。代わりに、本当に注意が必要なものがあるときに関連する調査結果が浮かび上がります。 限られた人数のプラットフォームチームにとって、手作業から継続的で状況に応じたコストインサイトに移行することは、力を倍増させる意味があります。 Eduard Kleynhans, Platform Engineering Manager, Mitre 10 New Zealand. Convera Convera は、規制のある金融サービス環境で事業を展開する商業決済のグローバルリーダーです。 私たちの FinOps プログラムの課題は、大規模な最適化ではなく、開発者が導入する意図しない小さなコスト変更を、複雑化する前に捉えることです。AWS FinOps Agent はそれをエンドツーエンドで処理します。異常を検出し、何が変更されたかを調査し、そしてリソースを所有するエンジニアリングチームに Jira チケットを作成します。これにより、誰も見ていない共有キューに埋もれることなく、適切なエンジニアの目に直接届くようになります。変化の速いエンジニアリング組織にとって、クローズドループのワークフローが、リアクティブな月次レビューに留まるか、継続的なコストガバナンスを実現できるかを分ける決定的な要素です。 Ramesh Singaraj, Infrastructure Engineering and Operations Leader, Convera. AVIV Group AVIV Group は、フランス、ドイツ、ベルギーで主要なデジタル不動産マーケットプレイスを運営しています。その一元化された FinOps チームは、さまざまな事業部門にわたる数百の AWS アカウントと、複数の共有サービスをサポートしています。 私たちの FinOps チームは、さまざまな事業部門の何百もの AWS アカウントをサポートしており、純粋な集中型モデルからハイブリッドモデルに移行するにつれて、ローカルチームがより多くのコスト作業を自ら引き受けるようになってきています。この移行で最も難しいのは、オンデマンドと Savings Plan の違い、支出予測の計算方法、コスト異常が発生した理由などのエンジニアの質問が、リソース所有者が行動する前に、すべて小さな中央チームにまわってきてしまうことです。AWS FinOps Agent は、独自のアカウントとビジネスユニットの対応関係のコンテキストに基づいて、エンジニアに対してこれらの質問に直接答えます。これにより、私たちの中央チームは、質問ごとのやり取りではなく、チャージバックロジック、最適化戦略、リーダーシップレポートに時間を費やすことができます。大規模な組織を支える小規模な FinOps チームにとって、それはまさに、私たちが可能な限り効果的に機能するために必要なレバレッジです。 Jordi Espasa, FinOps Director, AVIV Group. 提供状況と料金 US East（バージニア北部）リージョンで、AWS FinOps Agent を今すぐ試すことができます。エージェント自体は US East（バージニア北部）リージョンで実行され、管理アカウントで設定すると、AWS リージョンとアカウント全体のコストを管理できます。プレビュー期間中は、AWS FinOps Agent を追加料金なしで使用できますが、月単位の使用制限があります。AWS FinOps Agent に関連して使用される他の AWS サービスには標準料金が適用されます。 まとめ AWS FinOps Agent は、コストの異常が発生した瞬間に調査し、その結果を自動的に所有者に転送します。また、コストに関する答えをすべてのエンジニアが直接手に入れることができるため、すでに使用しているツールから離れることなくクラウド支出を把握できます。時間が経つにつれて、エージェントは AI ワークロードのコスト分析など、より多くの FinOps 機能に拡大するでしょう。これらの機能を組み合わせることで、お客様はクラウドコスト管理を FinOps チームとエンジニアリングチームの両方で継続的に実践できるようになります。 詳細については、 AWS FinOps Agent（プレビュー） にアクセスして、 ユーザーガイド を確認してください。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Jason Wu Jason Wu は AWS のシニアテクニカルプロダクトマネージャーであり、AWS Billing and Cost Management 内で AI for FinOps プロダクトポートフォリオを率いています。彼は FinOps、クラウドのコストおよび使用状況データ、AI を活用したクラウド運用にわたる豊富なプロダクトマネジメントの経験を持っています。複雑なデータについて推論し、インサイトを浮かび上がらせ、アクションを促進する自律型 AI エージェントの構築に注力し、お客様がクラウド環境をより効果的に管理・運用できるよう支援しています。 Letian Feng Letian Feng は AWS のシニアマネージャー（プロダクトマネジメント – テクニカル）であり、AWS のクラウド財務管理プロダクトポートフォリオを率いています。彼は FinOps、クラウド管理、AI/ML インフラストラクチャ、データ分析の分野で、15 年以上のプロダクトマネジメントおよびソフトウェアエンジニアリングの経験を持っています。AI を活用して、お客様がクラウド環境を管理・運用・最適化する方法を変革すること、そして実際の顧客の課題を解決する革新的なソリューションを提供することに情熱を注いでいます。

本日、 Amazon Bedrock と Claude Platform on AWS で Claude Fable 5 が利用可能になったことをお知らせいたします。Claude Fable 5 は、Mythos レベルの機能をすべてのお客様が利用できるようにするとともに、より広く安全に使用できるように設計された強力な保護手段を備えています。Fable 5 は、テストされたほぼすべてのベンチマークで最先端であり、ソフトウェアエンジニアリング、ナレッジワークタスク、ビジョンにおいて並外れたパフォーマンスを発揮し、野心的で長期にわたる作業向けに構築されています。 Claude Fable 5 on Bedrock を使用すると、既存の AWS 環境内で構築し、推論ワークロードをスケールできます。また、Claude Platform on AWS を通じて Claude Fable 5 を使用することも可能です。これにより、Anthropic のネイティブプラットフォームエクスペリエンスが得られます。 Anthropic によると、Claude Fable 5 は、AI モデルで達成できることの段階的な変化を表しています。このモデルの利点は次のとおりです。 長時間の非同期実行 – Claude Fable 5 は、以前のモデルでは維持できなかった複雑なタスクを処理し、コーディングやナレッジワークのタスクを介入なしに長期間実行します。 高度なビジョン機能 – Claude Fable 5 は、ファイルや PDF にネストされた図、チャート、表を理解します。これにより、財務、法務、分析、建築、ゲームにおけるリサーチや文書を多用する作業が可能になります。コーディングでは、モデルは忠実度の高い設計を実装し、ビジョンを使用してそのアウトプットを目標と照らし合わせます。 積極的な自己検証 – 本モデルは学習内容に基づいてスキルを自己更新し、独自のハーネスと評価を開発します。 Claude Fable 5 には、誤用のリスクが高い特定の領域でのパフォーマンスを制限する保護手段が含まれています。サイバーセキュリティ、生物学、化学、健康に関連する有害なプロンプトは、代わりに Opus 4.8 からの応答を受け取るようにフォールバックします。Anthropic はより強力な保護手段を開発することで、Claude Fable 5 の最先端機能のほぼすべてへのアクセスを拡大することができます。制限のない同一モデルが Claude Mythos 5 であり、精査された少数のお客様のみが利用できます。 動作中の Claude Fable 5 モデル Claude Fable 5 は Amazon Bedrock と Claude Platform on AWS の両方でご使用いただけます。この投稿では、Amazon Bedrock へのアクセス方法と使用方法に関するガイダンスをご紹介します。Claude Platform on AWS に関するガイダンスについては、 ドキュメント にアクセスして詳細をご確認ください。 Amazon Bedrock の使用を開始するには、 Anthropic Messages API を使用してプログラムでのみモデルにアクセスし、Anthropic SDK を介して bedrock-runtime エンドポイントまたは bedrock-mantle エンドポイントを呼び出します。 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を介して bedrock-runtime の Invoke API と Converse API のみ引き続き使用できます。 コンソールのサポートは近日開始予定です。 Claude Fable 5 モデルにアクセスするには、モデルを呼び出す前に Data Retention API を使用し、 provider_data_share を設定してデータ共有を有効にする必要があります。リリース時には、この設定用のコンソールユーザーインターフェイスはありません。 curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: <your-bedrock-api-key>" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' bedrock-runtime エンジンを使用している場合は、以下のサンプルスクリプトを実行してください。 curl -X PUT https://bedrock.us-east-1.amazonaws.com/data-retention \ -H "Authorization: Bearer <your_bearer_token>" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' このモードでは、Amazon Bedrock は推論データをモデルプロバイダーの要件に従って保持し、共有できます。Anthropic では、30 日間のインプットとアウトプットの保持と、人間によるレビューが必要です。詳細については、「 Amazon Bedrock の乱用検知 」をご覧ください。 まずは Anthropic SDK for Python から、 bedrock-mantle エンドポイントで Messages API を使ってみましょう。Anthropic SDK をインストールします。 pip install anthropic Claude Fable 5 モデルを呼び出すための Python コードのサンプルは次のとおりです。 import anthropic client = anthropic.Anthropic( base_url="https://bedrock-mantle.us-east-1.api.aws/anthropic", api_key= <your-bedrock-api-key> ) message = client.messages.create( model="anthropic.claude-fable-5", max_tokens=4096, messages=[ { "role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions", }, ], ) print(message.content[0].text) 詳細については、複数のユースケースとさまざまなプログラミング言語に対応した Anthropic Messages API のコード例 と ノートブックの例 をご覧ください。 Bedrock コンソー ルで Claude Fable 5 を使用できるようになりました。 Playground で Claude Fable 5 を選択してテストします。 bedrock-mantle におけるコンソールサポートは近日中に実装予定です。 また、Claude Fable 5 を bedrock-runtime エンドポイントの Invoke API と Converse APIと併用することもできます。AWS SDK for Python (Boto3) を使用して Converse API を呼び出し、統一されたマルチモデルエクスペリエンスを実現する例を次に示します。 import boto3 bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") response = bedrock_runtime.converse( modelId="global.anthropic.claude-fable-5", messages=[ { "role": "user", "content": [ { "text": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions." } ] } ], inferenceConfig={ "maxTokens": 4096 } ) print(response["output"]["message"]["content"][0]["text"]) 詳細については、AWS SDK を使用して Amazon Bedrock ランタイムを使用する方法を示す コード例 をご覧ください。 知っておくべきこと 役立つと思われる重要な技術的詳細をいくつかご紹介します。 モデルアクセス – Claude Fable 5 へのアクセスは、すべての AWS アカウントに徐々に拡張されます。アカウントにまだアクセスできない場合は、Bedrock の使用状況にもよりますが、すぐに有効になります。このモデルにすぐにアクセスしたい場合は、通常の AWS サポートにお問い合わせください。 価格設定 – 有害なプロンプトが Fable 5 ではなく Opus 4.8 にルーティングされた場合、支払うのは Opus の料金のみです。会話の途中でリクエストがブロックされた場合、最初のトークンは Fable レートで請求され、その後のトークンはOpus レートで請求されます。詳細については、「 Amazon Bedrock の料金 」ページにアクセスしてください。 データ保持 – 同等かそれ以上の機能レベルを持つBedrock の Fable 5、Mythos 5、および将来のモデルでは、Anthropic は Mythos クラスモデルのすべてのトラフィックを 30 日間保存する必要があります。データを一定期間保持することで、Anthropic は、1 回のやりとりでは見えない悪用のパターンを検出できます。データ保持を選択すると、データは AWS のデータとセキュリティの境界から外れます。 Claude Mythos 5 on Bedrock (限定プレビュー) – 脆弱性の発見、ドラッグデザイン、バイオディフェンススクリーニングなど、サイバーセキュリティとライフサイエンスに関する Anthropic の最も有能なモデルも使用できます。これらのドメインは二重使用であるため、現在アクセスは制限されています。詳細については、 モデルカードのドキュメント をご覧ください。 今すぐご利用いただけます Anthropic の Claude Fable 5 モデルは、本日から、米国東部 (バージニア北部) および欧州 (ストックホルム) リージョンの Amazon Bedrock でご利用いただけます。今後のアップデートについては、 リージョンの全リスト をご確認ください。Claude Fable 5 は、北米、南米、欧州、アジアパシフィックリージョンの Claude Platform on AWS でもご利用いただけます。 Claude Platform on AWS の Amazon Bedrock API を使用して Claude Fable 5 をお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

本稿は株式会社八十二長野銀行と AWS Japan の共同執筆により、AWS 人材育成プロジェクトを通じて得られた成果と今後の取り組みをお伝えするものです。 はじめに 株式会社八十二長野銀行 (以下同行) は、長野県長野市に本店を置く地域密着型の金融機関です。同行では「クラウドファースト」を掲げ、AWS を活用したシステム開発案件が年々増加しています。こうした流れの中で、分散系人材を増やし、クラウド技術を担える人材の育成が喫緊の課題となっていました。 この課題に対して同行と AWS は、2025 年度にシステム部門の新入行員 21 名を対象とした Enterprise Skills Transformation の Guild Incubator (以下 EST)  というプログラムを実施しました。 EST とは、AWS が提供する伴走支援型の人材育成プログラムです。一般的な短期間の研修プログラムとは異なり、専任のインストラクターがお客様に付き、組織の状況や課題をヒアリングした上で、人材育成のゴール設定からカリキュラム設計、研修の実施・改善までを支援します。 本記事では、4 ヶ月間にわたる EST の取り組み内容と、そこから得られた成果を共有します。 EST 実施の背景 同行では、上述の人材育成の課題を抱える中、分散系人材育成に向けた第一歩として、AWS の EST プログラムの導入を決定しました。 EST の実施内容 今回の EST では、専任のインストラクターが同行の状況や受講者のスキルレベルを踏まえ、以下の研修プログラムを設計・実施しました。 イノベーションカルチャーの体感からスタート 研修の初日には、AWS が提供する「New Builder Session」を 1 日かけて実施しました。New Builder Session とは、アマゾンのイノベーションカルチャーを体感するプログラムです。お客様を起点に考える「Working Backwards」をはじめとする、AWS のサービス開発の根幹となる考え方やメカニズムを、ワークショップ形式で学びます。 技術的なスキル習得に先立ち、「なぜクラウドを学ぶのか」「お客様にとっての価値とは何か」という本質的な問いに向き合うことで、受講者が主体的に学ぶためのマインドセットを醸成し、その後 4 ヶ月間にわたる研修の土台を築きました。 注: EST プログラムの中で、New Builder Session を必ず実施するというわけではありません。 New Builder Session 実施中の様子 1/2 New Builder Session 実施中の様子 2/2 研修設計の基本方針 本研修は 4 ヶ月間にわたり、「知識」「実践」「姿勢」の 3 つの軸で設計しました。同行には週あたり約 10 時間の学習時間を確保いただき、単なる座学による知識習得にとどまらず、実際に手を動かしてアプリケーションを開発する実践力の養成、そして主体的に学び続ける姿勢の醸成を目指しました。 ブレンデッドラーニングによる学習設計 学習の主軸は AWS Skill Builder によるデジタル学習としました。 AWS Skill Builder とは、600 以上のオンデマンド動画で AWS について学習できるウェブサービスです。動画コンテンツのみならず、 実際に手を動かして学ぶ AWS Builder Labs や、チームで AWS 環境の課題解決をすることでポイントを競い合う AWS Jam などのコンテンツがあります。これらは Skill Builder 側で用意されている AWS アカウントを使用するため、お客様の AWS アカウントを用意せずに利用できます。 有償のサブスクリプションに加入いただくことで、これらすべてのコンテンツに無制限でアクセスでき、受講者は自身のペースで体系的に学習を進めることができます。 受講者は AWS Skill Builder を活用し、AWS の基礎から応用までを体系的に学習しました。一方で、動画視聴のみでは理解が難しい領域については、インストラクターによる対面でのオンサイト研修で復習・補強する構成としました。 さらに、習得した知識を実際の AWS 環境で活用するハンズオンや、上述の AWS Jam といったイベントも実施し、知識の定着と実践力を鍛えました。 このように、セルフラーニング (動画視聴による個人学習) とグループラーニング (オンサイト研修でのチーム学習) を組み合わせた「ブレンデッドラーニング」の設計を採用することで、個人で考えて調べながら学習する時間と、チームでの議論によって別の意見を聞いたり、自分の考えを発信することで理解を深める仕組みにより、高い学習効果の実現を目指しました。 知識: 中級相当の認定資格取得を目指す 知識面では、初級相当の認定資格ではなく中級に相当する Associate レベルの認定資格である AWS Certified Solutions Architect – Associate (SAA) の取得を目標に設定しました。4 ヶ月間にわたり週 10 時間の学習時間を確保いただけるからこそ、AWS 初学者の多くが最初に目指す初級レベルの認定資格にとどまらず、あえて中級レベルの資格まで手を伸ばす構成としました。 認定資格対策としては、受講者がオンサイト研修以外の隙間時間にも繰り返し練習問題に取り組めるよう、生成 AI を活用した学習支援アプリケーションを開発し、同行の環境にデプロイする形で配布しました。受講者には日常的に SAA の練習問題に取り組んでもらうことで、知識の定着を図りました。 実践: チームでのアプリケーション開発 本研修の大きな特徴として、認定資格の取得にとどまらず、チームでのアプリケーション開発を通じて「実践力」を鍛えるプログラムを組み込んだ点が挙げられます。 チームごとに自由に開発ができる AWS のサンドボックス環境 (Amazon SageMaker Studio の Code Editor) で、Amazon Q Developer を用いて、”現場での課題” を解決するデモアプリケーションの設計、開発に取り組みました。 初学者ながらも、AWS のベストプラクティスを参考にして、初期段階からセキュリティやコストを意識したアプリケーションの開発手法を学びました。 研修中の様子 1/2 研修中の様子 2/2 姿勢: 主体性を引き出す研修設計 今回の研修は、受講者の主体性を最大限に引き出すように設計しました。発表会をはじめとするアウトプットの機会を複数用意し、受講者全員、必ず一度は全体で発表をする機会を設けました。また、進捗が早い方はどんどん先に進められるように、追加のコンテンツも用意しました。 一方で、研修の中盤以降、受講者間で理解度に差が生じてきたため、フォローアップミーティングを実施し、理解に苦しんでいる方へのフォローアップにも注力しました。全員を置き去りにしない丁寧なサポート体制を整えることで、受講者一人ひとりの成長を支援しました。 EST の成果 学習への取り組みについて、受講者全員が AWS Skill Builder で 70 時間以上の動画学習を完了しました。これにより、受講者全員が AWS の基礎的なスキルを身につけ、クラウド人材としての第一歩を踏み出したといえるでしょう。 認定資格の取得 SAA に 21 名中 17 名 (合格率 80%) が合格しました。 グループ開発の成果 グループ開発では、4 チームがそれぞれ部内の課題を調査し、その解決策となるアプリケーションを開発・発表しました。RAG (Retrieval-Augmented Generation) を活用した社内ドキュメント検索アプリケーションや、PowerPoint スライドの自動生成アプリケーションなど、いずれも実務に即した実用的なテーマが選定されました。 各チームが開発したアプリケーションはすべて実際に動作するものであり、非常に質の高い成果物となりました。成果発表会では、同行の幹部から「全くクラウド経験やスキルがないところから、4 ヶ月でここまでできることに感動している」とのコメントをいただきました。 成果発表会の様子 1/2 成果発表会の様子 2/2 各チームが開発したアプリケーションの概要 参加者の声 研修後のアンケートでは、受講者から以下のような声をいただきました。 「知識のインプットはオンデマンドがメインであったため自分のペースで確実に進めることができ、オンサイトではアウトプットがメインであったため、学習サイクルを効率的に回すことができた。効果的に知識とスキルが定着したと感じた」 「研修前はクラウドが何か分からない状態でしたが、4 ヶ月の研修で実践的な知識と技術を身につけることができました。知識をインプットするだけでなく、実際に AWS を操作する機会が多かったため、スキル面でも成長を感じることができました」 「AWS 含め、クラウドの概念さえ知識がないところからのスタートでしたが、チームでのアプリ開発ができるまで知識・技術が身についたため、とてもよかったと感じています。Amazon Q Developer などの生成 AI の活用方法についても学ぶ機会となり、AWS 研修開始前よりも AI を使ってできることが増えました」 「講師の方が用意してくださったコンテンツが非常に面白く、最初から最後まで楽しんで学習することができた。また、ただ話を聞いているのではなく受講者同士の意見交換の時間が非常に多く効率的な学習につながった」 「AWS とホスト開発の研修を並行して進める中で、AWS のメリット・デメリットだけでなく、ホストシステムについて客観的な視点でより理解を深めることができた。クラウドについて学ぶことで、今後のキャリアや自分のやりたいことを見つけていくことに非常に役立ったと感じる」 また、今後の意欲として「AWS Certified Solutions Architect – Professional 取得を目指したい」「今後も AWS を活用してアプリケーションを開発したい」といった声も多数寄せられました。 受講者が研修終了後もさらなる高みを目指す意欲を示していることは、本研修が知識やスキルの習得だけでなく、クラウド技術への興味・関心を深く醸成できた証拠であると考えています。 研修責任者の声 研修後、本研修の責任者から以下のような声をいただきました。 「行内研修では見たことがないくらい参加者が楽しそうに学んでおり、新しい発見があった。今回の人材育成を AWS に任せてよかった。」 「AWS は単なるインフラサービスではなく、AWS を活用することで銀行が自ら DX に向けた内製開発に取り組めるようになると感じた。」 今後の取り組み 今回の EST を通じて、クラウド技術の基礎を備えた若手人材を育成しました。しかしながら、ここがゴールではありません。同行では今後、以下の取り組みを検討しています。 まず、今回育成した若手人材が研修で培ったスキルを実務で発揮できるよう、AWS 活用案件への参画など実践の機会を積極的に設けていくことです。知識を現場で活かすことで、さらなるスキルの定着と成長が期待できます。 次に、リーダー・中堅層やクラウド育成担当者を含めた、より幅広い層へのクラウドスキル浸透です。若手層だけでなく組織全体のクラウドリテラシーを高めることで、分散系人材育成をより確実なものにしていきたいと考えています。 まとめ 今回の EST を通じて、同行はクラウド人材育成において大きな一歩を踏み出しました。 一般的な短期間の研修プログラムでは、あらかじめ決められたカリキュラムを数日間で実施し、研修後のフォローは受講者に委ねられます。一方、EST は研修の実施だけでなく、お客様が目指す組織変革に合わせたゴール設定やカリキュラム設計から始まり、研修期間中も受講者の理解度に応じ専任インストラクターが柔軟にコンテンツを調整しながら伴走する人材育成プログラムです。 今回の研修においても、中盤以降に受講者間で理解度の差が生じた際には、フォローアップ体制を迅速に整えることで、全員を置き去りにしない支援を実現しました。こうした伴走支援があったからこそ、AWS 初学者 21 名から SAA 合格率 80%、そして全チームが実際に動作するアプリケーションを完成させるという成果につながったと考えています。 AWS では、クラウドの人材育成経験豊富なインストラクターが、研修プログラムと様々な育成アプローチにより、企業や教育機関のクラウド人材育成をご支援します。ご興味をお持ちの方は、ぜひ AWS アカウントチームまでお問い合わせください。

本記事は 2026 年 6 月 5 日 に公開された「 Adding LINE Messenger to your AWS omnichannel fallback solution 」を翻訳したものです。 本記事では、既存のオムニチャネルフォールバックソリューションに LINE Messenger を統合して拡張する方法を説明します。アーキテクチャの変更点、デプロイ手順、テスト手順についても取り上げます。元のソリューションは Amazon API Gateway 、 AWS Lambda 、 Amazon Simple Email Service (Amazon SES) 、 AWS End User Messaging で構築されており、SMS、WhatsApp、メールを横断して自動フォールバック機能付きでメッセージを配信します。 本記事が拡張対象とする元のオムニチャネルフォールバックソリューションについては、 Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS を参照してください。 LINE Messenger を選ぶ理由 LINE は日本、台湾、タイで広く使われているメッセージングプラットフォームであり、主要市場での月間アクティブユーザー数は 1 億 8,100 万人、うち日本だけで 1 億人に達します ( LY Corporation FY2025 Q3 業績データ )。DAU/MAU 比率は 84% (日本では 88%) と高く、毎日活発に利用されているため、医療分野の予約リマインダー、EC の注文・配送通知、小売のプロモーションキャンペーンなど、タイムリーなコミュニケーションに適したチャネルです。 APAC には KakaoTalk (韓国)、WeChat (中国)、Zalo (ベトナム)、Viber (フィリピン) といった各国で人気のメッセージングプラットフォームが存在しますが、LINE は日本・台湾・タイの 3 市場で同時に強い存在感を持っており、これらの国々を対象としたマルチチャネルメッセージング戦略に高い効果をもたらします。オムニチャネルフォールバックソリューションに LINE を追加することで、各市場のユーザーが好むチャネルでリーチできるようになります。LINE はプライマリチャネルとしてもフォールバックチャネルとしても利用でき、他のチャネルで実装済みのフォールバック・ブロードキャストのパターンをそのまま活用できます。 費用について: LINE Messaging API の料金は国やプランによって異なります。各チャネルの詳細は LINE Messaging API 、 Amazon Simple Email Service (Amazon SES) 、 Amazon End User Messaging の料金ページをご覧ください。 アーキテクチャの概要 フォールバックソリューションに LINE を追加することで、単一の API エンドポイントから 4 つの主要メッセージングチャネルをカバーできます。既存の複雑さを増やさずにリーチを広げられる点が特長です。LINE の統合は既存チャネルと同じイベント駆動型のサーバーレスパターンに従います。次の図はアーキテクチャへの主な追加点を示しています。 図 1: LINE Messenger を追加した更新後のオムニチャネルアーキテクチャ (新規コンポーネントをハイライト表示) 既存のアーキテクチャに 2 つの要素を追加するだけで、LINE ユーザーにリーチできます。 LINE Messaging API の統合 – Primary Handler Lambda と Secondary Handler Lambda に send_line モジュールが追加され、Push Message エンドポイントを通じて LINE Messaging API でメッセージを配信します。 AWS Secrets Manager の統合 – LINE チャネルの認証情報 (アクセストークンとチャネルシークレット) は AWS Secrets Manager に安全に保存され、Lambda 関数がキャッシュを活用して取得します。 LINE 統合の仕組み LINE Messenger の統合は既存のメッセージ処理パイプラインを拡張する形で実装されているため、メール、SMS、WhatsApp と同じ信頼性の高いフォールバック動作が LINE でも利用できます。以下のセクションでは、システムが LINE メッセージとフォールバックシナリオをどのように処理するかを説明します。 LINE メッセージの送信 LINE をプライマリまたはフォールバックチャネルとしてメッセージを送信する場合、LINE 固有の処理を含む同じパターンに従います。 API Gateway がリクエストを受信し、Primary Amazon Simple Queue Service (Amazon SQS) キューに追加します。 Primary Handler Lambda がチャネルを “line” と検出し、 send_line モジュールを呼び出します。 send_line モジュールが Secrets Manager から LINE の認証情報をキャッシュ付きで取得し、LINE Messaging API の Push Message エンドポイントにリクエストを送信します。Push Message API はユーザーが先にメッセージを送ることなく LINE ユーザーへのメッセージ送信を可能にします。リクエストボディには受信者の LINE ユーザー ID (ユーザーが LINE 公式アカウントをフォローした際に割り当てられる一意の識別子) を含む to フィールドと、配信するメッセージオブジェクトを格納した messages 配列が含まれます。モジュールは LINE API を呼び出す前に、受信者の LINE ユーザー ID が期待されるフォーマット (大文字の ‘U’ に続く 32 文字の小文字 16 進数文字) と一致するか検証します。不正な受信者 ID のリクエストは早期に拒否され、外部 API に到達しません。 Lambda 関数がメッセージのステータスを Amazon DynamoDB テーブルに記録します。 フォールバックが設定されている場合、Lambda 関数はメッセージをフォールバックキューにエンキューします。このエンキューは LINE API 呼び出しが成功 (HTTP 200) した場合でも失敗 (200 以外のレスポンス、タイムアウト、または例外) した場合でも実行されます。DynamoDB には成功時に delivered 、失敗時に failed としてメッセージステータスが記録されます。Secondary Handler は DynamoDB を確認し、ステータスが delivered でない場合にフォールバックチャネルで送信します。 Secondary Handler が DynamoDB のステータスを sent_fallback に更新します。 LINE と他チャネルの違い 項目 メール SMS WhatsApp LINE API Amazon SES SendEmail API AWS End User Messaging SendTextMessage API AWS End User Messaging Social SendWhatsAppMessage API LINE Messaging API Push Message API 認証 IAM ロール IAM ロール IAM ロール Secrets Manager 経由のチャネルアクセストークン 外部メッセージ ID のマッピング 不要。 SES は配信コールバックで同じメッセージ ID を返します。 不要。 SMS は配信コールバックで同じメッセージ ID を返します。 必要。 WhatsApp は配信 Webhook で異なるプラットフォームメッセージ ID を返すため、内部の AWS メッセージ ID へのマッピングが必要です。 不要。 配信コールバックがないため、メッセージ ID の紐付けは不要です。 認証情報の保存 IAM (自動) IAM (自動) IAM (自動) Secrets Manager (手動) 配信追跡 SES 配信イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) End User Messaging イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) End User Messaging イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) なし。LINE API からの 200 レスポンス時に即時 delivered に設定。LINE Messaging API には配信 Webhook なし。 LINE は AWS ネイティブの IAM 認証ではなく独自の認証を持つ外部 API を使用します。そのため、認証情報の管理には IAM ではなく AWS Secrets Manager を使用する必要があります。詳細は LINE Messaging API ドキュメント を参照してください。 LINE はビジネス向けに 2 種類のメッセージングプロダクトを提供しています。LINE Messaging API と LINE Official Notification です。 LINE Messaging API は本ガイドの対象であり、双方向の会話型メッセージングをサポートし、モバイルオーダー、ロイヤルティプログラム、カスタマーエンゲージメントなど多くの業種で広く採用されています。LINE には LINE Official Notification (LINE 通知メッセージとも呼ばれる) という別サービスもあり、配送状況通知や予約リマインダーといった一方向のトランザクション通知向けに設計されていますが、ビジネス認証が必要です。 LINE Official Notification はメッセージごとの配信完了イベントを提供しますが、LINE Messaging API にはその機能がありません。Messaging API では HTTP 200 レスポンスが LINE によるメッセージ受け付けを示しており、これが利用可能な最も詳細な配信シグナルです。 LINE Messaging API チャネルの作成 LINE 統合でメッセージを認証・送信するには LINE Messaging API チャネルが必要です。手順は以下のとおりです。 LINE Developers Console にサインインします。アカウントをお持ちでない場合は 個人 LINE アカウント を作成し、対応する iOS/Android/PC アプリをダウンロードします。LINE メッセージの受信テストに必要です。 プロバイダーを作成します (会社名または組織名)。 そのプロバイダーの下に新しい Messaging API チャネルを作成します。 チャネル作成後、LINE Official Account Manager ページから Messaging API を有効化します。 チャネル設定から以下の情報を控えます。 チャネルアクセストークン (Messaging API タブで [Issue] を選択) チャネルシークレット ([Basic settings] タブ) Messaging API 設定で Auto-reply と Greeting messages を無効にします。 デプロイとテスト リポジトリには、CDK スタックのデプロイ、AWS Secrets Manager での LINE 認証情報の設定、個人の LINE ユーザー ID の取得、インテグレーションテストスイートの実行まで、手順を詳しく説明したデプロイガイドが含まれています。テストスイートは設定済みのチャネルを自動的に検出し、対応するテストを実行します。デプロイとテストの詳細については、 リポジトリ のデプロイガイドを参照してください。 セキュリティに関する考慮事項 本ソリューションを本番環境にデプロイする前に、以下の考慮事項をワークロードとコンプライアンス要件に照らして確認してください。 最小権限の IAM サンプルの Lambda 実行ロールは、DynamoDB、Amazon SQS、AWS Secrets Manager のアクセス許可を特定のリソース ARN にスコープしています。Amazon SES ( ses:SendEmail 、 ses:SendTemplatedEmail )、SMS ( sms-voice:SendTextMessage )、WhatsApp ( social-messaging:SendWhatsAppMessage ) の送信アクションは、このサンプルでは特定の送信 ID、電話プール、WhatsApp ビジネスアカウントを設定可能な状態にするため、シンプルに resources: [“*”] で付与しています。本番環境では API がサポートする範囲でさらにスコープを絞ってください。SES は ID レベルの ARN (例: arn:aws:ses:region:account:identity/example.com ) をサポートし、End User Messaging SMS はプールおよび電話番号 ARN をサポートします。このコードを適用する際は、サポートされているすべての項目にリソースレベルのスコープを維持し、本番デプロイ向けの AWS Well-Architected セキュリティの柱と Lambda 実行ロールのガイダンスを確認してください。 LINE 認証情報のローテーション LINE チャネルアクセストークンは有効期限が長く、LINE Developers Console からの手動発行・ローテーションのみサポートされています。プログラムによるローテーション API はありません。組織のキーローテーションポリシー (例: 90 日ごと) に沿って定期的にトークンをローテーションし、Secrets Manager のシークレットを新しい値に更新してください。また、キャッシュされた認証情報が更新されるよう、Lambda のコールドスタートを強制してください (スタックの再デプロイまたは Lambda 環境変数の更新による)。 データ保護と個人情報の保持 本ソリューションは、LINE ユーザー ID、電話番号、メールアドレスなどのメッセージメタデータと受信者識別子を Amazon DynamoDB に保存します。DynamoDB は保存時の AWS マネージド暗号化を使用し、Secrets Manager は AWS Key Management Service (AWS KMS) を使用します。また、LINE API へのすべての送信呼び出しは HTTPS で行われます。メッセージテーブルでは Point-in-time recovery が有効です。 本サンプルでは DynamoDB の Time-to-Live (TTL) 属性を設定していないため、レコードは無期限に保持されます。本番環境では、保持ポリシーに合った TTL 属性 (例: expiresAt) を追加し、テーブルの RemovalPolicy.RETAIN 設定がお使いの環境に適切かどうかを確認してください。LINE ユーザー ID、電話番号、メールアドレスは、日本の個人情報保護法 (APPI)、EU の GDPR をはじめとする各種規制において個人情報に該当します。サービス提供地域ごとの保持義務、データレジデンシー要件、データ主体からのアクセスおよび削除リクエストへの対応プロセスを検討してください。 まとめ オムニチャネルフォールバックソリューションに LINE Messenger を追加することで、メール、SMS、WhatsApp、LINE という重要な 4 つのメッセージングチャネルで顧客にリーチできるようになりました。統合は既存チャネルと同じサーバーレス・イベント駆動型のパターンに従っているため、デプロイと運用がシンプルです。LINE はプライマリチャネルとしてもフォールバックチャネルとしても利用でき、地域の好みに合わせたメッセージング戦略を柔軟に構築できます。次のステップとして、他の地域向けメッセージングサービスを追加してリーチをさらに拡大することを検討してください。また、リッチメッセージ、クイックリプライ、Flex Messages など LINE の高度な機能を活用することで、より魅力的なカスタマーインタラクションを実現できます。 リソース GitHub リポジトリ Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS LINE Developers ドキュメント AWS CDK ドキュメント 著者について Rommel Sunga シンガポール拠点の AWS シニア Solutions Architect。AWS End User Messaging と Amazon Simple Email Service を専門とし、スケーラブルで信頼性の高いコミュニケーションソリューションの構築をお客様と共に取り組んでいます。クラウドベースのメッセージングアーキテクチャの専門知識を活かし、組織のカスタマーエンゲージメント向上を支援しています。 Katsuya Matsuoka 日本拠点の AWS Solutions Architect。メディア業界のお客様を担当しており、レイクハウスアーキテクチャを含むデータ分析を中心に取り組んでいます。 Pavlos Ioannou Katidis Amazon Simple Email Service (SES) と AWS End User Messaging を専門とする AWS シニアスペシャリスト Solutions Architect。スケーラブルで回復性の高いソリューションの設計を得意とし、大規模コミュニケーションシステムやオムニチャネルフレームワークの構築に注力しています。幅広く採用されている AWS ワークショップ、ブログ、技術ソリューションを執筆し、生成 AI を活用した社内ツールの開発でプロセス効率化と生産性向上に貢献しています。re:Invent では、耐障害性の高い通知システム、ワンタイムパスワードの実装、大量メッセージングのベストプラクティスをテーマに登壇。テニス、ウォーキング、個人のコーディングプロジェクトを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Katsuya Matsuoka がレビューしました。

英語版ブログ： “ Highlights from the 2026 AWS Life Sciences Symposium: Research and Drug Discovery ” ライフサイエンス業界全体で、研究者たちは実験の設計方法、データの解釈、そしてシミュレーションとウェット実験を結ぶ創薬サイクルのあり方を根本から変えつつあります。AI エージェントは、この新薬候補の発見プロセス全体を加速させています。2026年5月に開催された 2026 AWS Life Sciences Symposium では、Sanofi、Genentech、Noetik、Apheris、Bristol Myers Squibb、Memorial Sloan Kettering などのリーダーたちが、科学的発見の加速と患者アウトカムの改善のために、エージェンティックAIを現在どのように活用しているかを紹介しました。 研究を変革する 3 つの能力 本シンポジウムを通じて、研究イノベーションの基盤となる3つの能力が浮き彫りになりました。これらは相互に連携し合うものです。 リアルラボ（Wet）とデジタルラボ（Dry）の接続 — ウェットラボを計装化し、実験データが自動的にシミュレーションシステムへ流れ込む仕組みを作ることで、仮説→実験→結果のサイクルを途切れなく回す。 FAIR（ Findable, Accessible, Interoperable, Reusable ）かつガバナンスの効いたデータ基盤の構築 — AI エージェントが推論に必要な科学的コンテキストを備え、インサイトが信頼できるデータに裏付けられるようにする。 強力なAIツールを研究者の手に直接届ける — 生物学的基盤モデルから自律的研究エージェントまで、一部の専門家だけでなく、すべての研究者が日々の業務でAIの全能力を活用できるようにする。 この3つの柱こそが、真の「 lab-in-the-loop 」を形づくる条件です。 本トラックは、ビジョンを示すセッションで幕を開け、なぜ今この瞬間が重要なのかを参加者に伝えました。目覚ましい科学的進歩にもかかわらず、創薬はヒト生物学の膨大な複雑さに依然として制約されています——細胞、化合物、分子間相互作用が生み出す途方もない組み合わせが生む探索空間、そして治療領域・組織・分野を越えて残り続ける知識交換のギャップがその要因です。より豊かな生物学データ、モダンなデータ基盤、そして新世代の AI が融合することで、これらのギャップは埋まり始めています。鍵となるのは、データ・基盤・AI の間をつなぐ仕組みを築き、インサイトが好循環で加速する構造を作ることです。これが lab-in-the-loop の本質です。 ループを閉じる：Amazon Bio Discovery を活用した AI 支援による抗体設 本イベントの目玉発表の一つとして、午前の基調講演で初めて披露され、本セッションで詳細が語られたのが、 Amazon Bio Discovery のローンチです Amazon Bio Discovery は、AI駆動の抗体探索に特化して構築された統合アプリケーションです。lab-in-the-loop ワークフローを阻害する最も一般的な課題——評価すべきモデルが多すぎる、データが断片化している、インシリコ実験とウェットラボでのバリデーションの調整が困難——に対処するよう設計されています。本アプリケーションは、これらを単一のセキュアでスケーラブルな環境に統合し、以下の機能を提供します： コードではなく科学用語で研究者をモデル選択・実験設計・候補評価へとガイドするエージェンティックAIアシスタント 40 以上のオープンソースおよび商用 Biological Foundation Model（生物学的基盤モデル）のカタログへのアクセス モデル間のヘッドトゥヘッドベンチマーク モデルトレーニング これらすべてが GUI 操作のみで完結するため、あらゆる研究者が初日から高度な探索ワークフローを実行できます。 Memorial Sloan Kettering （ MSK ）との印象的なケーススタディでは、チームが Amazon Bio Discovery の AI エージェントを使用し、ターゲットタンパク質の実験構造データや既存の抗体データが一切ない状態から、新規のデスモプラスティック小円形細胞腫瘍（ DSRCT ）ターゲットに対する de novo ナノボディバインダーを設計しました。3 つの de novo 設計手法（ RFantibody、IgGM、mBER ）を使用して 288,000 以上の候補配列を生成し、多目的パレート最適化でフィルタリングした上で、上位候補を Twist Bioscience に送付しウェットラボでバリデーションを行いました。その結果、46 個のバインダーが確認され、トップ候補は KD = 0.66 nM のサブナノモル親和性を達成。ターゲット選定からラボでの検証完了まで、わずか数週間でした。 Twist Bioscience は CRO（受託研究機関）パートナーとして抗体エンジニアリングと生物物理学的キャラクタリゼーションの専門知識を提供し、 Amazon Bio Discovery の CRO パートナーネットワークが自社ラボの枠を超えて lab-in-the-loop 能力を拡張できることを示す好例となりました。 本セッションでは、Johns Hopkins Whiting School of Engineering の Gray Lab との連携で開発された Antibody Developability Benchmark Dataset も紹介されました。本ベンチマークは、公開文献において最大かつ最も多様な抗体データセットで構成されており、4 つの構造フォーマット（ IgG、VHH、NearGermline-IgG、scFv ）にわたる 50 のシード抗体を含み、42 の異なる抗原を標的とし、シードあたり最大 99 のエンジニアリングバリアントを持ちます。評価対象は 6 つの主要な開発性（developability）特性——発現、純度、熱安定性、凝集、ポリリアクティビティ、疎水性——であり、すべてウェットラボ実験で検証済みです。このベンチマークは、AI モデル評価のために長年求められてきた厳密な基準を提供するとともに、モデルが事前にデータセットを学習していない状態で評価できるゼロショット推論にも対応しています。ベンチマーク結果は現在、 Amazon Bio Discovery の一部として利用可能です。 Boltz はセッションの最後に、 Amazon Bio Discovery へ近日提供予定の独自基盤モデルをプレビューしました。改良された基盤モデルの上に、タンパク質-タンパク質親和性予測と開発性フィルターを追加しています。また、説得力のある推論時スケーリング則を実証しました：生成するデザイン数を増やすほどヒット率は継続的に向上し、60,000 から 180,000 デザインの範囲でも改善が続くことが示されました。 発見サイクルの加速：Sanofi の AWS 上の集中型 lab-in-the-loop Sanofi の R&D データプラットフォーム＆プロダクツ責任者である Sabya Dasgupta 氏と、プラットフォーム＆AI ワークフロー責任者である Pradeep Bandaru 氏が、世界最大級の製薬企業の 1 つが AWS 上でエンタープライズ規模の lab-in-the-loop 能力をどのように構築しているかを共有しました。 Sanofiの取り組みから得られた核心的な洞察は、「コンテキストこそが新たなコンピュートである」ということです。パイプラインがどれだけ改善されても、科学的コンテキストを持たないAIエージェントは、すでに試みられた推奨を繰り返し、実験的背景を欠いたままデータを解釈し、良い判断ではなく悪い判断をスケールさせてしまいます。 Sanofi が辿り着いた答えが、 SWEL（Scientific Workflow Experience Labs）です。これは AI エージェントをコンテキスト認識型にし、複雑なコンピュートチェーンをオーケストレーションするオペレーションレイヤーです。AWS上に構築され Amazon Bedrock AgentCore を基盤とする SWEL は、創薬プロセスのあらゆる層にコンテキストを行き渡らせます。具体的には、AI 駆動の分子設計や SIPS（Sanofi 社の統合データ基盤）から始まり、実験の自動化、ワークフローの連携・計算処理のチェーンを経て、最終的には「この分子は過去にどのような検討を経たか」「前回のサイクルで何が起きたか」「なぜこの設計にしたか」「どこで失敗したか」といった文脈を理解する科学的推論エージェントにまでつながります。 成果は明白です：SWEL は MVP（Minimum Viable Product）を 2.5 か月で出荷し、現在 50 以上の科学ワークフローを支え、20 PB 以上の科学データプロダクトへのアクセスを提供し、同じ期間で 2～3 倍のプロジェクトを可能にし、デプロイ速度を 10 倍に加速しました。 際立つユースケースは AI Autolead でした。これは継続学習型のメディシナルケミストリーシステムで、10^13 を超える構造の特徴空間から、サイクルあたり 10 億以上の列挙分子をスクリーニングします。数百の ADME（Absorption, Distribution, Metabolism, Excretion：吸収・分布・代謝・排泄）モデルおよびターゲット AI モデルと、28 の検証済み反応を活用しています。結果：プログラムあたりの生成分子数が 50% 以上削減されつつヒット品質は向上し、ルーチンの de novo 設計が全モダリティで実行されるようになりました。 データインフラの側面では、AWS がエージェンティックコード生成によりインストルメントデータコンバーターの開発を大幅に加速できることを実演し、開発期間を数週間から数分に短縮しました。20 のインストルメントファイルタイプを対象とした評価では、ASM（Allotrope Simple Model）形式変換において 100% のパス率を達成し、ゼロショット生成の 35% と比較して大きな改善を示しました。 研究用途を超えたエージェント展開：Roche の Galileo プラットフォーム Rocheのグローバルヘッド兼 VP Diagnostics R&D である Arick Huensche 氏が、Roche が 90,000 台以上の接続されたラボ機器を横断して、エージェンティック AI をエンタープライズ規模でどのように展開しているかを語りました。 Roche の Galileo プラットフォーム— Amazon Bedrock および Bedrock AgentCore 上に構築されたエージェンティック AIプラットフォーム——は研究プロトタイプではありません。70,000人以上のユーザーにサービスを提供し、Roche のDIA（Diagnostics）R&D ドメイン全体で 29 のエージェントがデプロイされた本番インフラです。このプラットフォームにより、AI エージェントがデータの移動、メタデータの抽出、結果のバリデーション、ワークフローのオーケストレーションを行い、厳密性とトレーサビリティを維持しながら、複雑な科学プロセスを自然言語でのインタラクションに変換します。 2つのプロトコルイノベーションが注目を集めました。MCP（Model Context Protocol：モデルコンテキストプロトコル）は、AgentCore Gateway を通じて利用され、数百のラボ機器 API、LIMS/ELN（Laboratory Information Management System / Electronic Lab Notebook：ラボ情報管理システム/電子実験ノート）コネクター、バイオインフォマティクスパイプラインのトリガーを、既存システムを書き換えることなく MCP ツールとして公開できるようにしています。もう一つのA2A（Agent-to-Agent：エージェント間通信）プロトコルは、エージェントフレームワークやベンダーを横断した自律的コラボレーションを可能にするものです。タスクライフサイクルの状態管理が定義されており、Strands、LangGraph、CrewAI、Google ADK、OpenAI SDK にまたがるクロスフレームワーク相互運用性を実現しています Arick 氏の業界への主要なメッセージ：エージェントは広範な機能ではなく jobs-to-be-done（解決すべきジョブ）にスコープすること、エージェントの活用を考える前にまずデータ基盤へ重点投資すること、そしてガバナンスを制約ではなく機能として扱うこと。規制環境では、ビルトインのコンプライアンスが導入を加速します。なぜなら、科学者は監査可能なものを信頼するからです。 AWS ツールの観点からは、Brian Loyal 氏がデータサイエンス、バイオインフォマティクス、ラボプロセス自動化のワークフローにおいてお客様が AgentCore をどのように採用しているかを実演しました。これにより、チームは科学的厳密性を犠牲にすることなく、より迅速に前進できます。 AI サイエンスファクトリーのスケーリング：Lila Sciences Lila Sciences の VP of Next Generation Platform である Bob Gantzer 氏は、lab-in-the-loop で何が達成できるかについての大胆なビジョン——AI サイエンスファクトリー——を発表しました。 Lila が構築しているのは、単一の AI モデル——いわば「科学的インテリジェンス」——であり、科学のサイクル全体を回すために必要なツール群を備えています：知識ベース、ユニバースシミュレーター、計算ツール、そして AI サイエンスファクトリーです。目標は科学的方法そのものを再発明することであり、機器の完全なパラメトリゼーション、動的実行、スケールされたデータパイプラインを通じて、AI がラボで自律的に仮説生成・実験・学習のサイクルを回す「セルフプレイ」を実現することです。 印象的なデモンストレーションでは、Lila のシームレスな mRNA 設計から実験までのワークフローが示されました。生成 AI による分子選択から、自動合成、ADME アッセイ実行、ML モデル再トレーニングまで——すべてがサイエンティフィックグラフ（科学ワークフローグラフ）を通じてオーケストレーションされています。Lila の mRNA 設計は業界トップクラスの in vivo 性能を実証しており、プラットフォームは現在、タンパク質、RNA、DNA、低分子、触媒、ナノ粒子、そしてその先にまで展開されています。 生物学向け AI モデルの進化：データ駆動型モデルトレーニング 最終セッションでは、 Noetik CEO 兼共同創業者の Ron Alfa 氏、 Apheris CEO 兼共同創業者の Robin Roehm 氏、Bristol Myers Squibb SVP Therapeutic Discovery Sciences の Payal Sheth 氏が集まり、生物学基盤モデルトレーニングの最前線について深く掘り下げました。 AWS は生物学基盤モデルの全体像を示しました：創薬に関連する公開済み基盤モデルの累積数は、2021 年初頭の1から2025 年半ばまでに 226 に成長し、タンパク質・分子構造、シングルセルトランスクリプトミクス、バイオイメージング、DNA配列、マルチモーダルデータにまたがっています。AWSは、 Amazon Bio Discovery によるファインチューニングや Amazon Bedrock でのサーバーレスカスタマイゼーションから、 Amazon SageMaker HyperPod での大規模分散トレーニング、 Amazon Nova Forge によるフロンティアモデル開発まで、モデルカスタマイゼーションの全スペクトラムを提供しています。Nova Forge は、独自データを Amazon Nova のチェックポイントおよびキュレーションされたトレーニングデータとブレンドすることで、ゼロから構築する場合と比較して 10～100 分の 1 のコストでカスタムフロンティアモデルを構築できます。 BMS と Apheris は、AI Structural Biology（AISB）Network の次なる展開を紹介しました。AISB は製薬企業間の連合学習（Federated Learning）ネットワークであり、現在 9 社が参加して運用されています。AISB-1 連合コフォールディングモデルは、5 社のデータを用い 10 週間未満でトレーニングされ、構造的に信頼性の高い結合サイト相互作用の割合（ lDDT > 0.8）において 51% を達成しました。これは OpenFold3 ベースラインの 34% 、平均的な単一企業ファインチューニングモデルの 39% と比較して優れた結果です。AISB-1 は現在 Amazon Bio Discovery で利用可能です。AISB-2 は開発中であり、構造データ、定量的親和性データ、HTS スケールのバイナリ活性データにわたる桁違いに多い独自データを使用して、構造ベースのバーチャルスクリーニング、リード最適化、オフターゲットスクリーニングのための、より広範で汎化性の高い基盤モデルを目指しています。 Noetik はセッションの最後に大胆な主張を展開しました：「 AI 創薬はこの10年間、間違ったデータ——細胞株、マウスモデル、パブリックデータセット——でトレーニングしてきた」。Noetik のアプローチはリアルなヒトデータから始まります。商業ルートで調達し自社が完全に権利を保有するヒト腫瘍検体（ FFPE ）を、特許出願中のロボティクス支援ワークフローで処理し、H&E、タンパク質、空間 RNA、DNA データとペアリングしています。このマルチモーダル患者データセットでトレーニングされた基盤モデルは、Noetik が特定した患者集団においてゼロショット推論で 56% の客観的奏効率（ ORR ）を達成しました。元の臨床試験での ORR 8% と比較して大幅な改善です。スケーリング則は生物学にも当てはまります：性能はモデルサイズとコンテキスト長に応じて大幅に向上し、プラトーの兆候は見られません。 エージェンティック・ディスカバリーの時代が到来 すべてのセッションを通じて、一つの共通メッセージが浮かび上がりました：創薬の未来は、より多くのモデルやコンピュートではなく——コンテキスト、オーケストレーション、そして AI と実験の間のループを閉じることにあります。 2026 AWS Life Sciences Symposium の研究・創薬トラックは、エージェンティック AI がもはや将来の約束ではないことを明確にしました。それは Sanofi、Roche、BMS などにおける本番インフラです。MSK における検証済みの科学です。Noetik における新しいアセットクラスです。そして、次世代の医薬品が構築される基盤です。 AWS は、この転換点においてライフサイエンス業界とパートナーシップを組めることを誇りに思います。科学的野心を患者へのインパクトに変えるコンピュート、モデル、データインフラ、エージェンティックフレームワークを提供してまいります。エージェンティック・ディスカバリーの時代は、すでに始まっています。問われているのは、構築するかどうかではなく——どれだけ速く構築するかです。 亀田　俊樹 ( Toshiki Kameda ) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（DTx 含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

お知らせ 2026年7月からオンラインでサーバーレスに関するワークショップを4件開催します。ぜひ、ご参加ください。 7/7 10:00〜12:00  Kiroによるサーバーレス開発 7/9 10:00〜12:00  イベント駆動アーキテクチャ・アプリケーションの構築 7/14 10:00〜12:00 AWS Lambda durable functions によるコード型ワークフロー 7/16 10:00〜12:00 AWS Lambda マネージドインスタンス 本記事は2026年2月6日に公開された Building fault-tolerant applications with AWS Lambda durable functions を翻訳したものです。翻訳はSolutions Architectの加藤 諒が担当しました。 ビジネスアプリケーションでは、顧客オンボーディング、決済処理、大規模言語モデル推論のオーケストレーションなど、確実に実行する必要がある、あるいは長期間の待機が必要な、複数のステップを連携させることがあります。これらは、一時的な中断やシステム障害があってもプロセスを完了する必要があります。そのため、開発者はビジネスロジックではなく 進捗の追跡、障害の処理、外部イベントの待機時のリソース管理のメカニズムの実装といった付加価値を生まない作業に時間を費やしています。 re:Invent 2025で、 Amazon Web Services (AWS) は AWS Lambda durable functionsを発表しました。これは、使い慣れたプログラミング言語を使用して耐障害性のある複数のステップが必要なアプリケーションとAIワークフローを構築するための新しい機能です。基本的に、durable functionsは通常のLambda関数であるため、Lambdaの開発および運用プロセスは引き続き適用されます。ただし、Lambda関数を作成する際に、durable executionを有効にすることで、進捗のチェックポイント保存、障害からの自動回復が可能になります。また、human-in-the-loopプロセスなどの長時間実行タスクを待つ間、最大1年間実行を一時停止できます。 標準のLambda関数を使用する場合、コードは単一の呼び出しで開始から終了まで実行されます。実行中のいずれかの時点で障害が発生した場合、呼び出し元のイベントソースによって関数全体を再試行する必要があります。実行間で保持する必要がある状態は、明示的に保存および取得する必要があります。これは通常、 Amazon DynamoDB や Amazon Simple Storage Service (Amazon S3 )などの外部ストレージサービスを使用して行われます。さらに、同じイベントの重複（同時）呼び出しを防ぎ、イベントの処理を継続しながら安全に更新をデプロイする対策を講じる必要があります。 対照的に、Lambda durable functionsでは、開発者はイベントハンドラーで「Steps」や「Waits」などのdurable operationsを使用して、進捗をチェックポイントし、障害を処理し、Lambda関数のコンピュート料金を発生させることなく待機期間中に実行を一時停止します。これらのdurable operationsとそれらから任意で返される状態は、durable execution backendで管理され、 自動的に永続化されます。実行中に障害が発生した場合、または一時停止後に関数が実行を再開した場合、Lambdaは関数を再度呼び出し、イベントハンドラーを最初から実行することで以前の状態を復元（リプレイ）しますが、完了したdurable operationsはスキップします。開発者向けがこのチェックポイント/リプレイの仕組みを簡単に利用できるようにするため、Lambda durable execution SDKを使用してイベントハンドラーをラップまたはアノテーションできます。具体的には既存のLambdaコンテキストにcontext.step()やcontext.wait()などのいくつかの新しいメソッドが追加されます。さらに、context.waitForCallback()などのメソッドを使用して、”human-in-the-loop”シナリオなどの外部ジョブや非同期プロセスを待機できます。SendDurableExecutionCallbackSuccessまたはSendDurableExecutionCallbackFailureレスポンスがLambda APIに送信されるまで実行は一時停止されます。 AWS Serverless Application Model (AWS SAM) で、AWS Quick Start Templateを使用して新しいdurable functionを作成します。 sam init コマンドで実行できます。 Lambda durable functionsは、 AWS Cloud Development Kit (AWS CDK) 、 AWS Command Line Interface (AWS CLI) 、 AWS CloudFormation 、およびTerraformなどの他のinfrastructure as code (IaC)フレームワークでもサポートされています。 ユーザーオンボーディングを実行する以下の関数を考えてみましょう。まず、ユーザーの入力データに基づいてユーザープロファイルを作成し、次に検証のためにメールを送信し、ユーザーがメールアドレスを確認するか、24時間のタイムアウトに達するまで待機します。最後に、確認を送信します。 import { DurableContext, withDurableExecution, } from '@aws/durable-execution-sdk-js'; export const handler = withDurableExecution( async (event: OnboardingEvent, context: DurableContext) => { try { // Create user profile const profile = await context.step("create-profile", async () => createUserProfile(event.email, event.name) ); // Wait for email verification via callback const verification = await context.waitForCallback( "wait-for-email-verification", async (callbackId) => { // Send email to user and pass callbackId await sendVerificationEmail(profile, callbackId); }, { timeout: { hours: 24 } } ); // Send confirmation and welcome email const result = await context.step("complete-onboarding", async () => { if (!verification || !verification.verified) return { ...profile, status: 'failed' }; await sendWelcomeEmail(profile.email, profile.name); return { ...profile, status: 'active' }; }); return result; } catch (error) { // omitted } } ); durable functionsには、組み込みでステップ用の カスタマイズ可能なエラー処理があります。たとえば、プロファイルが正常に作成され検証されたが、確認の送信時に一時的なエラーが発生した場合、そのステップが再試行されます。再試行では、プロファイル作成やコールバックなど、以前に完了したチェックポイントはスキップされます。確認送信ステップ内のコードのみが再度実行されます。 次に、durable functionを含めるためにAWS SAMテンプレートを更新します。関数にDurableConfig設定を含めることで、Lambda durable functionを作成します。現在、後からLambda関数にdurable configurationを追加することはできないことに注意してください。ExecutionTimeoutは、暴走やデッドロックといったアプリケーションバグから保護するために、durable executionがタイムアウトする時間を定義します。この設定は、単一の呼び出しが実行できる時間を定義するinvocation timeoutとは別です。単一関数呼び出しの最大invocation timeoutは15分で変わりません。Lambda durable functionsでは、SDKでの待機機能や自動再試行を使用する場合など、通常、1回の’durable executionにつき複数の呼び出しが発生します。非同期呼び出しを使用する場合、ExecutionTimeoutを最大1年間設定できます。 RetentionPeriodInDaysは、実行完了後にdurable executionの実行データが利用可能な期間を定義します。 AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Resources: UserOnboardingFunction: Type: AWS::Serverless::Function Properties: FunctionName: UserOnboardingFunction CodeUri: ./src Handler: index.handler Runtime: nodejs24.x Architectures: - x86_64 MemorySize: 256 Timeout: 60 // 1回のInvocationに対するタイムアウト DurableConfig: // この設定によりdurable functionsになる ExecutionTimeout: 90000 // durable execution全体のタイムアウト（25時間） RetentionPeriodInDays: 7 UserOnboardingFunctionRole: Type: AWS::IAM::Role // omitted for brevity また、関数に必要な権限を含める必要があります。たとえば、マネージドポリシー AWSLambdaBasicDurableExecutionRole を設定します。このポリシーはセキュリティを向上させるためにチェックポイントとログの作成/取得のための最小限の AWS Identity and Access Management (IAM) アクションのみを許可します。したがって、他の（durable）関数を呼び出したり、コールバックを管理する場合はこれでは権限が不足します。詳細については、 ドキュメント を参照してください。 関数をデプロイする前に、AWS SAM local invokeを使用してローカルでテストできます。 AWS SAMは関数をローカルで呼び出し、 context.waitForCallback() に到達するまでイベントハンドラーを実行します。コールバックを完了するために、AWS SAMはコールバックを必要とするdurable functionsをローカル実行した際に対話的にコールバックの返却ができます。この例では、コールバックを完了するために Success レスポンスを送信します。レスポンスに関連データを含めることもできます。画面上のガイドを使用して直接レスポンスを送信するか、別のプロセスから別のAWS SAM CLIコマンドを使用してレスポンスを送信できます。 sam local callback succeed <your-callback-id> --result '<your data>' AWS SAMを使用してdurable functionsの実行履歴を取得できます。これには、以下のサンプルコードに示すように、ステップ、コールバック、待機時間に関する詳細が含まれます。 sam local execution history <execution-arn> 必要にに応じて、代わりにコールバックにFailureレスポンスを送信し、コード内でそれらのエラーを処理できます。 sam local callback fail <your-callback-id> --error-data '<your data>' たとえば、後続のステップで補償ロジックを定義している場合にそれの動作を試すことができます。 関数が意図したとおりに動作することを確認できたので、 sam deploy コマンドを使用してAWSにデプロイします。 Lambda durable functionの呼び出しには、エイリアスやバージョンなどの修飾された Amazon Resource Name (ARN) が必要です。速度優先のプロトタイピングやローカルテスト以外では、 $LATEST 修飾子を使用しないことをお勧めします。明示的なバージョンを使用することで、リプレイが実行開始時と同じコードで常に実行されることが保証されます。これは、決定論的実行を確保し、実行中に関数コードを更新する際の不整合を防ぐためです。 お好みのパッケージマネージャーを使用して、durable execution SDKを関数コードにバンドルすることをお勧めします。SDKは高速に進歩しているため、新機能が利用可能になったときに依存関係を更新できます。 アプリケーションの構築に使用できる、Lambda durable functions SDKの その他のdurable operations があります： waitForCondition() ：条件が満たされるまで関数の実行を一時停止します。たとえば、APIでポーリングされるジョブのステータスなどです。これを機能させるには、waitStrategyとステータスをポーリングするチェック関数を提供します。 parallel() ：同じ関数内で複数のdurable operationsを並列実行し、最大同時ブランチ数や望ましい障害動作などの設定可能なオプションを提供します。これにより、同時非同期アクションの耐久性とチェックポイント管理が合理化されます。 map() ：提供されたマッピング関数に基づいて、配列の各項目に対してdurable operationとチェックポイントを作成します。項目は同時に処理されます。 invoke() ：別のLambda関数を呼び出し、その結果を待機します。SDKはチェックポイントを作成し、ターゲット関数を呼び出し、呼び出しが完了すると関数を再開します。これにより、関数合成とワークフロー分解が可能になります。 詳細については、 開発者ガイド を参照してください。 Lambdaコンピュート料金は、リプレイを含むすべての呼び出しに適用されます。待機操作を使用する場合、関数は実行を一時停止し、Lambda関数の実行が再開されるまで実行時間料金は発生しません。また、durable operations、書き込まれたデータ、データ保持に対しても課金されます。Lambda durable functionsの料金について詳しく知るには、 Lambda料金 ページを参照してください。 最新のリージョン可用性については、 AWS Capabilities by Regionページ をご覧ください。 AWS Lambda durable functionsは、使い慣れたプログラミングパターンを使用して簡単に耐障害性のある長時間実行アプリケーションの構築するために、Lambdaのプログラミングモデルを拡張します。Lambda durable functionsを使用して、チェックポイントとエラー回復を自動的に処理する組み込みメソッドを使い、お好みのプログラミング言語でマルチステップワークフローを記述できます。これによりシンプルなアーキテクチャを維持したまま、ビジネスロジックに集中できます。また、課金は実際に処理を行っている時間のみなのでコストを最適化できます。 Lambda API、 AWS Management Console 、AWS CLI、AWS CloudFormation、AWS SAM、AWS SDK、およびAWS CDKを使用して、Python、Node.jsまたはJavaベースのLambda関数用のdurable functionsを構築できます。 開始するには、 Lambda Developer Guide をご覧いただくか、 re:Invent breakout session をご視聴ください。

こんにちは。流通小売・消費財・飲食業界を担当するソリューションアーキテクトチームです。いよいよ 6 月 25 日 (木)、26 日 (金) の 2 日間、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されます。基調講演や数多くの事例セッションとともに、AWS Expo のエリアでは AWS サービス・ソリューションの最新活用事例や、実際に AWS に触れられるデモを、さまざまな角度から体験いただけます。 その AWS Expo エリア内には、製造、金融、自動車、そして私たちの担当する流通小売・消費財・飲食など、業界別に特化したソリューションをご紹介する AWS Industries Zone が設けられます。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決の方法をご覧いただける場です。業界に精通したエキスパートと、具体的な活用シナリオについてじっくりご相談いただけるスペースもご用意しています。私たち流通小売・消費財・飲食業界担当チームも、このゾーンに今年ならではのテーマで展示を出展します。本ブログでは、その展示内容を一足先にご紹介します。まだ登録がお済みでない方は、ぜひ下記のリンクから。 登録はこちら 図 流通小売・消費財・飲食業界向けブースの位置 AWS 展示ブーステーマ 「AI エージェントが業務の主役になる日」 昨年の Summit では「The Future of Retail」をテーマに、カスタマージャーニーを軸とした店舗体験の “少し先の未来” をご紹介しました。今年、私たちが皆さまにお届けしたいのは、その一歩先 — AI エージェントが、業務そのものの主役になっていく世界 です。 生成 AI を「試してみた」というお客様は、この一年で本当に増えました。一方で、実務での大規模な活用にまで踏み込めている企業は、まだ決して多くありません。そのあいだに横たわっているのは、多くの場合「いまの業務プロセスを全部つくり変えなければならないのではないか」という、心理的なブロッカーです。 私たちが今年のブースでご提案したいのは、その逆の発想です。既存のプロセスはそのままに、まずは業務の “一部” に AI を組み込んでみる。そこから自律エージェント、そして複数のエージェントが連携するマルチエージェントへ少しずつ広げていくことで、やがて業務全体の最適化へたどり着く——この段階的な進化のステップを、実機デモで体感いただきます。 商品をつくり、届け、そして売る。流通小売・消費財・飲食業界のバリューチェーンのそれぞれの現場で、AI エージェントがどのように働き始めているのか。本ブースでは 「商品をつくる」「商品を届ける」「商品を売る・つながる」 の 3 つの切り口で、合計 6 つのデモをご用意しました。順にご紹介していきましょう。 商品をつくる — AI と共創する、これからの商品開発 ヒット商品は、どのように生まれるのでしょうか。市場調査からアイデアの発想、デザイン、検証まで——これまで多くの時間と専門知識を要してきた商品開発の現場に、AI エージェントが伴走するとどうなるのか。ここでは 2 つのデモをご覧いただきます。 バーチャル AI エキスパート — タッチ一つで、自律エージェントがアイデアを形にする 5〜10 人の個性豊かな AI ペルソナが、並列で Deep Research とディスカッションを重ね、あなただけの商品デザインを提案します。アパレルかパッケージのテーマを選び、雰囲気や素材をタッチパネルで選んでいくたびに、各ペルソナがそれぞれの視点で反応し、アイデアが少しずつ形になっていきます。複数の自律エージェントが同時並行で協調し、わずか数分でアウトプットが立ち上がっていく様子を、ぜひ目の前でご体感ください。「複数のエージェントが協調する」とはどういうことなのか、その手触りを感じていただけるはずです。 図 自律エージェントがアイデアを形にするデモイメージ AI で加速する製品イノベーション — マルチエージェントで実現する製品開発 製品開発におけるリサーチ、デザイン、製造計画の各工程を、役割の異なる複数の AI エージェントが連携して進めます。市場調査からターゲットの特定、デザイン生成、仮想ペルソナによる検証、そして製造コスト・収益予測まで——通常であれば数ヶ月を要する一連のプロセスを、わずか数分で駆け抜けます。とはいえ、すべてを AI に委ねるわけではありません。各フェーズで AI が多様な選択肢を提示し、戦略的な意思決定は人間が下す。この「Human in the Loop」の考え方によって、スピードと品質を両立させる新しい商品開発の姿をご覧いただけます。 図 マルチエージェントで実現する製品開発 デモイメージ 商品を届ける — 止めない物流とサプライチェーンのために 災害による物流の停止、深刻化するドライバー不足、原材料費の高騰。日本のサプライチェーンと物流の現場は、いくつもの不確実性と日々向き合っています。「想定外」が起きたそのとき、AI エージェントは何ができるのか。2 つのデモでお見せします。 AI エージェントで危機対応 — 小売×消費財の混乱を AI と人が即座に解決 混乱の検知から対応の完了まで、AI と人が協調する次世代のサプライチェーン管理オペレーションを、ライブでご覧いただきます。小売のシナリオでは、店舗の在庫不足に対して最適な振替ルートを AI が提案します。消費財のシナリオでは、原材料の供給が止まった際の代替サプライヤー探索を実行します。いずれの場合も、AI がビジネスインパクトを瞬時に分析・試算して対応策を提示し、人間がそれを承認し、AI が実行と通知までを担います。Amazon Bedrock AgentCore による Human-in-the-Loop の協調モデルが、リアルな課題シナリオの中でどう機能するのか、ぜひその目でお確かめください。 図 次世代のサプライチェーン管理オペレーション デモイメージ 物流異常を Quick が自動解決 — 配送在庫の異常検知〜問合せまで一気通貫 基幹システム、受発注、在庫、配送 —— 複数のシステムに分散しがちな物流のデータを Amazon Quick に統合し、業務の自動化と可視化を実現します。Amazon Quick – Automate が配送フローを自動で実行し、異常が発生すればメッセージングツールへリアルタイムに通知。Quick Sight のダッシュボードで滞留の状況を一目で把握し、その原因はチャットで深掘り分析できます。社内に蓄積された業務ナレッジも活かしながら、業者へのメール問い合わせまで ——「発見」から「対応」までが途切れなくつながる体験をご覧ください。 図 Quick Sight ダッシュボード デモイメージ 商品を売る・つながる — コマースと店舗の、新しいかたち 買い物の体験も、店頭での働き方も、AI エージェントによって静かに、しかし確かに塗り替わろうとしています。海の向こうで吹き荒れる新しい潮流から、日本の店舗現場のリアルな課題解決まで、2 つのデモでご紹介します。 Future of Agentic Commerce — AWS で実現する新しい E-Commerce の形 いま US で吹き荒れている Agentic Commerce の旋風。「名前は聞いたことがあるけれど、実態はどんなものなのだろう」「自社の事業では、どう対応すればいいのだろう」——そんな疑問をお持ちの方に、その答えをご用意しました。OpenAI や Google からやってくる Incoming Agent、自社で持つ Onsite Agent、そして MCP Apps、UCP、A2A といった実装を、実際にご覧いただけます。来たる Agentic Commerce の時代を、皆さまのビジネスにとって売上向上の Big Opportunity に変える——そのヒントが、ここにあります。 図 Future of Agentic Commerce デモイメージ Eyes On, Voice On — スマートグラスと音声 AI が融合する、フード・現場業務の未来形 実店舗では、スタッフの業務効率化とサービス品質の向上が常に求められています。本展示では、スマートグラスやウェアラブル音声デバイスを AI エージェントと連携させることで、こうした課題に応えるソリューションをご紹介します。デバイスを介して、在庫確認や接客、バックヤード業務を AI が支援し、現場のナレッジをリアルタイムに共有する。経験の浅いスタッフでも、誰もが安定した高品質な業務を実現できる——そんな新しい働き方をご提案します。物理デバイスと AWS がつながることで生まれる、業務の標準化と品質向上の姿を、現場での活用イメージとともにご体感ください。 図 音声操作によるキッチン業務の効率化ソリューション 図 スマートグラスによる店舗業務の効率化ソリューション お客様事例展示 — すでに現場で動いている、生成 AI コンセプトのご紹介だけではありません。展示エリアには、生成 AI を実際の現場で活用されているお客様 2 社の事例展示も併設しています。会期中はお客様ご自身による解説に加え、その場での Q&A も可能です。実装の裏側や、運用してみて初めて見えてきた気づきなど、現場の生の声を直接お聞きいただける貴重な機会です。 株式会社ユナイテッドアローズ 「Amazon Bedrock で実現 対話で深まる日報 AI」 日報には、「書く負担」と「うまく伝わらない」という、相反する 2 つの悩みがつきものです。本展示では、Amazon Bedrock を活用した対話型 AI が店舗スタッフの思考整理を支援し、日報を自動で要約する PoC をご紹介いただきます。AI が深掘りの質問を投げかけることで、報告内容の粒度と一貫性が高まり、本部の状況把握や店舗の行動改善にもつながることが確認できたといいます。現場と本部、その双方の業務品質を高める生成 AI の活用事例です。 株式会社カインズ 「AI で進化する顧客体験 Amazon Bedrock 活用事例」 Amazon Bedrock を活用し、生成 AI によって顧客一人ひとりに最適化された購買体験を実現するソリューションをご紹介いただきます。商品の提案や情報提供を高度にパーソナライズすることで、オンライン・オフラインを問わず顧客接点の価値を高め、購買意欲と満足度の向上に貢献します。 おわりに — 会場でお会いしましょう 「まだ早い」から「もう始めている」へ。流通小売・消費財・飲食業界の現場では、AI エージェントが業務の主役になっていく日が、すぐそこまで来ています。新しい技術を次々と取り込まなければならないように思われるかもしれません。けれども今年のデモでお伝えしたいのは、その逆です。AWS のサービスを組み合わせれば、皆さまの中にすでに蓄積されてきた知識と経験を起点に、業務の “一部” から無理なく始めていける——そんなアイデアばかりをご用意しました。 商品をつくり、届け、売る。そのすべての場面で、AI が業務の一部から全体最適へと進化していく姿を、6 つのデモと 2 社の事例展示でご覧いただけます。「試してみたい」と思われた方は、ぜひその場で私たちにお声がけください。 幕張メッセの AWS Industries Zone で、皆さまのお越しを心よりお待ちしています。会場でお会いしましょう！ 参考情報 AWS ブログ “流通小売” カテゴリー AWS ブログ “消費財” カテゴリー AWS 消費財・流通・小売業向けソリューション 紹介ページ 本ブログは AWS Japan のソリューションアーキテクト 山下 智之 が執筆しました。

2026 年 6 月 8 日週、 AWS IoT Device SDK for Swift が一般公開されました。 Swift Server Workgroup (SSWG) のメンバーである私は、これに注目しています。この SDK は、macOS、iOS、tvOS、Linux の Swift 開発者に本番環境で利用できる MQTT 5 接続、デバイスシャドウ、ジョブ、フリートプロビジョニングを提供します。 皆さんなら、この SDK を使用して何を構築しますか? サーバー上の Swift はここ数年で成熟し、現在では IoT デバイスにも適用されています。これは、Swift をエッジで実行するという幅広いトレンドにつながっています。例えば、 WendyOS は物理 AI 向けのオープンソースのオペレーティングシステムで、NVIDIA Jetson や Raspberry Pi ハードウェアにアプリケーションをデプロイするためのファーストクラスの Swift サポートを提供しています。サーバーサイドの Swift、IoT、エッジコンピューティング間で、数年前にはほとんどの人が驚いたであろう複数の場所にこの言語が登場しています。 それでは、2026 年 6 月 8 日週の AWS ニュースを見ていきましょう。 見出し Amazon RDS for SQL Server が Bring Your Own Media をサポート – オンプレミス環境から SQL Server アプリケーションを移行するお客様は、Amazon RDS 上の Microsoft の License Mobility プログラムを通じて、Software Assurance を含む既存の Microsoft SQL Server ライセンスを再利用できるようになりました。BYOM は AWS License Manager と統合されており、ライセンスの使用状況とコンプライアンスを追跡できます。 さらに表示 Amazon Cognito がマルチリージョンレプリケーションのサポートを開始 – 認証情報、ユーザープール設定、フェデレーション設定などのユーザーとマシンの ID データを、スタンバイリージョンのセカンダリユーザープールにほぼリアルタイムで同期できるようになりました。プライマリリージョンで障害が発生しても、サインインしたユーザーは再認証することなく引き続きアプリケーションにアクセスでき、登録ユーザーは既存の認証情報でサインインできます。マルチリージョンレプリケーションは、16 のリージョンにわたる Essentials または Plus 機能階層のユーザープールのアドオンとして利用できます。  さらに表示 OpenAI の GPT-5.5、GPT-5.4、Codex の Amazon Bedrock での一般提供を開始 – Amazon Bedrock の本番ワークロードで GPT-5.5 と GPT-5.4 を使用できるようになりました。また、AWS 全体で既に使用しているのと同じセキュリティ、ガバナンス、運用制御を使用して、AI を活用したソフトウェア開発でコーデックスを構築できます。GPT-5.5 は OpenAI の最も高性能なモデルで、エージェンティックコーディング、データ分析、多段階の自律タスクに長けています。Codex は、Codex App、Codex CLI、および Visual Studio Code、JetBrains、Xcode との IDE 統合を通じて利用できます。価格は OpenAI のファーストパーティー料金に一致し、使用回数は既存の AWS コミットメントに反映されます。  さらに表示 2026 年 6 月 1 日週のリリース 2026 年 6 月 1 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Bedrock に OpenAI および Anthropic互換 API 用の CloudWatch メトリクスを追加 – CloudWatch メトリクスを使用して、bedrock-mantle エンドポイントへの推論トラフィックをモニタリングできるようになりました。これには、推論カウント、入出力トークンの合計、アカウント、プロジェクト、モデル、プロジェクトおよびモデルの細分性におけるクライアントエラー数が含まれます。 Amazon Bedrock が OpenAI と Anthropic 互換の API 向けに最適化された再設計されたコンソールを発表 – モデルカタログ、並列比較、プロジェクトベースの編成、コードスニペットがあらかじめ入力されたプロジェクト対応ドキュメントなどを使用して、コンソールワークフローを一新しました。 Amazon Bedrock AgentCore Identity が AWS Secrets Manager による独自のシークレットの持ち込みのサポートを開始 – お客様は AgentCore ID 認証情報プロバイダの既存の AWS Secrets Manager シークレット ARN を参照できるようになり、カスタム CMK、タグ付け戦略、自動ローテーションを含むシークレットガバナンスの完全な所有権が実現しました。 AWS Step Functions に AgentCore を利用したエージェント推論ステップを追加 – Amazon Bedrock AgentCore のマネージドハーネスとの統合により、Step Functions ワークフローに AI エージェント推論ステップを追加できるようになりました。複数のエージェントを並行して実行したり、順番に実行したり、人間による承認を追加したり、すべてのエージェントの決定を追跡したりできます。 Amazon EKS と Amazon EKS Distro が Kubernetes バージョン 1.36 のサポートを開始 – Kubernetes 1.36 では、ユーザー名前空間が GA に昇格され、変更されたアドミッションポリシー、インプレースポッドレベルのリソースの垂直スケーリング、リソースヘルスステータスレポートが導入されました。EKS が利用可能なすべての地域で利用できます。 Amazon ECS マネージドインスタンスが AWS Trainium と AWS Inferentia のサポートを開始 – Inferentia2、Trainium1、Trainium2 の各インスタンスタイプで ECS マネージドインスタンスのキャパシティプロバイダーを作成し、Amazon ECS にすべてのアクセラレーターリソースをワークロードに自動的に割り当てることができるようになりました。 Amazon Quick が MCP 接続の VPC 接続のサポートを開始 – 企業のお客様は、プライベートにホストされているモデルコンテキストプロトコル (MCP) サーバーを VPC 経由で Amazon Quick に接続できるようになりました。これにより、インターネットに公開されることなく、独自のアプリケーションや内部ツールに安全にアクセスできるようになります。 AWS Cost and Usage Report 2.0 が Athena と Redshift の統合のサポートを開始 – CUR 2.0 のエクスポートは、サポート対象のインフラストラクチャテンプレート、テーブル定義、データロード手順とともに、選択したクエリエンジンに最適な形式で自動的に配信されます。 Amazon Location Service が公共交通機関とインターモーダルルーティングを発表 – Routes API では、交通手段とインターモーダルという 2 つの新しい移動モードがサポートされるようになりました。これにより、13 の地域にわたって、公共交通機関と徒歩、車、タクシー、レンタルのセグメントを組み合わせて旅行を計画できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 今後の AWS イベント AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 6 月 8 日週のニュースは以上です。2026 年 6 月 15 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – seb 原文は こちら です。

プログラマティック広告（※）に携わる DSP（Demand-Side Platform）・SSP（Supply-Side Platform）事業者なら、一度はこのジレンマに直面したことがあるのではないでしょうか。広告枠を提供するパートナーであるパブリッシャーと広告主との接続を増やせば入札機会が広がり、広告主にもパブリッシャーにも価値を届けられる。しかし現実には、接続のたびに発生するネットワークコストとインフラ構築の時間が、その判断にブレーキをかけてきました。DSP 事業者のUNICORN株式会社 と SSP 事業者の株式会社fluct は、AWSの広告テクノロジーワークロード向けマネージドサービスである AWS RTB Fabric を共通基盤として活用することで、この接続コストとスピードのジレンマを乗り越え、広告配信ネットワークの拡大に踏み出しています。両社は概念実証（PoC）を経て既に本番稼働を開始しており、本記事ではその取り組みと成果を説明します。 ※ プログラマティック広告とは、データとアルゴリズムを用いて広告の買い付け・配信を自動で行う手法。 接続コストとスピードのジレンマ プログラマティック広告の入札処理（Real-Time Bidding）では、1秒間に数十万〜数百万件の入札リクエストが DSP・SSP 間を行き交います。より多くのパートナーと接続し、より多くの入札機会を得ることが、広告主にとってもパブリッシャーにとっても価値を生みます。 しかし現実には、接続先を増やすほど以下のジレンマが深刻になります。 コストのジレンマ： 広告枠を提供するパートナーを増やすほどネットワークコストが膨らみ、応札数の拡大が利益を圧迫する。コストを抑えるためにフィルタリングを強化すれば、本来獲得できた広告枠を逃す。 スピードのジレンマ : 新規パートナーとの接続にコロケーション手配やネットワーク構成の調整が必要で、数週間〜数ヶ月を要する。ビジネス判断のスピードに技術が追いつかない。 パフォーマンスの制約 : ミリ秒単位の入札処理を安定的に維持しながら、トラフィックの急増にも対応し続ける必要がある。 ジレンマを解消に導くAWS RTB Fabricとは このような課題に対処するために生まれた広告テクノロジーワークロード向けフルマネージドサービスであるAWS RTB Fabric の主な技術的特長と構成を紹介します。 AWS RTB Fabricは、SSPとDSP間のリアルタイム入札通信を最適化するAWSのフルマネージドネットワークサービスです。SSPが広告枠のビッドリクエストをDSPに送信する際はパブリックインターネットを経由するのが一般的ですが、AWS RTB Fabricは専用プライベートネットワークを提供し、1桁ミリ秒の低レイテンシーでSSP⇔DSP間の入札リクエスト・レスポンスを交換可能にします。また、RTBワークロードは大量のビッドリクエスト/レスポンスを高頻度で交換するため、通常のインターネットエグレス料金が膨大になりがちですが、AWS RTB Fabricの専用ネットワークを経由することでデータ転送コストを大幅に圧縮できます。これにより標準的なクラウドネットワーキングコストと比較して最大80%のコスト削減が可能です。 AWS RTB Fabricを活用することでコストのジレンマとスピードのジレンマを解消できるのではという期待のもとUNICORN社 と fluct社 は、それぞれ DSP 側・SSP 側からこのジレンマに向き合い、2026年3月よりAWS RTB Fabric を活用した広告配信ネットワークの構築PoCに踏み出しました。 UNICORNとfluctが実施したAWS RTB FabricのPoC 今回の取り組みで両社がPoCを行ったのは、両社（SSP⇔DSP間）の通信経路を「パブリックインターネット経由」から「AWS RTB Fabricの専用プライベートネットワーク経由」に切り替えるというアーキテクチャ変更です。 ＜机上検討＞ AWSが公開しているドキュメントでの仕様確認を経て、利用対象とする機能を特定しました。また、マネージドサービスの利用ということで、特にスケーリングに関するサービス仕様の詳細確認や、モニタリング方法の確認、可用性要件をどのように実現できるかの確認・検討を行いました。また、公開されている価格表からコスト試算を実施したところ、コスト削減の見通しが立ったため、実環境への適用開始を決定しました。 ＜段階的なトランザクションの流入開始＞ 実際の環境でAWS RTB Fabricへの通信切り替えを段階的に実施しました。まずはコスト試算結果の妥当性確認のため、両社のSSP/DSP間で行われている通信の10％をAWS RTB Fabric経由に切り替えることから開始しました。 AWS RTB Fabricを実環境に適用したところ、以下のような結果が得られました。 ネットワークコスト 80～86.5% 削減 — 従来のパブリックインターネット経由と比較し、同一トラフィック量に対するデータ転送コストを大幅削減。これはフィルタリング強化による「入札機会の犠牲」ではなく、通信経路の最適化による純粋なコスト削減です。 入札処理の安定性維持 — レイテンシーの改善により、トラフィック急増時にもタイムアウト率を抑制し、応札率を維持できることを確認。 運用可視性の向上 — DSP 単位でのメトリクスとコストをリアルタイムで把握可能に。 このPoC結果を踏まえ、両社間のトランザクションを全面的にAWS RTB Fabricに切り替えることを決定。2026年5月より両社間のトランザクションのすべてをAWS RTB Fabricを用いた通信に切り替え、現在も安定的に運用を続けています。 ～概念図～ PoCでは以下の結果を確認することができました。 ネットワークコスト80%削減 — 従来のパブリックインターネット経由と比較し、同一トラフィック量に対するデータ転送コストを80%削減。これはフィルタリング強化による「入札機会の犠牲」ではなく、通信経路の最適化による純粋なコスト削減です。 入札処理の安定性維持 — レイテンシーの改善により、トラフィック急増時にもタイムアウト率を抑制し、ビッドレート（応札率）を維持できることを確認しました。 また本件について実際に取り組みを実施した両社からは下記のようなコメントを頂いています。 UNICORN株式会社　取締役 璩 暁毅 様 「AWS RTB FabricのPoCを通じて特に可能性を感じているのは、既存の配信基盤へ比較的容易に組み込めるアーキテクチャである点です。導入や接続にかかる負荷を低減できることで、より多くのパートナーが参加しやすいオープンなエコシステムの実現が期待できます。また、コスト効率の改善に加え、UNICORNとSSP間の処理経路が最適化されることで、広告取引におけるレイテンシの短縮も期待しています。これは広告主やメディアにとっての価値向上だけでなく、ページ表示や広告配信の高速化を通じて、ユーザー体験のさらなる改善にもつながると考えています。今後、こうした取り組みが業界全体の接続性と効率性を高め、オープンインターネットにおけるプログラマティック広告市場のさらなる発展につながることを楽しみにしています。」 株式会社fluct 代表取締役COO 黒田 岳志 様 「ネットワークコストの高騰は、DSPへの接続拡大における大きな課題でした。AWS RTB Fabricの適用によりデータ転送コストを80%削減できたことで、UNICORN様への入札リクエスト数を増加させることが可能となり、パブリッシャーの収益機会の拡大という具体的なビジネス成果に繋がっています。今後もAWSと連携し、配信基盤の強化を通じてパブリッシャーの成長を支援してまいります。」 AWS Japan 常務執行役員技術統括本部長 巨勢 泰宏 は今回の取り組みの成功について、以下のようにコメントしています。 「AWSは、Amazonの広告ビジネスで培った大規模データ処理と低レイテンシー技術の知見を活かし、広告業界のイノベーションを推進してまいりました。AWS RTB Fabricは、DSPとSSPを同一プラットフォーム上で直接接続することで、広告業界が長年抱えてきた大量データ転送と低レイテンシーという課題を解決し、広告の収益性と効果を最大化するサービスです。UNICORN様、fluct様をはじめとするお客様がこのテクノロジーを活用し、新たなイノベーションを生み出すことで、日本の広告業界のさらなる発展につながるものと確信しております。AWSは今後も、広告業界の未来を切り拓くテクノロジーの提供を通じて、業界全体の成長に貢献してまいります。」 UNICORN と fluct の取り組みは、AWS RTB Fabric を活用した広告配信ネットワーク構築の先行事例です。 AWS Japan は、この成果をもとに以下の展開を進めていきます。 ネットワークの拡大 — より多くの DSP・SSP・アドネットワーク事業者への参画呼びかけ ユースケースの深化 — リテールメディア、CTV（コネクテッドTV）など新しい広告領域への展開 技術支援の強化 — 導入を検討する事業者向けの技術ガイダンスと PoC 支援プログラムの提供 広告配信ネットワークへの参画にご関心のある DSP・SSP 事業者の皆様、ぜひお気軽にお問い合わせください。 本ブログに関連するイベント開催について 本ブログ執筆にご協力いただいたUNICORN社とfluct社にもご登壇頂くイベントを下記のとおり開催いたします。AWS RTB Fabric を活用した広告配信ネットワークの輪を広げることに少しでも関心を持たれている方がいらっしゃいましたらぜひご参加ください。 イベント名：AdTech meet up！ 「変わる広告、変わらない価値 ― いまAdTech事業者がAWSに集まる理由」 日時：2026年7月17日（金）16:00-19:00 場所：麻布台ヒルズ森JPタワー 36階 セミナールーム（東京都港区麻布台1-3-1） 対象：プログラマティック広告配信に携わる事業オーナー、エンジニアの方 申し込みWebページ： AdTech meet up「変わる広告、変わらない価値 ― いまアドテク事業者がAWSに集まる理由」 イベント概要： 広告の在り方は変わっても、届けたい付加価値は不変です。ただ、付加価値の届け方が過渡期を迎えています。AIとクラウドが稼ぐ力を引き上げ、そしてコストを大きく押し下げることが容易になったこの変革期に、アドテク事業者の皆様は、何に投資し、何を行い、そして誰と協働すべきでしょうか。 本イベントでは、AIが変えるプログラマティック広告の最前線、AWSのアドテク事業者様向けの最新テクノロジーであるAWS RTB Fabric によるコスト削減と収益拡大の実践、そしてDSP事業者 × SSP事業者によるオープンエコシステム戦略の対談を通じて、その答えを探ります。 また、それらセッションの後にはDSP・SSP事業者同士が直接つながるネットワーキングの場もご用意。同じ課題意識を持つ事業責任者様との交流を通じて、是非とも次の成長の起点を探って頂くことを心から願っております。 アジェンダ： AWS Session① ：AIが変えるプログラマティック広告 スピーカー：アマゾン ウェブ サービス ジャパン合同会社 アド ＆ マーケティング テクノロジーコミュニティ ソリューションアーキテクト　鈴木 康士郎 AWS Session② ：広告コストを収益に変える – AWS RTB Fabric スピーカー：アマゾン ウェブ サービス ジャパン合同会社 アド ＆ マーケティング テクノロジーコミュニティ ソリューションアーキテクト　関藤 寛喜 DSP事業者×SSP事業者による対談 ：アドテク事業者はどこに投資すべきか？—オープンエコシステムが切り拓く次の成長戦略 パネリスト：株式会社fluct　代表取締役COO　黒田 岳志 様 UNICORN株式会社　取締役　璩 暁毅 様 アマゾン ウェブ サービス ジャパン合同会社　プリンシパル事業開発マネージャー　松本 鋼治 本ブログは松原（AdTech Team, Account Executive）・安守（AdTech Team, Account Executive）・久野（Solutions architect）が担当しました

本記事は 2026 年 5 月 21 日 に公開された「 Building multi-tenant agents with Amazon Bedrock AgentCore 」を翻訳したものです。 マルチテナントのエージェント型アプリケーションを構築する SaaS (Software as a Service) プロバイダーは、セキュリティ、ガバナンス、応答精度といった一般的な懸念事項を超えたアーキテクチャ上の課題に取り組む必要があります。具体的には、テナント分離、テナント ID、テナントのオブザーバビリティ、データ分離、コスト配分、ノイジーネイバーの緩和などです。動作するデモから本番環境へのデプロイまでの隔たりを埋めるには、マルチテナント環境向けに設計されたインフラストラクチャが必要になります。Amazon Bedrock AgentCore は、AWS 上でエージェント型アプリケーションを構築、デプロイし、安全に運用するためのマネージドなサーバーレスサービスです。エージェントのデプロイと MCP サーバーのホスティングのための構成要素を提供し、ID 管理、メモリ、オブザーバビリティ、評価機能を標準で備えています。これらはすべて、マルチテナントのエージェントアーキテクチャを無理なく構築できるように設計されています。 本ブログシリーズの第 1 回となる本記事では、マルチテナントのエージェント型アプリケーションを設計する際の検討事項と、 Amazon Bedrock AgentCore で SaaS アーキテクチャの課題に取り組むために必要なフレームワークを解説します。 マルチテナントエージェントを構築する際の設計上の検討事項 強力な分離を備えた安全なマルチテナントのエージェント型アプリケーションを構築するには、図 1 に示すいくつかの主要コンポーネントにわたって、慎重なアーキテクチャ上の判断が必要です。各コンポーネントは、セキュリティとコンプライアンスの基準を維持しながら、テナント分離、運用効率、コスト最適化のバランスを取る必要があります。これらの設計上の検討事項は、3 つのテナント分離パターン ( サイロ、プール、ブリッジ ) を軸に展開され、これらを選択する際にはティアリング戦略が重要な検討要素になります。 図 1: マルチテナントエージェントの設計上の検討事項 続くセクションでは、マルチテナント化が各コンポーネントにどのような影響を与えるかを詳しく説明します。 1. エージェントランタイムのデプロイ: 専用と共有 マルチテナントのエージェントアーキテクチャにおける重要な判断は、テナントに対してエージェントランタイムをどのようにプロビジョニングするかです。テナントごとの 専用 ランタイムは、テナントごとに独立した実行環境をインスタンス化し、それぞれが固有のコンテナイメージ、プロセス空間、ライフサイクルを持ちます。このサイロ型のアプローチは、最も強力なノイジーネイバー対策となり、コンプライアンス監査を簡素化します。一方、 共有 ランタイムは、すべてのテナントのエージェントを同一のコンテナイメージとプロセスプール内でホストするため、インフラストラクチャのコストと運用負荷を抑えられますが、プロセス内でテナントコンテキストを厳密に伝播させる必要があります。 Amazon Bedrock AgentCore Runtime は、セッション分離された microVM ベースのコンピューティングによってこのトレードオフを解決します。AgentCore Runtime は、テナントごとに完全な仮想マシンを起動するコストやレイテンシーを伴わずに、セッション単位で軽量な microVM を起動します。各セッションは独自の永続ファイルシステムを持つため、エージェントはセッションスコープのファイルを読み書きし、中間的な計算結果を保持し、マルチステップのやり取りをまたいで状態を維持できます。これにより、セッション間でのデータ漏洩のリスクを軽減します。このアーキテクチャは、マルチテナントの MCP サーバー、エージェント、AG-UI サーバーをホストするのに適しています。テナントコンテキストは、カスタム HTTP ヘッダーを通じて分離された実行環境に流れ込みます。SaaS プラットフォームが AgentCore Runtime セッションにリクエストを転送する際、標準の認可トークンに加えて、テナント識別子、ティア、リージョンの設定、機能フラグ、エンタイトルメントといったテナント固有のメタデータを持つヘッダーを付与します。エージェントは呼び出し時にこれらのヘッダーを読み取ってテナントを完全に認識できるため、そのテナントのビジネスロジックに合わせたワークフローを実行し、ライセンスされたツールのみを呼び出し、ハードコードされたルーティングロジックなしにテナント固有の API エンドポイントを呼び出せます。 2. 共有モデル、ティア別モデル、ファインチューニング済みモデル ほとんどのマルチテナントデプロイでは、共有基盤モデル (FM) が推奨される出発点となり、単一のモデルを保守するだけで運用を簡素化できます。テナントは通常、テナントごとのカスタマイズなしに、自動的なモデル更新の恩恵を受けられます。テナントのティアに基づいてモデルを選択する方式 (ティア別モデル) では、柔軟性が得られ、テナントのティア間でコスト、パフォーマンス、精度のバランスを取れます。テナント固有の用語、規制対応、パフォーマンス SLA を必要とする特殊なユースケースでは、テナントごとにファインチューニングしたモデルが必要になりますが、運用が複雑になり、テナントごとのパイプラインが発生します。標準ティアには性能を抑えたモデルを、プレミアムなエンタープライズ顧客にはファインチューニング済みまたは高性能なモデルを使うハイブリッドなアプローチは、コスト効率とカスタマイズの要件のバランスを取れます。Amazon Bedrock は主要プロバイダーの大規模言語モデル (LLM) を幅広く提供しており、SaaS プロバイダーはテナントやティア固有のニーズに合ったモデルを選択できます。Amazon Bedrock のファインチューニングでは、独自のラベル付きデータセットを使って FM をカスタマイズし、ドメイン固有のタスクのパフォーマンスを高められます。Amazon Bedrock Custom Model Import を使えば、独自にファインチューニングしたモデルを持ち込み、Amazon Bedrock のマネージドインフラストラクチャを使ってデプロイできます。 3. ワークフロー: サイロ、プール、ブリッジパターン マルチテナントのエージェント型アプリケーションでは、各エージェントがテナントの要件とビジネスロジックに基づいて異なる一連のステップを実行する、柔軟なワークフロー管理が必要です。ワークフローは複数の仕組みで実装できます。手順を段階的にカプセル化する MCP ツールとして、ビジネスロジックのフローを定義する API エンドポイントとして、あるいはドメイン固有のワークフローパターンを組み込んだエージェントスキルとして実装できます。 テナント固有のワークフローを管理する主なパターンは 3 つあります。サイロパターンは、テナント固有の専用スキルを使い、ビジネスロジック、検証ルール、統合ステップを含む各テナントの完全なワークフローを、分離されたエージェントスキルに組み込みます。これにより最大限のカスタマイズと完全な独立性が得られますが、テナントごとに個別のスキル保守が必要です。プールパターンは、共有のエージェントスキルを使います。ブリッジパターンは、認証、ロギング、エラーハンドリングといった共通のワークフローステップを共有エージェントスキルに組み込み、ビジネスクリティカルなロジックについては実行時にテナント固有のスキルを呼び出します。その結果、再利用可能なインフラストラクチャとテナント固有のカスタマイズが共存します。 4. マルチテナント RAG 検索拡張生成 (RAG) システムでは、データ分離の判断が必要です。サイロパターンは、テナントごとに専用のベクトルデータベースを使い、最大限のセキュリティと完全なデータ分離を実現します。これは、規制業界や専用インフラストラクチャを必要とするエンタープライズ顧客に推奨されます。プールパターンは、メタデータベースのテナントフィルタリングと名前空間ベースのアクセス制御を備えた共有ベクトルデータベースを使い、多数の中小規模テナントにサービスを提供する SaaS プラットフォームでコスト効率の高い運用を実現します。検索操作には、テナント間でのデータ漏洩を防ぐため、自動的なテナントフィルターの注入と結果のサニタイズを含めるべきです。 Amazon Bedrock Knowledge Bases は、FM をデータソースに接続するフルマネージドな RAG 機能を提供し、データの取り込み、チャンキング、埋め込みの生成、ベクトルストレージを自動的に処理します。複数のベクトルデータベースに対応し、(メタデータフィルタリングを使って) サイロ型または共有型のベクトルデータベースを作成できます。 Amazon Bedrock Knowledge Bases でマルチテナント RAG アーキテクチャを実装する詳しい手順については、サイロ、プール、ブリッジのデプロイパターンを扱った Multi-tenant RAG with Amazon Bedrock Knowledge Bases と、共有ナレッジベース内でのメタデータベースのテナント分離を扱った Multi-tenancy in RAG applications in a single Amazon Bedrock knowledge base with metadata filtering を参照してください。 5. テナントコンテキスト、代理実行 (act-on-behalf) パターン、トークン伝播 マルチテナントの ID 管理では、サービスチェーン全体にわたってテナントコンテキストを慎重に扱う必要があります。完全な ID を表すテナントコンテキストと、リクエスト固有の状態は、信頼性が高く安全な仕組みを使ってすべてのアーキテクチャ層を流れる必要があります。実行パスが予測可能な決定論的なソフトウェア API とは異なり、AI エージェントは非決定論的で、自律的に動作する可能性があるため、セキュリティ上の考慮事項が重要な点で異なります。不正なエージェントや侵害されたエージェントは、ダウンストリームのサービスに対して不正な呼び出しを行い、認証情報の盗難、権限昇格、混乱する代理問題 (Confused Deputy) を引き起こす可能性があります。エージェントがユーザーの認証情報をすべて使って動作する (なりすまし) 場合、1 つの侵害されたエージェントが、すべてのダウンストリームシステムにわたるユーザー権限への完全なアクセスを得てしまいます。このリスクは、どのツールをいつどのようなパラメータで呼び出すかをエージェントが自律的に判断するようになるほど大きくなります。代理実行 (act-on-behalf) パターンが重要なのは、ユーザーとエージェントを明確に区別し、エージェントが操作ごとに明示的に制限・スコープされた権限でユーザーに代わって呼び出しを行うようにするためです。 テナントコンテキストは JSON Web Token (JWT) 内にエンコードし、3 つの次元を捉えます。セキュリティコンテキスト (標準クレーム: iss、sub、exp、aud)、テナントコンテキスト (tenant_id とテナント固有のスコープ)、リクエストコンテキスト (ビジネスロジック向けのドメイン固有の属性) です。このようにテナントコンテキストをエンコードすることで、マルチテナント運用の強力で柔軟な基盤が得られます。 セキュリティ上の影響が大きく異なる 2 つのパターンから選択します。なりすまし (Impersonation) はエージェントがユーザーの ID と権限をすべて使って動作できるようにするもので、実装は容易ですが、最小権限の原則に反し、セキュリティリスクを生みます。推奨されるアプローチである代理実行 (Act-on-Behalf、委譲) は、各サービス境界でトークンをスコープ制限された認証情報に変換し、エージェントを識別する act クレーム (OAuth 2.0 RFC 8693 に準拠) を付与する、真の委譲を実装します。AgentCore Identity の On-behalf-of トークン交換を使うと、エージェントや MCP サーバーなどのワークロードが、受信したユーザーアクセストークンを、ダウンストリームのリソースサーバー向けの新しいスコープ付きアクセストークンと交換できます。この交換では、ある対象者 (audience) 向けに発行されたトークンを、別のダウンストリームの対象者向けのトークンに直接変換するため、エージェントは追加の同意フローを発生させることなく、認証済みユーザーに代わって保護されたリソースにアクセスできます。交換されたトークンはエージェント自身の ID と元の呼び出し元の ID の両方を保持するため、リソースサーバーはホップごとにきめ細かなゼロトラスト認可を実施するために必要なシグナルを得られます。 6. MCP ツールと API に対するきめ細かなアクセス制御 マルチテナントのエージェント型アプリケーションでは、ポリシーを使った MCP サーバーアクセスの制限、ツール呼び出し層でのきめ細かなアクセス制御、データアクセス層でのテナント分離が必要です。認可層では、ポリシーが実行時にテナントコンテキストを評価して許可/拒否の認可判断を行い、トークンに埋め込まれた静的な権限だけに頼るのではなく、現在のテナントの状態に基づいて、ツール呼び出しを許可する前にテナントのクォータ、ティアベースの権限、使用制限を評価します。ポリシーストアを分離して一元化することで、再デプロイなしに動的な更新が可能になり、ポリシーのバージョン管理によって監査証跡とロールバックがサポートされます。AgentCore Policy は、ツールアクセスを許可する前に、定義されたポリシーに照らしてすべてのエージェントリクエストをインターセプトして評価し、ユーザー ID とツール入力パラメータに基づくきめ細かな制御を提供します。ポリシーは自然言語または Cedar で直接記述できます。 呼び出し層では、MCP サーバーがテナントのティア、機能フラグ、クォータ制限に基づいて、エージェントが呼び出す前に利用可能なツールをフィルタリングし、きめ細かなアクセス制御を実施します。ツールインターセプターは JWT クレームを検証し、リクエストを行うプリンシパルが特定の操作に対する適切な権限を持っていることを確認します。スキーマ変換機能は、テナントの設定とエンタイトルメントに基づいてツールのインターフェイスを適応させます。AgentCore Gateway は、API や AWS Lambda 関数をエージェント互換のツールに変換し、既存の MCP サーバーに接続することで、エージェントがツールに安全にアクセスできるようにします。Amazon API Gateway、OpenAPI スキーマ、Smithy モデル、Lambda 関数、MCP サーバーに対応しています。カスタムロジックにはゲートウェイインターセプターを通じてアクセス制御を実装することも、標準的な AWS スタイルのアクセス制御にはリソースベースのポリシーを使うこともできます。データアクセス層では、属性ベースのアクセス制御 (ABAC) ポリシーがデータアクセスのテナント分離を実施し、テナントの識別は JWT クレームを通じて行われます。ABAC ポリシーは AWS Identity and Access Management (IAM) の条件を使い、プリンシパルのタグと属性に基づいてデータアクセスを制限します。これにより、エージェントは行レベルセキュリティまたはストレージポリシーを通じて、自身のテナントコンテキストに一致するリソースのみをクエリできます。 7. メモリ: 階層的な名前空間による分離 マルチテナントのメモリ管理では、テナント間のデータ漏洩を防ぎながら、エージェントがコンテキストや学習した情報を保持できるよう、慎重なアーキテクチャ設計が必要です。メモリシステムは 5 つの論理レベルを実装すべきです。 グローバル (テナント横断で共有される知識) ストラテジー (エージェントタイプ固有のパターンと動作) テナント (テナントスコープの会話履歴と設定) ユーザー (テナント内の個々のユーザーコンテキスト) セッション (アクティブな会話のための一時的な短期メモリ) アクセス制御は、要求された名前空間パスに対してプリンシパルの ID を検証する属性ベースのポリシーを通じて分離を実施し、エージェントは許可されたスコープ内でのみメモリの読み書きができます。プールパターンは、運用効率とコスト効率のために、階層的な名前空間ベースの論理分離を備えた共有インフラストラクチャを使い、すべてのテナントデータを共通のデータストアに保存し、名前空間のプレフィックスに基づいて厳密にフィルタリングします。サイロパターンは、最大限の分離のためにテナントごとに専用のメモリストアをデプロイし、運用コストは高くなるものの、テナント間アクセスのリスクを低減します。実装にあたっては、テナントとユーザーの情報から複合識別子 (例: tenant_123:user_456) を構築し、テナントコンテキストをクレームやタグとして持つスコープ付き認証情報で認証し、すべてのメモリ操作に適切な名前空間パスをプレフィックスとして付けます。 AgentCore Memory は、グローバル、ストラテジー、テナント、ユーザー、セッションの各レベルにわたる階層的な名前空間分離を提供し、マルチターンの会話のための短期メモリと、セッションをまたいで永続する長期メモリの両方によって、コンテキストを意識したエージェント体験をサポートします。きめ細かなアクセスのために、 リソースベースのポリシー と 属性ベースのアクセス制御 に対応しています。 8. エージェントの ID、信頼、ディスカバリ エージェント型アプリケーションが組織の境界をまたいで外部のエージェントとやり取りするようになると、エージェント ID、エージェントの信頼、エージェントのディスカバリという 3 つの基本的な懸念事項が浮かび上がります。これらは関連していますが、それぞれ異なる問題に対処します。 エージェント ID は 「このエージェントは誰で、それを証明できるか」 に答えます。組織に紐づく、検証可能で一意な ID を確立します。 エージェントの信頼 は 「このエージェントを信頼すべきか」 に答えます。単一の認証情報ではなく、複数のシグナルの組み合わせに基づいて信頼性を評価します。 エージェントのディスカバリ は 「適切なエージェントをどうやって見つけるか」 に答えます。エンドポイントを事前に知らなくても、機能や所属によってエージェントを見つけられます。 AgentCore Identity によるエージェント ID Amazon Bedrock AgentCore Identity は、クラウドネイティブセキュリティで確立されたパターンであるワークロード ID として、エージェント ID を実装します。各エージェントは、組織の AWS アカウントと IAM インフラストラクチャに紐づいた、暗号的に検証可能な ID を受け取ります。エージェントは OAuth 2.0 フローを使ってユーザーに代わって AWS リソースやサードパーティ製ツールに安全にアクセスでき、AgentCore Identity は Okta、Microsoft Entra ID、Amazon Cognito といった既存の企業 ID プロバイダーと、ユーザーの移行を必要とせずに統合できます。 エージェントの信頼 ID だけでは、エージェントを信頼すべきかどうかには答えられません。業界はこの問題に積極的に取り組んでいます。 Agent Naming Service (ANS) v2 は、現在 IETF の Internet-Draft (策定中) であり、すべてのエージェント ID を DNS ドメイン名に紐づけます。クライアントは、Bronze (PKI)、Silver (PKI + DANE)、Gold (PKI + DANE + 透明性ログ) という 3 つの検証ティアから、取引のリスクに見合った保証レベルを選択できます。 AWS Agent Registry によるエージェントのディスカバリ Amazon Bedrock AgentCore を通じて利用できる AWS Agent Registry は、組織全体にわたってエージェント、スキル、MCP サーバー、カスタムリソースを発見するための一元化されたカタログを提供します。チームは再利用可能なエージェント機能を公開、バージョン管理、共有できます。利用者は、識別子やエンドポイントを事前に知らなくても、自然言語または構造化された検索を通じてエージェントを発見できます。組み込みのガバナンス制御により、利用者がレジストリにどのようにアクセスするか、レコードが発見可能になる前に承認を必要とするかどうかを決定します。まとめると、AgentCore Identity が ID の基礎的な証明を提供し、Agent Registry がディスカバリを解決し、ANS のような新興の信頼フレームワークがマルチシグナルによる信頼評価の隔たりを埋めることを目指しています。 9. テナントごとのコスト追跡とオブザーバビリティ 正確なマルチテナントのコスト配分には、エージェントの呼び出しごとにテナントタグ付きのメトリクスをロギングソリューションに送出し、入出力トークン、ツール呼び出し、実行時間を記録する、アプリケーションレベルの計装が必要です。テナントコンテキストを含む構造化ロギングにより、使用パターン、パフォーマンスのボトルネック、キャパシティプランニングを詳細に分析できます。AgentCore Observability は、Amazon CloudWatch を基盤とする OpenTelemetry 互換の統合により、エージェントのワークフローをリアルタイムで可視化し、エージェント実行の各ステップを詳細に可視化します。 10. ガードレール: コンテンツの安全性 マルチテナントのガードレールは、3 つの実施ポイントで安全性とコンプライアンスを実施します。前処理の入力ガードレールは、エージェントが処理する前にユーザー入力を検証し、悪意のあるプロンプトやプロンプトインジェクションをブロックし、ヘルスケアの HIPAA や金融の PCI-DSS といったテナント固有のコンプライアンス要件に基づいて PII をサニタイズします。後処理の出力ガードレールは、エージェントの応答について事実の正確性を検証し、ハルシネーションを検出し、フォーマットの準拠を確認し、テナント境界を越えた機密データの漏洩をスキャンします。ガードレールはテナントまたはティアごとに適用でき、毒性検出、コンテンツフィルタリング、カスタムのブロック対象用語の設定を提供します。オブザーバビリティのメトリクスでは、トリガー率、カテゴリ別のブロックされたリクエスト、誤検知率を追跡して継続的な改善につなげます。Amazon Bedrock Guardrails は、拒否トピック、コンテンツフィルター、単語フィルター、機密情報の編集に対する設定可能なポリシーを備えたコンテンツフィルタリングと安全性制御を提供し、すべてのモデルとのやり取りにわたって責任ある AI のデプロイをサポートします。 これら 10 個のコンポーネントは、マルチテナントエージェントを設計するための包括的なフレームワークとなります。続くセクションでは、これらの中核コンポーネントを念頭に置きながら、AgentCore でのサイロ、プール、ブリッジの各モデルの実装を解説します。 AgentCore でのサイロモデルの実装 次の図に示すように、 サイロモデル では、各テナントが専用の Bedrock AgentCore Runtime、Bedrock AgentCore Gateway、Bedrock AgentCore Memory を持ち、それぞれが個別の AWS IAM 境界の背後にスコープされた、完全に分離されたスタック内で動作できます。メモリには長期、短期、エピソード記憶など複数の分類があり、テナントの要件に応じて設定する必要があります。 主要なアーキテクチャコンポーネント サイロ化されたエージェント層 – テナント固有の権限のために個別の IAM 実行ロールでデプロイされた専用の AgentCore Runtime。 サイロ化されたゲートウェイ – MCP を使ったツールオーケストレーションのための専用 AgentCore Gateway。実行ロールに基づいてデータ層へのアクセスがスコープされます。 サイロ化されたエージェントメモリ – 階層的な名前空間分離を備えた専用の AgentCore Memory。すべての名前空間パスにテナント ID を含める必要がなくなります。エージェントは IAM ロールを通じてテナント固有のメモリにアクセスします。 サイロ化されたデータ層 – 最大限のデータ分離のための専用のツール、ナレッジベース、データベース、バックエンドリソース。 リクエストフロー 認証 – ユーザーは ID プロバイダーを使って認証し、テナントコンテキスト (テナント ID とサブスクリプションのティア) を含む JWT トークンを受け取ります。 SaaS アプリケーションプロキシによるルーティング – SaaS アプリケーションプロキシは、テナントコンテキストに基づいてどのエージェントを呼び出すかを決定します。これには、テナントとエージェントのデプロイの間にマッピング設定を確立する必要があり、これは通常 SaaS コントロールプレーンの一部となる機能です。プロキシは、アプリケーションレベルのリクエストを AgentCore Runtime の API 呼び出し (InvokeAgent) に変換し、テナントの JWT トークンを付与します。 エージェントの実行 – AgentCore Runtime は AgentCore Identity を使って JWT を検証し、分離された microVM セッションを作成し、エージェントの推論を開始します。さらに、AgentCore Identity の JWT オーソライザーでカスタムクレームを設定することで、テナント ID がこのエージェントの呼び出しを認可されているか (例: 「tenant_id = テナント A の場合のみ許可」) を検証します。エージェントは、ランタイムの IAM 実行ロールを使ってテナント固有の AgentCore Memory にアクセスします。 AgentCore Gateway を使ったツールアクセス – エージェントがツールを呼び出す必要がある場合、特定のテナントの MCP ツールにアクセスするようにスコープされた 専用の AgentCore Gateway を呼び出します。ゲートウェイは次の処理を行います。 AgentCore Identity を使って JWT を検証します。 検証済みのトークンからテナントコンテキストを抽出し、カスタムインターセプターを使って、ゲートウェイが対象のテナントにマッピングされていることを確認します。 サイロ化されたテナント固有のバックエンドリソース (API、データベース、ナレッジベース) と統合します。 応答フロー – ツールの応答はゲートウェイを通じてエージェントに戻り、エージェントは推論を完了します。サイロ化されたエージェントは、SaaS アプリケーションプロキシに返す前にテナント固有のフォーマットを適用します。プロキシは応答をユーザーに返します。 サイロパターンは、各顧客のエージェントセッション、ツールアクセス、メモリが完全に封じ込められ、処理のきっかけとなったアラートを発した顧客にコストが直接配分されるように設計されています。トレードオフは、各顧客がリソースを共有するのではなく専用リソースを実行するため、運用負荷が高くなる点です。しかし、セキュリティが重要でコンプライアンスに敏感なワークフローでは、影響範囲が限定されることから、これが適切な選択になります。 図 2: AgentCore によるサイロモデル AgentCore でのプールモデルの実装 次の図に示すように、 プールモデル では複数のテナント間でリソースを共有できるため、リソース利用率を最大化し、運用効率を実現するアーキテクチャを設計できます。 主要なアーキテクチャコンポーネント プール化されたエージェント層 – 複数のテナント間で共有される AgentCore Runtime とエージェントロジック。 プール化されたゲートウェイ – MCP を使ったツールオーケストレーションのための一元化された AgentCore Gateway。 プール化されたエージェントメモリ – テナントコンテキストに基づいて分割された共有 AgentCore Memory。 プール化されたデータ層 – 共有のツール、ナレッジベース、データベース、バックエンドリソース。 プール化された ID 管理 – JWT ベースのテナントコンテキスト伝播を備えたプール化された ID プロバイダー。 リクエストフロー 認証 – ユーザーは ID プロバイダーを使って認証し、テナントコンテキスト (テナント ID とサブスクリプションのティア) を含む JWT トークンを受け取ります。 SaaS アプリケーションプロキシによるルーティング – SaaS アプリケーションはパススルーとして機能し、テナントコンテキストを含む入力リクエストを、プール化された AgentCore Runtime で動作するエージェントにルーティングします。SaaS アプリケーションプロキシは、アプリケーションレベルのリクエストを AgentCore Runtime の API 呼び出し (InvokeAgent) に変換し、テナントの JWT トークンを付与します。 エージェントの実行 – AgentCore Runtime は AgentCore Identity を使って JWT を検証し、分離された microVM セッションを作成し、JWT からテナントコンテキストを抽出してエージェントの推論を開始します。エージェントは、名前空間ベースの分割 (例: actor_id: 「tenant-a:user-123」) を使ってテナントスコープの AgentCore Memory にアクセスします。 AgentCore Gateway を使ったツールアクセス – エージェントがツールを呼び出す必要がある場合、汎用的なルーティングではなく MCP ツールのオーケストレーション専用に設計された プール化された AgentCore Gateway を呼び出します。ゲートウェイは次の処理を行います。 AgentCore Identity を使って JWT を検証します。 検証済みのトークンからテナントコンテキストを抽出します。 ツール呼び出しをプール化されたバックエンドリソース (API、データベース、ナレッジベース) にルーティングします。 テナントスコープの認証情報と設定を通じてツールレベルの分離を実施します。 横断的な関心事に対してポリシーの実施とインターセプターを適用します。 応答フロー – ツールの応答はゲートウェイを通じてエージェントに戻り、エージェントは推論を完了します。エージェントの応答はランタイムを通じて、セラー (販売者) が運用するプロキシに戻り、プロキシはユーザーに返す前にテナント固有のフォーマットを適用します。 プールモデルは非常に効率的で、多数の小規模テナントを抱える場合には唯一の選択肢になることもあります。トレードオフは、きめ細かなアクセス制御のテストをより厳密に行う必要があり、コストをテナントに配分するためにより多くの計装が必要になる点です。 図 3: AgentCore によるプールモデル AgentCore でのブリッジモデルの実装 ブリッジモデル (ハイブリッドモデル) は、サイロとプールのデプロイパターンの戦略的な中間に位置します。このアプローチは、共有インフラストラクチャのコスト効率と、分離されたデータリソースのセキュリティ上の利点を組み合わせます。 ニーズに応じて、ブリッジパターンはさまざまな方法で実装できます。 プレミアムティアのテナントにはサイロ化された AgentCore Runtime/ゲートウェイ/ツール/メモリを、標準ティアにはプール化された共有の AgentCore Runtime/ゲートウェイ/ツール/メモリを使う サイロ化されたランタイムと、プール化されたゲートウェイ/ツールおよびメモリを使う その他 考え方は、特定のテナント分離パターンに縛られるのではなく、各層やコンポーネントごとにテナンシーを選択できるようにすることです。このアプローチは、実装に応じて両方のアプローチの利点を組み合わせます。たとえば SOC アナリストのユースケースでは、各調査が独自の分離された microVM で実行されるため、プール化されたエージェントランタイムがエージェントをホストして推論を行う一方で、ゲートウェイをサイロ化してメール API のやり取りやその他のダウンストリームのテナントリソースを処理する、といった構成が考えられます。 図 4: AgentCore によるブリッジモデル (パターン 1) 図 5: AgentCore によるブリッジモデル (パターン 2) 次のステップ 本記事では、マルチテナントエージェントを構築するための基礎的な概念を取り上げました。今後の記事では、これらの概念の実装面をより深く掘り下げます。具体的には、設計上の検討事項のセクションで概説したコンポーネントを組み込みながら、プールとサイロの両方のデプロイモデルのエンドツーエンドの実装を順を追って解説します。 まとめ 本番環境に対応したマルチテナントのエージェント型アプリケーションを構築するには、機能する AI エージェントだけでは不十分です。テナント分離、ID 管理、コスト配分、そしてあらゆる層でのセキュリティに対処する、包括的なアーキテクチャのアプローチが求められます。Amazon Bedrock AgentCore は、これらの課題に取り組むために必要な基礎的なプリミティブ (基本要素) を提供し、特定のティアリング戦略やコンプライアンス要件に合わせて調整できる、サイロ、プール、ブリッジの各モデルを通じた柔軟なデプロイパターンを提供します。専用インフラストラクチャを必要とするエンタープライズ顧客にサービスを提供する場合でも、数百もの小規模テナントにわたってコストを最適化する場合でも、AgentCore の統合された Runtime、Gateway、Memory、Identity、Observability の各コンポーネントを使えば、車輪の再発明をせずに、安全でスケーラブルなマルチテナントのエージェント型ワークフローを構築できます。これらのプリミティブは連携して、テナントのデータ分離、スコープされたツールアクセス、正確なコスト配分、セキュリティ境界の維持を支援し、マルチテナントエージェントアーキテクチャの複雑さを、SaaS ビジネスの成長に合わせてスケールする、管理しやすく本番環境に対応したソリューションへと変えます。 Amazon Bedrock AgentCore でこれらのマルチテナントエージェントを構築する実践的な体験のために、 マルチテナントエージェントのワークショップ をぜひお試しください。 著者について Dhawal Patel AWS のプリンシパル生成 AI テクニカルリードです。大企業から中規模のスタートアップまで、さまざまな組織と協力し、エージェント型 AI、ディープラーニング、分散コンピューティングに関する課題に取り組んできました。 Anubhav Sharma AWS のプリンシパルソリューションアーキテクトで、ビジネスクリティカルなアプリケーションの設計と構築に 20 年以上携わってきました。独立系ソフトウェアベンダー (ISV) と緊密に連携し、AWS 上での SaaS ソリューションの構築、デプロイ、運用を支援しています。近年は、エージェント型 AI への変革を通じて、お客様が製品やワークフローを再構築できるよう支援しています。 Aswin Vasudevan AWS のセキュリティ・ISV 担当シニアソリューションアーキテクトです。生成 AI とサーバーレスアーキテクチャの大ファンで、お客様と協力してビジネス価値を生み出すソリューションを構築することを楽しんでいます。 Sahil Thapar AWS のプリンシパルソリューションアーキテクトで、ISV のお客様と協力して、AWS クラウド上で高可用性、スケーラブル、かつ回復力のあるアプリケーションを構築しています。コンテナ、機械学習、生成 AI を専門とし、企業が本番環境品質のソリューションを設計できるよう支援しています。 Ujwal Bukka Amazon Web Services のシニアパートナーソリューションアーキテクトで、スケーラブルでエンタープライズ品質のアプリケーションの構築と提供に 20 年以上携わってきました。独立系ソフトウェアベンダー (ISV) と協力し、AWS 上でのマルチテナント SaaS ソリューションの設計、立ち上げ、運用を支援しています。また、エージェント型 AI を使って ISV の製品やワークフローを近代化できるよう、AWS 上でのソリューション設計から戦略策定、市場投入の実行まで幅広く支援しています。Ujwal は、実践的なワークショップ、技術コンテンツ、効果の高いイネーブルメントプログラムを通じてパートナーの成功を後押しすることに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kensuke Fukumoto がレビューしました。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 いよいよ AWS Summit Japan 2026 が今月の6 月 25 日（木）・26 日（金）の 2 日間に幕張メッセで開催されますね！日本最大級の「AWS を学ぶイベント」として、基調講演に加え、エージェント型 AI や機械学習、セキュリティ、アプリケーションモダナイゼーションまで、260 を超えるセッションや事例が揃います。 今回の AWS Summit では、私も Windows 依存のレガシーなアプリケーションを、生成 AI を活用していかに効率よくモダナイズするかをテーマにしたセッション ( セッション MAM331 ) で登壇します。AWS Transform for .NET を起点に、SQL Server から Amazon Aurora PostgreSQL へのデータベース移行、Linux コンテナ化、さらに Kiro を活用した加速アプローチまで、実際の事例とデモを交えてご紹介します。移行の「先送り」に悩んでいる方は、ぜひお越しください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年6月1日週の主要なアップデート 6/1(月) Amazon Bedrock で OpenAI の GPT-5.5、GPT-5.4、Codex が一般提供開始 Amazon Bedrock で OpenAI の最先端モデルである GPT-5.5 および GPT-5.4 が一般提供 (GA) を開始しました。GPT-5.5 は OpenAI の最も高性能なモデルで、自律的なコーディング、データ分析、複数ステップのタスク実行に優れています。同時に、AI コーディングエージェント Codex も Bedrock 経由で利用可能になり、Visual Studio Code、JetBrains、Xcode との統合を通じてソフトウェア開発を支援します。料金は OpenAI の直接提供と同額で、AWS の既存コミットメントにカウントされます。なお、本記事執筆時点では、これらのモデルは Bedrock マネジメントコンソールのモデルカタログにはまだ表示されておらず、OpenAI Responses API 経由 (bedrock-mantle エンドポイント) で利用可能です。GPT-5.5 は US East (オハイオ)、GPT-5.4 は US East (オハイオ) と US West (オレゴン) の 2 リージョンからの提供開始となっています。 Amazon Bedrock AgentCore Identity で AWS Secrets Manager の既存シークレットを利用可能に Amazon Bedrock AgentCore Identity で、AWS Secrets Manager に保存された既存のシークレット ARN を Credential Provider から直接参照できるようになりました。従来のサービス管理型シークレットでは、作成時にリソースタグを適用したり、カスタマーマネージドキー (CMK) で暗号化したりすることができませんでした。この機能により、組織のガバナンスポリシーに従ってシークレットを作成・管理し、CMK、タグ戦略、自動ローテーション、リソースポリシーを適用した上で、AgentCore Identity から参照できます。東京リージョンを含む、14 のリージョンで一般提供が開始されています。 Amazon Quick が MCP 接続で VPC 接続をサポート Amazon Quick が、プライベートネットワーク上でホストされた Model Context Protocol (MCP) サーバーに Amazon Virtual Private Cloud (VPC) 経由で接続できるようになりました。これまで MCP サポートはパブリックインターネット経由でアクセス可能なサードパーティホストサーバーに限定されていましたが、今回のアップデートにより、企業は Amazon EC2、AWS Fargate、Amazon Bedrock AgentCore などのプライベートネットワーク上で動作する MCP サーバーを、インターネットに公開することなく Quick に接続できます。この機能は Enterprise エディションにて利用可能です。 6/2(火) Amazon RDS for SQL Server が Bring Your Own Media をサポート Amazon RDS for SQL Server が Bring Your Own Media (BYOM) のサポートを開始しました。BYOM により、Microsoft の License Mobility プログラムを通じて既存の SQL Server ライセンスと Software Assurance を RDS で再利用できます。ユーザーは SQL Server の RTM (Release To Manufacturing) インストールメディアを S3 にアップロードし、AWS は SQL Server ライセンス費用を請求せず、インフラストラクチャ費用 (コンピュート、ストレージ、I/O、データ転送) と Windows OS 費用のみを課金します。これにより、オンプレミスや EC2 で SQL Server を運用している企業が、追加ライセンス費用なしでマネージドサービスへ移行できます。 Amazon ElastiCache for Valkey の 耐久性機能のサポートを発表 Amazon ElastiCache for Valkey が耐久性 (durability) 機能をサポートしました。この機能により、マイクロ秒の読み取りレイテンシを維持しながら、データ損失を許容できないワークロードに ElastiCache を利用できます。Multi-AZ transactional log を使用してデータを複数のアベイラビリティゾーン (AZ) に永続化し、障害時の高速フェイルオーバー、データベースリカバリ、ノード再起動を実現します。Synchronous writes (同期書き込み) と Asynchronous writes (非同期書き込み) の 2 つのオプションから選択でき、データ保護とパフォーマンスのバランスを調整できます。Valkey 9.0 以降で利用可能で、すべての AWS 商用リージョン、AWS 中国リージョン、AWS GovCloud (US) リージョンで提供されます。詳細は こちらのブログ をご参照ください。 AWS Config が internal service linked rules をサポート開始 AWS Config は internal service linked rules のサポートを開始しました。この機能により、AWS サービス（AWS Security Hub CSPM など）が AWS Config managed rules を使用して AWS リソースの設定を評価できるようになります。Internal service linked rules は既存の service linked recorder 機能を拡張し、AWS サービスがサービス固有の機能として AWS Config のルール評価を展開・管理できるようにします。評価結果はルールを展開した AWS サービスに直接配信され、AWS Config から顧客への課金は発生しません。これらのルールは既存の顧客管理 AWS Config レコーダーおよびルールとは独立して動作するため、顧客は引き続き AWS Config をインベントリ、ガバナンス、コンプライアンス、監査のユースケースに使用できます。 6/3(水) AWS Config が 9 つの新しいリソースタイプに対応 AWS Config が Amazon Bedrock、Amazon Bedrock AgentCore、Amazon SageMaker の 3 つのサービスにわたって 9 つの新しいリソースタイプに対応しました。これにより、生成 AI ワークフロー (Bedrock Flows)、エージェント評価機能 (Amazon Bedrock AgentCore)、大規模 ML インフラ (SageMaker HyperPod) などの設定を継続的に記録・監査できるようになります。すべてのリソースタイプの記録を有効にしている場合、これらは自動的に追跡対象に含まれます。新しいリソースタイプは Config Rules と Config Aggregator でも利用可能です。 Amazon SageMaker Unified Studio が 12 言語でのローカライズ体験をサポート Amazon SageMaker Unified Studio のユーザーインターフェースが日本語を含む 12 言語に対応しました。グローバルチームのデータエンジニア、アナリスト、データサイエンティストが、最も使いやすい言語でナビゲート、構築、コラボレーションできるようになり、生産性が向上します。ブラウザの言語設定から自動検出されるほか、プロフィール設定で手動変更も可能です。 AWS Step Functions が AgentCore を活用したエージェント推論ステップに対応 AWS Step Functions が Amazon Bedrock AgentCore のマネージドハーネスと統合され、ワークフロー内に AI エージェントの推論ステップを追加できるようになりました。Workflow Studio からハーネスを直接作成でき、ドキュメント分類や非構造化フォームの要素抽出など、推論タスクをワークフローに組み込めます。複数のエージェントを並列または順次実行でき、重要なアクションの前に承認ステップを追加できます。実行履歴にはエージェントの入出力、トークン使用量、実行時間が記録され、CloudWatch にターンごとの推論詳細へのリンクが表示されます。 6/4(木) Amazon Bedrock が OpenAI および Anthropic 互換 API に最適化されたコンソールを発表 Amazon Bedrock は、OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages API に対応した新しいコンソール体験を発表しました。このコンソールは、bedrock-mantle エンドポイントでの利用に最適化されており、実験、反復、スケールという実際の開発フローに沿ったワークフローを提供します。プロジェクト単位で作業を整理し、モデルカタログの一覧比較、評価の実行、使用状況インサイトの確認を 1 つのビューで完結できます。また、プロジェクト固有のモデル ID やエンドポイント URL が自動的に埋め込まれたコードサンプルを生成するため、開発者はコンソールからコードをコピーしてそのまま実行できます。 Amazon Cognito がマルチリージョンレプリケーションに対応 Amazon Cognito User Pool でマルチリージョンレプリケーション機能が利用可能になりました。この機能により、ユーザー認証情報や User Pool 設定をセカンダリリージョンにほぼリアルタイムで同期し、リージョン障害時にもサインイン済みユーザーが再認証なしでアプリケーションを利用できます。Essentials または Plus プランのアドオンとして提供され、東京リージョンを含む 16 リージョンで利用できます。 Amazon SageMaker Data Agent がビジネスコンテキストを会話に統合 Amazon SageMaker Data Agent が SageMaker Catalog のビジネスコンテキストとメタデータと統合し、技術的なテーブル名ではなくビジネス用語を使用してデータセットを発見し、より正確な SQL および Python コードを生成できるようになりました。この統合により、Collibra、Atlan、Alation から同期されたものを含む、企業が数ヶ月かけて SageMaker Catalog に蓄積したビジネスコンテキストを活用できます。データ実務者は「顧客維持率を計算して」「顧客離反に関するデータは何がある？」といった質問が可能になり、初回試行時からより正確なコード生成とデータガバナンスの尊重を実現します。 6/5(金) AWS MCP Server が cross-account および cross-role アクセスに対応 Agent Toolkit for AWS の一部である AWS Model Context Protocol (MCP) Server において、cross-account および cross-role アクセス機能を発表しました。この機能により、Kiro、Claude Code、Codex などの AI コーディングエージェントを使用する開発者は、セッションの再起動なしに単一のセッション内で複数の AWS アカウントと AWS Identity and Access Management (IAM) ロールを横断して作業できるようになります。従来はプロファイルを切り替えるたびに AI コーディングセッションを停止し、ローカルの AWS 認証情報を更新し、MCP サーバーを再起動する必要がありました。現在は、AWS MCP Server を使用する AI エージェントが各コマンドでプロファイルを指定できるため、アカウントとロールをシームレスに切り替えられます。 Amazon ECS with AWS Fargate が 32vCPU 構成をサポート開始 Amazon ECS with AWS Fargate が 32 vCPU の新しいコンピュート構成をサポートしました。従来の最大構成である 16 vCPU から倍増し、60 GiB、120 GiB、244 GiB の 3 つのメモリオプションを提供します。x86 と ARM の両アーキテクチャに対応し、Linux 環境で利用できます。この拡張により、AI 推論、大規模データ処理、ハイパフォーマンスコンピューティング (HPC) などの高負荷ワークロードを、サーバー管理なしで実行できるようになりました。Fargate と Fargate Spot の両方のキャパシティプロバイダーで利用可能で、既存の Compute Savings Plans が自動適用されます。 Amazon Bedrock AgentCore Runtime に対話型シェル (インタラクティブターミナル) 機能を導入 Amazon Bedrock AgentCore Runtime に新しい InvokeAgentRuntimeCommandShell API が追加され、WebSocket 経由で実行中のエージェントセッションに対話型シェルアクセスが可能になりました。この API は PTY-backed terminal (疑似端末) を提供し、カラー出力、タブ補完、Ctrl+C 処理、ターミナルリサイズ、ネットワーク切断時の自動再接続に対応します。既存の InvokeAgentRuntimeCommand API (ワンショット実行) と異なり、シェルセッションは環境変数、作業ディレクトリ、コマンド履歴を永続的に保持します。Claude Code、OpenAI Codex、Amazon Kiro などのコーディングエージェントをホスティングする開発者にとって、ローカルターミナルと同様の操作感でエージェント環境を操作・デバッグできるようになります。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。