Amazon Relational Database Service (Amazon RDS) for SQL Server は、マルチ AZ 配置におけるブロックレベルレプリケーションによる高可用性を導入することで、SQL Server 2022 Web Edition を強化しました。以前は、高可用性機能は Always On 可用性グループやデータベースミラーリングなどの技術を通じて、Enterprise Edition と Standard Edition に限定されていました。この新しい機能により、Web ホスターや Web 付加価値プロバイダー (VAP) がパブリックでインターネットアクセス可能な Web ページ、Web サイト、Web アプリケーション、Web サービスをホストするために設計された SQL Server Web Edition に、エンタープライズグレードの可用性がもたらされます。 このリリースにより、運用オーバーヘッドを大幅に削減しながら、高可用性データベースを迅速にセットアップし、維持することができます。この投稿では、ブロックレベルレプリケーションの利点と開始方法について説明します。詳細については、 Amazon RDS での Microsoft SQL Server のライセンス をご覧ください。 ソリューション概要 Amazon RDS のマルチ AZ 配置は、同期されたスタンバイデータベースインスタンスを維持することで高可用性を実現します。Amazon RDS for SQL Server は従来から様々なレプリケーション技術をサポートしてきましたが、この新しいソリューションは特にブロックレベルレプリケーションを活用して、プライマリインスタンスとスタンバイインスタンス間でストレージを同期します。このアプローチにより、データベースの冗長性を維持するためのより合理化された効率的な方法が提供されます。 SQL Web edition のマルチ AZ がサポートされているバージョンは次の通りです。 SQL Server 2022: Web Edition 16.00.4215.2.v1 または、それ以上のバージョン Microsoft SQL Server Web Edition について、ブロックレベルレプリケーションを使用したマルチ AZ 配置が可能なのは、16.00.4215.2.v1 以上のバージョンで新規作成またはアップグレードされた DB インスタンスのみであることに注意してください。 最新のバージョンサポートについて最新情報を得るには、 RDS ドキュメント を参照してください。 マルチ AZ 配置では、Amazon RDS が異なるアベイラビリティーゾーンに同期スタンバイレプリカを自動的にプロビジョニングし、維持します。フェイルオーバーが完了するまでの時間は、プライマリ DB インスタンスが利用できなくなった時点でのデータベースアクティビティやその他の条件によって異なります。フェイルオーバー時間は通常 60 ～ 120 秒です。ただし、大規模なトランザクションや長時間の復旧プロセスにより、フェイルオーバー時間が長くなる場合があります。 プライマリインスタンスのデータは、ブロックレベルでスタンバイインスタンスに同期的にレプリケートされ、サーバーレベルのオブジェクトや設定を含む完全なデータ冗長性を提供します。計画外のサービス中断が発生した場合、Amazon RDS は自動的にスタンバイインスタンスにフェイルオーバーします。フェイルオーバープロセス全体を通じて同じ DNS エンドポイントが維持されるため、アプリケーションの接続文字列を再設定する必要がなくデータベース操作を最小限の中断で再開できます。 AWS Management Console 、 AWS Command Line Interface (AWS CLI)、または AWS SDK を使用して、マルチ AZ オプション付きの新しい RDS SQL Server Web Edition データベースインスタンスを作成したり、既存の Web Edition データベースインスタンスをシングル AZ からマルチ AZ に変更したりできます。 前提条件 開始するには、以下のリソースが必要です： 適切な権限 を持つ AWS アカウント SQL Server Management Studio (SSMS) がインストールされ、Amazon RDS との通信を許可するセキュリティグループルールが設定された Windows EC2 インスタンス (オプション) AWS CLI の インストールと設定 このソリューションには新しい AWS リソースが必要で、コストが発生します。実装前に AWS 料金 を確認してください。 本番環境以外の環境でこの設定をテストし、本番環境への適用前に完全な検証を実行することを強く推奨します。 マルチ AZ の DB インスタンス作成 DB インスタンスを作成する前に、AWS リージョンとバージョン の可用性を確認して、RDS インスタンスをホストしたいリージョンで SQL Server エディションとバージョンの組み合わせが有効になっていることを確認してください。 マルチ AZ の Amazon RDS インスタンスを作成するには、以下の手順を実行してください： Amazon RDS コンソールで、ナビゲーションペインの「データベース」を選択します。 「データベースの作成」を選択します。 「標準作成」を選択します。 基本設定を構成します： エンジンタイプで「Microsoft SQL Server」を選択します。 データベース管理タイプで「Amazon RDS」を選択します。 エディションで「SQL Server Web Edition」を選択します。 バージョンで「16.00.4215.2.v1」を選択します。 インスタンス識別子に、インスタンスの名前を入力します。 設定で、以下を構成します： プライマリユーザー名とパスワードを入力します。 必要に応じて DB インスタンスクラスを指定します。 ストレージタイプとサイズを設定します。 可用性と耐久性で、マルチ AZ 配置について「はい (ブロックレベルレプリケーション)」を選択します。 接続の設定で、仮想プライベートクラウド (VPC) とサブネットグループを選択します。 パブリックアクセスについては、「いいえ」を選択します。 VPC セキュリティグループについては、既存を選択し、作成したセキュリティグループを選択します。 「データベースの作成」を選択します。 Amazon RDS が マルチ AZ Amazon RDS インスタンスをプロビジョニングするまで待機します。 または、AWS CLI を使用して マルチ AZ インスタンスをデプロイすることもできます。Windows 上で AWS CLIを 使用してSQL Server Web edition の RDS インスタンスを作成するには、次のコマンドを使用します： aws rds create-db-instance ^ --db-instance-identifier sqlserver-web-demo ^ --engine sqlserver-web ^ --engine-version 16.00.4215.2.v1 ^ --license-model license-included ^ --master-username master ^ --master-user-password password ^ --db-instance-class db.m5d.4xlarge --allocated-storage 16000 ^ --storage-type io2 --iops 64000 ^ --multi-az ^ --storage-encrypted ^ --region us-east-1 Code MacOS/Linux で AWS CLI を使用して SQL Server Web edition の RDS インスタンスを作成するには、以下のコマンドを使用してください： aws rds create-db-instance \ --db-instance-identifier sqlserver-web-demo \ --engine sqlserver-web \ --engine-version 16.00.4215.2.v1 \ --license-model license-included \ --master-username master \ --master-user-password password \ --db-instance-class db.m5d.4xlarge \ --allocated-storage 16000 \ --storage-type io2 \ --iops 64000 \ --multi-az \ --storage-encrypted \ --region us-east-1 Code 接続と設定確認 設定を確認するために、以下の手順を完了してください： Session Manager を使用して Amazon EC2 インスタンスに接続します。 SSMS を起動し、以下の情報で接続します： サーバー名：Amazon RDS for SQL Server インスタンスのエンドポイント 認証：SQL Server 認証 ログイン資格情報：作成時に指定したもの 新しいクエリウィンドウを開き、以下のクエリを実行してデータベースとテーブルを作成します： USE master ; GO CREATE DATABASE MAZDB ; GO USE MAZDB ; GO CREATE TABLE dbo . test ( ID int identity ( 1 , 1 ) primary key , [ Desc ] char ( 100 ) ) GO INSERT INTO dbo . test VALUES ( 'RDS MAZ' ) GO 50 SELECT COUNT ( * ) FROM dbo . test ; GO SQL データベースが作成され、50 件のレコードがテーブルに挿入されるのを確認できます。 フェイルオーバーの実行 コンソールを使用してフェイルオーバー機能をテストできます。フェイルオーバープロセスは、セカンダリノードを新しいプライマリインスタンスに昇格させます。プライマリのアベイラビリティーゾーンが変更されたことも確認できます。以下の手順を実行してください： Amazon RDS コンソールで、インスタンスを選択します。 アクションメニューで、再起動を選択します。 フェイルオーバーありで再起動を選択します。 再起動を確認します。 フェイルオーバーを伴う再起動操作により、短時間のダウンタイムが発生します。アプリケーションへの影響を最小限に抑えるため、オフピーク時間帯にスケジュールしてください。 または、AWS CLI を使用してフェイルオーバーを開始することもできます： aws rds reboot-db-instance \ --db-instance-identifier sqlserver-web-demo \ --region us-east-1 \ --force-failover Code フェイルオーバー後のステータス確認 フェイルオーバープロセスが完了したら、新しいプライマリインスタンスに接続して、以前に作成されたデータベースが利用可能な状態にあり、クエリを実行できることを確認できます。以下の手順を実行してください： Windows EC2 インスタンスにリモートデスクトップ接続します (以前の接続が切断されている場合)。 検索ウィンドウで SSMS を検索し、「接続」を選択して「データベースエンジン」を選択します。 サーバー名には、RDS for SQL Server のエンドポイントを入力します。 RDS for SQL Server インスタンスを作成する際に指定したログインとパスワードの詳細を入力します。 「接続」を選択します。 新しいクエリウィンドウを開いて、データアクセシビリティを確認してください： USE MAZDB ; GO SELECT COUNT ( * ) FROM dbo . test ; GO SQL 50 行が返されることを確認してください。 コンソールに新しいアベイラビリティーゾーンが反映されるまで数分かかります。 制限事項 このソリューションの制限事項の詳細については、 Microsoft SQL Server DB インスタンスの制限事項 を参照してください。 クリーンアップ 継続的な課金を避けるために、この投稿の一部として作成したリソースを削除してください： RDS インスタンスを削除する 。 EC2 インスタンスを削除する 。 結論 この投稿では、SQL Server Web Edition の マルチ AZ RDS インスタンスをセットアップし、フェイルオーバーテストを通じてその高可用性機能を検証する方法を紹介しました。 この新機能により、運用オーバーヘッドを削減しながら、データベースの高可用性を実装するプロセスが簡素化されます。手動での設定とメンテナンスの必要性を最小限に抑えることで、事業継続性とアプリケーションの可用性要件をより適切に満たすことができます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Ram Yellapragada Ram は、Amazon RDS チームのシニアデータベースエンジニアです。彼は AWS に 5 年以上在籍しています。RDS 製品の開発に従事し、特に マルチ AZと耐久性機能に注力しています。それ以前は、様々な業界のお客様と協力し、AWS クラウドにおける複雑なデータベースソリューションの設計、開発、展開に関する豊富なコンサルティング経験を持っています。 Nirupam Datta Nirupam は、AWS のシニアテクニカルアカウントマネージャーです。彼は AWS に 5 年以上在籍しています。データベースエンジニアリングとインフラアーキテクチャにおいて 13 年以上の経験を持ち、Amazon RDS コアシステムと Amazon RDS for SQL Server のスペシャリストでもあります。彼はお客様に技術支援を提供し、AWS クラウドでの移行、最適化、そして導入の道のりをガイドしています。 Shirin Ali Shirin は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。お客様のアーキテクトに対してデータベースソリューションを AWS に移行することを支援しています。AWS 入社以前は、エネルギーおよび教育業界セグメントにおいて、本番環境およびミッションクリティカルなデータベース実装をサポートしていました。

こんにちは。AWS シニアソリューションアーキテクトの崔 祐碩です。首都圏を中心に 125 店舗のスーパーマーケットを展開する サミット株式会社 （以下、サミット）では、DX 推進の一環として AI コーディングアシスタント「 Kiro 」を活用し、情報システム部門が自らの手で業務アプリケーションを素早く形にする取り組みを進めています。本ブログでは、サミット 情報システム部 企画・開発グループの小池様に、Kiro 導入の背景や具体的な活用事例、今後の展望について伺いました。 サミット株式会社について サミット株式会社は、東京・神奈川・埼玉・千葉の 1 都 3 県で 125 店舗を展開するスーパーマーケットチェーンです。1963 年の設立以来、「嘘の無い仕事」を経営理念に掲げ、売上高約 3,488 億円（2025 年 3 月期）、従業員数約 18,000 名の規模で事業を展開しています。「サミットが日本のスーパーマーケットを楽しくする」という事業ビジョンのもと、お客様一人ひとりに寄り添う店舗づくりとリテイル DX の推進に取り組んでいます。 Kiro との出会い ― 「これは運命でした」 DX 推進における課題 ― 「作りたいもの」が形にならない AWS： そうした課題を抱える中で、 Kiro とはどのように出会われたのでしょうか？ 小池様： もともとはコードエディタを使って、チャットボットの画面でコードを書いてはコピー＆ペーストする、というループでコーディングをしていました。他の AI コーディングツールも使っていましたが、当時の生成 AI が読み込めるコンテキスト量と、出力されるコードの品質には限界がありました。 様々な AI コーディングツールが出てきた中で、AWS の担当者からの紹介もあり、 Amazon Q Developer を試していたところ、ちょうど Kiro がリリースされたんです。自然な流れでたどり着いた、まさに運命的な出会いでしたね。 AWS： 他のツールと比較して、Kiro を選ばれた決め手は何でしたか？ 小池様： 開発ツールの選択は好みの問題になりがちですが、企業として使っていく上での条件を考えると、Kiro が最もリスクが少なく安心できるものでした。ポイントは大きく 3 つあります。 シンプルさと展開のしやすさ： Kiro はインストールしてログインすれば、すぐに使い始められます。初期設定の手間が少なく、環境の再現性が高いため、チームへの展開もスムーズです。 ガバナンス： Kiro はログインしないと使えない。これは企業利用において非常に重要です。拡張性が適切に管理されていることも、ガバナンスの観点ではメリットになります。何でもできてしまう環境は、統制が効かなくなるリスクがあります。 クラウドとの統合： AWS のバックエンドと統合したプロダクトを作ることを考えると、Kiroを使っておけば開発環境からクラウドまで一貫した体験が得られるという安心感があります。 つまり、「王道」のやり方ができるツールだと感じました。スタンダードで、シンプルで、ガバナンスが効く。企業の情報システム部門が安心して採用できるツールだと思います。 Kiro で作ったもの 事例 ① ：店舗クラスター分析ダッシュボード ― 12 時間で PoC を実現 AWS： 具体的に Kiro で開発されたものを教えてください。 小池様： 最初の事例は、リテイル DX チームからの依頼で作った店舗データの分析ダッシュボードです。店舗の従業員に対して、クラスター分析の結果を可視化して見せたい、PoC をやってみたいという要望がありました。 当初はBIツールなどを導入する話もありましたが、PoCの段階では新たなツールの導入には時間とコストがかかります。費用対効果が見えない中での意思決定にも時間を要するため、まずは自分の手で素早く形にしてみようと考えました。 AWS： 実際にどのくらいの時間で完成したのでしょうか？ 小池様： 初期バージョンは約 12 時間で完成しました。HTML ベースで Excel データを読み込んで表示するダッシュボードです。Kiro の Spec-driven Development の機能を活用して、要件から設計、実装までを一気に進めました。 店舗データ分析 BI ツール AWS： DX チームの反応はいかがでしたか？ フィードバックからすぐ改善 小池様： 「こんなにすぐできたの？」という驚きの声がありましたね。フィードバックを受けて修正する作業も、5 時間程度で何回かのイテレーションを回せました。しかも、別の打ち合わせをしながら、Kiro にプロンプトを投げて結果を待つ間に会議に参加する、という並行作業ができたんです。 フィードバックの内容も、機能を減らしたいとか、表示するタブやグラフの切り替え、初期データの自動読み込みといった調整レベルのもので、設定の切り替えで対応できるものがほとんどでした。 AWS： 従来のアプローチだと、同等のものを作るのにどのくらいかかると見積もられますか？ 小池様： 通常、このような PoC を外部に依頼する場合、要件定義からパートナーとの契約、見積もり、稟議、発注というプロセスだけで 1〜2 か月はかかります。開発自体も 1〜2 人月程度は見込まれ、全体では少なくとも 3 か月、費用も数百万円単位になることが一般的です。それが Kiro を使うことで、一人の担当者が 12 時間 + フィードバック対応 5 時間で実現できたというのは、非常に大きなインパクトです。 事例 ② ：3D インタラクティブプレゼンテーション ― 外部発表資料を 1 日で AWS： 他にも Kiro で作られたものはありますか？ 小池様： Vibe コーディングの事例を外部に発表する機会がありました。外部への発表ですから、それなりにクオリティの高い資料が求められる場です。 最初は HTML ベースで資料を作り始めたのですが、途中で「せっかくなら 3D 効果を入れてみよう」と思い立ち、Three.js を使った 3D インタラクティブなプレゼンテーションに仕上げました。聴衆が自由に 3D 空間を動き回れるよ うな体験型の資料です。 AWS： 制作時間はどのくらいでしたか？ 小池様： 他の作業と並行しながらも、約 8 時間で完成しました。3D 効果を入れずにシンプルなスライドにするなら 1〜2 時間で終わったと思いますが、外部発表の場ということもあり、表現にこだわりました。 3Dバーチャル展示会を回遊しながら楽しむプレゼンテーション 通常、外部向けの発表資料は、構成の検討からデザインの調整まで含めると 1 週間程度かかることも珍しくありません。それが Kiro を活用することで 1 日で完成し、さらに 3D インタラクティブという新しい表現も実現できました。 この経験から、社内の部会資料や共有資料も HTML ベースで作れるようになるといいなと考えています。議事録やメモをマークダウンで書いて、Kiro でスライド化する。そういう文化が社内に根付けば、資料作成の負担は大幅に減る はずです。社内の便利ツールとしても展開していきたいですね。 事例 ③ ：店舗エリア分析マップ ― 国土地理院 API を活用した地図アプリ AWS： 最後にもう一つ、事例をご紹介いただけますか。 小池様： マーケティング業務で使う地図ベースのエリア分析ツールを Kiro で作りました。店舗番号を入力すると、国土地理院の API から市区町村のデータを取得して、対象エリアを地図上に可視化するものです。 例えば、特定のエリアに何人住んでいるのか、商圏の人口分布はどうなっているのか、といったことを視覚的に確認できます。 AWS： こちらの制作時間は？ 小池様： これも 12 時間未満ですね。もともとコードエディタでベースを作っていたものを Kiro で作り直したのですが、モデルも良くなっているので、かなり実用的なものに仕上がりました。外部 API との連携や地図の描画処理など、自分でゼロから調べてコーディングしようとすると相当な時間がかかる部分を、Kiro が一気にやってくれます。 店舗エリア分析マップ これからの夢 ― リバースエンジニアリングと、パートナーとの新しい協業 AWS： 今後、Kiro を使ってどのようなことに取り組みたいとお考えですか？ ① レガシーシステムのリバースエンジニアリングと刷新 小池様： 一番やりたいのは、レガシーシステムのリバースエンジニアリングです。 多くの企業で、過去に作られたシステムが「なぜ動いているか分からない」状態で残っていると思います。担当者が変わり、ドキュメントも残っていない。コードだけが正しい、という状況です。 Kiro を使えば、既存のコードからドキュメントを自動生成できます。実際に私はすでにこれを始めていて、コードを Kiro に読み込ませてリバースエンジニアリングでドキュメントを作らせています。 AWS： そこから先の展望も見えてきますね。 小池様： はい。まず、今まで見える化すらできなかったレガシーコードの中身が、ドキュメントとして可視化される。これだけでも大きな一歩です。そして、そのドキュメントをチームでレビューして内容を正しく整理したら、今度はそれをスペック（要件定義）として Kiro に渡して、要件に合った新しいシステムを AI で作り直す。 つまり、古いコード → ドキュメント化 → スペック整理 → 新規開発 という流れです。 今までは、このドキュメント化の工程自体が膨大な手作業で、現実的に手が付けられなかった。それが Kiro によって一気に可能になる。ドキュメントさえできれば、そこからメンテナンスもしやすくなりますし、新しいメンバーへの引き継ぎも格段に楽になります。 ② パートナーとの協業を「動くもの中心」に変える 小池様： もう一つの夢は、パートナーとの協業モデルを根本的に変えることです。 実は一部の案件で、Kiro で実際に動くモックアップ ― 単なる画面イメージではなく、実データを読み込んで画面遷移も動作もするレベルのもの ― を作って開発パートナーに渡すという試みを始めています。パートナーがその意図を正しく理解できた場合は、こちらの期待の 120% のものが返ってくることもあり、手応えを感じています。 これを全面的に展開していきたい。Kiro は Spec-driven Development なので、モックアップを作る過程で仕様書（ Spec ）も自動的に生成されます。つまり、動くモックアップと仕様書をセットでパートナーに渡せる。パートナーはコードと仕様書の両方を参照しながら本番実装を進め、レビュー会では動くものを見ながらその場で修正する。1〜2 回のイテレーションで最終版に近づけて、完成後はレビューを通じて更新された仕様書に加え、運用ドキュメントなども Kiro で追加生成する。 Kiro を活用した新しいアプローチ 従来はドキュメントだけが共通言語でしたが、新しいアプローチでは動くコードと Kiro が生成した仕様書の両方が共通言語になる。要件定義をドキュメントから始めるのではなく、動くものと仕様書を同時に作り、開発・レビューを経てドキュメントも一緒に育てていく。日本の IT 業界に根付いたウォーターフォール文化を、もう少しアジャイルに変えていけるのではないかと思っています。 Kiro を使うコツ ― セッション管理とステアリング AWS： Kiro を効果的に使うためのコツがあれば教えてください。 小池様： 一番大事なのは、セッション情報の管理です。AI コーディングツール全般に言えることですが、長時間の開発ではコンテキストの引き継ぎが重要になります。Kiro ではこれを効率的に管理する仕組みがあり、私はそれを積極的に活用しています。 私はプロジェクトごとにセッション情報を記録するルールを設けていて、Kiro に「このタイミングでセッション情報を保存して」と指示しています。再開時には、最新のセッション情報とプロジェクトメモリーを参照するようにルールで定義しています。 もう一つのポイントは、 Steering  の活用です。ステアリングには、プロジェクトごとの統制ルールや、セッション再開時に参照すべき情報、コーディング規約などを定義しています。例えば「セッション再開時はプロジェクトごとの最新セッション情報とプロジェクトメモリーを必ず参照すること」といったルールです。 さらに、Steering の内容自体も Kiro との対話を通じて作成できます。「こういうルールをステアリングに追加して」と指示すると、Kiro が内容を整理して記録してくれるため、開発環境の設定も対話の中で完結します。 今後の展望 AWS： 最後に、今後についてお聞かせください。 小池様： 私は Kiro を活用した AI 開発によって、コードの品質向上や開発スピードの改善を実感しています。この流れをチーム全体に広げていきたいと考えています。 そのためにも、Kiro が Web 経由でクラウド環境から利用できるようになることや、AWS のサービスとの連携がより深まっていくことに期待しています。ローカル PC への環境構築が不要になれば、開発経験が浅いメンバーでもすぐに使い始められます。チーム全員が統一された環境で AI 支援を受けながら開発できるようになれば、社内での活用をさらに拡大していけると考えています。 著者について 小池 朋昭（こいけ ともあき）の紹介 サミット株式会社 情報システム部にて、ハイブリッドクラウド化やレガシー刷新をPM／テックリードとして推進。データスチュワードとして全社データの活用基盤整備も主導。現在はVibe コーディングによる内製開発やアジャイル 開発体制の構築に取り組み、業務・IT・データを横断した全社DXを牽引している。 崔 祐碩 （Woosuk Choi）は AWS Japan Senior Solution Architect としてエンタープライズ・商社のお客様を担当し、データ分析基盤やプライベートクラウドの構築、DevOps/SREの運用経験を活かして、クラウド導入やData/AIソリューションの実装を支援しています。

Amazon Relational Database Service（以下、RDS）や Amazon Aurora（以下、Aurora）のリザーブドインスタンス（RI）は、オンデマンド料金と比較して大幅なコスト削減が可能です。しかし、RDS の RI には Amazon EC2 の RI とは異なり開始日時を指定した予約購入の機能がなく、購入 API を実行した時点で即座に課金が開始されます。そのため、大量の RI を短時間で正確に購入するには手動オペレーションでは負荷が高く、お客様にとって購入のハードルが高い状況となっています。 なお、第 7 世代以降のインスタンスで利用可能になった Database Savings Plans では予約購入が可能ですが、旧世代のインスタンスを利用されている場合は引き続き RI での購入が必要です。 本記事では、公共機関における RI 購入の制約を例に、RDS / Aurora の RI を効率的に一括購入するサンプルスクリプトをご紹介します。公共機関以外のお客様でも、大量の RI を正確に購入したいケースで参考にしていただけます。 背景 公共機関ではデータ保管場所や予算執行の都合により購入方法が限定されることが一般的です。例えば、次のような制約があります。 日本リージョン（東京・大阪）のみ 前払いなし（No Upfront）のみ利用可能 購入タイミングは 4/1 09:00:00〜09:59:59（JST） ※会計年度を1時間でもまたがないようにする場合 この制約のもとでは、限られた時間内に正確な購入を完了する必要があり、事後に間違いに気づいても購入を止めることが出来ません。そして、多数のアカウントが同じ時間帯に一斉に RI を購入する必要があることを考えると、手動オペレーションでは品質・工数の両面で課題があります。 この課題に対応するため、AWS CloudShell 上で動作する RDS RI 一括購入のサンプルスクリプトを用意しました。AWS CloudShell はブラウザからアクセスできるシェル環境で、AWS CLI や jq（JSON 処理ツール）などの主要ツールがプリインストールされているため、実行環境の準備を別途行う必要がありません。AWS マネジメントコンソールにログインできれば、すぐにスクリプトを実行できます。 前提条件 AWS CloudShell 環境（AWS CLI、jq がプリインストール済みのため、追加のセットアップは不要） IAM ロールに以下の権限が付与されていること rds:DescribeReservedDBInstancesOfferings rds:PurchaseReservedDBInstancesOffering rds:DescribeDBInstances sts:GetCallerIdentity 1アカウントあたり同一リージョンで保有可能なRIはデフォルト40件まで（ 参考 ）。超過する場合は事前にサービスクォータの引き上げを申請してください （参考）AWS CloudShell VPC environment を利用する場合 CloudShell VPC environment ではシェルが指定した VPC のサブネット内で動作するため、スクリプトが呼び出す AWS API（RDS、STS）へのネットワーク到達性を確保する必要があります。具体的には、以下のいずれかを構成してください。 AWS PrivateLink（VPC エンドポイント）による RDS API および STS API へのアクセス NAT Gateway を経由したインターネットアクセス（ご利用環境のシステム要件やセキュリティポリシーを確認のうえ実施してください） ネットワーク構成が不十分な場合、API 呼び出しがタイムアウトしスクリプトが正常に動作しません。 ※ 本記事執筆時点では、デジタル庁が提供するガバメントクラウド環境で AWS CloudShell を利用するには CloudShell VPC environment の構成が必要です。 （参考）CloudShellを使わずローカル端末から実行する場合 AWS CloudShell を使用せず、お手元のローカル端末から実行することも可能です。その場合、以下の点にご注意ください。 シェルスクリプト実行環境が必要です。Linux や macOS ではデフォルトシェルである bash や zsh が利用できます。Windows の場合は WSL（Windows Subsystem for Linux）上で実行してください。 AWS CLI（バージョン2推奨）および jq を事前にインストールしてください。 AWS 認証情報の設定が必要です。aws configure 、IAM Identity Center（aws sso login）、 aws login 等で、スクリプト実行前に認証情報を構成してください。 スクリプトはタイムゾーン Asia/Tokyo を使用して購入タイミングの判定を行います。OS のタイムゾーンデータが正しくインストールされていることを確認してください。 Linux：“cat /etc/timezone” 等 macOS：“sudo systemsetup -gettimezone” 等 準備 入力ファイル（input.csv）を準備してください（フォーマットは後述）。次に、rds-ri-launchpad.sh を CloudShell へアップロード、または GitHub から直接取得し、実行権限を付与してください。 GitHub から直接取得する場合の例 curl -O https://raw.githubusercontent.com/aws-samples/sample-rds-ri-bulk-purchase-script/main/rds-ri-launchpad.sh chmod +x rds-ri-launchpad.sh スクリプトの特徴 スクリプトは「ドライラン（検証）モード」と「購入モード」の 2 段階で動作します。ドライランモードでは実際の購入を行わず、入力内容の検証のみを実施します。 ドライランモード（デフォルト） ./rds-ri-launchpad.sh input.csv 前述のとおり、RDS の RI には開始日時を指定した予約購入の機能がありません。そのため、本スクリプトではドライランモードを用意し、購入直前までの検証を事前に実施できるようにしています。以下のチェックを実施できます。 日本リージョン（ap-northeast-1 / ap-northeast-3）のみであること 前払いなし（No Upfront）のみであること インスタンスクラス形式の妥当性（db.xxx.xxx 形式） エンジン名の許可リスト検証 DescribeReservedDBInstancesOfferings API による Offering（購入可能な RI の条件と価格の組み合わせ）の存在確認 実際に稼働中のインスタンスとの突合（購入数量が稼働数を超過していないかの警告） 購入は一切実行されないため、実際のRI購入日である 4/1 より前に安全に事前確認が可能です。 購入モード ./rds-ri-launchpad.sh --purchase input.csv --purchase オプションを指定することで、実際の購入を実行します。購入時にはドライラン時のチェック項目に加えて、以下の制御が行われます。 購入タイミングの確認 — 4/1 09:00:00〜09:59:59（JST）の範囲外の場合はアラートを発行し、続行するかの確認プロンプトを表示 最終確認プロンプト — 購入実行前に yes/no の確認を要求 入力ファイル CSV 形式で購入情報を定義します。1 行目のヘッダー行はスクリプトが自動的にスキップします。 こちらはサンプルファイルです。 region,db_type,instance_class,engine,multi_az,quantity,duration,payment_option ap-northeast-1,RDS,db.t3.medium,mysql,yes,2,1,No Upfront ap-northeast-1,Aurora,db.r5.large,aurora-mysql,no,3,1,No Upfront フィールド 説明 許容値 region リージョン ap-northeast-1, ap-northeast-3 db_type DB 種別 RDS, Aurora instance_class インスタンスクラス db.xxx.xxx 形式 engine エンジン aurora-mysql, aurora-postgresql, mysql, postgresql, mariadb, oracle-se2, sqlserver-ex multi_az Multi-AZ yes, no（Aurora の場合は無視） quantity 購入数量 1 以上の整数 duration 期間（年） 1, 3 payment_option 支払いオプション No Upfront（他の文字列の場合はエラー） セキュリティ上の考慮 基本的なパストラバーサル対策 — 入力ファイルパスに .. が含まれる場合は即座に終了 入力値の許可リスト検証 — エンジン名、リージョン、支払いオプションを許可リストで検証 ロックディレクトリ機構 — 同時実行を防止し、二重購入を回避 結果ファイルのパーミッション制限 — chmod 600 で所有者のみ読み取り可能 エラー出力のサニタイズ — アカウント ID や ARN をマスクして表示 set -euo pipefail — 未定義変数やパイプエラーを即座に検出 エラーハンドリング スクリプトは「行単位の継続処理」を採用しています。ある行でバリデーションエラーや Offering 取得失敗が発生した場合でも、該当行をスキップして次の行の処理を継続します。AWS 認証エラーなど回復不能なエラーの場合のみスクリプトを終了します。 実行結果は ri_purchase_result_YYYYMMDD_HHMMSS.txt に自動出力され、成功・失敗・スキップの件数と各行の詳細が記録されます。一部の処理が失敗した場合は、 失敗した行のみを記載した新しいCSVファイルを作成し、再実行することで手動リトライが可能です。 本スクリプトは1回の実行あたり10〜100行程度の入力を想定しています。大量の入力（100行超）を処理する場合、AWS APIのスロットリングが発生する可能性があります。その場合はCSVファイルを分割し、複数回に分けて実行してください 。 ダウンロード サンプルスクリプトは以下リンクよりダウンロード可能です。 sample-rds-ri-bulk-purchase-script まとめ 本スクリプトは、限られた購入時間枠の中で大量の RDS / Aurora の RI を安全かつ効率的に一括購入するためのサンプルです。ドライランモードで事前に購入内容を検証し、購入モードで実行するという 2 段階のアプローチにより、オペレーションミスのリスクを低減します。 免責事項 本記事で紹介するスクリプトはサンプルコードであり、AWS サポートの対象外です。本番環境での使用前に、必ずテスト環境で十分な動作確認を行ってください。 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。本ブログや添付資料は AWS サービスの変更・追加などにより今後修正される場合があります。本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン合同会社は一切の責任を負いません。上記ご了承の上、ご利用ください。 筆者について Hidenori Hiroki 廣木 秀典（Hidenori Hiroki）は、公共部門担当のTechnical Account Manager（TAM）。ポストフェーズにおけるお客様の課題解決をご支援しています。コスト最適化やセキュリティ設計など、お客様のクラウド活用を日々サポートしています。 Kazuki Fujimoto 藤本 一樹（Kazuki Fujimoto）は、パブリックセクターの自治体担当のソリューションアーキテクトです。自治体の基幹システムのクラウド移行やそれに伴うコスト最適化とモダナイゼーション、生成 AI の活用支援などをおこなっています。

本記事は 2026 年 3 月 11 日 に公開された「 Amazon Redshift DC2 migration approach with a customer case study 」を翻訳したものです。 この記事は、AWS パートナーである Classmethod のソリューションアーキテクト、石川 覚氏によるゲスト投稿です。 2025 年 4 月、AWS は Amazon Redshift DC2 インスタンスの廃止を発表し、Redshift RA3 インスタンスまたは Redshift Serverless への移行を推奨しました。Redshift RA3 インスタンスと Serverless はストレージとコンピューティングを分離する設計を採用しており、 データ共有 、書き込みの 同時実行スケーリング 、 zero-ETL 、 クラスターリロケーション などの新機能を提供します。 本記事では、あるお客様が DC2 から RA3 インスタンスへ移行した事例を紹介します。小売業の大手企業であるこのお客様は、BI と ETL ワークロード向けに 16 ノードの dc2.8xlarge クラスターを運用していました。データ量の増加とディスク容量の制約に直面し、Blue-Green デプロイメントアプローチで RA3 インスタンスへの移行に成功。ETL クエリパフォーマンスの向上とストレージ容量の拡大を、コスト効率を維持しながら実現しました。 Amazon Redshift のアーキテクチャタイプ Amazon Redshift には 2 つのデプロイオプションがあります。Provisioned モードではインスタンスタイプとノード数を選択し、必要に応じてリサイズを管理します。Redshift Serverless はデータウェアハウスのキャパシティを自動的にプロビジョニングし、基盤リソースをインテリジェントにスケーリングします。次の図は、これら 2 つのアーキテクチャタイプを比較したものです。 Provisioned クラスターはクラスターサイズを事前に決定する必要がありますが、リザーブドインスタンス (RI) の購入や一時停止・再開のスケジューリングでコストを最適化できます。Serverless は必要に応じてリソースを自動プロビジョニングし、消費したコンピューティングリソースに対してのみ課金される従量課金モデルです。両サービスとも相互移行をサポートし、SQL、zero-ETL、Federated Query などの同じ機能を提供します。料金の詳細は Amazon Redshift の料金 をご覧ください。 Provisioned クラスターは大規模で予測可能なワークロードに適しており、キューイングに基づく自動スケーリングを提供します。Serverless は変動するワークロードに対して管理不要の自動スケーリングを提供し、ワークロードの複雑さとデータ量に基づいてスケーリングする AI 駆動の最適化 を備えています。詳細は Amazon Redshift Serverless とプロビジョニング済みデータウェアハウスの比較 をご覧ください。 お客様事例：DC2 インスタンスからの移行 このセクションでは、お客様の Amazon Redshift DC2 から RA3 インスタンスタイプへの移行について説明します。 Blue-Green デプロイメント アプローチを採用し、ダウンタイムを最小限に抑えながらコスト最適化とパフォーマンス向上の両方を達成しました。 お客様のワークロードには以下の特徴がありました。 ユースケース お客様の Amazon Redshift の主なユースケースは以下のとおりです。 営業時間中の BI ツールによるクエリ 大量の読み取りクエリ 月曜日と月初にアクセスがピークに達する 早朝のデータ処理 データロードと変換のための書き込みクエリが集中 定常的なワークロード特性 1 日 16 時間以上クエリを実行 要件 お客様の Amazon Redshift 移行における主な要件は以下のとおりです。 パフォーマンス ピークアクセス時に自動スケーリング (同時実行スケーリングなど) を使用 データサイズ ディスク容量の拡張が必要 コスト管理 予算の予測と管理が容易であること 長期利用向けの割引サービスを活用 互換性 既存のアプリケーションと BI ツールとの互換性を維持 エンドポイントの変更を回避 可用性 移行中の最大ダウンタイムは 8 時間まで許容 ネットワーク 既存の 2 アベイラビリティーゾーン (AZ) サブネット構成を変更しない 移行タイミング 負荷の低い日時に実施 8 時間以内の計画ダウンタイムが可能 システム設計、実装、運用における主な検討事項は、長時間の運用、予算の予測と管理の容易さ、リザーブドインスタンス (RI) によるコスト最適化、既存システムとの互換性維持 (エンドポイント変更の回避) でした。お客様は Amazon Redshift Serverless も評価しました。従量課金モデル、自動スケーリング機能、変動するワークロードに対するより良い価格性能比など、魅力的な機能を備えていました。Redshift Serverless と Provisioned クラスターのどちらもワークロードパターンを効果的にサポートできましたが、お客様は Provisioned 環境での長年の運用経験、既存の RI 戦略、確立されたキャパシティプランニングアプローチを活かし、RA3 ノードの Provisioned モデルを選択しました。 RA3 インスタンスタイプの特徴 AWS Nitro System 上に構築された RA3 インスタンスは、マネージドストレージを備え、コンピューティングとストレージを分離するアーキテクチャを採用しています。各コンポーネントを独立してスケーリングでき、課金も個別に行われます。ホットデータには高性能 SSD、コールドデータには Amazon S3 を使用し、使いやすさ、コスト効率の高いストレージ、高速なクエリパフォーマンスを実現します。詳細は Amazon Redshift RA3 instances with managed storage をご覧ください。 移行の前提条件 お客様の移行の前提条件は以下のとおりです。 16 ノードの dc2.8xlarge 構成の Redshift クラスターを使用していました。 移行には Blue-Green デプロイメントアプローチを採用し、スナップショットから RA3 インスタンスタイプにリストアすることで、必要に応じて迅速にロールバックできるようにしました。 クラスター識別子のローテーションによるエンドポイント切り替えで、クラスターの切り替えとロールバックを実装しました。 さらに、高い同時実行性でのパフォーマンス向上のため、トランザクション分離レベルを SERIALIZABLE ISOLATION から SNAPSHOT ISOLATION に移行しました。 クラスター移行方法 移行には Elastic Resize と Classic Resize の 2 つのオプションがありました。 Amazon Redshift の Classic Resize 機能が強化 され、RA3 インスタンスタイプへのリサイズにおいて書き込み不可期間が大幅に短縮されました。PoC テストの結果、リサイズ開始後、クラスターのステータスが modifying になってから利用可能になるまで 16 分でした。この結果を踏まえ、お客様は Classic Resize アプローチで進めました。 クラスターサイジング サイジングでは、移行先のインスタンスタイプとノード数を決定しました。CPU 集約型 (高 CPU 使用率のクエリ)、I/O 集約型 (データ読み書きが多いクエリ)、またはその両方といったワークロード特性を考慮しました。DC2 インスタンスタイプからの移行では、ワークロード要件に応じて追加ノードが必要になる場合があります。必要なクエリパフォーマンスに応じたコンピューティング要件に基づいてノードを増減しました。 インスタンスサイズとノード数でクラスターコストが同等の構成を比較すると、 dc2.8xlarge 16 ノードクラスターの推奨構成は ra3.16xlarge 8 ノード でした。東京リージョンでのコスト比較は以下のとおりです。 推奨構成：dc2.8xlarge 16 ノードクラスター => ra3.16xlarge 8 ノードクラスター $97.52/h (6.095/h * 16 ノード) => $122.776/h (15.347/h * 8 ノード) コスト重視：dc2.8xlarge 16 ノードクラスター => ra3.16xlarge 6 ノードクラスター $97.52/h (6.095/h * 16 ノード) => $92.082/h (15.347/h * 6 ノード) 今回の移行では、既存の予算制約内に収めるため、コスト効率の高い 6 ノードの ra3.16xlarge クラスターで進めました。ただし、このノード数では特定の時間帯にスループットの制約が生じる可能性があるため、RA3 インスタンスタイプの同時実行スケーリングを有効にしてスパイクアクセスに対応しました。 同時実行スケーリングは、アクティブなクラスターごとに 1 日最大 1 時間の無料クレジットを提供し、最大 30 時間まで蓄積できます。この無料枠を超えるとオンデマンド料金が適用されます。お客様は同時実行スケーリングの導入を選択しましたが、ピーク負荷時に一時的にノードを増やす Elastic Resize も検討されました。しかし、追加ノードのオンデマンドコストと切り替え時の短時間の切断が発生するため、採用を見送りました。 マネージドストレージのコスト RA3 インスタンスは Redshift Managed Storage (RMS) を使用し、固定の GB 月額料金で課金されます。お客様の約 2 TB のデータについて、ストレージコストを見積もりに含める必要がありました。料金の詳細は Amazon Redshift の料金 をご覧ください。 DC2 から RA3 への移行手順 DC2 クラスターのスナップショットから RA3 クラスターを作成した後、クラスター識別子を入れ替えました。次の図はこのプロセスを示しています。 現在の DC2 クラスターのスナップショットを取得します。 異なるクラスター識別子でスナップショットから RA3 クラスターをリストアします (Classic Resize)。 現在の DC2 クラスターと新しい RA3 クラスターのクラスター識別子を入れ替えます。 クラスター切り替え後に問題が発生した場合、元の DC2 クラスターのクラスター識別子を元に戻すことで迅速にロールバックできます。 注：スナップショットからのリストア 操作ミスを最小限に抑え、再現性を確保するため、CLI コマンドでリストア操作を実行することを推奨します。以下はサンプルコマンドです。 aws redshift restore-from-cluster-snapshot \ --cluster-identifier for-ra3-20250207 \ --snapshot-identifier cm-cluster-for-ra3-20250207 \ --cluster-subnet-group-name cm-cluster \ --vpc-security-group-ids sg-1234567a sg-2345678b sg-3456789c \ --cluster-parameter-group-name cm-cluster \ --node-type ra3.16xlarge \ --number-of-nodes 6 \ --port 5439 \ --no-publicly-accessible \ --enhanced-vpc-routing \ --availability-zone ap-northeast-1a \ --preferred-maintenance-window sat:17:00-sat:17:30 \ --automated-snapshot-retention-period 14 \ --iam-roles 'arn:aws:iam::123456789012:role/AmazonRedshift-CommandsAccessRole' 'arn:aws:iam::123456789012:role/AmazonRedshift-Spectrum' \ --maintenance-track-name current 本番移行の所要時間 リストアと Classic Resize の所要時間は、データ量とターゲットクラスターの仕様によって大きく異なります。お客様は事前にリハーサルを実施し、実際の所要時間を計測しました。 テスト結果 本番移行の前に、お客様はスナップショットを RA3 インスタンスタイプにリストアしてテストクラスターを作成しました。通常、ワークロードテストには Redshift Test Drive が有用ですが、このお客様には固有の制約がありました。本番クラスターで監査ログを有効にするには、設定変更、クラスター再起動、厳格な変更管理ポリシーに基づく複雑な承認プロセスが必要でした。この課題に対応するため、Amazon Redshift のシステムビュー ( SYS_QUERY_HISTORY と SYS_QUERY_TEXT ) を使用してワークロードパターンをキャプチャする独自の負荷テストツールを開発しました。これらのシステムビューは 7 日間のクエリ履歴を保持しています。このツールで 55,755 件の過去のクエリを 50 並列で DC2 と RA3 の両クラスターに対してリプレイし、クエリ実行時間、CPU 使用率、ディスク I/O などのメトリクスを比較しました。正確な比較のため、テスト中はクエリ結果のキャッシュを無効にしました。 BI クエリパフォーマンス BI クエリは前述の独自の負荷テストツールでテストしました。結果は、55,755 件のクエリを 50 並列で実行した 15 回のテストの平均実行時間です。同時実行スケーリングなしの場合、dc2.8xlarge 16 ノードクラスターの平均はクエリあたり 45.82 秒、ra3.16xlarge 6 ノードクラスターの平均は 91.30 秒でした。最適化なしの直接移行では、RA3 インスタンスは短・中程度のクエリで実行時間が長くなることが分かりました。しかし、同時実行スケーリングを有効にすると RA3 クラスターのパフォーマンスは段階的に改善しました。同時実行スケーリングを最大 2 クラスターで有効にした場合、ra3.16xlarge 6 ノードクラスターの平均はクエリあたり 72.48 秒となり、スケーリングなしの構成から 21% 改善しました。 ノードタイプ / ノード数 平均クエリ時間 ra3.16xlarge 6 ノードクラスター 72.48 秒 ETL クエリパフォーマンスの比較 長時間実行される ETL クエリ (実行時間 10 分以上) では、RA3 クラスターは DC2 クラスターよりも優れたパフォーマンスを示しました。これらの結果は、最適化を適用していないお客様のワークロードの直接移行によるものです。 大規模データロードワークロード 1 では、ra3.16xlarge クラスターは dc2.8xlarge クラスターより 28% 高速にクエリを完了しました (41 分 vs. 57 分)。 複雑な変換ワークロード 1 では、ra3.16xlarge クラスターは 23% 高速でした (1 時間 1 分 vs. 1 時間 20 分)。 これらの結果から、RA3 ノードタイプは時間のかかるデータロードや変換タスクでより高いパフォーマンスを発揮することが分かりました。RA3 クラスターの CPU 使用率が高い値を示したことは、コンピューティングリソースをより効果的に活用していることを示唆しています。 ノードタイプ / ノード数 平均クエリ時間 MAXCPU% ra3.16xlarge 6 ノードクラスター 41 分 09 秒 11.45 dc2.8xlarge 16 ノードクラスター 57 分 07 秒 10.85 ノードタイプ / ノード数 平均クエリ時間 MAXCPU% ra3.16xlarge 6 ノードクラスター 1 時間 01 分 33 秒 74.23 dc2.8xlarge 16 ノードクラスター 1 時間 20 分 36 秒 53.58 パフォーマンスチューニング テスト結果から、RA3 は短・中程度の BI クエリでは DC2 より実行時間が長くなる一方、長時間実行される ETL クエリでは高速であることが分かりました。全体的なパフォーマンスを最適化するため、遅いクエリと頻繁に参照されるテーブルを特定し、影響の大きい最適化を優先しました。 パフォーマンスチューニング戦略 お客様は RA3 のアーキテクチャ上の利点を活かすため、いくつかの最適化戦略を検討しました。主要な戦略の 1 つは、アドホックな短・中程度のクエリワークロードを低負荷時間帯に事前処理し、結合、集約、フィルタリング、射影を繰り返し実行するクエリ向けに事前処理テーブルやマテリアライズドビューを作成することでした。RA3 のコンピューティングとストレージを分離したアーキテクチャと、コスト効率の高い大容量ストレージがこのアプローチを支えました。 通常のビューからマテリアライズドビューへの変換 遅いクエリを分析したところ、ビュー内で結合が使用されており、頻繁に参照されるテーブルがこれらのビューを通じて複数回アクセスされていることが判明しました。対策として、頻繁に使用される通常のビューをマテリアライズドビューに置き換え、不要なデータ範囲と冗長なカラムを削除しました。 Amazon Redshift は REFRESH MATERIALIZED VIEW コマンドによるマテリアライズドビューの増分更新をサポートしており、効率的なデータ更新が可能です。 マテリアライズドビューとクエリリライト 通常のビューをマテリアライズドビューに変換すると、クエリプランナーが提供する「クエリリライト」機能により、既存のクエリが自動的に最適化される場合があります。詳細は マテリアライズドビューを使用した自動クエリリライト をご覧ください。 AutoMV による自動チューニング DC2 クラスターではディスク使用率が常に 80% を超えており、ディスク容量不足のため AutoMV 機能が無効になっていました。RA3 のストレージ拡張により、AutoMV による自動チューニングが可能になり、さらなるパフォーマンス改善につながりました。AutoMV の詳細は マテリアライズドビューを使用するための自動クエリ書き換え  をご覧ください。 パフォーマンスチューニングの結果 これらの最適化を適用した結果、お客様は以下を達成しました。 コスト増加を抑えながら既存のパフォーマンスを維持 スループットを維持しながら CPU 使用率を向上 同時実行スケーリングの自動スケーリングにより、ピーク負荷時の動的なスループットを強化 まとめ 本記事では、小売業の大手企業が Amazon Redshift DC2 インスタンスから RA3 インスタンスへ移行した事例を紹介しました。Blue-Green デプロイメントアプローチにより、迅速なロールバック機能を備えた安全な移行を実現しました。RA3 のコンピューティングとストレージを分離したアーキテクチャは、増加するデータ量に対応する柔軟性を提供しました。RA3 インスタンスは短い BI クエリで DC2 インスタンスと異なるパフォーマンス特性を示しましたが、長時間実行される ETL クエリでは大幅な改善を達成しました (データロードで最大 28% 高速化、複雑な変換で 23% 高速化)。マテリアライズドビューや AutoMV などの RA3 インスタンス固有の機能を活用し、リザーブドインスタンスと同時実行スケーリングによるコスト効率を維持しながら、全体的なクエリパフォーマンスを最適化しました。 RA3 インスタンスへの移行の詳細については、 Best practices for upgrading from Amazon Redshift DC2 to RA3 and Amazon Redshift Serverless と Resize Amazon Redshift from DC2 to RA3 with minimal or no downtime をご覧ください。 著者について Satoru Ishikawa (石川 覚) Satoru は、データ分析と AI コンサルティングを専門とし、Amazon SageMaker やマルチクラウドに注力しています。また、Classmethod の「Members」のバックエンド開発にも携わり、高度なデータと AI の活用を通じてデジタルトランスフォーメーションを推進しています。 Junpei Ozono (大薗 純平) Junpei は、データと AI ソリューションのテクニカルマーケット開発を推進し、グローバルチームと連携してスケーラブルな GTM 戦略を構築しています。Data Mesh、Data Lakehouse、AI などのモダンデータアーキテクチャを専門とし、お客様の AWS によるクラウドトランスフォーメーションの加速を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Junpei Ozono がレビューしました。

Fiti (スワヒリ語のスラングで「最高」) AWS Student Community Kenya! 2026年 3 月 2 日週は、ケニア全国でさまざまなミートアップ、ハンズオンワークショップ、キャリアディスカッションが開催された目まぐるしくもすばらしい一週間でした。そのフィナーレを飾ったのが Meru University of Science and Technology での AWS Student Community Day です。ここでは、私の同僚の Veliswa と Tiffany による基調講演に加えて、GitOps からクラウドネイティブエンジニアリングにおよぶ多種多様なセッションと、多数の AI エージェント構築セッションが行われました。 JAWS Days 2026 は世界最大の AWS Community Day で、3 月 7 日の参加者は 1,500 人を超えました。このイベントは、AI ドリブンな開発チームの構築に関する Jeff Barr の基調講演で始まり、100 を超える技術セッションとコミュニティ体験セッション、ライトニングトーク、そして Game Days、Builders Card Challenges、ネットワーキングパーティーなどのワークショップが行われました。 それでは、2026年 3 月 9 日週の AWS ニュースを見ていきましょう。 2026年 3 月 2 日週のリリース 2026年 3 月 2 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 ヘルスケア向けに構築されたエージェンティック AI、Amazon Connect Health の導入 – ヘルスケア専用の 5 つの AI エージェント (患者確認、予約管理、患者インサイト、アンビエントドキュメンテーション、医療コーディング) を備えた Amazon Connect Health の一般提供が開始されました。すべての機能は HIPAA に準拠しており、既存の臨床ワークフローに数日間で導入できます。 Amazon Bedrock AgentCore ポリシーの一般提供開始 – エージェントコード外で行われるエージェントとツールのやりとりに対し、一元的できめ細かなコントロールを利用できるようになりました。セキュリティチームとコンプライアンスチームは、AWS のオープンソースポリシー言語である Cedar に自動変換される自然言語を使用して、ツールアクセスルールと入力検証ルールを定義できます。 自律型プライベート AI エージェントを実行するための OpenClaw の Amazon Lightsail への導入 – 組み込みのセキュリティコントロール、サンドボックス化されたエージェントセッション、ワンクリック HTTPS、デバイスのペアリング認証機能を備えた独自のクラウドインフラストラクチャでプライベート AI アシスタントをデプロイできます。Amazon Bedrock がデフォルトのモデルプロバイダーとして機能し、Slack、Telegram、WhatsApp、Discord に接続できます。 AWS が VPC 暗号化コントロールの料金を発表 – 2026 年 3 月 1 日から、VPC 暗号化コントロールが無料プレビューから有料機能に移行します。リージョンに存在する VPC 内と VPC 間におけるすべてのトラフィックフローの転送時の暗号化を監査および強制でき、モニタリングモードでは暗号化されていないトラフィックが検知され、強制モードでは暗号化されていないトラフィックが阻止されます。 Database Savings Plans が Amazon OpenSearch Service と Amazon Neptune Analytics のサポートを開始 – 1 年間のコミットメントにより、対象のサーバーレスインスタンスとプロビジョニングされたインスタンスの使用に対する料金を最大 35% 節約できます。Savings Plans は、エンジン、インスタンスファミリー、サイズ、AWS リージョンに関わらず、自動的に適用されます。 AWS Elastic Beanstalk が AI 駆動の環境分析の提供を開始 – 環境状態が劣化した場合に、Elastic Beanstalk が最近のイベント、インスタンス状態、ログを収集し、Amazon Bedrock に送信できるようになりました。Amazon Bedrock はそれらを分析し、現行の環境状態に合わせてカスタマイズされたステップバイステップトラブルシューティングの推奨事項を提供します。 AWS がサービスワークフローでの IAM ロールの作成と設定を簡素化 – 新しいコンソール内パネルを使用することで、IAM コンソールに切り替えなくても、サービスワークフロー内で直接 IAM ロールの作成と設定を行えるようになりました。この機能は Amazon EC2、Lambda、EKS、ECS、Glue、CloudFormation などをサポートしています。 新しい Kiro power で Lambda 永続関数の開発を加速 – Kiro の AI エージェント支援開発を使用して、レジリエントで長期間実行されるマルチステップアプリケーションと AI ワークフローをより迅速に構築できるようになりました。この Kiro power は、リプレイモデル、ステップ操作と待機操作、同時実行パターン、エラー処理、およびデプロイのベストプラクティスに関するガイダンスを動的にロードします。 Amazon GameLift Servers が DDoS 保護の提供を開始 – アクセストークンを使用してクライアントトラフィックを認証し、プレイヤーごとのトラフィック制限を適用するコロケーションリレーネットワークを使用することで、DDoS 攻撃からセッションベースのマルチプレイヤーゲームを保護できるようになりました。GameLift Servers のお客様に対する追加コストはありません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS コミュニティからの記事 私が個人的に気に入っている AWS コミュニティと同僚の記事をご紹介します。 I Built a Portable AI Memory Layer with MCP, AWS Bedrock, and a Chrome Extension – MCP、Amazon Bedrock、セッションとアプリケーション全体にコンテキストを提供する Chrome 拡張機能を使用して、AI エージェント用の永続メモリレイヤーを構築する方法を学びましょう。 When the Model Is the Machine – Mike Chambers は、AI エージェントが単一のプロンプトからランタイム時に完全かつインタラクティブなウェブアプリケーションを生成する実験的なアプリを構築しました。これには、コードベースもフレームワークも永続的な状態もありません。モデルがランタイムになるときに何が起こるのかを考えさせられる考察です。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Community GameDay Europe – AWS に関する知識がありますか? 3 月 17 日に開催される AWS Community GameDay Europe でその知識を実証しましょう。このゲーム型学習イベントでは、AWS サービスを使って現実世界の技術的課題を解決するためにチームが競い合います。 AWS at NVIDIA GTC 2026 – 2026 年 3 月 16～19 日に米国サンノゼで開催される NVIDIA GTC 2026 で、AWS のセッション、ブース、デモ、付帯イベントに参加しましょう。AWS 経由でイベントパスの 20% 割引を受け、GTC での 1 対 1 ミーティングをリクエストできます。 AWS Summit – 2026 年の AWS Summit にご参加ください。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスです。今後のイベントには、 スロバキア (3 月 11 日）、 プネ (3 月 21 日)、および メキシコシティ で開催される AWSome Women Summit LATAM (3 月 28 日) などがあります。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026年 3 月 9 日週のニュースは以上です。2026年 3 月 16 日週の Weekly Roundup もお楽しみに! – seb 原文は こちら です。

本記事は 2026/03/11 に公開された “ From Pilot to Production: Scaling Industrial AI with AWS at Hannover Messe 2026 ” を翻訳し、 日本のお客様向けの補足情報 を追加したものです。 Hannover Messe 2026 がまもなく開催されます。今年注目の話題は工場フロアでの AI の活用です。世界有数の産業技術展示会である Hannover Messe の中心は、製造、エネルギー、物流の業界リーダーや実務者が一堂に会し、世界の産業が直面する重要な課題に取り組みます。今年のイベントは 4 月 20 日から 24 日までドイツのハノーバーで開催され、約 123,000 人の来場者、4,000 以上の出展者、そして数千もの製品やソリューションが集まります。AWS は、製造業の企業が AI を大規模に展開するための実用的なソリューションを提供します。Hannover Messe 2026 では今年も、ホール 15、ブース D76 の AWS ブースにご来訪ください。そこでは、AWS と AWS パートナーのソリューションを通じて、フィジカル AI、エージェンティック AI、エッジからクラウドへの連結性、インテリジェントなデータ基盤の最新情報を展示します。これらはすべて、製造業者が変革を加速し、測定可能なビジネス成果を促進するのに役立つように構築されています。 なぜ Hannover Messe 2026 に参加するのか 最新技術を学び、関係づけ、体験したいなら、Hannover Messe はまさにその機会です。以下の内容にご期待ください： 展示会： 4,000 以上の出展者が広大なホールに集まり、Hannover Messe はスマート製造、デジタルエコシステム、産業向けエネルギーにまたがるソリューションを紹介しています。AWS はデジタルエコシステムホールの中心、ホール 15、ブース D76 にあります。到着前に イベントレイアウト を確認しルートを計画してください。 カンファレンス： Hannover Messe のカンファレンスプログラムでは、C レベルの幹部、業界のビジョナリー、技術実務家によるプレゼンテーションが満載の専門ステージが特徴です。今年のアジェンダでは、フィジカル AI、エージェンティック AI、自律型製造、エッジからクラウドへの機器への接続、デジタル主権を取り上げます。AWS のスピーカーが週を通してステージに立ち、産業用 AI を大規模展開するための知見を共有します。スケジュールは以下のとおりです： 基調講演: AWS の自動車・製造部門のゼネラルマネージャーである Ozgur Tohumcu が、Volkswagen Group の Florian Lechner と共に、「 試験運用から本番へ：AWS とフォルクスワーゲングループで産業用 AI を大規模展開 (From Pilot to Production: Realizing Industrial AI at Scale with AWS and Volkswagen Group)」と題した基調講演を行います。このセッションは 4 月 21 日火曜日 午後 1:15–1:45 にセンターステージで行われます。Volkswagen Group が AWS を利用したデジタル生産プラットフォームを世界中の 40 以上の施設にどのようにスケールしているかを学びます。 成果のために: AIによる再産業化 (Build to Win: AI-driven Re-industrialization) – 4 月 20 日（月）午前10:20, Hall 26, Booth E43 – Spotlight Stage (Solution Lab Automation &amp; Digitalization) デジタル主権の複雑さを乗り越える (Navigate digital sovereignty complexity) – 4 月 20 日（月）午後3:10, Hall 26, booth E43 – Expert Stage 1 (Solution Lab Automation &amp; Digitalization) 製造のエージェントユースケースを初めて動かす:ライブマルチエージェントシステムデモ (Run Your First Manufacturing Agentic Use Case: Live Multi-Agent System Demo) – 4 月 21 日（火）午前11:15, 午前10:20 in Hall 26, Booth E43 – Spotlight Stage (Solution Lab Automation &amp; Digitalization) AI による製造業のバリューチェーンにおける脱炭素化と排出量モデリング (From Data to Decarbonization: AI-Powered Emissions Modeling Across Manufacturing Value Chains) – Hall 12, Stand F56 – Expert Stage (Solution Lab Energy &amp; Industry Infrastructure) マスタークラス： さらに深く学びたい人のために、Hannover Messe では、ライブ Q&amp;A を含む最大 60 分のインタラクティブな実務者によるセッションを提供します。AWS は今年、主要な産業用 AI トピックをカバーする 3 つのマスタークラスセッションを開催します。お早めに申し込んで、席を確保してください。 エージェントを活用したデータ探索によるデータ分析の加速(Accelerate data insights with agentic data exploration) – 4 月 20 日月曜日、午後 3:30、Solution Lab Automation &amp; Digitalization (Hall 26 Booth E43), Masterclass Room 1 エージェントベースの AI による在庫再調整の自動化 (Automate inventory rebalancing with Agentic AI)– 4 月 21 日火曜日、午後 4:45、Hall 12, Solution Lab (F56) Masterclass Room ショップフロア制御からフィジカル AI への移行：産業接続性とインテリジェントオートメーションの架け橋 (From Shop Floor Control to Physical AI: Bridging Industrial Connectivity and Intelligent Automation) – 4 月 23 日木曜日、午前 11:00、Solution Lab Automation &amp; Digitalization (Hall 26 Booth E43), Masterclass Room 1 ネットワーキング： Hannover Messe は、業界リーダーとつながる世界最大のグローバル産業イベントの 1 つです。展示フロア以外でも、AWS は週を通して様々なイベントを開催します。エグゼクティブ、顧客、パートナーが集まり、有意義なディスカッションを行います。AWS の専門家とのより深い個別ディスカッションをご希望の場合は、 ミーティングをリクエスト してください。ミーティングはブース内のミーティングルームで開催されます。 また、AWS パートナーのプラチナスポンサーが主催するブース内のイブニングレセプションも開催されます。ドリンクや軽食を楽しみながら、AWS のトップパートナーやその幹部とネットワーキングし、交流する機会をお楽しみいただけます。 4 月 20 日（月）午後 5:30 – 午後 7:00、 Zoomlion 提供のイブニングレセプション 4 月 21 日（火）午後 5:30 – 午後 7:00、 Siemens 提供のイブニングレセプション 4 月 22 日（水）午後 5:30 – 午後 7:00、 QAD Redzone がスポンサーのイブニングレセプション ホール 15 での AWS 展示内容 AWS は、ホール 15 のブース D76 に 1,400m² の展示スペースを設置します。ここでは、エンジニアリング・開発、スマート製造・サプライチェーン、スマート製品・サービスの 3 つのソリューション領域を紹介します。 今年の AWS ブースのハイライトは、 AI 駆動の製品ジャーニー です。これは製造工程を最初から最後まで実体験できる展示です。 参加者は自分でカスタムの金属製ドリンクコースターをデザインし、プロセスの最初から最後まで自律的に製造されるのを 確認 します。この体験は 3 つの領域全てにまたがります。 エンジニアリング &amp; 開発トンネル： ジェネレーティブデザイン、CAD AI エージェント、デジタルスレッドによるナレッジアシスタント、AI 駆動シミュレーションのライブデモンストレーションをご覧ください。 自律型製造セル： 自律移動ロボット（AMR）、協働ロボット（コボット）、ヒューマノイドロボットが、AWS を使用してオーケストレーションされたレーザー彫刻生産ラインを実行するためにリアルタイムで協力する様子をご覧ください。 フィジカル AI ステーション： AWS が提供するスケーラブルで統合されたエッジ to クラウドへのソリューションを通じて、製造業者は、合成データの生成、分散モデルトレーニング、写実的なシミュレーション、フリートの導入、物理ロボットとスマート製造システムのための高度なエージェントタスクを速やかに実現できます。これら&nbsp;5 つの柱となるプロセスを通じて、フィジカル AI の導入が可能になります。 今年の新展示 Amazon から学ぶ では、AWS が Amazon のフルフィルメントと物流を内側から支えているかを紹介します。ブース内のその他のキオスクでは、 Amazon Bedrock AgentCore 、 Amazon Nova Forge 、 Amazon Quick 、 AWS Transform に焦点を当てています。これらのキオスクでは、サプライチェーン最適化、データ探索、OT モダナイゼーション、組み込みソフトウェア開発、スマートマシンのためのエージェンティック AI ソリューションを 取り上げて います。 AWS のブースには 24 のスポンサーパートナー が参加し、プラチナスポンサーには QAD Redzone、Siemens、Zoomlion が含まれます。当社の 製造および産業パートナーネットワーク は、クラウドの旅のあらゆる段階で比類のない専門知識と選択肢をお客様に提供します。パートナーキオスクを探索して、幅広い製造のユースケース向けに AWS 上に構築された協調的なソリューションを発見してください。また、AWS Business Outcomes Xcelerator（BOX）プログラムについても学べます。このプログラムでは AWS と AWS パートナーが協力して、運用の近代化、生産プロセスの最適化、ビジネスの成長を促進します。 ブース体験をさらに豊かなものにする 50 以上のブース内シアターセッション が開催されます。ここでは、AWS の専門家、パートナー、顧客が実世界のストーリーを共有します。 セッションは、工場現場のフィジカル AI から、サプライチェーンのエージェントソリューションやインテリジェントなデータ基盤まで、幅広いトピックに及びます。AWS シアターセッションのスケジュールをチェックして、参加をご計画ください。 AWS が産業 AI をどのように支えているか AWS は、製造業の企業が AI でパイロットから本番環境へ移行するためのサポートを提供します。Hannover Messe 2026 では、AWS が産業変革における最重要課題にどのように取り組んでいるかを探ってみましょう： フィジカル AI と自律型製造： 工場フロアは急速に変化しています。フィジカル AI により、ロボット、コボット、自律システムが物理世界を認識、推論、行動します。AWS は、これらのソリューションを大規模に展開するための柔軟なエッジからクラウドまでのインフラストラクチャを提供します。シミュレーションやモデルトレーニングからエッジでのリアルタイム推論まで、AWS は製造業にフィジカル AI をもたらすのに役立っています。自律型製造セルでその様子をご覧ください。 サプライチェーンのためのエージェンティック AI： サプライチェーンは複雑で動的であり、迅速な意思決定を困難にします。AWS は製造業の企業のエージェンティック AI ソリューションの導入を支援し、お客様が計画を自律的に最適化し、混乱を予測し、意思決定を加速することを支援します。これらのソリューションは、産業グレードのインフラストラクチャによって実現されいてます。サプライチェーンキオスクを確認したり、Amazon Bedrock AgentCore でできることについてさらに学んでください。 インテリジェントデータ基盤とデジタルスレッド： サイロ化されたデータは、産業 AI の採用の大きな障壁です。AWS は、製造業者が統一されたデータ基盤を構築します。この基盤には、検索可能なナレッジグラフや製品デジタルスレッドソリューションが含まれ、製品ライフサイクル全体にわたって情報を接続します。この基盤により、生成 AI、エージェンティック AI、フィジカル AI をスケールすることが可能になります。ブースのエンジニアリングおよび開発エリアでさらに詳しく探ってみてください。 エッジからクラウドへの接続： 工場フロアの資産をクラウドに接続する際、既存のインフラストラクチャを丸ごと取り除く必要はありません。AWS IoT SiteWise Edge は、250 以上のデバイスのネイティブ産業プロトコルをサポートし、製造業務全体でデータをシームレスに収集、コンテキスト化、分析します。ブースのスマート製造エリアに立ち寄り、エッジからクラウドへの接続ソリューションをご覧ください。 運用レジリエンスとデジタル主権： 国境を越えて事業を展開する製造業者は、どこで事業を行っても、データの安全性、コンプライアンス準拠、レジリエンスに自信を持つ必要があります。AWS は、運用レジリエンスとデジタル主権のための目的別ソリューションを提供しており、欧州主権クラウドも含まれています。これらのソリューションにより、製造業者はイノベーションを遅らせることなく規制要件を満たすことができます。ブースの欧州主権クラウドの展示にお越しいただき、さらに詳しく学んでください。 ブースにお越しください Hannover Messe 2026 では、ホール 15、ブース D76 の AWS ブースへお越しください。クラウド技術における最新の産業イノベーションをご覧ください。AI による製品の旅を体験し、AWS の専門家と会い、ガイド付きブースツアーに参加するか、シアターセッションに参加して、AWS が製造業者の産業 AI 変革をどのように支援し加速させているかについてさらに学んでください。 イベントの前に AWS の担当者に連絡してミーティングを予約してください。最新の情報については、 Hannover Messe 2026 イベントページ を訪れ、LinkedIn で AWS for Manufacturing をフォローしてください。 日本のお客様に向けた情報 日本からのお客様向けには、ハノーバー現地において、AWS の日本メンバーによる日本語でのブースのご案内や、個別ミーティング等を実施しています。上記リンクまたは担当の営業経由でお申し込みください。また、現地でも日本人スタッフにお気軽にお声がけください。 <!-- '"` --> 翻訳は、ソリューションアーキテクトの山本が行いました。 Emily O’Kelly Emily は AWS のインダストリープロダクトマーケティングマネージャーです。彼女は産業および製造部門でのイノベーションとデジタル変革を推進することを専門としています。Emily は、明確で差別化されたメッセージング、説得力のあるユースケースの作成、サービスと機能を位置づけるために協力して働くことで、業界の変革を推進するインパクトのある瞬間を作り出すことに熱心です。Emily はロードアイランド大学で産業システム工学の学位を取得し、サザンニューハンプシャー大学で MBA を取得しています。

月刊 AWS 製造 2026年3月号 みなさん、こんにちは。AWS のソリューションアーキテクトの山田です。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 先月号は こちら です。未読の方はあわせてご覧ください。 今月は、ピックアップコンテンツとして製造業における Agentic AI の活用を特集します。 ピックアップトピック – Agentic AI × 製造業 Agentic AI（エージェンティック AI）は、人間の指示に基づいて自律的にタスクを計画・実行し、ツールを活用しながら目標を達成する AI システムです。2月には Amazon と OpenAI の 戦略的パートナーシップ が発表され、OpenAI モデルを活用した Stateful Runtime Environment を共同開発し、Amazon Bedrock を通じてユーザーに提供することが明らかになりました。AWS 上で利用可能な AI モデルのエコシステムがさらに拡充される中、製造業においても Agentic AI の具体的な適用事例が急速に増えています。今月はその中から 4 つのコンテンツをご紹介します。 品質管理：BMW Group — AWS 上の Agentic Search でペタバイト規模のデータからインサイトを抽出 BMW Group unlocks insights from petabytes of data with agentic search on AWS は、BMW Group が AWS Professional Services と協力して構築した Agentic Search ソリューションの事例です。20 PB のデータを保有する Cloud Data Hub に対し、Amazon S3 Vectors によるセマンティック検索、Amazon Athena による SQL フィルタリング、LLM による網羅的分類を組み合わせた 3 つの検索アプローチを AI エージェントが自動的に使い分けます。エージェントのオーケストレーションには Amazon Bedrock AgentCore と AWS のオープンソースフレームワーク Strands Agents を使用しており、技術スキルに関係なく自然言語でデータインサイトを抽出できる仕組みです。製品品質データの分析を例に、製造業におけるデータ駆動型意思決定の実践例として注目の内容です。 調達：Amazon Bedrock AgentCore を使用した AI エージェントによる調達ワークフローの自動化 Automate Procurement Workflows with AI Agents using Amazon Bedrock AgentCore は、製造業の調達プロセスに Agentic AI を適用した実践的なブログ記事です。Amazon Bedrock AgentCore を活用して、コンプライアンス検証、サプライヤー推薦、財務分析、RFQ（見積依頼）管理といった複雑なマルチステップの調達タスクを自律的に処理する AI エージェントの構築方法を解説しています。 研究開発：メック株式会社の事例 — Amazon Bedrock AgentCore で研究業務を効率化 メック株式会社の事例 では、AI エージェントを活用した研究業務の効率化が紹介されています。Amazon Bedrock AgentCore Runtime と Amazon S3 Vectors を利用し、ベテラン社員の検索ノウハウを AI エージェントとして実装することで、経験年数に関わらず高品質な情報アクセスを実現しています。AWS 主催のハッカソンをきっかけに約 3 週間で PoC を構築した点も注目です。 物流・SCM：Agentic AI でサプライチェーン ロジスティクスを変革 Agentic AI でサプライチェーン ロジスティクスを変革 は、シンガポールの A*STAR（科学技術研究庁）と AWS ProServe が共同開発した物流エージェントの事例を中心に、AI エージェントが ERP・TMS・WMS などの複数システムからリアルタイムデータを集約し、手動検索の作業負荷を最大 50% 削減する効果が紹介されています。複数の専門エージェントが協調するアーキテクチャは、製造業のサプライチェーン管理に直接適用できる内容です。 製造関連の主要なアップデート 2/12 Amazon EC2 M8azn インスタンスの一般提供開始 第5世代 AMD EPYC プロセッサを搭載し、最大 5 GHz のクロック周波数を実現する M8azn インスタンスが一般提供開始となりました。M5zn と比較して最大 2 倍のコンピューティング性能、4.3 倍のメモリ帯域幅、10 倍の L3 キャッシュを提供します。東京リージョンを含む 4 リージョンで利用可能で、製造業における CAE シミュレーションや設計最適化のワークロードに大きな恩恵をもたらすインスタンスタイプです。 2/17 Amazon EC2 Hpc8a インスタンスの一般提供開始 同じく第5世代 AMD EPYC プロセッサを搭載する Hpc8a インスタンスが一般提供開始となりました。192 コア、768 GiB メモリ、300 Gbps の Elastic Fabric Adapter（EFA）ネットワーキングを備え、前世代 Hpc7a と比較して最大 40% 以上の性能向上を実現します。 こちらのブログ でインスタンスの詳細が説明されています。また、 CAE アプリケーションを含むパフォーマンスの技術詳細ブログ も公開されており、ANSYS Fluent で約 50〜59%、Siemens StarCCM+ で約 36〜44%、ANSYS Mechanical で約 45%、LS-DYNA で約 51% の性能向上（いずれも Hpc7a 比）が報告されています。計算集約型のシミュレーション、エンジニアリングワークロード、密結合 HPC アプリケーションに最適です。 2/27 Amazon と OpenAI が戦略的パートナーシップを発表 Amazon が OpenAI に 500 億ドルを投資し、OpenAI モデルを活用した Stateful Runtime Environment を共同開発し、Amazon Bedrock を通じてユーザーに提供する戦略的パートナーシップが発表されました。ピックアップトピックでもご紹介した通り、Agentic AI の基盤がさらに強化されます。 直近で開催予定のイベント・セミナー AWS re:Invent 2025 re:Cap 製造業界編（オンデマンド配信中） re:Invent 2025 で発表された製造業関連のアップデートを日本語で解説する AWS Black Belt Online Seminar の re:Cap が公開されています。2部構成で、Part 1 では全体動向・スマート製造・サプライチェーン、Part 2 では製品設計・スマート製品を取り上げています。 Part 1（全体、スマート製造、サプライチェーン）： 動画 ｜ 資料 Part 2（製品設計、スマート製品）： 動画 ｜ 資料 NVIDIA GTC 2026（3/16〜19、サンノゼ） NVIDIA GTC 2026 が3月16日から19日にかけてサンノゼで開催されます。AWS は Booth #921 にて、フィジカル AI アプリケーションや Agentic AI など 6 つのドメインにわたる展示を行います。 Hannover Messe 2026（4/20〜24、ドイツ・ハノーバー） 世界最大級の産業技術展示会 Hannover Messe 2026 が4月20日から24日にドイツ・ハノーバーで開催されます。約 4,000 社の出展者が自動化、デジタル化、エネルギーシステムにわたる産業変革を展示する予定です。AWS もスマート生産やフィジカル AI に関する 展示 を行います。開催に先立ち、ブログでの事前情報公開も予定しています。また、日本人スタッフも現地に参加し、展示内容のご紹介を行いますので、ご来場予定の方はぜひお立ち寄りください。 AWS re:Invent 2026（11/30〜12/4、ラスベガス） AWS re:Invent 2026 が11月30日から12月4日にラスベガスで開催されることが発表されています。 事例のご紹介 製造業に関連する事例や、ブログによる技術詳細説明です。ピックアップトピックでご紹介した BMW Group の Agentic Search 事例 や メック株式会社の AI エージェント事例 もあわせてご覧ください。 日産が AWS と協業し SDV 開発を加速 日産自動車が AWS 上に構築した Nissan Scalable Open Software Platform による Software-Defined Vehicle（SDV）開発の加速について紹介されています。車両ソフトウェアのテスト実行時間を 75% 短縮し、世界中の 5,000 人以上の開発者を統一された開発エコシステムで接続しています。自動車産業における次世代ソフトウェアプラットフォームの構築事例として、製造業全般にも示唆に富む内容です。 Toyota Motor Europe が Amazon Bedrock でメインフレームモダナイゼーションを加速 Toyota Motor Europe が Deloitte および AWS Generative AI Innovation Center と連携し、Amazon Bedrock を活用して保証処理用レガシーメインフレームアプリケーションのソースコードからドキュメントを自動生成する取り組みが紹介されています（英語記事）。製造業では長年稼働してきたレガシーシステムの近代化が共通の課題であり、生成 AI を活用したアプローチとして参考になります。 製造関連ブログのご紹介 今月もたくさんのブログが公開されました。 1/28 AWS Well-Architected Modern Industrial Data Lens で製造ワークロードを加速 製造業のデジタルトランスフォーメーションを加速するための新しい AWS Well-Architected Modern Industrial Data Lens が公開されました（英語記事）。モダンな産業データアーキテクチャ（MIDA）基盤の構築、産業データカタログの実装、データメッシュアーキテクチャ、ナレッジグラフによるデジタルスレッド、コンピュータービジョンによる品質検査の 5 つのシナリオをカバーしています。 ホワイトペーパー もあわせてご参照ください。 2/6 VAMS における NVIDIA Isaac Lab を使用した GPU アクセラレーション型ロボットシミュレーショントレーニング AWS が提供するオープンソースの Visual Asset Management System（VAMS）は、3D モデルやシミュレーション環境などのビジュアルアセットをクラウド上で一元管理するためのソリューションです。今回、NVIDIA Isaac Lab との統合により GPU アクセラレーテッドな強化学習に対応しました。AWS Batch でスケーラブルな GPU コンピューティングを活用し、ロボットアセットのシミュレーショントレーニングからポリシー取得までをシームレスに実行できます。先月号で特集したフィジカル AI の実践的な開発基盤として注目のコンテンツです。 2/18 AWS で NVIDIA Cosmos world foundation models を実行 自律走行車、ロボティクス、スマートファクトリー向けのフィジカル AI 開発に必要な合成データを大規模に生成するための NVIDIA Cosmos ワールドファウンデーションモデル（WFM）を AWS 上でデプロイする方法を解説した日本語ブログです。Amazon EKS を使用したリアルタイム推論と AWS Batch を使用したバッチ推論の 2 つの本番環境向けアーキテクチャが紹介されています。製造業におけるフィジカル AI のデータパイプライン構築に参考になる内容です。 2/19 「導入しても使われない」を解決する ― 三菱電機 電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化 三菱電機 電力システム製作所 電力ICTセンターが、AI コーディングアシスタント Kiro と GitLab を組み合わせて開発ワークフローの標準化に取り組んだ事例です。Kiro の Steering（常時適用のグラウンドルール）、Powers（動的に呼び出されるワークフロー定義）、MCP（外部ツール連携）の 3 層構造を活用し、「ドキュメントを読まなくても、AI に聞けばワークフローに沿った開発ができる」仕組みを実現しています。製造業のソフトウェア開発効率化に関心のある方にぜひご覧いただきたい内容です。 2/25 Agentic AI でサプライチェーン ロジスティクスを変革 ピックアップトピックで詳しくご紹介しています。Agentic AI によるサプライチェーン物流の変革について、マルチエージェントアーキテクチャの設計パターンを含めて解説したブログです。 3/3 三菱電機のエンジニア 33 名が 3 日間で体感した AI 駆動開発の可能性 — AI-DLC Unicorn Gym 座談会 三菱電機 電力システム製作所 電力ICTセンターで開催された「AI-DLC Unicorn Gym」の座談会記事です。33 名のエンジニアが 3 日間にわたり、AI 駆動開発ライフサイクル（AI-DLC）を体験。5 チームがそれぞれ実際の業務課題（既存業務システム改良、IoT プラットフォーム改善、ダッシュボード開発など）に取り組み、AI を開発の中心的な協力者として活用する手法を実践しました。製造業における AI 駆動開発の組織的な導入事例として参考になります。 3/4 コネクテッドモビリティワークロードの DR 戦略 パート 1: バックアップとリストア コネクテッドモビリティ（CM）のワークロードにおける災害復旧（DR）戦略について解説するシリーズの第 1 弾です。車両接続、データ取り込み、可視化コンポーネントに対するバックアップとリストアの DR 戦略を、AWS Connected Mobility Reference Architecture に基づいて詳述しています。自動車製造業のお客様にとって、コネクテッドカーサービスのレジリエンス確保に役立つ内容です。 最後まで読んでいただきありがとうございました。いかがだったでしょうか？今月は Agentic AI の製造業への適用を中心に、幅広いアップデートをお届けしました。このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。月刊 AWS 製造ブログを今後ともよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 山田 航司 (Koji Yamada) AWS のソリューションアーキテクトとして、製造業のお客様を中心にクラウド活用の支援を行っています。製造業における業務課題解決や新規ビジネスにおけるクラウド活用の可能性をお客様と一緒に探求しています。

　 本稿は、三菱電機株式会社 名古屋製作所が新たに開発した AI を活用した商談支援サービス「 Memory Tech 」について、これを主導された三菱電機株式会社 名古屋製作所 江口 貴紀様、的場 祐弥様より寄稿いただきました。 はじめに 背景・課題 　 三菱電機株式会社 名古屋製作所 (以下、当製作所) は、FA (Factory Automation) 機器の開発・製造を手がける拠点です。シーケンサをはじめとする制御機器は製造業の現場で広く使われており、当製作所はこれまで製品の品質向上や機能強化を通じてお客様の課題解決に取り組んできました。 　 しかし、製品そのものの改善だけではお客様の課題を全て解決できるわけではありません。当製作所では、従来の製品起点のアプローチから一歩踏み出し、お客様の業務プロセス全体に目を向ける取り組みを開始しました。製造業のお客様に対して、商談から納品までの全工程を対象に「どこに課題があるのか」を徹底的にヒアリングしました。設計者、営業、調達部門といった職種を問わず、経営層から担当者まで幅広くアンケートやインタビューを実施しています。当製作所としてこのような顧客起点のヒアリングを体系的に実施するのは初めての試みでした。 　 その結果、コミュニケーションの齟齬による手戻りが深刻な課題であることが明らかになりました。手戻りによるコスト的なロスは数百万円から、最大で数億円に達するケースもあり、回答者の過半数が手戻りを課題として挙げています。さらに齟齬の原因を掘り下げたところ複数の要因が特定され、その中でも「口頭による認識齟齬」が最も優先的に解決すべき課題として浮かび上がりました。 　 FA の商談現場では、億単位の高額装置であれば仕様書を作成するものの、比較的安価な装置の場合は口頭でのやり取りで済ませてしまうケースが多くあります。この習慣を変えることは現実的ではないと判断し、「現場の習慣を一切変えずに課題を解決する」という方針を立てました。喋るという行為は必ず発生するため、喋った内容をいかに正確に記録するかという発想から、商談支援サービスの開発に至っています。 　 なお、競合サービスの存在も検討しましたが、多くの方が課題と認識しているにもかかわらず既存のツールが使われていないという事実から、市場にはまだ十分に浸透していないと判断しました。展示会に出展した際にも「こんなことができるのか」という驚きの反応が多く、この領域にはまだ大きな可能性があると確信しています。 開発体制 　 Memory Tech の開発は、当製作所にとって複数の「初めて」が重なるチャレンジでした。アジャイル開発、Web プログラミング、クラウドネイティブなサービス開発。いずれも従来の製品開発とは異なる領域です。しかし、お客様の課題を迅速に解決するためには、従来のウォーターフォール型ではなく、仮説検証を素早く繰り返せるアジャイル開発が不可欠でした。当製作所はこの機会を、顧客課題の解決だけでなく、組織としての開発力を根本から強化する契機と位置づけています。 　 開発体制はスクラムを採用しました。プロダクトオーナー (PO) を江口が務め、スクラムマスターは社内メンバーが担当しています。テックリードには KDDI アジャイル開発センター株式会社 (以下、KAG) のエンジニアに担当いただき、技術面でのリードとスクラム運営のサポートをお願いしました。特筆すべきは、KAG との協業を単なる開発委託ではなく、スキルトランスファーの場として設計した点です。KAG のエンジニアとペアプログラミングを行いながら社内エンジニアの育成を並行して進め、将来的に自社メンバーだけで開発を回せる体制を見据えています。実際に、スクラムマスターがコードも書く「半々」のスタイルで実践力を高めており、少人数でも自律的に開発を進められるチームへと成長しています。 　 また、AWS からは初めてのクラウド活用ということもあり、技術選定の段階から手厚いサポートをいただきました。サーバーレスアーキテクチャの設計方針やコスト最適化に関する助言をいただき、少人数のチームでも安心してクラウドネイティブな開発に踏み出すことができました。 ソリューション概要 システム要件 　 PO からの要件は明確でした。特別な機材の購入は不要とし、営業担当者が普段使っている Web ブラウザやスマートフォンだけで録音から議事録生成までを完結できること。そして、録音終了後 2 分以内に議事録を確認できること。この「その場で確認できる」というスピード感は、商談直後にお客様と内容を確認し合うために不可欠な要件でした。 採用方針 　 社内エンジニアは Web 開発やクラウド、インフラ運用の経験を持っていなかったため、インフラの管理・メンテナンスに工数を割くことなく、アプリケーション開発に集中できる環境が必要でした。また、成功するかどうかまだ未知数のサービスだからこそ、スモールスタートで始めて必要に応じてスケールできるクラウドのメリットを最大限に活かす方針としました。これらを踏まえ、AWS のマネージドサービスを最大限に活用したサーバーレス構成を採用しています。コスト面でも、サーバーレス構成による従量課金モデルにより、サービス開始当初の月額コストは数万円程度に抑えられました。また、初めてのクラウド活用ということもあり、AWS から手厚い技術サポートをいただけた点も大きな後押しとなりました。 要件に対応したソリューションの特徴 　 中核となるのは AWS Amplify Gen 2 です。AWS Amplify はフロントエンドからバックエンドまでをマネージドに提供するフルスタックの開発プラットフォームであり、AWS Amplify Gen 2 では AWS Cloud Development Kit (AWS CDK) ベースでインフラを定義できます。これにより、少ないコード量でバックエンド全体を構築でき、最初の議事録生成機能は約 1 ヶ月で PoC を開始できる状態に仕上がりました。KAG に AWS Amplify の豊富な実績があったことも、この技術選定を後押ししています。認証には Amazon Cognito を採用し、セキュリティの基盤を AWS に委ねることで、少人数のチームでも安全なサービスを提供できています。 　 バックエンドの処理フローは、 AWS Step Functions で構築したワークフローが中心です。録音データがアップロードされるとイベント駆動でバックエンド処理が開始され、文字起こしの結果が Amazon Bedrock に渡されて生成 AI が議事録を自動生成します。AWS Step Functions と AWS Lambda 、そして AWS Amplify のストレージやデータ機能を組み合わせ、全て Infrastructure as Code (IaC) で管理しています。この構成により、「ブラウザだけで完結」「2 分以内に議事録を確認」という PO の要件を実現しています。 　 Amazon Bedrock の採用は、AWS のエコシステム内で全てを完結できる点が大きなメリットでした。インフラ管理なしで生成 AI の機能を呼び出せるだけでなく、ストリーミングレスポンスにも対応しているため、ユーザーへの応答速度も確保できています。さらに、Amazon Bedrock が提供する複数の基盤モデルを柔軟に切り替えられる点も重要です。実際に Anthropic Claude のバージョンアップに合わせてモデルを切り替えたり、入力トークンが大きくなるフィラー削除処理には Amazon Nova を採用してコストを最適化するなど、用途に応じたモデルの使い分けを行っています。 図 1 : Memory Tech アーキテクチャ図 アプリケーション紹介 　 Memory Tech は、Web ブラウザまたはスマートフォンから利用できる、AI を活用した商談支援サービスです。ユーザーは商談や打ち合わせの音声をブラウザ上で録音するだけで、録音終了後 2 分以内に議事録が自動生成されます。特別な機材やアプリケーションのインストールは不要で、営業担当者が普段使っているデバイスだけで完結します。 　 生成される議事録は、単なる文字起こしではありません。Amazon Bedrock の生成 AI が会話の要点を抽出し、構造化された議事録として出力します。商談直後にその場でお客様と内容を確認できるため、「後から送っても見てもらえない」という従来の課題を解消しています。 図 2 : Memory Tech アプリケーション画面 ビジネス成果 　 Memory Tech は PoC の段階から非常に高い評価を得ています。社内外合わせて多くの方が PoC に参加し、アンケートのフィードバック結果も好評でした。無償 PoC に参加いただいた企業の多くがそのまま有償に移行しており、積極的なマーケティングは行わず、口コミベースでの展開にもかかわらず着実に契約数を伸ばしています。 　 社内利用はさらに急速に拡大しています。日々新たなユーザーが増加し、利用部門も FA 以外の事業部門にも広がっています。B2B の SaaS モデルとして解約率は極めて低く、安定的な収益基盤となることが期待されています。 　 技術面では、1,000 名を超えるユーザーが利用する状況においても、録音や議事録生成といったコア機能はスケーリングの問題なく安定稼働しています。少数精鋭の体制で、インフラの運用管理を意識することなくサービスを提供できている点は、AWS のマネージドサービスを全面的に採用した設計方針の成果といえます。1,000 人がアクセスしても問題なく動いていることに、開発した我々自身が一番驚いています。 　 また、Memory Tech はこれまで FA の主要顧客であった製造業の設計・生産技術部門だけでなく、営業や調達といった幅広い職種、さらには製造業以外の業界にも展開できる商材です。既存の取引先への新たな接点としても機能しており、当製作所の事業領域を広げるドアオープナーとしての役割も果たしています。 まとめと今後の展望 　 Memory Tech は、製造業の現場で長年見過ごされてきた「口頭コミュニケーションによる認識齟齬」という課題に対し、現場の習慣を変えることなく AI の力で解決するサービスです。AWS Amplify を中核としたサーバーレスアーキテクチャにより、少人数のチームでも迅速な開発と安定した運用を実現しました。 　 当製作所にとって、Memory Tech の開発はアジャイル開発や Web プログラミング、クラウドネイティブなサービス開発への初めての挑戦でもありました。KAG との協業によるスキルトランスファーを通じて社内の開発力を着実に高めており、この経験は今後の新規サービス開発の基盤となっています。 　 今後の展望として、まず海外リージョンでの SaaS 提供を視野に入れています。さらに、Memory Tech を単なる議事録ツールから「ビジネス支援プラットフォーム」へと進化させる構想があります。蓄積された会話データを活用し、商談におけるアドバイスの提供や、過去のナレッジを組織横断で活用できる仕組みなど、会話データを起点とした新たな価値創出を目指しています。 　 先行者として、ユーザーの声を取り入れながら AWS の開発スピードを活かし、常に一歩先を走り続けたいと考えています。 執筆者 江口 貴紀 三菱電機株式会社 名古屋製作所 ソフトウエアシステム部 エンジニアリングソフトウエア戦略グループ。Memory Tech の開発プロジェクトではプロダクトオーナー (PO) を務める。趣味の一つは旅行で、訪れた土地ならではのお酒や食事を楽しむことが大好き。 的場 祐弥 三菱電機株式会社 名古屋製作所 ソフトウエアシステム部 エンジニアリングソフトウエア戦略グループ。初めて触った AWS サービスである AWS Amplify Gen 2 に魅了される。FA (ファクトリーオートメーション) 業界の課題解決に取り組む新規事業企画に従事。Memory Tech を中核としたフルスタックエンジニアとして、企画立案からプロトタイプ、実装、運用まで一貫して担当。

本投稿は、 2025 年 10 月 21 日に公開された記事 「 Restore self-managed Db2 Linux databases in Amazon RDS for Db2 」を翻訳したものです。 より多くの組織がセルフマネージドの Db2 on Linux ワークロードを Amazon Relational Database Service (Amazon RDS) for Db2 へ移行するにつれ、移行チームは「準備こそがプロジェクト遅延を防ぐ鍵」であることを学んでいます。よくある障壁として、移行プロセス中に表面化する古いデータベースバージョン、無効なオブジェクト、不適切なストレージ設定などが挙げられます。本記事では、これらの問題をスケジュールに影響を与える前に検出する Db2 移行前提条件検証ツール (Db2 Migration Prerequisites Validation Tool) を紹介します。このツールは徹底的な移行前検証を実施し、セルフマネージド Db2 on Linux から Amazon RDS for Db2 への移行に必要な準備をガイドします。 ソリューション概要 Db2 移行前提条件検証ツールは、移行準備状況を確認するため、さまざまな検証カテゴリにわたって包括的な移行前評価を実施します。不整合が検出された場合、ツールは修正のための具体的かつ実行可能な推奨事項を提示します。これらの詳細な情報により、データベース管理者や移行チームが潜在的な問題に体系的に対処できます。特定された問題は、Amazon RDS for Db2 へのリストアに使用される最終的なオンプレミス Db2 バックアップを作成する前に解決する必要があります。 このプロアクティブなアプローチにより、障害を減らし、Amazon RDS for Db2 へのスムーズな移行を実現します。セルフマネージド Db2 データベースを Linux から Amazon RDS for Db2 へ移行するステップバイステップのガイダンスについては、 Amazon RDS for Db2 の Linux から Linux への移行 を参照してください。 以下の図は、オンプレミスのセルフマネージド Db2 データベース（Linux）から Amazon RDS for Db2 への正常なリストアを実現するための一般的なプロセスフローを示しています。 ツールの主な機能は以下のとおりです： クロスプラットフォームサポート： Linux on x86、Linux on POWER に対応 古い bash バージョン (訳注: bash 3.1 以降) との互換性あり 標準 Unix ツール以外の外部依存関係なし Linux 以外のプラットフォームやその他の移行オプションには Db2 Migration Tooling （Db2MT）の使用を検討 移行の詳細については Migrate from self-managed Db2 to Amazon RDS for Db2 using AWS DMS および Amazon RDS for Db2 へのデータマイグレーション戦略 を参照 複数の操作モード： インタラクティブモード – ユーザープロンプトによるガイド付き操作 非インタラクティブモード – スクリプト向け自動実行 リモートモード – リモート Db2 データベースへの接続と検証 包括的なレポート： カラーコード付きコンソール出力 タイムスタンプ付き詳細ログファイル 各チェックの PASS/FAIL/WARNING ステータス 失敗時の実行可能な推奨事項 インベントリ分析： 完全なデータベースオブジェクトインベントリ 移行準備状況の健全性チェック タイプ別オブジェクト数サマリー ツールは以下のシナリオで使用できます： 移行前計画 – 潜在的な問題を早期に特定し、修正のための時間を確保するため 移行準備状況評価 – Amazon RDS for Db2 への移行プロセス開始前の最終検証のため Fix Pack(s) 適用後 – Db2 Fix Pack 適用後にデータベースを検証し、適切な更新完了を確認するため 最終 Db2 バックアップ前 – Amazon RDS for Db2 へのリストア前に準備完了を確認する（クリーンな出力はリストアの失敗を防ぐセーフガードとなる）ため。データベースバックアップコマンドの使用に関する一般的なガイダンスは後述します。 ツールの使い方 前提条件 開始前に、以下の前提条件と制限事項を確認してください： ローカルモード Db2 インスタンスが起動・アクセス可能であること SYSADM 権限を持つ Db2 サーバー上でツールを実行すること Db2 環境が適切に source されていること（ . ~/sqllib/db2profile ） Db2 インスタンスユーザー（例：db2inst1）として実行すること リモートモード Db2 クライアントがインストール・設定済みであること リモート Db2 サーバーへのネットワーク接続があること DBADM または SYSMAINT 権限を持つ有効な Db2 ユーザー認証情報があること データベースがカタログ済み、または db2dsdriver.cfg ファイルに DSN エントリが存在すること インタラクティブフローでは、ツールは以下の手順を実行します： Db2 バージョン情報を表示する 利用可能なインスタンスを一覧表示する 検証対象の現在のインスタンスを特定する 現在のインスタンス内のローカルデータベースを検出する Db2 サーバー上でスクリプトを実行できない場合はリモートデータベースを検証する 検証対象データベースを選択する 包括的な検証チェックを実行する 詳細レポートを生成する 以下のコマンドはインタラクティブ実行のコードです。 ツールの直接実行 curl -sL https://bit.ly/precheckdb2migration | bash ダウンロードして実行 curl -sL https://bit.ly/precheckdb2migration -o db2_migration_prereq_check.sh chmod +x db2_migration_prereq_check.sh ./db2_migration_prereq_check.sh リモートモード – 直接実行 export DB2USER=myuser export DB2PASSWORD=mypassword export DBNAME=mydatabase curl -sL https://bit.ly/precheckdb2migration | bash -s -- --verbose リモートモード – ダウンロードして実行 curl -sL https://bit.ly/precheckdb2migration -o db2_migration_prereq_check.sh chmod +x db2_migration_prereq_check.sh export DB2USER=myuser export DB2PASSWORD=mypassword export DBNAME=mydatabase # リモートデータベースに対して検証を実行 ./db2_migration_prereq_check.sh --verbose 注意：リモート接続に使用する DBNAME 環境変数は、ローカルにカタログされたリモートデータベース名、または db2dsdriver.cfg ファイルで使用される DSN エントリ名である必要があります。 以下のコマンドは、Db2 サーバー上でローカル実行する非インタラクティブモードのコードです。 特定インスタンスの検証 DB2_INSTANCES=db2inst1 \ ./db2_migration_prereq_check.sh カスタムレポート出力先を指定 DB2_INSTANCES=db2inst1 \ REPORT_FILE_PATH=/opt/reports/db2_check.log \ ./db2_migration_prereq_check.sh 注意：「db2_inventory」プレフィックスのレポートは、スクリプトを起動したディレクトリに生成されます。 デバッグ用の詳細出力 DB2_INSTANCES=db2inst1 \ ./db2_migration_prereq_check.sh --verbose 複数インスタンスの実行では、各インスタンスで個別にツールを実行できます。以下のサンプルコードを参照してください： #!/bin/bash # 複数インスタンスの検証 INSTANCES=("db2inst1" "db2inst2" "db2inst3") REPORT_DIR="/var/log/db2_migration_checks" mkdir -p "$REPORT_DIR" for instance in "${INSTANCES[@]}"; do echo "Validating instance: $instance" su - "$instance" -c " . ~/sqllib/db2profile export REPORT_FILE_PATH='$REPORT_DIR/${instance}_migration_check.log' /path/to/db2_migration_prereq_check.sh " done ツール出力の理解 ツールをローカルで実行するか Db2 クライアント経由で実行するかによって、動作が若干異なります。 ローカル実行 以下のコマンドを実行すると、スクリプト db2_migration_prereq_check.sh がダウンロードされ即座に実行されます。 curl -sL https://bit.ly/precheckdb2migration | bash -s -- --verbose Db2 インスタンス上でローカル実行した場合、すべてのローカルデータベースを特定し、それらに対して検証を実施します。 出力には Db2 バージョン、検出されたローカルデータベース数、検証結果、データベースサイズ、インベントリ分析が表示されます。 リモート実行 リモート実行の場合、スクリプト実行前に DB2USER、DB2PASSWORD、DBNAME の3つの環境変数をエクスポートする必要があります。検証は一度に1つのデータベースに対してのみ実施されます。 検証チェックの内容 以下の表はさまざまなカテゴリのチェック内容を示しています。ツールはデータベースインベントリ分析も実施し、結果を db2_inventory_yyyymmdd_hhmmss.json としてローカルに保存します。 カテゴリ チェック内容・推奨事項・修正方法 db2updv115 最新の Amazon RDS for Db2 ソフトウェアを使用して RDS for Db2 インスタンスを作成していることを確認してください。IBM は db2updv115 ツール使用時に Db2 インスタンスクラッシュを引き起こす 既知の問題 を文書化しており、修正は Amazon RDS for Db2 ソフトウェアの最新リリースで提供されています。 これは RDS Db2 リストア失敗の最も一般的な原因の一つです。 db2updv115 ツールがデータベースで実行されたかどうかを検証する良い方法はありません。 推奨： db2updv115 -d &lt;DBName&gt; InDoubt Transaction（未確定トランザクション） 未確定トランザクションとは、準備済みだがまだコミットもロールバックもされていないトランザクションです。 すべてのトランザクションをコミットまたはロールバックする必要があります。 推奨： db2 list indoubt transactions with prompting Invalid Objects（無効オブジェクト） すべての無効オブジェクトを再検証またはドロップする必要があります。 推奨： db2 "call SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS()" （複数回実行が必要な場合あり） Tablespace Check（テーブルスペースチェック） すべてのテーブルスペースが Normal 状態である必要があります。 推奨： テーブルスペースの状態は 20 種類以上あります。状態に応じて適切な対処を行ってください。IBM の ドキュメント の各テーブルスペース状態の説明を参照してください。 Non-Fenced Routines（ fenced でないルーティン） すべてのルーティンは fenced である必要があります。 推奨： fenced ではないルーティンは Amazon RDS for Db2 では許可されていません。すべてのルーティンを fenced に変換してください。 Automatic Storage（自動ストレージ） Amazon RDS for Db2 へのリストア失敗の一般的な原因です。少なくとも1つのストレージグループが存在する必要があります。 推奨： db2 "CREATE STOGROUP &lt;name&gt; ON '&lt;PATHname&gt;'" Database Config（データベース設定） 以下のパラメータが No である必要があります： Backup pending Rollforward pending Restore pending Upgrade pending Database Config（データベース設定） 循環ログの場合、ログファイル数は254以下であること。 アーカイブログの場合、ログファイル数は4096以下であること。 Database Sizing（データベースサイジング） Amazon RDS for Db2 のサイジング時は、データベースとログスペースの合計を考慮してください。 推奨： db2_migration_prereq_report_yyyymmdd_hhmmss.log の RDS_SIZING_TIER 変数を参照してください。 Federation（フェデレーション） すべての DBMS へのフェデレーションは Amazon RDS for Db2 でサポートされていません。サポートされていない DBMS へのフェデレーションがあっても Amazon RDS for Db2 へのリストア失敗は発生しませんが、アプリケーションがサポートされていない DBMS へのフェデレーションに依存している場合は機能が失われます。 推奨： サポートされているライブラリは libdb2drda.so と libdb2rcodbc.so です。 Java stored procedures（Java ストアドプロシージャ） データベースに JAR ファイルが定義されている場合（sysibm.sysjarcontents）、必要に応じて RDS for Db2 インスタンスに JAR ファイルを追加してください。 推奨： インストール： call sqlj.install_jar('jar-url', 'jar-id') → 例： call sqlj.install_jar('file:/home/rdsdb/Common.jar', 'COMMON') 置換： call sqlj.replace_jar('jar-url', 'jar-id') → 例： call sqlj.install_jar('file:/home/rdsdb/Common.jar', 'COMMON') 削除： db2 "sqlj.remove_jar('jar-id') → 例： call sqlj.remove_jar('COMMON') レポートの読み方と対応 以下の表は生成されるレポートをまとめたものです。 レポート名 詳細 db2_migration_prereq_report_yyyymmdd_hhmmss.log スキャンされたすべてのデータベースのチェック、推奨事項、修正方法を含むレポート。 db2_inventory_detail_ yyyymmdd_hhmmss.txt スキャンされた各データベースのテーブルスペース数、テーブル数、ビュー数、インデックス数などのインベントリ詳細。 db2_inventory_summary_ yyyymmdd_hhmmss.txt スキャンされたすべてのデータベースのインベントリ情報サマリー。 db2_inventory_ yyyymmdd_hhmmss.json スキャンされた各データベースのインベントリ詳細（JSON形式）。 DATABASE READINESS ステータスを確認するには DATABASE SUMMARY セクションに移動してください： ========================================== DATABASE SUMMARY: DB2DB ========================================== Checks performed: 15 Passed: 15 Warnings: 0 Failed: 0 Informational: 48 ========================================== DATABASE READINESS: READY Database DB2DB passed all checks ========================================== 移行準備レベルは以下のとおりです： READY FOR MIGRATION（移行準備完了）： すべてのチェックが合格（PASS ステータス） 重大な問題なし データベースのバックアップおよび Amazon RDS for Db2 へのリストア準備完了 REVIEW REQUIRED（要確認）： 一部の警告あり 推奨事項の手動確認が必要 考慮事項はあるが移行は可能 NOT READY FOR MIGRATION（移行不可）： 重大な失敗あり 移行前に失敗したチェックへの対処が必須 移行を進めるべきではない ベストプラクティス 以下のベストプラクティスを考慮してください： 早期かつ頻繁に実行する： 移行計画フェーズ中に実行する データベース変更後に再実行する バックアップ作成直前に検証する 問題に体系的に対処する： まず FAIL 項目を修正する（ブロッキング問題） WARNING 項目を潜在的リスクとして確認する INFO 項目を参考情報として文書化する 複数データベースの自動化： 自動化には非インタラクティブモードを使用する マルチインスタンス環境向けスクリプトを作成する 定期的な検証実行をスケジュールする ドキュメントの維持： 監査証跡として検証レポートを保管する 実施した修正アクションを文書化する 検証履歴を時系列で追跡する 高度な使用シナリオ 以下のコードは継続的インテグレーションのシナリオを示しています： #!/bin/bash # CI/CD パイプライン統合 DB_VALIDATION_EXIT_CODE=0 for instance in $(db2ilist); do su - "$instance" -c " . ~/sqllib/db2profile /path/to/db2_migration_prereq_check.sh " || DB_VALIDATION_EXIT_CODE=1 done if [ $DB_VALIDATION_EXIT_CODE -ne 0 ]; then echo "db2 validation failed - blocking deployment" exit 1 fi 以下のコードは定期監視のシナリオを示しています： #!/bin/bash # 定期検証用 Cron ジョブ # 0 2 * * 1 /path/to/weekly_db2_validation.sh REPORT_DIR="/var/log/db2_weekly_checks" mkdir -p "$REPORT_DIR" DATE=$(date +%Y%m%d) for instance in $(db2ilist); do su - "$instance" -c " . ~/sqllib/db2profile export REPORT_FILE_PATH='$REPORT_DIR/${instance}_${DATE}.log' /path/to/db2_migration_prereq_check.sh " done # サマリーメールを送信 mail -s "Weekly db2 Validation Report" admin@company.com &lt; "$REPORT_DIR/summary_${DATE}.txt" よくある問題のトラブルシューティング 以下の表はよくある問題とトラブルシューティングのヒントを示しています。 問題 トラブルシューティング db2 コマンドが見つからない # db2 環境をソースする . ~/sqllib/db2profile # Db2 インストールを確認 which db2 echo $DB2INSTANCE Db2 インスタンスが見つからない # インスタンスが起動しているか確認 db2ilist # ユーザー権限を確認 whoami id データベースに接続できない # データベースディレクトリを確認して手動接続を試みる db2 list db directory db2 connect to &lt;dbname&gt; 接続に時間がかかりすぎる # データベースをアクティベート db2 activate db &lt;dbname&gt; db2 list active databases 権限エラー # Db2 インスタンスユーザーとして実行していることを確認 su - db2inst1 # 権限を確認 db2 "SELECT * FROM TABLE(SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID('DB2INST1'))" データベースバックアップコマンドの一般的なガイダンス データベースバックアップコマンドを使用する際は、以下のベストプラクティスを考慮してください： Amazon RDS for Db2 は Amazon Simple Storage Service （Amazon S3）のストリーミング機能を使用して並列ストリームでデータベースをリストアします。S3 ストリーミングはマルチパートファイルのバックアップイメージで最も効果的です。例えば、 db2 backup database &lt;dbname&gt; to /backup コマンドは単一イメージを生成しますが、パフォーマンス面で最適ではありません。代わりに db2 backup database to /backup, /backup, /backup, /backup, /backup のように複数のロケーションを指定してください。この例では、バックアップ操作が並列実行され、データベースイメージが .001 、 .002 、 .003 、 .004 、 .005 の5つのパートに分割されます。 小規模データベースでもマルチパートバックアップの使用を検討してください。Linux マシンの CPU とメモリ能力に基づいてロケーション数を決定します。不明な場合は20ロケーションの使用を推奨します。 セルフマネージド Db2 から AWS リージョンのネットワークへの接続がある場合、Amazon S3 への直接バックアップを検討してください。データベースのマルチパートイメージを Amazon S3 にコピーするには、必要な権限を持つバケットをアカウントに作成し、そのバケットを使用して db2 ストレージアクセスエイリアス を作成します。 ストレージエイリアス作成時の考慮事項： Db2 on EC2 を使用する場合、Amazon S3 バケットへのアクセスに適切な IAM ロールを付与し、ストレージエイリアス作成コマンドに USER 、 PASSWORD 、 TOKEN を指定しないでください。 コマンド例 db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER https://s3.&lt;region&gt;.amazonaws.com" CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt; セルフマネージド Db2 を使用する場合、AWS CLI 認証情報を取得してストレージエイリアスを作成できます。 長期認証情報を使用する場合： db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER s3.&lt;region&gt;.amazonaws.com USER $AWS_ACCESS_KEY_ID PASSWORD $AWS_SECRET_ACCESS_KEY CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt;" 短期認証情報を使用する場合： db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER s3.&lt;region&gt;.amazonaws.com USER $AWS_ACCESS_KEY_ID PASSWORD $AWS_SECRET_ACCESS_KEY CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt; TOKEN $AWS_SESSION_TOKEN" バックアップコマンドでストレージエイリアスを使用して、データベースバックアップイメージを Amazon S3 に直接書き込みます。例えば、作成したストレージエイリアスが db2S3 の場合、以下のコマンドを使用します： db2 backup database &lt;dbname&gt; to DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3 このコマンドにより、データベースのマルチパートイメージが S3 バケット内で5つのパートに分割されます。 データベースリストアコマンドの一般的なガイダンス データベースリストアコマンドを使用する際は、以下のベストプラクティスを考慮してください： データベースバックアップのマルチパートコピーが保存された S3 バケットへのアクセスに適切な AWS Identity and Access Management （IAM）ロールを持つ RDS for Db2 インスタンスの Amazon S3 統合 を有効にしていることを確認してください。 ストアドプロシージャ rdsadmin.set_configuration を使用して RESTORE_DATABASE_NUM_BUFFERS 、 RESTORE_DATABASE_PARALLELISM 、 RESTORE_DATABASE_NUM_MULTI_PATHS などのパフォーマンスパラメータを設定してください。 パラメータ USE_STREAMING_RESTORE を TRUE に設定して、Amazon S3 から Amazon RDS for Db2 への直接 S3 ストリーミングを有効にしてください。 Amazon RDS for Db2 は rdsadmin.restore_database ストアドプロシージャを使用してマルチパートバックアップイメージをリストアするための Db2 ストレージエイリアスを自動的に作成します。 rdsadmin.restore_database ストアドプロシージャで使用する s3_prefix 変数に注意してください。このプレフィックスは .001、.002 などの拡張子を除いたマルチパートバックアップイメージの共通部分です。 オンラインバックアップイメージを使用する場合、Db2 アーカイブログファイルを Amazon S3 にコピーし続け、 rdsadmin.rollforward_database ストアドプロシージャを実行してアーカイブログを適用する必要があります。すべてのログファイルを適用するまでこのプロセスを繰り返してください。各操作には異なるプレフィックスを使用してください。 すべてのログファイルを適用後、 rdsadmin.complete_rollforward ストアドプロシージャを実行して RDS for Db2 データベースを接続可能な状態にしてください。 手動手順の代わりにオンラインリストアの自動化には Db2MT ツール の使用を検討してください。 ツールの機能拡張 このツールのソースコードは以下の GitHub リポジトリ で公開されています。機能拡張のリクエストは Issue を登録 するか、変更提案は Pull Request として送信してください。 追加リソース Amazon RDS for Db2 と移行戦略の詳細については、以下のリソースを参照してください： Amazon RDS for Db2 ユーザーガイド Amazon RDS for Db2 へのデータマイグレーション戦略 AIX、Windows 上のセルフマネージド型 Db2 から Amazon RDS for Db2 へ IBM Q レプリケーションを使用してほぼゼロのダウンタイムで移行 セルフマネージド Db2 から Amazon RDS for Db2 へのフルロードおよび継続的レプリケーションタスクのパフォーマンス最適化 IBM Db2 for z/OS から Amazon RDS for Db2 へのテーブル移行 まとめ Db2 移行前提条件検証ツールは、一般的な問題を移行スケジュールに影響を与える前に特定・対処することで、移行失敗を大幅に削減します。このツールを移行ワークフローに組み込むことで、以下を実現できます： 移行リスクの低減 – プロセスの早期に問題を特定 時間の節約 – リストア失敗やトラブルシューティングを回避 成功率の向上 – データベースが適切に準備されていることを確認 ドキュメントの維持 – 詳細な検証記録を保持 Db2 のメンテナンスおよび移行プロセスの一部としてこのツールを定期的に使用することで、Amazon RDS for Db2 へのスムーズで成功した移行を実現できます。 このアプローチをご自身の環境で試しましたか？どのように機能したか、またはツールへの機能拡張要望があればぜひお知らせください。 著者について Vikram S Khatri Vikram は Amazon RDS for Db2 のSr. DBE です。Db2 において20年以上の経験を持ちます。ゼロからの新製品開発を楽しんでいます。余暇には瞑想を実践し、ポッドキャストを聴くことを楽しんでいます。 Umair Hussain Umair は Amazon RDS for Db2 のシニアデータベースエンジニアです。Db2 において20年以上の経験を持ちます。 Rajib Sarkar Rajib は Amazon RDS for Db2 のシニアデータベースエンジニアです。Db2 において20年以上の経験を持ちます。 この記事はクラウドサポートエンジニアの Shota Miyazaki が翻訳しました。

本記事は 2026 年 3 月 9 日 に公開された「 Kinesis On-demand Advantage saves 60%+ on streaming costs 」を翻訳したものです。 Amazon Kinesis Data Streams は、あらゆる規模のストリーミングデータをキャプチャ、処理、保存できるサーバーレスのストリーミングデータサービスです。2025 年 11 月 4 日、 Amazon Kinesis Data Streams に On-demand Advantage モードが導入されました。オンデマンドストリームで瞬時にスループットを増加させ、安定したストリーミングワークロードのコストを最適化できる機能です。従来はキャパシティを手動管理するプロビジョンドモードか、自動スケーリングするオンデマンドモードのどちらかを選ぶ必要がありましたが、On-demand Advantage の導入によりストリームタイプを意識する必要がなくなりました。 本記事では、使用パターンが異なる 3 つのシナリオを比較し、On-demand Advantage モードでパフォーマンスと柔軟性を維持しながらストリーミングコストを最適化する方法を紹介します。正確に比較するため、2 つの AWS アカウントでシミュレーションを実施しました。1 つは On-demand Standard モード、もう 1 つはアカウントレベルで On-demand Advantage モードを有効にしたアカウントです。両方のデプロイで同一のストリーム構成、シャード割り当て、取り込みパターンを維持し、以下のシナリオで課金への影響を比較しました。 本記事に記載されている料金はすべて us-east-1 リージョンのものです。 On-demand Advantage の節約効果の内訳 前回の記事 では、ウォームスループット機能と、On-demand Advantage モードでストリームをウォームアップしてギガバイト単位や毎秒数百万レコードを処理する方法を紹介しました。次に、On-demand Advantage モードでパフォーマンスと柔軟性を維持しながら、さまざまなストリーミングユースケースがどのようにコスト効率よく運用できるかを説明します。 アカウントレベルで On-demand Advantage モードを有効にすると、On-demand Standard と比較して多くの面でコスト削減が得られます。主なポイントは以下のとおりです。 AWS リージョンで最低 25 MiBps の使用量をコミットすることで、60% 以上の節約が得られます。最低コミットメントは、AWS バージニア北部リージョンの 公開料金 に基づき 1 日あたり約 100 ドルです。 Enhanced Fan Out コンシューマーの料金が 68% 低くなり、ストリームあたり最大 50 まで利用可能です (On-demand Advantage なしでは 20)。 24 時間を超えるデータ保持の料金が 77% 低くなります。 ストリームごとの最低固定料金がないため、コスト増加なしに必要な数のストリームを利用できます。 Kinesis On-demand Advantage を選ぶ理由: 60% 以上の節約 Amazon Kinesis Data Streams の On-demand Standard モードと Advantage モードの両方を評価するため、10 個のストリームをデプロイし、全ストリームで合計 100 MiBps の持続的な取り込みスループットを生成しました。EC サイトがユーザーのクリックストリームデータをストリーミングしてリアルタイムインサイトを生成するケースをモデル化しています。シミュレーションは異なるモードの 2 つの AWS アカウントで 2 日間実施しました。1 日目は 100 MiBps の安定した取り込みレートを維持しました。2 日目は、ホリデーセールイベントに備えて 10 個すべてのストリームのウォームスループットキャパシティを 10 倍に増加させ、実際の取り込みレートは 100 MiBps のまま維持しました。各ストリームは 10 MiBps を取り込み、全オンデマンドストリームで合計 100 MiBps です。 2 日目に、On-demand Advantage モードを設定したアカウントで 100 MiBps のウォームスループットを有効にしました。ウォームスループットを使えば、トラフィック急増に備えてストリームを事前にスケールアップできます。 On-demand Standard の Cost Explorer: On-demand Advantage モードの Cost Explorer: シナリオ 1 で On-demand Advantage のコスト効率が高い理由は、安定したデータスループットと複数ストリームの利用にあります。Advantage モードではストリーム時間料金がゼロですが、On-demand Standard モードではストリーム時間あたり $0.04 の料金が発生します。さらに、Advantage モードの受信バイト料金は GB あたり $0.032 で、On-demand Standard は GB あたり $0.08 です。On-demand Standard 構成では 48 時間で合計 $2,071.75 のコストが発生し、1 日あたり $1,037、年間 $378,505 になります。同じワークロードを On-demand Advantage モードで実行すると、同じ 48 時間で $823.44、1 日あたり約 $412、年間コスト $150,380 です。On-demand Advantage ではウォームスループットの追加料金もかかりません。60% のコスト削減に相当し、このワークロードだけで年間 $228,125 の節約になります。 シナリオ 2: 1 アカウントで 10 ストリーム、15 MiBps スループットと延長保持 ある医療企業では、データの再処理に備えて 2 日間のデータ保持期間が必要であり、規制要件により異なる種類のデータを別々のストリームに保存する必要があります。シナリオ 2 の再現として、On-demand Standard モードと Advantage モードの両方で、48 時間の延長保持期間を設定した 10 個の Amazon Kinesis Data Streams をデプロイしました。延長保持により、ダウンストリームシステムはデータを再処理し、一時的な障害から復旧できます。複数ストリームと保持期間を利用するため、On-demand Advantage モードでコスト効率が高いと予想されます。コスト内訳を見ていきましょう。 コストを評価するため、10 ストリームに分散した 15 MiBps の安定した取り込みトラフィックを 48 時間生成しました。On-demand Standard モード: On-demand Advantage モード有効時: Cost Explorer のスクリーンショットで、On-demand Standard モードと Advantage モードの料金を並べて比較できます。On-demand Standard の 1 日あたりのコストは $176 で、年間 $64,240 です。On-demand Advantage の 1 日あたりのコストは $104 で、年間コストは $37,960 です。15 MiBps のスループットと延長保持を利用しても、Advantage モードで 41% の節約を達成しました。Standard モードでは 24 時間を超え 7 日間までのデータ保存に GB あたり $0.10 の追加料金がかかります。Advantage モードでは 24 時間を超え 365 日間までのデータ保存に GB 月あたり $0.023 の追加料金となり、データストレージのコストが最適化されます。シナリオ 2 の結果は、Advantage モードがより幅広いワークロードでコストメリットをもたらすことを示しています。Advantage モードを有効にすると、最低 25 MiBps の使用量にコミットすることになります。しかし、15 MiBps スループットのシミュレーションでも大幅なコスト削減を達成しました。Advantage モードでは、10 MiBps 以上を取り込んでいれば、25 MiBps のしきい値にコミットしていても Standard モードより低コストになります。 シナリオ 3: 1 つの Kinesis Data Stream と 10 個の Enhanced Fan-Out コンシューマー マイクロサービスアーキテクチャでは、複数のサービスが同じデータストリームから同時に低レイテンシーで読み取る必要がある場合があります。システムの進化に伴い、新しい分析ユースケースをサポートし、ストリーミングデータパイプラインからより深いインサイトを得るために、Enhanced Fan-Out (EFO) コンシューマーが追加されることがあります。 次に、マイクロサービスアーキテクチャで On-demand Advantage モードを使用した EFO コンシューマーのコスト比較を評価します。24 時間にわたり、標準の 24 時間保持を設定した 1 つの Amazon Kinesis Data Stream に、EFO コンシューマーとして設定した 10 個の AWS Lambda 関数を接続してテストしました。 複数の EFO コンシューマーが同じストリームに同時にアクセスした場合のコスト影響を評価するため、評価期間を通じて 25 MiBps の安定した取り込みレートを生成しました。以下のチャートは、25 MiBps ペイロードの Enhanced Fan-Out コンシューマーを持つ Kinesis Data Stream を示しています。 以下のチャートは、On-demand Standard モードと On-demand Advantage モード有効時のコスト差を示しています。 Cost Explorer の分析から、複数の EFO コンシューマーを使用しても、On-demand Advantage モードの方が On-demand Standard モードより全体コストが低いことがわかります。On-demand Standard のコストは $1,266 で、Advantage モードのコストは $419 でした。同じワークロード特性で約 67% の節約を達成し、年間 $309,155 の節約になります。イベント駆動型アーキテクチャで複数のサービスがストリーミングデータへの独立したリアルタイムアクセスを必要とする組織にとって、EFO のコスト削減効果は特に大きいといえます。Enhanced Fan-Out のデータ取得料金は、Advantage モードではコンシューマーあたり GB あたり $0.016 で、Standard モードの $0.05 と比較して大幅に低くなっています。一方、持続スループットが低い (10 MiBps 未満) スパイクが大きく予測不可能なワークロードは、On-demand Standard の候補として推奨されます。スループット使用量をコミットせずに、ストリームのスループットキャパシティを自動スケーリングさせられます。 On-demand Advantage とプロビジョンドモードの比較: On-demand Standard モードと On-demand Advantage モードの両方が利用可能になったことで、プロビジョンドモードに頼る必要がなくなりました。キャパシティを手動管理する必要がなく、オンデマンドストリームならシンプルな料金モデルで運用できます。さらに、多数のストリームを運用したり、延長保持や Enhanced Fan-Out などの機能を使用しているプロビジョンドワークロードのお客様は、On-demand Advantage への移行を強く検討すべきです。データストリームはどのモードを選択しても同じ基盤インフラストラクチャを使用するため、On-demand Advantage とプロビジョンドの間で可用性や信頼性に違いはありません。 ウォームスループットに追加料金がかからないため、瞬時スケーリングが必要な場合は On-demand Advantage がプロビジョンドモードより適しています。 Gbps 規模でも、On-demand Advantage は実際のデータ使用量に基づく課金で競争力のある料金です。 On-demand Advantage は、EFO (マイクロサービスのような高ファンアウトニーズ向け) と延長保持の利用コストが大幅に低くなっています。 比較の参考として、Kinesis コンソールを使用して、アカウントの上位 200 のプロビジョンドストリームが On-demand Advantage に適しているかどうかを確認できます。 まとめ 本記事では、Amazon Kinesis Data Streams の On-demand Advantage モードがパフォーマンスと柔軟性を維持しながら大幅なコスト削減を実現する 3 つの実際のシナリオを紹介しました。On-demand Advantage は大規模ワークロードで優れたパフォーマンスを発揮し、On-demand Standard と合わせて、Kinesis Data Streams はさまざまなストリーミングユースケースにシンプルかつコスト効率の高いソリューションを提供します。ワークロードが安定して 10 MiBps 以上をストリーミングする場合、2 つ以上のコンシューマーにファンアウトする場合、24 時間を超えてデータを保持する場合、または数百のストリームを運用する場合は、On-demand Advantage が最もコスト効率の高いモードです。それ以外のワークロードには、On-demand Standard モードが適しています。多様なプロデューサーからコンシューマーへ毎秒数百万レコードやギガバイト単位のデータをストリーミングする場合でも、Kinesis Data Streams で対応できます。ぜひ Kinesis Data Streams On-demand Advantage を活用して、リアルタイムインサイトを組織やプロセスに取り入れてみてください。 著者について Sandhya Khanderia Sandhya は、AWS のシニアテクニカルアカウントマネージャー兼データ分析スペシャリストです。分析およびデータサービスの深い専門知識を持ち、パフォーマンス、スケーラビリティ、コスト効率に優れたクラウドアーキテクチャの最適化を支援しています。 Pratik Patel Pratik は、AWS のシニアテクニカルアカウントマネージャー兼ストリーミング分析スペシャリストです。AWS のお客様と連携し、ベストプラクティスに基づくソリューションの計画と構築を支援するとともに、お客様の AWS 環境の運用状態を健全に保つための継続的なサポートと技術ガイダンスを提供しています。 Varsha Palepu Varsha は、AWS のソリューションアーキテクトとして、中小企業のイノベーションと AWS 上での構築を支援しています。ストリーミングチームに所属し、技術コンテンツの作成やお客様のクラウド上での目標達成を支援しています。 Kalyan Janaki Kalyan は、Amazon Web Services のシニアビッグデータ＆分析スペシャリストです。高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースソリューションの設計と構築を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

2026 年 3 月 3 日、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、「フィジカル AI 開発支援プログラム by AWS ジャパン」のキックオフイベントを東京の AWS 目黒オフィスにて開催しました。本プログラムは 2026 年 1 月 27 日に発表 し、応募受付を開始したもので、多数の応募の中から厳正な選考を経て採択された皆さまをお迎えし、約 6 ヶ月間にわたる開発支援の幕開けとなりました。 フィジカル AI の可能性 フィジカル AI とは、物理世界で動作する AI の総称です。ロボットや自動運転車、ドローンなど、現実世界のセンサー情報を理解し、自律的に判断・行動する AI 技術を指します。近年、大規模言語モデル（LLM）の急速な進化を背景に、言語だけでなく視覚情報と行動を統合的に扱う Vision-Language-Action（VLA）モデルをはじめとしたロボット基盤モデルの研究開発が世界的に加速しています。 日本は製造業やロボティクスにおいて世界をリードしてきた歴史があります。この強みと、生成 AI の最新技術を掛け合わせることで、日本発のフィジカル AI イノベーションが生まれる大きな可能性があると私たちは考えています。 AWS ジャパンは 2023 年の LLM 開発支援プログラムを皮切りに、生成 AI 実用化推進プログラムや経済産業省 GENIAC へ参画するお客様の支援など、これまでに 300 を超える企業・団体の生成 AI 開発を支援してきました。本プログラムは、その知見と実績をフィジカル AI 領域に展開するものです。 プログラム概要 本プログラムは、AWS 上でロボット基盤モデル等を開発する日本の企業・団体を包括的に支援するもので、データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまでの一連のパイプライン構築をカバーします。 技術支援 : ソリューションアーキテクト（SA）によるアーキテクチャガイダンス、Prototyping &amp; Cloud Engineering（PACE）チームによるサンプルコード提供、生成 AI イノベーションセンター（GenAIIC）によるロボット基盤モデル開発支援 コスト最適化支援 : AWS クレジットの提供（計算リソースおよびデータ保管等の利用を支援） コミュニティ形成 : フィジカル AI コミュニティ Powered by AWS として、技術勉強会・ワークショップの開催、エンジニア間の交流促進、業界横断の知見共有 GTM 支援 : モデル開発企業と製造業などロボット導入企業とのマッチング機会の提供、実証環境の提供支援、スタートアップ間の技術連携促進 支援期間は 2026 年 3 月から約 6 ヶ月間で、成果発表会を予定しています。プログラムの詳細は 発表時のブログ記事 をご覧ください。 キックオフイベントの様子 キックオフイベントは、採択企業の皆さまと AWS の支援チームが一堂に会する初めての機会となりました。 ご挨拶 イベントの冒頭では、アマゾン ウェブ サービス ジャパン合同会社 代表執行役員社長の白幡 晶彦よりプログラムに対するビジョンについてお話しさせていただきました。 Amazon Robotics の取り組みについて 続いて、アマゾンジャパン合同会社 オペレーション技術統括本部 技術開発本部長 ダイレクターの内田 昌宏より、Amazon Robotics の取り組みについて講演いたしました。 Amazon のフルフィルメントセンター（FC）では、商品の入荷から出荷までの一連のオペレーションにおいて、AI とロボティクスの融合が進んでいます。講演では、自動レシーブ、AI による在庫配置最適化、Amazon Robotics の自動倉庫システム、そして触覚センサーをもつ棚入れ・棚出しロボット Vulcan など、実際の物流現場で稼働するフィジカル AI の事例をご紹介しました。 特に、Vision と深層学習で作業者の手の動きをトラッキングしてロケーションデータを自動確定する Intent Detection System（IDS）や、ML と Vision を活用して在庫の過不足を自動検出する Visual Bin Inspection（VBI）といった、現場の課題を AI で解決する具体的な取り組みをお伝えしました。さらに、ML アルゴリズムによる最小梱包の自動指定や、生成 AI を活用したオペレーションマネジメントなど、AI が物流オペレーション全体に浸透している様子を共有いたしました。 白幡 晶彦 内田 昌宏 Amazon は世界各国の物流拠点で 100 万台を超えるロボットを運用しており、こうした大規模な実践から得られた知見を、本プログラムを通じて日本のフィジカル AI 開発者の皆さまと共有していきます。 プログラム支援内容の紹介 続いて、プログラムの具体的な支援内容、支援チームのメンバー紹介、今後の進め方についてご説明しました。 本プログラムの技術支援の柱のひとつとして、 Physical AI Scaffolding Kit（PASK） が紹介されました。PASK は、PACE チームが開発するフィジカル AI 開発者向けのツールキットで、開発ライフサイクル全体の課題を体系的に解決することを目指しています。 フィジカル AI の開発は、データ収集・前処理からモデル学習、シミュレーション、実機デプロイまで、多くのステップにまたがります。各ステップで必要となるインフラ構築やパイプライン設計に多大な時間を費やし、本来注力すべきモデル開発やアルゴリズム改善に十分なリソースを割けないという課題を、多くの開発者が抱えています。 PASK の第一弾として、Amazon SageMaker HyperPod 上で VLA のトレーニングを実行する環境のサンプルが 3 月後半に提供予定です。Physical Intelligence の openpi（π0）や NVIDIA Isaac GR00T のファインチューニングサンプルも含まれる予定で、プログラム参加企業へのヒアリングを通じて継続的にフィードバックを取り込み、PASK を進化させていきます。 また、PACE チームによるプロトタイピング支援も提供されます。参加企業が実現したいフィジカル AI システムのプロトタイプを、AWS 上に共同で開発するプログラムで、トレーニング可能な標準化されたデータパイプラインの構築や、スケーラブルなトレーニング環境の整備、Sim2Real 等の技術的ブロッカーの解決を支援します。 さらに、 GenAIIC は、世界中の生成 AI エキスパートの知見に基づくベストプラクティスを共有し、VLA 開発の支援実績を活かしてソリューションの構築・展開を支援します。 採択企業によるピッチ キックオフのメインセッションとして、採択企業の皆さまによるピッチが行われました。会場に参加いただいた企業を中心に、それぞれが取り組むフィジカル AI の課題とビジョンを共有しました。 ロボットメーカー、AI スタートアップ、製造業、大学研究機関など、多様なバックグラウンドを持つ企業・団体が集まり、産業用ロボットの知能化、自律移動ロボット、マニピュレーション、ヒューマノイドなど、幅広い領域のプロジェクトが紹介されました。参加者同士が互いの取り組みを知り、刺激を受け合う貴重な機会となりました。 なぜコミュニティが重要なのか – 日本のフィジカル AI エコシステムの構築に向けて キックオフイベントの後半では懇親会が開催され、採択企業の皆さまと AWS チームが活発に交流しました。この「つながり」こそが、本プログラムが最も大切にしている要素のひとつです。 日本のフィジカル AI 業界の現状と課題 フィジカル AI の開発には、ソフトウェアだけの AI 開発とは異なる固有の課題があります。 データ収集の困難さ : ロボット基盤モデルの学習には、現実世界での大量の行動データが必要です。しかし、実機でのデータ収集はコストと時間がかかり、一社単独で多様なデータを網羅的に集めることには限界があります。シミュレーション環境の構築や合成データの生成といった技術的アプローチが重要性を増しており、本プログラムでもこうした取り組みを支援していきます。 ハードウェアとソフトウェアの融合 : フィジカル AI は、AI モデルの開発だけでなく、センサー、アクチュエーター、制御系、通信といったハードウェア領域との密接な連携が不可欠です。日本にはロボティクスや製造業で培われた優れたハードウェア技術がありますが、最新の生成 AI 技術との統合には、異なる専門領域をつなぐ人材やコミュニティが必要です。 研究と社会実装のギャップ : 大学や研究機関で生まれた先端技術を、実際の産業現場で使えるレベルまで引き上げるには、エンジニアリング、ビジネス、規制対応など多面的な取り組みが必要です。研究者と事業者が直接対話し、課題を共有できる場が不足しています。 計算資源へのアクセス : VLA モデルをはじめとするロボット基盤モデルの学習には、大規模な GPU コンピューティングリソースが必要です。特にスタートアップや大学研究室にとって、これらのリソースへのアクセスは大きなハードルとなっています。 コミュニティがもたらす価値 こうした課題は、一社や一組織だけで解決できるものではありません。だからこそ、本プログラムでは「コミュニティ形成」を 4 つの支援柱のひとつとして位置づけています。 知見の共有と相互学習 : 異なる領域で活動する企業・研究者が集まることで、技術的なブレークスルーや失敗からの学びを共有できます。キックオフイベントのピッチセッションでも、各社の発表に対して活発な質疑応答が行われ、分野を超えた知見の交換が始まっています。 エコシステムの形成 : ロボットメーカー、AI 開発企業、部品サプライヤー、エンドユーザー企業、大学研究機関 — フィジカル AI の社会実装には、これらのプレイヤーが有機的につながるエコシステムが必要です。本プログラムは、その核となるコミュニティを日本に作ることを目指しています。 日本の強みを活かしたグローバル競争力 : 日本のものづくりの精度、品質管理のノウハウ、そして産業用ロボットの豊富な運用実績は、フィジカル AI の開発において大きなアドバンテージです。これらの強みを生成 AI と融合させ、日本発のフィジカル AI ソリューションを世界に発信していくためには、国内のプレイヤーが連携し、互いの強みを補完し合うことが重要です。 コミュニティイベントの開催予定 本プログラムでは、キックオフイベントに続き、支援期間中に定期的なコミュニティイベントを開催していきます。技術的なディープダイブセッション、参加企業同士のコラボレーションワークショップ、外部有識者を招いた勉強会など、参加者の皆さまのニーズに応じた多様なプログラムを計画しています。 今後のスケジュール 時期 タイトル 内容 2026 年 3 月 24 日（火）午後 Physical AI on AWS アーキテクチャ勉強会 Physical AI 開発に必要なアーキテクチャの解説と PASK（preview）のご紹介 2026 年 4 月 3 日（金）16:30〜 フィジカル AI 開発支援プログラム Community Meetup #1 AWS Startup Loft Tokyo にて開催予定（内容調整中） 2026 年 4 月 9 日（水） 基盤モデル開発 Deep Dive AWS を活用した大規模モデルの学習から推論までを包括的に扱う終日セッション。午前は AWS ParallelCluster での分散トレーニングハンズオン、午後は SageMaker HyperPod アーキテクチャ、大規模 MoE モデルの推論最適化、AWS Trainium による基盤モデル構築、Physical AI モデル学習のスケーリングパスなどを解説 2026 年 4 月中 ロボット勉強会 AI 開発者がロボット業界に入っていく上で知っておくべき知識の共有（内容・日程調整中） 2026 年 6 月 25-26 日 Demo Day（中間報告会） AWS Summit Tokyo 2026（幕張メッセ） 2026 年 7 月下旬 最終成果報告会 AWS 麻布台ヒルズ オフィス 予定 おわりに キックオフイベントを通じて、日本のフィジカル AI の未来を担う多様なプレイヤーが一堂に会し、熱気あふれるスタートを切ることができました。ロボティクスと生成 AI の融合は、製造業、物流、農業、医療、インフラなど、あらゆる産業に変革をもたらす可能性を秘めています。 AWS ジャパンは、本プログラムを通じて日本のフィジカル AI エコシステムの発展に貢献してまいります。採択企業の皆さまの挑戦と、成果発表会をどうぞご期待ください。 関連リンク: フィジカル AI 開発支援プログラム by AWS ジャパン（発表ブログ） 木村 公哉（Kimura, Koya） アマゾン ウェブ サービス ジャパン合同会社 シニアスタートアップソリューションアーキテクト。2023 年よりディープテックスタートアップを担当。支援プログラムの立ち上げなどに尽力し、2025 年よりフィジカル AI をはじめとしたロボティクス関連領域にも支援を拡大。2026 年 1 月に「フィジカル AI 開発支援プログラム by AWS ジャパン」を発足。VC・政府とのディスカッションを通じ、フィジカル AI・ディープテック領域のエコシステム形成にも取り組んでいる。

2025 年 12 月 1 日 – 12 月 5 日にラスベガスで開催された AWS re:Invent 2025 では、メディア＆エンターテインメント領域における最新の AWS 活用事例が多数紹介されました。また、2025 年 11 月 19 日 – 11 月 21 日に幕張メッセで開催された Inter BEE 2025 では、Global AI x Cloud Pavilion にて Create、Connect、Captivate の 3 つのテーマによる展示を、また DX x IP Pavilion では複数局を集約した統合クラウドマスターの展示等を行いました。 本振り返りセミナーでは、上記 2 つのイベントのハイライトを、メディア＆エンターテインメント業界のお客様向けにご紹介しました。また、AWS Black Belt Online Seminar 上でも本セミナーの 資料を公開 しています。 re:Invent &amp; Inter BEE 2025 re:Cap メディア &amp; エンターテインメント業界編 [ 資料 ] re:Invent 2025 re:Cap メディア＆エンターテインメント業界編 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 小南 英司 re:Invent 2025 のセッションから、メディア＆エンターテインメント業界に関連する事例を、コンテンツ制作、メディアサプライチェーン、Direct-to-Consumer、スポーツの 4 分野に分けて紹介しました。 コンテンツ制作では、Amazon MGM Studios が Amazon S3 と Amazon FSx でストレージを統合し、 Amazon EC2 上にリモート編集環境を構築することで、数週間かかっていたメディア転送時間を大幅に短縮しました。これにより処理時間の 50% 短縮と 5,000 マイル離れた遠隔地からの 1 秒未満の遅延での編集を実現しました。また、Angry Birds を制作する Rovio は、 Amazon SageMaker AI &nbsp;に独自アートスタイルを学習させました。 Amazon Bedrock で全社員が使える AI ツールを構築し、背景制作時間を 80% 削減、アーティストが反復作業から解放され、クリエイティブな業務に集中できる環境を手に入れました。 メディアサプライチェーンでは、Netflix が Amazon S3 Storage Lens と Apache Iceberg を組み合わせることで、2 エクサバイト超のデータを対象にストレージ増加の早期検知とコストの完全可視化を実現し、消されず残されたままとなったアセットや設定ミスによる不要データの特定が可能になりました。ブンデスリーガは Amazon Nova を活用することで、試合終了後数分以内のレポート自動配信と動画の多言語ローカライズを実現し、制作時間を 75〜90% 削減しながらパーソナライズドコンテンツを 5 倍に増加させることができました。 Direct-to-Consumer では、Amazon Prime Video が Amazon Managed Service for Apache Flink でリアルタイムストリーム処理基盤を構築し、NASCAR 中継において燃料戦略を 5 秒以内に可視化する業界初のシステムを 8 週間で立ち上げました。5 億 3,400 万インプレッションという大規模なメディア露出を獲得しています。またマルチエージェントシステムと Amazon Bedrock を組み合わせることで、アートワーク品質評価を数日から 1 時間未満に短縮し、1,800 万人同時視聴のライブ配信でもリアルタイムの品質監視も可能にしています。Olympics.com は Amazon OpenSearch Service と RAG を活用することで 160 億エンゲージメントの処理と 100〜200 ミリ秒でのコンテンツ自動生成を実現し、マイナー競技のロングテールコンテンツを自動配信できる体制を構築しました。 スポーツでは、NBA が Amazon EKS と Apache Flink でリアルタイム処理基盤を構築することで、14 年分のテラバイト級追跡データを統合し 50 ミリ秒の遅延で統計配信を実現しました。これにより従来定量化が困難だった選手の注目度を数値化した「プレイヤーグラビティ」と呼ばれる新指標が生まれ、すでに放送で活用されています。 マルチエージェントによる制作自動化、未活用コンテンツの価値最大化、低遅延リアルタイム体験の 3 つが re:Invent 2025 のメディア＆エンターテインメント業界におけるトレンドでした。 Inter BEE 2025 re:Cap アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 金目 健二 Inter BEE 2025 の Global AI x Cloud Pavilion AWS ブースでは、Create、Connect、Captivate の 3 テーマで展示を行いました。Create では、 Amazon DCV や Amazon EC2 G6e インスタンス、 Amazon FSx for NetApp ONTAP を組み合わせたクラウドスタジオ環境や、ComfyUI、Griptape Nodes を使った生成 AI 制作ワークフローを実演しました。クラウド上に制作環境を構築することで、物理的なワークステーションに縛られず、必要な時に必要なリソースを確保して制作を進められることが可能となります。Connect では、 MediaLake による自然言語によるコンテンツ検索が可能になることで、クリエイターが必要な素材を探す時間を大幅に削減し、編集作業そのものに集中できる環境を紹介しました。また Amazon Bedrock や Amazon Nova を活用した記事制作支援ツールにより、文字起こしから多言語翻訳、SNS 動画生成までを一貫して行うことが可能となり、記事公開までの時間短縮と言語展開のコスト削減が可能となることを示しました。Captivate では、 Amazon Transcribe と Amazon Bedrock による 4 言語同時字幕翻訳や多言語ライブグラフィックスの生成により、自社コンテンツの IP を海外展開しマネタイズの幅を広げられることを紹介しました。GitHub リポジトリで公開されており、すぐにご利用いただくことが可能です。 出展者セミナーには 3 社にご登壇いただきました。株式会社毎日放送には、スポーツ中継で過去のシーンを即座に探し出して再生するクラウドリプレイシステムを紹介いただきました。従来、3 時間超の試合映像から手動でシーンを探す作業にはベテランの経験と膨大な時間が必要でしたが、AWS マネージドサービスと生成 AI を活用することで、クラウドに保存された映像から必要なシーンをわずか 10 秒で送出準備できる仕組みを内製開発しました。株式会社 TBS テレビは、生放送やイベント配信が一方通行になりがちで視聴者の参加感が不足するという課題を解決するために、 Amazon Interactive Video Service (Amazon IVS) と Amazon Nova を活用した双方向型配信プラットフォーム「 Kustamie 」を開発しました。0.3 秒の超低遅延配信と最大 12 視点のマルチアングル配信に加え、不適切な発言を 1.6 秒で検知するチャットモデレーションにより、安心安全でインタラクティブなライブ配信環境を実現しています。株式会社 IMAGICA GROUP のエンターテインメントメディアサービスは、制作需要の波に対応するリソース確保や設備資産に縛られない運用を目指し、Amazon DCV や Amazon FSx、 AWS Deadline Cloud でポストプロダクションの編集環境をクラウドに移行しました。編集開始までのリードタイムを大幅に削減可能で、オンプレミスとの単純なコスト比較ではなく、機器投資や保守運用、バックアップなどの隠れたコストも含めて総合的に判断することが重要であるとの考え方も共有されました。 DX x IP Pavilion では、AWS 上に集約型マスターを構築することで、番組編成に従ったインフラの自動オーケストレーションと AI による集約監視を実現し、従量課金を活かして信号送出がないタイミングでのコスト削減が可能となることや、監視業務の効率化を両立できることを、国内の放送機器ソリューションを組み合わせて示しました。 おわりに 本ブログでは、メディア＆エンターテインメント業界のお客様向けに開催された re:Invent 2025 &amp; Inter BEE 2025 振り返りセミナーの内容を紹介しました。セミナーにご参加いただいた皆さま、ご参加いただきましてありがとうございました。メディアチームでは、業界の皆様に役立つ情報を、引き続きセミナーやブログで発信してまいります。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 先日、 AI 駆動開発ライフサイクル（AI-DLC） の社内研修を受けて、生成 AI をフル活用することで開発のスピードと品質の両立ができる可能性を実感しました。AI-DLC に関するお客様事例ブログを下記で紹介していますので、ぜひご一読ください。 3 月 25 日（水）には「 AWS での Claude Code の買い方・使い方 」という Claude Code をAWS 上で活用する手段や買い方をご紹介するイベントが開催されます。また3 月 26 日（木）には「 Amazon Quick で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。ご興味がある方はぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、3 月 2 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「第 6 回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～【開催報告】」を公開 2026 年 2 月 17 日に開催された第 6 回 生成 AI Frontier Meetup の開催レポートです。PwC Japan との生成 AI 実態調査に基づくディスカッションや、みずほフィナンシャルグループ様、ライオン様、電通デジタル様、日本経済新聞社様、Sky様、アクト・ノード様など多様な企業によるライトニングトーク、基盤モデル開発者の紹介、経済産業省 GENIAC の最新動向が共有されました。 ブログ記事「三菱電機のエンジニア 33 名が 3 日間で体感した AI 駆動開発の可能性 — AI-DLC Unicorn Gym 座談会」を公開 三菱電機 電力システム製作所 電力 ICT センター様で 33 名のエンジニアが参加した 3 日間の AI-DLC Unicorn Gym の座談会レポートです。5 チームがそれぞれ実際の業務課題を持ち寄り、AI 駆動開発ライフサイクルを実践。参加者の 90% 以上が「働き方を変える可能性が高い」と回答し、体感で 30〜40 倍の生産性向上を実感した様子が語られています。 ブログ記事「株式会社タイミー様の AI-DLC Unicorn Gym 開催レポート: 全社横断で挑む開発生産性の変革」を公開 株式会社タイミー様と AWS が共同で実施した AI-DLC Unicorn Gym のレポートです。11 チーム約 69 名がエンジニア・PdM・デザイナー・QA など職種横断で参加し、3 日間で全チームが MVP を構築。一部チームは翌週にプロダクションリリースを達成しました。Inception（企画・構想）フェーズでのモブワークの効果や、既存コードベースへの適用における課題と学びが共有されています。 ブログ記事「AST を活用した Kiro の高精度なコード編集」を公開 Kiro に導入された AST（抽象構文木）ベースのコードナビゲーション・編集エンジンについて解説しています。従来のテキストベースのファイル読み込みや文字列マッチングに代わり、コードを構造的に理解して操作することで、ベンチマークにおいてトークン使用量を 20% 削減し、実行時間を約 49% 短縮するなどの成果を紹介しています。 ブログ記事「[資料公開 &amp; 開催報告] Amazon Q Developer &amp; Kiro Meetup #5 を開催しました」を公開 2025 年 12 月 15 日に開催された Amazon Q Developer &amp; Kiro Meetup #5 の開催レポートです。AWS re:Invent 2025 前後の Kiro のアップデート紹介に加え、ゼンリンデータコム様による組織展開の工夫、NTT ドコモ様の活用事例、リクルート様による AI-DLC の現場導入についての登壇内容がまとめられています。登壇資料もダウンロード可能です。 ブログ記事「バグ修正のパラドックス：AI エージェントが正常なコードを壊してしまう理由」を公開 AI エージェントにバグ修正を依頼すると、関係のないコードまで変更してしまう「過剰解決」の問題に対して、Kiro が採用する「プロパティ指向コード進化」という方法論を解説しています。バグ条件と事後条件を明示的に定義し、修正プロパティと保持プロパティのテストで修正の正しさと既存動作の維持を保証するアプローチを、二分探索木 (BST) 削除バグや RocketMQ のメモリリークなどの具体例で紹介しています。 ブログ記事「自律型プライベート AI エージェントを実行するための OpenClaw が Amazon Lightsail に導入されました」を公開 Amazon Lightsail で OpenClaw インスタンスを簡単に起動できるようになりました。OpenClaw はオープンソースのセルフホスト型 AI エージェントで、Amazon Bedrock がデフォルトの AI モデルプロバイダーとして事前設定されています。ブラウザとのペアリングや WhatsApp・Telegram 等のメッセージングアプリとの連携手順、セキュリティに関する考慮事項が紹介されています。 サービスアップデート Amazon Lightsail が OpenClaw (プライベートなセルフホスト型 AI アシスタント) を提供開始 上記ブログでも触れたように Amazon Lightsail で OpenClaw をワンクリックデプロイできるようになりました。サンドボックス分離、自動HTTPS、デバイス認証、自動バックアップといったセキュリティ機能が最初から組み込まれており、デフォルトの LLM プロバイダーとして Amazon Bedrock が統合されています。Slack・Telegram・WhatsApp・Discord への接続やモデルの切り替えも可能で、東京を含む15リージョンで利用できます。詳細は クイックスタートドキュメントページ をご覧ください。 新しい Kiro Power で Lambda durable functions 開発を加速 AWS が Lambda durable functions の Kiro power を発表しました。これにより、Kiro IDE や Kiro CLI 上の開発環境で、長時間実行される複雑なワークフローを簡単に構築しやすくなります。注文処理や支払い調整など複数ステップが必要な処理を、AI エージェントのサポートを受けながら効率的に開発可能です。詳細は こちらの developer guide をご参照ください。 AWS HealthLake が自動 CCDA-to-FHIR データ変換のためのデータ変換エージェントを発表 (プレビュー) AWS HealthLake に新機能「data transformation agent」(プレビュー版) が登場しました。この AI 機能により、医療機関の従来の CCDA 形式文書を FHIR R4 形式に自動変換できます。従来は数ヶ月かかっていた作業が数日で完了し、専門知識も不要です。自然言語で「エラー状態の薬剤情報をスキップ」などの指示を出せば AI が自動でテンプレートを調整します。患者の縦断的記録作成や集団健康分析など、医療データ活用の可能性が大きく広がります。 Amazon Connect Health の紹介、ヘルスケア向けに構築されたエージェント AI Amazon Connect Health が一般提供開始となりました。医療機関向けに特化した AI エージェントサービスで、患者対応や診療業務を効率化できます。患者確認エージェントは Electronic Health Records (EHR) 記録とリアルタイムで照合して本人確認を行い、予約管理エージェントは自然言語での音声対話により24時間365日の予約受付を提供します。診察前には患者インサイトエージェントが関連する患者履歴と臨床コンテキストを自動表示し、診察中はアンビエント文書化エージェントが会話から臨床ノートをリアルタイム生成、診察後は医療コーディングエージェントがICD-10・CPTコードを監査証跡付きで自動生成します。現在バージニア北部とオレゴンリージョンで利用できます。 AWS Elastic Beanstalk が AI を活用した環境分析機能を提供開始 AWS Elastic Beanstalk で AI 搭載の環境分析機能が利用可能になりました。従来は環境に問題が発生した際、ログやイベントを手動で確認して原因を特定する必要がありましたが、今回のアップデートにより Amazon Bedrock を活用した自動分析が可能となります。環境の状態が Warning や Degraded の場合、コンソールの AI Analysis ボタンから分析を実行でき、具体的なトラブルシューティング手順が提示されます。開発者や運用チームの作業効率向上と、平均解決時間の大幅短縮が期待できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore Policy が一般提供開始 Amazon Bedrock AgentCore で Policy 機能の一般提供が開始されました。これまでエージェントのツールアクセス制御にはコード変更が必要でしたが、今回の機能により、セキュリティチームや運用チームがエージェントコードを変更することなく、一元的にアクセス制御ルールを設定できるようになりました。自然言語でポリシーを記述すると自動的に Cedar 言語に変換され、AgentCore Gateway がリクエストを監視・制御します。組織のガバナンス強化やコンプライアンス対応に活用でき、東京リージョンを含む 13 リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker Unified Studio が Kiro IDE からのリモート接続サポートを開始 Amazon SageMaker Unified Studio で Kiro IDE からのリモート接続サポートが開始されました。これまでローカル IDE とクラウドインフラの間で作業環境を切り替える必要がありましたが、今回のアップデートにより Kiro の AI 機能を使いながら SageMaker のスケーラブルな計算リソースに直接アクセスできるようになります。データサイエンティストや ML エンジニアは使い慣れた開発環境を維持しつつ、クラウドの強力なリソースを活用した効率的な開発が可能です。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が Restricted Instance Groups に包括的な可観測性を提供開始 Amazon SageMaker HyperPod で Restricted Instance Groups (RIG) の包括的な監視機能が提供開始されました。これまで手動で行っていた GPU 使用率や CPU 負荷などのメトリクス収集が自動化され、Amazon Managed Grafana ダッシュボードで一元管理できます。基盤モデル訓練時のパフォーマンス監視や障害診断が大幅に効率化され、訓練ログやエラーも自動収集されるため運用負荷が軽減されます。詳細は こちらのドキュメント をご参照ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 新しいワークショップ Accelerating Smart Product SDLC with AI Agent Workshop Lab4 をリリースしました。このワークショップは、Kiro を SDLC (ソフトウェア開発ライフサイクル) 全体に活用し、HVAC (空調) 制御システムを題材に Kiro を用いた組込ソフトウェアやライフサイクルの長いソフトウェア開発への適用を実証します。新しい生成 AI の開発プロセスを学びたい方にお勧めです。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年3月2日週の主要なアップデート 3/2(月) AWS Config が 30 の新しいリソースタイプをサポート AWS Config が 30 種類の新しいリソースタイプをサポートしました。Amazon Bedrock AgentCore や Amazon Cognito などの主要サービスが対象で、これまで監視できなかったリソースも含まれています。すでに全リソースタイプの記録を有効にしている場合は、自動的に新しいリソースも追跡されるため、追加設定は不要です。Config ルールや Config アグリゲータでも利用でき、より包括的なクラウド環境の監視と管理が実現できます。 AWS Batch でスケールダウン遅延の設定が可能になりました AWS Batch でスケールダウンの遅延時間を設定できるようになりました。従来はジョブ完了後すぐにインスタンスが終了していましたが、新しい minScaleDownDelayMinutes パラメータで 20 分から 1 週間まで稼働継続時間を指定可能です。今回のアップデートで、しばしば発生していたバッチ処理を行う際に、インスタンス起動待ちを削減でき、処理時間の短縮につなげられます。詳細は こちらの API ガイドをご参照ください。 3/3(火) Amazon SageMaker Unified Studio が Kiro IDE からのリモート接続サポートを開始 Amazon SageMaker Unified Studio で Kiro IDE からのリモート接続サポートが開始されました。これまでローカル IDE とクラウドインフラの間で作業環境を切り替える必要がありましたが、今回のアップデートにより Kiro の AI 機能を使いながら SageMaker のスケーラブルな計算リソースに直接アクセスできるようになります。データサイエンティストや ML エンジニアは使い慣れた開発環境を維持しつつ、クラウドの強力なリソースを活用した効率的な開発が可能です。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker Unified Studio が AWS Glue 5.1 をサポートし、データ処理ジョブが可能に Amazon SageMaker Unified Studio が、Visual ETL、ノートブック、およびコードベースのデータ処理ジョブにおいて AWS Glue 5.1 をサポートするようになりました。Apache Spark 3.5.6 や Python 3.11 などの最新バージョンが使えるようになり、Apache Iceberg や Delta Lake といったオープンテーブルフォーマットライブラリも更新されています。データエンジニアやデータサイエンティストは、Visual ETL やノートブックジョブで最新の機能を活用でき、データ処理パフォーマンスの向上が期待できます。詳細は こちらのドキュメントをご参照ください。 3/4(水) Amazon OpenSearch Ingestion が OpenTelemetry データ用の統合取り込みエンドポイントをサポート Amazon OpenSearch Ingestion で OpenTelemetry の統合エンドポイントがサポートされました。従来はログ、メトリクス、トレースの 3 種類のデータを処理するために 3 つの別々のパイプラインが必要でしたが、今回のアップデートで 1 つのパイプラインで全てを処理できるようになりました。また、段階的に OpenTelemetry を導入する際も、パイプラインの再設定なしで新しいシグナルタイプを追加できるため、導入の柔軟性が向上します。詳細は こちらのドキュメントをご参照ください。 Amazon OpenSearch Ingestion が Amazon Managed Service for Prometheus をシンクとしてサポート開始 Amazon OpenSearch Ingestion が Amazon Managed Service for Prometheus をシンク (データの書き込み先) としてサポートし、マネージド型のメトリクス取り込みパイプライン構築が簡単になりました。従来必要だったパイプラインの構築作業を削減でき、ログ、トレース、メトリクスを同一パイプラインで統一管理できます。ログは OpenSearch Service に、メトリクスは Prometheus に送信し、各サービスの強みを活かした observability 環境を構築できます。詳細は こちらのドキュメントをご参照ください。 Amazon Lightsail が OpenClaw (プライベートなセルフホスト型 AI アシスタント) を提供開始 Amazon Lightsail で OpenClaw をワンクリックデプロイできるようになりました。サンドボックス分離、自動HTTPS、デバイス認証、自動バックアップといったセキュリティ機能が最初から組み込まれており、デフォルトの LLM プロバイダーとして Amazon Bedrock が統合されています。Slack・Telegram・WhatsApp・Discord への接続やモデルの切り替えも可能で、東京を含む15リージョンで利用できます。詳細は クイックスタートドキュメント ページをご覧ください。 AWS がサービスワークフロー内での IAM ロール作成とセットアップを簡素化 AWS IAM で、各種サービスのワークフロー内で直接 IAM ロールを作成・設定できるようになりました。従来は IAM コンソールに移動してロールを作成する必要がありましたが、EC2 や Lambda などのサービス画面内で権限設定まで完結できるため、作業効率が大幅に向上します。現在バージニア北部リージョンで提供開始され、他のリージョンにも順次展開予定です。 3/5(木) 新しい Kiro パワーで Lambda 永続関数開発を加速 AWS が Lambda durable functions の Kiro power を発表しました。これにより、Kiro IDE や Kiro CLI 上の開発環境で、長時間実行される複雑なワークフローを簡単に構築しやすくなります。注文処理や支払い調整など複数ステップが必要な処理を、AI エージェントのサポートを受けながら効率的に開発可能です。詳細は こちらの developer guide をご参照ください。 Amazon Connect Health の紹介、ヘルスケア向けに構築されたエージェント AI mazon Connect Health が一般提供開始されました。医療機関向けの AI エージェントサービスで、患者確認、予約管理、診察前の患者インサイト表示、診察中のアンビエント文書化、診察後の ICD-10・CPT コード自動生成など、診療業務全体を効率化します。自然言語での音声対話による 24 時間 365 日の予約受付や、EHR 記録とのリアルタイム照合による本人確認にも対応しています。現在バージニア北部とオレゴンリージョンで利用可能です。 Database Savings Plans が Amazon OpenSearch Service と Amazon Neptune Analytics をサポート開始 Database Savings Plans が新たに、 Amazon OpenSearch Service と Amazon Neptune Analytics に対応しました。これまでは RDS などの一部データベースサービスのみが対象でしたが、今回の拡張により検索エンジンサービスやグラフデータベース分析にも適用可能になります。1 年間のコミットメント (前払いなし) で最大 35 % のコスト削減が実現でき、インスタンスタイプを変更してもプランが自動適用される柔軟性もあります。詳細は こちらの pricing page をご参照ください。 3/6(金) Amazon Redshift が COPY オペレーション用の再利用可能なテンプレートを導入 Amazon Redshift で COPY コマンドのテンプレート機能が提供開始されました。COPY コマンドは、S3 などの外部データソースからRedshiftのテーブルに大量のデータを一括ロード（取り込み）するためのコマンドです。これまで COPY 操作のたびに手動でパラメータを指定する必要がありましたが、頻繁に使用するパラメータを事前にテンプレートとして保存し再利用できるようになります。ファイル形式やデータソースごとに標準設定を作成でき、チーム間での一貫性確保やヒューマンエラー削減、運用効率向上につながります。詳細は こちらの Blog 記事をご参照ください。 Amazon Redshift が半構造化データ処理のための新しい配列関数を導入 Amazon Redshift で、JSON などの半構造化データを格納できる SUPER データを操作するための 9 つの新しい配列関数をサポートするようになりました。新しい関数を利用することで、ARRAY_CONTAINS や ARRAY_SORT など、配列の検索・比較・並び替え・変換を SQL クエリーで実現できます。従来は複雑な PartiQL ロジックが必要だった操作が、単一の SQL 文で簡単に処理できるようになり、よりシンプルに利用できるようになりました。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

2026 年 02 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS re:invent 2025 recap 広告・マーケティングテクノロジー編 #.1 生成 AI と ML で進化する広告・マーケティング 2026 年の広告・マーケティングテクノロジーの重要なトピックスである AI、データ、新たな基盤における進化について、re:invent の内容を元に３つのセッションに分けてご紹介します。 本セッションでは広告・マーケティングテクノロジー編セッション #1 として、生成 AI と ML で進化する広告・マーケティング、関連する事例セッションについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 広告・マーケティングの業務・業界に従事されている全ての職種の方 AWS のクラウド /AI の新サービス/ソリューション、並びにそれらを活用した最新事例に興味のある方 本 BlackBelt で学習できること 広告・マーケティング業界の市場環境と業界が直面する課題について AI による解決策とアプローチ、re:invent 2025 で発表された関連 AWS サービスの詳細について スピーカー 鈴木 康士郎 ソリューションアーキテクト AWS re:invent 2025 recap 広告・マーケティングテクノロジー編 #.2 Customer 360 で実現する次世代マーケティング 2026 年の広告・マーケティングテクノロジーの重要なトピックスである AI、データ、新たな基盤における進化について、re:invent 2025 の内容を元に3つのセッションに分けてご紹介します。 本セッションでは広告・マーケティングテクノロジー編セッション #2 として、Customer 360 で実現する次世代マーケティング、関連する事例セッションについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 広告、マーケティングの業務、業界に従事されている全ての職種の方 AWS のクラウド /AI の新サービス/ソリューション、並びにそれらを活用した最新事例に興味のある方 本 BlackBelt で学習できること AI エージェント時代におけるマーケティング業務、顧客体験の変革について Customer 360 の実現事例と関連する AWS サービスの詳細について スピーカー 鈴木 康士郎 ソリューションアーキテクト AWS re:invent 2025 recap 広告・マーケティングテクノロジー編 #.3 次世代アドテック基盤 – AWS RTB Fabric とは – 2026 年の広告・マーケティングテクノロジーの重要なトピックスである AI、データ、新たな基盤における進化について、re:invent 2025 の内容を元に3つのセッションに分けてご紹介します。 本セッションでは広告・マーケティングテクノロジー編セッション #3 と題して、プログラマティック広告における次世代アドテック基盤として re:Invent 2025 で発表された AWS RTB Fabric について、従来の課題やサービスの仕組みを深掘りしてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 広告、マーケティングの業務、業界に従事されている全ての職種の方 AWS のクラウド /AI の新サービス/ソリューション、並びにそれらを活用した最新事例に興味のある方 本 BlackBelt で学習できること プログラマティック広告の仕組みと従来の課題について AWS RTB Fabric のサービス詳細とアーキテクチャについて スピーカー 鈴木 康士郎 ソリューションアーキテクト Apache Iceberg on AWS – 概要編 オープンテーブルフォーマットの 1 つである Apache Iceberg と AWS 上での Apache Iceberg の利活用について概要レベルでご紹介しています。 資料（ PDF ） | 動画（ YouTube ） 対象者 データレイクの設計、構築、運用を担当している⽅ これからデータレイクを構築することを検討されている⽅ Apache Iceberg に関⼼がある⽅ 本 BlackBelt で学習できること Apache Iceberg の特徴を大まかに知った上で、AWS 上で Iceberg を活用するにあたってどのようなサービスが利用できるか、Iceberg の PoC の始め方について学習できます。 スピーカー 高橋 佑里子 ソリューションアーキテクト AWS IoT Greengrass コンポーネント開発編 AWS IoT Greengrass は、インテリジェント IoT デバイスをより速く構築するためのサービスと、IoT デバイス向けのエッジランタイムです。本セミナーでは、AWS IoT Greengrass コンポーネント開発編として、AWS IoT Greengrass のコンポーネント開発方法についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 IoT 製品やサービスの担当者 これから AWS IoT を用いた製品やサービスの開発を検討されている方 AWS IoT Greengrass をご利用中、ご利用予定の方 AWS IoT Greengrass コンポーネントの開発・運用を担当中、担当予定の方 本 BlackBelt で学習できること AWS IoT Greengrass コンポーネント開発の流れ AWS IoT Greengrass コンポーネントの開発方法（ビルド、テスト、パブリッシュ、デプロイ） AWS IoT Greengrass コンポーネントのモニタリング AWS IoT Greengrass コンポーネントの開発ツール スピーカー 宇佐美 雅紀 ソリューションアーキテクト Amazon Bedrock Evaluations Amazon Bedrock Evaluations は、LLM や RAG の評価をマネージドに提供するサービスです。この AWS Black Belt Online Seminar では、LLM や RAG を評価する必要性や Amazon Bedrock Evaluations の各機能についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Bedrock Evaluations の概要を把握されたい⽅ これから LLM の導⼊を検討している⽅ 既に使⽤している LLM と新しく公開された LLM を⽐較されたい⽅ RAG の改善点特定のために RAG の性能評価を検討されている⽅ 本 BlackBelt で学習できること LLM や RAG 評価の必要性 Amazon Bedrock Evaluations の各機能の概要 適切な Amazon Bedrock Evaluations の機能の選び方 スピーカー 今泉 唯俊, 松岡 貴司 クラウドサポートエンジニア Amazon S3 Tables Amazon S3 Tables は Apache Iceberg テーブル形式のデータを格納するための専用ストレージです。本セッションでは、Iceberg について解説を行った後、Amazon S3 Tables の「ストレージ」としての機能を紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon S3 Tables に興味がある方、Apache Iceberg について最低限の知識を知った上で、Amazon S3 Tables がどのような特徴を持つストレージサービスか知りたい方、を対象としています。 本 BlackBelt で学習できること Apache Iceberg の基本的な内容をおさらいしながら、従来の Amazon S3 での活用方法を紹介します。その上で、Amazon S3 Tables の「ストレージ」としての機能、嬉しいポイントを説明します。 スピーカー 佐藤 真也 ソリューションアーキテクト re:Invent &amp; Inter BEE 2025 re:Cap メディア&amp;エンターテインメント業界編 AWS re:Invent 2025 にて登壇いただいたメディア&amp;エンターテインメント業界のお客様事例と Inter BEE 2025 において AWS やお客様が行った取り組みについて分かりやすくご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 メディア・エンターテインメント業界でのクラウド・ AI 活用に興味のある方 映像制作・配信業務の効率化や自動化を検討されている方 本 BlackBelt で学習できること re:Invent 2025 で発表されたメディア業界向けの最新事例とトレンド Inter BEE 2025 での AWS の展示内容と業界内での実践的なクラウド活用方法 スピーカー 小南 英司 / 金目 健二 ソリューションアーキテクト re:Invent 2025 re:Cap 製造業界編 Part1 2025 年 12 月に開催された学習型カンファレンス AWS re:Invent 2025 に関して、その展示の内容や 2000 以上に及ぶセッションの中から、製造業に関わる内容をまとめて解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 グローバルの製造業においてクラウドならびに AI を使った最新事例やユースケースに関心がある方。製造業ならびに製造業に関連する業務に従事している方。 本 BlackBelt で学習できること 本セミナーは二部構成になっており、今回の Part1 は、全体の概要と、生産、すなわちスマート製造およびサプライチェーンについての内容を扱います。 スピーカー 小川 貴士 インダストリースペシャリストソリューションアーキテクト re:Invent 2025 re:Cap 製造業界編 Part2 2025 年 12 月に開催された学習型カンファレンス AWS re:Invent 2025 に関して、その展示の内容や 2000 以上に及ぶセッションの中から、製造業に関わる内容をまとめて解説します。(全二部構成の Part2 です) 資料（ PDF ） | 動画（ YouTube ） 対象者 グローバルの製造業においてクラウドならびに AI を使った最新事例やユースケースに関心がある方。製造業ならびに製造業に関連する業務に従事している方。 本 BlackBelt で学習できること 本セミナーは二部構成になっており、今回の Part2 では、R&amp;D, 設計に係る内容、製品・サービスに関わる内容を扱います。 スピーカー 小川 貴士 インダストリースペシャリストソリューションアーキテクト

本記事は 2025 年 12 月 16 日 に公開された「 Reference guide for building a self-service analytics solution with Amazon SageMaker 」を翻訳したものです。 今日の組織は、データレイク、データウェアハウス、SaaS アプリケーション、レガシーシステムなど、複数のサイロに分散したデータという重大な課題に直面しています。データの分断により、顧客の全体像の把握、業務の最適化、リアルタイムなデータドリブンの意思決定が困難になっています。競争力を維持するため、企業はセルフサービス分析に注目しています。ビジネスユーザーと技術ユーザーの両方が、IT チームに依存せずにデータへすばやくアクセスし、探索・分析できる環境です。 しかし、セルフサービス分析の実装には大きな課題が伴います。多様なソースからのデータ統合によるシームレスなアクセスの実現、データの発見性を高めるビジネスカタログと技術カタログの作成、信頼性を確保するためのデータリネージと品質管理、セキュリティとコンプライアンスのためのきめ細かなアクセス制御、データエンジニア・アナリスト・AI/ML チーム向けのロール別ツールの提供、そしてポリシーや規制要件を適用するガバナンスフレームワークの確立が必要です。 本記事では、 Amazon SageMaker Catalog を使用して、 Amazon S3 、 Amazon Redshift 、Snowflake など複数のソースからデータを公開する方法を紹介します。Amazon SageMaker Catalog により、データガバナンスとメタデータ管理を確保しながらセルフサービスアクセスを実現できます。メタデータを一元管理することで、データの発見性、リネージ追跡、コンプライアンスが向上し、アナリスト、データエンジニア、データサイエンティストが AI ドリブンのインサイトを効率的かつ安全に導き出せるようになります。サンプルの小売ユースケースを使ってソリューションをデモし、実際のシナリオへの適用方法をわかりやすく説明します。 Amazon SageMaker: セルフサービス分析の実現 Amazon SageMaker は AWS の AI/ML と分析機能を統合し、統一されたデータアクセスによる分析と AI の統合エクスペリエンスを提供します。チームは以下が可能です。 Lakehouse アーキテクチャを通じて、Amazon S3、Amazon Redshift、その他のサードパーティソースに保存されたデータを検索・アクセスする。 データ分析、処理、モデルトレーニング、生成 AI アプリ開発など、使い慣れた AWS サービスで AI と分析のワークフローを完結させる。 高度な生成 AI アシスタント Amazon Q Developer でソフトウェア開発を加速する。 Amazon SageMaker Catalog による組み込みのガバナンス、きめ細かなアクセス制御、安全なアーティファクト共有でエンタープライズグレードのセキュリティを確保する。 共有プロジェクトでコラボレーションし、コンプライアンスとガバナンスを維持しながらチームが効率的に連携する。 小売ユースケースの概要 以下の例では、小売組織が複数の事業部門にまたがって運営されており、各部門が異なるプラットフォームにデータを保存しているため、データアクセス、一貫性、ガバナンスに課題が生じています。 図 1: 複数システム間のデータフローを示す小売ユースケースの全体アーキテクチャ 小売組織は事業部門間でデータの分断に直面しています。 卸売 事業部門は Amazon S3 にデータを保存しています。 店舗販売 事業部門は Amazon Redshift でトランザクションデータを管理しています。 オンライン販売データ は Snowflake に保存されています。 データソースが分散しているため、データサイロ、スキーマの不整合、重複、欠損値が発生し、アナリストや AI ソリューションが有意義なインサイトを導き出しにくくなっています。 データモデル 以下の ER (Entity-Relationship) 図は、卸売、小売、オンライン販売データにおけるデータセット構造とエンティティ間の関係を表しています。 図 2: データエンティティ間の関係を示す ER 図 データモデルの主要エンティティ サンプルデータセットは、商品、販売チャネル、顧客、拠点を表すエンティティが相互に接続されたマルチチャネル小売ビジネスをモデル化しています。 PRODUCTS は WHOLESALE_SALES、RETAIL_SALES、ONLINE_SALES にリンクする中心的なエンティティで、異なる販売チャネルにおける商品取引を表します。 WHOLESALE_SALES は、WAREHOUSES が小売業者に商品を配送する大量取引を記録します。各販売は PRODUCT と WAREHOUSE に関連付けられています。 RETAIL_SALES は実店舗 (STORES) での個別購入を記録します。各取引には PRODUCT と STORE が関連付けられ、販売数量、適用割引、売上などの詳細が含まれます。 ONLINE_SALES は顧客がオンラインで商品を購入する EC 取引を追跡します。各レコードは CUSTOMER と PRODUCT にリンクし、数量、価格、配送情報などの詳細が含まれます。 CUSTOMERS はシステム内の購入者を表し、ONLINE_SALES (購入) と CUSTOMER_REVIEWS (商品レビュー) にリンクしています。 CUSTOMER_REVIEWS は、顧客がオンラインで購入した商品に対するフィードバックを保存します。各レビューは ONLINE_SALES の注文、CUSTOMER、PRODUCT にリンクしています。 STORES は商品が販売される実店舗を表します。RETAIL_SALES に関連付けられ、店舗での商品購入を示します。 WAREHOUSES は商品の在庫管理と WHOLESALE_SALES 取引を通じた小売業者への大量販売を担当します。在庫レベルを管理し、小売業者への一括販売を促進します。 システム間のデータ分散 実際のエンタープライズシナリオをシミュレートするため、データは以下のように複数のシステムと AWS アカウントに分散されています。 アカウント 保存場所 テーブル 卸売 Amazon S3 WHOLESALE_SALES, PRODUCT, WAREHOUSE 店舗 Amazon Redshift RETAIL_SALES, STORE, PRODUCT オンライン販売 Snowflake ONLINE_SALES, CUSTOMER, CUSTOMER_REVIEWS, PRODUCT 前提条件 この実装では以下を前提としています。 3 つの AWS アカウント : 卸売アカウント、店舗アカウント、集中処理アカウント。 オンライン販売用の Snowflake アカウント 。 データモデルセクションで指定した通り、この サンプルスクリプト を使用して各アカウントに分散データを作成。 クロスアカウントリソースのセットアップに必要な権限を持つ AWS Identity and Access Management (IAM) ロールを作成。 SageMaker Catalog の構築 Amazon SageMaker Unified Studio を使用して複数のソースから SageMaker Catalog を作成する手順を説明します。 ステップ 1: SageMaker Unified Studio 環境のセットアップ データカタログの構築を始める前に、SageMaker Unified Studio の用語を確認します。 ドメイン: Amazon SageMaker Unified Studio のドメインは、すべてのデータアセット、ユーザー、リソースを管理する論理的な境界で、データを効率的に整理・管理できます。 ドメインユニット: ドメインユニットはドメイン内のサブコンポーネントで、関連するプロジェクトとリソースをまとめて整理し、データ管理を階層的に構造化できます。 ブループリント: Amazon SageMaker Unified Studio のブループリントは、プロビジョニングされるリソース、適用されるツールやパラメータなど、プロジェクトの標準化された設定を定義するテンプレートです。 プロジェクトプロファイル: プロジェクトプロファイルは、プロジェクトの作成に使用されるブループリントの集合です。プロジェクトプロファイルでは、プロジェクト作成時に特定のブループリントを有効にするか、プロジェクトユーザーがオンデマンドで有効にできるようにするかを定義できます。 プロジェクト: Amazon SageMaker Unified Studio のプロジェクトは、ドメイン内の境界で、ユーザーがビジネスユースケースに取り組むために他のメンバーとコラボレーションできます。プロジェクト内でデータやリソースを作成・共有できます。 では、Amazon SageMaker Unified Studio 環境をセットアップしましょう。 SageMaker ドメインの作成 集中処理アカウントで Amazon SageMaker マネジメントコンソールを開き、上部のナビゲーションバーのリージョンセレクターで適切な AWS リージョンを選択します。 Create a Unified Studio domain を選択します。 Amazon SageMaker Unified Studio ドメインの作成 – クイックセットアップ の説明に従い、 Quick setup を選択します。 Create IAM Identity Center User で、メールアドレスから SSO ユーザーを検索します。Amazon IAM Identity Center インスタンスがない場合は、メールアドレスの後に名前を入力するプロンプトが表示されます。新しいローカル IAM Identity Center インスタンスが作成されます。 Create domain を選択します。 SageMaker Unified Studio へのログイン SageMaker Unified Studio ドメインを作成したら、以下の手順で Amazon SageMaker Unified Studio にアクセスします。 SageMaker プラットフォームコンソールで、ドメインの詳細ページを開きます。 Amazon SageMaker Unified Studio URL のリンクを選択します。 SSO 認証情報でログインします。 これで SageMaker Unified Studio にサインインできました。 プロジェクトの作成 次のステップはプロジェクトの作成です。以下の手順を実行します。 SageMaker Unified Studio で、上部メニューの Select a project を選択し、 Create project を選択します。 Project name に名前 (例: AnyCompanyDataPlatform) を入力します。 Project profile で All capabilities を選択します。 Continue を選択します。 入力内容を確認し、 Create project を選択します。作成したプロジェクトがデータ統合のコラボレーションワークスペースになります。 プロジェクトが作成されるまで待ちます。プロジェクトの作成には約 5 分かかります。完了すると、SageMaker Unified Studio コンソールがプロジェクトのホームページに遷移します。 ステップ 2: データソースへの接続 次に、さまざまなデータソースに接続してデータカタログに取り込みます。 既存の AWS Glue Data Catalog のインポート (卸売販売データ) まず、卸売アカウントの Amazon S3 にある卸売販売データを Amazon SageMaker Unified Studio にインポートします。 クロスアカウントアクセスの設定 集中処理アカウントにログインし、 AWSGlueServiceRole と卸売アカウントへのクロスアカウント S3 アクセスポリシーを持つ Glue Crawler ロール (glue-cross-s3-access) を作成します。クロスアカウント S3 アクセスポリシーの例: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::&lt;wholesale-account-bucket&gt;/*" ] } ]} 卸売アカウントにログインし、集中処理アカウントで作成した glue-cross-s3-access ロールに S3 データファイルへのアクセスを許可する S3 バケットポリシーを作成します。 集中処理アカウントにログインし、 AWS Glue から anycompanydatacatlog という名前のデータベースを作成します。 AWS Lake Formation で anycompanydatacatalog データベースに対する glue-cross-s3-access ロールの権限を付与します。 glue-cross-s3-access ロールを使用して Glue Crawler を実行し、卸売アカウントの S3 バケットをスキャンします。詳細は、 Glue Crawler を使用した S3 データのカタログ化 のチュートリアルを参照してください。 anycompanydatacatlog データベースと対応するテーブルを確認します。 Glue Data Catalog アセットの設定 Bring Your Own Glue Data Catalog Assets リポジトリからスクリプトをダウンロードします。 プロジェクト概要セクションから Amazon SageMaker Unified Studio プロジェクトロール ARN をコピーします。 同じ Amazon SageMaker Unified Studio プロジェクトロールを Lake Formation のデータレイク管理者として追加します。 Amazon SageMaker Unified Studio へのアセットのインポート 集中処理アカウントのコンソールで AWS CloudShell を開きます。 先ほどダウンロードした bring_your_own_gdc_assets.py ファイルを AWS CloudShell にアップロードします。 以下のパラメータを指定して AWS CloudShell でインポートスクリプトを実行します。 project-role-arn : SageMaker Unified Studio のプロジェクトロール ARN を入力します。 database-name : Glue Catalog のデータベース名 (例: anycompanydatacatalog ) を入力します。 region : SageMaker Unified Studio のリージョン (例: us-east-1 ) を入力します。 python3 bring_your_own_gdc_assets.py \ --project-role-arn &lt;Project role ARN&gt; \ --database-name &lt;Glue Database name to import&gt; \ --region &lt;region-code&gt; インポートした卸売販売データの確認 集中処理アカウントで SageMaker Unified Studio コンソールに移動し、プロジェクトを選択します。 ナビゲーションペインで Data を選択します。 anycompanydatacatalog の下に wholesale_db データベースとそのテーブル (WHOLESALE_SALES, PRODUCT, WAREHOUSE) が表示されていることを確認します。 Amazon Redshift への接続 (店舗販売データ) 店舗アカウントの Amazon Redshift にある店舗販売データを Amazon SageMaker Unified Studio に取り込みます。 クロスアカウントアクセスの設定 店舗アカウントにログインし、Amazon SageMaker Unified Studio をホストする集中処理アカウントとの間に VPC ピアリング接続 を作成し、 ドキュメント に従ってルートテーブルを設定します。 Redshift VPC セキュリティグループのルールを更新し、集中処理アカウントの IPv4 CIDR 範囲を含めます。ネットワーク接続が有効になり、集中処理アカウントから店舗アカウントのリソースへのリクエストが許可されます。 Amazon Redshift のフェデレーテッド接続の作成 集中処理アカウントで SageMaker Unified Studio コンソールに移動し、プロジェクトを選択します。 ナビゲーションペインで Data を選択します。 データエクスプローラーでプラス記号を選択してデータソースを追加します。 データソースの追加で Add connection を選択し、 Amazon Redshift を選択します。 接続の詳細に以下のパラメータを入力し、 Add data を選択します。 Name : 接続名 (例: anycompanyredshift ) を入力します。 Host : Amazon Redshift クラスターのエンドポイントを入力します。 Port : ポート番号を入力します (Amazon Redshift のデフォルトポートは 5439)。 Database : データベース名を入力します。 Authentication : データベースのユーザー名とパスワード、または AWS Secrets Manager を選択します。AWS Secrets Manager の使用を推奨します。 接続が確立されると、以下のスクリーンショットのようにフェデレーテッドカタログが作成されます。フェデレーテッドカタログは Amazon Redshift への AWS Glue 接続を使用します。データベース、テーブル、ビューは自動的にカタログセクションにカタログ化され、Lake Formation に登録されます。 店舗販売データの確認 SageMaker Unified Studio の Catalog セクションにアクセスします。 小売販売の public データベースとそのテーブル (RETAIL_SALES, STORE, PRODUCT) が表示されていることを確認します。 Snowflake への接続 (オンライン販売データ) Snowflake のオンライン販売データを Amazon SageMaker Unified Studio に取り込みます。 Snowflake のフェデレーテッド接続の作成 集中処理アカウントで SageMaker Unified Studio コンソールに移動し、プロジェクトを選択します。 ナビゲーションペインで Data を選択します。 データエクスプローラーで プラス記号 (+) を選択してデータソースを追加します。 Add a data source で Add connection を選択し、 Snowflake を選択します。 接続の詳細に以下のパラメータを入力し、 Add data を選択します。 Name : 接続名 (例: anycompanysnowflake ) を入力します。 Host : Snowflake クラスターのエンドポイントを入力します。 Port : ポート番号を入力します (Snowflake のデフォルトポートは 443)。 Database : データベース名 (例: anycompanyonlinesales ) を入力します。 Warehouse: ウェアハウス名 (例: COMPUTE_WH) を入力します。 Authentication : データベースのユーザー名とパスワード、または Secrets Manager を選択します。 接続が確立されると、Snowflake 用のフェデレーテッドカタログが作成されます。フェデレーテッドカタログは Snowflake への AWS Glue 接続を使用します。データベース、テーブル、ビューは自動的に Data Catalog にカタログ化され、Lake Formation に登録されます。 オンライン販売データの確認 SageMaker Unified Studio の Catalog セクションに移動します。 オンライン販売の public データベースとそのテーブル (CUSTOMER_REVIEWS, CUSTOMER, ONLINE_SALES, PRODUCT) が表示されていることを確認します。 ステップ 3: データの統合分析 すべてのデータソースからのデータがカタログ化されたら、Amazon SageMaker Unified Studio から Amazon Athena クエリエンジンを使用して分析できます。 集中処理アカウントで SageMaker Unified Studio コンソールに移動し、プロジェクトを選択します。 Build セクションから Query Editor を選択します。 接続として Athena (Lakehouse) を選択します。 複数のデータソースカタログを結合するクエリを実行してデータを分析します。 例: 各商品の卸売、小売、オンライン販売の合計売上はいくらか？ SELECT p.product_id, p.product_name, COALESCE(SUM(ws.total_revenue), 0) AS wholesale_revenue, COALESCE(SUM(rs.revenue), 0) AS retail_revenue, COALESCE(SUM(os.sale_price * os.quantity_sold), 0) AS online_revenue, (COALESCE(SUM(ws.total_revenue), 0) + COALESCE(SUM(rs.revenue), 0) + COALESCE(SUM(os.sale_price * os.quantity_sold), 0)) AS total_revenueFROM awsdatacatalog.anycompanydatacatalog.anycompany_products pLEFT JOIN awsdatacatalog.anycompanydatacatalog.anycompany_wholessale_sales ws ON p.product_id = ws.product_idLEFT JOIN anycompanyredshift.public.retail_sales rs ON p.product_id = rs.product_idLEFT JOIN anycompanysnowflake.sales.online_sales os ON p.product_id = os.product_idGROUP BY p.product_id, p.product_nameORDER BY total_revenue DESC; 同様に、カタログ間でクエリを実行することで、さまざまな分析の観点から有益なビジネスインサイトを得られます。 ステップ 4: ビジネス用語集の作成 ビジネス用語集は、組織全体で用語を標準化し、データの発見性を高めます。ここでは、卸売データの PRODUCT に対するビジネス用語集を作成します。 ナビゲーションペインで Data を選択し、卸売データの PRODUCT テーブルの Publish to Catalog を選択します。 Assets を選択し、 products テーブルを選択します。 Metadata entities から「 Product 」という名前の用語集と「 Sales 」という名前の用語を作成します。 Generate Descriptions を選択して、AI でデータの概要を自動生成します。 Add Terms を選択します。 自動メタデータ生成で ACCEPT ALL を選択します。 sales 用語を選択し、 Add Terms を選択します。 Publish Asset を選択します。 Assets を選択し、 Published を選択します。検索可能でサブスクリプションリクエストが可能な公開アセットが表示されます。 同様の手順で、他のデータプロダクトのビジネス用語集も作成できます。 ステップ 5: アクセス制御の設定 適切なガバナンスを確保するため、きめ細かなアクセス制御を設定します。 各ユーザーに対して新しいシングルサインオン (SSO) ユーザーを作成します。 以下のロールと権限を作成し、SSO ユーザーに割り当てます。 ロール 説明 アクセスレベル Data Steward データカタログと用語集を管理 カタログと用語集へのフルアクセス ETL Developer データ統合パイプラインを開発 データソースと AWS Glue への読み取り/書き込みアクセス Data Analyst 販売データを分析 すべての販売データへの読み取り専用アクセス AI Engineer 予測モデルを構築 販売データへの読み取りアクセス、SageMaker 機能へのフルアクセス SageMaker Catalog のメリット Amazon SageMaker Unified Studio を使用してセルフサービスビジネスデータカタログを実装することで、小売組織は以下の主要なメリットを得られます。 統一されたデータアクセス : 単一のインターフェースから Amazon S3、Redshift、Snowflake のデータを検索・アクセスできます。 標準化されたメタデータ : ビジネス用語集により、組織全体で一貫した用語を使用できます。 ガバナンスとコンプライアンス : きめ細かなアクセス制御により、ユーザーは許可されたデータのみにアクセスできます。 コラボレーション : ETL 開発者、データアナリスト、AI エンジニアなど、異なるチームが共有環境でコラボレーションできます。 クリーンアップ 本記事で作成したリソースに関連する追加料金が発生しないよう、AWS アカウントから以下の項目を削除してください。 Amazon SageMaker ドメイン。 Amazon SageMaker ドメインに関連付けられた Amazon S3 バケット。 VPC ピアリング接続、セキュリティグループ、ルートテーブル、AWS Glue Data Catalog エントリ、関連する IAM ロールなどのクロスアカウントリソース。本記事で作成したテーブルとデータベース。 まとめ 本記事では、Amazon SageMaker Catalog が複数のデータソースにまたがるデータの公開、検索、分析に対して統一されたアプローチを提供する方法を紹介しました。小売シナリオを使用して、Amazon S3、Amazon Redshift、Snowflake からのデータを Amazon SageMaker Unified Studio にインポートし、複数のソースからのデータを結合・分析して有意義なビジネスインサイトを導き出す方法を示しました。 メタデータを一元管理しクロスソースのデータ統合を可能にすることで、組織全体でデータを容易に検索でき、データの移動や複製なしに複数のデータソースを結合して包括的な分析を実行できます。統一されたアプローチにより、すべてのデータソースにわたって一貫したポリシー、セキュリティ、コンプライアンスによる強力なガバナンスを維持しながら、チームのインサイト獲得までの時間を短縮するセルフサービス分析を実現できます。 Amazon SageMaker の詳細と開始方法については、 Amazon SageMaker ユーザーガイド を参照してください。 著者について Navnit Shukla Navnit は、AWS のスペシャリストソリューションアーキテクトで、データと AI を専門としています。お客様がデータから価値あるインサイトを発見できるよう支援することに情熱を持っています。その専門知識を活かし、ビジネスがデータドリブンな意思決定を行えるソリューションを構築しています。O’Reilly から出版された Data Wrangling on AWS と AI-Ready Data Blueprints の主著者です。 Ayan Majumder Ayan は、AWS のアナリティクススペシャリストソリューションアーキテクトです。堅牢でスケーラブル、かつ効率的なクラウドソリューションの設計を専門としています。仕事以外では、旅行、写真撮影、アウトドアアクティビティを楽しんでいます。 Karan Edikala Karan は、AWS のソリューションアーキテクトで、中小企業がクラウドテクノロジーで価値を引き出せるよう支援しています。生成 AI を専門とし、測定可能な ROI を実現する AI ソリューションの構築と AWS でのデータ戦略の最適化をお客様にガイドしています。仕事以外では、自家用機の操縦、ゴルフ、スキーを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

本記事は2025年11月20日に公開された AWS Cloud WAN Routing Policy: Fine-grained controls for your global network (Part 1) を翻訳したものです。 本日、AWS は AWS Cloud WAN Routing Policy のリリースを発表しました。この新機能により、グローバルネットワーク全体のトラフィックルーティングをより細かく制御できるようになります。 AWS Cloud WAN を使用して、高度なルーティング制御によるネットワークパフォーマンスの最適化や、より耐障害性の高いハイブリッドアーキテクチャの構築が可能です。本記事は2部構成の第1回です。 Part 1 では、主なユースケース、メリット、機能、基本的な設定ワークフローを含む新機能の概要を紹介します。 Part 2 では、大規模で複雑なネットワーク設計に Cloud WAN Routing Policy を適用するアーキテクチャシナリオを詳しく解説します。 Cloud WAN Routing Policy を使用すると、ルートフィルタリング、経路集約、パス操作などの手法を適用して、グローバルネットワークのルート管理を細かく調整できます。また、 Border Gateway Protocol（BGP） 属性を設定してトラフィックの動作を制御し、複雑なルーティング要件に大規模に対応できます。さらに、Cloud WAN ルーティングテーブルの可視性が向上し、複雑なルーティング環境やマルチパス環境での問題を迅速にトラブルシューティングできます。 Cloud WAN Routing Policy を実装する前に、 Amazon Virtual Private Cloud（Amazon VPC） 、 AWS Direct Connect 、 AWS Site-to-Site VPN 、AWS Cloud WAN などの主要な AWS ネットワークサービスと BGP の基礎を理解しておくことを推奨します。 ユースケースとメリット Cloud WAN Routing Policy で対応できる代表的なユースケースとネットワーキングの課題を紹介します。網羅的なリストではなく、この機能が大きな価値を発揮するシナリオを厳選しています。 きめ細かなルーティング制御 AWS Cloud WAN のエンドツーエンドのダイナミックルーティングのシンプルさは大きな利点ですが、グローバル環境全体でどのネットワークやリソースがルーティング可能かを細かく制御したい場面もあります。ルーティング動作を管理することで、以下が可能になります。 非最適または非対称な接続パターンの防止 不要な伝播ルートによるルートテーブルの過負荷の回避 意図しないルート伝播につながる設定ミスからの保護 ルーティング問題の影響範囲の最小化 競合しない CIDR 範囲のみを伝播することによる IP ルートの重複防止 Cloud WAN Routing Policy を使用すると、ルートをフィルタリングまたは選択的に伝播して特定の接続目標を達成し、ネットワークの安全性、効率性、最適化を維持できます。 トラフィックエンジニアリングとパス最適化 多くの組織は、耐障害性と高可用性を実現するために、AWS Cloud WAN とオンプレミスネットワーク間に複数の接続パスを構築しています。大規模な BGP ベースのダイナミック環境では、同じ宛先プレフィックスが複数のネットワークパスから学習されることがよくあります。Cloud WAN Routing Policy を使用すると、BGP 属性の操作によりネットワークトラフィックが通るパスを制御できます。帯域幅の可用性、過去の輻輳パターン、トランジットプロバイダーとの契約条件などの要素に基づいて BGP 設定を構成できます。これにより、パフォーマンス、信頼性、コスト効率の観点でパス選択を最適化し、ビジネスニーズに最も適したルートにトラフィックを誘導できます。 リージョン別インターネット送信制御 多くの組織は、特定の AWS リージョン の集中型検査 VPC が地理的エリア全体のアウトバウンドインターネットトラフィックを処理する、地域中心のインターネット送信アーキテクチャを採用しています。たとえば、アジアパシフィックの全リージョンからのインターネットトラフィックをシンガポールリージョンの集中型検査 VPC に誘導し、ヨーロッパのリージョンからのトラフィックはフランクフルトリージョンの検査 VPC にルーティングするといった構成です。Cloud WAN Routing Policy は、AWS Cloud WAN 上でこのような地域別インターネット送信パターンの設計を簡素化します。集中型のセキュリティおよびコンプライアンス制御を維持しながら、リージョン別のルーティング優先設定を適用できます。 まとめると、Cloud WAN Routing Policy は、複雑なグローバルネットワークを自信を持って運用するために必要な柔軟性と制御を提供します。高度なルート管理とトラフィック管理機能を組み合わせることで、スケーラブルで安全かつ高度に最適化されたネットワークアーキテクチャを AWS 上に構築できます。 機能の概要 Cloud WAN Routing Policy は以下の機能をサポートしています。 ルートフィルタリング — Cloud WAN アタッチメントのインバウンドおよびアウトバウンドのルート伝播からルートをフィルタリング（許可またはドロップ）できます。Cloud WAN コアネットワーク（CNE-to-CNE）ピアリングメッシュ上のセグメント間およびリージョン間で伝播されるルートもフィルタリングできます。 ルート集約 — Cloud WAN アタッチメントのアウトバウンドルートを、目的のサマリールートを指定して集約できます。 パス優先設定 — ローカルプリファレンス、AS_PATH、Multi-Exit Discriminator（MED）などの BGP 属性を変更して、Cloud WAN コアネットワークと外部ネットワーク間のインバウンドおよびアウトバウンドのトラフィックパスに影響を与えるパス優先設定を行えます。 BGP コミュニティ — BGP コミュニティがインバウンドとアウトバウンドのルート更新間で推移的に受け渡されるようになりました。カスタムインバウンド BGP コミュニティに基づくルートフィルタリングやパス優先設定のアクション、またはアウトバウンドルート更新への BGP コミュニティの付与も可能です。 仕組み Cloud WAN Routing Policy では、順序付けされたマッチ・アクションルールのセットで構成される1つ以上のルーティングポリシーを定義できます。これらのポリシーにより、AWS Cloud WAN 内および AWS Cloud WAN と外部ネットワーク間の動的ルート伝播を精密に制御できます。 AWS Cloud WAN ネットワーク内のさまざまなポイントにルーティングポリシーを関連付けて、ルートの交換と伝播の方法を制御できます。ポリシーは、Cloud WAN アタッチメント経由で伝播されるルート、セグメント間（セグメント共有）、またはリージョン間（CNE-to-CNE ピアリング）に適用できます。これにより、グローバルネットワーク全体で一貫したきめ細かなルーティング動作を実装できます。 各ポリシーは3つの主要コンポーネントで構成されます。 マッチ条件 — ルートプレフィックスまたは BGP 属性に基づく条件を定義します。 アクション — マッチが発生した場合の動作（ルートの許可、ドロップ、変更など）を決定します。 方向性 — ポリシーをインバウンドまたはアウトバウンドのルート伝播のどちらに適用するかを指定します。 図1：利用可能なマッチ条件とアクションの一覧 はじめに 前提条件： Cloud WAN Routing Policy 機能にはポリシーバージョン 2025.11 が必要です。この機能を使用するには、最新の Cloud WAN ポリシーバージョンに移動し、 Edit を選択して、 Network Configuration TAB → General Settings でバージョンを 2025.11 にアップグレードします。Routing Policy の設定を開始する前に、このポリシーバージョンのアップグレードが必要です。 図2：バージョン 2025.11 へのアップグレード バージョンのアップグレードが完了したら、Cloud WAN Routing Policy の設定に進みます。 Cloud WAN Routing Policy の設定は、以下の4つのステップで行います。 Cloud WAN ポリシードキュメントでルーティングポリシーを定義する。 アタッチメントルーティングポリシーを作成または更新して、ルーティングポリシーを特定のアタッチメントに関連付ける（セグメント間またはリージョン間にルーティングポリシーを適用する場合、このステップは不要）。 Cloud WAN コアネットワークポリシーを確認して適用する。 選択したアタッチメント、セグメント間、またはリージョン間にルーティングポリシーを関連付ける。 設定例のウォークスルー パート1では、2つの例を紹介します。最初の例では、VPC アタッチメントにインバウンドルートフィルターを適用します。このシナリオでは、セグメント内の既存ルートと重複するプライマリ VPC CIDR ブロック（ 10.0.0.0/16 ）が AWS Cloud WAN コアネットワークに伝播されるのを防ぎ、セカンダリ CIDR ブロック（ 10.1.0.0/16 ）のみを許可します。 2つ目の例では、2つの VPN から同一の CIDR ルートが学習される場合に、ローカルプリファレンスを調整する方法を示します。各 VPN は、2つのオンプレミスサイトから BGP を通じて同じプレフィックスをアドバタイズしています。 同様のワークフローで、ルート集約や他の BGP 属性の変更を、AWS Site-to-Site VPN、AWS Direct Connect、Connect アタッチメント、ピアリングアタッチメントなどの BGP 対応アタッチメントに適用できます。ルーティングポリシーは、セグメント間およびリージョン間の伝播ルートにも適用可能です。 例1：VPC アタッチメントのインバウンドルートフィルター 図3：VPC アタッチメントへのインバウンドルートフィルターの適用 ステップ1： ルーティングポリシーを作成します。 Network Manager コンソールを開き、 Global Networks に移動します。 Global Network を選択し、ルーティングポリシーを定義する Core Network の Policy Versions を選択します。 変更を適用する Policy version を選択し、 Edit をクリックします。 新しいタブ Routing policies が表示されるので、 Create routing policy をクリックします。 図4：Routing policies タブ 次のウィンドウで、番号、名前、説明（任意）、方向を設定します。 図5：ルーティングポリシーの作成 ルーティングポリシーを作成したら、プレフィックス 10.0.0.0/16 にマッチしてドロップするルーティングポリシールールを追加します。 図6：ルーティングポリシー設定の一部として新しいルールを定義 図7に示すように、以下のアクションオプションが利用可能です。 図7：Routing Policy でルールを追加する際のアクションオプション ルール番号、アクション、条件（必要に応じて複数追加可能）を設定します。条件として Prefix equals: 10.0.0.0/16 を指定します。 図8：プレフィックス 10.0.0.0/16 にマッチするルールの追加 Condition logic （AND または OR）は、ルーティングポリシールール内で複数の条件をどのように評価するかを決定します。指定したすべての条件が満たされた場合にのみルールを適用する場合は AND を選択します。いずれかの条件が満たされた場合にルールを適用する場合は OR を選択します。条件が1つだけの場合は、デフォルト値の OR のままで問題ありません。 ステップ2： ステップ1で作成したルーティングポリシーを特定のアタッチメントに関連付けるために、 Attachment routing policy rules を作成します。 このステップは、アタッチメントにルーティングポリシーを適用する場合にのみ必要です。セグメント間（セグメント共有）またはリージョン間（CNE-to-CNE）にルーティングポリシーを適用する場合は、別のステップが必要です。 新しく追加されたAttachment routing policy rules は、アタッチメントをセグメントに関連付ける既存の Attachment policies とは異なります。Attachment routing policy rules は、 Routing policy label を介してアタッチメントを1つ以上のルーティングポリシーに関連付けます。 図9：Attachment policies と Attachment routing policy rules の比較 Attachment routing policy rules には、ルーティングポリシーを最大256文字のシンプルなテキスト識別子である route policy label にマッピングするマッチ・アクションルールのセットが含まれます。 以下の例では、ルーティングポリシー FilterPrimaryCIDR をラベル PrimaryVpcCidr にマッピングする attachment routing policy rule を示しています。 図10：Attachment routing policy rule の作成 アタッチメントをルートポリシーに関連付ける際（ステップ4）にも、同じ route policy label PrimaryVpcCidr を使用する必要があります。ルールの作成が完了したら、 Create policy をクリックして新しい Cloud WAN ポリシーバージョンを生成します。 ステップ3： 新しいポリシーを確認して適用します。 ステップ1と2で行った変更により、新しいポリシーバージョンが作成されます。更新された設定を有効にするには、 View or apply changes set を選択します。 図11：実行準備が整った新しい Cloud WAN ポリシーバージョン ポリシーのデプロイが成功すると、ステータスが Execution succeeded に更新され、新しいルーティングポリシーが AWS Cloud WAN コアネットワークでアクティブになったことを示します。 ステップ4： Cloud WAN アタッチメント、セグメント間、またはリージョン間にルーティングポリシーを関連付けます。 この最後のステップでは、ステップ1で作成したルーティングポリシーを、ステップ2で定義したラベル PrimaryVpcCidr を使用して、選択した AWS Cloud WAN アタッチメントに関連付けます。ラベルを使用することで、個別に設定することなく、複数のアタッチメントに一貫したルーティング動作を適用できます。 新しい AWS Cloud WAN アタッチメントを作成する際に、対応する Routing policy label を選択してルーティングポリシーを関連付けることができます。 図12：アタッチメント作成時の routing policy label の選択 または、既存の Cloud WAN アタッチメントを編集して Routing policy label を関連付けることもできます。アタッチメントを再作成せずにルーティングポリシーを適用できます。 図13：既存アタッチメントの routing policy label の更新 routing policy label をアタッチメントに適用すると、ラベルが削除されるまで、AWS Cloud WAN は関連付けられたルーティングポリシーで定義されたルーティング動作を適用します。 例2：最適なパス選択のためのローカルプリファレンスの適用 2つ目の例では、2つの VPN 接続が BGP を通じてデフォルトルート 0.0.0.0/0 を AWS にアドバタイズしています。1つの VPN は ap-southeast-2 リージョンに接続され、もう1つは us-east-1 リージョンに接続されています。us-west-2 リージョンには CNE 上にローカル VPN 接続がないため、アクティブな VPN 接続を持つ2つのリモートリージョンを通じてデフォルトルートを学習します。 非決定的なルーティングを回避し、遠方のリージョンを経由する非最適なルーティングを防ぐために、us-west-2 の CNE がより近いリージョンである us-east-1 の VPN エンドポイントを優先するようにローカルプリファレンスを設定します。 図14：us-west-2 でのデフォルトルート（0.0.0.0/0）に対するローカルプリファレンスの調整 これは、ローカルプリファレンスを 300 に設定するルールを持つインバウンドルーティングポリシーを作成することで実現できます（ローカルプリファレンスの値が高いほど優先されます）。デフォルトのローカルプリファレンスは 0 です。ルールには、プレフィックス 0.0.0.0/0 にマッチする単一の条件を含めます。 図15：ローカルプリファレンスの調整 最後に、図15に示すルールを含むルーティングポリシーを、セグメント内の2つのエッジロケーション（2つの CNE）間のルート伝播に関連付けます。これは Segment actions → Edge location routing policy associations で設定できます。 図16：CNE-to-CNE Routing Policy 図16は、production セグメント内で us-east-1 から発信されるルートに対して、us-west-2 エッジロケーション（CNE）にルーティングポリシーを適用する方法を示しています。 これにより、us-west-2 の CNE は、ap-southeast-2 から受信した同じデフォルトルートと比較して、us-east-1 経由のデフォルトルート 0.0.0.0/0 をより高い優先度で扱うようになります。 ルート可視性の強化 今回のリリースでは、新しい Route information base タブも導入しています。このタブは、ルーティングポリシーが適用される前の、学習されたすべてのルートと関連する BGP 属性を、従来の Routing Information Base（RIB）ビューのように表示します。インバウンドまたはアウトバウンドポリシーによる属性の変更は Route information base には反映されません。ルーティングポリシーの評価後、AWS Cloud WAN は最適なルートを1つ選択し、パケット転送に使用される Forwarding Information Base（FIB）を表す Routes タブにインストールします。 図17は、us-west-2 CNE が学習したルートを表示する Route information base タブを示しています。この例では、デフォルトルート 0.0.0.0/0 が us-east-1 と ap-southeast-2 の両方のリージョンから学習されています。us-east-1 から学習したルートにローカルプリファレンス 300 を設定しましたが、この変更は RIB には反映されていません。Route information base は、ローカル CNE でルーティングポリシーが適用される前のルートを表示します。 図17：ルーティングポリシー適用前の RIB ビュー 一方、 Routes タブ（FIB）を確認すると、最適なルートがインストールされていることがわかります。より高いローカルプリファレンスが設定されている us-east-1 から学習したルートが選択されています。 図18：FIB ビュー – パケット転送に使用される Routes タブ 留意事項 Cloud WAN Routing Policy 機能は、AWS Site-to-Site VPN、AWS Direct Connect、Connect アタッチメント、ピアリングアタッチメント（Transit Gateway ルートテーブル）、VPC アタッチメントを含むすべての AWS Cloud WAN アタッチメントタイプ、およびセグメント間（セグメント共有）とリージョン間（CNE-to-CNE）のルートでサポートされています。ルート集約と BGP 属性の変更は、すべての BGP 対応アタッチメント（Site-to-Site VPN、Direct Connect、Connect、ピアリング）およびセグメント間・リージョン間のルートで利用可能です。VPC アタッチメントについては、VPC からコアネットワークへのインバウンドルート伝播に対するルートフィルタリング（「allow」または「drop」アクション）のみサポートしています。 BGP コミュニティのサポートは、Connect、VPN、ピアリングアタッチメントで利用可能です。本リリース時点では、Direct Connect アタッチメントでは利用できません。 ルート集約は、BGP 対応アタッチメントのアウトバウンドルートでのみサポートされています。 Routing Policy は、Network Function Groups（Service Insertion）へのルート伝播の制御をサポートしていません。 この機能の使用に追加料金はかかりません。 この新機能に関するクォータは AWS ドキュメント に追加される予定です。 まとめ 本ブログ（パート1）では、グローバルネットワーク全体のダイナミックルート伝播とトラフィックエンジニアリングをきめ細かく制御する新機能、Cloud WAN Routing Policy を紹介しました。機能の仕組みを説明し、AWS コンソールを使用した基本的なルーティングポリシーの設定手順をウォークスルーしました。 Cloud WAN Routing Policy を使用すると、AWS Cloud WAN のアタッチメント、セグメント、リージョン全体でカスタムルーティング動作を定義でき、複雑さを増すことなくネットワークの可視性、パフォーマンス、制御を強化できます。 本シリーズの パート2 では、マルチリージョンおよびハイブリッド環境で BGP 属性を使用したルートフィルタリング、集約、パス操作を適用するアーキテクチャシナリオを紹介し、AWS 上で高度にスケーラブルで耐障害性の高いネットワークを設計する方法を解説します。 開始するには、 AWS Cloud WAN ドキュメント を参照してください。 翻訳は Professional Services の森瀬 健太郎が担当しました。原文は こちら です。

現在、AI がメインフレームアプリケーションのモダナイゼーションを可能にすることについて、大きな期待が寄せられています。企業の取締役会は注目しています。CIO はプランを求められています。AI は COBOL のモダナイゼーションを加速する真のアクセラレーターです。しかし、確かな結果を得るには、ソースコードだけでは提供できない追加のコンテキストが必要です。400 社を超える企業顧客と一緒に仕事をした経験から私たちが学んだことは、メインフレームのモダナイゼーションには 2 つのまったく異なる側面があるということです。前半はリバースエンジニアリングで、既存のシステムが実際に何をするのかを理解します。後半は、新しいアプリケーションを構築するフォワードエンジニアリングです。 メインフレームプロジェクトが生き残るか死ぬかは前半で決まります。一方、コーディングアシスタントが本当に優れているのは後半だけです。明確で検証済みの仕様を提供すれば、モダンなアプリケーションを素早く構築できます。 COBOL のモダナイゼーションを成功させるには、決定論的にリバースエンジニアリングを行い、検証済みで追跡可能な仕様を生成し、それらの仕様をフォワードエンジニアリング用の AI 搭載コーディングアシスタントに流し込むことができるソリューションが必要である、ということを私たちは学びました。モダナイゼーションを成功させるには、リバースエンジニアリングとフォワードエンジニアリングの両方が必要です。 メインフレームのモダナイゼーションを成功させるために必要なこと 対象範囲内の全てを含む完全なコンテキスト メインフレームアプリケーションは大規模です。実に大きい。1 本のプログラムが何万行のこともあり、システム全体で共有しているデータ定義を取り込んだり、他のプログラムを呼び出したり、環境全体にわたる JCL を介してオーケストレーションされている場合があります。現在、AI が一度に処理できるコードの量は限られています。1 本のプログラムを生成 AI に入力しただけでは、そのプログラムから参照されるコピーブック、呼び出されるサブルーチン、共有ファイル、これら全てを結び付ける JCL があっても、関連するコード一式を生成 AI が見に行くことはできません。対象のコードに対して一見妥当に見える出力が生成されますが、不可視だった依存関係は見逃されます。お客様との共同作業では、まず暗黙の依存関係をすべて決定論的に抽出し、対象範囲内で必要なものすべてを特定済の完全なものとして AI に供給することで、この問題を解決します。そうすれば、AI は実際には見えていない関連性を推測で補おうとしなくても良くなり、得意なこと (ビジネスロジックの理解、仕様の生成) に集中できます。 各プラットフォームに固有のコンテキスト 同じ COBOL ソースコードでも、実行するコンパイラおよびランタイムによって動作が異なり、驚くことがあります。数値が四捨五入される仕組み、データがメモリー内にどのように配置されるか、プログラムがミドルウェアと通信する方法。これらはソースコードには書かれていません。これらは、コードをビルドする特定のコンパイラと、デプロイ先の特定のランタイム環境によって決まります。ハードウェアとソフトウェアの組み合わせで何十年にもわたって実行されてきた結果は、別のプラットフォームにコードを移動するだけで単純に再現できるものではありません。AI は、プラットフォーム固有の動作が既に解決済の場合に最も効果を発揮することがわかりました。クリーンで、プラットフォームを意識したインプットを AI に提供すれば、それが実現します。生のソースコードをそのまま生成 AI にインプットすると、一見正しく見えても、元のアウトプットと異なる結果が生成されることがあります。金融システムでは、四捨五入の差は見かけ上の問題ではありません。これは重大な誤差です。 トレーサビリティの基礎 銀行、保険、政府関係者の場合、規制当局からある質問を受けることになります。それは、何も見落としていないことを証明できるか、ということです。ビジネスロジックを抽出し、規制当局が受け入れ可能な文書を生成するには、AI だけでは不十分です。規制遵守のためには、すべてのアウトプットが元のシステムに正式かつ監査可能な形で結び付けられている必要があります。AI によるソースコードの読み取りだけからトレーサビリティが得られないことは、早い段階で学びました。正確で特定の単位にコードを構造化することで、AI に何が入るかを正確に把握し、すべての出力をそのソースまで追跡できるようになります。規制の厳しい業界のお客様にとって、これは多くの場合、プロジェクトが進むか行き詰まるかの分かれ目になります。 AI をどのように設定したことで AWS Transform が成功したか 私たちは、大規模なメインフレームアプリケーションをモダナイズするために AWS Transform を構築しました。アイデアは単純明快です。AI に適切な基盤を提供すれば、お客様はトレーサブルで正確かつ完全な結果を得て、本番環境に持ち込むことができます。AWS Transform は、まずアプリケーションの完全で決定論的なモデルを構築することから始めます。システム全体 (一度に 1 本のプログラムではなく、対象のコード一式) のコード構造、実行時の動作、データ間の関連を、専門的に特化したエージェントが抽出します。これにより、実際のコンパイラのセマンティクスに沿った依存関係グラフを構成し、AI が関与する前に、プログラム間の依存関係、ミドルウェアのやり取り、プラットフォーム固有の動作をキャプチャします。そこから、大規模なプログラム群は、処理可能な単位にグループ化されます。プラットフォーム固有の動作は決定論的に解決されます。AI が効果的に処理できるよう、各グループに上限サイズを設定できます。次に AI がビジネスロジックを自然言語で抽出し、既に抽出済の決定論的なエビデンスと、すべての出力を照らし合わせて検証します。スペック(仕様)は元のコードにマッピングされます。規制当局の「何か見落としはありましたか?」という問いに対して、検証可能な答えがあります。このように明解に言い切ることができるのは、AI の動作に透明性があるためです。AI によるすべての処理単位には、既知のインプットと期待されるアウトプットがあるため、何が戻されるか検証することができます。メインフレームモダナイゼーション市場において、生成 AI でこのようなクローズドループを実現するアプローチは、他にありません。出力されるのは、あらゆるモダンな開発環境に対応する、検証済みでトレーサブルな技術仕様一式です。モダナイゼーションで難しいのは、現在存在しているものを理解することです。それを正確な仕様で把握できれば、AI 搭載の IDE は自信を持って新しいアプリケーションを構築することができます。 エンタープライズトランスフォーメーションのための end-to-end のプラットフォーム 単一のアプリケーションだけをモダナイズする人はいません。AWS のお客様は、何百、何千もの相互に接続されたアプリケーションのポートフォリオに注目していますが、必要としているのは分析の支援だけで無く、それ以外にもあります。AWS Transform は、分析、テスト計画、リファクタリング、reimagine といったライフサイクル全体を自動化します。これら全て。そしてその中でも、アプリケーションが異なれば、モダナイゼーションで辿る経路も異なります。中にはゼロから reimagine されるものもあります。Java へのクリーンで決定論的な変換だけが必要なものもあります。中には、まずワークロードをデータセンターから出すことを優先して、その後でモダナイズする企業もあります。一部はメインフレームに残るものもあります。それらをすべて同じように扱うとプロジェクトが爆発するということを私たちは苦労の末に学びました。ポートフォリオの決定 (どのアプリケーション、どのパス、どの順序) は、テクノロジーと同じくらい重要です。私たちの経験では、これが企業のモダナイゼーションを実際に完了する唯一の方法です。単一のソリューションで全てを解決しようとするアプローチこそが、これらのプロジェクトが失敗する理由です。もう 1 つ見過ごされがちなのは、テストデータです。リアルな本番データとリアルなシナリオがなければ、モダナイズされたアプリケーションが機能することを証明することはできません。チームがコード変換を最後までやり遂げたのに、誰もデータキャプチャを計画していなかったため行き詰まるのを目撃したこともあります。そこで、私たちはテスト計画を作成し、オンプレミスデータのキャプチャと移行先プラットフォームへの取り込みを初日から構築し始めました。最後のクリーンアップ作業ではありません。実際にうまく行った時は、このような感じです。End-to-end の自動化、各アプリケーションに適したパス、検証を視野に入れた機能が組み込まれています。 うまく行う方法 問題は「COBOL のモダナイゼーションに AI を使うべきか」ということではありません。もちろんそうすべきです。規制当局のトレーサビリティや、プラットフォーム固有の動作の適切な処理、アプリケーションポートフォリオ全体の一貫性、数百の相互接続されたプログラムにまで適用を広げることなど、AI をどのように設定して実現するかということが問題なのです。それこそが、私たちが AWS Transform を構築するときに考え出したことです。基礎としての決定論的分析。アクセラレータとしての AI。あらゆるモダナイゼーションパターンをカバーする AWS サービス。 そして、これらの工夫が実際に機能しています。 BMW Group はテスト時間を 75% 短縮し、テスト対象範囲を 60% 拡大したことで、モダナイゼーションのスケジュールを加速させながらリスクを大幅に軽減しました。 Fiserv は、29 か月以上かかったメインフレームモダナイゼーションプロジェクトを、わずか 17 か月で完了しました。 Itau はメインフレームアプリケーションのディスカバリー時間とテスト時間を 90% 以上削減し、チームは以前の手作業よりも 75% 速くアプリケーションをモダナイズできるようになりました。 著者 Dr. Asa Kalavade Asa は AWS Transform をリードし、お客様のインフラストラクチャ、アプリケーション、コードの移行とモダナイゼーションを支援しています。以前は、AWS の go-to-market ツールへの生成 AI 機能を組み込みによるトランスフォーメーションをリードしていました。また、ハイブリッドストレージとデータ転送サービスのマネジメントも担当していました。2016 年に AWS に入社する前、Asa はベンチャーキャピタルによる支援のもと 2 つのスタートアップを設立し、現在もボストンのスタートアップのメンタリングに積極的に取り組んでいます。Asa は、カリフォルニア大学バークレー校で電気工学とコンピューターサイエンスの博士号を取得し、40 件以上の特許を取得しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

2026 年 3 月 4 日、 Amazon Lightsail で OpenClaw の一般提供開始が発表されました。これは、ブラウザをペアリングし、AI 機能を有効にして、オプションでメッセージングチャネルに接続できる OpenClaw インスタンスを起動するためのものです。Lightsail OpenClaw インスタンスには、 Amazon Bedrock がデフォルトの AI モデルプロバイダーとして事前設定されています。セットアップが完了すると、追加設定なしで即座に AI アシスタントとのチャットを開始できます。 オープンソースでセルフホスト型の自律的なプライベート AI エージェントである OpenClaw は、ユーザーのコンピューター上で直接動作することでパーソナルデジタルアシスタントとして機能します。OpenClaw の AI エージェントはブラウザ経由で実行でき、WhatsApp、Discord、Telegram といったメッセージングアプリに接続して、質問に答えるだけでなく、メールの管理、ウェブブラウジング、ファイルの整理などのタスクを処理します。 AWS のお客様からは、AWS で OpenClaw を実行できるかどうかに関する問い合わせをいただいており、中には Amazon EC2 インスタンスでの OpenClaw の実行に関するブログを書いた方もおられました。私は、自宅のデバイスに OpenClaw を直接インストールした経験を通じて、これが簡単に行えるものではなく、セキュリティに関する多くの考慮事項があることを学びました。 そこで、事前設定された OpenClaw インスタンスを Amazon Lightsail でより簡単に起動し、よりセキュアに実行する方法を皆さんにご紹介したいと思います。 Amazon Lightsail で OpenClaw を実際に使ってみましょう 手順を開始するには、 Amazon Lightsail コンソール に移動し、 [インスタンス] セクションで [インスタンスの作成] を選択します。希望する AWS リージョンとアベイラビリティーゾーン、インスタンスを実行する Linux/Unix プラットフォームを選択したら、 [設計図の選択] で OpenClaw を選択します。 インスタンスプランを選択し (最適なパフォーマンスを実現するには 4 GB のメモリプランが推奨されます)、インスタンスの名前を入力します。最後に [インスタンスの作成] を選択します。インスタンスは数分間で [実行中] 状態になります。 OpenClaw ダッシュボードを使用する前に、ブラウザの OpenClaw とのペアリングを行う必要があります。そうすることで、ブラウザセッションと OpenClaw 間にセキュアな接続が確立されます。ブラウザと OpenClaw をペアリングするには、 [Getting started] タブで [SSH を使用して接続] を選択します。 ブラウザベースの SSH ターミナルが開くと、ウェルカムメッセージにダッシュボード URL とセキュリティ認証情報が表示されています。それらをコピーしてから、新しいブラウザタブでダッシュボードを開きます。コピーしたアクセストークンは、OpenClaw ダッシュボードの [Gateway Token] フィールドに貼り付けることができます。 プロンプトが表示されたら、SSH ターミナルで [y] を押して続行し、 [a] を押してデバイスのペアリングを承認します。ペアリングが完了すると、OpenClaw ダッシュボードに OK ステータスが表示されます。これで、ブラウザが OpenClaw インスタンスに接続されました。 Lightsail 上の OpenClaw インスタンスは、Amazon Bedrock を使用して AI アシスタントを動作させるように設定されています。Bedrock API アクセスを有効にするには、 [Getting started] タブにあるスクリプトをコピーし、コピーしたスクリプトを AWS CloudShell ターミナルで実行します。 スクリプトが完了したら、OpenClaw ダッシュボードの [Chat] に移動して、AI アシスタントの使用を開始しましょう! 携帯電話やメッセージングクライアントから AI アシスタントと直接やり取りするには、OpenClaw を設定して Telegram や WhatsApp などのメッセージングアプリと連携させることができます。詳細については、Amazon Lightsail ユーザーガイドの「 Get started with OpenClaw on Lightsail 」を参照してください。 知っておくべきこと 以下は、この機能に関する重要な考慮事項です。 許可 – OpenClaw インスタンスに付与される AWS IAM 許可をカスタマイズできます。セットアップスクリプトは、Amazon Bedrock へのアクセス権を付与するポリシーが含まれた IAM ロールを作成します。このポリシーはいつでもカスタマイズできますが、許可を変更することで OpenClaw が AI 応答を生成できなくなる可能性があるため、変更時には注意が必要です。詳細については、AWS ドキュメントの 「 AWS IAM ポリシー 」を参照してください。 コスト – 選択したインスタンスプランの料金は、使用分に対する時間単位のオンデマンド料金のみをお支払いいただきます。OpenClaw アシスタントとの間で送受信されるすべてのメッセージは、トークンベースの料金モデルを使用して Amazon Bedrock 経由で処理されます。Anthropic Claude や Cohere など、 AWS Marketplace を通じて配布されているサードパーティモデルを選択する場合は、トークンあたりのコストに加えて追加のソフトウェア料金が適用される場合があります。 セキュリティ – OpenClaw のパーソナル AI エージェントの実行は強力な手段ですが、注意を怠った場合はセキュリティ脅威となる可能性があります。OpenClaw ゲートウェイがオープンインターネットにさらされないようにするためにも、ゲートウェイを非表示にすることが推奨されます。ゲートウェイ認証トークンはパスワードです。このため、頻繁にローテーションを行って環境ファイルに保存し、設定ファイルにハードコーディングしないようにしてください。セキュリティに関するヒントの詳細については、「 Security on OpenClaw Gateway 」を参照してください。 今すぐご利用いただけます Amazon Lightsail の OpenClaw は、 Amazon Lightsail が提供されている すべての AWS 商用リージョンで今すぐご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」をご覧ください。 Lightsail コンソール で OpenClaw をお試しいただき、フィードバックを AWS re:Post for Amazon Lightsail または通常の AWS サポート窓口にお寄せください。 – Channy 原文は こちら です。

このブログ記事では、移行途中の過渡期に於けるハイブリッドアーキテクチャの連携パターンと連携ソリューションを設計する方法を紹介します。 多くの一般的なメインフレーム環境には、データやコードを共有するアプリケーション間の複雑で密結合されたシステム間連携があります。メインフレームアプリケーションを AWS クラウドに移行するとき、大規模な移行には Strangler fig パターン を使用した段階的なアプローチが推奨されます。インクリメンタルなアプローチでは、過渡期 (移行) フェーズまたはトランスフォーメーション (モダナイゼーション) フェーズ中に、メインフレームと AWS クラウド間のハイブリッドアーキテクチャを構成する連携を実装することになります。 概要 メインフレームワークロードは通常、一連のビジネス機能を実行するプログラム、ミドルウェア、データストア、依存関係、およびリソースの集合体として定義されます。 AWS は、お客様のビジネス戦略および技術戦略の目標に応じて、メインフレームワークロードをモダナイズするための複数のパターンを提案しています。これらのオプションは大きく 2 つのグループに分類できます。 マイグレーション &amp; モダナイゼーション (図 1.1 — 左側) 拡張 &amp; 連携 (図 1.2 — 右側) 図 1. AWS Mainframe Modernization パターン ワークロードのマイグレーションまたはモダナイゼーションは、アプリケーションと移行の目的に応じた一連の戦略 (replatform, refactor, rewrite, repurchase) に従ってメインフレームからコンポーネントをオフロードし、AWS クラウドに移行することを目的としています。 ワークロード拡張の目的は、メインフレームのデータを活用して AWS 上に新しいビジネス機能を構築することにあります。 いずれのアプローチでも、メインフレームと AWS 環境との共存を促進する連携アーキテクチャが必要です。これには、移行の過渡期もしくは恒久的にメインフレームに残されるワークロードと、AWS クラウドに移行または作成されるワークロードとの間の相互作用を管理することが含まれます。 アプローチ 一般的に、大規模なメインフレームワークロードは同時並行的に実行され、互いに密結合しています。Strangler fig パターンでは、各ワークロードは個別に移行されます。ハイレベルで見ると、個々のワークロードが段階的に次々と移行されます。ビジネス価値、アプリケーションの複雑さ、連携ポイント、およびビジネスの重要性に基づいて、ワークロードの移行に優先順位を付けます。時間の経過とともに、メインフレームのワークロードは一つずつ切り離されていきます。 図 2. ワークロードに Strangler fig パターンを適用したメインフレームアプリケーションの移行 メインフレームワークロードの移行を開始しようとすると、メインフレームと密に連携されているワークロードは他にもあることがわかります。それらには、アプリケーション間連携、データ間連携、そしてアプリケーションからデータへの連携があります。図 3 では、一部のワークロードを AWS に移行し、他のワークロードがメインフレームに残るシナリオを示しました。 図 3 に示す連携は、以下の 3 種類です。 アプリケーション間の連携 アプリケーションからデータに対する連携 データ間の連携 図 3. 移行前後のシステムが併存するハイブリッドアーキテクチャが必要 各連携タイプは相互に排他的ではなく、むしろ互いに補完し合うことができます。連携タイプの選択は、主に、メインフレーム上のワークロード間の既存の連携設定に影響されます。たとえば、ワークロード 1 がアプリケーションコンポーネント (CICS、COBOL、MQ 呼び出しなど) を介してワークロード 2 とやり取りする場合は、アプリケーション間のパターンを確立する必要があります。逆に、ワークロード 1 がワークロード 2 のデータにアクセスする必要がある場合は、データからデータへ、またはアプリケーションからアプリケーションへのパターンのいずれかを実装する必要があります。これらのパターンおよび関連する技術的実装の中で、いずれを選択するかは、主に、スループット、パフォーマンス、データ本体の保管場所、という 3 つの重要な基準に基づいて決定されます。 連携パターン 以下のパターンは、併存シナリオにおけるアプリケーション連携と利用可能なソリューションを理解するのに役立ちます。これらの機能を実現する製品は市場に出回っていますが、ここではそのうちのいくつかについて説明します。 パターン 1 — アプリケーション間の連携パターン アプリケーション同士の連携は、アプリケーション間連携パターンと呼ばれ、2 つのソフトウェアアプリケーションまたはシステムを接続して連携させるプロセスを指します。アーキテクチャと連携にはいくつかのタイプがあり、それぞれ目的が異なり、さまざまなニーズに応えます。 アーキテクチャ的には、アプリケーション連携ための Hub-and-Spoke、Enterprise Service Bus (ESB)、API マネジメントなど、複数のパターンがあります。これらのアーキテクチャパターンには、メインフレームと他の環境との間の仲介役として機能する中央集権型の連携ハブやミドルウェアプラットフォームが含まれます。各アプリケーションをハブ、ESB、または API マネジメント層と連携するだけで、接続されたシステム間のデータルーティングと変換が管理されます。このアプローチにより、連携の管理と保守を簡素化できます。中央ハブ、ESB、または API マネジメント層とメインフレームの間は、図 4 に示す point-to-point の連携パターンで接続します。 図 4. アプリケーション間連携パターン AWS クラウドとメインフレーム間の最も一般的な連携タイプをいくつか紹介します。 JCA コネクタを使った point-to-point 連携 このタイプの連携では、2 つのアプリケーションを相互に直接接続してデータを交換します。Java Connector Architecture (JCA) コネクタを使用した point-to-point 連携は、Java EE アプリケーションと CICS、IMS/TM、Db2 ストアドプロシージャなどのメインフレームサブシステムとの直接接続を伴います。JCA コネクタとの point-to-point 連携には、Java アプリケーションとメインフレームを直接接続できるため、パフォーマンス、スケーラビリティ、トランザクション性のサポート、セキュリティなどが向上するメリットがあります。また、連携するシステム間が密結合になるため、メッセージングや API のように疎結合された連携アプローチに比較すると、柔軟性が低下し、保守し難くなる場合があります。 CICS、IMS、Db2 と統合するための 3 つの主な point-to-point 連携ソリューションを以下に示します。 CICS と連携するための CICS Transaction Gateway (CTG)。CTG は z/OS またはオープンシステムにデプロイできます。 IMS Connect を使用して IMS と連携できます。IMS Connect は z/OS にデプロイする必要があります。 Db2 z/OS ストアドプロシージャをトリガーするには、外部アプリケーションから直接 JDBC 接続を行います。 JCA コネクタを使用した point-to-point 連携のもう 1 つの注目すべき点は、その単方向性です。つまり、双方向通信をサポートする IMS Connect の場合を除き、連携は AWS クラウドからメインフレームに流れ、その逆は行われないということです。 API ベースの連携 RESTful API ベースの連携は、ソフトウェアシステムを連携するための柔軟で標準化されたアプローチを提供します。これにより、相互運用性、拡張性、および開発が容易になります。RESTful API は、Web 開発、モバイルアプリ、クラウドコンピューティング、Internet of Things (IoT) など、さまざまな分野で広く使用されています。RESTful API ベースの連携を使用するアプリケーションは、2 つの環境間でのトランザクションコンテキストの伝播が緩和されるように設計する必要があります ( SAGA などのパターンや補償メカニズムを使用するなど)。そうしないと、不整合が発生したり、同期の問題が発生したりする可能性があります。 IBM の z/OS Connect や OpenLegacy などのソリューションは、API 対応のメインフレームサブシステムで使用できます。z/OS Connect では、プログラム、データ、トランザクションなどのメインフレーム資産を RESTful API として公開できます。これにより、クラウド内のさまざまなモダンなアプリケーションやサービスからこれらの資産にアクセスして利用できるようになります。z/OS Connect の大きな利点の 1 つは、双方向の連携機能です。これにより、モダンなアプリケーションとメインフレームシステム間の双方向の通信が可能になります。つまり、モダンアプリケーションはメインフレームのサービスとデータを利用できるだけでなく、メインフレームのトランザクションとアプリケーションも AWS クラウドのアプリケーションとサービスを使用できるということです。 メッセージ指向型とイベント駆動型の連携 メッセージ指向型の連携では、アプリケーションはメッセージを介して非同期的に通信します。メッセージはキューに入れられ、システム間で確実に配信されます。メッセージ指向の連携とイベント駆動型の連携により、パブリッシュ/サブスクライブやリクエスト/レスポンスなど、さまざまなメッセージングパターンをサポートできます。IBM MQ は、メインフレームと AWS クラウド間の通信とデータ交換を容易にする主要なメッセージングミドルウェアの 1 つです。パブリッシュ/サブスクライブまたはリクエスト/レスポンスのパターンを活用することで、メインフレームとの連携に使うことができます。 もう 1 つの選択肢は、IBM MQ を通じて Kafka をメインフレームと連携することです。この方式は、適切なコネクターと Kafka Connect を使用した Kafka と MQ 間の通信を伴います。Kafka Connect はメインフレームでもクラウドでも実行できます。Kafka とメインフレームアプリケーション間でデータをストリーミングするコネクタを構築およびデプロイするためのフレームワークを提供することで、連携プロセスを簡素化します。Kafka を使うと、メインフレームと AWS クラウド間で追加の連携作業を行わなくても、より多くのコンシューマーが自分のドメインに関連するトピックを購読できるようになります。 パターン 2 — データ間の連携パターン あるワークロードが AWS クラウドに移行され、他のワークロードがまだメインフレームに残っている場合、メインフレームとの間でデータを送信する頻度に応じてさまざまな方法があります。データ転送のニーズと頻度に応じて構築するさまざまな連携パターンを図 5 に示します。 図 5. データ間連携パターン ニアリアルタイムのデータ転送 ニアリアルタイムのデータ転送は、あるプラットフォームから別のプラットフォームにニアリアルタイムで複製しデータを更新できるようにする処理です。本機能を実現するツールは Change Data Capture (CDC) を使用して、変更ログに基づいてニアリアルタイムでデータを移行します。データ転送のニーズは、単方向、単方向と逆向き単方向の組み合わせ、あるいは双方向である可能性があります。 単方向とは、メインフレームのデータソースから AWS データソースに、またはその逆にデータを複製する必要があることを意味します。単方向と逆向き単方向の組み合わせとは、データのレプリケーションを双方向で行う必要があるものの、異なるテーブルや無関係なテーブルに対して行う場合です。双方向とは、関連する複数のテーブルで両方向にレプリケーションを実行する必要があることを意味します。双方向レプリケーションは、関連テーブルの更新によるデータ競合という課題が増えるため、最終手段にすべきです。アプリケーションをメインフレームから AWS に移行すると、あるプラットフォームのアプリケーションからの更新を別のプラットフォームでもすぐに利用できるようになります。 AWS Mainframe Modernization サービスは、CDC テクノロジーと AWS Mainframe Modernization Data Replication powered by Precisely を使って、メインフレームと AWS 間のデータレプリケーション機能を提供します。これにより、Db2、IMS、VSAM などのメインフレームや IBM i (AS/400) のデータソースから、さまざまな AWS クラウドデータベースに向けて、またはその逆に、異種データをニアリアルタイムで複製できます。AWS のデータレプリケーションでは、低レイテンシー CDC テクノロジーが活用されています。このテクノロジーでは、ソースデータベースに加えた変更がニアリアルタイムでターゲットデータベースに伝達されると同時に、データの一貫性、正確性、鮮度、有効性も確保されます。この機能により、併存シナリオや、データ分析、新規チャネルの展開など、さまざまなユースケースが可能になります。 ファイルベースの転送 ほとんどの企業には、メインフレームからデータを移動するためのファイルベースの転送メカニズムがあります。NDM (Network Data Mover) や SFTP のような仕組みを使ってファイル転送をサポートできます。メインフレームとオープンシステム間のファイル転送における課題の 1 つは、データ形式の違いです。メインフレームの COMP、COMP-3、その他のバイナリフィールドがないファイルの場合、SFTP と NDM はそのままデータ転送を行うことができます (EBCDIC を ASCII ベースまたは選択した文字セットに変換)。バイナリフィールドを含むファイルには、特定の変換ソフトウェアが必要です。AWS Mainframe Modernization サービスでは、併存、拡張、移行のさまざまなユースケースをサポートするファイル転送機能を提供しています。 AWS Mainframe Modernization File Transfer を利用すると、フルマネージドサービスを使ってデータセットとファイルを転送および変換できるため、AWS Mainframe Modernization service サービスと Amazon S3 へのモダナイゼーション、移行、拡張のユースケースを加速および簡素化することができます。 Extract, Transfer, and Load (ETL) ベースの転送 ETL ベースの転送は、メインフレームから AWS にデータを移動するためのデータ連携および転送メカニズムです。メインフレームのソース (VSAM、Db2 など) から、変換プロセスの一環としてデータが抽出、整理、クレンジングされ、AWS にアップロードされます。すべての ETL 処理はソースとターゲットへの JDBC 接続を使用します。この方法は、 AWS Glue などの専用の ETL ツールや、IBM DataStage、Informatica、Precisely ETL Connect などの ISV 製品によってサポートされており、メインフレームのデータソースから AWS データソースに、またはその逆にデータを移行できます。 アーカイブされたデータの転送 仮想テープライブラリ (VTL) などのメインフレーム独自のストレージソリューションでは、貴重なデータが複雑なツールを備えたプラットフォームにロックインされます。これにより、メインフレームでこれらのデータ取得タスクにかかるコンピューティングコストとストレージコストが高くなる可能性があります。アーカイブされたデータの転送というパターンは、メインフレームのテープから Amazon S3 にデータを移動するのに役立ちます。 BMC AMI Cloud により、お客様はメインフレーム内のテープを Amazon S3 に移動することができます。 パターン 3 — アプリケーションからデータへの連携パターン このオプションは、プラットフォーム全体でデータ連携へのアプリケーションを実装することです (図 6)。アプリケーションからデータへの連携とは、AWS またはメインフレーム上で実行され、AWS またはメインフレームのいずれかでリモートでホストされているデータにアクセスするアプリケーションを意味します。 図 6. アプリケーションからデータへの連携パターン 一般に、リモートデータアクセスに伴うレイテンシーの影響を回避しつつローカルデータアクセスを可能にするには、データ間の連携を行うことをお勧めします。ただし、データが密結合されている場合、データ間連携パターンの実装は困難になります。このような場合は、アプリケーションからデータへの連携の方が適している場合があります。 アプリケーションからデータへの連携パターンには 2 つのバリエーションがあります。 一元管理するデータに対してアプリケーションから連携するパターン 二重書き込みによりアプリケーションからデータに連携するパターン データ一元管理パターン このパターンでは、データの信頼できる唯一の情報源が AWS またはメインフレームのいずれかに存在します。データに対して直接ローカルアクセスできないアプリケーションは、JDBC やゲートウェイなどの技術を使用してリモートアクセスを実行する必要があります。このパターンでは、1 つのデータコピーを維持することでデータ管理が簡単になりますが、リモートアプリケーションがデータにアクセスする際に待ち時間が発生し、アプリケーション全体のパフォーマンスに影響します。 AWS 上のアプリケーション、メインフレーム上のデータベース — このタイプの連携では、クラウド上のアプリケーションがメインフレームデータベースに直接接続します。Java Connector Architecture (JCA) コネクタとの point-to-point 連携には、クラウド上の Java アプリケーションがメインフレーム上のデータベースに直接接続することで、標準化されたインターフェイス、パフォーマンス、移植性、スケーラビリティ、トランザクション性とセキュリティのサポートなどのメリットがあります。JCA や JDBC で連携すると、システム間が密結合になるため、柔軟性が低下し、保守が難しくなります。JCA Connector または JDBC を使用した point-to-point 連携は、本質的に単方向です。つまり、クラウド上のアプリケーションからメインフレームデータベースに向かう方向にのみ連携します。 メインフレーム上のアプリケーション、AWS 上のデータベース、またはその逆 — メインフレーム上のアプリケーションを AWS 上のデータベースに直接連携したり、その逆を行ったりするさまざまなチャネルがあります。メインフレーム上のアプリケーションは Db2 フェデレーテッドサーバーを使用して AWS のデータベースにアクセスでき、その逆も可能です。これにより、あいまいさが減り、データのコピーを 1 つ保存するだけで済むため、運用の複雑さが軽減されます。 フェデレーションは、データベースを機能ごとに分割するスケーリング手法です。メインフレームデータのフェデレーションにより、異種データに対しても統一された方法でリアルタイムでアクセスできるようになります。これにより、設定のオーバーヘッドを最小限に抑えながら、AWS 上の分散アプリケーションやデータベースを利用したり、その逆を行ったりできます。フェデレーションサーバーでは、異なるデータストアのデータを結合するという点で、ある程度複雑になり、クエリのパフォーマンスとアプリケーションのスケーラビリティに影響する可能性があります。 仮想化は、形式や保存場所に関する技術的な詳細を知らなくても、アプリケーションがデータにアクセスして変更できるようにするデータ管理手法の 1 つです。IBM Data Virtualization Manager for z/OS (IBMz DVM) は、データをコピーまたは移動することなく、複数のソースからのデータを単一形式で表示できます。このため、AWS 上の分散アプリケーションやデータベースは、メインフレーム上のさまざまなデータストア (IMS、IDMS、または Db2) やファイルシステム (順次ファイル、VSAM、VSAM CICS、ADABAS、または MQ) にアクセスできます。仮想化によってデータ実装がアプリケーション開発者から見えなくなり、メインフレーム資産が API として AWS アプリケーションやデータベース上の分散チャネルに安全に公開されます。また、データ仮想化は、データフェデレーションとは対照的に、データベース結合と基本的なデータ処理を使用する単純なデータ処理に限定されます。 二重書き込みパターン このパターンでは、データのコピーが 2 つあり、1 つは AWS に、もう 1 つはメインフレームにあります。レプリケーションメカニズムを使用する代わりに、アプリケーションは両方の場所に対して二重の書き込み (挿入/更新) を行います。このパターンでは、読み取り操作はローカルで行われ、書き込み操作はローカルとリモートの両方で実行されるため、レイテンシーへの影響が軽減されます。書き込み頻度が低く、読み取りが頻繁なアプリケーションに適しています。この方式の主な欠点は、データの整合性と一貫性を確保するために単一トランザクション内で二重書き込みを実行するため、アプリケーションレベルで複雑になることです。このパターンでは、ニアリアルタイムで同期できるデータ間連携とは異なり、両方の場所でリアルタイムにデータをコピーできます。 AWS 上のアプリケーションと AWS とメインフレーム上のデータベース — このタイプの連携では、AWS とメインフレームの両方にデータの同期コピーが保持されます。AWS 上のアプリケーションは、AWS データベースとメインフレームデータベースに同時に直接接続されます。この連携は JCA (Java Connector Architecture) コネクタを使用して実現されます。このコネクタでは、AWS 上の Java EE アプリケーション、AWS 上のデータベース、およびメインフレームデータベースを JDBC 経由で直接接続します。二重書き込みを選択すると、アーキテクチャにデータの耐障害性が向上しますが、アプリケーションのパフォーマンス上の問題が発生する可能性があります。この連携パターンの特徴と特性は、AWS 上のアプリケーションとメインフレーム上のデータベースのデータパターンのシングルコピーと似ています。 メインフレーム上のアプリケーションと、メインフレームと AWS 上のデータベース — メインフレーム上のアプリケーションをメインフレームデータベースや AWS 上のデータベースに直接統合するさまざまなチャネルは、データの同期コピーを AWS だけでなくメインフレームにも保存するという唯一の違いを除いて、データ一元管理パターンと似ています。 結論 大規模なメインフレームアプリケーションを AWS に移行する際に、大規模な移行に伴うリスクを最小限に抑えるために、Strangler fig パターンを使って段階的に移行する顧客もいます。このアプローチには、メインフレームと AWS クラウド間の相互運用性が必要です。本ブログでは、この相互運用性を促進するさまざまな連携パターンを整理してまとめました。単一のソリューションですべての連携シナリオに対応できるような万能のソリューションはありません。各パターンにはそれぞれ長所と短所があります。これらの連携パターンを選択する際には、慎重に検討する必要があります。決定の主な要因には、スループット、パフォーマンス、トランザクションコンテキストの伝達、整合性、プライマリデータの場所などがあります。 移行を始める際には、AWS のメインフレームモダナイゼーションのスペシャリスト (mainframe@amazon.com) に連絡することをお勧めします。 著者 Yann Kindelberger Yann Kindelberger は、アマゾンウェブサービスの Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 Chiranjeev Mukherjee Chiranjeev は AWS のメインフレームモダナイゼーション担当 Sr. Specialist Solution Architect です。Chiranjeev は、メインフレームで約 20 年間働いており、主に世界中のお客様を対象としたメインフレームのモダナイゼーションイニシアチブにフォーカスしてきました。現在の役職では、メインフレームとレガシーシステムに AWS の価値提案を最大限に活用する方法について、お客様やパートナーに助言しています。 Saikat Chatterjee Saikat Chatterjee は、Specialist Solutions Architect であり、AWS Mainframe Modernization のワールドワイドチームのメンバーです。Saikat は、世界中のお客様を対象としたエンタープライズモダナイゼーションの取り組みに積極的に関わってきました。現在の役職では、AWS での分散型アーキテクチャの構築、エンタープライズ連携ソリューションの構築に注力しながら、メインフレームをモダナイズするさまざまなパターンに深く注力しています。彼は、メインフレームと関連するレガシーシステムの移行とモダナイゼーションに AWS の価値提案を最大限に活用する方法について、お客様に助言しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。