本ブログは 2026 年 5 月 19 日に公開された AWS Blog、” CIRT insights: How to help prevent unauthorized account removals from AWS Organizations ” を翻訳したものです。 AWS Customer Incident Response Team (CIRT) は、お客様がアクティブなセキュリティインシデントから復旧するためのご支援を行っています。この活動の中で、特定の お客様の構成や設計 を悪用する、新しいまたは流行している攻撃手口を発見することがしばしばあります。 これらの手口を理解することは、アーキテクチャ上の意思決定への反映、対応計画の改善、そして実際にこのような状況が発生した場合の検出に役立ちます。 本投稿では、攻撃者がお客様アカウントの制御を奪取した後に取る新しいアプローチを取り上げます。具体的には、お客様の AWS Organizations 実装から該当アカウントを離脱させ、その構造が提供するポリシーや保護を回避する手口です。 本記事で説明する手口は、AWS サービスの脆弱性を利用するものではありません。代わりに、特定の構成や設計によって生じた予期しない機会を悪用し、AWS アカウント内のリソースを不正に使用するものです。 何が起きているのか このアプローチは、攻撃者が organizations:LeaveOrganization 権限の付与を持つクレデンシャルを使用するところから始まります。この権限は LeaveOrganization API コール へのアクセスを提供し、メンバーアカウントから呼び出されると、そのアカウントを Organization から離脱させようとします。 重要な点として、このアプローチでは侵害されたルートクレデンシャルが使われる場合もありますが、攻撃者は他の手段でアクセス権を昇格させ、必要な権限を取得したり、その権限を持つロールを引き受ける能力を獲得したり、現在のクレデンシャルにこの権限を付与する能力を獲得したりすることもできます。これが、認可に対して 最小権限のアプローチ を取ることが、お客様の環境を保護する上で極めて重要である理由です。詳細については、 AWS Identity and Access Management (IAM) ドキュメント と、 組織単位 (OU) 設計および サービスコントロールポリシー (SCP) 実装に関する AWS Organizations のガイダンスをご覧ください。 お客様の環境への影響 アカウントが Organization から離脱させられると、その Organization の一部として継承されていた制限 (破壊的なアクションを防止していた SCP、利用可能な AWS リージョンを制限していたもの、特定の API コールをブロックしていたもの等) が適用されなくなります。また、当該アカウントは一括請求 (Consolidated Billing) の対象外となるため、Organization の請求アラートやコスト異常検知も該当アカウントの活動をカバーしなくなります。 AWS CloudTrail の組織トレイルは離脱したアカウントからのイベント取得を停止し、委任管理者を介して管理されていた Amazon GuardDuty の検出結果も中央のセキュリティアカウントへ流れなくなります。 その結果しばしば発生するのは、Organization が当該アカウントへの可視性を失う一方で、そのアカウント内には引き続き Organization のリソースが残るという状況です。関連する Threat Technique Catalog のエントリを以下に示します。 T1078.A002: Account Root User : 侵害されたルートクレデンシャルを利用した初期アクセス T1078.004: Cloud Accounts : 侵害された IAM クレデンシャルを利用した初期アクセス T1098: Account Manipulation : 制御を維持するための権限昇格とアカウント設定の変更 T1666.A002: Leave AWS Organization : SCP やガバナンスコントロールを回避するため、メンバーアカウントを Organization から離脱させる T1562.008: Disable Cloud Logs : Organization からの離脱後、中央集約型ロギングの可視性が失われる この手口の検知 アカウントが Organization からの離脱を試みると、CloudTrail には少なくとも 2 つの API コールが記録されます。 organizations:AcceptHandshake と organizations:LeaveOrganization です。中央集約型のロギングを構成している場合、これらのイベントが侵害アカウントから観測される最後のイベントとなる可能性があります。Organization からの離脱後、デフォルトではアカウント内のイベントは自身の CloudTrail ログに記録されることになります。アカウントが Organization に参加または離脱する際に関連する CloudTrail イベントを以下に示します。これらのイベントは、AWS Organizations を管理するためにチームが利用する承認済みの運用ワークフローの一部でない限り、調査が必要です。 CloudTrail イベント 意味 LeaveOrganization メンバーアカウントが Organization から離脱しようとしている AcceptHandshake アカウントが別の Organization への参加招待を承諾している InviteAccountToOrganization Organization がアカウントを招待している RemoveAccountFromOrganization 管理アカウントがメンバーアカウントを削除している (メンバー自らが離脱する場合とは異なる) この手口を防ぐための推奨ステップ organizations:LeaveOrganization アクションを拒否する SCP を実装してください。AWS Organizations は この制御の実装に関する詳細なガイダンス を提供しており、具体的な SCP ポリシー JSON や、本番環境および開発環境のアカウントには保護を維持しつつ正当なアカウント移行を許容できる OU 構造の設計に関するアドバイスが含まれています。 SCP は、メンバーアカウント内で IAM ポリシーが許可できる範囲を制限するガードレールとして機能します。AWS Organizations をご利用のすべてのお客様には、この SCP が現在配置されているかを確認し、配置されていない場合には実装に向けた手順を踏むことを強く推奨いたします。この SCP は迅速にデプロイでき、運用上の影響も最小限です。メンバーアカウントを Organization から分離することを慎重に管理・検討するためのプロセスを提供します。 このアクションは、ルートだけでなく organizations:LeaveOrganization 権限を持つあらゆる侵害された IAM プリンシパルから発生し得るため、IAM 権限の最小権限原則は重要な補完的な制御となります。ユーザーやロールがポリシーの追加・削除・変更を行ったり、別のロールを引き受けたり、自身の権限を変更したりできる範囲を制限することで、不正な権限変更が行われる経路を減らすことができます。IAM ポリシーを定期的にレビューし、過度に広範な権限 (特に iam:AttachRolePolicy 、 iam:AttachUserPolicy 、 iam:PutRolePolicy 、および広範な信頼ポリシーを伴う sts:AssumeRole ) を確認することは、侵害されたプリンシパルが実行できる範囲を制限するのに役立ちます。 ルートアカウントのセキュリティは引き続き重要です。ルートの侵害がこのパターンの一般的な侵入経路となるためです。すべてのルートユーザーに対して多要素認証 (MFA) を有効化し、ルートアクセスキーを削除し、メンバーアカウントからルートクレデンシャルを完全に取り除く ルートアクセスの一元管理 を採用することで、リスクの軽減につながります。 今後について 本手口は、私たちが様々なエンゲージメントを通じて目にしている、より広範なテーマを浮き彫りにしています。攻撃者は AWS のガバナンスコントロールがどのように機能するかをますます認識しており、Organization が提供する制御からアカウントを切り離すための意図的な手段を取っています。AWS CloudTrail を無効化する、Amazon GuardDuty ディテクターを削除する、Organization からアカウントを離脱させるといった行為は、いずれも同じ戦略の派生形にあたります。すなわち、本来であれば攻撃者の活動を制約し、お客様による対応を支援するはずのガードレールと可視性から、お客様のアカウントを切り離すというものです。 これを防ぐための制御は本日時点で利用可能であり、実装も簡単です。 AWS Organizations サービスチームのガイダンス から始め、 DenyLeaveOrganizationSCP を実装することをお勧めします。本手口に対して、最も効果が大きく、かつ最も労力の少ない制御です。それ以外にも、OU 構造全体での SCP のカバレッジを見直すこと、すべてのメンバーアカウントでルートクレデンシャルと IAM 権限が適切に保護されていることを確認すること、検知・対応プロセスが本手口を考慮に入れていることを確かめることが、より強固なセキュリティ態勢に貢献します。 Threat Technique Catalog for AWS には、根底にある手口の検知ガイダンスが含まれています。 関連リソース Threat Technique Catalog for AWS – Matrix T1078.A002: Account Root User T1078.004: Cloud Accounts T1098: Account Manipulation T1666.A002: Leave AWS Organization AWS Organizations における不正なアカウント離脱を防止するための重要なセキュリティコントロール メンバーアカウントのルートアクセスを一元管理する AWS Organizations サービスコントロールポリシー Amazon GuardDuty AWS CloudTrail ユーザーガイド 本投稿に関するフィードバックがありましたら、下のコメントセクションにご投稿ください。 著者について Shannon Brazil Shannon は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアであり、デジタルフォレンジックとクラウドセキュリティ調査を専門としています。コミュニティでは 4n6lady として知られ、セキュリティ教育と次世代の防御者の育成に情熱を注いでいます。 Derek Ramirez Derek は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアです。サイバーセキュリティと、困難なインシデントレスポンスの課題への対処を支援する AI ツールの構築という、自身が情熱を注ぐ 2 つのことを組み合わせて取り組んでいます。オースティンのダウンタウンを走ったり、ゴルフのショートゲームに取り組んだり、Dallas Cowboys を熱心に応援したりしています。 Richard Billington Richard は AWS Customer Incident Response Team (アクティブなセキュリティイベント中に AWS のお客様をサポートするチーム) のアジア太平洋地域における Sr. Security Engineer です。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

本ブログは 2026 年 4 月 7 日に公開された Amazon Science Blog “ Verifying and optimizing post-quantum cryptography at Amazon ” を翻訳したものです。 自動推論によって、セキュリティ、性能、保守性の要求をどのように両立させるか。 現在、安全なオンライン通信は 公開鍵暗号 によって実現されています。主に RSA と楕円曲線暗号 (ECC) が使われており、その安全性はある計算問題が困難であるという仮定に依存しています。しかし、これらの問題は 従来の コンピュータでは困難と考えられているものの、十分に大規模な量子コンピュータでは扱える可能性があります。「Store now, decrypt later」(今保存して後で復号) 攻撃は、暗号化された情報を傍受しておき、量子コンピュータで復号できるようになるまで保持する攻撃です。こうした攻撃が技術的に実現可能になるよりはるか前から、対策が必要となります。 ポスト量子暗号 (PQC) は、従来のコンピュータ上で動作しながら量子コンピューティングに対しても安全な暗号です。2024 年、米国国立標準技術研究所 (NIST) は 8 年にわたる標準化作業を経て、標準規格 FIPS-203 を公開しました。FIPS-203 では、量子コンピュータからの攻撃に対して安全と考えられている鍵共有メカニズムとして、Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) が規定されています。 本記事では、Amazon Automated Reasoning Group、AWS Cryptography、そしてオープンソースコミュニティが協力して、ML-KEM のオープンソースかつ形式的に検証された最適化実装をどのように作り上げ、お客様を「Store now, decrypt later」攻撃から最高の保証と最小のコストで保護しているかをご紹介します。 優れた暗号エンジニアリングとは何か? Amazon の Customer Obsession に従い、AWS は暗号ソリューションに取り組む際、次の 3 つの目標を優先します。 お客様のデータのセキュリティ : 暗号は安全に実装することが極めて難しく、わずかな欠陥でもお客様のプライバシーを危険にさらす可能性があるため、万全を期す必要があります お客様の体験 : 暗号には計算コストが伴います。AWS はこれを最小化し、お客様に最小のコストと最良の体験を提供します ソリューションを将来にわたって保守する能力 : 保守に費やす時間が少ないほど、お客様のためにより多くのイノベーションを生み出せます しかし、これらの目標の間にはトレードオフがあります。シンプルなコードは保守も安全な記述も最も簡単ですが、動作が遅くなりがちです。一方、高速なコードは監査が難しく、エラーが起きやすい傾向があります。 自動推論 によって、AWS はこのトレードオフを解消し、安全で、高速で、保守しやすい暗号ソリューションを同時にお客様に提供できます。 なぜ新たな ML-KEM 実装が必要なのか ML-KEM (旧称 Kyber) は実装の観点から十分に研究されています。一方では、 Kyber リファレンスコード が、長年精査されてきたクリーンな C 言語実装を提供しています。他方では、ML-KEM をさまざまな指標やプラットフォーム向けに最適化する方法を記述した数多くの研究論文があります。 2024 年に AWS Cryptography と Amazon Automated Reasoning Group が直面した課題は、リファレンス実装のシンプルさと、研究で明らかになった最適化の可能性を、本番環境で使える単一の実装に組み合わせることでした。 2024 年、AWS Cryptography と Amazon Automated Reasoning Group は、徹底的に精査された ML-KEM リファレンス実装のシンプルさと、研究で明らかになった最適化の可能性を、本番環境で使える単一の実装 mlkem-native にまとめるという課題に取り組みました。 同じ頃、AWS は Linux Foundation の Post-Quantum Cryptography Alliance (PQCA) の創設メンバーとなりました。PQCA は、「標準化過程にあるポスト量子暗号アルゴリズムの高保証ソフトウェア実装の構築を目指すオープンソースプロジェクトの集合」である Post-Quantum Cryptography Package (PQCP) を立ち上げました。 そこで AWS は独自にコードを開発するのではなく、チームメンバーが PQCP に参加し、まもなく mlkem-native を立ち上げました。これは、ML-KEM リファレンス実装と、最適化および形式的検証に関する研究を組み合わせることを目的とした、ML-KEM の高保証・高性能 C 言語実装です。 速く、そして慎重なコーディング mlkem-native のモジュラー設計は、ML-KEM の高レベルロジックをカバーする フロントエンド と、性能が重要なすべてのサブルーチンを担当する バックエンド を組み合わせています。各サブルーチン (SHA3 の基礎となる Keccak 置換や、高速な多項式演算の基礎となる数論変換 (NTT) を含む) には、特定のハードウェア向けにネイティブに記述された、高効率な複数の実装が用意されています。デフォルトの C 言語実装に加えて、mlkem-native は AArch64、x86_64、RISC-V64 向けのアセンブリ/組み込み関数バックエンドを提供しています。 mlkem-native のモジュラー設計は、ML-KEM の高レベルロジックをカバーするフロントエンドと、性能が重要なサブルーチンの複数のハードウェア固有実装からなるバックエンドを組み合わせています。 保守性のために重要なのは、フロントエンドとバックエンドの間のインターフェイスが固定されていることです。新しいターゲットアーキテクチャ向けの最適化を追加する開発者は、バックエンド仕様に従って選択したバックエンド機能を実装し、フロントエンドはそのまま維持します。バックエンド仕様の策定は、見かけほど単純ではないことが分かりました。これについては以下で説明します。 限界を知る メモリ安全性 C プログラミング言語のよく知られた課題は、バッファオーバーフローのリスクです。メモリ領域の指定された境界を超えて書き込むと、データ構造が破壊され、悪意を持って悪用されると非特権コードの実行につながる可能性があります。こうした問題の総称が メモリ安全性 です。Rust のようなメモリ安全な言語は、範囲外アクセスの影響を制限できます (たとえば、未定義動作を示す代わりにパニックする)。しかし、間違いそのものを防ぐわけではありません。 型安全性 もう一つのよく知られた課題は ML-KEM の実装に関するもので、整数オーバーフローのリスク、つまり 型安全性 の側面です。RSA や ECC と同様に、ML-KEM はモジュラー演算に依存しています。モジュラー演算では、演算の結果を特定の数 (ML-KEM の場合は素数 3,329 で、 MLKEM_Q または単に q と表記) で割り、その剰余だけが次に持ち越されます。剰余演算子はパーセント記号 % で表されます。 論理的には、ML-KEM で 2 つの数 x と y を加算または乗算する必要がある場合、( x + y ) % q および ( x * y ) % q を計算する必要があります。たとえば、(294 * 38) % q = 11,172 % q = 1,185 となります。このような「即時」のモジュラー q 演算は、データを「正規」範囲 {0, 1, 2, … , q -1} で表すために常にモジュラー還元を適用するもので、極めて遅くなります。 効率的な ML-KEM 実装では、代わりに「遅延」モジュラー q 演算を使用します。データはできるだけ長くモジュラー還元なしで操作され、最悪の場合のオーバーフローのリスクが生じたときにのみ還元が行われます。さらに、これにより Montgomery 還元のような不完全な還元アルゴリズムが使えるようになります。これは高速ですが、必ずしも完全に還元された出力を返すわけではありません。 ML-KEM の場合、モジュラー q = 3,329 のデータは通常、符号付き 16 ビット整数に格納されます。ML-KEM の数多くの算術ルーチン全体で遅延演算を扱う際には、データの最悪値の境界を追跡し、それらの境界が 16 ビット整数の限界を超える可能性のある箇所にモジュラー還元を挿入することが不可欠です。この領域での小さな間違いは、テストで見逃されることがあります。なぜなら、平均的な境界は最悪値の境界よりはるかに小さい傾向があるためです。そして、本番環境でランダムに表面化することがあります。 バッファ境界、特に算術境界の追跡は、時間がかかり、エラーが起きやすい作業です。たとえば、低レベルの算術関数の出力境界を弱めると、まったく別の関数で稀に算術オーバーフローが発生することがあります。これを手作業で確認するには、緻密なドキュメント作成と熟練した監査担当者が必要なだけでなく、開発が遅くなります。 mlkem-native では、C Bounded Model Checker (CBMC) というツールを使用して、C レベルでメモリ安全性と型安全性を自動的に検証しています。各関数について、機械可読かつ人間可読な契約をソースコードに追加してバッファと算術データの境界を指定し、CBMC にそれらの境界に対してバッファオーバーフローや算術オーバーフローが発生し得ないことを自動的に検証させます。 モジュラー還元の簡単な例を見てみましょう。 void mlk_poly_reduce_c(mlk_poly *r) __contract__( requires(memory_no_alias(r, sizeof(mlk_poly))) assigns(memory_slice(r, sizeof(mlk_poly))) ensures(array_bound(r->coeffs, 0, MLKEM_N, 0, MLKEM_Q))) { unsigned i; for (i = 0; i < MLKEM_N; i++) __loop__( invariant(i <= MLKEM_N) invariant(array_bound(r->coeffs, 0, i, 0, MLKEM_Q))) { /* Barrett reduction, giving signed canonical representative */ int16_t t = mlk_barrett_reduce(r->coeffs[i]); /* Conditional addition to get unsigned canonical representative */ r->coeffs[i] = mlk_scalar_signed_to_unsigned_q(t); } mlk_assert_bound(r, MLKEM_N, 0, MLKEM_Q); } 関連する部分を一つずつ見ていきましょう。まず、 __contract__( … ) に注目します。簡単に言うと、 memory_no_alias と memory_slice の行は、コードが読み書きできるメモリを指定しています。これはメモリ安全性に関連します。 ensures(array_bound(…)) 句は型安全性に関連しています。これは、関数が戻った時点でデータが区間 [0, 1, …, q ) 内にあることを 保証する ことを指定します。証明では、 __loop__(invariant(…)) があり、ループがこの境界を段階的にどう確立するかを指定しています。 i 番目のイテレーションでは、 i 番目の係数まで成立します。最後に、実装は実質的に mlk_barrett_reduce と mlk_scalar_signed_to_unsigned_q を組み合わせています。CBMC はこれらの内部を見ず、それらの契約に置き換えます。 int16_t mlk_barrett_reduce(int16_t a) __contract__( ensures(return_value > -MLKEM_Q_HALF && return_value < MLKEM_Q_HALF) { ... } int16_t mlk_scalar_signed_to_unsigned_q(int16_t c) __contract__( requires(c > -MLKEM_Q && c < MLKEM_Q) ensures(return_value >= 0 && return_value < MLKEM_Q) ensures(return_value == (int32_t)c + (((int32_t)c < 0) * MLKEM_Q)) { ... } mlk_barrett_reduce がまず対称的な出力区間 ( -q /2, …, q /2) を確立し、次に mlk_scalar_signed_to_unsigned_q がそれを [0,1, …, q ) にマッピングしているのが分かります。この例では、仕様が望ましい形で整合していることを目視で簡単に確認できますが、より複雑な例ではそれほど明確ではありません。いずれにせよ、CBMC が自動的にチェックしてくれます。 速く動かしながら安全を保つ 上述の CBMC 証明は、mlkem-native の C コードに対するメモリ安全性と型安全性を確立します。しかし、mlkem-native の最も性能が重要な部分 (Keccak 置換と数論変換) は、AArch64 と x86_64 向けに手作業で最適化されたアセンブリで実装されています。 mlkem-native のアセンブリ実装に対して、高い性能を維持しつつ保証を得るために、AWS は次の 3 つのコンポーネントを使用しています。アセンブリのスーパーオプティマイザーである SLOTHY、対話型定理証明器である HOL Light、そして HOL Light 上に構築されたアセンブリ用検証基盤である s2n-bignum です。これらを組み合わせることで、開発者がクリーンで保守しやすいアセンブリを記述しつつ、デプロイされるコードが正当性の形式的保証を伴ってピーク性能を達成するワークフローが可能になります。 高性能なアセンブリを手で書くと、根本的なトレードオフが生じます。計算を明確に表現するクリーンで監査可能なコードは遅く、高速なコードは密で、マイクロアーキテクチャ固有で、保守が困難です。SLOTHY はマイクロアーキテクチャ固有の最適化を自動化することで、このトレードオフを解消します。アセンブリプログラムを制約充足問題に変換し、制約ソルバーを使用して最適な命令スケジュールとレジスタ割り当てを見つけ、最適化されたアセンブリを出力します。開発者は計算のロジックを重視したクリーンなコードを書き、SLOTHY が高速なコードを生成します。 AWS は、すべての AArch64 および x86_64 アセンブリルーチンの機能的正当性を、HOL Light と s2n-bignum を使用して証明します。SLOTHY が使用される場所では、特定の命令順序やレジスタ割り当てに依存しないように証明が記述されます。したがって、証明を調整することなく、特定のマイクロアーキテクチャ向けにコードを再最適化できます。この「事後」検証アプローチは、アセンブリで表現された計算の数学的な正しさを、それがどのように生成されたかにかかわらず確立します。特に、SLOTHY は信頼できるコンピューティングベース (TCB) から除外されます。 誠実さを保つ 形式的検証は決して絶対的なものではありません。すべての証明は、形式的なオブジェクト (仕様とモデル) を非形式的な現実世界の要件とシステムに結び付けるものであり、これらの結び付きにはギャップが生じます。形式的仕様は実際に必要なものを捉えているか? 形式的モデルは実際のシステムを忠実に反映しているか? 証明基盤自体は健全か? お客様の信頼を獲得し維持するには、これらの限界について透明性を保つ必要があります。そこで AWS は、 SOUNDNESS.md と題したドキュメントを作成・公開しました。ここでは、mlkem-native で何が証明され、何が仮定され、残存リスクがどこにあるかを、HOL Light 証明で使用されるハードウェアモデルの忠実性、CBMC のより大きな TCB、2 つの検証スタック間の手動の橋渡しに至るまでマッピングしています。各ギャップについて、実施されている緩和策を説明し、今後の作業の概要を示しています。 AWS の目標は完璧を主張することではなく、透明性を通じて信頼を獲得することです。コミュニティの皆様には SOUNDNESS.md を批判的に読み、AWS の前提に異議を唱え、残存するギャップを埋めることにご協力いただければ幸いです。 本番環境への展開 mlkem-native は、AWS サービス全体の安全な通信を支える Amazon のオープンソース暗号ライブラリ AWS-LC に統合されています。この統合では、自動インポーターを使用して mlkem-native のソースコードをアップストリームリポジトリから直接取り込み、AWS-LC が最新の検証済み実装と同期し続けることを保証します。 この統合は手間を最小限に抑えるよう設計されています。mlkem-native のモジュラーアーキテクチャにより、AWS-LC はコアの ML-KEM ロジックをインポートしながら、プラットフォーム固有のコンポーネントには独自の実装を提供できます。たとえば、AWS-LC は mlkem-native の暗号プリミティブを既存の FIPS-202 (SHA-3) 実装にマッピングし、AWS-LC の乱数生成およびメモリゼロ化関数を使用し、必要な場合はペアワイズ一貫性テストなど FIPS モード機能を有効にします。これを可能にしているのは、検証済みコードを変更することなく mlkem-native の API を AWS-LC のインフラストラクチャに橋渡しする薄い互換性レイヤーです。 重要なのは、メモリ安全性と型安全性を証明する CBMC 契約が、インポートされたソースコード内に保持されていることです。プリプロセッサがコンパイルされたバイナリからこれらを削除しますが、ソース内には残り、コードの保証の機械チェック可能なドキュメントとして機能します。これは、実装と共に移動する一種の「生きた証明」です。 さらに、mlkem-native も AWS-LC もオープンソースで寛容なライセンスのため、その利点は AWS の枠を超えて広がります。誰でも mlkem-native を自社のシステムに統合し、同じ性能と保証の組み合わせを得ることができます。形式的検証成果物 (CBMC 契約と HOL Light 証明) はリポジトリの一部であり、関連するすべてのツールはオープンソースであり、セットアップと証明チェックのスクリプトが提供されているため、AWS のセキュリティ主張を独立に検証できます。 インパクト mlkem-native の開発は、自動推論を体系的に適用すれば、暗号エンジニアリングの 3 つの目標 (セキュリティ、性能、保守性) が衝突しないことを示しています。 CBMC は、複雑な算術全体で境界を手動で追跡する作業から AWS を解放し、テストでは見逃されて本番環境でランダムに表面化するエラーを捕捉しました。アノテーションはソースコード内に機械チェック可能なドキュメントとして残り、コードを同時により保守しやすく、より安全にします。HOL Light と s2n-bignum により、AWS は数学的な正当性の確実性を持って積極的なアセンブリ最適化をデプロイできました。SLOTHY により、特定のマイクロアーキテクチャ向けにピーク性能を達成しながら、クリーンで監査可能なコードを書くことができました。そして、証明は最適化に依存しないように記述されているため、検証をやり直すことなくコードのターゲットを変更できます。 その結果、従来の開発で達成できるものよりも、同時により安全で、より高速で、より保守しやすい実装が実現しました。AWS はお客様のセキュリティ、お客様の体験、そして革新する能力の間で妥協しませんでした。自動推論は 3 つすべてを実現したのです。 AWS-LC-FIPS リリース プラットフォーム 処理 3.1 4.0 改善倍率 c7i Keygen 30899 65146 2.1 Encaps 30623 61233 2.0 Decaps 25141 51545 2.0 c7g Keygen 29617 71134 2.4 Encaps 28482 66874 2.3 Decaps 23919 64765 2.3 Amazon の暗号ライブラリ AWS-LC で ML-KEM リファレンス実装から mlkem-native に切り替えた際の性能影響。ML-KEM-768 の性能は c7i および c7g EC2 インスタンスで測定されています。数値は 1 秒あたりの処理数を表します (高いほど良い)。ベースラインは ML-KEM の C リファレンス実装を含む AWS-LC-FIPS 3.1 リリースです。AWS-LC-FIPS 4 リリースは mlkem-native でビルドされています。プラットフォームは Intel(R) Xeon(R) Platinum 8488C を搭載した c7i と、Graviton 3 プロセッサを搭載した c7g です。 謝辞 同僚の John Harrison 氏 (Automated Reasoning Group の senior principal applied scientist) には、HOL Light での AArch64 アセンブリ証明の大部分を提供し、また HOL Light 対話型定理証明器および s2n-bignum 検証基盤の保守を担当いただいたことに感謝します。mlkem-native は AWS だけでなく、オープンソースコミュニティの多くのメンバーが関わる共同作業です。とりわけ、共同保守者である zeroRISC の Matthias Kannwischer 氏に感謝します。彼は AWS と共に mlkem-native を立ち上げ、以来プロジェクトの成功に重要な役割を果たしてきました。 著者について Hanno Becker Hanno Becker は Amazon の Automated Reasoning Group の principal applied scientist です。元 Mbed TLS の開発者で、Arm 上の高性能 (ポスト量子) 暗号に情熱を注いでいます。SLOTHY スーパーオプティマイザーの作者でもあります。 Rod Chapman Rod Chapman は Amazon Web Services (AWS) の senior principal scientist です。 Dusan Kostic Dusan Kostic は Amazon Web Services (AWS) の senior applied scientist です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは。ソリューションアーキテクトの東 健一です。普段はパブリックセクター技術統括本部で中央省庁のお客様の技術支援を担当しており、主にガバメントクラウドや医療 DX に関わるご支援を担当しております。 2026年5月19日（火）に、AWS 目黒オフィスにて「ガバメントクラウドワークショップ 2026 春 ～ AI で実践する開発・モダナイズ・運用 ～」を開催しました。 本ワークショップは、ガバメントクラウドに携わる事業者様を対象に、移行を進める上で必要となる技術を深く学び (Dive Deep)、案件で直面するリアルな課題や他官公庁／自治体の取り組みを共有し、参加者同士の交流を楽しむ (Have Fun) ことを目的とした技術イベントです。 今回のワークショップでは、「 AI を使った開発・モダナイゼーション・運用 」をメインテーマに掲げ、事例セッション・デジタル庁様セッションに加え、参加者の皆様にあらかじめ関心のあるテーマを選択いただいたうえで、手を動かしながら学ぶ 4 つのテーマ別ワークショップを実施しました。当日は会場が満席となり、総勢150名以上の方々にご参加いただく盛況なイベントとなりました。さらに夜の部として、AWS ユーザーコミュニティ「JAWS-UG」の公共分野支部である Gov-JAWS との懇親会を併催し、日中のセッションを振り返りながら参加者同士の交流を深める時間としました。 なお、前回の開催内容について気になる方は下記のブログをご参照ください。 【開催報告】 第2回 自治体事業者向け AWS ガバメントクラウドワークショップ 2025 in 大阪 【開催報告】第三回 中央省庁向け AWS ガバメントクラウドワークショップ イベント概要 本ワークショップは以下のような形で実施しました。 日時 : 2026年5月19日（火）13:00 – 18:30（12:30 受付開始） 懇親会・Gov-JAWS: 18:30 – 21:00 場所 : アマゾン ウェブ サービス ジャパン合同会社 目黒オフィス 参加対象 : ガバメントクラウドに携わる全ての方々 時間 セッション・ワークショップ名 13:00-14:00 中央省庁担当 事業者様登壇 14:00-14:30 自治体担当 事業者様登壇 14:30-15:30 デジタル庁様登壇 15:30-15:40 休憩 15:40-18:30 各テーマに分かれて Workshop 18:30-21:00 懇親会 / Gov-JAWS イベント構成 オープニングおよび事例セッション・デジタル庁セッションを全体で実施した後、参加者の皆様にあらかじめ選択いただいた以下 4 つのテーマに分かれて、各部屋でハンズオン形式のワークショップを実施しました。 AI エージェントを開発する（Strands Agents / AgentCore） AI を使ってシステムをモダナイズする（AWS Transform / Kiro） AI を使ってシステムを開発する（Kiro IDE 実践） AI を使ってシステムを運用する（生成 AI を用いた AWS 環境のトラブルシューティング効率化） 各セッションの概要と発表資料は以下をご覧ください。 事例セッション・デジタル庁セッション ハイライト Step Functions で実現するフルマネージド・ジョブ開発 — ガバメントクラウド開発における 設計／開発・運用時の「理想と現実」のギャップ 発表資料 ： Step Functions で実現する フルマネージド・ジョブ開発（杉元） NTT データ 杉元様より、ジョブ管理ツールを AWS Step Functions を中核に据えてフルマネージドなジョブ機能として作り変えた取り組みについて、設計・開発・運用のリアルな学びとともにご紹介いただきました。「依存関係の表現」「再実行 / リラン」「リトライや補償」「並列実行」「監視・通知」「権限分離」といった “ジョブ管理っぽさ” を、Step Functions のステートマシンとしてどのように実装で落とし込んだかを共有いただきました。 あわせて、移行時に直面した設計／開発時の理想と現実（苦悩）のギャップ、稼働後に見えてきた運用時の理想と現実のギャップを、失敗事例も含めて整理いただきました。ジョブ管理ツールの置き換えを検討している方や、ワークフローを “運用できるジョブ基盤” にしたい方にとって、現実的な設計判断と運用設計の勘所を持ち帰れるセッションとなりました。 Amazon Bedrock で生成 AI 活用サービスをセキュアに構築する方法 発表資料 ： Amazon Bedrock で生成AI活用サービスをセキュアに構築する方法 – Speaker Deck アクロクエストテクノロジー 鈴木様より、 国土交通省様向けにAI書類審査ソリューションを構築支援したご経験 などを踏まえ、AWS の生成 AI サービスである Amazon Bedrock を前提として、どのように基盤モデルのセキュリティ対応を実現するかのポイントをご紹介いただきました。 あわせて、RAG（Retrieval-Augmented Generation）や AI エージェントといった生成 AI 活用サービスを構築する上でのセキュリティ観点を、構成例を交えながら解説いただきました。日本の公共案件で生成 AI を活用する際に求められるセキュリティの考え方が整理されており、これから生成 AI 活用に取り組む事業者様が設計の指針として持ち帰れる実用的な発表内容でした。 自治体ガバメントクラウドにおける生成 AI 活用 NTT 西日本 三浦様より、自治体のお客様向けに生成 AI を導入された取り組みについてご紹介いただきました。AWS が公開している OSS の生成 AI 活用基盤 GenU の閉域オプションをベースに、 Amazon Bedrock AgentCore を活用した独自 AI エージェントの開発を行っているとのお話で、自治体特有のセキュリティ要件を満たしつつ生成 AI 活用を進めるための実践的な設計・構築のポイントを共有いただきました。OSS をベースとしたうえで自社のユースケースに合わせて AgentCore で拡張するアプローチは、これから自治体向けに生成 AI 導入を検討する事業者様にとっても参考になる内容となっておりました。 GCAS ヘルプデスクについて 概要説明および活用方法のご紹介 デジタル庁 加藤様、萬谷様より、ガバメントクラウドにおける GCAS ヘルプデスクの役割と活動についてご紹介いただきました。GCAS ヘルプデスクの概要から、より効果的にご活用いただくための考え方や問い合わせ方法、実際のお問い合わせ事例やフィードバック、CSP (Cloud Service Provider) との連携内容、今後の改善に向けた方針までお話しいただきました。 GCAS ヘルプデスクが単なる問い合わせ窓口にとどまらず、利用者の声をガバメントクラウドの改善につなげる場であるというメッセージは、参加事業者様にとって今後の活用イメージを大きく広げるものとなりました。 ガバメントクラウドにおける生成 AI 利用環境「源内」の構築と展開 デジタル庁 荻原様より、政府職員の業務品質の向上と効率化を実現するために、ガバメントクラウド上に構築・展開している生成 AI 利用環境「 源内 」についてご紹介いただきました。現在、デジタル庁の職員のみならず、全府省庁約 18 万人の政府職員が生成 AI を利用できるよう、大規模実証事業を推進されています。 本セッションでは、ガバメントクラウドにおける「源内」のシステム概要と、大規模展開にあたって考慮した AI 特有の観点についてご説明いただきました。あわせて、行政業務に特化したアプリケーションの取り組みや、オープンソースソフトウェア (OSS) として公開された内容についてもご紹介いただきました。 ガバメントクラウド上での生成 AI 利用の最前線の取り組みを、構築・運用の双方の観点から伺えるセッションとなり、参加事業者様にとっても今後の生成 AI 活用案件に向けた貴重なリファレンスとなりました。 テーマ別ワークショップ Strands Agents, AgentCore を使った AI エージェントのデプロイ（AI エージェントを開発する） ワークショップ資料 ： AI エージェントハンズオン 〜 作って、動かして、体験する 〜 AWS ソリューションアーキテクトの松本より、オープンソースの AI エージェント開発フレームワークである Strands Agents を使ったエージェント開発の体験から、 Model Context Protocol (MCP) を使った AI エージェントの動きの理解、そして AgentCore Runtime を使った AI エージェントのデプロイまでを、一連のハンズオンとして体験いただきました。 さらに後半では、AWS 公式 GitHub で公開しているサンプル実装である RAPID （生成 AI を活用した書類審査ソリューション）と Moca （マルチエージェントオーケストレーションのサンプル）を実際にお試しいただき、業務適用イメージを具体化していただきました。実装から本番デプロイ、さらにユースケース特化型のサンプル実装までをエンドツーエンドで体験できる内容となり、生成 AI を活用したサービス開発の第一歩として手応えを感じていただけたワークショップとなりました。 Kiro IDE 実践ワークショップ（AI を使ってシステムを開発する） ワークショップ資料 ： Kiro IDE 実践ワークショップ AWS ソリューションアーキテクトの葉山より、生成 AI の概要解説からスタートし、生成 AI を使った開発体験、Kiro を活用した開発業務の効率化までを体験いただきました。仕様駆動開発（Spec-Driven Development）の考え方に基づき、要件定義からコード生成までを Kiro でどのように実現するかをハンズオンで学んでいただきました。「すぐにでも自分の業務で試したい」という声を多くいただいたワークショップとなりました。 生成 AI を用いた AWS 環境のトラブルシューティング効率化（AI を使ってシステムを運用する） ワークショップ資料 ： 生成AIを用いたAWS環境のトラブルシューティング効率化ワークショップ ワークショップ補足資料 ： 生成 AI を用いた AWS 環境のトラブルシューティング – Speaker Deck AWS ソリューションアーキテクトの東より、AWS 上に構築したシステムにおいてトラブルシューティングを生成 AI を用いて効率化するための手法をご紹介し、ハンズオンとして体験いただきました。ガバメントクラウドで活用できる手法・サービスを紹介しつつ、一般の AWS 環境でも活用可能な手法も併せてお試しいただける内容となり、運用業務の効率化に向けた具体的な打ち手を持ち帰っていただけました。 AWS Transform, Kiro を使ったモダナイゼーション（AI を使ってシステムをモダナイズする） AWS ソリューションアーキテクトの今坂より、AI エージェントによるレガシーコードの分析・バージョンアップグレード計画の自動生成を体験いただいた後、AI エージェントを活用したバージョンアップグレードを実際に体験いただきました。「これまで人手で時間をかけていたモダナイゼーション作業が、AI エージェントの活用でここまで自動化できるのか」という驚きとともに、自社案件への適用イメージを持ち帰っていただけたワークショップとなりました。 ※ ワークショップ資料については「Kiro IDE 実践ワークショップ」と同じコンテンツをベースに実施しております。 Gov-JAWS ワークショップと併せて、 Gov-JAWS の活動も行われました。Gov-JAWS は、AWS のユーザーコミュニティ「 JAWS-UG 」の支部として、公共分野における AWS 利用に焦点を当てた新しいコミュニティです。政府や自治体が進める公共分野のクラウド利用に関連する知識やノウハウを共有するための場として設立されました。 イベント当日は夜の部として Gov-JAWS 第 5 回 Meet Up が開催され、懇親会と併せて多くの参加者が交流を深めました。このコミュニティを通じて、今後も公共分野でのクラウド活用に関する情報共有と横のつながりの拡大が期待されています。 詳細は Gov-JAWS 側のページをご覧ください。 まとめ 今回のガバメントクラウドワークショップ 2026 春では、「AI エージェント開発」「モダナイゼーション」「AI 駆動開発」「AI による運用効率化」という生成 AI を軸とした 4 つのテーマに加え、ジョブ基盤の実装事例、生成 AI のセキュアな構成、自治体システム標準化の取り組み、GCAS ヘルプデスクの活用といった、ガバメントクラウドに携わる事業者様にとって直近で必要となるテーマを幅広く取り扱いました。 ご参加いただいた皆様におかれましては、お忙しい中ご足労いただき誠にありがとうございました。また、ご登壇いただいた NTT データ様、アクロクエストテクノロジー様、NTT 西日本様、デジタル庁様にも、貴重な知見をご共有いただきましたことを心より御礼申し上げます。 AWS では、今後もガバメントクラウドに携わる事業者様向けのワークショップを継続して開催してまいります。次回開催のご案内をお待ちください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウド相談窓口を設けております。ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/ 著者について 東 健一 アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト。パブリックセクター技術統括本部に所属し、主にガバメントクラウドや医療 DX 、コンテナワークロードに関する案件の技術支援に取り組んでいる。

本ブログは、キヤノンIT ソリューションズ株式会社様と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクト木村、アカウントマネージャーの池田です。 本記事では、キヤノン IT ソリューションズ株式会社様が 、Amazon Q Developer を開発現場に導入し、3 か月間効果検証を実施した取り組みをご紹介します。コード生成やレビュー支援による効率化、現場での活用事例、そして検証から得られた知見について詳しく解説します。 なお、本ブログに登場する Amazon Q Developer は 2026 年 4 月 30 日に AI 駆動開発IDE「Kiro」へと進化的に統合されることが発表されています 。 本検証で培ったAI駆動開発のプラクティスやノウハウは、Kiro の仕様駆動開発（Spec-driven Development）へとそのまま活かせるものであり、キヤノン IT ソリューションズ様 の取り組みはまさにこの進化を先取りしたものと言えます。 背景/課題 キヤノンITソリューションズ株式会社様(以下、キヤノン ITS )では、生成 AI ツールの社内推進活動を積極的に実施しています。今後 SIer としての競争力を維持していくために、生成 AI の活用は不可欠です。しかし、個人レベルでの試行には限界があるため、企業として活用のための基盤整備や推進を進める必要がありました。 そこでキヤノン ITS 様は、2024年に「生成 AI ビジネス検討委員会」を立ち上げて、生成 AI ビジネスにおける 5 年後のありたい姿と戦略を策定し、その具体的な施策を推進するための「生成 AI ビジネス推進室」を発足。社内の利用ガイドラインの整備、生成 AI ツールの全社的な導入を推進してきました。 生成 AI ツールの導入後に現場への定着をいかに進めるかは、多くの企業にとって共通の課題です。キヤノン ITS 様は全社横断向けの複数回に渡るイベント形式で「AI 駆動開発の普及」を行うことで、より深い活用推進を実施しました。 なぜ Amazon Q Developer を選択したのか(導入当時) 全社利用が可能な生成 AI ツールは導入済みではありましたが、「AI 駆動開発の普及」という目的に対し、コスト・運用・性能のバランスに優れた選択肢であることから Amazon Q Developer を選択しました。 コスト: 月額ユーザー数の固定料金で予算計画が容易 同機能の固定費用で使えるサービスとしては最も安価 運用: 既存の AWS 環境（情報システム部門の管轄）でアカウント管理可能 AWS から導入・普及の支援を受けることができる 性能: Claude Sonnet 4（実施当時）による高精度の生成 MCP 対応による拡張性の高さ セキュリティ・脆弱性診断、モダナイゼーションなど SI に役立つ機能搭載 AI駆動開発の普及をする上での工夫ポイント 本施策が単なるツール導入だけで終わらぬよう、事前に懸念事項を洗い出し、キヤノン ITS 様と AWS にて、役割分担を行い施策設計をしました。 懸念事項 Amazon Q Developerのリリース・キックオフがなされただけで、ツールが使われない 事業部側での予算制限があり、積極利用がなされない ツールの認知はされているが、使い方が分からずに利用がされない AI駆動開発の取組自体が限られた少数のメンバーにしか知られない 対策 オペレーション整備 ツールを使ってもらえるような申請フローの整備（キヤノン ITS） 興味喚起 「このツールは面白い」と思ってもらえるイベント。継続するための仕掛けづくり（AWS） 障壁排除 ハンズオン/定期的なオフィスアワーを行うことで技術的な懸念点を払拭（キヤノンITS/AWS） イベント化 打ち上げ花火のようなオンラインイベントで終わらせず、興味喚起、ハンズオン研修、利用者のトラッキングを行いランキング発表等、全社向けの年末までのロードマップを敷いて継続施策として打ち出す（キヤノンITS/AWS） エグゼクティブスポンサー エグゼクティブスポンサーである、金澤社長からの支援と声かけを実施（キヤノンITS） ロードマップ全体像 AI駆動開発の社内展開に向けて、Amazon Q Developer の業務適用検証を実施しました。本取り組みは、9 月 5 日に開催した「AI Agent DAY」をキックオフとし、Amazon Q Developer を実際の業務に適用した際の有効性を約 3 か月間にわたり検証したものです。 キックオフイベントには約 250 名が参加し、100 名以上の技術者が Amazon Q Developer のハンズオンを体験しました。その後の業務適用検証フェーズでは、生成 AI ビジネス推進室がツール利用費を負担する形で施策を企画し、57 名が参加しています。検証期間中は、インフラおよびアプリケーションを対象としたハンズオンセッションやオフィスアワー、中間イベントを実施しました。あわせて、Teams 上の「生成 AI 交流広場」での情報共有やアンケートを通じた成果の可視化にも取り組んでいます。 最終的には、技術者向けイベント「CITS Day 2025」において、Amazon Q Developer を効果的に活用した取り組みを表彰しています。なお、表彰対象検討のための利用状況のデータ分析においても、Amazon Q Developer を活用しました。 Amazon Q Developer の利用状況を示すダッシュボード Amazon Q Developer へ利用率ランキングを集計するプロンプト CITS Day 2025 での表彰 活用事例 CITS Dayのイベント内では、複数の事例が共有されました。 事例1: 開発ツール×生成AI（佐野様の発表） 抱えていた課題 プログラミングの抽象化レイヤーの進化と開発ツールの変化への対応 開発業務の効率化と生産性向上 資料作成やアイデア整理などのコーディング以外の作業の効率化 導入した理由・きっかけ 新しい開発スタイルで「速さ」「安全性」「柔軟性」を実現するため Kiro との出会い（2024年夏）がきっかけ 生成 AI の柔軟性を活かしつつ、課題（コード品質のばらつき、非機能要件への対応不足など）を解決するため 導入して得られた結果 バイブコーディングモードを活用することで、マークダウン形式で効率的に資料作成が可能に レイアウト案をアスキーアートで事前確認するなど、視覚的な提示が可能に 仕様駆動開発モードではプロトタイプの迅速な作成が実現 バーコードスキャナーアプリの要件からタスク分解、実装まで効率的に進行 事例2: PoCでのAmazon Q Developer活用（可知様の発表） 抱えていた課題 SNS バズ検知を需給マネジメントに繋げるための PoC を短期間・低コストで実施 SNS API や可視化技術など、未経験の技術を習得して実装 技術検証フェーズに時間やコストをかけられない 導入した理由・きっかけ 社内からの提案で、生成 AI の活用が適した題材と判断 低コスト（$19/月）で社内環境も整備されていたため 短期間での技術獲得とプロトタイプ開発、生成 AI 活用のノウハウ獲得を目指して導入 導入して得られた結果 新規技術（SNS API 活用技術、Streamlit によるアプリ開発技術）の習得が迅速に進んだ 開発スピードが約 3 倍に向上（通常 2 週間かかる作業が 3 日で完了） コスト削減（10 人日 → 3 人日＋$19の料金のみ、約 1/3 のコスト） 事例3: Amazon Q Developerを使用したインフラ構築（谷様の発表） 抱えていた課題 インフラ構築業務での効率化とエラー削減 Terraform の定義言語 HCL の習得や適切なコーディングの必要性 インフラコード化（IaC）におけるコードレビューと品質確保 導入した理由・きっかけ インフラ構築業務の流れが「パラメーター設計 → コード生成 → デプロイ → テスト」に変わる中で効率化を図るため コード生成からドライテスト、デプロイまでのプロセスを改善するため Claude Sonnet 4.5 が API 課金ではなく使える点が魅力的だった 導入して得られた結果 パラメーターシートやアーキテクチャ図を基に Terraform コードの自動生成が可能に AI によるコードレビューが人間のレビューを補完し、エラー検出が向上 validate、plan、apply の各段階でのエラー検出と修正が効率化 事例4: 仕様駆動開発の手引き（古川様の発表） 抱えていた課題 「仕様が主、実装が従」という本来あるべき開発の構図が逆転しがち 仕様書の陳腐化や実装との乖離の発生 vibe coding は業務で活用するには曖昧すぎる 導入した理由・きっかけ 自分で設計して自分で実装するケースが多く、生成 AI 導入の恩恵が大きいと考えたため 他の生成 AI ツールと Amazon Q Developer の比較検討を自分自身でやってみたかったため 仕様駆動開発が開発手法として確立しつつあり、業務に適用してみたかったため 導入して得られた結果 ルール制定 → README記述 → 設計書作成 → TODOリスト作成 → 実装という流れで社内用の小規模なツールを効率的に開発できた AI が設計図やタスク分解などを自動化し、人間はレビューと意図合わせに集中できる 仕様駆動開発の考え方を取り入れることで、開発の最初に充実したドキュメントを作れるようになった 事例5: Amazon Q Developer 活用事例紹介（鈴木様の発表） 抱えていた課題 製品機能設計に向けて AI エージェント技術の理解と実験環境構築が必要だった AgentCore や CloudFormation など、大量コードの読解や IaC 化の負荷が高い 新しい技術領域で情報が少なく、定義ミスやドキュメント解釈間違いが発生しやすい 導入した理由・きっかけ Amazon Bedrock AgentCore を使った機能検討のため、AI エージェントの仕組み理解と環境構築を効率化したかった GitHub の AgentCore サンプルを活用する中で、Q を使えばコード理解・修正・IaC 化まで一気に進められると判断 大量コードの理解、React アプリ実装など AI に向いている作業が多かったため Q 活用を決断 導入して得られた結果 AgentCore + Knowledge MCP + CloudFormation による再利用可能なAIエージェント実験環境を構築 React チャットアプリやブラウザ動作確認まで実装〜テストの大部分を Q が自動化 Rules 整備やレビューを通じて、Q を“正解を出す AI ”ではなく“協働する相棒”として運用する体制を確立 Try & Error の混乱を Git コミットや TODO 管理で整理し、AI と協働できる実践的な開発フローを確立 定量的な成果 3か月間の業務適用検証期間において、Amazon Q Developerを利用した取組は以下の定量的な成果を達成しました。 コード生成・開発効率 開発スピード 3 倍向上: 通常 2 週間かかる PoC 開発が 3 日で完了 工数削減 67%: 10 人日から 3 人日へ削減、コストは約 1/3 に コード生成数: 検証期間中、57 名の参加者が累計で数千行のコード生成を実施 レビュー・品質向上 レビュー時間短縮: AIによるコードレビュー支援により、人間のレビュー工数を削減しつつエラー検出精度が向上 エラー早期発見: validate、plan、apply の各段階でのエラー検出が効率化され、手戻りコストを削減 継続利用 参加率 95% : 募集定員 60 名に対し 57 名が参加し継続して利用 アクティブ利用: 検証期間中、定期的なオフィスアワーやTeams「生成AI交流広場」での活発な情報交換を実施 イベント参加: キックオフイベントに 250 名、ハンズオンに 100 名以上が参加 定性的なフィードバック（利用者の声） 検証期間中のアンケートやCITS Day 2025での発表から、以下のような利用者の声が得られました。 「SNS API や Streamlit など、未経験の技術を短期間で習得できた。新規技術獲得へのハードルが大幅に下がった」 「PoC の進め方が大きく変わることを実感。人は課題抽出やロジック検討、結果確認に注力できるようになった」 「生成 AI と開発の構造を組み合わせることで、柔軟性・速さと品質・一貫性の両立が可能になった」 「仕様書を起点に、AI エージェントに任せながら効率的に開発できる。仕様駆動開発が現実的な選択肢になった」 「パラメーターシートやアーキテクチャ図を基に Terraform コードの自動生成が可能になり、インフラ構築業務が大幅に効率化された」 検証の総括 キヤノンITS 様は、生成 AI ビジネス推進室を中心に Amazon Q Developer の展開を推進し、3 か月間の業務適用検証を通じて組織的な AI 駆動開発の定着を実現しました。エグゼクティブスポンサーの支援と予算負担の工夫により現場の参加障壁を排除し、専用 Teams チャネルでのコミュニティ形成、定期的なオフィスアワー、実践的なハンズオンセッションという段階的な学習支援を提供しました。 検証期間中、57 名の技術者が実務で Amazon Q Developer を活用し、開発スピード 3 倍向上、工数 67 %削減という具体的な定量効果を達成。Amazon Q Developer 自身で作成したダッシュボードにより利用状況を可視化し、CITS Day 2025 での表彰制度により 5 つの優秀事例を全社で共有しました。 成功の鍵は、生成AIビジネス推進室の設立による組織的な推進体制、単発イベントで終わらせない年間ロードマップに基づく継続的な支援施策、そして実ビジネスでの活用という 3 つの要素にあります。キックオフから始まり、ハンズオン、中間イベント、表彰へと続く一連の取り組みにより、SNS バズ検知システムなど実際の PoC 案件での成果を創出し、新規技術習得の加速、PoC プロセスの変革、インフラ構築の効率化など、多様な領域での効果を実証しました。 キヤノンITS 様からAmazon Web Services Japanへの期待 今回の取り組みを通じて、Amazon Q Developer を開発現場の生産性向上に有効活用できることが実感できました。PoC からインフラ構築、既存システムの改善まで、多様な領域で活用の可能性が広がっています。 今後は、今回の検証で得られた知見をもとに、社内での活用パターンの整理やナレッジの共有を進め、より多くのプロジェクトで生成AIを活かせる環境づくりを進めていきます。また、Amazon Web Services Japan 様と連携しながら、新機能の検証や他サービスとの組み合わせなど、さらなる活用領域の拡大にも取り組んでいく予定です。 生成AI が IT ライフサイクル全般の在り方を大きく変えつつある中、私たちは、現場の開発体験を改善するとともに、社会やお客様へ更なる価値提供に向けて積極的に活用していくための取り組みを継続して進めていきます。 執筆者 キヤノンITソリューションズ株式会社 生成AIビジネス推進室 石堂 きよみ Amazon Web Services Japan ハイテク&ヘルスケア事業本部 アカウントマネージャー Amazon Web Services Japan ソリューションアーキテクト 木村 直登(Naoto Kimura)

本記事は、シリーズ「AWS における AI エージェント対応のデータ基盤」の第 2 回です。 第 1 回 では、AI エージェントが組織の本番データに対して正しく動くために必要な 3 要素（認可・ビジネスデータカタログ・ドメイン知識）を紹介し、認可が効いている様子をデモで示しました。本記事では、3 要素のうち認可に焦点を当て、AI エージェント経由のデータアクセスに Amazon SageMaker Catalog のアクセス制御を透過的に効かせる実装パターンを解説します。 サンプルリポジトリ: aws-samples/sample-sagemaker-agentic-analyst aws-samples sample-sagemaker-agentic-analyst A demo application that demonstrates how fine-grained access controls configured in SageMaker Unified Studio are transparently enforced on data access through AI agents. AI エージェントにアクセス制御を効かせる 3 つの壁 AI エージェントにデータアクセスを任せるとき、守るべき原則があります。エージェントは独自の認可ロジックを持たず、ユーザーが SageMaker Catalog で付与されている権限を、エージェント経由でもそのまま透過的に利用させることです（SageMaker Catalog は Amazon DataZone の上に構築されており、権限設定は DataZone API で操作します）。エージェント内に独自の認可ロジックを作ると、既存のガバナンスと二重管理になり、整合性を保つのが難しくなるからです。 この原則を実現しようとすると、素直な実装ではたどり着けない 3 つの壁があります。これらは本記事で解説する設計上の工夫によって越えられます。 壁 1: コンピュートリソース自体のロールで権限を取得すると、全ユーザーが同一権限になる。 AI エージェントのツールは AWS Lambda 、 AWS Fargate 、 Amazon EC2 など何らかのコンピュートリソース上で実行されます。そのコンピュートリソース自体のロール（たとえば Lambda の実行ロール）で DataZone の GetEnvironmentCredentials API を呼ぶと、返ってくるのはそのロール自身のメンバーシップに基づくプロジェクトロールです。どのユーザーがリクエストしても同じ認証情報が返るため、ユーザー個別のアクセス制御を効かせるには工夫が必要です。 壁 2: SAML フェデレーション経由のトークンには、IdP 側のグループ情報が乗らない。 AWS IAM Identity Center （以下 IdC）と、たとえば Amazon Cognito を SAML フェデレーションで連携する構成では、IdC 側のグループ情報が Cognito のトークンに自動的には含まれません。「データコンシューマーには athena_query を許可し、ドメイン管理者には cloudtrail_query のみ許可する」といったツール単位の認可を IdC のグループベースで行うには、グループ情報をトークンに載せる工夫が必要です。 壁 3: 設定時と実行時で関与するサービスが異なり、認可の全体像を把握する必要がある。 SageMaker Catalog の裏側では複数のサービスが連携しています。設定時に使うサービスと、クエリ実行時に評価されるサービスが異なるため、全体像を把握しないと正しい実装にたどり着けません。 本記事では、サンプルリポジトリ sample-sagemaker-agentic-analyst がこれらの壁をどう越えているかを解説します。 サービスの役割分担を整理する 本記事で扱うサービスの関係を先に整理します。 Amazon SageMaker Catalog は、データと AI の発見・ガバナンス・コラボレーションを担うサービスで、Amazon DataZone の上に構築されています。データの Publish/Subscribe やアクセス権の設定は SageMaker Catalog（および Amazon SageMaker Unified Studio の UI）で行いますが、実際のクエリ実行時に行・列レベルのアクセス制御を評価するのは AWS Lake Formation です。S3 上のファイルに対するアクセス制御は Amazon S3 Access Grants が担います。 つまり、SageMaker Catalog で「誰がどのデータを見てよいか」を 設定 し、Lake Formation と S3 Access Grants が 実行時 にその設定を評価する、という役割分担です。 重要な原則として、DataZone はクエリ実行パスに入りません。後述する認証情報変換フローでは DataZone API（ RedeemAccessToken / GetEnvironmentCredentials ）を呼びますが、これは AgentCore Gateway に接続された Lambda（以下 Tool Lambda）が プロジェクトロールの認証情報を取得する ための前段であり、Athena クエリや S3 オブジェクト取得そのものには DataZone は介在しません。クエリ実行時の認可評価は Lake Formation と S3 Access Grants が担います。この「認証情報取得の経路」と「データアクセスの経路」の分離を理解しておくと、以降のフローが読みやすくなります。 認証情報変換フロー: 5 つのステップ 壁 1 と壁 3 に対応するため、本サンプルでは 5 つのステップで認証情報を変換します。ブラウザでサインインしたユーザーの Cognito トークンから出発し、最終的にそのユーザーの権限が反映された SageMaker プロジェクトロールの一時認証情報を Tool Lambda の手元に届けます（下図）。 Step 1: ブラウザから AgentCore Runtime へ ブラウザ上の React アプリが、 Amazon Bedrock AgentCore Runtime のエンドポイントに HTTPS リクエストを送ります。このリクエストには 2 つのトークンが乗っています。 Authorization: Bearer <Cognito Access Token> — Runtime の Cognito Authorizer が検証します カスタムヘッダー X-Amzn-Bedrock-AgentCore-Runtime-Custom-Cognito-Id-Token: <Cognito ID Token> — 次のステップで使います Cognito Access Token と Cognito ID Token はどちらも Amazon Cognito が発行する JSON Web Token（JWT）ですが、役割が異なります。Access Token は「このリクエストは正当なユーザーから来たか」を Runtime と Gateway が判定するために使います。ID Token はユーザーのアイデンティティ情報（メールアドレスなど）を含んでおり、次のステップで IdC のユーザーと突き合わせるために使います。 Step 2: chat-agent が Cognito ID Token を IdC Access Token に引き換える Amazon Bedrock AgentCore Runtime はエージェントプロセスをホストするマネージドサービスです。呼び出し主体はその上で動くユーザーコード（本サンプルでは chat-agent ）であり、Runtime サービス自身がトークン変換を自動で行うわけではありません。 chat-agent が IdC の CreateTokenWithIAM API を呼びます。 const tokenRes = await new SSOOIDCClient({ region }).send( new CreateTokenWithIAMCommand({ clientId: idcApplicationArn, grantType: 'urn:ietf:params:oauth:grant-type:jwt-bearer', assertion: cognitoIdToken, }), ); const idcAccessToken = tokenRes.accessToken; jwt-bearer grant で Cognito ID Token を渡すと、IdC はそのクレームから IdC ユーザーを特定し、IdC Access Token を返します。 ここで 2 つの補足があります。 Cognito JWT と IdC Access Token は別物です。 発行者が違い（Cognito vs IdC）、形式も違います（JWT vs 不透明トークン）。Cognito JWT は Cognito 連携アプリでしか通用しませんが、IdC Access Token は IdC の Trusted Identity Propagation（TIP） に対応した AWS サービスで通用します。TIP は、IdC ユーザーのアイデンティティを IAM ロールの STS セッションに identity context として伝播させる仕組みです。DataZone は TIP 対応サービスの 1 つで、 RedeemAccessToken はその入口に位置します。 CreateTokenWithIAM と RedeemAccessToken は、このトークンの世界をまたぐブリッジの役割を果たします。 ただし本サンプルでは、TIP の identity-enhanced session をそのままデータ層まで持ち込んで Lake Formation や S3 Access Grants に評価させる構成は採っていません。SageMaker Catalog の Publish/Subscribe モデルが プロジェクトロール に行・列・オブジェクトレベルの権限を付与する設計になっているため、IdC ユーザーのアイデンティティは RedeemAccessToken → GetEnvironmentCredentials を経由してプロジェクトロールへ引き換えられ、以降のデータアクセスはプロジェクトロールの権限で評価されます。TIP の役割はこの引き換えの前段に限定され、本記事の焦点もそこにあります。 CreateTokenWithIAM には jti 制約があります。 JWT には jti （JWT ID）という一意識別子のクレームがあり、IdC は jwt-bearer grant で受け取った JWT の jti を記録します。同じ jti の JWT が再度送られると拒否されるため、同一の Cognito ID Token で CreateTokenWithIAM を 2 回呼ぶことはできません。このため、chat-agent で 1 リクエストあたり 1 回だけ実行し、得られた IdC Access Token を x-idc-access-token カスタムヘッダーで AgentCore Gateway 経由で全 Tool Lambda に伝播する設計になっています。 なお、 CreateTokenWithIAM を呼ぶための IAM アクション名は sso-oauth:CreateTokenWithIAM です。SDK クライアントは SSOOIDCClient を使いますが、IAM ポリシー側のサービス名は sso-oauth になります。また、IdC の OAuth Customer Managed Application に datazone:domain:access スコープを事前に登録しておく必要があります。 Step 3: Tool Lambda が IdC Access Token を DomainExecutionRole の認証情報に引き換える Tool Lambda が Amazon DataZone の RedeemAccessToken エンドポイントに HTTP POST を投げます。 const redeemRes = await fetch( `https://datazone.${region}.api.aws/sso/redeem-token`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ domainId, accessToken: idcAccessToken }), }, ); const { credentials: domainExecRoleCreds } = await redeemRes.json(); RedeemAccessToken は AWS SDK に含まれていません。 公開ドキュメントでは Athena JDBC ドライバ経由の利用例（ Analyze subscribed data via JDBC ）が示されていますが、サーバーサイドアプリからの直接呼び出しは生の HTTP リクエストで行う必要があります。このため、エンドポイント URL も通常の DataZone SDK が使う datazone.{region}.amazonaws.com ではなく datazone.{region}.api.aws を指定します。 この API には 2 つの特徴があります。SigV4 署名が不要であること（認証は IdC Access Token 自体が行う）、そして jti 制約がないため並列の Tool 呼び出しで複数の Lambda が同じ IdC Access Token を使っても問題ないことです。 返ってくるのは DomainExecutionRole の一時認証情報（ accessKeyId / secretAccessKey / sessionToken / expiration ）です。DomainExecutionRole は SageMaker Unified Studio ドメインに紐付く IAM ロールで、この認証情報には IdC ユーザーのアイデンティティが紐付いています 。内部的には、 RedeemAccessToken が DomainExecutionRole を assume する際に、Step 2 で触れた TIP の仕組みにより STS セッションに IdC ユーザーの identity context が埋め込まれます。これが次のステップで効いてきます。 Step 4: Tool Lambda が DomainExecutionRole の認証情報でプロジェクトロールを取得する Tool Lambda が Amazon DataZone SDK を DomainExecutionRole の認証情報で 初期化し、 GetEnvironmentCredentials を呼びます。 const envCreds = await new DataZoneClient({ region, credentials: domainExecRoleCreds, }).send( new GetEnvironmentCredentialsCommand({ domainIdentifier: domainId, environmentIdentifier: environmentId, }), ); Amazon DataZone は呼び出し元の STS セッションから identity context を取り出し、IdC ユーザーを特定します。そのユーザーがプロジェクトのメンバーであれば、プロジェクトロールの一時認証情報を返します。メンバーでなければ拒否されます。 ここが本サンプルの核心です。DomainExecutionRole の認証情報で呼ぶからこそ、 ユーザー本人のメンバーシップ で認可が評価されます。もし Lambda 実行ロールで直接 GetEnvironmentCredentials を呼んでいたら、Lambda 実行ロール自身のメンバーシップで判定されてしまい、ユーザーごとの権限差が消えます。 Step 5: プロジェクトロールで Athena / S3 を呼び出す Tool Lambda が Athena や S3 のクライアントを プロジェクトロールの認証情報で 初期化し、クエリやオブジェクト取得を実行します。 const athena = new AthenaClient({ region, credentials: { accessKeyId: envCreds.accessKeyId, secretAccessKey: envCreds.secretAccessKey, sessionToken: envCreds.sessionToken, }, }); Athena がクエリを実行すると、Lake Formation がプロジェクトロールの権限に基づいて行・列レベルのフィルタリングを透過的に適用します。ユーザーの権限の範囲内にある行と列だけが結果として返り、範囲外の情報は応答に含まれません。 ステップのまとめ Step 主体 API 入力 出力 1 ブラウザ → Runtime POST /invocations — Cognito Access Token + ID Token（Runtime に到達） 2 chat-agent → IdC CreateTokenWithIAM Cognito ID Token IdC Access Token 3 Tool Lambda → DataZone RedeemAccessToken IdC Access Token DomainExecutionRole 認証情報 4 Tool Lambda → DataZone GetEnvironmentCredentials DomainExecutionRole 認証情報 プロジェクトロール認証情報 5 Tool Lambda → Athena/S3 StartQueryExecution / GetObject 等 プロジェクトロール認証情報 クエリ結果 / オブジェクト Step 5 の S3 アクセスは Publisher と Subscriber で経路が分かれます。後述の「Publisher と Subscriber で異なる S3 アクセス方式」で詳述します。 この設計では、 Lambda 実行ロールはデータアクセスに一切使いません 。権限判定はすべてユーザーに紐付いた認証情報で行われます。 Policy in AgentCore によるツール単位認可 認証情報変換フローはデータアクセスの認可を扱いますが、「どのユーザーがどのツールを呼べるか」という別軸の認可も必要です。AgentCore の認可モデルは、 Inbound（ユーザー → AI エージェントへの入口） と Outbound（AI エージェント → ツールへの出口） の 2 軸で整理されます。Inbound は AgentCore Runtime の JWT Authorizer が Cognito Access Token を検証して「この呼び出し元はエージェントを呼んでよいか」を判定します。Outbound はツール単位の認可で、本サンプルでは AgentCore Gateway の Policy in AgentCore で実現しています（下図）。 グループ情報の埋め込み 壁 2 で述べた通り、IdC と Cognito を SAML フェデレーションで連携する構成では、IdC 側のグループ情報は Cognito トークンに自動的には含まれません。本サンプルでは、 Amazon Cognito の Pre token generation Lambda trigger の V2 イベントを使い、Cognito Access Token に cedar_groups カスタムクレームを埋め込みます。値は |data-producers|security-auditors| のようにパイプ区切りの文字列です。 Cedar ポリシーによる評価 Policy in AgentCore では、Cedar 言語で記述されたポリシーを policy engine に登録し、それを AgentCore Gateway に関連付けます。Gateway にリクエストが到達すると、policy engine が Cognito Access Token の cedar_groups クレームを読み取り、Cedar ポリシーで評価します。Gateway はリクエスト時点で JWT のクレームを AgentCore::OAuthUser エンティティのタグとして Entity Store に格納するため、ポリシー上は principal.getTag("cedar_groups") のようにタグとして参照します。「JWT では cedar_groups クレーム、Cedar ポリシーでは cedar_groups タグ」という名前の対応関係です。 permit( principal is AgentCore::OAuthUser, action, resource == AgentCore::Gateway::"<gateway-arn>" ) when { principal.hasTag("cedar_groups") && principal.getTag("cedar_groups") like "*|security-auditors|*" && (action == AgentCore::Action::"cloudtrail-query___cloudtrail_query") }; このポリシーは「 security-auditors グループに属するユーザーだけが cloudtrail_query ツールを呼べる」ことを宣言しています。アクション名の cloudtrail-query___cloudtrail_query は、AgentCore Gateway が MCP ツール定義から自動生成する命名で、 ターゲット名（ cloudtrail-query ） ___ ツール名（ cloudtrail_query ） の形を取ります。 Cedar の policy engine は default-deny （明示的に許可されない限り拒否）で動作します。上記の 1 本のポリシーだけでは security-auditors 向けの 1 ツールしか許可されていないため、他のユーザー・他のツールはすべて拒否されます。同様のポリシーを複数定義することで、たとえばデータコンシューマーには athena_query と s3_read のみを許可し、データプロデューサーにはカタログ管理ツールも許可する、といった職務分離を実現できます。 Policy in AgentCore によるツール単位認可と、認証情報変換フローによるデータアクセス認可は独立した 2 つの軸です。Gateway で「このユーザーはこのツールを呼んでよいか」を判定し、Tool Lambda で「このユーザーはこのデータを見てよいか」を判定します。 Publisher と Subscriber で異なる S3 アクセス方式 非構造化データ（S3 上のファイル）へのアクセスは、プロジェクトの役割によって経路が異なります。Amazon S3 Access Grants は、S3 の prefix / bucket / object 単位で IAM プリンシパルやディレクトリユーザーに READ/WRITE/READWRITE 権限を付与する仕組みで、 GetDataAccess API で当該対象への一時認証情報を取得してから S3 API を呼ぶ形で利用します。SageMaker Catalog の Publish/Subscribe は、この Grant を Subscriber のプロジェクトロールに対してのみ自動作成する 設計です。Publisher 側のプロジェクトロールには明示的な Grant が作られず、Publisher は別のパス（IAM ポリシーによる直接アクセス）でバケットを読みます。これが Publisher/Subscriber で経路が分かれる理由です。 Publisher（プロジェクトがバケットを所有する場合）: プロジェクトロールの認証情報で直接 S3:GetObject を呼びます。アクセス権は、プロジェクトロールに付与された IAM インラインポリシー（プロジェクト配下のプレフィックスに限定）によって許可されます。Publisher プロジェクトロール自身への明示的な S3 Access Grants の Grant は存在しないため、 GetDataAccess は失敗します。 Subscriber（別プロジェクト経由で購読する場合）: SageMaker Unified Studio の Publish/Subscribe が Subscriber ロールに対して IAM タイプの Grant を自動作成します。Tool Lambda はまず S3Control:GetDataAccess で一時認証情報を取得し、その認証情報で S3:GetObject を呼びます。 判断ロジックは、コネクションの accessRole の有無とプロジェクトの所有関係で決まります。プロジェクトレベルのコネクションで accessRole があれば S3 Access Grants 経由、なければ直接アクセスです。 まとめと次のアクション 本記事では、AI エージェント経由のデータアクセスに SageMaker Catalog のアクセス制御を透過的に効かせる実装パターンを解説しました。 設定時と実行時の役割分担 を整理し、SageMaker Catalog / DataZone が設定を担い、Lake Formation / S3 Access Grants が実行時に認可を評価する構造を明確にする 認証情報変換フロー （ CreateTokenWithIAM → RedeemAccessToken → GetEnvironmentCredentials ）で、ユーザーに紐付いたプロジェクトロールの認証情報を Tool Lambda に届ける Policy in AgentCore で、ツール単位の認可をデータアクセス認可とは独立した軸で制御する Lambda 実行ロールはデータアクセスに一切使わず、権限判定はすべてユーザーに紐付いた認証情報で行われます。これにより、SageMaker Catalog で設定された行・列・オブジェクトレベルのアクセス権は、AI エージェント経由でも透過的に適用されます。 第 1 回 で紹介した拡張性（ゼロショット時系列予測のオンデマンド実行）も、本記事で解説した認可の仕組みに支えられています。アクセス制御されたデータを、追加の認証設計なしで Amazon SageMaker AI の推論エンドポイントに流し込めるのは、プロジェクトロールの認証情報が Tool Lambda の手元まで届いているからです。サンプルリポジトリの apps/gateway-tools/time-series-forecast/ と design/data-access-control.md で実装の詳細を確認できます。 高野 賢司 AWS のシニアソリューションアーキテクトとして、東海以西の製造業のお客様を中心に支援しています。Infrastructure as Code や AI 駆動開発を中心とした開発者ツールのエキスパートでもあり、 Kiro によって広がったソフトウェア開発の世界を楽しんでいます。

AI エージェントに本番データを分析させるには、単にモデルと API をつなぐだけでは足りません。認可、ビジネスデータカタログ、ドメイン知識の 3 要素が揃うことで、エージェントは組織のアクセス制御とデータ構造を尊重した形で動作できます。 本記事は、シリーズ「AWS における AI エージェント対応のデータ基盤」の第 1 回です。 Amazon SageMaker を使用したデータ分析エージェントの参照実装としてサンプルリポジトリ aws-samples/sample-sagemaker-agentic-analyst を公開しました。本記事ではこのサンプルを題材に、3 要素がどう組み立てられているかを俯瞰し、2 つのデモシナリオで実際の挙動を見ていきます。また、AI エージェント対応のデータ基盤でできることの例として、従来は個別のモデルトレーニングが必要だった時系列予測を、任意のデータかつゼロショットで実行する例も紹介します。認可の実装詳細は 第 2 回 で扱います。 aws-samples sample-sagemaker-agentic-analyst A demo application that demonstrates how fine-grained access controls configured in SageMaker Unified Studio are transparently enforced on data access through AI agents. ツールを配る時代から、データを返す時代へ 組織のデータを業務で活用したい場合、利用者はこれまで BI ツール、ダッシュボード、SQL エディタといったツールを使って、自分でデータにたどり着く必要がありました。「先月の関西エリアの売上の前年同月比を見たい」と思ったら、ダッシュボードを開き、フィルタを設定し、数値を読み取ります。慣れていない利用者は、ツールの使い方を覚えるところから始めなければなりません。 AI エージェントがあれば、要求の形が変わります。利用者はチャット UI に「先月の関西エリアの売上の前年同月比を見せて」と依頼すれば、エージェントが利用者の権限を代行してデータを取得し、集計し、結果を返します。利用者はツールの操作を学ぶ必要はありません。必要なのは、何を知りたいかを言葉で伝えることだけです。 この変化を成立させる要素は 3 つあります。 第 1 に、認可がデータ層で効いていること。 エージェントは利用者本人の権限でデータを取得する必要があります。例えば「 AWS Lambda の実行ロールに全てのデータへのアクセス権を与え、利用者が見てよい範囲は LLM に判断させる」という仕組みは成立しません。システムプロンプトはユーザーからの指示によって上書きされる可能性があるからです。このため、アクセス制御は LLM の外側、データ層で効かせる必要があります。行・列・オブジェクトレベルのアクセス制御は、データ層で宣言的に設定され、利用者を特定した認証情報でクエリが実行されなければなりません。 第 2 に、データがカタログ化され、エージェントから発見可能であること。 エージェントは組織のどこにどんなデータがあるか知らなければ、正しいクエリを実行できません。エージェントのコンテキストウィンドウをあふれさせる前に、的確にデータを発見するための仕組みが必要です。 第 3 に、ドメイン知識がエージェントに届くこと。 同じ「アクティブユーザー」という語でも、組織ごとに定義が違います。「週次レポートでは前週比と前年同週比を併記する」といった分析パターンも組織ごとに異なります。こうした文脈をエージェントに渡す方法がないと、一般的には正しいが組織の文脈と合わない回答や、あるいはもっともらしく見える誤ったデータを返す可能性があります。 本記事で紹介するサンプルは、これら 3 要素を Amazon SageMaker Catalog 、 Amazon Bedrock AgentCore 、 AWS Lake Formation 、 Amazon S3 Access Grants の組み合わせで実装しています。 AI エージェント対応のデータ基盤の 3 要素 3 要素がサンプルでどのように実装されているかを表にまとめます。 要素 役割 本サンプルでの実装 認可 触ってよいデータ・使ってよいツールを制御する SageMaker Catalog（AWS Lake Formation + Amazon S3 Access Grants）で設定された行・列・オブジェクトレベルのアクセス権が、エージェント経由のデータアクセス時にも透過的に評価される。ツール単位の認可は、エージェントからツールへのリクエストを仲介する Amazon Bedrock AgentCore Gateway 上で、 Policy in Amazon Bedrock AgentCore により管理する ビジネスデータカタログ どこにどんなデータがあるかを発見させ、正しいデータに導く SageMaker Catalog をエージェントから検索・参照できるツール（ catalog_search / catalog_detail ）として提供する。Publish/Subscribe モデルと整合する ドメイン知識 組織固有の語彙・パターン・嗜好を注入する SageMaker Catalog のアセット説明・ビジネス用語集を通じて、組織のデータ資産そのものがエージェントのドメイン知識源になる。 Amazon Bedrock AgentCore Memory がチャット履歴を担当する 認可: 宣言的な設定を透過的に適用する Amazon SageMaker Catalog は、データと AI の発見・ガバナンス・コラボレーションを担うサービスで、 Amazon DataZone の上に構築されています。データプロデューサーがテーブルやファイルを Publish し、データコンシューマーが Subscribe することで、プロジェクト単位の権限が宣言的に設定されます。 このデータ層の認可では、 権限を設定する場所と、権限が適用される場所が分離されている のが特徴です。設定は SageMaker Catalog 上で Publish/Subscribe モデルに沿って行い、実際のアクセス制御はクエリ実行時に別のサービスで適用されます。行・列レベルのフィルタリングは、データレイクに対するきめ細かなアクセス制御を担う AWS Lake Formation が適用します。S3 オブジェクトへのアクセスは、利用者・グループ単位で管理する Amazon S3 Access Grants が適用します。 AI エージェントがデータアクセスするときも、同じ認可設定がそのまま効きます。エージェントの内部にアクセス制御ロジックを書く必要はありません。利用者が SageMaker Catalog で付与されている権限が、エージェント経由のアクセスに対しても同じように評価されます。具体的な実装パターン（ブラウザのログインセッションから Tool Lambda の手元までプロジェクトロールの一時認証情報を運ぶ仕組み）は 第 2 回 で扱います。 ツール単位の認可は別軸で必要になります。たとえばセキュリティ監査ロールには CloudTrail 検索ツールだけを許し、データコンシューマーには Athena クエリと S3 読み取りだけを許す、といった職務分離です。本サンプルでは、Policy in Amazon Bedrock AgentCore により、AgentCore Gateway に接続されたツールの実行がグループベースのポリシーで制御されます。 ビジネスデータカタログ: エージェントから発見可能にする SageMaker Catalog は UI から人間が検索するだけのものではありません。本サンプルでは、エージェントがツール経由で検索・参照できるよう、以下の Tool を独自に実装して AgentCore Gateway 経由で提供しています。 catalog_search : 自然言語クエリやキーワードでアセットを検索する catalog_detail : 特定アセットの詳細（スキーマ、説明、ビジネス用語集との関連）を取得する エージェントは、利用者の問いに応じてまずカタログを検索し、適切なテーブルを特定してからクエリを組み立てます。検索は Subscribe 済みアセットに絞り込むか、カタログ全体を対象にするかを選べます。Subscribe 済みに絞ると回答は利用者の現在の権限で得られる範囲に限定されます。一方、全体検索では Subscribe していないアセットも「未購読」として識別できるため、必要であれば利用者に Subscribe 申請を促すこともできます（デモ 2 で扱います）。いずれの場合も、実際のデータアクセスは利用者本人の権限で実行されるため、Subscribe していないアセットのデータを勝手に読むことはできません。 ドメイン知識: データ資産に書き込む ドメイン知識には、組織内で共有されるものと、利用者個人に紐付くものがあります。本サンプルでは、それぞれを注入できるパスを以下のように整理しています。 種類 注入できるパス 組織固有の語彙・定義（例: 「アクティブユーザー」の定義） SageMaker Catalog のアセット説明・ビジネス用語集。データプロデューサーが Publish 時に書き込むと、そのままエージェントが参照できる 分析パターン・クエリテンプレート（例: 月次売上では必ず前年同月比も出す） システムプロンプトへの注入、SageMaker Catalog のアセット説明への記述、Agent Core Memory のセマンティック検索 利用者個人の嗜好・履歴（例: 関西エリアの分析をよく頼む） AgentCore Memory の長期記憶 ポイントは、カタログのメタデータだけでは似たテーブルを区別できない場面が多いことです。たとえば sales_daily と sales_fact がどちらも売上を表していても、一方は速報値で一方は確定値かもしれません。この違いを自然言語でアセット説明に書き込めば、エージェントは正しいテーブルを選べます。ドメイン知識をデータ資産そのものに書き込む文化が、エージェントの回答品質を左右します。 補足: SQL 生成とセマンティックレイヤー AI エージェントにデータ分析を任せる際のアプローチは、大きく 2 つに整理できます。1 つは本サンプルのようにエージェントが SQL を直接生成する方法（Text-to-SQL）、もう 1 つは事前に定義したメトリクスと次元を持つセマンティックレイヤーを通じて問い合わせる方法です。前者は任意の問いに柔軟に応答でき、後者は正確性と決定性が必要な分析を安定して返せます。どちらが優れているというより、組織のデータ成熟度と用途で使い分けるのが現実的です。 本サンプルのアーキテクチャは、どちらのアプローチにも寄せられる構造を持ちます。Amazon Bedrock AgentCore Gateway は任意のツールを AWS Lambda 上で実装して接続できるため、 athena_query のような汎用的な SQL 実行ツールと、 sales_monthly_metric のように事前にパラメータ化されたツールを、同じエージェントに共存させられます。広いカバレッジを Text-to-SQL で取りつつ、よくあるユースケースや間違えてはいけない分析だけをセマンティックレイヤー相当のツールとして事前定義する、という運用も組めます。SageMaker Catalog のアセット説明・ビジネス用語集は、どちらのアプローチでもドメイン知識の伝達路として使えます。 デモ 3 要素がどう協調して動くかを、2 つのシナリオで見ていきます。 デモ 1: 構造化データと非構造化データを束ねて分析する 営業分析担当者が「店舗別の売上傾向を知りたい」と問いかけるところから始まります。 エージェントはまず SageMaker Catalog を検索し、売上テーブルを見つけます。利用者本人の権限で Amazon Athena にクエリを投げ、店舗別の集計を取得します。 Amazon Bedrock AgentCore Code Interpreter で集計結果を可視化し、グラフと短い解釈を返します。ここで効いている要素は次の通りです。 ビジネスデータカタログ : 利用者はテーブル名を知らなくてよい。エージェントがカタログから探す 認可 : クエリは利用者本人の権限で実行される。Subscribe していないアセットはエージェントが検索で「未購読」と判別できる ドメイン知識 : 「店舗別の売上傾向」という問いを、適切な集計粒度に落とし込む 続いて利用者が「既存の製品カタログを読んで、製品ごとのトレンドを分析して」と依頼します。ここでは、品番は売上テーブルにありますが、品名や製品説明はテーブルには含まれておらず、 Amazon S3 上のテキストファイル（製品カタログ）にしかないという状況です。 エージェントは S3 からテキストファイルを取得し、そこに書かれた品名・説明と売上データを突き合わせて、製品カテゴリごとのトレンドを分析します。構造化データ（Athena / Lake Formation）と非構造化データ（S3 / S3 Access Grants）を同じ会話の中で束ねられるのは、どちらも利用者本人の権限で取得しているからです。 デモ 2: 権限のないデータへのアクセスを、エージェントが仲介する もう 1 つのシナリオは、データへのアクセス権がまだない状況から始まります。利用者が「B2B 商談パイプラインの状況を教えて」と問いかけます。 カタログには B2B 商談データがありますが、利用者のプロジェクトはまだ Subscribe していません。エージェントはデータにアクセスできないことを伝え、利用者の指示に従って SageMaker Catalog に Subscribe 申請を出します。申請自体をエージェントが Amazon DataZone の API 経由で実行します（上のスクリーンショット）。 次に、データ所有者の操作に移ります。データ所有者は Amazon SageMaker Unified Studio にログインし、届いている Subscribe 申請を確認して承認します。 利用者の画面に戻ります。同じチャットセッションで「承認されました」と伝えると、エージェントは再度データアクセスを試み、今度は成功します。B2B 商談パイプラインの分析と可視化が提示されます。 このシナリオの注目点は、利用者が SageMaker Catalog の UI を直接触らなくても、既存の Publish/Subscribe モデルに乗ってデータアクセス権の申請と取得ができることです。データガバナンスの仕組みはそのまま維持され、利用者体験だけがチャット UI に統合されます。 デモで起きていること どちらのデモでも、データ取得は利用者本人の権限で実行されています。AWS Lake Formation が行・列レベルのアクセス制御を、Amazon S3 Access Grants がオブジェクトレベルのアクセス制御を、クエリ実行時にプロジェクトロールの認証情報に対して評価します。利用者が Subscribe していないアセットには、エージェントもアクセスできません。デモ 2 で Subscribe 申請が承認されるまでデータが返らなかったのは、その評価がエージェント経由のアクセスにも同じように効いている証拠です。 どの利用者がどのロールで何を見たかは、すべて AWS CloudTrail に記録されます。Lambda の実行ロールは監査ログのデータアクセスに登場しません。プロジェクトロールの一時認証情報でクエリが実行されているからです。 サンプルの拡張例: ゼロショット時系列予測をオンデマンドで 3 要素（認可、ビジネスデータカタログ、ドメイン知識）が揃ったデータ基盤の上には、分析以外の高度な機能もオンデマンドで組み込めます。ここでは一例として、本サンプルに含めているゼロショット時系列予測を紹介します。 従来、時系列予測モデルを使うには、データ準備、特徴量設計、モデル学習、評価、運用という長いサイクルが必要でした。系列ごとに個別のモデルをトレーニングするコストは、適用対象を限定する要因になっていました。近年登場したゼロショット予測モデル（本サンプルでは Chronos-2 ）は、新しい系列に対する追加学習なしに実用精度の予測を返します。このモデルを Amazon SageMaker AI の推論エンドポイントでホストし、エージェントのツール（ time_series_forecast ）として公開することで、利用者は任意のテーブルに対して「来月の売上を予測して」と依頼するだけで予測結果とグラフを受け取れます。 このツール 1 つで、本サンプルの世界観は次のように広がります。 利用者が SageMaker Catalog で Subscribe した売上・在庫・トラフィック等のテーブルに対して、学習プロジェクトを立ち上げずに予測を実行できる エージェントがデータの取得から集計、予測、可視化までを一連の会話の中で扱う。Amazon Athena で取得したデータはそのまま Chronos-2 の推論エンドポイントに渡され、AgentCore Code Interpreter で fan chart として描画される アクセス制御はデータ取得の段階で効いているため、予測対象になるのは利用者が見てよい系列だけに自動的に限定される 個別のトレーニング基盤を用意せずに、アクセス制御されたデータの上で時系列予測を提供できる点が、この組み合わせの面白さです。実装の詳細（Chronos-2 の系列フォーマット、前処理の難しさ、AgentCore Code Interpreter 側の描画仕様）は、サンプルリポジトリの apps/gateway-tools/time-series-forecast/ と apps/chat-agent/src/prompt.ts を参照してください。 考慮事項 コスト 本サンプルの固定費は月数ドル程度です。大半を占めるのは Amazon Bedrock のモデル推論の従量課金で、利用量に依存します。具体的な試算はサンプルリポジトリの docs/ 配下に掲載しています。AWS 無料利用枠の範囲で動く部分も多く、低コストで検証を始めることができます。 既存データレイクへの適用 既存の S3 / Redshift データレイクを、作り直さずに本サンプルと同じ構造に組み込めます。対象のテーブルやデータセットを SageMaker Catalog で管理するようにし、Publish/Subscribe を設定することで、エージェント経由のアクセスを追加できます。データのメタデータ整備や Publisher/Subscriber の役割分担、運用ポリシーの設計は、組織のデータガバナンス方針に沿って進めます。 デプロイ手順の概要 読者が自分で動かせるよう、手順の全体像を示します。詳細は リポジトリの README を参照してください。前提として、 AWS IAM Identity Center （以下 IdC）の組織インスタンスが必要で、SageMaker Unified Studio ドメインは AWS マネジメントコンソールから作成する必要があります。 まとめと次のアクション AI エージェントが組織の本番データで動くには、認可、ビジネスデータカタログ、ドメイン知識の 3 要素が揃う必要があります。本サンプルは、これらを Amazon SageMaker Catalog、Amazon Bedrock AgentCore、AWS Lake Formation、Amazon S3 Access Grants の組み合わせで実現しています。既存のデータレイクを作り直すことなく、SageMaker Catalog で管理する形に組み込んで AI エージェントに接続できます。 ツールを配る時代から、データを返す時代へ。次のアクションとして、以下を検討してください。 試す : GitHub リポジトリ を参照してデプロイし、3 つの IdC ユーザーで権限ごとに異なる回答が返ることを確認する 自社に当てはめる : 既存の S3 / Redshift データレイクを SageMaker Catalog で管理する形に組み込めるかを検討する。具体的には、対象テーブルの洗い出しと、Publisher/Subscriber の役割分担の設計から着手する 仕組みの理解を深める : 第 2 回「SageMaker Catalog で行・列レベルのアクセス権を透過的に適用する」 で、認可の実装パターンを追う 高野 賢司 AWS のシニアソリューションアーキテクトとして、東海以西の製造業のお客様を中心に支援しています。Infrastructure as Code や AI 駆動開発を中心とした開発者ツールのエキスパートでもあり、 Kiro によって広がったソフトウェア開発の世界を楽しんでいます。

technical how本記事は 2026 年 5 月 13 日 に公開された「 Sim-to-Real and Real-to-Sim: The Engine Behind Capable Physical AI 」を翻訳したものです。 はじめに 現実世界で知覚・推論・行動するロボット、いわゆる Physical AI システムの進化が加速しています。その中心にあるのが Sim-to-Real パイプラインです。しかし、実験室の外でも安定して動作するモデルの構築は、この分野で最も難しい課題の一つです。シミュレーションで機能するものと実際のハードウェアで機能するものの間にあるギャップこそ、多くのプロジェクトが行き詰まる原因です。 本記事では、Sim-to-Real (Sim2Real) と Real-to-Sim (Real2Sim) が、物理環境で動作する AI モデル構築において最も重要な技術となった理由を解説します。シミュレーションと現実のギャップがなぜ埋まりにくいのか、現代的なアプローチでどう克服するのか、そしてロボティクスをけん引する Vision Language Action モデル (VLA) がこのパイプラインの品質に全面的に依存している理由についても説明します。 実世界のデータだけではスケールしない理由 ロボットに操作タスクを学習させるには、照明・物体の位置・表面テクスチャ・グリッパーの向きといった条件を横断して汎化するために、通常数万件のデモンストレーションが必要です。それを実機で実施するのは時間もコストもかかり、リスクも伴います。 この制約はあらゆる分野に共通します。倉庫の自動化では通常、数千種類の SKU バリエーションへの対応が必要です。自動運転車は通常、数百万件の走行シナリオを必要とします。手術ロボットは、実際の患者で倫理的にリハーサルできない処置を扱います。必要な規模での物理的なデータ収集は、現実的に不可能です。 シミュレーションはこの課題に直接対処します。物理的に正確な仮想環境では、通常、はるかに低コストで安全な環境から桁違いの速さでトレーニングデータを生成できます。ただし、純粋にシミュレーションで学習したモデルは、常に変化し予測不可能な物理環境での動作という性質上、実世界に展開すると失敗しがちです。この失敗パターンには名前があります。シミュレーションと現実のギャップ、すなわち「リアリティギャップ」です。 シミュレーションと現実のギャップ シミュレーションと現実のギャップとは、シミュレーションで学習したモデルを実機に展開したときの性能差のことです。シミュレーションはあくまで近似であるため、このギャップは避けられません。実際のカメラはノイズ・歪み・露出変動をもたらしますが、合成レンダリングはデフォルトではそれを再現しません。実際の表面には、どの物理エンジンも完全にはモデル化できない摩擦係数があります。実際のアクチュエータにはバックラッシュ・遅延・熱ドリフトがあります。クリーンな合成データで学習したモデルはシミュレーションの完全性を利用することを覚えてしまい、その挙動は現実には転用できません。 ギャップを埋めるには、二つの補完的なアプローチが必要です。 シミュレーション精度の向上 NVIDIA Isaac Sim のような現代の物理シミュレーターは、剛体ダイナミクス・変形可能物体・流体挙動・接触力を、数年前には実現できなかったレベルの精度でモデル化します。パストレーシングと物理ベースマテリアルを用いたフォトリアリスティックなレンダリングにより、実際のカメラ映像との区別がますます難しい視覚入力が生成されます。 Figure 1: Amazon EC2 G6e.4xlarge インスタンス上で動作する NVIDIA Isaac Sim ドメインランダム化　 単に一つのシミュレーションを完全に正確にするのではなく、多数のランダム化されたバリエーションにわたって学習します。照明・テクスチャ・物体の質量・関節摩擦・センサーノイズを変化させることで、幅広い条件の分布に対してロバストなポリシーを学習します。重要なのは、純粋なデータ量ではなく、シミュレーションパラメータの十分な多様性とカバレッジです。これにより、ニューラルネットワークは多様な環境において、対象物のキーとなる要素を識別することを学習します。 Figure 2: OpenAI が実証した、ルービックキューブを解くロボット。(出典: OpenAI, https://openai.com/index/solving-rubiks-cube/) Real-to-Sim: 物理世界をトレーニングインフラに変える Real-to-Sim とは、現実の環境をキャプチャしてシミュレーション対応のデジタル表現に変換するプロセスです。Sim2Real が学習済みポリシーを実機に転用することを目的とするなら、Real2Sim はそのシミュレーションがハードウェアの実際の動作環境を反映することを保証するためのものです。 使用される技術は複数の分野にまたがります。LiDAR スキャンとフォトグラメトリーは、3D メッシュに処理できる点群を生成します。 Neural Radiance Fields (NeRF) と 3D Gaussian Splatting は、通常のカメラ映像からシーンのジオメトリと外観を再構築し、物理シミュレーション環境に直接取り込めるアセットを生成します。これはリアリティギャップ、すなわち仮想アセットと物理アセットのモデル化における性能差の解消に役立ちます。これらのアセットは、多様な照明条件やカメラアングルにわたって現実の見た目や質感を保持する技術を用いて仮想世界に取り込まれます。 Physical AI のトレーニングパイプラインにおいて、Real2Sim は 遠隔操作によるデータ収集 で特に重要な役割を果たします。人間のオペレーターがデモンストレーションインターフェースを通じて物理的なロボットアームを操作すると、システムはその動きをシミュレーション上のデジタルツインに同時にミラーリングします。これにより現実世界で記録された人間品質のデモンストレーションデータセットと、同じタスクの追加的な合成バリエーションを生成できる同期済みシミュレーショントレースという二つのデータを同時に得られます。。 Figure 3: SO-101 を使ったテレオペレーション このアプローチが実用的な加速手段となるのは、 模倣学習 の中心的なボトルネックに対処しているからです。模倣学習とは、報酬ベースの試行錯誤ではなく人間のデモンストレーションを観察することでロボットが学習する枠組みです。高品質な人間のデモンストレーションは模倣学習が依存するトレーニングシグナルであり、Real2Sim インフラを活用することで、物理ハードウェアのコストを比例的に増やすことなくそのシグナルをスケールできます。 合成データの生成とフィルタリング 実世界およびテレオペレーションで収集したデータは分布に沿った教師信号を提供します。つまり、トレーニングサンプルがロボットの展開時に実際に直面する条件 (照明・物体の種類・カメラアングル) を反映しています。シミュレーションはスケールを提供します。現代の Physical AI トレーニングパイプラインはこの二つを組み合わせます。 合成データ生成とは、シミュレーション環境内でラベル付きトレーニングサンプルをプログラム的に大規模生成することです。操作タスクでは、異なる物体姿勢・照明条件・グリッパー構成にわたって把持シナリオの数千バリエーションをレンダリングし、それぞれに深度・セグメンテーションマスク・アクションラベルのグラウンドトゥルースを自動アノテーションします。 データ量だけでは不十分です。フィルタリングパイプラインは、自動品質メトリクスと学習済み識別器を使って、分布外または物理的に不自然なサンプルをトレーニングセットに入る前に除去します。適切に構築されたパイプラインの出力は、実際のデモンストレーションによる物理的な根拠、合成生成の規模、および自動フィルタリングによる品質管理を備えたトレーニングデータセットとなります。 VLM・VLA と、シミュレーション品質がモデル性能を決める理由 Physical AI チームがロボット制御の基盤レイヤーとして注目しているモデルが、Vision Language Model (VLM) と Vision Language Action モデル (VLA) です。 VLM は、大規模な画像とテキストのコーパスで学習したマルチモーダル基盤モデルです。幅広い視覚的理解で、画像内の内容を推論し、空間的な関係を説明し、物体を識別し、視覚的なコンテンツを参照する言語指示に従う能力を獲得します。 Amazon Bedrock 上の Amazon Nova 、Anthropic Claude、Qwen、Mistral などがこのクラスの例です。Amazon Bedrock は、基盤インフラを管理することなくこれらのモデルにアクセスするためのマネージド API レイヤーを提供します。これは、独自のインフラの複雑さを持つ Physical AI パイプラインに視覚的推論を統合する際に重要です。 VLA は、VLMのパラダイムを物理的な動作へと拡張したものです。VLAは、テキストを出力するのではなく、視覚的な観察と言語による指示に応じて、ロボットの動作、関節の位置、速度指令、エンドエフェクタの軌道などを生成します。VLAのトレーニング目標は、視覚的理解と物理的な因果関係の両方に基づいた方針を学習することです。つまり、「自分が見ているものと、自分がするように求められていることを踏まえて、どのような行動をとるべきか？」を学習します。 シミュレーションデータの品質は、VLAが明示的に学習されていないタスクに対してどれだけうまく汎化できるかを直接左右します。学習に使用した視覚ドメイン（合成レンダリング）が展開ドメイン（現実世界）と一致しない場合、学習されたポリシーは破綻し、ぎこちない動作制御、タスクの失敗、ポリシー評価の精度低下といったパフォーマンス上の問題が即座に発生します。ドメインランダム化は、高品質のベースデータセットを取り込み、それを拡張して、新しいオブジェクト、異なる照明条件や色を持つ環境などを含むさらに高品質のデータセットを生成することで、ポリシーの堅牢性を高めます。高忠実度物理演算により、動作出力が物理的に意味のあるものとなることが保証されます。 合成データパイプラインは、実際のデモンストレーションだけではカバーできないタスク分布、まれな障害モード、エッジケース構成、そしてまだ物理的に存在しない環境に対してVLAを学習させることを可能にします。 産業への応用 このパイプラインが最も即効性のある価値をもたらす業界には、ある共通の特徴があります。それは、物理的な環境がリスクが高く、変化に富み、直接学ぶには費用がかかったり危険を伴ったりするという点です。 製造業 では、倉庫自動化システムが SKU のバリエーション・梱包の損傷・フロアレイアウトの変化に対応する汎化能力を必要とします。Real2Sim キャプチャがシミュレーショントレーニングに供給され、Sim2Real 転用により実世界のバリエーションに耐えるポリシーが生成されます。 自動車業界 では、自動運転システムは通常、実世界では安全に再現できない数百万件のエッジケースシナリオにわたるトレーニングを必要とします。 医療分野 では、手術や患者ケアへの応用が厳格な安全規制上の制約を受けます。高精度なシミュレーションにより、患者への接触なしにモデルのトレーニングと検証を進められます。 エネルギー・公益事業 では、点検用の自律ロボットが変電所・パイプライン・風力発電所など、人間が立ち入ることに実際の身体的リスクを伴う環境で稼働します。 小売業界 では、自律型フルフィルメントシステムは、絶えず変化するレイアウトの中で膨大な種類のSKU（在庫管理単位）に対応しなければなりません。数千種類もの製品バリエーションにわたるトレーニングデータを生成するシミュレーションこそが、生産規模での汎用化を実現する唯一の現実的な方法です。 今後の展望 本記事では、Physical AIモデルを現実世界で動作させるためのコアエンジンであるSim2Real/Real2Simパイプラインの目的と内容について解説しました。本シリーズの次回記事では、LeRobot SO-101 AWS Sim2Real2Sim リファレンスプロジェクトのハンズオン技術解説を通じて、これらの概念を具体化します。AWS インフラストラクチャ・NVIDIA Isaac Sim・公開されている LeRobot プラットフォームを使ってエンドツーエンドで実装する、完全にデプロイ可能なアーキテクチャを紹介します。 まずは基盤モデルへのアクセスに Amazon Bedrock を、シミュレーションワークロードに最適化された Amazon EC2 G6e インスタンス をご確認ください。 <!-- '"` --> Dario Macagnano Dario Macagnano is a Physical AI Solutions Architect at AWS. With years of experience designing and deploying solutions spanning real-time simulation, digital twins, and edge inference — from rapid prototypes to large-scale production systems — Dario is passionate about the convergence of AI, robotics, and cloud infrastructure that brings intelligent systems into the physical world. Ignacio Sánchez Ignacio Sanchez is a Worldwide Specialist Solutions Architect for Physical AI in AWS, based in Madrid, Spain. He works with customers and partners globally to design and deploy AI solutions that bridge the digital and physical worlds, spanning spatial computing, robotics, and edge inference workloads on AWS. Ignacio is passionate about emerging technologies and their real-world applications. In his spare time, he enjoys reading, playing video games, and staying active through sports. Quinn Cheong Quinn Cheong is a Worldwide Specialist Solutions Architect for Physical AI at AWS, helping to shape the global Physical AI architectural strategy for the domain. Quinn’s expertise spans cutting-edge software development, and he has pioneered multiple solutions from World Generation and 3D Model Inferencing on Kubernetes, to creating WebXR augmented workers for AR Glasses. Quinn is also a seasoned AWS speaker, having presented at 30+ global events and summits. He is now focused on scaling Physical AI Infrastructure with Kubernetes and Agentic AI. 翻訳は Visual Compute SSA 森が担当しました。原文はこちらをご覧ください。

本ブログは 2026 年 3 月 20 日に公開された Amazon Science Blog “ Formally verified AES-XTS: The first AES algorithm to join s2n-bignum ” を翻訳したものです。 コア演算のアセンブリコードを単純化して明確化することで、自動最適化と検証が可能になりました。 暗号化アルゴリズムは、読み取り可能なデータをランダムなビットの並びのように見える暗号文に変換する数学的手続きです。暗号文は、対応する復号アルゴリズムと正しい鍵を使用したときにのみ復号できます。 保管中のデータ (ディスクやデータベースに保存される情報) に対しては、 AES-XTS のようなアルゴリズムが、ストレージに書き込まれる前に各ブロックを暗号化することで、物理的な盗難やストレージシステムへの不正アクセスから保護します。転送中のデータ (ネットワーク上を移動する情報) に対しては、TLS のようなプロトコルが複数のアルゴリズムを組み合わせて使用します。非対称暗号化アルゴリズム (RSA や楕円曲線) で安全な接続を確立し、高速な対称暗号化アルゴリズム (AES-GCM など) で実際のデータストリームを保護するとともに改ざんされていないことを検証します。Amazon Web Services (AWS) では、 EBS 、 Nitro Card 、DynamoDB などのサービスでお客様のデータを保護するために AES-XTS を使用しており、AES-GCM を用いた TLS によりサービス間およびお客様との通信を含むすべてのネットワーク通信を保護しています。 AWS は、AES-XTS 復号の最適化された Arm64 アセンブリ実装の形式的検証に挑戦しました。「形式的検証」とは、エンジニアリングされたシステムが特定の 仕様 を満たすことを数学的に証明するプロセスです。 本研究は、ブロック指向ストレージデバイスの暗号保護に関する IEEE 標準 1619 に従い、AES-XTS の AES-256-XTS バリアントに焦点を当てています。「256」は暗号化鍵のサイズを表します。 固定サイズのブロックを処理するアルゴリズムとは異なり、AES-XTS は 16 バイトから 16 メガバイトまでの可変長データを扱い、不完全なブロックには特別なロジックを使用します。検証されたアセンブリコードは 5 倍アンロール版で、ループが 5 つのレジスタ (それぞれが入力ブロックを格納) で並列実行されるように展開され、最新の CPU パイプライン向けに最適化されていました。エラーがあるとお客様データのセキュリティを損なう可能性がある重要なコードでありながら、手動レビューでは正当性を保証できないほど複雑でした。 Amazon Web Services の形式的に検証された大数演算ライブラリである s2n-bignum の一部として、AWS は改善された Arm64 アセンブリ実装による AES-XTS 暗号化と復号を提供するとともに、チームメンバー (John Harrison) が開発した HOL Light 対話型定理証明器を用いた仕様記述および形式的検証を行いました。 これは、入力長に応じて複数の経路を持つ大規模関数を対象とした証明駆動開発の実験でした。その結果、s2n-bignum ライブラリにおいてこれまでで最大規模の証明が完成しました。典型的な入力サイズである 512 バイトでは、アルゴリズムのパフォーマンスは元のコードと同等か、高度に最適化された Arm コアではわずかに向上しました。このアルゴリズムとその証明を s2n-bignum ライブラリに追加することで、より多くの AES ベースのアルゴリズムを追加する道が開かれます。 アルゴリズムの説明 AES は鍵付き置換を実装するブロック暗号です。つまり、平文ファイルをブロック (この場合は 128 ビットのブロック) に分けて処理し、任意の鍵に対して、各平文ブロックを一意の暗号文ブロックに対応付ける全単射 (一対一かつ可逆) 関数を定義します。この数学的性質により、復号によって元の平文を一意に復元できることが保証されます。 AES-XTS は、ストレージ暗号化のために特別に設計されたモードです。基盤となる構成要素として AES を使用しますが、ディスク暗号化の独自要件に対応するため、位置依存の tweak (調整値) と暗号文スティーリング (ciphertext stealing) (部分ブロックを処理する方法) を追加しています。ディスク暗号化では、任意のセクタへのランダムアクセスが必要であり、データサイズを正確に保つ必要があります。 AES-XTS は、2 つの鍵を使用するアプローチでストレージデータを暗号化します。各 128 ビットブロックとその位置依存の tweak は排他的論理和 (XOR、入力値が異なる場合のみ 1 を出力する二項演算) され、その結果が AES で暗号化され、再び tweak と XOR されます。これにより、ディスク上の異なる位置にある同一のデータが異なる暗号文を生成します。tweak は、セクタ番号を 2 番目の鍵で暗号化し、 ガロア体 で α のべき乗を掛けることで生成され、各ブロック位置に対して一意の値が作成されます。 最後のブロックが完全な 128 ビットでない場合、暗号文スティーリングが機能します。暗号文スティーリングは前のブロックからバイトを「借用」することで、パディングや無駄な領域なしに任意の長さのデータを暗号化できるようにします。これにより、各ブロックの暗号化を位置に基づいて行いながら、任意のセクタを独立して読み書きできます。これはディスク暗号化において重要な機能です。なぜなら、ディスク暗号化のセキュリティモデルでは、攻撃者が対象以外のセクタにアクセスし、それらを変更し、復号を要求することが許容されているためです。また、暗号文のサイズが平文と完全に同じになることも保証され、所定の場所に収まります。 XOR-暗号化-XOR (XEX) 構造を採用した AES-XTS 暗号化 暗号文スティーリングは、最後から 2 番目のブロックの出力を分割することで、暗号化中の部分ブロックを処理 対称復号プロセス 復号のための逆暗号文スティーリング アセンブリ実装の制御フロー AWS は、Amazon の AWS-LC 暗号ライブラリにある既存の AES-XTS 実装から開始しました。AES-XTS は平文を 128 ビットブロックでループ処理し、各ブロックの暗号化には 15 のステップが必要で、各ステップには暗号化鍵から導出された独自の「ラウンドキー」が使用されます。既存の実装は 5 倍アンロールされており、5 ブロックずつ並列で処理します。最後のブロックの長さが 128 ビット未満の場合、入力バッファの限界を超えて読み取る「バッファオーバーリード」のリスクがあります。 オーバーリードを回避するため、既存の実装では入力バッファ内の現在位置へのポインタに対して複雑な操作を行います。これには、追跡が困難な高度な制御フローが必要です。ループカウンタはループの前と途中で複数回インクリメントおよびデクリメントされ、ループには最終的なループバック分岐以外に 2 つの追加の出口点があります。 1 つの出口点は、ループの最終イテレーションで 4 ブロックが残っている場合のためのもので、もう 1 つの出口点は 1 ～ 3 ブロックが残っている場合のためのものです。ループのフローは、パイプラインの使用率を最大化するためにロード/ストア命令と AES および XOR 命令をインターリーブしています。ループ終了後、残りのブロックの処理は 4 から 1 までの長さに対して絡み合っており、最後に部分ブロックがある場合、アルゴリズムは暗号文スティーリング手順を実行します。さらに、15 個のラウンドキーのうち 7 つだけがレジスタに保持され、他の 8 つはループ内外でメモリから繰り返しロードされていました。 AWS はまず、Arm コード用のスーパーオプティマイザである SLOTHY に命令を再配置させてパイプラインの使用率を最大化することで、メインループのパフォーマンスを向上できるかを調査しました。SLOTHY には、さまざまな Arm マイクロアーキテクチャの簡略化されたモデルが含まれています。制約ソルバーを使用して、最適な命令スケジュール、レジスタリネーミング、および周期的なループインターリーブを提供します。 しかし、SLOTHY がループを識別して最適化するためには、ループは典型的なループの動作を示し、各イテレーションの最後にカウンタを減少させ、最初に戻る必要があります。SLOTHY はまた、8 つのラウンドキーをロードすることで作成されるネストされたループを処理できません。 これがループを「整理」し始める動機となりました。まず、すべてのラウンドキーを永続的に保持するためにレジスタを解放しました。これは、最適化された命令の順序が元のコードよりも少ない一時レジスタしか必要としなかったため可能でした。次に、複数の出口点と、残りのブロックを処理するためのループカウンタの操作を取り除きました。カウンタの値は常にバッファに残っている 5 ブロックチャンクの数を示し、SLOTHY の要件に適合します。ループは残りのブロックの処理の前に終了します。 ループが終了したら、1 から 4 までの残りブロック数のそれぞれを処理するための個別の処理ブランチを用意します。4 つのブランチはすべて暗号文スティーリングで終了します。これは、暗号化アルゴリズムと復号アルゴリズムの制御フローグラフ (下記参照) で確認できます。コード全体を通して、定数時間の設計思想を維持しました。つまり、分岐や特別な処理は秘密データではなく、入力バイト長などの公開値のみに基づいています。 AES-256-XTS 暗号化制御フローグラフ AES-256-XTS 復号制御フローグラフ パフォーマンス コードへの修正により、AWS は SLOTHY を使用して暗号化アルゴリズムを最適化できるようになりました。これにより AWS Graviton ファミリーの Arm プロセッサでわずかなパフォーマンス向上が得られましたが、最適化されたアウトオブオーダーパイプラインを持つより高度なチップでは、向上幅は小さくなりました。元の実装と比較して、アルゴリズムの実行を通じてラウンドキーをレジスタに保持しメモリからのロードを節約することで、AES 命令を他の命令とインターリーブしないことの影響を相殺できました。 ループ内の命令フローをよりクリーンにし、出口処理をモジュール化したことで、ループイテレーションのさまざまなアンロール係数を試すことができました。AWS は 3 倍、4 倍、6 倍の係数を実験し、さまざまなマイクロアーキテクチャにおいて 5 倍が依然として最良の選択であると結論付けました。 形式的検証による正当性の確保 最適化された暗号化コードを本番環境にデプロイするには、それが正しく動作することの数学的な確実性が必要です。ランダムテストでは単純なケースを素早くチェックできますが、AWS は AES-XTS 実装に対して最高レベルの保証を提供するために形式的検証を活用しています。 なぜ AES-XTS に HOL Light なのか? AWS の実装が IEEE 1619 仕様に一致することを証明するために、同僚の John Harrison が開発した対話型定理証明器である HOL Light を使用しています。HOL Light は、コードが書かれる際に検証される「構築による正当性」アプローチをソフトウェア開発に対して特に単純に実装したものです。HOL Light の信頼されたカーネルはわずか数百行のコードで、基本的な論理推論規則を実装しています。これは、証明戦術や自動化にバグがあったとしても、HOL Light が誤った証明を受け入れる原因にはなり得ないことを意味します。最悪の場合、バグによって証明を完了できなくなりますが、偽の命題を証明可能にすることはできません。 AWS が AES-XTS 検証に HOL Light を選んだ理由はいくつかあります。 アセンブリレベルの検証 : AWS はコンパイル済みコードに依存するのではなく、実装を直接アセンブリで記述しています。より困難ではありますが、これにより証明はあらゆるコンパイラから独立したものになります。HOL Light は CPU 命令仕様を使用してマシンコードバイトについて直接推論し、ソフトウェアスタックの最下層で保証を提供します。 既存の暗号インフラストラクチャ : s2n-bignum は、実行アーティファクトを取り除き純粋に数学的な問題を残すシンボリックシミュレーション、ワード演算用の特殊化された戦術、バイトリスト処理など、暗号検証のための広範なサポートをすでに提供しています。AWS は AES 演算に関する証明された補題を追加し、他の AES モードの証明にも再利用できるようにしました。 複雑な制御フローの処理 : 十分な説明なしに複雑な証明で失敗する可能性のある完全自動証明器とは異なり、HOL Light の対話型アプローチにより、5 倍アンロールされたループに必要な複雑なループ不変条件を経由して証明を導くことができ、任意の長さのデータブロックを処理し、可変長入力と部分ブロックに必要な複雑なメモリ推論を実行できます。 s2n-bignum フレームワーク s2n-bignum を AES-XTS の実装に使用することは、2 つの目的を果たします。これは x86-64 および Arm アーキテクチャでアセンブリコードを形式的に検証するためのフレームワークであり、暗号化のための高速で検証されたアセンブリ関数のコレクションでもあります。このライブラリには、特に大数の数学的演算 (これが名前の由来) に関する多数の暗号化アルゴリズムの検証済み実装がすでに含まれており、これらは公開鍵暗号プリミティブの基盤となっています。s2n-bignum の一部として公開鍵アルゴリズムを証明するために HOL Light がどのように使用されたかの詳細については、Amazon Science の以前のブログ記事「 Graviton での RSA の高速化: 形式的検証で正当性を証明し開発も加速 」および「 自動推論で「25519」楕円曲線暗号の高速化と正当性保証を実現 」を参照してください。 前述のとおり、AES-XTS は AES ブロック暗号のモードの 1 つです。AES は、換字操作 (S ボックスを使用した SubBytes)、転置操作 (ShiftRows、MixColumns)、および鍵混合を組み合わせた換字・転置ネットワーク (SPN) 構造に基づいています。s2n-bignum を Arm64 および x86_64 プロセッサにある AES 命令セットアーキテクチャ (ISA)、AES ブロック暗号の仕様、および AES-XTS 用の追加仕様を含むように拡張することで、より多くの AES ベースのアルゴリズムを同じ厳密な検証で扱う道を開いています。 仕様の開発とテスト AES およびそれに基づくモードの SPN の性質は、定理証明器が本来理解できる単純な数式 (公開鍵暗号の基本である剰余乗算など) では表現できません。データを処理するステップの記述を書く必要があります。これがアセンブリを検証する前に、HOL Light の仕様が IEEE 標準を正確に捉えているという確信が必要だった理由です。 AWS は、入出力にバイトリストを使用し、内部ブロック演算には 128 ビットワードを使用して、標準の構造を反映するように仕様を記述しました。次に、 変換 を開発しました。これは、評価が数学的に正しいという証明を生成しながら、具体的な入力で仕様を評価するために使用される HOL Light 関数です。 AWS は、さまざまな AES-XTS 暗号化/復号シナリオをカバーし、すべてのブロックの処理 (再帰を使用) と暗号文スティーリングを実行する単体テストを実施することで、仕様を検証しました。 これらのテストにより、より複雑なアセンブリ検証に取り組む前に、仕様が IEEE 標準と一致することが確認されました。この 2 段階のアプローチ (まずテストにより仕様が正しいことを保証し、次に実装が仕様と一致することを形式的に検証する) により、AWS は正しいことを証明しているという確信を得られました。 証明戦略 AWS の証明はコンポジショナル (合成的) であり、全体の問題を個別に証明できる部分問題に分解します。部分問題に応じて、部分証明は有界 (入力範囲に対してのみ真) または無界となります。 5 ブロック (復号の場合は 6 ブロック) 未満の入力に対しては、各ケースを網羅的に検証する有界証明を作成しました。5 ブロック (復号の場合は 6 ブロック) 以上の入力に対しては、ループ実行中に真であり続ける数学的命題であるループ不変条件を開発し、任意の長さの入力に対する正当性を証明しました。ループ不変条件は、ループ終了条件が満たされるまでに 3 つの重要な要素を追跡します。各イテレーションでのレジスタ状態、「tweak」(各ブロックの暗号化を一意にするもの) の進化、そしてブロックが処理されるにつれてのメモリ内容です。部分ブロック (末尾) 処理については、すべてのケースで再利用できる暗号文スティーリングの個別の定理を証明しました。 トップレベルの正当性定理はすべての証明を組み合わせ、次の命題を主張します。 もしプログラム、入力、出力、スタックが特定の互いに素な性質を満たし、 入力長 len が 16 &lt;= len &lt;= 2 24 を満たすならば、 初期マシン状態が適切なシンボリック値で設定されている場合、 プログラム全体が実行された後、出力バッファに格納された値は AES-XTS 仕様を満たさなければならない。 メモリ安全性と定数時間の証明 最近、s2n-bignum にはアセンブリ関数の定数時間およびメモリ安全性の特性を形式的に定義するための新しい関数と戦術が追加されました。これらのリソースにより、s2n-bignum の多くのアセンブリサブルーチンが定数時間でメモリ安全であることが検証されました。これには、楕円曲線のトップレベルのスカラー乗算関数、RSA の大整数演算、ML-KEM 暗号標準の Arm 実装 (Amazon Science で近日公開予定のブログ記事のテーマ) が含まれます。2025 年 10 月時点で AWS-LC で使用するために特定されたすべてのアセンブリサブルーチンは、定数時間でメモリ安全であることが形式的に検証されました。 AWS は、新しい戦術を AES-XTS など、その後追加されたアセンブリサブルーチンの検証に簡単に使用できるかを探っています。前述のとおり、AES-XTS は非常に複雑な制御フローを持っており、長く込み入った機能的正当性証明となりました。その複雑さは安全性証明にとっても課題です。プロセスは進行中ですが、復号および暗号化アルゴリズムの暗号文スティーリングサブルーチンの安全性特性はすでに証明されています。 これらの最初の証明は、バッファオーバーリードが起こりやすい重要なメモリアクセス手順に焦点を当てました。復号および暗号化アルゴリズムの残りの部分の証明は、同じ方法論を使用できます。定数時間およびメモリ安全性の証明は、機能的正当性の証明と同じ構造に従いますが、証明目標がより焦点を絞っているためより単純です。 正当性の継続的保証 AWS は形式的検証を s2n-bignum の継続的インテグレーション (CI) ワークフローに統合しました。これにより、AES-XTS 実装への変更は、形式的な正当性証明を成功裏に通過しなければコミットできないという保証が得られます。CI の一環として、CPU 命令モデリングは実際のハードウェアに対するランダム化テストによって検証され、不正確さを「ファジング」することで、仕様が正しく証明が実際に成立することを保証します。 さらに、証明では入力がシンボルとして表現されるため、すべての可能な入力に対する正当性が保証されます。これにより、コードのすべての経路をカバーできても、すべての入力値をカバーできない可能性があるカバレッジテストの典型的な欠点を克服します。たとえば、ここで使用されているような定数時間コードは、秘密値で分岐することなく記述されます。通常、秘密値はそれらから派生したマスクの使用により演算に組み込まれます。同じ命令が秘密値に関係なく実行されます。したがって、ライン (行) カバレッジの達成は通常開発者の手の届く範囲にありますが、値カバレッジの達成は正当性の形式的検証に委ねられます。 この同じ方法論により、AWS は数学的な正当性の保証を持つ最適化された暗号化実装をデプロイし、同時に大幅なパフォーマンス向上を達成できました。これにより、開発者やツールはバグの導入を心配することなくコードをさらに自由に最適化でき、バグは証明によって自動的に検出されます。AES-XTS での経験により、アセンブリコードの証明駆動開発が、証明可能な正当性を保ちつつ、より理解しやすく、レビューしやすく、保守しやすく、最適化しやすい制御フローを生み出すことが示されました。 著者について Yan Peng Yan Peng は Amazon Web Services (AWS) の applied scientist (応用科学者) です。暗号ライブラリと認可評価ライブラリの形式的検証に取り組んでいます。 Nevine Ebeid Nevine Ebeid は Amazon Web Services (AWS) の Cryptography グループの senior applied scientist (シニア応用科学者) であり、AWS 暗号ライブラリである AWS-LC のための最適化されたアルゴリズムの開発、検証、コンプライアンスに注力しています。AWS に入社する前は、自動車およびモバイルセキュリティアプリケーション向けの暗号ライブラリとプロトコルの研究開発を行っていました。 June Lee Juneyoung Lee は Amazon の Automated Reasoning Group の senior applied scientist (シニア応用科学者) です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

.NET 、 メインフレーム、および VMware ワークロード 向けの AWS Transform がリリースされたのは、今からちょうど 1 年前のことです。AWS Transform は、エンタープライズアプリケーションの大規模なモダナイズ専用に構築された初のエージェンティック AI サービスでした。re:Invent 2025 では、組織が AWS マネージド変換とカスタム変換を使用してコードを大規模にモダナイズし、変換することを可能にする AWS Transform カスタム が発表されました。そのまま使用できる変換や、組織固有の要件に合わせてカスタマイズできる変換を使用して、言語バージョンのアップグレード、フレームワークの移行、パフォーマンスの最適化、コードベースの分析を実行できます。また、 フルスタック Windows モダナイズ機能 と、 メインフレーム向けの Reimagine 機能と自動テスト機能 も導入されました。 この12 か月間で、何千ものお客様が AWS Transform を使用して何 10 万ものサーバーを移行し、160 万時間以上の時間を節約して、45 億行以上のコードを処理しました。1 周年を記念して、AWS Transform エージェントが Kiro、Claude、Cursor、Codex で利用可能になりました。これには、カスタマイズされた変換エージェントを構築するための エージェントビルダーツールキット「Kiro パワー」 が含まれます。 AWS の 12 か月間の歩み、学んだ 4 つの事柄、そしてこれらがロードマップをどのように進化させたかについては、 1 周年記念ブログ記事 をお読みください。 2026 年 5 月 11 日週のリリース 2026 年 5 月 11 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Claude Platform on AWS の一般提供開始 – 既存の AWS アカウントから、API、コンソール、早期アクセスのベータ機能を含めた Anthropic のネイティブ Claude Platform エクスペリエンスに直接アクセスでき、個別のアカウント、請求、追跡を管理する必要はありません。Claude Platform on AWS は Anthropic が運営しており、カスタマーデータは AWS のセキュリティ境界外で処理されます。詳細については、 機能を詳しく検証するブログ記事 をお読みください。 Amazon EC2 M3 Ultra Mac インスタンス – これらのインスタンスは、28 コアの CPU、60 コアの GPU、32 コアの Neural Engine、256 GB のユニファイドメモリを搭載した Apple M3 Ultra Mac Studio コンピュータ上に構築されています。EC2 M3 Ultra Mac インスタンスは、M4 Max Mac インスタンスの 2 倍のユニファイドメモリ、1.75 倍の CPU コア、1.5 倍の GPU コア、2 倍の Neural Engine コアを備えているため、Apple 開発者ははるかに多くの Xcode シミュレータを並列実行し、オンデバイス機械学習ワークフローを高速化して、製品の市場投入までの時間を短縮できます。 AWS Graviton 搭載の Amazon Redshift RG インスタンス – より優れたパフォーマンスを実現するこれらのインスタンスは、データウェアハウスとデータレイクのワークロードを前世代 RA3 インスタンスの最大 2.4 倍の速さで実行でき、vCPU あたりの料金も 30% 削減されます。RG インスタンスには、Apache Iceberg と Parquet のデータをクラスターノード上で処理する、Redshift のカスタムビルドされたベクトル化データレイククエリエンジンが含まれています。 Amazon Bedrock の Advanced Prompt Optimization – Bedrock では、あらゆるモデルのプロンプトを最適化できます。元のプロンプトと最適化されたプロンプトを同時に最大 5 個のモデルで比較しながら最適化が行われ、新しいモデルに移行する場合や、現在のモデルでより優れたパフォーマンスを実現したい場合にも使用できます。 AWS セキュリティエージェントによるリポジトリ全体のコードスキャン (プレビュー) – コードベース全体を対象としたコンテキスト認識型の詳しいセキュリティ分析を実行する、AWS セキュリティエージェントの新機能を使用できます。脆弱性が発見されると、スキャナーがコード修正 (正確なファイルと行に関連付けられた具体的な修正案) を生成するため、チームはセキュリティ脆弱性をこれまでにない速さで修正できます。プレビュー中、既存の AWS セキュリティエージェントのお客様はこの機能を追加料金なしで利用できます。 Oracle Cloud Infrastructure との AWS Interconnect – マルチクラウド接続 (プレビュー) – AWS Interconnect – マルチクラウド接続を使用することで、他のクラウドプロバイダーに対するレジリエントでスケーラブルなプライベート接続をすばやくプロビジョニングできます。OCI は AWS Interconnect の基盤であるオープン仕様を採用した最新の CSP です。これは、AWS が OCI (プレビュー)、Google Cloud (一般提供)、および Microsoft Azure (2026 年後半に提供予定) をご利用のお客様に、一貫性のあるシンプルなエクスペリエンスを提供することを可能にします。 その他のアップデート 皆さんが興味を持つと思われるその他のニュースをいくつかご紹介します。 Build on Trainium プログラムを通じて AI 研究と教育を加速 – 次世代の AI 研究者が Amazon チップを使用して発見を加速させる方法をお読みください。AWS は、大学研究者が専用の AI チップにアクセスできるようにするために、1 億 1,000 万 USD を投資しました。AWS Trainium は、UC Berkeley、MIT、Carnegie Mellon などの大学で AI 研究を高速化しています。すべての研究はオープンソースであるため、より広範な開発者コミュニティに改善内容が還元されることになります。 AWS Community Days 2026 の完全リスト – 講演者が同じ志を持つ仲間であり、主催者が情熱を持つがゆえに活動するボランティアであって、コミュニティ自体がアジェンダを作成するようなイベントには、他とは違う特別な何かがあります。AWS Community Day はまさにそのようなイベントで、世界全大陸の都市で毎年開催されています。 Kiro スタートアップクレジットプログラムが復活 – 第一弾では何千人もの創業者が応募したプログラムが、申し込みの受け付けを再開しました。プログラムに申し込んで、最大 1 年分の Kiro Pro+ クレジットを受け取りましょう。このクレジットは、組織の AWS アカウントに自動的に適用されます。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS について詳しく学び、次に予定されている AWS 主催の対面イベントとバーチャルイベント 、 スタートアップイベント 、 AWS Summits などの 開発者向けイベント を調べて参加しましょう。 AWS Builder Center にもご参加ください。ビルダーとつながり、ソリューションを共有して、開発をサポートするコンテンツにアクセスできます。 2026 年 5 月 18 日週のニュースは以上です。2026 年 5 月 25 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

本ブログは 2026 年 5 月 12 日に公開された AWS Blog “ AWS Security Agent full repository code scanning feature now available in preview ” を翻訳したものです。 本日 (2026 年 5 月 12 日)、AWS は AWS Security Agent の新機能であるフルリポジトリコードレビューのプレビューリリースを発表します。この機能は、コードベース全体に対して深いコンテキスト認識型のセキュリティ分析を実行します。AI 駆動型サイバーセキュリティ機能は急速に進化しており、AWS Security Agent は、これまでにない規模とスピードでコードベース全体にわたる脆弱性の発見と動作する攻撃コードの構築が可能になりました。人間のセキュリティ研究者のように推論しながら、マシンスピードで動作します。既知の脆弱性パターンとコードを照合する従来の静的解析ツールとは異なり、フルリポジトリコードレビューは、人間のセキュリティ研究者と同様にアプリケーションのアーキテクチャ、信頼境界、データフローについて推論し、透明性のある証拠と具体的な修復方法を伴う、開発者がすぐに対応できる検出結果を生成します。 AWS は、お客様への無償の早期アクセスを優先しています。これにより、防御側がコードベースを強化し、得られた知見を共有することで、業界全体が恩恵を受ける機会を提供します。 課題: コードに合わせてスケールするセキュリティ分析 今日の開発チームは、継続的なジレンマに直面しています。従来の静的アプリケーションセキュリティテスト (SAST) ツールは、SQL インジェクションのシンク(脆弱性箇所)、エスケープされていない出力、ハードコードされた認証情報など、既知のパターンを高速かつ確実に検出します。しかし、現代のアプリケーションは、サービス、API、信頼境界、認可ロジックが絡み合う複雑なシステムです。最も危険な脆弱性は、単一行のパターン違反ではなく、システム全体にわたるギャップであることが少なくありません。たとえば、検証関数が 5 つのケースのうち 4 つしかカバーしていない、あるエンドポイントだけ近隣のエンドポイントに存在する認可アノテーションが欠けている、エンコーディングがあるコンテキストでは適用されているのに別のコンテキストでは適用されていない、といったケースです。 手動のセキュリティレビューはこうした問題を発見できますが、コストが高く、時間がかかり、現代の開発のペースにスケールしません。コードベースが拡大するにつれ、チームは広さと深さのどちらかを選ばざるを得なくなります。 フルリポジトリコードレビューは、このギャップを埋めるために構築されました。個々の行やファイルだけでなく、リポジトリ全体を読み取って推論する自動化されたセキュリティ研究者をチームに提供し、パターンマッチングツールが見逃す検出結果を浮かび上がらせます。 仕組み: プロファイル、検索、トリアージ、検証 フルリポジトリコードレビューは、経験豊富なセキュリティエンジニアによる調査の進め方を反映した 4 つのステージで動作します。 アプリケーションのプロファイリング : スキャナーはまず、リポジトリ全体を読み取り、エントリポイント、信頼境界、データフロー、認可不変条件、すでに導入されている防御策を含むアプリケーションのセキュリティモデルを構築します。このプロファイリングステップはすべてのソースファイルを対象とするため、カバレッジの判断は暗黙的ではなく明示的になります。その結果、 アプリケーションが何を行うか と そのアタックサーフェスがどこにあるか を構造化された形で理解できるようになります。 脆弱性の検索 : オーケストレーターはセキュリティプロファイルを読み取り、アタックサーフェスについて推論し、最もリスクの高いコンポーネントから順に専門エージェントを展開します。各エージェントは、調査対象のモジュール、脅威コンテキスト、攻撃者視点での検証項目を含む、範囲を限定したタスクを受け取ります。手がかりがあれば、エージェントは開始スコープを超えてインポートや呼び出し元を自由に追跡できます。 トリアージと重複排除 : 候補となる検出結果は重複排除され (同じシンク、同じ根本原因)、検証フェーズの前に低信頼度のノイズが除去されます。 独立した検証 : すべての候補について、独立した検証エージェントがソースコードを再度読み取り、攻撃チェーン全体をトレースします。検証エージェントは両方の側から検討します。検出結果が脆弱性ではない理由 (補完的コントロール、意図的な設計) を探すと同時に、脆弱性である理由 (代替の攻撃経路、エッジケース) も探します。検出結果が拒否されるのは、それを支持する証拠と同等の強さの反証がある場合に限られます。このプロセスは、構造化された Verified (検証済み) と Could not verify (検証できず) のセクションを持つ検出結果を生成するため、スキャナーがコードで何を確認したか、何がデプロイ環境に依存するかをチームが正確に把握できます。 何が違うのか フルリポジトリコードレビューは、従来の静的解析と 2 つの根本的な点で異なります。1 つは、既知の脆弱性パターンと照合するのではなく、アプリケーションの実際の動作について推論すること。もう 1 つは、不確実性を隠すのではなく明示する構造化された証拠を伴う検出結果を提示することです。 パターンマッチングではなく、コンテキスト認識型の推論 スキャナーは脆弱性を検索する前にセキュリティモデルを構築するため、表面的なコードパターンだけでなく、アプリケーションの実際の動作について推論します。 実際の例を見てみましょう。あるストアドプロシージャに SQL インジェクションの脆弱性がありました。従来の SAST ツールは、特定の EXECUTE IMMEDIATE 呼び出しを検出するでしょう。しかし、スキャナーはさらに深く分析し、中央の検証関数が 5 つの正規表現プロファイルのいずれにおいてもシングルクォートをブロックしていないことを特定し、5 つのプロファイルすべてを名前で列挙したうえで、特定のデータベースエンジンでシングルクォートが重要である理由を説明し、別のストアドプロシージャが検証関数を完全にスキップしていることを指摘しました。1 つの呼び出しサイトでのポイント修正ではなく、検出結果はシステム全体のギャップに対する包括的な修復につながりました。 別のケースでは、HTML エンコーディングなしでフィールドに値が追加されている XSS 脆弱性をスキャナーが発見しました。同じ値は、同じファイル内の別のコンテキストでは Encode.forHtml() で適切にエンコードされて いました 。パターンマッチングツールは、エンコーディング関数が存在するためこれを見逃しますが、脆弱性は 不整合 そのものにあり、これを発見するにはコードパス全体にわたるアプリケーションの動作を理解する必要があります。 不確実な部分を明示する検証済み検出結果 すべての検出結果は、効率的な開発者トリアージのために構造化されています。 問題 : コードの何が間違っているかを、具体的なファイル名と行番号とともに明示 影響 : 攻撃者が何を得られるかを、デプロイ環境の詳細とともに明示 検証範囲 : スキャナーがコード内で直接確認した内容 (Verified) と、環境 (ネットワークセグメンテーション、ランタイム動作) に依存する内容 (Could not verify) を区別して明示 修復 : 一般的なガイダンスではなく、具体的なコード変更を含む修正案を提示 重大度と信頼度 : それぞれ独立して評価。重大度は脆弱性が悪用された場合の影響を、信頼度は攻撃チェーンのどの程度がコード内で検証されたかを反映 フルリポジトリコードレビューをワークフローに組み込む方法 フルリポジトリコードレビューは、既存のセキュリティツールを置き換えるのではなく、補完するように設計されています。現代の開発ワークフローへの組み込み方は以下のとおりです。 セキュリティレビューの前 : ペネトレーションテストやセキュリティレビューをスケジュールする前に、フルリポジトリコードレビューを実行します。レビューが明白な問題と半ば明白な問題を浮かび上がらせるため、セキュリティチームは限られた時間を、人間の判断を必要とする高度な設計レベルの問題に集中できます。 買収したコードやオープンソースコードのオンボーディング時 : フルリポジトリコードレビューは、買収やベンダー依存関係を通じて、または統合中のオープンソースコンポーネントからコードを継承する際に特に価値を発揮します。スキャナーはセキュリティモデルをゼロから構築するため、コードベースに関する組織内の知識を必要としません。 アーキテクチャレビュー中 : スキャナーは信頼境界、データフロー、認可不変条件について推論するため、その検出結果は実装上のバグだけでなく、アーキテクチャ上の問題を浮かび上がらせることがよくあります。スキャン結果を脅威モデルと並べて確認し、コンポーネントの相互作用に関する仮定を検証してください。 AWS Security Agent でフルリポジトリコードレビューをご利用の場合は、 クイックスタートガイド に従ってセットアップして実行してください。 プレビュー提供と価格 フルリポジトリコードレビューは、本日 (2026 年 5 月 12 日) より AWS Security Agent のお客様向けに追加料金なしでプレビュー提供されています。プレビュー期間中、エクスペリエンスの改良に向けて、みなさまからのフィードバックをお待ちしております。Security Agent ウェブアプリケーションの組み込みフィードバック機能をご利用いただくか、AWS アカウントチームにお知らせください。 開始方法 AWS Security Agent コンソール にアクセスして、フルリポジトリコードレビューを有効にし、最初のスキャンを実行してください。詳細については、 AWS Security Agent ドキュメント を参照してください。 Ayush Singh Ayush は AWS のシニアプロダクトマネージャーで、AWS Security Agent の開発をリードしています。エンタープライズグレード、オープンソース、エージェンティック AI 製品をスケールさせた実績があります。組織がセキュリティプラクティスを効果的にスケールできるツールの構築に注力しています。ロチェスター大学で MBA を、KIIT 大学でコンピュータサイエンスの学士号 (B.Tech) を取得しています。 Daniele Bonadiman Daniele は AWS のシニアアプライドサイエンティストで、AWS Security Agent に取り組んでいます。トレント大学で応用機械学習および自然言語処理の博士号を取得しました。AWS 在籍中、対話型 AI、マルチエージェントシステムのオーケストレーション、AI エージェントによるコード解釈に焦点を当てた複数の AI イニシアチブに貢献してきました。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 5 月 14 日 に公開された「 Getting started with Change Data Capture in Amazon Aurora DSQL 」を翻訳したものです。 本日、 Amazon Aurora DSQL はパブリックプレビューで Change Data Capture (CDC) を発表しました。これにより、データベースの変更をほぼリアルタイムで Amazon Kinesis Data Streams にストリーミングできます。Amazon Aurora DSQL は、常時利用可能なアプリケーション向けのサーバーレス分散 SQL データベースです。新しいアクティブ-アクティブ分散アーキテクチャにより、シングルリージョン構成で 99.99%、マルチリージョン構成で 99.999% の可用性を実現するよう設計されているため、可用性の高いアプリケーション構築に適しています。 最新のアプリケーションでは、分析、自動化、イベント駆動アーキテクチャを支えるリアルタイムデータパイプラインへの依存度が高まっています。従来、運用データベースから下流システムへデータを移動するには、スケジュール実行されるエクスポート、ポーリングクエリ、独自のレプリケーションソリューションが必要でした。これらの方法ではレイテンシーが発生し、運用負荷が増え、システム間の整合性維持が困難になります。 CDC の登場により、Aurora DSQL は下流サービスへのデータベース変更のネイティブストリーミングをサポートするようになりました。CDC は行レベルの変更を捕捉し、外部システムにほぼリアルタイムで配信します。 本記事では、Aurora DSQL Change Data Capture を構成し、データベースの変更を Kinesis Data Streams にストリーミングする方法を説明します。CDC の仕組み、ストリーミングパイプラインの構成方法、変更イベントの消費方法を学べます。 本記事を読み終えると、データベースの変更を耐久性のあるイベントストリームに送り出し、下流のアプリケーションで処理できる動作中の CDC パイプラインを構築できます。 Change Data Capture とは Change Data Capture は、データベースに対する変更を識別および記録し、外部システムから利用できるようにします。データセット全体を繰り返しコピーするのではなく、CDC は変更のあった行のみに焦点を当てます。アプリケーションが INSERT 、 UPDATE 、 DELETE ステートメントを実行するたびに、CDC は変更を捕捉して対応するイベントを生成します。これらのイベントには通常、操作の種類、対象テーブル、変更前後のデータが含まれます。この方式によりリソース消費を抑えつつ、低レイテンシーでデータパイプラインを動作させられます。 例えば、 INSERT 操作では新しい行の値を含むイベントが生成されます。 UPDATE 操作では更新後の完全な行を含むイベントが生成されます。 DELETE 操作では削除された行の主キー値を含むイベントが生成されます。CDC は変更分のみを捕捉するため、下流システムは大きなテーブルを繰り返しスキャンせずにデータの同期を維持できます。 Aurora DSQL Change Data Capture の概要 今回のリリースで、Aurora DSQL CDC は変更イベントを Amazon Kinesis Data Streams にストリーミングできるようになりました。Kinesis Data Streams はフルマネージドかつサーバーレスのストリーミングサービスで、 AWS Lambda などの他の AWS サービスと統合でき、 Apache Kafka のような外部ストリーミングシステムとも統合できます。 Aurora DSQL CDC はネイティブな機能で、データベースの変更を継続的に記録し、ストリーミング先に発行します。アプリケーションが SQL ステートメントでデータを変更すると、Aurora DSQL は発生した行レベルの変更を捕捉し、構造化されたイベントに変換します。 各変更イベントには、データベース操作と変更対象データを記述するメタデータが含まれます。このメタデータにより、下流のコンシューマーはデータベース変更の順序を正確に再構成できます。Aurora DSQL の CDC はアプリケーションのデータベーストランザクションとは独立して動作します。Aurora DSQL は変更イベントをバックグラウンドで捕捉および配信するため、運用ワークロードのパフォーマンスに影響を与えません。現在のリリースでは、CDC はクラスターレベルで動作し、すべてのテーブルの変更を捕捉します。テーブル単位の選択的なフィルタリングはサポートされていないため、特定のテーブルのみが必要な場合は下流のコンシューマー側でフィルタリングロジックを適用する必要があります。CDC の基本概念を理解したところで、実際のアーキテクチャでこの機能がどのように活用されるか見てみましょう。 Aurora DSQL CDC のユースケース Aurora DSQL CDC は、幅広い最新のデータアーキテクチャをサポートします。CDC はデータベース変更のほぼ連続したストリームを提供するため、新しいデータに対してシステムが素早く反応できます。代表的なユースケースの 1 つが リアルタイム分析 です。多くの組織では、運用データを最小の遅延で分析システムに反映する必要があります。CDC ストリームをデータウェアハウスや分析プラットフォームで消費することで、継続的に更新されたデータセットを維持できます。これにより、ダッシュボードやレポートに最新のビジネス活動を反映できます。 もう 1 つの重要なユースケースが イベント駆動アーキテクチャ です。最新のアプリケーションの多くは、イベントを介して通信する疎結合のサービスで構成されています。CDC により、データベースの変更をアプリケーションのイベントとして扱えます。例えば、新しい注文レコードを挿入すると、決済処理や在庫更新などの下流ワークフローを起動できます。 CDC は データレプリケーションのシナリオ でも有用です。多くの組織では、運用データベース、検索インデックス、分析システムなど、用途別に複数のデータストアを運用しています。CDC によって、データ全体をコピーすることなくシステム間で増分同期できます。 最後に、CDC はデータベース活動の包括的な監査証跡を提供します。各変更がイベントとして記録されるため、CDC ストリームはコンプライアンスやトラブルシューティング目的でアーカイブおよび分析できます。 アーキテクチャの概要 次のアーキテクチャは、Aurora DSQL CDC が下流のコンシューマーへデータベース変更をストリーミングする仕組みを示しています。 アプリケーションは標準の SQL ステートメントを使用して Aurora DSQL とやり取りします。これらの操作はデータベース内の行を変更し、変更イベントの主要な発生源となります。Aurora DSQL はテーブルの変更を監視し、変更内容を記述する CDC イベントを生成します。各イベントには、操作の種類、タイムスタンプ、トランザクション識別子、行の値などの情報が含まれます。 Aurora DSQL は CDC イベントを Kinesis データストリームに発行します。ストリームは、データベースワークロードと下流処理を切り離す耐久性とスケーラビリティに優れたバッファです。コンシューマーアプリケーションはストリームからイベントを読み取り、アプリケーションの要件に従って処理します。コンシューマーは分析システムの更新、ワークフローの起動、外部データベースの同期などを行います。 このアーキテクチャにより、Aurora DSQL は信頼できる唯一の情報源となり、下流のシステムは非同期にデータを消費できます。このアーキテクチャを構築する前に、環境を準備する必要があります。 前提条件 本セクションでは、Aurora DSQL Change Data Capture を構成するために必要なツールと権限を説明します。詳細については、 前提条件 を参照してください。 AWS アカウントにアクセスできる認証情報で構成済みの AWS Command Line Interface (AWS CLI) バージョン 2 が必要です。AWS CLI は、Aurora DSQL クラスターの作成、CDC ストリームの構成、関連リソースの管理に使用します。 単一の AWS リージョンに Aurora DSQL クラスター が必要です。 クライアントマシンに PostgreSQL クライアントユーティリティ psql がインストールされている必要があります。Aurora DSQL は PostgreSQL 互換の接続を提供しており、 psql を使って接続、テーブル作成、テストデータ生成を行います。 jq ユーティリティは必須ではありませんが、JSON 出力の閲覧が容易になるため推奨します。 AWS の ID には、Aurora DSQL クラスターの作成、CDC ストリームの管理、Kinesis ストリームの作成、IAM ロールの構成を行う権限が必要です。次のポリシーが必要な権限を提供します。Aurora DSQL クラスターの作成、CDC ストリームの管理、Kinesis ストリームの作成、IAM ロールの構成に必要な IAM 権限 を以下に示します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dsql:ListClusters", "dsql:CreateCluster", "dsql:GetCluster", "dsql:DeleteCluster", "dsql:DbConnectAdmin", "dsql:CreateStream", "dsql:GetStream", "dsql:ListStreams", "dsql:DeleteStream", "dsql:UpdateCluster" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kinesis:CreateStream", "kinesis:DescribeStream", "kinesis:DescribeStreamSummary", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards", "kinesis:DeleteStream" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePolicy", "iam:GetRole", "iam:PassRole", "iam:DeleteRole", "iam:DeleteRolePolicy" ], "Resource": "*" } ] } 環境の準備ができたら、次は AWS CLI を使って Aurora DSQL CDC を有効化します。 マルチリージョンの Aurora DSQL クラスター では、CDC ストリームはストリームが作成されたリージョンに関係なく、すべてのリージョンからコミット済みの書き込みを捕捉します。Aurora DSQL クラスター、ストリーミングターゲット、IAM ロール、呼び出し元プリンシパルなどのすべてのリソースは、同じ AWS アカウントとリージョン内に存在する必要があります。複数のリージョンに CDC レコードを配信するには、各リージョンで個別のストリームを作成してください。各ストリームは独立して同じコミット済み変更のセットを配信します。 注意 : 本記事では、&lt;プレースホルダー値&gt; を実際の情報に置き換えてください。 ステップ 1: Kinesis データストリームを作成する Aurora DSQL CDC はイベントをストリーミング先に発行します。本記事では、ストリーミング先として Amazon Kinesis データストリームを使用します。 単一の シャード で新しい Kinesis ストリームを作成します。シャードは CDC イベントで利用可能なスループット容量を決定します。ストリームを構成する際は、ストリーミング設定でサポートされる最大レコードサイズを考慮してください。Aurora DSQL は最大 2 MiB の 行サイズ をサポートしており、CDC イベントはスキーマやワークロード次第でこの上限に近づくことがあります。設定したレコードサイズが発行されるイベントのサイズより小さい場合、配信に失敗し CDC パイプラインが機能しなくなる可能性があります。 新しい Kinesis ストリームを作成する前に、まずこのデモで使用する環境変数を設定します。 export REGION="&lt;us-east-2&gt;" export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export AWS_DEFAULT_OUTPUT=json export KINESIS_STREAM_NAME="&lt;dsql-cdc-stream&gt;" aws kinesis create-stream \ --stream-name ${KINESIS_STREAM_NAME} \ --stream-mode-details StreamMode=ON_DEMAND \ --max-record-size-in-ki-b 2024 \ --region ${REGION} ストリームを作成したら、ストリームステータスが “ ACTIVE ” になるまで待ちます。Aurora DSQL は、ストリームが完全に利用可能になるまでイベントを発行できません。 # Check stream status aws kinesis describe-stream \ --stream-name ${KINESIS_STREAM_NAME} \ --region ${REGION} \ --query 'StreamDescription.StreamStatus' 次に、ストリームの Amazon Resource Name (ARN) を取得します。 export KINESIS_STREAM_ARN=$(aws kinesis describe-stream \ --stream-name ${KINESIS_STREAM_NAME} \ --region ${REGION} \ --query 'StreamDescription.StreamARN' \ --output text) echo "Kinesis Stream ARN: ${KINESIS_STREAM_ARN}" ARN はストリームを一意に識別するもので、CDC を構成する際に必要です。後で使用する可能性があるため、ストリーム ARN をメモしておいてください。ストリーミング先が準備できたら、次に Aurora DSQL がイベントを発行する権限が必要です。 ステップ 2: CDC 用の IAM ロールを作成する Aurora DSQL は、Kinesis ストリームに書き込む権限を持つ IAM ロールを引き受けて CDC イベントを発行します。IAM ロールには、Aurora DSQL がロールを引き受けることを許可する信頼ポリシーが必要です。 信頼ポリシー は特定の Aurora DSQL クラスターへのアクセスを制限します。ロールには、Kinesis ストリームへの書き込みアクセスを付与する アクセス許可ポリシー も必要です。 まず、次のセクションのように信頼ポリシーとアクセス許可ポリシーを作成します。 # Create Trust policy cat &gt; trust-policy.json &lt;&lt; EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "dsql.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "${ACCOUNT_ID}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:dsql:${REGION}:${ACCOUNT_ID}:cluster/*" } } } ] } EOF # Create Permission policy cat &gt; permissions-policy.json &lt;&lt; EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:PutRecord", "kinesis:PutRecords", "kinesis:DescribeStreamSummary", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:${REGION}:${ACCOUNT_ID}:stream/${KINESIS_STREAM_NAME}" } ] } EOF 次に、ロールを作成してポリシーをアタッチします。 # Create an IAM Role export CDC_ROLE_NAME="&lt;dsql-cdc-kinesis-role&gt;" aws iam create-role \ --role-name ${CDC_ROLE_NAME} \ --assume-role-policy-document file://trust-policy.json # Attach the policy to the Role aws iam put-role-policy \ --role-name ${CDC_ROLE_NAME} \ --policy-name &lt;cdc-kinesis-policy&gt; \ --policy-document file://permissions-policy.json ロールを作成してアクセス許可ポリシーをアタッチしたら、ロール ARN を取得します。 aws iam get-role \ --role-name ${CDC_ROLE_NAME} \ --query 'Role.Arn' \ --output text ロール ARN をメモしておいてください。ロール ARN は CDC ストリームの作成時に必要です。権限を構成したら、CDC ストリームを作成できます。 ステップ 3: CDC ストリームを作成する CDC ストリームは Aurora DSQL クラスターと Kinesis ストリームを接続します。CDC ストリームを作成すると、Aurora DSQL はデータベースの変更を Kinesis ストリームに発行し始めます。ストリームの作成には通常数分かかり、その間に Aurora DSQL は CDC 処理に必要な内部インフラストラクチャをプロビジョニングします。 aws dsql create-stream \ --cluster-identifier ${CLUSTER_ID} \ --target-definition "{\"kinesis\":{\"streamArn\":\"${KINESIS_STREAM_ARN}\",\"roleArn\":\"${CDC_ROLE_ARN}\"}}" \ --ordering UNORDERED \ --region ${REGION} \ --format JSON # Example output { "clusterIdentifier": "2ntttwpyh6nbmi5h54h2e4p4ja", "streamIdentifier": "fntuauzlakwytxknp2k6acrxk4", "arn": "arn:aws:dsql:us-east-2:444455556666:cluster/2ntttwpyh6nbmi5h54h2e4p4ja/stream/fntuauzlakwytxknp2k6acrxk4", " status": "CREATING ", "creationTime": "2026-03-18T10:14:55.405000-04:00", "ordering": "UNORDERED", "format": "JSON" } ストリームが “ ACTIVE ” になるまで待ちます。 # Check stream status (repeat until status is "ACTIVE") export STREAM_ID="&lt;your-stream-identifier-from-output&gt;" aws dsql get-stream \ --cluster-identifier ${CLUSTER_ID} \ --stream-identifier ${STREAM_ID} \ --region ${REGION} \ --query 'status' ストリームが “ ACTIVE ” になると、Aurora DSQL はデータベースの変更を捕捉する準備ができます。次のステップでは、データベースの活動を生成します。 ステップ 4: データベースの変更を生成する CDC を有効化したら、データベースに変更を加えて構成を検証できます。PostgreSQL クライアントで Aurora DSQL に接続し、テスト用テーブルを作成します。CDC に参加するテーブルに主キーは厳密には必要ありませんが、定義することを推奨します。主キーがあれば Aurora DSQL は行を一意に識別でき、より意味のある変更イベントを生成できます。主キーがない場合、 INSERT および UPDATE 操作は完全な行データを含みますが、 DELETE イベントには削除された行を識別する十分な情報が含まれない可能性があります。 テーブルを作成したら、いくつかのレコードに対して挿入、更新、削除を行います。これらの操作によって Aurora DSQL が Kinesis ストリームに発行する CDC イベントが生成されます。次のコマンドで Aurora DSQL クラスターへの 接続 を確立します。 PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname ${CLUSTER_ID}.dsql.${REGION}.on.aws --region ${REGION}) \ PGSSLMODE=require \ psql -h ${CLUSTER_ID}.dsql.${REGION}.on.aws -U admin -d postgres 接続を確立したら、次のコードで主キー付きのテーブルを作成します。 CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name VARCHAR(100) NOT NULL, email VARCHAR(255), created_at TIMESTAMP DEFAULT NOW() ); 次のコードでいくつかの行を挿入します。 INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com'); INSERT INTO users (name, email) VALUES ('Bob', 'bob@example.com'); INSERT INTO users (name, email) VALUES ('Charlie', 'charlie@example.com'); 続いて、変更レコードを生成します。テストデータの生成が終わったら、データベースから切断します。 -- Update a record UPDATE users SET email = 'alice.updated@example.com' WHERE name = 'Alice'; -- Delete a record DELETE FROM users WHERE name = 'Charlie'; -- Exit from psql \q 次のステップでは、ストリームから CDC イベントを読み取ります。 ステップ 5: CDC イベントを読み取る CDC イベントは Kinesis ストリームに保存され、AWS CLI またはコンシューマーアプリケーションで読み取れます。まず、ストリーム内のシャードを一覧表示します。 # List shards in the stream aws kinesis list-shards \ --stream-name ${KINESIS_STREAM_NAME} \ --region ${REGION} 各シャードはレコードのシーケンスを表します。本例では簡単のためシャードを 1 つだけ使用していますが、本番環境のワークロードではストリームに複数のシャードを含められ、コンシューマーはすべてのレコードを読み取るためにシャードを横断的に処理する必要があります。次に、読み取りを開始する位置を指定する シャードイテレータ を取得します。例えば TRIM_HORIZON は、利用可能な最も古いレコードから読み取りを開始します。シャードイテレータを使用してストリームからレコードを取得します。CDC イベントのペイロードは Base64 でエンコードされています。ペイロードをデコードすると、イベントは読み取り可能な JSON になります。各イベントはデータベースの変更を記述し、タイムスタンプ、トランザクション識別子、スキーマ名、テーブル名などのメタデータを含みます。 # Get iterator for the first shard, starting from the beginning export SHARD_ITERATOR=$(aws kinesis get-shard-iterator \ --stream-name ${KINESIS_STREAM_NAME} \ --shard-id shardId-000000000000 \ --shard-iterator-type TRIM_HORIZON \ --region ${REGION} \ --query 'ShardIterator' \ --output text) # Fetch records from Kinesis aws kinesis get-records \ --shard-iterator ${SHARD_ITERATOR} \ --region ${REGION} # Example output { "Records": [ { "SequenceNumber": "49654...", "ApproximateArrivalTimestamp": "2026-03-18T10:24:01.153000-04:00", "Data": "eyJ0eXBlIjoiSU5TRVJUIiwic2NoZW1hIjoicHVibGljIiwidGFibGUiOiJ1c2VycyIsLi4ufQ==", "PartitionKey": "..." } ], "NextShardIterator": "AAAA...", "MillisBehindLatest": 0 } 続いて、データをデコードしてみましょう。 CDC イベントの構造とセマンティクスの理解 Amazon Kinesis Data Streams からレコードを取得した後、次のステップは CDC イベントペイロードの解釈方法を理解することです。Amazon Aurora DSQL が発行する各イベントは、データの変更とそれに関連するメタデータを記述する一貫した JSON 構造に従います。大まかに見ると、すべての CDC イベントには操作の種類、変更前後の行の状態、ソースとイベントのタイミングに関するメタデータが含まれます。 op フィールドは操作の種類を示します。パブリックプレビュー期間中、Aurora DSQL は INSERT 操作と UPDATE 操作の両方を c (create) で表します。これは、更新が行の新しいバージョンとしてモデル化されるためです。 DELETE 操作は d で表されます。 INSERT と UPDATE を区別するには、特定の主キーが過去に観測されたかを追跡する必要があります。 一般提供 (GA) の段階で、Aurora DSQL CDC は更新用の独立した u 操作タイプを導入する予定です。そのため、コンシューマーは将来のすべての行変更が c イベントのみを使い続けると仮定すべきではなく、それを踏まえてイベント処理ロジックを設計する必要があります。 op フィールドは操作の種類を示します。Aurora DSQL は INSERT 操作と UPDATE 操作の両方を c (create) で表します。これは、更新が行の新しいバージョンとしてモデル化されるためです。 DELETE 操作は d で表されます。そのため、 INSERT と UPDATE を区別するには、特定の主キーが過去に観測されたかを追跡する必要があります。 before フィールドと after フィールドは行の状態を表します。 INSERT および UPDATE 操作では、イベントには変更後の完全な行が含まれ、before フィールドは null になります。 DELETE 操作では after フィールドが null になり、before フィールドには削除された行の主キーのみが含まれます。この設計により、削除されたレコードを下流システムが識別可能なまま、ペイロードサイズを抑えられます。 各イベントには 2 種類のタイムスタンプも含まれます。ルートレベルの ts_ms および ts_ns フィールドは、変更がデータベースにコミットされた時刻を表します。 source.ts_ms および source.ts_ns フィールドは、CDC パイプラインがイベントを処理してストリームに発行した時刻を表します。これらのタイムスタンプの差は、データベースからストリーミングシステムへの伝播レイテンシーを示します。source オブジェクトには、トランザクション ID、スキーマ名、テーブル名、データベース名、クラスター識別子などの追加メタデータが含まれます。これらのメタデータは、監査、デバッグ、下流処理ロジックの構築に有用です。 詳細については、 CDC レコード形式 を参照してください。 次の例は、各種データベース操作が CDC イベントとしてどのように表されるかを示します。 # Using the output from get-records echo "&lt;base64-encoded-data&gt;" | base64 -d | jq 次の例は INSERT 操作を示します。”Alice” の新しい行が挿入されました。 op フィールドは “c”、 before は null 、 after には完全な行が含まれます。コミットタイムスタンプ ( ts_ms ) は CDC 発行タイムスタンプ ( source.ts_ms ) より前で、変更が CDC パイプラインを伝播するのにかかった時間を示しています。 # Example output for an INSERT { "op": "c", "before": null, "after": { "id": "521d51b6-47fd-46dc-854a-32306bfc5001", "name": "Alice", "email": "alice@example.com", "created_at": 1773843841048727 }, "source": { "version": "1.0", "ts_ms": 1773843841175, "ts_ns": 1773843841175766820, "txId": "dco7le2ijpdsjtspu7hqkf2lyi", "schema": "public", "table": "users", "db": "postgres", "cluster": "2ntttwpyh6nbmi5h54h2e4p4ja" }, "ts_ms": 1773843841076, "ts_ns": 1773843841076494565 } 次の例は UPDATE 操作を示します。Alice のメールアドレスが更新されました。 op フィールドは c で、イベントには更新後の完全な行が含まれます。Aurora DSQL は更新を行の新しいバージョンとして表すため、このイベントは構造的には INSERT と同一です。 UPDATE と INSERT を区別するには、同じ主キーが過去のイベントで現れたかを追跡する必要があります。 # Example outuput for an UPDATE { "op": "c", "before": null, "after": { "id": "521d51b6-47fd-46dc-854a-32306bfc5001", "name": "Alice", "email": "alice.updated@example.com", "created_at": 1773843841048727 }, "source": { "version": "1.0", "ts_ms": 1773843889144, "ts_ns": 1773843889144309734, "txId": "dco7lhttogt6ntspu7hrvfvsuq", "schema": "public", "table": "users", "db": "postgres", "cluster": "2ntttwpyh6nbmi5h54h2e4p4ja" }, "ts_ms": 1773843889108, "ts_ns": 1773843889108904247 } 次の例は DELETE 操作を表します。行が削除されました。 op フィールドは d 、 after フィールドは null、 before フィールドには削除された行の主キーのみが含まれます。これにより、下流システムは行データ全体を含めなくても、どのレコードが削除されたかを識別できます。 # Example output for DELETE { "op": "d", "before": { "id": "539cdc67-d1a0-4a56-b9cc-98d6f61bdef8" }, "after": null, "source": { "version": "1.0", "ts_ms": 1773843901898, "ts_ns": 1773843901898646132, "txId": "dco7lillvfrhjtspu7h36ehc3e", "schema": "public", "table": "users", "db": "postgres", "cluster": "2ntttwpyh6nbmi5h54h2e4p4ja" }, "ts_ms": 1773843901887, "ts_ns": 1773843901887887743 } これらのイベントをアプリケーションで消費することで、リアルタイムのデータパイプラインを構築できます。 Aurora DSQL CDC のイベント順序の理解 CDC を基盤としてアプリケーションを構築する際に最も重要な検討事項の 1 つが、変更イベントが下流システムに配信される順序です。イベントの処理順序は、コンシューマーが変更を解釈および適用する方法に直接影響します。 Aurora DSQL CDC は、CDC ストリーム作成時に明示的な順序設定を導入しています。この設定はストリーミング先に配信されるイベントの順序保証を定義し、追加の順序モードや統合の導入に伴って今後変化する可能性があります。Aurora DSQL CDC は現在パブリックプレビュー段階のため、下流のコンシューマーは操作タイプのセマンティクスに関する仮定をハードコードすることを避け、将来のイベント形式の拡張を許容できるよう設計する必要があります。 本記事の執筆時点では、Aurora DSQL CDC ストリームは順序を保証しないイベント配信を提供します。つまり、行やトランザクション間で厳密な順序保証なしにイベントが配信されます。詳細については、 順序と配信のセマンティクス を参照してください。この方式は高いスケーラビリティとスループットをサポートするため、効率的で大規模な変更ストリーミングを必要とするワークロードに適しています。各イベントは完全かつ一貫していますが、下流のコンシューマーは順序が前後して到着するイベントを正しく処理できるよう、冪等処理や状態の整合性確保といったパターンを使って設計する必要があります。ストリーム作成時に順序を明示することで、配信セマンティクスを最初から明確に理解した上でアプリケーションを設計できます。順序を保証しないストリームを処理するコンシューマーの設計について、ポーリングやバッチ処理などの手法を含めた詳細は、 Lambda を使用した Amazon Kinesis Data Streams のレコード処理 と 順序と重複排除の戦略 を参照してください。 ベストプラクティス Amazon Kinesis Data Streams を使用する際は、データストリームを作成し、ワークロードに合った適切なキャパシティモードを選択できます。ストリーム管理を簡素化するには、オンデマンドキャパシティモードを選びます。このモードでは、Kinesis が CDC トラフィックに合わせてスループットを自動的にスケーリングするため、シャードを手動でプロビジョニングおよび管理する必要がありません。詳細については、 適切なストリームモードを選択する を参照してください。 Amazon Aurora DSQL から Amazon Kinesis Data Streams へ CDC イベントをストリーミングする際は、ストリームでサポートされる最大レコードサイズを考慮することが重要です。Kinesis は個々のレコードのサイズに上限を設けています。CDC イベントがこの上限を超えると、ストリームにイベントを配信できません。その場合、サイズ制約が解消されるまで CDC パイプラインが機能しなくなる可能性があります。これを避けるため、データモデルの サイズ特性 を考慮し、想定されるペイロードサイズを 処理できるよう ストリーミングパイプラインとコンシューマーを構成してください。これらの上限を踏まえて設計することで、中断のない継続的かつ信頼性の高い CDC イベント配信を維持できます。 下流のシステムは、 重複イベントの処理 と順序が前後して到着するイベントの処理に対応できるよう設計してください。CDC の配信は非同期で厳密な順序を保証しないため、コンシューマーは同じイベントを複数回受信したり、順序が前後して到着するイベントを観測したりする可能性があります。正確性を保つため、アプリケーションは冪等な処理ロジックを実装し、イベントが繰り返されても結果に不整合が生じないようにする必要があります。これは通常、主キーやトランザクションのメタデータ (タイムスタンプやトランザクション ID など) を使って変更を検出および調整することで実現します。順序が重要な場合は、コンシューマーは バッチ処理 、タイムスタンプを使用したイベントの並べ替え、コミット時刻に基づく last-write-wins セマンティクスを適用できます。一部のテーブルのみを処理したい場合は、CDC ストリームにすべてのテーブルの変更が含まれるため、下流のコンシューマー側でフィルタリングロジックを適用してください。これらのパターンを踏まえてコンシューマーを設計することで、高スループットのストリーミング条件下でも信頼性と一貫性のあるデータ処理を実現できます。 クリーンアップ CDC パイプラインが正しく動作し、Amazon Kinesis Data Streams へのデータベース変更のストリーミングを検証できたら、本ウォークスルーで作成したリソースをクリーンアップできます。 Amazon Aurora DSQL の CDC ストリームを削除しても、データベース内の既存データは維持されます。ストリームを削除すると、Kinesis データストリームへの新しい変更イベントの配信が停止するだけです。同様に、Kinesis ストリームを削除してもソースデータベースには影響しませんが、ストリームに保存されている未消費の CDC レコードは完全に削除されます。 本セクションでは、本記事で作成したリソースを削除する手順を案内します。これにより、不要なコストを避けつつ、AWS 環境をクリーンに保てます。 # Delete the CDC stream aws dsql delete-stream \ --cluster-identifier ${CLUSTER_ID} \ --stream-identifier ${STREAM_ID} \ --region ${REGION} # Wait for stream deletion, then disable deletion protection and delete the cluster aws dsql update-cluster \ --identifier ${CLUSTER_ID} \ --no-deletion-protection-enabled \ --region ${REGION} # If you created a new Aurora DSQL cluster to test CDC feature aws dsql delete-cluster \ --identifier ${CLUSTER_ID} \ --region ${REGION} # Delete the Kinesis data stream aws kinesis delete-stream \ --stream-name ${KINESIS_STREAM_NAME} \ --region ${REGION} # Delete the IAM role and associated policy aws iam delete-role-policy \ --role-name ${CDC_ROLE_NAME} \ --policy-name cdc-kinesis-policy aws iam delete-role \ --role-name ${CDC_ROLE_NAME} # Clean up local files rm -f trust-policy.json permissions-policy.json これらの手順を完了すると、CDC パイプライン用に作成したリソースが削除され、AWS 環境は元の状態に戻ります。 まとめ Aurora DSQL Change Data Capture は、データベースの変更を外部システムにストリーミングするネイティブな仕組みを提供します。本記事では、データベースの変更を捕捉して Kinesis ストリームに発行する CDC パイプラインを構成しました。データベースの活動を発生させ、生成されたイベントを検証しました。Aurora DSQL CDC は独自のレプリケーションソリューションを不要にし、リアルタイムアーキテクチャの構築を簡素化します。Aurora DSQL をストリーミングシステムと統合することで、開発者はデータの変更にほぼリアルタイムで反応する応答性の高いアプリケーションを構築できます。Aurora DSQL Change Data Capture は、スケーラブルなイベント駆動システムやリアルタイム分析パイプラインを構築するための基盤となります。 著者について Vijay Karumajji Vijay は、AWS のプリンシパルデータベーススペシャリスト Solutions Architect です。商用およびオープンソースのデータベースで 20 年以上の経験を持ち、深い技術的専門知識を活かして組織のデータプラットフォームのモダナイゼーションと AWS マネージドデータベースサービスの価値最大化を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Koji Shinkubo がレビューしました。

2026 年 5 月 14 日、 Amazon Bedrock Advanced Prompt Optimization を発表しました。これは、 Amazon Bedrock 上のあらゆるモデルのプロンプトを最適化するための利用できる新しいツールです。最大 5 個のモデルで、元のプロンプトと最適化されたプロンプトを同時に比較できます。この新しいプロンプト最適化を使用することで、新しいモデルに移行したり、現在のモデルのパフォーマンスを改善したりできます。それらをテストして、既知のユースケースでパフォーマンスの低下がないかをテストしたり、パフォーマンスの低いタスクを改善したりすることもできます。 この新しいプロンプト最適化ツールは、ガイドとして使用するために、プロンプトテンプレート、変数値のユーザー入力例、正解データ、評価メトリクスを受け取ります。これはマルチモーダルユーザー入力とともに使用することもできます。プロンプトテンプレートに対する入力として、 png 、 jpg 、 pdf 形式をサポートしているため、文書や画像分析などのタスク向けにプロンプトを最適化できます。 最適化のガイドとするために、 AWS Lambda 関数、LLM-as-a-judge ルーブリック、または短い自然言語による説明を提供することもできます。プロンプト最適化ツールは、評価メトリクスに基づいて、プロンプトと、結果として得られるモデル応答を最適化するために、メトリクスドリブンのフィードバックループで動作し、評価スコア、コスト見積り、レイテンシーとともに、元のプロンプトテンプレートと最終プロンプトテンプレートを出力します。 Bedrock の高度なプロンプト最適化の実際の動作 新しいプロンプト最適化の使用を開始するには、 Amazon Bedrock コンソール の [高度なプロンプト最適化] ページで [プロンプト最適化を作成] を選択します。 プロンプトを最適化する最大 5 つの推論モデルを選択します。新しいモデルに移行する場合、または現在のモデルでより優れたパフォーマンスを実現したい場合に、これを使用できます。モデルを変更する場合は、現在のモデルをベースラインとして選択するほか、最大 4 つの他のモデルを選択できます。モデルを変更しない場合は、現在のモデルを選択して最適化前後の結果を確認します。 プロンプトテンプレートは、サンプルユーザーデータ、正解データ、および評価メトリクスまたは書き換えガイダンスを含む JSONL 形式で準備する必要があります。 .jsonl ファイルの場合、各 JSON オブジェクトは単一の行に記述されている必要があります。 { "version": "bedrock-2026-05-14", // 必須; 固定値 "templateId": "string", // 必須 "promptTemplate": "string", // 必須 "steeringCriteria": ["string"], // 任意 "customEvaluationMetricLabel": "string", // customLLMJConfig または evaluationMetricLambdaArn が使用される場合は必須 "customLLMJConfig": { // 任意 "customLLMJPrompt": "string", // customLLMJConfig が存在する場合は必須 "customLLMJModelId": "string" // customLLMJConfig が存在する場合は必須 }, "evaluationMetricLambdaArn": "string", // 任意 "evaluationSamples": [ // 必須 { "inputVariables": [ // 必須 { "variableName1": "string", "variableName2": "string" } ], "referenceResponse": "string" // 任意 "inputVariablesMultimodal": [ // 任意 { "Arbitrary_Name": { // マルチモーダル変数には必須。 "type": "string", // [PDF] または [IMAGE] から選択します。Acceptable filetypes for IMAGE = png, jpg, "s3Uri": "string" // ファイルの S3 パスを入力 } ] } ] } ファイルを直接アップロードするか、または Amazon Simple Storage Service (Amazon S3) からプロンプトテンプレートをインポートして、プロンプト最適化の結果と評価データを保存する S3 出力場所を設定できます。その後、 [最適化を作成] を選択します。 Amazon Bedrock は、プロンプトテンプレートとサンプルデータ (オプションの正解データを含む) を推論モデルに自動的に送信し、評価メトリクスで応答を評価した後、フィードバックループでプロンプトを書き換えて、推論モデル向けに最適化します。指定したメトリクスに基づく評価結果と、最終的に最適化されたプロンプトが表示されます。 お気づきのとおり、独自の Python スコアリングロジックを用いた Lambda 関数、カスタムルーブリックを利用した LLM-as-a-judge、または自然言語による方向性基準といった 3 つの方法でプロンプトの質を評価できます。プロンプトテンプレートごとに 1 つの方法を選択することもできますが、1 つのジョブで複数のプロンプトテンプレートを使用できるため、必要に応じて各テンプレートごとに異なる方法を使用できます。 Lambda 関数 – 具体的なメトリクス (精度、F1 スコア、実行精度、構造化 JSON 一致など) がある場合は、独自のスコアリングロジックを含む Lambda 関数をデプロイし、プロンプトテンプレートの evaluationMetricS3Uri フィールドを設定できます。Lambda 内で中核となるのは、参照応答に照らしてモデル出力をプログラムで比較する compute_score の実装です。 LLM-as-a-judge – タスクが自由形式 (要約、生成、推論の説明) であり、ルーブリックに基づいたスコアが必要な場合は、プロンプトテンプレートの customLLMJConfig フィールドにある S3 設定ファイルで、構造化された指示と評価尺度を含む名前付きメトリクスを定義できます。Bedrock のジャッジモデルが各プロンプトと回答のペアを評価し、推論付きのスコアを返します。デフォルトのモデルは Claude Sonnet 4.6 ですが、ジャッジモデルのリストから独自のモデルを選択することもできます。 方向性基準 – 必要な特性 (ブランドボイス、フォーマット、安全上の制約) はわかっているものの、ジャッジプロンプト全体を作成したくない場合は、プロンプトテンプレートの steeringCriteria 配列を通じて、入力データセットに基準を定義できます。評価尺度を含む構造化されたメトリクスの代わりに、LLM ジャッジが総合的に評価する自由形式の自然言語基準を提供します。このオプションを使用すると、デフォルトの LLM-as-a-judge プロンプトが応答を評価し、方向性基準をジャッジプロンプトに組み込みます。この場合のジャッジモデルは、Anthropic Claude Sonnet 4.6 です。 高度なプロンプト最適化と移行方法の詳細については、 Bedrock における高度なプロンプト最適化 ガイドと GitHub のサンプルコード にアクセスしてください。 今すぐご利用いただけます Amazon Bedrock の高度なプロンプト最適化は、現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、チューリッヒ)、南米 (サンパウロ) リージョンでご利用いただけます。最適化中に消費された Bedrock モデル推論トークンに基づいて課金され、通常の Bedrock 推論と同じトークン単価が適用されます。詳細については、「 Amazon Bedrock の料金 」ページにアクセスしてください。 Amazon Bedrock コンソール で、または CreateAdvancedPromptOptimizationJob API を使用して、高度なプロンプト最適化を今すぐお試しください。フィードバックは AWS re:Post for Amazon Bedrock 宛てに、または通常の AWS サポート担当者を通じてお寄せください。 – Channy 原文は こちら です。

本記事は 2026 年 4 月 14 日に公開された「 AI, Technical Debt, and the Path to Real Fluency 」を翻訳したものです。 ※ 本記事では、原文の “AI fluency” を「AI を使いこなす力」と訳しています。単なる AI に関する知識ではなく、実践を通じて身につく AI を使った問題解決力を意味しています。 まさに今、私がお話を伺っているエンタープライズのリーダーの誰もが同じ 3 つの問題に頭を悩ませています。これらは特定の業界や企業規模に限った話ではなく、金融サービス、政府機関、ヘルスケアなどで見られます。そして、これらの問題は往々にして同時に現れます。 1 つ目の問題は、ほとんどの組織が自社にどのようなシステム、ツール、アプリケーションがあるのかを実は把握していないということです。技術資産は広範囲にわたり、ドキュメントは不十分で、多くの場合、それを理解していた人はすでに退職しています。問題があることは分かっていて、それが足かせになっていると感じているのに、どこに問題が潜んでいるのかを正確に特定できないのです。何か新しいことを始めるたびに、「はい、でも実は…」がまた一つ出てきます。 私自身、インディアナ州の CTO としてこれを身をもって経験しました。課題があることは分かっていましたが、体系的に対処できるほどの精度で毎回安定して課題を特定することができませんでした。 2 つ目の問題は、AI の幅広い導入をどう促進するかです。技術チームは AI の活用方法を模索していますが、多くはコード生成やテスト作成の段階で止まっています。明確なユースケースも、どこに AI の変革が必要で、どのようなインセンティブが求められるかを判断するフレームワークもありません。それがなければ、AI の本格的な導入は構想のままなかなか進みません。 3 つ目の問題は最も言語化しにくいものですが、チームが AI ツールを使っている様子を観察すると明らかになります。それは、トレーニングが提供する 手順通りにこなせるスキル と、自分自身の環境で実際に手を動かして身につく 問題解決の実践力 との間にあるギャップです。チームを前者から後者へ導くためには、トレーニングではなく経験が重要です。 私がお客様にお伝えしているのは、1 つのアプローチでこれら 3 つの問題すべてに対処できるということです。そしてそれは、最新のコミットまで反映された正確なドキュメントアーティファクト (コードから自動生成されるドキュメント類の成果物) の作成を必須にすることから始まります。 今いる場所から始める：未知を既知にする この業界で 30 年間働いてきましたが、優れたドキュメントを見たことがありません。効果的なドキュメント作成は時間がかかり、デリバリーのプレッシャーと相反するためです。開発者にドキュメントを書くことを期待し続ける限り、この状況は変わらないでしょう。 最近、もっと有望なものを目にしました。それは、チームが AI を使って、作業の副産物としてリアルタイムにドキュメントやその他の有用なアーティファクトをプログラム的に生成しているケースです。 AI はコードにコメントを書いたりドキュメントアーティファクトを作成したりすることを気にしません。しかも、目にしたものをうまく読み解くのが得意です。十分なコンテキストを与えてコードを読み込ませれば、チームが忘れていた、あるいはそもそも知らなかった情報、例えば依存関係、パターン、リスク、ロジックに組み込まれたアーキテクチャ上の判断などを浮き彫りにしてくれます。 実践的な出発点として、 AWS Transform custom のモダナイゼーションエージェントがあります。すぐに使える変換定義 (TD) が用意されており、ニーズに合わせてカスタマイズできます。1 つの TD でコードを読み取り、アプリケーションを変更することも移行を行うこともなく、コードに関する情報を生成できます。 レガシー資産から 1 つか 2 つのアプリケーションを選び、分析を実行して、AWS Transform custom が何を教えてくれるか確認してみてください。すでに知っていたこと、疑っていたこと、そして本当に驚くようなことが見つかるでしょう。そして、チームがアプリケーションについて実際に知っていることと、その出力結果を照合する時間を取ってください。精度の感触を掴んだら、「チームがどのようなコンテキストを追加すれば、これをもっと有用にできるか？」と自問してみてください。 既製のツールは、お客様がどのように、そしてなぜそうしているかを熟知しているわけではありません。しかし、アーキテクチャ標準、既知の制約、技術的な意思決定、ソフトウェアバージョンの基準など、企業固有のコンテキストでこれらのツールを拡張することができます。 最近、お話を伺った銀行のチームは、複雑で複数のシステムから構成される、レガシー環境全体での日付とタイムゾーンの処理について特に懸念していました。ここで有効なのが、AWS Transform custom のコード分析 TD をカスタマイズして、資産全体の日付と時刻のロジックを浮き彫りにするというアプローチです。これは自社ビジネスの将来にとって重要な課題にピンポイントで切り込む取り組みであり、汎用的な AI ユースケースとは一線を画すものです。 このプロセスから生まれるアーティファクト（リポジトリに保存された Markdown ファイルなど、お好みのテキスト形式で構いません）は、価値あるものの始まりです。それは、検索可能で体系化された、レガシー資産のナレッジベースです。プロセスを自動化して、好きな名前を付けてください。リビングドキュメントでもリアルタイムアーティファクトでも構いません。名前は重要ではありません。重要なのは、それが存在し、コードの実態に即しており、変更に合わせて更新され続けることです。 隠れたメリット：実際の業務を通じて AI を使いこなす力を身につける このアプローチの予想外の成果は、それが AI を使いこなす力を養う演習になるということです。チームが AI に何を探してほしいかを記述し、コンテキストを提供し、出力結果を磨き上げていくとき、他のあらゆる AI ユースケースに転用できるスキルを実践することになります。自分が求めるものをどう記述するか？コンテキストをどう管理するか？有用なものになるまで、どう磨き上げていくか？ これらは机上の知識ではありません。コードの分析、ドキュメントの作成、前例のない問題の解決など、AI と効果的に協働するための実践的な技術です。何かを始め、改善し、コンテキストを管理し、求めるものに到達するという実践の積み重ねこそが、AI による問題解決の核心です。こうしたスキルは研修で学ぶものではありません。実際の課題に向き合う中で身につくものです。 AI の利用を義務化しても導入の問題は解決しません。チームに AI と真剣に向き合うことを求める、具体的で意味のあるタスクを与えることで解決するのです。 すべてをつなげる：OKR にする (翻訳時注釈: OKR とは Objectives and Key Results の略で、目標と主要な結果を意味します。) ここまでで、技術資産を理解するための方法が手に入りました。そしてその過程で、AI を使いこなす力も身につけられます。では、これを組織として定着させるにはどうすればよいでしょうか？ ポートフォリオ内のすべてのアプリケーションが、年末までに現行のコードを正しく反映するリアルタイムアーティファクトを持つことを目標に設定することを検討してください。リアルタイムアーティファクトとは、一度書いて終わりのドキュメントではなく、コミットやメインブランチへのプッシュ、コードの変更があるたびに自動で更新されるアーティファクトのことです。今日実際に稼働しているアプリケーションの姿をそのまま映し出す、生きた記録を作成しましょう。 OKR は AI の使用を義務化するものではなく、成果を定義するものです。 この目標への道筋には 3 つのステップがあります： 基本的なやり方を教える仕組みを提供する。 チームにツールを使ってこれらのアーティファクトを生成する方法を示します。具体的で手を動かすようなものにしてください。 実験を奨励する。 チームが自由に試し、定義を改善し、AI を独自に使いこなす力を身につけられるようにします。多様性はバグではなく、仕様です。(翻訳時注釈: チームごとのばらつきは問題ではなく、むしろ望ましいことです) 成果を自動化する。 プロセスが理解できたら、CI/CD フックやスケジュールジョブ、エージェントトリガーとしてパイプラインに組み込みましょう。誰かが忘れずに実行しなければならない状態ではなく、アーティファクトが自動的に生成される状態にするのです。 3 つのステップすべてを完了したとき、解決しているのはドキュメントの問題だけではありません。技術資産に関する組織としてのナレッジを、一貫して自動的に生成するプロセスを構築したのです。 これらのアーティファクトは以下のことに活用できます： アプリケーションの動作に関する正確なコンテキストを必要とする AI エージェントへの情報提供 監査およびコンプライアンスワークフローのサポート オンボーディングの加速 インシデントになる前のリスクの可視化 成果 AI 導入に苦戦しているお客様は、十分にインパクトがあり、かつ安全に始められるユースケースを探していることが多いです。ここで紹介したアプローチがまさにそれです。 コードを変更したり、チームを置き換えたりするわけではありません。組織が常に必要としながらも、なかなか実現しきれなかったこと、つまり組織そのものを理解することを AI を使って行うのです。そしてその過程で、その後のあらゆる AI 投資の成功確率を高める AI を使いこなす力、習慣、組織としてのナレッジを構築することになるのです。 この記事はカスタマー ソリューション マネージャーの仁科 みなみが翻訳しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。生成AIを使ったサービスが日々の業務やプライベートに溶け込んできていますが、その裏側でどんなハードウエアが動いているのかまで意識する機会はあまり多くないかもしれません。普段車に乗るときにエンジンの仕組みまで気にしないのと似ていて、たまにボンネットを開けて覗いてみると、自分が使っているサービスへの理解が深まり、技術選定や活用方法を考えるうえでのヒントになることもあります。「 10 AI chip terms you should know (知っておきたいAIチップに関する10の用語)」というブログを見つけたのでお時間あるときに是非読んでみてください。 お昼休みの30分で最新情報を知れる場として「 もぐもぐAWS 」という企画がスタートしました。是非チェックしてみてください。 5 月 28 日には「 第7回　AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～ 」というイベントが開催されます。生成 AI の最新トレンド紹介や参加者間での情報交換を目的としたイベントですのでぜひご参加ください。 それでは 5月 11 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 株式会社アクト・ノード様の AWS 生成 AI 活用事例：Amazon Bedrock Agent Coreで実現する「見守りエージェントAI」。一次産業の人手不足と熟練知識の属人化を解決し、見守り頻度を最大48倍に拡大、生産者の工数を50%削減 」 養鶏や果樹、水産養殖といった一次産業の現場で、Amazon BedrockとAmazon Bedrock AgentCoreを活用した「見守りエージェントAI」を構築した株式会社アクト・ノードの事例を紹介するブログです。生産者がチャットで相談すると見守り要件をAIが整理し、既存の定点カメラから取得した画像を自律的に分析して異常時にアラートを出す仕組みになっています。少量の参考画像と説明文だけで多様な見守りニーズに対応できるFew-shot examplesの活用や、Amazon Bedrock AgentCoreの会話メモリでセッションをまたいだ文脈維持を実現している点が特徴です。実証では見守り頻度が1日1〜3回から30分間隔で最大48回へ拡大し、生産者の工数も50%削減されたほか、ベテランの暗黙知を構造化データとして蓄積できる副次的な効果も確認されています。人手不足と知識の属人化に悩む一次産業の現場で生成AIの活用を検討しているユーザーにとって参考になる内容です。 AWS生成AI国内事例ブログ「 「人がいない」を、AIが埋める ── 養鶏・防災・建設・化学の中堅・中小企業4社が示すDX最前線 」 人手不足や知識継承といった日本の中堅・中小企業に共通する課題に対して、生成AIとAIエージェントで解決に取り組む4社の事例をまとめたブログです。アクト・ノード（養鶏での見守りエージェント）、ヤマトプロテック（防災・書類電子保管）、大豊建設（社内生成AIツール「大豊AI」）、メック（化学の研究情報検索エージェント）の取り組みが紹介されています。ヤマトプロテックではAmazon BedrockとKiroを使ってわずか2日でAI-OCRによる書類電子保管システムを構築し、手作業入力を85%以上削減した事例、大豊建設では8ヶ月で307名が利用し規程検索で約250時間の業務時間を削減した事例、メックではAmazon Bedrock AgentCore・Amazon S3 Vectors・Strands Agentsを組み合わせた情報検索エージェントを約3週間で開発した事例など、短期間に生成AIを業務に組み込みたいユーザーにとって参考になる内容です。 AWS生成AI国内事例ブログ「 AWS GenAIIC の技術支援で実現する建設・BIM 特化基盤モデル開発 — GENIAC 第 3 期 ONESTRUCTION Ishigaki-IDS 事例 」 GENIAC第3期において、ONESTRUCTION株式会社が建設・BIM領域に特化した基盤モデル「Ishigaki-IDS」を開発した事例を紹介するブログです。BIMモデルへの情報付与・照査内容を定義する新しいXML規格「IDS（Information Delivery Specifications）」に対応するため、Qwen3（8B/14B/32B）をベースに、継続事前学習（CPT）、教師ありファインチューニング（SFT）、検証可能な報酬による強化学習（RLVR）の3段階パイプラインで学習を進めています。学習基盤にはAmazon EC2 P5enインスタンス（NVIDIA H200 GPU搭載）を2ノード、AWS ParallelClusterによる分散学習のオーケストレーション、Amazon FSx for Lustreによる高スループットな共有ストレージが使われています。AWS Generative AI Innovation Center（GenAIIC）からは、学習データ設計・評価ベンチマーク・学習テクニック・インフラ・実験結果の診断まで隔週で技術アドバイザリーを受ける形で支援され、最終的に「Ishigaki-IDS-8B」とベンチマーク「IDS-Bench」がHugging Faceで公開されています。 ブログ記事「 3人月の開発を2日間で ─ 日立グループ初の AI-DLC 実践で得たリアルな手応え 」 2026年1月22〜23日にAWS Loft Tokyoで開催された「11社合同 AI-DLC Unicorn Gym」に株式会社日立産業制御ソリューションズが参加した体験レポートです。「分散したIT資産・セキュリティデータの統合基盤構築」をテーマに、Kiroを中心にAWS Lambda・Amazon DynamoDB・AWS CDKを使った構成を2日間で形にしています。従来手法で約530時間（3人月相当）と見積もられた開発を、7名×10時間の約70時間で動作するプロトタイプまで到達させた点が特徴です。AI駆動開発を社内で本格的に検討したいユーザーにとって、前提条件（業務担当者の同席、結合テストやセキュリティ審査は別途）も含めて参考になる内容です。 ブログ記事「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート 」 2026年4月13日にAWS大阪支社で開催された「AWS Local Executive Roadshow」シリーズ第1回の開催レポートです。全国5都市・計8回のシリーズの初回として、エグゼクティブや情シス部門に向けて生成AIをビジネス価値に転換するためのポイントが、関西拠点の実践企業の事例を中心に共有されました。文具メーカーのサクラクレパスでは、Amazon BedrockとDifyを組み合わせた社内AI共通基盤を「情シス主導×ユーザー作成」の役割分担で運用している事例、化学メーカーのメックではAWS Amplify、Amazon Bedrock AgentCore、Amazon S3 Vectors、Strands Agentsを使ったAgentic RAGを自前構築している事例が紹介されています。 ブログ記事「 AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 」 2026年4月14日にAWS大阪支社で開催された「AWS Local Executive Roadshow」シリーズ第2回の開催レポートです。AIで顧客を支援するIT企業のエグゼクティブ向けに、開発力をストック型収益に変えるためのビジネスモデル変革をテーマに開催されました。ロジカル・アーツのSaaS「HARMONY」では、Amazon Connectベースに7つのAI機能を組み込んだAIコンタクトセンターソリューションで、アフターコールワーク時間を20分から5分へ短縮し、ランニングコストを85%削減した事例が紹介されています。アプリズムの競走馬見守りプロダクト「aiba」では、Amazon SageMaker AIで独自の骨格推定モデルを反復学習させ、AWS IoT Coreのフリートプロビジョニングでデバイスのプロビジョニング工数を約90%削減した取り組みが共有されています。 ブログ記事「 最新の Amazon Q コスト機能による FinOps の変革 」 Amazon Q Developerに追加されたコスト分析・最適化機能を使って、FinOps（クラウド財務運用）の進め方をどう変えられるかを解説するブログです。AWS Cost Explorer、AWS Cost Optimization Hub、AWS Compute Optimizer、AWS Budgets、AWS Pricing APIなど複数のサービスから情報を横断的に取得し、自然言語の質問に対して時間単位・リソースレベルの粒度で回答できるようになっています。設計段階のアーキテクチャを読み取ってAmazon EC2やAmazon S3の料金見積もりを生成したり、AWS GravitonやサーバーレスへのWhat-if分析を行ったりと、開発者がコスト意識を「シフトレフト」させやすくなる点が特徴です。 ブログ記事「 Hannover Messe 2026 AWS ブースレポート 」 世界最大級の産業見本市「Hannover Messe 2026」のAWSブースを紹介するレポートです。スマート生産・サプライチェーン・製品設計開発・スマートプロダクトの4領域で、Amazon Bedrock、Amazon Bedrock AgentCore、Amazon Nova、Amazon Quick、AWS IoT Core、Amazon Connect、Kiroなどを組み合わせたデモが展示されました。また、注目の「AI-Driven Product Journey」では、来場者がキオスクで入力したデザインから生成AIがオリジナルデザインを作り、AMR・協働ロボット・レーザー彫刻機・AI画像検査・ヒューマノイドロボットが連携して金属コースターを製造する一連のフローを、エージェントAIが自律的にオーケストレーションする様子が披露されました。スマート生産の「Investigation Trace」によるエージェントの推論過程の可視化や、Kiroで7インチHMI向けの空調管理システムをC++で開発するデモを30分以内で完了させる事例など、実運用フェーズに進みつつある産業AIの最新動向を把握したいユーザーにとって参考になる内容です。 ブログ記事「 Specがさらに高速にスマートに進化 」 Kiroの仕様駆動開発（spec-driven development）機能に、開発スピードを高めながら品質を維持するための3つの新機能が追加されました。タスクリストの依存関係を自動でグラフ化して独立タスクを並列実行する「Run tasks in parallel」、要件・設計・タスクを一度に自動生成する「Quick plan mode」、そしてLLMと自動推論を組み合わせるNeurosymbolic AIで要件の曖昧性や論理矛盾を検出する「Requirements analysis」の3つです。タスクの並列実行では、同じファイルを編集するタスクは並列化を避けつつ、独立タスクは「waves」としてまとめて同時実行する仕組みになっており、1時間以上かかっていた大規模な仕様の実装時間が約4分の1に短縮された例が紹介されています。Quick plan modeでは2〜4個の的を絞った質問とワークスペースの自動スキャンで承認プロセスを簡略化し、Requirements analysisでは「レコードを削除」がハード削除かソフト削除かといった解釈のばらつきを実装前に検知できます。 ブログ記事「 探求のための広い余地：20ドル分の有料ティアサインアップボーナス 」 Kiroの新規有料サブスクライバー向けサインアップボーナスが、これまでの500クレジットから1,000クレジット相当（20ドル分）に倍増されました。初日からClaude Opus 4.7を含むプレミアムモデルにフルアクセスでき、ソーシャルログインまたはBuilder IDで登録した利用者が対象になります。無料ティアの構成も見直され、Claude Sonnet 4.5に加えてQwen3 Coder Next、DeepSeek v3.2、MiniMax 2.1といったオープンウェイトモデルがクレジットカード不要で使えるようになりました。 サービスアップデート Claude Platform on AWSが一般提供開始 Anthropic社のネイティブなClaude Platformの体験を、既存のAWSアカウントから直接利用できる「Claude Platform on AWS」が一般提供開始されました。AWSがこの体験を提供する最初のクラウドプロバイダーとなり、AWSのIAM認証情報、統合請求、AWS CloudTrailによる監査ログをそのまま利用できます。Claude Managed Agents（ベータ）、Advisor strategy（ベータ）、ウェブ検索、ウェブフェッチ、コード実行、Files API（ベータ）、Skills（ベータ）、MCPコネクタ（ベータ）、プロンプトキャッシング、引用、バッチ処理など、Anthropic側の最新機能に同じAPIで直接アクセスできる点が特徴です。東京リージョンを含む17のAWSリージョン（米国・欧州・アジアパシフィックなど）で利用でき、別アカウント・別請求の管理を増やさずにClaudeの最新機能を試したい開発チームや企業にとって参考になる内容です。 Amazon Bedrockが高度なプロンプト最適化と移行ツールを発表 Amazon Bedrockに、プロンプトの最適化と複数モデル間での比較評価を一括で行える「Advanced Prompt Optimization」機能が追加されました。プロンプトテンプレート、サンプル入力、任意の正解データ、評価指標または自然言語の評価基準を入力すると、元のプロンプトと最適化後のプロンプトを最大5モデルで同時に比較できます。JPG・PNG・PDFなどのマルチモーダル入力にも対応しており、出力には最終プロンプトに加えて評価スコア・コスト見積もり・レイテンシーがまとめて表示されます。現行モデルをベースラインに据えて移行先候補と比較できるため、モデル変更時のパフォーマンスの後退（リグレッション）を事前に検知しやすくなる点も特徴です。 Kiro CLI 2.3.0でMCPサーバー接続の拡充、~/.kiroの再配置、TUIのリマップに対応 Kiro CLIのバージョン2.3.0がリリースされ、MCPサーバーへの接続性、Kiroのインストール場所、ターミナルUIのキーバインドのカスタマイズ性を高める4つの機能が追加されました。動的クライアント登録に対応していないHTTPベースのMCPサーバーに対しては、設定ファイルに事前登録済みの oauth.clientId を指定することで、Slack・GitHub・Figmaなどのサービスを独自プロキシなしで使えるようになります。 KIRO_HOME 環境変数を設定するとグローバルエージェント・プロンプト・スキル・設定・セッションの保存先を変更でき、複数マシンでのdotfiles管理や仕事用・個人用プロファイルの分離、コンテナ環境での状態の隔離がしやすくなります。V2 TUIのキャンセル・メニュー終了・終了アクションのキーバインドをリマップできるようになったほか、エージェントの実行結果を $AGENT_DISPLAY_OUT と $AGENT_CONTEXT_OUT という2つの新チャネルに出力する仕組みも追加され、コンテキスト消費を抑えつつ進捗表示と内部メモを使い分けられるようになっています。 Amazon SageMaker AIがQwen3.6のサーバーレスモデルカスタマイズに対応 Amazon SageMaker AIで、Alibaba Cloudが提供する「Qwen3.6 27Bパラメータモデル」に対するサーバーレスのファインチューニングがサポートされました。教師ありファインチューニング（SFT）と強化学習ファインチューニング（RFT）の両方に対応しており、これまではベースモデルのデプロイのみだったところから、特定のドメインやワークフローに合わせたカスタマイズが可能になります。インフラのプロビジョニングやトレーニングのオーケストレーションはAmazon SageMaker AIが担い、利用した分だけの従量課金モデルで使える点が特徴です。東京リージョンを含む4つのAWSリージョン（米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド））で提供されています。 AWS Transformがエージェントビルダーツールキット「Kiro Power」を提供開始 AWS Transform向けのエージェントビルダーツールキット「Kiro Power」の一般提供が開始されました。「AWS Transform composability initiative」の一環として提供され、移行・モダナイゼーションを担うパートナーやISV、ユーザーが、自社の専門エージェント・ツール・ナレッジベース・ワークフローをAWS Transformのエージェント型AI機能と統合できます。ツールキットはエージェントの構築から共有、AWS Transformへの登録、ディスカバリーまでのライフサイクル全体をカバーしており、構築したカスタムエージェントは「Kiro Power Marketplace」を通じて他のユーザーからも利用される形で展開できます。 AWS Transformがカスタマー所有のアーティファクトストアをサポート アセスメント・移行・モダナイゼーションをAI駆動で進めるAWS Transformで、変換アーティファクトの保存先として、ユーザー自身が所有するAmazon S3バケットを設定できるようになりました。任意でAWS KMSキーによる暗号化を組み合わせることもでき、自社のIAMポリシーでアクセス制御を行えます。S3バケットへ直接ファイルをアップロードすればAWS Transformのエージェントが即座に利用でき、複数のAWSアカウントにまたがるアーティファクトを集約管理できる点が特徴です。 Amazon SageMaker JumpStartで画像生成・テキスト埋め込みの新モデルが利用可能に Amazon SageMaker JumpStartに、Black Forest Labsの画像生成モデル「FLUX.2-klein-base-4B」と、Qwenのテキスト埋め込みモデル「Qwen3-Embedding-0.6B」の2つが追加されました。FLUX.2-klein-base-4Bはコンパクトなアーキテクチャでリアルタイム画像生成とマルチリファレンス編集に対応し、13GBのVRAMがあれば動作します。Qwen3-Embedding-0.6Bは100以上の言語に対応したテキスト埋め込みモデルで、検索・分類・クラスタリング・バイテキストマイニングといった用途に向き、出力次元の柔軟な指定や指示認識型の埋め込みにも対応しています。 Amazon SageMaker JumpStartで音声認識・テキスト読み上げの3つの新モデルが利用可能に Amazon SageMaker JumpStartに、Qwenの音声系モデル3種が追加されました。多言語TTSで音色・感情・韻律の指示制御に対応する「Qwen3-TTS-12Hz-1.7B-CustomVoice」、3秒の音声入力からの高速ボイスクローニングが可能な「Qwen3-TTS-12Hz-1.7B-Base」、52言語・方言に対応し複雑な音響環境に強い音声認識モデル「Qwen3-ASR-1.7B」の3つです。数クリックでデプロイできるJumpStartの特性を活かし、リアルタイム対話型のボイスアプリ、仮想アシスタント、文字起こしや多言語カスタマーサポート、リアルタイム字幕といった幅広いユースケースに対応します。 Amazon SageMaker JumpStartでエージェント型コーディングと効率的AI向けの2つの新モデルが利用可能に Amazon SageMaker JumpStartに、Z.aiの「GLM-5.1-FP8」とMicrosoftの「Phi-4-mini-instruct」の2つの新モデルが追加されました。GLM-5.1-FP8はリポジトリレベルのコード生成、ターミナルタスク、複雑なデバッグワークフローを得意とするエージェント型ソフトウェアエンジニアリング向けのモデルで、長期的な反復推論で解を磨き上げるタイプです。Phi-4-mini-instructはメモリやレイテンシーの制約がある環境向けにコンパクトに作られており、24言語と関数呼び出しに対応し、推論・数学・論理処理に強みがあります。自動コードレビューパイプラインやAI開発環境を構築したいユーザーや、エッジ・低レイテンシー環境で多言語チャットボットやリソース制約下の推論を扱いたいユーザーにとって参考になる内容です。 Amazon SageMaker Data AgentがIAM Identity Centerドメインで利用可能に Amazon SageMaker Unified StudioのData Agentが、AWS IAM Identity Centerで構成されたドメインでも利用できるようになりました。Amazon Athena、Amazon Redshift、Amazon S3、AWS Glue Data Catalogなどに接続し、自然言語で分析目的を伝えるとPythonまたはSQLのコードを生成します。ノートブックのセル、選択中のテーブル、クエリ履歴を会話のコンテキストとして引き継ぎ、コード生成前に段階的な実行プランを提示する仕組みになっています。 Amazon SageMaker Feature StoreがSageMaker Python SDK V3をサポート 機械学習モデル向けの特徴量を保存・共有・管理するAmazon SageMaker Feature Storeが、SageMaker Python SDK V3（v3.8.0以降）に対応しました。フィーチャーグループの作成時にAWS Lake Formationを有効化することで、オフラインストアのデータに列レベル・行レベルのアクセス制御を適用できます。加えて、Apache Icebergのコンパクションやスナップショットの有効期限といったテーブルプロパティを、SDK経由で直接設定できるようになっています。 Amazon SageMakerノートブックインスタンスでG6インスタンスのリージョン拡大 Amazon SageMakerノートブックインスタンスで利用できるAmazon EC2 G6インスタンスが、東京リージョンを含む8つのAWSリージョン（東京、ムンバイ、シドニー、ロンドン、パリ、フランクフルト、ストックホルム、チューリッヒ）に拡大されました。G6は最大8基のNVIDIA L4 Tensor Core GPU（1基あたり24GBメモリ）と第3世代AMD EPYCプロセッサを搭載しています。 Amazon SageMaker StudioノートブックがP6-B200インスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで、Amazon EC2 P6-B200インスタンスが米国東部（バージニア北部）リージョンで利用できるようになりました。NVIDIA Blackwell GPUを8基（高帯域幅GPUメモリ合計1,440GB）と第5世代Intel Xeonプロセッサ（Emerald Rapids）を搭載しており、AIトレーニングでP5enと比較して最大2倍の性能が示されています。現時点では東京・大阪リージョンは対象外です。 Amazon SageMaker StudioノートブックでG6eインスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで、Amazon EC2 G6eインスタンスが東京リージョンを含む6つのAWSリージョン（東京、ソウル、ドバイ、フランクフルト、ストックホルム、スペイン）に拡大されました。G6eは最大8基のNVIDIA L40s Tensor Core GPU（1基あたり48GBメモリ）と第3世代AMD EPYCプロセッサを搭載しており、EC2 G5と比べて最大2.5倍の性能が示されています。 Amazon SageMaker StudioノートブックでG6インスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで利用できるAmazon EC2 G6インスタンスが、中東（ドバイ）とアジアパシフィック（マレーシア）の2つのAWSリージョンに新たに拡大されました。G6は最大8基のNVIDIA L4 Tensor Core GPU（1基あたり24GBメモリ）と第3世代AMD EPYCプロセッサを搭載し、EC2 G4dnと比較してディープラーニング推論性能が約2倍となります。 Amazon SageMaker StudioノートブックでP4deインスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで利用できるAmazon EC2 P4deインスタンスが、東京リージョンを含む3つのAWSリージョン（東京、シンガポール、フランクフルト）に拡大されました。P4deは80GBのHBM2eメモリを搭載したNVIDIA A100 GPUを8基使用し、合計640GBのGPUメモリを提供します（P4d比でGPUメモリが2倍）。 Amazon SageMaker StudioノートブックでP5.48xlインスタンスのリージョン拡大 Amazon SageMaker Studioノートブックで利用できるAmazon EC2 P5.48xlインスタンス（NVIDIA H100 Tensor Core GPU搭載）が、東京リージョンを含む7つのAWSリージョン（サンフランシスコ、東京、ムンバイ、シドニー、ジャカルタ、ロンドン、ストックホルム）に拡大されました。ディープラーニングやハイパフォーマンスコンピューティング向けに設計されたインスタンスです。 Amazon SageMaker StudioノートブックがP5.4xlインスタンスタイプをサポート Amazon SageMaker Studioノートブックで、Amazon EC2 P5.4xlインスタンス（NVIDIA H100 Tensor Core GPU搭載）が一般提供開始されました。東京リージョンを含む7つのAWSリージョン（米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、ムンバイ、東京、ジャカルタ、サンパウロ）で利用できます。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。

本記事は 2026 年 5 月 5 日 に公開された「 Amazon Aurora DSQL for global-scale financial transactions 」を翻訳したものです。 Amazon Aurora DSQL を使えば、強い整合性と低レイテンシーを両立しながら、複数の AWS リージョンにまたがるグローバル規模の金融トランザクションを実行できます。従来はこの選択にコストが伴いました。夜間のリコンシリエーションバッチ、手動フェイルオーバー手順、顧客残高や決済を扱うシステムでの短時間のデータ不整合リスクなどです。Amazon Aurora DSQL はグローバルに整合性のある強い耐久性を持つトランザクションを、アクティブ-アクティブの可用性とサーバーレス運用で提供し、従来のトレードオフを解消します。 本記事ではまず、分散整合性に対する従来のアプローチが金融ワークロードで不十分な理由を検証します。次に Amazon Aurora DSQL のアーキテクチャが分散整合性の課題にどう対処するかを説明し、3 つの本番ユースケース (勘定系、グローバル支出管理、デジタル通貨インフラストラクチャ) に適用します。最後に実装上の考慮事項と、 Amazon Aurora DSQL 無料利用枠 での始め方を紹介します。 金融サービスデータベースに求められる要件の変化 金融データベースには常に整合性と可用性が求められてきました。変わったのは運用環境です。10 年前、トランザクション処理のほとんどはリージョナルでした。銀行の中央台帳は 1 つのデータセンターで稼働し、トレーディングシステムは単一の取引所に対応し、日次バッチによる突合処理は当たり前のものとして受け入れられていました。現在、顧客は地理的に分散した拠点間でのリアルタイムな可視性を求め、規制当局は取引報告の期限を厳格化し、マルチリージョンでの可用性はもはや付加価値ではなく競争上の必須要件となっています。 よくあるシナリオで課題を説明します。あるリージョンの口座から引き落とし、別のリージョンの口座に入金する処理を、単一のトランザクションで実行する必要があります。従来の解決策は 2 フェーズコミット (2PC) で、コーディネーターノードが各参加者から合意を集めてからコミットします。動作はしますが、コーディネーターが単一障害点となり、ラウンドトリップ全体にわたってロックを保持し、部分的な障害にはテストが困難で運用コストの高いリカバリロジックが必要です。リージョン間ではコーディネーターのラウンドトリップに数百ミリ秒が加わり、クロスリージョントランザクション中のロック競合が最も重要なタイミングでスループットを制限する可能性があります。 多くのチームが代替手段として選ぶのは、非同期レプリケーションによる結果整合性、競合解決を伴うマルチプライマリ構成、あるいは専用の分散データストアです。これにより 2PC の調整負荷は回避できますが、その負担はアプリケーション開発者にのしかかります。共有状態を扱うサービスすべてに冪等性、競合解決、突合ロジックを実装しなければなりません。一時的な不整合を許容し、それを運用リスクモデルに織り込むチームもあります。分析やキャッシュのワークロードでは合理的なトレードオフですが、顧客残高、決済、取引を直接扱う場合には正当化が難しくなります。 Amazon Aurora DSQL はこの 2 つのアプローチの間を埋めます。2PC の調整負荷なしに強い整合性を提供し、結果整合性の突合負債も発生しません。 Amazon Aurora DSQL のアーキテクチャと金融サービスへの意義 Amazon Aurora ストレージエンジンの利点を、AWS リージョン間の分散運用向けに拡張した形で利用できます。 Amazon Aurora DSQL の紹介 でアーキテクチャの詳細を解説しています。ここでは金融サービスワークロードで最も重要な特性に焦点を当てます。 アクティブ-アクティブのマルチリージョン設計です。クラスターをデプロイした全リージョンで読み書きが可能です。各リージョンのノードは対等なピアとしてトランザクションを受け付け、書き込みトランザクションはリージョン間およびウィットネスリージョンに同期レプリケートされます。 ウィットネスリージョン は、軽量かつ中立的な第三の拠点で、コミットの判定に参加することで 3 拠点間のクォーラム（多数決）を維持し、トランザクションの永続性を確認します。クォーラムには 3 つの参加者のうち少なくとも 2 つの合意が必要なため、3 リージョンが必要です。2 つのアクティブリージョンのうち 1 つが停止しても、残りのアクティブリージョンとウィットネスリージョンで過半数を構成できるため、中断やデータ損失なくトランザクションのコミットが継続されます。もしウィットネスなしの 2 リージョン構成だったら、1 リージョンが失われた時点で、処理中のトランザクションがコミットされたのかどうかすら確認できなくなります。 マルチリージョンクラスターにより、データベースレイヤーで最大 99.999% の可用性を実現します。マルチリージョン運用を必要とするレジリエンス戦略において、手動フェイルオーバー、プライマリ/セカンダリの調整、フェイルオーバー後のデータ突合の構築・維持が不要になります。これは、各リージョンで独立して動作するアクティブ-アクティブのアプリケーション層と組み合わせると最も効果的で、スタック全体がすべてのレイヤーで集中的な調整なしにリージョン障害を吸収できるようになります。 サーバーレスで運用・スケーリング。キャパシティプランニング、レプリカ管理、シャーディング戦略の設計は不要です。コンピュート、コミット、ストレージの各レイヤーが独立して自動的にスケールします。Amazon Aurora DSQL は消費したコンピュートと I/O に対して課金されます。マーケットオープンや四半期末のスパイク時に使用した分だけ支払い、閑散期のアイドルには課金されません。予測困難な需要パターンを持つ金融ワークロードでは、従来のプロビジョニング型データベースアーキテクチャと比較して大幅なコスト削減が見込めます。 整合性モデル。トランザクションは最寄りのリージョンでローカルに実行され、Amazon Aurora DSQL は変更を伴うトランザクションのコミット時にのみリージョン間で調整します。整合性モデルはスナップショット分離を伴う楽観的同時実行制御 (OCC) で、トランザクション実行中にロックを保持しません。読み取り専用トランザクションはローカルのレイテンシーで完了し、リージョン間調整なしに一貫性のあるスナップショットを参照できます。書き込みトランザクションはコミット時にのみクロスリージョン調整コストが発生するため、調整ウィンドウは最小限に抑えています。 代わりに、各トランザクションはデータの一貫したスナップショットに対して動作し、Amazon Aurora DSQL はコミット時にのみ競合をチェックします。2 つのトランザクションが同じ行を変更した場合、一方が正常にコミットされ、もう一方はシリアライゼーションエラーとなり、アプリケーション側でリトライします。 この特性は以降のユースケースで重要です。通常は異なる行 (異なる口座、異なる取引) に触れるワークロードでは、競合は最小限です。同じ行を頻繁に更新するワークロードでは、カウンターをインプレースで更新するのではなく新しい行を追加するなど、行レベルの競合を減らすスキーマ設計が有効です。 Amazon Aurora DSQL のドキュメント で OCC 向けスキーマパターンの詳細なガイダンスを提供しています。 PostgreSQL 互換性。PostgreSQL を使用しているチームは、既存の SQL 構文、ドライバー、クライアントライブラリを Amazon Aurora DSQL でそのまま使用できます。本記事の例では馴染みのある PostgreSQL パターンを使用しており、既存のリレーショナルスキーマを最小限の変更で移行できます。Amazon Aurora DSQL が現在サポートしていない PostgreSQL 機能については、 Amazon Aurora DSQL の使用に関する考慮事項 を参照してください。 金融サービスのユースケース 以下のユースケースに共通するテーマは、複雑なマルチデータベースアーキテクチャを単一のグローバルに整合性のあるデータレイヤーに置き換え、突合プロセスや手動フェイルオーバー手順を排除する点です。異なるのは具体的な運用コンテキストと規制上の要件です。 勘定系と台帳の整合性 勘定系アプリケーションは、顧客口座、残高、トランザクションの正確なリアルタイム台帳を管理します。地理的に分散して運用する大規模銀行は、従来はリージョンごとに別々の勘定系を運用するか、バッチ処理でデータを同期していました。 これには 2 つの問題があります。プライマリリージョンがダウンすると、トランザクション処理が停止するか、データ損失を伴うフェイルオーバーが発生します。通常運用時でも、あるリージョンでの残高クエリが別のリージョンで処理された最近のトランザクションを反映していない場合があります。規制当局と顧客は、リージョン間での継続的な可用性とリアルタイムの正確性を期待しています。 Amazon Aurora DSQL は、各支店やリージョンのアプリケーションがローカルエンドポイントに読み書きを行い、更新は全リージョンに自動伝播することで、この問題を解決します。米国東部 (オハイオ) で処理された入金は、米国西部 (オレゴン) から照会する窓口担当者にも即座に表示されます。あるリージョンが利用不能になっても、残りのリージョンはデータ損失も手動フェイルオーバーもなくトランザクション処理を継続します。データベースが単一のグローバルに整合性のある状態を提供するため、システム間の突合なしに全リージョンから規制報告を作成できます。 具体例として、2 つの口座間の資金移動を考えます。従来のマルチリージョンアーキテクチャでは、リージョナルデータベース間の部分的な障害に対処するために、Saga パターン、メッセージキュー、補償トランザクションが必要になる場合があります。Amazon Aurora DSQL では単一の ACID (原子性、整合性、分離性、耐久性) トランザクションに簡素化できます。 以下のスキーマは、Amazon Aurora DSQL の分散アーキテクチャ向けに最適化されたいくつかの設計選択を示しています。UUID 主キーはリージョン間でのシーケンシャル ID の調整負荷を回避します。CHECK 制約はアプリケーションコードではなくデータベースレベルでビジネスルールを適用します。TIMESTAMPTZ 列はどのリージョンがトランザクションを処理しても一貫したタイムスタンプを提供します。これらの例ではわかりやすさのためにリテラル値を使用しています。本番環境では SQL インジェクションを防ぐため、データベースドライバーを通じたパラメータ化クエリを必ず使用してください。アプリケーションコードで送金開始前に十分な残高があることを検証する必要があります。以下の SQL は Amazon Aurora DSQL playground でインタラクティブに実行できます。 -- Schema: simplified core banking ledger CREATE TABLE accounts ( account_id UUID PRIMARY KEY, customer_id UUID NOT NULL, balance NUMERIC(18,2) NOT NULL CHECK (balance &gt;= 0), currency VARCHAR(3) NOT NULL, updated_at TIMESTAMPTZ DEFAULT NOW() ); CREATE TABLE transactions ( transaction_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), from_account UUID NOT NULL, to_account UUID NOT NULL, amount NUMERIC(18,2) NOT NULL, description TEXT, created_at TIMESTAMPTZ DEFAULT NOW() ); -- Funds transfer as a single ACID transaction BEGIN; UPDATE accounts SET balance = balance - 500.00, updated_at = NOW() WHERE account_id = 'acct-1234' AND balance &gt;= 500.00; UPDATE accounts SET balance = balance + 500.00, updated_at = NOW() WHERE account_id = 'acct-5678'; INSERT INTO transactions (from_account, to_account, amount, description) VALUES ('acct-1234', 'acct-5678', 500.00, 'Funds transfer'); COMMIT; 口座の更新と取引き録は、アプリケーションがどのリージョンに接続していても原子的にコミットされます。送金元の残高が不足している場合、CHECK 制約で弾かれトランザクション全体がロールバックされます。片方の口座だけが引き落とされ、もう片方に入金されていない、そんな中間状態は起こりません。Saga オーケストレーション、補償トランザクション、夜間の突合バッチは不要です。 振替は通常、異なる口座行を操作するので、異なる口座に対する並行トランザクションは Amazon Aurora DSQL の楽観的同時実行モデルで競合なくコミットされます。まれに 2 つのトランザクションが同時に同じ口座を対象とするケースでは、OCC がコミット時に競合を検出し、一方のトランザクションがリトライされます。アプリケーション側でロックを取る必要はなく、整合性は保たれます。 グローバル支出管理と法人カードシステム 現代の支出管理サービスは、世界中の数千の企業のあらゆる金融取引を承認・追跡する集中的な意思決定レイヤーとして機能します。カードの利用、ACH (Automated Clearing House) 送金、電信送金、経費精算のいずれも、残高、与信限度額、加盟店管理、リスクスコア、会計マッピングに対する複数のトランザクション更新を発生させます。これらの操作は異なるロケーションから数秒以内に発生することが多く、わずかな不整合 (例: 承認判定に対して残高更新が遅れる) でも取引の拒否、過剰支出、不正リスクの露出につながります。 Amazon Aurora DSQL を使えば、リージョン間で単一のグローバルに整合性のある台帳を維持できます。各リージョンがローカルで書き込みを受け付け、同じグローバルに整合性のあるトランザクションセットの一部としてコミットします。これは、異なるリージョンにデプロイされた複数の決済プロセッサーや銀行パートナーと連携する場合に特に有用です。最大の価値は、統合された台帳と突合レイヤーにあり、リージョナルデータベース間のバッチ同期なしにグローバルに整合性のある残高ビュー、支出管理、会計記録を維持できます。 デジタル通貨インフラストラクチャ グローバルなデジタル通貨発行体は、複数のリージョン、ブロックチェーン、銀行パートナーにまたがる発行、償還、送金、決済をサポートする常時稼働サービスを運用しています。これらのサービスは、トークン供給量、顧客残高、取引状態を正確に追跡するリアルタイム台帳の維持が不可欠です。発行（ミント）、焼却（バーン）、送金イベントを取引所、決済プロセッサー、銀行パートナーの近くでローカルに処理でき、Amazon Aurora DSQL がそれらを原子的にコミットしてグローバルに可視化します。流通供給量、顧客残高、取引履歴はリージョン間で継続的に同期されます。 AWS 無料利用枠で始める 永続的な AWS 無料利用枠 と、分散データベース設計の専門知識がなくても開発を加速する AI スキルを利用できます。無料利用枠には毎月 100,000 Database Processing Units (DPU) と 1 GB のストレージが無料で含まれ、開発環境の運用や小規模アプリケーションのサポートに十分な容量です。 Amazon Aurora DSQL AI スキル は、分散ワークロード向けのスキーマ設計、外部キーなしの参照整合性、初日から本番対応のアプリケーション構築を支援します。Kiro や Claude Code などの AI コーディングツールと連携し、分散トランザクション向けに最適化されたスキーマ設計、レジリエントなマルチリージョンアプリケーションアーキテクチャの構築、既存の PostgreSQL ワークロードの Amazon Aurora DSQL への移行などのタスクについてインタラクティブなガイダンスを提供します。 Amazon Aurora DSQL スキルの全セットについては、 Amazon Aurora DSQL ステアリングガイド を参照してください。 まとめ 本記事では、Amazon Aurora DSQL がグローバルに分散した ACID トランザクション、最大 99.999% の稼働率を持つアクティブ-アクティブの可用性、サーバーレス運用を単一のマネージドサービスで実現する方法を紹介しました。2 フェーズコミットと結果整合性の限界にアーキテクチャがどう対処するかを説明し、金融サービスチームが構築する 3 つの本番パターン (原子的なクロスリージョン送金を行うコアバンキング台帳、グローバルに整合性のある経費管理システム、リージョン間で流通供給量と残高を同期するデジタル通貨プラットフォーム) に適用しました。 実際に試すには、 Amazon Aurora DSQL サービスページ から無料利用枠クラスターを作成し、 開発者ガイド で接続設定、クエリパターン、スキーマ設計を確認してください。アーキテクチャの詳細や機能比較については Amazon Aurora DSQL のドキュメント を参照し、移行のビジネスケース構築については AWS アカウントチームにご相談ください。 著者について Trevor Spires Trevor は、AWS の金融サービス担当シニアソリューションアーキテクトです。キャピタルマーケットおよびフィンテックのお客様と密接に連携し、コアインフラストラクチャと AI システムのクラウドでのスケーリングとセキュリティ確保を支援しています。 Raluca Constantin Raluca は、Amazon Aurora DSQL を専門とする AWS のシニアデータベースエンジニアです。Oracle、MySQL、PostgreSQL、クラウドネイティブソリューションにわたる 18 年のデータベース経験を持ち、データベースのスケーラビリティ、パフォーマンス、リアルタイムデータ処理に注力しています。 Jigna Gandhi Jigna は、AWS の金融サービス担当シニアソリューションアーキテクトです。フィンテック、Web3、銀行組織と密接に連携し、最新の金融プラットフォームを支えるスケーラブルでセキュアかつレジリエントなクラウドおよび AI ソリューションを設計しています。 Narendra Reddy Bathina Narendra は、AWS の金融サービス担当テクニカルアカウントマネージャーです。フィンテックのお客様と連携し、データベース、ストレージ、クラウドオペレーションの豊富な現場経験を活かして、本番システムのレジリエンス、パフォーマンス、スケーラビリティの向上を支援しています。 Viraj Padte Viraj は、AWS の金融サービス担当シニアソリューションアーキテクトです。さまざまなフィンテックのお客様と連携し、コアビジネスおよび AI を活用したプラットフォームとソリューションを支えるエンタープライズ対応のインフラストラクチャを設計しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

みなさん、こんにちは。ソリューションアーキテクトの川﨑です。この記事では、 富士電機ITソリューション株式会社 が Amazon Q Developer Pro サブスクリプションを活用し、開発者が実施する業務だけではなく日常業務でも生成 AI を取り込むことで、業務効率化のその先にある新しい企業価値の創出へと歩みを進めている旅路をご紹介します。 Amazon Q Developer の新規利用については Amazon Q Developer のサポート終了に関するお知らせ をご確認ください。 富士電機ITソリューション株式会社について 富士電機ITソリューション株式会社（以下、 FSL ）は、システム開発・運用保守・インフラ構築からセキュリティ対応まで、幅広いITソリューションを提供するシステムインテグレーターです。製造・流通・金融・建設など幅広い業界向けの”民需分野”、中央省庁や自治体などの”公共分野”、そして小中学校から大学までをカバーする”文教分野”の 3 本柱で構成され、コンサルティングからシステム設計・開発、ICT インフラ構築、運用・保守までを一気通貫で提供しています。 長年培われた業種・業務ノウハウと、全国規模の顧客基盤を持つ FSL にとって、生成 AI による開発生産性の向上は、自社の競争力強化だけでなく、お客様への付加価値提供を大きく加速する重要なテーマとなっています。 Amazon Q Developer Pro サブスクリプションの展開 FSL では Amazon Q Developer Pro サブスクリプション を 2025年12月に金森 重晴 執行役員 の指揮のもと 20 ユーザーから展開し、現在(2026年4月から)では、50 ユーザー以上へ展開しています。利用場面は、開発現場だけではなく通常業務での活用を推進してきました。導入当初から「まず使ってみる」を合言葉に、各メンバーが自身の業務のなかで生成 AI をどう活かせるかを自律的に模索する文化を育てています。一方的に「こう使ってください」とルールを押し付けるのではなく、自分の業務課題と向き合いながら活用方法を見つけ、社内で事例を共有し合う。このボトムアップ型のアプローチが、想像を超える多様なユースケースを生み出し短期間での利用者拡大を実現できています。勉強会や事例共有会を通して、今後も利用者は拡大していく予定です。 本稿では、2026年4月に実施した Amazon Q Developer ハンズオン勉強会の中でも特に反響の大きかった FSL 社内事例 LT ( Lightning Talk )で共有された 3 名のメンバーの取り組みをご紹介します。 現場から生まれた 3 つの活用事例 事例 1：原田 浩司 氏 – 業務ドキュメント作成の効率化と生成 AI 比較評価 – 原田 氏は、Amazon Q Developer を業務ドキュメントの効率化に活用されています。代表的なユースケースは、 テスト結果報告書の作成 です。これまで手作業で多くの時間を割いていた報告書ドラフト作成を Amazon Q Developer に支援させることで、レビューに集中できる時間が大幅に増えました。作成時のポイントは、HTML出力をすることです。マークダウン形式よりも表現豊かな報告書として出力できるため、作成後の報告にそのまま活用できる点がポイントです。さらに、管理用のExcelレポートへ変換出力をし、業務の効率化をはかっています。説明時に以下のようにコメントされていました。 「Amazon Q Developer の利点である動作しているファイルの読み書きが実行できることで、生成AIを疑問の回答を得るツールではなく、解決策まで実装できる点が使いやすい」 図1:システム試験結果のHTML出力例 図2:システム試験結果のExcel出力例 報告書を作成するだけではなく、障害情報を利用し再発防止策を講じるためのインサイトも生成AIを利用し作成しています。この時の説明時には、以下のようにコメントされていました。 「出力結果も妥当な結果が多く、ある程度の経験者が考えたインサイトと同程度である品質になっている」 さらに原田 氏は、Amazon Q Developer と他の生成 AI　との比較評価にも取り組んでいます。同じタスクを複数のツールで試し、それぞれの強み・弱みを見極めながら「業務ごとに最適な AI を選ぶ」という視点を社内にもたらしています。ツール選定を「感覚」ではなく「実測」で判断する文化は、今後の AI 活用拡大に向けた重要な資産になっています。 事例 2：久保田 匡史 氏 – 開発者業務の生産性を底上げする使いこなし – 久保田 氏は、日常業務の幅広い場面で Amazon Q Developer を使いこなしています。コーディングの枠を超えた特徴的な活用方法を3つ紹介しました。 従来では紙の書類をスキャンした押印画像から、押印部分を透過画像に変換する作業を画像変換ソフトなどを用い数時間かけて作業をしていました。この作業時間短縮のため、 Amazon Q Developer を活用し、画像編集ソフトで手作業していた業務を自動化されています。 続いて、 障害発生時のリスク分析 として、修正前後 ( before / after ) のソースコードを Amazon Q Developer に渡し、「この変更にはどのようなリスクが潜在するか」を問いかけるという、レビュー支援ツールとして利活用できるか検証されていました。人間が特定した原因と同じ問題を、ソースコードと一行のプロンプト”問題があれば指摘してください”だけで特定できたとのことです。この結果を受け、レビュー観点の追加だけではなく、潜在的リスクを早期に検出できるツールとして利用を検討されています。 図3：レビュー支援ツールとしての利用レポート 最後に、 既存プログラムの理解 として、引き継ぎや保守で読み解く必要のあるソースコードを Amazon Q Developer に解説させ、キャッチアップ時間を大幅に短縮されていました。説明時に、以下のようにコメントされていました。 「人間だと理解してドキュメントを作成するために、2週間は必要であった時間が1日で実用レベルのドキュメントを作成することができました。」 図4:既存プログラム理解のレポート 図5:既存プログラムの画面イメージ 久保田 氏の使い方は、「生成 AI はコードを書くためのもの」という固定観念を超え、 開発者の思考を拡張するパートナー として位置付けている点が印象的です。 事例 3：前田 隆憲 氏 – 既存資産の分析から業務ツール内製まで – 前田 氏は、より高度で専門性の高い領域に Amazon Q Developer を活用されています。 ログ／テレメトリーの分析 として、 Amazon Q Developer の利用データを Amazon S3 へ保存する設定をしています。そのため、ユーザー単位で利用状況が csv ファイルとして保存されます。この保存される膨大なログファイルやテレメトリーデータを Amazon Q Developer に読み込ませ、利用状況分析を行っています。 リバースエンジニアリング でも活用されています。既存ソースコードから画面遷移図や ER 図を生成し、ドキュメントが失われた既存システムの保守性を向上されています。また、 プロジェクトルール を活用することで、機能ごとに作成させる設計書のフォーマット統一を図るなど工夫されています。 図6：プログラムから設計書の作成 FSL がソリューションを導入する際の 見積もりツールの開発 にも Amazon Q Developer を利用しています。情報を入力することで、お客様もしくは社内向けに提示する費用を算出することができ、さらに、PDF化することで印刷して見積書としても利用できるツールとなるように開発をされています。 図7：作成中の見積もりツール画面イメージ 前田 氏の事例は、 Amazon Q Developer を「開発の隣にいるアシスタント」から、 業務プロセスに組み込まれたインフラ へと昇華させている点が特徴的でした。 勉強会参加者の声 「事例紹介や演習問題を通して、現在の業務の中で活用シーンはありそうなので、積極的に活用していきます。」 「画面の基本的な利用手順から具体的なチャットへの入力内容を確認できてスタートできそうです。事例では、具体的な入力イメージができました。」 「Amazon Q Developer は、コードを書くときだけでなく、調べる・考える・まとめるといった周辺業務全てに効いてきます。一度使い始めると、もう手放せません」 利用者拡大と Kiro への展開 50 を超えるユーザーでの活用成功と、社内から自然発生的に広がる多様なユースケースを受け、FSL は次のステップとして Amazon Q Developer の利用者数拡大、そして Kiro による次世代の開発体験の取り込みへと舵を切ろうとしています。 Kiro は、仕様からコードまでを一気通貫で扱える、スペック駆動の AI 開発ツールです。Amazon Q Developer で「部分最適」の効率化を積み重ねてきた FSL にとって、Kiro は要件定義から設計・実装・テストまでを横断的に変革する、次なるレバレッジ・ポイントとなります。業務効率化ツールの延長ではなく、 SDLC(ソフトウェア開発ライフサイクル) 全体を再設計する挑戦 が始まろうとしています。 今後の展望：業務効率化から、新しい企業価値の創出へ FSL の旅路は、コーディングエージェントの導入が「開発者の作業を速くする」ことだけに留まらないことを示されていると考えます。今回事例として紹介いただいたものは、 生産性向上に留まらず、自身のお客様へ提供する価値そのものを変えていく動き になっている点が特徴的でした。FSL は今後、Amazon Q Developer の利用者拡大と Kiro の導入も通じて、働き方のイノベーションを起こすことを目指していかれる予定です。生成 AI を導入し利用する本当の目的は、業務や携わっている事業にどのように価値を与えるかにあります。FSL の事例が示すように、現場の一人ひとりが「まずやってみる」を積み重ねることで、自身の業務から事業、さらには、企業全体の変革が形になっていきます。 AWS は、Amazon Q Developer や Kiro をはじめとするコーディングエージェントや生成 AI サービスを通じて、お客様ならではの価値創出の旅路を引き続きサポートしてまいります。生成 AI を活用した開発変革について、ぜひ AWS の担当者にご相談ください。 川﨑 裕希 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。IoTやエッジデバイスに興味があり、エッジ推論の検証が最近の趣味です。 <!-- '"` -->

2026 年 04 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS IAM Identity Center 導入 デモンストレーション編 複数の AWS アカウントへのアクセスを一元管理できる AWS IAM Identity Center について、アクセスポータルを利用したコンソールアクセスや、AWS CLI での一時認証情報の利用方法をデモンストレーションを交えてご紹介します。本セッションでは導入デモンストレーション編として、アクセスポータルからの権限の切り替えや、AWS CLI 経由でのユーザー認証によるコマンド実行など、具体的な利用の流れについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 IAM ユーザーの代わりに、AWS IAM Identity Center のご利用を考えている方 AWS IAM Identity Center がどのようなサービスか知りたい方 本 BlackBelt で学習できること AWS IAM Identity Center でのユーザー認証からマネジメントコンソールアクセスまでの流れについて理解 AWS IAM Identity Center を用いて AWS CLI を利用する流れについて理解 スピーカー 大平 修慈 アソシエイトセキュリティコンサルタント AWS IAM Identity Center 導入 説明編 AWS IAM Identity Center は、複数の AWS アカウントやアプリケーションへのアクセス管理を一元管理できるフルマネージド型の AWS サービスです。 本セミナーでは、AWS IAM Identity Center の概要や特徴、主要な構成要素について解説いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 IAM ユーザーの代わりに、AWS IAM Identity Center のご利⽤を考えている⽅ AWS IAM Identity Center がどのようなサービスか知りたい⽅ 本 BlackBelt で学習できること 本セミナーを受講することで、AWS IAM Identity Center の概要、特徴、主要な構成要素について学習することができます。 スピーカー 松谷 圭 セキュリティコンサルタント AWS IAM Identity Center 設計構築 デモンストレーション編 複数の AWS アカウントとアプリケーションへのアクセスを一元管理する AWS IAM Identity Center について、外部 ID プロバイダーとの連携設定をハンズオン形式で解説します。 また、AWS IAM Identity Center に関連する AWS サポートによくある質問と回答について紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 * AWS IAM Identity Center と既存の ID プロバイダー（Microsoft Entra ID 等）との連携を検討している管理者の方 ユーザー管理の運用コストを削減しながらセキュリティを強化したい管理者の方 本 BlackBelt で学習できること * AWS IAM Identity Center と外部 ID プロバイダー（Microsoft Entra ID）を連携させる具体的なメリットについて SAML によるシングルサインオン設定、SCIM による自動プロビジョニング、許可セットの作成と割り当といった一連の構築手順の概要について スピーカー 松﨑 明 クラウドサポートエンジニア AWS IAM Identity Center 設計構築 説明編 複数の AWS アカウントへのアクセス管理を一元化できる AWS IAM Identity Center について、導入時の設計ポイントや外部 ID プロバイダーを利用した構成例・設定例をご紹介します。 本セッションでは設計構築 説明編として、利用リージョンや ID ソースの選択、許可セットの設計、SAML/SCIM を用いたシングルサインオンの構成について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS IAM Identity Center の設計や構築をはじめられる方 AWS IAM Identity Center の構成例を知りたい方 本 BlackBelt で学習できること AWS IAM Identity Center の導入時の設計ポイント（利用リージョン、インスタンス、ID ソースの選択）について理解 外部 ID プロバイダー（Entra ID）を利用した構成例と設定手順について理解 許可セットの設計とユーザーへの割り当てによるマルチアカウントのアクセス管理について理解 スピーカー 西田　直弘 クラウドサポートエンジニア Amazon FSx for NetApp ONTAP Part1 Amazon FSx for NetApp ONTAP は、NetApp ONTAP の機能を、AWS サービスのクラウド特有のシンプルさ/敏捷性/スケーラビリティとともにご利用いただけるサービスです。本セミナーでは Part1/Part2 の二部構成で、概要から技術詳細、設定手順まで一挙にご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon FSx for NetApp ONTAP をこれからご利用予定の方 SMB や NFS の共有ファイルサーバの知識をお持ちの方 現在 NetApp ONTAP をご利用中の方 NetApp ONTAP の提案や実装に携わる方 AWS のファイルストレージサービスをすでにご利用の方でより理解を深めたい方 本 BlackBelt で学習できること 本セミナーでは Amazon FSx for NetApp ONTAP の概要/技術詳細/設定手順について二部構成で網羅的に学習いただけます。 スピーカー 辻 佑一郎 クラウドサポートエンジニア Amazon FSx for NetApp ONTAP Part2 Amazon FSx for NetApp ONTAP は、NetApp ONTAP の機能を、AWS サービスのクラウド特有のシンプルさ/敏捷性/スケーラビリティとともにご利用いただけるサービスです。本セミナーでは Part1/Part2 の二部構成で、概要から技術詳細、設定手順まで一挙にご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon FSx for NetApp ONTAP をこれからご利用予定の方 SMB や NFS の共有ファイルサーバの知識をお持ちの方 現在 NetApp ONTAP をご利用中の方 NetApp ONTAP の提案や実装に携わる方 AWS のファイルストレージサービスをすでにご利用の方でより理解を深めたい方 本 BlackBelt で学習できること 本セミナーでは Amazon FSx for NetApp ONTAP の概要/技術詳細/設定手順について二部構成で網羅的に学習いただけます。 スピーカー 辻 佑一郎 クラウドサポートエンジニア re:Invent 2025 通信業界向け recap シリーズ CX 編 CX の改善に向けた Agentic AI 及び業界特化 LLM の活用 通信業界における CX の改善について、AWS re:Invent 2025 で発表されたアップデートを踏まえた Agentic AI 及び業界特化 LLM の活用などのアプローチや、お客様の事例を交えてご紹介致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界において CX 領域に携わる方、Agentic AI を活用した CX の改善に関心がある方、業界特化 LLM を活用した CX 改善に関心がある方を主な対象としております。 本 BlackBelt で学習できること 通信業界における CX 領域の課題の概要、 Agentic AI 及び業界特化 LLM を活用した通信業界における CX 領域の課題に対するアプローチを、お客様の事例を交えて学ぶことができます。 スピーカー 松岡雄地 ソリューションアーキテクト re:Invent 2025 通信業界向け recap シリーズ セキュリティ編 ⽣成 AI で変⾰する 通信事業者のセキュリティ運⽤ AWS re:Invent 2025 で発表された AWS の生成 AI を活用した通信業界におけるサイバーセキュリティ運用の技術が、通信事業者のセキュリティ運用をどのように変革していくのか、事例も交えてご紹介致します 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界に携わる方、通信ネットワークのサイバーセキュリティに関心のある方、通信ネットワークのセキュリティ運用において 生成 AI の活用をしたいと考えられている方を主な対象としております。 本 BlackBelt で学習できること 通信ネットワークのセキュリティ運用において AWS の生成 AI をどのように活用することができるか、またその活用事例をお届けします スピーカー 岡本 篤志 ソリューションアーキテクト re:Invent 2025 通信業界向け recap シリーズ ネットワーク編 ハイブリッドアーキテクチャによる ネットワークのモダナイゼーション モバイルネットワークにおけるクラウドとオンプレミスのハイブリッド構成を実現する方法について AWS re:invent 2025 で紹介された事例を交えてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界に携わる方 、モバイルネットワークにおけるクラウド活用を検討している方、オンプレミスとクラウドのハイブリッドアーキテクチャに関心のある方を対象としております。 本 BlackBelt で学習できること モバイルネットワークをクラウドへ移行するメリット、実現に必要なオンプレミスとクラウドのハイブリッドサービス、お客様事例を学ぶことができます。 スピーカー 伊藤 広記 ソリューションアーキテクト re:Invent 2025 通信業界向け recap シリーズ ネットワーク運用編　 Agentic AI を活用した通信ネットワーク運用の自律化 AWS re:Invent 2025 で発表された通信ネットワーク運用の自律化を Agentic AI を活用してどのように実現できるか、について参考アーキテクチャと事例も交えてご紹介致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界に携わる方、通信ネットワークの運用における自動化/自律化に関心のある方、通信ネットワークの運用における Agentic AI の活用したいと考えられている方を主な対象としております。 本 BlackBelt で学習できること 通信ネットワークの運用における課題、Autonomous Network の実現に向けた AWS の活用方法、Autonomous Network を実現するための参考アーキテクチャ、お客様事例をお届けいたします。 スピーカー 宮崎 友貴 ソリューションアーキテクト re:Invent 2025 通信業界向け recap シリーズ 移行 / モダナイズ編　 AI を活用した通信ワークロードの移行とモダナイゼーション AWS re:Invent 2025 で発表された AI を活用した通信ワークロードの移行 / モダナイゼーション技術が、通信業界のデジタル変革をどのように加速させるかを、事例も交えてご紹介致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 通信業界に携わる方、レガシーなシステムを担当しており AWS クラウドへの移行 / モダナイゼーションに関心のある方、AWS クラウドへの移行 / モダナイゼーション向けに AI エージェント / Agentic AI の活用に関心のある方、を主な対象としております。 本 BlackBelt で学習できること 通信ワークロードのクラウド移行へ課題、クラウド移行への AI 活用、AWS を活用した移行とモダナイゼーションの実現、及びお客様事例をお届け致します。 スピーカー 黒田　由民 ソリューションアーキテクト

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 AWSが提供するAIエージェント搭載の統合ワークスペース「Amazon Quick」をご存知でしょうか？自然言語で質問・指示するだけで、社内データの検索・分析・業務自動化をひとつの画面で完結できるサービスです。5月26日（火）に東京・赤坂にて、Amazon Quickの導入を検討中の企業向けに、複数のパートナー企業の支援内容を半日で比較検討できるイベント「 Amazon Quick で実現するAI業務変革 — 半日で一気見できるパートナーエクスポ 」が開催されます。最新機能デモ、業界別ハンズオン、パートナーセッションと盛りだくさんの内容です。定員制のため、ご興味ある方はお早めにご登録ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年5月11日週の主要なアップデート 5/11(月) AWS Transform が移行時の自動コンテナ化に対応 AWS Transform が、AWS への移行時にアプリケーションをコンテナにリプラットフォームする機能を追加しました。エージェンティック AI を活用してソースコードのコンテナ化を自動化し、移行とモダナイゼーションを並行実行できます。GitHub、Bitbucket、GitLab、または zip ファイルからソースコードを取り込み、Dockerfile の生成、Docker イメージのビルド、Amazon ECR への公開、Amazon ECS または Amazon EKS へのデプロイまでを一連のワークフローで実行します。これにより、オンプレミスからクラウドネイティブアーキテクチャへの移行にかかる時間と複雑さを削減できます。 Claude Platform on AWS が一般提供開始 AWS は、Anthropic のネイティブ Claude Platform を AWS アカウント経由で直接利用できる新サービス「Claude Platform on AWS」の一般提供を開始しました。AWS は Claude Platform のネイティブ体験を提供する初のクラウドプロバイダーです。このサービスでは、既存の AWS アカウント、IAM 認証、CloudTrail 監査、統合請求を活用しながら、Anthropic が運用する Claude API、コンソール、ベータ機能に直接アクセスできます。データ処理は Anthropic が管理するインフラ上で行われ、AWS セキュリティ境界外で処理される点が Amazon Bedrock との主な違いとなります。18 のリージョンで利用可能です。 ENA Express for Amazon EC2 が Availability Zone 間トラフィックに対応 Elastic Network Adapter (ENA) Express が、同一リージョン内の異なる Availability Zone (AZ) 間トラフィックに対応しました。これにより、クロス AZ 通信での単一フロー帯域幅が従来の 5 Gbps から最大 25 Gbps に向上します。ENA Express は AWS Scalable Reliable Datagram (SRD) プロトコルを使用し、マルチパス経路選択と高度な輻輳制御により、分散ストレージ、データベース、ファイルシステムなどのマルチ AZ 構成でのネットワーク性能を改善します。追加コストは発生せず、TCP/UDP プロトコルに対応し、アプリケーションの変更は不要です。 5/12(火) Amazon Redshift が AWS Graviton 搭載の RG インスタンスを発表 Amazon Redshift は、AWS Graviton プロセッサを搭載した新世代のプロビジョンドクラスタノード「RG インスタンス」の一般提供を開始しました。RG インスタンスは、データウェアハウスおよびデータレイクワークロードを前世代の RA3 インスタンスと比較して最大 2.4 倍高速に実行し、vCPU あたりの価格を 30% 削減します。カスタムビルドされたベクトル化データレイククエリエンジンをクラスタノード上で直接実行するため、Redshift Spectrum の別スキャンフリートと スキャンデータ量に応じた TB 単位の課金が不要になります。26 の AWS リージョンで rg.xlarge と rg.4xlarge の 2 つのインスタンスサイズで利用可能です。 Amazon CloudFront Premium flat-rate plan で設定可能な使用量上限をサポート Amazon CloudFront Premium flat-rate plan が、複数の使用量レベルに対応しました。従来は単一の使用量上限のみでしたが、現在は月間リクエスト数 5 億 ～ 60 億、データ転送量 50 TB ～ 600 TB の範囲で、6 つのレベルから選択できます。CloudFront コンソールで即座に使用量レベルを変更でき、年間コミットメントは不要です。すべての Premium プラン機能は、どの使用量レベルでも利用できます。 Karpenter が Amazon Application Recovery Controller の zonal shift をサポート Amazon EKS で Karpenter を使用する際に、Amazon Application Recovery Controller (ARC) の zonal shift および zonal autoshift がサポートされました。これにより、AZ 障害時にクラスタ内のネットワークトラフィックを自動的に健全な AZ へ転送し、Kubernetes アプリケーションの可用性を維持できます。Karpenter は障害 AZ への新規ノード起動と自発的な中断（voluntary disruption）を一時停止することで、安全なトラフィックシフトを実現します。 AWS Security Agent が full repository code review をサポート AWS は 2026 年 5 月 12 日、AWS Security Agent の新機能 full repository code review をプレビューとして提供開始しました。この機能はコードベース全体に対して、AI を活用した深いコンテキスト認識型のセキュリティ分析を実行します。従来のパターンマッチング型の静的解析ツールとは異なり、アプリケーションのアーキテクチャ、信頼境界、データフローを理解して、パターンマッチングでは見逃される体系的な脆弱性を検出します。脆弱性が見つかると、具体的なファイルと行番号を指定した修復コードを生成し、チームは従来よりも迅速に脆弱性を特定して修復できます。この機能は、プレビュー期間中、既存の AWS Security Agent 顧客に追加料金なしで提供されます。 AWS Lambda が Lambda Managed Instances での関数の scheduled scaling をサポート AWS Lambda は、Lambda Managed Instances 上で実行される関数に対して、Amazon EventBridge Scheduler を使用した scheduled scaling をサポートしました。この機能により、予測可能なトラフィックパターンに対して、ワンタイムまたは繰り返しのスケジュールを定義し、関数のキャパシティ制限を事前に調整できます。ピーク時のパフォーマンス目標を達成しながら、アイドル期間のコストを削減することが可能になります。すべての Lambda Managed Instances サポートリージョンで利用できます。 5/13(水) Amazon RDS for Oracle が M8i と R8i インスタンスで Oracle SE2 License Included に対応 Amazon RDS for Oracle が M8i と R8i インスタンスで Oracle Database Standard Edition 2 (SE2) License Included に対応しました。これらのインスタンスは AWS 専用の Intel Xeon 6 プロセッサを搭載し、前世代の Intel ベースインスタンスと比較して最大 15% のコストパフォーマンス向上と 2.5 倍のメモリ帯域幅を実現します。License Included モデルでは Oracle ライセンスを別途購入する必要がなく、サブスクリプション型の従量課金でソフトウェアライセンス、サポート、コンピューティングリソース、マネージドデータベースサービスをまとめて利用できます。 Amazon SageMaker Data Agent が IAM Identity Center ドメインで利用可能に Amazon SageMaker Data Agent が、IAM Identity Center で構成された SageMaker Unified Studio ドメインで利用できるようになりました。Data Agent は、データアナリストやデータエンジニアが自然言語で分析目標を記述すると、Python や SQL コードを自動生成する AI 支援機能です。Amazon Athena、Amazon Redshift、Amazon S3、AWS Glue Data Catalog などのデータソースに対応し、複雑な SQL の JOIN や集計、Python コードを手動で記述する必要がなくなります。ノートブックと Query Editor の両方で利用でき、「Fix with AI」機能により実行エラーの自動診断と修正提案も行います。全 15 リージョンで利用可能です。 5/14(木) Amazon RDS for PostgreSQL がマイナーバージョン 18.4、17.10、16.14、15.18、14.23 をサポート Amazon RDS for PostgreSQL が 2026年5月14日に最新マイナーバージョン 18.4、17.10、16.14、15.18、14.23 のサポートを開始しました。特に PostgreSQL 18.4 では 11 件の CVE (CVE-2026-6479 など) を含む重要なセキュリティ脆弱性が修正されており、任意コード実行や SQL インジェクションなどの重大な問題に対応しています。また PostgreSQL 18 向けに PostGIS 3.6.3 の postgis_topology サポートが追加され、ネットワーク接続や空間的な隣接関係をデータベース内で直接モデリングできるようになりました。自動マイナーバージョンアップグレードと AWS Organizations Upgrade Rollout Policy を組み合わせることで、数千台規模のデータベースを段階的にアップグレードできます。 AWS CloudFormation と CDK でアカウント・リージョン間のスタック出力参照が可能に AWS CloudFormation に新しい組み込み関数 Fn::GetStackOutput が追加されました。この関数により、異なる AWS アカウントや異なるリージョンにあるスタックの出力値を直接参照できるようになりました。従来の Fn::ImportValue が同一アカウント・同一リージョンに限定され、明示的な Export が必要だったのに対し、Fn::GetStackOutput は Export 不要で、IAM ロールを使用したクロスアカウント参照に対応します。CDK では、クロス参照時に自動的にこの関数を使用するため、以前必要だった Custom Resources や SSM Parameters が不要になり、デプロイデッドロックの問題も解消されます。全 CloudFormation 対応リージョンで利用可能です。 AWS Transform agents が Kiro、Claude、Cursor、Codex で利用可能に AWS は、AI エージェント型のモダナイゼーションサービス AWS Transform を、Kiro power、agent plugins、MCP server を通じて複数の開発環境から利用できるようにしました。開発者は Kiro、Claude Code、Cursor、Codex といった 開発エージェントツールから直接、.NET、VMware、メインフレーム、カスタムコードの変換作業を実行できます。同じ変換ジョブに対して IDE、Web コンソール、MCP 経由でアクセスでき、状態が一貫して管理されます。また IAM ロール認証に対応したことで、既存の AWS 認証情報を使用して Transform 環境、ワークスペース、変換ジョブを作成できるようになりました。 Amazon CloudFront で mutual TLS (Viewer) のパススルーモードを発表 Amazon CloudFront は、viewer mutual TLS (mTLS) 認証のパススルーモードをサポートしました。このモードでは、CloudFront が証明書検証を行わず、クライアント証明書をオリジンに転送してオリジン側で検証を実施します。オリジンで既に mTLS 実装を運用している顧客は、エッジでの検証ロジックを再実装することなく CloudFront を導入できます。パススルーモードは追加料金なしで利用できます。 5/15(金) AWS Interconnect – multicloud with Oracle Cloud Infrastructure (OCI) のパブリックプレビューを発表 AWS Interconnect – multicloud with Oracle Cloud Infrastructure (OCI) のパブリックプレビューを発表しました。このサービスは、クラウドサービスプロバイダー (CSP) 間の専用プライベート接続を数分でプロビジョニングできるサービスです。従来の DIY マルチクラウドアプローチで発生していた、グローバルな多層ネットワークの構築・管理の複雑さを解消します。プレビュー版は us-east-1 リージョンで利用可能で、AWS マネージメントコンソール、CLI、API から作成できます。 Amazon RDS for PostgreSQL Extended Support マイナーバージョン 11.22-rds.20260224、12.22-rds.20260224、13.23-rds.20260224 を発表 Amazon RDS for PostgreSQL は、Extended Support 対象の PostgreSQL 11.22-rds.20260224、12.22-rds.20260224、13.23-rds.20260224 マイナーバージョンをリリースしました。これらのバージョンは、4 つのセキュリティ脆弱性 (CVE-2026-2003、CVE-2026-2004、CVE-2026-2005、CVE-2026-2006) を修正します。標準サポート終了後も PostgreSQL の旧バージョンを実行する必要があるお客様は、これらのバージョンへのアップグレードを推奨します。 Amazon CloudWatch Logs が Logs Insights クエリ結果の上限を 100,000 件に拡大 Amazon CloudWatch Logs が Logs Insights クエリ言語 (QL) で取得できる結果の上限を、従来の 10,000 件から 100,000 件に拡大しました。これにより、大量のログイベントを分析する際に、時間範囲を分割してクエリを実行する必要がなくなります。GetQueryResults API もページネーションに対応し、1 回の呼び出しで最大 10,000 件の結果と次のページを取得するためのトークンを返します。この機能は全ての商用 AWS リージョンで利用できます。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は、2026 年 5 月 1 日 に公開された A guide to Airflow worker pool optimization in Amazon MWAA を翻訳したものです。翻訳はクラウドサポートエンジニアの山本が担当しました。 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は、AWS のフルマネージド Apache Airflow サービスです。Amazon MWAA で Airflow ワーカープールの設定を最適化することは、ワークフロー運用をスケールするうえで重要でありながら見過ごされやすいポイントです。タスクが長時間キューに滞留している場合、ワーカー不足が原因だと考えがちですが、実際には別の根本原因が潜んでいることがあります。スケールの判断は単純ではありません。DevOps エンジニアやシステム管理者は、ワーカーを追加すればパフォーマンスの問題が解決するのか、それとも根本原因に対処せずに運用コストが増えるだけなのかを見極める必要があります。 本記事では、Amazon MWAA におけるワーカースケーリングの判断パターンを、タスクプールの仕組みとワーカー割り当ての関係に焦点を当てて解説します。具体的なシナリオと実践的な判断フレームワークを示し、ワーカーの追加がパフォーマンス課題の適切な解決策かどうか、また適切な場合にどうスケーリングを実装するかの指針を提供します。 主なパターン 本セクションでは、ワーカーの追加が必要かどうかを検討するきっかけとなる、代表的な問題パターンを紹介します。 高い CPU 使用率 Airflow は、外部サービス上のタスク実行を調整・スケジュールするワークフロー管理プラットフォームです。 AWS Glue 、 AWS Batch 、 Amazon EMR など、さまざまなデータ処理システム間のタスクをトリガーおよびモニタリングする中央オーケストレーターとして機能します。Airflow の強みは、データ処理そのものではなく、複数のシステムやサービス間でタスクの依存関係や実行順序を管理できる点にあります。 分析やビッグデータ基盤では、リソースが飽和すると自動的に容量の追加が必要だという誤解がよくあります。しかし Amazon MWAA では、スケーリングの判断に先立って、ワークフローの特性と最適化の余地を理解することが重要です。 ワークフローの規模が拡大すれば、Airflow クラスターのリソース使用率は当然高くなります。ワーカーが常にフル稼働している状況では、コンピューティングリソースの追加が最も手早い対処に見えるかもしれません。しかし、リソース追加は根本的な問題を解決するのではなく、問題を先送りにしてしまうだけです。 たとえば、Amazon MWAA で単一のタスクがワーカーの利用可能な CPU を 100% 消費している場合、ワーカーを追加しても問題は解決しません。タスクが最適化されていないか、より小さな部分に分割されていないためです。そのため、最小ワーカー数を増やしても期待した効果は得られず、運用コストが増加するだけです。 Amazon MWAA ワーカーの CPU またはメモリ使用率が常に 90% を超えている場合、重要な判断ポイントに達しています。対策を講じる前に、根本原因の理解が不可欠です。主に 3 つの対策があります。 水平スケーリング: ワーカーを追加して負荷を分散する。 垂直スケーリング: より大きな環境クラスにアップグレードして、ワーカーあたりのリソースを増やす。 DAG とスケジューリングパターンの最適化: 効率を高めリソース消費を削減する。 各アプローチは異なる根本的な問題に対処するものであり、容量の制約、リソース集約型のタスク設計、ワークフローの非効率のいずれに直面しているかを特定したうえで適切な方法を選択します。最適化戦略のガイダンスについては、 Performance tuning for Apache Airflow on Amazon MWAA を参照してください。 ワーカーの CPUUtilization と MemoryUtilization をモニタリングするには、 Accessing metrics in the Amazon CloudWatch console を参照し、対応するメトリクスを選択してください。 使用パターンを確認できる十分な時間枠を選択する。 期間を 1分 &nbsp;に設定する。 統計を 最大 に設定する。 長いキュー待ち時間 Airflow タスクがキュー状態で長時間滞留し、DAG が予定通りに完了しないことがあります。 Amazon MWAA では、各環境クラスに最小および最大ワーカーノード数が設定されています。各ワーカーには事前設定された同時実行数があり、任意の時点で各ワーカーが同時に実行できるタスク数を表します。この動作は celery.worker_autoscale=(max,min) で制御されます。 たとえば、最小 4 台の mw1.small ワーカーがあり、デフォルトの Airflow 設定の場合、20 個のタスクを同時実行できます (4 ワーカー × 5 max_tasks_per_worker)。システムが突然 20 を超えるタスクの同時実行を必要とすると、オートスケーリングイベントが発生します。Amazon MWAA はワーカーを効率的にスケールする方法を決定し、プロセスをトリガーします。ただし、オートスケーリングプロセスには新しいワーカーのプロビジョニングに追加の時間が必要なため、キュー状態のタスクが増加します。キューイングの問題を軽減するには、以下を検討してください。 ワーカーの CPU 使用率が低い場合、 celery.worker_autoscale=(max,min) の max 値を増やすと、各ワーカーがより多くのタスクを同時処理できるため、タスクのキュー滞留時間を短縮できます。Airflow ワーカーは、自身のシステムリソースの空き状況に関係なく、定義されたタスク同時実行数までタスクを受け取れます。その結果、オートスケーリングが作動する前にワーカーの CPU/メモリ使用率が 100% に達する可能性があります。 ワーカーのタスク同時実行数を増やしたくない場合、最小ワーカー数を増やすことも有効です。利用可能なワーカーが増えることで、より多くのタスクを同時実行できるようになります。 スケジューリングの遅延 新しい DAGの追加は、システムリソースに影響するだけでなく、スケジューリングのばらつきを発生させる可能性があります。環境全体のメトリクスが正常に見えても、リソースの競合によって一部の DAGの実行が遅延することがあります。このばらつきは、特定のタスクが常にキューで長く待機する一方、他のタスクはすぐに実行されるといった状況が発生します。 Amazon CloudWatch メトリクス で、特に DAG の実行数が多い期間において、実行開始時間のばらつきが増加している場合、環境の最適化が必要です。実行パターンとリソース使用率を分析した上で、以下を判断してください。 ワーカーの追加はワークロードの分散に役立ちますが、高いリソース使用率が DAG のパースやスケジューリングのオーバーヘッドではなく、主にタスク実行の負荷によるものである場合に最も効果的です。最小ワーカー数を増やすと、より多くのタスクを並列実行できます。たとえば、 AWS/MWAA/ApproximateAgeOfOldestTask の値が着実に増加している場合、ワーカーがキューからのメッセージを十分な速度で消費できていないことを意味します。さらに、 AWS/MWAA/QueuedTasks をモニタリングして同様のパターンを特定することもできます。 環境クラスのアップグレードにより、スケジューリング容量が向上します。スケジューラーに負荷の兆候が見られる場合や、すべてのコンポーネントでリソース使用率が高い場合は、より大きな環境クラスへのアップグレードが最適な解決策かもしれません。スケジューラーとワーカーの両方により多くのリソースが提供され、DAG の複雑さとボリュームの増加に対応できます。検証するには、 AWS/MWAA/CPUUtilization と AWS/MWAA/MemoryUtilization のクラスターメトリクスで Scheduler 、 BaseWorker 、 AdditionalWorker メトリクスを選択してください。 DAG スケジュールの再構成により、リソース競合を削減する。 重要なのは、ワークフローパターンを理解し、スケジューリングの遅延がワーカー容量の不足によるものか、その他の環境上の制約によるものかを特定することです。 アンチパターン ワーカーを追加することでパフォーマンスが改善するという誤った結論につながりやすい、よくあるアンチパターンを紹介します。 稼働率の低いワーカー Amazon MWAA のパフォーマンスボトルネックを評価する際は、環境をスケールアップする前に、リソース制約と DAG 設計の非効率を区別することが重要です。 Amazon MWAA 環境が 100 タスクを同時実行できる容量を持っていても、キューメトリクス ( AWS/MWAA/RunningTasks ) ではほとんどの時間で 20 タスクしかアクティブでなく、キュー状態のタスクも残っていないことがあります。その場合、ピークワークロード時に既存ワーカーの CPU とメモリ使用率が常に低いかどうかを Amazon CloudWatch で確認してください。リソース使用率が低い場合、通常は DAG 設計、スケジューリングパターン、または Airflow 設定が非効率であることを示しています。 対処には主に 2 つの選択肢があります。 1. ダウンサイズ : ワークロードの増加が見込まれない場合、クラスターが過剰にプロビジョニングされていると判断できます。まず余分なワーカーを削除し、最終的に環境クラスのダウンサイズを検討してください。 2. 最適化 : プールや同時実行数の Airflow 設定を通じて DAG スケジューリングを調整し、システムのスループットを向上させてください。 人為的なボトルネックを生む Airflow 設定の誤り Apache Airflow では、実際のリソース制約ではなく設定によってパフォーマンスボトルネックが発生することがよくあります。コンピューティングリソースの不足ではなく、同時実行数の設定ミスによって DAG の実行が遅延します。 Amazon MWAA を効率的に使用するには、ワーカーとスケジューラーのリソース使用率だけでなく、人為的なボトルネックとなる同時実行数設定も確認する必要があります。1 つの制限的な設定が、より大きな環境や追加ワーカーのスケーリング効果を打ち消してしまうことがあります。システムメトリクスに余裕があるにもかかわらずパフォーマンスが制限されている場合は、Airflow 設定を監査してください。 重要な考慮事項 : Amazon MWAA は、環境クラスを変更してもワーカーの同時実行数設定を自動的に更新しません。スケーリング時にこの動作を理解しておくことが重要です。最初に mw1.small 環境を作成した場合、各ワーカーはデフォルトで最大 5 つの同時タスクを処理できます。medium 環境クラス (デフォルトでワーカーあたり 10 の同時タスクをサポート) にアップグレードしても、インプレース更新された環境では同時実行数の設定は 5 のまま です。新しい環境クラスの容量を最大限に活用するには、同時実行数の設定を手動で更新する必要があります。 このため、環境クラスを更新する際は、同時実行数を制御する Airflow 設定も更新する必要があります。環境クラスのアップグレード後に同時実行数の設定を更新するには、Apache Airflow 設定オプションの celery.worker_autoscale 設定を変更してください。ワーカーが新しい環境クラスでサポートされる最大同時タスク数を処理できるようになります。 また、Amazon MWAA 環境が実際のリソース制限ではなく、 max_active_runs や DAG 同時実行数の制御によって制約されている場合もあります。設定ベースのスロットルは、ワーカーインスタンスにワークロードを処理する利用可能なコンピューティングリソースがあっても、タスクの実行を妨げます。 この 2 つには重要な違いがあります。設定による制限は並列処理の人為的な上限として機能し、真のリソース制限はワーカーが CPU またはメモリ容量をフルに使用していることを示します。どちらの制約が環境に影響しているかを理解することで、設定を調整すべきかインフラストラクチャをスケールすべきかを判断できます。 プール、同時実行数、max_active_runs などの Airflow 設定を調整することで、ワーカーをスケールせずにパフォーマンスの問題を解決できます。制御に使用できる設定の一部を以下に示します。 max_active_runs_per_dag (DAG レベル): 特定の DAG について同時に許可される DAG 実行数を制御します。2 に設定すると、ワーカー容量に余裕があっても同時に 2 つの DAG 実行しか実行できません。追加の実行はキューに入り、ワーカーがアイドル状態でも DAG の実行が遅くなります。 max_active_tasks: DAG 定義の concurrency フィールド (または環境レベルの設定) を制御し、システム全体の容量やワーカー数に関係なく、その DAG から同時に実行されるタスク数を制限します。 プール: プールは、特定の種類 (多くの場合リソース集約型) のタスクが同時に実行できる数を制限します。3 スロットのプールは、そのプールに割り当てられた 3 を超えるタスクをスロットルし、ワーカーをアイドル状態にします。 実行タイムアウトとリトライ: 適切に調整されていない場合、失敗したタスクが不必要にスロットを占有し、スタックしたタスクがワーカースロットをブロックしてキュー処理を遅延させる可能性があります。 スケジューリング間隔と依存関係: 重複する非効率なスケジューリングは、アイドル期間やリソースの過度な競合を引き起こし、実際のスループットに影響する可能性があります。 Airflow 設定の相互上書き Airflow には、同時実行数とスケジューリングを制御する複数のレイヤーがあります。環境レベル、DAG/タスクレベル、プール用のものがあります。より制限的な設定がより許容的な設定を上書きし、予期しないキューの蓄積を引き起こすことがあります。 DAG レベル vs 環境レベル: “max_active_runs_per_dag” (DAG レベル) が環境レベルの “max_active_runs_per_dag” やシステム全体の同時実行数より低い場合、DAG の設定が使用され、環境がより多くの処理を行えるにもかかわらずタスクがスロットルされます。 タスクレベルの上書き: 個々のタスク定義には “max_active_tis_per_dag” などの独自のパラメータを設定でき、グローバル設定より低く設定するとボトルネックを生み出す可能性があります。 優先順位: 任意のレベル (環境、DAG、タスク) で最も制限的な設定が、並列タスク実行の上限を実質的に決定します。 設定場所 設定 タスクスループットへの影響 環境レベル parallelism スケジューラーで実行される最大タスク総数 DAG レベル max_active_runs 同時 DAG 実行の最大数 タスクレベル concurrency その DAG の最大同時タスク数 パフォーマンスの問題はリソース枯渇のように見えることが多いですが、実際には過度に制限的な設定に起因しています。上記のパラメータをすべて慎重に監査してください。制限的な値を段階的に緩和し、クラスターのスケールを決定する前に効果をモニタリングできます。アイドル容量に対して支払うことなく、クラウドリソースを最適かつコスト効率よく使用できます。 メモリリークによる緩やかなリソース枯渇 Amazon MWAA でメモリリークや緩やかなリソース枯渇が発生する一般的なシナリオは、DAG やタスクが時間の経過とともに失敗したり遅くなったりする場合です。ワーカーのスケールや環境サイズの拡大では根本的な問題は解決しません。根本原因は容量不足ではなく、持続的な枯渇を引き起こすアプリケーションレベルのリークであるためです。 たとえば、Airflow がタスクの実行と DAG のパースを継続的に行うと、環境全体のメモリ消費が着実に増加する可能性があります。ワークロードが一定または減少しているにもかかわらず、Amazon MWAA メタデータデータベースの FreeableMemory メトリクスが低下するという形で現れることがあります。メモリリソースがスケジューラー/ワーカーおよびメタデータデータベースで制約されると、データベースクエリのパフォーマンスが徐々に低下し、Airflow はメタデータデータベースに重要な操作を大きく依存しているため、最終的に環境全体の応答性に影響します。アプリケーションがデータベース接続を適切に閉じずに作成し、リソース枯渇に至るのと似た状況です。 グラフ: FreeableMemory と MemoryUtilization の低下(上: メタデータデータベース、下: スケジューラー及びワーカー) 一般的な原因: コネクションプールの枯渇: データベース接続を適切に閉じない DAG は、コネクションプールの枯渇とデータベースのメモリリークを引き起こす可能性があります。 リソース集約型の操作: メタデータデータベースに対する複雑で長時間実行されるクエリや XCOM 操作は、過剰なメモリを消費する可能性があります。 非効率な DAG 設計: トップレベルに多数の Python 呼び出しを持つ DAG は、DAG パース中にデータベースクエリをトリガーする可能性があります。たとえば、タスクレベルではなく DAG レベルで variable.get() を呼び出すと、不要なデータベースの負荷が発生します。 推奨される解決策: Amazon CloudWatch モニタリングの実装: FreeableMemory に適切なしきい値で Amazon CloudWatch アラームを設定し、問題を早期に検出する。 定期的なデータベースメンテナンス: 不要になった履歴データをパージするスケジュールされたデータベースクリーンアップ操作を実行する。 DAG コードの最適化: variable.get() などのデータベース操作を DAG レベルからタスクレベルに移動するよう DAG をリファクタリングし、パースのオーバーヘッドを削減する。 接続管理: すべてのデータベース接続が使用後に適切に閉じられるようにし、コネクションプールの枯渇を防止する。 上記の推奨事項に従うことで、メタデータデータベースのメモリ使用率を健全に維持し、ワーカーをスケールせずに Amazon MWAA 環境の最適なパフォーマンスを維持できます。 まとめ Amazon MWAA 環境でワーカーを追加する判断には、単純なタスクキューメトリクスを超えた複数の要因の検討が必要です。本記事では、ワーカーの追加が特定のパフォーマンス課題に対処できる一方で、システムボトルネックへの最適な最初の対応ではないことが多い点を示しました。 ワーカーをスケールする前に考慮すべき重要なポイント: 根本原因の分析 高い CPU/メモリ使用率がタスク最適化の問題に起因するかどうかを確認する。 キューイングの問題がリソース制限ではなく設定の制約に起因するかどうかを調べる。 メモリリークやリソース枯渇のパターンがないか調査する。 設定の最適化 Airflow パラメータ (同時実行数の設定、プール、タイムアウト) を確認・調整する。 異なる設定レイヤー間の相互作用を理解する。 DAG 設計とスケジューリングパターンを最適化する。 最も成功している Amazon MWAA の実装は、体系的なアプローチに従っています。まず既存のリソースと設定を最適化し、データに基づくキャパシティプランニングで正当化された場合にのみワーカーをスケールします。信頼性の高いワークフローパフォーマンスを維持しながら、コスト効率の高い運用が実現します。 ワーカーのスケーリングは、Amazon MWAA 最適化ツールキットの 1 つのツールにすぎません。長期的な成功は、適切なモニタリング、プロアクティブなキャパシティプランニング、Airflow ワークフローの継続的な最適化を組み合わせたパフォーマンス管理戦略の構築にかかっています。 次の記事では、環境に追加の DAG を投入する前に実行すべきキャパシティプランニングの手順について説明します。追加の負荷に対する計画を立て、十分なヘッドルームを確保する方法を解説します。 開始するには、 Amazon MWAA の製品ページ と Performance tuning for Apache Airflow on Amazon MWAA ページをご覧ください。 ご質問がある場合や MWAA のスケーリング経験を共有したい場合は、以下にコメントを残してください。 著者について Boyko Radulov AWS のシニアクラウドサポートエンジニアで、Amazon MWAA と AWS Glue のサブジェクトマターエキスパートです。お客様と密接に連携し、コスト削減しながら AWS 上のワークロードの構築と最適化を支援しています。仕事以外では、スポーツと旅行に情熱を注いでいます。 Kamen Sharlandjiev Kamen は、プリンシパルビッグデータおよび ETL ソリューションアーキテクトで、Amazon MWAA と AWS Glue ETL のエキスパートです。複雑なデータ統合やオーケストレーションの課題に直面しているお客様の負担を軽減することをミッションとしています。 Venu Thangalapally シカゴを拠点とする AWS のシニアソリューションアーキテクトで、クラウドアーキテクチャ、データとアナリティクス、コンテナ、アプリケーションモダナイゼーションに深い専門知識を持っています。金融サービス業界のお客様と連携し、ビジネス目標をセキュアでスケーラブルかつコンプライアンスに準拠したクラウドソリューションに変換しています。 Harshawardhan Kulkarni AWS のパートナーテクニカルアカウントマネージャーで、Amazon MWAA のサブジェクトマターエキスパートです。アイルランドのダブリンを拠点に、EMEA のエンタープライズのお客様と連携し、複雑なワークフローやオーケストレーションの課題をナビゲートしながらベストプラクティスの実装を支援しています。 Andrew McKenzie AWS での経験から得た深い技術的専門知識を活用するデータエンジニア兼エデュケーターです。元 Amazon MWAA サブジェクトマターエキスパートとして、現在はデータソリューションの構築とデータエンジニアリングのベストプラクティスの教育に注力しています。

みなさん、こんにちは。今回の月刊 AWS 製造を担当させたいただきます。自動車・製造ソリューションアーキテクトのミカエルです。 今月は、製造関連のビッグイベントである 2026 年のハノーバーメッセの他に、開催予定のイベントや直近 1 カ月に発表された製造関連のブログ・サービスアップデート・事例などをお届けしています。 ピックアップトピック HANNOVER MESSE 2026 2026 年 4 月 20 日 〜 24 日 に開催された Hannover Messe&nbsp;2026 で、AWS は今年も様々な展示を行いました。AWS&nbsp;の自動車・製造のリーダーである&nbsp; Ozgur&nbsp;Tohumcu&nbsp;の基調講演 では、Volkswagen のデジタル生産プラットフォームを用いた 43 工場における AI の取り組みを紹介し、産業 AI を実務展開する重要性を語りました。 デジタル主権、AI エージェント、フィジカル AI、炭素排出モデルに関する 4 つの講演と 3 つのマスターコースセッションを行いました。 ドイツのロボティクススタートアップ NEURA Robotics との フィジカル AI 分野での協業 や、Infor との ERP でのエージェント AI 活用 が発表されました。 AWS のブースでは、フィジカル AI を始めとした産業 AI の実務適用に向けた様々なデモや、 欧州主権クラウド や、Amazon のサプライチェーンやロボティクスにおける AI 活用の事例を含む 47 に及ぶデモ展示、52 の シアターセッション を実施しました。ブースデモの内容については、 こちらのブログ でご紹介していますので、併せてご覧ください。 AWS Summit Japan 2026 今年の AWS Summit Japan では、製造業向けにはハイライト展示とインダストリ展示を用意させていただいています。 ハイライト展示では、「AI で加速する製造業のルネッサンス」というテーマで、製造業の普遍的な目標であるばらつき低減、迅速な意思決定、生産能力向上を、仮想化・AI・データ統合という最新技術で飛躍的に向上させる「製造業のルネッサンス」を体験できる展示です。サプライチェーンの需要・リスクの予測、工場のボトルネック特定、制御プログラムを含むシミュレーション検証、設備への安全なデプロイ、PLM データを活用した学習レス外観検査まで、AI によって得られる製造現場での新しい能力を実機デモで紹介します。 インダストリ展示では、いくつかの AWS とパートナーのソリューションを紹介します。 直近での開催予定のイベント 5/26 Amazon Quick で実現する AI 業務変革 — 半日で一気見できるパートナーエクスポ Amazon Quick の導入を検討中の企業の DX 推進責任者・IT 部門責任者向けに、多数のパートナー企業が一堂に会し、それぞれの強みと伴走支援サービスをご紹介します。本イベント主催側による最新機能デモと業界別実践ハンズオンに加え、各パートナーの専門性を直接比較・相談できる機会です。一日で複数のパートナーの比較検討できるため、導入判断に必要な情報を効率的に収集し、業務改善への第一歩を早期に踏み出すことができます。 6/25 – 6/26 AWS Summit Japan 2026 今年も日本最大の “AWS を学ぶイベント” AWS Summit Japan が 6 月 25 日（水）、26 日（木）の二日間で開催されます！ベストプラクティスの共有や情報交換のこのチャンスにぜひご来場ください。ご登録は&nbsp; こちらのリンク からお願いします。 製造関連ブログの紹介 4/13 荏原製作所様と共催！社内クラウドイベント「Ebara Cloud Day」開催レポート クラウドに対する心理的障壁を取り除き、社内のクラウド活用文化を醸成することを目的に、2026 年 3 月 25 日にオンラインで開催されました。AWS によるクラウド基礎セッションに加え、社内エンジニア 5 名による LT（新入社員研修での EC2 構築、EC2 運用、中国リージョン導入、Kiro を活用したツール開発、EventBridge/Lambda によるコスト半減事例）が発表され、満足度 4.27/5.0、次回参加意向 100% という高い成果を達成。IT 部門が「クラウドの旗振り役」として社内に認知される契機となった事例です。 AI-DLC は開発をどう変えるか – ブラザー工業エンジニアが語る AI-DLC 体験記 ブラザー工業のエンジニア 4 名が、AI-DLC（AI 駆動開発ライフサイクル）体験会に参加した感想をインタビュー形式で語るブログ記事です。 2026 年 2 月・3 月に各3日間実施された体験会では、要件定義から実装まで開発の全フェーズで AI を活用する新しい働き方を実践。参加者からは「コーディング支援の枠を超えた開発手法の変革」「企画と開発の距離が縮まる」といった驚きの声が上がる一方、ドメイン知識や「問いかける力」の重要性、ジュニアエンジニアの成長機会確保といった AI 時代ならではの課題も浮き彫りになりました。組織展開に向けた具体的な戦略も議論されています。 4/14 パナソニック エレクトリックワークス株式会社の新組織立ち上げに向けた取り組み – AI 駆動開発ライフサイクルと AI 成熟度診断の実践 このブログでは、その立ち上げに向けて AWS と連携して実施した2つの取り組み ― わずか2.5日で動作するシステムを構築する「AI-DLC Unicorn Gym」と、日本初実施となる CAF-AI ベースの「AI Foundation Pack」による組織の AI 成熟度診断 ― を紹介しています。企画と開発の壁を越えたチーム協働の実現と、AI 活用戦略の策定に向けた組織的な目線合わせの実践事例です。 4/19 AWS と NVIDIA によるフィジカル AI の加速: シミュレーションと実世界での学習による本番環境向けアプリケーションの構築 AWS と NVIDIA は、フィジカル AI（ロボットや自律システムが物理世界で知的に行動するAI）を本番環境で実用化するためのリファレンスアーキテクチャを発表しました。このアプローチでは、NVIDIA Isaac Sim と Isaac Lab によるシミュレーション上での高速・安全な大規模訓練と、AWS IoT Greengrass や Amazon SageMaker を活用したエッジデプロイ後の実世界データによる継続的なモデル改善を組み合わせることで、シミュレーションと現実のギャップ（sim-to-real ギャップ）を埋めます。これにより、製造・物流・ヘルスケアなどの分野で、開発を加速しコストを抑えながら、運用中も自律的に性能が向上し続けるフィジカル AI システムの構築が可能になります 。 4/28 製造業 × 生成 AI 、8 社の「ここだけの話」がつながり課題解決を加速する — AWS 生成 AI ラウンドテーブル in 大阪 開催報告 2026 年 3 月 31 日に AWS 大阪オフィスで開催された、製造業 8 社（シャープ、ヤマハ、村田製作所、日立産業制御ソリューションズ、コベルコシステム、東洋紡、大日本印刷、ダイキン工業）のクローズド・ラウンドテーブルの開催報告です。社内ツールの現場定着、少人数での AI 推進体制、製造業特有の非構造化データの扱いといった共通課題に対し、各社の実践知が交換された様子が紹介されています。AWS セッションでは Amazon Bedrock AgentCore を活用した AgentOps の 4 ステップ評価フレームワークも紹介されています。 イベント動画のご紹介 4/29 What’s Next with AWS – AWS and OpenAI leaders on Agentic AI | Amazon Web Services AWS と OpenAI が、エージェンティック AI の次なる展開を共有し、エージェントがビジネスやビルダーの働き方をどのように変えているかを示す新機能を発表します。AWS CEO のMatt Garman 氏、AWS Applied AI ソリューション担当 SVP の Colleen Aubrey 氏、OpenAI CRO の Denise Dresser 氏をはじめとするリーダーたちによる率直なディスカッションをご覧ください。AWS と OpenAI のパートナーシップの拡大、Amazon Quick の新機能、そして Amazon での実際の運用から得た知見をもとに構築されたエージェンティック AI ビジネスソリューションファミリーである Amazon Connect についてお聞きください。 製造関連の主要なサービスアップデート 4/17 Engineering Development Hub (EDH) のリリース Hannover Messe での展示と併せて、2026 年 4 月に元 Scale-Out Computing on AWS (SOCA) が EDH に名前を変えました。EDH は、計算集約型ワークロード向けのマルチユーザー環境を容易にデプロイ・運用できるオープンソースソリューションです。豊富なコンピューティングリソース、高速ネットワーク、無制限のストレージ、予算・コスト管理機能を AWS に統合し、キュー、スケジューラ、AMI、ソフトウェアを自由に構成できる UI と自動化ツールを提供します。スケールアウトワークロードの実行環境として、本番対応のリファレンス実装を提供し、複雑な計算問題のシミュレーションに集中できるよう設計されています。 4/20 AWS IoT Greengrass v2.17 が非ルートインストールをサポートし、新しい軽量コンポーネントを導入 AWS IoT Greengrass v2.17&nbsp;が利用可能になりました。Linux&nbsp;システム上で非ルートユーザーとしてエッジランタイムを実行できるようになり、メモリ使用量を大幅に削減した軽量コンポーネントのデプロイが可能になりました。AWS IoT Greengrass&nbsp;は、IoT（モノのインターネット）エッジランタイムおよびクラウドサービスであり、お客様がエッジでデバイスソフトウェアを構築、デプロイ、管理することを支援します。 4/26 Research and Engineering Studio on AWS (RES) 2026.03 のリリース Research and Engineering Studio on AWS (RES)&nbsp;は、管理者がセキュアなクラウドベースの研究・エンジニアリング環境を作成・管理するための、オープンソースで使いやすいウェブベースのポータルです。RES&nbsp;を使用することで、科学者やエンジニアはクラウドの専門知識がなくても、データの可視化やインタラクティブなアプリケーションの実行が可能になります。 RES 2026.03&nbsp;では、管理者が環境の設定と管理をより柔軟に行えるようになりました。管理者は、複数の個別の&nbsp;FSx&nbsp;for ONTAP&nbsp;ボリュームを&nbsp;RES&nbsp;ファイルシステムとしてオンボードできるようになりました。また、DCV&nbsp;トークンの有効期限を設定できるようになり、より長時間のセッションファイルを有効にする場合に便利です。さらに、RES&nbsp;ログインページにアカウント管理ページ、ヘルプドキュメント、利用ポリシーページなどのリソースへのカスタムリンクを最大3つ追加できるようになりました。 4/28 Amazon Connect Decisions のリリース Amazon Connect &nbsp;は、単一製品から、Amazon Connect Decisions (サプライチェーン)、Talent (採用)、Customer (カスタマーエクスペリエンス)、および&nbsp;Health (ヘルスケア)&nbsp;の&nbsp;4&nbsp;つを含めた一連のエージェンティック&nbsp;AI&nbsp;ソリューションへと拡大されました。これらは既存のワークフローで機能するように設計されています。 Amazon Connect Decisions は、サプライチェーンチームが事後対応型のオペレーションからプロアクティブ（先手を打つ）なオペレーションへの転換を支援する、エージェント型 AI 計画・インテリジェンスソリューションです。Amazon の 30 年にわたるオペレーション科学と 25 以上の専門的なサプライチェーンツールを組み合わせ、AI チームメイトがお客様のビジネスに適応し、チームの意思決定から学習し、オペレーションを継続的に改善します。Amazon Connect Decisions は、既存のシステムを置き換えることなくサプライチェーンオペレーションを変革したいと考える、小売、消費財（CPG）、自動車、産業製造業などの幅広い業界のお客様にご利用いただけます。 最後までに読んでいただき、ありがとうございました。来月も 月刊 AWS 製造ブログ をよろしくお願いします。 著者について &nbsp; Mickaël Charneau (シャルノ ミカエル) AWS とパートナーのソリューションを元に、自動車と製造のお客様の業務の効率化とデジタルトランスフォーメーションをサポートしているソリューションアーキテクトです。