「あの商品どこ？」というお客様からの一言に、新人スタッフは即答できるでしょうか。 AWS Summit Japan 2026 の流通小売・消費財・飲食ブースで、「スマートグラス × 音声 AI エージェントによる店舗業務支援」デモを展示し、スマートグラスを装着した来場者ご自身が、声で話しかけるだけで AI が音声と AR 表示で即答する体験をお届けしました。 図 1: デモのイメージ。スマートグラスに話しかけると、棚位置・商品名・在庫を視界に表示 このデモは、 Amazon Nova 2 Sonic と Amazon Bedrock AgentCore Gateway を中核とするマネージドサービスの組み合わせで構成されています。 解決したい課題: 新人の「即戦力化」 流通小売・飲食業界のお客様とお話しする中で、必ずと言っていいほど話題に上るのが「人手不足」です。採用が難しいことに加え、パート・アルバイトの入れ替わりや外国人スタッフの増加により、経験の浅いスタッフで現場を回す場面は今後ますます増えていきます。 そこで本デモが着目したのが、「 新人が戦力になるまでの時間 」を縮められないか、という切り口です。ベテランなら 1 秒で答えられる「あの商品どこ？」も新人には答えられず、売り場を覚えるのに数週間、商品知識を身につけるのに数ヶ月かかり、その間の接客品質はシフトの巡り合わせで決まってしまいます。 壁 具体的な場面 ビジネスへの影響 知識の属人化 「あの商品どこ？」にベテランしか即答できない 接客品質がシフト次第でばらつく バックヤード往復 「在庫ありますか？」の確認で往復 2〜3 分 お客様は待ちきれず離脱、販売機会を損失 両手が塞がる 品出し・調理中に端末を取り出せない 情報を調べる行為自体が業務の中断になる タスク管理の断絶 品出し・値札変更等が口頭伝達やメモベース 抜け漏れ・重複対応が発生、連携コストが高い 言語の壁 外国人スタッフがマニュアルにアクセスできない 戦力化がさらに遅れ、業務の偏りが生まれる 生成 AI によるチャットボットの業務活用は一般的になりつつあります。しかし、画面とキーボードを前提とした UI は、品出し中・調理中・接客中など「両手が塞がる」現場では使いにくく、情報を調べる行為自体が業務の中断になってしまいます。 そこで本デモでは、 スマートグラス × 音声 AI エージェント という組み合わせを選びました。声で聞けば、AI がベテランの知識で即答する。新人が初日からベテランの知識にアクセスできる状態を目指したデモです。 使用したスマートグラス: RayNeo X3 Pro RayNeo X3 Pro（製品ページ） 透過型フルカラー MicroLED ディスプレイ（6,000nits ピーク輝度）により、装着した本人にだけ文字やカードが浮かんで見える マイク 3 基（ビームフォーミング対応）+ ステレオスピーカー 2 基を内蔵し、音声入力と再生がグラス単体で完結 スピーカーは耳を塞がない骨伝導方式。AI の音声を聞きながらお客様との会話や店内アナウンスも聞き逃さないため、通常のイヤホンのように業務を阻害しない スナップオン式の度付きインサートレンズに対応。普段メガネをかけている方でも視力を補正した状態で体験可能 図 2: 本デモで使用したスマートグラス RayNeo X3 Pro。見た目は普通のメガネながら、AR ディスプレイ・マイク・スピーカーを内蔵 本デモでは、右フレーム上部の物理ボタンをワンクリックすると音声入力が始まるようアプリを実装し、来場者が迷わず操作できるようにしました。 なお、本ソリューションは特定デバイスに依存しません。「音声を送り、テキスト・画像を受け取って表示する」API を呼び出せるスマートグラスであれば、他機種にも置き換え可能です。 体験シナリオ 来場者には 1〜2 分で、スーパー / アパレル / 飲食の 3 業態から興味のあるシナリオを選んでいただきました。 図 3: ブースに掲示した操作手順と質問例のパネル ここでポイントとなるのが、AI の回答が 音声と AR 表示の 2 チャネルで同時に届く ことです。 音声 : 耳で聞きながら手を止めずに作業を続けられる AR 表示 : エリア番号や在庫数など「聞き逃したら困る情報」が視界に残り続ける 「音声で概要を掴み、詳細は視界のカードで確認する」という組み合わせが、ハンズフリーでも確実な情報アクセスを実現します。それでは、代表的なやり取りをご紹介します。 スーパー: バイト初日でもベテランの案内 入社初日のアルバイトスタッフ。お客様に「コーヒーはどこ？」と聞かれたが、売り場配置をまだ覚えていない。 [スタッフ] 「コーヒーはどこですか？」 [音声] 「有機コーヒー豆 200g は C-02 エリアにあります。在庫は 7 点です」 売り場を覚えていない新人でも、音声で答えを聞きながら、視界に残るエリア番号を頼りにお客様をそのままご案内できます。 図 4: 商品名・棚位置・在庫を AR カードで表示（実際の UI を背景に合成して再現。実機では背景が現実の視界になる） スーパー: 「ありません」で終わらない接客 品出し中のスタッフ。お客様から在庫を聞かれたが、自店舗には在庫がないケース。従来なら「ありません」で終わるところを、AI が在庫システムを参照し近隣店舗の在庫まで提示する。 [スタッフ] 「食パンはありますか？」 [音声] 「食パン 6枚切りは、幕張店には在庫がありませんが、麻布台店には 12 点の在庫があります」 自店舗に在庫がないと判断すると、AI エージェントが指示されなくても近隣店舗の在庫を検索し、代替案を提示します。 図 5: 自店舗に在庫がない場合、近隣店舗の在庫を表示 アパレル: EC へのシームレスな誘導 アパレル店舗の接客スタッフ。お客様が欲しいサイズが店舗に無い場合、近隣店舗や EC サイトの在庫まで自動で探し、売り逃しを防ぐ。 [スタッフ] 「Tシャツの L サイズはありますか？」 [音声] 「L サイズの Tシャツ ベーシック 白は、幕張店には在庫切れですが、EC サイトに 5 点あります」 店舗 → 近隣店舗 → EC と段階的にフォールバックするため、売り逃しが発生しません。この「在庫切れでも終わらない接客」は、来場者に最も驚かれたポイントの一つでした。 図 6: サイズ別在庫を表示。在庫切れサイズは EC 在庫も表示 飲食: 予約確認 飲食店のホールスタッフ。料理を運びながら、次のテーブルの予約状況を確認したい。端末を取りに行かずに声だけで確認できる。 [スタッフ] 「テーブル 5 の予約状況は？」 [音声] 「テーブル 5 は伊藤様、2 名、17 時半から 19 時半です。ラストオーダーは 19 時です」 予約確認も声だけで完結。テーブル番号を聞くだけで予約者名・時間帯・ラストオーダーまで即座に返答します。 図 7: テーブル番号・予約者名・時間帯・ラストオーダーを表示 タスク管理: 声で登録 清掃担当のスタッフ。作業中に気づいたタスクを、手を止めずにその場で登録したい。 [スタッフ] 「トイレ清掃をタスクに追加して」 [音声] 「トイレ清掃をタスクに追加しました」 タスクの登録も声だけで完結。手を止めてメモを書いたり端末を操作する必要がありません。 図 8: 追加されたタスクの内容と優先度を表示 多言語: 英語で聞けば英語で返る 外国人スタッフ、または英語しか話せないお客様への対応。日本語のマニュアルや POS 端末を読めなくても、母国語で質問すれば母国語で回答が返る。 [スタッフ] “Where is the coffee?” [音声] “The Organic Coffee Beans 200g are in area C-02 at the Makuhari Store. We have 7 in stock.” 英語で話しかければ英語で回答し、AR カードの値も英語に切り替わります。 図 9: 英語で質問すると、AR カードも英語で表示 管理者からのプッシュ通知 店長がバックオフィスからフロアスタッフへリマインドを送るケース。ラストオーダーの声かけ忘れを防ぎたい。 管理画面からリマインドを送信すると、スタッフのグラスに音声と AR カードで通知が届きます。 [AR] テーブル 5 ラストオーダー [音声] 「テーブル 5、ラストオーダーの時間です」 インカムのように全員に割り込むのではなく、必要な情報を必要なスタッフへ届けられます。 図 10: プッシュ通知の流れ。上が店長の管理画面（リマインド送信ボタン）、下がスタッフのグラスに届いた通知 Agent Monitor: AI の思考プロセスを「見せる」 音声対話はグラス装着者にしか聞こえません。そこでブースの大型モニターに、AI エージェントが「商品検索 → 在庫確認 → 棚位置取得」と業務システムを呼び出す思考プロセスをリアルタイム表示しました。 図 11: Agent Monitor の動作画面。「コーヒーはどこ？」と聞いた瞬間から、ツール呼び出しの思考プロセスがリアルタイムに表示される 順番待ちの来場者にも楽しんでいただけると同時に、技術的な会話のきっかけとしても機能しました。 ご来場いただいたお客様の声 ブースには約 500 名の方にお立ち寄りいただき、多くのポジティブなフィードバックをいただきました。 図 12: AWS Summit Japan 2026 ブースの様子 最も大きな “Wow” を生んだのは、やはりスマートグラス越しに情報が浮かんで見える AR 体験そのものです。一方で技術者の方が驚かれていたのは別のポイントで、Amazon Nova 2 Sonic の応答の速さと、業務システムと自然に連携する Tool Use でした。 「スタッフがアトラクション・イベント・食事の確認に苦労しているため、導入検討したい」（テーマパーク業界） 「工場の業務が属人化しており、マニュアルを読み込ませて活用したい」（製造業） 「スーパー、ホームセンター、コンビニ、外食、アパレルなど店舗スタッフの業務支援に使いたい」（流通小売業界） 店舗向けに設計したデモにもかかわらず、ご来場いただいた方々には、「手が塞がる現場」「知識が属人化した現場」という共通項で自社の課題に置き換えて受け取っていただきました。私たちが訴求した「店舗業務支援」よりも一段抽象度の高い「現場の知識アクセス」というニーズが存在することは、展示を通じて得られた大きな気づきでした。 システム構成と技術的なポイント ここからは、本デモの技術構成をご紹介します。体験シナリオの裏側では、次の一連の処理が数秒で完結しています。 スタッフの声がスマートグラスからクラウド上の AI モデルに届く AI が発話を理解し、「どの業務システムに問い合わせるべきか」を自律的に判断してツール（商品検索・在庫確認など）を呼び出す ツールの結果を組み立てて、音声と AR 表示の両方で回答を返す この「AI が自分でツールを選んで呼び出す」仕組みは Tool Use と呼ばれ、本デモのアーキテクチャの中核です。以下、この流れを支える各コンポーネントを解説します。 全体アーキテクチャ 図 13: システムアーキテクチャ全体像 レイヤー コンポーネント 実体 役割 クライアント スマートグラス RayNeo X3 Pro (Kotlin + Jetpack Compose) 音声入力・AR 表示 クライアント Agent Monitor Next.js ( Amazon ECS Fargate) 思考プロセスのリアルタイム表示（ AG-UI プロトコル） 音声・推論 Sonic Sidecar ECS Fargate (Python) グラスと AI の橋渡し（WebSocket / SSE） 音声・推論 Amazon Nova 2 Sonic Amazon Bedrock (us-east-1) 音声理解・推論・Tool Use・音声生成を 1 モデルで完結 ツール接続 AgentCore Gateway Amazon Bedrock AgentCore Lambda を MCP ツールとしてエージェントに公開 バックエンド 業務ツール群 AWS Lambda (Python, ARM64) × 5 商品検索・在庫確認・棚位置取得・タスク管理・予約確認 データ 商品マスター Amazon OpenSearch Serverless + Amazon Titan Text Embeddings V2 セマンティック検索 データ 在庫・棚・タスク Amazon DynamoDB トランザクショナルデータ 全リソースは AWS CDK (TypeScript) で定義しています。 Amazon CloudFront による配信を組み合わせたマネージド構成です。 アーキテクチャのポイント 1. Amazon Nova 2 Sonic のネイティブ Tool Use で「1 モデル完結」 Amazon Nova 2 Sonic は、音声を直接入力として受け取り、音声で直接回答を返す Speech-to-Speech モデルです。従来の音声アシスタントでは「音声→テキスト変換 (STT) → テキスト LLM で推論 → テキスト→音声変換 (TTS)」と 3 つのステップを組み合わせる必要がありましたが、Nova 2 Sonic はこれを 1 モデルで完結させます。さらに、推論の途中でバックエンドのツールを呼び出す Tool Use もモデル内で行われるため、レイテンシとシステム複雑性の両方を削減できます。 本デモでは Sonic Sidecar が Nova 2 Sonic と双方向ストリームを張り、モデルから toolUse イベントを受け取るとバックエンドのツールを呼び出し、結果を返します。モデルは必要に応じて複数ツールを連鎖的に呼び出し（商品検索 → 在庫確認 → 棚位置取得）、最終的に音声で回答を生成します。 Amazon Nova 2 Sonic モデルカード（ドキュメント） 2. AG-UI プロトコルによる思考プロセスのリアルタイム可視化 Agent Monitor は AG-UI (Agent-User Interface) というプロトコルでエージェントの実行状態をストリーミング受信しています。AG-UI は「エージェントの中で今何が起きているか」をフロントエンドにリアルタイムに伝えるためのプロトコルです。本デモでは RUN_STARTED 、 TOOL_CALL_START 、 TOOL_CALL_RESULT 、 TEXT_MESSAGE_CONTENT といったイベントを SSE で逐次受け取り、エージェントが「今何を考え、どのツールを呼んでいるか」をリアルタイムに描画しています。フロントエンドのフレームワークを問わず同じイベントストリームを消費できるため、UI を独立して開発・差し替えできます。 3. Amazon Bedrock AgentCore Gateway で既存業務システムを簡単に接続 Amazon Bedrock AgentCore Gateway は、既存の API や Lambda 関数を AI エージェントが呼び出せるツールとして公開するマネージドサービスです。ツールの公開には、AI エージェントとツールをつなぐ共通規格として広く採用されている MCP (Model Context Protocol) を用いており、エージェントのフレームワークを問わず接続できます。本デモでは商品検索・在庫確認・棚位置取得・タスク管理・予約確認の 5 つの Lambda を Gateway に登録し、エージェントから MCP プロトコルで呼び出せるようにしています。 これにより、既存の業務システム（商品マスタ / 在庫マスタ / 基幹 API 等）を Gateway にツールとして登録するだけで、AI エージェントから即座に利用可能になります。Lambda でラップする方法に加え、OpenAPI 仕様に準拠した既存の REST API をそのまま登録することもできます。認証（IAM SigV4）やツールのセマンティック検索も Gateway が管理するため、エージェント側の実装を変更せずにツールの追加・差し替えができます。 Amazon Bedrock AgentCore Gateway（ドキュメント） 他業界への応用 本ソリューションのコアパターン「スマートグラス × Speech-to-Speech × ネイティブ Tool Use」は、手が塞がる業務環境全般に適用可能です。 業界 適用イメージ 製造 設備マニュアル・作業手順の音声照会、点検記録のハンズフリー登録 物流・倉庫 ピッキング位置案内、在庫照会、作業指示の音声受け取り 医療・介護 器材の所在確認、申し送り事項の音声記録 テーマパーク・ホテル 施設情報の即時照会、多言語での接客支援 技術的には AgentCore Gateway にツールを追加登録するだけで異なるドメインに対応できるため、自社の業務システムを Gateway に接続するだけで同様の体験を実現できます。 まとめ 本記事では、AWS Summit Japan 2026 で展示した「スマートグラス × 音声 AI エージェント」によるハンズフリー店舗業務支援デモをご紹介しました。 「あの商品どこ？」に新人が即答できない。この小さな困りごとの裏には、知識の属人化、販売機会の損失、外国人スタッフの戦力化といった、現場が長年抱えてきた課題が積み重なっています。声で聞けば AI がベテランの知識をスマートグラス上に AR + 音声で即答してくれる体験は、これらの課題への一つの答えになり得ると、来場者の皆様の反応を通じて実感しました。 そして、この体験を支える技術は決して特別なものではありません。Amazon Nova 2 Sonic と Amazon Bedrock AgentCore Gateway を中心としたマネージドサービスの組み合わせで構成しており、既存の業務システムをツールとして接続すれば、同様の仕組みをご自身の環境でも実現できます。 「手が塞がっている現場での情報アクセス」は、小売・飲食に限らず、製造、物流、医療、ホスピタリティなど多くの業界に共通する課題です。本記事が、現場業務への音声 AI エージェント活用を検討されている方の参考になれば幸いです。

2026年6月25日に開催された AWS Summit Japan 2026 の流通小売・消費財ブースにて、Amazon Quick を活用した物流業務の一気通貫自動化デモを展示しました。本ブログでは、展示の概要とデモの見どころをご紹介します。 はじめに 物流の現場では、基幹・受発注・在庫・配送など複数のシステムにデータが分散しています。今回の展示では、 Amazon Quick がこれらの課題をどのように解決するかを、実際の業務シナリオに沿ってデモでお見せしました。皆さまの物流現場でも、こんな課題はありませんか？ データの散在 ：複数システムにデータが散在し、異常に気付きにくい。探すのも一苦労。 発見の遅れ ：日次レポートの目視確認で数日遅れ、異常を見逃す。 属人化による対応の遅れ ：分析も対応も特定の人に依存し、知識が共通化されていない。 Point 1：データ横断できるようにする バラバラだったデータを一つの AI サービスに集約します。受発注情報、在庫管理情報、配送情報、SLA規約、過去の報告書、業務マニュアル——これらすべてを Amazon Quick に統合し、セキュアに横断活用できるようにします。 これにより、ダッシュボード・Chat Agent・自動化などの Agent 機能から、データを横断的にセキュアに活用できるようになります。自然言語による原因追及、メール送信、ダッシュボードでの異常確認、異常検出の自動化——すべてが、統合されたデータの上で動きます。 Point 2：プロアクティブに情報を獲得し、物流業務を一気通貫で完結 データを集約した上で、プロアクティブに必要な情報を獲得し、すぐにアクションできるようにします。以下の4ステップで、異常検知から対応完了までを一気通貫で完結します。 Quick Automate がシステムの異常を検出し、すぐにチームへ通知。早期発見で対応遅れを防止します。 Quick Sight で配送の滞留異常を一目で把握。チャットで追加グラフも簡単に生成できます。専門知識は不要です。 Chat Agent がチャットだけで根本原因を深掘り分析。基幹データも過去報告書も、セキュアに横断活用します。 配送業者をすぐに特定し、過去の取引状況に沿ったレポートやメール送信を即時で実行します。 ソリューション ステップ1：異常検知と通知（Quick Automate） 従来は日次レポートを目視確認して、数日遅れで配送異常に気づいていました。Amazon Quick では、Quick Automate が受発注・在庫・配送など、業務システムを横断的に監視し、Agent が自律的に異常を検知します。異常を検知した瞬間に、チームの Microsoft Teams チャネルにアラートが通知されます。手作業は不要です。しきい値の設定やトリガー条件はワークフロー内で柔軟に変更でき、分析の視点を与えて Agent に判断させることも可能です。スケジュール実行にも対応しており、定期的な監視を完全に自動化できます。 ステップ2：滞留状況の可視化（Quick Sight） 通知を受け取ったら、次は状況の把握です。従来は配送・在庫・受発注の各システムに個別にログインして確認する必要がありましたが、Amazon Quick なら Quick Sight ダッシュボード1画面で配送の滞留状況をすぐに全体把握できます。AWS のサービスとネイティブに統合されているため、データソースの接続から可視化までを、一つのサービス内でご利用いただけます。 さらに遅延が発生しているルートに関して「ABC運輸の大阪→福岡の遅延率を週別で出して」とチャットで聞けば、その場でグラフが生成されます。「大阪→福岡ルートで他の業者は？」と聞けば、業者リストなど別のデータを掛け合わせ、代替業者を探すことも可能です。SQL や専門知識は不要です。 ステップ3：原因の深掘り分析（Chat Agent） ダッシュボードで異常箇所を特定したら、次は根本原因の追及です。物流専門家の Chat Agent に聞くだけで、業務システムの構造化データと、SharePoint やファイルストア上の報告書・SLA合意書などの非構造化データを Agent がセキュアに横断して読み解きます。権限を持つユーザーのみが適切にデータにアクセスする仕組みです。 従来なら報告書を探して、データを手動で突き合わせて、ベテランに聞いて……半日かかっていた原因追及作業が、チャットで聞くだけで数分で完了します。ベテランの知見を誰でも獲得でき、属人化が解消されます。 ステップ4：業者への素早い問合せ（Connectors） 原因がわかったら、最後は配送業者への対応です。従来は担当者の連絡先を調べ、過去のやり取りを探し、文面を1から作成していました。Amazon Quick では、Agent が業者の連絡先や過去の取引状況を把握しているため、調査で得たすべてのコンテキストを踏まえて適切な文面を自動生成し、メール送信まで完結します。Outlook だけでなく、Gmail・Slack・Salesforce・ServiceNow・Jira など40以上の Action Connector に対応しており、分析→判断→連絡という業務がワンストップで完結します。 アーキテクチャ紹介 本デモの技術構成を紹介します。 関連する業務システム（配送管理・在庫管理・受発注）からデータを取得し、Amazon Quick 内でAgent が利用できるようにデータセットへ変換します。ユーザーはダッシュボードやトピックで配送異常を確認し、Chat Agent を通じて自然言語で原因を追及できるようになります。 物流専門家 Agent が、配送異常がある業者への問い合わせや、過去の対応履歴確認に対応します。Outlook や SharePoint などと Connector で接続しておけば、ユーザーに代わって Agent が過去報告書を探し、問合せ先を確認し、メールを送信してくれます。 定期的な異常確認には Automate を使い、Connector として、業務システムの API と接続します。リアルタイムでの情報確認や Teams へのアラート通知を実現しています。 セキュリティ面では、データごとにアクセス制御（行レベルセキュリティ）や ACLの継承 を設定でき、安全なデータ接続を支援します。 このように、Amazon Quick は可視化・AI 分析・自動化・外部連携をひとつのサービス上で統合的に提供しており、個別のツールを組み合わせる必要がありません。既存のデータソースや業務アプリケーションを横断的に接続し、目的に応じたデータ活用が実現できます。 まとめ 今回の展示では、Amazon Quick が物流業務の課題を以下のように解決する姿をお見せしました。 データの散在 : 1つのサービスに集約し、横断的にセキュアに活用 発見の遅れ : Agent が自律的に異常を検知し、即時通知 属人化 : チャットで聞くだけで誰でも深い分析が可能。対応まで完結 Amazon Quick は単なる BI ツールではなく、検知→可視化→分析→アクションまでを AI で一気通貫に自動化する統合的な体験を提供します。物流に限らず、在庫管理や配送最適化など、複数システムをまたぐ業務課題をお持ちのお客様に幅広くご活用いただけます。 著者について 加藤 菜々美 (Nanami Kato) アマゾンウェブサービスのソリューションアーキテクトです。エンタープライズの小売・消費財業界のお客様を支援しています。AI/ML や、サーバーレスの専門チームにも所属しています。お客様の業種業態に特化したビジネス課題に対して、テクノロジーを駆使した解決手段をお客様と一緒に検討・策定し、展開するご支援をしています。 古山 亮 (Ryo Furuyama) アマゾンウェブサービスのソリューションアーキテクトです。流通小売業界のお客様を中心にクラウド活用の技術支援を行なっています。好きなAWSサービスは Kiro, Quick です。

はじめに 「This Month in AWS Observability」最新号へようこそ。今回は、この6月に Amazon CloudWatch と AI 駆動型オペレーション全般で発表された新機能をご紹介します。CloudWatch でネイティブな OpenTelemetry メトリクスと PromQL クエリが一般提供（GA）となり、より深い統計・構造化分析のための 23 個の新しい Logs Insights コマンドがローンチされ、CloudWatch RUM に Session Replay が登場し、 AWS DevOps Agent では MCP および Agent-to-Agent プロトコルをサポートするカスタム SRE エージェントがリリースされました。EKS クラスター全体で GPU コストを配賦する場合も、実際のセッション再生でフロントエンドの問題をデバッグする場合も、チームのランブックを自律型 SRE エージェントに組み込む場合も、役立つ情報が見つかるはずです。これらの新機能のデモをご覧になりたい方は、8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」にご登録ください。 OpenTelemetry と Prometheus Amazon CloudWatch は、ネイティブ OpenTelemetry メトリクスと PromQL クエリの一般提供という大きなマイルストーンに到達しました。また、Amazon Managed Service for Prometheus には、高カーディナリティなワークロードのコストと複雑さを削減する機能が追加されました。 ネイティブ OpenTelemetry メトリクスと PromQL クエリ（GA）  Amazon CloudWatch が OpenTelemetry メトリクスをネイティブにサポートし、一般提供が開始されました。チームは OpenTelemetry Protocol（OTLP）経由でメトリクスを直接送信し、Prometheus Query Language（PromQL）でクエリできます。料金は GB あたりの取り込み課金で、15 か月分のストレージが含まれます。これにより、CloudWatch と並行して別途 Prometheus 互換バックエンドを用意する必要がなくなります。数十のラベル（namespace、pod、container、node、deployment）を持つ高カーディナリティメトリクスが CloudWatch に直接流れ込み、チームがすでに慣れ親しんだ PromQL 構文で即座にクエリ可能になります。 CloudWatch Pipelines が OpenTelemetry メトリクスの処理とエンリッチメントをサポート  CloudWatch Pipelines により、カスタムインフラストラクチャやアプリケーション計装の変更なしに、取り込み時に OpenTelemetry メトリクスの処理とエンリッチメントが可能になりました。例えば、ビジネスコンテキストの追加、高カーディナリティラベルの除去、命名規則の強制などが行えます。 Amazon Managed Service for Prometheus のネイティブヒストグラムサポート  ネイティブヒストグラムは、バケット境界ごとに 1 つの時系列を出力する従来の Prometheus ヒストグラムを置き換えるものです。20 個以上のバケット境界を事前定義してメトリクスごとに 20 以上の時系列分のコストを支払う代わりに、ネイティブヒストグラムは分布全体を動的な解像度を持つ単一の時系列に格納します。これにより、レイテンシー、リクエスト時間、値の分布の追跡において正確なパーセンタイル計算を維持しながら、ストレージコストとカーディナリティを削減できます。 OTel と Managed Prometheus による GPU コスト配賦  Amazon Elastic Kubernetes Service 上で AI/ML ワークロードをスケールさせるチーム向けに、OpenTelemetry コレクター、Amazon Managed Service for Prometheus、Amazon Managed Grafana を使用した GPU コスト配賦の新しいリファレンスアーキテクチャが公開されました。namespace、チーム、ワークロードタイプごとに GPU コストを配賦でき、「共有クラスターで最も高価なコンピューティングリソースを消費しているのは誰か」という問いに答えられます。 CloudWatch と OpenTelemetry による Claude Code 利用状況の分析  Claude Code のような AI コーディングエージェントがエンジニアリング組織全体に広がる中、トークン消費量、チームごとのコスト、開発者の生産性の追跡が重要になっています。このパターンでは、CloudWatch OTLP エンドポイントを使用して Claude Code セッションからカスタム OpenTelemetry メトリクスを取り込み、既存ツールでは答えられない問い（どのチームが最も多くのトークンを消費しているか、開発者あたりのコストはいくらか、AI 支援開発が最も価値を発揮しているのはどこか）に答えるダッシュボードを実現します。 ログ分析の進化 Amazon CloudWatch Logs の新しいクエリ・取り込み機能により、ログデータの大規模な分析・検索・ルーティングが容易になります。 23 個の新しい CloudWatch Logs Insights クエリコマンド  CloudWatch Logs Insights に、複数カテゴリにわたる 23 個の新しいクエリコマンドが追加されました。 パースコマンド: 多様なログ形式からの構造化抽出のための parse_json、parse_kv、parse_csv、parse_xml 分析関数: より深い統計分析のための median、percentile_cont、mode、variance、stddev ハッシュ・IP 関数: セキュリティおよびネットワーク調査ワークフローのための md5、sha256、ip_to_int、cidr_match 条件ロジック: より表現力豊かなクエリ構築のための case、coalesce、nullif、if これらの追加により、複雑な調査のためにログを外部分析プラットフォームへエクスポートする必要性が減少します。 Log Analytics 統合コンソール  新しい Log Analytics コンソールは、ロググループ横断のクエリ、自然言語によるログデータの探索、再利用可能なクエリパターンの保存を単一のインターフェースで提供します。従来は複数のコンソールページを行き来する必要があった作業が、単一のワークフローに統合されました。 タグベースのロググループクエリ 個々のロググループ名を指定する代わりに、タグでロググループをクエリできるようになりました。数百〜数千のロググループを持つ組織にとって、クエリのスコープ指定が簡素化されます。チーム、環境、サービス階層でロググループにタグ付けすることで、明示的なリストを維持することなく「決済チームの本番ログすべて」をクエリできます。 マネージド Syslog 取り込み  CloudWatch Logs が、VPC エンドポイント経由で TCP、TLS、UDP を使用したマネージド syslog 取り込みをサポートしました。RFC 5424、RFC 3164、および Cisco FTD や ASA を含むベンダー固有の形式に対応します。syslog メッセージは自動的に構造化フィールドにパースされ、手動での変換なしに Logs Insights で即座にクエリ可能になります。 Elastic Beanstalk ログ統合  AWS Elastic Beanstalk 環境が、ネイティブ統合によりアプリケーションログとプラットフォームログを CloudWatch Logs に直接ストリーミングできるようになりました。カスタムの .ebextensions 設定や、Beanstalk 管理インスタンス上のログストリーミングエージェントは不要です。 大規模なメトリクスとモニタリング 新しいクエリおよびメトリクス機能が拡張され、より大規模で複雑なマルチアカウントアーキテクチャを、より長い保持期間とより深いサービス固有の可視性でサポートします。 クロスアカウントメトリクスの一元化  CloudWatch が、簡素化された設定によるクロスアカウントメトリクスの一元的な収集をサポートしました。組織はモニタリングアカウントを指定し、メンバーアカウントからメトリクスを自動的に集約できます。アカウントごとの手動セットアップなしに、フリート全体のダッシュボードとアラームが実現します。 Metrics Insights の保持期間延長 CloudWatch Metrics Insights クエリが延長された保持期間をサポートし、より長い過去のウィンドウにわたる分析クエリを実行できるようになりました。これにより、外部分析システムへのデータエクスポートを必要とせず、CloudWatch 内で直接トレンド分析、キャパシティプランニング、前年比較が可能になります。 Amazon ElastiCache: 13 個の新しい CloudWatch メトリクス  Amazon ElastiCache が、メモリ断片化、接続チャーン、キー削除（Eviction）パターン、レプリケーションラグの詳細、コマンドレベルのレイテンシー分布をカバーする 13 個の新しい CloudWatch メトリクスを公開しました。これらのメトリクスは、従来は Redis や Memcached インスタンスに直接接続しないと観測できなかった、キャッシュ劣化の早期警告指標を見える化します。 エンドユーザーモニタリングと合成モニタリング 強化されたリアルユーザーの可視性と、より柔軟な合成テストトポロジーにより、モニタリングがエンドユーザーにさらに近づきます。 CloudWatch RUM Session Replay CloudWatch Real User Monitoring（RUM）に Session Replay が追加され、実際のユーザーセッションを発生した通りに記録・再生できるようになりました。顧客から報告された問題を調査する際、エンジニアはユーザーが体験したインタラクション、ページロード、エラー、レイテンシーの正確なシーケンスを見ることができ、フロントエンドデバッグから当て推量を排除します。 Synthetics マルチロケーション Canary  CloudWatch Synthetics に、単一の管理設定のもとで同じ合成テストを複数の AWS リージョンから同時に実行するマルチロケーション Canary が導入されました。各ロケーションは独立して動作します。あるロケーションが失敗を報告し、他が成功している場合、CloudWatch はシグナルを相関させて局所的な問題とグローバルな障害を区別し、誤検知によるアラームノイズを削減します。 AWS DevOps Agent によるインテリジェントオペレーション AWS DevOps Agent は、クラウド環境向けの AI 搭載オペレーションアシスタントとして進化を続けており、自動調査のインテリジェンスとリーチの両方を向上させる新機能が追加されました。 カスタム SRE エージェント  チーム固有の運用ランブックやインフラストラクチャパターンに合わせたカスタム SRE エージェントを構築できるようになりました。カスタムエージェントは、サービスアーキテクチャ、よくある障害モード、推奨される修復手順に関する組織の知見をエンコードし、繰り返し発生する問題の解決時間短縮を可能にします。 MCP および A2A プロトコルサポート  AWS DevOps Agent が Model Context Protocol（MCP）と Agent-to-Agent（A2A）通信をサポートしました。これにより、DevOps Agent はマルチエージェントアーキテクチャの中で他の AI エージェントとオーケストレーションし、外部ツールの呼び出し、ナレッジベースへのクエリ、組織の境界を越えた修復ワークフローの調整が可能になります。 Webhook トリガーと曖昧性解消カード  新しい Webhook ベースのトリガーにより、外部システム（PagerDuty、Datadog、カスタムアラートパイプライン）が DevOps Agent の調査を自動的に開始できるようになりました。調査中に曖昧さに遭遇した場合、曖昧性解消カード（disambiguation cards）が実行を停止させる代わりに構造化された選択肢をオペレーターに提示し、人間のガイダンスを得ながら調査ループを前進させ続けます。 5 つの新リージョンへの展開  AWS DevOps Agent がさらに 5 つの AWS リージョンで利用可能になり、広範なグローバルカバレッジを実現しました。ヨーロッパ、アジアパシフィック、および追加の北米リージョンで運用するチームは、調査をローカルで実行できるようになり、データレジデンシーの懸念を軽減し、リアルタイム運用ワークフローのレイテンシーを改善します。 開発者体験の改善 AWS DevOps Agent には、日常の運用ワークフローの摩擦を減らす、的を絞った QOL（quality-of-life）改善が加えられました。 リリース管理機能（プレビュー） DevOps Agent がリリース管理機能をプレビューとして提供開始しました。コード変更の本番投入準備状況をレビューし、標準からの逸脱、依存関係への影響、Well-Architected への準拠をチェックするとともに、テスト計画を自律的に生成・実行してデプロイ前にリグレッションを検出します。これにより、チームは AWS、マルチクラウド、オンプレミス環境全体で、より速いリリースと MTTR の削減を実現できます。 静的 IP サポート エージェントスペースにアウトバウンドトラフィック用の静的 IP アドレスを設定できるようになりました。IP ベースの許可リストを必要とする外部システム（オンプレミスの ITSM プラットフォーム、パートナー API、レガシーファイアウォール）との統合が可能になります。 自動拡張チャットと完全なコンテキスト保持  DevOps Agent の調査インターフェースに、自動的に広がるチャット入力欄と、調査セッションをまたいだ完全なコンテキスト保持が追加されました。より長く詳細なプロンプトが切り捨てられることなくサポートされ、以前の調査に戻ると会話履歴と調査結果が完全な状態で保持されています。 AWS Cloud Operations Blog の関連記事（2026年6月） 2026年5月〜6月に AWS Cloud Operations Blog で公開された記事は以下の通りです。 2026年6月 Log analysis with facets, correlation, enrichment, and automation in Amazon CloudWatch Log Analytics （6月19日）– Salman Ahmed, Ravi Kumar Amazon CloudWatch と OpenTelemetry による Claude Code 利用状況の分析 （6月17日）– Rodrigue Koffi, Gianluca Cacace, Vadim Omeltchenko GPU Cost Attribution in Amazon EKS Using Amazon Managed Service for Prometheus, Amazon Managed Grafana, and OpenTelemetry （6月12日）– Siva Guruvareddiar Introducing native histogram support in Amazon Managed Service for Prometheus （6月12日）– Vinod Kisanagaram, Priyanka Verma, Rohit Sharma まとめ 過去 2 か月間のオブザーバビリティ関連のローンチは、明確な方向性を示しています。AI 支援オペレーションはプロダクショングレードへの移行を続け、ログ分析は CloudWatch コンソールを離れることなくより強力になり、メトリクスはマルチアカウントのエンタープライズアーキテクチャに対応する規模へスケールし、モニタリングは合成テストとリアルユーザー体験の両レイヤーへさらに深く到達しています。 これらの機能を使い始めるには OpenTelemetry メトリクスを OTLP 経由で CloudWatch に直接送信 し、別途 Prometheus バックエンドなしで PromQL でクエリする 既存のロググループで新しい Logs Insights クエリコマンド を試す   CloudWatch RUM の Session Repla y を有効にして、ユーザーが体験していることを正確に確認する   マルチロケーション Canary を設定して、合成テストのカバレッジを向上させ誤報を削減する AWS DevOps Agent の  カスタムエージェント  を探索し、チームの運用ノウハウをエンコードする 最近のローンチの完全なリストは、Amazon CloudWatch でフィルタリングした AWS What’s New ページ をご覧ください。 さらに詳しく知りたい方へ 8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」に参加して、これらの新機能の実際の動作を確認し、トラブルシューティングの高速化に活用してください。 著者 Dot Ho Dot は AWS Observability 担当の Senior Technical Product Marketing Manager です。WCA 3×3 マルチブラインド（目隠し複数ルービックキューブ）ソルブの記録向上に向けて練習中です。 Joe Alioto Joe は AWS の Cloud Operations 担当の Worldwide Senior Specialist Solutions Architect で、オブザーバビリティ、AI 駆動のオペレーション、集中型オペレーション管理を専門としています。20年以上のオペレーションエンジニアリング経験を持ち、直近2年間は AI と AIOps に注力しています。彼は、アプリケーションパフォーマンス、インフラメトリクス、データベースワークロードを結びつけるインテリジェントなオブザーバビリティ戦略の構築を支援しており、AI エージェントと自動化を活用して平均解決時間 (MTTR) を短縮し、オペレーションチームの大規模な働き方を変革することにますます取り組んでいます。 本ブログは 2026 年 7 月 15 日に公開された This Month in AWS Observability: June 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

はじめに 2026年6月25日、26日に幕張メッセで開催された AWS Summit Japan 2026において、AIエージェントによる建設機械のフリート管理デモ「産業機械の自律診断とリアルタイム安全監視」を展示しました。本記事では、このデモの技術的な構成と考え方を解説します。 建設機械や産業機械の保全業務では、機械の異常をいかに早く検知し、いかに早く適切な対処につなげるかが稼働率を左右します。また、日本をはじめ多くの国で熟練技術者の高齢化と労働力不足が進行しており、保全業務の担い手の確保は年々困難になっています。フリート運用の現場では、機械の情報が現場や機体ごとに分散して全体状況が把握できないこと、故障対応が熟練者の経験に依存することが課題となり、結果として復旧に時間と人手がかかります。センサーデータに基づく予知保全はこの課題への代表的なアプローチですが、従来の機械学習による異常検知には「異常が起きていることは分かるが、なぜ起きているのか、何をすべきかまでは分からない」という限界がありました。異常スコアを受け取った保全担当者は、結局マニュアルを調べ、過去の類似事例を探し、対処方針を自分で組み立てる必要があります。 本デモはこの課題に対し、IoT による遠隔監視で分散した情報を集約して機械の状態を可視化し、生成 AI エージェントが異常の一次分析と情報収集を自動で行うことで、保全担当者が判断と対処に集中できる環境を作る構成としています。エージェントが原因候補と対処手順をあらかじめ提示することで、経験の浅い担当者でも初動対応に着手しやすくなり、熟練者は高度な判断が求められる場面に集中できます。人手による報告、古典的な機械学習、そしてエージェント型の予知保全という3 つのアプローチを同一のフリートに対して並べて体験できる構成とし、それぞれの特性の違いが分かるようにしています。さらに、検知した異常に対する診断、チケット起票、オペレーターへの音声通知、実機の遠隔操作までを含めたエンドツーエンドのデモとして構築しました。 デモ概要紹介の動画は こちら からご覧いただけます。 デモの全体像 デモのシナリオは、建設機械メーカーのアフターサービス部門が、顧客先で稼働する 20 台の掘削機を遠隔監視し、サポートを提供するという設定です。東京エリアの各現場に散らばる掘削機はエンジン温度、エンジン回転数、油温、油圧、冷却水温度、クーラント残量、燃料残量といったテレメトリを送信しており、ダッシュボードではフリート全体の状態を一覧できます。 フリートマップは Amazon Location Service で構築しており、各機体の位置と状態 (Operational / Warning / Critical / Offline)を地図上に表示します。展示では、20 台のうち 19 台が正常に稼働し、1 台が異常状態にあるというシナリオを用いました。異常機体の存在を把握しマシン一覧に進むと、該当機体のエンジン温度と油温が異常に高いことをテレメトリから確認できます。分散していた機体の情報が一画面に集約されているため、異常の発見から状況の把握までがダッシュボード上で完結します。 Analytics 画面ではエンジン温度、エンジン回転数、油圧、燃料残量などの時系列チャートをリアルタイムに描画します。 デモ全体のアーキテクチャは、実機・エッジ・クラウドの 3 層で構成されています。実機側には ESP32 を搭載した掘削機の模型と、NVIDIA Jetson Orin Nano とカメラを組み合わせたエッジ推論環境があり、クラウド側では AWS IoT Core 、 AWS IoT SiteWise 、 AWS Lambda 、 Amazon DynamoDB を中心としたデータ基盤の上に、 Amazon Bedrock AgentCore と Strands Agents によるエージェント層を構築しています。詳細は後述します。 設計の考え方 デモの各機能を紹介する前に、設計にあたって重視した 2 つの考え方を説明します。なお、本デモの考え方は AWS Summit Japan 2026 のセッション「情報を集め、判断し、行動する時代へ:データ基盤・AI エージェント・エッジ AI で変わる製造現場」(IND327) でも解説しています。セッション資料は こちら からダウンロード可能です。 データにコンテキストを付与する センサーから届く生データは、センサー ID、タイムスタンプ、値、単位といった情報しか持ちません。「75.3 ℃」という値だけでは、それがどの現場の、どの機体の、どの部品の温度なのかが分からず、AI はもちろん人にも意味のある判断ができません。どの機体か、どの部位か、どの機種かといったコンテキストをデータに付与 (エンリッチ) して初めて、その値を「この機種の冷却系としては高すぎる」と解釈できるようになります。データの質と流れが AI の判断力を決める、というのが本デモの土台にある考え方です。本デモでは AWS IoT SiteWise のアセットモデルで機体・部位と計測値の関係を構造化し、エージェントが参照するテレメトリに機体のコンテキストが伴う状態を作っています。 人間と AI の役割分担を設計する AI を組み込んだシステムには、ルールベースの自動化、AI による支援、ゴール駆動型エージェントとの協働、完全自律型のエージェントというように、自律性の異なる段階があります。どの段階を採用するかは、対象業務のリスクと複雑性に応じて設計するものであり、既存のプロセスを単に AI に置き換えれば良いわけではありません。本デモの 3 種類のアラート(人手・古典的 ML・エージェント)は、後半に向けて自立度が高くなります。またデモ全体を通して、異常の検知や分析に必要な情報収集はエージェントが担い、機械を止めるか、現場に作業員を派遣するかといった判断は人間が行う、という役割分担で設計しています。 予知保全の 3 つのアプローチ 本デモの中心は、同じフリートに対する 3 つの異常検知アプローチの比較です。 人手による報告(Alerts – Human Driven) 最も基本的な形態として、現場の作業者が観察した異常を手動で報告するフォームを用意しました。機械、深刻度、タイトル、詳細を入力して起票します。人の観察は「油圧ポンプから変な音がする」といった、センサーには現れにくい定性的な情報を含む点で価値がありますが、報告のタイミングと粒度が人に依存し、状態を定量的に捉えて比較・追跡することができません。フリートが大きくなるとスケールしないという限界もあります。 古典的な機械学習(Alerts – Classical PM) 次の段階として、Amazon SageMaker AI 上に構築した古典的な機械学習パイプラインによる異常検知を実装しました。このパイプラインは、正常運転時のテレメトリから学習したモデルで各機体を継続的にスコアリングし、平常時からの逸脱が大きいときにアラートを発報します。デモの画面では、フリート 20 台それぞれの異常スコアと、予測値と実測値の乖離をチャートで確認できます。異常が進行している機体では、エンジン温度の実測値がモデルの予測レンジから外れていく様子が見て取れます。このアプローチはスケールし、人の観察より早く統計的な逸脱を捉えられます。一方で、アラートに含まれるのは異常スコアという数値だけで、原因や対処までは示されません。異常が起きていることは検知できても、なぜ起きているのかは説明できない。この点が古典的な機械学習による予知保全の限界であり、次のエージェント型アプローチが価値を発揮するところです。 エージェント型予知保全(Alerts – Agentic PM) エージェント型の予知保全では、Amazon Bedrock AgentCore と Strands Agents で構築した AI エージェントがテレメトリを監視し、異常を検知した際に原因分析と推奨アクションを含むアラートを生成します。たとえばデモでは「エンジン温度 95.2 ℃ と油圧低下 48.5 PSI の組み合わせはエンジン故障が差し迫っているリスクを示している。ただちに掘削機を停止し、点検を実施すること」といった、複数のテレメトリを組み合わせた解釈と具体的な対処指示を含むアラートが発報されます。単一メトリクスの閾値超過ではなく、エンジン温度と油圧の同時異常からオイルシステムの問題を推定するといった、保全担当者が行う推論に近い分析が行われる点が古典的 ML との違いです。アラートを受け取った担当者は、原因の調査から始めるのではなく、提示された分析と対処の妥当性を確認するところから対応を始められます。 もうひとつの特徴は、アラートルールの管理を自然言語で行える点です。「エンジン温度が 90 ℃ を超えたら警告して」「燃料レベルのアラートを無効化して」といった指示を入力すると、エージェントが予知保全モニターの使用するルールを更新します。閾値の調整のたびに設定画面を操作したりコードを変更したりする必要がなく、運用者の意図を直接ルールに反映できます。アラートの感度調整は運用を続けながら繰り返し行う作業であるため、この調整を運用者自身で完結できることは運用負荷の軽減につながります。 検知から対処までをエージェントで支援 異常の検知は保全業務の入口にすぎません。本デモでは、検知の後工程である診断、起票、通知、対話までをエージェントで支援する構成としました。 チケットの起票と AI 分析 アラートが発報された後のチケット起票は、人間が行います。担当者はアラート画面からエージェントに原因と対応策の分析を指示します。アラートはアラート画面で管理しますが、メールや SMS で通知することも可能です。人間から指示を受けた後、エージェントはマニュアルやテレメトリデータを自動で収集し、原因の特定と現場作業員向けの作業指示を作成します。チケットサービスはデモ内に MCP 経由で接続されており、担当者は分析結果を確認したうえで、アラート画面からそのままチケットを起票できます。起票されたチケットには、エージェントの分析結果が日本語で付与されます。たとえば「掘削機 001 はエンジン冷却水温度が 94.7 度と高く、C62 および C65 のオーバーヒート関連の故障診断コードが検知されています」といったように、テレメトリの値と診断コードを突き合わせた診断が記載されます。 異常の検知と、分析に必要な情報の収集はエージェントが行い、現場に作業員を派遣するかどうかの判断とチケット起票は人間が行う — このように分担することで、複雑な現場保全を効率的に進められます。分析にあたってエージェントは、後述する Knowledge Base を検索し、機器マニュアルや診断コードの定義を参照します。テレメトリ (定量データ) と技術文書 (定性情報) を組み合わせて、状況を総合的に判断させています。チケットには深刻度とステータスが付与され、Ticketing 画面で一覧・検索できます。診断コードの意味をマニュアルで調べるという一次診断と、機体名やテレメトリ値の転記が不要になるため、担当者の作業は分析内容の確認と派遣の判断に絞られます。また分析結果が日本語で記載されるため、現場の担当者がそのまま読んで対応に移れます。 Knowledge Base による技術文書の検索 Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless で、機器マニュアル、診断コード一覧、保守手順書を検索できるナレッジベースを構築しました。「掘削機のオーバーヒートに関する診断コードは何か」「油圧ポンプの交換手順は」「緊急停止の手順は」といった質問に、文書に基づいた回答を返します。このナレッジベースは、チケット起票時の AI 分析と、次に述べる音声通知の両方から参照されます。 Amazon Connect による音声通知 検知と診断の結果を現場のオペレーターに届ける手段として、 Amazon Connect による架電機能を実装しています。エラーコードを指定すると、エージェントが Knowledge Base からトラブルシューティング手順を検索し、その要約を Text-to-Speech で読み上げる電話をオペレーターにかけます。同じ内容はメールでも送付されます。ダッシュボードを見ていない現場の担当者にも、異常の内容と初動手順が音声で届くという体験です。 双方向の音声対話 通知にとどまらず、AI エージェントとオペレーターがリアルタイムに双方向で会話する音声対話も実装しています。エージェントは対象機体のライブテレメトリと診断結果のコンテキストを保持した状態で通話するため、オペレーターからの質問に答え、トラブルシューティングを対話的にガイドし、必要に応じてエスカレーションできます。一方向の読み上げと異なり、手順の途中で生じた疑問にその場で答えられるため、担当者への折り返し確認を減らせます。音声対話の基盤には Amazon Nova Sonic を利用しています。 AI Assistant これらの機能とは別に、フリート全体を対象としたチャット形式の AI Assistant も用意しています。Strands Agents によるマルチエージェント構成で、「フリートの状態は?」「掘削機-001 を診断して」「掘削機-003 のテレメトリを読んで」といった問い合わせに対し、フリート状態の照会、機体診断、ドキュメント検索を担当するエージェントが連携して回答します。現場の作業員はタブレットやスマートフォンからこのアシスタントを利用でき、展示ではエンジン温度が異常に高い機体への対応方法を質問する流れを紹介しました。診断コードやマニュアルの知識を持つ熟練者でなくても、その場で対応方法を引き出せることがこの機能の狙いです。 エッジと実機 クラウド側の機能に加えて、実機とエッジ推論を組み合わせた構成も実装しています。なお、今回の展示ではこの部分のデモフローは割愛しました。以下では、実装した構成を紹介します。掘削機の模型には ESP32 を搭載し、モーター、センサー、LED を MQTT で AWS IoT Core に接続しています。掘削機制御画面からは走行、キャビン旋回、アームの上下、非常停止(E-STOP)を遠隔操作でき、掘削機の状態は Unreal Engine で構築した 3D デジタルツインに反映されます。エッジ推論としては、NVIDIA Jetson Orin Nano 上で YOLO による物体検出と VLM(Vision Language Model)を組み合わせ、映像から安全に関わる状況をエッジ側で判定する構成を実装しました。また、 Amazon Kinesis Video Streams 03:06 PM と WebRTC による低遅延のライブ映像配信の上で、Amazon Bedrock による映像分析を行う構成も実装しています。「機材の近くに人が近づいたら通知して」のように監視条件を自然言語で定義でき、条件に合致するイベントが検出されると指定の方法で通知されます。この構成では、人の接近検知のような安全に関わる即時判断を Jetson 上のエッジ推論が担い、フリート全体の分析や診断をクラウド側のエージェントが担う分担を想定しています。 アーキテクチャ詳細 最後に、デモ全体のアーキテクチャを整理します。 データ基盤の層では、掘削機のアセット情報を AWS IoT SiteWise で管理し、実機からのテレメトリは MQTT で AWS IoT Core に取り込み、機体状態を Amazon DynamoDB に保持します。アラート、チケット、チャット履歴もそれぞれ DynamoDB のテーブルで管理し、生成・更新の処理は AWS Lambda と AWS Step Functions で実装しています。 エージェント層は Strands Agents で実装しています。アシスタント、シナリオ、ナレッジベース検索、チャット履歴といったエージェントは AWS Lambda(コンテナ)上で稼働し、音声対話エージェントは Amazon Bedrock AgentCore 上で稼働させています。エージェントから AWS IoT SiteWise などの OT/IT システムへのアクセスは MCP(Model Context Protocol) サーバーを介して行い、エージェントは目標に応じて必要なツールを自律的に選択・実行します。AgentCore はランタイム管理、認証、メモリ、可観測性といった、エージェントを本番運用するための基盤機能を提供します。ナレッジベースは Amazon Bedrock Knowledge Bases と Amazon OpenSearch Service で構成し、音声対話には Amazon Nova Sonic を利用しています。音声通知は Amazon Connect、メール等の通知は Amazon SNS が担います。 フロントエンドは Amazon CloudFront と AWS WAF を通じて配信し、認証には Amazon Cognito を利用しています。リアルタイム性が求められるテレメトリ配信には Amazon API Gateway の WebSocket API を、その他の操作には REST API を使い分けています。映像系は Amazon Kinesis Video Streams、地図表示は Amazon Location Service です。 まとめ 「産業機械の自律診断とリアルタイム安全監視」デモでは、建機フリートの予知保全を題材に、人手による報告、古典的な機械学習、生成 AI エージェントという 3 つのアラート発火のアプローチを比較できる形で実装しました。古典的な機械学習が「異常の検知」を担い、エージェントが「原因の分析と対処の提示」、さらに「起票・通知・対話」までを担うという役割分担は、製造業や建設業における保全業務の実務に近い形で生成 AI を組み込む際のひとつの参考になると考えています。さらに、検知後に人が担っていた調査・起票・連絡といった作業をエージェントに任せることで、担当者は判断と実際の対処に集中できるようになります。 本記事で紹介した構成の多くは、標準的な AWS サービスの組み合わせで実現しています。自社の設備データへの適用をご検討の際は、ぜひ AWS の担当ソリューションアーキテクトにご相談ください。 著者 新澤 雅治(Niizawa Masaharu) — IoT Specialist Solutions Architect。製造業、IT 企業を経て AWS に入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 深澤 真愛(Fukasawa Mana) — Solutions Architect。入社以来、製造業を中心に、様々な業界のお客様の AI 活用やデータ活用の技術的支援に携わる。

2026 年 7 月 20 日週、私のチームは AWS Korea User Group (AWSKRUG) のリーダーの皆さんに会うためにソウルを訪問しました。AWSKRUG は韓国最大のクラウド開発者コミュニティで、トピックや領域ごとに 20 のミートアップグループが設けられ、主にソウルを中心に毎年 100 以上のイベントが開催されています。 私のチームは定期的にアジア太平洋地域の国々を訪問し、ユーザーグループのリーダーからのフィードバックに耳を傾け、コミュニティの支援に取り組んでいます。今回の会議では、リーダーの皆さんから、上半期の成果、改善が必要な点、AWS Developer Experience チームへの要望について率直な意見を共有していただきました。また、一緒に チメク を囲んで和やかな会話を楽しみました。 それでは、 7 月 20 日週の主なリリースを詳しく見ていきましょう。 7 月 20 日週、最も目を引いたのは、 コーディングエージェント向けのワンクリック Lambda セットアッププロンプト です。このプロンプトを使用すると、AWS サーバーレススキルとサーバーレスモデルコンテキストプロトコル (MCP) サーバーをエージェントに設定し、サーバーレスのベストプラクティスを初めから組み込むことができます。このプロンプトでは、Claude Code、Kiro、Cursor、GitHub Copilot、Codex、Devin Desktop、および OpenCode のインストールコマンドを含む、Lambda エージェントセットアップガイドが参照されます。 開始するには、Lambda コンソール画面で [エージェントプロンプトをコピー] ボタンを選択するか、 fetch https://docs.aws.amazon.com/lambda/latest/dg/samples/aws-lambda-agent-setup.md を直接コピーして、この URL を任意の AI エージェントに貼り付けます。 Agent Toolkit for AWS を使用して、コーディングエージェントに AWS に関する最新の知識とリソースへの安全なアクセスを提供することもできます。AWS MCP サーバーのインストールには fetch https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md を使用してください。  7 月 20 日週のリリース 7 月 20 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Bedrock での OpenAI GPT-5.6 Sol、Terra、Luna : 高いパフォーマンス、セキュリティ、信頼性を実現するように構築された Bedrock の次世代推論エンジンで、OpenAI のこれまでで最もスマートなモデルファミリーを使用できます。この 3 つのモデルは、主力級の推論 (Sol)、バランスの取れたパフォーマンス (Terra)、高速でコスト効率の高い推論 (Luna) という異なる機能階層があり、すべて Amazon Bedrock の Responses API からアクセスできます。 Amazon S3 Standard-IA および S3 One Zone-IA への即日移行 : S3 Standard の 30 日間の最小保持期間が撤廃され、作成日にすぐに S3 Standard 低頻度アクセス (S3 Standard-IA) と S3 One Zone 低頻度アクセス (S3 One Zone-IA) にオブジェクトを移行できるようになりました。これらのストレージクラスは、S3 Standard よりもストレージコストを最大 40% 低く抑えながら、必要に応じてミリ秒単位でアクセスできるため、データが数時間または数日でコールドデータとなるバックアップ、ログ分析、コンプライアンスワークロードに最適です。 AWS Lambda でのセルフマネージド型コードストレージ : コードストレージにセルフマネージド型 Amazon S3 バケットを使用すると、Lambda によって中間コピーを作成することなく、独自の S3 バケットからソースコードを直接参照できます。コピーステップが不要になることで、コードストレージの制限がなくなり、関数の作成と更新後の関数のアクティブ化時間が短縮されます。 Amazon Cognito でのパスワードハッシュを含むユーザーのインポート : CSV ユーザーインポートでパスワードハッシュを含めてユーザーをインポートできるようになりました。これまでは、インポートされたユーザーは最初のサインイン時にパスワードをリセットする必要がありました。CSV インポートにパスワードハッシュを含めることができるようになったため、ユーザーは既存の認証情報ですぐにサインインできます。CSV インポートを作成するときに、ソースシステムで使用されるパスワードハッシュアルゴリズムを指定します。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんが興味を持つと思われるその他のニュースをいくつかご紹介します。 Amazon SQS が誕生 20 周年に: 大規模かつ信頼性の高いメッセージングを支えてきた 20 年間 : 2006 年 7 月に Amazon SQS の一般提供が開始されると、このパターンは AWS のすべてのお客様にご利用いただけるようになりました。20 年経った今でも、プロデューサーとコンシューマーを分離するというその中核的な機能こそが、お客様が SQS を使用する理由となっています。 Jeff の 15 周年記念の記事 投稿以降の重要なマイルストーンを振り返ってみましょう。 Strands Agents SDK でのオープンプロトコル : MCP、A2A、UTCP、AG-UI、x402 といったオープン AI プロトコルがどのように連携して AI エージェントを構築するのかを Strands Agents SDK を実装例として用いて説明します。なお、これらのパターンはどのエージェントフレームワークにも適用できます。 オープンソースの Bulk Executor for Amazon DynamoDB : これまでは、テーブルのすべての項目に対して一括操作を実行するにはカスタムコーディングが必要でした。 Bulk Executor for DynamoDB を使用すると、このような一括タスクが簡略化されます。この機能を使用して、 count 、 find 、 delete 、 update などのコマンドを呼び出すことができます。大規模に実行する場合でも、コーディングは不要です。 Kiro CLI による AWS サポートケースワークフローの変革 : Kiro CLI の MCP 統合により、AWS Glue ジョブの失敗、AWS Lambda コールドスタートの調査、AWS WAF の誤検知分析という 3 つの実際のシナリオにおいて、調査、ドキュメントのルックアップ、ケースの作成を単一の対話型インターフェイスにまとめることで、サポートケースワークフローを加速させる方法を説明します。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS について詳しく学び、次に予定されている AWS 主催の対面イベントとバーチャルイベント 、 スタートアップイベント 、 AWS Summits などの 開発者向けイベント を調べて参加しましょう。 AWS Builder Center にもご参加ください。ビルダーとつながり、ソリューションを共有して、開発をサポートするコンテンツにアクセスできます。 最後に、 7 月 20 日週末に一部のお客様において、 Cost Explorer で不正確な請求見積データが表示される 問題が発生しました。これにより、予算とコストに関する誤った異常検知アラートが通知されたり、見積コストと使用量データが実際より高く表示されたりした可能性があります。この問題は解決され、すべての AWS サービスが正常に動作しています。このインシデントによりお客様にご心配をおかけしたことをお詫び申し上げます。このようなイベントの再発を防ぐため、また請求インシデントが発生した場合の対応を改善するために、徹底的な事後調査を実施しています。詳細については、 AWS Health Dashboard にアクセスしてください。 2026 年 7 月 20 日週のニュースは以上です。7 月 27 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの呉(オ)です。 2026 年 6 月 11 日（木）〜 12 日（金）の 2 日間、AWS の拠点にて、9 社 11 チーム・約 90 名のお客様と一緒に AI-DLC Unicorn Gym（AI 駆動開発ライフサイクルを体験する実践型ワークショップ）を合同開催しました。参加各社が「自社の実際の業務課題」を持ち込み、Kiro と Claude Code を使って、ユーザーストーリーの作成からモック、実装、成果発表までを走り抜ける 2 日間です。 本記事では、複数社が同時に自社ワークロードで AI 駆動開発を体験したこの合同開催で何が起きたのか、どんな成果と気づきが生まれたのかをレポートします。 AI 駆動開発ライフサイクル（AI-Driven Development Lifecycle, AI-DLC）とは AI-DLC は、AI を開発プロセスの中心に据える開発手法です。AI をアシスタントとして後から付け足すのではなく、AI が実装を担い、人間は「何を作るか」「その出力は正しいか」を判断することに集中します。 プロセスは大きく 3 つのフェーズで構成されます。 Inception（インセプション）：解くべき課題を定義し、ユーザーストーリーへ分解する Construction（コンストラクション）：AI と対話しながら並行して実装する Operation（オペレーション）：運用・改善につなげる 特徴的なのは、「モブ」と呼ばれる進め方を重視する点です。モブとは、チーム全員が 1 つの画面を囲み、一人が操作役（ドライバー）となって手を動かしながら、残りのメンバー全員が意見を出し合い、その場で議論して進める共同作業のスタイルです。役割を固定して分業するのではなく、全員が同じ情報を見て一緒に考えることで、認識のズレを防ぎ、判断の質を高めます。AI-DLC では、要件を練り上げる Inception を全員で行う「モブエラボレーション」、実装を全員で進める Construction を「モブコンストラクション」と呼び、いずれもこのモブを基本形とします。Unicorn Gym ではこのプロセスを座学ではなく、自社の実テーマで 2 日間走り切ることで体で覚えていただきます。AI 駆動開発ライフサイクルの詳細については、 AI 駆動開発ライフサイクル：ソフトウェアエンジニアリングの再構築  をご参照ください。 9 社 11 チームが持ち込んだテーマ 今回集まったのは、事業ドメインの異なる 9 社でした。BtoB の卸・仕入れサイトや企業間決済・売掛保証サービスを展開するラクーン（ラクーンホールディングス）と、キャラクタービジネスで知られるサンリオは、それぞれ 2 チームで臨み、全体では 11 チームが同じ会場に机を並べました。DX 現場支援を強みとするメンバーズ、幅広い業界のシステム開発を担うテクノブレイブ・ニーズウェル・科学情報システムズ（SIS）、大手企業の DX 内製化を支援する情報戦略テクノロジー、法務業務を効率化するリーガルテックの GVA TECH、そしてコンビニ ATM 最大手のセブン銀行です。B2B プラットフォーム、エンターテインメント、システム開発、リーガルテック、金融と、まったく異なる事業領域のプレイヤーが一堂に会したことになります。 参加各社は、練習用の題材ではなく「今まさに解きたい実課題」を持ち込みました。テーマは、新規サービス機能の立ち上げ、社内基幹システムへの機能追加、営業支援、提案書ドラフトの自動生成、ピープルマネジメントなど多岐にわたります。 Day 1: Inception 「まず何を作るか（作らないか）を決める」 初日の午前は、いきなり自社テーマに入るのではなく、まず AI-DLC の考え方の説明と共通題材を使ったハンズオンから始めました。Kiro の操作感やユーザーストーリーからモック作成、実装へと進める一連の流れを、全員が同じ題材で一度体験します。この助走を挟んでから本番に臨みました。チームは、各社が自社の PdM（プロダクトマネージャー）とエンジニアで編成しました。実際に手を動かして議論を主導するのはお客様自身で、AWS のメンバーは技術的に詰まったところの解消やフェーズの進め方のガイドに徹し、チームの自走を後押しする役に回りました。 午後からは、各チームが自分たちのテーマをユーザーストーリーへ分解する Inception に本格的に取り組みました。ここで多くのチームが口を揃えたのが、「まず対象を決めることに時間をかけたのが効いた」という気づきです。実装が速いからこそ、入口の「何を作るか」が成果を左右します。象徴的だったのは、「どこまで作るか」を大胆に絞り込んだチームです。セブン銀行のチームは、洗い出したユーザーストーリー 29 件のうち 13 件をその場でカットし、初日のうちに 16 件まで絞り込みました。サービスデザインの視点から参加したメンバーは、「どこまでを人間が決め、どこからを AI に委ねるか」という線引きこそが今回の一番の学びだったと振り返ります。スコープを決めるのは、あくまで人間の仕事だという実感です。その「人間が決める」を象徴する場面もありました。ラクーンのチームでは、AI がある機能を「マストだ」と提案してきました。しかし、同チームではその機能は当面手動運用でカバーできると割り切り、AI が「マスト」とした機能をあえて優先度の低い区分へ格下げしました。AI の提案をそのまま鵜呑みにするのではなく、事業の文脈を踏まえて人間が最終判断を下す、Inception ではこうした「AI が提案し、人間が決める」という役割分担が随所で見られました。また、AI にインタビューされながらユーザーストーリーを固めることで、リリース後の不正対策といった人間だけでは抜け落ちがちな観点まで AI が先回りして拾う場面も見られました。 各チームの開発風景（サンリオ／ニーズウェル／科学情報システムズ／セブン銀行） Day 2: Construction 「動くものを見ながら、その場で会話する」 2 日目は、並行して実装できるサブチームに分かれて実装を進め、最終成果発表へ向かいます。参加チームから最も多く声として挙がった一番の価値は、「動くものを見ながら、ビジネス側と開発側がリアルタイムに会話できたこと」でした。従来は、要望を伝えてから次のバージョンが上がってくるまで数週間のタイムラグがありました。それがこの 2 日間では目の前で動く成果物を見ながらその場で方向を変えられる、このフィードバックの即時性が多くのチームで共通の手応えになりました。一方で、AI が高速に生成物を出すぶん、「その出力が正しいかを判断し続ける」負荷が人間側に集中する、という声も複数上がりました。「もっともらしいコードがすぐ出るからこそ、正しさの見極めが難しい」「判断の連続で頭は疲れるが、面白い」「AI に任せるほど、人間の判断力が試される」 など、その手応えと難しさの両方を体感する時間でもありました。成果発表では、各チームが 2 日間で作り上げたものを発表しました。完成までたどり着いたチームや実装ゼロで並行開発の設計に振り切ったチーム、アプローチは様々でしたが、いずれも自社に持ち帰る具体的な手応えを掴んでいました。 各チームによる Day 2 成果発表の様子 各チームのハイライトとお客様の声 成果発表で各チームが見せてくれた成果から、印象的だったものを紹介します。 新規アプリの運営管理画面に取り組んだチームは、「Kiro は 1ヶ月と見積もった。私たちは 2 日で 80% 終わった」と話します。Kiro が当初約 1 ヶ月と見積もった開発を 2 日間で 8 割完成させ、自社ドメインの実サブドメインへのデプロイまで到達しました。後回しにされがちな運営管理画面のような領域こそ、AI に任せることで一気に前へ進むという手応えが語られました。 既存の社内管理システムに操作履歴機能を追加したチームは、「2 ヶ月の開発が 2.5 日で見通せる可能性がある」と振り返ります。AI による既存ソースコードの読み込み精度の高さに驚き、従来 2 ヶ月相当の開発が 2.5 日で見通せる感触を得ていました。同時に「手戻り＝悪」という常識が覆り、「戻りやすさを設計しておけば、手戻りコストは構造的に低い」という発想の転換も語られました。 営業支援システムに取り組んだチームからは、「数人で数ヶ月分の差分が 1 日弱で出せた」という声が上がりました。実際に 1 日弱で約 14,000 行の差分を生成し、非エンジニアの責任者と事業ドメインの観点で議論できたことが最大の収穫だったと振り返ります。 5 人・5 台の PC で誰も 5 分以上手を止めない並行開発とコードを一切書かず AI とエンターキーだけで進めるという 2 つに取り組んだチームからは、「合意と設計に投資したら、コンフリクトはゼロになった」という言葉が生まれました。初日から 2 日目の午前まで一行もコードを書かず、全員が並行開発できる構造の設計に投資した結果、コンフリクトゼロで並行実装を走り切っています。クロージングの一言「Don’t write code, Write construct.（コードを書くな、構造を作れ）」は、AWS メンバーにも印象的でした。 商品企画出身の PdM が、「生まれて初めてプルリクエストを送れました」と語る場面も生まれました。AI との対話を通じて人生で初めて Pull Request (PR) を送り、さらに Inception のスキル化（AI がインタビューしてユーザーストーリーとドキュメントを生成し、PR でマージする仕組み）まで自作して再現性も確保していました。 これらの成果に加えて、合同開催ならではの声もありました。 「他社さんと一緒に取り組めたのがとても刺激的でした。発表で各社のドメインがにじみ出て、自社への適用イメージがどんどん湧きました。」「開発生産性がかなり上がることを実感しました。お客様への提供スピードが上がるので、ビジネスインパクトの面でも有意義でした。」「プロダクトを AI-DLC で作る経験ができて、純粋に楽しかったです。」 ポジティブな声だけではありません。 「判断の連続で疲れた」「AI に情報を渡し忘れ、AI が置いてけぼりになった」「既存システムの拡張は、作るべき範囲の議論が複雑になる」。こうした率直な気づきも、次に活かすための貴重な学びとして共有されました。 2 日間で見えた手応え 2 日間を通じて、参加各社が共通して手応えを感じたのは次の点でした。 動くものを見ながら、ビジネスと開発がリアルタイムに会話できること AI による既存コードの読み込み精度の高さ（レガシー資産の棚卸しに有効） 音声入力がタイピングより圧倒的に速いこと Inception をスキル化し、再現性と抜け漏れ防止を両立できること 合意形成と設計に投資すれば、コンフリクトゼロの並行開発が実現できること いずれも、「AI を開発の中心に据える」という進め方だからこそ生まれた実感です。 イベント後のアンケートでは、満足度は 5 点満点中 4.7 点、93.9% の参加者が肯定的な評価（4 点以上）を寄せています。また、体感された工数削減率は平均 74.0% にのぼりました。なお、継続して伴走支援を受けたいという声も多く寄せられ、この 2 日間が終わりではなくそれぞれの現場での始まりとして受け止められたことがうかがえます。 おわりに この 2 日間で最も印象的だったのは AI が実装を肩代わりするほど、人間の仕事が「書くこと」から「決めること」へと移っていく、という共通の実感でした。参加各社は、それぞれのドメインでその手触りを掴んで帰っていきました。そして、複数社が同じ場で真剣に取り組む合同開催だからこそ、互いの成果が刺激となり、自社でもできるという確信が生まれました。AWS はこうした AI 駆動開発への挑戦を、これからも各社の現場に寄り添いながら伴走していきます。 自社のワークロードで AI-DLC を試してみたい、という方は、ぜひお近くの AWS 担当者までお声がけください。AI-DLC に興味を持たれた方は、 aidlc-workflows  をチェックしてみてください。Kiro や Claude Code などを使って AI-DLC を始めるためのワークフローやテンプレートが公開されています。 集合写真 著者 Oh Minjung （オミンジョン） AWS Japan のソリューションアーキテクト。お客様のクラウドジャーニーにおける技術的なご支援をしています。その活動の傍ら、最近は AI 駆動開発ライフサイクル(AI-DLC) の布教活動をしています。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 AWS Summitが終了し、各チームからはAWSブログを通じて、より詳しい解説が公開されています。ぜひチェックしてみてください。 私が所属する流通小売事業部のブースでは、飲食店舗などで活用できるソリューションとして、AmiVoiceと連携したデモを出展しました。こちらは、AmiVoiceを提供されているアドバンスト・メディア様との共著でブログ「 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション 」として公開しています。 飲食店舗に限らず、「音声認識 × Agentic AI」を検討されている方にとって参考になる内容ですので、ぜひご一読ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月13日週の主要なアップデート 7/13(月) Amazon SageMaker HyperPod が Slurm クラスターでカスタム AMI をサポート Amazon SageMaker HyperPod が､Slurm でオーケストレーションするクラスターでカスタム AMI (Amazon Machine Image) を利用できるようになりました｡ユーザーは HyperPod の性能最適化済みベース AMI をもとに､セキュリティエージェントやコンプライアンスツール､専用ライブラリ､ドライバーをイメージに組み込めます｡これまでライフサイクル設定スクリプトで起動後に実行していたセットアップ処理を AMI 側に取り込めるため､クラスターの起動時間を短縮でき､ノード間の構成の不整合を抑えられます｡カスタム AMI は CreateCluster / UpdateCluster / UpdateClusterSoftware の各 API で指定でき､HyperPod がサポートするすべての AWS リージョンで利用できます｡ OpenAI privacy-filter による PII 検出とマスキングが Amazon SageMaker JumpStart で利用可能に OpenAI が開発した PII 検出･マスキング用モデル privacy-filter が Amazon SageMaker JumpStart で利用できるようになりました｡テキスト中の個人識別情報 (PII) を検出する双方向トークン分類モデルで､1 回の forward pass で入力全体にラベルを付与します｡アカウント番号･住所･メールアドレス･氏名･電話番号･URL･日付･secret の 8 カテゴリを検出できます｡SageMaker Studio の Models セクションまたは SageMaker Python SDK から数クリックで自分の AWS アカウントにデプロイでき､データサニタイズ (無害化) のワークフローを構築できます｡ Voxtral-Mini-4B-Realtime をリアルタイム音声文字起こし向けに Amazon SageMaker JumpStart で提供開始 AWS は Mistral AI のリアルタイム音声文字起こしモデル Voxtral-Mini-4B-Realtime-2602 を Amazon SageMaker JumpStart で利用できるようにしました｡ このモデルは音声を逐次処理するストリーミングアーキテクチャを備え、500ms 未満の遅延で文字起こしを出力できます｡ 13 言語に対応し、文字起こしの遅延を 240ms から 2.4s の範囲で設定してレイテンシと精度のバランスを調整できます｡ SageMaker Studio の Models 画面または SageMaker Python SDK から数クリックで自分の AWS アカウントにデプロイできます｡ Gemma-4-E2B-it が Amazon SageMaker JumpStart で利用可能に AWS は 2026 年 7 月 13 日に､ Google DeepMind の gemma-4-E2B-it を Amazon SageMaker JumpStart で提供開始しました｡ このモデルはテキスト･画像･音声を入力として受け取り､ テキストを出力するマルチモーダルの指示調整済みモデルです｡ ステップごとに思考する reasoning モードを内蔵し､ 有効パラメータ 2.3B (埋め込み込みで 5.1B) という小型構成でエッジ寄りの効率的な実行に最適化されています｡ SageMaker Studio の Models セクションまたは SageMaker Python SDK から数クリックでデプロイできます｡ OpenAI GPT-5.6 Sol、Terra、 Luna が Amazon Bedrock で一般提供開始 OpenAI の GPT-5.6 ファミリー (Sol、Terra、Luna) が Amazon Bedrock で一般提供 (GA) されました｡3 モデルはフラッグシップの推論特化 (Sol)、バランス型 (Terra)、 高速低コスト型 (Luna) という 3 階層で構成され、いずれも `bedrock-mantle` エンドポイント上の Responses API 経由で利用します｡コンテキストウィンドウは 272K トークンで、prompt caching により再利用コンテキストのキャッシュ読み取りが 90% 割引になります｡料金は OpenAI の first-party レートと同等で、 利用額は既存の AWS コミットメントに算入されます｡ 7/14(火) AWS Security Hub が組織全体の AI アセットを可視化する AI インベントリの提供を開始 AWS Security Hub に AI インベントリ機能が追加されました｡ この機能は組織全体の AI アセット (エージェント､ モデル､ パイプライン) を継続的に検出し､ そのセキュリティ状態を中央のセキュリティチームが確認できるようにするものです｡ 検出は AWS Config リソース､ Amazon Inspector の SBOM 分析､ Amazon GuardDuty の DNS テレメトリという 3 つの方法で自動的に行われます｡ 検出された各アセットは基盤インフラにマッピングされ､ GuardDuty の脅威検出を含むセキュリティ検出結果と関連付けられます｡ この機能は Security Hub Essentials に含まれ､ 追加費用はかからず､ 新たな有効化操作も不要です｡ Amazon GuardDuty AI Protection を発表 (AWS AI ワークロード向け脅威検知) Amazon GuardDuty に AI Protection が追加され、 Amazon Bedrock と Amazon SageMaker AI のワークロードを対象とした脅威検知に対応しました｡CloudTrail の管理イベントとデータイベントを解析し、 異常なモデル呼び出し、 コストハーベスティング攻撃、 プロンプトインジェクションの 3 種類を検出します｡検出結果は AWS Security Hub に集約され、 AWS Organizations で組織全体に一元的に有効化できます｡GuardDuty 利用者は 30 日間の無料トライアルで利用を開始できます｡ AWS Lambda コンソールにコーディングエージェント向けワンクリックセットアッププロンプトを追加 AWS Lambda コンソールに､コーディングエージェントを 1 クリックでサーバーレス開発向けに構成するセットアッププロンプトが追加されました｡このプロンプトは AWS Serverless skills と Serverless Model Context Protocol (MCP) server をエージェントにインストールするよう指示します｡従来は複数のドキュメントを参照する必要があったエージェント設定の手間がなくなります｡Claude Code、 Kiro、 Cursor、 GitHub Copilot、 Codex、 Devin Desktop、 OpenCode の 7 種類のエージェントに対応します｡AWS GovCloud (US) を含む Lambda 提供リージョンで利用でき、 Middle East (Bahrain) と Middle East (UAE) は対象外です｡ 7/15(水) AWS Lambda が self-managed code storage に対応 AWS Lambda は､関数のデプロイパッケージをユーザー自身の Amazon S3 バケットから直接参照する self-managed code storage に対応しました｡従来 Lambda は関数や layer の作成時にコードを Lambda 管理ストレージへコピーしていましたが､`S3ObjectStorageMode` を `REFERENCE` に設定することでコピーを行わず S3 上のコードを直接参照します｡これによりコードストレージの上限が実質的に S3 バケットの容量まで拡張され､コピー処理が省かれるため関数の作成/更新後の有効化時間が短縮されます｡あわせて Lambda 管理ストレージのデフォルト上限が 75GB から 300GB per Region に引き上げられました｡self-managed code storage の利用に Lambda 側の追加料金は発生せず､S3 の標準料金のみが発生します｡ Amazon Cognito がパスワードハッシュ付きのユーザーインポートに対応 Amazon Cognito の CSV ユーザーインポートで、パスワードハッシュを含めてユーザーを取り込めるようになりました｡ 従来は CSV でインポートしたユーザーは初回サインイン時にパスワードリセットが必須でしたが、本機能によりインポート済みユーザーは既存の認証情報でそのままサインインできます｡ 対応アルゴリズムは bcrypt、scrypt、Argon2id、PBKDF2 with SHA-256 の 4 種類です｡ Amazon Cognito が利用可能な全 AWS リージョンで使えます｡ ただし、本機能のリリース前に作成された一部の user pool ではパスワードハッシュのインポートを利用できません｡ 7/16(木) Amazon S3 が S3 Standard-IA および S3 One Zone-IA への移行における 30 日間の最低保持期間を撤廃 Amazon S3 は､オブジェクト作成後 S3 Standard に 30 日間保持してから S3 Standard-IA および S3 One Zone-IA へ移行するという従来の制約を撤廃しました｡これにより S3 Lifecycle ルールで作成後 0 日 (作成当日) からこれらの Infrequent Access クラスへ移行できます｡両クラスは S3 Standard と比べて最大 40% 低いストレージコストで､必要時にはミリ秒単位でアクセスできます｡バックアップ､ログ分析､コンプライアンスなど数時間から数日で低頻度アクセスになるデータで効果があります｡なお､IA クラス自体の 30 日間の最低課金保持期間は引き続き適用される点に注意が必要です｡ AWS Sustainability に取水量 (water withdrawals) データを追加 AWS は AWS Sustainability サービスにおいて、従来の炭素排出量データに加え、ワークロードに関連する年間取水量 (water withdrawals) データを確認できるようにしました｡データは AWS リージョン別、サービス別、AWS アカウント別に年次で提供され、コンソールと API の両方から参照できます｡取水量はデータセンター運用のために取り込まれた水の総量を表し、効率改善は取水量の減少として反映されます｡このデータは対象リージョンすべてで追加料金なしに利用できます｡ Amazon S3 Event Notifications がシステム生成タグを含むように Amazon S3 Event Notifications が､ バケットに付与された system-generated tags (AWS サービスが自動付与するタグ) をイベントメッセージに含めるようになりました｡ 対応先は Amazon EventBridge､ Amazon SQS､ Amazon SNS､ AWS Lambda の全てです｡ これにより､ 数千個のバケットを個別に列挙せず 1 つの EventBridge ルールでタグを条件にイベントをフィルタリングできます｡ 追加料金はなく､ 全 AWS リージョンで利用でき､ 既存の設定変更も不要です｡ Billing and Cost Management Dashboards に Cost Efficiency ウィジェットを追加 AWS Billing and Cost Management (BCM) Dashboards に Cost Efficiency ウィジェットが追加されました｡コスト効率スコアの推移を、Cost Explorer、Budgets、Savings Plans/Reserved Instance のカバレッジ･使用率レポートと同じ 1 枚のダッシュボードで確認できます｡ウィジェットは Cost Optimization Hub のコンソールに直接リンクし、節約の推奨事項があればそのまま対処できます｡全ての AWS 商用リージョンで追加料金なしで利用できます｡ それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。今回は Kiro の公開 1 周年にあわせた記事群やAWS Summit Japan 2026 の開催報告など、盛りだくさんの内容です。 7 月 28 日（火）に「 AWS Bedrock LLM Day Japan 」が東京 赤坂インターシティにて開催されます。AWS Summit New York で発表された最新のサービスアップデートを日本のお客様向けにいち早くお届けするとともに、Amazon Bedrock 上での Anthropic・OpenAI モデルの活用法や、AI エージェント構築基盤 AgentCore の最新機能を実践的に解説します。ぜひご参加ください。 それでは 7月 13日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ「 株式会社村田製作所様の AWS 生成 AI 活用事例 : 3 万人利用の「Murata Coworker」を AI エージェント活用基盤へ進化させるまで 」を公開 株式会社村田製作所様による寄稿記事です。全社生成 AI プロダクト「Murata Coworker」は資料作成、翻訳、調査、社内データを活用した RAG/Agent などを統合的に提供し、累計約 3 万人が利用、1 人あたり月約 3 時間の工数削減などの効果が確認されています。この Murata Coworker を Amazon Bedrock AgentCore を中心とした AI エージェント活用基盤へ進化させる取り組みが紹介されています。社内外の知識をつなぐ Knowledge Hub やヘルプデスク業務を支援する ITSM Agent の実装に加え、AI エージェント特有のリスクを体系化したガイドライン、Amazon Bedrock のガードレール機能と NVIDIA NeMo Guardrails を組み合わせた二重構造、「人 → Agent → ツール/データ」の認可チェーン設計など、ガバナンスの実践例が具体的に語られており、AI エージェントの全社展開と統制の両立を検討している方の参考になる内容です。 ブログ記事「 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション 」を公開 株式会社アドバンスト・メディア様と AWS Japan の共同執筆記事です。AWS Summit Japan 2026 で展示した、セントラルキッチン（複数店舗向けの集中調理施設）の業務課題を音声 AI エージェントで解決するアーキテクチャを解説しています。AmiVoice による高精度な日本語音声認識、Amazon Bedrock AgentCore Runtime と Strands Agents SDK による AI エージェント、Amazon DynamoDB や AWS Lambda によるサーバーレスバックエンドを組み合わせ、「手を使わずにレシピを操作できる」ハンズフリーオペレーションを実現しています。調理中に手が塞がる環境でのデータ入力障壁は、食品製造に限らずホテル・医療・製造・物流など多くの業界に共通する課題であり、音声認識と AI エージェントを組み合わせたシステム設計の参考になります。 ブログ記事「 AI と一緒に進める AWS Well-Architected Framework レビュー のすすめ 」を公開 AWS Summit Japan 2026 の Well-Architected ブースで展示した、AI を活用して AWS Well-Architected Framework レビュー（WAFR）を加速する 3 つのアプローチを紹介する記事です。Amazon Quick のチャットエージェント機能を活用して構築する Well-Architected Quick Advisor、Kiro や Claude Code などのコーディングエージェントに Well-Architected の知識を組み込むサンプルスキル・ステアリング集、そして IaC ファイルや設計書を生成 AI で自動レビューする Well-Architected IaC Analyzer です。「フレームワークの内容を理解するのが難しい」「時間がなくてレビューを実施できない」という悩みに対してレビューのハードルを下げる具体的なツールが揃っており、チームの状況に合わせて始めやすいものから取り入れられます。 ブログ記事「 Amazon Bedrock における LLM コストの最適化：請求の帰属から運用テレメトリまで 」を公開 Amazon Bedrock 上の LLM コストを可視化・最適化するための 3 層のオブザーバビリティフレームワークを解説する翻訳記事です。AWS IAM と AWS Cost and Usage Report（CUR）を用いたネイティブな請求の帰属、モデル呼び出しのログ記録、OpenTelemetry によるアプリケーションレベルのテレメトリを段階的に積み重ねる構成で、Kiro や Amazon Q Developer、Claude Code、Cursor、カスタムアプリケーションのいずれにも対応します。あわせて、モデルの切り替えやキャッシュ効率の改善など、ワークロードに応じて支出を 30〜50% 削減できる 5 つの具体的なレバー（施策）も紹介されています。「いくら使ったか」だけでなく「なぜそのコストが発生したのか」まで踏み込めるようになり、LLM 利用の拡大に伴うコスト管理に悩む方の実践的な指針になります。 ブログ記事「 Amazon Bedrock と Oracle Database@AWS で生成 AI ユースケースを加速する 」を公開 Oracle Database@AWS 上の Oracle AI Database 26ai をベクトルストアとして使い、Amazon Bedrock と統合して RAG（検索拡張生成）アプリケーションを構築する手順を解説する翻訳記事です。Oracle AI Database 26ai は VECTOR データ型と AI Vector Search 機能により、データベース内にビジネスデータと並べてベクトル埋め込みを保存し、セマンティック検索を実行できます。記事では Amazon Titan Text Embeddings v2 モデルで埋め込みを生成し、Amazon Bedrock 上の Anthropic Claude モデルと LangChain を組み合わせた Streamlit ベースの AI チャットアシスタントを構築しています。コードは GitHub で公開されており、Oracle Exadata ワークロードを AWS で運用しながら生成 AI 活用を進めたい方が手を動かして試せる内容です。 ブログ記事「 ナレッジグラフと IoT データによる生産ラインのボトルネック分析 〜AI エージェントのための製造データの構造化〜 」を公開 AWS Summit Japan 2026「生産ラインの未来」ブースで展示した、AI エージェントが生産ラインのボトルネックを検知し改善策を提案するデモの実装詳細を解説する記事です。製品・部品・設備・サプライヤーといった要素間の関係性を Amazon Neptune 上のナレッジグラフとして定義し、サイクルタイムや在庫といった鮮度の高いデータは AWS IoT SiteWise や Amazon DynamoDB から必要なときに参照する構成で、変わりにくい構造と刻々と変わる値を分離しています。「300 台増産は間に合うか」という問いに対して AI エージェントがナレッジグラフ探索、リアルタイムデータ取得、在庫照合、統合判定、自然言語での報告までを実行する推論フローが具体的に示されており、製造データを AI エージェントで活用するためのデータ構造化の進め方として参考になります。 Kiro関連 ブログ記事「 Kiro の 1 年：学生たちが今まさに未来を築いている 」を公開 Kiro 公開 1 周年にあわせ、学生ビルダーたちの活躍を紹介する記事です。Kiro for students の開始以来、数千人の学生が Kiro で開発に取り組んでおり、視覚障害のあるユーザー向けに Web の視覚コンテンツを音声フィードバックに変換するアクセシビリティアプリや、音声起動の遠隔ウェルネスシステム、自然言語の説明から配線済みブレッドボード回路を生成する電子工作プロトタイピングツールなど、分野を横断したプロジェクトが生まれています。ハッカソン経験者から初めてコードを書く学生、開発に踏み出したデザイナーまで、それぞれのやり方で Kiro を使う 4 人の学生の声も掲載されています。今年後半には学生向け提供の拡大やキャンパスでのワークショップ・ハッカソン開催も予定されており、AI とともに開発を学ぶ次世代の動きを知ることができます。 ブログ記事「 Kiro でテスト駆動開発（TDD）：こうあるべき体験 」を公開 テスト駆動開発（TDD）の red-green-refactor サイクルを Kiro の hook で徹底する方法を紹介する翻訳記事です。hook は IDE で特定のイベントが発生したときに自動的に実行される自動化ツールで、Kiro がコードを書こうとする前に「まず失敗するテストを書く」ことを促す hook の設定例が、そのままコピーして使える形で掲載されています。モンティ・ホール問題（確率のパズルとして知られる題材）を使ったシンプルな例と、タスク管理システム用 REST API の構築という実践的な例の両方で hook が機能する様子が示されています。TDD の利点は理解しつつも、テストを書く単調さやコンテキストスイッチが負担で実践しきれなかった方にとって、その規律を AI に守らせるアプローチとして試す価値があります。 ブログ記事「 Kiro の 1 年：これまでの振り返りと、これから 」を公開 Kiro の公開から 1 年を振り返る記事です。プレビュー公開から最初の 5 日間で 10 万人以上の開発者が Kiro IDE を試し、10 月にはその数が倍以上に増加、11 月には一般提供を開始しました。仕様駆動開発、プロパティベーステスト、チェックポイント、CLI、エンタープライズ機能に加え、Web・モバイル体験の提供や OpenAI の GPT-5.6 モデルの追加まで、この 1 年の進化がまとめられています。2 人のクラウドチームが数十の AWS アカウントにまたがる 500 の Lambda 関数の更新を 2 ヶ月から半日に短縮した Loyola Marymount University の事例や、従来は複数の開発者で 3〜4 ヶ月を要するプロジェクトを 1 人のアーキテクトが 2 週間で完了させた Siemens の事例など、利用者の具体的なストーリーからも Kiro の広がりが伝わります。 ブログ記事「 GPT‑5.6 が Kiro で利用可能に 」を公開 OpenAI のモデルが初めて Kiro に登場しました。GPT-5.6 Sol、Terra、Luna の 3 モデルが Kiro の IDE、CLI、Web で利用可能になり、性能とコストのトレードオフに応じて選択できます。フラッグシップの Sol は複雑なマルチステップ作業向け、Terra は日常的なエージェント作業向けのバランス型、Luna は最もコスト効率の高いモデルという位置づけで、クレジット倍率は Sol が 2.4 倍、Terra が 1.2 倍、Luna が 0.6 倍です。AWS 米国東部（バージニア北部）リージョンと欧州（フランクフルト）リージョンにおいて、Kiro Pro、Pro+、Pro Max、Power のお客様向けに実験的サポートとして段階的に展開されており、クロスリージョン推論にも対応しています。 ブログ記事「 ビルダーたちを称えて：創業者は Kiro でどのように開発を加速しているか 」を公開 Kiro 公開 1 周年にあわせ、スタートアップ創業者たちの事例を紹介する記事です。昨年 11 月に開始した Kiro for startups は応募が殺到して早期に受付を終了し、今年 4 月に Kiro Startup Credits として再開、この 1 年で数千の創業者が Kiro を選びました。記事では、規制の厳しい金融コンプライアンス分野で対象ワークフローのデリバリーを約 50% 高速化した Facctum Solutions や、テスト開始まで 24〜32 週間と見積もっていたプロジェクトを 5〜7 週間で完了させた Banking-as-a-Service プラットフォームの Nymbus など、4 社の創業者の声が紹介されています。Kiro Startup Credits の応募は年末まで延長されており、アーリーステージから Series A のスタートアップが対象です。 イベント開催報告関連 ブログ記事「 【開催報告】AWS Summit Japan 2026 — AI エージェントで危機対応：小売×消費財の混乱を AI と人が即座に解決 」を公開 AWS Summit Japan 2026 の流通小売・消費財・飲食業界向けブースで展示した、サプライチェーン危機対応デモの開催報告です。台風による広域配送停止や原材料の調達難といった外乱に対し、AI エージェントが検知・影響分析・代替案の探索と提示を行い、人間が承認したうえで実行と通知までを一気通貫で行う流れをライブで実演しました。Amazon Bedrock AgentCore Runtime と Strands Agents SDK によるマルチエージェント構成で、Strands Agents SDK の Interrupt 機能を使った人間による承認の必須化（Human-in-the-Loop）や、AWS AppSync Events による AI の思考プロセスのリアルタイム可視化が工夫のポイントです。AI に任せる範囲を 5 段階の自動化レベルとして整理し、既存データを使った「レベル 1 のシミュレーション」からであれば実業務のプロセスを変更せずに今日からでも始められると提案しており、BCP 訓練に課題を持つ企業に具体的な出発点を示しています。 ブログ記事「 【開催報告】AWS Summit Japan 2026 ― AI で加速する製品イノベーション 〜マルチエージェントで実現する製品開発 」を公開 AWS Summit Japan 2026 の流通小売・消費財・飲食ブースで展示した、マルチエージェントによる製品開発デモの開催報告です。製品イノベーションのライフサイクルをリサーチ・デザイン・製造の 3 フェーズに分け、それぞれに専任の AI エージェントを配置し、市場調査から製品デザイン、原価試算・収益予測までを一気通貫で進める体験を提供しました。従来 6 ヶ月から 1 年以上を要することも珍しくない開発プロセスを数分に短縮しつつ、各ステップで AI が複数の案を提示し人間が方向性を決める Human in the Loop の思想を貫いています。エージェントは Amazon Bedrock AgentCore 上で Strands Agents SDK により構築され、経営戦略資料などの自社データを Amazon Bedrock Knowledge Base に連携することで「一般解」ではなく「わが社の解」が得られる点も強調されており、製品開発の高速化を検討する方がイメージを掴みやすい内容です。 ブログ記事「 AIで変える鉄道保全と、「クローズド」を読み解くクラウド設計 — AWS Summit Japan 2026 展示ブース開催報告 」を公開 AWS Summit Japan 2026 の鉄道ブースにおける 2 つの展示の開催報告です。1 つ目は、AI エージェントと地理情報システム（GIS）を統合した鉄道設備保全プラットフォームで、異常検知から原因調査、作業指示書の生成までを AI エージェントが支援するとともに、Amazon Science が開発したオープンソースの時系列基盤モデル Chronos-2 を応用した学習不要（ゼロショット）の予兆検知を紹介しています。2 つ目は、国土交通省「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」第 6 版を踏まえた OT/IT 設計アプローチのパネル展示で、AWS Direct Connect による閉域網接続を前提に、Amazon GuardDuty などのマネージドサービスでセキュリティ運用の負荷を軽減する考え方を示しています。人手不足や保全対象機器の増加に直面する保全現場と、クローズド前提の制御系システムの両面から、鉄道業界のクラウド活用を考えるヒントになります。 ブログ記事「 【開催報告】AWS Summit Japan 2026 — 「AI ペルソナ達がビジネス課題解決を加速する」バーチャル AI エキスパート 」を公開 AWS Summit Japan 2026 の流通小売・消費財・飲食ブースで展示したプロトタイプ「バーチャル AI エキスパート」の開催報告です。CEO 視点、IT Director 視点、店舗マネージャー視点など異なる専門性と立場を持つ複数の AI ペルソナが専門家チームとして自律的に調査・分析・議論し、人間は最終判断だけを行うというコンセプトで、数分の対話で数週間かかっていた意思決定の下準備が完了する体験を提供しました。Nova 2 Sonic によるリアルタイム音声対話、A2A・AG-UI プロトコルによるエージェント間・UI 間通信の標準化、Amazon Bedrock AgentCore Runtime 上での実行という技術構成に加え、4 名のソリューションアーキテクトが Kiro と AI-DLC（AI Development Life Cycle）を活用して約 3 週間のスプリントで設計から開発まで完了させた過程も詳しく語られています。マルチエージェント開発の設計判断や苦労した点が率直に共有されており、同様のシステムを検討する方に実践的な学びがあります。 ブログ記事「 【開催報告】AWS Summit Japan 2026 〜 Future of Agentic Commerce ブース 」を公開 AWS Summit Japan 2026 で展示した、流通小売消費財業界ブース「AWS で実現する新しい E-Commerce の形 〜 Future of Agentic Commerce」の開催報告です。Agentic Commerce とは、自律的な AI エージェントがユーザーに代わって商品の検索・比較・購入・決済までを独立して実行する新しい形の e コマースで、現状では購入の最終判断は人が行う形が中心です。デモでは、AI プラットフォーム側の Incoming Agent と EC 事業者側の Onsite Agent を Amazon Bedrock AgentCore を中心に統合し、UCP・AP2・ECP・MCP Apps といった複数のコマースプロトコルへの対応や Amazon Pay による決済まで、一連のカスタマージャーニーを実際に動く形で紹介しました。来場者からは「AI エージェントに決済まで任せたい」よりも「AI プラットフォーマーに自社の商品を推薦してもらい、自社の EC サイトへ流入させたい」という声が多かったなど現場の生の反応も紹介されており、急速に整備が進むこの分野の全体像を掴むのに役立ちます。 ブログ記事「 【開催報告】AWS GenAI Catapult! 〜AI 駆動型ハッカソンイベント：ユースケース創出から Kiro によるプロトタイプ開発まで〜 」を公開 2026 年 6 月 11 日・12 日の 2 日間、AWS 麻布台オフィスで開催した AI 駆動型ハッカソンイベント「AWS GenAI Catapult!」の開催報告です。Amazon のイノベーション創出メカニズム「Working Backwards」手法を用いて顧客起点で生成 AI ユースケースを創出し、AI コーディングエージェント Kiro でプロトタイプ開発まで行うコンテスト形式のイベントで、金融領域の 13 社 12 チーム（47 名）が参加しました。前回はアイデア創出が中心でしたが、今年は「考える」から「作る」までを 2 日間で一気通貫に体験する構成へと進化しています。参加者アンケートでは総合満足度 4.8/5.0、今後も Kiro を業務で使いたいと回答した方は約 94% にのぼり、「開発をしたことがない人間でも、ここまで作れるのか」という驚きの声とともに、生成 AI 活用を業務効率化の先のイノベーション創出へ引き上げようとする場の熱気が伝わってきます。 サービスアップデート OpenAI GPT-5.6 Sol、Terra、Luna が Amazon Bedrock で一般提供開始 OpenAI の GPT-5.6 Sol、Terra、Luna が Amazon Bedrock で一般提供を開始しました。フラッグシップの推論性能を持つ Sol、バランスの取れた性能の Terra、高速かつコスト効率の高い推論の Luna という能力階層をカバーし、いずれも Amazon Bedrock の Responses API から利用できます。Sol はエージェンティックコーディングのベンチマークで最先端の結果を示し、Terra は GPT-5.5 レベルの性能を半分のコストで、Luna は最も低い価格で高速な推論を提供します。明示的なキャッシュブレークポイントを指定できるプロンプトキャッシュに対応しており、エージェントワークフローで繰り返し使われるコンテキストは 90% 割引で課金されます。料金は OpenAI が直接提供する場合と同じ水準で、利用分は AWS のコミットメントにもカウントされます。Sol は米国東部（バージニア北部）と米国東部（オハイオ）の各リージョンで、Terra と Luna はこれに加えて米国西部（オレゴン）リージョンで利用できます。 AWS の AI ワークロード向け Amazon GuardDuty AI Protection のご紹介 Amazon GuardDuty に、Amazon Bedrock や Amazon SageMaker を含む AWS の AI サービスへ脅威検知を拡張する AI Protection が登場しました。AWS AI サービスの AWS CloudTrail 管理イベントとデータイベントを分析し、異常な呼び出しパターン、攻撃者が AI リソースに GPU 時間やトークンを過剰消費させるコストハーベスティング攻撃、Amazon Bedrock Guardrails との統合によるプロンプトインジェクションの試行などを検出します。検出結果は AWS Security Hub に直接連携され、AI 資産と脅威を単一のビューで確認して優先度を付けた対応ができます。GuardDuty または Security Hub のコンソールから数ステップで有効化でき、AWS Organizations を使えば組織内の全アカウントで一括して有効化することも可能です。手動の設定や独自ツールなしに AI 特有の脅威へ対応できるようになり、GuardDuty のお客様は 30 日間の無料トライアルで利用を開始できます。 AWS Security Hub が組織全体の AI 資産を可視化する AI インベントリを提供開始 AWS Security Hub が、組織全体の AI 資産とそのセキュリティ態勢を継続的に把握できる AI インベントリの提供を開始しました。Amazon Bedrock、Bedrock AgentCore、Amazon SageMaker といったマネージド AI サービスは AWS Config リソースから追加設定なしでインベントリ化し、Amazon EC2 インスタンスや Amazon ECR コンテナイメージ上のセルフホスト型 AI ワークロード（Ollama、vLLM、Hugging Face TGI などのフレームワークを含む）は Amazon Inspector の SBOM（ソフトウェア部品表）分析で、EC2 インスタンスからアクセスされる外部 AI API エンドポイントは Amazon GuardDuty の DNS テレメトリで発見する、3 つの発見方法を組み合わせています。発見された AI 資産は基盤となるインフラにマッピングされ、Amazon GuardDuty の脅威検出結果を含むセキュリティ検出結果と相関付けられるため、実際に脅威にさらされている AI ワークロードから優先的に対処できます。Security Hub Essentials に追加料金なしで含まれ、新たな有効化作業も不要で、Security Hub が提供されているすべての AWS 商用リージョンで利用できます。 PII の検出とマスキングを行う OpenAI の privacy-filter が Amazon SageMaker JumpStart で利用可能に OpenAI の privacy-filter が Amazon SageMaker JumpStart で利用可能になりました。テキスト中の個人を特定できる情報（PII）の検出とマスキングを行う双方向トークン分類モデルで、入力シーケンスを 1 回のフォワードパスでラベル付けし、アカウント番号、住所、メールアドレス、名前、電話番号、URL、日付、シークレットといった PII のカテゴリを検出します。高速で文脈を認識し、チューニングも可能という特性を備え、高スループットなデータサニタイズ（無害化）ワークフロー向けに設計されています。SageMaker JumpStart から数クリックでデプロイできるため、機密情報を含むテキストを扱う処理にデータの無害化を組み込みたい場合に活用できます。 Gemma-4-E2B-it が Amazon SageMaker JumpStart で利用可能に Google DeepMind の Gemma-4-E2B-it が Amazon SageMaker JumpStart で利用可能になりました。テキスト・画像・音声の入力を処理してテキストを出力するマルチモーダルな指示チューニング済みモデルで、効率的なローカル実行に最適化されており、回答の前にステップバイステップで考える推論モードを内蔵しています。物体検出、ドキュメント解析、画面や UI の理解、チャートの読み取り、OCR といった画像理解に加え、動画理解、エージェントワークフロー向けのネイティブな関数呼び出し、コードの生成・補完・修正、数十言語にわたる多言語対応を提供します。SageMaker JumpStart から数クリックでデプロイでき、幅広いタスクに対応するモデルを自社の AWS アカウント上で試せます。 検索（retrieval）向けの Qwen3 埋め込みモデルとリランキングモデルが Amazon SageMaker JumpStart で利用可能に Qwen の Qwen3-VL-Embedding-2B と Qwen3-Reranker-4B が Amazon SageMaker JumpStart で利用可能になりました。2 つのモデルは通常セットで使われ、埋め込みモデルが効率的な初期リコール（候補の絞り込み）を行い、リランカーが後段の再ランキングで結果を精緻化します。Qwen3-VL-Embedding-2B はテキスト、画像、スクリーンショット、動画やそれらの混合入力を受け付け、視覚情報とテキスト情報を共有空間で捉える意味的に豊かなベクトルを生成し、30 以上の言語をサポートします。Qwen3-Reranker-4B はクエリと文書のペアを入力として精密な関連性スコアを出力し、テキスト検索、コード検索、テキスト分類、テキストクラスタリング、バイテキストマイニングを 100 以上の言語で扱え、タスクや言語に応じたユーザー定義の指示にも対応します。検索パイプラインの品質を左右する 2 つの段階を、自社の AWS インフラストラクチャ上で構築したい場合の選択肢になります。 リアルタイム音声書き起こし向けの Voxtral-Mini-4B-Realtime が Amazon SageMaker JumpStart で利用可能に Mistral AI の Voxtral-Mini-4B-Realtime-2602 が Amazon SageMaker JumpStart で利用可能になりました。ネイティブなストリーミングアーキテクチャによりリアルタイムの書き起こしを実現する音声書き起こしモデルで、13 言語にわたる多言語書き起こしをサポートします。書き起こしの遅延を設定で調整できるため、用途に応じてレイテンシー（応答までの遅延時間）と精度のバランスを選べる点が特徴です。SageMaker JumpStart から数クリックでデプロイでき、低レイテンシーの音声アプリケーションを AWS インフラストラクチャ上に構築できます。 Amazon OpenSearch Service が Agent Toolkit for AWS をサポート Amazon OpenSearch Service が Agent Toolkit for AWS と統合され、Claude Code、Kiro、Cursor などの AI コーディングエージェントから OpenSearch Service ドメインや OpenSearch Serverless コレクションを直接構築・管理・クエリできるようになりました。AWS API 呼び出しを代行する AWS MCP（Model Context Protocol）サーバーと、自然言語のリクエストを適切な機能へ自動的に振り分けるキュレーション済みスキル「amazon-opensearch-service」の組み合わせで動作します。セルフマネージドの OpenSearch からの移行、ドメインとコレクションのプロビジョニング・管理、ベクトル・セマンティック・ハイブリッド・RAG 検索の構築、PPL と OpenSearch Ingestion によるログ分析、OpenTelemetry による分散トレース分析という 5 つの領域を、目的を自然言語で伝えるだけでエージェントが処理してくれます。既存インフラの変更は不要で追加料金なしに利用でき、Amazon OpenSearch Service と OpenSearch Serverless が提供されているすべての AWS リージョンでサポートされます。 Kiro-CLI : Introspect サブエージェントとグローバル hooks Kiro CLI 2.13.0 がリリースされ、早期アクセス中の CLI 3.0 向けに 2 つの新機能が追加されました。Introspect サブエージェントは、Kiro の機能について質問するとその場で正確な回答が得られる組み込みのサブエージェントで、カスタムエージェント・hooks・steering ファイルの書き方の案内や、ワークフローに合った設定の提案も行います。グローバル hooks は、~/.kiro/hooks/ に配置した hook がすべてのワークスペースで自動的に発火する仕組みで、保存時の lint、コミット前のセキュリティチェック、カスタムの承認ゲートといった横断的な処理をプロジェクトごとに複製する必要がなくなります（ワークスペースレベルの hooks も引き続き併用できます）。いずれも kiro-cli –v3 で利用でき、全ユーザー向けのエラーハンドリング修正もあわせて含まれています。 Kiro-Model : OpenAI GPT-5.6 Sol、Terra、Luna が利用可能に OpenAI のモデルが初めて Kiro に登場し、GPT-5.6 Sol、Terra、Luna が IDE、CLI、Web で利用できるようになりました。フラッグシップの Sol は仕様駆動の実装や長期にわたるリファクタリング、複雑なターミナルタスクといった難度の高いマルチステップ作業向けで、Coding Agent Index で 80、Terminal-Bench 2.1 で 88.8% のスコアを記録しています。Terra は日常的なマルチステップ開発をフラッグシップの数分の一のコストでこなすバランス型、Luna はスループット重視の高頻度タスク向けの最速・最安のティアです。3 モデルとも 272K のコンテキストウィンドウを持ち、Kiro のクレジット倍率は Sol が 2.4 倍、Terra が 1.2 倍、Luna が 0.6 倍。実験的サポートとして、米国東部（バージニア北部）と欧州（フランクフルト）の各リージョンで、Pro、Pro+、Pro Max、Power のお客様向けにクロスリージョン推論とともに展開が進んでいます。なお、これらのモデルは思考過程を非公開とする chain-of-thought 推論を用いるため、内部の推論ステップは表示されず最終出力のみが表示されます。 Kiro-IDE : セッションの高速化、コンパクションの修正、PowerShell の信頼設定 Kiro IDE 1.0.138 がリリースされました。セッションの起動が高速化されたほか、大規模なセッションで「Context limit exceeded」エラーが繰り返し発生していたコンパクション（コンテキストの自動圧縮）のループが修正され、Windows での PowerShell の信頼（trust）が完全にサポートされました。また、MCP ツールが一時的なネットワーク障害の際にサイレントに失敗せず、回復するようになっています。最新の 1.0.x リリースは kiro.dev/downloads から直接ダウンロードでき、自動更新はユーザーへ段階的に展開中です。 最後に、「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近燻製づくりにハマってます。

2026 年 6 月 25 日、26 日に AWS Summit Japan が開催され、多数のセッションとブース展示が行われました。AWS セッションや AWS Village のブース展示においては、レジリエンスに関するトピックを多数お届けしていました。本ブログでは、AWS Summit Japan 2026 よりレジリエンスに関するセッション、ブースの内容をサマリーでご紹介します。 AWS セッションより 大規模障害から考える、AWS 上で備えるべきレジリエンスの実践 AWS エンタープライズサポート シニアテクニカルアカウントマネージャー 猪又 赳彦より、実際の障害発生時に AWS が何をしているのかを解説するセッションをお届けしました。AWS の障害対応は「検出と軽減策の実施」「振り返り」「学習とスケーリング」の 3 フェーズで進められ、振り返りでは COE（Correction of Error）の中核として Five Whys による根本原因分析が行われることを紹介。「5 回で止める」「直線的な分析に限定する」といった典型的な誤解に触れつつ、1 つの事象から複数の根本原因へ問いを分岐させていく実例が解説されました。 また、障害から生まれた「Availability Axioms（可用性の基本原則）」として、リージョンの分離（AWS STS のリージョナル化の歴史）、AZ 障害への自動対応（Fleet Health Service や Zonal Event Detector による検知と Amazon Application Recovery Controller の Zonal Shift / Autoshift）、厳密なテスト（専用のテストリージョンでのゲームデー）、過負荷からの保護（Metastable Failure という準安定障害の概念）という 4 つの原則が紹介されました。事例では、2025 年 10 月 20 日の US East 1（バージニア北部）リージョンでの Amazon DynamoDB DNS 障害を踏まえ、Fidelity Investments 社が日常的なレジリエンステストにより、当日 2,000 個のアプリケーションのフェイルオーバーを検知から 9 分で完了させた実践が紹介されました。 Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－ AWS Developer スペシャリストソリューションアーキテクト 金森 政雄より、AI-Driven Development Lifecycle（AI-DLC）の Operation フェーズに焦点を当てたセッションをお届けしました。AI-DLC のホワイトペーパーでは、AI がテレメトリを能動的に分析して問題を予測し、ランブックと連携して推奨アクションを提案・実行し、開発者が検証・承認するというサイクルが定義されていますが、実運用に導入するには「既存の運用に乗せる」→「AI で改善する」→「AI を活用した運用（AIOps）へ」という段階的なアプローチが有効であると解説されました。具体例として、アーキテクチャ図上でリスクを可視化する「リスクストーミング」と、カオスエンジニアリングを組み合わせ、AI-DLC で開発されたデモアプリ「Unicorn Market」を用いて、リスク抽出から障害注入実験までを AI が加速するデモが実演されました。 AWS DevOps Agent による自律的インシデント対応 －その能力を引き出す設計のベストプラクティス－ AWS シニアスペシャリストソリューションアーキテクト 加藤 正樹より、障害対応と運用改善に特化した AI エージェント「AWS DevOps Agent」の能力を引き出す設計を解説するセッションをお届けしました。障害対応における AI 活用の課題として、暴走と停止の制御、多様なデータソースの横断、チーム全員でのコンテキスト維持の 3 点を整理し、「調査は AI、判断は人」という設計思想のもと、複数オブザーバビリティツールを横断したテレメトリ調査やコードリポジトリと連携した変更特定、Skills によるナレッジ共有といった機能が紹介されました。デモでは CloudWatch Alarm をトリガーに自律的に調査を開始し、複数テレメトリを相関づけて根本原因に到達、緩和計画を Kiro 等のコーディングエージェントに引き渡すまでの一連の流れが実演されています。 能力を引き出すベストプラクティスとして、調査スコープを定義する Agent Space の設計原則、Insights ファミリーや OpenTelemetry によるテレメトリの充実、Skills と Agent Instructions によるナレッジ共有の 3 点が解説されました。ナレッジ整備前後では根本原因到達時間が 6 分 32 秒から 3 分 38 秒へ短縮された結果も共有されています。事例として KDDI 様では調査リードタイムが数週間から数日へ短縮され、CyberAgent 様では MCP サーバーを活用して本番データベースを安全に調査する独自拡張を構築した事例が紹介されました。 ランサムウェアに対して最優先で取るべき AWS の復旧対策 ソリューションアーキテクト 向井 稔より、ランサムウェア被害からの「復旧」にフォーカスし、状況に応じた 3 段階の対策を解説するセッションをお届けしました。IPA「情報セキュリティ 10 大脅威 2026」でランサム攻撃が 11 年連続 1 位となる中、防御・検知・対応だけでなく、暗号化されたデータを確実に復元し業務を再開する「復旧」フェーズの重要性を強調しました。 まず「すぐに始められる対策」として、Write Once Read Many（WORM）によるイミュータブルなデータ保護を紹介しました。AWS では Amazon S3 Object Lock、Amazon EBS Snapshot Lock、Amazon FSx for NetApp ONTAP SnapLock、AWS Backup Vault Lock の 4 つのサービスで WORM を実現でき、いずれも追加料金なしで利用可能です。Compliance モードを選択すれば、保持期間中は管理者であってもデータを削除できない強固な保護が適用されます。 次に「包括的な対策」として、AWS アカウント自体が侵害されるリスクに備え 3-2-1-1-0 ルールに基づく戦略を解説しました。具体的には、AWS Backup の論理エアギャップボールト（Logically Air-gapped Vault）により AWS 管理の専用アカウント内にバックアップを隔離し、デフォルトで Vault Lock による WORM 保護を適用する構成を紹介しました。さらに Amazon GuardDuty Malware Protection for AWS Backup によりバックアップのマルウェアスキャンを復旧前に実施できること、自動復元テストにより復旧プロセスの正常性を継続的に確認できることを説明しました。最後に「オンプレミス環境の対策」として、バックアップソフトウェアと S3 Object Lock を連携させ、オンプレミスのデータを AWS に WORM 保護付きでバックアップし、DR 対策とランサムウェア対策を同時に実現する構成を紹介しました。 AWS ブース展示より レジリエンス強化と障害対応につかえる AI 体験 本ブースでは「EC サイトが障害で停止し、復旧まで 1 時間を要した」というシナリオを起点に、レジリエンスライフサイクルの各ステップを AI で加速する 4 つのデモを体験いただきました。 起点となる AWS DevOps Agent のデモでは、DB 接続プール枯渇と Redis キャッシュ障害が同時発生する複合障害に対し、CloudWatch Alarm をトリガーに AI が自律的に調査を開始。約 10 分で 2 件の根本原因を特定し、緩和計画まで日本語でレポートする一連の流れをお見せしました（運用・対応と学習）。続いて BIA（Business Impact Analysis）のデモでは、Kiro 上で動く AI ファシリテーターが対話形式でビジネスインパクトの分析を支援。ダウンタイムコストと最大許容ダウンタイムを算出し、DR の目標値を導き出す過程をご紹介しました（目標を設定）。 3 つ目の次世代 AWS Resilience Hub × Kiro のデモでは、GenAI による障害モードアセスメントが現行アーキテクチャの課題を評価し、その結果を Kiro に渡すとマルチリージョン化の提案レポートから CloudFormation テンプレートの改修まで AI が一気通貫で生成。評価・計画・実装を AI が担い、人間は判断とデプロイ承認に集中できるワークフローを提案しました（設計と実装）。最後の Chaos Agent（Kiro × AWS FIS）のデモでは、再設計後の環境に対し AI がカオステストのシナリオ生成から障害注入、RTO/RPO の合否判定までを自律実行。実測 RTO 約 99 秒で目標を大幅にクリアする結果を示し、設計後も AI が継続的に検証する重要性をお伝えしました（評価とテスト）。 4 つのデモは「運用・対応と学習 → 目標を設定 → 設計と実装 → 評価とテスト」というライフサイクルを一気通貫で体験できる構成とし、ご来場いただいた方のご興味のポイントに合わせてご説明させていただきました。 大阪リージョンを使用したマルチリージョン構成のデモ（たこ焼き AI 大将） 大阪リージョンをメインとしたディザスタリカバリ（DR）構成を、たこ焼き注文アプリ「たこ焼き AI 大将」として体験できるデモをご案内しました。レジリエンス／DR は重要でありながら難解と捉えられやすいテーマなので、技術的な堅牢性を保ちつつ誰もが直感的に楽しめる構成を目指してデモを設計・実装しました。注文操作に連動して、たこ焼きを焼く・盛り付けるロボットアームを配置し、来場者の関心を自然に技術デモへ引き込む導線を目指しました。 ブースではリージョン障害を疑似的に発生させても注文を継続できる様子を実演し、Amazon Aurora DSQL のマルチリージョン アクティブ‐アクティブクラスターによる高可用性、Amazon Bedrock のクロスリージョン推論、Amazon CloudWatch Application Signals による SLO モニタリングを組み合わせた構成を紹介しました。障害対応には Amazon CloudFront のオリジンフェイルオーバーと Amazon Application Recovery Controller の Region Switch を採用し、AWS Fault Injection Service で Lambda レイテンシーや DSQL 接続障害時の動作を検証するアーキテクチャを体感いただきました。 AWS レジリエンス体験ゲーム 〜 選ぶだけで学べる、障害対応の意思決定 手を動かしながらレジリエンスを学べるよう、ブースにクイズ形式のゲームを用意しました。AWS のレジリエンス設計を体験できる展示です。来場者は架空のグローバル企業で「最高レジリエンス責任者（Chief Resilience Officer）」となり、次々と発生する障害シナリオに対して復旧の選択肢を選んでいきます。専門知識がなくても選択肢を選ぶだけで進められるので、クラウド初心者からアーキテクトまで、立ち止まって手を動かしていただけました。 用意したのは、業種の異なる 4 つのシナリオです。 FinancePay（決済 / マルチリージョン災害復旧） — リージョン障害に直面し、RTO / RPO を意識しながら、バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイトアクティブ/アクティブという 4 つの DR 戦略を選択。Amazon Application Recovery Controller（ARC）のルーティングコントロールによるリージョン間のトラフィック切り替えも体験します。 StreamMax（動画配信 / 高可用性とゾーン分離） — ライブ配信中のアベイラビリティゾーン（AZ）障害に対応。マルチ AZ 配置と、ARC の Zonal Shift・Zonal Autoshift による健全な AZ へのトラフィック退避を通じて、障害の影響を AZ 単位に封じ込める考え方を学びます。 ShopFast（EC / セルベースアーキテクチャ） — フラッシュセール中のカスケード障害が題材。セルベースアーキテクチャとシャッフルシャーディング、バルクヘッドパターンで爆発半径（Blast Radius）を最小化し、一部が壊れてもサービス全体を止めないグレースフルデグラデーションを体感します。 DoWellAI（生成 AI / AI ワークロードのレジリエンス） — 生成 AI アプリの安定運用がテーマ。Amazon Bedrock Guardrails による入出力フィルタリング、クロスリージョン推論、プロンプトキャッシング、共有障害の防止といった、生成 AI 時代のレジリエンスパターンを扱います。 「アベイラビリティゾーンとは何か」といった基礎から、セルベースアーキテクチャや生成 AI ワークロードの可用性設計まで、体験しながら段階的に学べる展示を行いました。 進化する金融 × レジリエンス 〜 金融システムを支えるセキュリティ＆レジリエンス 金融ブースでは、ミッションクリティカルなワークロードのレジリエンス強化とサイバーセキュリティ対策について、具体的な実装をデモでご紹介しました。取り上げたのは、次のようなユースケースです。 リアルタイムカード決済のマルチリージョン構成 — 東京・大阪の両拠点で止まらない決済基盤をライブ実演。カードをかざした瞬間から処理完了までの流れを体感いただけます。 認証情報侵害の検知と AI による自律調査 — 多段階攻撃の個別アラートを AI が「攻撃チェーン」として自動判定し、調査レポートまで生成。検知から調査完了までを一気通貫でお見せしました。 AWS Security Agent による設計書レビュー — 設計書を読み込ませ、コンプライアンス確認作業を効率化する取り組みをご紹介しました。 AI との対話によるランサムウェア対策アーキテクチャ提案 — ランサムウェア対策を生成 AI が活用できる Agent Skill として体系化。金融グレードの AWS 推奨構成を対話で具体化し、設計提案・現状評価・改善ロードマップをレポート出力します。 障害訓練シナリオの AI 自動生成 — 構成情報を入力するだけで障害訓練のシナリオと実施計画を AI が自動生成し、訓練準備の負担を大幅に削減します。 止まらない決済基盤から、AI を活用した脅威検知・設計レビュー・障害訓練まで。守りを固めるだけでなく、生成 AI で運用そのものを進化させていく。そんな金融システムのこれからを、実装を通して感じていただける展示となりました。 人間 vs AI 障害対応バトル – Chaos Kitty Challenge AWS のアーキテクチャを物理的に表現し、インシデント対応を体験学習できる Chaos Kitty。4 回目の登場となる今年は、新たに「対戦モード」を追加して AWS Builders’ Fair に展示しました。同じ障害が発生した 2 つの環境で参加者と AI エージェントが同時に対応を開始し、どちらが早く正確に Web 3 層アプリケーションの障害を解決できるかを競います。 AI エージェントには AWS DevOps Agent を採用。メトリクス・ログ・トレースやデプロイ履歴を横断分析して根本原因を特定していく調査プロセスが対戦画面上にリアルタイムで可視化され、AI 時代のインシデント対応の未来を体感できる展示となりました。 Chaos Kitty は AWS Samples として公開しており、ご自身の AWS 環境にデプロイしてお試しいただけます。詳しくは紹介ブログ記事もあわせてご覧ください。 AWS Summit Japan 2026 に Chaos Kitty が対戦モードを引っさげて 4 回目の登場！   大阪リージョンデータセンター 最新の災害対策 大阪リージョンデータセンターブースでは、AWS インフラストラクチャの耐災害性を直感的に体験いただける展示を行いました。今回のサミットでは、大阪リージョンで採用されている日鉄エンジニアリングの免震装置「NS-SSB（球面滑り構造）」を模型と VR 体験装置でご紹介。VR を通じて免震構造の効果を体感いただくことで、大阪リージョンのインフラストラクチャが持つ高い耐災害性をより実感いただける内容としました。特に DR 戦略として大阪リージョンの利用を検討されているお客様から高い関心をいただきました。 まとめ 障害へのアプローチとしては、障害が起こる事を前提とし、素早く復旧する事（レジリエンス、回復力）が重要です。今回の AWS Summit では、このプラクティスを AI エージェントによって加速するという新しい潮流が多く確認できる内容となっておりました。特に、Business Impact Analysis から Resilience Hub によるアーキテクチャ評価、Fault Injection Service を用いたカオステスト、そして障害発生時の DevOps Agent による一次対応まで、レジリエンスライフサイクルの各フェーズに AI を組み込む具体的な実装例が確認できる内容になっておりました。加えて、ランサムウェアからの復旧対策や大阪リージョンを活用したマルチリージョン構成など、ミッションクリティカルなワークロードを守るための実践的な選択肢も幅広くご紹介しました。これからミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド活用を検討頂いている皆様に少しでも参考になれば幸いです。 現在は、セッションの動画や資料を以下で公開中です。ぜひあわせてご覧ください。 – 動画（視聴には登録が必要です）： https://aws.amazon.com/jp/events/summits/japan/ – セッション資料： https://pages.awscloud.com/AWS-Summit-Japan-2026-Session-Materials-Download.html – ブース展示資料： https://pages.awscloud.com/AWS-Summit-Japan-2026-AWS-Expo.html 著者について 猪又 赳彦 技術支援本部 エンタープライズサポート シニアテクニカルアカウントマネージャー 鈴木 真史 技術統括本部 交通・物流ソリューション部 シニアソリューションアーキテクト 三好 史隆 技術統括本部 自動車・製造 ソリューションアーキテクト 安藤 麻衣 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト

イベント概要 半導体業界をリードする企業の皆様をお迎えし、昨年ご好評いただいた「EDA on the Cloud – Tokyo」を今年も開催します。オンプレミスからクラウドへの移行に悩むお客様に対し、AIとHPCが融合したEDAワークロードの未来、EDAに最適化されたAWSサービスやロードマップ、そして革新的な生成AIの活用など、EDA領域におけるクラウド活用のすべてをご紹介します。 本イベントはアメリカ、ロンドン、韓国、台湾で開催しているイベントの日本開催となり、グローバルにおける最新情報をお届けします。EDA・半導体・AIの各領域をリードするグローバルAWSパートナーが一堂に会し、EDAのクラウド活用に関する最新動向と最先端の取り組みをご紹介します。また、お客様事例としてソニーセミコンダクタソリューションズ様より半導体EDA基盤のクラウドジャーニーについてご講演いただきます。 開催日時 2026年8月4日（火）9:30 – 18:00 (9:00 受付開始) 開催場所 AWS 麻布台オフィス 〒106-0041　東京都港区麻布台1丁目3-1　麻布台ヒルズ 森JPタワー 東京メトロ日比谷線 神谷町駅 直結・東京メトロ南北線 六本木一丁目駅より徒歩約4分 ※入退館等詳細は別途ご連絡いたします 参加対象者 このイベントは、クラウドアーキテクトやエンジニアから、ディレクター、CTOまで、あらゆるレベルの技術リーダーやビルダーを対象としています。 プレゼンテーションでは、技術ソリューションやその実装方法、業界への影響に焦点を当てますのでクラウド上でのEDAワークロード実行における最新トレンドを把握したい方や、他社事例を参考にしたい方、EDA領域におけるAWSの実装方法に興味のある方など、多くの方にご参加いただけます。 特に以下のような方々に最適なイベントとなっております： 半導体設計におけるクラウド活用を検討されている方 EDAワークロードの最適化やコスト削減に取り組まれている方 クラウドベースの設計検証環境の構築を目指している方 大規模なEDAジョブの効率的な実行方法を模索されている方 セキュアなクラウド環境でのIP管理に関心のある方 本イベントでは、業界をリードする企業の実践事例や、最新のクラウドソリューション、そして将来的な技術展望まで、幅広いトピックをカバーいたします。また、ネットワーキングの時間もご用意しており、パートナー様やAWSメンバーとの情報交換を通じて、具体的な課題解決のヒントを得ていただける機会となっております。 ぜひこの機会に、次世代の半導体設計インフラの可能性を共に探求してまいりましょう。 想定している参加者様のレベル Level 200（AWSのインフラストラクチャに関する基礎的なナレッジがあることを前提に、EDA・生成AI・セキュリティ等に関連したセッションを実施します） 定員 100名 （参加費無料） 参加申し込みについて 以下のページよりお申し込みください。 [ お申し込みはこちら ] プログラム内容 時間 内容 9:00-9:30 受付 9:30-9:35 オープニング アマゾン ウェブ サービス ジャパン合同会社 袴田 淳 9:35-10:10 EDA on AWS Updates Kirti Devi, Sr. Manager, Tech Business Development HPC/ML, AWS アマゾン ウェブ サービス ジャパン合同会社 小林 広志 10:10-10:40 EDA x AI x Cloud Umar Shah, Head of Solutions/GTM, Electronics & EDA, AWS 10:40-11:10 AWSシリコン最前線 ～ AI時代のチップ選択を読み解く ～ 常世 大史, Principal Solutions Architect, Annapurna Labs 11:10-11:20 休憩 11:20-12:00 ソニー半導体EDA基盤のCloud Journey ソニーセミコンダクタソリューションズ株式会社 設計基盤技術部門 設計環境推進部 豊田 剛介 様 12:00-13:00 昼休憩 13:00-13:45 AI時代のEDAデータ基盤：Amazon FSx for NetApp ONTAPとS3 Access Pointsで加速する半導体設計ワークロード ネットアップ合同会社 シニアクラウドソリューションアーキテクト 藤原 善基 様 13:45-14:15 EDA on the Cloudを加速するAMD EPYC Turin – AWSクラウド上での半導体設計ワークロード最適化 日本AMD株式会社 コマーシャル営業本部 セールスエンジニアリング シニアマネージャー 小林 宏行 様 14:15-14:45 これから選ぶべきEDA向けインスタンスは？ – Amazon EC2 Gen 8に搭載 最新フラッグシップ・デバイス　インテル® Xeon® 6 – インテル株式会社 シニア・HPC & AI ソリューション・アーキテクト 髙藤 良史 様 14:45-14:55 休憩 14:55-15:25 クラウド時代のAI-Driven EDA：Cadence AI Super Agentが変える設計・検証フロー 日本ケイデンス・デザイン・システムズ社 Lead Application Engineer 安川 勝 様 15:25-15:55 クラウドとAIが変える半導体設計 – Siemens EDA × AWSが実現する次世代EDA環境 シーメンスEDAジャパン株式会社 技術本部 技術本部長 丁子 和之 様 15:55-16:05 休憩 16:05-16:35 半導体のためのフロンティアAI Anthropic Japan合同会社 アプライド AI アーキテクト 松井 佑馬 様 16:35-17:05 ChipAgents William Wang, CEO and Founder, ChipAgents.ai 17:05-17:10 クロージング アマゾン ウェブ サービス ジャパン合同会社 野間 愛一郎 17:10-18:00 ネットワーキング (Sponsored by AMD) 参加者同士の情報交換や、AWS パートナー様や AWS メンバーへのご質問の時間としてご活用ください アジェンダや参加パートナー企業は変更となる可能性がございます。 一部のセッションは英語での提供となりますが、通訳を手配する予定です。

このワークショップで起きたこと みなさん、こんにちは。AWS アカウントマネージャーの岩上です。 2026年6月8日、AWS 麻布台オフィスで 「Claude , Kiro実践ワークショップ」 を開催しました。 参加者22社51名、ハンズオン2時間、そして最後に参加者が自作アプリを発表する時間を設けました。 ワークショップの満足度はなんと100%というアンケート結果 でした。 本記事では当日の流れ、参加者が作ったアプリ、そして高い満足度を頂けた背景をまとめます。 ワークショップの出発点 多くの企業がDXに取り組む中、共通して聞こえてくる課題があります。それはアイデアはあっても実装できる人材がいないでした。IT部門は日々の運用に追われ、新しい取り組みに手が回らない。この業務変革の「最後の1マイル」が状態が続いています。AI コーディングツール（Claude Desktop Cowork / Code、Kiro IDE）は、この構造を変える可能性を持っています。自然言語で指示するだけでアプリの雛形が作れる時代になりました。 しかし、AI コーディングツールのデモを見ても「すごいけど自分には関係ない」で終わりがちです。ツールを配るだけでは組織は変わりません。 そこで、AIを学び場だけでなく業務変革のきっかけの場を提供したいと考えました。 参加者が自分の業務課題を起点に、実際に動くアプリを作る ことを主眼としたワークショップを企画しました。 プログラム構成 今回は参加要件として、 ”事前セットアップを完了頂いている事” とさせていただきました。事前セットアップを完了してもらうことで、ワークショップ当日はアプリ作成に集中できる環境を用意しました。 座学では操作に必要な最低限の知識を共有し、試していただく時間を最大限長くとる構成で運営しました。※セットアップガイド（ Kiro / Claude Desktop ) まず座学パートではソリューションアーキテクトの山澤が担当しました。 ワークショップ全体像 ハンズオンではテキスト教材を起点にしつつ、各自が「自分の困りごと」をテーマに開発。ソリューションアーキテクトがフロアを巡回し、手が止まっている人に声をかける体制としました。 アプリ発表事例：日本曹達 宮形様の農業化学品FAQデータベース アプリ作成時間は30分間という限られたお時間の中、参加者の皆様も集中して生成AIを使った開発をされていました。その後今回のメインパートである「アプリ発表」を実施しました。 今回は発表者の代表として日本曹達株式会社農業化学品事業部普及部広報課 宮形様を取り上げさせていただきます。 日本曹達様は総合化学メーカーで、非エンジニアの方々も積極的に生成AIを活用されているお客様です。 課題: 顧客からの技術問い合わせに対し、過去の回答履歴を毎回手作業で検索。同じ質問に何度も回答し、回答品質がベテランの記憶に依存していた。 ワークショップ内で作ったもの: 過去のQ&Aデータをキーワード検索できるFAQアプリ。カテゴリを絵文字で直感的に表示し、関連度の高い過去回答を提示。 ポイント: 巨大システムの刷新ではなく「毎日繰り返す不便」を解消する題材選び 業務を最もよく知る担当者自身が、仕様書を書く代わりにアプリを作った 属人的なナレッジを検索可能にする「組織化の第一歩」になる ここから先は、データ拡充→意味検索（RAG）→回答案の自動生成→組織展開と段階的に進化させられます。重要なのは、最初の一歩をワークショップの2時間で踏み出せたことです。 日本曹達株式会社農業化学品事業部普及部広報課 宮形様の発表 他の発表者が作ったアプリ また現地では業務からプライベートなお悩みまで多様なアイディアのもと、様々なアプリケーションが発表があり、双方向での学びの場として盛り上がりを見せていました。発表頂いた皆様、すばらしいアプリの共有ありがとうございました。 画像アイコン加工（ドラッグ＆ドロップで透過・補正を自動処理） 製品CSV一括登録（バリデーション付き一括登録Webアプリ） クラウドコスト可視化（ブラウザ拡張でリアルタイム表示） ゲーム開発（ターン制戦車バトルゲームをフルスクラッチ） 外食抑制カウンター（月間上限に対する進捗可視化 ワークショップ後の懇親会 発表終了後、そのまま会場で懇親会を実施しました。参加企業同士が 「自社ではこう使おうと思っている」「セキュリティ部門への説明はどうしたか」 といった具体的な情報交換を行い、企業の枠を超えた議論が自然発生していました。普段接点のない他社の担当者と、同じツールを触った直後だからこそ生まれる会話があり、ワークショップ本編に匹敵する価値がこの時間にあったと感じています。 高い満足度 の背景 ― 何がうまくいったのか ワークショップ終了後のアンケート（1 ~ 5の5段階で満足度を評価）では、参加者の100%が「4」または「5」を選択いただき高い満足度を示しました。運営として意識していたのは、 「参加者がアプリを作る体験の品質」をいかに上げるかでした。 またコメントでも 「刺激になりました！」「他の人の作成したアプリが動作含め見られたことが良かった」 などアプリ発表に関しての好意的なコメントも多く頂いております。 振り返りとして3点を共有します。 1. 「当日動かない」リスクの排除 AI コーディングツールはクライアント環境への依存が大きく、セットアップ不備が致命的です。そこで以下を事前に準備しました。 参加者に事前セットアップを必須化し、Zenn 記事で手順を詳細公開。さらに当日の想定外のトラブルの対策としてサポートメンバーとしてソリューションアーキテクトが巡回し、 お客様の課題をその場で解決しました。 2. ゴールを押しつけない 教材はあっても「このアプリを作ってください」というお題はあえて出していません。チュートリアルを最後までなぞるのではなく、途中から自分のテーマに切り替えてよい設計にしました。 結果的に、発表された6つのアプリはすべて別々の課題を解いています。 3. 発表の場があること 「2時間後に発表できる人を募集します」と冒頭で伝えたことで、ハンズオン中に「見せられるものを作ろう」というモチベーションが自然に生まれました。 なお、発表は完全任意で進行させていただきました。発表頂いた皆様の素晴らしいOwnershipに感謝いたします。 どのように生成AIをつかって業務を変えていくかの現場の活用Tipsをその場で学べることに価値を感じて頂けました。 なお今回のワークショップで持ち帰るアイディアを記載いただきました。 ワークショップ後の支援 AWS では、ワークショップで「自分でも作れる」と実感いただいた後も、お客様の状況に応じた継続支援をご用意しています。活用方法の共有会、業務課題の深掘り、セキュリティ面の技術説明など、次のステップについては担当のアカウントマネージャーまでお気軽にご相談ください。 なお本ワークショップの目的はアプリを作ることではありません。 AIを使い、自ら業務を改善できる人材を増やすこと です。個人の生産性向上が組織全体へ広がることで、企業はこれまで改善できなかった業務変革を現場から進められるようになります。私たちは今後も、お客様が生成AIを単なるツールではなく、継続的な業務変革の基盤として活用できるよう支援していきます。 本記事公開時点では、当該ワークショップは招待制のイベントとなります。AWS側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください。 関連リンク Claude Desktop セットアップガイド（Zenn） Kiro IDE セットアップガイド（Zenn）

AWS で実現する新しい E-Commerce の形 〜 Future of Agentic Commerce みなさんこんにちは。ソリューションアーキテクトの中島です。 本記事では AWS Summit Japan 2026 で展示した、流通小売消費財業界ブース「AWS で実現する新しい E-Commerce の形 〜 Future of Agentic Commerce」の様子を皆様にお伝えさせていただきます。 Agentic Commerce とは Agentic Commerce とは、自律的な AI エージェントが、ユーザーに代わって商品の検索・比較・購入・決済までを独立して実行する、新しい形の e コマースです。従来の EC ではユーザー自身が検索・比較・購入を行い、意思決定もすべて人間が担っていましたが、Agentic Commerce では AI エージェントが検索・比較・購入・決済を自律的に実行し、人間は条件設定と監督に役割が変わります。なお現状では、購入の最終判断は人が行い、決済は人の指示を受けてエージェントが代行する形が中心です。 こうした AI エージェント経由の商品発見・購買は、直近のニュースでも大きく取り上げられています。たとえば AWS は、決済パートナーと連携して AI エージェント向けのステーブルコイン決済基盤（ Amazon Bedrock AgentCore payments ）を発表し、自律型 AI エージェントがリアルタイムに購入を行えるインフラの構築を進めています。また EC プラットフォーム側でも、AI エージェント経由の意図しない購買を防ぎつつ、マーチャントが商品データを適切に連携できるフィード機能の提供が始まるなど、各社の対応が急速に進んでいます。 Amazon 自身も、こうした Agentic Commerce の実装を既に提供しています。Amazon Shopping アプリ内の AI アシスタント「Rufus」（2026 年 5 月より Alexa と統合し「Alexa for Shopping」としてリニューアル）は、Amazon Bedrock を活用して数億人規模の顧客に会話型の商品検索・比較体験を提供しており、その裏側のアーキテクチャは こちらのブログ で詳しく紹介されています。Onsite Agent（EC サイト上での接客エージェント）の実運用例として参考になる内容です。 日本国内でも、EC サイト上に AI アシスタントを組み込む取り組みや、AI プラットフォーム上に自社の商品を発見してもらう取り組みが、複数の企業で始まりつつあります。 AWS Summit Japan 2026 の会場では、こうした AI エージェントが商品を探し、比較し、購入するという新しい EC の姿を、実際に動くデモとともにご紹介しました。AI プラットフォーマーが提供する Incoming Agent から EC サイトに流入し、そのまま自社 EC サイト上の Onsite Agent による接客を経て購入に至るまで、そして裏側で動く EC バックエンド・バックオフィスの仕組みまで、一つの Demo システムとして統合してご覧いただきました。 このブログでは、当日の様子や Demo シナリオ、ブースでご紹介した Demo システムのアーキテクチャをダイジェストでご紹介します。 AWS 展示ブーステーマ 「Future of Agentic Commerce」 AI プラットフォーマーが提供するショッピング機能や、EC プラットフォーマーが組み込む AI エージェントの台頭により、消費者の商品発見から購入までの体験は大きく変わり始めています。この変化を「来たる Agentic Commerce 時代を売上向上の Big Opportunity に」できるよう、ブースでは実際に稼働する Demo システムを通じて、Agentic Commerce の実装イメージを具体的にご覧いただきました。 デモのご紹介に入る前に、本デモに登場する 2 種類のエージェントについて簡単に整理します。 Incoming Agent（インカミングエージェント）: AI プラットフォーマー側（チャットアプリや AI アシスタントなど）に存在し、ユーザーに代わって複数の EC サイトを横断的に検索・比較し、商品を推薦・購入までつなぐエージェントです。ユーザーは EC サイトを直接訪れるのではなく、普段使っている AI プラットフォーム経由で EC 事業者の商品と出会います。その後、AI Agent が決済まで終わらせるケースもあれば、EC サイトへ流入するケースもあります。 Onsite Agent（オンサイトエージェント）: EC 事業者が自社サイト上に実装するエージェントで、訪問したユーザーに対して商品検索・比較・接客を行います。従来の EC サイト内検索やレコメンドの役割を、対話型のエージェントが担う形です。 本デモでは主に Incoming Agent 経由の体験を中心にご紹介しつつ、Onsite Agent による自社 EC 上での接客体験もあわせてご覧いただける構成にしています。 デモでは、次の 6 つのストーリーをご覧いただけるようにしています。 複数の EC 事業者にまたがって商品を探し、1 つの仮想的なカートで管理した上で、AI プラットフォーマーが提供するウォレットで購入するケース（購入の最終確認はユーザー自身が行い、確認ボタンを経て決済する） 同じくウォレットでの購入において、あらかじめ 5,000 円以下の決済権限をエージェントに与えておき、その条件に該当する場合はユーザーの確認なしにエージェントが購入まで自律的に実行するケース 仮想的なカートに商品を入れるところまでは同様だが、そこから「EC で購入したい」ボタンを押すことで、連携先の EC 事業者側のカートに商品が転送され、そちらで購入を完了できるケース Onsite Agent が自社 EC 上で最適化された UI/UX を通じて、来訪したお客様をおもてなしするケース なお、このデモの決済には Amazon Pay を採用しています。Amazon Pay の Payment Method On File（PMOF） は、初回に支払い方法を設定しておくことで、以降はワンクリックで決済が完了する方式です。Onsite Agent との対話から購入確定までをチャット UI 内で完結させる、スムーズな決済体験を実現しています。さらに本デモでは、ECP を通じて AI プラットフォーム側のエージェントからも同じ Amazon Pay 決済を呼び出せる実装としています。 友達同士で買い物をするケース：それぞれのユーザーに紐づいた AI エージェントが、購入前に互いに会話をして、各ユーザーの趣味・嗜好データを踏まえながら「何を買うか」「予算をどうするか」を事前に調整し、方針が決まったところで「こういう議論をしてこう決まったけれど、これでいいですか」とユーザー本人に確認を取る、という未来の購買体験を示すコンセプトデモ 注文した商品が在庫切れとなった場合の例外処理を EC バックオフィスエージェントが検知し、ユーザーに代替品を提案するケース Agent に Apps を導入して EC 側のデザインやビジネスロジックを持ち込むケース Demo システム全体像 Demo システムは、AI プラットフォーム側の Incoming Agent と、EC 事業者側の EC フロントエンド・EC バックエンド・EC バックオフィスエージェントまでを一つのシステムとして統合し、Agentic Commerce の一連の流れを再現しました。（図の Amazon Bedrock AgentCore runtime アイコンが見えづらいのですが、MCP, UCP Server を ホストしています。） AI プラットフォーム側の Incoming Agent: AI プラットフォーム側から EC 事業者の商品を発見・推薦するエージェント。 UCP (Universal Commerce Protocol: AI Agent が購買するために必要な一連の機能と I/F を定義したプロトコル) / AP2 (Agent Payments Protocol: AI Agent が決済時に使用するプロトコル) / ECP (Embedded Checkout Protocol) / MCP Apps (Model Context Protocol Apps: UI 転送を伴う MCP) といった複数のコマースプロトコルに対応 EC フロントエンド: 自社 EC サイトに実装した Onsite Agent が、MCP Apps を通じて商品検索・接客を提供 EC バックエンド: 商品 Feed、在庫、決済などの機能を EC API・MCP/UCP 経由で提供。複数の Agent 間連携は A2A（Agent-to-Agent）Mesh で実装 EC バックオフィスエージェント: 発注、顧客管理、在庫管理と連携し、例外処理の解決を行う AI プラットフォーマー側を入り口にして、自社の EC サイトで決済をしていくというユーザーストーリーまで、一連のカスタマージャーニーを実現しています。 Demo システムで利用している AWS サービス 用途 AWS サービス AI プラットフォーム側 Agent、EC の認証サービス Amazon Cognito 静的アセットの配信 Amazon CloudFront 静的アセットの配置 Amazon S3 API 呼び出し、Agent 呼び出し時の入り口 Amazon API Gateway ビジネスロジックの実装 AWS Lambda EC / UCP checkout session の管理 Amazon DynamoDB 商品 Feed からの検索 Amazon OpenSearch Serverless 商品 Feed の連携 AWS Step Functions AP2 の鍵管理 AWS Secrets Manager LLM 推論 Amazon Bedrock （Claude Sonnet 4.6） Agent、MCP Server の Host Amazon Bedrock AgentCore ※ 決済には Amazon Pay（AWS サービス外）を利用しています。詳細は後述の「アーキテクチャのポイント」をご参照ください。 アーキテクチャのポイント AI プラットフォーマー側 AI Agent は Amazon Bedrock AgentCore runtime 上に Strands Agents で実装 商品検索は Amazon OpenSearch Serverless で実装 すべての推論は Amazon Bedrock 経由で Claude Sonnet 4.6 を利用 EC 事業者側 OpenSearch Serverless への Ingest パイプライン（商品が追加されるとベクトル化 → Ingest を自動実行）を実装 MCP Apps Server、UCP（MCP）Server も Amazon Bedrock AgentCore runtime 上にパススルー構成で実装 複数の Agent 間連携は A2A（AgentCore runtime 上）で実装 決済は Amazon Pay の Payment Method On File（PMOF）で実装。初回設定以降はワンクリックで決済が完了し、Onsite Agent の購買体験を途切れさせない。ECP 経由で AI プラットフォーム側からも呼び出し可能 プロトコルについて（UCP / AP2 / ECP） 本デモでは、Agentic Commerce を支える複数のコマースプロトコルに対応しています。それぞれの位置づけは以下のとおりです。 UCP（Universal Commerce Protocol）: Google と Shopify が中心となって策定した、AI エージェントが商品発見・条件交渉・チェックアウト・購入後のデータ連携までを行うためのオープンな仕様です。 AP2（Agent Payments Protocol）: Google が提唱する、暗号署名された Mandate（委任状）を用いて、エージェントによる決済を安全かつ検証可能な形で実行するためのプロトコルです。UCP と組み合わせて利用され、現在は FIDO Alliance がガバナンスを担っています。 ECP（Embedded Commerce Protocol）: UCP を EC サイト内に埋め込む形（embedded 版）で利用するための実装形態を指します。本デモでは、ギフト設定が可能な EC 側のチェックアウト画面を AI PF 側に転送する仕組みや、そのチェックアウト画面にて EC 事業者が使用する決済手段を指定する仕組みとして活用しています。 これらのプロトコルは 2026 年に入ってから急速に整備が進んでいる分野であり、今後も仕様のアップデートが続くことが予想されます。最新の動向は各プロトコルの公式サイトをご確認ください。 認証について（補足） 今回の Demo では、認証はすべて Amazon Cognito で一元管理し、AI プラットフォーマー側と EC 事業者側の ID を単一の Cognito で代替しています。ただし本来、AI プラットフォーマーと EC 事業者間の ID 連携は、世界的にもまだ標準化の議論が進行中で、業界標準は定まっていません。今回のデモでは、その先にある体験（ID 連携済みの世界）を示すために、便宜上 1 つの Cognito に統合している点にご留意ください。 実装上の注意点 今回のデモでは MCP Apps Server・UCP Server を Amazon Bedrock AgentCore runtime 上にパススルー構成で自前実装していますが、これが唯一の実装パターンというわけではありません。Agentic Commerce を取り巻くプロトコルやサービスはまだ発展途上であり、今後リファレンスアーキテクチャが出てくることが期待されます。 ご来場いただいたお客様の声 ブースにお立ち寄りいただいたお客様からは、たくさんの生の声をいただきました。 まず印象的だったのは、「AI エージェントに決済まで任せたい」という声はそれほど多くなく、むしろ「AI プラットフォーマーに自社の商品を推薦してもらい、自社の EC サイトへ流入させたい」というニーズを持つお客様が多かった点です。Agentic Commerce というと購入・決済の自動化に注目が集まりがちですが、現場の実感としては、まず「見つけてもらうこと」への関心の高さがうかがえました。 また意外な反応をいただいたのが、「友達同士で買い物をする」というコンセプトデモです。「これはいいね」という反応もあれば、「ここまで技術的にできるんですね」と驚かれるお客様もいらっしゃり、Agentic Commerce の可能性を考えるきっかけとして興味深い反応をいただきました。 そしてもう一つ大きな評価をいただいたのが、「Agentic Commerce という言葉は知っているが、実際にどういう挙動をするものなのか、業界としてどこまで進んでいるのか（全体像）がわからない」という声に対して、ブースが一つの「アンサー」を示せたという点です。実際に「Agentic Commerce という名前しか知らず、何のことかよくわからなかったが、このブースを見て完全に理解できた。自分たちが何を検討すればいいかが分かった」と言って帰られたお客様もいらっしゃいました。まだ日本国内では実際に触れられる Agentic Commerce の実装例が少ない中、こうした「わかる」体験を提供できたことは、現在の日本市場において意味のあることだったと感じています。 まとめ Agentic Commerce は、まだ「購入の最終判断は人間が行う」段階にあるものの、AI プラットフォーマーや EC プラットフォーマーによる対応が急速に進んでおり、日本国内でも Onsite Agent・Incoming Agent の取り組みが着実に増え始めています。 AWS Summit のブースでご紹介した Demo システムは、 Amazon Bedrock AgentCore を中心に、Incoming Agent・Onsite Agent・MCP Apps Server・UCP（AP2）Server・A2A による Agent 間連携までを、実際に動く形で統合したものです。ぜひ皆さまの自社 EC における Agentic Commerce 対応の第一歩として、AWS サービスをご活用ください。 これからも、AWS 小売・消費財チームはユーザー企業様間の情報共有・議論の場をご提供し、1 つでも多くのお客様ビジネス課題の解決をご支援させていただく所存です。今後ともご期待ください！ 著者 中島　佑樹 西日本の小売・消費財のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としています。Agentic Commerce x AWS を推進中。最近 Google AI 要約で “日本の Agentic Commerce の有名なエンジニア?” で検索すると自分の名前が出てくることに喜びを感じています。 木下 尚英 (Naohide Kinoshita)  アマゾンジャパン合同会社 Amazon Pay シニアソリューションアーキテクト  Amazon Pay の日本の事業者様向け技術支援を担当しています。カートシステムを提供するプラットフォーム事業者様から大手・中小の EC 事業者様まで、業種を問わず数多くの導入・ローンチをご支援してきました。最近は決済の観点から Agentic Commerce の実装を検討・提案しています。好きなサービスは Amazon Bedrock AgentCore です。趣味はガンプラと旅行です。 堀内 保大 (Yasuhiro Horiuchi) / @ka_shino_ki アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 大規模なWeb系のお客様をご支援する傍ら、Eコマース関連のお客様を横断的に技術支援しています。 好きなサービスは、Amazon EKS や Amazon ECS 等のコンテナ関連サービスですが、最近はAmazon AgentCore Evaluationsに夢中です。趣味は旅行とスノーボードです。 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon Quick です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。ソリューションアーキテクトの 寺山です。 AutoGluon-Cloud v0.5.0 のアップデートにより、Chronos-2 は Amazon SageMaker AI へコード数行でデプロイ/利用できるようになりました。デプロイが簡単になった今、本番運用で本当に悩むのは「どの推論タイプを選ぶか」です。本記事ではアップデートの要点を押さえたうえで、3 つの推論パターン(リアルタイム推論：Realtime Inference、サーバーレス推論：Serverless Inference、バッチ変換：Batch Transform)をユースケースに応じてどう使い分けるかを具体的に紹介します。 1.背景 AutoGluon-Cloud は、 AutoGluon を Amazon SageMaker AI 上で実行するためのデプロイ・推論ライブラリです。v0.5.0 の核心は、Foundation Model 向けの新クラス（ TimeSeriesFoundationModel ）の追加です。学習（fit）ステップが不要になり、 model_id="chronos-2" を指定するだけで、この共通クラスから 3 つの推論タイプすべてにデプロイ・推論できますこれにより、 Chronos 2 on Amazon SageMaker AI のデプロイ~ 推論までをコード数行で 実現できるようになりました。 AutoGluon-Cloud には v0.5.0 以前 Foundation Model 専用のクラスが存在せず、Chronos-2 のようなゼロショットモデルを扱う手段がありませんでした。また異なる手段として、 Amazon SageMaker JumpStart からリアルタイム推論にアクセスできます。一方で、サーバーレス推論・バッチ変換にはモデルアーティファクトの再パッケージなど一手間が必要でした。 Autogluon-Cloud v0.5.0 の登場により、SageMaker AI 上にデプロイする 3 パターンとも同じ手軽さでアクセスできるようになりました。 その他の変更点（詳細は リリースノート 参照）: bootstrap() による 1 コマンドセットアップ、ローカルに AutoGluon 本体が不要（pip install autogluon.cloud のみ） サーバーレス推論のサポート、共変量（known_covariates）のフルサポート Note: v0.5.0 より前のバージョンでデプロイしたエンドポイントは互換性がありません。再デプロイが必要です。 2. 事前準備 デプロイする全ての環境（AWS アカウントとリージョンの組み合わせ） をブートストラップする必要があります。bootstrap() を実行するだけで、SageMaker が利用する IAM ロールと S3 バケットが自動的に作成され、設定は ~/.autogluon/cloud.yaml に保存されます。環境がすでにブートストラップされているかどうかが不明な場合は、いつでもコマンドを再実行できます。 既存のロール・バケットを使う場合は register() で登録します。 pip install autogluon.cloud  from autogluon.cloud import bootstrap  bootstrap()  # 初回のみ実行すれば十分  `bootstrap()`は、IAM ロールや S3バケットが未設定の場合に実行するものです。既にリソースがある場合は`register()`で登録できます。いずれも設定は`~/.autogluon/cloud.yaml`に保存され、以降の呼び出しで自動的に読み込まれます。この保存済み設定を使わず、呼び出しごとに明示的にリソースを渡したい場合は、IAM ロールの ARN と S3 パスを直接指定することもできます。 3. Chronos-2 をデプロイする3つの方法 Autogluon-Cloud を使うと、Chronos-2 は 3 つの推論タイプから選択して設定すると SageMaker AI 上にデプロイできます。もちろん、このライブラリを使わなくても Amazon SageMaker AI 上にデプロイできます。その場合は、推論タイプもこの３つに限りません。 下記では、３つの推論タイプそれぞれでコード例を示します。例はすべて同じ入力データ・同じ予測タスクを想定しています。今回は具体的なデータを用意しているわけではありませんが、サンプルコードの理解のためにデータについて補足します。 data : 店舗・SKU ごとの過去の売上時系列（列: id＝系列の識別子、timestamp＝日時、Sales＝売上） target =”Sales”: 予測したい対象列 known_covariates : 予測期間中に既知の説明変数（例: 価格やプロモーション実施の有無）。Chronos-2 が共変量を使って予測精度を高める prediction_length =13: 何ステップ先まで予測するか（例: 13 週先までの週次売上） 「何を予測したいか」を target に、「その予測に効く既知の情報は何か」を known_covariates に対応させて考えると、どのカラムをどこに渡せばよいかイメージしやすくなります。例えばコールセンターの入電数予測であれば、target は入電数、known_covariates はキャンペーン実施の有無や祝日フラグに相当します。 3.1 リアルタイム推論 図1 : リアルタイム推論の場合の構成 GPU/CPU インスタンスを選択でき、常時稼働してリクエストに即座にレスポンスを返します。 model.deploy() で SageMaker 上にエンドポイントが立ち上がり、以降は endpoint.predict() を呼ぶたびに Client Application からのリクエストがそのエンドポイントに直接渡されます。図1 では、ラップトップからSageMaker 上に モデルをデプロイする構成を示しています。 from autogluon.cloud import TimeSeriesFoundationModel model = TimeSeriesFoundationModel(model_id="chronos-2") endpoint = model.deploy(instance_type="ml.g5.xlarge") predictions = endpoint.predict( data=data, target="Sales", id_column="id", timestamp_column="timestamp", prediction_length=13, known_covariates=known_covariates, ) endpoint.delete_endpoint() 3.2 サーバーレス推論 図2 : サーバーレス推論の場合の構成 サーバーレス推論を実行したい場合、リアルタイム推論を実現するコードとの差分は inference_mode=”serverless” の指定です。 このサーバーレス推論ではリクエストがない間はインスタンス台数はゼロにスケールし、推論時間のみ課金されます。ネットワーク分離環境で動作するため、モデルを事前に S3 にキャッシュする必要があります。 model = TimeSeriesFoundationModel(model_id="chronos-2") cached = model.cache_model_artifact("s3://my-bucket/fm-cache") endpoint = cached.deploy(inference_mode="serverless") predictions = endpoint.predict( data=data, target="Sales", id_column="id", timestamp_column="timestamp", prediction_length=13, ) endpoint.delete_endpoint() 3.3 バッチ変換 図3 : バッチ変換の場合の構成 バッチ変換では、エンドポイントをデプロイせず、model.predict() に直接データを渡します。 ジョブとしてデータを処理し、完了後にリソースは自動シャットダウンされます。 model = TimeSeriesFoundationModel(model_id="chronos-2") future = model.predict( data=data, target="Sales", id_column="id", timestamp_column="timestamp", prediction_length=13, known_covariates=known_covariates, wait=False, ) print(future.status()) # 'InProgress' predictions = future.result() # 完了まで待機し DataFrame を返す data には DataFrame だけでなく、ローカルファイルや S3 パス（ s3://my-bucket/data.csv ）も直接渡せます。大規模データをすでに S3 に置いている場合は、DataFrame にロードし直さずそのまま渡せます。また予測結果は内部で S3 を経由して書き出されます。デフォルトでは {cloud_output_path}/{job_name}/predictions.csv に保存され、 predictions_path で明示的な出力先を指定することも可能です。 4. ユースケースに合わせた推論タイプの選定 3 パターンすべてに同じ手軽さでデプロイできるようになった今、実務で最も重要な判断は「どの推論タイプが自分のユースケースに合うか」です。 制約を比較する SageMaker AI の制約: 項目 リアルタイム推論 サーバーレス推論 バッチ変換 ペイロード上限 6 MB 4 MB 100 MB / 1 レコード（S3 経由） タイムアウト 60 秒 60 秒 なし GPU 利用 選択可能 選択不可（CPU のみ） 選択可能 課金 常時稼働 推論時間のみ ジョブ時間のみ コールドスタート なし あり N/A（ジョブ起動に数分） 注意したいのは サーバーレス推論が CPU 専用であることです。Chronos-2 は GPU で強みを発揮するモデルのため、サーバーレスを選ぶ場合は系列数やレイテンシ要件を見積もった上でご利用ください。 推論タイプによる違いはありませんが、Chronos-2 モデル自体の制約もあります。 時間軸方向の最大コンテキスト長は 8,192 ステップ 時間軸方向の最大出力長は 1,024 ステップ cross_learning モード（デフォルト有効）は batch_size 単位で系列をグループ化して共同予測を行う。系列数にハードリミットはないが、 batch_size=100 程度が推奨 推論タイプの選び方例 リアルタイム推論を選ぶシーン: 店長が共変量（価格、プロモーション等）を変えながら対話的に予測し、発注量を決める（What-if 分析） AI エージェントから高頻度で予測 API を呼び出す 系列数が多く GPU を使いたい、かつオンデマンドでレスポンスが必要 サーバーレス推論を選ぶシーン: What-if 分析を行うが利用頻度が低く、エンドポイントの常時課金を避けたい PoC や検証フェーズで、コストを最小限に抑えつつ動作確認したい データサイズが小さく（4 MB 以下）、CPU 推論とコールドスタートを許容できる バッチ変換を選ぶシーン: 定期実行（日次・週次）で、全店舗・全 SKU の予測をまとめて生成する 大量の系列を一括処理したく、タイムアウトやペイロード制限を気にしたくない 予測結果を S3 に書き出し、後続のパイプラインやレポートに利用する 5. まとめ AutoGluon-Cloud v0.5.0 により、Chronos-2 はリアルタイム・サーバーレス・バッチのいずれにも、同じ TimeSeriesFoundationModel クラス・数行のコードでアクセスできるようになりました。デプロイの複雑さという障壁が下がった今、向き合うべき問いは「どう実装するか」ではなく「自分たちのユースケースにどの推論タイプが最適か」です。 デプロイ後のエンドポイントは Amazon SageMaker AI のエンドポイントとして扱えるため、既存の監視やコスト管理にもそのまま組み込めます。まずはサーバーレスで小さく試し、要件が固まってからリアルタイムやバッチへ移行する、という段階的な導入も一つの手です。ぜひ自分たちのデータで動かしてみてください。 寺山 怜志 (Satoshi Terayama) 外食業界や百貨店業界のお客様を支援しているソリューションア―キテクトです。 最近は、時系列基盤モデル Chronos-2 を始めとした機械学習領域での学びを深めています

本記事は 2026 年 3 月 19 日 に公開された「 Synchronizing a Backup on-premises Db2 Server with Amazon RDS for Db2 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 は、プロビジョニング、パッチ適用、バックアップ、スケーリングといった手間のかかる作業を自動化し、リレーショナルデータベースの管理をシンプルにするフルマネージドサービスです。運用効率を高め、マルチ AZ 配置による高可用性を実現し、セキュリティを強化します。そのうえでインフラの保守ではなくアプリケーション開発に集中できます。 本記事では、セルフマネージドの Db2 インスタンスをアーカイブログの継続的な適用によって Amazon RDS for Db2 と同期させ続けるハイブリッドアーキテクチャの構築方法を説明します。これにより、クラウドネイティブなマネージドサービスの利点を損なうことなく、戦略的な配置の選択肢を維持できます。 ソリューションの概要 本ソリューションは、Amazon RDS for Db2 と同期を維持するオプションのセルフマネージド Db2 緊急バックアップサーバーを構築するハイブリッド構成です。基本的な仕組みとしては、Amazon RDS for Db2 インスタンスがアーカイブログを Amazon Simple Storage Service (Amazon S3) バケットにレプリケートし、セルフマネージドのオンプレミス Db2 インスタンスがそのアーカイブログを適用し続けます。先回りで同期を続けることで、バックアップがリアルタイムで最新の状態に保たれ、予期しない障害が発生した際にすぐに稼働させられます。 ソリューションは 3 つのステージで構成されます。 ステージ 1: Amazon RDS for Db2 でデータベースを構築する Amazon RDS for Db2 にデータベースをリストアする 緊急用セルフマネージドバックアップサーバーにデータベースをリストアする Amazon RDS for Db2 にアーカイブログを適用し続ける 緊急用セルフマネージドバックアップサーバーにアーカイブログを適用し続ける ステージ 2: Amazon RDS for Db2 へ移行する 最後のロールフォワードログを適用し、ロールフォワード処理を完了する RDS for Db2 に接続できるようになる アプリケーションの接続先を Amazon RDS for Db2 に切り替える 従来のセルフマネージド Db2 サーバーを停止するか、別の用途に転用する ステージ 3: Amazon RDS for Db2 との継続的なバックアップ同期を確立する 緊急バックアップサーバーをアーカイブログと同期させ続ける 緊急バックアップサーバーを常にロールフォワード保留モードに保つ オプション: セルフマネージドサーバーへ切り戻す状況が生じた場合は、最後のログを適用してロールフォワード操作を完了し、データベースに接続できるようにする 前提条件 RDS for Db2 のアーカイブログを Amazon S3 にコピーできるのは、データベース作成時にバックアップ期間が設定されている場合のみです。アーカイブログを生成するには、バックアップ保持期間を有効にする必要があります。 aws rds modify-db-instance \ --db-instance-identifier <your-db-instance-identifier> \ --backup-retention-period <days> \ --apply-immediately 注: your-db-instance-identifier と日数 (有効な値は 1 ～ 35 日) を指定してください。 以降のセクションでは、RDS for Db2 のアーカイブログファイルを Amazon S3 バケットにコピーする手順を説明します。 Amazon S3 へのアーカイブログコピーを設定する前に、以下を用意してください。 稼働中の Amazon RDS for Db2 インスタンス バックアップとアーカイブログを保存する Amazon S3 バケット Amazon S3 統合に適した AWS Identity and Access Management (IAM) 権限 (次のセクションで詳しく説明します) 互換性のある Db2 バージョンで稼働するセルフマネージド Db2 インスタンス (Amazon EC2、他のクラウドプロバイダー、またはオンプレミス上) Amazon S3 からセルフマネージド Db2 サーバーへファイルをダウンロードするためのネットワーク接続 Amazon S3 統合と権限を設定する Amazon RDS for Db2 が S3 バケットにアーカイブログをコピーできるようにするには、適切な IAM 権限を設定する必要があります。この手順は、標準的な Amazon RDS for Db2 の Amazon S3 統合 と同様です。 以下の手順を実行します。 Amazon RDS for Db2 に S3 バケットへのアクセスを許可する IAM ポリシーを作成します。 { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3BucketAccess", "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt", "s3:PutObject", "s3:GetObject", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:GetObjectVersion", "s3:ListMultipartUploadParts", "s3:GetBucketAcl", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3::: <amzn-s3-demo-bucket> /*", "arn:aws:s3::: <amzn-s3-demo-bucket> " ] }, { "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": [ "*" ] } ] } 注: <amzn-s3-demo-bucket> を実際の S3 バケット名に置き換えてください。 作成したポリシーを使って IAM ロールを作成します。 Amazon RDS がこのロールを引き受けられるように、次の信頼関係を追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } この IAM ロールを、 AWS Management Console または AWS Command Line Interface (AWS CLI) を使って RDS for Db2 インスタンスに関連付けます。 Amazon S3 へのアーカイブログコピーを有効にする (ステージ 1) この最初のステージでは、Amazon RDS for Db2 がアーカイブログを S3 バケットに自動でレプリケートするよう設定し、継続的な同期の基盤を築きます。有効にすると、アーカイブログが継続的に S3 にアップロードされ、トランザクションデータのリアルタイムストリームが生成されます。このストリームを適用することで、ハイブリッドアーキテクチャ全体でデータベースの一貫性を保てます。 IAM 権限を設定したら、RDS for Db2 インスタンスでアーカイブログのコピーを有効にできます。以下の手順を実行します。 RDS for Db2 の RDSADMIN データベースに接続し、アーカイブログのコピー先となる S3 ロケーションを設定します。 db2 "connect to RDSADMIN user <masterUserName> using <masterPassword> " db2 "call rdsadmin.set_configuration('ARCHIVE_LOG_COPY_TARGET_S3_ARN', 'arn:aws:s3:::/ <my_rds_db2_backups> / <prefix path> ')" <my_rds_db2_backups> を実際の S3 バケット名に置き換え、目的の <prefix path> を指定してください。 対象のデータベースでアーカイブログのコピーを有効にします。 db2 "call rdsadmin.enable_archive_log_copy(?, ' <database_name> ')" <database_name> を実際のデータベース名 (例: RLSDB1 ) に置き換えてください。 設定を確認するには、アーカイブログコピーのステータスをチェックします。 db2 "select * from table(rdsadmin.list_databases())" --The following is a sample output: DATABASE_NAME CREATE_TIME DATABASE_UNIQUE_ID ARCHIVE_LOG_RETENTION_HOURS ARCHIVE_LOG_COPY ARCHIVE_LOG_LAST_UPLOAD_FILE ARCHIVE_LOG_LAST_UPLOAD_FILE_TIME ARCHIVE_LOG_COPY_STATUS --------------- -------------------------- -------------------------------------------- --------------------------- ---------------- ---------------------------- --------------------------------- ----------------------- RDSADMIN 2025-12-12-20.24.10.222944 RDSADMIN 0 DISABLED - - - RLSDB1 2025-12-12-20.45.39.867726 35FFE475-D381-43A9-B5B6-475C1C589CDE 0 ENABLED S0000001.LOG 2025-12-13-10.30.15.123456 COMPLETED 対象のデータベースで ARCHIVE_LOG_COPY のステータスが ENABLED になっていることを確認します。 アーカイブログを Amazon S3 にコピーする詳細については、 Copying archive logs to Amazon S3 を参照してください。 セルフマネージド Db2 インスタンスにデータベースをリストアする (ステージ 2) このステージでは、オンラインバックアップイメージからリストアしてセルフマネージド Db2 インスタンスのベースラインを確立します。バックアップイメージには、移行時に取得した元のバックアップか、Amazon RDS for Db2 から新たに取得したバックアップのいずれかを使用します。リストア操作を行うと、データベースはロールフォワード保留状態になり、Amazon S3 からのアーカイブログの継続的なストリームを受け取って適用できる状態になります。 セルフマネージドの緊急バックアップ Db2 サーバーに適用できるオンラインバックアップイメージが必要です。この場合、2 つの選択肢があります。 緊急バックアップサーバーに同じオンラインバックアップを適用する 移行の過程で、現在のオンプレミス Db2 サーバーからオンラインバックアップを取得し、同じオンラインバックアップを Amazon RDS for Db2 と、もう 1 台の緊急バックアップ用セルフマネージド Db2 サーバーの両方に適用します。 Amazon RDS for Db2 からオンラインバックアップを取得する Amazon RDS for Db2 インスタンスからオンラインバックアップを取得し、オンプレミスの Db2 インスタンスに適用できます。 db2 "connect to RDSADMIN user <masterUserName> using <masterPassword> " db2 "call rdsadmin.backup_database(?, ' <database_name> ', 'Online', 'arn:aws:s3:::/ <online-backup-bucket-name> / <prefix-path> ')" このコマンドにより Amazon S3 上にバックアップイメージが作成されます。このイメージをリストアしたうえでアーカイブログを使って継続的に更新し、別のお客様管理の Db2 サーバーに反映できます。 Amazon RDS for Db2 との継続的なバックアップ同期を確立する (ステージ 3) この最終ステージでは、S3 からアーカイブログを定期的にダウンロードし、ロールフォワード操作によってセルフマネージド Db2 インスタンスに適用することで、継続的な同期を実現します。データベースをロールフォワード保留モードに保ち、新しいログを定期的に適用することで、Amazon RDS for Db2 インスタンスとセルフマネージドバックアップサーバーの間でリアルタイムの同期を維持でき、さまざまなビジネスシナリオに対応できる運用上の柔軟性が得られます。 セルフマネージドの Db2 で、S3 バケット用のストレージエイリアスを作成します。 db2 catalog storage access s3_backup \ type s3 \ server 's3.amazonaws.com' \ container '' \ object_path '/ <offline-backup-bucket-name> /' \ authentication 'AWS_IAM' ストレージアクセスのカタログ登録の詳細については、 IBM Db2 catalog storage access documentation を参照してください。 バックアップイメージが Amazon S3 上にある場合のデータベースのリストア db2 restore database <source_dbname> from s3_backup \ taken at <timestamp> \ into <target_dbname> \ REPLACE EXISTING \ WITHOUT ROLLING FORWARD restore コマンドの詳細については、 IBM Db2 restore documentation を参照してください。 バックアップイメージがローカルファイルシステム上にある場合のデータベースのリストア db2 restore database <source_dbname> from /db2backup/ \ taken at <timestamp> \ into <target_dbname> \ REPLACE EXISTING WITHOUT ROLLING FORWARD を省略すると、データベースはロールフォワード保留状態のままになります。 アーカイブログを適用する (ロールフォワード) オンラインバックアップをリストアすると、データベースはロールフォワード保留状態になります。ここからアーカイブログを継続的に適用して、RDS インスタンスとの同期を保てます。 ログを継続的に適用するには、以下の手順を実行します。 セルフマネージドシステムで、アーカイブログ用のディレクトリを作成します。 mkdir -p /db2logs/archive S3 からアーカイブログをダウンロードします。 aws s3 sync s3:// <my_rds_db2_backups> /archive-log-copy/ /db2logs/archive/ ログを適用します。 db2 rollforward database <target_dbname> \ to end of logs \ and stop \ overflow log path /db2logs/archive 特定の時点までログを適用するには、次のコードを使用します。 db2 rollforward database <target_dbname> \ to <timestamp> \ using local time \ overflow log path /db2logs/archive 継続的な同期を維持する Amazon S3 のアーカイブログの監視は、お客様の責任で行う必要があります。アーカイブログを削除すると判断した場合は、セルフマネージド Db2 のデータベースを最初からやり直す必要があります。また、削除したアーカイブログを復元する方法はありません。 セルフマネージドのデータベースを Amazon RDS と同期させ続けるには、以下の手順を実行します。 新しいアーカイブログを定期的にダウンロードするスケジュールジョブを設定します。 */15 * * * * aws s3 sync s3:/// <my_rds_db2_backups> /archive-log-copy/ /db2logs/archive/ 新しいログが届いたら適用します。 db2 rollforward database <target_dbname> \ to end of logs \ overflow log path /db2logs/archive 後でさらにログを適用し続けたい場合は、 and stop を使用しないでください。 データベースを接続可能な状態にする準備ができたら、次のコードを使用します。 db2 rollforward database <target_dbname> \ to end of logs \ and stop \ overflow log path /db2logs/archive and stop 句を指定すると、ロールフォワード処理が完了し、データベースが接続可能になります。 アーカイブログのコピーを無効にする アーカイブログのコピーを無効にする必要がある場合は、次のコードを使用します。 db2 "call rdsadmin.disable_archive_log_copy(?, ' <database_name> ')" アーカイブログのコピーステータスを監視する アーカイブログのコピーステータスを定期的に確認します。 db2 "select DATABASE_NAME, \ ARCHIVE_LOG_COPY, \ ARCHIVE_LOG_LAST_UPLOAD_FILE, \ ARCHIVE_LOG_LAST_UPLOAD_FILE_TIME \, ARCHIVE_LOG_COPY_STATUS \ FROM TABLE (rdsadmin.list_databases())" 監視すべき主なフィールドは以下のとおりです。 ARCHIVE_LOG_COPY は ENABLED と表示されるはずです ARCHIVE_LOG_LAST_UPLOAD_FILE は最後にアップロードされたログファイルを示します ARCHIVE_LOG_LAST_UPLOAD_FILE_TIME は最後のアップロードのタイムスタンプを示します ARCHIVE_LOG_COPY_STATUS はアップロードが成功していれば UPLOADING と表示されるはずです よくある問題のトラブルシューティングと解決策 このセクションでは、よくある問題とその解決策について説明します。 設定エラー 主に Amazon S3 の設定の問題により、次のようなエラーメッセージが表示されることがあります。 S3_INVALID_ARN_FORMAT – Amazon S3 の Amazon リソースネーム (ARN) の形式が無効です。Amazon S3 の ARN が AWS パーティションに対して正しい形式になっているか確認してください。 S3_NON_S3_SERVICE – ARN が Amazon S3 のものではありません。有効な S3 バケットの ARN を指定してください。 S3_REGION_MISMATCH – アーカイブログコピーの設定エラー: S3 バケットのリージョンが RDS インスタンスのリージョンと一致しません。S3 バケットが RDS インスタンスと同じリージョンにあることを確認してください。 S3_ACCOUNT_MISMATCH – S3 バケットのアカウントが AWS アカウントと一致しません。S3 バケットが RDS インスタンスと同じ AWS アカウントに属していることを確認してください。 S3_BUCKET_NOT_EXISTS – S3 バケットが存在しません。バケットを作成してから再試行してください。 S3_BUCKET_OWNERSHIP_MISMATCH – S3 バケットが AWS アカウントによって所有されていません。バケットが RDS インスタンスと同じ AWS アカウントに属していることを確認してください。 S3_BUCKET_PUBLIC_ACCESS – S3 バケットが一般公開されています。セキュリティ上の理由から、バケットのパブリックアクセスを無効にしてください。 S3_BUCKET_ACCESS_VALIDATION_FAILED – S3 バケットの権限を検証できません。IAM ロールにこのバケットへアクセスするために必要な権限があるか確認してください。 Amazon S3 関連の設定の問題の詳細については、 Viewing Amazon RDS events を参照してください。 IAM 権限のエラー アーカイブログコピーのステータスが CONFIGURATION_ERROR と表示される場合や、バックアップ操作が権限エラーで失敗する場合は、次のようにトラブルシューティングします。 IAM ポリシーに s3:PutObject 、 s3:GetObject 、 s3:ListBucket 、 s3:DeleteObject の権限が含まれているか確認します IAM ロールが RDS インスタンスに正しく関連付けられているか確認します 信頼関係で rds.amazonaws.com がロールを引き受けられるようになっているか確認します S3 バケットポリシーに矛盾する拒否ステートメントがないか確認します アーカイブログが Amazon S3 に表示されない ARCHIVE_LOG_COPY が有効になっているのに Amazon S3 にログが表示されない場合は、次のようにトラブルシューティングします。 設定で Amazon S3 の ARN が正しく指定されているか確認します データベースにログを生成するアクティブなトランザクションがあるか確認します RDS for Db2 のエラーログでコピーの失敗がないか確認します S3 バケットが存在し、同じリージョンにあるか (またはクロスリージョンレプリケーションが設定されているか) を確認します ロールフォワードがログの欠落で失敗する ロールフォワード操作が「log file not found」エラーで失敗する場合は、次のようにトラブルシューティングします。 バックアップのタイムスタンプから対象のタイムスタンプまでのすべてのアーカイブログがダウンロードされているか確認します ログシーケンス番号に抜けがないか確認します オーバーフローログパスが正しく指定されているか確認します Db2 インスタンスのユーザーがログディレクトリに対する読み取り権限を持っているか確認します データベースがロールフォワード保留状態のままになる リストア後にデータベースに接続できない場合は、次のようにトラブルシューティングします。 and stop 句を指定してロールフォワード操作を完了します 後でさらにログを適用したい場合は、データベースを開く準備ができたときにのみ and stop を使用します db2 list history rollforward for <dbname> を使って、未完了のロールフォワード操作がないか確認します Amazon S3 ストレージエイリアスの接続の問題 ストレージエイリアスを使って Amazon S3 から直接リストアできない場合は、次のようにトラブルシューティングします。 セルフマネージド Db2 サーバーで AWS 認証情報が正しく設定されているか確認します S3 エンドポイントへのネットワーク接続を確認します db2 list storage access を使って、ストレージエイリアスが正しくカタログ登録されているか確認します S3 バケット名とオブジェクトパスが正しいか確認します ベストプラクティス 以下のベストプラクティスの導入を検討してください。 定期的なテスト – リストアとロールフォワードの手順を定期的にテストし、災害復旧計画が想定どおりに機能することを確認します。 Amazon S3 コストの監視 – アーカイブログはすぐに蓄積されます。Amazon S3 のライフサイクルポリシーを導入し、不要になった古いログをアーカイブまたは削除します。 ログ適用の自動化 – cron ジョブやスケジュールタスクを使ってログのダウンロードと適用を自動化し、手作業を減らします。 ログの連続性の維持 – バックアップのタイムスタンプから現在までのすべてのログをそろえておきます。ログが欠落するとロールフォワードチェーンが途切れます。 同期にはオンラインバックアップを使用する – Amazon S3 へのアーカイブログ転送を設定する際はオンラインバックアップを使用し、ロールフォワード操作との互換性を確保します。 タイムスタンプの記録 – バックアップのタイムスタンプと最後に適用したログを記録しておき、トラブルシューティングと復旧計画に役立てます。 セキュリティ – S3 の保管中データ (SSE-S3 または SSE-KMS) と転送中データ (S3 アクセスの SSL/TLS) に暗号化を使用します。 クリーンアップ ロールフォワード処理が完了したら、Amazon S3 バケットからアーカイブログを削除して、割り当てられた領域を回収できます。このソリューションをテスト目的で使用している場合は、Amazon S3 バケット、RDS for Db2 インスタンス、EC2 インスタンス、および IAM などのその他のリソースを必ず削除してください。 まとめ RDS for Db2 のアーカイブログを Amazon S3 バケットにコピーすることで、セルフマネージドインフラ上にデータベースの同期コピーを維持する仕組みが得られます。この機能により、移行の計画、災害復旧の構築、開発環境の作成において、Amazon RDS のマネージドの利点とセルフマネージド Db2 インスタンスの制御性の両方を柔軟に活用できます。 本記事で説明した手順に従うことで、セルフマネージドの Db2 データベースを RDS インスタンスと同期させ続ける堅牢なデータレプリケーションパイプラインを、最小限のレイテンシーと運用負荷で構築できます。 Amazon RDS for Db2 の詳細については、 Amazon RDS for Db2 ユーザーガイド を参照してください。 謝辞 本記事を丁寧にレビューしてくれた Rajib Sarkar と Umair Hussain に感謝します。 著者について Vikram S Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。Db2 の分野で 20 年以上の経験を持ち、製品をゼロから作り上げることを楽しんでいます。余暇には瞑想を実践し、ポッドキャストを聴くのが好きです。 Kshitij Sanghoi Kshitij は、 Kshitij はシニアソフトウェア開発エンジニアで、11 年以上の AWS 経験を含む 15 年以上の IT 経験を持っています。 Sumit Kumar Sumit は、 Sumit は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを楽しんでいます。さまざまな業界のお客様を支援し、AWS クラウド上でワークロードの構築と設計を行ってきました。料理やチェス、家族と過ごす時間を楽しんでいます。 Javeed Mohammed Javeed は、 Javeed は Amazon Web Services (AWS) のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームに所属し、Oracle や Db2 などの商用データベースエンジンを担当しています。お客様と協力して、AWS クラウド上でリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援することを楽しんでいます。 この記事はSolutions Architect の矢木 覚が翻訳しました。

    株式会社エブリーは、「前向きなきっかけを、ひとりひとりの日常にとどける。」というミッションのもと、デリッシュキッチン、retail HUB、トモニテ、MOMENTH といった BtoC・BtoB を横断するメディアやサービスを展開しています。同社では、小売事業者向けサービス retail HUB におけるピッキングサービスの新規開発にあたり、データベースとして Amazon Aurora DSQL を採用しました。本ブログでは、お客様の開発チームに伺った Aurora DSQL 採用の背景、導入の取り組み、そして導入後に得られた効果についてご紹介します。 対象システム 今回 Aurora DSQL を採用したのは、 retail HUB 事業のネットスーパーサービスにおけるピッキングサービスです。 retail HUB は、お客様が提供する小売事業者向けの DX ソリューションです。店頭サイネージによるレシピ提案、デジタルチラシ、ネットスーパーアプリの提供、店頭運営の効率化、CRM によるロイヤルカスタマー育成まで、小売事業者の販促プロセス全体をデジタル化し、業務効率化ときめ細やかな顧客アプローチを実現しています。 retail HUB 事業のネットスーパーサービスでは、店舗側が売り場から注文商品をピックアップする作業が発生しますが、従来この運用は紙のリストで行われており、商品を探すのに時間がかかることや習熟度による作業スピードのばらつきなどにより人的ミスの防止が難しく、誤ピックによる取り直しが発生するといった課題がありました。この問題を解決するため、ピッキングアプリ「retail HUB Picker」の開発が求められました。 アーキテクチャ ピッキングサービスのアーキテクチャは、ピッキングアプリ（Android アプリ）から Amazon ECS + ALB で構成された API サーバーに接続し、担当者の認証管理には Amazon Cognito を利用しています。バックエンドのデータベースとして Aurora DSQL を採用し、ピッキング対象の商品情報やピッキング状態、担当者情報の格納・参照に使用しています。 ピッキングサービスのシステムアーキテクチャは以下のとおりです。今回新規に開発したピッキングシステムは既存のネットスーパーシステムとは分離しており、注文データを連携する箇所のみで結合しています。 データベース選定の背景 今回のピッキングサービスは新規開発であり、データベースの選定にあたってはシステムの特性に合わせた検討が行われました。データベースに求められる要件は以下でした。 安定性と可用性 ピッキング作業中にシステムが停止すると店舗のピッキング業務に影響を与え、導入店舗数が増えるほどその影響範囲も大きくなるため、安定性と高い可用性が重要な要件でした。また、小売店舗は土日も稼働しているため、運営側の都合でメンテナンス時間を設定しにくいというビジネス上の課題も考慮する必要がありました。 低コストによるスモールスタート 初期フェーズではリクエスト数が限定的であり、構築・運用にあまりコストをかけたくないという要望がありました。一方で、今後サービスの成長に伴いトラフィックの増加も想定されるため、高いスケーラビリティを備えたデータベースであることが望ましいと考えていました。 運用負荷の軽減 メンテナンスウィンドウに伴う運用負荷が課題となっていました。新規サービスでは、こうした運用負荷を極力下げたいという考えがありました。 Aurora DSQL を選択した理由 お客様では当初、既存システムで利用している Amazon RDS for MySQL や Amazon Aurora MySQL の導入を想定していました。しかし、上記の要件を踏まえて検討を進めた結果、サーバーレスの分散データベースである Aurora DSQL が採用されました。その理由は以下の通りです。 安定性と可用性 — シングルリージョン構成で 99.99%（マルチリージョン構成では 99.999%）の可用性を備えたサーバーレスの分散データベースであり、インフラ管理が不要。ピッキング作業中のシステム停止リスクを低く抑えられる 低コストによるスモールスタート — 従量制の課金モデルで初期コストを抑えつつ、将来のサービス成長に伴うトラフィック増加にも自動スケールで対応できる 運用負荷の軽減 — パッチ適用がダウンタイムなしで自動的に行われるため、関係者との調整や作業工数が不要になる 加えて、Aurora DSQL が PostgreSQL との互換性を備えていたことで、社内の既存知見を活かしながら導入できる点も後押しとなりました。また、お客様の開発チームには分散データベースへの技術的な関心が高く、Aurora DSQL を通じて得られる知見が今後の技術選定の指標になるという期待も大きく、採用の決め手の一つとなりました。 Aurora DSQL とは Aurora DSQL は、AWS が提供するサーバーレスの分散 SQL データベースです。従来のデータベースのようにクエリ処理・ストレージ・トランザクション管理が密結合した構成ではなく、それぞれが独立したコンポーネントに分かれています。各コンポーネントがワークロードに応じて個別にスケールするため、特定の処理がボトルネックになりにくく、低レイテンシーで強固な一貫性を実現しています。また、PostgreSQL との互換性を備えており、既存の PostgreSQL の知見やツールを活かして開発を進めることができます。 お客様が選定の理由に挙げた以下の 3 つについて、Aurora DSQL の特性を簡単に説明します。 安定性と可用性 Aurora DSQL では、すべての書き込みトランザクションを分散トランザクションログにコミットし、コミットされたすべてのログデータを 3 つのアベイラビリティーゾーンにあるストレージレプリカに同期レプリケーションします。これにより、Aurora の Multi-AZ 構成と同等の 99.99% の可用性を実現しています。以下の図は、Aurora DSQL の可用性に関する特性を示しています。 低コストによるスモールスタート 課金はリクエスト数やデータ量に応じた従量制で、リクエスト数が少ない段階ではコストを低く抑えられます。アーキテクチャを変更することなく自動的にスケールするため、小規模な構成から始めて、トラフィックの増加に応じてシームレスにスケールすることができます。以下の図は、Aurora DSQL のコストモデルを示しています。 運用負荷の軽減 サーバーのプロビジョニングやパッチ適用、インフラのアップグレードといった管理作業が不要です。パッチ適用やセキュリティアップデートはダウンタイムなしで自動的に処理されるため、メンテナンスウィンドウの調整や計画停止が不要です。以下の図は、Aurora DSQL と従来のデータベースにおけるメンテナンスの違いを示しています。 開発時の課題 開発スケジュール 開発スケジュールは以下のとおりです。 時期 内容 2025年5月 小売事業者に対するヒアリング（事業部門＋開発部門） 2025年6月 運用分析、開発要件定義、分析要件定義、システム設計 2025年7月〜8月 開発（アプリケーション、API サーバー、インフラ、分析基盤） 2025年9月上旬 社内 QA 2025年9月中旬 リリース、小売事業者にて検証・運用開始 Aurora DSQL を用いた開発にあたっては、PostgreSQL との互換性に関していくつかの課題がありました。 スキーマ変更の制約 Aurora DSQL ではカラム追加時にデフォルト値を指定する構文がサポートされていないことが開発中に判明しました。PostgreSQL では一般的に使用される構文であるため、既存の知見をそのまま適用できないケースでした。対処として、カラムのみを追加し、デフォルト値や NOT NULL 制約はソフトウェアレベルで保証する実装としました。なお、サービスリリース前であったため、最終的にはテーブルを再作成することで問題を回避しました。このように、事前のドキュメント確認だけでは把握しきれず、実際の操作を通じて発見される差分もありました。 ローカル開発環境との互換性 当初ローカル開発では PostgreSQL のコンテナを使用していましたが、 CREATE INDEX を CREATE INDEX ASYNC に変更する必要があるなど、Aurora DSQL との互換性がない部分が判明したため、ローカル環境でも Aurora DSQL を使用する方式に切り替えました。 トランザクションサイズの制限 Aurora DSQL にはトランザクションデータ件数に制限があるため、大量のデータを一括で処理する実装には工夫が必要でした。この制限を回避するため、大量のデータ投入処理においては全体を 1 トランザクションにまとめず、処理を分割する設計としました。具体的には、データ量が大きい投入処理ではトランザクションを使わずに実行し、途中でエラーが発生しても何度でもやり直せる設計としました。その上で、整合性の担保が必要な少量のデータ更新処理だけをトランザクション内で実行するようにしました。 こうした課題を一つずつ解消しながら開発を進め、ピッキングサービスは無事にローンチを迎えました。 ローンチと導入後の効果 2025 年 9 月中旬にローンチしてから数ヶ月が経過していますが、大きな問題は発生しておらず、安定した稼働を続けています。 導入後に得られた効果は以下のとおりです。 コスト削減 Aurora PostgreSQL（Provisioned）で想定していたインスタンスサイズと比較すると、コストは 90% 以上低くなっています。従量制のコストモデルにより、初期フェーズにおいて大幅なコスト削減を実現しました。 以下は、今回のワークロードを想定したコスト比較の試算です。Aurora PostgreSQL（Provisioned）を 100 とした場合の相対コストを示しています。 構成 Pattern S コスト比 Pattern M コスト比 Pattern L コスト比 Aurora PostgreSQL (Provisioned) 100% 100% 100% Aurora Serverless v2 41% 41% 66% Aurora DSQL 4% 6% 12% 安定稼働とメンテナンスフリー サービス導入後は安定して稼働しており、パフォーマンス上の問題も発生していません。メンテナンスウィンドウが不要であるため、基盤のメンテナンス作業そのものだけでなく、それに伴う小売事業者やサービス利用者との調整業務も不要となりました。既存システムでは 3 ヶ月ごとのパッチアップデートのたびに、メンテナンス時間帯の調整、影響範囲の洗い出し、小売事業者や関係部署への連携が必要でしたが、Aurora DSQL ではこうした業務コストがゼロになり、運用負荷が大きく削減されました。 スケーラビリティの確保 現時点でのリクエスト数の変動については特に大きな問題は発生していません。今後のサービス成長に伴うトラフィック増加についても、検証の結果スケーリングに問題がないことを確認しており、今後のトラフィック増加にも不安なく運用できる見通しです。 お客様の声 お客様に Aurora DSQL の導入効果について伺ったところ、次のように述べています。 スケーラビリティと安定性の要件が高いシステムにおいて Aurora DSQL を選択する利点は高いと考えています。 – 内原 章 氏　株式会社エブリー 開発本部 開発2部 部長 今後の展望 お客様では、今回のピッキングサービスでの導入実績を踏まえ、スケーラビリティの要件が高いシステムにおいて Aurora DSQL を選択肢として検討していく方針です。新規開発だけでなく、既存システムのリプレースにおいても Aurora DSQL の活用を視野に入れています。 また、Aurora DSQL のさらなる進化への期待として、PostgreSQL との互換性向上を挙げています。特に RLS（Row Level Security）のような機能がサポートされることで、より幅広いユースケースに対応しやすくなると考えています。 Aurora DSQL は、高い可用性とスケーラビリティを必要とするシステムにおいて、運用負荷とコストの低減が期待できるデータベースです。本ブログが、同様の課題を持つお客様にとって参考になれば幸いです。

本記事は 2026 年 7 月 8 日 に公開された「 Fail back from Amazon RDS for Db2 to on-premises AIX Db2 using DMS 」を翻訳したものです。 本記事では、AWS Database Migration Service ( AWS DMS ) を使って、Amazon Relational Database Service ( Amazon RDS ) for Db2 からオンプレミスの AIX Db2 インスタンスへ、CDC のみのリバースレプリケーションを構成する方法を説明します。 Db2 ワークロードをオンプレミスの AIX から Amazon RDS for Db2 に移行した後は、カットオーバー後の重要な検証期間に問題が発生した場合でもデータの整合性を保てる、検証済みのフェイルバック経路が必要です。検証済みのフェイルバック戦略があれば、カットオーバー後にアプリケーションがコミットしたトランザクションを保持したまま、迅速にロールバックできます。標準的なバックアップとリストアの手法では数時間かかることがあり、最新の変更を取り込めない場合もあります。本記事で紹介する構成は、設定と検証におよそ 2〜3 時間かかります。 DMS を使えば、Amazon Relational Database Service (Amazon RDS) for Db2 からオンプレミスの AIX Db2 インスタンスへ、変更データキャプチャ (CDC) のみのリバースレプリケーション経路を構成できます。この方法は、AWS への移行中だけ機能する一時的なセーフティネットとして設計されており、本番ワークロードの切り替え後に問題が発生した場合にオンプレミス環境へ戻す助けとなります。 オンプレミス Db2 から Amazon RDS へのフォワード移行パターンには豊富なドキュメントがあります。詳しくは、 Migrate from self managed Db2 to Amazon RDS using DMS および Migrate from self managed Db2 to Amazon RDS using native tools を参照してください。Db2 のリバースレプリケーションパターンは、フォワード移行に比べてドキュメントが少ないのが現状です。本記事の方法を使えば、AIX 環境を起点とする Db2 ワークロード向けに、検証済みのフェイルバック戦略を実装できます。 Rolling back from a migration with AWS DMS 。 移行時のロールバック戦略の概念的な枠組みについては、basic fallback、fall forward、dual write、bidirectional replication という 4 つの戦略を解説した「Rolling back from a migration with DMS」を参照してください。本記事では、検証済みのフェイルバック経路を維持するため、CDC のみのタスクで Db2 の単方向リバースレプリケーションパターンを実装する方法に焦点を当てます。 ソリューションの概要 移行の検証中は、問題が発生しても安全にロールバックできるという確信が必要です。このリバースレプリケーションは、そのセーフティネットを提供するために設計されています。AWS へのデータベース移行はすべて、plan(計画)、migrate(移行)、validate(検証)、complete(完了)というライフサイクルをたどります。リバースレプリケーションが支えるのは validate フェーズです。カットオーバー後の検証期間(通常は 2〜4 週間)のみ稼働し、検証が成功した時点で廃止します。継続的なレプリケーションパターンではなく、移行を完了させる確信を得るための一時的な安全策です。コストの詳細は、本記事後半の「コストに関する考慮事項」セクションを参照してください。 この方法では、Amazon RDS をソース、オンプレミスの自己管理型 AIX Db2 インスタンスをターゲットとして AWS DMS の CDC のみのレプリケーションタスクを実行し、検証済みのフェイルバック経路を維持します。レプリケーションするのは進行中の変更のみ(フルロードなし)であり、冗長なデータ転送を回避します。オンプレミスのデータベースには、カットオーバー前の完全なデータセットがすでに含まれています。接続はプライベートのままで、パブリックサブネット、パブリック IP アドレス、インターネットゲートウェイのいずれも使用しません。データは AWS Direct Connect だけを経由して流れます。 データがインターネットゲートウェイを使わずプライベート接続を経由して流れる点に注目してください。次の図はこのアーキテクチャを示しています。 図 1: CDC のみのリバースレプリケーションのソリューションアーキテクチャ(プライベートネットワークのみ) 主要な設計上の決定 CDC のみ、フルロードなし: オンプレミスのデータベースにはカットオーバー前の完全なデータセットがすでに保持されているため、データの再ロードにかかる時間とコストを回避できます。カットオーバー後に Amazon RDS で行われた増分変更のみが戻されます。 プライベートのみのネットワークアーキテクチャ: データがパブリックインターネットを経由しません。DMS や Amazon RDS インスタンスにパブリックサブネットもパブリック IP アドレスもありません。AWS サービスへのアクセスは Amazon Virtual Private Cloud ( Amazon VPC ) エンドポイント ( AWS PrivateLink ) を経由し、データは AWS Direct Connect のプライベート VIF を通過します。 単方向リバースレプリケーション : カットオーバー後の検証期間中、アプリケーションは Amazon RDS にのみ書き込みます。リバース CDC タスクが変更をオンプレミスのデータベースにレプリケーションします。 接続には AWS Direct Connect: Amazon VPC とオンプレミスデータセンターの間の専用のプライベート接続で、インターネット経路は一切含まれません。 前提条件 このチュートリアルには、Db2 管理と AWS ネットワークに関する中級レベルの知識が必要です。構成全体の設定と検証には、およそ 2〜3 時間を見込んでください。リバースレプリケーションを構成する前に、次の要件を満たしていることを確認してください。 開始前に必要なもの フォワード移行が完了していること: DMS(フルロード + CDC)またはネイティブツールを使って、Db2 ワークロードをオンプレミスの AIX から Amazon RDS へ移行済みであること。 Amazon RDS インスタンス: Amazon Virtual Private Cloud (Amazon VPC) 内で稼働し、 PubliclyAccessible が false に設定された(プライベートエンドポイントのみの)Amazon RDS インスタンス。 オンプレミスの AIX Db2 インスタンス: 元のソースデータベースが破損せず利用可能な状態で、Db2 LUW バージョン 10.5 以降が稼働していること。 AWS Direct Connect: オンプレミスデータセンターと AWS の間で、プライベート仮想インターフェイス (VIF) を備えた AWS Direct Connect 接続が確立されていること。パブリックインターネット経由の VPN は使用しません。 このチュートリアルで作成するもの DMS レプリケーションインスタンス: バージョン 3.5.4 以降で、Publicly Accessible を false に設定したプライベートサブネットにデプロイします。 VPC エンドポイント: AWS Secrets Manager 、Amazon CloudWatch Logs、DMS のインターフェイスエンドポイント。これにより、DMS インスタンスはインターネットゲートウェイなしで AWS サービスにアクセスできます。 AWS Identity and Access Management ( IAM ) の権限: DMS に Amazon RDS for Db2、AWS Secrets Manager、Amazon CloudWatch へのアクセスを付与する IAM ロール。 データベースユーザーの権限: ソース (Amazon RDS for Db2) とターゲット (オンプレミスの AIX Db2) の両方のエンドポイントに対する適切な権限付与。 ネットワークアーキテクチャ: AWS Direct Connect によるプライベートのみの接続 ネットワークアーキテクチャ全体でプライベート接続のみを使用します。アーキテクチャにインターネットゲートウェイは含まれません。DMS レプリケーションインスタンスと Amazon RDS は、パブリック IP アドレスを持たないプライベートサブネットにデプロイします。Amazon VPC エンドポイント (AWS PrivateLink) が、 Amazon CloudWatch や AWS Secrets Manager などの AWS サービスに接続します。データは、プライベート仮想インターフェイスを使い、AWS Direct Connect だけを経由してオンプレミス環境へ流れます。 セキュリティグループの設定 通信をプライベートサブネットのみに制限するため、次のセキュリティグループを作成します。 DMS レプリケーションインスタンスのセキュリティグループ (dms-reverse-repl-sg): # Create security group for DMS replication instance aws ec2 create-security-group \ --group-name dms-reverse-repl-sg \ --description "SG for DMS reverse replication (private only)" \ --vpc-id vpc-<vpc-id> # Allow outbound to on-premises Db2 (port <db-port>) through AWS Direct Connect aws ec2 authorize-security-group-egress \ --group-id sg-dms-xxxxxxxxx \ --protocol tcp --port <db-port> \ --cidr <on-premises-db2-ip>/32 # Allow outbound to RDS for Db2 (port <db-port>) - private subnet aws ec2 authorize-security-group-egress \ --group-id sg-dms-xxxxxxxxx \ --protocol tcp --port <db-port> \ --cidr <private-subnet-cidr> # Allow outbound HTTPS to Amazon VPC Endpoints (443) aws ec2 authorize-security-group-egress \ --group-id sg-dms-xxxxxxxxx \ --protocol tcp --port 443 \ --cidr <vpc-cidr> Amazon RDS のセキュリティグループ (rds-db2-sg): # Allow inbound from DMS replication instance on port <db-port> aws ec2 authorize-security-group-ingress \ --group-id sg-rds-xxxxxxxxx \ --protocol tcp --port <db-port> \ --source-group sg-dms-xxxxxxxxx プライベートな AWS サービスアクセス用の VPC エンドポイント Amazon VPC にはインターネットゲートウェイがないため、DMS レプリケーションインスタンスが AWS サービスにプライベートにアクセスできるよう、Amazon VPC エンドポイントを作成します。 # Create Interface Amazon VPC Endpoints for DMS service access for SERVICE in secretsmanager monitoring logs dms; do aws ec2 create-vpc-endpoint \ --vpc-id vpc-<vpc-id> \ --service-name com.amazonaws.<aws-region>.${SERVICE} \ --vpc-endpoint-type Interface \ --subnet-ids subnet-aaaaaaaaaa \ --security-group-ids sg-vpce-xxxxxxxxx \ --private-dns-enabled done VPC ルートテーブルの設定 # Add route to on-premises network through VGW (private routing) aws ec2 create-route \ --route-table-id rtb-<route-table-id> \ --destination-cidr-block <on-premises-cidr> \ --gateway-id vgw-<vgw-id> # Note: No route to internet gateway - traffic stays private 接続の検証 DMS タスクを作成する前に、DMS インスタンス、ソース、ターゲット間のプライベート接続を検証します。 到達性をテストする : Amazon VPC Reachability Analyzer を使い、DMS サブネットからオンプレミス IP () へのポート <db-port> 経由のネットワーク経路を検証します。 ファイアウォールルールを確認する : オンプレミスのファイアウォールが、Amazon VPC の CIDR 範囲 () からのポート <db-port> 宛て受信 TCP トラフィックを許可していることを確認します。 エンドポイント接続をテストする : エンドポイントを作成した後、DMS の接続テストを使用します。 aws dms test-connection \ --replication-instance-arn arn:aws:dms:<aws-region>:<aws-account-id>:rep:my-instance \ --endpoint-arn arn:aws:dms:<aws-region>:<aws-account-id>:endpoint:my-target 期待される出力: { "Connection": { "ReplicationInstanceArn": "arn:aws:dms:<aws-region>:<aws-account-id>:rep:my-instance", "EndpointArn": "arn:aws:dms:<aws-region>:<aws-account-id>:endpoint:my-target", "Status": "testing", "LastFailureMessage": "", "EndpointIdentifier": "my-target", "ReplicationInstanceIdentifier": "my-instance" } } Amazon RDS for Db2 を CDC ソースとして構成する Amazon RDS を CDC ソースとして準備するため、次の 3 つの設定手順を実施します。 マスターユーザー(インスタンス作成時に指定した管理ユーザー)を使って Amazon RDS for Db2 インスタンスに接続します。次のコマンドには rdsadmin の権限が必要なため、標準的なデータベースユーザーでは権限が不足します。 アーカイブログ保持を有効にする -- Increase archive log retention to 24 hours CALL rdsadmin.set_archive_log_retention(?, 'PRODDB', '24'); 重要: アーカイブログの保持期間は最低でも 24 時間に設定してください。DMS タスクの処理が遅延し、必要なログがすでに削除されている場合、タスクは失敗し、新しい位置から再開する必要があります。 DATA CAPTURE CHANGES を有効にする ALTER TABLE SCHEMA_NAME.TABLE_NAME DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS; DMS ユーザーに権限を付与する GRANT DBADM ON DATABASE TO USER dms_user; GRANT DATAACCESS ON DATABASE TO USER dms_user; オンプレミスの AIX Db2 をターゲットとして構成する AWS DMS からの CDC 変更を受け取れるよう、オンプレミスのターゲットデータベースを準備します。 SYSADM または SECADM 権限を持つユーザーを使って、オンプレミスの AIX Db2 インスタンスに接続します。次の GRANT ステートメントには、ターゲットデータベースの管理者権限が必要です。 ターゲットデータベースの権限を付与する GRANT DBADM ON DATABASE TO USER dms_user; GRANT DATAACCESS ON DATABASE TO USER dms_user; ターゲットテーブルを準備する 外部キー制約を削除または無効化する: AWS DMS は、親子関係の順序ではなくトランザクションログの順序で変更を適用します。外部キーを無効化しないと、子テーブルへの INSERT が対応する親行より先に到着し、参照整合性違反を引き起こしてレプリケーションタスクが失敗する可能性があります。フェイルバックを検証した後に制約を再度有効化します。 トリガーを無効化する : CDC の適用による意図しない副作用を防ぎます。 ALTER TABLE TARGET_SCHEMA.TABLE_NAME DEACTIVATE TRIGGERS; シーケンスをリセットする : RDS ソースから現在の値を取得し、ターゲットでリセットします。 SELECT 'ALTER SEQUENCE ' || TRIM(SEQSCHEMA) || '.' || TRIM(SEQNAME) || ' RESTART WITH ' || NEXTCACHEFIRSTVALUE || ';' FROM SYSCAT.SEQUENCES WHERE SEQSCHEMA IN ('APP_SCHEMA') AND SEQTYPE = 'S'; ステップバイステップ: CDC のみのリバースレプリケーションを作成する 次の 7 つのステップでは、CDC のみのリバースレプリケーション用の DMS リソースを作成する手順を説明します。以降のコマンドでは、プレースホルダーの値( vpc-xxxxxxxxx や sg-dms-xxxxxxxxx など)を実際のリソース識別子に置き換えてください。 ステップ 1: IAM ロールを作成する aws iam create-role --role-name dms-vpc-role \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Principal": {"Service": "dms.amazonaws.com"}, "Action": "sts:AssumeRole"}]}' aws iam attach-role-policy --role-name dms-vpc-role \ --policy-arn arn:aws:iam::aws:policy/service-role/AmazonDMSVPCManagementRole ステップ 2: DMS レプリケーションインスタンスを作成する(プライベート) aws dms create-replication-subnet-group \ --replication-subnet-group-identifier db2-reverse-repl-subnet-group \ --replication-subnet-group-description "Private subnets for reverse replication" \ --subnet-ids subnet-aaaaaaaaaa subnet-bbbbbbbbbb aws dms create-replication-instance \ --replication-instance-identifier db2-reverse-repl-instance \ --replication-instance-class dms.c6i.xlarge \ --allocated-storage 100 \ --vpc-security-group-ids sg-dms-xxxxxxxxx \ --replication-subnet-group-identifier db2-reverse-repl-subnet-group \ --no-multi-az --engine-version 3.5.4 \ --no-publicly-accessible 重要: --no-publicly-accessible フラグは非常に重要です。DMS インスタンスは、パブリック IP を持たないプライベートサブネットにデプロイされます。オンプレミスへの接続は、仮想プライベートゲートウェイ (VGW) を経由した AWS Direct Connect を通じて行われます。 ステップ 3: ソースエンドポイントを作成する (Amazon RDS for Db2) aws dms create-endpoint \ --endpoint-identifier rds-db2-source-for-reverse \ --endpoint-type source --engine-name db2 \ --server-name mydb2instance.xxxx.<aws-region>.rds.amazonaws.com \ --port <db-port> --database-name PRODDB \ --username dms_user --password '<your-password>' \ --ibm-db2-settings '{"CurrentLsn":"scan","SetDataCaptureChanges":true}' \ --extra-connection-attributes "StartFromContext=NOW;" 設定 値 目的 CurrentLsn scan Db2 ログをスキャンして、現在のログシーケンス番号 (LSN) の位置を判定します SetDataCaptureChanges true テーブルに対して DATA CAPTURE CHANGES を自動的に設定します StartFromContext NOW 最新のログシーケンスオフセットからキャプチャを開始します ステップ 4: ターゲットエンドポイントを作成する(オンプレミスの AIX Db2) aws dms create-endpoint \ --endpoint-identifier aix-db2-target-for-reverse \ --endpoint-type target --engine-name db2 \ --server-name <on-premises-db2-ip> \ --port <db-port> --database-name PRODDB \ --username dms_user --password '<your-password>' \ --ibm-db2-settings '{"LoadTimeout":1200,"MaxFileSize":1048576,"WriteBufferSize":1024}' ステップ 5: エンドポイント接続をテストする # Test both endpoints (must return "successful") aws dms test-connection \ --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \ --endpoint-arn arn:aws:dms:...endpoint:rds-db2-source-for-reverse aws dms test-connection \ --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \ --endpoint-arn arn:aws:dms:...endpoint:aix-db2-target-for-reverse ステップ 6: CDC のみのレプリケーションタスクを作成する aws dms create-replication-task \ --replication-task-identifier db2-reverse-cdc-task \ --source-endpoint-arn arn:aws:dms:...endpoint:rds-db2-source-for-reverse \ --target-endpoint-arn arn:aws:dms:...endpoint:aix-db2-target-for-reverse \ --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \ --migration-type cdc \ --table-mappings '{"rules":[ {"rule-type":"selection","rule-id":"1","rule-name":"exclude-sys", "object-locator":{"schema-name":"SYS%","table-name":"%"}, "rule-action":"exclude"}, {"rule-type":"selection","rule-id":"2","rule-name":"include-app", "object-locator":{"schema-name":"APP_SCHEMA","table-name":"%"}, "rule-action":"include"}]}' \ --cdc-start-position "scan" レプリケーションタスクの主要な設定 設定 値 目的 migration-type cdc CDC のみ — フルロードなし TargetTablePrepMode DO_NOTHING ターゲットの既存データを保持します BatchApplyEnabled true トランザクションをグループ化してスループットを向上させます EnableValidation true ソースとターゲットのデータを比較します ApplyErrorDeletePolicy IGNORE_RECORD ターゲットに存在しない行の削除操作をスキップします。タスクの失敗を回避できますが、トレードオフとして CDC 中に軽微な不整合が生じます cdc-start-position scan Db2 ログ内の現在の LSN から開始します 注: これらの設定は、タスク作成時に --replication-task-settings の JSON パラメータで渡します。ステップ 6 の CLI コマンドは簡略化した形式を使用しているため、JSON の構成を自分の環境に合わせて調整してください。 ステップ 7: レプリケーションタスクを開始する aws dms start-replication-task \ --replication-task-arn arn:aws:dms:...task:db2-reverse-cdc-task \ --start-replication-task-type start-replication モニタリングと検証 レプリケーションタスクを開始した後は、次の主要な Amazon CloudWatch メトリクスをモニタリングします。次の表は、メトリクス、しきい値、推奨されるアクションを示しています。メトリクスがしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) で通知を送信する Amazon CloudWatch アラームを設定することもできます。 メトリクス しきい値 アクション CDCLatencySource (ソースデータベースと AWS DMS の間の遅延秒数) > 120 秒 アーカイブログの保持期間と DMS インスタンスの CPU を確認する CDCLatencyTarget (DMS とターゲットデータベースの間の遅延秒数) > 120 秒 オンプレミス Db2 のパフォーマンスと AWS Direct Connect のレイテンシーを確認する CDCIncomingChanges (適用待ちの変更イベント数) 継続的に高い タスクが遅延している。レプリケーションインスタンスをスケールアップする CDCChangesDiskSource (レプリケーションインスタンスのメモリが不足したときに DMS がディスクに書き込む変更イベント) > 0 が継続 インスタンスのメモリ、または MemoryLimitTotal タスク設定(レプリケーションタスクが消費できる最大メモリ (MiB) を制御)を増やす CPUUtilization > 80% より大きなインスタンスクラスにスケールアップする aws cloudwatch put-metric-alarm \ --alarm-name db2-reverse-cdc-latency \ --metric-name CDCLatencySource --namespace AWS/DMS \ --statistic Average --period 300 --threshold 120 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 3 \ --alarm-actions arn:aws:sns:<aws-region>:<aws-account-id>:dms-alerts フェイルバック手順 オンプレミス環境へフェイルバックする必要がある場合は、ダウンタイムを最小限に抑え、データの整合性を維持するために次の手順に従います。 図 3: フェイルバックの実行手順 フェイルバック前のチェックリスト CDC のレイテンシーがほぼゼロであることを確認する : CDCLatencySource と CDCLatencyTarget が ≈ 0 データ検証が合格することを確認する : テーブルが Validated 状態になっている RDS へのアプリケーション書き込みを停止する : アプリケーション層を静止させる CDC タスクが排出済みであることを確認する: CDCIncomingChanges = 0 フェイルバックの実行 リバース CDC タスクを停止します。 ターゲットの外部キー制約を再度有効化します。 ターゲットテーブルのトリガーを再度有効化します。 シーケンスを Amazon RDS for Db2 の現在の値にリセットします。 アプリケーションの接続文字列を、オンプレミスの Db2 (:) を指すように更新します。 オンプレミスのデータベースに対してスモークテストを実行します。 任意: 再移行のために、フォワードレプリケーションを再度セットアップします。 リソースをクリーンアップする このリバースレプリケーションは、移行の検証フェーズを支えるためだけに存在します。継続的な利用を想定したものではありません。アプリケーションが 2〜4 週間問題なく稼働し、関連チームが承認し、変更管理が承認した時点で廃止する計画を立てます。廃止後は、課金を止めるために DMS レプリケーションインスタンス、エンドポイント、関連する IAM ロールを削除します。 aws dms stop-replication-task --replication-task-arn arn:aws:dms:... aws dms delete-replication-task --replication-task-arn arn:aws:dms:... aws dms delete-endpoint --endpoint-arn arn:aws:dms:... aws dms delete-replication-instance --replication-instance-arn arn:aws:dms:... 廃止後、延長した保持期間が不要になった場合は、Amazon RDS for Db2 インスタンスのアーカイブログ保持期間をデフォルト値に戻します。これにより、保持されたアーカイブログによるストレージコストを削減できます。 -- Revert archive log retention to default (1 hour) CALL rdsadmin.set_archive_log_retention(?, 'PRODDB', '1'); 制限事項 DMS は IBM Db2 for LUW を CDC ソースとしてサポートします。このアーキテクチャでは、オンプレミスの AIX Db2 インスタンスをターゲットエンドポイントとして構成し、標準的な Db2 接続を通じて変更を受け取ります。 DMS は Db2 LUW ターゲットに対して完全な大規模オブジェクト (LOB) モードをサポートしません。代わりに制限付き LOB モードを使用します。 DMS は Db2 LUW ソースの Boolean データ型をサポートしません。 DMS はレプリケーション中に DECFLOAT 列の変更を無視します。 DMS は一部の DDL 操作(パーティション表の ALTER、RENAME COLUMN)をレプリケーションしません。これらはターゲットで手動で適用します。 多次元クラスタリング (MDC) 表の更新は、INSERT と DELETE のペアとして現れます。 DMS はシーケンス値をレプリケーションしません。フェイルバック前に手動で同期します。 CDC は Db2 の LOAD ユーティリティによるページレベルのロードをキャプチャしません。代わりに IMPORT を使用します。 コストに関する考慮事項 リバースレプリケーションの構成を計画する際は、次のコスト要因を考慮してください。 DMS レプリケーションインスタンスの稼働時間(インスタンスクラスに基づく)。 AWS Direct Connect 経由のデータ転送。 アベイラビリティーゾーンごと、1 時間あたりの VPC エンドポイント料金。 Amazon CloudWatch のメトリクスとアラーム。 AWS Secrets Manager のシークレットストレージと API 呼び出し。 最新の料金については、 DMS pricing page 、 AWS Direct Connect pricing ページ、 AWS PrivateLink pricing ページを参照してください。これは一時的な移行の安全策であるため、検証期間の終了後にレプリケーション基盤を廃止することでコストを最小限に抑えられます。 ベストプラクティス 本番のカットオーバー前に、非本番環境でフェイルバック手順全体をドライランし、各ステップを検証します。 データベースの認証情報は、自動ローテーションを有効にした AWS Secrets Manager に保存します。これにより、ハードコードされたパスワードをなくし、セキュリティ体制を強化できます。 CDCLatencySource と CDCLatencyTarget メトリクスに Amazon CloudWatch アラームを設定し、レプリケーションの遅延が許容できるしきい値を超えたときに通知を受け取れるようにします。 アーカイブログの保持期間は 24 時間以上を維持します。DMS が読み取る前に必要なログが削除されると、タスクは失敗し、新しい位置から再開する必要があります。 レプリケーションが 48〜72 時間安定したら、DMS のログ詳細度を DETAILED_DEBUG から DEFAULT に下げ、Amazon CloudWatch Logs のコストを削減します。 サイジングの目安として、 c6i.xlarge インスタンスは 1 秒あたり 1,000 トランザクション (TPS) 未満を処理できます。ワークロードがこれを超える場合は、 c6i.2xlarge にスケールアップします。 ソースとターゲットのデータベース間で、独立した行数とチェックサムの比較による週次のデータ検証をスケジュールします。 まとめ 本記事では、プライベートのみのネットワーク上で AWS DMS を使い、Amazon RDS for Db2 からオンプレミスの AIX Db2 インスタンスへ CDC のみのリバースレプリケーションを構成する方法を説明しました。VPC インターフェイスエンドポイントをセットアップし、ソースとターゲットの Db2 エンドポイントを構成し、CDC のみのレプリケーションタスクを作成して、AWS Direct Connect 経由のデータフローを検証しました。この一時的なフェイルバック経路により、移行カットオーバー期間中の厳しい RTO および RPO 要件を満たしやすくなります。移行が安定した後は、リバースレプリケーションを廃止し、AWS 上の恒久的なアーキテクチャへ移行します。 著者について Ashish Srivastava Amazon Web Services のプロフェッショナルサービスチームに所属する Delivery Consultant – Data & Analytics です。データベース移行のスペシャリストとして、Db2 や SQL Server などのエンタープライズデータベースの経験を持ち、オンプレミスデータベースの AWS への移行を技術的に支援しています。 Ivan Schuster AWS の Senior Database Specialty Architect です。テクノロジー業界で 20 年以上の経験を持ち、その大半をデータベースに携わってきました。プロフェッショナルサービスコンサルタントとして、数多くのお客様のワークロードの AWS クラウドへの移行を支援してきました。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 30 日 に公開された「 Enable self-managed AD Kerberos authentication with Amazon RDS for Db2 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 は、AWS、オンプレミス、他のクラウドのいずれで稼働している場合でも、お客様自身の Active Directory ドメインを利用した Kerberos 認証をサポートしています。Amazon RDS for Db2 をお客様が管理する Microsoft Active Directory に直接接続することで、データベースユーザーの認証を一元化し、シングルサインオンを実現できます。この構成の要となるのは、正確に絞り込んだ一連の AD 権限を専用のサービスアカウントに委任し、その認証情報を RDS へ安全に受け渡すことです。 本記事では、Amazon RDS for Db2 向けに Windows Active Directory を Kerberos 認証で構成する方法と、ドメイン参加済みのクライアントから構成を検証する方法を紹介します。 aws-samples/sample-rds-db2-tools リポジトリで公開されている一連の手順を、最初から最後まで順を追って説明します。 専用の OU とサービスアカウントを作成する。 Amazon RDS for Db2 が AD と連携するために必要な AD 権限を委任する。 認証情報を AWS Key Management Service (AWS KMS) で暗号化したシークレットとして AWS Secrets Manager に保存する。 生の GUID を人間が読める権限名に変換する PowerShell スクリプトで構成を検証する。 続いて、ドメイン参加済みの Db2 クライアントから構成を検証する方法を紹介します。 EC2 インスタンスを起動する。 インスタンスをドメインに参加させる。 Db2 Runtime Client をインストールする。 Kerberos チケットで接続する (パスワード不要)。 さらに、多くの人がつまずく分かりにくいステップも 1 つ取り上げます。User オブジェクトに対して servicePrincipalName の読み取り/書き込み権限を付与するには、標準の Active Directory ユーザーとコンピューター スナップインではなく、ADSI エディター ( adsiedit.msc ) が必要です。 ソリューションの概要 次の図は、お客様が管理する Active Directory に対して Amazon RDS for Db2 を認証する際のアーキテクチャを示しています。 この設計では、RDS for Db2 がお客様のセルフマネージド AD ドメインに直接参加します。専用の AD サービスアカウントのユーザー ID とパスワードは AWS Secrets Manager に保存され、AWS KMS キーで暗号化されます。ドメイン参加の際、RDS はこれらの認証情報を Secrets Manager から取得し、ディレクトリにインスタンスを登録します。ドメイン参加済みの Db2 クライアントは AD の KDC から Kerberos チケット (TGT) を取得し、そのチケットを使ってパスワードのやり取りなしに RDS for Db2 へ接続します。RDS、クライアント、ドメインコントローラー間の通信は、標準的な AD のポート、すなわち DNS (53)、Kerberos (88、464)、LDAP (389、3268)、RPC 動的範囲 (49152〜65535) を利用します。 構築するもの RDS for Db2 用に範囲を絞った専用の OU と AD サービスアカウント、および RDS for Db2 が必要とする権限を委任した ACL。 認証情報を RDS へ安全に受け渡すための AWS KMS キーと Secrets Manager シークレット。 セルフマネージド AD 変数を設定した Amazon RDS for Db2 インスタンス。 AL2023 の EC2 ドメイン参加済みクライアントを使ってテスト済みの接続。 1. AD 権限を委任する 専用の OU とサービスアカウントを作成し、[制御の委任] ウィザードと ADSI エディターを使って必要なアクセス制御エントリ (ACE) を付与します。 OU 内で User オブジェクトと Computer オブジェクトを作成/削除する。 子孫の User オブジェクトに対して、パスワードのリセットと msDS-SupportedEncryptionTypes の読み取り/書き込みを行う ([制御の委任] ウィザードを使用)。 子孫の User オブジェクトに対して servicePrincipalName の読み取り/書き込みを行う — ADSI エディターを使用 ( adsiedit.msc )。 あるいは、提供されている PowerShell スクリプト を実行すれば、9 つの ACE すべてを冪等な 1 回の処理で適用できます。 .\Grant-ADDomainJoinPrivileges.ps1 ` -ServiceAccount "CORP\rdsdb2svc" ` -TargetOU "OU=RDSDb2,DC=company,DC=com" ` -Verbose 同梱の、人間が読める形式で表示する ACL ビューアー スクリプトで検証します。 .\Show-OUDelegation.ps1 -OU "OU=RDSDb2,DC=company,DC=com" -SamAccountName rdsdb2svc ServiceAccount 名はお好みの名前に置き換えるか、 rdsdb2svc のままにします。 TargetOU では、OU 名をお好みの名前に変更するか RDSDb2 のままにできますが、DC 名は必ずお使いの AD のドメイン名に合わせて変更してください。例: "OU=RDSDb2,DC=corp,DC=mycompany,DC=com" 。 リポジトリでは、この委任について 2 つの同等な方法を説明しています。ADUC の [制御の委任] ウィザードと ADSI エディターを使う UI での手順と、上記の PowerShell スクリプトです。どちらも同じ ACL を生成するため、運用モデルに合った方を選んでください。始める前に、 リポジトリの README を読んで一連の手順の全体像を把握してから、委任そのものについては詳細な UI での手順 (または PowerShell ガイド ) に従ってください。 リポジトリの詳細な手順: README-UI.md 2. KMS キーと Secrets Manager シークレットを作成する 対称 KMS キーを作成し、サービスアカウントの認証情報を Secrets Manager シークレットとして保存します。このとき、RDS が読み取れるようにするリソースポリシーを設定します。 aws kms create-key --key-usage ENCRYPT_DECRYPT --key-spec SYMMETRIC_DEFAULT ... aws secretsmanager create-secret --name "rds-db2-self-managed-ad-secret" ... リポジトリの詳細な手順: README-KMS-Secret.md 3. サービスアカウントの認証情報を AWS Secrets Manager に保存する AD サービスアカウントのユーザー名 ( sAMAccountName のみで、 DOMAIN\ プレフィックスは付けない) とパスワードを、前のステップで作成した KMS キーで暗号化した Secrets Manager シークレットとして保存し、RDS が読み取れるようにするリソースポリシーをアタッチします。RDS for Db2 は、ドメイン参加の際にこのシークレットを取得します。 aws secretsmanager create-secret --name "rds-db2-self-managed-ad-secret" ... UI と CLI の詳しい手順はリポジトリにあります: README-KMS-Secret.md 4. RDS for Db2 インスタンスを構成する DB インスタンスを変更または作成し、[ディレクトリ] セクションでシークレットの ARN を指定します。CLI の場合は次のとおりです。 aws rds modify-db-instance \ --db-instance-identifier your-db-instance \ --domain-fqdn "company.com" \ --domain-ou "OU=RDSDb2,DC=company,DC=com" \ --domain-auth-secret-arn "arn:aws:secretsmanager:..." \ --domain-dns-ips "<dc-ip-1>" "<dc-ip-2>" \ ... リポジトリの詳細な手順: README-RDS-Db2.md 5. ドメイン参加済みの Db2 クライアントから接続をテストする 同じ VPC 内で Amazon Linux 2023 の EC2 インスタンスを起動し、AD ドメインに参加させて、Db2 Runtime Client をインストールします。 ステップ 1 – AD に参加する realmd 、 sssd 、 adcli 、 krb5-workstation をインストールします。 curl -sL https://bit.ly/domainjoin | bash source joindomain.sh ステップ 2 – Db2 RT クライアント をインストールする REGION=<region> ./db2-driver.sh ステップ 3 – DSN エントリを構成する ドメイン参加を自動検出し、ローカル認証用と Kerberos 用の両方の DSN を書き込みます。 sudo su - db2inst1 REGION=<region> source db2client-configure.sh ステップ 4 – 接続する kinit user@COMPANY.COM db2 terminate db2 "connect to RDSAKS" # Kerberos, no password db2 "connect to RDSAS user admin using '$MASTER_USER_PASSWORD'" # local auth リポジトリの詳細な手順: README-Db2-Client.md 重要なポイント User オブジェクトの SPN には ADUC ではなく ADSI エディターを使う。 ADUC スナップインは、User オブジェクトの属性一覧から servicePrincipalName を除外して表示します。ADSI エディターはスキーマ全体を表示します。ここが最もよくあるつまずきポイントです。 スコープが重要。 User オブジェクトではなく Computer オブジェクトに SPN の読み取り/書き込みを付与すると、一見正しく見えても実行時に失敗する ACL になります。Amazon RDS for Db2 は、自身が作成する User オブジェクトの権限をチェックするのであって、Computer オブジェクトではありません。 UI ではなく PowerShell で検証する。 ADUC の [セキュリティ] タブは、属性レベルの ACE を空白の行にまとめて表示してしまいます。提供されている Show-OUDelegation.ps1 スクリプトは、GUID を名前に解決して ACL を読みやすくします。 Secrets Manager でのユーザー名の形式。 シークレットには sAMAccountName のみを含める必要があり、 DOMAIN\ プレフィックスは付けません。ドメインプレフィックスを含めると、インスタンスの作成に失敗します。 ネットワーク AD と RDS の間には、複数のネットワーク構成が考えられます。次の 3 つのネットワークトポロジーについては、この ガイド を参照してください。 AD と RDS が同じ VPC 内にある構成。 AD を Microsoft Azure でホストする構成 (VPN または AWS Direct Connect + ExpressRoute)。 AD が別の VPC または AWS アカウントにある構成 (VPC ピアリングまたは AWS Transit Gateway)。 主要なポートは DNS (53)、Kerberos (88、464)、LDAP (389、3268)、RPC 動的ポート (49152〜65535) です。RPC の範囲を開け忘れることが、最初のドメイン参加が成功した後に断続的な障害が起きる最もよくある原因です。 クリーンアップ 継続的な課金を避け、この手順で Active Directory に作成したプリンシパルを削除するには、作成した順序とは逆の順序でリソースを削除します。 EC2 の Db2 クライアントを終了する — ドメインから離脱し (realm leave)、自身のコンピューターオブジェクトを削除してから、インスタンスを終了し、専用の IAM インスタンスプロファイル/ロールがあれば削除します。 RDS for Db2 からセルフマネージド AD を削除する — インスタンスを残す場合は aws rds modify-db-instance --disable-domain でドメインをデタッチして (再起動)、不要になった場合は aws rds delete-db-instance でインスタンスを削除します。 サービスアカウントの認証情報を保持している Secrets Manager シークレットを削除する 。 KMS キーの削除をスケジュールし 、そのエイリアスを削除します。いずれかのインスタンスがストレージ暗号化にそのキーをまだ使用している間はキーを削除しないでください。削除するとスナップショットが復元不能になります。 AD オブジェクトを削除する — サービスアカウントと専用の OU を削除します (RDS がドメイン参加時に作成した Computer/User オブジェクトをすべて消去するため、再帰的に削除します)。OU は残して委任した権限だけを外したい場合は、OU の ACL をリセットします。 これらそれぞれについて、コンソールと CLI のオプションや検証チェックを含む手順ごとのコマンドは、GitHub リポジトリの クリーンアップガイド にあります。 まとめ 本記事では、セルフマネージド Active Directory を使って Amazon RDS for Db2 の Kerberos 認証を有効にする方法を紹介しました。9 つの AD 権限を正確に専用のサービスアカウントに委任し、その認証情報を KMS で暗号化した Secrets Manager シークレットとして RDS へ安全に受け渡し、DB インスタンスをドメインに参加させ、ドメイン参加済みの Db2 クライアントから Kerberos チケットを使ってパスワードなしで接続することで、結果を最初から最後まで検証しました。その過程で、多くの人がつまずきやすいステップも取り上げました。すなわち、 servicePrincipalName の ACE には ADSI エディターを使うこと、権限を User オブジェクトに絞ること、そして RPC の動的ポート範囲を開けることです。 本記事全体で参照した PowerShell スクリプト、CLI コマンド、検証ツールは、 aws-samples/sample-rds-db2-tools GitHub リポジトリで入手できます。リポジトリをクローンし、変数をお使いのドメインに合わせて調整すれば、RDS for Db2 ワークロード向けに一元化されたシングルサインオン認証をすぐに稼働させられます。詳細については、Amazon RDS ユーザーガイドの Kerberos authentication for Amazon RDS for Db2 を参照してください。ご質問やご提案があれば、コメントをお寄せください。 著者について Vikram S Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。プロダクトマネジメント、経験豊富なアーキテクト、リーダーシップ、AI エキスパートユーザーなど、複数の役割を担っています。20 年以上の経験を持ち、ゼロから新しい製品を生み出すことに情熱を注いでいます。 Sindhu Simhadri Sindhu は、 Sindhu は Amazon RDS for Db2 のソフトウェア開発エンジニアです。10 年以上のソフトウェア開発経験を持っています。 Yiwen Shen Yiwen は、 Yiwen は Amazon RDS for Db2 のソフトウェア開発エンジニアです。5 年以上のソフトウェア開発経験を持っています。 この記事はSolutions Architect の 矢木 覚が翻訳しました。

はじめに こんにちは、IoT Specialist ソリューションアーキテクトの新澤です。2026 年 6 月 25〜26 日に幕張メッセで開催された AWS Summit Japan 2026 の「生産ラインの未来」ブースでは、AI エージェントが生産ラインのボトルネックを検知し改善策を提案するデモを展示しました。 開催前の予告ブログ ではデモの概要をご紹介しましたが、本記事では展示を終えた今、その実装の詳細を解説します。 このデモのテーマは、「AI エージェントに工場の「構造」をどう教えるか」です。どの製品にどの部品が必要で、どの設備で加工し、どのサプライヤーから調達しているか。こうした関係性が構造化されていなければ、AI は参照すべきデータソースを判断できず、回答が不安定になったり、必要なデータに到達するまでの試行錯誤が増えたりします。本デモではこの関係性をスキーマとして定義し、ナレッジグラフとして実装しました。一方、スキーマだけでは「今」が分かりません。設備のサイクルタイムは今何秒か、現状の設備で増産対応が可能なのか。ここに IoT のリアルタイムデータを接続することで、AI エージェントは構造を知った上で現状を踏まえた判断を行えるようになります。まず、なぜ製造業にナレッジグラフが必要なのかという課題から出発し、グラフスキーマの設計、データストアの役割分担、AI エージェントの推論フロー、全体アーキテクチャの順に解説します。 なお本記事では、製品・部品・設備・サプライヤーといった要素間の関係性をグラフ構造で表現したものを「ナレッジグラフ」と呼ぶこととします。これは OWL や記述論理に基づくいわゆるオントロジー (TBox/ABox による概念公理や自動推論)とは異なり、AI エージェントが「どのデータをどう辿るか」を判断するためのセマンティックなコンテキスト情報として活用することを目的としています。また、本記事で「推論」と呼ぶのは、記述論理（OWL など）による論理推論ではなく、AI エージェント（LLM）がナレッジグラフを文脈として複数のデータソースを横断し、回答を組み立てる処理を指します。 デモ画面:生産ラインのナレッジグラフマップ なぜ製造業にナレッジグラフが必要か 突然の増産指示「来月末までに 300 台追加で出荷できるか?」この問いに答えるには、オーダー → 製品 → 部品 → 在庫 → サプライヤー → 設備稼働と、異なるシステムに散在するデータを横断的に辿らなければなりません。難しいのは個々のデータを取ることではなく、それらのデータ間の依存関係を何段も辿り切らなければならない点にあります。さらに各データは多対多の関係を持ちます。1 つの製品は複数の部品を必要とし、1 つの部品は複数のサプライヤーから調達可能で、1 台の設備は複数の製品の工程に関与します。増産対応に限らず、このような「多段の関係性探索」は製造現場で繰り返し発生します。 特に顕著なのが BOM (部品表) の探索です。BOM はツリー構造で、増産の実現性判断では BOM を順方向に展開して必要部品を洗い出す必要があります。一方、品質問題のトレーサビリティでは逆方向に辿って「この素材を使っている全製品は」を特定します。設計変更の影響確認でも同様です。しかも構成が何階層あるかは製品ごとに異なるため、探索の深さを事前に固定できません。本デモでは以下の 3 階層の BOM を定義しました (来場者の方から「うちは 100 階層を超える」という声もいただきました) 。 SD1 圧力センサーモジュール (完成品) ├── センサーユニット (サブアセンブリ) │ ├── セラミック圧力センサー素子 │ └── 配線ハーネス ├── 駆動ユニット (サブアセンブリ) │ ├── ブラシレスモーター ×4 │ └── モータードライバ IC └── フライトコントローラー 「300 台増産できるか」の判断には、部品ツリーを最下層まで展開し、在庫・リードタイム・設備の稼働状況を確認する必要があります。RDB では構成表テーブルを何段階も繰り返し結合して検索するため、部品が増えるほど処理が重くなります。一方、ナレッジグラフなら階層の深さに関わらず 1 行のクエリで記述でき、順方向・逆方向の検索もまったく同じ構文で対応できます。 // 順方向: 増産に必要な全部品を展開 g.V('PROD-SD1').repeat(out('REQUIRES')).emit().valueMap('name') // 逆方向: 不良素材の影響を受ける全製品を特定 g.V('PART-CERAMIC-001').repeat(in('REQUIRES')).emit().valueMap('name') ナレッジグラフの利点は、探索の書きやすさだけではありません。ユーザーにとって直接的なメリットが 2 つあります。 1 つはコストです。グラフ探索は問いに関係するサブグラフだけを返すため、テーブルや文書を丸ごと LLM のコンテキストに渡す必要がなく、消費トークンを抑えられます。またグラフが「次にどこを見るべきか」を示すため、エージェントが無関係なデータソースを探索して往復する無駄も生じません。もう 1 つは回答の信頼性です。エージェントは LLM の記憶ではなく、グラフに格納された検証済みの関係を根拠に回答を組み立てます。ナレッジグラフによる知識の裏付けがハルシネーションの抑制に有効と考えられます。 ここからは、これらの利点を実際のデモでどう形にしたかを解説します。 グラフスキーマの設計 まずは、AI エージェントに接続したデータソースと、その関係性を定義したグラフスキーマの設計から解説します。 デモで用意したデータソース AI エージェントが増産の実現性を判断するために、以下のデータソースを用意しました。 生産オーダー (Amazon DynamoDB) : どの製品をいつまでに何個作るかを管理します。本デモでは「SD1 圧力センサーモジュール 300 台、納期 7/10」のオーダーを投入しています。 BOM — 部品表 (Amazon Neptune ナレッジグラフ) : 製品に必要な部品の構成を定義します。前セクションで示した 3 階層のツリー(完成品 → サブアセンブリ → 部品)が REQUIRES エッジとして格納されています。 在庫 (Amazon DynamoDB) : 各部品の現在の在庫数量と安全在庫を保持します。例 : セラミック素子 10,000 個、ブラシレスモーター 30,000 個。 サプライヤー (Amazon Neptune ナレッジグラフ + Amazon DynamoDB) : 部品と調達先の対応関係は SUPPLIED_BY エッジとしてグラフに、リードタイムや最小発注数量などの値は Amazon DynamoDB に持たせています。例: セラミック素子は LT 14 日、ブラシレスモーターは LT 21 日。 設備稼働データ (AWS IoT SiteWise) : 各ステーション(受入検査、搬送、自動倉庫、加工、組立、出荷)のリアルタイムなサイクルタイムと稼働率を 1 分間隔で収集しています。Amazon Neptune の Equipment ノード ID と AWS IoT SiteWise のアセット ID を共通化しているため、グラフ探索で特定した設備の最新値を、ID 変換なしにそのまま取得できます。 工程設計書・FMEA (Amazon Bedrock Knowledge Bases) : 各工程の加工条件や運転手順を記述した工程設計書(Word ファイル)、FMEA(Excel ファイル)、PLC コーディング規約(Word ファイル)などのドキュメントを RAG 検索可能にしています。 グラフスキーマの全体像 本デモでは「増産オーダーの実現性診断」を頻出ユースケースとして特定し、そのグラフ探索パス (オーダー → 製品 → 部品 → 設備) を専用ツールとして事前実装しました。ユースケースに登場するエンティティをノード、関係をエッジとして Amazon Neptune に格納し、鮮度の高いデータ (サイクルタイム、在庫数量等) は IoT サービス群や Amazon DynamoDB に分離しています。静的な構造と動的な値を分けることで、レスポンス速度と回答精度を安定させることを目指しました。 しかし、現場では設備起点の問いも発生します。デモでは「オーダー起点で、影響する設備を探しに行く」パスを実装しましたが、現場ではその逆方向、設備で異常が起きたときに「何に影響するか」を知りたい場面が日常的に発生します。「焼成炉の温度が基準を超えた。この設備が停止したら、どの製品の出荷が遅れるか?」、「切削精度の劣化が検出された。同じユニットを使う他ラインの品質にも影響するか?」。これらはグラフ上の同じデータ構造を起点を変えて辿るだけなので簡単な話ですが、事前に定義した固定的な探索パスだけではカバーできません。なので実運用では頻出パターンは専用ツール (固定探索) で高速かつ安定した回答を返し、それ以外の問いには汎用グラフ探索 (LLM がノードの隣接関係を見て自律的に辿る方式) をフォールバックとして組み合わせるハイブリッド構成が現実的ではないかと考えています。 以下は、今回作成したグラフの全体像です。 本デモで定義したグラフスキーマ 本デモでは、グラフの実装基盤として Amazon Neptune を採用しました。Amazon Neptune 上に以下の 8 種類のノードと 10 種類のエッジを定義しました。以下は本ナレッジグラフのスキーマ (型定義) であり、実際の工場データ (インスタンス) はこの型に沿って格納されます。 ノードタイプ (8 種類) No. ノード 説明 例 1 Company 企業 AnyCompany 2 Factory 工場 Plant 02 横浜 3 Equipment 設備・ライン Production Line, Warehouse Station 4 SubUnit 設備内サブユニット Furnace Unit, Milling Machine 5 Product 製品 AnyCompany-SD1 6 Part 部品 セラミック圧力センサー素子 7 Supplier サプライヤー セラミック素材社 8 ProductionOrder 生産オーダー ORDER-2026-06-001 エッジタイプ (10 種類) No. エッジ 関係性 意味 1 CONTAINS Company → Factory 企業が工場を所有 2 HAS_EQUIPMENT Factory → Equipment 工場が設備を保有 3 HAS_SUBUNIT Equipment → SubUnit 設備がサブユニットを持つ 4 REQUIRES Product → Part 製品が部品を必要とする(BOM) 5 SUPPLIED_BY Part → Supplier 部品の調達先 6 STORED_AT Part → Equipment 部品の保管場所 7 PROCESSED_AT Part → Equipment 部品の加工場所 8 ASSEMBLED_AT Part → Equipment 部品の組立場所 9 PRODUCES ProductionOrder → Product オーダーの生産対象 10 EXECUTED_ON ProductionOrder → Equipment オーダーの実行設備 ISA-95 との対応 本デモのグラフモデルは、製造業の国際標準である ISA-95 の設備階層モデルと以下のように対応しています。 No. ISA-95 レベル 本デモのノード 説明 1 Level 4 — Enterprise Company ビジネス計画、オーダー管理 2 Level 4 — Site/Plant Factory 工場単位の生産管理 3 Level 2〜3 — Area/Work Cell Equipment 製造実行・各ステーション制御 4 Level 0〜1 — Control Module SubUnit 個別機器の制御 5 (サプライチェーン) Supplier, Part, Product, ProductionOrder ISA-95 外のビジネスエンティティ 本デモでは簡略化を目的として ISA-95 の Level 2〜3 を Equipment ノードに統合しています。実規模の適用時には、Work Center / Production Line / Work Unit を分離し、より詳細な階層を定義することも可能です。 ここまでで、グラフに格納する「構造」の設計を解説しました。一方、「グラフの全体像」で触れたとおり、鮮度の高いデータはグラフの外に置いています。次のセクションでは、この静的な構造と動的な値の分離を、データストアの役割分担として具体化します。 データストアの役割分担 本デモでは、データの特性に応じて 4 つのデータストアを使い分けています。 No. データストア 格納するもの 更新頻度 1 Amazon Neptune 静的な関係性 (BOM、設備構成、サプライヤー依存) 構造変更時のみ 2 AWS IoT サービス群 各設備のリアルタイム稼働データ (サイクルタイム、稼働率) 1 分間隔 3 Amazon DynamoDB 業務マスタデータ (生産オーダー、在庫、BOP) 日次〜週次 4 Amazon Bedrock Knowledge Bases 非構造化ドキュメント (工程設計書、FMEA、PLC コーディング規約) ドキュメント改訂時 データの置き場所が定まったところで、次は AI エージェントがこれらのデータソースをどのような順序で参照し、回答を組み立てるのかを、実際の問い合わせを例に見ていきます。 AI エージェントの推論フロー 「300 台増産は間に合う?」への回答プロセス AI エージェント (Amazon Bedrock AgentCore 上で動作) がユーザーからの問いに答えるプロセスを見てみます。ユーザーが「ORDER-2026-06-001 の増産 300 台は実現可能ですか?」とプロンプトウインドウに入力します。このとき、エージェントは以下の 5 つのステップを実行します。 Step 1 — ナレッジグラフ探索 (Amazon Neptune) オーダーを起点に、ノードタイプごとに異なる情報を収集しながら関係性を辿ります。 ProductionOrder (ORDER-2026-06-001) │ → 数量: 300台、納期: 7/10 │ ├─PRODUCES→ Product (AnyCompany-SD1) │ │ │ ├─REQUIRES→ Part (セラミック素子) │ │ ├─SUPPLIED_BY→ Supplier (セラミック素材社, LT:14日) │ │ ├─STORED_AT→ Equipment (Warehouse Station) │ │ └─PROCESSED_AT→ Equipment (Production Line) │ │ │ ├─REQUIRES→ Part (ブラシレスモーター) │ │ ├─SUPPLIED_BY→ Supplier (モーター工業, LT:21日) │ │ └─ASSEMBLED_AT→ Equipment (Assembly Line) │ │ │ └─REQUIRES→ Part (フライトコントローラー) │ ├─SUPPLIED_BY→ Supplier (エレクトロニクス社, LT:30日) │ └─ASSEMBLED_AT→ Equipment (Assembly Line) │ └─EXECUTED_ON→ Equipment (Production Line, Assembly Line) 1 回の探索で以下が判明します: 部品 3 種 とそれぞれの所要数・リードタイム サプライヤー 3 社 と最小発注数量 関連設備 3 台 の ID(= AWS IoT SiteWise アセット ID) 各ノードに到達するたびに、次のステップで必要な情報 (ID、属性値) が揃います。Part ノードからは在庫確認 (Step 3) に進み、Equipment ノードからはリアルタイムデータ取得 (Step 2) に進みます。グラフが「次にどのデータソースを見るべきか」を教えてくれる構造です。 Step 2 — リアルタイムデータ取得 (AWS IoT SiteWise) Step 1 で特定した設備の ID (= AWS IoT SiteWise アセット ID) を使い、各設備の現在のサイクルタイムと稼働率を取得します。Amazon Neptune のノード ID と AWS IoT SiteWise のアセット ID に同じ UUID を使用しているので、Amazon Neptune のグラフ探索で特定した設備のノード ID を、そのまま AWS IoT SiteWise の API パラメータとして渡しています。別途マッピングテーブルを参照する必要がなく、グラフの探索結果が即座にリアルタイムデータの取得キーになります。関係性は頻繁には変わりませんがサイクルタイムは 1 分ごとに変わり、在庫数量は日々変動します。こうした鮮度の高いデータはそれぞれに適したデータストアに置き、必要なときに ID をキーにして参照するようにしています。 AWS IoT SiteWise 側のアセット階層: AnyCompany (企業) └── Plant 02 横浜工場 └── Line A ├── DSI (受入検査) assetId: d0754657-... ├── VGR (搬送ロボット) assetId: 787a70d9-... ├── HBW (自動倉庫) assetId: 58f6c640-... ├── MPO (加工機) assetId: 2b326756-... ├── FA (最終組立) assetId: 2c26ccc0-... └── DSO (出荷) assetId: d38bb203-... 各アセットは avg_mct (平均サイクルタイム) と Availability_Pct (稼働率) のプロパティを持ち、1 分間隔で更新されます。Step 1 で特定した設備の ID で問い合わせた結果、HBW のサイクルタイムが目標値 (60秒) の 3 倍に達していることが判明します。 Step 3 — 在庫照合 (Amazon DynamoDB) Step 1 で特定した部品の ID を使い、Amazon DynamoDB の在庫テーブルから現在の数量を取得します。BOM の所要数 (×300 台) と比較した結果、在庫は充足していると判断されます。 No. 部品ID 部品名 在庫 所要数 (×300台) 判定 1 PART-CERAMIC-001 セラミック圧力センサー素子 10,000 300 ✓ 十分 2 PART-MOTOR-001 ブラシレスモーター 30,000 1,200 ✓ 十分 3 PART-FC-001 フライトコントローラー 10,000 300 ✓ 十分 Step 4 — 統合判定 Step 2 (設備) と Step 3 (在庫) の結果を突き合わせ、生産能力を評価します。 ボトルネック: VGR + HBW (実測 CT 254.2 秒。タクトタイム 60 秒の約 4.2 倍、稼働率 35%) 在庫リスク: なし (全部品十分) 問題の所在: 部品は足りているが、HBW の処理能力がライン全体のスループットを制約している Step 5 — 自然言語で報告 エージェントが上記を統合し、以下のように自然言語で回答します。 思考過程 ・ユーザーは「ORDER-2026-06-001 の増産 300 台は実現可能ですか?」と聞いています。これは増産指示の実現性診断を求める質問です。 ・生産オーダー情報を取得します。製品名、数量、納期、ステータスを返します。 ・get_production_order 完了 (0.2s) ・Neptune ナレッジグラフを探索して、指定オーダーの影響範囲とボトルネックを検出します。オーダーから製品→部品→設備→サプライヤーの関係性を辿り、在庫不足やサイクルタイム超過を自動検出します。 ・neptune_impact 完了 (0.3s) ・Production Line のリアルタイム稼働データを一括取得 ・get_production_line_metrics 完了 (3.5s) ・部品の在庫情報を取得します。在庫数、安全在庫、リードタイム、サプライヤーを返します。 ・get_inventory 完了 (0.1s) 回答 ■ 影響範囲 (サプライチェーン探索結果) ・対象オーダー: ORDER-2026-06-001(AnyCompany-SD1 ドローン用圧力センサーモジュール 300台、納期 2026-06-13) ・製品: AnyCompany-SD1 ドローン用圧力センサーモジュール ・生産工場: 横浜工場 ・既存バックログ: 200台(合計処理必要数: 500台) ・必要部品と数量: セラミック圧力センサー素子×300、ブラシレスモーター×1,200、フライトコントローラー×300 ■ ボトルネック検出(リアルタイムデータ) ・VGR+HBW(搬送＋自動倉庫): CT 254.2秒(タクト60秒を194.2秒超過、424%)、稼働率 35.0% ・ライン実効CT: 254.2秒/個(ボトルネック律速) ・日産能力: 39台/日 ・5日間生産可能数: 195台 → 横浜工場ダッシュボードで確認 ■ 在庫状況 ・全部品充足(セラミック圧力センサー素子 10,000個、ブラシレスモーター 30,000個、フライトコントローラー 10,000個) ■ 実現性判定 ・間に合いません:5日間で195台しか生産できず、300台に105台不足 ・既存バックログ200台を含めると合計500台必要。達成には13日(約2週間)必要 ・ボトルネックの搬送＋自動倉庫工程(VGR+HBW)がタクトの4.2倍、稼働率も35%と低い 改善策を提案しますか? 参照データソース ・DynamoDB: 生産オーダーテーブル(ORDER-2026-06-001) ・Neptune: ナレッジグラフ(オーダー→製品→部品の関連) ・IoT SiteWise: 横浜工場 Production Line のリアルタイムデータ(サイクルタイム、稼働率) ・DynamoDB: 在庫テーブル(部品在庫状況) (グラフ上で6ノードをハイライト中) なお、この後に続く改善策の提案 — 工程設計書や FMEA を根拠とした運転方法の変更案、PLC プログラムの修正案の生成 — も本デモの見どころですが、紙幅の都合により本記事では割愛します。 全体アーキテクチャ ここまで、ナレッジグラフの設計と AI エージェントの推論フローを解説してきました。このセクションでは視点を引いて、工場の設備からデータを収集し、エージェントが推論するまでを支えるシステム全体の構成を説明します。 本デモは、エッジ (工場) ・IoT データ収集・AI エージェントの 3 レイヤーで構成されています。工場側では 2 系統のデータ経路を持ちます。設備データは PLC → OPC UA サーバー → AWS IoT Greengrass → AWS IoT SiteWise という経路で収集されます。OPC UA は設備のリアルタイム値だけでなくアセット階層(設備間の親子関係や型定義)も標準化された形で公開するため、AWS IoT SiteWise 側でデータストリームとアセット階層の両方を構造化して管理できます。カメラ映像は別系統で、ONVIF 対応カメラ → Raspberry Pi 上の AWS IoT Greengrass → Amazon Kinesis Video Streams に送信されます。カメラの PTZ 制御は AWS IoT Core 経由の MQTT で行い、AI エージェントから操作可能です。 AI エージェントレイヤーでは、Amazon Bedrock AgentCore 上で Strands SDK ベースのオーケストレーターが動作し、問いの種類に応じて専門サブエージェントに処理を委譲します。本記事で解説した実現性診断のフロー (Step 1〜5) は Production Analyst が担当し、カメラ映像による現場確認は Camera Inspector、FMEA など品質文書の参照は QA Manager、制御プログラムの変更案生成は PLC Engineer が担います。各サブエージェントは Amazon Neptune (ナレッジグラフ探索)、AWS IoT SiteWise (リアルタイム値取得) 、DynamoDB (BOP・在庫・オーダー) 、Amazon Bedrock Knowledge Bases (工程設計書・FMEA) 、Amazon Kinesis Video Streams (映像フレーム取得) にアクセスします。 以上が本デモの技術的な全体像です。最後に、実際にブースで来場者の方々と対話する中で見えてきた、実運用に向けた課題を考察します。 全体アーキテクチャ お客様の声と課題 AWS Summit Japan 2026 のブースで製造業のお客様から得たフィードバックのうち、特に多かった 3 点と現時点での見解を共有します。 「関係性を最初に定義するのが大変だ」 — 本デモでは生成 AI に グラフスキーマの定義 を依頼し、一括で生成することで対応しました。「増産診断」というユースケースが明確だったため、必要な関係性の範囲を絞れたことが大きいです。ただし、対象範囲やノード数が拡大した場合に同じ手法でスケールするかは検証が必要です。 「グラフのメンテナンスが大変では?」 — ブースでは「BOM 階層が 100 近くある」という声も戴きました。本デモは数十ノード程度の規模であり、そうした現実のスケールでの変更管理、例えば ERP マスタ変更をイベント駆動で Amazon Neptune に反映するパイプラインなどは今後取り組む必要があります。 「そもそもデータが揃っていない」 — AI エージェント活用デモの多くは参照先データが整備済みの前提で構築されており、本デモも例外ではありません。ただ、本デモは全データをグラフに集約せず、グラフ・IoT・DynamoDB・ドキュメントをそれぞれ別のツールとしてエージェントに持たせる構成にしています。この形だと、新しいデータソースが用意できたときに既存の構成を作り直さず、ツールを 1 つ足すことで対応できます。全体が揃うのを待つのではなく、まず 1 ユースケースに必要なデータから始めて、揃った分だけ段階的に足していく進め方も、選択肢としてあり得るのではないかと考えています。 まとめ 本記事では、AWS Summit Japan 2026「生産ラインの未来」ブースで展示したデモの技術詳細として、製造ドメインのグラフスキーマの設計と、そこに IoT データを接続する方式を解説しました。取り組んだのは「AI エージェントに工場の構造をどう教えるか」というテーマです。製品・部品・設備・サプライヤーの関係を型とエッジとして定義し、Amazon Neptune 上のナレッジグラフに実装しました。サイクルタイムや在庫といった鮮度の高いデータはグラフに持たせず、AWS IoT SiteWise や Amazon DynamoDB から必要なときに参照します。変わりにくい構造と、刻々と変わる値を分けることで、エージェントの回答を速く安定させることを目指しました。一方で、本デモで定義したのは、型（ノード）と、型の間にどの関係が張れるかまでで、その関係自体が従うルールは定義していません。次のステップとして考えられるのは、こうしたルールを RDF/OWL のような形式で記述し、オントロジーへと発展させることです。明示的にリンクを張らなくても不良素材から影響製品を辿れたり、データの矛盾を自動で検出できたりと、対応できる範囲を広げられると考えています。本記事が、製造業のお客様が自社のデータを AI エージェントで活かすための一歩として、参考になれば幸いです。 使用サービス Amazon Neptune — 製造ドメインのナレッジグラフ Amazon Bedrock / Amazon Bedrock AgentCore — AI エージェントの推論基盤 Amazon Bedrock Knowledge Bases — 工程設計書のドキュメント検索 AWS IoT Greengrass — エッジゲートウェイ AWS IoT Core — デバイス接続 AWS IoT SiteWise — 設備稼働データの構造化・蓄積 Amazon Kinesis Video Streams — 工場カメラ映像の管理 Amazon DynamoDB — 生産オーダー・在庫・BOP の格納 著者 新澤 雅治 (Masaharu Niizawa) — IoT Specialist Solutions Architect。製造業、IT 企業を経て AWS に入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 松永 充弘 (Mitsuhiro Matsunaga) — Senior Solutions Architect。製造業のお客様を担当するソリューションアーキテクト。クラウド × データ × AI でお客様のビジネスを支援。前職では製造業にて、機器の IoT 化、AI 活用を担当。 関連リンク AWS Summit Japan 2026 ブース紹介 生産ラインの未来 Amazon Neptune — 概要 Amazon Bedrock AgentCore — 概要 AWS IoT Core ー 概要 AWS IoT Greengrass ー 概要 AWS IoT SiteWise — 概要

本記事は 2026 年 5 月 26 日 に公開された「 Preserving custom domain names for Amazon RDS for Db2 」を翻訳したものです。 IBM Db2 のワークロードをオンプレミスから Amazon Relational Database Service (Amazon RDS) for Db2 へ移行するお客様からは、既存のアプリケーション接続文字列を変更せずに使い続ける方法についてよく質問をいただきます。Amazon RDS for Db2 は、DB パラメータグループの ssl_svcename パラメータと db2comm レジストリ変数を SSL または SSL,TCP に設定することで、エンドツーエンドの暗号化をネイティブにサポートしています。ただしアプリケーションは、あらかじめ定義された RDS エンドポイント (例: mydb.abc123.us-east-1.rds.amazonaws.com:50000 ) に接続する必要があります。 proddb.company.com:1443 から RDS エンドポイントへ切り替えるために数百ものアプリケーション接続文字列を書き換える作業は、コストがかかり、ミスも生じやすく、リフトアンドシフト移行の速度を低下させます。 本記事では、 aws-samples/sample-rds-db2-tools リポジトリで公開されているモジュール化された Terraform テンプレートを紹介します。このテンプレートを使うと、Amazon RDS for Db2 へのエンドツーエンドの TLS 暗号化を維持しながら、アプリケーションが既存のカスタムドメイン名とポートをそのまま利用できます。テンプレートは、Server Name Indication (SNI) ベースの TLS プロキシをデプロイし、暗号化されたトラフィックを復号することなく転送します。 ソリューションの概要 テンプレートは、次の図のように 5 つの番号付き Terraform モジュールに分割されています。 各モジュールはスタックの特定の部分を担当し、それぞれ独立したリモート状態を保持します。そのため、他のモジュールに影響を与えずに 1 つのモジュールだけを更新できます。テンプレートは、状態管理とロックに Amazon Simple Storage Service (Amazon S3) と Amazon DynamoDB を使用し、証明書の保管に AWS Secrets Manager と AWS Certificate Manager (ACM) を使用します。 モジュール 作成されるもの 0-backend-setup Terraform のリモート状態用の Amazon S3 バケットと Amazon DynamoDB テーブル 1-prerequisites AWS Secrets Manager と ACM に保管される自己署名 SSL 証明書 2-infrastructure OpenResty (Nginx) を実行する Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Network Load Balancer (NLB) 、 Amazon Route 53 のプライベートホストゾーン 3-mappings AWS Systems Manager パラメータストア内のカスタムドメインから RDS エンドポイントへのマッピング、およびポートごとに動的に作成される NLB リスナーとターゲットグループ 4-health-check デプロイの検証 (EC2 のステータス、リッスンしているポート、ターゲットグループのヘルス、設定ファイル) プロキシは TLS の ClientHello から SNI フィールドを読み取り、暗号化されたストリームを一致する RDS エンドポイントへ転送します。トラフィックはプロキシ上で復号されないため、クライアントから RDS までエンドツーエンドの暗号化が維持されます。EC2 インスタンス上の cron ジョブが 5 分ごとにパラメータストアからプロキシ設定を更新するため、データベースの追加や削除の際にインフラストラクチャを再デプロイする必要はありません。 前提条件 この手順を進めるには、次のものが必要です。 Amazon EC2、NLB、Route 53、 AWS Identity and Access Management (IAM) 、AWS Secrets Manager、ACM、Amazon S3、Amazon DynamoDB のリソースを作成する権限を持つ AWS アカウント。リポジトリには terraform-service-account-policy.json と サービスアカウントのセットアップガイド が同梱されています。 ローカルにインストールされた Terraform 1.5 以降、AWS Command Line Interface (AWS CLI)、および jq 。 少なくとも 2 つのアベイラビリティーゾーンにプライベートサブネットを持ち、DNS ホスト名と DNS 解決が有効になっている既存の Amazon Virtual Private Cloud (Amazon VPC) 。 SSL アクセス用に設定された 1 つ以上の Amazon RDS for Db2 インスタンス。 db2comm を SSL または SSL,TCP に設定し、DB パラメータグループの ssl_svcename で SSL ポートを定義します。詳細については、 Amazon RDS for Db2 DB インスタンスでの SSL/TLS の使用 を参照してください。 リポジトリをクローンします。 git clone https://github.com/aws-samples/sample-rds-db2-tools.git cd sample-rds-db2-tools/tools/End-to-End-Trust ウォークスルー 以下の各サブセクションでは、それぞれのステップを要約します。完全なコマンド、変数の説明、サンプルの tfvars ファイルは、リポジトリの README からリンクされている各モジュールの README にあります。 ステップ 1: リモート状態を初期化する 残りのモジュールの状態を保持する S3 バケットと DynamoDB テーブルを作成します。 cd 0-backend-setup ./bootstrap-backend.sh terraform init && terraform apply --auto-approve cd .. ./configure-modules.sh configure-modules.sh スクリプトは、モジュール 1 から 4 に backend.tf を書き込み、すべてが同じ共有状態バケットを使用するようにします。 ステップ 2: 証明書を生成する モジュール 1 は、ワイルドカードのカスタムドメイン (例: *.db.mycompany.com) 用の自己署名証明書を生成し、秘密鍵を AWS Secrets Manager に、証明書を ACM に保管します。 terraform.tfvars を aws_region 、 domain_name 、 organization で編集し、 terraform init && terraform apply --auto-approve を実行します。 本番環境では、自己署名証明書を、企業の認証局が発行した証明書に置き換えてください。自己署名のフローは、開発およびテスト用です。 ステップ 3: プロキシインフラストラクチャをデプロイする モジュール 2 は、EC2 プロキシ、NLB、および Route 53 プライベートホストゾーンをデプロイします。 ./configure-infrastructure.sh を実行して VPC、サブネット、セキュリティグループを対話的に選択するか、 terraform.tfvars を手動で記述します。スクリプトがファイルを生成し、モジュール 2 が NLB を EC2 プロキシに接続し、証明書とパラメータストアの読み取りを許可するインスタンスプロファイルをアタッチして、NLB を指すワイルドカード DNS レコードをカスタムドメイン配下に作成します。 ステップ 4: RDS マッピングを設定する モジュール 3 では、どのカスタムドメインとポートをどの RDS エンドポイントにルーティングするかを記述します。 rds_mappings = { "proddb.company.com:1443" = "mydb-prod.abc123.us-east-1.rds.amazonaws.com:50000" "testdb.company.com:1443" = "mydb-test.def456.us-east-1.rds.amazonaws.com:50000" "devdb.company.com:50443" = "mydb-dev.ghi789.us-east-1.rds.amazonaws.com:50000" } モジュールは一意のクライアントポート (この例では 1443、50443) を抽出し、ポートごとに 1 つの NLB リスナーとターゲットグループを作成して EC2 プロキシを登録し、各マッピングを /rds/proxy/mappings/<domain> 配下のパラメータストアに書き込みます。EC2 インスタンス上の cron ジョブが 5 分以内に新しいマッピングを取得し、プロキシ設定を再読み込みします。 後からデータベースを追加または削除するには、 rds_mappings を編集して terraform apply を実行し、cron ジョブを待ちます。インフラストラクチャの再デプロイは不要です。 ステップ 5: デプロイを検証する モジュール 4 は、EC2 インスタンスが実行中であること、SSM エージェントがオンラインであること、 OpenResty がアクティブであること、マッピングされたすべてのポートがリッスンしていること、すべての NLB ターゲットグループが正常であること、プロキシ設定と証明書がインスタンス上に存在することを検証する、スクリプト化されたヘルスチェックを実行します。 4-health-check から terraform init && terraform apply --auto-approve を実行します。実行に成功すると、次のようなサマリーが出力されます。 ✓ EC2 instance is running ✓ OpenResty service is active ✓ Port 1443 is listening ✓ Port 50443 is listening ✓ Port 1443 target group: healthy ✓ Port 50443 target group: healthy ✓ RDS mappings configured (3 entries) ステップ 6: Db2 クライアントから接続する 同じ VPC 内 (またはプロキシ VPC とピアリングされた Amazon VPC) の Db2 クライアントから、リージョン固有の RDS 証明書バンドル (例: us-east-1-bundle.pem ) をダウンロードし、カスタムドメインとポートを使用するように db2dsdriver.cfg を設定します。 <dsn alias="PRODDB" host="proddb.company.com" name="BLUDB" port="1443"> <parameter name="SSLServerCertificate" value="/home/db2user/certs/us-east-1-bundle.pem"/> <parameter name="SecurityTransportMode" value="SSL"/> <parameter name="TLSVersion" value="TLSV12"/> </dsn> 次に接続します。 db2 connect to PRODDB user <username> using <password> プロキシはストリームを一切復号しないため、クライアントが検証する証明書は RDS の証明書となり、接続がエンドツーエンドで暗号化されていることが確認できます。Java KeyStore の設定を完全に回避する Java クライアントのレシピについては、 KeyStore や Keytool を使わずに Java で Amazon RDS for Db2 への SSL 接続を作成する を参照してください。 クリーンアップ 継続的な課金を避けるため、モジュールを逆順に破棄します。 ./cleanup.sh スクリプトはモジュール 3 から 1 を破棄し、状態バケットから rdsdb2-proxy/* プレフィックスを削除して、ローカルの Terraform ファイルをリセットします。モジュール 0 の状態バケットと DynamoDB テーブルは保持されるため、同じアカウント内の他の Terraform プロジェクトには影響しません。不要になった場合は手動で削除してください。 考慮事項と制限事項 このテンプレートは移行期の暫定的なソリューションとして設計しました。目的は、アプリケーション接続文字列を初日から書き換えることなく Amazon RDS for Db2 へ移行する時間を確保し、その後アプリケーションがネイティブの RDS エンドポイントを採用するにつれてプロキシを廃止できるようにすることです。アプリケーションを本当に変更できない場合 (例: 接続文字列がハードコードされたサードパーティ製アプリケーション) は、プロキシを無期限に運用することもできますが、その場合は運用、監視、パッチ適用が必要な追加のインフラストラクチャとして扱う必要があります。 コスト。 プロキシは、RDS for Db2 の料金に加えて、次の費用が発生します (参考として us-east-1 のリスト価格を使用)。 Amazon EC2 インスタンス 1 台: t3.medium (開発用) で月額約 30 ドル、 c8i.large (本番のベースライン) で月額約 55 ドル。高可用性のためにアベイラビリティーゾーンをまたいで 2 台にすると、おおよそこの倍になります。 Network Load Balancer 1 台: アベイラビリティーゾーンあたり月額約 16 ドルに加え、LCU 時間あたり 0.006 ドルと GB あたりのデータ処理料金。低ボリュームのワークロードでカスタムポートが 1 つか 2 つの場合、NLB の料金は通常月額 25 ドル未満に収まります。 Amazon Route 53 プライベートホストゾーン: ゾーンあたり月額 0.50 ドルに加え、100 万クエリあたり 0.40 ドル。 AWS Secrets Manager と AWS Systems Manager パラメータストア: 証明書のシークレットと標準ティアのマッピングパラメータで月額 1 ドル未満。 単一インスタンスのリファレンスデプロイは、通常月額 50 ドルから 100 ドルの間に収まります。 c8i.large の Auto Scaling グループを使用する 2 アベイラビリティーゾーンの本番デプロイは、データ転送料金を除いて月額 140 ドルから 200 ドルの間に収まります。 運用上の考慮事項。 デプロイを計画する際は、次の点に留意してください。 リファレンスアーキテクチャの単一障害点。 モジュール 2 は EC2 インスタンスを 1 台デプロイします。本番環境では、アベイラビリティーゾーンをまたいで 2 台以上のインスタンスを同じ NLB ターゲットグループに登録する Auto Scaling グループに置き換えてください。プロキシはステートレスなので、スケールアウトは容易です。 デフォルトでは自己署名証明書。 モジュール 1 は、ウォークスルーが単独で完結するように自己署名ワイルドカード証明書を生成します。本番環境では、企業の認証局が発行した証明書に置き換え、同じパラメータ名を使用して AWS Certificate Manager と AWS Secrets Manager にインポートしてください。 SNI が必須。 プロキシは、TLS の ClientHello の SNI 拡張を読み取って接続をルーティングします。最新の Db2 クライアントは SSL が設定されていると SNI を送信しますが、SNI を送信しないレガシークライアントはルーティングできず、単一の RDS エンドポイントにマッピングされたポートを使用する必要があります。 設定更新の遅延。 rds_mappings の新しいエントリは、EC2 の cron ジョブによって 5 分以内に取得されます。それを見込んで変更を計画するか、即時に更新するにはインスタンス上で /usr/local/bin/update-nginx-config.sh を実行してください。 DNS のスコープ。 Route 53 ホストゾーンはプライベートです。クライアントは、ゾーンに関連付けられた VPC (プロキシ VPC、ピアリングされた VPC、または Route 53 Resolver ルールを使用して AWS Transit Gateway 経由で到達可能な VPC) からカスタムドメインを解決する必要があります。パブリック DNS の解決は意図的に公開されていません。 単一リージョンのデプロイ。 テンプレートは 1 つの AWS リージョンにデプロイされます。マルチリージョンの災害対策のためには、各リージョンにテンプレートを個別にデプロイし、フェイルオーバーには Route 53 のヘルスチェックを使用してください。 キャパシティプランニング。 OpenResty は TCP パススルーで効率的に動作し、 c8i.large インスタンスは数千の同時接続を余裕を持って処理しますが、プロキシが集約ワークロードに見合ったサイズになるよう、 CPUUtilization 、 NetworkIn 、 NetworkOut 、および NLB の HealthyHostCount と ActiveFlowCount を監視する必要があります。 プロキシからの移行パス。 アプリケーションがネイティブの RDS エンドポイントに接続するよう更新されたら、対応するエントリを rds_mappings から削除して terraform apply を実行します。最後のエントリを削除したら、 cleanup.sh を実行してプロキシインフラストラクチャを廃止します。 まとめ このモジュール化された Terraform テンプレートを使うと、真のエンドツーエンドの TLS 暗号化を維持しながら、アプリケーション接続文字列を 1 つも書き換えることなく IBM Db2 ワークロードを Amazon RDS for Db2 へリフトアンドシフトできます。プロキシは TLS 終端ではなく SNI ルーティングを使用するため、暗号化されたストリームはバイト単位でそのまま RDS へ転送されます。各モジュールは小さく、焦点が絞られ、冪等性があるため、段階的に採用でき、プロキシのロジックを変更せずにネットワークレイヤーを単一 VPC、マルチ VPC、AWS Transit Gateway、AWS PrivateLink、ハイブリッドのデプロイパターンに適応させられます。 完全なテンプレート、パラメータリファレンス、トラブルシューティングガイド、サンプルの tfvars ファイルは、 aws-samples/sample-rds-db2-tools で入手できます。 AWS における Db2 関連のコンテンツについては、 Deploying Amazon RDS for Db2 using Terraform 、 Amazon RDS for Db2 ユーザーガイド 、および AWS Database Blog を参照してください。 謝辞 本記事をレビューしてくれた Rajib Sarkar と Kshitoj Sanghoi 、そしてソリューションを徹底的にテストしてくれた Muhammad Gaballah に心から感謝します。 著者について Vikram Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。プロダクトマネジメント、経験豊富なアーキテクト、リーダーシップ、AI エキスパートユーザーなど、複数の役割を担っています。20 年以上の経験を持ち、新しい製品をゼロから開発することに情熱を注いでいます。 Sumit Kumar Sumit は、 Sumit は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを楽しんでいます。さまざまな業界のお客様が AWS クラウド上でワークロードを構築・設計するのを支援してきました。料理、チェス、家族と過ごす時間を楽しんでいます。 Ashish Prasad Ashish は、 Ashish は AWS のシニアソリューションアーキテクトであり、リードデータベースアーキテクトです。データベース技術において 20 年以上の経験を持っています。 この記事はSolutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 5 月 19 日 に公開された「 Deploying Amazon RDS for Db2 using Terraform 」を翻訳したものです。 IBM Db2 ワークロードを運用しているお客様からは、既存の Infrastructure as Code のプラクティスに適合する形で、Amazon Relational Database Service (Amazon RDS) for Db2 を再現性が高く監査可能な方法でプロビジョニングしたいという要望をよくいただきます。本記事では、 aws-samples/sample-rds-db2-tools リポジトリで公開しているモジュール式の Terraform テンプレートを紹介します。このテンプレートを使えば、空の AWS アカウントから、AWS License Manager で追跡される稼働中の RDS for Db2 インスタンスまでを 1 時間以内で構築できます。 ソリューションの概要 テンプレートは、以下の図のように 7 つの番号付き Terraform モジュールに分かれています。 各モジュールはスタックの特定の部分を担い、独自のリモートステートを保持します。そのため、他のモジュールに影響を与えることなく 1 つのモジュールだけを変更できます。ステート管理、ロック、暗号化には、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、AWS Key Management Service (AWS KMS) を使用します。 モジュール 作成されるもの 0-backend-setup Terraform のリモートステート用の Amazon S3 バケットと Amazon DynamoDB テーブル 1-networking 仮想プライベートクラウド (VPC) から導出した DB サブネットグループ (オプションでインターフェイス型 VPC エンドポイントを含む) 2-iam 拡張モニタリング、S3 統合、ディレクトリサービス、監査用の IAM ロール 3-kms カスタマーマネージド AWS KMS キー (マルチリージョン対応) 4-parameter-group IBM カスタマー ID と IBM サイト ID を含む DB パラメータグループ 5-rds RDS for Db2 インスタンス本体 6-license-manager エンジンエディションの製品フィルターを持つ AWS License Manager のセルフマネージドライセンス 各モジュールは入力値を terraform.tfvars ファイルから読み取り、AWS プロバイダーで default_tags を使用するため、すべてのリソースに一貫したタグ ( Project 、 ManagedBy 、 Environment 、 Owner ) が付与されます。 テンプレートは、AWS の商用リージョンと AWS GovCloud (US) リージョンの両方に対応しています。すべての ARN は aws_partition データソースを使って構築されるため、同じコードで商用リージョンでは arn:aws:... 、GovCloud では arn:aws-us-gov:... を修正なしで生成できます。 前提条件 この手順を進めるには、以下が必要です。 IAM ロール、KMS キー、RDS インスタンス、License Manager の設定を作成する権限を持つ AWS アカウント。 ローカルにインストールされた Terraform 1.5 以降。 RDS for Db2 インスタンスを実行する既存の Amazon Virtual Private Cloud (Amazon VPC) とセキュリティグループ。 IBM カスタマー ID と IBM サイト ID (Bring Your Own License に必要。 RDS for Db2 のライセンスに関するドキュメント を参照)。 リポジトリをクローンします。 git clone https://github.com/aws-samples/sample-rds-db2-tools.git cd sample-rds-db2-tools/tools/rds-db2-terraform ウォークスルー 以降のセクションで各モジュールの概要を説明します。完全なコマンド、変数の説明、サンプルの tfvars ファイルは、リポジトリの README にあります。 ステップ 1: リモートステートの初期化 残りのモジュールのステートを保持する S3 バケットと DynamoDB テーブルを作成します。 cd 0-backend-setup cp terraform.tfvars.example terraform.tfvars # edit terraform.tfvars to set a globally unique bucket name terraform init && terraform apply cd .. ./configure-modules.sh configure-modules.sh スクリプトは、各下流モジュールに backend.tf を書き込み、すべてのモジュールが同じ共有ステートバケットを使用するようにします。 ステップ 2: ネットワーク、IAM、暗号化 モジュール 1 から 3 で、支えとなるインフラストラクチャをセットアップします。それぞれ 1 分以内に完了します。 1-networking は、VPC のサブネットをルートテーブルに基づいてパブリックまたはプライベートに自動分類し、適切なサブネットで DB サブネットグループを作成します。 2-iam は、それぞれブール値のフラグで制御される 4 つのオプションの IAM ロールを作成します。対応する _exists フラグを設定すれば既存のロールを再利用でき、 EntityAlreadyExists エラーを回避できます。 3-kms は、カスタマーマネージド KMS キーを作成するか、エイリアス検索で既存のキーを再利用します。後でクロスリージョンのスタンバイレプリカを追加する予定がある場合は、 multi_region_key = true を設定します。 ステップ 3: パラメータグループ モジュール 4 は、IBM カスタマー ID と IBM サイト ID を含む DB パラメータグループを作成します。検証によってサポートされる組み合わせが強制されます。Db2 11.5 ではエディション se と ae 、Db2 12.1 では ce 、 se 、 ae を受け付けます。どちらの ID も sensitive としてマークされるため、プランの出力には表示されません。 ステップ 4: RDS for Db2 インスタンス モジュール 5 は最も実行時間が長いステップです (ストレージサイズやマルチ AZ を有効にするかどうかによって 15 分から 40 分)。事前に決めなければならない項目を減らす便利な機能がいくつか用意されています。 engine_version を空白のままにすると、選択したメジャーバージョンの最新マイナーバージョンが自動的に解決されます (たとえば Db2 11.5 は 11.5.9.0 に解決されます)。 db_instance_identifier を空白のままにすると、エンジン、バージョン、インスタンスクラス、ストレージタイプ、タグから db2se-11-5-r7i-xl-xs-gp3-saz-12k-myproj のような名前が自動的に構築されます。 manage_master_user_password = true (デフォルト) を設定すると、RDS がマスターパスワードを AWS Secrets Manager で作成し、ローテーションします。シークレットの ARN は managed_master_user_secret_arn としてエクスポートされます。 このモジュールは gp3 の IOPS ルールも処理します。 allocated_storage < 400 GiB の場合は iops と storage_throughput の引数を省略し、API がリクエストを受け付けられるようにします。 ステップ 5: License Manager モジュール 6 は、セルフマネージドのライセンス設定を作成します。 RDS for Db2 のライセンスに関するドキュメント に従い、BYOL を利用するお客様は License Manager で vCPU の消費量を登録します。その後、License Manager はエンジンエディションの製品情報フィルターを使って、該当する RDS インスタンスを自動的に検出します。 重要な注意点が 2 つあります。 アカウントとリージョンで License Manager を初めて使用する際は、サービスにリンクされたロールを作成する必要があります。このモジュールには、これを冪等に実行する bootstrap.sh スクリプトが含まれています。最初の terraform apply の前に一度実行してください。 AWS Terraform プロバイダーは現在、 aws_licensemanager_license_configuration の product_information_list ブロックを公開していません。このモジュールは、作成後に null_resource を使って AWS Command Line Interface (AWS CLI) 経由で aws license-manager update-license-configuration を呼び出すことで、この制約を回避します。該当する RDS インスタンスの検出には最大 24 時間かかることがあります。 クリーンアップ 継続的な課金を避けるため、モジュールを逆順に破棄します。 ./cleanup.sh 0-backend-setup モジュールでは、ステートバケットとロックテーブルに prevent_destroy = true が設定されています。ステートバックエンド自体を破棄したい場合は、まずそのライフサイクルルールを削除してください。 まとめ このモジュール式の Terraform テンプレートを使えば、リモートステートと License Manager 統合を最初から備えた形で、本番環境レベルの Amazon RDS for Db2 をプロビジョニングできます。さらに、GovCloud 互換性のためのパーティション対応 ARN や、RDS が管理するマスターパスワードも利用できます。各モジュールは小さく焦点が絞られており、冪等であるため、段階的に導入できます。たとえば、 3-kms モジュールを既存の KMS エイリアスに向けたり、モニタリングと監査のロールがすでに存在する場合は 2-iam を丸ごとスキップしたりできます。 完全なテンプレート、パラメータリファレンス、トラブルシューティングガイド、サンプルの tfvars ファイルは、 aws-samples/sample-rds-db2-tools で入手できます。 AWS における Db2 関連のコンテンツについては、 Amazon RDS for Db2 ユーザーガイド と AWS Database Blog を参照してください。 著者について Vikram S Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。プロダクトマネジメント、経験豊富なアーキテクト、リーダーシップ、AI エキスパートユーザーなど、複数の役割を担っています。20 年以上の経験を持ち、製品をゼロから開発することに情熱を注いでいます。 Sumit Kumar Sumit は、 Sumit は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを楽しんでいます。さまざまな業界のお客様が AWS クラウド上でワークロードを構築・設計できるよう支援してきました。料理やチェス、家族と過ごす時間を楽しんでいます。 Ashish Prasad Ashish は、 Ashish は AWS のシニアソリューションアーキテクトであり、リードデータベースアーキテクトです。データベース技術において 20 年以上の経験を持っています。 Javeed Mohammed Javeed は、 Javeed は Amazon Web Services (AWS) のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームに所属し、Oracle や Db2 といった商用データベースエンジンを専門としています。お客様と協力して、AWS クラウド上でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援することに取り組んでいます。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。