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

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

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

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

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

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

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

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

大学生向けのプログラミング学習コミュニティ「POSSE」では、実践的な開発スキルやチームワークの向上を目指して、独自のカリキュラムを提供しています。 その中でもチーム開発は、個人の学習では得られない「チームでものをつくる力」を試される実践プログラムとなっており、約2 カ月間、企業から提示されたリアルな課題のもとで、プロダクト開発に取り組み、その成果を発表します。 2年生・3年生にとって学びの集大成となる取り組みで、要件定義から設計・開発・発表までを一貫して経験します。上級生となる4年生は後輩たちの取り組みに対して相談に乗り、サポートしています。 この記事では、2026年4月12日に開催された決勝戦の模様をお届けします。 POSSEとは 「POSSE」は、株式会社アンチパターンが運営する大学生向けプログラミング学習コミュニティです。関東圏の大学生約 180 名が所属し、学生同士が教え合うコミュニティ形式で学んでいます。 独自カリキュラムによる学習に加え、ハッカソンやチーム開発といった実践的な開発機会を通じて、技術力とチームワークの両方を磨いています。AWS もこの活動を支援しています。 【参考記事】 大学の 4 年間で、即戦力レベルのデジタル人材に。AWS も支援する”人が育つ”コミュニティ「POSSE」 要件定義・開発・チームワーク──学生たちの挑戦が実を結ぶ！ 大学生向けプログラミング学習コミュニティ「POSSE」決勝レポート 開会式 今年もPOSSEチーム開発決勝戦の日がやってきました。2026年4月12日、目黒セントラルスクエアにはPOSSE関係者、新入生候補者、企業審査員など約100名を超える来場者が集まり、昨年を上回る規模での開催となりました。 運営メンバーによる開会の挨拶で幕を開けると、会場は一気に熱を帯びました。今年はPOSSE入会予定の新入生も発表を見に来ており、コミュニティとしての成長を感じさせるイベントとなりました。 会場には、POSSEを卒業された社会人メンバーの姿もあり、後輩たちの発表を見届けようという温かいまなざしが印象的でした。かつて同じ舞台に立った先輩たちが、今度は見守る側として後輩を支えている。そんな光景に、POSSEが大切にしてきたつながりを感じました。 チーム開発発表 運営メンバーによる概要紹介が始まりました。チーム開発概要の説明に先立ち、POSSEというコミュニティが何を目指し、チーム開発がその中でどのような役割を果たしているのかが語られました。POSSEが見据える未来と、そこに向かうためにチーム開発が果たす役割について語られる場面があり、これから始まる発表の意義を改めて感じさせる導入となりました。 チーム開発は、2年生が挑む「初級プログラム」と3年生が挑む「中級プログラム」の 2 部門で構成されています。今年のチーム開発には初級 16 チーム、中級 6 チーム、合わせて 22 チームがエントリーしました。約 8 週間にわたり、テーマ提供企業へのヒアリングを起点に要件定義や設計、開発、そして発表までをチームで走り抜けるプログラムとなっていました。前日（2026年4月11日）の予選で全チームが成果を披露し、審査を経て初級 4 チーム・中級 4 チームが決勝へ駒を進めました。 チーム開発の序盤は、要件定義期間からスタートします。テーマ提供企業へのヒアリングをもとに、誰のどんな課題を解決するのか、本当に必要な機能は何かをチーム内で徹底的に議論します。方向性が固まってから設計・実装に入り、途中のヒアリングで得たフィードバックをもとに軌道修正を重ねながら、動くプロダクトとして仕上げていきます。 今回の初級プログラムのテーマは、主催の株式会社アンチパターン代表・小笹氏が独自に設計した「企業向けオフィス利用可視化ソフトウェア」。ハイブリッドワークが当たり前になった今、自社のオフィスは適正な広さなのかという経営課題に対して、データで意思決定を支援するプロダクトの開発に学生たちは挑みました。開発期間中には計 2 回の要件ヒアリングが設けられ、単に動くものをつくるだけでなく、なぜそれが必要なのかを問い続ける姿勢が求められました。 中級プログラムのテーマは、株式会社リンクアンドモチベーションが提供した「チームの生産性とモチベーションを高めるプロダクト」。 プロジェクトの停滞やメンバーのコンディション低下といった、組織マネジメントの現場で実際に起きている課題に正面から向き合いました。開発期間を通じて計 4 回の要件ヒアリングが行われ、プロダクトの実現可能性や提供価値について踏み込んだ対話を重ねました。 閉会式（結果発表） 全チームの発表が終わり、会場に緊張感が漂うなか、結果発表の時間を迎えました。 「OOPARTS」チーム 初級最優秀賞に輝いたのは「OOPARTS」チームでした。ハイブリッドワーク時代のオフィス最適化をテーマに、オフィス利用データの可視化と分析で経営判断をサポートするプロダクトを提案しました。受賞を受けてメンバーは、家族や友人をはじめ多くの人の支えに感謝を伝えた上で、「最後まで走り切れたのは自分たちだけの力ではない。この経験を通じて大きく成長できたと実感しています」と笑顔で振り返りました。 「marni」チーム 中級最優秀賞に選ばれたのは「marni」チームでした。チームの生産性やメンバーのモチベーションを見える化し、マネージャーが役割の再設計やメンバー間の相互理解を促しながらチーム力を底上げできるプロダクトを提案しました。 受賞を受けてメンバーは「チームのメンバーや周囲の方々に感謝したい」と穏やかに語りました。しかし、その言葉の裏には、昨年の予選で敗退し、悔しさを日記に書き殴った経験を持つメンバーもいました。「あの日があったから、今ここに立てている。諦めなければ来年は決勝に立てる」と、最後に後輩たちへ向けて力強いメッセージを送りました。 講評では、審査員・ゲストそれぞれの立場から温かいメッセージが贈られました。審査基準については「お客様に自信を持って提案できるかどうかで選んだ」と明かされ、ビジネスの現場に直結する視点で評価が行われたことが窺えます。また、「学びが大きいのは、むしろ負けたチームではないか。この経験を記録し、振り返ることで必ず次に活きる」と、結果に関わらず全チームの挑戦に敬意を表する言葉が印象的でした。加えて、「プレゼンテーションの水準が高く、実務の場でも通用するレベルにある」といった評価も寄せられ、学生たちの取り組みに対する期待の大きさが伝わる講評となりました。 AWS 相澤恵奏氏 POSSEの活動を支援する AWS からは、相澤恵奏氏が総評を行いました。「努力は熱中に勝てない」という言葉とともに、悔しさを感じられること自体が熱中の証であると述べ、その情熱を今後も大切にしてほしいとメッセージを贈りました。 基調講演 衆議院議員 平井卓也氏 イベント終盤には、初代デジタル大臣を務めた衆議院議員 平井卓也氏が基調講演に登壇しました。 講演では、インターネットの普及からクラウドコンピューティングの台頭、そして AI の急速な進展に至るまでの技術変遷を概観した上で、AI 時代に求められる姿勢について語られました。平井氏は、AI が既存の業務を担う時代において人間に求められるのは、責任ある意思決定と感性に基づく価値創造であると述べました。 学生たちに対しては、テクノロジーの主導権を自らの手に持ち続けること、すなわち道具としての AI を主体的に活用しながら、自分自身の価値を磨いていく姿勢が重要であると語りかけました。また、変化の激しい時代だからこそ、その変化を楽しんでほしいと前向きなメッセージを贈りました。 さらに、当日の学生たちの発表についても言及し、技術力だけでなく課題解決のアプローチやプレゼンテーションの質を高く評価されました。POSSE の活動については、ともに学び合う中で生まれる深いつながりに価値があると述べ、温かい言葉で講演を締めくくりました。 最後に 今年の決勝戦を振り返ると、印象に残るのは結果そのものよりも、各チームの発表から伝わってくる 8 週間の密度でした。プレゼンテーションの完成度や質疑応答での受け答え、そしてチームワークを語る時の実感のこもった言葉、どれも 8 週間を全力で走り抜けてきたチームにしか出せないものだと感じました。 POSSEで過ごした時間は、社会に出てからもふとした瞬間に立ち返る原点になると思います。あの時チームで悩み抜いた経験、本音でぶつかり合った記憶、そして最後にやり切った達成感、それらは年月が経つほど、自分を支える土台になっていくはずです。 今回の決勝に立った学生たちも、惜しくも届かなかった学生たちも、この 8 週間で得たものをぜひ大切にしてほしいと思います。学生たちのこれからに、大いに期待しています！ 【関連リンク】 大学生向けプログラミング学習コミュニティ「POSSE」 公式サイト 株式会社アンチパターン コーポレートサイト 著者情報 影嶋亮太朗（Kageshima Ryotaro） AWS Cloud Support Engineerとして、AWSサービスを活用したアーキテクチャ設計のお問い合わせや障害対応などに日々取り組んでおり、お客様の技術的課題解決に努めております。スタートアップの支援や次世代デジタル人材の育成とAI領域に興味があり、活動しております。 森 瞭輔（Mori Ryosuke） ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。好きな AWS サービスは Amazon Connect で、業界問わずコンタクトセンター関連の技術支援も行っています。先日念願だったフルマラソン完走を達成することができました。

本ブログは 2026 年 4 月 8 日に公開された Amazon Science Blog “ How Amazon uses agentic AI for vulnerability detection at global scale ” を翻訳したものです。 Amazon の RuleForge システムは、エージェンティック AI を活用して、従来の手法より 336% 速く本番環境向けの検出ルールを生成します。 2025 年、NVD (米国国立脆弱性データベース) には 48,000 件を超える新しい CVE (共通脆弱性識別子) が公開されました。これは、自動化ツールや AI を活用したツールが脆弱性発見に与える影響を反映しています。しかし、セキュリティチームにとっては、新しい脆弱性を把握するだけでは十分ではありません。各開示情報を、大規模で複雑なシステムを保護するのに十分な速度で、堅牢な検出ロジックに変換する必要があります。 そこで AWS が構築したのが RuleForge です。RuleForge は、脆弱性を悪用するコードのサンプルから直接検出ルールを生成するエージェンティック AI システムです。本番セキュリティシステムに求められる精度を維持しつつ、お客様のセキュリティを強化しながら、手動でのルール作成と比較して 336% 速く検出ルールを生成しています。 CVE リポジトリ、ルール生成、検証、フィードバック統合のコンポーネントを示す RuleForge のアーキテクチャ。 開示から防御までのギャップの解消 Amazon では、検出ルールは JSON で記述され、MadPot へのリクエストなどのデータに適用されます。MadPot は、デジタルおとりを使って悪意のあるハッカーの動作を捕捉する世界規模の「ハニーポット」システムです。また、社内の検出システムである Sonaris が検知した、エクスプロイトの試行と思われるものにも適用されます。NVD で公開される高深刻度の脆弱性の数は今後も増加し続けると予想されるため、大規模なセキュリティ運用には AI を活用した自動化が不可欠です。 ルール生成を自動化することで、私たちはそのギャップを埋めながら、対応範囲を拡大しています。チームは現在、従来の手法では不可能だったペースと規模で、高深刻度の CVE を検証済みの検出ルールに変換できるようになり、お客様により包括的な保護を提供しています。 手動の検出ルールワークフロー RuleForge 登場以前、新しい CVE に対する検出ルールの作成は、アナリスト主導の複数ステップから成るプロセスでした。 ダウンロードと分析: セキュリティアナリストは、公開されている概念実証 (PoC) エクスプロイトコード (脆弱性を悪用する方法を示すコード) を見つけ出し、それを調査して攻撃メカニズム、入力、想定される動作を把握 検出ロジックの作成: アナリストは脆弱性を狙う悪意のあるトラフィックを捕捉するルールを作成し、トラフィックログに対するルールの精度を測定するクエリを記述 検証とイテレーション: アナリストはこれらのクエリを実行し、結果を確認し、誤検知 (False Positive) を減らすためにルールを調整するという作業を、ルールが本番環境で十分に機能するまで繰り返し ピアレビューとデプロイ: 最後にアナリストは、デプロイ前に別のセキュリティエンジニアによるコードレビューを受けるためにルールを提出 このワークフローは高品質なルールを生み出す一方で、時間がかかるため、チームはどの脆弱性を最初にカバーするかを慎重に優先順位付けする必要がありました。 エージェンティック AI パイプラインとしてのルール作成の再構築 RuleForge は、このワークフローをエージェンティック AI システムとして再構想したものです。検出ルールの生成、評価、改良を協調して行う特化型 AI エージェント群で構成されており、最終承認には引き続き人間が関与します。単一のモデルでエンドツーエンドに問題を解決しようとするのではなく、RuleForge はタスクを人間の専門家の働き方を模した段階に分解します。 自動取り込みと優先順位付け: RuleForge は、特定の脆弱性を狙う方法を示す公開済みの PoC エクスプロイトコードをダウンロードします。コンテンツ分析と脅威インテリジェンスソースを使用して各エクスプロイトをスコアリングします。これにより、ルール生成が最も重要な脅威に集中することが保証されます 並列ルール生成: 優先順位付けされた各 CVE について、AWS Fargate 上で Amazon Bedrock を使用して動作するルール生成エージェント (generation agent) が、複数の検出ルール候補を並列に提案します。各候補は、後段のステージからのフィードバックに基づいて複数のイテレーションで改良できるため、システムは最も有望なものを選択する前に、さまざまな検出戦略を検討できます。一人の専門家がルールを 1 つずつ作成するのに頼るのではなく、RuleForge は検出エンジニアリングを、AI が選択肢を提案し人間がデプロイの可否を決定するパイプラインとして扱います AI を活用した評価: 個別のルール評価エージェント (evaluation agent) が各候補をレビューします。これは RuleForge の重要な革新の 1 つです。生成モデル (generation model) が自身の作品を判断するのではなく、RuleForge は専用の「ジャッジ」モデル (judge model) を使用して、人間の専門家が検出ルールを評価する際に用いる 2 つの次元で各ルールをスコアリングします。 感度 (sensitivity): このルールが CVE で説明されている悪意のあるリクエストを検知できない確率はどのくらいか? 特異度 (specificity): このルールが脆弱性そのものではなく、脆弱性と相関する特徴を狙っている確率はどのくらいか? 多段階検証: ジャッジを通過したルールは、段階的に厳格になるテストパイプラインを通過します。合成テストでは、悪意のあるテストケースと無害なテストケースの両方を生成し、基本的な検出精度を検証します。次に、ルールは MadPot などのトラフィックログに対して検証され、期待どおりに動作することを確認します。いずれかの段階で失敗したルールは、理由を説明する具体的なフィードバックとともにルール生成エージェントに送り返され、改善のクローズドループを形成します 人間によるレビューとデプロイ: 最高のパフォーマンスを発揮するルールは、以前と同様にコードレビューに進みます。セキュリティエンジニアがレビューを行い、フィードバックは修正のためにルール生成エージェントに戻されます。本番デプロイ前の最終ゲートには、引き続き人間の判断が残ります RuleForge の 5 × 5 生成戦略を表した図。5 つの並列検出ルール候補、それらの信頼度スコア、および反復的な改良を示しています。システムは複数の候補を同時に生成し、検証結果に基づいて最高のパフォーマンスを発揮するものを選択します。 個別のジャッジモデルが重要な理由 ルール生成モデルに対して自身の検出ルール候補への信頼度を報告するよう求めたところ、生成したほぼすべてのものを良いと判断しました。これは、セキュリティトピックにおける LLM のキャリブレーションが不十分であることを示す研究結果と一致しています。 その解決策は、生成と評価を分離することでした。専用のジャッジモデルを使用することで、真陽性 (True Positive) の検出数を維持しながら、誤検知を 67% 削減できました。 ジャッジを効果的にしたのは、主に 2 つの設計選択です。 否定的な表現が精度を向上させる: 「ルールが悪意のあるリクエストを検知できない確率はどのくらいか?」と尋ねた方が、「ルールがすべての悪意のあるリクエストを正しく検知する確率はどのくらいか?」と尋ねるよりも、より良いキャリブレーションが得られます。LLM は肯定に傾く傾向があるため、評価を問題探しとして組み立てることで、より誠実な評価が得られます ドメイン固有のプロンプトは汎用的なものより優れている: 単にモデルにルールへの全体的な信頼度を評価するように依頼するだけでは、キャリブレーションが不十分になりました。うまくいった質問は、セキュリティエンジニアが実際に注目する観点を組み込んだものでした。たとえば、ルールが相関する表面的な特徴ではなく脆弱性メカニズム自体を狙っているか、ルールがエクスプロイトのバリエーションの全範囲をカバーしているかといった観点です システムは、スコアを説明する推論チェーンも生成します。私たちはこれらの推論チェーンを人間の評価と照らし合わせて評価し、9 つのルールのうち 6 つで AI ジャッジの推論が人間の専門家の推論と一致することを確認しました。たとえば、人間の評価者が「あの SQL インジェクションの正規表現はゆるすぎる」と指摘した際、ジャッジは独立して「正規表現パターンはシングルクォートを含むあらゆるクエリパラメータを捕捉するため、特定の脆弱性だけよりも範囲が広い」と判断していました。 結果と今後の展望 私たちは 2025 年 8 月に信頼度スコアリングシステムをデプロイし、アナリストが新しい検出ルールをデプロイする速度を加速させました。その年の最後の 4 か月間で、RuleForge により、本番セキュリティシステムに必要な高い精度を維持しながら、手動より 336% 速くルールを生成および検証できるようになりました。アナリストの焦点を作成からレビューに移すことで、品質を損なうことなく全体的なスループットを大幅に向上させました。脆弱性開示と防御の間のギャップをこれまで以上に効果的に埋めることで、AWS 上のお客様のワークロードを守るマネージド保護がより速く更新され、より多くの高深刻度の CVE をカバーできるようになっています。 RuleForge は、エージェンティック AI が精度要件を満たしながら、本番規模で人間のセキュリティ専門知識を強化できることを実証しています。重要な革新はアーキテクチャ的なものです。ルール生成とルール評価の分離、単一のモデルではなく複数の特化型 AI エージェントの使用、そして最終承認のためのヒューマンインザループの維持です。脆弱性開示の頻度が加速し続ける中、これらの設計原則は、防御を最新の状態に保つのに役立ちます。 評価方法論や実験結果を含む RuleForge の技術的詳細について詳しくは、 私たちが arXiv で公開している論文 を参照してください。 著者について C. J. Moses C. J. Moses は Amazon の chief information security officer 兼 vice president of security engineering です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

中国 (国番号 +86) へのコンプライアンスに準拠した発信を維持することは、通信規制が進化し続ける中、グローバル企業にとって大きな課題です。 Amazon Connect Customer を使用して中国へ顧客コミュニケーションを行っている場合、コンプライアンスのベストプラクティスを理解し実装することで、サービスの中断を回避し、顧客との関係を保護できます。 あるグローバル旅行サービス企業は、承認済みの電話番号の設定とレート制限の実装によって、Amazon Connect Customer による中国への発信を中断なく維持しています。規制要件が変更された際も、収益と顧客関係の継続を守ることができました。この事例は、適切なツールとアプローチを用いれば、複雑な規制環境でも安心してビジネスを運営できることを示しています。 本記事では、中国へのコンプライアンスに準拠した発信に関する 5 つの重要なベストプラクティスを説明します。承認済み番号の組み合わせの設定、禁止番号タイプの排除、レート制限の実装、発信者 ID の設定、番号検証の実装です。これらのプラクティスに従うことで、通信要件を満たしながら中国の顧客への安定した通話の接続性を維持できます。 中国の通信規制環境 中国の通信キャリアは、国際通話に対して特定の基準を適用しています。正常に運用するには、以下の機能が必要です。要件と適格基準の完全なリストについては、Amazon Connect Customer 管理者ガイドの アウトバウンド発信の制限 を参照してください。 コールバック機能を備えた 直通ダイヤル (DID) 番号 パラメータ設定によるレート制限 発信前の番号検証 コンプライアンスに準拠した発信者識別情報 アウトバウンド発信での承認された番号タイプの利用(フリーダイヤル番号 (TFN) および国際フリーダイヤル番号 (UIFN) を除く) Amazon Connect Customer と AWS のモニタリングおよび検証サービスを組み合わせることで、通話量に関係なく中国への安定した接続を維持しながら、これらの要件を満たすことができます。 コンプライアンス要件の理解 中国のキャリアは、ネットワークの品質とセキュリティを維持するために通信基準を一貫して適用しています。準拠した設定をしない場合、以下の問題が発生するリスクがあり、それぞれの対処が有効です。 顧客コミュニケーションに影響するサービスの中断(例 : 通話切断のリスク) レート制限 [ベストプラクティス 3] によって、承認されたしきい値内に収めることができます 中国への発信機能の利用制限(例 : 中国への発信機能が使えなくなるリスク) 承認済み番号の設定 [ベストプラクティス 1] と禁止された番号タイプの排除 [ベストプラクティス 2] でリスクを軽減できます カスタマーサポートおよび営業チームの運用上の課題(例 : 運用ミスによる非準拠の通話や設定をするリスク) 番号検証 [ベストプラクティス 5] によって、発信前に失敗を防止できます 事業継続性と顧客関係への影響(例 : 発信者 ID が表示されず受信者からの信頼を失うリスク) 発信者 ID の設定 [ベストプラクティス 4] によって、受信者からの信頼を構築できます 本記事の各ベストプラクティスを活用することで、これらのリスクに直接対処できます。たとえば、レート制限によってキャリアに承認されたしきい値内に収めることで、サービス中断のリスクを軽減できます。承認済み番号の設定により、スパムフラグや受信者への課金につながる発信機能の制限を回避できます。 AWS は、規制要件をすぐに満たすためのツールを提供しています。これらのサービスのモニタリングおよび検証機能はプロアクティブな管理をサポートし、発信オペレーションの安定性と信頼性の維持に役立ちます。一方で、これらのツールの使用が適用される通信規制に準拠しているかどうかはお客様の責任で確認が必要です。 成功のための重要なポイント Amazon Connect Customer を使用した中国向け発信をコンプライアンスに準拠して行うには、以下の 5 つのベストプラクティスが不可欠です。最初の 2 つ (承認済み番号の設定と禁止された番号タイプの排除) から始めることを推奨します。残りのステップは、規制に準拠した番号が設定されていることを前提としています。 1. 承認済み番号の設定 達成基準: アウトバウンド発信の 100% が承認済みの DID 番号を使用していること。 番号を中国向けの発信に利用する承認を得るためには、以下の手順に従います。 承認のリクエスト: 正確な電話番号リストを添えて AWS サポート にリクエストを送信します。 サービスの 直通ダイヤル (DID) 番号を使用します。 香港、マカオ、台湾の番号は使用できません。注: この国リストは変更される可能性があります。最新情報は Amazon Connect Customer の ドキュメント を確認してください。 1 つのインスタンスでキャリアが発信機能を停止した場合の影響を軽減するため、複数の Amazon Connect Customer インスタンスに番号を分散させることを検討してください。 コールバック機能の設定 各 DID 番号がインバウンドコールを受信できることを確認します。会社名を明確に伝えるメッセージを再生するインバウンドコンタクトフローを設定します。 コンタクトフロー、キュー、ルーティングポリシーなどの設定変更後にコールバック機能をテストします。 ユースケースの説明を提出 詳細なユースケースの説明を提出します。 Amazon Connect Customer 管理者ガイドの サポートされるユースケース に対して適格性を確認します。 2. 禁止された番号タイプの排除 達成基準: 中国への発信で TFN/UIFN 番号を使用していないこと。 中国のキャリアは、中国へのアウトバウンド発信で以下の 2 つの番号タイプの利用を禁止しています。 フリーダイヤル番号 (TFN): ダウンストリームプロバイダーでスパムフラグが立てられ、レピュテーションスコアの低下や予期しない受信者への課金が発生する可能性があります。詳細については、Amazon Connect Customer 管理者ガイドの アウトバウンド発信の制限 – フリーダイヤル番号 を参照してください。 国際フリーダイヤル番号 (UIFN): 中国のキャリアは、中国へのアウトバウンド使用で UIFN 番号をブロックします。詳細については、Amazon Connect Customer 管理者ガイドの アウトバウンド発信の制限 – UIFN 番号 を参照してください。 対処するため、現在の番号インベントリを監査し、禁止番号を承認済みの DID 番号に置き換えます。 3. レート制限の実装 達成基準: 通話レートが アウトバウンド発信の制限 – 中国のドキュメント に記載された規制上の制限内に収まっていること (たとえば、本記事執筆時点では同一の発信者 ID で 1 分あたり 5 通話以下)。 発信方法に応じて 2 つの実装オプションがあります。 直接アウトバウンド発信の場合: GitHub の AWS Samples にある Amazon Connect Customer Outbound Rate Limiting サンプルなどのレート制限ソリューションを実装します。規制要件に従ってレート制限を設定します。 Amazon Connect Customer のクイック接続設定の場合: クイック接続を使用した中国へのアウトバウンド発信では: Amazon Connect Customer インスタンスで、「キュークイック接続」タイプのコンタクトフローのみを使用します。電話番号クイック接続とユーザークイック接続はサポートされていません。 「キューへの転送フロー」タイプのコンタクトフローを作成します。 新しいコンタクトフローを作成し、コンプライアンスに準拠した中国へのアウトバウンド発信のために「キューへの転送フロー」タイプを選択します。 「電話番号への転送」ブロックを使用してコンタクトフローを設計し、 E.164 形式 (国際電話番号形式) で番号を指定します (例: +86XXXXXXXXXX)。 「電話番号への転送」ブロックを使用し、宛先番号を E.164 形式 (例: +86XXXXXXXXXX) で指定してコンタクトフローを設計します。 前のステップで設定したコンタクトフローに対して、キューとフローを指定してクイック接続を設定します。 キュータイプを指定し、前のステップで作成したキューとコンタクトフローを設定してクイック接続を構成します。 モニタリング: レート制限違反に対するオブザーバビリティとリアルタイムアラートを設定します。たとえば、Amazon Connect Customer と Amazon CloudWatch を使用した以下のアプローチがあります。 Amazon Connect Customer のコンタクトフローログ を有効にします。 CloudWatch ログメトリクスフィルター を作成して通話レートメトリクスを追跡します。 通話が制限に近づいた場合や超過した場合にトリガーされる CloudWatch アラーム を作成します。 リアルタイム可視性のために CloudWatch ダッシュボード を設定します。 通話が制限を超過した際にリアルタイムアラートを受信するために Amazon Simple Notification Service ( Amazon SNS ) 通知を設定します。 4. 発信者 ID の設定 達成基準: アウトバウンド発信の 100% が準拠した発信者識別情報を表示していること。 ステップバイステップの手順については、Amazon Connect Customer 管理者ガイドの アウトバウンド発信者 ID の設定 ドキュメントに従ってください。 5. 番号検証の実装 達成基準: 番号の正確性を検証し、発信の失敗を防止すること。 通話検証には 2 つのアプローチがあります。 初期検証には AWS End User Messaging Phone Number Validate API を使用します。結果はリアルタイムの番号ステータスを反映しない場合があるため、リアルタイムチェックではなく簡易的な初期チェックが必要な場合に適しています。 サードパーティの検証サービス: ほぼリアルタイムの検証が必要な場合は、サードパーティの検証サービスを通話ワークフローに統合できます。発信前に最新の番号ステータスが必要な場合に適しています。利用可能なソリューションについては、 AWS パートナーネットワーク または AWS Marketplace を確認してください。AWS は特定のサードパーティソリューションを推奨していません。要件に基づいてパートナーソリューションを独自に評価することを推奨します。 次のステップ 本記事の要件に照らして現在の番号設定を監査します。非準拠の番号の利用はサービスの即時中断につながる恐れがあります。 AWS サポート を通じて番号の承認リクエストを送信します。 GitHub サンプル または本記事で説明したクイック接続設定を使用してレート制限を実装します。 AWS End User Messaging またはサードパーティサービスを使用して番号検証を設定します。 チームが制限事項と承認済み番号タイプを理解していることを確認します。 継続的な運用として、オブザーバビリティダッシュボードとアラートの維持、要件変更に応じた承認済み番号リストの更新、新しい番号や設定変更後のコールバック機能のテスト、チームの制限事項に対する認識の検証を推奨します。 まとめ 最新のコンプライアンス要件については、Amazon Connect Customer 管理者ガイドの アウトバウンド発信の制限 を参照してください。レート制限の実装については、 Amazon Connect Customer Outbound Rate Limiting サンプルを参照してください。番号検証については、 AWS End User Messaging Phone Number Validate API のドキュメントを参照してください。 コンプライアンスに準拠した中国への発信には、5 つの要素を正しく実装する必要があります。承認済みの DID 番号、禁止されている番号タイプの不使用、キャリアのしきい値内でのレート制限、準拠した発信者 ID、宛先番号の検証です。これらのベストプラクティスを実装することで、サービス中断のリスクを軽減しながら中国の顧客への安定した通話接続を維持できます。 コンプライアンスに準拠した中国への発信オペレーションを確立した後は、顧客にサービスを提供している他の規制市場にもこれらのプラクティスを展開することを検討してください。また、大量発信オペレーションの管理を最適化するために Amazon Connect Customer の アウトバウンドキャンペーン 機能も活用できます。 サポートリソース 最新のコンプライアンス要件と設定手順については、Amazon Connect Customer の ドキュメント を参照してください。 技術的な実装支援については、AWS サポートにお問い合わせください。 ユースケースに合わせた追加のガイダンスについては、AWS アカウントチームにお問い合わせください。 筆者について Vivek は、カナダのバンクーバーを拠点とし、ISV のお客様を支援する AWS のテクニカルアカウントマネージャーです。お客様のクラウドオペレーションの最適化、セキュリティ体制の強化、先進的なテクノロジーの導入を支援しています。Vivek は、AWS 上でコスト効率が高く、Well-Architected なソリューションの構築をお客様が実現できるよう支援することに情熱を注いでいます。仕事以外では、テニスを楽しんだり、さまざまな文化や料理を探求したりしています。 Andrey は、カナダのトロントを拠点とし、AWS の Applied AI &amp; Communications Technical Field Community に所属する Amazon Connect のシニアスペシャリストソリューションアーキテクトです。2015 年にコーポレート IT サポートエンジニアとして AWS でのキャリアを開始しました。その後、エンタープライズサポートリードとして、カナダの公共セクターのお客様を支援しました。現在の役割では、さまざまな業界のお客様と協力し、Amazon Connect を活用したカスタマーエクスペリエンスの向上に取り組んでおり、AWS のテレフォニーソリューションや AI テクノロジーに関するプロアクティブなガイダンスを提供しています。 Avijit は、ロンドンを拠点とし、AWS の戦略アカウント担当のシニアテクニカルアカウントマネージャーです。2019 年にシアトルを拠点とするクラウドサポートアソシエイトとして AWS でのキャリアを開始し、Amazon Connect やサーバーレスサービスなどを専門としていました。現在の役割では、プロアクティブなアーキテクチャガイダンスと運用の健全性の監視を提供し、ビジネスの自動化とオペレーショナルエクセレンスを推進することで、お客様の AWS 上での継続的な成功を加速させています。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

2026 年 5 月 28 日、各種機能を大幅に強化した次世代の AWS Resilience Hub を発表いたしました。これにより、新しいアプリケーションモデル、依存関係の検出・評価、生成 AI を活用した障害モード分析、モジュール型レジリエンスポリシー、組織全体のレポート機能を統合し、包括的な体験を実現します。 数百単位のアプリケーションを運用している組織はいずれも、可用性が最重要課題である一方で、レジリエンス目標の設定、進捗状況の測定、ポートフォリオ全体でのコンプライアンス証明を行う一貫した方法がないという、共通の課題を抱えています。チームごとに採用している基準やツールが異なるため、アプリケーションが実際に期待どおりの水準を満たしているかどうかについて情報共有に苦労しています。 次世代の AWS Resilience Hub はこうした状況を打破します。サイト信頼性エンジニア (SRE) と開発チームがレジリエンスポリシーに関する要件への認識を合わせ、アプリケーションチームがその要件を達成できるよう支援するとともに、テストによってコンプライアンスを証明できるようにします。 AWS Organizations との連携により、チームはレジリエンスの大規模な評価、障害モードの特定、隠れた依存関係の検出、企業全体にわたる進捗状況のレポート作成が可能になりました。 次世代の Resilience Hub は企業によるレジリエンス向上の取り組みを段階的に支援するため、以下の概念を取り入れています。 レジリエンスポリシー : モジュラー型の組み合わせ可能な要件により、レジリエンスに関する要件を設定できます。単一の固定的なポリシーの種類を指定するのではなく、サービスレベル目標 (SLO)、マルチ AZ やマルチリージョンのディザスタリカバリ、データ復旧要件など、アプリケーションにとって重要な要件を選択してポリシーを構築できます。 ビジネスレベルの把握 : ビジネス成果に直結する重要なエンドユーザーパスを通じて、新しいアプリケーションモデリングを使用できます。&nbsp;システムはビジネスアプリケーションを表し、ユーザージャーニーは重要なビジネスパスを示します。また、サービスは AWS リソース、コード、オブザーバビリティに関する要素で構成されるデプロイ可能な単位です。Resilience Hub はそれらを自動的に検出し、リソースの接続関係を示すトポロジにマッピングします。 AI による障害モード評価 : 生成 AI を活用した評価を実行し、自社定義のレジリエンスポリシー、 AWS Well-Architected ベストプラクティス、 AWS Resilience Analysis Framework に照らしてサービスを分析できます。この評価を通じて潜在的な障害モードを特定し、実行可能な推奨事項を得ることができます。 依存関係の検出・評価 : サービスが依存している AWS サービス、内部エンドポイント、サードパーティのエンドポイントを自動的に検出できます。依存関係評価では DNS クエリログ分析を活用し、予期しないクロスリージョン呼び出しや重大なサードパーティ依存関係など、見落としがちな依存関係を特定できます。 次世代 AWS Resilience Hub の活用例 まず、レジリエンスポリシーを設定し、最初のシステムとサービスをセットアップします。その後、障害モード評価を実行して結果を確認し、検出結果に基づいて対応を行います。 開始する前に、Invoker IAM ロールを設定する必要があります。このロールにより、Resilience Hub に AWS リソース、クロスアカウントロール (AWS Organizations を使用しない場合)、または サービスリンクロール (SLR) (AWS Organizations を使用する場合) への読み取り専用アクセス権限が付与されます。&nbsp;また、Resilience Hub は AWS Organizations と統合されており、単一の委任管理者アカウントから組織全体のレジリエンスを管理できます。これにより、企業全体のレジリエンス体制を評価するために個々のアカウントにログインする必要がなくなります。詳細は、AWS Resilience Hub ユーザーガイドの「 前提条件の詳細 」を参照してください。 レジリエンスポリシーを設定するには、 AWS Resilience Hub コンソール の [ ポリシー ] メニューで [ ポリシーを作成する ] を選択します。ポリシー名と説明を入力し、レジリエンス要件を選択します。たとえば、金融アプリケーションで使用されるマルチリージョンのディザスタリカバリ用に再利用可能なポリシーを作成できます (例: 99.95% の可用性 SLO、15 分の RTO、マルチリージョンのディザスタリカバリにおける 5 分の RPO、RTO と RPO の要件に沿ったディザスタリカバリアプローチ)。 データリカバリ要件を選択した場合は、このポリシーに関連付けられたサービスごとに、バックアップから復元する際のデータリカバリ時間目標を設定できます。 ビジネスアプリケーションを表す最初のシステムを作成するには、[ システム ] メニューの [ システムを作成する ] を選択します。システムには、AWS Organizations アカウントアクセスを有効にできます (任意)。 これで、特定のマイクロサービスなど、デプロイ可能なユニットを表すサービスを作成し、それをシステムに関連付けるとともに、Resilience Hub がリソースを検出する場所を指定できます。サービス名 (例: stock-exchange-service ) を入力し、レジリエンスポリシーと Invoker AWS IAM ロール名を選択します。サービスリージョンのほか、リソースタグ、AWS CloudFormation スタック、Terraform ステートファイルの場所、Amazon EKS のクラスターと名前空間などのサービスリソースを選択できます。 このサービスに対する依存関係検出を有効にすると、AWS はサービス内のリソースに関連付けられた VPC の VPC クエリログを分析します。この機能は、サービス詳細ページの依存関係検出設定からいつでも無効にできます。 これで、サービスの作成が完了し、ポリシーが適用された状態で、最初の評価を実行できます。サービスページで [ 障害モード評価を実行する ] を選択し、評価が完了するまで待ちます。 評価中、Resilience Hub は Invoker ロールを引き受け、設定された入力ソースからリソースを読み取り、親子関係を特定し、アプリケーショントポロジサービスにクエリを実行してリソース間の接続関係を示し、データフロー、包含関係、権限を示すトポロジを構築します。 [ サービストポロジ ] を選択すると、グラフ、表、JSON 形式でサービスリソースをサービス機能別に表示できます。 [ 障害モードガイダンス ] を選択すると、障害モード評価の実行中にエージェントに指示を与えるためのアサーションを追加できます。&nbsp;アサーションはエージェントが生成することも、ユーザーが追加することもできます。既存のアサーションを修正して、評価の精度を向上させることが可能です。 評価が完了すると、サービスページの [ 評価 ] タブで検出結果と推奨事項を確認できます。&nbsp;各検出結果からは、障害モードの内容と、それがアーキテクチャにとって重要な理由、修正方法、関連するポリシー要件を把握できます。 推奨事項を実装する場合は [ 解決済みとしてマークする ] を選択します。検出結果がユースケースに当てはまらない場合は、[ 無関係としてマークする ] を選択することもできます。 Resilience Hub をすでに導入済みの場合は、Resilience Hub の移行 API を使用して、既存のアプリケーションを簡単に移行できます。移行 API を使用することで、既存の評価ポリシーを新しいレジリエンスポリシーに変換し、既存のアプリケーションを新しいモデルにマッピングできます。たとえば、複数の関連アプリケーションを、複数のサービスを備えた単一のシステムにマッピングできます。 新機能の詳細は、 AWS Resilience Hub ユーザーガイド をご確認ください。 今すぐご利用いただけます このたび、Resilience Hub が利用可能な AWS 商用リージョンで、次世代 AWS Resilience Hub の一般提供を開始しました。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」をご確認ください。 Resilience Hub は、新しいサービスベースの料金モデルを採用しています。料金には、サービスごとに月 2 回の障害モード評価と、オプションの自動依存関係評価が含まれます。AWS Resilience Hub は無料でお試しいただけます。料金の詳細は、 AWS Resilience Hub 料金ページ をご確認ください。 Resilience Hub コンソール で新しい AWS Resilience Hub をお試しいただき、 AWS re:Post for Resilience Hub または普段ご利用の AWS サポート窓口にフィードバックをお寄せください。 – Channy 原文は こちら です。

4 名の傑出したコミュニティリーダーを、最新の AWS ヒーローとしてお迎えできることを大変うれしく思います。これらのリーダーは、AWS コミュニティの発展を支えるコラボレーションと知識の共有の精神を体現しています。他のビルダーが AWS re:Invent を効果的に活用するのに役立つ AI を活用したツールの構築から、ラテンアメリカにおける最大規模のいくつかの AWS コミュニティの主導や、ブログやイベントを通じたクラウドアーキテクチャに関する深い専門知識の共有まで、その活躍は多岐にわたります。教育、メンターシップ、コミュニティ活動を通じて他者をサポートするこれらのリーダーの献身的な姿勢は、世界中のビルダーにインスピレーションを与えています。 Damiano Giorgi 氏 – パヴィア (イタリア) AI ヒーローである Damiano Giorgi 氏は、AI とその進化に焦点を当てた Cloud Solutions Architect です。オンプレミスシステムエンジニアリングから AWS へと転身し、以来、後悔したことは一度もありません。同氏は AWS User Group Pavia および AWS User Group Milan の運営をサポートしており、個人的なブログである「Bass and Bytes」でコンテンツを共有しています。 Damiano 氏は、ビルダーが自身の興味に合った AWS re:Invent セッションを見つけるのをサポートするために、Amazon Bedrock と Amazon Nova を利用する「Unofficial post:Invent Session Suggester」を開発しました。同氏は、AWS Summit Milan や AWS Community Day Italy のほか、アドリア地域、ギリシャ、オランダなど、欧州各地のカンファレンスで講演しています。 Darryl Ruggles 氏 – オタワ (カナダ) サーバーレスヒーローである Darryl Ruggles 氏は、Cloud Solutions Architect であり、AWS アプリケーションおよび AI/ML アーキテクチャに注力するようになる以前は、長年ソフトウェアデベロッパーとして活躍していました。同氏は、自身のブログ、LinkedIn、公開プロジェクトを通じて、サーバーレス、コンテナ、AI/ML、FinOps に関する知識を共有しています。Darryl 氏は、「Believe In Serverless」をはじめとする多くのオンライン AWS コミュニティで積極的に活動しており、オンラインイベントと実地イベントの両方でコミュニティとの交流を楽しんでいます。 Ricardo Daniel Ceci 氏 – ブエノスアイレス (アルゼンチン) AI ヒーローである Ricardo Daniel Ceci 氏は、アルゼンチン最大の AWS コミュニティであり、約 2,400 名のメンバーを擁する AWS User Group Buenos Aires を率いています。同氏はまた、AWS Community Day Argentina の主要なオーガナイザーであり、AWS Community Leader of the Year 2025 for LATAM に選出されました。Ricardo 氏は、ラテンアメリカ各地のクラウドエキスパート、AWS ヒーロー、デベロッパーアドボケイトとの対話を特集したポッドキャストを配信しています。同氏は、クラウドとウェブ開発において 15 年を超える期間にわたる経験を有しておりち、スペイン語圏のビルダーを支援し、LATAM におけるクラウドと AI の普及を促進することに情熱を注いでいます。 Matias Kreder 氏 – ブエノスアイレス (アルゼンチン) AI ヒーローである Matias Kreder 氏は、AWS Certification Subject Matter Expert (SME) であり、AWS Certified AI Practitioner 試験を含む複数の AI/ML 認定に貢献しました。同氏のジャーニーは AWS DeepRacer から始まり、そこで 3 度ファイナリストに選出されました。同氏はこれをきっかけにして、地域全体でレースイベントや ML に関する講演会を企画するコミュニティ活動に積極的に取り組むようになりました。AWS User Group Leader for Buenos Aires として、同氏は AWS Community Day Argentina 2025 を主催し、LATAM 全域におけるコミュニティイベントにおいて講演しています。 詳細 AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブページ にアクセスしてください。 – Taylor 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 AWS Summit Japan が開催される 6 月 25 – 26 日 まで 1 ヶ月を切りましたね。登録がまだの方は こちら から登録しぜひ来場ください！様々なコンテンツをご用意してお待ちしております！ また最近気軽に参加いただける勉強会として「昼休みの 30 分」を活用した Amazon Quick 勉強会が開催されています。 6 月 3 日 、 6 月 10 日 に予定されていますのでぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、5 月 25 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「寄稿：生成 AI で”探せなかった開示情報”を見つけ出す 〜 JPX の AI 開示情報検索サービス J-LENS〜」を公開 日本取引所グループ（JPX）傘下の JPX 総研様が開発した、上場企業の適時開示情報を対象とした AI 検索サービス「J-LENS」の技術的な仕組みと成果を紹介する寄稿記事です。Amazon Bedrock と Amazon OpenSearch Service を基盤に、クエリ解析・ベクトル検索・リランキングなど多層的な工夫を組み合わせることで、キーワード検索では見つけられなかった情報を自然文で発見できるセマンティック検索を実現しています。 ブログ記事「Physical AIのためのデータ収集基盤を構築する①：模倣学習データの完全性を保証させるエッジシステム」を公開 株式会社 APTO 様が AWS 上に構築している双腕遠隔操作ロボット向け Physical AI データ基盤について、3部作の第1回としてエッジ側の「収集」レイヤーを解説しています。VLA モデルのファインチューニングに使う模倣学習データを、エッジ側で品質を確定させてから Amazon S3 に送る仕組みや、不完全データの排除、S3 Event Notifications によるイベント駆動設計など、Physical AI / ロボティクス分野のデータパイプラインを構築する際の実践的なアーキテクチャが紹介されています。 ブログ記事「AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート」を公開 2026 年 4 月 23 日に名古屋で開催された、IT 企業エグゼクティブ向けイベントのレポートです。製造業 SI を行うエスツーアイ株式会社様が Kiro の仕様駆動開発を活用して上流工程の課題を解決した事例と、i Smart Technologies 株式会社様が Amazon Bedrock を使い IoT データを現場の意思決定に活かす「AI 製造部長」を開発した事例を紹介しています。AI を「パートナー」として自社のドメイン知識と掛け合わせる発想が印象的です。 ブログ記事「Kiro アンバサダープログラムのご紹介」を公開 AWS が提供する AI 開発ツール「Kiro」のコミュニティアンバサダープログラムが発表されました。アンバサダーには無償サブスクリプションや未公開機能への早期アクセス、プロダクトチームとの直接コミュニケーションなどの特典があり、月 3〜4 時間程度の活動が期待されます。Kiro を日常的に使っている開発者にとって、製品の方向性に直接影響を与えられる機会です。応募は kiro.dev から随時受付中です。 ブログ記事「満員御礼！ Claude Code による開発体験ワークショップ【イベントレポート】」を公開 2026 年 5 月に NHN テコラス主催で開催された Claude Code のハンズオンワークショップのレポートです。Agentic Coding の基礎から、CLAUDE.md による設定、Plan Mode、MCP の活用までを座学で学んだ後、Excalidraw のコードベースへ実際に Claude Code で機能追加を体験する内容です。ワークショップコンテンツは公開されており自身の AWS アカウントで取り組めるので、Claude Code を始めてみたい方はぜひ参考にしてみてください。 サービスアップデート Kiro で Claude Opus 4.8 が利用可能に Kiro の IDE、CLI、Web で Claude Opus 4.8 が利用可能になりました。自己検証機能の強化、より効率的なツール呼び出し、長期プロジェクトでのフォロースルー改善が特徴です。Pro、Pro+、Power プランで利用でき、CLI ユーザーは v2.5.0 以上へのアップデートが必要です。 Amazon Connect が生成 AI を使用してセルフサービスインタラクションを自動評価 Amazon Connect で、AI エージェントによるセルフサービス対応の品質を生成 AI が自動評価する機能が追加されました。マネージャーが自然言語で評価基準を定義すると、生成 AI がその基準に基づいてインタラクションを評価し、詳細な理由付けとトランスクリプトからの参照ポイントを提供します。東京リージョンを含む 7 リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Connect の生成 AI 搭載コンタクト後サマリーが 8 つの新しい言語に対応 Amazon Connect で生成 AI を活用したコンタクト後の要約機能が、新たに日本語・フランス語・ドイツ語・スペイン語・ポルトガル語・イタリア語・中国語・韓国語の 8 言語に対応しました。会話の言語に合わせて自動的にサマリーが生成されるようになり、多言語サポートを提供するグローバル組織でもコンタクト内容を効率的に把握できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock が Service Quotas のサポートを拡大 Amazon Bedrock の bedrock-mantle エンドポイントに対する推論クォータ（input-tokens-per-minute / output-tokens-per-minute）が AWS Service Quotasコンソールから確認可能になりました。クォータの可視化により本番スケールの事前計画が容易になり、標準的なプロセスでクォータ増加をリクエストできます。東京リージョンを含む複数リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Claude Opus 4.8 が AWS で利用可能になりました Anthropic 社の最新モデル Claude Opus 4.8 が AWS 上で利用可能になりました。エージェント型コーディング、自律的タスク実行、複雑な知識労働において優れた性能を発揮し、長い自律実行セッションでもコンテキストを保持しながら深い推論を行えます。Amazon Bedrock および Claude Platform on AWS からアクセスできます。詳細は こちらの Amazon Bedrock ページ をご参照ください。 Amazon SageMaker HyperPod Slurm クラスターが継続的プロビジョニングでの最小キャパシティ要件の指定をサポート Amazon SageMaker HyperPod の Slurmクラスターで、継続的プロビジョニング利用時に最小キャパシティ要件（MinCount）を指定できるようになりました。固定数のノードを必要とする分散学習フレームワーク（PyTorch FSDP、Megatron-LM等）で、最小閾値が満たされるまでクラスターが待機するため、不完全な状態でのジョブ開始を防止できます。HyperPod対応の全リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 P5.48xl インスタンスが SageMaker ノートブックインスタンスで東京リージョンに拡大 NVIDIA H100 GPU 搭載の P5.48xl インスタンスが、SageMaker ノートブックインスタンスにおいて東京リージョンで利用可能になりました。前世代比で処理時間を最大 4倍短縮し、トレーニングコストを最大 40% 削減できます。LLM や拡散モデルのトレーニングなど生成 AI 開発に活用できます。詳細は こちらのドキュメント をご参照ください。 P4de インスタンスが SageMaker ノートブックインスタンスで東京リージョンに拡大 NVIDIA A100 GPU 8 基搭載（合計 640 GB GPU メモリ）の P4de インスタンスが、SageMaker ノートブックインスタンスにおいて東京リージョンで利用可能になりました。P4d 比で MLトレーニング性能が最大 60% 向上し、コストを 20% 削減できます。詳細は こちらのドキュメント をご参照ください。 P6-B200 インスタンスが SageMaker ノートブックインスタンスでバージニア北部リージョンに拡大 NVIDIA Blackwell GPU 8 基搭載（1440 GB GPU メモリ）の P6-B200 インスタンスが、SageMaker ノートブックインスタンスにおいてバージニア北部リージョンで利用可能になりました。P5en 比で最大2 倍の AI トレーニング性能を提供し、大規模基盤モデルのインタラクティブな開発やファインチューニングに最適です。 次世代 Amazon OpenSearch Serverless が一般提供開始 Amazon OpenSearch Serverless の次世代版が一般提供開始されました。エージェント構築向けに設計され、前世代比 20 倍速いオートスケーリング、スケール・トゥ・ゼロによる最大 60%のコスト削減、コンピュートとストレージの完全分離を実現しています。Kiro や Claude Code などとのネイティブ統合も提供されます。詳細は こちらのドキュメント をご参照ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 「AWS 初学者向けの勉強方法 7 ステップ ! 2026 年版 !」 のブログを公開しました。「AWS を勉強したいけど、何から手をつければいいんだろう…」という方に向けて、クラウドの概要をつかむところからお客様事例、サービスの全体像、各サービスの深掘り、ハンズオンでの実践、最新情報のキャッチアップ、そしてさらなるレベルアップまで、知識の深め方が 7 ステップで体系的にまとめられています。 これから AWS の学習を始める方や、「勉強し始めたけど次にどうしよう」という方はもちろん、社内で AWS 初学者を育成する立場の方にもぴったりの内容です。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年5月25日週の主要なアップデート 5/26(火) Amazon GuardDuty Malware Protection for AWS Backup が Amazon S3 continuous backups に対応 Amazon GuardDuty Malware Protection for AWS Backup が Amazon S3 continuous backups (継続的バックアップ) に対応しました。これにより、S3 の継続的バックアップに対してマルウェアスキャンを実行し、バックアップタイムライン全体から安全な復元時点を特定できるようになります。バックアッププラン内でフルスキャンまたは増分スキャンを有効化でき、復元可能な任意の時点までオンデマンドスキャンを実行できます。新しい GetPITRMalwareScanResults API により、継続的バックアップ内の任意の時点におけるマルウェアスキャンステータスをクエリできるため、復元前に特定の復元時点が安全であることを確認できます。 5/27(水) AWS Backup、論理的エアギャップボールトのマルチパーティ承認に OTP 検証を追加 AWS Backup は、論理的エアギャップボールトに隔離されたバックアップへ一時的に読み取り専用アクセスする際などに用いるマルチパーティ承認において、承認者が投票する際に 6 桁のワンタイムパスワードによる検証を必須としました。承認者は AWS IAM Identity Center に登録されたメールアドレスに送信される OTP を入力する必要があります。この機能は追加料金なしで、既存および新規のすべてのマルチパーティ承認セッションに自動適用され、設定作業は不要です。論理的エアギャップボールトをサポートするすべての AWS リージョンで利用できます。 Amazon Aurora MySQL が Kiro Powers との統合をサポート AWS は、Amazon Aurora MySQL-Compatible Edition が Kiro Powers との統合をサポートすることを発表しました。Kiro Powers は、Model Context Protocol (MCP) サーバー、ステアリングファイル、フックを事前パッケージ化したリポジトリで、AI エージェント支援により Aurora MySQL を使用したアプリケーション開発を加速します。この統合により、開発者は自然言語の会話形式で、データベースクエリの実行、スキーマ管理、クラスタ作成などの操作を実行できます。Kiro IDE または Kiro Web からワンクリックでインストールでき、Aurora MySQL が利用可能な全ての AWS リージョンで使用できます。 Amazon Connect Customer が生成 AI によるセルフサービスインタラクションの自動評価に対応 Amazon Connect Customer に、生成 AI を活用してセルフサービスインタラクション（タッチトーン、Lex ボット、AI エージェントとの対話）を自動評価する機能が追加されました。マネージャーは自然言語で評価基準を定義でき（例：「AI エージェントは顧客の問題をすべて解決しましたか？」）、生成 AI が会話トランスクリプトを分析して評価結果と詳細な理由付けを提供します。これにより、最大 100% のセルフサービスインタラクションを自動評価し、AI エージェントのパフォーマンス改善サイクルを加速できます。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、欧州 (フランクフルト) の 7 リージョンで利用可能です。 AWS Elemental Inference が Smart Subtitles でライブ字幕の自動生成に対応 AWS Elemental Inference に Smart Subtitles 機能が追加されました。この機能は、AI を活用した音声認識により、ライブビデオストリームからリアルタイムで字幕を自動生成します。英語 (米国、英国、オーストラリア)、フランス語、ドイツ語、イタリア語、ポルトガル語、スペイン語の6言語に対応し、TTML または WebVTT 形式で低レイテンシーの字幕を配信します。AWS Elemental MediaLive とのネイティブ統合により、手動の字幕作成ワークフローやサードパーティサービスなしでアクセシブルなコンテンツを配信できます。スポーツ中継の選手名や専門用語に対応するため、カスタム辞書の作成も可能です。 Amazon Bedrock が Service Quotas のサポートを bedrock-mantle エンドポイントに拡張 Amazon Bedrock は、bedrock-mantle エンドポイントの推論クォータを AWS Service Quotas コンソールから確認できるようになりました。これにより、OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages API をサポートする bedrock-mantle エンドポイントについて、モデルごとの入力トークン毎分 (input-tokens-per-minute) および出力トークン毎分 (output-tokens-per-minute) のクォータを、bedrock-runtime エンドポイントや他の AWS サービスと同じ方法で追跡できます。この機能は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、東京、シドニー、ジャカルタ)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、ストックホルム)、南米 (サンパウロ) の全 13 リージョンで利用可能です。 5/28(木) Amazon OpenSearch Serverless 次世代版が一般提供開始 AWS は Amazon OpenSearch Serverless の次世代版 (NextGen) の一般提供を開始しました。前世代と比較して 20 倍速いオートスケールを実現し、数秒でリソースをプロビジョニングできます。10 分間アイドル状態が続くとコンピュート容量が 0 に縮小してコンピュート課金が停止し、再びリクエストが到着すると約 10 秒で容量が復帰します。この scale-to-zero と従量課金制により、ピーク負荷用にプロビジョニングした OpenSearch クラスタと比較して最大 60% のコスト削減が可能です。コンピュートとストレージの完全な分離、2 種類の新しいエンドポイント構造、Vercel や Kiro などの AI 開発プラットフォームとのネイティブ統合により、エージェント構築のワークフローに最適化されています。 Amazon WorkSpaces Applications が Windows Desktop OS をサポート Amazon WorkSpaces Applications が、ライセンス持ち込みを通じて Windows Desktop OS (Windows 11) を使用したストリーミングリソースのセットアップをサポートしました。お客様は既存の Windows Desktop ライセンスを持ち込むことで、Microsoft 365 Apps for enterprise を含む Windows デスクトップアプリケーションを専用ハードウェア上でストリーミングできるようになります。BYOL を利用することで OS ライセンス料が免除され、コンピュートとストリーミングインフラのみの支払いとなり、コスト削減を実現します。ただし、利用にあたってはライセンス上の制約があります。仮想ホスト環境での利用が許可された Microsoft の Windows VDA または Windows Enterprise ライセンス（VDA E3/E5 など）が必要で、リージョンあたり月間最低 50 WorkSpaces の稼働コミットメントが求められます。 Claude Opus 4.8 が AWS で利用可能に Claude Opus 4.8 の提供を開始しました。Anthropic の最高性能モデルとして、agentic coding、知識作業、長時間自律タスクで大幅な性能向上を実現しています。提供方法は Amazon Bedrock と Claude Platform on AWS の 2 つで、後者は AWS Console から Anthropic のネイティブプラットフォーム体験にアクセスできる新しいサービスです。料金は入力 $5/MTok、出力 $25/MTok で、1M トークンのコンテキストウィンドウと 128K トークンの最大出力に対応します。 Amazon Connect の生成 AI 搭載コンタクト後サマリーが 8 つの新しい言語に対応 Amazon Connect の生成 AI 搭載コンタクト後サマリーが、ポルトガル語、フランス語、イタリア語、ドイツ語、スペイン語、中国語、日本語、韓国語の 8 つの言語に対応しました。これにより、グローバルなコンタクトセンター運営組織は、会話の言語に合わせて自動的にサマリーを生成できるようになり、エージェントのアフターコンタクトワーク (ACW) の効率化と、複数言語にまたがる問い合わせのレビューが可能になります。この機能は Amazon Connect が利用可能なすべての AWS リージョンで提供されます。 5/29(金) AWS Interconnect – multicloud に 500 Mbps の無料枠を提供開始 AWS は AWS Interconnect – multicloud で 500 Mbps の無料枠の提供を開始しました。この無料枠により、AWS と他のパブリッククラウド間でプライベート接続を簡単に評価・テストできるようになります。月間約 160 TB のデータ転送が可能で、マルチクラウドワークロード、データレプリケーション、ハイブリッドアプリケーションアーキテクチャを AWS 側の料金負担なしでサポートします。オープン仕様に基づき、Google Cloud と Oracle Cloud Infrastructure (Public Preview) が既に対応しており、Microsoft Azure も 2026年後半に対応予定です。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

2026 年 5 月 13 日に公開された “ Accelerating VMware migrations with AWS Transform and MGN replication agent installation automation ” を翻訳したものです。 オンプレミスの VMware 環境から AWS への数百台のサーバー移行には、チーム、アカウント、ツール間の調整が必要です。ターゲット環境のセットアップ、ウェーブの計画、レプリケーションエージェントのデプロイ、進捗の監視、テストの実行、カットオーバーの実施が必要であり、多くの場合、複数の AWS アカウントにまたがります。各ステップはそれ自体が困難であり、マイグレーションを成功させるためには全体を通じた慎重な計画と調整が求められます。 AWS Transform は、これらのステップを単一の AI アシスト付きリホスト (リフトアンドシフト) ワークフローに統合します。AWS Transform は AWS Transform for VMware のマイグレーションライフサイクル全体のオーケストレーション機能を基盤とし、プロセスの各ステップで対話型 AI ガイダンスを提供します。 AWS Transform for VMware をすでにご利用の方は、その エクスペリエンス に馴染みがあるかもしれません。ワークフローの概要を簡単に振り返ります: ディスカバリー : AWS Transform がソース環境を分析します マイグレーション計画 : マイグレーションの目標とビジネス要件を共有すると、AWS Transform がディスカバリーフェーズで収集したデータを目標に沿って処理します ランディングゾーンの作成とネットワーク構成の移行 : AWS Transform がデプロイ可能なターゲットランディングゾーンの基盤構築を支援し、ソース環境のネットワーク設定をクラウドネイティブな AWS ネットワーク構成に変換するネットワーク構成の移行を自動化します サーバーマイグレーション : AWS Transform が既存のレプリケーションエージェントを使用して、ソースサーバーの AWS への移行を行います このワークフローは完全にダイナミックでカスタマイズ可能であり、マイグレーションジョブに最適なタスクを選択できます。 レプリケーションエージェントは、組織の既存のソフトウェア配布ツールを使用してデプロイしたり、ソースサーバーに手動で接続してデプロイしたり、あるいは MGN コネクタ (AWS Application Migration Service (MGN) 独自の効率化されたレプリケーションエージェントデプロイ機能) を使用してデプロイしたりできます。 MGN コネクタは、ソース環境の Linux マシンにデプロイされ、認証情報とソースサーバーへのネットワーク接続を提供すると、前提条件の検証からインストール、インストール後のデプロイ検証チェックの実行まで、ソースサーバー (Windows または Linux) へのレプリケーションエージェントのデプロイという「重労働」を含むインストールプロセス全体を管理・処理します。 本稿では、最新の AWS Transform リホストジョブの改善が、MGN コネクタのセットアップと構成のプロセスを自動化・加速し、大規模なマルチアカウントマイグレーションを高速に実行する方法をご紹介します。セットアッププロセスは、AWS Identity and Access Management (AWS IAM) ロールの作成と AWS Systems Manager ハイブリッドアクティベーションコードの生成を自動化するガイド付きの対話型エクスペリエンスにより合理化されました。その結果、ソース環境に MGN コネクタをデプロイするためのすぐに使用できるインストールコマンドが得られます。コネクタがデプロイされると、AWS Transform はソースサーバー全体へのレプリケーションエージェントのインストールを自動的に管理し、マイグレーションプロセス全体を通じてインストールの進捗、ステータス、実行結果の一元的な可視化を提供します。 前提条件 サーバーマイグレーションフェーズにある VMware マイグレーションジョブを持つ AWS Transform ワークスペースがあること。 AWS Transform の ランディングゾーン とネットワークマイグレーション機能を活用して、マイグレーション実行前にこのターゲット環境のセットアップと構成を自動化できます。 移行されたサーバーが起動するターゲット AWS アカウントに、ネットワークインフラストラクチャ (VPC、サブネット、セキュリティグループ) が既に配置されていること。 ソース環境に MGN コネクタをホストするための、 サポートされるオペレーティングシステム の Linux マシンが利用可能であり、ソースサーバーへのネットワークアクセスと AWS への接続があること (ネットワークフローについては アーキテクチャ図 を参照)。 ソースサーバーの認証情報が AWS Secrets Manager に保存されていること。エントリ形式の例については ドキュメント を参照してください。 マルチアカウントマイグレーションの場合、複数の AWS アカウントが AWS Organizations メンバーアカウント としてセットアップされており、メンバーアカウントのいずれかが AWS MGN の AWS Organizations 委任管理者 として機能するか、AWS Organizations 管理アカウントを使用すること。 MGN コネクタは最初のウェーブで管理アカウントまたは委任管理者アカウントにセットアップされ、他のメンバーアカウントをターゲットとする後続のウェーブで再利用できます。 AWS Transform を介した MGN コネクタのセットアップとレプリケーションエージェントデプロイのウォークスルー 以下の画像は、サーバーインベントリを AWS Transform ジョブワークスペースに読み込み完了後のセットアッププロセスを示しています。「レプリケーションエージェントのデプロイ」フェーズを開始し、AWS Transform による自動インストールで MGN コネクタを使用することを選択します。 AWS Transform は、コネクタに名前を付けるよう求めます (または自動生成されたデフォルトを使用します)。この名前は、環境全体で複数のインストールを管理する際にコネクタを識別するのに役立ちます。 図 1 – AWS Transform へ MGN コネクタの使用を指示 次のフェーズでは、MGN コネクタセットアップを使用してソース環境に MGN コネクタをインストールするための AWS アカウントの準備を行います。AWS Transform は、AWS アカウントコンソールでセットアップを起動するためのリンクを提供します。以下の画像は、エージェントと連携してこれらのステップを進め、AWS コンソールでセットアップを完了する様子を示しています。 このプロセスでは、MGN コネクタに必要なリソースの作成を効率化します: IAM ロール : MGN コネクタは、エージェントデプロイタスクの実行中に引き受ける一連の IAM ロールに依存します。IAM リソースを自分で管理したい場合は、代わりにセットアップページから AWS CloudFormation テンプレートをダウンロードできます。 SSM ハイブリッドアクティベーション : 最大 30 日間有効なアクティベーションコードで、安全なコマンド実行のためにコネクタマシンを AWS Systems Manager にリンクするために使用されます。 図 2 – AWS Transform がユーザーにコンソールで MGN コネクタセットアップを完了するよう指示する 図 3 – AWS コンソールでの ATX MGN コネクタセットアップ ATX MGN コネクタセットアップページは、必要なすべての認証情報と構成を含む完全なインストールコマンドを生成します。これを、MGN コネクタ用に準備したサーバーにコピーして実行できます。 インストールが完了するまでセットアップページを開いたままにしてください。インストールコマンドにはブラウザにのみ存在する機密性の高い認証情報が含まれており、AWS Transform には保存されません。 セットアップページからインストールコマンドをコピーし、MGN コネクタを実行するために指定した Linux マシンで実行します。 コネクタのインストールには約 2〜3 分かかります。インストールにより、Linux マシン上に SSM Agent が構成され、コネクタが AWS サービスに登録されます。 図 4 – ソース環境の Linux サーバーへの MGN コネクタのインストール AWS Transform ワークスペースに戻り、MGN コネクタが正常にインストールされたことをエージェントに確認します。 図 5 – AWS Transform で MGN コネクタのデプロイ完了を確認する 以下の画像に示すように、AWS Transform はソースサーバーの認証情報を必要とします。これは AWS Secrets Manager にシークレットとして保存したものです。Transform は、Linux サーバーと Windows サーバーのシークレット ARN を提供するよう求めます。これらのシークレットは後でオンデマンドで取得され、ソースサーバーにレプリケーションエージェントをデプロイするために使用されます。 図 6 – ソースサーバーへの認証情報を含むシークレット ARN を AWS Transform に提供する オペレーティングシステムの種類ごとに、すべての Linux サーバーと Windows サーバーに対して単一の共有シークレットを構成するか、認証情報がアプリケーションやサーバー間で異なる場合には、サーバーごとに複数のシークレットを定義できます。多様な認証情報を持つ環境の場合、AWS Transform はサーバーインベントリが事前入力された CSV ファイルを生成してプロセスを簡素化し、各サーバーを対応するシークレットにマッピングしてワークフローにアップロードし直すことができます。 AWS Transform はシークレットを MGN 内のソースサーバーに関連付け、コネクタは IAM ロールを使用してレプリケーションエージェントをデプロイする際にオンデマンドでシークレットを取得します。シークレットは Secrets Manager 以外のどこにも保存されません。 MGN コネクタが構成され、シークレットがソースサーバーに関連付けられると、Transform はレプリケーションエージェントをデプロイする準備が整います。 AWS Transform は、SSM エージェントを使用してコネクタにデプロイコマンドを送信し、ソースサーバーにレプリケーションエージェントをインストールします。以下の画像に示すように、各ソースサーバーに対してコネクタは以下を実行します: Secrets Manager から認証情報を取得 サーバーに接続 (Linux は SSH 、Windows は WinRM) サーバーが前提条件を満たしているか検証 (利用可能な CPU、RAM、ディスクスペース) レプリケーションエージェントをインストール レプリケーションエージェントを構成 インストールの成功と AWS MGN サービスへの接続を検証 図 7 – AWS Transform がソースサーバーの前提条件を検証し、レプリケーションエージェントをデプロイする AWS Transform ジョブワークスペースを通じてデプロイの進捗をリアルタイムで監視し、各ソースサーバーのステータスを個別に追跡できます。サーバーが前提条件の検証に失敗した場合、コネクタは具体的な問題を報告するため、再試行前に対処できます。 次のステップ エージェントがデプロイされると、データレプリケーションが自動的に開始され、ソースサーバーは AWS MGN の ライフサイクルステート を経ていきます。 AWS MGN は、レプリケーション対象として選択された各サーバーのディスクの初期同期を実行し、その後、継続的なブロックレベルのレプリケーションを維持します。AWS Transform は、移行されたワークロードを検証するためのテストインスタンスの起動や、本番稼働の準備が整った際のカットオーバーの実行など、残りのステージを引き続きガイドします。 マルチアカウントマイグレーションの場合、最初のウェーブでセットアップしたコネクタは、組織内のメンバーアカウントをターゲットとする後続のウェーブで再利用できます。AWS Transform は AWS CloudFormation StackSets を通じてクロスアカウント IAM ロールのデプロイを処理するため、アカウントごとにコネクタのセットアップを繰り返す必要はありません。 クリーンアップ VMware マイグレーションに AWS Transform for VMware を使用した場合は、 AWS Transform ワークスペースまたはその使用中に作成されたリソースに関連するコストが発生しないよう、不要なリソースをクリーンアップしてください。具体的には: AWS Application Migration Service によって作成されたリソース (進行中のレプリケーションジョブ、マイグレーション中のテスト用に起動された EC2 インスタンス、ソース環境で MGN コネクタを実行する Linux サーバーなど) をクリーンアップしてください AWS Secrets Manager で作成されたシークレット AWS Transform ワークスペースまたはコンソールでの MGN コネクタセットアッププロセスによって作成された IAM ロール 有効な SSM ハイブリッドアクティベーション インフラストラクチャコンポーネント (VPC、サブネット、セキュリティグループ) リソースの削除によりデータも削除されるため、マイグレーションが完了したことを確認した後に、不要なリソースのみをクリーンアップしてください。 まとめ 本稿では、AWS Transform が大規模なレプリケーションエージェントデプロイのための MGN コネクタのセットアップと構成をどのように合理化するかをご紹介しました。IAM ロールの作成、SSM ハイブリッドアクティベーションを自動化し、ガイド付きのセットアップエクスペリエンスを提供することで、AWS Transform はソースサーバーへのレプリケーションエージェントのデプロイにかかる時間と労力を削減し、マイグレーションを加速します。今すぐ AWS Transform ワークスペースを作成 して VMware マイグレーションジョブを始めてみましょう。 著者について Dor Shiloni Dor は AWS シニアスペシャリストソリューションアーキテクトで、EMEA マイグレーション・モダナイゼーションチームのメンバーです。彼は顧客のニーズを理解し、クラウドを活用して革新的なソリューションを設計し、顧客にビジネス価値をもたらすことに情熱を注いでいます。 Efrat Manor Portnoy Efrat は、AWS Transform のシニアプロダクトマネージャーであり、ディスカバリー・計画からランディングゾーン、ネットワーク、サーバー移行まで、完全な移行ライフサイクルを加速する簡素化されたエージェント駆動型の新しい AWS エクスペリエンスを構築するチームの一員です。顧客、パートナー、AWS フィールドチームと密接に連携してきた彼女の専門知識と経験は、この進化を形作る上で重要な役割を果たし、移行を AWS Transform 内でより自動化された、エージェント駆動型のエクスペリエンスに変革することを支援しています。 Patrick Kremer Patrick Kremer は、インフラストラクチャの移行とモダナイゼーションに焦点を当てたシニアスペシャリストソリューションアーキテクトです。Patrick は 2022 年に AWS に入社し、20 年間の VMware の経験を活かして、お客様の AWS ソリューションへの移行を支援しています。彼は認定 AWS ソリューションアーキテクトプロフェッショナルであり、教育とブログ執筆に情熱を注いでいます。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。 &nbsp;

アマゾン ウェブ サービス ジャパンのソリューションアーキテクト、齋藤です。 NHN テコラス様が主催する 「はじめてでも大丈夫 – 今からでも遅くない、Claude Code による開発体験ワークショップ」 に、AWS のソリューションアーキテクトが登壇しました。本イベントは定員に達し満員御礼での開催となりました。ご参加いただいた皆様、ありがとうございました！ 本イベントは、「AI コーディングツールは気になっているけど、まだ触ったことがない」というエンジニアの方を対象に、Claude Code を使った Agentic Coding を実際に体験いただくオフライン形式のワークショップです。 Claude Code 入門 &amp; ハンズオン ～ Agentic Coding を一緒に体験しよう～ AWS ソリューションアーキテクト 山澤による座学セッション 座学パートでは、Agentic Coding の概要に加え、 CLAUDE.md による設定、Plan Mode を使った計画的な実装、コンテキスト管理、MCP（Model Context Protocol）といった Claude Code を使いこなすためのポイントを解説しました。 ハンズオンに取り組む参加者の様子 ハンズオンでは、 手を動かして学ぶ Claude Code 入門ワークショップ のモジュール 1 を、AWS ソリューションアーキテクトの齋藤がファシリテーターとして進行しました。オープンソースのホワイトボーディングツール Excalidraw を題材に、本物のコードベースへ Claude Code で機能追加を行う体験をしていただきました。 AWS ソリューションアーキテクト 齋藤によるハンズオンセッション 参加者は AWS 上にデプロイされた Code Editor サーバーにブラウザからアクセスするだけで、ローカル PC に何もインストールすることなく Claude Code を体験できる環境を用意しました。Claude Code は Amazon Bedrock 経由で Claude モデルを呼び出す構成です。モジュール 1 では、以下の内容を体験しました。 Claude Code の基本操作（プロンプトの書き方、ファイル操作） CLAUDE.md の作成と活用 Plan Mode を使った計画的な実装 Excalidraw への機能追加 Playwright MCP を使った視覚的な動作確認 Claude Code を AWS で始めるには ～ Amazon Bedrock 連携から組織導入まで～ NHN テコラス株式会社 AWS Ambassador 福永 悠斗 氏 2 つ目のセッションでは、NHN テコラスの福永氏より、Claude Code を AWS 環境で動かすための 2 つの選択肢を解説いただきました。 Amazon Bedrock API 連携 — セットアップ手順や必要な IAM 権限の設定方法 AWS Marketplace Enterprise Plan — 請求の一元化や管理面でのメリットなど、組織導入を見据えた選択肢 企業で Claude Code を導入する際の具体的なステップが示され、「明日から自社でも始められそう」という声が聞かれました。 参加者の声 「自然言語でコードを改修できることを体感できた」「サポートが手厚く安心して取り組めた」といった声が多く、初めて AI コーディングツールに触れる方にとって実践的な学びの場になったほか、「第二弾・第三弾も開催してほしい」というリクエストや「これから利用・提案予定」という回答も多く、本イベントが Claude Code の導入検討を後押しする機会になりました。 おわりに 本イベントでは、Claude Code on Amazon Bedrock を活用した実践的な開発体験を提供しました。AI コーディングツールの第一歩を踏み出すきっかけとなれば幸いです。 今回使用したワークショップコンテンツは公開されています。ご自身の AWS アカウントにデプロイして取り組むこともできますので、ぜひお試しください。 ワークショップ: 手を動かして学ぶ Claude Code 入門ワークショップ 解説ブログ: 手を動かして学ぶ Claude Code 入門ワークショップを公開しました〜！ AWS では今後もパートナー企業様と連携し、最新の AI 開発ツールを体験いただけるイベントを企画してまいります。 著者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。 森 瞭輔 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。好きな AWS サービスは Amazon Connect で、業界問わずコンタクトセンター関連の技術支援も行っています。先日念願だったフルマラソン完走を達成することができました。 登壇者について 山澤 良介 ソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。前職では主にネットワーク案件を担当していました。好きなサービスは、Amazon Bedrock と AWS Transit Gateway です。休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っております。 福永 悠斗 NHN テコラスにてデータ・AI 活用を中心にお客様のクラウド活用支援に従事。2025 年には、AWS がグローバルで選出する表彰プログラムである AWS Ambassador に認定。AWS 普及・啓発活動を精力的に推進している。

本記事は 2025 年 12 月 10 日 に公開された「 How to use Sustainability Insights Framework on AWS 」を翻訳したものです。 従来、組織は炭素排出量を追跡し、気候関連レポートを作成する際に、複雑で労働集約的、かつエラーが発生しやすい手動プロセスに直面してきました。このプロセスでは通常、従業員が公共料金の請求書、燃料消費記録、調達文書、出張領収書、施設運営ログなど、異なるソースから無数の時間をかけてデータを収集する必要がありました。大規模なチームは、このデータをスプレッドシートに手動で入力する必要があり、多くの場合、一貫性のない形式や単位を扱い、慎重な変換と検証が必要でした。このプロセスは、異なる地域基準、報告要件、排出係数を扱う多国籍組織にとって特に困難でした。スタッフは、スコープ 1 排出量（所有するソースからの直接排出）、スコープ 2 排出量（購入した電力からの間接排出）、さらに複雑なスコープ 3 排出量（バリューチェーン内のその他すべての間接排出）を手動で計算する必要がありました。各計算には適切な排出係数の慎重な適用が必要であり、これらの係数自体も基準の進化に伴って定期的に更新する必要がありました。 これらの懸念に対処するため、AWS は AWS Solutions Library に Sustainability Insights Framework (SIF) を導入しました。 これは、あらゆる規模の組織が AWS 上で炭素排出量を自動的に追跡し、気候関連レポートを作成するアプリケーションを構築するのに役立つ、柔軟でスケーラブルなソフトウェアプラットフォームです。計算、パイプライン処理、参照データセット用の特殊なコンポーネントを含むモジュラーアーキテクチャを通じて、SIF は組織が膨大な量のサステナビリティデータを処理しながら、すべての計算とレポート全体で精度と一貫性を維持できる高度なアプリケーションを作成することを可能にします。 フレームワークの有効性は最終的に入力データと推定方法の品質に依存し、すべての出力は規制遵守と公式開示のために独立した検証が必要ですが、SIF の自動化されたアプローチは 3 つの重要な利点を提供します：自動化されたデータ処理と計算を通じて人的エラーのリスクを劇的に削減し、増大する報告要件を処理するために動的にスケールし、進化するサステナビリティ基準と規制に容易に適応します。SIF には、それぞれ特定の目的を果たす複数のモジュールが含まれています。これらのモジュールは、アクセス管理、インパクト管理（排出係数管理）、参照データセット管理、計算、データパイプラインを処理します。 ​ SIF の主要機能 アカウント管理 – 組織の報告境界を設定します。フレームワーク内でユーザーアクセス、ロール、権限を制御します。 インパクト – GHG 排出係数などの活動インパクトのカタログを作成します。公開されたソースから排出係数を追加するか、独自のカスタム係数を作成します。 参照データセット – データパイプラインにカスタムデータセットを追加して、データ品質を向上させます。 計算 – ローコードアプローチを使用してカスタム計算を作成します。 メトリクス（KPI） – 処理された活動を自動的に集計するメトリクスを設定します。これらを組織の報告境界と期間に合わせます。 データ取り込みパイプライン – CSV ファイル、AWS Clean Rooms、または入力データコネクタフレームワークを使用した他のソースからデータをインポートします。計算を適用してデータを必要な出力に変換します。 監査可能性 – すべての計算と結果を完全な透明性で追跡および再現します。 マルチテナンシー – シングルテナントまたはマルチテナントモードで動作します。自社の排出量を計算したい組織と、SaaS オファリングを構築する組織をサポートします。必要に応じて、分離されたテナント間でデータを安全に共有します。たとえば、SaaS オファリングを構築する場合、トップティアのお客様は業界固有の数式などの事前定義された計算にアクセスできます。中央テナントは、集中管理のためにこれらの計算を保存します。トップティアテナントは、これらの計算にリモートでアクセスして使用する権限を取得します。 ソリューションアーキテクチャ SIF は、それぞれ特定の機能に焦点を当てた複数のモジュールで構成されています。以下のアーキテクチャ図は、これらのモジュールがどのように連携するかを示しています。 ​ SIFソリューションアーキテクチャモジュール ​ ユーザーは REST API を通じて SIF を操作します。 アクセス管理モジュール は、ユーザーと権限を管理し、グループごとにリソースを分離します。 インパクトモジュール は、データ処理計算中にインパクト係数などのリソースを管理するのに役立ちます。これらは計算モジュールとパイプラインモジュールから参照できます。 参照データセットモジュール は、ルックアップテーブルなどのデータセットを管理するのに役立ちます。これらのデータセットは、計算モジュールとパイプラインモジュールから参照できます。 計算モジュール は、方程式または関数を作成および管理するのに役立ちます。これらの計算は、データ処理計算のために他のモジュールで参照できます。 パイプラインモジュール は、計算用のデータ処理パイプラインを設定するのに役立ちます。 パイプラインプロセッサモジュール は、パイプラインを管理し、パイプライン集計を実行します。 計算機モジュール は、バックエンドコンポーネントとしてパイプライン内の操作を実行します。これには、算術演算とリソースルックアップが含まれます。 SIF は、AWS サービス上に構築されたモジュールのレイヤーとして機能します。各モジュールは特定の機能を処理します。各コンポーネントを見てみましょう： ​ アクセス管理モジュール アクセス管理モジュールは、ユーザーとグループを使用して SIF 内の権限を管理し、リソースを分離します。外部 REST API を通じてユーザーとグループを作成できます。他の SIF モジュールは、アクセス管理モジュールを呼び出して権限を確認します。各テナントは、独自のアクセス管理インフラストラクチャのコピーを取得します。 ​ SIF アクセス管理モジュール図 ​ インパクトモジュール インパクトモジュールは、インパクト関連のリソースを管理するのに役立ちます。排出量追跡などのデータ処理計算中に、計算モジュールとパイプラインモジュールからこれらのリソースを参照できます。インパクトの例としては、モバイルディーゼル燃料消費の二酸化炭素換算量（CO2e）があります。インパクトモジュールは、インパクトタスク API を通じて一度に多くのインパクトリソースを作成できます。すべてのインパクトには、透明性のためのバージョン追跡が含まれています。 ​ SIF インパクトモジュール図 ​ 参照データセットモジュール 参照データセットモジュールは、ルックアップテーブルなどのデータセットを管理するのに役立ちます。排出量追跡などのデータ処理計算中に、計算モジュールとパイプラインモジュールからこれらのデータセットを参照できます。参照データセットの例は、特定の場所の発電ミックス（石炭、原子力、風力）を示すテーブルです。すべての参照データセットには、透明性のためのバージョン追跡が含まれています。 ​ SIF 参照データセットモジュール ​ 計算モジュール 計算モジュールは、方程式または関数を作成および管理するのに役立ちます。排出量追跡などのデータ処理計算中に、他の計算モジュールまたはパイプラインモジュールでこれらの計算を参照できます。計算は、単純（単位変換など）または複雑（ビジネス固有の排出量計算など）にすることができます。すべての計算には、透明性のためのバージョン追跡が含まれています。 ​ SIF 計算モジュール ​ パイプラインモジュール パイプラインモジュールは、パイプライン構成を管理するのに役立ちます。これらの構成は、排出量追跡などの計算用のデータ処理パイプラインを設定します。パイプラインを構成して、実行全体で出力を結合し、メトリクスにグループ化できます。メトリクスは、時間の経過に伴う総排出量などの主要業績評価指標（KPI）を捕捉します。パイプライン構成のドライランをリクエストして、計算機を通じて処理し、作成前にエラーをチェックできます。すべてのパイプライン構成には、透明性のためのバージョン追跡が含まれています。 ​ SIF パイプラインモジュール ​ パイプラインプロセッサモジュール パイプラインプロセッサモジュールは、パイプライン操作を管理します。これには、入力ファイルを提供したときのパイプライン実行の開始と、パイプライン構成で定義された集計の実行が含まれます。パイプラインプロセッサモジュールは、パイプライン実行のステータスも表示します。 ​ パイプラインプロセッサモジュール ​ 計算機モジュール 計算機モジュールは、パイプラインで定義された操作を読み取って実行するバックエンドコンポーネントとして機能します。これには、算術演算と、参照データセットやインパクトなどのリソースのルックアップが含まれます。計算機は、入力値と実行で使用された各リソース（参照データセット、インパクト、計算）のバージョンを含む、すべてのパイプライン操作の監査ログも作成します。 ​ さまざまなモジュールの詳細については、こちらをご覧ください： Architecture diagrams for SIF on AWS ​ 米国環境保護庁（EPA）は、AWS と Sustainability Insights Framework（SIF）を使用して、サブパートW規制に基づく温室効果ガス排出量を管理および報告しています。SIFは、データ収集、分析、報告を容易にする包括的でスケーラブルかつ安全なプラットフォームを提供します。これにより、コンプライアンスが向上し、環境の持続可能性がサポートされます。このユースケースの詳細については、こちらをご覧ください： U.S. EPA Subpart W Greenhouse Gas Reporting with AWS and Sustainability Insights Framework ​ SIF 計算機モジュール ​ SIF の利点 SIF は以下の利点を提供します： 運用効率と自動化 ：データ収集から自動化された排出量計算と報告までの手動作業を削減します。 透明性と監査可能性 ：すべてのデータソース、計算式、結果がバージョン管理され、ログに記録されます。これにより、監査をサポートするトレーサビリティが作成されます。 標準化されたデータモデル ：データ統合と品質保証、さらにレポートの再利用性と高度なデータ分析を可能にします。 高い柔軟性とスケーラビリティ ：排出係数、ワークフロー、計算式を簡単に追加または変更できます。これにより、将来のニーズに柔軟に対応できます。 セキュリティと一貫性 ：データ暗号化や最小権限の原則を含む、AWS セキュリティのベストプラクティスに従います。 ガイダンスをデプロイする手順 SIF のソースコードは GitHub で見つけることができます： Guidance for AWS sustainability insights framework 。2 つのデプロイオプションがあります： CDK を使用して手動でデプロイする。 sif-cli を使用してデプロイする 。SIF コマンドラインインターフェース（sif-cli）は、コマンドラインコマンドを通じて SIF コンポーネントと対話するのに役立つオープンソースツールです。最小限のセットアップで、sif-cli は SIF の管理の多くの複雑さを簡素化します。また、デプロイされたバージョンと最新の SIF リリース間の互換性を確保する機能も含まれています。 デプロイを完了し、SIF を本番環境に移行したい場合は、 Considerations of running SIF in production を確認してください。 ​ カスタマイズガイダンス（さまざまなお客様向け） SIFは、多様なお客様要件を満たすために柔軟に適応します。 業界および地域別の排出係数のカスタマイズ ：製造や輸送などの業界、または米国や日本などの地域に応じて排出係数を管理します。 お客様固有の KPI とレポート形式の追加 ：SIF のカスタマイズ可能な計算式とレポートテンプレート機能を使用して、独自のメトリクスとカスタマイズされたレポート出力をサポートします。 既存のデータレイクとシステムとの統合 ：API と AWS サービス統合を通じて、SIFを既存のデータインフラストラクチャとシームレスに接続します。 組織構造とセキュリティ要件の最適化 ：SIF のマルチテナントアーキテクチャを使用して、複数の部門またはグループ会社間で操作を分離します。必要に応じて詳細なアクセス制御を設定します。 次のステップ SIF を始める準備はできましたか？以下をお勧めします： 初めてのユーザー向け： GitHub リポジトリを探索する – コードベースと要件を理解するために、AWS sustainability insights framework のガイダンスを確認してください。 開発環境をセットアップする – 必要な AWS CLI、CDK、および権限が構成されていることを確認してください。 パイロットデプロイから始める – 最もシンプルなセットアップエクスペリエンスのために、sif-cli ツールを使用して開発環境に SIF をデプロイします。 EPA ユースケースを確認する – 米国環境保護庁がサブパート W 報告のためにSIFをどのように実装したかを研究して、実際のアプリケーションを理解してください。 実装の準備ができている組織向け： データソースを評価する – SIF と統合する必要があるシステムとデータ形式を特定します。 排出係数を定義する – 構成する必要がある業界固有または地域固有の排出係数を決定します。 組織構造を計画する – 報告境界に基づいて、シングルテナントまたはマルチテナントアーキテクチャが必要かどうかを決定します。 本番環境の考慮事項を確認する – 本番環境にデプロイする前に、「 Considerations of running SIF in production 」のドキュメントを読んでください。 サポートを受ける： ベストプラクティスとピアサポートのために、AWS サステナビリティコミュニティに参加してください。 実装ガイダンスとカスタマイズサポートについては、AWS プロフェッショナルサービスをご検討ください。 SIF が使用する基盤となるサービスについては、AWS ドキュメントを確認してください。 パイロットプロジェクトから小規模に始めてアプローチを検証し、プラットフォームの経験を積むにつれてスケールアップしてください。 ​ 結論 AWS Sustainability Insights Framework（SIF）は、AWS上に構築された貴重なツールです。自動化された炭素排出量追跡のためのアプリケーションの設計と実装を加速する基盤となるソフトウェアコンポーネントを提供します。SIF は、自動化、カスタマイズの柔軟性、スケーラビリティ、コスト効率、セキュリティなどの利点を提供するために連携する、さまざまな独立したモジュールで構成されています。 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 Smita Srivastava Smita Srivastava は、Amazon Web Services のシニアソリューションアーキテクトで、デジタルネイティブ企業のイノベーション促進を支援しています。その経験を活かし、企業の成長を導き、AWS サービスを活用した AI/ML に重点を置きながら、アイデアを現実に変えるサポートをしています。AWS のお客様にサステナビリティソリューションを提案することに深い関心を持っています。仕事以外では、旅行好きで、読書家であり、食の探求者でもあります。

本記事は、2025 年 6 月 20 日に公開された Implement a rollback strategy for Amazon Aurora PostgreSQL upgrades using Amazon RDS Blue/Green deployments を翻訳したものです。翻訳は Cloud Support Engineer の野島 正就が担当しました。 Amazon Aurora PostgreSQL 互換エディション は、高いパフォーマンスと可用性を実現するために設計されたフルマネージドのリレーショナルデータベースエンジンで、更新時のダウンタイムの削減とリスクの最小化を支援する マネージドなブルー/グリーンデプロイ をサポートしています。ブルー/グリーンデプロイは、論理レプリケーションを使用してフルマネージドのステージング環境を作成し、本番環境の変更を安全にデプロイおよびテストできるようにします。ブルー環境は現在の本番データベースです。グリーン環境には必要な更新や変更が含まれていますが、アプリケーションエンドポイントを変更する必要はありません。このアプローチにより、エンジンバージョンのアップグレードやシステムパッチなどの更新に伴うリスクとダウンタイムを最小限に抑えることができます。検証が完了したら、アプリケーションエンドポイントの変更なしにグリーン環境をシームレスに本番環境に昇格させることができます。 非本番環境で入念に計画とテストを行ったとしても、バージョンアップグレード後に予期しない問題が発生することがあります。例えば、新しいスキーマ変更がステージング環境では完璧に動作しても、本番環境では実際のデータパターンの違いやテスト中に実行されなかったアプリケーションクエリが原因でエラーが発生する場合があります。また、実際のトラフィックやワークロードによってパフォーマンスが低下することもあります。このような場合、サービスの安定性を迅速に復旧するためにロールバック計画を用意しておくことが不可欠です。ブルー/グリーンデプロイ機能には現在組み込みのロールバック機能はありませんが、バージョン管理のための代替ソリューションを実装することができます。 この記事では、Amazon RDS ブルー/グリーンデプロイの切り替え後に、セルフマネージドな論理レプリケーションを使用してロールバッククラスターを手動でセットアップし、新しいバージョンとの同期を維持する方法を紹介します。ロールバッククラスターは、元のバージョンに戻す必要がある場合のバックアップオプションとして機能します。 ソリューションの概要 次の図は、このソリューションの高レベルなワークフローを示しています。 スイッチオーバーの前には、2 つのクラスターがあります: ブルークラスター – 既存の本番データベースクラスター グリーンクラスター – ブルークラスターからミラーリングおよび同期されたステージング環境 スイッチオーバー後、3 つのクラスターが存在します: 旧ブルークラスター – 元の本番クラスター (以前のブルークラスター) 新ブルークラスター – 本番クラスターの新バージョンで、ワークロードが実行される場所 (以前のグリーンクラスター) ブループライマリ (ロールバック) クラスター – 旧ブルークラスターのクローンで、新ブルークラスターのデータと同期されたもの (ロールバッククラスターとして使用されます) ワークフローのステップは以下のとおりです: ブルー/グリーンデプロイを作成 します ブルークラスターへのトラフィックを停止し グリーンクラスターへのスイッチオーバーを実行 します ブルー/グリーンデプロイを削除 します 旧ブルークラスターを クローン して、ブループライマリ (ロールバック) クラスターを作成します 新しいブルークラスターからブループライマリ (ロールバック) クラスターへの論理レプリケーションを設定します 新しいブルークラスターへのトラフィックを開始します この記事では、 Amazon Aurora PostgreSQL 互換エディション のメジャーバージョンアップグレード (バージョン 15.10 から 16.6 へ) をシミュレーションします。 制限事項 Aurora ブルー/グリーンデプロイは DDL、シーケンス、マテリアライズドビューのリフレッシュ、ラージオブジェクトの作成や変更、プライマリキーのないテーブルでのデータの更新や削除をレプリケートしません。詳細については、 Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項 を参照してください。 Aurora ブルー/グリーンデプロイはスイッチオーバー後にプライマリクラスターエンドポイントを自動的に管理しますが、以前のバージョンへのロールバックが必要な場合は、アプリケーションまたは DNS レベルでエンドポイントの変更を処理する必要があります。 ロールバッククラスターのセットアップには追加のダウンタイムが発生します。 前提条件 このソリューションを実装するには、以下のコンポーネントが必要です: ブルー/グリーンデプロイのサポート – 既存の Aurora クラスターのバージョンがブルー/グリーンデプロイをサポートしていることを確認します。詳細については、 データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する および New – Fully managed Blue/Green Deployment in Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL を参照してください。 ソースデータベースクラスター (この記事では Aurora PostgreSQL v15) で論理レプリケーションを有効にします。 必要に応じてブルー/グリーンデプロイをサポートするバージョンへのインプレースマイナーバージョンアップグレードを 1 回実行します。 AWS CLI による操作。 注意: 論理レプリケーションパラメータを有効にするには、ライターインスタンスの再起動が必要です。詳細については、 Aurora PostgreSQL DB クラスターの論理レプリケーションの設定 を参照してください。 新しいバージョンのデータベース用のクラスターパラメータグループ : 新しいバージョンから古いバージョンへの論理レプリケーションを設定するため、新しいバージョン (Aurora PostgreSQL 16) で論理レプリケーションが有効になっていることを確認する必要があります。以下の AWS CLI コマンドでクラスターパラメータグループを作成し、論理レプリケーションパラメータを有効にします。 aws rds create-db-cluster-parameter-group \ --db-cluster-parameter-group-name pg16-blue-green \ --db-parameter-group-family aurora-postgresql16 \ --description "Parameter group that contains logical replication settings for Aurora PG 16" aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name pg16-blue-green \ --parameters "ParameterName='rds.logical_replication',ParameterValue=1,ApplyMethod=pending-reboot" Aurora のクローン機能については Amazon Aurora DB クラスターのボリュームのクローン作成 を参照してください。 ブルー/グリーンデプロイの作成 Amazon RDS ブルー/グリーンデプロイは AWS によって管理されます。内部的には、ブルー環境からグリーン環境にリソースを作成してミラーリングし、ネイティブの論理レプリケーションを使用してブルー環境からグリーン環境に DML の変更をレプリケートします。 AWS コマンドラインインターフェイス (AWS CLI) を使用して、以下のコマンドで RDS ブルー/グリーンデプロイを作成できます。ここで source は本番データベースの Amazon Resource Name (ARN) です。以下の RDS コンソールのスクリーンショットは、論理レプリケーションが有効になっている既存のクラスター (ブルークラスター) を示しています。 以下のコマンドを使用して、Amazon Aurora PostgreSQL バージョン 16 のグリーンクラスターを持つブルー/グリーンデプロイを作成します。グリーンクラスターには、事前に作成した論理レプリケーション用の適切なパラメータグループをアタッチする必要があります。 aws rds create-blue-green-deployment \ --blue-green-deployment-name my-blue-green-deployment \ --source arn:aws:rds: {REGION} : {ACCOUNT_NUMBER} :cluster: {CLUSTER_ID} \ --target-engine-version 16.6 \ --target-db-cluster-parameter-group-name pg16-blue-green すべてのインスタンスが利用可能になると、ブルークラスターとグリーンクラスターの両方がアタッチされたブルー/グリーンデプロイが完成します。 トラフィックの停止とスイッチオーバーの実行 グリーンクラスターを昇格させるには、 スイッチオーバー アクションを開始する必要があります。スイッチオーバーを開始する前に、ブループライマリの作成中のデータ整合性を確保するために、ブルークラスターのデータベーストラフィックを停止してください。VPC セキュリティグループを使用して、インバウンドおよびアウトバウンドのデータベーストラフィックをブロックできます。スイッチオーバーが完了したら、RDS ブルー/グリーンデプロイの更新されたラベルを確認してください。 aws rds switchover-blue-green-deployment \ --blue-green-deployment-identifier {BG_RESOURCE_ID} \ --switchover-timeout "300" ブルー/グリーンデプロイの削除 ブループライマリ (ロールバック) クラスターを設定する前に、ブルー/グリーンデプロイを削除する必要があります。RDS ブルー/グリーンデプロイを削除すると、マネージド環境からクラスターが解放され、Amazon RDS ブルー/グリーンデプロイによって生成されたレプリケーションスロット、パブリケーション、サブスクリプション、論理レプリケーションコンポーネントなどのオブジェクトがクリーンアップされます。 aws rds delete-blue-green-deployment \ --blue-green-deployment-identifier {BG_RESOURCE_ID} \ --no-delete-target 次のスクリーンショットに示すように、apg-blue-green-demo (v16.6) と apg-blue-green-demo-old1 (v15.10) の 2 つの独立したクラスターが作成されました。 新しいブルークラスターをクローンしてブループライマリ (ロールバック) クラスターを作成 コンプライアンスや監査の目的で、元のブルークラスターを保持する必要がある場合があります。ロールバッククラスターをセットアップするには: 元のブルークラスターをクローンしてセルフマネージドのブループライマリ (ロールバック) クラスターを作成します 利用可能になったら、クローンしたクラスターで簡単な読み取り専用クエリを実行して、クラスターとデータへのアクセスを確認します ロールバックが必要になった場合に備えて、DNS またはアプリケーションのエンドポイント更新用にブループライマリ (ロールバック) クラスターのエンドポイントを記録します aws rds restore-db-cluster-to-point-in-time \ --db-cluster-identifier "apg15-blue-prime" \ --restore-type copy-on-write \ --use-latest-restorable-time \ --source-db-cluster-identifier "apg-blue-green-demo-old1" \ --db-subnet-group-name " {DB_SUBNET} " \ --vpc-security-group-ids " {VPC_SECUITY_GROUP} " \ --db-cluster-parameter-group-name " pg15-blue-green " aws rds create-db-instance \ --db-instance-identifier "apg15-blue-prime" \ --db-instance-class "db.r6g.large" \ --db-cluster-identifier "apg15-blue-prime" \ --engine "aurora-postgresql" \ --engine-version "15.10" 次のスクリーンショットに示すように、ロールバック先となる新しい復元クラスター「apg15-blue-prime」を作成しました。 ブループライマリ (ロールバック) クラスターのセットアップ ブループライマリのクローンが完了したら、新しいブルークラスター (パブリッシャー) からブループライマリクラスター (サブスクライバー) へのセルフマネージドな論理レプリケーションを設定します。データ同期の問題を防ぐため、書き込みアクティビティやスキーマ変更が行われないようにしてください。 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントを使用してデータベースに接続し、新しいパブリケーションを作成します: CREATE PUBLICATION publication_name FOR ALL TABLES ; 重要 : 各テーブルにレプリケーションアイデンティティ (プライマリキーやユニークキーなど) があることを確認してください。同じクラスターに複数のデータベースがある場合は、新しく昇格した本番クラスター (新しいブルークラスター) の各データベースに対して以下の手順を繰り返してください。 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントに接続し、以下のコマンドを使用して ‘pgoutput’ プラグインを使用したレプリケーションスロットを作成します: SELECT pg_create_logical_replication_slot(' replication_slot_name ', 'pgoutput'); ブループライマリクラスター (サブスクライバー) で、以下のコマンドを使用して、データのコピーや新しいスロットの作成を行わずに新しいサブスクリプションを作成します: CREATE SUBSCRIPTION subscription_name CONNECTION 'postgres:// admin_user_name : admin_user_password @ source_instance_URL / database ' PUBLICATION publication_name WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = ' replication_slot_name '); このコードには以下のパラメータが必要です: subscription_name – サブスクリプションの名前 admin_user_name – rds_superuser 権限を持つ管理ユーザーの名前 admin_user_password – 管理ユーザーに関連付けられたパスワード source_instance_URL – パブリケーションサーバーインスタンスの URL database – サブスクリプションサーバーが接続するデータベース publication_name – パブリケーションサーバーの名前 replication_slot_name – ステップ 2 で作成したレプリケーションスロットの名前 重要 : ブループライマリクラスター上のすべてのパブリケーション (ステップ 1) に対して、この作業を繰り返す必要があります。 ブループライマリクラスターで、以下のコマンドを使用してサブスクリプションを有効にします: ALTER SUBSCRIPTION subscription_name ENABLE ; 重要 : ブループライマリクラスター上のすべてのサブスクリプションに対して、この作業を繰り返す必要があります。 論理レプリケーションのセットアップが完了し、新しいブルークラスターからブループライマリクラスターへのデータフローを確認した後、既存のクラスターエンドポイントを使用して新しいブルークラスターへのトラフィックを再開できます。Amazon RDS ブルー/グリーンデプロイが DNS の変更を自動的に処理するため、アプリケーションは同じエンドポイントを引き続き使用できます。 ブループライマリクラスターへのロールバック ブループライマリクラスター (元のバージョン) にロールバックする必要がある場合は、以下の手順に従ってください。 移行中のデータ整合性を維持するためにアプリケーショントラフィックを停止します (Amazon Aurora VPC セキュリティグループを使用して受信トラフィックをブロックできます) アプリケーションまたは DNS レコードを更新して、ブループライマリクラスターのエンドポイントを指すようにします ブループライマリクラスターのサブスクリプションを削除します 該当する場合はシーケンス値を手動で更新します この切り替えは自動ではありません。ブループライマリクラスターはマネージドサービスの管理下にないためです。実行時のエラーを最小限に抑えるために、ロールバック手順のランブックまたは自動化スクリプトを作成することをお勧めします。 この戦略はロールバックオプションを提供しますが、ブループライマリクラスターのセットアップ時に追加のダウンタイムが発生します。このアプローチを実装する際に考慮すべきトレードオフであり、本番環境に移行する前にステージング環境で十分にテストすることを推奨します。 クリーンアップ 本番環境では、すべてのアプリケーションが正常に移行されたことを検証する間、新しいブループライマリクラスターを維持する必要があります。両方の環境を同時に稼働させておくことで、新しいインフラストラクチャで何か不整合や予期しない動作が発生した場合にロールバックできることが保証されます。コンプライアンス目的で旧ブルークラスターをバックアップした後、コスト削減のためにクラスターを削除できます。すべてのクラスターは削除されるまで課金されます。 テスト目的でこれらのリソースを作成した場合は、追加料金が発生しないように、すべてのクラスター (ブルー、グリーン、ブループライマリ) を削除する必要があります。データベースクラスターをクリーンアップするには、以下の手順を実行してください。 リードレプリカインスタンスがあれば、 それぞれを削除します。 プライマリインスタンスを削除します。 データベースクラスターを削除します。 まとめ この記事では、Amazon RDS ブルー/グリーンデプロイを使用してデータベースバージョンのアップグレードを行う際のロールバック戦略の作成方法を紹介しました。安全性を高めるために、ロールバック戦略として論理レプリケーションを設定しました。ブルー/グリーンデプロイは、ミラーリングされた同期済みのデータベースステージングバージョンの作成、ガードレールチェックの実行、スイッチオーバーの実施、DNS 変更の自動化など、多くの複雑なタスクを自動的に処理します。しかし、本番データベースの変更には、アプリケーションの非互換性などのリスクが伴う可能性があります。ロールバッククラスターを設定しておくことで、アップグレード後に問題が発生した場合に迅速にフォールバックできる追加の安全策が得られます。問題が解決されるまで、以前の本番バージョンに戻すことができます。 本番ワークロードを切り替える前に、本番レベルの負荷をかけた状態で新しいデータベースバージョンに対してアプリケーションを十分にテストしてください。アプリケーションが完全に互換性があり、パフォーマンスが安定していることを確認してください。これにより、ブルー/グリーンデプロイの切り替え後にアプリケーションの問題やパフォーマンス低下が発生する可能性を大幅に減らすことができます。このロールバック戦略を実装する前に、 RDS ブルー/グリーンデプロイ の仕組みと機能について確認することから始めることをお勧めします。 Chirag Dave Chirag は マネージドな PostgreSQL を専門とする Amazon Web Services のプリンシパルソリューションアーキテクトです。セキュリティ、コスト、パフォーマンス、信頼性、効率的なオペレーション、アーキテクチャについてのベストプラクティスを通じてお客様と技術的な関係を構築しています。 Kovan Chandra Kovan は PostgreSQL データベースを専門とする Amazon Web Services (AWS) のテクニカルアカウントマネージャーです。エンタープライズサポートのお客様と協業し、クラウドにおけるカスタマージャーニー、セキュリティ、レジリエンシー、コスト削減、およびオペレーショナルエクセレンスの改善に取り組んでいます。 Daxeshkumar Patel Daxeshkumar は Amazon Web Services (AWS) のソリューションアーキテクトであり、主要なクラウド案件においてお客様やパートナーと密接に連携しています。概念実証（PoC）プロジェクトの設計・提供、実装支援、および AWS サービスを活用したアプリケーションの構築・移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。 Kamal Singh Kamal は Amazon Web Services (AWS) のシニアデリバリーコンサルタントです。データベースの移行およびモダナイゼーションプログラムに重点を置き、お客様やパートナーの AWS クラウドへの移行を支援しています。 Jinesh Shah Jinesh は Amazon Web Services (AWS) のデリバリーコンサルタントです。レガシーデータベースおよびアプリケーションのモダンな AWS プラットフォームへの移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。

みなさん、こんにちは。ソリューションアーキテクトの田村です。 サイバー攻撃の脅威は質的に変化しています。AI の進展により高度な技術を持たない攻撃者でも大規模な攻撃を実行できるようになり、攻撃の参入障壁が大きく下がっています。サプライチェーン攻撃も急拡大しており、正規の開発プロセスそのものが攻撃経路として悪用されるケースが増えています。（参考：「 サプライチェーン攻撃への防御策: Chalk/Debug 侵害と Shai-Hulud ワームの対応事例から 」「 最近の npm サプライチェーン攻撃への対応から AWS Security が学んだこと 」） こうした状況を受け、AWS Japan パブリックセクター技術統括本部では2026年4月よりセキュリティワークショップを月次で開催してきました。4月・5月は特に「ランサムウェア対策」をテーマとしました。ランサムウェアは侵入後に長期間潜伏し、業務データだけでなくバックアップ自体も暗号化する高度な攻撃が増加しており、多くの組織にとって喫緊の課題であるためです。第1回は脅威検知、第2回は統合セキュリティ管理にフォーカスしました。 さらに直近では、Claude Mythos に代表されるフロンティア AI モデルの登場を背景に、これを悪用したサイバー攻撃への対策が急速にクローズアップされています。金融庁は2026年5月22日に「 フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応 」を発出し金融機関に対応を要請、厚生労働省も同日に医療機関を含む重要インフラへの AI を活用したサイバー攻撃について 対策強化の議論を開始 しています。こうした状況を踏まえ、6月12日（金）開催予定の第3回では急遽「Claude Mythos の登場で変化する脅威への対応」をテーマとし、生成 AI 時代の脅威動向を座学で解説するとともに、ハンズオンではアプリケーションの脆弱性管理を体験いただきます。 本記事では第1回・第2回の開催レポートと、今後の取り組みについてご紹介します。 ワークショップの概要 本ワークショップは「ランサムウェア対策」を共通テーマとし、第1回と第2回で異なる AWS セキュリティサービスにフォーカスした内容となっています。講師はシニア セキュリティ ソリューションアーキテクトの中島 章博が務め、前半の座学で近年の脅威動向やセキュリティ対策の考え方を解説し、後半はハンズオン形式で実際に AWS のセキュリティサービスを体験していただきました。 ランサムウェア対策を考える上では、NIST Cybersecurity Framework（CSF）の識別・防御・検知・対応・復旧という各段階に沿って対策を整理することが有効です。 AWS にはこれらの各段階で活用できるセキュリティサービスがあります。 本ワークショップでは「検知」を担う Amazon GuardDuty と、「識別」「検知」を担う AWS Security Hub にフォーカスしました。 以下、各回の内容をご紹介します。 第1回: Amazon GuardDuty で実現する脅威検知（2026年4月10日） Amazon GuardDuty とは Amazon GuardDuty は、AI と ML に AWS と主要なサードパーティーが提供する統合脅威インテリジェンスを組み合わせて使用し、AWS アカウント、ワークロード、およびデータを脅威から保護します。ランサムウェア、バックドア、暗号通貨マイナー、トロイの木馬などのマルウェアを検出することもできます。 ハンズオン概要 参加者一人ひとりにワークショップ専用の AWS サンドボックス環境が払い出されます。この環境にはあらかじめ悪意のあるアクティビティを模したシナリオが構築されており、GuardDuty が実際に検出結果（Findings）を生成した状態になっています。参加者はセキュリティ担当者の立場で、攻撃（Attack）→ 検知（Detect）→ 調査・対応（Respond）の一連の流れを体験します。 ハンズオンは「基礎・設定」「脅威対応シナリオ」の2パートで構成されています。 前半の基礎・設定パートでは、GuardDuty の有効化と検出結果の読み方、自社固有の脅威 IP リストを GuardDuty に登録するカスタム脅威リストの構築、Amazon Simple Storage Service (Amazon S3) にアップロードされたマルウェアを自動検知する Malware Protection for Amazon S3、Amazon Elastic Compute Cloud (Amazon EC2) などのランタイムアクティビティを監視する Runtime Monitoring の設定、Amazon EventBridge と Amazon Simple Notification Service (Amazon SNS) を組み合わせた脅威通知の仕組みづくりを行います。 後半の脅威対応シナリオでは、ランサムウェア攻撃を模した「攻撃シーケンス検出結果への対応」がメインシナリオです。このシナリオでは、攻撃者が AWS Identity and Access Management (IAM) 認証情報を窃取し、Amazon S3 バケットのポリシーを変更してデータを流出させた後、証拠隠滅のためにログを無効化しバケットを削除する、という多段階の攻撃が再現されています。GuardDuty はこれらの個々のシグナルを相関分析し、「攻撃シーケンス」として一つの重大な検出結果にまとめます。参加者は MITRE ATT&amp;CK の戦術マッピングを手がかりに攻撃の全体像を把握し、AWS CloudTrail で攻撃者の行動を時系列で追跡した上で、IAM 認証情報の無効化や Amazon S3 バケットポリシーの修正といった封じ込めを実践します。 このほか、侵害された Amazon S3 バケットへの対応、IAM 認証情報が流出した場合の対応、Amazon EC2 上で Runtime Monitoring が検出した不正プロセスへの対応、Amazon Elastic Block Store (Amazon EBS) ボリュームのマルウェアスキャンと対応など、実際のインシデントで遭遇する代表的なシナリオに取り組みます。 「GuardDuty をオンにしてはいるが、検出結果が出たときに何を見ればいいのかわからない」「インシデント発生時にどこから調査を始めればよいかわからない」という方にとって、実践的なインシデント対応を安全な環境で体験できる内容です。ワークショップ教材は「 Amazon GuardDuty &amp; Amazon Detective ワークショップ 」として公開しています。 第2回: AWS Security Hub で実現する統合セキュリティ管理（2026年5月15日） AWS Security Hub とは AWS Security Hub は、お客様の重大なセキュリティ問題に優先順位を付け、規模に応じた対応を支援して環境を保護します。クラウド環境全体の可視性を一元化することで、セキュリティ運用を統合します。シグナルを相互に関連付け、実用的なインサイトへと充実させることで重大な問題を検出し、効率的な対応を可能にします。ランサムウェア対策の「予防」の観点から、自環境の弱点を事前に把握し改善しておく上で重要な役割を果たします。 ハンズオン概要 第2回のハンズオンでは、Security Hub が複数のセキュリティサービスの検出結果を相関分析して検出する「露出（Exposure）」の概念を中心に、セキュリティポスチャの改善サイクルを体験しました。 ハンズオンの前半では、Security Hub の概要と露出の仕組みを学びます。露出とは、設定ミス（Misconfiguration）、ネットワーク到達可能性（Reachability）、ソフトウェア脆弱性（Vulnerability）、機密データの存在（Sensitive Data）といった複数の特性を Security Hub が自動的に相関分析し、「このリソースは攻撃者に悪用される可能性が高い」と判断した検出結果です。参加者は実際に露出の検出結果を確認し、潜在的な攻撃パスを視覚的に把握した上で、以下のような修復作業を実践しました。 ネットワークアクセスの制限 : セキュリティグループで不要なポート（Telnet など）を閉じ、SSH アクセスを Amazon Virtual Private Cloud (Amazon VPC) 内に限定する ソフトウェア脆弱性へのパッチ適用 : Amazon Inspector が検出した既知の CVE に対し、AWS Systems Manager Session Manager 経由でパッチを適用する IAM 権限の最小化 : 過度に広範な権限を持つインスタンスプロファイルを特定し、IAM Access Analyzer を活用した最小権限への道筋を確認する 構成の改善 : IMDSv2 の強制適用により、SSRF 攻撃による認証情報窃取のリスクを排除する 後半では、Security Hub の自動化ルール（検出結果に対するアクションの自動実行）、Automated Security Response ソリューションによる修復の自動化、Security Hub と Slack を連携した通知の仕組みなど、運用に直結する内容に取り組みました。 「Security Hub を有効にしたものの、大量の検出結果をどう優先順位付けすればよいかわからない」という方にとって、露出を起点に最もリスクの高い問題から対処していくアプローチを実感いただける内容です。ワークショップ教材は「 Security Hub ワークショップ 」として公開しています。 参加者からのフィードバック 両回とも多くの方にご参加いただき、ご好評をいただきました。 「実際に手を動かすことで理解が深まった」「自組織での活用イメージが湧いた」「普段から利用しているサービスだが、何を見ればいいのか理解できるようになった」など、日々の運用に直結する学びを得られたというフィードバックをいただきました。 まとめと今後の取り組み 本ワークショップシリーズは、皆様のご要望に応じて今後も継続的に開催予定です。次回（2026年6月12日）は「Claude Mythos 時代の脅威と対応」をテーマに、フロンティア AI の普及により変化しつつある脅威動向を座学で扱い、ハンズオンではアプリケーションセキュリティワークショップとして Amazon Inspector を用いた脆弱性管理を体験いただきます。さらに 7月2日（木）には第4回として、お客様自身がフロンティア AI を使って攻撃者より先に脆弱性を検出して対策ができる&nbsp; AWS Security Agent をテーマに開催予定です。ご関心ある方は担当営業にご連絡ください。 ワークショップで学んだ内容を次のアクションにつなげるために、AWS では以下のようなセキュリティ支援を提供しています。 AWS セキュリティ成熟度モデル : 組織のセキュリティ対策の現在地を把握し、次に取り組むべき施策を明確にするフレームワークです。脅威検知やポスチャ管理が自組織ではどの段階にあるのか、確認してみてはいかがでしょうか。 Security Health Improvement Program (SHIP) : データ主導でセキュリティ改善を進めるための無償プログラムです。 脅威モデリングワークショップ : 設計段階からセキュリティを組み込みたい方に向けて、サンプルシステムを対象としたワークショップ形式のほか、実際のワークロードを対象とした個別支援も実施しています。 上記の支援にご興味がある方は、担当の AWS アカウントチームまでお気軽にお声がけください。 著者 田村 健祐 (Kensuke Tamura) — AWS Japan, Public Sector, Solutions Architect 梅田 昌太 (Shota Umeda) — AWS Japan, Public Sector, Sr Solutions Architect