2026 年 5 月 14 日、 Amazon Bedrock Advanced Prompt Optimization を発表しました。これは、 Amazon Bedrock 上のあらゆるモデルのプロンプトを最適化するための利用できる新しいツールです。最大 5 個のモデルで、元のプロンプトと最適化されたプロンプトを同時に比較できます。この新しいプロンプト最適化を使用することで、新しいモデルに移行したり、現在のモデルのパフォーマンスを改善したりできます。それらをテストして、既知のユースケースでパフォーマンスの低下がないかをテストしたり、パフォーマンスの低いタスクを改善したりすることもできます。 この新しいプロンプト最適化ツールは、ガイドとして使用するために、プロンプトテンプレート、変数値のユーザー入力例、正解データ、評価メトリクスを受け取ります。これはマルチモーダルユーザー入力とともに使用することもできます。プロンプトテンプレートに対する入力として、 png 、 jpg 、 pdf 形式をサポートしているため、文書や画像分析などのタスク向けにプロンプトを最適化できます。 最適化のガイドとするために、 AWS Lambda 関数、LLM-as-a-judge ルーブリック、または短い自然言語による説明を提供することもできます。プロンプト最適化ツールは、評価メトリクスに基づいて、プロンプトと、結果として得られるモデル応答を最適化するために、メトリクスドリブンのフィードバックループで動作し、評価スコア、コスト見積り、レイテンシーとともに、元のプロンプトテンプレートと最終プロンプトテンプレートを出力します。 Bedrock の高度なプロンプト最適化の実際の動作 新しいプロンプト最適化の使用を開始するには、 Amazon Bedrock コンソール の [高度なプロンプト最適化] ページで [プロンプト最適化を作成] を選択します。 プロンプトを最適化する最大 5 つの推論モデルを選択します。新しいモデルに移行する場合、または現在のモデルでより優れたパフォーマンスを実現したい場合に、これを使用できます。モデルを変更する場合は、現在のモデルをベースラインとして選択するほか、最大 4 つの他のモデルを選択できます。モデルを変更しない場合は、現在のモデルを選択して最適化前後の結果を確認します。 プロンプトテンプレートは、サンプルユーザーデータ、正解データ、および評価メトリクスまたは書き換えガイダンスを含む JSONL 形式で準備する必要があります。 .jsonl ファイルの場合、各 JSON オブジェクトは単一の行に記述されている必要があります。 { "version": "bedrock-2026-05-14", // 必須; 固定値 "templateId": "string", // 必須 "promptTemplate": "string", // 必須 "steeringCriteria": ["string"], // 任意 "customEvaluationMetricLabel": "string", // customLLMJConfig または evaluationMetricLambdaArn が使用される場合は必須 "customLLMJConfig": { // 任意 "customLLMJPrompt": "string", // customLLMJConfig が存在する場合は必須 "customLLMJModelId": "string" // customLLMJConfig が存在する場合は必須 }, "evaluationMetricLambdaArn": "string", // 任意 "evaluationSamples": [ // 必須 { "inputVariables": [ // 必須 { "variableName1": "string", "variableName2": "string" } ], "referenceResponse": "string" // 任意 "inputVariablesMultimodal": [ // 任意 { "Arbitrary_Name": { // マルチモーダル変数には必須。 "type": "string", // [PDF] または [IMAGE] から選択します。Acceptable filetypes for IMAGE = png, jpg, "s3Uri": "string" // ファイルの S3 パスを入力 } ] } ] } ファイルを直接アップロードするか、または Amazon Simple Storage Service (Amazon S3) からプロンプトテンプレートをインポートして、プロンプト最適化の結果と評価データを保存する S3 出力場所を設定できます。その後、 [最適化を作成] を選択します。 Amazon Bedrock は、プロンプトテンプレートとサンプルデータ (オプションの正解データを含む) を推論モデルに自動的に送信し、評価メトリクスで応答を評価した後、フィードバックループでプロンプトを書き換えて、推論モデル向けに最適化します。指定したメトリクスに基づく評価結果と、最終的に最適化されたプロンプトが表示されます。 お気づきのとおり、独自の Python スコアリングロジックを用いた Lambda 関数、カスタムルーブリックを利用した LLM-as-a-judge、または自然言語による方向性基準といった 3 つの方法でプロンプトの質を評価できます。プロンプトテンプレートごとに 1 つの方法を選択することもできますが、1 つのジョブで複数のプロンプトテンプレートを使用できるため、必要に応じて各テンプレートごとに異なる方法を使用できます。 Lambda 関数 – 具体的なメトリクス (精度、F1 スコア、実行精度、構造化 JSON 一致など) がある場合は、独自のスコアリングロジックを含む Lambda 関数をデプロイし、プロンプトテンプレートの evaluationMetricS3Uri フィールドを設定できます。Lambda 内で中核となるのは、参照応答に照らしてモデル出力をプログラムで比較する compute_score の実装です。 LLM-as-a-judge – タスクが自由形式 (要約、生成、推論の説明) であり、ルーブリックに基づいたスコアが必要な場合は、プロンプトテンプレートの customLLMJConfig フィールドにある S3 設定ファイルで、構造化された指示と評価尺度を含む名前付きメトリクスを定義できます。Bedrock のジャッジモデルが各プロンプトと回答のペアを評価し、推論付きのスコアを返します。デフォルトのモデルは Claude Sonnet 4.6 ですが、ジャッジモデルのリストから独自のモデルを選択することもできます。 方向性基準 – 必要な特性 (ブランドボイス、フォーマット、安全上の制約) はわかっているものの、ジャッジプロンプト全体を作成したくない場合は、プロンプトテンプレートの steeringCriteria 配列を通じて、入力データセットに基準を定義できます。評価尺度を含む構造化されたメトリクスの代わりに、LLM ジャッジが総合的に評価する自由形式の自然言語基準を提供します。このオプションを使用すると、デフォルトの LLM-as-a-judge プロンプトが応答を評価し、方向性基準をジャッジプロンプトに組み込みます。この場合のジャッジモデルは、Anthropic Claude Sonnet 4.6 です。 高度なプロンプト最適化と移行方法の詳細については、 Bedrock における高度なプロンプト最適化 ガイドと GitHub のサンプルコード にアクセスしてください。 今すぐご利用いただけます Amazon Bedrock の高度なプロンプト最適化は、現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、チューリッヒ)、南米 (サンパウロ) リージョンでご利用いただけます。最適化中に消費された Bedrock モデル推論トークンに基づいて課金され、通常の Bedrock 推論と同じトークン単価が適用されます。詳細については、「 Amazon Bedrock の料金 」ページにアクセスしてください。 Amazon Bedrock コンソール で、または CreateAdvancedPromptOptimizationJob API を使用して、高度なプロンプト最適化を今すぐお試しください。フィードバックは AWS re:Post for Amazon Bedrock 宛てに、または通常の AWS サポート担当者を通じてお寄せください。 – Channy 原文は こちら です。

本記事は 2026 年 4 月 14 日に公開された「 AI, Technical Debt, and the Path to Real Fluency 」を翻訳したものです。 ※ 本記事では、原文の “AI fluency” を「AI を使いこなす力」と訳しています。単なる AI に関する知識ではなく、実践を通じて身につく AI を使った問題解決力を意味しています。 まさに今、私がお話を伺っているエンタープライズのリーダーの誰もが同じ 3 つの問題に頭を悩ませています。これらは特定の業界や企業規模に限った話ではなく、金融サービス、政府機関、ヘルスケアなどで見られます。そして、これらの問題は往々にして同時に現れます。 1 つ目の問題は、ほとんどの組織が自社にどのようなシステム、ツール、アプリケーションがあるのかを実は把握していないということです。技術資産は広範囲にわたり、ドキュメントは不十分で、多くの場合、それを理解していた人はすでに退職しています。問題があることは分かっていて、それが足かせになっていると感じているのに、どこに問題が潜んでいるのかを正確に特定できないのです。何か新しいことを始めるたびに、「はい、でも実は…」がまた一つ出てきます。 私自身、インディアナ州の CTO としてこれを身をもって経験しました。課題があることは分かっていましたが、体系的に対処できるほどの精度で毎回安定して課題を特定することができませんでした。 2 つ目の問題は、AI の幅広い導入をどう促進するかです。技術チームは AI の活用方法を模索していますが、多くはコード生成やテスト作成の段階で止まっています。明確なユースケースも、どこに AI の変革が必要で、どのようなインセンティブが求められるかを判断するフレームワークもありません。それがなければ、AI の本格的な導入は構想のままなかなか進みません。 3 つ目の問題は最も言語化しにくいものですが、チームが AI ツールを使っている様子を観察すると明らかになります。それは、トレーニングが提供する 手順通りにこなせるスキル と、自分自身の環境で実際に手を動かして身につく 問題解決の実践力 との間にあるギャップです。チームを前者から後者へ導くためには、トレーニングではなく経験が重要です。 私がお客様にお伝えしているのは、1 つのアプローチでこれら 3 つの問題すべてに対処できるということです。そしてそれは、最新のコミットまで反映された正確なドキュメントアーティファクト (コードから自動生成されるドキュメント類の成果物) の作成を必須にすることから始まります。 今いる場所から始める：未知を既知にする この業界で 30 年間働いてきましたが、優れたドキュメントを見たことがありません。効果的なドキュメント作成は時間がかかり、デリバリーのプレッシャーと相反するためです。開発者にドキュメントを書くことを期待し続ける限り、この状況は変わらないでしょう。 最近、もっと有望なものを目にしました。それは、チームが AI を使って、作業の副産物としてリアルタイムにドキュメントやその他の有用なアーティファクトをプログラム的に生成しているケースです。 AI はコードにコメントを書いたりドキュメントアーティファクトを作成したりすることを気にしません。しかも、目にしたものをうまく読み解くのが得意です。十分なコンテキストを与えてコードを読み込ませれば、チームが忘れていた、あるいはそもそも知らなかった情報、例えば依存関係、パターン、リスク、ロジックに組み込まれたアーキテクチャ上の判断などを浮き彫りにしてくれます。 実践的な出発点として、 AWS Transform custom のモダナイゼーションエージェントがあります。すぐに使える変換定義 (TD) が用意されており、ニーズに合わせてカスタマイズできます。1 つの TD でコードを読み取り、アプリケーションを変更することも移行を行うこともなく、コードに関する情報を生成できます。 レガシー資産から 1 つか 2 つのアプリケーションを選び、分析を実行して、AWS Transform custom が何を教えてくれるか確認してみてください。すでに知っていたこと、疑っていたこと、そして本当に驚くようなことが見つかるでしょう。そして、チームがアプリケーションについて実際に知っていることと、その出力結果を照合する時間を取ってください。精度の感触を掴んだら、「チームがどのようなコンテキストを追加すれば、これをもっと有用にできるか？」と自問してみてください。 既製のツールは、お客様がどのように、そしてなぜそうしているかを熟知しているわけではありません。しかし、アーキテクチャ標準、既知の制約、技術的な意思決定、ソフトウェアバージョンの基準など、企業固有のコンテキストでこれらのツールを拡張することができます。 最近、お話を伺った銀行のチームは、複雑で複数のシステムから構成される、レガシー環境全体での日付とタイムゾーンの処理について特に懸念していました。ここで有効なのが、AWS Transform custom のコード分析 TD をカスタマイズして、資産全体の日付と時刻のロジックを浮き彫りにするというアプローチです。これは自社ビジネスの将来にとって重要な課題にピンポイントで切り込む取り組みであり、汎用的な AI ユースケースとは一線を画すものです。 このプロセスから生まれるアーティファクト（リポジトリに保存された Markdown ファイルなど、お好みのテキスト形式で構いません）は、価値あるものの始まりです。それは、検索可能で体系化された、レガシー資産のナレッジベースです。プロセスを自動化して、好きな名前を付けてください。リビングドキュメントでもリアルタイムアーティファクトでも構いません。名前は重要ではありません。重要なのは、それが存在し、コードの実態に即しており、変更に合わせて更新され続けることです。 隠れたメリット：実際の業務を通じて AI を使いこなす力を身につける このアプローチの予想外の成果は、それが AI を使いこなす力を養う演習になるということです。チームが AI に何を探してほしいかを記述し、コンテキストを提供し、出力結果を磨き上げていくとき、他のあらゆる AI ユースケースに転用できるスキルを実践することになります。自分が求めるものをどう記述するか？コンテキストをどう管理するか？有用なものになるまで、どう磨き上げていくか？ これらは机上の知識ではありません。コードの分析、ドキュメントの作成、前例のない問題の解決など、AI と効果的に協働するための実践的な技術です。何かを始め、改善し、コンテキストを管理し、求めるものに到達するという実践の積み重ねこそが、AI による問題解決の核心です。こうしたスキルは研修で学ぶものではありません。実際の課題に向き合う中で身につくものです。 AI の利用を義務化しても導入の問題は解決しません。チームに AI と真剣に向き合うことを求める、具体的で意味のあるタスクを与えることで解決するのです。 すべてをつなげる：OKR にする (翻訳時注釈: OKR とは Objectives and Key Results の略で、目標と主要な結果を意味します。) ここまでで、技術資産を理解するための方法が手に入りました。そしてその過程で、AI を使いこなす力も身につけられます。では、これを組織として定着させるにはどうすればよいでしょうか？ ポートフォリオ内のすべてのアプリケーションが、年末までに現行のコードを正しく反映するリアルタイムアーティファクトを持つことを目標に設定することを検討してください。リアルタイムアーティファクトとは、一度書いて終わりのドキュメントではなく、コミットやメインブランチへのプッシュ、コードの変更があるたびに自動で更新されるアーティファクトのことです。今日実際に稼働しているアプリケーションの姿をそのまま映し出す、生きた記録を作成しましょう。 OKR は AI の使用を義務化するものではなく、成果を定義するものです。 この目標への道筋には 3 つのステップがあります： 基本的なやり方を教える仕組みを提供する。 チームにツールを使ってこれらのアーティファクトを生成する方法を示します。具体的で手を動かすようなものにしてください。 実験を奨励する。 チームが自由に試し、定義を改善し、AI を独自に使いこなす力を身につけられるようにします。多様性はバグではなく、仕様です。(翻訳時注釈: チームごとのばらつきは問題ではなく、むしろ望ましいことです) 成果を自動化する。 プロセスが理解できたら、CI/CD フックやスケジュールジョブ、エージェントトリガーとしてパイプラインに組み込みましょう。誰かが忘れずに実行しなければならない状態ではなく、アーティファクトが自動的に生成される状態にするのです。 3 つのステップすべてを完了したとき、解決しているのはドキュメントの問題だけではありません。技術資産に関する組織としてのナレッジを、一貫して自動的に生成するプロセスを構築したのです。 これらのアーティファクトは以下のことに活用できます： アプリケーションの動作に関する正確なコンテキストを必要とする AI エージェントへの情報提供 監査およびコンプライアンスワークフローのサポート オンボーディングの加速 インシデントになる前のリスクの可視化 成果 AI 導入に苦戦しているお客様は、十分にインパクトがあり、かつ安全に始められるユースケースを探していることが多いです。ここで紹介したアプローチがまさにそれです。 コードを変更したり、チームを置き換えたりするわけではありません。組織が常に必要としながらも、なかなか実現しきれなかったこと、つまり組織そのものを理解することを AI を使って行うのです。そしてその過程で、その後のあらゆる AI 投資の成功確率を高める AI を使いこなす力、習慣、組織としてのナレッジを構築することになるのです。 この記事はカスタマー ソリューション マネージャーの仁科 みなみが翻訳しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。生成AIを使ったサービスが日々の業務やプライベートに溶け込んできていますが、その裏側でどんなハードウエアが動いているのかまで意識する機会はあまり多くないかもしれません。普段車に乗るときにエンジンの仕組みまで気にしないのと似ていて、たまにボンネットを開けて覗いてみると、自分が使っているサービスへの理解が深まり、技術選定や活用方法を考えるうえでのヒントになることもあります。「 10 AI chip terms you should know (知っておきたいAIチップに関する10の用語)」というブログを見つけたのでお時間あるときに是非読んでみてください。 お昼休みの30分で最新情報を知れる場として「 もぐもぐAWS 」という企画がスタートしました。是非チェックしてみてください。 5 月 28 日には「 第7回　AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～ 」というイベントが開催されます。生成 AI の最新トレンド紹介や参加者間での情報交換を目的としたイベントですのでぜひご参加ください。 それでは 5月 11 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 株式会社アクト・ノード様の AWS 生成 AI 活用事例：Amazon Bedrock Agent Coreで実現する「見守りエージェントAI」。一次産業の人手不足と熟練知識の属人化を解決し、見守り頻度を最大48倍に拡大、生産者の工数を50%削減 」 養鶏や果樹、水産養殖といった一次産業の現場で、Amazon BedrockとAmazon Bedrock AgentCoreを活用した「見守りエージェントAI」を構築した株式会社アクト・ノードの事例を紹介するブログです。生産者がチャットで相談すると見守り要件をAIが整理し、既存の定点カメラから取得した画像を自律的に分析して異常時にアラートを出す仕組みになっています。少量の参考画像と説明文だけで多様な見守りニーズに対応できるFew-shot examplesの活用や、Amazon Bedrock AgentCoreの会話メモリでセッションをまたいだ文脈維持を実現している点が特徴です。実証では見守り頻度が1日1〜3回から30分間隔で最大48回へ拡大し、生産者の工数も50%削減されたほか、ベテランの暗黙知を構造化データとして蓄積できる副次的な効果も確認されています。人手不足と知識の属人化に悩む一次産業の現場で生成AIの活用を検討しているユーザーにとって参考になる内容です。 AWS生成AI国内事例ブログ「 「人がいない」を、AIが埋める ── 養鶏・防災・建設・化学の中堅・中小企業4社が示すDX最前線 」 人手不足や知識継承といった日本の中堅・中小企業に共通する課題に対して、生成AIとAIエージェントで解決に取り組む4社の事例をまとめたブログです。アクト・ノード（養鶏での見守りエージェント）、ヤマトプロテック（防災・書類電子保管）、大豊建設（社内生成AIツール「大豊AI」）、メック（化学の研究情報検索エージェント）の取り組みが紹介されています。ヤマトプロテックではAmazon BedrockとKiroを使ってわずか2日でAI-OCRによる書類電子保管システムを構築し、手作業入力を85%以上削減した事例、大豊建設では8ヶ月で307名が利用し規程検索で約250時間の業務時間を削減した事例、メックではAmazon Bedrock AgentCore・Amazon S3 Vectors・Strands Agentsを組み合わせた情報検索エージェントを約3週間で開発した事例など、短期間に生成AIを業務に組み込みたいユーザーにとって参考になる内容です。 AWS生成AI国内事例ブログ「 AWS GenAIIC の技術支援で実現する建設・BIM 特化基盤モデル開発 — GENIAC 第 3 期 ONESTRUCTION Ishigaki-IDS 事例 」 GENIAC第3期において、ONESTRUCTION株式会社が建設・BIM領域に特化した基盤モデル「Ishigaki-IDS」を開発した事例を紹介するブログです。BIMモデルへの情報付与・照査内容を定義する新しいXML規格「IDS（Information Delivery Specifications）」に対応するため、Qwen3（8B/14B/32B）をベースに、継続事前学習（CPT）、教師ありファインチューニング（SFT）、検証可能な報酬による強化学習（RLVR）の3段階パイプラインで学習を進めています。学習基盤にはAmazon EC2 P5enインスタンス（NVIDIA H200 GPU搭載）を2ノード、AWS ParallelClusterによる分散学習のオーケストレーション、Amazon FSx for Lustreによる高スループットな共有ストレージが使われています。AWS Generative AI Innovation Center（GenAIIC）からは、学習データ設計・評価ベンチマーク・学習テクニック・インフラ・実験結果の診断まで隔週で技術アドバイザリーを受ける形で支援され、最終的に「Ishigaki-IDS-8B」とベンチマーク「IDS-Bench」がHugging Faceで公開されています。 ブログ記事「 3人月の開発を2日間で ─ 日立グループ初の AI-DLC 実践で得たリアルな手応え 」 2026年1月22〜23日にAWS Loft Tokyoで開催された「11社合同 AI-DLC Unicorn Gym」に株式会社日立産業制御ソリューションズが参加した体験レポートです。「分散したIT資産・セキュリティデータの統合基盤構築」をテーマに、Kiroを中心にAWS Lambda・Amazon DynamoDB・AWS CDKを使った構成を2日間で形にしています。従来手法で約530時間（3人月相当）と見積もられた開発を、7名×10時間の約70時間で動作するプロトタイプまで到達させた点が特徴です。AI駆動開発を社内で本格的に検討したいユーザーにとって、前提条件（業務担当者の同席、結合テストやセキュリティ審査は別途）も含めて参考になる内容です。 ブログ記事「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート 」 2026年4月13日にAWS大阪支社で開催された「AWS Local Executive Roadshow」シリーズ第1回の開催レポートです。全国5都市・計8回のシリーズの初回として、エグゼクティブや情シス部門に向けて生成AIをビジネス価値に転換するためのポイントが、関西拠点の実践企業の事例を中心に共有されました。文具メーカーのサクラクレパスでは、Amazon BedrockとDifyを組み合わせた社内AI共通基盤を「情シス主導×ユーザー作成」の役割分担で運用している事例、化学メーカーのメックではAWS Amplify、Amazon Bedrock AgentCore、Amazon S3 Vectors、Strands Agentsを使ったAgentic RAGを自前構築している事例が紹介されています。 ブログ記事「 AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 」 2026年4月14日にAWS大阪支社で開催された「AWS Local Executive Roadshow」シリーズ第2回の開催レポートです。AIで顧客を支援するIT企業のエグゼクティブ向けに、開発力をストック型収益に変えるためのビジネスモデル変革をテーマに開催されました。ロジカル・アーツのSaaS「HARMONY」では、Amazon Connectベースに7つのAI機能を組み込んだAIコンタクトセンターソリューションで、アフターコールワーク時間を20分から5分へ短縮し、ランニングコストを85%削減した事例が紹介されています。アプリズムの競走馬見守りプロダクト「aiba」では、Amazon SageMaker AIで独自の骨格推定モデルを反復学習させ、AWS IoT Coreのフリートプロビジョニングでデバイスのプロビジョニング工数を約90%削減した取り組みが共有されています。 ブログ記事「 最新の Amazon Q コスト機能による FinOps の変革 」 Amazon Q Developerに追加されたコスト分析・最適化機能を使って、FinOps（クラウド財務運用）の進め方をどう変えられるかを解説するブログです。AWS Cost Explorer、AWS Cost Optimization Hub、AWS Compute Optimizer、AWS Budgets、AWS Pricing APIなど複数のサービスから情報を横断的に取得し、自然言語の質問に対して時間単位・リソースレベルの粒度で回答できるようになっています。設計段階のアーキテクチャを読み取ってAmazon EC2やAmazon S3の料金見積もりを生成したり、AWS GravitonやサーバーレスへのWhat-if分析を行ったりと、開発者がコスト意識を「シフトレフト」させやすくなる点が特徴です。 ブログ記事「 Hannover Messe 2026 AWS ブースレポート 」 世界最大級の産業見本市「Hannover Messe 2026」のAWSブースを紹介するレポートです。スマート生産・サプライチェーン・製品設計開発・スマートプロダクトの4領域で、Amazon Bedrock、Amazon Bedrock AgentCore、Amazon Nova、Amazon Quick、AWS IoT Core、Amazon Connect、Kiroなどを組み合わせたデモが展示されました。また、注目の「AI-Driven Product Journey」では、来場者がキオスクで入力したデザインから生成AIがオリジナルデザインを作り、AMR・協働ロボット・レーザー彫刻機・AI画像検査・ヒューマノイドロボットが連携して金属コースターを製造する一連のフローを、エージェントAIが自律的にオーケストレーションする様子が披露されました。スマート生産の「Investigation Trace」によるエージェントの推論過程の可視化や、Kiroで7インチHMI向けの空調管理システムをC++で開発するデモを30分以内で完了させる事例など、実運用フェーズに進みつつある産業AIの最新動向を把握したいユーザーにとって参考になる内容です。 ブログ記事「 Specがさらに高速にスマートに進化 」 Kiroの仕様駆動開発（spec-driven development）機能に、開発スピードを高めながら品質を維持するための3つの新機能が追加されました。タスクリストの依存関係を自動でグラフ化して独立タスクを並列実行する「Run tasks in parallel」、要件・設計・タスクを一度に自動生成する「Quick plan mode」、そしてLLMと自動推論を組み合わせるNeurosymbolic AIで要件の曖昧性や論理矛盾を検出する「Requirements analysis」の3つです。タスクの並列実行では、同じファイルを編集するタスクは並列化を避けつつ、独立タスクは「waves」としてまとめて同時実行する仕組みになっており、1時間以上かかっていた大規模な仕様の実装時間が約4分の1に短縮された例が紹介されています。Quick plan modeでは2〜4個の的を絞った質問とワークスペースの自動スキャンで承認プロセスを簡略化し、Requirements analysisでは「レコードを削除」がハード削除かソフト削除かといった解釈のばらつきを実装前に検知できます。 ブログ記事「 探求のための広い余地：20ドル分の有料ティアサインアップボーナス 」 Kiroの新規有料サブスクライバー向けサインアップボーナスが、これまでの500クレジットから1,000クレジット相当（20ドル分）に倍増されました。初日からClaude Opus 4.7を含むプレミアムモデルにフルアクセスでき、ソーシャルログインまたはBuilder IDで登録した利用者が対象になります。無料ティアの構成も見直され、Claude Sonnet 4.5に加えてQwen3 Coder Next、DeepSeek v3.2、MiniMax 2.1といったオープンウェイトモデルがクレジットカード不要で使えるようになりました。 サービスアップデート Claude Platform on AWSが一般提供開始 Anthropic社のネイティブなClaude Platformの体験を、既存のAWSアカウントから直接利用できる「Claude Platform on AWS」が一般提供開始されました。AWSがこの体験を提供する最初のクラウドプロバイダーとなり、AWSのIAM認証情報、統合請求、AWS CloudTrailによる監査ログをそのまま利用できます。Claude Managed Agents（ベータ）、Advisor strategy（ベータ）、ウェブ検索、ウェブフェッチ、コード実行、Files API（ベータ）、Skills（ベータ）、MCPコネクタ（ベータ）、プロンプトキャッシング、引用、バッチ処理など、Anthropic側の最新機能に同じAPIで直接アクセスできる点が特徴です。東京リージョンを含む17のAWSリージョン（米国・欧州・アジアパシフィックなど）で利用でき、別アカウント・別請求の管理を増やさずにClaudeの最新機能を試したい開発チームや企業にとって参考になる内容です。 Amazon Bedrockが高度なプロンプト最適化と移行ツールを発表 Amazon Bedrockに、プロンプトの最適化と複数モデル間での比較評価を一括で行える「Advanced Prompt Optimization」機能が追加されました。プロンプトテンプレート、サンプル入力、任意の正解データ、評価指標または自然言語の評価基準を入力すると、元のプロンプトと最適化後のプロンプトを最大5モデルで同時に比較できます。JPG・PNG・PDFなどのマルチモーダル入力にも対応しており、出力には最終プロンプトに加えて評価スコア・コスト見積もり・レイテンシーがまとめて表示されます。現行モデルをベースラインに据えて移行先候補と比較できるため、モデル変更時のパフォーマンスの後退（リグレッション）を事前に検知しやすくなる点も特徴です。 Kiro CLI 2.3.0でMCPサーバー接続の拡充、~/.kiroの再配置、TUIのリマップに対応 Kiro CLIのバージョン2.3.0がリリースされ、MCPサーバーへの接続性、Kiroのインストール場所、ターミナルUIのキーバインドのカスタマイズ性を高める4つの機能が追加されました。動的クライアント登録に対応していないHTTPベースのMCPサーバーに対しては、設定ファイルに事前登録済みの oauth.clientId を指定することで、Slack・GitHub・Figmaなどのサービスを独自プロキシなしで使えるようになります。 KIRO_HOME 環境変数を設定するとグローバルエージェント・プロンプト・スキル・設定・セッションの保存先を変更でき、複数マシンでのdotfiles管理や仕事用・個人用プロファイルの分離、コンテナ環境での状態の隔離がしやすくなります。V2 TUIのキャンセル・メニュー終了・終了アクションのキーバインドをリマップできるようになったほか、エージェントの実行結果を $AGENT_DISPLAY_OUT と $AGENT_CONTEXT_OUT という2つの新チャネルに出力する仕組みも追加され、コンテキスト消費を抑えつつ進捗表示と内部メモを使い分けられるようになっています。 Amazon SageMaker AIがQwen3.6のサーバーレスモデルカスタマイズに対応 Amazon SageMaker AIで、Alibaba Cloudが提供する「Qwen3.6 27Bパラメータモデル」に対するサーバーレスのファインチューニングがサポートされました。教師ありファインチューニング（SFT）と強化学習ファインチューニング（RFT）の両方に対応しており、これまではベースモデルのデプロイのみだったところから、特定のドメインやワークフローに合わせたカスタマイズが可能になります。インフラのプロビジョニングやトレーニングのオーケストレーションはAmazon SageMaker AIが担い、利用した分だけの従量課金モデルで使える点が特徴です。東京リージョンを含む4つのAWSリージョン（米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド））で提供されています。 AWS Transformがエージェントビルダーツールキット「Kiro Power」を提供開始 AWS Transform向けのエージェントビルダーツールキット「Kiro Power」の一般提供が開始されました。「AWS Transform composability initiative」の一環として提供され、移行・モダナイゼーションを担うパートナーやISV、ユーザーが、自社の専門エージェント・ツール・ナレッジベース・ワークフローをAWS Transformのエージェント型AI機能と統合できます。ツールキットはエージェントの構築から共有、AWS Transformへの登録、ディスカバリーまでのライフサイクル全体をカバーしており、構築したカスタムエージェントは「Kiro Power Marketplace」を通じて他のユーザーからも利用される形で展開できます。 AWS Transformがカスタマー所有のアーティファクトストアをサポート アセスメント・移行・モダナイゼーションをAI駆動で進めるAWS Transformで、変換アーティファクトの保存先として、ユーザー自身が所有するAmazon S3バケットを設定できるようになりました。任意でAWS KMSキーによる暗号化を組み合わせることもでき、自社のIAMポリシーでアクセス制御を行えます。S3バケットへ直接ファイルをアップロードすればAWS Transformのエージェントが即座に利用でき、複数のAWSアカウントにまたがるアーティファクトを集約管理できる点が特徴です。 Amazon SageMaker JumpStartで画像生成・テキスト埋め込みの新モデルが利用可能に Amazon SageMaker JumpStartに、Black Forest Labsの画像生成モデル「FLUX.2-klein-base-4B」と、Qwenのテキスト埋め込みモデル「Qwen3-Embedding-0.6B」の2つが追加されました。FLUX.2-klein-base-4Bはコンパクトなアーキテクチャでリアルタイム画像生成とマルチリファレンス編集に対応し、13GBのVRAMがあれば動作します。Qwen3-Embedding-0.6Bは100以上の言語に対応したテキスト埋め込みモデルで、検索・分類・クラスタリング・バイテキストマイニングといった用途に向き、出力次元の柔軟な指定や指示認識型の埋め込みにも対応しています。 Amazon SageMaker JumpStartで音声認識・テキスト読み上げの3つの新モデルが利用可能に Amazon SageMaker JumpStartに、Qwenの音声系モデル3種が追加されました。多言語TTSで音色・感情・韻律の指示制御に対応する「Qwen3-TTS-12Hz-1.7B-CustomVoice」、3秒の音声入力からの高速ボイスクローニングが可能な「Qwen3-TTS-12Hz-1.7B-Base」、52言語・方言に対応し複雑な音響環境に強い音声認識モデル「Qwen3-ASR-1.7B」の3つです。数クリックでデプロイできるJumpStartの特性を活かし、リアルタイム対話型のボイスアプリ、仮想アシスタント、文字起こしや多言語カスタマーサポート、リアルタイム字幕といった幅広いユースケースに対応します。 Amazon SageMaker JumpStartでエージェント型コーディングと効率的AI向けの2つの新モデルが利用可能に Amazon SageMaker JumpStartに、Z.aiの「GLM-5.1-FP8」とMicrosoftの「Phi-4-mini-instruct」の2つの新モデルが追加されました。GLM-5.1-FP8はリポジトリレベルのコード生成、ターミナルタスク、複雑なデバッグワークフローを得意とするエージェント型ソフトウェアエンジニアリング向けのモデルで、長期的な反復推論で解を磨き上げるタイプです。Phi-4-mini-instructはメモリやレイテンシーの制約がある環境向けにコンパクトに作られており、24言語と関数呼び出しに対応し、推論・数学・論理処理に強みがあります。自動コードレビューパイプラインやAI開発環境を構築したいユーザーや、エッジ・低レイテンシー環境で多言語チャットボットやリソース制約下の推論を扱いたいユーザーにとって参考になる内容です。 Amazon SageMaker Data AgentがIAM Identity Centerドメインで利用可能に Amazon SageMaker Unified StudioのData Agentが、AWS IAM Identity Centerで構成されたドメインでも利用できるようになりました。Amazon Athena、Amazon Redshift、Amazon S3、AWS Glue Data Catalogなどに接続し、自然言語で分析目的を伝えるとPythonまたはSQLのコードを生成します。ノートブックのセル、選択中のテーブル、クエリ履歴を会話のコンテキストとして引き継ぎ、コード生成前に段階的な実行プランを提示する仕組みになっています。 Amazon SageMaker Feature StoreがSageMaker Python SDK V3をサポート 機械学習モデル向けの特徴量を保存・共有・管理するAmazon SageMaker Feature Storeが、SageMaker Python SDK V3（v3.8.0以降）に対応しました。フィーチャーグループの作成時にAWS Lake Formationを有効化することで、オフラインストアのデータに列レベル・行レベルのアクセス制御を適用できます。加えて、Apache Icebergのコンパクションやスナップショットの有効期限といったテーブルプロパティを、SDK経由で直接設定できるようになっています。 Amazon SageMakerノートブックインスタンスでG6インスタンスのリージョン拡大 Amazon SageMakerノートブックインスタンスで利用できるAmazon EC2 G6インスタンスが、東京リージョンを含む8つのAWSリージョン（東京、ムンバイ、シドニー、ロンドン、パリ、フランクフルト、ストックホルム、チューリッヒ）に拡大されました。G6は最大8基のNVIDIA L4 Tensor Core GPU（1基あたり24GBメモリ）と第3世代AMD EPYCプロセッサを搭載しています。 Amazon SageMaker StudioノートブックがP6-B200インスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで、Amazon EC2 P6-B200インスタンスが米国東部（バージニア北部）リージョンで利用できるようになりました。NVIDIA Blackwell GPUを8基（高帯域幅GPUメモリ合計1,440GB）と第5世代Intel Xeonプロセッサ（Emerald Rapids）を搭載しており、AIトレーニングでP5enと比較して最大2倍の性能が示されています。現時点では東京・大阪リージョンは対象外です。 Amazon SageMaker StudioノートブックでG6eインスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで、Amazon EC2 G6eインスタンスが東京リージョンを含む6つのAWSリージョン（東京、ソウル、ドバイ、フランクフルト、ストックホルム、スペイン）に拡大されました。G6eは最大8基のNVIDIA L40s Tensor Core GPU（1基あたり48GBメモリ）と第3世代AMD EPYCプロセッサを搭載しており、EC2 G5と比べて最大2.5倍の性能が示されています。 Amazon SageMaker StudioノートブックでG6インスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで利用できるAmazon EC2 G6インスタンスが、中東（ドバイ）とアジアパシフィック（マレーシア）の2つのAWSリージョンに新たに拡大されました。G6は最大8基のNVIDIA L4 Tensor Core GPU（1基あたり24GBメモリ）と第3世代AMD EPYCプロセッサを搭載し、EC2 G4dnと比較してディープラーニング推論性能が約2倍となります。 Amazon SageMaker StudioノートブックでP4deインスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで利用できるAmazon EC2 P4deインスタンスが、東京リージョンを含む3つのAWSリージョン（東京、シンガポール、フランクフルト）に拡大されました。P4deは80GBのHBM2eメモリを搭載したNVIDIA A100 GPUを8基使用し、合計640GBのGPUメモリを提供します（P4d比でGPUメモリが2倍）。 Amazon SageMaker StudioノートブックでP5.48xlインスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで利用できるAmazon EC2 P5.48xlインスタンス（NVIDIA H100 Tensor Core GPU搭載）が、東京リージョンを含む7つのAWSリージョン（サンフランシスコ、東京、ムンバイ、シドニー、ジャカルタ、ロンドン、ストックホルム）に拡大されました。ディープラーニングやハイパフォーマンスコンピューティング向けに設計されたインスタンスです。 Amazon SageMaker StudioノートブックがP5.4xlインスタンスタイプをサポート Amazon SageMaker Studioノートブックで、Amazon EC2 P5.4xlインスタンス（NVIDIA H100 Tensor Core GPU搭載）が一般提供開始されました。東京リージョンを含む7つのAWSリージョン（米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、ムンバイ、東京、ジャカルタ、サンパウロ）で利用できます。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。

本記事は 2026 年 5 月 5 日 に公開された「 Amazon Aurora DSQL for global-scale financial transactions 」を翻訳したものです。 Amazon Aurora DSQL を使えば、強い整合性と低レイテンシーを両立しながら、複数の AWS リージョンにまたがるグローバル規模の金融トランザクションを実行できます。従来はこの選択にコストが伴いました。夜間のリコンシリエーションバッチ、手動フェイルオーバー手順、顧客残高や決済を扱うシステムでの短時間のデータ不整合リスクなどです。Amazon Aurora DSQL はグローバルに整合性のある強い耐久性を持つトランザクションを、アクティブ-アクティブの可用性とサーバーレス運用で提供し、従来のトレードオフを解消します。 本記事ではまず、分散整合性に対する従来のアプローチが金融ワークロードで不十分な理由を検証します。次に Amazon Aurora DSQL のアーキテクチャが分散整合性の課題にどう対処するかを説明し、3 つの本番ユースケース (勘定系、グローバル支出管理、デジタル通貨インフラストラクチャ) に適用します。最後に実装上の考慮事項と、 Amazon Aurora DSQL 無料利用枠 での始め方を紹介します。 金融サービスデータベースに求められる要件の変化 金融データベースには常に整合性と可用性が求められてきました。変わったのは運用環境です。10 年前、トランザクション処理のほとんどはリージョナルでした。銀行の中央台帳は 1 つのデータセンターで稼働し、トレーディングシステムは単一の取引所に対応し、日次バッチによる突合処理は当たり前のものとして受け入れられていました。現在、顧客は地理的に分散した拠点間でのリアルタイムな可視性を求め、規制当局は取引報告の期限を厳格化し、マルチリージョンでの可用性はもはや付加価値ではなく競争上の必須要件となっています。 よくあるシナリオで課題を説明します。あるリージョンの口座から引き落とし、別のリージョンの口座に入金する処理を、単一のトランザクションで実行する必要があります。従来の解決策は 2 フェーズコミット (2PC) で、コーディネーターノードが各参加者から合意を集めてからコミットします。動作はしますが、コーディネーターが単一障害点となり、ラウンドトリップ全体にわたってロックを保持し、部分的な障害にはテストが困難で運用コストの高いリカバリロジックが必要です。リージョン間ではコーディネーターのラウンドトリップに数百ミリ秒が加わり、クロスリージョントランザクション中のロック競合が最も重要なタイミングでスループットを制限する可能性があります。 多くのチームが代替手段として選ぶのは、非同期レプリケーションによる結果整合性、競合解決を伴うマルチプライマリ構成、あるいは専用の分散データストアです。これにより 2PC の調整負荷は回避できますが、その負担はアプリケーション開発者にのしかかります。共有状態を扱うサービスすべてに冪等性、競合解決、突合ロジックを実装しなければなりません。一時的な不整合を許容し、それを運用リスクモデルに織り込むチームもあります。分析やキャッシュのワークロードでは合理的なトレードオフですが、顧客残高、決済、取引を直接扱う場合には正当化が難しくなります。 Amazon Aurora DSQL はこの 2 つのアプローチの間を埋めます。2PC の調整負荷なしに強い整合性を提供し、結果整合性の突合負債も発生しません。 Amazon Aurora DSQL のアーキテクチャと金融サービスへの意義 Amazon Aurora ストレージエンジンの利点を、AWS リージョン間の分散運用向けに拡張した形で利用できます。 Amazon Aurora DSQL の紹介 でアーキテクチャの詳細を解説しています。ここでは金融サービスワークロードで最も重要な特性に焦点を当てます。 アクティブ-アクティブのマルチリージョン設計です。クラスターをデプロイした全リージョンで読み書きが可能です。各リージョンのノードは対等なピアとしてトランザクションを受け付け、書き込みトランザクションはリージョン間およびウィットネスリージョンに同期レプリケートされます。 ウィットネスリージョン は、軽量かつ中立的な第三の拠点で、コミットの判定に参加することで 3 拠点間のクォーラム（多数決）を維持し、トランザクションの永続性を確認します。クォーラムには 3 つの参加者のうち少なくとも 2 つの合意が必要なため、3 リージョンが必要です。2 つのアクティブリージョンのうち 1 つが停止しても、残りのアクティブリージョンとウィットネスリージョンで過半数を構成できるため、中断やデータ損失なくトランザクションのコミットが継続されます。もしウィットネスなしの 2 リージョン構成だったら、1 リージョンが失われた時点で、処理中のトランザクションがコミットされたのかどうかすら確認できなくなります。 マルチリージョンクラスターにより、データベースレイヤーで最大 99.999% の可用性を実現します。マルチリージョン運用を必要とするレジリエンス戦略において、手動フェイルオーバー、プライマリ/セカンダリの調整、フェイルオーバー後のデータ突合の構築・維持が不要になります。これは、各リージョンで独立して動作するアクティブ-アクティブのアプリケーション層と組み合わせると最も効果的で、スタック全体がすべてのレイヤーで集中的な調整なしにリージョン障害を吸収できるようになります。 サーバーレスで運用・スケーリング。キャパシティプランニング、レプリカ管理、シャーディング戦略の設計は不要です。コンピュート、コミット、ストレージの各レイヤーが独立して自動的にスケールします。Amazon Aurora DSQL は消費したコンピュートと I/O に対して課金されます。マーケットオープンや四半期末のスパイク時に使用した分だけ支払い、閑散期のアイドルには課金されません。予測困難な需要パターンを持つ金融ワークロードでは、従来のプロビジョニング型データベースアーキテクチャと比較して大幅なコスト削減が見込めます。 整合性モデル。トランザクションは最寄りのリージョンでローカルに実行され、Amazon Aurora DSQL は変更を伴うトランザクションのコミット時にのみリージョン間で調整します。整合性モデルはスナップショット分離を伴う楽観的同時実行制御 (OCC) で、トランザクション実行中にロックを保持しません。読み取り専用トランザクションはローカルのレイテンシーで完了し、リージョン間調整なしに一貫性のあるスナップショットを参照できます。書き込みトランザクションはコミット時にのみクロスリージョン調整コストが発生するため、調整ウィンドウは最小限に抑えています。 代わりに、各トランザクションはデータの一貫したスナップショットに対して動作し、Amazon Aurora DSQL はコミット時にのみ競合をチェックします。2 つのトランザクションが同じ行を変更した場合、一方が正常にコミットされ、もう一方はシリアライゼーションエラーとなり、アプリケーション側でリトライします。 この特性は以降のユースケースで重要です。通常は異なる行 (異なる口座、異なる取引) に触れるワークロードでは、競合は最小限です。同じ行を頻繁に更新するワークロードでは、カウンターをインプレースで更新するのではなく新しい行を追加するなど、行レベルの競合を減らすスキーマ設計が有効です。 Amazon Aurora DSQL のドキュメント で OCC 向けスキーマパターンの詳細なガイダンスを提供しています。 PostgreSQL 互換性。PostgreSQL を使用しているチームは、既存の SQL 構文、ドライバー、クライアントライブラリを Amazon Aurora DSQL でそのまま使用できます。本記事の例では馴染みのある PostgreSQL パターンを使用しており、既存のリレーショナルスキーマを最小限の変更で移行できます。Amazon Aurora DSQL が現在サポートしていない PostgreSQL 機能については、 Amazon Aurora DSQL の使用に関する考慮事項 を参照してください。 金融サービスのユースケース 以下のユースケースに共通するテーマは、複雑なマルチデータベースアーキテクチャを単一のグローバルに整合性のあるデータレイヤーに置き換え、突合プロセスや手動フェイルオーバー手順を排除する点です。異なるのは具体的な運用コンテキストと規制上の要件です。 勘定系と台帳の整合性 勘定系アプリケーションは、顧客口座、残高、トランザクションの正確なリアルタイム台帳を管理します。地理的に分散して運用する大規模銀行は、従来はリージョンごとに別々の勘定系を運用するか、バッチ処理でデータを同期していました。 これには 2 つの問題があります。プライマリリージョンがダウンすると、トランザクション処理が停止するか、データ損失を伴うフェイルオーバーが発生します。通常運用時でも、あるリージョンでの残高クエリが別のリージョンで処理された最近のトランザクションを反映していない場合があります。規制当局と顧客は、リージョン間での継続的な可用性とリアルタイムの正確性を期待しています。 Amazon Aurora DSQL は、各支店やリージョンのアプリケーションがローカルエンドポイントに読み書きを行い、更新は全リージョンに自動伝播することで、この問題を解決します。米国東部 (オハイオ) で処理された入金は、米国西部 (オレゴン) から照会する窓口担当者にも即座に表示されます。あるリージョンが利用不能になっても、残りのリージョンはデータ損失も手動フェイルオーバーもなくトランザクション処理を継続します。データベースが単一のグローバルに整合性のある状態を提供するため、システム間の突合なしに全リージョンから規制報告を作成できます。 具体例として、2 つの口座間の資金移動を考えます。従来のマルチリージョンアーキテクチャでは、リージョナルデータベース間の部分的な障害に対処するために、Saga パターン、メッセージキュー、補償トランザクションが必要になる場合があります。Amazon Aurora DSQL では単一の ACID (原子性、整合性、分離性、耐久性) トランザクションに簡素化できます。 以下のスキーマは、Amazon Aurora DSQL の分散アーキテクチャ向けに最適化されたいくつかの設計選択を示しています。UUID 主キーはリージョン間でのシーケンシャル ID の調整負荷を回避します。CHECK 制約はアプリケーションコードではなくデータベースレベルでビジネスルールを適用します。TIMESTAMPTZ 列はどのリージョンがトランザクションを処理しても一貫したタイムスタンプを提供します。これらの例ではわかりやすさのためにリテラル値を使用しています。本番環境では SQL インジェクションを防ぐため、データベースドライバーを通じたパラメータ化クエリを必ず使用してください。アプリケーションコードで送金開始前に十分な残高があることを検証する必要があります。以下の SQL は Amazon Aurora DSQL playground でインタラクティブに実行できます。 -- Schema: simplified core banking ledger CREATE TABLE accounts ( account_id UUID PRIMARY KEY, customer_id UUID NOT NULL, balance NUMERIC(18,2) NOT NULL CHECK (balance >= 0), currency VARCHAR(3) NOT NULL, updated_at TIMESTAMPTZ DEFAULT NOW() ); CREATE TABLE transactions ( transaction_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), from_account UUID NOT NULL, to_account UUID NOT NULL, amount NUMERIC(18,2) NOT NULL, description TEXT, created_at TIMESTAMPTZ DEFAULT NOW() ); -- Funds transfer as a single ACID transaction BEGIN; UPDATE accounts SET balance = balance - 500.00, updated_at = NOW() WHERE account_id = 'acct-1234' AND balance >= 500.00; UPDATE accounts SET balance = balance + 500.00, updated_at = NOW() WHERE account_id = 'acct-5678'; INSERT INTO transactions (from_account, to_account, amount, description) VALUES ('acct-1234', 'acct-5678', 500.00, 'Funds transfer'); COMMIT; 口座の更新と取引き録は、アプリケーションがどのリージョンに接続していても原子的にコミットされます。送金元の残高が不足している場合、CHECK 制約で弾かれトランザクション全体がロールバックされます。片方の口座だけが引き落とされ、もう片方に入金されていない、そんな中間状態は起こりません。Saga オーケストレーション、補償トランザクション、夜間の突合バッチは不要です。 振替は通常、異なる口座行を操作するので、異なる口座に対する並行トランザクションは Amazon Aurora DSQL の楽観的同時実行モデルで競合なくコミットされます。まれに 2 つのトランザクションが同時に同じ口座を対象とするケースでは、OCC がコミット時に競合を検出し、一方のトランザクションがリトライされます。アプリケーション側でロックを取る必要はなく、整合性は保たれます。 グローバル支出管理と法人カードシステム 現代の支出管理サービスは、世界中の数千の企業のあらゆる金融取引を承認・追跡する集中的な意思決定レイヤーとして機能します。カードの利用、ACH (Automated Clearing House) 送金、電信送金、経費精算のいずれも、残高、与信限度額、加盟店管理、リスクスコア、会計マッピングに対する複数のトランザクション更新を発生させます。これらの操作は異なるロケーションから数秒以内に発生することが多く、わずかな不整合 (例: 承認判定に対して残高更新が遅れる) でも取引の拒否、過剰支出、不正リスクの露出につながります。 Amazon Aurora DSQL を使えば、リージョン間で単一のグローバルに整合性のある台帳を維持できます。各リージョンがローカルで書き込みを受け付け、同じグローバルに整合性のあるトランザクションセットの一部としてコミットします。これは、異なるリージョンにデプロイされた複数の決済プロセッサーや銀行パートナーと連携する場合に特に有用です。最大の価値は、統合された台帳と突合レイヤーにあり、リージョナルデータベース間のバッチ同期なしにグローバルに整合性のある残高ビュー、支出管理、会計記録を維持できます。 デジタル通貨インフラストラクチャ グローバルなデジタル通貨発行体は、複数のリージョン、ブロックチェーン、銀行パートナーにまたがる発行、償還、送金、決済をサポートする常時稼働サービスを運用しています。これらのサービスは、トークン供給量、顧客残高、取引状態を正確に追跡するリアルタイム台帳の維持が不可欠です。発行（ミント）、焼却（バーン）、送金イベントを取引所、決済プロセッサー、銀行パートナーの近くでローカルに処理でき、Amazon Aurora DSQL がそれらを原子的にコミットしてグローバルに可視化します。流通供給量、顧客残高、取引履歴はリージョン間で継続的に同期されます。 AWS 無料利用枠で始める 永続的な AWS 無料利用枠 と、分散データベース設計の専門知識がなくても開発を加速する AI スキルを利用できます。無料利用枠には毎月 100,000 Database Processing Units (DPU) と 1 GB のストレージが無料で含まれ、開発環境の運用や小規模アプリケーションのサポートに十分な容量です。 Amazon Aurora DSQL AI スキル は、分散ワークロード向けのスキーマ設計、外部キーなしの参照整合性、初日から本番対応のアプリケーション構築を支援します。Kiro や Claude Code などの AI コーディングツールと連携し、分散トランザクション向けに最適化されたスキーマ設計、レジリエントなマルチリージョンアプリケーションアーキテクチャの構築、既存の PostgreSQL ワークロードの Amazon Aurora DSQL への移行などのタスクについてインタラクティブなガイダンスを提供します。 Amazon Aurora DSQL スキルの全セットについては、 Amazon Aurora DSQL ステアリングガイド を参照してください。 まとめ 本記事では、Amazon Aurora DSQL がグローバルに分散した ACID トランザクション、最大 99.999% の稼働率を持つアクティブ-アクティブの可用性、サーバーレス運用を単一のマネージドサービスで実現する方法を紹介しました。2 フェーズコミットと結果整合性の限界にアーキテクチャがどう対処するかを説明し、金融サービスチームが構築する 3 つの本番パターン (原子的なクロスリージョン送金を行うコアバンキング台帳、グローバルに整合性のある経費管理システム、リージョン間で流通供給量と残高を同期するデジタル通貨プラットフォーム) に適用しました。 実際に試すには、 Amazon Aurora DSQL サービスページ から無料利用枠クラスターを作成し、 開発者ガイド で接続設定、クエリパターン、スキーマ設計を確認してください。アーキテクチャの詳細や機能比較については Amazon Aurora DSQL のドキュメント を参照し、移行のビジネスケース構築については AWS アカウントチームにご相談ください。 著者について Trevor Spires Trevor は、AWS の金融サービス担当シニアソリューションアーキテクトです。キャピタルマーケットおよびフィンテックのお客様と密接に連携し、コアインフラストラクチャと AI システムのクラウドでのスケーリングとセキュリティ確保を支援しています。 Raluca Constantin Raluca は、Amazon Aurora DSQL を専門とする AWS のシニアデータベースエンジニアです。Oracle、MySQL、PostgreSQL、クラウドネイティブソリューションにわたる 18 年のデータベース経験を持ち、データベースのスケーラビリティ、パフォーマンス、リアルタイムデータ処理に注力しています。 Jigna Gandhi Jigna は、AWS の金融サービス担当シニアソリューションアーキテクトです。フィンテック、Web3、銀行組織と密接に連携し、最新の金融プラットフォームを支えるスケーラブルでセキュアかつレジリエントなクラウドおよび AI ソリューションを設計しています。 Narendra Reddy Bathina Narendra は、AWS の金融サービス担当テクニカルアカウントマネージャーです。フィンテックのお客様と連携し、データベース、ストレージ、クラウドオペレーションの豊富な現場経験を活かして、本番システムのレジリエンス、パフォーマンス、スケーラビリティの向上を支援しています。 Viraj Padte Viraj は、AWS の金融サービス担当シニアソリューションアーキテクトです。さまざまなフィンテックのお客様と連携し、コアビジネスおよび AI を活用したプラットフォームとソリューションを支えるエンタープライズ対応のインフラストラクチャを設計しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

みなさん、こんにちは。ソリューションアーキテクトの川﨑です。この記事では、 富士電機ITソリューション株式会社 が Amazon Q Developer Pro サブスクリプションを活用し、開発者が実施する業務だけではなく日常業務でも生成 AI を取り込むことで、業務効率化のその先にある新しい企業価値の創出へと歩みを進めている旅路をご紹介します。 Amazon Q Developer の新規利用については Amazon Q Developer のサポート終了に関するお知らせ をご確認ください。 富士電機ITソリューション株式会社について 富士電機ITソリューション株式会社（以下、 FSL ）は、システム開発・運用保守・インフラ構築からセキュリティ対応まで、幅広いITソリューションを提供するシステムインテグレーターです。製造・流通・金融・建設など幅広い業界向けの”民需分野”、中央省庁や自治体などの”公共分野”、そして小中学校から大学までをカバーする”文教分野”の 3 本柱で構成され、コンサルティングからシステム設計・開発、ICT インフラ構築、運用・保守までを一気通貫で提供しています。 長年培われた業種・業務ノウハウと、全国規模の顧客基盤を持つ FSL にとって、生成 AI による開発生産性の向上は、自社の競争力強化だけでなく、お客様への付加価値提供を大きく加速する重要なテーマとなっています。 Amazon Q Developer Pro サブスクリプションの展開 FSL では Amazon Q Developer Pro サブスクリプション を 2025年12月に金森 重晴 執行役員 の指揮のもと 20 ユーザーから展開し、現在(2026年4月から)では、50 ユーザー以上へ展開しています。利用場面は、開発現場だけではなく通常業務での活用を推進してきました。導入当初から「まず使ってみる」を合言葉に、各メンバーが自身の業務のなかで生成 AI をどう活かせるかを自律的に模索する文化を育てています。一方的に「こう使ってください」とルールを押し付けるのではなく、自分の業務課題と向き合いながら活用方法を見つけ、社内で事例を共有し合う。このボトムアップ型のアプローチが、想像を超える多様なユースケースを生み出し短期間での利用者拡大を実現できています。勉強会や事例共有会を通して、今後も利用者は拡大していく予定です。 本稿では、2026年4月に実施した Amazon Q Developer ハンズオン勉強会の中でも特に反響の大きかった FSL 社内事例 LT ( Lightning Talk )で共有された 3 名のメンバーの取り組みをご紹介します。 現場から生まれた 3 つの活用事例 事例 1：原田 浩司 氏 – 業務ドキュメント作成の効率化と生成 AI 比較評価 – 原田 氏は、Amazon Q Developer を業務ドキュメントの効率化に活用されています。代表的なユースケースは、 テスト結果報告書の作成 です。これまで手作業で多くの時間を割いていた報告書ドラフト作成を Amazon Q Developer に支援させることで、レビューに集中できる時間が大幅に増えました。作成時のポイントは、HTML出力をすることです。マークダウン形式よりも表現豊かな報告書として出力できるため、作成後の報告にそのまま活用できる点がポイントです。さらに、管理用のExcelレポートへ変換出力をし、業務の効率化をはかっています。説明時に以下のようにコメントされていました。 「Amazon Q Developer の利点である動作しているファイルの読み書きが実行できることで、生成AIを疑問の回答を得るツールではなく、解決策まで実装できる点が使いやすい」 図1:システム試験結果のHTML出力例 図2:システム試験結果のExcel出力例 報告書を作成するだけではなく、障害情報を利用し再発防止策を講じるためのインサイトも生成AIを利用し作成しています。この時の説明時には、以下のようにコメントされていました。 「出力結果も妥当な結果が多く、ある程度の経験者が考えたインサイトと同程度である品質になっている」 さらに原田 氏は、Amazon Q Developer と他の生成 AI　との比較評価にも取り組んでいます。同じタスクを複数のツールで試し、それぞれの強み・弱みを見極めながら「業務ごとに最適な AI を選ぶ」という視点を社内にもたらしています。ツール選定を「感覚」ではなく「実測」で判断する文化は、今後の AI 活用拡大に向けた重要な資産になっています。 事例 2：久保田 匡史 氏 – 開発者業務の生産性を底上げする使いこなし – 久保田 氏は、日常業務の幅広い場面で Amazon Q Developer を使いこなしています。コーディングの枠を超えた特徴的な活用方法を3つ紹介しました。 従来では紙の書類をスキャンした押印画像から、押印部分を透過画像に変換する作業を画像変換ソフトなどを用い数時間かけて作業をしていました。この作業時間短縮のため、 Amazon Q Developer を活用し、画像編集ソフトで手作業していた業務を自動化されています。 続いて、 障害発生時のリスク分析 として、修正前後 ( before / after ) のソースコードを Amazon Q Developer に渡し、「この変更にはどのようなリスクが潜在するか」を問いかけるという、レビュー支援ツールとして利活用できるか検証されていました。人間が特定した原因と同じ問題を、ソースコードと一行のプロンプト”問題があれば指摘してください”だけで特定できたとのことです。この結果を受け、レビュー観点の追加だけではなく、潜在的リスクを早期に検出できるツールとして利用を検討されています。 図3：レビュー支援ツールとしての利用レポート 最後に、 既存プログラムの理解 として、引き継ぎや保守で読み解く必要のあるソースコードを Amazon Q Developer に解説させ、キャッチアップ時間を大幅に短縮されていました。説明時に、以下のようにコメントされていました。 「人間だと理解してドキュメントを作成するために、2週間は必要であった時間が1日で実用レベルのドキュメントを作成することができました。」 図4:既存プログラム理解のレポート 図5:既存プログラムの画面イメージ 久保田 氏の使い方は、「生成 AI はコードを書くためのもの」という固定観念を超え、 開発者の思考を拡張するパートナー として位置付けている点が印象的です。 事例 3：前田 隆憲 氏 – 既存資産の分析から業務ツール内製まで – 前田 氏は、より高度で専門性の高い領域に Amazon Q Developer を活用されています。 ログ／テレメトリーの分析 として、 Amazon Q Developer の利用データを Amazon S3 へ保存する設定をしています。そのため、ユーザー単位で利用状況が csv ファイルとして保存されます。この保存される膨大なログファイルやテレメトリーデータを Amazon Q Developer に読み込ませ、利用状況分析を行っています。 リバースエンジニアリング でも活用されています。既存ソースコードから画面遷移図や ER 図を生成し、ドキュメントが失われた既存システムの保守性を向上されています。また、 プロジェクトルール を活用することで、機能ごとに作成させる設計書のフォーマット統一を図るなど工夫されています。 図6：プログラムから設計書の作成 FSL がソリューションを導入する際の 見積もりツールの開発 にも Amazon Q Developer を利用しています。情報を入力することで、お客様もしくは社内向けに提示する費用を算出することができ、さらに、PDF化することで印刷して見積書としても利用できるツールとなるように開発をされています。 図7：作成中の見積もりツール画面イメージ 前田 氏の事例は、 Amazon Q Developer を「開発の隣にいるアシスタント」から、 業務プロセスに組み込まれたインフラ へと昇華させている点が特徴的でした。 勉強会参加者の声 「事例紹介や演習問題を通して、現在の業務の中で活用シーンはありそうなので、積極的に活用していきます。」 「画面の基本的な利用手順から具体的なチャットへの入力内容を確認できてスタートできそうです。事例では、具体的な入力イメージができました。」 「Amazon Q Developer は、コードを書くときだけでなく、調べる・考える・まとめるといった周辺業務全てに効いてきます。一度使い始めると、もう手放せません」 利用者拡大と Kiro への展開 50 を超えるユーザーでの活用成功と、社内から自然発生的に広がる多様なユースケースを受け、FSL は次のステップとして Amazon Q Developer の利用者数拡大、そして Kiro による次世代の開発体験の取り込みへと舵を切ろうとしています。 Kiro は、仕様からコードまでを一気通貫で扱える、スペック駆動の AI 開発ツールです。Amazon Q Developer で「部分最適」の効率化を積み重ねてきた FSL にとって、Kiro は要件定義から設計・実装・テストまでを横断的に変革する、次なるレバレッジ・ポイントとなります。業務効率化ツールの延長ではなく、 SDLC(ソフトウェア開発ライフサイクル) 全体を再設計する挑戦 が始まろうとしています。 今後の展望：業務効率化から、新しい企業価値の創出へ FSL の旅路は、コーディングエージェントの導入が「開発者の作業を速くする」ことだけに留まらないことを示されていると考えます。今回事例として紹介いただいたものは、 生産性向上に留まらず、自身のお客様へ提供する価値そのものを変えていく動き になっている点が特徴的でした。FSL は今後、Amazon Q Developer の利用者拡大と Kiro の導入も通じて、働き方のイノベーションを起こすことを目指していかれる予定です。生成 AI を導入し利用する本当の目的は、業務や携わっている事業にどのように価値を与えるかにあります。FSL の事例が示すように、現場の一人ひとりが「まずやってみる」を積み重ねることで、自身の業務から事業、さらには、企業全体の変革が形になっていきます。 AWS は、Amazon Q Developer や Kiro をはじめとするコーディングエージェントや生成 AI サービスを通じて、お客様ならではの価値創出の旅路を引き続きサポートしてまいります。生成 AI を活用した開発変革について、ぜひ AWS の担当者にご相談ください。 川﨑 裕希 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。IoTやエッジデバイスに興味があり、エッジ推論の検証が最近の趣味です。 <!-- '"` -->

2026 年 04 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS IAM Identity Center 導入 デモンストレーション編 複数の AWS アカウントへのアクセスを一元管理できる AWS IAM Identity Center について、アクセスポータルを利用したコンソールアクセスや、AWS CLI での一時認証情報の利用方法をデモンストレーションを交えてご紹介します。本セッションでは導入デモンストレーション編として、アクセスポータルからの権限の切り替えや、AWS CLI 経由でのユーザー認証によるコマンド実行など、具体的な利用の流れについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 IAM ユーザーの代わりに、AWS IAM Identity Center のご利用を考えている方 AWS IAM Identity Center がどのようなサービスか知りたい方 本 BlackBelt で学習できること AWS IAM Identity Center でのユーザー認証からマネジメントコンソールアクセスまでの流れについて理解 AWS IAM Identity Center を用いて AWS CLI を利用する流れについて理解 スピーカー 大平 修慈 アソシエイトセキュリティコンサルタント AWS IAM Identity Center 導入 説明編 AWS IAM Identity Center は、複数の AWS アカウントやアプリケーションへのアクセス管理を一元管理できるフルマネージド型の AWS サービスです。 本セミナーでは、AWS IAM Identity Center の概要や特徴、主要な構成要素について解説いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 IAM ユーザーの代わりに、AWS IAM Identity Center のご利⽤を考えている⽅ AWS IAM Identity Center がどのようなサービスか知りたい⽅ 本 BlackBelt で学習できること 本セミナーを受講することで、AWS IAM Identity Center の概要、特徴、主要な構成要素について学習することができます。 スピーカー 松谷 圭 セキュリティコンサルタント AWS IAM Identity Center 設計構築 デモンストレーション編 複数の AWS アカウントとアプリケーションへのアクセスを一元管理する AWS IAM Identity Center について、外部 ID プロバイダーとの連携設定をハンズオン形式で解説します。 また、AWS IAM Identity Center に関連する AWS サポートによくある質問と回答について紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 * AWS IAM Identity Center と既存の ID プロバイダー（Microsoft Entra ID 等）との連携を検討している管理者の方 ユーザー管理の運用コストを削減しながらセキュリティを強化したい管理者の方 本 BlackBelt で学習できること * AWS IAM Identity Center と外部 ID プロバイダー（Microsoft Entra ID）を連携させる具体的なメリットについて SAML によるシングルサインオン設定、SCIM による自動プロビジョニング、許可セットの作成と割り当といった一連の構築手順の概要について スピーカー 松﨑 明 クラウドサポートエンジニア AWS IAM Identity Center 設計構築 説明編 複数の AWS アカウントへのアクセス管理を一元化できる AWS IAM Identity Center について、導入時の設計ポイントや外部 ID プロバイダーを利用した構成例・設定例をご紹介します。 本セッションでは設計構築 説明編として、利用リージョンや ID ソースの選択、許可セットの設計、SAML/SCIM を用いたシングルサインオンの構成について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS IAM Identity Center の設計や構築をはじめられる方 AWS IAM Identity Center の構成例を知りたい方 本 BlackBelt で学習できること AWS IAM Identity Center の導入時の設計ポイント（利用リージョン、インスタンス、ID ソースの選択）について理解 外部 ID プロバイダー（Entra ID）を利用した構成例と設定手順について理解 許可セットの設計とユーザーへの割り当てによるマルチアカウントのアクセス管理について理解 スピーカー 西田　直弘 クラウドサポートエンジニア Amazon FSx for NetApp ONTAP Part1 Amazon FSx for NetApp ONTAP は、NetApp ONTAP の機能を、AWS サービスのクラウド特有のシンプルさ/敏捷性/スケーラビリティとともにご利用いただけるサービスです。本セミナーでは Part1/Part2 の二部構成で、概要から技術詳細、設定手順まで一挙にご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon FSx for NetApp ONTAP をこれからご利用予定の方 SMB や NFS の共有ファイルサーバの知識をお持ちの方 現在 NetApp ONTAP をご利用中の方 NetApp ONTAP の提案や実装に携わる方 AWS のファイルストレージサービスをすでにご利用の方でより理解を深めたい方 本 BlackBelt で学習できること 本セミナーでは Amazon FSx for NetApp ONTAP の概要/技術詳細/設定手順について二部構成で網羅的に学習いただけます。 スピーカー 辻 佑一郎 クラウドサポートエンジニア Amazon FSx for NetApp ONTAP Part2 Amazon FSx for NetApp ONTAP は、NetApp ONTAP の機能を、AWS サービスのクラウド特有のシンプルさ/敏捷性/スケーラビリティとともにご利用いただけるサービスです。本セミナーでは Part1/Part2 の二部構成で、概要から技術詳細、設定手順まで一挙にご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon FSx for NetApp ONTAP をこれからご利用予定の方 SMB や NFS の共有ファイルサーバの知識をお持ちの方 現在 NetApp ONTAP をご利用中の方 NetApp ONTAP の提案や実装に携わる方 AWS のファイルストレージサービスをすでにご利用の方でより理解を深めたい方 本 BlackBelt で学習できること 本セミナーでは Amazon FSx for NetApp ONTAP の概要/技術詳細/設定手順について二部構成で網羅的に学習いただけます。 スピーカー 辻 佑一郎 クラウドサポートエンジニア re:Invent 2025 通信業界向け recap シリーズ CX 編 CX の改善に向けた Agentic AI 及び業界特化 LLM の活用 通信業界における CX の改善について、AWS re:Invent 2025 で発表されたアップデートを踏まえた Agentic AI 及び業界特化 LLM の活用などのアプローチや、お客様の事例を交えてご紹介致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界において CX 領域に携わる方、Agentic AI を活用した CX の改善に関心がある方、業界特化 LLM を活用した CX 改善に関心がある方を主な対象としております。 本 BlackBelt で学習できること 通信業界における CX 領域の課題の概要、 Agentic AI 及び業界特化 LLM を活用した通信業界における CX 領域の課題に対するアプローチを、お客様の事例を交えて学ぶことができます。 スピーカー 松岡雄地 ソリューションアーキテクト re:Invent 2025 通信業界向け recap シリーズ セキュリティ編 ⽣成 AI で変⾰する 通信事業者のセキュリティ運⽤ AWS re:Invent 2025 で発表された AWS の生成 AI を活用した通信業界におけるサイバーセキュリティ運用の技術が、通信事業者のセキュリティ運用をどのように変革していくのか、事例も交えてご紹介致します 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界に携わる方、通信ネットワークのサイバーセキュリティに関心のある方、通信ネットワークのセキュリティ運用において 生成 AI の活用をしたいと考えられている方を主な対象としております。 本 BlackBelt で学習できること 通信ネットワークのセキュリティ運用において AWS の生成 AI をどのように活用することができるか、またその活用事例をお届けします スピーカー 岡本 篤志 ソリューションアーキテクト re:Invent 2025 通信業界向け recap シリーズ ネットワーク編 ハイブリッドアーキテクチャによる ネットワークのモダナイゼーション モバイルネットワークにおけるクラウドとオンプレミスのハイブリッド構成を実現する方法について AWS re:invent 2025 で紹介された事例を交えてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界に携わる方 、モバイルネットワークにおけるクラウド活用を検討している方、オンプレミスとクラウドのハイブリッドアーキテクチャに関心のある方を対象としております。 本 BlackBelt で学習できること モバイルネットワークをクラウドへ移行するメリット、実現に必要なオンプレミスとクラウドのハイブリッドサービス、お客様事例を学ぶことができます。 スピーカー 伊藤 広記 ソリューションアーキテクト re:Invent 2025 通信業界向け recap シリーズ ネットワーク運用編　 Agentic AI を活用した通信ネットワーク運用の自律化 AWS re:Invent 2025 で発表された通信ネットワーク運用の自律化を Agentic AI を活用してどのように実現できるか、について参考アーキテクチャと事例も交えてご紹介致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界に携わる方、通信ネットワークの運用における自動化/自律化に関心のある方、通信ネットワークの運用における Agentic AI の活用したいと考えられている方を主な対象としております。 本 BlackBelt で学習できること 通信ネットワークの運用における課題、Autonomous Network の実現に向けた AWS の活用方法、Autonomous Network を実現するための参考アーキテクチャ、お客様事例をお届けいたします。 スピーカー 宮崎 友貴 ソリューションアーキテクト re:Invent 2025 通信業界向け recap シリーズ 移行 / モダナイズ編　 AI を活用した通信ワークロードの移行とモダナイゼーション AWS re:Invent 2025 で発表された AI を活用した通信ワークロードの移行 / モダナイゼーション技術が、通信業界のデジタル変革をどのように加速させるかを、事例も交えてご紹介致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界に携わる方、レガシーなシステムを担当しており AWS クラウドへの移行 / モダナイゼーションに関心のある方、AWS クラウドへの移行 / モダナイゼーション向けに AI エージェント / Agentic AI の活用に関心のある方、を主な対象としております。 本 BlackBelt で学習できること 通信ワークロードのクラウド移行へ課題、クラウド移行への AI 活用、AWS を活用した移行とモダナイゼーションの実現、及びお客様事例をお届け致します。 スピーカー 黒田　由民 ソリューションアーキテクト

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 AWSが提供するAIエージェント搭載の統合ワークスペース「Amazon Quick」をご存知でしょうか？自然言語で質問・指示するだけで、社内データの検索・分析・業務自動化をひとつの画面で完結できるサービスです。5月26日（火）に東京・赤坂にて、Amazon Quickの導入を検討中の企業向けに、複数のパートナー企業の支援内容を半日で比較検討できるイベント「 Amazon Quick で実現するAI業務変革 — 半日で一気見できるパートナーエクスポ 」が開催されます。最新機能デモ、業界別ハンズオン、パートナーセッションと盛りだくさんの内容です。定員制のため、ご興味ある方はお早めにご登録ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年5月11日週の主要なアップデート 5/11(月) AWS Transform が移行時の自動コンテナ化に対応 AWS Transform が、AWS への移行時にアプリケーションをコンテナにリプラットフォームする機能を追加しました。エージェンティック AI を活用してソースコードのコンテナ化を自動化し、移行とモダナイゼーションを並行実行できます。GitHub、Bitbucket、GitLab、または zip ファイルからソースコードを取り込み、Dockerfile の生成、Docker イメージのビルド、Amazon ECR への公開、Amazon ECS または Amazon EKS へのデプロイまでを一連のワークフローで実行します。これにより、オンプレミスからクラウドネイティブアーキテクチャへの移行にかかる時間と複雑さを削減できます。 Claude Platform on AWS が一般提供開始 AWS は、Anthropic のネイティブ Claude Platform を AWS アカウント経由で直接利用できる新サービス「Claude Platform on AWS」の一般提供を開始しました。AWS は Claude Platform のネイティブ体験を提供する初のクラウドプロバイダーです。このサービスでは、既存の AWS アカウント、IAM 認証、CloudTrail 監査、統合請求を活用しながら、Anthropic が運用する Claude API、コンソール、ベータ機能に直接アクセスできます。データ処理は Anthropic が管理するインフラ上で行われ、AWS セキュリティ境界外で処理される点が Amazon Bedrock との主な違いとなります。18 のリージョンで利用可能です。 ENA Express for Amazon EC2 が Availability Zone 間トラフィックに対応 Elastic Network Adapter (ENA) Express が、同一リージョン内の異なる Availability Zone (AZ) 間トラフィックに対応しました。これにより、クロス AZ 通信での単一フロー帯域幅が従来の 5 Gbps から最大 25 Gbps に向上します。ENA Express は AWS Scalable Reliable Datagram (SRD) プロトコルを使用し、マルチパス経路選択と高度な輻輳制御により、分散ストレージ、データベース、ファイルシステムなどのマルチ AZ 構成でのネットワーク性能を改善します。追加コストは発生せず、TCP/UDP プロトコルに対応し、アプリケーションの変更は不要です。 5/12(火) Amazon Redshift が AWS Graviton 搭載の RG インスタンスを発表 Amazon Redshift は、AWS Graviton プロセッサを搭載した新世代のプロビジョンドクラスタノード「RG インスタンス」の一般提供を開始しました。RG インスタンスは、データウェアハウスおよびデータレイクワークロードを前世代の RA3 インスタンスと比較して最大 2.4 倍高速に実行し、vCPU あたりの価格を 30% 削減します。カスタムビルドされたベクトル化データレイククエリエンジンをクラスタノード上で直接実行するため、Redshift Spectrum の別スキャンフリートと スキャンデータ量に応じた TB 単位の課金が不要になります。26 の AWS リージョンで rg.xlarge と rg.4xlarge の 2 つのインスタンスサイズで利用可能です。 Amazon CloudFront Premium flat-rate plan で設定可能な使用量上限をサポート Amazon CloudFront Premium flat-rate plan が、複数の使用量レベルに対応しました。従来は単一の使用量上限のみでしたが、現在は月間リクエスト数 5 億 ～ 60 億、データ転送量 50 TB ～ 600 TB の範囲で、6 つのレベルから選択できます。CloudFront コンソールで即座に使用量レベルを変更でき、年間コミットメントは不要です。すべての Premium プラン機能は、どの使用量レベルでも利用できます。 Karpenter が Amazon Application Recovery Controller の zonal shift をサポート Amazon EKS で Karpenter を使用する際に、Amazon Application Recovery Controller (ARC) の zonal shift および zonal autoshift がサポートされました。これにより、AZ 障害時にクラスタ内のネットワークトラフィックを自動的に健全な AZ へ転送し、Kubernetes アプリケーションの可用性を維持できます。Karpenter は障害 AZ への新規ノード起動と自発的な中断（voluntary disruption）を一時停止することで、安全なトラフィックシフトを実現します。 AWS Security Agent が full repository code review をサポート AWS は 2026 年 5 月 12 日、AWS Security Agent の新機能 full repository code review をプレビューとして提供開始しました。この機能はコードベース全体に対して、AI を活用した深いコンテキスト認識型のセキュリティ分析を実行します。従来のパターンマッチング型の静的解析ツールとは異なり、アプリケーションのアーキテクチャ、信頼境界、データフローを理解して、パターンマッチングでは見逃される体系的な脆弱性を検出します。脆弱性が見つかると、具体的なファイルと行番号を指定した修復コードを生成し、チームは従来よりも迅速に脆弱性を特定して修復できます。この機能は、プレビュー期間中、既存の AWS Security Agent 顧客に追加料金なしで提供されます。 AWS Lambda が Lambda Managed Instances での関数の scheduled scaling をサポート AWS Lambda は、Lambda Managed Instances 上で実行される関数に対して、Amazon EventBridge Scheduler を使用した scheduled scaling をサポートしました。この機能により、予測可能なトラフィックパターンに対して、ワンタイムまたは繰り返しのスケジュールを定義し、関数のキャパシティ制限を事前に調整できます。ピーク時のパフォーマンス目標を達成しながら、アイドル期間のコストを削減することが可能になります。すべての Lambda Managed Instances サポートリージョンで利用できます。 5/13(水) Amazon RDS for Oracle が M8i と R8i インスタンスで Oracle SE2 License Included に対応 Amazon RDS for Oracle が M8i と R8i インスタンスで Oracle Database Standard Edition 2 (SE2) License Included に対応しました。これらのインスタンスは AWS 専用の Intel Xeon 6 プロセッサを搭載し、前世代の Intel ベースインスタンスと比較して最大 15% のコストパフォーマンス向上と 2.5 倍のメモリ帯域幅を実現します。License Included モデルでは Oracle ライセンスを別途購入する必要がなく、サブスクリプション型の従量課金でソフトウェアライセンス、サポート、コンピューティングリソース、マネージドデータベースサービスをまとめて利用できます。 Amazon SageMaker Data Agent が IAM Identity Center ドメインで利用可能に Amazon SageMaker Data Agent が、IAM Identity Center で構成された SageMaker Unified Studio ドメインで利用できるようになりました。Data Agent は、データアナリストやデータエンジニアが自然言語で分析目標を記述すると、Python や SQL コードを自動生成する AI 支援機能です。Amazon Athena、Amazon Redshift、Amazon S3、AWS Glue Data Catalog などのデータソースに対応し、複雑な SQL の JOIN や集計、Python コードを手動で記述する必要がなくなります。ノートブックと Query Editor の両方で利用でき、「Fix with AI」機能により実行エラーの自動診断と修正提案も行います。全 15 リージョンで利用可能です。 5/14(木) Amazon RDS for PostgreSQL がマイナーバージョン 18.4、17.10、16.14、15.18、14.23 をサポート Amazon RDS for PostgreSQL が 2026年5月14日に最新マイナーバージョン 18.4、17.10、16.14、15.18、14.23 のサポートを開始しました。特に PostgreSQL 18.4 では 11 件の CVE (CVE-2026-6479 など) を含む重要なセキュリティ脆弱性が修正されており、任意コード実行や SQL インジェクションなどの重大な問題に対応しています。また PostgreSQL 18 向けに PostGIS 3.6.3 の postgis_topology サポートが追加され、ネットワーク接続や空間的な隣接関係をデータベース内で直接モデリングできるようになりました。自動マイナーバージョンアップグレードと AWS Organizations Upgrade Rollout Policy を組み合わせることで、数千台規模のデータベースを段階的にアップグレードできます。 AWS CloudFormation と CDK でアカウント・リージョン間のスタック出力参照が可能に AWS CloudFormation に新しい組み込み関数 Fn::GetStackOutput が追加されました。この関数により、異なる AWS アカウントや異なるリージョンにあるスタックの出力値を直接参照できるようになりました。従来の Fn::ImportValue が同一アカウント・同一リージョンに限定され、明示的な Export が必要だったのに対し、Fn::GetStackOutput は Export 不要で、IAM ロールを使用したクロスアカウント参照に対応します。CDK では、クロス参照時に自動的にこの関数を使用するため、以前必要だった Custom Resources や SSM Parameters が不要になり、デプロイデッドロックの問題も解消されます。全 CloudFormation 対応リージョンで利用可能です。 AWS Transform agents が Kiro、Claude、Cursor、Codex で利用可能に AWS は、AI エージェント型のモダナイゼーションサービス AWS Transform を、Kiro power、agent plugins、MCP server を通じて複数の開発環境から利用できるようにしました。開発者は Kiro、Claude Code、Cursor、Codex といった 開発エージェントツールから直接、.NET、VMware、メインフレーム、カスタムコードの変換作業を実行できます。同じ変換ジョブに対して IDE、Web コンソール、MCP 経由でアクセスでき、状態が一貫して管理されます。また IAM ロール認証に対応したことで、既存の AWS 認証情報を使用して Transform 環境、ワークスペース、変換ジョブを作成できるようになりました。 Amazon CloudFront で mutual TLS (Viewer) のパススルーモードを発表 Amazon CloudFront は、viewer mutual TLS (mTLS) 認証のパススルーモードをサポートしました。このモードでは、CloudFront が証明書検証を行わず、クライアント証明書をオリジンに転送してオリジン側で検証を実施します。オリジンで既に mTLS 実装を運用している顧客は、エッジでの検証ロジックを再実装することなく CloudFront を導入できます。パススルーモードは追加料金なしで利用できます。 5/15(金) AWS Interconnect – multicloud with Oracle Cloud Infrastructure (OCI) のパブリックプレビューを発表 AWS Interconnect – multicloud with Oracle Cloud Infrastructure (OCI) のパブリックプレビューを発表しました。このサービスは、クラウドサービスプロバイダー (CSP) 間の専用プライベート接続を数分でプロビジョニングできるサービスです。従来の DIY マルチクラウドアプローチで発生していた、グローバルな多層ネットワークの構築・管理の複雑さを解消します。プレビュー版は us-east-1 リージョンで利用可能で、AWS マネージメントコンソール、CLI、API から作成できます。 Amazon RDS for PostgreSQL Extended Support マイナーバージョン 11.22-rds.20260224、12.22-rds.20260224、13.23-rds.20260224 を発表 Amazon RDS for PostgreSQL は、Extended Support 対象の PostgreSQL 11.22-rds.20260224、12.22-rds.20260224、13.23-rds.20260224 マイナーバージョンをリリースしました。これらのバージョンは、4 つのセキュリティ脆弱性 (CVE-2026-2003、CVE-2026-2004、CVE-2026-2005、CVE-2026-2006) を修正します。標準サポート終了後も PostgreSQL の旧バージョンを実行する必要があるお客様は、これらのバージョンへのアップグレードを推奨します。 Amazon CloudWatch Logs が Logs Insights クエリ結果の上限を 100,000 件に拡大 Amazon CloudWatch Logs が Logs Insights クエリ言語 (QL) で取得できる結果の上限を、従来の 10,000 件から 100,000 件に拡大しました。これにより、大量のログイベントを分析する際に、時間範囲を分割してクエリを実行する必要がなくなります。GetQueryResults API もページネーションに対応し、1 回の呼び出しで最大 10,000 件の結果と次のページを取得するためのトークンを返します。この機能は全ての商用 AWS リージョンで利用できます。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は、2026 年 5 月 1 日 に公開された A guide to Airflow worker pool optimization in Amazon MWAA を翻訳したものです。翻訳はクラウドサポートエンジニアの山本が担当しました。 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は、AWS のフルマネージド Apache Airflow サービスです。Amazon MWAA で Airflow ワーカープールの設定を最適化することは、ワークフロー運用をスケールするうえで重要でありながら見過ごされやすいポイントです。タスクが長時間キューに滞留している場合、ワーカー不足が原因だと考えがちですが、実際には別の根本原因が潜んでいることがあります。スケールの判断は単純ではありません。DevOps エンジニアやシステム管理者は、ワーカーを追加すればパフォーマンスの問題が解決するのか、それとも根本原因に対処せずに運用コストが増えるだけなのかを見極める必要があります。 本記事では、Amazon MWAA におけるワーカースケーリングの判断パターンを、タスクプールの仕組みとワーカー割り当ての関係に焦点を当てて解説します。具体的なシナリオと実践的な判断フレームワークを示し、ワーカーの追加がパフォーマンス課題の適切な解決策かどうか、また適切な場合にどうスケーリングを実装するかの指針を提供します。 主なパターン 本セクションでは、ワーカーの追加が必要かどうかを検討するきっかけとなる、代表的な問題パターンを紹介します。 高い CPU 使用率 Airflow は、外部サービス上のタスク実行を調整・スケジュールするワークフロー管理プラットフォームです。 AWS Glue 、 AWS Batch 、 Amazon EMR など、さまざまなデータ処理システム間のタスクをトリガーおよびモニタリングする中央オーケストレーターとして機能します。Airflow の強みは、データ処理そのものではなく、複数のシステムやサービス間でタスクの依存関係や実行順序を管理できる点にあります。 分析やビッグデータ基盤では、リソースが飽和すると自動的に容量の追加が必要だという誤解がよくあります。しかし Amazon MWAA では、スケーリングの判断に先立って、ワークフローの特性と最適化の余地を理解することが重要です。 ワークフローの規模が拡大すれば、Airflow クラスターのリソース使用率は当然高くなります。ワーカーが常にフル稼働している状況では、コンピューティングリソースの追加が最も手早い対処に見えるかもしれません。しかし、リソース追加は根本的な問題を解決するのではなく、問題を先送りにしてしまうだけです。 たとえば、Amazon MWAA で単一のタスクがワーカーの利用可能な CPU を 100% 消費している場合、ワーカーを追加しても問題は解決しません。タスクが最適化されていないか、より小さな部分に分割されていないためです。そのため、最小ワーカー数を増やしても期待した効果は得られず、運用コストが増加するだけです。 Amazon MWAA ワーカーの CPU またはメモリ使用率が常に 90% を超えている場合、重要な判断ポイントに達しています。対策を講じる前に、根本原因の理解が不可欠です。主に 3 つの対策があります。 水平スケーリング: ワーカーを追加して負荷を分散する。 垂直スケーリング: より大きな環境クラスにアップグレードして、ワーカーあたりのリソースを増やす。 DAG とスケジューリングパターンの最適化: 効率を高めリソース消費を削減する。 各アプローチは異なる根本的な問題に対処するものであり、容量の制約、リソース集約型のタスク設計、ワークフローの非効率のいずれに直面しているかを特定したうえで適切な方法を選択します。最適化戦略のガイダンスについては、 Performance tuning for Apache Airflow on Amazon MWAA を参照してください。 ワーカーの CPUUtilization と MemoryUtilization をモニタリングするには、 Accessing metrics in the Amazon CloudWatch console を参照し、対応するメトリクスを選択してください。 使用パターンを確認できる十分な時間枠を選択する。 期間を 1分 &nbsp;に設定する。 統計を 最大 に設定する。 長いキュー待ち時間 Airflow タスクがキュー状態で長時間滞留し、DAG が予定通りに完了しないことがあります。 Amazon MWAA では、各環境クラスに最小および最大ワーカーノード数が設定されています。各ワーカーには事前設定された同時実行数があり、任意の時点で各ワーカーが同時に実行できるタスク数を表します。この動作は celery.worker_autoscale=(max,min) で制御されます。 たとえば、最小 4 台の mw1.small ワーカーがあり、デフォルトの Airflow 設定の場合、20 個のタスクを同時実行できます (4 ワーカー × 5 max_tasks_per_worker)。システムが突然 20 を超えるタスクの同時実行を必要とすると、オートスケーリングイベントが発生します。Amazon MWAA はワーカーを効率的にスケールする方法を決定し、プロセスをトリガーします。ただし、オートスケーリングプロセスには新しいワーカーのプロビジョニングに追加の時間が必要なため、キュー状態のタスクが増加します。キューイングの問題を軽減するには、以下を検討してください。 ワーカーの CPU 使用率が低い場合、 celery.worker_autoscale=(max,min) の max 値を増やすと、各ワーカーがより多くのタスクを同時処理できるため、タスクのキュー滞留時間を短縮できます。Airflow ワーカーは、自身のシステムリソースの空き状況に関係なく、定義されたタスク同時実行数までタスクを受け取れます。その結果、オートスケーリングが作動する前にワーカーの CPU/メモリ使用率が 100% に達する可能性があります。 ワーカーのタスク同時実行数を増やしたくない場合、最小ワーカー数を増やすことも有効です。利用可能なワーカーが増えることで、より多くのタスクを同時実行できるようになります。 スケジューリングの遅延 新しい DAGの追加は、システムリソースに影響するだけでなく、スケジューリングのばらつきを発生させる可能性があります。環境全体のメトリクスが正常に見えても、リソースの競合によって一部の DAGの実行が遅延することがあります。このばらつきは、特定のタスクが常にキューで長く待機する一方、他のタスクはすぐに実行されるといった状況が発生します。 Amazon CloudWatch メトリクス で、特に DAG の実行数が多い期間において、実行開始時間のばらつきが増加している場合、環境の最適化が必要です。実行パターンとリソース使用率を分析した上で、以下を判断してください。 ワーカーの追加はワークロードの分散に役立ちますが、高いリソース使用率が DAG のパースやスケジューリングのオーバーヘッドではなく、主にタスク実行の負荷によるものである場合に最も効果的です。最小ワーカー数を増やすと、より多くのタスクを並列実行できます。たとえば、 AWS/MWAA/ApproximateAgeOfOldestTask の値が着実に増加している場合、ワーカーがキューからのメッセージを十分な速度で消費できていないことを意味します。さらに、 AWS/MWAA/QueuedTasks をモニタリングして同様のパターンを特定することもできます。 環境クラスのアップグレードにより、スケジューリング容量が向上します。スケジューラーに負荷の兆候が見られる場合や、すべてのコンポーネントでリソース使用率が高い場合は、より大きな環境クラスへのアップグレードが最適な解決策かもしれません。スケジューラーとワーカーの両方により多くのリソースが提供され、DAG の複雑さとボリュームの増加に対応できます。検証するには、 AWS/MWAA/CPUUtilization と AWS/MWAA/MemoryUtilization のクラスターメトリクスで Scheduler 、 BaseWorker 、 AdditionalWorker メトリクスを選択してください。 DAG スケジュールの再構成により、リソース競合を削減する。 重要なのは、ワークフローパターンを理解し、スケジューリングの遅延がワーカー容量の不足によるものか、その他の環境上の制約によるものかを特定することです。 アンチパターン ワーカーを追加することでパフォーマンスが改善するという誤った結論につながりやすい、よくあるアンチパターンを紹介します。 稼働率の低いワーカー Amazon MWAA のパフォーマンスボトルネックを評価する際は、環境をスケールアップする前に、リソース制約と DAG 設計の非効率を区別することが重要です。 Amazon MWAA 環境が 100 タスクを同時実行できる容量を持っていても、キューメトリクス ( AWS/MWAA/RunningTasks ) ではほとんどの時間で 20 タスクしかアクティブでなく、キュー状態のタスクも残っていないことがあります。その場合、ピークワークロード時に既存ワーカーの CPU とメモリ使用率が常に低いかどうかを Amazon CloudWatch で確認してください。リソース使用率が低い場合、通常は DAG 設計、スケジューリングパターン、または Airflow 設定が非効率であることを示しています。 対処には主に 2 つの選択肢があります。 1. ダウンサイズ : ワークロードの増加が見込まれない場合、クラスターが過剰にプロビジョニングされていると判断できます。まず余分なワーカーを削除し、最終的に環境クラスのダウンサイズを検討してください。 2. 最適化 : プールや同時実行数の Airflow 設定を通じて DAG スケジューリングを調整し、システムのスループットを向上させてください。 人為的なボトルネックを生む Airflow 設定の誤り Apache Airflow では、実際のリソース制約ではなく設定によってパフォーマンスボトルネックが発生することがよくあります。コンピューティングリソースの不足ではなく、同時実行数の設定ミスによって DAG の実行が遅延します。 Amazon MWAA を効率的に使用するには、ワーカーとスケジューラーのリソース使用率だけでなく、人為的なボトルネックとなる同時実行数設定も確認する必要があります。1 つの制限的な設定が、より大きな環境や追加ワーカーのスケーリング効果を打ち消してしまうことがあります。システムメトリクスに余裕があるにもかかわらずパフォーマンスが制限されている場合は、Airflow 設定を監査してください。 重要な考慮事項 : Amazon MWAA は、環境クラスを変更してもワーカーの同時実行数設定を自動的に更新しません。スケーリング時にこの動作を理解しておくことが重要です。最初に mw1.small 環境を作成した場合、各ワーカーはデフォルトで最大 5 つの同時タスクを処理できます。medium 環境クラス (デフォルトでワーカーあたり 10 の同時タスクをサポート) にアップグレードしても、インプレース更新された環境では同時実行数の設定は 5 のまま です。新しい環境クラスの容量を最大限に活用するには、同時実行数の設定を手動で更新する必要があります。 このため、環境クラスを更新する際は、同時実行数を制御する Airflow 設定も更新する必要があります。環境クラスのアップグレード後に同時実行数の設定を更新するには、Apache Airflow 設定オプションの celery.worker_autoscale 設定を変更してください。ワーカーが新しい環境クラスでサポートされる最大同時タスク数を処理できるようになります。 また、Amazon MWAA 環境が実際のリソース制限ではなく、 max_active_runs や DAG 同時実行数の制御によって制約されている場合もあります。設定ベースのスロットルは、ワーカーインスタンスにワークロードを処理する利用可能なコンピューティングリソースがあっても、タスクの実行を妨げます。 この 2 つには重要な違いがあります。設定による制限は並列処理の人為的な上限として機能し、真のリソース制限はワーカーが CPU またはメモリ容量をフルに使用していることを示します。どちらの制約が環境に影響しているかを理解することで、設定を調整すべきかインフラストラクチャをスケールすべきかを判断できます。 プール、同時実行数、max_active_runs などの Airflow 設定を調整することで、ワーカーをスケールせずにパフォーマンスの問題を解決できます。制御に使用できる設定の一部を以下に示します。 max_active_runs_per_dag (DAG レベル): 特定の DAG について同時に許可される DAG 実行数を制御します。2 に設定すると、ワーカー容量に余裕があっても同時に 2 つの DAG 実行しか実行できません。追加の実行はキューに入り、ワーカーがアイドル状態でも DAG の実行が遅くなります。 max_active_tasks: DAG 定義の concurrency フィールド (または環境レベルの設定) を制御し、システム全体の容量やワーカー数に関係なく、その DAG から同時に実行されるタスク数を制限します。 プール: プールは、特定の種類 (多くの場合リソース集約型) のタスクが同時に実行できる数を制限します。3 スロットのプールは、そのプールに割り当てられた 3 を超えるタスクをスロットルし、ワーカーをアイドル状態にします。 実行タイムアウトとリトライ: 適切に調整されていない場合、失敗したタスクが不必要にスロットを占有し、スタックしたタスクがワーカースロットをブロックしてキュー処理を遅延させる可能性があります。 スケジューリング間隔と依存関係: 重複する非効率なスケジューリングは、アイドル期間やリソースの過度な競合を引き起こし、実際のスループットに影響する可能性があります。 Airflow 設定の相互上書き Airflow には、同時実行数とスケジューリングを制御する複数のレイヤーがあります。環境レベル、DAG/タスクレベル、プール用のものがあります。より制限的な設定がより許容的な設定を上書きし、予期しないキューの蓄積を引き起こすことがあります。 DAG レベル vs 環境レベル: “max_active_runs_per_dag” (DAG レベル) が環境レベルの “max_active_runs_per_dag” やシステム全体の同時実行数より低い場合、DAG の設定が使用され、環境がより多くの処理を行えるにもかかわらずタスクがスロットルされます。 タスクレベルの上書き: 個々のタスク定義には “max_active_tis_per_dag” などの独自のパラメータを設定でき、グローバル設定より低く設定するとボトルネックを生み出す可能性があります。 優先順位: 任意のレベル (環境、DAG、タスク) で最も制限的な設定が、並列タスク実行の上限を実質的に決定します。 設定場所 設定 タスクスループットへの影響 環境レベル parallelism スケジューラーで実行される最大タスク総数 DAG レベル max_active_runs 同時 DAG 実行の最大数 タスクレベル concurrency その DAG の最大同時タスク数 パフォーマンスの問題はリソース枯渇のように見えることが多いですが、実際には過度に制限的な設定に起因しています。上記のパラメータをすべて慎重に監査してください。制限的な値を段階的に緩和し、クラスターのスケールを決定する前に効果をモニタリングできます。アイドル容量に対して支払うことなく、クラウドリソースを最適かつコスト効率よく使用できます。 メモリリークによる緩やかなリソース枯渇 Amazon MWAA でメモリリークや緩やかなリソース枯渇が発生する一般的なシナリオは、DAG やタスクが時間の経過とともに失敗したり遅くなったりする場合です。ワーカーのスケールや環境サイズの拡大では根本的な問題は解決しません。根本原因は容量不足ではなく、持続的な枯渇を引き起こすアプリケーションレベルのリークであるためです。 たとえば、Airflow がタスクの実行と DAG のパースを継続的に行うと、環境全体のメモリ消費が着実に増加する可能性があります。ワークロードが一定または減少しているにもかかわらず、Amazon MWAA メタデータデータベースの FreeableMemory メトリクスが低下するという形で現れることがあります。メモリリソースがスケジューラー/ワーカーおよびメタデータデータベースで制約されると、データベースクエリのパフォーマンスが徐々に低下し、Airflow はメタデータデータベースに重要な操作を大きく依存しているため、最終的に環境全体の応答性に影響します。アプリケーションがデータベース接続を適切に閉じずに作成し、リソース枯渇に至るのと似た状況です。 グラフ: FreeableMemory と MemoryUtilization の低下(上: メタデータデータベース、下: スケジューラー及びワーカー) 一般的な原因: コネクションプールの枯渇: データベース接続を適切に閉じない DAG は、コネクションプールの枯渇とデータベースのメモリリークを引き起こす可能性があります。 リソース集約型の操作: メタデータデータベースに対する複雑で長時間実行されるクエリや XCOM 操作は、過剰なメモリを消費する可能性があります。 非効率な DAG 設計: トップレベルに多数の Python 呼び出しを持つ DAG は、DAG パース中にデータベースクエリをトリガーする可能性があります。たとえば、タスクレベルではなく DAG レベルで variable.get() を呼び出すと、不要なデータベースの負荷が発生します。 推奨される解決策: Amazon CloudWatch モニタリングの実装: FreeableMemory に適切なしきい値で Amazon CloudWatch アラームを設定し、問題を早期に検出する。 定期的なデータベースメンテナンス: 不要になった履歴データをパージするスケジュールされたデータベースクリーンアップ操作を実行する。 DAG コードの最適化: variable.get() などのデータベース操作を DAG レベルからタスクレベルに移動するよう DAG をリファクタリングし、パースのオーバーヘッドを削減する。 接続管理: すべてのデータベース接続が使用後に適切に閉じられるようにし、コネクションプールの枯渇を防止する。 上記の推奨事項に従うことで、メタデータデータベースのメモリ使用率を健全に維持し、ワーカーをスケールせずに Amazon MWAA 環境の最適なパフォーマンスを維持できます。 まとめ Amazon MWAA 環境でワーカーを追加する判断には、単純なタスクキューメトリクスを超えた複数の要因の検討が必要です。本記事では、ワーカーの追加が特定のパフォーマンス課題に対処できる一方で、システムボトルネックへの最適な最初の対応ではないことが多い点を示しました。 ワーカーをスケールする前に考慮すべき重要なポイント: 根本原因の分析 高い CPU/メモリ使用率がタスク最適化の問題に起因するかどうかを確認する。 キューイングの問題がリソース制限ではなく設定の制約に起因するかどうかを調べる。 メモリリークやリソース枯渇のパターンがないか調査する。 設定の最適化 Airflow パラメータ (同時実行数の設定、プール、タイムアウト) を確認・調整する。 異なる設定レイヤー間の相互作用を理解する。 DAG 設計とスケジューリングパターンを最適化する。 最も成功している Amazon MWAA の実装は、体系的なアプローチに従っています。まず既存のリソースと設定を最適化し、データに基づくキャパシティプランニングで正当化された場合にのみワーカーをスケールします。信頼性の高いワークフローパフォーマンスを維持しながら、コスト効率の高い運用が実現します。 ワーカーのスケーリングは、Amazon MWAA 最適化ツールキットの 1 つのツールにすぎません。長期的な成功は、適切なモニタリング、プロアクティブなキャパシティプランニング、Airflow ワークフローの継続的な最適化を組み合わせたパフォーマンス管理戦略の構築にかかっています。 次の記事では、環境に追加の DAG を投入する前に実行すべきキャパシティプランニングの手順について説明します。追加の負荷に対する計画を立て、十分なヘッドルームを確保する方法を解説します。 開始するには、 Amazon MWAA の製品ページ と Performance tuning for Apache Airflow on Amazon MWAA ページをご覧ください。 ご質問がある場合や MWAA のスケーリング経験を共有したい場合は、以下にコメントを残してください。 著者について Boyko Radulov AWS のシニアクラウドサポートエンジニアで、Amazon MWAA と AWS Glue のサブジェクトマターエキスパートです。お客様と密接に連携し、コスト削減しながら AWS 上のワークロードの構築と最適化を支援しています。仕事以外では、スポーツと旅行に情熱を注いでいます。 Kamen Sharlandjiev Kamen は、プリンシパルビッグデータおよび ETL ソリューションアーキテクトで、Amazon MWAA と AWS Glue ETL のエキスパートです。複雑なデータ統合やオーケストレーションの課題に直面しているお客様の負担を軽減することをミッションとしています。 Venu Thangalapally シカゴを拠点とする AWS のシニアソリューションアーキテクトで、クラウドアーキテクチャ、データとアナリティクス、コンテナ、アプリケーションモダナイゼーションに深い専門知識を持っています。金融サービス業界のお客様と連携し、ビジネス目標をセキュアでスケーラブルかつコンプライアンスに準拠したクラウドソリューションに変換しています。 Harshawardhan Kulkarni AWS のパートナーテクニカルアカウントマネージャーで、Amazon MWAA のサブジェクトマターエキスパートです。アイルランドのダブリンを拠点に、EMEA のエンタープライズのお客様と連携し、複雑なワークフローやオーケストレーションの課題をナビゲートしながらベストプラクティスの実装を支援しています。 Andrew McKenzie AWS での経験から得た深い技術的専門知識を活用するデータエンジニア兼エデュケーターです。元 Amazon MWAA サブジェクトマターエキスパートとして、現在はデータソリューションの構築とデータエンジニアリングのベストプラクティスの教育に注力しています。

みなさん、こんにちは。今回の月刊 AWS 製造を担当させたいただきます。自動車・製造ソリューションアーキテクトのミカエルです。 今月は、製造関連のビッグイベントである 2026 年のハノーバーメッセの他に、開催予定のイベントや直近 1 カ月に発表された製造関連のブログ・サービスアップデート・事例などをお届けしています。 ピックアップトピック HANNOVER MESSE 2026 2026 年 4 月 20 日 〜 24 日 に開催された Hannover Messe&nbsp;2026 で、AWS は今年も様々な展示を行いました。AWS&nbsp;の自動車・製造のリーダーである&nbsp; Ozgur&nbsp;Tohumcu&nbsp;の基調講演 では、Volkswagen のデジタル生産プラットフォームを用いた 43 工場における AI の取り組みを紹介し、産業 AI を実務展開する重要性を語りました。 デジタル主権、AI エージェント、フィジカル AI、炭素排出モデルに関する 4 つの講演と 3 つのマスターコースセッションを行いました。 ドイツのロボティクススタートアップ NEURA Robotics との フィジカル AI 分野での協業 や、Infor との ERP でのエージェント AI 活用 が発表されました。 AWS のブースでは、フィジカル AI を始めとした産業 AI の実務適用に向けた様々なデモや、 欧州主権クラウド や、Amazon のサプライチェーンやロボティクスにおける AI 活用の事例を含む 47 に及ぶデモ展示、52 の シアターセッション を実施しました。ブースデモの内容については、 こちらのブログ でご紹介していますので、併せてご覧ください。 AWS Summit Japan 2026 今年の AWS Summit Japan では、製造業向けにはハイライト展示とインダストリ展示を用意させていただいています。 ハイライト展示では、「AI で加速する製造業のルネッサンス」というテーマで、製造業の普遍的な目標であるばらつき低減、迅速な意思決定、生産能力向上を、仮想化・AI・データ統合という最新技術で飛躍的に向上させる「製造業のルネッサンス」を体験できる展示です。サプライチェーンの需要・リスクの予測、工場のボトルネック特定、制御プログラムを含むシミュレーション検証、設備への安全なデプロイ、PLM データを活用した学習レス外観検査まで、AI によって得られる製造現場での新しい能力を実機デモで紹介します。 インダストリ展示では、いくつかの AWS とパートナーのソリューションを紹介します。 直近での開催予定のイベント 5/26 Amazon Quick で実現する AI 業務変革 — 半日で一気見できるパートナーエクスポ Amazon Quick の導入を検討中の企業の DX 推進責任者・IT 部門責任者向けに、多数のパートナー企業が一堂に会し、それぞれの強みと伴走支援サービスをご紹介します。本イベント主催側による最新機能デモと業界別実践ハンズオンに加え、各パートナーの専門性を直接比較・相談できる機会です。一日で複数のパートナーの比較検討できるため、導入判断に必要な情報を効率的に収集し、業務改善への第一歩を早期に踏み出すことができます。 6/25 – 6/26 AWS Summit Japan 2026 今年も日本最大の “AWS を学ぶイベント” AWS Summit Japan が 6 月 25 日（水）、26 日（木）の二日間で開催されます！ベストプラクティスの共有や情報交換のこのチャンスにぜひご来場ください。ご登録は&nbsp; こちらのリンク からお願いします。 製造関連ブログの紹介 4/13 荏原製作所様と共催！社内クラウドイベント「Ebara Cloud Day」開催レポート クラウドに対する心理的障壁を取り除き、社内のクラウド活用文化を醸成することを目的に、2026 年 3 月 25 日にオンラインで開催されました。AWS によるクラウド基礎セッションに加え、社内エンジニア 5 名による LT（新入社員研修での EC2 構築、EC2 運用、中国リージョン導入、Kiro を活用したツール開発、EventBridge/Lambda によるコスト半減事例）が発表され、満足度 4.27/5.0、次回参加意向 100% という高い成果を達成。IT 部門が「クラウドの旗振り役」として社内に認知される契機となった事例です。 AI-DLC は開発をどう変えるか – ブラザー工業エンジニアが語る AI-DLC 体験記 ブラザー工業のエンジニア 4 名が、AI-DLC（AI 駆動開発ライフサイクル）体験会に参加した感想をインタビュー形式で語るブログ記事です。 2026 年 2 月・3 月に各3日間実施された体験会では、要件定義から実装まで開発の全フェーズで AI を活用する新しい働き方を実践。参加者からは「コーディング支援の枠を超えた開発手法の変革」「企画と開発の距離が縮まる」といった驚きの声が上がる一方、ドメイン知識や「問いかける力」の重要性、ジュニアエンジニアの成長機会確保といった AI 時代ならではの課題も浮き彫りになりました。組織展開に向けた具体的な戦略も議論されています。 4/14 パナソニック エレクトリックワークス株式会社の新組織立ち上げに向けた取り組み – AI 駆動開発ライフサイクルと AI 成熟度診断の実践 このブログでは、その立ち上げに向けて AWS と連携して実施した2つの取り組み ― わずか2.5日で動作するシステムを構築する「AI-DLC Unicorn Gym」と、日本初実施となる CAF-AI ベースの「AI Foundation Pack」による組織の AI 成熟度診断 ― を紹介しています。企画と開発の壁を越えたチーム協働の実現と、AI 活用戦略の策定に向けた組織的な目線合わせの実践事例です。 4/19 AWS と NVIDIA によるフィジカル AI の加速: シミュレーションと実世界での学習による本番環境向けアプリケーションの構築 AWS と NVIDIA は、フィジカル AI（ロボットや自律システムが物理世界で知的に行動するAI）を本番環境で実用化するためのリファレンスアーキテクチャを発表しました。このアプローチでは、NVIDIA Isaac Sim と Isaac Lab によるシミュレーション上での高速・安全な大規模訓練と、AWS IoT Greengrass や Amazon SageMaker を活用したエッジデプロイ後の実世界データによる継続的なモデル改善を組み合わせることで、シミュレーションと現実のギャップ（sim-to-real ギャップ）を埋めます。これにより、製造・物流・ヘルスケアなどの分野で、開発を加速しコストを抑えながら、運用中も自律的に性能が向上し続けるフィジカル AI システムの構築が可能になります 。 4/28 製造業 × 生成 AI 、8 社の「ここだけの話」がつながり課題解決を加速する — AWS 生成 AI ラウンドテーブル in 大阪 開催報告 2026 年 3 月 31 日に AWS 大阪オフィスで開催された、製造業 8 社（シャープ、ヤマハ、村田製作所、日立産業制御ソリューションズ、コベルコシステム、東洋紡、大日本印刷、ダイキン工業）のクローズド・ラウンドテーブルの開催報告です。社内ツールの現場定着、少人数での AI 推進体制、製造業特有の非構造化データの扱いといった共通課題に対し、各社の実践知が交換された様子が紹介されています。AWS セッションでは Amazon Bedrock AgentCore を活用した AgentOps の 4 ステップ評価フレームワークも紹介されています。 イベント動画のご紹介 4/29 What’s Next with AWS – AWS and OpenAI leaders on Agentic AI | Amazon Web Services AWS と OpenAI が、エージェンティック AI の次なる展開を共有し、エージェントがビジネスやビルダーの働き方をどのように変えているかを示す新機能を発表します。AWS CEO のMatt Garman 氏、AWS Applied AI ソリューション担当 SVP の Colleen Aubrey 氏、OpenAI CRO の Denise Dresser 氏をはじめとするリーダーたちによる率直なディスカッションをご覧ください。AWS と OpenAI のパートナーシップの拡大、Amazon Quick の新機能、そして Amazon での実際の運用から得た知見をもとに構築されたエージェンティック AI ビジネスソリューションファミリーである Amazon Connect についてお聞きください。 製造関連の主要なサービスアップデート 4/17 Engineering Development Hub (EDH) のリリース Hannover Messe での展示と併せて、2026 年 4 月に元 Scale-Out Computing on AWS (SOCA) が EDH に名前を変えました。EDH は、計算集約型ワークロード向けのマルチユーザー環境を容易にデプロイ・運用できるオープンソースソリューションです。豊富なコンピューティングリソース、高速ネットワーク、無制限のストレージ、予算・コスト管理機能を AWS に統合し、キュー、スケジューラ、AMI、ソフトウェアを自由に構成できる UI と自動化ツールを提供します。スケールアウトワークロードの実行環境として、本番対応のリファレンス実装を提供し、複雑な計算問題のシミュレーションに集中できるよう設計されています。 4/20 AWS IoT Greengrass v2.17 が非ルートインストールをサポートし、新しい軽量コンポーネントを導入 AWS IoT Greengrass v2.17&nbsp;が利用可能になりました。Linux&nbsp;システム上で非ルートユーザーとしてエッジランタイムを実行できるようになり、メモリ使用量を大幅に削減した軽量コンポーネントのデプロイが可能になりました。AWS IoT Greengrass&nbsp;は、IoT（モノのインターネット）エッジランタイムおよびクラウドサービスであり、お客様がエッジでデバイスソフトウェアを構築、デプロイ、管理することを支援します。 4/26 Research and Engineering Studio on AWS (RES) 2026.03 のリリース Research and Engineering Studio on AWS (RES)&nbsp;は、管理者がセキュアなクラウドベースの研究・エンジニアリング環境を作成・管理するための、オープンソースで使いやすいウェブベースのポータルです。RES&nbsp;を使用することで、科学者やエンジニアはクラウドの専門知識がなくても、データの可視化やインタラクティブなアプリケーションの実行が可能になります。 RES 2026.03&nbsp;では、管理者が環境の設定と管理をより柔軟に行えるようになりました。管理者は、複数の個別の&nbsp;FSx&nbsp;for ONTAP&nbsp;ボリュームを&nbsp;RES&nbsp;ファイルシステムとしてオンボードできるようになりました。また、DCV&nbsp;トークンの有効期限を設定できるようになり、より長時間のセッションファイルを有効にする場合に便利です。さらに、RES&nbsp;ログインページにアカウント管理ページ、ヘルプドキュメント、利用ポリシーページなどのリソースへのカスタムリンクを最大3つ追加できるようになりました。 4/28 Amazon Connect Decisions のリリース Amazon Connect &nbsp;は、単一製品から、Amazon Connect Decisions (サプライチェーン)、Talent (採用)、Customer (カスタマーエクスペリエンス)、および&nbsp;Health (ヘルスケア)&nbsp;の&nbsp;4&nbsp;つを含めた一連のエージェンティック&nbsp;AI&nbsp;ソリューションへと拡大されました。これらは既存のワークフローで機能するように設計されています。 Amazon Connect Decisions は、サプライチェーンチームが事後対応型のオペレーションからプロアクティブ（先手を打つ）なオペレーションへの転換を支援する、エージェント型 AI 計画・インテリジェンスソリューションです。Amazon の 30 年にわたるオペレーション科学と 25 以上の専門的なサプライチェーンツールを組み合わせ、AI チームメイトがお客様のビジネスに適応し、チームの意思決定から学習し、オペレーションを継続的に改善します。Amazon Connect Decisions は、既存のシステムを置き換えることなくサプライチェーンオペレーションを変革したいと考える、小売、消費財（CPG）、自動車、産業製造業などの幅広い業界のお客様にご利用いただけます。 最後までに読んでいただき、ありがとうございました。来月も 月刊 AWS 製造ブログ をよろしくお願いします。 著者について &nbsp; Mickaël Charneau (シャルノ ミカエル) AWS とパートナーのソリューションを元に、自動車と製造のお客様の業務の効率化とデジタルトランスフォーメーションをサポートしているソリューションアーキテクトです。

1. はじめに Amazon Connect Customer は音声/ビデオとチャットを個別のチャネルとしてサポートしており、それぞれ独自の API を備えています。ネイティブウィジェットやカスタムウィジェットを使う場合、各チャネルは独立して動作します。一般的なコンタクトセンターのシナリオではこれで十分です。 しかし、顧客とエージェントのやり取りが通話だけでは済まない場合はどうでしょうか？ たとえば、顧客がローン申請の最終手続きのために電話をかけてきたとします。エージェントは事前承認を確認しますが、顧客は書類を確認して署名する必要がありますが、郵送された書類はまだ届いていない状況です。エージェントは顧客に電話を切って郵便を待つよう伝えるか、別でチャットを開始するしかありません。複数のやり取り、異なるエージェント、場合によっては数日の遅延が発生します。 もし通話中にエージェントが書類を送信できたらどうでしょうか？ 顧客はその場で署名して返送できます。同じエージェント、同じやり取りで済ませられ、数日ではなく数分で完了することができるでしょう。 本記事ではこのような課題を扱います。音声/ビデオとチャットを統合し、シームレスな顧客体験を実現するソリューションを紹介します。 1.1. Amazon Connect Customer で実現できる理由 根本的な課題はシンプルです。ライブ通話中に顧客がエージェントとテキストメッセージやファイルをやり取りするにはどうすればよいか、ということです。 Amazon Connect Customer は必要な API とツールを提供しています。StartWebRTCContact API で音声・ビデオ通話を開始し、DescribeContact API でエージェントが応答した後のエージェント ID を取得できます。コンタクトフローは特定のエージェントにルーティングするための属性をサポートしており、チャットウィジェットは初期化時にコンタクト属性を受け取れるため、チャット開始時にアプリケーションからエージェント ID を渡せます。 これらの機能はいずれも新しいものではありません。新しいのは、それらを組み合わせる方法です。カスタム UI がアクティブな通話からエージェント ID を抽出し、チャットのルーティングロジックに渡します。チャット中も顧客は同じエージェントに接続されたままで、切断や別のキューでの待機は不要です。 1.2. ビジネス価値 1 回の顧客・エージェント間のやり取りでチャネルを統合することで、具体的な効果が得られます。 顧客にとって: コールバックや転送、別のキューでの待機が不要になります。先ほどのローンの顧客は、数日ではなく数分で申請を完了できます。 運用面: エージェントが顧客対応をエンドツーエンドで完結できます。重複作業、引き継ぎの手間、フォローアップタスクによるエージェントの負荷がなくなります。 コンプライアンス面: すべての音声・チャットのやり取りが 1 人のエージェント、1 人の顧客、1 つのケースに紐づきます。規制の厳しい業界では、チャネルをまたいだコンタクトレコードの紐づけにより監査が容易になります。 2. ソリューションのアーキテクチャ このソリューションは、カスタムフロントエンドを 3 つのレイヤー (ホスティングと配信、認証と認可、リアルタイム通信) で AWS サービスに接続します。 2.1. 概要 以下の手順は、図の番号付きラベルに対応しています。 ステップ 1 — 認証。顧客がユーザーインターフェースにログインします。フロントエンドが認証情報を Amazon Cognito ユーザープール に送信し、検証後に ID トークンが返されます。 ステップ 2 — 認可。フロントエンドが ID トークンを Amazon Cognito アイデンティティプール に渡し、 AWS STS の AssumeRoleWithWebIdentity を呼び出します。IAM ロールが Amazon Connect に対する最小権限を付与し、一時的な認証情報がフロントエンドに返されます。これは重要な設計上のポイントです。フロントエンドは長期間有効なシークレットを保持せず、すべての認証情報はスコープが限定され、短期間で失効します。 ステップ 3 — 音声・ビデオ通話。顧客が通話を開始します。フロントエンドは一時的な認証情報を使って StartWebRTCContact API を呼び出し、WebRTCQueueRouting コンタクトフローをトリガーします。このフローが対応可能なエージェントに通話を割り当て、 Amazon Chime SDK のミーティング設定を返します。フロントエンドは Chime SDK セッションを初期化し、リアルタイムの音声・ビデオストリームを管理します。同時に、フロントエンドは DescribeContact API を呼び出してアクティブなコンタクトからエージェント ID を取得し、ローカルに保存します。 ステップ 4 — 同じエージェントとのチャット。顧客がチャットを開くと、フロントエンドは保存済みのエージェント ID を Amazon Connect Customer チャットウィジェット に渡します。チャットウィジェットは Amazon Connect Customer のホストエンドポイントから読み込まれます。チャットコンタクトが ChatAgentRouting コンタクトフローをトリガーし、エージェント ID を使って通話中の同じエージェントに直接ルーティングします。このステップで、音声/ビデオとチャットが 1 人のエージェントに集約されます。やり取りが終了すると、フロントエンドは StopContact と DisconnectParticipant API を呼び出してセッションを適切に終了します。 2.2. フロントエンドコンポーネント ユーザーインターフェースは 5 つのコンポーネントで構成され、それぞれ異なる役割を担います。 Authentication State Manager は、Cognito ユーザープールのフローを通じてログインを処理し、ID トークンを生成します。 Credential Manager は、そのトークンを Amazon Connect Customer API にスコープされた一時的な AWS 認証情報と交換します。 Session Manager は通話のセッション全体を管理します。暗号化されたセッションコンテキストをローカルストレージに保存し、通話の開始を制御し、チャットウィジェットのルーティング先となるエージェント ID を取得します。 WebRTC Manager はリアルタイムメディアを管理します。StartWebRTCContact の呼び出し、Chime SDK セッションの初期化、音声/ビデオストリームの管理を行います。 Chat Widget は Amazon Connect Customer のホストエンドポイントから読み込まれます。Session Manager からエージェント ID を受け取り、チャットを同じエージェントにルーティングします。コンタクトの作成、WebSocket 接続、メッセージング、ファイル添付など、チャットのライフサイクル全体を処理します。 2.3. バックエンドサービス バックエンドは 3 つのレイヤーの AWS サービスで構成されています。 ホスティングと配信: Amazon CloudFront がセキュリティヘッダーとキャッシュを使って UI をグローバルに配信します。Amazon S3 に静的アセットを保存します。 認証と認可: Amazon Cognito ユーザープール、Amazon Cognito アイデンティティプール、AWS STS、IAM が連携します。フロントエンドには必要最小限の権限のみが付与されます。 コミュニケーション: リアルタイムのやり取りが行われるレイヤーです。StartWebRTCContact API が WebRTCQueueRouting フローをトリガーしてエージェントを割り当てます。API は Amazon Chime SDK の設定を返し、フロントエンドがリアルタイムの音声・ビデオを確立します。DescribeContact API でエージェント ID を取得し、ChatAgentRouting フローがチャットを同じエージェントにルーティングします。StopContact と DisconnectParticipant API でセッションをクリーンアップします。 3. 前提条件 デプロイには、以下の準備が必要です。 AWS アカウント ファイル添付が有効化 された Amazon Connect Customer インスタンス AWS CDK v2 のインストールと設定 Node.js v20.x 以降 適切な権限で設定された AWS CLI 4. ソリューションのデプロイとクリーンアップ ソリューション全体は AWS CDK アプリケーションとして GitHub リポジトリ にパッケージ化されています。このスタックは CloudFront、S3、Cognito、IAM ロール、Amazon Connect Customer コンタクトフローなど、すべてをプロビジョニングします。 README にリポジトリのクローン、依存関係のインストール、Connect インスタンスの設定、スタックのデプロイ、テストユーザーの作成、統合体験の検証まで、各手順が記載されています。 以下のステップバイステップのデプロイ手順に沿って進めてください。テストが完了したら、不要な課金を避けるためにすべてのリソースを削除してください。 5. まとめと次のステップ 本記事では、1 回の顧客・エージェント間のやり取りで、Amazon Connect の 1 人のエージェントを通じて音声/ビデオとチャットを統合する方法を紹介しました。この方法は StartWebRTCContact と DescribeContact API、コンタクトフローのルーティング、Amazon Chime SDK、標準のチャットウィジェット、Amazon Cognito と AWS STS による短期間有効な AWS 認証情報など、既存の機能を組み合わせたソリューションです。 これは 1 つのアプローチにすぎません。完全な柔軟性を求める場合は、音声/ビデオとチャットのカスタムウィジェットをゼロから構築することもできます。Amazon Connect API ( StartChatContact でチャットを開始、 CreateParticipantConnection で WebSocket 接続を確立、 SendMessage でメッセージング、 StartAttachmentUpload と CompleteAttachmentUpload でファイル共有) を使えば、すべてのインタラクションをきめ細かく制御できますが、実装の複雑さが増します。可能な限り Amazon Connect Customer の組み込み機能を活用し、必要な部分だけカスタマイズすることをお勧めします。 まず、書類への署名、ビジュアルトラブルシューティング、フォーム送信など、顧客がタスクを完了するために複数のタッチポイントを必要とするケースを特定しましょう。 GitHub リポジトリ からソリューションをデプロイし、実際に動作を確認してみてください。その後、1 つのチームと 1 つのユースケースでパイロットを実施し、導入前後の対応時間、初回解決率、顧客の手間の変化を測定しましょう。そのデータをもとに、ソリューションが自社のカスタマーサービス運用に適しているかを評価しましょう。 6. 関連資料 ソリューションの GitHub リポジトリ Amazon Connect Customer 管理者ガイド: アプリ内、ウェブ、ビデオ通話、画面共有機能のセットアップ Amazon Connect Customer StartWebRTCContact API Amazon Connect Customer DescribeContact API Amazon Chime SDK for JavaScript Amazon Cognito デベロッパーガイド Amazon Connect Customer 管理者ガイド: ウェブサイトにチャットユーザーインターフェースを追加する 著者について Ying Qian は、コンタクトセンター技術分野で 19 年以上の経験を持ち、ソリューションアーキテクト、テクニカルプロジェクトマネージャー、ICT リードエンジニア、オペレーションエンジニアなどの経験があります。AWS ではサービス担当ソリューションアーキテクトとして Amazon Connect Telephony &amp; Resiliency SME チームをリードし、AWS Well-Architected Framework の原則に沿った Amazon Connect の導入を支援しています。仕事以外ではジョギング、家族とのアルプスハイキング、ボーデン湖での水泳を楽しんでいます。 Nelson Martinez はシドニーを拠点とする Applied AI シニアソリューションアーキテクトです。コンタクトセンター、ユニファイドコミュニケーション、IP テレフォニー、ネットワーキングの分野でオーストラリアと米国にまたがり 31 年以上の経験を持ちます。AWS で 5 年以上にわたり、クラウドコンタクトセンターと Applied AI ソリューションを専門とし、グローバル規模で業界をリードする実装を直接お客様と進めています。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

新しいノーコード機能によって、ビジネスチームはエンジニアリングのボトルネックなく、AI を活用した高度なカスタマーエクスペリエンスを迅速に構築できます。エージェンティック AI の柔軟性と企業が求める信頼性を兼ね備えています。 NLX ( nlx.ai ) が Amazon Connect のチームに加わり、Connect のエージェンティック AI ソリューションの価値提供を加速します。NLX は高度な会話型 AI 機能を備えており、今回の買収により、企業が求めるコントロール性と信頼性を損なうことなく、AI を活用したカスタマーエクスペリエンスを数か月ではなく数週間で Connect にデプロイできるようになります。NLX のノーコードキャンバスを使えば、ビジネスチームはエンジニアリングリソースを待つことなく、Connect で的確なセルフサービス体験を設計・展開できます。そしてあらゆるチャネルでパーソナライズされた対話を提供し、顧客ロイヤルティを高める柔軟性を利用できます。 NLX チームの魅力 優秀な NLX チームの心強い点は、私たちのカルチャーとの一致です。NLX は、お客様に実際の成果を届けることへのこだわりで私たちと一致しています。ビジネスの迅速化、コントロール性の維持、優れたカスタマーエクスペリエンスの提供を実現するソリューションを構築してきた NLX の価値観は、Amazon のイノベーションへの取り組み方と一致しています。私たちは会話型 AI の展開における難しい課題の解決への情熱と、お客様中心のアプローチに感銘を受けています。 エンタープライズ規模での実績 United Airlines は 12 か月ではなく 3 か月で本番稼働を実現し、ある大手グローバル小売企業は 6 か月ではなく 6 週間でデプロイしました。いずれも例外的な事例ではなく、技術的なボトルネックを取り除き、お客様を最もよく理解するチームがデザインの主導権を持つことで実現できた成果です。 NLX チームの参加により、Amazon Connect のお客様にとって価値実現までの時間が短縮されます。企業は期待どおりのコントロール性と実績あるスケーラビリティを維持しながら、適切な体験をより迅速にデプロイできます。 詳細については、 Amazon Connect Customer をご覧ください。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

AWS の請求書からわかるのは、支出パターンだけではありません。セキュリティ上の問題を特定することもできます。 AWS Cost and Usage Reports (CUR) には、 AWS Organizations 全体にわたる詳細な使用状況データが含まれており、コスト最適化の機会の発見、コストの配分、そして潜在的なセキュリティリスクの検出に活用できます。この記事では、AWS CUR を使用して環境内の潜在的なセキュリティ上の問題を特定する方法について説明します。潜在的なリスクの例と、それらがアカウント内に存在するかどうかを判断するために使用できる CUR データ内のマーカーを紹介します。 この記事の手順に沿って進めるには、AWS Organizations のプライマリ請求アカウント (※注) (または委任管理者アカウント) へのアクセス権があること、 Data Exports が設定された Cost and Usage Reports 2.0 が利用可能であること、そしてデータをクエリするための Amazon Athena へのアクセス権があることが必要です。 ※注：通常は管理アカウントですが、AWS Billing Transfer 利用時は異なる場合があります。 各セキュリティリスクについて、それが問題となる理由、検出方法、そして AWS 環境内の潜在的な問題を特定するために コンソールの Athena で CUR データに対して実行できる SQL クエリなどの詳細を提供します。CUR テーブル名と日付フィルターにはプレースホルダーとして ${table} と ${date-filter} を使用しています。これらの値の確認方法については、 CUR Query Library を参照してください。また、質問や発見事項がある場合は、自社のアーキテクチャを踏まえて検討できるよう、貴社のセキュリティチームにも相談してください。 リスク 1：暗号化されていない Amazon CloudFront トラフィック 問題点： Amazon CloudFront は、暗号化されたトラフィック (HTTPS) と暗号化されていないトラフィック (HTTP) の両方をサポートしています。HTTP をサポートするように設定されている場合、ユーザーと CloudFront ディストリビューション間のデータは保護されない状態で送信されます。このトラフィックを傍受した第三者は、データを読み取ったり改ざんしたりすることが可能です。 多くのコンプライアンスフレームワーク (PCI DSS、HIPAA、GDPR) では、転送中のデータの暗号化が求められています。暗号化されていないトラフィックは、コンプライアンス違反、データ侵害、そして顧客からの信頼の喪失につながる可能性があります。 検出方法： CUR は、HTTP トラフィックと HTTPS トラフィックを区別する特定の使用タイプコードを通じて、CloudFront の使用パターンを記録しています。HTTP トラフィックでは、region-Out-Bytes-HTTP-Static や region-Out-Bytes-HTTP-Dynamic のような料金が発生し、セキュアなトラフィックでは region-Out-Bytes-HTTPS-Static や region-Out-Bytes-HTTPS-Dynamic として表示されます。これらの HTTP 料金が存在する場合、ポリシー違反の可能性があることを示しており、調査が必要です。 以下のクエリを使用して、CloudFront ディストリビューション上の暗号化されていないトラフィックを特定できます。 SELECT line_item_resource_id, line_item_usage_type, product['region'] AS region, billing_period, SUM(line_item_usage_amount) AS total_usage_amount, SUM(line_item_unblended_cost) AS total_cost FROM ${table} WHERE product['product_name'] = 'Amazon CloudFront' AND ( line_item_usage_type LIKE '%HTTP-Static%' OR line_item_usage_type LIKE '%HTTP-Dynamic%' OR line_item_usage_type LIKE '%HTTP-Proxy%' ) AND line_item_usage_type NOT LIKE '%HTTPS%' AND line_item_unblended_cost &gt; 0 AND billing_period = ${date-filter} GROUP BY 1, 2, 3, 4 ORDER BY total_cost DESC; このクエリの結果は、暗号化されていないトラフィックを実際に配信している CloudFront ディストリビューションを示します。line_item_resource_id を使用して CloudFront コンソールで該当するディストリビューションを見つけ、Viewer Protocol Policy を「Redirect HTTP to HTTPS」または「HTTPS Only」に更新してください。 リスク 2：承認されていないリージョンの使用 問題点： 組織は通常、データ所在地の要件、コンプライアンス規制、またはビジネスポリシーに基づいて、特定の承認されたリージョンで AWS リソースを運用しています。承認されていないリージョンにリソースが存在する場合、認証情報の漏洩や、従業員が確立されたポリシーを回避している可能性を示唆しており、調査が必要です。 検出方法： CUR は、各明細項目の product[‘region’] フィールドを通じてリージョン情報を記録しており、送信元-送信先-使用状況のパターン (例：USE1-TimedStorage-ByteHrs) に従うデータ転送コードを識別します。承認済みリスト外のリージョンでフィルタリングすることで、想定外のリソース使用を特定できます。なお、AWS CloudTrail など一部の AWS サービスは、設計上グローバルまたは複数リージョンにまたがって動作するため、この分析からは除外する必要があります。 以下のクエリを使用して、承認済みリスト外のリージョンで発生している料金を特定できます。クエリを実行する前に、NOT IN 句を更新して、組織で承認されているすべてのリージョン (例：’us-east-1’、’us-west-2’、’eu-west-1’、’global’) を含めてください。 SELECT CASE WHEN (bill_billing_entity = 'AWS Marketplace' AND line_item_line_item_type NOT LIKE '%Discount%') THEN product['product_name'] WHEN (product['product_name'] = '') THEN line_item_product_code ELSE product['product_name'] END AS product_name, CASE product['region'] WHEN NULL THEN 'Global' WHEN '' THEN 'Global' WHEN 'global' THEN 'Global' ELSE product['region'] END AS product_region, line_item_availability_zone, SUM(line_item_unblended_cost) AS sum_line_item_unblended_cost FROM ${table} WHERE billing_period = ${date-filter} AND line_item_line_item_type IN ('DiscountedUsage', 'Usage', 'SavingsPlanCoveredUsage') AND product['region'] NOT IN ('us-east-1', 'global') -- update with approved region list GROUP BY 1, line_item_product_code, line_item_availability_zone, product['region'] HAVING SUM(line_item_unblended_cost) &gt; 0 ORDER BY product_region, sum_line_item_unblended_cost DESC; このクエリの結果は、承認されていないリージョンで稼働しているリソースを示しています。product_name と product_region の列を確認して、どのサービスがどこで実行されているかを特定してください。コストの高い項目は、暗号通貨のマイニングやその他の悪意のあるアクティビティを示している可能性があるため、優先的に調査してください。CloudTrail のログと照合して、これらのリソースを誰が作成したのか、そのアクティビティが承認されたものであったかどうかを確認してください。 リスク 3：Amazon CloudFront と Route 53 における保護されていない DDoS 攻撃対象領域 問題点： Amazon CloudFront と Amazon Route 53 は、DNS 解決とコンテンツ配信を大規模に処理する、ワークロードへの入り口となることが多いサービスです。その露出度の高さゆえに、ボリューム型 DDoS 攻撃の標的となります。 AWS Shield Advanced などのプロアクティブな DDoS 保護がない場合、組織は専用の DDoS 保護レイヤー、リアルタイムの攻撃通知、および AWS DDoS Response Team (DRT) へのアクセスを欠くことになります。この保護のギャップは、サービス停止、攻撃中のパフォーマンス低下、そしてダウンタイムによる潜在的な経済的損失につながる可能性があります。 検出方法： CUR は、このセキュリティギャップを、データの存在ではなく不在によって明らかにします。CloudFront と Route 53 の支出を算出し、同じ請求期間内に Shield Advanced の料金が存在するかどうかを確認することで、保護されていないインフラストラクチャを特定できます。CloudFront または Route 53 のコストが発生しているにもかかわらず、対応する Shield Advanced の支出がない場合、それらのディストリビューションには専用の DDoS 保護が欠けていることを意味します。 以下のクエリを使用して、Shield Advanced のカバレッジがないままの CloudFront/Route 53 の支出を検出できます。 WITH cloudfront_route53_spend AS ( SELECT billing_period, SUM(line_item_unblended_cost) AS exposed_spend FROM ${table} WHERE product['product_name'] IN ('Amazon CloudFront', 'Amazon Route 53') AND line_item_unblended_cost &gt; 0 AND billing_period = ${date-filter} GROUP BY 1 ), shield_spend AS ( SELECT billing_period, SUM(line_item_unblended_cost) AS shield_cost FROM ${table} WHERE product['product_name'] = 'AWS Shield' AND line_item_unblended_cost &gt; 0 AND billing_period = ${date-filter} GROUP BY 1 ) SELECT c.billing_period, c.exposed_spend AS cloudfront_route53_spend, COALESCE(s.shield_cost, 0) AS shield_advanced_spend, CASE WHEN COALESCE(s.shield_cost, 0) = 0 THEN 'No Shield Advanced - DDoS Protection Gap' ELSE 'Shield Advanced Active' END AS ddos_risk_status FROM cloudfront_route53_spend c LEFT JOIN shield_spend s ON c.billing_period = s.billing_period ORDER BY c.exposed_spend DESC; 結果に「No Shield Advanced – DDoS Protection Gap」と表示された場合、DDoS 保護なしで稼働している CloudFront または Route 53 のディストリビューションがあることを示しています。exposed_spend を確認して、AWS 環境全体で保護されていないインフラストラクチャとリソースを特定してください。リスク許容度と、DDoS 攻撃がオペレーションに与える潜在的な影響に基づいて、費用対効果を評価してください。特に機密データやビジネスクリティカルなアプリケーションを扱う重要なディストリビューションについては、AWS Shield Advanced の有効化を検討してください。 リスク 4：延長サポートが適用された古いソフトウェア 問題点： 延長サポートの料金 が発生しているということは、既知のセキュリティ上の脆弱性を含む古いバージョンのソフトウェアでシステムが稼働していることを示しています。標準サポートのライフサイクルを超えたレガシーソフトウェアバージョンの運用を続けている場合、割増料金 (100〜600% のコスト増加) を支払っているだけでなく、それらの古いバージョンには攻撃者が悪用可能なパッチ未適用の脆弱性が含まれている可能性もあります。3 年目以降の延長サポートは、延長サポート対象のリソースの重要度に応じて、即時の修復が必要となる可能性のある深刻なリスクがあることを示しています。延長サポートによる財務的な影響は、アップグレードの優先度を上げるべき明確なシグナルとしても捉えるべきです。 検出方法： CUR は、line_item_usage_type フィールドに「ExtendedSupport」パターンを含む延長サポート料金を記録します。これらの料金は請求データ内で個別の明細項目として表示されるため、容易に特定できます。使用タイプに ExtendedSupport を含む Usage 明細項目でフィルタリングすることで、脆弱性のある古いバージョンで稼働しているワークロードやリソースを正確に特定できます。コストの大きさもまた深刻度を示す指標となります。延長サポートのコストが高いほど、一般的にはより古いバージョンで稼働していることを意味し、より緊急な対応が求められます。以下のクエリを使用して、延長サポート料金が発生しているシステムを特定できます。 SELECT line_item_line_item_type, line_item_resource_id, line_item_usage_account_id, product['product_code'] AS product_code, line_item_operation, line_item_line_item_description, line_item_usage_type, billing_period, SUM(line_item_usage_amount) AS sum_line_item_usage_amount, SUM(line_item_unblended_cost) AS sum_line_item_unblended_cost FROM ${table} WHERE billing_period = ${date-filter} AND line_item_line_item_type = 'Usage' AND line_item_usage_type LIKE '%ExtendedSupport%' GROUP BY 1, 2, 3, 4, 5, 6, 7, 8 ORDER BY sum_line_item_unblended_cost DESC LIMIT 100; 延長サポート料金が表示された結果は、古く脆弱性のあるソフトウェアが存在しており、早急な対応が必要であることを示しています。line_item_line_item_description を確認して、具体的なリソースやワークロードを特定してください。コストへの影響とサポートティアに基づいてアップグレードの優先順位を決定してください。たとえば、長期 (3 年以上) の延長サポートは重大なリスクを伴う可能性があり、移行計画の推進に役立てることができます。 リスク 5：異常なデータ転送コスト 問題点： データ転送料金の急増は、セキュリティ上の問題を示している可能性があります。攻撃者が AWS 環境を侵害した場合、大量のデータを窃取 (持ち出し) しようとしたり、外部のコマンド＆コントロール (C&amp;C) サーバーと通信するためにリソースを悪用したりすることがよくあります。これらのアクティビティは、請求データ上でコストの異常として現れる、通常とは異なるデータ転送パターンを生み出します。 検出方法： CUR は、lineItem/UsageType フィールドを通じて詳細なデータ転送情報を記録しています。このフィールドにより、アウトバウンドインターネットトラフィック (DataTransfer-Out-Bytes)、リージョン間転送 (AWS-Out-Bytes)、アベイラビリティゾーン間トラフィック (DataTransfer-Regional-Bytes) など、さまざまな種類のデータ移動を識別できます。これらのパターンを時系列で分析し、ベースラインの使用状況と比較することで、調査が必要な不審な急増を特定できます。 以下のクエリを使用して、セキュリティ上の問題を示す可能性のあるデータ転送コストとパターンを特定できます。 SELECT line_item_usage_account_id, line_item_resource_id, product['region'] as region, line_item_usage_type, product_product_family, line_item_operation, product_from_location, product_to_location, pricing_unit, DATE_FORMAT(line_item_usage_start_date, '%Y-%m-%d') AS usage_date, ROUND(SUM(line_item_usage_amount), 2) AS total_gb, ROUND(SUM(line_item_unblended_cost), 2) AS total_cost FROM ${table} WHERE product_product_family = 'Data Transfer' AND line_item_line_item_type = 'Usage' AND ( line_item_usage_type LIKE '%DataTransfer-Out-Bytes%' OR line_item_usage_type LIKE '%DataTransfer-Regional-Bytes%' OR line_item_usage_type LIKE '%AWS-Out-Bytes%' ) AND billing_period = ${date-filter} GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ORDER BY total_cost DESC, total_gb DESC; この結果で大幅なコスト増加や通常とは異なる転送パターンが示された場合は調査が必要です。他のリスクほど単純に潜在的なリスクを判断できるものではないため、このデータについては必ず開発チームと連携して確認してください。確認すべき主なフィールドは以下のとおりです。 line_item_resource_id： データ転送を発生させている特定の AWS リソース (EC2 インスタンス、S3 バケットなど) を識別します total_gb： 転送されたデータ量 — 急激な増加は調査が必要です total_cost： 転送アクティビティによる財務的な影響 product_from_locationとproduct_to_location： 転送元と転送先のリージョン line_item_resource_id を既知のリソースと照合して、承認されていないインスタンスや侵害されたインスタンスがないかを確認してください。さらに詳しく調査するには、これらの結果を VPC Flow Logs や CloudTrail と関連付けて、データ転送の急増に関連する具体的なネットワーク接続や API アクティビティを特定してください。 追加のプロアクティブなセキュリティ対策 ここまで、CUR を分析するために使用できるクエリの例をいくつか紹介してきましたが、セキュリティ上の問題を検出するために活用できる AWS サービスを使ったプロアクティブな対策もあります。 AWS Budgets は、突然の支出の急増を検出し、承認されていないリソースのプロビジョニングを示唆します。悪意のあるアクティビティの標的になりやすいコンピューティング集約型のサービスには、個別の予算を設定してください。 AWS Cost Anomaly Detection は、機械学習を使用して異常な支出パターンを自動的に検出します。1 日 3 回、24 時間の検出ウィンドウで実行されます。 Amazon GuardDuty は、行動分析とコストパターンを関連付けます。特に、不審なシステムコールとコンピューティングコストの急増を組み合わせることで、暗号通貨マイニングやその他の種類の分析を検出します。 AWS Security Hub は、コストベースの検出結果と従来のセキュリティアラートを一元化し、統合的に確認できるようにすることで調査時間を短縮します。予算アラートを GuardDuty の検出結果や Amazon Inspector の脆弱性評価と関連付けることで、包括的な脅威検出が可能になります。 今すぐ行動を開始しましょう 以下のステップから始めてください。 時間単位の粒度とリソースレベルのデータを含む AWS Cost and Usage Reports (CUR) を有効にする 前述の SQL クエリを使用して CUR データをクエリできるように Amazon Athena を設定する 厳しめのしきい値で Budgets と Anomaly Detection を設定する この記事で紹介したリスクを検出するためのクエリを実行する 検出結果を AWS Security Hub に統合し、セキュリティ管理を一元化する コストベースのセキュリティモニタリングは、財務的な痕跡を通じて脅威を検出することで、従来のセキュリティツールを補完します。経済的なインセンティブとセキュリティ要件が交わることで、より良いアーキテクチャへの改善を促す自然な力が生まれます。セキュリティ上の問題が目に見えるコストとして現れることで、組織はそれを修正する動機を得ると同時に、測定可能なセキュリティ指標も手に入れることができます。 セキュリティと FinOps のリーダーは協力して、コストベースのモニタリングを標準的なプラクティスとして確立すべきです。この記事で紹介したクエリは、すぐに実装できる手段を提供します。また、AWS のセキュリティサービスとの統合により、既存のオペレーションとの互換性も確保されます。AWS の請求データを、単なる財務レポートツールからセキュリティインテリジェンスプラットフォームへと変革しましょう。今こそ行動する時です。 Steph Gooch Steph は、シニア最適化ソリューションアーキテクトアドボケイトです。お客様が現在および将来の AWS 支出を最適化する方法をガイドする分野のエキスパートです。お客様が請求データと使用状況データを整理・分析し、そのデータから実行可能なインサイトを見出し、コスト意識を組織文化に根付かせるための持続可能な戦略を策定できるよう支援しています。前職では、Big Four の 1 社で FinOps チームを率いていました。 Mark Keating Markは、英国を拠点とするプリンシパルセキュリティソリューションアーキテクトで、グローバルのヘルスケア・ライフサイエンスおよび自動車業界のお客様と連携し、セキュリティとコンプライアンスの課題解決およびリスク低減を支援しています。オペレーション、ソリューション、エンタープライズアーキテクチャの各分野にわたり、20年以上のテクノロジー業界での経験を持っています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。 原文 はこちらです。

本ブログは ONESTRUCTION 株式会社様と Amazon Web Services Japan 合同会社が共同で執筆しました。GENIAC（Generative AI Accelerator Challenge）第 3 期の取り組みとして、ONESTRUCTION が AWS の Generative AI Innovation Center（以下、GenAIIC）から技術アドバイスを受けながら開発した、建設・BIM 特化型基盤モデル「Ishigaki-IDS」の開発事例をご紹介します。 背景 ONESTRUCTION 株式会社 （ note ） は、openBIM を中心に建設分野の課題解決に取り組む建設テックスタートアップです。建設業界の人手不足が続く中、設計・施工・維持管理の各段階で情報を一元的に扱える BIM（Building Information Modeling）の活用が、国レベルでも推進されています。一方で、BIM の導入や運用には専門知識が必要であり、習得コストの高さが普及の壁となっていました。 BIM モデル（IFC モデル）に対する情報の付与・照査の内容を定義する XML 形式の規格が IDS（Information Delivery Specifications）です。IDS の作成には、独自の文法に加えて IFC（Industry Foundation Classes）に関する知識やルールの理解が求められます。本プロジェクトでは、この専門知識の障壁を基盤モデルの力で下げ、BIM の専門家でなくても属性情報の確認と管理を行えるようにすることを目指しました。 課題 開発では主に 3 つの課題に直面しました。1 つ目はデータ不足です。IDS は 2024 年に公開された比較的新しい規格であり、建設業はもともと Web 上の公開情報が限られる領域です。金融・医療・法律のような主要ドメインでは数 B から数百 B トークン規模のコーパスが用いられることも珍しくない一方、IDS 領域ではそれに匹敵する量の公開データが存在しません。最新の Web コーパスを収集しても得られる情報はごく少量かつ浅いものにとどまり、大量のデータがなければモデルが IDS や関連情報を十分に学習できず、小手先のテクニックではカバーできない理解不足・精度不足に陥ります。2 つ目は数千規模の IFC 語彙の注入です。例えば「梁」は「IfcBeam」、「エアコン」は「IfcUnitaryEquipment」のように、建設領域の用語を IFC 上の語彙へ正確に対応付ける必要があります。従来は専門家が一つひとつ手作業で紐づけてきた知識を、モデル側に学習させなければなりません。3 つ目は IDS 独自文法の習得です。IDS は単なる XML ではなく、情報付与や確認の対象・記述内容に応じてタグ構造が変化する専用ルールを持ちます。繰り返しや専用タグの使い分けが求められるため、汎用の基盤モデルでは正確に生成することが難しい領域でした。 解決策 学習パイプライン 汎用言語性能とモデルサイズの選択肢を考慮し、Qwen3（8B / 14B / 32B）をベースに 3 段階の学習パイプラインで Ishigaki-IDS を開発しました。 継続事前学習（CPT）：Web コーパスに加え、社内のドメインエキスパートと協働して構築した大量の合成データを用い、IDS と IFC に関するドメイン知識をモデルに注入しました。具体的には、妥当性のある IDS を大量に生成するとともに、IDS 関連ドキュメントを多角的に説明する合成データセットを整備し、学習データの多くを合成で補いました。 教師ありファインチューニング（SFT）：CSV または自然言語による IDS 作成指示と、出力すべき IDS のペアデータでモデルを学習させ、IDS の「型」を安定して生成できるようにしました。SFT 単独では、XML タグの選択ミスや誤った属性値の付与など、それらしいが不正な生成が残ることが分かっており、後段の学習で補強する前提で設計しています。 検証可能な報酬による強化学習（RLVR）：国際標準団体 buildingSMART が提供する IDS-Audit-Tool を報酬関数に組み込みました。同ツールは XML としての整合性、IDS 形式としての妥当性、意味的な整合性の 3 観点を自動検証できるため、モデル自身が出力を試行し、機械的な正誤フィードバックを受けながら改善を重ねられます。RLVR は大量の教師データがなくても出力品質を洗練できるため、データが乏しい IDS 生成タスクとの相性が非常に良いと考えています。 アーキテクチャと評価 学習基盤は、Amazon EC2 P5en インスタンス（p5en.48xlarge × 2 ノード、NVIDIA H200 GPU 搭載）を AWS ParallelCluster でオーケストレーションし、学習データ・合成データ・チェックポイントは Amazon FSx for Lustre 上で高スループットに共有する構成としました。これにより、複数ノードでの分散学習と大容量データの並列アクセスを安定して回しています。評価軸は、社内の IDS 専門家と協働で独自ベンチマーク「IDS-Bench」として構築し、IFC バージョン × 建設分類（意匠／構造／設備／共通）× 言語（日本語／英語）× Implement／Structure／Content の多軸で、実業務に耐え得る精度を測定しました。 結果 開発した Ishigaki-IDS-8B と IDS-Bench は Hugging Face で公開しています。 Ishigaki-IDS-8B IDS-Bench 評価の結果、汎用フロンティアモデルでは十分に対応できないケースが多い一方、Ishigaki-IDS は IDS を適切に生成できることを確認しました。IDS が専門性の高い比較的新しい領域であるため、ドメイン特化モデルであれば解決可能な課題設定であったと考えられます。また、YaRN によるコンテキスト長スケーリングにも対応しており、最大 120k トークンほどの入出力でも問題なく生成できることを確認しました。buildingSMART と実施した実証実験でも、IDS の専門家・非専門家の双方から、業務への活用可能性や、曖昧な表現からでも意図通りの IDS を生成できる点について、ポジティブな反応を得ました。同時に、今後の改善や展開に繋がる多くの示唆もいただき、開発したモデルの実用性と意義を改めて確認できました。 IDS-Bench 評価結果。Ishigaki-IDS（8B / 14B / 32B）は XML 構造準拠・IDS 構造準拠・IDS 内容整合性準拠のいずれでも高いスコアを達成している一方、汎用フロンティアモデルでは低いスコアにとどまっている。 GenAIIC からの技術アドバイザリー ONESTRUCTION が建設・BIM ドメインの知見をもとに開発を主導し、GenAIIC から基盤モデル開発に関する技術アドバイザリーを Bi-weekly で受けながら進めました。開発の節目ごとに学習結果や評価データを持ち寄り、以下の 5 つの観点から GenAIIC の専門的な助言を得ています。 学習データ設計：IDS ドメインにおける合成データ活用と、CPT／SFT／RLVR 各段階のデータ配合・多様性設計 評価ベンチマーク：IFC／IDS 知識、構造化生成、汎用対話を多面的に評価する指標設計 学習段階と学習テクニック：CPT／SFT／RLVR の学習設計と、長文対応・報酬設計・構造化生成の最適化 学習インフラ：大規模分散学習における並列化設計と、スループット・安定性の最適化 実験結果の診断と次段の方向提示：学習・評価結果に基づく課題要因の特定と、次イテレーション方針の整理 これらの観点で「どの方向に振れば IDS 生成の精度と実用性が一段上がるか」を継続的に議論できたことが、データの乏しいニッチ領域でドメイン特化の基盤モデルを短期間で成立させる推進力となりました。 まとめと今後 専門家との協働・合成データ・検証ツール連動型の RLVR の組み合わせが、データが乏しい専門領域のドメイン特化モデル開発に有効であることを確認しました。本開発は、GenAIIC から技術アドバイスを継続的にいただきながら進められたことで、短期間でも高い品質の基盤モデルを完成させることができました。ONESTRUCTION では今後も、AWS との連携を活かしながら、AI を活用した建設 DX の推進に取り組んでまいります。 About the authors 日高洸陽 ONESTRUCTION AI戦略ユニット Manager。自社でのAI開発にとどまらず、自社製品へのAI活用や、クライアントとのAI領域の共同研究も行っています。最近生活の意思決定をAI Agentに預けるようになってきました。好きなSFは、エヴァンゲリオンとSteins Gateです。 金澤 亮 ONESTRUCTION AI戦略ユニット AIエンジニア。建設xAIの基盤モデル開発に取り組んでおり、GENIAC Cycle3ではIDS特化モデルIshigaki-IDSを開発。東京理科大学修士2年。好きなSFは、Steins Gateと三体です。 王　晨光 アマゾンウェブサービスジャパン合同会社 Applied Scientist。APJCのエンタープライズ企業に対し、LLM・VLM・MLMのトレーニングおよびエージェント導入の技術支援を担当しております。 姜　大原 アマゾンウェブサービスジャパン合同会社 Senior Deep Learning Architect。９年以上のAI・機械学習の業務経験を持ち、ビジネス環境でデータサイエンスの概念を適用することに熟練しており、現実世界の問題をモデル化し、問題を解決するためにデータを解釈し分析することに経験があります。 Angie Wang アマゾンウェブサービスジャパン合同会社 Sr. Generative AI Strategist。AWSのお客様を対象に、生成AIの活用戦略策定から本番導入までを支援しています。コンピュータサイエンスとベンチャーキャピタル投資のバックグラウンドを活かし、ビジネス戦略と技術実装の橋渡しを行っています。

2026年4月17日、目黒セントラルスクエア17F AWS Startup Loft Tokyoにて「AWS Container Platform Engineering Meetup」を開催しました。このイベントは、Amazon ECSやAmazon EKSを活用しながらプラットフォームエンジニアリングに取り組む企業が一堂に会し、実践的な知見を共有し合うイベントです。今回は約60名の方にご参加いただき、会場ではPlatform Engineering に関する様々な知見が飛び交いました。 イベント構成 本イベントは3部構成で実施しました。 メインセッション : AWSによるセッションとカスタマー企業によるパネルディスカッション RoundTable Session (事前招待制) : 事前招待制のラウンドテーブルディスカッション ネットワーキング (事前招待制) : 参加者同士の交流 セッションで広い視点を得た後、ラウンドテーブルで具体的な議論を深め、懇親会でさらに交流するという流れが好評でした。 AWSセッション — プラットフォームエンジニアリングの実践 Speaker: Hayashi Masatoshi（アマゾン ウェブ サービス ジャパン合同会社 Container Specialist SA） オープニングセッションではアマゾン ウェブ サービス ジャパン合同会社の林より「AWSが考えるプラットフォームエンジニアリングの実践」を実施しました。クラウドにおけるプラットフォームエンジニアリングにおける様子と、AWSでの実装方法を解説しました。加えて、ECSおよびEKSに関連する最新アップデートを紹介しました。 パネルディスカッション Part 1: Amazon ECS 登壇企業: クックパッド株式会社様、レバレジーズ株式会社様、株式会社タイミー様 Facilitator: Hayashi Masayoshi（アマゾン ウェブ サービス ジャパン 合同会社 Specialist SA） ECSを活用する3社に、コンテナサービスの選択理由、開発者向けインターフェースの設計、チーム組織・文化の3つのテーマで議論いただきました。 コンテナサービスの選択理由 では、クックパッド様からECSからEKSに移行後、再度ECSに戻した経験が語られました。グローバルサービス統合の過程でEKSに移行したものの、運用負荷とチーム規模の変化を踏まえ、ECSのシンプルさを優先して再移行を決断したとのことです。 開発者向けインターフェースの設計 では、レバレジーズ様がTerraformリモートモジュールとコーディングエージェントスキルを組み合わせ、AWSの深い知識がなくても本番インフラを構築できる仕組みを整えた事例を紹介されました。 チーム組織・文化 では、3社ともEmbedded SRE（プロダクトチームにSREメンバーが常駐するモデル）を実践しており、SREチームが撤退した後にナレッジが失われる課題を共通して認識していました。ガードレールによる安全確保や、テンプレートの配布など、各社それぞれのアプローチで対策を講じています。 パネルディスカッション Part 2: Amazon EKS 登壇企業: 株式会社マネーフォワード様、ウォンテッドリー株式会社様、株式会社サイバーエージェント様 Facilitator: Goto Kenta（アマゾン ウェブ サービス ジャパン 合同会社 Solutions Architect） EKSを活用する3社に、EKSの選択理由と移行事例、プラットフォームの抽象化レベル設計、チーム組織とフィードバックサイクルについて議論いただきました。 EKSの選択理由と移行事例 では、ウォンテッドリー様が2016年からEKS登場以前よりKubernetesを本番運用してきた歴史を紹介しました。Herokuの開発者体験をAWS上で再現するために内製CLIツールを構築し、20回以上のクラスターアップグレードで蓄積された知見が大きな資産になっていると語りました。 プラットフォームの抽象化レベル設計 では、サイバーエージェント様がKubeVelaによる抽象化の取り組みを紹介しました。開発者がKubernetesを意識せずにアプリケーションをデプロイできる環境を実現した一方、プラットフォームが提供するテンプレートへの社内コントリビューションをどう促進するかが次の課題として挙げられました。 チーム組織とフィードバックサイクル では、マネーフォワード様がプラットフォームチームへのリクエスト集中という課題を共有。定型作業の自動化やAI活用の検討、SRE出身者が開発側の業務も担当する柔軟な体制づくりなど、実践的なアプローチが議論されました。 事前招待制 RoundTable Session メインセッション終了後、事前招待した企業によるクローズドなラウンドテーブルを実施しました。EKS/Platform EngineeringグループとECS/Containerグループの2つに分かれ、より踏み込んだ議論が行われました。 EKSグループ では、以下のトピックが議論されました： プラットフォーム提供における失敗と改善のアプローチ プラットフォームの抽象化レベルの設計 プラットフォーム運用におけるAIの活用戦略 マルチテナント環境でのセキュリティ分離 ECSグループ では、以下のトピックが議論されました： ECSにおけるジョブオーケストレーションの課題と各社の工夫 キュー設計と運用のベストプラクティス 組織拡大に伴うアーキテクチャの分離戦略 グローバル展開時のアーキテクチャ設計 フェーズやアーキテクチャの特性が近い企業同士で、具体的かつ実践的な議論が実現しました。 参加者の声 「業界のフロントランナーたちのECS, EKSの選択理由と開発者へ提供するインターフェースについて聞くことができ、非常に参考になりました。」 「現在進行系でPlatform化の議論が行われている状態でちゃんとした形としてプロダクトチームに提供できているわけではないので、ほかの事例ややり方などを聞くことができ助かりました」 「現在ECSを運用していて、規模が大きくなってきたのでそろそろプラットフォームがないと難しいのではないか？という課題感が出てきたので、今回のイベントに参加した。実際にプラットフォームを運用している人たちの、ベストプラクティス以外の生の話を聞くことができて、とても参考になった。次回もあれば参加したい」 「小さい範囲に閉じたミートアップだったことで、より濃い内容の話を聞けたのが良かったです。別のテーマでも実施いただけるとよいかなと思いました」 「セッション → ラウンドテーブル → 懇親会という会の構成が良くて、広い考え方から徐々に具体の話の議論ができて良かったです」 「ラウンドテーブルでは組織規模の近い企業と話すことで、課題感を共有しディスカッションすることができた。」 おわりに 第1回の開催を通じて、コンテナとプラットフォームエンジニアリングに取り組む企業同士が実践知を共有し合う場の価値を実感しました。今後も同様のイベントを企画していく予定です。事前招待制のクローズドセッションにご興味のある方は、ぜひAWSのアカウントチームにお問い合わせください。 著者情報 岸田 晃季（Kishida Kouki） スタートアップソリューションアーキテクト。スタートアップにて機械学習エンジニア、プロダクトマネージャーを経験後、より多くのスタートアップと関わりたいと思い現職にジョイン。スタートアップのために何ができるか日々模索中。

本ブログは、アスクル株式会社と Amazon Web Services Japan が共同で執筆しました。 はじめに アスクル株式会社 （以下、アスクル）は、「お客様のために進化する」という DNA のもと、事業所向け通信販売サービス「ASKUL」や個人向け通信販売サービス「LOHACO」を運営しています。取り扱い商品はオフィス用品、生活用品、家具、製造業・建設業向けの専門用品、衛生・介護・薬局用品等の一般医療用商品・医薬品・医療機器等の医療材料まで多岐にわたります。 1,500 万アイテム以上の商品をワンストップで購入できるサービスを提供しています。 アスクルは 2019 年頃から主要システムのクラウドネイティブ環境への移行を段階的に実施し、SAP ERP をはじめとする多数の基幹システムのマイグレーションに成功しました。こうしたモダナイゼーションの取り組みの延長として、運用やコストの最適化にも継続的に取り組んでおり、Amazon ElastiCache を Redis から Valkey にマイグレーションすることで約 20% のコスト削減を実現しました。 本記事では、アスクルが ElastiCache を Redis から Valkey にマイグレーションした際の移行戦略、当日の作業手順、およびコスト最適化の成果について紹介します。 システム構成 アスクルは 2019 年から基盤システムのモダナイゼーションの一環としてマイクロサービスアーキテクチャを積極的に採用しています。社内で「Trylion（トライオン）」と呼ばれるプロジェクトの一部として、膨大な商品情報を管理する商品プラットフォームもマイクロサービス化されており、特に商品 API や外部サービス（広告出稿など）への商品情報連携バッチなど、高速な処理が求められる機能に Amazon ElastiCache を採用しています。 アスクルの商品プラットフォームでは、Amazon ElastiCache を以下の 2 つの用途で活用しています。 商品 API（Amazon ECS）: お客様が askul.co.jp にアクセスした際、商品 API が Amazon Aurora（PostgreSQL）から取得した結果（商品名、価格など）を Amazon ElastiCache にキャッシュします。これにより、同一商品への繰り返しアクセスに対してデータベースへの問い合わせを削減し、高速なレスポンスを実現しています。 商品更新バッチ（Amazon EC2）: 商品情報の更新処理において、冪等性の担保や並列処理時の処理重複を避けるために処理済み ID を Amazon ElastiCache にキャッシュしています。これにより、大量の商品データを効率的に更新できる仕組みを構築しています。 Valkey へのマイグレーションを検討した背景 モダナイゼーションの中ではコスト最適化も重要な課題です。ElastiCache のコストをさらに最適化するため、アスクルは Valkey への移行を検討しました。 Valkey は 40 社以上の支持を受けて Linux Foundation が運営するオープンソースプロジェクトです。Amazon ElastiCache では 2024 年 10 月 8 日に Valkey のサポートを開始 しました。ElastiCache for Valkey はノードベースクラスターのコストが従来の ElastiCache for Redis OSS と比較して約 20% 低く、アスクルのコスト最適化の目標に合致していました。 加えて、Redis OSS の API およびデータフォーマットとの互換性があり、ダウンタイムゼロで移行できるオプションが提供されていることも魅力的で、前向きに検討してみる要因の一つになりました。これらの要素を総合的に評価し、アスクルは Valkey の採用を決定しました。特に、Redis OSS との API 互換性によりアプリケーションコードの改修が不要と見込まれた点は、移行の意思決定を後押しする大きな要因でした。 移行前の懸念事項と事前準備 Amazon ElastiCache では、既存の Redis クラスターをダウンタイムなしで Valkey へ移行するオプションが提供されており、その手軽さは魅力的でした。しかし、移行後に予期しない問題が発生した場合の切り戻しを考慮すると、インプレース移行だけでは不十分と判断しました。 そこでアスクルは、既存の Redis クラスターは維持したまま新規に Valkey クラスターを構築することで、問題が発生した場合でも Redis に即時切り戻せる体制を確保しました。ただし、新規 Valkey クラスターへの切り替えは API の参照先変更（= API リリース）を伴います。リリース直後はキャッシュが空の状態となるため、大量のキャッシュミスが発生するリスクがありました。これを軽減するため、商品 API の Amazon ECS サービスに対する AWS CodeDeploy のデプロイ設定を変更しました。 具体的には、 ECSAllAtOnce （トラフィックを一度にすべて切り替える設定）から ECSLinear10PercentEvery3Minutes （3 分ごとにトラフィックの 10% ずつを新クラスターへ切り替える設定）に変更し、トラフィックを段階的に新クラスターへ誘導する方式を採用しました。これにより、ウォームアップ時間を確保しつつキャッシュミスの影響を最小限に抑えることができました。 また、本番移行前に開発環境で一連の流れを検証し懸念事項の解消を確認しました。 切り戻しの準備は、移行当日までに本番用の新規 Valkey クラスターを事前構築しておく程度だったため、手間なく当日の作業を最小化することができました。 移行当日の作業手順 移行当日は、インフラチームと開発チームが連携し、以下の手順で作業を進めました。 ステップ 1（インフラチーム）: CodeDeploy デプロイ設定を ECSAllAtOnce から ECSLinear10PercentEvery3Minutes に変更しました。 ステップ 2（開発チーム）: API をリリースし、参照先を Redis から Valkey へ変更しました。Valkey は Redis OSS と API 互換性があるため、アプリケーションコードの変更は接続先の設定変更のみで済みました。 ステップ 2-1（開発チーム）: Blue/Green デプロイの Green タスクセット（移行先環境）を使用して動作確認を実施しました。本番（Redis）と移行先環境（Valkey）のレスポンス結果を突合するスクリプトを実行し、レスポンス結果に差分がないことを確認しました。 ステップ 3（インフラチーム）: 動作確認完了後、CodeDeploy 設定を元の ECSAllAtOnce に戻しました。 移行作業は約 40 分で完了し、移行前後を通じてシステム側での問題は発生しませんでした。 移行結果と今後の展開 移行検討から本番移行の完了まで約 3〜4 か月のスケジュールで、無事に移行を完了しました。移行後の商品 API のレスポンスタイムは Redis 利用時と同等で、性能劣化は確認されませんでした。 Redis と Valkey を並行稼働させていたため一時的にコストが増加しましたが、Redis クラスター削除後は想定どおり約 20% のコスト削減を達成しました。さらに、 リザーブドノード の購入を組み合わせることで、最終的に約 30% のコスト削減を実現しました。この成果を受けて、他プラットフォームでも同様の手順で Valkey への移行を進めています。また、今後新規に Amazon ElastiCache クラスターを構築する場合は Valkey を標準採用とする方針に変更しました。 まとめ アスクルは十分な事前準備により、約 40 分という短時間で安全に ElastiCache for Redis OSS から Valkey へのマイグレーションを完了し、最終的には約 30% のコスト削減を実現しました。ElastiCache for Valkey への移行を検討されている方は、 開始方法 もあわせてご参照ください。 著者について 荒木 泰詞 2023年にアスクル株式会社へ入社。Trylionのインフラをメインに、他のプロダクト も含めた設計・構築・運用保守を横断的に担当。JAWS-UGに参加し、AWSの学びを楽し みながらキャッチアップや情報発信活動を行っている 中野 暁人 2018年にアスクル株式会社へ入社。商品プラットフォームの立ち上げ初期より参画 し、設計・実装・運用まで一貫して担当。OSSの公開およびコントリビュートに積極的 に取り組んでいる。 藤田 将大 Database Specialist Solutions Architect として、担当テリトリーのお客様に対し、データベース全般の活用を技術支援してい ます。 朴 総明 Technical Account Manager。AWS データベース技術コミュニティメンバーとしてデータベースの課題解決＆技術支援を しています。

SAP を運用している経営層にとって、問いはすでに変わっています。クラウドに移行するかどうかではなく、どれだけ早くそこに到達できるか、そして到達した後に組織として何を構築できるかが問われています。課題は、SAP のトランスフォーメーションが企業が取り組む最も複雑なプログラムの一つであり、財務、サプライチェーン、製造、お客様対応業務に同時に影響を及ぼすことです。そして AI はすべての経営会議の最重要議題ですが、ほとんどの組織は SAP データがクラウドに移行されるまで、その潜在能力を最大限に引き出すことができません。クラウドに移行して初めて、実際に何かを構築できるようになるのです。 これこそが AWS が注力している機会です。現在、数千の組織が AWS 上で SAP を運用しており、その半数以上が SAP Cloud ERP を導入しています。AWS は ISG により SAP HANA Infrastructure Services のリーダーとして5年連続で認定 されており、現在 RISE with SAP ワークロードに対して AWS 上で 99.95% の SLA を提供しています。 SAPPHIRE 2026 において、AWS はクラウドへの移行をより迅速にし、AI を活用して SAP データからより簡単に価値を引き出し、お客様がすでにその組み合わせを実際のビジネス成果に変えている明確な事例を示す新機能を発表しました。 より迅速でシンプルなマイグレーション AWS と SAP は、クラウドマイグレーションをより迅速にするための協業を拡大しています。新しいオーケストレーション機能を RISE with SAP System Transition Workbench に直接統合することで、重要なマイグレーションステップを自動化します。これは、SAP のマイグレーションツールがデータ転送のためにクラウドプロバイダーのネイティブサービスを直接オーケストレーションする最初の事例の一つです。セキュアで標準化された転送アクセラレーションを活用することで、この共同作業は特定のファイルベースのマイグレーションシナリオに対して高性能な自動化オプションを提供し、RISE with SAP System Transition Workbench がサポートする既存の SAP マイグレーションアプローチのポートフォリオを補完します。 これらのプラットフォームレベルの進歩は、すでにパートナーによって増幅されています。例えば、 Accenture は Amazon Bedrock 上にエージェント駆動のデリバリープラットフォームを構築し、目的別に構築された AI エージェントをデリバリーワークフローに直接組み込んでいます。これにより、問題のトリアージ、インテグレーションマッピング、データマイグレーションの検証を自動化し、初期の結果ではより迅速な問題解決が示されています。 新しい SAP Seamless Private Connectivity オファリングは、Amazon VPC Lattice 上に構築された AWS Resource Gateway を使用し、ネットワーク層を完全に抽象化します。お客様は既存のインフラストラクチャを SAP RISE ランドスケープに数週間ではなく数日で接続できるようになりました。これにより、IP アドレスの競合が解消され、ネットワークの再設計や複雑な回避策が不要になり、お客様は自社のネットワーク設計に対する完全な制御を維持できます。このエンタープライズグレードのセキュアなプライベート接続モデルにより、SAP はお客様の環境をより迅速にプロビジョニングでき、オンボーディングと価値実現までの時間を大幅に短縮します。 開発者レベルでは、コードのモダナイゼーションが一般的な SAP マイグレーションにおける最大のタスクの一つであり、AI が最も即座にインパクトを与えている領域です。AWS と SAP は、Kiro を含む AWS AI コーディングアシスタントがオーケストレーション層として機能し、SAP ABAP Model Context Protocol（MCP）ツールとスキルを活用してドメイン固有のタスクを実行できるようにします。これにより、開発者は使い慣れたワークフロー内で AI を使用して、アプリケーションの構築とモダナイゼーションをより迅速に行えるようになります。 SAP と AWS はまた、追加の SAP Business Data Cloud、GROW、および SAP Business Technology Platform の機能をより多くの AWS リージョンで利用可能にすることも計画しています。これにより、規制産業やレイテンシーに敏感なオペレーションを持つお客様は、ビジネスが運営されている場所により近い環境で SAP を実行できるようになります。 AI で SAP データを活用する マイグレーションは出発点です。真の価値は、お客様が次に何を構築するかから生まれます。 AWS は、Amazon Bedrock、Amazon Quick、Amazon SageMaker、Kiro を含む 240 以上のクラウドおよび AI サービスを提供しており、SAP のお客様がエンタープライズデータからインサイトを引き出すことを可能にします。SAPPHIRE では、 SAP Business Data Cloud Connect for Amazon Athena を発表しました。これは、SAP Business Data Cloud と Amazon Athena 間の双方向ゼロコピー統合を提供する新しいオファリングです。ビジネス全体のチームが、レプリケーションの遅延や IT のボトルネックなしに、ライブの SAP データ上で分析レポート、ダッシュボード、AI エージェントを構築できるようになります。 イノベーションはお客様エンゲージメントにも及びます。SAP と AWS は、AWS の Amazon Connect ファミリーのエージェント型 AI ソリューションの一部である Amazon Connect Customer を、SAP Service Cloud および SAP Enterprise Service Management（ESM）と統合することも計画しています。これにより、組織はあらゆるチャネルで大規模にエージェント型のお客様体験を提供できるようになります。 また、 Amazon Bedrock AgentCore での MCP サポート により、お客様は SAP Integration Suite を通じて AI エージェントを SAP ERP システムに接続し、SAP ビジネスデータへのセキュアでプロトコル駆動のアクセスを実現できます。これにより、チームはエンタープライズグレードのセキュリティとオブザーバビリティを維持しながら、インサイトとアクションへのより迅速なアクセスが可能になります。 お客様はすでに成果を上げています 業界を問わず、組織は SAP データを AI と組み合わせて活用し、測定可能なビジネス成果を推進しています。例えば、 Hyundai は Amazon Quick を使用して、グローバルビジネス全体のオペレーション管理方法を再構築しています。 Mercedes-Benz は、SAP データから得られる AI 駆動のインサイトを通じて、製造オペレーションとお客様体験を変革しています。 これらの成果は、SAPPHIRE 2025 で発表された SAP and AWS AI Co-Innovation Program を通じて加速されています。このプログラムにより、企業は Accenture、Capgemini、Cognizant、Deloitte などのパートナーを通じて、コンセプトからエンタープライズ全体への展開まで、SAP と AWS の強みを活用できます。お客様が高価値のユースケースを特定し、コンセプトから本番環境への移行をより迅速に行えるよう支援します。 今後の展望 SAPPHIRE 2026 での発表は、シンプルなアイデアを反映しています。クラウドは目的地ではなく、基盤であるということです。ミッションクリティカルな SAP ワークロードが AWS に移行されると、お客様は運営方法を変革するために必要な AI サービス、パートナーネットワーク、インフラストラクチャにアクセスできるようになります。 詳細を確認する、または SAPPHIRE での AWS セッションを確認するには、 こちらをクリック してください。 本ブログはAmazon Bedrockによる翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

2013 年以来、 Amazon Redshift はオンプレミスの数分の 1 のコストでクラウドデータウェアハウスの力を最大限に発揮してきました。高密度コンピューティングから Amazon RA3 インスタンス 、Provisioned から Amazon Redshift Serverless へとアーキテクチャ世代が進むたびに、クエリが前世代よりも低コストかつ高速になり、効率性が向上しました。 10 年以上にわたるデータ量の増加と分析要件の進化により、組織では頻繁にアクセスされる構造化データのためのデータウェアハウステーブルと、さまざまなデータセットのコスト効率に優れたストレージのためのデータレイクの両方を活用することが増えています。人間の使用量をはるかに超える規模でデータウェアハウスをクエリする AI エージェントがこれに加わり、運用コストの高騰を招くことになっています。 その中核をなす強みをさらに倍増させた Amazon Redshift は、ワークロードを実行するのが人間か AI エージェントかにかかわらず、あらゆるワークロードの要求に対応します。例えば、2026 年 3 月、Amazon Redshift は 新規クエリを最大 7 倍高速化 することによって、ビジネスインテリジェンス (BI) ダッシュボードと ETL ワークロードのパフォーマンスを向上させました。これは、ほぼリアルタイムの分析アプリケーション、BI ダッシュボード、ETL パイプライン、自律的な目標指向型 AI エージェントで使用されるクエリなど、低レイテンシー SQL クエリの応答時間を大幅に改善しました。 2026 年 5 月 12 日、AWS は AWS Graviton を搭載した新しいインスタンスファミリー、 Amazon Redshift RG インスタンス を発表しました。より優れたパフォーマンスを実現する RG インスタンスでは、データウェアハウスワークロードの実行が RA3 インスタンスよりも最大 2.2 倍速くなり、vCPU あたりの料金も 30% 低くなります。統合されたデータレイククエリエンジンは、単一のエンジンからデータウェアハウスとデータレイクの両方を対象とした SQL 分析を実行できるようにし、そのパフォーマンスは Apache Iceberg 向け RA3 の 2.4 倍、 Apache Parquet 向け RA3 の1.5 倍高速になっています。&nbsp;こうした速度、コスト効率、統合されたデータレイククエリエンジンを組み合わせた Redshift RG インスタンスは、今日の分析ワークロードとエージェンティック AI ワークロードの要件である大量のクエリと低レイテンシーへの対応に最適です。 新しい RG インスタンスと現在の RA3 インスタンスは、以下のように比較できます。 現在の RA3 インスタンス 推奨される RG インスタンス vCPU メモリ (GB) 主要ユースケース ra3.xlplus rg.xlarge 4 32 小規模クラスター部門別分析 ra3.4xlarge rg.4xlarge 12 → 16 (1. 33:1) 96 GB → 128 GB (1.33:1) 標準的な本番ワークロード、中規模のデータ量 このアプローチは、データウェアハウスワークロードとデータレイクワークロードの組み合わせを実行しているお客様の総分析コストを削減しながら、ウェアハウステーブルと Amazon Simple Storage Service (Amazon S3) データレイクの両方をクエリする単一のシステムによって運用を簡素化します。節約額の見積もりには、 AWS 料金見積りツール で特定のワークロードパターンを使用することをお勧めします。 Amazon Redshift RG インスタンスの使用を開始する 新しいクラスターの起動と既存クラスターの移行には、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS API を使用できます。統合されたデータレイククエリエンジンはデフォルトで有効になっています。 Amazon Redshift コンソールでは、クラスターの作成時に新しい RG インスタンスを選択できます。 クラスター構成に基づいた最適なパスを使用して前世代のインスタンスを RG インスタンスに移行し、コストの見積もり、互換性の検証、実行の自動化を行うことができます。 伸縮自在なサイズ変更 – 10～15 分のダウンタイムを伴う、互換構成のためのインプレース移行 スナップショットとリストア – RA3 スナップショットから RG クラスターを作成。移行中に構成を変更したいお客様に最適です 外部テーブル、スキーマ、クエリ構文 (既存の Spectrum クエリを含む) は変更されません。外部テーブルを再度作成したり、アプリケーションコードを変更したりする必要もありません。&nbsp;詳細については、「 Redshift Management Guide 」をご覧ください。 Amazon Redshift は、クラスターノード (データウェアハウスワークロードを処理するものと同じコンピューティング) でデータレイククエリ実行するようになったため、 Amazon Redshift Spectrum を使用する必要がなくなりました。データレイククエリは VPC 境界内にとどまり、既存の IAM ロールを使用して、テラバイト単位のスキャン料金を発生させません。このため、これまで Redshift の合計コストに加算されていた 5 USD/TB の Spectrum スキャン料金がかからなくなります。 今すぐご利用いただけます Amazon Redshift RG インスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、台湾、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ミラノ、ロンドン、パリ、スペイン、ストックホルム)、中東 (UAE)、南米 (サンパウロ) の各 AWS リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」をご覧ください。&nbsp;Redshift Provisioned では、コミットメント不要で料金が時間単位で請求されるオンデマンドインスタンス、またはコスト節約のためのリザーブドインスタンスを選択できます。&nbsp;詳細については、 Amazon Redshift の料金ページ をご覧ください。 Redshift コンソール で RG インスタンスをぜひお試しください。フィードバックは AWS re:Post for Amazon Redshift 、または通常の AWS サポート担当者を通じてお寄せください。 – Channy 原文は こちら です。

少子高齢化、人口減少、労働力不足、地方における過疎化と地域経済の空洞化、医療・介護リソースの構造的逼迫、そして、激甚化する自然災害への防災・減災対応など、日本が直面する社会課題は、年々複雑化し、深刻さを増しています。こうした社会課題の本質に目を向けるとその多くは、行政機関や大企業の力だけで解決の道筋を描くことには限界があります。日本の全企業数のおよそ&nbsp;99%&nbsp;を占め、地域社会の経済基盤を支える中堅・中小企業が、それぞれの地域に根ざした形で課題に対し持続可能な解決を実現する重要な役割を担っていると考えます。 そして今、生成AIをはじめとするAI技術は、現代社会が抱える複雑かつ多層化する課題を解きほぐすための強力な推進力として、今後さらに重要な役割を果たしていくことが期待されています。2023年以降、AIは急速に普及し、技術検証から業務活用、ビジネス価値の創出へとフェーズを進めてきました。2026年は、AIエージェントの活用へという新たな段階へと移行しています。この潮流は、専門的なAIエンジニアを擁しない中堅・中小企業においても進んでおり、AIエージェントを活用することで、現場の課題に即したAIソリューションを迅速に構築・展開する取り組みが加速しています。 本ブログでは、社会課題をAIで解決する取り組みに焦点を当て、中堅・中小企業のお客様が、AWSの生成AIサービス&nbsp; Amazon Bedrock や　AIエージェントサービス　 Amazon Bedrock AgentCore などを活用し、日本の社会課題に真正面から向き合い、解決策を生み出している先進事例を４つご紹介いたします。 株式会社アクトノード 「Amazon Bedrock Agent Coreで実現する『見守りエージェントAI』　一次産業の人手不足と熟練知識の属人化を解決し、見守り頻度を最大48倍に拡大、生産者の工数を50%削減」　 AWSブログ（5/12公開） 深刻な人手不足と熟練知識の属人化などの課題を抱える一次産業の生産者や流通事業者向けに、IoT や AI などの技術を使ったサービスを提供するアクトノードは、農業・畜産・水産養殖向け記録アプリ「ACT.app」をAWS上で開発、2020年より提供しています。農業・畜産・水産養殖の現場では、環境や生育状態の継続的な監視と異常時の早期対応が求められますが、これらの作業は熟練者による現地見回りに依存していることが多く、1&nbsp;日&nbsp;数回の見回りが限界で、夜間に異変が起きてしまうと翌朝まで気づくことが難しく、また、既存の定点カメラは単純な記録に留まるため、異常検知は人間が映像を目視して判断する必要があるなど、様々な問題を抱えていました。 こうした状況に対してアクトノードは、生産者が自然言語で養鶏の様子を相談すると、AIが見守り要件を理解し、カメラ画像を自律分析するアプリ　「見守りエージェントAI」を、Amazon&nbsp;Bedrock、Amazon&nbsp;Bedrock Agent&nbsp;Core、Amazon&nbsp;Nova&nbsp;を活用して開発。「見守りエージェントAI」の導入により、 見守り頻度を最大48倍に拡大 、 生産者の工数を50%削減 したことに加え、24時間365日の監視を実現。さらに参考画像を数枚と説明文を組み合わせる&nbsp;Few-shot examples手法を採用することで、少数の参考画像で多様な見守りニーズに対応することが可能となりました。養鶏場での実証実験では実用レベルの精度を確認し、暗黙知の言語化・共有による技術継承の加速も期待されています。本取り組みは経済産業省の&nbsp;NEDO懸賞金活用型プログラム&nbsp;GENIAC-PRIZEにエントリーされ、農林水産省のスマート農業実証プロジェクトにも認定されています。 ヤマトプロテック株式会社 「ヤマトプロテック　AIを利用した書類電子保管システムをわずか2日で構築」　 AWSブログ（5/11公開） 創業から107年、消火・防災領域におけるメーカーとして、開発・製造・設計・施工・メンテナンスを網羅し「火にまつわる安心」を作り出してきたヤマトプロテック株式会社。安心を届け続けるための重要な課題の一つとして、DXの取り組みを進めるなか、受発注に関連する部署において、書類の電子保管担当者が突然欠員。他の担当者が急きょカバーせざるを得ない状況となり、部署全体の負荷増大と業務時間の延長という事態に陥りました。こうした状況を改善するため、経営企画本部 情報システム室は、 Amazon&nbsp;Bedrock&nbsp;と&nbsp;Kiro&nbsp;を活用して、わずか2日という短期間でマルチモーダルAIによる書類電子保管システムを構築 しました。加えて、Amazon Nova LiteのAI-OCRにより 日本語書類の認識率が89%に向上 し、書類の読み取りから登録までの完全自動化を実現。 手作業による入力作業の85%以上を削減 し、急な欠員による業務逼迫という課題を解消しました。情報システム部門も限られたリソースでありながら、適切な生成AI開発ツールの選択により、短期間での課題解決が可能であることを示した事例となります。 大豊建設株式会社 「大豊建設が AWS で実現した大豊 AI：業務の様々な場面で活躍する生成 AI 活用事例」～「規程、どこだっけ？」を250時間分削減、307名が月3万回以上使う社内AIの全貌　 AWSブログ（4/8公開） 土木・建築工事を中心とする総合建設会社の大豊建設は、社内情報へのアクセスの煩雑さや文書作成の負担、中堅社員不足による知識継承の課題に対し、Amazon Bedrockを活用した社内生成AIツール「大豊AI」を構築。社内規程の検索、議事録の自動生成、資料の要約、日常的な疑問への回答など幅広い業務で活用され、 全社展開から約8ヶ月で307名の社員が利用し、累計32,709回以上の利用を記録。規程検索だけで約250時間の業務時間削減を達成 しました。今後は、Amazon Bedrock&nbsp;AgentCoreを活用した施工計画書の作成支援や社内資料作成の自動化にも取り組み、過去データの検索から計画書の素案作成までをAIエージェントが自律的に処理することで、現場担当者の工程の効率化を目指します。 メック株式会社 「Amazon Bedrock AgentCore で研究業務を効率化 – AI エージェントによる情報検索と更新の自動化」　 AWSブログ（2/19公開） ～新人でもベテラン並みに探せる 、化学メーカーが3週間で構築した「研究知識を腐らせない」AIエージェント～ 電子基板・部品製造用薬品の開発、製造販売および、機械装置、各種資材の販売を行うメック株式会社は、研究開発部門に蓄積された専門知識や技術情報を組織全体の資産として最大限に活用し、全メンバーが高いレベルで業務を遂行できる環境の構築を目指し取り組みを進めています。AWSハッカソンへの参加をきっかけに同社は、 わずか約3週間という短期間で、Amazon Bedrock&nbsp;AgentCoreを活用し、情報検索エージェントの開発を行いました。ユーザーの意図を理解して最適な検索クエリを自動生成し、経験年数に関わらず、高品質な情報収集が可能 となることに加え、 情報更新エージェントが新規情報にコンテキストやメタデータを自動付与し、知的資産を体系的に蓄積 。Strands Agentsや Amazon S3 Vectors も活用した先進的なアーキテクチャにより、研究業務レベルの底上げと組織全体の生産性向上が期待されてます。 今回ご紹介したお客様のお取り組み以外にも、数多くのお客様がAIを活用した課題解決への取り組みを加速しています。AWSジャパン広域事業統括本部は、クラウドおよび生成AIを最大限に活用したデジタルトランスフォーメーション（DX）の推進を通じて、自社のビジネス変革のみならず、社会課題の解決にまで取り組む中堅・中小企業のお客様への伴走支援を一層強化してまいります。 アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 広域事業統括本部 統括本部長　原田 洋次

本記事は 2026 年 5 月 7 日 に公開された「 Migrating data from an Amazon Aurora snapshot into Amazon Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は、高可用性、無制限のスケール、マルチリージョンの強整合性、そしてインフラ管理不要を実現したサーバーレス分散 SQL データベースです。Aurora DSQL はデータベースへのデータ移行に PostgreSQL の COPY コマンドをサポートしており、Aurora DSQL 向けに COPY コマンドを利用しやすくした dataloader スクリプトも提供しています。ただしこの方式は、テーブルを 1 つずつ移行する必要があるうえ、ソースデータベースから移行先 Aurora DSQL クラスターへデータをコピーする中継用コンピュートインスタンスを別途用意しなければならず、ソースとターゲット間でデータを変換する手段も用意されていません。大規模なデータ移行や、データ型変換、スキーマ変更、その他の変換が必要な移行には、マネージドな移行手法のほうが適しています。本記事では AWS Glue を使って Amazon Aurora のスナップショットから Aurora DSQL クラスターへデータを移行する方法を紹介します。 ソリューション概要 AWS Glue は、Extract, Transform, Load (ETL) 処理を行う Apache Spark ジョブ向けにマネージドな並列実行環境を提供するデータ統合サービスです。AWS Glue では、移行に必要なデータ変換を PySpark スクリプトとして記述でき、移行に利用するコンピュートノードの数とキャパシティを指定して実行できます。AWS Glue が背後のコンピュートインフラを管理し、コンピュートノード間で処理の分散と並列実行をオーケストレーションします。 本記事では、Amazon Aurora PostgreSQL-Compatible Edition から Aurora DSQL へ、データベーススナップショットと AWS Glue を使って 2 つのテーブルを持つデータベースを移行する例で、この移行手法を紹介します。今回の移行のワークフローは次の図のとおりです。 移行ワークフローは次のとおりです。 Aurora PostgreSQL クラスターのスナップショットを作成します。 Aurora スナップショットの S3 へのエクスポート機能 を使い、スナップショットから Amazon Simple Storage Service (Amazon S3) バケットへ Parquet 形式でデータを抽出します。 AWS Glue クローラーを作成・実行して S3 上の Parquet ファイルを発見し、スキーマを判定し、スキーマとファイルの場所を AWS Glue Data Catalog に記録します。ソースデータベースのテーブルごとに 1 つのクローラーを作成します。 Data Catalog を参照して S3 からファイルを見つけて読み込み、必要なデータ変換を行ったうえで Aurora DSQL に書き込む PySpark ETL ジョブを AWS Glue で作成します。 ETL ジョブを実行し、ワンタイムのデータロードを行います。 Aurora DSQL は 1 クラスターあたり 1 データベースのみをサポートしますが、Aurora クラスターは複数のデータベースをホストできます。複数のデータベースをホストする Aurora クラスターを移行するには、Aurora スナップショットに含まれるデータベースごとにこの移行プロセスを繰り返し、データベースをそれぞれ独立した Aurora DSQL クラスターにデプロイするか、Aurora DSQL の 1 つのデータベース内に複数のスキーマとして移行する必要があります。 データ型変換 Aurora スナップショットの S3 エクスポート処理では、Aurora DSQL への最終的な書き込みに影響するデータ変換が行われます。一部の変換は修正や再変換が必要になる場合があり、その作業は AWS Glue ETL ジョブ内の PySpark で行えます。たとえば、ソースデータベースの timestamp 型カラムは、スナップショットエクスポート時に Parquet のバイト配列に変換され 、PySpark で読み込んだ際には文字列オブジェクトとして解釈されます。Aurora DSQL に書き込む前に、この文字列を timestamp 型へ戻す必要があります。スナップショットエクスポート処理が PostgreSQL のデータ型を Parquet にどう変換するかは、 エクスポート関連のドキュメント を参照してください。 Aurora DSQL はオープンソースの PostgreSQL で利用できる全データ型をサポートしているわけではありません。Aurora DSQL がサポートするデータ型の一覧は Aurora DSQL ユーザーガイド を参照してください。ソースデータベースのテーブルで Aurora DSQL がサポートしないデータ型を使っているカラムを特定し、Aurora DSQL ではどう表現するかを決め、AWS Glue PySpark ジョブで変換を行う必要があります。該当するカラムはスナップショットエクスポート時にも変換される場合があるため、PySpark スクリプトでその点も考慮しなければなりません。 主キーの扱い 多くのアプリケーションは主キーに連番の整数を使います。新しいデータに一意の識別子を自動付与でき、ほとんどのリレーショナルデータベースでは新しい行がストレージ上で近い位置に配置されるため、最近追加された行が他の新しい近接行の読み取りでバッファキャッシュに乗りやすくなります。アプリケーションでは古いデータより新しいデータのほうが頻繁に読まれる傾向があり、ストレージからの読み取りよりキャッシュからの読み取りのほうがはるかに高速なため、連番識別子は多くのアプリケーションで読み取り性能の向上につながります。 ただし Aurora DSQL はバッファキャッシュを提供しておらず、大規模に連番整数キーを使うとホットなストレージパーティションが発生する可能性があります。Aurora DSQL のレンジパーティショニングでは新しいデータがすべて同じストレージパーティションに配置されるためです。代わりに、レンジパーティション化されたストレージで分散が良くなる主キーを選びましょう。テーブル内に既に存在するカラムの中から、カーディナリティの高いカラムに他の 1 つ以上のカラムを続けた複合キーを選ぶことを推奨します。この種のキーはデータへのアクセス方法と一致しやすく、追加のセカンダリインデックスを必要としません。また、テーブル定義のみを変更しテーブル内のデータは変えないため、移行時に追加のデータ変換も必要ありません。 ただし、これが常に可能とは限りません。場合によっては、UUID (Universally Unique Identifier) かランダム化された識別子で旧主キーを置き換える新しい主キーカラムを作成する必要があります。移行時に主キーを変換するのは難しく、外部キー関係も修正しなければなりません。移行検証のためにソースデータベースとターゲットデータベース間で行をマップできるよう、元の識別子を別カラムに残しておきたい場合もあります。データベースを利用するすべてのアプリケーションも新しい識別子を使うように更新する必要があります。 本記事の例では主キーを UUID に変換し、外部キー関係を修正することで、AWS Glue と PySpark を使った主キー変換の進め方を示します。元の主キーは別カラムに残し、ソースデータベースへマップし直せるようにします。 移行手順 本セクションでは、架空の小売アプリケーション向けデータベースを Aurora PostgreSQL から Aurora DSQL へ移行する手順を順を追って説明します。本記事では、例を交えて移行プロセスを示し、実際の移行に応用していただくことを目的としています。 Aurora PostgreSQL のソースデータベース名は「storefront」です。storefront には次のテーブルを持つ sales スキーマが含まれています。 CREATE SCHEMA sales; CREATE TABLE sales.customers ( id integer NOT NULL, username character varying(50), first_name character varying(50), last_name character varying(50) ); CREATE TABLE sales.orders ( id integer NOT NULL, customer_id integer, order_date date, order_timestamp timestamp without time zone, product_details jsonb, quantity integer, unit_cost numeric(6,2), unit_weight real ); これらのテーブルは実際の小売データベースとしては必ずしも適切ではありませんが、Aurora DSQL でどう変換されるかを示すためにさまざまなデータ型のカラムを持たせています。 sales.orders テーブルの customer_id カラムは sales.customers テーブルの id カラムを参照しています。簡潔にするためインデックスや制約は省略しています。 前提条件 この例の移行は本番環境で実施しないでください。実行には、AWS アカウントと、移行に必要なリソース (AWS Identity and Access Management (IAM) のロールやアクセス許可を含む) を作成できる十分な権限が必要です。例のソリューションを自分の移行に応用する場合は、本番データを移行する前に必ず非本番アカウントで作業し、十分にテストしてください。 また、ワークステーションのローカルか、AWS 環境で動作するコンピュートインスタンス上で動作する Unix bash シェルセッションへのアクセスも必要です。ワークステーションは AWS アカウントおよびソース／ターゲットデータベースへのネットワークアクセスを持ち、最近のバージョンの AWS Command Line Interface (AWS CLI) がインストールされている必要があります。AWS CLI は前述の IAM ロールで 設定されている必要があります 。 AWS 環境でのデータベース操作、Unix シェル、AWS マネジメントコンソールや AWS CloudFormation などの AWS サービスについて中級程度の経験があることを前提としています。そのため、ソースデータベースの構築、データベースへの接続、コマンドを実行するワークステーションのセットアップについての具体的な手順は示しません。 本移行には Amazon S3 バケット、AWS Glue クローラー、AWS Glue ジョブ、 AWS Key Management Service (AWS KMS) キー、エンドツーエンドのワークフローを実現するためのアクセス許可を付与する複数の IAM ポリシーとロールが必要です。利便性のため、これらのコンポーネントは AWS CloudFormation テンプレートでデプロイし、移行に使う PySpark コードもあわせてデプロイします。CloudFormation テンプレートと関連ファイルは GitHub リポジトリで公開しており、ワークステーションにダウンロードしてください。次のコマンドでプロジェクトファイルをダウンロードします。 git clone git@github.com:aws-samples/sample-migrate-to-dsql.git リポジトリには amazon-aurora-snapshots-to-dsql というサブディレクトリがあり、以下のファイルが含まれています。本記事ではこのディレクトリを「プロジェクトディレクトリ」と呼びます。 プロジェクトに含まれるファイルは次のとおりです。 stack.yml 後続のセクションで参照する S3 バケット、AWS KMS キー、AWS Glue クローラー、AWS Glue ジョブ、関連する IAM ポリシーおよびロールを作成します。 ddl-dsql.sql ターゲットの Aurora DSQL クラスターに必要なスキーマ、テーブル、インデックスを作成する SQL コマンドが含まれています。 storefront.sql.zip ソースデータベースのスキーマとテーブルを作成し、サンプルデータをテーブルに投入する SQL コマンドが含まれています。 AWS アカウント内の Amazon Virtual Private Cloud (Amazon VPC) のプライベートサブネットに、 新しい Aurora PostgreSQL クラスターを作成します 。本例では PostgreSQL 17.7 を使用しています。クラスター名は「prod-cluster」とし、 初期データベース名 には「storefront」を指定します。クラスター作成時に初期データベース名を設定し忘れた場合は、クラスターにログインし、次の SQL 文でデータベースを作成します。 CREATE DATABASE storefront; プロジェクトディレクトリの bash シェルで次のコマンドを実行し、データベーススキーマを作成してサンプルデータをロードします。 unzip storefront.sql.zip psql -h &lt;&lt;your cluster's hostname&gt;&gt; -U postgres -f storefront.sql -d storefront データベースクラスターの「postgres」ユーザーのパスワード入力を求められます。データのロード後、storefront データベースにログインし、次の SQL コマンドでサンプルデータを確認します。 select * from sales.customers limit 20; select * from sales.orders limit 20; これでソースデータベースの準備ができました。Aurora DSQL へのデータ移行に進みます。 移行の実行 まず Aurora DSQL クラスターを作成します。Unix 系のコマンドラインで次のコマンドを実行し、「storefront」という名前の単一リージョン Aurora DSQL クラスターを作成し、エンドポイントと Amazon Resource Name (ARN) を新しい環境変数に保存します。クラスター作成は数秒で完了します。 export DSQL_CLUSTER_ID=($(aws dsql create-cluster --no-deletion-protection-enabled --tags Name=storefront --output text --query 'identifier')) export DSQL_ENDPOINT=$(aws dsql get-cluster --identifier $DSQL_CLUSTER_ID --output text --query 'endpoint') export DSQL_CLUSTER_ARN=$(aws dsql get-cluster --identifier $DSQL_CLUSTER_ID --output text --query 'arn') クラスターのステータスは次のコマンドで確認します。 aws dsql get-cluster --identifier $DSQL_CLUSTER_ID \ --output text --query 'status' ステータスが「ACTIVE」になるまで何度か実行します。Aurora DSQL クラスターがアクティブになったら、 クラスターに接続 し、GitHub プロジェクトの ddl-dsql.sql ファイルにあるコマンドを実行してスキーマとテーブルを作成します。 次に、先ほどの GitHub プロジェクトの stack.yml テンプレートファイルを使い、「apg-to-dsql」という名前の AWS CloudFormation スタックを作成します。スタック名は後で参照するため重要です。スタックには次のパラメータが必要です。 DSQLClusterEndpoint 作成した Aurora DSQL クラスターのエンドポイント。AWS マネジメントコンソールのクラスター詳細ページで確認できます。 DSQLClusterArn 作成した Aurora DSQL クラスターの ARN。AWS マネジメントコンソールのクラスター詳細ページで確認できます。 LoaderJobCapacity DSQL ローダージョブに割り当て可能な AWS Glue data processing unit (DPU) の最大キャパシティで、2〜100 の範囲で指定します。DPU は処理能力の相対的な指標で、4 vCPU と 16 GB メモリで構成されます。移行のサイズと複雑さに応じて DPU 数を選びます。 ExportJobName スナップショットエクスポートジョブの名前。アカウント内で一意である必要があります。 SourceDatabaseName Aurora PostgreSQL のソースデータベース名。 SourceSchemaName ソースデータベースから移行するスキーマ名。 サンプル移行のデフォルト値でスタックを作成するには、プロジェクトディレクトリで次のコマンドを実行します。 aws cloudformation create-stack --stack-name apg-to-dsql \ --template-body file://stack.yml --capabilities CAPABILITY_NAMED_IAM \ --parameters ParameterKey=DSQLClusterEndpoint,ParameterValue=$DSQL_ENDPOINT ParameterKey=DSQLClusterArn,ParameterValue=$DSQL_CLUSTER_ARN aws cloudformation wait stack-create-complete --stack-name apg-to-dsql スタックの完了を待ちます。後続の手順で必要となる出力値が複数あります。 KmsKeyArn エクスポートしたスナップショットデータを暗号化するために作成された AWS KMS キーの ARN。 SnapshotExportRoleArn スナップショットエクスポート処理が S3 にデータを保存するために必要な IAM ロールの ARN。 GlueRoleName AWS Glue ジョブが必要なアクセスを得るための IAM ロール名。 GlueRoleArn AWS Glue ジョブが必要なアクセスを得るための IAM ロールの ARN。 GlueJobName AWS Glue ジョブの名前。 後続のコマンドで使いやすいように、スタックパラメータと出力値を環境変数に取り込みます。スタック名を「apg-to-dsql」以外にした場合は、コマンドを設定したスタック名に合わせて修正してください。 export EXPORT_JOB_NAME=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Parameters[?ParameterKey==`ExportJobName`].ParameterValue' --output text) export BUCKET_NAME=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Outputs[?OutputKey==`BucketName`].OutputValue' --output text) export DATABASE_NAME=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Parameters[?ParameterKey==`SourceDatabaseName`].ParameterValue' --output text) export EXPORT_ROLE_ARN=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Outputs[?OutputKey==`SnapshotExportRoleArn`].OutputValue' --output text) export KMS_KEY_ARN=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Outputs[?OutputKey==` KmsKeyArn`].OutputValue' --output text) export GLUE_JOB_NAME=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Outputs[?OutputKey==`GlueJobName`].OutputValue' --output text) 次のコマンドでデータベーススナップショットを作成します。スナップショット名は「migrate-to-dsql」、ソースデータベースクラスター名は前述の「prod-cluster」です。スナップショットの ARN は後で使うため SNAPSHOT_ARN という環境変数に取り込みます。 export SNAPSHOT_ARN=$(aws rds create-db-cluster-snapshot --db-cluster-snapshot-identifier migrate-to-dsql --db-cluster-identifier prod-cluster --output text --query 'DBClusterSnapshot.DBClusterSnapshotArn') スナップショットのステータスは次のコマンドで確認します。 aws rds describe-db-cluster-snapshots \ --db-cluster-snapshot-identifier migrate-to-dsql --output text \ --query 'DBClusterSnapshots[*].Status' ステータスが「available」になるまで何度か実行し、その後で次のコマンドでスナップショットをエクスポートします。 aws rds start-export-task --export-task-identifier "$EXPORT_JOB_NAME" \ --source-arn $SNAPSHOT_ARN --s3-bucket-name "$BUCKET_NAME" \ --iam-role-arn "$EXPORT_ROLE_ARN" --kms-key-id "$KMS_KEY_ARN" エクスポートジョブのステータスが「COMPLETE」になるまで、次のコマンドを定期的に実行して状態を確認します。 aws rds describe-export-tasks --export-task-identifier "$EXPORT_JOB_NAME" --query 'ExportTasks[0].Status' --output text ここまでで、移行に必要なインフラの構築、ソースデータベースのスナップショット作成、Parquet ファイルとしての S3 バケットへのスナップショットエクスポートが完了しました。次に AWS Glue クローラーを実行してエクスポート済みデータをカタログ化し、PySpark ジョブを実行して Aurora DSQL にデータをロードします。 ソースデータベースからエクスポートした両方のテーブルに対して、次のコマンドで AWS Glue クローラーを実行します。クローラーは CloudFormation テンプレートで作成済みです。 aws glue start-crawler --name customers aws glue start-crawler --name orders クローラージョブの状態は次のコマンドで取得できます。クロール対象データの量によっては完了まで数分かかることがあります。両方のジョブが「COMPLETED」になるまで 1 分ごとに実行してください。 aws glue list-crawls --crawler-name customers \ --output text --query 'Crawls[0].State' aws glue list-crawls --crawler-name orders --output text --query 'Crawls[0].State' 両方のクローラージョブが完了したら、次のコマンドでクローラーがエクスポート済みスナップショットデータからカタログ化したテーブルとカラムを確認します。AWS Glue ローダージョブはこのカタログを使って S3 バケット内のエクスポート済みスナップショットデータを見つけます。 aws glue get-tables --database-name "$DATABASE_NAME" \ --query 'TableList[*].[Name,StorageDescriptor.Columns[*]]' 出力は次のようになります。 [ [ "sales_customers", [ { "Name": "id", "Type": "int" }, { "Name": "username", "Type": "string" }, { "Name": "first_name", "Type": "string" }, { "Name": "last_name", "Type": "string" } ] ], [ "sales_orders", [ { "Name": "id", "Type": "int" }, { "Name": "customer_id", "Type": "int" }, { "Name": "order_date", "Type": "string" }, { "Name": "order_timestamp", "Type": "string" }, { "Name": "product_details", "Type": "string" }, { "Name": "quantity", "Type": "int" }, { "Name": "unit_cost", "Type": "string" }, { "Name": "unit_weight", "Type": "float" } ] ] ] 次のコマンドで AWS Glue ジョブを実行します。 export JOB_RUN_ID=($(aws glue start-job-run --job-name "$GLUE_JOB_NAME" --output text --query 'JobRunId')) ジョブのステータスは次のコマンドで取得します。完了するまで定期的に実行してください。 aws glue get-job-run --job-name "$GLUE_JOB_NAME" --run-id $JOB_RUN_ID --output text --query 'JobRun.JobRunState' ジョブが完了すれば、データ移行は完了です。 検証 行数のカウントと数値カラムの合計を取り、移行が正しく完了したか検証します。 まずソースの Aurora PostgreSQL データベースとターゲットの Aurora DSQL クラスターの両方で次のクエリを実行します。 select count(*) from sales.customers; 両方の件数が一致するはずです。次のクエリもソースとターゲットの両方で実行し、件数と合計値がすべて一致することを確認します。 select count(*), sum(quantity), sum(unit_cost) from sales.orders; この単純な検証方法は本番環境の移行には十分ではありません。実際には、移行中に行った変換処理を考慮しつつ、すべてのカラム値を行ごとに比較する必要があります。 AWS Glue ジョブを理解する 本移行手法には多くの構成要素がありますが、唯一複雑なのはスクリプトを自分で書く必要のある AWS Glue ジョブです。本記事の AWS Glue ジョブはシンプルで、いくつかのデータ型変換と整数識別子から UUID への変更しか行っていませんが、より複雑な移行を構築する際の基本要素を示しています。本サンプル移行の AWS Glue ジョブのコードは CloudFormation スタックでデプロイ済みです。閲覧するには AWS Glue コンソールで ETL jobs を選択し、 storefront-snapshot-dsql-loader ジョブを選びます。スクリプトエディタにスクリプトが読み込まれます。コードを順に確認していきましょう。 ファイル冒頭はセットアップコードで、ライブラリのインポート、API コンポーネントの初期化、CloudFormation テンプレートで設定したジョブ設定パラメータの取得を行います。該当部分は次のとおりです。 import boto3 import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.dynamicframe import DynamicFrame from pyspark.sql import SparkSession from pyspark.sql import functions as func from pyspark.sql.functions import to_timestamp, to_date, col from awsglue.job import Job # Read job configuration parameters args = getResolvedOptions(sys.argv, ['JOB_NAME', 'dsql_endpoint', 'glue_database', 'schema']) # Job initializations dsql = boto3.client('dsql') sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) 続く数行のコードでは、AWS Glue カタログを使って S3 上のファイルを見つけ構造を解釈しつつ、customers と orders のデータを読み込みます。 # Read the exported snapshot tables from S3 customers_df = glueContext.create_dynamic_frame_from_catalog(database=args['glue_database'], table_name=args['schema'] + '_customers').toDF() orders_df = glueContext.create_dynamic_frame_from_catalog(database=args['glue_database'], table_name=args['schema'] + '_orders').toDF() 次にデータにいくつかの変換を適用します。データ型をいくつか変換し、テーブルの主キーを UUID に変換しつつ、元の ID は別カラム名で残します。まず customers テーブルから始めます。 # Perform transformations for the customers table customers_df.createOrReplaceTempView('customers') customers_adjusted = spark.sql('SELECT uuid() AS id, customers.id AS old_id, username, first_name, last_name FROM customers') customers_adjusted.createOrReplaceTempView('customers') ここでは id カラムを「old_id」にリネームします。続いて新しい「id 」 カラムを作成し、各行に新たに生成した UUID 値を設定します。これらの変換と後続ステップで残すカラムの選択は、使い慣れた SQL で行えます。 orders テーブルでも同様の処理を行いますが、加えて customer_id カラムを「old_customer_id」にリネームします。「old_customer_id」カラムは一時的なもので、後ほど UUID 主キーへの切り替えに伴う外部キー関係の修正で使います。 # Perform transformations for the orders table orders_df.createOrReplaceTempView('orders') orders_adjusted = spark.sql('SELECT uuid() AS id, orders.id AS old_id, customer_id as old_customer_id, order_date, order_timestamp, product_details, quantity, unit_cost, unit_weight FROM orders') 次に「order_timestamp」カラムと「order_date」カラムを修正し、Parquet 変換で文字列になっていた値を本来の timestamp 型と date 型に戻します。 to_timestamp() と to_date() を使っている点に注目してください。 orders_adjusted = orders_adjusted.withColumn('order_timestamp', to_timestamp(col('order_timestamp'))) orders_adjusted = orders_adjusted.withColumn('order_date', to_date(col('order_date'))) 続いて orders と customers の外部キー関係を新しい UUID 主キーを使うように修正し、Aurora DSQL のデータベースには残したくない「old_customer_id」カラムを削除します。Aurora DSQL は現状で外部キー制約を強制しませんが結合はサポートしているため、効率的な結合のために関係を修正することは重要です。 # Fix foreign key relationship between orders and customers orders_adjusted.createOrReplaceTempView('orders') orders_final = spark.sql('select o.id, c.id as customer_id, o.order_date, o.order_timestamp, o.product_details, o.quantity, o.unit_cost, o.unit_weight from orders o inner join customers c on o.old_customer_id = c.old_id') customers_adjusted = customers_adjusted.drop('old_id') データ変換の作業はこれで完了です。移行のアーキテクチャを示すために基本的な変換のみを紹介しましたが、PySpark は表現力が高く、移行で必要なあらゆる変換を実装できます。 データの準備ができたので、DSQL に書き込みます。次のコードがその処理です。 # Fetch token for authorization jdbc_url = 'jdbc:postgresql://' + args['dsql_endpoint'] + ':5432/postgres?sslmode=require' password = dsql.generate_db_connect_admin_auth_token(args['dsql_endpoint'], ExpiresIn=28800) # Write tables to DSQL customers_adjusted.write \ .format("jdbc") \ .mode('append') \ .option("url", jdbc_url) \ .option("dbtable", 'sales.customers') \ .option("user", "admin") \ .option("password", password) \ .option('sslmode', 'require') \ .option('isolationLevel', 'NONE') \ .option('batchsize', '2500') \ .option('stringtype', 'unspecified') \ .save() orders_final.write \ .format("jdbc") \ .mode('append') \ .option("url", jdbc_url) \ .option("dbtable", 'sales.orders') \ .option("user", "admin") \ .option("password", password) \ .option('sslmode', 'require') \ .option('isolationLevel', 'NONE') \ .option('batchsize', '2500') \ .option('stringtype', 'unspecified') \ .save() job.commit() まず、コードは IAM 認証 用のトークンを生成します。このトークンをデータベースのパスワードとして使います。移行ジョブの実行を通じてトークンが有効であり続けるよう、認証トークンに長めのタイムアウトを設定しています。 次に DataFrameWriter を使い、DataFrame の write() を呼び出して customers と orders の DataFrame を Aurora DSQL のそれぞれのテーブルに書き込みます。Spark が Aurora DSQL でテーブル作成を試みないよう、 DataFrameWriter の書き込みモードを「append」に設定します。Aurora DSQL は SSL 接続が必須のため、「sslmode」を「require」に設定します。 DataFrameWriter のデフォルト動作では、insert を複数バッチに分割しつつもすべてを 1 つのデータベーストランザクションで実行します。この挙動は Aurora DSQL の「1 トランザクションあたり 3,000 行まで」という変更行数の制限に抵触し、AWS Glue ジョブが失敗する原因になります。これを回避するため「isolationLevel」を「NONE」に設定し、各バッチの後に DataFrameWriter がコミットするよう強制します。バッチサイズが DSQL の制限を超えないよう「batchsize」を「2500」に設定しています。 クリーンアップ 移行を実行し、結果を検証し、AWS Glue スクリプトを理解できたところで、本記事で作成したリソースをクリーンアップします。 まず、次のコマンドで CloudFormation スタックを削除します。 aws cloudformation delete-stack --stack-name apg-to-dsql 次のコマンドを定期的に実行し、コマンドが「Stack with id apg-to-dsql does not exist」というエラーを返すまで状態を確認します。エラーが返ればスタックが削除されたことを意味します。 aws cloudformation describe-stacks --stack-name apg-to-dsql --output text --query 'Stacks[*].StackStatus' CloudFormation スタックが削除されたら、次のコマンドで Aurora DSQL クラスターを削除します。 aws dsql delete-cluster --identifier $DSQL_CLUSTER_ID 続いて、次のコマンドでデータベーススナップショットを削除します。 aws rds delete-db-cluster-snapshot --db-cluster-snapshot-identifier migrate-to-dsql 最後に、本例でソースデータベースとして使った Aurora PostgreSQL クラスターを削除します 。 まとめ 本記事では、AWS Glue を使って Aurora PostgreSQL のスナップショットから Aurora DSQL へデータを移行する方法を紹介しました。AWS Glue はマネージドな並列実行環境を提供し、大量のデータを Aurora DSQL に短時間で移行しつつ、表現力の高いプログラミング言語でデータ変換を行えます。プロセス全体は複雑に見えますが、難しいのは AWS Glue スクリプトを書く部分だけで、その難易度は移行の複雑さや PySpark の習熟度によって変わります。本記事では、ご自身の移行に合わせて修正できるベーススクリプトを提供しています。 ブラウザベースの プレイグラウンド を使えば、AWS アカウントがなくても今日から Aurora DSQL を評価できます。プレイグラウンドは一時的なデータベース環境で、Aurora DSQL を素早く試して数分でハンズオンを始められます。 著者について Dan Blaner Dan は、データベースを専門とする Principal Solutions Architect です。シナジーの活用、パラダイムシフト、枠にとらわれない発想を楽しんでいます。閉所恐怖症で箱には入れないので、まず枠の中で考えること自体が得意ではないかもしれません。なぜ箱に入れと言うのか、ですって? 性格的に疑り深いところもあります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Koji Shinkubo がレビューしました。

2026/4/20 – 4/24 に世界最大規模の産業向け展示会ハノーバーメッセが開催されました。AWS は今年も “Built for Industrial AI” というテーマを掲げ、フィジカル AI を筆頭に、AI とクラウドを活用し製造業の業務を変革するアイディアを提供しました。AWS の製造のリーダーである Ozgur Tohumcu から、”産業 AI は大規模展開してこそ意味がある”というメッセージを基調講演で語りました。イベント全体での AWS の活動は、別途 月刊 AWS 製造ブログ でもご紹介しています。このブログでは AWS ブースの概要と展示ソリューションについてご紹介します。 AWS の展示ブース AWS は “Built for Industrial AI” を体現するブースとして「スマート生産」「サプライチェーン」と「製品設計・開発」「スマートプロダクト」の４領域を２つに分けて展示しました。フィジカル AI やシミュレーションへの注目により製品開発系の展示が大きく増えています。 今年度も昨年同様、SIEMENS, QAD, Zoomilion といった様々な業界パートナーが AWS ブース内で展示を行うとともに、AWS 自身の展示を大きく増やしました。本年も、日本チームが現地で日本語でお客様をご案内しました。 本ブログでは、フィジカル AI と主要な４領域の展示についてご紹介します。 フィジカル AI 写真: フィジカル AI デモ “AI-Driven Product Journey” フィジカル AI は本年 AWS ブースで最も注目を集めたエリアの一つで、来場者の足が絶えない人気を博していました。目玉となったのが、”AI-Driven Product Journey” と題された大型デモです。このデモは、来場者がキオスク端末でデザインを選択・入力すると、生成 AI がオリジナルデザインを生成し、AMR(自律走行ロボット)・協働ロボットアーム・レーザー彫刻機・AI 画像検査装置・ヒューマノイドロボットが協調しながら金属製コースターを製造、最終的にヒューマノイドが完成品を来場者に手渡すという一連のプロダクトジャーニーを実演するものです。AMR が LiDAR で周囲を知覚し自律走行する、ロボットアームが 3D ビジョンで部材を認識し把持する、ヒューマノイドが強化学習で獲得した歩行で物を運ぶなど、それぞれが物理世界を知覚・理解し、直接作用するという フィジカル AI の異なる側面を体現しており、フィジカル AI が役割分担して働く姿を一望できる構成になっています。 写真: エージェント AI による工程のオーケストレーション 本デモのもう一つの注目点は、工程全体を エージェント AI が自律的にオーケストレーションしている点です。各装置・ロボットの操作がツールとして定義され、エージェント AI が状況をリアルタイムに判断しながら全工程を指揮します。事前にハードコードされたシナリオをなぞるだけではなく、状況に応じて柔軟に振る舞える点が従来の産業オートメーションとの大きな違いであり、産業 AI を実運用へスケールさせていく上での重要なステップを示すデモとなっていました。 スマート生産 (Smart Manufacturing) Smart Manufacturing エリアは今年も AWS ブースの中で最も広いスペースが割かれており、上記の AI-Driven Product Journey を中心に多くの来場者で賑わっていました。また Rockwell Automation、HighByte、Databricks、Snowflake、Palantir といったパートナー各社との協業展示が目立ち、AWS 単独ではなくエコシステム全体でスマート製造を実現するという姿勢が強く打ち出されていました。技術面では AI エージェントが自律的に複数システムを横断して分析・判断を行うアーキテクチャが前面に出てきたのが昨年からの大きな変化です。ここではその中から、Agentic Workflow Automation と Real-Time Plant Analytics の 2 つのデモをご紹介します。 写真: Agentic Workflow Automation — AI エージェントが製造現場の意思決定を自律支援する内容のデモ Amazon Bedrock AgentCore を基盤に、複数の AI エージェントが MES・ERP・CMMS・IoT を横断して製造データを分析するデモです。「3 工場の生産実績とオーダー目標を比較してほしい」「納期リスクのある顧客オーダーはどれか」といった質問を自然言語で投げかけると、エージェントがグラフデータベースの関係性を元に複数システムからデータを取得し、レポートを自動生成します。エージェントの推論過程がステップごとにリアルタイム表示される “Investigation Trace” 機能もあり、AI がどのデータソースにアクセスしてどう判断したかが透明に追跡できる点が印象的でした。 写真: Real-Time Plant Analytics — 工場 KPI（OEE、不良率等）のリアルタイム監視と、AI によるシフト交代レポートの自動生成デモ Amazon Quick を基盤とした Manufacturing Dashboard の展示です。Overview 画面では OEE や Defect Rate、First Pass Yield といった主要 KPI がリアルタイムで一覧表示されます。中でも注目したいのが Shift Handoff Report 機能で、シフト交代時に AI がワークセンター別の OEE・欠陥分布・保全状況を自動分析し、引き継ぎレポートを生成します。画面右側には Manufacturing Assistant チャットも統合されており、レポートの内容を対話形式でさらに深掘りすることも可能です。 サプライチェーン (Supply Chain) 写真：Supply Chain のデモ 今年も AWS ブース内の他のデモと連携した、Supply Chain のデモをご紹介しました。昨年も同じ AWS ブース内にある製造デモと情報連携し、Supply Chain に関わる情報の可視化や需要予測などを展示しておりましたが、昨年からの大きな変更点として、今回は Kiro で開発したアプリケーションを展示させていただきました。 業務仕様書とデータの構成を元にアプリケーションを自動生成することで、企業におけるカスタムアプリケーション導入/利用の柔軟性を上げ、開発/導入の時間および難易度を下げていく例をご紹介しました。また、同ブース内では、パートナー企業である QAD の ERP・Redzone の展示や、会期中には、こちらもパートナー企業である Infor が製造業における エージェント AI の活用に関する協業の発表を行い、パッケージアプリケーションとカスタムアプリケーションを選択していただく、または組み合わせて利用するといった、お客様の状況に合わせて選択していただける選択肢を AWS が提供している様子をお伝えしました。 製品設計・開発 (Product Engineering) 今回、フィジカル AI の注目により製品設計・開発領域の内容を大きく増やしました。Engineering &amp; Development Tunnel という展示では、AI によるデザインの提案 –&gt; エンジニアリングツールを仮想化 –&gt; デジタルスレッドで設計開発データの連携 –&gt; AI によるパラメータ空間探索(サロゲートモデル)という流れをご紹介しました。AI ( Amazon Nova ) が提案した意匠は、Smart Manufacturing のデモに連携され、レーザー加工によりコースターとして生産されます。 製品設計に必要な様々なエンジニアリングツールを仮想化する例として、 PTC の CAD (Creo) と、開発中の CAD へのアドバイスを行う紹介がありました。全体に、Engineering Development Hub (EDH) という新しいエンジニアリング環境が使われ、様々な CAD/CAE の環境を仮想化し、呼び出し、管理し、VDI で接続することで計算リソースやワークステーションを柔軟に増減させ管理の手間を減らすことができる様をご紹介しました。 写真：Engineering &amp; Development Tunnel (左) と Creo のデモ (右) 設計されたデータはシミュレーションにより性能を検証しますが、設計パラメータを変更して都度シミュレーションを行うとそのための計算量やコストも膨大になります。そこで、過去のシミュレーション結果から異なる設計パラメータのシミュレーション結果を AI で予測する手法がサロゲートモデルです。パートナーの Neural Concept との共同展示で、データセンターの冷却を題材としたパラメータスタディを行うデモを展示しました。 SIEMENS との共同展示では、設計データから強度シミュレーションを行い、その結果を元に生成 AI に設計改善のアドバイスをさせるデモが示されました。また、“OT Modernization” という展示では、シミュレーションを製品開発だけではなく生産設備のエンジニアリングに活用し、生産ラインにおけるアームロボットの動作を生成 AI で最適化してタクトタイムを縮めるという提案を行いました。 写真：SIEMENS との共同展示 (左) と OT Modernization の展示 (右) 他にも、CAD の展示として完全クラウドベースのアーキテクチャにより無限 Undo や PDM の統合を可能にし、オペレーションを中間言語で記述することで AI による支援を容易にするといった意欲的な機能を搭載した PTC の Onshape が紹介されました。 スマートプロダクト (Smart Products &amp; Services) 今年のスマートプロダクトエリアのトレンドは、「売って終わり」から「売った後も継続改善」への転換が現実的になってきたことです。開発面では、AI エージェントが設計からリリースまで全フェーズに介入し、組み込みソフトの開発サイクルを劇的に短縮。出荷後も迅速にアップデートを続けられる体制が整いつつあります。サービス面では、テレメトリ・保守履歴・顧客問い合わせなど複数データソースを AI が統合解析し、故障予兆検知やプロアクティブなサポートを実現。予防保守サブスクやリモート診断など新収益ストリームの創出と顧客関係強化につながっています。スマートプロダクトでも DevOps の継続改善サイクルが回せる時代に入った — これが今年最大の変化です。この記事では、”Accelerate embedded software development and equipment” と “Smart Products Telemetry Driven ‘X'”の 2 デモをご紹介します。 写真: Accelerate embedded software development and equipment — 組み込みソフトウェア開発の課題を示すスライドと、Kiro が 30 分以内で実装した 空調管理システム UI の実機（右下） Kiro （AI 駆動 IDE）による組み込みソフト開発ライフサイクル全体の加速デモです。空調管理システム（C++ で実装/ 7 インチ HMI 画面）を題材に、Research・Plan・Development・Release の 4 フェーズを一気通貫で実演します。注目すべきは、画像右下の空調管理システム実装において、リモートデバッグ・UI チェック・デプロイをすべて Kiro が自律実行し、30 分以内で完了させている点です。従来 1 週間以上かかる作業が、コード生成→デプロイ→スクリーンショット評価→改善のフィードバックループで劇的に短縮されています。 デモの内容を体験できるワークショップ も公開されています。 写真: Smart Products Telemetry Driven “X” — デバイス障害検知時に Amazon Connect へリアルタイムのテレメトリとアラートが自動連携される様子 AWS IoT Core と Amazon Connect を組み合わせたサービス改善の展示です。産業機器（デモでは 3D プリンター）のテレメトリをリアルタイム収集・監視し、エラー発生時にはデバイスデータがサポートエージェントに自動連携されます。顧客にシリアル番号や症状を確認する手間なく即座に問題解決に着手できます。AI エージェントが解決できない場合は自動でタスク生成し、熟練技術者や専門 AI エージェントへエスカレーションする仕組みも備えています。 まとめ 本年のハノーバーメッセでは、”Built for Industrial AI” のテーマのもと、フィジカル AI と エージェント AI が製造業のバリューチェーン全体に広がりつつある姿が印象的でした。生成 AI による意匠提案から エージェント AI による工程オーケストレーション、ロボットによる物理世界での実行までが一つのシナリオで繋がる “AI-Driven Product Journey” は、その象徴的な事例です。Smart Manufacturing・Supply Chain・Product Engineering・Smart Product の各領域でも、AI エージェントが複数システムを横断して人の意思決定を支援するアーキテクチャが共通の方向性となりつつあり、産業 AI が実証から実運用フェーズへ着実に進みつつあることを感じる場となりました。AWS は引き続き、産業 AI を実運用にスケールさせていくお客様の取り組みを支援してまいります。 なお、6 月 25, 26 日に開催される AWS Summit Japan 2026 でも フィジカル AI や産業 AI の展示をご用意しています。Summit 向けに企画した新たなデモを通じて、製造業における AI の可能性を体感いただけます。ぜひご登録のうえ、会場でお会いできれば幸いです。 AWS Summit Japan 2026 の登録は こちら 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI エージェントと毎日戯れており、AI エージェント無しでは生きていけなくなっています。好きなうどんは’かけ’です。