Amazon Web Services ブログ

週刊AWS – 2026/7/13週

Tomoya Tozuka — Tue, 21 Jul 2026 09:03:14 +0000

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も週刊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 商用リージョンで追加料金なしで利用できます｡

それでは、また来週お会いしましょう！

著者について

週刊生成AI with AWS – 2026/7/13 週

Aiichiro Noma — Tue, 21 Jul 2026 05:18:21 +0000

みなさん、こんにちは。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 実用化推進プログラム」も引き続き実施中ですので検討してみてください。

今週は以上です。それでは、また来週お会いしましょう！

著者について

AWS Summit Japan 2026 に見る Resilience at AWS

Mai Ando — Tue, 21 Jul 2026 03:47:42 +0000

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 2026 – Tokyo (2026年8月4日開催)

Aiichiro Noma — Mon, 20 Jul 2026 20:04:19 +0000

イベント概要

半導体業界をリードする企業の皆様をお迎えし、昨年ご好評いただいた「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 メンバーへのご質問の時間としてご活用ください

アジェンダや参加パートナー企業は変更となる可能性がございます。

一部のセッションは英語での提供となりますが、通訳を手配する予定です。

22社51名の参加者が2時間で業務アプリを自作し発表！Claude ・Kiro実践ワークショップの記録

岩上剛 — Mon, 20 Jul 2026 09:01:54 +0000

このワークショップで起きたこと

みなさん、こんにちは。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側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください。

【開催報告】AWS Summit Japan 2026 〜 Future of Agentic Commerce ブース

中島佑樹 — Fri, 17 Jul 2026 11:47:34 +0000

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 です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

Chronos-2 on Amazon SageMaker AI にアクセスする3つのパターン – AutoGluon-Cloud v0.5.0 で数行に

Satoshi Terayama — Fri, 17 Jul 2026 07:51:58 +0000

みなさん、こんにちは。ソリューションアーキテクトの寺山です。
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 を始めとした機械学習領域での学びを深めています

バックアップ用オンプレミス Db2 サーバーを Amazon RDS for Db2 と同期する

Satoru Yagi — Fri, 17 Jul 2026 07:07:06 +0000

本記事は 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 に感謝します。

著者について

この記事はSolutions Architect の矢木覚が翻訳しました。

エブリーが、Aurora DSQL の採用でデータベースコストを 90% 以上削減とメンテナンス運用からの解放も実現

Yoshio Uchiyama — Fri, 17 Jul 2026 06:41:36 +0000

株式会社エブリーは、「前向きなきっかけを、ひとりひとりの日常にとどける。」というミッションのもと、デリッシュキッチン、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 は、高い可用性とスケーラビリティを必要とするシステムにおいて、運用負荷とコストの低減が期待できるデータベースです。本ブログが、同様の課題を持つお客様にとって参考になれば幸いです。

AWS DMS を使って Amazon RDS for Db2 からオンプレミスの AIX Db2 へフェイルバックする

Satoru Yagi — Fri, 17 Jul 2026 05:25:03 +0000

本記事は 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 上の恒久的なアーキテクチャへ移行します。

著者について

この記事は Solutions Architect の矢木覚が翻訳しました。

Amazon Web Services ブログ

週刊AWS – 2026/7/13週

2026年7月13日週の主要なアップデート

著者について

週刊生成AI with AWS – 2026/7/13 週

さまざまなニュース

サービスアップデート

著者について

AWS Summit Japan 2026 に見る Resilience at AWS

AWS セッションより

大規模障害から考える、AWS 上で備えるべきレジリエンスの実践

Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－

AWS DevOps Agent による自律的インシデント対応 －その能力を引き出す設計のベストプラクティス－

ランサムウェアに対して最優先で取るべき AWS の復旧対策

AWS ブース展示より

レジリエンス強化と障害対応につかえる AI 体験

大阪リージョンを使用したマルチリージョン構成のデモ（たこ焼き AI 大将）

AWS レジリエンス体験ゲーム 〜 選ぶだけで学べる、障害対応の意思決定

進化する金融 × レジリエンス 〜 金融システムを支えるセキュリティ＆レジリエンス

人間 vs AI 障害対応バトル – Chaos Kitty Challenge

大阪リージョンデータセンター 最新の災害対策

まとめ

著者について

EDA on the Cloud 2026 – Tokyo (2026年8月4日開催)

イベント概要

開催日時

開催場所

参加対象者

想定している参加者様のレベル

定員

参加申し込みについて

プログラム内容

22社51名の参加者が2時間で業務アプリを自作し発表 ！Claude ・Kiro実践ワークショップの記録

このワークショップで起きたこと

ワークショップの出発点

プログラム構成

ワークショップ全体像

アプリ発表事例：日本曹達 宮形様の農業化学品FAQデータベース

他の発表者が作ったアプリ

ワークショップ後の懇親会

高い満足度 の背景 ― 何がうまくいったのか

ワークショップ後の支援

【開催報告】AWS Summit Japan 2026 〜 Future of Agentic Commerce ブース

Agentic Commerce とは

AWS 展示ブーステーマ 「Future of Agentic Commerce」

複数の EC 事業者にまたがって商品を探し、1 つの仮想的なカートで管理した上で、AI プラットフォーマーが提供するウォレットで購入するケース（購入の最終確認はユーザー自身が行い、確認ボタンを経て決済する）

同じくウォレットでの購入において、あらかじめ 5,000 円以下の決済権限をエージェントに与えておき、その条件に該当する場合はユーザーの確認なしにエージェントが購入まで自律的に実行するケース

仮想的なカートに商品を入れるところまでは同様だが、そこから「EC で購入したい」ボタンを押すことで、連携先の EC 事業者側のカートに商品が転送され、そちらで購入を完了できるケース

Onsite Agent が自社 EC 上で最適化された UI/UX を通じて、来訪したお客様をおもてなしするケース

注文した商品が在庫切れとなった場合の例外処理を EC バックオフィスエージェントが検知し、ユーザーに代替品を提案するケース

Agent に Apps を導入して EC 側のデザインやビジネスロジックを持ち込むケース

Demo システム全体像

Demo システムで利用している AWS サービス

アーキテクチャのポイント

AI プラットフォーマー側

EC 事業者側

プロトコルについて（UCP / AP2 / ECP）

認証について（補足）

実装上の注意点

ご来場いただいたお客様の声

まとめ

著者

中島 佑樹

木下 尚英 (Naohide Kinoshita)

堀内 保大 (Yasuhiro Horiuchi) / @ka_shino_ki

西村 忠己(Tadami Nishimura) / @tdmnishi

Chronos-2 on Amazon SageMaker AI にアクセスする3つのパターン – AutoGluon-Cloud v0.5.0 で数行に

1.背景

2. 事前準備

3. Chronos-2 をデプロイする3つの方法

3.1 リアルタイム推論

3.2 サーバーレス推論

3.3 バッチ変換

4. ユースケースに合わせた推論タイプの選定

SageMaker AI の制約:

推論タイプの選び方例

リアルタイム推論を選ぶシーン:

サーバーレス推論を選ぶシーン:

バッチ変換を選ぶシーン:

5. まとめ

AWS DevOps Agent による自律的インシデント対応－その能力を引き出す設計のベストプラクティス－

AWS レジリエンス体験ゲーム〜選ぶだけで学べる、障害対応の意思決定

進化する金融 × レジリエンス〜金融システムを支えるセキュリティ＆レジリエンス

大阪リージョンデータセンター最新の災害対策

22社51名の参加者が2時間で業務アプリを自作し発表！Claude ・Kiro実践ワークショップの記録

アプリ発表事例：日本曹達宮形様の農業化学品FAQデータベース

高い満足度の背景 ― 何がうまくいったのか

AWS 展示ブーステーマ「Future of Agentic Commerce」

中島　佑樹

木下尚英 (Naohide Kinoshita)

堀内保大 (Yasuhiro Horiuchi) / @ka_shino_ki

西村忠己(Tadami Nishimura) / @tdmnishi

寺山怜志 (Satoshi Terayama)