2026 年 6 月 5 日、 Amazon Bedrock における新しいコンソールエクスペリエンスをお知らせします。このコンソールでは、高いパフォーマンスと信頼性、および強力なセキュリティを実現するために構築された Amazon Bedrock の次世代推論エンジン上で、最新の AI モデルを用いて、実験、イテレーション、スケールできます。このコンソールは、最新の GPT、Claude、およびオープンウェイトモデルをサポートする bedrock-mantle エンドポイント向けに最適化された、刷新されたワークフローを備えています。OpenAI Responses API、OpenAI Chat Completions API、および Anthropic Messages API に対応しています。 新しいコンソールエクスペリエンスにより、適切なモデルを簡単に見つけ、評価から本番に迅速に移行できます。 新しいモデルカード機能 – モデルカタログ全体を閲覧し、機能、モダリティサポート、コンテキストウィンドウ、適用可能なサービスクォータを 1 つの画面で並べて比較できます。ドキュメントや制限計算ツールからの情報をつなぎ合わせる必要がなくなります。 プロジェクトベースの作業 – 生成 AI アプリケーションの構築ライフサイクルを反映した 1 つの効率的なワークフローで、評価を実行したり、使用状況に関するインサイトを確認したりするプロジェクトを作成できます。 ライブドキュメント – プロジェクトに対応したライブドキュメントを使用できます。コードサンプル、SDK スニペット、API リファレンスは、プロジェクト変数が自動的に事前入力されます。コンソールからスニペットをアプリケーションに直接コピーして、変更せずに実行できます。 開始方法 Amazon Bedrock コンソール 内から [Bedrock Mantle コンソールを試す] を選択するか、または 新しいコンソールのリンク を使用して、新しいエクスペリエンスを試すことができます。 プロジェクトベースのダッシュボードでは、最近の日付範囲、最近使用したモデル、プロジェクトリストに基づいて、推論リクエストとエラーを表示できます。プロジェクトを作成し、モデルを割り当て、API キーを設定して、数分で推論リクエストの実行を開始できます。 新しいモデルカタログには、 bedrock-mantle エンジンでサポートされている最新の GPT、Claude、およびオープンウェイトモデルが表示されます。機能、トークン、料金、入出力、料金情報、および利用できるリージョンの詳細を確認できます。また、1 つのビューで最大 3 つのモデルを比較することもできます。 プロジェクトダッシュボードを選択すると、プロジェクトで使用されているモデル、トークン使用量の分布 (合計トークン使用量、1 分あたりのトークン使用量、1 分あたりの推論リクエスト、推論リクエストあたりのトークンなど) を確認できます。これは、モデルの選択、プロンプトの最適化、ワークロードの一貫性に関する意思決定に役立ちます。 最大 3 つのモデルを選択して評価を開始し、同じプロンプトに対する応答を並べて比較できます。 プロジェクトでアプリケーションを構築するには、 [開始方法] を選択します。既存のコードを移行したり、Anthropic または OpenAI SDK を使用して新しいアプリケーションを構築したり、AI コーディングアシスタントを Bedrock に接続したりできます。 [API & SDK] を選択し、SDK (Anthropic または OpenAI)、使用するプログラミング言語、認証方法を選択します。これらの設定をターミナルで実行して簡単にテストしたり、アプリケーション用に .env ファイルに保存したりするための環境コードが表示されます。また、サンプルコードスニペットを使用して最初のリクエストを送信し、セットアップを検証することもできます。 [クライアント] を選択すると、Claude Code、Cline、Codex、Cursor、OpenCode など、 bedrock-mantle エンジンに接続する AI コーディングエージェントのソースを選択できます。AI エージェントのインストール方法、AWS IAM 認証情報または Bedrock API キーの使用方法、環境変数の設定方法、各 AI エージェントからのリクエストを Bedrock を通じてルーティングする方法に関する手順が表示されます。 Anthropic および OpenAI 互換 API の詳細については、 [ライブ API ドキュメント] を選択します。Claude モデルの Messages API などの機能にアクセスするには [Anthropic API プロトコル] を、Responses API などの機能にアクセスするには [OpenAI API プロトコル] を選択できます。 例えば、OpenAI Response API を選択すると、指定されたモデル ID を持つモデルレスポンスが取得されます。これらの API リファレンスには、プロジェクトの選択されたモデル ID、リージョン、 bedrock-mantle エンドポイント URL、および API キーリファレンスが自動的に入力され、モデルや設定を変更すると、それに合わせて更新されます。 また、既存の Bedrock コンソールを選択して、エージェント、ナレッジベース、ガードレール、ファインチューニング、InvokeModel API、Converse API など、フルマネージド機能を管理し、 bedrock-runtime エンドポイントで実行することもできます。 今すぐご利用いただけます 新しいコンソールエクスペリエンスは、 bedrock-mantle エンドポイントが提供されているすべての AWS リージョン (米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ジャカルタ、ムンバイ、シドニー、東京)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、ストックホルム)、南米 (サンパウロ)) でご利用いただけます。今後のアップデートについては、 リージョンの詳細なリスト をご確認ください。 新しいコンソールエクスペリエンスを 新しい Amazon Bedrock コンソール でお試しいただき、 AWS re:Post for Amazon Bedrock 宛てに、または通常の AWS サポート担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も AWS の最新アップデートをお届けします。Amazon Bedrock に OpenAI のモデルが加わり、Anthropic や Meta など各社のモデルを共通のセキュリティ・ガバナンスのもとで選べる——ユースケースに最適なモデルを一つの基盤から選べる AWS の強みが、今週も光る内容です。 お昼休みの30分で最新情報を知れる場として「 もぐもぐAWS 」というウェビナーを実施中です。今週は6月9日「 Kiro Pro を組織で使うための最初の一歩 」、10日「 1人のトライアルから始める買い方のコツ (Amazon Quick)」、11日「 Amazon Bedrockで利用可能になったOpenAIモデルとCodexの最新速報をキャッチしよう 」とありますので是非チェックしてみてください。 AWS Summit Japan の開催（6 月 25 – 26 日）も近づいてまいりました！ 登録がまだの方は こちら から登録しぜひ来場ください！様々なコンテンツをご用意してお待ちしております！ それでは 6月 1 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 生成 AI を活用した SRE レジリエンスジャーニーを支援する次世代 AWS Resilience Hub のご紹介 」 アプリケーションの耐障害性（レジリエンス）を管理する AWS Resilience Hub が機能を強化し、新しいアプリケーションモデル、依存関係の検出・評価、生成 AI による障害モード分析、組織全体のレポート機能を備えた次世代版として一般提供が始まりました。SLO やマルチ AZ／マルチリージョンのディザスタリカバリ要件などを組み合わせる「レジリエンスポリシー」も導入されています。SRE（サイト信頼性エンジニア）や開発チームにとっては、システム・ユーザージャーニー・サービスという単位でアプリケーションをモデリングし、レジリエンスポリシーで要件の認識を揃えやすくなる点が便利です。AWS Organizations と連携すれば、単一の委任管理者アカウントから組織全体のレジリエンスを見渡せるため、アカウントごとにログインし直す手間がなくなります。クエリログの分析によって見えにくい依存関係を検出し、生成 AI が潜在的な障害モードを評価してくれるので、これまで気づきにくかった障害ポイントの把握にも役立ちます。既存ユーザーは移行 API を使って移行できます。 ブログ記事「 エージェンティック AI でグローバル規模の脆弱性検出を加速 」 Amazon が、脆弱性を悪用するコードのサンプルから検出ルールを自動生成するエージェンティック AI システム「RuleForge」を紹介しています。ルール生成は手動と比べて 336% 速くなり、専用の「ジャッジ」モデルで生成と評価を分離することで誤検知を 67% 削減したと説明されています。最終的な承認は引き続き人間が担当する仕組みです。ルール生成エージェントは AWS Fargate 上で Amazon Bedrock を使って動作し、世界規模のハニーポット「MadPot」などから得た脅威情報を活用しています。AWS を利用するお客様にとっての価値は、ワークロードを守るマネージドな保護がより速く更新され、深刻度の高い CVE（共通脆弱性識別子）をより広くカバーできるようになる点です。脆弱性が公開されてから防御が整うまでの時間差を縮める取り組みといえます。 ブログ記事「 AI の脅威からオープンソースを守るため 1,250 万ドルを AWS など複数社が拠出 」 AWS、Anthropic、Google、Microsoft、OpenAI の 5 社が、Linux Foundation を通じて総額 1,250 万ドル（うち AWS は 250 万ドル）を拠出すると発表しました。資金は Alpha Omega イニシアチブと OpenSSF を通じて提供され、AI によって生成・増幅されたセキュリティ脆弱性レポートの急増にオープンソースプロジェクトが対応できるよう支援します。背景には、AI が本物の脆弱性を見つける能力を高める一方で、メンテナーのもとに低品質な「AI スロップ」と呼ばれるレポートが大量に届くという課題があります。この取り組みによって、オープンソースのメンテナーが正当な脆弱性を素早く検証・修正しつつ、品質の低い報告を選り分けられるツールやリソースを利用しやすくなります。多くのソフトウェアが依存するオープンソースの基盤を守る活動として、AWS を含むクラウド利用者全体にとっても意味のある内容です。 ブログ記事「 AWS Transform Custom を使用した VB6 アプリケーションのモダナイズ 」 エージェンティック AI 機能を持つ AWS Transform custom を使って、レガシーな VB6（Visual Basic 6.0）アプリケーションを大規模に C# へモダナイズする手法を、水産物受注管理システムのサンプルを題材に解説しています。評価・定義・実行・レビューと反復という 4 段階のプロセスで、VB6 フォームを Blazor コンポーネントへ、ADO/DAO を Entity Framework Core へ変換する具体例が示されています。価値は、組織独自のビジネスルールやコーディング規約を保ったまま変換できる点にあります。一度作成した変換定義はチームで共有・再利用でき、数百規模の VB6 アプリケーションを同じ方針で体系的に移行できます。モダナイズ後は Linux や AWS Graviton 上で動作するため、インフラストラクチャのコスト削減につながる可能性もあります。手を動かしながら学べる中〜上級者向けの内容です。 ブログ記事「 Amazon Bedrock 上で OpenAI の GPT-5.5 モデル、GPT-5.4 モデル、Codex の使用を開始する 」 Amazon Bedrock で、OpenAI の GPT-5.5、GPT-5.4、およびコーディングエージェント Codex の一般提供が始まりました。各モデルは Responses API から呼び出し、推論はすべて Bedrock 上で処理されます。提供リージョンは、GPT-5.5 は米国東部(オハイオ)、GPT-5.4 は米国東部(オハイオ)・米国西部(オレゴン)・AWS GovCloud(米国西部)リージョンです。リージョンによって利用可能なモデルに差があるので利用時には ドキュメント を確認してください。トークン単位の従量課金で使え、シートライセンスや開発者ごとの契約は必要ありません。処理が選択した Bedrock リージョン内で完結するためデータレジデンシーの要件にも対応しやすく、Codex は Visual Studio Code や JetBrains、Xcode との IDE 統合を通じてコードの記述・リファクタリング・デバッグなどに活用できます。 ブログ記事「 AI 時代におけるセキュリティ体制の強化 」 AWS が提供する Security Health Improvement Program（SHIP）を紹介する記事です。SHIP は、サポートティアに関わらずすべての AWS のお客様が無償で利用でき、汎用的な推奨ではなくお客様の環境から取得した実際のデータをもとにセキュリティ体制を評価・改善するプログラムです。脅威検出や脆弱性管理、暗号化、シークレット管理など 10 のコアユースケースを対象にしています。ソリューションアーキテクトやテクニカルアカウントマネージャーが主導し、お客様の環境固有の改善点を洗い出します。Amazon Bedrock や Amazon Bedrock AgentCore で AI ワークロードを構築する前にセキュリティの土台を整えておきたい組織にとって、現状を把握し継続的に改善する仕組みづくりの足がかりになります。 イベント開催レポート ブログ記事「 9 社合同 AI-DLC Unicorn Gym 大阪 ── AI と開発した 3 日間で見えた、人間の仕事 」 2026 年 5 月 18 日〜20 日に AWS 大阪オフィスで開催された「合同 AI-DLC Unicorn Gym」の開催レポートです。9 社 10 チーム・計 75 名が参加し、AI を開発プロセスの中心に据える AI-DLC（AI 駆動開発ライフサイクル）を実践しました。Inception（要件定義）・Construction（実装）・Operations（運用）の 3 フェーズで進め、全 10 チームが 3 日間で動くアプリケーションのデモまで到達しています。特徴は、チーム全員で 1 画面を囲み AI と対話する「モブエラボレーション」「モブコンストラクション」という進め方です。コーディングエージェントを操作しながら、従来は数か月を見込んでいた要件定義から実装までを数日に圧縮できた様子が紹介されています。AI が「作業」を担い、人間が「意思決定」に集中するという役割の変化を、実際の開発体験を通じて知りたい方に参考になる内容です。 ブログ記事「 【開催報告】データから業務アクション、展開まで繋げる Amazon Quick ワークショップ in 大阪 」 2026 年 5 月 29 日に大阪オフィスで開催された「AWS Business Innovation Series – West Japan」第 2 回の開催報告です。西日本企業のデジタル変革を後押しするシリーズで、今回は 20 社 34 名が参加し、Amazon Quick を題材に座学・ハンズオン・ハッカソン・LT を通じて学びました。Amazon Quick は、Slack やメール、カレンダー、ファイルなど多様なデータソースに接続し、業務の文脈を理解したうえでアクションを実行できるツールです。当日は架空の人事課題を題材に、Chat から Space、構造化データの接続、HR Agent の作成までを段階的に体験し、ハッカソンでは自社課題に沿ったエージェントや導入提案資料を作成しました。普段コードを書かない参加者を含め、半日で実際に動くエージェントを作れた点が価値として示されています。 サービスアップデート OpenAI の GPT-5.5、GPT-5.4、Codex が Amazon Bedrock で一般提供開始 OpenAI の GPT-5.5、GPT-5.4、およびコーディング向けの Codex が、Amazon Bedrock で一般提供されました。GPT-5.5 はエージェント型コーディングやデータ分析、多段階の自律タスクに優れたモデルとされ、Codex は Codex アプリや Codex CLI、IDE 連携（Visual Studio Code、JetBrains、Xcode）から利用できます。ユーザーはこれらのモデルを AWS で既に使っているセキュリティ・ガバナンス・運用管理の仕組みのまま利用できます。料金は OpenAI の公式レートと同じで、利用量は既存の AWS のコミットメントにカウントされます。リージョンによって利用可能なモデルに差があるので利用時には ドキュメント を確認してください。 Amazon Bedrock が OpenAI・Anthropic 互換 API 向けに最適化した新コンソールを公開 Amazon Bedrock が、OpenAI Responses API・Chat Completions API、Anthropic Messages API（bedrock-mantle エンドポイント）向けに最適化した新しいコンソールを公開しました。最新の Claude、GPT、オープンウェイトモデルを、機能・対応モダリティ・コンテキストウィンドウ・クォータの観点で横並びに比較できます。ポイントはコードサンプルや SDK スニペット、API リファレンスが、選択したモデル ID・リージョン・エンドポイント URL・API キーの参照で自動的に埋め込まれ、設定変更に合わせて更新される点です。スニペットはそのまま実行でき、既存の OpenAI／Anthropic のクライアントライブラリを変えずに使えます。東京リージョンを含むアジアパシフィック（東京、ジャカルタ、ムンバイ、シドニー）、米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（フランクフルト、アイルランド、ロンドン、ミラノ、ストックホルム）、南米（サンパウロ）の各リージョンで利用できます。 Amazon Bedrock が OpenAI・Anthropic 互換 API 向けに Amazon CloudWatch メトリクスを追加 Amazon Bedrock の bedrock-mantle エンドポイント（OpenAI Responses／Chat Completions API、Anthropic Messages API に対応）の推論トラフィックを、Amazon CloudWatch メトリクスで監視できるようになりました。メトリクスは AWS/BedrockMantle ネームスペースに公開され、推論回数、入出力トークン合計、クライアントエラー数を、アカウント・プロジェクト・モデル・プロジェクトとモデルの組み合わせの各単位で確認できます。これにより、本番環境の推論にアラームを設定したりキャパシティを計画したりでき、利用量やコストをワークロードやチームごとに正しく割り当てられます。既存の OpenAI / Anthropic ベースのアプリケーションを最小限のコード変更で Bedrock 上に持ち込めるのも利点です。東京リージョンを含むアジアパシフィック（東京、ジャカルタ、ムンバイ、シドニー）、米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（フランクフルト、アイルランド、ロンドン、ミラノ、ストックホルム）、南米（サンパウロ）の各リージョンで利用できます。 Amazon Bedrock AgentCore Identity が AWS Secrets Manager による独自シークレットの持ち込みに対応 Amazon Bedrock AgentCore Identity の Credential Provider で、既存の AWS Secrets Manager のシークレット ARN を直接参照できるようになりました。従来のサービス管理型シークレットでは、作成時のタグ付与やカスタマー管理キー（CMK）による暗号化、独自のガバナンス制御を適用できませんでしたが、それが解消されます。ポイントは、CMK やタグ付け、自動ローテーション、リソースポリシーといった自社のガバナンス・コンプライアンス方針に沿ってシークレットを作成・管理できる点です。エージェントの実行時の動作を変えることなく、シークレットの作成・分類・管理の方法をコントロールできます。東京リージョンを含む 14 リージョンで利用できます。 Amazon Quick が MCP 接続の VPC 経由接続に対応 AI アシスタントの Amazon Quick が、プライベートにホストした MCP（Model Context Protocol）サーバーへ VPC（Amazon Virtual Private Cloud）経由で接続できるようになりました。これまでは公開インターネット経由の外部サーバーに限られていた MCP 連携が、プライベートネットワークにも広がります。社内ツールやカスタムデータソース向けに Amazon EC2、AWS Fargate、AWS AgentCore などで MCP サーバーを運用している組織が、それをインターネットに公開せずに Quick のワークフローへ安全に取り込める点がポイントです。MCP コネクター作成時に VPC 接続を選んでサーバーの URL を指定するだけで設定でき、その後はチームが自然言語で操作できます。Amazon Quick が利用可能なすべての AWS リージョンで利用可能です。 Amazon SageMaker HyperPod が EFA 専用ネットワークインターフェイスに対応 Amazon SageMaker HyperPod のクラスターインスタンスグループで、EFA（Elastic Fabric Adapter）専用のネットワークインターフェイスを設定できるようになりました。EFA はノード間の低レイテンシー・高スループット通信を担うデバイスで、従来は IP 通信用の ENA（Elastic Network Adapter）が併設されサブネット内の IP アドレスを消費していました。efa-only を指定すると ENA を付けず IP アドレスを消費しないため、同じサブネット内でより大規模なクラスターにスケールできます。全インターフェイスに IP 通信が不要な大規模分散トレーニングで特に有効です。設定は CreateCluster／UpdateCluster API の ClusterNetworkInterface で行います。SageMaker HyperPod がサポートされるすべての AWS リージョンで利用可能です。 Amazon SageMaker HyperPod が AI コーディングアシスタント向けのトラブルシューティングスキルを提供開始 Amazon SageMaker HyperPod が、AI コーディングアシスタント向けのトラブルシューティングスキルをオープンソースで提供開始しました。Claude Code、Cursor、Kiro と連携し、クラスターのヘルスチェック、ハードウェア・通信診断、ソフトウェアバージョンのドリフト検出、診断レポートの自動作成といった領域をカバーします。これまで GPU ハードウェア障害のデバッグや NCCL 通信障害の診断は、手動でノードに接続してログを解析する必要があり時間がかかっていました。新しいスキルは AWS Systems Manager 経由でノードから証拠を収集してパターンを分析し、実行可能な推奨事項を提示するため、自然言語でクラスターの問題を診断・解決できます。既存の HyperPod インフラを変更せずに使え、Slurm と Amazon EKS の両方のクラスターに対応します。 Amazon SageMaker AI が AI エージェントのモデルカスタマイズ向けにマルチターン強化学習を提供開始 Amazon SageMaker AI が、複数ステップのエージェントタスク向けにモデルを調整できる、サーバーレスのマルチターン強化学習を提供開始しました。これは教師ありファインチューニングや RLVR、RLAIF といった既存のモデルカスタマイズ機能に加わるもので、エージェントがタスク全体で行う一連の意思決定に報酬を与えて学習させます。Amazon Bedrock AgentCore Runtime や Amazon EKS、Amazon EC2、AWS Fargate などの実行環境と接続できます。ロールアウトの調整やトラジェクトリ（軌跡）の収集、学習、チェックポイント管理といったトレーニングループ全体を SageMaker AI が管理し、数週間かかっていたカスタムインフラの構築が不要になる点がポイントです。小型で低コストなモデルを特定のワークロード向けに特化させ、大型の汎用モデルと同等以上の精度を狙えます。完全サーバーレスで処理トークン分のみの課金です。提供は米国西部（オレゴン）リージョンと米国東部（バージニア北部）リージョンで、対応モデルはリージョンによって異なり、オレゴンは Qwen 3.6 27B・Nova Lite 2.0・GPT-OSS-20B・Gemma 31B、バージニア北部は Nova Lite 2.0・GPT-OSS-20B が対象です。 Amazon SageMaker Studio がモデルカスタマイズをすぐに使える状態で数秒でセットアップ可能に Amazon SageMaker Studio のクイックセットアップが、従来の 2 分超から 20 秒未満に短縮されました。新規に作成した Studio 環境にはサーバーレスのモデルカスタマイズ権限が自動構成され、AmazonSageMakerModelCustomizationCoreAccess という管理ポリシーが自動で作成・アタッチされます。このポリシーで、強化学習のカスタム報酬関数を使ったファインチューニング、モデル評価、SageMaker または Bedrock エンドポイントへのデプロイが行えます。IAM ロールやポリシーを手動で作る必要がなくなり、サインインからほぼ即座に実験を始められるのが利点です。 AWS Step Functions が AgentCore を活用したエージェント推論ステップを追加 AWS Step Functions に、AI エージェントの推論ステップをワークフローへ直接組み込める機能が追加されました。プレビュー中の Amazon Bedrock AgentCore Managed harness と統合し、モデル・ツール・動作を設定で宣言してエージェントを定義できます。ポイントは、ドキュメントの分類や非構造化フォームからの要素抽出といった推論タスクを自動化でき、複数のエージェントを並列・直列でワークフロー内の判断ポイントに配置できる点です。重要なアクションの前に人による承認ステップを挟むこともでき、実行履歴でエージェントの入出力・トークン使用量・実行時間を確認し、Amazon CloudWatch で個々の判断をトレース・監査できます。統合自体に追加料金はかかりませんが、ワークフロー実行には標準の Step Functions 料金が、モデル推論と関連 AgentCore リソースには標準の Amazon Bedrock・AgentCore 料金が適用されます。提供は米国東部（バージニア北部）、米国西部（オレゴン）、欧州（フランクフルト）、アジアパシフィック（シドニー）の各リージョンです。 Kiro トランスクリプトのエクスポート、ターミナルタイトル、モデル設定の永続化 Kiro CLI 2.6 では、作業の持ち運びと素早い再開に焦点を当てた機能が追加されました。/transcript save で会話全体を markdown・プレーンテキスト・JSON のいずれかで書き出せるようになり、チームへの共有やチケットへの添付ができます。/title でターミナルウィンドウにラベルを付けられるようになり、どのセッションがどこで動いているか把握しやすくなりました。さらに /model と /effort が選択を自動的に記憶するようになり、一度変更すれば以降のセッションにも引き継がれます。起動時に推論レベルを指定する –effort フラグ（low／medium／high／xhigh／max）も追加され、簡単な検索は高速に保ちつつ、複雑な作業には最初から深い推論を使えます。 リポジトリなしで開始、いつでもモード切替 Kiro web で、GitHub リポジトリを接続しなくてもセッションを開始できるようになりました。まずやりたいタスクを記述し、必要になったら後からリポジトリを接続する流れになります。また、Vibe セッションの途中でも Autonomous モードに切り替えられるようになり、開始時だけでなく最初のプロンプト送信後の任意のタイミングでエージェントに作業を引き渡せます。最初からやり直す必要はありません。セッションのメッセージには相対的なタイムスタンプが表示され、ホバーで絶対時刻も確認できるため、長時間のタスクでイベントの発生時刻を追いやすくなっています。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近燻製づくりにハマってます。

本ブログは “ Capacity-aware inference: Automatic instance fallback for SageMaker AI endpoints ” を翻訳したものです。 組織が本番環境で生成 AI ワークロードをスケールさせていく中で、信頼性の高い GPU コンピュートを確保することは、最も根強い運用上の課題の 1 つになっています。大規模言語モデル (LLM) やマルチモーダルアーキテクチャは特定のインスタンスタイプを必要とし、そのキャパシティが利用できない場合、エンドポイントは 1 件のリクエストも処理する前に失敗してしまいます。 Amazon SageMaker AI でリアルタイム推論エンドポイントを構築する際は、これまで作成時に単一のインスタンスタイプを指定する必要がありました。そのインスタンスタイプのキャパシティが不足していると、エンドポイントは実行状態に到達できません。設定を更新し、別のインスタンスタイプを選択して再試行する、というサイクルをプロビジョニングが成功するまで繰り返すことになります。 本日、Amazon SageMaker AI は、新規および既存の推論エンドポイント向けに キャパシティ対応インスタンスプール を導入します。優先順位付きのインスタンスタイプリストを定義しておけば、SageMaker AI はキャパシティが制約されているとき (作成時、スケールアウト時、スケールイン時) に、自動的にそのリストを順に処理します。エンドポイントは手動の介入なしで、利用可能な AI インフラ上にプロビジョニングされます。この機能は、シングルモデルエンドポイント、推論コンポーネントベースのエンドポイント、非同期推論エンドポイントで利用できます。 本記事では、インスタンスプールの仕組みと、新規エンドポイントの作成や既存エンドポイントの移行を含めた使い始め方について説明します。 これまでの課題 SageMaker AI 推論エンドポイント (リアルタイムまたは非同期) にモデルをデプロイするとき、単一のインスタンスタイプを指定します。そのインスタンスタイプの利用可能なキャパシティがない場合、エンドポイントの作成は失敗します。この制約は、エンドポイントのライフサイクルのあらゆる段階で現れます。 キャパシティ不足によるエンドポイント作成失敗： 希望するインスタンスタイプが利用できない場合、SageMaker AI は Insufficient Capacity エラーを返します。エンドポイントを稼働状態にするには代替のインスタンスタイプを手動で試行し続ける必要があり、結果がわかるまで毎回かなりの時間を要します。 Auto Scaling がフリートを拡張できない： スケールアウトイベントが発生し、インスタンスタイプにキャパシティが不足している場合、Auto Scaling は同じインスタンスタイプを際限なくリトライします。トラフィックが増加し続ける一方で、エンドポイントのサイズは現状のままです。 スケールダウンに優先順位の概念がない： 単一のインスタンスタイプでは、優先 (preferred) とフォールバック (fallback) のハードウェアという概念がありません。すべてのインスタンスが区別なく削除候補となります。 オブザーバビリティが集約されてしまい、対処につなげにくい： Amazon CloudWatch メトリクスはエンドポイントレベルで集約されます。レイテンシやキャパシティの問題を調査する際、メトリクスは「何かがおかしい」ことは示しても、「どのインスタンスタイプが原因か」までは示してくれません。 優先順位ベースのインスタンスプールの仕組み エンドポイント設定の中で、 instance pools と呼ばれるインスタンスタイプの優先順位付きリストを定義します。SageMaker AI はキャパシティが制約されたときに、自動的にそのリストを順番に処理します。 エンドポイントが立ち上がる： SageMaker AI は最初の選択肢のインスタンスタイプを試します。キャパシティが利用できない場合、ただちに 2 番目の選択肢、次に 3 番目の選択肢を試します。手動でリトライする必要はありません。エンドポイントは数分以内に、最初に利用可能な AI インフラ上で InService に到達します。 エンドポイントが稼働し続ける： Auto Scaling がトリガーされ、優先するインスタンスタイプが制約されている場合、SageMaker AI は優先順位リストの次に利用可能なインスタンスタイプでスケールアウトするため、トラフィックが流れ続けます。 フリートは優先ハードウェアに収束する傾向を持つ： スケールイン時、SageMaker AI は最も優先度の低い (フォールバック) インスタンスから先に削除します。その後のスケールアウトイベントでは、再び最も優先度の高いタイプから試行します。優先するハードウェアが利用可能になるにつれて、フリートは時間とともに自然にそちらへ戻り、手動の介入は必要ありません。 すべてを可視化できる： 既存のすべての CloudWatch メトリクスに InstanceType ディメンションが追加されているため、1 つのエンドポイント内のインスタンスタイプごとに、レイテンシ、スループット、GPU 使用率、インスタンス数を追跡できます。 詳細については、 Amazon SageMaker AI のドキュメント を参照し、 GitHub のサンプルノートブック を試してみてください。 各インスタンスタイプに適切なモデルを当てる フォールバック先のインスタンスタイプは、GPU メモリ、コンピュート性能、アーキテクチャが異なることがよくあります。高メモリのマルチ GPU インスタンス向けに最適化されたモデルが、より小さなシングル GPU のフォールバックで必ずしも動作するとは限りません。プールリスト内の各インスタンスタイプを、正しく構成されたモデルとマッチングさせる方法は 2 つあります。 オプション 1: 自分で最適化したモデルを持ち込む ターゲットのインスタンスタイプがすでに分かっている場合、それぞれに対してモデルアーティファクトを準備します。プライマリのハイエンドインスタンスでは、複数 GPU にわたるテンソル並列を使うかもしれません。中位のフォールバックでは、推論を高速化するために投機的デコーディング (speculative decoding) を適用することが考えられます。最も優先度の低いフォールバックでは、メモリ予算に収めるために INT4 量子化を使うかもしれません。 各構成について個別の SageMaker AI モデルを作成し、それぞれの InstancePools エントリ (Single Model Endpoint の場合) またはインスタンスタイプごとの Specifications (InferenceComponent ベースのエンドポイントの場合) で、 ModelNameOverride を使って参照します。SageMaker AI が優先度の低いプールにフォールバックすると、そのハードウェア用に準備したモデルがデプロイされます。 オプション 2: SageMaker AI 推論レコメンデーション機能を使う 各ハードウェアターゲットを手動で最適化するのが手間な場合は、 SageMaker AI 推論レコメンデーション によってハードウェア固有の構成を生成できます。ベースモデルを与えると、投機的デコーディングや量子化などの技術を使って、ターゲットのインスタンスタイプ全体にわたる最適化された構成を SageMaker AI が生成します。 レコメンデーションジョブはターゲットのインスタンスタイプごとに 1 つの結果を返します。各結果には AIRecommendationModelDetails のレスポンス内に ModelPackageArn と InferenceSpecificationName が含まれており、それぞれ特定のハードウェア向けの構成を示しています。両方のフィールドを使って結果ごとに 1 つの SageMaker AI モデルを作成し、対応するプールエントリで ModelNameOverride を介して参照します。これはオプション 1 と同じパターンですが、最適化作業はサービス側が処理します。 MODEL_PACKAGE_ARN = "arn:aws:sagemaker:us-west-2:123456789012:model-package/MyModelPkgGroup/1" # AIRecommendationModelDetails の両フィールドを使ってインスタンスタイプごとに 1 つのモデルを作成。 sm.create_model( ModelName="my-llm-for-p5", PrimaryContainer={ "ModelPackageName": MODEL_PACKAGE_ARN, "InferenceSpecificationName": "p5-48xlarge-optimized", }, ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerRole", ) sm.create_model( ModelName="my-llm-for-g6", PrimaryContainer={ "ModelPackageName": MODEL_PACKAGE_ARN, "InferenceSpecificationName": "g6-48xlarge-optimized", }, ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerRole", ) # その後、後述の「セットアップ」のとおり、プールエントリごとに ModelNameOverride で各モデルを参照する。 混在フリートでの Auto Scaling Auto Scaling は、作成時に定義したのと同じ優先順位ロジックに従います。スケールアウトはまず最も優先度の高いプールを試し、キャパシティが利用できない場合は次のプールにフォールバックします。スケールインは最も優先度の低いインスタンスから先に削除し、フリートが縮小しても優先するハードウェアを温存します。 加重スケーリングメトリクスを構築する フリートには異なるスループットキャパシティを持つインスタンスタイプが含まれているため、デフォルトの集約メトリクスは実際の使用状況を正しく表現できないことがあります。たとえば p5 インスタンスが 18 件の同時リクエストを処理し、g6 が 7 件処理しているとき、これらの生の数値を平均して 12.5 にしても、どちらのインスタンスタイプの負荷も正確には反映されません。 CloudWatch のメトリクス計算 (metric math) を使うと、タイプごとの使用率( per-type utilization ratios )に基づいた加重メトリクスを構築できます。各項はそのタイプで観測された並列実行数を最大キャパシティで割って、0.0 〜 1.0 の値を生成します。それらの比率を平均することで、 TargetValue と同じ 0.0 〜 1.0 のスケールでフリートレベルの使用シグナルが得られます。 TargetValue を 0.7 に設定すると、「フリート内のすべてのインスタンスタイプにわたる加重平均がキャパシティの 70% を超えたらスケールアウトする」という意味になります。 aas = boto3.client("application-autoscaling") aas.put_scaling_policy( PolicyName="weighted-utilization-scaling", ServiceNamespace="sagemaker", ResourceId="endpoint/my-heterog-endpoint/variant/primary", ScalableDimension="sagemaker:variant:DesiredInstanceCount", PolicyType="TargetTrackingScaling", TargetTrackingScalingPolicyConfiguration={ "TargetValue": 0.7, # 加重フリート使用率が 70% を超えたらスケールアウト "CustomizedMetricSpecification": { "Metrics": [ { "Id": "p5_concurrency", "MetricStat": { "Metric": { "Namespace": "AWS/SageMaker", "MetricName": "ConcurrentRequestsPerModel", "Dimensions": [ {"Name": "EndpointName", "Value": "my-heterog-endpoint"}, {"Name": "VariantName", "Value": "primary"}, {"Name": "InstanceType", "Value": "ml.p5.48xlarge"}, ], }, "Stat": "Average", }, "ReturnData": False, }, { "Id": "g6_concurrency", "MetricStat": { "Metric": { "Namespace": "AWS/SageMaker", "MetricName": "ConcurrentRequestsPerModel", "Dimensions": [ {"Name": "EndpointName", "Value": "my-heterog-endpoint"}, {"Name": "VariantName", "Value": "primary"}, {"Name": "InstanceType", "Value": "ml.g6.48xlarge"}, ], }, "Stat": "Average", }, "ReturnData": False, }, { "Id": "weighted_utilization", # タイプごとの使用率比 = 観測値 / 最大キャパシティ、それを平均する "Expression": "(p5_concurrency / 20 + g6_concurrency / 8) / 2", "ReturnData": True, }, ], }, }, ) この式の 20 と 8 は、各インスタンスタイプで測定された最大同時並列数です。この例では p5 は最大 20 リクエスト、g6 は最大 8 リクエストを処理します。これらの値は、負荷テストでお使いのモデルについて測定した最大値に置き換えてください。次の表は、トラフィックレベルごとにこのメトリクスがどう反応するかを示しています。 トラフィックレベル p5 リクエスト g6 リクエスト 加重使用率 アクション 低 5 2 (0.25 + 0.25) / 2 = 0.25 スケールイン 中 12 5 (0.60 + 0.63) / 2 = 0.61 維持 高 18 7 (0.90 + 0.88) / 2 = 0.89 スケールアウト ターゲット付近 14 6 (0.70 + 0.75) / 2 = 0.73 ターゲット付近 — 維持 注 : すべてのインスタンスタイプのスループットキャパシティが同程度のワークロードでは、既存のスケーリングポリシーを変更せずにそのまま使用できます。加重使用率メトリクスは、プールメンバーの GPU キャパシティが大きく異なる場合に最も価値を発揮します。 フリートをモニタリングする 既存のすべての CloudWatch メトリクスに InstanceType という新しいディメンションが追加されました。 ModelLatency 、 ConcurrentRequestsPerModel 、 GPUUtilization 、 InstanceCount 、 InvocationsPerInstance を、1 つのエンドポイント内のハードウェアタイプごとに分解できます。各インスタンスタイプを独立して追跡するダッシュボードやアラームを構築できます。 DescribeEndpoint はプールごとの現在のインスタンス数を返すため、フリートの構成を常に把握できます。 response = sm.describe_endpoint(EndpointName="my-heterog-endpoint") pools = response["ProductionVariants"][0]["InstancePools"] # 出力例: # [ # {"InstanceType": "ml.p5.48xlarge", "CurrentInstanceCount": 4}, # {"InstanceType": "ml.g6.48xlarge", "CurrentInstanceCount": 2}, # ] トラフィックルーティング インスタンスプールを使うエンドポイントでは、 ProductionVariant の RoutingConfig を設定することで、Least Outstanding Requests (LOR) ルーティングを有効化することを推奨します。LOR は受信リクエストごとに、モデルコピーあたり処理中のリクエストが最も少ないインスタンスへルーティングします。キャパシティの大きいインスタンスはリクエストを高速に処理するためキューが速やかに解消され、定常状態では処理中のリクエスト数が少なく保たれます。これにより、手動の重み付け設定なしで、キャパシティの大きいインスタンスは自然に多くのトラフィックを受け取るようになります。 "RoutingConfig": {"RoutingStrategy": "LEAST_OUTSTANDING_REQUESTS"} この設定がない場合、エンドポイントはデフォルトで RANDOM ルーティングを使用し、インスタンスの負荷に関係なくリクエストを均等に分散します。プールメンバー間でスループットキャパシティが大きく異なる場合、これは最適ではありません。詳細については、 ProductionVariant API リファレンスの RoutingConfig を参照してください。 更新とロールバック インスタンスプールは、Blue/Green デプロイ と ローリングデプロイ の両方をサポートしています。 Blue/Green デプロイ  では、トラフィックを切り替える前に、同じ優先順位ベースのフォールバックロジックを使って、新しい (グリーン) フリート全体をプロビジョニングします。ヘルスチェックがパスしたらトラフィックがカットオーバーされます。失敗した場合は自動ロールバックによってブルーフリートが保持され、エンドポイントは終始 InService を維持します。 ローリングデプロイ では、設定可能なバッチ (一度に 5〜50% のインスタンス) でフリートを更新します。Blue/Green 全体ほどの追加キャパシティを必要としないため、特に大規模モデルや需要の高い GPU インスタンスタイプで価値があります。SageMaker AI は新しい各バッチをプロビジョニングする際に、優先順位ベースのフォールバックロジックを適用します。ベーキング期間中に CloudWatch のアラームが発火した場合、トラフィックは自動的にロールバックされます。設定の詳細は Use rolling deployments を参照してください。 前提条件 開始する前に、以下を確認してください。 sagemaker:CreateEndpointConfig 、 sagemaker:CreateEndpoint 、 sagemaker:UpdateEndpoint の IAM 権限を持つ AWS アカウント Amazon S3 にアーティファクトを持つ少なくとも 1 つの SageMaker モデル Boto3 1.43.1 以降 (Python SDK での InstancePools サポートのため) (任意) ターゲットのインスタンスタイプごとに最適化された個別のモデルアーティファクト、または SageMaker AI 推論レコメンデーション からの ModelPackage SageMaker AI 推論エンドポイントのインスタンスプールサポートは、すべての商用 AWS リージョンで利用可能です。 AWS マネジメントコンソール 、AWS Command Line Interface (AWS CLI)、または AWS SDK から始められます。 インスタンスプールでエンドポイントを構成するワークフロー インスタンスプールを構成する方法は 2 つあります。Amazon SageMaker AI で新規エンドポイントを作成する場合と、既存のエンドポイントを移行する場合の 2 通りです。 新規エンドポイントを作成する場合、以下の図がワークフローを説明します。 インスタンスタイプを選択し、優先順位を割り当てる (1 が最高)。 各インスタンスタイプ向けに最適化したモデルを準備する、または SageMaker AI 推論レコメンデーションを実行して生成する。 優先順位を持つ InstancePools をリスト化したエンドポイント設定を作成する。 エンドポイントを作成する。SageMaker AI が自動的にキャパシティの確保を処理する。 新しい InstanceType ディメンションを使って、インスタンスタイプごとの CloudWatch モニタリングを設定する。 既存のエンドポイントを移行する場合、以下の図がワークフローを説明します。 新しいエンドポイント設定を作成する。 InstanceType を InstancePools に置き換え、現在のインスタンスタイプを Priority: 1 に保つ。 UpdateEndpoint を呼び出す。エンドポイントは Blue/Green 移行中も InService を維持する。 フォールバック先のインスタンスタイプ間でスループットキャパシティが大きく異なる場合は、加重使用率スケーリングメトリクスを任意で追加する。 セットアップ インスタンスプールの導入は、エンドポイント設定の 1 フィールドを変更するだけで済みます。 ProductionVariant の単一の InstanceType フィールドを InstancePools リストに置き換えてください。モデル、スケーリングポリシー、モニタリングダッシュボードは変更なしで動作し続けます。 既存エンドポイントの移行 移行前: 単一インスタンスタイプ import boto3 sm = boto3.client("sagemaker") sm.create_endpoint_config( EndpointConfigName="my-config", ProductionVariants=[{ "VariantName": "primary", "ModelName": "my-llm", "InitialInstanceCount": 2, "InstanceType": "ml.g6e.48xlarge", # 単一タイプ — キャパシティフォールバックなし }], ) 移行後: 優先順位付きインスタンスプール sm.create_endpoint_config( EndpointConfigName="my-config-v2", ProductionVariants=[{ "VariantName": "primary", "ModelName": "my-llm", "InitialInstanceCount": 2, "VariantInstanceProvisionTimeoutInSeconds": 1200, # 後述の注を参照 "InstancePools": [ {"InstanceType": "ml.g6e.48xlarge", "Priority": 1}, # 現在のタイプ {"InstanceType": "ml.g6.48xlarge", "Priority": 2}, # 同ファミリ、最初のフォールバック {"InstanceType": "ml.p4d.24xlarge", "Priority": 3}, # より広いフォールバック ], }], ) Blue/Green 移行中もエンドポイントは InService を維持します。 sm.update_endpoint( EndpointName="my-endpoint", EndpointConfigName="my-config-v2", ) 注 : VariantInstanceProvisionTimeoutInSeconds は、インスタンスプールサポートで導入された新しいフィールドです。プールからインスタンスを調達する全体の時間枠を設定します。SageMaker AI はこの時間枠の中で Insufficient Capacity エラーに対してリトライを続け、タイムアウト後に次のプールへ移ります。有効な範囲は 300 〜 3600 秒です。大規模 GPU インスタンスタイプでは、1200 秒が妥当な開始値です。このタイマーはインスタンス調達のみをカバーします。モデルダウンロードとコンテナ起動時間は、既存の ModelDataDownloadTimeoutInSeconds と ContainerStartupHealthCheckTimeoutInSeconds フィールドで個別に管理されます。インスタンスタイプごとに異なる最適化済みモデルをデプロイするには、任意のプールエントリに ModelNameOverride を追加します。モデル設定オプションは前のセクションで確認できます。 InferenceComponent ベースのエンドポイント sm.create_inference_component( InferenceComponentName="my-ic", EndpointName="my-heterogeneous-endpoint", VariantName="primary", Specifications=[ { "InstanceType": "ml.p5.48xlarge", "ModelName": "my-model-p5-optimized", "ComputeResourceRequirements": { "NumberOfAcceleratorDevicesRequired": 8, "MinMemoryRequiredInMb": 65536, }, }, { "InstanceType": "ml.g6.48xlarge", "ModelName": "my-model-g6-optimized", "ComputeResourceRequirements": { "NumberOfAcceleratorDevicesRequired": 8, "MinMemoryRequiredInMb": 32768, }, }, ], RuntimeConfig={"CopyCount": 4}, ) 非同期推論エンドポイント 非同期推論 エンドポイントでもインスタンスプールは同じように動作します。 InstancePools の定義と並べて CreateEndpointConfig の呼び出しに AsyncInferenceConfig ブロックを追加するだけで、優先順位ベースのプロビジョニングとフォールバックロジックがそのまま適用されます。これは、インスタンス数 0 までスケールダウンする非同期ワークロードで特に有用です。エンドポイントが再びスケールアップしてキューイングされたリクエストを処理する際、SageMaker AI はまず最も優先度の高い利用可能なプールを使ってプロビジョニングし、手動介入なしで耐障害性のあるコールドスタート挙動を提供します。 まとめ Amazon SageMaker AI Instance Pools は、推論エンドポイント向けにインスタンスタイプの優先順位付きリストを定義することを可能にし、SageMaker AI がその順序に基づいてキャパシティを自動的に管理します。 エンドポイント作成時、スケールアウト時、スケールイン時にわたって、SageMaker AI は優先するインスタンスタイプを順に処理するため、第 1 候補のハードウェアが利用できないときでもデプロイを手動でリトライする必要がありません。始め方は簡単です。エンドポイント設定の InstanceType を InstancePools に置き換えて UpdateEndpoint を呼び出します。既存のモデル、Auto Scaling ポリシー、モニタリングダッシュボードは大きな変更なしに動作し続けます。 インスタンスタイプごとの CloudWatch メトリクスと DescribeEndpoint からの詳細なプール数によって、どのインスタンスタイプがフリートを支えているかをリアルタイムに明確に把握できます。コスト最適化、GPU キャパシティ制約への対応、ゼロからコールドスタート可能な耐障害性の高い非同期パイプラインの構築など、どの目的であっても、インスタンスプールは運用負荷を抑えながら ML 推論をスムーズに動かし続けるための柔軟性と自動化を提供します。 この機能は本日から追加費用なしで利用可能です。実際にプロビジョニングされたインスタンスタイプに対しては、標準の単一タイプエンドポイントと同じ料率で課金されます。詳細については、 Amazon SageMaker AI のドキュメント と GitHub のサンプルノートブック を参照してください。 著者について Kareem Syed-Mohammed Kareem Syed-Mohammed は AWS のプロダクトマネージャーです。SageMaker HyperPod 上での生成 AI モデル開発とガバナンスの実現に注力しています。それ以前は Amazon QuickSight で組み込み分析と開発者エクスペリエンスをリードしました。QuickSight に加えて、AWS Marketplace と Amazon Retail でもプロダクトマネージャーを務めてきました。Kareem はコールセンター技術の開発者としてキャリアをスタートし、Expedia の Local Expert と広告、McKinsey の経営コンサルタントとしての経歴を持ちます。 Dmitry Soldatkin Dmitry Soldatkin は AWS の SageMaker Inference におけるスペシャリストソリューションアーキテクチャのワールドワイドリーダーです。エンタープライズ全体にわたる生成 AI および AI/ML ソリューションの設計、構築、最適化を支援する取り組みを率いています。彼の仕事は幅広い ML ユースケースに及び、生成 AI、ディープラーニング、大規模な ML のデプロイメントに重点を置いています。金融サービス、保険、通信などの業界の企業と協業してきました。Dmitry とは LinkedIn でつながることができます。 Johna Liu Johna Liu は Amazon SageMaker チームのソフトウェア開発エンジニアです。効率を高め新たな機能を可能にする AI/LLM 駆動のツールを構築し探求しています。仕事以外では、テニス、バスケットボール、野球を楽しんでいます。 Xu Deng Xu Deng は SageMaker チームのソフトウェアエンジニアリングマネージャーです。Amazon SageMaker 上でお客様の AI/ML 推論体験の構築と最適化を支援することに注力しています。余暇には旅行とスノーボードを楽しんでいます。 Mona Mona Mona Mona は現在、Amazon でシニア AI/ML スペシャリストソリューションアーキテクトとして勤務しています。以前は Google でリード生成 AI スペシャリストとして働いていました。『Natural Language Processing with AWS AI Services: Derive strategic insights from unstructured data with Amazon Textract and Amazon Comprehend』および『Google Cloud Certified Professional Machine Learning Study Guide』の 2 冊の著者であり、AI/ML とクラウド技術に関する 19 本のブログを執筆、CORD19 Neural Search に関する研究論文の共著者として、権威ある AAAI (Association for the Advancement of Artificial Intelligence) カンファレンスで Best Research Paper 賞を受賞しています。 翻訳は Solutions Architect 片山洋平 が担当しました。原文は こちら です。

本ブログは 2026年 5月 1日に公開された、 Security posture improvement in the AI era を翻訳したものです。 Anthropic が Claude Mythos Preview モデルを発表し、AWS およびその他の主要組織と共に Project Glasswing を立ち上げてから、まだ数週間しか経っていません。これにより、サイバーセキュリティの将来と、基盤モデルの能力が急速に向上することが組織にとって何を意味するのかについて、多くの議論が生まれています。 AWS CISO の Amy Herzog が Project Glasswing の 発表 で指摘したように、「AWS では、カスタムシリコンからテクノロジースタック全体にわたって、脅威が顕在化する前に防御を構築しています。セキュリティは私たちにとって単なる一フェーズではなく、継続的にすべての取り組みに組み込まれているものです。」 この詳細については、Amy が執筆した Building AI defenses at scale: Before the threats emerge をご覧ください。 サイバーセキュリティの将来についての議論は重要ですが、確実に言えることは、AI がテクノロジーやビジネス全般にもたらす急速な変化に、組織が迅速に対応できる必要があるということです。そして、セキュリティの基本が確立されていなければ、迅速な対応は不可能です。 セキュリティ基本対策のギャップ 基本的なセキュリティ要素がカバーされていると思い込んだり、一部を見落としたりすることは珍しくありません。アイデンティティ管理、脅威検出、脆弱性管理、データ保護、ネットワークセキュリティといった基本的なセキュリティのユースケースは、クラウド環境全体で一貫して実装されていないことがあります。AI がセキュリティの状況を変革しつつある中でも、強固なセキュリティの基礎は、規模や業種を問わず、すべての組織にとって引き続き不可欠です。 これらは、AI を導入するかどうかに関わらず重要なセキュリティの基本事項です。具体的には、一貫したパッチ適用、最小権限アクセスの徹底、ログ記録とモニタリングの有効化、保存データおよび転送中データの暗号化、そして定期的なセキュリティ設定のレビューが挙げられます。これらの基本事項が整っていれば、AI 駆動のツールを活用し、発見元を問わず新たに発見された脆弱性に対応できる体制が整います。 セキュリティの基本原則は普遍的なものですが、実際の環境への適用は、組織固有のコンテキストを理解した上で行うことが重要です。そのため、 AWS Well-Architected Framework など、適切な質問を行い環境に変更を加えるために活用できる多数の無償資料を提供しています。また、 Security Health Improvement Program (SHIP) のようなプログラムも提供しており、具体的なガイダンスと継続的な改善を通じてセキュリティ体制の向上を支援しています。 Security Health Improvement Program (SHIP) とは？ SHIP は、サポートティアに関わらず、すべての AWS のお客様が無償で利用できるプログラムです。SHIP は、以下を実現するための実績ある、データ主導の方法論を提供します。 AWS 環境のデータを使用して、現在のセキュリティ体制を評価する 10 のコアセキュリティユースケースにわたる具体的な改善機会を特定する 環境に合わせた優先度付きアクションプランを構築する 継続的なセキュリティ改善のための仕組みを確立する このプログラムは、AWS ソリューションアーキテクトとテクニカルアカウントマネージャーが主導し、パーソナライズされたレポートを通じてご案内し、お客様の環境に合わせた調査結果の解説と、優先順位付けされたアクションプランの策定をサポートします。 AI 時代における SHIP の重要性 Project Glasswing は重要な変化を浮き彫りにしています。AI を活用したツールが脆弱性の発見を加速させており、組織はこれまで以上に迅速に調査結果や変化する状況を評価・対応できる体制を整える必要があります。外部要因に加え、組織が基盤モデルのデプロイ、エージェント型ワークフローの構築、AI を活用したサービスの利用など、AI を採用するにあたって、セキュリティコントロールの実装方法も変えていく必要があります。強固なセキュリティ基盤こそが、自信を持って AI を採用するための土台となります。 SHIP がどのように役立つかを以下に示します。 基盤となるセキュリティのギャップに先手を打って対処する SHIP は、データ主導の手法を用いて、脅威検出、クラウドセキュリティ態勢管理、アプリケーションセキュリティテスト、構成管理、アクセスガバナンス、脆弱性管理、アプリケーション保護、ネットワークセキュリティ、暗号化、シークレット管理という 10 のコアセキュリティユースケースにわたる改善・最適化の機会を特定します。このプログラムには、現在のセキュリティ態勢に関連する重要なセキュリティ上の問題を特定するための SHIP アセスメントが含まれており、チームがお客様の環境に合わせた優先度付きの改善ロードマップを構築できるようになります。 AI ワークロードに必要なセキュリティベースラインを確立する Amazon Bedrock に最初のモデルをデプロイする前、あるいは Amazon Bedrock AgentCore でエージェント型ワークフローを構築する前に、基盤となるインフラストラクチャがセキュリティのベストプラクティスに従っていることを確認する必要があります。SHIP は、汎用的なセキュリティ推奨事項ではなく、お客様の環境から取得した実際のデータを使用して、具体的な指針を提供します。AI を活用した脆弱性発見ツールがより広く普及しつつある現在、これは特に重要です。強固なベースラインを持つ組織は、新たな発見事項に対して迅速かつ効果的に対応できるようになります。 継続的なセキュリティ改善のための仕組みを構築する AI の能力が進化するにつれ、組織はセキュリティ体制を継続的に評価・強化するための再現可能なプロセスを持つことで恩恵を受けられます。SHIP は、チームが継続的に評価、優先順位付け、改善を行うための方法論とメカニズムを確立します。この運用能力を構築することで、組織の適応力が強化され、業界全体のレジリエンス向上にも貢献できます。サイバーセキュリティコミュニティが AI を防御戦略に統合していく中で、SHIP は基本的なベストプラクティスの維持を支援し、これらのイノベーションを効果的かつ自信を持って採用できるようにします。 始め方はシンプルです SHIP は現在、すべての AWS のお客様に無料でご利用いただけます。始め方は以下の通りです。 AWS アカウントチームにご相談ください。 SHIP エンゲージメントのスケジュール調整についてご相談いただくか、 SHIP ページ から直接リクエストしてください。 SHIP Activation Day に参加してください。 AWS では定期的にハンズオンワークショップを開催しており、AWS ソリューションアーキテクトと共に SHIP アセスメントを実施し、改善計画の策定を開始できます。 具体的なガイダンスを参照してください。 今すぐ活用できるドキュメント、リファレンスアーキテクチャ、および実装ガイドについては、 AWS Well-Architected Framework – Security Lens をご参照ください。 次のステップを共に踏み出しましょう AWS は、Project Glasswing への参加から、インフラストラクチャのあらゆる層に組み込まれたセキュリティに至るまで、最もセキュアなクラウドであり続けることに取り組んでいます。セキュリティは共有責任であり、SHIP のようなプログラムは、お客様がセキュリティの基盤を強化するためのツール、ガイダンス、サポートを提供します。これにより、お客様はどのような状況においても自信を持って構築できるようになります。 セキュリティ体制を強化する準備はできていますか？ SHIP エンゲージメントのスケジュールを組むには AWS アカウントチームにお問い合わせいただくか、詳細については SHIP リソースページ をご覧ください。 Celeste Bishop Celeste is a Senior Security Specialist at AWS, based in Austin, Texas. Over the past five years, she has held a range of security-focused roles spanning field and product marketing, developer relations, and executive engagement. She partners closely with customers, security leaders, and field teams to help organizations operate securely in the cloud. Celeste holds a Bachelor’s in Economics from the University of Texas at Austin. 翻訳は Solutions Architect の 日吉 康仁、松崎 博昭 が担当しました。

ウェブアプリケーションおよびモバイルアプリのデベロッパーと連携するデベロッパーアドボケートとして、私は、リージョンレベルのサービスが万が一中断した場合に備えて、一貫したユーザー認証を維持する必要性について、しばしば耳にしてきました。エージェンティック AI、マイクロサービス、オートメーション、サービスアカウントの利用拡大に伴って、マシン間認証についての同様のニーズが高まっています。本日、Amazon Cognito の 2 つの重要なアップデートについてお知らせします。1 つは回復力を高めるための マルチリージョンレプリケーション 、もう 1 つは暗号化コントロールをより詳細に制御できる カスタマーマネージドキー のサポートです。 多くのアプリケーションは、ユーザー認証およびマシン間認証の処理やユーザープロファイルの管理に Amazon Cognito を利用しています。高可用性を実現するために構築するには、異なる AWS リージョン間でデータの一貫性を実現することが不可欠ですが、これまでその一貫性を実現するには大きな課題が伴っていました。エンジニアリングチームは、リージョン間で設定を同期するために、カスタムレプリケーションソリューションの構築と維持に多大な時間を費やしていました。リージョン間でのユーザーデータの手動エクスポートとインポートは、潜在的なデータ漏えいによるセキュリティリスクを生み出し、データの不整合を引き起こす可能性をはらんでいました。リージョンレベルの移行時には、エンドユーザーは、強制パスワードリセットや再認証などの中断を経験していました。マシン間通信では、チームは、セカンダリリージョンで新しいアプリケーションクライアントを作成する必要があり、そのためにはアプリケーションを再設定し、新しいリージョンレベルの発行者によって発行されたアクセストークンを受け入れるように OAuth で保護されたリソースを更新する必要がありました。これらの課題により、リージョン間で中断のない運用を維持することが困難となっていました。 マルチリージョンレプリケーションを使用することで、Amazon Cognito は、任意のセカンダリ AWS リージョンにユーザーデータとマシンシークレットの同期コピーを自動的に維持します。レプリケーションは、プライマリリージョンからセカンダリリージョンへの一方向で行われます。これには、ユーザープロファイル、認証情報、およびプール設定が含まれます。セカンダリリージョンは読み取り専用モードで動作し、認証機能の維持に重点を置きます。既存のセッションは中断されずに継続されます。 トラフィックをセカンダリリージョンにルーティングする必要がある場合、既存のユーザーは、中断なく既存の認証情報を使用してサインインを継続でき、現在サインインしているユーザーは、両方のリージョンがどちらのリージョンによって発行されたアクセストークンも認識するため、認証された状態が維持されます。マルチリージョンレプリケーションは、ソーシャルプロバイダー (Amazon、Google、Apple、Facebook) を通じたフェデレーションサインイン、Security Assertion Markup Language (SAML) と OpenID Connect (OIDC) の統合、API 認証フローなど、すべての認証方法をサポートします。このアプローチにより、顧客向けアプリケーションとバックエンドサービスにおけるマシン間通信の両方で可用性が維持されます。認証は中断なく継続されますが、フェイルオーバー中は新規ユーザー登録やプロファイル更新などの操作は利用できません。 マルチリージョンレプリケーションを設定する前に、 AWS Key Management Service (AWS KMS) に保存されているマルチリージョンカスタマーマネージドキーを設定し、保管中のユーザーデータを暗号化する必要があります。これらのキーは、リージョン間で一貫した暗号化を提供すると同時に、暗号化戦略を制御できるようにします。 実際の動作 us-west-2 (オレゴン) リージョンにある既存の Cognito ユーザープールを使用してこのデモを開始します。 us-east-1 (バージニア北部) へのレプリケーションを設定したいと考えています。また、これらの 2 つのリージョンにレプリケートされたカスタマーマネージドキーもあります。 マルチリージョンレプリケーションの設定は、わずか 3 つのステップで完了します。 AWS マネジメントコンソール は、暗号化のためのカスタムキーの設定、マルチリージョン OIDC エンドポイントの設定、レプリケーション自体の設定というステップを通じてガイドしてくれます。 まず、保管中のデータを暗号化するためにカスタム AWS KMS キーをセットアップします。 作成したカスタムキーを選択します。また、Amazon Cognito がキーにアクセスして使用できるように、キーポリシーを更新します。コンソールには、キーポリシーに追加すべき正しい IAM ポリシーステートメントが表示されます。 カスタムキーが選択され、正しく設定されたことをコンソールが確認します。 次に、コンソールの指示に従って OIDC 発行者タイプを設定します。 [ステップ 2 – オプション] で、 [設定] を選択します。 これらの新しいエンドポイントを使用してクライアントアプリケーションを更新します。これは必須の変更であり、サーバー側のアプリケーションの再デプロイと、App Store および Google Play におけるモバイルアプリの更新申請が必要となります。エンドポイントを更新しないと、古いエンドポイントに対するリクエストが正しくルーティングされなくなるため、ユーザーに障害が発生します。 次の画面で、 [更新済み] を選択します。新しい URL をメモしておきます。変更内容を確認し、 [発行者タイプを変更] を選択します。 最後に、レプリケーションのターゲットリージョンを選択します。カスタム暗号化キーがレプリケートされているリージョンのみを選択できます。ターゲットリージョンを選択したら、 [作成] を選択します。 サービスがレプリケーションのために準備します。必要な時間は、ユーザープール内のデータ量によって異なります。 レプリケートされたユーザープールの準備が整ったら、手動で [アクティブ化] します。 レプリケーションステータスは [アクティブ] になります。これで、トラフィックをレプリカにルーティングする準備が整いました。 追加の設定 コンソールは、計画する必要のある追加の設定を追跡するのに役立ちます。また、 カスタム認証フロー や SMS または E メール通知のために Lambda 関数 を使用する場合は、新しいリージョンでこれらのリソースをデプロイして設定する必要があります。 同様に、認証トラフィックをターゲットリージョンにルーティングする前に、ログストリーミングや AWS WAF の設定をそのターゲットリージョンで手動設定する必要があります。 ヘルスチェックとフェイルオーバー プライマリリージョンレベルとセカンダリリージョンレベルのエンドポイントは、常にアクティブな状態を維持し、いつでもトラフィックを処理できる準備が整っています。システムの正常性をモニタリングし、フェイルオーバーを管理するには、アプリケーション固有の要件とセキュリティ体制に整合的な戦略を設計する必要があります。ヘルスチェックを実装することで、プライマリリージョンの認証サービスのステータスをモニタリングし、フェイルオーバーを開始する条件を定義できます。これらのチェックでは、エラー率、レイテンシーパターン、特定のサービスアラートなどを確認できます。 モニタリングシステムがフェイルオーバーの条件を満たす問題を検出した場合、DNS 更新を通じてトラフィックをセカンダリリージョンにリダイレクトできます。このアプローチにより、セキュリティを維持しながら、フェイルオーバープロセスを制御できます。ピーク時以外の時間帯に、トラフィックの一部をリダイレクトし、セカンダリリージョンで認証が想定どおりに機能し続けることを検証することで、フェイルオーバー戦略をテストすることをお勧めします。 カスタムドメインでマネージドログインとフェデレーションを使用する場合、 Amazon Route 53 ヘルスチェック ID を指定することで、組み込みのトラフィックルーティング機能も利用できます。 料金と利用可能なリージョン マルチリージョンレプリケーションは、Essentials および Plus 階層をご利用の Amazon Cognito のお客様向けのアドオン機能として、本日よりご利用いただけます。ユーザー認証では、アドオン料金は、Essentials 階層のお客様の場合、レプリカリージョンごとに月間アクティブユーザーあたり 0.0045 USD、Plus 階層のお客様の場合、レプリカリージョンごとに月間アクティブユーザーあたり 0.006 USD です。マシン間 (M2M) 認証では、アドオンについては、正常に発行されたトークンの標準ボリュームベース料金に 30% が加算されます。料金に関する詳細については、 「Amazon Cognito の料金」をご覧ください 。 マルチリージョンレプリケーションは現在、米国東部 (オハイオ、バージニア北部)、米国西部 (カリフォルニア北部、オレゴン)、アジアパシフィック(ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、パリ、ストックホルム)、南米 (サンパウロ) のリージョンでご利用いただけます。 これらのリージョンはいずれも、レプリケーション元またはレプリケーション先として使用できます。 Essentials および Plus 階層では、カスタマーマネージドキーのサポートをご利用いただけます。次のリージョンでご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (北カリフォルニア、オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ムンバイ、ニュージーランド、大阪、ソウル、シンガポール、シドニー、タイ、東京)、カナダ (中部)、カナダ西部 (カルガリー)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、スペイン、ストックホルム、チューリッヒ)、イスラエル (テルアビブ)、メキシコ (中部)、南米 (サンパウロ)、および AWS GovCloud (米国東部、米国西部) お客様との会話から、リージョンレベルのインシデントの発生時であっても、セキュリティ要件を満たしながら事業継続性を維持することが優先事項であることがわかりました。マルチリージョンレプリケーションにより、複雑なレプリケーションロジックを自社で管理することなく、より堅牢なアプリケーションを構築できます。ユーザーデータと設定の自動同期により、セキュリティを維持しながら運用上のオーバーヘッドを削減できます。 規制が厳しい業界のお客様向けに、カスタマーマネージドキーの新たなサポートは、データ暗号化に対する追加のコントロールを提供します。独自の暗号化キーを使用して保管中のユーザーデータを保護できるようになりました。これは、ヘルスケアや金融サービスなどの業界における規制要件に対応するのに役立ちます。 マルチリージョンレプリケーションとカスタマーマネージドキー暗号化の使用を開始するには、 Amazon Cognito コンソール にアクセスしてください。また、詳細なセットアップ手順については、 ドキュメント をご覧ください。この機能を活用してアプリケーションアーキテクチャを強化する方法について、ぜひお聞かせください。 – seb 原文は こちら です。

「What’s Next with AWS 2026」でプレビューしたとおり 、 Amazon Bedrock における OpenAI の GPT-5.5 モデル、GPT-5.4 モデル、および Codex の一般提供の開始をお知らせします。これにより、フロンティアモデルとソフトウェア開発のためのコーディングエージェントにアクセスできるようになります。 OpenAI によると、GPT-5.5 モデルと GPT-5.4 モデルは、コーディング、推論、エージェンティックワークフロー、複雑かつ専門的な業務で優れたパフォーマンスを発揮します。極めて負荷の高いワークロードでは GPT-5.5 を、料金パフォーマンスを重視する場合は GPT-5.4 を利用できます。これらのモデルは、高いパフォーマンスと信頼性、および強力なセキュリティを実現するために構築された Amazon Bedrock の次世代推論エンジン上で、 Responses API を通じて呼び出すことができます。 Codex は、AI を利用したソフトウェア開発のための OpenAI コーディングエージェントです。OpenAI によると、毎週 400 万を超えるデベロッパーが Codex を使用して、大規模なコードベース全体で、コードの記述、リファクタリング、デバッグ、テスト、検証を行っています。GPT-5.5 を利用する推論を備えた Codex は、複雑で長期的なデベロッパーワークフロー向けに最適化された、新しいクラスのインテリジェンスを提供します。Codex アプリ、Codex CLI、および Visual Studio Code、JetBrains、Xcode との IDE 統合を利用できます。すべてのモデル推論は、Amazon Bedrock 上で Responses API を通じてルーティングされます。 データレジデンシー要件を満たす必要があるお客様の場合、すべての処理は、選択した Bedrock リージョン内で行われます。トークン単位でのお支払いとなり、シートライセンスやデベロッパーごとの契約は不要です。 Bedrock 上で GPT-5.5 モデルおよび GPT-5.4 モデルが機能している様子 OpenAI SDK や curl などのコマンドラインツールを通じて、OpenAI Responses API で bedrock-mantle エンドポイントを呼び出すことで、プログラムを使用してモデルにアクセスできます。 まずは OpenAI SDK for Python から始めましょう。OpenAI SDK をインストールします。 pip install -U openai 認証用の環境変数を設定します。 export OPENAI_BASE_URL="https://bedrock-mantle.us-east-2.api.aws/openai/v1" export OPENAI_API_KEY="<BEDROCK_API_KEY>" export BEDROCK_OPENAI_MODEL_ID="openai.gpt-5.5" Bedrock 上で GPT-5.5 モデルを呼び出すためのサンプル Python コードを次に示します: import os from openai import OpenAI client = OpenAI( base_url=os.environ["OPENAI_BASE_URL"], api_key=os.environ["OPENAI_API_KEY"], ) response = client.responses.create( model=os.environ["BEDROCK_OPENAI_MODEL_ID"], input=[ { "role": "developer", "content": "You are a software engineer with excellent AWS cloud knowledge.Be concise and practical.", }, { "role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions.", }, ], reasoning={"effort": "medium"}, text={"verbosity": "low"}, ) print(response.output_text) curl を使用して、モデルのエンドポイントを直接呼び出すことができます。 curl "$OPENAI_BASE_URL/responses" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -d '{ "model": "openai.gpt-5.5", "input": [ { "role": "developer", "content": "You are a software engineer with excellent AWS cloud knowledge." }, { "role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions." } ], "reasoning": {"effort": "medium"}, "text": {"verbosity": "low"} }' モデルマネージドの複数ターン状態を使用したい場合、ホスト型ツール、関数ツール、もしくはよりリッチなツールオーケストレーションが必要な場合、またはバックグラウンドもしくは長時間の処理を実行する場合は、 Responses API を使用できます。詳細については、 OpenAI Cookbook Responses の例 にアクセスしてください。 Amazon Bedrock 上での GPT-5.5 と OpenAI Codex の使用 Codex CLI、Codex アプリ、または Codex VS Code 拡張機能をダウンロードして、モデル推論のために Bedrock の利用を開始できます。Codex は、 Amazon Bedrock API キー または AWS SDK 認証情報チェーンという 2 つの Bedrock 認証方法をサポートしています。 AWS_BEARER_TOKEN_BEDROCK を設定すると、Codex はまずそれを使用します。設定しない場合、Codex は AWS SDK の認証情報チェーンにフォールバックします。 Codex が読み取る環境変数に AWS_BEARER_TOKEN_BEDROCK を設定します: export AWS_BEARER_TOKEN_BEDROCK=<your-bedrock-api-key> その後、希望するリージョンを設定し、 ~/.codex/config.toml でモデル ID を openai.gpt-5.5 に設定します。これは Bedrock API キー認証に必要です。また、 openai.gpt-5.4 、 openai.gpt-oss-120b 、または openai.gpt-oss-20b を選択することもできます。デスクトップアプリまたは VS Code 拡張機能の場合は、アプリが必要とする環境変数を ~/.codex/.env に記述します。 model = "openai.gpt-5.5" model_provider = "amazon-bedrock" [model_providers.amazon-bedrock.aws] region = "us-east-2" ~/.codex/config.toml または ~/.codex/.env を変更した後は、デスクトップアプリまたは VS Code 拡張機能を再起動します。Codex CLI では、次のような /status タブが表示されるはずです: Codex アプリでは、Amazon Bedrock 推論を通じて GPT-5.5 モデルを使用できます。 知っておくべきこと 役立つと思われる重要な技術的詳細をいくつかご紹介します。 モデルレイテンシー : OpenAI のモデル情報では、GPT-5.5 は高速、GPT-5.4 は中速とされていますが、ユーザーが感じるレイテンシーは、推論の effort、出力の長さ、ツール呼び出し、バックグラウンドモード、リージョン、クォータ、スロットリング、プロンプトサイズ、キャッシュヒットによって異なります。GPT-5.5 は medium の effort で起動してください。GPT-5.4 は、デフォルトの none に依拠するのではなく、effort を明示的に設定して起動してください。 スケーリングとキャパシティ : Bedrock の新しい推論エンジンは、さまざまなモデル全体でキャパシティを迅速にプロビジョニングして提供するように設計されています。リクエストを受け入れる際には、定常状態のワークロードを稼働させ続けることを優先し、需要の変化に応じて使用量とキャパシティを迅速に増やします。需要が高い期間中は、リクエストは拒否されるのではなく、キューに入れられます。 今すぐご利用いただけます Amazon Bedrock 上で OpenAI GPT モデルと Codex が本日よりご利用いただけます: GPT-5.5 モデルは米国東部 (オハイオ) リージョンで、GPT-5.4 モデルは米国東部 (オハイオ) リージョンと米国西部 (オレゴン) リージョンでご利用いただけます。今後のアップデートについては、 リージョンの詳細なリスト をご確認ください。詳細については、「 Amazon Bedrock での OpenAI 」ページと「 Amazon Bedrock の料金 」ページにアクセスしてください。 Amazon Bedrock 上で GPT-5.5 モデル、GPT-5.4 モデル、Codex をぜひ今すぐお試しいただき、 AWS re:Post for Amazon Bedrock 宛てに、または通常の AWS サポート担当者を通じて、フィードバックをお寄せください。 – Channy 2026年6月1日更新 – GPTモデルは現在、Amazon Bedrock上でのみResponses APIをサポートしており、コンソールサポートは近日中に提供予定です。 2026年6月3日更新 – Amazon Bedrockは、 AWS GovCloud（米国西部）リージョンにおいて 、OpenAIのGPT-5.4をサポートするようになりました。 原文は こちら です。

本ブログは 2026 年 4 月 24 日に公開された AWS Blog “ Protecting your secrets from tomorrow’s quantum risks ” を翻訳したものです。 AWS のポスト量子暗号 (PQC) 移行計画 で説明したとおり、 harvest now, decrypt later (今すぐ収集し、後で復号する) 攻撃 (HNDL) のリスクへの対処は、ポスト量子移行計画の重要な部分です。量子耐性のある機密性をサポートするためにワークロードのクライアント側をアップグレードすることは、 PQC 責任共有モデル においてお客様側が担う重要な側面です。PQC アップグレードの計画と実行のタイムラインは、リージョンや業界によって異なり、お客様自身のビジネスリスクプロファイルに依存します。詳細については、AWS の PQC に関するよくある質問 を参照してください。 AWS Secrets Manager は SSL/TLS を使用して AWS リソースと通信し、現在すべての AWS リージョンで TLS 1.2 と 1.3 をサポートしています。この機能をサポートするクライアントに対しては、ハイブリッドポスト量子鍵交換を使用した TLS 1.3 をサポートしています。 ハイブリッドポスト量子 アプローチは、従来の暗号 (X25519 など) とポスト量子アルゴリズム (ML-KEM) を組み合わせて TLS 接続を確立することで、現在の古典的な攻撃と将来の量子コンピュータの脅威の両方からシークレットを保護します。ワークロードが Secrets Manager にどのようにアクセスする場合でも、HNDL によるシークレットへのリスクに対処するために必要なのは、このクライアント側のソフトウェアアップグレードだけです。保管中のシークレットは、 AWS Key Management Service (AWS KMS) が管理するキーを使用して、すでに暗号化されています。適切に実装された対称暗号は量子耐性があると考えられていますが、非対称暗号は量子の脅威に直面しています。詳細については、 AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified をご覧ください。 クライアント側のアップグレードにおける開発者の負担を軽減するため、以下の Secrets Manager クライアントが、Secrets Manager への接続を開始する際にポスト量子 TLS を有効化して優先するようになりました。対象となるのは、 Secrets Manager Agent ( v2.0.0 以降)、 AWS Lambda 拡張機能 (v19 以降)、 Secrets Manager CSI Driver ( v2.0.0 以降) です。SDK ベースのクライアントの場合、ハイブリッドポスト量子鍵交換はサポートされている AWS SDK で利用できます。有効化の要件は、言語、バージョン、オペレーティングシステムによって異なります。お使いの SDK クライアントについては、以下の表を参照してください。 このリリースは、システムをポスト量子暗号に移行し、お客様の移行も容易にするという AWS の継続的な取り組みの一環です。詳細については、 ポスト量子暗号 を参照してください。 クライアントのハイブリッドポスト量子鍵交換の要件 以下の表は、各クライアントの動作をまとめたものです。クライアントがハイブリッドポスト量子鍵交換をサポートするようにアップグレードされると、Secrets Manager のサービスエンドポイントは TLS ハンドシェイク中に自動的にこれを選択します。Secrets Manager API を呼び出す際にワークロードがハイブリッドポスト量子鍵交換を使用し始めるために必要なのは、表に記載されているバージョンへのアップグレードだけです。 クライアント 要件 Secrets Manager Agent TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( v2.0.0 以降 ) AWS Lambda 拡張機能 TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます (バージョン 19 以降) Secrets Manager CSI Driver TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( v2.0.0 以降) AWS SDK for Rust TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( 2025 年 8 月 29 日以降のリリース ) AWS SDK for Go TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( Go v1.24 以降 ) AWS SDK for Node.js TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( Node.js v22.20 および v24.9.0 以降 ) AWS SDK for Kotlin Linux で TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます (v1.5.78 以降) AWS SDK for Python AWS SDK for Python (boto3) は、TLS に OS が提供する OpenSSL を使用します TLS でのハイブリッドポスト量子鍵交換には、 OpenSSL 3.5 以降がインストールされた システムでの実行が必要です AWS SDK for Java v2 AWS SDK for Java v2 では、 postQuantumTlsEnabled を使用して設定する場合に、PQ TLS をサポートする AWS CRT HTTP クライアントが必要です Secrets Manager キャッシュクライアント Secrets Manager キャッシュライブラリは AWS SDK 上に構築されており、その TLS 動作を継承します。Java に関する注意: TLS でのハイブリッドポスト量子鍵交換を有効にするには、 JDBC ドライバーフラグ と Java キャッシュフラグ を設定する必要があります Secrets Manager Agent、Lambda 拡張機能、または CSI Driver を使用している場合は、TLS でのハイブリッドポスト量子鍵交換をデフォルトとして使用するために、記載されているバージョンにアップグレードしてください。表に記載されているバージョンの AWS SDK for Rust、Go、または Node.js を使用しているお客様は、すでにアップグレード済みであり、追加のアクションは必要ありません。SDK が API コールに対してハイブリッドポスト量子鍵交換を選択します。AWS SDK for Python を使用しているお客様の場合、TLS でのハイブリッドポスト量子鍵交換には、ホストシステムに OpenSSL 3.5 以降が存在する必要があります。これを確認して有効化する方法については、 AWS Secrets Manager ドキュメント を参照してください。AWS SDK for Java v2 を使用しているお客様の場合、TLS でのハイブリッドポスト量子鍵交換には AWS CRT HTTP クライアントの使用が必要です。これを有効にするには、CRT クライアントで postQuantumTlsEnabled(true) を設定する必要があります。 クライアントのバージョンが表に記載されている要件を満たした後は、接続が実際にハイブリッドポスト量子鍵交換を使用していることを検証できます。 接続がハイブリッドポスト量子鍵交換を使用していることを検証する方法 ML-KEM を使用したハイブリッドポスト量子鍵交換が Secrets Manager クライアントでデフォルトで有効になったため (前述の表を参照)、ほとんどのお客様にとって、正しい動作の検証やリグレッションの検出のための継続的なモニタリングは不要です。ただし、セキュリティチームやコンプライアンス責任者は、Secrets Manager API コールがハイブリッド鍵交換をネゴシエートしていることを確認したい場合があります。サーバー側では、 AWS CloudTrail を使用して TLS でのハイブリッドポスト量子鍵交換を確認できます。クライアント側では、Wireshark などのユーティリティを使用するか、主要なウェブブラウザに組み込まれた開発者ツールを使用して、TLS ハンドシェイクの詳細を確認できます。 検証は 2 段階のプロセスです。まず、Secrets Manager クライアントを使用してシークレットを取得し、 GetSecretValue API コールを生成します。次に、 AWS CloudTrail で、そのコールがハイブリッドポスト量子鍵交換をネゴシエートしたことを確認します。 Secrets Manager クライアントを使用してシークレットを取得する 以下の例では、Secrets Manager Agent、Lambda 拡張機能、CSI Driver を使用してシークレットを取得する方法を示します。これらはいずれも、 GetSecretValue API を呼び出す際に自動的にハイブリッドポスト量子鍵交換をネゴシエートします。 EC2 インスタンスで Secrets Manager Agent を使用してハイブリッドポスト量子 TLS を検証するには: Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにエージェントをインストールし、シークレットを取得するためのクライアントとして使用します。 AWS Secrets Manager Agent の手順に従います EC2 インスタンスプロファイルが、シークレットを取得するための secretsmanager:GetSecretValue 権限を持っていることを確認します プライベート EC2 インスタンス に接続します EC2 インスタンスにエージェントをインストールします エージェントを使用して シークレットを取得 します curl -H "X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)" localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN> CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します Lambda 拡張機能を使用してハイブリッドポスト量子 TLS を検証するには: AWS パラメータおよび Secrets Manager Lambda 拡張機能を使用して、直接 API コールを介して Secrets Manager からシークレットを取得する Lambda 関数を作成します。 AWS パラメータおよびシークレット Lambda 拡張機能の使用 に従って、Lambda レイヤーと Lambda 関数を作成します 最新の拡張機能バージョンを選択します CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します Amazon EKS で CSI Driver を使用してハイブリッドポスト量子 TLS を検証するには: Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで、 AWS Secrets Store CSI Driver プロバイダーを使用して Secrets Manager からシークレットを取得 し、Kubernetes ポッドで使用します。 インストールされているアドオンのバージョンが 2.0.0 以降であることを確認します eksctl get addon --cluster <CLUSTER-NAME> --name aws-secrets-store-csi-driver-provider シークレットをマウントするポッドを再起動するか、新しいポッドをデプロイして、シークレットの取得をトリガーします CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します CloudTrail を使用してハイブリッドポスト量子鍵交換を確認する CloudTrail ログ には、Secrets Manager API コールの tlsDetails フィールドが含まれています。TLS でのハイブリッドポスト量子鍵交換がアクティブな場合、 tlsDetails の keyExchange フィールドに X25519MLKEM768 が表示されます。各 CloudTrail レコードには、暗号スイートと、利用可能な場合は TLS ハンドシェイク中にネゴシエートされた鍵交換グループを含む tlsDetails フィールドが含まれています。 CloudTrail 用の AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、 CloudTrail イベント履歴 を操作できます。 コンソールを使用して CloudTrail イベントを検索するには: 正しい AWS リージョンにいることを確認します CloudTrail コンソールを開き、[イベント履歴] を選択します [ルックアップ属性] フィルターで、[イベント名] と [GetSecretValue] を選択します 図 1: イベント名で CloudTrail イベント履歴を検索 イベントを選択します 図 2: イベントを選択 ページの [イベントレコード] セクションで出力を表示します 図 3: CloudTrail – GetSecretValue イベント AWS CLI を使用して CloudTrail イベントを検索するには: AWS CLI を使用して、最新のイベントを選択し、出力を確認します。 aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \ --max-results 5 \ --region <YOUR-REGION> \ --query 'Events[0].CloudTrailEvent' \ --output text GetSecretValue API コールの CloudTrail イベントの例: 以下の例では、 userAgent フィールドは、Secrets Manager への接続にクライアントとして使用されたものを反映しています。 注 : userAgent の値は、使用するクライアントによって異なります。 { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89", "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89", "accountId": "111122223333", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE", "accountId": "111122223333", "userName": "YOUR-EC2-INSTANCE-PROFILE" }, "attributes": { "creationDate": "2026-03-27T17:08:37Z", "mfaAuthenticated": "false" }, "ec2RoleDelivery": "2.0" }, "inScopeOf": { "issuerType": "AWS::EC2::Instance", "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89" } }, "eventTime": "2026-03-27T17:12:54Z", "eventSource": "secretsmanager.amazonaws.com", "eventName": "GetSecretValue", "awsRegion": "eu-west-2", "sourceIPAddress": "1.2.3.4", "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0", "requestParameters": { "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret" }, "responseElements": null, "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223", "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73", "readOnly": true, "resources": [ { "accountId": "111122223333", "type": "AWS::SecretsManager::Secret", "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com", "keyExchange": "X25519MLKEM768" } } keyExchange フィールドに X25519MLKEM768 が表示されている場合、TLS でのハイブリッドポスト量子鍵交換がアクティブです。 X25519 などの従来のアルゴリズムが表示されている場合は、クライアントが ML-KEM のサポートを通知していないため、クライアントのバージョンと設定を確認する必要があります。 トラブルシューティング クライアントを更新した後も Secrets Manager API コールが X25519MLKEM768 をネゴシエートしない場合は、この記事の冒頭付近にある クライアントのハイブリッドポスト量子鍵交換の要件 セクションに記載されているとおり、SDK バージョン、OpenSSL バージョン (Python)、ファイアウォールまたはプロキシの設定を確認してください。 次のステップ このリリースは、より広範な移行における 1 ステップです。AWS は、 AWS PQC 移行計画 のワークストリーム 2 の一環として、AWS サービスの HTTPS エンドポイント全体で ML-KEM のサポートを引き続き展開しており、パブリック AWS エンドポイント全体での完全なカバレッジを目指しています。 ML-KEM の標準化前の前身である CRYSTALS-Kyber のサポートは、2026 年に AWS エンドポイント全体で段階的に廃止されます。CRYSTALS-Kyber のサポートのみを通知する古い SDK バージョンを使用しているお客様は、廃止されたアルゴリズムをネゴシエートするのではなく、従来の TLS に適切にフォールバックします。このフォールバックを回避するには、この記事に記載されている SDK バージョンにアップグレードしてください。 PQC 移行の道のりは、転送中のデータの機密性にとどまりません。AWS の PQC への取り組みやお客様側の責任共有に関する最新の動向を把握するには、 AWS ポスト量子暗号 ページをフォローしてください。 まとめ AWS Secrets Manager は、シークレットの保護とコンプライアンスの取り組みのサポートに役立てるため、ML-KEM を使用したハイブリッドポスト量子鍵交換をデフォルトで有効にするようになりました。この更新は、最新のクライアントバージョンを使用しているお客様にとって、コード変更や設定の更新を必要としません。 この記事では、AWS Secrets Manager がハイブリッドポスト量子暗号を使用して TLS 接続を保護する方法、どのクライアントがこの機能をサポートしているか、そして harvest now, decrypt later 攻撃から接続が保護されていることを検証する方法について説明しました。 今回のリリースの恩恵を今すぐ受けるには、以下を実施してください。 Secrets Manager クライアント (Agent、Lambda 拡張機能、または CSI Driver) を利用可能な最新バージョンにアップグレードして、ML-KEM を使用したハイブリッドポスト量子鍵交換を有効にする ワークロードがキャッシュクライアントではなく AWS SDK を使用している場合は、AWS SDK と基盤となる依存関係を、この記事に記載されている最小バージョンにアップグレードする Secrets Manager API コールの CloudTrail tlsDetails の keyExchange フィールドを確認して、TLS でのハイブリッドポスト量子鍵交換がアクティブであることを検証する 企業のファイアウォールやプロキシを経由するネットワークパスを含め、環境内でエンドツーエンドのハイブリッドポスト量子鍵交換 TLS 接続をテストする AWS は引き続きポスト量子暗号のサポートを展開していきます。より広範な移行の取り組みについては、 AWS PQC 移行計画 を参照してください。また、より広範な環境の最新の暗号インベントリを維持して、移行が必要となる従来の公開鍵暗号の他の使用箇所を特定してください。 CISA Quantum-Readiness ガイダンス と AWS PQC 移行計画が、その良い出発点となります。 追加リソース AWS KMS、ACM、Secrets Manager で ML-KEM ポスト量子 TLS をサポート開始 ポスト量子 TLS を Python で実装・検証する方法 P. Stéphanie Mbappe Stéphanie は Amazon Web Services のセキュリティコンサルタントです。お客様のセキュリティの取り組みのあらゆる段階で支援することに喜びを感じています。学習や新しいソリューションの設計、そして自分の知識を他の人と共有することを楽しんでいます。 Tobias Nickl Tobias は Amazon Web Services のセキュリティコンサルタントで、セキュリティアーキテクチャとクラウド変革を専門としています。AWS のお客様と協力して、現在および新たに出現する脅威の両方に対処するセキュリティアーキテクチャを設計および実装しています。その活動を通じて、組織がクラウドの成熟度とともに進化するセキュリティ戦略を構築できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

AWS オブザーバビリティ関連リリースまとめの第1回へようこそ！2026年の最初の5か月間は、AWS オブザーバビリティにとって大きな変革をもたらした期間となり、 Amazon CloudWatch 、 AWS X-Ray 、 Amazon Managed Grafana 、 Amazon Managed Service for Prometheus にまたがって40を超えるリリースが行われました。この期間を特徴づける2つの大きなテーマは、統一された計装標準である OpenTelemetry 対応を強化したことと、オブザーバビリティを誰もが利用できるようにする AI 駆動のオペレーション です。 ​ Amazon Elastic Kubernetes Service (EKS) 上でコンテナを実行している方も、複数リージョンにまたがるデータベースを管理している方も、AI 支援のワークフローを構築している方も、ここには役立つ情報があります。さっそく見ていきましょう。 図1. カテゴリ別の AWS オブザーバビリティ リリース数 図2. AWS オブザーバビリティ リリースカレンダー一覧 OpenTelemetry が CloudWatch にネイティブ対応 CloudWatch OpenTelemetry Metrics（プレビュー） カスタムの変換ロジックや追加ツールなしで、OpenTelemetry Protocol (OTLP) を使ってメトリクスを直接送信できます。OpenTelemetry メトリクスは、1メトリクスあたり最大150のラベルをサポートし、gauge・sum・histogram・exponential histogram といったメトリクスタイプに対応します。 PromQL と Query Studio（プレビュー） Query Studio は、PromQL と CloudWatch Metric Insights を単一のインターフェースに統合します。コンソールを切り替えることなく、お好みの言語で AWS 提供メトリクスと OpenTelemetry メトリクスをクエリできます。ビジュアルなフォームビルダーとコードエディタを備えています。米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（シドニー）、アジアパシフィック（シンガポール）、欧州（アイルランド）で利用可能です。 Container Insights with OpenTelemetry for EKS（プレビュー） OpenTelemetry ネイティブのメトリクス収集が Kubernetes モニタリングに対応し、コンテナのオブザーバビリティをより広範な OpenTelemetry 戦略と整合させます。 クロスリージョンのテレメトリ有効化ルール 単一のリージョンから、複数リージョンにまたがるテレメトリを監査・有効化できます。すべての AWS 商用リージョンで利用可能です。 AI 駆動オペレーション：オブザーバビリティの新しいインターフェース CloudWatch Pipelines AI 設定 生成 AI を活用し、自然言語による記述でログプロセッサを設定できます。変換ルールを手動で記述する代わりに、意図を記述するだけでシステムが適切な設定を生成します。 AWS Observability Kiro Power AI エージェント支援のワークフローを Kiro 内で直接利用し、アプリケーションの健全性に関する問題をより迅速に調査できます。これにより、開発者ツールに直接組み込まれた AI ネイティブなオブザーバビリティが実現します。 CloudWatch Logs：より強力に、より柔軟に クエリ同時実行数が3倍に Logs Insights QL の同時クエリ上限が30から100に増加しました。アカウント・リージョンごとに、1秒あたり StartQuery API を10回、GetQueryResults API を10回実行できるようになりました。 HTTP ベースのインジェスト HTTP Log Collector、ND-JSON、Structured JSON、OpenTelemetry プロトコルによるログインジェストを新たにサポートしました。これにより、CloudWatch エージェントや AWS SDK 以外の、より柔軟な選択肢が加わりました。 Infrequent Access（低頻度アクセス）の機能強化 Infrequent Access ログクラスにデータ保護機能と、OpenSearch PPL および SQL クエリ言語のサポートが追加されました。これにより、これまで Standard クラスが必要だったワークロードでも、コスト最適化されたこのクラスが利用可能になります。 テレメトリ収集の自動有効化の拡張 自動有効化が、Amazon CloudFront 標準アクセスログ、AWS Security Hub CSPM 検出結果ログ、Amazon Bedrock AgentCore のMemory・Gateway のログ/トレースに対応しました。 データソース別のマルチアカウント集約 データソースの名前と種類に基づいて、複数アカウントにまたがるログを集約できるようになりました。どのログを中央アカウントに集約し、どのログをローカルに保持するかをきめ細かく制御できます。 CloudWatch Logs Insights の lookup クエリコマンド lookup コマンドを使うと、クエリ実行時にログデータをルックアップテーブルと結合し、結果を意味のある値で自動的にエンリッチ（拡充）できます。 Logs Insights の JOIN・サブクエリコマンド JOIN とサブクエリコマンドにより、異なるサービスやロググループにまたがるアプリケーションとインフラのエラーの相関分析、複数サービスにわたるセキュリティイベントの分析、分散システムをまたぐユーザーセッションの追跡など、さまざまなシナリオでのトラブルシューティングを高速化できます。 ロググループのタグによる Logs Insights クエリ このリリースにより、共通のタグを持つすべてのロググループに対してクエリを実行できるようになりました。ロググループのタグが追加・削除されると、クエリは一致するロググループを自動的に反映するため、環境の拡大に伴う運用負荷を軽減します。 CloudWatch Pipelines：フィルタリング・ルーティング・変換 イベントのドロップと条件付き処理 新しいドロップイベントプロセッサと条件付き処理機能により、パイプライン内でコンテンツに応じたフィルタリング、ルーティング、変換が可能になりました。詳細は Amazon CloudWatch Pipelines  のドキュメントをご覧ください。 コンプライアンスとガバナンスの制御 ログパイプライン向けのデータ整合性とアクセス制御の機能がリリースされました。これにより、エンタープライズの監査証跡と制御されたデータフローの要件に対応しました。 メトリクス Amazon Bedrock の Time To First Token とクォータ消費量 TimeToFirstToken は、リクエスト送信時から最初のトークン受信時までのレイテンシを、ストリーミング API（ConverseStream および InvokeModelWithResponseStream）について計測します。 EstimatedTPMQuotaUsage  は、すべての推論 API（Converse、InvokeModel、ConverseStream、InvokeModelWithResponseStream）にわたって、キャッシュ書き込みトークンや出力バーンダウンレートを含む、推定 Tokens Per Minute (TPM) クォータ消費量を追跡します。 Direct Connect の BGP モニタリング 仮想インターフェイス (VIF) 向けの3つの新しい Amazon CloudWatch メトリクスにより、Border Gateway Protocol (BGP) セッションの健全性とルート数を可視化できます。ハイブリッドクラウド接続を管理するネットワークエンジニアや運用チームは、カスタムソリューションの構築や API のポーリングなしに、CloudWatch を通じて BGP セッションをネイティブに監視できます。 AWS Private CA の使用率メトリクス 新しいメトリクスは、各 CA が発行した証明書の数と各リージョンの CA の総数を追跡します。これにより、これらのクォータに対する使用状況を監視し、CA のライフサイクルを先回りして管理して高可用性を維持できます。 Amazon S3 Express One Zone のリクエストメトリクス リクエストメトリクスを使用して、S3 Express One Zone を利用するアプリケーションのパフォーマンスを追跡し、運用上の健全性を監視できます。 Amazon ECS Managed Instances が NVIDIA GPU メトリクスをサポート 新しい GPU メトリクスにより、Amazon ECS Managed Instances の GPU の容量、使用率、メモリ、ハードウェアの健全性、温度状態を CloudWatch で直接監視できるようになりました。 AWS Outposts ラックの LagStatus CloudWatch メトリクス このメトリクスにより、外部のネットワークツールや他チームとの調整に頼ることなく、CloudWatch コンソール内で Outposts の LAG 接続ステータスを直接監視できます。 Amazon ElastiCache がネットワーク容量計画とエンジン診断向けに13の新しい CloudWatch メトリクスを追加 ​ Amazon ElastiCache のお客様は、ノードベースのクラスター向けの13の新しい CloudWatch メトリクスを使用して、ネットワークスロットリング、メモリの断片化、接続枯渇を検出できるようになりました。個々のノードで INFO コマンドを実行したり、生のバイトカウンターからベースラインを計算したりすることなく、これらのホストレベルおよびエンジンレベルの診断を CloudWatch から直接監視できます。 アラーム、Application Signals、RUM アラームミュートルール 計画的なデプロイやメンテナンスウィンドウ、業務時間外において、監視の可視性を損なうことなくアラーム通知を一時的にミュートできるようになりました。計画的な変更時のアラート疲れに対する、待望のネイティブソリューションです。 Application Signals の SLO 機能 Service Level Objectives（SLO：サービスレベル目標）向けの3つの新機能をリリースしました。 SLO レコメンデーション ：過去のパフォーマンスに基づいて適切な SLO ターゲットを提案します。 サービスレベル SLO ：個々の SLO を集約してサービスレベルのビューを提供します。 SLO パフォーマンスレポート ：経営層向けの SLO 遵守状況のサマリーを提供します。 欧州ソブリンクラウドでの RUM CloudWatch RUM が AWS 欧州ソブリンクラウド (eusc-de-east-1) に拡大しました。データがソブリン境界の外に出ることなく、Web アプリケーションのパフォーマンスを監視できます。 RUM アプリモニターの概要画面 改善された概要画面により、フリート全体の健全性、SLO 違反、分散トレーシングのカバレッジを単一のページで把握できるようになりました。 Web アプリケーション向け Amazon CloudWatch RUM セッションリプレイ セッションリプレイは、フォームのレンダリング失敗やナビゲーションフローの破綻など、誰も報告しないまま静かにコンバージョンやエンゲージメントに影響を与えうるユーザー体験の問題を、開発者が特定するのに役立ちます。 Amazon CloudWatch Database Insights リージョン拡大（ 1月20日 ＆ 3月11日 ） オンデマンド分析がアジアパシフィック（ニュージーランド、台北、タイ）およびメキシコ（中部）に拡大し、続いて AWS GovCloud (US) でも利用可能になりました。この機能は、選択した期間をベースラインのパフォーマンスと自動的に比較し、異常を特定し、具体的な是正アドバイスを提供します。 RDS PostgreSQL 向けロック競合診断 Amazon RDS for PostgreSQL インスタンス向けのロック競合診断を提供します。この機能により、進行中および過去のロック競合問題の根本原因を数分で特定できます。ロック競合診断機能は、CloudWatch Database Insights の Advanced モードでのみ利用可能です。 Amazon EC2 組織全体での EC2 詳細モニタリング 単一の設定ポイントから、 AWS Organizations 全体にわたって EC2 の詳細モニタリングを自動的に有効化できます。 EC2 ビジュアルエージェント設定エディタ EC2 コンソールに CloudWatch エージェント 向けのビジュアル設定エディタが追加され、JSON を手動で編集する必要がなくなりました。 AWS X-Ray：OpenTelemetry への移行が正式に X-Ray SDK とデーモンがメンテナンスモードに移行 2026年2月25日、AWS X-Ray の SDK とデーモンが正式にメンテナンスモードに入りました。この日以降、リリースはセキュリティ修正のみに限定されます。 これがお客様にとって意味すること： X-Ray サービス自体は引き続き完全にサポートされます。コンソール、トレース処理、バックエンド機能は変更なく継続します。 AWS Distro for OpenTelemetry (ADOT) を介した OpenTelemetry ベースの計装へ移行してください。 Java、Python、Node.js、.NET、Go、Ruby 向けの言語別移行ガイドが利用可能です。 ゼロコードの自動計装と手動計装の両方がサポートされます。 Amazon Managed Grafana AWS GovCloud (US) での提供 政府機関のお客様や規制業界向けに、GovCloud US-West および US-East の両リージョンで利用可能です。 KMS カスタマーマネージドキーによる暗号化 コンプライアンスのため、ワークスペースデータをお客様自身の暗号化キーで暗号化できます。GovCloud を除くすべてのリージョンで利用可能です。 Grafana 12.4 ワークスペースの作成 Drilldown アプリ ：Prometheus メトリクス、Loki ログ、Tempo トレース、Pyroscope プロファイルを、クエリ不要でポイント＆クリックで探索 Scenes ベースのダッシュボード ：レンダリングパフォーマンスが向上 強化された CloudWatch プラグイン ：PPL/SQL クエリのサポート、クロスアカウント Metrics Insights、ログ異常検出 再構築されたテーブルビジュアライゼーション ：CSS によるセルスタイリングとインタラクティブな Actions ボタン Amazon Managed Service for Prometheus この期間に Amazon Managed Service for Prometheus 単体の新機能はありませんでしたが、2つのエコシステム統合がその価値を大きく高めています。 OpenSearch Ingestion → Amazon Managed Service for Prometheus Sink カスタムの転送インフラなしに、フルマネージドでエンドツーエンドのメトリクスインジェストパイプラインを構築できます。単一のパイプラインで、メトリクスを PromQL 分析用に Amazon Managed Service for Prometheus にルーティングしつつ、ログ/トレースを OpenSearch に送信できます。 Amazon OpenSearch Service が Managed Prometheus とエージェントトレーシングをサポート データを重複させることなく、OpenSearch 内でログやトレースと並べて、ネイティブの PromQL 構文を使って Prometheus メトリクスを直接クエリできます。 まとめ 今回のまとめ：3つのポイント OpenTelemetry への移行を今すぐ始めましょう。 CloudWatch のネイティブ OpenTelemetry メトリクス、PromQL Query Studio、そしてメンテナンスモードに入る X-Ray SDK によって、進むべき道は明確です。ADOT が計装レイヤーになります。 AI がオブザーバビリティの新しいインターフェースです。 MCP サーバー、自然言語によるパイプライン設定、Kiro 統合により、クエリを書く代わりに監視データと「対話」できる場面がますます増えています。 コスト最適化がより容易になりました。 Infrequent Access ログクラスの機能強化、プレビュー期間中の無料 OpenTelemetry メトリクス、無料の Pipeline 機能により、包括的なオブザーバビリティへのハードルが下がりました。 さらに情報をお探しですか？ Cloud Operations Enablement シリーズのライブ／ハンズオンセッションに参加：h ttps://aws-experience.com/amer/smb/events/series/Cloud-Operations-Enablement CloudWatch ドキュメントを確認： https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ MCP サーバーに関するブログ記事を読む： https://aws.amazon.com/jp/blogs/news/enhance-your-aiops-introducing-amazon-cloudwatch-and-application-signals-mcp-servers/ 次の四半期にまたお会いしましょう！ Joe Alioto Joe は AWS の Cloud Operations 担当の Worldwide Senior Specialist Solutions Architect で、オブザーバビリティ、AI 駆動のオペレーション、集中型オペレーション管理を専門としています。20年以上のオペレーションエンジニアリング経験を持ち、直近2年間は AI と AIOps に注力しています。彼は、アプリケーションパフォーマンス、インフラメトリクス、データベースワークロードを結びつけるインテリジェントなオブザーバビリティ戦略の構築を支援しており、AI エージェントと自動化を活用して平均解決時間 (MTTR) を短縮し、オペレーションチームの大規模な働き方を変革することにますます取り組んでいます。 本ブログは 2026 年 5 月 19 日に公開された AWS Observability ICYMI: Jan-May 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

本記事は 2026 年 6 月 2 日に公開された “ Announcing durability for Amazon ElastiCache for Valkey ” を翻訳したものです。 Amazon ElastiCache は数十万のお客様にサービスを提供し、Valkey、Memcached、Redis OSS のワークロード全体で毎秒数十億のリクエストをマイクロ秒のレイテンシーで処理しています。多くの組織では、ElastiCache のマルチ AZ レプリケーションと自動フェイルオーバーがレジリエンスの要件を満たしていますが、お客様がキャッシュだけでなく永続的なデータストアとして ElastiCache を採用するケースが増えるにつれ、データ損失が主要な懸念事項となっています。 本日、 Amazon ElastiCache for Valkey の耐久性機能の提供開始を発表します。これにより、データ損失を許容できないワークロードに ElastiCache を使用できるようになります。 この記事では、耐久性がどのように機能するかを説明し、アーキテクチャを詳しく見ていき、耐久性が ElastiCache でお客様が期待するマイクロ秒単位のレイテンシーを損なわないことを示すパフォーマンス結果を共有します。 耐久性の仕組み ElastiCache の耐久性は、マルチ AZ トランザクションログを使用して、インフラストラクチャ障害時の高速リカバリと再起動によるデータ保護を提供します。ElastiCache は 2 つの耐久性オプションを提供しています。ゼロデータ損失を設計した同期書き込みと、マイクロ秒単位の書き込みレイテンシーを実現する非同期書き込みです。 同期書き込み は、データ損失が許容できない場合に適した選択肢です。ElastiCache は、クライアントに応答する前に、マルチ AZ トランザクションログ内の少なくとも 2 つのアベイラビリティーゾーン (AZ) にデータを永続化します。確認応答された書き込みはすべて永続的であり、書き込みレイテンシーは 1 桁台のミリ秒です。プライマリノードは強い整合性を持ち、プライマリでの読み取り操作は常に最新のデータを返します。この整合性はフェイルオーバー時にも保持されます。同期書き込みは、RAG アプリケーション向けのナレッジベース、AI エージェントの長期メモリ、AI エージェントのワークフロー状態、決済トークン化、ストリーミングメタデータ、ゲームプレイヤーの状態、リアルタイム在庫管理など、書き込みの損失が誤ったアプリケーション動作を引き起こす場合に最適です。 非同期書き込み は、データが復旧可能であるものの、ソースからの再構築が遅い、または運用コストが高い場合に適した選択肢です。非同期書き込みでは、クライアントへの応答後にデータが Multi-AZ トランザクションログに永続化されるため、追加コストなしでマイクロ秒単位の書き込みレイテンシーを維持できます。万が一障害が発生した場合、最大 10 秒間のコミットされていないデータが失われる可能性があります。潜在的なデータ損失を制限するため、ElastiCache は耐久性ラグを監視します。これは、まだログに永続化されていない最も古い書き込みからの経過時間です。このラグが 10 秒に達すると、プライマリノードはログが追いつくまで書き込みの受け入れを停止します。非同期書き込みは、セッションストア、ゲームのリーダーボード、リアルタイム分析、事前ロードされたデータセットなど、数秒間の最近の書き込みを失うことは許容できるものの、より大きなギャップが生じると調整にコストがかかる場合に最適です。 耐久性を有効にしていない ElastiCache は、データがオンデマンドで簡単に再構築できる場合に適しています。元となるデータベースに基づくリードスルーキャッシュ、レート制限カウンター、または欠落したエントリをその場で取得または再計算できるワークロードに使用してください。 同期書き込みと非同期書き込みの両方で、マイクロ秒単位の読み取りレイテンシーが維持されます。いずれのオプションでも、レプリカノードは結果整合性を持ち、レプリカからの読み取り操作は常に最新の書き込みを反映するとは限りません。次の表に、2 つの耐久性オプションをまとめます。   同期書き込み 非同期書き込み 標準的な読み取りレイテンシー マイクロ秒 マイクロ秒 標準的な書き込みレイテンシー 1 桁ミリ秒 マイクロ秒 データ損失に関する保証 データ損失ゼロ。確認された書き込みはすべて、少なくとも 2 つのアベイラビリティーゾーンにわたって永続化されます 万が一障害が発生した場合、最大 10 秒間の確認された書き込みが失われる可能性があります。 一般的なユースケース RAG アプリケーションのナレッジベース、AI エージェントの長期メモリとワークフロー状態、支払いトークン化、リアルタイム在庫管理 セッションストア、ゲームリーダーボード、リアルタイム分析、事前ロード済みデータセット アーキテクチャ 次の図は、Multi-AZ のトランザクションログを使用した ElastiCache の耐久性がどのように機能するかを示しています。 同期書き込み 同期書き込みが設定されたクラスターにクライアントが書き込みコマンドを送信した場合: プライマリノードがメモリ内で書き込みコマンドを受信して実行します。 書き込みは、少なくとも 2 つのアベイラビリティゾーンにまたがる Multi-AZ トランザクションログに永続化されます。 永続化が確認されると、プライマリはクライアントに成功レスポンスを返します。 これは、クライアントが成功レスポンスを受け取った後、その書き込みが永続化されることを意味します。プライマリノードがその直後に障害を起こしても書き込みは失われず、新しいプライマリへのフェイルオーバー後を含め、プライマリからの今後のすべての読み取りにその書き込みが反映されます。トレードオフは書き込みレイテンシーです。各書き込みはトランザクションログへの AZ 間ネットワークラウンドトリップが発生するため、数ミリ秒の書き込みレイテンシーが生じます。 非同期書き込み 非同期書き込みが設定されたクラスターにクライアントが書き込みコマンドを送信する場合： プライマリノードがメモリ内で書き込みコマンドを受信して実行します。 プライマリはマイクロ秒のレイテンシーで即座にクライアントに応答を返します。 バックグラウンドで、書き込みは Multi-AZ トランザクションログに書き込まれます。 クライアントが成功レスポンスを受信した時点では、書き込みはプライマリノードのメモリ内にのみ存在します。まだトランザクションログには書き込まれていません。書き込みが永続化される前にプライマリノードに障害が発生すると、その書き込みは失われます。これが非同期書き込みの基本的なトレードオフです。マイクロ秒単位の書き込みレイテンシーと引き換えに、データ損失が発生しうる限られた時間枠が存在します。 非同期書き込みの耐久性バッファ 非同期書き込みによる潜在的なデータ損失を制限するため、ElastiCache は最大 10 秒の耐久性バッファを強制します。プライマリノードは、受け入れられたがまだ Multi-AZ トランザクションログに永続化されていない最も古い書き込みの経過時間を継続的に追跡し、この値を DurabilityLag メトリクスとして Amazon CloudWatch に公開します。 この経過時間が 10 秒未満である限り、ノードは通常通り新しい書き込みを受け入れ続けます。バッファが 10 秒を超えて増加した場合、例えばトランザクションログへの一時的なネットワーク輻輳が原因である場合、プライマリは追いつくまで一時的に受信する書き込みコマンドを拒否します。この期間中も読み取り操作はマイクロ秒のレイテンシーで提供され続けます。トランザクションログが追いつき、耐久性ラグがしきい値を下回ると、手動介入を必要とせず書き込みが自動的に再開されます。実際には、ほとんどの書き込みは 10 秒のしきい値内に十分永続化され、ほとんどのクラスターは通常の動作条件下で拒否状態に入ることはありません。非同期耐久性クラスターにトラフィックを送信するようにクライアントを構成する場合、一時的に拒否された書き込みコマンドに対して指数バックオフによる自動リトライを有効にすることをお勧めします。Valkey の公式オープンソースクライアントライブラリの 1 つである Valkey GLIDE をお勧めします。これは信頼性と高可用性を考慮して設計されています。GLIDE は指数バックオフによる自動リトライとアベイラビリティーゾーン認識ルーティングをサポートしています。クライアント構成のベストプラクティスについては、 Best practices: Valkey/Redis OSS clients and Amazon ElastiCache を参照してください。 障害シナリオ ElastiCache の耐久性は、以下の障害タイプから保護します。 プライマリノードの障害。 プライマリノードに障害が発生した場合、ElastiCache は自動的にレプリカへのフェイルオーバーをトリガーします。レプリカはトランザクションログから追いつき、その後新しいプライマリとして書き込みを受け入れ始めます。障害が発生したノードは置き換えられ、ログから同期されます。同期書き込みでは、データは失われません。非同期書き込みでは、プライマリが障害を起こす前にトランザクションログにすべての書き込みが記録されていない可能性があるため、最大 10 秒間の確認応答済みの書き込みが失われる可能性があります。 リードレプリカの障害。 リードレプリカに障害が発生した場合、障害が発生したノードは置き換えられ、選択された耐久性オプションに関係なく、Multi-AZ トランザクションログから同期されます。データ損失は発生しません。 シャード全体の障害 (シャード内のすべてのノード)。 シャード全体に障害が発生した場合、すべてのノードが置き換えられ、Multi-AZ トランザクションログから同期されます。同期書き込みでは、データは失われません。非同期書き込みでは、最大 10 秒間の確認応答済みの書き込みが失われる可能性があります。コミットされたデータが復元された後、置き換えられたノードの 1 つが自動的に新しいプライマリとして選出されます。 パフォーマンス分析 ElastiCache の耐久性を有効にした場合と無効にした場合のスループットと読み取り/書き込みレイテンシーを測定し、それらを比較しました。その結果、ElastiCache で耐久性を有効にしても、お客様が ElastiCache に期待するマイクロ秒単位のレイテンシーが損なわれないことを実証しました。 テスト方法 r7g.4xlarge ノードを使用して、耐久性なし、同期書き込み、非同期書き込みの Valkey 9.0 for Amazon ElastiCache クラスターを起動しました。各クラスターは、1 つのプライマリノードと 1 つのリードレプリカで構成され、テスト実行前にサンプルデータが事前に投入しました。Valkey のデフォルトのパフォーマンス測定ツール ( valkey-benchmark ) を使用して、300 万個のキーでコマンドパイプラインなしで実行し、プライマリノードと同じ AZ 内の 10 個の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用してクラスターにトラフィックを向けました。一般的なお客様のワークロードパターンを代表する混合ワークロード (80% 読み取り、20% 書き込み) を使用して、50K と 100K TPS の 2 つのスループットレベルでテストしました。ElastiCache クラスターはマルチ AZ 分散システムであるため、同一のセットアップでも下の表の数値からある程度のばらつきが観察される場合があります。 次の表は、r7g.4xlarge ノードにおけるすべての ElastiCache オプションの読み取りおよび書き込みレイテンシーを比較したものです。 ワークロード (80% 読み取り、20% 書き込み) ElastiCache オプション ノードタイプ 読み取り P50 読み取り P90 書き込み P50 書き込み P90 50K TPS 耐久性機能なしの ElastiCache r7g.4xlarge 260 µ s 301 µ s 147 µ s 185 µ s 50K TPS 非同期書き込み r7g.4xlarge 245 µ s 289 µ s 112 µ s 152 µ s 50K TPS 同期書き込み r7g.4xlarge 245 µ s 288 µ s 2.15 ms 2.36 ms 100K TPS 耐久性機能なしの ElastiCache r7g.4xlarge 263 µ s 301 µ s 160 µ s 196 µ s 100K TPS 非同期書き込み r7g.4xlarge 245 µ s 286 µ s 128 µ s 158 µ s 100K TPS 同期書き込み r7g.4xlarge 879 µ s 992 µ s 2.72 ms 3.12 ms 重要なポイント: すべてのオプションでマイクロ秒の読み取りレイテンシーを維持します。同期か非同期かに関わらず、耐久性は両方のスループットレベルでマイクロ秒の読み取りパフォーマンスを維持するため、実際のユースケースの大半を占める読み取り中心のワークロードに適しています。 非同期書き込みは、耐久性を有効にしていない ElastiCache と同等のレイテンシーを実現します。50K TPS と 100K TPS の両方で、読み取りと書き込みのレイテンシーはいずれもマイクロ秒レベルです。追加料金なしで耐久性を追加でき、一般的なワークロードレベルでのスループットへの影響はごくわずかです。データ損失ゼロを必要としないすべてのワークロードに対して、非同期書き込みをデフォルトとして推奨します。このオプションは、レイテンシーのペナルティなしで耐久性を提供します。 同期書き込みは、中程度のスループットでマイクロ秒の読み取りレイテンシーを維持します。50K TPS では、読み取りレイテンシーは 300 µ s 未満のままです。100K TPS では、システムがトランザクションログへのより高い並行性を処理するため、読み取りレイテンシーはサブミリ秒 (879 µ s) に増加します。書き込みレイテンシーは、両方のスループットレベルでミリ秒の 1 桁台に留まります。これは、書き込みを確認する前に 2 つのアベイラビリティーゾーンにデータを永続化するための予想されるトレードオフです。アプリケーションがデータ損失を一切許容できない場合は、同期書き込みを使用する必要があります。 ElastiCache の耐久性を使い始める 前提条件 始める前に、以下を確認してください。 アクティブな AWS アカウント AWS CLI バージョン 2.x 以降がインストールおよび設定されていること elasticache:CreateReplicationGroup と elasticache:ModifyReplicationGroup の IAM 権限 永続化クラスターの作成 耐久性を使い始めるには、新しい ElastiCache クラスターを作成し、 AWS Management Console 、AWS Software Development Kit (SDK)、または AWS Command Line Interface (CLI) を使用して、希望する耐久性オプションを選択する必要があります。 AWS マネジメントコンソールの使用 新しいクラスターを作成する際は、Valkey 9.0 以降を選択してください。クラスター設定で希望する耐久性オプションを選択します。 AWS CLI の使用 同期書き込みを使用する新しい耐久性のあるクラスターを作成するには： aws elasticache create-replication-group \ --replication-group-id my-durable-cluster \ --replication-group-description "ElastiCache durable cluster" \ --engine valkey --engine-version 9.0 \ --num-node-groups 2 --replicas-per-node-group 1 \ --cache-node-type cache.r7g.large \ --multi-az-enabled \ --transit-encryption-enabled \ --durability sync \ --region us-east-1 非同期書き込みを使用するクラスターを作成するには、 --durability async を設定します。 aws elasticache create-replication-group \ --replication-group-id my-durable-cluster \ --replication-group-description "ElastiCache durable cluster" \ --engine valkey --engine-version 9.0 \ --num-node-groups 2 --replicas-per-node-group 1 \ --cache-node-type cache.r7g.large \ --multi-az-enabled \ --transit-encryption-enabled \ --durability async \ --region us-east-1 クラスターの検証 クラスターを作成した後、耐久性が有効になっている状態で実行されていることを確認できます。 aws elasticache describe-replication-groups \ --replication-group-id my-durable-cluster \ --query 'ReplicationGroups[0].[Status,Durability]' --region us-east-1 出力には、ステータスが available として、選択した耐久性オプションが表示されるはずです。 耐久性オプションの切り替え 既存のクラスターを同期書き込みと非同期書き込みの間で切り替えるには、 modify-replication-group を使用します。 aws elasticache modify-replication-group \ --replication-group-id my-durable-cluster \ --durability async クリーンアップ 継続的な料金が発生しないように、作成した ElastiCache クラスターを削除してください。 aws elasticache delete-replication-group \ --replication-group-id my-durable-cluster \ --region us-east-1 注意: この操作により、クラスターとすべてのデータが永久に削除されます。続行する前に、必要なデータをバックアップしていることを確認してください。 まとめ ElastiCache の耐久性により、ElastiCache をキャッシングと永続的なデータストアの両方のユースケースで使用できます。同期書き込みは、マイクロ秒の読み取りレイテンシーと 1 桁ミリ秒の書き込みレイテンシーでデータ損失ゼロを実現するように設計されており、データ損失を許容できないワークロードに適しています。非同期書き込みは、追加料金なしで耐久性のない ElastiCache と同等のパフォーマンスを提供し、まれに障害が発生した場合に最大 10 秒の潜在的なデータ損失を許容できるワークロードに適しています。耐久性のない ElastiCache は、データをオリジンソースから再構築でき、書き込みの完全な可用性が最重要な従来のキャッシングワークロードに適した選択肢です。 ElastiCache の耐久性は、Valkey 9.0 から、すべての AWS 商用リージョン、AWS 中国リージョン、および AWS GovCloud (US) リージョンでご利用いただけます。料金の詳細については、 Amazon ElastiCache 料金ページ をご覧ください。詳細については、 ElastiCache ドキュメント をご覧ください。 著者について Jules Lasarte Jules は Amazon インメモリデータベースチームのソフトウェア開発エンジニアです。ElastiCache の耐久性に関するエンジニアリング活動を主導し、高性能分散システムとインメモリワークロードのデータ保護に注力しています。カナダのバンクーバーを拠点としています。 Karthik Konaparthi Karthik は Amazon インメモリデータベースチームのプリンシパルプロダクトマネージャーで、ワシントン州シアトルを拠点としています。データに関するあらゆることに情熱を持ち、お客様の課題を彼らが愛する製品に変えることを楽しんでいます。仕事以外では、家族と新しい場所を探索することを楽しみ、常に次の素晴らしいレストランを探しています。 本記事は、 Announcing durability for Amazon ElastiCache for Valkey を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの河井です。 6 月といえば、いよいよ FIFA ワールドカップ 2026 が開幕します！日本代表の活躍に期待が高まりますね。このワールドカップ期間中にもう 1 つ熱いイベントがあります！ 6 月 25-26 日に幕張メッセで開催される AWS Summit Japan 2026 です。ワールドカップではチームワークとデータ分析が勝敗を分けますが、製造業でも AI エージェントとデータ活用が競争力の鍵を握る時代になりました。今月の「月刊 AWS 製造」では、 Summit の製造業向け展示の見どころを中心に、 5 月の注目トピックをお届けします。さあ、キックオフです！ ピックアップトピック AWS Summit Japan 2026 — 製造業向け展示の見どころ いよいよ 6 月 25 日（木）〜 26 日（金） に千葉・幕張メッセにて AWS Summit Japan 2026 が開催されます！ 260 を超えるセッション、 300 以上の展示が予定されており、日本最大の「AWS を学ぶイベント」です。製造業のお客様にとって注目のポイントは、 Hall 7 の AWS Industries Zone 内にある製造業向け展示エリアです。今年は 2 つの展示エリアを用意しています ① 製造業 Highlight 展示 — 「AIで加速する製造業のルネッサンス」をテーマに、未来の製造業を体感できる展示 生産ラインの未来 — デジタルツイン×シミュレーションでボトルネックを特定し生産効率を最大化します。技術要素として「ソフトウェア定義型生産ライン」「デジタルツインによるシミュレーション」「AI エージェントによる意思決定支援」の 3 つを実機デモでご紹介しています。 ソフトウェア定義型ファクトリー — 物理 PLC を仮想化し「ソフト PLC」として動作させることで、生産ラインの制御ロジックをソフトウェアとして管理できます。 Git リポジトリによるバージョン管理やエッジからクラウドまでの一気通貫アーキテクチャを体感いただけます。 サプライチェーン — 需要変動や供給遅延が発生した際に、 AI エージェントが在庫枯渇の予測・生産計画への影響・代替調達の選択肢・対応方針案を迅速に導き出す一連の流れをデモで体験いただけます。 ② 製造業 Industry 展示 — すぐに使える」テクノロジーを実機デモで体感いただけます。 Product Engineering （製品設計開発）と Smart Product （スマート製品開発・運用）の 2 軸に加え、 AWS 認定デバイスウォールやお客様事例展示エリアで構成されています。 詳しくはこちらのブログをご覧ください： AWS Summit Japan 2026 製造業向け展示の見どころ紹介！ まだ登録していない方はぜひお早めに！ →  AWS Summit Japan 2026 登録ページ 直近で開催予定のイベント 6/17 AWS Summit New York City 6 月 17 日（水）にニューヨーク Javits Convention Center で開催されます。昨年の NY サミットでは Amazon Bedrock AgentCore や Amazon S3 Vectors など、 AI ・データ領域の重要な新サービス発表が相次ぎました。今年もキーノートに AWS VP of Agentic AI の Dr. Swami Sivasubramanian が登壇予定であり、エージェント AI をはじめとする最新のアップデートが期待されます。製造業のお客様にとっても、 Industrial AI や IoT に関する新発表が出る可能性がありますので要注目です。昨年の主な発表まとめは こちら をご参照ください。 6/25 – 6/26 AWS Summit Japan 2026 今年も日本最大の “AWS を学ぶイベント” AWS Summit Japan が 6 月 25 日（木）、 26 日（金）の二日間、幕張メッセで開催されます！ 260 以上のセッションと 300 以上の展示が予定されており、基調講演・事例セッション・パートナーセッションに加え、オフラインならではのハンズオン体験が可能です。製造業のお客様は Hall 7 の AWS Industries Zone にある製造業向け展示エリア（Highlight 展示 + Industry 展示）と Physical AI 特設展示をお見逃しなく！ 製造関連ブログのご紹介 5/8 データサイロの解消: Volkswagen の Amazon DataZone を活用したアプローチ フォルクスワーゲングループが Amazon DataZone を活用し、組織全体のデータサイロを解消するアプローチを紹介するブログ（翻訳記事）です。 43 工場をクラウド接続し、 1,200 以上の AI アプリケーションを展開する同社の Digital Production Platform （DPP）において、データメッシュアーキテクチャを実現した事例が紹介されています。製造業でよくある「部門間のデータが繋がらない」課題に対する実践的な解決手法として参考になります。 5/11 Manufacturing intelligence with Amazon Nova Multimodal Embeddings Amazon Nova のマルチモーダル埋め込みモデルを製造業で活用する方法を紹介するブログです。テキスト・画像・ドキュメントページを共有ベクトル空間にマッピングすることで、 CAD 図面、検査レポート、設計仕様書などをテキスト＋画像の両方で意味的に検索できるようになります。設計ナレッジの横断検索やビジュアル類似検索に活用できます。 5/14 Hannover Messe 2026 AWS ブースレポート 4 月にドイツ・ハノーバーで開催された世界最大級の産業見本市 Hannover Messe 2026 における AWS ブースのレポートです。今年のテーマは 「Built for Industrial AI」 です。 Physical AI （フィジカル AI）のデモが最大の注目を集め、来場者がデザインを入力すると生成 AI がオリジナルデザインを作成し、 AMR ・協働ロボットアーム・レーザー彫刻機・ AI 画像検査・ヒューマノイドロボットが協調して金属製コースターを製造する一連のデモンストレーションが披露されました。エージェント AI が工程全体を自律的にオーケストレーションする点が従来の産業オートメーションとの大きな違いです。その他、スマート生産・サプライチェーン・製品設計開発・スマートプロダクトの 4 領域で最新デモが展示されました。 5/21 AWS IoT Core 上の MCP と MQTT で Physical AI エージェントを構築する 本ブログでは、MQTT と MCP を AWS IoT Core 上で組み合わせ、Physical AI エージェントを構築する方法を紹介します。自律型バリスタロボットを例に、エッジの物理制御とクラウド AI の推論をリアルタイムに連携させ、未知のレシピや顧客の好みに即座に対応する実装パターンを解説します。 5/26 AWS Summit Japan 2026 ― AWS IoT サービスを活用した展示の一部をご紹介 AWS Summit Japan 2026 での AWS IoT サービス関連展示を紹介するブログです。 IoT Greengrass を活用したロボット遠隔テレオペレーション体験、 AI エージェントによる産業機械の自律診断とリアルタイム安全監視（スマートマシン）、 Physical AI 基盤としての IoT アーキテクチャ（Raspberry Pi/Jetson によるライブデモ、 A/B デプロイ・ロールバック等の本番運用機能）、 builders’ Fair のクラウド VLA 搭載ミニロボ、 AWS 認定デバイスウォールなどが紹介されています。 イベント動画のご紹介 Hannover Messe 2026 の AWS セッション動画が公開されています。 Hannover Messe 2026 – Realizing Industrial AI at Scale with AWS Hannover Messe 2026 における AWS のキーノートセッションです。 Industrial AI を実験段階から本番スケールへと進化させるための戦略と技術について、 AWS VP の Ozgur Tohumcu が解説しています。 Physical AI 、エージェント AI 、インテリジェントデータ基盤の 3 つの柱を軸に、自律製造システム、サプライチェーン最適化、製品イノベーションの加速に AWS がどう貢献するかが紹介されています。 Hannover Messe 2026 – How Amazon builds and deploys autonomous robots Amazon が自律ロボットをどのように設計・開発・デプロイしているかを紹介するセッションです。物流・製造現場で活躍する自律移動ロボット（AMR）の開発プロセス、シミュレーションによる強化学習、 Physical AI の実装アプローチなど、ロボティクスと AI の融合について解説されています Hannover Messe 2026 – Reply: From Factory Floor to Cloud — Scaling Manufacturing Data on AWS イタリアの IT コンサルティング企業 Reply が、製造現場のデータをクラウドにスケーラブルに接続するアーキテクチャを紹介するセッションです。工場フロアの OT データを AWS に統合し、データ基盤として活用するための実践的なアプローチが解説されています。 その他のセッション動画は以下のプレイリストからご覧いただけます。 AWS at Hannover Messe 2026 動画リスト 最新事例のご紹介 Volkswagen Group — Digital Production Platform (DPP) フォルクスワーゲングループは AWS との DPP 協業を 5 年間延長し、世界 43 工場をクラウド接続、 1,200 以上の AI アプリケーションを展開しています。 Amazon SageMaker による品質管理用コンピュータービジョン、 AI による電力消費最適化（ポズナン工場でエネルギーコスト 12%削減・ CO2 排出削減）、ソフトウェア定義車両（SDV）の製造プロセスへのソフトウェアデプロイなどを実現しています。 Siemens Energy — Connected Factory シーメンス・エナジーが AWS IoT SiteWise Edge と Domatica EasyEdge を活用し、世界 18 工場の Connected Factory プラットフォームを構築。手動データ収集時間を 50% 削減、設備保守コスト 25% 低減、機械稼働率 15% 向上を達成しました。 10 以上の産業プロトコルからデータを取り込み、 30 のカスタムユースケースを展開しています。 Miraitek — Amazon Bedrock で工場デジタル化 ミラノ工科大学発スタートアップの Miraitek が、 Amazon Bedrock を活用して工場フロアの効率化を支援するバーチャルアシスタント「Robin」を開発。生成 AI により製造デジタル化を加速しています。 Toyota Motor North America — HiveMQ × mTLS によるスマート製造 IIoT 基盤 トヨタ自動車北米（TMNA）が、 IIoT プラットフォーム「NEXUS」の MQTT メッセージング基盤として HiveMQ を Amazon ECS Fargate 上にセキュアにデプロイしました。mTLS （相互 TLS 認証）によるゼロトラスト接続を実現し、工場フロアデータの統合・リアルタイムインサイト・予知保全を実現しています。現在、単一工場パイロットから北米全工場へスケール中です。 Everllence — P & ID （配管計装図）の AI ナレッジグラフ化 ドイツのスタートアップ Everllence が AWS Generative AI Innovation Center と協業し、 P&ID をナレッジグラフ（Neo4j）に変換するソリューションを開発しました。 AI エージェントが機器の関係性やプロセスフローを推論・クエリし、エンジニアのトラブルシューティング時間を大幅に短縮します。 1 サイト分で 1,909 ノード・ 7,525 リレーションを 1 時間で自動生成できます。 エージェント AI × デジタルツインで製造オペレーショナルエクセレンスを実現 エージェント AI （自律型 AI）とデジタルツインを AWS 上で組み合わせ、製造業のオペレーショナルエクセレンスを実現するアーキテクチャと実践パターンを紹介するブログです。自律的な生産最適化、予知保全のスケール化、サプライチェーンインテリジェンスの 3 つの活用領域と、自動車メーカーのエンジン生産ライン（10,000+センサー）での実装事例が解説されています。 製造関連の主要なサービスアップデート 5/1 AWS for SAP Management MCP Server 一般提供開始 Amazon Bedrock AgentCore 上で動作する SAP 環境管理用 MCP サーバーが一般提供開始しました。自然言語で SAP 環境のモニタリング、コンプライアンスチェック、ライフサイクル管理（起動・停止）、スケジュール運用が可能になります。複数コンソール＋ 10 以上の API 呼び出しが必要だった操作を 1 つのインターフェースに統合します。 SAP を利用する製造業のお客様の Basis 運用効率化に直結します。 5/1 セキュリティ強化と MQTT v5.0 に対応した FreeRTOS 202604 LTS が利用可能に FreeRTOS の長期サポート版（202604 LTS）がリリースされました。セキュリティ強化と MQTT v5.0 対応が主な更新点です。製造現場のマイコンベースのエッジデバイスやセンサーノードで FreeRTOS を利用しているお客様は、より安全で高機能な通信が可能になります。 5/5 AWS IoT Core for Device Location に信頼レベル設定と測定タイプのサポートが追加 IoT Core for Device Location に信頼レベル（confidence level）設定と測定タイプのサポートが追加されました。デバイスの位置情報の精度をより細かく制御できるようになり、工場内の資産追跡や物流トラッキングの信頼性が向上します。 5/5 Amazon EC2 I8ge インスタンスが一般提供される AWS リージョンが増加 ストレージ最適化インスタンス EC2 I8ge の利用可能リージョンが拡大しました。高スループット・低レイテンシーのローカルストレージを必要とするワークロード（製造データ分析、シミュレーション、大規模ログ処理等）に適したインスタンスです。 5/28 AWS Iot CoreがDirect Messaging（ポイントツーポイント通信）をサポート AWS IoT Core に、接続中のデバイスへ MQTT クライアント ID を指定してダイレクトにメッセージを送信できる新機能「Direct Messaging」が追加されました。従来のようにデバイス側でトピックを事前にサブスクライブする必要がなく、メッセージ配信の可視性向上とコスト削減を実現します。この機能により、クラウド上の AI エージェントがロボットやエッジデバイスに対してリアルタイムに指示を送る Physical AI のユースケースが大幅に簡素化されます。具体的には、 MCP（Model Context Protocol）と MQTT を組み合わせることで、クラウド AI が「何をすべきか」を推論し、エッジの機械が「どう動くか」を実行するアーキテクチャを低レイテンシーで実現できます。 最後まで読んでいただきありがとうございました。それでは、また来月お会いしましょう！ 著者について 　河井信彦（Nobuhiko Kawai） アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト セキュリティベンダーを経て AWS Japan に入社し、エンタープライズ技術本部でソリュー ションアーキテクトとして活動中。関西の製造業のお客様を中心担当している。趣味はサッカーとフットサル。

2026年5月21日、アマゾンウェブサービスジャパン目黒オフィスにて、 招待制 セキュリティセミナー「ランサムウェアに備える『防御』と『復旧』— AWS で実現するセキュリティ対策」を開催しま した。当日は 37 社 54 名のお客様にご参加いただきました。 ランサムウェア攻撃の脅威が深刻化する中、多くの企業で「防御はしているが復旧設計まで手が回っていない」「バックアップはあるが本当に戻せるか検証できていない」「何から手をつければよいか分からない」といった課題があります。そこで本セミナーでは、AWS サービスとパートナーソリューションを通じて、「防御」と「復旧」の両面で自社のギャップを把握し、具体的な次のアクションを持ち帰っていただくことを目的に開催しました。 アジェンダ # タイトル スピーカー 1 オープニング 大西 千夏（エンタープライズ事業統括本部 流通・小売・消費財 第一事業本部 事業本部長） 2 基調講演：ランサムウェアの脅威と、いま求められる『2つの備え』 中島 智広（シニアセキュリティソリューションアーキテクト） 3 AWS セッション①：突破されないための備え（防御・検知） 須田 聡（シニアセキュリティソリューションアーキテクト） 4 AWS セッション②：突破されたときの備え — AWS Backup で実現する復旧力 焼尾 徹（シニアストレージソリューションアーキテクト） 5 パートナーセッション①：最新のサイバーリスクに対抗するためのエンドポイントセキュリティ CrowdStrike 菅村 優哉 様 6 パートナーセッション②：AWS 活用とセキュリティ強化を実現する Zscaler のご紹介 Zscaler 井上 智也 様 7 パートナーセッション③：ランサムウェア対策における運用支援 — 防御と復旧の間にある「第三の軸」 Cyber Security Cloud 山田 匡志 様 8 クロージング 石橋 香代子（技術統括本部 小売・消費財第一ソリューション部 部長） 9 個別相談会 – 本セミナーでは、まず基調講演でランサムウェア対策の全体像を「防御」と「復旧」の2軸で整理した上で、AWS サービスによる防御・検知、AWS Backup による復旧力の確保、そしてパートナーソリューションによるエンドポイント・ネットワーク・運用面でのさらなる強化と、対策の層を順に深めるかたちでセッションを構成しました。本ブログでは、各セッションの概要をご紹介します。 基調講演：ランサムウェアの脅威と、いま求められる『2つの備え』 最初に、シニアセキュリティソリューションアーキテクトの中島 智広より、ランサムウェア対策の全体像を「防御」と「復旧」の2つの軸で整理しました。 ランサムウェア侵害は、最終的にデータが暗号化されるまでに、いくつかの段階を経て進行します。言い換えれば、その途中のどこかで攻撃を止められれば、深刻な被害は防げます。一方で、万が一最終段階まで至ってしまった場合にも、事業を継続できる備えがあれば被害を最小化できます。この「防御」と「復旧」の2つを、本セミナーで提示した備えの軸としてお話ししました。本セミナー全体も、この2軸に沿ってセッションを構成しています。 「復旧」については、お客様とお話ししていてよく話題になる論点として、障害復旧（DR）とサイバーリカバリの違いをご紹介しました。多くのお客様がバックアップとリストアの仕組みを備えていますが、その多くは「同一環境に戻す」ことを前提としています。一方でサイバー攻撃を想定した場合は、新しい環境に作り直すという観点が必要になりやすく、そのための手順やプレイブックの整備が論点になりやすい——こうした会話の機会が多いことをお伝えしました。 最後に、AWS の責任共有モデルや Secure by Default の考え方を踏まえつつ、AWS 以外の環境も含めた全体での備えが大切であること、そして中長期的な基盤刷新と今すぐ着手できる対策を並行して進めるという視点を共有し、基調講演を締めくくりました。 突破されないための備え（防御・検知） 基調講演で示した「防御」の軸を具体化するセッションとして、シニアセキュリティソリューションアーキテクトの須田 聡より、AWS のセキュリティサービスを活用した防御・検知の具体策をご紹介しました。 「セキュリティは何かやっているが、十分かと言われると自信がない」「誰がどこまでやればいいか基準が決められない」「ソリューションの検討だけで時間がかかる」。お客様から多く聞かれるこうした悩みに対して、本セッションで最もお伝えしたかったのは「今すぐやれることがある」ということです。 Amazon GuardDuty と AWS Security Hub は、既存のシステム構成やパフォーマンスに影響を与えることなく、有効化するだけで使い始められます。セキュリティソリューションの比較検討に時間がかかっている間も、まずこの2つを有効化しておくことで、その間の穴を作らないことが効果的です。さらに、組織全体のアカウントを束ねて管理する仕組みとして AWS Control Tower そして新しい Security Hub の統合機能を活用することで一括有効化できます。 加えて、より高度な対策として、 Amazon GuardDuty Malware Protection for AWS Backup や AI エージェントによる自動ペネトレーションテスト（ AWS Security Agent ）といった新機能もご紹介しました。 突破されたときの備え — AWS Backupで実現する復旧力 防御で止めきれなかった場合に備える「復旧」の軸として、シニアストレージスペシャリストソリューションアーキテクトの焼尾 徹より、 AWS Backup を中心にご紹介しました。 攻撃者は必ずバックアップの削除を試みます。こうした脅威に対して、復旧設計のフレームワーク「3-2-1-1-0 ルール」を紹介した上で、AWS Backup を活用して今日から取り組める3つのアクションをお伝えしました。 1つ目は、AWS Backup の Vault Lock の有効化です。設定した保持期間中は誰にも（悪意のある操作だとしても）バックアップを削除できない状態を実現します。AWS Backup はネイティブのデータ保護機能を尊重する設計のため追加コストも最小限で、今日帰ってすぐに実行できる第一歩です。 2つ目は、リストアテストの実行です。バックアップを取っていても、実際に戻せるか、クリーンなデータであるかを確認することが重要です。AWS Backup のリストアテスト機能を使えば、クラウドのメリットを活かした確認がしやすくなります。 3つ目は、IaC（Infrastructure as Code）で環境自体も再構築できる状態にしておくことです。データだけ戻しても、システム環境が復旧できなければ業務は再開できません。データの復旧と環境の再構築の両方をスムーズにすることで「システムとして復旧」が迅速になります。 パートナーセッション：AWS上の防御をさらに強化する ここまでの AWS サービスによる防御・復旧に加えて、エンドポイントやネットワーク、日常の運用といった AWS の外側の領域をカバーするパートナーソリューションとして、3社にご登壇いただきました。 CrowdStrike：最新のサイバーリスクに対抗するためのエンドポイントセキュリティ CrowdStrike 様より、ランサムウェア対策に特化したエンドポイントセキュリティをご紹介いただきました。保護の柱は、NGAV（次世代型アンチウイルス）による AI と脅威インテリジェンスを活用した実行前の検知・駆除、EDR による侵害の全体像可視化とリモートでの迅速な対処、そして脅威ハンティングチーム（Falcon OverWatch）による24時間365日のプロアクティブな監視の3つです。特に脅威ハンティングは、正規ツールを悪用した「正常な動作と区別がつかない攻撃」を人の目で検知する CrowdStrike 独自の強みです。 保護対象はオンプレミスの PC から AWS 上の EC2 インスタンス、Kubernetes・Fargate 環境まで幅広くカバーしています。導入後の運用課題（アラートを捌ききれない、24時間体制を組めない等）に対しては、MDR サービス「Falcon Complete」が調査から対処まで主体的に実施する体制を提供しており、一般的な MDR の「助言のみ」とは異なる手厚いサポートが特徴です。さらに、AWS Marketplace を活用した調達により、包括契約のコミットメント消化やプロモーションクレジットの活用が可能であることもご紹介いただきました。 Zscaler：AWS 活用とセキュリティ強化を実現する Zscaler のご紹介 Zscaler 様より、ゼロトラストアーキテクチャによるランサムウェア対策をご紹介いただきました。ネットワークセキュリティは30年間アーキテクチャが変わっておらず、VPN を中心とした境界型セキュリティはクラウド・リモートワーク時代において限界を迎えています。VPN の脆弱性を突いた侵入が増加し、一度侵入されるとネットワーク全体に横展開されてしまう構成が課題です。 Zscaler のアプローチは3つ。まず「見つからないようにする」こと。アプリケーションをインターネットから隠蔽し、攻撃者がたどり着けない仕組みを実現します。次に、AWS を専用線経由の Private Cloud ではなく本来あるべき Public Cloud として活用するゼロトラストネットワークアーキテクチャ（ZTNA）により、高い生産性とセキュリティを両立します。そして、デセプション（欺瞞技術）によりおとりの偽資産を配置し、攻撃者がたどり着いた瞬間に検知・隔離することで、侵入後の横展開も防止します。Okta × CrowdStrike × Zscaler の3社連携による鴻池運輸様の導入事例もご紹介いただきました。 Cyber Security Cloud：ランサムウェア対策における運用支援 — 防御と復旧の間にある「第三の軸」 Cyber Security Cloud 様より、防御と復旧の「間」にある「第三の軸」としての運用の重要性をご紹介いただきました。EDR やバックアップの議論に集中しがちですが、有事の説明責任を支える生命線はログの取得・保全・改ざん防止・分析体制にあります。 有事に運用が手薄な組織で起きる破綻シナリオとして、侵入経路を特定できない（潜伏期間中のログが残っていない）、情報持ち出しの有無を判断できない（二重恐喝への対応不能）、ログそのものが攻撃対象になる、個人情報保護法の報告期限（速報3〜5日、確報30日）に間に合わない、平時から運用が疲弊している、という課題を提示いただきました。 マネージドセキュリティサービス「CloudFastener」では、NIST サイバーセキュリティフレームワーク（CSF）における統治から復旧までの全体のセキュリティ運用をワンストップで包括的に支援しています。カスタマイズされたコンサルティング、日常の運用負荷の削減、そしてインシデントレスポンス・デジタルフォレンジック（IRDF）まで一気通貫で対応できる体制を提供しています。 おわりに 本記事では、2026年5月21日に開催した「ランサムウェアに備える『防御』と『復旧』— AWS で実現するセキュリティ対策」セミナーについてレポートしました。参加いただいたお客様からは全体満足度 4.46 / 5.0 の高い評価をいただきました。「未実装部分があったのですぐに取り掛かります」「セキュリティ対応しているメンバーにも聞かせたい」「今後の自社インフラに有用な情報が得られた」などの声を頂戴しています。ご参加いただきました皆様、本当にありがとうございました。いただいたフィードバックをもとに改善を重ねてまいります。ランサムウェア対策の推進に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。

はじめに 本ブログは、株式会社丸千代山岡家と Fivetran Japan、Amazon Web Services Japan が共同で執筆しました。 みなさま、こんにちは。AWS ソリューションアーキテクトの大久保です。 昨今、Apache Iceberg を利用したレイクハウスアーキテクチャが AWS の Analytics ワークロードの中心となりつつあります。Iceberg テーブルを分析基盤の核に据える構成が広がる一方で、「データベースからどのように Iceberg テーブルにデータを連携するか」――この”データを投入するコンポーネント”の選定に悩まれている方も多いのではないでしょうか。特に、基幹データベースの変更をタイムリーに反映したい場合、 CDC（Change Data Capture） が有力な選択肢となります。CDC とは、データベースに対する変更（INSERT / UPDATE / DELETE）をリアルタイムまたはニアリアルタイムに検知・取得する手法です。従来のバッチ処理のようにテーブル全体を定期的にコピーするのではなく、変更差分のみを効率的に転送できるため、データの鮮度と転送効率を両立できます。しかし、実際に CDC パイプラインを構築しようとすると、複数サービスを組み合わせた運用負荷など、想定以上のハードルに直面することも少なくありません。 本記事では、ラーメンチェーン「山岡家」を展開する 株式会社丸千代山岡家 （以下、山岡家）が、Fivetran の CDC 機能を活用して Oracle から Amazon S3 上の Iceberg テーブルへのデータ同期を実現した事例をご紹介します。アーキテクチャの検討プロセスから Fivetran 導入後の効果まで解説しますので、同様の構成を検討されている方の参考になれば幸いです。 図 1：山岡家オリジナル看板ロゴ T シャツ。「ラーメンはスープが命。データは鮮度が命。」 山岡家のデータ活用と今回の課題 山岡家では、データ活用による経営の最適化に積極的に取り組んでいます。具体的には、以下のような取り組みを進めています。 仕入れ量の最適化 ：各店舗の売上・仕入れデータの分析による適正発注 人員配置の効率化 ：来客予測に基づくシフト最適化 キャッシュロジスティックスの最適化 ：店舗内現金の金種別増減予測 現金管理の差異分析 ：店舗ごとの現金過不足の検知・分析 これらのデータ活用を支える基盤として、Snowflake を中核に据え、AWS サービスと組み合わせたデータパイプラインを構築しています。Snowflake は分析・クエリだけでなく、パイプラインのオーケストレーション（タスク完了検知等）も担っており、データ基盤全体の中核的な役割を果たしています。 会計仕訳データのリアルタイム連携 こうしたデータ基盤をさらに発展させるにあたり、今回取り組んだのが 会計仕訳データのリアルタイム連携です。会計仕訳データは、現金管理の差異分析を含む幅広い用途で活用しています。現状は会計データを直接 BI に接続していますが、BI 層を分離し、データレイク経由での参照に移行することで、会計データを SSOT（Single Source of Truth）として一元管理したいと考えています。 今回の具体的な課題は Amazon RDS for Oracle 上の会計仕訳データを、ニアリアルタイム（数分間隔）で S3 上の Iceberg テーブルに同期し、 Snowflake からクエリ できるようにすること でした。このデータ連携の方式として CDC を採用した理由は以下の通りです。 ニアリアルタイムの反映が必要 ：店舗の現金出納データを BI で社内公開しており、数分単位でのデータ反映が求められていた 差分同期が必要 ：会計仕訳データは日々の入力に加えて過去データの修正・削除も発生するため、INSERT だけでなく UPDATE・DELETE を含むテーブル同期が必要だった 構築したアーキテクチャ この課題に対し、Fivetran の CDC 機能を採用して以下のアーキテクチャを構築しました。 図 2：RDS for Oracle から S3 Iceberg への CDC パイプラインアーキテクチャ Fivetran が RDS for Oracle から変更データを取得し、S3 上に Iceberg 形式で書き込みます。データカタログは Fivetran が管理する Polaris Catalog を利用しており、Snowflake はこのカタログを参照して S3 上の Iceberg テーブルを認識します。Tableau は Snowflake 経由でデータにアクセスする構成です。 以降のセクションでは、この構成に至った経緯と Fivetran を選択した理由、データの流れの詳細を解説します。 Fivetran の採用 検討した構成 当初は AWS のサービスを組み合わせた構成も検討しましたが、それぞれ課題がありました。 ストリーミング CDC（  AWS Database Migration Service → Amazon Kinesis Data Streams → Amazon Data Firehose → Amazon S3 ） ：DMS の CDC 機能自体は実績のある手法だが、今回の構成では DMS に加えて Kinesis Data Streams、Data Firehose、S3 と 4 つのサービスを組み合わせる必要があり、それぞれの設定・監視・障害対応を含めた運用負荷が課題だった。また、DMS の定期的なバージョンアップに伴うダウンタイムへの対応も継続運用上の考慮点だった バッチ ETL ：ニアリアルタイムでのデータ反映という要件を満たせなかった よりシンプルかつリアルタイム性を両立できる構成を模索する中で、Fivetran の CDC 機能に着目しました。 Fivetran とは Fivetran は、データの収集・転送を自動化するマネージドデータパイプラインサービスです。700 以上のデータソースに対応しており、ノーコードでデータパイプラインを構築できます。詳細は Fivetran 公式サイト をご参照ください。 図 3：Fivetran の全体像 — 多様なデータソースから Data Warehouse・Data Lake への連携を自動化する（出典: Fivetran） Fivetran の CDC 機能 は、ソースデータベースの変更（INSERT / UPDATE / DELETE）やスキーマの変更を検知し、ターゲットシステムへ自動的に反映します。Oracle を含む主要な RDB に対応しており、インフラの構築・管理なしに CDC パイプラインを実現できる点が特徴です。 Fivetran を選択した理由 山岡家が Fivetran を選択した背景には、以下のポイントがありました。 Oracle CDC の運用複雑性を吸収できる ：Oracle の CDC は、アーカイブログの管理や補足ロギングの設定など、他の RDB と比較して実装の複雑さが高い。Fivetran は Binary Log Reader 方式 でこれらを吸収し、Oracle 固有の設定を深く意識することなく CDC パイプラインを構築できる Iceberg 形式での書き込みと Snowflake と直接連携できる Polaris Catalog を提供している ：S3 に Iceberg 形式でデータを書き込み、カタログでメタデータを管理できる 複数データソースを統合管理できる ：Oracle の CDC だけでなく SmartHR 等の SaaS からの API 連携も同一プラットフォームで管理でき、データ基盤全体の統一性が向上する 運用コンポーネントが少ない ：SaaS として提供されるため、前述のストリーミング CDC 構成のように複数サービスの設定・監視・障害対応を個別に行う必要がない 山岡家では、本来単純な EL（Extract / Load）処理に社内リソースを割くのではなく、データ活用そのものに注力したいという背景がありました。データベースから Iceberg へ低い運用コストでニアリアルタイムに CDC が可能な Fivetran を選定し、短期間で目的を達成できました。 データの流れ 本記事で解説する CDC パイプラインのデータの流れは以下の通りです。 ソースからのデータキャプチャ ： Fivetran が Binary Log Reader 方式で RDS for Oracle の変更情報を取得し 、INSERT・UPDATE・DELETE の変更を検知します。初回実行時にはフルロードが行われ、以降は差分のみが転送されます。SmartHR からは API 経由で人事データを取得します（こちらは CDC ではなく API ポーリング）。 初回フルロードから差分同期への切り替えを含む具体的なセットアップ手順については「 Fivetran の Managed Data Lake Service の CDC で実現する業務システムから Apache Iceberg へのリアルタイムデータ連携 」をご参照ください Iceberg 形式での S3 書き込み ：キャプチャした変更データを Apache Iceberg 形式で Amazon S3 に書き込みます。データファイル（Parquet）とメタデータが S3 上に格納されます カタログでのメタデータ管理 ：Polaris Catalog に Iceberg テーブルのメタデータ（スキーマ情報、スナップショット履歴、パーティション情報など）が登録されます。分析エンジンはカタログを参照するだけでテーブルの構造と最新の状態を把握できます Snowflake からの分析クエリ ：Snowflake は Polaris Catalog を参照し、S3 上の Iceberg テーブルを Iceberg Tables として認識します。Fivetran が新しいデータを書き込むたびに Snowflake 側のテーブル情報が自動更新され、常に最新のデータに対してクエリを実行できます なお、CDC はデータ同期だけでなく、Snowflake 上の仕訳連携タスクの完了検知トリガーとしても活用しており、データ同期とパイプライン制御を一つの仕組みで兼ねています。 なお、S3 Tables ではなく S3 Standard を採用しています。これは、Fivetran の Iceberg 連携に必須となる Fivetran 管理の Polaris Catalog が、執筆時点で S3 Tables との統合に対応していないためです。S3 Tables の利用を検討される場合はこの点にご留意ください。 Fivetran 導入の効果 実際に Fivetran を導入した結果、山岡家が実感している効果は以下の通りです。 環境維持の負荷が低い 山岡家が最も評価しているポイントの一つです。維持すべきものは S3 バケットと Fivetran のデータカタログ環境のみであり、複数コンポーネントの監視・障害対応・バージョン管理が不要です。データエンジニアリングに専任チームを置かない組織でも無理なく運用できる構成になっています。 データ反映のレイテンシ Fivetran の CDC 機能により、会計仕訳データの変更が 約 5 分 で S3 上の Iceberg テーブルに反映され、Snowflake からクエリ可能になります。日々の仕訳入力から分析可能になるまでのタイムラグが大幅に短縮され、よりタイムリーな経営判断が可能になりました。 運用工数の大幅削減 Fivetran 導入後、データパイプラインの運用工数は月あたり約 0.5 日にまで削減されました。導入前は月あたり約 6 日の運用工数が発生していましたが、SaaS としてコンポーネントの監視・障害対応・バージョン管理が抽象化されたことで大幅に削減されています。 複数データソースの一元管理 Oracle の会計仕訳データ（CDC）に加えて SmartHR の人事データ（API 連携）も Fivetran 経由で連携しており、データ取得方式が異なるソースでも同一プラットフォームでデータパイプラインを管理できています。データソースが増えても Fivetran 上でコネクタを追加するだけで済むため、データ基盤の拡張が容易です。 ワークロードの規模感 採用を検討されている方の参考として、本パイプラインのワークロード規模を記載します。 # 項目 値 1 月間レコード数 約 20 万行 2 月間データサイズ 約 2 GB 3 日次平均レコード数 約 7,000 行 4 日次平均データサイズ 約 70 MB 5 ピーク（月初） 約 7,000 件 / 5 分 通常時は比較的少量のデータが継続的に連携されますが、月初の会計締め処理時にはバースト的にデータ量が増加します。Fivetran はこのようなピーク時にも安定して動作しており、レイテンシの悪化やエラーは発生していません。 今後の展望 今回の Fivetran CDC パイプラインは、山岡家のデータ基盤を発展させるための第一歩です。今後は既存の Snowflake 基盤を活かしつつ Iceberg の適用範囲を広げ、定型データがほぼすべて可視化された状態を目指していきます。 データ基盤の方向性：Snowflake + S3 Iceberg の併用 現状は Snowflake Internal Tables にデータを直接格納するケースが多くありますが、長期的にはデータ入力等にかかるコストとオープン性を見据え、活用できる箇所には Amazon S3 上の Apache Iceberg テーブルを採用していく方針です。Iceberg を採用する理由は主に 3 つあります。 Snowflake とのネイティブ連携 ：Snowflake が Iceberg テーブルをネイティブに参照できるため、既存の分析基盤との親和性が高い オープンフォーマットの拡張性 ：特定のエンジンにロックインされず、将来的に用途に応じた分析ツールを選択できる 運用の柔軟性 ：タイムトラベルやスキーマ進化といった機能により、データ管理の負荷を軽減できる S3 にデータを Iceberg 形式で集約しておくことで、Snowflake での分析に加え、将来的には他のサービスからもデータを活用できます。Snowflake 経由の分析についても、現在の Tableau に加え、Sigma BI や Streamlit など、用途に応じた分析ツールの活用を視野に入れており、データ活用の幅をさらに広げていく予定です。 まとめ 本記事では、山岡家が Fivetran の CDC 機能を活用して、RDS for Oracle から Amazon S3 上の Apache Iceberg テーブルへのデータ同期を実現した事例をご紹介しました。 当初は AWS のサービスを組み合わせたストリーミング CDC 構成も検討しましたが、複数コンポーネントの運用負荷を考慮し、Fivetran のマネージド CDC 機能を採用しました。その結果、約 5 分でのデータ反映、月あたりの運用工数を約 6 日から 0.5 日への削減、PoC から本番稼働まで約 1 ヶ月という短期導入を実現しています。 CDC × Iceberg on AWS の構成を検討されている方にとって、本記事がアーキテクチャ選定の一助となれば幸いです。 著者について 田中 陽里 株式会社丸千代山岡家 経営企画室 副室長 2023 年より現職。外食産業における DX を推進し、データドリブン経営を支えるデータ基盤の企画・構築を推進。 好きな AWS サービスは Amazon Elastic Container Service です。 大久保 裕太 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっています。IoT 領域が得意で、好きな AWS サービスは AWS IoT Core 。  

本ブログは 2026 年 4 月 3 日に公開された AWS Blog “ How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds ” を翻訳したものです。 大量のデータを暗号化する大規模なアプリケーションを運用している場合、暗号化限界の追跡や鍵のローテーションが課題になることがあります。この記事では、 AWS Key Management Service (AWS KMS) と AWS Encryption SDK が、派生鍵方式を用いて Galois Counter Mode の Advanced Encryption Standard (AES-GCM) の encryption limits (暗号化限界) や bounds (境界) を自動的に処理し、手動での管理を不要にする仕組みを説明します。これらの方式では、ランダムなノンスを使って、メインキー K から新しい派生鍵 K d を生成します。これにより、暗号化のたびに一意の鍵が使われるため、 K をはるかに長く使い続けられます。同様の派生鍵モードは、 (KC-)XAES 、 DNDK v2 、 ia.cr/2020/1153 など、最近のさまざまなスキームでも提案されています。 対称暗号化の境界 対称暗号化アルゴリズムは、転送中のデータと保管中のデータを大量に暗号化します。最新の暗号は、認証タグを使ってデータの認証も行います。これらは追加データ付き認証暗号 (AEAD) と呼ばれます。AEAD 暗号の例としては、AES-GCM や ChaCha20/Poly1305 があります。 AES-GCM は最も広く使われている暗号化アルゴリズムで、NIST によって SP 800-38D として標準化されました。AES-GCM は、128 ビットまたは 256 ビットの鍵 K と、初期化ベクトル ( IV 。通常は 96 ビット) を使って、平文 P を暗号化し認証します。また、追加認証データ ( AAD ) も認証します。出力は暗号文 C と認証タグ T です。 (C, T) = AES-GCM(K, IV, AAD, P ) 復号時には、受信者は K 、 IV 、 AAD を使って C を復号し、タグ T を検証します。タグの認証が成功すれば、元の平文 P が得られます。 暗号化呼び出し限界 データを暗号化するときには、鍵 K の使用期間中、 K, IV のタプルが繰り返されないことが極めて重要です。繰り返されると、AES-GCM のセキュリティ特性が失われてしまうためです。 SP 800-38D では、実装において鍵と IV が再利用される確率を 42.9 億分の 1 未満 (<2 -32 ) にすることが求められています。これは、繰り返されない決定論的な IV を使うか、ランダムな IV を使うことで達成できます。ランダムな IV を使う場合は、2 32 回の暗号化後に鍵を再生成する必要があります。たとえば、TLS や IKEv2/IPsec のような一般的なプロトコルでは、接続ごとに決定論的な (つまりランダムな値から始めてインクリメントする) IV を使うことで、( K, IV ) の衝突を防いでいます。 データ境界 ( K, IV ) の衝突確率が統計的に無視できる (<2 -32 ) と仮定しても、同じ鍵 K で大量の平文を暗号化するときには、依然としてデータ境界が存在します。AES-GCM のブロックカウンターは 32 ビットであるため、1 回の暗号化操作 (( K, IV ) のペアごと) あたり 2 32 -2 ブロック (68.72 GB) という限界が生じます。さらに、データの総量を制限しないと、攻撃者が 2 つの異なる平文を識別できる、つまり 2 つのメッセージのうちどちらが暗号文に暗号化されているかを判別できるようになり、セキュリティ保証が低下します。識別不可能性の保護を高めるほど、暗号化できるバイト総数は少なくなります。NIST の仕様 SP 800-38D では、単一の鍵 K で保護するデータの限界を 2 68 バイトと示しており、これは識別不可能性の確率 50% に相当します。さまざまな分析 ( ia.cr/2024/051 、 10.1145/3243734.3243816 ) に基づいて、より保守的なセキュリティマージンが使われることもあります。AWS もより保守的なマージンを設定しており、デフォルトでは無視できる程度の識別不可能性の確率 (<2 -32 ) を強制しています。 あるセキュリティマージンにおける AES-GCM のデータ境界に達したら、対称鍵をローテーションする必要があります。こうした限界 (たとえば、ランダムな IV を使った鍵あたり 2 32 回の暗号化や、鍵あたりの最大データ総量) には、最新の大規模な暗号化ユースケースで到達する可能性があります。多数の同時セッションを持つ分散システム全体でこれらの限界を追跡すると、運用上の複雑さが増します。AWS では、AWS の規模で AES-GCM を使う際のこうした課題を、 2023 年に開催された NIST の第 3 回 Workshop on Block Cipher Modes of Operation での 解説資料 と プレゼンテーション で共有しました。 AWS KMS が派生鍵を使う仕組み AWS KMS は、データの暗号化と署名に使う鍵を作成し制御できるマネージドサービスです。AWS KMS Encrypt API は、対称暗号化と非対称暗号化をサポートしています。対称鍵暗号化の場合、AWS KMS は 256 ビットの鍵を使った AES-GCM を用いて、最大 4 KB のサイズの平文を暗号化します。AWS KMS リクエストには、平文と、KMS に保管されている対称カスタマーマネージドキー (CMK) の対称鍵識別子 ( KeyId ) が含まれます。 AWS KMS への対称鍵 Encrypt API コールでは、平文を暗号化する前に CMK を使って対称暗号化鍵を派生させます。AWS KMS は、ランダムな 128 ビットのノンス N を生成し、鍵導出関数 (KDF) を使って、 KeyId で指定されたメインキー K から 256 ビットの対称鍵を生成します。KDF は、鍵、ラベルとコンテキスト、呼び出し固有のノンス N 、そしてバイト単位の出力長 L Km を入力として受け取り、その長さの鍵マテリアルを K mat = KDF(K, <label>, <context>, N, L Km ) として生成します。 <label> は通常、アプリケーション固有または呼び出し固有の値です。 <context> には呼び出し固有の入力が含まれます。AWS KMS の場合、KDF 関数は NIST SP 800-108r1 Counter Mode KDF で、擬似ランダム関数として HMAC-SHA256 を使って 256 ビットの鍵マテリアルを生成します。 K d は基本的に、鍵 K を使った 1 回の HMAC-SHA256 呼び出しで次のように生成されます。 K d = HMAC-SHA256(K, <ctx>) ここで <ctx> は、カウンター値と定数および N を連結したものです。 続いて、AWS KMS は 96 ビットのランダムな IV を生成し、入力された平文 P を AES-GCM で (C, T) = AES-GCM(K d , IV, AAD, P) として暗号化します。 AWS KMS は、 IV 、ノンス N 、暗号文、タグ ( C,T ) を含む CiphertextBlob を返します。これにより、後続の Decrypt API への呼び出しで CiphertextBlob を復号できます。 直感的に言うと、CMK のもとで暗号化鍵を派生させるために使われる 128 ビットのランダムなノンスにより、呼び出し元は CMK のもとで実行できる暗号化回数の 2 32 限界をはるかに超えられます。さらに、AWS Encrypt 呼び出しのペイロードサイズに対する 4 KB の限界により、暗号化鍵のもとで暗号化されるデータの総量は、NIST やその他のより保守的な暗号化データ総量の上限（境界）をはるかに下回るよう保たれます。このスキームのセキュリティ基盤に関する詳細と数学的な背景については、 Key Management Systems at the Cloud Scale を参照してください。 AWS Encryption SDK が呼び出しごとに派生鍵モードを適用する仕組み AWS Encryption SDK は、データの暗号化と復号に使われるクライアント側の暗号化ライブラリです。複数のペイロードを暗号化するときに API コールを減らすため、データキーキャッシュを使うように設定できます。AES-GCM の暗号化呼び出しごとにノンスベースの派生鍵を使うことで、単一のデータキーのもとで暗号化するデータの総量を追跡する必要がなくなります。 AWS Encryption SDK は多くの暗号化シナリオに対応する柔軟性を備えていますが、デフォルト設定では鍵導出とフレームサイズの設定を自動的に処理するため、ほとんどのユースケースでこれらの設定を調整する必要はありません。AWS KMS と同様に、呼び出しごとに異なる鍵を派生させるために、ランダムに生成された値 N 、メインキー K 、そして KDF 内の呼び出し固有のコンテキストを使います。 N はデフォルト設定では 256 ビットです。基盤となる KDF は、デフォルトのハッシュとして SHA512 を使う HMAC ベースの抽出展開鍵導出関数 (HKDF) です。 K d は基本的に、鍵 K を使った 1 回の HKDF 呼び出しで次のように生成されます。 K d = HKDF(K, salt=<lbl>, info=<ctx>, 32) ここで <lbl> は定数であり、 <ctx> はデフォルト設定では定数とランダムな 256 ビットの値を連結したものです。 続いて、AWS Encryption SDK は派生鍵 K d を使って、デフォルトでは 4 KB のフレームに分割されたユーザーコンテンツを暗号化します。各フレームの平文 Pf は、決定論的な IV を使った AES-GCM で (C, T) = AES-GCM(Kd, IV, AAD, Pf) として暗号化されます。 96 ビットの決定論的な IV は、フレームカウンター frameID で構成され、 frameID <2 32 です。追加認証データ AAD は Encryption SDK のデータフレームに固有 です。復号時には、受信者は同じ方法で K から K d を派生させ、暗号文 C を復号してフレームの平文 Pf を生成し、認証タグ T を検証します。 4 KB のフレームサイズにより、デフォルトでは単一の暗号化鍵のもとで暗号化できるデータは 2 44 バイト (各 4 K バイトの 2 32 フレーム) を超えないことが保証されます。これは、データキーキャッシュを使った場合でも、NIST が示す境界 (2 68 ) をはるかに下回ります。また、AWS の保守的な要件である <2 -32 の識別不可能性の確率もはるかに下回ります。鍵あたりの呼び出し回数の限界は、データキーキャッシュを使った場合でも、ほとんどの大規模アプリケーションの暗号化回数を上回ります。 注: AWS Encryption SDK はデフォルト設定で保守的な選択をしていますが、 レガシーのバージョン 1.0 を使っている場合や設定を変更している場合は、セキュリティ保証が低くなる可能性があります。たとえば、2 32 -1 バイトというカスタムで最大化したフレームサイズを使うと、平文の合計サイズが大きくなります。これは NIST が示す限界 2 68 は下回りますが、その他の保守的な境界は下回りません。 なお、デフォルトの AWS Encryption SDK 設定は、 鍵コミットメント のような、あまり知られていないセキュリティ特性も提供します。 コミットメント文字列 は、 K と HKDF を使って、派生鍵と同様に生成されます。 まとめ 暗号化呼び出しごとに一意の鍵を派生させることで、AWS KMS と AWS Encryption SDK は、AES-GCM の限界を手動で追跡する必要をなくします。 AES-GCM の境界に関する学術的な根拠については、 SP 800-38D と draft-irtf-cfrg-aead-limits を参照してください。KMS で使われる鍵導出スキームの暗号解析についてさらに詳しく知りたい場合は、 Key Management Systems at the Cloud Scale を参照してください。Encryption SDK の AES-GCM 鍵導出の詳細については、 AWS Encryption SDK algorithms reference を参照してください。 この記事に関するご質問がある場合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせ ください。   Panos Kampanakis Panos は AWS の Principal Security Engineer です。サイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理の経験があります。サイバーセキュリティに関する出版物を共著し、セキュリティ情報共有、暗号、公開鍵基盤のための共通かつ相互運用可能なプロトコルや言語を提供すべく、さまざまなセキュリティ標準化団体に参加してきました。現在は、エンジニアや業界パートナーと協力して、暗号学的に安全なツール、プロトコル、標準の提供に取り組んでいます。 Matt Campagna Matthew は Amazon Web Services の Cryptographer 兼 Sr. Principal Engineer です。社内全体の暗号ソリューションの設計とレビューを管理し、ポスト量子暗号への移行を主導しています。余暇には、シアトルで完璧なコリアンフライドチキンを探し求めています。 Patrick Palmer Patrick は AWS の Principal Security Specialist Solutions Architect です。世界中のお客様が AWS サービスを安全に使えるよう支援しており、暗号を専門としています。仕事以外では、増えつつある家族と過ごしたり、ビデオゲームをプレイしたりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

お知らせ 2026年7月からオンラインでサーバーレスに関するワークショップを4件開催します。ぜひ、ご参加ください。 7/7 10:00〜12:00 Kiroによるサーバーレス開発 7/9 10:00〜12:00 イベント駆動アーキテクチャ・アプリケーションの構築 7/14 10:00〜12:00 AWS Lambda durable functions によるコード型ワークフロー 7/16 10:00〜12:00 AWS Lambda マネージドインスタンス 本記事は、2026 年 1 月 30 日に公開された Serverless ICYMI Q4 2025 を翻訳したものです。翻訳は Solutions Architect の 齋藤 拓巳 が担当しました。 最新のサーバーレスイノベーションを把握して、アプリケーションの変革に役立てましょう。 この第 31 回四半期レビューでは、2025 年第 4 四半期に発表された、見逃しているかもしれない AWS サーバーレスの重要なリリース、機能、リソースをご紹介します。 前回の ICYMI を見逃した方は、 2025 年第 3 四半期 の内容をご確認ください。 2025 年第 4 四半期カレンダー re:Invent 2025 におけるサーバーレス この記事では、re:Invent 2025 で発表された主要なサーバーレス関連のアナウンスを取り上げ、アプリケーションの改善に役立つ重要な機能アップデートを紹介するとともに、最新情報を把握するための有用なリソースを共有します。 AWS re:Invent 2025 には 60,000 人以上が現地参加し、基調講演には 200 万人以上のオンライン視聴者が集まりました。 イベントでは 3,000 人のスピーカーによる 3,500 のセッションが開催され、530 の AWS サービスおよび機能のアナウンスに関する情報が紹介されました。 基調講演 サーバーレスムーブメントの火付け役 サーバーレス関連のコンテンツは、Containers and Serverless (CNS) と Application Integration (API) の 2 つのトラックで構成されていました。 これらのトラックでは 150 種類のセッションが開催され、16,000 人を超える参加者が現地で視聴しました。 開発者向けの体験として、 Road to re:Invent Hackathon 、AWS Builder Loft、Builders Arena が用意されていました。 サーバーレステクノロジーで運営されるコーヒーショップ Serverlesspresso は、イベント期間中、Expo Hall と認定資格ラウンジの 2 か所で営業していました。 サーバーレスおよび開発者コミュニティの写真 厳選されたサーバーレス動画のリストは Serverless Land YouTube でご覧いただけます。 AWS Lambda durable functions マルチステップのサーバーレスワークフローにおける状態管理には、従来、複雑な外部オーケストレーションツールが必要でした。 AWS Lambda の durable functions は、開発者が Lambda を活用する方法を拡張します。 信頼性の高いマルチステップのアプリケーションや AI ワークフローを Lambda 内で直接構築できるようになりました。 AWS Lambda durable functions のコード durable functions は、実行中の重要なポイントで現在の状態と完了したステップを保存することで、自動的に進捗のチェックポイントを保存します。 これにより、長時間実行されるタスク中に最大 1 年間実行を一時停止でき、障害が発生した場合も最初からやり直すのではなく最後のチェックポイントから再開して復旧できます。しかも追加のインフラストラクチャ管理は一切不要です。 開発者は Python または TypeScript で構築し、自動リトライとチェックポイント機能を備えたステップで呼び出しをラップできるようになりました。 wait を使用すると、アイドル状態のコンピューティングに課金されることなく、数分、数時間、最大 1 年間まで実行を一時停止できます。 durable functions はリプレイメカニズムを使用して状態を維持し、障害を適切に処理します。 このメカニズムは、障害からの復旧時にチェックポイントから関数コードを再実行することで動作し、データを失うことなく状態の一貫性を確保します。 これにより、多くのユースケースで複雑な外部オーケストレーションツールが不要になります。 外部インフラストラクチャを管理することなく信頼性の高い状態管理が必要な AI ワークフローやマルチステップアプリケーションに特に役立ちます。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画をご覧ください: Deep Dive on AWS Lambda durable functions (CNS380) AWS Lambda Managed Instances Lambda は、 Lambda Managed Instances という新しいコンピューティングオプションを提供開始しました。これは Amazon EC2 の柔軟性とフルマネージドインフラストラクチャを組み合わせたものです。 AWS がインスタンスのプロビジョニング、スケーリング、メンテナンスを自動的に処理しながら、Graviton4、ネットワーク最適化インスタンス、その他の特殊なコンピューティングオプションを含む EC2 の幅広い機能にアクセスできます。 AWS Lambda Managed Instancesの設定 関数は、お客様のアカウントの専用 EC2 キャパシティ上で、お客様自身の Amazon Virtual Private Cloud (Amazon VPC) 内で実行されます。 OS パッチ適用、ロードバランシング、オートスケーリングなどの運用オーバーヘッドは引き続き AWS が管理します。 これにより、サーバーレスの運用モデルを維持しながら、特殊なハードウェアオプションにアクセスできます。 Compute Savings Plans や Reserved Instances などの EC2 料金モデルを Lambda ワークロードに活用することで、コストをさらに最適化できます。 各インスタンスは複数の同時リクエストを処理できるため、予測可能な料金体系と特定のハードウェア要件が重要な、大量かつ定常的なワークロードに特に適しています。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画 Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382) をご覧ください。 その他の Lambda に関する発表 マルチテナント SaaS アプリケーションには、テナント間のデータ漏洩や、あるテナントのワークロードが他のテナントに影響を与えるノイジーネイバー問題といった課題があります。 また、カスタムの分離メカニズムの実装にも苦労してきました。 テナント分離モード は、テナントごとに個別の実行環境で関数の呼び出しを処理することで、これらの課題に対処します。 これにより、テナントレベルのコンピューティング環境の分離が自動的に管理されます。 AWS Lambda tenant isolation Lambda は Amazon SQS イベントソースマッピングに Provisioned Mode を追加しました。これにより、高スループットの SQS 処理ワークロードにおいて、予測可能なパフォーマンスとコールドスタートの削減を実現します。 非同期 Lambda 呼び出しで 最大 1 MB のデータを送信 できるようになりました。 従来の 256 KB から引き上げられ、より複雑なデータ処理シナリオの構築が可能になります。 Lambda 関数は IPv6 ネットワーキング をサポートするようになったため、VPC に接続された関数からインターネットや他の AWS サービスにアクセスする際に NAT Gateway が不要になりました。 NAT Gateway を介した Lambda のインターネット接続 (IPv4) と、Egress-Only インターネットゲートウェイを介した Lambda のインターネット接続 (IPv6) です。 Lambda の Rust サポート が一般提供 (GA) になり、実験的ステータスから移行しました。 これは AWS サポートおよび Lambda の可用性 SLA の対象となります。 Lambda は、 Python 3.14 、 Node.js 24 、 Java 25 をマネージドランタイムおよびコンテナベースイメージとして追加し、ランタイムサポートを拡充しました。 これにより、最新の言語機能を利用でき、長期サポートも確保されます。 Amazon ECS Amazon Elastic Container Service (Amazon ECS) Express Mode は、従来開発者の作業を遅らせていたインフラストラクチャのセットアップを自動化することで、コンテナ化されたアプリケーションのデプロイと管理を効率化します。 Amazon ECS Express Mode デプロイメント これにより、AWS のベストプラクティスを活用して自信を持ってデプロイしながら、アプリケーションの構築に集中できます。 Express Mode では、単一のコマンドで本番環境対応のコンテナ化された Web アプリケーションと API をデプロイできます。 シンプルな API を通じて、ドメイン、ネットワーキング、ロードバランシング、 AWS Identity and Access Management (IAM) ロール、オートスケーリングが自動的に処理されます。 アプリケーションが進化し、高度な機能が必要になった場合は、Amazon ECS を含むリソースのすべての機能をシームレスに設定してアクセスできます。 詳細については、 発表ブログ記事 をご覧ください。 Amazon ECS は、AI を活用した開発・運用体験を実現するフルマネージド型の MCP サーバー のパブリックプレビューを発表しました。 この Model Context Protocol (MCP) サーバーは、自動更新とパッチ適用、AWS IAM 統合による一元的なセキュリティ管理、 AWS CloudTrail を通じた包括的な監査ログ、そして AWS が実証済みのスケーラビリティ、信頼性、サポートといったエンタープライズグレードの機能を提供します。 Amazon Elastic Container Registry (ECR) の マネージドコンテナイメージ署名 は、セキュリティ体制を強化し、署名のセットアップにかかる運用上のオーバーヘッドを排除します。 コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。 ECR は、イメージがプッシュされる際に、プッシュしたエンティティの ID を使用して自動的にイメージに署名します。 署名操作は CloudTrail を通じてログに記録されるため、完全な監査が可能です。 Amazon API Gateway Amazon API Gateway では、レスポンスペイロードをクライアントに 段階的にストリーミング することで、REST API の応答性を向上させることができます。 この新機能により、ストリーミングレスポンスを使用して、LLM 駆動のアプリケーション (AI エージェントやチャットボットなど) を構築する際のユーザーエクスペリエンスの向上、Web およびモバイルアプリケーションの Time-to-First-Byte (TTFB) パフォーマンスの改善、大容量ファイルのストリーミング、 Server-Sent Events (SSE) などのプロトコルを使用した増分的な進捗報告を伴う長時間実行オペレーションの実行が可能になります。 Amazon API Gateway streaming API Gateway は、 Application Load Balancer (ALB) との プライベート統合 を導入しました。 これにより、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API を通じて安全に公開できます。 API エンドポイントやカスタムドメイン名に 強化された TLS セキュリティポリシー を設定できるようになり、API のセキュリティ体制をより細かく制御できるようになりました。 Amazon EventBridge Amazon EventBridge に、カスタムアプリケーションや 200 以上の AWS サービスからのイベントを開発者が発見しサブスクライブできる 拡張ビジュアルルールビルダー が導入されました。 このコンソールベースのインターフェースは、EventBridge の スキーマレジストリ と包括的なイベントカタログ、直感的なドラッグアンドドロップキャンバスを統合し、イベント駆動型アプリケーションの構築を簡素化します。 開発者は、個々のサービスのドキュメントを探し回ることなく、すぐに利用可能なサンプルペイロードやスキーマを使ってイベントを閲覧・検索できます。 スキーマ対応のビジュアルビルダーが、イベントフィルターパターンやルールの作成をガイドし、構文エラーを削減して開発時間を短縮します。 EventBridge では、 SQS フェアキュー をターゲットとして指定することもできます。 AWS Step Functions AWS Step Functions では、 TestState API を通じて強化されたローカルテストが可能です。 AWS にデプロイすることなく、包括的なテスト機能にプログラムからアクセスできます。 これにより、開発マシン上でワークフロー定義をローカルに検証する自動テストスイートを構築できます。 お好みのテストフレームワークを使用して、エラーハンドリングパターン、データ変換、モックサービス統合をテストしましょう。 また、新しい メトリクスダッシュボード も追加され、アカウントレベルとステートマシンレベルの両方でワークフローの運用状況を可視化できるようになりました。 その他の発表 Savings Plans の柔軟な料金モデルが、 Database Savings Plans のローンチにより AWS マネージドデータベースサービスにも拡張されました。 1 年間の一定量の使用量 ($/時間) をコミットすることで、データベースコストを最大 35% 削減できます。 割引は毎時間、対象のデータベースサービス全体の適格な使用量に自動的に適用され、コミットメントを超える追加使用量はオンデマンド料金で課金されます。 Amazon DynamoDB が グローバルセカンダリインデックスでの複数属性複合キー をサポートするようになりました。 これまでは値を手動で連結して合成キーを作成する必要があり、新しいインデックスを追加する前にデータのバックフィルが必要になることもありました。 今後は、最大 8 つの既存属性を使用してプライマリキーを作成できるため、多様なアクセスパターンのモデリングや新しいクエリ要件への対応が容易になります。 Amazon Bedrock は、信頼性の高い AI エージェントを大規模にデプロイするための 品質評価とポリシーコントロールを備えた AgentCore を発表しました。 Bedrock には 18 のフルマネージドオープンウェイトモデル も追加され、開発者が利用できる AI モデルの選択肢が拡大しました。 Strands Agents SDK は、モデル駆動型のアプローチで AI エージェントをわずか数行のコードで構築・実行できるオープンソースフレームワークです。 TypeScript のサポートがプレビューとして 利用可能になり 、Strands Agents の構築に Python と TypeScript のどちらかを選択できるようになりました。 Amazon S3 Vectors が一般提供開始となりました。 S3 Vectors は、AI エージェント、推論、検索拡張生成 (RAG)、セマンティック検索を数十億ベクトル規模で実現する、専用設計されたコスト最適化済みのベクトルストレージを提供します。 サーバーレスに関するブログ記事 10 月 モノリスワークフローの分解: AWS Step Functions ワークフローのモジュール化 AWS Serverless MCP Server での AWS Lambda イベントソースマッピングツールの紹介 AWS Step Functions Distributed Map S3 プレフィックスを使用した Amazon S3 オブジェクトの大規模処理 11 月 AWS Lambda の IPv6 ネットワーキング AWS Step Functions Distributed Map によるビッグデータ処理のオーケストレーション AWS Step Functions Distributed Map を使用したネストされた JSON 配列処理の最適化 新しい Amazon API Gateway Portal で API の見つけやすさを向上させる Amazon API Gateway レスポンスストリーミングでレスポンシブな API を構築する AWS Lambda で Python 3.14 ランタイムが利用可能になりました AWS Lambda 上で Rust を使用したサーバーレスアプリケーションの構築 非同期 AWS サービスを AWS Step Functions ステートマシンと統合する際に、予測不能な処理時間を運用の一貫性を保ちながら処理する AWS Lambda が Java 25 をサポートしました Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化 Kafka 向けサーバーレスストリーミングワークロードのスループット向上 Amazon API Gateway と Application Load Balancer のプライベート統合を使用してスケーラブルな REST API を構築する LLM レスポンスのストリーミングにおけるサーバーレス戦略 AWS Lambda の新しいテナント分離モードを使用したマルチテナント SaaS アプリケーションの構築 AWS Step Functions と Amazon Bedrock バッチ推論による大規模ドキュメント処理のオーケストレーション AWS Lambda で Node.js 24 ランタイムが利用可能になりました Serverless Office Hours 毎週火曜日の午前 11 時 (太平洋時間) に開催されるライブストリームにぜひご参加ください。サーバーレステクノロジーに関するライブディスカッション、Q&A セッション、深掘りセッションを行っています。 エピソードは serverlessland.com/office-hours でオンデマンドでもご視聴いただけます。 10 月 10 月 7 日 – Amazon API Gateway Routing Rules 10 月 14 日 – Amazon DynamoDB Global Tables 10 月 21 日 – Building agents with Amazon Bedrock AgentCore 10 月 28 日 – What’s new with Observability 11 月 11 月 4 日 – AI 仕様を正しく定義する！ 11 月 11 日 – AWS Lambda で Swift を実行する 11 月 18 日 – EventCatalog の最新情報 11 月 24 日 – pre:Invent 2025 12 月 12 月 9 日 – AWS Lambda Managed Instances 12 月 16 日 – AWS Lambda durable functions さらに詳しく知りたい方へ サーバーレスのランディングページ には、サーバーレスアプリケーションの構築に関する全般的な情報があります。 Lambda リソースページ には、ケーススタディ、ウェビナー、ホワイトペーパー、お客様事例、リファレンスアーキテクチャ、さらに多くの入門チュートリアルが掲載されています。 Serverless Developer Advocacy チームをフォローして、最新ニュースの確認、会話のフォロー、チームとの交流もできます。 Julian Wood: @julian_wood , https://www.linkedin.com/in/julianrwood/ Eric Johnson: @edjgeek , https://www.linkedin.com/in/singledigit/ Gunnar Grosch: @GunnarGrosch , https://se.linkedin.com/in/gunnargrosch Erik Hanchet: @ErikCH , https://www.linkedin.com/in/erikhanchett/ Salih Gueler: @salihgueler , https://www.linkedin.com/in/salihgueler/ Marcia Villalba: @mavi888uy , https://www.linkedin.com/in/marciavillalba 最後に、サーバーレスに関するあらゆる情報については Serverless Land をご覧ください。

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの多田です。2026 年 5 月 29 日に、大阪オフィスにて「AWS Business Innovation Series – West Japan」の第 2 回を開催いたしました。本シリーズは、西日本のお客様のデジタル変革を加速することを目的に、生成 AI を活用した実践的なプログラムを約 3 ヶ月に 1 回のペースでお届けしているものです。ご参加いただいた皆様に、改めて御礼申し上げます。 本ブログでは、イベントの背景や当日の様子、参加者の皆様からいただいた声をお届けいたします。 はじめに 本シリーズは 2025 年に関西を中心に開催したワークショップの高い満足度を受けて、2026 年は業界を問わず幅広い企業の皆様にご参加いただける形で継続しています。約 3 ヶ月に 1 回のペースで年 4 回の開催を予定しており、今回がその第 2 回です。第 2 回では、さらに一歩進んで Amazon Quick をテーマに選びました。 Amazon Quick は、Slack・メール・カレンダー・ファイルなど業務で使う多様なデータソースに接続し、AI アシスタントが業務のコンテキストを深く理解した上でアクションまで実行できるツールです。チャットエージェント、ワークフロー自動化、リサーチなど幅広い機能を備えていますが、今回はデータ接続とチャットエージェント構築にフォーカスしました。「AI ツールは気になるけれど、自分の業務にどう活かせるかイメージが湧かない」「社内のデータを活用したいけれど、どう繋げればいいかわからない」――そんな方々に、半日でデータ接続からエージェント構築までを体験していただくことが今回のイベントの狙いでした。 過去開催分についてはこちらをご覧ください。 第 1 回：お試しから卒業！Kiro の仕様駆動開発を本格活用（2026/3/17） イベント概要 項目 内容 テーマ データから業務アクション、展開まで繋げる Amazon Quick ワークショップ 日時 2026 年 5 月 29 日（金）13:00〜18:00（懇親会 18:00〜） 場所 アマゾン ウェブ サービス ジャパン 大阪オフィス（中之島三井ビルディング 26F） 参加者 20 社 34 名 満足度 4.11 / 5 タイムテーブル 時間 内容 13:00 – 13:10 オープニング 13:10 – 13:30 座学：AI アシスタントは あなたの仕事の何割を見ていますか？ ― Why Quick 13:30 – 14:50 Amazon Quick ハンズオン ~ HR Agentを作ってみよう 14:50 – 15:00 休憩 15:00 – 17:30 Amazon Quick ハッカソン ~ ビジネス貢献できるチャットエージェントを作ろう 17:30 – 17:50 LT：あなたの業務、アプリにしませんか？ 17:50 – 18:00 クロージング 当日の様子 座学：AI アシスタントは あなたの仕事の何割を見ていますか？ ― Why Quick 発表資料： AI アシスタントは あなたの仕事の何割を見ていますか？ ― Why Quick 最初のセッションでは、「AI に何ができるか」ではなく「AI があなたの仕事のどれだけを見ているか」という問いからスタートしました。私たちは日常業務で、コミュニケーションツール(メール / Teams / Slack など)、コラボレーションツール(Box / SharePoint など)、社内システム、SaaS、Web といった 5 つの階層のデータソースを無意識に行き来して判断しています。一方で多くの AI ツールが見ているのはそのうち 1〜2 階層だけ ― このギャップが AI 活用の天井を決めているという構造を整理しました。さらに、データに繋がった先で「探せる → 見渡せる → わかる → 動ける」の 4 象限を回すことが重要であり、Amazon Quick はその全体をカバーする設計であることをお伝えしました。まずは小さく検証し、効果が見えたら利用者を広げていくというアプローチを紹介し、後半のハンズオン・ハッカソンへの橋渡しとしました。 Amazon Quick ハンズオン ~ HR Agent を作ってみよう ハンズオンでは、架空の人事課題 ―「直近 1 年で離職率が上昇傾向にある。散在する従業員データを活用し、離職可能性の高い従業員を早期に特定してリテンション施策を打てる仕組みを構築してほしい」― をミッションに設定しました。参加者は以下の 4 つの練習を通じて、段階的にデータ接続の深さを体験しました。 Chat で触ってみよう ― ドキュメントをアップロードして自然言語で Q&A。手軽さを体験する一方、毎回のアップロードが必要で、チームで共有しにくい限界も実感。 Space を作ろう ― 非構造化データ（社員フィードバックレポート、オンボーディングチェックリスト）を永続的なナレッジベースとして統合。他ユーザーへの共有も可能に。 構造化データと接続しよう ― S3 上の従業員マスタ テーブルをデータソースとして接続し、自然言語で「部門ごとの平均満足度は？」と分析。非構造化データと統合して横断分析可能な状態を構築。 HR Agent を作ろう ― Chat Agent を作成し、構造化データ（数値・フラグ）と非構造化データ（評価コメント・退職面談記録）を組み合わせた離職リスク分析を実施。単なるダッシュボードでは得られない、文脈を踏まえた多角的な分析を体験。 Amazon Quick ハッカソン ~ ビジネス貢献できるチャットエージェントを作ろう ハンズオンで基本操作を習得した後は、個人ハッカソンです。ゴールは「ビジネスに役立つチャットエージェントを作る」こと。参加者は以下のステップで進めました。 テーマ設計 ― Amazon Quick からの質問に答えながら、自社ビジネスに貢献できるエージェントのテーマを決定 チャットエージェント作成 ― ハンズオンの手順を応用してエージェントを構築 評価エージェント作成 ― 作ったエージェントの品質を評価する仕組みも構築 反復改善 ― 評価結果をもとにプロンプトやデータを改善 提案資料作成 ― Amazon Quick を使って導入提案の PPTX を自動生成し、自社に持ち帰れる成果物に グループ内発表 ― 成果を共有 LT：あなたの業務、アプリにしませんか？ 発表資料： あなたの業務、アプリにしませんか？ ハッカソンの興奮冷めやらぬ中、LT（ライトニングトーク）では「あなたの業務、アプリにしませんか？」と題して、Amazon Quick のアプリ機能「Quick Apps (プレビュー)」をご紹介しました。ハンズオン・ハッカソンで体験したチャットエージェントに加え、Quick には自然言語で Web アプリを作成できる機能もあります。定型業務をアプリ化し、Publish & Share でチームや組織に展開できる ― 個人の武器を組織の力に変えるもう一つのアプローチをお伝えしました。 参加者の声 参加者アンケートからいくつかの声をご紹介します。 「資料・説明ともにわかりやすかったです。SA の方も楽しく教えてくれて良かったと思いました。」 「持ち帰れるモノが多く、有意義な時間でした。」 「Quick を使っているつもりでしたが、全然足りませんでした。他の人の使い方をみるのは非常に重要です。」 「業務アプリが一通り構築できそうです。」 「Quick の利点について、データ連携先が豊富であること、BI ツールと統合した UI が作成可能であることが、既存のチャット型 AI エージェントにない利点だと理解しました。」 まとめ 第 2 回「AWS Business Innovation Series – West Japan」では、Amazon Quick をテーマに、座学で「AI が見ている世界」の構造を理解し、ハンズオンで Chat → Space → データソース接続 → Agent 作成を段階的に体験し、ハッカソンでは自社課題をもとにエージェントと導入提案資料を作り上げる ― データから業務アクション、そして展開までを一気通貫で体験いただくプログラムとなりました。 普段コードを書かない方々も含め、参加者の皆様が半日で実際に動くエージェントと導入提案資料を作り上げる姿は非常に印象的でした。 ご興味のある方は、担当のアカウントチームまでお気軽にお問い合わせください。皆様のご参加をお待ちしております。 本ブログは、ソリューションアーキテクトの多田 慎也が執筆いたしました。

本記事は 2026 年 4 月 17 日 に AWS Migration & Modernization Blog で公開された「 Modernize VB6 Applications at Scale with AWS Transform Custom  」を翻訳したものです。 想定所要時間 : 90 〜 120 分 レベル : 上級 (400) Microsoft は Visual Basic 6.0 (VB6) の延長サポートを 2008 年に終了 (*) しましたが、金融サービス、保険、ヘルスケア、製造業など、数千ものミッションクリティカルなアプリケーションが依然として VB6 に依存しています。これらのアプリケーションには数十年分のビジネスロジックが含まれていますが、年々メンテナンスが困難になっています。VB6 開発者は労働市場に残る人数が減少しているため採用コストが上昇し、パッチ未適用の脆弱性はコンプライアンス違反のリスクを高め、モノリシックなアーキテクチャは AI、アナリティクス、クラウドサービスとの統合を困難にしています。 * 訳注：厳密には、VB6 の IDE のサポートは終了してますが、VB6 のランタイムはまだサポートはされています。ランタイムは Windows のライフタイムに合わせてサポート継続されていますが、対応は重大なセキュリティ問題等に限定されています。詳細は こちら を参照してください。 これらの課題は、AWS Transform custom でカスタム変換プランを作成することで解決できます。 この記事では、AWS Transform custom のエージェンティック AI 機能を活用して、組織固有のビジネスルールを維持しながら VB6 アプリケーションを大規模にモダナイズする方法を紹介します。 VB6 モダナイゼーションの課題 VB6 アプリケーションのモダナイゼーションには、単純な構文変換を超えた固有の課題があります。 AWS Transform for .NET  は .NET Framework アプリケーションの自動ポーティングを提供していますが、VB6 には固有の特性があるため、異なるアプローチが必要です。 VB6 のモダナイゼーションでは、レガシープラットフォームとモダンな .NET の間にある根本的なアーキテクチャの違いに対処する必要があります。言語レベルでは、VB6 の手続き型および COM ベースのパターンをオブジェクト指向の C# 構造にマッピングする必要があります。ユーザーインターフェースも、ActiveX コントロールを使用した VB6 フォームから Blazor や ASP.NET Core MVC などのモダンな Web フレームワークへの変換が必要です。データアクセスパターンはレガシーな ADO や DAO から Entity Framework Core の async/await パターンに移行し、COM 依存関係は .NET ネイティブの代替手段や NuGet パッケージに置き換える必要があり、エラーハンドリングは On Error Resume Next や On Error GoTo パターンから構造化された try-catch 例外処理に移行します。 サンプルアプリケーションの紹介 Salmon King Seafood (SKS)  という VB6 Multiple Document Interface (MDI) アプリケーションを使って AWS Transform custom を解説します。これは典型的なエンタープライズモダナイゼーションの課題を表すアプリケーションです。SKS は以下の特徴を持つ水産物受注管理システムです。 15 以上の VB6 フォーム – 受注、顧客管理、商品カタログ、在庫管理、承認ワークフローを含む 3 つの VB6 モジュール (modConnection.bas、modFunctions.bas、modMain.bas) – 共有ビジネスロジックとデータベース接続を含む SQLite データベース (Orders.db) – ADO データコントロールとデータバインディングを通じてアクセス 標準 VB6 コントロール – MSFlexGrid、ListView、Toolbar、ImageList、ComboBox、Control Arrays を含む MDI アーキテクチャ  – メインコンテナフォームとメニューからトリガーされる子フォーム このアプリケーションは、エンタープライズアプリケーションでよく見られる VB6 パターンを実装しています。 イベントハンドラを持つフォームベースの UI データバインディングを使用した ADO データアクセス COM ベースのコントロール モジュール内の手続き型ビジネスロジック これらの要素により、SKS はエンタープライズ VB6 モダナイゼーションで遭遇する複雑さを代表するものとなっています。 ソリューション概要 VB6 から C# へのモダナイゼーションには、AWS Transform custom の複雑な変換パターンの学習・適用機能を活用できます。エンドツーエンドのプロセスは以下のステージに従います。 評価 – VB6 アプリケーションポートフォリオのスコープと複雑さを評価する 定義 – VB6 から C# への変換パターン、ビジネスルール、コーディング標準を含むカスタム変換を定義する 実行 – 大規模に変換を実行する レビューと反復 – フィードバックループによる継続的な改善を行いながらレビューと反復を行う このアーキテクチャにより、変換定義を一度作成してテストし、数百のアプリケーションに適用できます。 前提条件 開始する前に、以下を確認してください。 AWS Transform Custom へのアクセス権を持つ AWS アカウント 。現在の料金の詳細については、AWS Transform の料金ページをご覧ください。 ATX CLI (Command Line Interface) がインストールされた MacOS または Linux 環境。詳細なセットアップ手順については、 AWS Transform custom 前提条件ガイド を参照してください。 **Windows 開発者の場合** : WSL2 (Windows Subsystem for Linux) をインストールし、Ubuntu またはその他の Linux ディストリビューションから ATX CLI を実行してください。CLI は `/mnt/c/` パスを通じてローカルコードベースを直接操作します。 変換後のアプリケーションをテストするための .NET 10 SDK 以降 コードレビュー用の Visual Studio 2022 以降または Visual Studio Code VB6 および .NET の開発知識 有効な認証情報が設定されている Git があること 環境の準備 Salmon King Seafood (SKS)  サンプルアプリケーションをダウンロードします。これには、典型的なエンタープライズ VB6 ワークロードを代表する VB6 MDI アプリケーションが含まれています。 リポジトリをローカルマシンにクローンします。 git clone https://github.com/GAPVelocityAI/SKSVB6.git  cd SKSVB6  Windows で WSL2 を使用している場合は、両方の環境からアクセス可能なパスにクローンします。 git clone https://github.com/GAPVelocityAI/SKSVB6.git /mnt/c/Projects/SKSVB6  cd <path-to-repository>  リポジトリの内容を確認します。VB6 プロジェクトファイル (SKS.vbp)、フォームファイル (.frm/.frx)、モジュール (.bas)、SQLite データベース (Orders.db) が表示されます。 ls -la *.vbp *.frm *.bas *.db  変換追跡用にリポジトリを初期化します。 git add .  git commit -m "Baseline before VB6 to C# transformation"  次に、リファレンスドキュメントを含むリポジトリをクローンします。このリポジトリには、AWS Transform にコンテキストとして渡すビジネスルールと変換例が含まれており、組織の標準に合ったコードを生成します。 git clone -b dotnet-transform-custom https://github.com/aws-samples/dotnet-genai-samples.git  ウォークスルー 以下のセクションでは、AWS Transform CLI を使用して VB6 コードをモダンな C# プロジェクトに変換する手順を説明します。 ステップ 1: VB6 アプリケーションを評価する 変換定義を作成する前に、VB6 ポートフォリオのスコープと複雑さを把握します。SKS リポジトリをクローンした状態で、ATX CLI を起動して評価を開始します。 atx custom def exec -p <path-to-repository> \  -n 'AWS/early-access-comprehensive-codebase-analysis' \  -t  パラメータ : -p: ソースプロジェクトのパス (クローンした SKS リポジトリ) -n: 変換定義名 -t: 変換に関わるすべてのツールを信頼し、実行中に AWS Transform が許可を求めて一時停止するのを防ぐ 注意 ：2026 年 5 月 1 日時点では、変換定義名は AWS/early-access-comprehensive-codebase-analysis から AWS/comprehensive-codebase-analysis に変更になっています AWS Transform custom は、シェルスクリプトなどの特定のアクションを実行するために許可を必要とします。上記のコマンドの –t 引数により、ツールはユーザーに継続的にプロンプトを表示することなく実行できます。 評価では SKS プロジェクトを分析し、フォーム数 (15 以上)、モジュール数 (3)、COM コンポーネントの依存関係 (MSFlexGrid、ListView)、データベースアクセスパターン (ADO with SQLite)、推定変換複雑度スコアを含む包括的なレポートを生成します。 この評価レポートを使用して、VB6 アプリケーションを変換する際に AWS Transform custom に追加のコンテキストを提供します。 ステップ 2: VB6 から C# へのカスタム変換定義を作成する 次に、VB6 からモダンな C# への変換パターンとルールをキャプチャするカスタム変換定義を作成します。AWS Transform custom は、提供された例、ドキュメント、ビジネスルールから学習し、これらのパターンを一貫して適用します。 対話型 CLI を起動します。 atx -t  プロンプトが表示されたら、変換の説明として VB6 to C# ASP.NET Core web application migration と入力します。AWS Transform custom は既存の変換を検索し、この特定のシナリオに該当するものが見つからない場合、カスタム変換を作成するかどうかを尋ねます。「create a new one」と入力して確認します。 図 1 – atx cli の起動 変換コンテキストとビジネスルールの提供  AWS Transform custom は、ドキュメント、移行ガイド、サンプルコードの提供を求めます。ここで組織固有の要件を追加します。SKS アプリケーションについては、そのアーキテクチャに関するコンテキストを提供します。 Salmon King Seafood (SKS) という VB6 MDI アプリケーションがあります。ソースコードは <path-to-repository> にあります。注文受付、顧客管理、製品カタログ、在庫管理、承認ワークフローなど、15 以上のフォームがあります。3 つのモジュール (データベース接続用の modConnection.bas、ユーティリティ関数用の modFunctions.bas、アプリケーションのエントリ ポイント用の modMain.bas) を使用しています。データベースは SQLite で、データ バインディングを使用した ADO データ コントロールを介してアクセスします。コントロールには、MSFlexGrid、ListView、Toolbar、ImageList、およびコントロール アレイが含まれます。これを .NET 10 をターゲットとする ASP.NET Core Blazor Server アプリケーションに変換してください。 組織向けの移行パターンのカスタマイズ  移行の精度を向上させるために、組織固有のマッピングルールを提供します。これらはユーザーが作成したマークダウンファイルで、AWS Transform custom からプロンプトが表示された際に参照します。AWS Transform custom はこれらを変換プランに組み込みます。プロンプトが表示されたら、対話型セッション中に VB6 ソースコードとともにこれらのファイルを参照します。 図 2 – 変換プランへのビジネスルールやその他のコンテキストの追加 変換例の参照 <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/example-transformations.md ファイルを確認します。ATX エージェントがサンプル変換を求めるプロンプトを表示したら、以下のように参照します。 変換前後の例は、<path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/example-transformations.md にあります。 企業コーディング規約の参照 AWS Transform custom では、組織のコーディング規約を変換に使用することでコード生成を制御できます。これには特定の C# の機能や規約を含めることができます。AWS Transform custom はこれらを使用して、チームのスタイルに合ったコードを生成します。<path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/coding-standards.md ファイルを確認します。組織のプラクティスに合わせて独自の規約を作成できます。 例 : <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/coding-standards.md で定義されているコーディング規約を適用してください。 ターゲットアーキテクチャ仕様の参照 オプションとして、 <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/target-architecture.md にあるような、望ましい出力アーキテクチャを記述したドキュメントを使用できます。 AWS Transform custom は参照されたすべてのファイルを読み取り、組織のパターン、規約、アーキテクチャに合った変換プランを生成します。 生成された変換定義 あなたの入力に情報に基づいて、AWS Transform custom はフェーズごとに整理された包括的な変換定義を生成します。 フェーズ 1 – 分析 : VB6 コンポーネントのインベントリ、依存関係の特定、依存関係グラフの作成 フェーズ 2 – プロジェクト構造 : ASP.NET Core Blazor Server プロジェクトの生成、NuGet パッケージの設定、依存性注入のセットアップ フェーズ 3 – データレイヤー : ADO/DAO から Entity Framework Core への変換、DbContext とエンティティモデルの生成 (適切な場合は record 型を使用) フェーズ 4 – ビジネスロジック : モジュールからサービスクラスへの変換 (プライマリ コンストラクターを使用)、関数から async メソッドへの変換 フェーズ 5 – UI レイヤー : VB6 フォームから Blazor コンポーネントへの変換、イベントハンドラの変換 フェーズ 6 – 検証 : ビルド成功の確認、ユニットテストの生成、機能的等価性のテスト 変換定義をすぐに適用するか、レビューして修正するか、レジストリに公開して再利用するか、新しいプランを開始するかを選択できます。次のステップでは、大規模に再利用できるように変換定義を公開します。 AWS Transform custom は変換プランの名前と説明を提案してきます。そのまま受け入れるか、必要に応じて修正できます。これで変換定義がチーム全体で利用可能になります。 カスタム変換定義の表示と管理  公開後、対話型エージェントまたは以下の CLI コマンドを使用して、カスタム変換定義と利用可能なすべての AWS マネージド変換を表示できます。 atx custom def list 図 3 – ユーザーが作成したカスタム変換プランの一覧 このコマンドは、AWS マネージド変換 (AWS/ プレフィックス付き) とカスタム定義の変換の両方を表示します。カスタム定義の下に VB6-to-CSharp-Blazor-Migration 変換プランが表示されます。 ステップ 3: 変換を実行する カスタム変換定義を公開したら、VB6 アプリケーションのモダナイゼーションを実行できます。プロンプトが表示されたら、プロジェクトに対して変換プランを実行します。リポジトリへのパスと、変換後にプロジェクトをビルドするためのビルドコマンドを与える必要があります。 図 4 – 変換を検証するためのビルドコマンドの追加 以下のコマンドを使用して変換プランを直接ターミナルから実行することもできます。 atx custom def exec -p <path-to-repository>\  -n 'VB6-to-CSharp-Blazor-Migration' \  -t  AWS Transform custom が認識すべき追加のコンテキストを提供するかどうかを尋ねられます。これは、保存された変換定義には含まれないその場限りのコンテキスト (コード分析で生成されたドキュメントなど) を提供する場合に便利です。 図 5 – 変換プラン生成前の追加コンテキストの追加 プロンプトに回答すると、AWS Transform は実行またはレビュー・修正するための変換プランを生成します。 図 6 – 変換プランのレビューまたは続行 変換プランの内容に問題なければ 続行する 変換エージェントは SKS プロジェクトの構造を分析し、MDI コンテナ (frmMain.frm)、子フォーム、モジュール、データベースパターンを特定してから、変換定義を適用します。エージェントは以下を変換します。 frmMain.frm (MDI コンテナ) → ナビゲーションメニュー付きの Blazor MainLayout.razor frmCustomers.frm、frmProviders.frm など → 個別の Blazor ページコンポーネント modConnection.bas → Entity Framework Core と SQLite プロバイダーを使用した SksDbContext.cs modFunctions.bas → ドメインごとに整理された拡張メソッドクラス MSFlexGrid データグリッド → データバインディング付きの Blazor テーブルコンポーネント ADO データコントロール → async/await を使用した Entity Framework Core クエリ ステップ 4: レビュー、テスト、反復 変換が完了すると、AWS Transform custom は変換されたコードを新しいブランチまたはディレクトリに出力し、変換レポートと手動修正の次のステップを提示します。 変換結果のレビュー  変換レポートには、以下を含む終了基準の検証が含まれます。 dotnet build がエラーゼロで成功 すべての VB6 フォームが Blazor コンポーネントに変換済み (例: frmCustomers.frm → Customers.razor、frmOrderReception.frm → OrderReception.razor) データアクセスレイヤーが Entity Framework Core と SQLite プロバイダーおよび async パターンを使用 (ADO/ADODC データコントロールを置換) COM 依存関係の排除 — MSFlexGrid は Blazor テーブルコンポーネントに、Toolbar/ImageList は Blazor ナビゲーションに置換 エラーハンドリングが On Error 文から構造化された try-catch 例外処理に変換 仕様に従ったモダンな C# 機能の適用 (レコード型、プライマリコンストラクター、パターンマッチング) modConnection.bas が IDbContextFactory<SksDbContext> を使用した登録済み Dependency Injection (DI) サービスに変換 AWS Transform は 1 回の実行で検証基準を満たさない場合があります。変換の実行後、成功した部分と失敗した部分のサマリーを含む部分的な変換結果が得られることがあります。以下に変換結果を示します。 図 7 – 完了した変換結果 フィードバックプロンプトから、未達成の基準に対処するために変換を再実行できます。変換された SKS アプリケーションを検証するには、ターミナルに切り替えて以下を実行します。 cd <path-to-your-project>  dotnet build  dotnet run  ブラウザで https://localhost:<port> にアクセスし、以下に示すように Blazor アプリケーションが受注、顧客管理、商品カタログのページを正しくレンダリングすることを確認します。 図 8 – 請求書作成ページ 図 9 – 注文作成ページ 機能が不足している場合は、CLI にフィードバックを返して変換結果を繰り返し改善します。 Transform コマンドのパフォーマンス Transform custom コマンドは、変換対象のコードベースのサイズに応じて、完了までに最大 60 分かかる場合があります。コードファイルや依存関係が多い大規模なプロジェクトでは、当然ながらより多くの処理時間が必要になります。 変換の制限事項について Transform custom の機能では、VB6 アプリケーションのすべての機能を自動的に変換できるとは限りません。変換完了後、ソースの VB6 アプリケーションと変換先の C# アプリケーション間の機能を比較・検証する必要があります。変換されなかった不足機能については、 Kiro  や  Amazon Q Developer  などの AI 搭載ツールを使用して、ソースから変換先のコードベースへの変換・移植を支援できます。 ユニットテストの重要性 ユニットテストは、変換プロセス全体を通じて機能の正当性を検証します。変換されたコードが元の VB6 アプリケーションと同一の動作をすることを確認し、変換中に導入された不一致やリグレッションを迅速に特定するのに役立ちます。変換前に一連のテストを整備してください。これがリグレッションテストの基準となり、変換後も同等に動作することを検証できます。 まとめ 組織固有のパターン、ビジネスルール、モダンな C# 機能の設定を含むカスタム変換定義を使用することで、組織に蓄積された知見を維持しながら数百の VB6 アプリケーションを体系的にモダナイズできるようになりました。 変換を一度定義すれば、アプリケーションポートフォリオ全体に適用できます。これにより、再利用可能な変換定義に組織に蓄積された知見が保存されます。フィードバックループによる継続的な改善により、各変換はより洗練され、レコード型、プライマリコンストラクター、パターンマッチングなどのモダンな C# 機能がコードベースに自動的に適用されます。モダナイズされたアプリケーションは Linux と AWS Graviton 上で動作し、インフラストラクチャコストを削減できる可能性があります。 AWS Transform custom を使用して VB6 アプリケーションポートフォリオのモダナイゼーションを始めましょう。セットアップ手順については、 AWS Transform custom Getting Started Guide  をご覧ください。 追加リソース AWS Transform custom Getting Started Guide AWS Transform custom Product Page AWS Transform custom Documentation AWS Transform custom Command Reference AWS Transform for .NET .NET on AWS Developer Center 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について David Kilzer David Kilzer は、AWS エコシステム内での Microsoft ワークロードの最適化を専門とするソリューションアーキテクトです。C#、SQL Server、そして AWS サービスを用いた最新のソフトウェアソリューション構築に関する専門知識を有しています。 Ashish Bhatia Ashish Bhatia は、AWS のシニアソリューションアーキテクトで、エンタープライズのお客様のクラウドジャーニーのガイドに注力しています。AWS のクラウドネイティブサービスを使用して最新のソフトウェアソリューションを構築するお客様を支援することに情熱を注いでいます。また、彼は Amazon Web Services のスペシャリストソリューションアーキテクトです。最先端の生成 AI ソリューションの作成に取り組み、お客様中心のアプローチを優先しています。 Ty Augustine Ty Augustine は、.NET、SQL Server、コンテナを専門とする Microsoft スペシャリストソリューションアーキテクトです。ニューヨークを拠点に、様々な業界の企業と緊密に連携し、AWS クラウドへの移行とモダナイゼーションを加速させています。AWS に入社する前は、20 年以上にわたり Microsoft スタックのソフトウェアアーキテクトとして活躍していました。

本ブログは 2026 年 3 月 17 日に公開された AWS Blog “ AWS and Others Invest $12.5M to Defend the Open Source Ecosystem from AI Threats ” を翻訳したものです。 AWS、Anthropic、Google、Microsoft、OpenAI は本日 (2026 年 3 月 17 日)、AI によって強化された、あるいは AI が生成したセキュリティ脆弱性レポートの急増にオープンソースプロジェクトが対応できるよう支援するため、Linux Foundation を通じて 1,250 万ドルを拠出することを 発表しました 。 Alpha Omega イニシアチブと Open Source Security Foundation (OpenSSF) の両方が、Linux Foundation の助成金を通じて資金提供を受けます。 ソフトウェアセキュリティは重要な転換点を迎えています。重要なコードのバグを発見する能力において、基盤モデルがセキュリティ研究者を上回り始めています。たとえば Anthropic は 2026 年 2 月、最新の Claude Opus 4.6 モデルが研究の初回ラウンドで、オープンソースプロジェクトにおける重大度の高い脆弱性を 500 件以上発見し、検証したと 報告しました 。 今回の新たな資金提供は、AWS、Google、Microsoft が Alpha Omega に対してこれまで行ってきた 数百万ドル規模の取り組み を基盤としています。AWS はこの資金を活用し、オープンソースのメンテナーが正当な脆弱性を迅速に検証して修正しつつ、低品質な提出物を除外できるよう、ツール、自動化、リソースを提供します。この拠出は、過去 4 年間にわたってエコシステム全体のオープンソースセキュリティを強化してきた Alpha Omega の実績の上に成り立っています。 Alpha Omega の参加組織、Linux Foundation、OpenSSF、そしてより広範なオープンソースセキュリティコミュニティとともに、AWS は新たな課題を生み出しているのと同じ AI の能力を活用し、世界のデジタルインフラを支えるソフトウェアサプライチェーンに、より堅牢な防御を構築できるよう取り組んでいきます。 AI によるオープンソースプロジェクトの脆弱性発見の増加 セキュリティ関連のバグレポートを作成する作業は、かつては専用のツールでアプリケーションのファジングやペネトレーションテストを実施し、問題を検証して報告し、脆弱性を修正するという多大な労力を要するプロセスであり、しばしば数か月、あるいはそれ以上の時間を要しました。このプロセスは今や、時間との戦いとなっています。広く利用可能な生成 AI ツールを使い、悪用の可能性を特定できる強力な AI モデルに同じようにアクセスできる潜在的な脅威アクターよりも、先んじなければならないからです。 オープンソースのメンテナーは、AI が生成したバグレポートがレビューしきれないほど押し寄せているという警鐘も鳴らしています。それらのレポートの多くは非常に低品質であり、これが「AI スロップ」(AI が生成した低品質なコンテンツ) という新しい業界用語を生む現実となっています。多くのプロジェクトはすでに、AI による提出物に対するガイドラインを導入することを選択しており、なかには AI が生成したプルリクエストの殺到を防ぐために、アップストリームへの貢献を完全に停止したプロジェクトもあります。 AI が正当な脆弱性を発見しているにせよ、スロップレポートを提出しているにせよ、迅速かつ大規模に対応する必要性は、急速に業界全体の課題になりつつあります。プロジェクトはコードにパッチを適用する必要がありますが、その責任を、すでに対応が逼迫しているメンテナーだけに完全に負わせることはできませんし、そうすべきでもありません。 AWS、オープンソース、人工知能 世界をリードするクラウドプロバイダーとして、オープンソースのサプライチェーンセキュリティ、ツール、ベストプラクティスに 深く注力 してきました。AI が遍在する時代に生じる新たなセキュリティ課題への対応を支援するために、AWS は積極的に取り組んでいきます。AWS は、数えきれないほどの企業と同様に、クラウドサービスを構築・運用するために、コア技術をオープンソースとして活用し、開発に参加し、自社コードも公開しています。安全なオープンソースプロジェクトは、お客様の次なる素晴らしい AI 対応イノベーションを支えるクラウドサービスを AWS が提供するための基盤です。 AWS はすでに、高度な AI システムを構築・維持するための価値あるツールや技術を数多く提供しています。安全なモデルホスティングを実現する Amazon Bedrock サービスと Amazon Bedrock AgentCore フレームワークは、高度で安全なエージェント型アプリケーションのための豊富な構成要素を提供します。これらの機能には、 Firecracker をベースとしたエージェント向けの安全で隔離されたコンピューティングプラットフォーム、IAM と OAuth ベースの ID 管理、AgentCore Gateway と Cedar ベースのポリシーエンジンによって仲介される一元化されたツールアクセス、そして豊富なオブザーバビリティと Evaluations の機能が含まれます。 Kiro は、最先端の AI モデルの力を活用し、AWS のセキュリティベストプラクティスに支えられた仕様駆動開発によって、AI コーディングに構造をもたらします。 Amazon の Frontier Agents は、自動化されたソフトウェア開発だけでなく、AWS Security Agent および AWS DevOps Agent も提供し、ソフトウェアの開発・デプロイのライフサイクルに対してより包括的な AI サポートを実現します。Alpha Omega への追加拠出により、AWS はより広範なオープンソースエコシステム全体にわたって AI の力をより広範なオープンソースエコシステム全体に広げていきます。 バグの発見と修正 AI が生成したバグレポートはオープンソースプロジェクトにとって問題を生み出すこともありますが、サプライチェーンのセキュリティを向上させる上では計り知れない価値があります。これほどの速度や規模でバグを発見し、修正できるようになったことはこれまでありませんでした。AWS は、問題を発見しているのと同じ高度なモデルやツールが、より優れたツールと自動化を通じて、それらを修正するためにも活用できると考えています。 しかし、この問題を 1 社だけで解決することはできません。より高度なモデルがリリースされるにつれて、問題はさらに大きくなっていきます。業界のリーダーは協力し合い、修正を迅速に行いつつ、オープンソースのメンテナーが長期にわたってプロジェクトの健全性を維持できるような方法で進めなければなりません。そうすることで、すべての人のためにソフトウェアサプライチェーンのセキュリティ確保を支援できます。 この目的のために、AWS は Alpha Omega のプラチナメンバーである Google、Microsoft、そして新メンバーの Anthropic、OpenAI とともに、1,250 万ドルの追加資金提供を発表しました。AWS による 250 万ドルの拠出は、オープンソースプロジェクトとそこで働くメンテナーがセキュリティ脆弱性をより迅速に修正できるよう支援するために特別に確保された、より大きな資金プールの一部です。この新たな資金により、Alpha Omega は、基盤モデルが新たな脆弱性を報告する速度にオープンソースプロジェクトが追いつけるよう、ツール、自動化、トレーニング、その他のリソースの提供を目指します。 Alpha Omega によるオープンソースセキュリティの改善 過去 4 年間、Alpha Omega はオープンソースプロジェクトと財団に助成金を提供し、セキュリティの改善に充ててきました。これらの改善には、フルタイムのセキュリティエンジニアの雇用、セキュリティ監査の実施、リリースツールの改善など、さまざまなものが含まれます。Alpha Omega を通じて、拠出組織は互いに協力し、またプロジェクトのメンテナーやオープンソースセキュリティコミュニティの他のメンバーと連携して、資金が最も重要なプロジェクトやイニシアチブに確実に届くようにできます。 この組織は Linux Foundation の OpenSSF 内に置かれており、エコシステム全体に影響を与える重要なセキュリティ改善をすでに達成しています。過去 4 年間にわたり、Alpha Omega はセキュリティレポートを提供し、脆弱性への対応を調整し、Internet Security Research Group、Apache Software Foundation、Rust Foundation、Python Software Foundation、Eclipse Software Foundation などの組織とパートナーシップを築いてきました。 たとえば、2025 年の Alpha Omega の資金提供の結果として、Rust Foundation は crates.io に Trusted Publishing を完全に展開し、公式の CVE 採番機関 (CNA) となりました。Node.js は重大度の高い脆弱性を 2 件修正しました。Python Software Foundation は PyPI のマルウェア検出とアカウントセキュリティを強化しました。FreeBSD Foundation は FreeBSD のベースシステム におけるサードパーティソフトウェアのセキュリティを改善し、OpenSSL の 3.0 から 3.5 LTS へのアップグレード (2030 年までサポートを延長) に成功しました。Eclipse Foundation は OpenVSX の脆弱性 に対処しました。 AWS は、新たな AI 技術や将来の未知の課題から生じる問題の解決を支援するために、他の Alpha Omega 参加組織や、それらが資金提供するプロジェクトとともに取り組むことに尽力しています。皆様もぜひご参加ください。プロジェクトやそのイニシアチブの詳細、参加方法については、 https://alpha-omega.dev/ をご覧ください。 <!-- '"` --> Mark Ryland Mark Ryland は AWS Security の Director です。テクノロジー業界で 30 年以上の経験を持ち、サイバーセキュリティ、ソフトウェアエンジニアリング、分散システム、技術標準化、公共政策の分野でリーダーシップを発揮してきました。以前は、AWS World Public Sector チームの Solutions Architecture および Professional Services の Director を務めていました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

日本最大の「AWS を学ぶイベント」、 AWS Summit Japan &nbsp;が 2026年6月25日(木)、26日(金) の2日間にわたり幕張メッセで開催されます。AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、AWS に興味がある全ての皆様のための無料のイベントです。 今回はその中から データベース関連の注目セッション を、以下の 4 つのテーマに沿ってご紹介します。 AI × データベース ― 生成 AI やエージェントがデータベースの移行・運用をどう変えるか 分散 SQL の最前線 ― Amazon Aurora DSQL のアーキテクチャから実装・検証まで コストとパフォーマンスの最適化 ― 既存環境の見直しとキャッシュ基盤の刷新 データモデリング実践 ― DynamoDB の設計力を引き上げる 今年のデータベースセッションは、この 4 つの潮流を押さえれば全体像が見えてきます。気になるテーマからぜひチェックしてみてください。 1. AI × データベース AI エージェントをデータベースの移行や運用に活用する実践的なセッションです。「移行のコード変換を自動化したい」「運用の検知・対応を AI に任せたい」「エージェントの記憶をどう永続化するか知りたい」という方に。 (DAT302) AI エージェントで切り拓く商用 DB から Amazon Aurora への移行 ―コード変換の実践手法とお客様検証事例 6月25日(木) 13:30–14:10 商用 DB 移行のコード変換、AI エージェントでどこまで自動化できるか？ ― 数千行のストアドプロシージャや動的 SQL の変換は、移行を諦める理由になりがちです。本セッションでは、AWS DMS によるルールベース変換と AI エージェントによる変換を組み合わせた新しいアプローチを解説します。変換ルールやコーディング規約を自然言語で指示し、変換・テスト・突合を自動で繰り返すワークフローにより、従来ツールでは困難だったコードをどこまで自動化できるのか、2 社のお客様検証事例と具体的な数値結果を交えてお伝えします。セッション後すぐに PoC を始められるワークショップやサンプルスクリプトもご案内します。 (DAT358) AI エージェントで実現するデータベース運用：検知・推奨・最適化 6月26日(金) 13:00–13:40 本番障害が起きる前に、AI が問題を見つけて対処法まで提案してくれたら？ ― Amazon RDS、Amazon Aurora、Amazon Redshift を監視・分析する AI エージェントの実装方法を紹介します。パフォーマンスボトルネックの検知からクエリパターンの可視化、最適化戦略の提案まで、AI によるインサイトでデータベースモニタリングを強化する方法を学べます。 (DEV303) AWS サービスを使ったエージェントのメモリ実装パターン 6月25日(木) 12:30–12:50｜シアターセッション AI エージェントの「記憶」をどのデータベースに保存すべきか？ ― 過去の会話履歴をもとに AI がアクションを実施するための重要機能であるメモリについて、AWS のデータベースサービスをメモリストアとして選択する際のポイントを考察します。 2. 分散 SQL の最前線 ついに一般公開された Amazon Aurora DSQL。マルチリージョンでの強い整合性をサーバーレスで実現する分散 SQL データベースを、アーキテクチャ・設計・実プロダクト検証の 3 つの角度から掘り下げます。 (DAT338) Amazon Aurora DSQL Deep Dive ― 内部アーキテクチャの設計思想と実装の勘所 6月26日(金) 12:00–12:40 Aurora DSQL はなぜ軽量な接続と低レイテンシを実現できるのか？ ― OLTP ワークロードに最適化されたサーバーレスの分散 SQL データベースである Aurora DSQL が、トランザクションをどのように処理するかを内部コンポーネントの役割に沿って図解します。特に中核コンポーネントである Query Processor の内部動作を掘り下げ、実装パターンや考慮事項を設計意図とともに整理します。 (AIM252) Kiro でつくる！Amazon Aurora DSQL の特性を活かしたスキーマ設計 6月25日(木) 13:30–13:50｜シアターセッション 分散 SQL のスキーマ設計、何から始めればいい？ ― 「分散 SQL データベースを使ったことがないから設計がわからない…」という方に向けて、Kiro Powers を使ったスキーマ設計支援の方法をデモで紹介します。 (ANT333) 実プロダクトで検証する Amazon Aurora DSQL の可能性と制約 6月26日(金) 14:00–14:20｜シアターセッション 実際のワークロードで Aurora DSQL はどこまで使えるのか？ ― モバイルゲームのシャーディング DB を Aurora DSQL へリフトした場合の性能・コスト・運用性を実プロダクト規模で検証。ベンチマーク結果や制約など実践的な知見を共有します。 3. コストとパフォーマンスの最適化 「今の構成でコストを下げつつパフォーマンスも上げたい」「キャッシュ基盤をモダナイズしたい」という方に。 (DAT318) 実践！Amazon RDS と Amazon Aurora のコスト最適化とパフォーマンス向上 6月25日(木) 14:30–15:10 コスト削減とパフォーマンス向上は両立できる。 ― 架空の企業 AnyCompany が直面する課題を通して、コンピューティング、ストレージ、バックアップの各要素でコストを最適化しながらパフォーマンスを向上させるベストプラクティスを学びます。CloudWatch Database Insights を使ったワークロード特定の手法も実践形式でご説明します。 (DAT456) より速く、より安く、より良く ― Valkey がもたらすキャッシュ基盤の革新 6月26日(金) 16:00–16:40 スループット 230% 向上、メモリ 40% 削減、コスト 33% 削減 ― キャッシュ基盤を一新しませんか？ ― 2024 年に誕生したオープンソースプロジェクト Valkey は、マルチスレッドアーキテクチャや効率型辞書により、キャッシュ技術に革新をもたらしています。Valkey と Amazon ElastiCache が実現する高スケーラビリティ・高可用性の Serverless 構成まで、キャッシュ基盤の未来に迫ります。 4. データモデリング実践 DynamoDB をフル活用するためのデータモデリング手法と、最新機能による設計の変化を学べるセッションです。 (DAT340) Amazon DynamoDB アドバンスドデータモデリング 6月26日(金) 14:00–14:40 「DynamoDB の設計、これで合っているのか？」という不安を解消。 ― DynamoDB の基礎と設計原則を通じて「DynamoDB データモデリングの考え方」を習得し、複雑なユースケースに対応するための実践的な戦略と機能を解説します。 (CNS204) マルチキーサポートで変わる Amazon DynamoDB の GSI 戦略 6月25日(木) 13:00–13:20｜シアターセッション GSI の設計パターンが変わる ― マルチキーサポートで何が可能に？ ― 2025 年に追加されたグローバルセカンダリインデックス (GSI) のマルチキーサポートにより、従来の GSI 設計がどのように変わるかをデモを交えて解説します。 データベース関連ブースのご案内 セッションだけでなく、EXPO 会場内のブースでもデータベースに関する技術デモや個別相談を実施しています。セッションで気になったトピックを、ブースでさらに深掘りできます。 商用データベースを Amazon RDS で最適化 Oracle / SQL Server / Db2 からの移行相談、Oracle Database@AWSに関する最新情報など 生成 AI でデータベース業務を効率化 AI エージェントによるデータベース運用のデモ・技術相談 AWS マネージドデータベース Amazon Aurora、DSQL、DynamoDB の可用性、スケーラビリティに関するデモ・技術相談 Neptune（オントロジーナレッジグラフ for AI エージェント） ナレッジグラフ、オントロジー管理のユースケース AWS Transform によるモダナイゼーション モダナイゼーション全般のご相談 まとめ AWS Summit Japan 2026 のデータベースセッションは、どのテーマも「明日から使える実践知」を重視した内容になっていますので、ぜひ興味のあるセッションに足を運んでみてください。 一部のセッションは既に満席となっております。気になるセッションがあればお早めにご登録ください。 AWS Summit Japan 2026 登録ページ 著者 長久保 武 データベース スペシャリスト ソリューションアーキテクト

みなさん、こんにちは。ソリューションアーキテクトの池田、ポール、佐山です。 2026 年 5 月 18 日〜20 日の 3 日間、AWS 大阪オフィスにて「合同 AI-DLC Unicorn Gym」を開催しました。H2O Retailing、パナソニックコネクト、パナソニックデジタル、村田製作所、東洋紡、ギフトパッド、シャープ、ダイキン工業、近鉄情報システム（順不同、敬称略）の 9 社 10 チームから計 75 名のビジネスメンバー・開発メンバーが参加し、3 日間 AI 駆動の開発プロセスを実践しました。 本記事では、9 社 75 名が 3 日間 AI-DLC をどう体験したのか、参加者の声を交えてレポートします。 AI-DLC (AI-Driven Development Lifecycle) とは AI 駆動開発ライフサイクル (AI-DLC) は、AI を開発プロセスの中心に据えた開発手法です。AI をアシスタントとして後付けで使うのではなく、要件定義・設計・実装の主役を AI が担い、人間は意図のすり合わせと重要な判断に集中する── この役割分担により、従来は数ヶ月かかっていた要件定義から実装までを数日に圧縮します。 プロセスは Inception（要件を練る）・Construction（実装する）・Operations（運用する）の 3 フェーズ。鍵となるのが、チーム全員で 1 つの画面を囲んで AI と対話する「モブエラボレーション」（Inception）と「モブコンストラクション」（Construction）です。AI が要件案やコードを素早く提示し、ビジネス・開発メンバーがその場で検証・判断する。この共同作業が、開発速度の向上だけでなく、ビジネスと開発のギャップを埋め、チーム全員の認識を揃える効果をもたらします。今回の Unicorn Gym では主にこの 2 つを 3 日間で集中実践しました。 詳しくは AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 、 11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 、および AI-DLC ホワイトペーパー をご参照ください。 9 社 10 チームが持ち込んだテーマ 各社はビジネスメンバーと開発メンバーの混成チーム（6〜8 名）で、実際のビジネス課題をテーマに持ち込みました。営業支援ツール、現場の点検・検査業務のデジタル化、環境データの集計・可視化、社内インフラの払い出し自動化、グループウェア間のデータ連携など、テーマは多岐にわたります。新規開発だけでなく、既存システムへの機能追加に取り組んだチームもありました。AI を使わない従来の開発手法で見積もると平均して十数人月かかる規模のものです。 「色々取り組んでいるがうまくいかない」「スクラムに限界を感じている」「AI を使わないと間に合わない、AI を積極的に取り入れると決めてメンバーを連れてきた」「開発プロセスが定まらない」── 業界はバラバラでも、開発の壁にぶつかっている点では共通していました。近鉄情報システムでは CTO 自らが参加し、コーディングエージェントを操作して開発に加わるなど、各社の取り組み姿勢もさまざまでした。Spec 駆動開発を実践しているチームもあれば、AI をチームで使うのは初めてというチームもありました。 会場の雰囲気も印象的でした。パナソニックデジタルはオレンジのチーム T シャツを全員で着用して一体感を演出。シャープのメンバーは「服装自由」を活かして着物で参加するなど、普段の業務とは違う特別な 3 日間にしようという空気が会場に満ちていました。 Day 1: Inception ── 同じ画面を囲んで、要件を練り上げる 午前は AI-DLC の概要と Hands-on。午後から「モブエラボレーション」に突入しました。 モブエラボレーションとは、チーム全員が 1 つの画面を囲み、AI と対話しながら要件を練り上げる共同作業です。ビジネスメンバーも開発メンバーも同じ場で AI の提案を検証し、判断し、修正していく。このプロセスを通じてチーム全員のコンテキストが揃い、その共通認識が Construction フェーズにそのまま引き継がれます。 半日で多くのチームがユーザーストーリー作成からモックアップ確認まで到達。 普段、開発とビジネスが面と向かって議論する機会がほとんどない。やってみたら、開発側がビジネスを理解しようとする姿勢が自然に生まれた（H2O Retailing） Day 1 の共有会で印象的だったのは、こんな声です。 何もわかっていない AI に教えながら進めることで、メンバー全員の知識ラインが揃った。結果として良い要件定義になった（東洋紡） AI に説明する行為そのものが、チーム内の認識合わせになっていた。これは狙い通りでもあり、想像以上に効果的でした。 タスクを AI に任せて、判断を人間に回されるプロセスが結構大変。判断力が成果物に直結する（近鉄情報システム） AI に委ねるほど、人間の判断力が試される。この実感は 3 日間を通して繰り返し語られることになります。 自分で体験しないと効果がわからない。人に聞くのではなく自発的に新たな体験をしていきたい（東洋紡） AI-DLC は説明を聞いて理解するものではなく、やってみて初めて腹落ちする── 多くの参加者がそう語っていました。 Day 2: Construction ── コードは出る。でも判断が追いつかない 2 日目は朝からグループワーク。各チームのペースで Inception を仕上げ、Construction フェーズへ入っていきます。 Inception の仕上げとして取り組むのがユニット分割です。ユーザーストーリーを独立して開発できる単位（ユニット）に切り分け、チーム内を 2〜3 のサブチームに分けて並行開発に入る準備をします。 午前の共有会では、Inception フェーズの速さに驚く声が上がりました。 いつもなら 1 ヶ月、2〜3 スプリントかかることが 4 時間でできた。めっちゃしんどかった（パナソニックデジタル） 午後、並行開発が本格化すると「I/F 合意の壁」が見えてきます。 単体テストは通っていたのに、結合したらつながらない箇所があった（シャープ） I/F のつめが甘くて手戻りが発生した（村田製作所） AI がコードを高速に吐き出しても、チーム間の合意が足りなければ結合で引っかかる。開発全体の速度を決めているのはコード生成ではなく、人間の判断と合意形成だ── 複数のチームが同じ気づきに至っていました。 AI がわかったつもりで勝手に再定義してきて時間を食った。レビューをサボると後で痛い（ダイキン工業） AI の出力は必ず人間が検証する、というプロセスの重要性が裏付けられました。 うまくいったパターンとして共有されたのは「最初から大きく扱わず、ミニマルに絞る」「チーム全員で共通認識を作ってから分かれる」の 2 点。 社内で AI を使った開発を検討していたが明確な手順が定まっていなかった。今回の AI-DLC は開発手法としてかなり参考になった。この手法を軸に社内の既製品に対してどうアプローチするか考えていきたい（ダイキン工業） 自社への持ち帰り方が具体的に見え始めたチームもありました。 Day 2 のクロージング時点で、多くのチームがコード生成・ローカル動作確認まで進んでいました。 Day 3: 仕上げと成果発表 最終日は朝から Construction の追い込みです。ユニットの結合、テスト、デプロイ。「動くもの」を 3 日間の集大成として仕上げにかかります。 16 時からは成果発表会。各社が到達した地点を全体に共有しました。 全 10 チームがデモを実施しました。全チームが動くアプリケーションを画面に映して見せるところまで到達しています。 発表を通じて見えたのは、成果の大きさだけではありません。各チームが共通して語ったのは以下のような気づきでした。 Inception フェーズで要件を丁寧に練り上げたチームほど、Construction がスムーズに進んだ ユニット分割の前に、チーム全員で共通のインターフェース定義を固めておくと結合時の手戻りが激減する 既存システムへの機能追加にも AI-DLC は適用できる。AI-DLC Workflow にはリバースエンジニアリングのフェーズが組み込まれており、既存コードの構造を AI に理解させた上で新機能の設計に入る流れがカバーされている AI の出力が速いからこそ、人間のレビューと判断がボトルネックになる。でも、チーム全員で同じものを見ながら判断を重ねるこのプロセスは強い あるチームは「従来 6 ヶ月を見込んでいた開発が 3 日で形になった。特に要件定義のスピードが劇的に変わった」と振り返り、別のチームは「明日の社内ミーティングで、早速プロジェクトに適用したいと提案するつもり」と語っていました。3 日間の体験が、そのまま翌日からのアクションに直結している── 参加者が自社に持ち帰れる手応えを得られたことが何よりの成果です。 AWS セッション・懇親会・Lightning Talks 成果発表の後は AWS の井形（Data&amp;AI 事業開発マネージャー）によるミニセッション「AWS Japan の事業開発マネージャーが生成 AI（Kiro）を使って業務効率化をした話」を実施しました。 AI-DLC が製品ライフサイクルの「作る力」をカバーするのに対し、GTM（Go-To-Market）は「届ける力」をカバーする。Build が速くなるほど、次のボトルネックは「誰に、どう届けるか」に移る。そして AI-DLC の考え方── AI に作業を任せ、人間は方向性と判断に集中する──は、GTM の領域にもそのまま当てはまる、という内容でした。3 日間で動くものを作った参加者にとって、「この先どう活かすか」を考えるきっかけになるセッションでした。 クロージングの後は懇親会 ＋ Lightning Talks。3 日間を共にした 10 チームのメンバーが、業界を越えて AI 駆動開発の実体験を語り合う時間です。この場での会話が、各社の持ち帰りをさらに厚くしたはずです。 3 日間を終えて AI はやっぱり自分の鏡だと思った。AI が理解できていないということは、自分がそこまでの解像度でインプットできていないということ（パナソニックコネクト） アプリ開発は 100% AI-DLC で進めたいと思えた。AI の成果物をレビューするために、私たちの知識を高めることも必要だと感じた（H2O Retailing） 個人で Kiro を触っていた時よりはるかに学びが多く、これは絶対に現場に適用すべきだと確信した（パナソニックデジタル） イベント後のアンケート（61 名回答）では、全体満足度は 5 点満点中 4.57 点。回答者の 96.7% が「満足」または「非常に満足」と評価しました。「AI-DLC はあなたの働き方を変える可能性があるか」という問いには 91.8% が 5 段階中 4 以上で回答。85.2% が継続的なフォローアップを希望しており、3 日間が「終わり」ではなく「始まり」として受け止められていることがわかります。 おわりに AI がコードを書いてくれるようになると、人間の仕事は変わります。手を動かしてコードを書くことから、何を作るか決めること、設計の方向性を判断すること、チーム間の認識を揃えることへ。人間の役割は「作業」から「意思決定」に集中していきます。 AI-DLC がモブで集まることを重視するのはそのためです。ビジネスメンバーと開発メンバーが同じ場に集まり、AI が揃えた材料をもとにその場で判断を重ねていく。意思決定に集中できる環境を作ることで、チーム全体の開発サイクルが速くなる。3 日間で参加者が体感したのは、まさにこの変化でした。 参加いただいた 9 社がこの体験を各社の現場に持ち帰り、それぞれの形で活かしていかれることを楽しみにしています。 参加企業からもレポートが公開されていますので、あわせてご覧ください。 ギフトパッド プレスリリース パナソニックデジタル 参加ブログ（1） パナソニックデジタル 参加ブログ（2） パナソニックデジタル 参加ブログ（3） パナソニックコネクト 参加ブログ 今回の AI-DLC Unicorn Gym は AWS 大阪オフィスで開催しました。前回の東京開催に続き、関西でも各社のチームが集まり、AI-DLC の実践を共にしました。AWS は地域を問わず、お客様の AI による開発プロセスの変革の挑戦に伴走していきます。 著者について 池田 敬之 (Takayuki Ikeda) 関西の製造業のお客様を担当するソリューションアーキテクトです。クラウド × データ × AI でお客様のビジネスを支援しています。好きなサービスは Amazon Bedrock AgentCore と Strands Agentsです。休日はキックボクシングで汗を流した後、愛犬と散歩といったコンボで英気を養うのが定番コースです。 ポール (Paul Nobuo Okada) 製造業のお客様を担当するソリューションアーキテクトです。サーバーレスの活用や AI 駆動開発ライフサイクル (AI-DLC) を日本のお客様への布教する活動もしてます。好きな AWS サービスは AWS サポートです。趣味はDTMとベース、最近ドラムも始めました。ただ、メンバー探しだけが難航しています。 佐山 朝葉 (Sayama Asaha) ソリューションアーキテクト。製造業のお客様をご支援しています。

本記事は 2026 年 05 月 20 日に公開された “ Introducing ExtendDB: An open source DynamoDB-compatible adapter with pluggable storage backends ” を翻訳したものです。 本日、Apache 2.0 ライセンスの下でリリースされた、プラガブルなストレージバックエンドを備えたオープンソースの Amazon DynamoDB 互換アダプターである ExtendDB を発表します。ExtendDB は DynamoDB のワイヤープロトコルを実装し、最初のバックエンドとして PostgreSQL に対応してリリースされます。そのため、DynamoDB で動作するすべての AWS SDK、CLI、ツールは ExtendDB でも変更なしで動作します。 本記事では、ExtendDB の紹介、利用開始の手順、アーキテクチャの説明を行います。これは開発、テスト、実験用途向けの v0.1 リリースです。 背景 Amazon DynamoDB は、あらゆる規模で 1 桁ミリ秒のパフォーマンスを発揮する、サーバーレスでフルマネージドな NoSQL データベースです。DynamoDB 上に構築するチームは、そのデータモデリングパターン、条件式、トランザクション、ストリームについて深い専門知識を培います。それを取り巻く CI パイプラインを構築し、運用ランブックを作成し、エンジニアのトレーニングを行います。これらのチームがエッジ、オンプレミス、切断された環境へと活動範囲を広げるにつれ、同じ API と開発者エクスペリエンスを持ち込みたいというニーズが生まれます。 ある大手航空会社は、ほとんどのアプリケーションを AWS 上で実行し、DynamoDB を主要なデータストアとして利用しています。しかし、ゲートおよび機内システムは、ネットワーク障害が発生しても稼働し続ける必要があり、搭乗、手荷物照合、機内販売についてはクラウドへのラウンドトリップ遅延を許容できません。これらのシステムは、同じアクセスパターン、同じ条件付き書き込み、同じトランザクション保証を必要とします。互換性のあるランタイムがないため、このチームは異なるデータアクセスレイヤー、異なる運用手順、異なる専門知識要件を持つ 2 つの別々のアプリケーションスタックを保守しています。 現在、AWS の外で DynamoDB ワークロードを実行することは、データアクセスレイヤーを書き直すことを意味します。DynamoDB Local はユニットテスト向けの単一プロセスのツールです。ExtendDB は初期段階のプロジェクトとして、より広範なローカル開発およびオンプレミスシナリオを対象としています。 ユースケース ExtendDB はマネージド DynamoDB サービスが利用できない、または現実的でないシナリオに対応します。 ローカル開発とCI/CD クラウドへの依存性ゼロで、ラップトップ上または継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで DynamoDB ワークロードを実行できます。統合テストは数秒で開始でき、決定論的に実行され、クリーンに終了します。 オンプレミスおよびエアギャップ環境 クラウド接続のない開発者、オンプレミスワークロードを実行するチーム、エッジのオペレーターは、自身のインフラストラクチャ上で DynamoDB のアクセスパターンを実行できます。 マルチクラウドおよびハイブリッド インフラストラクチャプロバイダー間でのポータビリティを試しているチームは、PostgreSQL が利用可能なあらゆる場所で DynamoDB API を利用できます。次の図は、ExtendDB から DynamoDB へのマイグレーションがエンドポイント URL の変更だけで済むことを示しています: ExtendDB とは ExtendDB は DynamoDB ワイヤープロトコルの実装で、Rust で書かれており AWS のエンジニアによって開発されています。アプリケーションとストレージバックエンドの間に位置するトランスレーターと考えてください。PostgreSQL リファレンスバックエンドを使用する場合、アプリケーションは DynamoDB プロトコルで通信し、ExtendDB が SQL に変換し、PostgreSQL がストレージを処理します。 ExtendDB はワイヤーレベルで DynamoDB JSON プロトコル を実装します。既存のアプリケーションコード、SDK、ツールは変更なしで接続できます。すべてのデータは PostgreSQL に保存されるため、 pg_dump 、レプリケーション、ポイントインタイムリカバリ、標準的な監視など、すでに知っている運用ツールを利用できます。 ストレージレイヤー は Rust の trait として定義されています。水平スケールに適した Apache Cassandra など、追加のバックエンドをコアを変更することなく実装できます。 ExtendDB は外部ランタイム依存性のない 単一バイナリ にコンパイルされます。 TLS は必須であり、初回実行時に自己署名証明書を自動生成します。ローカル IAM ライクなクレデンシャルストアを備えた SigV4 認証 により、アプリケーションコードは DynamoDB サービスに対して使用するのと同じ署名ロジックを使用します。 サポートされるオペレーション カテゴリ オペレーション テーブル CreateTable、DeleteTable、DescribeTable、ListTables、UpdateTable アイテム PutItem、GetItem、DeleteItem、UpdateItem (条件式付きの SET、REMOVE、ADD、DELETE) Query と Scan キー条件、フィルター式、プロジェクション、ページネーション、セカンダリインデックスの選択 バッチとトランザクション BatchGetItem、BatchWriteItem、TransactGetItems、TransactWriteItems ストリーム ListStreams、DescribeStream、GetShardIterator、GetRecords TTL UpdateTimeToLive、DescribeTimeToLive インポート / エクスポート ImportTable、ExportTableToPointInTime タグ TagResource、UntagResource、ListTagsOfResource アカウントとクレデンシャルの管理は、コマンドラインまたは https://127.0.0.1:8000/console/ の Web 管理コンソールから行えます。 利用開始 ExtendDB は Linux と macOS で動作します。Rust 1.85+ と PostgreSQL 14+ が必要です。 git clone https://github.com/ExtendDB/extenddb.git cd extenddb cargo build --release init コマンドは、稼働中の PostgreSQL インスタンスに接続し、必要なデータベースとスキーマを作成し、管理者用クレデンシャルを生成し、TLS 証明書をプロビジョニングし、設定ファイルを書き出します: ./target/release/extenddb init ./target/release/extenddb serve --config extenddb.toml 次に、DynamoDB アクセス権を持つ IAM ユーザーを作成します。 init コマンドは、 extenddb manage で使用する管理者パスワードとデフォルトのアカウント ID を出力します: ./target/release/extenddb manage --user admin --password '&lt;admin-password&gt;' \ create-user --account-id &lt;account-id&gt; --user-name myuser ./target/release/extenddb manage --user admin --password '&lt;admin-password&gt;' \ put-user-policy --account-id &lt;account-id&gt; --user-name myuser \ --policy-name full-access \ --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"dynamodb:*","Resource":"*"}]}' ./target/release/extenddb manage --user admin --password '&lt;admin-password&gt;' \ create-access-key --account-id &lt;account-id&gt; --user-name myuser これによりアクセスキー ID とシークレットが返されます。CA バンドルとともにこれらをエクスポートします: export AWS_ACCESS_KEY_ID="AKIA..." export AWS_SECRET_ACCESS_KEY="extenddb..." export AWS_CA_BUNDLE=~/.extenddb/tls/cert.pem ExtendDB は https://127.0.0.1:8000 でリッスンしています。標準的な DynamoDB コマンドを使用します: aws dynamodb create-table \ --table-name Orders \ --attribute-definitions AttributeName=PK,AttributeType=S AttributeName=SK,AttributeType=S \ --key-schema AttributeName=PK,KeyType=HASH AttributeName=SK,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 aws dynamodb put-item \ --table-name Orders \ --item '{"PK":{"S":"CUSTOMER#123"},"SK":{"S":"ORDER#2026-001"},"total":{"N":"49.99"}}' \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 aws dynamodb query \ --table-name Orders \ --key-condition-expression "PK = :pk" \ --expression-attribute-values '{":pk":{"S":"CUSTOMER#123"}}' \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 AWS SDK はエンドポイント URL の設定をサポートしています。エンドポイント URL を変更するだけで、その他はすべて変更不要です。 アーキテクチャ ExtendDB は責務を Rust の crate に分離しています。 core crate は、純粋な同期 Rust として型、検証、式の評価を処理します。 engine crate は DynamoDB API のセマンティクスを実装します。 storage-postgres crate は PostgreSQL バックエンドであり、任意のバックエンドが実装すべきインターフェースを定義する storage trait に対して構築されています。 server crate は HTTP サーバー、管理 API、Web コンソールを提供し、これらを統合します。 次のアーキテクチャ図は、ExtendDB の高レベルの概要を示しています: 制限事項 ExtendDB は DynamoDB ではありません。これは互換性のある実装であり、マネージドサービスの代替ではありません。パフォーマンス特性、スケーリング動作、運用上の特性は異なります。マネージドサービスの保証が必要な場合は DynamoDB を使用してください。 データベースが必要であり、その可用性、バックアップ、メンテナンスはユーザーの責任です。TLS は必須です。ExtendDB は SigV4 署名検証とポリシー評価を備えた独自の IAM ライクな実装を含みます。これはスタンドアロンのシステムです。ExtendDB で作成されたクレデンシャルとポリシーは AWS IAM とは完全に分離されており、両者の間で共有することはできません。グローバルテーブルとクロスリージョンレプリケーションは、これらが DynamoDB 固有のマネージド機能であるため実装されていません。 参加するには 本記事では、PostgreSQL をバックエンドとするオープンソースの DynamoDB 互換アダプターである ExtendDB を紹介しました。ローカル開発、CI/CD テスト、オンプレミスデプロイメント、エアギャップ環境のいずれであっても、AWS の外で DynamoDB アクセスパターンを必要とするワークロードがある場合、ExtendDB は既存のアプリケーションコードと SDK で動作する互換性のある実装を提供します。 ExtendDB は初期段階にあり、私たちはオープンに開発を進めています。 GitHub リポジトリ をクローンし、 Getting Started ガイド に従って、数分で DynamoDB 互換エンドポイントをローカルで実行できます。コントリビュート方法の詳細については、 Contribution Guide を参照してください。ギャップを発見した場合や、ストレージバックエンドをコントリビュートしたい場合は、issue を起票するか、プルリクエストを送信してください。 著者について Lee Hannigan Lee はアイルランドのドニゴールを拠点とするシニア Amazon DynamoDB データベースエンジニアです。彼はビッグデータと分析技術の強固な基盤の上に、分散システムにおける豊富な専門知識を持っています。彼の役割では、DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に注力し、お客様や社内チームがその機能を最大限に活用できるよう支援しています。 Deepthi Mohan Deepthi は DynamoDB チームのプリンシパルプロダクトマネージャーです。