本記事は 2025年9月4日に公開された Amazon CloudFront now supports IPv6 origins for end-to-end IPv6 を翻訳したものです。 組織が IPv4 アドレス空間の制限を超えるにつれて、IPv6 の採用は世界中で加速し続けています。Amazon Web Services (AWS) では、長い間、エンドユーザーから Amazon CloudFront ネットワークまでについては IPv6 をサポートしてきました。これにより、エンドユーザーがレイテンシーを削減し、パフォーマンスを向上させ、最新のモバイルネットワークにアクセスできるよう支援してきました。今、私たちはそれをさらに一歩進めることができることを嬉しく思います。本日より、CloudFront はエッジからオリジンまで IPv6 接続をサポートするようになり、真のエンドツーエンドの IPv6 配信パスを実現できるようになりました。これにより、エンドユーザーは CloudFront をウェブアプリケーションの IPv6 と IPv4 のデュアルスタックインターネットゲートウェイとして使用し、コンテンツアクセラレーションを実現できます。 なぜこれが重要か？ IPv6 は、最近のほとんどのモバイルネットワークの基盤となるトランスポートプロトコルであり、ブロードバンドトラフィックに占める割合は増加の一途をたどっています。IPv6 をオリジンまで有効化することで、配信チェーン全体でプロトコルの一貫性を維持し、デュアルスタックの複雑さによる運用上のオーバーヘッドを軽減し、より確定的で、オブザーバビリティに優れた、パフォーマンスの高いトラフィックフローを実現できます。CloudFront のエンドユーザーにとって、これらの利点は、ページロードの高速化、ストリーミングの安定化、IPv4 リソースの代替として引き続き機能する配信アーキテクチャにつながります。 CloudFront アプリケーションにおける IPv6 のメリット CloudFront は IPv6 経由のオリジンをサポートするようになったため、エンドユーザーからオリジンサーバーに至るまで、エンドツーエンドの IPv6 接続を実現できます。これにより、従来の IPv4 ベースの配信に比べて、技術面および運用面でさまざまなメリットが得られます。 1. NAT のオーバーヘッドを排除し、パフォーマンスを向上させます IPv4 ネットワークは、ネットワークアドレス変換 (Network Address Translation: NAT)、特に ISP や携帯電話事業者が使用するキャリアグレードの NAT に大きく依存しています。これらの NAT 層は、接続設定の遅延を招き、ポートの可用性を制限し、パケットドロップの原因となる可能性があります。IPv6 では NAT が不要になり、エンドユーザー、CloudFront、オリジン間の直接のエンドツーエンド接続が可能になります。その結果、特に IPv6 の採用が最も多いモバイルファーストの市場では、レイテンシーが減り、ページの読み込みが速くなり、ユーザーエクスペリエンスが向上します。 2. より効率的なパケット処理 IPv6 では、オプションの制御情報として、簡略化された固定長のヘッダーと拡張ヘッダーが導入されています。これにより、ルーター、ファイアウォール、ロードバランサー、CloudFront ノードのパケット解析と転送がより効率的になります。IPv6 は、特にディープパケットインスペクションやトラフィックシェーピングを実行するシステムにおいて、パケットごとの処理オーバーヘッドを削減し、パケット転送や検査中のあいまいさを解消します。ルーターによる経路内でのフラグメンテーションが可能な IPv4 とは異なり、IPv6 はフラグメンテーションの責任をすべてソースホストに委任します。このアーキテクチャ上の制約により、再送信回数が減り、転送パス全体で最適なセグメントサイズが維持されるため、転送パフォーマンスが向上します。その結果、IPv6 では、特に CloudFront とオリジンの間の長距離または高レイテンシーのリンクで、より安定してパフォーマンスの TCP 接続が可能になります。これは、再送信を減らし、トランスポートパス全体で最適なセグメントサイズを維持することによって実現されます。 3. 予測可能な伝送と輻輳制御 IPv6 ではエンドツーエンドのパス MTU 検出 (PMTUD) が実行され、フラグメンテーションの責任はすべてソースホストに委任されます。このアーキテクチャ上の制約により、伝送の予測性が向上し、MTU の不一致によるパケットのドロップやフラグメント化のリスクが最小限に抑えられます。IPv6 は 特に CloudFront と AWS 以外のオリジン間の長距離または高レイテンシーのパスでは、TCP の安定性とスループットを向上させます。これは、再送信を最小限に抑え、エンドツーエンドで最適なセグメントサイズを維持することによって実現されます。AWS オリジンについても、現在、ジャンボフレームサポートなどの AWS バックボーンネットワークを通じて同様の成果が得られています。AWS エッジロケーションと AWS リージョンのアプリケーションエンドポイントの間でジャンボフレームを有効にすると、CloudFront は各パケットでより大きなペイロードを送受信できるようになります。ジャンボフレームのサポートにより、エンドユーザーとアプリケーション間のデータ転送に必要な合計時間が短縮されます。 4. 接続スケーラビリティの向上 IPv4 では、NAT によってオリジン IP アドレスごとに使用できるソースポートの数が減るため、CloudFront ノードがオリジンと同時に確立できる接続の数が制限されます。この制約は、何千もの同時リクエストを効率的に処理しなければならないトラフィックの多い環境では問題になる可能性があります。この機能は、HTTP/2 などのプロトコルを使用する場合に特に役立ちます。このようなプロトコルでは、1 つの接続で複数のストリームを多重化し、接続を再利用することが、パフォーマンスを最大化し、レイテンシーを最小限に抑えるために不可欠です。 開始方法 この度、CloudFront ディストリビューションに関連付けるオリジンとして IPv6 を使用するように設定できるようになりました。この新機能では、IPv4 (デフォルト)、IPv6 、またはデュアルスタック ( IPv4 と IPv6 ) のいずれかを選択できます。既存のオリジンについては、CloudFront は引き続き IPv4 を使用します。デュアルスタックを使用する場合、CloudFront は IPv4 と IPv6 の IP アドレスを自動的に選択して、トラフィックが両方のオリジンで均等に分散されるようにします。 CloudFront コンソールまたは CloudFront API を使用して CloudFront ディストリビューションを作成または更新し、オリジンへの IPv6 接続を設定できます。この投稿では、IPv6 をサポートするオリジンの作成方法を説明し、既存のオリジンで IPv6 を安全に有効化するためのベストプラクティスを探ります。始める前に、オリジンが IPv6 またはデュアルスタック接続をサポートしていることを確認してください。オリジンは、カスタムオリジンでも、 Elastic Load Balancers 、 Amazon API Gateway 、 AWS Lambda の関数 URL などの IPv6 をサポートする AWS サービスでもかまいません。 IPv6 オリジンを使用した新規 CloudFront ディストリビューションの作成 CloudFront コンソールで、CloudFront ディストリビューションの作成を選択します。 Step 1: Get started ディストリビューション名を入力し、その他のオプションパラメータを入力してから、 [Next] を選択してステップ 2 に進みます。 Step 2: Specify origin オリジンのタイプを選択し、オリジン情報を入力します。IPv6 を設定するには、 Setting パネルで [customize origin settings] を選択します。 オリジン IP アドレスタイプ設定に IPv6 または Dualstack を選択し、 [Next] を選択します。 Step 3: Enable security AWS WAF を有効にしてアプリケーションを保護し、 [Next] を選択します。 Step 4: Review and create 設定内容を確認したのち、 [Create distribution] ボタンを選択し、ディストリビューションを作成します。 既存の CloudFront ディストリビューションに新規の IPv6 オリジンを追加する 既存の CloudFront ディストリビューションに新しい IPv6 オリジンを追加するには、ディストリビューションを選択してディストリビューション設定を開き、 [Origins] タブを選択して [Create Origin] を選択します。 [Additional settings] を展開し、Origin IP address type で [IPv6] または [Dualstack] オプションを選択して、オリジンへの IPv6 接続を有効にします。オリジンを作成したら、新しいオリジンを指すようにビヘイビアを追加または更新します。 既存のオリジンで IPv6 を有効化する CloudFront 継続的デプロイ を使用すると、変更をオリジン設定に安全に移行できます。CloudFront 継続的デプロイでは、デプロイポリシーを使用してリクエストをステージングディストリビューションにルーティングし、変更を検証してプロモートすることで、変更を安全にテストできます。このアプローチの詳細については、CloudFront の ドキュメント を参照してください。 オリジンへの IPv6 接続の検証 メトリクスまたはアプリケーションログを使用して、オリジンでの IPv6 トラフィックを検証します。このケースでは、オリジンとして Application Load Balancer (ALB) を使用し、IPv6 Requests メトリクスを使って検証しました。 まとめ モバイルネットワークやグローバルネットワークで IPv6 の採用が拡大するにつれて、エンドユーザーから Amazon CloudFront、そしてオリジンに至るまで、エンドツーエンドの IPv6 を有効にすることで、IPv4 では対応できないパフォーマンスとアーキテクチャ上の利点が得られます。NAT のオーバーヘッドがなくなり、ルーティングとフローの可視性が向上し、固定ヘッダーと信頼性の高い パス MTU 検出によってパケット処理が合理化されます。CloudFront は IPv4 と IPv6 の両方に最適化されていますが、IPv6 の利点は配信のファーストマイル、 ラストマイルで最も顕著になります。IPv6 をエンドツーエンドで採用することで、スケーラブルで高性能で、将来を見据えたコンテンツ配信の基盤が築かれます。 Amazon CloudFront で IPv6 をエンドツーエンドで有効にすることはもはやオプションではありません。これは、レイテンシーの低減、耐障害性の向上、将来を見据えたスケーラビリティを実現するための基本的なステップです。まだ CloudFront ディストリビューションの IPv6 サポート を有効にしていない場合は、今すぐ IPv6 サポートを有効にしてください。 翻訳は Solutions Architect の山本 大貴が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 つい先週、趣味のパデルで、右手を骨折してしまいました。スポーツや仕事がしにくく、こういう時は大人しく過ごそうということで、最近出版された「 AWS 生成 AI アプリ構築実践ガイド 」を購入して読み始めました。Amazon Bedrock Agents／Amazon Bedrock AgentCore についても記載され、内容も充実しており、参考になる一冊です。読書の秋にじっくり AWS を学んでみるのはいかがでしょうか。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年9月15日週の主要なアップデート 9/15(月) AWS Organizations がメンバーアカウントのアカウント状態情報を提供開始 AWS Organizations で新しい State フィールドが追加され、メンバーアカウントの状態をより詳細に把握できるようになりました。従来の Status フィールドでは分からなかった「AWS による強制停止 (SUSPENDED)」「クローズ処理中 (PENDING_CLOSURE)」「クローズ済み (CLOSED)」などの細かい状態が確認可能です。複数のアカウントを管理する組織では、各アカウントの正確な状況を把握することで適切な対応が取れるようになります。詳細は こちらの Blog 記事をご参照ください。 Amazon Bedrock でカスタム Meta Llama モデルのオンデマンドデプロイメントを発表 Amazon Bedrock で、カスタマイズした Meta Llama 3.3 モデルのオンデマンドデプロイメントが可能になりました。従来は常時稼働するサーバーが必要でしたが、今回のアップデートにより使用時のみリソースを起動し、利用分だけの支払いでコストを大幅削減できます。AI チャットボットや文書生成システムなど、利用頻度が不定期なアプリケーションに最適です。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker HyperPod が Slurm クラスターのヘルスモニタリングエージェントサポートを発表 Amazon SageMaker HyperPod の Slurm クラスターでヘルスモニタリングエージェント機能が利用可能になりました。この機能は GPU や Trainium ノードの状態を常時監視し、ハードウェア障害を検出すると自動的にノードを交換します。従来は訓練中に障害が発生すると手動対応が必要でしたが、今回のアップデートにより自動レジューム機能と連携してチェックポイントから訓練を継続できるようになりました。大規模言語モデルなど数週間かかる訓練でも中断リスクを大幅に軽減し、コストと時間のロスを削減できます。詳細は こちらのドキュメントをご参照ください。 9/16(火) Amazon OpenSearch Service が Star-Tree Index を発表 Amazon OpenSearch Service で Star-Tree Index という新機能が利用開始となりました。この機能により、大量データの集計処理が大幅に高速化され、従来時間がかかっていた複雑な分析クエリもサブ秒で応答できるようになります。データを事前に集計して保存するため、リアルタイムダッシュボードや監視システム、パーソナライゼーション機能などで威力を発揮します。詳細は こちらのドキュメントをご参照ください。 Amazon S3 が汎用バケットで条件付き削除をサポート開始 Amazon S3 の汎用バケットで条件付き削除機能が追加されました。HTTP if-match ヘッダーと ETag を使用し、オブジェクトが変更されていない場合のみ削除を実行できます。複数のユーザーが同時にファイルを操作する環境で、誤ってファイルを削除してしまうリスクを大幅に軽減できます。従来は削除前にオブジェクトの状態を確認する仕組みがなく、競合状態での誤削除が課題でした。全リージョンで追加コストなしで利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon Lex が 8 つの新しい言語で生成 AI ベースの強化された自然言語理解を提供 Amazon Lex が大規模言語モデル (LLM) を活用した自然言語理解機能を日本語を含む 8 つの新言語で提供開始しました。これまでチャットボットが理解しにくかった複雑な発話や、スペルミスがある入力でも正確に処理できるようになります。例えば「妻と子供 2 人と私でフライト予約したい」と話すと、4 人分の予約として正しく理解してくれます。東京リージョンなど 10 の商用リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 9/17(水) AWS Network Firewall がコンソール、モニタリング、セキュリティ機能を強化 AWS Network Firewall で監視機能とセキュリティ機能が強化されました。監視ダッシュボードでは Amazon S3 や DynamoDB などの AWS サービスへのトラフィック状況を詳細に可視化でき、IP アドレス別やプロトコル別の分析も可能になります。また新しい TLS Inspection のセッションホールディング機能により、悪意のある接続先への通信をより確実にブロックできるようになりました。詳細は こちらのドキュメントをご参照ください。 AWS Budgets でカスタム期間がサポートされるようになりました AWS Budgets でカスタム期間の予算設定が可能になりました。従来の月次や四半期などの固定期間ではなく、任意の開始日と終了日を指定できます。月の途中から始まる 3 ヶ月プロジェクトなども一つの予算で管理でき、複数月に分けて計算する手間が不要になりました。詳細は こちらのドキュメントをご参照ください。 9/18(木) Qwen3 モデルが Amazon Bedrock で完全マネージド型として利用可能になりました Amazon Bedrock に Qwen3 モデル 4 種類が追加されました。コーディング特化の Coder モデルや汎用推論用モデルなど、用途に応じて選択できます。インフラ管理が不要なフルマネージドサービスとして提供されるため、AI アプリケーション開発に集中できます。東京リージョンを含む複数リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 OpenAI オープンウェイトモデルが AWS Bedrock で新しいリージョンに拡張 AWS Bedrock で OpenAI のオープンウェイトモデルが 8 つの新リージョンに拡大しました。東京、ロンドン、ムンバイなど世界各地で利用可能となり、これまでオレゴンリージョンのみだった制限が解消されます。ユーザーに近いリージョンでの実行により、レイテンシが大幅に改善され、AI アプリケーションの応答速度が向上します。また、データ所在地の要件に対応でき、コンプライアンスを重視する企業でも安心して活用できます。詳細は こちらの Blog 記事をご参照ください。 DeepSeek-V3.1 モデルが Amazon Bedrock でフルマネージドサービスとして利用可能に Amazon Bedrock で DeepSeek-V3.1 モデルが利用可能になりました。このモデルは詳細分析用の thinking モードと高速応答用の non-thinking モードを切り替えできるのが特徴です。従来モデルと比較してハルシネーション (誤った情報生成) が減少し、精度が向上しています。ソフトウェア開発や数学的推論、データ分析などの業務で活用でき、 AI エージェント構築やプロセス自動化にも最適です。オレゴン、東京、ムンバイ、ロンドン、ストックホルムリージョンで提供開始されています。詳細は こちらの Blog 記事をご参照ください。 Stability AI Image Services が Amazon Bedrock で利用可能に Amazon Bedrock で Stability AI Image Services が利用開始となりました。背景除去やオブジェクト消去など 9 つの画像編集ツールが使えるようになり、API 経由で高度な画像加工が可能です。従来は専用ソフトが必要だった画像編集作業を、クラウドサービスで簡単に自動化できるため、EC サイトの商品画像作成やマーケティング素材の制作が効率化されます。オレゴン、バージニア北部、オハイオリージョンで提供中です。 Amazon Q Developer CLI がリモート MCP サーバーのサポートを発表 Amazon Q Developer CLI がリモート MCP サーバーのサポートを開始しました。従来はローカルでの MCP サーバー利用が中心でしたが、今回のアップデートによりリモートサーバーを活用できるようになり、計算リソースの削減とセキュリティ管理が向上します。Atlassian や GitHub などの外部サービスとの統合も可能で、OAuth 認証による安全な接続を実現します。詳細は こちらのドキュメントをご参照ください。 9/19(金) AWS が簡素化されたモデリングのための SiteWise MCP Server を発表 AWS が AWS IoT SiteWise 向けの MCP (Model Context Protocol) サーバーをオープンソースで公開しました。このサーバーは産業データのモデリング作業を大幅に簡素化し、従来必要だった複雑な API 知識がなくても会話型インターフェースで直感的に操作できるようになります。産業分野の専門知識が内蔵されており、適切な単位やデータ型を自動で適用するため、手作業での調整や修正作業が不要になり開発時間を大幅に短縮できます。詳細は こちらの GitHub リポジトリをご参照ください。 AWS Neuron SDK 2.26.0 の発表 AWS Neuron SDK 2.26.0 が一般提供開始となりました。この SDK は Inferentia や Trainium インスタンスで機械学習モデルを効率的に実行するためのツールです。今回のアップデートでは PyTorch 2.8 や JAX 0.6.2 といった最新フレームワークに対応し、画像生成モデル FLUX.1-dev や大規模言語モデル Llama 4 の新バリアントを Trn2 インスタンス上で実行できるようになりました。特に注目すべきは Expert parallelism サポート (beta) により、複雑な MoE モデルを複数の NeuronCore に分散して効率的に処理できる点です。詳細は こちらのドキュメントをご参照ください。 最後にイベントのお知らせです。2025年10月9日（木）19:00-「10 周年を迎えた AWS IoT Core – 過去を振り返り、未来を見据えて」というテーマで、目黒セントラルスクエア現地のみのイベントを開催いたします。詳細、お申し込みは こちら 。AWS が 2015 年の re:Invent で IoT 向けのサービスを発表してから 10 年が経ちました。この記念すべき節目を迎え、IoT を取り巻く環境の劇的な変化を振り返るとともに、未来への展望を共有する特別なイベントとなります。お客様セッションやネットワーキングもご用意がございます。私も参加いたしますので、ぜひお声掛けください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料食品やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

この記事は 2025 年 8 月 27 日公開の韓国語記事 래빗 워크의 제작 혁신 を翻訳したものです。 Rabbit Walks Inc.（以下ラビット ウォークス）は、2010 年に設立された特殊映像専門会社で、世界初の立体テレビコンテンツ制作を皮切りに業界をリードしてきました。サムスン電子、LG、現代自動車などグローバルブランドとコラボレーションし、高画質デモコンテンツやインタラクティブ展示コンテンツなどを制作してきており、CES、IFA、ISE、Infocomm などの世界的な展示会でも技術力を認められている韓国の代表的な VFX 産業基盤の会社です。 約 75 人のメンバーで構成されたラビット ウォークスは、企画、演出、デザイン、作曲などコンテンツ制作の全行程を自社内で遂行できる「オールインワン」の組織構造を備えています。これらの「ワンストップソリューション」の能力は、迅速な意思決定と創造的なアイデアの即時実装を可能にしますが、同時にプロジェクトが集中すると、コンピューティングリソース、特にレンダリングパワーの需要が爆発的に増加する要因にもなります。 特にリアルタイムゲームエンジンベースのレンダリングのない CG コンテンツ制作技術をもとに、ライブ放送とストリーミング環境に最適化された VFX ワークフローを運営しており、最近では AI 技術を活用した高画質広告コンテンツやデジタルヒューマン制作まで商用化に成功しました。このように最先端技術を積極的に導入する過程で、AI モデルの学習や高解像度の最終結果出力など、既存のリアルタイムワークフローを補完する大規模なプリレンダリング作業の必要性が出てきました。 次世代製品の開発段階から、お客様と協力してインターフェースや視覚化コンテンツを共に開発する「先行開発コンテンツ」分野でも強みを見せ、AR ガラス、透明 OLED、ホログラムディスプレイ、モジュラーディスプレイなど未来型デバイスに最適化されたコンテンツを継続的に披露しています。 2025 年には欧州進出を本格化し、イタリアのミラノに法人を設立し、今後はパリおよびミラノオリンピック関連プロジェクトの実施を準備中です。 このようなグローバル展開と超大型 / 超高画質プロジェクトは予測不可能な規模のレンダリング需要を生み出し、既存の固定オンプレミスインフラだけでは対応し難い課題をもたらします。 超大型 / 超高画質サイネージ、空間演出、ホログラムコンテンツなど、次世代インタラクティブメディア領域においても継続的な技術投資と研究開発を続けています。 Deadline Cloud レンダーファームプロジェクトの背景 ラビット ウォークスは、最先端の技術力と芸術性を組み合わせてメディア業界の新しい基準を提示してきました。特に AI 技術の融合、18K 以上の超高解像度コンテンツ制作、グローバルプロジェクトの遂行など、ビジネスの成功拡大は、既存のオンプレミスインフラに新たな課題をもたらしました。これらの背景の中で、ラビット ウォークスは将来の成長を支える柔軟で強力なレンダリング環境を構築するためクラウド導入を決定し、そのコアソリューションとして AWS Deadline Cloud を選択しました。 この過程で、レンダーファームの技術と多様なコンピテンシー能力を保有している AWS のパートナーである Megazone Cloud は、AWS Deadline Cloud の設計から技術サポートまで、全方位的なパートナーシップを提供し、ラビット ウォークスがより安定的で柔軟なコンテンツ制作環境を確保する上で重要な役割を果たしました。 当初の課題 現在、ラビット ウォークスは約 50 台規模の高性能 GPU（RTX 3080Ti 以上）で構成された社内レンダーファームを運用しています。これは十分に強力な設備ですが、ビジネスの爆発的な成長の中で、次のような「成長痛」を経験していました。 リソースの非効率的な割り当て: レンダリング作業中に複数の GPU リソ​​ースが 4 または 10 単位の固定グループに割り当てられる構造のため、30 人を超えるアーティストが同時に作業を進行するときに余剰リソースが発生するにもかかわらず、特定のワークグループでボトルネックが発生する問題がありました。これはアーティストの待ち時間を増やし、全体的な生産性を低下させる主な原因でした。 予測不可能な需要に対する対応が困難： 最近 4K を超えて 8K、18K 以上の超大型プロジェクトの受注が増加し、レンダリングに必要なコンピューティングパワーが指数関数的に増加しました。特定のプロジェクトの締切が差し迫ったとき、瞬間的に通常の数倍に達するレンダリングリソースが必要でしたが、物理的に限られたオンプレミスファームではこれらのピーク需要にすぐに対応できませんでした。 膨大な増設費用と将来の不確実性： これらの問題を解決するためにレンダーファームの増設を検討しましたが、GPU 端末 1 台に数千万ウォンに達する膨大な初期投資費用が負担となりました。さらに重要な問題は、将来のプロジェクト規模と必要な GPU 仕様を予測するのが難しいということでした。今すぐ巨額を投資して増設しても、1～2 年後にはより高性能な GPU が必要になるか、逆にプロジェクトがない期間には高価な機器の余剰が発生する可能性がありました。 レンダーファーム増設の難しさ これらの問題に対処するためにレンダーファームの増設を検討しましたが、1 台の機器を増設するには少なくとも 4000 万ウォン以上の費用がかかります。これは短期的な解決策には適しているかもしれませんが、会社の継続的な成長と従業員の増加に比例したレンダーファームの確保には根本的な限界があります。 既存の選択肢の限界と新しい基準の必要性 ラビット ウォークスは、オンプレミスの増設に加えて、他の代替案も慎重に検討しました。 短期での機器のレンタル： 外部機器を借りる方法は作業に比べて費用対効果が低く、機器の設置や撤退の過程に別々の管理人員と時間が投入される運営上の負荷が高い。 オンラインレンダーファームサービス： 従来の商用オンラインレンダーファームサービスは、間欠的なエラーが発生した場合、即時の技術サポートが困難であり、特に大規模なプロジェクトを長期的に進める場合、予測するのが難しいコスト構造のために実質的な代替策になり得なかった。 このように、既存の代替案の明確な限界は、ラビット ウォークスがレンダリングインフラストラクチャの新しい基準を確立することになったきっかけになりました。必要なのは単により多くのコンピューティングパワーではありませんでした。 必要に応じてすぐに使用できる「弾力性」 使用した分だけ費用を支払う「経済性」 複雑な設定なしでアーティストが創作に集中できるようにする「シンプルさ」 信頼できる技術サポートが保証される「信頼性」 この 4 つの基準が次世代レンダリング環境には重要な要件でした。 レンダリング環境改善の取り組みにおける選択 これまでの社内のレンダリング設備には限界があり、外部への代替え案も効率的とは言えない状況です。一方で、制作プロジェクトは増加の一途をたどり、作品の品質要求も高度化しています。この状況に対応するためには、安定性と拡張性を備えた新しいレンダリング環境が必要です。そこで私たちは、効率的なリソース管理が可能で、将来の需要増加にも柔軟に対応できるAWS Deadline Cloudの導入を決定しました。 クラウドレンダーファーム導入過程と当初の技術的課題 AWS Deadline Cloud 導入戦略の策定 ラビット ウォークスの既存のオンプレミス環境と要件を分析した結果、AWS Deadline Cloud が最適なソリューションと判断されました。しかし、既存のワークフローとの互換性、アーティストの学習曲線、そして多様なレンダリングエンジンのサポートなど解決しなければならない課題がありました。 そのため、Magazone Cloud とともに段階的導入戦略を策定し、リスクを最小限に抑えながら実質的な成果を確認できるロードマップを設計しました。 導入ステップ 1：SMF (Service Managed Fleet) 環境の構築と初期テスト 期間：2024 年 10 月 20 日～ 2024 年 11 月 13 日 目標：AWS Deadline Cloud の基本機能の検証と既存のワークフローとの互換性を確認 構成環境： レンダリングソフトウェア： Houdini 19.5 レンダリングエンジン: Mantra 制限事項： Cinema4D および Redshift の UBL (Usage-Based Licensing) 未サポート (2024年当時の状況。現在はサポート済み) 主な成果： AWS Deadline Cloud の基本アーキテクチャとジョブ送信プロセスの理解 クラウド環境におけるレンダリングパフォーマンスベースラインの確保 ネットワーク帯域幅とファイル転送最適化方式の導出 当初の技術的課題： ライセンス管理の複雑さ &nbsp;既存のオンプレミスライセンスとクラウド環境間の互換性の問題 UBL 方式のライセンス未サポートによるソフトウェア制約 ネットワーク最適化の必要性 大容量 3D アセットファイルのアップロード/ダウンロード時間の問題 社内ネットワーク帯域幅制約の特定 ワークフローの標準化 既存のパイプラインとクラウド環境間の統合方式が必要 導入ステップ 2：パフォーマンスの最適化と GPU タイプの選択 期間：2025 年 3 月 ～ 2025 年 4 月 目標：Cinema4D ワークロードに最適化された GPU インスタンスタイプの選択 テスト方法論： 実稼働プロジェクトと同じ条件でベンチマーク操作を実行 さまざまな EC2 GPU インスタンスタイプによるパフォーマンスとコスト効率の比較分析 レンダリングの複雑さに応じた最適なインスタンス構成の導出 性能テスト結果： インスタンスタイプによるパフォーマンス比較： G4dn.xlarge：基本的なパフォーマンスベースライン G5.2xlarge：約 40％ の性能向上 G6.12xlarge：約 75％ の性能向上 (最終選定) コスト効率分析： 純粋なレンダリング時間に対して約 60％ のコスト削減 プロジェクトターンアラウンド時間 90％ 以上短縮 技術的な洞察： NVIDIA RTX A10G ベースの G5 インスタンスが Cinema4D + Redshift の組み合わせで最適なパフォーマンスを発揮 メモリ集約型タスクでは、G6インスタンスの優れたGPUメモリ効率の確認 Spot インスタンスを活用した場合の追加で 30% コスト削減の可能性の確認 導入ステップ3 ： CMF (Customer Managed Fleet) の移行と本格的な運用 期間：2025 年 5 月 15 日～現在 目標：完全な実稼働環境の構築とスケーラブルなワークフローの完成 主な改善点： オペレーティングシステムの最適化 &nbsp;Linux ベースのレンダリング環境に切り替える コンテナベースのワークフロー導入により環境一貫性を確保 ライセンス管理の改善 Cinema4D と Redshift のクラウド互換ライセンスを取得 動的ライセンス割り当てシステムの構築 自動化と監視 &nbsp;CloudWatch によるリアルタイムレンダリングジョブの監視 自動スケーリングポリシーの最適化 運営上の課題と解決策： 課題 1：アーティストの教育と適応 解決策：段階的教育プログラムの運営 既存のワークフローと同様の UI/UX を提供 専門技術支援チームの運営 課題 2：ハイブリッド環境管理 解決策：オンプレミスとクラウド間の作業優先度、自動判断ロジックの実装 統合ダッシュボードによる完全なリソースの可視性の確保 課題 3：コスト最適化 解決策： 作業パターン分析に基づく予測スケーリング Reserved Instance と Spot Instance の混合での活用 リアルタイムコスト監視と通知システムの構築 導入の過程で得た主な教訓 段階的な移行の重要性 段階的導入をすることでリスク最小化と学習効果を最大化 各段階的なパフォーマンス測定による継続的な改善 技術パートナーシップの価値 パートナー Megazone Cloud の専門性が導入期間の短縮と安定性確保に決定的に貢献 24 時間 365 日の技術支援による運用安定性の確保 柔軟な管理の重要性 アーティスト中心でユーザー体験を設計 十分な教育と段階的な移行で現場のストレスを最小限に抑える 以上の体系的な導入プロセスにより、ラビット ウォークスは本番環境に AWS Deadline Cloud を統合することができました。 テスト環境とワークロード &lt;Deadline Cloud Rendering Architecture&gt; レンダリング内容 解像度：8880 x 1890 (Ultra-wide 4K) レンダリングフレーム数：91 フレーム 事前予想コスト：ハイパフォーマンスレンダリングに ＄880 以上と予測 テストインフラストラクチャの構成 オンプレミス環境 (ローカルPC) GPU：NVIDIA RTX 3080 Ti 4 台構成 1 フレームのレンダリング時間：約 32 分 総レンダリング時間：約 12 時間 8 分 AWS Deadline Cloud 環境 インスタンスタイプ：G6.12xlarge (GPU 最適化タイプインスタンス) テスト構成：1 回目、2 回目、3 回目スケーリングテスト &lt;Deadline Cloud Monitoring Dashboard&gt; 性能比較結果 レンダリング時間の最適化 AWS Deadline Cloud のスケーリング効果がはっきりと現れました。 構成 1 フレーム レンダリング 時間 総 レンダリング 時間 パフォーマンス の向上 ローカルPC (RTX 3080 Ti x4) 32 分 12 時間 8 分 基準 Deadline Cloud 1 回目 15 分 30 秒 47 分 50 秒 93％ 短縮 Deadline Cloud 2 回目 8 分 9 秒 39 分 23 秒 95％ 短縮 Deadline Cloud 3 回目 16 分 1 時間 4 分 91％ 短縮 コアパフォーマンス 劇的なパフォーマンス向上 最適構成（2 回目テスト）で総レンダリング時間を 12 時間から 39 分に 95％ 短縮 シングルフレームレンダリング時間を 32 分から 8 分 9 秒に 75% 改善 弾力的な拡張性 ワークロードに応じた動的なリソース割り当てによるコスト効率の最大化 ピークタイムゾーンの自動スケーリングによるボトルネックの除去 ネットワーク伝送の最適化 ファイル転送性能 アップロード：レンダーファーム→Dropbox 約 7-8 分（テスト自動化環境） ダウンロード：Dropbox →ローカル 約 40 分 ネットワーク最適化: 社内帯域幅の制約が主なボトルネックとして特定 技術的な洞察 ワークロード分散の効率性 AWS Deadline Cloud の自動分散機能により、91 フレームを複数インスタンスに最適に配分して処理時間を大幅に短縮しました。 GPU リソースの活用 G6.12xlarge インスタンスの高性能な GPU は、複雑な 3D レンダリングにおいてオンプレミス環境と比べて優れたパフォーマンスを示しました。 費用対効果 初期予想コスト $ 880 と比較して、実際のクラウドレンダリングのコスト効率と時間短縮による運用コスト削減が証明されました。 結論 ラビット ウォークスとのコラボレーションにより、AWS Deadline Cloud は既存のオンプレミスレンダーファームと比較して次の重要な価値を提供することを確認しました。 パフォーマンス：最大 95％ のレンダリング時間を短縮 スケーラビリティ：プロジェクトの規模に応じた柔軟なリソース拡張 コスト効率：使用した分だけ支払うモデルで運用コストを最適化 管理の利便性：インフラ管理負担の除去 今回のテスト結果は、3D レンダリングスタジオがクラウド移行を通じて得られる実用的なビジネス価値を明確に示すとともに、AWS Deadline Cloud が現代のメディア制作ワークフローにおけるコアソリューションであることを実証しました。 Deadline Cloud 以外で今回追加した実装部分について ラビット ウォークスは、アーティストのリモート作業環境をサポートするために、 Amazon Elastic Compute Cloud (Amazon EC2) &nbsp;と Amazon DCV を活用したワークステーションの設定も行いました。一方で、アーティストは AWS コンソールを介した EC2 サーバーの管理に精通していなかったため、 Amazon Cognito 、 Amazon CloudFront 、 Amzazon Simple Storage Service (Amazon S3) 、 Amazon API Gateway を組み合わせてサーバーレスベースのリモートサーバー管理ページを個別に構築しました。これにより、アーティストは簡単に EC2 のクラウドワークステーションを管理できるようになり、リモートサーバーを使用して社内ネットワークから AWS Deadline Cloud へのアップロード速度も大幅に向上しました。また、必要に応じて高性能なサーバーに簡単に切り替えができ、作業効率を高めるとともに、運営およびメンテナンスへの負担も軽減できる環境を整えました。 &lt;Rabbitwalks Renderfarm Process Architecture&gt; 作業結果のパフォーマンスについて 今回のプロジェクトでは AWS Deadline Cloud を導入したことで、オンプレミス環境では締切までの完成が難しかったスケジュールをこなすことできました。 特に、当日午前に要求された修正を反映した映像を同日午後までに提供できることは、従来の環境ではほぼ不可能なことでしたが、AWS Deadline Cloud を活用することで、厳しい作業スケジュールにも安定した映像の提供ができるようになりました。 従来のオンプレミス環境では、1 フレームのレンダリングに約 32 分かかりましたが、AWS Deadline Cloud レンダーファームを利用した結果、15～16 分に大幅に短縮できました。 &lt;Rabbitwalks Renderfarm Architecture&gt; Deadline Cloud導入後のプラン ラビット ウォークスは AWS Deadline Cloud を活用し、高速かつコスト効率の高いレンダリング環境を実現しました。これにより、プロジェクトごとに必要なリソースを柔軟に活用できる体制を整えています。 今後は、ワークロードのクラウド移行を進めることで、災害対策 (DR) の強化、映像データの迅速な運用、そして GenAI を用いた企画・制作プロセスの効率化を目指しています。こうした取り組みによって、最終成果物の完成までのスピードを加速させ、新しい映像制作のスタイルをいち早く実現し、ビジネスの成長につなげていきます。 パク・チャンモク、ラビット ウォークス 3D チームリーダー パク・チャンモクは現在、ラビット ウォークスでチームリーダーとして、様々なプロジェクトを率いています。R&amp;D 部門で新しい技術とワークフローを実験する役割として、Houdini、Cinema 4D、Unreal Engine、Redshift などのツールを活用したコンテンツ制作に集中しています。最近では、クラウドベースのレンダリング環境を構築し、生成 AI と機械学習技術を視覚芸術分野に融合する研究を通じて、新しい表現方式と制作方式を模索しています。 キム・ユンスク、Megazone Cloud メディアスペシャルチーム キム・ユンスク Megazone Cloud メディアユニットクラウドテック担当者は、メディア・VFX 顧客のクラウド基盤制作環境の構築を支援しており、プレセールスエンジニアとして顧客カスタマイズ型アーキテクチャ設計及びコンサルティングを通じて実質的な技術転換を導いています。 アンテヨン、Megazone Cloud メディアユニットクラウドセールス アンテヨン Megazone Cloud メディアユニットクラウドセールス担当者は、 メディア・VFX 業界のお客様が AWS クラウドをベースに制作効率と技術競争力を確保できるように、インフラストラクチャの提案とクラウド移行を支援しています。 チョウ・ボラエ チョウ・ボラエは AWS のシニアソリューションズアーキテクトで、ビジュアルコンピューティングの分野を担当しています。スタジオ制作プロセスの技術に対する豊富な経験に基づき、生成 AI とエージェント AI の分野で革新的な作業を進めています。 ソ・ダンヒ ソ・ダンヒ (AWS Cloud Sales Rep) は、AWS カスタマーのデジタルイノベーションとビジネス成長のための信頼できるパートナーになることを目指しています。具体的には、お客様が AWS クラウドを効果的に活用してビジネス目標を達成できるように、統合的なクラウド旅行をサポートしています。 <!-- '"` --> カン・スンウク カン・スンウク Solutions Architect は、長年のバックエンド開発経験に基づいて、スタートアップからエンタープライズまで、さまざまな顧客の AWS ベースのワークロード実装をサポートしています。現在、CSC チームで迅速なイノベーションを推進する企業に、スケーラブルな技術ソリューションとアーキテクチャガイダンスを提供し、顧客のデジタル転換とクラウドの旅を加速する役割を担っています。 本記事は、 2025 年 8 月 27 日公開の韓国語記事 래빗 워크의 제작 혁신 を翻訳したものです。 翻訳は Sir. Visual Compute Specialist Solutions Architect の森が担当しました。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

本記事は米国時間 2025 年 9 月 15 日に公開された Announcing new pricing plans and Auto, our new agent を翻訳したものです。 Kiro は 9 月 30 日まで引き続き無料でご利用いただけます。10 月 1 日以降は、選択したプランに応じて課金されます。 この 1 か月間、皆さまから Kiro に関する素晴らしいフィードバックをいただきました。そのフィードバックや日常の開発作業における利用状況を踏まえ、Kiro の新しい料金体系を発表いたします。 統一された利用上限 : これまでの vibe タスクと spec タスクで別々だった上限をやめ、すべてのリクエストが 単一のクレジットプール から消費されるようになります。これにより、柔軟にコントロールしながら Kiro をご利用いただけます。新しい統一上限は以下の通りです。 &nbsp; 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 ボーナスクレジットが付与されます。 チームでサブスクリプションを共有できますか？ いいえ。利用制限はユーザー単位で計算されます。&nbsp;組織向けの課金・管理機能は今後提供予定です。 未使用クレジットは翌月に繰り越せますか？ 利用制限は各請求月の初日にリセットされます。未使用のクレジットは翌月に繰り越せません。 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=&lt;s3 bucket name&gt; \ -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://&lt;s3 bucket name&gt;/' TBLPROPERTIES ``( 'areColumnsQuoted'='false', 'classification'='csv', 'columnsOrdered'='true', 'compressionType'='none', 'delimiter'=',', 'skip.header.line.count'='1', 'typeOfData'='file' &lt;s3 bucket name&gt; は、生成されたレポートを保存するために作成したバケット名に置き換えることを覚えておいてください。 このクエリを実行後、 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 &gt; 365 ORDER BY dayssincelastpull DESC limit 10; 言い換えれば、このデータで好きなだけ創造性を発揮できるということです！この手順では、CSV 出力形式を利用しました。Parquet や JSON の利用も同様ですが、若干の変更が必要になる場合があります (本記事の範囲外です)。 クリーンアップ レポートを Amazon S3 に保存し、Amazon Athena を利用して分析する場合、AWS アカウントに課金されます。もし、あなたが不要な課金が発生しないようにクリーンアップすることを決めたなら、このデプロイ中に作成された全ての AWS リソースを削除してください。 Amazon S3 バケットとコンテンツを削除する aws s3 rb s3://&lt;bucket name&gt; --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://&lt;s3 bucket name&gt;/ # Delete Athena database using AWS CLI aws athena start-query-execution \ --query-string "DROP DATABASE IF EXISTS \`ecr_repository_summary\`;" \ --result-configuration OutputLocation= s3://&lt;s3 bucket name&gt;/ IAM ユーザーやロールにアタッチされた IAM ポリシーをデタッチする aws iam detach-user-policy --user-name &lt;user name&gt; --policy-arn &lt;policy ARN&gt; aws iam detach-role-policy --role-name &lt;role name&gt; --policy-arn &lt;policy ARN&gt; おわりに パフォーマンスとイノベーションを維持しながら 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://&lt;hostname&gt;:&lt;port&gt; 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を見つけます。 ボットを選択します。 チームに追加 を選択し、プロンプトを完了します &nbsp; ステップ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&nbsp; と名付けました ポリシー テンプレート : Amazon Q Developer access permissions チャンネルガードレールポリシー[ポリシー名]: AWSLambdaBasicExecutionRole 、 AmazonQDeveloperAccess。 要件に応じてIAMポリシーを調整できますが、常に 最小権限 権限 のベストプラクティスに従うことを推奨します。 ステップ4: 次に、エージェントをチャットチャンネルに接続します Amazon Q Developer Bedrock Agentコネクタには bedrock:InvokeAgent IAMアクションが必要です。 前のステップで作成したIAMロール： awschatbot-sap-genai-teams-role&nbsp; に以下のポリシーを追加します。 { "Sid": "AllowInvokeBedrockAgent", "Effect": "Allow", "Action": "bedrock:InvokeAgent", "Resource": [ "arn:aws:bedrock:aws-region:&lt;AWS Account ID&gt;:agent-alias/&lt;Bedrock Agent ID&gt;/&lt;Agent Alias ID&gt;/" ] } 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&nbsp; と名付けました ポリシー テンプレート : Amazon Q Developer access permissions チャンネルガードレールポリシー[ポリシー名]: AWSLambdaBasicExecutionRole 、 AmazonQDeveloperAccess。 要件に応じてIAMポリシーを調整できますが、常に 最小権限 権限 のベストプラクティスに従うことを推奨します。 ステップ4: 次に、エージェントをチャットチャンネルに接続します Amazon Q Developer Bedrock Agentコネクタには bedrock:InvokeAgent IAMアクションが必要です。 前のステップで作成したIAMロール： awschatbot-sap-genai-teams-role&nbsp; に以下のポリシーを追加します。 { "Sid": "AllowInvokeBedrockAgent", "Effect": "Allow", "Action": "bedrock:InvokeAgent", "Resource": [ "arn:aws:bedrock:aws-region:&lt;AWS Account ID&gt;:agent-alias/&lt;Bedrock Agent ID&gt;/&lt;Agent Alias ID&gt;/" ] } 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 &amp; Streamlitは8501から1ずつ増加して利用可能なポートを割り当てます。streamlitに特定のポートを考慮させたい場合は、以下のコマンドを使用できます $streamlit run streamlit-app.py --server.port XXXX&nbsp; 上記のコマンドを実行した後、以下に示すように、ブラウザで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 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 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 です。 &nbsp; [インスタンスを起動] ページで [名前] に入力します。ここでは 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 ==&gt; 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 ==&gt; Fetching downloads for: xcodeinstall ==&gt; Fetching sebsto/macos/xcodeinstall ==&gt; 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 ==&gt; Installing xcodeinstall from sebsto/macos ==&gt; Pouring xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz 🍺 /opt/homebrew/Cellar/xcodeinstall/0.12.0: 8 files, 55.2MB ==&gt; 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`). ==&gt; 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界隈のニュースを見ていきましょう！ さまざまなニュース 資料公開 &amp; 開催報告 「AWS for Software &amp; 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 &nbsp;シリーズの一部です。毎週、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 プレイリスト にサブスクライブしてください。 このブログは&nbsp;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 何が起きるか &nbsp; : 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. 監視対象のパス :&nbsp; **/*.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 を高度なオートコンプリートツールとして扱うのではなく、戦略的な思考のパートナーとして位置づけることで、変更コストが高くなる前により良い意思決定を行えるようになります。結果として、開発サイクルはより速くなり、コードの品質は向上し、予期せぬ事態は減少し、ドキュメントはプロセスに統合されているため後付けではなく常に最新の状態に保たれます。次に新しい機能を構築するときは、コードではなく仕様から始めてみてください。将来の自分（そしてチームメイト）はその明確さに感謝するでしょう。そして、最高のコードとは書く前に計画されたコードであると気づくかもしれません。 準備はできましたか？違いを体験してみましょう。 ウェイトリスト に参加してください。