本稿は、2026 年 06 月 04 日に公開された “ Gain visibility into DDoS attacks with flow logs in AWS Shield Advanced ” を翻訳したものです。 これまで、分散型サービス妨害 (DDoS) 攻撃のトラフィックを再構成するには、事後に複数のデータソースを組み合わせる必要がありました。 AWS Shield Advanced の攻撃フローログは、これを変革します。攻撃中にトラフィックのメタデータをキャプチャするため、送信元の特定、緩和策の検証、既存の分析パイプラインへのデータ投入が可能になります。 Shield は、他の AWS フローログと同じ CloudWatch Logs の配信インフラストラクチャを使用して、 Amazon Simple Storage Service (Amazon S3) 、 Amazon CloudWatch Logs 、または Amazon Data Firehose にログを発行します。そのため、すでに使用しているモニタリングおよび分析ツールに直接組み込めます。 この記事では、 Shield Advanced 攻撃フローログ が DDoS イベント中にどのようにメタデータをキャプチャするか、フローログエントリの各フィールドが何を意味するか、そして保護対象リソースに対してフローログを有効化および設定する方法を説明します。 DDoS 攻撃がアプリケーションに与える影響 DDoS 攻撃は、アプリケーションをトラフィックであふれさせ、ユーザーが利用できない状態にします。インフラストラクチャ層の攻撃は帯域幅を飽和させ、接続テーブルを枯渇させるため、パケットロスやタイムアウトが発生します。 Shield Advanced は、 Amazon CloudFront ディストリビューション、 Elastic Load Balancing のロードバランサー、 Amazon Route 53 のホストゾーン、 AWS Global Accelerator の標準アクセラレーター、および Elastic IP (EIP) アドレスに対して、攻撃を検出して緩和するマネージド型の DDoS 保護サービスです。対応範囲の詳細については、 AWS Shield Advanced のドキュメント を参照してください。 Shield Advanced では、まず EIP 保護を対象としたインフラストラクチャレイヤーの攻撃フローログが提供され、その後、対応するリソースタイプが順次拡大される予定です。 主な利点 フローログは、攻撃を以下のようなさまざまな観点から理解するのに役立ちます。 トラフィックパターンの再構築 – 攻撃発生後にログをクエリすることで、トラフィック量、送信元の分布、プロトコルの構成比を分析でき、CloudWatch の集約メトリクスだけに頼る必要がなくなります。 攻撃元の特定 – srccountry および location フィールドは、トラフィックがどこから発生し、どの AWS エッジロケーションに入ってきたかを示します。 緩和動作の検証 – action フィールドは、Shield が各フローに対して行った処理を記録します。 ログは Amazon S3、CloudWatch Logs、または Data Firehose に送られます。その後、新しいインフラストラクチャをデプロイすることなく、 Amazon Athena (Amazon S3 内のデータを分析するためのサーバーレスのクエリサービス) でクエリしたり、サードパーティのセキュリティ情報イベント管理 (SIEM) プラットフォームにルーティングしたり、 CloudWatch Logs Insights (対話型のログ分析機能) のクエリを構築したりできます。 攻撃フローログがキャプチャする内容 ログレコードは、送信元と送信先の IP アドレスおよびポート、プロトコル、パケット数とバイト数、Shield Advanced が実行したアクション、TCP フラグをキャプチャします。また、トラフィックが入ってきた AWS イングレスロケーションと、可能な場合はトラフィック送信元の 2 文字の国コードも含まれます。ログは 5 分間隔で書き込まれ、攻撃の進行中および終了後に利用できます。 ファイルの最大サイズは 75 MB です。5 分間のウィンドウ内にファイルがその上限に達した場合、そのファイルはクローズされて転送され、新しいファイルが開始されます。フローログは JSON、プレーンテキスト、W3C、Parquet の出力形式に対応しており、以下のフィールドを含みます。 フィールド 説明 protection_arn Shield 保護の Amazon リソースネーム (ARN) event_timestamp ログ生成のタイムスタンプ version フローログのバージョン番号 srcaddr 送信元 IP アドレス dstaddr 送信先 IP アドレス srcport 送信元ポート dstport 送信先ポート protocol プロトコル番号 packets 集約ウィンドウ内のパケット数 bytes 集約ウィンドウ内のバイト数 starttime 集約ウィンドウの開始時刻 endtime 集約ウィンドウの終了時刻 action Shield が実行したアクション location AWS イングレスロケーション sampling_rate パケット処理中に使用されたサンプリングレート tcp_flags パケットの TCP フラグ srccountry トラフィック送信元の 2 文字の国コード Shield Advanced 保護対象リソースに対するフローログの設定方法 以下の手順では、Shield Advanced 保護を任意のログ送信先に接続する CloudWatch Logs 配信リソースの作成方法を説明します。 前提条件 フローログを設定する前に、以下を準備してください。 有効な Shield Advanced サブスクリプション 少なくとも 1 つの既存の Shield Advanced 保護 CloudWatch Logs 配信リソースを作成するための AWS Identity and Access Management (IAM) 権限 ( logs:PutDeliverySource 、 logs:PutDeliveryDestination 、 logs:CreateDelivery ) フローログには標準の CloudWatch Logs のベンドログ料金が発生し、送信先リソース (S3 バケットのストレージ、CloudWatch Logs のロググループのストレージ、または Firehose のデータ処理) には別途料金が発生します。トラフィックの多いリソースでフローログを有効化する前に、 CloudWatch の料金ページ のベンドログの項目と、選択した送信先サービスの料金を確認してください。 仕組み ログ配信には 3 つのオブジェクトが必要です。 DeliverySource – ログを生成する Shield Advanced 保護を表します DeliveryDestination – ログの送信先 (Amazon S3、CloudWatch Logs、または Amazon Data Firehose) を表します Delivery – ソースと送信先を接続します この 3 オブジェクトモデルにより、複数のソース間で送信先を再利用したり、配信パイプラインを個別に管理したりできます。たとえば、同じ DeliveryDestination を参照する複数の DeliverySource オブジェクトを作成することで、複数の Shield 保護からのログを同じ S3 バケットに送信できます。 Shield Advanced 攻撃フローログは CloudWatch Logs 配信インフラストラクチャを使用するため、他のベンドログと同様に、アカウントやリージョンをまたいで集約できます。 クロスアカウントポリシーを使用して一元管理された S3 バケット へ直接配信したり、 クロスアカウント・クロスリージョンの集約ルール を使用して CloudWatch Logs のロググループをレプリケートしたり、 クロスアカウントサブスクリプション を使用して共有 Firehose ストリームにストリーミングしたりできます。これらのオプションを活用して、マルチアカウント・マルチリージョン環境全体にわたる DDoS 攻撃トラフィックの統合ビューを構築することができます。 ステップ 1: 送信先リソースを作成する 送信先を選択します。 オプション A – S3 バケット : 長期保存と Athena クエリに最適です。 S3 バケットの作成 を参照してください。 オプション B – CloudWatch Logs ロググループ : リアルタイムモニタリングと CloudWatch Logs Insights に最適です。 CloudWatch Logs でのロググループの作成 を参照してください。 オプション C – Data Firehose 配信ストリーム : サードパーティツールや SIEM へのストリーミングに最適です。 Firehose ストリームの作成 を参照してください。 ステップ 2: 送信先リソースポリシーを設定する (必要な場合) 送信先リソースには、CloudWatch Logs 配信サービスに書き込み権限を付与するポリシーが必要です。ポリシーは送信先のタイプによって異なります。詳細については、 Amazon S3 に送信されるログ 、 CloudWatch Logs に送信されるログ 、または Firehose に送信されるログ を参照してください。 Amazon S3 を送信先とする場合は、2 つのオプションがあります。 自動ポリシー作成: バケットに既存のリソースポリシーがなく、 s3:GetBucketPolicy および s3:PutBucketPolicy 権限を持っている場合、ステップ 6 で配信を作成する際に AWS が必要なポリシーを自動的に作成します。ステップ 3 に進んでかまいません。 手動ポリシー更新: ポリシーをカスタマイズする必要がある場合や、組織で事前承認済みのポリシーが必要な場合は、 Amazon S3 に送信されるログ の手順に従って手動でポリシーを作成してください。 ステップ 3: 保護 ARN を取得する Shield Advanced はグローバルサービスであり、管理には us-east-1 リージョンを使用します。次のコマンドを実行して、 Shield Advanced 保護の一覧を表示 します。 aws shield list-protections \ --region us-east-1 出力から、ログを記録したい保護の ProtectionArn の値をコピーします。 ステップ 4: 配信ソースを作成する 次のコマンドを実行して配信ソースを作成します。 <protection-arn> をステップ 3 の ProtectionArn の値に置き換えてください。 aws logs put-delivery-source \ --name my-shield-delivery-source \ --resource-arn <protection-arn> \ --log-type FLOW_LOGS \ --region us-east-1 --resource-arn には、保護対象のリソースそのものの ARN ではなく、Shield Advanced の保護オブジェクトの ARN を指定します。Shield Advanced は、リソースをラップする個別の保護オブジェクトを作成し、フローログはその保護レイヤーから生成されます (基盤となるリソースからではありません)。 ステップ 5: 配信先を作成する 次のコマンドを実行して配信先を作成します。 <resource-arn> をステップ 1 で作成した送信先リソースの ARN に置き換えてください。 aws logs put-delivery-destination \ --name my-shield-delivery-destination \ --output-format plain \ --delivery-destination-configuration '{"destinationResourceArn":"<resource-arn>"}' \ --region us-east-1 --delivery-destination-configuration パラメーターは、 destinationResourceArn キーを持つ JSON オブジェクトを指定します。 その値には、S3 バケット、ロググループ、または Firehose ストリームの ARN を設定します。 出力結果から、トップレベル (レスポンス直下) の ARN フィールドの値をコピーしてください。これは配信先 ARN (バケット ARN とは異なります) です。この値はステップ 6 で使用します。 ステップ 6: 配信を作成する 次のコマンドを実行して、配信ソースと配信先を接続します。 <delivery-destination-arn> をステップ 5 の配信先 ARN に置き換えてください。 aws logs create-delivery \ --delivery-source-name my-shield-delivery-source \ --delivery-destination-arn <delivery-destination-arn> \ --region us-east-1 ステップ 7: 配信を検証する 次のコマンドを実行して、配信が有効であることを確認します。 aws logs describe-deliveries \ --region us-east-1 配信が有効になると、Shield Advanced は DDoS イベント中にフローログレコードを送信先に転送します。 クリーンアップ 継続的な料金が発生しないように、作成したリソースを削除します。 配信を削除します。 aws logs delete-delivery \ --id <delivery-id> \ --region us-east-1 配信ソースを削除します。 aws logs delete-delivery-source \ --name my-shield-delivery-source \ --region us-east-1 配信先を削除します。 aws logs delete-delivery-destination \ --name my-shield-delivery-destination \ --region us-east-1 (任意) コンプライアンスや分析のためにログを保持する必要がある場合は、フローログのデータをバックアップします。 送信先リソースを削除します。 警告: 送信先リソースを削除すると、すべてのフローログデータが完全に削除されます。 S3 バケットの場合: aws s3 rb s3://<bucket-name> \ --force \ --region <region> CloudWatch Logs のロググループの場合: aws logs delete-log-group \ --log-group-name <log-group-name> \ --region <region> Firehose ストリームの場合: aws firehose delete-delivery-stream \ --delivery-stream-name <stream-name> \ --region <region> まとめ Shield Advanced の攻撃フローログは、DDoS 攻撃を効果的に理解し対応するために必要な可視性を提供します。既存のオブザーバビリティ基盤と統合できるため、新しいツールの導入や複雑なセットアップを必要とせず、すぐに活用できるインサイトを得ることができます。今すぐ Shield Advanced の保護でフローログを有効にして、攻撃パターンへの即時の可視性を確保し、DDoS 防御態勢を強化しましょう。 次のステップ Amazon S3 内のログをクエリするための Athena テーブルの構築 Amazon CloudWatch Logs でのログデータの対話的な検索と分析 攻撃パターンに対する CloudWatch アラームの作成 フローログ設定に関する完全なリファレンスについては、 AWS Shield Advanced のドキュメント を参照してください。 Ken Kitts Ken は、Amazon Web Services (AWS) のテクニカルアカウントマネージャーであり、フィンテック分野におけるソフトウェア定義ネットワーキング (SDN) を含む、20 年以上のコンピューターネットワーキングの経験を持っています。仕事以外では、遺跡や博物館を巡ることが好きな旅行愛好家で、メキシコのテオティワカンがお気に入りの場所です。 翻訳は Solutions Architect の 長谷川 純也 が担当しました。

AWS WAF に AI トラフィック収益化機能が含まれるようになりました。これにより、デジタルコンテンツの所有者とパブリッシャーは、保護されたウェブコンテンツに AI ボットやエージェントがネットワークエッジで直接アクセスした場合に課金できます。この機能により、コンテンツ所有者とパブリッシャーは、オリジンインフラストラクチャを変更したり、アプリケーションコードを作成したりすることなく、コンテンツパス、ボットカテゴリ、または検証階層ごとにリクエストごとの料金を設定できます。コンテンツ所有者は、エージェントタイプごとにきめ細かなアクセスポリシーを定義したり、ステーブルコインで好みのウォレットに支払いを回収したり、収益やボットアクティビティを単一のダッシュボードから監視したりできます。 現在、多くのコンテンツプロバイダーにおいて AI ボットのトラフィックがウェブトラフィックの 50% 以上を占めており、AI 固有のクローラーは前年比で 300% 以上増加しています。コンテンツをインデックスし、測定可能な参照トラフィックをパブリッシャーのウェブサイトに返す従来の検索エンジンのクローラーとは異なり、AI ボットは同じコンテンツを消費して AI インターフェイスで要約と回答を生成するため、元のソースにトラフィックをほとんどまたはまったく送り返しません。パブリッシャーは、そのトラフィックを処理するためのインフラストラクチャ費用を負担しますが、通常はこれらの費用を相殺するページビュー、広告インプレッション、またはサブスクリプションコンバージョンは発生しません。 AWS WAF Bot Control では、既にボットのアクティビティを可視化し、トラフィックをブロックまたはレート制限する機能をお客様に提供していますが、料金設定や AI エージェントからの支払いの回収は、これまで不可能でした。AI トラフィック収益化は、そのギャップを埋める新しい Bot Control 機能です。コンテンツ所有者とパブリッシャーは、カスタムの支払いインフラストラクチャを構築したり個別のライセンス契約を交渉したりすることなく、AWS WAF コンソールから直接料金ルールを設定し、サードパーティーの支払い統合を通じて AI エージェントから支払いを回収できます。支払い決済および検証フローは、Coinbase の x402 Facilitator によって提供されます。アカウントへの直接支払いと Machine Payments Protocol (MPP) サポートのための Stripe との統合が間もなく開始されます。 AI トラフィック収益化の開始方法 収益化を設定する前に、CloudFront ディストリビューションに関連付けられているウェブ ACL で AWS WAF Bot Control が共通レベルまたはターゲットレベルで有効になっていることを確認します。Bot Control は、収益化ルールが依存するエージェント分類を提供します。まだ設定していない場合は、「 ウェブ ACL への AWS WAF Bot Control マネージドルールグループの追加 」ドキュメントを参照してください。AWS マネジメントコンソールで [WAF & Shield] に移動し、左側のナビゲーションペインで [保護パック (ウェブ ACL)] を選択して開始します。 保護パックは、AI トラフィック収益化の中核となる構成単位です。収益化の対象となるコンテンツパス、各エージェント検証階層に課金される内容、受け入れる支払い方法、適用されるライセンス条件を定義します。作成するには、 [保護パック (ウェブ ACL) を作成] を選択します。 [アプリについて教えてください] で、コンテンツを説明するアプリカテゴリを 1 つ以上選択し ([コンテンツと公開システム]、[E コマースとトランザクションプラットフォーム]、[エンタープライズとビジネスアプリケーション] など)、 [アプリフォーカス] を選択します。AWS WAF はこれらの選択を使用して、お客様の設定に適したセキュリティ保護を推奨します。 [保護するリソースを選択] で [リソースを追加] を選択し、CloudFront ディストリビューションなどのリージョンリソースまたはグローバルリソースをこの保護パックに関連付けます。このステップはスキップして、後でリソースを追加することができます。 [初期保護を選択] で、アプリのカテゴリとリソースの選択に基づいて、AWS WAF マネージドルールパッケージから選択します。パッケージの代わりに個別のルールを選択することもできます。 [名前と説明] に、保護パックの名前と任意の説明を入力します。 オプションで、 [カスタマイズ保護パック (ウェブ ACL)] を展開し、料金階層、支払い方法、コンテンツ範囲、ライセンス条件などの追加設定を行います。 終了したら、 [保護パック (ウェブ ACL) を作成] を選択します。 保護パックが導入されたら、料金戦略を立てる前に、AI トラフィック分析ダッシュボードを確認して、AI ボットトラフィックがコンテンツに与える影響を理解してください。WAF & Shield コンソールで、左側のナビゲーションペインの [AI トラフィック分析] に移動します。ドロップダウンから保護パック (ウェブ ACL) を選択し、ダッシュボードに入力します。 AI トラフィック分析ダッシュボードは、ボットトラフィック概要パネルに表示されるトラフィックを、 すべてのボットリクエスト 、 AI ボットリクエスト 、 検証済み AI ボットトラフィック 、 未検証 AI ボットトラフィック の 4 つのカテゴリに分類します。ダッシュボードには、消費された帯域幅、推定月間コスト、ピークリクエスト率などのインフラストラクチャへの影響メトリクスが表示されます。パスごとのヒートマップには、AI ボットのアクティビティが最も多いコンテンツパスが時間単位で示され、情報に基づいた料金決定を行うために必要なデータを取得できます。 AWS WAF Bot Control は、GptBot、Claude-Web、Perplexity-Bot を含む 650 種類以上の AI ボットとエージェントを分類し、それぞれに検証階層を割り当てます。 検証済み – ウェブボット認証 (WBA) Ed25519 暗号署名によって身元が確認されたか、ユーザーエージェントとドメイン名の既知のセットを使用して文書化されたIP範囲から取得されたエージェント。 未検証 – ユーザーエージェントマッチング、行動フィンガープリンティング、IP レピュテーションによって認識されるが、身元は暗号で確認されていないエージェント。 トラフィックパターンを確認したら、 [保護パック (ウェブ ACL)] に戻り、リストから保護パックを選択し、右側のパネルで [AI 収益化を設定] を選択して料金設定とアクセスポリシーを設定します。各保護パックは、定義された一連のコンテンツパスに適用される料金、エージェントポリシー、利用可能な支払い方法、ライセンス条件を定義します。複数の保護パックを作成し、同じディストリビューション内のさまざまなコンテンツゾーンに異なる価格を適用できます。作成したら、ウェブ ACL を開いて [保護パックを追加] を選択して、保護パックをウェブ ACL に関連付けます。 パック内のエージェント検証レベルごとに、 [収益化] (402 を料金付きで返す)、 [許可 (無料アクセスを許可)] 、 [ブロック (アクセスを完全に拒否)] 、 [カウント (課金せずにログ記録)] 、 [CAPTCHA (パズルを提示して人間の送信者であることを検証)] 、 [チャレンジ (クライアントがボットではなくブラウザであることを確認)] の 6 つのアクションのいずれかを割り当てることができます。 [収益化設定を編集] ページで、次の内容を設定します。 [支払い決済] で、ステーブルコイン決済用のブロックチェーンネットワークを 1 つ以上選択します。自社で管理されているか、コインベースなどのウォレットプロバイダーがホストしているかにかかわらず、サポートされているネットワーク上のすべてのウォレットアドレスを使用できます。ネットワークごとに、ウォレットアドレスを入力し、USDC で 1 ページあたりの基本料金 を設定します。 [ネットワークを追加] を使用して複数のネットワークを追加できます。AWS はコンテンツ収益に対する支払い処理や手数料の徴収は行いません。支払いは自己管理されるか、ウォレットプロバイダーによって管理されます。 収益化 ルールが受信リクエストと一致すると、AWS WAF は HTTP 402 支払いが必要な応答を返します。レスポンス本体には、マシン間決済用の x402 オープンプロトコルを使用した JSON 形式の機械可読価格マニフェストが含まれます。マニフェストには、USDC でのコンテンツ料金、Base や Solana などの受け入れ可能なブロックチェーンネットワーク、宛先ウォレットアドレス、最大支払いタイムアウト、支払いスキームが含まれます。 x402 互換のエージェントランタイムであれば、このフローを自律的に完了できます。クライアントは、選択した支払いネットワークで署名済みの支払い承認を送信します。AWS WAF はそれを検証し、コンテンツを取得し、サードパーティーのファシリテーターサービスと統合してオンチェーンでの支払いを行い、応答を提供します。 収益化 アクションは、Amazon CloudFront ディストリビューションに関連付けられたウェブ ACL でのみサポートされていることに注意してください。リージョナルウェブ ACL への 収益化 ルールの追加はサポートされていません。 通貨モード の切り替えは収益化設定ページから直接利用できるため、 リアル モードと テスト モードはいつでも切り替えることができます。本番環境に移行する前に、非プロダクショントラフィックでテストモードを使用し、料金設定、ウォレット設定、x402 決済フローを検証してください。なお、テストモードでは引き続き x402 の支払いが適用されますが、これらの支払いは、faucet.circle.com などの蛇口から取得したテスト資金を使用して、Base Sepolia や Solana Devnet などのテストネットで行うことができます。テストモードを有効にするには、保護パック設定で [通貨モード] を [テスト] に切り替えます。AWS WAF は実際の価格マニフェストを返し、設定されたテストチェーンで本番環境と同じように支払いフロー全体を実行します。すべてのイベントは CurrencyMode: TEST を使用してログ記録されます。設定に問題がなければ、通貨モードをリアルに戻して実際の支払いの処理を開始します。 [通貨モード] を [リアル] に切り替えたら、左側のナビゲーションペインで [AI アクセス収益化] に移動して、収益化の結果をリアルタイムで追跡します。 AI アクセス収益化 ダッシュボードには、実際の通貨モードからのアクティビティのみが反映され、テストトランザクションは表示されないことに注意してください。 収益ダッシュボードには、 総収益 、 検証済みボット と 未検証ボット 別の収益、 リクエストあたりの平均が表示されます。 上位収益源 パネルでは収益をボットカテゴリ別にグループ化し、AI アクセスパターンパネルでは発生した収益に基づいてコンテンツパスをランク付けします。 決済 タブを使用して、プロバイダーごとに支払いを調整し、支払い方法の配分と失敗した支払い試行を確認します。 今すぐご利用いただけます AI トラフィックの収益化は、Amazon CloudFront のお客様において、標準の AWS WAF 料金を超える追加料金なしでご利用いただけるようになりました。この機能は、AWS WAF ウェブ ACL が Amazon CloudFront ディストリビューションに関連付けられているすべてのエッジロケーションで利用できます。 AI トラフィックの収益化の詳細については、「 AWS WAF デベロッパーガイド 」を参照してください。 – Esra 原文は こちら です。

2026 年 6 月 15 日週、ニューヨーク市では AWS Summit が開催されます。これは、Javits Center での 1 日間のイベントであり、発表、デモ、テクニカルセッションを目的として、ビルダー、お客様、AWS チームが一堂に会します。私は Summit でのいくつかのリリースについてブログ記事を書いたので、今週それらが Go Live になるのを楽しみにしています。ただ、私は Javits Center には行くことができません。4 日間の音楽フェスティバルに参加し、テントをどのように設営しようか考えながら、スマートフォンでリリース内容をチェックする予定です。私のように現地参加できない方々のために、6 月 17 日に基調講演の ライブ配信 が行われます。VP of Agentic AI である Dr.Swami Sivasubramanian と、VP of Security Services and Observability である Chet Kapoor 氏が、デベロッパーツール、AI インフラストラクチャ、セキュリティにおける新機能について解説します。 2026 年 6 月 15 日週の主なトピックは以下のとおりです。 主なトピック フロンティアチームが AI ネイティブ開発をいかに革新しているか – Swami は今週、数百の Amazon エンジニアリングチームでの実験から得られたデータに基づく詳細な記事を公開しました。自社チームでの AI 導入の仕組みを検討しているなら、この記事の内容をじっくりお読みいただく価値があります。 6 人のエンジニアで構成されるチームは、Amazon Bedrock 推論エンジンをわずか 76 日間で再構築しました。このプロジェクトは、当初 30 人のデベロッパーが 12～18 か月間かけて取り組む予定だったものです。Amazon Stores チームとの体系的なパイロットでは、正規化されたデプロイ速度で、生産性向上の中央値が 4.5 倍となり、中には 10 倍を超えるチームもありました。Perfect Order Experience では、2 週間の機能サイクルが、午後だけで完了するようになりました。WW Grocery では、設計ドキュメントの作成期間が 5 日間から数時間に短縮されました。 この記事では、これらの結果を、フロンティアチームになるための 5 つの実践にまとめています。第 1 に、エージェントコンテキストに投資しましょう。本番コードを記述する前に、ステアリングファイル、コーディング標準、構造化されたリポジトリを構築しましょう。第 2 に、ワークフローの再構築中には初期の処理速度低下が想定されますが、それを乗り越えましょう。第 3 に、エージェントが逐次監視なしで並列実行できるように、適切にスコープ設定されたタスクのバックログを安定的に維持しましょう。第 4 に、コード生成を開始する前に、構造化された仕様を通じて意図を明確にしましょう。第 5 に、コードがパイプラインに到達する前にエージェントが自己修正できるよう、テストをシフトレフトしましょう。 記事の最後には、コミット速度は全体像の一部に過ぎず、リリース管理、運用、セキュリティ運用、および EOL アップグレードについて後続の記事で解説する予定である旨が記載されています。 AWS FinOps Agent がプレビューで利用可能に – AWS FinOps Agent は、FinOps の実践者とエンジニアリングチーム向けの新しいエージェントです。このエージェントは、コストに関する質問への回答、最適化の機会の提示、コスト異常の調査、および定義されたスケジュールに基づく定期的な FinOps ワークフローの実行を行います。AWS コストの照会、財務チームとエンジニアリングチーム向けのコストレポートの生成、AWS Cost Optimization Hub と AWS Compute Optimizer からの適切なサイジング、アイドル状態のリソース、および Savings Plans に関するレコメンデーションの提示に使用できます。エージェントは、これらのレコメンデーションに基づいて、お客様のために Jira チケットをオープンできます。コスト異常が検出されると、FinOps Agent は根本原因を自動的に調査し、検出結果を Slack チャンネルに投稿します。 2026 年 6 月 8 日週のリリース まずは 6 月 15 日週に私が書いた記事から始めて、その後に私が注目した他のリリースについてご紹介します: Amazon EC2 M9g および M9gd インスタンスの一般提供を開始 – AWS Graviton5 プロセッサを搭載し、第 6 世代 AWS Nitro System 上に構築された M9g インスタンスは、Graviton4 ベースのインスタンスと比較して、最大 25% 優れたコンピューティングパフォーマンスを提供します。ウェブアプリケーションでは最大 35%、機械学習推論では最大 35%、データベースでは最大 30% 高速なパフォーマンスを実現します。Graviton5 は、AWS フリートで初めて PCIe Gen6 と DDR5-8800 メモリをサポートするプロセッサであり、前世代と比較して 5 倍大きい L3 キャッシュを含みます。M9g および M9gd インスタンスは、M8g と比較して、サイズを問わず平均で最大 15% 広いネットワーク帯域幅と 20% 広い Amazon EBS 帯域幅を提供します。また、今回のリリースでは、Nitro System の機能強化である Nitro Isolation Engine も導入されました。これは、形式検証を用いて仮想マシン間の数学的に証明された分離を提供するものであり、Nitro を初の形式検証済みのクラウドハイパーバイザーとして位置づけるものです。M9gd インスタンスは、M8gd と比較して最大 11.4 TB の NVMe SSD ローカルストレージと 30% 高い IOPS を追加します。両インスタンスタイプとも、EBS と VPC ネットワーキング間の帯域幅の割り当てを最大 25% 調整できるよう、Instance Bandwidth Configuration (IBC) をサポートしています。 Amazon Bedrock での Anthropic Claude Fable 5 – Claude Fable 5 は 6 月 9 日に Amazon Bedrock でリリースされました。これは、拡張された非同期タスク実行、図表、チャート、PDF 全体にわたる高度な視覚的機能、およびプロアクティブな自己検証を提供します。アクセスするには、モデルを呼び出す前に Data Retention API を介してデータ共有をオプトインする必要があります。Anthropic は、Mythos クラスのモデルで入出力の 30 日間の保持を要求しています。 可用性に関する重要なお知らせ: 6 月 12 日、Anthropic から AWS に対して、米国政府の輸出管理指令を遵守するため、すべてのユーザーについて、Claude Fable 5 および Claude Mythos 5 へのアクセスを取り消すよう要請がありました。Opus 4.8 を含む他のすべてのモデルは影響を受けません。詳細については、 Anthropic の声明 をお読みください。AWS は、今後新たな情報が入り次第、共有します。 Amazon Bedrock で Gemma 4 モデルが利用可能に – Google DeepMind の Gemma 4 ファミリーが、Amazon Bedrock において 3 つのバリアント、すなわち、Gemma 4 31B (Dense、256K トークンのコンテキストウィンドウ、推論およびコーディングワークロードに適しています)、Gemma 4 26B-A4B (Mixture of Experts、コストとレイテンシーが重要な要素となるワークロードを対象としています)、Gemma 4 E2B (最小バリアント、低レイテンシーのインタラクティブなユースケース向けに設計されています) で利用可能になりました。これらの 3 つはすべて、ネイティブ関数呼び出し、構造化された出力、推論、レスポンスストリーミング、テキスト、画像、動画、音声にわたるマルチモーダル入力、35 を超える言語をサポートしています。 Amazon OpenSearch Service がエージェンティックオブザーバビリティのための MCP アプリケーションをリリース – Amazon OpenSearch Service が MCP アプリケーションをサポートするようになりました。これにより、Claude Desktop や VS Code などの互換性のあるエージェンティック IDE 内でオブザーバビリティワークフローを実現できます。ローカル環境の AI エージェントは、OpenSearch ドメイン、コレクション、および Amazon Managed Service for Prometheus に保存されているログ、トレース、メトリクス、アラートを使用してインシデントを調査できます。MCP アプリケーションツールの呼び出しごとに、エージェントが推論するためのテキスト要約と、同じ会話スレッドにレンダリングされるインタラクティブなビジュアライゼーションという 2 つの応答が返されます。使用可能な MCP アプリケーションツールは、ログ、メトリクス、トレースの調査、サービスパフォーマンス、トポロジ、動的ビジュアライゼーション、エージェントの状態、クラスターの状態、およびインストルメンテーションスコアリングをカバーしています。 その他の AWS ニュース お客様に役立つ可能性のある他の記事や最新情報をいくつか次に示します: AWS CLI v1 がメンテナンスモードに移行 – CLI v1 がメンテナンスモードに移行すると、botocore と s3transfer の依存関係は、個別のパッケージとしてインストールされるのではなく、CLI v1 のコードベースに直接組み込まれるようになります。これは、CLI v1 をアップグレードしても、スタンドアロンの botocore または s3transfer パッケージは更新されなくなり、これらのパッケージを個別にインストールしても、CLI v1 によって使用されるバージョンには影響しないことを意味します。CLI v1 と boto3 の両方がインストールされている環境には、これらのライブラリの個別のコピーが含まれます。CLI v1 の新しいリリースは、重大なバグ修正とセキュリティ問題に限定されます。推奨パスは、AWS CLI v2 に移行することです。 AWS Workload Credentials Provider が利用可能に – AWS は、ワークロードが長期アクセスキーを必要とせずに短期的な AWS 認証情報を取得できるようにする、新しい Workload Credentials Provider をリリースしました。これは、AWS 外で実行されているアプリケーションの認証情報の管理をサポートします。これにより、チームは、サードパーティーまたはオンプレミス環境のワークロードのために、最小特権アクセスパターンに従うことができます。 Kiro Pro Max が利用可能に – Kiro は、より高い使用制限、最新のフロンティアモデルへのアクセス、および開発チーム向けの追加のエージェンティック機能を追加した新しい Pro Max 階層を導入しました。Kiro Pro Max は、コーディング、仕様の生成、エージェントドリブンのタスク全体で持続的かつ大量の使用を必要とするプロデベロッパー向けに設計されています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Summits – AWS Summits は、クラウドと AI をカバーする無料の実地イベントです。今後の開催予定: ニューヨーク市 (6 月 17 日)、 香港 (6 月 17 日)、 上海 (6 月 23 日～24 日)、 日本 (6 月 25 日)、 ワシントン D.C. (6 月 30 日～7 月 1 日)、 台北 (7 月 15 日)、 ボゴタ (7 月 30 日)。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 モントリオール (カナダ) (6 月 20 日)、 インディアナポリス (米国) (6 月 24 日)、 杭州 (中国) (6 月 28 日)、 ベンガルール (インド) (7 月 11 日)、 ヤウンデ (カメルーン) (7 月 25 日) が含まれます。 AWS Builder Center にアクセスして、他のビルダーと交流したり、ソリューションを提供したり、構築を継続するのに役立つリソースを見つけたりしましょう。また、今後開催される AWS 主導の実地およびオンラインイベント や、 デベロッパー向けセッション もご覧いただけます。 – Esra この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

AI Agent が企業のワークフローに組み込まれ始めている中で、「エージェントにどこまでの権限を持たせるべきか」「ユーザーの操作として実行されるべきなのか、エージェント自身の権限で実行されるべきなのか」といった設計判断に悩まれている方は多いのではないでしょうか。従来のアプリケーションとは異なり、エージェントは自律的にツールを呼び出し外部リソースへアクセスするため、認証・認可の設計にも新しい考え方が必要になります。 こうした課題に取り組む開発者・セキュリティエンジニアの皆様を対象に、2026 年 5 月 22 日、AWS 麻布台ヒルズオフィスにて「Security for App Builders #2」を開催しました。ご参加いただきました皆様には、改めて御礼申し上げます。 本ブログでは、当日の各セッションの概要をお伝えするとともに、発表資料を公開いたします。AI Agent のアイデンティティ制御に関心をお持ちの方にとって、設計の出発点となる情報が得られる内容になっていますので、ぜひご覧ください。 Security for App Builders とは 「Security for App Builders」は、アプリケーション開発者・セキュリティエンジニアを対象としたセキュリティイベントシリーズです。アプリケーション開発や SDLC におけるセキュリティの原理原則とプラクティスを、セッションとハンズオンを通じて学んでいただくことを目的としています。 昨年 11 月に実施した第一回 では「Coding Agent が生成したコードの安全性をどう確保するか」を扱いました。第二回となる今回は、エージェント自体の開発をテーマとして取り上げ、自律的にアクションを起こす段階で必要になる 認証・認可・監査可能性 に焦点を当てています。 イベント概要 エージェント型 AI は、従来のソフトウェアと生成 AI の特徴を併せ持ちます。ユーザーの指示に基づいて自律的にツールを呼び出し外部リソースへアクセスする一方で、その挙動は非決定論的です。この自律性を維持しつつ、決定論的なセキュリティ制御を与えるためにはアイデンティティ（認証・認可）の設計が重要になります。 本イベントでは、AWS セッション・お客様事例・ハンズオンを通して、AI Agent における基本となる考え方、実際のお客様での実践例を学び、AWS のマネージドサービスでの実現方法を体験いただきました。セッション終了後にはネットワーキングの時間も設け、各社のプロダクトセキュリティに関心を持つ方同士での情報交換が行われました。ご参加いただきました皆様には、改めて御礼申し上げます。 以下、各セッションの概要と当日の様子を紹介いたします。 セッションの紹介 AWS Session : AI Agent のアイデンティティ制御 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 デジタルサービス技術本部 シニアソリューションアーキテクト 柴田 龍平 最初のセッションでは、AI Agent のセキュリティの考え方とその基礎となるアイデンティティについてベースとなる考え方についてお話しました。 エージェントティック AI は自律的にツールを呼び出し、人間の数十〜数百倍の速度でアクションを実行します。これにより生産性が大きく向上する反面、エージェントが予想外の動作をしないような制御も必要になります。ただし、LLM の内部にはセキュリティを強制するメカニズムが存在しないため、プロンプトでルールを与え、行動を制限するような実際には効果は限定的です。そこで、エージェントの外部に決定論的なコントロールを導入するというアプローチがセキュリティの出発点となります。その外部コントロールの中核となるアイデンティティについて「誰として認証されるのか」「何を許可し何を禁止するか」「その操作を後から追跡できるか」── この 3 つをAWS 上で設計するために Amazon Bedrock AgentCore Identity / Policyや AWS Verified Permissions がどのように活用いただけるかを解説を行いました。 セッション資料 Customer Session : Cedar × AI Agent の認可基盤 – ポリシー設計とアーキテクチャ 株式会社エクサウィザーズ アーキテクト 小島 和也 氏 続いてのセッションでは、エクサウィザーズの小島氏より、Cedar を用いた AI Agent の認可基盤についてお話しいただきました。 「飲み会の幹事をエージェントに任せたら、役員の非公開スケジュールまで読めてしまうとよくないですよね？」という問いかけから始まり、場合によっては上書きされうるプロンプトでは行動が縛れない以上、「認可（Authorization）」の仕組みで縛るというアプローチを説明いただきました。その具体的な実現として、①鍵を縛る（エージェントが持つクレデンシャルをユーザー本人のものに制御する）②呼び出し方を縛る（ツール 1 本ずつに認可をかける）③相手そのものを縛る（エージェントの起動自体を制御する）── という三層の認可モデルを Cedar で実装し、さらに業務管理者が GUI で Business Policy を 1 件作成するだけで裏側の Cedar Policy が自動生成される Translation Layer により、ポリシーの爆発を防ぎつつ非エンジニアでも運用できる基盤を実現されています。 また、Cedar をプロダクトに組み込むにあたり、ローカル開発では Cedar エンジンを直接使い、本番では環境変数を切り替えるだけで Amazon Verified Permissions（AVP）に移行できる設計の工夫など実践的な知見も共有いただきました。 セッション資料 Workshop : AI エージェントの認証・認可・ログ設計ハンズオン アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ソリューションアーキテクト 松井 僚太郎 Workshopで構築するアーキテクチャ 最後のワークショップでは、松井が講師を務め、参加者の皆様に以下の一連の流れを実際に手を動かしながら体験いただきました： AgentCore Identity を使ったエージェントへのアクセス制御 ツール利用時の認可フロー実装 監査ログの設計と出力 概念として理解していても、実際に実装してみると考慮すべきポイントが多いのがエージェントセキュリティの特徴です。本ワークショップでは、手を動かしながらそれらのポイントを体感いただくことを重視して設計しました。 Workshop まとめ AI Agent の活用が広がる中で、「何にアクセスできるか」「誰として操作するか」「その操作を後から追跡できるか」というアイデンティティの設計は、エージェントを本番環境に投入するうえで避けて通れないテーマです。本イベントでは、この課題に対する原理原則の理解から、AWS サービスを使った実装、そしてお客様のプロダクション事例まで、一連の流れを体験いただきました。AI Agent を活用しながらよりセキュアで信頼性の高いアプリケーションを構築するためのヒントを得ていただけていれば幸いです。 AWS では Amazon Bedrock AgentCore を通じて、エージェントのアイデンティティ制御をよりシンプルに実現するための仕組みを提供しています。各セッション資料もぜひ併せてご参考ください。 今後もこのようなイベントを継続的に企画・開催してまいります。ご興味をお持ちの方がいらっしゃいましたら、お近くの AWS 営業担当もしくは技術担当にお気軽にお声がけください。 アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 柴田 龍平 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 松井 僚太郎

本記事は 2026 年 6 月 3 日に AWS Migration & Modernization Blog で公開された Consistent Code Modernization at Scale with AWS Transform custom Knowledge Items を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 はじめに AWS Transform custom (ATX) は、コードモダナイゼーションを大規模に自動化します。各リポジトリで AI コーディングアシスタントを個別に実行する場合と異なるのは、ATX が 学習する ということです。各実行からパターン、修正、エッジケースを再利用可能なナレッジとして蓄積するため、変換は実行するたびに高速化し、信頼性も向上します。 Java 8 のリポジトリを数百個抱えていたり、非推奨 API を使った Spring Boot 2.x アプリ、あるいは AWS Graviton で動かせるにもかかわらず x86 に縛られたワークロードがある場合、こうした技術的負債こそがチームの開発速度を妨げている原因です。手動でのアップグレードはスケールしません。数百のリポジトリにまたがる Java のアップグレードは単調な繰り返し作業であり、この規模の繰り返しは一貫性の欠如を招きます。 AWS Transform custom は Agentic AI を活用してこれらの変換を自動化します。一般的なシナリオに対応する AWS マネージドな変換 が同梱されているほか、独自の カスタム変換定義 を構築することも可能です。改善の蓄積は ナレッジアイテム によって実現されます。ナレッジアイテムとは、各実行からパターン、修正、エッジケースを蓄積する再利用可能なアーティファクトであり、将来の実行で自動的に適用されます。 本記事では、サンプルの Spring Boot プロジェクトを Java 8 から 26 にアップグレードし、ナレッジアイテムがどのように生成・管理されるかを確認し、同じ変換をリポジトリのポートフォリオ全体に適用する方法をご紹介します。 開始方法 実際のプロジェクトで Java 8 から 26 へのアップグレードを実行し、Transform custom の動作を確認しましょう。 前提条件 AWS Transform custom へのアクセス が有効化された AWS アカウント ATX CLI の インストールおよび設定 Java 8 以上、Java 26、Maven のインストール（サンプルプロジェクトのビルド用） Git のインストール Java と Maven の基本的な知識 シナリオ 本記事では aws-appconfig-java-sample を使用します。これは Java 8 と Maven で構築された Spring Boot アプリケーションで、非推奨の Java API や古いフレームワークバージョンに依存している、典型的なモダナイゼーション候補です。 セットアップ リポジトリをクローンします: git clone --depth 1 https://github.com/aws-samples/aws-appconfig-java-sample.git ディレクトリに移動します: cd aws-appconfig-java-sample ローカル依存関係をインストールします: mvn install:install-file \ -Dfile=./movie-service-utils/built-library/0_1_0/movie-service-utils-0.1.0.jar \ -DgroupId=com.amazonaws.samples \ -DartifactId=movie-service-utils \ -Dversion=0.1.0 \ -Dpackaging=jar ビルドが通ることを確認します: mvn clean compile -DskipTests 変換定義 変換定義 (Transformation Definition) は、Transform custom に 何を どのように変換するかを指示する再利用可能なレシピです。ソースとターゲットのスタック、変換パターン、コーディング規約、そしてエージェントに従わせたい組織ナレッジが含まれます。AWS は Java のバージョンアップグレードなど一般的なアップグレード向けに マネージド変換定義 を提供しています。組織固有のニーズに合わせて 独自の変換定義を構築する ことも可能です。 変換定義の実行 インタラクティブモードと自律モードの 2 つから選択できます。インタラクティブモードでは、ツール使用の確認、計画のレビュー、ステップの承認が求められます。自律モード ( -x ) は確認なしですべてを実行するモードで、CI パイプラインや一括実行で使用します。 ここでは -x で自律モード、 -t ですべてのツールを信頼する設定で実行します。 -t は注意して使用してください。すべてのコンテキストでエージェントが任意のツールをトリガーすることを許容したくない場合もあります。 CLI コマンドリファレンス にオプションの一覧があります。 AWS/java-version-upgrade は、Java プロジェクトを Java 26 にアップグレードするマネージド変換定義です: atx custom def exec -n "AWS/java-version-upgrade" -p . -c "mvn clean compile -DskipTests" -x -t -g "additionalPlanContext=The target Java version to upgrade to is Java 26" 上記コマンドの出力を以下の画像に示します。 AWS/java-version-upgrade 変換定義は Java 26 をターゲットとし、アップグレードの全範囲を処理します。 javax.security.cert の移行、Spring Boot のメジャーバージョンアップグレード、テスト依存関係のモダナイゼーション、ビルドツールの更新など、POM ファイル内の Java バージョン番号を変更するだけではありません。 エージェントは依存関係グラフ全体を分析し、すべての変更を一括で適用し、コンパイルとテストの両方を検証した後、すべてを単一のアトミックなコミットとして記録しました。14 件の個別の変更（依存関係のアップグレード、API の移行、ビルドツールの更新）がすべて一緒に検証されました。実行ログには、実行内容、遭遇した問題（Spring Boot 3.2.12 の ASM が Java 26 と非互換、Mockito の ByteBuddy の問題）、およびそれらの解決方法が記録されています。 14 件の変更、1 つのアトミックコミット、完全なビルドとテストの検証。しかしエージェントはコードの変更を生成しただけではありません。何がうまくいき、何がうまくいかなかったかも観察しました。この観察こそがナレッジアイテムの源であり、別のリポジトリに対する次の実行が今回よりも高速になる理由です。 結果の確認 変更は専用のローカル Git ブランチに反映されます。Transform custom はリモートにプッシュしません。標準的な Git ツールで確認できる完全な監査証跡が得られます。コミットメッセージにはすべての変更が詳細に記載され、実行ログには遭遇した問題と解決方法が記録されます。インタラクティブモード（ -x なし）で実行した場合は、実行開始前に計画をレビュー・修正でき、検証ステップや外部ツールチェックなど必要なゲートを追加できます。 変換によるすべての変更を確認するには: git diff main diff --git a/pom.xml b/pom.xml --- a/pom.xml +++ b/pom.xml @@ -5,7 +5,7 @@ <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.0.5.RELEASE</version> + <version>3.5.14</version> </parent> diff --git a/src/main/java/.../movies/MoviesController.java b/src/main/java/.../movies/MoviesController.java --- a/src/main/java/.../movies/MoviesController.java +++ b/src/main/java/.../movies/MoviesController.java @@ -1,5 +1,5 @@ -import javax.validation.Valid; +import jakarta.validation.Valid; diff --git a/src/main/java/.../utils/Security.java b/src/main/java/.../utils/Security.java --- a/src/main/java/.../utils/Security.java +++ b/src/main/java/.../utils/Security.java @@ -1,5 +1,5 @@ -import javax.security.cert.*; +import java.security.cert.*; 代表的な 3 つの変更を示します。Spring Boot が 2.0.5.RELEASE から 3.5.14 に（エージェントは 3.2.12 の ASM が Java 26 のクラスフォーマットをサポートしないことを検出し、3.5.14 にアップグレードしました）、 javax.validation.Valid が jakarta.validation.Valid に移行、 javax.security.cert が java.security.cert に置き換えられました。完全な diff には Mockito と JUnit の依存関係更新、Gradle ビルドのモダナイゼーション、AWS SDK BOM のアップグレードも含まれます。 変更内容に問題がなければ、マージします: git checkout main git merge <transformation-branch-name> 変換の改善 最初の実行は動作します。面白くなるのは 2 回目からです。 リファレンスとナレッジアイテム Transform custom が変換精度を向上させる手段は 2 つあります。 リファレンス は、変換定義の作成時にアップロードする移行ガイド、API 仕様、コードサンプルなど、事前に提供するドキュメントです。即座に有効化され、完全にお客様の管理下にあります。 ナレッジアイテム は、実際の変換中に何が起こったかを観察することで、システムが自ら学習したものです。Transform custom は各実行後に非同期でナレッジアイテムを生成し、無効状態で開始し、お客様がレビューして承認した場合にのみ適用されます。 リファレンスが出発点を設定し、真に価値が積み上がるのはナレッジアイテムによってです。本記事の残りでは、このナレッジアイテムに焦点を当てます。 ナレッジアイテムの管理 どのナレッジアイテムを有効にするかは、お客様が制御します。承認なしに有効化されることはありません。 これまでに蓄積されたものを一覧表示するには: atx custom def list-ki -n "AWS/java-version-upgrade" 以下のナレッジアイテムは、先ほどの変換実行で生成されたものです。エージェントはプロジェクトのアップグレード中にこれらの問題に遭遇し、自動的に記録しました: KI - 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 - DISABLED Title: Mockito 5.14.2 ByteBuddy incompatible with Java 26 Description: Mockito 5.14.2 fails to mock standard library classes like ArrayList under Java 26. Error message indicates ByteBuddy cannot modify ArrayList and related collection classes. Mockito 5.15.2 resolves the compatibility issue. Fix: Upgrade Mockito to 5.15.2: <!-- Before - ByteBuddy in Mockito 5.14.2 can't handle Java 26 --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.14.2</version> <scope>test</scope> </dependency> <!-- After - Mockito 5.15.2 supports Java 26 bytecode --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.15.2</version> <scope>test</scope> </dependency> KI - adb1b8e6-4199-4d4d-964c-1eab5c94de1a - DISABLED Title: Spring Boot 3.2.12 ASM lacks Java 26 class format support Description: Spring Boot 3.2.12 uses ASM library version that cannot parse Java 26 class files (major version 70). Test execution fails with "Incompatible class format" during classpath scanning. Spring Boot 3.5.14 or newer required for Java 26 compatibility. Fix: Upgrade Spring Boot to 3.5.14: <!-- Before - ASM in Spring Boot 3.2.12 can't parse Java 26 classes --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.12</version> </parent> <!-- After - Spring Boot 3.5.14 includes ASM with Java 26 support --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.5.14</version> </parent> どちらもデフォルトでは DISABLED です。有効化する前にレビューを行います。各説明には、何が変更されたか、なぜ重要か、症状、そして正確な修正方法が記録されています。これらは、Java 26 アップグレード中にエージェントが遭遇した 2 つの異なるカテゴリの問題です: Mockito/ByteBuddy: バイトコード操作の失敗。Mockito にバンドルされた ByteBuddy が Java 26 のクラスフォーマットを処理できず、テスト時のモックが実行時に失敗する。 Spring Boot ASM: クラスフォーマット解析の失敗。Spring Boot の ASM ライブラリがクラスパススキャン中に Java 26 のバイトコードをスキャンできず、テスト実行が完全に破綻する。 どちらもコンパイルだけでは検出できません。アップグレード後のコードに対してテストを実行する必要があり、そのためビルド検証コマンドが重要になります。 ナレッジアイテムを有効化するには: atx custom def update-ki-status -n "AWS/java-version-upgrade" --id 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 --status ENABLED atx custom def update-ki-status -n "AWS/java-version-upgrade" --id adb1b8e6-4199-4d4d-964c-1eab5c94de1a --status ENABLED すべてのナレッジアイテムを Markdown にエクスポートしてオフラインでレビューすることもできます: atx custom def export-ki-markdown -n "AWS/java-version-upgrade" Markdown へのエクスポートは、チームがオフラインでナレッジアイテムをレビューしたり、スプリント計画や技術的負債レビューのセッションでどれを有効化するかを議論したりする場合に便利です。自分のコードベースに対して適用範囲が広すぎるナレッジアイテムがあれば、無効化してください。次回別のリポジトリで実行した際に、より限定的な修正パターンが生成されることがあります。そちらを有効化すれば、徐々に汎用的なアドバイスではなく、組織の実コードに即したナレッジアイテムを取捨選択していけます。 なお、これらのナレッジアイテムはお客様の組織に固有のものであり、他のお客様とは共有されません。 学習ループ Transform custom の価値はイテレーションにあります。実行し、エージェントが学習した内容を蓄積し、有効化し、再度実行する。先ほどの 2 つのナレッジアイテムを有効化した状態で、同じ変換定義を 2 番目のリポジトリに対して実行します: git clone --depth 1 <second-repo-url> cd <second-repo> atx custom def exec -n "AWS/java-version-upgrade" -p . -c "<build-command>" -x -t 最初のリポジトリでは、ビルド検証コマンドとして -DskipTests を渡しましたが、エージェントはアップグレードの検証のためにテストも独立して実行しました。そのテスト実行中に、反復的に解決した 2 つの問題に遭遇しました: Mockito 5.14.2 が標準ライブラリクラスのモックに失敗。バンドルされた ByteBuddy が Java 26 のバイトコード操作を処理できなかったため、エージェントは 5.15.2 にアップグレード。 クラスパススキャン中に「Incompatible class format」でテスト実行が失敗。エージェントが最初に行った Spring Boot 3.2.12 へのアップグレードでは、Java 26 のクラスファイル（メジャーバージョン 70）を解析できない ASM バージョンが使用されていた。3.5.14 にアップグレード。 Transform custom はこれらを観察し、先ほどレビューしたナレッジアイテムとして蓄積し、修正内容を記録しました。エージェントは問題を解決し、その経験から再利用可能なナレッジを生成しました。 これらを有効化して 2 番目のリポジトリで実行します: atx custom def update-ki-status -n "AWS/java-version-upgrade" --id 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 --status ENABLED atx custom def update-ki-status -n "AWS/java-version-upgrade" --id adb1b8e6-4199-4d4d-964c-1eab5c94de1a --status ENABLED Mockito 5.14.2 または Spring Boot 3.2.x を使用して Java 26 をターゲットとする後続のリポジトリでは、Transform custom がテスト実行前に事前に修正を適用します。Mockito は 5.15.2 にアップグレードされ、Spring Boot は 3.5.14 に引き上げられます。テストは通過し、手動介入は不要です。 以前のリポジトリではデバッグと手動修正が必要だったことが、その後のすべてのリポジトリで自動的な修正になります。各実行はより高速で信頼性が高くなり、次の実行のために新しいエッジケースを蓄積します。 具体的に説明します。この変換定義を 1 週間で 15 の Spring Boot リポジトリに実行するとします。4 番目のリポジトリまでに、Mockito 5.14.2 を使用するすべてのプロジェクトに対して事前にアップグレードが適用されます。6 番目のリポジトリまでに、Java 26 をターゲットとする古い 3.x バージョンを検出するたびに Spring Boot 3.5.14 へのバージョンアップが自動的に行われます。10 番目のリポジトリでは、カスタム @Query アノテーションを持つリポジトリで Hibernate 6 のダイアレクト変更が問題になるかもしれません。すべての実行で新しいナレッジアイテムが生成されるわけではなく、エージェントが何を発見するかに依存します。しかし生成されたものをレビューし、望ましいものを有効化すれば、後続のすべての実行がその恩恵を受けます。15 番目のリポジトリは、最初のリポジトリよりもクリーンな変換になります。なぜなら、それ以前の 14 個分の蓄積された経験を持っているからです。 大規模な実行 本記事では 2 つのリポジトリを扱いました。大規模に展開する場合は、同じ変換定義をポートフォリオ全体に適用します。これが Learn-Scale-Improve フライホイール です。各実行が新しいナレッジアイテムを蓄積し、後続のすべての実行がシステムのこれまでの学習内容から恩恵を受けます。20 番目のリポジトリでは、最初のリポジトリで手動介入が必要だったパターンを自動的に処理します。 数百のリポジトリにまたがる実行には自動化が必要です。 aws-transform-custom-samples リポジトリには 2 つのオープンソースアプローチがあります: Bash 自動化 : ワークステーションから並列実行、進捗ダッシュボード、自動リトライを備えて実行します。 コンテナベース実行 : AWS Batch + AWS Fargate 上で数百から数千のリポジトリに対して実行します。セットアップの手順は AWS DevOps ブログの記事 をご参照ください。 クリーンアップ 変換はローカルで実行され、AWS リソースはプロビジョニングされません。クリーンアップするには: cd .. rm -rf aws-appconfig-java-sample AWS Batch でスケール実行を行った場合は、 コンテナベース実行の README にあるクリーンアップ手順に従ってください。 まとめ ナレッジアイテムはポートフォリオ全体で蓄積されます。各実行はエージェントが遭遇した内容に応じて新しい学びを生成する可能性があり、有効化したものが後続のすべての実行を高速化します。単発のリファクタリングスプリントではなく、今日の負債削減が明日のデリバリーを直接加速させる継続的なループが得られます。 ぜひお試しください: ご自身のリポジトリをクローンし、 AWS/java-version-upgrade 変換定義を実行して、生成されるナレッジアイテムを確認してみてください。組織固有のパターン（フレームワーク移行、コーディング規約の強制、依存関係の置き換え）がある場合は、 カスタム変換定義を作成 し、いくつかのリポジトリで実行して学習ループの動作を確認してみてください。 AWS Transform custom ドキュメント AWS マネージド Java アップグレード変換定義 : ご自身のコードベースでお試しください 独自の変換定義を作成 して組織固有のパターンに対応 aws-transform-custom-samples : 大規模実行のためのスクリプトとインフラ 著者について Jean-Baptiste Guillois Jean-Baptiste は、AWS のシニアスペシャリストソリューションアーキテクトであり、アプリケーションの移行とモダナイゼーションを専門としています。エンタープライズおよびソフトウェアベンダーとの 20 年以上の経験を持ち、AI を活用したサービスを使ってお客様がアプリケーションをより効率的にモダナイズできるよう支援することに情熱を注いでいます。 Gengis Birsen Gengis Birsen は、AWS の AI/ML および Generative AI スペシャリストソリューションアーキテクトです。エンタープライズのお客様と連携し、エージェント、評価、強化ファインチューニング、検索に重点を置いて、現在の生成 AI に関する課題に取り組んでいます。仕事以外では、現在の趣味は娘と一緒に Connetix のビルドを共同設計することです。

お知らせ 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 年 3 月 30 日に公開された Build high-performance apps with AWS Lambda Managed Instances を翻訳したものです。翻訳は 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 年 4 月 15 日に Migration & Modernization Blog で公開された AWS Transform: Comprehensive Codebase Analysis for Modernization を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 アプリケーションのモダナイゼーションは、多くの場合、困難なタスクから始まります。それは、システムの仕組みを理解するための包括的なレガシーコードベース分析です。多くのレガシーアプリケーションは長年にわたる段階的な変更を経て進化しており、ドキュメントは限られ、依存関係は密結合し、ビジネスロジックは複数のサービスやモジュールに分散しています。エンジニアリングチームにとって、この可視性の欠如は共通の課題を生み出します。モダナイゼーションを開始する前に、開発者はソースコードを確認してアプリケーションアーキテクチャ、動作パターン、隠れた依存関係を理解するための時間を費やす必要があります。この作業を行っても、サービス間の依存関係、アーキテクチャ上の制約、埋め込まれたビジネスルールなどの重要な知見は、変更がより複雑でコストがかかるプロジェクトの後半で明らかになることがよくあります。 AWS Transform の包括的コードベース分析マネージド変換は、アプリケーションの明確でエビデンスに基づいた理解を提供することで、これらの課題に対処します。これにより、数か月分の手作業を節約し、モダナイゼーションへの取り組みを加速できます。この記事では、変換の仕組み、前提条件、実行手順、実践的なシナリオを含めた結果の解釈方法、より広範なモダナイゼーションの取り組みとの関係、ベストプラクティス、トラブルシューティングガイダンスについて説明します。この記事を読み終えた頃には、ドキュメントが不十分なレガシーコードベースを構造化されたナビゲーション可能なナレッジベースに変換するための再現可能なアプローチを習得できるでしょう。 AWS Transform の包括的コードベース分析の仕組み この変換は、静的コード解析に基づいて動作します。決定論的ツール、基盤モデル（FM）、大規模言語モデル（LLM）、グラフニューラルネットワーク、自動推論を組み合わせて、アプリケーションコードベースの 4 つの重要な側面を分析します。 システム全体のコンポーネントの関係と依存関係 コードがどのように機能するかを明らかにする動作パターン 実装に埋め込まれたアーキテクチャ上の決定 ステークホルダーとのコミュニケーションのために平易な言葉で抽出されたビジネスロジック この多層的な分析により、技術チームとビジネスリーダーの両方が、実装中に問題が発生する前に十分な情報に基づいたモダナイゼーションの意思決定を行うのに役立つ構造化されたドキュメントが生成されます。 前提条件 開始する前に、以下を確認してください。 AWS Transform コマンドラインインターフェース （CLI）がインストールされていること: 詳細は スタートガイド を参照。 AWS 認証情報が設定されていること: 適切な権限で AWS CLI をセットアップし、AWS 認証情報に AWS Transform サービスを呼び出す権限があることを こちら で確認。最低限、 transform-custom: * の権限が必要。 クリーンな状態の読み取り可能なファイルを含む Git ソースコードリポジトリを準備すること: コミットされていない変更はコミットまたはスタッシュ。 推定所要時間: 30〜45 分（分析の実行時間を除く。実行時間はコードベースのサイズによって異なります） ステップバイステップガイド: 包括的コードベース分析の実行 以下の手順では、レガシーアプリケーションに対して AWS Transform の包括的コードベース分析を実行し、主要なステークホルダーと結果を共有し、インサイトに基づいて行動するまでの完全なプロセスを説明します。 ステップ 1: 環境の確認 AWS Transform が正しくインストールおよび設定されていることを確認します。 atx -version atx custom def list 上記のコマンドは、 AWS/early-access-comprehensive-codebase-analysis などの利用可能な AWS Transform マネージド変換を表示します。 注: 早期アクセス変換 (early-access-*) は機能しますが、お客様のフィードバックに基づいて頻繁に更新される可能性があります。時間が経つと、変換の名前が「AWS/comprehensive-codebase-analysis」として一覧に表示されるようになります。 図 1: AWS マネージド変換のリストで包括的コードベース分析変換が利用可能であることを確認 ステップ 2: コードベースの準備 Git リポジトリがクリーンな状態であることを確認します。 git status 図 2: 分析を実行する前に Git リポジトリがクリーンな状態であることを確認 既存のソースコードリポジトリをクローンします。 git clone <repository-url> 図 3: 包括的分析のためにレガシーコードベースリポジトリをクローン ステップ 3: ターミナルで以下のコマンドを実行 AWS Transform を使用して包括的分析を開始します。これにより、リポジトリ内のすべてのファイルと依存関係に対して深い静的解析が実行されます。 cd /path/to/your/project atx custom def exec -p /path/to/your/repository -n AWS/early-access-comprehensive-codebase-analysis -c "noop" -x -t 注: -n は変換名を指定します -c "noop" – ビルドコマンド（no operation – ビルドステップをスキップ） -x – 確認プロンプトなしでツールを自動信頼/実行 -t – インタラクティブターミナルモードを有効化 図 4: AWS Transform CLI を使用して包括的コードベース分析変換を実行 ステップ 4: 追加コンテキストの提供（オプション） よりターゲットを絞った分析を行うために、設定ファイルを使用して追加のガイダンスを提供できます。 transform-config.yaml という名前のファイルを作成します。 cat > transform-config.yaml << 'EOF' codeRepositoryPath: /Users/milola/Prince-of-Persia-Apple-II transformationName: AWS/early-access-comprehensive-codebase-analysis buildCommand: noop additionalPlanContext: | Focus analysis on the following areas: - Document the overall architecture and code structure - Identify deprecated or outdated coding patterns - Highlight areas that may benefit from modernization - Analyze dependencies and their relationships EOF カスタム設定ファイルを実行します。 atx custom def exec -g file://transform-config.yaml -x -t 図 5: YAML 設定ファイルを使用して追加コンテキスト付きで分析を実行 ステップ 5: 分析のモニタリング 処理が進むにつれて、階層的なドキュメント構造にまとめられた分析結果、優先度付けされた技術的負債のインサイト、簡単にナビゲートできる相互参照されたナレッジベースが提供されます。コードベースのサイズと複雑さに応じて、完全なプロセスには通常 45 分から 2 時間以上かかります。 ステップ 6: 結果の確認 分析が完了すると、4 つの領域にわたって整理された包括的なドキュメントセットが表示されます。 技術的負債レポート: 古くなったコンポーネントの優先度付きビュー、重大度別にランク付けされたセキュリティの問題、長期的な影響について評価されたメンテナンスの懸念事項。 アーキテクチャドキュメント: コンポーネントの依存関係グラフ、サービスの相互作用パターン、データフロー図を含むシステム全体の概要。 ビジネスロジックの抽出: 複雑なプロセスのわかりやすい言葉での説明。主要なビジネスルール、バリデーションロジック、外部統合ポイントを浮き彫りにします。 コード分析: コードベースのファイルごとの内訳。複雑度メトリクス、コード品質の指標、具体的なリファクタリングの機会を提示します。 以下は、プロジェクト概要、技術的負債レポート、コード分析出力、システムアーキテクチャ概要のスクリーンショットです。 プロジェクト概要: 図 6: ビジネスコンテキストと技術的成果を含む、包括的コードベース分析によって生成されたプロジェクト概要ドキュメント 技術的負債レポート: 図 7: プラットフォームの陳腐化やハードウェア依存関係を含む、重大度別に優先度付けされた重要な問題を強調する技術的負債レポート コード分析: 図 8: 複雑度、保守性の指標、品質評価を示すコード分析メトリクス システムアーキテクチャ概要: 図 9: モジュール性と結合度の具体的な評価を含む、システムの強みと弱みを示すアーキテクチャドキュメント ステップ 7: ナレッジベースのナビゲーション 生成されたドキュメントは、ハイレベルなレビューと詳細な調査の両方をサポートするように構造化されています。 ルートレベルでは、エグゼクティブサマリーが最も重要な技術的負債の分析結果とともに表示され、即座に注意を要するインサイトが明らかになります。さらに掘り下げると、ドメインレベルでは関連するコンポーネントが論理的なクラスターにグループ化され、コンポーネントレベルでは個々のモジュールの詳細な分析が提供されます。 ドキュメント全体を通じて、相互参照が関連するコンポーネントと依存関係を接続し、チームがコンテキストを失うことなくシステム全体の関係を追跡しやすくなります。 トップから始めて、モダナイゼーションの優先事項に最も関連する領域を分析してください。 ステップ 8: エクスポートと共有 各グループが受け取る内容を、それぞれの責任と意思決定のニーズに基づいてカスタマイズします。このターゲットを絞ったアプローチにより、各チームはモダナイゼーションの取り組みにおける自分たちの役割に最も関連するインサイトに基づいて即座に行動できます。 まず、エンジニアリングチームに技術的負債レポートを提示してください。これにより、モダナイゼーション中に遭遇するリファクタリングの優先順位とアーキテクチャ上の制約が把握できます。 アーキテクチャチームは、ターゲット状態の計画と慎重な検討が必要な統合ポイントの特定に、システム全体のドキュメントが非常に有用であると感じるでしょう。 ビジネスステークホルダーは、わかりやすい言葉でのビジネスロジック抽出から大きな恩恵を受けます。これにより、変換中に重要なワークフローとルールが保持されていることを検証できます。 セキュリティチームも、依存関係の分析とアーキテクチャのインサイトを確認して、モダナイゼーションプロセスの早い段階でセキュリティに関する考慮事項を特定できます。 ステップ 9: インサイトに基づいた行動 出力は、それに基づいて何を行うかによってのみ価値が決まります。短期的には、関連するセキュリティの問題への対処、優先度の高い技術的負債の正式なドキュメント化、今後のスプリント計画への分析結果の組み込みに注力してください。戦略的には、アーキテクチャのインサイトがモノリシックシステムの分解の決定に情報を提供し、依存関係の分析に基づいてモダナイゼーションの各フェーズの実施順序を決定します。技術的負債データは、測定可能なリスクと影響に基づいた説得力のあるビジネスケースを構築するための基盤を提供します。 実践的なシナリオ 数十年の歴史を持ち、ドキュメントが最小限で、理解できる開発者が限られているモノリシックアプリケーションを引き継いだとします。そして、ビジネスステークホルダーは数か月ではなく数週間以内にモダナイゼーションのタイムラインを必要としています。包括的コードベース分析は、そうでなければ広範な手作業を必要とするディスカバリーフェーズを加速し、数週間ではなく数時間で実行可能な結果を提供します。コンポーネントの相互作用を示す完全な依存関係グラフを生成し、リスクと影響で優先度付けされた技術的負債のホットスポットを特定し、技術とビジネスの理解を橋渡しするビジネスロジックを抽出し、分解戦略に情報を提供するアーキテクチャのインサイトを提供します。この基盤により、特定のコンポーネントをリファクタリングするか、リプラットフォームするか、置き換えるかについて十分な情報に基づいた意思決定が可能になり、推測ではなくエビデンスに裏付けられた現実的なモダナイゼーションタイムラインをビジネスステークホルダーに提供できます。 より広範なモダナイゼーションの取り組みとの関係 包括的コードベース分析は、単独ではなく、より広範なモダナイゼーション機能と連携して動作するように設計されています。生成されるインサイトは、モダナイゼーションジャーニー全体を通じて使用できます。分解の計画では、インサイトが実際の依存関係とアーキテクチャの境界に基づいてモノリシックアプリケーションを管理可能なドメインに分解する方法の理解を提供します。技術的負債の分析は、リスク、影響、ビジネス価値に基づいた順序付きの作業を確保し、モダナイゼーションの各フェーズの優先順位を決定します。詳細なコンポーネント分析は、システムのどの部分が変換の候補であり、どの部分が完全な置き換えの候補であるかを示すことで、リファクタリングの決定を明確にします。ビジネスステークホルダーにとっては、抽出されたビジネスロジックがモダナイゼーション投資のビジネスケースを構築するために必要なナラティブを提供します。これを、後続のすべてのステップをより意図的でより良い情報に基づいたものにする基盤と考えてください。 ベストプラクティス 変換を実行する前に、結果に影響を与える可能性のある既知の問題や制限事項を文書化し、注力すべき特定の懸念領域を特定してください。 変換をターゲットを絞ったインサイトに導くために明確な追加コンテキストを提供し、出力を充実させることができる関連するアーキテクチャ図やドキュメントを含めてください。 分析が完了したら、チームとして技術的負債の分析結果をレビューし、技術的な重大度だけでなくビジネスへの影響に基づいて修正の優先順位を決定してください。 インサイトをスプリント計画と長期的なロードマップに活用し、技術者と非技術者の両方のステークホルダーとドキュメントを共有して、全員がシステムの全体像を理解できるようにしてください。 トラブルシューティング 結果に具体的なインサイトが不足している場合 出力が一般的すぎると感じる場合、最も効果的な修正方法は、エージェントにより明確な方向性を与える additionalPlanContext を通じてより詳細なコンテキストを提供することです。認証、決済処理、特定のサービスレイヤーなど、最も関心のある注力領域やドメインを指定し、エージェントがよりターゲットを絞った分析結果を生成できるように、既存のアーキテクチャドキュメントや図を参考資料として含めることを検討してください。 分析が完了しない場合 分析が完了できない場合は、エージェントが自力で解決できない可能性のある依存関係や設定ファイルの欠落を確認し、プロセスに干渉する可能性のあるコミットされていない変更がない、クリーンな状態の Git リポジトリであることを確認してください。大規模または複雑なコードベースの場合は、エージェントをガイドするために焦点を絞った additionalPlanContext を提供してください。 ドキュメントが広範すぎる場合 生成されたドキュメントが必要以上に広い範囲をカバーしている場合は、 additionalPlanContext でモジュールやドメインを指定してスコープを絞ってください。また、リポジトリ全体ではなく特定のサブディレクトリに対して分析を実行することもできます。これにより、システム全体の出力を確認する必要なく、最も重要な領域に焦点を当てた実行可能なインサイトを得ることができます。 まとめと次のステップ コードベースを理解することは、モダナイゼーション成功の基盤です。AWS Transform の包括的コードベース分析は、数か月の手動ドキュメント作成を数時間の AI によるインサイト生成に変換します。これにより、コードを変更する前に十分な情報に基づいた意思決定を行うための明確さが得られます。この基盤があれば、リアクティブではなく戦略的にモダナイズでき、レガシーアプリケーションをビジネスを推進するスケーラブルで保守可能なシステムに変えることができます。 次のステップとして、パイロットモダナイゼーションプロジェクトから始めてください。以下の追加リソースを確認し、レガシーコードベースに対して包括的コードベース分析を実行してください。アーキテクチャのインサイトを分解の計画に活用し、技術的負債の分析結果に基づいてモダナイゼーションの各フェーズの優先順位を決定し、抽出されたビジネスロジックをステークホルダーと共有してアラインメントを構築してください。定期的に再実行して進捗を追跡し、モダナイゼーションの取り組みが計画した成果を達成していることを検証できます。 追加リソース AWS Transform custom Documentation AWS Comprehensive Codebase Analysis Getting Started with AWS Transform Quotas for AWS Transform Ask questions on re:Post 著者について Damilola Odeleye Damilola Odeleye は、Amazon Web Services (AWS) のシニアテクニカルアカウントマネージャーです。エンタープライズ組織と連携し、クラウドのモダナイゼーションを加速させ、ビジネスに大きなインパクトをもたらす成果を推進しています。モダナイゼーションと AI/ML の両分野を専門とし、テクノロジーを長期的なビジネス成長と整合させることに注力しています。 Srinivas Ganapathi Srinivas Ganapathi は、Amazon Web Services のプリンシパルテクニカルアカウントマネージャーです。カナダのトロントを拠点とし、ゲーム業界のお客様と協力して、AWS 上で効率的にワークロードを実行できるよう支援しています。

本記事は 2026 年 4 月 26 日に AWS DevOps & Developer Productivity Blog で公開された AWS Transform custom: Enterprise Code Modernization with the Learn-Scale-Improve Flywheel を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 エンタープライズにおけるモダナイゼーションは、大きな転換点を迎えています。1 つのリポジトリを変換するだけなら容易です。 AWS Transform custom でも、他の既存のツールでも、個別のリポジトリに対して十分に機能し、プロセスも確立されています。しかし、50 のリポジトリではどうでしょうか。100、200 ではどうでしょうか。エンタープライズ規模でモダナイゼーションを進めようとすると、コードを変換することは課題全体の一部にすぎません。人員の調整、ナレッジの蓄積、そしてポートフォリオ全体における品質の維持も重要になります。 本記事では、AWS Transform custom の 大規模な自動化の仕組み が、インテリジェントな学習とスケール実行によって、エンタープライズにおける組織内連携の課題をどう解決するかをご紹介します。あるお客様は、モダナイゼーション全体の期間を 7-12 週間から 2.5 週間へと短縮し、デリバリー期間を 3-5 分の 1 に、総工数を 10-20 分の 1 に削減しました。そして何より、ご自身のモダナイゼーションの取り組みを今すぐ始めるための方法をお伝えします。 エンタープライズ規模における組織内連携の課題 エンタープライズのアーキテクトに直近の大規模モダナイゼーションについて尋ねると、きまって同じような話を耳にします。例えば、あるエンタープライズソフトウェア企業では、大規模なレガシーコードベースをモダンなプラットフォームへ移行する必要がありました。当初の見積りは、複数チームにまたがる調整作業を含めて 12 週間の集中的な作業でした。 コード変換そのものは数日で完了しました。しかし残りの数週間は、コード変換を取り巻く一連の作業に費やされました。具体的には、タイムゾーンをまたぐチームの調整、異なる経緯を持つコードベース間でのパターンの一貫性の確保、そして上流の変更が下流のシステムを壊さないよう依存関係を管理することです。各チームはミーティングやスプレッドシートでステータスを追跡し、シニア開発者の頭の中にしか存在しない暗黙知に頼っていました。 これがエンタープライズにおける組織内連携の課題です。1 つのリポジトリから数百のリポジトリへとスケールするとき、連携のオーバーヘッドは爆発的に増大します。リポジトリが 1 つ増えるごとに、そのリポジトリ自身の複雑さだけでなく、新たな連携箇所、エッジケース、そして想定外の調整要件が加わるのです。 見落とされがちな 70% のギャップ エンタープライズの案件において、私たちはコード変換がモダナイゼーション作業全体の約 30% にすぎないことを確認してきました。残りの 70% には、テスト生成、検証、包括的なドキュメント作成、ビジネス分析、そして数百の作業項目にまたがる組織的な調整などが含まれます。 このギャップこそが、変換ツールによる生産性向上がなかなか実を結ばない理由です。ツールがコードの変更は処理できても、組織は連携、検証、ナレッジの蓄積に依然として苦労しています。変換作業は迅速に終わるのに、プロジェクト全体は数か月を要するという状況です。 実際に私たちが目にしてきたのは、従来のアプローチがエンタープライズ規模で機能しないという事実です。各リポジトリを独立した課題として扱ってしまうからです。チームはコードベース間で同じ作業を繰り返し、一貫性のない判断を下し、開発者が別のプロジェクトへ異動するたびに学びを失っていきます。組織のナレッジは再利用可能な資産とならず、個人の頭の中に閉じ込められたままです。 エンタープライズモダナイゼーションへの新しいアプローチ AWS Transform custom は、エンタープライズモダナイゼーションに対して異なるアプローチをとります。同じ操作を何百回も繰り返すのではなく、すべての実行から学習し、そこで得た知見を次の変換の改善に活用します。 Learn-Scale-Improve フライホイール この Learn-Scale-Improve（学習・スケール・改善）フライホイール のワークフローは、リスクを最小化しつつ学習効果を最大化するよう綿密に設計されたステップで進みます。まず小規模な Learn (学習) パイロットから始め、一括自動化を通じて Scale (スケール) し、計画的なレビューによって Improve (改善) する。このサイクルを繰り返すフライホイールによって、イテレーションのたびに前回よりも良い結果を生み出します (図 1)。 図 1: AWS Transform custom の変換ワークフローにおける Learn-Scale-Improve フライホイール Learn (学習) : 代表的な 2-3 個のリポジトリを対象に、インタラクティブモードで変換を実行するところから始めます。AI エージェントと直接やり取りしながら、各ステップでの判断にフィードバックを提供し、品質を検証します。エージェントが曖昧な箇所に遭遇すると質問を投げかけ、お客様がガイダンスを与えると、システムがそのコンテキストを記録します。パイロットの最後には、蓄積されたフィードバックを確認して変換定義を修正します。その結果として得られるのは、お客様の組織のナレッジが組み込まれた、スケール実行の準備が整った変換定義です。 Scale (スケール) : 次に、自律モードへ切り替えて一括実行を行います。システムは数十、数百のリポジトリを一晩で、手動介入なしに処理し、パイロットで学習したパターンを適用します。ビルドコマンドやテストコマンドを使用して変換結果を検証し、ポートフォリオ全体の進捗状況をリアルタイムで追跡します。これまで数週間のチーム調整を要していた作業が、一晩で完了します。実行中、システムは新しいエッジケース、想定外のパターン、パイロットでは見えてこなかった最適化の機会などを発見事項として記録します。 Improve (改善) : 一括実行のラウンドが終わるごとに、処理中にシステムが記録したナレッジアイテムをレビューします。これらの発見事項は、パイロットではカバーできなかったリポジトリ特有のパターンやエッジケースを浮き彫りにします。その中から価値のある学びを承認することで、次のイテレーションに向けて変換定義が改善されます。このレビューステップが品質管理の役割を担います。システムは自己改変せず、どの学びを取り込むかを決めるのは、変換定義のオーナーです。 Scale と Improve のサイクルは繰り返されます。一括実行のラウンドごとに得られたインサイトが、次のラウンドをさらに効果的にします。変換の成功率は向上し、手動介入は減少し、エッジケースのハンドリングもイテレーションを重ねるたびに改善されます。 このフライホイールは、エンタープライズが組織としてナレッジをどう蓄積し共有するかを大きく変えます。変換定義は単なる自動化スクリプトではありません。特定のモダナイゼーションシナリオに対して、自社がどう取り組むかを体系化した組織資産です。アーキテクトが変換戦略を定義すると、その戦略は再利用可能な定義としてレジストリに保存されます。チームがベストプラクティスを特定すると、それらは変換定義の中に埋め込まれ、すべてのリポジトリに自動的に適用されるようになります。従来であれば、シニア開発者がチームを離れれば、そのナレッジも一緒に消えてしまっていました。AWS Transform custom を利用すれば、その専門知識を変換定義やナレッジアイテムとして蓄積し、組織全体で使える形にできます。個人の専門性が、組織のケイパビリティへと昇華するのです。 エンタープライズのお客様によるモダナイゼーション事例 これらの生産性向上は理論上の予測ではなく、実際の本番環境での成果です。あるエンタープライズソフトウェア企業では、本番環境で稼働する大量の Control-M（訳註: BMC Software 社のワークロード自動化プラットフォーム）のワークフローを Apache Airflow へ移行する必要がありました。このモダナイゼーションには、技術的な精密さと、複雑かつ相互依存するコードベース全体における一貫性の両方が求められました。当初の見積りでは、複数チームでの集中的な調整に 12 週間を要するとされ、一貫性の欠如や統合失敗のリスクも抱えていました。 この企業は、 AWS Transform custom を活用して Learn-Scale-Improve のイテレーション型ワークフローを実行しました。パイロットフェーズでは、代表的なリポジトリに対してインタラクティブモードでの変換を実行し、結果をレビューしたうえで変換定義を洗練させました。イテレーションを重ねるごとに、変換定義はエッジケースへの対応精度を高めていきました。その後、自律モードの一括実行へと移行し、ポートフォリオ全体の移行を 2.5 週間で完了しました。 検証の結果、対象となったすべてのワークフローで 100% の成功率を達成しました。エッジケースのハンドリングは従来のアプローチと比べて 60% 改善し、変換後のコードは業界の専門家が求めるコード品質基準を満たしながら、実行時のパフォーマンスも 19% 向上しました。この事例は、移行のスピードと本番品質の両立が可能であることを示しました。従来のアプローチと比較して、デリバリー期間を 3-5 分の 1 に、総工数は 10-20 分の 1 に削減しました。 ポートフォリオ全体の変換を始めましょう AWS Transform custom の大規模な自動化の仕組みは、 GitHub リポジトリ でソリューションとして提供されています。Learn-Scale-Improve ワークフローに沿って、モダナイゼーションの取り組みを始めてみてください。 前提条件 開始前に、以下をご確認ください。 AWS Transform custom へのアクセスが有効化された AWS アカウント 適切な認証情報で構成された AWS CLI ローカルマシンまたは CI/CD 環境にインストールされた Git AWS Transform custom の操作に必要な IAM 権限 実装の進め方 AWS Transform custom は、 Java のアップグレード (例: 8 から 17、17 から 21)、Python の移行 (例: 3.7 から 3.11)、Node.js のアップデート (例: 14 から 20)、AWS SDK の移行 (例: boto2 から boto3、SDK v1 から v2) など、多様な変換 をサポートしています。これらの AWS マネージドな変換に加えて、組織固有の標準、独自のフレームワーク移行、各環境特有のアーキテクチャパターンに対応するカスタム変換定義を作成することもできます。 AWS Transform custom は、既存の開発プロセスに自然に統合できます。CLI は Jenkins、GitLab CI、GitHub Actions といった CI/CD パイプラインと連携します。変換結果はローカルの Git ブランチとして生成され、お客様の標準的なコードレビュー・マージプロセスに沿って流れていきます。Web インターフェイスでは、チーム横断での進捗状況を一元的に可視化できます。検証コマンドは変換処理中に自動的に実行され、変更が完了したと見なされる前にコードが正常にビルドされ、テストが通過していることを保証します。変換処理の終了時に検証条件を満たさない場合、その変換は失敗として扱われます。 スケール実行までの道のりを加速するため、AWS は本番環境で利用できるスタート地点となるオープンソースのサンプルリポジトリを提供しています。複数のリポジトリと変換定義に対して同時に変換を実行するためのものです。 aws-transform-custom-samples の scaled-execution リポジトリには、一括実行をオーケストレーションするスクリプト、リポジトリのキューイングを管理する仕組み、ポートフォリオ全体のステータス追跡を扱うスクリプトが含まれています。オーケストレーションをゼロから構築するのではなく、サンプルをクローンし、ご自身のリポジトリリストと変換定義で設定すれば、すぐにスケール変換の実行を始められます。 まとめ エンタープライズ規模でのモダナイゼーションには、コード変換ツール以上のものが必要です。本当の課題は、チーム間の連携、実行からの学習、そしてナレッジを組織資産として蓄積することにあります。AWS Transform custom の Learn-Scale-Improve ワークフローは、これらの課題に対して、実行のたびに品質を高める継続的学習、暗黙知を再利用可能な資産へと変える組織ナレッジの捕捉、そして数百のリポジトリに一貫して適用できる一括自動化で応えます。次に重大なセキュリティ脆弱性が発見され、リポジトリ全体のフレームワーク更新が必要になったときも、新しいランタイムのバージョンでパフォーマンスを改善できるようになったときも、すでに効果を検証済みの変換定義を使って、数か月ではなく数日単位で対応できるようになります。 実際のお客様は、デリバリー期間を 3-5 分の 1、総工数を 10-20 分の 1 に削減し、モダナイゼーションを数か月から数週間に圧縮しています。これは願望ではなく、AWS Transform custom を活用している組織が本番環境で実現している成果です。 今すぐ変換を始めましょう まずは 2-3 個の代表的なリポジトリを対象に Learn-Scale-Improve ワークフローを実施し、変換定義を洗練させたうえで、ポートフォリオ全体へと展開してください。 AWS Transform custom の大規模な自動化の仕組みをさらに深く知るには、以下のリソースをご覧ください。 AWS Transform custom ドキュメント : 全機能、API リファレンス、統合ガイドを網羅した技術ドキュメント: AWS Transform custom Scaled Execution サンプルリポジトリ : 複数のリポジトリと変換定義に対して変換を実行するためのオープンソーススクリプト: aws-transform-custom-samples Transformation Registry : AWS マネージドな変換の発見と、カスタム定義の作成: aws-transform-custom-samples 取り組みを開始するには、AWS アカウントチームにお問い合わせいただくか、AWS Transform custom のドキュメントをご参照ください。 著者について Meghan Kothari Meghan Kothari は、Customer Experience and Business Trends チームのシニアテクニカルプロダクトマネージャーです。AWS のリーダーシップと連携し、Agentic AI を活用したアプリケーション開発とモダナイゼーションにおける進化するトレンドを発見するための戦略的な Deep Dive に取り組んでいます。ソリューションアーキテクトおよびフルスタック開発者としての経歴により、開発者体験の形成に貢献する独自の実践的な視点を持っています。 Venugopalan Vasudevan Venugopalan Vasudevan (Venu) は、AWS のプリンシパルスペシャリストソリューションアーキテクトであり、AWS Transform に焦点を当てた Agentic AI の取り組みを主導しています。お客様が AI を活用した開発者向けソリューションおよびモダナイゼーションソリューションを採用しスケールさせ、イノベーションとビジネス成果を加速できるよう支援しています。 Rodney Grilli Rodney Grilli は、AWS のプリンシパルテクノロジストであり、Agentic AI サービスを活用した製品およびコードのモダナイゼーションを専門としています。お客様が製品ポートフォリオをモダナイズし、AI-Native Enterprise への変革を加速できるソリューションを構築しています。

re:Invent 2025 でコスト効率（Cost Efficiency）メトリクス を発表して以来、お客様から繰り返し寄せられる質問があります。「自社は他社と比べてどうなのか？」というものです。この問いに答えるため、私たちは直近四半期において、分析への参加に同意いただいた 71,000 社を超える AWS のお客様の匿名データを対象に、最適化のパターンを分析しました。Savings Plans のカバレッジは、あらゆるコスト最適化戦略の基盤となるものですが、それはパズルの 1 ピースに過ぎません。データが示すのは、コスト効率が最も高いお客様では、Savings Plans だけにとどまらず、削減効果を複利的に高める一連のプラクティスを実践しているということです。本レポートでは、トップパフォーマーが何を実践しているのか、そして彼らと同じ成果を実現するためにはどうすればよいのかを、詳しく解説します。 2026 年 5 月時点で、すべてのお客様のコスト効率スコアの中央値は 83、一方で平均値は 79 です。この差は、最適化が進んでいないアカウントによるロングテール（裾が長い分布）によって生じています。 EC2 のメモリメトリクスを有効化すると、推奨事項 1 件あたりの削減率が 8〜30 パーセンテージポイント高くなる傾向がありますが、対象のお客様のうち有効化しているのはわずか 17.7% にとどまっています。 AWS Compute Optimizer の「アイドル状態」および「ライトサイジング」の推奨事項をカスタマイズしているお客様は、カスタマイズしていないお客様よりスコアの中央値が 3〜4 ポイント高くなっています。 直近四半期のデータによると、Savings Plans とライトサイジングを併用している大規模なお客様は、Savings Plans のみを利用するお客様と比べて、新しい世代のハードウェアで実行している EC2 インスタンスの割合が約 60% 多く、コスト効率スコアの中央値の改善も 4 倍速い傾向にあります。 Savings Plans のカバレッジが高いと、ライトサイジングや Graviton による最適化機会が見えにくくなる場合があります。Savings Plans のカバレッジが 95〜100% のお客様では、カバレッジが 0〜25% のお客様と比べて、Savings Plans 以外の最適化機会の合計が 65〜80% 減少することが確認されています。 コスト効率メトリクスとは？ コスト効率は、 AWS Cost Optimization Hub において毎日算出される単一のスコア（0〜100%）で、最適化可能な支出額のうち、すでに十分に最適化されている割合を測る指標です。このスコアは、ワークロードの最適化（ライトサイジング、アイドルリソースのクリーンアップ）とレートの最適化（Savings Plans、リザーブドインスタンス）を 1 つの数値に統合しています。メトリクスの仕組みの詳細については、 コスト効率の発表ブログ をご覧ください。 あなたの効率スコアはどのくらい？ 2026 年 5 月時点で、すべてのお客様のコスト効率スコアの中央値は 83、一方で平均値は 79 です。この差は、最適化が進んでいないアカウントによるロングテール（裾が長い分布）によって生じています。 Cost Optimization Hub を開けば、自社の現在地を確認できます。注記：新しい最適化の推奨事項がリリースされると、スコアが変動する場合があります。 最適化の傾向をさらに理解するため、私たちは支出規模に基づいてお客様を「小規模」と「大規模」の 2 グループに分類しました。これは、概ね中小企業とエンタープライズ企業の区分に相当します。小規模のお客様では、最もスコアが低いお客様と最もスコアが高いお客様との間に 52 パーセンテージポイントの開きがあるのに対し、大規模なお客様ではこの差が 35 パーセンテージポイントとより狭い範囲に集中しています。いずれのグループも、上位層では高い効率スコアに達しています。ここから読み取れるポイントは 2 つあります。 小規模のお客様では、スコアのばらつきが大きく、FinOps プラクティスを本格的に導入しているお客様と、取り組みがまだ初期段階にあるお客様が混在していることを反映しています。 大規模のお客様は、より一貫して最適化を行っています。専任の FinOps チームや Savings Plans 戦略を持つ傾向が高く、その結果としてスコアも高くなっています。 図 1. 小規模・大規模のお客様におけるコスト効率スコアの分布。小規模のお客様は 52 ポイントの範囲に分布し、大規模のお客様はより狭い 35 ポイントの範囲に分布している。両グループともに、分布の上位層では同程度に高いスコアに達している。 高い効率スコアは、どこからでも到達できる スコアが高いお客様と低いお客様の違いを分析した結果、上位 25% のお客様に共通して見られる 4 つの行動を特定しました。 Amazon EC2 のメモリメトリクス Amazon CloudWatch  またはサポートされている サードパーティのオブザーバビリティツール を通じて  EC2 インスタンスのメモリメトリクス を有効化しているお客様は、スコアが高くなる傾向があります。既存の EC2 インスタンスでメモリメトリクスを有効化することは、EC2 のコスト最適化において最も効果の高い施策の 1 つです。多くのインスタンスにおいて、メモリデータがあるかどうかで、ライトサイジングの推奨が得られるか、全く得られないかが決まります。新たな削減機会が表面化することで、一時的にコスト効率スコアが低下する場合がありますが、それは、対処できる削減余地をより多く掘り起こせていることを意味します。EC2 のメモリメトリクスを有効化すると、推奨事項 1 件あたりの削減率が 8〜30 パーセンテージポイント高くなる傾向がありますが、対象のお客様のうち有効化しているのはわずか 17.7% にとどまっています。図 2 は、メモリメトリクスの導入が、さまざまなインスタンスタイプでどの程度削減率を向上させるかを示しています。 図 2. メモリメトリクスの有無によるインスタンスタイプ別の削減率 推奨事項設定のカスタマイズ AWS Compute Optimizer の推奨事項をカスタマイズ しているお客様は、カスタマイズしていないお客様よりスコアが 3〜4 ポイント高くなっています。推奨事項のカスタマイズは、必ずしも削減額の増加に結びつくわけではありません。しかし、それはチームが最適化に積極的に取り組み、エンジニアリングチームに推奨事項を信頼してもらえるよう努めていることを示す先行指標となります。 高い Savings Plans のカバレッジはゴールではない Savings Plans のカバレッジが高いお客様は、コスト効率スコアも高くなります。Savings Plans は最適化済みの支出としてカウントされるため、Savings Plans のカバレッジとスコアには直接的な相関があり、カバレッジを上げればスコアも高くなります。一見するとこれは、「高度に最適化されている」という喜ばしい状況に見えますが、時に誤解を招くことがあります。なぜなら、その背後にあるリソースは依然として過剰なサイズである、あるいはアイドル状態である可能性があるからです。 Savings Plans のカバレッジが 95〜100% のお客様では、カバレッジが 0〜25% のお客様と比べて、Savings Plans 以外の最適化機会の合計が 65〜80% 減少することが確認されています。これらの削減機会は、コミットメントが更新時期を迎えたとき、またはワークロードが変化したときに初めて、再び実行可能になります。大規模・小規模のお客様における削減額については、図 3 をご覧ください。ここから次のポイント、「まず縮小する（Shrink first）」につながります。 図 3. Savings Plans カバレッジが低い場合（0〜25%）と高い場合（90%以上）における、ライトサイジングおよび Graviton による削減額の差 まず縮小し、それからコミットする（複利効果） 最も効率的なお客様は、Savings Plans と能動的なライトサイジングを組み合わせており、コスト効率スコアと実際の総削減額の両方で、より大きな成果を上げています。直近四半期のデータによると、コミットメントとライトサイジングを併用している大規模なお客様は、Savings Plans のみを利用するお客様と比べて、新しい世代のハードウェアで実行している EC2 インスタンスの割合が約 60% 多く、コスト効率スコアの中央値の改善も 4 倍速い傾向にあります。Savings Plans を利用しているお客様のうち、能動的にライトサイジングを行っているのは 47.1% に過ぎず、潜在的な削減機会が手つかずのまま残されています。コミットメントはインスタンスの単価を下げ、ライトサイジングは必要なインスタンスのサイズを縮小します。新しい世代のハードウェアでワークロードを稼働させることで、より高い性能を得ながら、単位あたりのコストも下げられます。時間の経過とともに、追加の Savings Plans がより無駄のない最新のリソース構成に割引を適用するため、これらの削減効果は複利的に積み上がっていきます。 効率スコアを改善する方法 ここまで、トップパフォーマーが何を実践しているかを見てきました。ここからは、これらのインサイトを実際の行動に移していきましょう。以下のステップは、リスクと労力の小さい順に並べてあり、まずは取り組みやすい施策から始めて、信頼と推進力を高めながら、より大きな変革へとつなげていくことができます。 アイドルリソースから始める アイドルリソースのクリーンアップは、最もリスクの低い出発点です。対象となるのは、何の役割も果たしていない可能性が高いリソース、たとえばどこにもアタッチされていない Amazon EBS ボリューム、使用率がほぼゼロの EC2 インスタンス、接続のない Amazon RDS データベースなどです。 AWS Compute Optimizer は、 Amazon Elastic Compute Cloud （Amazon EC2）、 Amazon Elastic Block Store （Amazon EBS）、 Amazon Relational Database Service （Amazon RDS）をはじめとするコンピューティング、ストレージ、ネットワークの各サービスにわたって、 アイドルリソース を特定します。今週初めには、 アイドルリソースの検出対象をさらに 6 つの AWS サービスに拡大し 、アイドルリソースに関する推奨事項の数を 2 倍に増やしました。 これらの推奨事項はすべて、 Cost Optimization Hub に集約された形で確認できます。各推奨事項には、そのリソースをアイドル状態であると判定した具体的な基準が含まれています。たとえば、アイドル状態の EC2 インスタンスとは、直近 14 日間においてピーク時の CPU 使用率が 5% 未満、かつネットワーク I/O が 1 日あたり 5 MB 未満であるものを指します。アクションを実行する前に、そのリソースが本当に不要であるかどうかを確認することをお勧めします。EBS ボリュームについては、Compute Optimizer は削除前のスナップショット作成を推奨しています。これにより、データを復元可能な状態に保てます。RDS については、再び必要になる可能性がある場合は、削除ではなくインスタンスの停止を検討するとよいでしょう。ただし、RDS インスタンスはメンテナンスのため 7 日ごとに 自動的に再起動 される点にご注意ください。そのため、長期的な解決策としては、スナップショットを取得したうえで削除することになります。多数の推奨事項に対応しやすくするために、Compute Optimizer の 自動化機能 を利用できます。この機能は、EBS のアップグレードやアタッチされていないボリュームのクリーンアップに関する推奨事項を、設定した基準に合致した場合に定期的に適用し、スナップショットの作成やロールバックにも対応しています。まずは本番以外の環境から始めて、確信を得たうえで、対象を広げていくとよいでしょう。 リソースをライトサイジングする リソースの ライトサイジング は、大きなコスト削減の可能性を秘めています。メモリデータを有効にすると、Compute Optimizer は、メモリの実際の使用状況も把握できるようになるため、メモリ不足を懸念して保守的な推奨にとどまることなく、EC2 インスタンスの CPU とメモリの両方を適正なサイズ に調整できます。新たな削減機会が表面化することで、最初はスコアが低下する場合があります。しかしそれは、実現可能な削減余地がそれだけ多くあることを意味します。Compute Optimizer は、 RDS および Aurora データベース 、 EBS ボリューム 、 Lambda 関数 、 ECS on Fargate  など、さまざまなリソースについてもライトサイジングの推奨事項を提供します。まずは削減額の合計が最も大きい推奨事項に注目し、本番以外のリソースから着手することで、エンジニアの信頼を得ていきましょう。また、 推奨事項をカスタマイズして 、組織のリスクおよびパフォーマンスの許容度に合った内容に近づけることも検討してください。このカスタマイズは、 Compute Optimizer コンソール から、ルックバック期間、使用率のヘッドルーム、インスタンスファミリーなどの項目について推奨事項の設定を調整することで行えます。これらの設定は、組織全体に対して一度だけ構成することも、パフォーマンスとコストのトレードオフが異なる環境向けにアカウントごとに構成することも可能です。 最適化済みリソースの上にコミットメント購入を重ねる アイドルリソースをクリーンアップし、インスタンスのライトサイジングを終えたら、無駄を削減したリソースに対して Savings Plans を購入します。最大限の削減を得るには、この順序が重要です。先にすべてのリソースに対してコミットメントを購入してしまうと、過剰にプロビジョニングされた容量に割引レートを固定することになり、後からライトサイジングをしても、請求額が下がるのではなくコミットメントが余ってしまいます。別の方法として、 より小さい単位で頻繁に購入を始め 、ライトサイジングの進行に合わせてカバレッジを段階的に増やしていくこともできます。この方法には、将来、大きなコミットメントが一度にまとめて期限切れを迎える「崖」を回避できるという利点もあります。新しい Savings Plans Purchase Analyzer のターゲットカバレッジ機能を利用すれば、一度に大きくまとめてコミットするのではなく、時間をかけて段階的にカバレッジを買い増していくことができます。 進捗を追跡し、改善を繰り返す コスト効率スコアは毎日更新されるため、月曜日に実施したアクションは水曜日までに反映されます。このフィードバックループを活用して、削減機会とコスト効率スコアへの影響を確認し、目標に対する進捗を追跡しましょう。月次・四半期ごとの目標を設定すれば、FinOps チームは、具体的なコスト削減額と結びついたコスト効率の改善成果を示せるようになります。週次または隔週のレビューサイクルを設け、アカウント単位の内訳も確認しましょう。これは、最適化目標を着実に追い続ける必要があり、運用面での規律が求められるチームに役立つとともに、最も効率的に取り組んでいるチームの優れた実践を可視化することにもつながります。 まとめ 私たちは、71,000 社を超える AWS のお客様の最適化パターンを分析し、「最も効率的なお客様が何を実践しているのか？」という 1 つの問いに答えました。トップ層のお客様で実施しているのは、Savings Plans の購入だけにとどまりません。メモリメトリクスを有効化し、コミットする前にライトサイジングを行い、最適化を一度きりのイベントではなく継続的な取り組みとして捉えています。 こうしたトップ FinOps プラクティスを実践することで、戦術的に信頼を積み重ねながら文化の変革を促し、測定可能な形でより大きな削減を実現できます。 Cost Optimization Hub を開いて 、現在のスコアと、最も大きな削減機会がどこにあるかを確認してください。スコアは毎日更新されます。 翻訳はテクニカルアカウントマネージャーの西村が担当しました。原文は こちら です。 Rick Ochs Rick Ochs は、Compute Optimizer や RI/SP 購入の推奨事項など、AWS における最適化関連製品を担当するプロダクトチームを率いています。AWS に入社する以前は、Turbonomic で最適化にフォーカスしたクラウドプロダクトチームを牽引していました。 Raj Mehta Raj Mehta は、Amazon Web Services で 4 年の経験を持つプログラムマネージャーです。大規模にカスタマーエクスペリエンスを向上させることを目的としたクラウドの請求・支払いプログラムを牽引しています。これまでの業務には、クレジット適用システムの自動化、請求データの異常検知の開発、AI を活用した請求ワークフローの構築などがあります。デューク大学で定量分析の修士号を取得しており、お客様がクラウドの請求とどのように関わっているかを理解し、改善するために、データドリブンな視点をもたらしています。 Arun Somalinga Arun Somalinga は、AWS のシニアソフトウェア開発エンジニアであり、バックエンド開発において 10 年以上の経験を持っています。彼は AWS Cost Optimization Hub および AWS Compute Optimizer に携わり、数百万に及ぶ AWS アカウントに対して日々、最適化に関する推奨事項のインデックス化と提供を行うコントロールプレーンシステムを構築しています。以前の業務では、AWS Support において診断ツールを構築し、エンジニアがお客様の問題をより迅速に解決できるよう支援しました。仕事以外では、バドミントンと読書を楽しんでいます。

本記事は「 New in Kiro Web: Build with Spec, GitLab, and more 」を翻訳したものです。 先月、私たちは Kiro Web をプレビュー版として公開 し、皆さんがすでに作業している場所へと Kiro を広げました。ブラウザから Kiro とともにアイデアを探求して変更を形にし、ローカル環境を最初にセットアップすることなくプルリクエストをオープンします。あるいは自律モード（Autonomous mode）でタスクを任せれば、Kiro が最初から最後まで処理します。いずれの場合も、1 つのセッションで複数の GitHub リポジトリにまたがる 1 つの変更を調整できます。公開以降、私たちはワークフローの改善を一通り提供してきました。今回のアップデートでは、開発者の皆さんから要望のあった 2 つの機能をお届けします。構造化されたスペックワークフローがブラウザで実行できるようになり、さらに Kiro Web が GitLab に対応しました。GitLab と GitHub の両方にまたがるセッションも含めてです。 Spec が Web へ スペックは、重要な意思決定を最初に行います。プロンプトから直接コードへ進むのではなく、Kiro とともに「何を作るか」「どのように動作すべきか」「何を含めないか」を、曖昧さや矛盾を最も容易に発見できる、コードを書く前に定義します。実装はレビュー済みのスペックから始まるため、プルリクエストの内容はあなたが承認したものを反映しており、後から軌道修正が必要な「最初の推測」ではありません。Kiro Web は Kiro IDE と同じスペックタイプをサポートしているので、Feature Spec を書いたり、Bugfix Spec を進めたり、作業内容が十分に理解できていて要件・技術設計・タスクを一度にまとめたい場合は Quick Plan を使ったりできます。 Kiro はスペックごとにドキュメントを生成します。要件（requirements）は何を作るかを記録し、設計（design）はアプローチを説明し、タスクリスト（task list）は作業を個別のステップに分解します。これらをブラウザ上で直接レビューし、Kiro とチャットしながら要件を追加したり、設計の一部を考え直したり、作業の分解方法を調整したりしながら磨き上げられます。スペックの準備が整ったら、サンドボックス内で Kiro にすべてのタスク、あるいは特定のタスクを実行させることができ、作業が完了するとプルリクエストがオープンされます。。スペックを保存したい場合や別の場所で続けたい場合は、ドキュメントをローカルマシンにダウンロードできます。 Kiro Web から GitLab を利用する Kiro Web は GitHub に加えて GitLab に対応しました。パーソナルアクセストークンで GitLab を接続し、セッションに GitLab プロジェクトを追加して Kiro に作業を依頼します。Kiro はプロジェクトをサンドボックスにクローンし、変更を加え、皆さんに代わってマージリクエストをオープンします。依頼すればマージリクエストやイシューを確認することもできるので、セッションを離れることなく一覧表示や閲覧が可能です。 Kiro Web は当初から、1 つのセッションで複数のリポジトリにまたがる変更を調整してきました。新しいのは、それらのリポジトリが同じプロバイダー上に存在する必要がなくなった点です。1 つのセッションで GitLab と GitHub のリポジトリを混在させることができ、Kiro はそのすべてを横断的に読み取って変更を調整し、それぞれに応じて GitLab ではマージリクエストを、GitHub ではプルリクエストをオープンします。これは、ある場所の共有ライブラリと、別の場所にあるそれに依存するサービスの両方に変更が及ぶ場合に、たとえそれらのプロジェクトが異なるプロバイダー上にあっても重要になります。 最近のアップデート 公開以降、いくつかの改善も提供してきました。最初にリポジトリを接続しなくてもセッションを開始できるようになり、やりたいことを説明してから、必要に応じて後でリポジトリを追加できます。タスクの途中で Kiro を停止したり、ワークスペースの起動中に進捗を確認したり、メッセージの相対的なタイムスタンプを読んだりできます。また、表示が勝手に飛ぶことなく読んでいる位置に留まるようになったため、長時間の実行も追いやすくなりました。さらに、サンドボックスがどのネットワークモードを使用しているかをより分かりやすくし、デフォルトのサンドボックスディスクを 128 GB に増やし、小さい画面でのレイアウトを整理しました。 今すぐお試しください Kiro Web は、Kiro Pro、Pro+、Pro Max、Power の各サブスクライバー向けに app.kiro.dev でプレビュー提供中です。さらに詳しく知りたい場合は、 Specs ガイドと GitLab ガイドをご覧いただき、 Web changelog をフォローして次に何が提供されるかをチェックしてください。

本ブログは 2026 年 6 月 4 日に公開された Blog “ Amazon Cognito unlocks advanced capabilities with next-generation infrastructure ” を翻訳したものです。 Amazon Cognito は最近、3 つの強化を導入しました。要求の厳しいワークロードに対応する高スループットパフォーマンス、保管時のデータ暗号化を完全に制御できるカスタマーマネージドキー、そして事業継続性を向上させるマルチリージョンレプリケーションです。これらの機能は、拡張性とスケールを考慮して設計された次世代のストレージインフラストラクチャによって実現されています。これらの強化をお客様に提供するにあたり、数億件のユーザープロファイルを移行しましたが、おそらくお気づきになることはなかったはずです。本投稿では、新機能の概要、その背後にあるアーキテクチャ、そしてお客様のアプリケーションを稼働させたままゼロダウンタイムで実現した移行について解説します。 Cognito で利用可能になった新機能 新しいインフラストラクチャへの移行は、単に既存の機能を維持するためだけのものではありませんでした。それは、Amazon Cognito の継続的な改善を可能にしつつ、お客様の課題を解決する機能を提供するための基盤を構築するものでした。 高スループットなパフォーマンス : 新しいアーキテクチャは、モダンなアプリケーションが要求するより高いリクエスト量とスケール要件をサポートしながら、アプリケーションが依存する低レイテンシのパフォーマンスを維持します。これにより、1 つのユーザープールあたり数千万人のユーザーと、1 秒あたり数千トランザクション (TPS) をサポートできます。 カスタマーマネージドキー : お客様は、保管時のデータの暗号化に、 AWS Key Management Service (AWS KMS) に保存された独自の暗号化キーを使用できるようになりました。これにより、セキュリティ制御と機能が強化され、お客様は暗号化キーのライフサイクルを完全に管理できます。 マルチリージョンレプリケーション : お客様は、ユーザーのパスワード、属性、設定を含むユーザープール全体のデータを、選択した別のリージョンの別のユーザープールに同期できるようになりました。これにより、お客様は事業継続計画 (BCP) を実装し、リージョンのフェイルオーバーが発生した場合でも認証の可用性を維持できます。予期しない障害が発生した場合でも、アプリケーションをユーザーが利用し続けられるようサポートします。 イノベーションのためのアーキテクチャ 新しいアーキテクチャでは、ID 操作の拡張性とスケーラビリティを目的として設計された専用のストレージレイヤーを使用しています。新しいアーキテクチャは、以下の設計理念を中心に据えて構築しました。 アイデンティティファーストの設計 : ストレージレイヤーがユーザー ID を理解します。クライアント固有のビジネスロジックは存在せず、ID 管理を超えた一般化も行いません。これにより、システムは焦点を絞り、ポータブルで最適化された状態を保ちます。 後戻りできない選択を避ける : アーキテクチャの選択を後から変更可能な状態に保ちながら、価値を段階的に提供します。これにより、新たなニーズが生じた際に進化できます。 後方互換性 : 基盤となるインフラストラクチャへの変更が、お客様のアプリケーションの動作を決して損なわないようにします。 これらの理念が、すべてのアーキテクチャ上の意思決定を形作りました。このアーキテクチャは、独立してデプロイ可能なドメインに分割されています。以前は、 Amazon Cloud Directory を使用していたため、サービスアーキテクチャはすべての顧客情報を永続化するために単一のデータストアに依存していました。これにより、シンプルなデータ走査が可能になりましたが、新機能が必要になった際にデータベーススキーマを調整するには複数サービス間の調整が必要でした。新しいアーキテクチャでは異なるデータセットを使用しており、それぞれが独立して進化できるため、より迅速な機能の反復改善が可能になります。 ゼロダウンタイムでの移行 ユーザーの移行には細心の注意が求められ、すべてのステップでダウンタイムゼロを維持し、データの整合性を確保するために設計された戦略が必要です。私たちのアプローチでは、次の施策を通じて、即時の安定性と長期的な柔軟性の両方を優先しています。 シャドウモード検証 : 顧客の API リクエストを新旧両方のインフラストラクチャに同時に流し、レスポンス構造、ステータスコード、動作特性を比較しました。この検証は、比較中に機密情報が平文で公開されることが決してないように設計されています。たとえば、システム間でタイムスタンプがわずかに異なる場合があるといった既知の差異を考慮し、意味のある不一致のみが対処すべきアラートとして表面化するようにしました。 データバックフィル: ユーザープールを新しいインフラストラクチャに切り替える前に、レガシーシステムから既存のすべてのユーザーレコードを新しいストレージへ一括投入（バックフィル）しました。この反映は本番トラフィックの裏側で並行して実行され、後述のデュアルライトによってバックフィル期間中に行われた変更を取り込み、データの損失や古いデータの参照が発生しないようにしました。シャドウモードはバックフィルの検証レイヤーとして機能しました。データ同期におけるエッジケースへの対応を進めるにつれてシャドウモードの一致率が上昇し、切り替えに進む前にデータの完全性を確認できました。 デュアルライトアーキテクチャ : すべての ID 操作をレガシーサービスと新サービスの両方に同時に書き込むシステムを実装し、整合性を確保するための包括的な検証を行いました。新しいインフラストラクチャへのデュアルライトが失敗した場合でも、操作はレガシーシステムで引き続き成功し、顧客が開始したすべてのリクエストが保持されます。これはつまり、デュアルライトの失敗は内部的な整合性の問題として封じ込められ、顧客に影響を与えなかったということです。 アンチエントロピー検証 : 新旧のインフラストラクチャ間でレコードを継続的に比較し、データの乖離を検出して解決するデータ検証および修正システムを実装しました。アンチエントロピースキャンでは、ユーザー属性、認証情報のハッシュ、グループメンバーシップ、設定などのレコードを比較しました。真の不一致が見つかった場合、システムはレガシーシステムを信頼できる情報源 (source of truth) として使用し、自動的にそれらを調整しました。このレイヤーは、シャドウモードとデュアルライトだけではカバーできないエッジケースを捕捉できました。 ロールバック機能を備えた段階的ロールアウト : 即時ロールバック機能を備えた、制御されたデプロイフェーズを確立しました。ユーザープールを新しいインフラストラクチャに切り替えた後も、すべての書き込みをレガシーシステムへ複製し続け、データの損失なしにいつでもユーザープールをレガシーインフラストラクチャに戻せるようにしました。移行中にロールバックが必要になった場合、オーケストレーターがタイムスタンプ順にエントリを再適用し、ユーザープロファイルをレガシーシステムに同期し直しました。 インフラストラクチャモダナイゼーションから得られた教訓 このモダナイゼーションを通じて、私たちはあらゆる大規模インフラストラクチャプロジェクトに適用できる貴重な原則を学びました。そのため、皆様が同様の移行を実施する際の参考になるよう、これらの学びを共有することにしました。 顧客のアクセスパターンがアーキテクチャの意思決定を左右する : 実際の顧客のアクセスパターンを分析した結果、ID ワークロードは予測可能なパターンに従うことが明らかになりました。これは、完全性と運用のシンプルさのバランスを取った同期型のデュアルライトアプローチを採用できることを意味していました。この原則は、あらゆるドメイン固有の移行に適用できます。汎用的なソリューションに手を伸ばす前に、ワークロードの実際のアクセスパターンを理解しましょう。 動作の保持には従来のテストを超えた技術が必要 : 新旧のシステム間で同等の機能を確保することは簡単でした。しかし、まったく同じ API の動作を保持することは簡単ではありませんでした。機能テストは意図された動作を検証しますが、特定の API の動作を前提に顧客がアプリケーションを構築しているシナリオを特定しました。そのような場合、変更によって顧客のアプリケーションが気づかないうちに壊れてしまう可能性がありました。たとえば、同じユーザーへの同時書き込みが、新旧のシステム間で最終的に異なる状態に収束する可能性があります。書き込みはすべて成功しますが、結果がわずかに異なるのです。同様に、属性を書き込んだ直後にそれを読み取る顧客は、整合性ウィンドウの影響を受けます。更新が反映されるタイミングのわずかな違いが、古いデータの読み取りを引き起こす可能性があります。これらは機能的な障害ではありませんが、実際のトラフィックパターンにおける動作は変化する可能性があります。シャドウモードでの検証により、自動テストだけでは見逃していたエッジケースが浮き彫りになりました。これらの技術には早期に投資しましょう。 段階的な検証は、テストだけでは得られない信頼性を築く : それぞれが異なるアクセスパターンをカバーする複数の独立した検証技術（シャドウモード、デュアルライト、アンチエントロピースキャンなど）を、組み合わせて適用しましょう。単一のアプローチですべてを検出できることはなく、それらの間の隙間こそが本番環境の問題が潜む場所です。即時ロールバック機能を備えた段階的なロールアウトにより、各ステップを検証しながら、迅速に元の状態に戻す能力を維持できます。 ご自身のモダナイゼーションプロジェクトで押さえるべき主要原則 : 目的に特化したソリューションに投資し、拡張性を考慮した設計を行い、段階的な検証を実装しましょう。あるいは、マネージドサービスを利用すれば、アプリケーションを稼働させ続けながら、手間をかけることなくインフラストラクチャが改善され、ビジネスニーズに集中できるようになります。 まとめ 本投稿では、最新の ID 管理機能の基盤を構築する Amazon Cognito のインフラストラクチャモダナイゼーションから得られた全体的なアプローチと学びを共有しました。新しい Cognito インフラストラクチャはすでに稼働しており、カスタマーマネージドキーやマルチリージョンレプリケーションといった機能を提供しています。移行が進むにつれて、すべての Cognito のお客様は、現在ご利用中のものと同じサービス上で、特別な操作を必要とすることなくこれらの機能を利用できるようになります。 認証インフラストラクチャをモダナイズする準備はできましたか？詳細については、 Amazon Cognito をご覧ください。   Howie Li Howie は Amazon Web Services のプロダクトマネージャーで、認証をデフォルトで簡単にすることに取り組んでいます。仕事以外では、旅行を通じて文化や食を探求したり、それらにインスパイアされた新しいアイスクリームのフレーバーを考案したりすることを楽しんでいます。 Georgi Baghdasaryan Georgi は Amazon Web Services のプリンシパルエンジニアであり、組織が大規模にアクセスと認証を安全に管理できるよう支援するアイデンティティシステムを構築しています。彼のより広範な関心は、お客様がクラウドで安心して運用できるようにする、信頼性が高く影響力の大きいインフラストラクチャにあります。仕事以外では、新しい抹茶ラテのレシピを試したり、長距離のサイクリングを楽しんだりしています。 本ブログは Solutions Architect の松井 僚太郎が翻訳しました。

AWS は 2026 年 4 月 18 日 – 22 日にラスベガスで開催された世界最大の放送機器展「NAB Show 2026」に出展し、 30 を超えるデモを展示 しました。全デモの 83% に AI が組み込まれ、 そのうちの半分の展示に AI エージェントが採用されるなど、さまざまなメディアワークフローに AI が組み込まれていました。 AWSメディアセミナーでは、NAB Show に参加したソリューションアーキテクトの井村紀彦と小南英司が登壇し、AWS ブース展示の中から注目度の高いトピックを厳選してご紹介しました。 本セミナーは AWS Black Belt Online Seminar シリーズ として資料を公開しています。 NAB Show 2026 recap メディア & エンターテインメント業界編 [ 資料 ][ 動画 ] Multiplatform Distribution — クラウド × IP × AI でライブ配信を再定義 MXL（Media eXchange Layer）— 11 社相互運用で業界標準が現実に 本エリアで最もインパクトが大きかったのが MXL v1.0 の正式リリースです。非圧縮メディアを超低遅延で交換するクラウド共通規格が存在しなかったために、これまでのライブ制作では環境がベンダーロックインされてしまったり複雑なインテグレーションを自前で行う必要があったりと困難が生じていました。NAB Show のデモでは、 Amazon EC2 上の共有メモリと EFA RDMA を活用し、11 社が映像や音声、メタデータを放送品質で相互に共有しました。多くの製品間で相互運用性が成立することを示した点が画期的です。 3つの AI エージェントでライブ配信障害を End-to-End で診断 ライブ配信の障害特定はこれまで時間と専門知識を要する課題で、視聴者から「映像が止まった」との問い合わせが来た際に、エンコーダーや途中経路、CDN などのどこが原因なのか、切り分けに多大な時間を要していました。会場で常に人だかりができていたこのデモでは、 Amazon Bedrock AgentCore と Strands SDK で実装した 1 つの Supervisor と 3 つのサブエージェントが、MCP（Model Context Protocol）を介して各データソースを統一的に分析します。本デモはこれらのバックエンドを 2 つの UI から利用できる点も特徴的で、非技術者向けの AI アシスタント Amazon Quick と技術者がトラブルシューティングやデプロイを行う AI IDE の Kiro を、利用者のスキルに応じて入口を選べます。実装サンプルは GitHubで公開 されており、任意の AWS アカウントへのデプロイが可能です。 その他の注目展示 AWS Elemental MediaConnect Router は、SDI マトリクスや IP ルーターを使わずにクラウド上でライブ映像フィードのルーティングや切替を API 経由で制御することが可能な AWS サービスです。TAMS（Time-addressable Media Store）は BBC が開発をしたオープンソースプロジェクトで、 Amazon S3 上に保存したライブ素材を TAMS 対応ソリューションを介して追っかけ編集したりプレビューしたりすることを紹介しました。また、AI ブランドセーフティのデモでは Amazon Bedrock と Amazon Rekognition 、 Amazon Transcribe でライブニュース映像をリアルタイムにカテゴリ分析して、適合した広告のみを配信する仕組みを展示しました。 Content Creation — コンテンツ制作 AWS Elemental Inference — 複数デモで存在感を示した今年最大の注目サービス AWS Elemental Inference は、AWS 初のライブ映像向け AI サービスで、追加の制作チームや特別な AI 専門知識を準備することなく、リアルタイムに縦型フォーマットに自動変換し重要シーンのハイライトクリップを自動抽出可能です。 AWS Elemental MediaLive や AWS Elemental MediaConvert と統合されており、既存ワークフローにそのまま組み込めます。Fox Sports での採用も発表されています。 その他の展示 Kiro を用いて Adobe Premiere Pro のネイティブプラグインを半日で開発するデモや、ComfyUI を Amazon EKS 上でコンテナ化することで GPU 環境を安価に実現する AI クリエイティブ環境、 AWS Deadline Cloud による最大 85% コスト削減のレンダリング最適化、Avid Content Core によるクラウド MAM 環境なども展示されました。 Media Lifecycle Management — アーカイブを収益源へ 本テーマは「アーカイブをコストセンターから収益源へ」で、メタデータの自動付与やメタレス検索などの検索の高度化、コンプライアンスや契約のチェックを行う利用可否の判定、多言語翻訳やニュース自動編集を行う作業の自動化の 3 軸で展示が行われました。 AI エージェントによるコンテンツ審査・契約書チェックの自動化 利用可否の判定で多くの来場者の注目を集めていた展示はコンテンツ審査の自動化です。 Amazon Nova で映像全体を分析してレーティングとモデレーションフラグを検出し、Amazon Bedrock Agents で権利検証とメタデータ品質管理を自動化することで、審査サイクルを大幅に短縮し、コンプライアンス基準への一貫した準拠を実現します。また契約書の構造化も多くの来場者を集める展示でした。膨大な PDF に埋もれた権利契約やライセンス、人材契約を、25 種のAI エージェントが分析し、 Amazon OpenSearch Service で検索可能なメタデータに変換します。これにより数十年分の契約を数秒で検索でき、権利判断の意思決定を大幅に加速することが可能です。 その他の展示 検索の高度化では Media2Cloud によるフレームレベル動画分析と、 MediaLake による自然言語によるマルチモーダル検索が展示されました。どちらもオープンソースで公開されており、すぐにデプロイ可能です。作業の自動化では Amazon Bedrock などを用いた 20 言語以上の字幕や吹替自動化が展示されました。 Revenue Generation — 収益の創出 本エリアでは、AI を用いることで中小企業が数分でテレビ広告を自動生成するデモ、広告エージェントによるメディアプラン立案の短縮、ライブスポーツ配信における文脈判断による広告挿入などが展示されました。 Builder Zone 製品開発チームによる高度な技術ディスカッションエリア「 Builder Zone」では、AWS Elemental Inference による縦型動画やハイライト自動生成、 AWS Elemental MediaConnect によるライブ配信品質監視（MQAR）と自動フェイルオーバー、AWS Elemental MediaConnect Router によるクラウドネイティブ映像ルーティング、 Amazon CloudFront の CBOR Web Token (CWT)/Common Access Token (CAT) によるミリ秒以下の認証トークンの展示がありました。 おわりに 本ブログでは、NAB Show 2026 の AWS のブース展示を 4 つのテーマで振り返りました。今年の展示が示した方向性は、(1) AI がリアルタイムを制す (2) IP × クラウドでソフトウェア化を加速 (3) アーカイブが”動く資産”になる (4) コンテンツ制作の民主化でした。セミナーにご参加いただいた皆さま、ありがとうございました。メディアチームでは、業界の皆様に役立つ情報を引き続きセミナーやブログで発信してまいります。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

本記事は「 Introducing the Kiro merch store 」を翻訳したものです。 2026 年 6 月 15 日、Kiro 公式グッズストアを shop.kiro.dev にてオープンしました。これまで Kiro を使って最高の仕事を生み出してきた皆さんが、今度はそれを身にまとえるようになりました。 Kiro コミュニティは、オープンに発展し、プロジェクトを共有し、ハッカソンに参加し、ワークショップに加わるなど、さまざまな活動を続けてきました。このたび Kiro グッズをお届けできることを、私たちは大変うれしく思っています。コミュニティの選択肢がさらに広がり、カンファレンス会場の向こうに別の Kiro ユーザーを見つけたり、お気に入りの Kiro グッズを身につけてハッカソンに参加したり、ラバーダック（アヒルのおもちゃ）の代わりに Kiro のぬいぐるみを使ってデバッグするような、そんな楽しみが生まれます。 コレクションの内容 まずはアパレル、小物、アクセサリーにわたる 15 アイテムからスタートします。 アパレル : ヘビーウェイトのパーカー、T シャツ、キャップやニット帽、さらにはローカットスニーカーまで。Kiro のゴーストがあしらわれた、普段使いにぴったりのアイテムがそろっています。 Kiro コレクションのアパレルアイテムの一例 小物 : ウォーターボトル、メカニカルキーボードのキーキャップ、そして長時間の開発に寄り添う Kiro ゴーストのぬいぐるみなど、実用的な定番アイテムから選べます。 Kiro コレクションの小物アイテムの一例 アクセサリー : 仕上げのひと品として、ラップトップ収納付きのロールトップバックパック、エナメルピン、そして持ち物を彩るさまざまなステッカーをご用意しました。 Kiro コレクションのアクセサリーアイテムの一例 意図を込めたデザイン 質の高いアウトプットは、質の高い意図から生まれると私たちはそう考えています。デザインにも同じ基準を適用し、すべての要素を Kiro のブランド、開発者文化、そして一貫したルックアンドフィールへとさかのぼって紐づけています。これらのアイテムは、Kiroの存在感をさりげなく演出してくれるので、単に「好きだから」という理由で身につけたり使ったりしても、まるで歩く広告塔のような気分になることはありません。 これをしっかり実現するには、細部へのこだわりが欠かせませんでした。たとえば、1 か月で表面がテカってしまわない本物の PBT 製キーキャップ、長時間の着用でも快適で、もたつかずに重ね着できるヘビーウェイトのパーカーと T シャツ、そしてすばやく取り出せる専用サイドジッパー付きの 16 インチラップトップ収納などです。 グッズを通じてブランドに命を吹き込み、世界中の開発者にとって Kiro コミュニティをより身近なものにできることを、私たちはとてもうれしく思っています。これほど開発者に寄り添ったものを作り上げる経験は、非常にやりがいのあるものでした。Kiro ストアは、開発者同士がつながり、ブランドの一員だと感じられる場を生み出しています。— Elie Bess, Canary Marketing ストアを立ち上げること自体が、一大プロジェクトでした。いくつかの定番アイテムから、コミュニティに開かれた本格的なストアフロントへと仕上げるには、厳格な品質チェック、物流体制の構築とスケーリング、そして直感的で公式感のあるストア UI への改善の繰り返しが必要でした。今回は v1 であり、今後も磨きをかけ、新しいアイテムを投入し、皆さんのフィードバックをもとに改善を続けていきます。 カートに追加する準備はできましたか？ Kiro コレクションの全ラインナップは、 shop.kiro.dev にて今すぐご覧いただけます。じっくり見て回り、ぴったりのサイズを見つけて、あなたのセットアップに最も合うアイテムを手に入れてください。購入したら、X・LinkedIn・Instagram では @kirodotdev を、Bluesky では @kiro.dev をタグ付けし、#BuildWithKiro を付けて投稿してください。皆さんが選んだアイテムを、ぜひ見せてください。

こんにちは。広告・マーケティング業界を担当するソリューションアーキテクトチームです。いよいよ 6 月 25 日 (木)、26 日 (金) の 2 日間、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されます。基調講演や数多くの事例セッションとともに、AWS Expo のエリアでは AWS サービス・ソリューションの最新活用事例や、実際に AWS に触れられるデモを、さまざまな角度から体験いただけます。 その AWS Expo エリア内には、製造、金融、自動車、そして私たちの担当する広告・マーケティングなど、業界別に特化したソリューションをご紹介する AWS Industries Zone が設けられます。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決の方法をご覧いただける場です。業界に精通したエキスパートと、具体的な活用シナリオについてじっくりご相談いただけるスペースもご用意しています。私たち広告・マーケティング業界担当チームも、このゾーンに今年ならではのテーマで展示を出展します。本ブログでは、その展示内容を一足先にご紹介します。まだ登録がお済みでない方は、ぜひ下記のリンクから。 登録はこちら AWS 展示 A033：行動ログと AI による次世代パーソナライズ —  購買データだけでなく「顧客の迷い」を資産に、自律型顧客体験の実現へ 購買データという「結果」だけに頼ってパーソナライズしていませんか？閲覧、比較、カート放棄など、購入に至らなかった「顧客の迷い」にこそ本音が隠れています。この行動データを全量収集し資産化することで、顧客の真のニーズを捉えられます。本展示では、行動データの自社資産化基盤と、Agentic AI が最適なコンテンツ・タイミングを自律的に判断して届ける次世代の仕組みをご紹介します。 A035：すべての仮説を AI ペルソナで試す時代へ —  ふと浮かんだアイデアを、自社データで即検証 「この層はどう反応するだろう？」ふと浮かんだ仮説をコストや時間を理由に諦めていませんか？本ソリューションは自社の購買・顧客データから AI ペルソナを生成し、思いついたアイデアをその場で検証できます。試して、直して、また試す——このサイクルが数分で回るから、今まで捨てていた “小さな思いつき” すべてをぶつけられます。カスタムプロンプトで検証シナリオも自在に調整でき、ブースで実際にお試しいただけます。ソリューションのコードは aws-samples（GitHub） で公開中 です。 お客様展示 A034：株式会社電通, 株式会社電通デジタル — AI Agent を活用した広告効果分析の効率化 電通/電通デジタルのマーケティング領域における知見をもとに生まれた新たなエージェントサービスは、広告活動に関わる分析・検証業務を対話形式で支援します。広告データ活用において、課題整理から分析実行、結果の取りまとめまでを自然言語で支援することで、専門的知識や個別担当者への依存を抑え、業務効率化と意思決定の高度化に貢献します。AWS を活用した柔軟なエージェントシステムで広告業務全体を横断的に補助し、より多くの方が直感的に高度な判断を行える環境の実現を目指します。 A036：株式会社NTTドコモ — AI エージェント「SyncMe」の基盤に AWS を活用 あなただけのパーソナル AI エージェント 「SyncMe」 は、ユーザーひとりひとりに合わせた体験を提供するために、マルチエージェントアーキテクチャと独自の記憶管理を組み合わせています。本展示では、パーソナライズを行うため「d アカウント情報に基づいたパーソナライズ」と「エージェントとの会話を重ねることによって育まれるパーソナライズ」の 2 点の取り組みが、どのような工夫で実現されているかご紹介します。 あわせて聴きたい — 関連セッションのご紹介 ブース展示をご覧いただいたあとは、ぜひ関連セッションにも足をお運びください。広告・マーケティング業務に直結するセッション、AI エージェントやデータ分析の最新動向まで、いくつかピックアップしてご紹介します。 広告・マーケティング × AI AIM202｜あなたの新しいエージェンティックなチームメイト、Amazon Quick を知ろう （6/25 木 11:30–12:10） 私たちの多くは、情報を活用するよりも探すことに多くの時間を費やしています。Amazon Quick はそれを変えます。ドキュメント、データベース、メール、Slack のスレッド、ダッシュボード、Jira チケットなど、社内のあらゆるデータに横断的にアクセスし、検索、質問、そしてアクションの実行までを一つの場所で完結させます。Web、モバイル、Slack、Microsoft の各種ツールに対応し、マルチモデル AI を搭載。コンシューマー向けの使いやすさと、エンタープライズレベルのセキュリティおよびガバナンスを両立しています。ベンダーロックインも、ツールごとに分断されたコパイロットもありません。あなたがどこで働いていても、一緒に働いてくれる、たった一つの AI チームメイトです。 ANT310｜AWS Analytics MCP サーバーで実現するエージェント型データエンジニアリング （6/25 木 16:30–17:10） 本セッションでは、AWS Analytics Model Context Protocol (MCP) サーバーをご紹介します。Data Processing MCP Server と Amazon Redshift MCP Server を含むこれらのオープンソースツールにより、AWS Glue、Amazon EMR、Amazon Athena、Amazon Redshift を横断するエージェント型ワークフローが実現できます。AIエージェントとの自然言語による対話を通じて、複雑な分析オペレーションをどのように簡素化できるかをご説明します。MCPサーバーの実装戦略、実際のユースケース、デプロイメントのためのアーキテクチャパターン、そしてアナリティクス環境を理解し統制するインテリジェントなデータエンジニアリングワークフローを構築するための本番環境でのベストプラクティスを取り上げます。 AIM343｜生成 AI で「売れる製品」を作る — POC 止まりを突破する 6 つのプロダクトデザイン戦略 （6/26 金 13:00–13:40） 生成 AI への投資額は世界で急拡大し、2029 年には約 18 兆円規模に達すると予測されています。しかし現実には、AI プロジェクトの多くが POC から本番導入に至らず廃止されており、「技術は動くが、売上にはつながらない」という課題に多くの ISV が直面しています。本セッションでは、この「POC の壁」を突破し、生成 AI を持続的な収益成長エンジンに変えるための 6 つの AI プロダクトデザイン戦略を体系的に解説します。テクノロジードリブンではなくバリュードリブンで「ゴールから逆算」するアプローチを軸に、実際に収益化に成功した ISV の具体的な設計手法をご紹介します。 MAM241 ｜ 「統制された自由」の実現 －電通グループ 140 社を支える AI 時代の IT ガバナンス（6/26 木 14:30–15:00） 生成 AI 時代に拡大するクラウド投資とリスクをどう統制するか。電通グループが AWS のエコシステムで実践する、統制と自由を両立するグループ IT ガバナンスの具体例をご紹介します。 AI エージェント全般 AIM201｜本番展開を見据えて：エージェンティック AI に対する実践的アプローチ （6/25 木 11:30–12:10） AI 実証実験の 46 % は本番に届かず消滅する – 同じ経験をされた方も多いのではないでしょうか。本セッションでは、プロトタイプの壁を突破するために必要な 4 つの柱「運用」「データ」「信頼性」「堅牢性」を、これまで AWS が多くのお客様支援から得たナレッジをもとに体系的に解説します。既存サービスの活用判断から、オブザーバビリティ、データ整備、セキュリティ設計、評価の自動化まで、エージェントの価値を最大化するための近道をお伝えします。 AIM216｜エージェンティック AI におけるビジネスインテリジェンスの再構築と民主化 （6/25 木 12:30–13:10） ビジネスインテリジェンス（ BI ）は、AI の進化とともに大きな転換期を迎えています。構造化・非構造化データの統合活用、ワークフロー自動化が進む一方、エンタープライズ環境ではデータサイロや管理コストといった課題が依然として残っています。本セッションではエージェンティック AI を活用した Amazon Quick による BI の再構築について解説します。Amazon 社内での活用を一例として交えながら、誰もがデータから価値を引き出せる環境の実現に向けた具体的なアプローチをご紹介します。参加者は、自社の BI 戦略にエージェンティック AI を取り入れるためのヒントをお持ち帰りいただけます データ分析基盤 ANT209｜データウェアハウスのモダナイズ – 事例とデモで学ぶ Amazon Redshift マルチウェアハウスアーキテクチャ （6/25 木 15:30–16:10） 「ETL が走ると BI が遅くなる」「生成 AI ワークロードを追加したいがリソースが足りない」といった悩みを抱えていませんか？その課題、マルチウェアハウスアーキテクチャで解決することができます。エンタープライズ分析プラットフォームは、集中型で過負荷状態のデータウェアハウスから、分散型でガバナンスが効いた、生成 AI 対応のマルチウェアハウスアーキテクチャへと進化しています。データをコピーする必要もありません。本セッションでは、ビジネスニーズに応じてスケールするデータウェアハウスアーキテクチャの設計方法を学びます。モノリシックな Amazon Redshift クラスターから最新のマルチウェアハウスアーキテクチャへのモダナイゼーションを実事例で紹介し、ETL・BI・生成 AI それぞれを干渉なく動かすデモを通じて、具体的な実現ステップをお持ち帰りいただけます。 まとめ 広告・マーケティングブースでは、AWS 展示 2 つ、お客様展示 2 つの合計 4 ブースで皆さまをお待ちしています。行動ログ × Agentic AI による自律型パーソナライズ、AI ペルソナによる高速仮説検証、そして株式会社電通, 株式会社電通デジタル様・株式会社NTTドコモ様による最先端のお客様事例を学ぶことができます。ぜひエキスパートと直接お話しください。皆さまのご来場を心よりお待ちしております。 AWS Summit Japan 2026 への登録はこちら 著者について 小川　翔 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売業界のお客様を中心にクラウド活用の技術支援を行っています。好きな AWS サービスは Amazon Bedrock と、Amazon Personalize です。

本記事は 2026 年 6 月 11 日に公開された Ranjith Ramakrishnan, Dragos Ilinca による “ Introducing Kiro Pro Max ($100/mo): more credits, less guesswork ” を翻訳したものです。 Kiro の 料金プラン は、お客様の多様なニーズと利用実態にお応えできるよう、一貫した思想のもとで設計されてきました。無料プランでは定評あるオープンウェイトモデルを使って気軽にお試しいただくことができ、月額 $20 の Pro プランは軽量なワークフローに対応しています。月額 $40 の Pro+ プランは Kiro を日常的にご活用いただく開発者に適しており、月額 $200 の Power プランは大規模なワークロードに対応しています。しかしながら、多くのお客様から、$40 と $200 の間には大きなギャップがあるとのフィードバックを頂戴しておりました。Pro+ のクレジット上限に達した場合でも、超過利用を有効化することで作業を継続することは既に可能でしたが、超過利用は予測が難しく、費用がかさんでしまうという課題がありました。 Kiro Pro Max: 月額 $100 このギャップを解消する新しいプランとして「Kiro Pro Max」をご紹介します。本プランの主な内容は以下の通りです。 月 5,000 クレジット : Kiro を 1 日数時間以上ご利用いただくプロフェッショナルな開発者向けに設計 全プレミアムモデルへのアクセス : Claude Opus 4.8、Sonnet 4.6、Auto をはじめ、モデルセレクターに含まれるすべてのモデルをご利用いただけます（地域ごとのモデル提供状況に準じます） Power プランと同等の機能セット : スペック、カスタムサブエージェント、Powers、フック、CLI への完全なアクセス 月額 $100 という価格設定は、日々の業務でエージェンティック開発を実践されるお客様にとって有力な選択肢となります。Pro+ の割り当てを常に大幅に超過されているお客様や、超過料金が $60〜70 に達してしまっているお客様にとって、Pro Max は予測可能な定額料金で大幅に余裕のあるご利用を実現します。 対象ユーザー Pro Max は、Kiro を業務の中核ツールとしてご活用いただくプロフェッショナルな開発者向けに設計されています。1 日を通じて複数のプロジェクトでコーディング、スペックの実行、機能のイテレーション、デバッグを行うようなお客様を想定しています。利用可能な最良のモデルにアクセスし、意義のある作業を進めるのに十分なクレジットを確保しつつ、月次支出を明確に管理されたいお客様に最適な選択肢です。 アップグレード方法 6 月 11 日より、アカウント設定画面から Pro Max へ切り替えていただけます。月の途中でアップグレードされる場合、差額は日割り計算となります。日割り計算後の新しいクレジット割り当ては、ただちに有効となります。Kiro を新たにご利用開始されるお客様は、他のすべてのプランと同様に、 $20 のサインアップボーナスクレジット を Kiro Pro Max サブスクリプションにご適用いただけます。 画一的ではなく、柔軟性とコントロールを 無料プランから Power プランまで、Kiro は様々な利用レベルのお客様に対応するサブスクリプションをご提供しております。週末に個人プロジェクトを開発される場合も、1 日 8 時間プロダクションコードを書き続けられる場合も、すべてのお客様に Kiro を最大限ご活用いただけるよう取り組んでいます。優れた開発者体験には柔軟性とコントロールが不可欠であり、料金プランはお客様の実際の作業スタイルに即したものであるべきです。過小あるいは過大なプランをお客様に強いるものであってはなりません。 ぜひこの機会に Kiro をお試しいただく か、 プランのアップグレード をご検討ください。 翻訳は Solutions Architect の吉村が担当いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 いよいよ AWS Summit Japan 2026 が 6 月 25 日（木）、26 日（金）に幕張メッセで開催されます。今週は各業界ブースの見どころを紹介するブログが続々と公開されました。AI Scientist が実験用ロボットを自律操作する創薬向けの  Self-Driving Lab 、AI エージェントが生産ラインのボトルネックを検知して改善する 製造業向けデモ 、ユナイテッドアローズ様・カインズ様の事例展示を含む 流通・小売・消費財・飲食業界向けブース など、生成 AI エージェントが業務の主役になる未来を体感できる展示が目白押しです。ぜひ事前にチェックしてみてください。 それでは、6 月 8 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS Local Executive Roadshow 名古屋編: タキヒヨー株式会社様、非エンジニアが数週間で社内システムを内製化 タキヒヨー株式会社様は、1751 年創業、270 年以上の歴史を持つ繊維・アパレル企業です。経営に必要なデータが Excel に散在し、VBA マクロでの集計に追われていたことや、需要予測データが分析できる形になっていないことが課題でした。これを解決するために、まず Amazon QuickSight でデータを一元的に可視化し、さらに非エンジニアの担当者が Amazon Bedrock 経由の Claude Code を使ってデータ整形ツールを内製開発しました。その結果、通常なら数カ月・数百万円かかるシステムを数週間で構築し、現場が意思決定業務に集中できるようになったそうです。パートナーのクラスメソッド株式会社様とともに、「まずは可視化から始める」という現実的なアプローチが語られている開催レポートです。 AWS Local Executive Roadshow 広島編: 株式会社エイチビーソフトスタジオ様、生成 AI 導入の「3 つの壁」を乗り越える 株式会社エイチビーソフトスタジオ様は、愛媛県松山市を拠点に全社員リモートで開発を手がける企業で、中小企業への生成 AI 導入支援にも取り組んでいます。支援先では、問い合わせ対応が特定の担当者に集中し回答品質にばらつきが出ることや、導入時の「期待値の壁」「ルール（ガバナンス）の壁」「データの壁」が課題でした。これを解決するために、Amazon Bedrock を活用しつつ、ハンズオンによる期待値調整、叩き台ベースでの運用ルール作り、AI に社員へインタビューさせて属人ノウハウをドキュメント化する、といった工夫を重ねました。その結果、対応時間の削減や負荷集中の緩和に加え、「完璧を待たず小さく始める」ドキュメント化の文化が根づいたそうです。 AWS Summit Japan 2026 流通・小売・消費財・飲食業界向けブースのご案内 テーマは「AI エージェントが業務の主役になる日」。「商品をつくる・届ける・売る / つながる」の 3 つの切り口で、バーチャル AI エキスパートやマルチエージェントによる製品開発、サプライチェーンの危機対応など 6 つのデモを体験できます。あわせて、株式会社ユナイテッドアローズ様の「Amazon Bedrock で実現 対話で深まる日報 AI」や、株式会社カインズ様の「AI で進化する顧客体験」といったお客様の事例展示も予定されています。 AWS Summit Japan 2026 製造業ブース「生産ラインの未来」のご案内 AI エージェントが生産ラインのボトルネックを検知し、改善までを一気通貫で支援するデモを紹介しています。需要の増加を検知して影響を分析し、ボトルネックの特定から工程設計書を参照した改善提案、PLC プログラムの改修案づくり、シミュレーション環境での事前検証までを、エージェントとの会話で体験できます。Amazon Neptune や AWS IoT SiteWise、Amazon Bedrock AgentCore などを活用した構成です。 フィジカル AI で創薬が変わる Self-Driving Lab のご紹介（ヘルスケア・ライフサイエンスブース） AWS 上の AI Scientist が実験用ロボットを直接操作し、設計・実行・分析（DMTA サイクル）を 24 時間自律的に回す「Self-Driving Lab」のデモを紹介しています。会場では、3 色の原液の配合比率を AI が自律的に突き止める実演が行われます。アッセイ条件の最適化や製剤処方の設計などにも応用でき、創薬研究の加速が期待できる内容です。 ブログ記事「 AWS、初の一般提供版 Mythos クラスモデルとなる Claude Fable 5 を発表 」を公開 Anthropic の最上位クラス「Mythos」レベルの機能を、強力なセーフガードを組み込んだうえで一般提供する Claude Fable 5 が発表されました。長時間の非同期実行や高度なビジョン機能、成果物を提供する前に自ら結果を検証する能力が特徴で、評価されたほぼすべてのベンチマークで最先端の性能を示すモデルです。Amazon Bedrock と Claude Platform on AWS の 2 つの方法でアクセスできます。なお本記事には 6 月 12 日付の更新があり、米国政府の輸出管理指令への準拠のため、Anthropic の要請により現在 Claude Fable 5 および Claude Mythos 5 へのアクセスは停止されています（Claude Opus 4.8 などの他モデルは影響を受けません）。ご利用前に最新の提供状況をご確認ください。 ブログ記事「 AWS FinOps Agent のパブリックプレビュー提供開始のお知らせ 」を公開 コスト管理を継続的な運用へと進化させるエージェント型 AI ソリューション AWS FinOps Agent がパブリックプレビューになりました。この記事では、コスト異常を AWS CloudTrail のイベントと関連付けて根本原因と責任者を特定し、Jira チケットや Slack に調査結果を届ける仕組みや、エンジニアが「なぜ先月コストが上がったのか」を自然言語で質問できる機能を紹介しています。Workday 様や Mitre 10 様など初期のお客様の声も掲載されています。月次レビューに追われている FinOps チームの方は必見です。 ブログ記事「 AWS DevOps Agent によるネットワークインシデント対応の自動化 」を公開 この記事では、Amazon CloudWatch のアラートを Webhook で受け取った AWS DevOps Agent が、メトリクス・ログ・ネットワークフロー・API 変更履歴を相関分析し、根本原因と修復プランを提示する方法を紹介しています。セキュリティグループの設定ミスや NAT Gateway のルート削除など、すぐに試せる 4 つのシナリオと、複数アカウントにまたがる Transit Gateway の事例を CloudFormation テンプレート付きで解説しています。手動で 1 時間かかっていた切り分けを数分に短縮できる様子は一読の価値ありです。 ブログ記事「 Amazon Bedrock AgentCore でマルチテナントエージェントを構築する 」を公開 SaaS プロバイダーがエージェント型アプリケーションを本番運用するには、テナント分離やコスト配分、セキュリティといった固有の課題に向き合う必要があります。本記事はシリーズ第 1 回として、Amazon Bedrock AgentCore を使ったサイロ・プール・ブリッジの 3 つの分離パターンと、ランタイム分離・トークン伝播・メモリ階層・ガードレールなど 10 個の設計コンポーネントを体系的に整理しています。マルチテナント SaaS でエージェントを設計する際の見取り図として参考にして頂けるのではないでしょうか。 ブログ記事「 Anthropic / OpenAI 互換 API 向けに最適化された Amazon Bedrock の新しいコンソールエクスペリエンス 」を公開 この記事では、最新の GPT・Claude・オープンウェイトモデルに対応する Amazon Bedrock の次世代推論基盤と、その新しいコンソール体験を紹介しています。最大 3 モデルを比較できるモデルカード、プロジェクト単位での作業、プロジェクト変数を自動で埋め込むライブドキュメントなどにより、モデルの発見から本番移行までをスムーズに行えます。Claude Code や Cline、Cursor などの AI コーディングエージェントとの接続手順も紹介されています。 ブログ記事「 キャパシティ対応推論: SageMaker AI エンドポイントにおけるインスタンスの自動フォールバック 」を公開 GPU キャパシティ不足でエンドポイントの作成や Auto Scaling が失敗する、という悩みを解消する Amazon SageMaker AI の新機能「キャパシティ対応インスタンスプール」を紹介する記事です。優先順位を付けたインスタンスタイプのリストを定義しておくと、キャパシティ制約時に SageMaker AI が自動でリストを順に試し、利用可能なインフラ上にプロビジョニングしてくれます。生成 AI モデルの推論基盤を安定運用したい方におすすめの内容です。 ブログ記事「 2026 AWS Life Sciences Symposium ハイライト: 創薬研究領域 」を公開 この記事では、Sanofi 様や Roche 様、ブリストル マイヤーズ スクイブ様といったリーダーが登壇した本シンポジウムから、エージェント型 AI の創薬活用の最前線を紹介しています。目玉は 40 以上の生物学基盤モデルを備えた Amazon Bio Discovery のローンチで、メモリアル・スローン・ケタリングがん研究所の事例では、標的に対してわずか数週間で高い親和性を持つナノボディを設計した様子が語られています。エージェント型 AI が「将来の約束」ではなく本番インフラとして使われ始めていることが分かる内容です。 ブログ記事「 Kiro の Spec が速く、そしてスマートになりました 」を公開 AI を活用した IDE である Kiro の仕様駆動開発（Spec）フローに、3 つの新機能が追加されました。独立したタスクを依存関係に基づいて同時に処理する「並列タスク実行」、要件・設計・タスクを一度に生成する「Quick Plan」、そしてニューロシンボリック AI で要件の曖昧さや矛盾を設計前に検出する「要件分析」です。「構造と品質を求めると遅くなる」という前提を覆す内容で、大きな Spec の実装時間が大幅に短縮されるとのことです。 ブログ記事「 生成 AI で開発ツール操作を自動化 – Kiro × MCP Server × dSPACE ControlDesk 」を公開 自動車の ECU 開発で使われる dSPACE ControlDesk の複雑な GUI / API 操作を、AWS 上に構築した MCP サーバーと Agentic IDE「Kiro」の組み合わせで自然言語から自動化するアプローチを紹介する記事です。Amazon EC2 上の MCP サーバーが API マニュアルやサンプルコードをナレッジとして保持し、Kiro が ControlDesk を操作する Python コードを自動生成します。API 仕様を調べる時間や新メンバーのオンボーディングコストの削減に役立つ、実践的なユースケースとして参考になります。 サービスアップデート AWS、初の一般提供版 Mythos クラスモデルとなる Claude Fable 5 を発表 Anthropic の Mythos レベルの機能を一般提供する Claude Fable 5 が AWS で発表されました。金融・法務・マーケティング・エンジニアリングなどの専門業務向けに設計され、学習結果に基づいてスキルを自律的に更新し、自ら評価ハーネスを開発して成果物を検証します。Amazon Bedrock と Claude Platform on AWS の 2 つの経路でアクセスできます。なお前述のとおり、6 月 12 日以降は輸出管理指令への準拠のためアクセスが停止されているため、ご利用前に最新の提供状況をご確認ください。 Google DeepMind の Gemma 4 モデルが Amazon Bedrock で利用可能に Google DeepMind のオープンウェイトモデル Gemma 4 ファミリーが Amazon Bedrock で利用可能になりました。Gemma 4 31B、26B-A4B、E2B の 3 種類があり、組み込みの推論機能、ネイティブな Function Calling、35 以上の言語、テキスト・画像・動画・音声のマルチモーダル入力に対応します。31B は最大 256K トークンのコンテキストウィンドウを備え、推論やコーディング中心のワークロードに適しています。現在、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、欧州（フランクフルト）で利用可能です。 OpenAI の GPT-5.4 / GPT-5.5 が Amazon Bedrock の米国東部（バージニア北部）で利用可能に OpenAI の GPT-5.4 と GPT-5.5 が、Amazon Bedrock の米国東部（バージニア北部）リージョンでも利用可能になりました。GPT-5.5 は OpenAI の最も高性能なモデルで、高度なコーディングや調査・分析、長時間にわたるエージェント型タスクに向いています。両モデルとも 272K トークンのコンテキストウィンドウとテキスト・画像入力に対応し、Responses API を通じてサーバーサイド・クライアントサイド両方のツール呼び出しやレスポンスストリーミングを利用できます。 Amazon SageMaker AI が NVIDIA Nemotron モデルのサーバーレスファインチューニングに対応 Amazon SageMaker AI が、NVIDIA の 30B オープンウェイトモデル Nemotron 3 Nano のサーバーレスなモデルカスタマイズに対応しました。教師ありファインチューニング（SFT）と強化学習ファインチューニング（RFT）が利用でき、独自データでドメインに合わせた調整が行えます。サーバーレスのため、インフラのプロビジョニングや学習のオーケストレーションは SageMaker AI が処理し、使った分だけの課金でクラスター管理から解放されます。アジアパシフィック（東京）を含む 4 リージョンで利用可能です。 Amazon OpenSearch Serverless が Agentic Search をサポート Amazon OpenSearch Serverless で、自然言語でデータをクエリできる Agentic Search 機能が利用可能になりました。「800 ドル未満で東京行きのフライトを検索する」のように尋ねるだけで、システムが意図を解釈し、最適な検索戦略を計画して適切な DSL クエリを生成し、推論内容の説明とともに結果を返します。背後では LLM を搭載した QueryPlanningTool が自然言語を DSL クエリに変換します。OpenSearch Serverless が提供されているすべての商用リージョンで利用できます。 Amazon OpenSearch Service が エージェント型オブザーバビリティ向けの MCP Apps を提供開始 Amazon OpenSearch Service が MCP Apps に対応し、Claude Desktop や VS Code といった agentic IDE の中で直接オブザーバビリティのワークフローを実行できるようになりました。ローカル環境の AI エージェントが、OpenSearch や Amazon Managed Service for Prometheus に保存されたログ・トレース・メトリクス・アラートを使ってインシデントを調査できます。各ツール呼び出しはエージェント向けの要約テキストと、会話内に描画されるインタラクティブな可視化の両方を返すため、環境を離れずに結果を確認できます。 AWS で AI を活用したコスト調査機能が提供開始 AWS Cost Anomaly Detection に、Amazon Q を使って検出されたコスト異常の根本原因を分析する機能が搭載されました。これまで数時間かかることもあったコスト変化の調査が、わかりやすい言葉での説明として数分で得られます。Amazon Q がコスト変化を使用量主導型かレート主導型かを判断し、原因となったサービス・アカウント・リージョンを特定。使用量主導型の変更は AWS CloudTrail と関連付けて、特定の API コールや IAM プリンシパルに帰属させます。すべての商用リージョンで追加料金なしで利用できます。 AWS Cost Explorer で Amazon Q を活用したインテリジェントなコスト説明機能を提供開始 AWS Cost Explorer に「Amazon Q を利用して分析」機能が追加されました。ボタンを 1 回クリックするだけで、設定したレポートに対するコスト傾向・主なコスト要因・異常などの詳細な分析を受け取れます。設定したフィルターと期間はそのまま分析に引き継がれ、過去の日付には履歴の説明、将来の日付には予測の説明が提供されます。会話を通じてコンテキストが維持されるため、フォローアップの質問で深掘りも可能です。すべての商用リージョンで追加料金なしで利用できます。 Amazon Quick が Snowflake Cortex AI との統合に対応 Amazon Quick が、Model Context Protocol（MCP）を通じて Snowflake Cortex AI と統合できるようになりました。Snowflake のマネージド MCP サーバーを OAuth 認証で接続すると、Cortex Analyst を通じた構造化データへの問い合わせや、Cortex Search を通じた非構造化文書からのインサイト取得を、自然言語で実行できます。Quick の Flows で Snowflake Cortex Agents をオーケストレーションし、繰り返し可能でガバナンスの効いたワークフローを構築することも可能です。Amazon Quick が利用可能なすべての AWS リージョンで利用できます。 Kiro のアップデート Kiro CLI 2.7 が公開、/goal ループと Queue Steering を追加 AI を活用した IDE である Kiro のコマンドラインツール Kiro CLI 2.7 が公開されました。目標を達成するまで実装と自己検証を繰り返す /goal ループ、実行中のエージェントにツール境界で指示を割り込ませる Queue Steering、各ターンのツール呼び出しや変更ファイルを一覧できる強化版 /rewind が追加され、エージェントの自律性ときめ細かな制御をより両立しやすくなりました。 Kiro Web が GitLab 連携とブラウザ上での Spec 実行に対応 ブラウザで動作する Kiro Web に、2 つの機能が追加されました。要件・設計・タスクからなる Spec ワークフローをブラウザ上で実行できるようになり、GitHub に加えて GitLab にも対応しています。1 つのセッションで GitLab と GitHub のリポジトリを混在して扱い、それぞれにマージリクエストやプルリクエストを作成できるようになりました。 Kiro の新プラン「Kiro Pro Max」（月額 100 ドル）が登場 Kiro に、Pro+（月額 40 ドル）と Power（月額 200 ドル）の間を埋める新プラン Kiro Pro Max（月額 100 ドル）が追加されました。月 5,000 クレジット（Pro+ の 2.5 倍）とすべてのプレミアムモデル、Specs・カスタムサブエージェント・powers・hooks といったフル機能を利用でき、Kiro を日常的に使う開発者向けの予測可能な定額プランとなっています。 生成 AI を活用したビジネス変革に取り組むお客様を支援する 生成 AI 実用化推進プログラム は引き続き参加企業を募集しています。ご興味のある方はぜひご覧ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いよいよ AWS Summit Japan 2026 が 6月25日(木)・26日(金) の 2 日間、幕張メッセで開催されます。260 を超えるセッションと 300 以上の展示が集まる、日本最大の “AWS を学ぶイベント” です。 今回はその中から、開発者の方にぜひ立ち寄っていただきたい「Developer Community Zone」をご紹介します。ここは、開発者同士がディスカッションを楽しみ、コミュニティとのつながりを育むインタラクティブなラウンジです。サーバーレスアーキテクチャでコーヒーを淹れる名物アクティベーション 「Serverlesspresso」 を体験できるほか、コミュニティのメンバーと交流できる、Summit ならではの場になっています。 セッションや EXPO の合間に、ぜひ Developer Community Zone に足を運んで、ビルダー同士の”つながり”を体験してみてください。詳細は AWS Summit Japan 2026 公式サイト をご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年6月8日週の主要なアップデート 6/8(月) Amazon OpenSearch Serverless が Agentic Search に対応 Amazon OpenSearch Serverless に Agentic Search 機能が追加されました。自然言語でクエリを記述すると、LLM を活用した QueryPlanningTool が意図を解釈し、適切な DSL クエリを自動生成して検索を実行します。「東京行きの $800 以下の航空券を探して」のような問い合わせに対して、システムが検索戦略を計画し、推論内容のわかりやすい説明とともに結果を返します。Amazon Bedrock の Claude Haiku などの LLM を使用し、OpenSearch Dashboards または API 経由で設定できます。全ての OpenSearch Serverless 対応リージョンで利用可能です。 AWS Transform における Amazon RDS for SQL Server マイグレーションコスト評価機能の提供開始 AWS Transform で Amazon RDS for SQL Server の TCO 評価機能が利用可能になりました。AI エージェントを活用して、オンプレミス SQL Server 環境を分析し、ワークロード要件を満たす最適なデータベースインスタンスを推奨します。What-if 分析により複数のマイグレーションオプションを評価でき、BYOM (Bring Your Own Media) と License Included の両方のライセンスモデルに対応しています。Database Savings Plans を活用することでオンデマンド価格と比較して最大 20% のコスト削減が可能です。 Amazon Redshift Serverless および RG インスタンスのマニュアルスナップショットコストを削減 Amazon Redshift は、Serverless および RG (AWS Graviton ベース) インスタンスにおけるマニュアルスナップショットの課金モデルを変更しました。従来は各スナップショットの合計サイズで課金されていましたが、新モデルでは複数スナップショット間で固有のデータブロックのみを課金対象とします。これにより、複数のスナップショットを保持する顧客は大幅なコスト削減を実現できます。10TB のデータウェアハウスで 3 つのスナップショットを保持する場合、従来の 30TB 課金が 11TB に削減される計算となり、約 63% のコスト削減効果があります。この変更は 2026年6月8日 から自動的に適用されます。 AWS Application Migration Service が AWS Transform MGN に名称変更 AWS Application Migration Service (MGN) が AWS Transform MGN に名称変更されました。これは MGN が AWS Transform という agentic migration service（AI エージェント型移行サービス）の基盤となるレプリケーションエンジンとして位置付けられたことを反映しています。ユーザーは従来通り MGN コンソールで直接制御する方法と、AWS Transform のエージェンティックワークフローでディスカバリーからランディングゾーン構築、ネットワーク作成、リホストやコンテナ化までを自動化する方法の 2 つから選択できます。既存のコンプライアンス認証（FedRAMP High、HIPAA、PCI DSS、ISO、SOC 1/2/3）はすべて維持され、全商用リージョンおよび AWS GovCloud (US) で利用できます。 6/9(火) AWS Cost Explorer が Amazon Q による AI コスト分析機能を提供開始 AWS Cost Explorer に「Analyze with Amazon Q」機能が追加されました。ワンクリックで、現在表示しているコストレポートについて、コストトレンド、主要なコストドライバー、異常検知の包括的な分析を Amazon Q Developer から受け取ることができます。従来は複数のフィルターやデータポイントをまたいで手動で調査する必要がありましたが、この機能により、設定済みのフィルターや期間に基づいた詳細な説明が自動生成されます。過去データには実績分析を、未来データには予測分析を、混在期間には両方の分析を提供します。すべての商用 AWS リージョンで追加料金なしで利用できます。 AWS FinOps Agent がプレビュー提供開始 AWS FinOps Agent は、FinOps 実務者とエンジニアリングチーム向けの AI エージェントで、コストに関する質問への回答、最適化機会の提示、コスト異常の自動調査、定期的な FinOps ワークフローの実行を行います。Amazon Bedrock 上に構築され、Cost Optimization Hub、Compute Optimizer、Jira、Slack に直接統合することで、エンジニアが普段使うツール内でコスト分析を完結できます。プレビュー版は 米国東部 (バージニア北部)リージョンで提供され、プレビュー期間中は追加料金なしで利用できます（ただし、エージェントが呼び出す AWS API の標準料金は発生します）。 6/10(水) AWS Cost and Usage Report 2.0 でテーブル設定の更新をサポート AWS は AWS Cost and Usage Report 2.0 (CUR 2.0) において、AWS Management Console および SDK/CLI を通じてデータテーブル設定を更新できる機能を追加しました。これにより、既存のエクスポートを削除して再作成することなく、新しい CUR 2.0 機能（追加カラムや詳細な行レベル粒度など）を採用できるようになります。更新された設定は、次回のスケジュール配信から適用されます。 Amazon EC2 M9g および M9gd 汎用インスタンスが利用可能に AWS は AWS Graviton5 プロセッサを搭載した Amazon EC2 M9g および M9gd インスタンスの一般提供を開始しました。M9g インスタンスは前世代の M8g 比で最大 25% の性能向上を実現し、データベースで最大 30%、Web アプリケーションと機械学習で最大 35% の高速化を達成しています。M9gd インスタンスはローカル NVMe SSD ストレージを搭載し、メディア処理やバッチ処理などの高速ストレージを必要とするワークロードに対応します。第 6 世代 AWS Nitro System を採用し、形式検証により数学的に証明されたワークロード分離を提供する Nitro Isolation Engine を初めて搭載しています。現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州(フランクフルト)の 4 リージョンで利用できます。 6/11(木) OpenAI GPT-5.4 および GPT-5.5 モデルが Amazon Bedrock の米国東部 (バージニア北部) リージョンで利用可能に AWS は OpenAI の GPT-5.4 および GPT-5.5 モデルを Amazon Bedrock の米国東部 (バージニア北部)リージョンで提供開始しました。両モデルは 272K トークンのコンテキストウィンドウを持ち、テキストと画像の入力に対応します。GPT-5.5 は OpenAI の最も高性能なモデルで、高度なコーディング、調査分析、ソフトウェア操作、長時間実行されるエージェントタスクに特化しています。GPT-5.4 はフロンティア推論、コーディング、コンピュータ使用、長文コンテキストワークフロー、ツール使用を本番環境にもたらします。両モデルは Responses API 経由で利用でき、サーバーサイドおよびクライアントサイドのツール呼び出し、プロジェクト、レスポンスストリーミングに対応しています。 AWS Workload Credentials Provider を発表 AWS は AWS Workload Credentials Provider を発表しました。このプロバイダーは、AWS Certificate Manager (ACM) からエクスポートした証明書の自動デプロイと、AWS Secrets Manager のシークレットをローカルキャッシュする軽量なクライアント側プロバイダーです。従来は ACM から証明書をエクスポートする際、Amazon EventBridge を使ってカスタム自動化を構築する必要がありましたが、CA/B Forum の規定により公開証明書の有効期限が短縮される中、このカスタム自動化は大規模環境でのメンテナンスが困難になっていました。AWS Workload Credentials Provider は、証明書とシークレットの両方を単一のプロバイダーで配布・自動化できる統合ソリューションを提供します。Windows と Linux で動作し、Apache と NGINX ウェブサーバーに対応しています。 Amazon Aurora が PostgreSQL メジャーバージョン 18 をサポート Amazon Aurora PostgreSQL-Compatible Edition が PostgreSQL メジャーバージョン 18 (18.3) をサポート開始しました。このリリースでは、B-tree skip scans によるクエリパフォーマンス改善、pg_roaringbitmap 拡張機能の追加、オプティマイザ統計の保持によるアップグレード後の性能維持、論理レプリケーションの並列ストリーミングによるレプリケーションラグ削減が実現されます。すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで利用可能です。 Amazon Quick と Snowflake Cortex AI の統合 Amazon Quick が Snowflake Cortex AI との統合を発表しました。Model Context Protocol (MCP) を介した接続により、自然言語で Snowflake の構造化データと非構造化ドキュメントをクエリできます。OAuth 認証による Snowflake 管理型 MCP サーバーを設定することで、Cortex Analyst（構造化データ分析）と Cortex Search（非構造化ドキュメント検索）へアクセス可能になります。Amazon Quick の Flows 機能を使用して、Snowflake Cortex Agents を組み合わせた反復可能なワークフローを構築でき、構造化された一貫性のある出力を得られます。この統合は Amazon Quick が利用可能な全 AWS リージョンで提供されます。 6/12(金) Amazon SageMaker AI が Nvidia Nemotron モデルのサーバーレスファインチューニングに対応 Amazon SageMaker AI は Nvidia Nemotron 3 Nano モデル (30B パラメータ) のサーバーレスモデルカスタマイゼーションに対応しました。Supervised Fine-Tuning (SFT) と Reinforcement Fine-Tuning (RFT) の両方に対応し、インフラ管理を完全に自動化することで、開発者はデータ準備とモデル評価に集中できます。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド)の 4 リージョンで利用できます。 Claude Fable および Mythos に関する発表 もありましたが、米国政府から指示があり、現在アクセス停止となっておりますのでご注意ください。Opus 4.8 等の他のモデルに関しては影響ありません。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

この記事では、パブリック API および Amazon Q との統合を備えた AWS Billing and Cost Management (請求とコスト管理) コンソールのクレジット詳細ページについてご紹介します。これにより、お客様はクレジットの確認と管理を一箇所で行えるようになります。 AWS クレジットを大規模に管理することは容易ではありません。組織の AWS 利用が拡大するにつれて、複数のプログラムからクレジットが蓄積されていきます。残高の追跡、消費の把握、割り当ての制御は、ますます複雑になっていきます。本日、パブリック API および Amazon Q との統合を備えた AWS Billing and Cost Management コンソールのクレジット詳細ページを発表します。これにより、お客様はすべてのクレジットの確認と管理を一箇所で行えるようになります。この記事では、クレジットのメタデータと適用履歴を確認する方法、ビジネス構造に合わせてクレジットレベルの共有を設定する方法、およびクレジットの一時停止や有効化によって消費タイミングを制御する方法をご紹介します。 課題：大規模なクレジット管理 組織の AWS 利用が拡大するにつれて、クレジット管理のニーズも同様に増大します。お客様からは、現在の制約についていくつかのご意見をいただいています。 個々のクレジットの識別 ： 同じプログラムから複数のクレジットが付与される場合、それらを区別するためにお客様は AWS とは別に追跡手段を用意する必要があります。 クレジット消費の追跡 ： どのアカウントやサービスがクレジットを消費したかを把握するには、複数のデータソースを突き合わせ、カスタムレポートを作成する必要があります。 残高の把握 ： お客様はチャージバックの計画や消費予測のために、月に一度よりも高い頻度でクレジット残高の情報を必要としています。 クレジット割り当ての管理 ： クレジットはデフォルトで組織内のすべてのアカウントで共有され、利用率を最大化するようになっています。ビジネス構造上必要な場合に、特定のクレジットを特定のチームやプロジェクトに割り当てるオプションを求めるお客様の声がありました。 クレジット消費タイミングの管理 ： クレジットは利用率を最大化するために自動的に適用されます。特定のクレジットを一時停止し、将来の利用のために確保しておく機能を求めるお客様の声がありました。 クレジット情報の集約 ： 複数のプログラムにまたがるクレジットを管理するチームは、統一的なビューを作成するために独自のスプレッドシートやトラッキングシステムを維持しています。 クレジット詳細ページのご紹介：すべてのクレジットを確認・管理 クレジット詳細ページは、クレジットの可視性とクレジット共有の管理機能を一箇所に集約することで、これらの課題に対応します。 確認・追跡：クレジットのメタデータと適用履歴 クレジットページから任意のクレジットを選択すると、その詳細情報をすべて確認できます。 クレジットメタデータ ： クレジット名、クレジット ID、タイプ、ステータス、発行済みクレジット額、残高、推定残高、開始日、有効期限、適用可能な製品、クレジット所有者のアカウント ID 月次適用履歴 ： 各月の連結アカウント (メンバーアカウント)、サービス、プロダクトコードごとに、クレジットがどれだけ適用されたかを示す内訳 24 時間ごとの残高更新 ： 従来の月次更新に代わり、推定残高を 24 時間ごとに更新 月次適用履歴テーブルは、お客様から最も多く寄せられた「どのアカウントとサービスが各クレジットを消費したのか」という疑問に答えるものです。これにより、社内のチャージバックプロセス、財務締め処理、消費計画をコンソールから直接行えるようになります。 管理：クレジットレベルの柔軟な共有設定 クレジット詳細ページの「共有設定 (Sharing preference)」タブから、お客様は各クレジットの消費方法を管理できます。 クレジットレベルの共有 ： 定義したアカウントグループ内のアカウントにクレジットの消費を制限します。これらのグループの作成と管理には Cost Categories を使用できます。当該クレジットは、指定されたグループに属するアカウントの利用分にのみ適用されるため、クレジットが意図した割り当て先でのみ使われるようになります。これは、予算の区分、規制要件、またはプロジェクト固有の割り当てにより、クレジットを定義されたアカウントセット内に留める必要があるシナリオで有用です。 有効化と一時停止 ： 個々のクレジットのオン・オフを切り替えることができます。アクティブなクレジットは対象の料金に適用されます。一時停止中のクレジットは、再度有効化されるまで適用されません。将来の利用や購入のためにクレジットを確保しておきたい場合に使用します。 主なメリット ビジネス構造との整合 ： 組織構造やビジネスニーズを反映した Cost Categories を使用して、ビジネスユニット、コストセンター、プロジェクト、リージョン、または資金源ごとにクレジットの割り当てを管理できます。 クレジットの消費タイミングの管理 ： クレジットを一時停止して将来の購入に備えたり、意図しない消費を防いだりできます。準備が整ったら再度有効化できます。 再利用可能なグルーピング ： 各クレジットは個別に設定しますが、グルーピングに使用する Cost Category のルールはクレジット間で再利用でき、Cost Explorer、AWS Budgets、コストと使用状況レポート、AWS Billing Conductor などの他のコスト管理ツールとも統合されています。 実際のユースケース この機能は、以下のようなタイプの組織にとって有用です。 複数のビジネスユニットを持つ企業 ： 各部門は、それぞれのプログラムや資金源に合わせたクレジットを受け取ることができ、手動での再配分なしに正確な損益報告を実現できます。 公共機関および教育機関 ： 助成金によるクレジットを承認済みのアカウントに制限することで、資金提供機関の要件に対するコンプライアンスを維持できます。 多国籍企業 ： 税務、法務、または規制上の要件を満たすために、特定の地域のアカウントにクレジットを割り当てることができます。 始めてみましょう クレジット詳細ページは、AWS のお客様向けに AWS Billing and Cost Management コンソールで現在ご利用いただけます。 AWS Billing and Cost Management コンソールのクレジットページに移動します 個々のクレジットを選択してクレジット詳細ページを開くと、クレジットのメタデータと月次適用履歴を確認できます 支払いアカウント (管理アカウント) から Cost Categories を使用して、クレジットレベルの共有設定を行い、特定のアカウントグループにクレジットの消費を制限します パブリック API を通じてプログラムによるクレジットデータへのアクセスを行ったり、Amazon Q を通じてクレジットに関する質問を自然言語で行ったりすることができます (読み取り専用) クレジットの共有設定は、コンソールおよびパブリック API を通じて管理できます。 詳細情報 AWS Billing and Cost Management コンソールのクレジット クレジットレベルの共有に関するドキュメント Cost Categories のドキュメント クレジットデータ用パブリック API Ethan Yoon Ethan Yoon は、AWS Billing and Cost Management チームのシニアプロダクトマネージャーです。クレジット、リザーブドインスタンス、Savings Plans の特典適用に関する市場投入戦略を担当しています。お客様や社内チームと連携し、企業がコストに対する説明責任を維持し、AWS へのコミットメント投資とその特典を適切に活用できるよう支援する機能の開発に取り組んでいます。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2026年 4 月号 はお読みいただけましたでしょうか。今月は、6月25日と26日に AWS Summit Japan 2026 が開催予定となっており、AWS Village では Amazon Connect Customer に関する出展を行います。皆様とお会いできることを楽しみにしています。 今月はアップデート 情報に加え、AWS Summit の Amazon Connect Customer 関連セッションに関する情報をお届けします。皆様のお役に立つ内容があれば幸いです！今月は 以下の内容でアップデート情報をお届けします。 AWS Summit Japan 2026 Amazon Connect Customer 関連セッション 2026 年 5 月のアップデート一覧 AWS Contact Center Blog のご紹介 今月のアップデートに関するよくある質問 1. AWS Summit Japan 2026 Amazon Connect Customer 関連セッション AWS Summit Japan 2026 では、今年も Amazon Connect Customer のお客様導入事例や、ユースケースを元にした最新機能のご紹介についてのセッションを行います。皆様のコンタクトセンター改革のヒントとなる情報をご提供いたしますので、是非ご参加ください。最新のセッション情報、およびご登録については AWS Summit Japan ページをご覧下さい。 日付 時刻 タイトル 6/25(木) 11:30～12:10 AI ネイティブで実現する、妥協なき顧客体験 — Amazon Connect Customer － 6/25(木) 12:20～12:50 JRE GO — 予約体験の再設計と内製開発 6/25(木) 12:30～13:10 Amazon Connect Customer で実現する進化したコンタクトセンター — Agentic AI が変える顧客体験 — 6/25(木) 16:30～17:10 パーソナライズでビジネス成長を実現するコンタクトセンターへ ― AI エージェントが顧客を知り、先回りする― 6/26(金) 13:40～14:10 東京電力におけるコンタクトセンター変革 － CX 向上に向けた AI 活用の取り組み－ 2. 2026 年 5 月のアップデート一覧 Amazon Connect Customer のタスクは何日先までスケジュールできますか？最長90日先までの登録に対応しました – 2026/05/29 Amazon Connect Customer で、最長90日先までのタスクをスケジュール登録できるようになりました。組織が長期にわたるフォローアップ作業の計画、ルーティング、および追跡を行えるようになります。例えば、自動車修理の請求を管理する保険チームでは、査定員の訪問、部品の在庫確認、修理完了後のフォローアップのために将来のタスクをスケジュールでき、それぞれのタスクは関連する請求のコンテキストを保持したまま、適切なタイミングで適切なチームにルーティングされます。タスクのスケジュール登録は、StartTaskContact API、フロー、またはエージェントワークスペースから行えます。この機能は、Amazon Connect Customer が提供されているすべての商用リージョンおよび AWS GovCloud（米国）リージョンで利用可能です。 管理者ガイド Amazon Connect Customer のタスク Amazon Connect Customer のコンタクト後の要約は日本語に対応していますか？日本語を含む8言語ファミリーが新たに追加されました – 2026/05/28 Amazon Connect Customer の生成 AI を活用したコンタクト後の要約が、日本語を含む8つの言語ファミリー（ポルトガル語、フランス語、イタリア語、ドイツ語、スペイン語、中国語、日本語、韓国語）に対応しました。コンタクト後の要約は、音声・チャット・メールチャネルにわたる顧客との会話の簡潔で構造化された概要をエージェントやマネージャーに提供し、トランスクリプト全体を読む必要をなくします。この拡張により、会話で使用された言語で要約が自動的に生成されるため、エージェントはコンタクト後の作業をより迅速に完了でき、マネージャーは複数の言語でコンタクトを確認できるようになります。例えば、グローバルなサポート組織では、フランス語、ドイツ語、日本語で対応した通話の要約を自動生成し、スーパーバイザーがすべての地域のサービス品質を把握できます。この機能は、Amazon Connect Customer のコンタクト後の要約が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド 生成 AI を活用したコンタクト後の要約の表示 Amazon Connect Customer のステップバイステップガイドを自然言語で作成できますか？ノーコード UI ビルダーに AI アシスタントが搭載されました  – 2026/05/28 Amazon Connect Customer アシスタントが UI ビルダーに統合され、コンタクトセンターのマネージャーが自然言語を使用してビューを作成・変更できるようになりました。例えば、「評価フィールドとコメントフィールドを含んだフィードバックフォームを作成」と説明するだけで、対応する UI コンポーネントが自動生成されます。生成されたものはレビューしてから公開でき、ステップバイステップガイドやワークスペースページのビュー作成に必要な時間と専門知識を最大70%削減できます。マネージャーは会話形式のプロンプトを使用して、ビューの作成、条件付き UI によるレイアウトの設定、コンポーネントプロパティの設定、スタイルの適用を、手作業に頼らずに行えます。アシスタントはコンポーネントの推奨、オプションの説明、問題のトラブルシューティングも行い、構築作業を迅速化します。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（ロンドン）、AWS GovCloud（米国西部）の各 AWS リージョンで利用可能です。 管理者ガイド Connect assistant in the UI builder Amazon Connect Customer で AI エージェントによるセルフサービス対話の品質を自動評価できますか？生成 AI を使用した自動評価が可能になりました – 2026/05/27 Amazon Connect Customer で、マネージャーが生成 AI を使用してセルフサービスの対話を自動的に評価し、カスタマーエクスペリエンスを向上させるための集約されたインサイトを取得できるようになりました。マネージャーは評価フォーム内で「お客様の問題はすべて AI エージェントによって解決されたか?」など、自然言語でカスタム評価基準を定義できます。生成 AI はこの基準を使用してセルフサービス対話の質を評価し、会話の文字起こしからの関連する参照ポイントとともに、評価の詳細な推論を提供します。管理者は、これらのインサイトのまとめや個々の問い合わせについて、セルフサービス対話の記録や文字起こしと合わせて確認し、AI エージェントのパフォーマンスを向上させる機会を特定できます。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）の AWS リージョンで利用可能です。 管理者ガイド セルフサービス対話のパフォーマンス評価 Amazon Connect Customer のエージェントログイン/ログアウトレポートにきめ細かなアクセス制御は適用できますか？タグベースアクセスコントロールに対応しました – 2026/05/26 Amazon Connect Customer のエージェントログイン/ログアウトレポートで、タグベースのアクセスコントロールがサポートされるようになりました。データアクセスに関するコンプライアンスおよび規制要件を満たすために、きめ細かなアクセス制御を適用できます。コンタクトセンター管理者は、リソースタグを使用して、特定のエージェントのログインおよびログアウト情報を閲覧できるユーザーを制御できます。例えば、エージェントに「Department: Customer Service」というタグを付けると、カスタマーサービスのチームマネージャーのみがこれらのエージェントのログイン/ログアウト情報を確認できるようになります。この機能は、Amazon Connect Customer が提供されているすべての AWS 商用リージョンおよび AWS GovCloud（米国西部）リージョンで利用可能です。 管理者ガイド タグベースのアクセス制御 Amazon Connect Cases でエージェントがケースの関連項目を編集・削除できますか？エージェントワークスペースからの直接操作に対応しました – 2026/05/15 Amazon Connect Customer Cases で、関連項目の編集と削除、およびエージェントワークスペースからのケースの直接削除が管理者の介入なしで行えるようになりました。エージェントは、コメントを更新したり、間違ったケースに関連付けられている連絡先のリンクを解除したり、誤って開かれたケースを削除したりできます。また、注文、返品、請求書などのカスタム関連項目を作成・編集・削除して、追加のケースコンテキストを把握することも可能です。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト）、欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アフリカ（ケープタウン）の各 AWS リージョンで利用可能です。 Amazon Connect Customer でエージェントが自分のパフォーマンス評価だけを確認できますか？自己評価の表示専用権限が追加されました – 2026/05/14 Amazon Connect Customer で、他のエージェントの評価を公開せずに、エージェントが自分のパフォーマンス評価のみにアクセスできる権限がサポートされるようになりました。エージェントはフィードバックを確認してパフォーマンスを向上させることができます。この権限により、エージェントは自分が評価を受けたコンタクトを検索し、通話録音やトランスクリプトと並べて評価を確認したり、確認後に承認を送信したりできます。例えば、複数のコンタクトにまたがる顧客の問題を調査するために部署全体の連絡先を閲覧する権限をエージェントに付与しつつ、評価については自分のものだけを確認できるように設定できます。同僚の機密性の高いパフォーマンスデータをエージェントが閲覧できない状態を確保しながら、運用上の柔軟性を提供します。この機能は、Amazon Connect Customer が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド 評価とコーチングの権限 Amazon Connect Customer の Cases と Customer Profiles をカスタムエージェントアプリケーションに埋め込めますか？SDK による統合が可能になりました – 2026/05/12 Amazon Connect Customer で、カスタムエージェントアプリケーションに Cases と Customer Profiles を埋め込めるようになりました。エージェントは問題解決のために既に使用しているツールに加えて、ケースの詳細や顧客のコンテキストにアクセスできるようになります。デベロッパーは Amazon Connect SDK を使用してネイティブの Connect 環境をカスタムアプリケーションに取り込むことができるため、これらの機能をゼロから構築して保守する必要がなくなります。この機能は、Amazon Connect Customer が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド / デベロッパーガイド カスタムアプリケーションへの統合 Amazon Connect SDK（GitHub） Amazon Connect Customer のアフターコンタクトワーク時にステップバイステップガイドを自動起動できますか？ACW 用デフォルトガイドが追加されました – 2026/05/08 Amazon Connect Customer で、アフターコンタクトワーク（ACW）のデフォルトガイドがサポートされるようになりました。コンタクトセンターの管理者は、エージェントが ACW 状態になったときに手動操作なしでステップバイステップガイドを自動的に起動できます。処理コードの記録、ケースの更新、フォローアップアクションの完了など、必要なラップアップタスクをエージェントが自動的に実行できるようにすることで、コンタクト後のワークフローを標準化し、対応時間を短縮できます。ACW 中にエージェントが手動で正しいアプリケーションに移動する必要がなくなるため、コンタクトセンター業務全体において一貫性の向上、エラーの削減、エージェントの生産性向上が期待できます。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（ロンドン）、AWS GovCloud（米国西部）の各 AWS リージョンで利用可能です。 管理者ガイド Amazon Connect のフローブロック: ビューを表示 Amazon Connect Customer のアウトバウンドキャンペーンは複数タイムゾーンの顧客に適切な時間帯で配信できますか？複数の連絡先情報からのタイムゾーン検出に対応しました – 2026/05/07 Amazon Connect Customer のアウトバウンドキャンペーンで、主要な連絡先フィールドだけでなく、顧客プロファイルのすべての電話番号と住所を使用して顧客のタイムゾーンが検出されるようになりました。これまでは主要な電話番号のみが使用されていたため、複数のタイムゾーンにまたがる顧客を見落とす場合がありました。プロファイルの連絡先情報が複数のタイムゾーンにまたがっている場合は、検出されたすべてのタイムゾーンにおいて設定済みの時間帯に含まれる場合にのみ配信し、重複がない場合はプロファイルをスキップします。例えば、顧客に東部標準時の市外局番の携帯電話番号と太平洋標準時の市外局番の事業用電話番号があり、キャンペーンが午前9時から午後5時まで配信されるように設定されている場合、メッセージは両方のタイムゾーンが許可された時間帯に含まれる東部標準時午後12時から午後5時（太平洋標準時午前9時から午後2時）にのみ配信されます。この機能は、Amazon Connect アウトバウンドキャンペーンが提供されているすべての AWS リージョンで追加費用なしで利用可能です。 管理者ガイド アウトバウンドキャンペーンの配信時間設定 Amazon Connect Customer Cases で重複する顧客プロファイルが統合されたときケースも自動的にまとまりますか？アイデンティティ解決との連携に対応しました – 2026/05/05 Amazon Connect Customer Cases で、重複する顧客プロファイルが統合される際にケースが自動的に再度関連付けられるようになりました。これにより、エージェントは常にそれぞれの顧客の完全なケース履歴を確認できます。同じ顧客が異なるチャネルを通じて連絡したり、異なる連絡先情報を提供したりすることで複数のプロファイルが作成される場合があります。Amazon Connect Customer Profiles のアイデンティティ解決がそれらの重複を検出して統合すると、関連付けられたすべてのケースが Cases によって統合プロファイルに自動的にまとめられます。エージェントは複数のプロファイルを検索したり、顧客の履歴を手動でまとめたりする必要がなくなりました。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト）、欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アフリカ（ケープタウン）の各 AWS リージョンで利用可能です。 管理者ガイド Amazon Connect Cases 3. AWS Contact Center Blog のご紹介 Amazon Connect Customer: 中国への発信におけるコンプライアンスのベストプラクティス (日本語翻訳) グローバルにビジネスを展開する企業にとって、中国（国番号 +86）への発信における通信規制への準拠は避けて通れない課題です。規制に適合しない設定のままアウトバウンド発信を行うと、通話切断やサービス停止、さらには中国への発信機能そのものの利用制限といった深刻な影響を受ける可能性があります。本記事では、Amazon Connect Customer を使用して中国へコンプライアンスに準拠した発信を行うための 5 つのベストプラクティス（承認済み DID 番号の設定、禁止番号タイプの排除、レート制限の実装、発信者 ID の設定、番号検証の実装）を紹介します。 4. 今月のアップデートに関するよくある質問 Q. Amazon Connect Customer とは何ですか？ Amazon Connect は、Amazon の運用実績に基づいて構築されたエージェンティック AI ソリューションのファミリーになりました。2026年4月に、Amazon Connect Customer（カスタマーエクスペリエンス）、Amazon Connect Decisions（サプライチェーン）、Amazon Connect Talent（採用）、Amazon Connect Health（ヘルスケア）の4つのソリューションに拡張されました。( Amazon Connect について ) コンタクトセンター領域を担う Amazon Connect Customer は、音声・チャット・メール・タスクなど複数のチャネルを一つのプラットフォームに統合し、AI を中核に据えたクラウドコンタクトセンターソリューションです。料金プランは、すべての AI 最適化機能がチャネル料金に含まれる「Amazon Connect Customer」（旧 Unlimited AI）がデフォルトです。従来のアラカルト型プランは「Amazon Connect Customer Basic」として既存顧客向けに提供されていますが、今後の新しい AI 機能は Connect Customer で提供されるため、Customer Basic からの移行が推奨されます。( Amazon Connect Customer について / Amazon Connect Customer の料金 ) Q. Amazon Connect Customer Tasks とは何ですか? Amazon Connect Customer Tasks は、音声・チャット・メールと同じように優先順位付け、割り当て、追跡、自動化ができる作業項目です。エージェントはエージェントワークスペース上でタスクを受け取り、フォローアップの電話、保険請求の処理、ケースの更新など、コンタクト対応以外の業務を管理できます。タスクは手動で作成するほか、コンタクトフロー内のアクション、ルール、StartTaskContact API から自動生成することも可能です。ルーティングプロファイルによりキューへの振り分けや優先度の設定ができ、今月のアップデートでは最長90日先までのスケジュール登録にも対応しました。（ Amazon Connect Customer Tasks ） Q. Amazon Connect Customer のステップバイステップガイドとは何ですか？ ステップバイステップガイドは、エージェントワークスペース上でエージェントに対して業務手順を段階的に案内する UI コンポーネントです。管理者はノーコードの UI ビルダーでフォーム、ボタン、テキストなどのコンポーネントを組み合わせてガイドを作成し、コンタクトフローでトリガー条件を設定できます。エージェントが通話を受けた際やアフターコンタクトワーク（ACW）に入った際に自動的に表示され、処理コードの入力、ケース作成、顧客情報の確認などを標準化された手順で実行できます。今月のアップデートでは、ACW 状態でデフォルトガイドを自動起動する機能と、AI アシスタントによる自然言語でのガイド作成（作成時間を最大70%削減）が追加されました。（ ステップバイステップガイド ） Q. Amazon Connect Customer にはどのようなレポートがありますか？ Amazon Connect Customer は以下のレポート・分析機能を提供しています。 リアルタイムメトリクス : キューやエージェントの現在の状態（待ち呼数、対応可能エージェント数、サービスレベルなど）をリアルタイムに表示します。 履歴メトリクス : 指定した期間のコンタクト数、平均処理時間、放棄率などを集計し、トレンド分析に活用できます。 ダッシュボード : キューとエージェントのパフォーマンスを視覚的に一覧でき、カスタムウィジェットやカスタムメトリクスの作成も可能です。 ログイン/ログアウトレポート : エージェントの勤務時間を追跡し、タグベースのアクセスコントロールによりチームマネージャーごとに閲覧範囲を制限できます。 会話分析（Conversational Analytics） : 音声・チャット・メールのコンタクトに対してリアルタイムおよびコンタクト後の分析を提供します。自動文字起こし、感情分析、コンタクトの自動分類、PII（個人識別情報）の墨消し、生成 AI によるコンタクト後の要約生成、テーマ検出などの機能を備えています。 分析データレイク : コンタクトデータを Amazon Athena や Amazon Quick で直接クエリ・分析でき、複雑なデータパイプラインを構築することなくカスタムレポートを作成できます。今月のアップデートでは、ログイン/ログアウトレポートへのタグベースアクセスコントロールが追加されました。 Q. Amazon Connect Customer の Identity Resolution(アイデンティティ解決)とは何ですか？ アイデンティティ解決は、Amazon Connect Customer Profiles の機能で、同じ顧客が異なるチャネルや連絡先情報で作成した複数のプロファイルを自動的に検出・統合する仕組みです。今月のアップデートにより、プロファイルが統合される際に Amazon Connect Cases のケースも自動的に統合プロファイルに再関連付けされるようになりました。エージェントは複数のプロファイルを検索する必要なく、常に顧客の完全なケース履歴を確認できます。( Amazon Connect Customer Profiles , Identity Resolution ) Q. Amazon Connect Customer Cases とは何ですか？ Amazon Connect Customer Cases は、顧客との応対履歴をケースとして作成・追跡・管理する機能です。エージェントはエージェントワークスペース内でケースの作成、ステータスの更新、関連するコンタクトやタスクの紐づけを一画面で行えます。ケースにはカスタムフィールドを定義でき、テンプレートを使って業種や業務に応じた構造化が可能です。コンタクトフローからケースを自動作成するルールも設定できます。今月のアップデートでは、エージェントがワークスペースから関連項目の編集・削除やケースの直接削除が可能になったほか、Amazon Connect Customer Profiles のアイデンティティ解決によりプロファイル統合時にケースが自動的に再関連付けされるようになりました。（ Amazon Connect Customer Cases ） Q. Amazon Connect Customer のアウトバウンドキャンペーンとは何ですか？ アウトバウンドキャンペーンは、Amazon Connect Customer Profiles のセグメントに基づいて、音声・SMS・メールなど複数チャネルで顧客にプロアクティブにアプローチする機能です。そして、ジャーニー（複数ステップのワークフロー）を設計し、顧客の行動や属性に応じたパーソナライズされたアウトリーチを実行できます。セグメントビルダーで対象顧客を定義し、ビジュアルフローデザイナーでマルチチャネルジャーニーを構築します。配信ガードレールやエンゲージメント設定により、適切な時間帯・頻度でのコミュニケーション管理も可能です。今月のアップデートでは、顧客プロファイルのすべての電話番号と住所からタイムゾーンを検出し、複数タイムゾーンにまたがる顧客にも適切な時間帯で配信できるようになりました。（ アウトバウンドキャンペーン ） 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 AWS Summit Japan 2026 にもぜひご登録の上、ご来場ください。会場でお待ちしています！Amazon Connect Customer の最新情報は毎月このブログでお届けしていますので、来月号もお楽しみに。 著者プロフィール   梅田　裕義（Hiroyoshi Umeda） アマゾンウェブサービスジャパン合同会社 シニア Amazon Connect ソリューションアーキテクト 2020年12月入社。コンタクトセンター領域を専門に、Amazon Connect Customer を活用した顧客体験の向上や業務効率化の技術支援を行っています。AI によるセルフサービスの導入、オムニチャネル対応、分析基盤の構築などコンタクトセンターが抱える課題解決に幅広く取り組んでいます。

セガサミーホールディングス株式会社は、エンタテインメントコンテンツ事業、遊技機事業、ゲーミング事業の 3 つの事業領域を軸に展開する総合エンタテインメント企業グループの持株会社です。同社では、グループ会社であるサミー株式会社の基幹業務システム（販売、調達、生産、在庫管理）を支えるデータベースを、オンプレミスの Oracle Database から Amazon RDS for Oracle に移行しました。本ブログでは、移行の背景にあった課題、移行の取り組み、そして移行後に得られた効果についてご紹介します。 移行対象のシステム 今回の移行対象のデータベースは、サミー株式会社の基幹業務（販売、調達、生産、在庫管理）を支える複数の業務システムのバックエンドとして利用されていました。その大部分を占めるのが intra-mart を開発基盤とした基幹システムです。intra-mart の AP サーバーおよびデータベースはオンプレミス環境で運用されており、今回のプロジェクトで AP サーバーとデータベースの双方を AWS に移行しました。データベースには約 4,000 のテーブル、約 650 のマテリアライズドビュー、約 600 のプロシージャが存在し、データサイズは約 2TB に及びます。基幹系システムであるため、月次メンテナンス日以外は無停止での稼働が求められていました。 課題 当該システムをオンプレミスで運用する中で、大きく 3 つの課題がありました。 物理制約と調達遅延 オンプレミス環境では、リソース拡張にサーバーやストレージの事前購入が必要で、調達に時間がかかるため、事業や環境変化への即時対応が困難でした。初期投資の負担も大きく、突発的な負荷変動にも即座に対応できない状況でした。加えて、ハードウェア障害時には長時間のダウンタイムをともなうリスクがあり、DR/BCP 対策の強化も容易ではなく、基幹系システムとしての可用性に懸念を抱えていました。 運用負荷 監視ツールは自社で選定・管理する必要があり、開発・テスト環境の構築にもインフラ担当への依頼が必要でした。物理機器の保守やハードウェアのライフサイクル対応（リプレイス作業）にも工数を割かれ、月次メンテナンスなど業務時間外の対応も発生していました。こうした定型的な運用業務に時間を取られ、インフラ担当者が本来注力すべき高度な業務に集中しにくく、モチベーションの維持も難しい状況でした。 AI 活用を見据えた拡張性の確保 同社では、グローバルレベルでのデータ基盤強化とデータ利活用の促進、AI 活用による業務効率化を IT 戦略として掲げていました。将来的な AI 活用やデータ分析の推進を見据え、周辺サービスと柔軟に連携できる環境への移行も視野に入れていました。 ソリューション これらの課題を解決するため、オンプレミスのデータベースをクラウドへ移行する方針が決定されました。移行先として AWS に加え Oracle Cloud Infrastructure（OCI）やオンプレミスの継続も検討しましたが、以下の理由から AWS 上のマネージドサービスである Amazon RDS for Oracle を採用しました。 同一エンジン（Oracle）のマネージドサービスへの移行であるため、アプリケーション改修を最小限に抑え、移行コストを低減できる マネージドサービスの活用により、バックアップやパッチ適用などの運用負荷を軽減し、DR/BCP 対策の強化やリソースの柔軟な拡張が実現できる AWS 上にデータベースを配置することで、ETL、分析基盤、AI/ML など AWS の周辺サービスとの連携が容易になり、データ利活用の推進基盤として活用できる また、同社ではクラウドファーストを会社の方針として掲げており、コスト最適化およびマネージドサービス活用による運用効率の向上を推進していたことも、今回の移行を後押ししました。 移行スケジュール 移行は以下のスケジュールで実施しました。 プロジェクト計画フェーズ 移行に先立ち、2025 年 2 月中旬から 3 月末にかけてプロジェクト計画を策定しました。本プロジェクトは Oracle 11g から 19c へのバージョンアップも兼ねていたため、AWS Schema Conversion Tool（SCT）を使用してスキーマの互換性を事前に検証しました。これにより、DB オブジェクトの互換性に関する課題を早期に把握することができました。 また、Amazon RDS for Oracle に向けて対応が必要な箇所や影響範囲の洗い出しを行った結果、帳票出力や SQL Loader によるデータロードなどに影響があることが判明しました。帳票出力については、オンプレミス環境でファイルシステムにマウントして出力していた処理を変更する必要がありました。また、SQL Loader によるデータロードについても同様に影響がありました。いずれも Amazon RDS と Amazon S3 のインテグレーション機能を活用する方式に置き換えて対処しました。S3 インテグレーションへの切り替えは当初想定よりも対応範囲が広かったものの、方針が固まってからはスムーズに進めることができました。 加えて、オンプレミスからクラウドへの移行にあたっては、ネットワークレイテンシーの影響が懸念されました。検証ではデータ量に応じてレイテンシーが増加する傾向が見られましたが、最も遅延の影響を受けやすく、データ量が比較的小さい工場システムで問題がないことを確認し、移行可能と判断しました。 テストフェーズ 2025 年 8 月中旬から 11 月末にかけて、主要業務の SQL を対象としたシステムテストを実施しました。約 8 件の SQL でパフォーマンスの劣化が確認されました。原因は、移行先の Oracle バージョンでオプティマイザが生成する実行計画が最適ではなかったことにありました。この問題には OPTIMIZER_FEATURES_ENABLE パラメータのヒント句で対応しました。OPTIMIZER_FEATURES_ENABLE は、オプティマイザの動作を指定したバージョンの挙動に合わせるパラメータです。移行元のバージョンを指定することで移行前と同等の実行計画が生成されるようになり、性能劣化の大部分を解消しました。 移行実施 2025 年 12 月末に本番移行を実施しました。約 4,000 テーブル・約 2TB の基幹 DB を EXP/IMP で移行しました。本番切替後にも、事前テストでカバーしきれなかった一部の SQL でパフォーマンスの遅延が発生しましたが、テストフェーズで OPTIMIZER_FEATURES_ENABLE によるワークアラウンドを把握できていたため、同じ対処で速やかに改善することができました。それ以外に大きな問題は発生せず、基幹業務システムとしてスムーズに稼働を開始しました。DB が AWS 上に移行されたことでネットワーク構成が改善され、移行前と比較してパフォーマンスの向上も実感できる結果となりました。 導入効果 Amazon RDS for Oracle への移行により、以下の効果が得られました。 パフォーマンスの向上 移行により明らかにパフォーマンスが向上し、日次夜間バッチの処理時間も約 22% 短縮されました。高負荷時に遅くなる事象が解消され、サーバーダウンにつながるような負荷の問題もなくなりました。また、最適なリソース選択が容易になり、ワークロードに応じた適切なインスタンスサイズを柔軟に選択できるようになりました。 柔軟性の向上 AWS への移行により、数分でリソース拡張が可能になり、オンプレミス特有の物理制約や調達遅延が解消されました。突発的な負荷変動が発生した場合でも対処できる選択肢が確保され、事業や環境変化に対応できる安心感のある基盤を実現しました。初期投資についても、オンプレミスのようにサーバーやストレージを事前に大きく購入する必要がなくなり、利用量ベースで投資判断がしやすくなりました。さらに、別リージョンや別 AZ への設計を取り入れやすくなったことで、DR/BCP 対策の強化や事業継続性の向上にもつながっています。 運用効率の改善 監視は Amazon CloudWatch や Amazon CloudWatch Database Insights といった AWS のマネージドサービスに統合され、自社で監視ツールを選定・管理する必要がなくなりました。インフラ担当に頼らず、アプリ開発チームでも環境準備が可能になり、早期の環境構築が実現しました。月次メンテナンス時の再起動も不要になりました。オンプレミスの物理機器保守やハードウェアのライフサイクル対応（リプレイス作業）からも解放され、運用負荷が大幅に低下しました。こうした定型的な運用業務からの解放により、インフラ担当者のモチベーション向上にもつながっています。 データ利活用基盤としての拡張性 AWS 上にデータベースを配置したことで、ETL、分析基盤、AI/ML など AWS の周辺サービスとの連携が容易になりました。データベースを起点とした拡張性が高まり、IT 戦略として掲げるデータ利活用や AI 活用を推進するための基盤が整いました。 こうした効果を踏まえ、今回の AWS 移行についてセガサミーホールディングス株式会社の江田氏は以下のように振り返っています。 「移行により明らかにパフォーマンスが良くなりました。移行後は障害も発生しておらず、インフラ担当者が本来やるべき高度な業務に専念できる環境にシフトすることができました。」 – 江田 英昭 氏　セガサミーホールディングス株式会社 ITソリューション本部 ビジネスシステム部 部長 今後は、クラウドファースト方針のもと AWS のサービスや AI の活用を推進し、Amazon Redshift によるデータ分析をはじめ、グループ全体でのデータ利活用を拡大していく予定です。