みなさんこんにちは！関西で製造業のお客様を中心に技術支援をしているソリューションアーキテクトの河井です。今年も AWS Summit Japan 2026 の季節がやってまいりました！会場は千葉県の幕張メッセです。今年も製造業向けの展示を出展する予定ですので、ぜひ遊びに来てください。AWS Summit の概要と製造ハイライト展示の見どころは こちらのブログ に掲載していますのでご覧ください。 本ブログではハイライト展示内の Supply Chain ブースの展示について紹介します。今回のブースでは、サプライチェーンの意思決定を AI で加速する 2 つのアプローチを展示します。1 つ目は AWS のサービスを組み合わせて作る AI エージェントを活用したアプリケーション で、マーケットサインを起点に需要予測から生産計画提案までを一気通貫で実行するデモです。2 つ目は SaaS 形態でサプライチェーンの Decision Intelligence (DI) をエージェントとして提供する Amazon Connect Decisions で、サプライチェーン上で発生している問題を自動検知し、AI が根本原因の分析と推奨アクションを提示するマネージドサービスです。それぞれ異なるアプローチでサプライチェーンの意思決定を加速する様子をご覧いただけます。 製造業が直面するサプライチェーンの課題 製造製造業のサプライチェーンを管理する方々の頭を悩ませる課題は多くありますが、ざっくりとまとめると下記のように分類できるのではないでしょうか。 需要変動の兆候を掴んでも、定量化できない：  政策発表や市場トレンドの変化を感じても、「実際にどれだけ需要が増えるのか」を定量的に見積もれません。結果として対応が後手に回ります。 需要変動への対応に時間がかかる：  需要が急変したとき、在庫・生産キャパ・部品調達の見通しを確認するために、営業、生産管理、調達部門など様々な部署からの情報が必要で数日かかります。 物流の不確実性： 海上交通を使う場合はコンテナ不足・港湾混雑など予期せぬ問題が発生する可能性があります。そのほかにも地政学的リスクなどにより、輸送のリードタイムが突然倍増し、供給計画が崩れます。 在庫配分の判断の難しさ： 限られた在庫を複数の製品ラインにどう再配分するか、人手では即座に最適解を出せません。 これらの課題に共通するのは、「 情報はあるのに、それを統合して迅速に意思決定する仕組みがない 」 ということです。 AWS サービスを組み合わせた アプリケーションの概要 本デモでは、架空のドローンのメーカー「AnyCompany」（横浜工場）を題材に、マーケットサイン（政府のインフラ点検プロジェクト閣議決定）を起点として、AI エージェントに分析を依頼するだけで以下を一気通貫で提示する仕組みを体験いただけます。 需要予測 — 過去の受注履歴と公共入札件数から、今後 6 ヶ月の需要を予測 在庫・供給状況の可視化 — 現在の在庫水準、サプライヤー別の供給力、コンテナ不足の影響を即座に一覧化 増産シナリオ別の生産計画提案 — 需要予測の各シナリオに対して、3 製品間の生産配分最適化と売上影響を計算 総合提案 — 時間軸別（即時/短期/中期）の具体的なアクションリストを提示 従来なら数日かかる「需要変動への対応策立案」を、AI エージェントへの一言の依頼で数分に短縮します。 （需要予測） （増産シナリオ別の生産計画の提案） AI でどのように解決するのか このデモのアプローチは 3 つのステップで構成されています。 ステップ1：不確実な需要を「数字」に変える 市場の変化を感じても「増えそうだ」という感覚のままでは動けません。時系列基盤モデルが過去の受注履歴と外部指標（公共入札件数）を組み合わせて、「月 180 台（+50%）」のように確率区間付きで需要を予測します。これにより、感覚ではなくデータに基づく判断が可能になります。 ステップ2：制約の中で「何ができるか」を即座に計算する 需要が増えても、部品の供給制約や在庫水準によって実際に対応できる範囲は限られます。AI エージェントが在庫・供給データを取得し、複数製品間の生産配分を利益率・季節需要・納期制約を考慮して最適化します。 ステップ3：段階的な対応策を提示する 「まず生産配分の見直しで即座に対応（追加コストゼロ）→ 需要が上振れしたら追加調達」という段階的な提案により、過剰投資を避けつつ機会損失も防ぎます。AI エージェントがサプライヤー情報や過去の調達実績を検索し、具体的なコスト・リードタイムを含めた調達オプションを提示します。 使用している技術要素 Amazon Bedrock AgentCore Amazon Bedrock AgentCore は、AI エージェントの構築・デプロイ・運用を統合的に提供するプラットフォームです。エージェントにツール・メモリ・データを装備し、複雑なワークフローを処理させることができます。インフラ管理は不要で、セキュアかつスケーラブルなランタイム上でエージェントを実行できます。本デモでは、AgentCore 上に構築したエージェントが担当者の自然言語での依頼を理解し、需要予測の呼び出し → 在庫データの取得 → シナリオ計算 → Knowledge Base 検索を自律的にオーケストレーションします。従来であれば複数部門にまたがっていた確認作業を、1 つのエージェントが一気通貫で実行します。 Chronos-2（時系列基盤モデル） Chronos-2 は Amazon が開発した時系列予測の基盤モデルです。単変量・多変量、さらに影響を及ぼすその他の要因（共変量）を含む予測タスクを、追加学習なしで処理できます。グループアテンション機構により、複数の関連する時系列間で効率的に情報を共有し、高精度な予測を実現します。本デモでは、産業用ドローンの月次受注数（ターゲット系列）とインフラ点検関連の公共入札件数（共変量）を入力として、今後 6 ヶ月の需要を確率区間付きで予測します。単なるトレンド延長ではなく、外部要因の影響を反映した予測が可能です。 Amazon Bedrock Knowledge Bases Amazon Bedrock Knowledge Bases は、RAG（Retrieval Augmented Generation）ワークフローをフルマネージドで提供する機能です。データの取り込みから検索、プロンプト拡張までを、カスタム統合やデータフロー管理なしで実現します。本デモでは、サプライヤー別の基本情報（所在地・供給シェア・リードタイム）、部品仕様、過去の調達実績（増量交渉の実績・コスト増の目安）、航空便切り替え時のコスト情報を格納しています。AI エージェントがシナリオ分析の中で調達オプションを提示する際に、これらの情報を検索して正確な根拠に基づいた提案を行います。 これらの技術要素が同一プラットフォーム（AWS）上で動作するため、予測結果をエージェントに渡すための API 変換レイヤーや、Knowledge Bases へのアクセスのための認証統合を個別に設計する必要がないのも良いところです。IAM による統一的なアクセス制御のもと、エージェントが各サービスをネイティブに呼び出せます。 （アーキテクチャ図） ここからは、サプライチェーンの問題検知と対応を継続的に行うためのマネージドサービス、Amazon Connect Decisions を紹介します。 Amazon Connect Decisions コンセプト：発生した問題を即座に捉え、原因分析から対応策までを自動で提示する サプライチェーンの現場では、在庫不足・供給遅延・需要との乖離といった問題が日々発生します。これらの問題に対して、従来は担当者がデータを突き合わせて原因を調査し、対応策を検討する必要がありました。Amazon Connect Decisions は、この「問題の検知 → 原因分析 → 対応策の提示」という一連の流れを AI で自動化します。 検知（Detection） — あらかじめ定義したメトリクスとルール（例：「在庫カバー日数が 15 日を下回ったら」）に基づいて、サプライチェーン上の問題を自動的に検知します。 洞察（Insight） — 検知された問題に対して、AI が根本原因を分析します。例えば「2025 年に発注した入庫注文 2 件（計 5,169 EA）が未受領のまま 200 日以上経過し、補充パイプラインが完全に途絶している」といった具体的な原因特定を行います。 推奨アクション（Recommendation） — 分析結果に基づき、「発注書作成：17,105 EA」「サプライヤーパフォーマンスレビューの実施」「未受領注文の調査」といった具体的な対応策を優先度付きで提示します。 主な機能 Insights（問題の検知と分析）： ビジネスルールに基づいてサプライチェーンの問題を検知し、 AI が根本原因の分析と推奨アクションを生成します。ユーザーは自社のオペレーションを記述した S&OP を AI に読み込ませて「ガイドライン」を設定します。 Demand Planning（需要予測）： Amazon が培ったノウハウを組み込んだ AI/ML モデルが、過去の販売実績から自動的に需要予測を生成します。少ない履歴データでも初日から利用可能です。営業見込み・顧客コミットメントなど複数部門からのインプットを 1 つの合意予測（Consensus Plan）に統合する仕組みも備えており、AI Teammate（自然言語インターフェース） に「なぜこの予測値になったのか」と聞いて根拠を確認することもできます。 Supply Planning（供給計画）： 需要予測や受注データをもとに、素材の利用可能性・リードタイム・生産キャパシティ・倉庫スペースといった現実の制約を考慮した供給計画（生産・調達スケジュール）を生成します。計画の定期実行スケジュールも設定でき、プランナーが計画を調整・確定したうえで下流プロセスへ公開できます。 （ Insights の検出） （根本原因と推奨アクション） まとめ サプライチェーンの意思決定には、大きく 2 つの局面があります。1 つは市場の変化や突発的な事象に対して「次にどう動くか」を素早く判断する局面。もう 1 つは、日々発生する在庫不足や供給遅延といった問題に対して「いま何が起きていて、どう対処すべきか」を把握し続ける局面です。本ブースでは、前者に対しては AI エージェントがマーケットサインから需要予測・生産計画提案までを一気通貫で実行するデモを、後者に対しては Amazon Connect Decisions が問題を自動検知し、根本原因の分析から推奨アクションまでを提示するデモをお見せします。 注文を待ってから動くのではなく、不確実な時点から先手を打つ。問題が大きくなってから調査するのではなく、発生した瞬間に原因と対応策を手にする。この 2 つのアプローチで、ビジネスのアジリティを強化します。あなたのビジネスへの次の装備となるこの AWS Summit のサプライチェーンブースのデモを、ぜひ体験しに来てください。 著者について 　河井信彦（Nobuhiko Kawai） アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト セキュリティベンダーを経て AWS Japan に入社し、エンタープライズ技術本部でソリュー ションアーキテクトとして活動中。関西の製造業のお客様を中心担当している。趣味はサッカーとフットサル。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が実施する「 生成 AI 実用化推進プログラム 」は、生成 AI の活用を支援する取り組みです。お客様のニーズに合わせ、生成 AI による価値創出のため戦略策定に取り組む方向けの「戦略プランニングコース」、カスタムモデルによる課題解決に取り組む方向けの「モデルカスタマイズコース」、公開モデルによるビジネス課題解決を狙う方向けの「モデル活用コース」をご用意しております。 その「生成 AI 実用化推進プログラム」の参加者や、GENIAC（Generative AI Accelerator Challenge）の関係者、生成 AI に関心を持つ企業が一堂に会する「生成 AI Frontier Meetup」が、2026 年 5 月 28 日に開催されました。2024 年 11 月の 第 1 回 、2025 年 2 月の 第 2 回 、2025 年 4 月の 第 3 回 、2025 年 8 月の 第 4 回 、2025 年 11 月の 第 5 回 、2026 年 2 月の 第 6 回 に続き、今回が第 7 回となります。本記事では、イベントの模様をレポートします。 本イベントの司会進行は、AWS ジャパン 戦略事業開発本部 プリンシパル 戦略事業開発マネージャー 塚本 陽子が務め、全体を通じて登壇者の紹介やセッションの案内を行いました。 開会のご挨拶 イベントの冒頭では、塚本が開会の挨拶をしました。塚本はまず、2023年の「 AWS LLM開発支援プログラム 」開始以来、AWS が継続してきた生成 AI 活用支援の歩みを振り返りました。直近では 2026 年 1 月より「 フィジカル AI 開発支援プログラム 」を始動させるなど、移り変わる顧客ニーズに合わせ、支援内容を拡充してきたことを強調しました。 また、これまでの実績として「生成 AI 実用化推進プログラム」への参画企業が合計で 320 社に達したことを報告。経済産業省および NEDO が主導する「GENIAC」プロジェクトへの支援も含め、AWS が日本の生成 AI の発展に尽力している旨を共有しました。 続いて、生成 AI の現状に触れる中で、Amazon CEO Andy Jassy の「株主への手紙」から「不釣り合いに大きな変曲点を見つけたら、大きく賭けよ」という趣旨の一節を引用しました。 技術動向については、2026 年 4 月に「What’s Next with AWS 2026」で発表された最新アップデートに触れ、「お客様が用途に応じて最適な生成 AI を自由に選択できるよう、サービスをさらに拡充していく」という AWS の方針を強調しました。 アップデートの具体的な内容として、AI アシスタント Amazon Quick のデスクトップアプリ・無料プラン提供開始に加え、OpenAI とのパートナーシップ拡大により 最新の OpenAI モデルが Amazon Bedrock 上で利用可能になったこと や Codex on Bedrock、Managed Agents のリリースを紹介。 Amazon Connect の 4 ソリューション（Decisions、Talent、Customer、Health）についても解説しました。 さらに、 Amazon Bedrock において Claude Code と Codex 双方をサポートすることや、Claude のネイティブプラットフォームと AWS の認証・課金を組み合わせた新たなサービスの開始についても紹介しました。 最後に塚本は、今回で 7 回目を迎えた本ミートアップが、エンジニアから経営層までが業界を越えて一堂に会する貴重な場であることに言及。「この場を通じて知識を吸収し、ネットワークを広げていただくことで、みなさまのプロジェクトがさらに前進することを願っています」と期待を込め、挨拶を締めくくりました。 AWS セッション AWS セッションの前半パートでは、ゲストスピーカーである株式会社 NTTドコモ コンシューマサービスカンパニー Senior Principal Architect 三井 力 氏（写真上）が登壇。後半パートでは、AWS ジャパン AIML 事業本部 シニアAIML セールススペシャリスト 近藤 祐丞（写真下）をモデレーターに三井 氏との対談が行われました。 三井氏はまず、同社のスマートライフ事業を支える「プロダクトデザイン部」の体制を解説しました。100 以上のプロダクトを抱え、年間 12,000 回以上のリリースを行う大規模な開発運用（DevOps）組織です。さらなる開発速度向上と顧客体験価値の最大化を目指し、AI 駆動開発に全面的に取り組んでいる旨を語りました。 組織的な仕掛けとして、2025 年 4 月に「生成 AI 本格活用元年」を宣言し、プロジェクトを推進。社内の生成 AI コンテストを通じて 250 件以上のアイデアを創出しました。実用化された施策によって、今年度末までに約 13.3 億円もの事業成果が見込まれています。 技術論として三井氏が強調したのが、AI が信頼できる仕事をするための環境を整える「ハーネスエンジニアリング」の概念です。静的解析やテストを活用してのフィードバックループの実施や、要件定義やレビューといった勘所に高性能モデルを配置する推論サンドイッチといった手法を紹介しました。 また、運用の高度化についても言及。Agent CoreやLangChainを使った自前のエージェントに加え、東京リージョンで GA（一般提供開始）された AWS DevOps エージェントを導入し、障害対応を AI がサポートする体制を整えています。加えて、AWS の提唱する AI-DLC（AI 駆動開発ライフサイクル）に準拠したテンプレートを社内展開し、誰でも標準化された環境で開発を始められる工夫をしています。 対談パートでは、AI 時代の開発者像について議論が交わされました。三井氏は「AI 駆動開発は避けて通れない道。実装を AI が担うようになるからこそ、エンジニアはより上流のビジネス理解や、下流のデータ活用へと役割を広げ、技術を繋いでいく存在になるべき」と指摘。「AI と共に、顧客体験価値の高いプロダクトを作り続けたい」と展望を語り、セッションを締めくくりました。 カスタマー事例 ここからは、生成 AI 実用化推進プログラムに参加する各社の代表者が登壇し、「カスタマー事例」「モデル開発者紹介」の 2 部構成で取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 AI/ML Specialist SA の飯塚 将太（写真左）と鯨田 連也（写真右）がモデレーターを務め、登壇者に質問を投げかけつつ進行しました。 株式会社 JDSC FDE / テックリードの鈴木 海斗 氏は、船主（船舶所有者）の業務を支援する海運 AI エージェント「AI番頭」の取り組みを解説しました。海事領域特有の課題に対し「データ」「回答生成」「運用」において独自の工夫を凝らしています。 データ設計では、画像処理（OpenCV）を用いて古い契約書の不要記述（取り消し線など）を除去し OCR 精度を向上させたほか、船舶データベースによる名称の正規化を行いました。回答生成では、質問からメタデータを抽出して検索ロジックを動的に切り替える仕組みを構築し、高精度な回答を可能にしました。運用面でも、アプリの利用者と目線を合わせながら「観測・評価・改善」を続けてきたのです。こうした活動が評価され、経産省・NEDO「GENIAC-PRIZE」最終審査で第 2 位を獲得しています。 ウォンテッドリー株式会社 Visit AI Squad リーダー の市古 空 氏は、同社のビジネス SNS「Wantedly Visit」における AI エージェントの実装事例と、設計思想の核となる Human-in-the-Loop の重要性について説明しました。 生成 AI の技術基盤には Amazon Bedrock を採用し、マイクロサービス群から共通ライブラリ経由でアクセスして、複数のモデルを柔軟に使い分ける構成にしました。また、採用ドメインにおける説明責任やユーザーの納得感を重視し、AI の判断を人間が評価するプロセスを意図的に組み込んでいます。「Human-in-the-Loop は人間の介入ポイントをいつ・どの粒度で持たせるかを意識して設計することが重要」と市古氏は語りました。 アイフル株式会社 グループシステム本部デジタル推進1部5課 課長兼 CCoE 統括長の大田 悠司 氏は「属人化したレガシーの再生」をテーマに、生成 AI とサーバーレスを活用した完全内製開発の事例を紹介しました。同社は従来はシステム開発を外部ベンダーに頼ることが多く、ドキュメントが欠落・形骸化したレガシーシステムの保守・改善が大きな課題となっていました。 そこで、内製化へと舵を切るため、特定プロジェクトで Amazon Bedrock 経由の Claude Code を活用した仕様駆動開発を実践。特に既存コードから仕様を逆算出するリバースエンジニアリングの工程では、工数を従来の 86.7% 削減することに成功しました。全工程を通じた開発効率も約 4 倍に向上したほか、フルサーバーレス構成への移行により、インフラコストを 95% 以上削減するという劇的な成果をあげています。 株式会社リーフワークス 代表取締役の澤 健太 氏は、会社の規模や目的に合わせて使える PaaS 型 Web サービス構築プラットフォーム「Palette CMS」への AI エージェント実装事例を共有しました。 UI 設計では、チャットを通じて動的に画面要素を生成する Generative UI を採用。アーキテクチャ面では、各エージェントが「これは自分の仕事ではない」と自律判断した時点で専門エージェントへバトンを渡すスキルディスパッチ機能を搭載しました。さらに RAG においては、Markdown の階層構造を保持したままデータ化することで、ドキュメントの文脈を正確に捉えた高精度な回答を実現しています。 モデル開発者紹介 ストックマーク株式会社 取締役 CTO の有馬 幸介 氏は、複雑なビジネス資料を読み解くための専用 AI の開発・運用事例を解説しました。フルスクラッチで開発した1000億パラメータの日本語 LLM やマルチモーダル文書読解 VLM は、特に日本語のドキュメント理解に優れており、GPT-4o を超える性能を示しています。 開発には Amazon SageMaker HyperPod を活用。加えて、多様な学習用合成データ自動生成技術を駆使し、専門的な図面や文書の理解力を大幅に向上させました。今後は大手企業や産総研との協業を通じて、ビジネスシーンにおける生成 AI の社会実装を加速させることを目指しています。 登壇者の皆様 クロージング クロージングでは塚本より、次回の「生成 AI Frontier Meetup」が、2026 年 8 月 27 日に開催予定であることを説明しました。会場は東京都港区の麻布台ヒルズ JP タワーの新オフィスです。加えて、今後開催される他のイベントも紹介しました。 Physical AI — クラウドとロボティクスの融合 AI が仮想空間を超え、物理世界で自律的に動作する「フィジカル AI 」の時代が到来しています。本イベントでは、AWS のフィジカル AI スペシャリストよりグローバルの最新動向を紹介するとともに、ファナック株式会社をゲストに迎え、協働ロボットCRXの実践事例やオープンプラットフォーム戦略を通じて、フィジカル AI プロジェクトを成功に導くための具体的なアプローチをお伝えします。また、同週開催の AWS Summit Japan の「フィジカル AI 観点での楽しみ方」もご紹介します。 イベント概要 日時：2026 年 6 月 24 日（水） 13:00 – 15:00 場所 : 東京都港区麻布台1丁目3-1 麻布台ヒルズ 森JPタワー 36階 形式：対面（定員 70名） ※ 参加希望者は担当営業にお問い合わせください AWS Summit Japan 2026 AWS Summit Japan は、クラウドと AI イノベーションの最前線を体験できる 2 日間の無料イベントです。エージェンティック AI やサーバーレスコンピューティングなど、業界を変革し、デジタル時代においてビジネスの成長を支えるテクノロジーを体感しましょう。業界のリーダーとの交流、同業他社とのコラボレーション、そして AWS エキスパートへ直接質問し疑問を解消できる貴重な機会です。同じ興味・関心を持つプロフェッショナルとの交流を広げ、インタラクティブなワークショップやカスタマーショーケースなど、多彩なラインアップからご自身のビジネスニーズに最適な体験を自由にカスタマイズしましょう。 イベント概要 日時：2026 年 6 月 25 日（木）〜 6 月 26 日（金） 場所：千葉市美浜区中瀬 2 – 1 幕張メッセ 公式サイト：https://aws.amazon.com/jp/events/summits/japan/ 参加者交流会の様子 交流会では、各セッションで語られた具体的な開発手法や組織文化の作り方を起点に、参加者同士の自由な議論が交わされました。業界の垣根を越えて「学びと繋がり」を深める本イベントらしい活気にあふれ、新たな共創の可能性を感じさせる場となりました。 会場内には、技術的な相談に応じる「Ask an Expert」コーナーや、各種の疑問を気軽に相談できる「よろず相談」コーナーも設けられ、参加者の方々の質問に回答いたしました。 おわりに 第 7 回を迎えた本イベントでは、技術的な工夫のみならず、組織文化の醸成やデータの質を追求する取り組みまで多岐にわたる知見が語られました。各社の生成 AI 活用が、より多角的かつ実用的なフェーズに進展していることを実感できる場となりました。AWS ジャパンは、今後もコミュニティの活性化や技術支援を通じて企業の生成 AI 活用を後押しし、その実用化と発展に貢献してまいります。

2026年6月4日、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が実施する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の 第4期における採択事業者 のキックオフが行われました。今回 AWS は NVIDIA B200 Tensor Core GPU を搭載する Amazon EC2 P6-B200 インスタンス ( p6-b200.48xlarge )、NVIDIA H200 Tensor Core GPU を搭載する Amazon EC2 P5en インスタンス ( p5en.48xlarge )、NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンス ( p5.48xlarge , p5.4xlarge ) 等の学習・推論に必要な仮想サーバーを提供します。 AWS は、 GENIAC バーチャルチーム を中心に、以下の支援を提供します: 計算資源 : Amazon EC2 P6-B200, P5en, P5 インスタンスの提供 技術支援 : AWS Solutions Architect (SA) を中心としたメンバーにより、コンピュート (EC2)・ネットワーク ( Elastic Fabric Adapter (EFA) )・ストレージ ( Amazon FSx for Lustre および Amazon S3 ) で構成される分散学習環境の AWS ParallelCluster  を活用した構築・管理の支援 開発者コミュニティ支援 : 海外モデルプロバイダーの開発メンバーとの交流イベントによる最先端の開発動向調査や海外視察、国内の機械学習エンジニア同士の交流による知見共有をはじめとした Meetup の実施 事業化支援 : GENIAC を通じて開発された基盤モデル・生成 AI アプリケーションの Amazon Bedrock Marketplace 、 AWS Marketplace の活用による go-to-market (GTM) 支援、利用企業との AWS 主催イベントを通じたマッチング機会の提供 これらは、経済産業省商務情報政策局情報処理基盤産業室、NEDO、ボストン コンサルティング グループ (BCG)、および AWS パートナーであるクラスメソッド株式会社と密に連携のうえで提供されます。 採択事業者 採択事業者のうち AWS を利用する事業者は以下です (現時点で承諾が得られたもののみをアルファベット・五十音順で掲載): 株式会社ABEJA Direava株式会社 株式会社DubGuild 株式会社Preferred Networks 株式会社メルカリ ONESTRUCTION株式会社 Sansan株式会社 株式会社Spectee 採択事業者からコメントを頂きました 株式会社ABEJAは、GENIAC第一期から継続して、LLMの社会実装への貢献を目的に、LLMおよび周辺技術の社会実装に取り組んでまいりました。 第四期では間違いが許されないミッションクリティカル事業への利活用を目的に、LLMおよび領域特化型のAIエージェントの研究開発に取り組みます。その上で、株式会社IDOM様と連携し、自動車整備領域における利活用を実証します。 AWS様の大規模な計算資源および技術支援を活用することで、過去事例など複数の情報ソースから必要な情報を自律的に検索・参照するToolUse能力、多様なデータを用いて論理的・段階的に解答を導き出す多段推論能力の強化を進めてまいります。 このたび新たに開発する技術は、実店舗で「Human in the Loop」の元、運用することを予定しています。精度を継続的に向上させながら、自動車整備領域における人手不足、属人化、技術の高度化による生産性低下といった課題の解決に貢献してまいります。 — 株式会社ABEJA 執行役員 木下 正文 氏   弊社はGENIACサイクル4において、外科手術における「未来予測AI基盤モデル」の開発に注力します。 サイクル3に引き続き、Amazon EC2 P5インスタンスや、大規模分散学習を支える最先端のインフラを継続して活用できることに深く感謝しております。AWS様の強力なサポートのもと、最先端AIの力で一歩先の医療現場を支えるソリューションの開発を加速させてまいります。 — Direava株式会社 CTO 斎藤 洸輔 氏   DubGuildは、大規模な音声インタラクションモデルの研究開発に取り組んでいます。 GENIACプロジェクトでは、B200 GPUを搭載したAWSのP6-B200インスタンスを活用し、30B級の大規模音声言語モデルの開発を進めてまいります。 本取り組みにあたり、Generative AI Innovation Centerをはじめ、AWSの皆様より多大なるご支援を賜っておりますこと、心より感謝申し上げます。 — 株式会社DubGuild CEO 大嵜匡俊 氏   株式会社メルカリは、GENIACプロジェクト4期目において、”Generative Retrieval技術を用いた二次流通市場向け高精度検索・推薦基盤モデルの開発”に取り組みます。Amazon EC2 P5インスタンスを活用し、大規模な学習を行います。AI自身が商品を丸暗記して探す次世代検索モデルによって、世界中の誰もが欲しい物にすぐに出会える最高の買い物体験を目指します。 — 株式会社メルカリ 研究開発組織R4D 所長 小堀 訓成 氏   AWS様には第3期に続き、第4期も引き続き支援いただきありがとうございます。 ONESTRUCTIONは本事業において、建設×AIをテーマに、建設ドメイン知識のAIエージェントへの統合と、それによる3次元設計（BIM）のAIによる自律化を目指します。 AWSの圧倒的なレジリエンスと信頼性に加え、とりわけGenAI Innovation Centerのチームによる世界水準の知見によるバックアップにより、建設業界のAI-Powerdを実現させます、ご期待ください。 — ONESTRUCTION株式会社 AI戦略ユニット Manager 日高 洸陽 氏   防災・危機管理分野からは初の採択となる今回、Specteeは独自の災害データとAI技術を基盤に、危機事象をリアルタイムに抽出する災害検知LLMと、ユーザー固有のBCP等を踏まえて行動を示唆する危機管理AIエージェントの開発に取り組みます。学習には Amazon EC2 P5 インスタンス、データ管理には Amazon S3 を活用し、AWS様のバーチャルチームによる技術支援のもと、人命に関わる領域に求められる高い精度と安定性の実現を目指します。日本発の次世代防災・危機管理基盤として、グローバル展開を見据えて開発を加速してまいります。 — 株式会社Spectee 取締役CRDO 加藤 奈々 氏 まとめ AWS では日本のお客様に対し、2023年の AWS LLM 開発支援プログラム にはじまり、グローバルの Generative AI Accelerator や AWS ジャパン生成 AI 実用化推進プログラム といった取り組みを通して生成 AI ワークロードを支援しています。GENIAC においても 第2期 、 第3期 に続き、第4期でも引き続き採択事業者の皆様と伴走し、これまで蓄積してきた知見を活かして日本の生成 AI 基盤モデル開発力の向上に貢献できれば幸いです。

本記事は 2026 年 6 月 3 日 に公開された「 Migrating data from Oracle to Amazon Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は、サーバーレスで柔軟にスケールする分散 SQL データベースサービスです。複数の AWS リージョンにまたがって、強力な ACID 準拠を実現します。データベースのモダナイゼーションに向けて Amazon Aurora DSQL を検討している場合、サービスの現在の機能と制約の範囲内で既存のエンタープライズデータベースを移行するという課題に直面することがあります。 本記事では、 AWS Database Migration Service (AWS DMS) 、 Amazon Simple Storage Service (Amazon S3) 、 AWS Glue 、 AWS Step Functions を使い、Oracle ソースから Amazon Aurora DSQL へデータを移行する手順を説明します。エンタープライズ規模のデプロイに適した、自動化されたコスト効率の高い移行パイプラインを構築します。 このソリューションの完全なソースコードは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリで入手できます。 Amazon Aurora DSQL の概要 Amazon Aurora DSQL は、高可用性、スケーラビリティ、パフォーマンスを必要とするアプリケーション向けに設計された、サーバーレスの分散 SQL データベースです。主な特長は次のとおりです。 サーバーレスアーキテクチャ – Amazon Aurora DSQL はフルマネージドのサーバーレスデータベースサービスで、需要に応じてコンピューティング、ストレージ、実行レイヤーを自動的にスケールします。 PostgreSQL 互換性 – Amazon Aurora DSQL は PostgreSQL 互換の SQL 構文と機能を提供するため、PostgreSQL インターフェイスで動作するアプリケーションに適しています。 分散設計 – 分散アーキテクチャを採用し、複数のアベイラビリティーゾーンにわたる高可用性と耐久性を実現します。 マルチリージョン対応 – Amazon Aurora DSQL は、ディザスタリカバリやグローバルアプリケーション向けにマルチリージョンデプロイをサポートします。 IAM 統合 – AWS Identity and Access Management (IAM) と統合し、認証とアクセス制御を行います。 暗号化 – Amazon Aurora DSQL は、データセキュリティのために保管時と転送時の暗号化を提供します。 移行の課題と要件 エンタープライズデータベースを Amazon Aurora DSQL に移行する際には、いくつかの固有の課題に直面します。 認証の複雑さ – Amazon Aurora DSQL では、特定のトークン生成要件を伴う IAM ベースの認証が必要です。必要なロールを引き受けられる AWS サービスは限られているため、直接接続できる手段が制限され、認証を慎重に管理する必要があります。 スキーマ作成の自動化 – Amazon Aurora DSQL では、データをロードする前にスキーマとテーブルを明示的に作成する必要があります。そのため、ソースデータベースからのスキーマ分析と変換を自動化する仕組みが必要です。 データロードの制約 – Amazon Aurora DSQL は主にファイルからの COPY コマンドでのデータロードをサポートしており、移行戦略に固有の要件が生じます。ファイルはデータベースエンジンからローカルにアクセスできる必要があり、移行パイプラインの構成方法に影響します。 コスト最適化 – 中間処理に Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使う従来の方法では、特に移行期間が長期にわたる大規模データベースで、ストレージとコンピューティングのコストが大きくなることがあります。 ソリューションの概要 次の図は、ソリューションのアーキテクチャを示しています。 ワークフローは次のステップで構成されます。 パイプラインがオンプレミスの Oracle データベースからデータを抽出します。ソースには、AWS DMS がサポートする他のリレーショナルデータベースを使うこともできます。 AWS DMS がデータを Amazon S3 に移行し、AWS Glue データカタログを作成します。 Step Functions が AWS DMS タスクの進行を開始・監視し、 AWS Lambda 関数と AWS Glue ジョブを起動します。 Lambda 関数が AWS DMS からテーブルマッピングを取得して Step Functions に返し、Step Functions がそれを AWS Glue ジョブに渡します。 AWS Glue がターゲットの Amazon Aurora DSQL データベースに接続し、データカタログを使ってカラムを識別します。続いてターゲットにスキーマを作成し、ターゲットのデータ型にデータを変換します。最後に Amazon S3 からデータを読み取り、Amazon Aurora DSQL データベースにロードします。 前提条件 始める前に、次の前提条件を満たしていることを確認してください。 AWS DMS のレプリケーションソースとして設定し、データベース移行の準備が整ったソース Oracle データベース。 中間データストレージ用の S3 バケット。次の設定を行います。 ブロックパブリックアクセスを有効化。 デフォルト暗号化 (SSE-S3 または SSE-KMS) を構成。 AWS DMS がターゲットとして使用し、AWS Glue がアクセスするために必要な権限。 AWS DMS タスクの監視、Lambda 関数の起動、AWS Glue ジョブの管理を行うサービスロールを引き受ける Step Functions ワークフローを作成するためのユーザー権限。 特定の Amazon Aurora DSQL クラスターにスコープを限定した次の IAM 権限。 iam:CreateServiceLinkedRole 。 dsql:DbConnect 。 dsql:DbConnectAdmin 。 dsql:GenerateDbConnectAdminAuthToken 。 dsql:GenerateDbConnectAuthToken 。 Amazon Aurora DSQL のターゲットインスタンスを作成する Amazon Aurora DSQL クラスターを作成するには、次のステップを実行します。 Amazon Aurora DSQL コンソールのナビゲーションペインで、[ Clusters ] を選択します。 [ Create cluster ] を選択し、[ Single-Region ] または [ Multi-Region ] を選択します。 暗号化設定、削除保護、タグを構成します。 [ Create cluster ] を選択します。 クラスター作成の詳細な手順、高度な設定、マルチリージョンのセットアップオプションについては、 Aurora DSQL の開始方法 を参照してください。 AWS DMS タスクを構成する 次のステップで AWS DMS タスクを構成します。 データ量を処理できる十分な容量のレプリケーションインスタンスを作成します。 接続情報を設定し、転送時の暗号化のために SSL モードを verify-full に設定した Oracle ソースエンドポイントを作成します。 次の設定で Amazon S3 ターゲットエンドポイントを作成します。 DataFormat を CSV に設定。 EncryptionMode を SSE_KMS に設定。 ServerSideEncryptionKmsKeyId を KMS キーの ARN に設定。 GlueCatalogGeneration と IncludeOpForFullLoad を True に設定。 AWS DMS 移行タスクを作成します。 移行タイプに [ full load ] を選択します。 ソーススキーマのテーブルマッピングを構成します。 ラージオブジェクト (LOB) の処理とパフォーマンスに適したタスク設定を行います。 移行タスクの起動設定を [ Manually later ] に設定します。 AWS DMS の詳細な構成手順、エンドポイント設定、タスク構成オプションについては、 Creating a task 、 Using an Oracle database as a source for AWS DMS 、 Using Amazon S3 as a target for AWS Database Migration Service を参照してください。 Lambda 関数を作成する AWS DMS タスクのマッピングからテーブル情報を抽出する Lambda 関数を作成します。この関数は DMS タスクのテーブルマッピングを解析してターゲットのテーブル名を特定し、それを AWS Glue ETL ジョブに渡します。 Lambda 関数の完全なコードは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 この関数は主に次の処理を行います。 DMS タスクイベントから tableMappings を解析します。 DMS ルールを順に処理し、選択タイプのルールを見つけます。 object-locator からテーブル名を抽出して返します。 Lambda の構成 メモリ – 128 MB (テーブル名の抽出には十分です)。 タイムアウト – 15 秒 (5 秒より長く設定します)。 IAM ロール – 次の AWS DMS 権限を持つ基本的な Lambda 実行ロール。 dms:DescribeReplicationTasks – AWS DMS タスクの詳細とテーブルマッピングを読み取ります。 dms:DescribeTableStatistics – テーブル単位の移行統計にアクセスします。 Lambda の IAM 権限要件の詳細については、 AWS Lambda アクセス許可の管理 および AWS DMS API Reference を参照してください。 AWS Glue ETL ジョブを作成する AWS Glue ETL ジョブは、スキーマの作成、データ型のマッピング、Amazon Aurora DSQL へのデータロードを担います。 データカタログのセットアップ Amazon S3 をターゲットにすると、AWS DMS がデータカタログのエントリを自動的に作成します。別途クローラーを用意する必要はありません。AWS DMS は移行中にデータカタログを生成し、Oracle ソースの適切なスキーマ情報を使ってテーブルをカタログ化します。 ジョブの構成 ジョブタイプ – Spark ETL。 AWS Glue バージョン – 3.0 以降。 依存 JAR のパス – postgresql-42.7.4.jar (JAR ファイルをダウンロードし、S3 のアクセスパスを指定します)。 Python モジュールのパス – boto3>=1.35.95 (Amazon Aurora DSQL の認証に使用します)。 ワーカータイプ – データ量に応じて調整します。 Glue ジョブの IAM 権限 AWS Glue ジョブには、次のサービスにまたがる権限が必要です。完全な IAM ポリシーについては、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 ステートメント アクション 目的 S3Access s3:GetObject , s3:ListBucket 移行データを Amazon S3 から読み取る GlueDataCatalogAccess glue:GetDatabase , glue:GetTable , glue:GetPartitions スキーマのメタデータにアクセスする AuroraDSQLAccess dsql:DbConnect , dsql:DbConnectAdmin ターゲットデータベースに接続する DSQLTokenGeneration dsql:GenerateDbConnectAdminAuthToken , dsql:GenerateDbConnectAuthToken 認証トークンを生成する AWS Glue の IAM 要件の詳細については、 「AWS Glue」 のセキュリティ および Aurora DSQL での Identity and Access Management を参照してください。 AWS Glue ETL ジョブのスクリプト 完全なスクリプトは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 このスクリプトは主に次の処理を行います。 トークン生成 – boto3.client("dsql") の generate_db_connect_admin_auth_token() を使って IAM 認証トークンを生成します。 スキーマ検出 – AWS Glue データカタログからテーブルスキーマを読み取ります。 データ型マッピング – 次の表のように、Oracle と Glue のデータ型を Amazon Aurora DSQL 向けの PostgreSQL 互換型にマッピングします。 Glue の型 Amazon Aurora DSQL の型 string VARCHAR(255) int INTEGER bigint BIGINT double DOUBLE PRECISION float REAL boolean BOOLEAN timestamp TIMESTAMP date DATE decimal NUMERIC long BIGINT binary BYTEA map JSONB struct JSONB array TEXT[] 入力検証 – SQL インジェクションを防ぐため、テーブル名を SQL ステートメントで使用する前に、正規表現 ^[a-zA-Z0-9_]{1,64}$ で検証します。 DDL 実行 – 明示的なトランザクション管理を伴う JDBC 接続を使って、Amazon Aurora DSQL にテーブルを作成します。 データロード – Amazon S3 から CSV データを読み取り、型キャストを適用し、トランザクション分離レベル REPEATABLE_READ とバッチサイズ 9,900 行で JDBC を使って Amazon Aurora DSQL に書き込みます。 Glue ジョブの主な設定 トークン生成 – boto3.client("dsql") の generate_db_connect_admin_auth_token() メソッドを使用します。 トークンの有効期限 – 最大 24 時間です。ここでは 1 時間に設定しています。 ユーザー ID – サンプルコードで使用するユーザー ID は admin です。 データ型マッピング戦略 – GlueCatalogGeneration を使うと、スキーマのカラムにはソースの値と一致しないことがあるデフォルトのデータ型が割り当てられます。AWS Glue のコードでデータ型マッピング戦略を定義してください。Amazon Aurora DSQL がサポートするデータ型については、 Amazon Aurora DSQL ユーザーガイド を参照してください。 トランザクション分離レベル – Amazon Aurora DSQL ターゲットでは、データ整合性のために REPEATABLE_READ が必要です。 Step Functions ステートマシンを作成する Step Functions ステートマシンが移行ワークフローを制御します。ステートマシンは AWS DMS タスクを開始し、その状態を監視します。AWS DMS タスクが完了すると、テーブルマッピングを抽出してテーブル名を AWS Glue ジョブに渡します。その後、AWS Glue ジョブを起動します。 次の図は、ステートマシンのワークフローを示しています。 ステートマシンワークフローの特徴 AWS DMS の自動開始 – レプリケーションタスクをプログラムで開始します。 進行状況の監視 – AWS DMS タスクの状態を 60 秒ごとにポーリングします。 完了の検出 – stopped ステータスと進行状況 100% を待ちます。 エラー処理 – 失敗した AWS DMS タスクを適切に処理します。 Lambda 連携 – AWS Glue ジョブ向けにテーブル情報を抽出します。 AWS Glue ジョブの起動 – テーブルパラメータを指定して AWS Glue ETL ジョブを開始します。 セットアップの手順 ステートマシンを構成するには、次のステップを実行します。 Step Functions コンソールで、[ Create state machine ] を選択します。 [ Write your workflow in code ] を選択し、ステートマシン定義を入力します。完全なステートマシン定義については、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 定義内の Amazon リソースネーム (ARN) とジョブ名を更新します。 AWS DMS タスクの ARN を、自分のタスクの ARN に置き換えます。 Lambda 関数の ARN を、自分の関数の ARN に置き換えます。 AWS Glue ジョブ名を、自分のジョブ名に置き換えます。 ステートマシンを作成する前に、参照する ARN が存在することを確認します。 次の権限を持つ IAM 実行ロールを作成します。 dms:StartReplicationTask 。 dms:DescribeReplicationTasks 。 lambda:InvokeFunction 。 glue:StartJobRun 。 CloudWatchLogsDeliveryFullAccessPolicy (ステートマシンの実行ログを保存するため)。 ステートマシンのステート ステートマシンは、次のステートを通じて移行を制御します。 ステート タイプ 目的 StartDMSTask Task DMS レプリケーションタスクを開始する GetDMSTaskDetails Task レプリケーションタスクの状態を取得する CheckDMSTaskStatus Choice ステータス (stopped、failed、running) に応じて分岐する WaitForDMSTask Wait 60 秒ごとにポーリングする DMSTaskFailed Fail 失敗したタスクのエラー処理 ExtractTableName Task Lambda を呼び出してテーブル名を取得する StartGlueJob Task テーブル名パラメータを指定して AWS Glue ETL ジョブを起動する Step Functions のセットアップと AWS DMS との統合パターンの詳細については、 AWS Step Functions デベロッパーガイド および Create and run AWS DMS tasks using AWS Step Functions を参照してください。 セキュリティに関する考慮事項 このソリューションでは、機密データを扱う可能性のある複数の AWS サービスを使用します。次のセキュリティのベストプラクティスに従ってください。 責任共有モデル このアーキテクチャは AWS 責任共有モデル に従います。責任は次のように分担されます。 サービス AWS の管理範囲 お客様の管理範囲 Amazon Aurora DSQL データベースエンジン、パッチ適用、高可用性、インフラストラクチャのセキュリティ IAM ポリシー、VPC エンドポイントの構成、暗号化キーの選択 Amazon S3 ストレージインフラストラクチャ、耐久性、可用性 バケットポリシー、暗号化の構成、アクセス制御、ブロックパブリックアクセス AWS DMS レプリケーションインスタンスの OS、エンジンのパッチ適用 エンドポイントのセキュリティ、SSL/TLS の構成、ネットワークアクセス セキュリティ実装の優先順位 データ移行を開始する前に、次の順序でセキュリティ対策を実装してください。 S3 バケットの暗号化 (SSE-KMS) とブロックパブリックアクセスを構成します。 各サービス (AWS DMS、Lambda、AWS Glue、Step Functions) に最小権限の IAM ロールを作成します。 カスタマーマネージド KMS キーで Amazon Aurora DSQL クラスターの暗号化を有効にします。 データがパブリックインターネットを経由しないように、Amazon S3 と AWS Glue の VPC エンドポイントを構成します。 監査とモニタリングのために、AWS CloudTrail と Amazon CloudWatch のログ記録を有効にします。 すべてのデータベース接続で SSL/TLS が強制されていることを確認します。 セキュリティ検証の手順 デプロイ後、次の点を確認します。 # Confirm S3 bucket encryption aws s3api get-bucket-encryption --bucket your-migration-bucket # Confirm Block Public Access aws s3api get-public-access-block --bucket your-migration-bucket さらに、次の点を確認します。 本番環境の IAM ポリシーにワイルドカード ( * ) リソースが含まれていないこと。 DMS レプリケーションインスタンスがパブリック IP を持たないプライベートサブネットに配置されていること。 すべての JDBC 接続文字列で、Amazon Aurora DSQL への接続に sslmode=require が使われていること。 認証トークンが設定した期間内 (AWS は 1 時間を推奨) に失効すること。 移行中のデータ保護 AWS DMS エンドポイントで転送時の暗号化を有効にします (Oracle ソースには SSL/TLS、Amazon S3 ターゲットには SSE-KMS)。 認証トークンをログに出力しないでください。有効期間の短いトークン (1 時間) を使い、設定は環境変数または AWS Secrets Manager に保存します。 aws:SecureTransport 条件を使って、暗号化されていない通信を拒否する S3 バケットポリシーを適用します。完全なバケットポリシーについては、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 AWS Glue ジョブの IAM ロールを、特定の S3 プレフィックスと Amazon Aurora DSQL クラスターに限定します。ワイルドカードの ARN は避けてください。 KMS キーポリシーを使って、移行データを暗号化・復号できるプリンシパルを制御します。 脅威モデル 次の表は、このアーキテクチャで特定し、緩和した脅威を示しています。 脅威 緩和策 過剰な権限を持つ IAM ロール すべての IAM ポリシーを、ワイルドカードではなく特定のリソース ARN に限定します。 テーブル名を介した SQL インジェクション テーブル名を SQL ステートメントで使用する前に、正規表現 ^[a-zA-Z0-9_]{1,64}$ で入力を検証します。 認証トークンの盗難やリプレイ 有効期間の短いトークン (有効期限 1 時間) を使い、ログには出力せず、認証情報はコードではなく環境変数に保存します。 S3 中間ストレージへの不正アクセス ブロックパブリックアクセスを有効にし、バケットポリシーを特定の IAM ロールに限定し、SSE-KMS 暗号化を使用します。 コードのセキュリティレビュー 本記事のすべてのコードサンプルは、入力検証、安全な認証処理、最小権限のアクセスパターン、インジェクション攻撃への防御を対象に、手動でセキュリティレビューを実施しています。レビューは、Bandit 1.7 (Python) と ESLint security plugin (JavaScript) による静的解析を使って行いました。 検出結果: Critical または High の重大度の問題は見つかりませんでした。Medium の検出結果 (情報レベルのログ出力) はレビューのうえ、サンプルコードとして妥当と判断しました。 本番環境にデプロイする前に、Amazon Inspector や同等のツール (Bandit (Python)、ESLint security plugin (JavaScript) など) で独自に静的解析スキャンを実行し、組織のセキュリティ基準に照らして検証してください。 Lambda のセキュリティガイドライン インターネットアクセスのない VPC プライベートサブネットに関数をデプロイします。AWS サービスには VPC エンドポイントを使用します。 AWS Key Management Service (AWS KMS) を使って環境変数を暗号化します。 リソースベースのポリシーを適用し、呼び出しを Step Functions のみに制限します。 実行ロールには最小権限の原則を適用します ( dms:DescribeReplicationTasks と dms:DescribeTableStatistics のみ)。 予約済み同時実行数を設定し、呼び出しの暴走を防ぎます。 Step Functions のセキュリティガイドライン AWS KMS カスタマーマネージドキーを使って、ステートマシンの保管時の暗号化を有効にします。 実行履歴のために、暗号化を有効にした Amazon CloudWatch Logs を有効にします。 ステートマシンの入力や出力で機密データ (トークン、パスワード) を渡さないようにします。AWS Systems Manager Parameter Store または AWS Secrets Manager を使用します。 実行ロールが最小権限に従っていることを確認します (AWS DMS、Lambda の呼び出し、AWS Glue の StartJobRun の権限のみ)。 IAM リソースベースのポリシーを使って、ステートマシンへのアクセスを制限します。 クリーンアップ 今後の課金を避けるため、このチュートリアルで作成したリソースを削除します。 Step Functions コンソールで、対象のステートマシンを選択し、[ Delete ] を選択します。 Lambda コンソールで、対象の関数を選択し、[ Actions ]、[ Delete ] の順に選択します。 AWS Glue コンソールで、対象の ETL ジョブを選択し、[ Action ]、[ Delete job ] の順に選択します。 AWS DMS コンソールで、次のリソースをこの順序で削除します。 移行タスク。 エンドポイント (ソースとターゲット)。 レプリケーションインスタンス。 Amazon S3 コンソールで、移行用バケットを空にして削除します。 Amazon Aurora DSQL コンソールで、対象のクラスターを選択し、[ Delete ] を選択します。 IAM コンソールで、このソリューション用に作成した IAM ロールとポリシーを削除します。 カスタマーマネージド KMS キーを使用した場合は、まだ必要かどうかを評価し、適切であれば削除をスケジュールします。 まとめ 本記事では、AWS DMS、Step Functions、Lambda、AWS Glue を使った自動化のアプローチで、Oracle から Amazon Aurora DSQL へ移行する手順を説明しました。このソリューションは、Amazon Aurora DSQL のサーバーレスアーキテクチャ特有の課題に対応します。Amazon S3 を中間ストレージとして使い、ワークフロー全体に十分なエラー処理を組み込むことで、手作業や運用の複雑さを抑えつつ、信頼性の高いデータ移行を実現できます。 Amazon Aurora DSQL の進化に合わせて、この移行フレームワークはデータベースモダナイゼーションを進めるうえで確かな基盤になります。インフラストラクチャのコストと管理の負荷を抑えながら、Amazon Aurora DSQL を最大限に活用できます。 この移行アプローチを始めるには、次の手順を実行します。 GitHub の sample-oracle-to-aurora-dsql-migration リポジトリをクローンします。 テストテーブルを使って、AWS アカウントに Step Functions ワークフローをデプロイします。 本番のワークロード全体に拡張します。 ご質問やフィードバックがあれば、コメントで共有するか、 AWS re:Post community をご覧ください。 著者について Aliasghar Hussain AWS の Database Specialist Solutions Architect です。Amazon RDS、DocumentDB、DynamoDB、ElastiCache といったクラウドデータベース技術で 6 年以上の経験があります。また、複雑なデータベース移行戦略、モダナイゼーション、インフラストラクチャ最適化に関する技術的なガイダンスを提供する分野の専門家として、お客様の AWS におけるクラウド導入の加速を支援しています。 Wasim Shaikh AWS でデータベースを専門とする Senior Solutions Architect です。お客様と協力して、さまざまなデータベースおよび分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を利用する際のソリューションの価値向上を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 5 回レポートです。シリーズの背景や全体像については、 初回の大阪・事業会社編レポート をご覧ください。 大阪・名古屋に続き、2026 年 4 月 27 日は広島にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト木村 友則から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる」存在へと進化してきた流れ、人手不足という社会課題に対して AI エージェントが果たせる役割、そして AI コーディングツールの Kiro と AI エージェントプラットフォームの Amazon Quick を、デモを交えてご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: ソリューションアーキテクト木村によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、中小企業のお客様への生成 AI 導入を支援されたパートナー企業様に、その現場で得られた知見をお話しいただきました。 事例紹介：株式会社エイチビーソフトスタジオ様 〜「完璧を待たず、まず触ってみる」現場に寄り添う生成 AI 導入支援〜 事例紹介は 株式会社エイチビーソフトスタジオ 様です。愛媛県松山市を拠点に、全社員が完全リモートで業務を行い、スタッフ全員がエンジニアという企業です。システム開発・スマートフォンアプリ開発・Web システム開発などを手がけられ、使い勝手とデザイン性にこだわったアプリケーションの制作や、障害に強いサーバー設計・運用を得意とされています。同社のサービスサイトには「小さく作るを繰り返す」という開発スタイルが掲げられており、AWS を活用したクラウド環境の構築支援も提供されています。当日は AWS 木村 (営業) がモデレーターを務め、代表取締役の影浦 義丈 様に、実際に手がけられた中小企業向けの生成 AI 導入支援についてパネルディスカッション形式でお話しいただきました。 きっかけは、属人化した問い合わせ対応 今回ご紹介いただいたのは、社員 10〜50 名程度の中小企業のお客様に対する、生成 AI を活用したナレッジ共有・業務効率化の導入支援プロジェクトです。 きっかけは、お客様社内での問い合わせ対応に多くの時間が割かれていたことでした。質問が特定の人に集中し、回答の品質も人によってばらつく。多くの企業が抱える「詳しい人に聞かないと分からない」という状態です。影浦様は「お客様に対するサポートも含め、何とかしたいというのが取り組みのきっかけでした」と振り返られました。 立ちはだかった 3 つの壁 ― 期待値・ルール・データ 実際に取り組みを進める中では、大きく 3 つの壁に直面したといいます。 1 つめは 期待値の壁 です。生成 AI に対する社内の温度感に差があり、影浦様は「トップの方は『ゴーゴー』という感じなんですけれども、現場の方は『何のためにやるのか分からない』という気持ちを持たれている場合もある」と語られました。その一方で、「AI を導入すれば何とかなる」「AI を入れれば 100% の結果が返ってくる」という、高すぎる期待値が生まれてしまうこともあったといいます。 2 つめは ルールの壁 です。生成 AI を活用する上で、どこでデータが処理されるべきかといったガバナンスの考え方や社内ルールが、そもそも全くない状態でした。 3 つめは データの壁 です。生成 AI 活用のベースになるノウハウやナレッジが、そもそもドキュメント化されていない。あるいはドキュメントにはなっていても、ファイル形式や保存場所がバラバラだったり、古い状態のまま更新されていなかったりと、活用の準備が整っていない状態でした。 3 つの壁をどう乗り越えたか これらの壁に対する影浦様の実際のアプローチをお話いただきました。 AI への期待値の壁を乗り越えるために、実際に AI に触れてもらい、何ができて何ができないかを肌感をもって理解してもらうことに取り組まれました。ただ、「ツールをポンとお渡しして『やってください』と言っても、なかなか難しい」と感じられたため、社員の皆様に向けたハンズオンを定期的に開催し、生成 AI への理解を高める機会を作りました。あわせて、活用のノウハウがどうしても各人それぞれに蓄積されてしまうという課題に対しては、各自の使い方や「結果が良かった・悪かった」を発表してもらう場を設け、QA を通じて全社的にノウハウを蓄積していく方法をとり、その実施にあたっての支援も行ったということです。 ルールの壁については、いきなり「まずはルールを作ってください！」とお伝えしてもプロジェクトが進みづらい、という前提に立ち、まず影浦様が叩き台となる基準を用意し、それをベースにお客様とやり取りしながら細かく積み立てて運用ルールを作っていかれました。 そして特徴的だったのが、データの壁への対処です。ドキュメント化されていない属人的なノウハウを「ゼロから文章を書いてください」と言ってもなかなか書けない。そこで影浦様が試したのが、 AI でインタビューをさせて、ドキュメントの種を引き出す という方法でした。継続的に改善するには、人のインタビュアーを常に用意するのは難しい。そこで AI を活用してインタビューからドキュメント化までを一貫して行える仕組みを構築したといいます。このとき影浦様が強調されたのは、ツールの新しさそのものではなく使い手の側でした。「生成 AI を結局利用するのは人間なので、人間がどれだけ詳細な指示を与えられるか。これが肝になってくると思います」。AI をうまく動かすためのドキュメントづくりを、AI 自身に手伝わせる。データが整理しきれていない中でも、まず一歩を踏み出すための現実的な工夫です。 取り組みの成果と、残る課題 取り組みの結果、問い合わせ対応の時間が削減され、特定の人への負荷集中が緩和されました。加えて、回答品質のばらつきの是正など、いくつかの成果を得ることにつながりました。 またさらなる成果として、ドキュメント化の「文化」が根づき始めた、という点もありました。それまでは様々な知見が暗黙知になりがちでしたが、AI への取り組みを続けるなかで、少しずつドキュメントに残し、展開していこうという文化につながりつつあるということです。この文化が広がっていくことで、他の業務でも「生成 AI を使ってみたい」という社員様が新しく出てくるなど、新たなユースケースの創出にもつながり始めています。 一方で、文化の定着には時間がかかること、AI の回答精度を上げながら改善し続ける必要があること、勉強会はやっているものの個人ごとの定着度や使い方にばらつきが残ることなど、継続的なフォローの重要性も語っていただきました。 参加者へのアドバイス ― 「触ってみないと分からない」 AI は進化も早く、また企業の課題も様々であるため、AI の活用方法の見定めには「やはり触ってみないと分からないことが多い」と述べられたうえで、「データにしてもセキュリティのルールにしても、完璧に全て揃えてからではなく、今あるもので、まず小さく始めて触ってみることが大切」と述べていただきました。 また、生成 AI の社内展開について、「個人で進めるのではなく、ハンズオンや勉強会、共有会のような場で、全社的に・チームでノウハウを共有しながら進めていただくと、取り組みが定着しやすくなる」と語られました。 写真: 株式会社エイチビーソフトスタジオ 影浦様、AWS 木村 (営業) によるパネルディスカッション まとめ セッション後には参加者同士のグループワーク・ディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。アンケートでは「他業種の方のお話を聞く機会が少ないため大変参考になった」「少人数で密に意見交換ができた」といった、参加者同士の交流を評価する声を多くいただきました。参加者の皆様も、ご自身に近い背景を持つ地元企業の取り組みを情報交換したり、その場で相談しあったりできており、AWS もその輪に参加させていただけてとても有意義な時間だったと感じております。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした広島編に続き、次回は福岡編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

国内最大規模の学習型 IT カンファレンスである AWS Summit Japan が、2026 年 6 月 25 日（木）・26 日（金）の二日間にわたり幕張メッセで開催されます。今年のサミットでは エージェンティック AI と Physical AI（フィジカル AI） が大きなテーマとして掲げられており、AI Agent が自律的にタスクを遂行するだけでなく、現実世界のモノを動かす技術に注目が集まっています。ヘルスケア・ライフサイエンス（ HCLS ）ブースでは、昨年に続き（ 開催報告はこちら ）、今年も多彩なデモを展示予定です。 本記事では、その中から AWS 上の AI Scientist（ AI 科学者）が実験用ロボットを直接操作し、自律的に科学実験を遂行する Self-Driving Lab デモをご紹介します。 創薬研究と DMTA サイクル ライフサイエンス研究、特に創薬研究では DMTA サイクル （ Design–Make–Test–Analyze ）と呼ばれる反復プロセスが広く用いられています。研究者は候補となる化合物や実験条件を 設計（ Design ） し、それを実際に 合成・作製（ Make ） し、得られたサンプルを 測定・評価（ Test ） し、その結果を 分析（ Analyze ） して次のサイクルへフィードバックする ― このループを何度も回しながら、最適な化合物や条件を探索していきます。しかし、各ステップには専門的な判断と手作業が伴います。サイクルを回す速度と、同時に探索できる範囲が、研究の進捗を左右する大きなボトルネックです。 AI Agent が変える研究のかたち ” Self-Driving Lab ” ― Dry から Wet へ 近年、 AI Agent は研究の世界に急速に浸透しつつあります。 DMTA サイクルにおける Design（設計）や Analyze（分析）のような Dry（計算・情報処理）のプロセス ― すなわちコンピュータ上で完結する In Silico の領域 ― では、最新の基盤モデルを活用した AI Agent が研究者レベルの分析・推論を行えるようになってきました。一方で、 Make（合成）や Test（評価）のような Wet（実験）のプロセス は物理的な操作を伴います。コンピュータの中に閉じた AI Agent だけでは、このステップを自律的に実行することはできませんでした。ここに Physical AI ― AI が実世界の装置やロボットを直接制御する技術 ― を組み合わせることで、はじめて DMTA サイクル全体を AI が回しきることが可能になります。 もし AI が DMTA サイクルのすべてのステップ ― Dry も Wet も ― を自律的に実行できたら、何が起こるでしょうか。 AI が仮説を立て、実験を設計し、ロボットに指示を出して実際にサンプルを作り、測定結果を解析し、次の実験を自分で決める。このループを AI が完全に閉じることができれば、人間の介在なしに実験を 24 時間回し続けることが可能になります。これが Self-Driving Lab（自律実験室）のコンセプトです。 Self-Driving Lab が実現することで、探索の範囲を一気にスケールアウトでき、従来であれば研究者が数週間かけて到達する結論に、はるかに短い時間で辿り着ける可能性があります。 ラボ自動化の壁を AI が乗り越える ラボの自動化装置自体は以前から存在しています。しかし、こうした装置を動かすには実験ごとに専用のプロトコル（メソッド）を作成する必要があり、実験のたびに条件が変わる研究の現場では「プロトコルを毎回書き直す学習コスト・構築コストが重い」という壁がありました。結局、手作業のほうが早いと判断されてしまうケースが少なくありません。 AI Agent がプロトコル設計やバリデーションを自律的に行えるようになると、この状況は大きく変わります。今回のデモのようにループを完全に閉じる Self-Driving Lab だけでなく、研究者と AI が協調しながらプロトコルを半自動的に生成・検証するだけでも、 Wet 研究を大幅に加速できます。自動化装置の真のポテンシャルを引き出す鍵が、 AI Agent にあると言えるでしょう。 デモ紹介：AI Scientist ― フィジカル AI が実現する眠らないラボ 今年の HCLS ブースでは、 Self-Driving Lab のコンセプトを体感いただけるライブデモを展示します。シナリオはシンプルです。 3 種類の異なる色の原液（ A / B / C ）をランダムな比率で混合した「秘密サンプル」を用意します。 AI Scientist は、この秘密サンプルの配合比率を、実際にロボットを操作しながら自律的に突き止めます。 具体的な流れを見てみましょう。 まず AI は秘密サンプルの吸光度スペクトル（光の吸収度合いを波長ごとに測定したデータ）を取得し、ターゲットとなる測定値を把握します。 次に、配合比率に関する仮説を立て、それを検証するための実験パターンを設計します。 設計が決まると、 AI は自動分注装置（ Tecan Fluent ）に対して分注指示を送り、配合候補のサンプルを実際に作製します。 作製したサンプルの測定データをターゲットと比較・分析し、差異が大きい部分に注目して次に試すべき配合を決定します。 このサイクルを数回繰り返すうちに推定精度が上がり、最終的には正しい配合比率に到達します。 色水という身近な題材ではありますが、 AI が「考えて、試して、学んで、また試す」という科学研究の本質的なプロセスを自律的に実行する様子を目の前でご覧いただけます。 Dry のプロセス（仮説生成・実験設計・データ分析）と Wet のプロセス（ロボットによる分注・測定）の両方を AI が担い、ループを完全に閉じて自律的に回している点が、本デモの最大の見どころです。徐々に混合液の色が正解に近づいていく過程は、視覚的にもお楽しみいただけるポイントです。 技術的なポイント 自動分注装置との接続には SiLA 2 （ Standardization in Lab Automation ）プロトコルを採用しています。 SiLA 2 はラボ機器間の通信を標準化するオープンな国際規格で、メーカーを問わず装置を統一的なインターフェースで制御できるようにするものです。これにより、 AI Agent がソフトウェアから直接ロボットを操作する連携が可能になります。AI Agent 自体は Amazon Bedrock 上で動作し、実験の計画立案から測定結果の解析、次の実験の意思決定までを一貫して担います。実験全体のワークフロー管理には AWS のクラウドサービスを活用し、一連の自律実験ループをオーケストレーションしています。アーキテクチャの詳細・実装の工夫・技術的なご質問は、ぜひ当日ブースにて直接どうぞ。 同じアーキテクチャで広がる応用先 今回は色水の配合比率という分かりやすいシナリオでデモを行いますが、この Self-Driving Lab のアーキテクチャは、より実践的な研究課題へそのまま展開できます。 創薬研究におけるアッセイ（生物活性の測定試験）条件の最適化 細胞培養のための培地組成探索 製剤における処方設計 いずれも「複数の条件を組み合わせて最適解を見つける」という課題構造は共通しており、 AI が自律的に探索空間を効率よくカバーする Self-Driving Lab の真価が発揮される領域です。HCLS ブースでは、本デモのライブ実演に加え、 4 月に一般提供が開始された Amazon Bio Discovery のデモなど、複数の展示を用意しております。「 AI × ロボット × クラウド」が創る研究の未来を、ぜひ会場で体感してください。皆さまのご来場を心よりお待ちしております。 ヘルスケア・ライフサイエンス関連ブースのご案内：ブース一覧 エリア ブース番号 タイトル テーマ AWS for Healthcare & Life Sciences A001 AI Scientist ― フィジカル AI が実現する眠らないラボ Self-Driving Lab A013 中外製薬株式会社 創薬・業務向け AI 共通基盤 A014 第一三共株式会社 AWS PCS × AI エージェントによる創薬研究基盤 A015 Amazon Bio Discovery AI エージェント型 AWS マネージドサービス A016 AI エージェントが実現する次世代医療ワークフロー AI エージェントによる自律的な診断支援 AWS for Public Sector A039 神戸大学大学院医学系研究科 生成 AI 書類審査ソリューション「 RAPID 」 A040 公共ヘルスケア＆アカデミア ヘルスケア× AI ：医療・介護の未来 A001　AI Scientist ― フィジカル AI が実現する眠らないラボ AI が仮説を立て、実験し、最適解を導く ― クラウドが繋ぐ Self-Driving Lab AI が自律的に仮説を立て、ライフサイエンス向けオートメーションワークステーション実機へ実験を指示し、測定結果を解析して次の実験計画を自ら決める。このサイクル全体を AWS クラウドがオーケストレーション。ブースでは実機稼働の様子をリアルタイムで観察でき、 AI が「秘密の混合サンプル」を自力で推定・再現する瞬間を目の前で体感できます。ぜひブースにお立ち寄りください。 A013　中外製薬株式会社 創薬・業務向け AI 開発を支える AWS 共通基盤 中外製薬では、創薬領域や全社業務の変革に向けた AI 活用を支える基盤の整備を進めています。 AWS 上に認証、 API 連携、 LLM 利用等の共通機能を集約することで、 AI アプリごとの重複実装を抑制し、品質向上と開発スピード向上を両立します。 AI 活用を広げながら、新たなアプリ、エージェント開発・連携や価値創出に繋げる取り組みをご紹介します。 A014　第一三共株式会社 AWS PCS と AI エージェントで作る創薬研究基盤 近年、 AI や解析技術の急速な発展により研究の在り方は大きく変革しており、ロボティクスや生成 AI の導入によって、大量の情報に基づく意思決定の質の向上と効率化が期待されています。第一三共では AWS PCS を用いた解析基盤の安定化と、 AI エージェントによる研究効率化に挑戦しました。本発表では技術導入の背景・成果・今後をご紹介します。 AI エージェントが研究現場にもたらす変革の可能性や期待について、議論できれば幸いです。 A015　AI 創薬 新サービス Amazon Bio Discovery Lab in the loop の創薬をすべての研究者に ― AI エージェント型 AWS マネージドサービス このブースでは、 AWS の新サービス「 Amazon Bio Discovery 」をご紹介します。 AI エージェントと 40 以上の生物学 AI モデルを活用し、抗体設計からウェットラボ検証までを一気通貫で支援する AWS マネージドサービスです。計算予測と実験結果が自動フィードバックされることで、研究組織全体で「 Lab-in-the-Loop 」をアクセス可能かつスケーラブルにすることが可能です。ご興味ある方はぜひブースにお立ち寄りください。 A016　AI エージェントが実現する次世代医療ワークフロー 画像解析からレポートドラフト生成まで ― 自律的な診断支援で医師を支える 日本の放射線科医は世界トップクラスの画像診断件数をこなし、業務負荷は増す一方です。本展示では、新規の医用検査画像の到着を起点に Amazon Bedrock AgentCore にホストされた AI エージェントが読影前の準備を自律的に遂行し、医師が確認と最終判断に集中できるワークフローをお見せします。  エージェントが自動で行うこと： 電子カルテから患者背景・既往歴・過去の読影レポートを収集 専門の医療 AI モデルによる病変検出・臓器セグメンテーション・画像所見の解釈 過去検査の確定所見との突き合わせによる経時比較 診断ガイドライン等と照合した日本語の構造化レポートドラフトを生成。過去レポートから読影医の記述スタイルを抽出し、その医師らしい書き味で下書き 医師は AI エージェントによる解析結果とドラフトを確認・修正するだけでレポートを仕上げられ、診断までの時間を短縮可能になります。チャットでの追加指示や所見の深掘りも可能です。ぜひブースで体感してください。 A039　公共アカデミア 神戸大学大学院医学系研究科  生成 AI 書類審査ソリューション「 RAPID 」による研究申請プロセス DX / AX 神戸大学 MedLeap（医療特化型スタートアップ拠点）は、研究審査における修正の往復という課題に対し、申請プロセスを再設計する取り組みを進めています。その実装として、 Amazon Bedrock を基盤とする書類審査ソリューション「 RAPID 」で先行開発中。現場のスピードと品質の両立を目指し、当日は、今後の展望をご紹介いたします。 AI 実装、業務改革、産学共創、実証フィールド、スタートアップ創出に関心のある皆様のご来訪をお待ちしております。 A040　公共部門 ヘルスケア ヘルスケア× AI ：医療・介護の未来 AWS の先進技術を活用し、医療・介護の現場課題を解決するデモを展示します。医療文書の自動生成や診察・カンファレンスにおける音声入力を利用した診療録・記録の作成、医療情報ガイドラインやデジタル庁 GCAS ガイドを遵守したアプリケーション開発に AWS のエージェントコーディングツール Kiro を活用する方法、 Kiro と AWS HealthOmics を利用した精密医療のためのゲノミクス解析と可視化、さらには AI を利用した研究計画書の自動作成まで、ヘルスケアにおける幅広い AI 活用の最前線をぜひブースでご体験ください。 Summit 会場：HCLS ブースへのアクセス 本ブログは AWS Summit Japan 2026 ヘルスケア・ライフサイエンスブースの展示紹介シリーズです。他の展示内容については追って公開予定です。

AWS Graviton プロセッサは世代を重ねるごとに着実に進化を遂げ、イテレーションを経るごとに、コンピューティングパフォーマンス、料金パフォーマンス、エネルギー効率の点で進歩してきました。re:Invent 2025 では、Graviton5 を搭載した初のインスタンスである Amazon EC2 M9g のプレビュー版について お知らせしました 。それ以降、お客様は、幅広いワークロードで M9g をテストし、その結果を共有してくださいました。 ClickHouse は、コードを変更することなく、M8g と比較して 36% のパフォーマンス向上を実現しました。 Honeycomb は、本番オブザーバビリティワークロードの 6 か月間の A/B テストにおいて、Graviton4 と比較してコアあたりのスループットが 36% 向上しました。  HubSpot は、MySQL データベースに M9g をデプロイし、クエリ実行時間を最大 60% 短縮しました。2026 年 6 月 10 日より、M9g インスタンスと、高速かつ低レイテンシーのローカル NVMe SSD ストレージを必要とするお客様向けの新しい M9gd インスタンスの一般提供を開始しました。どちらのインスタンスも、AWS がこれまでに構築した中で最も強力かつエネルギー効率に優れたプロセッサである Graviton5 を搭載しています。 業界では多くの Arm ベースのインスタンスが登場していますが、AWS Graviton の展開の幅広さと奥深さに匹敵するものは他にありません。カスタムシリコンの 5 つの世代と 8 年間の継続的な投資を経て、Graviton は 350 を超えるインスタンスタイプを支え、スタートアップから大企業、強固な ISV パートナーエコシステム、幅広い一連のマネージドサービスに至るまで、12 万を超えるお客様にサービスを提供しています。Graviton は、ウェブアプリケーション、マイクロサービス、分析、データベース、機械学習 (ML) 推論、Electronic Design Automation (EDA)、ゲーム、動画エンコーディングなど、多種多様なワークロードにご利用いただけます。ワークロードでのコンピューティング負荷がより高まり、ワークロードがよりデータドリブンになるにつれ、より多くのデータを移動し、ワークロードをより迅速に完了させるために、より高い処理能力に加え、ネットワークとストレージの帯域幅の拡大を求める声が高まっています。また、当社は、コンピューティング、メモリ、I/O を効率的にパッケージ化して、エネルギー効率を最大化するために、これらのインスタンスを設計しました。 AI の役割が、質問への回答から、アクションの実行、コードの実行、ツールの使用、結果の評価、複数ステップのタスクのオーケストレーションに移行するにつれ、CPU コンピューティングの需要は急速に高まっています。Graviton5 はこの変化に対応するために構築されました。192 コア、5 倍の L3 キャッシュ、最大 33% 低いコア間レイテンシー、高帯域幅を実現する DDR5 メモリを搭載した Graviton5 は、エージェントが CPU バウンドなステップでの待機時間を短縮して、より多くの命令を処理し、多数の同時実行環境に対応するとともに、アクセラレーターを常に稼働させ続けるのに役立ちます。 Meta は、そのエージェンティック AI の取り組みをサポートするために、まずは数千万コアの規模で Graviton を大規模にデプロイしており、Graviton を利用する世界最大のお客様の 1 社となっています。リアルタイム推論、コード生成、複数ステップのタスクのオーケストレーションなど、エージェンティック AI ワークロードは CPU 負荷が高く、Graviton5 の優れたコンピューティングパフォーマンス、より大きなキャッシュ、より高いメモリ帯域幅、コア密度の恩恵を享受できます。 M9g および M9gd の新機能 第 6 世代 AWS Nitro System を基盤として構築された M9g インスタンスは、Graviton4 プロセッサと比較して、より高いコンピューティングパフォーマンス、より大きなキャッシュ、改善されたメモリおよび I/O スケーラビリティを提供する AWS Graviton5 プロセッサを搭載しています。Graviton5 は、Graviton4 ベースのインスタンスと比較して、最大 25% 優れたコンピューティングパフォーマンスを提供し、ウェブアプリケーションでは最大 35%、機械学習推論では最大 35%、データベースでは最大 30%、パフォーマンスが高速化されます。AWS Graviton5 インスタンスは、AWS フリートで初めて最新世代の PCIe Gen6 と DDR5-8800 メモリをサポートする CPU として、クラウドにおけるあらゆるプロセッサインスタンスの中で最速のメモリと、前世代と比較して 5 倍の L3 キャッシュを提供します。 また、これらの改善により、エネルギー効率も向上します。そのため、性能を損なうことなく、持続可能性に関する目標を達成するのに役立ちます。 コンピューティングの増大に対応するため、ネットワーキングとストレージの帯域幅が拡張されました。M9g および M9gd インスタンスは、さまざまなサイズにわたって、平均で最大 15% 高いネットワーク帯域幅と 20% 高い Amazon Elastic Block Store (Amazon EBS) 帯域幅を提供し、最大インスタンスサイズではネットワーク帯域幅が最大 2 倍になります。また、M9g および M9gd インスタンスは、Amazon EC2 インスタンスの Amazon EBS と Amazon Virtual Private Cloud (Amazon VPC) ネットワーキングの間の帯域幅の割り当てを最大 25% 調整するのに役立つ機能である Instance Bandwidth Configuration (IBC) もサポートしています。IBC は、データベースの読み書きのパフォーマンス、クエリ処理、ログ記録など、特定の帯域幅要件を満たす必要があるワークロードのパフォーマンスの最適化に役立ちます。これらの機能強化は、高い I/O パフォーマンスを必要とするワークロードのために、より迅速なデータ移動と改善されたスループットをサポートします。 セキュリティと分離は、クラウドでワークロードを実行するための基本的な要件です。Nitro System 内では、AWS Nitro Hypervisor が、インスタンス同士で、また、AWS オペレーターからも分離するように設計されています。M9g および M9gd インスタンスでは、Nitro Isolation Engine の導入により、セキュリティの水準をさらに引き上げています。Nitro Isolation Engine は Nitro System の機能強化であり、インスタンスの分離を強制し、形式検証を活用して数学的な精度で分離の保証を提供します。Nitro Isolation Engine は、仮想マシン間の分離を強制する役割を担う専用コンポーネントです。その役割には、最小限の一連の API を通じて、仮想マシンのメモリ、CPU レジスタ状態、I/O デバイスに対するあらゆるアクセスを仲介することが含まれます。Nitro Isolation Engine は形式検証を活用しています。形式検証とは、ハードウェアまたはソフトウェアが、特定のテストケースにおいてだけでなく、意図されたとおりに動作することを数学的に証明する手法です。この高度な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなっており、数学的に証明されたクラウドセキュリティの新たな標準を打ち立てています。 M9g インスタンスは、4 GiB のメモリごとに 1 vCPU を提供し、アプリケーションサーバー、マイクロサービス、中規模データストア、ゲーミングサーバー、キャッシングフリート、コンテナ化アプリケーション、大規模 Java アプリケーション、コードリポジトリ、ウェブアプリケーション、エージェンティック AI など、幅広い汎用ワークロードに適しています。 高速かつ低レイテンシーのローカルストレージを必要とするワークロード向けには、M9gd インスタンスが、最大 11.4 TB の NVMe SSD ストレージに加えて、Graviton4 ベースの M8gd インスタンスと比較して 30% 向上した IOPS とストレージパフォーマンスを提供します。M9gd インスタンスは、アプリケーションサーバー、マイクロサービス、ゲーミングサーバー、中規模 key-value データストア、キャッシングフリート、データログ記録、メディア処理、バッチおよびログ処理、キャッシュやスクラッチファイルなどの一時ストレージを必要とするアプリケーションなど、コンピューティングとメモリのバランスと、高速かつ低レイテンシーのローカルストレージが求められる汎用ワークロードに適しています。 このファミリー全体の主な仕様を次に示します: M9g vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 4 最大 15 最大 12 large 2 8 最大 15 最大 12 xlarge 4 16 最大 15 最大 12 2xlarge 8 32 最大 17 最大 12 4xlarge 16 64 最大 17 最大 12 8xlarge 32 128 17 12 12xlarge 48 192 25 18 16xlarge 64 256 34 24 24xlarge 96 384 50 36 48xlarge 192 768 100 72 metal-48xl 192 768 100 72 M9gd インスタンスには、ローカル NVMe SSD ストレージが含まれます。以下の表は、各サイズのインスタンスストレージを示しています。コンピューティング、メモリ、ネットワーク、および EBS 帯域幅の仕様は M9g と同じです。 M9gd vCPU メモリ (GiB) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 4 1 x 59 NVMe SSD 最大 15 最大 12 large 2 8 1 x 118 NVMe SSD 最大 15 最大 12 xlarge 4 16 1 x 237 NVMe SSD 最大 15 最大 12 2xlarge 8 32 1 x 475 NVMe SSD 最大 17 最大 12 4xlarge 16 64 1 x 950 NVMe SSD 最大 17 最大 12 8xlarge 32 128 1 x 1900 NVMe SSD 17 12 12xlarge 48 192 3 x 950 NVMe SSD 25 18 16xlarge 64 256 1 x 3800 NVMe SSD 34 24 24xlarge 96 384 3 x 1900 NVMe SSD 50 36 48xlarge 192 768 3 x 3800 NVMe SSD 100 72 metal-48xl 192 768 3 x 3800 NVMe SSD 100 72 今すぐご利用いただけます M9g および M9gd インスタンスは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) リージョンでご利用いただけます。M9g および M9gd インスタンスは、 Savings Plans 、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、または専有ホストを通じて購入できます。詳細については、「 Amazon EC2 の料金 」にアクセスしてください。 M9g および M9gd インスタンスの使用開始に際して、いくつかのリソースをご利用いただけます。 AWS Graviton 開始方法ガイド は、Graviton ベースのインスタンス上でワークロードを構築、実行、最適化する方法をカバーするテクニカルガイドです。 Graviton Savings Dashboard は、Graviton ベースのインスタンス上でワークロードを実行することで実現できるコスト削減を追跡および測定するのに役立ちます。 AWS Transform は、Java アプリケーションを x86 から Graviton ベースの Amazon EC2 インスタンスに移行するためのコード変換を自動化する、AI を利用したサービスです。互換性分析、自動再コンパイル、依存関係の更新、検証を処理します。 Graviton ベースのインスタンスの詳細については、「 AWS Graviton プロセッサ 」または「 Level up your compute with AWS Graviton 」にアクセスしてください。 – Esra 原文は こちら です。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 3 回レポートです。シリーズの背景や全体像については、 前回の大阪・初回レポート をご覧ください。 大阪での 2 日間のイベントに続き、2026 年 4 月 22 日は名古屋にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト古屋 楓から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI を取り巻く世界と日本の環境、AWS の生成 AI ポートフォリオ、そして AI を自社の業務に活かしたいお客様がどのように生成 AI で業務とビジネスを変えていけるかについて、 Amazon Quick のデモを交えながらご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: 古屋によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、中部を拠点に 270 年以上の歴史を持ちながら、経営・現場の双方から生成 AI 活用に挑戦されている 1 社の事例をご紹介します。 事例紹介：タキヒヨー株式会社様 〜経営と現場、両輪で進める Amazon QuickSight によるデータ活用〜 事例紹介は タキヒヨー株式会社 様です。1751 年（江戸時代の宝暦元年）に名古屋で創業された 270 年以上の歴史を持つ繊維アパレル企業で、テキスタイル事業では愛知県一宮市に自社工場をお持ちで、伝統的な英国式紡績機を生かしたものづくりを行われています。アパレル事業では企画・製造・販売に加え、リテール事業として自社ブランドの展開もされており、東京証券取引所・名古屋証券取引所に上場されている企業です。従業員数は540 名(2026年2月末)、ニューヨークに拠点をお持ちのグローバル企業でもあります。 当日は、経営視点と現場視点の両面から、二つのプロジェクトについてパネルディスカッション形式でお話しいただきました。AWS 小嶋がモデレーターを務め、それぞれのプロジェクトの背景から成果までを伺いました。 業務 KPI ダッシュボード化プロジェクト 一つめのエピソードは、執行役員の平田様が経営の視点で推進された、業務 KPI ダッシュボードプロジェクトについてです。 アパレル業界は職人的・属人的な業務傾向があり、勘や経験に頼りがちな面があります。経営として、売上や利益といった KGI よりもっと粒度の細かい業務 KPI で組織の状態を定量的に把握し、営業活動の改善に繋げたいという思いがプロジェクトの出発点でした。ただ当時は、各組織のデータが Excel に散在し、VBA マクロで集計していたため、処理に時間がかかったりマクロが想定どおり動作しないなどの課題がありました。 この課題に対して、 Amazon QuickSight を導入し、基幹システムや NAS のデータを一元的に可視化・分析できる基盤を構築されました。ただ、導入にあたって一番苦労されたのが「現場のアレルギー反応」だったといいます。それまで各マネージャーが各々のやり方で管理業務を回していたところに、統一のダッシュボードを導入するという施策そのものに対して、「手間が増える」という受け止めから反発があったとのことです。 この壁を乗り越えるために、とにかく使い勝手にこだわってプロジェクトを進められました。便利さを実感してもらうことで理解を得て、利用も促進したいと考え、ドリルダウン機能の設計に特に注力されました。 大きなデータから詳細なデータへと段階的に掘り下げることができ、感覚的な操作で目的のデータにたどり着けるよう設計 しました。「普段の動線そのままで使える」ことで現場の抵抗感を下げることに繋げました。また、 データの欠損を補うためにWeb経由のデータ入力の仕組みも構築 し、ダッシュボードに表示されるデータの信頼性を担保する工夫も行われました。 結果として、URL にアクセスすれば経営データがすぐ確認できる状態になり、 現場のマネージャーが本来の意思決定業務に集中 できる環境が整いつつあるとのことです。今後は、分析の精度向上や、分析から起こしたアクションが業績にどう寄与するかの効果検証をしていきたい、とお話いただけました。 需要予測データのダッシュボード構築プロジェクト マーケティングチーム兼DX 推進チームの山口様が現場の実践者として推進されたプロジェクトです。 山口様ご自身はエンジニアではなく、プログラムを書いたご経験はありませんでした。ただ、「自分たちの手でなんとか活性化させたい」という思いから、需要予測データを Amazon QuickSight で可視化するダッシュボードの内製構築に取り組まれました。既存データには、複数の情報（色・柄・素材など）が一つのカラムにまとめて格納されていたため個別の値で抽出できない（例えば何色が売れているか？といった分析はできない）、需要予測の数値が絶対値のみのため、判断の基準がなくアクションに繋がらない、という二つの課題がありました。 開発にあたって、当初は Generative AI Use Cases （ AWSが提供するチャットベースの生成AIアプリケーション）で SQL を生成させていましたが、開発が難航しました。チャットベースのアプリケーションで、必要なデータ（DBのテーブル情報、全体設計、既存データなど）をAIに与えながら作業をさせようとすると、開発が進むほどコンテキストの制限に達してしまい、その都度新しい会話を立ち上げ直す必要が生じ、作業上の煩雑さを生んでいました。さらに、本来は必要なコンテキストを渡しきれない状況も発生し、そうなるとAIが出力するSQLが本来の目的と異なるものになる、といった問題も発生していました。 このような経緯から、チャットボットベースのアプリケーションに限界を感じられ、コーディングエージェントの Claude Code を Amazon Bedrock 経由で利用する方針に切り替えられました。コーディングエージェントであれば、AI エージェントがユーザー指示に応じて必要なローカルファイルを自律的に参照しにいくため、今まで作成してきたテーブル情報やシステム設計、エラー内容までを AI が自動で把握してくれ、開発効率が大きく向上しました。 データの課題については、既存のデータのETLにも取り組まれました。具体的には、一つのカラムに混在していた色・柄・素材などのデータを色別・素材別・シルエット別などにそれぞれのカラムに分けて対応し、絶対値で表示されていた需要予測値も ◎○△✕評価が動的に表示される仕組みに変更されました。この際、Claude Code を単なるコード生成ツールとしてではなく、 目的を共有し、既存のデータを生かすためにどんな方法がよいかを一緒に探る「頼れる相談相手」として活用 されました。「こういう見せ方はどうか」「この分け方だとデータが崩れないか」── ジェンガのピースを崩さないように一つずつ探していくような試行錯誤を、AI と対話しながら繰り返された とのことです。 結果として、 通常であれば外注で数ヶ月・数百万ほどかかるシステムを、非エンジニアの山口様ご自身が数週間で構築 されました。さらに、データ構造を深掘りしていく過程で、 ベンダー側でブラックボックス化していた課題に気づき、改善提案に繋げられた という副次的な効果もあったとのことです。今後は自社に蓄積された売上・在庫データの取り込みや、 Amazon Quick （Amazon QuickSight が進化して生まれた Agentic AI プラットフォーム）の AI チャット機能の活用も検討されています。 お二人から参加者へのアドバイス 最後に、お二人から参加者へのアドバイスをいただきました。 平田様からは、「 まずは現業務を可視化してデータで見られる体制を整えることが第一歩。完璧を目指すのではなく、経営層が現場に対して『小さく試して失敗から学ぶ』ことを許容し、現場の変革を後押しするスタンスが重要 」というメッセージをいただきました。 山口様からは、「 とにかくデジタル上にデータを蓄積することに注力してほしい。デジタルデータは企業の財産になる 」というメッセージ。同じ分量のデータでも、デジタルかアナログかで将来の資産価値が大きく変わる。仮にデータの中身が多少整理されていなくても、AI を活用すれば非エンジニアでも理想的な形に整形できる。 アナログからデジタルへの移行方法自体も、AI に相談してみてほしい 、とお話しいただきました。 写真: タキヒヨー株式会社 平田様・山口様、AWS 小嶋によるパネルディスカッション 経営と現場の両輪で取り組まれたお話に続いて、こうしたデータ活用の取り組みを伴走支援するパートナー様からのセッションです。 パートナーセッション：クラスメソッド株式会社様 〜生成 AI 活用のためのデータ収集〜 お客様事例のあとには、AWS プレミアティアサービスパートナーである クラスメソッド株式会社 データ事業本部 チームリーダー / プロジェクトマネージャーの三鴨 勇太 様より、「生成 AI 活用のためのデータ収集」と題したセッションをお届けいただきました。名古屋オフィスを拠点に、お客様のデータ基盤構築やデータ戦略支援を担当されている三鴨様から、データドリブン経営を支えるデータ基盤整備の考え方をお話しいただきました。 データ収集がデータドリブン経営と生成 AI 活用の共通の土台であるという点を特に強調しました。ビジネスの加速のためには、企業が持つデータ資産を生成 AI と組み合わせることで差別化につながる。そのために、属人化している情報があればそれらを効率的にデータ化し、収集していく仕組みが重要だと述べられました。 データ基盤整備の進め方としては、企業文化に合わせて、 Needs （需要があるところからデータ基盤整備を進めていく） と Seeds （できるところからデータ基盤整備を始める） の 2 つのアプローチのどちらを取ることもあり、クラスメソッド様が提供するデータ活用基盤構築・運用サービス、データ活用コンサルティング、データ活用分析研修、生成 AI 総合支援サービスなど様々な支援のあり方を紹介いただきました。 写真: クラスメソッド株式会社 三鴨様によるセッション まとめ セッション後には参加者同士のグループディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。 名古屋でご登壇いただいたタキヒヨー様とクラスメソッド様に共通していたのは、 データをいかに集め、活かせる状態に整えるか という土台の重要性と、 小さい成功体験を少しずつ積み重ねる という進め方のベストプラクティスでした。AI を活用している企業様は、データや周囲の巻き込み方など AI 以外の部分にもプラクティスを持っておられることが伝わるセッションでした。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした名古屋・3 日目に続き、次回は翌日開催の名古屋・AI で顧客を支援する IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート タキヒヨー、生成 AI を活用し社内業務効率化と 450 時間超の工数削減を実現。Amazon Bedrock を衣服デザイン等に適用、デジタル人材育成を推進 中堅・中小企業でも広がる生成 AI。企業の成長にも貢献 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

このブログは、第一三共株式会社 スマートリサーチ第二研究所と 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 アカウントチームまでお問い合わせください。