本記事は 2026 年 6 月 5 日 に公開された「 Adding LINE Messenger to your AWS omnichannel fallback solution 」を翻訳したものです。 本記事では、既存のオムニチャネルフォールバックソリューションに LINE Messenger を統合して拡張する方法を説明します。アーキテクチャの変更点、デプロイ手順、テスト手順についても取り上げます。元のソリューションは Amazon API Gateway 、 AWS Lambda 、 Amazon Simple Email Service (Amazon SES) 、 AWS End User Messaging で構築されており、SMS、WhatsApp、メールを横断して自動フォールバック機能付きでメッセージを配信します。 本記事が拡張対象とする元のオムニチャネルフォールバックソリューションについては、 Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS を参照してください。 LINE Messenger を選ぶ理由 LINE は日本、台湾、タイで広く使われているメッセージングプラットフォームであり、主要市場での月間アクティブユーザー数は 1 億 8,100 万人、うち日本だけで 1 億人に達します ( LY Corporation FY2025 Q3 業績データ )。DAU/MAU 比率は 84% (日本では 88%) と高く、毎日活発に利用されているため、医療分野の予約リマインダー、EC の注文・配送通知、小売のプロモーションキャンペーンなど、タイムリーなコミュニケーションに適したチャネルです。 APAC には KakaoTalk (韓国)、WeChat (中国)、Zalo (ベトナム)、Viber (フィリピン) といった各国で人気のメッセージングプラットフォームが存在しますが、LINE は日本・台湾・タイの 3 市場で同時に強い存在感を持っており、これらの国々を対象としたマルチチャネルメッセージング戦略に高い効果をもたらします。オムニチャネルフォールバックソリューションに LINE を追加することで、各市場のユーザーが好むチャネルでリーチできるようになります。LINE はプライマリチャネルとしてもフォールバックチャネルとしても利用でき、他のチャネルで実装済みのフォールバック・ブロードキャストのパターンをそのまま活用できます。 費用について: LINE Messaging API の料金は国やプランによって異なります。各チャネルの詳細は LINE Messaging API 、 Amazon Simple Email Service (Amazon SES) 、 Amazon End User Messaging の料金ページをご覧ください。 アーキテクチャの概要 フォールバックソリューションに LINE を追加することで、単一の API エンドポイントから 4 つの主要メッセージングチャネルをカバーできます。既存の複雑さを増やさずにリーチを広げられる点が特長です。LINE の統合は既存チャネルと同じイベント駆動型のサーバーレスパターンに従います。次の図はアーキテクチャへの主な追加点を示しています。 図 1: LINE Messenger を追加した更新後のオムニチャネルアーキテクチャ (新規コンポーネントをハイライト表示) 既存のアーキテクチャに 2 つの要素を追加するだけで、LINE ユーザーにリーチできます。 LINE Messaging API の統合 – Primary Handler Lambda と Secondary Handler Lambda に send_line モジュールが追加され、Push Message エンドポイントを通じて LINE Messaging API でメッセージを配信します。 AWS Secrets Manager の統合 – LINE チャネルの認証情報 (アクセストークンとチャネルシークレット) は AWS Secrets Manager に安全に保存され、Lambda 関数がキャッシュを活用して取得します。 LINE 統合の仕組み LINE Messenger の統合は既存のメッセージ処理パイプラインを拡張する形で実装されているため、メール、SMS、WhatsApp と同じ信頼性の高いフォールバック動作が LINE でも利用できます。以下のセクションでは、システムが LINE メッセージとフォールバックシナリオをどのように処理するかを説明します。 LINE メッセージの送信 LINE をプライマリまたはフォールバックチャネルとしてメッセージを送信する場合、LINE 固有の処理を含む同じパターンに従います。 API Gateway がリクエストを受信し、Primary Amazon Simple Queue Service (Amazon SQS) キューに追加します。 Primary Handler Lambda がチャネルを “line” と検出し、 send_line モジュールを呼び出します。 send_line モジュールが Secrets Manager から LINE の認証情報をキャッシュ付きで取得し、LINE Messaging API の Push Message エンドポイントにリクエストを送信します。Push Message API はユーザーが先にメッセージを送ることなく LINE ユーザーへのメッセージ送信を可能にします。リクエストボディには受信者の LINE ユーザー ID (ユーザーが LINE 公式アカウントをフォローした際に割り当てられる一意の識別子) を含む to フィールドと、配信するメッセージオブジェクトを格納した messages 配列が含まれます。モジュールは LINE API を呼び出す前に、受信者の LINE ユーザー ID が期待されるフォーマット (大文字の ‘U’ に続く 32 文字の小文字 16 進数文字) と一致するか検証します。不正な受信者 ID のリクエストは早期に拒否され、外部 API に到達しません。 Lambda 関数がメッセージのステータスを Amazon DynamoDB テーブルに記録します。 フォールバックが設定されている場合、Lambda 関数はメッセージをフォールバックキューにエンキューします。このエンキューは LINE API 呼び出しが成功 (HTTP 200) した場合でも失敗 (200 以外のレスポンス、タイムアウト、または例外) した場合でも実行されます。DynamoDB には成功時に delivered 、失敗時に failed としてメッセージステータスが記録されます。Secondary Handler は DynamoDB を確認し、ステータスが delivered でない場合にフォールバックチャネルで送信します。 Secondary Handler が DynamoDB のステータスを sent_fallback に更新します。 LINE と他チャネルの違い 項目 メール SMS WhatsApp LINE API Amazon SES SendEmail API AWS End User Messaging SendTextMessage API AWS End User Messaging Social SendWhatsAppMessage API LINE Messaging API Push Message API 認証 IAM ロール IAM ロール IAM ロール Secrets Manager 経由のチャネルアクセストークン 外部メッセージ ID のマッピング 不要。 SES は配信コールバックで同じメッセージ ID を返します。 不要。 SMS は配信コールバックで同じメッセージ ID を返します。 必要。 WhatsApp は配信 Webhook で異なるプラットフォームメッセージ ID を返すため、内部の AWS メッセージ ID へのマッピングが必要です。 不要。 配信コールバックがないため、メッセージ ID の紐付けは不要です。 認証情報の保存 IAM (自動) IAM (自動) IAM (自動) Secrets Manager (手動) 配信追跡 SES 配信イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) End User Messaging イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) End User Messaging イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) なし。LINE API からの 200 レスポンス時に即時 delivered に設定。LINE Messaging API には配信 Webhook なし。 LINE は AWS ネイティブの IAM 認証ではなく独自の認証を持つ外部 API を使用します。そのため、認証情報の管理には IAM ではなく AWS Secrets Manager を使用する必要があります。詳細は LINE Messaging API ドキュメント を参照してください。 LINE はビジネス向けに 2 種類のメッセージングプロダクトを提供しています。LINE Messaging API と LINE Official Notification です。 LINE Messaging API は本ガイドの対象であり、双方向の会話型メッセージングをサポートし、モバイルオーダー、ロイヤルティプログラム、カスタマーエンゲージメントなど多くの業種で広く採用されています。LINE には LINE Official Notification (LINE 通知メッセージとも呼ばれる) という別サービスもあり、配送状況通知や予約リマインダーといった一方向のトランザクション通知向けに設計されていますが、ビジネス認証が必要です。 LINE Official Notification はメッセージごとの配信完了イベントを提供しますが、LINE Messaging API にはその機能がありません。Messaging API では HTTP 200 レスポンスが LINE によるメッセージ受け付けを示しており、これが利用可能な最も詳細な配信シグナルです。 LINE Messaging API チャネルの作成 LINE 統合でメッセージを認証・送信するには LINE Messaging API チャネルが必要です。手順は以下のとおりです。 LINE Developers Console にサインインします。アカウントをお持ちでない場合は 個人 LINE アカウント を作成し、対応する iOS/Android/PC アプリをダウンロードします。LINE メッセージの受信テストに必要です。 プロバイダーを作成します (会社名または組織名)。 そのプロバイダーの下に新しい Messaging API チャネルを作成します。 チャネル作成後、LINE Official Account Manager ページから Messaging API を有効化します。 チャネル設定から以下の情報を控えます。 チャネルアクセストークン (Messaging API タブで [Issue] を選択) チャネルシークレット ([Basic settings] タブ) Messaging API 設定で Auto-reply と Greeting messages を無効にします。 デプロイとテスト リポジトリには、CDK スタックのデプロイ、AWS Secrets Manager での LINE 認証情報の設定、個人の LINE ユーザー ID の取得、インテグレーションテストスイートの実行まで、手順を詳しく説明したデプロイガイドが含まれています。テストスイートは設定済みのチャネルを自動的に検出し、対応するテストを実行します。デプロイとテストの詳細については、 リポジトリ のデプロイガイドを参照してください。 セキュリティに関する考慮事項 本ソリューションを本番環境にデプロイする前に、以下の考慮事項をワークロードとコンプライアンス要件に照らして確認してください。 最小権限の IAM サンプルの Lambda 実行ロールは、DynamoDB、Amazon SQS、AWS Secrets Manager のアクセス許可を特定のリソース ARN にスコープしています。Amazon SES ( ses:SendEmail 、 ses:SendTemplatedEmail )、SMS ( sms-voice:SendTextMessage )、WhatsApp ( social-messaging:SendWhatsAppMessage ) の送信アクションは、このサンプルでは特定の送信 ID、電話プール、WhatsApp ビジネスアカウントを設定可能な状態にするため、シンプルに resources: [“*”] で付与しています。本番環境では API がサポートする範囲でさらにスコープを絞ってください。SES は ID レベルの ARN (例: arn:aws:ses:region:account:identity/example.com ) をサポートし、End User Messaging SMS はプールおよび電話番号 ARN をサポートします。このコードを適用する際は、サポートされているすべての項目にリソースレベルのスコープを維持し、本番デプロイ向けの AWS Well-Architected セキュリティの柱と Lambda 実行ロールのガイダンスを確認してください。 LINE 認証情報のローテーション LINE チャネルアクセストークンは有効期限が長く、LINE Developers Console からの手動発行・ローテーションのみサポートされています。プログラムによるローテーション API はありません。組織のキーローテーションポリシー (例: 90 日ごと) に沿って定期的にトークンをローテーションし、Secrets Manager のシークレットを新しい値に更新してください。また、キャッシュされた認証情報が更新されるよう、Lambda のコールドスタートを強制してください (スタックの再デプロイまたは Lambda 環境変数の更新による)。 データ保護と個人情報の保持 本ソリューションは、LINE ユーザー ID、電話番号、メールアドレスなどのメッセージメタデータと受信者識別子を Amazon DynamoDB に保存します。DynamoDB は保存時の AWS マネージド暗号化を使用し、Secrets Manager は AWS Key Management Service (AWS KMS) を使用します。また、LINE API へのすべての送信呼び出しは HTTPS で行われます。メッセージテーブルでは Point-in-time recovery が有効です。 本サンプルでは DynamoDB の Time-to-Live (TTL) 属性を設定していないため、レコードは無期限に保持されます。本番環境では、保持ポリシーに合った TTL 属性 (例: expiresAt) を追加し、テーブルの RemovalPolicy.RETAIN 設定がお使いの環境に適切かどうかを確認してください。LINE ユーザー ID、電話番号、メールアドレスは、日本の個人情報保護法 (APPI)、EU の GDPR をはじめとする各種規制において個人情報に該当します。サービス提供地域ごとの保持義務、データレジデンシー要件、データ主体からのアクセスおよび削除リクエストへの対応プロセスを検討してください。 まとめ オムニチャネルフォールバックソリューションに LINE Messenger を追加することで、メール、SMS、WhatsApp、LINE という重要な 4 つのメッセージングチャネルで顧客にリーチできるようになりました。統合は既存チャネルと同じサーバーレス・イベント駆動型のパターンに従っているため、デプロイと運用がシンプルです。LINE はプライマリチャネルとしてもフォールバックチャネルとしても利用でき、地域の好みに合わせたメッセージング戦略を柔軟に構築できます。次のステップとして、他の地域向けメッセージングサービスを追加してリーチをさらに拡大することを検討してください。また、リッチメッセージ、クイックリプライ、Flex Messages など LINE の高度な機能を活用することで、より魅力的なカスタマーインタラクションを実現できます。 リソース GitHub リポジトリ Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS LINE Developers ドキュメント AWS CDK ドキュメント 著者について Rommel Sunga シンガポール拠点の AWS シニア Solutions Architect。AWS End User Messaging と Amazon Simple Email Service を専門とし、スケーラブルで信頼性の高いコミュニケーションソリューションの構築をお客様と共に取り組んでいます。クラウドベースのメッセージングアーキテクチャの専門知識を活かし、組織のカスタマーエンゲージメント向上を支援しています。 Katsuya Matsuoka 日本拠点の AWS Solutions Architect。メディア業界のお客様を担当しており、レイクハウスアーキテクチャを含むデータ分析を中心に取り組んでいます。 Pavlos Ioannou Katidis Amazon Simple Email Service (SES) と AWS End User Messaging を専門とする AWS シニアスペシャリスト Solutions Architect。スケーラブルで回復性の高いソリューションの設計を得意とし、大規模コミュニケーションシステムやオムニチャネルフレームワークの構築に注力しています。幅広く採用されている AWS ワークショップ、ブログ、技術ソリューションを執筆し、生成 AI を活用した社内ツールの開発でプロセス効率化と生産性向上に貢献しています。re:Invent では、耐障害性の高い通知システム、ワンタイムパスワードの実装、大量メッセージングのベストプラクティスをテーマに登壇。テニス、ウォーキング、個人のコーディングプロジェクトを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Katsuya Matsuoka がレビューしました。

英語版ブログ： “ Highlights from the 2026 AWS Life Sciences Symposium: Research and Drug Discovery ” ライフサイエンス業界全体で、研究者たちは実験の設計方法、データの解釈、そしてシミュレーションとウェット実験を結ぶ創薬サイクルのあり方を根本から変えつつあります。AI エージェントは、この新薬候補の発見プロセス全体を加速させています。2026年5月に開催された 2026 AWS Life Sciences Symposium では、Sanofi、Genentech、Noetik、Apheris、Bristol Myers Squibb、Memorial Sloan Kettering などのリーダーたちが、科学的発見の加速と患者アウトカムの改善のために、エージェンティックAIを現在どのように活用しているかを紹介しました。 研究を変革する 3 つの能力 本シンポジウムを通じて、研究イノベーションの基盤となる3つの能力が浮き彫りになりました。これらは相互に連携し合うものです。 リアルラボ（Wet）とデジタルラボ（Dry）の接続 — ウェットラボを計装化し、実験データが自動的にシミュレーションシステムへ流れ込む仕組みを作ることで、仮説→実験→結果のサイクルを途切れなく回す。 FAIR（ Findable, Accessible, Interoperable, Reusable ）かつガバナンスの効いたデータ基盤の構築 — AI エージェントが推論に必要な科学的コンテキストを備え、インサイトが信頼できるデータに裏付けられるようにする。 強力なAIツールを研究者の手に直接届ける — 生物学的基盤モデルから自律的研究エージェントまで、一部の専門家だけでなく、すべての研究者が日々の業務でAIの全能力を活用できるようにする。 この3つの柱こそが、真の「 lab-in-the-loop 」を形づくる条件です。 本トラックは、ビジョンを示すセッションで幕を開け、なぜ今この瞬間が重要なのかを参加者に伝えました。目覚ましい科学的進歩にもかかわらず、創薬はヒト生物学の膨大な複雑さに依然として制約されています——細胞、化合物、分子間相互作用が生み出す途方もない組み合わせが生む探索空間、そして治療領域・組織・分野を越えて残り続ける知識交換のギャップがその要因です。より豊かな生物学データ、モダンなデータ基盤、そして新世代の AI が融合することで、これらのギャップは埋まり始めています。鍵となるのは、データ・基盤・AI の間をつなぐ仕組みを築き、インサイトが好循環で加速する構造を作ることです。これが lab-in-the-loop の本質です。 ループを閉じる：Amazon Bio Discovery を活用した AI 支援による抗体設 本イベントの目玉発表の一つとして、午前の基調講演で初めて披露され、本セッションで詳細が語られたのが、 Amazon Bio Discovery のローンチです Amazon Bio Discovery は、AI駆動の抗体探索に特化して構築された統合アプリケーションです。lab-in-the-loop ワークフローを阻害する最も一般的な課題——評価すべきモデルが多すぎる、データが断片化している、インシリコ実験とウェットラボでのバリデーションの調整が困難——に対処するよう設計されています。本アプリケーションは、これらを単一のセキュアでスケーラブルな環境に統合し、以下の機能を提供します： コードではなく科学用語で研究者をモデル選択・実験設計・候補評価へとガイドするエージェンティックAIアシスタント 40 以上のオープンソースおよび商用 Biological Foundation Model（生物学的基盤モデル）のカタログへのアクセス モデル間のヘッドトゥヘッドベンチマーク モデルトレーニング これらすべてが GUI 操作のみで完結するため、あらゆる研究者が初日から高度な探索ワークフローを実行できます。 Memorial Sloan Kettering （ MSK ）との印象的なケーススタディでは、チームが Amazon Bio Discovery の AI エージェントを使用し、ターゲットタンパク質の実験構造データや既存の抗体データが一切ない状態から、新規のデスモプラスティック小円形細胞腫瘍（ DSRCT ）ターゲットに対する de novo ナノボディバインダーを設計しました。3 つの de novo 設計手法（ RFantibody、IgGM、mBER ）を使用して 288,000 以上の候補配列を生成し、多目的パレート最適化でフィルタリングした上で、上位候補を Twist Bioscience に送付しウェットラボでバリデーションを行いました。その結果、46 個のバインダーが確認され、トップ候補は KD = 0.66 nM のサブナノモル親和性を達成。ターゲット選定からラボでの検証完了まで、わずか数週間でした。 Twist Bioscience は CRO（受託研究機関）パートナーとして抗体エンジニアリングと生物物理学的キャラクタリゼーションの専門知識を提供し、 Amazon Bio Discovery の CRO パートナーネットワークが自社ラボの枠を超えて lab-in-the-loop 能力を拡張できることを示す好例となりました。 本セッションでは、Johns Hopkins Whiting School of Engineering の Gray Lab との連携で開発された Antibody Developability Benchmark Dataset も紹介されました。本ベンチマークは、公開文献において最大かつ最も多様な抗体データセットで構成されており、4 つの構造フォーマット（ IgG、VHH、NearGermline-IgG、scFv ）にわたる 50 のシード抗体を含み、42 の異なる抗原を標的とし、シードあたり最大 99 のエンジニアリングバリアントを持ちます。評価対象は 6 つの主要な開発性（developability）特性——発現、純度、熱安定性、凝集、ポリリアクティビティ、疎水性——であり、すべてウェットラボ実験で検証済みです。このベンチマークは、AI モデル評価のために長年求められてきた厳密な基準を提供するとともに、モデルが事前にデータセットを学習していない状態で評価できるゼロショット推論にも対応しています。ベンチマーク結果は現在、 Amazon Bio Discovery の一部として利用可能です。 Boltz はセッションの最後に、 Amazon Bio Discovery へ近日提供予定の独自基盤モデルをプレビューしました。改良された基盤モデルの上に、タンパク質-タンパク質親和性予測と開発性フィルターを追加しています。また、説得力のある推論時スケーリング則を実証しました：生成するデザイン数を増やすほどヒット率は継続的に向上し、60,000 から 180,000 デザインの範囲でも改善が続くことが示されました。 発見サイクルの加速：Sanofi の AWS 上の集中型 lab-in-the-loop Sanofi の R&D データプラットフォーム＆プロダクツ責任者である Sabya Dasgupta 氏と、プラットフォーム＆AI ワークフロー責任者である Pradeep Bandaru 氏が、世界最大級の製薬企業の 1 つが AWS 上でエンタープライズ規模の lab-in-the-loop 能力をどのように構築しているかを共有しました。 Sanofiの取り組みから得られた核心的な洞察は、「コンテキストこそが新たなコンピュートである」ということです。パイプラインがどれだけ改善されても、科学的コンテキストを持たないAIエージェントは、すでに試みられた推奨を繰り返し、実験的背景を欠いたままデータを解釈し、良い判断ではなく悪い判断をスケールさせてしまいます。 Sanofi が辿り着いた答えが、 SWEL（Scientific Workflow Experience Labs）です。これは AI エージェントをコンテキスト認識型にし、複雑なコンピュートチェーンをオーケストレーションするオペレーションレイヤーです。AWS上に構築され Amazon Bedrock AgentCore を基盤とする SWEL は、創薬プロセスのあらゆる層にコンテキストを行き渡らせます。具体的には、AI 駆動の分子設計や SIPS（Sanofi 社の統合データ基盤）から始まり、実験の自動化、ワークフローの連携・計算処理のチェーンを経て、最終的には「この分子は過去にどのような検討を経たか」「前回のサイクルで何が起きたか」「なぜこの設計にしたか」「どこで失敗したか」といった文脈を理解する科学的推論エージェントにまでつながります。 成果は明白です：SWEL は MVP（Minimum Viable Product）を 2.5 か月で出荷し、現在 50 以上の科学ワークフローを支え、20 PB 以上の科学データプロダクトへのアクセスを提供し、同じ期間で 2～3 倍のプロジェクトを可能にし、デプロイ速度を 10 倍に加速しました。 際立つユースケースは AI Autolead でした。これは継続学習型のメディシナルケミストリーシステムで、10^13 を超える構造の特徴空間から、サイクルあたり 10 億以上の列挙分子をスクリーニングします。数百の ADME（Absorption, Distribution, Metabolism, Excretion：吸収・分布・代謝・排泄）モデルおよびターゲット AI モデルと、28 の検証済み反応を活用しています。結果：プログラムあたりの生成分子数が 50% 以上削減されつつヒット品質は向上し、ルーチンの de novo 設計が全モダリティで実行されるようになりました。 データインフラの側面では、AWS がエージェンティックコード生成によりインストルメントデータコンバーターの開発を大幅に加速できることを実演し、開発期間を数週間から数分に短縮しました。20 のインストルメントファイルタイプを対象とした評価では、ASM（Allotrope Simple Model）形式変換において 100% のパス率を達成し、ゼロショット生成の 35% と比較して大きな改善を示しました。 研究用途を超えたエージェント展開：Roche の Galileo プラットフォーム Rocheのグローバルヘッド兼 VP Diagnostics R&D である Arick Huensche 氏が、Roche が 90,000 台以上の接続されたラボ機器を横断して、エージェンティック AI をエンタープライズ規模でどのように展開しているかを語りました。 Roche の Galileo プラットフォーム— Amazon Bedrock および Bedrock AgentCore 上に構築されたエージェンティック AIプラットフォーム——は研究プロトタイプではありません。70,000人以上のユーザーにサービスを提供し、Roche のDIA（Diagnostics）R&D ドメイン全体で 29 のエージェントがデプロイされた本番インフラです。このプラットフォームにより、AI エージェントがデータの移動、メタデータの抽出、結果のバリデーション、ワークフローのオーケストレーションを行い、厳密性とトレーサビリティを維持しながら、複雑な科学プロセスを自然言語でのインタラクションに変換します。 2つのプロトコルイノベーションが注目を集めました。MCP（Model Context Protocol：モデルコンテキストプロトコル）は、AgentCore Gateway を通じて利用され、数百のラボ機器 API、LIMS/ELN（Laboratory Information Management System / Electronic Lab Notebook：ラボ情報管理システム/電子実験ノート）コネクター、バイオインフォマティクスパイプラインのトリガーを、既存システムを書き換えることなく MCP ツールとして公開できるようにしています。もう一つのA2A（Agent-to-Agent：エージェント間通信）プロトコルは、エージェントフレームワークやベンダーを横断した自律的コラボレーションを可能にするものです。タスクライフサイクルの状態管理が定義されており、Strands、LangGraph、CrewAI、Google ADK、OpenAI SDK にまたがるクロスフレームワーク相互運用性を実現しています Arick 氏の業界への主要なメッセージ：エージェントは広範な機能ではなく jobs-to-be-done（解決すべきジョブ）にスコープすること、エージェントの活用を考える前にまずデータ基盤へ重点投資すること、そしてガバナンスを制約ではなく機能として扱うこと。規制環境では、ビルトインのコンプライアンスが導入を加速します。なぜなら、科学者は監査可能なものを信頼するからです。 AWS ツールの観点からは、Brian Loyal 氏がデータサイエンス、バイオインフォマティクス、ラボプロセス自動化のワークフローにおいてお客様が AgentCore をどのように採用しているかを実演しました。これにより、チームは科学的厳密性を犠牲にすることなく、より迅速に前進できます。 AI サイエンスファクトリーのスケーリング：Lila Sciences Lila Sciences の VP of Next Generation Platform である Bob Gantzer 氏は、lab-in-the-loop で何が達成できるかについての大胆なビジョン——AI サイエンスファクトリー——を発表しました。 Lila が構築しているのは、単一の AI モデル——いわば「科学的インテリジェンス」——であり、科学のサイクル全体を回すために必要なツール群を備えています：知識ベース、ユニバースシミュレーター、計算ツール、そして AI サイエンスファクトリーです。目標は科学的方法そのものを再発明することであり、機器の完全なパラメトリゼーション、動的実行、スケールされたデータパイプラインを通じて、AI がラボで自律的に仮説生成・実験・学習のサイクルを回す「セルフプレイ」を実現することです。 印象的なデモンストレーションでは、Lila のシームレスな mRNA 設計から実験までのワークフローが示されました。生成 AI による分子選択から、自動合成、ADME アッセイ実行、ML モデル再トレーニングまで——すべてがサイエンティフィックグラフ（科学ワークフローグラフ）を通じてオーケストレーションされています。Lila の mRNA 設計は業界トップクラスの in vivo 性能を実証しており、プラットフォームは現在、タンパク質、RNA、DNA、低分子、触媒、ナノ粒子、そしてその先にまで展開されています。 生物学向け AI モデルの進化：データ駆動型モデルトレーニング 最終セッションでは、 Noetik CEO 兼共同創業者の Ron Alfa 氏、 Apheris CEO 兼共同創業者の Robin Roehm 氏、Bristol Myers Squibb SVP Therapeutic Discovery Sciences の Payal Sheth 氏が集まり、生物学基盤モデルトレーニングの最前線について深く掘り下げました。 AWS は生物学基盤モデルの全体像を示しました：創薬に関連する公開済み基盤モデルの累積数は、2021 年初頭の1から2025 年半ばまでに 226 に成長し、タンパク質・分子構造、シングルセルトランスクリプトミクス、バイオイメージング、DNA配列、マルチモーダルデータにまたがっています。AWSは、 Amazon Bio Discovery によるファインチューニングや Amazon Bedrock でのサーバーレスカスタマイゼーションから、 Amazon SageMaker HyperPod での大規模分散トレーニング、 Amazon Nova Forge によるフロンティアモデル開発まで、モデルカスタマイゼーションの全スペクトラムを提供しています。Nova Forge は、独自データを Amazon Nova のチェックポイントおよびキュレーションされたトレーニングデータとブレンドすることで、ゼロから構築する場合と比較して 10～100 分の 1 のコストでカスタムフロンティアモデルを構築できます。 BMS と Apheris は、AI Structural Biology（AISB）Network の次なる展開を紹介しました。AISB は製薬企業間の連合学習（Federated Learning）ネットワークであり、現在 9 社が参加して運用されています。AISB-1 連合コフォールディングモデルは、5 社のデータを用い 10 週間未満でトレーニングされ、構造的に信頼性の高い結合サイト相互作用の割合（ lDDT > 0.8）において 51% を達成しました。これは OpenFold3 ベースラインの 34% 、平均的な単一企業ファインチューニングモデルの 39% と比較して優れた結果です。AISB-1 は現在 Amazon Bio Discovery で利用可能です。AISB-2 は開発中であり、構造データ、定量的親和性データ、HTS スケールのバイナリ活性データにわたる桁違いに多い独自データを使用して、構造ベースのバーチャルスクリーニング、リード最適化、オフターゲットスクリーニングのための、より広範で汎化性の高い基盤モデルを目指しています。 Noetik はセッションの最後に大胆な主張を展開しました：「 AI 創薬はこの10年間、間違ったデータ——細胞株、マウスモデル、パブリックデータセット——でトレーニングしてきた」。Noetik のアプローチはリアルなヒトデータから始まります。商業ルートで調達し自社が完全に権利を保有するヒト腫瘍検体（ FFPE ）を、特許出願中のロボティクス支援ワークフローで処理し、H&E、タンパク質、空間 RNA、DNA データとペアリングしています。このマルチモーダル患者データセットでトレーニングされた基盤モデルは、Noetik が特定した患者集団においてゼロショット推論で 56% の客観的奏効率（ ORR ）を達成しました。元の臨床試験での ORR 8% と比較して大幅な改善です。スケーリング則は生物学にも当てはまります：性能はモデルサイズとコンテキスト長に応じて大幅に向上し、プラトーの兆候は見られません。 エージェンティック・ディスカバリーの時代が到来 すべてのセッションを通じて、一つの共通メッセージが浮かび上がりました：創薬の未来は、より多くのモデルやコンピュートではなく——コンテキスト、オーケストレーション、そして AI と実験の間のループを閉じることにあります。 2026 AWS Life Sciences Symposium の研究・創薬トラックは、エージェンティック AI がもはや将来の約束ではないことを明確にしました。それは Sanofi、Roche、BMS などにおける本番インフラです。MSK における検証済みの科学です。Noetik における新しいアセットクラスです。そして、次世代の医薬品が構築される基盤です。 AWS は、この転換点においてライフサイエンス業界とパートナーシップを組めることを誇りに思います。科学的野心を患者へのインパクトに変えるコンピュート、モデル、データインフラ、エージェンティックフレームワークを提供してまいります。エージェンティック・ディスカバリーの時代は、すでに始まっています。問われているのは、構築するかどうかではなく——どれだけ速く構築するかです。 亀田　俊樹 ( Toshiki Kameda ) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（DTx 含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

お知らせ 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年2月6日に公開された Building fault-tolerant applications with AWS Lambda durable functions を翻訳したものです。翻訳はSolutions Architectの加藤 諒が担当しました。 ビジネスアプリケーションでは、顧客オンボーディング、決済処理、大規模言語モデル推論のオーケストレーションなど、確実に実行する必要がある、あるいは長期間の待機が必要な、複数のステップを連携させることがあります。これらは、一時的な中断やシステム障害があってもプロセスを完了する必要があります。そのため、開発者はビジネスロジックではなく 進捗の追跡、障害の処理、外部イベントの待機時のリソース管理のメカニズムの実装といった付加価値を生まない作業に時間を費やしています。 re:Invent 2025で、 Amazon Web Services (AWS) は AWS Lambda durable functionsを発表しました。これは、使い慣れたプログラミング言語を使用して耐障害性のある複数のステップが必要なアプリケーションとAIワークフローを構築するための新しい機能です。基本的に、durable functionsは通常のLambda関数であるため、Lambdaの開発および運用プロセスは引き続き適用されます。ただし、Lambda関数を作成する際に、durable executionを有効にすることで、進捗のチェックポイント保存、障害からの自動回復が可能になります。また、human-in-the-loopプロセスなどの長時間実行タスクを待つ間、最大1年間実行を一時停止できます。 標準のLambda関数を使用する場合、コードは単一の呼び出しで開始から終了まで実行されます。実行中のいずれかの時点で障害が発生した場合、呼び出し元のイベントソースによって関数全体を再試行する必要があります。実行間で保持する必要がある状態は、明示的に保存および取得する必要があります。これは通常、 Amazon DynamoDB や Amazon Simple Storage Service (Amazon S3 )などの外部ストレージサービスを使用して行われます。さらに、同じイベントの重複（同時）呼び出しを防ぎ、イベントの処理を継続しながら安全に更新をデプロイする対策を講じる必要があります。 対照的に、Lambda durable functionsでは、開発者はイベントハンドラーで「Steps」や「Waits」などのdurable operationsを使用して、進捗をチェックポイントし、障害を処理し、Lambda関数のコンピュート料金を発生させることなく待機期間中に実行を一時停止します。これらのdurable operationsとそれらから任意で返される状態は、durable execution backendで管理され、 自動的に永続化されます。実行中に障害が発生した場合、または一時停止後に関数が実行を再開した場合、Lambdaは関数を再度呼び出し、イベントハンドラーを最初から実行することで以前の状態を復元（リプレイ）しますが、完了したdurable operationsはスキップします。開発者向けがこのチェックポイント/リプレイの仕組みを簡単に利用できるようにするため、Lambda durable execution SDKを使用してイベントハンドラーをラップまたはアノテーションできます。具体的には既存のLambdaコンテキストにcontext.step()やcontext.wait()などのいくつかの新しいメソッドが追加されます。さらに、context.waitForCallback()などのメソッドを使用して、”human-in-the-loop”シナリオなどの外部ジョブや非同期プロセスを待機できます。SendDurableExecutionCallbackSuccessまたはSendDurableExecutionCallbackFailureレスポンスがLambda APIに送信されるまで実行は一時停止されます。 AWS Serverless Application Model (AWS SAM) で、AWS Quick Start Templateを使用して新しいdurable functionを作成します。 sam init コマンドで実行できます。 Lambda durable functionsは、 AWS Cloud Development Kit (AWS CDK) 、 AWS Command Line Interface (AWS CLI) 、 AWS CloudFormation 、およびTerraformなどの他のinfrastructure as code (IaC)フレームワークでもサポートされています。 ユーザーオンボーディングを実行する以下の関数を考えてみましょう。まず、ユーザーの入力データに基づいてユーザープロファイルを作成し、次に検証のためにメールを送信し、ユーザーがメールアドレスを確認するか、24時間のタイムアウトに達するまで待機します。最後に、確認を送信します。 import { DurableContext, withDurableExecution, } from '@aws/durable-execution-sdk-js'; export const handler = withDurableExecution( async (event: OnboardingEvent, context: DurableContext) => { try { // Create user profile const profile = await context.step("create-profile", async () => createUserProfile(event.email, event.name) ); // Wait for email verification via callback const verification = await context.waitForCallback( "wait-for-email-verification", async (callbackId) => { // Send email to user and pass callbackId await sendVerificationEmail(profile, callbackId); }, { timeout: { hours: 24 } } ); // Send confirmation and welcome email const result = await context.step("complete-onboarding", async () => { if (!verification || !verification.verified) return { ...profile, status: 'failed' }; await sendWelcomeEmail(profile.email, profile.name); return { ...profile, status: 'active' }; }); return result; } catch (error) { // omitted } } ); durable functionsには、組み込みでステップ用の カスタマイズ可能なエラー処理があります。たとえば、プロファイルが正常に作成され検証されたが、確認の送信時に一時的なエラーが発生した場合、そのステップが再試行されます。再試行では、プロファイル作成やコールバックなど、以前に完了したチェックポイントはスキップされます。確認送信ステップ内のコードのみが再度実行されます。 次に、durable functionを含めるためにAWS SAMテンプレートを更新します。関数にDurableConfig設定を含めることで、Lambda durable functionを作成します。現在、後からLambda関数にdurable configurationを追加することはできないことに注意してください。ExecutionTimeoutは、暴走やデッドロックといったアプリケーションバグから保護するために、durable executionがタイムアウトする時間を定義します。この設定は、単一の呼び出しが実行できる時間を定義するinvocation timeoutとは別です。単一関数呼び出しの最大invocation timeoutは15分で変わりません。Lambda durable functionsでは、SDKでの待機機能や自動再試行を使用する場合など、通常、1回の’durable executionにつき複数の呼び出しが発生します。非同期呼び出しを使用する場合、ExecutionTimeoutを最大1年間設定できます。 RetentionPeriodInDaysは、実行完了後にdurable executionの実行データが利用可能な期間を定義します。 AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Resources: UserOnboardingFunction: Type: AWS::Serverless::Function Properties: FunctionName: UserOnboardingFunction CodeUri: ./src Handler: index.handler Runtime: nodejs24.x Architectures: - x86_64 MemorySize: 256 Timeout: 60 // 1回のInvocationに対するタイムアウト DurableConfig: // この設定によりdurable functionsになる ExecutionTimeout: 90000 // durable execution全体のタイムアウト（25時間） RetentionPeriodInDays: 7 UserOnboardingFunctionRole: Type: AWS::IAM::Role // omitted for brevity また、関数に必要な権限を含める必要があります。たとえば、マネージドポリシー AWSLambdaBasicDurableExecutionRole を設定します。このポリシーはセキュリティを向上させるためにチェックポイントとログの作成/取得のための最小限の AWS Identity and Access Management (IAM) アクションのみを許可します。したがって、他の（durable）関数を呼び出したり、コールバックを管理する場合はこれでは権限が不足します。詳細については、 ドキュメント を参照してください。 関数をデプロイする前に、AWS SAM local invokeを使用してローカルでテストできます。 AWS SAMは関数をローカルで呼び出し、 context.waitForCallback() に到達するまでイベントハンドラーを実行します。コールバックを完了するために、AWS SAMはコールバックを必要とするdurable functionsをローカル実行した際に対話的にコールバックの返却ができます。この例では、コールバックを完了するために Success レスポンスを送信します。レスポンスに関連データを含めることもできます。画面上のガイドを使用して直接レスポンスを送信するか、別のプロセスから別のAWS SAM CLIコマンドを使用してレスポンスを送信できます。 sam local callback succeed <your-callback-id> --result '<your data>' AWS SAMを使用してdurable functionsの実行履歴を取得できます。これには、以下のサンプルコードに示すように、ステップ、コールバック、待機時間に関する詳細が含まれます。 sam local execution history <execution-arn> 必要にに応じて、代わりにコールバックにFailureレスポンスを送信し、コード内でそれらのエラーを処理できます。 sam local callback fail <your-callback-id> --error-data '<your data>' たとえば、後続のステップで補償ロジックを定義している場合にそれの動作を試すことができます。 関数が意図したとおりに動作することを確認できたので、 sam deploy コマンドを使用してAWSにデプロイします。 Lambda durable functionの呼び出しには、エイリアスやバージョンなどの修飾された Amazon Resource Name (ARN) が必要です。速度優先のプロトタイピングやローカルテスト以外では、 $LATEST 修飾子を使用しないことをお勧めします。明示的なバージョンを使用することで、リプレイが実行開始時と同じコードで常に実行されることが保証されます。これは、決定論的実行を確保し、実行中に関数コードを更新する際の不整合を防ぐためです。 お好みのパッケージマネージャーを使用して、durable execution SDKを関数コードにバンドルすることをお勧めします。SDKは高速に進歩しているため、新機能が利用可能になったときに依存関係を更新できます。 アプリケーションの構築に使用できる、Lambda durable functions SDKの その他のdurable operations があります： waitForCondition() ：条件が満たされるまで関数の実行を一時停止します。たとえば、APIでポーリングされるジョブのステータスなどです。これを機能させるには、waitStrategyとステータスをポーリングするチェック関数を提供します。 parallel() ：同じ関数内で複数のdurable operationsを並列実行し、最大同時ブランチ数や望ましい障害動作などの設定可能なオプションを提供します。これにより、同時非同期アクションの耐久性とチェックポイント管理が合理化されます。 map() ：提供されたマッピング関数に基づいて、配列の各項目に対してdurable operationとチェックポイントを作成します。項目は同時に処理されます。 invoke() ：別のLambda関数を呼び出し、その結果を待機します。SDKはチェックポイントを作成し、ターゲット関数を呼び出し、呼び出しが完了すると関数を再開します。これにより、関数合成とワークフロー分解が可能になります。 詳細については、 開発者ガイド を参照してください。 Lambdaコンピュート料金は、リプレイを含むすべての呼び出しに適用されます。待機操作を使用する場合、関数は実行を一時停止し、Lambda関数の実行が再開されるまで実行時間料金は発生しません。また、durable operations、書き込まれたデータ、データ保持に対しても課金されます。Lambda durable functionsの料金について詳しく知るには、 Lambda料金 ページを参照してください。 最新のリージョン可用性については、 AWS Capabilities by Regionページ をご覧ください。 AWS Lambda durable functionsは、使い慣れたプログラミングパターンを使用して簡単に耐障害性のある長時間実行アプリケーションの構築するために、Lambdaのプログラミングモデルを拡張します。Lambda durable functionsを使用して、チェックポイントとエラー回復を自動的に処理する組み込みメソッドを使い、お好みのプログラミング言語でマルチステップワークフローを記述できます。これによりシンプルなアーキテクチャを維持したまま、ビジネスロジックに集中できます。また、課金は実際に処理を行っている時間のみなのでコストを最適化できます。 Lambda API、 AWS Management Console 、AWS CLI、AWS CloudFormation、AWS SAM、AWS SDK、およびAWS CDKを使用して、Python、Node.jsまたはJavaベースのLambda関数用のdurable functionsを構築できます。 開始するには、 Lambda Developer Guide をご覧いただくか、 re:Invent breakout session をご視聴ください。

こんにちは。流通小売・消費財・飲食業界を担当するソリューションアーキテクトチームです。いよいよ 6 月 25 日 (木)、26 日 (金) の 2 日間、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されます。基調講演や数多くの事例セッションとともに、AWS Expo のエリアでは AWS サービス・ソリューションの最新活用事例や、実際に AWS に触れられるデモを、さまざまな角度から体験いただけます。 その AWS Expo エリア内には、製造、金融、自動車、そして私たちの担当する流通小売・消費財・飲食など、業界別に特化したソリューションをご紹介する AWS Industries Zone が設けられます。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決の方法をご覧いただける場です。業界に精通したエキスパートと、具体的な活用シナリオについてじっくりご相談いただけるスペースもご用意しています。私たち流通小売・消費財・飲食業界担当チームも、このゾーンに今年ならではのテーマで展示を出展します。本ブログでは、その展示内容を一足先にご紹介します。まだ登録がお済みでない方は、ぜひ下記のリンクから。 登録はこちら 図 流通小売・消費財・飲食業界向けブースの位置 AWS 展示ブーステーマ 「AI エージェントが業務の主役になる日」 昨年の Summit では「The Future of Retail」をテーマに、カスタマージャーニーを軸とした店舗体験の “少し先の未来” をご紹介しました。今年、私たちが皆さまにお届けしたいのは、その一歩先 — AI エージェントが、業務そのものの主役になっていく世界 です。 生成 AI を「試してみた」というお客様は、この一年で本当に増えました。一方で、実務での大規模な活用にまで踏み込めている企業は、まだ決して多くありません。そのあいだに横たわっているのは、多くの場合「いまの業務プロセスを全部つくり変えなければならないのではないか」という、心理的なブロッカーです。 私たちが今年のブースでご提案したいのは、その逆の発想です。既存のプロセスはそのままに、まずは業務の “一部” に AI を組み込んでみる。そこから自律エージェント、そして複数のエージェントが連携するマルチエージェントへ少しずつ広げていくことで、やがて業務全体の最適化へたどり着く——この段階的な進化のステップを、実機デモで体感いただきます。 商品をつくり、届け、そして売る。流通小売・消費財・飲食業界のバリューチェーンのそれぞれの現場で、AI エージェントがどのように働き始めているのか。本ブースでは 「商品をつくる」「商品を届ける」「商品を売る・つながる」 の 3 つの切り口で、合計 6 つのデモをご用意しました。順にご紹介していきましょう。 商品をつくる — AI と共創する、これからの商品開発 ヒット商品は、どのように生まれるのでしょうか。市場調査からアイデアの発想、デザイン、検証まで——これまで多くの時間と専門知識を要してきた商品開発の現場に、AI エージェントが伴走するとどうなるのか。ここでは 2 つのデモをご覧いただきます。 バーチャル AI エキスパート — タッチ一つで、自律エージェントがアイデアを形にする 5〜10 人の個性豊かな AI ペルソナが、並列で Deep Research とディスカッションを重ね、あなただけの商品デザインを提案します。アパレルかパッケージのテーマを選び、雰囲気や素材をタッチパネルで選んでいくたびに、各ペルソナがそれぞれの視点で反応し、アイデアが少しずつ形になっていきます。複数の自律エージェントが同時並行で協調し、わずか数分でアウトプットが立ち上がっていく様子を、ぜひ目の前でご体感ください。「複数のエージェントが協調する」とはどういうことなのか、その手触りを感じていただけるはずです。 図 自律エージェントがアイデアを形にするデモイメージ AI で加速する製品イノベーション — マルチエージェントで実現する製品開発 製品開発におけるリサーチ、デザイン、製造計画の各工程を、役割の異なる複数の AI エージェントが連携して進めます。市場調査からターゲットの特定、デザイン生成、仮想ペルソナによる検証、そして製造コスト・収益予測まで——通常であれば数ヶ月を要する一連のプロセスを、わずか数分で駆け抜けます。とはいえ、すべてを AI に委ねるわけではありません。各フェーズで AI が多様な選択肢を提示し、戦略的な意思決定は人間が下す。この「Human in the Loop」の考え方によって、スピードと品質を両立させる新しい商品開発の姿をご覧いただけます。 図 マルチエージェントで実現する製品開発 デモイメージ 商品を届ける — 止めない物流とサプライチェーンのために 災害による物流の停止、深刻化するドライバー不足、原材料費の高騰。日本のサプライチェーンと物流の現場は、いくつもの不確実性と日々向き合っています。「想定外」が起きたそのとき、AI エージェントは何ができるのか。2 つのデモでお見せします。 AI エージェントで危機対応 — 小売×消費財の混乱を AI と人が即座に解決 混乱の検知から対応の完了まで、AI と人が協調する次世代のサプライチェーン管理オペレーションを、ライブでご覧いただきます。小売のシナリオでは、店舗の在庫不足に対して最適な振替ルートを AI が提案します。消費財のシナリオでは、原材料の供給が止まった際の代替サプライヤー探索を実行します。いずれの場合も、AI がビジネスインパクトを瞬時に分析・試算して対応策を提示し、人間がそれを承認し、AI が実行と通知までを担います。Amazon Bedrock AgentCore による Human-in-the-Loop の協調モデルが、リアルな課題シナリオの中でどう機能するのか、ぜひその目でお確かめください。 図 次世代のサプライチェーン管理オペレーション デモイメージ 物流異常を Quick が自動解決 — 配送在庫の異常検知〜問合せまで一気通貫 基幹システム、受発注、在庫、配送 —— 複数のシステムに分散しがちな物流のデータを Amazon Quick に統合し、業務の自動化と可視化を実現します。Amazon Quick – Automate が配送フローを自動で実行し、異常が発生すればメッセージングツールへリアルタイムに通知。Quick Sight のダッシュボードで滞留の状況を一目で把握し、その原因はチャットで深掘り分析できます。社内に蓄積された業務ナレッジも活かしながら、業者へのメール問い合わせまで ——「発見」から「対応」までが途切れなくつながる体験をご覧ください。 図 Quick Sight ダッシュボード デモイメージ 商品を売る・つながる — コマースと店舗の、新しいかたち 買い物の体験も、店頭での働き方も、AI エージェントによって静かに、しかし確かに塗り替わろうとしています。海の向こうで吹き荒れる新しい潮流から、日本の店舗現場のリアルな課題解決まで、2 つのデモでご紹介します。 Future of Agentic Commerce — AWS で実現する新しい E-Commerce の形 いま US で吹き荒れている Agentic Commerce の旋風。「名前は聞いたことがあるけれど、実態はどんなものなのだろう」「自社の事業では、どう対応すればいいのだろう」——そんな疑問をお持ちの方に、その答えをご用意しました。OpenAI や Google からやってくる Incoming Agent、自社で持つ Onsite Agent、そして MCP Apps、UCP、A2A といった実装を、実際にご覧いただけます。来たる Agentic Commerce の時代を、皆さまのビジネスにとって売上向上の Big Opportunity に変える——そのヒントが、ここにあります。 図 Future of Agentic Commerce デモイメージ Eyes On, Voice On — スマートグラスと音声 AI が融合する、フード・現場業務の未来形 実店舗では、スタッフの業務効率化とサービス品質の向上が常に求められています。本展示では、スマートグラスやウェアラブル音声デバイスを AI エージェントと連携させることで、こうした課題に応えるソリューションをご紹介します。デバイスを介して、在庫確認や接客、バックヤード業務を AI が支援し、現場のナレッジをリアルタイムに共有する。経験の浅いスタッフでも、誰もが安定した高品質な業務を実現できる——そんな新しい働き方をご提案します。物理デバイスと AWS がつながることで生まれる、業務の標準化と品質向上の姿を、現場での活用イメージとともにご体感ください。 図 音声操作によるキッチン業務の効率化ソリューション 図 スマートグラスによる店舗業務の効率化ソリューション お客様事例展示 — すでに現場で動いている、生成 AI コンセプトのご紹介だけではありません。展示エリアには、生成 AI を実際の現場で活用されているお客様 2 社の事例展示も併設しています。会期中はお客様ご自身による解説に加え、その場での Q&A も可能です。実装の裏側や、運用してみて初めて見えてきた気づきなど、現場の生の声を直接お聞きいただける貴重な機会です。 株式会社ユナイテッドアローズ 「Amazon Bedrock で実現 対話で深まる日報 AI」 日報には、「書く負担」と「うまく伝わらない」という、相反する 2 つの悩みがつきものです。本展示では、Amazon Bedrock を活用した対話型 AI が店舗スタッフの思考整理を支援し、日報を自動で要約する PoC をご紹介いただきます。AI が深掘りの質問を投げかけることで、報告内容の粒度と一貫性が高まり、本部の状況把握や店舗の行動改善にもつながることが確認できたといいます。現場と本部、その双方の業務品質を高める生成 AI の活用事例です。 株式会社カインズ 「AI で進化する顧客体験 Amazon Bedrock 活用事例」 Amazon Bedrock を活用し、生成 AI によって顧客一人ひとりに最適化された購買体験を実現するソリューションをご紹介いただきます。商品の提案や情報提供を高度にパーソナライズすることで、オンライン・オフラインを問わず顧客接点の価値を高め、購買意欲と満足度の向上に貢献します。 おわりに — 会場でお会いしましょう 「まだ早い」から「もう始めている」へ。流通小売・消費財・飲食業界の現場では、AI エージェントが業務の主役になっていく日が、すぐそこまで来ています。新しい技術を次々と取り込まなければならないように思われるかもしれません。けれども今年のデモでお伝えしたいのは、その逆です。AWS のサービスを組み合わせれば、皆さまの中にすでに蓄積されてきた知識と経験を起点に、業務の “一部” から無理なく始めていける——そんなアイデアばかりをご用意しました。 商品をつくり、届け、売る。そのすべての場面で、AI が業務の一部から全体最適へと進化していく姿を、6 つのデモと 2 社の事例展示でご覧いただけます。「試してみたい」と思われた方は、ぜひその場で私たちにお声がけください。 幕張メッセの AWS Industries Zone で、皆さまのお越しを心よりお待ちしています。会場でお会いしましょう！ 参考情報 AWS ブログ “流通小売” カテゴリー AWS ブログ “消費財” カテゴリー AWS 消費財・流通・小売業向けソリューション 紹介ページ 本ブログは AWS Japan のソリューションアーキテクト 山下 智之 が執筆しました。

2026 年 6 月 8 日週、 AWS IoT Device SDK for Swift が一般公開されました。 Swift Server Workgroup (SSWG) のメンバーである私は、これに注目しています。この SDK は、macOS、iOS、tvOS、Linux の Swift 開発者に本番環境で利用できる MQTT 5 接続、デバイスシャドウ、ジョブ、フリートプロビジョニングを提供します。 皆さんなら、この SDK を使用して何を構築しますか? サーバー上の Swift はここ数年で成熟し、現在では IoT デバイスにも適用されています。これは、Swift をエッジで実行するという幅広いトレンドにつながっています。例えば、 WendyOS は物理 AI 向けのオープンソースのオペレーティングシステムで、NVIDIA Jetson や Raspberry Pi ハードウェアにアプリケーションをデプロイするためのファーストクラスの Swift サポートを提供しています。サーバーサイドの Swift、IoT、エッジコンピューティング間で、数年前にはほとんどの人が驚いたであろう複数の場所にこの言語が登場しています。 それでは、2026 年 6 月 8 日週の AWS ニュースを見ていきましょう。 見出し Amazon RDS for SQL Server が Bring Your Own Media をサポート – オンプレミス環境から SQL Server アプリケーションを移行するお客様は、Amazon RDS 上の Microsoft の License Mobility プログラムを通じて、Software Assurance を含む既存の Microsoft SQL Server ライセンスを再利用できるようになりました。BYOM は AWS License Manager と統合されており、ライセンスの使用状況とコンプライアンスを追跡できます。 さらに表示 Amazon Cognito がマルチリージョンレプリケーションのサポートを開始 – 認証情報、ユーザープール設定、フェデレーション設定などのユーザーとマシンの ID データを、スタンバイリージョンのセカンダリユーザープールにほぼリアルタイムで同期できるようになりました。プライマリリージョンで障害が発生しても、サインインしたユーザーは再認証することなく引き続きアプリケーションにアクセスでき、登録ユーザーは既存の認証情報でサインインできます。マルチリージョンレプリケーションは、16 のリージョンにわたる Essentials または Plus 機能階層のユーザープールのアドオンとして利用できます。  さらに表示 OpenAI の GPT-5.5、GPT-5.4、Codex の Amazon Bedrock での一般提供を開始 – Amazon Bedrock の本番ワークロードで GPT-5.5 と GPT-5.4 を使用できるようになりました。また、AWS 全体で既に使用しているのと同じセキュリティ、ガバナンス、運用制御を使用して、AI を活用したソフトウェア開発でコーデックスを構築できます。GPT-5.5 は OpenAI の最も高性能なモデルで、エージェンティックコーディング、データ分析、多段階の自律タスクに長けています。Codex は、Codex App、Codex CLI、および Visual Studio Code、JetBrains、Xcode との IDE 統合を通じて利用できます。価格は OpenAI のファーストパーティー料金に一致し、使用回数は既存の AWS コミットメントに反映されます。  さらに表示 2026 年 6 月 1 日週のリリース 2026 年 6 月 1 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Bedrock に OpenAI および Anthropic互換 API 用の CloudWatch メトリクスを追加 – CloudWatch メトリクスを使用して、bedrock-mantle エンドポイントへの推論トラフィックをモニタリングできるようになりました。これには、推論カウント、入出力トークンの合計、アカウント、プロジェクト、モデル、プロジェクトおよびモデルの細分性におけるクライアントエラー数が含まれます。 Amazon Bedrock が OpenAI と Anthropic 互換の API 向けに最適化された再設計されたコンソールを発表 – モデルカタログ、並列比較、プロジェクトベースの編成、コードスニペットがあらかじめ入力されたプロジェクト対応ドキュメントなどを使用して、コンソールワークフローを一新しました。 Amazon Bedrock AgentCore Identity が AWS Secrets Manager による独自のシークレットの持ち込みのサポートを開始 – お客様は AgentCore ID 認証情報プロバイダの既存の AWS Secrets Manager シークレット ARN を参照できるようになり、カスタム CMK、タグ付け戦略、自動ローテーションを含むシークレットガバナンスの完全な所有権が実現しました。 AWS Step Functions に AgentCore を利用したエージェント推論ステップを追加 – Amazon Bedrock AgentCore のマネージドハーネスとの統合により、Step Functions ワークフローに AI エージェント推論ステップを追加できるようになりました。複数のエージェントを並行して実行したり、順番に実行したり、人間による承認を追加したり、すべてのエージェントの決定を追跡したりできます。 Amazon EKS と Amazon EKS Distro が Kubernetes バージョン 1.36 のサポートを開始 – Kubernetes 1.36 では、ユーザー名前空間が GA に昇格され、変更されたアドミッションポリシー、インプレースポッドレベルのリソースの垂直スケーリング、リソースヘルスステータスレポートが導入されました。EKS が利用可能なすべての地域で利用できます。 Amazon ECS マネージドインスタンスが AWS Trainium と AWS Inferentia のサポートを開始 – Inferentia2、Trainium1、Trainium2 の各インスタンスタイプで ECS マネージドインスタンスのキャパシティプロバイダーを作成し、Amazon ECS にすべてのアクセラレーターリソースをワークロードに自動的に割り当てることができるようになりました。 Amazon Quick が MCP 接続の VPC 接続のサポートを開始 – 企業のお客様は、プライベートにホストされているモデルコンテキストプロトコル (MCP) サーバーを VPC 経由で Amazon Quick に接続できるようになりました。これにより、インターネットに公開されることなく、独自のアプリケーションや内部ツールに安全にアクセスできるようになります。 AWS Cost and Usage Report 2.0 が Athena と Redshift の統合のサポートを開始 – CUR 2.0 のエクスポートは、サポート対象のインフラストラクチャテンプレート、テーブル定義、データロード手順とともに、選択したクエリエンジンに最適な形式で自動的に配信されます。 Amazon Location Service が公共交通機関とインターモーダルルーティングを発表 – Routes API では、交通手段とインターモーダルという 2 つの新しい移動モードがサポートされるようになりました。これにより、13 の地域にわたって、公共交通機関と徒歩、車、タクシー、レンタルのセグメントを組み合わせて旅行を計画できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 今後の AWS イベント AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 6 月 8 日週のニュースは以上です。2026 年 6 月 15 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – seb 原文は こちら です。

プログラマティック広告（※）に携わる DSP（Demand-Side Platform）・SSP（Supply-Side Platform）事業者なら、一度はこのジレンマに直面したことがあるのではないでしょうか。広告枠を提供するパートナーであるパブリッシャーと広告主との接続を増やせば入札機会が広がり、広告主にもパブリッシャーにも価値を届けられる。しかし現実には、接続のたびに発生するネットワークコストとインフラ構築の時間が、その判断にブレーキをかけてきました。DSP 事業者のUNICORN株式会社 と SSP 事業者の株式会社fluct は、AWSの広告テクノロジーワークロード向けマネージドサービスである AWS RTB Fabric を共通基盤として活用することで、この接続コストとスピードのジレンマを乗り越え、広告配信ネットワークの拡大に踏み出しています。両社は概念実証（PoC）を経て既に本番稼働を開始しており、本記事ではその取り組みと成果を説明します。 ※ プログラマティック広告とは、データとアルゴリズムを用いて広告の買い付け・配信を自動で行う手法。 接続コストとスピードのジレンマ プログラマティック広告の入札処理（Real-Time Bidding）では、1秒間に数十万〜数百万件の入札リクエストが DSP・SSP 間を行き交います。より多くのパートナーと接続し、より多くの入札機会を得ることが、広告主にとってもパブリッシャーにとっても価値を生みます。 しかし現実には、接続先を増やすほど以下のジレンマが深刻になります。 コストのジレンマ： 広告枠を提供するパートナーを増やすほどネットワークコストが膨らみ、応札数の拡大が利益を圧迫する。コストを抑えるためにフィルタリングを強化すれば、本来獲得できた広告枠を逃す。 スピードのジレンマ : 新規パートナーとの接続にコロケーション手配やネットワーク構成の調整が必要で、数週間〜数ヶ月を要する。ビジネス判断のスピードに技術が追いつかない。 パフォーマンスの制約 : ミリ秒単位の入札処理を安定的に維持しながら、トラフィックの急増にも対応し続ける必要がある。 ジレンマを解消に導くAWS RTB Fabricとは このような課題に対処するために生まれた広告テクノロジーワークロード向けフルマネージドサービスであるAWS RTB Fabric の主な技術的特長と構成を紹介します。 AWS RTB Fabricは、SSPとDSP間のリアルタイム入札通信を最適化するAWSのフルマネージドネットワークサービスです。SSPが広告枠のビッドリクエストをDSPに送信する際はパブリックインターネットを経由するのが一般的ですが、AWS RTB Fabricは専用プライベートネットワークを提供し、1桁ミリ秒の低レイテンシーでSSP⇔DSP間の入札リクエスト・レスポンスを交換可能にします。また、RTBワークロードは大量のビッドリクエスト/レスポンスを高頻度で交換するため、通常のインターネットエグレス料金が膨大になりがちですが、AWS RTB Fabricの専用ネットワークを経由することでデータ転送コストを大幅に圧縮できます。これにより標準的なクラウドネットワーキングコストと比較して最大80%のコスト削減が可能です。 AWS RTB Fabricを活用することでコストのジレンマとスピードのジレンマを解消できるのではという期待のもとUNICORN社 と fluct社 は、それぞれ DSP 側・SSP 側からこのジレンマに向き合い、2026年3月よりAWS RTB Fabric を活用した広告配信ネットワークの構築PoCに踏み出しました。 UNICORNとfluctが実施したAWS RTB FabricのPoC 今回の取り組みで両社がPoCを行ったのは、両社（SSP⇔DSP間）の通信経路を「パブリックインターネット経由」から「AWS RTB Fabricの専用プライベートネットワーク経由」に切り替えるというアーキテクチャ変更です。 ＜机上検討＞ AWSが公開しているドキュメントでの仕様確認を経て、利用対象とする機能を特定しました。また、マネージドサービスの利用ということで、特にスケーリングに関するサービス仕様の詳細確認や、モニタリング方法の確認、可用性要件をどのように実現できるかの確認・検討を行いました。また、公開されている価格表からコスト試算を実施したところ、コスト削減の見通しが立ったため、実環境への適用開始を決定しました。 ＜段階的なトランザクションの流入開始＞ 実際の環境でAWS RTB Fabricへの通信切り替えを段階的に実施しました。まずはコスト試算結果の妥当性確認のため、両社のSSP/DSP間で行われている通信の10％をAWS RTB Fabric経由に切り替えることから開始しました。 AWS RTB Fabricを実環境に適用したところ、以下のような結果が得られました。 ネットワークコスト 80～86.5% 削減 — 従来のパブリックインターネット経由と比較し、同一トラフィック量に対するデータ転送コストを大幅削減。これはフィルタリング強化による「入札機会の犠牲」ではなく、通信経路の最適化による純粋なコスト削減です。 入札処理の安定性維持 — レイテンシーの改善により、トラフィック急増時にもタイムアウト率を抑制し、応札率を維持できることを確認。 運用可視性の向上 — DSP 単位でのメトリクスとコストをリアルタイムで把握可能に。 このPoC結果を踏まえ、両社間のトランザクションを全面的にAWS RTB Fabricに切り替えることを決定。2026年5月より両社間のトランザクションのすべてをAWS RTB Fabricを用いた通信に切り替え、現在も安定的に運用を続けています。 ～概念図～ PoCでは以下の結果を確認することができました。 ネットワークコスト80%削減 — 従来のパブリックインターネット経由と比較し、同一トラフィック量に対するデータ転送コストを80%削減。これはフィルタリング強化による「入札機会の犠牲」ではなく、通信経路の最適化による純粋なコスト削減です。 入札処理の安定性維持 — レイテンシーの改善により、トラフィック急増時にもタイムアウト率を抑制し、ビッドレート（応札率）を維持できることを確認しました。 また本件について実際に取り組みを実施した両社からは下記のようなコメントを頂いています。 UNICORN株式会社　取締役 璩 暁毅 様 「AWS RTB FabricのPoCを通じて特に可能性を感じているのは、既存の配信基盤へ比較的容易に組み込めるアーキテクチャである点です。導入や接続にかかる負荷を低減できることで、より多くのパートナーが参加しやすいオープンなエコシステムの実現が期待できます。また、コスト効率の改善に加え、UNICORNとSSP間の処理経路が最適化されることで、広告取引におけるレイテンシの短縮も期待しています。これは広告主やメディアにとっての価値向上だけでなく、ページ表示や広告配信の高速化を通じて、ユーザー体験のさらなる改善にもつながると考えています。今後、こうした取り組みが業界全体の接続性と効率性を高め、オープンインターネットにおけるプログラマティック広告市場のさらなる発展につながることを楽しみにしています。」 株式会社fluct 代表取締役COO 黒田 岳志 様 「ネットワークコストの高騰は、DSPへの接続拡大における大きな課題でした。AWS RTB Fabricの適用によりデータ転送コストを80%削減できたことで、UNICORN様への入札リクエスト数を増加させることが可能となり、パブリッシャーの収益機会の拡大という具体的なビジネス成果に繋がっています。今後もAWSと連携し、配信基盤の強化を通じてパブリッシャーの成長を支援してまいります。」 AWS Japan 常務執行役員技術統括本部長 巨勢 泰宏 は今回の取り組みの成功について、以下のようにコメントしています。 「AWSは、Amazonの広告ビジネスで培った大規模データ処理と低レイテンシー技術の知見を活かし、広告業界のイノベーションを推進してまいりました。AWS RTB Fabricは、DSPとSSPを同一プラットフォーム上で直接接続することで、広告業界が長年抱えてきた大量データ転送と低レイテンシーという課題を解決し、広告の収益性と効果を最大化するサービスです。UNICORN様、fluct様をはじめとするお客様がこのテクノロジーを活用し、新たなイノベーションを生み出すことで、日本の広告業界のさらなる発展につながるものと確信しております。AWSは今後も、広告業界の未来を切り拓くテクノロジーの提供を通じて、業界全体の成長に貢献してまいります。」 UNICORN と fluct の取り組みは、AWS RTB Fabric を活用した広告配信ネットワーク構築の先行事例です。 AWS Japan は、この成果をもとに以下の展開を進めていきます。 ネットワークの拡大 — より多くの DSP・SSP・アドネットワーク事業者への参画呼びかけ ユースケースの深化 — リテールメディア、CTV（コネクテッドTV）など新しい広告領域への展開 技術支援の強化 — 導入を検討する事業者向けの技術ガイダンスと PoC 支援プログラムの提供 広告配信ネットワークへの参画にご関心のある DSP・SSP 事業者の皆様、ぜひお気軽にお問い合わせください。 本ブログに関連するイベント開催について 本ブログ執筆にご協力いただいたUNICORN社とfluct社にもご登壇頂くイベントを下記のとおり開催いたします。AWS RTB Fabric を活用した広告配信ネットワークの輪を広げることに少しでも関心を持たれている方がいらっしゃいましたらぜひご参加ください。 イベント名：AdTech meet up！ 「変わる広告、変わらない価値 ― いまAdTech事業者がAWSに集まる理由」 日時：2026年7月17日（金）16:00-19:00 場所：麻布台ヒルズ森JPタワー 36階 セミナールーム（東京都港区麻布台1-3-1） 対象：プログラマティック広告配信に携わる事業オーナー、エンジニアの方 申し込みWebページ： AdTech meet up「変わる広告、変わらない価値 ― いまアドテク事業者がAWSに集まる理由」 イベント概要： 広告の在り方は変わっても、届けたい付加価値は不変です。ただ、付加価値の届け方が過渡期を迎えています。AIとクラウドが稼ぐ力を引き上げ、そしてコストを大きく押し下げることが容易になったこの変革期に、アドテク事業者の皆様は、何に投資し、何を行い、そして誰と協働すべきでしょうか。 本イベントでは、AIが変えるプログラマティック広告の最前線、AWSのアドテク事業者様向けの最新テクノロジーであるAWS RTB Fabric によるコスト削減と収益拡大の実践、そしてDSP事業者 × SSP事業者によるオープンエコシステム戦略の対談を通じて、その答えを探ります。 また、それらセッションの後にはDSP・SSP事業者同士が直接つながるネットワーキングの場もご用意。同じ課題意識を持つ事業責任者様との交流を通じて、是非とも次の成長の起点を探って頂くことを心から願っております。 アジェンダ： AWS Session① ：AIが変えるプログラマティック広告 スピーカー：アマゾン ウェブ サービス ジャパン合同会社 アド ＆ マーケティング テクノロジーコミュニティ ソリューションアーキテクト　鈴木 康士郎 AWS Session② ：広告コストを収益に変える – AWS RTB Fabric スピーカー：アマゾン ウェブ サービス ジャパン合同会社 アド ＆ マーケティング テクノロジーコミュニティ ソリューションアーキテクト　関藤 寛喜 DSP事業者×SSP事業者による対談 ：アドテク事業者はどこに投資すべきか？—オープンエコシステムが切り拓く次の成長戦略 パネリスト：株式会社fluct　代表取締役COO　黒田 岳志 様 UNICORN株式会社　取締役　璩 暁毅 様 アマゾン ウェブ サービス ジャパン合同会社　プリンシパル事業開発マネージャー　松本 鋼治 本ブログは松原（AdTech Team, Account Executive）・安守（AdTech Team, Account Executive）・久野（Solutions architect）が担当しました

本記事は 2026 年 5 月 21 日 に公開された「 Building multi-tenant agents with Amazon Bedrock AgentCore 」を翻訳したものです。 マルチテナントのエージェント型アプリケーションを構築する SaaS (Software as a Service) プロバイダーは、セキュリティ、ガバナンス、応答精度といった一般的な懸念事項を超えたアーキテクチャ上の課題に取り組む必要があります。具体的には、テナント分離、テナント ID、テナントのオブザーバビリティ、データ分離、コスト配分、ノイジーネイバーの緩和などです。動作するデモから本番環境へのデプロイまでの隔たりを埋めるには、マルチテナント環境向けに設計されたインフラストラクチャが必要になります。Amazon Bedrock AgentCore は、AWS 上でエージェント型アプリケーションを構築、デプロイし、安全に運用するためのマネージドなサーバーレスサービスです。エージェントのデプロイと MCP サーバーのホスティングのための構成要素を提供し、ID 管理、メモリ、オブザーバビリティ、評価機能を標準で備えています。これらはすべて、マルチテナントのエージェントアーキテクチャを無理なく構築できるように設計されています。 本ブログシリーズの第 1 回となる本記事では、マルチテナントのエージェント型アプリケーションを設計する際の検討事項と、 Amazon Bedrock AgentCore で SaaS アーキテクチャの課題に取り組むために必要なフレームワークを解説します。 マルチテナントエージェントを構築する際の設計上の検討事項 強力な分離を備えた安全なマルチテナントのエージェント型アプリケーションを構築するには、図 1 に示すいくつかの主要コンポーネントにわたって、慎重なアーキテクチャ上の判断が必要です。各コンポーネントは、セキュリティとコンプライアンスの基準を維持しながら、テナント分離、運用効率、コスト最適化のバランスを取る必要があります。これらの設計上の検討事項は、3 つのテナント分離パターン ( サイロ、プール、ブリッジ ) を軸に展開され、これらを選択する際にはティアリング戦略が重要な検討要素になります。 図 1: マルチテナントエージェントの設計上の検討事項 続くセクションでは、マルチテナント化が各コンポーネントにどのような影響を与えるかを詳しく説明します。 1. エージェントランタイムのデプロイ: 専用と共有 マルチテナントのエージェントアーキテクチャにおける重要な判断は、テナントに対してエージェントランタイムをどのようにプロビジョニングするかです。テナントごとの 専用 ランタイムは、テナントごとに独立した実行環境をインスタンス化し、それぞれが固有のコンテナイメージ、プロセス空間、ライフサイクルを持ちます。このサイロ型のアプローチは、最も強力なノイジーネイバー対策となり、コンプライアンス監査を簡素化します。一方、 共有 ランタイムは、すべてのテナントのエージェントを同一のコンテナイメージとプロセスプール内でホストするため、インフラストラクチャのコストと運用負荷を抑えられますが、プロセス内でテナントコンテキストを厳密に伝播させる必要があります。 Amazon Bedrock AgentCore Runtime は、セッション分離された microVM ベースのコンピューティングによってこのトレードオフを解決します。AgentCore Runtime は、テナントごとに完全な仮想マシンを起動するコストやレイテンシーを伴わずに、セッション単位で軽量な microVM を起動します。各セッションは独自の永続ファイルシステムを持つため、エージェントはセッションスコープのファイルを読み書きし、中間的な計算結果を保持し、マルチステップのやり取りをまたいで状態を維持できます。これにより、セッション間でのデータ漏洩のリスクを軽減します。このアーキテクチャは、マルチテナントの MCP サーバー、エージェント、AG-UI サーバーをホストするのに適しています。テナントコンテキストは、カスタム HTTP ヘッダーを通じて分離された実行環境に流れ込みます。SaaS プラットフォームが AgentCore Runtime セッションにリクエストを転送する際、標準の認可トークンに加えて、テナント識別子、ティア、リージョンの設定、機能フラグ、エンタイトルメントといったテナント固有のメタデータを持つヘッダーを付与します。エージェントは呼び出し時にこれらのヘッダーを読み取ってテナントを完全に認識できるため、そのテナントのビジネスロジックに合わせたワークフローを実行し、ライセンスされたツールのみを呼び出し、ハードコードされたルーティングロジックなしにテナント固有の API エンドポイントを呼び出せます。 2. 共有モデル、ティア別モデル、ファインチューニング済みモデル ほとんどのマルチテナントデプロイでは、共有基盤モデル (FM) が推奨される出発点となり、単一のモデルを保守するだけで運用を簡素化できます。テナントは通常、テナントごとのカスタマイズなしに、自動的なモデル更新の恩恵を受けられます。テナントのティアに基づいてモデルを選択する方式 (ティア別モデル) では、柔軟性が得られ、テナントのティア間でコスト、パフォーマンス、精度のバランスを取れます。テナント固有の用語、規制対応、パフォーマンス SLA を必要とする特殊なユースケースでは、テナントごとにファインチューニングしたモデルが必要になりますが、運用が複雑になり、テナントごとのパイプラインが発生します。標準ティアには性能を抑えたモデルを、プレミアムなエンタープライズ顧客にはファインチューニング済みまたは高性能なモデルを使うハイブリッドなアプローチは、コスト効率とカスタマイズの要件のバランスを取れます。Amazon Bedrock は主要プロバイダーの大規模言語モデル (LLM) を幅広く提供しており、SaaS プロバイダーはテナントやティア固有のニーズに合ったモデルを選択できます。Amazon Bedrock のファインチューニングでは、独自のラベル付きデータセットを使って FM をカスタマイズし、ドメイン固有のタスクのパフォーマンスを高められます。Amazon Bedrock Custom Model Import を使えば、独自にファインチューニングしたモデルを持ち込み、Amazon Bedrock のマネージドインフラストラクチャを使ってデプロイできます。 3. ワークフロー: サイロ、プール、ブリッジパターン マルチテナントのエージェント型アプリケーションでは、各エージェントがテナントの要件とビジネスロジックに基づいて異なる一連のステップを実行する、柔軟なワークフロー管理が必要です。ワークフローは複数の仕組みで実装できます。手順を段階的にカプセル化する MCP ツールとして、ビジネスロジックのフローを定義する API エンドポイントとして、あるいはドメイン固有のワークフローパターンを組み込んだエージェントスキルとして実装できます。 テナント固有のワークフローを管理する主なパターンは 3 つあります。サイロパターンは、テナント固有の専用スキルを使い、ビジネスロジック、検証ルール、統合ステップを含む各テナントの完全なワークフローを、分離されたエージェントスキルに組み込みます。これにより最大限のカスタマイズと完全な独立性が得られますが、テナントごとに個別のスキル保守が必要です。プールパターンは、共有のエージェントスキルを使います。ブリッジパターンは、認証、ロギング、エラーハンドリングといった共通のワークフローステップを共有エージェントスキルに組み込み、ビジネスクリティカルなロジックについては実行時にテナント固有のスキルを呼び出します。その結果、再利用可能なインフラストラクチャとテナント固有のカスタマイズが共存します。 4. マルチテナント RAG 検索拡張生成 (RAG) システムでは、データ分離の判断が必要です。サイロパターンは、テナントごとに専用のベクトルデータベースを使い、最大限のセキュリティと完全なデータ分離を実現します。これは、規制業界や専用インフラストラクチャを必要とするエンタープライズ顧客に推奨されます。プールパターンは、メタデータベースのテナントフィルタリングと名前空間ベースのアクセス制御を備えた共有ベクトルデータベースを使い、多数の中小規模テナントにサービスを提供する SaaS プラットフォームでコスト効率の高い運用を実現します。検索操作には、テナント間でのデータ漏洩を防ぐため、自動的なテナントフィルターの注入と結果のサニタイズを含めるべきです。 Amazon Bedrock Knowledge Bases は、FM をデータソースに接続するフルマネージドな RAG 機能を提供し、データの取り込み、チャンキング、埋め込みの生成、ベクトルストレージを自動的に処理します。複数のベクトルデータベースに対応し、(メタデータフィルタリングを使って) サイロ型または共有型のベクトルデータベースを作成できます。 Amazon Bedrock Knowledge Bases でマルチテナント RAG アーキテクチャを実装する詳しい手順については、サイロ、プール、ブリッジのデプロイパターンを扱った Multi-tenant RAG with Amazon Bedrock Knowledge Bases と、共有ナレッジベース内でのメタデータベースのテナント分離を扱った Multi-tenancy in RAG applications in a single Amazon Bedrock knowledge base with metadata filtering を参照してください。 5. テナントコンテキスト、代理実行 (act-on-behalf) パターン、トークン伝播 マルチテナントの ID 管理では、サービスチェーン全体にわたってテナントコンテキストを慎重に扱う必要があります。完全な ID を表すテナントコンテキストと、リクエスト固有の状態は、信頼性が高く安全な仕組みを使ってすべてのアーキテクチャ層を流れる必要があります。実行パスが予測可能な決定論的なソフトウェア API とは異なり、AI エージェントは非決定論的で、自律的に動作する可能性があるため、セキュリティ上の考慮事項が重要な点で異なります。不正なエージェントや侵害されたエージェントは、ダウンストリームのサービスに対して不正な呼び出しを行い、認証情報の盗難、権限昇格、混乱する代理問題 (Confused Deputy) を引き起こす可能性があります。エージェントがユーザーの認証情報をすべて使って動作する (なりすまし) 場合、1 つの侵害されたエージェントが、すべてのダウンストリームシステムにわたるユーザー権限への完全なアクセスを得てしまいます。このリスクは、どのツールをいつどのようなパラメータで呼び出すかをエージェントが自律的に判断するようになるほど大きくなります。代理実行 (act-on-behalf) パターンが重要なのは、ユーザーとエージェントを明確に区別し、エージェントが操作ごとに明示的に制限・スコープされた権限でユーザーに代わって呼び出しを行うようにするためです。 テナントコンテキストは JSON Web Token (JWT) 内にエンコードし、3 つの次元を捉えます。セキュリティコンテキスト (標準クレーム: iss、sub、exp、aud)、テナントコンテキスト (tenant_id とテナント固有のスコープ)、リクエストコンテキスト (ビジネスロジック向けのドメイン固有の属性) です。このようにテナントコンテキストをエンコードすることで、マルチテナント運用の強力で柔軟な基盤が得られます。 セキュリティ上の影響が大きく異なる 2 つのパターンから選択します。なりすまし (Impersonation) はエージェントがユーザーの ID と権限をすべて使って動作できるようにするもので、実装は容易ですが、最小権限の原則に反し、セキュリティリスクを生みます。推奨されるアプローチである代理実行 (Act-on-Behalf、委譲) は、各サービス境界でトークンをスコープ制限された認証情報に変換し、エージェントを識別する act クレーム (OAuth 2.0 RFC 8693 に準拠) を付与する、真の委譲を実装します。AgentCore Identity の On-behalf-of トークン交換を使うと、エージェントや MCP サーバーなどのワークロードが、受信したユーザーアクセストークンを、ダウンストリームのリソースサーバー向けの新しいスコープ付きアクセストークンと交換できます。この交換では、ある対象者 (audience) 向けに発行されたトークンを、別のダウンストリームの対象者向けのトークンに直接変換するため、エージェントは追加の同意フローを発生させることなく、認証済みユーザーに代わって保護されたリソースにアクセスできます。交換されたトークンはエージェント自身の ID と元の呼び出し元の ID の両方を保持するため、リソースサーバーはホップごとにきめ細かなゼロトラスト認可を実施するために必要なシグナルを得られます。 6. MCP ツールと API に対するきめ細かなアクセス制御 マルチテナントのエージェント型アプリケーションでは、ポリシーを使った MCP サーバーアクセスの制限、ツール呼び出し層でのきめ細かなアクセス制御、データアクセス層でのテナント分離が必要です。認可層では、ポリシーが実行時にテナントコンテキストを評価して許可/拒否の認可判断を行い、トークンに埋め込まれた静的な権限だけに頼るのではなく、現在のテナントの状態に基づいて、ツール呼び出しを許可する前にテナントのクォータ、ティアベースの権限、使用制限を評価します。ポリシーストアを分離して一元化することで、再デプロイなしに動的な更新が可能になり、ポリシーのバージョン管理によって監査証跡とロールバックがサポートされます。AgentCore Policy は、ツールアクセスを許可する前に、定義されたポリシーに照らしてすべてのエージェントリクエストをインターセプトして評価し、ユーザー ID とツール入力パラメータに基づくきめ細かな制御を提供します。ポリシーは自然言語または Cedar で直接記述できます。 呼び出し層では、MCP サーバーがテナントのティア、機能フラグ、クォータ制限に基づいて、エージェントが呼び出す前に利用可能なツールをフィルタリングし、きめ細かなアクセス制御を実施します。ツールインターセプターは JWT クレームを検証し、リクエストを行うプリンシパルが特定の操作に対する適切な権限を持っていることを確認します。スキーマ変換機能は、テナントの設定とエンタイトルメントに基づいてツールのインターフェイスを適応させます。AgentCore Gateway は、API や AWS Lambda 関数をエージェント互換のツールに変換し、既存の MCP サーバーに接続することで、エージェントがツールに安全にアクセスできるようにします。Amazon API Gateway、OpenAPI スキーマ、Smithy モデル、Lambda 関数、MCP サーバーに対応しています。カスタムロジックにはゲートウェイインターセプターを通じてアクセス制御を実装することも、標準的な AWS スタイルのアクセス制御にはリソースベースのポリシーを使うこともできます。データアクセス層では、属性ベースのアクセス制御 (ABAC) ポリシーがデータアクセスのテナント分離を実施し、テナントの識別は JWT クレームを通じて行われます。ABAC ポリシーは AWS Identity and Access Management (IAM) の条件を使い、プリンシパルのタグと属性に基づいてデータアクセスを制限します。これにより、エージェントは行レベルセキュリティまたはストレージポリシーを通じて、自身のテナントコンテキストに一致するリソースのみをクエリできます。 7. メモリ: 階層的な名前空間による分離 マルチテナントのメモリ管理では、テナント間のデータ漏洩を防ぎながら、エージェントがコンテキストや学習した情報を保持できるよう、慎重なアーキテクチャ設計が必要です。メモリシステムは 5 つの論理レベルを実装すべきです。 グローバル (テナント横断で共有される知識) ストラテジー (エージェントタイプ固有のパターンと動作) テナント (テナントスコープの会話履歴と設定) ユーザー (テナント内の個々のユーザーコンテキスト) セッション (アクティブな会話のための一時的な短期メモリ) アクセス制御は、要求された名前空間パスに対してプリンシパルの ID を検証する属性ベースのポリシーを通じて分離を実施し、エージェントは許可されたスコープ内でのみメモリの読み書きができます。プールパターンは、運用効率とコスト効率のために、階層的な名前空間ベースの論理分離を備えた共有インフラストラクチャを使い、すべてのテナントデータを共通のデータストアに保存し、名前空間のプレフィックスに基づいて厳密にフィルタリングします。サイロパターンは、最大限の分離のためにテナントごとに専用のメモリストアをデプロイし、運用コストは高くなるものの、テナント間アクセスのリスクを低減します。実装にあたっては、テナントとユーザーの情報から複合識別子 (例: tenant_123:user_456) を構築し、テナントコンテキストをクレームやタグとして持つスコープ付き認証情報で認証し、すべてのメモリ操作に適切な名前空間パスをプレフィックスとして付けます。 AgentCore Memory は、グローバル、ストラテジー、テナント、ユーザー、セッションの各レベルにわたる階層的な名前空間分離を提供し、マルチターンの会話のための短期メモリと、セッションをまたいで永続する長期メモリの両方によって、コンテキストを意識したエージェント体験をサポートします。きめ細かなアクセスのために、 リソースベースのポリシー と 属性ベースのアクセス制御 に対応しています。 8. エージェントの ID、信頼、ディスカバリ エージェント型アプリケーションが組織の境界をまたいで外部のエージェントとやり取りするようになると、エージェント ID、エージェントの信頼、エージェントのディスカバリという 3 つの基本的な懸念事項が浮かび上がります。これらは関連していますが、それぞれ異なる問題に対処します。 エージェント ID は 「このエージェントは誰で、それを証明できるか」 に答えます。組織に紐づく、検証可能で一意な ID を確立します。 エージェントの信頼 は 「このエージェントを信頼すべきか」 に答えます。単一の認証情報ではなく、複数のシグナルの組み合わせに基づいて信頼性を評価します。 エージェントのディスカバリ は 「適切なエージェントをどうやって見つけるか」 に答えます。エンドポイントを事前に知らなくても、機能や所属によってエージェントを見つけられます。 AgentCore Identity によるエージェント ID Amazon Bedrock AgentCore Identity は、クラウドネイティブセキュリティで確立されたパターンであるワークロード ID として、エージェント ID を実装します。各エージェントは、組織の AWS アカウントと IAM インフラストラクチャに紐づいた、暗号的に検証可能な ID を受け取ります。エージェントは OAuth 2.0 フローを使ってユーザーに代わって AWS リソースやサードパーティ製ツールに安全にアクセスでき、AgentCore Identity は Okta、Microsoft Entra ID、Amazon Cognito といった既存の企業 ID プロバイダーと、ユーザーの移行を必要とせずに統合できます。 エージェントの信頼 ID だけでは、エージェントを信頼すべきかどうかには答えられません。業界はこの問題に積極的に取り組んでいます。 Agent Naming Service (ANS) v2 は、現在 IETF の Internet-Draft (策定中) であり、すべてのエージェント ID を DNS ドメイン名に紐づけます。クライアントは、Bronze (PKI)、Silver (PKI + DANE)、Gold (PKI + DANE + 透明性ログ) という 3 つの検証ティアから、取引のリスクに見合った保証レベルを選択できます。 AWS Agent Registry によるエージェントのディスカバリ Amazon Bedrock AgentCore を通じて利用できる AWS Agent Registry は、組織全体にわたってエージェント、スキル、MCP サーバー、カスタムリソースを発見するための一元化されたカタログを提供します。チームは再利用可能なエージェント機能を公開、バージョン管理、共有できます。利用者は、識別子やエンドポイントを事前に知らなくても、自然言語または構造化された検索を通じてエージェントを発見できます。組み込みのガバナンス制御により、利用者がレジストリにどのようにアクセスするか、レコードが発見可能になる前に承認を必要とするかどうかを決定します。まとめると、AgentCore Identity が ID の基礎的な証明を提供し、Agent Registry がディスカバリを解決し、ANS のような新興の信頼フレームワークがマルチシグナルによる信頼評価の隔たりを埋めることを目指しています。 9. テナントごとのコスト追跡とオブザーバビリティ 正確なマルチテナントのコスト配分には、エージェントの呼び出しごとにテナントタグ付きのメトリクスをロギングソリューションに送出し、入出力トークン、ツール呼び出し、実行時間を記録する、アプリケーションレベルの計装が必要です。テナントコンテキストを含む構造化ロギングにより、使用パターン、パフォーマンスのボトルネック、キャパシティプランニングを詳細に分析できます。AgentCore Observability は、Amazon CloudWatch を基盤とする OpenTelemetry 互換の統合により、エージェントのワークフローをリアルタイムで可視化し、エージェント実行の各ステップを詳細に可視化します。 10. ガードレール: コンテンツの安全性 マルチテナントのガードレールは、3 つの実施ポイントで安全性とコンプライアンスを実施します。前処理の入力ガードレールは、エージェントが処理する前にユーザー入力を検証し、悪意のあるプロンプトやプロンプトインジェクションをブロックし、ヘルスケアの HIPAA や金融の PCI-DSS といったテナント固有のコンプライアンス要件に基づいて PII をサニタイズします。後処理の出力ガードレールは、エージェントの応答について事実の正確性を検証し、ハルシネーションを検出し、フォーマットの準拠を確認し、テナント境界を越えた機密データの漏洩をスキャンします。ガードレールはテナントまたはティアごとに適用でき、毒性検出、コンテンツフィルタリング、カスタムのブロック対象用語の設定を提供します。オブザーバビリティのメトリクスでは、トリガー率、カテゴリ別のブロックされたリクエスト、誤検知率を追跡して継続的な改善につなげます。Amazon Bedrock Guardrails は、拒否トピック、コンテンツフィルター、単語フィルター、機密情報の編集に対する設定可能なポリシーを備えたコンテンツフィルタリングと安全性制御を提供し、すべてのモデルとのやり取りにわたって責任ある AI のデプロイをサポートします。 これら 10 個のコンポーネントは、マルチテナントエージェントを設計するための包括的なフレームワークとなります。続くセクションでは、これらの中核コンポーネントを念頭に置きながら、AgentCore でのサイロ、プール、ブリッジの各モデルの実装を解説します。 AgentCore でのサイロモデルの実装 次の図に示すように、 サイロモデル では、各テナントが専用の Bedrock AgentCore Runtime、Bedrock AgentCore Gateway、Bedrock AgentCore Memory を持ち、それぞれが個別の AWS IAM 境界の背後にスコープされた、完全に分離されたスタック内で動作できます。メモリには長期、短期、エピソード記憶など複数の分類があり、テナントの要件に応じて設定する必要があります。 主要なアーキテクチャコンポーネント サイロ化されたエージェント層 – テナント固有の権限のために個別の IAM 実行ロールでデプロイされた専用の AgentCore Runtime。 サイロ化されたゲートウェイ – MCP を使ったツールオーケストレーションのための専用 AgentCore Gateway。実行ロールに基づいてデータ層へのアクセスがスコープされます。 サイロ化されたエージェントメモリ – 階層的な名前空間分離を備えた専用の AgentCore Memory。すべての名前空間パスにテナント ID を含める必要がなくなります。エージェントは IAM ロールを通じてテナント固有のメモリにアクセスします。 サイロ化されたデータ層 – 最大限のデータ分離のための専用のツール、ナレッジベース、データベース、バックエンドリソース。 リクエストフロー 認証 – ユーザーは ID プロバイダーを使って認証し、テナントコンテキスト (テナント ID とサブスクリプションのティア) を含む JWT トークンを受け取ります。 SaaS アプリケーションプロキシによるルーティング – SaaS アプリケーションプロキシは、テナントコンテキストに基づいてどのエージェントを呼び出すかを決定します。これには、テナントとエージェントのデプロイの間にマッピング設定を確立する必要があり、これは通常 SaaS コントロールプレーンの一部となる機能です。プロキシは、アプリケーションレベルのリクエストを AgentCore Runtime の API 呼び出し (InvokeAgent) に変換し、テナントの JWT トークンを付与します。 エージェントの実行 – AgentCore Runtime は AgentCore Identity を使って JWT を検証し、分離された microVM セッションを作成し、エージェントの推論を開始します。さらに、AgentCore Identity の JWT オーソライザーでカスタムクレームを設定することで、テナント ID がこのエージェントの呼び出しを認可されているか (例: 「tenant_id = テナント A の場合のみ許可」) を検証します。エージェントは、ランタイムの IAM 実行ロールを使ってテナント固有の AgentCore Memory にアクセスします。 AgentCore Gateway を使ったツールアクセス – エージェントがツールを呼び出す必要がある場合、特定のテナントの MCP ツールにアクセスするようにスコープされた 専用の AgentCore Gateway を呼び出します。ゲートウェイは次の処理を行います。 AgentCore Identity を使って JWT を検証します。 検証済みのトークンからテナントコンテキストを抽出し、カスタムインターセプターを使って、ゲートウェイが対象のテナントにマッピングされていることを確認します。 サイロ化されたテナント固有のバックエンドリソース (API、データベース、ナレッジベース) と統合します。 応答フロー – ツールの応答はゲートウェイを通じてエージェントに戻り、エージェントは推論を完了します。サイロ化されたエージェントは、SaaS アプリケーションプロキシに返す前にテナント固有のフォーマットを適用します。プロキシは応答をユーザーに返します。 サイロパターンは、各顧客のエージェントセッション、ツールアクセス、メモリが完全に封じ込められ、処理のきっかけとなったアラートを発した顧客にコストが直接配分されるように設計されています。トレードオフは、各顧客がリソースを共有するのではなく専用リソースを実行するため、運用負荷が高くなる点です。しかし、セキュリティが重要でコンプライアンスに敏感なワークフローでは、影響範囲が限定されることから、これが適切な選択になります。 図 2: AgentCore によるサイロモデル AgentCore でのプールモデルの実装 次の図に示すように、 プールモデル では複数のテナント間でリソースを共有できるため、リソース利用率を最大化し、運用効率を実現するアーキテクチャを設計できます。 主要なアーキテクチャコンポーネント プール化されたエージェント層 – 複数のテナント間で共有される AgentCore Runtime とエージェントロジック。 プール化されたゲートウェイ – MCP を使ったツールオーケストレーションのための一元化された AgentCore Gateway。 プール化されたエージェントメモリ – テナントコンテキストに基づいて分割された共有 AgentCore Memory。 プール化されたデータ層 – 共有のツール、ナレッジベース、データベース、バックエンドリソース。 プール化された ID 管理 – JWT ベースのテナントコンテキスト伝播を備えたプール化された ID プロバイダー。 リクエストフロー 認証 – ユーザーは ID プロバイダーを使って認証し、テナントコンテキスト (テナント ID とサブスクリプションのティア) を含む JWT トークンを受け取ります。 SaaS アプリケーションプロキシによるルーティング – SaaS アプリケーションはパススルーとして機能し、テナントコンテキストを含む入力リクエストを、プール化された AgentCore Runtime で動作するエージェントにルーティングします。SaaS アプリケーションプロキシは、アプリケーションレベルのリクエストを AgentCore Runtime の API 呼び出し (InvokeAgent) に変換し、テナントの JWT トークンを付与します。 エージェントの実行 – AgentCore Runtime は AgentCore Identity を使って JWT を検証し、分離された microVM セッションを作成し、JWT からテナントコンテキストを抽出してエージェントの推論を開始します。エージェントは、名前空間ベースの分割 (例: actor_id: 「tenant-a:user-123」) を使ってテナントスコープの AgentCore Memory にアクセスします。 AgentCore Gateway を使ったツールアクセス – エージェントがツールを呼び出す必要がある場合、汎用的なルーティングではなく MCP ツールのオーケストレーション専用に設計された プール化された AgentCore Gateway を呼び出します。ゲートウェイは次の処理を行います。 AgentCore Identity を使って JWT を検証します。 検証済みのトークンからテナントコンテキストを抽出します。 ツール呼び出しをプール化されたバックエンドリソース (API、データベース、ナレッジベース) にルーティングします。 テナントスコープの認証情報と設定を通じてツールレベルの分離を実施します。 横断的な関心事に対してポリシーの実施とインターセプターを適用します。 応答フロー – ツールの応答はゲートウェイを通じてエージェントに戻り、エージェントは推論を完了します。エージェントの応答はランタイムを通じて、セラー (販売者) が運用するプロキシに戻り、プロキシはユーザーに返す前にテナント固有のフォーマットを適用します。 プールモデルは非常に効率的で、多数の小規模テナントを抱える場合には唯一の選択肢になることもあります。トレードオフは、きめ細かなアクセス制御のテストをより厳密に行う必要があり、コストをテナントに配分するためにより多くの計装が必要になる点です。 図 3: AgentCore によるプールモデル AgentCore でのブリッジモデルの実装 ブリッジモデル (ハイブリッドモデル) は、サイロとプールのデプロイパターンの戦略的な中間に位置します。このアプローチは、共有インフラストラクチャのコスト効率と、分離されたデータリソースのセキュリティ上の利点を組み合わせます。 ニーズに応じて、ブリッジパターンはさまざまな方法で実装できます。 プレミアムティアのテナントにはサイロ化された AgentCore Runtime/ゲートウェイ/ツール/メモリを、標準ティアにはプール化された共有の AgentCore Runtime/ゲートウェイ/ツール/メモリを使う サイロ化されたランタイムと、プール化されたゲートウェイ/ツールおよびメモリを使う その他 考え方は、特定のテナント分離パターンに縛られるのではなく、各層やコンポーネントごとにテナンシーを選択できるようにすることです。このアプローチは、実装に応じて両方のアプローチの利点を組み合わせます。たとえば SOC アナリストのユースケースでは、各調査が独自の分離された microVM で実行されるため、プール化されたエージェントランタイムがエージェントをホストして推論を行う一方で、ゲートウェイをサイロ化してメール API のやり取りやその他のダウンストリームのテナントリソースを処理する、といった構成が考えられます。 図 4: AgentCore によるブリッジモデル (パターン 1) 図 5: AgentCore によるブリッジモデル (パターン 2) 次のステップ 本記事では、マルチテナントエージェントを構築するための基礎的な概念を取り上げました。今後の記事では、これらの概念の実装面をより深く掘り下げます。具体的には、設計上の検討事項のセクションで概説したコンポーネントを組み込みながら、プールとサイロの両方のデプロイモデルのエンドツーエンドの実装を順を追って解説します。 まとめ 本番環境に対応したマルチテナントのエージェント型アプリケーションを構築するには、機能する AI エージェントだけでは不十分です。テナント分離、ID 管理、コスト配分、そしてあらゆる層でのセキュリティに対処する、包括的なアーキテクチャのアプローチが求められます。Amazon Bedrock AgentCore は、これらの課題に取り組むために必要な基礎的なプリミティブ (基本要素) を提供し、特定のティアリング戦略やコンプライアンス要件に合わせて調整できる、サイロ、プール、ブリッジの各モデルを通じた柔軟なデプロイパターンを提供します。専用インフラストラクチャを必要とするエンタープライズ顧客にサービスを提供する場合でも、数百もの小規模テナントにわたってコストを最適化する場合でも、AgentCore の統合された Runtime、Gateway、Memory、Identity、Observability の各コンポーネントを使えば、車輪の再発明をせずに、安全でスケーラブルなマルチテナントのエージェント型ワークフローを構築できます。これらのプリミティブは連携して、テナントのデータ分離、スコープされたツールアクセス、正確なコスト配分、セキュリティ境界の維持を支援し、マルチテナントエージェントアーキテクチャの複雑さを、SaaS ビジネスの成長に合わせてスケールする、管理しやすく本番環境に対応したソリューションへと変えます。 Amazon Bedrock AgentCore でこれらのマルチテナントエージェントを構築する実践的な体験のために、 マルチテナントエージェントのワークショップ をぜひお試しください。 著者について Dhawal Patel AWS のプリンシパル生成 AI テクニカルリードです。大企業から中規模のスタートアップまで、さまざまな組織と協力し、エージェント型 AI、ディープラーニング、分散コンピューティングに関する課題に取り組んできました。 Anubhav Sharma AWS のプリンシパルソリューションアーキテクトで、ビジネスクリティカルなアプリケーションの設計と構築に 20 年以上携わってきました。独立系ソフトウェアベンダー (ISV) と緊密に連携し、AWS 上での SaaS ソリューションの構築、デプロイ、運用を支援しています。近年は、エージェント型 AI への変革を通じて、お客様が製品やワークフローを再構築できるよう支援しています。 Aswin Vasudevan AWS のセキュリティ・ISV 担当シニアソリューションアーキテクトです。生成 AI とサーバーレスアーキテクチャの大ファンで、お客様と協力してビジネス価値を生み出すソリューションを構築することを楽しんでいます。 Sahil Thapar AWS のプリンシパルソリューションアーキテクトで、ISV のお客様と協力して、AWS クラウド上で高可用性、スケーラブル、かつ回復力のあるアプリケーションを構築しています。コンテナ、機械学習、生成 AI を専門とし、企業が本番環境品質のソリューションを設計できるよう支援しています。 Ujwal Bukka Amazon Web Services のシニアパートナーソリューションアーキテクトで、スケーラブルでエンタープライズ品質のアプリケーションの構築と提供に 20 年以上携わってきました。独立系ソフトウェアベンダー (ISV) と協力し、AWS 上でのマルチテナント SaaS ソリューションの設計、立ち上げ、運用を支援しています。また、エージェント型 AI を使って ISV の製品やワークフローを近代化できるよう、AWS 上でのソリューション設計から戦略策定、市場投入の実行まで幅広く支援しています。Ujwal は、実践的なワークショップ、技術コンテンツ、効果の高いイネーブルメントプログラムを通じてパートナーの成功を後押しすることに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kensuke Fukumoto がレビューしました。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 いよいよ AWS Summit Japan 2026 が今月の6 月 25 日（木）・26 日（金）の 2 日間に幕張メッセで開催されますね！日本最大級の「AWS を学ぶイベント」として、基調講演に加え、エージェント型 AI や機械学習、セキュリティ、アプリケーションモダナイゼーションまで、260 を超えるセッションや事例が揃います。 今回の AWS Summit では、私も Windows 依存のレガシーなアプリケーションを、生成 AI を活用していかに効率よくモダナイズするかをテーマにしたセッション ( セッション MAM331 ) で登壇します。AWS Transform for .NET を起点に、SQL Server から Amazon Aurora PostgreSQL へのデータベース移行、Linux コンテナ化、さらに Kiro を活用した加速アプローチまで、実際の事例とデモを交えてご紹介します。移行の「先送り」に悩んでいる方は、ぜひお越しください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年6月1日週の主要なアップデート 6/1(月) Amazon Bedrock で OpenAI の GPT-5.5、GPT-5.4、Codex が一般提供開始 Amazon Bedrock で OpenAI の最先端モデルである GPT-5.5 および GPT-5.4 が一般提供 (GA) を開始しました。GPT-5.5 は OpenAI の最も高性能なモデルで、自律的なコーディング、データ分析、複数ステップのタスク実行に優れています。同時に、AI コーディングエージェント Codex も Bedrock 経由で利用可能になり、Visual Studio Code、JetBrains、Xcode との統合を通じてソフトウェア開発を支援します。料金は OpenAI の直接提供と同額で、AWS の既存コミットメントにカウントされます。なお、本記事執筆時点では、これらのモデルは Bedrock マネジメントコンソールのモデルカタログにはまだ表示されておらず、OpenAI Responses API 経由 (bedrock-mantle エンドポイント) で利用可能です。GPT-5.5 は US East (オハイオ)、GPT-5.4 は US East (オハイオ) と US West (オレゴン) の 2 リージョンからの提供開始となっています。 Amazon Bedrock AgentCore Identity で AWS Secrets Manager の既存シークレットを利用可能に Amazon Bedrock AgentCore Identity で、AWS Secrets Manager に保存された既存のシークレット ARN を Credential Provider から直接参照できるようになりました。従来のサービス管理型シークレットでは、作成時にリソースタグを適用したり、カスタマーマネージドキー (CMK) で暗号化したりすることができませんでした。この機能により、組織のガバナンスポリシーに従ってシークレットを作成・管理し、CMK、タグ戦略、自動ローテーション、リソースポリシーを適用した上で、AgentCore Identity から参照できます。東京リージョンを含む、14 のリージョンで一般提供が開始されています。 Amazon Quick が MCP 接続で VPC 接続をサポート Amazon Quick が、プライベートネットワーク上でホストされた Model Context Protocol (MCP) サーバーに Amazon Virtual Private Cloud (VPC) 経由で接続できるようになりました。これまで MCP サポートはパブリックインターネット経由でアクセス可能なサードパーティホストサーバーに限定されていましたが、今回のアップデートにより、企業は Amazon EC2、AWS Fargate、Amazon Bedrock AgentCore などのプライベートネットワーク上で動作する MCP サーバーを、インターネットに公開することなく Quick に接続できます。この機能は Enterprise エディションにて利用可能です。 6/2(火) Amazon RDS for SQL Server が Bring Your Own Media をサポート Amazon RDS for SQL Server が Bring Your Own Media (BYOM) のサポートを開始しました。BYOM により、Microsoft の License Mobility プログラムを通じて既存の SQL Server ライセンスと Software Assurance を RDS で再利用できます。ユーザーは SQL Server の RTM (Release To Manufacturing) インストールメディアを S3 にアップロードし、AWS は SQL Server ライセンス費用を請求せず、インフラストラクチャ費用 (コンピュート、ストレージ、I/O、データ転送) と Windows OS 費用のみを課金します。これにより、オンプレミスや EC2 で SQL Server を運用している企業が、追加ライセンス費用なしでマネージドサービスへ移行できます。 Amazon ElastiCache for Valkey の 耐久性機能のサポートを発表 Amazon ElastiCache for Valkey が耐久性 (durability) 機能をサポートしました。この機能により、マイクロ秒の読み取りレイテンシを維持しながら、データ損失を許容できないワークロードに ElastiCache を利用できます。Multi-AZ transactional log を使用してデータを複数のアベイラビリティゾーン (AZ) に永続化し、障害時の高速フェイルオーバー、データベースリカバリ、ノード再起動を実現します。Synchronous writes (同期書き込み) と Asynchronous writes (非同期書き込み) の 2 つのオプションから選択でき、データ保護とパフォーマンスのバランスを調整できます。Valkey 9.0 以降で利用可能で、すべての AWS 商用リージョン、AWS 中国リージョン、AWS GovCloud (US) リージョンで提供されます。詳細は こちらのブログ をご参照ください。 AWS Config が internal service linked rules をサポート開始 AWS Config は internal service linked rules のサポートを開始しました。この機能により、AWS サービス（AWS Security Hub CSPM など）が AWS Config managed rules を使用して AWS リソースの設定を評価できるようになります。Internal service linked rules は既存の service linked recorder 機能を拡張し、AWS サービスがサービス固有の機能として AWS Config のルール評価を展開・管理できるようにします。評価結果はルールを展開した AWS サービスに直接配信され、AWS Config から顧客への課金は発生しません。これらのルールは既存の顧客管理 AWS Config レコーダーおよびルールとは独立して動作するため、顧客は引き続き AWS Config をインベントリ、ガバナンス、コンプライアンス、監査のユースケースに使用できます。 6/3(水) AWS Config が 9 つの新しいリソースタイプに対応 AWS Config が Amazon Bedrock、Amazon Bedrock AgentCore、Amazon SageMaker の 3 つのサービスにわたって 9 つの新しいリソースタイプに対応しました。これにより、生成 AI ワークフロー (Bedrock Flows)、エージェント評価機能 (Amazon Bedrock AgentCore)、大規模 ML インフラ (SageMaker HyperPod) などの設定を継続的に記録・監査できるようになります。すべてのリソースタイプの記録を有効にしている場合、これらは自動的に追跡対象に含まれます。新しいリソースタイプは Config Rules と Config Aggregator でも利用可能です。 Amazon SageMaker Unified Studio が 12 言語でのローカライズ体験をサポート Amazon SageMaker Unified Studio のユーザーインターフェースが日本語を含む 12 言語に対応しました。グローバルチームのデータエンジニア、アナリスト、データサイエンティストが、最も使いやすい言語でナビゲート、構築、コラボレーションできるようになり、生産性が向上します。ブラウザの言語設定から自動検出されるほか、プロフィール設定で手動変更も可能です。 AWS Step Functions が AgentCore を活用したエージェント推論ステップに対応 AWS Step Functions が Amazon Bedrock AgentCore のマネージドハーネスと統合され、ワークフロー内に AI エージェントの推論ステップを追加できるようになりました。Workflow Studio からハーネスを直接作成でき、ドキュメント分類や非構造化フォームの要素抽出など、推論タスクをワークフローに組み込めます。複数のエージェントを並列または順次実行でき、重要なアクションの前に承認ステップを追加できます。実行履歴にはエージェントの入出力、トークン使用量、実行時間が記録され、CloudWatch にターンごとの推論詳細へのリンクが表示されます。 6/4(木) Amazon Bedrock が OpenAI および Anthropic 互換 API に最適化されたコンソールを発表 Amazon Bedrock は、OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages API に対応した新しいコンソール体験を発表しました。このコンソールは、bedrock-mantle エンドポイントでの利用に最適化されており、実験、反復、スケールという実際の開発フローに沿ったワークフローを提供します。プロジェクト単位で作業を整理し、モデルカタログの一覧比較、評価の実行、使用状況インサイトの確認を 1 つのビューで完結できます。また、プロジェクト固有のモデル ID やエンドポイント URL が自動的に埋め込まれたコードサンプルを生成するため、開発者はコンソールからコードをコピーしてそのまま実行できます。 Amazon Cognito がマルチリージョンレプリケーションに対応 Amazon Cognito User Pool でマルチリージョンレプリケーション機能が利用可能になりました。この機能により、ユーザー認証情報や User Pool 設定をセカンダリリージョンにほぼリアルタイムで同期し、リージョン障害時にもサインイン済みユーザーが再認証なしでアプリケーションを利用できます。Essentials または Plus プランのアドオンとして提供され、東京リージョンを含む 16 リージョンで利用できます。 Amazon SageMaker Data Agent がビジネスコンテキストを会話に統合 Amazon SageMaker Data Agent が SageMaker Catalog のビジネスコンテキストとメタデータと統合し、技術的なテーブル名ではなくビジネス用語を使用してデータセットを発見し、より正確な SQL および Python コードを生成できるようになりました。この統合により、Collibra、Atlan、Alation から同期されたものを含む、企業が数ヶ月かけて SageMaker Catalog に蓄積したビジネスコンテキストを活用できます。データ実務者は「顧客維持率を計算して」「顧客離反に関するデータは何がある？」といった質問が可能になり、初回試行時からより正確なコード生成とデータガバナンスの尊重を実現します。 6/5(金) AWS MCP Server が cross-account および cross-role アクセスに対応 Agent Toolkit for AWS の一部である AWS Model Context Protocol (MCP) Server において、cross-account および cross-role アクセス機能を発表しました。この機能により、Kiro、Claude Code、Codex などの AI コーディングエージェントを使用する開発者は、セッションの再起動なしに単一のセッション内で複数の AWS アカウントと AWS Identity and Access Management (IAM) ロールを横断して作業できるようになります。従来はプロファイルを切り替えるたびに AI コーディングセッションを停止し、ローカルの AWS 認証情報を更新し、MCP サーバーを再起動する必要がありました。現在は、AWS MCP Server を使用する AI エージェントが各コマンドでプロファイルを指定できるため、アカウントとロールをシームレスに切り替えられます。 Amazon ECS with AWS Fargate が 32vCPU 構成をサポート開始 Amazon ECS with AWS Fargate が 32 vCPU の新しいコンピュート構成をサポートしました。従来の最大構成である 16 vCPU から倍増し、60 GiB、120 GiB、244 GiB の 3 つのメモリオプションを提供します。x86 と ARM の両アーキテクチャに対応し、Linux 環境で利用できます。この拡張により、AI 推論、大規模データ処理、ハイパフォーマンスコンピューティング (HPC) などの高負荷ワークロードを、サーバー管理なしで実行できるようになりました。Fargate と Fargate Spot の両方のキャパシティプロバイダーで利用可能で、既存の Compute Savings Plans が自動適用されます。 Amazon Bedrock AgentCore Runtime に対話型シェル (インタラクティブターミナル) 機能を導入 Amazon Bedrock AgentCore Runtime に新しい InvokeAgentRuntimeCommandShell API が追加され、WebSocket 経由で実行中のエージェントセッションに対話型シェルアクセスが可能になりました。この API は PTY-backed terminal (疑似端末) を提供し、カラー出力、タブ補完、Ctrl+C 処理、ターミナルリサイズ、ネットワーク切断時の自動再接続に対応します。既存の InvokeAgentRuntimeCommand API (ワンショット実行) と異なり、シェルセッションは環境変数、作業ディレクトリ、コマンド履歴を永続的に保持します。Claude Code、OpenAI Codex、Amazon Kiro などのコーディングエージェントをホスティングする開発者にとって、ローカルターミナルと同様の操作感でエージェント環境を操作・デバッグできるようになります。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

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 。