本記事は米国時間 2025 年 9 月 15 日に公開された Announcing new pricing plans and Auto, our new agent を翻訳したものです。 Kiro は 9 月 30 日まで引き続き無料でご利用いただけます。10 月 1 日以降は、選択したプランに応じて課金されます。 この 1 か月間、皆さまから Kiro に関する素晴らしいフィードバックをいただきました。そのフィードバックや日常の開発作業における利用状況を踏まえ、Kiro の新しい料金体系を発表いたします。 統一された利用上限 : これまでの vibe タスクと spec タスクで別々だった上限をやめ、すべてのリクエストが 単一のクレジットプール から消費されるようになります。これにより、柔軟にコントロールしながら Kiro をご利用いただけます。新しい統一上限は以下の通りです。   Free Pro Pro+ Power $0 $20 / 月 $40 / 月 $200 / 月 50 クレジット 1,000 クレジット 2,000 クレジット 10,000 クレジット 従量課金 ($0.04 / クレジット) 従量課金 ($0.04 / クレジット) 従量課金 ($0.04 / クレジット) クレジットの細分化課金 : クレジットはプロンプトの複雑さに応じて小数点単位で消費されます。簡単な編集やプロンプトであれば 1 クレジット未満の消費となり、0.01 クレジット単位で課金されるため、クレジットを最大限に活用できます。 無料トライアル : 初めて Kiro にアクセスした際には、14 日間有効な 500 クレジットのボーナスを付与します。詳細は FAQ をご覧ください。 タスクは複雑さに応じて異なる速度でクレジットを消費します。クレジットの仕組みの詳細については、FAQ をご覧ください。また、月次使用ダッシュボードでクレジット消費が可視化されるよう改善しました。今後数週間のうちに、Kiro は通知バーに消費したクレジット数を表示するようになり、月間制限に対する進捗状況を簡単に確認できるようになります。 Auto の紹介 Kiro の利用方法から学んだ重要なことの一つは、プロンプトの複雑さや出力要件が大きく異なるという点です。Kiro の目標は「最高の結果を最適な価格で」提供することです。そのために構築したのが Auto という新しいエージェントです。Auto は Sonnet 4 のようなフロンティアモデルと、特定のタスクに特化したモデルを組み合わせ、インテント検出やキャッシングなどの最適化技術を活用します。 Auto は常に性能・効率・出力品質を最適化します。例えば、あるタスクを Auto で実行すると X クレジット消費する場合、Sonnet 4 で実行すると 1.3 Xクレジット消費します。このコスト効率と Sonnet 4 レベルの品質を両立するため、Auto をチャット画面のデフォルトオプションに設定しました。もちろん、Sonnet 4 を指定して利用することも可能ですが、その場合はプランの上限が早く尽きてしまいます。 現在の Auto はまだ始まりに過ぎません。今後はニューロシンボリック AI（ニューラルネットワークと形式的推論の組み合わせ）を導入し、要件作成や改善、実装の検証といったタスクでさらに高品質な出力を目指しています。Auto が日常のリクエストを高性能かつコスト効率よく処理する様子をぜひ体感いただけると思います。 価格改定の実施 10 月 1 日までに、有料ユーザー向けにクレジットの単一プールと新たな制限を適用した更新プランを段階的に導入します。移行後、制限が新しい月額プランの制限値にリセットされることをご確認ください。Kiro は 9 月 30 日まで引き続き無料でご利用いただけます。10 月 1 日より、ご利用中のプランの課金が発生します。 有料プランをご利用の場合、超過料金の利用も可能です。超過料金も 9 月 30 日まで無料となります。10 月 1 日までは超過料金の上限を 1,000 クレジットとし、 10 月 1 日までに返金いたします。 10 月 1 日までに新規で Kiro にご加入いただいた場合、ご利用分は 10 月 1 日までに返金され、月額制限をフルにご利用いただけます。例えば 9 月 20 日にPro+ プランを購入された場合、9 月 30 日まで月額 2,000 クレジットを無料で全額ご利用いただけます。 FAQ Kiro の料金体系はどうなっていますか？ Kiro は開発者の利用方法に合わせた柔軟な料金体系を提供しています。Free プラン（50 クレジット）から始められ、Pro（$20/月）、Pro+（$40/月）、Power（$200/月）にアップグレード可能です。すべての有料プランで超過利用に対する従量課金（$0.04/クレジット）を利用できます。料金には消費税等は含まれません。日本の請求先住所を持つ場合、日本の消費税が適用されます。 クレジットとは何ですか？ クレジットはユーザーのプロンプトに対する作業単位です。簡単なプロンプトは 1 クレジット未満、spec タスクなどの複雑なプロンプトは 1 クレジット以上を消費します。モデルごとに消費量も異なり、Sonnet 4 では Auto より 1.3 倍多く消費します。クレジットは小数点第 2 位まで計測され、最小消費は 0.01 クレジットです。 クレジットは何に使えますか？ vibe モードや spec モードでのプロンプト実行、spec の洗練、タスク実行、エージェントフックの実行に消費されます。 クレジット使用量はどうやって確認できますか？ Kiro IDE のサブスクリプションダッシュボードでは、ご契約プランの月間クレジット上限、使用済みクレジット数、残りのクレジットを確認できます。使用量は 5 分以内に更新されます。 追加クレジットは購入できますか？ はい。有料プランでは利用超過機能を有効化すれば、月間上限を超えて利用可能です。追加分は $0.04/クレジットで月末に精算されます。例えば Pro プラン（1,000 クレジット）で 1,100 クレジット使用した場合、翌月の請求に $4 が加算されます。超過料金はデフォルトで無効化されており、適用するには設定で有効にする必要があります。超過料金を有効にした後は、有料プランを利用している限り有効な状態が維持されます。Kiro Free プランにダウングレードすると超過料金は無効化され、有料プランに戻った際に再度有効にする必要があります。 料金展開はどのように行われますか？ 10 月 1 日までに順次新プランへ移行します。移行後は新しい月間上限が適用されます。超過料金も 9 月 30 日までは無料で、上限 1,000 クレジットまで利用可能です。新規ユーザーも 9 月 30 日までは利用料が返金されます。 無料トライアルはどうなっていますか？ 10 月 1 日以降、Kiro に初めてアクセスした場合（ウェイティングリストから解除された場合）、ご登録プラン（Kiro Free を含む）に関わらず、14 日間有効な 500 ボーナスクレジットが付与されます。 チームでサブスクリプションを共有できますか？ いいえ。利用制限はユーザー単位で計算されます。 組織向けの課金・管理機能は今後提供予定です。 未使用クレジットは翌月に繰り越せますか？ 利用制限は各請求月の初日にリセットされます。未使用のクレジットは翌月に繰り越せません。 Kiro はどのモデルを利用していますか？ デフォルトでは Auto エージェントによって処理されます。このエージェントは、Sonnet 4 などの複数のフロンティアモデルと、特定のタスク、意図検出、キャッシュ、その他の技術に特化した専門モデルを組み合わせて使用し、品質、レイテンシー、コストのバランスを最適化します。 支払い方法は？ 主要なクレジットカードをご利用いただけます。 有料プランに対応している国は？ 現在、オーストラリア、ブラジル、カナダ、中国、フランス、ドイツ、香港特別行政区、インド、インドネシア、イスラエル、イタリア、日本、韓国、メキシコ、オランダ、ポーランド、ルーマニア、シンガポール、スペイン、タイ、イギリス、アメリカ、ベトナムの請求先住所でご利用いただけます。今後さらに国や地域が追加される予定です。

本記事は米国時間 8 月 29 日に公開された “ Implementing usage and security reporting for Amazon ECR ” を翻訳したものです。 コンテナワークロードを管理する際、コンテナレジストリの一元的なオブザーバビリティを維持することはセキュリティと効率的なリソース利用のために不可欠です。 Amazon Elastic Container Registry (ECR) は、イメージレベルとリポジトリレベルの両方でメトリクスを提供し、統合されたオブザーバビリティを構築する上で重要な役割を果たします。本記事では、これらのメトリクスをコスト内訳、利用状況メトリクス、セキュリティスキャン結果、および全リポジトリにわたるコンプライアンスステータスを含む、基本的で包括的なレポートに一元化する手順をご案内します。統合されたオブザーバビリティにより、利用パターンをより深く理解し、セキュリティリスクを特定し、セキュリティ要件と最適化のベストプラクティスに準拠させる必要があるリソースに優先順位を付けることが出来ます。 本記事では、 サンプルコード を利用して 2 種類のレポートを生成します。1) リポジトリサマリーレポート – レジストリ内の全ての Amazon ECR リポジトリを一覧表示し、コスト、利用状況、 Amazon ECR イメージスキャン で検出された OS 脆弱性の追跡と最適化に必要な属性を提供します。2) イメージレベルレポート – 特定のリポジトリ内の全てのイメージを含み、最初のレポートで発見された内容を詳しく調査するために利用可能な属性を提供します。 これらのレポートは、コスト削減のために未使用のリポジトリとイメージの特定に役立ち、最も多くまたは最も重いイメージを持つリポジトリとライフサイクルポリシーが欠けているリポジトリを強調するのに役立ちます。これらは、ストレージ利用状況、セキュリティスキャン状態、リポジトリ全体にわたる重要なセキュリティ発見事項に関する洞察を提供し、それによってより良いコスト管理、ポリシー実装、優先順位付けされたセキュリティ修復を可能にします。 ソリューション概要 このセクションでは、Amazon ECR リポジトリに関する詳細なレポートを生成する サンプルコード を実行する方法を示す実践的な例を提供します。2 種類のレポートは次のように説明されます。 リポジトリサマリー : レジストリ内のリポジトリのサマリーで、次の属性を提供します: 名前 説明 repositoryName リポジトリ名 createdAt リポジトリが作成された日付 scanOnPush リポジトリにプッシュされた後にイメージがスキャンされるかどうか totalImages リポジトリ内のイメージ / アーティファクトの総数 totalSize(MB) リポジトリ内のイメージ / アーティファクトの総サイズ (MB) hasBeenPulled リポジトリ内のいずれかのイメージが少なくとも 1 回プルされたか lastRecordedPullTime リポジトリ内のイメージが最後にプルされた日付 daysSinceLastPull リポジトリが最後のイメージプルを記録してからの日数 lifecyclePolicyText リポジトリのライフサイクルポリシーテキスト この情報は、どのリポジトリが最も多くのイメージを持っているか、どれが最も重いか (イメージ / アーティファクトの総サイズについて) 、どれがライフサイクルポリシーを欠いているかを特定するのに役立ちます。これらの要因は、リポジトリの維持コストに大きく影響します。最後に、このレポートでは、イメージがリポジトリにプッシュされた後にスキャンされるかどうかを確認できます。コンテナスキャンを有効にすることで、組織はセキュリティリスクを大幅に削減し、コンテナ化された環境で強力なセキュリティ態勢を維持できます。 totalSize (MB) フィールドは、Amazon ECR における総ストレージコストを見積もるために利用すべきではありません。なぜなら、これにはリポジトリ内で共通のイメージレイヤーを共有する Amazon ECR の最適化の利点が含まれていないからです。このフィールドは、より多くのストレージを消費しているリポジトリに関する洞察を提供し、それゆえ最適化の候補となり得る可能性があります。 イメージレベル : リポジトリ内の全てのイメージ / アーティファクトの主要な属性を提供します。 名前 説明 repositoryName リポジトリ名 imageTags イメージのタグ imagePushedAt イメージがプッシュされた日時 imageSize(MB) イメージサイズ (MB) imageScanStatus イメージのセキュリティスキャン状態 imageScanCompletedAt イメージが最後にスキャンされた日時 findingSeverityCounts イメージ内のセキュリティ検出結果の重要度別カウント lastRecordedPullTime イメージが最後にプルされた日時 daysSinceLastPull イメージが最後にプルされてから経過した日数 この情報はイメージとストレージ利用量を詳細に分析するのに役立ち、コスト削減のために削減可能な未使用イメージを特定するのに役立ちます。また、この内容はより効果的なライフサイクルポリシーを実施するための知見も提供します。例えば、1/ タグ付けされていないイメージをクリーンアップする、2/ リポジトリごとに一定数のイメージを残す、または 3/ 古いイメージを削除することです。 さらに、本レポートでは Amazon ECR 基本スキャンを利用しているユーザー向けに統合されたセキュリティ検出結果データを提供し、是正措置の優先順位付けを支援します。Amazon ECR 拡張スキャンを利用しているユーザーには、 Amazon Inspector を通じて利用可能なセキュリティ機能と検出結果の利用をおすすめします。 前提条件 このウォークスルーを進めるには、以下の前提条件を満たしている必要があります 環境にインストールされた Finch (またはその他のコンテナビルドツール) 環境にインストールされた AWS Command Line Interface (AWS CLI) このポリシー を持つ AWS Identity and Access Management (IAM) プリンシパル (ユーザーまたはロール) 環境にインストールされた Git ウォークスルー 以下の手順でこのソリューションを実行します。 コンテナイメージを設定する リポジトリをクローンし、コンテナをビルドします。 git clone https://github.com/aws-samples/amazon-ecr-cost-vulnerability-and-usage-reporting.git cd amazon-ecr-cost-vulnerability-and-usage-reporting finch build -t ecr-reporter:v0.1.0 . このコマンドは以下のパラメータでイメージをビルドします: -t ecr-reporter:v0.1.0 : イメージに名前 ecr-reporter とタグ v0.1.0 を付与します。名前とタグは任意の値に置き換え可能です。 . : カレントディレクトリにある Dockerfile をビルドコンテキストとして利用します。 Docker を利用する場合、コマンド内の finch を docker に置き換え、その他のパラメータはすべて同じままにします。 リポジトリーサマリーレポートを実行する 以下のコマンドを実行してリポジトリサマリーレポートを生成する finch run \ -e AWS_ACCESS_KEY_ID=$(aws --profile aws-samples configure get aws_access_key_id) \ -e AWS_SECRET_ACCESS_KEY=$(aws --profile aws-samples configure get aws_secret_access_key) \ -e AWS_DEFAULT_REGION=us-east-1 \ -e AWS_SESSION_TOKEN=$(aws --profile aws-samples configure get aws_session_token) \ -v /Path:/data \ ecr-reporter:v0.1.0 このコマンドでは、 aws-samples と言う名前のプロファイルを利用し、 AWS リージョン は us-east-1 に設定されています。また、コンテナが停止した後もレポートをローカル環境 (この場合は /Path ) に永続化するためにボリュームを設定しています。コンテナには設定可能なパラメータがさらにあります。 LOG_VERBOSITY : DEBUG 、 INFO 、 WARNING 、または ERROR を設定 (デフォルト: INFO ) DECIMAL_SEPARATOR : CSV 数値フォーマットのために . または , を設定 (デフォルト: .) EXPORT_FORMAT : レポート生成に利用する区切り形式。csv、json、または parquet を設定 (デフォルト: csv) コンテナを実行するための全パラメーターは、 GitHub リポジトリ で確認できます。 Docker を利用する際は、コマンド内の finch を docker に置き換え、その他のパラメーターは全て同じにしてください。 リポジトリサマリーレポートを確認する 指定された出力ディレクトリに、1 つの CSV ファイルが作成されます。レポートは以下のようになります: 図 1: サンプルコンテンツ付きのリポジトリサマリーレポート イメージレベルレポートを実行する リポジトリ foobar のイメージレベルレポートを生成するには次のコマンドを実行する finch run \ -e AWS_ACCESS_KEY_ID=$(aws --profile aws-samples configure get aws_access_key_id) \ -e AWS_SECRET_ACCESS_KEY=$(aws --profile aws-samples configure get aws_secret_access_key) \ -e AWS_DEFAULT_REGION=us-east-1 \ -e AWS_SESSION_TOKEN=$(aws --profile aws-samples configure get aws_session_token) \ -e REPORT=foobar -v /Path:/data \ ecr-reporter:v0.1.0 イメージレベルレポートを生成するには、環境変数 REPORT にリポジトリ名を設定します。コンテナを実行するための全パラメーターは GitHub リポジトリ で確認できます。 Docker を利用する際は、コマンド内の finch を docker に置き換え、その他のパラメーターは全て同じにしてください。 イメージレベルレポートを確認する 指定した出力ディレクトリに、このレポートを含む 1 つの CSV ファイルが作成されます。レポートは次のようになります。 図 2: サンプルコンテンツ付きのイメージレベルレポート 更なる取り組み (任意) 以下のステップは任意です。 レポート生成をスケジュールする このコードは、AWS コンテナサービスにおいて 1) Amazon Elastic Kubernetes Service (Amazon EKS) における cron ジョブ ( 手順 を参考に設定可能)、または 2) Amazon Elastic Container Service (Amazon ECS) でスケジュールされたタスクとして定期的に実行できます。 レポートを分析するために Amazon Athena を利用する レポートを Amazon S3 に保存することもでき、 Amazon Athena を利用してクエリを実行できます。これを行うには、特定のバケットにオブジェクトをアップロードする権限を付与する ポリシー を IAM プリンシパルに設定する必要があります (ポリシー作成時にバケット名を指定してください) 。ポリシーをアタッチしたら、環境変数 AMAZON_S3_BUCKET にバケット名を設定することで各レポートを生成できます。 finch run \ -e AWS_ACCESS_KEY_ID=$(aws --profile aws-samples configure get aws_access_key_id) \ -e AWS_SECRET_ACCESS_KEY=$(aws --profile aws-samples configure get aws_secret_access_key) \ -e AWS_DEFAULT_REGION=us-east-1 \ -e AWS_SESSION_TOKEN=$(aws --profile aws-samples configure get aws_session_token)] \ -e AMAZON_S3_BUCKET=<s3 bucket name> \ -e EXPORT_FORMAT=csv \ ecr-reporter:v0.1.0 Docker を利用する際は、コマンド内の finch を docker に置き換え、その他のパラメーターは全て同じにしてください。 レポート生成後、Athena を利用してその内容を分析できます。この例では、事前に Athena の設定が完了していることを前提としています。もし設定が完了していない場合は、この はじめに ガイドに従って設定を完了し、その後戻ってきて続きを進めることができます。 リポジトリ概要レポート用スキーマを格納するデータベース ecr_repository_summary を作成します。Athena クエリエディタで次のクエリを実行する CREATE DATABASE IF NOT EXISTS ecr_repository_summary; リポジトリサマリーレポートのテーブルスキーマを作成する リポジトリサマリーレポートの詳細を表示するには、Amazon S3 に保存されているレポートのスキーマを保持するテーブルをこのデータベース内に作成する必要があります。これを実行するには Athena クエリエディタで次のクエリを実行できます。 CREATE EXTERNAL TABLE IF NOT EXISTS `repo_summary` ( `repositoryname` string COMMENT '', `createdat` string COMMENT '', `scanonpush` boolean COMMENT '', `totalimages` bigint COMMENT '', `totalsize(mb)` double COMMENT '', `hasbeenpulled` boolean COMMENT '', `lastrecordedpulltime` string COMMENT '', `dayssincelastpull` bigint COMMENT '') ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3://<s3 bucket name>/' TBLPROPERTIES ``( 'areColumnsQuoted'='false', 'classification'='csv', 'columnsOrdered'='true', 'compressionType'='none', 'delimiter'=',', 'skip.header.line.count'='1', 'typeOfData'='file' <s3 bucket name> は、生成されたレポートを保存するために作成したバケット名に置き換えることを覚えておいてください。 このクエリを実行後、 repo_summary という名前の新しいテーブルが作成されます。このテーブルをクエリすることで、生成してバケットに保存したリポジトリサマリーサポート CSV におけるデータのレコードを取得できます。 新しいテーブルをクエリしてデータを確認する SELECT * FROM "ecr_repository_summary"."repo_summary" limit 100; この出力は以下のようになります。 図 3: Amazon Athena を利用して SQL でリポジトリサマリーレポートを操作する インサイトを収集し、分析する データをクエリする容易な方法ができたため、これを使用してコスト最適化、健全性、Amazon ECR リポジトリのメンテナンスに関する情報に基づいた意思決定に役立つ関連性のある洞察を得ることができます。例えば、以下のクエリを利用すると、ストレージ利用料が最も多いリポジトリを素早く特定できます。 SELECT * FROM "ecr_repository_summary"."repo_summary" ORDER BY "totalsize(mb)" DESC limit 10; あるいは、一度もプルされたことのないイメージを持つものを見つけることもできます。 SELECT * FROM "ecr_repository_summary"."repo_summary" WHERE hasbeenpulled = false limit 10; あるいは、1 年以上取得されていないものを探して、古いリソースを削除することもできます。 SELECT * FROM "ecr_repository_summary"."repo_summary" WHERE dayssincelastpull > 365 ORDER BY dayssincelastpull DESC limit 10; 言い換えれば、このデータで好きなだけ創造性を発揮できるということです！この手順では、CSV 出力形式を利用しました。Parquet や JSON の利用も同様ですが、若干の変更が必要になる場合があります (本記事の範囲外です)。 クリーンアップ レポートを Amazon S3 に保存し、Amazon Athena を利用して分析する場合、AWS アカウントに課金されます。もし、あなたが不要な課金が発生しないようにクリーンアップすることを決めたなら、このデプロイ中に作成された全ての AWS リソースを削除してください。 Amazon S3 バケットとコンテンツを削除する aws s3 rb s3://<bucket name> --force Athena リソースをクリーンアップする # Delete Athena table using AWS CLI aws athena start-query-execution \ --query-string "DROP TABLE IF EXISTS \`ecr_repository_summary\`.\`repo_summary\`;" \ --result-configuration OutputLocation= s3://<s3 bucket name>/ # Delete Athena database using AWS CLI aws athena start-query-execution \ --query-string "DROP DATABASE IF EXISTS \`ecr_repository_summary\`;" \ --result-configuration OutputLocation= s3://<s3 bucket name>/ IAM ユーザーやロールにアタッチされた IAM ポリシーをデタッチする aws iam detach-user-policy --user-name <user name> --policy-arn <policy ARN> aws iam detach-role-policy --role-name <role name> --policy-arn <policy ARN> おわりに パフォーマンスとイノベーションを維持しながら AWS コストを最適化することは、効果的なオブザーバビリティによって実現可能です。Amazon ECR に関するインサイトを活用することで、組織はコンテナ運用を強化するデータドリブンな意思決定を行うことができます。リポジトリに関する詳細な可視性 (コスト内訳、利用状況メトリクス、セキュリティスキャン結果、コンプライアンス状況など) により、チームはイノベーションを加速させながらコンテナインフラストラクチャを合理化する準備が整います。 本記事で提供されているサンプルコードを利用することで、Amazon ECR リポジトリに関するインサイトを提供するだけでなく、それぞれのイメージの詳細まで深く掘り下げることができる包括的なレポートを生成できます。これらのレポートにより、コスト効率性、効率的なリソース利用、セキュリティの強化を目的として Amazon ECR の利用状況を積極的にレビューし、最適化することが可能になります。ぜひ、サンプルコードをお試しいただき、フィードバックをお寄せください。皆様のご意見は、AWS コンテナコミュニティにより良いサービスを提供するための改善と強化に役立ちます。 ご質問、機能リクエスト、プロジェクトの貢献については GitHub リポジトリをご覧ください 。

本記事は、2025 年 9 月 4 日に実施した、ファッション、アパレル、コンビニエンスストアといった事業を展開されている小売企業のお客様を対象とした、AI エージェント活用ワークショップの内容をご報告するものです。本ワークショップでは、これらの業界の共通項である、店舗運営に焦点を当てて、店舗業務における課題を 生成 AI や AI エージェントを活用することでどのように解決できるかについてみんなで考え、アイデア出しから実装までの流れを体験いただくことを目的としています。 ワークショップの概要 ワークショップには、15 社 30 名の方にご参加いただきました。IT / DX 部門のみならず、企画、事業開発、AI 推進、元店長など、多種多様な所属部門、経歴のお客様にご参加いただきました。 主なアジェンダは、下記の通りです。 生成 AI の今　- 汎用的→特定業務を支援するエージェント – ハンズオン　- 店舗向け AI エージェントを体験してみよう – ハッカソン　- 店舗業務を効率化しよう – 生成 AI の今　- 汎用的→特定業務を支援するエージェント – [ 資料 ] アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 平井 健治 2025 年の今、企業における生成 AI の活用は汎用的なチャットツールから、特定業務を支援する AI エージェントの活用へと進化している段階にあります。 PwC 社のレポート によると、生成 AI の活用において、米国と比較し日本は期待を下回るケースが多く見られます。その要因として知識やスキル不足による具体的なユースケース検討の停滞が挙げられる一方で、期待以上の成果が出たケースとして日米間で共通している要因は「ユースケース設定」にあることが明らかになっています。 AWS は、多くの汎用ユースケースに対応可能な生成 AI サンプルソリューション「 Generative AI Use Cases （略称 GenU ）」をオープンソースで公開しており、ユーザーはユースケースビルダー機能を利用することで、ノーコードで独自のユースケースも構築できることをご紹介しました。データ活用のユースケースにおいては、自然言語でデータ分析や新たなダッシュボード生成を行う Amazon Q in QuickSight や、追加学習なしに高精度な時系列予測を実現する基盤モデル Chronos-Bolt について、デモを通じてご紹介しました。 そして店舗業務に目を向けると、これらのユースケース以外にも、発注、検品、シフト作成など様々なタスクがあり、ここに AI エージェントの活用を検討しましょう、と参加者に投げかけました。注意すべき点として、エージェント 1 つに多数の役割を持たせると、ハルシネーションの発生確率を高めたり、後からの機能追加が困難になるため、エージェントを役割で分けて、複数の業務特化エージェントが連動するマルチエージェント構成の必要性について説明しました。 ハンズオン　- 店舗向け AI エージェントを体験してみよう – [ 資料 ] アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 喜多 望 ハンズオンでは、店舗業務で重要な在庫管理と売上分析する AI エージェントの構築を体験いただきました。AI エージェントは独自の在庫管理 DB や売上分析システムと連携した処理を行うことができます。参加者は、ノーコードで AI エージェントを開発できる Amazon Bedrock Agents を利用し、在庫確認を行うエージェントと売上分析を行うエージェントを作り、そして、これらのエージェントと連携し取りまとめる Supervisor エージェントを構築しました。さらに、GenU から Supervisor エージェントを呼び出せるように設定することで、 Web アプリケーションから自然言語で店頭在庫の確認や売上分析を行えるチャット環境を短時間で構築いただきました。AI エージェントがユーザーからのリクエストを理解してタスクを細分化し、業務特化のエージェントと連携して、複合的な処理を完結できるということを体験いただきました。 ハッカソン　-店舗業務を効率化しよう – [ 資料 ] アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 濱上 和也 「ユースケースの解像度が高ければ、実用的な AI アプリは作れる」ということを体験いただくため、店舗業務を効率化する AI エージェントを具体化するハッカソンを行いました。現実世界の業務には、単純なワークフローもあれば、複雑な処理の分岐や判断を必要とするケースなど多岐に渡り、それぞれの業務フローに対して AI はどのように機能できるか、人間との役割分担はどうあるべきか、について問いかけました。AI から人間に判断を求めるユースケースの具体例として、FAQ ページを更新する AI エージェントのデモをお見せし、これを実現する AWS アーキテクチャの概要と、 実は Amazon Q Developer がほぼ全て開発したことについて触れ、ユースケースの解像度が高ければ、開発自体のハードルは今はかなり低いということを説明しました。 ハッカソンでは、今回のテーマである店舗業務の課題の具体例を示しながら、誰のどんな業務を解決するのか、グループ内で話し合い、ユースケースを 1 点に絞り込んでいただきました。そのユースケースで活用できる AI エージェントアプリケーションを利用者視点で 5W1H を定義し、必要となるデータやツール、連携方式について整理いただきました。 このワークでは、先ほどのハンズオンで作成した GenU の各種機能も活用し、要件の解像度を高める手法も実践しました。例えば、 議事録生成 を使い、ディスカッション中の音声から 利用者視点の 5W1H を自動整理させたり、 ダイアグラム生成 でシステム関連図の作成や、 画像生成 で利用シーンをビジュアル化、 チャット でシステム要件定義を行うなど、生成 AI の力を借りることで議論から効率良く解像度を上げていきました。 そして、これらの情報をインプットに、 Amazon Q Developer を使って画面プロトタイプの開発にも挑戦いただきました。全てのグループが画面プロトタイプを作成し、実用的な AI アプリケーションのアイデアを全体で発表いただきました。限られた時間でしたが、参加いただいたお客様は店舗業務における具体的な AI 活用のユースケースを特定し、その検討過程においても AI を活用しながら、アイデアからアプリケーション実装への実践的な流れを体験いただきました。 お客様の声 アンケートでは、CSAT 4.58 ととても高い評価をいただくことができました。「業務効率化を図れるような機能を体験することができ、過去実店舗に在籍していた身としても、非常に興味深く、店舗に実装されたらどれだけのことができるだろうかと、思い描くのが楽しい時間でした」、「ハッカソンで出ていた様々な案はいずれも実際の業務に活用できそうだと思いました」、「店長エージェントの実装を検討する中で、自社ソリューションの組み合わせなど、試したいアイデアが出ました」、「他社の方の事例を聞いたり、小売業界ならではの共通した課題への気づきを得られてかなり勉強になりました」、「 AI エージェントを活用するために今日から行動を起こしてみます」など多数のポジティブなコメントと、次回開催に対する期待の声をいただくことができました。 まとめ ワークショップを通じて、各グループ計 6 つの具体的なユースケースを特定することができました。ユースケースの内訳として、店長視点のものが 3 つ（売れ筋商品の補充発注、シフト変更調整、週報の作成）、店舗スタッフ視点のものが 3 つ（店舗コンシェルジュ、商品ポップ作成、滞留在庫商品の広告作成）でした。偶然にもグループ間でテーマの被りがなく、何よりどのグループも議論と実装で盛り上がり、もっと時間が欲しかったというコメントをたくさんいただきました。これは、テーマを店舗業務に絞ったことの効果と AI ツールの活用、そして企業をまたぐお客様同士のコミュニケーションによって、お客様の気づきと満足度に大きく寄与したものと考えています。お客様の声に耳を傾けて、今後も期待に応える企画を考えてご提供していきます。 著者 / ワークショップ提供コアメンバーについて 平井 健治（Kenji Hirai） 流通・小売のお客様を担当するソリューションアーキテクトです。Amazon Redshift などアナリティクス関連の技術支援も行っています。 喜多 望（Nozomi Kita） 流通・小売のお客様を担当するソリューションアーキテクトです。好きな AWS サービスは Amazon GuardDuty で、業界問わず、Security 分野の技術⽀援も行っています。趣味はゲームとお笑いライブの鑑賞です 西村 忠巳（Tadami Nishimura） 流通・小売のお客様を担当するソリューションアーキテクトです。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。 濱上 和也（Kazuya Hamagami） 流通・小売のお客様を担当するソリューションアーキテクトです。好きな AWS サービスは Amazon Connect で、業界問わずコンタクトセンター関連の技術支援も行っています。最近は、Amazon Nova Canvas でバーチャル試着を楽しんでいます。

8 月、 Amazon Web Services (AWS) は 2025年 Gartner Magic Quadrant において、戦略的クラウドプラットフォームサービス (SCPS) 部門でリーダー として認められました。ガートナーは、15 年連続で AWS をリーダーとして位置付けました。 2024 年度は、 Gartner の AIコードアシスタント 、 クラウドネイティブアプリケーションプラットフォーム 、 クラウドデータベース管理システム 、 コンテナ管理 、 データ統合ツール 、 Desktop as a Service (DaaS) 、 データサイエンスおよび機械学習プラットフォーム の Magic Quadrant、および SCPS において、AWSがリーダーとして選定されました。2025年度には、Gartner の Magic Quadrant のサービスとしての Contact Center as a Service (CCaaS 、 Desktop as a Service 、 データサイエンスおよび機械学習 (DSML) プラットフォームでもリーダーとして選定されました。AWS がお客様に最も幅広く、かつ最も奥深いサービスを提供していることを意味すると、弊社は強く信じています。 9 月 15 日、最新の Magic Quadrant レポートにて、AWS がより多くのクラウドテクノロジー市場、具体的にはクラウドネイティブアプリケーションプラットフォーム (別名：クラウドアプリケーションプラットフォーム) とコンテナ管理でリーダーに選出されたことをご報告できることを嬉しく思います。 2025年 Gartner Magic Quadrant のクラウドネイティブアプリケーションプラットフォーム部門 AWS は Gartner Magic Quadrant のクラウドネイティブアプリケーションプラットフォーム部門で、 2 年連続でリーダーに選出されました。AWS は「実行能力（Ability to Execute）」において、最も高い位置に付けられました。Gartner はクラウドネイティブアプリケーションプラットフォームを、アプリケーション向けのマネージドアプリケーションランタイム環境と、クラウド環境におけるアプリケーションやアプリケーションコンポーネントのライフサイクルを管理するための統合機能を提供するプラットフォームと定義しています。 次の画像は、2025 年版クラウドネイティブアプリケーションプラットフォームの Magic Quadrant の図です。 弊社の包括的なクラウドネイティブアプリケーションポートフォリオ ( AWS Lambda 、 AWS App Runner 、 AWS Amplify 、 AWS Elastic Beanstalk ) は、継続的なイノベーションと広範な AWS サービスポートフォリオ全体にわたる緊密な統合によって実証されているように、強力な AI 機能を備えた最新のアプリケーションを構築するための柔軟な選択肢を提供します。 AWS ソリューションライブラリ で利用できる包括的なドキュメント、リファレンスアーキテクチャ、規範的なガイダンス、および特定の要件に基づく Amazon Q による AI を活用したコンテキスト応じた推奨事項を通じて、サービスの選択を簡素化できます。AWS Lambda は、可能な限り最高のサーバーレス体験を提供するために AWS 向けに最適化されていますが、サーバーレスコンピューティングの業界標準に準拠しており、一般的なプログラミング言語やフレームワークをサポートしています。AI/ML、エッジコンピューティング、エンタープライズ統合などの高度な特徴量を含む、必要なすべての特徴量を AWS 内で見つけることができます。 Amazon Bedrock によるサーバーレス推論や、 Amazon SageMaker による 人工知能および機械学習 (AI/ML) のトレーニングと管理用に、これらのコンピューティングサービスを統合することで、 生成 AI のエージェントやアプリケーションを構築、デプロイ、およびスケールすることができます。 詳細については、 2025 年 Gartner Magic Quadrant のクラウドネイティブアプリケーションプラットフォーム部門 の完全版レポートをご覧ください。 2025年 Gartner Magic Quadrant のコンテナ管理部門 2025 年 Gartner Magic Quadrant のコンテナ管理部門において、AWS は 3年連続でリーダーに選出され、「ビジョンの完全性」が最も上位に位置付けられました。Gartner は、コンテナ管理をコンテナ化されたワークロードのデプロイと運用をサポートするサービスと定義しています。このプロセスには、デプロイ、スケーリング、運用を含むコンテナのライフサイクル全体をオーケストレーションおよび監視して、異なる環境で効率的かつ一貫したパフォーマンスを確保することが含まれます。 次の画像は、2025年のコンテナ管理に関する Magic Quadrant の視覚的な表現です。 AWS コンテナサービス は、AWS ネイティブソリューションとオープンソース技術を活用したフルマネージドコンテナオーケストレーションを提供し、Kubernetes からネイティブオーケストレーターまで、幅広いデプロイオプションに対応しています。 Amazon Elastic Container Service (Amazon ECS) および Amazon Elastic Kubernetes Service (Amazon EKS) を利用できます。どちらも AWS Fargate でサーバーレスコンテナのデプロイに使用できます。さらに、EKS Auto Mode は、インフラストラクチャのプロビジョニング、最適なコンピューティングインスタンスの選定、コンテナ化されたアプリケーションのリソースの動的なスケーリングを自動的に行うことで、Kubernetes の管理を簡素化します。 EKS Hybrid Nodes と ECS Anywhere を使用して、オンプレミスとエッジのインフラストラクチャを AWS コンテナサービスに接続できます。また、 EKS Anywhere を使えば、AWS によってサポートされる、完全に切り離された Kubernetes 環境を利用することもできます。柔軟なコンピューティングとデプロイのオプションにより、運用負荷を軽減し、イノベーションに集中して、より迅速にビジネス価値を高めることができます。 詳細については、 2025 年 Gartner Magic Quadrant のコンテナ管理部門 の完全版レポートをご覧ください。 – Channy 原文は こちら です。 Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価または他の認定を受けたベンダーのみを選定するようテクノロジーユーザーに助言するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、本調査に関して、明示または黙示を問わず、商品性または特定目的適合性に関する保証を含め、一切の保証を放棄します。 GARTNER は Gartner の登録商標およびサービスマークであり、Magic Quadrant は Gartner, Inc. および/またはその米国および他国の関連会社の登録商標であり、許可を得て使用されています。All rights reserved.

9 月 8 日週、エージェンティック AI SDK の AWS オープンソースである Strands Agents は、 2025 年 5 月のプレビュー版リリース からわずか 4 か月足らずで、ダウンロード数 100 万回を突破し、3,000 個以上の GitHub スターを獲得しました。Strands Agents を使用すると、数行のコードで本番環境に対応したマルチエージェント AI システムを構築できます。 私たちは、マルチエージェントパターン、A2A プロトコル、Amazon Bedrock AgentCore のサポートなど、特徴量を継続的に改善してきました。Strands Agents を使用してインテリジェントエージェントの構築を開始する際に役立つ サンプル実装のコレクション を使用できます。私たちは、バグレポート、新特徴量、修正、追加ドキュメントなど、プロジェクトへの 貢献やフィードバック をいつでも歓迎します。 ここでご紹介するのは、 エージェンティック AI の未来と、科学者が問い続ける疑問 (エージェント間のコミュニケーション、コンテキストの理解、常識的な推論など) に関する Amazon Science の最新の研究記事です。エージェンティック AI の技術的なトピックについては、身近な例 (ドアを開けたままにするか閉めたままにするか、鍵をかけたままにするか開けたままにするかといった個人的な行動) を用いると理解することができます。 9 月 8 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon EC2 M4 および M4 Pro Mac インスタンス – 新しい M4 Mac インスタンスは M2 Mac インスタンスと比較して最大 20% 優れたアプリケーションビルドパフォーマンスを提供し、M4 Pro Mac インスタンスは M2 Pro Mac インスタンスと比較して最大 15% 優れたアプリケーションビルドパフォーマンスを提供します。これらのインスタンスは、iOS、macOS、iPadOS、tvOS、watchOS、VisionOS、Safari などの Apple プラットフォーム向けのアプリケーションの構築とテストに最適です。 Visual Studio Code (VS Code) での LocalStack 統合 – LocalStack を使用すると、ツールを切り替えたり、複雑なセットアップを管理したりすることなく、使い慣れた VS Code インターフェイスを使用してサーバーレスアプリケーションをローカルでエミュレートおよびテストできるため、ローカルサーバーレス開発プロセスが簡素化されます。 AWS Cloud Development Kit (AWS CDK) リファクタリング (プレビュー) – デプロイされたリソースの状態を維持したまま、コンストラクトの名前を変更したり、スタック間でリソースを移動したり、CDK アプリケーションを再編成したりできます。CDK リファクタリングは、 AWS CloudFormation のリファクタリング機能 と自動マッピング計算を使用することで、コードの再構築中に意図しないリソース置換が発生するリスクを排除します。 AWS CloudTrail MCP サーバー – 新しい AWS CloudTrail MCP サーバーにより、AI アシスタントは、自然言語による対話を通じて、API コールの分析、ユーザーアクティビティの追跡、および AWS 環境全体の高度なセキュリティ分析を行うことができます。AWS サービスリソースを使用するための AWS MCP サーバー は他にもあります。 Amazon CloudFront の IPv6 オリジンのサポート – アプリケーションは IPv6 トラフィックをオリジンまで送信できるため、IPv6 導入に関するアーキテクチャ要件や規制要件を満たすことができます。エンドツーエンドの IPv6 サポートにより、IPv6 ネットワーク経由で接続するエンドユーザーのネットワークパフォーマンスが向上し、オリジンインフラストラクチャの IPv4 アドレス枯渇の懸念も解消されます。 AWS のお知らせに関する詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 手のひらに収まる都市 – AWS Trainium チップの設計者が都市計画者さながらに思考し、ナノメートル単位で最適化を重ねた結果、光速に近い速度でデータを移動させる仕組みを実現した経緯を解説するインタラクティブ特徴量をご利用ください。 ソフトウェア開発ツールとプラクティスの有効性の測定 – Amazon 開発者が AI ツールを採用する前に具体的な課題を特定し、当社のソフトウェアサービスコストフレームワーク (CTS-SW) を使用して前年比で 15.9% のコスト削減を実現した経緯についてお読みいただけます。適切な問題に最初に焦点を合わせて、デプロイ頻度を増やし、手動による介入を 30.4% 削減しました。 AWS Cloud Club Captain 会員募集中 – AWS Cloud Club Captain の一員になって、拡大中の学生クラウド愛好家のネットワークにご参加ください。 Captain の一員になると、リーダーシップスキルを磨きながら、イベントの企画やクラウドコミュニティの構築を行うことができます。応募受付期間は 2025 年 9 月 1 日から 28 日までです。 近日開催予定の AWS イベント カレンダーをチェックして、近日開催予定の AWS イベント、 AWS re:Invent 、 AWS Summits にぜひサインアップしてください。 AWS AI Agent Global Hackathon – 弊社の強力な生成 AI スタックを深く掘り下げて、真に素晴らしいものを創り出すチャンスです。9 月 8 日から 10 月 20 日までの期間、AWS の AI サービススイートを使用して AI エージェントを作成する機会が与えられ、45,000 USD を超える賞金と独占的な市場参入のチャンスを賭けて競い合っていただきます。 AWS Gen AI Lofts – 限定セッションで AWS AI 製品とサービスについて学び、業界をリードするエキスパートと交流し、投資家や同業者との貴重なネットワーキングの機会を得ることができます。日程は、 メキシコシティ (9 月 30 日～10 月 2 日)、 パリ (10 月 7 日～21 日)、 ロンドン (10 月 13 日～21 日)、 テルアビブ (11 月 11 日～19 日) です。最寄りの都市で登録してください。 AWS Community Days – 世界各地のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 アオテアロア と ポーランド (9 月 18 日)、 南アフリカ (9 月 20 日)、 ボリビア (9 月 20 日)、 ポルトガル (9 月 27 日)、 ドイツ (10 月 7 日)、 ハンガリー (10 月 16 日) です。 今後開催される AWS イベント と AWS スタートアップイベント をすべて閲覧できます。 9 月 15 日週のニュースは以上です。9 月 22 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

はじめに アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの黒田です。 通信業界の企業様を対象に、2025 年 4 月 24 日に AWS Startup Loft Tokyo で「AWS GameDay for Telecom: Winning the DDoS Game」を開催しました。近年増加傾向にあり日本の通信事業者共通の課題である「DDoS 攻撃」への対策をテーマとして、AWS のサービスでどう対応していくのか体験しながら学ぶイベントです。1 チーム最大 3 名にてエントリー頂き、13 企業 / 29 チーム / 84 名のエンジニアの参加する、通信事業者横断のチーム対抗戦となりました。本記事では、当日の概要を皆様にご紹介します。 AWS GameDay とは？ AWS GameDay は、チーム毎の環境で AWS ソリューションを利用して現実世界の技術的問題を解決することを参加者に課題として提示する ゲーム化された学習イベントです。本番環境に近い条件下でシステム障害やセキュリティインシデントを模擬的に発生させ、実際の障害対応と同様の手順で問題解決に取り組み、システムの復旧やインシデント対応を体験します。この演習により、チームは障害対応スキルの向上、システム間の依存関係の把握、組織全体のレジリエンス文化の醸成を図ることができます。詳細は こちら を参照ください。 図1: AWS GameDay for Telecom の様子 Winning the DDoS Game シナリオ概要 本 AWS GameDay for Telecom では、近年急増する DDoS 攻撃への対策をテーマに、参加者がチームを組んで架空の企業「ユニコーンレンタル株式会社」のインフラを守るという設定で、実践的なセキュリティ対策を題材としました。 今回の Winning the DDoS Game シナリオでは、以下のような架空の状況が設定されました： ユニコーンレンタル社が新サービスをローンチし、注文サイトに通常の 100 倍以上の勢いでお客様からのアクセスが殺到 喜びも束の間、大規模な DDoS 攻撃によりサイトがダウン。サイトには突如 “503 Service Temporarily Unavailable” エラーが表示され、ユーザーからの批判が殺到 サイトはいつの間にか直り、サイトにアクセス可能になった。 そこで緊急対応としてお詫びキャンペーンセールを開始 図2: オープニング説明 昨日の失敗を取り戻すべく、社長からの大号令で特別セールキャンペーン開催の決定がなされました。そこで前述のサイトダウンのようにならない様に、たまたま新入社員として入社することになった参加者の皆様には、引継ぎ資料として渡されたアーキテクチャ図を基にこの危機的状況から会社を救うべく、適切な AWS サービスを活用して DDoS 対策を実施して頂きました。 図3: 引継ぎ資料として渡されたアーキテクチャ図 DDoS 対策に有効な AWS サービス (1) AWS Shield Advanced: レイヤー3-4 の保護 AWS Shield Advanced は、DDoS 攻撃の可視化レポートや専用 CloudWatch メトリクス、 AWS WAF と連携したアプリケーション層の自動緩和機能を提供します。24 時間 365 日体制の DDoS 対策専門チーム（Shield レスポンスチーム）からの支援が受けられることも大きなメリットです。保護対象は Elastic Load Balancing (ELB) 、 Amazon Route 53 、 Amazon CloudFront 等です。オンプレミスの HTTP/HTTPS ワークロードも CloudFront 経由で DDoS 保護が可能です。 図4: AWS Shield Standard と Shield Advanced の違い (2) AWS WAF: レイヤー7 の保護 AWS WAF は、Web アプリケーションに送信される HTTP/HTTPS リクエストを監視し、コンテンツへのアクセスを制御するWebアプリケーションファイアウォールです。Amazon CloudFront、 Application Load Balancer 、 Amazon API Gateway 、 AWS AppSync 、 Amazon Cognito 、 AWS App Runner 、などのリソースを保護できます。WebACL または保護パックでルールを定義し、IP アドレス、地理的位置、リクエストヘッダー、SQL インジェクション、クロスサイトスクリプティングなどの条件に基づいて、リクエストの許可・ブロック・カウント・CAPTCHA 実行を制御します。 図5: AWS WAF シナリオを進める上での工夫 本 GameDay for Telecom では生成 AI ツール等を参加者にご活用頂きながら、シナリオを進める上でのチーム内調査・解析の補佐、コミュニケーションの活性化、リアルタイムな競技進捗の可視化による企画側の盛り上げの工夫を施しました。 Generative AI Use Cases JP（略称 GenU*、AWS 独自の生成AIツール）の活用による AI 支援型の補佐 Slackを活用したチーム内/間コミュニケーション リアルタイムスコアボードによる競技進捗の可視化 *GenU は OSS として公開: https://github.com/aws-samples/generative-ai-use-cases-jp 図6: GenU 結果と上位入賞チームのご紹介 シナリオを順調に進めていただき、多くのポイントを獲得なされた上位入賞チームをご紹介します。 図7: GameDay for Telecom 結果 第1位: Team クラソル (Score: 293,700) 荒井 冬樹 氏 小林 優輝 氏 後藤 大輝 氏 第2位: dポマ (Score: 293,650) 伊藤 幹人 氏 酒井 芳章 氏 與那嶺 正美 氏 第3位: Foo (Score: 232,300) 岡田 誠 氏 岡本 康宏 氏 福嶋 慶介 氏 （氏名: 五十音順) 今回の AWS GameDay for Telecom: Winning the DDoS Game の結果ですが、1位と 2位のチームがわずか 50 ポイントという僅差で競り合う、最後の最後まで目が離せない白熱した展開となりました。上位 2 チームは 29 万ポイントを超える高得点を記録し、DDoS 攻撃への対応力の高さを示しました。3位チームも 23 万ポイントを獲得し、全体として参加チームが高い技術力を発揮した対抗戦だったと思います。 まとめ 本 GameDay for Telecom を通じて、参加者の皆様には実践的な DDoS 対策スキルを身につけていただくとともに、AWS の最新セキュリティソリューションについてのご理解を深めて頂きました。また、「実際に行っている障害調査の実施」、「リアリティのあるやり取りを交えての原因分析」、「普段一緒に仕事をしない同僚や他社の方々と同じ目標に向かっての競争・協力」、といった AWS GameDay ならではの価値もご体験頂けました。本イベントで得られた知見は、以下のような実務での課題解決にご活用いただけるかと考えております。 大規模 DDoS 攻撃への防御態勢の構築 インシデント発生時の優先順位付けと対応手順の確立 チーム間連携とコミュニケーションの最適化 AWS 最新セキュリティサービスの実践的活用 今後も AWS は、このような実践的な学習機会を提供し続け、お客様のセキュリティ対策強化を支援して参ります。 このブログの著者 黒田 由民 (Yoshimi Kuroda) 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 ソリューションアーキテクト

このブログ記事は、AWS ソリューションアーキテクトの吉澤 稔と都築 了太郎が執筆し、住信 SBI ネット銀行様が監修しています。 住信 SBI ネット銀行株式会社（以下、住信 SBI ネット銀行）は、勘定系システムの更改に向けてアマゾン ウェブ サービス（以下、AWS）のクラウド環境を採用することを決定しました。2028 年初旬の本番稼働を目指し、AWS 上での次世代勘定系システムの設計・構築が進められており、移行完了後は、同行の主要システム全てが AWS 上で稼働することとなります。将来的なスケーラビリティを見据えた、デジタルバンク向けの次世代クラウド勘定系アーキテクチャーへの移行により、3,000 万口座を超える膨大なデータボリュームへの対応が可能となるほか、今後の事業拡大にも柔軟に対応できる設計が実現されます。 今後も、AWS を推奨クラウドプロバイダーに選定する住信 SBI ネット銀行は、AWS との連携をさらに強化し、柔軟性と拡張性に優れたクラウドや最先端の生成 AI 技術などを活用して、新たなビジネス価値創出とイノベーションを加速させます。 2017 年クラウドファーストを決定、AWS への移行開始 インターネット専業銀行として 2007 年に開業した住信 SBI ネット銀行は、「銀行を超えたテックカンパニー」を目指し、最先端の IT を駆使したイノベーションにより金融サービスの変革を推進しています。住信 SBI ネット銀行は、2017 年に 「クラウドファースト」 の意思決定を行い、勘定系以外の商用システムの AWS 移行を開始しました。AWS 選定の理由として住信 SBI ネット銀行は、FISC（金融情報システムセンター）の安全対策基準への対応に関する情報や第三者による認証、内部統制、監査に関するポリシーや結果が外部に公開されていることによる信頼性の高さ、AWS の開発力、比較的容易にエンジニアが確保できることにより運用体制の構築がスムーズに進められることなどを挙げています。また、システムの職員には AWS 認定ソリューションアーキテクトの資格取得を必須としており、AWS のサービスを積極的に活用できる体制を整えています。2020 年には、オンプレミスにあったインターネットバンキングシステムの Oracle データベース（DB）を、Amazon Aurora PostgreSQL へと移行完了しました。その後、2023 年邦銀で初めて（同年 8 月時点）、AWS のアジアパシフィック （東京） リージョン（以下、東京リージョン）およびアジアパシフィック （大阪） リージョン（以下、大阪リージョン）を活用したマルチリージョンによる冗長化を実施、インターネットバンキングシステムの可用性の向上を実現しています。 モダナイゼーションへの挑戦 住信 SBI ネット銀行において、2020 年に勘定系以外の商用システムを AWS に移行完了し、インフラ面でのハードウェア調達や構築のボトルネックが解消されました。しかし、2007 年の開業以降、顧客向けサービス開発を優先し機能を集約しながら開発した結果、プログラムの構造が複雑化し、事業のさらなる拡大に支障をきたすケースも生じてきました。そこで、これらの課題を解決し、持続的な成長を実現するため、住信 SBI ネット銀行はモダナイゼーションに着手しました。内製開発でモダナイゼーションを進めるうえで、必要な専門知識などを提供する AWS の　「DevTX プログラム」　を採用しました。同プログラムには、PACE（prototyping and cloud engineering）専門チームとの伴走により、イベントストーミング手法を用いてドメイン駆動設計のファーストステップを実現し、技術的負債の解消と組織文化変革を同時に加速しています。現在、モダナイゼーションの PoC を進めるための準備をし、顧客サービス向上や事業規模拡大に合わせた拡張性の確保を目指し、インターネットバンキングをはじめ主要システムのモダナイゼーションを進めています。 勘定系システムの AWS 移行へ 2025 年 9 月、住信 SBI ネット銀行は、勘定系システムを AWS のクラウド環境に全面移行することを決定しました。住信 SBI ネット銀行は、勘定系システムの更改に向けて、2024 年より既存のオンプレミス環境の継続も含め、拡張性・信頼性・可用性・セキュリティ・費用面などを含む複数の観点から総合的に検討を重ねました。その結果、同行において AWS の豊富な導入実績がありノウハウが蓄積されていたこと、AWS スキルを持つ人材が市場に豊富であること、安全性などから、最終的に AWS への移行を決定しました。すでに運用中の東京リージョンおよび大阪リージョンの東阪マルチリージョンに勘定系システムが加わることにより、システム処理の効率化・俊敏性の向上に加え、障害発生時の迅速な切り替えや災害時の業務継続など、一層のレジリエンシーの向上を実現します。 勘定系システムの AWS 移行の検討において住信 SBI ネット銀行は、AWS が実施するオペレーショナル・レジリエンス ワークショップに参加し、AWS で実現するレジリエンシーについて理解を深めたこともその決定に寄与しました。同ワークショップを通じて住信 SBI ネット銀行は、AWS のベストプラクティスに沿ったシステム設計を行うことで、可用性と回復力が大幅に向上し、障害発生時の迅速な切り替え、災害発生時のビジネス継続性（BCP）が確保できることを確認し、AWS による設計段階から運用まで一貫したサポートにより、安全かつ効率的な移行が実現できる体制を構築しています。 AWS 上に稼働予定の住信 SBI ネット銀行の次世代勘定系システムは、現行のオンプレミスで稼働する IBM 社の NEFSS をベースとして、 Amazon RDS for Db2 をはじめとする AWS のマネージドサービスに移行されます。将来的なスケーラビリティを見据え、クラウドネイティブな AWS のサービスを利用したデジタルバンク向け次世代クラウド勘定系アーキテクチャーに移行することで、3,000 万口座以上のデータボリュームに対応可能となり、さらにその後の事業成長にも柔軟に対応できる設計が実現されます。また、運用コストは約 30 ％削減が見込まれており、安定性・可用性・拡張性・効率性の向上により、開発・運用のスピードと柔軟性を確保できます。 さらに、これまで住信 SBI ネット銀行は、 AWS PrivateLink を活用して、他社のシステムともセキュアかつシームレスな接続を行ってきましたが、AWS に勘定系システムが移行されることで、AWS 上での他のシステムとの連携が容易になるため、サービス開発の高速化や柔軟性の向上が期待されます。これにより、新規システムの開発や機能追加の速度が大幅に向上するとともに、テスト環境の柔軟性も高まりサービス品質の向上も見込めます。その結果、BaaS（Banking as a Service）など先端技術を活用した新サービスの開発・展開が加速されることが期待されています。 住信 SBI ネット銀行株式会社　執行役員 システム副本部長　渡邊 弘様からのコメント 当行は 2017 年のクラウドファースト決定以降、段階的に AWS への移行を進めてきましたが、今回ついに勘定系システムという銀行の心臓部とも言える基幹システムの移行決定に至りました。 拡張性・信頼性・可用性・セキュリティ・費用面など、あらゆる角度から慎重な検討を重ねた結果、これまでの AWS 導入実績で培ったノウハウを活かし、3,000 万口座以上のお客様により安定的かつ効率的なサービス提供が可能になると確信しております。 全ての主要システムが AWS 上で統一されることで、システム間連携の効率化や新サービス開発の高速化が実現し、お客様により良いサービスをスピーディーにお届けできるようになります。 今後も AWS との連携を深め、生成 AI などの最先端技術も積極的に活用しながら、デジタル金融サービスのイノベーションをリードしてまいります。

はじめに SAPシステムは多くの企業のバックボーンであり、重要なビジネスプロセスを管理し、膨大な量の貴重なデータを生成しています。これらの重要なビジネスプロセスとデータは通常、エンタープライズSAPシステムを超えて拡張され、顧客は外部システムとも相互作用する必要があります。組織がより深い洞察と改善された意思決定のためにこのデータを活用しようとする中で、SAP顧客がデータやシステムとどのように相互作用するかを変革する必要性が高まっています。 Generative AIの自然言語処理（NLP）機能は、SAP ユーザーに自然言語クエリを使用して複雑なERPシステムと相互作用する強力なツールを提供し、専門的な技術知識や複雑なSQLクエリの必要性を排除します。これにより組織全体でのデータアクセスが民主化され、ビジネスユーザーが会話型インターフェースを使用してリアルタイムで質問し、レポートを生成し、洞察を得ることができるようになります。 Generative AIをSAPシステムと統合することで、組織は構造化されたERPデータと様々なSAPおよび非SAPソースからの非構造化情報との間のギャップを埋めることができ、ビジネス環境のより包括的な視点を提供します。この統合により、より正確な予測、パーソナライズされた顧客体験、そして企業エコシステム全体にわたるデータ駆動型の意思決定が可能になります。 AWSとSAPは、最先端の生成AIサービス、堅牢なインフラストラクチャ、豊富な実装リソースの包括的なスイートで、Generative AI導入ジャーニーのあらゆる段階で顧客を支援します。これらの提供物はSAPシステムと統合でき、AWSとSAPの広大なクラウドサービスエコシステムを補完します。 このブログ（2部構成シリーズのパート1）では、 Amazon Bedrock と他のAWSサービスを活用して、MS Teams、Slack、Streamlitユーザーインターフェースを通じて統一されたビューで人間の自然言語でSAPおよび非SAPデータソースから洞察を得る方法について説明し、図解します。 このブログシリーズのパート2では、 SAP BTPサービス （ SAP Build Apps 、 SAP Generative AI Hub ）を活用して、SAP Build Appsユーザーインターフェースで統一されたビューで人間の自然言語でSAPおよび非SAPシステムから洞察を得る方法について説明し、図解します。 概要 まず、SAPシステムからデータを抽出するために必要なビジネスロジックを開発します。 Bedrock Knowledge Bases と AWS Secrets Manager を含む様々なAWSサービスによってサポートされる、ビジネスロジックを実行する2つの AWS Lambda 関数を作成します。次に、追加の非SAPデータソースからデータを処理するビジネスロジックの作成に焦点を当て、物流情報を含む Amazon DynamoDB からデータを抽出するために特別に設計された別のlambda関数を実装します。システムの機能を強化するために、一般的なユーザークエリを促進する第3のデータソースとして機能するナレッジベースを確立します。その後、ユーザークエリに基づいてこれらの異なるデータソース間のフローを調整する責任を持つ Amazon Bedrock Agents を実装します。最終段階では、Streamlitを使用してユーザーインターフェースを作成し、アクセシビリティを向上させるためにMS TeamsとSlackとの代替統合オプションも提供します。 図1. ハイレベルアーキテクチャ ウォークスルー ソリューションを5つのステップに構造化しました。各ステップを順を追って説明します： ステップ1 – SAPシステムからデータを取得するビジネスロジックを作成 ステップ2 – 非SAPシステムからデータを取得するビジネスロジックを作成 ステップ3 – 一般的なクエリ用のBedrock Knowledge Basesを作成 ステップ4 – 異なるデータソース間を調整するBedrock Agentsを作成 ステップ5 – Microsoft Teams、Slack、Streamlitでユーザーインターフェースを作成 前提条件 Amazon S3 、AWS Lambda、Amazon Bedrock Agents、Amazon Bedrock Knowledge Bases、 Amazon Bedrock LLM（Claude） 、AWS Secrets Manager、Amazon DynamoDBを操作するための適切なIAM権限を持つAWSアカウント。これらのサービスに慣れていない場合は、先に進む前にそれらを確認することを強く推奨します。 SAP Sales OrderのデータソースとしてSAP ODataサービスをサポートするSAPシステム。 このデモでは標準のODataサービス、SAP Sales Order Service: API_SALES_ORDER_SRV とEntity Set: A_SalesOrder を使用していますが、ユースケースに基づいて任意のODataサービスを使用できます。ODataをインターネット上に公開していますが、SAPシステムの場所によってはインターネットに公開する必要がない場合もあります。ただし、より良いパフォーマンスとセキュリティ体制のためにプライベート接続を設定することを推奨します。詳細については、 SAP S/4HANAでODataサービスを有効にする方法 と AWSアカウントからRISEへの接続 を参照してください。 Slack統合用のSlackアカウントとMS Teams統合用のMS Teamsアカウント[オプション] ステップ1 – SAPシステムからデータを取得するビジネスロジックを作成 I. まず、S4システムの認証情報とシステム接続詳細を保存するためにAWS Secrets Managerでシークレットを作成します。 シークレットタイプを選択 で Other type of secret を選択し、 キー/値ペア の下に以下の詳細を追加します。環境に適用可能なシークレット値を入力してください。 シークレットキー シークレット値 S4_host_details https://<hostname>:<port> S4_username xxxx S4_password xxxx 詳細については、 AWS Secrets Managerシークレットの作成 を参照してください。 II. 第2ステップとして、必要に応じてSAPデータを補完・補足するために2つのBedrock Knowledge Basesを作成します。 Odata-Schema-knowledgebase このKnowledge Basesを使用してLLMにスキーマ詳細を提供し、ユーザークエリに基づいてOdata URLを作成する際に使用する属性について十分な知識をモデルが持てるようにします。 SAP-external-knowledgebase このKnowledge Basesを使用して非SAPデータに補足詳細を提供します。 2つのKnowledge Basesを作成する際に以下の入力を考慮し、他のすべての設定はデフォルト値のままにしました。 Bedrock Knowledge Base詳細を提供 Knowledge Base名: ユーザーフレンドリーな説明とともに各Knowledge Basesの名前を選択します。 Odata-Schema-knowledgebase と SAP-external-knowledgebase を使用しました。 Knowledge Base説明: ナレッジベースを一意に定義する説明を提供します。 IAM権限 : Create and use a new service role を選択 データソースを設定 データソース : Amazon S3 を選択 データソース名 : 各データソースの名前を選択します。 S3 URI : 各Knowledge Bases用に2つのS3バケットを作成します。 Odata-Schema-knowledgebase 用に Sales_Order_Schema.json ファイルを、 SAP-external-knowledgebase 用に Shipping_Policy.pdf を GitHubリポジトリ から対応するS3バケットにアップロードし、S3 URIを提供します。 データストレージと処理を設定 埋め込みモデル : Amazon Titan Text Embeddings V2 ベクターデータベース : ベクター作成方法として Quick create a new vector store 、ベクターストアとして Amazon OpenSearch Serverless を選択。 詳細については、 Amazon Bedrock Knowledge Basesでデータソースに接続してナレッジベースを作成 を参照してください。 最終的なエントリは以下のようになります： III. 次に、ユーザークエリに基づいてSAPシステムからデータを抽出する2つのLambda関数を作成します。 SAP-Odata-URL-Generation このLambdaは、Knowledge Basesからのスキーマ詳細とAWS Secrets Managerからのホスト詳細によってサポートされるLLMの助けを借りて、ユーザークエリに基づいてOdata URLを生成するビジネスロジックを実行します。 SAP-Sales-Order-Query このLambda関数は、SAPシステムからデータを取得するためのコアビジネスロジックを実行します。SAP-Odata-URL-Generation Lambdaによって提供されるOData URLを利用し、AWS Secrets Managerに保存されたシステム認証情報に安全にアクセスします。その後、関数は取得したデータを処理し、bedrockを通じてLLMを活用し、最終的に構造化された情報をBedrock Agentに提示してさらなる使用に供します。 関数を作成する際に以下の入力を考慮し、他のすべての設定はデフォルト値のままにしました。 Author from scratch を選択 関数名 : ユーザーフレンドリーな説明とともに各関数の名前を選択します。 SAP-Odata-URL-Generation と SAP-Sales-Order-Query を選択しました。 ランタイム : Python 3.13 アーキテクチャ : x86_64 コード : 関数 SAP-Odata-URL-Generation 用に SAP-Odata-URL-Generation.py のコードを、 SAP-Sales-Order-Query 用に SAP-Sales-Order-Query.py を GitHubリポジトリ からコピーします。 注意： kb_id、SecretIdなど、デプロイメント固有の値でコードを適応させてください。 設定 : メモリ : 1024MB 、 タイムアウト： 15min レイヤー : lambda関数に requests モジュールを追加するために、 GitHubリポジトリ から requests-layer.zip レイヤーを追加 権限： Lambda関数に以下の権限を設定する必要があります。 SAP-Odata-URL-Generation： 実行ロール – lambda基本ロールに加えて、以下のアクション bedrock:InvokeModel 、 bedrock-agent-runtime:Retrieve 、 secretsmanager:GetSecretValue を持つ新しいIAMポリシーを作成、 リソースベースポリシーステートメント – ステップ4で作成するBedrock Agent ARNへの lambda:InvokeFunction アクセス。 SAP-Sales-Order-Query： 実行ロール – lambda基本ロールに加えて、以下のアクション bedrock:InvokeModel 、 secretsmanager:GetSecretValue を持つ新しいIAMポリシーを作成 リソースベースポリシーステートメント – ステップ4で作成するBedrock Agent ARNへの lambda:InvokeFunction アクセス。 詳細については、 PythonでLambda関数を構築 と Python Lambda関数のレイヤーの操作 を参照してください。 ステップ2 – 非SAPシステムからデータを取得するビジネスロジックを作成 I. まず、以下の入力でDynamoDBテーブルを作成します。 テーブル名 : logistics パーティションキー： order_id GitHubリポジトリ の Items.json ファイルを使用してDynamoDBテーブルにアイテムを作成します。詳細については、 JSONファイルからAmazon DynamoDBテーブルアイテムを作成 を参照してください。 II. 次に、ユーザークエリに基づいてDynamoDBテーブルからデータを抽出するLambda関数を作成します。 Author from scratch を選択 関数名 : ユーザーフレンドリーな説明とともに関数の名前を選択します。 Logistics-System を選択しました ランタイム : Python 3.13 アーキテクチャ : x86_64 設定 : メモリ : 1024MB 、 タイムアウト： 15min コード : GitHubリポジトリ から Logistics-System.py のコードをコピーします。 権限 : Lambda関数に以下の権限を追加します。 実行ロール – lambda基本ロールに加えて、以下のアクション dynamodb:Query 、 dynamodb:DescribeTable を持つ新しいIAMポリシーを作成、 リソースベースポリシーステートメント – ステップ4で作成するBedrock Agent ARNへの lambda:InvokeFunction アクセス。 ステップ3 – 一般的なクエリ用のKnowledge Basesを作成 次に、3番目のナレッジベースを作成します。このナレッジベースは一般情報リポジトリとして機能します。ユーザーは、組織情報から特定の専門知識まで、必要に応じて様々なトピックについて学ぶためにこのリソースにアクセスできます。 General-information-knowledgebase : このデモでは、このナレッジベースを使用してSAPビジネスプロセスに関するガイダンスを提供します。 Knowledge Basesを作成する際に以下の入力を考慮し、残りはデフォルトのままにしました。 Knowledge Base詳細を提供 Knowledge Base名 : 各Knowledge Basesの名前を選択します。ユーザーフレンドリーな説明とともに General-information-knowledgebase を使用しました。 IAM権限 : Create and use a new service role を選択 データソースを設定 データソース : Amazon S3 を選択 データソース名 : 選択に応じてデータソースの名前を選択します。 S3 URI : S3バケットを作成し、GitHubリポジトリから「 How to create SAP Sales Order pdf 」をアップロードし、対応する S3 URI を提供します。 データストレージと処理を設定 埋め込みモデル : Amazon Titan Text Embeddings V2 ベクターデータベース : ベクター作成方法として Quick create a new vector store 、ベクターストアとして Amazon OpenSearch Serverless を選択。 最終的なエントリは以下のようになります： ステップ4 – Bedrock Agentを作成： このステップでは、前のステップで作成した異なるデータソース間を調整してユーザークエリに応答するBedrock Agentを作成します。 bedrock agentを作成する際に以下の入力を考慮し、他のすべての設定はデフォルト値のままにしました。 Agent詳細： Agent名 : エージェントの名前とユーザーフレンドリーな説明を選択します。 Business-Query-System と名付けました。 Agentリソースロール : Create and use a new service role を選択 モデルを選択 : Claude 3 Sonnet v1 を選択。異なるLLMを選択することもできますが、望ましい応答を得るためにプロンプトを適宜修正する必要があります。 Agentへの指示 : Agentに何をしてほしいかを明確に説明する正確で段階的な指示を与えます。 You are an AI assistant helping users in querying SAP sales data directly from SAP system and shipping details from logistic system. You also help users with general queries about business process from the company knowledge base. 追加設定 : ユーザー入力 で Enabled を選択 アクショングループ： アクショングループは、エージェントがユーザーの達成を支援すべきタスクを定義します。 アクショングループ : SAP-Sales-Order 。このアクショングループを使用してSAP Sales orderに関連するクエリを処理します。 アクショングループ名 : アクショングループの名前を選択し、ユーザーフレンドリーな説明を入力します。 SAP-Sales-Order と名付けました アクショングループタイプ : Define with function details アクショングループ呼び出し : Select an existing Lambda function を選択し、ステップ1で作成したlambda関数 SAP-Sales-Order-Query を選択 アクショングループ関数1名 : SalesOrder として関数の説明を提供します。 アクショングループ : Logistics-System 。このアクショングループを使用して販売注文の物流情報に関連するクエリを処理します。 アクショングループ名： アクショングループの名前を選択し、ユーザーフレンドリーな説明を入力します。 Logistics-System と名付けました アクショングループタイプ : Define with API schemas アクショングループ呼び出し : Select an existing Lambda function を選択し、ステップ2で作成したlambda関数 Logistics-System を選択。 アクショングループスキーマ : Select an existing API schema 。 S3 Url : S3バケットを作成し、 GitHubリポジトリ から logistics.json ファイルをS3バケットにアップロードし、バケットのS3 Urlを提供します。 メモリ： Enabled を選択し、 メモリ期間 を 2 days 、 最大最近セッション数 を 20 に設定。 Knowledge Bases： 以前に作成したナレッジベースを追加 Knowledge Baseを選択 : SAP-external-knowledgebase AgentのKnowledge Base指示： SAPシステム外の情報が必要で、SAPシステムデータと組み合わせて応答を完成させる場合にこのナレッジベースを使用 Knowledge Baseを選択 : General-Information-knowledgebase AgentのKnowledge Base指示： SAPシステムから利用できないユーザーからの一般的なビジネス質問に答えるためにこのナレッジベースを使用。 オーケストレーション戦略詳細 – Default orchestration 。Bedrock agentsはデフォルトプロンプト テンプレート を提供しますが、特定の要件に合わせて調整できます。特定のユースケース要件に合わせて以下のプロンプトテンプレートをカスタマイズします。 前処理 : Override pre-processing template defaults を選択。プロンプトテンプレートに以下のセクションを追加します。 -Category F: Questions that can be answered or assisted by our function calling agent using the functions it has been provided and arguments from within conversation history or relevant arguments it can gather using the askuser function AND also needs external data from the knowledge base to complete the response. Combine data from the SAP or non-SAP Logistic system and the external knowledge base to prepare the final answer オーケストレーション : Override orchestration template defaults を選択。プロンプトテンプレートの対応するセクションの下に以下のテキストを追加します。 $knowledge_base_guideline$ - If any data is not updated in the Logistic system like order shipping date, then check the knowledge base named 'SAP-external-knowledgebase' to look for the estimated delivery timeline as per the shipping category. Then consider that timeline and add the timeline to the date of 'Order Received' and share the estimated the shipping date with the user - If the SAP system throws any error due to unavailability of the requested data, check the knowledge base named 'SAP-external-knowledgebase' to look for the explanation of the ERROR CODE. Respond to the user with the explanation of the error code ONLY $tools_guidelines$ [ このセクションは存在しないため、作成する必要があります ] - Invoke tool 'SAP-Sales-Order' ONLY for any questions related to sales order - Invoke tool 'Logistics-System' ONLY for any shipping details for the sales order - Do NOT invoke both tools 'SAP-Sales-Order' and 'Logistics-System' unless user requested for both the information. $multiple_tools_guidelines$ [ このセクションは存在しないため、作成する必要があります ] - If user asks question which needs to invoke more than one tool. Invoke the tools one by one. Collect the response from both the tools and then combine them before responding to the users. For example, if user requests for both Sales order and Logistic information. First fetch the Sales Order details with Sales Order tool. Then fetch logistic details from Logistic tool. Finally combine both responses into one when responding to the user. すべての詳細を入力したら 保存 し、 準備 を選択して最新の変更を更新します。エージェント概要ページに移動するには 保存して終了 を選択します。 最後に、アプリケーションで使用するエージェントの特定のスナップショットまたはバージョンを持つために エイリアス を作成します。 作成 を選択し、ユーザーフレンドリーな 説明 とともに エイリアス名 を提供します。 スループットをデフォルトの オンデマンド にしたバージョンで 新しいバージョンを作成してこのエイリアスに関連付ける を選択します。 詳細については、 エージェントを手動で作成および設定 を参照してください。 最終的なエントリは以下のようになります： ご覧のように、エージェントの複数のエイリアスとバージョンを作成し、任意のエイリアスを選択してアプリケーションに特定のスナップショットまたはバージョンを統合できます。 次に、bedrock agentがそれらを呼び出せるようにLambda関数のIAMロールを調整する必要があります。 Lambdaのリソースベースポリシーの使用 の手順に従い、Amazon Bedrockがエージェントのアクショングループ用にLambda関数にアクセスできるようにするために、必要に応じて ${values} を置き換えて、以下のリソースベースポリシーをLambda関数にアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AccessLambdaFunction", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:${region}:${account- id}:function:function-name", "Condition": { "StringEquals": { "AWS:SourceAccount": "${account-id}" }, "ArnLike": { "AWS:SourceArn": "arn:aws:bedrock:${region}:${account-id}:agent/${agent-id}" } } } ] } 私のポリシーは以下のようになります { "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "bedrock-agent-sales", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:1234567xxxx:function:SAP-Sales-Order-Query", "Condition": { "StringEquals": { "AWS:SourceAccount": "1234567xxxx" }, "AWS:SourceArn": { "arn:aws:bedrock:us-east-1: 1234567xxxx:agent/VX5FAWE3OO" } } } ] } ステップ5 – Microsoft Teams、Slack、Streamlitでユーザーインターフェースを作成 このステップでは、ユーザーがBedrock agentと相互作用できるユーザーインターフェースの開発を行います。 Microsoft Teams – この統合には、MS Teams（適切な権限を持つ）と Amazon Q Developer in chat application の両方へのアクセスが必要です。Amazon Q Developer in chat applications（以前のAWS Chatbot）により、Microsoft TeamsでGenAI Bedrock Agentsと相互作用できます。 ステップ1: アプリアクセスを設定： Microsoft Teamsが組織管理者によってインストールされ、承認されています。 ステップ2: Teamsチャンネルを設定： MS Teams標準チャンネルを作成するか既存のものを使用し、Amazon Q DeveloperをチャンネルにAmazon Q Developerを追加します。[ 注意： Microsoft Teamsは現在プライベートチャンネルでAmazon Q Developerをサポートしていない ため、標準チャンネルが必要です] Microsoft Teamsで、チーム名を見つけて選択し、 チームを管理 を選択します。 アプリ を選択し、 その他のアプリ を選択します。 検索バーに Amazon Q Developer と入力してAmazon Q Developerを見つけます。 ボットを選択します。 チームに追加 を選択し、プロンプトを完了します   ステップ3: TeamsクライアントのAmazon Q Developerを設定 このステップでは、 Amazon Q Developer in chat Applications にMS Teamsチャンネルへのアクセスを提供します。 AWSコンソールで Amazon Q Developer in chat applications を開きます。 チャットクライアントを設定 の下で、 Microsoft Teams を選択し、前のステップで作成したMicrosoft TeamsチャンネルURLをコピーして貼り付け、 設定 を選択します。[ Amazon Q DeveloperがあなたのAmazon Q Developerがあなたの情報にアクセスする権限を要求するTeams認証ページにリダイレクトされます]。 Microsoft Teams認証ページで、 承認 を選択します。左側に、Microsoft TeamsでTeamsチャンネルがリストされているのが確認できるはずです。 次に、MS Teamsチャンネルを設定に関連付けます。 Amazon Q Developerコンソールの Teams詳細 ページで、 新しいチャンネルを設定 を選択します。設定に以下の入力を使用し、残りはデフォルトのままにします。 設定詳細 : 設定名 : 設定の名前を選択します。 aws-sap-demos-team と名付けました Microsoft Teamsチャンネル チャンネルURL : ステップ2で作成したMicrosoft TeamsチャンネルURLをコピーして貼り付けます。 権限 ロール設定 : チャンネルロール を選択 チャンネルロール: テンプレートを使用してIAMロールを作成 を選択 ロール名: 選択した名前を選択します。 awschatbot-sap-genai-teams-role  と名付けました ポリシー テンプレート : Amazon Q Developer access permissions チャンネルガードレールポリシー[ポリシー名]: AWSLambdaBasicExecutionRole 、 AmazonQDeveloperAccess。 要件に応じてIAMポリシーを調整できますが、常に 最小権限 権限 のベストプラクティスに従うことを推奨します。 ステップ4: 次に、エージェントをチャットチャンネルに接続します Amazon Q Developer Bedrock Agentコネクタには bedrock:InvokeAgent IAMアクションが必要です。 前のステップで作成したIAMロール： awschatbot-sap-genai-teams-role  に以下のポリシーを追加します。 { "Sid": "AllowInvokeBedrockAgent", "Effect": "Allow", "Action": "bedrock:InvokeAgent", "Resource": [ "arn:aws:bedrock:aws-region:<AWS Account ID>:agent-alias/<Bedrock Agent ID>/<Agent Alias ID>/" ] } Amazon Bedrock agentをチャットチャンネルに追加するには、 @Amazon Q connector add connector_name arn:aws:bedrock:aws-region : AWSAccountID :agent/ AgentID AliasID . と入力します。選択したコネクタ名を選択してください。 私のエントリは以下のようになります。 @Amazon Q connector add order_assistant arn:aws:bedrock:us-east-1:xxxxxxx:agent/VX5FAWE3OO VG92WRF1JI 詳細については、 チュートリアル：Microsoft Teamsを開始する を参照してください。 Teamsインターフェースは以下のようになります Slack – この統合には、Slack（適切な権限を持つ）と Amazon Q Developer in chat application の両方へのアクセスが必要です。Amazon Q Developer in chat applications（以前のAWS Chatbot）により、SlackでGenAI Bedrock Agentsと相互作用できます。 ステップ1: アプリアクセスを設定： ワークスペース管理者は、ワークスペース内でのAmazon Q Developerアプリの使用を承認する必要があります。 ステップ2: Slackチャンネルを設定： slackチャンネルを作成するか既存のものを使用し、Amazon Q DeveloperをSlackチャンネルに追加します。 Slackチャンネルで、 /invite @Amazon Q と入力し、 招待する を選択します ステップ3: SlackクライアントのAmazon Q Developerを設定 このステップでは、 Amazon Q Developer in chat Applications にSlackワークスペースへのアクセスを提供します。 AWSコンソールで Amazon Q Developer in chat applications を開きます。 チャットクライアントを設定 の下で、 Slack を選択し、 設定 を選択します。[ Amazon Q Developerがあなたの情報にアクセスする権限を要求するSlackの認証ページにリダイレクトされます]。 Amazon Q Developerで使用したいSlackワークスペースを選択し、 許可 を選択します。 左側に、SlackでSlackワークスペースがリストされているのが確認できるはずです。 次に、チャンネルを設定に関連付けます。 Amazon Q Developerコンソールの ワークスペース詳細 ページで、 新しいチャンネルを設定 を選択します。設定に以下の入力を使用し、残りはデフォルトのままにします。 設定詳細 : 設定名 : 設定の名前を選択します。 sap-genai-slack-chatbot と名付けました Amazon内部設定 アカウント分類 : 非本番 を選択 Slackチャンネル チャンネルID : ステップ2で設定したslackチャンネルのチャンネルIDを提供します。 権限 ロール設定 : チャンネルロール を選択 チャンネルロール: テンプレートを使用してIAMロールを作成 を選択 ロール名: 選択した名前を選択します。 aws-sap-genai-chatbot-role  と名付けました ポリシー テンプレート : Amazon Q Developer access permissions チャンネルガードレールポリシー[ポリシー名]: AWSLambdaBasicExecutionRole 、 AmazonQDeveloperAccess。 要件に応じてIAMポリシーを調整できますが、常に 最小権限 権限 のベストプラクティスに従うことを推奨します。 ステップ4: 次に、エージェントをチャットチャンネルに接続します Amazon Q Developer Bedrock Agentコネクタには bedrock:InvokeAgent IAMアクションが必要です。 前のステップで作成したIAMロール： awschatbot-sap-genai-teams-role  に以下のポリシーを追加します。 { "Sid": "AllowInvokeBedrockAgent", "Effect": "Allow", "Action": "bedrock:InvokeAgent", "Resource": [ "arn:aws:bedrock:aws-region:<AWS Account ID>:agent-alias/<Bedrock Agent ID>/<Agent Alias ID>/" ] } Amazon Bedrock agentをチャットチャンネルに追加するには、以下のように入力します。選択したコネクタ名を選択してください。 @Amazon Q connector add connector_name arn:aws:bedrock:aws-region: AWSAccountID :agent/ AgentID AliasID . 私のエントリは以下のようになります。 @Amazon Q connector add order_assistant arn:aws:bedrock:us-east-1:xxxxxxx:agent/VX5FAWE3OO VG92WRF1JI 詳細については、 チュートリアル：Slackを開始する を参照してください。 Slackインターフェースは以下のようになります Streamlit – Streamlitは、pythonスクリプト用のインタラクティブなWebアプリを構築するために一般的に使用されるオープンソースのPythonフレームワークです。Amazon EC2インスタンスでアプリケーションをホストするために以下の手順に従いました。 EC2インスタンスを起動します。Amazon Linux t2.microインスタンスを考慮しました。 HTTP/HTTPSトラフィック（ポート80/443/8501または使用を選択した他のポート）を許可する必要なセキュリティグループでEC2インスタンスを設定 以下のように環境を準備 必要なパッケージをインストール $sudo apt update $sudo apt-get install python3-venv 仮想環境を設定 $mkdir streamlit-demo $cd streamlit-demo $python3 -m venv venv $source venv/bin/activate Streamlitをインストール $pip install streamlit Vi/Vim/nanoエディタを使用してstreamlit-app.pyという名前のファイルを作成し、 GitHubリポジトリ から streamlit-app.py のコードをコピーします。 以下のコマンドでStreamlitアプリを実行 $streamlit run streamlit-app.py 以下のコマンドでstreamlitアプリをバックグラウンドで実行 $nohup streamlit run streamlit-app.py & Streamlitは8501から1ずつ増加して利用可能なポートを割り当てます。streamlitに特定のポートを考慮させたい場合は、以下のコマンドを使用できます $streamlit run streamlit-app.py --server.port XXXX  上記のコマンドを実行した後、以下に示すように、ブラウザでStreamlitアプリケーションを開くURLを確認できました Streamlitアプリケーションは以下のようになります コスト 大規模言語モデル（LLM）の運用には、相当なインフラストラクチャ、開発、保守コストが伴います。しかし、Amazon BedrockなどのAWSサービスは、簡素化されたインフラストラクチャ管理、合理化された開発プロセス、柔軟な価格モデル、選択したLLMにアクセスするための様々なコスト最適化オプションを通じて、費用を大幅に削減できます。 AWSサービス – US East（N. Virginia） コスト 見積もり[1時間実行] Bedrock – Foundation Model LLM推論[Claude 3.5 Sonnet] 100K入力、200K出力 $3.3 Bedrock – 埋め込みモデル推論[Amazon Titan Text Embeddings v2] 100ドキュメント、各平均500語 $0.10 OpenSearch Compute Unit（OCU）– インデックス作成 2 OCU[最小2 OCU] $0.48 OpenSearch Compute Unit（OCU）– 検索とクエリ 2 OCU[最小2 OCU] $0.48 OpenSearch管理ストレージ 10GB $0.24 EC2インスタンス[Streamlitアプリ] t2.micro $ 0.0116 Lambda、Secrets Manager、DynamoDB $ 0.2                     1時間のアプリケーション使用の推定コスト – $4.8116 詳細については、 Amazon Bedrock価格 、 Amazon OpenSearch Service価格 、 Amazon EC2オンデマンド価格 、 AWS Lambda価格 、 AWS Secrets Manager価格 、 Amazon DynamoDB価格 を参照してください。 結論 このブログ投稿では、Amazon Bedrockに焦点を当てたAWSサービスを使用して、SAPと非SAPシステムの両方とシームレスに相互作用するインテリジェントな仮想アシスタントを作成する方法を実演しています。このソリューションは、販売注文データ用のSAPシステム、物流情報用の非SAPシステム、補足詳細用のKnowledge Basesを統合し、Streamlit、Microsoft Teams、Slackを含む複数のユーザーインターフェースを通じてアクセス可能です。Lambda、Bedrock、Secrets Manager、DynamoDBなどのAWSサービススイートを活用することで、実装は複雑なエンタープライズシステムとの自然言語相互作用を可能にし、堅牢なセキュリティを維持しながら多様なデータソースへの統一アクセスを提供します。サーバーレスアーキテクチャと従量課金制価格モデルにより、これは会話型AIインターフェースを通じてデータアクセス機能を強化しようとする組織にとってアクセス可能で費用対効果の高いソリューションとなります。このブログ投稿では、このソリューションを実装するための詳細な段階的ガイドを提供し、企業がSAPおよび非SAP環境で生成AIを活用する道を開きます。 このソリューションを実装することで、エンタープライズデータとの相互作用を変革する実践的な経験を得てください。 Amazon AgentCore（プレビュー） でAIエージェントを安全に大規模にデプロイ・運用、予測分析用の Amazon Forecast 、インテリジェントドキュメント処理用の Amazon Textract 、言語翻訳用の Amazon Translate 、自然言語処理用の Amazon Comprehend を含む包括的な機械学習サービススイートを探索してデジタル変革を加速してください。これらのサービスはSAPとシームレスに統合し、様々なビジネスニーズに対応し、組織の新しい可能性を解き放ちます。 何千もの顧客がSAPの移行とイノベーションでAWSを信頼する理由を学ぶには、 AWS for SAP ページをご覧ください。 本ブログはパートナー SA 松本が翻訳しました。原文は こちら です。

本ブログは 2025 年 8 月 29 日に公開された AWS Blog “ Amazon disrupts watering hole campaign by Russia’s APT29 ” を翻訳したものです。 Amazon の脅威インテリジェンスチームは、ロシアの対外情報庁 (SVR) に関連する脅威アクター APT29 (Midnight Blizzard としても知られる) による水飲み場型攻撃キャンペーンを特定し、阻止しました。私たちの調査により、標的を選ばない水飲み場型攻撃キャンペーンが明らかになりました。このキャンペーンでは、侵害されたウェブサイトを利用して訪問者を悪意のあるインフラストラクチャにリダイレクトし、Microsoft のデバイスコード認証フローを通じて攻撃者が制御するデバイスを承認するようユーザーを騙していました。この標的を選ばないアプローチは、APT29 が情報収集活動においてより広範な対象を捕捉するために、その運用を拡大する継続的な進化を示しています。 APT29 の進化する戦術 このキャンペーンは、私たちが以前 APT29 から観測した活動パターンと一致しています。2024 年 10 月、 Amazon は APT29 による AWS を偽装したドメイン使用の試み を阻止しました。これは攻撃者が制御するリソースを指す Remote Desktop Protocol ファイルでユーザーをフィッシングするものでした。また、2025 年 6 月には、Google の Threat Intelligence Group が、アプリケーション固有のパスワード (ASP) を使用してロシアの学者や批評家を標的としたAPT29 のフィッシングキャンペーンについて 報告 しました。現在のキャンペーンは、認証情報収集と情報収集への継続的な焦点と、技術的アプローチの改良を示しており、APT29 の工作手法が以下の点で進化していることを示しています 正規のウェブサイトを侵害し、最初に難読化された JavaScript を注入する 攻撃が阻止されたら迅速にインフラストラクチャを適応させる 新しいインフラストラクチャでは、JavaScript リダイレクトからサーバーサイドリダイレクトへの調整を行う 技術的詳細 Amazon は APT29 のインフラストラクチャ向けに作成した分析を通じてこのアクティビティを特定し、攻撃者が制御するドメイン名の発見につながりました。さらなる調査により、Amazon は攻撃者が様々な正規のウェブサイトを侵害し、訪問者の約 10% を攻撃者が制御するドメインにリダイレクトする JavaScript を注入していたことを特定しました。findcloudflare[.]com などのこれらのドメインは、正規に見えるように Cloudflare の検証ページを模倣していました。このキャンペーンの最終的な標的は Microsoft のデバイスコード認証フローでした。AWS システムの侵害はなく、AWS サービスやインフラストラクチャへの直接的な影響も観察されませんでした。 コードの分析により、以下のような回避テクニックが明らかになりました ランダム化を使用して訪問者の一部のみをリダイレクトする 悪意のあるコードを隠すために base64 エンコーディングを使用する 同じ訪問者の繰り返しのリダイレクトを防ぐためにクッキーを設定する ブロックされた場合に新しいインフラストラクチャに移行する 侵害されたページの画像、ドメイン名は削除されています。 Amazon の阻止の取り組み Amazon は、高度な脅威アクターを積極的に探索し阻止することで、インターネットのセキュリティを保護することに引き続き取り組んでいます。私たちは業界パートナーやセキュリティコミュニティと協力して、インテリジェンスを共有し脅威を軽減し続けます。このキャンペーンを発見した際、Amazon は迅速に影響を受けた EC2 インスタンスを隔離し、Cloudflare や他のプロバイダーと連携して攻撃者のドメインを無効化し、関連情報を Microsoft と共有しました。 攻撃者が AWS から別のクラウドプロバイダーへの移行を含む新しいインフラストラクチャへの移行を試みたにもかかわらず、私たちのチームは彼らの活動を追跡し阻止し続けました。私たちの介入後、攻撃者が cloudflare[.]redirectpartners[.]com などの追加ドメインを登録し、再び Microsoft のデバイスコード認証ワークフローに被害者を誘導しようとしているのを観察しました。 ユーザーと組織の保護 組織には以下の保護対策を実施することをお勧めします。 エンドユーザー向け： セキュリティ検証ページを装った不審なリダイレクトチェーンに注意してください。 デバイス認証リクエストを承認する前に、常にその信頼性を確認してください。 AWS が現在ルートアカウントに多要素認証 (MFA) を要求しているのと同様に、すべてのアカウントで MFA を有効にしてください。 コマンドをコピー＆ペーストしたり、Windows の実行ダイアログ (Win+R) でアクションを実行するよう求めるウェブページには注意してください。 これは最近文書化された「ClickFix」テクニックに一致しており、攻撃者がユーザーに悪意のあるコマンドを実行させるよう騙します。 IT 管理者向け： デバイス認証フローに関する Microsoft のセキュリティガイダンスに従い、必要でない場合はこの機能を無効にすることを検討してください。 デバイスのコンプライアンス、場所、リスク要因に基づいて認証を制限する条件付きアクセスポリシーを適用してください。 特に新しいデバイス認証を含む認証イベントのための堅牢なログ記録とモニタリングを実装してください。 侵害の痕跡 (IOC) findcloudflare[.]com cloudflare[.]redirectpartners[.]com サンプル JavaScript コード デコードされた JavaScript コード。[removed_domain]は侵害されたサイトで削除されています この投稿に関する質問がある場合は、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。この役割において、CJ は Amazon 全体のセキュリティエンジニアリングと運用を主導しています。彼のミッションは、セキュリティの利点を最小抵抗の道にすることで Amazon のビジネスを可能にすることです。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO などの様々な役割を経て、最近では AWS CISO を務めた後、2023 年 9 月に Amazon Integrated Security の CISO になりました。 Amazon に入社する前、CJ は連邦捜査局 (FBI) のサイバー部門でコンピュータとネットワーク侵入の技術分析を主導していました。CJ はまた、空軍特別捜査局 (AFOSI) の特別捜査官も務めました。CJ は今日のセキュリティ業界の基礎となる複数のコンピュータ侵入調査を主導しました。 CJ はコンピュータサイエンスと刑事司法の学位を持ち、アクティブな SRO GT America GT2 レースカードライバーです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

2001 年から macOS を使用し、4 年前のリリースから Amazon EC2 Mac インスタンス を使用してきた私は、AWS での継続的インテグレーションとデリバリー (CI/CD) パイプラインのスケーリングで大勢のお客様をサポートしてきました。今日は、Amazon EC2 M4 インスタンスと M4 Pro Mac インスタンスの一般提供が開始されたことをお知らせしたいと思います。 Apple プラットフォーム向けのアプリケーションを構築している開発チームには、複雑な構築プロセスを処理し、複数の iOS シミュレータを同時に実行するための強力なコンピューティングリソースが必要です。開発プロジェクトの規模が大きくなり、より高度になるにつれて、チームもパフォーマンスを強化し、メモリ容量を増やして、迅速な開発サイクルを維持しなければなりません。 Apple M4 Mac mini を中核としたインスタンス EC2 M4 Mac (API では mac-m4.metal ) インスタンスは、 Apple M4 Mac mini コンピュータ上に構築され、 AWS Nitro System を搭載しています。10 コア CPU (4 個のパフォーマンスコアと 6 個の効率性コア)、10 コア GPU、16 コア Neural Engine、24 GB ユニファイドメモリを備えた Apple シリコン M4 チップを使用しており、iOS と macOS のアプリケーション構築ワークロードのパフォーマンスを強化します。M4 Mac インスタンスは、アプリケーションの構築時やテスト時に EC2 M2 Mac インスタンスよりも最大 20% 優れたアプリケーション構築パフォーマンスを実現します。 EC2 M4 Pro Mac (API では mac-m4pro.metal ) インスタンスは、14 コア CPU、20 コア GPU、16 コア Neural Engine、48 GB ユニファイドメモリを備えた Apple シリコン M4 Pro チップを搭載しています。これらのインスタンスは、EC2 M2 Pro Mac インスタンスよりも最大 15% 優れたアプリケーション構築パフォーマンスを実現します。増強されたメモリとコンピューティング能力により、複数のデバイスシミュレータを使用してさらに多くのテストを同時実行することが可能になります。 M4 インスタンスと M4 Pro Mac インスタンスにはそれぞれ 2 TB のローカルストレージがあり、キャッシュ、構築、テストのパフォーマンスを向上させる低レイテンシーのストレージを提供します。 どちらのインスタンスタイプも、macOS Sonoma のバージョン 15.6 以降を Amazon マシンイメージ (AMI) としてサポートしています。AWS Nitro System は、高速 Thunderbolt 接続を使用することで、最大 10 Gbps の Amazon Virtual Private Cloud (Amazon VPC) ネットワーク帯域幅と 8 Gbps の Amazon Elastic Block Store (Amazon EBS) ストレージ帯域幅を提供します。 Amazon EC2 Mac インスタンスは AWS サービスとシームレスに統合するため、以下が可能になります。 AWS CodeBuild と AWS CodePipeline を使用して自動 CI/CD パイプラインを構築する AWS Secrets Manager でビルドシークレット (Apple の開発用証明書やキーなどの) の複数バージョンを保存して管理する AWS CloudFormation を使用して開発インフラストラクチャを管理する Amazon CloudWatch を使用してインスタンスのパフォーマンスをモニタリングする 使用開始方法の説明 EC2 M4 インスタンスと M4 Pro Mac インスタンスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して起動できます。 このデモでは、コンソールから M4 Pro インスタンスを起動しましょう。まず、インスタンスを実行するための専有ホストを割り当てます。 AWS マネジメントコンソール で [EC2]、 [専有ホスト] の順に移動し、 [専有ホストの割り当て] を選択します。 次に、 [名前タグ] に入力してから、 [インスタンスファミリー] ( mac-m4pro ) と [インスタンスタイプ] ( mac-m4pro.metal ) を選択します。 [アベイラビリティーゾーン] を 1 つ選択し、 [ホストのメンテナンス] のチェックを外します。 または、コマンドラインインターフェイスを使用することも可能です。 aws ec2 allocate-hosts \ --availability-zone-id "usw2-az4" \ --auto-placement "off" \ --host-recovery "off" \ --host-maintenance "off" \ --quantity 1 \ --instance-type "mac-m4pro.metal" 専有ホストが私のアカウントに割り当てられたら、割り当てられたホストを選択して、 [アクション] メニュー、 [インスタンスをホストで起動] の順に選択します。 コンソールには、このタイプのホスト向けに [サポートされている最新の macOS バージョン] が他の情報とともに表示されているのがわかります。今回は macOS 15.6 です。   [インスタンスを起動] ページで [名前] に入力します。ここでは macOS Sequoia の Amazon マシンイメージ (AMI) を選択します。このときに、 [アーキテクチャ] が 64 ビット ARM、 [インスタンスタイプ] が mac-m4pro.metal であることを確認します。 残りのパラメータは Amazon EC2 Mac 固有のものではなく、ネットワークとストレージの設定です。開発用のインスタンスを起動するときは、200 Gb 以上のボリュームを選択するようにしてください。Xcode をダウンロードしてインストールするには、デフォルトの 100 GB ボリュームサイズでは不十分です。 準備ができたら、ページの最下部にあるオレンジ色の [インスタンスを起動] ボタンを選択します。コンソールにはインスタンスが直ちに 実行中 として表示されますが、SSH 経由で接続できるようになるまで最大 15 分かかる場合があります。 または、このコマンドを使用することも可能です。 aws ec2 run-instances \ --image-id "ami-000420887c24e4ac8" \ # AMI ID depends on the region ! --instance-type "mac-m4pro.metal" \ --key-name "my-ssh-key-name" \ --network-interfaces '{"AssociatePublicIpAddress":true,"DeviceIndex":0,"Groups":["sg-0c2f1a3e01b84f3a3"]}' \ # Security Group ID depends on your config --tag-specifications '{"ResourceType":"instance","Tags":[{"Key":"Name","Value":"My Dev Server"}]}' \ --placement '{"HostId":"h-0e984064522b4b60b","Tenancy":"host"}' \ # Host ID depends on your config --private-dns-name-options '{"HostnameType":"ip-name","EnableResourceNameDnsARecord":true,"EnableResourceNameDnsAAAARecord":false}' \ --count "1" ターミナルからの Xcode のインストール インスタンスにアクセスできるようになったら、SSH を使用してインスタンスに接続し、開発ツールをインストールできます。 Xcode 16.4 のダウンロードとインストールには xcodeinstall を使用します。 ノートパソコンから、Apple Developer 認証情報を使用してセッションを開始します。 # on my laptop, with permissions to access AWS Secret Manager » xcodeinstall authenticate -s eu-central-1 Retrieving Apple Developer Portal credentials... Authenticating... 🔐 Two factors authentication is enabled, enter your 2FA code: 067785 ✅ Authenticated with MFA. 先ほど起動した EC2 Mac インスタンスに接続します。次に、Xcode をダウンロードしてインストールします。 » ssh ec2-user@44.234.115.119 Warning: Permanently added '44.234.115.119' (ED25519) to the list of known hosts. Last login: Sat Aug 23 13:49:55 2025 from 81.49.207.77 ┌───┬──┐ __| __|_ ) │ ╷╭╯╷ │ _| ( / │ └╮ │ ___|\___|___| │ ╰─┼╯ │ Amazon EC2 └───┴──┘ macOS Sequoia 15.6 ec2-user@ip-172-31-54-74 ~ % brew tap sebsto/macos ==> Tapping sebsto/macos Cloning into '/opt/homebrew/Library/Taps/sebsto/homebrew-macos'... remote: Enumerating objects: 227, done. remote: Counting objects: 100% (71/71), done. remote: Compressing objects: 100% (57/57), done. remote: Total 227 (delta 22), reused 63 (delta 14), pack-reused 156 (from 1) Receiving objects: 100% (227/227), 37.93 KiB | 7.59 MiB/s, done. Resolving deltas: 100% (72/72), done. Tapped 1 formula (13 files, 61KB). ec2-user@ip-172-31-54-74 ~ % brew install xcodeinstall ==> Fetching downloads for: xcodeinstall ==> Fetching sebsto/macos/xcodeinstall ==> Downloading https://github.com/sebsto/xcodeinstall/releases/download/v0.12.0/xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz Already downloaded: /Users/ec2-user/Library/Caches/Homebrew/downloads/9f68a7a50ccfdc479c33074716fd654b8528be0ec2430c87bc2b2fa0c36abb2d--xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz ==> Installing xcodeinstall from sebsto/macos ==> Pouring xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz 🍺 /opt/homebrew/Cellar/xcodeinstall/0.12.0: 8 files, 55.2MB ==> Running `brew cleanup xcodeinstall`... Disable this behaviour by setting `HOMEBREW_NO_INSTALL_CLEANUP=1`. Hide these hints with `HOMEBREW_NO_ENV_HINTS=1` (see `man brew`). ==> No outdated dependents to upgrade! ec2-user@ip-172-31-54-74 ~ % xcodeinstall download -s eu-central-1 -f -n "Xcode 16.4.xip" Downloading Xcode 16.4 100% [============================================================] 2895 MB / 180.59 MBs [ OK ] ✅ Xcode 16.4.xip downloaded ec2-user@ip-172-31-54-74 ~ % xcodeinstall install -n "Xcode 16.4.xip" Installing... [1/6] Expanding Xcode xip (this might take a while) [2/6] Moving Xcode to /Applications [3/6] Installing additional packages...XcodeSystemResources.pkg [4/6] Installing additional packages...CoreTypes.pkg [5/6] Installing additional packages...MobileDevice.pkg [6/6] Installing additional packages...MobileDeviceDevelopment.pkg [ OK ] ✅ file:///Users/ec2-user/.xcodeinstall/download/Xcode%2016.4.xip installed ec2-user@ip-172-31-54-74 ~ % sudo xcodebuild -license accept ec2-user@ip-172-31-54-74 ~ % 知っておくべきこと 開発目的で使用する場合は、少なくとも 200 GB の EBS ボリュームを選択してください。Xcode をインストールするには、100 Gb のデフォルトボリュームサイズでは不十分です。私は、通常 500 Gb を選択します。インスタンスの起動後に EBS ボリュームサイズを増やす場合は、 APFS ファイルシステムのサイズも忘れずに変更してください 。 別の手段として、Mac mini で利用できる低レイテンシーのローカル 2 Tb SSD ドライブに開発ツールとフレームワークをインストールすることも選択できます。そのボリュームのコンテンツは、専有ホストではなく、インスタンスライフサイクルに結び付けられていることに注意してください。つまり、インスタンスを停止して再起動すると、すべてのコンテンツが内部 SSD ストレージから削除されます。 mac-m4.metal インスタンスと mac-m4pro.metal インスタンスは、macOS Sequoia 15.6 以降をサポートします。 既存の EC2 Mac インスタンスは、移行したインスタンスが macOS 15 (Sequoia) を実行している場合に移行できます。既存のインスタンスからカスタム AMI を作成して、この AMI から M4 または M4 Pro インスタンスを起動してください。 最後に、私が作成したチュートリアルを参照することをお勧めします。これらのチュートリアルは、Amazon EC2 Mac の使用を開始するために役立ちます。 Start an Amazon EC2 Mac instance Connect to an Amazon EC2 Mac instance (3 つの異なる接続方法を紹介します) Build your applications faster with a CI/CD pipeline on Amazon EC2 Mac 料金と利用可能なリージョン 現在、EC2 M4 インスタンスと M4 Pro Mac インスタンスを利用できるのは米国東部 (バージニア北部) と米国西部 (オレゴン) リージョンですが、将来は他のリージョンでも利用可能になる予定です。 Amazon EC2 Mac インスタンスは、オンデマンドと Savings Plans の料金モデルを使用して、専有ホストとして購入できます。EC2 Mac インスタンスの料金は 1 秒単位で請求され、最小割り当て期間は Apple macOS ソフトウェアライセンス契約に従って 24 時間になっています。24 時間の最小割り当て期間が終了すると、ホストはいつでも解放でき、追加の契約は必要ありません。 私は Apple 開発者と密接に連携しているので、皆さんが開発サイクルを加速するためにこれらの新しいインスタンスをどのように使用するのかを見るのが楽しみです。パフォーマンスの向上、メモリ容量の増強、AWS サービスとの統合の組み合わせは、iOS、macOS、iPadOS、tvOS、watchOS、VisionOS プラットフォーム向けのアプリケーションを構築するチームに新たな可能性をもたらします。アプリケーション開発以外にも、Apple シリコンの Neural Engine を使用するこれらのインスタンスは、 機械学習 推論ワークロードを実行するためのコスト効率性に優れた候補になります。このトピックについては、AWS re:Invent 2025 で詳しくお話しする予定になっており、EC2 Mac インスタンスで機械学習ワークロードを最適化するためのベンチマークとベストプラクティスをご紹介します。 EC2 M4 インスタンスと M4 Pro Mac インスタンスの詳細については、Amazon EC2 Mac インスタンス ページ、または EC2 Mac ドキュメント を参照してください。これらのインスタンスは、AWS で Apple 開発ワークフローをモダナイズするために今すぐご利用いただけます。 – seb 原文は こちら です。

9 月 11 日、AWS は AWS Toolkit for Visual Studio Code への LocalStack の統合を発表しました。この統合により、開発者はサーバーレスアプリケーションのローカルでのテストとデバッグをこれまで以上に簡単に行えるようになります。この機能強化は、2025 年 7 月にリリースされた コンソールと IDE の統合やリモートデバッグ 機能などの 最近行われた AWS Lambda 開発エクスペリエンスの改善 を踏まえたもので、Amazon Web Services (AWS) でのサーバーレス開発を簡素化するという継続的な取り組みの一環です。 開発者がサーバーレスアプリケーションを構築するときは、テストエクスペリエンスを効率化するために、ユニットテスト、統合テスト、クラウド内で実行されているリソースのデバッグの 3 つの重要分野に焦点を当てるのが一般的です。 AWS サーバーレスアプリケーションモデルコマンドラインインターフェイス (AWS SAM CLI) は個々の Lambda 関数に優れたローカルユニットテスト機能を提供しますが、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon EventBridge 、 Amazon DynamoDB などの複数の AWS サービスを使用するイベントドリブンなアーキテクチャで作業を行っている開発者には、ローカル統合テストのための包括的なソリューションが必要です。LocalStack は AWS サービスのローカルエミュレーションを提供していましたが、開発者は LocalStack をスタンドアロンツールとして管理しなければならず、複雑な設定や複数のインターフェイス間における頻繁なコンテキストスイッチが必要であったため、開発サイクルの速度が低下する原因となっていました。 AWS Toolkit for VS Code への LocalStack 統合 これらの課題に対応するため、AWS は LocalStack 統合を導入して、開発者が AWS Toolkit for VS Code を LocalStack エンドポイントに直接接続できるようにしました。この統合により、開発者はツールを切り替えたり、複雑な LocalStack 設定を管理したりすることなく、サーバーレスアプリケーションのテストとデバッグを実行できます。開発者は、クラウドリソースに接続する必要があった複数のツールの管理、複雑なエンドポイント設定、サービス境界問題への対応を行わなくても、Lambda、Amazon SQS、EventBridge などのサービスを使用するイベントドリブンなワークフローをエンドツーエンドでエミュレートできるようになります。 この統合の主なメリットは、以前は不可能だった LocalStack などのカスタムエンドポイントへの AWS Toolkit for VS Code の接続が可能になったことです。これまで、AWS Toolkit for VS Code をその LocalStack 環境にポイントするには、開発者が手動設定とツール間でのコンテキストスイッチを行う必要がありました。 VS Code で LocalStack の使用を開始する方法は簡単です。開発者は、LocalStack の 無料 バージョンから始めることができます。このバージョンは、初期段階の開発とテストに最適な AWS のコアサービスのローカルエミュレーションを提供します。VS Code にあるガイド付きアプリケーションウォークスルーを使用することで、開発者は LocalStack をツールキットインターフェイスから直接インストールできます。このウォークスルーは、LocalStack 拡張機能を自動的にインストールし、セットアッププロセスをガイドします。設定されると、開発者は IDE を離れずに、サーバーレスアプリケーションをエミュレートされた環境に直接デプロイし、アプリケーションの機能をローカルでテストできます。 試してみましょう まず、AWS Toolkit for VS Code のコピーを最新バージョンに更新します。更新してから [Application Builder] に移動すると、新しいオプションが表示されているので、 [Application Builder のウォークスルー] をクリックします。そうすることで、LocalStack をワンクリックでインストールできます。 LocalStack のセットアップが完了したら、ステータスバーから起動できます。その後、 設定済みの AWS プロファイル のリストから LocalStack できるようになります。この画像では、Application Composer を使用して、 Amazon API Gateway 、Lambda、DynamoDB を使用するシンプルなサーバーレスアーキテクチャを構築しています。通常、私は AWS SAM を使用して AWS にデプロイします。今回も、同じ AWS SAM コマンドを使用してスタックをローカルにデプロイします。 コマンドラインから `sam deploy –guided –profile localstack` を実行して、いつものプロンプトに従うだけです。AWS SAM CLI を使用した LocalStack へのデプロイは、AWS へのデプロイで慣れ親しんだものとまったく同じエクスペリエンスを提供します。以下のスクリーンショットでは、AWS SAM からの標準的な出力と、AWS Toolkit Explorer にリストされている新しい LocalStack リソースを確認できます。 Lambda 関数にアクセスして、ローカルにデプロイした関数コードを編集することもできます! LocalStack のウェブサイトでは、ウェブサイトにログインして、私がローカルで実行しているすべてのリソースを見ることができます。以下のスクリーンショットでは、先ほどデプロイしたローカル DynamoDB テーブルを確認できます。 強化された開発ワークフロー これらの新しい機能は、最近リリースされたコンソールと IDE の統合やリモートデバッグ特徴量を補完することで、開発ライフサイクル全体のさまざまなテストニーズに対応する包括的な開発エクスペリエンスを生み出します。AWS SAM CLI は、個々の Lambda 関数に優れたローカルテスト機能を提供し、ユニットテストシナリオを効果的に処理します。統合テストでは、LocalStack 統合を通じて、開発速度を低下させる可能性のある AWS Identity and Access Management (IAM) 許可、Amazon Virtual Private Cloud (Amazon VPC) 設定、サービス境界問題の複雑性に煩わされることなく、マルチサービスワークフローをローカルにテストできます。 開発者が開発環境内で AWS サービスを使用してテストを実施する必要がある場合は、Amazon VPC リソースと IAM ロールへのフルアクセスを提供する、AWS のリモートデバッグ機能を使用できます。この多層的なアプローチにより、開発者は LocalStack を使用して開発の早い段階でビジネスロジックに集中し、AWS サービスの動作や設定に照らして検証する必要があるときはクラウドベースのテストにシームレスに移行できるようになります。この統合では、複数のツールや環境間の切り替えを行う必要がなくなるため、開発者は特定のニーズに適したテストアプローチを選択する柔軟性を維持しながら、問題をより迅速に特定して修正できます。 今すぐご利用いただけます これらの新特徴量は、v3.74.0 に更新した AWS Toolkit for VS Code を通じて使用を開始できます。LocalStack 統合は、 AWS GovCloud (米国) リージョンを除くすべての商用 AWS リージョン でご利用いただけます。詳細については、 AWS Toolkit for VS Code と Lambda のドキュメントをご覧ください。 より広範なサービスカバレッジや高度な機能が必要な開発者には、LocalStack がより多くの特徴量を備えた追加のティアを提供しています。この統合の使用に追加の AWS 料金はかかりません。 これらの機能強化は、サーバーレス開発エクスペリエンスを簡素化するという AWS の継続的な取り組みにおけるもう 1 つの大きな前進を表しています。この 1 年間、AWS は VS Code をサーバーレス開発者に選ばれるツールにすることに重点を置いてきました。LocalStack 統合は、サーバーレスアプリケーションをこれまで以上に効率的に構築してテストするためのツールを開発者に提供することで、このジャーニーを前進させます。 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 AWS Summit Japan 2025 の動画アーカイブが YouTube に公開 されています。もともと、AWS 登壇セッションが公開されていましたが、少し前にお客様の登壇セッションが追加されています。実際に活用いただいているお客様の発表内容は、貴重な経験を基にしたお話となっており、大変参考にいただける話が多いです。ぜひご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年9月8日週の主要なアップデート 9/8(月) Amazon CloudFront が IPv6 オリジンのサポートを発表 Amazon CloudFront で、オリジンサーバーへの IPv6 接続のサポートを開始しました。これまで、クライアントからの接続は IPv6 を受け付けていましたが、オリジンサーバーへは IPv4 でのみ接続が可能でした。今回のアップデートにより、オリジンサーバーへの接続も IPv6 通信が可能になり、IPv6 ネットワーク環境でのパフォーマンス向上や IPv4 アドレス枯渇問題の解決に貢献します。設定は IPv4 のみ、IPv6 のみ、デュアルスタックから選択でき、すべての商用リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 9/9(火) Amazon EC2 R8g インスタンスが追加リージョンで利用可能に Amazon EC2 R8g インスタンスが大阪リージョンとカナダ中部リージョンで利用開始となりました。最新の AWS Graviton4 プロセッサを搭載し、従来の Graviton3 ベースと比べて最大 30% の性能向上を実現しています。データベースやインメモリキャッシュなどメモリを大量に使うアプリケーションに最適で、従来の R7g と比べて最大 3 倍の vCPU とメモリを提供します。詳細は こちらをご参照ください。 Amazon ElastiCache が追加の AWS リージョンで M7g および R7g Graviton3 ベースノードをサポート Amazon ElastiCache で Graviton3 ベースの M7g と R7g ノードが、大阪、香港、パリなど 13 の新しいリージョンで利用可能になりました。従来の Graviton2 と比較して、スループットが最大 28 % 向上し、レイテンシが最大 21 % 改善されます。特に Redis を使用するアプリケーションで高いパフォーマンスが期待でき、ネットワーク帯域幅も最大 25 % 向上します。詳細は こちらのドキュメントをご参照ください。 9/10(水) AWS がセキュリティ分析強化のための CloudTrail MCP Server を開始 AWS Labs MCP オープンソースリポジトリ に CloudTrail MCP Server をリリースしました。この新機能により、AI エージェントが自然言語でセキュリティ分析を実行できるようになります。従来は複雑な API 統合が必要でしたが、今回のアップデートで会話形式での操作が可能となり、90日間の管理イベント履歴検索や CloudTrail Lake での最大 10年間のデータ分析が簡単に行えます。詳細は こちらの GitHub リポジトリをご参照ください。 Amazon Bedrock AgentCore Gateway が AWS PrivateLink 呼び出しと呼び出しログ記録をサポート Amazon Bedrock AgentCore Gateway で 「AWS PrivateLink 対応」と、「Amazon CloudWatch、Amazon S3、Amazon Data Firehose を通じた呼び出しログ記録」をサポートしました。これにより VPC 内から直接アクセスでき、パブリックインターネットを経由せずセキュアに AI エージェントツールを利用できます。また CloudWatch や S3 を通じてログ記録が可能になり、エージェントの動作監視や監査が容易になりました。現在 AgentCore は Preview となっており、バージニア北部、オレゴン、シドニー、フランクフルトリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 AWS CDK Refactor (プレビュー) の紹介 AWS CDK で新機能「cdk refactor」コマンド (プレビュー版) が利用可能になりました。インフラのリファクタリングを安全に実行できる機能で、コンストラクトの名前変更やスタック間でのリソース移動、CDK アプリケーションの再編成が可能です。従来は論理 ID の変更によりリソース置換のリスクがありましたが、この機能によりデプロイ済みリソースの状態を保持しながらコード構造を改善できます。詳細は こちらの Blog 記事をご参照ください。 9/11(木) Amazon Athena がドライバーでのシングルサインオンサポートを開始 Amazon Athena で、 AWS IAM Identity Center の信頼できるアイデンティティ伝播を通じて、JDBC および ODBC ドライバーのシングルサインオン (SSO) 対応が開始されました。これまでは各ツールで個別に認証情報を管理する必要がありましたが、企業の認証情報を使って BI ツールや SQL クライアントから直接 Athena にアクセスできるようになります。Lake Formation で設定したアクセス権限も自動適用されるため、データガバナンスを保ちながら分析作業を効率化できます。詳細は こちらのドキュメントをご参照ください。 9/12(金) Amazon SageMaker Unified Studio が VS Code からのリモート接続をサポート Amazon SageMaker Unified Studio で VS Code からのリモート接続機能が提供開始されました。これまでローカルの VS Code 環境とクラウドの ML 開発環境は別々でしたが、今回の機能により慣れ親しんだ VS Code の設定やワークフローをそのまま維持しながら SageMaker のスケーラブルなコンピュートリソースにアクセスできるようになりました。AWS Toolkit 拡張機能を使った簡単な認証でデータ処理や ML ワークフローを実行でき、開発効率が向上します。詳細は こちらのドキュメントをご参照ください。 Amazon RDS Proxy がエンドツーエンド IAM 認証のサポートを発表 Amazon RDS Proxy で、エンドツーエンド IAM 認証がサポートされました。これまでデータベース接続時に Secrets Manager での認証情報管理が必要でしたが、今回のアップデートにより IAM 認証のみでの接続が可能になりました。認証情報のローテーション作業が不要となり、運用負荷が軽減されます。詳細は こちらのドキュメントをご参照ください。 S3 向けマルウェア保護がファイルサイズとアーカイブスキャン制限を拡張 GuardDuty Malware Protection for S3 のスキャン機能を強化しました。従来は 5GB までのファイルしかスキャンできませんでしたが、今回のアップデートで 100GB まで対応可能になりました。また、アーカイブファイル内の処理可能ファイル数も 1,000 個から 10,000 個に拡張されています。これにより、大容量の動画ファイルや大量のファイルが含まれた ZIP アーカイブなども安全にスキャンできるため、より包括的なセキュリティ保護が実現できます。この機能強化は全サポートリージョンで自動的に有効化されます。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 M4 および M4 Pro Mac インスタンスの一般提供開始を発表 Amazon EC2 で M4 と M4 Pro Mac インスタンスの一般提供が開始されました。M4 は従来の M2 と比べて最大 20% 、M4 Pro は M2 Pro と比べて最大 15% のアプリケーションビルド性能向上を実現します。iOS や macOS など Apple プラットフォーム向けアプリの開発・テストに最適で、複数の Xcode シミュレータを並列実行することで開発サイクルを大幅に短縮できます。バージニア北部とオレゴンリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon ECS Service Connect がクロスアカウントワークロードのサポートを追加 Amazon ECS Service Connect がクロスアカウントワークロードに対応しました。AWS Resource Access Manager (RAM) との統合により、異なる AWS アカウント間でのサービス通信がシームレスに実現できます。従来は同一アカウント内でのみ利用可能でしたが、今回のアップデートで複数アカウントにまたがる大規模な組織でも効率的なサービス間通信が可能になりました。プラットフォームエンジニアは共通の名前空間を使用して複数アカウントのサービスを管理でき、運用負荷の軽減とリソースの重複回避が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS Japan の技術職の方を中心とした、 Zenn Publication を新たに作りました。AWS Japan の従業員が持つ知識や経験を元にした記事を出していくスペースとなっており、よろしければこちらも活用いただけると幸いです。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。最近若干？の涼しさを感じる日も増えてきましたが、皆さまいかがお過ごしでしょうか。先週はAWS Amazon Nova Igniteの開催発表（ 申し込みはこちら ）や、Amazon Bedrockの新機能アップデートなど、生成AIの実運用に役立つニュースが盛りだくさんでした。今週も引き続き、現場ですぐに活用できる事例やサービスアップデートをピックアップしてお届けしますので、ぜひご一読ください。 新たに2つのプランが追加された「 AWS ジャパン生成 AI 実用化推進プログラム 」も、たくさんのお申し込みをいただいています。企業やプロジェクト単位でもまだまだ募集中ですので、この機会にご活用いただけますと幸いです。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース 資料公開 & 開催報告 「AWS for Software & Technology | Builders Forum Tokyo – AI Agent 時代の SaaS イベントを開催しました」 このブログは、2025年9月3日に開催されたAWS主催のイベント「AI Agent時代のSaaS」の詳細レポートです。300名以上が参加したこのイベントで紹介された、AIエージェント技術の最新動向と実践的な活用事例について詳しく解説しています。ブログでは、フリー、kubell、エムオーテックスの3社による貴重な導入事例が紹介されており、特に「まほう経費精算」での業務効率化や、Amazon Q Developerの全社導入により月600時間の効率化を実現した具体的な取り組みが詳細に説明されています。また、AWSのソリューションアーキテクトによる3つの技術セッションでは、マルチテナント環境でのAIエージェント設計思想、Observability、セキュリティという本番運用に欠かせない要素が包括的に解説されています。さらに、初心者向けから上級者向けまでのワークショップの内容や、Amazon Bedrock Knowledge Basesを活用したRAGの実装方法も紹介されており、実際に手を動かして学べる貴重な学習機会の様子も詳しくレポートされています。イベントの全資料も公開されていますので是非ご参照ください。 ブログ記事「チャットから仕様へ : Kiro を用いた AI 支援開発の深掘り」 AIコーディングアシスタントを使っていて「要件を整理するのに1時間かかったのに、肝心のコードは思うように生成されない」という経験はありませんか？今回ご紹介する記事では、この課題を根本から解決する新しいIDE「Kiro」と、その革新的な「仕様駆動型開発」のアプローチについて詳しく解説しています。記事では、従来のAIコーディングアシスタントがなぜ非効率になってしまうのかという根本原因から始まり、Kiroがどのようにstructure.md、tech.md、product.mdなどの基礎ドキュメントを自動生成し、その後requirements.md、design.md、tasks.mdという詳細仕様を作成することで開発プロセスを変革するかを具体的なワークフロー例とともに紹介しています。 ブログ記事「Kiro の AI エージェントフックで開発ワークフローを自動化する」 開発プロジェクトが成長するにつれて、ドキュメントの更新やテストの同期など、重要だけれど繰り返し発生する作業に多くの時間を取られていませんか？このブログではエージェント型IDE「Kiro」の革新的な「エージェントフック」機能について詳しく解説しています。ブログでは、従来の受動的なAI支援から能動的なAI統合への転換を実現するエージェントフックの仕組みを、具体的な設定方法とともに紹介しています。エージェントフックは、ファイルの保存や編集といったトリガーイベントに対して、AIが自動的にテスト更新やドキュメント同期などのアクションを実行する機能で、自然言語による設定が可能です。ブログでは、TypeScriptプロジェクトでのユニットテスト自動更新やPythonアプリケーションでのテスト生成、APIドキュメントの自動同期など、実際の開発現場で即座に活用できる具体的な実装例が豊富に紹介されています。また、フックの設定からチーム共有、ベストプラクティスまで、実際の運用に必要な知識が体系的にまとめられています。 サービスアップデート Amazon SageMaker Unified StudioにおけるAIアシスタント機能の改善 Amazon SageMaker Unified Studioの開発環境において、Amazon Q Developerのチャット機能が改善され、Jupyter NotebookとCode Editorでのコマンドライン操作時にもAmazon Q Developerが利用可能になりました。Model Context Protocol (MCP)サーバーとの統合により、プロジェクトのリソース（データ、コンピューティング、コードなど）を認識し、データエンジニアリングや機械学習開発作業において、より個々に合わせたサポートを提供できるようになります。コードのリファクタリングやファイルの修正、トラブルシューティングなどのタスクに対して、より関連性の高い支援が可能になり、開発者の生産性向上に貢献します。この機能はAmazon Q Developer Free Tierで無料で利用でき、Amazon SageMaker Unified Studioが利用可能なすべてのAWSリージョンで提供されています。 Amazon Q in Connect が Connect Web UI で直接LLMを選択可能に カスタマーサービス向けの生成AI搭載アシスタント「Amazon Q in Connect」において、コンタクトセンターの管理者がAmazon Connect web UIから直接異なる大規模言語モデル（LLM）を選択できるようになり、AIエージェントの設定がよりシンプルになりました。管理者はコードを書くことなく、ビジネスニーズに合わせて最適なLLMを選択できます。例えば、素早いレスポンスが必要な場合はAmazon Nova Proを、複雑な推論が必要な場合はAnthropic Claude Sonnetを選択するなど、顧客とのやり取りの種類に応じて柔軟にモデルを切り替えることが可能です。 Amazon BedrockでTwelveLabs’ Marengo Embed 2.7の同期推論が利用可能に Amazon BedrockでTwelveLabs社のMarengo 2.7モデルの同期推論がサポートされるようになりました。これまでは動画や音声ファイルなどの大容量コンテンツ処理に特化した非同期推論のみでしたが、今回のアップデートによりテキストや画像の埋め込みベクトル生成において低遅延での同期処理が可能になりました。これにより、自然言語クエリによる瞬時の動画検索や、画像の類似性を使ったインタラクティブな商品発見など、よりレスポンシブな検索・検索体験を構築できるようになります。一般ユーザーにとっては、動画コンテンツから特定のシーンを素早く見つけたり、商品画像から類似商品を即座に発見できるなど、より直感的で高速な検索体験が提供される点が大きな価値となります。生成AIを活用している開発者にとっては、マルチモーダル埋め込みモデルの高度な機能を低遅延で活用できることで、リアルタイム性が求められるアプリケーションの開発が格段に容易になり、ユーザーエクスペリエンスの向上と開発効率の改善を同時に実現できます。 Amazon Bedrock AgentCore GatewayがAWS PrivateLinkの呼び出しと呼び出しログ機能をサポート Amazon Bedrock AgentCore Gatewayにおいて、AWS PrivateLinkによる呼び出しと、Amazon CloudWatch、Amazon S3、Amazon Data Firehoseを通じたinvocation loggingがサポートされるようになりました。AgentCore Gatewayは開発者がエージェントツールを安全かつ大規模に構築、デプロイ、発見、接続するための基盤を提供するサービスです。AWS PrivateLinkサポートにより、VPC内のユーザーやエージェントがパブリックインターネットを経由することなく、プライベートネットワーク経由でAgentCore Gatewayにアクセスできるようになり、セキュリティが大幅に向上します。また、呼び出しログを使用すると、各呼び出しログを可視化し、問題や監査アクティビティを深く掘り下げることができます。Amazon Bedrock AgentCore は現在プレビュー段階で、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジア太平洋 (シドニー)、およびヨーロッパ (フランクフルト) でご利用いただけます。 AWSがセキュリティ分析強化のためのCloudTrail MCP Serverを発表 AWS Labs MCPオープンソースリポジトリ にAWS CloudTrail用のModel Context Protocol（MCP）サーバーを追加しました。これにより、AIエージェントが会話形式のインターフェースを通じて、CloudTrailの包括的なセキュリティおよびコンプライアンス機能を活用できるようになります。AIアシスタントはAPI呼び出しの分析、ユーザーアクティビティの追跡、AWS環境全体での高度なセキュリティ分析を自然言語で実行でき、90日間の管理イベント履歴の検索や最大10年間のCloudTrail LakeデータへのTrino SQLも実行可能です。セキュリティ担当者にとっては、複雑なセキュリティ調査やコンプライアンスワークフローが大幅に効率化され、専門的な技術知識がなくても直感的にセキュリティ分析を実行できる点が大きな価値となります。カスタムAPI統合を構築することなく、AIエージェントが自然言語でセキュリティデータにアクセスし、高度な分析を自動化できることで、セキュリティ運用の自動化と効率性が向上します。 Amazon SageMakerノートブックがP6-B200インスタンスタイプをサポート Amazon SageMakerノートブックでAmazon EC2 P6-B200インスタンスの一般提供が開始されました。P6-B200 インスタンスには、1440 GB の高帯域幅 GPU メモリを搭載した 8 機の NVIDIA B200 GPU、第 5 世代インテル Xeon スケーラブルプロセッサ (Emerald Rapids)、2 TiB のシステムメモリ、30 TB のローカル NVMe ストレージが搭載されており、従来のP5enインスタンスと比較してAIトレーニングで最大2倍の性能向上を実現します。LLM、MoEモデル、マルチモーダル推論モデルなどの大規模ファウンデーションモデルの開発やファインチューニングが可能で、JupyterLabやCodeEditor環境で効率的に実験できるようになり開発サイクルの短縮と、より高品質なAIモデルの構築が実現できます。Amazon EC2 P6-B200 インスタンスは、AWS 米国東部 (オハイオ) および米国西部 (オレゴン) リージョンの SageMaker ノートブックで利用できます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、ハーブを育てるのにハマっています。

私が住んでいるオランダの都市、ユトレヒトでは、夏も終わりを迎えました。2 週間後の 9 月 24 日、私は Kinepolis Jaarbeurs Utrecht で開催される AWS Community Day 2025 に出席する予定です。この 1 日限りのイベントでは、オランダ全土から 500 人を超えるクラウドプラクティショナーが集まり、5 つのテクニカルトラックで合計 25 のブレイクアウトセッションが行われます。当日は、午前 9 時の仮想基調講演で始まります。その後、サーバーレスアーキテクチャの実用的な実装とコンテナ最適化戦略に焦点を当てた 2 つのブレイクアウトセッションが並行して行われ、経験レベルを問わない貴重なインサイトを提供します。 2025 年の AWS Community Day Netherlands 2024 では、さまざまなクラウドプラクティショナー、講演者、AWS 愛好家が一堂に会し、コミュニティ主導のカンファレンスを貴重な知識共有プラットフォームにしてくれました。今回の Community Day に参加する予定ならば、いつでも私に声をかけてください。AWS サービスや、クラウド実装の経験について語り合いましょう! では、9 月 1 日週の新しい発表を見てみましょう。 9 月 1 日週のリリース AWS Transform 評価がデタッチドストレージ分析の提供を開始 – AWS Transform の評価機能が拡大され、オンプレミスのデタッチドストレージインフラストラクチャを分析できるようになりました。この機能は、お客様が移行の総保有コスト (TCO) を判断するために役立ちます。新しい評価機能は、ストレージエリアネットワーク (SAN)、ネットワークアタッチドストレージ (NAS)、ファイルサーバー、オブジェクトストレージ、仮想環境を評価して、Amazon S3、Amazon EBS、Amazon FSx などの適切な AWS サービスへの移行に関する推奨事項を提供します。このツールは、パフォーマンスとコストの最適化に関する推奨事項に加えて、現在の環境と AWS 環境の包括的な TCO 比較も提供します。ストレージは移行機会全体の最大 45% を占めていることから、お客様はこの機能強化を使用してさまざまな AWS 移行オプションを視覚化できます。AWS Transform 評価は、米国東部 (バージニア北部) リージョンと欧州 (フランクフルト) リージョンでご利用いただけます。 Amazon Bedrock が Anthropic Claude Sonnet 4 のグローバルクロスリージョン推論を導入 – Amazon Bedrock で Anthropic の Claude Sonnet 4 モデルがグローバルクロスリージョン推論のサポートを開始し、推論リクエストを任意の対応商用 AWS リージョンにルーティングして処理できるようになりました。この機能強化は利用可能なリソースを最適化するとともに、複数のリージョンにトラフィックを分散することで、より高いモデルスループットを実現します。これまでは、特定の地域 (米国、EU、または APAC) に関連付けられたクロスリージョン推論プロファイルの選択が可能でしたが、新しいグローバルクロスリージョン推論プロファイルは、地域固有の処理を必要としない生成 AI ユースケースの柔軟性を高めるため、計画外のトラフィックバーストの管理やモデルスループットの向上に役立ちます。詳しい実装ガイダンスについては、 Amazon Bedrock ドキュメント を参照してください。 Amazon Neptune データベースがパブリックエンドポイントのサポートを追加 – Amazon Neptune がパブリックエンドポイントのサポートを開始し、複雑なネットワーク設定を行わなくても VPC 外から Neptune データベースに直接接続できるようになりました。この特徴量は、IAM 認証、VPC セキュリティグループ、転送時の暗号化を用いてセキュリティを維持しながら、開発者が VPN 接続や踏み台ホストを必要とすることなく、開発デスクトップからグラフデータベースにセキュアな方法でアクセスできるようにします。パブリックエンドポイントは、AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して、エンジンバージョン 1.4.6 以降を実行している Neptune クラスターで有効化できます。この特徴量は、Neptune データベースが提供されているすべての AWS リージョンで、Neptune の標準料金以外の追加料金なしでご利用いただけます。実装の詳細は、 Amazon Neptune ドキュメント に記載されています。 AWS マネジメントコンソールでの ECS Exec の提供開始 – Amazon ECS が AWS マネジメントコンソールで ECS Exec を直接サポートするようになりました。このため、インバウンドポートや SSH キー管理を必要とすることなく、実行中のコンテナへのセキュアでインタラクティブなシェルアクセスが可能になります。これまでは API、CLI、SDK 経由でしか利用できなかったこの特徴量は、コンソールインターフェイスからコンテナに直接アクセスできるようにすることで、トラブルシューティングを効率化します。ECS Exec は、サービスやスタンドアロンタスクの作成時や更新時に有効化できます。その後、タスク詳細ページで [接続] を選択してコンテナに接続すると、CloudShell 経由でインタラクティブなセッションが開始されます。コンソールには、ローカルターミナルで使用するための基盤となる AWS CLI コマンドも表示されます。この特徴量はすべての商用 AWS リージョンで利用でき、「 ECS デベロッパーガイド 」に説明が記載されています。 AWS User Notifications の組織的な通知設定の一般提供開始 – AWS User Notifications が組織的な通知設定をサポートするようになりました。この機能は、AWS Organizations ユーザーが組織全体の通知を一元的に設定し、表示するために役立ちます。特定の組織部門、または組織内のすべてのアカウントに対する通知は、管理アカウント、または委任された管理者が設定できます。このサービスは、MFA を使用しないコンソールサインインなどのサポート対象 Amazon EventBridge イベントに関する通知の設定をサポートし、通知は管理者のコンソール通知センターと AWS コンソールモバイルアプリケーションに表示されます。ユーザー通知は委任された管理者を最大 5 人サポートし、AWS User Notifications が提供されているすべての AWS リージョンでご利用いただけます。実装の詳細については、「 AWS User Notifications ユーザーガイド 」を参照してください。 AWS からのお知らせのすべてが記載されたリストについては、「AWS の最新情報」ページをご確認ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – クラウドコンピューティングコミュニティが交流し、コラボレートして、AWS について学ぶために一堂に会する無料のオンラインイベントと対面イベントに参加しましょう。最寄りの都市で開催されるイベントにご登録ください。日程は、 チューリッヒ (9 月 11 日)、 ロサンゼルス (9 月 17 日)、 ボゴタ (10 月 9 日) です。 AWS re: Invent 2025 – 12 月 1 日から 5 日は、最新の AWS イノベーション、ピアツーピア学習、エキスパート主導のディスカッション、貴重なネットワーキング機会のために世界中のクラウドパイオニアが米国ラスベガスに集結する AWS re:Invest に参加しましょう。 イベントカタログ の確認もお忘れなく。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18 日)、 南アフリカ (9 月 20 日)、 ボリビア (9 月 20 日)、 ポルトガル (9 月 27 日) です。 近日開催される AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 9 月 8 日週のニュースは以上です。9 月 15 日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

はじめに Windows 10 のサポート終了が近づいており、エンドユーザーコンピューティング管理者はユーザーを Windows 11 の仮想デスクトップに移行する必要があります。 Amazon WorkSpaces はセルフサービスによる BYOL（Bring Your Own License）有効化機能 を提供開始しました。この新機能により、BYOL を有効化するために サポートケースを開く必要がなくなりました。BYOL を有効化することで、Amazon WorkSpaces のユーザーはカスタム Windows イメージ、ISO、または既存の AMI をインポートできるようになります。 改善された BYOL フレームワークは、以下のハイレベルな手順で構成されています： 1.WorkSpaces コンソールで BYOL を有効化し、最小限の WorkSpaces 要件に同意する 2.有効化後、Windows VM イメージを Amazon S3 にアップロードし、WorkSpaces コンソールからインポートする 3.WorkSpaces は自動的に EC2 Image Builder のパイプラインを生成し、イメージをビルド、テストして互換性に関する問題を解決する 4.イメージのインポートが成功したら、 カスタムバンドル を作成して Amazon WorkSpaces をプロビジョニングする 前提条件: 1.WorkSpaces をサポートする AWS リージョンを使用していることを確認する 2.BYOL を有効化するために、 最低限の WorkSpaces 利用コミットメント に同意する 注意: GovCloud リージョンではアカウントの自動有効化は利用できません。BYOL を有効化するには AWS サポートにケースを開く必要があります。ISO インポートオプションは GovCloud リージョンでは利用できません。 Amazon WorkSpaces での BYOL の有効化 1.WorkSpaces コンソールを開く 2.左側のナビゲーションペインで アカウント設定 を選択 3. ライセンス持ち込み (BYOL) のセクションで、「 BYOL を今すぐ開始する 」を選択し、「 BYOL のアカウントを有効にする 」をクリック 4. BYOL の最小要件 に同意するチェックボックスにチェックを入れ、「 アカウントを有効にする 」をクリック 5.BYOL が有効化されたらイメージをインポートして、WorkSpaces 管理インターフェイスの IP 範囲を選択 WorkSpaces BYOL イメージのインポート 1.WorkSpaces コンソールの「イメージ」タブに移動し、「イメージのインポート」を選択 2.Windows イメージをインポートするためのウィザードが表示されます。以下 3 つのオプションがあります: VM Import: 事前にカスタマイズされた仮想マシンイメージをインポートします。VHDX、VMDK、OVF ファイルをインポートできます ISO Import: Microsoft からダウンロードしたカスタマイズされていない Windows ISO イメージをインポートします AMI Import: 既存の EC2 AMI を WorkSpaces BYOL イメージとしてインポートします 3.次に、必要な VM イメージをアップロードした S3 バケットの場所を イメージソース として指定します。 4. インフラストラクチャ設定 では、EC2 Image Builder から既存のインフラ構成を選択するか、新しいものを作成します。これは、イメージを構築する際の設定をカスタマイズするために使用されます。詳細は AWS ドキュメント を参照してください 5. イメージの詳細 を指定し、必要に応じて タグ を追加します。タグにより、イメージやコストの追跡に必要なメタデータが生成されます WorkSpaces BYOL イメージのインポートプロセスでは、EC2 Image Builder が使用され、自動的に修復を試みますが、場合によっては手動での対応が必要になる場合があります。その際は、EC2 ビルドインスタンスにアクセスして修正を行い、WorkSpaces コンソールから再度インポートを試みてください。 トラブルシューティングガイド も参照可能です。 BYOL 管理用 IP アドレス範囲の選択 1.BYOL イメージのインポートが正常に完了した後、左ペインの アカウント設定 に移動する 2. ライセンス持ち込み（BYOL） の「 BYOL を今すぐ開始する 」をクリック 3. IP アドレス範囲を選択する にて、 「 IP アドレス範囲を選択する 」をクリック 3.検索範囲で絞り込み、Select CIDR block で選択して「 送信 」をクリック 一度 IP アドレス範囲を指定すると、後から変更することはできません。内部ネットワークと衝突しないアドレス範囲を指定してください。IP アドレス範囲に関するガイダンスやご質問がある場合は、 AWS サポート またはアカウントチームにご相談ください。 アカウントのリンク アカウントをリンクすることで、同じ基盤となる BYOL ハードウェアと管理インターフェイスを使用できます。以前アカウントのリンクは WorkSpaces API からのみ可能でしたが、WorkSpaces コンソールでリンク招待を送信することで、アカウントをリンクできるようになりました。 まとめ 新しい WorkSpaces BYOL イメージインポートプロセスの改善により、仮想化デスクトップの移行が大幅に簡素化されました。WorkSpaces の他の機能やメリットについては、 製品ページ をご覧ください。 AWS サポートチームは、これらの機能を環境に導入する際の質問に対応する準備ができています。最新のエンドユーザーコンピューティングのイノベーションについては「 What’s New with AWS 」をフォローしてください。詳細な手順とベストプラクティスについては、 YouTube プレイリスト にサブスクライブしてください。 このブログは Senior Product Manager の Brandon How、Senior Specialist Solutions Architect の Joe Jabbour と Senior Specialist Solutions Architect の Shantanu Padhye によって書かれた「 Introducing an Improved BYOL Image Import Process for Amazon WorkSpaces 」の翻訳です。 翻訳は Senior Solutions Architect の森が担当しました。

本記事は米国時間 2025 年 7 月 16 日に公開された Automate Your Development Workflow with Kiro’s AI Agent Hooks を翻訳したものです。 ソフトウェアプロジェクトが成長するにつれ、ドキュメント、テスト、コードの可読性、パフォーマンスを同期させ続けることはますます難しくなります。Kiro のエージェントフックは、こうした重要な作業をバックグラウンドで自動的に処理し、コーディング中の集中を保ちながら、毎回高品質なコードを出荷できるように支援します。 エージェント型 IDE である Kiro は、複雑なワークフローを簡素化する新しい手段としてエージェントフックを導入しました。これらのカスタム AI 駆動のトリガーは、コーディング活動にリアルタイムで反応し、テストの更新、ドキュメントの同期、コードベース全体でのコーディング規約の適用といった作業を処理します。 Kiro のエージェントフックは、受動的な AI 支援から能動的な AI 統合への根本的な転換を示しており、開発環境がニーズを予測して自動的に動く知的なパートナーへと進化します。 本記事では、Kiro のエージェントフックのセットアップ方法と使用方法を紹介し、これらのフックが開発ワークフローをどのように変革できるかを示す実践例を解説します。 Kiro のエージェントフックとは？ Kiro の エージェントフック は、ワークスペースのイベントを AI 駆動のアクションに接続するインテリジェントな自動化ルールです。開発環境における「if-then」ロジックのようなもので、自然言語 AI がコードやコンテキストを理解して動作します。つまり、Kiro のフックは、ワークスペースのアクティビティと Kiro に組み込まれた強力なエージェント機能をつなぐ橋渡しです。 フックは 2 つの主要コンポーネントから成ります: トリガー : フックを起動するイベント（ファイルの保存、編集、作成、削除など） アクション : 自動的に実行される AI 駆動の応答（コード生成、ファイル更新、ドキュメント作成など） 主な利点 タスクにユーザーの指導や専門知識が必要な場合、Kiro はマルチモーダルなエージェントチャットを通じて制御を維持します。Kiro のエージェントはコードを超えた思考を促し、難しいエンジニアリング課題を自信を持って解決できるように支援します。エージェントフックには従来の自動化を超える数多くの利点があります。 自然言語による設定 : 複雑なスクリプトではなく平易な英語でフックを定義可能 コンテキスト認識 AI : コードベースの構造を理解し、知的な判断を迅速に実行 リアルタイム実行 : 作業と同時にアクションが発生し、開発の流れを維持 協調的 : エージェントフックをバージョン管理を通じてチームと共有可能 カスタマイズ可能 : ワークフローやコーディングパターンに合わせて調整可能 最初のエージェントフックを設定する クイックスタート手順 TypeScript プロジェクトのユニットテストをコードと同期させ続けるフックを作成してみましょう。 フックパネルを開く : アクティビティバーの Kiro アイコンをクリックし、サイドバーから「Agent Hooks」を選択 フックを作成 : パネルの「+」ボタンをクリックし、 希望するフックを自然言語で記述する または既存のテンプレートから選択する 図 1: Kiro フックパネルのインターフェース。自然言語入力フィールドを使ったフック作成とサンプルプロンプトの表示 オプションを設定 : タイトル、説明、イベントタイプ、ファイルパターン、プロンプトを確認・調整 図 2: ユーザー入力に基づいて作成されたフック設定を表示する Kiro フックパネルのインターフェース フックを作成 : フックを作成すると IDE のフックパネルに表示され、 .kiro/hooks ディレクトリに対応する設定ファイルが生成されます。 { "name": "TypeScript Test Updater", "description": "Monitors changes to TypeScript source files and updates corresponding test files with tests for new functions or methods", "version": "1", "when": { "type": "fileEdited", "patterns": [ "**/*.ts", "!**/*.test.ts", "!**/*.spec.ts", "!**/node_modules/**" ] }, "then": { "type": "askAgent", "prompt": "I noticed you've edited a TypeScript file. I'll analyze the changes and update the corresponding test file. 1. First, I'll identify any new functions or methods added to the source file 2. Then I'll locate or create the corresponding test file (either .test.ts or .spec.ts in the same directory) 3. I'll generate appropriate test cases for the new functions/methods 4. I'll ensure the tests follow the project's existing testing patterns and conventions Here are my suggested test updates based on your changes:" } } フック設定オプション 一般オプション name: フック名 description: フックの説明 トリガーオプション when type: fileEdit: ファイル変更の監視 fileCreate: 新規ファイル作成に応答 fileDelete: ファイル削除イベントの処理 userTriggered: 手動トリガー patterns: GLOB パターンでファイルやディレクトリ構造を指定 アクションオプション then type: askAgent: AIエージェントに完全なコンテキストを含むカスタムプロンプトを送信する prompt: フック起動時に Kiro に取らせたいアクションを記述 フックの管理 Kiro のフックパネルでは以下が可能です。 フックの有効化/無効化 設定の編集 フックの削除 図 3: アクティブなフックと設定オプションを表示する Kiro フックパネルのインターフェース また、 .kiro/hooks ディレクトリの設定ファイルを直接編集することもできます。 実際の利用例 テスト同期 : ソースコードの変更に合わせてユニットテストを更新 ドキュメント更新 : 新機能追加時に README を自動更新 国際化サポート : ドキュメントを英語との間で翻訳 Git アシスタント : Git diff に基づく changelog 生成、コミットメッセージ補助 コンプライアンスチェック : 標準への準拠を自動確認 スタイル統一 : フォーマットやコーディング規約を自動適用 例 1: 自動テスト生成 シナリオ : Python アプリケーションを開発しており、テストをコンポーネントと常に同期させたい。 フックの説明 : You are a test-driven development assistant. The user has modified a Python source file. Your task is to: 1. Analyze the changes in the source file 2. Identify any new functions, methods, or classes that were added 3. Update or create the corresponding test file (same filename but with test_ prefix) 4. Add appropriate test cases for the new functionality 5. Ensure test coverage for the new code while maintaining existing tests, Focus on writing practical, meaningful tests that verify the behavior of the new code. Use the existing testing patterns in the project if available. If using unit test, add new test methods to the appropriate test class. If using pytest, add new test functions. 監視対象のファイルパス *.py: all the python files !test_*.py: exclude the files that start with test_ and ends with .py 何が起きるか   : Python ファイルを変更するたびに、Kiro が変更をレビューし、テストファイルを更新して新しい機能の包括的なカバレッジを維持します 図 4: Python ファイルの変更後にテストファイルを自動的に更新する Kiro エージェントフック Example 2: ドキュメント同期 シナリオ : API ドキュメントをコード変更と常に一致させたい。 フックの説明 : Monitor all my typescript files and review the API changes in workspace and update the corresponding documentation in docs/api/. Include new endpoints, parameter changes, and response formats. Maintain consistent documentation style. 監視対象のパス :  **/*.ts, **/*.tsx: all the files with ts and tsx extension. 結果 : API ドキュメントがコード変更を自動的に反映し、ドキュメントが古くなるという一般的な問題を解消します。 Kiro エージェントフックのベストプラクティス 以下は、Kiro のエージェントフックを始める際のヒント、コツ、ベストプラクティスです。 シンプルに始める ソースコード変更時にテストを更新するといった基本的なファイル間の関係から始めてください。すぐに価値を実感でき、慣れてきたらより複雑なワークフローへ発展できます。 説明的なプロンプトを使用する フックプロンプトに多くのコンテキストを提供するほど、AI が意図を正確に理解します。 // Good "Update the test file to cover the new authentication method, including edge cases for invalid tokens and expired sessions" // Better "Review the authentication changes in this file and update tests/auth.test.js to include comprehensive tests for the new authentication method. Cover success cases, invalid token scenarios, expired session handling, and ensure all tests follow our existing test patterns using Jest and supertest." ワークスペースのコンテキストを活用する プロジェクトのドキュメント、コーディング規約、パターンをフックプロンプトで参照して一貫性を維持します。 // Good "Update or create new test files to cover the new functions, make sure to include multiple tests for each function to cover different paths." // Better "Update or create new test files to cover the new functions, make sure to include multiple tests for each function to cover different paths. Look at the existing unit tests and follow the same format and use the same testing libraries used, read the package.json file to understand how we initiate the unit tests." 監視と改善 チャット履歴を利用してフックの動作を確認し、結果に基づいてプロンプトを改善してください。 図 5: 過去のフック実行を表示するチャット履歴 チームコラボレーション フックをバージョン管理にコミットしてチームと共有できます。新しく作成したフックは .kiro/hooks ディレクトリに保存されるため、すぐに共有可能です。変更をプッシュすれば、チームメイトがプルしてすぐに利用できます。これは、チームとともに成長する自動化レシピ集を共有するようなものです。 自動化の未来はフックにある Kiro のエージェントフックは、日常的な開発作業に知的な自動化をもたらし、繰り返し作業を処理することで創造的な問題解決に集中できるようにします。フォーマットの好みからデプロイ手順まで、コーディングパターンを学習し、プロジェクト全体で一貫性を維持するスマートアシスタントのように機能します。自然言語による設定で高度な自動化を誰でも利用でき、AI 駆動のアクションは知的で文脈に沿った変更をガイドします。 個人開発でも時差のあるチーム開発でも、Kiro のエージェントフックは自然にワークフローに適合します。チームは自動化レシピをコードのように共有・バージョン管理でき、プロジェクトに合わせた時間節約ツールのライブラリを拡張していけます。コードフォーマットの標準化やテスト実行の自動化といった基本から始め、慣れるにつれて複雑なワークフローへと拡張することで、スムーズで効率的な開発サイクルを実現できます。 ぜひ試してみませんか？Kiro は無料で始められ、ドキュメントには最初のフックを作成するために必要なすべての情報が揃っています。私たちは、より良いコードを効率的に書くために支援します。 X 、 LinkedIn 、 Instagram では @kirodotdev、 Bluesky では @kiro.dev をタグ付けし、ハッシュタグ #builtwithkiro を使って成果をシェアしましょう。

本記事は米国時間 2025 年 7 月 15 日に公開された From Chat to Specs: A Deep Dive into AI-Assisted Development with Kiro を翻訳したものです。 開発者であれば誰もが経験したことがあるでしょう。新しい機能やアプリケーションの素晴らしいアイデアを思いつき、お気に入りの AI コーディングアシスタントを立ち上げます。ところが…その後 1 時間を要件の洗い出しやエッジケースの明確化に費やし、コードを 1 行も書く前にコンテキストウィンドウが探索的な会話で埋め尽くされてしまいます。 Kiro という新しい IDE は、この問題を Spec-Driven Development（仕様駆動型開発） によって根本から変えます。 現在の AI コーディングアシスタントの限界 現在の AI コーディングアシスタントの限界は予測可能で非効率的なパターンに従う傾向があります。開発者が高レベルのプロンプトを与えると、AI は要件を完全に理解する前に即座にコード生成へ飛びついてしまいます。この時期尚早な行動は、「いや、実際にはこういう意味だった…」という明確化の繰り返しを招きます。初期の要件が十分に明確でなかったためです。こうした探索的対話が続くにつれ、コンテキストウィンドウは往復の議論でますます散らかり、最終的なコード生成に残るスペースは限られます。その結果、最終的なアウトプットの品質と完全性に影響が出てしまい、プロセス全体が本来よりも非効率になります。つまり、このアプローチは LLM をまずコードジェネレーターとして扱ってしまっており、本来は開発ライフサイクル全体を通して「思考のパートナー」として位置づけるべきなのです。 仕様駆動型開発: 設計意図と実装をつなぐ 難しい機能に取り組むとき、Kiro はあなたのインテリジェントな相談相手として、コードベースの理解、問題の明確化、効率的な品質解決を助けます。 Kiro と協力して、明確な要件、システムアーキテクチャ、技術スタックの考慮、実装アプローチを含む簡潔な仕様を作成できます。Kiro はすべての要件や制約を明示化し、それをコンテキストとして利用して、少ない反復回数で高精度にタスクを完了します。これこそが 仕様駆動型開発の力 です。 それでは、Kiro のアプローチがもたらす主な利点をさらに詳しく見ていきましょう。 1. 既存コードベースの理解 新開発に着手する前に、Kiro は既存コードを解析し、3 つの基礎ドキュメントである structure.md (コードベースのアーキテクチャ)、 tech.md (技術スタックとパターン)、 product.md (ビジネス文脈と要件) を生成します。これにより、チーム全員が今後の仕様策定を支える明確な基盤を共有できます。 2. プロジェクトの分析と計画 プロジェクトプロンプトを spec モードで与えると、Kiro はすぐにコーディングを始めるのではなく、要件を深く分析し、潜在的な課題を特定し、包括的な計画ドキュメントを作成します。 3. 包括的な計画ドキュメントの生成 シンプルなプロンプトから、Kiro は以下の詳細仕様ファイルを生成します。 要件分析 : プロンプトを具体的で実行可能な要件に分解 技術設計 : アーキテクチャ判断、技術選択、実装アプローチ タスク分解 : 明確な受け入れ基準を伴う粒度の細かい開発タスク 4. AI との効果的な協働 Kiro は仕様ファイルを Markdown 形式でプロジェクトディレクトリに保存します。コードが書かれる前にレビュー・編集・改善が可能になり、チームや関係者との自然なコラボレーションのチェックポイントを生み出します。 5. コーディング効率とコンテキストの最大化 実際にコーディング段階に入ると、Kiro は仕様ファイルを参照するため、探索的会話でコンテキストを圧迫することがありません。これにより、実際のコーディングタスクに最大限のコンテキストスペースを確保できます。 仕様駆動型開発の力 仕様駆動型開発は、ソフトウェアの設計・構築・維持の方法を根本から改善する重要な利点をもたらします。計画を「余計な負担」と見なすのではなく、競争優位性へと変えます。このアプローチは開発プロセスを次のように変革します。 高コストになる前に問題を発見 開発途中で要件の問題に気づくのではなく、Kiro が事前にあいまいさを特定して解消します。これによりコストのかかる手戻りを防ぎ、実装前にアラインメントが取れます。 プロジェクトの方向性を制御 仕様策定フェーズは自然な停止ポイントを作り、人間がレビュー・修正・承認できるため、リソースを投資する前に方向性を確認できます。 進捗を失わずに反復可能 要件定義でミスがあっても問題なし。仕様ファイルを修正し、実装計画を再生成できます。会話履歴をすべてやり直す必要はありません。 AI を重要な部分に集中させる 計画フェーズをファイルに外部化することで、AI のコンテキストは目の前のコーディングタスクに集中します。その結果、より高品質なコード生成が可能です。 シームレスなチームコラボレーション 仕様ファイルは生きたドキュメントとして、標準的な開発ワークフローの中でレビュー・コメント・貢献が可能です。 組織的ナレッジの構築 あらゆる決定や要件が文書化され、なぜ特定の技術選択が行われたのかという明確な監査証跡を残し、将来のチームメンバーにコンテキストを提供します。 Kiro スペックを実際に見てみよう 仕様駆動型開発を理解する最良の方法は、実際のワークフローを観察することです。新規プロジェクトでも既存コードベースでも、Kiro の体系的アプローチは堅実な基盤上で構築を可能にします。典型的なワークフローは、最初のコンセプトから実装準備の整った仕様書まで、次のように展開されます。 図1: Kiro は「仕様駆動開発」モードを使用して、要件、設計、タスクを含む詳細な出力を生成します ステップ 1: プロジェクトの開始 新機能に取り掛かる前に、まずプロジェクトのコンテキストを確立します。 ユーザー: 「このプロジェクトの steering をセットアップして」 Kiro は既存コードベースを分析し、次の 3 つの基礎ドキュメントを生成します: structure.md – 現在のアーキテクチャ、主要コンポーネント、コード構成 tech.md – 技術スタック、パターン、技術的制約 product.md – ビジネス文脈、既存機能、ユーザーワークフロー これにより、構築する対象の明確な基盤理解が得られます。 ステップ 2: プロジェクト仕様の生成 次に、構築したいプロジェクトの詳細を整理していきます。 ユーザー: 「小規模チーム向けのリアルタイム協働機能を持つタスク管理アプリを作りたい」 ここで仕様駆動型開発の真価が現れます。Kiro はフレームワーク選択や DB 設計に飛びつくのではなく、一歩下がって本当に達成したいことを理解します。既存アーキテクチャや制約を踏まえ、この新機能がどう収まるかを考えます。 Kiro は順を追って以下のドキュメントを作成します。 requirements.md – ユーザーストーリーや受け入れ基準を含む詳細な要件分解 design.md – フレームワーク、アーキテクチャ図、構造を含む技術設計 tasks.md – 実装フェーズと順序立てられたタスク一覧 図2：Kiro は3つの主要文書（要件、設計、タスクリスト）を作成します ステップ 3: レビューと改良 仕様をレビューし、例えば以下のような要件を追加できます。 ## Additional Requirements - Slack 通知との統合 - モバイル対応デザインを優先 - GDPR 準拠の考慮 ステップ 4: 情報に基づく開発 こうして Kiro がコーディングを始めるとき、参照するのは会話履歴ではなく、これらの包括的な仕様です。すべての実装判断は、文書化された要件と設計選択に基づいて行われます。 開発の未来は仕様から始まる 仕様駆動型開発は、受動的なコーディングから能動的な仕様策定への移行を意味します。これは単なるワークフロー改善ではなく、AI と協働してソフトウェアを構築する方法の根本的な進化です。AI を高度なオートコンプリートツールとして扱うのではなく、戦略的な思考のパートナーとして位置づけることで、変更コストが高くなる前により良い意思決定を行えるようになります。結果として、開発サイクルはより速くなり、コードの品質は向上し、予期せぬ事態は減少し、ドキュメントはプロセスに統合されているため後付けではなく常に最新の状態に保たれます。次に新しい機能を構築するときは、コードではなく仕様から始めてみてください。将来の自分（そしてチームメイト）はその明確さに感謝するでしょう。そして、最高のコードとは書く前に計画されたコードであると気づくかもしれません。 準備はできましたか？違いを体験してみましょう。 ウェイトリスト に参加してください。

本投稿は、 Sameer Malik とNitin Saxenaによる記事「 Getting started with Amazon EC2 bare metal instances for Amazon RDS for Oracle and Amazon RDS Custom for Oracle 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Oracle は、クラウドでのOracle Databaseのデプロイを簡単にセットアップ、運用、拡張できるフルマネージド型の商用データベースです。 Amazon RDS Custom for Oracle を使用すると、データベース管理者はOracle Database環境とオペレーティングシステムにアクセスしてカスタマイズすることができます。 この投稿では、Amazon RDS for OracleとRDS Custom for Oracleの Amazon EC2ベアメタルインスタンス でのAWSベアメタルインスタンスのサポートについて説明します。 Amazon EC2のベアメタルインスタンスは、アプリケーションが基盤となるサーバーのプロセッサとメモリに直接アクセスできるように設計されています。Amazon EC2のベアメタルインスタンスは、非共有テナンシーモデル専用の容量を提供し、共有仮想化インスタンスと比較してより高いレベルの分離を提供します。 これらのベアメタルインスタンスは、マイクロソフトやオラクルなどのベンダーのBring Your Own License（BYOL）ライセンスモデルの対象となるソフトウェアライセンスを使用するための追加のライセンス特典も提供する場合があります。Amazon EC2のベアメタルインスタンスを使用する場合のライセンス上の利点の詳細については、AWSのライセンスパートナーであるHouse of Brickの「 Oracle Hypervisor on AWS Bare Metal 」の投稿を参照してください。 さらに、Amazon RDS for Oracleと RDS Custom for Oracle の Amazon EC2 ベアメタルインスタンスは、同じサイズの仮想化インスタンスよりも 25% 低いコンピューティングコストで提供されるため、RDS ベアメタルインスタンス上の Oracle ワークロードの費用対効果が高くなります。 EC2 ベアメタルインスタンスの一般的なユースケース EC2 ベアメタルインスタンスの一般的なユースケースは次のとおりです。 ライセンス制限のあるワークロードのサポート – 特にOracle Database、SQL Server、SAP、Windows Serverなどの従来のエンタープライズソフトウェアでは、物理コアや専用ハードウェアの方がライセンスの方が有利な場合が多いため、これが主な推進要因となることがよくあります。 ハイパフォーマンスコンピューティング（HPC）と科学シミュレーション – これらのワークロードには、最高のパフォーマンス、特殊なハードウェア機能への直接アクセス、または非常に低遅延のノード間通信が必要です。 レガシーアプリケーション – これらのアプリケーションは仮想化環境ではサポートされていないか、特定のハードウェアアクセスが必要です。 分離とセキュリティ – ベアメタルインスタンスは、共有の仮想化インスタンスと比較して高い分離レベルを提供するため、非常に機密性の高いワークロードやコンプライアンス要件に役立ちます。また、特定の企業のコンプライアンスや規制要件を満たすために、仮想化されていない環境のシングルテナントインフラストラクチャで特定のアプリケーションを実行したい場合のオプションとしても役立ちます。 Amazon RDS for Oracle, RDS Custom for Oracleで ベアメタルインスタンスを使用するメリット RDS ベアメタルインスタンスには次の利点があります。 ライセンスのメリット – RDSベアメタルインスタンスは、非共有テナントモデルにおいて完全に専用化されたキャパシティを提供するため、ライセンスは、顧客が（オラクルとの契約に応じて）従来のコア・ベースのライセンスとオラクルのプロセッサーコアファクターを適用できるオンプレミスでのデプロイに似たものになる可能性があります。 低いコンピューティングコスト – Amazon RDS for OracleとRDS Custom for Oracle の RDS ベアメタルインスタンスは、同じサイズの仮想インスタンスと比較して 25% 低いコンピューティングコストで価格設定されています。たとえば、m6i.metalベアメタルインスタンスの価格（コンピューティングコスト）は、同等のサイズの仮想化インスタンスm6i.32xlよりも 25% 低くなります。 効果的なデータベース統合 – Amazon RDS for OracleとRDS Custom for Oracleのベアメタルインスタンスのライセンス上の利点とコンピューティングコストの削減により、スキーマ統合やOracleマルチテナントオプションなど、現在サポートされているデータベース統合方法を使用して、データベースワークロードを効果的に統合できます。 特定のワークロードのパフォーマンスの向上 – Oracle Databaseワークロードを仮想環境で実行し、物理サーバー全体の半分以上のコアを使用しているお客様は、追加のライセンスコストなしで、物理サーバー全体のパフォーマンス（CPU、メモリ、IOPS、スループットなど）を利用できるようになります。 Amazon RDSコンソールを使用して、RDS for Oracleベアメタルインスタンスを作成 このセクションでは、 AWSマネジメントコンソール を使用して、ベアメタルインスタンスタイプのRDS for Oracle DBインスタンスを作成する方法を示します。詳細と前提条件については、 Oracle DB インスタンスの作成 を参照してください。  Amazon RDS コンソールにサインインします。  Amazon RDS コンソールの右上隅で、DB インスタンスを作成したい AWS リージョンを選択します。  ナビゲーションペインで、「 データベース 」を選択します。  「 データベースの作成 」を選択します。  標準作成 を選択します。   エンジンのタイプ については、 Oracle を選択します。 データベース管理タイプ については、 Amazon RDS を選択します。 エディション には、 Oracle Enterprise Edition を選択します。  ライセンス については、デフォルトの Bring Your Own License（BYOL） のままにします。   エンジンのバージョン については、ご希望のバージョンを選択します。 テンプレート セクションで、 本番稼働用 を選択してください。 DB インスタンス識別子 には、DB インスタンスの名前を入力します。 認証情報の設定 セクションで、管理者ユーザーのユーザー名を入力し、 認証情報管理 で「 セルフマネージド 」を選択して、パスワードを入力します。   暗号化キー には、任意のキーを使用します。 インスタンス設定 セクションの DB インスタンスクラスで、ベアメタルインスタンス（たとえば、db.m6i.metal）を選択します。 インスタンスの残りの作成手順を完了して、「 データベースの作成 」を選択します。 DB インスタンスを作成したら、Amazon RDS コンソールでステータスを確認できます。 AWS CLIを使用してRDS for Oracleのベアメタル・インスタンスを作成 次のコードに示すように、 AWSコマンドラインインターフェイス （AWS CLI）を使用してベアメタルインスタンスを作成することもできます。AWS CLIに必要な認証情報とデフォルトのリージョンが設定されていることを確認してください。 aws rds create-db-instance \ --db-instance-identifier metaldb \ --db-instance-class db.m6i.metal \ --engine oracle-ee \ --allocated-storage 100 \ --master-username <username> \ --master-user-password <YourStrongPassword> \ --engine-version 19.0.0.0.ru-2025-04.spb-1.r1\ --license-model license-included \ --publicly-accessible false \ --storage-encrypted \ --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \ --db-subnet-group-name my-db-subnet-group クリーンアップ RDSインスタンスの実行コストを抑えるには、上記でプロビジョニングされたRDSインスタンスを削除してください。DB インスタンスは、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して削除できます。RDS インスタンスを削除する方法の詳細については、「 DB インスタンスを削除する 」を参照してください。 結論 Amazon RDS for OracleとRDS Custom for Oracle用のAmazon EC2ベアメタルインスタンスを使用すると、ライセンスの柔軟性が高まり、低コストのオプションが得られるため、Oracle DatabaseのワークロードをAmazon RDS for OracleおよびRDS Custom for Oracleで効果的に実行できます。このローンチの詳細については、「 What’s new 」を参照してください。 本投稿へのご意見はコメント欄にお願いします。 翻訳はソリューションアーキテクトの 矢木 覚 が担当しました。原文は こちら です。

このブログは 2025 年 9 月 2 日に Tom Tasker と Danny Johnston によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ランサムウェア攻撃は現代組織において取締役会レベルで優先課題となっています。データは次の明確な傾向を示しています: ランサムウェアのパンデミック発生以降、攻撃件数は 2 倍以上に増加し、特に金融サービス業界は標的となってきました。AWSでは、グローバルな金融サービスのお客様、規制当局、統制機関、業界パートナーとの分野横断的な連携により、 Cloud Hosted Data Vault (CHDV、略称ボールト) の認定アーキテクチャを確立しました。 大規模サイバー攻撃発生時の業務継続性強化において、ボールトは重要な検討事項です。ボールトは組織の最も重要な資産を隔離した最終防衛ラインとして機能し、従来の高可用性 (HA)、事業継続 (BC)、災害復旧 (DR)、バックアップによる復旧ができない場合においても、事業の再構築を可能にします。既存の運用レジリエンス対策にボールトを組み込むには、多角的で綿密な計画が必要です。本記事では、その計画上の考慮事項と、既存の HA、BC/DR、バックアップソリューションにさらに保護レイヤーを追加する方法を解説します。技術導入だけでなく、ボールトを機能させるための人的要素、プロセス、実践的要素に関する重要な検討事項にも焦点を当てます。 1. 何をボールトに組み込む必要があるか？ どんな事業部門の責任者も、全て、あらゆるものを組み込む必要がある、と言うでしょう。しかし、全てボールトに含める必要があるわけではなく、少なくとも即座には必要ないです。大規模なサイバーインシデントを考える際、全てのデータ、アプリケーション、サービスを重要かつボールトに保管必須とラベル付けしたくなる誘惑に駆られます。必要でなければ本番環境に存在しないはずだ、と考えるかもしれません。しかし、初期の精査なしに全てを保護しようとすると、膨大なデータ量、コスト、意図しない復旧遅延を招く可能性があります。 真のサイバーインシデント発生時には、事業再開に不可欠な中核的な IT 機能と運用サービスを、12 時間後、24 時間後、48 時間後に再開すべきか自問する必要があります。同様に重要なのは、不要なものは何かを見極めることです。これらは「最小限の事業継続機能 (Minimum Viable Business: MVB)」とも呼ばれ、お客様だけでなく二次、三次、四次関係者にも提供される中核的な機能とサービスです。 Figure 1: 何をボールトに組み込む必要があるか？ – 主要な IT 機能と運用サービスに焦点を当てる。 この問いは一夜にして答えが出るものではありません。ボールトは単なる技術的なソリューションではなく、多くの分野からの意見が関わります。MVB を特定し、それを最善の方法で保護するには、IT、セキュリティ、法務、事業部門責任者、アプリケーション責任者、経営幹部など、複数のチームからの意見、経験、知識が必要です。 2. 復旧とはどのような状態を指すのか？ サイバー攻撃は、標準的な運用復旧メカニズム (HA、BC、DR、バックアップ) を通じてシステムやサービスをオンラインに戻すことを困難、あるいは不可能にするよう設計されています。悪意のある攻撃者が身代金を確保するためには、復旧可能性を最小限にした上で最大限の混乱を引き起こすことです。大規模なサイバー攻撃に対しては、通常の運用復旧方法のみに依存することはできず、事前に検討すべき重要な考慮事項がいくつか存在します: 決定時間目標 (DTO) : ボールトから復旧するまでにどれだけの時間がかかるか、定義する目標です。セキュアで信頼できる環境における高度に自動化された復旧プロセスが侵害を受け、その結果、信頼性に不確実性が生じたり、破壊的な行為により完全に使用不能な事態が発生したとします。ボールトから完全または部分的にいつまでに復旧することが必要か、関係者と主要な意思決定ポイントを調整することが極めて重要です。 サイバー復旧時間目標 (C-RTO) とサイバー復旧時点目標 (C-RPO) : サイバーイベントの影響拡大と復旧時間を考慮して、復旧時間の期待値を調整します。従来数秒で済んだ復旧が数日かかる可能性があり、企業はサイバーインシデントに対応する方法を把握する必要があります。 最低限許容可能なサービス提供 (MASO) : MVB が事業活動に焦点を当てる一方、MASO は顧客や第三者に対して提供すべき許容可能なサービス水準を問うものです。これは主要サービスの機能制限版、あるいは代替手段でアクセスするバックアップシステムとなる可能性があります。 Figure 2: 復旧とはどのような状態を指すのか？ – 通常数秒で完了する処理が数日かかる場合があるため、事前に計画を立てる。 3. ボールトをどのように分割するか？ 単一のボールトに全てを統合するか、サービスごとにボールトを設けるかに関わらず、管理性、実用性、セキュリティのバランスを取ることが鍵となります。 簡素性 : ボールトは理解、操作、復元が可能な限り明確になるように保ちます。複雑さは遅延を生みます。 独立性 : 各ボールトは単独で機能し、待機時間を最小化し並列処理を促進します。 サービスマッピング : 復元の開始点はどこか、最適な復元順序は何か把握します。 役割と責任 : 責任者と管理者はサービス、アプリケーション、インフラストラクチャごとに割り当てられます。 保守 : アプリケーションの更新やビジネスユースケースの変化に伴い、ボールトも変化します。 Figure 3: ボールトをどのように分割するか？ – 管理性、内容、復旧プロセスのバランスをとる。 AWS が提供する柔軟性は、技術的負債を残すことなく、テスト、失敗、改善を繰り返しながら最適解を見つけることを可能にする点で非常に価値があります。ホワイトボード上でうまく機能したものが、最初の机上演習で失敗することもあり、そこから得た教訓は次のボールトでの試行に反映できます。ビジネスに適応する柔軟性を持つことで、ソリューションと復旧プロセスへの信頼性が向上します。ボールトに格納されるものは単なる「データ」の問題ではないです。—アプリケーションの責任者や事業部門からの意見が必要です。 4. ボールトをどのように管理するか？ ボールトは運用環境から切り離す必要があります。これにより、本番環境を横方向に移動するサイバー攻撃はぼーるとの入口で遮断されます。このレベルの分離がなければ、サイバー攻撃時にボールトも侵害される可能性があります。従来のエアギャップ方式では、メディアの抜去や物理的分離により、保護機構と運用環境の間に文字通りの空気の隙間 (エアギャップ) を設けていました。この隔離をクラウド環境とボールトにどう適用すべきでしょうか？クラウド上で同様のセキュリティ対策を実現するには以下の要件が必要です: イングレスゾーン : アクセス可能な時間帯にのみ利用可能な一時的な領域、サービス、機能。 多要素認証 : 許可された担当者だけがアクセス可能な物理トークン。 ゼロトラスト : あらゆる段階での認証。 AWS Identity and Access Management (IAM) : 制限された役割と責任。 変更管理 : トークンとアカウントへの承認済みアクセスを処理するプロセス。 Figure 4: ボールトをどのように管理するか？ – 可視性を維持しつつ意図的に隔離する。 5. 物流とサービスプロバイダーについてはどのように計画するか？ サイバーインシデントへの対応策を検討する際、物理的な解決策は見過ごされがちです。中核となるサービス、アプリケーション、基盤インフラに焦点を当てることで、それらを復旧させる方法を考える際に周辺的な物理的依存関係が焦点から外れてしまいます。例えば: 内部および外部ネットワークへのアクセス : 災害が発生しなくてもサービス中断を引き起こす接続障害だけで十分ニュースになります。 ソフトウェアリポジトリ : 自動化されたソフトウェアデプロイとは、デジタル依存関係なしに取得できる、引き出しに置かれた USB スティックなどの物理メディアを意味します。 サプライチェーン : 物理機器が機能不全に陥った場合、必要な場所に大量のハードウェアを調達する計画とプロセスはありますか？ 物理的な物流: : 大規模なイベントに対して大規模な対応が必要な場合、人員、設備、作業スペースをどう確保しますか？ Figure 5: 物流とサービスプロバイダー – 計画を外部依存関係まで拡大する。 サイバー攻撃の高度な手法では、個々の障害が通常の業務運営において想定され、かつ、影響も最小限であるような障害を複数強制的に発生させます。これらの障害が大規模に発生すると、複合的な影響をもたらし、複雑性と復旧の遅れを増大させる可能性があります。 6. ボールトに関するプロセスは誰が責任を持つのか？ 責任者は、ボールトに関するプロセスと管理を持ち、ベストプラクティスを提供し、復旧が必要な際には最前線に立つことになります。どのチームがボールトを責任を持つか決定することは極めて重要で、必ずしも単純な作業ではありません。ボールトの基本原則は、保護・計画・プロセスという多面的な要素をカバーするという事実に基づいており、これらには単一チームではなく、複数の部門からの意見が必要となります。 復旧の優先順位付けは、依存関係、コンプライアンス要件、ビジネスへの影響に関する理解に基づき、バックアップチームではなくビジネスステークホルダーが主導すべきです。効果的なサイバー復旧計画には、技術チームとビジネスチーム間の明確なコミュニケーションが不可欠です。 Figure 6: 人とプロセス – この2つの要素のバランスを取ることが優れた実践を推進する。 この部門横断的な協力の結果として、企業が採用し遵守しなければならない復旧計画が策定されます。しかし、バッドプラクティスにつながる可能性のある硬直的なアプローチにより、サイバーイベント復旧シナリオの質が意図せず低下する可能性があります。過度に負担の大きいプロセス、俊敏性の欠如、そして最も当たり障りのない方法を選ぶという傾向により、最良の計画が実装されない可能性があります。これはセキュリティと復旧手順には即座に影響しません。しかしながら、ボールトの原則が適用されていないことに気付く最悪のタイミングは、それらが必要な時です。サイバーイベントからの効果的な復旧を確実にするためには、組織は日常業務にベストプラクティスをシームレスに統合する必要があります。この統合には、堅牢な復旧要件と、チームがセキュリティや効率性を損なうことなく一貫して従うことができる実用的で持続可能なプロセスとの間の絶妙なバランスを取ることが必要です。 7. なぜスポンサーが必要なのか？ 組織に追加業務を導入することで、コストと苦労は確実に増大し、他の事業開発から時間とリソースを奪うことになります。時間、資金、人的リソースを消費する技術ソリューションが収益をなぜ生み出さないのか、と最高財務責任者 (CFO) なら疑問に思います。企業は、ボールトと積極的に中核業務に組み込もうとしないでしょう。したがって、その本質的価値と活用事例を理解することが極めて重要です。経営陣レベルのリーダーシップによる「トップダウン」アプローチによってのみ達成可能です。 Figure 7: スポンサーシップ – トップダウンアプローチにより、事業全体を導く。 AWS で始めましょう AWS はランサムウェア攻撃に対する多重防御層を提供します。複数の AWS データサービスにわたる即時データ保護のため、 AWS Backup は不正な改ざんの防止だけでなく迅速な復旧オプションも可能な イミュータブルバックアップ と論理的なエアギャップを備えた集中管理型バックアップ管理を提供します。 バージョニングとObject Lock を備えた Amazon S3 、および Amazon FSx for NetApp ONTAP は、重要データのための改ざん防止ストレージ機能を提供します。 検知においては、 Amazon GuardDuty が不審な活動を監視し、 AWS Security Hub が包括的なセキュリティ状況を可視化します。 Amazon Macie は標的となる可能性のある機密データを特定し、 AWS Shield と AWS WAF は初期の攻撃になりうる DDoS 攻撃や Web エクスプロイトから保護します。 AWS Network Firewall はネットワークレベルで悪意のあるトラフィックをフィルタリングします。 elastio などのパートナーは AWS Backup と連携し、組織がほぼリアルタイムでデータの整合性を検証できるようにします。これにより、ダウンタイムとデータ損失を最小限に抑えながら、あらゆる事象から完全な復旧を実現します。 アイデンティティ保護のため、 AWS IAM で最小権限アクセスを実装し、 AWS Organizations でアカウント横断的なセキュリティポリシー管理を実現します。 AWS Config と AWS CloudTrail は構成変更と API アクティビティの可視性を提供するため、インシデント後のフォレンジック分析に不可欠です。 まとめ サイバー攻撃、特にランサムウェア攻撃は年々増加しています。偶発的なインシデントから標的型攻撃に対する防御への移行は、企業と経営陣が迅速に対応転換する必要があることを意味しています。これは、深刻ではあるものの現実的に起こりうる事象が、サービスを麻痺させるだけでなく、事業を永久に閉鎖させるリスク範囲を小さくするためです。増加するサイバー攻撃への技術的ソリューションは対策の一環ではありますが、全てではありません。標的型攻撃への対応策を計画することは、日常業務で慣れ親しんだ固定観念を取り除く一環でもあります。サイバーイベントは日常業務ではないため、重要な決定をその場しのぎで行うことがないように、適切な準備と計画が必要です。効果的なサイバーレジリエンスには、組織全体にわたる包括的なアプローチが不可欠です。まず自社の業務運営において「復旧成功」の定義を明確にし、詳細な計画を通じて最悪のシナリオを想定した準備を進めます。これらの計画は定期的に見直し、復旧プロセスや手順が実際に機能することを確認するため、徹底的なテストと検証を実施してください。最も重要なのは、サイバーレジリエンスが IT 部門の枠をはるかに超える課題である点です。これは本質的に全社的な取り組みを必要とするビジネス上の課題です。運用部門や財務部門から経営陣、現場スタッフに至るまで、あらゆるチームがレジリエンス構築とインシデント発生時の復旧において重要な役割を担います。成功は「CEO からシステム管理者まで」組織全体でサイバーレジリエンスを共有責任とすることにかかっています。 <!-- '"` --> Tom Tasker Tom は Amazon Web Services のグローバル金融サービス部門に所属するストレージソリューションアーキテクトです。彼は世界最大かつ最も影響力のある金融サービス企業、規制当局、パートナーと連携し、AWS ストレージプラットフォームと統合し、同プラットフォーム上で稼働するソリューションの推進に取り組んでいます。 Danny Johnston Danny は Amazon Web Services において、グローバル金融サービス向けストレージ事業開発チームを率いています。エンタープライズ向けストレージソリューションを専門とする経験豊富な事業開発プロフェッショナルであり、顧客や規制当局との戦略的パートナーシップ構築を推進しています。金融サービス組織がデータインフラを最適化し、デジタルトランスフォーメーションの取り組みを加速させる支援に情熱を注いでいます。

2025 年 9 月 3 日に東郷記念館東京で開催された「AWS for Software &amp; Technology | Builders Forum Tokyo – AI Agent 時代の SaaS」のイベントについてレポートします。本イベントの全セッション資料は こちら です。 本イベントは現地参加・オンライン参加合わせて 300 名以上の方にご参加いただきました。参加者からは「AI エージェント時代の SaaS について具体的な実装例が聞けて非常に参考になりました」「セキュリティや可観測性の観点からの実践的なアドバイスが有用でした」などの感想をいただきました。これから AI エージェント技術を導入してみたい方、すでに利用しているがさらに活用したい方、それぞれの皆様にご参考いただける情報をご紹介させていただきました。 このイベントは、AI エージェント時代の SaaS をテーマに、 SaaS 提供者が今すぐに AI エージェントを AWS とともに取り組み始めるべき理由、既に AWS で AI エージェントに取り組まれているお客様事例、そして SaaS サービスへの AI エージェント導入のために必要な、テナントを考慮した全体像、オブザーバビリティ、セキュリティ、が紹介されました。 キーノートセッション キーノートセッションでは、AWSジャパン 常務執行役員 デジタルサービス事業統括本部長 佐藤有紀子による開会の挨拶から始まり、AWSジャパン デジタルサービス技術本部 本部長 塚田朗弘と、一般社団法人日本 CPO 協会 – 代表理事 / 株式会社 LayerX – Product Strategy のワカマツ様からはグローバルな AI エージェント導入トレンドと、企業が今すぐ取り組むべき理由について 「いつ始めるべきか？今日ではなく、昨日です！」 というメッセージと共にお話しいただきました。塚田からは AWS の日本の未来への投資内容、AWS AI スタック全体を通じた本番グレードの AI エージェント基盤としての AWS のケイパビリティ、SaaS 領域での支援実績と 我々が既にお客様と一緒に Agentic AI の世界を作っていく準備ができている ことを力強く説明しました。 いつ始めるべきか？今日ではなく、昨日です！ お客様事例: フリー宇佐美ゆう様「SaaS × AI Agent 未来 – freee が AWS で築く AI Agent 基盤」 フリー株式会社様からは、AWS 上での AI エージェント基盤の導入事例について技術選択の意思決定、セキュリティ視点で詳細にご紹介いただきました。 実装例としてご紹介いただいた「まほう経費精算」では、チャットベース UI での正確な申請により経費申請者の負担を極小化させることを目的としており、デモを踏まえてご紹介いただきました。システムの安定稼働、コスト効率、品質向上等の整備が急務であり、そのために LLM Observability による評価基盤の重要性についてご説明いただきました。 会計業務の自動化を目的として AI エージェントを導入し、ユーザーの業務効率を大幅に向上させることに成功されています。特に、マルチテナント環境でのデータ分離とセキュリティ確保、リアルタイムでの処理性能最適化、ユーザー体験の向上などの技術的な課題をどのように解決されたかについて具体的な実装例と共にお話しいただきました。AI エージェント基盤の選定理由や全体の構成について非常に参考になるため是非資料をご覧ください。 お客様事例: kubell 藤井 謙太郎様「BPaaS におけるヒトと協働する前提の AI エージェント開発」 株式会社 kubell 様からは、短期と長期で目指されている BPaaS と AI エージェントについてご紹介いただきました。AI エージェントによる業務実行は、処理結果の再現性がない、サービスレベルをわかりやすく設定困難などの課題があり、ヒトによる業務代行は属人性やスケーリングの障壁などの課題があります。両者の良いところを受け入れつつ協調型からの発展をスケーリングできる仕組みと領域を選定する、ということを短期で目指されています。現在、経費精算エージェントで、人間のアシスタント、自律 AI エージェント、ワークフロー型 AI エージェントが協調する構成を検証されており、ドメイン知識と企業別のコンテキストをマルチテナントでどのように取り扱うのかがポイントであるとご説明いただきました。現実的な AI エージェントの導入のロードマップが非常に参考になるためぜひ資料をご確認ください。 お客様事例: エムオーテックス 小沼 祐貴様「開発チーム全員で AI の世界に飛び込む！〜全員参加で進めた Amazon Q Developer 導入物語〜」 エムオーテックス株式会社様からは、チーム生産性を向上させる取り組みについてご紹介いただきました。 組織として、チーム生産性の効果測定指標の検討、PoC、勉強会＆ハンズオン、利用推進活動、報告会、等を設計され、組織に全員参加で AI コーディングエージェントを導入するための全体像を作成されました。アンケート結果から業務効率化の改善は PoC 期間の活用だけでも、600時間/月 だったとのことです。 多くの企業様では一部の社員のみで AI が活用され、全社的に広まっていかない、効果がわからないので投資判断できない、といった声を聞くことがありますが、エムオーテックス様では全員参加で利用推進の施策を取って取り組まれており、非常に参考になる社内導入の進め方ですので資料をご覧ください。 AWS テクニカルセッション: 「SaaS アーキテクチャの設計思想 AI – Agent との共創」 AWS ソリューションアーキテクトの福本より、AI エージェントと SaaS の協調アーキテクチャについて、マルチテナント環境で AI エージェントを実装・運用する際の考慮点について紹介しました。クォータ管理、テナント別プロンプト管理の効率化、監視、セキュリティ、そしてリソース使用量の最適化など、広く課題とその解決アプローチについて整理しました。 AWS テクニカルセッション: 「SaaS 開発者のための AI Agent Observability」 AWS ソリューションアーキテクトの桂井より、AI Agent の振る舞いを適切に監視・分析するためのアプローチについて紹介しました。AI Agent を活用した SaaS アプリケーションにおいて、可観測性（Observability）の確保はマルチテナントごとの精度向上、セキュリティの両面で重要な要素であり、福本の SaaS x AI エージェントセッション、後続の加治のセキュリティセッション両方に取って重要です。フリー様からも Langfuse の活用の重要性について説明いただいていることから実用上非常に重要であることが理解できます。本セッションでは AWS が AI エージェントの Observability のためにどのような仕組みを提供しているのかをわかりやすく解説しました。 AWS テクニカルセッション: 「SaaS 開発者のための AI Agent Security」 AWS ソリューションアーキテクトの加治より、AI エージェントを安全に運用するための包括的なセキュリティプラクティスについて説明しました。AI エージェントにおいても引き続き多層的なセキュリティ対策が重要であり、一般的な Web セキュリティ、SaaS セキュリティ、AI セキュリティについて包括的に考慮するための考慮ポイントを整理しました。Amazon Bedrock AgentCore Runtime、Amazon Bedrock AgentCore Identity などにも触れて本番環境のセキュリティについて概要をお伝えしました。 ワークショップ L200: マルチテナント SaaS &amp; AI エージェント 入門ワークショップ AWS ソリューションアーキテクトの後藤から初学者向けの AI エージェントのワークショップを開催しました。ハンズオン形式で資料に沿って最も初歩的なチャットエージェントから徐々に Amazon Bedrock Knowledge Bases を用いた RAG の追加、マルチテナントプロンプト管理、などの少し発展的な内容までを取り扱いました。 L400:&nbsp; Model Context Protocol Security on AWS AWS ソリューションアーキテクトの赤澤から Model Context Protocol の概要、包括的なセキュリティの考慮ポイントと対策案、について座学を実施し、そのあとはモクモク形式で参加者のペースに合わせてハンズオンを実施いただきました。MCP 含む AI エージェントのセキュリティは既に実用化のフェーズに至っているお客様にとっては喫緊の課題です。それらに対して包括的な視点から今回は MCP に特化して情報を提供しました。 ネットワーキング ご紹介したセッション・ワークショップ以外にも、現地参加ならではの体験として、ブース展示やネットワーキングパーティを実施しました。ブースにご出展をいただきましたkubell 様、セーフィー様、フリー様、また、ネットワーキングパーティ中に開催したライトニングトークにご登壇をいただきましたエクサウィザーズ様、ゼンリンデータコム様、ユーザベース様、弁護士ドットコム様、Techouse 様、ご協力をいただきありがとうございました。 おわりに 今回のイベントでは、AI エージェント時代における SaaS をテーマにグローバル動向、AWS からのキーメッセージ、お客様の事例、ソリューションアーキテクトからの技術セッションを紹介させていただきました。AI エージェントは急速に進歩しており、SaaS 業界においても新たな価値創出の機会が広がっています。AWS では、日本への継続的な投資、各種プログラム提供、Amazon Bedrock をはじめとする AI サービスを通じて、皆様の AI エージェント導入を継続的に支援してまいります。