2026 年 7 月 1 日より、Claude Sonnet 5 が Kiro の IDE 、 CLI 、 Web でご利用いただけるようになりました。Sonnet 5 は Anthropic がこれまでに提供した中で最もエージェント性能に優れた Sonnet モデルであり、Sonnet 4.6 から大幅にアップグレードされ、推論力・ツール利用・コーディング能力が強化されています。しかも価格は Sonnet クラスのままです。 Sonnet クラスの価格で、Opus クラスに近いエージェント性能を 多くの開発者にとって、Agentic AI の時代は Sonnet クラスのモデルから始まりました。しかし最近では、エージェント性能における最も明確な向上は Opus 系列で見られていました。Sonnet 5 はこのギャップを縮めます。推論、ツール利用、コーディング、知的作業において、その性能は Opus 4.8 に近づきつつ、コストは大幅に抑えられています。 Kiro では、これにより実質的な「コストと性能の選択肢」が手に入ります。最も難しいタスクで最大限の精度が必要なときは Opus 4.8 を、強力なエージェント性能をより多く実行できる価格帯で使いたいときは Sonnet 5 を選べます。両者の間で実行レベルを調整し、タスクごとに最適なバランスを見つけることができます。 エンドツーエンドのエージェント作業のために構築 Kiro の IDE、CLI、Web 全体において、Sonnet 5 は編集前に計画を立て、監督なしでより長く動作し続け、明示的に指示されなくても自身の出力を確認します。初期テストを行ったユーザーからは、従来の Sonnet モデルでは途中で止まってしまっていた複雑なタスクを最後までやり遂げる、という感想が一貫して寄せられています。 IDE における 仕様駆動のワークフロー では、これはより広範囲な変更において、スペックからのズレが少ない、より忠実度の高い実装につながります。CLI と Web においては、ブラウジング、ターミナル操作、複数ファイルにわたるリファクタリングといった複数ステップのエージェントタスクが、より確実に完了まで到達し、手詰まりが減り、密に監督する必要も少なくなります。 利用可能な環境 Sonnet 5 は、AWS us-east-1 (バージニア北部)リージョンおよび AWS Europe (フランクフルト) リージョンにおいて、クロスリージョン推論のサポートとともに、Kiro Pro、Pro+、Pro Max、Power のお客様に対して 実験的サポートとして 段階的に展開されます。100万トークンのコンテキストウィンドウを備え、クレジット倍率は Sonnet 4.6 と同じ 1.3 倍です。 トークナイザーの変更に関する注記 : Sonnet 5 は更新されたトークナイザーを使用しており、Sonnet 4.6 とはテキストの処理方法がわずかに異なります。同じ入力でも、コンテンツの種類によっておおよそ 1.0〜1.35 倍のトークン数になる場合があります。 Kiro をダウンロード するか、IDE や CLI を再起動して最新のモデルを確認してください。 Web をご利用の方 は、ブラウザを再読み込みするとモデルセレクターに Sonnet 5 が表示されます。 本記事は Sonnet 5 is now available in Kiro (2026年7月1日公開、著者: Vipin Mohan)の日本語翻訳版です。

みなさん、こんにちは。ソリューションアーキテクトの武松です。 AWS は数十年にわたり、世界中で事業を展開する何百万のお客様を同時に保護するためのプロセスとツールを開発してきました。AWS のセキュリティチームと脅威インテリジェンスチームは、日々 AI と自動化を駆使した取り組みを続けています。たとえば AI を活用したログ分析により、SecOps エンジニアがセキュリティログの分析に要する時間は平均 6 時間からわずか 7 分へと短縮され、この 50 倍もの生産性向上により脅威の検出と対応をかつてないスピードで行えるようになっています。あるお客様を保護する過程で得た知見は、すべてのお客様の保護に役立ちます。この規模で運用しているからこそ、新たに検出した脅威がすべてのお客様の防御強化に直結します。AI はすでにその中核を担っています。 2026 年 4 月 7 日、 Anthropic が Project Glasswing を発表しました 。世界で最も重要なソフトウェアの保護と、AI の進化に伴い業界に求められるサイバーセキュリティの実践を前進させることを目的としたイニシアチブです。これを支えるのが、サイバーセキュリティにおける推論能力と AI 能力の飛躍的な進歩を実現する新しいクラスの AI モデル Claude Mythos です。Claude Mythos は Anthropic のこれまでのフロンティアモデルを上回る知性と能力を備え、サイバーセキュリティやソフトウェアコーディング、複雑な推論タスクで高いパフォーマンスを発揮します。Project Glasswing の一環として、AWS では継続的な AI セキュリティレビューが行われている重要なコードベースに Claude Mythos をすでに適用しています。十分にテストされた環境であっても、コードをさらに強化できる箇所の特定に役立っています（参考：「 AI を活用した大規模なセキュリティ防御の構築 — 脅威が出現する前に 」）。 しかし、こうした強力な AI は防御側だけのものではありません。国家レベルの攻撃者やランサムウェアオペレーター、サプライチェーン攻撃者も、すでに AI を活用して攻撃のスケールを拡大しています。 AWS Japan パブリックセクター技術統括本部では、2026 年 4 月より、官公庁・自治体・教育・医療などパブリックセクターのお客様向けのセキュリティワークショップシリーズを月次で開催しています。4 月・5 月の第 1 回・第 2 回ではランサムウェア対策をテーマに、 Amazon GuardDuty や AWS Security Hub を用いた脅威検知と統合セキュリティ管理を扱いました（参考：「 第 1 回・第 2 回の開催レポート 」）。続く 6 月・7 月の第 3 回・第 4 回では、 金融庁が対応を要請 し、 厚生労働省が医療機関等との意見交換を開始する など状況が急速に変化する中、一刻も早く実践的な対策をお届けすべく、テーマを「Claude Mythos 時代の脅威への対応」とし、第 3 回で Amazon Inspector 、第 4 回で AWS Security Agent を用いたハンズオンを実施しました。 本記事では第 3 回・第 4 回の開催レポートをお届けします。 ワークショップの概要 第 3 回・第 4 回のワークショップは「Claude Mythos 時代の脅威への対応」を共通テーマとしています。講師はシニア セキュリティ ソリューションアーキテクトの中島 章博氏が務めました。セキュリティは組織全体で取り組むテーマであることを踏まえ、考え方を理解する座学と手を動かすハンズオンの 2 部構成とすることで、幅広い立場の方にメリットがあるよう工夫しています。前半の座学でフロンティア AI 時代の脅威動向やセキュリティ対策の考え方を解説し、後半はハンズオン形式で実際に AWS のセキュリティサービスを体験していただきました。 座学では、Claude Mythos / Project Glasswing の登場により今後予想される 2 つの脅威を解説しました。(1) 大量の脆弱性が公開されパッチ適用が追いつかなくなる N デイ攻撃の増加と、(2) フロンティア AI の一般化によるサイバー攻撃高度化とゼロデイ攻撃の増加です。対応策として、前者にはパッチ適用の日常業務化やマネージドサービスの活用、後者には AI を活用した脆弱性スキャンとセキュリティレビューをご紹介しました。これらの対策を実践するハンズオンとして、第 3 回では Amazon Inspector による脆弱性管理とパッチ運用の自動化を、第 4 回では AWS Security Agent による設計レビュー・コードレビュー・自動ペネトレーションテストを通じた AI エージェントによるプロアクティブなセキュリティ評価を体験いただきました。 Claude Mythos 時代のサイバーセキュリティ 第 3 回: Amazon Inspector で実現する脆弱性管理（2026 年 6 月 12 日） Amazon Inspector とは Amazon Inspector は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナイメージ、 AWS Lambda 関数などのワークロードやコードリポジトリを自動的に検出し、ソフトウェアの脆弱性や意図しないネットワークへの露出がないかスキャンする脆弱性管理サービスです。 ハンズオン概要 参加者一人ひとりにワークショップ専用の AWS サンドボックス環境が払い出されます。この環境には複数の Amazon EC2 インスタンス、コンテナイメージ、Lambda 関数があらかじめデプロイされており、Amazon Inspector が継続的にスキャンし脆弱性を検出しています。参加者はセキュリティ担当者の立場で、検出（Detect）→ 優先順位付け（Prioritize）→ 修復（Remediate）の一連の流れを体験します。 ハンズオンは「基礎・検出」「修復・自動化」の 2 パートで構成されています。 前半の基礎・検出パートでは、Amazon Inspector ダッシュボードでカバレッジと脆弱性の全体像を把握し、検出結果の重大度・影響リソースの読み方を学びます。抑制ルールによるノイズ削減や、CVE 脆弱性データベースでの CVSS スコアの調査も行います。 後半の修復・自動化パートでは、 AWS Systems Manager Patch Manager を使い、Amazon Inspector が検出した脆弱性に対してフリート全体でパッチを一括適用します。パッチベースラインの定義から、Run Command による Amazon EC2 インスタンスのスキャンと不足パッチのインストール、パッチポリシーによるスケジュール設定まで実施いただきました。そして、パッチ適用後に Amazon Inspector が再スキャンし、検出結果が自動的にクローズされる継続的な脆弱性管理の流れを体験いただきました。さらに、Lambda 関数のコードスキャンで検出された脆弱性を修正して Amazon Inspector で修復を確認するサーバーレスの脆弱性管理や、Amazon Inspector SBOM Generator と Inspector Scan API を組み合わせた CI/CD パイプラインへの脆弱性スキャン統合にも取り組みました。 「Amazon Inspector を有効にしたが、検出結果の優先順位付けや実際のパッチ適用プロセスをどう自動化すればよいかわからない」という方にとって、開発ライフサイクル全体（コード → ビルド → デプロイ → 実行）での脆弱性管理を安全な環境で体験できる内容です。ワークショップ教材は「 アプリケーションセキュリティワークショップ 」として公開しています。 Amazon Inspector ワークショップ環境の概要 第 4 回: セキュリティ運用を支援する AWS Security Agent（2026 年 7 月 2 日） AWS Security Agent とは AWS Security Agent は、すべての環境における開発ライフサイクル全体でアプリケーションを積極的に保護するフロンティアエージェントです。お客様のアプリケーションに合わせたオンデマンドのペネトレーションテストを実施し、確認済みのセキュリティリスクを発見して報告します。また、お客様の要件に合わせてカスタマイズされた自動セキュリティレビューを実施し、設計からデプロイまでセキュリティを統合することで、脆弱性を早期かつ大規模に防ぐのに役立ちます。 ハンズオン概要 第 3 回と同様に参加者ごとにサンドボックス環境が払い出されます。この環境には、学習用に意図的に脆弱性を持たせた架空の Web サイト Juice Shop が AWS Fargate 上にデプロイされており、AWS Security Agent が設計・コード・本番環境をそれぞれ検証できる状態になっています。参加者はセキュリティ担当者の立場で、要件定義（Requirements）→ 設計レビュー（Design Review）→ コードレビュー（Code Review）→ ペネトレーションテスト（Pentest）の一連の流れを体験します。 ハンズオンは 4 つのモジュールで構成されています。 Module 1（セキュリティ要件） : AWS Security Agent がレビュー時に適用するセキュリティ基準を定義します。業界標準とベストプラクティスに基づき AWS が提供・維持するマネージドセキュリティ要件に加え、組織固有のポリシーに対応するカスタムセキュリティ要件（JWT 認証のベストプラクティス、FTP/SFTP によるファイルホスティングの禁止など）を作成しました。 Module 2（設計レビュー） : Juice Shop アプリケーションの詳細な設計ドキュメントをアップロードし、Module 1 で定義したセキュリティ要件と照らし合わせた設計レビューを実施します。コードを書く前の段階で JWT 実装の問題などアーキテクチャ上のセキュリティ課題を発見できることを体験いただきました。 Module 3（コードレビュー） : リポジトリ全体を対象としたコードスキャンと、GitHub プルリクエストに対する自動分析の 2 種類のコードレビューを実施しました。設計レビューで指摘された JWT の問題をコードで修正し、PR を作成して AWS Security Agent からのフィードバックを確認しました。 Module 4（ペネトレーションテスト） : AWS Security Agent が Juice Shop に対して自律的に実行した自動ペネトレーションテストの結果を調査します。SQL インジェクションなどの確認済み脆弱性を AWS CloudShell から実際に再現し、検出結果の信頼性を確認しました。 「ペネトレーションテストを実施したいが、人手やコストの制約でなかなか実施できない」「開発ライフサイクル全体でアプリケーションを積極的に保護したい」という方にとって、AI エージェントを活用したセキュリティ運用の実践を体験できる内容です。ワークショップ教材は「 AWS Security Agent ハンズオン: プロアクティブな AppSec と自律型ペネトレーションテスト 」として公開しています。 AWS Security Agent ワークショップ環境の概要 参加者からのフィードバック 第 3 回は計 122 名、第 4 回は 59名 の方にご参加いただき、ご好評をいただきました。官公庁・教育・医療など幅広い組織からご参加いただいています。「とても分かりやすい座学・ハンズオンだった」「自組織での活用イメージが湧いた」「Inspector を利用してみたい」など、日々の運用に直結する学びを得られたというフィードバックをいただきました。 まとめと今後の取り組み 本ワークショップシリーズは、皆様のご要望に応じて今後も継続的に開催予定です。第 5 回（2026 年 8 月 21 日）は「耐障害性ライフサイクル実践ワークショップ ― FlyWheel で回す継続的なレジリエンス強化」をテーマに、たこ焼き注文システムを題材にした耐障害性ライフサイクルの各ステージを実践いただきます。ご関心のある方は担当の AWS アカウントチームまでお気軽にお声がけください。 ワークショップで学んだ内容を次のアクションにつなげるために、AWS では以下のようなセキュリティ支援を提供しています。 AWS セキュリティ成熟度モデル : 組織のセキュリティ対策の現在地を把握し、次に取り組むべき施策を明確にするフレームワークです。脆弱性管理やポスチャ管理が自組織ではどの段階にあるのか、確認してみてはいかがでしょうか。 脅威モデリングワークショップ : 設計段階からセキュリティを組み込みたい方に向けて、サンプルシステムを対象としたワークショップ形式のほか、実際のワークロードを対象とした個別支援も実施しています。 Security Health Improvement Program (SHIP) : お客様のセキュリティ状況を可視化し、改善に向けた具体的なアクションプランの策定と実行を継続的に支援するプログラムです。自組織のセキュリティを体系的に強化したい方におすすめです。詳しくは「 AI 時代におけるセキュリティ体制の強化 」もあわせてご覧ください。 上記の支援にご興味がある方は、担当の AWS アカウントチームまでお気軽にお声がけください。 著者 武松 未来 (Mirai Takematsu) — AWS Japan, Public Sector, Associate Solutions Architect 今井 真宏 (Masahiro Imai) — AWS Japan, Public Sector, Solutions Architect

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクトの深井 宣之です。 2026 年 6 月 5 日に AWS 公共パートナーネットワーク（PSN）セミナーとして「IT 基盤の環境変化に対応する AWS マイグレーション」と題した Webinar を開催しました。本ブログでは開催内容について Blog にまとめたものになります。投影資料もダウンロードすることが可能です。 本セミナーでは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター統括本部 パートナーアカウントマネージャーの坂口 雄一郎と、同 パブリックセクター技術統括本部 パートナーソリューションアーキテクトの深井 宣之が登壇し、ハードウェアの価格高騰や納期遅延、仮想化ソフトウェアのライセンス体系変更といった IT 基盤を取り巻く環境変化を踏まえ、AWS マイグレーションの全体像をご紹介しました。初級レベルの内容として、AWS やクラウドの知識がない方にもご参加いただける構成としています。 資料（PDF）の ダウンロードはこちら から可能です。 IT 基盤を取り巻く環境変化 近年、エンタープライズサーバーやメモリ、SSD ストレージなどハードウェアの価格高騰が続いており、リードタイムも延長しています。多くの現場では納期が読めず、入札や調達計画に影響が出ているのが実態です。 加えて、仮想化ソフトウェアのライセンス体系変更により、既存の IT 基盤を従来と同じコストで維持することが困難になるケースが増えています。 セキュリティ面では、AI を悪用したサイバー攻撃が高度化しており、Claude Mythos に象徴されるような AI 時代のセキュリティ脅威が現実のものとなっています。一方で、日本政府は行政機関での AI 徹底利活用を基本方針として決定しており、守りと攻めの両面での対応が求められています。 AWS が選ばれる理由 こうした環境変化を踏まえ、マイグレーション先の IT 基盤として AWS が選ばれる 7 つの理由を紹介しました。 IT リソース調達時間の短縮 — オンデマンドで即座にリソースを確保でき、数か月の調達リードタイムから解放 コスト最適化 — 従量課金モデルにより、使った分だけの支払いが可能 継続的な値下げ — AWS はこれまで 161 回 (2026年 5月時点) の値下げを実施 耐障害性と高可用性 — グローバルインフラストラクチャにより、マルチ AZ 構成での高可用性を実現 AI 時代に対応するセキュリティ — AWS は主要なコンプライアンスに準拠しておりその中で ISMAP 認定も取得。AWS では従前より AI を活用したセキュリティの高度化に取り組む 最新 AI サービスへのアクセス — Amazon Bedrock をはじめとする AI サービスや、Anthropic 社との戦略的提携による最新モデルへのアクセスが可能 移行を成功に導くためのソリューション — 移行ツールやプログラムが充実 AWS マイグレーションの進め方 移行パス AWS では移行戦略として 7 つのパス（7R）を定義しています。多くのケースではリホスト（Lift-and-shift）で移行し、まず AWS に移行することでハードウェア保守から解放され、空いた工数でモダナイゼーションに注力する段階的アプローチが一般的です。 リロケート: Amazon Elastic VMware Service (Amazon EVS) VMware 環境をそのまま AWS に移行する場合は、Amazon Elastic VMware Service（Amazon EVS）が活用できます。東京リージョンで既に利用可能です。 リホスト: AWS Application Migration Service（AWS MGN） OS やアプリケーションをそのまま移行するリホストには AWS MGN が利用できます。継続的にデータをレプリケーションし、ダウンタイムを最小化します。エージェント型とエージェントレス型の 2 つの方式があります。 データベース移行: AWS Database Migration Service (AWS DMS) と AWS Schema Conversion Tool (AWS SCT) データベースの移行には AWS DMS が利用できます。異なるエンジン間の移行では AWS SCT を併用します。 モダナイゼーション: AWS Transform AWS Transform は大規模な移行とモダナイゼーションのための初のエージェント型 AI サービスです。 コスト把握: Migration Evaluator 移行後コストを事前に把握する無料サービスです。約 1 週間のデータ収集後に評価レポートを提示します。 MAP（Migration Acceleration Program） MAP は移行時の二重投資負荷を軽減するため、クレジットや現金還元を提供するプログラムです。MAP の詳細は AWS Partner Central をご参照ください。 お客様事例 東京都中央区 — Amazon WorkSpaces による VDI 刷新 オンプレミス VDI のレスポンス低下を Amazon WorkSpaces で解消。基幹系・内部事務系の両セグメントで利用しています。 岩手県教育委員会 — 共同利用型校務支援システム 全 33 市町村が共同利用する校務支援システムの基盤として AWS を採用。校務支援システムを含む学校関連のIT基盤では、長崎県、新座市、名古屋市、福岡市でも実績があります。 同志社大学 — 情報インフラの全体最適化 4 系統の情報インフラを AWS に移行。AWS MGN を活用し、ダウンタイム削減とコスト最適化を実現しました。 おわりに IT 基盤を取り巻く環境は大きく変化しています。AWS はこうした環境変化への対応を支援します。ご興味をお持ちの方は御社担当の Partner Account Manager にお気軽にご連絡ください。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクト 深井 宣之が執筆しました。

本ブログは井村屋グループ株式会社様、株式会社 Hashup 様、Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です。 昨今、食品・製造業のお客様から「需要予測の精度向上」や「属人化した業務の自動化」についてご相談いただく機会が増えています。特に食品業界では、賞味期間の制約や季節変動の大きさから、需要予測の精度が欠品・廃棄に直結するため、AI 活用への期待が高まっています。 1896年の創業から130年、1947年の設立から80年目を迎え「あずきバー」や「肉まんあんまん」で知られる 井村屋グループ株式会社 様（以下、井村屋グループ様）は、 株式会社 Hashup 様（以下、Hashup 様）と連携し、 Amazon SageMaker Canvas を活用したチルド製品（肉まん・あんまん・ピザまん等）の翌日出荷数 AI 需要予測の自動化のPOCを実施しました。本記事では、熟練担当者の経験と勘に依存していた需要予測業務を、AWS 上で再現・自動化した取り組みについてご紹介します。 お客様の状況と検証に至る経緯 井村屋グループ様は、DX 戦略プロジェクト（2024年度完了）を経て、需給管理と SCM 標準化プロジェクトを推進してきました。その次のステップとして、標準化された需給データを活用した AI 需要予測システムの導入に着手しました。 同社のチルドタイプの肉まんあんまんは、季節性や営業施策によって出荷量の変動が大きく、さらに賞味期間が短いため、特に高い予測精度が求められます。しかし、従来の予測業務は熟練担当者の経験と勘に依存しており、欠品や廃棄のリスクが高く、生産・出荷計画の最適化が困難な状況でした。 「業務担当者が毎日約2時間をかけて、複数の Excel シートや kintone アプリ、基幹システムからデータを手作業で抽出・整形し、前週トレンドや経験則をもとに翌日の出荷数を決定していました。まさに運用当初から継ぎ足して使われてきた”秘伝のたれ”のような業務でした」と熟練担当者は当時を振り返ります。 また、この業務は特定の担当者に属人化しており、引き継ぎリスクや、気象データなど予測に有効な外部情報を活用できていないという課題もありました。 こうした課題を解決するため、井村屋グループ様は AWS とのパートナーシップに加え、AI・データ活用に強みを持つ Hashup 様をコンサルティングパートナーとして迎え、3 社体制でPOCを実施・推進しました。 ソリューション／構成 Hashup 様が中心となり、AWS 上に以下の 2 つのアプローチでシステムを構築しました。 ① 業務自動化：データレイクの構築 複数の Excel シート、kintone アプリ、基幹システムに散在していたデータの参照・抽出・整形の流れを、AWS 上にデータレイクとして構築し自動化しました。 ·     kintone や基幹システムのデータを AWS 上に自動連携 ·     毎日約2時間かけて手作業で作成していた見込シートを、ボタンひとつで 5 秒で自動生成 ·     気象情報も自動取得し、予測の参考データとして活用可能に 「担当者様へのヒアリングを何度も実施し、複雑なデータの流れを完全に理解した上で AWS 上に再現しました。担当者様がスムーズに移行できるよう、出力は既存の見込シートとできるだけ同じ見た目になるよう配慮しています」と Hashup 様は構築時のこだわりを語ります。 ② AI 需要予測：Amazon SageMaker Canvas による時系列予測モデル Amazon SageMaker Canvas の AutoML 機能を活用し、時系列予測モデルを構築しました。 ·       学習データ : 過去 2 年半の出荷実績データに、気温（代表 6 地点の平均最高・最低気温）、販促情報、前週トレンドなどを説明変数として投入 ·       予測対象 : チルドまん各商品の翌日出荷数 ·       モデル構築 : AutoML によりハイパーパラメータ最適化を自動実行し、最もパフォーマンスの高いモデルを自動選択 ·       有効因子 : 日本の祝日（SageMaker が自動付与）、気温、小売見込、前日計、前週トレンドなどが予測に寄与 導入効果 AI 需要予測システムのPOC実施により、以下の顕著な効果が得られました。 ·       業務工数 90% 削減 : 毎日約2時間を要していた予測業務のデータ抽出・前処理・予測・結果出力を自動化し、手作業をほぼゼロに ·       熟練担当者と同等以上の予測精度を実現 : あんまん: AI 6.0% vs 担当者 6.2%（WAPE）— AI が同等 ゴールド肉まん: AI 9.8% vs 担当者 15.4%（WAPE）— AI が大幅に上回る ·       属人化からの脱却： 特定担当者の経験・勘に依存しない、再現性のある予測プロセスを確立 ·       外部データの活用： 従来取り入れられていなかった気象データを予測に組み込み、精度向上に貢献 「Amazon SageMaker Canvas の AutoML 機能により、機械学習の専門知識がなくても高精度な時系列予測モデルを構築できました。また、AWS 上にデータレイクを構築したことで、これまで散在していたデータが一元化され、AI 予測だけでなく今後のデータ活用基盤としても機能しています」と井村屋グループ様は技術面でのメリットを説明します。 Hashup 様は「井村屋グループ様のデジタル戦略室の皆様に多大なるご協力をいただき、担当者様への丁寧なヒアリングを重ねることで、長年培われてきた”秘伝のたれ”とも言える業務ノウハウを AWS 上に忠実に再現できました。AWS のマネージドサービスを活用することで、2025 年 11 月の開始からわずか約 4 ヶ月で概念実証を完了できたことも大きな成果です」とプロジェクトを振り返ります。 AWS Summitと同日に幕張メッセ併設の国際会議場で開催されたプライベートセッション「AI Leaders Session」ご登壇時の様子（井村屋グループ株式会社 執行役員常務 デジタル戦略室長 岡田孝平様） 今後の展望 「2026 年 秋冬のチルドまんシーズンに向けて、業務自動化から AI 需要予測までの一気通貫システムへの完全移行を目指しています。さらに、kintone の特売見込み情報と連携した長期の出荷予測を実現し、原材料発注計画の AI 予測・自動化にも取り組んでいきます。他カテゴリへの AI 予測の展開も計画しています」 また、今回のプロジェクトを通じて AWS 上のデータレイクに蓄積された販売実績・気象・販促などの多様なデータを、需要予測だけでなく経営判断や現場のアクションにも活かしていくため、 Amazon Quick の活用もご検討いただいています。AI が生成した予測値と実績の乖離をダッシュボードでリアルタイムに可視化することで、予測精度のモニタリングや、需要変動の要因分析をより直感的に行える環境の構築を目指しています。 株式会社Hashup 代表取締役 CEO 神野 悦太郎様（左端） 井村屋グループ株式会社 執行役員常務 デジタル戦略室長 岡田孝平様（左から二番目） Amazon Web Services Japan : アカウントマネージャー 藤川 高志朗（右から二番目）、ソリューションアーキテクト 古屋 楓（右端）

本文は 2026年6月26日 に公開された AWS Cloud WAN Routing Policy: Real-World Global Network Scenarios (Part 2) を翻訳したものです。 Part 1 では、 AWS Cloud WAN のルーティングポリシーを紹介し、グローバルネットワーク全体でルート伝播とパス選択に影響を与えるためのきめ細かな制御をどのように使用できるかを示しました。各ルーティングポリシーは、3つの主要コンポーネントで構成されます。1) マッチ条件：ルートプレフィックスまたは BGP 属性を評価します。2) アクション：マッチしたルートの処理方法を決定します。3) 方向性：ポリシーをインバウンドとアウトバウンドのどちらのルート伝播に適用するかを指定します。これらの構成要素は、アタッチメント、セグメント、またはリージョンのレベルで適用できます。 本記事では、これらの概念を踏まえ、ハイブリッド環境やマルチサイト環境で一般的に見られる3つの実運用シナリオを取り上げます。AWS Cloud WAN のルーティングポリシーを使用して、 AWS Transit Gateway 環境からの移行中にルーティングを制御する方法、ローカルプリファレンスを使用して複数の AWS Direct Connect ロケーション間のパス選択を改善する方法、そして同一の BGP 自律システム番号（ASN）を持つネットワーク間の接続を許可する方法を学びます。 これらのパターンは、AWS Cloud WAN を集中型のポリシー適用ポイントとして使用し、グローバルネットワーク全体のルーティング制御を簡素化する方法を示しています。 本記事で説明するシナリオは、網羅的なリストではありません。AWS Cloud WAN のルーティングポリシーは、ここで扱う以外にも追加のマッチ条件とアクションをサポートしているため、お客様の環境固有のルーティング課題に対応できます。利用可能なマッチ条件とアクションの完全なリストについては、 AWS Cloud WAN ルーティングポリシーのドキュメント を参照してください。 前提条件 本記事は、2部構成のシリーズの第2回です。マッチ条件、アクション、方向性、基本的な設定ワークフローなど、ルーティングポリシーの基礎を扱った Part 1: AWS Cloud WAN Routing Policy — Fine-grained controls for your global network を既に読まれていることを前提とします。また、 Amazon Virtual Private Cloud（Amazon VPC） 、AWS Cloud WAN、AWS Direct Connect、 AWS Site-to-Site VPN などの主要な AWS ネットワークサービス、および AS-path、ローカルプリファレンス、コミュニティ属性といった概念を含む Border Gateway Protocol（BGP） の基礎を理解していることを前提とします。AWS Cloud WAN のハイブリッド接続パターンに関する補足的な背景情報については、 Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration を参照することを推奨します。 補足：AWS Cloud WAN のルーティングポリシーには、コアネットワークポリシーバージョン 2025.11 以降が必要です。本記事で説明する設定を実装する前に、コアネットワークがこのバージョンで動作していることを確認してください。 シナリオ1：既存の Transit Gateway 環境からのルート伝播の制御 AWS Cloud WAN を採用する場合、既に AWS Transit Gateway 上に構築された既存環境を運用しているかもしれません。移行中は、これらの環境を AWS Cloud WAN に接続することで、一度きりのカットオーバーではなく、段階的な移行が可能になります。 こうしたアーキテクチャでよくある要件は、AWS Cloud WAN が Transit Gateway から学習したルートを、ネットワークの他の部分、特に AWS Direct Connect や AWS Site-to-Site VPN を通じて接続されたオンプレミス環境にどのように伝播するかを制御することです。 次の図（図1）は、ルーティングポリシーが適用されていない場合に、AWS Cloud WAN 内でルートがどのように学習され、伝播されるかを示しています。この例では、ap-southeast-2 リージョンの Transit Gateway が、AWS Direct Connect を通じてオンプレミスのデータセンター（DC1）に接続されています。この Transit Gateway が AWS Cloud WAN にアタッチされると、DC1 は重複したルートを受信し始めます。1つ目のルートセットは、Transit Gateway から直接伝播されます。2つ目のセットは AWS Cloud WAN 自体から来るもので、AWS Cloud WAN は Transit Gateway ルートテーブルのアタッチメントから同じルートを学習し、それらを Direct Connect 経由で DC1 に再配布します。ルーティングポリシーがない場合、このルートの重複は、非効率的または予測不可能なルーティング動作につながる可能性があります。 図1：ルーティングポリシーがない場合のルート伝播動作 AWS Cloud WAN のルーティングポリシーは、BGP コミュニティのタグ付けとフィルタリングによってこの問題を解決し、どのルートをオンプレミス環境にアドバタイズするかを正確に制御できるようにします。 図2：ルーティングポリシー適用後のルート伝播動作 図2に示すように、Transit Gateway は自身の production ルートテーブルを AWS Cloud WAN の production セグメントに接続します。ルーティングポリシーは2つのステップで動作します。第1に、Transit Gateway ルートテーブルのアタッチメントから学習したルートに、BGP コミュニティ値（65000:1 など）をタグ付けします。第2に、このコミュニティタグを、production セグメントから hybrid セグメントへルートを共有する際のフィルタとして使用します。タグ付けされたルートは、hybrid セグメントの Direct Connect ゲートウェイ（DXGW）へはそれ以上アドバタイズ（伝播）されません。 その結果、オンプレミスのデータセンターは Transit Gateway から直接ルートのみを受信することになり、重複したアドバタイズが排除され、Transit Gateway が同じデータセンターに接続されたままのアーキテクチャにおけるルーティングの競合を回避できます。 補足：AWS Cloud WAN に直接アタッチされた新しい VPC は、Transit Gateway の背後にある既存の VPC が AWS Cloud WAN 上の VPC と通信できるように、自身の Classless Inter-Domain Routing（CIDR）ブロックを Transit Gateway にアドバタイズします。ただし、これらの CIDR ブロックは、その関連付けの 許可プレフィックスリスト に含まれていない限り、Transit Gateway の Direct Connect ゲートウェイの関連付けを通じてオンプレミスにはアドバタイズされません。これにより、Cloud WAN の VPC ルートが Transit Gateway パス経由で DC1 にアドバタイズされるのを防ぎ、AWS Cloud WAN の Direct Connect ゲートウェイをオンプレミスへの唯一のパスとして残します。 仕組み 既存の Transit Gateway から学習したルートは production セグメントに入り、アタッチメントのインバウンドポリシーによってコミュニティ 65000:1 でタグ付けされます。production の VPC と AWS Cloud WAN のリソースは、Transit Gateway のワークロードに通常どおり到達できます。一方、production のルートが hybrid セグメントと共有される際、アウトバウンドのセグメントフィルタリングポリシーがコミュニティタグ 65000:1 にマッチし、それらのルートをドロップします。その他すべての production ルート（VPC からのルート）は hybrid セグメントに通過し、Direct Connect 経由でオンプレミスにアドバタイズされます。これにより、同じ Transit Gateway に依然として直接接続されているデータセンターへの重複したルートアドバタイズを防ぎます。 ステップ1：Transit Gateway のルートにコミュニティをタグ付けする（Transit Gateway ルートテーブルアタッチメントでインバウンド） このインバウンドポリシーを、AWS Cloud WAN の Transit Gateway ルートテーブルアタッチメントに適用します。このポリシーは、Transit Gateway から学習したすべてのルートにマッチし、コミュニティ 65000:1 でタグ付けします。 { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "tagTgwRoutes", "routing-policy-description": "Tag routes learned from existing TGW with community 65000:1", "routing-policy-direction": "inbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "prefix-in-cidr", "value": "0.0.0.0/0" } ], "condition-logic": "and", "action": { "type": "add-community", "value": "65000:1" } } } ] } ] } ステップ2：セグメント共有時にタグ付けされたルートをフィルタリングする（prod → hybrid） このアウトバウンドポリシーを、production セグメントから hybrid セグメントへルートを共有する際に適用します。このポリシーは、コミュニティ 65000:1 を持つルートにマッチしてドロップし、Transit Gateway 由来のルートが hybrid セグメントおよび Direct Connect 経由でオンプレミスの DC に伝播されるのを防ぎます。コミュニティ値 65000:1 にマッチしないルートは暗黙的に許可され、通常どおり伝播を続けます。AWS Cloud WAN のルーティングポリシールールはデフォルト許可（default-allow）を基本として動作し、ドロップルールによって明示的にマッチしたルートのみがフィルタリングされます。 { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "filterRoutesToHybrid", "routing-policy-description": "Drop TGW-originated routes (community 65000:1) when sharing prod to hybrid", "routing-policy-direction": "outbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "community-in-list", "value": "65000:1" } ], "condition-logic": "and", "action": { "type": "drop" } } } ] } ] } ステップ3：ポリシーを配布ポイントに関連付ける 3.1 ルーティングポリシーラベルを使用して、タグ付けポリシーを Transit Gateway ルートテーブルアタッチメントに適用します。 { "attachment-routing-policy-rules": [ { "rule-number": 100, "conditions": [ { "type": "routing-policy-label", "value": "TgwInbound" } ], "action": { "associate-routing-policies": [ "tagTgwRoutes" ] } } ] } 関連付けを完了するには、routing-policy-label を Transit Gateway ルートテーブルアタッチメントに割り当てます。これは、アタッチメントの作成時に routing-policy-label パラメータを使用するか、AWS Cloud WAN コンソールで既存のアタッチメントを編集することで実行できます。このシナリオでは、ラベル TgwInbound を Transit Gateway ルートテーブルアタッチメントに割り当てます。 3.2 セグメント共有のレベルでフィルタリングポリシーを適用します。 { "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "production", "share-with": [ "hybrid" ], "routing-policy-names": [ "filterRoutesToHybrid" ] } ] } シナリオ2：複数の Direct Connect ロケーション間でのパス選択の改善 複数のオンプレミスロケーションがある場合、耐障害性のために複数のサイトから同じプレフィックスをアドバタイズしていることが多いでしょう。これは可用性を向上させますが、AWS Cloud WAN が複数のロケーションから固有の優先度なしに同一のルートを受信するというルーティングの曖昧さを生み出します。追加の制御がなければ、トラフィックが適切に誘導されない場合に非効率的なルーティング決定につながる可能性があります。 ルーティングポリシーが適用されていない場合、AWS Cloud WAN はデフォルトのルーティング動作（ロンゲストプレフィックスマッチ）に依存し、ローカルプリファレンスやパスステアリングは行われません。図3に示すように、AWS Cloud WAN が同じプレフィックス（例えば DC2 から発信される 10.2.0.0/16）を3つの DXGW とサイトすべてから同時に学習する場合、DC2 を通る直接パスを優先するメカニズムがありません。その結果、DC2 宛てのトラフィックが代わりに DC1 や DC3 を経由して出ていくことがあり、不要なバックボーンの通過、レイテンシーの増加、コストの増加を招きます。 補足：このシナリオでは、オンプレミスのデータセンターが MPLS や AWS Direct Connect SiteLink などのバックボーンネットワークを通じて相互接続されており、フェイルオーバー時にサイト間でトラフィックを通過させられることを前提としています。 図3：ルーティングポリシーがない場合のルートパス選択 AWS Cloud WAN のルーティングポリシーは、ローカルプリファレンスなどの BGP 属性を使用して、パス選択を集中的に制御します。図4に示すように、各 DXGW アタッチメントに適用されたインバウンドルーティングポリシーがローカルプリファレンス値を割り当て、トラフィックを発信元のデータセンターへ誘導することで、最も直接的なパスが優先されるようにします。 図4：ルーティングポリシー適用後のルートパス選択 このシナリオでは、各データセンターが特定のプレフィックスのセットを保有しています。DC1 は 10.1.0.0/16 を、DC2 は 10.2.0.0/16 を、DC3 は 10.3.0.0/16 を発信します。耐障害性のため、3つの DC はいずれも、自身の Direct Connect ロケーションから3つすべてのプレフィックスをアドバタイズします。各 DC は専用の DXGW を通じて接続されており、DC1 は ASN 65010、DC2 は 65011、DC3 は 65012 を使用します。AWS Cloud WAN は3つの DXGW すべてから同じルートを学習し、ローカルプリファレンスを使用して各プレフィックスのトラフィックをその保有元 DC へ誘導します。他の DC は、セカンダリおよび第3（ターシャリ）のフェイルオーバーパスとして機能します。 AWS Cloud WAN の観点から見ると、このシナリオのパス優先度マトリックスは次のとおりです。 プレフィックス 1番目（ローカルプリファレンス 300） 2番目（LP 200） 3番目（LP 100） DC1: 10.1.0.0/16 DXGW 65010 DXGW 65011 DXGW 65012 DC2: 10.2.0.0/16 DXGW 65011 DXGW 65012 DXGW 65010 DC3: 10.3.0.0/16 DXGW 65012 DXGW 65011 DXGW 65010 仕組み 3つの DC はいずれも耐障害性のために3つすべてのプレフィックスをアドバタイズしますが、各プレフィックスは特定の DC に属します。AWS Cloud WAN が 10.1.0.0/16 を3つの DXGW すべてから学習すると、ルーティングポリシーは、DXGW 65010（保有元である DC1）から 300、DXGW 65011（DC2）から 200、DXGW 65012（DC3）から 100 のローカルプリファレンスを割り当てます。AWS Cloud WAN は最も高いローカルプリファレンスを持つパスを選択し、10.1.0.0/16 のトラフィックを DC1 経由で誘導します。DC1 の Direct Connect パスに障害が発生した場合、トラフィックは自動的に DC2（ローカルプリファレンス 200）、次いで DC3（ローカルプリファレンス 100）へフォールバックします。同じロジックが、DC2 保有のプレフィックス（プライマリは DXGW 65011、セカンダリは 65012、第3経路は 65010 経由）および DC3 保有のプレフィックス（プライマリは DXGW 65012、セカンダリは 65011、第3経路は 65010 経由）にも適用されます。 DXGW のレベルでは、VIF 上の BGP コミュニティ を通じて、追加のパス制御レイヤーが利用できます。各 DXGW にはプライマリとセカンダリの2つの VIF があり、コミュニティタグによってアウトバウンドトラフィックにどちらの VIF が優先されるかが決まります。高優先度には 7224:7300、低優先度には 7224:7100 を使用します。あるいは、アクティブ・アクティブの ECMP ロードバランシングのために、両方の VIF に 7224:7200 を適用することもできます。 この設定により、AWS Cloud WAN と DXGW は、インバウンドのルート優先設定を使用してアウトバウンドトラフィックをオンプレミスへ誘導します。対称ルーティングを実現するには、オンプレミスから AWS へ流れるトラフィックについても、オンプレミスのデバイスが同じパスを優先するように設定する必要があります。 補足：定義された3つのプレフィックスリストのいずれにもマッチしないプレフィックスは、明示的なローカルプリファレンスが設定されないまま通過し、3つの DXGW すべてにわたって非決定的なパス選択となります。オンプレミスから新しいプレフィックスがアドバタイズされるのに合わせて、プレフィックスリストを最新の状態に保つようにしてください。 ステップ1：各データセンター用のプレフィックスリストを定義する データセンターごとに個別のプレフィックスリストを作成し、そのサイトから発信される CIDR をグループ化します。プレフィックスリストは Amazon VPC マネージドプレフィックスリスト（カスタマーマネージドプレフィックスリスト）として作成され、その後プレフィックスリストエイリアスを使用してコアネットワークに関連付けられます。ルーティングポリシーがプレフィックスをマッチする際に参照するのは、このエイリアスです。例えば、10.1.0.0/16、10.2.0.0/16、10.3.0.0/16 をそれぞれ含む3つの マネージドプレフィックスリスト を作成し、エイリアス dc1Prefixes、dc2Prefixes、dc3Prefixes を使用してコアネットワークに関連付けます。 補足：–max-entries パラメータは必須で、プレフィックスリストが保持できるエントリの最大数を定義します。ここで使用している値 5 は任意のものであり、含める予定のプレフィックス数に応じて調整できます。 aws ec2 create-managed-prefix-list --prefix-list-name dc1Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.1.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc2Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.2.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc3Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.3.0.0/16 aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc1-prefix-list-arn> --prefix-list-alias dc1Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc2-prefix-list-arn> --prefix-list-alias dc2Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc3-prefix-list-arn> --prefix-list-alias dc3Prefixes ステップ2：DXGW アタッチメントごとにルーティングポリシーを定義する 各 DXGW は、それぞれ独自のインバウンドルーティングポリシーを持ちます。このポリシーは、パス優先度マトリックスに基づいて各プレフィックスにローカルプリファレンス値を割り当て、各プレフィックスを発信元 DC へ、決定的なフェイルオーバー順序で誘導します。 DXGW 65010（DC1）のポリシー。DC1 のプライマリ、DC2 と DC3 の第3経路： { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "pathPreferenceDxgw65010", "routing-policy-description": "DXGW 65010 (DC1): primary for DC1, tertiary for DC2, tertiary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}} ] } ] } DXGW 65011（DC2）のポリシー。DC2 のプライマリ、DC1 と DC3 のセカンダリ： { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "pathPreferenceDxgw65011", "routing-policy-description": "DXGW 65011 (DC2): secondary for DC1, primary for DC2, secondary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}} ] } ] } DXGW 65012（DC3）のポリシー。DC3 のプライマリ、DC2 のセカンダリ、DC1 の第3経路： { "routing-policies": [ { "routing-policy-number": 300, "routing-policy-name": "pathPreferenceDxgw65012", "routing-policy-description": "DXGW 65012 (DC3): tertiary for DC1, secondary for DC2, primary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}} ] } ] } ステップ3：ポリシーを DXGW アタッチメントに関連付ける 各ルーティングポリシーを routing-policy-label にマッピングし、次にラベルによってアタッチメントをマッチし、対応するルーティングポリシーを関連付ける attachment-routing-policy-rules を定義します。routing-policy-label を各アタッチメントに割り当てます。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dxgw65010inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65010"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dxgw65011inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65011"]}}, {"rule-number": 300, "conditions": [{"type": "routing-policy-label", "value": "dxgw65012inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65012"]}} ] } 次に、routing-policy-label パラメータまたはコンソールを使用して、対応する routing-policy-label を各 DXGW アタッチメントに適用します。このシナリオでは、ラベル dxgw65010inbound を DXGW 65010 アタッチメントに、dxgw65011inbound を DXGW 65011 アタッチメントに、dxgw65012inbound を DXGW 65012 アタッチメントに割り当てます。 シナリオ3：同一 ASN を持つネットワーク間の通信の許可 Wide Area Network（WAN）を構築する企業は、グローバル接続のために AWS のバックボーンインフラストラクチャをますます活用していますが、買収、有機的な成長、または一般的なデフォルト ASN 値を使用したマルチサイト展開などにより、プライベート ASN の重複に直面することがよくあります。複数のサイトが同一の ASN を使用している場合、BGP のループ防止機能が、AS-path にそのサイト自身の ASN を含むルートを拒否し、WAN 全体のエンドツーエンドの通信を妨げます。 このシナリオでは、2つの ASN の競合がエンドツーエンドの通信を妨げています。図5に示すように、DC1 と DC2（A）はどちらも ASN 65000 を使用しています。AWS Cloud WAN がそれらの間でルートを伝播すると、各サイトは AS-path に自身の ASN を検出するため、相手のルートを拒否します。これが BGP のループ防止機能を引き起こします。 図5：DC1 と DC2 間で BGP ループ防止機能を引き起こす ASN の競合 2つ目の競合（B）は、図6に示すように、ASN 64512 を使用する DC3 が、ap-southeast-2 の AWS Cloud WAN コアネットワークエッジ（CNE）の ASN と競合するというものです。これにより、DC3 のルートは ap-southeast-2 の CNE によってドロップされ、DC3 もその CNE からのルートをドロップします。 図6：DC3 と AWS Cloud WAN CNE 間の ASN の競合によるルート伝播のブロック これら2つの競合が組み合わさることで、3つのデータセンターすべてにわたって到達性が完全に失われる結果となります。 AWS Cloud WAN のルーティングポリシーは、replace-asn-list アクションによってこの問題に対処します。このアクションは、AS-path 全体を指定した ASN のセットで置き換え、ループ防止機能を引き起こす競合を取り除き、オンプレミスの BGP の番号を振り直すことなく接続を復元します。 図7に示すように、3つのデータセンターは AWS Cloud WAN を中央のグローバルバックボーンとして使用します。DC1 は ap-southeast-2 リージョンの Direct Connect を通じて接続し、DC2 は us-west-2 リージョンの Site-to-Site VPN を通じて接続し、DC3 はメトロファイバー経由で DC2 を通じて AWS Cloud WAN に到達します。インバウンドルーティングポリシーは、2つのアタッチメントポイントに適用されます。(1) DC1 用の Direct Connect ゲートウェイアタッチメント、および (2) DC2 用の VPN アタッチメントです。DC3 のルートは DC2 の VPN アタッチメントを経由して通過するため、そのアタッチメントのインバウンドポリシーが DC2 と DC3 の両方の ASN 置換を処理します。 図7：3つのデータセンターすべての接続を復元する ASN 置換ルーティングポリシー 次の表は、ASN の置換をまとめたものです。 ソース 元の ASN 置換後の ASN 理由 DC1（Direct Connect） 65000 65550 DC2 でのループ検出を回避 DC2（Site-to-Site VPN） 65000 65551 DC1 でのループ検出を回避 DC3（DC2 のメトロファイバー経由） 64512 65552 ap-southeast-2 の CNE ASN との競合を回避 重要：AWS Cloud WAN のコアネットワークエッジ（CNE）は、インバウンドルーティングポリシーが評価される前に、BGP AS-path のループ検出を実行します。CNE が自身の ASN と一致する ASN を持つルートを受信した場合、replace-asn-list アクションが実行される前にそのルートをドロップします。トポロジーを計画する際は、オンプレミスのルートが、受信側の CNE の ASN と一致する ASN を持たないようにしてください。 仕組み このアプローチは、各サイトに固有で競合しない置換 ASN を割り当てることで、どのサイトも伝播されたルートの中に自身の ASN を見ることがなく、また、どのルートもトポロジー内の CNE と競合する ASN を持たないようにするものです。DC1 が AWS Cloud WAN にルートをアドバタイズすると、Direct Connect ゲートウェイアタッチメントのインバウンドポリシーが、AS-path 全体を ASN 65550 で置き換えます。これらのルートは AWS Cloud WAN を通じて伝播し、AS-path に 65000 ではなく 65550 を含んだ状態で DC2 に到達するため、DC2 のルーターはループ検出を引き起こすことなくそれらを受け入れます。 DC2 がルートをアドバタイズすると、VPN アタッチメントのインバウンドポリシーが AS-path 全体を ASN 65551 で置き換えます。これにより DC1 は、AS-path に 65000 ではなく 65551 を含んだ状態でこれらのルートを受信するため、BGP のループ検出を防ぎ、DC1 と DC2 間の双方向通信を復元します。 DC3 については、ルートは ASN 64512（DC3）と ASN 65000（DC2）の両方を持った状態で、DC2 の VPN アタッチメントを通じて AWS Cloud WAN に入ります。インバウンドポリシーは AS-path 全体を単一の専用 ASN（65552）で置き換え、競合する2つの値を1回の操作で取り除きます。これにより、DC3 のプレフィックスが AWS Cloud WAN のルートテーブルに受け入れられ、DC1 およびクラウドリソースにアドバタイズされるようになります。 すべての置換 ASN（65550、65551、65552）は、コアネットワークエッジ用に設定された ASN 範囲の外から選択されています。ルーティングポリシーの置換値は、AWS Cloud WAN の CNE の ASN 範囲と重複できないためです。 ステップ1：DC1 の Direct Connect ゲートウェイアタッチメントにインバウンドポリシーを定義する このポリシーは、DC1 から到着する AS-path に ASN 65000 を含むルートにマッチし、それを 65550 に置き換えます。これらのルートが DC2 に伝播されるとき、AS-path には 65000 が含まれなくなるため、DC2 のルーターはそれらを受け入れます。 { "routing-policies": [ { "routing-policy-name": "replaceasndc1", "routing-policy-description": "Replace ASN 65000 from DC1 with 65550 to avoid loop detection at DC2", "routing-policy-direction": "inbound", "routing-policy-number": 100, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65550]}}} ] } ] } ステップ2：DC2 の VPN アタッチメントにインバウンドポリシーを定義する このポリシーは、2つのルーティングルールを使用して ASN の競合を解決します。 ルール10 ：DC3 の ASN（64512）を 65552 に置き換えます。 ルール20 ：DC2 の ASN（65000）を 65551 に置き換えます。 DC3 からのルートは DC2 を経由して通過するため、AS-path に両方の ASN を含みます。そのため、順序が重要です。replace-asn-list は AS-path 全体を上書きするため、DC3 のルートが専用の置換 ASN（65552）を受け取れるように、ルール10 を先に実行する必要があります。 もしルール20 が先に実行されると、DC2 の ASN にマッチして AS-path 全体を 65551 で置き換えてしまいます。DC3 のルートは依然として受け入れられ、接続は機能しますが、DC2 のルートと区別がつかなくなり、ルートの追跡やトラブルシューティングが難しくなります。 { "routing-policies": [ { "routing-policy-name": "replaceasndc2", "routing-policy-description": "Replace ASN 65000 from DC2 with 65551 and ASN 64512 from DC3 with 65552", "routing-policy-direction": "inbound", "routing-policy-number": 200, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 64512}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65552]}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65551]}}} ] } ] } ステップ3：ポリシーをアタッチメントに関連付ける routing-policy-label にマッチする attachment-routing-policy-rules を定義することで、各ルーティングポリシーをアタッチメントに関連付けます。routing-policy-label パラメータまたはコンソールを使用して、各アタッチメントに指定の routing-policy-label をタグ付けします。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dc1inbound"}], "action": {"associate-routing-policies": ["replaceasndc1"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dc2inbound"}], "action": {"associate-routing-policies": ["replaceasndc2"]}} ] } 最後に、routing-policy-label パラメータまたはコンソールを使用して、各アタッチメントに指定の routing-policy-label をタグ付けします。このシナリオでは、ラベル dc1inbound を DC1 の Direct Connect ゲートウェイアタッチメントに、dc2inbound を DC2 の VPN アタッチメントに割り当てます。 知っておくべきこと AWS Cloud WAN への Direct Connect ゲートウェイアタッチメントを作成する際、DXGW が接続する CNE を選択できます。各 CNE は自身のローカルリージョンの VPC ルートのみを DXGW にアドバタイズするため、関連付けを制限する特別な理由がない限り、シナリオ2に示すようにすべての CNE を選択することを推奨します。 IPv6 がサポートされています。同じマッチ条件、アクション、ポリシー構造が IPv6 プレフィックスにも適用されます（ワイルドカードマッチとして ::/0 を使用）。本記事で説明したすべてのシナリオにおいて、IPv6 のルート伝播に同一のルーティングポリシーパターンを適用できます。 シナリオ2に示すように複数の Direct Connect ゲートウェイをデプロイすると、単一の Direct Connect ゲートウェイ（DXGW）を使用する場合よりも、きめ細かなルーティング制御が可能になります。AWS Cloud WAN のルーティングポリシーは、VIF や DXGW のレベルで利用できるものよりも幅広い BGP 属性の制御を提供します。オンプレミス接続を複数の DXGW に分散させることで、ルーティングの決定を AWS Cloud WAN に移し、トラフィックエンジニアリングのためのより豊富なポリシー制御を利用できるようになります。 ルーティングポリシー内のルールは、rule-number の順に評価されます。評価を停止する終端アクションは drop と allow のみです。replace-asn-list、set-local-preference、add-community などのその他のアクションは非終端であり、評価は残りのルールへと続き、各変更が引き継がれていきます。replace-asn-list アクションは、個々の ASN を置換するのではなく、AS-path 全体を上書きします。その結果、先のルールによって変更されたルートは、後のルールがマッチするための元の ASN をもはや持ちません。シナリオ3の DC2 を経由する DC3 のルートのように、ルートが複数の ASN を持ちうる場合は、最も具体的なマッチが最初に適用されるようにルールを順序付けてください。 AWS Cloud WAN は、CNE ごとに BGP AS-path のループ検出を実行し、このチェックはインバウンドルーティングポリシーが適用される前に実行されます。受信ルートの AS-path に、そのアタッチメントが接続する CNE の ASN が含まれている場合、replace-asn-list ポリシーが変更を加える前にそのルートは拒否されます（詳細な例についてはシナリオ3を参照してください）。 クリーンアップ 本記事で説明したルーティングポリシーは、AWS Cloud WAN のコアネットワークポリシードキュメント内で定義されるものであり、単独で課金対象となるリソースを作成することはありません。これらの設定を削除するには、次の手順を実行します。 AWS Cloud WAN コンソールでアタッチメントを編集するか、AWS CLI を使用して、各アタッチメントから routing-policy-label を削除します。 ポリシーを参照している attachment-routing-policy-rules と、すべての segment-actions を削除します。 コアネットワークポリシーの routing-policies セクションから、ルーティングポリシーの定義（tagTgwRoutes、filterRoutesToHybrid、pathPreferenceDxgw*、replaceasn*）を削除します。 変更を適用するために、コアネットワークポリシーのバージョン更新を送信します。 シナリオ2でマネージドプレフィックスリストを作成し、それらが不要になった場合は、AWS CLI または AWS マネジメントコンソールを使用して削除します。 まとめ 本記事では、AWS Cloud WAN のルーティングポリシーが、ハイブリッド環境やマルチサイト環境における一般的なルーティングの課題をどのように解決できるかを示す、3つの実運用シナリオを取り上げました。コミュニティのタグ付けとフィルタリングを使用して Transit Gateway 環境からのルート伝播を制御する方法、ローカルプリファレンスを使用して複数の DXGW と Direct Connect ロケーション間のパス選択を改善する方法、そして AS-path の置換を使用して BGP の ASN の競合を解決する方法を紹介しました。ルーティングポリシー設定の基礎を扱った Part 1 と合わせて、これらのシナリオは、AWS Cloud WAN をグローバルネットワークの統合的なルーティング制御レイヤーとしてどのように使用できるかを示しています。始めるには、 AWS Cloud WAN のドキュメント を参照してください。 著者について Jordan Rojas Garcia Jordan は、AWS の Worldwide Specialist Organization に所属するシニアネットワークスペシャリストソリューションアーキテクトです。従来型のデータセンターネットワークの分野でキャリアをスタートし、2018年に AWS に入社しました。AWS では、クラウドネットワーキングソリューションの設計に注力し、AWS クラウドでネットワークを構築するためのガイダンスとベストプラクティスを提供しています。仕事以外では、旅行、新しい料理の開拓、ハイキングを楽しみ、二輪車と四輪車の運転への情熱を燃やしています。 Akeef Khan Akeef Khan は、オーストラリアのシドニーを拠点とする Amazon Web Services のソリューションアーキテクトです。Cross-Industries セグメントのお客様を担当し、小売業や QSR（クイックサービスレストラン）の組織が AWS を採用、運用、スケールできるよう支援しています。彼の専門分野はネットワーキングであり、AWS のサービスを使ってお客様のグローバルなネットワーク接続をシンプルにすることに情熱を注いでいます。仕事以外では、新しいテクノロジーの探求と継続的な学習を楽しんでいます。 翻訳は Solutions Architect の田村 大地が担当しました。原文は こちら です。

本記事は 2026 年 7 月 2 日に公開された Ranjith Ramakrishnan による “ Set a cap on overage spend, or pre-pay for it ” を翻訳したものです。 現在 Kiro で超過利用 (overage) をしている場合、いくら使ったかがわかるのは、すでに使い切ってしまった後です。ヘビーな利用の結果は翌月の請求書に金額として現れ、その時点ではもう支払うしかありません。チームで Kiro をご利用のお客様からは、自分たちでコントロールできる上限が欲しいという声を聞いてきました。個人開発者からは、予測できない請求書を受け取るくらいなら前払いしたいという声を聞いてきました。 チーム向け: Service Quotas コンソールから超過利用に上限を設定する 2026 年 7 月 2 日より、チームが AWS IAM Identity Center または外部 ID プロバイダーで Kiro にサインインしている場合、AWS Service Quotas コンソールで超過利用の上限設定が利用可能になりました。Service Quotas コンソールを開き、サービス一覧から Kiro を選択し、アカウントレベルで上限の引き上げをリクエストします。上限が設定されると、そのアカウントでサブスクライブしているすべてのユーザーに適用されます。 上限の最大値は、アカウントの利用履歴や状態に応じて自動的に調整されます。自動で設定される上限よりも高くしたい場合は、同じコンソールから追加の引き上げをリクエストしてください。 この仕組みにより、AWS 管理者がすでにクォータを管理している場所に上限が置かれるため、別途確認する場所も、新しく覚えるべき権限モデルもありません。 個人開発者向け: クレジットパックによる前払い GitHub、Google、または AWS Builder ID でサインインし、有料プラン (Kiro Pro、Pro+、Pro Max、または Power) を利用している場合、 アドオンクレジットを購入 して、プランの上限を超えて Kiro を使い続けられるようになりました。 アカウントページ にアクセスし、クレジットパック (最小 5 ドルから) を購入すれば、あとは通常どおり Kiro を使うだけで残高が自動的に消費されます。 後から請求される超過利用を積み上げるのではなく、いつでも確認できる残高に対して使っていく形になります。残高が少なくなってきたら、チャージするか、通常のサブスクリプションのクレジット上限がリセットされるまで待つかを、自分で決められます。クレジットはすでに支払い済みなので、請求書で驚かされることもありません。 支出をよりコントロールしやすく これらの機能が最も役立つのは、支出の予測が難しいことが実際にリスクとなるケースです。たとえば、どのメンバーでも利用量を押し上げられる共有のチームアカウントや、ヘビーな利用が続いた 1 か月分がそのまま想定外の請求として計上されてしまう個人の作業などです。利用量がプランの範囲内に十分収まっているなら、どちらの機能も使わないかもしれません。すでに両アップデートを ご利用いただけます 。 翻訳は Solutions Architect の吉村 が担当いたしました。

数回前の号で、スタートアップと仕事をすることがどれほど活力になるかについて書きました。2026 年 6 月 29 日週、それを改めて感じました。AWS スタートアップチームと数日過ごし、創業者たちが実際に解決しようとしている問題について語る話に耳を傾けたのです。私の心に残った話の 1 つは、眼科医療へのアクセスを拡大しているブラジルのヘルステック企業 EyeCare Health の創業者である Marco Negreiros 氏から聞いたものです。彼は驚くべき事実を明かしました。ブラジルの自治体の 70％ 以上には眼科医が一人もいないというのです。彼の対応策は、ほぼすべての人が既に持ち歩いているデバイス、つまりスマートフォンで視力検査機能を搭載することでした。これにより、基本的な視力検査を受けるために診療所の近くに住む必要がなくなりました。創業者があれほど大きなギャップを、これほど具体的な解決策に変えていく姿を見ることができるからこそ、私はこの分野が大好きなのです。 今週は、いくつかの主要なリリースについて詳しく見たあと、四半期ごとの AWS サービスの可用性アップデートを取り上げます。 2026 年 6 月 29 日週のリリース 6 月 29 日週の AWS ニュースブログで取り上げられた発表の一部を以下にご紹介します。 AWS Graviton5 プロセッサを搭載した Amazon EC2 C9g および C9gd インスタンス : これらは、Graviton4 ベースのインスタンスよりも最大 25% 優れたコンピューティングパフォーマンス、5 倍大きいキャッシュ容量、クラウド内のプロセッサインスタンスの中で最速のメモリ、ローカル NVMe ストレージオプション (C9gd) を実現します。 新しい AWS CloudFormation Express モード : AWS CloudFormation Express モードを使用すると、インフラストラクチャのデプロイを高速化できます。これにより、AI エージェントとデベロッパーは数秒でデプロイの確認を受け取り、より迅速に反復できます。すべての AWS 商用リージョンで追加費用なしでご利用いただけます。 Kubernetes バージョンロールバックを活用し、Amazon EKS クラスターを安心してアップグレード : Amazon EKS の Kubernetes バージョンロールバックにより、クラスターのアップグレードを 7 日以内にロールバックできます。この新機能は、アップグレードが失敗した場合のセーフティネットを提供し、クラスターの再構築を不要にします。これにより、Kubernetes のバージョンアップグレードがロールバック可能な、低リスクのオペレーションになります。 AWS Certificate Manager の ACME サポートによるパブリック TLS 証明書発行の自動化 : AWS Certificate Manager が ACME プロトコルをサポートするようになりました。これにより、広く採用されている標準ツールを使用して、パブリック TLS 証明書の発行と更新を自動化できます。 私が注目したいくつかのリリースや最新情報をいくつかご紹介します: Claude Sonnet 5 が AWS で利用可能 – Anthropicの最も高性能な Sonnet モデルは、コーディング、エージェント、そして日常のプロフェッショナルワークを大規模に処理するための一流のインテリジェンスを、Sonnet の価格で提供します。大規模なコードベースを効率的に探索し、ツールを正確に呼び出し、長時間におよぶエージェントタスクでも状態を保持します。詳細については、 AI ブログの記事 をご覧ください。 AI エージェント向け Amazon WorkSpaces が一般公開 : AI エージェントは、アプリケーションのモダナイズやカスタム統合を必要とせずに、マネージド WorkSpaces 環境を通じてデスクトップアプリケーションに安全にアクセスして操作できるようになりました。詳細については、 デスクトップとアプリケーションストリーミングのブログ記事 をご覧ください。 Amazon OpenSearch Service がログ分析用に最適化 : このリリースでは、ログ分析ワークロード専用に設計された新しいエンジンが導入されました。このエンジンは、OpenSearch が誇る全文検索機能を維持しながら、内部ベンチマークで最大 4 倍のコストパフォーマンスを実現します。チームは、集計と高精度なテキスト検索を 1 か所で行えるようになりました。詳細については、 ビッグデータブログの記事 をご覧ください。 Amazon SageMaker AI は、生成 AI 推論のスケールアウト時間を最大半分に短縮 : SageMaker Inference がコンテナイメージのキャッシュをサポートし、スケールアウトイベント中の生成 AI モデルのエンドツーエンドスケーリングが最大 2 倍高速になります。詳細については、 AI ブログの記事 をご覧ください。 Amazon CloudWatch はログクエリからのアラーム作成をサポート : ログクエリの結果に対して直接アラームを作成し、単一のワークフローでしきい値を設定できるようになり、中間ステップとしてメトリックスフィルターやカスタムメトリクスを事前に作成する必要がなくなりました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS サービス可用性アップデート AWS のサービスまたは機能の可用性が変化した場合、私たちは運用の中断を最小限に抑えるために、利用可能な代替案について AWS 製品ライフサイクル の変更に関するガイダンスをお客様に提供し、移行をサポートします。次のライフサイクル変更は、2026 年 6 月 30 日に更新されました。 メンテナンスフェーズへの移行 (2026 年 7 月 30 日以降、新規のお客様は利用できなくなります): Amazon Bedrock Agents (2023 年 11 月リリース) は Amazon Bedrock Agents Classic になりました Amazon Cognito Sync Amazon Kendra Amazon Q Business AWS Directory Service — Simple AD AWS IoT Device Defender — 検出 (2026 年 8 月 31 日以降、新規のお客様は機能にアクセスできなくなります) AWS Mainframe Modernization — セルフマネージドエクスペリエンス AWS マネジメントコンソール — myApplications AWS リソースグループ — グループライフサイクルイベント AWS Service Catalog — アプリケーションレジストリ AWS Systems Manager — アプリケーションマネージャー Amazon SageMaker AI の機能: A2I 、 Clarify 、 Debugger 、 GeoSpatial 、 Ground Truth 、 Mechanical Turk 、 Model Monitor 、Role Manager、Studio Lab サンセットフェーズに入るサービス: Amazon WorkSpaces – PCoIP Amazon WorkSpaces – Pool AWS Managed Services (AMS) Advanced AWS re:Post Private Amazon SageMaker AI – Profiler サポート終了間近のサービス (2026 年 6 月 30 日現在): Amazon Chime SDK — キャリアボイスフォーカス Amazon SageMaker AI – Ground Truth Plus 私たちは、可用性の変化がお客様の業務に影響を与える可能性があることを理解しています。具体的なガイダンスについては、関連するサービスドキュメントを参照するか、AWS サポートにお問い合わせください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Summit — AWS Summit は、クラウドや AI のコミュニティが一堂に会し、最新のテクノロジーを学び、探求するための無料のイベントです。カレンダー全体をご覧になって、2026 年後半にお近くで開催されるサミットを見つけてください。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの場合は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受け付けています。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 2026 年 7 月 6 日週のニュースは以上です。7 月 13 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

本ブログは 2026 年 7 月 7 日に公開された AWS Blog “ Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies ” を翻訳したものです。 Claude Fable 5 のように、サードパーティープロバイダーとのデータ共有を必要とするモデルの登場により、組織には データ保持 ポリシーを一元的に適用する方法が求められています。 Amazon Bedrock では、推論リクエストの完了後にプロンプトとモデル出力を保持するかどうかを制御できます。すべてのアカウントに保持設定を適用しつつ、選択したモデルが対応している場合にはプロジェクト単位でデータ保持をきめ細かく制御したい、というケースもあるでしょう。 本記事では、Amazon Bedrock のデータ保持モードの仕組み、保持を管理するために利用できるツール ( Amazon Bedrock Projects や サービスコントロールポリシー (SCP) など)、およびポリシー設定が正しく機能していることを検証する方法を説明します。 本記事では、以下の内容を取り上げます。 Amazon Bedrock のデータ保持モードの仕組みと、各モードがデータに対して何を意味するか 互換性のあるモデルで Amazon Bedrock Projects を使用して、保持要件が異なるワークロードを分離する方法 組織内の誰もデータ共有を有効にできないようにする SCP の作成とデプロイの方法 データ保持モードとクロスリージョン推論プロファイルの相互作用 設定が正しく機能していることを検証する方法 データ保持モードを理解する Amazon Bedrock では、アカウントのモード設定を通じてデータ保持を制御できます。この設定は、各推論リクエストの後にプロンプトと出力がどのように扱われるかを決定するものであり、コンプライアンス要件を評価するうえで理解しておくことが重要です。すべてのモデルがデータ保持やデータ共有を必要とするわけではなく、これらを必要としないモデルで Amazon Bedrock を引き続き利用することもできます。データ保持またはデータ共有を必要とするモデルの最新リストについては、「 Amazon Bedrock ドキュメント 」を参照してください。最終的には、コンプライアンス要件に合致するモデルを選択することはお客様の責任となります。 重要な注意事項 : 児童性的虐待コンテンツ (CSAM) の拡散を防止するため、Amazon Bedrock は自動化されたメカニズムを使用して、モデルの入力/出力に含まれる CSAM を特定します。モードが none の場合でも、フラグが付けられたコンテンツを保存および確認し、報告目的で CSAM に該当するかどうかを判断することがあります。 以下のモードによって、Amazon Bedrock がデータをどのように扱うかが決まります。 モード 動作 プロバイダーとのデータ共有 none ゼロデータ保持。プロンプトとレスポンスは処理後、直ちに破棄されます。 なし default モデルプロバイダーとデータは共有されません。一部のモデルでは、信頼と安全性のチェックのために最大 30 日間のデータ保持が必要になる場合があります。詳細は各モデルの利用条件を確認してください。このモードでは、本質的に保持を必要とする API (例: Batch API、store=true を指定した Responses API) も使用できます。ゼロデータ保持をサポートするモデルは、引き続きゼロデータ保持で動作します。 なし inherit 明示的な設定は適用されず、1 つ上のスコープに従います (プロジェクトはアカウントに、アカウントはサービスのデフォルトに従います)。新しいアカウントのデフォルトはこのモードです。 なし provider_data_share データは信頼と安全性のために最大 30 日間保持され、モデルプロバイダーと共有される場合があります。 あり モードは下限ではなく上限であることを理解する 最も重要な概念は、 設定したモードは許容できる保持の上限であり 、すべてのリクエストがそのモードで動作するわけではないという点です。アカウントを provider_data_share に設定しても、すべてのリクエストが突然データの保持や共有を始めるわけではありません。ゼロデータ保持をサポートするモデルは、アカウントレベルの設定にかかわらず、引き続きゼロデータ保持で動作します。 アクセス許可の上限として考えてみましょう。 アカウントのモード 呼び出すモデル 動作 provider_data_share Claude Sonnet (none をサポート) ゼロデータ保持。Sonnet はデータ共有もデータ保持も必要としません。 provider_data_share Claude Fable 5 ( provider_data_share が必要) データは最大 30 日間保持され、プロバイダーと共有される場合があります。Fable 5 はデータ共有とデータ保持を必要とします。 none Claude Sonnet ( none をサポート) ゼロデータ保持、データ共有なし none Claude Fable 5 ( provider_data_share が必要) ブロックされます。上限がモデルの要件を下回っているため、このモデルの呼び出しは拒否されます。 default Claude Sonnet ( none をサポート) ゼロデータ保持。Sonnet はゼロデータ保持をサポートしており、データ保持もデータ共有もありません。 default 安全性チェックのために保持を必要とするモデル データは保持されます。モデルが保持を必要としており、上限がそれを許可しているためです。 重要なポイント: モード設定は、許容するデータ保持の最大レベルを宣言するものです。ゼロデータ保持をサポートするモデルは、アカウント設定にかかわらず、引き続きゼロデータ保持で動作します。Amazon Bedrock は、アカウントのモードが許可しているという理由だけで、必要以上のデータ保持が発生 しない ように設計されています。 重要: provider_data_share はモデルから継承されるものではなく、アカウントまたはプロジェクトレベルでの明示的なオプトインです。アカウントが inherit または default に設定されている場合、アカウントまたはプロジェクト内で設定しない限り、どのモデルを使用してもプロバイダーとのデータ共有が行われることはありません。 注: inherit の動作について: inherit モードは、階層の 1 つ上のスコープに従います (プロジェクトはアカウントに、アカウントはサービスのデフォルトに従います)。プロジェクトが inherit に設定され、その上のアカウントが provider_data_share に設定されている場合、プロジェクトは provider_data_share を継承します。 モデル から provider_data_share を継承することはなく、アカウントまたはプロジェクトレベルでの明示的な設定が必要です。 注: 保持を必要とする API について: 一部の Amazon Bedrock API は、モデルのサポート状況にかかわらず、動作にデータ保持を必要とします。例えば、 Batch API と store=true を指定した Responses API が該当します。モードを none に設定すると、これらの API はブロックされますが、これは想定どおりの動作です。上限が none であるということは保持を一切許容しないという意味であり、保持を必要とする API は利用できなくなります。 なぜ provider_data_share が存在するのか 一部の基盤モデルは、動作に provider_data_share モードを必要とします。AI モデルの進化に伴い、お客様と、お客様による安全な利用を保護するメカニズムも進化していく必要があります。 provider_data_share を必要とするモデルには allowed_modes: ["provider_data_share"] が設定されており、アカウントが明示的にオプトインしない限り、 利用不可 として表示されます。 これは意図的な設計です。 AWS では、お客様がこれらのモデルを使用する前に、データを共有するという意識的な決定を行うことを求めています。Amazon Bedrock で利用可能なモデルとその保持要件については、「 現在のモデルリスト 」を参照してください。この内容は新しいモデルのリリースに伴い変わる可能性があります。 規制要件、社内ポリシー、またはお客様への約束事項により、サードパーティーのモデルプロバイダーとのデータ共有が禁止されている場合は、複数のレベルでこれを強制できます。Amazon Bedrock は、きめ細かいプロジェクトレベルの設定から組織全体での強制まで、データ保持を管理するための複数のツールを提供しています。 データ保持を管理するためのツール Amazon Bedrock は、データ保持に対する複数レイヤーの制御手段を提供しています。これらは個別に使用することも、多層防御のために組み合わせることもできます。 ツール スコープ ユースケース Amazon Bedrock コンソール アカウントごと、AWS リージョンごと 迅速な設定と可視化。新しい Amazon Bedrock (mantle エンドポイント) コンソールで保持モードを直接表示および変更できます。 Amazon Bedrock Projects アカウント内のプロジェクトごと 互換性のあるモデル について、同一アカウント内で保持要件が異なるワークロードを分離 SCP 組織全体 どのアカウントもデータ共有にオプトインできないようにする IAM ポリシー アカウントごとまたはプリンシパルごと 管理アカウント (SCP の対象外) を含む、きめ細かい制御 Amazon Bedrock Projects によるきめ細かい制御 アカウント内のすべてのワークロードが同じデータ保持要件を持つとは限りません。 bedrock-mantle エンドポイント (OpenAI 互換 API など) を使用している場合、Amazon Bedrock Projects を使用することで、データ保持を許容できるトラフィックと保持してはならないトラフィックを、同じアカウント内であっても分離できます。 例えば、以下のような状況が考えられます。 チームが実験のために最新のモデル ( provider_data_share を必要とするモデルを含む) へのアクセスを必要とするリサーチプロジェクト ゼロデータ保持が必須である、顧客データを扱う本番プロジェクト Amazon Bedrock Projects を使用すると、リサーチプロジェクトには provider_data_share を設定しながら、本番プロジェクトは none にロックしたままにできます。各プロジェクトは、それぞれ独立して保持の上限を強制します。 プロジェクトレベルの保持の仕組み: 各プロジェクトは、それぞれ独自のデータ保持モードを設定できます inherit に設定されたプロジェクトは、アカウントレベルからモードを継承します none に設定されたプロジェクトは、アカウント設定にかかわらずゼロデータ保持を強制します。そのプロジェクトを経由するトラフィックでデータ共有が行われることはありません provider_data_share に設定されたプロジェクトは、データ共有を必要とするモデルを許可しますが、そのプロジェクト内のリクエストに限られます これにより、組織は機密性の高いワークロードに対して厳格なデータガバナンスを維持しながら、新しいモデルを段階的に導入する柔軟性を得られます。プロジェクト設定は、Amazon Bedrock コンソールまたは bedrock-mantle API を使用して管理できます。 重要: Amazon Bedrock Projects は bedrock-mantle エンドポイントでのみ利用可能です。mantle エンドポイント上の OpenAI 互換 API ( Responses 、 Chat Completions ) および Anthropic Messages API を使用してアクセスするモデルで動作します。すべてのモデルが bedrock-mantle で利用できるわけではありません。最新のサポート状況については、「 モデルごとのエンドポイントの可用性 」ページを確認してください。 bedrock-runtime エンドポイントでのワークロードの分離 bedrock-runtime エンドポイント ( Invoke 、 Converse API) を使用している場合、プロジェクトレベルのデータ保持は利用できません。 bedrock-runtime を通じて行われるすべてのリクエストには、アカウントレベルの保持モードが適用されます。 bedrock-runtime でワークロードレベルの分離を実現するには、別々の AWS アカウントを使用してください。 provider_data_share を必要とするワークロードは、SCP を適用しないアカウント (または OU) に配置します ゼロデータ保持を必要とするワークロードは、SCP を適用した別のアカウント (または OU) に配置します AWS Organizations の OU を使用して、保持ポリシーごとにアカウントをグループ化し、SCP を選択的に適用できます。 Organization Root ├── OU: Zero-Retention (SCP attached — blocks provider_data_share) │ ├── Account: Production-App-A │ └── Account: Production-App-B └── OU: Research (no SCP — allows provider_data_share) └── Account: ML-Experimentation プロジェクトと SCP の組み合わせ: SCP を使用して組織レベルで none を強制すると、 bedrock-mantle 上のすべてのプロジェクトレベル設定より優先されます。プロジェクトレベルの柔軟性が必要なアカウントには SCP を適用せず、代わりにプロジェクトレベルの分離を使用してください。いかなる状況でもデータ共有を許可してはならないアカウントに対しては、SCP を使用することで、両方のエンドポイントにおいて回避不可能な保証が得られます。 SCP による組織全体での強制 誰が管理者アクセス権を持っていても、どのエンドポイントを使用していても、どのアカウントもデータ共有を有効にできないという絶対的な保証が必要な組織にとって、SCP は最も強力な強制メカニズムです。SCP は、Amazon Bedrock コントロールプレーン ( bedrock:PutAccountDataRetention ) と mantle エンドポイント ( bedrock-mantle:PutAccountDataRetention 、 bedrock-mantle:CreateProject 、 bedrock-mantle:UpdateProject ) の両方に適用されます。 SCP によるゼロデータ保持の強制 このセクションでは、SCP を使用してデータ保持ポリシーを管理する方法を説明します。まず SCP とは何かを紹介し、続いて組織で使用できるポリシーの例をいくつか示します。 SCP とは サービスコントロールポリシー (SCP) は、組織レベルで設定されるガードレールです。アカウント管理者やルートユーザーを含む、組織内のすべてのプリンシパルより優先されます。たとえフル管理者権限を持っていても、SCP による拒否を AWS Identity and Access Management (IAM) ポリシーで上書きすることはできません。 SCP は AWS Organizations で管理され、以下のさまざまなレベルにアタッチできます。 ルート – 組織内のすべてのアカウントに適用されます 組織単位 (OU) – その OU 内のすべてのアカウントに適用されます 個別のアカウント – その特定のアカウントにのみ適用されます 重要: すべてのアカウントをカバーするには、SCP をルート OU にアタッチする必要があります。子 OU にアタッチした場合、その OU の外にあるアカウントは保護されません。また、組織の管理アカウントには SCP による制御は適用されません。 SCP ポリシー 以下のポリシーを使用すると、組織内の誰も Amazon Bedrock のデータ保持モードを none 以外に変更できなくなります。 重要: 新しいアカウントのデフォルトは inherit です ( none ではありません)。この SCP をアタッチする前に、各アカウントを明示的に none に設定する必要があります。まず、各アカウントで以下を実行してください。 aws bedrock put-account-data-retention --region us-east-1 --mode none 数百、数千の AWS アカウントを持っている場合は、この作業をスケールさせる方法が必要になります。その方法については、AWS re:Post の記事「 Automate Bedrock Zero Data Retention Across All Accounts in Your Organization 」を参照してください。 Amazon Bedrock ポリシー: このポリシーは、データ保持を none にのみ設定できるように制限するために使用します。 none 以外の値は拒否されます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RESTRICTBEDROCKDATARETENTION", "Effect": "Deny", "Action": [ "bedrock:PutAccountDataRetention" ], "Resource": "*", "Condition": { "StringNotEquals": { "bedrock:DataRetentionMode": "none" } } } ] } 仕組み Condition ブロックでは StringNotEquals を使用しており、 none 以外の値に対して拒否が発動します。これにより、以下が保証されます。 アクション 結果 モードを none に設定 許可 モードを provider_data_share に設定 SCP により拒否 モードを default に設定 SCP により拒否 モードを inherit に設定 SCP により拒否 この設定が組織にとって意味することは、以下のとおりです。 誰もモデルプロバイダーとのデータ共有を有効にできない – アカウント管理者であっても Access Denied を受け取ります provider_data_share を必要とするモデルは恒久的に利用不可になる – データ共有を必要とするモデル (Claude Fable 5 や Claude Mythos 5 など) は組織全体で動作しなくなります その他のすべてのモデルは引き続き通常どおり動作する – none モードをサポートするモデルは影響を受けません この設定は回避できない – IAM ポリシーで SCP の deny を上書きすることはできません オプション: プロジェクトレベルの上書きをブロックする bedrock-mantle エンドポイントは、プロジェクトレベルのデータ保持設定をサポートしています。追加の SCP でカバーしない場合、誰かが provider_data_share を設定したプロジェクトを作成または更新することで、アカウントレベルの制限を回避できてしまいます。これを防ぐには、SCP を拡張して bedrock-mantle のプロジェクトアクションを含めます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RESTRICTBEDROCKDATARETENTION", "Effect": "Deny", "Action": [ "bedrock:PutAccountDataRetention", "bedrock-mantle:PutAccountDataRetention", "bedrock-mantle:CreateProject", "bedrock-mantle:UpdateProject" ], "Resource": "*", "Condition": { "StringNotEquals": { "bedrock:DataRetentionMode": "none" } } } ] } なぜ bedrock-runtime にはプロジェクトレベルのブロックが不要なのか？ bedrock-runtime エンドポイントにはプロジェクトが存在しません。bedrock-runtime のトラフィックの保持設定を変更する唯一の方法は、アカウントレベルの bedrock:PutAccountDataRetention アクションであり、これは基本の SCP で既にブロックされています。追加の CreateProject と UpdateProject アクションが必要なのは、 bedrock-mantle がプロジェクトごとの保持設定の上書きを許可しているためであり、 bedrock-runtime ではプロジェクトレベルの制御は必要ありません。 データ保持とクロスリージョン推論 クロスリージョン推論プロファイルを使用する場合、データ保持モードがどのように評価されるかを理解しておくことが重要です。モードは、リクエストのソースリージョン、つまり API コールを行う AWS リージョンで評価されます。すべてのデスティネーションリージョンで保持モードを設定する必要はありません。 ただし、重要な注意点があります。モードのチェックはソースリージョンで行われますが、データ自体は推論が処理されるデスティネーションリージョンで保持される可能性があります。これは、保持されたデータが地理的にどこに存在するかを追跡している組織にとって重要なポイントです。 実際には何を意味するか データ保持と推論が実際にどのように動作するかを、以下に示します。 ソースリージョン (例: us-east-1) が provider_data_share に設定されている場合、クロスリージョン推論プロファイルを使用するリクエストは、デスティネーションリージョンの保持設定にかかわらず許可されます ソースリージョンが none に設定されている場合、 provider_data_share を必要とするモデルへのリクエストは、デスティネーションリージョンにルーティングされる前に、ソース側でブロックされます SCP は引き続きグローバルに適用されます。ルート OU の単一の SCP により、すべてのリージョンで provider_data_share が自動的にブロックされます SCP はグローバルに適用される データ保持設定はきめ細かい制御に役立ちますが、SCP を使用すれば、すべてのリージョンにわたってデータ保持の制限をグローバルに自動適用できます。ルート OU にアタッチされた単一の SCP により、リージョンごとに設定を行うことなく、すべてのリージョンで provider_data_share がブロックされます。これが、手動設定に頼るのではなく SCP を強制手段として使用することの主な利点の 1 つです。 設定を検証する データ保持設定と SCP の強制は、AWS SDK、 AWS コマンドラインインターフェイス (AWS CLI) 、または Amazon Bedrock コンソールを使用して検証できます。 現在の保持モードを確認する 現在の保持モードは、以下の方法で確認できます。 Amazon Bedrock コンソールを使用する場合: AWS マネジメントコンソールで新しい Amazon Bedrock (mantle エンドポイント) コンソールに移動し、[ 設定 ] を選択してから、[ データ保持 ] を選択します。ここで、現在のアカウントレベルの保持モードを確認し、直接変更できます。 訳注: bedrock-runtime 経由 ( aws bedrock コマンド、Invoke / Converse API) と bedrock-mantle 経由のアカウントレベルのデータ保持モードは、それぞれ独立した設定です。一方を変更しても他方には反映されません。コンソールで変更できるのは mantle 側のみのため、 bedrock-runtime のトラフィックを制御するには、別途 aws bedrock コマンドまたは API での設定が必要です。 AWS CLI を使用する場合 (CLI バージョン 2.35 以降が必要): aws bedrock get-account-data-retention --region us-east-1 想定されるレスポンス: { "mode": "none", "updatedAt": "2026-07-01T01:58:34.684Z" } bedrock-mantle API を使用する場合 (Amazon Bedrock API キーを使用): curl https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" 想定されるレスポンス: { "mode": "none", "updated_at": 1719792000 } モデルの有効なモードと許可されているモードを確認する bedrock-mantle API を使用して、特定のモデルでどの保持モードが有効になっているか、およびそのモデルがどのモードをサポートしているかを確認することもできます。 curl https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-fable-5 \ -H "x-api-key: $BEDROCK_API_KEY" レスポンス: { "id": "anthropic.claude-fable-5", "status": "available", "data_retention": { "mode": "provider_data_share", "source": "account", "allowed_modes": ["provider_data_share"] } } モデルが "status": "unavailable" と表示される場合、 status_reason フィールドに保持モードの競合に関する説明が表示されます。 SCP が機能していることを検証する SCP がデータ保持の変更を実際にブロックしていることを確認するには、モードを provider_data_share に設定してみてください。 AWS CLI を使用する場合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode provider_data_share bedrock-mantle API を使用する場合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' SCP が機能している場合 、 Access Denied エラーが返されます。 An error occurred (AccessDeniedException) when calling the PutAccountDataRetention operation: User: arn:aws:iam::123456789012:user/admin is not authorized to perform: bedrock:PutAccountDataRetention with an explicit deny in a service control policy SCP が機能していない場合 、リクエストは成功してしまいます。この場合は、直ちに設定を元に戻してください。 aws bedrock put-account-data-retention \ --region us-east-1 \ --mode none その後、SCP のアタッチについて、以下の観点でトラブルシューティングを行います。 SCP が子 OU ではなくルート OU にアタッチされていることを確認する SCP ポリシーの構文と条件キーを確認する AWS Organizations の管理アカウントは SCP の対象外であることに注意する。そのアカウントにポリシーを強制するには IAM ポリシーを使用してください データ保持を必要とするモデルでデータ保持を有効にする provider_data_share を必要とするモデルを使用したいアカウント (SCP が適用されていないアカウント) では、AWS CLI、API、またはコンソールを使用してモードを設定します。 AWS CLI を使用する場合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode provider_data_share bedrock-mantle API を使用する場合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' 新しい Amazon Bedrock (mantle エンドポイント) コンソールの [ 設定 ] にある [ データ保持 ] からも設定できます。 データ保持を none に戻す ゼロデータ保持に戻すには、以下を実行します。 AWS CLI を使用する場合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode none bedrock-mantle API を使用する場合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "none" }' プロジェクトレベルのデータ保持を管理する プロジェクトレベルでデータ保持を設定することで、同じアカウント内の異なるワークロードに異なる保持ポリシーを適用できます。プロジェクトのデータ保持モードを更新するには、 bedrock-mantle API を使用します。 # Set a project to provider_data_share curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "data_retention": { "mode": "provider_data_share" } }' # Set a project to none (zero retention) curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "data_retention": { "mode": "none" } }' # Check a project's current setting curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" プロジェクトレベルの保持の解決方法: リクエストに対する有効なモードは、プロジェクト、アカウント、モデルのデフォルトという階層の中で、最初に見つかった inherit 以外の値によって決まります。プロジェクトが none に設定されている場合、アカウント設定にかかわらずゼロデータ保持が強制されます。プロジェクトが inherit に設定されている場合は、アカウントレベルの設定に従います。 注: プロジェクトレベルのデータ保持は、 bedrock-mantle API を通じてのみ管理できます。プロジェクトレベルの設定用の AWS CLI コマンドはありません。前述の AWS CLI コマンドは、Amazon Bedrock コントロールプレーンを通じてアカウントレベルの設定のみを管理します。 まとめ 本記事では、プロジェクトレベルのデータ保持や、SCP を使用して実装できる組織全体での制御など、Amazon Bedrock でデータ保持を管理するさまざまな方法を紹介しました。要件に合った組み合わせを選択し、デプロイ前に Amazon Bedrock のドキュメントで各モデルのモード要件を確認してください。 Amazon Bedrock のデータ保持の詳細については、「 データ保持のドキュメント 」を参照してください。SCP については、AWS Organizations ユーザーガイドの「 サービスコントロールポリシー 」を参照してください。 その他のリソース Amazon Bedrock のデータ保持 – 保持モード、設定、IAM による強制に関する完全なドキュメント クロスリージョン推論プロファイル – 推論が AWS リージョン間でどのようにルーティングされるかを理解する Amazon Bedrock の不正使用検出 – 安全性の目的で保持されるデータ 拒否されたリクエストに対するフォールバッククレジット – Fable 5 が Opus 4.8 にフォールバックした場合の請求の仕組み Claude Fable 5 と Mythos 5 の発表 – 新しいデータ保持ポリシーに関する Anthropic の説明 Anthropic データ処理補遺 – Anthropic と共有されるデータを管理する法的条件 サービスコントロールポリシー (SCP) – AWS Organizations のドキュメント ぜひ本記事の例をお試しください。フィードバックは、 AWS re:Post for Amazon Bedrock または通常の AWS サポートの窓口を通じてお寄せください。 Rob Higareda Rob は AWS の Security Risk and Compliance 組織のプリンシパルソリューションアーキテクトで、AI を活用したサービスのリスク評価に注力しています。システムエンジニアとして 20 年以上の経験を経て AWS に入社しました。主に AWS の規制対象のお客様を担当し、セキュリティとインフラストラクチャの設計に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 7 月 6 日 に公開された「 Deploying VCF 9.1 on Amazon EVS with End-to-End Automation 」を翻訳したものです。 はじめに Amazon Elastic VMware Service (Amazon EVS) を使用すると、Amazon VPC 内の AWS ベアメタル EC2 インスタンス上で VMware Cloud Foundation (VCF) を直接実行できます。EVS では、使い慣れた VMware スタックの運用一貫性を維持しながら、AWS クラウドサービスの弾力性、セキュリティ、豊富な機能を活用できます。 VCF 9 は VMware Cloud Foundation の最新リリースであり、以前の VCF 5.2 リリースとは根本的に異なる方法で Amazon EVS と連携します。VCF 5.2 では、EVS サービスがデプロイ全体をエンドツーエンドで処理していました。VLAN サブネットのデプロイ、ホストを含む EVS 環境、および完全な VCF スタックはすべて、サービスが自動的にプロビジョニングおよび設定していました。VCF 9 では、Amazon EVS はセルフデプロイモードと呼ばれる方式でのみ動作します。 セルフデプロイモードとは？ セルフデプロイモードでは、Amazon EVS が基盤となる AWS インフラストラクチャをプロビジョニングします。具体的には、VCF に必要な VLAN サブネットと、選択した ESXi バージョン（9.0 または 9.1）を実行するベアメタル EC2 ホストです。ただし、サービスが担うのはここまでです。EVS は VCF 自体のインストールや設定は行いません。EVS が代わりに VCF 9 をデプロイするオプションは存在しません。 つまり、EVS がホストとネットワークを提供した後は、VCF のインストールはお客様の責任となります。VMware のドキュメントに従って手動でインストールするか、自動化を使ってプログラム的に処理できます。本ブログ記事ではまさにその自動化を取り上げます。AWS が公開した エンドツーエンドの自動化ツールキット は、前提条件となる AWS インフラストラクチャと EVS 環境のプロビジョニングから、VCF のインストールおよび設定まで、ワークフロー全体を処理します。このツールキットは VCF 9.0 と 9.1 の両方に対応しています。 VCF デプロイを自動化する理由 セルフデプロイモードでは VCF 9 のインストールはお客様の責任であるため、自動化が特に効力を発揮します。VCF の手動インストールには、数十もの設定ステップ、複雑な JSON 仕様の作成、パスワード生成、そして数時間の待機が必要です。本ツールキットはそれを 3 つの CLI コマンドに集約します。 再現性：リージョンやアカウントをまたいで同一環境をデプロイ可能 スピード：数時間かかる手動プロセスを 3 コマンドに短縮 監査性：すべての設定判断がバージョン管理されたコードに記録 エラー削減：DNS レコード、VLAN CIDR、bringup 仕様における手動入力ミスを排除 セキュリティ：パスワードを自動生成して AWS Secrets Manager に保存 構築するもの 自動化ツールキットは VCF 9.0 と 9.1 の両方に対応していますが、本ブログでは VCF 9.1 のデプロイに絞って説明します。このウォークスルーを完了すると、以下が構築されます。 Route 53 DNS、BGP 対応 Route Server、必要なネットワーキングを備えた VPC ESXi 9.1 を実行する 3 台のベアメタルホストを持つ Amazon EVS 環境 完全に動作する VCF 9.1 スタック：vCenter、SDDC Manager、NSX Manager、VCF Operations、VCF Cloud Proxy、2 台の NSX Edge NSX オーバーレイセグメントと VPC ルートテーブル間で動的なルート伝播を行う Tier-0 および Tier-1 ゲートウェイ EVS サービス内の Ops Manager Connector コストの考慮事項 本自動化でデプロイされるリソースには、EC2 ベアメタルコンピューティング、Amazon EVS コントロールプレーン、VPC Route Server、Transit Gateway（有効化した場合）、NAT Gateway、EBS ボリューム、Route 53 ホストゾーンなど、相当な月額費用が発生します。デプロイ前に Amazon EVS 料金ページ を確認し、 AWS Pricing Calculator を使って環境全体のコストを把握することをお勧めします。 アーキテクチャの概要 本自動化は、完全な Amazon EVS 環境と VCF 9 を 3 つのステージにわたってデプロイします（1 ステージにつき 1 つのレイヤー）。最初に設定の詳細を入力するだけで、各ステージで生成されたリソース ARN などのメタデータとともに設定値が次のステージへ自動的に引き継がれます。同じ情報を 2 度入力する必要はなく、設定ミスを大幅に削減できます。各ステージの内容は次のとおりです。 AWS 前提条件とアンダーレイ： VPC、サービスアクセスサブネット、Route 53（フォワードおよびリバースゾーン）、2 つの BGP エンドポイントを持つ Route Server、セキュリティグループ、オプションの Transit Gateway、オプションの Windows ジャンプボックス（踏み台サーバー）、オプションのパブリックまたはプライベート HCX 接続などを構築します。 EVS レイヤー： まず、管理、vMotion、vSAN、vTEP、エッジアップリンクなどに使用する 10 個の VLAN サブネットを作成し、EVS 環境を構築します。次に、ESXi 9.1 で起動する 3 台のベアメタルホスト（ユーザーが指定する i4i.metal または i7i.metal-24xl）をプロビジョニングします。最後に、VCF Installer をステージングするデータストアとして EBS ボリュームを作成し、いずれかのホストにマウントします。 VCF のインストールと NSX ルーティング： VCF Installer のデポを設定し、ターゲット VCF バージョンに基づいてバイナリのダウンロードを自動的にトリガーします。次に vCenter、SDDC Manager、NSX Manager、VCF Operations、VCF Cloud Proxy、アクティブ/スタンバイ構成の 2 台の NSX Edge をデプロイします。エッジは BGP で AWS Route Server とピアリングし、NSX セグメントルートを VPC にアドバタイズします。 3 フェーズの自動化アプローチ 本自動化は 3 つの順次フェーズで構成されており、それぞれ独自のツールと目的を持ちます。 フェーズ スタック 内容 1 Terraform VPC、Route 53、Route Server、セキュリティグループ、オプションの Transit Gateway、オプションのジャンプボックス、オプションのパブリック接続など 2 Python (boto3) EVS 環境と VLAN サブネットの作成、ESXi 9.1 を搭載したベアメタルホストのプロビジョニング、インストーラーステージング用 EBS ボリュームの作成とアタッチ 3 Python (VCF SDK + boto3) デポの設定、バイナリのダウンロード、VCF bringup、インストーラーのクリーンアップ、NSX Edge Cluster とルーティングのデプロイ、Ops Manager Connector の作成 フェーズ 1 と 2 は Mac、Linux、または Windows ワークステーションからローカルで実行します。フェーズ 3 は VPC 内のジャンプボックスから実行します（VCF Installer および NSX Manager への直接接続に必要）。唯一の手動ステップは、フェーズ 2 と 3 の間に行う 2 つの簡単な ESXi 設定と VCF Installer OVA のデプロイです。デプロイ全体の所要時間はおよそ 3.5〜6 時間で、大部分はフェーズ 3 の VCF bringup プロセスが占めます。 前提条件 AWS アカウントと権限 以下を満たす AWS アカウント AWS Business Support 以上 EVS 環境あたりのホスト数サービスクォータが 3 以上に設定済み オンデマンドスタンダード（A、C、D、H、I、M、R、T、Z）インスタンスのサービスクォータが 256 以上に設定済み コードリポジトリのフェーズ 1 配下にある iam_policy.json ファイルで定義された権限ポリシーを持つ IAM ユーザーまたはロール ローカルワークステーションのツール Terraform 1.7 以降 Python 3.12 以降 AWS CLI v2 （AWS_PROFILE または環境変数でクレデンシャルを設定済み） pip （Python 依存関係のインストール用） git （コードリポジトリのクローン用） Broadcom デポトークン フェーズ 3 では Broadcom デポから VCF コンポーネントのバイナリをダウンロードします。Broadcom サポートポータルの「My Dashboard」→「Quick Links」→「Generate Download Token」からダウンロードトークンを生成してください。このトークンはフェーズ 3 の実行前に VCF_DEPOT_TOKEN 環境変数として設定します。 VCF Installer OVA Broadcom ダウンロードポータルから VCF 9.1 Installer OVA をダウンロードしてください。このアプライアンスはフェーズ 2 と 3 の間に、いずれかの ESXi ホスト上へ手動でデプロイします。 リポジトリのクローン 自動化リポジトリをクローン してローカルワークステーションに配置してください（このコマンドは Linux と Windows の両方で使用できます）。 git clone https://github.com/aws/solutions-for-amazon-evs.git cd solutions-for-amazon-evs/Deploy/VCF9-Phased-Deployment  フェーズ 0：デプロイ前の入念な計画 自動化を実行する前に、設定ファイルを慎重に計画して入力する必要があります。このステップは非常に重要です。インフラストラクチャをデプロイした後は、環境全体を解体して再構築しなければ変更できない値が多数あるため、時間をかけて正確に設定してください。 自動化では、最初に 1 度だけ入力する 2 つの設定ファイルを使用します。その後のフェーズはこれらのファイルから値を読み取り、次のフェーズへ自動的に引き継ぎます。 terraform.tfvars（フェーズ 1 の入力） このファイルは AWS インフラストラクチャの基盤を定義します。 terraform.tfvars.example を terraform.tfvars にコピーして以下を設定してください（Linux）。 cd Phase_1_Base_Infrastructure cp terraform.tfvars.example terraform.tfvars  Windows の場合： cd Phase_1_Base_Infrastructure copy terraform.tfvars.example terraform.tfvars  以下の値を実際の環境に合わせて更新してください。 region ：デプロイ先の AWS リージョン（例：us-east-2）。Amazon EVS が利用可能なリージョンを指定してください。 availability_zone ：リージョン内の特定の AZ（例：us-east-2a）。すべてのリソースは単一の AZ にデプロイされます。EC2 キャパシティ予約がある場合は、予約済みの AZ と一致させてください。 fqdn ：環境の完全修飾ドメイン名（例：mylab.evs.aws）。Route 53 フォワードホストゾーンとなり、すべての DNS レコードに使用されます。慎重に選択してください。 cidr_prefix ：VPC CIDR の最初の 2 オクテット（例：”10.0.”）。自動化はこのプレフィックスからすべての VLAN サブネット CIDR を導出します。Transit Gateway または Direct Connect で接続する予定のネットワークと重複しないようにしてください。 DNS ホスト名 ：各 VCF アプライアンスと ESXi ホストの短い DNS 名（esxi01_name から vcf_fleet_name まで）。 create_tgw ：他の VPC やオンプレミスネットワークへの Transit Gateway 接続が必要な場合は true に設定してください。 create_jumpbox ：Windows ジャンプホストを作成する場合は true に設定してください。VPC 内から実行する必要があるフェーズ 3 に必須です。このフラグを有効にすることをお勧めします。 enable_public_hcx ：HCX インターネット接続用のパブリック IP スペースを割り当てる場合は true に設定してください。false の場合、HCX はプライベート VLAN を使用します（Direct Connect または Transit Gateway 経由の HCX に適しています）。 VPC CIDR の分割方法 cidr_prefix で最初の 2 オクテットのみ指定します（例：”10.0.”）。自動化は /16 の VPC を作成し、ハードコードされた第 3 オクテットを使って /24 の VLAN サブネットに分割します。 <prefix>0.0/24 — サービスアクセスサブネット <prefix>10.0/24 — ホスト vmkernel 管理（vmkManagement） <prefix>20.0/24 — vMotion <prefix>30.0/24 — vSAN <prefix>40.0/24 — Host TEP (vTep) <prefix>50.0/24 — Edge TEP (edgeVTep) <prefix>60.0/24 — VM 管理（vmManagement） <prefix>70.0/24 — HCX <prefix>80.0/24 — NSX アップリンク（nsxUplink） <prefix>90.0/24 — 拡張 VLAN 1 <prefix>100.0/24 — 拡張 VLAN 2 config.json でこれらの VLAN サブネット CIDR を変更する場合は、NSX Edge IP、Route 53 インバウンドリゾルバーエンドポイント（<prefix>0.100 および <prefix>0.101）、BGP アップリンクアドレスなど、サブネット内に設定されるハードコードされた IP アドレスと競合しないよう注意してください。 config.json（フェーズ 2 の入力） このファイルは EVS 環境と VCF デプロイパラメーターを定義します。 config.example.json を config.json にコピーして以下を設定してください（Linux）。 cd Phase_2_evs_env/python cp config.example.json config.json Windows の場合： cd Phase_2_evs_env/python copy config.example.json config.json  以下の値を実際の環境に合わせて更新してください。 environmentName ：EVS 環境のわかりやすい名前。AWS コンソールに表示され、リソースのタグ付けに使用されます。 vcfInstallerProductVersion ：VCF Installer の製品バージョン番号のみ（ビルド文字列は含めない）。例：”9.1.0.0″。正確な値は OVA ファイル名またはインストーラー UI の設定ページで確認してください。 simpleDeployment ：単一ラック・シンプルデプロイ（最小 3 ホスト）の場合は true、単一ラック・HA デプロイ（最小 4 ホスト）の場合は false を設定してください。この設定は、デプロイされる NSX Manager と VCF Operations ノードの数に影響します。詳細は Single-Rack vSphere クラスターモデルのドキュメント を参照してください。 vcfSizing ：vCenter（vmSize、storageSize）、NSX（nsxSize）、VCF Operations（operationsApplianceSize、operationsCollectorApplianceSize）のアプライアンスサイジング。ほとんどのデプロイでは “medium” のデフォルト値が適切です。 ヒント： FQDN、CIDR プレフィックス、ホスト名の選択は事前に十分確認してください。フェーズ 1 のデプロイ後にも検証することをお勧めします。フェーズ 1 の削除と再デプロイは数分で完了するため、この時点であれば変更は容易です。フェーズ 2 で FQDN や CIDR などの値を組み込んだ EVS 環境がデプロイされると、変更には最初から再構築が必要になります。 フェーズ 1：基盤 AWS インフラストラクチャ（Terraform） フェーズ 1 で作成されるもの フェーズ 1 は、EVS が必要とする AWS ネットワークおよびサポートリソースをすべてプロビジョニングします。 terraform apply が完了すると（通常 3〜5 分）、以下が構成されます。 VCF アプライアンスと ESXi ホスト用の Route 53 プライベートホストゾーン フォワードホストゾーン（A レコード） リバースホストゾーン（PTR レコード） 2 つの IP を持つインバウンドリゾルバーエンドポイント Amazon VPC 専用サービスアクセスルートテーブルに関連付けられたプライベートサービスアクセスサブネット 専用パブリックアクセスルートテーブルに関連付けられたパブリックアクセスサブネット Elastic IP を持つ NAT Gateway Internet Gateway FQDN、Route 53 インバウンドリゾルバー IP、NTP（169.254.169.123：AWS NTP サーバー）を設定した DHCP オプションセット VPC CIDR からの受信を許可する専用 EVS サービスアクセスセキュリティグループ VPC Route Server VPC に関連付け済み それぞれピア IP、ピア ASN（65000）、BGP キープアライブを設定した 2 つの Route Server エンドポイント サービスアクセスルートテーブルとパブリックアクセスルートテーブルへの 2 つの Route Server 伝播 EVS ホスト用の EC2 キーペア （オプション）アンダーレイ VPC への VPC アタッチメントを持つ Transit Gateway （オプション）VPC 内の Windows ジャンプホスト ジャンプホスト用の VPC パブリックサブネット Internet Gateway へのルートを持つジャンプホスト用専用ルートテーブル 専用ルートテーブルへの Route Server 伝播 VPC CIDR と EVS サービスアクセスセキュリティグループからのすべてのトラフィックを許可するジャンプホスト用専用セキュリティグループ 50 GB 暗号化 gp3 ルートボリュームとパブリック IPv4 アドレスを持つ、Windows Server 2025 を実行する t3.2xlarge EC2 インスタンス ジャンプホスト用専用 EC2 キーペア 注：このキーペアは “Jumpbox-KeyPair” という名前です。同名のキーペアが既に存在する場合、このコードは失敗します。その場合はコード内でキーペア名を変更してください。 （オプション）パブリック HCX 接続 IPv4 IPAM プール 連続したパブリック IP スペースの /28 VPC CIDR へのパブリック /28 の追加 デプロイの実行（Linux）： export AWS_PROFILE=your-profile-name    terraform init  terraform plan  terraform apply  Windows の場合： $env:AWS_PROFILE = "your-profile-name" terraform init terraform plan terraform apply Terraform は VPC ID、サブネット ID、Route Server エンドポイント IP、セキュリティグループ ID などの値を出力します。フェーズ 2 はこれらを terraform.tfstate ファイルから直接読み取ります。フェーズ 1 のデプロイはおよそ 5〜10 分で完了します。 インフラストラクチャの検証 フェーズ 1 の完了後、AWS コンソールで以下を確認してください。 期待される CIDR で VPC が作成されていること Route 53 ホストゾーンに、すべての VCF アプライアンスと ESXi ホストの A レコードおよび PTR レコードが含まれていること Route Server の 2 つのエンドポイントが “Available” 状態であること ジャンプボックスを使用する場合：インスタンスが実行中でパブリック IP を持つこと ジャンプボックスをデプロイした場合は、以下の手順で RDP アクセスを確立してください。 Jumpbox-SG セキュリティグループに、自分の IP アドレスからの RDP（TCP 3389）を許可するインバウンドルールを追加する EC2 キーペアを取得して Windows Administrator パスワードを復号する。PEM ファイルをダウンロードする（Linux）： KEY_PAIR_ID=$(terraform output -raw jumpbox_key_pair_id) aws ssm get-parameter --name /ec2/keypair/$KEY_PAIR_ID --with-decryption \ --region us-east-2 --query 'Parameter.Value' --output text > jumpbox.pem chmod 400 jumpbox.pem Windows の場合： $KEY_PAIR_ID = terraform output -raw jumpbox_key_pair_id aws ssm get-parameter --name "/ec2/keypair/$KEY_PAIR_ID" --with-decryption ` --region us-east-2 --query 'Parameter.Value' --output text | Out-File -Encoding ascii jumpbox.pem icacls jumpbox.pem /inheritance:r /grant:r "$($env:USERNAME):(R)" この PEM ファイルを EC2 コンソール（Connect > Get Windows Password）で使用して Administrator パスワードを復号してください。 最後に、VCF Installer OVA をジャンプホストにダウンロードまたはコピーしてください。フェーズ 2 と 3 の間の手動作業ステップで必要になります。 フェーズ 2：EVS 環境のデプロイ（Python） フェーズ 2 の処理内容 フェーズ 2 は Python CLI で、AWS API 経由で EVS デプロイを調整し、SDDC bringup 仕様と NSX デプロイ仕様を構築します。単一の CLI コマンドで、以下の 6 つのサブステップを順番に実行します。 pre-evs-sync-config ：フェーズ 1 の Terraform ステートを読み取り、VCF bringup 仕様とエッジクラスター仕様の初期版を生成 create-environment-and-hosts ：AWS API を呼び出して EVS 環境を作成し、完了後にベアメタルホストをプロビジョニング（15〜20 分） すべてのホストが CREATED ステータスになるまで待機（20〜40 分） post-evs-sync-config ：環境とホスト ID から派生した名前で SDDC 仕様を確定し、対応する VCF パスワードを Secrets Manager にプロビジョニング associate-vlan-subnets ：10 個の EVS VLAN サブネットをすべてサービスアクセスルートテーブルに関連付け create-and-attach-ebs ：256 GB の gp3 EBS ボリュームを作成し、VCF Installer VMFS 用として 1 台のホストにアタッチ deploy-environment の実行 Python 環境をセットアップし、単一コマンドでフェーズ 2 のパイプライン全体を実行します（Linux）。 python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python -m src.main deploy-environment \ --profile your-aws-profile \ --config config.json \ --tfstate ../../Phase_1_Base_Infrastructure/terraform.tfstate \ --instance-type <INSTANCE_TYPE> # 'i4i.metal' or 'i7i.metal-24xl' Windows の場合： py -m venv .venv .venv\Scripts\Activate.ps1 pip install -r requirements.txt python -m src.main deploy-environment ` --profile your-aws-profile ` --config config.json ` --tfstate ..\..\Phase_1_Base_Infrastructure\terraform.tfstate ` --instance-type <INSTANCE_TYPE> # 'i4i.metal' or 'i7i.metal-24xl' このコマンドは 6 つのサブステップを自動的に連結して実行します。合計所要時間はおよそ 30〜45 分で、大部分はベアメタルホストがプロビジョニングされて CREATED ステータスになるまでの待機時間が占めます。デバッグ用に各サブステップを個別に実行することも可能ですが、単一コマンドによるアプローチを 強く推奨 します。 Secrets Manager によるパスワード管理 フェーズ 2 の構築中、post-evs-sync-config サブステップがすべての VCF アプライアンス用の複雑なパスワードを自動生成し、AWS Secrets Manager に保存します。命名パターンは evs-<environment-id>_<role> です。 VCF のアカウントには vcenterRoot 、 vcenterSso 、 nsxRoot 、 nsxAdmin 、 nsxAudit 、 sddcManagerRoot 、 sddcManagerSsh 、 sddcManagerLocal 、 operationsAdmin 、 operationsMaster 、 operationsCollector 、 edgeAppliance が含まれます。 bringup 仕様はプレースホルダートークンを通じてこれらのパスワードを参照します。フェーズ 3 は実行時に Secrets Manager からパスワードを解決するため、平文パスワードがディスクに書き込まれることはありません。 手動による事前作業：ESXi 設定とインストーラー OVA フェーズ 2 と 3 の間に、いくつかの簡単な手順を手動で実施する必要があります。デプロイ全体を通じて唯一の非自動化部分であり、所要時間はおよそ 30 分です。以下の手順はすべて、フェーズ 2 で EBS ボリュームを受け取った 1 台の ESXi ホスト上で実施します。 EBS ボリュームへの VMFS データストアの作成 フェーズ 2 でいずれかの ESXi ホストに 256 GB の EBS ボリュームをアタッチしました。フェーズ 2 のコンソール出力で、どのホストがボリュームを受け取ったか確認できます。VCF Installer アプライアンスをホストするために、VMFS データストアとしてフォーマットする必要があります。 ESXi ホスト UI（ https://<esxi-host-ip> ）に root としてログインします。root パスワードは AWS Secrets Manager から取得してください（シークレット名は evs-<environment-id>_<role> のパターンです）。 Storage に移動し、New Datastore を選択する NVMe デバイス（256 GB EBS ボリューム）を選択して VMFS データストアを作成する VM Network ポートグループへの VLAN タグ付け EBS ボリュームを持つ ESXi ホストで、デフォルトの “VM Network” ポートグループに VLAN ID 20 をタグ付けし、VCF Installer が VM 管理ネットワークで通信できるようにします。 ESXi UI で Networking に移動し、Port groups を選択する “VM Network” ポートグループを編集する VLAN ID を 20 に設定する VCF Installer OVA のデプロイ VMFS データストアを持つホスト上に VCF Installer アプライアンスをデプロイします。 ESXi UI で Virtual Machines > Create/Register VM > Deploy OVF template に移動する VCF 9.1 Installer OVA ファイルをアップロードする 上記で作成した 256 GB VMFS データストアに配置する “VM Network” ポートグループにアタッチする 管理 IP を DNS 設定の SDDC Manager IP アドレスに設定する ネットマスクを 255.255.255.0 に設定する admin@local パスワードを設定する。手動で選択する唯一のパスワードです。独自のパスワードを作成するか、Secrets Manager に生成済みのパスワードを使用することもできます。フェーズ 3 で必要になるためパスワードを控えておいてください。 アプライアンスの電源を入れ、起動を待つ（ https://<sddcm_name>.<your-fqdn> でアクセスを確認） フェーズ 3：VCF Bringup と NSX Edge Cluster（Python） フェーズ 3 の処理内容 フェーズ 3 は EVS 環境をホストする VPC 内のジャンプホストから実行する必要があります。公式 VMware VCF Python SDK（vcf-installer、vcf-nsx）と vCenter 操作用 pyvmomi、および対応する AWS 操作用 boto3 ライブラリを使用します。単一の CLI コマンドで、以下の 7 つのサブステップを順番に実行します。 Secrets Manager 事前確認 ：開始前に必要なすべての Secrets Manager シークレットが存在することを確認。不足している場合、不足している VCF アカウントを明示したエラーでパイプラインを即座に終了。 prepare-depot ：Broadcom ダウンロードトークンをインストーラーに設定し、デポカタログを同期して必要なすべてのコンポーネントバイナリをダウンロード（約 30〜60 分） start-bringup --wait ：bringup 仕様を VCF Installer に送信し、ワークフローが完了するまでポーリング。vCenter、NSX Manager、SDDC Manager、VCF Operations をデプロイ（約 2〜4 時間） remove-installer-datastore ：手動で作成した 256 GB VMFS データストア上の VM を vSAN にストレージ vMotion し、データストアをアンマウント（約 5〜10 分） destroy-ebs-volume ：AWS 側からアンマウント済み VMFS データストアをホストしていた EBS ボリュームをデタッチして削除（約 30 秒） deploy-edge-cluster ：2 台の NSX Edge アプライアンスをデプロイし、エッジクラスターを作成し、Tier-0/Tier-1 ルーティングを設定し、AWS Route Server との BGP ピアリングを確立（約 30〜50 分） create-connector ：VCF Operations Manager コネクターを CreateEnvironmentConnector 経由で EVS に登録。 ACTIVE になるまでポーリング（約 2〜5 分） 以下のサブセクションでは、フェーズ 3 の内部処理をより詳細に段階的に説明します。 deploy-vcf-and-edge の実行 と題したセクションに、フェーズ 3 のワークフロー全体を実行する単一コマンドが記載されています。 デポとバンドルの管理 prepare-depot サブステップは、VCF Installer UI にログインして Broadcom デポを設定する手動プロセスを自動化します。具体的には以下を実行します。 VCF SDK 経由でデポトークンをインストーラーに保存 メタデータ同期をトリガーしてバンドルカタログを更新 ターゲットバージョンに一致するすべての INSTALL タイプバンドルを特定 必要なすべてのコンポーネントバイナリ（vCenter、NSX、SDDC Manager、VCF Operations、ESXi）をダウンロード すべてのダウンロードが完了するまでポーリングし、その後 bringup に進む ヒント ：デポの問題をデバッグする必要がある場合、list-bundles、get-depot-settings、sync-depot などの個別アクションをスタンドアロン CLI コマンドとして実行できます。 VCF bringup ワークフロー start-bringup アクションは型付きの SddcSpec を VCF Installer に送信し、ワークフローを監視します。bringup 中にインストーラーは以下を実行します。 ESXi ホストを VCF 管理ドメインにコミッション vCenter Server をデプロイして設定 NSX Manager をデプロイして仮想 IP アドレスでクラスター化 SDDC Manager をデプロイ VCF Operations をデプロイ すべてのホストで vSAN ESA を設定 必要なすべてのポートグループを持つ分散仮想スイッチを作成 ヒント： CLI は 10 分ごとにインストーラーをポーリングして進捗を報告します。bringup が失敗した場合は、 https://<sddcm_name>.<your-fqdn> のインストーラー UI でタスクごとの詳細なエラー情報を確認してください。 インストーラーのクリーンアップ bringup が正常に完了した後、自動化は 2 つのクリーンアップステップを実行します。 remove-installer-datastore ：ローカル VMFS データストアに配置された VM を vSAN にストレージ vMotion し、データストアをホストからアンマウントします。これにより EBS ボリュームが削除可能になります。 destroy-ebs-volume ：EC2 インスタンスから EBS ボリュームをデタッチして削除します。ボリュームは ManagedBy タグと EnvironmentId タグで識別され、他のボリュームを誤って削除しないよう保護されています。 NSX Edge Cluster のデプロイ 次のサブステップは NSX Manager と vCenter API を直接使用して NSX Edge Cluster をデプロイします。7 つのステージで実行されます。 prep-edge-cluster ：DVS TRUNK ポートグループ、IP プール、アップリンクプロファイル、VLAN トランスポートゾーンを作成 deploy-edge-nodes ：2 台のラージフォームファクター エッジトランスポートノードを作成（OVA デプロイをトリガー） create-edge-cluster ：両方のトランスポートノードをグループ化するエッジクラスターを作成 create-tier0 ：ロケールサービスと BGP を有効にした Tier-0 ゲートウェイを作成 create-tier1 ：Tier-0 とエッジクラスターにアタッチした Tier-1 ゲートウェイを作成 configure-routing ：アップリンクセグメント、インターフェース、BGP ネイバー、プレフィックスリスト、スタティックルート、再配布を設定 create-anti-affinity ：エッジ VM 用の vCenter DRS アンチアフィニティルールを作成 各エッジアプライアンスは ASN 65000（NSX 側）と 65022（AWS 側）を使って 1 つの AWS Route Server エンドポイントと BGP ピアリングします。ピアリングが確立されると、NSX オーバーレイセグメントが VPC ルートテーブルにルートとして自動的にアドバタイズされます。 Ops Manager Connector 最後のサブステップは VCF Operations Manager コネクターを Amazon EVS に登録します。これは仮想マシンの Windows Server ライセンスエンタイトルメントの作成など、後続のアクションに使用されます。 環境変数の設定 フェーズ 3 では Secrets Manager に保存されていない 2 つのシークレットが必要です。手動手順で設定した VCF_INSTALLER_PASSWORD と、Broadcom ポータルから取得した VCF_DEPOT_TOKEN です。以下のコマンドで環境変数として設定します（Linux）。 # The admin@local password you set when deploying the installer OVA: read -rs VCF_INSTALLER_PASSWORD ; export VCF_INSTALLER_PASSWORD # Your Broadcom depot download token: read -rs VCF_DEPOT_TOKEN ; export VCF_DEPOT_TOKEN Windows の場合： # The admin@local password you set when deploying the installer OVA: $env:VCF_INSTALLER_PASSWORD = Read-Host -MaskInput "VCF Installer Password" # Your Broadcom depot download token: $env:VCF_DEPOT_TOKEN = Read-Host -MaskInput "VCF Depot Token" 他のパスワード（vCenter、NSX、SDDC Manager など）はすべて Secrets Manager から自動的に解決されます。 deploy-vcf-and-edge の実行 Python 環境を作成し、単一の CLI コマンドでフェーズ 3 のパイプライン全体をエンドツーエンドで実行します（Linux）。 cd Phase_3_VCF9/python python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python -m src.main deploy-vcf-and-edge \ --installer-host sddcm.<your-fqdn> \ --target-version 9.1.0 \ --nsx-manager-host nsx.<your-fqdn> \ --vcenter-host vc.<your-fqdn> \ --aws-profile your-aws-profile Windows の場合： cd Phase_3_VCF9\python python -m venv .venv .venv\Scripts\Activate.ps1 pip install -r requirements.txt python -m src.main deploy-vcf-and-edge ` --installer-host sddcm.<your-fqdn> ` --target-version 9.1.0 ` --nsx-manager-host nsx.<your-fqdn> ` --vcenter-host vc.<your-fqdn> ` --aws-profile your-aws-profile デバッグ用に各サブステップを個別に実行することも可能ですが、単一コマンドによるアプローチを 強く推奨 します。 検証と次のステップ deploy-vcf-and-edge が正常に返ったら、以下でエンドツーエンドの接続性を確認してください。 Route Server BGP ピアの確認 AWS コンソールで VPC > Route Servers > Peers に移動してください。両方の BGP ピアの BGP ステータスが “Up” になっているはずです。”学習済みルート” タブには NSX から発信された CIDR が表示されます（後で作成したセグメントも自動的にここに表示されます）。 テスト用 NSX セグメントの作成 NSX Manager（ https://nsx.<your-fqdn> ）にログインし、Tier-1 ゲートウェイにアタッチした新しいオーバーレイセグメントを作成します。 Networking > Segments > Add Segment に移動する セグメント名を test-segment とする 作成した Tier-1 ゲートウェイにセグメントをアタッチする サブネットを設定する（例：ゲートウェイ 172.16.1.1 の 172.16.1.0/24） このセグメントにテスト VM をデプロイし、IP アドレスを受け取ることを確認する オーバーレイからアンダーレイへの接続確認 NSX セグメント上のテスト VM から以下を実行します。 パブリックサブネット内のジャンプボックスに Ping する（デプロイ済みの場合） サービスアクセスサブネット内の EC2 インスタンスに Ping する セグメント CIDR（172.16.1.0/24）が VPC ルートテーブルに学習済みルートとして表示されることを確認する 3 つの確認がすべて成功すれば、NSX オーバーレイと AWS アンダーレイ間の動的なルート伝播が確立された、完全に動作する EVS 環境の構築完了です。 次のステップ： VMware HCX やその他の移行ツールを使用してオンプレミスからワークロードを移行する データセンターへのハイブリッド接続のために AWS Transit Gateway を設定する（フェーズ 1 でオプションとして作成しなかった場合） 補足ストレージとして Amazon FSx for NetApp ONTAP をセットアップする 運用監視のために AWS Systems Manager を統合する SDDC Manager 経由で追加のワークロードドメインをデプロイする トラブルシューティング よくある障害パターンと解決策を以下にまとめます。 フェーズ 1 および 2：AWS リソースエラー 対象リソースの AWS コンソールを確認してください。Terraform または boto3 のエラーテキストは通常、正しくプロビジョニングされなかった特定のリソース（AZ の誤り、サブネットの欠落、API コールのスロットリング）を指しています。 サービス制限を確認してください：EVS サービスクォータ、Dedicated Host の割り当て、VPC Route Server クォータ、EBS ボリューム制限。 ホストの実現がタイムアウトした場合（90 分超）、コンソールで EVS 環境のステータスを確認してください。FAILED 状態はキャパシティまたは設定の問題を示します。 フェーズ 3：デポの同期問題 Broadcom デポトークンが有効で有効期限が切れていないことを確認してください インストーラーアプライアンスが depot.broadcom.com へのアウトバウンドインターネットアクセス（ポート 443）を持つことを確認してください ダウンロードが止まった場合、自動化は指数バックオフで再試行し、5 回失敗後にエラーを報告します。その場合は download-all-product-binaries --wait で手動再試行できます フェーズ 3：Bringup の失敗 VCF Installer UI（ https://<sddcm_name>.<your-fqdn> ）はタスクごとの進捗と詳細なエラーメッセージを提供しており、API エラー本文よりも参考になります。 スタックトレースについてはインストーラーアプライアンスの /var/log/vmware/vcf/domainmanager/domainmanager.log を確認してください。 bringup が “VMwareProductVersion can not be null or empty” で失敗した場合、デポに必要なバイナリがキャッシュされていません。 prepare-depot を再実行して再試行してください。 フェーズ 3：Edge Cluster のデプロイ vSAN データストアに十分な空き容量がない場合、エッジノードのデプロイが失敗することがあります（各エッジ VM には約 200 GB が必要） BGP ピアリングの問題：エッジクラスター仕様の Route Server エンドポイント IP がフェーズ 1 の Terraform 出力と一致することを確認してください configure-routing が失敗した場合、クラスターが作成される前に両方のエッジノードが Success 状態に達していることを確認してください ヒント ：自動化の各アクションはべき等です。ステップが失敗した場合は、根本的な問題を修正して同じコマンドを安全に再実行できます。副作用は発生しません。 クリーンアップ 構築した環境を解体する場合は、以下の順序で実施してください。 EVS 内の仮想マシンを保持したい場合は、まず別の場所に移行してください。 AWS コンソールから EVS ホストを 1 台ずつ削除してください。 AWS コンソールから EVS 環境を削除してください。 フェーズ 1 を実行した元のワークステーションから Phase_1_Base_Infrastructure ディレクトリに移動し、 terraform destroy を実行してください。Terraform は既存の状態ファイルを使用してすべてのフェーズ 1 リソースを特定して削除します。 まとめ 本ウォークスルーでは、3 フェーズの自動化ツールキットを使って VMware Cloud Foundation 9.1 を Amazon EVS にデプロイしました。空の AWS アカウントから出発し、Terraform で前提条件となる AWS インフラストラクチャをすべてプロビジョニングし、AWS API 経由の Python CLI で EVS 環境とベアメタルホストをデプロイし、公式 VCF Python SDK を使って NSX Edge Cluster ルーティングを含む完全な VCF スタックを立ち上げました。 terraform apply から BGP ピアリングの確認まで、デプロイ全体でおよそ 3.5〜6 時間かかります。自動化により、作業は 3 つの CLI コマンドと ESXi 設定・OVA デプロイに必要な約 30 分の手作業のみに削減されます。 このアプローチの主な利点： Infrastructure as Code：すべてのリソースが Terraform または Python 自動化で定義されています デフォルトセキュア：すべての VCF パスワードが厳格な複雑性要件に従って生成され、AWS Secrets Manager に保存されます 安全な再実行：フェーズ 1 と 3 は完全にべき等であり、デバッグや復旧のためにどのステップも副作用なく安全に再実行できます SDK 駆動：フェーズ 3 は公式 VMware VCF Python SDK を使用し、手動による REST ペイロードの構築を排除します モジュラー設計：1 つのコマンドでパイプライン全体を実行するか、デバッグや部分的な再実行のために個別ステップを実行できます 開発環境のセットアップ、本番環境のデプロイ、顧客デモ用の再現可能なラボなど、あらゆるユースケースに対応できる堅牢な基盤として、バージョン管理・カスタマイズ・拡張が可能です。 著者について David Piet Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトとして、VMware ベースのワークロードを持つエンタープライズのお客様が AWS へ移行し、モダナイズするための支援を担っています。2018 年にパートナーソリューションアーキテクトとして AWS に入社し、VMware Cloud on AWS を専門としてきました。以来、AWS 最大規模のエンタープライズ顧客を数多くサポートし、VMware ベースのワークロードのクラウド移行と最適化戦略を牽引してきました。長年にわたり、AWS での VMware ビジネスの成長とともに担当範囲を広げ、現在もお客様のモダナイゼーションジャーニーの支援に深く関わっています。ノースウェスタン大学で博士号を取得しており、応用数学とエンジニアリングを専門としています。AWS 入社前はシリコンバレーのストレージスタートアップでソフトウェアデベロッパーとして勤務していました。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

AWS Summit Japan 2026（2026年6月25日〜26日、幕張メッセ）では、「AWS パートナーと実現する生成 AI」と題したPartner Breakout Sessionを4部構成でお届けしました。AWSの4つのAIビルディングブロックをテーマに、8組のAWSパートナーとお客様が独自視点でお客様の課題に挑んだ実践事例を共有しました。 本ブログでは、各セッションのハイライトと、全セッションを通して見えてきた「AIの価値を現場で実現するために本当に必要なこと」についてお伝えします。 セッション全体のアーキテクチャ概念 本セッションは、AWSの4つのAIビルディングブロックに沿って構成されています。そして重要なのは、この4つのブロックにわたり一貫したセキュリティ、ガバナンス、運用の仕組みが支えていることです。 AIビルディングブロック 対応パート　　 該当事例　　　　　 AI を活用したアプリケーション開発 Part 1 Kiro × 東邦ガス / エッジAI × KMバイオロジクス 基盤モデルの活用 Part 2 文字起こし × 青森放送 / 音声AI × 品川区 AI エージェント活用 Part 3 エージェント本番化 × ミルボン / 従量課金AI × 36flip AI 基盤とデータ活用 Part 4 エンタープライズAI × カラクリ / GraphRAG × 日本取引所     Part 1: 現場を変える AI ソリューションの実践 事例1: Kiro 導入で得られた開発プロセス改善効果と、AI 駆動開発に向けた組織課題 登壇: 東邦ガス情報システム 日沖裕介氏（デジタルソリューション部 主任）/ ソニービズネットワークス 濱田一成氏（開発本部 クラウド開発部 マネージャー） 東邦ガス情報システム様は、エネルギー契約者向け会員サイトの開発効率向上PoCに取り組みました。ソニービズネットワークスのKiro伴走支援のもと、AI駆動開発を組織に定着させる挑戦です。 ポイント : Kiroのspec駆動開発により、要件定義〜実装の一連のプロセスを大幅に効率化 単なるツール導入ではなく、組織全体のマインドセット変革が最大の課題だった パートナーの伴走支援が「ツールの使い方」ではなく「開発文化の変革」を支えた インサイト : AI駆動開発は個人のスキルではなく、チーム全体の協調と学習意欲が成果を左右する。技術的なハードルよりも「人がどう向き合うか」が鍵。   事例2: 現場の “気づき・判断・対応” を、人依存から “流れる業務” へ 登壇: KMバイオロジクス 田崎裕三氏（デジタルIT部）/ 富士ソフト 飯法師祐輔氏（組込/制御ビジネスユニット 営業統括部 九州営業部 リーダー） 製造業における属人化・現場依存・技術承継の課題に対し、後付け可能なエッジAIカメラとAWSのクラウド基盤、生成AIを融合したAI/IoTソリューションを展開。 ポイント : レガシーな機器でも後付けAIカメラでデータ取得を可能に – 異常検知だけでなく、過去データから次のアクションをナビゲーション Amazon Quickを用いた予兆保全にも活用可能 「気づき→判断→対応」の全フローを標準化し、ベテラン不在でも品質を維持 インサイト : 製造現場のAI化は最新設備だけの話ではない。「今ある環境を活かしながら、AIを”流れる業務”に変える」という現場起点の発想が重要。   Part 2: Amazon Bedrock で言葉の業務を変革する 事例3: 青森の放送局が報道現場で磨き上げた Amazon Bedrock を活用した文字起こしシステム 登壇: 青森放送 内山匠氏（デジタル報道室）/ ヘプタゴン 三浦一樹氏（クラウドソリューション部 クラウドアーキテクト） 青森県で2025年度平均個人視聴率13%を誇る『RAB ニュースレーダー』。放送だけでなくネット配信にも注力する中で、日々のインタビュー文字起こし作業を劇的に効率化するシステム「dahande」を開発しました。 ポイント : 現役報道記者自身が課題を感じ、パートナーと共にシステムを構築 Amazon Bedrock を活用し、方言や専門用語にも対応する高精度文字起こしを実現 「報道のスピード」に耐えうる実用性 — 使われなければ意味がないという現場の厳しい基準をクリア インサイト : 「使う人自身」が課題解決の主語になったとき、AIは初めて現場に根付く。記者とエンジニアが対等に対話したからこそ生まれた成果。   事例4: 「区民の問い合わせ、AI にどこまで任せる？」品川区 × SHIFT が挑む自治体音声 AI 実証 登壇: 品川区役所 西澤拓氏（企画経営部 DX戦略担当部長 CIO・CISO）/ SHIFT 寅野理司氏（AI・DX開発部 シニアクラウドアーキテクト） 戸籍・異動手続きの音声AI対応実証実験。Amazon ConnectとAmazon Bedrockを組み合わせ、RAG設計・セッション管理・有人窓口へのシームレスな接続を実装しました。 ポイント : 区民の属性や状況によって聞き返しの分岐が複雑に変わる業務に対し、業務マニュアルをAIネイティブに変換するRAG設計を実施 「AIに任せる業務 / 人が担う業務」の境界線を実証を通じて明確  自治体DXの現場視点（品川区）と技術アーキテクチャ視点（SHIFT）の両輪が重要 インサイト : AIの価値は「全てを自動化する」ことではない。「どこまで任せ、どこから人が担うか」を現場と技術者が一緒に線引きするプロセスこそが、信頼されるAI実装の基盤。   Part 3: 企業が今すぐ始める AI エージェント活用 事例5: AI エージェントを”検証”から”本番活用”へ — ミルボン様と進める、Amazon Bedrock 活用の実践 登壇: ナレッジコミュニケーション 奥沢　明氏 案件初期から動くモックアップで活用イメージを具体化し、Amazon Bedrockを活用したセキュアなAWSアーキテクチャでAIエージェントの本番活用を実現する実践を紹介。 ポイント : モックアップファースト — 初期段階から動くプロトタイプを提示し、お客様の「使いたい」を引き出す PoCで終わらせない「本番活用」への確実なステップ設計 Amazon Bedrockのマルチエージェントコラボレーションを活用 インサイト : AIエージェントを「検証」で終わらせず「本番」に進めるには、初期段階での”手触り感のある体験”が意思決定者の背中を押す。   事例6: 無駄な費用ゼロ！「使った分だけ」で始める企業向け生成 AI ソリューション 登壇: 36flip 谷口慶多氏 / KDDIアイレット 平野健介氏 従来の定額・ユーザー数課金型AIサービスの常識を覆す、アクティブ数連動型の企業向け生成AIソリューション。コストを最適化しながら、ビジネス現場の生産性を最大化する新しいモデルを提案。 ポイント : 「使った分だけ」の料金体系で、組織全体への展開時のコストの壁を解消 Amazon Bedrockをバックエンドに、スケーラブルで安全な基盤を構築 「全社導入したいがコストが見えない」という経営層の最大の懸念に正面から回答 インサイト : AI全社展開の最大の障壁は技術ではなく「コストの不透明さ」。ビジネスモデルのイノベーションがAI普及を加速させる。   Part 4: AI実装を支える AI 基盤とデータ活用 事例7: 現場で機能するエンタープライズ AI とは — Upstage・Karakuri の実践知 登壇: カラクリ 中山智文氏（CPO）/ Upstage AI 松下紘之氏（代表取締役） 日本語特化LLM、Document AI、エージェント型AIワークフローを組み合わせ、実際の業務環境で機能するAIの実装方法を解説。AWSとともに、インフラ・学習・推論・本番運用までの実践知を共有。 ポイント : 汎用LLMだけでは不十分 — 日本語特化モデル × Document AI × エージェントの組み合わせが現場品質を実現 AWS Trainiumを活用したコスト効率の高い学習基盤 「実験」から「実装」への移行に必要なインフラ設計の勘所 インサイト : エンタープライズAIは「一つのモデルで全て解決」ではない。複数の技術を組み合わせ、現場の業務フローに溶け込ませる設計力が問われる。   事例8: GraphRAG Toolkit (ナレッジグラフ) による暗黙知の形式知化 登壇: 日本取引所グループ 夏目卓哉氏（IT企画部 課長）/ 豆蔵 高田恵子氏（AIコンサルティング事業部 データ戦略グループ シニアコンサルタント） 日本取引所グループにおけるベテラン職員の「暗黙知」を、オントロジー技術を基盤としたナレッジグラフ（GraphRAG Toolkit）により「形式知化」した事例。 ポイント : 従来のRAGでは捉えきれない構造的な知識の関係性をナレッジグラフで表現 データ前処理・実行環境・ユーザー評価の3観点で取り組みを整理 ベテランの「なぜそう判断するか」のプロセスをAIが再現可能に インサイト : 暗黙知の形式知化は、テクノロジーだけでは完結しない。ベテラン本人が「言語化」に協力する意思と、それを引き出すファシリテーション力がプロジェクトの成否を分ける。   全セッションを通して感じたこと — AIの価値を実現する「人の力」 4部・8事例を通して、一つの共通点が浮かび上がりました。 AIの本当の意味での価値を実現するには、単なる技術やプロセスではなく、多くの人の意思、協調、現場力が不可欠だということです。 技術的に優れたAIモデルは日々進化しています。しかし、それを現場で価値に変えるのは、課題を自分ごととして捉え、部署を超えて協調し、「変えたい」という意思を持った人々です。それが文化となり、プロセス変革の推進力となり、AIによるビジネス価値を実現できるのではないでしょうか。   まとめ AWS Summit Japan 2026のPartner Breakout Sessionは、AWSパートナーがお客様と共に挑んだリアルな実践の場でした。PoCで終わらず、現場で使われ続けるAIを作るために必要なのは、最先端の技術だけではありません。 現場の人々の意思と協調 — それこそが、AIの価値を最大化する最も重要なファクターです。 AWS パートナーエコシステムは、お客様の AI ジャーニーをあらゆるフェーズで支援しています。本セッションで紹介された各パートナーへのお問い合わせは、 AWS パートナーファインダー からご確認いただけます。     本ブログは AWS Summit Japan 2026 の Partner Breakout Session「AWS パートナーと実現する生成 AI」の内容をもとに作成しました。 タグ: #AWSSummitJapan #GenerativeAI #AmazonBedrock #AIAgent #PartnerSolutions #Kiro #GraphRAG #EdgeAI          

オンプレミスの HPC 環境からの移行を進める研究チームは、クラウドへのデプロイの複雑さに悩まされることがよくあります。従来のアプローチでは、AWS のネットワーク、ストレージアーキテクチャ、Slurm の構成管理に関する深い専門知識が必要でした。一般的な手動デプロイでは、インフラのプロビジョニング、ネットワークトポロジの設計、スケジューラの構成、パフォーマンスチューニングに数週間を要します。プラットフォームエンジニアリングのリソースが限られている研究チームは、計算能力に対する差し迫ったニーズと、デプロイの技術的な障壁との間で板挟みになってしまいます。 本記事では、業界のベストプラクティスを組み込んだ AWS PCS クラスターを、Kiro CLI を使って自動的にデプロイ・構成する方法をご紹介します。インフラのプロビジョニング、モニタリングのセットアップ、コスト最適化を担いながら、研究チームが特定のワークロードに必要とする柔軟性を維持する「カスタムエージェント」の作成手順を順を追って解説します。 クラウドにおける HPC クラウドベースの HPC は、柔軟なコンピューティングアクセス、幅広いリソースの可用性、そして価値あるインフラの抽象化により、標準的な手法となっています。本記事では、AWS Parallel Computing Service (PCS) と Kiro CLI を活用して、このアプローチを実演します。 AWS PCS : AWS PCS は、自動構成・スケーリング・メンテナンスを備えたマネージドな Slurm スケジューラを提供することで、HPC のデプロイを簡素化します。本サービスはクラスターのライフサイクル管理を担う一方で、コンピューティングリソースとジョブスケジューリングポリシーに対するコントロールはお客様が維持できます。PCS は、共有ストレージ向けの Amazon Elastic File System やモニタリング向けの Amazon CloudWatch といった AWS サービスとネイティブに統合され、HPC のデプロイで通常必要となる統合作業を削減します。 Kiro CLI : Kiro CLI は、特定のユースケースに合わせた専門的なガイダンスを備えた カスタムエージェント を定義することで、非常に強力なものになります。ドメインの専門知識をエージェント定義に直接エンコードすることで、組織のベストプラクティスや要件を理解した専用の自動化を構築できます。例えば本記事では、HPC ワークロード向けの AWS Parallel Computing Service のベストプラクティス（最適なインスタンスの選択、ネットワーク構成、ストレージの最適化など）を組み込んだ PCS デプロイエージェントを作成します。このエージェントは確立されたデプロイパターンを活用することで、複雑なクラスターのプロビジョニングを効率化し、デプロイ時間と構成ミスのリスクの両方を削減します。汎用的な自動化とは異なり、このアプローチは実証済みの方法論を特定のインフラのニーズに適応させる、インテリジェントでコンテキストを理解した支援を提供します。 はじめに 自動化された PCS デプロイのアプローチを実装する前に、3 つの前提条件が必要です。 インストールガイド に従って Kiro CLI をインストールする pcs-kiro デモリポジトリ からデモコードをダウンロードする ローカルの AWS 認証情報があることを確認する。 aws sts get-caller-identity を実行して確認できます （オプション） MCP 構成ガイド に従って AWS Knowledge MCP Server を構成する エージェントを使う まず、エージェントを初期化します。Kiro で TODO リスト設定を有効にしておくとよいでしょう。これによりエージェントのより詳細なプランニングが可能になり、クラスターの作成を進める際にタスクのリストを作成し、ステップごとに処理を進めるようになります。 kiro settings chat.enableTodoList true 対話型の PCS デプロイエージェントを起動します。 kiro chat --agent pcs-interactive-agent ディスカバリーフェーズ ここで、エージェントにクラスターの作成を手伝ってもらいます。 User: I am new to PCS. Help me create my first cluster with best practices. （訳: PCS は初めてです。ベストプラクティスに沿って最初のクラスターを作成するのを手伝ってください。） エージェントはまずアクティブな AWS 認証情報を確認し、詳細が不明な場合はいくつかのディスカバリーのための質問を返します。また、既存の環境を調査し、ベストプラクティスに基づいた推奨事項を提示します。これは、既存の VPC やその他の AWS リソースをエージェントに使ってもらいたい場合に役立ちます。 ここで詳細を調整・指定でき、エージェントは最終的なサマリーを作成して、お客様の AWS アカウント内でインフラの作成を開始します。 インフラの作成 以下はインフラ作成プロセスの抜粋です。環境や要件によって、この出力は変わる可能性があります。 Agent: VPC Created:vpc-█████████████████ (10.3.0.0/16) - Public Subnet:subnet-████████████ (10.3.0.0/20) - ログインノード用 - Private Subnet:subnet-████████████ (10.3.32.0/20) - コンピュートノード用 - Internet Gateway:igw-████████████ - NAT Gateway:nat-████████████ (52.38.92.80) - Route Tables:Public (rtb-████████████), Private (rtb-01484185571aabba1) Security Groups Created: - Cluster SG:sg-████████████ (Slurm ポート 6817-6818) - SSH SG:sg-████████████ (SSH ポート 22) IAM Role Created:AWSPCS-scientific-cluster-role - Instance Profile:AWSPCS-scientific-cluster - Policies:AmazonSSMManagedInstanceCore + PCS registration Cluster Created:pcs_xfzpdypb7z (scientific-cluster) - Status:CREATING → エンドポイント取得中 - Size:SMALL (最大 100 ノード、1000 ジョブ) - Slurm Version:24.11 - Controller Endpoint:10.3.45.99:6817 Launch Templates Created: - Compute:lt-████████████ (c6i.xlarge) - Login:lt-████████████ (c6i.xlarge + SSH key) Compute Node Groups Created: - Login Group:pcs_ndgfaikhwl (パブリックサブネット内に 1 台の c6i.xlarge) - Compute Group:pcs_████████████ (プライベートサブネット内に 0〜10 台の c6i.xlarge) - AMI Used:ami-████████████ (Slurm 24.11) - Status:CREATING (3〜5 分かかります) Queue Created:pcs_bogst8bszr (scientific) - Status:CREATING → ACTIVE - Targets:コンピュートノードグループ (pcs_dficwpzin2) - Purpose:科学計算ワークロード インフラの作成が完了すると、エージェントは詳細を提示します。AWS リソースのデプロイが失敗する場合もあります。エージェントに与えられた指示には、そうした問題のトラブルシューティングを行い、処理を続行する前に修正するように記載されています。また、エージェントは /generated ディレクトリにクラスターのサマリーとドキュメントを作成し、何がどのように構築・構成されたかを正確に示します。 完了すると、エージェントはクラスターへの接続方法とテスト方法を示し、コストの見積もりも提示します。 このわずかなやり取りの中で、完全に機能するネットワーク、コントローラー、キュー、コンピュートノードとログインノード、適切なテンプレートとロールを備えた、相応に複雑なアーキテクチャを作成しました。これらすべてを、一般的なニーズとユースケースを定義するだけで実現できたのです。 図 1: Virtual Private Cloud (VPC) 内での AWS Parallel Computing Service (PCS) クラスターのデプロイを示すアーキテクチャ図。 この図では、VPC の外側に配置された PCS コントローラーが PCS キューに接続されています。VPC の内側には 2 つのサブネットがあります。パブリックサブネットには、静的な起動テンプレートを使用する 1 台の c6i.xlarge インスタンスを含むログインノードグループがあり、プライベートサブネットには、動的な起動テンプレートを使用する c6i.xlarge インスタンス（0〜10 台のキャパシティ）を含むコンピュートノードグループがあります。両方のノードグループにはロールの割り当てが含まれ、コンピュートインスタンスや起動テンプレートのシンボルなどの AWS サービスアイコンで表現されています。 これらすべてのプロセスは、ユーザーとのいくつかのやり取りを含めて約 30 分で完了し、すぐにログインしてジョブの実行を開始できます。このアーキテクチャは、共有ストレージや追加のコンピュートノードグループ・キューなどを含むように拡張できます。 推奨されるベストプラクティス エージェントへの指示は、直接的・具体的・明示的に行う 例えば、本記事のアーキテクチャではファイルシステムを要求しませんでしたが、FSx for Lustre 分散ファイルシステムのセットアップを併せて依頼することも簡単にできる可能性があります デプロイをモニタリングし、混乱しているようであればコマンドをキャンセルする 時折の失敗は許容する — エージェントは回復する傾向があります 特定のユースケースに合わせてエージェントの構成をカスタマイズする ワークロードのコンテキストと要件を包括的に提供する 既知の制限事項 エージェントは詳細を見失うことがある — 必要に応じて指示を再度伝えてください 手動での検証が必要 — 結果が要件に合致しているか確認してください まとめ AWS Parallel Computing Service (PCS) は、Slurm クラスターを大規模に運用する際の運用の複雑さを取り除く、フルマネージドな HPC サービスを研究チームに提供します。Kiro CLI のマルチエージェントアーキテクチャと組み合わせることで、チームは本番環境対応の HPC 環境を数週間ではなく数時間でデプロイできるようになります。このアプローチは、基盤となるインフラの管理にかかるオーバーヘッドなしに計算能力を必要とする研究組織にとって、特に価値があります。 それでは、よい構築を！（Happy Building!） 著者について Markus Adhiwiyogo Markus Adhiwiyogo は、Amazon EC2 インスタンスを担当するシニアプロダクトマーケティングマネージャーであり、AWS Graviton、AWS Inferentia、AWS Trainium を含む AWS カスタムシリコンに注力しています。 Kyle Bush Kyle Bush は、AWS のヘルスケア・ライフサイエンスチームでグローバルなヘルスケア ISV を支援するシニアソリューションアーキテクトです。Kyle は、お客様が最新のテクノロジーを活用してデジタルトランスフォーメーションを推進し、ヘルスケアの提供と成果を近代化できるよう支援することに情熱を注いでいます。 Charunethran Panchalam Govindarajan Charunethran Panchalam Govindarajan は、AWS のシニアプロダクトマーケティングマネージャーであり、ハイパフォーマンスコンピューティングと量子テクノロジーに注力しています。彼は幅広いテクノロジー領域で活躍してきましたが、特に R&D と製品開発の交差点に関心を持っています。Charunethran はスタンフォード大学で電気工学の修士号を取得しています。仕事以外では、スケッチや哲学的な会話を楽しんでいます。 Kareem Abdol-Hamid Kareem は、スタートアップ向けのシニアアクセラレーテッドコンピュートスペシャリストです。アクセラレーテッドコンピュートのスペシャリストとして、Kareem は生成 AI、ハイパフォーマンスコンピューティング、超大規模ワークロードに関する新たな課題に日々取り組んでいます。余暇にはピアノを演奏し、ビデオゲーム『ストリートファイター』で腕を競っています。 翻訳はソリューションアーキテクトの 山田航司 が担当しました。原文は こちら です。

2022年にスタートし、毎年全国の地域を巡ってきた「AWS デジタル社会実現ツアー」が今年で 5年目 を迎えます。2026年は 全国8都市（北海道・宮城・新潟・静岡・愛知・広島・愛媛・福岡）  を約2週間で巡り、最新のAI・クラウド技術と、地域の未来を動かすプログラムをお届けします。 本イベントでは、AIやクラウドの「今」と「これから」を一日で体感できる多彩なセッションをご用意しました。 いま注目のAIエージェント技術をデモを交え、わかりやすく解説。続いて、地域企業のAI/クラウド活用事例を当事者が語ります。社会課題に挑んだ学生コンテスト入賞者のプレゼンテーション、自治体・地銀・大学・AWSパートナーが地域のAI活用の未来を議論する産学官金パネルディスカッションも開催。さらに経済産業省「GENIAC PRIZE」による懸賞金企画の最新情報もお届けします。 開催日程・会場など 日程 県道 会場 申込リンク 8/18（火） 北海道 DO-BOX EAST アジェンダおよびお申し込みはこちら 8/19（水） 新潟 NINNO3 アジェンダおよびお申し込みはこちら 8/20（木） 静岡 M20 アジェンダおよびお申し込みはこちら 8/21（金） 愛知 中日ホール＆カンファレンス アジェンダおよびお申し込みはこちら 8/25（火） 広島 エディオンピースウイング広島 アジェンダおよびお申し込みはこちら 8/26（水） 愛媛 E:N BASE アジェンダおよびお申し込みはこちら 8/27（木） 福岡 Growth1 アジェンダおよびお申し込みはこちら 8/28（金） 宮城 せんだいメディアテーク アジェンダおよびお申し込みはこちら ※ 会場によって時間が異なりますのでご注意ください。 ※参加無料・事前登録制です。 こんな方におすすめ AI・クラウドの最新情報を効率よくキャッチアップしたい方 地域でのDX推進・AI導入に関心のある経営者・自治体関係者 AI活用の先行事例を知りたい方 地域の産学官金ネットワークを広げたい方 学生AIコンテストの成果に興味がある教育関係者   主催・共催 主催：アマゾンウェブサービスジャパン合同会社 共催：共同通信社、河北新報 後援・協力：広島県、愛媛県、仙台市、名古屋市、北海道新聞、 新潟日報、 静岡新聞、 中日新聞、 中国新聞、 愛媛新聞、 西日本新聞 皆さまのご参加を心よりお待ちしております。ふるってお申し込みください！  

2026 年 7 月 6 日に公開された “ Announcing support for VCF 9.0 and 9.1 on Amazon EVS ” を翻訳したものです。 VMware Cloud Foundation (VCF) 9.0 および 9.1 が Amazon Elastic VMware Service (EVS) で利用可能になり、VCF インストールを完全に制御できるようになったことをお知らせいたします。Amazon EVS における私たちの焦点は、お客様が現在お持ちのツール、運用プロセス、スキルを使用して、ニーズに合わせて VCF をデプロイおよび構成できる柔軟性を提供することです。 Amazon EVS での VCF 9 エクスペリエンス VCF 9.x では、AWS インフラストラクチャのプロビジョニングを VCF ソフトウェアから分離します。Amazon EVS は、ESX 9.x を実行する EC2 ベアメタルインスタンスをお客様の Amazon Virtual Private Cloud (VPC) にデプロイし、VCF デプロイメントのアンダーレイとして機能するプライベート VLAN に接続します。そこから、Broadcom の VCF Installer をダウンロードしてデプロイし、Broadcom のネイティブワークフローを使用して VCF インストールを完了します。 評価モードでの VCF 9.x のデプロイ VCF 9.x を有効化する一環として、Amazon EVS は VCF 評価モードをサポートするようになりました。ライセンスキーを事前に提供することなく、EVS 環境を作成して VCF のデプロイを開始できます。これにより、サブスクリプションを適用してワークロードの移行を開始する前に、環境を構築し、設計を検証し、実装をテストする余地が生まれます。評価モードを超えて使用する際には、適切な VCF サブスクリプションカバレッジを維持する責任はお客様にあります。 Solutions for EVS GitHub リポジトリ エンドツーエンドのデプロイをより簡単にするため、開始を支援するサンプル、テンプレート、Infrastructure as Code アーティファクトを含む新しい Solutions for EVS GitHub リポジトリ を公開します。今後、このリポジトリを拡張し、追加のリファレンスアーキテクチャ、新しいベアメタルインスタンスおよびストレージ構成、ネイティブ AWS サービス統合を含める予定です。AWS CloudFormation や HashiCorp Terraform などの Infrastructure as Code ツールを使用している場合、これらのアーティファクトを、AWS インフラストラクチャから稼働中の VCF 環境までの経路を自動化するための基盤として使用できます。 EVS コネクタを使用した VCF の接続 VCF がインストールされ、VCF 管理アプライアンスに到達可能になったら、2026 年 4 月に Windows Server ライセンス機能 で初めて導入した EVS コネクタ を使用して、VCF デプロイメントを Amazon EVS コントロールプレーンに接続します。コネクタは、AWS Secrets Manager に保存された認証情報を使用して、EVS から VCF 管理アプライアンスへの永続的で認証された接続です。この接続により、EVS はお客様のデプロイメントを継続的に把握し、VCF ソフトウェアの運用上に介在することなく、環境状態の監視、Windows ライセンスエンタイトルメントの有効化、ライセンス使用状況のレポートを可能にします。 クラウドへのファーストパス 多くのお客様にとって、Amazon EVS はクラウドへ移行する最も高速な方法の 1 つであり、特にデータセンター契約の満了やインフラストラクチャの更新サイクルといった時間的制約に直面している場合に有効です。 Aeroméxico のようなお客様は、最大のメリットは VMware ワークロードを AWS へいかに迅速かつ容易に移行できるかにあると語っています。オンプレミスと同じように VCF をデプロイ、構成、運用することで、ソース環境とデスティネーション環境のアーキテクチャ上の差異を最小限に抑え、大規模な移行を簡素化・加速できます。 速度と制御の組み合わせこそが、今回のリリースの本質です。Amazon EVS 上の VCF 9.x は、最新の VMware Cloud Foundation ソフトウェアを現在と同じ方法で実行できる能力を提供しながら、AWS グローバルインフラストラクチャのスケールと信頼性を兼ね備えています。組織で VMware を使用している場合、私たちは Amazon EVS が VMware ベースのワークロードを実行する世界最高の場所となることを目指しています。 Amazon EVS の詳細については、 製品詳細ページ および ユーザーガイド をご覧ください。 著者について Andy Reedy Andy Reedy は EC2 Commercial Applications のシニアプロダクトマネジメントマネージャーで、VMware、SAP、Red Hat OpenShift ワークロードに注力するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェアにおいて 25 年以上の経験を持ち、お客様のビジネスクリティカルなアプリケーションの移行とモダナイゼーションを支援することに情熱を注いでいます。 Spiros Tsitsonis Spiros Tsitsonis は AWS のシニアテクニカルプロダクトマネージャーで、インフラストラクチャ移行と Amazon Elastic VMware Service に注力しています。以前は Amazon Elastic Container Service とサーバーレスの Fargate チームを管理しており、AWS サービスを使用してお客様がビジネス成果を達成できるよう支援することに情熱を注いでいます。休日は、旅行やさまざまな場所、人々、文化を体験することを楽しんでいます。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。

本記事は 2026 年 6 月 16 日 に公開された「 Modernize Amazon Redshift: RA3 to RG Migration best practices 」を翻訳したものです。 Amazon Redshift は、フルマネージドで AI を活用したクラウドデータウェアハウスです。数万のお客様がエクサバイト規模のデータを業界最高水準のコストパフォーマンスで分析しています。Amazon Redshift は Amazon SageMaker Unified Studio でレイクハウス全体にわたる SQL 分析を提供し、複数のソースからのデータを統合します。 Zero-ETL 統合により、ストリーミング、データベース、エンタープライズアプリケーションを接続して複雑なパイプラインを排除し、ほぼリアルタイムのインサイトを得られます。 2026 年 5 月 12 日、Amazon Redshift はプロビジョンドノードの新世代である Graviton ベースの RG インスタンス をリリースしました。RG インスタンスは、 RA3 インスタンスと比較して、データウェアハウスワークロードで最大 2.2 倍、データレイクワークロードで最大 2.4 倍高速で、vCPU あたりの価格は 30% 低くなっています。RG インスタンスは RA3 がサポートするすべてのデータレイクフォーマットをサポートし、 Amazon Redshift Spectrum の TB あたりのスキャン料金が不要になります。 本記事では、Amazon Redshift RA3 クラスターを Graviton ベースの RG インスタンス に移行する方法を説明します。Elastic Resize、Classic Resize、Snapshot/Restore の 3 つの移行戦略を比較し、スムーズな移行に向けた考慮事項とベストプラクティスを紹介します。また、RA3 から RG へのノードマッピングガイダンスも紹介します。 RG への移行対象 すべての RA3 のお客様に、コストパフォーマンスを最大化するため RG への移行を推奨します。RG は RA3 と比較して、コンピューティング集約型と I/O 集約型の両方のワークロードでパフォーマンスが向上するよう設計されており、ワークロードパターンを問わず性能向上が期待できます。Amazon Redshift Graviton RG インスタンスは前世代の RA3 インスタンスと機能パリティを維持しており、機能を失わず移行できます。 RG ノードタイプ RG インスタンスファミリーには現在 2 つのノードタイプがあります。次の表に RG インスタンスタイプ、ハードウェア仕様、対応する RA3 ノードタイプを示します。RA3 からの移行時のサイジング判断に活用してください。 ノードタイプ 構成 vCPU メモリ 最大ストレージ/ノード ノード範囲 ステータス RA3 相当 RG.xlarge マルチノード 4 32 GB 16 TB 2-32 GA (05/12/2026) RA3.xlplus と直接対応 RG.4xlarge マルチノードのみ 16 128 GB 128 TB 2-64 GA (05/12/2026) RA3.4xlarge と比較して vCPU とメモリが 1.33 倍 注意 : 今後、Amazon Redshift ワークロードに最適なコストパフォーマンスを提供するため、追加のインスタンスタイプのサポートを拡大する予定です。 インスタンスタイプの詳細については、 Amazon Redshift のドキュメント を参照してください。 RA3 から RG へのノードマッピング 現在のノードタイプ ノード範囲 推奨 RG タイプ 推奨 RG ノード数 RA3.xlplus 1-32 RG.xlarge 1:1 マッピング（同じノード数） RA3.4xlarge 2 RG.4xlarge RA3.4xl 2 ノードに対して RG.4xl 2 ノード RA3.4xlarge 3-64 RG.4xlarge RA3.4xl 4 ノードに対して RG 3 ノード（偶数に切り上げ） 注意 : これらは初期の推奨値です。ワークロードによっては、ターゲット RG ノード構成の調整が必要です。ターゲット構成を確定する前に、下位環境でワークロードをテストしてパフォーマンスを検証してください。本番ワークロード全体をテストするには、 Amazon Redshift Test Drive ユーティリティ も使用できます。 マッピングの考慮事項: RG ファミリー内では、RG.4xlarge 1 ノードは RG.xlarge 4 ノードに相当します。 RG ノードタイプの選択: Amazon Redshift クラスターのサイジングでは、少数の大きなノードと多数の小さなノードのどちらを使うかが重要な判断ポイントです。RG ノードタイプ間の主な差別化要因はローカル SSD キャッシュ容量です。大きなノードはノードあたりのローカルキャッシュが多く、マネージドストレージからのデータ読み込みが減り、I/O 集約型クエリの性能が向上します。 次のようなワークロードでは、大きなノードタイプを検討してください: 大量のディスクスピル – メモリを超える中間結果セットが生じる複雑なクエリ。 リーダーノード負荷の高い処理 – 多数の同時クライアント接続、多数の結合やサブクエリを含む複雑なクエリコンパイル、または負荷の大きい最終段階の集約処理。 大量の頻繁にアクセスされるデータ – ローカル SSD キャッシュの活用でマネージドストレージからの読み込みを抑えたいホットデータセット。 大きな結果セット – クライアントアプリケーションに大量のデータを返すクエリ。 頻繁なメタデータ操作 – カタログルックアップの多いワークロードや、多数の小バッチでの CURSOR ベースのフェッチ。 前提条件 本記事の手順には、以下が必要です。 RA3 ノードタイプで稼働中の Amazon Redshift クラスター。 リサイズ操作に必要な AWS Identity and Access Management (IAM) アクセス許可（ redshift:ResizeCluster 、 redshift:DescribeClusters ）。 AWS CLI のインストールと設定（CLI ベースの移行の場合）。 Classic Resize を使用する場合、10 時間以内の最新の手動スナップショット。 既存データに対するターゲット RG 構成の十分なストレージ容量。 移行方法 次の図は、3 つの移行アプローチを比較したものです。 1. Elastic Resize（推奨） Elastic Resize は、ターゲットの RG ノード構成が Elastic Resize のサポート範囲内にある場合に、ノードアップグレードの推奨方法です。ノードタイプの変更（例: RA3 から RG）やノードの追加・削除に使用できます。 Elastic Resize を実行すると、Amazon Redshift はまずソースクラスターのスナップショットを作成します。スナップショットの最新データを使用して新しいターゲットクラスターがプロビジョニングされ、バックグラウンドでデータが新しいクラスターに転送されます。この間、データは読み取り専用になります。リサイズが完了に近づくと、Amazon Redshift はエンドポイントを新しいクラスターに向けて更新し、ソースクラスターへのすべての接続を切断します。障害が発生しても、ほとんどの場合は手動介入なしに自動ロールバックされます。 利点 平均約 10〜15 分で完了します。最初の選択肢として推奨します。 リサイズ中もクラスターが読み取り専用で利用できるため、ダウンタイムが最小限です。 クラスターエンドポイントが変わらないため、接続文字列の変更が不要です。 オンデマンドで実行するか、メンテナンスウィンドウ中にスケジュールできます。 考慮事項 プロデューサークラスターでノードタイプを変更する Elastic Resize では、接続が新しいターゲットクラスターに切り替わる間、データ共有が利用できなくなります。 ターゲットノード構成に既存データ用の十分なストレージがあることを確認してください。 Elastic Resize で対応できないターゲット構成もあります。その場合は Classic Resize または Snapshot/Restore を検討してください。 Elastic Resize 操作は開始後にキャンセルできません。 データスライスは変更されません。データや CPU のスキューが発生する可能性があります。 Elastic Resize は AWS マネジメントコンソールまたは AWS CLI で開始できます。 コンソールでクラスターをリサイズする手順 AWS マネジメントコンソールにサインインします。 https://console.aws.amazon.com/redshiftv2/ で Amazon Redshift コンソールを開きます。 左側のナビゲーションメニューで Provisioned clusters を選択します。 リサイズするクラスターを選択します。 Actions で Resize を選択します。 Resize cluster ページが表示されます。 Resize cluster ページで、リサイズタイプとして Elastic resize (recommended) を選択します。 New configuration で、ノードタイプ（例: rg.4xlarge ）を選択します。 ノード数を入力します。 選択内容に応じて、 Resize now または Schedule resize を選択します。 AWS CLI でクラスターをリサイズする手順 # Initiate an Elastic Resize to upgrade from RA3 to RG node type aws redshift resize-cluster \ --cluster-identifier <my-RA3-cluster> \ # Source cluster ID --node-type rg.4xlarge \ # Target RG node type --number-of-nodes <#nodes> \ # Target node count --no-classic # false = Elastic Resize 2. Classic Resize Classic Resize は、クラスターサイズやノードタイプの変更が Elastic Resize でサポートされていない場合に推奨されます。シングルノードからマルチノードへの変換にも必要です。 Classic Resize を実行すると、Amazon Redshift はターゲットクラスターを作成し、バックアップとリストアでソースクラスターからデータとメタデータを移行します。データベーススキーマやユーザー設定を含むすべてのデータが正確に転送されます。ソースクラスターは最初に再起動され、数分間利用できなくなります。その後、クラスターは読み書き可能な状態になり、リサイズはバックグラウンドで続行されます。 Enhanced Classic Resize は 2 つのステージで構成されます: ステージ 1（クリティカルパス）: ソースクラスターからターゲットクラスターへのメタデータの移行。このステージ中、ソースクラスターは読み取り専用モードになります。通常、非常に短い時間です。その後、クラスターは読み取りと書き込みクエリで利用可能になります。KEY ディストリビューションスタイルのすべてのテーブルは一時的に EVEN ディストリビューションで保存され、ステージ 2 で KEY スタイルに再配分されます。 ステージ 2（オフクリティカルパス）: 以前のディストリビューションスタイルに従ったデータの再配分。バックグラウンドで実行されます。所要時間はデータ量、クラスターワークロード、ノードタイプによって異なります。 詳細については、「 Accelerate resizing of Amazon Redshift clusters with enhancements to classic resize 」を参照してください。 利点 すべてのターゲットノード構成をサポートします。 ソースクラスターを柔軟に再構成できます。 データスライスをノードあたりのデフォルトにリバランスし、ノード間で均等なデータ分散を実現します。 考慮事項 ソースクラスターのデータサイズが 2 PB 未満である必要があります。2 PB を超えるデータには Snapshot/Restore アプローチを使用してください。 開始前に 10 時間以内の手動スナップショットがあることを確認し、なければ新たに取得してください。 Classic Resize に使用されたスナップショットは、テーブルリストアやその他の目的には使用できません。 クラスターは Virtual Private Cloud (VPC) 内にある必要があります。 リサイズ中はクエリの完了に時間がかかる場合があります。Concurrency Scaling の有効化を検討してください。 Classic Resize の前に不要なテーブルを削除すると、データ分散が高速化されます。 Classic Resize は Elastic Resize よりも完了までに時間がかかります。 リサイズ操作をオフピーク時間帯またはメンテナンスウィンドウ中にスケジュールしてください。 Classic Resize はコンソールまたは次の AWS CLI コマンドで開始できます。 コンソールで Classic Resize を実行するには、前述のリサイズ手順で次のスクリーンショットのように Classic resize を選択します。 AWS CLI による Classic Resize # Initiate Classic Resize via AWS CLI aws redshift resize-cluster \ --cluster-identifier <my-ra3-cluster> \ # Source cluster ID --node-type rg.4xlarge \ # Target RG node type --number-of-nodes <#nodes> \ # Target node count --classic # true = Classic Resize プロビジョンドクラスターの Classic Resize（KEY ディストリビューションを含む）の進捗を監視するには、 SYS_RESTORE_STATE を使用します。変換中のテーブルの完了パーセンテージが表示されます。アクセスにはスーパーユーザー権限が必要です。 Elastic Resize と Classic Resize の比較 動作 Elastic Resize Classic Resize システムテーブル Elastic Resize はシステムログデータを保持します。 Classic Resize はシステムテーブルとデータを保持しません。 ノードタイプの変更 ノードタイプが変わらない場合、Elastic Resize はインプレースリサイズとなり、ほとんどのクエリは保持されます。新しいノードタイプを選択した場合、新しいクラスターが作成され、リサイズ完了時にクエリが切断されます。 新しいクラスターが作成されます。リサイズ中にクエリが切断されます。 セッションとクエリの保持 Elastic Resize は、ソースとターゲットのノードタイプが同じ場合、セッションとクエリを保持します。新しいノードタイプを選択した場合、クエリは切断されます。 Classic Resize はセッションとクエリを保持しません。クエリが切断され、パフォーマンスの低下が予想されます。使用量の少ない時間帯にリサイズを実行してください。 リサイズ操作のキャンセル Elastic Resize はキャンセルできません。 RG または RA3 クラスターへの Classic Resize はキャンセルできません。 3. Snapshot, Restore, Resize 移行中もほぼ常時書き込みアクセスが必要な場合や、既存クラスターに影響を与えず新しい RG セットアップを検証したい場合に使用します。 手順 Amazon Redshift コンソールで Provisioned clusters dashboard を選択し、ソースクラスターを選択して Actions から Create manual snapshot を選択します。スナップショット名を指定して Create snapshot を選択します。 スナップショットを選択します。 Restore from snapshot を選択します。 クラスター ID と構成（ターゲットクラスター）を指定します。 次の手順でターゲットクラスターにデータが存在することを確認します: 新しいエンドポイントを使用してターゲットクラスターに接続します。 主要なテーブルに対して SELECT COUNT(*) FROM <table_name> を実行し、ソースクラスターとカウントを比較します。 すべてのスキーマが存在することを確認します。 ユーザー権限が正しくリストアされたことを検証します。 スナップショット取得後にソースクラスターにデータを書き込んだ場合は、手動でターゲットクラスターにデータをコピーします。 アプリケーションの接続文字列を新しいクラスターエンドポイントに更新します。 利点 既存クラスターに影響を与えずに新しい RG セットアップを検証できます。 異なるリージョンやアベイラビリティーゾーンへのリストアが柔軟に行え、追加の災害復旧オプションを提供します。 クラスターが書き込み操作で利用できない時間を最小限に抑えます。 考慮事項 クラスターのセットアップとデータリストアは Elastic Resize より時間がかかることがあります。 スナップショット後にソースクラスターへ書き込まれたデータは、手動でターゲットにコピーが必要です。 新しいエンドポイントが作成されるため、接続文字列の変更が必要です。 エンドポイントを維持するには、ターゲットクラスターがソースクラスターと同じ名前になるように 両方のクラスターの名前を変更する ことを検討してください。 フォールバック 同じ移行アプローチでいつでも RA3 に戻せます。 移行時の DMS、Zero-ETL、データ共有に関する考慮事項 Amazon Redshift クラスターが AWS Database Migration Service (AWS DMS) のターゲット、Zero-ETL 統合のターゲット、またはデータ共有のプロデューサーとして使用されている場合、RA3 から RG へのリサイズ時に以下の点に留意してください。 AWS DMS の変更データキャプチャ (CDC) タスクはリサイズの影響を受けません。レプリケーションインスタンスは独立して動作し、クラスター復帰後に書き込みを再開します。タスクの再起動は不要です。 Zero-ETL テーブルはリサイズ中に一時的に利用できなくなり、再同期状態になります。再同期にかかる時間はデータ量に依存します。 svv_integration_table_state を使用して、すべてのテーブルが Synced に戻ったことを確認してください。詳細については、「 Zero-ETL considerations 」を参照してください。 プロデューサークラスターをリサイズすると、接続が新しいクラスターに転送される間、 データ共有 が一時的に利用できなくなります。通常、数分間です。この間、コンシューマークラスターは共有データにアクセスできません。リサイズ完了後、データ共有は再設定不要で自動的に再開します。リサイズ対象のプロデューサーに依存するコンシューマーワークロードには、短いメンテナンスウィンドウを計画してください。 Snapshot/Restore が DMS、Zero-ETL、データ共有に与える影響 Zero-ETL 統合は元のクラスターに紐づいています。リストア先は新しいクラスターとして扱われるため、レプリケーションは自動再開されません。リストア後、新しいクラスターを指す Zero-ETL 統合を再作成する必要があります。初回同期が実行され、データが最新の状態になります。 AWS DMS 接続はエンドポイントベースです。リストア先は新しいエンドポイントになるため、AWS DMS タスクは自動接続しません。リストア後、AWS DMS エンドポイント設定を新しいアドレスに更新し、タスクを再起動してください。 データ共有はクラスターの名前空間に紐づいています。リストア先は異なる名前空間になるため、既存のデータ共有は引き継がれません。プロデューサー側は、新しいデータ共有を作成してコンシューマーと再共有する必要があります。コンシューマー側は、プロデューサーが新しいクラスターから共有を再確立するまでアクセスできません。 移行のベストプラクティス 移行前に、データ共有のコンシューマー、Zero-ETL アプリケーション、BI/ETL パイプラインなど下流チームに通知してください。 本番環境への影響を軽減するため、メンテナンスウィンドウ中に移行をスケジュールしてください。 リサイズ開始前に手動スナップショットを取得し、ロールバックポイントとして確保してください。 本番環境を移行する前に、代表的なワークロードでターゲットの RG 構成をテストしてください。 完了後に下流のアプリケーションが正常に動作していることを確認してください。 クリーンアップ 不要な課金を防ぐため、テスト用の RG クラスターと移行テスト中に作成した手動スナップショットを削除してください。クラスター削除時はすべてのデータが完全に消去されます。テストクラスターのみを削除していることを確認してください。テストデータを保持する必要がある場合は、削除前に最終スナップショットの取得を検討してください。 まとめ 本記事では、Amazon Redshift RA3 インスタンスから Graviton ベースの RG インスタンスへのアップグレードに関する移行オプション、考慮事項、ベストプラクティスを説明しました。RG のパフォーマンス上のメリットの詳細については、 発表ブログ記事 を参照してください。 本記事のガイダンスを参考に、今すぐ Amazon Redshift RG インスタンス へのアップグレードを開始して、コストパフォーマンスの向上を活用してください。アーキテクチャのサポートや概念実証 (POC) の支援については、 AWS Support にお問い合わせください。 著者について Nita Shah Nita は AWS のシニアアナリティクススペシャリストソリューションアーキテクトで、ニューヨークを拠点としています。20 年以上にわたりエンタープライズデータプラットフォーム、データウェアハウジング、アナリティクスソリューションの構築に携わり、Amazon Redshift を専門としています。エンタープライズ規模の Well-Architected なアナリティクスおよび意思決定支援プラットフォームの設計・構築を支援しています。 Ankit Sahu Ankit は革新的なデータ製品とサービスの構築において 18 年以上の経験を持ちます。プロダクト戦略、Go-to-Market の実行、デジタルトランスフォーメーションなど多様な経験があります。現在は AWS のシニアプロダクトマネージャーとして、Amazon Redshift のビジョンと戦略を推進しています。 Vinayaka Gangadhar Vinayaka は Amazon Web Services（AWS）のアナリティクススペシャリストです。スケーラブルなデータプラットフォームの構築・トラブルシューティングや、AWS の分析サービスを活用した有意義なインサイトの導出を通じてお客様を支援しています。Amazon Redshift とAmazon OpenSearch に深い専門知識を持っています。複雑な分析課題に取り組んでいないときは、新しいテクノロジーの探求や家族との時間を楽しんでいます。 Ricardo Serafim Ricardo は AWS のシニアアナリティクススペシャリスト Solutions Architect です。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

はじめに エムシーディースリー株式会社様（MCD3：以下同社）は、三菱商事グループの一員として、AI・デジタル技術を活用したオペレーティングモデルを構築することで顧客価値の最大化を目指し、社会課題の解決に取り組まれています。 同社では、建設業界向けの Vertical SaaS「 グリーンサイト 」「 ワークサイト 」や、流通・食品を取り扱う小売業界向けに特化した、マーケティングDXサービス「 cacicar（カシカル） 」など、複数の事業領域で産業DXを推進されています。三菱商事グループの持つ幅広い産業ネットワークと、AI・データサイエンスの専門性を掛け合わせ、各産業に特化したデジタルプロダクトを通じて顧客企業のオペレーション変革を実現されています。 同社では、プロダクトの急成長に伴い、開発生産性の抜本的な向上という課題への取り組みとして生成AIの活用にも注力されています。本ブログでは、2026年6月8日から10日の3日間にわたり実施された AI 駆動開発ライフサイクル（AI-Driven Development Life Cycle、略称 AI-DLC）Unicorn Gym について、その実施内容と成果を紹介いたします。 開発生産性向上への課題とこれまでの取り組み 同社のプロダクト群 同社が開発・運用するプロダクト群は多岐にわたります。 建設業界向けプロダクト グリーンサイト — 建設現場の労務安全書類をクラウドで一元管理するSaaS。元請け・協力会社間の書類やり取りをデジタル化し、建設業界の生産性向上と安全管理の高度化を支援。全国数万の建設現場で利用されている業界スタンダードのプラットフォーム。 ワークサイト — 建設現場の施工管理・工程管理を支援するSaaS。現場の進捗状況のリアルタイム共有、帳票作成・カスタマイズ、作業員の入退場管理など、現場業務のデジタル化を包括的にサポート。 流通・小売業界向けプロダクト cacicar（カシカル） — 食品を取り扱う小売業界向けに特化した、マーケティングDXに関わる多様な機能を有するクラウドサービスです。データ分析機能（cacicarBI）／1to1マーケティング機能（cacicarMA）／お客様向けアプリ（cacicarCommu）を提供。 直面していた課題 これらのプロダクトが成長し利用者が拡大する一方で、開発生産性の向上が不可欠でした。 主な課題 機能カスタマイズ要望の開発リードタイムが長い — 複数のお客様の要望を広く満たせるほど機能の柔軟性が高くない レガシーワークロードのモダナイゼーションが不十分 — グリーンサイトの基盤アプリケーションをコンテナ環境へ移行できていない 運用業務の属人化 — 一部業務で多くの関係者が手動対応しており、オペレーションミスが発生しやすい状況にあった 新規プロダクト開発への挑戦 — AIネイティブな新サービスプロダクトの構想があり、開発機会を求めていた こうした課題を解決し、生産性向上を実現するためには、従来の延長線上の改善ではなく、開発プロセスそのものを根本的に変革する新しいアプローチが必要でした。 AI-DLC：新しいアプローチ このような課題に対し、同社はAI-DLCを実践しました。AI-DLC は、コーディング支援にとどまらず、要件定義からリリースまでの開発プロセス全体に AI を深く組み込む開発手法です。AI-DLC の詳細については、 解説ブログ をご覧ください。 お客様に AI-DLC を体験いただくにあたり、AWS は「AI-DLC Unicorn Gym」という体験型プログラムを提案しました。これは、AI-DLC を組織の特徴やニーズに合わせてカスタマイズし、実際のプロダクト開発を通じてその効果を検証するプログラムです。 AI-DLC Unicorn Gym の実施と成果 実施概要 今回の AI-DLC Unicorn Gym では、同社から 7つの異なるチーム が参加し、それぞれが実際のプロダクトや業務課題に対して AWSのAIエージェントであるKiroを使ってAI-DLC の手法を適用しました。エンジニアだけでなく、ビジネス部門のメンバーも参加し、3日間で実際に動くプロダクトの開発に挑戦しました。 参加チームとテーマ チーム名 人数 取り組み内容 成果 グリーンサイトチーム 4名  業務の一部自動化ツール作成（手動オペレーション・属人化の解消）  マスターデータ自動取得、PDF→CSV変換、重複チェック、SQL自動生成を実装。属人化していたID採番ルールを明文化 グリーンサイト インフラチーム 3名  グリーンサイトの AWS 稼働環境のモダナイゼーション（最小構成での検証）  既存アプリのコンテナ化完了。AWS環境デプロイ・ブラウザ操作確認まで達成。ローカル環境ワンコマンド起動も完成 DataHub チーム 4名 エンジニアだけでなくビジネスサイドも気軽にグリーンサイトの環境を立ち上げ・削除できるワンコマンド構築ツールの開発  Docker Composeワンコマンド起動を実現。テーブル自動作成、ログイン・操作確認まで達成 CTO室チーム 5名 新プロダクト SaaS のフルスクラッチ開発（マルチテナント対応、ガントチャート、リアルタイム共同編集）  3日目だけで219コミット・20件超のPR。ガントチャート、リアルタイム共同編集、AI自然言語工程修正など高度機能を実装しデモ可能な状態に BD部チーム 5名 AIで業務を効率化する新プロダクト開発（過去案件のナレッジDB化＋ベクトル検索による類似案件検索・見積もり支援） 5ユニット完成・16PR作成。Next.js/PGVector/Bedrockフルスタックアプリ構築。App Runnerデプロイまで完了 cacicarチーム 3名 Amazon Personalizeを活用したリコメンドAPIの開発、および iPad 会員入会フォームWebアプリの開発 リコメンドAPIの設計・実装完了、入会フォームWebアプリをローカル動作確認まで完了。本番運用アーキテクチャ（DynamoDBキャッシュ方式）を確立 ワークサイトチーム 6名 新規機能の開発（お客様にてカスタマイズ可能となるよう機能の拡張）  エクセル取込→マッピング→プレビュー出力のUIモック完成。ユーザーストーリー整理・詳細設計完了 各チームのAI-DLC Unicorn Gym からの学び 最終日には成果発表会を開催し、各チームからAI-DLC Unicorn Gymを通じて得られた学びを共有いただきました。 AI-DLCの醍醐味である要件定義からAIに委ねる手法を取り入れたことで、「人間は判断・方向性決定・レビューに集中することができた。」という声や、「暗黙知がAIへのインプットを通じて明文化し、要件に落とし込むことができた。」というコメントをいただきました。 全チームが対面で集まり実施できたことで、AIの実装待ち時間を活用して仕様確認や議論ができること、リアルタイムでのフィードバックが可能なこと、複数部門のドメイン知識を即座に引き出せること、ユニット分割により2名以上が同時にユニットを並列実装し、3日間という短期間で商用レベルに近いアプリケーションを構築できることが大きな利点として挙げられました。 また各チームが、AIによる開発生産性を最大化するために、以下のような工夫をして活用されていたことも印象的でした。 HTMLモックで事前にUI合意を得て、共通仕様（ドメインモデル・API仕様）も最初に固めたことで翌日からの並列開発を可能にする 複数の案がある時は、それぞれのメリットとデメリットも一緒に出させることで、チーム内の意思決定を高速化させる 人間が軌道修正に介在する手間を減らすために、レビュー専用のAIを導入し、要件充足を自動チェックする仕組みを入れ込む 今後の展望 同社では、今回の AI-DLC Unicorn Gym の成果を踏まえ、以下の取り組みを進められる予定です。 1. 各チームの成果物のブラッシュアップと本番環境への適用 2. AI-DLC の他プロジェクトへの適用 3. AIの活用拡大による開発速度と品質の両立 まとめ エムシーディースリー株式会社様との AI-DLC Unicorn Gym は、実際のプロダクト開発・業務改善に取り組むという大規模な実践の場となりました。 特筆すべきは、単にAIでコードを生成するだけでなく、 要件定義からアーキテクチャ設計、実装、テスト、デプロイまでの開発ライフサイクル全体 でAIを活用し、従来数か月かかっていた開発を3日間で実現可能なレベルまで圧縮できることを実証した点です。 今回の取り組みについて、同社の本間 嗣崇様は、 「今回のAI-DLC Unicorn Gymでは、グリーンサイトやcacicarなど実際のプロダクト課題に7チームで同時に挑み、3日間でここまで形にできたことに正直驚いています。Kiroを中心としたAI-DLCという開発手法を体験する場を提供いただいたAWSの皆様に感謝します。”コードを書く”から”意図を伝える”へという開発体験のシフトは、私たちエンジニアの働き方を根本から変える可能性を感じました。この体験を社内で広げ、各プロダクトの現場へ着実に展開していくことが、次のステップだと捉えています。」 とコメントしています。 著者について エムシーディースリー株式会社 エンジニアリング部 チームリード グループマネージャー エンジニアリングマネージャー 本間嗣崇 新卒でSI会社へ入社し、一貫してシステム開発に携わる。 2019年より大手通信会社へ転職後も複数のBtoCシステム開発に従事。主に新規システム構築に強みを持つ。 その後、ソフトウェアエンジニアとして旧エムシーデジタル(現 MCD3)に入社​へ入社。 入社後は物流最適化、プロダクト開発、LLM を活用した SaaS システムの開発など多岐にわたって開発を推進。ビジネス検討から運用・問い合わせ窓口、また開発プロセスの最適化も行うフルスタックエンジニア 兼 エンジニアリングマネージャー。 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 三宅穂波 主に商社業界、サービス業界のお客様に対して技術支援しています。好きなサービスはAmazon Quick、GlueなどのAnalyticsサービスです。

はじめに Q. 日々、テレビでながれる、国会における国会議員と大臣の議論。霞が関では多くの国家公務員が夜遅くまで働いていますが、国会での議論に先立って、どのような業務が行われているかご存知でしょうか？ A. 様々ありますが、その主な業務の一つが、国会において想定される質問と、それに対する回答案や関連情報をまとめた資料（想定問答）を作成することです。 国会答弁は、国民及び国民の代表である国会議員に対して、政府の政策や方針、予算について国会で説明し、行政の透明性と説明責任を果たすためのものです。その質を支えるのが、国会答弁の想定問答作成業務であり、正確性や首尾一貫性などが厳しく求められる重要度の高い業務となっています。それゆえに職員の負担も大きく、 昨今の公務員の働き方改革や生成 AI 技術の急速な発展も相まって、本業務のさらなる高度化・効率化への期待が高まっています。AWS はとある省庁のシステム担当部局と、この想定問答の作成・審査業務における、 AI を活用した高度化・効率化の可能性を検討してきました。本稿では、AWS の公共部門のアカウントチームおよびプロトタイピングチームが伴走し、省庁が組織内に持つ過去の想定問答ファイルを横断検索しながら、AI による想定問答のドラフトの生成や、人の手による修正を含む審査プロセスを支援する AI アプリケーションを構築した取り組みをご紹介します。 プロトタイピングチームについて AWS パブリックセクタープロトタイピングチームは、公共・教育・医療・NPO などの分野のお客様が抱える課題の解決を無償で支援・加速するチームです。プロトタイピングという名前の通り、お客様の「実現したいこと」を、実際に動作するプロトタイプとして形にし、お客様に（技術）提供することで課題解決のご支援を行っています。 背景と課題 国会答弁のための想定問答を作成する際には、過去に作成した想定問答ファイルや国会会議録を、限られた時間の中で正確に参照する必要があります。しかし、参照すべき文書や資料の候補は大量にあり、検索対象も複数あることなどから、極めて限られた時間の中で、必要な情報に素早くたどり着くこと自体、容易ではないケースが多々あります。 補足：国会対応業務の流れ 国会対応における行政職員の作業の概要は以下の通りです（あくまで概略であり、実際の業務とは異なる場合があります）。 質問内容の聞き取り ：次の委員会で質問することが予定されている国会議員やその秘書の方から、質問内容やその趣旨・背景について、事前に聞き取ります。 答弁案の初稿作成 ：質問の対象となっている施策や領域の担当部局の行政職員が、現在の政府方針や現行法令、そのときどきの経済・社会情勢や過去の答弁等の関連情報を踏まえ、答弁案の初稿を作成します。 関係部局との調整 ：答弁案の初稿に対して、関連する部局と調整を行います。質問や回答案が他の省庁に関係する場合は、他の省庁とも調整を行い、内容を精査します。 答弁審査 ：担当部局が作成した答弁案について、過去の説明や他の部局が担当している施策、当日など直前に決まった政府方針などを踏まえているかどうか、質問に対する応答として正しく成立しているか、国民目線で適切な答弁案となっているかといった総合的な観点から、一言一句、審査が行われます。 レクチャー ：答弁者への完成した原稿を、答弁者である大臣などに説明し、国会での議論に備えます。 今回のプロトタイプで注目したのは、このうち 答弁作成 と 答弁審査 の工程です。AI によって答弁案の作成を効率化したいという期待がある一方で、そもそも実際に役に立つ AI 支援ツールの作成は実現可能なのか。ユーザーである国家公務員の期待に応える水準の機能を提供できるのか。こうした問いを本格的な導入の前に見極めたい——それが今回のプロトタイピングプログラムの出発点です。 なお、本取り組みは答弁の最終的な判断や回答案の表現を AI に委ねるものではなく、あくまで人間の判断を中心に据えた上、関連する文書の検索やドラフトの準備など機械的に処理できる部分を AI に担わせることで、職員がより本質的な検討に集中できる環境を目指すものです。 なぜ AWS のプロトタイピングプログラム支援だったのか AWS のプロトタイピングプログラムは、公共のお客様のアイデアをプロトタイプに落とし込み、技術的な実現可能性を短期間で検証するための無償の支援プログラムです。アイデアを机上の議論にとどめず、現場の業務に近い形で動かし、使用者のフィードバックを得ながら評価したいという職員の方々のニーズに対し、Amazon Bedrock をはじめとするマネージドな AI サービス群と AWS アカウントチーム、そしてプロトタイピングチームの伴走により、最小限のリードタイムで検証サイクルを回せる本プログラムが最も適していると判断し、支援を開始しました。 プロトタイピングの進め方 一般的にプロトタイピングプログラムは１～３ヶ月程度で行いますが、本件では本番環境での導入を目指し約半年にわたって担当部局の方々と反復改善を重ね、画面の使い勝手から検索精度、運用面を含めた部分まで、利用者の声を起点に作り込みました。その結果、設定変更を含めた５回のメジャーバージョンと１１回のマイナーバージョンを経て、本番運用を前提とした水準のプロトタイプとなりました。 進め方は、以下のサイクルを高頻度で回す共創型のアプローチです。 ヒアリングした要件を元に機能を開発。 担当部局の方々に実際にデプロイして使っていただき、フィードバックを収集する。 フィードバックを要件や設計に落とし込み、機能として実装する。 ２に戻る。２で必要であれば、デプロイ支援、トラブルシューティング、バグ修正を行う。 サイクル完了後は、AWS 社内でセキュリティレビューを行い品質を保った状態のソースコード一式および「Path to Production（本番環境への移行ガイド）」を含むプロトタイプアセットをお客様にハンドオーバーします。 作成したプロトタイプについて 作成したプロトタイプ（DietSearch）は、想定問答における答弁案の初稿ドラフト案の生成と、その修正プロセスにおける審査を支援する AI アプリケーションです。組織が持つ過去の想定問答ファイルを検索し、文脈に即して初稿ドラフト案を作成し、その際に参照した過去の想定問答を、その類似度や関連性に応じてソートして表示することで審査を支援します。主な機能について、より詳しくは以下のとおりです。 文書のナレッジベース化 ：組織が保有する過去の想定問答ファイルをセキュアな環境にアップロードすると、関連するメタデータを生成・付与することができ、検索可能なナレッジベースを構築できます。 メタデータの生成部分のカスタマイズ機能 ：ユーザーが事前に定義したルールがシステム内で自動的に適用され、各文書に対してリッチで文脈豊かなメタデータが生成されます。（このメタデータにより、検索時の関連度合いや検索精度が飛躍的に向上します。）ルールの定義は UI 上で完全にカスタマイズ可能で、組み込みの AI アシスタントのサポートによりルールロジックの改善や拡張が容易に行えます。 例１：文書のファイルパスから年月、日時の情報をメタデータとして抽出 例２：文書情報やプロパティから構造化された洞察を導出 ドラフト生成 ：入力された質問に対して、LLM による検索でヒットした文書をコンテキストとして参照し、 AI が答弁の初稿ドラフト案を作成します。ドラフトの各パラグラフには参照した過去の想定問答ファイルが紐づくため、過去の答弁案での記載を確認しながら加筆・修正できます。 過去の想定問答ファイルの横断検索（ハイブリッド検索） ：修正後の答弁案に対して、改めて過去の類似する内容を含む想定問答ファイルを検索できます。過去答弁の検索には、ベクトル検索と全文検索を組み合わせたハイブリッド検索を採用。リランキングと日本語処理を組み合わせて、高い精度の検索を実現しています。 答弁案審査支援 ：作成・修正された答弁案に対して、過去の想定問答との類似性を検証し、関連性の高い箇所をハイライト表示します。レビュー者は過去の類似のケースでどのように説明していたかを示す文書を並べて確認しながら、効率的にチェックできます。 国会会議録検索システムとの連携 ：公開されている 国会会議録検索システム API と連携し、議事録を取得することで、検索結果として表示された組織内の過去の想定問答について、対応する日付の該当委員会において、実際にどのような発言があったか、あるいはなかったかを確認できるようになっています(LLM によってマッチしているかを段落ごとで判別しハイライトし可視化）。 また、利用者のフィードバックを起点に使いやすさと運用性にもこだわりました。検索結果と答弁案を左右に並べて比較できる UI、議事録原文のプレビュー、検索条件のフィルタリング、作業状況の他ユーザーへの共有、ロールベースのアクセス制御（既存の認証システムとの連携）、少ない操作でのファイルアップロードと同期を実現する機能などを備えています。 アプリイメージ図 アーキテクチャと採用サービス DietSearch は AWS のサーバーレス構成を基本とし、運用負荷やコストを抑えながらスケールできるよう設計しています。 フロントエンド配信 ：Amazon CloudFront + Amazon S3、AWS WAF による保護 認証・認可 ：Amazon Cognito (Identity Pool) によるロールベースアクセス制御(管理者／一般利用者) Amazon Cognito (User Pool) と Azure Entra ID との SAML 連携による認証部分の繋ぎ込みも行い、現場の既存の認証システムでのアプリの使用を可能にしました。 API ：AWS Lambda (Function URL, TypeScript・Hono を利用） 検索・生成 ：Amazon Bedrock Knowledge Bases を基盤とし、埋め込みモデルに Amazon Titan Text Embeddings V2、推論モデルに Claude 等を選択可能、セーフガードに Amazon Bedrock Guardrails を採用 ベクトルストア ：Amazon Aurora Serverless v2 (PostgreSQL + pgvector) または Amazon OpenSearch Serverless を要件に応じて選択可能 データ管理 ：Amazon S3 (文書データソース)、Amazon DynamoDB (データ管理) セキュリティ・運用 ：AWS KMS による暗号化、Amazon CloudWatch によるモニタリング インフラはすべて IaC ( SST / Pulumi ) で管理し、セキュリティやコンプライアンスの観点からPulumi Policy Pack によるインフラ検証をデプロイ前のチェックに組み込んでいます。以下に DietSearch のシステム構成図を示します。 アーキテクチャ図 お客様の評価と今後の展望 担当部局の方々から以下のコメントを頂戴しております。 担当部局管理職より 本プロジェクトは、数か月という短期間で、構想段階からプロトタイプのリリースまでを進めることができた貴重な取組となりました。 初期的な要望に合わせて作成いただいたアプリケーションを、実際にユーザーとなり得る職員が試用し、その過程で判明した追加要望や課題を短いサイクルで設計や機能改善に反映いただけたことで、効率的にプロトタイプをブラッシュアップしていくプロセスを実践できました。 また、デプロイ作業や非機能要件に関する検討、課題対応の過程においても、AWSプロトタイピングチームから緊密なコミュニケーションをいただけたことは、アプリケーションの構成や運用方法に加え、インフラ環境に対する理解を深めることにもつながりました。 本プロジェクトを通じて、他の分野も含む今後のシステム開発の進め方について、多くの示唆が得られたと考えています。 担当部局職員より 本システムの構築にあたっては、AWS社との間で何度もフィードバックを重ねる機会を得ることができ、その結果、当組織の業務実態に即した、非常に使い勝手の良いアプリケーションを実現することができました。 一般に、官公庁におけるシステム構築ではウォーターフォール型の開発が主流であり、完成後に想定と異なる操作性となるケースも少なくありません。これに対し、本取組においてはアジャイル型の開発手法を採用したことで、利用者のニーズを反映した改善を随時行うことが可能となり、結果として業務効率化に大きく寄与するアプリケーションを構築するに至りました。 実際に組織内に部分的に展開したところ、「作成される初稿ドラフトの質が想像よりも高かった」「ファイルを自分で開いて確認する手間や国会議事録検索システムを検索する手間が減り、作業が早くなる」など、好評をいただいております。 当該省庁では、2026 年の秋から本格導入を目指し、準備を進めています。あわせて、本ソリューションは中央省庁にとどまらず、他の省庁や地方自治体での展開可能性も期待されています。AWS は引き続き、パートナーとともに本番運用に向けた支援を継続してまいります。 まとめ 「まず動かして確かめる」というプロトタイピングのアプローチは、 AI のように実際に動かしてみなければ効果を判断しにくい領域で、本格導入の判断材料を得るために特に有効です。AWS のパブリックセクター プロトタイピングチームは、公共のお客様のアイデアを短期間で形にし、次の意思決定を後押しします。同様の検討をされている方は、ぜひお近くの AWS 担当者にご相談、または次のメールアドレスにご連絡ください。 aws-jpps-prototyping@amazon.com 著者について Shota Kishimoto – Associate Prototyping Solutions Architect, AWS (プロトタイプチーム） Jorge Lanzarotti – Sr. Prototyping Solutions Architect, AWS (プロトタイプチーム） Hiromichi Miyawaki – Account Executive, Central Government, AWS (アカウントチーム） Naoki Miyaguchi – Solutions Architect, Central Government, AWS (アカウントチーム）

本記事は 2026 年 7 月 2 日 に公開された「 Amazon Redshift RG: Faster and lower cost, Graviton-powered 」を翻訳したものです。 Amazon Redshift は、Graviton プロセッサを搭載した新しいインスタンス RG の一般提供を開始しました。Amazon 独自の Graviton プロセッサ上に構築された RG は、以下を実現します。 データウェアハウスワークロードで RA3 と比較して最大 2.2 倍高速なパフォーマンス 統合されたベクトル化データレイクエンジンにより、Iceberg クエリで最大 2.4 倍、Parquet クエリで 1.5 倍高速 データレイククエリに対する TB あたりのスキャン料金が不要。RA3 クラスターに適用されていた Amazon Redshift Spectrum のコストを排除 RA3 と比較して vCPU あたりのコストが 30% 低減 RG はより高速かつ低コストです。一般的にクラウドベンダーは高速なパフォーマンスや新世代ハードウェアに対してより高い料金を設定しますが、Amazon Redshift はより高いパフォーマンスをより低いコストで提供します。 本記事では、RG インスタンスが高速な理由を説明します。また、RG が他の主要データウェアハウスと比較して最大 4.2 倍優れたプライスパフォーマンスを実現するベンチマーク結果も紹介します。 RG が高速な理由 新しい RG インスタンスは、Graviton プロセッサの性能を最大限に活用するためにゼロから設計されています。Amazon Redshift のベクトル化エンジンは Graviton ベースの SIMD (Single Instruction, Multiple Data) カーネルで最適化されており、分析ワークロードに対して高速で並列化された実行を実現します。Parquet エンコーディングに対する述語評価などの操作では、Graviton のベクトル比較、テーブルルックアップ、ベクトル操作のインストリンシクス（組み込み命令）を活用しています。処理速度の向上を支えるため、RG インスタンスはカスタムビルドの Nitro SSD を使用します。高速なローカルストレージをキャッシュレイヤーとして活用し、 Amazon Redshift Managed Storage (RMS) やデータレイクスキャン、メモリに収まらない計算の中間結果セットに対応します。また、RG の JIT (Just-In-Time) Analyze 機能は、クエリの実行中にデータレイクファイルの統計情報を自動的に収集・保存するため、オプティマイザが大幅に優れたクエリプランを生成できます。ハードウェアアクセラレーション (Graviton)、ベクトル化実行 (SIMD カーネル)、高速ストレージ (Nitro SSD)、適切なクエリプランニング (JIT Analyze) と、スタック全体で最適化を実現しています。 上記の最適化と、RG 専用に構築された高性能ベクトル化データレイクエンジンの組み合わせにより、Amazon Redshift の RG インスタンスは分析ワークロードで RA3 と比較して最大 2.2 倍高速に動作し、コストも 30% 低く抑えられます。 専用の高性能ベクトル化データレイクエンジン RA3 では、データレイククエリのスキャンを Amazon Redshift Spectrum と呼ばれる別のコンピュートフリートにオフロードしていました。データレイククエリが別のコンピュートで実行されるため、RA3 クラスターと Spectrum フリート間でクエリメタデータや結果を転送する際に追加の負荷が発生していました。Amazon Redshift RG インスタンスには、データレイク向けにゼロから設計された、まったく新しい組み込みスキャンレイヤーが含まれています。新しいスキャンレイヤーには、データレイテンシーを削減するスマートプリフェッチ機能を組み込んだ専用 I/O サブシステムが含まれます。また、Iceberg で最も一般的に使用されるファイル形式である Apache Parquet の処理に最適化されており、Graviton 向けに最適化された SIMD カーネルによる高速なベクトル化スキャンを実行します。スキャンレイヤーには、パーティションレベルとファイルレベルの両方で動作する高度なデータプルーニングメカニズムが含まれており、スキャンが必要なデータ量を大幅に削減します。プルーニング機能はスマートプリフェッチシステムと連携して動作し、データ取得プロセス全体の効率を最大化します。 新しい専用ベクトル化データレイクエンジンは、Iceberg クエリで RA3 と比較して最大 2.4 倍、Parquet クエリで 1.5 倍高速です。 新しいベクトル化データレイクエンジンは Amazon Redshift のコア実行エンジンに直接統合されているため、RA3 と比較して新たなパフォーマンス最適化が可能です。この統合アーキテクチャにより、RG でのデータレイククエリは高速なローカルデータキャッシュ、改良されたブルームフィルタ、ベクトル化 Parquet スキャン、高度なフィルタリングとプルーニングの恩恵を受けられます。 RG は、データレイクのクエリでお客様が直面する一般的な問題も解決します。Amazon Simple Storage Service (Amazon S3) 上の Iceberg などのオープンフォーマットファイルには有用なメタデータや統計情報が不足していることが多く、SQL クエリを最適に実行することが困難でした。 統計情報とは、個別値の数、最小値/最大値、分布パターン、行数などのデータに関するメタデータです。クエリオプティマイザはこの情報を使用して、クエリの最も効率的な実行方法を選択します。たとえば、2 つのテーブルを結合する際、オプティマイザは適切な結合戦略を選択するために各側が生成する一意の値の数を把握する必要があります。統計情報がなければ推測に頼ることになり、多くの場合、結合が遅くなりノード間で不要なデータ移動が発生します。ここで Amazon Redshift の新機能 JIT (Just-In-Time) Analyze が役立ちます。RG インスタンスはクエリの実行中に Iceberg ファイルの統計情報を自動的に取得・保存するため、Amazon Redshift は統計情報がない場合と比較してはるかに最適化されたクエリ実行戦略を選択できます。 Iceberg や Parquet データのスキャンが RA3 よりも大幅に高速になります。Amazon Redshift Spectrum のコンピュートが不要になったことで、RG インスタンスではデータレイククエリの $5/TB のコストも排除されます。データレイククエリがより安価になり、コストの予測も容易になります。パフォーマンスの向上、コンピュートコストの低減、TB あたりのスキャンコストの撤廃という 3 つのメリットにより、データレイクのプライスパフォーマンスが大幅に改善します。 データロードの高速化によるインサイト取得の迅速化 Amazon Redshift RG の高速 I/O と Graviton 最適化エンジンにより、RA3 と比較してデータロードが高速化されています。パフォーマンス改善を測定するため、同等サイズの RA3 と RG クラスターで 10TB TPC-DS および TPC-H のデータ取り込みステップを実行しました。RG は TPC-DS データセットを 2 倍高速に、TPC-H データセットを 1.4 倍高速に取り込みました (次の図を参照)。 新しい Graviton ベースの RG インスタンスは、RA3 インスタンスと比較してデータロードが最大 2.0 倍高速です。ワークロードはより早く最新データを取得でき、ユーザーやエージェントはより迅速に最新のインサイトを得られます。RG でのデータ取り込み高速化は RA3 と比較して 30% 低いコストで実現されており、データロードのプライスパフォーマンスは RA3 インスタンスと比較して最大 2.9 倍です。 お客様の声 Amazon Redshift のお客様は、RG への切り替えによるパフォーマンスとコストのメリットをすでに実感しています。Southwest Airlines と tombola はビジネスクリティカルなワークロードでテストを行い、パフォーマンスの向上とコスト削減を確認しました。 Southwest Airlines 「Amazon Redshift RG インスタンスは、Southwest Airlines に大きなビジネスインパクトをもたらす可能性があります。開発環境での初期テストでは、データウェアハウスワークロードが 50〜60% 高速化し、データレイク分析は 45% 高速化しました。チームはより早くインサイトを得て、運用状況に迅速に対応し、低レイテンシーでデータドリブンな意思決定を行えるようになります。これらの初期結果は期待が持てるもので、本番環境での検証とスケールアップが楽しみです。さらに、TB あたりの Spectrum スキャン料金が不要になり、燃料価格が業界のマージンを圧迫し続ける中、RA3 と比較して 30% のコスト削減を実現しています！」 — Sean Lynch、Vice President, Data and Architecture、Southwest Airlines tombola 「Graviton ベースの Amazon Redshift RG インスタンスは、バッチジョブと分析ジョブの多様なセットで、RA3 と比較して 1.8〜2 倍の書き込みスループットと最大 2.2 倍の読み取り速度を実現しました。同じ時間枠で 40% 多くの処理が可能になりました。ETL サイクルが短縮され、インサイト取得までの時間が加速し、パイプラインによる意思決定のボトルネックがなくなりました。これらの改善により、アナリストやビジネスチームにより新鮮なデータがより早く届くようになりました。さらに魅力的だったのは、パフォーマンス向上と同時にコンピュート費用が 30% 削減されたことです。より少ないコストでより多くを実現するのは稀な成果であり、強調する価値があります。クエリレイテンシーとコストがスケールに伴い複合的に影響する tombola のような大量データを扱うゲーム業界では、今年最もインパクトのあるプラットフォーム決定の一つとなりました。」 — Akshay Srinivasan、Data Engineer、tombola Qoala 「Amazon Redshift クラスターを RA3 から Graviton ベースの RG インスタンスに移行した結果、BI および分析ワークロード全体でクエリ処理時間が 60〜70% 高速化しました。数百万件の保険契約トランザクションを処理する成長中のインシュアテックプラットフォームとして、インサイト取得までの時間短縮は、データチームがダッシュボードやレポートをより早くビジネスに届けられることを意味します。将来の成長に対応するためにより大きなノード構成に移行しましたが、パフォーマンスの向上は追加投資をはるかに上回り、今年最もインパクトのあるインフラストラクチャ決定の一つとなりました。」 — Umar Abdul Aziz、VP of Data、Qoala パフォーマンス結果 RG の実力を確認するため、業界標準の TPC-DS および TPC-H ベンチマークをベースとしたベンチマークを 10TB スケールで、新しい Amazon Redshift RG インスタンスおよび主要な代替データウェアハウスで実行しました。ベンチマークは、アドホック、レポーティング、反復的なオンライン分析処理 (OLAP)、データマイニングなど、さまざまな運用要件と複雑性を持つクエリを実行するよう設計されています。各データウェアハウスをほぼ同じオンデマンドコスト ($32/時間) でサイジングし、特別なチューニングやカスタマイズなしにそのままの状態で 3 回のパワーランを実行しました。結果は以下のチャートのとおりです。 新しい RG インスタンスが大差をつけてリードしています。プライスパフォーマンスが優れているということは、パフォーマンスが高く、 かつ コストが低いことを意味します。 まとめ Amazon Redshift RG インスタンスは次世代の分析エンジンであり、データウェアハウスとデータレイクワークロードに高いパフォーマンスを提供します。RG は RA3 と同じワークロードと機能をすべてサポートしているため、利用開始は簡単です。アップグレードして、より低コストでより高いパフォーマンスを得る方法については、 移行ガイド を参照してください。 ワークロードに最適なプライスパフォーマンスを見つける 本記事で使用したベンチマークは、業界標準の TPC-DS および TPC-H ベンチマークをベースとしており、以下の特徴があります。 TPC-DS および TPC-H のスキーマとデータを変更せずに使用しています。 クエリは公式の TPC-DS および TPC-H キットを使用し、キットのデフォルトのランダムシードで生成されたクエリパラメータで生成されています。デフォルトクエリの SQL ダイアレクトをサポートしていないデータウェアハウスでは、TPC 承認済みのクエリバリエーションを使用しています。 テストには TPC-DS の 99 個の SELECT クエリと TPC-H の 22 個の SELECT クエリが含まれます。メンテナンスとスループットのステップは含まれません。 3 回のパワーランを実行し、各データウェアハウスで最も良い結果を採用しています。 プライスパフォーマンスは、時間あたりのコスト (USD) を 1時間あたり 3,600 秒で割り、ベンチマークの幾何平均 (秒) を掛けて計算します。これはクエリあたりの幾何平均コストに相当します。すべてのデータウェアハウスで最新の公開オンデマンド料金を使用しています。 Cloud Data Warehouse ベンチマークと呼ばれるこのベンチマークの結果は、 GitHub リポジトリ で公開されているスクリプト、クエリ、データを使用して再現できます。本記事で説明したとおり TPC-DS ベンチマークをベースとしていますが、公式仕様に準拠していないため、公開済みの TPC-DS 結果とは比較できません。 著者について Stefan Gromoll Amazon Redshift チームのプリンシパルエンジニアで、Redshift のパフォーマンスを担当しています。プライベートでは料理、4 人の息子たちとの遊び、薪割りを楽しんでいます。 Ankit Sahu データ製品やサービスの構築に 18 年以上の経験を持ち、プロダクト戦略、Go-to-Market 実行、デジタルトランスフォーメーションの幅広い経験があります。現在は Amazon Web Services (AWS) のシニアプロダクトマネージャーとして、Amazon Redshift のビジョンと戦略を推進しています。 Mohammed Alkateb Amazon Redshift のエンジニアリングマネージャーで、クエリ最適化、データレイクアクセス、パフォーマンスエンジニアリング、新しいインスタンスの検証にわたるソフトウェアエンジニア、アプライドサイエンティスト、Amazon Scholar のチームを率いています。Amazon 入社前は Teradata のオプティマイザチームに 12 年以上在籍。バーモント大学で博士号を取得し、主要なデータベースカンファレンスでの論文発表や米国特許を多数保有しています。 Yousuf Hussain Amazon Redshift のシニアソフトウェアエンジニアで、大規模クラウドデータウェアハウスシステムの構築と運用に 11 年の経験があります。分析に情熱を持ち、Amazon Redshift のお客様に高パフォーマンスな体験を提供するためにインスタンス戦略、可用性、信頼性に注力しています。 Nita Shah ニューヨーク拠点の AWS シニアアナリティクススペシャリストソリューションアーキテクトです。20 年以上にわたりエンタープライズデータプラットフォーム、データウェアハウス、分析ソリューションを構築しており、Amazon Redshift を専門としています。エンタープライズ規模の Well-Architected な分析・意思決定支援プラットフォームの設計と構築を支援しています。 Sanket Hase Amazon Redshift チームのエンジニアリングマネージャーで、データレイク分析、ハードウェア・ソフトウェア協調設計、ベクトル化クエリ実行に焦点を当てたクエリ実行チームを率いています。カーネギーメロン大学でコンピューターサイエンス修士号を取得し、データベースシステム分野で複数の米国特許を保有しています。 Jingbo Zhang Amazon Redshift のデータエンジニアで、新しいインスタンスの検証とパフォーマンスバリデーションを担当しています。RG、r8gd、r7gd を含む複数の Graviton ベース Redshift インスタンスファミリーの検証とローンチに貢献し、ベンチマーク、パフォーマンス分析、自動化に注力しています。カーネギーメロン大学でデータアナリティクス修士号を取得しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 7 月 1 日 に公開された「 AI-powered performance recommendations for Amazon Redshift 」を翻訳したものです。 Amazon Redshift を運用するデータプラットフォームチームは、 SYS_QUERY_HISTORY 、 SVV_TABLE_INFO 、 SVV_ALTER_TABLE_RECOMMENDATIONS などのシステムビューや、キャパシティ、クエリ実行、ストレージに関する Amazon CloudWatch メトリクスからパフォーマンステレメトリを収集しています。課題はテレメトリの解釈です。 QueryRuntimeBreakdown のコミット時間の急増と数百件の小規模な INSERT 文の関連性を見抜く、あるいはディスクスピルの多発とコンピュートの不足を結びつけるには、深い専門知識と数時間に及ぶ手作業の分析が必要です。 本記事では、テレメトリを収集し、パフォーマンスシグナルを事前計算し、CloudWatch と相関分析を行い、 Amazon Bedrock で優先度付きの推奨事項を生成する AI ソリューションの構築方法を解説します。ソースコードは GitHub リポジトリ sample-ai-performance-advisor-for-amazon-redshift で公開しています。 シグナルベースの設計により、汎用的なアドバイスではなく的確な推奨を生成できます。システムビューの生出力をそのまま大規模言語モデル (LLM) のプロンプトに渡すのではなく、コレクターが真偽値やしきい値に基づく検出結果を事前計算し、CloudWatch との相関を付与したうえで、構造化されたコンテキストをモデルに渡します。これにより、モデルの出力で具体的なクエリ ID、テーブル名、メトリクス値を参照できます。 ソリューション概要 2 つの AWS Lambda 関数が 24 時間間隔の Amazon EventBridge スケジュールで実行されます。 コレクター Lambda は、 Amazon Redshift Serverless に対して 13 の診断 SQL クエリを実行し、ワークグループの Workload Management (WLM) 設定を読み取ります。また、キャパシティ、クエリ実行、WLM、接続数、ストレージの CloudWatch メトリクスも収集します。これらの入力からパフォーマンスシグナルを計算し、テレメトリ JSON ファイルを Amazon Simple Storage Service (Amazon S3) に書き込みます。 アナライザー Lambda は Amazon S3 からテレメトリを読み取り、CloudWatch とシグナルの相関をインラインで含む構造化プロンプトを構築します。相関情報を活用して Amazon Bedrock ( Anthropic Claude Sonnet 4.6) を呼び出し、生成された推奨事項 JSON を Amazon S3 に書き戻します。 Amazon Simple Notification Service (Amazon SNS) トピックが、上位の推奨事項をメールでサブスクライバーに送信します。 図 1 – アーキテクチャ図 前提条件 デプロイ前に、以下を準備してください。 データベースとクエリ履歴がある Amazon Redshift Serverless ワークグループ。 Amazon Redshift データベース管理者ユーザー (スーパーユーザー)。コレクターはスーパーユーザーのみがクエリできるビュー ( SVV_TABLE_INFO 、 SVV_ALTER_TABLE_RECOMMENDATIONS 、 SVV_MV_INFO 、 SYS_SERVERLESS_USAGE 、 SYS_AUTO_TABLE_OPTIMIZATION ) を読み取ります。 管理者の認証情報を AWS Secrets Manager に保存し、シークレット ARN をコレクターに渡します。 別の方法として、既存のスーパーユーザーで ALTER USER "IAMR:redshift-performance-recommendations-role" CREATEUSER; を一度実行し、Lambda ロールにスーパーユーザー権限を付与する方法もあります。 使用するモデルの Amazon Bedrock モデルアクセス。本ソリューションでは、マルチリージョン推論用に us.anthropic.claude-* モデルを推奨しますが、特定のモデルに依存しない設計です。 AWS Command Line Interface (AWS CLI) のインストールと設定、および GitHub リポジトリのクローン。 サポートリソースの作成 Lambda 関数を実行するには、Amazon S3 バケット、Amazon SNS トピック、 AWS Secrets Manager シークレット、 AWS Identity and Access Management (IAM) ロールが必要です。 Amazon S3 バケットの作成 Amazon S3 バケットに出力レポートを保存します。 Amazon S3 コンソールを開き、 バケットを作成 を選択します。 グローバルに一意の名前 (例: amzn-s3-demo-bucket ) を入力し、デフォルト設定のまま バケットを作成 を選択します。 コレクターは telemetry/ プレフィックス配下にテレメトリ JSON を書き込み、アナライザーは recommendations/ プレフィックス配下に推奨事項を書き込みます。 Amazon SNS トピックとサブスクリプションの作成 レポート作成後の通知に Amazon SNS を使用します。 Amazon SNS コンソールを開き、 トピック 、 トピックの作成 の順に選択します。 スタンダード を選択し、名前に redshift-performance-recommendations と入力します。 トピックの作成 を選択します。 トピック詳細ページで サブスクリプションの作成 を選択します。 プロトコルとして E メール を選択し、メールアドレスを入力して サブスクリプションの作成 を選択します。 AWS Notifications からの確認メールを開き、 サブスクリプションの確認 を選択します。 図 2 – SNS トピックの作成 管理者の認証情報を AWS Secrets Manager に保存 ハードコードされた認証情報を避けるため、AWS Secrets Manager シークレットを作成して Amazon Redshift に接続します。 AWS Secrets Manager コンソールを開き、 新しいシークレットを保存する を選択します。 その他のシークレットのタイプ を選択し、 プレーンテキスト タブを選択して以下を貼り付けます。 <ADMIN_PASSWORD> はワークグループの管理者パスワードに置き換えてください。 {"username":"admin","password":"<ADMIN_PASSWORD>"} 次へ を選択し、シークレット名に redshift-performance-admin と入力して、 次へ 、 次へ 、 保存 を選択します。 シークレット詳細ページからシークレットの Amazon Resource Name (ARN) をコピーします。後のステップでコレクターに渡します。 図 3 – シークレットの作成 IAM ロールの作成とポリシーのアタッチ リポジトリには、 iam/trust-policy.json に信頼ポリシー ( lambda.amazonaws.com がロールを引き受けることを許可) と、 iam/lambda-role-policy.json に最小権限のアクセス許可ポリシーが含まれています。アクセス許可ポリシーの <ACCOUNT_ID> 、 <REGION> 、 <YOUR_BUCKET> 、SNS トピック ARN のプレースホルダーを自身の値に置き換えてから、 AWS マネジメントコンソール または以下の AWS CLI コマンドでロールを作成します。 aws iam create-role --role-name redshift-performance-recommendations-role \ --assume-role-policy-document file://iam/trust-policy.json aws iam put-role-policy --role-name redshift-performance-recommendations-role \ --policy-name redshift-performance-policy \ --policy-document file://iam/lambda-role-policy.json アクセス許可ポリシーは、両方の Lambda 関数に必要な Amazon Redshift Data API、Amazon S3、Amazon SNS、Amazon Bedrock、AWS Lambda 呼び出し、AWS Secrets Manager、 Amazon CloudWatch Logs の権限を付与します。 Lambda 関数のデプロイ コレクターのソースは lambda/collector.py にあり、実行時に sql/ 配下の SQL ファイルを読み込みます。デプロイパッケージには両方を含める必要があります。 コレクターのパッケージング ターミナルまたはシェルを開き、コレクターのコードと SQL をフォルダにコピーしてアーカイブを作成します。 mkdir -p build/collector/sql cp lambda/collector.py build/collector/ cp sql/*.sql build/collector/sql/ (cd build/collector && zip -qr ../collector.zip .) コレクター関数の作成 AWS マネジメントコンソールで AWS Lambda に移動します。 関数の作成 を選択します。   図 4 – AWS Lambda 関数の作成 一から作成 を選択し、名前に redshift-performance-collector と入力して、 Python 3.14 を選択します。 カスタム設定 を展開し、 カスタム実行ロール を切り替えて、 既存のロール を選択し、 redshift-performance-recommendations-role を選択して 保存 を選択します。 関数ページで アップロード元 、 .zip ファイル を選択し、 build/collector.zip をアップロードします。 ランタイム設定 で 編集 を選択し、 ハンドラ を collector.lambda_handler に設定します。   図 5 – AWS Lambda ハンドラの設定 設定 、 編集 を選択し、タイムアウトを 5 分、メモリを 256 MB に設定します。   図 6 – AWS Lambda のタイムアウトとメモリの設定 設定 で 環境変数 を選択し、以下のキーを追加します。 WORKGROUP : Amazon Redshift Serverless ワークグループ名。 NAMESPACE_NAME : ワークグループが属する名前空間。 DATABASE : dev (または対象のデータベース)。 BUCKET : 先ほど作成した Amazon S3 バケット名。 SECRET_ARN : 先ほどコピーした AWS Secrets Manager シークレット ARN。 ANALYZER_FN : redshift-performance-analyzer 。 アナライザーのパッケージングと作成 lambda/analyzer.py を使用して、アナライザーも同様の手順で作成します。タイムアウトは 15 分です。 (cd lambda && zip -q ../build/analyzer.zip analyzer.py) Lambda コンソールで redshift-performance-analyzer を作成し、ハンドラを analyzer.lambda_handler 、タイムアウトを 15 分、メモリを 256 MB、同じ実行ロールを設定して、以下の環境変数を追加します。 BUCKET : 同じ Amazon S3 バケット。 SNS_TOPIC : SNS トピック ARN。 MODEL_ID : us.anthropic.claude-sonnet-4-6 。 アナライザーは read_timeout=600 と max_tokens=16384 を指定して Amazon Bedrock クライアントを作成し、大規模なプロンプトと長い応答に対応します。フルテレメトリペイロードでの Anthropic Claude 推論は通常 2〜4 分かかります。 シグナルとプロンプトの仕組み シグナル計算やプロンプト構築のカスタムコードを書く必要はありません。どちらもリポジトリに含まれています。 lambda/collector.py の compute_signals() 関数は、テレメトリをスキャンして真偽値としきい値に基づくアンチパターンを検出します。テーブルレベルでは、行の偏り (skew)、ゴースト行（論理削除行）、統計情報の陳腐化、未ソートデータ、最適でないソートキーや分散キー、過大な VARCHAR カラムを検出します。ランタイムとワークロードの問題として、ディスクスピル（中間データのディスク書き出し）、小規模 INSERT のバースト、DDL (データ定義言語) の多発、最適化されていない COPY ファイルサイズも検出します。さらに、パーティションプルーニングに失敗した Amazon Redshift Spectrum クエリや、フルリフレッシュを行うデータ共有マテリアライズドビューも検出します。また、ディスクスピルブロック数やクエリ実行時間の制限など、Query Monitoring Rules (QMR) が欠如している WLM 設定も検出します。シグナルとしきい値の全セットは関数内にインラインで定義されています。しきい値の調整やカスタムシグナルの追加は、この関数を編集して再デプロイするだけで対応できます。 lambda/analyzer.py の build_prompt() 関数は、Amazon Bedrock プロンプトを 4 つのセクションで構築します。第 1 セクションはトリガーされたシグナルの一覧です。第 2 セクションは CloudWatch メトリクスを追加し、各シグナルとそのサポートメトリクスを対にする  >> CORRELATION 行で注釈をつけます。第 3 セクションはフィルタリングされたサポートデータで、シグナルをトリガーしたテーブル行とクエリ行に限定されています。第 4 セクションは、すべての推奨事項で特定のテーブル名、クエリ ID、メトリクス値を参照するパイプ区切りテキストを返すよう明示的に指示します。この構造により、モデルは汎用的なベストプラクティスではなく具体的な出力を生成します。 日次実行のスケジュール設定 Amazon EventBridge コンソールでコレクターを 24 時間ごとにトリガーします。 EventBridge コンソールを開き、 Scheduler の スケジュール 、 スケジュールを作成 を選択します。 スケジュール名 に redshift-performance-daily と入力し、 定期スケジュール と レートベースのスケジュール を切り替えます。 レート式 に 24 と入力し、 時間 を選択します。 フレキシブルタイムウィンドウ で オフ を選択し、 次へ を選択します。 図 7 – Amazon EventBridge スケジュールの作成 ターゲットを選択 ページで、 AWS Lambda を選択し、 redshift-performance-collector 関数を選択して 次へ を選択します。   図 8 – Amazon EventBridge スケジュールターゲットの選択 設定 のデフォルトを受け入れて 次へ を選択します。EventBridge は Lambda 関数にリソースベースのアクセス許可を自動的に追加し、ルールが関数を呼び出せるようにします。 スケジュールを作成 を選択します。 実行して出力を確認する コレクターを手動で呼び出し、パイプライン全体が動作することを確認します。 Lambda コンソールで redshift-performance-collector 関数を開き、 テスト を選択します。テストイベント名に manual 、本文に {} と入力して テスト を選択します。   図 9 – エンドツーエンドワークフローのテスト 関数は 1 分以内に完了します。 モニタリング タブの CloudWatch ライブログ リンクで呼び出しログを確認します。 Amazon S3 コンソールでバケットを開きます。 telemetry/ プレフィックスに現在のタイムスタンプの JSON ファイルがあることを確認します。 2〜4 分以内にアナライザーが SNS トピックにメッセージを発行します。登録したメールアドレスで上位 10 件の推奨事項サマリーを確認します。Amazon S3 の recommendations/ プレフィックスに完全な JSON があることも確認します。 各推奨事項には、優先度 (critical、high、medium、low) とカテゴリ ( query_optimization 、 table_design 、 capacity 、 wlm 、 maintenance 、 ingestion ) があります。また、推奨をトリガーしたシグナルと CloudWatch メトリクスを示す signal_source 、平易な言葉での説明、具体的な SQL または設定アクション、想定される影響の見積もりも含まれます。 図 10 – アナライザーのメール出力サンプル ベストプラクティス しきい値をワークロードに合わせて調整する。 compute_signals() のデフォルトしきい値は Amazon Redshift 運用レビュープレイブックに基づいています。高速取り込みや小規模クラスター環境では、小規模 INSERT のしきい値を下げる、統計情報の陳腐化ウィンドウを広げる、テーブル固有のカスタムシグナルを追加するなどの調整を検討してください。 シグナルとメトリクスの相関を最新に保つ。 シグナルを追加する場合は、 build_correlations() に対応する相関も追加してください。インラインの >> CORRELATION 行が、インフラストラクチャメトリクスとアプリケーションレベルの症状を結びつけます。 推奨事項は実行前にレビューする。 アナライザーは優先度付きの提案を生成しますが、 VACUUM 、 ANALYZE 、 ALTER TABLE はテーブルの状態を変更します。各推奨事項の説明とアクションを確認し、スキーマに対して SQL を検証してから、メンテナンスウィンドウ中に実行してください。 クリーンアップ 不要な課金を避けるため、本ソリューション用に作成したリソースを削除してください。 2 つの AWS Lambda 関数: redshift-performance-collector と redshift-performance-analyzer 。 Amazon EventBridge ルール: redshift-performance-daily 。 Amazon SNS トピックとメールサブスクリプション: redshift-performance-recommendations 。 Amazon S3 バケット ( telemetry/ と recommendations/ のオブジェクトを含む)。 AWS Secrets Manager シークレット: redshift-performance-admin 。 IAM ロールとインラインポリシー: redshift-performance-recommendations-role 。 まとめ Amazon Redshift Serverless の日次パフォーマンスレビューを AWS Lambda で実行し、結果を Amazon S3 に保存し、優先度付きの推奨事項をメールで配信する仕組みが完成しました。シグナルベースのプロンプトパターンにより、Amazon Bedrock のコストを抑えつつ、ワークロード固有の推奨を生成できます。 詳細については、以下のリソースを参照してください。 ソースコード: GitHub の sample-ai-performance-advisor-for-amazon-redshift 。 Amazon Redshift のシステムテーブルとビュー 。 Amazon Bedrock ユーザーガイド 。 Amazon CloudWatch での Amazon Redshift Serverless のモニタリング 。 著者について Steve Phillips Steve は、AWS 北米リージョンのプリンシパルテクニカルアカウントマネージャー兼 Analytics スペシャリスト。データウェアハウスのアーキテクチャ設計、AI/ML データ基盤、データレイク、データ取り込みパイプライン、クラウド分散アーキテクチャに注力しています。 Richard Raseley Richard は、北米のシニアテクニカルアカウントマネージャーとして、ゲーム業界のお客様を担当。自動化、クラウドコンピューティング、ネットワーク、ストレージのバックグラウンドを活かし、お客様の AI ソリューション構築を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 6 月 29 日 に公開された「 Scale analytics with Amazon Redshift multi-warehouse enhancements 」を翻訳したものです。 Amazon Redshift のリモートテーブル DDL の改善、マテリアライズドビューの機能強化、ゼロ ETL および 自動コピー向けの同時実行スケーリング拡張により、大規模なアナリティクスワークロードを効率的にオンボードできるようになりました。 組織がアナリティクス機能を拡張する際には、本番環境の運用を中断せず、単一のデータウェアハウスのリソースに制約されずにワークロードを追加できる柔軟性が求められます。本記事では、 Amazon Redshift のマルチウェアハウスおよびスケーリング機能を強化する新機能として、リモートマテリアライズドビュー (MV) 操作、リモートテーブル DDL サポート、ゼロ ETL および S3 イベント統合向け同時実行スケーリングの拡張を紹介します。各機能を組み合わせることで、Amazon Redshift 上でスケーラブルかつ高パフォーマンスな分散型アナリティクスアーキテクチャを構築できます。 マルチウェアハウスの新機能で大規模アナリティクスをどのように実現できるか確認していきましょう。 リモートマテリアライズドビュー操作の新機能 Amazon Redshift では CREATE MATERIALIZED VIEW がユーザーワークロードとして分類される ようになりました。リソース競合時に同時実行スケーリングが追加のウェアハウスで MV ロジックを実行できるため、高負荷時でもクエリが MV のパフォーマンスメリットを安定して享受できます。 Amazon Redshift で リモートデータ共有上での MV 作成 がサポートされるようになりました。Redshift ウェアハウス間でデータを共有しているお客様が、ローカルデータと共有データの両方で MV のパフォーマンスメリットを活用できます。 コンシューマーウェアハウスで、 プロデューサーで作成された MV のリフレッシュや、データ共有された MV の上に MV を作成 できるようになりました。データ共有アーキテクチャのプロデューサーとコンシューマーのウェアハウス間で MV の機能が完全に同等になりました。 リモートテーブル DDL 操作の新機能 ALTER TABLE ALTER DISTSTYLE 操作が、同時実行スケーリングとデータ共有を通じてリモートウェアハウスで動作するようになりました。分散環境全体でデータ分散を動的に最適化し、データ移行なしでクエリパフォーマンスとリソース使用率を改善できます。複数のウェアハウスにまたがるパフォーマンスチューニングを行うデータエンジニアや、変化するクエリパターンに対応する管理者にとって特に有用です。 ALTER TABLE APPEND 操作が、同時実行スケーリングとデータ共有を通じてリモートウェアハウスに拡張されました。分散環境間でデータを統合でき、複雑なデータ移動や ETL プロセスなしで効率的にテーブルを結合できます。複数環境にまたがる動的テーブル操作を管理する組織が、運用負荷を軽減しながらデータの一貫性を維持できます。 同時実行スケーリングの改善 Amazon Redshift の拡張された ゼロ ETL 機能が同時実行スケーリングをサポート し、アプリケーションやオペレーショナルソースからの自動データ取り込みに対応しました。 Amazon Redshift の拡張された 自動コピー機能が同時実行スケーリングをサポート し、S3 からの自動データ取り込みに対応しました。 Amazon Redshift の同時実行スケーリングが Amazon S3 からの COPY クエリをサポートするようになりました。バッチワークロード向けに 同時実行スケーリングでデータ取り込みを自動的にスケール できます。 同時実行スケーリングの拡張により、既存のウェアハウスパフォーマンスを損なわずに一貫したデータ鮮度を維持できます。アナリティクスとデータロードのトレードオフが解消されます。同時実行スケーリングを有効にする以外に、追加の変更は不要です。 お客様のユースケース ここでは、金融サービスとゲーム業界の 2 つのユースケースを紹介します。 金融サービスのユースケース 以下は、グローバル展開する大手金融サービスのお客様のサンプルアーキテクチャです。同社は Amazon Redshift 上にマルチウェアハウスアーキテクチャを構築しています。 ステージング (STG) ウェアハウスは、メダリオンアーキテクチャのブロンズレイヤーのように、さまざまなソースからのデータの 生データゾーンです。STG ウェアハウスは 生データのクレンジングと標準化も行い、シルバーレイヤーとして後続処理に利用可能にします。また、MV を使用して数百万件のネストされた JSON メッセージを処理し、属性をスカラーのカラム型 Amazon Redshift テーブルに抽出します。 CREATE MATERIALIZED VIEW rawdb.fsi.customer_orders_raw distkey(c_custkey) sortkey(c_custkey) AS ( SELECT c_custkey, o.o_orderstatus, o.o_totalprice, o_idx FROM customer_orders_lineitem c, c.c_orders o AT o_idx ); REFRESH MATERIALIZED VIEW rawdb.fsi.customer_orders_raw; DWH ウェアハウスはプライマリ Amazon Redshift インスタンスおよびゴールドレイヤーとして、Business Objects や Tableau などのコンシューマーアプリケーションにデータを提供します。ゼロ ETL 同時実行スケーリングの改善により、ゼロ ETL の取り込みスパイクと DWH の高負荷ワークロードが同時に発生しても、一貫したデータ鮮度を維持できます。DWH の MV は、Tableau エクストラクトや Business Objects のライブレポート向けに集約データへの高速アクセスを提供します。DWH ウェアハウスは、DWH インスタンス上で複数の MV をリフレッシュする必要がある場合に同時実行スケーリングを活用します。 CREATE MATERIALIZED VIEW bodb.final.customer_churn_tbl AS ( SELECT state, account_length, area_code, total_charge/account_length AS average_daily_spend, cust_serv_calls/account_length AS average_daily_cases, churn FROM custdb.final.customer_activity_all ); REFRESH MATERIALIZED VIEW bodb.final.customer_churn_tbl; ETL01/02 ウェアハウスはプロジェクト固有の ETL ジョブを実行する専用コンピュート環境として、USR01/02 ウェアハウスは dbt からのアドホック分析やモデル構築などのユーザーワークロードを処理します。ユーザーワークロードに新しいオブジェクトが必要な場合、リモートのプロデューサーウェアハウス (DWH) 上で作成・管理されます。 ALTER TABLE salesdb.final.sales_report_all ALTER DISTKEY sales_id; ALTER TABLE APPEND salesdb.final.sales_report_all FROM stagingdb.sales.sales_2026_02; ゲーム業界のユースケース 大手ゲーム会社は、アナリティクスインフラ全体を AWS 上に構築しており、アナリティクスチームがゲームからのデータストリーミング、データウェアハウジング、BI ツールを管理しています。同社は Amazon EC2 上で稼働していた Vertica から移行し、Amazon Redshift を組織全体で標準化しました。クラスターリサイズ操作に関する初期の課題を克服した後、チームは Amazon Redshift の強力な推進者となり、現在は 32 ノードの ra3.16xlarge でプライマリ本番クラスターを運用しています。 データ取り込みパイプラインの成長に伴い、クエリワークロードがデータ取り込みプロセスと競合し、パフォーマンスのボトルネックが発生しました。プライマリクラスターをスケールアップするのではなく、Amazon Redshift データ共有を使用したワークロード分離戦略を実装しました。プライマリクラスターをプロデューサーとして、16 ノードの ra3.4xlarge クラスターをデータ共有コンシューマーとして起動しました。データ共有アーキテクチャにより、コンシューマークラスターにコンシューマーワークロードを移行し、プロデューサーはデータ取り込みに集中することで、プライマリクラスターのサイズを増やすことなく成長に対応できました。 分散アーキテクチャの利点を認識した同社は、ワークロードを Amazon Redshift Serverless に移行してアプローチを拡大し、ワークロード分離のためにデータ共有モデルをさらに活用しました。Amazon Redshift のリモートマテリアライズドビュー機能により、プロデューサークラスターが共有するデータ上に直接マテリアライズドビューを作成できるようになりました。各コンシューマークラスターが、固有のワークロードパターンに最適化されたマテリアライズドビューを構築できます。事前集約データセット、カスタム結合戦略、ワークロード固有のデータ分散を、プロデューサークラスターのパフォーマンスに影響を与えずデータの重複も不要で実現できました。プロデューサーウェアハウスは汎用的なエンタープライズニーズ向けに設計されたデータ分散とソート戦略を維持し、すべてのコンシューマーに対して一貫したデータ品質を提供します。一方、コンシューマーウェアハウスはリモートマテリアライズドビューを使用して、リアルタイムのプレイヤーアナリティクス、BI ダッシュボード、アドホックなデータサイエンスワークロードなど、固有の分析要件に合わせてクエリパフォーマンスを最適化しました。データ消費を最適化する分散アプローチは同社にとって不可欠でした。プロデューサークラスターを信頼できる唯一の情報源 (Single Source of Truth) として維持し、冗長なデータコピーの管理負荷を回避しながら、多様な分析ワークロード全体で高速なクエリパフォーマンスを実現しました。 ベストプラクティス 新機能を最大限に活用するために、以下のベストプラクティスを検討してください。 Amazon Redshift クラスターおよび Serverless ワークグループで同時実行スケーリングを有効にし、ETL やユーザークエリの実行をさらに高速化して、レポートやダッシュボードのパフォーマンスを安定させましょう。 Amazon Redshift プロビジョンドクラスターおよび Serverless ワークグループの両方で、適切な MaxRPU 設定により同時実行スケーリングの使用制限を設定しましょう。予期しない追加コストの発生を防げます。詳細については、Amazon Redshift の使用制限に関するドキュメントを参照してください。 リモート MV を使用して、リソース集約型の MV 作成やリフレッシュ操作をプライマリウェアハウスからリモートデータ共有クラスターにオフロードしましょう。 まとめ 本記事では、MV リフレッシュの新機能、リモートテーブル DDL 機能、ゼロ ETL および S3 自動コピー向けの同時実行スケーリングサポートの拡張について紹介しました。各機能により、単一ウェアハウスの制約を超えることができます。複数環境にまたがる動的テーブル管理を必要とし、データの一貫性を維持しながら変化するワークロードに迅速に適応する分散データアーキテクチャを管理する組織にとって特に価値があります。利用を開始するには、最新の Amazon Redshift バージョン を実行していることを確認してください。続いて Amazon Redshift のドキュメントで 同時実行スケーリング 、 データ共有 、 マテリアライズドビュー の詳細をご覧ください。 著者について Raza Hafeez Raza は、Amazon Redshift のシニアテクニカルプロダクトマネージャー。エンタープライズデータウェアハウスの構築と最適化に 15 年以上の経験があり、あらゆる規模のお客様にとってクラウドアナリティクスを利用しやすく費用対効果の高いものにすることに注力しています。 Ravi Animi Amazon Redshift チームのシニアプロダクトリーダー。空間アナリティクス、ストリーミングアナリティクス、クエリパフォーマンス、Spark インテグレーション、アナリティクスビジネス戦略など、Amazon Redshift クラウドデータウェアハウスサービスの複数の機能領域を管理しています。リレーショナルデータベース、多次元データベース、IoT 技術、ストレージおよびコンピュートインフラサービスの経験があり、最近では人工知能 (AI) とディープラーニング、コンピュータビジョン、ロボティクスの分野でスタートアップの創業者としての経験もあります。 Satesh Sonti Satesh は、アトランタ拠点のプリンシパルアナリティクススペシャリストソリューションアーキテクト。エンタープライズデータプラットフォーム、データウェアハウジング、アナリティクスソリューションの構築を専門としています。20 年以上にわたり、世界中の銀行・保険のお客様向けにデータ資産の構築と複雑なデータプラットフォームプログラムのリードに携わっています。 Milind Oke Amazon Web Services で 3 年間勤務するシニア Redshift スペシャリストソリューションアーキテクト。AWS 認定ソリューションアーキテクト – アソシエイト、セキュリティ – 専門知識、アナリティクス – 専門知識を保有。ニューヨーク州クイーンズ在住。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 6 月 29 日 に公開された「 Amazon Redshift delivers faster performance for BI dashboards and real-time analytics 」を翻訳したものです。 ビジネスインテリジェンス (BI) ダッシュボードとリアルタイム分析は、迅速な意思決定に欠かせないツールです。現代のデータウェアハウスは、複雑で長時間実行される分析クエリに優れるだけでなく、インタラクティブなリアルタイム体験を支える短時間のアドホッククエリにもサブ秒のレスポンスタイムを実現する必要があります。エージェントが大量のデータから新たなインサイトを探索・導出するようになった今、低レイテンシーの要件はさらに重要になっています。朝のダッシュボードで KPI を確認する経営層から、エージェントを使ってデータセットをインタラクティブに探索するデータアナリストまで、クエリが高速かつ安定した応答を返すことへの期待は明確です。 Amazon Redshift はこうしたユースケース向けに長年最適化されてきました。BI やリアルタイム分析ワークロードのクエリパフォーマンスを向上させるため、結果キャッシュ、マテリアライズドビュー、自動ワークロード管理 (AutoWLM) など、多くの機能を導入しています。こうした機能により、数千のお客様がレスポンスの良いダッシュボードやリアルタイムアプリケーションを Amazon Redshift 上に構築してきました。しかし、インタラクティブ分析ではミリ秒単位の差が重要です。ダッシュボードの読み込み高速化と探索的クエリの応答時間短縮に引き続き注力しています。 本日、Amazon Redshift の新しいパフォーマンス最適化を発表します。リアルタイム分析アプリケーションや BI ダッシュボードが生成する低レイテンシー SQL クエリのレスポンスタイムを改善する機能です。SQL クエリの実行準備にかかる時間を短縮することで、クエリレイテンシーが改善されます。クエリの開始が速くなるため、結果もより早く返されます。 最適化の仕組み 今回の改善を理解するために、まず Amazon Redshift の既存のコアパフォーマンス機能であるコード生成について説明します。コード生成は、各 SQL クエリを分析し、クエリ固有の C++ コードを内部的に生成する最適化手法です。生成されたコードはコンパイルされ、利用可能な Amazon Redshift コンピューティングノード全体で並列実行されて結果を返します。コード生成は Amazon Redshift のクエリパフォーマンスの基盤であり、複雑な分析クエリを高い効率で実行します。 コード生成により高いクエリ実行性能を実現する一方で、新しいクエリは初回実行時に一度だけコンパイルの負荷が発生します。Amazon Redshift はすでにコンパイル済みコードをキャッシュしており、 Amazon Redshift フリート内のクエリの 99% 以上がキャッシュされた生成コードで実行され 、コンパイルの負荷は発生しません。まだキャッシュされていないクエリの場合、初回コンパイルの負荷は高速実行クエリ (ミリ秒や 1 桁秒台のクエリなど) で特に顕著で、全体の実行時間に対して大きな割合を占めることがあります。 今回の最適化により、Amazon Redshift はコンパイルの負荷を軽減します。具体的には、Amazon Redshift がクエリを受信すると、まずフリート内で過去に類似クエリを実行した際の最適化済みコンパイル済み C++ コードがキャッシュに存在するかを確認します。存在する場合は最高のパフォーマンスを得るためにそのコードを使用します。存在しない場合、Amazon Redshift は新しいクエリコンパイル最適化を適用し、コンポジションを使ってクエリを即座に処理します。コンポジションは、既存のロジックの軽量な組み合わせを生成する手法です。同時に、クエリ固有の最適化コードを作成し、利用可能なコンピューティングリソース全体でコンパイル・実行してパフォーマンスをさらに向上させます。コンポジションにより、コンパイルがクエリ実行のクリティカルパスから外れ、バックグラウンドでコンパイルが進行する間に即座に実行を開始できます。その結果、Amazon Redshift で処理される新しいクエリの開始が速くなり、2 回目以降の実行と同等のパフォーマンスが得られます。 コンポジションにより初回クエリの開始が大幅に高速化される一方、繰り返し実行されるクエリは Amazon Redshift のコード生成がもたらす優れた価格性能比の恩恵を引き続き受けられます。 重要な点として、このパフォーマンス最適化を利用するためにユーザー側の操作は不要です。Amazon Redshift が利用可能なすべての AWS リージョンにおいて、プロビジョンドクラスターまたはサーバーレスワークグループのすべてのユーザーのすべての SQL クエリにデフォルトで有効化されており、追加費用はかかりません。 実環境でのパフォーマンス結果 Amazon Redshift のお客様クラスターに対する今回の最適化の効果を分析しました。コンパイルキャッシュでキャッシュヒットせず、コンパイルが必要だった 1% のクエリセグメントのコンパイル時間を測定しました。次のグラフがその結果です。最適化前の P50 コンパイル時間は 4.3 秒でした。最適化後は 25.7 倍短縮され、170 ミリ秒になりました。 今回の最適化により、BI ダッシュボードの読み込みが速くなり、インタラクティブな探索がよりレスポンシブになり、リアルタイム分析アプリケーションがより低レイテンシーでインサイトを提供できます。 お客様の声 「FastCompile クエリパフォーマンス機能を有効にしたクラスターで、Amazon Redshift がコールドクエリ実行のパフォーマンスを大幅に改善したことを確認しました。コンパイル時間が 12 秒から 5 秒に短縮され、2.4 倍高速なクエリパフォーマンスを達成したことを受け、分析ソリューションとして Amazon Redshift を採用しました」 — Vijay Hiremath 氏 (Intuit、Group Manager、Business Platforms) 「中国の大手酒類企業のデータプラットフォームリーダーとして、エンタープライズデータウェアハウスに Amazon Redshift を活用しています。多様な分析クエリパターンがあるため、初回コンパイル時のパフォーマンスに課題がありました。Redshift の新しいコールドクエリコンパイル強化機能をテストしたところ、コールドクエリがウォームクエリとほぼ同等の速度で実行されるようになり、多様なクエリで大幅な速度改善が見られました」 — Yujie Wang 氏 (JNC、Data Platform Leader) 「約 85 GB のデータを日次で複雑な ETL パイプライン (複数テーブル、混合 DML 操作) を通じて処理し、1.7 TB の Amazon Redshift データウェアハウスに格納する中規模のお客様において、fast compile 機能の強化によりメンテナンス後の ETL パイプラインが 25% 高速化されました。データロードが早く完了し、アナリストがより迅速に意思決定できるようになりました」 — Jagan Mohan 氏 (Algonomy、Product Engineering Head) 技術の詳細については、 VLDB 2026 Boston カンファレンス に採択された論文「 FastCompose: Eliminating compilation cold starts in query execution with composition 」をご覧ください。 あらゆるワークロードに対して業界最高の価格性能比 今回の最適化の効果を示すため、業界標準の TPC-DS ベンチマークから派生したベンチマークを使用して、短時間実行の BI 型低レイテンシーワークロードをシミュレーションしました。3 ノード RG xlarge の Amazon Redshift クラスター上で、比較的小規模な 100 GB のスケールでワークロードを実行しました。このクラスターサイズとスケールでは、クエリはミリ秒から 1 桁秒台で完了し、一般的な BI ダッシュボードで期待されるレイテンシーに相当します。派生 TPC-DS ベンチマークには 99 の異なるクエリが含まれ、レポートクエリ、アドホック分析、データ探索パターンなど、現実的なビジネスインテリジェンスワークロードの組み合わせを表しています。テストでは、Amazon Redshift RG クラスターでのコールド 1 回実行と、同等の他社クラウドデータウェアハウスでの同様の実行を比較しました。ウェアハウスを起動し、データをロードし、99 クエリを 1 回実行して、合計実行時間とクエリの幾何平均を測定しました。その他のクラスターウォームアップやセットアップは行っていません。今回のクエリパフォーマンス改善はハードウェアに依存しません。Amazon Redshift でサポートされるすべてのハードウェアインスタンスタイプ (プロビジョンドクラスターの RA3 と RG、サーバーレスワークグループをサポートするハードウェア) で動作します。 結果を以下の表にまとめ、続くグラフに要約しています。今回の最適化により、Amazon Redshift は短時間クエリに対して最速の実行時間と幾何平均を最低コストで実現し、新しいクエリに対して他社の主要データウェアハウスの最大 8.3 倍の価格性能比を達成しています。 . コスト/時間 実行時間 (秒) 幾何平均 (秒) 実行時間比較 幾何平均比較 幾何平均価格性能比 Redshift 3-node RG.xlarge $2.28 235 1.7 ベースライン ベースライン ベースライン Alternative Warehouse A $3.00 327 2.3 1.4 倍遅い 1.3 倍遅い 1.7 倍高コスト Alternative Warehouse B $4.00 538 3.4 2.3 倍遅い 2 倍遅い 3.4 倍高コスト Alternative Warehouse C $6.00 907 5.5 3.9 倍遅い 3.2 倍遅い 8.3 倍高コスト まとめ Amazon Redshift の新しいクエリ起動最適化は、分析ワークロード全体にわたる高速パフォーマンスへの取り組みの一環です。コンパイルの負荷を軽減することで、BI ダッシュボードやリアルタイム分析アプリケーションのレスポンスを向上させつつ、定評のあるクエリ実行パフォーマンスを維持しています。 すべての Amazon Redshift ユーザーに自動的に有効化されているため、すぐに効果を体験できます。設定変更やクエリの書き換えは不要です。既存のクエリがそのまま高速に実行されます。 詳細については、 Amazon Redshift をご覧ください。 Amazon Redshift Serverless を使えば、データウェアハウスインフラストラクチャのセットアップや管理なしに数分でクエリを開始できます。パフォーマンスのベストプラクティスについては、 Amazon Redshift Database データベース開発者ガイド  を参照してください。 ワークロードに最適な価格性能比を見つける 本記事で使用したベンチマークは業界標準の TPC-DS ベンチマークから派生したもので、以下の特徴があります。 スキーマとデータは TPC-DS をそのまま使用しています。 クエリは TPC-DS から変更せずに使用しています。ウェアハウスがデフォルトの TPC-DS クエリの SQL 方言をサポートしていない場合は、TPC 承認済みのクエリバリエーションを使用しています。 テストには 99 の TPC-DS SELECT クエリのみが含まれます。メンテナンスとスループットのステップは含まれていません。 TPC-DS キットのデフォルトランダムシードで生成したクエリパラメーターを使用して、単一のパワーランを実行しました。単一のコールド実行の合計実行時間と幾何平均を結果として使用しています。 価格性能比は、幾何平均 (秒) を 1時間あたり 3,600 秒で除算し、ウェアハウスの時間あたりのコストを乗算して算出しています。結果はクエリあたりの幾何平均コストに相当します。すべてのデータウェアハウスで公表されているオンデマンド価格を使用しています。 Cloud Data Warehouse Benchmark と呼ぶこのベンチマークは、 GitHub で公開されているスクリプト、クエリ、データを使用して結果を再現できます。TPC-DS ベンチマークから派生したものであり、仕様に準拠していないため、公表された TPC-DS 結果とは比較できません。 ワークロードにはそれぞれ固有の特性があります。初めて検討する場合は、概念実証 (PoC) が要件に対する Amazon Redshift のパフォーマンスを理解する最良の方法です。PoC を実行する際は、適切なクラスターサイジングと適切な指標 (時間あたりのクエリ数であるクエリスループットと価格性能比) に焦点を当ててください。概念実証の 支援をリクエスト するか、 システムインテグレーションおよびコンサルティングパートナー と協力することで、データに基づいた意思決定が可能です。 Amazon Redshift の最新の開発状況を把握するには、 What’s New in Amazon Redshift の RSS フィードをご購読ください。 著者について Stefan Gromoll Amazon Redshift の Principal Engineer として、スタック全体にわたる Redshift のパフォーマンスを担当しています。余暇には料理、3 人の息子との遊び、薪割りを楽しんでいます。 Ravi Animi Redshift チームの Senior Product Management リーダーとして、Amazon Redshift クラウドデータウェアハウスサービスのパフォーマンス、クエリ処理、マテリアライズドビュー、空間分析、ストリーミング分析、移行戦略など複数の機能領域を管理しています。リレーショナルデータベース、多次元データベース、IoT テクノロジー、ストレージおよびコンピューティングインフラストラクチャサービスの豊富な経験があり、AI/ディープラーニング、コンピュータービジョン、ロボティクスを活用したスタートアップ創業者としての経験もあります。Washington Univ. St. Louis で物理学と電気工学の学士号を、Stanford で工学修士号を、Chicago Booth で MBA を取得しています。 Venkat Govindaraju Amazon Web Services (AWS Redshift) の Principal Engineer として、大規模データ管理システムの構築、最適化、スケーリングに 25 年以上の経験があります。University of Wisconsin-Madison でコンピューターサイエンスの Ph.D. を取得し、コンパイラ支援による動的ハードウェア特殊化を通じたエネルギー効率の高いコンピューティングを研究しました。分散システム、クエリエンジン、ハードウェアとソフトウェアの協調設計に精通し、VLDB、SIGMOD、MICRO、ISCA など一流会議での発表実績と複数の米国特許を保有しています。過去には Facebook、Oracle Labs、Epic Systems に在籍していました。 Kiran Chinta Amazon Redshift エンジニアリングチームの Senior Development Manager です。Amazon Redshift の主要機能を複数リードしてきた実績があります。Amazon Web Services、IBM、その他の企業でソフトウェアエンジニアリングチームをリードした豊富な経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。