本ブログは 2025 年 11 月 19 日に公開された AWS Blog “ New Amazon Threat Intelligence findings: Nation-state actors bridging cyber and kinetic warfare ” を翻訳したものです。 新たな脅威の状況 サイバー戦争と従来のキネティック作戦 (kinetic operations/物理的軍事作戦) の境界線は急速に薄れています。Amazon 脅威インテリジェンスチームによる最近の調査では、国家支援型脅威アクターがキネティック作戦の遂行と強化にサイバーを体系的に活用する新たなトレンドが明らかになりました。チームはこのトレンドを「サイバー支援キネティックターゲティング (物理的軍事攻撃の標的選定)」と呼んでいます。従来のサイバーセキュリティフレームワークでは、デジタルの脅威と物理的な脅威を別々の領域として扱うことが多くありました。しかし、私たちの調査研究では、この区別はもはや実態にそぐわなくなっていることが明らかになりました。複数の国家支援型脅威グループが、サイバー偵察を通じてキネティックターゲティングを直接可能にする新しい作戦モデルを開拓しています。 国家支援型アクターの戦争へのアプローチに根本的な変化が起きていることを確認しています。これらは単にたまたま物理的な被害を引き起こすサイバー攻撃ではありません。物理的な軍事目標を支援するために意図的に設計された組織的なキャンペーンなのです。 Amazon 独自の可視性 Amazon 脅威インテリジェンスがこれらのキャンペーンを特定できるのは、グローバルな脅威の状況における独自のポジションに起因しています。 脅威インテリジェンステレメトリ : Amazon のグローバルクラウドオペレーションは、多様な環境にわたる脅威を可視化できます。これには Amazon MadPot ハニーポットシステムからのインテリジェンスが含まれ、攻撃の兆候を示すパターン、攻撃者のインフラストラクチャ、およびこれらのサイバー支援キネティックターゲティングキャンペーンで使用されるネットワーク経路の検出を可能にします オプトイン (同意に基づく) 顧客データ : エンタープライズ環境からオプトインベースで提供される、脅威アクターの活動の試みに関する実際のデータ 業界パートナーとの連携 : 主要なセキュリティ組織や政府機関との脅威インテリジェンス共有により、観測されたアクティビティに対する追加のコンテキストと検証を得ています こうした複数の情報源を組み合わせることで、個々の組織や政府機関だけでは気づけない攻撃活動の関連性を、Amazon は捉えることができます。 ケーススタディ 1: Imperial Kitten の海運インフラ攻撃キャンペーン 最初のケーススタディは、イラン革命防衛隊 (IRGC) のために活動していると疑われる脅威グループ Imperial Kitten に関するものです。このタイムラインは、デジタル偵察がいかにしてキネティック攻撃へとつながったかを示しています。 2021 年 12 月 4 日 : Imperial Kitten が海上船舶の船舶自動識別システム (AIS) プラットフォームを侵害し、重要な海運インフラへのアクセスを獲得。Amazon 脅威インテリジェンスチームがこの侵害を特定し、影響を受けた組織と協力してセキュリティイベントを修復 2022 年 8 月 14 日 : 脅威アクターが追加の船舶プラットフォームへの海上ターゲティングを拡大。その一例として、海上船舶に搭載された CCTV カメラへのアクセスを獲得し、リアルタイムの視覚的インテリジェンスを取得 2024 年 1 月 27 日 : Imperial Kitten が特定の船舶の AIS 位置データを標的とした検索を実施。これは、広範な偵察から標的を絞ったインテリジェンス収集への明確な移行を示している 2024 年 2 月 1 日 : フーシ派勢力によるミサイル攻撃が発生し、アメリカ中央軍が報告。標的となったのは、Imperial Kitten がサイバー偵察で位置情報を収集していた船舶そのものだった。ミサイル攻撃は失敗に終わったものの、サイバー偵察とキネティック攻撃 (物理的軍事攻撃) が連動していたことは明白だった。 このケースは、サイバー偵察で得た正確な情報をもとに、敵対者が海運インフラへのキネティック攻撃を実行できることを示しています。海運インフラは、国際貿易や軍事補給を支える重要な基盤です。 ケーススタディ 2: MuddyWater のエルサレム作戦 2 番目のケーススタディは、脅威グループ MuddyWater に関するものです。米国政府は、このグループがイラン情報安全保障省 (MOIS) の指揮下にある Rana Intelligence Computer Company によって運営されていると指摘しています。このケースでは、サイバー軍事作戦とキネティックターゲティングがさらに密接に連動していたことが明らかになっています。 2025 年 5 月 13 日 : MuddyWater がサイバーネットワーク作戦専用のサーバーをプロビジョニングし、キャンペーンに必要なインフラストラクチャを確立 2025 年 6 月 17 日 : 脅威アクターがサーバーインフラストラクチャを使用して、エルサレムからのライブ CCTV ストリームを含む別の侵害されたサーバーにアクセス。これにより、市内の標的候補をリアルタイムの映像で監視し、視覚的インテリジェンスを収集できるようになった 2025 年 6 月 23 日 : イランがエルサレムに対して広範なミサイル攻撃を開始。同日、イスラエル当局は、イラン軍がリアルタイムのインテリジェンスを収集し、ミサイルの照準を調整するために侵害されたセキュリティカメラを悪用していたと報告 このタイミングは偶然ではありません。 The Record の報道によると、イスラエル当局は市民にインターネット接続されたセキュリティカメラを切断するよう促し、イランが「リアルタイムのインテリジェンスを収集し、ミサイルの照準を調整するために」それらを悪用していると警告しました。 技術インフラストラクチャと手法 Amazon の調査では、これらの作戦を支える高度な技術インフラストラクチャを明らかにしました。脅威アクターは多層的なアプローチを採用しており、その主な要素は以下の通りです。 匿名化 VPN ネットワーク : 脅威アクターは、匿名化 VPN サービスを経由することで発信元を隠し、攻撃元の特定を困難にする 攻撃者が制御するサーバー : 専用のインフラストラクチャを構築し、継続的な作戦のための永続的なアクセスとコマンド＆コントロール（C&C）機能を確保する 侵害されたエンタープライズシステム : CCTV システム、海上プラットフォームなど、情報価値の高い重要インフラをホストするエンタープライズサーバーに侵入する リアルタイムデータストリーミング : 侵害したカメラやセンサーからライブ映像を取得し、ほぼリアルタイムで標的の照準調整に活用する 新しい戦争カテゴリの定義 私たちの調査チームは、これらのハイブリッド作戦を説明するための新しい用語を提案しています。従来の用語では、今回明らかになった脅威を適切に表現できないためです。 サイバーキネティック作戦: この用語は、システムに物理的な損害を与えるサイバー攻撃を指すことが多く、今回のケースには当てはまらない ハイブリッド戦争: この用語は概念が広すぎ、サイバーと物理の統合に特化していない そこで私たちは、「サイバー支援キネティックターゲティング」という用語を提案しています。これは、キネティック軍事作戦の遂行と強化を目的として設計されたサイバー作戦キャンペーンを、より正確に表現するためです。 防御者への影響 サイバーセキュリティコミュニティにとって、この調査は警告であると同時に行動への呼びかけでもあります。防御者は、デジタルと物理の両方の領域にまたがる脅威に対処するために戦略を適応させる必要があります。これまで脅威アクターの関心の対象ではないと考えていた組織も、今では戦術的インテリジェンスのために標的にされる可能性があります。脅威モデリングを拡張し、インテリジェンス共有を強化し、多様な敵対者によるサイバー支援キネティックターゲティングの現実を考慮した新しい防御戦略を開発する必要があります。 脅威モデリングの拡張 : 組織は、サイバー攻撃の直接的な影響だけでなく、侵害されたシステムが自組織や他者に対するキネティック攻撃を支援するためにどのように使用される可能性があるかを考慮する必要があります 重要インフラストラクチャの保護 : 海上システム、都市監視ネットワーク、その他のインフラストラクチャの運用者は、自分たちのシステムがスパイ活動だけでなく、キネティック作戦の照準支援としても価値がある可能性があることを認識する必要があります インテリジェンス共有 : これらのケースは、民間セクター組織、政府機関、国際パートナー間での脅威インテリジェンス共有の重要性を示しています 攻撃元特定の課題 : サイバー軍事作戦がキネティック攻撃を直接可能にする場合、攻撃元の特定と対応のフレームワークはより複雑になり、サイバーセキュリティ、軍事、外交チャネル間の連携が必要になる可能性があります 今後の展望 私たちは、サイバー支援キネティックターゲティングが複数の敵対者にわたってますます一般的になると考えています。国家支援型アクターは、デジタル偵察とキネティック攻撃を組み合わせることによる戦力増強効果を認識しています。このトレンドは、サイバー軍事作戦とキネティック作戦の間の従来の境界線が消滅しつつある、戦争の根本的な進化を表しています。 侵害指標 (IOC) IOC 値, IOC タイプ, 初回確認日, 最終確認日,備考 18[.]219.14.54, IPv4, 2025-05-13, 2025-06-17, MuddyWater の C&C IP アドレス 85[.]239.63.179, IPv4, 2023-08-13, 2025-09-19, Imperial Kitten のプロキシ IP アドレス 37[.]120.233.84, IPv4, 2021-01-01, 2022-11-01, Imperial Kitten のプロキシ IP アドレス 95[.]179.207.105, IPv4, 2020-11-11, 2022-04-09, Imperial Kitten のプロキシ IP アドレス このブログ記事は、Amazon 脅威インテリジェンスの Principal Engineer である David Magnotti と Senior Threat Intelligence Engineer である Dlshad Othman が CYBERWARCON で発表した調査に基づいています。著者らは、軍事活動の報告における透明性についてアメリカ中央軍に感謝するとともに、これらの重要な調査におけるお客様とパートナーの継続的なサポートに謝意を表します。 この記事に関するご質問がある場合は、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。彼のミッションは、セキュリティのメリットを最も抵抗の少ない道にすることで、Amazon のビジネスを支援することです。2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO など様々な役職を歴任した後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 Amazon 入社前は、連邦捜査局 (FBI) サイバー部門でコンピュータおよびネットワーク侵入対策の技術分析を指揮していました。また、空軍特別捜査局 (AFOSI) の特別捜査官としても勤務しました。今日のセキュリティ業界の基盤となったと見なされる複数のコンピュータ侵入捜査を指揮しました。 コンピュータサイエンスと刑事司法の学位を持ち、現役の SRO GT America GT2 レースカードライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

この シリーズのパート1 では、Amazon Q BusinessとAmazon Bedrockの力を組み合わせて、SAP Early Watch Reportsから実用的なインサイトを得る方法、およびBusiness Data Automationを使用したIntelligent Document ProcessingをSAPシステムの請求書データ処理に使用する方法を検討しました。この投稿では、Amazon Bedrock Knowledge Bases for Structured Dataを使用して、SAPデータに関する質問に自然言語形式で回答する方法を実演します。 自然言語を使用した財務データ分析 チャットベースのインターフェースは、営業チームとリーダーシップに迅速で実用的なインサイトを提供できます。売上と予測データへのアクセスと分析を容易にすることで、組織はより情報に基づいた意思決定を行い、市場の変化により迅速に対応し、複雑なデータ処理プラットフォームを学ぶ必要なく、最終的により良い営業パフォーマンスを推進できます。 営業パフォーマンス、製品インサイト、営業予測、地域比較などの情報は、構造化データ用Amazon Bedrock Knowledge Basesを使用して迅速に利用可能にできるデータの例です。このユースケースでは、Amazon Bedrock Knowledge Bases for Structure Dataを使用して、会話インターフェースを使用してデータへのインサイトを迅速に提供する方法を示します。 SQLデータ用の構造化ナレッジベースは、目的と実装の両方において従来のRAG（Retrieval Augmented Generation）とは異なります。RAGは主にLLMレスポンスを拡張するために非構造化テキストの関連チャンクを取得することに焦点を当てているのに対し、SQLデータ用の構造化ナレッジベースは、データベーススキーマ、テーブル、およびそれらの相互接続に関する明示的な関係、ビジネスルール、メタデータを維持します。この構造により、運用データのより正確で信頼性の高いクエリが可能になり、RAGの確率的性質が適切でない財務計算、在庫数、営業指標などの分野で保証された精度を提供します。 SQLデータ用の構造化ナレッジベースを使用する主な利点は、自然言語アクセスを提供しながらデータの整合性とビジネスロジックを維持できることです。RAGはドキュメントや非構造化コンテンツからのコンテキスト提供に優れていますが、構造化ナレッジベースは、運用データにとって重要なテーブル関係、データ型、ビジネスルールを尊重して、クエリが正しくSQLに変換されることを保証します。さらに、ERPデータには大きなデータセットが含まれており、従来のRAG技術を使用すると性能やコスト効率が良くない場合があります。ペタバイト規模の分析をサポートするAmazon Redshiftにデータを保存することで、大量のデータボリュームにアクセスし、Bedrockで利用可能な選択したLLMによって分析できます。 SAP Datasphere、SAP SLT、AWS Glue、パートナーソリューションなど、SAPが提供する技術を使用して、SAPまたは他のERPシステムからAmazon Redshiftにデータを移動してデータ分析を行うためのいくつかのオプションがあります。詳細については、 AWS上のSAPデータ統合と管理のガイダンス を参照してください。 注： このブログでは、Apache 2.0ライセンスの下でGitHubで SAPが公開した自転車販売サンプルデータ を使用します。これには、分析のためにS3にロードされる自転車販売データの例が含まれています。リアルタイムデータ更新を有効にするために、S3の情報は、この AWSブログ で説明されているように、自動コピーを使用して取り込むことができます。 エンタープライズデプロイメントの場合、ビジネスコンテキストをより良く保持するために、Amazon Redshiftにロードする前に Amazon S3への統合にSAP Datasphere の使用を検討してください。SAP DatasphereはSAP Business Technology PlatformとSAP Business Data Cloudの一部として利用でき、どちらもAWS上で実行されます。 アーキテクチャ 図1はソリューションのアーキテクチャ図を示しており、このセクションではそれを構築する手順を示します： データは、お好みの統合ソリューションを使用してSAPからS3にコピーされます。この場合、SAPが公開したBike Salesデータを使用します。 データはAmazon Redshiftデータウェアハウスにコピーされます。 構造化データ用Amazon Bedrock Knowledge Baseを設定します。 ユーザーは、正確な情報検索のためにSQLを生成するために、お好みのBedrockを活用します。 生成されたSQLは、Bedrockナレッジベースによって調整され、リアルタイム情報とスケーラビリティのためにAmazon Redshiftで実行されます。 モデルは、クエリの結果を使用して、リクエストに基づいてユーザーにインサイトを要約し提供します。コンテキストが維持されるため、ユーザーは会話形式で情報を詳しく調べることができます。 図1: 生成AIを使用した構造化データ分析のアーキテクチャ プロセス ここで概説されている手順に従うことで、Amazon Redshiftデータベースを作成し、Bedrockチャットインターフェースを使用して結果をクエリできます。 S3へのデータロード Amazon S3バケットを作成し（この場合、バケットをkb-structured-data-bike-salesと呼びますが、名前は一意である必要があります）、図2に示すように、Uploadボタンを選択し”Add Files”を選択して、 サンプルデータファイル （合計9ファイルである必要があります）をS3バケットにアップロードします。 図2: S3バケットでのSAPサンプルデータの保存 注： サンプルファイルEmployees.csvには、以下に示すようにいくつかの空白の列名があります。これらをヘッダーとデータ行で削除して、より簡単にインポートできるようにするために、お気に入りのエディターを使用してください。また、より最近の情報を提示するためにサンプルデータを更新することもできます。 EMPLOYEEID,NAME_FIRST,NAME_MIDDLE,NAME_LAST,NAME_INITIALS,SEX,LANGUAGE,PHONENUMBER,EMAILADDRESS,LOGINNAME,ADDRESSID,VALIDITY_STARTDATE,VALIDITY_ENDDATE,,,,,, 0000000001,Derrick,L,Magill,,M,E,630-374-0306,derrick.magill@itelo.info,derrickm,1000000001,20000101,99991231,,,,,, 0000000002,Philipp,T,Egger,,M,E,09603 61 24 64,philipp.egger@itelo.info,philippm,1000000002,20000101,99991231,,,,,, 0000000003,"Ellis",K,Robertson,,M,E,070 8691 2288,ellis.robertson@itelo.info,ellism,1000000003,20000101,99991231,,,,,, 0000000004,William,M,Mussen,,M,E,026734 4556,william.mussen@itelo.info,williamm,1000000004,20000101,99991231,,,,,, SAPデータと非SAPデータの結合 この段階で、SAPデータを他のビジネスソースからの非SAP関連データと組み合わせることもでき、それが生成AI技術を使用した統合エンタープライズの価値です。 クエリの容易さのためにAmazon Redshiftデータウェアハウスにデータをロード S3からRedshiftにデータを追加するには、次の手順に従います： Amazon Redshiftに移動し、サーバーレス名前空間を作成します。この例では、default-workgroupと名前空間を使用します。 Redshift Query Editorにアクセスするには、Amazon RedshiftのコンソールからQuery Dataを選択します。これによりRedshiftクエリエディターに移動します クエリエディターから、図3に示すようにCreate > Databaseを選択します 図3: クエリエディター画面からRedshiftデータベースを作成 “create database”フォームを使用してデータベースを作成します（このブログでは、bike_salesという名前を使用し、Redshift serverlessを使用しています） 各.csvファイルについて、bike_salesデータベースに対応するテーブルを作成します。テーブルを作成し、1つのステップでデータをロードするには、”Load Data”ボタンを選択することから始めます “Load from S3 Bucket”と”Browse S3″を選択して、適切なファイルを選択します データファイルにはYYYYMMDD形式を使用したDATE形式が含まれており、これは整数値として誤って自動検出される可能性があります。これを修正するには、図4に示すように”Data Conversion Parameters”ボタンを選択し、図5に示すようにデータ形式を変更します（空白値に対応するために”Accept any date”を選択する必要がある場合もあります） 図4: 日付形式のデータ変換パラメータの使用 図5: 日付形式変更オプション Nextを選択してLoad dataスクリーンに進みます “Load new table”を選択して、.csvヘッダー情報に基づいて新しいテーブルを作成します。図6に示すように、ドロップダウンから適切なワークグループ、データベース、スキーマを選択し、.csvファイル名に従ってテーブルに名前を付けます 図6: Redshiftへのテーブルロード データフィールドのデータ型を”DATE”データ型に変更します（データ型がない列がある場合は、VARCHARを選択できます） “Create Table”と”Load Data”を選択して、テーブルを作成しデータをロードします テーブル名を右クリックし、”Select table”オプションを選択することで、テーブルが正しく作成されたことを検証します。これにより、select * from “bike_sales”. “public”. “addresses”などのクエリが自動的に作成されます 他のテーブルについてもこのプロセスを繰り返します。完了すると、9つのファイルすべてがRedshiftにあり、Amazon Bedrockで使用できるようになります Amazon Bedrockに移動し、左パネルからKnowledge Basesを選択します 図7に示すように、Createを選択し、次にKnowledge Base with structured data storeを選択します 図7: 構造化データストアオプション付きAmazon Bedrock Knowledge Bases Knowledge Baseに名前を付け、データソースとしてAmazon Redshiftを選択します IAM権限については、”Create and use a new service role”を選択します Nextをクリックし、デプロイメントに一致するQuery Engineの詳細を選択します（この例ではredshift serverless） ストレージメタデータについては、作成したデータベース（この例ではbike_sales）を選択し、Nextを選択します サービスロールをメモし、”Create Knowledge Base”を選択します サービスロールに対応するRedshiftユーザーを追加 Redshiftコンソールに移動し、前のステップのサービスロールでユーザーを作成するために次のコマンドを使用します: create user "IAMR:AmazonBedrockExecutionRoleForKnowledgeBase<XXXXX>" with password disable; コマンド「grant select on all tables in schema “public” to IAMR:AmazonBedrockExecutionRoleForKnowledgeBase<XXXXX>」を使用してIAMサービスロールに権限を付与します ヒント:  IAMロールの設定に関する追加の詳細とベストプラクティスは こちらに文書化されています 。 Query Engineの同期 Amazon Bedrock Knowledge Baseに戻り、図8に示すように同期ボタンを使用します。同期には数分かかり、ステータスが「COMPLETE」と表示されます 図8: ナレッジベースの同期 基盤モデルを使用した自然言語によるデータ分析 これで、選択した基盤モデルでこのナレッジベースを使用する準備が整いました。図9に示すように、作成したKnowledge Baseを選択し、モデルを選択することから始めます。 図9: 選択した基盤モデルでRedshiftナレッジベースを使用 ヒント: 私たちのテストでは、「Amazon Nova」と「Anthropic Claude」Sonnetモデルがこの分析に適しています。 図10のスクリーンキャプチャは、基盤モデルからの質問と結果の例を示しています。レスポンスを生成するためにデータセットで使用された特定のクエリを表示するAmazon Bedrockの透明性の側面に注目してください。 図10 – データとのチャットの例 最適なユーザーエクスペリエンスのために複数のモデルをテストし、Redshiftナレッジベースをビジネスアプリケーションに統合できます。 サンプルコスト内訳 次の表は、US-EAST-1（バージニア北部）リージョンでデフォルトパラメータを使用して、独自のAWSアカウントでこのソリューションをデプロイするためのサンプルコスト内訳を提供します。 AWSサービス ディメンション コスト（USD） Amazon S3 CSVファイル用の月間10GBストレージ $0.26 Amazon Redshift Serverless 月間8時間/日実行時間で4RPU $366.24 構造化データ用Amazon Bedrock Knowledge Base 平均入出力トークンサイズ1000で1日8時間、1分あたり1リクエスト。 $259.20 コストを管理するために、 AWS Cost Explorer を通じて 予算 を作成することをお勧めします。詳細については、このブログで使用される各AWSサービスの価格ページを参照してください。 リソースのクリーンアップ このブログで言及されているサービスは、アカウント内のAWSリソースを消費するため、不要になったらさらなるコストを防ぐためにクリーンアップする必要があります。以下を削除してください： データステージング用に使用されたS3バケット内のファイルとS3バケット自体 構造化データをホストするために使用されたRedshiftデータベース 構造化データストア用Amazon Bedrock Knowledge Base IAMサービスロール（これらは課金対象ではありませんが、不要になった場合はクリーンアップする必要があります） 結論と次のステップ このブログでは、特定のユースケースを使用してSAPデータ（構造化および非構造化の両方）に生成AIを使用する方法について説明しましたが、概念は組織が持つ可能性のある他のユースケースにも転用できます。 Amazon BedrockとAmazon Qをすぐに開始するには、 AWS生成AIページ から始めてください。 Kiro CLI と Amazon Bedrock Knowledge Retrieval MCPサーバー を使用してコマンドラインでKnowledge Baseを直接クエリすることもできます。今日試してみてください！また、 SAP DevOps用Amazon Q の使用に関する最近公開されたビデオもご覧ください。 本ブログはAmazon Bedrockによる翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本ブログは 株式会社 Sumarch 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 Web サービスを運営する上で、セキュリティ対策とパフォーマンスの両立は重要な課題です。特に SaaS 事業者にとって、悪意ある攻撃からサービスを守りながら、正規ユーザーに快適な体験を提供することは、ビジネスの成否を左右する重要な要素となっています。 従来のセキュリティ対策では、攻撃トラフィックがアプリケーション層まで到達してしまい、サーバーリソースを消費してしまうという問題がありました。その結果、CPU 使用率が逼迫し、正規ユーザーのレスポンスタイムが悪化するといった事態も発生していました。また、スクレイピングボットや SQL インジェクション攻撃などの脅威に対して、十分な防御策を講じることが困難でした。 今回は不動産物件検索システムを運営する株式会社 Sumarch 様が、AWS WAF を段階的に導入し、数万件以上の攻撃をブロックしながら、システムのパフォーマンスを向上させた事例を紹介します。 株式会社 Sumarch 様の状況と課題 株式会社 Sumarch 様は、不動産物件検索システムである「 ハウスボカン 」を運用されており、以下のような課題に直面していました。 セキュリティ脅威の増大 突発的な DDoS 攻撃により、通常時の約 10 倍のトラフィックが発生していた スクレイピングボットによる大量のデータアクセスが発生し、管理する物件データに対する攻撃リスクがあった SQL インジェクション攻撃の試行が頻繁に観測され、データベースのセキュリティに懸念があった パフォーマンスの悪化 CPU 使用率が 100% に到達し、レスポンスタイムのスパイクする事象が発生していた 現在のレート制限設定では、画像ファイルなどの静的リソースも含めたリクエストカウントにより正常ユーザーもブロックされる事象が発生していた 攻撃パターンが不規則で複数サーバーから実行されるため、特定 IP アドレスでのブロックが困難な状況であった そこで AWS WAF を活用したセキュリティ強化により、これらの課題を解決することになりました。 ソリューション 株式会社 Sumarch 様は、AWS WAF を活用した多層防御アーキテクチャを採用し、以下のような構成を実現しました： 包括的なセキュリティルール構成 AWS Managed Rules for AWS WAF と独自ルールを組み合わせ、SQL インジェクション、ボット攻撃、DDoS 攻撃など多様な脅威から保護し、最新の脅威情報への自動対応と運用負荷の削減を実現 Bot Control マネージドルールグループの活用 機械学習を活用した高度なボット検出により、悪意あるスクレイピングボットを効果的にブロックしながら、SEO に重要な正規の検索エンジンボットは適切に許可 Amazon CloudWatch との統合 AWS WAF によるブロック数の推移、ルール別のブロック統計、地域別の攻撃パターンをリアルタイムで可視化し、迅速な対応と継続的な最適化を実現 段階的導入アプローチの重要性 AWS WAF の導入では、サービスへの影響を最小限に抑えるため、段階的なアプローチが重要です。本番環境での使用前にマネージドルールグループのテストとチューニングを行うことで、正規ユーザーへの影響を回避できます。 今回の事例では、基本的なセキュリティルールから開始し、Bot Control を監視モードで導入してボット検出精度を検証、CloudWatch メトリクスによる効果分析を経て、最終的にカスタムルールを追加することで改善を実現しました。 導入効果 AWS WAF の導入により、セキュリティとパフォーマンスの両面で改善を実現しました。 セキュリティ向上 2 ヶ月間で 92,000 件以上の攻撃をブロック スクレイピングボット、SQL インジェクション攻撃などを自動検出・防御 正規の検索エンジンボットは適切に許可し、SEO への影響を回避 パフォーマンス改善 CPU 使用率が 100% に到達する事象の解消 レスポンスタイムを最大 30% 改善 お客様の声 AWS WAF の段階的な導入により、セキュリティとパフォーマンスの両立を実現できました。Bot Control マネージドルールグループと独自ルールの組み合わせにより、CPU 使用率が 100% に達する課題が解消され、レスポンスタイムも改善しました。AWS Managed Rules for AWS WAF により、数万件件以上の攻撃を自動的にブロックしながら、正規ユーザーには快適な体験を提供できています。Amazon CloudWatch との統合で攻撃パターンの可視化とリアルタイム監視が可能になり、少人数のエンジニアチームでも効率的にセキュリティ対策を運用できる AWS WAF は、当社にとって必須のサービスです。 まとめ 株式会社 Sumarch 様の事例では、AWS WAF の段階的導入により、数万件以上の攻撃をブロックしながら、CPU 使用率の逼迫を解消し、レスポンスタイムを最大 30% 改善することに成功しました。 成功の要因は、段階的な導入アプローチによるサービスへの影響最小化、AWS Managed Rules for AWS WAF による最新脅威への自動対応、CloudWatch 統合による継続的な監視と最適化です。これにより、セキュリティ強化と運用負荷削減を同時に実現し、高い投資対効果を得られています。 本事例が、Web アプリケーションのセキュリティ強化をご検討中のお客様の参考になれば幸いです。AWS WAF を活用したセキュリティ対策にご興味をお持ちの方は、お気軽にお問い合わせください。 株式会社 Sumarch（左から）： 杉田 昌隆 様 佐々木 正男 様   Amazon Web Services Japan 合同会社： アカウントマネージャー 植木 輝（右端） ソリューションアーキテクト 森 瞭輔（左端） ソリューションアーキテクト 森

みなさん、明けましておめでとうございます！AWS ソリューションアーキテクトの野間です。　2026年最初の週刊生成AIです。 午年の2026年がスタートしました。馬が疾走するように、生成AI の世界も驚くべきスピードで進化しています。昨年は基盤モデルの飛躍的な性能向上やエンタープライズ活用の本格化など、大きな進展がありました。今年はその勢いがさらに加速し、現場で使える実践的なソリューションがどんどん生まれる年になりそうですね。技術の進歩速きこと駿馬の如し。これを見極め、適切に活用する智慧こそが求められる時節なり。（孔明風） 馬が千里の道を駆けるように、生成AIの可能性も限りなく広がっています。今年もこのブログが、皆さまの生成AI活用の道しるべとなれば嬉しいです。では今週も生成 AI with AWS界隈のニュースを見ていきましょう！（今号は年末年始のアップデートを含めてお届けします） さまざまなニュース AWS生成AI国内事例ブログ「人に依存しないCRMによりEC事業者のLTV最大化を実現 Amazon Bedrock AgentCoreを活用したAIオートパイロット型CRM開発事例」 EC 事業者の CRM 運用効率化についての生成 AI 活用事例です。株式会社ダイレクトマーケティングエージェンシー（DMA）が、EC 業界における CRM 運用の属人化、短期的施策への偏重、データ統合の複雑さといった構造的課題を解決するため、Amazon Bedrock AgentCore を中核に据えた AI オートパイロット型 CRM プラットフォーム「リピートMAX」を開発しました。このプラットフォームは、Amazon S3 および Amazon Redshift Serverless に蓄積された顧客行動データを基に AgentCore 上の AI エージェントが推論を行い、その結果をデータレイクへフィードバックする循環型アーキテクチャを採用しています。ターゲティングからクリエイティブ生成、売上予測、事後検証まで全ての CRM プロセスを対話形式で実行でき、大手百貨店 EC サイトでの導入により、リピート購入率が 125% 向上、離脱予兆顧客の CVR が 150% 以上改善、CRM 運用工数が約 1 時間まで効率化という具体的な成果を上げています。担当者のスキルに依存せず、顧客行動を文脈として理解し状況に応じて判断を変える高度な CRM 施策を自動化できる点が大きな特徴です。EC 事業者で CRM の効率化や LTV 向上に取り組まれている方、生成 AI を活用したマーケティング自動化に関心のある方は、ぜひこの実践的な事例をご覧ください。 AWS生成AI国内事例ブログ「株式会社サンブリッジ様のAWS生成AI事例「採用担当向け育成 AI コーチの構築により育成業務の一部を自動化し、年間 360 時間の工数削減と育成の質の高度化を実現」のご紹介」 採用業務の効率化に生成 AI を活用した事例です。株式会社サンブリッジが、年間 720 回にのぼる採用面接の半数以上に CEO が関与し、採用担当者の育成に大きな負荷がかかっていた課題を、Amazon Bedrock を活用した採用担当向け育成 AI コーチで解決しました。この AI コーチは、Bedrock の大規模言語モデルを活用した対話型チャットボットに CEO の判断ポイントや候補者との向き合い方を学習させ、Slack と連携してナレッジを継続的に更新できる仕組みと、RAG を利用したテスト機能で理解度を定量的に把握できる機能を備えています。特筆すべきは、AI コーディングアシスタントも活用することで、新人エンジニア 1 名がわずか 2 週間でシステム全体を構築できたという開発効率の高さです。導入後は、CEO の面接同席負担が半減し年間 360 時間の削減を実現したほか、年間 280 回の質問機会で CEO 視点の回答を提供できるようになり、採用担当者によるばらつきも解消されました。採用業務の属人化や育成負荷に課題を感じている企業、限られたリソースで高品質な採用活動を実現したい方は、ぜひこの具体的な実装手法と成果をご確認ください。 AWS生成AI国内事例ブログ「株式会社アド・ダイセンが生成 AI で実現した現場主導の業務効率化：非技術者による生成 AI 活用の実践」 このブログでは、ダイレクトメール事業を手がける株式会社アド・ダイセンが、 Generative AI Usecases (GenU) と Kiro を活用し、現場の非技術者が主導して業務効率化と DX を推進した事例を紹介しています。 議事録作成や画像判定、営業数字分析に加え、出荷日から逆算したスケジュール自動生成や配送シミュレーションなど、従来は数時間〜丸2日かかっていた事務・シミュレーション作業を数分〜数十秒に短縮し、人的ミス削減と品質向上を両立しながら「現場が自分たちでツールを作れる」体制を築ける点が大きな価値となっています。GenU のチャットとビルダーモード、Kiro の IDE＋Agentic AI によって、「このデータをこう処理したい」という自然言語の要件からコード生成・修正・実行まで対話的に進められるため、専門エンジニアに依存せず高度なツール開発が可能となり、成熟業界でもマニュアルワーカーからナレッジワーカーへのシフトとイノベーション文化の醸成を加速できる点が価値として示されています。エンジニアリソースの制約がある中で現場主導の DX を推進したい方、生成 AI で業務効率化を実現したい方は、ぜひこの実践的な成功事例をご確認ください。 AWS生成AI事例ブログ「smart EuropeがAmazon Bedrockでカスタマーサポート業務を変革した方法」 自動車業界のカスタマーサポート業務に革新をもたらした生成 AI 活用事例です。電気自動車メーカーの smart Europe は、製品の頻繁なリリースや OTA によるソフトウェアアップデートに伴うサポート問い合わせの急激な増加、解決時間の増大、サービス品質のばらつきといった課題に直面していました。これらの課題を解決するため、AWS と協力して smart.AI Case Handler という生成 AI ソリューションを開発し、わずか 4 人の開発者で 3 か月という短期間で実現しました。このソリューションは、Amazon Bedrock を中核に Amazon EventBridge、Amazon SQS、AWS Lambda、AWS Step Functions、Amazon Aurora などを組み合わせたサーバーレスアーキテクチャで構築され、2 つの補完的なワークフロー（問い合わせケースの自動タグ付けと AI によるインサイト生成）が連携して動作します。サポート担当者が Salesforce で問い合わせを開くと、AI が生成した概要、類似の過去事例、ナレッジベースの抜粋、顧客への回答案が即座に提示される仕組みです。実装にあたっては、担当者の待ち時間を解消する先回りした処理、Amazon SQS による API スロットリング対策、不要な更新を除外するフィルタリング機構といった工夫により、問い合わせ解決時間を 40% 短縮、ファーストコンタクトによる解決が 20% 増加、10,000 件超の問い合わせを処理し、2025 年の当初計画予算から 30% の節約を見込むという大きな成果を上げています。自動車業界でサポート業務の効率化や顧客満足度向上に取り組まれている方は、ぜひこの詳細な実装事例をご覧ください。 イベントレポート「第 45 回 医療情報学連合大会 (JCMI 45th) 出展レポート」 2025 年 11 月に開催された第 45 回医療情報学連合大会において、AWS は「生成 AI とヘルステックの融合が拓く、次世代の医療サービス」をテーマにスポンサードセッションと展示ブースを通じて医療 DX と生成 AI 活用の最新動向を共有しました。セッションでは、Amazon Bedrock を中核とした医療機関向けサービスが紹介され、日本国内に限定したクロスリージョン推論により医療情報ガイドラインへの準拠をサポートすることが示されました。特に注目されたのが Agentic AI で、従来の Chatbot や RAG を超えて、診療記録の作成や検査オーダーなど複雑なタスクを自律的に実行できる可能性が説明されました。株式会社メドレーからは、診察中の発話をリアルタイムで文字起こしし AI が自動要約する実証実験が紹介され、カルテ作成時間を約 11.3% 削減し、医師が「メモを取ることに集中しなくてよい」という安心感により患者との対話により集中できる環境を実現したことが報告されました。展示ブースでは Amazon Quick Suite のデモとともに、ANGEL Dojo という内製化支援プログラムの成果が紹介され、兵庫県立リハビリテーション中央病院では IT 知識ゼロの総務部の方が 90 日間でスケジュール作成時間を 80% 短縮し 60% の自動化を実現し、熊本中央病院では月 800 時間の文書作成時間削減を達成しました。生成 AI を活用することで、医療従事者は業務効率化を実現しながら、患者体験の向上にも貢献でき、適切な支援とパートナーシップがあれば IT 知識がなくても医療機関自らが生成 AI システムを構築できることが示されました。 イベントレポート「【開催報告】通信ネットワーク運用向け AI エージェントワークショップ開催しました！ ( 2025 年 11 月 27 日 )」 通信ネットワークの運用業務に AI エージェントを活用したい方に必見のワークショップ開催レポートです。2025 年 11 月 27 日に開催されたこのイベントには、96 名/ 14 社の通信業界の方々が参加し、AI エージェントの実践的な活用方法を学びました。ワークショップでは、NTTドコモから docomo MEC のオプションサービス MECダイレクトにおける Amazon Bedrock エージェントの活用事例が紹介され、監視措置業務の自律的実行により、アラート受信から分析、措置手順の提案までの自動化を実現した実績が共有されました。参加者は Strands Agents を使ったハンズオンで数行のコードで AI エージェントを構築する方法を体験し、通信ネットワーク運用 AI エージェント実践編では、Amazon Neptune をベースにした複数の専門エージェント（Orchestration、Observability、ナレッジ、チケット管理、RCA）が連携する本格的なシステムを実際に操作しました。アラーム分析から根本原因の特定、ServiceNow へのチケット起票まで、実務に即したシナリオを通じて AI エージェントの可能性を体感できる内容となっています。通信業界で Autonomous Network の実現を目指す方、ネットワーク運用の自動化・高度化に関心のある方は、ぜひこのブログで詳細な技術解説とハンズオンの様子をご確認ください。 ブログ記事「PartyRock の保護：AWS WAF を利用した Amazon Bedrock エンドポイントを保護する方法」 AWS WAF を利用して分散型サービス拒否 (DDoS) 攻撃や Wallet 拒否攻撃 (DoW) のような潜在的な脅威から PartyRock を保護した方法を解説します。生成 AI アプリケーションのセキュリティ設計や AWS WAF の実践的な活用方法を学びたい方は、ぜひこの詳細な実装事例をご覧ください。 ブログ記事「Amazon Bedrock は、新しい Mistral Large 3 モデルと Ministral 3 モデルを含む 18 のフルマネージドオープンウェイトモデルを追加します」 Amazon Bedrock が、Google、Moonshot AI、MiniMax AI、Mistral AI、NVIDIA、OpenAI、Qwen から 18 種類の新しいフルマネージドオープンウェイトモデルを追加し、合計で 100 近くのサーバーレスモデルを提供するようになりました。新たに追加された Mistral Large 3 は、ロングコンテキスト、マルチモーダル、エージェントワークフローに最適化されており、Ministral 3 シリーズ（3B、8B、14B）はエッジデプロイ向けに最適化された軽量モデルとして、画像キャプション、リアルタイム翻訳、ローカル AI アシスタントなどに活用できます。 ブログ記事「2D から 3D へ: Amazon SageMaker AI を使用したスケーラブルなヒューマンメッシュリカバリパイプラインの構築」 コンピュータグラフィックスとアニメーションの分野で注目される、動画データから現実的な 3D ヒューマンアニメーションを生成する技術が詳しく解説されています。従来は専用ハードウェアと複雑なソフトウェアパイプラインが必要だったヒューマンメッシュリカバリ（HMR）を、Amazon SageMaker AI を中心とした AWS サーバーレスアーキテクチャでスケーラブルに実現する方法が紹介されています。中核となる ScoreHMR は、従来の最適化技術とは異なり拡散モデルを使用して入力画像から人体パラメータを再構築し、遮蔽された状況や困難な条件下でも高精度な結果を実現します。パイプラインは AWS Lambda、Amazon S3、Amazon SQS、Amazon SageMaker AI の非同期エンドポイントを組み合わせて設計され、リクエストがない時はインスタンス数をゼロにスケールしてコストを節約しながら、トラフィックに応じて自動的にスケールする仕組みになっています。出力される 3D メッシュ、ベクトルキーポイントデータ、カメラポーズ情報は任意の 3D アプリケーションで利用でき、没入型フィットネス体験、映画制作、デジタルコンテンツ制作など幅広い用途に活用できます。動画からの 3D ヒューマンアニメーション生成に興味がある方、コンテンツ制作の自動化を検討されている方は、ぜひこの技術的な実装詳細をご確認ください。 ブログ記事「AWS AI League: モデルカスタマイゼーションとエージェント対決」 AWS AI League は、Agentic AI とモデルカスタマイゼーションの分野でイノベーションを促進する、企業向けのコンペティションプログラムです。2026 年チャンピオンシップでは、Amazon Bedrock AgentCore を使用してインテリジェントエージェントを構築する「エージェンティック AI チャレンジ」と、SageMaker Studio の最新ファインチューニングレシピを活用して特定ユースケース向けにモデルをカスタマイズする「モデルカスタマイゼーションチャレンジ」という 2 つの新しいチャレンジが導入されました。この記事では、AWS AI League プログラムを使用して AI コンペティションを開催する方法について説明します。AI スキルを実践的に磨きたい方、社内で AI コンペティションを開催したい企業は、ぜひこのプログラムの詳細をご確認ください。 ブログ記事「回復力のあるサプライチェーンの構築: Amazon Bedrock を活用した小売・消費財向けマルチエージェント AI アーキテクチャー」 小売・消費財企業が直面する港湾閉鎖や気象現象などのサプライチェーン混乱に対し、Amazon Bedrock AgentCore のマルチエージェント協調機能を活用したリアルタイム対応システムを紹介しています。このアーキテクチャは、スーパーバイザーエージェントが混乱を分析してタスクを委任し、物流最適化エージェント、在庫エージェント、プロモーションリスクエージェント、出荷追跡エージェントといった専門エージェントが協調して作業することで、従来は手動で数時間かかっていた分析を数分以内に完了させます。生成 AI を活用することで、サプライチェーンの混乱を危機から管理可能なイベントに変換し、複数の同時混乱を追加人員なしで処理できるため、小売・消費財企業は市場シェアを守りながらビジネスの継続性を確保できます。 ブログ記事「AWS IoT Greengrass と Strands Agents を使用した Small Language Model の大規模デプロイ」 製造業では、セキュリティとパフォーマンスの基準を維持しながらリアルタイムの運用データに応答するインテリジェントな意思決定システムの実装が課題となっており、Small Language Models (SLM) が解決策として注目されています。SLM は約 30 億から 150 億のパラメータを持ち、軽量でありながら、コンテキストを理解した洞察を提供できるため、リソースが限られた工場環境に最適です。このブログでは、AWS IoT Greengrass を使用して SLM を Greengrass コンポーネントとして OPC-UA ゲートウェイに直接デプロイし、Strands Agents がローカルエージェント機能を提供する実装方法が詳しく解説されています。エッジで AI エージェントを実装したい方、IoT デバイスに生成 AI を組み込みたい方は、ぜひこの実践的な実装ガイドをご確認ください。 ブログ記事「Amazon Bedrock は ISMAP の言明対象であることについての考え方」 2026 年 1 月 9 日、ISMAP ポータルサイトに重要な更新があり、生成 AI 開発基盤が ISMAP に登録されている場合、その上で動作する個々の生成 AI モデルは必ずしも ISMAP に個別登録されている必要はないという見解が示されました。ISMAP は政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録することにより、政府のクラウドサービス調達におけるセキュリティ水準の確保を図る制度で、政府情報システムにおいてクラウドサービスを利用する際には原則として ISMAP に登録されたサービスを選定することが求められています。Amazon Bedrock は生成 AI 開発基盤として ISMAP の言明対象範囲に含まれており、生成 AI モデルが AWS の内部環境に持ち込まれているため、お客様のデータが生成 AI モデル開発事業者に提供されることはなく、モデル学習にも使用されません。Guardrails for Amazon Bedrock による有害コンテンツのフィルタリング、モデル評価機能、AWS CloudTrail によるアクセスログ記録など、生成 AI 特有のリスクへの対応機能も提供されています。政府機関や公共セクターで、セキュリティ要件を満たしながら生成 AI を活用したい方は、ぜひこの制度更新の解説をご確認ください。 ブログ記事「Kiro のマルチルートワークスペース：1 つのプロジェクト内だけでなく、複数のプロジェクトにまたがって作業する」 このブログでは、 Kiro の新しいマルチルートワークスペース機能により、複数のプロジェクトを単一の IDE ウィンドウで効率的に管理する方法をお伝えします。共有ライブラリとメインアプリケーション、複数のマイクロサービス、モノレポのパッケージなど、関連するプロジェクトを同時に編集する際の課題を解決し、各ルートが独立性を保ちながら統合された開発環境を提供する仕組みと、その設定方法や実際の活用例を詳しく説明します。 ブログ記事「プロパティベーステストが見つけた、私が決して発見できなかったセキュリティバグ」 このブログでは、 Kiro の仕様駆動開発ワークフローを使用したチャットアプリケーション開発において、プロパティベーステスト（PBT）が従来のテスト手法では発見困難なセキュリティバグをどのように発見したかをお伝えします。75 回目のテスト反復で proto というプロバイダー名が JavaScript プロトタイプの誤った処理を露呈し、ランダム生成による体系的な入力空間の探索が、手動コードレビューや単体テストでは見逃されるエッジケースを効果的に発見できることを実例とともに紹介します。 サービスアップデート AWS Neuron SDK 2.27.0 の発表 AWS Neuron SDK 2.27.0 がリリースされ、Trainium3 UltraServer のサポートとオープンソースコンポーネントの拡張が追加されました。今回のアップデートでは、Neuron Explorer ツールスイートや MLIR ベースの Enhanced NKI（プライベートベータ）、最適化されたカーネルを集めた NKI ライブラリに加え、TorchNeuron によるネイティブ PyTorch サポート（プライベートベータ）、Kubernetes ネイティブなリソース管理を実現する Neuron DRA（プライベートベータ）が導入されています。SDK の新しいバージョンは、Inferentia インスタンスと Trainium インスタンスをサポートしているすべての AWS リージョンで利用できます。 NVIDIA Nemotron 3 Nano が Amazon Bedrock で利用可能に Amazon Bedrock で NVIDIA Nemotron 3 Nano 30B A3B モデルがサポートされました。このモデルは、効率的な Mixture-of-Experts (MoE) アーキテクチャを採用し、高い推論パフォーマンス、ネイティブツール呼び出しのサポート、256k トークンという拡張されたコンテキストウィンドウを備えています。また、Amazon Bedrock の新しい分散型推論エンジンである Project Mantle 上で動作し、OpenAI API 仕様との互換性も提供されるため、既存のコードやツールをそのまま活用できます。NVIDIA Nemotron 3 Nano は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (ムンバイ)、南米 (サンパウロ)、欧州 (ロンドン)、欧州 (ミラノ) の AWS リージョンの Amazon Bedrock で利用でき、Amazon Bedrock の統合 API サービスエンドポイントと OpenAI API 互換サービスエンドポイントの両方をサポートしています。 Amazon Quick adds third-party AI agents and expands built-in actions library Amazon Quick Suite がサードパーティ製 AI エージェントとの統合を拡張し、ビルトインアクションライブラリを強化しました。今回のアップデートにより、Box、Canva、PagerDuty の専門的なエージェントを呼び出せるようになり、例えば PagerDuty からインシデントのインサイトを取得し、Canva でプレゼンテーションを生成し、Box に保存されているドキュメントをクエリするといった作業を、すべて Quick Suite から直接実行できます。さらに GitHub、Notion、HubSpot、Intercom、Monday.com、Linear、Hugging Face などの統合も追加され、GitHub Issue の作成、Notion での会議メモの要約、CRM 管理などのタスクが可能になりました。これにより、異なるアプリケーション間を切り替える手間が軽減され、生成 AI を活用したワークフローを単一のインターフェースから効率的に実行できるようになります。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。今年はコロコロを続けたいと思います。

みなさん、あけましておめでとうございます。ソリューションアーキテクトの杉山です。 年末年始はどのように過ごされましたか。私は「あなたのチームは、機能してますか？」という本を読み、チームワークの本質について考えさせられました。本に書いている文章そのままではないのですが、良いチームとは「調和を保つチーム」ではなく、「建設的な衝突を恐れないチーム」である、という点が印象に残っています。最高の成果を出すためには、時に激しく議論することが必要となる。また、激しく議論したとしても互いに信頼しあう「心理的安全性」が重要であるという内容も含まれており、とても示唆に富む内容でした。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年1月5日週の主要なアップデート 1/5(月) EC2 Capacity Manager に Spot 中断メトリクスが追加されました EC2 Capacity Manager に Spot インスタンスの中断メトリクスが新たに追加されました。今回のアップデートにより「Spot Usage Total Count (実行された Spot インスタンスの数)」「Spot Total Interruptions (中断された数)」「Spot Interruption Rate (中断された割合)」の 3 つの新しいメトリクスが利用可能になりました。Spot インスタンス利用状況や中断率をリージョンやアベイラビリティーゾーン別に分析でき、データに基づいた Spot インスタンスの利用戦略を立てやすくなります。全ての商用リージョンで追加料金なしで利用できます。詳細は こちらのドキュメントをご参照ください。 1/6(火) AWS Config が 21 の新しいリソースタイプをサポート AWS Config は、Amazon EC2、Amazon SageMaker、Amazon S3 Tables を含む主要サービスにわたって 21 の追加 AWS リソースタイプをサポートするようになりました。EC2 のサブネット CIDR ブロック、CloudFront の Key Value Store、Route 53 の DNSSEC などのリソースタイプが含まれています。これにより AWS 環境全体でより幅広いリソースの設定変更を自動追跡できるようになり、コンプライアンス監査やセキュリティチェックの範囲が拡張されます。 Amazon MQ が RabbitMQ ブローカーの HTTP ベース認証をサポート開始 Amazon MQ で RabbitMQ ブローカーが HTTP ベースの認証をサポートしました。m7g インスタンス で RabbitMQ 4.2 以上を稼働している場合に利用できます。外部の HTTP サーバーを使った認証・認可が可能になります。これまでは内部の認証機能に限定されていましたが、既存の認証基盤や LDAP サーバーとの連携が容易になり、より柔軟なセキュリティ設定を実現できます。設定ファイルの編集で簡単に導入可能です。詳細は こちらのドキュメントをご参照ください。 Amazon ECS が AWS Fargate と ECS マネージドインスタンスで tmpfs マウントをサポート Amazon ECS で tmpfs マウント機能が Fargate と ECS Managed Instances でも利用できるようになりました。tmpfs はメモリベースの一時ファイルシステムで、従来のストレージよりも高速なアクセスが可能です。キャッシュや一時ファイル、短期間の認証情報保存に最適で、タスク終了時にデータが自動削除されるためセキュリティ面で向上するメリットがあります。詳細は こちらのドキュメントをご参照ください。 1/7(水) Amazon EC2 C8i および C8i-flex インスタンスが追加の AWS リージョンで利用可能になりました Amazon EC2 の新しいインスタンスタイプ C8i と C8i-flex が東京、ソウル、ムンバイリージョンで利用開始されました。Intel Xeon 6 プロセッサを搭載し、前世代の C7i と比較して 20% の性能向上を実現します。Web アプリケーションでは 60% 高速化、AI 推論では 40% 高速化など、大幅なパフォーマンス向上が期待できます。C8i-flex は Web サーバーやデータベース向け、C8i はメモリ集約型ワークロード向けに最適化されています。詳細は こちらの Blog 記事をご参照ください。 Amazon Managed Workflows for Apache Airflow での Apache Airflow 2.11 サポートの発表 Amazon MWAA (Managed Workflows for Apache Airflow) で Apache Airflow 2.11 がサポート開始されました。MWAA は、データパイプライン構築をクラウドで簡単に管理できるサービスです。今回のアップデートでは Python 3.12 対応や、トリガーベーススケジューリングなど Apache Airflow 3 への移行準備に役立つ機能が追加されています。AWS Management Console から数クリックで新環境を作成でき、データ処理ワークフローの運用がより効率的になります。詳細は こちらのドキュメントをご参照ください。 Client VPN のオンボーディングを Quickstart セットアップで簡素化 AWS Client VPN で新しい Quickstart セットアップが利用できるようになりました。これまで Client VPN エンドポイントの作成には多くの設定ステップが必要でしたが、Quickstart では IPv4 CIDR、サーバー証明書 ARN、サブネット選択の 3 つの入力だけで簡単にセットアップできます。開発チームがテスト環境への VPC リモートアクセスを素早く構築したい場合に有効です。VPC 作成時には自動的に Quickstart ワークフローが提案され、作成完了後すぐにクライアント設定ファイルをダウンロードして接続できます。詳細は こちらのドキュメントをご参照ください。 1/8(木) AWS Lambda が .NET 10 のサポートを追加 AWS Lambda で .NET 10 がサポート開始されました。これにより開発者は最新の .NET 機能を使ったサーバーレスアプリケーションを構築できるようになります。.NET 10 は長期サポート版 (LTS) のため、2028 年 11 月までの長期間サポートが提供されています。マネージドランタイムとコンテナ両方で使用でき、自動アップデートも適用されます。全リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Quick がサードパーティ AI エージェントを追加し、組み込みアクションライブラリを拡張 Amazon Quick が Box や Canva、PagerDuty などのサードパーティ AI エージェントとの連携機能を拡張しました。従来は複数のアプリケーション間を切り替える必要がありましたが、今回のアップデートにより Quick の単一インターフェースから様々なツールを操作できるようになりました。例えば PagerDuty でインシデント分析を行い、その結果を基に Canva でプレゼン資料を作成し、Box のドキュメントを検索するといった一連の作業を Quick 内で完結できます。詳細は こちらのドキュメントをご参照ください。 Amazon MQ が RabbitMQ ブローカーで相互 TLS を使用した証明書ベース認証をサポート Amazon MQ の RabbitMQ ブローカーで、mTLS を利用した X.509 クライアント証明書による認証機能が追加されました。従来のユーザー名とパスワード認証に加えて、より安全な証明書ベース認証が利用可能になり、企業システムでよく使われる PKI 基盤との連携が簡単になります。RabbitMQ 4.2 以上と M7g インスタンスで利用でき、設定ファイルを編集するだけで有効化できます。詳細は こちらのドキュメントをご参照ください。 1/9(金) Amazon Lightsail でより大きなマネージドデータベースバンドルの提供を発表 Amazon Lightsail でより大きなマネージドデータベースバンドルが利用できるようになりました。最大 8 vCPU、32GB メモリ、960GB SSD ストレージという高性能な構成で、MySQL と PostgreSQL データベースを構築できます。従来のバンドルでは処理しきれなかった大規模なデータ処理や多数の同時接続が必要な本格的なプロダクションワークロードに対応可能です。e コマースサイトや CMS、BI アプリケーション、SaaS 製品などの運用に最適で、全リージョンで利用開始できます。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

本ブログは 2025 年 12 月 17 日に公開された AWS Blog “ Security Hub CSPM automation rule migration to Security Hub ” を翻訳したものです。 AWS Security Hub の新しいバージョンの一般提供が開始されました。このバージョンでは、 Amazon Web Services (AWS) アカウント全体のセキュリティアラートを集約、相関付け、コンテキスト化する新機能が追加されています。旧バージョンは AWS Security Hub CSPM として引き続き利用可能で、クラウドセキュリティポスチャ管理と検出結果の集約に特化した独立したサービスとして提供されます。 両方のサービスで利用できる機能の 1 つが 自動化ルール です。Security Hub と Security Hub CSPM のどちらでも、自動化ルールを使用して、定義した条件が満たされたときに検出結果のフィールドを自動的に更新できます。Security Hub では、自動化ルールを使用して 検出結果をサードパーティプラットフォームに送信し、運用対応を行う こともできます。既存の Security Hub CSPM ユーザーの多くは、本番リソースに影響する検出結果の重要度を上げたり、修復ワークフローを支援するコメントを追加したりするタスクに自動化ルールを使用しています。両方のサービスで同様の自動化ルール機能が提供されていますが、ルールは 2 つのサービス間で同期されません。新しい Security Hub の導入を検討している既存の Security Hub CSPM のお客様は、すでに構築した自動化ルールの移行に関心があるかもしれません。これにより、検出結果の確認と自動化ルールの処理を同じ場所で行えるようになります。本ブログの公開時点 (2025 年 12 月 17 日) では、この機能は Security Hub エッセンシャルプランの料金に含まれています。最新の料金の詳細については、 Security Hub の料金ページ を参照してください。 この記事では、Security Hub CSPM から Security Hub に自動化ルールを自動的に移行するソリューションを紹介します。これにより、新しい Security Hub の機能を活用しながら、セキュリティ自動化ワークフローを維持できます。現在自動化ルールを使用しておらず、これから始めたい場合は、 Security Hub の自動化ルール を参照してください。 自動化ルール移行の課題 Security Hub CSPM は、検出結果のスキーマとして AWS Security Finding Format (ASFF) を使用しています。このスキーマは、検出結果が生成されたときに自動化ルールがどのように適用されるかの基盤となっています。自動化ルールは、まず 1 つ以上の条件を定義し、次に指定した条件が満たされたときに適用される 1 つ以上のアクションを選択することで作成します。各条件では、ASFF フィールド、演算子 ( equals や contains など)、および値を指定します。アクションは 1 つ以上の ASFF フィールドを更新します。 新バージョンの Security Hub は、 Open Cybersecurity Schema Framework (OCSF) を使用しています。これは、AWS とサイバーセキュリティ業界のパートナーがサポートする、広く採用されているオープンソーススキーマです。Security Hub の自動化ルールは、構造的には Security Hub CSPM のルールと同じように機能しますが、基盤となるスキーマの変更により、既存の自動化ルールには変換が必要です。 この記事で紹介するソリューションは、Security Hub CSPM の自動化ルールを自動的に検出し、OCSF スキーマに変換し、新バージョンの Security Hub を実行している AWS アカウントにデプロイするための AWS CloudFormation テンプレートを作成します。ASFF と OCSF スキーマには本質的な違いがあるため、一部のルールは自動的に移行できず、移行後に手動でのレビューが必要になる場合があります。 以下の表は、条件としてサポートされている ASFF フィールドと、対応する OCSF フィールドの現在のマッピングを示しています。これらのマッピングは、将来のサービスリリースで変更される可能性があります。 N/A と記載されているフィールドは移行できないため、自動化ルールを移行する際には特別な考慮が必要です。これらは新しい Security Hub で再設計する必要があります。この記事で紹介するソリューションは、OCSF フィールドにマッピングされない ASFF 条件が 1 つ以上あるルールの移行をスキップするように設計されていますが、レビュー用のレポートでそれらのルールを特定します。 ASFF のルール条件 対応する OCSF フィールド AwsAccountId cloud.account.uid AwsAccountName cloud.account.name CompanyName metadata.product.vendor_name ComplianceAssociatedStandardsId compliance.standards ComplianceSecurityControlId compliance.control ComplianceStatus compliance.status Confidence confidence_score CreatedAt finding_info.created_time Criticality N/A Description finding_info.desc FirstObservedAt finding_info.first_seen_time GeneratorId N/A Id finding_info.uid LastObservedAt finding_info.last_seen_time NoteText comment NoteUpdatedAt N/A NoteUpdatedBy N/A ProductArn metadata.product.uid ProductName metadata.product.name RecordState activity_name RelatedFindingsId N/A RelatedFindingsProductArn N/A ResourceApplicationArn N/A ResourceApplicationName N/A ResourceDetailsOther N/A ResourceId resources[x].uid ResourcePartition resources[x].cloud_partition ResourceRegion resources[x].region ResourceTags resources[x].tags ResourceType resources[x].type SeverityLabel vendor_attributes.severity SourceUrl finding_info.src_url Title finding_info.title Type finding_info.types UpdatedAt finding_info.modified_time UserDefinedFields N/A VerificationState N/A WorkflowStatus status 以下の表は、アクションとしてサポートされている ASFF フィールドと、対応する OCSF フィールドを示しています。一部のアクションフィールドは OCSF では利用できない点にご注意ください。 ASFF のルールアクションフィールド 対応する OCSF フィールド Confidence N/A Criticality N/A Note Comment RelatedFindings N/A Severity Severity Types N/A UserDefinedFields N/A VerificationState N/A Workflow Status Status OCSF に対応するフィールドがないアクションを含む Security Hub CSPM の自動化ルールについては、このソリューションはルールを移行しますが、サポートされているアクションのみを含めます。これらのルールは、ルールの説明と移行レポートで「partially migrated」(部分的に移行) と表示されます。この情報を活用して、ルールを有効にする前にレビューおよび変更し、新しい自動化ルールが期待どおりに動作することを確認してください。 ソリューションの概要 このソリューションは、Security Hub CSPM から新しい Security Hub への自動化ルールの移行を支援する Python スクリプトのセットを提供します。移行プロセスは以下のように動作します。 移行の開始 : このソリューションは、3 つのサブスクリプトを起動し、適切な入力を渡すオーケストレーションスクリプトを提供します 検出 : このソリューションは、Security Hub CSPM 環境をスキャンして、指定した AWS リージョン全体の既存の自動化ルールを特定して収集します 分析 : 各ルールは、ASFF から OCSF へのフィールドマッピングの互換性に基づいて、完全に移行できるか、部分的に移行できるか、または手動での対応が必要かを判断するために評価されます 変換 : 互換性のあるルールは、事前定義されたフィールドマッピングを使用して、ASFF スキーマから OCSF スキーマに自動的に変換されます テンプレートの作成 : このソリューションは、変換されたルールを含む CloudFormation テンプレートを生成し、元のルールの順序とリージョンのコンテキストを維持します デプロイ : 生成されたテンプレートをレビューし、デプロイして Security Hub に移行されたルールを作成します。ルールはデフォルトで無効状態で作成されます ルールの検証と有効化 : Security Hub の AWS マネジメントコンソールで移行された各ルールをレビューし、条件、アクション、および該当する場合は現在一致する検出結果のプレビューを確認します。ルールが個別に、またシーケンスとして意図したとおりに動作することを確認した後、ルールを有効にして自動化ワークフローを再開します 図 1: スクリプトと AWS との連携を示すアーキテクチャ図 図 1 に示すソリューションは、自動化ルールを移行するために連携して動作する 4 つの Python スクリプトで構成されています。 Orchestrator : 検出、変換、生成をレポートとログ記録とともに調整します Rule discovery : 指定したリージョン全体で Security Hub CSPM から既存の自動化ルールを特定して抽出します Schema transformation : 前述のフィールドマッピングを使用して、ルールを ASFF から OCSF 形式に変換します Template generation : 移行されたルールをデプロイするために使用できる CloudFormation テンプレートを作成します これらのスクリプトは、 AWS Command Line Interface (AWS CLI) を使用して設定された認証情報で、既存の Security Hub 自動化ルールを検出します。AWS CLI を使用した認証情報の設定方法の詳細については、 AWS CLI のセットアップ を参照してください。 前提条件 ソリューションを実行する前に、以下のコンポーネントと権限が整っていることを確認してください。 必要なソフトウェア: AWS CLI (最新バージョン) Python 3.12 以降 Python パッケージ: boto3 (最新バージョン) pyyaml (最新バージョン) 必要な権限: ルールの検出と変換に必要な権限: securityhub:ListAutomationRules securityhub:BatchGetAutomationRules securityhub:GetFindingAggregator securityhub:DescribeHub securityhub:ListAutomationRulesV2 テンプレートのデプロイに必要な権限: cloudformation:CreateStack cloudformation:UpdateStack cloudformation:DescribeStacks cloudformation:CreateChangeSet cloudformation:DescribeChangeSet cloudformation:ExecuteChangeSet cloudformation:GetTemplateSummary securityhub:CreateAutomationRuleV2 securityhub:UpdateAutomationRuleV2 securityhub:DeleteAutomationRuleV2 securityhub:GetAutomationRuleV2 securityhub:TagResource securityhub:ListTagsForResource AWS アカウントの設定 Security Hub は、 AWS Organizations と併用する場合、委任管理者アカウントモデルをサポートしています。委任管理者アカウントは、組織のメンバーアカウント全体のセキュリティ検出結果とサービス設定を一元管理します。自動化ルールは、ホームリージョンおよびリンクされていないリージョンの委任管理者アカウントで作成する必要があります。メンバーアカウントは独自の自動化ルールを作成できません。 AWS では、一貫したセキュリティ管理を維持するために、Security Hub CSPM と Security Hub の両方で同じアカウントを委任管理者として使用することを推奨しています。移行ソリューションを実行する前に、この委任管理者アカウントの認証情報を使用して AWS CLI を設定してください (詳細については、 AWS CLI のセットアップ を参照してください)。 このソリューションは主に委任管理者のデプロイ向けに設計されていますが、単一アカウントの Security Hub 実装もサポートしています。 移行の主要な概念 Security Hub CSPM から Security Hub への自動化ルールの移行を進める前に、ルールの移行とデプロイに影響するいくつかの重要な概念を理解しておくことが大切です。これらの概念は移行プロセスとルールの動作に影響するため、理解しておくことで移行戦略の計画と結果の検証を効果的に行えます。 デフォルトのルール状態 デフォルトでは、移行されたルールは DISABLED 状態で作成されます。つまり、検出結果が生成されてもアクションは適用されません。このソリューションでは、オプションでルールを ENABLED 状態で作成することもできますが、これは推奨されません。代わりに、ルールを DISABLED 状態で作成し、各ルールをレビューして一致する検出結果をプレビューしてから、準備ができたらルールを ENABLED 状態に変更してください。 サポートされていないフィールド 移行レポートには、新しい Security Hub でサポートされていない Security Hub CSPM の条件が 1 つ以上含まれているために移行できないルールの詳細が記載されます。これらのケースは、ASFF と OCSF スキーマの違いによって発生します。同等の動作を自動的に再現できないため、これらのルールには特別な注意が必要です。特に、優先順位に依存する Security Hub CSPM ルールがある場合は重要です。 サポートされていないアクションがあるルールでも、少なくとも 1 つのアクションがサポートされていれば移行されます。部分的にサポートされているアクションを持つルールは、移行レポートと新しい自動化ルールの説明でフラグが付けられるため、レビューが必要です。 ホームリージョンとリンクされたリージョン Security Hub CSPM と Security Hub はどちらも、 リンクされた リージョンからの検出結果を集約する ホーム リージョンをサポートしています。ただし、自動化ルールの動作は異なります。Security Hub CSPM の自動化ルールはリージョン単位で動作し、ルールが作成されたリージョンで生成された検出結果にのみ影響します。ホームリージョンを使用している場合でも、Security Hub CSPM の自動化ルールは、ホームリージョンでリンクされたリージョンから集約された検出結果には適用されません。一方、Security Hub は、ホームリージョンで定義してすべてのリンクされたリージョンに適用される自動化ルールをサポートしており、リンクされたリージョンでの自動化ルールの作成はサポートしていません。ただし、Security Hub では、リンクされていないリージョンは独自の自動化ルールを持つことができ、そのリージョンで生成された検出結果にのみ影響します。リンクされていないリージョンには、自動化ルールを個別に適用する必要があります。 このソリューションは、これらの違いに対応するために 2 つのデプロイモードをサポートしています。最初のモードは ホームリージョン モードと呼ばれ、ホームリージョンが有効になっている Security Hub のデプロイに使用します。このモードでは、指定したリージョンから Security Hub CSPM の自動化ルールを特定し、ルールの元のリージョンを考慮した追加の条件を付けて再作成します。その後、ホームリージョンにデプロイできる 1 つの CloudFormation テンプレートが生成されます。元のリージョンの条件が追加されているため、自動化ルールは意図したとおりに動作します。 2 番目のモードは リージョン別 モードと呼ばれます。このモードは、現在ホームリージョンを使用していないユーザー向けです。このモードでも、指定したリージョンの自動化ルールを検出しますが、各リージョンに対して個別の CloudFormation テンプレートを生成します。生成されたテンプレートは、対応するリージョンの委任管理者アカウントに 1 つずつデプロイできます。このモードでは、自動化ルールに追加の条件は追加されません。 Security Hub でホームリージョンを使用し、一部のリージョンをリンクしているが、すべてではない場合もあります。この場合は、ホームリージョンとすべてのリンクされたリージョンに対してホームリージョンモードを実行します。次に、すべてのリンクされていないリージョンに対してリージョン別モードでソリューションを再実行します。 ルールの順序 Security Hub CSPM と Security Hub の自動化ルールには、どちらも評価される順序があります。これは、異なる自動化ルールが同じ検出結果に適用されたり、同じフィールドに対してアクションを実行したりする可能性がある特定の状況で重要になることがあります。このソリューションは、自動化ルールの元の順序を維持します。 既存の Security Hub 自動化ルールがある場合、このソリューションは既存のルールの後から新しい自動化ルールを作成します。たとえば、3 つの Security Hub 自動化ルールがあり、10 個の新しいルールを移行する場合、ソリューションは新しいルールに 4 から 13 の順序を割り当てます。 ホームリージョンモードを使用する場合、各リージョンの自動化ルールの順序は維持され、最終的な順序でまとめてグループ化されます。たとえば、3 つの異なるリージョンに 3 つの Security Hub 自動化ルールを持つユーザーがルールを移行する場合、ルールは順番に移行されます。ソリューションは、まずリージョン 1 のすべてのルールを元の順序で移行し、次にリージョン 2 のすべてのルールを元の順序で移行し、最後にリージョン 3 のすべてのルールを元の順序で移行します。 移行のデプロイと検証 前提条件が整い、基本的な概念を理解したら、移行をデプロイして検証する準備ができました。 移行をデプロイする手順 1. AWS samples GitHub リポジトリ から Security Hub 自動化ルール移行ツールをクローンします。 git clone https://github.com/aws-samples/sample-SecurityHub-Automation-Rule-Migration.git 2. README ファイルの手順に従ってスクリプトを実行します。README ファイルには最新の実装手順が記載されています。これにより、新しい Security Hub 自動化ルールを作成する CloudFormation テンプレートが生成されます。AWS CLI またはコンソールを使用して CloudFormation テンプレートをデプロイします。詳細については、 CloudFormation コンソールからスタックを作成する または README ファイルを参照してください。 デプロイが完了したら、Security Hub コンソールを使用して移行された自動化ルールを確認できます。ルールはデフォルトで DISABLED 状態で作成されることに注意してください。各ルールの条件とアクションを慎重に確認し、意図した自動化ワークフローと一致していることを確認してください。コンソールで、各自動化ルールに一致する既存の検出結果をプレビューすることもできます。 移行されたルールを確認して検証するには: 1. Security Hub コンソールに移動し、ナビゲーションペインから [Automations] (オートメーション) を選択します。 図 2: Security Hub の Automations ページ 2. ルールを選択し、ページ上部の [Edit] (編集) を選択します。 図 3: Security Hub 自動化ルールの詳細 3. [Preview matching findings] (一致する検出結果をプレビューしてください) を選択します。自動化ルールが期待どおりに動作していても、検出結果が返されない場合があります。これは、現在 Security Hub にルールの条件に一致する検出結果がないことを意味します。この場合でも、ルールの条件を確認できます。 図 4: Security Hub の自動化ルール編集ページ 4. ルールの設定を検証した後、ルール編集ページからコンソールを通じてルールを有効にできます。CloudFormation スタックを更新することもできます。自動化ルールの条件やアクションを変更する必要がなかった場合は、オプションの —create-enabled フラグを付けてスクリプトを再実行し、すべてのルールが有効な状態の CloudFormation テンプレートを再生成して、既存のスタックの更新としてデプロイできます。 partially migrated actions (部分的に移行されたアクション) となっているルールに注意してください。これは各ルールの [Description] に記載されています。Security Hub CSPM の元のルールの 1 つ以上のアクションが Security Hub でサポートされておらず、ルールが意図したとおりに動作しない可能性があることを意味します。このソリューションは、どのルールが部分的に移行されたか、元のルールのどのアクションが移行できなかったかを示す移行レポートも生成します。これらのルールは期待どおりに動作しない可能性があり、変更または再作成が必要な場合があるため、慎重に確認してください。 図 5: 部分的に移行された自動化ルールの説明を確認する まとめ 新しい AWS Security Hub は、セキュリティ検出結果の集約、相関付け、コンテキスト化のための強化された機能を提供します。ASFF から OCSF へのスキーマ変更により、相互運用性と統合オプションが向上しますが、既存の自動化ルールの移行が必要になります。この記事で紹介したソリューションは、既存のルールを検出し、新しいスキーマに変換し、ルールの順序とリージョンのコンテキストを維持する CloudFormation テンプレートを実行することで、この移行プロセスを自動化します。 自動化ルールを移行した後は、まず移行レポートを確認して、完全に移行されなかったルールを特定してください。部分的に移行されたとマークされたルールには特に注意が必要です。これらは元のバージョンとは異なる動作をする可能性があります。各ルールを無効状態でテストし、特に同じフィールドに対して操作するルールについては、ルールが期待どおりに連携して動作することを検証してから、環境で有効にすることをお勧めします。 Security Hub とその強化された機能の詳細については、 Security Hub ユーザーガイド を参照してください。 Joe Wagner Joe は AWS セキュリティサービスに注力するシニアセキュリティスペシャリストソリューションアーキテクトです。サイバーセキュリティは常に変化しており、お客様がそれらすべてをナビゲートできるよう支援することに誇りを持っています。仕事以外では、新しい趣味を試したり、地元のレストランを探索したり、できるだけ屋外で過ごしたりしています。 Ahmed Adekunle Ahmed は AWS で検出と対応サービスに注力するセキュリティスペシャリストソリューションアーキテクトです。AWS 入社前は、ビジネスプロセス管理と AWS 技術コンサルティングのバックグラウンドを持ち、お客様がクラウドテクノロジーを使用してビジネスを変革できるよう支援していました。仕事以外では、サッカー、恵まれない人々への支援活動、旅行、スパイシーな食べ物 (特にアフリカ料理) を楽しんでいます。 Salifu (Sal) Ceesay Sal は金融サービスを専門とする Amazon Web Services (AWS) のテクニカルアカウントマネージャーです。ネイティブのインシデント検出と対応サービスの専門知識を持ち、さまざまなユースケースにわたってマネージドソリューションの運用化と最適化を支援するために組織と連携しています。仕事以外では、ガーデニング、サッカーのプレーと観戦、旅行、家族とのさまざまなアウトドア活動を楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 11 月 13 日に公開された AWS Blog “ Amazon Inspector detects over 150,000 malicious packages linked to token farming campaign ” を翻訳したものです。 Amazon Inspector のセキュリティリサーチャーは、 npm レジストリにおいて、 tea.xyz トークンファーミングキャンペーンに関連する 15 万件以上のパッケージを特定し、報告しました。これはオープンソースレジストリ史上最大規模のパッケージフラッディングインシデントの 1 つです。2024 年 4 月に Sonatype のリサーチャーが報告した当初の 1.5 万件 をはるかに上回り、サプライチェーンセキュリティにおける重大な転換点となっています。リサーチチームは、高度なルールベースの検出と AI を組み合わせて、自己複製型の攻撃パターンを発見しました。この攻撃では、脅威アクターがパッケージを自動生成・公開し、ユーザーが気づかないうちに暗号通貨報酬を得ていました。これにより、最初の特定以降、このキャンペーンがいかに急激に拡大してきたかが明らかになりました。 このインシデントは、金銭的インセンティブが前例のない規模でレジストリ汚染を引き起こすという脅威の進化と、ソフトウェアサプライチェーンを守るための業界とコミュニティの連携の重要性の両方を示しています。Amazon Inspector チームは、革新的な検出手法を通じて、巧妙で従来の手法では見つけにくい新しいタイプの脅威を検出する能力を発揮しました。また、悪意あるパッケージ識別子 (MAL-ID) の割り当てと対応の調整のために Open Source Security Foundation (OpenSSF) と迅速に連携したことは、セキュリティ組織が新たな攻撃ベクトルに対して迅速かつ効果的に対応する方法のモデルを示しています。オープンソースコミュニティが成長を続ける中、このケースは、金銭的インセンティブが存在する場所には新たな脅威が出現するという警告であると同時に、協調的な防御がサプライチェーン攻撃への対処にいかに役立つかを示しています。 検出 2025 年 10 月 24 日、Amazon Inspector のセキュリティリサーチャーは、npm レジストリ内の疑わしいパッケージパターンの検出能力を強化するために、AI と組み合わせた新しい検出ルールをデプロイしました。数日以内に、システムは tea.xyz プロトコル (オープンソース開発者に報酬を与えるために設計されたブロックチェーンベースのシステム) に関連するパッケージを検出し始めました。 11 月 7 日までに、リサーチャーは数千のパッケージを検出し、組織的なキャンペーンの可能性があるとして調査を開始しました。翌日、評価結果を検証しパターンを分析した後、OpenSSF に連絡を取り、調査結果を共有して対応を調整しました。OpenSSF のレビューと合意を得て、Amazon Inspector のセキュリティリサーチャーは発見したパッケージを OpenSSF の悪意あるパッケージリポジトリ に体系的に提出し始め、各パッケージは 30 分以内に MAL-ID を受け取りました。この作業は 11 月 12 日まで続き、最終的に 15 万件以上の悪意あるパッケージが発見されました。 調査で明らかになった内容は以下のとおりです。 tea.xyz トークンファーミングキャンペーンに関連する 15 万件以上のパッケージ 有用な機能を持たないパッケージを作成する自己複製型の自動化プロセス パッケージをブロックチェーンウォレットアドレスにリンクする tea.yaml ファイルの体系的な組み込み 複数の開発者アカウントにわたる組織的なパッケージ公開 従来のマルウェアとは異なり、これらのパッケージには明らかに悪意のあるコードは含まれていません。代わりに、自動複製と依存関係チェーンを通じてパッケージメトリクスを人為的に水増しすることで tea.xyz の報酬メカニズムを悪用し、脅威アクターがオープンソースコミュニティから金銭的利益を得ることを可能にしています。 新たな攻撃ベクトルとしてのトークンファーミング このキャンペーンは、サプライチェーンセキュリティにおける懸念すべき進化を表しています。これらのパッケージは認証情報を盗んだりランサムウェアを展開したりするわけではありませんが、重大なリスクをもたらします。 レジストリ汚染: npm レジストリは低品質で機能しないパッケージで溢れ、正当なソフトウェアを見えにくくし、オープンソースコミュニティへの信頼を低下させます リソースの悪用: レジストリのインフラストラクチャ、ネットワーク帯域、ストレージが、金銭的利益のためだけに作成されたパッケージによって消費されます 悪用の前例: このキャンペーンの成功は、他の報酬ベースのシステムでも同様の悪用を促し、金銭的利益のための自動パッケージ生成を常態化させる可能性があります サプライチェーンリスク: 無害に見えるパッケージでも不要な依存関係を追加し、予期しない動作を引き起こしたり、依存関係の解決に混乱を生じさせる可能性があります OpenSSF との連携: 迅速な対応 Amazon Inspector のセキュリティリサーチャーと OpenSSF の連携により、迅速な対応と以下のようなメリットがもたらされました。 脅威インテリジェンスの即時共有: リサーチャーの調査結果は OpenSSF の悪意あるパッケージリポジトリと共有され、コミュニティに包括的な脅威データが提供されました MAL-ID の割り当て: OpenSSF は検出されたパッケージに MAL-ID を迅速に割り当て、コミュニティ全体でのブロックと修復を可能にしました。割り当ての平均時間は 30 分でした 協調的開示: 両組織は協力して、より広いオープンソースコミュニティに脅威について通知しました 検出基準の強化: このキャンペーンからの知見は、オープンソースセキュリティコミュニティ全体での検出能力の向上とポリシー推奨に活用されています この連携は、業界のリーダーとコミュニティ組織がソフトウェアサプライチェーンの保護にどのように協力できるかを示す好例です。MAL-ID の迅速な割り当ては、オープンソースレジストリの整合性を維持するという OpenSSF のコミットメントを示しています。また、リサーチャーの検出作業と脅威インテリジェンスは、進化する攻撃パターンに先んじるために必要な高度な知見を提供しています。 技術的詳細: リサーチャーがキャンペーンを検出した方法 Amazon Inspector のセキュリティリサーチャーは、ルールベースの検出と AI を活用した技術を組み合わせて、このキャンペーンを発見しました。リサーチャーは、以下のような疑わしい特徴を特定するためのパターンマッチングルールを開発しました。 tea.yaml 設定ファイルの存在 オリジナルの機能を持たない最小限またはクローンされたコード 予測可能な命名パターンと自動生成のシグネチャ 関連パッケージ間の循環依存関係チェーン 公開パターンを監視することで、リサーチャーは自動化ツールを使って高速にパッケージを作成する組織的なキャンペーンを明らかにしました。 脅威への対応方法 お客様の環境でこのような脅威を検出し対処するには、標準的なインシデント対応プロセスに従ってください。 開発環境をスキャンするには、以下の手順を推奨します。 Amazon Inspector の使用: tea.xyz トークンファーミングに関連するパッケージの 検出結果 を確認し、推奨される修復手順に従ってください パッケージの監査: 低品質で機能しないパッケージを削除してください サプライチェーンの強化: ソフトウェア部品表 (SBOM) を適用し、パッケージバージョンを固定し、CI/CD 環境を分離してください この投稿についてご質問がある場合は、 Amazon Inspector タグ付きの AWS re:Post にコメントを追加するか、 AWS サポート にお問い合わせください。 Chi Tran Chi は Amazon Web Services のシニアセキュリティリサーチャーで、オープンソースソフトウェアサプライチェーンセキュリティを専門としています。オープンソースソフトウェア内の悪意あるパッケージを検出する Amazon Inspector のエンジンの研究開発をリードしています。Amazon Inspector の SME として、複雑なセキュリティ実装や高度なユースケースについてお客様に技術的なガイダンスを提供しています。専門分野はクラウドセキュリティ、脆弱性リサーチ、アプリケーションセキュリティです。OSCP、OSCE、OSWE、GPEN などの業界認定資格を保有し、複数の CVE を発見し、オープンソースセキュリティイノベーションに関する特許を出願中です。 Charlie Bacon Charlie は AWS の Amazon Inspector セキュリティエンジニアリングおよびリサーチ責任者です。Amazon Inspector やその他の Amazon Security 脆弱性管理ツールを支える脆弱性スキャンおよびインベントリ収集サービスのチームをリードしています。AWS 入社前は、金融およびセキュリティ業界で 20 年間にわたり、リサーチと製品開発の両方でシニアロールを務めました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの岩根です。3号目となった月間 AWS 製造ブログでは、re:Invent 2025 の注目セッションを中心に、re:Invent 特集としてお届けします。先月号は こちら です。未読の方はあわせてご覧ください。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 ピックアップトピック AWS re:Invent 2025 が 12 月 1 日から 5 日までラスベガスで開催されました。サービスアップデートの速報動画は こちら からご覧いただけます。新しいサービスの発表も楽しみなのですが、沢山のセッションも行われした。今回は、日本のメンバーも現地で Chalk Talk 「Accelerating Smart Products SDLC with Amazon Q Developer (IND303)」 に登壇しました。Amazon Q Developer によるスマートプロダクト開発ライフサイクルの革新をテーマに、ハードウェア・組込みソフトウェア・アプリケーションを AI 支援のチケット駆動型ワークフローで統合する方法をご紹介しました。このChalk Talkの内容は、2月に開催予定の製造業向け reCap 動画配信で、概要をお伝えします。 特集：re:Invent 2025 製造業関連ブレイクアウトセッションのご紹介 ここでは、re:Invent 2025におおける製造業関連のセッションをご紹介します。セッション資料は こちら からダウンロードいただけます。 Product Engineering領域 Detecting falls in aged care with a minimum lovable product (IND321) ボーイング社がPLMシステムをAWSに移行し、Terraformを活用してモダナイズした結果、デプロイ時間を99％削減、インフラコストを40％削減、手動プロセスを78％削減という驚異的な成果を達成した事例をご紹介しました。 Democratizing Whirlpool’s Virtual Product Development with AWS (IND331) アメリカ家電最大手のWhirlpoolが、AWS上でSageMakerを活用した設計探索システムを構築し、10000の製品イテレーションをわずか5分で完了させ、50以上の設計要素を最適なトレードオフで評価できるようになった革新的な製品開発事例をご紹介しました。 Apollo Tyres Accelerates Engineering Workflows with HPC on AWS (IND368) インドのタイヤメーカーApplloTyersが、AWS上にHPC環境を構築してセルフサービス型のシミュレーションシステムを実現し、シミュレーション時間を60％短縮しながらコストも削減した製品開発効率化事例をご紹介しました。 HPC at Scale with AWS Parallel Computing Service (PCS) (CMP340) AI/シミュレーション統合でHPC需要が爆発的に増加する中、AWS Parallel Computing Service（PCS）が登場し、豊田中央研究所では環境セットアップ時間を6週間から30分に短縮し、自動スケール機能でコスト最適化を実現した革新的なフルマネージドHPCサービス事例をご紹介します AI Factory in the Cloud with NVIDIA on AWS (AIM116) ServiceNowとSLBがNVIDIA DGX Cloudを活用し、ServiceNowは6000億パラメータモデルと同等性能を30倍小さい150億パラメータで実現、SLBは地質データ分析を加速させた事例から、自社開発の思い込みを捨ててターンキー環境でモデル開発に集中する重要性をご紹介しました。 Smart Product 領域 Caterpillar’s Geospatial Intelligence Solution (IND322) Caterpillarが150万台の接続機械からのデータを統合し、建設業界の深刻な非効率性（材料10%無駄、作業やり直し3分の1、プロジェクト遅延4分の3）を解決するため、AWSでCat Heliosプラットフォームを構築し、23,000以上のMLモデルを活用した精密作業システムで大幅なコスト削減と環境負荷軽減を実現した事例をご紹介しました。 Detecting falls in aged care with a minimum lovable product (DEV337) オーストラリアの介護スタートアップCuidadoConnectが、高齢者介護施設の転倒検知システムの課題（古い、高額、精度不良）を解決するため、ミリ波レーダーとAWS IoT Coreを活用し、ペルソナ定義によるバッチ・リアルタイム処理の使い分けで顧客ニーズに応えた革新的なソリューション開発事例をご紹介しました。 Control humanoid robots and drones with voice and Agentic AI (DEV313) 香港情報技術学院の学生チームが、Amazon Bedrock Nova SonicとAWS IoT Coreを活用した完全サーバーレスアーキテクチャで、プログラミング未経験でも音声で直感的にロボットやドローンを制御でき、単一コマンドで複数デバイスを連続実行する革新的な音声制御システムを実現した事例をご紹介しました。 Designing local Generative AI inference with AWS IoT Greengrass (DEV316) ソラコム松下氏がRaspberry Pi 5でフィジカルAIの実現可能性を実証し、日本のLinku社がAWS IoT GreengrassとVLAモデルを活用したエッジAIで、従来500-600ミリ秒のクラウドレイテンシを大幅短縮し、物体位置自動認識による人手調整不要のロボットアーム制御を実現した革新的事例をご紹介しました。 Edge AI in Real-World Solutions using AWS SageMaker, Greengrass and Bedrock エッジAIの普及に伴う移植困難・最適化複雑さ・デプロイ管理の煩雑さという課題を、AWSがQualcomm AI HubとEdge Impulseと連携して6ステップのシームレス統合パイプラインで解決し、工場での錠剤欠陥検出実証で20倍高速なスループットを達成したリアルタイム品質検査事例をご紹介しました。 Accelerate product development lifecycle with a product digital twin (IND371) 従来のOEMが新製品開発に5-7年要する一方、中国BYDなどが2年以内で完了する競争力格差を背景に、AWSがDigital Engineering Frameworkを通じてAmazon NeptuneのKnowledge Graphとデータ統合、Amazon Bedrockによる自然言語クエリで設計・製造・サービスのデータサイロを統合し、開発サイクル大幅短縮と実際の使用データに基づいた製品開発を実現した事例をご紹介しました。 Smart Manufacturing 領域 Real-time insights for smart manufacturing with AWS Serverless (CNS375) 製造企業上位500社で年間1.4兆ドルの損失をもたらす計画外ダウンタイムを、AWSのServerlessアーキテクチャとGarnetフレームワークでデータサイロを解消し、Amazon Bedrockのビジョン言語モデルで人間には見えない複合要因異常をリアルタイム検知して、わずか7日間で実装可能なデジタルツイン活用事例をご紹介しました。 Implement Agentic AI at the edge for industrial automation (HMC317) 製造業で年間1.4兆ドルの損失をもたらす計画外ダウンタイムの4つの原因を、AWS OutpostsのEKSローカルクラスタ上でファインチューニング済みLlama3.2とVLMを組み合わせたAgentic AIソリューションにより、クラウド接続切断時も自律動作してリアルタイム診断と推奨事項提供を実現した革新的事例をご紹介しました。 Revolutionizing Audi’s Welding Inspection System through AI (IND367) Volkswagen グループがAWSと共同構築したDigital Production Platform（DPP）で、既に50工場に展開し450のユースケースを実現、抵抗スポット溶接分析では1日500万回の溶接データを100%収集・分析し、AIによる外観検査で従来の人による検査より高精度を実現して固定週間検査を5台から1台に削減した革新的製造データ活用事例をご紹介しました。 Modernizing Operational Technology for AI-power Manufacturing (IND370) AWSのManufacturing & Supply Chain CoEリードのJosephが、製造業の再工業化において変動削減・従業員エンパワーメント・スピード感のある実行という3つのニーズをAIで飛躍的にスピードアップし、3層アプローチで既存プロセス自動化ではなくワークフロー再定義を通じて「完璧を待たずにまず始める」ことの重要性を説いた変革アプローチを講演しました。 Agentic Code Generation for Industrial Analytics & Predictive Maintenance(PEX320) GitHubに公開されているAWS IoT SiteWiseソリューションをライブコーディング形式で紹介し、工場現場とIT側の分断やデータ分析スキルギャップを解決するため、Agent Coreを使用したモーターセンサー異常時の自動修復プラン生成とAgent Core Memoryによる繰り返し障害の原因究明機能をSiteWiseとの組み合わせで実現した事例をご紹介しました。 Supply Chain 領域 Transforming Supply Chains with Amazon Bedrock AgentCore (API206) FujitsuがUvanceブランドで提供する「Uvance decision intelligence」において、AWS Bedrock Agent Coreを活用して従来の「エージェントドリフト」問題をガーディアンエージェントの自動品質維持機能で解決し、顧客企業で人員半減と1000万ドル以上のコスト削減を実現、マルチAIエージェント連携技術で異なる企業のAIエージェント同士がセキュアに連携して全体最適化を図るサプライチェーン管理AIソリューションの実践事例をご紹介しました。 Drive Supply Chain Innovation Using AWS Cloud and AI Solutions (IND3307) 食品業界からシスコとマクドナルドの二社の事例で、シスコが25-30年構築のレガシーシステム「SWIMS」をストラングラーパターンでモダン化し記録的な1年間で110拠点をゼロロールバックで移行完了、50%のコスト削減を実現、マクドナルドが世界120カ国45,000店舗で年間12億個の箱追跡が必要な巨大サプライチェーンにAmazon Supply Chain SolutionとAI/MLを活用したMCD Trackシステムでグローバルな原材料トレーサビリティと需要予測精度向上を実現した事例をご紹介しました。 Automotive Supply Chain Optimization using AI (PEX305) IBMとAWS、トヨタが協力したプレゼンテーションで、従来の手動ファイルベースとバッチプロセス中心の遅いシステムに対し、デジタルツイン構築による物流ネットワーク可視化とメインフレームからAWSクラウドへのCDCデータ移行、SageMakerによる予測モデル構築で正確なETA予測による顧客満足度向上を実現し、トヨタのTravis Washingtonさんが「AIや機械学習は重要だが人々の連携なしには構築できない」と人を中心に考える重要性を強調した顧客中心のサプライチェーン構築事例をご紹介しました。 ** ** Automating Amazon Fulfillment Center Operations with Generative AI (IND393) AWS re:Invent 2025で発表された生成AIによるAmazonフルフィルメントセンターの運用自動化について、製造業・サプライチェーンの再工業化におけるAIの重要性と、年間150のフルフィルメントセンター立ち上げで必要な2,000人月のモジュールテスト工数を削減するため、Amazon Bedrock を活用したコンピュータビジョンソリューション「IORA」で60%のテスト工数削減と600万ドルの費用節約を実現し、2025年初頭のハッカソン優勝から年内の複数センター展開まで進んだスピード感ある事例をご紹介しました。 事例動画のご紹介 三菱電機株式会社: AWS 生成 AI 事例 Vol. 3「AIが実現する次世代の製造革新 スマートファクトリーの未来 三菱電機株式会社 FA システム事業本部 DX 推進プロジェクトグループ プロジェクトグループマネージャー 冨永 博之氏が、製造業のデジタル革新の最前線をお伝えします。長年磨き上げてきたオートメーション技術と AWS の先端テクノロジーの融合がもたらす、自律進化型の次世代製造現場。デジタル基盤「Serendie（セレンディ）」を軸とした部門横断的なデータ連携と、生成 AI や Agentic AI の活用による開発プロセスの革新的な進化。産業のデジタル化を加速し、人々の暮らしを豊かにする—— 三菱電機が描く、製造業の新たな地平をご紹介します。 三菱電機株式会社: AWS 生成 AI 事例 Vol. 4「AIで切り拓く製造業のデジタル革新 最先端テクノロジーの挑戦」 三菱電機のエンジニアたちが、AWSとの革新的な取り組みを語ります。 デジタル基盤「Serendie（セレンディ）」を開発する辻尾氏、家電・住宅機器向けクラウドプラットフォーム「Linova」を担当する小川氏、そしてDX推進基盤の構築を担う杉村氏。3名のエンジニアが、Amazon BedrockやエージェンティックAI、Amazon Q Developerなど、最先端技術の活用事例についてお伝えします。 さらに、エンジニア主導のコミュニティ「MAWS」を通じた組織文化の変革や、AWSとのパートナーシップが創出する新たな可能性まで、製造業のデジタル革新に挑む三菱電機の最前線をご紹介します。 直近で開催予定のイベント AWSは2026年1月6日～9日、ラスベガスで開催された CES 2026 に出展しました（West Hall ブース#4099）。自動車業界向けのライブデモ、シアターセッション、専門家との面談、ガイドツアーを提供しました。主要なAWSパートナーデモとして、Fujitsu（AIによるソフトウェア定義車両とデジタルツイン）、NVIDIA（AWS上のCosmosによる自動運転車開発用合成データ生成）、Siemens（Xceleratorプラットフォームによるスマート製造）、Snowflake（リアルタイム工場インテリジェンス）が、AIとクラウドを活用したモビリティイノベーションの最前線を紹介しました。 製造関連ブログのご紹介 今月もたくさんのブログが公開されました。中でも、Physical AI 関連など注目度の高いブログは順次日本語化も予定しています。 12/3 Embodied AI Blog Series, Part 1: Getting Started with Robot Learning on AWS Batch このブログは、NVIDIA Isaac GR00Tという汎用ロボット学習基盤モデルをAWS Batchでファインチューニングするスケーラブルなパイプラインを構築し、Amazon VPC内にAWS Batch、Amazon ECR、Amazon EFSを組み合わせた訓練環境とAmazon DCVを用いたシミュレーション評価環境を連携させ、TensorBoardによるリアルタイム訓練進捗可視化など開発者が効率的に作業できる機能を提供するAWSを活用したロボット学習インフラストラクチャについて解説したものです。 12/4 Physical AI: Building the Next Foundation in Autonomous Intelligence このブログは、AWSが提案する物理的AI（Physical AI）フレームワークについて、IoTデバイスによる物理世界のデジタル化からエッジでのリアルタイム分析・制御まで6つの重要な機能で構成され、クラウドでのトレーニングループとエッジでの自律ループという2つのループで継続的な学習と改善を実現し、製造、輸送、エネルギー、医療などの分野で最小限の人間の介入で複雑な物理環境で動作する自律システムの開発を可能にするハードウェアとソフトウェアを統合したシステムについて解説したものです。 12/13 Rivian’s proactive approach to identify unrouteable traffic with AWS Transit Gateway Flow Logs このブログは、電気自動車メーカーのRivianがAWS Transit Gateway Flow Logsを活用して複数のアカウントと複数のリージョンにまたがるAWS環境でVPC間の通信が適切にルーティングされていない場合を自動検知・通知するシステムを構築し、サーバーレスアーキテクチャで未ルーティングトラフィックを自動処理・分析してSlack通知を送信することで、アプリケーションチームとネットワークチーム間の可視性問題を解決し、リアクティブな監視からプロアクティブな検知への転換を実現したソリューションについて解説したものです。 12/15 ブラザー工業株式会社インタビュー：IoT プラットフォームの運用とAWS活用事例 このブログは、AWS Summit 2025やIoT@Loftに登壇したブラザー工業株式会社のIoTプラットフォーム開発・運用担当者へのインタビュー記事です。瀧尻氏（プロダクトオーナー）と墨氏（開発・実装担当）が、CDKを活用したIaCによる属人化排除、コントロールプレーンとデータプレーンに分けたリソース管理、事業部への標準化されたプラットフォーム提供について詳しく説明しています。特にリモート印刷システムではMQTTの常時接続により高速な反応を実現し、AWS IoT Coreの接続ステータスクエリAPIなど新機能を積極的に取り入れてコスト最適化を図っています。CloudWatchダッシュボードによる監視とコスト可視化により、朝会での定期チェックを通じて継続的な改善を行っており、事業部が使いやすく管理しやすいIoTプラットフォームの構築事例として参考になる内容となっています。 12/17 How AstraZeneca improved their genomics processing to be 60% faster, 70% more cost-effective このブログは、AstraZenecaのゲノム研究センター（CGR）が2026年までに200万のゲノム分析を目指す中、2025年のF1インスタンスサービス終了を受けてAWS、AstraZeneca、Illuminaが共同でF2インスタンスへの移行テストを実施し、AWS BatchとNextflowワークフローシステムを活用した結果、処理速度60%向上、コスト70%削減を実現し、パイプラインメトリクス、コマンドプロベナンス、変異コールの3つのレベルで出力の同等性を検証してF1とF2インスタンス間で完全な一致を確認した成功的な移行事例について解説したものです。 12/18 Deploying Small Language Models at Scale with AWS IoT Greengrass and Strands Agents このブログは、AWS IoT GreengrassとStrands Agentsを使用した小規模言語モデル(SLM)のエッジデバイス大規模展開ソリューションについて、製造業者が直面するリアルタイム運用データへの知的な意思決定システム実装という課題に対し、SLMとAWS Lambda関数をOPC-UAゲートウェイに直接デプロイして安全性重要タスクへの即時応答を確保しつつクラウドで広範な分析を行うハイブリッドパターンを実現し、エッジAIエージェントとクラウドベースエージェントがシームレスに統合された分散型協調システムを構築する手法について解説したものです。 12/19 Building Resilient Supply Chains: Multi-Agent AI Architectures for Retail and CPG with Amazon Bedrock このブログは、Amazon Bedrockを活用したマルチエージェントAIアーキテクチャによる小売・消費財企業向けサプライチェーン強靭化ソリューションについて、港湾閉鎖などの混乱に対し従来の手動分析や逐次的意思決定では対応困難な課題に対して、Amazon Bedrock AgentCoreを用いたSupply Chain Coordinatorというスーパーバイザーエージェントが物流最適化、在庫管理、プロモーションリスク、出荷追跡の各専門エージェントを統括して協調し、港湾閉鎖シナリオで数分以内に代替ルートの提案や在庫再配置など具体的対応策を提示する新しい解決策について解説したものです。 12/22 Build a multimodal generative AI assistant for root cause diagnosis in predictive maintenance using Amazon Bedrock このブログは、Amazon BedrockのFoundation Modelsを活用した予知保全ソリューションについて、Amazonフルフィルメントセンターの製造設備を事例として機器センサーデータと高度な分析により機器故障を予測し、センサーによる継続的モニタリングと異常パターン検出、そしてマルチモーダルな生成AIアシスタントによるセンサーデータからの根本原因特定とメンテナンスガイダンス提供の2つのフェーズで構成され、診断効率化、ダウンタイム最小化、運用効率向上を実現して石油・ガス、物流、製造、ヘルスケアなど様々な産業に適用可能な予防的メンテナンスソリューションについて解説したものです。 12/24 Streamlining Amazon Sidewalk Device Fleet Management with AWS IoT Core’s New Bulk Operations このブログは、AWS IoT Core for Amazon Sidewalkに追加された新しい一括管理機能を解説しています。Amazon Sidewalkは、Amazon EchoやRingデバイスをゲートウェイとして使用するコミュニティベースのIoTネットワークです。この新機能により、CDKベースのスタックとJSONファイルを使用して、数千台のデバイスのプロビジョニング、設定、管理を効率的に行えるようになりました。CloudWatchによるリアルタイムモニタリング、自動エラー処理、柔軟な通知オプションを提供し、数百から数百万台のデバイスまでスケーラブルに管理できます。 12/31 AWS IoT: A 10-year foundation for an intelligent, connected future このブログは、AWS IoTの10周年を振り返る内容です。2015年の立ち上げから現在まで、毎日数億台のデバイスが接続するまでに成長し、Device ShadowsやAWS IoT Greengrass、IoT SiteWiseなど多数の機能が追加されました。世界的企業がスマートホーム、自動車、産業製造、ヘルスケア分野で活用し、業務効率化や新ビジネスモデル創出を実現しています。他のAWSサービスとの統合や60以上のパートナーとの協力により包括的なソリューションを提供し、今後はAIエージェントとの統合やエッジコンピューティングの進化でさらなる発展が期待されています。 1/3 AWS re:Invent 2025 Recap for Automotive and Manufacturing このブログは、2025年12月1日から5日に開催されたAWS re:Invent 2025の自動車・製造業向け発表内容をまとめています。製造・サプライチェーン分野ではAIエージェントを活用した品質管理・予測保全事例、製品エンジニアリング分野では新EC2インスタンスとSageMaker HyperPod機能強化が発表され、自動車・製造業のデジタル変革を加速させる重要な技術革新が示されました。 製造関連の主要なアップデート 12/3 AWSのAI Factories の紹介 AWSはデータセンターにAWSのAI専用インフラストラクチャを提供するAWS AI Factoriesを発表しました。最新のAcceleratorsとGPUを組み合わせた高性能なAIインフラで、AIの構築を大幅に加速できます。政府機関や企業向けに、データ残留要件を満たす専用の分離されたAI環境を提供します。AWSのクラウドサービスと統合されており、Amazon Bedrock、Amazon SageMaker などの先進的なAIサービスにアクセスできます。 12/17 AWS IoT デバイス管理コマンドが、動的ペイロードをサポート AWS IoT Device Management コマンドで動的ペイロード機能がサポートされるようになり、開発者はコマンドテンプレートを作成してパラメータを実行時に指定できるようになりました。これにより、IoTデバイスへの同様のコマンド送信を合理化できます。 12/19 AWS IoT 、可観測性コストを最適化するのに役立つイベントベースのロギングを提供 AWS IoTでは、イベントベースのロギング機能が新たに導入されました。この機能により、開発者はイベントの重要度に応じてログレベルを細かく設定できるようになり、ログの検索性と分析効率が向上するとともに、コストを削減することができます。 12/20 AWS IoT CoreはHTTPルールアクションにメッセージバッチ機能を追加 AWS IoT Coreでは、複数のIoTメッセージを1つのバッチにまとめてHTTPエンドポイントにルーティングできるようになり、IoTワークロードからのテレメトリ取り込み時のコストとスループット負荷を削減できるようになりました。この新機能はすべてのAWS リージョンで利用可能です。 12/22 Research and Engineering Studio on AWS バージョン 2025.12 が利用可能に CloudFormationリソースへのタグ伝播、Windowsドメイン設定の柔軟性向上、デフォルトのセッションスケジューリング、セキュリティ強化などの新機能が導入されました。この更新により、組織全体でのリソース管理が容易になり、セキュリティ標準の遵守と運用の効率化が図れます。 最後まで読んでいただきありがとうございました。いかがだったでしょうか？このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。月刊 AWS 製造ブログを今後ともよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 岩根 義忠 (Yoshitada Iwane) 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。

本記事は「 Property-Based Testing Caught a Security Bug I Never Would Have Found 」を翻訳したものです。 ターゲット型ランダムテストが実際のセキュリティ脆弱性を発見したとき セキュリティ脆弱性は、私たちがテストしようと思わないコードの隅に隠れていることがよくあります。正常系テストを書き、想像できるいくつかの境界値ケースをテストしますが、考えもしない入力についてはどうでしょうか？ LLM がデフォルトでこれらのシナリオを処理していると仮定することが多いですが、LLM が生成したコードも人間が書いたコードと同様にバグや脆弱性を含む可能性があります。ユーザーがアプリケーションに悪意のある文字列を入力したらどうなるでしょうか？ これは、Kiro の 最新の GA 機能 を使用して AI でチャットアプリケーション用のストレージサービスを構築するテストを行ったときに起こったことです。 仕様駆動開発（SDD）ワークフロー に従って、Kiro は要件を慎重に定義し、テスト可能なプロパティを抽出し、API キーの保存と取得のための一見単純なコードを実装しました。実装は堅実に見えました。コードレビューでも承認されたでしょう。従来の単体テストも通過したでしょう。 しかし、プロパティベーステストの 75 回目の反復で、予期しないことが起こりました。ラウンドトリップケースのプロパティテスト全体が失敗したのです。単純な保存と取得操作であるはずが、代わりに JavaScript プロトタイプの誤った処理を露呈しました。これは、早期に欠陥を排除するよう注意しないと、将来的にセキュリティ問題につながる可能性があるバグです。 この投稿では、プロパティベーステスト（PBT）が人間の直感や従来のテスト手法では見逃されたであろうセキュリティバグをどのように発見したかのストーリーを紹介します。以下について説明します。 Kiro が定義した仕様とプロパティ 重大な欠陥を含んでいた一見無害な実装 PBT の入力空間の体系的な探索が脆弱性をどのように発見したか 脆弱性に対処する修正 これが安全なソフトウェア構築にとってなぜ重要なのか これは単なる理論的な演習ではありません。自動テスト技術が、セキュリティ研究者を夜も眠れなくするエッジケースを、本番環境に到達する前に発見できることの実例です。 背景 一部の顧客とアプリケーションの構築に取り組み、仕様のプロンプトを検討する際、Kiro はユーザーデータをブラウザの localStorage に保存するチャットアプリケーション用のストレージシステムを実装していました。主要な機能の一つは、異なる LLM プロバイダー（OpenAI、Anthropic など）の API キーを保存することでした。ユーザーはプロバイダー名をキーとして API キーを保存できます。このオブジェクトは以下のような API を持ちます。 storageService.saveApiKey("openai", "sk-abc123..."); storageService.saveApiKey("anthropic", "sk-ant-xyz..."); Kiro は SDD に従って以下の要件を策定しました。 ### 要件 6 **ユーザーストーリー:** ユーザーとして、異なる LLM プロバイダーの API キーを設定したい。そうすることで、自分のアカウントを使用してコストを管理できる。 #### 受け入れ基準 1. ユーザーが設定を開いたとき、チャットアプリケーションは各 LLM プロバイダーの API キー入力フィールドを表示する 2. ユーザーが API キーを保存したとき、チャットアプリケーションはそれをローカルストレージに安全に保存する 3. API キーが無効または欠落している場合、チャットアプリケーションは明確なエラーメッセージを表示し、メッセージ送信を防ぐ 4. チャットアプリケーションはセキュリティのため UI で API キー値をマスクする 5. ユーザーが API キーを削除したとき、チャットアプリケーションはその LLM プロバイダーを無効にする 受け入れ基準 2 について詳しく見てみましょう。Kiro はこれを重要な正確性プロパティとして選択しました。 **プロパティ 19: API キーストレージのラウンドトリップ** *任意の* プロバイダーに保存された API キーについて、ストレージから取得すると同じキー値が返される。 **検証対象: 要件 6.2** Kiro はこれを「ラウンドトリップ」プロパティと呼んでいます。ラウンドトリップは正確性プロパティの一般的な形で、任意の値から始めて、一連の操作を実行し、同じ値で終わるものです。この場合、任意の文字列値 provider と key から始めて以下を行いました。 ストレージの provider の下に key を保存 provider に関連付けられた値を取得 そして、取得した値は key と等しくなければなりません。これが真でない場合（異なる値を取得したり、例外が発生したりする場合）、明らかに実装に何か問題があります。この仕様は素晴らしく見えるので、承認して Kiro に API を実装してもらいます。 LLM は API の一部として以下のコードを生成しました。 /** * 特定のプロバイダーの API キーを保存 */ saveApiKey(provider: string, apiKey: string): void { try { const apiKeys = this.loadAllApiKeys(); apiKeys[provider] = apiKey; localStorage.setItem( StorageService.API_KEYS_KEY, JSON.stringify(apiKeys) ); } catch (error) { if (error instanceof Error && error.name === 'QuotaExceededError') { throw new Error('ストレージクォータを超過しました。API キーを保存できません。'); } throw error; } } その後、Kiro はプロパティベーステストを使用してこのコードをテストし、期待するプロパティが実際に成り立つという証拠を収集しました。プロパティ 19 をチェックするために、Kiro は TypeScript 用の fast-check ライブラリを使用して以下のテストを書きました。 describe('プロパティ 19: API キーストレージのラウンドトリップ', () => { /** * 機能: llm-chat-app, プロパティ 19: API キーストレージのラウンドトリップ * 検証対象: 要件 6.2 * * プロバイダーに保存された任意の API キーについて、ストレージから取得すると * 同じキー値が返される。 */ it('保存と読み込みサイクルを通じて API キーを保持する', () => { fc.assert( fc.property( fc.string({ minLength: 1, maxLength: 100 }), // プロバイダー名 fc.string({ minLength: 10, maxLength: 200 }), // API キー (provider, apiKey) => { // 各プロパティテスト実行前に localStorage をクリア global.localStorage.clear(); // API キーを保存 storageService.saveApiKey(provider, apiKey); // 読み込み直す const loaded = storageService.loadApiKey(provider); // 元の値と一致することを確認 expect(loaded).toBe(apiKey); } ), { numRuns: 100 } ); }); Kiro がこのテストを実行すると、試行 #75 で失敗が発生しました！Kiro は失敗を Shurinking し、以下の反例を報告しました。プロバイダー "__proto__" と API キー " " 。 何が起こっているのか？ プロパティベーステストはプロバイダー名にランダムな文字列を生成し、75 回のテスト実行後、プロバイダー名として文字列 "__proto__" を生成しました。これにより、以下の反例でテストが失敗しました。 反例: ["__proto__"," "] プロバイダー名 __proto__ で API キーを保存してから読み込もうとすると、奇妙なことが起こり、期待した値を取得できません。Kiro は Shurinking を使用して最小反例を提示して問題を特定し、問題から余分な詳細を取り除くのに役立ちます。この場合、apiKey 文字列をジェネレーターで許可される最小の文字列（スペースのみを含む）に Shurinking します。これは、問題が値ではなく、奇妙なキーが問題を引き起こしていることを示しています。JavaScript に詳しい方なら、このエラーはすぐに目に付くでしょうが、そうでない方は読み続けてください。 これは JavaScript がオブジェクトシステムを実装する方法の特徴です。より伝統的なオブジェクト指向プログラミング言語（Java、Python、SmallTalk など）は、クラスの概念を使用します。各クラスは、オブジェクトの構築方法を記述し、異なるオブジェクト間の継承関係を記述するコードベースの静的メンバーです。JavaScript は「プロトタイプ」と呼ばれる代替アプローチを使用します。プロトタイプベースのオブジェクトシステムでは、クラスは存在しません。代わりに、すべてのオブジェクトには、コードとデータを継承すべき親オブジェクトを指すプロトタイプと呼ばれる特別なフィールドが含まれています。これにより、継承関係を動的に設定できます。JavaScript では、このプロトタイプは __proto__ フィールドに存在します。フィールドを文字列に設定しようとしたとき、JavaScript エンジンはこれを拒否し、元のプロトタイプをそのまま保持しました。これにより、プロパティテストの第 2 ステップで provider を検索したときに、元のプロトタイプ（空のオブジェクト）を取得することになります。 プロトタイプへの書き込みが例のように無害というわけではありません。 provider と apiKey は攻撃者の制御下にあるため、攻撃者が apiKey に文字列以外の値を取得する方法を見つけた場合、プロトタイプに値を注入でき、オブジェクトのプロパティからのさらなる読み取りが攻撃者制御の値を返す可能性があります。 これは悪用可能でしょうか？いいえ。 apiKeys オブジェクトは十分に長く存在せず、シリアル化後すぐに解放され、 JSON.stringify は __proto__ フィールドをスキップすることを知っています。また、グローバルプロトタイプを変更するのではなく、 apiKeys のプロトタイプのみを上書きしています。しかし、コードのリファクタリングにより、この悪用不可能な脆弱性をより広範囲な影響を与える可能性のあるものに変える新しいコードパスが導入される可能性があります。プロパティベーステストが提供するテスト力は、これを即座に捕捉して、コードベースにおいて微妙な不正確さや難しいエッジケースが増えるのを防ぐのに役立ちます。 Kiro はこれをどのようにテストしたのか？ プロバイダー名 __proto__ で API キーを保存してから読み込もうとしたとき、保存した API キーの代わりに空のオブジェクト {} を取得しました。なぜこれが起こったのでしょうか？内部で何が起こったかについてもう少し背景を理解しましょう。 PBT の利点の１つと言われているのはバイアスです。単体テストでは、テストを書いた人（モデルまたは人間）がエッジケースを考慮しようとしましたが、自分自身の内部バイアスによって制限されています。同じ（モデル/人）が実装を書いたので、実装中に考えなかったエッジケースを思いつくのは困難だと考えるのが妥当です。この場合、プロパティベーステストを使用することで、テストフレームワークを作った人たちの集合知が使えます。この場合、一般的なバグタイプの体系的知識“をプロセスに注入しています。（ __proto__ は、fast-check コミュニティの作者によって PBT ジェネレーターにエンコードされた一般的なバグ文字列の一つです）をテストプロセスに注入しています。 続行する前に注意すべき点は、PBT コードに { numRuns: 100 } があることです。これは、ジェネレーターがバグを見つけようとする 100 回の反復があることを意味します。Kiro はこれをデフォルトにしていますが、プログラムに求める信頼レベルに応じて、この値を上げたり下げたりできます。時にはもっと必要ですが、実装のテストに少し時間がかかるため、100 回以上の入力テストを実行するパフォーマンスが開発ライフサイクルのその段階ではまだ価値がない場合もあります。良い点は、必要に応じていつでもこれを上げたり下げたりできることです。 修正 Kiro は MITRE の高効果緩和戦略 に基づいて 2 つの防御策を実装しました。 1. 安全な保存（ saveApiKey 内） // プロトタイプ汚染を避けるため null プロトタイプオブジェクトを作成 const safeApiKeys = Object.create(null); Object.assign(safeApiKeys, apiKeys); safeApiKeys[provider] = apiKey; Object.create(null) で作成されたオブジェクトにはプロトタイプチェーンがないため、 __proto__ は単なる通常のプロパティになります。 2. 安全な取得（ loadApiKey 内） // hasOwnProperty を使用してキーを安全にチェック return Object.prototype.hasOwnProperty.call(apiKeys, provider) ? apiKeys[provider] : null; より大きな視点 このストーリーは、Kiro が SDD の一部としてプロパティベーステストを使用する理由を示しています： プロパティは要件に直結 – 「任意のプロバイダー名について、ラウンドトリップする」というプロパティは、要件をそのまま変換したものです。 ランダム生成は予期しないエッジケースを発見 – 人間と LLM は、テストする入力についてバイアスを持っています。ランダム生成はテストケースを徹底的に追い込みます 実行可能な仕様 – プロパティは実行できる仕様です。「コードは何をすべきか」（要件）と「コードは実際にそれを動かすのか」（テスト）の間のギャップを埋めます。 タイトなフィードバックループ – プロパティが失敗すると、デバッグを容易にする最小限の反例を取得します。Kiro はこれを使用してコードを修正し、迅速な反復サイクルを作成できます。 このバグは Kiro での実際の開発中に発見されました。プロパティベーステストは、以下の方法では発見が非常に困難だったであろうセキュリティ弱点をキャッチしました。 手動コードレビュー 手動で選んだ例を使った従来の単体テスト 統合テスト

マルチルートワークスペースとは？ 通常、Kiro ワークスペースは単一のプロジェクトフォルダに紐づいています。 📁 my-app/ ├── .kiro/ ← すべての仕様、ステアリング、フックがここに存在 ├── src/ └── tests/ しかし、 my-app と、それが依存する共有ライブラリを同時に作業している場合はどうでしょうか？複数のマイクロサービスを管理している場合は？多数のパッケージを持つモノレポの場合は？そこでマルチルートワークスペースの出番で、今日から試すことができます！ マルチルートサポートにより、複数のフォルダを単一の Kiro IDE ウィンドウに取り込むことができます。この方法で、それぞれが独立性を保ちながら、すべてが連携して動作します。 📁 my-app/ ← ルート 1 ├── .kiro/ └── src/ 📁 shared-ui/ ← ルート 2 ├── .kiro/ └── components/ 📁 auth-service/ ← ルート 3 ├── .kiro/ └── api/ この方法により、マージやシンボリックリンクを心配する必要がなく、クリーンな複数プロジェクトへの同時アクセスが得られます。 なぜこれを使うのでしょうか？ マルチルートは以下の場合に適しています： 共有ライブラリへの変更が必要なアプリの機能を編集している場合 複数の関連サービスを保守している場合（例：フロントエンド + バックエンド + 認証） git サブモジュールやワークスペース（npm/yarn/pnpm ワークスペースなど）を使用している場合 複数のプロジェクトにまたがって検索、ナビゲーション、リファクタリングを行いたい場合 チームメイトに回避策を DM で尋ねたり、複数のリポジトリなどを Kiro IDE で同時に開く方法を考えたりする代わりに、プロジェクトの全コンテキストを 1 つのワークスペースで同期させることができます。これにより、Kiro で複数のルートにまたがるタスクの作業が容易になります。 どのように設定するのでしょうか？ 2 つのオプションがあり、どちらも簡単です。 File → Add Folder to Workspace… → フォルダを選択 フォルダを Kiro にドラッグアンドドロップ Kiro は各フォルダをルートとして認識し、各ルートから .kiro 設定ファイルの読み込みを開始します。 Kiro が複数のルートを処理する方法 各ルートは独自の識別子を保持しますが、Kiro がすべてをまとめてくれます。 仕様：1 つのリスト、複数のソース すべてのステアリングファイルは、Agent Steering パネルの「Workspace」の下の 1 つのリストに表示され、それぞれがどのルートから来ているかを示します。新しいステアリングファイルを作成する際、Kiro は 3 つのオプションを提供します。 my-app エージェントステアリング – その特定のワークスペース内でのみ適用 グローバルエージェントステアリング – すべてのワークスペースにまたがって適用 ファンデーションステアリングファイル – コアワークスペースコンテキストを確立するためのファンデーションファイルを自動作成 「Always Included」ディレクティブを持つステアリングファイルは、エージェントが作業している特定のルートフォルダに関係なく、常に読み込まれます。しかし、「Conditional Inclusion」ディレクティブを持つものは、エージェントが同じルートで定義されたファイルで作業している場合にのみ読み込まれます。 マルチルートワークスペースでは、ステアリングを整理するために通常は最初のオプションを選択します。 エージェントフック：ホームにスコープ フックは一緒にリストされますが、それぞれがルートに紐づいています。そのため、 shared-ui/.kiro/hooks/ で共有されるフックは、 shared-ui 内のファイルが変更された場合にのみトリガーされ、すべてが適切に分離されます。 MCP：統合されていますが、ルールあり 各ルートからのすべての MCP サーバー定義は起動時に読み込まれます。2 つの異なるルートが同じ名前の MCP を持つ場合、ワークスペースフォルダで最後に表示されるルートのものが「勝ち」ます。そのため、競合を避けるために MCP 名に戦略的かつ慎重になる必要があります。単に github ではなく、 frontend-github や backend-github のようなプレフィックスを使用してください。その後、MCP 設定を開くと、Kiro はどのルートの設定を見たいかを選択するよう促します。 コードベース検索とコンテキスト #codebase はすべてのルートにまたがって検索し、Kiro はワークスペース内のすべてのルートフォルダからソースコード、ドキュメント、設定ファイルを自動的にインデックス化します。 #file を使用して重複がある場合（例：2 つのルートに utils/logger.ts ）、Kiro は完全パスのリストを表示するため、正しいものを選択できます。さらに制御したい場合は、 #file:src/index.ts:10-25 のように行範囲を使用してコンテキストを絞り込むことができます。 実世界の例：クロスプロジェクトワークフロー このシナリオを想像してみてください。 shared-ui の Button コンポーネントを更新し、その後 my-app を更新して新しい variant プロパティを使用する。 Kiro のマルチルートワークスペースでは my-app と shared-ui の両方を 1 つのワークスペースで開きます Kiro に尋ねます #spec:ui-update Button に 'outline' バリアントを追加し、その後 my-app でそれを使用するよう更新 Kiro は、コードの更新、フックの実行、仕様の作業が必要な場合に、1 つの会話で両方のルートにまたがって動作します。 これはすべて 1 つのフローで発生するため、ウィンドウを切り替えたり、別々の会話を作成したりする必要がありません。 試す準備はできていますか？ Kiro の最新バージョンに更新されていることを確認し、別のプロジェクトフォルダを Kiro ウィンドウにドラッグするだけで準備完了です！Kiro の新機能を見たい場合は、 General Availability Launch Blog と Changelog をチェックしてください。

はじめに ISMAP ポータルサイトに、「 生成AIサービスに関する留意点について 」が追加されていますが、その内容について考察したいと思います。 この内容に基づけば、AWS としてはAmazon Bedrock のような生成AI開発基盤を通じて提供される生成 AI サービスの位置づけに関し、Amazon Bedrock上で動作する個々の生成 AI モデルについては、必ずしも ISMAP に登録されている必要がないと考えます。 本記事では、この更新内容と Amazon Bedrock 、生成 AI モデル(*1)の関係について解説します。 (*1) 生成 AI モデル： 生成 AI モデルは「基盤モデル」と称されることもありますが、本記事では ISMAP ポータルの表記に合わせて、「生成 AI モデル」という表記に統一しています。 ISMAP とは ISMAP ( Information system Security Management and Assessment Program ) は、政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録することにより、政府のクラウドサービス調達におけるセキュリティ水準の確保を図り、もってクラウドサービスの円滑な導入に資することを目的とした制度です。政府情報システムにおいてクラウドサービスを利用する際には、原則として ISMAP に登録されたサービスを選定することが求められています。 ISMAP ポータルサイトより引用： 「 ISMAP ポータルサイト 制度案内 」 URL: https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010005 本制度は、「政府情報システムにおけるクラウドサービスのセキュリティ評価制度の基本的枠組みについて」（令和2年1月30日サイバーセキュリティ戦略本部決定）に基づき、国家サイバー統括室・デジタル庁・総務省・経済産業省が運営しています。独立行政法人情報処理推進機構（ IPA ）は、本制度の制度運用に係る実務及び評価に係る技術的な支援を行います。 ISMAP ポータルサイトの重要な更新 2026 年 1 月 9 日(記事公開追記)、ISMAPポータルサイトのページに、生成AIサービスに関する以下の内容が掲載されました。 ISMAPポータルサイトより引用： 「 生成AIサービスに関する留意点について 」 URL: https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0011070 【クラウドサービス事業者、生成 AI モデル提供者向けの周知事項】 クラウドサービス事業者が生成AIサービスをSaaSとして提供する場合には、当該SaaSは原則としてISMAP等クラウドサービスリストに登録が必要となります。これは生成AIサービスを外部連携で利用する場合においても同様です。 なお、ISMAPに登録されていない生成AIサービスをISMAPに登録されているIaaS、PaaSを用いて提供しても、当該生成AIサービスはISMAPに登録されているサービスと同等とみなすことはできません。 ただし、クラウドサービス事業者が、生成AIモデルを提供する事業者から生成AIモデルの提供を受け、当該生成AIモデルの扱うデータに対してセキュリティ管理機能を適用する自らの生成AI開発基盤において生成AIサービスを提供する場合（PaaSに相当）に、当該生成AI開発基盤を言明対象範囲に含めてISMAPに登録したときには、通常は当該生成AIサービスが取り扱うデータのセキュリティは、ISMAPのセキュリティ要件を満たす状態とみなされます。この場合において、クラウドサービス事業者が生成AI開発基盤を言明対象範囲に含めてISMAPの登録を行う場合には、提供される個々の生成AIモデルを言明対象範囲に含める必要はありません。また、提供される生成AIモデルは必ずしもISMAPに登録されている必要はありません。 この場合において、生成AI特有のリスクについては、ISMAPにおける管理基準とは別に、生成AI開発基盤をISMAP言明対象範囲に含めたクラウドサービス事業者において措置を講じることが必要です。具体的な措置については、「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」の調達チェックシート等を参考にしてください。なお 、ISMAP登録に関する審査基準等については、「ISMAPクラウドサービス登録規則」等において定めており、詳細はISMAPポータルサイトの制度規程等をご確認下さい。 Amzaon Bedrock と生成 AI モデルの位置関係 Amazon Bedrock の特徴の一つとして、 生成 AI モデルが AWS の内部環境に持ち込まれており、お客様のデータが生成 AI モデル開発事業者に提供されることはありません。 これは、政府情報システムにおいて機密性の高いデータを扱う上で重要なポイントになると思います。 [ ご参考： Amazon Bedrock のよくある質問 セキュリティ ] この仕組みにより、以下のセキュリティ上の利点が実現されています: データの機密性保持: お客様の入力データや生成結果が外部の生成 AI モデル開発事業者に送信されることはありません モデル学習への不使用: お客様のデータが生成 AI モデルの学習に使用されることはありません 統一されたセキュリティ管理: Amazon Bedrock の ISMAP 準拠のセキュリティ管理機能により、すべての生成 AI モデルへのアクセスが保護されます ISMAP の評価対象の適切な理解 ISMAP は政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録することにより、政府のクラウドサービス調達におけるセキュリティ水準の確保を図り、もってクラウドサービスの円滑な導入に資することを目的とした制度であり、クラウド基盤上で動作するアプリケーションやデータそのものは評価対象ではありません。これは生成 AI サービスにおいても同様です。 重要なのは、 データのセキュリティを管理する責任がどこにあるか という点です。 Amazon Bedrock の場合下記になります。 Amazon Bedrock (生成 AI 開発基盤): ISMAP の言明対象範囲に含まれ、データのセキュリティ管理を担当 生成 AIモデル: Amazon Bedrock 上で動作し、AWS 内部に配置されているため、ISMAP への個別登録は不要 この構造により、お客様は複数の生成 AIモデルを柔軟に選択・利用しながら、ISMAP のセキュリティ要件を満たした環境でサービスを提供できます。 Amazon Bedrock が提供する生成 AI 特有のリスクへの対応 ISMAP のセキュリティ要件への対応に加えて、生成 AI 特有のリスク(ハルシネーション、プロンプトインジェクション、バイアスなど)について、「行政の進化と革新のための生成 AI の調達・利活用に係るガイドライン」の調達チェックシート等を参考に、適切な措置を講じることが推奨されています。 Amazon Bedrock では、以下のような機能を提供しており、これらのリスクへの対応を支援しています: Guardrails for Amazon Bedrock : 有害なコンテンツのフィルタリング、個人情報の保護 モデル評価機能: 力品質の評価とモニタリング 監査ログ: AWS CloudTrail による詳細なアクセスログの記録 まとめ Amazon Bedrock は ISMAP の言明対象範囲に含まれており、政府情報システムにおいて安心してご利用いただける生成 AI 開発基盤です。ISMAP ポータルサイトの更新により、生成 AI 開発基盤が ISMAP に登録されている場合、その上で動作する個々の生成 AI モデルは必ずしも ISMAP に個別登録されている必要はないという見解が示されました。 Amazon Bedrock の特徴である「生成 AI モデルの AWS 内部への配置」により、お客様のデータは生成 AI モデル開発事業者に送信されることなく、モデル学習にも使用されません。これにより、機密性の高い政府情報を安全に取り扱いながら、最新の生成 AI 技術を活用することが可能です。 政府機関の皆様におかれましては、ISMAP に準拠した Amazon Bedrock を活用することで、セキュリティ要件を満たしながら、生成 AI による業務効率化やイノベーションを推進していただけます。   アマゾン ウェブ サービス ジャパン 合同会社 執行役員 パブリックセクター 技術統括本部長 瀧澤 与一 参考リンク ISMAP ポータルサイト Amazon Bedrock 製品ページ 行政の進化と革新のための生成 AI の調達・利活用に係るガイドライン

本記事は 2026 年 1 月 6 日 に公開された「 Implement multi-Region endpoint routing for Amazon Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は、事実上無制限のスケール、最高レベルの可用性、ゼロインフラストラクチャ管理を実現する、サーバーレスの分散 PostgreSQL 互換データベースです。Aurora DSQL は、データベースシャーディングやインスタンスのアップグレードの必要性を軽減し、シングルリージョンとマルチリージョンの両方のデプロイメントをサポートします。Aurora DSQL は、マルチリージョンクラスターの各リージョンに専用のリージョナルエンドポイントを提供し、アプリケーションが最適なリージョンに直接接続して可能な限り低いレイテンシーを実現できるようにします。そのアーキテクチャは、アクティブ-アクティブ分散設計により、読み取りと書き込みに対して強力なデータ整合性を提供し、シングルリージョンデプロイメントでは 99.99% の可用性、マルチリージョンデプロイメントでは 99.999% の可用性を実現します。 Aurora DSQL マルチリージョンクラスターを使用するアプリケーションは、DNS ベースのルーティングソリューション ( Amazon Route 53 など) を実装して、AWS リージョン間でトラフィックを自動的にリダイレクトする必要があります。これにより、Aurora DSQL クラスターまたは AWS リージョン全体が到達不能になった場合でも、運用の継続性が確保されます。 ベストプラクティスでは、リージョナルフェイルオーバーを包括的に管理するために、アプリケーションレベルのルーティングロジックを実装することを推奨しています。ただし、アプリケーションが Aurora DSQL を含む複数のデータストアに依存している場合、Aurora DSQL リージョナルエンドポイントが到達不能になる状況を処理するための特定の戦略が必要です。この記事では、手動での設定変更を必要とせずに、データベーストラフィックを代替リージョナルエンドポイントに自動的にリダイレクトするソリューションを紹介します。特に、混在データストア環境において有効です。 マルチリージョン Aurora DSQL クラスターのエンドポイント管理 Amazon Aurora DSQL を永続化層として使用する、マルチリージョンアプリケーションアーキテクチャを見てみましょう。 Aurora DSQL マルチリージョンクラスターは、同期クロスリージョンレプリケーションを使用して、リージョン間 (および図には示されていない DSQL ウィットネスリージョン間) で強力な整合性を維持します。DSQL は、どちらのリージョナルエンドポイントでも読み取りと書き込みを受け入れることができ、Aurora DSQL の強力な整合性のおかげで、リージョン A のリーダーはリージョン B でコミットされた書き込みをすぐに確認でき、その逆も可能です。DSQL のこの特性により、マルチリージョンアクティブ-アクティブアプリケーションの構築がはるかに簡単になります。 DSQL がクロスリージョンの調整やメッセージングを実⾏するため、アプリケーションは他のリージョンを考慮する必要はありません。 Aurora DSQL では、サービスがこれらの操作を自動的に処理するため、データベースのフェイルオーバーやスイッチオーバー操作を心配する必要はありません。ただし、アプリケーションが異なる API コールに対して複数のデータストアを使用する特定のシナリオや、外部データセンターからマルチリージョン DSQL クラスターに接続するアプリケーションの場合、DSQL エンドポイント間を直接切り替える方が、アプリケーションサーバーエンドポイント全体をリダイレクトするよりも効率的です。このアプローチは、完全なアプリケーションスタックを移動するのではなく、影響を受けるデータベース接続のみをターゲットにすることで、運用の複雑さを軽減し、サービス中断時に必要な労力を最小限に抑えます。DSQL リージョナルクラスターに中断を引き起こすイベントは、影響を受けるリージョンのアプリケーションの可用性にも影響を与える可能性があります。マルチリージョン DSQL クラスターセットアップでリージョナルエンドポイント障害が発生した場合に、アプリケーションを到達可能なリージョナルエンドポイントに接続する自動化されたソリューションを紹介します。 この記事で説明するソリューションは、 GitHub でサンプルコードとして入手できます。 ソリューション概要 このソリューションでは、カスタム Python クライアント側ライブラリを使用して、アプリケーションから Aurora DSQL エンドポイント間の接続の自動リダイレクトを実装する方法を示します。デプロイされると、 Amazon Route 53 API を通じて Aurora DSQL エンドポイントを監視します。ライブラリは、まずこれらのヘルスチェックを通じて正常なエンドポイントを識別し、次にクライアントと各正常なエンドポイント間のレイテンシーを測定します。クライアント接続を、最も低いレイテンシーを持つ正常なエンドポイントに自動的にルーティングし、リージョナルエンドポイントが到達不能になるまれなイベントが発生した場合でも、クライアント接続が最も低いレイテンシーを持つ正常な Aurora DSQL エンドポイントにルーティングされることを保証します。そして、Aurora DSQL の強力な整合性のおかげで、クライアントは任意のエンドポイントで正常にコミットされたすべてのトランザクションの結果をすぐに確認できます。 このソリューションの主な機能を見てみましょう。 自動エンドポイント選択 – 最適な接続性を提供するために、このソリューションは利用可能なデータベースクラスターエンドポイントの動的リストを維持し、利用可能なエンドポイントに対して定期的にレイテンシーテストを実行し、応答時間に基づいてランク付けされたリストを作成します。このランキングは、設定ファイルで事前定義された優先度設定と組み合わされます。各エンドポイントへのレイテンシーに基づいて、各接続に最適なエンドポイントを選択します。 Route 53 ヘルスチェック – このソリューションは、 Route 53 ヘルスチェック と統合され、AWS グローバルインフラストラクチャを使用して包括的なヘルス監視を行います。このアプローチは、エンドポイントのヘルスを維持し、ルーティングの決定に情報を提供するための堅牢で柔軟なシステムを提供します。 自動接続フェイルオーバーサポート – 高可用性を維持し、アプリケーションのダウンタイムを最小限に抑えるために、ソリューションは各リージョナルデータベースクラスターエンドポイントのヘルスを継続的に監視します。現在のエンドポイントで問題が検出されると、クライアント接続を正常な代替エンドポイントに自動的にリダイレクトします。これにより、特定のエンドポイントが到達不能な場合でも、クライアントアプリケーションは継続的なデータベースアクセスを維持します。このソリューションは、クライアントがデータベース接続を確立するリージョンを管理します。その結果、アプリケーションが手動介入なしに利用可能なエンドポイントにスムーズに移行するため、ユーザーエクスペリエンスへの中断が最小限に抑えられます。 次の図は、ソリューションのワークフローを示しています。 ワークフローには次のステップが含まれます。 クライアント (クラスターがデプロイされているいずれかのリージョンで実行) は、 get_connection() を呼び出して接続を開始します。その後、ライブラリは利用可能な DSQL エンドポイントを評価し、ヘルスとパフォーマンスメトリクスに基づいて最適な接続を確立します。 ライブラリは、リアルタイムのエンドポイントステータスについて Route 53 ヘルスチェックを参照します。これらのヘルスチェックは 30 秒間隔で実行され、エンドポイントの可用性に関するほぼ最新の情報を提供し、劣化または障害の兆候を継続的に監視します。 ヘルスチェックデータを使用して、ライブラリは正常なエンドポイントに接続します。プライマリエンドポイントが失敗した場合、システムは自動的に正常な代替エンドポイントにリダイレクトします。 前提条件 このソリューションをデプロイするには、次の前提条件を完了する必要があります。 マルチリージョン Aurora DSQL クラスターを作成 し、両方のリージョンの cluster id と endpoint の値をキャプチャします。 Python バージョン 3.10 以上がシステムにインストールされていることを確認します。ターミナルで次のコードを実行してインストールを確認します。 python3 --version 適切な DSQL アクセス権限を持つ AWS 認証情報を取得します。 AWS コマンドラインインターフェイス (AWS CLI) または環境変数を使用してこれらの認証情報を設定します。 システムが DSQL エンドポイントへのネットワークアクセスを持っていることを確認します。これには、 Amazon Virtual Private Cloud (VPC) 設定またはセキュリティグループの設定が含まれる場合があります。 AWS 認証情報に Route 53 ヘルスチェックを作成および管理する権限があることを確認します。 Python と依存パッケージのインストール、および AWS CLI の設定 次のステップを完了します。 リポジトリをクローンします。 git clone https://github.com/aws-samples/sample-multi-region-Endpoint-Routing-for-Aurora-DSQL.git cd sample-multi-region-Endpoint-Routing-for-Aurora-DSQL Python 環境をセットアップし、 venv という名前の新しい仮想環境を作成します。 python3 -m venv venv source venv/bin/activate # Windows の場合: venv\Scripts\activate このソリューションを実行するために必要な、ファイル requirements.txt 内の必要な依存関係をインストールします。 pip install -r requirements.txt AWS CLI を設定します。これにより、認証情報をグローバルに設定する便利な方法が提供されます。 aws login ターミナルのプロンプトに従います。コマンドは自動的にデフォルトのブラウザを開き、認証プロセスをガイドします。認証が成功すると、AWS CLI セッションは最大 12 時間有効になります。 設定ファイルと Route 53 ヘルスチェックのセットアップ GitHub リポジトリには、 dsql_config_with_healthchecks.json という名前の設定ファイルが含まれています。このファイルには、次の例のような構造があります。次のフィールドを変更する必要があります。 両方のリージョンについて、前提条件で記録したクラスター ID を使用して cluster_id フィールドを更新します。 hostname フィールドを、以前にキャプチャしたリージョナル DSQL エンドポイントに置き換えます。 { "endpoints": [ { "cluster_id": "<Your-cluster-id>", "region": "<cluster-region-1>", "hostname": "<Your-Cluster-endpoint>", "port": 5432, "health_check_id": "" }, { "cluster_id": "<Your-cluster-id>", "region": "<cluster-region-2>", "hostname": "<Your-Cluster-endpoint>", "port": 5432, "health_check_id": "" } ], "connection_settings": { "connect_timeout": 5, "application_name": "dsql-hybrid-router", "keepalives": 1, "keepalives_idle": 30, "keepalives_interval": 10, "keepalives_count": 3 } } ターミナルで次のコマンドを実行して、エンドポイントの Route 53 ヘルスチェックを作成します。 python3 hybrid_failover_approach.py --setup --config dsql_config_with_healthchecks.json このスクリプトのパラメータには次のものが含まれます。 –config – このパラメータは、設定ファイルへのパスを指定します。設定ファイルは、DSQL エンドポイントと接続設定に関する情報を含む JSON ファイル dsql_config_with_healthchecks.json です。 –setup – このパラメータは、Route 53 ヘルスチェックを作成し、設定ファイル dsql_config_with_healthchecks.json 内の各エンドポイントの health_check_id を更新します。 –test – このパラメータは、接続テストを実行するためのものです。 このスクリプトは、設定ファイルを読み取り、各エンドポイントの Route 53 にヘルスチェックを作成し、新しく作成されたヘルスチェック ID で設定ファイルを更新します。 health_check_id は、各エンドポイントに関連付けられた Route 53 ヘルスチェックの一意の識別子です。 { "endpoints": [ { "cluster_id": "<your-cluster-id-1>", "region": "us-east-1", "hostname": "<your-hostname-1.dsql.us-east-1.on.aws>", "port": 5432, "health_check_id": "57a713b9-a58f-4ae5-baaa-70cf62ca78eb" }, { "cluster_id": "<your-cluster-id-2>", "region": "us-east-2", "hostname": "<your-hostname-2.dsql.us-east-1.on.aws>", "port": 5432, "health_check_id": "37d3a545-2917-4e8f-9e44-f7d5e9b966a7" } ], "connection_settings": { "connect_timeout": 5, "application_name": "dsql-hybrid-router", "keepalives": 1, "keepalives_idle": 30, "keepalives_interval": 10, "keepalives_count": 3 } } Route 53 ヘルスチェックとクライアント側レイテンシールーティングによる接続テスト DSQL エンドポイントへの基本的な接続をテストするには、次のコマンドを実行します。このスクリプトは、最適なエンドポイント選択のためのクライアント側レイテンシー測定、信頼性の高いヘルス監視のための Route 53 ヘルスチェック、および継続的なサービス可用性を提供する自動フェイルオーバー機能を組み合わせています。 python3 hybrid_failover_approach.py --test --config dsql_config_with_healthchecks.json --database postgres --user admin Route 53 ヘルスチェックによるフェイルオーバーのテスト このテストは、障害シナリオをシミュレートし、システムが適切に応答することを検証します。次のコマンドでテストスクリプトを実行します。 python3 test_route53_failover.py --config dsql_config_with_healthchecks.json --database postgres --user admin このスクリプトは、アプリケーション (またはクライアント接続) のフェイルオーバーメカニズムを検証するための一連の操作を実行します。 まず、設定の優先順位によって決定された最適な利用可能なエンドポイントへの接続を確立します。 接続後、スクリプトは意図的にこのプライマリエンドポイントに関連付けられた Route 53 ヘルスチェックを無効にし、障害をシミュレートします。 次に、スクリプトはヘルスチェックステータスが AWS ネットワークを通じて伝播するのを待ち、実際の障害状態を再現します。 その後、スクリプトは新しい接続の作成を試み、プライマリの障害シミュレーションにより、セカンダリエンドポイントにフェイルオーバーするはずです。 この期間中、システムがセカンダリエンドポイントへのフェイルオーバーに成功したことを検証し、プライマリエンドポイントのシミュレートされた障害にもかかわらず、継続的な動作を確認します。 フェイルオーバーの成功を確認した後、スクリプトはプライマリエンドポイントのヘルスチェックを再度有効にし、復元されたプライマリエンドポイントへの接続が再び確立できることを検証します。 python3 test_route53_failover.py --config dsql_config_with_healthchecks.json --database postgres --user admin; 2025-05-21 19:03:52,864 - main - INFO - === STEP 1: Testing connection under normal conditions === 2025-05-21 19:03:52,866 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json 2025-05-21 19:03:52,879 - botocore.credentials - INFO - Found credentials in environment variables. 2025-05-21 19:03:52,982 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints 2025-05-21 19:03:54,055 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: 16/16 healthy observations 2025-05-21 19:03:54,055 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: Healthy 2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations 2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy 2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2 2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - Endpoint latency comparison: 2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - 1. xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws - Latency: 0.002422s, Priority: 1, Region: us-east-2 2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - 2. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.012726s, Priority: 2, Region: us-east-1 2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - Selected best endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.002422s, priority: 1) 2025-05-21 19:03:55,058 - main - INFO - Best endpoint selected: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.002422s) 2025-05-21 19:03:55,058 - main - INFO - Health check ID: a4709bfe-bc41-4afc-9f55-4919ee884b7c 2025-05-21 19:03:55,058 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2 2025-05-21 19:03:55,100 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws in us-east-2 2025-05-21 19:03:55,101 - dsql_hybrid_manager - INFO - Generated token preview: jiabuacbso...a4e75aa0f9 2025-05-21 19:03:55,101 - dsql_hybrid_manager - INFO - Connecting to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001538s, region: us-east-2, priority: 1) 2025-05-21 19:03:55,344 - dsql_hybrid_manager - INFO - Successfully connected to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:03:55,344 - main - INFO - Connected to: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:03:55,344 - main - INFO - Running query iteration 1/1 2025-05-21 19:03:55,451 - main - INFO - Result: ('PostgreSQL 16',) 2025-05-21 19:03:55,451 - main - INFO - Query execution time: 106.33ms 2025-05-21 19:03:55,451 - main - INFO - Average query execution time over 1 iterations: 106.33ms 2025-05-21 19:03:55,451 - main - INFO - Connection closed 2025-05-21 19:03:55,452 - main - INFO - === STEP 2: Simulating failure of the primary endpoint's health check: a4709bfe-bc41-4afc-9f55-4919ee884b7c === 2025-05-21 19:03:55,627 - main - INFO - Disabled health check a4709bfe-bc41-4afc-9f55-4919ee884b7c to simulate failure 2025-05-21 19:03:55,628 - main - INFO - Waiting 60 seconds for health check status to propagate... 2025-05-21 19:04:55,674 - main - INFO - === STEP 3: Testing connection with primary endpoint health check failure === 2025-05-21 19:04:55,674 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json 2025-05-21 19:04:55,684 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints 2025-05-21 19:04:55,796 - dsql_hybrid_manager - ERROR - Error checking Route 53 health status for a4709bfe-bc41-4afc-9f55-4919ee884b7c: An error occurred (InvalidInput) when calling the GetHealthCheckStatus operation: Invalid parameter : The specified health check has a special status of always healthy. GetHealthCheckStatus can't return the status of one of these special health checks. 2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations 2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy 2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Found 1 healthy endpoints out of 2 2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - Endpoint latency comparison: 2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - 1. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.013187s, Priority: 2, Region: us-east-1 2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - Selected best endpoint: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.013187s, priority: 2) 2025-05-21 19:04:56,837 - main - INFO - Best endpoint selected: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.013187s) 2025-05-21 19:04:56,837 - main - INFO - Health check ID: 46eca8a2-6a07-43e6-94fb-21f95fb11d5a 2025-05-21 19:04:56,878 - dsql_hybrid_manager - ERROR - Error checking Route 53 health status for a4709bfe-bc41-4afc-9f55-4919ee884b7c: An error occurred (InvalidInput) when calling the GetHealthCheckStatus operation: Invalid parameter : The specified health check has a special status of always healthy. GetHealthCheckStatus can't return the status of one of these special health checks. 2025-05-21 19:04:56,879 - dsql_hybrid_manager - INFO - Found 1 healthy endpoints out of 2 2025-05-21 19:04:56,918 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws in us-east-1 2025-05-21 19:04:56,919 - dsql_hybrid_manager - INFO - Generated token preview: e4abuacbso...238cb4c5fe 2025-05-21 19:04:56,919 - dsql_hybrid_manager - INFO - Connecting to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.011756s, region: us-east-1, priority: 2) 2025-05-21 19:04:57,234 - dsql_hybrid_manager - INFO - Successfully connected to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws 2025-05-21 19:04:57,234 - main - INFO - Connected to: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws 2025-05-21 19:04:57,234 - main - INFO - Running query iteration 1/1 2025-05-21 19:04:57,368 - main - INFO - Result: ('PostgreSQL 16',) 2025-05-21 19:04:57,368 - main - INFO - Query execution time: 133.73ms 2025-05-21 19:04:57,368 - main - INFO - Average query execution time over 1 iterations: 133.73ms 2025-05-21 19:04:57,368 - main - INFO - Connection closed 2025-05-21 19:04:57,369 - main - INFO - Failover successful! Switched from xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws 2025-05-21 19:04:57,369 - main - INFO - === STEP 4: Restoring original health check configuration === 2025-05-21 19:04:57,500 - main - INFO - Re-enabled health check a4709bfe-bc41-4afc-9f55-4919ee884b7c 2025-05-21 19:04:57,502 - main - INFO - Waiting 60 seconds for health check status to propagate... 2025-05-21 19:05:57,553 - main - INFO - === STEP 5: Testing connection after restoring health check === 2025-05-21 19:05:57,554 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json 2025-05-21 19:05:57,561 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints 2025-05-21 19:05:58,571 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: 16/16 healthy observations 2025-05-21 19:05:58,571 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: Healthy 2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations 2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy 2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Endpoint latency comparison: 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - 1. xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws - Latency: 0.001920s, Priority: 1, Region: us-east-2 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - 2. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.011219s, Priority: 2, Region: us-east-1 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Selected best endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001920s, priority: 1) 2025-05-21 19:05:59,815 - main - INFO - Best endpoint selected: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001920s) 2025-05-21 19:05:59,815 - main - INFO - Health check ID: a4709bfe-bc41-4afc-9f55-4919ee884b7c 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2 2025-05-21 19:05:59,862 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for.dsql.us-east-2.on.aws in us-east-2 2025-05-21 19:05:59,864 - dsql_hybrid_manager - INFO - Generated token preview: jiabuacbso...f42f2e31ea 2025-05-21 19:05:59,865 - dsql_hybrid_manager - INFO - Connecting to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001445s, region: us-east-2, priority: 1) 2025-05-21 19:06:00,099 - dsql_hybrid_manager - INFO - Successfully connected to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:06:00,099 - main - INFO - Connected to: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:06:00,099 - main - INFO - Running query iteration 1/1 2025-05-21 19:06:00,210 - main - INFO - Result: ('PostgreSQL 16',) 2025-05-21 19:06:00,210 - main - INFO - Query execution time: 110.73ms 2025-05-21 19:06:00,210 - main - INFO - Average query execution time over 1 iterations: 110.73ms 2025-05-21 19:06:00,211 - main - INFO - Connection closed 2025-05-21 19:06:00,211 - main - INFO - === ROUTE 53 FAILOVER TEST SUMMARY === 2025-05-21 19:06:00,211 - main - INFO - Primary endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:06:00,212 - main - INFO - Failover endpoint: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws 2025-05-21 19:06:00,212 - main - INFO - Restored endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:06:00,212 - main - INFO - RESULT: Route 53 failover test SUCCESSFUL! アプリケーションでの DSQL 接続マネージャーの使用 hybrid_failover_approach.py ファイルを入手したら、アプリケーションへの統合は簡単です。接続マネージャーは、データベース接続のドロップイン置換として設計されており、バックグラウンドプロセスや複雑なセットアップは必要ありません。 次のコードは、アプリケーションで接続マネージャーを使用する方法の一般的な例です。 from hybrid_failover_approach import DSQLHybridConnectionManager # アプリケーション起動時に一度初期化 db_manager = DSQLHybridConnectionManager(config_file="dsql_config_with_healthchecks.json") # 接続が必要な場所で使用 conn = db_manager.get_connection("postgres", "admin") まず、 dsql_config_with_healthchecks.json ファイルを変更して DSQL エンドポイントを設定します。 次のコードは、Flask アプリケーションでの実際の例を示しています。 from flask import Flask, jsonify from hybrid_failover_approach import DSQLHybridConnectionManager app = Flask(__name__) db_manager = DSQLHybridConnectionManager(config_file="dsql_config_with_healthchecks.json") @app.route('/users') def get_users(): # 最速で最も正常なエンドポイントに自動的に接続 conn = db_manager.get_connection("postgres", "admin") try: with conn.cursor() as cursor: cursor.execute("SELECT id, name, email FROM users") return jsonify(cursor.fetchall()) finally: conn.close() このアプローチの美しさはそのシンプルさにあります。バックグラウンドプロセスや複雑なインフラストラクチャを管理することなく、インテリジェントなルーティング、自動フェイルオーバー、ヘルス監視を実現できます。これは、DSQL クラスターに接続するためのよりスマートな方法です。 クリーンアップ ヘルスチェックを削除するには、セットアップ中に設定ファイルに追加されたヘルスチェック ID を使用して AWS CLI を使用します。 aws route53 delete-health-check --health-check-id <health-check-id> ヘルスチェック ID は、 dsql_config_with_healthchecks.json ファイルの各エンドポイントの health_check_id フィールドで確認できます。設定内の各ヘルスチェック ID に対して削除コマンドを実行します。 ヘルスチェック設定 DSQL 接続マネージャーでヘルスチェックの頻度をカスタマイズできます。 health_check_ttl=60, # ヘルスチェック結果を 60 秒間キャッシュ health_check_ttl パラメータは、指定された期間ヘルスチェック結果をキャッシュします。低い値 (< 60 秒) はより高速なフェイルオーバーを可能にしますが、Route 53 への API コールが増加します。一方、高い値は API 負荷を軽減しますが、問題の検出が遅れる可能性があります。60 秒から始めて、必要に応じて調整してください。 まとめ この記事では、自動クロスリージョン接続フェイルオーバーサポートを備えた Aurora DSQL 接続を管理する効果的な方法を提供するカスタムソリューションについて説明しました。このソリューションをデプロイすることで、最適なパフォーマンスと可用性を維持しながら、アプリケーションに信頼性の高いデータベース接続を提供できます。 ご自身のユースケースで このソリューション を試して、コメントでフィードバックを共有してください。 著者について Rajesh Kantamani Rajesh は、シニアデータベーススペシャリストソリューションアーキテクトです。お客様と協力して、Amazon Web Services 上でデータベースソリューションの設計、移行、最適化を行い、スケーラビリティ、セキュリティ、パフォーマンスに焦点を当てています。分散データベースへの情熱を持ち、組織がデータインフラストラクチャを変革するのを支援しています。 Sukhpreet Kaur Bedi Sukhpreet は、Amazon RDS/Aurora PostgreSQL エンジンに焦点を当てた AWS のシニアデータベーススペシャリストソリューションアーキテクトです。お客様が高可用性でスケーラブル、かつ安全なデータベースアーキテクチャを構築することで、AWS プラットフォーム上でイノベーションを起こすのを支援しています。 Raluca Constantin Raluca は、Amazon Aurora DSQL を専門とする AWS のシニアデータベースエンジニアです。18 年間のデータベース専門知識は、Oracle、MySQL、PostgreSQL、クラウドネイティブソリューションにわたり、データベースのスケーラビリティ、パフォーマンス、リアルタイムデータ処理に焦点を当てています。

本ブログは 2025 年 12 月 8 日に公開された AWS Blog “ IAM Policy Autopilot: An open-source tool that brings IAM policy expertise to builders and AI coding assistants ” を翻訳したものです。 本日 (2025 年 12 月 8 日)、AWS は IAM Policy Autopilot を発表しました。これは、AI コーディングアシスタントがベースラインとなる AWS Identity and Access Management (IAM) の IAM ポリシーを迅速に作成できるよう支援するオープンソースの静的解析ツールです。作成されたポリシーは、アプリケーションの成長に合わせて継続的にレビュー・改善できます。IAM Policy Autopilot はコマンドラインツールおよび Model Context Protocol (MCP) サーバーとして利用可能です。アプリケーションコードをローカルで解析し、アプリケーションにアタッチする IAM ロールのアクセスを制御するアイデンティティベースのポリシーを作成します。IAM Policy Autopilot を導入することで、ビルダーはアプリケーションコードの作成に集中でき、 Amazon Web Services (AWS) での開発を加速し、IAM ポリシーの作成やアクセス問題のトラブルシューティングにかかる時間を節約できます。 AWS で開発するビルダーは、開発を加速してビジネスにより早く価値を届けたいと考えており、そのために Kiro、Claude Code、Cursor、Cline などの AI コーディングアシスタントをますます活用しています。IAM 権限に関して、ビルダーには 3 つの課題があります。1 つ目は、ビルダーは権限の理解、IAM ポリシーの作成、権限関連のエラーのトラブルシューティングに時間を取られ、アプリケーション開発に集中しづらいことです。2 つ目は、AI コーディングアシスタントはアプリケーションコードの生成には優れていますが、IAM の細かなニュアンスには苦労しており、複雑なクロスサービス依存関係の権限要件を捉えた信頼性の高いポリシーを生成するためのツールを必要としていることです。3 つ目は、ビルダーと AI アシスタントの両方が、AWS ドキュメントを手動で確認することなく、最新の IAM 要件と統合アプローチを把握し続ける必要があることです。理想的には、IAM の専門知識を常に最新に保つ単一のツールを通じて実現できることが望ましいです。 IAM Policy Autopilot は、これらの課題に 3 つの方法で対処します。まず、アプリケーションの決定論的コード解析を実行し、コードベース内の実際の AWS SDK 呼び出しに基づいて必要なアイデンティティベース の IAM ポリシーを生成します。これにより、初期のポリシー作成プロセスが高速化され、トラブルシューティング時間が短縮されます。次に、IAM Policy Autopilot は MCP を通じて AI コーディングアシスタントに正確で信頼性の高い IAM ポリシーを提供し、ポリシーエラーにつながることが多い AI のハルシネーションを防ぎ、生成されたポリシーが構文的に正しく有効であることを検証します。3 つ目に、IAM Policy Autopilot は定期的に更新され、新しい AWS サービス、権限、サービス間連携のパターンに対応します。そのため、ビルダーも AI アシスタントも、ドキュメントを手動で調べることなく最新の IAM 要件にアクセスできます。 本ブログでは IAM Policy Autopilot を使って開発中にコードを解析し、アイデンティティベースの IAM ポリシーを生成する流れを紹介します。IAM Policy Autopilot が AI コーディングアシスタントとシームレスに統合してデプロイ時に必要なベースラインポリシーを作成する方法と、ビルダーがコマンドラインインターフェイス (CLI) ツールを通じて IAM Policy Autopilot を直接使用する方法も説明します。また、IAM Policy Autopilot を開発ワークフローに組み込むためのベストプラクティスと考慮事項についてもガイダンスを提供します。IAM Policy Autopilot のセットアップは、GitHub リポジトリにアクセスして行えます。 IAM Policy Autopilot の仕組み IAM Policy Autopilot は、アプリケーションコードを解析し、アプリケーション内の AWS SDK 呼び出しに基づいてアイデンティティベースの IAM ポリシーを生成します。テスト中に権限がまだ不足している場合、IAM Policy Autopilot はこれらのエラーを検出し、解消するために必要なポリシーを追加します。IAM Policy Autopilot は、Python、Go、TypeScript の 3 つの言語で記述されたアプリケーションをサポートしています。 ポリシーの作成 IAM Policy Autopilot のコア機能は、一貫性のある信頼性の高い結果でアイデンティティベースの IAM ポリシーを生成する決定論的コード解析です。SDK から IAM へのマッピングに加えて、IAM Policy Autopilot は AWS サービス間の複雑な依存関係を理解します。 s3.putObject() を呼び出す場合、IAM Policy Autopilot は Amazon Simple Storage Service (Amazon S3) の権限 ( s3:PutObject ) だけでなく、暗号化シナリオで必要になる可能性のある AWS Key Management Service (AWS KMS) の権限 ( kms:GenerateDataKey ) も含めます。IAM Policy Autopilot はクロスサービス依存関係と一般的な使用パターンを理解し、この初期パスで PutObject API に関連するこれらの権限を意図的に追加するため、暗号化設定に関係なく、最初のデプロイからアプリケーションが正しく機能します。 Access Denied のトラブルシューティング 権限が作成された後、テスト中に Access Denied エラーが発生した場合、IAM Policy Autopilot はこれらのエラーを検出し、即座にトラブルシューティングを提供します。有効にすると、AI コーディングアシスタントは IAM Policy Autopilot を呼び出して拒否を分析し、対象を絞った IAM ポリシーの修正を提案します。分析と提案された変更をレビューして承認すると、IAM Policy Autopilot が権限を更新します。 MCP と CLI のサポート IAM Policy Autopilot は、さまざまな開発ワークフローに適合するように 2 つのモードで動作します。MCP サーバーとして、 Kiro 、 Amazon Q Developer 、Cursor、Cline、Claude Code などの MCP 互換コーディングアシスタントと統合します。また、IAM Policy Autopilot をスタンドアロンの CLI ツールとして使用して、ポリシーを直接生成したり、不足している権限を修正したりすることもできます。どちらのアプローチでも同じポリシー作成とトラブルシューティング機能が提供されるため、ワークフローに最適な統合方法を選択できます。 IAM Policy Autopilot 使用のウォークスルー このセクションでは、実践的な例を通じて IAM Policy Autopilot の MCP サーバー機能を紹介します。AWS KMS のカスタマーマネージドキーを使用したサーバーサイド暗号化で Amazon S3 にドキュメントを保存するファイルアップロードアプリケーションを作成します。このブログでは Cline を使用しますが、IAM Policy Autopilot は MCP 互換のコーディングアシスタントで動作します。 前提条件とセットアップ IAM Policy Autopilot は uv または pip を使用してインストールできます。最も簡単な方法は、 uvx iam-policy-autopilot を実行して uv でインストールし、MCP クライアント設定ファイルで MCP サーバーを以下のように設定することです。 pip を使用して IAM Policy Autopilot をインストールする場合、MCP 設定は異なることに注意してください。 { "mcpServers": { "iam-policy-autopilot": { "command": "uvx", "args": ["iam-policy-autopilot", "mcp-server"], "env": { "AWS_PROFILE": "your-profile-name", "AWS_REGION": "us-east-1" } "disabled": false, "autoApprove": [] } } } 安全なファイルアップロード Lambda 関数の作成 このセクションでは、アプリケーションをゼロから作成する手順を説明します。開発者、Cline、IAM Policy Autopilot 間のやり取りを紹介し、Cline へのガイダンスの提供方法と、Cline がバックグラウンドで IAM Policy Autopilot を呼び出して IAM ポリシーを生成し、アプリケーションをデプロイする流れを紹介します。 訳注: 以下のやり取りでは、「ユーザー:」は開発者が AI コーディングアシスタントに入力するプロンプトを、「Cline:」は AI アシスタントからの応答を示しています。 1. ビルダーが要件を説明する ユーザー: S3 にファイルをアップロードする Lambda 関数を作成したいです。ファイルは AWS KMS のカスタマーマネージドキーで暗号化する必要があります。構築を手伝ってもらえますか? 2. Cline がソリューションの計画を開始する Cline: 安全なファイルアップロード Lambda 関数の作成をお手伝いします。以下のように分解してみましょう。 ファイルアップロードを処理する Lambda 関数を作成する AWS KMS のカスタマーマネージドキーで暗号化を使用した S3 統合をセットアップする 必要な IAM 権限を作成する AWS CDK を使用してインフラストラクチャを構築する まず Lambda 関数のコードを書くことから始めましょう。 3. Cline が AWS Lambda 関数のコードを作成する Cline は、パーティション、AWS リージョン、AWS アカウント ID など、デプロイに必要な認証情報の入力も求めます。 次に Cline は uploadHandler.js ファイルを作成します。 const { S3Client, PutObjectCommand } = require('@aws-sdk/client-s3'); const s3Client = new S3Client({ region: 'us-west-2' }); exports.handler = async (event) => { const { fileName, fileContent } = JSON.parse(event.body); const putObjectParams = { Bucket: process.env.BUCKET_NAME, Key: fileName, Body: fileContent, ServerSideEncryption: 'aws:kms', SSEKMSKeyId: process.env.KMS_KEY_ID }; try { await s3Client.send(new PutObjectCommand(putObjectParams)); return { statusCode: 200, body: JSON.stringify({ message: 'File uploaded successfully' }) }; } catch (error) { return { statusCode: 500, body: JSON.stringify({ error: error.message }) }; } }; 4. Cline が IAM ポリシーの作成が必要だと判断し、IAM Policy Autopilot を検出する Cline: 次に、この Lambda 関数に適切な権限を持つ IAM ロールを作成する必要があります。IAM ポリシーの作成に役立つツールが利用可能かどうか確認してみましょう。 Cline は IAM Policy Autopilot MCP サーバーにポリシー作成機能があることを検出し、それを呼び出します。 Request Type: CallToolRequest Method: CallToolRequestMethod Params: Name: "generate_application_policies" Arguments: account: "123456789012" partition: "aws" region: "us-west-2" source_files: [ "/Users/user/workspace/uploadHandler.js" ] Extensions: Extensions 5. IAM Policy Autopilot がコードを解析してポリシーを生成する IAM Policy Autopilot はコードをスキャンし、アプリケーションコード内の PutObjectCommand を識別します。これは Amazon S3 API コールとして認識されます。AWS のお客様の一般的な使用パターンに基づいて、IAM Policy Autopilot は暗号化権限と CloudWatch ログ権限も提案します。 IAM Policy Autopilot は、暗号化シナリオで必要になる可能性のある AWS KMS 権限を含む、Amazon S3 PutObject に必要な権限を含むアイデンティティベースの IAM ポリシーを生成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::*/*" }, { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-west-2:123456789012:key/*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-west-2:123456789012:*" } ] } 6. Cline が完全な CloudFormation インフラストラクチャを作成する Cline: 完璧です! IAM Policy Autopilot が Lambda 関数に必要な包括的な権限を生成しました。S3 PutObject 権限、暗号化シナリオに対応する KMS 権限、関数実行用の CloudWatch Logs 権限が含まれています。次に完全な CloudFormation テンプレートを作成します。 Cline は IAM Policy Autopilot が提供した権限を使用して AWS CloudFormation テンプレートを生成します。 AWSTemplateFormatVersion: "2010-09-09" Resources: UploadEncryptionKey: Type: AWS::KMS::Key Properties: KeyPolicy: Statement: Effect: Allow Principal: AWS: !Sub "arn:aws:iam::123456789012:root" Action: "kms:*" Resource: "*" SecureUploadBucket: Type: AWS::S3::Bucket UploadLambdaRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: UploadPolicy PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - s3:PutObject Resource: !Sub "${SecureUploadBucket}/*" - Effect: Allow Action: - kms:Encrypt - kms:GenerateDataKey Resource: !GetAtt UploadEncryptionKey.Arn - Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: "arn:aws:logs:*:*:*" UploadHandler: Type: AWS::Lambda::Function Properties: Runtime: nodejs18.x Handler: uploadHandler.handler Code: ZipFile: | // Lambda function code would be deployed separately Role: !GetAtt UploadLambdaRole.Arn Environment: Variables: BUCKET_NAME: !Ref SecureUploadBucket KMS_KEY_ID: !Ref UploadEncryptionKey この例は、IAM Policy Autopilot が開発ワークフローにシームレスに統合され、呼び出し時にコーディングアシスタントに最新かつ正確な IAM ポリシーを提供し、ユーザーの作業負担を軽減する様子を示しています。 今回のウォークスルーでは、IAM Policy Autopilot に解析用の単一ファイルを渡していますが、静的コード解析を実行して IAM ポリシーを作成する際には複数のファイルを取り込むことができます。 CLI の直接使用: シンプルなポリシー作成 CLI を使えば、AI コーディングアシスタントなしでも同じ解析機能を直接利用できます。 1. 既存のコードから IAM ポリシーを生成する この例では、同じ uploadHandler.js ファイルがあり、デプロイ用のアイデンティティベースの IAM ポリシーを生成したいとします。 $ iam-policy-autopilot generate-policy --region us-west-2 --account 123456789012 --pretty Users/user/workspace/uploadHandler.js 2. IAM Policy Autopilot がコードを解析してポリシーを出力する { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::*/*" }, { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-west-2:123456789012:key/*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-west-2:123456789012:*" } ] } 3. ビルダーが生成された IAM ポリシーを使用する このポリシーを CloudFormation テンプレート、 AWS Cloud Development Kit (AWS CDK) スタック、または Terraform 設定に直接コピーできます。 この CLI アプローチは、MCP サーバーと同じコード解析とクロスサービス権限検出を提供しますが、コマンドラインワークフローや自動化されたデプロイパイプラインに適しています。 ベストプラクティスと考慮事項 開発ワークフローで IAM Policy Autopilot を使用する際は、以下のプラクティスに従うことで、セキュリティのベストプラクティスを維持しながらメリットを最大化できます。 IAM Policy Autopilot で生成されたポリシーから始めて改善する IAM Policy Autopilot は、最小権限よりも機能性を優先したポリシーを生成し、最初のデプロイからアプリケーションが正常に動作するよう支援します。これらのポリシーは、アプリケーションが成熟するにつれて改善できる出発点となります。デプロイ前に、生成されたポリシーがセキュリティ要件に合致しているかレビューしてください。 IAM Policy Autopilot の解析範囲を理解する IAM Policy Autopilot は、コード内の直接的な AWS SDK 呼び出しの識別に優れており、ほとんどの開発シナリオに対応した IAM ポリシーを提供します。ただし、いくつかの制限があることを覚えておいてください。例えば、コードが s3.getObject ( bucketName ) を呼び出し、 bucketName がランタイムで決定される場合、IAM Policy Autopilot は現在どのバケットにアクセスされるかを予測しません。AWS SDK をラップするサードパーティライブラリを使用するアプリケーションでは、IAM Policy Autopilot が生成した解析を手動のポリシーレビューで補完する必要がある場合があります。現在、IAM Policy Autopilot は IAM ロールとユーザーのアイデンティティベースのポリシーに焦点を当てており、S3 バケットポリシーや KMS キーポリシーなどのリソースベースポリシーは作成しません。 既存の IAM ワークフローと統合する IAM Policy Autopilot は、包括的な IAM 戦略の一部として最も効果を発揮します。IAM Policy Autopilot を使用して機能的なポリシーを迅速に生成し、継続的な改善には他の AWS ツールを活用してください。例えば、 AWS IAM Access Analyzer は、時間の経過とともに未使用の権限を特定するのに役立ちます。この組み合わせにより、迅速なデプロイから最小権限の最適化までのワークフローが実現します。 IAM Policy Autopilot とコーディングアシスタントの境界を理解する IAM Policy Autopilot は、コードの決定論的解析に基づいて特定のアクションを含むポリシーを生成します。MCP サーバー統合を使用する場合、AI コーディングアシスタントはこのポリシーを受け取り、Infrastructure as Code (IaC) テンプレートを作成する際に変更を加える場合があります。例えば、アシスタントがコードの追加コンテキストに基づいて、特定のリソース Amazon Resource Name (ARN) を追加したり、KMS キー ID を含めたりすることがあります。これらの変更は、IAM Policy Autopilot が提供する静的解析からではなく、コーディングアシスタントがより広いコードコンテキストを解釈した結果です。デプロイ前に、コーディングアシスタントが生成したコンテンツがセキュリティ要件を満たしているか必ずレビューしてください。 適切な統合アプローチを選択する 開発中の会話でシームレスにポリシーを作成するために AI コーディングアシスタントと連携する場合は、MCP サーバー統合を使用してください。CLI ツールは、バッチ処理や直接的なコマンドライン操作を好む場合に適しています。どちらのアプローチも同じ解析機能を提供するため、ご自身の開発ワークフローに合わせて選択してください。 まとめ IAM Policy Autopilot は、IAM ポリシー管理を開発上の課題から、既存のワークフロー内でシームレスに機能する自動化された機能へと変革します。IAM Policy Autopilot の決定論的コード解析とポリシー作成機能を活用することで、ビルダーは AWS で正常に実行するために必要な権限があることを確信しながら、アプリケーションの作成に集中できます。 MCP サーバー統合を通じて AI コーディングアシスタントと連携する場合でも、CLI を直接使用する場合でも、IAM Policy Autopilot は同じ解析機能を提供します。このツールは、AWS KMS 暗号化を伴う S3 操作などの一般的なクロスサービス依存関係を識別し、構文的に正しいポリシーを生成し、AWS が提供する拡大するサービスカタログに対応して最新の状態を維持するため、ビルダーと AI アシスタントの両方の負担を軽減します。 IAM Policy Autopilot を使えば、ビルダーが IAM の専門家になる必要はなく、わかりにくい権限エラーに悩まされることもありません。AWS 開発がより身近で効率的になります。その結果、デプロイサイクルが短縮され、権限関連の不具合が減少し、アクセス問題のデバッグではなくビジネス価値の創出により多くの時間を費やせるようになります。 開発ワークフローにおける IAM ポリシー作成の手間を減らしませんか？IAM Policy Autopilot は追加費用なしで今すぐ利用可能です。 GitHub リポジトリ からダウンロードして IAM Policy Autopilot を始め、自動化されたポリシー作成が AWS 開発をどのように加速できるかを体験してください。IAM Policy Autopilot の機能とカバレッジを拡大し続ける中で、みなさまからのフィードバックとコントリビュートをお待ちしています。 Diana Yin Diana は AWS IAM Access Analyzer のシニアプロダクトマネージャーです。顧客インサイト、製品戦略、テクノロジーの交差点で問題を解決することに注力しています。仕事以外では、水彩画で自然の風景を描いたり、ウォーターアクティビティを楽しんでいます。University of Michigan で MBA を、Harvard University で教育学修士号を取得しています。 Luke Kennedy Luke は AWS Identity and Access Management (IAM) のプリンシパルソフトウェア開発エンジニアです。Rose-Hulman Institute of Technology でコンピュータサイエンスとソフトウェアエンジニアリングの学位を取得後、2013 年に IAM 組織に加わりました。AWS 以外では、猫と過ごしたり、ホームラボやネットワークを過度に複雑にしたり、パンプキン味のものを追求したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 10 月 2 日に公開された AWS Blog “ Defending against supply chain attacks like Chalk/Debug and the Shai-Hulud worm ” を翻訳したものです。 オープンソースパッケージを利用することで、開発を加速できます。npm、PyPI、Maven Central、NuGet などで提供されている一般的なライブラリやモジュールを使用することで、チームは自社固有のコード作成に集中できます。これらのオープンソースパッケージレジストリは何百万ものパッケージをホストしており、毎日何千ものプログラムに組み込まれています。 これらの重要なサービスは、残念ながら、大規模にコードを配布しようとする脅威アクターの格好の標的となっています。これらのサービスのいずれかでパッケージを侵害できれば、その 1 つのアクションで自動的に何千もの他のシステムに影響を与えることができます。 2025 年 9 月 8 日: Chalk と Debug の侵害 この侵害は、npm の信頼されたメンテナーの認証情報が不正に取得されたことから始まりました。ソーシャルエンジニアリングで認証情報を窃取した後、18 の人気パッケージ (Chalk、Debug、ansi-styles、supports-color など) に悪意あるペイロードが注入されました。 このペイロードは、暗号通貨のアクティビティを密かに監視し、攻撃者の利益のためにトランザクションを改ざんするように設計されていました。 これらのパッケージは合わせて毎週推定 20 億回ダウンロードされています。メンテナーと npm 運営による迅速な対応があったにもかかわらず、侵害されたバージョンが利用可能だった数時間の間に、重大な影響を受けた可能性があります。この期間中にパッケージをダウンロードしたビルドシステムや、リモートでパッケージを読み込んだサイトは、脆弱な状態になった可能性があります。 この巧妙なマルウェアは、高度な偵察技術を備えており、実行環境に応じて最も効果的な攻撃ベクトルを選択するよう動作を適応させました。 2025 年 9 月 15 日: Shai-Hulud ワーム 翌週、Shai-Hulud ワームが npm の信頼チェーンを通じて自律的に拡散し始めました。このマルウェアは、開発者の環境での最初の足がかりを使用して、npm トークン、GitHub パーソナルアクセストークン、クラウド認証情報など、さまざまな認証情報を収集します。 可能な場合、マルウェアは収集した認証情報を公開します。npm トークンが利用可能な場合、ワームを追加のペイロードとして含む更新されたパッケージを公開します。侵害されたパッケージは、感染を継続的に拡散するために postinstall スクリプトとしてワームを実行します。 この自己増殖方法に加えて、ワームはアクセスを取得した GitHub リポジトリの改ざんも試みます。Shai-Hulud は、すべてのリポジトリアクティビティで実行される悪意のあるワークフローを設定し、コードを継続的に窃取し続けます。 このエクスプロイトは、技術的に高度であると同時に、開発者が信頼してパッケージをインストールする流れを巧みに悪用していることを示しました。標準的な npm インストールプロセスを使用することで、ワームは開発者に期待される動作パターン内で動作するため、検出がより困難になります。 このエクスプロイトの最初の 24 時間以内に、180 を超える npm パッケージが侵害され、再び何百万ものシステムに影響を与える可能性がありました。両方のインシデントは、サプライチェーン侵害の潜在的な規模を示しています。 このようなインシデントへの対応方法 侵害されたパッケージが本番環境に入った場合は、問題を解決するためにアクティブなインシデントに対する標準的なインシデント対応プロセスに従う必要があります。 開発環境をスキャンするには、以下の手順をお勧めします。 依存関係の監査 : Chalk と Debug パッケージを削除するか、クリーンなバージョンにアップグレードし、Shai-Hulud に感染したパッケージがないか確認する シークレットのローテーション : npm トークン、GitHub パーソナルアクセストークン、API キーが侵害されている可能性があると想定し、認証情報を直ちにローテーションして再発行する ビルドパイプラインの監査 : 不正な GitHub Actions ワークフローや予期しないスクリプトの挿入がないか確認する Amazon Inspector の使用 : Amazon Inspector の検出結果で Chalk/Debug エクスプロイトまたは Shai-Hulud ワームの影響を受けていないか確認し、推奨される修復を行う サプライチェーンの強化 : SBOM (ソフトウェア部品表) を適用し、パッケージバージョンを固定し、権限を限定したトークンを採用し、CI/CD 環境を分離する Amazon Inspector が OpenSSF とともにオープンソースセキュリティを強化する仕組み AWS は、Open Source Security Foundation (OpenSSF) とのパートナーシップを通じて、Amazon Inspector の悪意あるパッケージ検出システムからの検出結果をコミュニティと定期的に共有しています。Amazon Inspector は、Open Source Vulnerability (OSV) 形式を使用して、このタイプの脅威インテリジェンスを共有する自動化されたプロセスを採用しています。 Amazon Inspector は、悪意あるパッケージを特定するために、多角的な分析技術を組み合わせた多層検出アプローチを採用しています。このアプローチは、既知の攻撃パターンと新しい脅威の両方に対する堅牢な保護を提供します。 YARA ルールの広範なライブラリを使用した静的解析から始めて、Amazon Inspector はパッケージコンテンツ内の疑わしいコードパターン、難読化技術、既知の悪意あるシグネチャを特定できます。それに基づいて、システムは動的解析と動作監視を使用して、回避技術が使用されていても脅威を特定します。最後の分析セットは、AI と機械学習モデルを使用してコードのセマンティクスを分析し、パッケージ内の意図された目的と疑わしい機能を判断します。 この多段階アプローチにより、Amazon Inspector は誤検知を最小限に抑えながら高い検出精度を維持でき、正当なパッケージが誤ってフラグ付けされず、巧妙な脅威が確実に特定され軽減されるようにします。 これらの脅威がオープンソースパッケージで検出されると、システムはこの脅威インテリジェンスを OpenSSF と共有するための自動化されたワークフローを開始します。このワークフローは、検証された脅威インテリジェンスを OpenSSF に送信し、コミュニティデータベースにマージされる前に OpenSSF のメンテナーによって厳格にレビューされます。そこで、公式の MAL-ID (悪意あるパッケージ識別子) が付与されます。 このプロセスは、こうした脅威検出をできるだけ早くコミュニティと検証および共有し、他のセキュリティツールや研究者が Amazon Inspector の検出機能の恩恵を受けられるようにするのに役立ちます。 今後の展望 Chalk/Debug と Shai-Hulud ワームは、新しいタイプのエクスプロイトではありません。残念ながら、この攻撃ベクトルを使用した最新のインシデントにすぎません。オープンソースリポジトリは開発者にとって素晴らしいリソースであり、多くのチームがより迅速にイノベーションを実現するのに役立っています。オープンソースコミュニティは、このようなインシデントの影響を軽減するために懸命に取り組んでいます。 そのため、AWS は OpenSSF とパートナーシップを結び、侵害されたか悪意を持って作成された 40,000 を超える npm パッケージを特定したレポートを提供してきました。AWS は、Amazon Inspector が安全かつセキュアに構築するための優れたツールであると考えています。すべての方に使用していただきたいと思っていますが、OpenSSF のような取り組みへの AWS の貢献がコミュニティ全体のセキュリティ向上に役立っていることを誇りに思っています。 この投稿に関するご質問がある場合は、 Amazon Inspector タグ付きの AWS re:Post に質問をするか、 AWS サポート にお問い合わせください。 Chi Tran Chi は Amazon Web Services のシニアセキュリティリサーチャーで、オープンソースソフトウェアサプライチェーンセキュリティを専門としています。オープンソースソフトウェアの悪意あるパッケージを検出する Amazon Inspector のエンジンの研究開発をリードしています。Amazon Inspector の SME として、複雑なセキュリティ実装や高度なユースケースについてお客様に技術的なガイダンスを提供しています。専門分野は、クラウドセキュリティ、脆弱性調査、アプリケーションセキュリティです。OSCP、OSCE、OSWE、GPEN などの業界認定資格を保有し、複数の CVE を発見し、オープンソースセキュリティイノベーションに関する特許を出願中です。 Charlie Bacon Charlie は AWS の Amazon Inspector セキュリティエンジニアリングおよびリサーチ責任者です。Amazon Inspector やその他の Amazon Security 脆弱性管理ツールを支える脆弱性スキャンおよびインベントリ収集サービスのチームをリードしています。AWS に入社する前は、金融およびセキュリティ業界で 20 年間、リサーチと製品開発の両方でシニアロールを務めていました。 Nirali Desai Nirali はクラウドセキュリティのプロダクトリーダーで、現在 Amazon Web Services (AWS) でアプリケーションセキュリティイニシアチブを推進しています。AWS に入社する前は、Palo Alto Networks、Zscaler、Cisco Tetration で重要な役割を担い、Secure Access Secure Edge (SASE)、エンドユーザーセキュリティ、ワークロード保護、ゼロトラストセキュリティソリューションの構築に注力していました。進化するサイバー脅威から防御するスケーラブルなセキュリティ製品の構築に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

新年あけましておめでとうございます。Amazon Connect ソリューションアーキテクトの坂田です。 2025年12月には AWS re:Invent 2025 がラスベガスで開催され、Amazon Connect に関する多くの革新的な発表がありました。本ブログでは、2025年11月と12月に発表された Amazon Connect と Amazon Lex のアップデートをまとめました(新年合併号です！)。今年も皆さんのお役に立つ内容をお届けしてまいりますので、どうぞよろしくお願いいたします。 目次 注目のアップデートについて AWS Workshop のご紹介 2025年11月・12月のアップデート一覧 AWS Contact Center Blog のご紹介 1. 注目のアップデートについて AWS re:Invent 2025 では、Amazon Connect のアップデートが以下の4つの主要カテゴリに整理されました： Action with AI: Beyond simple automation （AI によるアクション：単純な自動化を超えて） Elevate your workforce: True human+AI partnership （ワークフォースの向上：真の人間+ AI パートナーシップ） Transform data into relationships: Proactive intelligence （データを関係性に変換：プロアクティブインテリジェンス） Accelerate Outcomes: Confidence Through Observability （成果の加速：可視性による信頼性） 本セクションでは、これらのカテゴリから特に注目すべき2つのテーマをご紹介します。 テーマ1: AI エージェントの大幅な強化とオブザーバビリティの向上 2025年11月・12月期間中、Amazon Connect AI エージェントは革新的な進化を遂げました。 Model Context Protocol (MCP) サポート により、AI エージェントは豊富なコンテキスト情報を活用した高精度な応答が可能になり、 Amazon Nova Sonic との統合でリアルタイム会話 AI による自然で表現豊かな音声インタラクションを実現しています。さらに、 Amazon Bedrock Knowledge Bases との統合により、複数のナレッジソースを活用した包括的な情報提供が可能になりました。 これらの技術革新により、AI エージェントは注文状況確認、返金処理、顧客記録更新などの複雑なタスクを人的介入なしで自動実行できるようになり、従来の単純な質問応答を超えた知的な顧客支援を提供します。 また、AI エージェント活用の成功において重要なのは、継続的な監視と改善です。Amazon Connect は AI エージェントの分析・監視機能 をネイティブに搭載し、AI エージェントが関与した問い合わせ数、ハンドオフレート、会話ターン数、平均処理時間などの主要メトリクスをカスタマイズ可能なダッシュボードで提供。さらに、 自動パフォーマンス評価機能 により、セルフサービスインタラクションの品質を自動的に評価し、改善点を特定できます。 テーマ2: 顧客価値重視のプロアクティブエンゲージメント Amazon Connect Customer Profiles に新しい AI 活用予測インサイト機能 が追加され、5つの推奨アルゴリズム（「推奨」「類似アイテム」「よく一緒に購入される商品」「人気アイテム」「現在のトレンド」）により、顧客の行動パターンと対話履歴を分析したパーソナライズされた提案が可能になりました。 Amazon Connect Outbound Campaigns では、 マルチステップ・マルチチャネル顧客エンゲージメントジャーニービルダー により、複数のチャネルと複数のステップを組み合わせた洗練されたキャンペーンを構築できます。さらに、 新しいセグメンテーション機能 により、顧客データをより詳細にセグメント化し、真に価値のあるパーソナライズされた顧客体験を提供できるようになりました。 これらの機能により、企業は単なる一方的なマーケティングから脱却し、顧客の真のニーズに基づいたプロアクティブで価値あるエンゲージメントを実現できます。 2. AWS Workshop のご紹介 Amazon Connect の新機能を実際に体験しながら実装スキルを習得するための、AWS Workshop をご紹介します。これらのハンズオンワークショップでは、最新の AI 機能やコンタクトセンター管理機能を実際の環境で学習できます。 AI エージェント・セルフサービス関連ワークショップ Agentic AI on Amazon Connect を使った知的な顧客サービスの構築 エージェンティック AI の力を活用して顧客サービスを変革する没入型ワークショップです。ホテルチェーンの IT チームの立場に立ち、予約システムを革新的に変えて、シームレスでインテリジェントなセルフサービス体験を提供する実践的な学習を行います。 学習内容: 空き状況の確認、予約の作成、予約の変更ができるインテリジェントな AI エージェントの構築 Model Context Protocol (MCP) サーバーを使用した安全で拡張性の高いバックエンドの実装 AI の自動化と人間の専門知識を無理なく組み合わせた Amazon Connect フローの設計 様々な業界に適用できる、エージェンティック AI のパターンに関する実践的な経験 多言語・国際化ワークショップ Multilingual Contact Center with Amazon Connect さまざまな言語の好みを持つ多様なグローバル顧客基盤に対して効果的な顧客サポートを提供するための、多言語コンタクトセンターソリューションを構築するワークショップです。Amazon Connect の拡張性と AWS サービス統合を活用して、音声からテキストまでの真のオムニチャネル翻訳機能を実現する方法を学習します。 解決する課題: 従来のテキストベースサポート、サードパーティ翻訳サービス、多言語コンタクトセンターエージェントによるアプローチは、しばしば一貫性のない顧客体験と運用コスト増加を招きます。 革新的ソリューション – Voice to Voice 翻訳: 高度な音声認識と機械翻訳技術を活用して、エージェントと顧客間の音声会話のほぼリアルタイム翻訳を実現します。言語能力や追加スタッフィングを必要とせず、エージェントが顧客の好みの言語でコミュニケーションできるソリューションを開発できます。 技術的実装: 音声認識 : 顧客の話し言葉を音声認識技術でテキストに変換し、機械翻訳エンジンに送信 機械翻訳 : 顧客のテキストをエージェントの好みの言語にほぼリアルタイムで翻訳し、音声合成でスピーチに変換 双方向翻訳 : エージェントの応答も同様に処理し、顧客の言語に翻訳して音声で配信 シームレス統合 : Amazon Connect との統合により、エージェントは追加の努力や訓練なしで多言語での顧客対応が可能 使用技術: Amazon Connect Streams JS : 既存 Web アプリケーションと Amazon Connect の統合、Contact Control Panel (CCP) の埋め込み Amazon Connect RTC JS : Amazon Connect へのソフトフォンサポート提供、WebRTC プロトコル実装 対象チャネル: チャット、SMS、メール（拡張可能）などのテキストベース通信から音声まで、統一された顧客体験を提供 使用サービス: Amazon Connect、Amazon Translate、Amazon Transcribe、Amazon Polly、Amazon Cognito、Amazon Connect Streams JS、Amazon Connect RTC JS 3. 2025年11月・12月のアップデート一覧 AWS re:Invent 2025 では、Amazon Connect のアップデートを 4 つの主要カテゴリに整理して発表されました。以下、これらのカテゴリに基づいて 2025年11月・12月のアップデートをご紹介します。 注記 : re:Invent 期間中（11月30日）以外に発表されたアップデートについては、著者が re:Invent の 4 つのカテゴリフレームワークに基づいて分類したものです。 1. Action with AI: Beyond simple automation（AI によるアクション：単純な自動化を超えて） 自律型 AI エージェントとインテリジェントな自動化により、従来の単純な自動化を超えた高度な AI 機能を提供します。 Amazon Nova 2 Sonic でリアルタイム会話 AI を発表 （2025年12月２日） 概要 : Amazon Nova 2 Sonic がリアルタイム会話 AI 機能を提供開始。双方向音声ストリーミング、音声理解、適応的応答、中断処理、ナレッジグラウンディング、関数呼び出し、ノイズ耐性、多言語表現豊かな音声を特徴とする次世代の会話 AI 体験を実現します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京) 関連リソース : AWS ニュースブログ Amazon Nova Sonic ユーザーガイド Amazon Connect でより自然で表現豊かな適応型音声インタラクションによるエージェンティックセルフサービスを導入 （2025年11月30日） 概要 : より自然で表現豊かな適応型音声インタラクションを特徴とするエージェンティックセルフサービスを導入。Nova Sonic を活用した高度な音声 AI 体験を提供します。 利用可能リージョン : 米国東部 (バージニア北部) と米国西部 (オレゴン) 関連リソース : Nova Sonic Speech-to-Speech 設定ガイド Amazon Connect でサードパーティ音声認識・音声合成 AI モデルをサポート （2025年11月30日） 概要 : エンドカスタマーのセルフサービス向けにサードパーティの音声認識（STT）および音声合成（TTS）AI モデルのサポートを追加。より多様な音声技術の選択肢を提供します。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン ( Amazon Connect の無制限の AI を有効にする) 関連リソース : Amazon Connect でサードパーティーの音声プロバイダーを設定する Amazon Connect で複数のナレッジベースと Amazon Bedrock Knowledge Bases との統合をサポート （2025年11月30日） 概要 : 複数のナレッジベースのサポートと Amazon Bedrock Knowledge Bases との統合を提供。より包括的な知識管理と AI 支援機能を実現します。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : 生成 AI を活用したリアルタイムのエージェント支援のために Amazon Q in Connect を使用する Amazon Bedrock Knowledge Bases Amazon Connect で Model Context Protocol (MCP) サポートを開始（2025年11月30日） 概要 : Amazon Connect で Model Context Protocol (MCP) のサポートを開始。MCP により、AI エージェントがより豊富なコンテキスト情報を活用して、より正確で関連性の高い応答を提供できるようになります。 利用可能リージョン : リージョンごとの Amazon Connect 機能の提供状況 を参照 (※東京リージョンは利用可能) 関連リソース : Amazon Connect AI エージェント AI エージェントによる MCP ツールによる情報の取得とアクションの完了を有効にする Amazon Connect で AI 搭載インタラクションのメッセージストリーミングを提供 （2025年11月30日） 概要 : Amazon Connect が AI チャット対話でメッセージストリーミング機能を提供開始。この新機能により、Connect AI エージェントの応答が生成された時点で表示されるため、待ち時間が短縮され、カスタマーエクスペリエンスが向上します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アフリカ (ケープタウン) 関連リソース : AI を活用したチャットのメッセージストリーミングを有効にする Amazon Lex で自然言語理解の主要オプションとして LLM をサポート （2025年11月26日） 概要 : Amazon Lex が自然言語理解（NLU）の主要オプションとして大規模言語モデル（LLM）をサポート開始。より高度で柔軟な自然言語処理能力を提供し、複雑な会話パターンの理解を向上させます。 利用可能リージョン : Amazon Connect と Amazon Lex が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect セルフサービス Amazon Lex 開発者ガイド Amazon Lex で待機・継続機能を10の新言語に拡張 （2025年11月21日） 概要 : Amazon Lex の待機・継続機能を10の新しい言語に拡張。より多くの言語でユーザーが追加情報を収集している間に音声ボットやチャットボットは会話を一時停止し、準備ができたらシームレスに再開できるようになります。 利用可能リージョン : Amazon Lex が利用可能なすべての AWS リージョン 関連リソース : Amazon Lex サポート言語 2. Elevate your workforce: True human+AI partnership（ワークフォースの向上：真の人間+ AI パートナーシップ） AI とエージェントの協働により、エージェントの能力を向上させ、より効率的で効果的な顧客サービスを実現します。 Amazon Connect Chat でエージェントが開始するワークフローをサポート （2025年11月30日） 概要 : Amazon Connect Chat でエージェントが開始するワークフローをサポート開始。エージェントが顧客との会話中に特定のワークフローやプロセスを開始できるようになります。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アフリカ (ケープタウン) 関連リソース : アクティブなチャットセッション中にエージェント開始フローを有効にする Amazon Connect が Agentforce Service 向け AI エージェント支援と要約を提供 （2025年11月30日） 概要 : Salesforce Contact Center with Amazon Connect 向けの AI エージェント支援と要約機能を提供開始。Salesforce Agentforce Service 環境でのエージェント支援機能を強化し、より効率的な顧客サービスを実現します。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Salesforce Contact Center with Amazon Connect のドキュメント Amazon Connect でフローを使用した関連連絡先とケースのリンク簡素化 （2025年11月30日） 概要 : フローを使用して関連する連絡先をケースにリンクするプロセスを簡素化。より効率的なケース管理とコンタクト追跡を実現します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases 製品ページ Amazon Connect Cases 管理者ガイド Amazon Connect で AI 搭載ケース要約を提供 （2025年11月30日） 概要 : AI を活用したケース要約機能を提供開始。複雑なケースの内容を自動的に要約し、エージェントやマネージャーが迅速に状況を把握できるようにします。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases 製品ページ Amazon Connect Cases 管理者ガイド Amazon Connect でエージェント支援機能を強化 （2025年11月30日） 概要 : エージェント支援機能を全般的に強化。AI を活用したより高度な支援機能により、エージェントの生産性と顧客満足度を向上させます。 利用可能リージョン : リージョンごとの Amazon Connect 機能の提供状況 を参照 (※東京リージョンは利用可能) 関連リソース : Amazon Connect AI エージェント Amazon Connect 管理者ガイド Amazon Connect でビジネスユーザーがカスタム UI を作成してリアルタイムでコンタクトセンター設定を調整可能に （2025年11月30日） 概要 : ビジネスユーザーが技術リソースを必要とせずに、日常のコンタクトセンター運用をより詳細に制御できるようになりました。キュー、ルーティング動作、顧客体験設定をリアルタイムで調整するカスタム UI を作成する新機能により、エンタープライズグレードのガバナンスとセキュリティを維持しながら、変化する条件に即座に対応できます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : ビジネスユーザーのワークスペースを設定する Amazon Connect エージェントワークスペースでカスタムビジュアルテーマをサポート （2025年11月30日） 概要 : エージェントワークスペースでカスタムビジュアルテーマをサポート開始。組織のブランディングに合わせたインターフェースのカスタマイズが可能になります。 利用可能リージョン : Amazon Connect エージェントワークスペースは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、AWS GovCloud (米国西部) の各 AWS リージョンで利用できます。 関連リソース : Amazon Connect エージェントワークスペースをカスタマイズする エージェントワークスペース デベロッパーガイド Amazon Connect でエージェントがメール連絡先にフォローアップ返信を送信可能に （2025年11月21日） 概要 : Amazon Connect でエージェントがメール連絡先にフォローアップ返信を送信できる機能を提供開始。エージェントは顧客からのメールに対して、初回応答後も継続的なフォローアップメールを送信し、より包括的な顧客サポートを提供できるようになります。 利用可能リージョン : Amazon Connect Email は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) の各リージョンでご利用いただけます。 関連リソース : Amazon Connect で E メールを設定する Amazon Connect でマルチスキルエージェントスケジューリングをサポート （2025年11月21日） 概要 : Amazon Connect が複数のスキルを持つエージェントのスケジューリングをサポート開始。エージェントが複数の専門分野やスキルセットを持つ場合に、より効率的なスケジューリングと人員配置が可能になります。 利用可能リージョン : Amazon Connect エージェントのスケジューリングが利用可能なすべての AWS リージョン 関連リソース : AWS Contact Center ブログ Amazon Connect でのマルチスキル予測 Amazon Connect で永続的なエージェント接続による高速通話処理をサポート （2025年11月21日） 概要 : Amazon Connect とエージェント間の通信チャネルを永続化することで、お客様との接続処理の高速化を実現。アウトバウンドキャンペーンの通話において、お客様の体験とエージェントの効率性を向上させます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect エージェントの永続的接続を有効にする 3. Transform data into relationships: Proactive intelligence（データを関係性に変換：プロアクティブインテリジェンス） 顧客データを活用してより深い関係性を構築し、プロアクティブでパーソナライズされた顧客体験を提供します。 Amazon Connect で AI を活用した予測インサイト機能がプレビュー開始 （2025年11月30日） 概要 : Amazon Connect Customer Profiles を基盤として、AI を活用した5つの推奨アルゴリズムを導入。顧客の行動パターンと対話履歴を分析し、セルフサービスとエージェント対話の両方で利用可能な予測インサイトを提供します。 利用可能リージョン : 欧州 (フランクフルト)、米国東部 (バージニア北部)、アジアパシフィック (ソウル)、アジアパシフィック (東京)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、カナダ (中部) 関連リソース : 予測インサイト (プレビュー) Amazon Connect がアウトバウンドキャンペーン向け WhatsApp チャネルをリリース （2025年12月5日） {#whatsapp-campaigns} 概要 : Amazon Connect の Outbound Campaigns 機能で WhatsApp チャネルをサポート開始。マーケティングキャンペーンや大規模な顧客エンゲージメント活動において、WhatsApp を活用したアウトバウンドキャンペーンの実行が可能になります。 利用可能リージョン : Amazon Connect Outbound Campaigns が提供されているすべてのリージョン 関連リソース : アウトバウンドキャンペーンのチャネル設定 Amazon Connect Customer Profiles で新しいセグメンテーション機能を開始（ベータ） （2025年12月5日） 概要 : Amazon Connect Customer Profiles で新しいセグメンテーション機能をベータ版で提供開始。顧客データをより詳細にセグメント化し、パーソナライズされた顧客体験を提供できます。 利用可能リージョン : Amazon Connect Customer Profiles が提供されているすべてのリージョン 関連リソース : Amazon Connect で顧客セグメントを構築する Amazon Connect Outbound Campaigns でマルチステップ・マルチチャネル顧客エンゲージメントジャーニービルダーをサポート （2025年11月30日） 概要 : Amazon Connect Outbound Campaigns でマルチステップ・マルチチャネル顧客エンゲージメントジャーニービルダーをサポート開始。複数のステップと複数のチャネルを組み合わせた複雑な顧客エンゲージメントジャーニーを構築できます。 利用可能リージョン : Amazon Connect Outbound Campaigns が提供されているすべてのリージョン 関連リソース : Amazon Connect のアウトバウンドキャンペーンを作成する Amazon Connect Outbound Campaigns で未応答通話のリング時間設定をサポート （2025年11月19日） 概要 : Amazon Connect Outbound Campaigns でキャンペーンマネージャーが音声通話のリング時間を15〜60秒の範囲で設定できる機能を提供開始。通話が「無応答」としてマークされ次の連絡先に移る前のリング時間を調整可能。各連絡先でリング開始・終了時刻も記録され、正確なレポートと追跡が可能になります。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) 関連リソース : Amazon Connect Outbound Campaigns ウェブページ 4. Accelerate Outcomes: Confidence Through Observability（成果の加速：可視性による信頼性） 包括的な可視性と制御により、迅速なイノベーションと信頼性を両立させます。 Amazon Connect ダッシュボードでカスタムビジネスディメンションによるメトリクスフィルタリングをサポート （2025年12月29日） 概要 : 事業部門、製品ライン、顧客セグメントなどのカスタムビジネスディメンションに基づいたメトリクスフィルタリングをサポート。事前定義された属性を使用してビジネスディメンションを作成し、独自のビジネスニーズに基づいてダッシュボードをカスタマイズ可能。 利用可能リージョン : Amazon Connect が提供されているすべての AWS 商用リージョンおよび AWS GovCloud（US-West）リージョン 関連リソース : Amazon Connect 管理者ガイド – ダッシュボード Amazon Connect ウェブページ Amazon Connect でエージェント評価自動化を5つの追加言語に拡張 （2025年12月26日） 概要 : 生成 AI を使用してポルトガル語、フランス語、イタリア語、ドイツ語、スペイン語でのエージェントパフォーマンス評価を自動化。クロス言語評価もサポートし、多言語コンタクトセンターで標準化された評価フレームワークを使用可能。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) 関連リソース : 生成 AI を使用して Amazon Connect でエージェントのパフォーマンスを評価する Amazon Connect での AI を活用した会話分析 Amazon Connect でリアルタイムメトリクスアラートに追加詳細を提供 （2025年12月16日） 概要 : リアルタイムメトリクスアラートで、閾値を超えてアラートをトリガーした特定のエージェント、キュー、フロー、またはルーティングプロファイルの詳細を提供開始。マネージャーがアラートの根本原因を手動で調査する必要がなくなり、顧客体験と運用上の問題により迅速に対応できます。 利用可能リージョン : Amazon Connect が提供されているすべてのリージョン 関連リソース : Amazon Connect でリアルタイムメトリクスに基づくアラートを作成する Amazon Connect で評価フォームに複数選択と日付質問をサポート （2025年12月15日） 概要 : 人間と AI エージェントのパフォーマンスに関するより深いインサイトを取得するための2つの新しい評価質問タイプを提供。複数選択質問と日付質問により、より詳細な評価が可能になります。 利用可能リージョン : Amazon Connect が提供されているすべてのリージョン 関連リソース : Amazon Connect で評価フォームを作成する Amazon Connect でネイティブテストとシミュレーション機能を提供 （2025年11月30日） 概要 : Amazon Connect がネイティブなテストとシミュレーション機能を提供開始。コンタクトセンターの体験を自動的にシミュレートし、ワークフローの変更を検証し、新しい体験をビジュアルデザイナーや API を通じてデプロイできます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect コールシミュレーション テストと シミュレーションダッシュボード Amazon Connect でパフォーマンス評価の詳細なアクセス制御を提供 （2025年11月30日） 概要 : パフォーマンス評価に対するタグベースの詳細なアクセス制御を提供。マネージャーが関連する評価フォームのみにアクセスできるよう制限し、セキュリティを向上させます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect で評価フォームを作成する パフォーマンス評価にtag-based-accessコントロールを設定する Amazon Connect でセルフサービスインタラクションの自動パフォーマンス評価を提供 （2025年11月30日） 概要 : セルフサービスインタラクションに対する自動パフォーマンス評価機能を提供開始。AI を活用したセルフサービス体験の品質を自動的に評価し、改善点を特定できます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect で評価フォームを作成する Amazon Connect で AI エージェントの分析・監視機能を改善 （2025年11月30日） 概要 : AI エージェントのセルフサービスとエージェント支援体験における分析・監視機能を提供。AI エージェントが関与した問い合わせ数、ハンドオフレート、会話ターン数、平均処理時間などの主要メトリクスを含むカスタマイズ可能なダッシュボードを通じて、AI エージェントのパフォーマンスと顧客成果を測定・改善できます。 利用可能リージョン : Amazon Connect AI エージェントが提供されているすべての AWS リージョン 関連リソース : AI エージェントのパフォーマンスダッシュボード Amazon Connect でパフォーマンス評価の対象になる問い合わせを自動的に選択する新基準を導入 （2025年11月30日） 概要 : パフォーマンス評価の対象にする問い合わせを自動的に選択する新しい基準を導入。より効率的で的確な評価プロセスを実現します。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect 管理ウェブサイトを使用して Contact Lens ルールを作成する Amazon Connect でダッシュボードと API で使用するカスタムメトリクスの作成をサポート （2025年11月30日） 概要 : Amazon Connect でダッシュボードと API で使用するカスタムメトリクスの作成をサポート開始。組織固有の KPI や業務要件に合わせたカスタムメトリクスを定義し、ダッシュボードや API で活用できます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect のメトリクス、ダッシュボード、レポート Amazon Connect Chat が仕掛かり中のデータ削除とメッセージ処理のサポートを開始 （2025年11月30日） 概要 : Amazon Connect で、チャットメッセージが参加者に届く前にインターセプトして処理するメッセージ処理がサポートされるようになりました。この新機能により、機密データの自動削除とカスタムメッセージ処理が可能になるため、企業は個別設定されたカスタマーエクスペリエンスを提供しながら、コンプライアンスとセキュリティの基準を維持できます。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アフリカ (南アフリカ) 関連リソース : 処理中の機密データの秘匿化とメッセージ処理を有効にする Amazon Connect でマネージャーによるエージェント評価完了メトリクスを提供 （2025年11月14日） 概要 : マネージャーによるエージェントパフォーマンス評価の完了状況に関するメトリクスを提供開始。評価プロセスの進捗状況を追跡し、評価の完了率や遅延を監視できます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : エージェントパフォーマンス評価ダッシュボード Amazon Connect で条件付きキーワードとフレーズを使用した自動メール応答を開始 （2025年11月30日） 概要 : 条件付きキーワードとフレーズを使用した自動メール応答機能を開始。特定の条件に基づいて自動的にメール応答を生成し、効率的な顧客対応を実現します。 利用可能リージョン : Amazon Connect の E メールは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) の各リージョンで利用できます。 関連リソース : Amazon Connect で E メールを設定する Amazon Connect のフローブロック: 保存されたコンテンツを取得する Amazon Connect で音声・チャットボット向け会話分析を提供 （2025年11月19日） 概要 : Amazon Connect で音声およびデジタルチャネル全体のエンドカスタマーセルフサービスインタラクション向け会話分析を提供開始。PSTN/電話、アプリ内・ウェブ通話、ウェブ・モバイルチャット、SMS、WhatsApp Business、Apple Messages for Business を含む全チャネルで利用可能。顧客感情の自動分析、機密データの編集、主要な連絡要因とテーマの発見、コンプライアンスリスクの特定が可能になります。 利用可能リージョン : 対応言語 と リージョン を参照してください。 関連リソース : Amazon Connect Contact Lens 会話分析を使用して会話を分析する 4. AWS Contact Center Blog のご紹介 2025年11月・12月期間中、AWS Contact Center Blog では、Amazon Connect の最新機能と実践的な活用方法について多数の記事が公開されました。以下、注目すべき記事をご紹介します。 日本語記事 Amazon Connect Data Tables でコンタクトセンター運用を簡素化 コンタクトセンターの運用チームが直面する日常的な変更における開発者依存の課題を解決する、Amazon Connect Data Tables の活用方法について詳しく解説されています。この機能により、管理者はノーコードインターフェースを通じて運用データを管理でき、実装時間を数日から数分に短縮できます。 主な使用例： 直通電話番号内線システム : 富裕層顧客を担当アドバイザーに直接ルーティング 季節的サイト閉鎖フラグ : 冬季期間中の特別ルーティング設定 季節的ワクチンキャンペーン : 秋季のワクチン接種促進メッセージの自動再生 Amazon Connect のフローモジュールを強化する 3 つの強力な新機能 Amazon Connect のコアであるフローとモジュールに関する3つの革新的な新機能について解説されています： 1. カスタムブロックによるモジュールの柔軟性向上 JSON スキーマ v4 構文を実装し、入力・出力オブジェクトを正確に制御 カスタムブランチ名の設定により、従来のデータ受け渡しメカニズムの複雑さを解消 2. バージョニングとエイリアシングによるデプロイメント信頼性向上 変更されないモジュールの固定バージョン作成 エイリアス更新による全実装への自動適用 3. ツールとしてのモジュール活用 フロー外での独立実行単位としての利用 AI エージェントによるツールとしての活用が可能 MCP を用いた Amazon Connect の監視運用準備 Amazon Connect の使いやすいエンタープライズクラウドコンタクトセンターについて解説。組織が規模に応じて優れた顧客体験を提供できるよう支援します。Amazon Connect の主要な利点の一つは、Amazon CloudWatch とのネイティブ統合であり、運用活動を分析し、問題が顧客に影響を与える前にアラートを受信する強力な機能を提供することについて詳しく説明されています。 英語記事 AWS re:Invent 2025: カスタマーエクスペリエンスの再構築 | AWS re:Invent 2025: Reimagining customer experience with Amazon Connect AWS re:Invent 2025（12月1-5日、ラスベガス）での Amazon Connect チームの取り組みについて紹介。ビジョナリーリーダー、技術革新者、業界のパイオニアが集結し、インテリジェントな顧客体験の未来を探求する没入型の体験について解説されています。 Amazon Connect の対話型 AI | Leading the conversation with conversational AI in Amazon Connect 現代の顧客体験におけるデジタルコンシェルジュとしての会話型 AI の役割について詳しく解説。人間の言語を自然に理解・処理・応答する能力が、単なる自動化の機会を超えて、AI の効率性と人間の判断力・共感力を組み合わせる方法について説明されています。 Amazon Connect アシスタントでよりスマートなコンタクトセンター体験を創造 | Create smarter contact center experiences with the Amazon Connect assistant コンタクトセンターリーダーが直面する複雑な課題への対応について解説。顧客は全チャネルで即座にパーソナライズされたサービスを期待する一方、人間エージェントは複数のシステム、ナレッジベース、ワークフローを駆使して問題を解決する必要があります。従来のアプローチの課題と革新的なソリューションについて詳しく説明されています。 Amazon Connect at re:Invent 2025: AI で顧客体験の未来を創造 | Amazon Connect at re:Invent 2025: Creating the future of customer experience with AI 顧客体験の未来は、AI の効率性と人間のつながりのどちらかを選ぶことではなく、両方を組み合わせて特別なものを創造することについて解説。re:Invent 2025 で Amazon Connect が発表した、人間チームメイトと連携するインテリジェント AI エージェントによる顧客インタラクション変革の包括的ビジョンについて紹介されています。 Amazon Connect Data Tables でコンタクトセンター運用を簡素化 | Simplify contact center operations with Amazon Connect Data Tables コンタクトセンター運用チームが日常的な変更を行う際に直面する遅延の課題について解説。従来のアプローチでは開発者の支援とコード変更が必要でしたが、Amazon Connect Data Tablesにより管理者がノーコードインターフェースを通じて運用データを管理できるようになった経緯と活用方法について詳しく説明されています。 Toyota Insurance が Amazon Connect で顧客サービスコストを98.5%削減し、60%のセルフサービス率を達成 | How Toyota Insurance cut customer service costs by 98.5% and achieved 60% self-service with Amazon Connect 技術主導の保険代理店であるToyota Insurance Management Solutionsの事例について紹介。主に北米のトヨタ車オーナーにサービスを提供する同社が、運用効率を維持しながら顧客体験を向上させる革新的な方法を継続的に模索している取り組みについて詳しく解説されています。 テスト時間を最大90%削減：Amazon Connect のネイティブテスト・シミュレーション機能の紹介 | Reduce testing time by up to 90%: Introducing native testing and simulation for Amazon Connecte testing time by up to 90%: Introducing native testing and simulation for Amazon Connect コンタクトセンター管理者が直面する持続的な課題である、ライブ運用を中断することなくコンタクトフローを効率的にテスト・検証する方法について解説。従来のアプローチ（手動でのシステム呼び出し、カスタム検証ツールの構築、サードパーティソリューションへの投資）の課題と、新しいネイティブソリューションについて詳しく説明されています。 Amazon Connect AI 強化メールワークフローで顧客サービスを向上 | Boost customer service with Amazon Connect AI-enhanced email workflows Amazon Connect Email の組み込み機能について詳しく解説。統合されたオムニチャネルコンタクトセンタープラットフォーム内で、顧客サービスメールの優先順位付け、割り当て、解決の自動化を実現する方法について説明されています。組織は音声・チャットと並行してメールインタラクションを管理し、顧客属性とコンテンツに基づいてメールをルーティングできます。 Amazon Connect が3つの強力な新機能でフローモジュールを強化 | Amazon Connect enhances flow modules with 3 powerful new capabilities Amazon Connect のコアであるフローとモジュールについて詳しく解説。フローは顧客ジャーニーを定義し、モジュールは運用を合理化する再利用可能な構築ブロックとして機能します。これまで以上に強力で柔軟性があり、保守性を高める3つの新機能について詳しく説明されています。 Amazon Connect と Salesforce 間のケース同期の自動化 | Automate case synchronization between Amazon Connect and Salesforce Amazon Connect と Salesforce の統合について解説。統一された顧客ビューでエージェント体験を簡素化する方法について説明されています。各サービスがそれぞれの領域で優れている一方で、Amazon Connect で作成されたケースが Salesforce に同期されない場合（またはその逆）の課題と解決策について詳しく紹介されています。 常時稼働、常時保証：クラウドベース監視による継続的CX品質の実現 | Always on, always assuring: Unlocking continuous CX quality with cloud-based monitoring 顧客体験の進化する状況について詳しく解説。フライト予約、銀行残高確認、小売ブランドのサポートボットとのチャット等、今日の顧客はすべてのインタラクションが高速で、エラーフリーで、オンデマンドで利用可能であることを期待しています。単一の遅延、欠陥、停止でも顧客が競合他社を探す原因となる現状について説明されています。 Amazon Connect でのマルチスキル予測とスケジューリングの実装 | Implementing multi-skill forecasting and scheduling in Amazon Connect Amazon Connect が提供するコンタクトセンター向けマルチスキル予測・スケジューリング機能について解説。このアプローチは、エージェントを交換可能として扱うのではなく、専門エージェントスキルに基づいて需要をセグメント化します。Amazon Connect により、専門エージェントが高価値インタラクションを処理することを保証しながら、コストのかかるスタッフィング不均衡を解消する方法について説明されています。 Blink by Amazon が AWS Glue Zero ETL を使用してコンタクトセンターレポートを合理化した方法 | How Blink by Amazon streamlined contact center reporting using AWS Glue Zero ETL 大規模なコンタクトセンターワークフォースの管理において組織が長年直面してきた課題について解説。主要な問題の一つは、顧客関係管理（CRM）システムとレポートツール間のデータ一貫性の維持です。コンタクトセンタースーパーバイザーが直面する複数の課題点について詳しく説明されています。 Amazon Connect エージェントワークスペースでサードパーティアプリケーションとしてエージェント間通話を有効化 | Enable agent to agent calling as a third-party (3P) application in Amazon Connect agent workspace 協調的なコンタクトセンター環境において、エージェント同士が直接接続する能力が生産性を大幅に向上させ、問題解決を合理化できることについて解説。文脈情報の転送、スーパーバイザー支援の要請、チーム間の協力など、エージェント間通話が内部コミュニケーションの向上において重要な役割を果たすことについて詳しく説明されています。 Amazon Connect Tasks を使用したコンタクト後調査による顧客満足度スコアの分析 | Analyze customer satisfaction scores with post-contact surveys using Amazon Connect Tasks 顧客満足度（CSAT）がコンタクトセンターでのインタラクション後の顧客の認識を測定するために使用される主要メトリクスの一つであることについて解説。CSATコール後調査は、コンタクトセンターで提供される体験とサービスを微調整するための診断ツールとして重要であることについて詳しく説明されています。 Amazon Connect でビデオ通話を安全に実装 | Securely implement enterprise-ready video calling in Amazon Connect Amazon Connect のビデオ通話機能について詳しく解説。組織が人間エージェントと顧客間の対面インタラクションを提供できるようにします。しかし、組織は適切な認証を確保しながら、この機能を安全に実装することに注意を払う必要があります。エンドユーザー認証を含む Amazon Connect での安全なビデオ通話の設定方法について説明されています。 Amazon Connect でケース管理ワークフローを自動化 | Automate case management workflows with Amazon Connect 今日の多くのコンタクトセンターが、解決を遅らせ、運用コストを増加させ、ケースが見落とされるリスクを伴う手動ケース管理プロセスに苦労していることについて解説。特に、厳格なSLAとコンプライアンス要件が適用される保険などの規制業界において顕著です。従来のツールがしばしば失敗する中で、顧客は現在、タイムリーな更新、プロアクティブなコミュニケーション、サービスジャーニー全体でのシームレスなエスカレーションを期待していることについて詳しく説明されています。 Inside Amazon Connect | Inside Amazon Connect: The evolution of a disruptor Amazon Connect が AI を活用した顧客体験ソリューションとして、より低コストで優れた成果を可能にすることについて解説。2017年の公開ローンチ以来、Amazon Connect は AI リーダーとなり、あらゆるタイプの組織が顧客とのインタラクション方法を変革してきました。先週の Q3 2025年決算報告で、Amazon が Amazon Connect の重要なマイルストーンを発表したことについて詳しく紹介されています。 Amazon Connect と Amazon Lex を使用した NatWest での銀行セルフサービスの簡素化 | Simplifying banking self-service at NatWest using Amazon Connect and Amazon Lex 英国有数の金融機関の一つである NatWest Group の事例について解説。小売、商業、プライベートバンキング部門にわたって幅広い銀行サービスを提供する同行が、既存のレガシープラットフォームからコンタクトセンター運用を近代化し、自然言語コールステアリング（NLCS）エンジンの管理において直面した重要な課題について詳しく説明されています。 Amazon Connect と Amazon Lex でチャネル間のインタラクションコンテキストを保持 | Preserve interaction context across channels with Amazon Connect and Amazon Lex 今日の顧客が音声通話、ウェブチャット、モバイルアプリ、SMS、iMessage、Facebook、X などの様々なソーシャルメディアプラットフォームなど、好みのコミュニケーションチャネルを通じて組織とインタラクションすることを好むことについて解説。チャネルの選択は、多くの場合、顧客の現在の状況に依存することについて詳しく説明されています。 詳細情報 : AWS Contact Center Blog 皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 Amazon Connect ソリューションアーキテクト 坂田

明けましておめでとうございます! クリスマスや年末年始を通じて、皆さんが心身ともにリフレッシュし、愛する人と一緒に時間を過ごせたことを願っています。 例年どおり、私は AWS re:Invent 後に数週間休暇を取って疲れを癒し、今後の計画を立てました。休暇の一部は、 Become a Solutions Architect (BeSA) の次のグループを計画するために使いました。無料のメンタリングプログラムである BeSA は、人々がクラウドキャリアや AI キャリアで能力を発揮するための支援手段として、私、そしてその他数人の Amazon Web Services (AWS) 社員ボランティアがホストしています。2026 年 2 月 21 日には、「AWS でのエージェンティック AI」に関する 6 週間のプログラムが開始されます。詳細については、 BeSA のウェブサイト をご覧ください。 まだ遅くはありません。 Global 10,000 AIdeas Competition にアイデアを提出し、賞金 250,000 USD、AWS クレジット、受賞を目指して競いましょう。受賞者は、AWS re:Invent 2026 やさまざまな AWS チャネルで特集紹介される可能性もあります。 次世代 AI 開発ツールで実践的な経験を積み、世界中のイノベーターとつながるとともに、2 週間に 1 度のワークショップ、AWS ユーザーグループ、AWS Builder Center リソースによるテクニカルイネーブルメントにアクセスできます。 締め切りは 2026 年 1 月 21 日で、コードはまだ必要ありません。準決勝進出者に選出されたら、その時点でアプリケーションを作成します。完成したアプリケーションは、開発の少なくとも一部に Kiro が使用されており、 AWS 無料利用枠 の範囲を越えず、完全にオリジナルかつ未公開である必要があります。 AWS re:Invent 2025 からの新リリースや発表のすべてをまだ把握していない場合は、 注目の発表記事 を読む、または 基調講演、イノベーショントーク、ブレイクアウトセッションをオンデマンドでご覧ください 。 過去数週間のリリース 2025 年 12 月 15 日の最後の Week in Review 後に行われた発表で、私が注目したものをいくつか紹介したいと思います。 Amazon EC2 M8gn および M8gb インスタンス – 新しい M8gn インスタンスと M8gb インスタンスには、AWS Graviton3 プロセッサよりも最大 30% 優れたコンピューティングパフォーマンスを実現する AWS Graviton4 プロセッサが搭載されています。M8gn インスタンスには最新の第 6 世代 AWS Nitro Card が使用されており、ネットワーク最適化 EC2 インスタンスの中でも最も高いネットワーク帯域幅である、最大 600 Gbps のネットワーク帯域幅を提供します。M8gb は最大 150 Gbps の Amazon EBS 帯域幅を提供し、同じサイズの同等の Graviton4 ベースインスタンスよりも優れた EBS パフォーマンスを実現します。 AWS Direct Connect が AWS Fault Injection Service を用いたレジリエンステストをサポート – AWS Fault Injection Service を使用して、アプリケーションが Direct Connect ボーダーゲートウェイプロトコル (BGP) フェイルオーバーをどのように処理するのかを制御された環境内でテストできるようになりました。例えば、プライマリ仮想インターフェイスの BGP セッションが中断されたときにトラフィックが冗長仮想インターフェイスにルーティングされ、アプリケーションが期待どおりに機能し続けることを検証できます。 AWS Control Tower での新しい AWS Security Hub コントロール – AWS Control Tower が Control Catalog でさらに 176 個の Security Hub コントロールをサポートするようになりました。これらは、セキュリティ、コスト、耐久性、運用などのユースケースを対象としています。このリリースにより、これらのコントロールの検索、検出、有効化、管理を AWS Control Tower から直接実行して、マルチアカウント環境全体でさらに多くのユースケースを制御できるようになります。 AWS Transform がハイブリッドデータセンター移行のためのネットワーク変換をサポート – AWS Transform for VMware を使用して、ハイブリッドデータセンターからネットワークを自動的に変換できるようになりました。このため、VMware ワークロードとその他ワークロードの両方を実行する環境のネットワークマッピングを手動で行う必要がなくなります。このサービスは、エクスポートされたすべてのソースネットワークで VLAN と IP 範囲を分析し、それらを仮想プライベートクラウド (VPC)、サブネット、セキュリティグループなどの AWS コンストラクトにマップします。 Amazon Bedrock での NVIDIA Nemotron 3 Nano の提供開始 – Amazon Bedrock が NVIDIA Nemotron 3 Nano 30B A3B モデルをサポートするようになりました。これは、効率的な言語モデリングにおける NVIDIA 最新のブレークスルーであり、高度な推論パフォーマンス、組み込み型のツール呼び出しサポート、256,000 トークンのコンテキストウィンドウによる拡張コンテキスト処理を実現します。 Amazon EC2 がすべての API でアベイラビリティゾーン ID をサポート – Amazon EC2 API にアベイラビリティゾーン ID (AZ ID) パラメータを直接指定して、リソースの一貫的な配置を保証することができます。AZ ID は、すべての AWS アカウント全体で同一の物理的な場所を表す一貫的かつ静的な識別子で、リソース配置の最適化に役立ちます。今回のリリース以前は、リソースの作成時に AZ 名を使用する必要がありましたが、AZ 名は異なる物理的な場所にマップされる可能性がありました。このマッピングは、特に複数のアカウントを用いた運用において、リソースを常に同じ場所に配置することを困難にしていました。 Amazon ECS マネージドインスタンスが Amazon EC2 スポットインスタンスをサポート – Amazon ECS マネージドインスタンスが Amazon EC2 スポットインスタンスをサポートするようになり、AWS マネージドインフラストラクチャで利用できる機能の範囲が拡大されました。Amazon ECS マネージドインスタンス内のフォールトトレラントワークロードに対し、オンデマンド料金から最大 90% の割引料金で予備の EC2 キャパシティを使用できます。 この記事で取り上げられていないその他のリリースニュースについては、 AWS の最新情報 をご覧ください。 今週のニュースは以上です。2026 年 1 月 12 日週の Weekly Roundup もお楽しみに! 2026 年の素晴らしいスタートを祝して乾杯。ハッピービルディング! –  Prasad 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server が、CPU 最適化機能をサポートするようになりました。 CPU 最適化機能 を使用すると、新しいインスタンスを起動する際や既存のデータベースインスタンスを変更する際に、コア数を定義することができます。この機能は第 7 世代インスタンスクラスから利用可能です。以下のメリットがあります： RDS SQL Server インスタンスの vCPU 数をカスタマイズ 特定のワークロードに対して望ましいメモリ対 CPU 比を実現 ライセンスコストを削減し、全体的なコスト管理においてさらなる柔軟性を獲得する可能性 この投稿では、Amazon RDS for SQL Server で CPU 最適化機能を使用する方法について説明します。内容は以下の通りです： CPU 最適化を設定して新しいインスタンスを作成する CPU 最適化で既存のインスタンスを変更する CPU 最適化で設定されたスナップショットから復元する CPU 最適化でポイントインタイムリカバリ (PITR) を実行する 前提条件 この投稿の例では、 AWS Command Line Interface (AWS CLI) を使用します。 RDS for SQL Server DB インスタンス の作成に関する基本的な知識があり、CPU アーキテクチャの概念 (コア、コアあたりのスレッド数、vCPU) を理解している必要があります。 また、 CPU 最適化機能 が Amazon RDS for SQL Server の 料金 と DB インスタンスのパフォーマンスの両方にどのような影響を与えるかについても理解しておく必要があります。 CPU 最適化された新しいインスタンスの作成 CPU 最適化機能を使用して RDS SQL Server インスタンスを作成するには、create-db-instance コマンドで --processor-features パラメータを使用します。 coreCount と threadsPerCore の値を指定してください。次のコマンドは、8 コアで 1 コアあたり 1 スレッドのインスタンスを作成し、合計 8 個の vCPU になります。 aws rds create-db-instance --region us-west-2 \ --engine-version 16.00 \ --allocated-storage 100 \ --license-model license-included \ --master-username admin --master-user-password XXXXX \ --no-multi-az \ --publicly-accessible \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --db-instance-identifier rfs-test-ocpu-instance \ --db-instance-class db.r7i.8xlarge \ --engine sqlserver-ee \ --processor-features "Name=coreCount,Value=8" "Name=threadsPerCore,Value=1" Bash このコマンドを使用する場合： --processor-features パラメータには、 coreCount と threadsPerCore の両方を指定することが必須です。 coreCount : インスタンスの CPU コア数をカスタマイズできます。選択したインスタンスタイプでコア数に許可されている値を確認するには、 CPU 最適化をサポートする DB インスタンスクラス を参照してください。 hreadsPerCore : コアあたりのスレッド数は、CPU コアあたりのスレッド数を定義するように設定されます。第 7 世代インスタンスクラスタイプ以降、CPU 最適化機能がサポートされており、第 7 世代インスタンスではハイパースレッディングが無効になっているため、コアあたりのスレッド数の許可値は 1 です。 --processor-features パラメータは、Amazon RDS for SQL Server に最低 4 vCPU が必要です。 これらの設定を確認するには、 describe-db-instances コマンドを使用してください： ---------------------------------------------------------------------------------- | DescribeDBInstances | +-----------------+--------------------------+---------------+-------------------+ | DBInstanceClass | DBInstanceIdentifier | Engine | EngineVersion | +-----------------+--------------------------+---------------+-------------------+ | db.r7i.8xlarge | rfs-test-ocpu-instance | sqlserver-ee | 16.00 .4215.2.v1 | +-----------------+--------------------------+---------------+-------------------+ || ProcessorFeatures || | +---------------------------------------------------+--------------------------+ | || Name | Value || | +---------------------------------------------------+--------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +---------------------------------------------------+--------------------------+ | Bash 以下は、AWS Management Console での CPU 最適化機能の設定画面です。 注意 : ワークロードや RDS で自動化されたタスクに対してリソース制約を引き起こすことなく、設定された vCPU がワークロードを処理できるように、CPU 最適化機能を使用してワークロードのベンチマークを実行することをお勧めします。 CPU 最適化機能が有効になっている既存インスタンスの変更 –use-default-processor-features を使用したインスタンスの変更 CPU 最適化インスタンスをデフォルト設定に戻すには、 --use-default-processor-features パラメータを使用します。 例えば、以下のコマンドは、db.r7i.8xlarge インスタンスタイプで 8 コア、1 スレッドのプロセッサ機能で設定されたインスタンス (rfs-test-ocpu-instance) を、そのデフォルト設定に変更します。 aws rds modify-db-instance --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance \ --use-default-processor-features \ --apply-immediately Bash 前の例では、8 コアで 1 コアあたり 1 スレッドの CPU 最適化設定で構成された既存の db.r7i.8xlarge インスタンスを、16 コアで 1 コアあたり 1 スレッドの db.r7i.8xlarge インスタンスタイプの デフォルト設定 を使用するように変換されます。 マルチ AZ インスタンスの場合、プライマリインスタンスとセカンダリインスタンスの両方が、プロセッサ機能設定に従って同一の vCPU 構成を持ちます。 注意 : DB インスタンスを変更して CPU 最適化を設定する場合、インスタンスクラスタイプを変更する際と同じように短時間の DB インスタンスのダウンタイムが発生します –processor-features を使用したインスタンスの変更 既存のインスタンスを変更して、プロセッサ機能設定を指定することができます。例えば、以下のコマンドは、db.r7i.8xlarge インスタンスタイプとデフォルト設定で構成されている既存のインスタンス (rfs-test-ocpu-instance) を、CPU 最適化のカスタム設定に変更します。 aws rds modify-db-instance --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance \ --db-instance-class db.r7i.16xlarge \ --processor-features "Name=coreCount,Value=8" "Name=threadsPerCore,Value=1" \ --apply-immediately Bash デフォルトでは、db.r7i.16xlarge インスタンスは 32 コアでコアあたり 1 スレッドをサポートし、合計 32 個の vCPU となります。指定された設定で CPU 最適化機能を利用すると、インスタンスは 8 コアでコアあたり 1 スレッドに変更され、合計 8 個の vCPU となります。 CPU 最適化が設定されたスナップショットからの復元 CPU 最適化が有効になっているインスタンスのスナップショットから復元する場合、デフォルトでは設定はターゲットインスタンスにコピーされます。復元プロセス中に異なる CPU 最適化設定を指定することもできます。 CPU 最適化機能を使用したスナップショットの復元 この例では、CPU 最適化設定で構成された既存のインスタンス (rfs-test-ocpu-instance) のスナップショットバックアップを使用しています。これは db.r7i.16xlarge インスタンスタイプを使用し、8 コアでコアあたり 1 スレッドの CPU 最適化設定により、合計 8 個の vCPU を実現しています。 スナップショットを作成するには、以下のコマンドを実行してください : aws rds create-db-snapshot --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance \ --db-snapshot-identifier backup-rfs-test-ocpu-instance Bash DB スナップショットの詳細を確認するには、次のコマンドを実行してください： aws rds describe-db-snapshots --region us-west-2 \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --query "DBSnapshots[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBSnapshotIdentifier:DBSnapshotIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures}" Bash 次のようなアウトプットを取得できます : ------------------------------------------------------------------------------------------------ | DescribeDBSnapshots | +-------------------------+---------------------------------+---------------+------------------+ | DBInstanceIdentifier | DBSnapshotIdentifier | Engine | EngineVersion | +-------------------------+---------------------------------+---------------+------------------+ | rfs-test-ocpu-instance | backup-rfs-test-ocpu-instance | sqlserver-ee | 16.00 .4215.2.v1 | +-------------------------+---------------------------------+---------------+------------------+ || ProcessorFeatures || | +-------------------------------------------------------------+------------------------------+ | || Name | Value || | +-------------------------------------------------------------+------------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +-------------------------------------------------------------+------------------------------+ | Bash スナップショットから復元するには、次のコマンドを実行してください： aws rds restore-db-instance-from-db-snapshot --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --db-instance-identifier rfs-test-ocpu-instance-3 Bash restore-db-instance-from-db-snapshot では、インスタンスタイプや CPU 最適化設定を指定しなかったため、Amazon RDS はスナップショットから同じインスタンスタイプ (db.r7i.16xlarge) と CPU 最適化設定 (8 コア、コアあたり 1 スレッド) でインスタンスを作成します。 スナップショット復元で CPU 最適化機能を使用するシナリオは複数あります。 スナップショットを異なるインスタンスタイプとデフォルトのプロセッサ機能に復元 CPU 最適化が有効になっているインスタンスで取得したスナップショットは、異なるインスタンスタイプと --use-default-processor-features を指定することで復元できます。 この例では、CPU 最適化設定で構成された既存のインスタンス (rfs-test-ocpu-instance) のスナップショットバックアップを使用しています。元のインスタンスは db.r7i.16xlarge インスタンスタイプを使用し、8 コアでコアあたり 1 スレッドの CPU 最適化設定により、合計 8 個の vCPU となっています。 以下のコマンドは、スナップショットを異なるインスタンスタイプ (db.r7i.8xlarge) にデフォルトの CPU 設定 (16 コア、コアあたり 1 スレッド) で復元します。 aws rds restore-db-instance-from-db-snapshot --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --db-instance-identifier rfs-test-ocpu-instance-5 \ --db-instance-class db.r7i.8xlarge \ --use-default-processor-features Bash (無効) 異なるインスタンスタイプで、プロセッサ機能が設定されていない設定でのスナップショットの復元 CPU 最適化の設定をしたインスタンスから異なるインスタンスタイプにスナップショットを復元する際は、プロセッサ機能設定を省略することはできません。以下の例では、これを試行した場合に何が起こるかを示しています。 このシナリオでは、db.r7i.16xlarge、8 コア、コアあたり 1 スレッドで構成されたインスタンス (rds-test-ocpu-instance) から取得したスナップショットを、プロセッサ機能を指定せずに異なるインスタンスタイプ (db.r7i.8xlarge) に復元しています : aws rds restore-db-instance-from-db-snapshot --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --db-instance-identifier rfs-test-ocpu-instance-6 \ --db-instance-class db.r7i.8xlarge Bash このコマンドは次のエラーで失敗します： An error occurred ( InvalidParameterCombination ) when calling the RestoreDBInstanceFromDBSnapshot operation: Your request must specify ProcessorFeatures settings or set UseDefaultProcessorFeatures since the snapshot has ProcessorFeatures set. Bash スナップショットでプロセッサ機能が有効になっており、復元時に異なるインスタンスタイプを指定する場合は、 ProcessorFeatures 設定または UseDefaultProcessorFeatures オプションのいずれかを明示的に指定する必要があります。 カスタムプロセッサ機能を持つ異なるインスタンスタイプにスナップショットを復元する 例えば、以下のコマンドは、db.r7i.16xlarge インスタンスタイプを使用して CPU 最適化設定 (8 コア、コアあたり 1 スレッド) で構成されたインスタンス (rfs-test-ocpu-instance) のスナップショットを復元します。新しいインスタンスタイプ (db.r7i.12xlarge) と新しい CPU 最適化設定 (18 コア、コアあたり 1 スレッド) を指定しました。 aws rds restore-db-instance-from-db-snapshot --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --db-instance-identifier rfs-test-ocpu-instance-7 \ --db-instance-class db.r7i.12xlarge \ --processor-features "Name=coreCount,Value=18" "Name=threadsPerCore,Value=1" Bash CPU 最適化されたポイントインタイムリカバリ (PITR) ポイントインタイムリカバリ (PITR) を使用すると、インスタンスを特定の時点に復元できます。このプロセスでは、PITR で指定された時刻に基づいて特定のスナップショットを復元し、その後そのスナップショットにすべてのトランザクションログバックアップを適用することで、インスタンスを指定された時点の状態にします。 PITR では、 coreCount と threadsPerCore のプロセッサ機能設定は、PITR リクエスト時にカスタム値が指定されない限り、(その時点に設定されていた値ではなく) ソーススナップショットから取得されます。使用されているソーススナップショットで CPU 最適化が有効になっており、PITR で異なるインスタンスタイプを使用している場合は、ターゲットインスタンスの CPU 最適化オプションを定義するか、 --use-default-processor-features オプションを指定する必要があります。上記のスナップショット復元で説明されたユースケースは、PITR にも適用されます。 TimeStamp-1 : CPU 最適化されたソースデータベースインスタンスの詳細 例えば、8 コアで 1 コアあたり 1 スレッドの CPU 最適化設定で db.r7i.8xlarge インスタンスタイプで実行されるインスタンス (rfs-test-ocpu-instance-8) があります。以下のコマンドはインスタンス設定を表示します。 aws rds describe-db-instances --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-8 \ --query 'DBInstances[].{DBInstanceIdentifier:DBInstanceIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures,DBInstanceClass:DBInstanceClass}' Bash 次のような出力が得られます : ------------------------------------------------------------------------------------ | DescribeDBInstances | +-----------------+----------------------------+---------------+-------------------+ | DBInstanceClass | DBInstanceIdentifier | Engine | EngineVersion | +-----------------+----------------------------+---------------+-------------------+ | db.r7i.8xlarge | rfs-test-ocpu-instance-8 | sqlserver-ee | 16.00 .4215.2.v1 | +-----------------+----------------------------+---------------+-------------------+ || ProcessorFeatures || | +-----------------------------------------------------+--------------------------+ | || Name | Value || | +-----------------------------------------------------+--------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +-----------------------------------------------------+--------------------------+ | Bash TimeStamp-2: データベーススナップショットの作成 データベースのスナップショットを作成するために、以下のコマンドを実行します。 aws rds create-db-snapshot --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-8 \ --db-snapshot-identifier pitr-backup-rfs-test-ocpu-instance-8 Bash データベーススナップショットの詳細を確認するために以下のコマンドを使用します： aws rds describe-db-snapshots --region us-west-2 \ --db-snapshot-identifier pitr-backup-rfs-test-ocpu-instance-8 \ --query "DBSnapshots[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBSnapshotIdentifier:DBSnapshotIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures}" Bash 次のような出力が得られます : --------------------------------------------------------------------------------------------------------- | DescribeDBSnapshots | +---------------------------+----------------------------------------+---------------+------------------+ | DBInstanceIdentifier | DBSnapshotIdentifier | Engine | EngineVersion | +---------------------------+----------------------------------------+---------------+------------------+ | rfs-test-ocpu-instance-8 | pitr-backup-rfs-test-ocpu-instance-8 | sqlserver-ee | 16.00 .4215.2.v1 | +---------------------------+----------------------------------------+---------------+------------------+ || ProcessorFeatures || | +-------------------------------------------------------------------+---------------------------------+ | || Name | Value || | +-------------------------------------------------------------------+---------------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +-------------------------------------------------------------------+---------------------------------+ | Bash TimeStamp-3: インスタンスプロセッサ機能設定の変更 次に、以下のコマンドを実行して、インスタンスのプロセッサ機能設定を 4 コア、コアあたり 1 スレッドに変更します： aws rds modify-db-instance --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-8 \ --db-instance-class db.r7i.8xlarge \ --processor-features "Name=coreCount,Value=4" "Name=threadsPerCore,Value=1" \ --apply-immediately Bash インスタンスの詳細を確認します : aws rds describe-db-instances --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-8 \ --query 'DBInstances[].{DBInstanceIdentifier:DBInstanceIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures,DBInstanceClass:DBInstanceClass}' Bash 次のような出力が得られます : ----------------------------------------------------------------------------------- | DescribeDBInstances | +-----------------+----------------------------+---------------+-------------------+ | DBInstanceClass | DBInstanceIdentifier | Engine | EngineVersion | +-----------------+----------------------------+---------------+-------------------+ | db.r7i.8xlarge | rfs-test-ocpu-instance-8 | sqlserver-ee | 16.00 .4215.2.v1 | +-----------------+----------------------------+---------------+-------------------+ || ProcessorFeatures || | +-----------------------------------------------------+--------------------------+ | || Name | Value || | +-----------------------------------------------------+--------------------------+ | || coreCount | 4 || || threadsPerCore | 1 || | +-----------------------------------------------------+--------------------------+ | Bash TimeStamp-4: 最新の復元可能時刻への PITR 次に、インスタンスを最新の復元可能時刻に復元します。 aws rds restore-db-instance-to-point-in-time --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --source-db-instance-identifier rfs-test-ocpu-instance-8 \ --target-db-instance-identifier rfs-test-ocpu-instance-9 \ --use-latest-restorable-time Bash 復元されたインスタンスに対して describe コマンドを実行します： aws rds describe-db-instances --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-9 \ --query 'DBInstances[].{DBInstanceIdentifier:DBInstanceIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures,DBInstanceClass:DBInstanceClass}' \ Bash 次のような出力が得られます : ------------------------------------------------------------------------------------ | DescribeDBInstances | +-----------------+----------------------------+---------------+-------------------+ | DBInstanceClass | DBInstanceIdentifier | Engine | EngineVersion | +-----------------+----------------------------+---------------+-------------------+ | db.r7i.8xlarge | rfs-test-ocpu-instance-9 | sqlserver-ee | 16.00 .4215.2.v1 | +-----------------+----------------------------+---------------+-------------------+ || ProcessorFeatures || | +-----------------------------------------------------+--------------------------+ | || Name | Value || | +-----------------------------------------------------+--------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +-----------------------------------------------------+--------------------------+ || Bash ポイントインタイムリカバリ (PITR) の時点で、ソースインスタンスは db.r7i.8xlarge インスタンスタイプで実行されており、4 コア、コアあたり 1 スレッドの構成となっています。しかし、復元されたインスタンス (最新の復元可能時刻を使用) の CPU 設定は、8 コア、コアあたり 1 スレッドに設定されています。 クリーンアップ RDS for SQL Server インスタンスが不要になった場合は、追加料金の発生を避けるために削除してください。 RDS SQL Server DB インスタンスの削除 次のコマンドを使用します : aws rds delete-db-instance \ --region us-west-2 \ --db-instance-identifier < db_instance_name > \ --skip-final-snapshot Bash 手動で取得した DB Snapshot の削除 次のコマンドを使用します : aws rds delete-db-snapshot \ --region us-west-2 \ --db-snapshot-identifier < db_snapshot_name > Bash 結論 この投稿では、Amazon RDS for SQL Server の CPU 最適化機能を使用して vCPU 割り当てをカスタマイズし、特定のワークロードのコストを削減し、パフォーマンスを最適化する方法を実演しました。新しいインスタンスの作成、既存インスタンスの変更、CPU 最適化設定でのスナップショットからの復元とポイントインタイムリカバリについて説明しました。CPU リソースを微調整することで、アプリケーションが必要とするパフォーマンスを維持しながら、より良いコスト最適化を実現できます。 Amazon RDS for SQL Server とその機能の詳細については、 Amazon RDS ユーザーガイド を参照してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Srikanth Katakam Srikanth は、Amazon RDS やAmazon RDS Custom for SQL Server などの Amazon RDS 商用データベースエンジンを専門とするAWS のシニアデータベースエンジニアです。豊富な技術的専門知識を持っていて、AWS のお客様の多様なニーズに応える堅牢な機能の設計と開発に情熱を注いでいます。 Sandesh Bhandari Sandesh は、AWS のソフトウェア開発エンジニアで、Amazon RDS for SQL Server と RDS Custom for SQL Server に取り組んでいます。彼はスケーラブルなデータベースソリューションの構築と複雑な技術的問題の解決を専門としています。詳細な分析とイノベーションに重点を置き、AWS データベースサービスの信頼性と効率性を向上させる機能を開発しています。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、SQL Server インストールファイルを Amazon Simple Storage Service (Amazon S3) にアップロードするカスタムエンジンバージョン (CEV) アプローチを通じて、SQL Server Developer Edition をサポートするようになりました。この機能により、フルマネージドな RDS インフラストラクチャの恩恵を受けながら、追加のライセンス費用を発生させることなく、開発およびテスト環境で Developer Edition を使用することができます。 SQL Server Developer Edition は、Enterprise Edition のすべての機能を含む完全機能版です。 RDS上 の SQL Server Developer Edition により、開発チームは本番環境との一貫性を保ちながら、管理された環境で Developer Edition の機能を利用でき、AWS インフラストラクチャの料金のみを支払うだけで、SQL Server のライセンス料金は不要です。料金の詳細については、 Amazon RDS for SQL Server の料金ページ をご覧ください。 ソーリューション概要 SQL Server Developer Edition インスタンスを作成するには、以下の 3 つの手順に従ってください。 Developer Edition ISO および必要な累積更新プログラムを含む SQL Server インストールファイルを準備し、Amazon S3 にアップロードします。 Amazon RDS が特定のデータベースエンジン構成を構築するために使用する CEV を作成します。 CEV を使用して RDS インスタンスを起動すると、フルマネージドな SQL Server Developer Edition データベースが提供されます。 以下の図は、前述の手順で説明されたワークフローを示しています。 前提条件 この機能の初期リリースの一環として、Developer Edition は累積更新プログラム 21(CU21) を適用した SQL Server 2022 をサポートしています。この機能は第 6 世代インスタンスクラス (M6i および R6i) でサポートされています。サポートされているインスタンスクラスの最新リストについては、 AWS RDS SQL Server インスタンスクラス を参照してください。 開始する前に、以下が必要です： 以下の権限を持つ RDS for SQL Server Developer Edition インスタンスを作成できる AWS Identity and Access Management (IAM) プリンシパル (ロールまたはユーザー) ： AmazonRDSFullAccess – RDS 操作のための AWS 管理ポリシー s3:GetObject – Amazon S3 内の SQL Server インストールファイルにアクセスするための権限 インストールファイルを保存する S3 バケット。すべてのインストールファイルは、CEV を作成するのと同じ AWS リージョンの同じ S3 バケット内の同じフォルダパスに保存する必要があります。 ステップ 1: インストールファイルを準備してアップロードする 開始するには、SQL Developer Edition と累積更新プログラムをダウンロードしてインストールします。この手順の一部として、ファイルを保存するための S3 バケットを作成します。 SQL Server Developer Edition をダウンロード SQL Server 2022 Developer Edition をダウンロードする 注意 : Developer Edition を入手するために Visual Studio サブスクリプション を使用することもできます。英語版をダウンロードしてください。他のバージョンはサポートされていません。 インストーラーを実行し、「メディアのダウンロード」を選択してください。 優先言語として英語を選択し、メディアタイプとして ISO を選択し、インストールファイルを保存するダウンロード場所を指定してください。他の言語の ISO ファイルはサポートしていません。ISO ファイルが英語でない場合、またはファイルに ISO 拡張子がない場合、Developer Edition CEV の作成プロセスは失敗します。 または、SQL Server Developer Edition のインストールパッケージをダウンロードした後、以下のコマンドを使用してインタラクティブインストーラーの無人ダウンロードを実行できます。 SQL2022-SSEI-Dev.exe /Action=Download /Language=en-US /MediaType=ISO /MediaPath=C:\InstallationMedia /Quiet Code サポートされている累積更新プログラム Developer Edition CEV の作成でサポートされているすべてのエンジンバージョンを表示するには、以下の AWS Command Line Interface (AWS CLI) コマンドを実行してください： aws rds describe-db-engine-versions \ --engine sqlserver-dev-ee \ --output json \ --query "{DBEngineVersions: DBEngineVersions[?Status=='requires-custom-engine-version'].{Engine: Engine, EngineVersion: EngineVersion, Status: Status, DBEngineVersionDescription: DBEngineVersionDescription}}" Code このコマンドは以下のような出力を返します : { "DBEngineVersions": [ { "Engine": "sqlserver-dev-ee", "EngineVersion": "16.00.4215.2.v1", "Status": "requires-custom-engine-version", "DBEngineDescription": "Microsoft SQL Server Enterprise Developer Edition", "DBEngineVersionDescription": "SQL Server 2022 16.00.4215.2.v1" } ] } Code エンジンバージョンのステータスを “requires-custom-engine-version” に設定すると、サポートされているテンプレートエンジンバージョンが識別されます。これらのテンプレートは、インポート可能な SQL Server バージョンを示します。 累積更新プログラムをダウンロード Microsoft Update Catalog にアクセスします。 最新の RDS サポート対象累積更新プログラムを検索してダウンロードします。この例では、CU21 (SQLServer2022-KB5065865-x64.exe) を使用しています。 S3 バケットを作成し、SQL Serverのインストールファイルをアップロード 以下のサンプルコードは、 us-west-2 リージョンに amzn-s3-demo-destination-bucket バケットを作成します。 aws s3 mb s3://amzn-s3-demo-destination-bucket --region us-west-2 Code ISO ファイルをアップロードするために以下のコマンドを実行してください。 aws s3 cp SQLServer2022-x64-ENU-Dev.iso s3://amzn-s3-demo-destination-bucket/sqlserver-dev-media/ Code 累積更新ファイルをアップロードするために、以下のコマンドを実行してください。 aws s3 cp SQLServer2022-KB5065865-x64.exe s3://amzn-s3-demo-destination-bucket/sqlserver-dev-media/ Code 結果を確認するには、Amazon S3 コンソールに移動してバケットを参照してその内容を表示してください。 ステップ 2: CEV を作成 CEV は、Amazon RDS がインスタンスをデプロイする際に使用する SQL Server のインストールファイルを再利用可能なテンプレートにパッケージ化します。この手順では、S3 バケットにアップロードした SQL Server インストールファイルから CEV を作成します。 Aurora と RDS の AWS マネジメントコンソールから、ナビゲーションペインで「カスタムエンジンバージョン」を選択し、次に「カスタムエンジンバージョンの作成」を選択します。 CEV の設定をします : エンジンのタイプ : SQL Server を選択 データベース管理タイプ : Amazon RDS を選択 エディション : SQL Server Developer Edition を選択 エンジンバージョン : ドロップダウンメニューから SQL Server エンジンバージョンを選択してください。メニューには SQL Server Developer Edition でサポートされているエンジンバージョン (16.00.4215.2 など) が表示されます。 カスタムエンジンバージョン識別子 : sql-server-dev-edition-cev などの名前を入力してください。 インストールメディアで、ISO ファイルと累積更新プログラムを検索して選択します。 SQL インストールファイルパス : s3://amzn-s3-demo-destination-bucket/sqlserver-dev-media/SQLServer2022-x64-ENU-Dev.iso 更新プログラムファイルパス : s3://amzn-s3-demo-destination-bucket/sqlserver-dev-media/SQLServer2022-KB5065865-x64.exe 「カスタムエンジバージョンの作成」をクリックします。 CEV の作成には通常 15 ～ 30 分かかります。新しく作成された CEV は、検証が完了するまで「検証中」のステータスになります。RDS インスタンスを作成する前に、コンソールで CEV のステータスを監視し、「利用可能」になるまで待ってください。 または、AWS CLI を使用して CEV を作成し、そのステータスを監視することもできます。 CEV の作成 aws rds create-custom-db-engine-version \ --engine sqlserver-dev-ee \ --engine-version 16.00.4215.2.sql-server-dev-ed-cev \ --region us-west-2 \ -- database-installation-files-s3-bucket-name amzn-s3-demo-destination-bucket \ --database-installation-files-s3-prefix sqlserver-dev-media \ --database-installation-files "SQLServer2022-x64-ENU-Dev.iso" "SQLServer2022-KB5065865-x64.exe" Code CEV 作成ステータスの監視 aws rds describe-db-engine-versions \ --engine sqlserver-dev-ee \ --engine-version 16.00.4215.2.sql-server-dev-ed-cev \ --region us-west-2 Code 注意 : このコマンドは、ステータスが 「利用可能」の CEV のみを返します。「検証中」やその他のステータスの CEV を表示するには、 --include-all フラグを含めてください。 ステップ 3: RDS インスタンスの起動 CEV が「利用可能」のステータスを表示した後、カスタム SQL Server Developer Edition 設定を使用する RDS インスタンスを作成できます。インスタンスは、特定の SQL Server バージョンと累積更新プログラムでデプロイされます。 Aurora と RDS の AWS マネジメントコンソールから、左側のナビゲーションペインで「データベース」を選択し、次に「データベースの作成」を選択します。 データベース作成ページで、インスタンスに必要な設定を入力し、エンジンオプションが正しく設定されていることを確認してください。 エンジンのタイプ : Microsoft SQL Server を選択 データベース管理タイプ : Amazon RDS を選択 エディション : SQL Server Developer Edition を選択 カスタムエンジンバージョン : ドロップダウンメニューから希望する CEV を選択 ユースケースに合わせて、DB インスタンスサイズ、ストレージ、接続性の設定を定義してください。 「データベースの作成」をクリックします。 または、AWS CLI を使用して RDS インスタンスを作成することもできます。 aws rds create-db-instance \ --db-instance-identifier sqlserver-dev-ed \ --db-instance-class db.m6i.xlarge \ --engine sqlserver-dev-ee \ --engine-version 16.00.4215.2.sql-server-dev-ed-cev \ --allocated-storage 200 \ --master-username admin \ --master-user-password your-secure-password-here \ --license-model bring-your-own-license \ --no-multi-az \ --vpc-security-group-ids sg-xxxxxxxxx\ --db-subnet-group-name my-db-subnet-group-name \ --backup-retention-period 7 \ --region us-west-2 Code 重要な制限事項と考慮事項 Amazon RDS 上の SQL Server Developer Edition には以下の制限と考慮事項があります : Microsoft のライセンス条項に準拠し、本番ワークロードでは適切なライセンスの SQL Server エディションを使用することを確実にする責任があります。 マルチ AZ デプロイメントとリードレプリカは現在サポートされていません。 CEV はリージョンとアカウント固有であり、リージョン間でのコピーや AWS アカウント間での共有はできません。現在のリージョン可用性については、 Amazon RDS ドキュメント を参照してください。 最新の累積更新プログラムで DB インスタンスをアップグレードするには、Amazon RDS でサポートされている最新の CU を使用して新しい CEV を作成する必要があります。データベースインスタンスに最新の更新プログラムを適用するには、この投稿で説明されているのと同じ新しい CEV 作成プロセスに従う必要があります。詳細については、「 データベースマイナーバージョンアップグレードの適用 」を参照してください。 RDS DB インスタンス、DB スナップショット、バックアップなどの関連リソースがある場合、CEV を削除することはできません。 SQL Server Developer Edition 自体は開発およびテスト目的では無料ですが、以下のコストを考慮する必要があります： Amazon RDS インスタンス コスト データベースとバックアップの Amazon RDS ストレージ コスト インストールファイルの Amazon S3 ストレージコスト データ転送 コスト セキュリティとパフォーマンスを維持するため、インストールファイルと累積更新プログラムを最新の状態に保ってください。 下位環境でのコスト削減を最大化するために Developer Edition の使用を組み合わせて、不要な時には定期的なシャットダウンを実装してください。 クリーンアップ 継続的な課金を防ぐため、このウォークスルーで作成したリソースが不要になったら削除してください。 RDS for SQL Serve インスタンスを削除します。手順については、「 DB インスタンスの削除 」を参照してください。 カスタムエンジンバージョンを削除します。手順については、「 カスタムエンジンバージョンの削除 」を参照してください。 S3 バケットを削除します。手順については、「 バケットの削除 」を参照してください。 結論 この投稿では、Amazon RDS 上で SQL Server Developer Edition の作成およびデプロイする方法をご紹介しました。インストールファイルの準備と Amazon S3 へのアップロードから、CEV の作成、そして最終的な RDS インスタンスの起動までのプロセスを見てただきました。Amazon RDS 上の SQL Server Developer Edition は、Enterprise ライセンス料金なしで、非本番環境において Enterprise Edition の機能と Amazon RDS の自動管理機能を提供します。Amazon S3 にアップロードされたインストールファイルから CEV を作成し、それらを使用して開発およびテスト環境用の複数のデータベースインスタンスを作成しながら、本番レベルの一貫性を確保することができます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Sudhir Amin Sudhir は、ニューヨークを拠点とする AWS のシニアソリューションアーキテクトです。彼は様々な業界のお客様に対してアーキテクチャのガイダンスと技術支援を提供し、クラウド導入の促進を支援しています。仕事以外では、スヌーカーやボクシング、UFC などの格闘技に情熱を注いでいます。また、世界各地の野生動物保護区を旅行し、雄大な動物たちを自然の生息地で観察することを楽しんでいます。 Mesgana Gormley Mesgana は、AWS のシニアデータベーススペシャリストソリューションアーキテクトで、Amazon RDS チームで働いています。彼女は、AWS のお客様に技術的なガイダンスを提供し、AWS 上でリレーショナルデータベースワークロードの移行、設計、デプロイ、最適化を成功させる支援に注力しています。仕事以外では、旅行や家族や友人との質の高い時間を過ごすことを楽しんでいます。 Kalyan Banala Kalyan は、AWS の Amazon RDS Custom for SQL Server チームで活躍するデータベースエンジニアです。複雑な技術的課題を解決することを楽しみ、チームメイトや AWS のお客様との知識の学び合いや共有に情熱を注いでいます。

本ブログは 2025 年 12 月 16 日に公開された AWS Blog “ GuardDuty Extended Threat Detection uncovers cryptomining campaign on Amazon EC2 and Amazon ECS ” を翻訳したものです。 Amazon GuardDuty と AWS の自動セキュリティ監視システムは、2025 年 11 月 2 日に開始された暗号通貨マイニングキャンペーンを検出しました。この攻撃は、侵害された AWS Identity and Access Management (IAM) 認証情報を使用して、 Amazon Elastic Container Service (Amazon ECS) と Amazon Elastic Compute Cloud (Amazon EC2) を標的としています。 GuardDuty 拡張脅威検出 は、これらのデータソース全体のシグナルを相関させ、重大度がクリティカルの攻撃シーケンスの検出結果を生成しました。 Amazon Web Services (AWS) の大規模で高度な脅威インテリジェンス機能と既存の検出メカニズムを活用し、GuardDuty はこの進行中のキャンペーンをプロアクティブに特定し、お客様に脅威を迅速に通知しました。AWS は、お客様がこの進行中のキャンペーンに対して適切な対策を講じられるよう、関連する検出結果と緩和策のガイダンスを共有しています。 重要な点として、これらのアクションは AWS サービスの脆弱性を悪用するものではなく、正規の認証情報が侵害され、本来の所有者が意図しない方法で攻撃者に悪用されることで発生します。これらのアクションは 責任共有モデル におけるお客様の責任範囲で発生しますが、AWS はこのようなアクティビティを検出、防止、または影響を軽減するためにお客様が実施できる手順を推奨しています。 暗号通貨マイニングキャンペーンの概要 今回検出された暗号通貨マイニングキャンペーンでは、インシデントレスポンスを妨害し、マイニング活動を長期化させるように設計された新たな永続化手法が使用されていました。GuardDuty のセキュリティエンジニアが、複数の AWS カスタマーアカウントで類似した攻撃手法が使用されていることを発見し、このキャンペーンを特定しました。これは、侵害された IAM 認証情報を使用してお客様を標的とした組織的なキャンペーンであることを示しています。 脅威アクターは外部のホスティングプロバイダーを拠点として、Amazon EC2 のサービスクォータと IAM 権限を素早く列挙した後、Amazon EC2 と Amazon ECS 全体に暗号通貨マイニングリソースをデプロイしました。脅威アクターが初期アクセスを取得してから 10 分以内に、暗号通貨マイナーが稼働を開始しました。 この攻撃で観測された主要な手法は、 ModifyInstanceAttribute を使用して 終了保護 (DisableApiTermination) を true に設定 することでした。これにより、被害者は影響を受けたリソースを削除する前に終了保護を無効にする必要があります。インスタンス終了保護を有効にすることで、インシデント対応者にとって追加の考慮事項が生じ、自動修復コントロールが妨害される可能性があります。脅威アクターが複数のコンピューティングサービスをスクリプト化して使用し、新たな永続化手法と組み合わせたことは、セキュリティチームが認識すべき暗号通貨マイニングの永続化手法の進化を示しています。 GuardDuty の複数の検出機能は、EC2 ドメイン/IP 脅威インテリジェンス、異常検出、および拡張脅威検出の EC2 攻撃シーケンスを通じて、悪意のあるアクティビティを的確に特定しました。GuardDuty 拡張脅威検出は、シグナルを AttackSequence:EC2/CompromisedInstanceGroup の検出結果として相関させることができました。 侵害の痕跡 (IoC) セキュリティチームは、この暗号通貨マイニングキャンペーンを特定するために、以下の IoC を監視する必要があります。脅威アクターは戦術と手法を頻繁に変更するため、これらの指標は時間の経過とともに変化する可能性があります。 悪意のあるコンテナイメージ: 2025 年 10 月 29 日に作成され、10 万回以上プルされた Docker Hub イメージ yenik65958/secret が、コンテナ化された環境に暗号通貨マイナーをデプロイするために使用されました。この悪意のあるイメージには、暗号通貨マイニング用の SBRMiner-MULTI バイナリが含まれていました。この特定のイメージは Docker Hub から削除されましたが、脅威アクターは別の名前で類似のイメージをデプロイする可能性があります 自動化とツール: 攻撃チェーン全体で、Python ベースの自動化スクリプトを示す AWS SDK for Python (Boto3) のユーザーエージェントパターンが使用されました 暗号通貨マイニングドメイン: asia[.]rplant[.]xyz 、 eu[.]rplant[.]xyz 、および na[.]rplant[.]xyz インフラストラクチャの命名パターン: Auto Scaling グループは特定の命名規則に従っていました。スポットインスタンスの場合は SPOT-us-east-1-G* -* 、オンデマンドインスタンスの場合は OD-us-east-1-G* -* で、G はグループ番号を示します 攻撃チェーンの分析 この暗号通貨マイニングキャンペーンは、複数のフェーズにわたって体系的な攻撃の進行をたどりました。本ブログでは、個人を特定できる情報 (PII) を保護するため、機密フィールドには架空の値を使用しています。 図 1: 暗号通貨マイニングキャンペーンの図 初期アクセス、偵察、攻撃準備 攻撃は、異常なネットワークとロケーションから管理者相当の権限を持つ侵害された IAM ユーザー認証情報で開始され、GuardDuty の異常検出の検出結果がトリガーされました。偵察フェーズでは、攻撃者はお客様の AWS 環境を体系的に調査し、どのようなリソースをデプロイできるかを把握しました。攻撃者は Amazon EC2 のサービスクォータ ( GetServiceQuota ) を確認して起動可能なインスタンス数を特定し、次に DryRun フラグを有効にして RunInstances API を複数回呼び出すことで権限をテストしました。 DryRun フラグは、実際にインスタンスを起動することなく IAM 権限を検証できる意図的な偵察手法でした。これにより、コストを回避し、検出される可能性を低減しています。この手法は、脅威アクターが行動を起こす前に暗号通貨マイニングインフラストラクチャをデプロイする能力を検証していたことを示しています。通常 DryRun フラグを使用しない組織は、この API パターンを侵害の早期警告指標として監視することを検討してください。 AWS CloudTrail ログは、 Amazon CloudWatch アラーム 、 Amazon EventBridge 、またはサードパーティツールと組み合わせて、これらの疑わしい API パターンに対するアラートを設定できます。 脅威アクターは、攻撃インフラストラクチャの一部として IAM ロールを作成するために 2 つの API を呼び出しました。Auto Scaling グループ用のロールを作成するための CreateServiceLinkedRole と、 AWS Lambda 用のロールを作成するための CreateRole です。その後、Lambda ロールに AWSLambdaBasicExecutionRole ポリシーをアタッチしました。これら 2 つのロールは、攻撃の影響と永続化フェーズに不可欠でした。 Amazon ECS への影響 脅威アクターはまず、環境全体で数十の ECS クラスターを作成し、1 回の攻撃で 50 を超える ECS クラスターを作成することもありました。次に、悪意のある Docker Hub イメージ yenik65958/secret:user を使用して RegisterTaskDefinition を呼び出しました。クラスター作成時と同じ文字列を使用して、攻撃者はタスク定義を使用してサービスを作成し、 AWS Fargate で実行される ECS タスク上で暗号通貨マイニングを開始しました。以下は、最大 CPU 割り当て 16,384 ユニットを指定した RegisterTaskDefinition の API リクエストパラメータの例です。 { "dryrun": false, "requiresCompatibilities": ["FARGATE"], "cpu": 16384, "containerDefinitions": [ { "name": "a1b2c3d4e5", "image": "yenik65958/secret:user", "cpu": 0, "command": [] } ], "networkMode": "awsvpc", "family": "a1b2c3d4e5", "memory": 32768 } このタスク定義を使用して、脅威アクターは CreateService を呼び出し、希望タスク数を 10 に設定して ECS Fargate タスクを起動しました。 { "dryrun": false, "capacityProviderStrategy": [ { "capacityProvider": "FARGATE", "weight": 1, "base": 0 }, { "capacityProvider": "FARGATE_SPOT", "weight": 1, "base": 0 } ], "desiredCount": 10 } 図 2: 悪意のあるイメージ内の暗号通貨マイニングスクリプトの内容 悪意のあるイメージ ( yenik65958/secret:user ) は、デプロイ後に run.sh を実行するように設定されていました。 run.sh は、マイニングプール asia|eu|na[.]rplant[.]xyz:17155 を使用して randomvirel マイニングアルゴリズムを実行します。 nproc --all フラグは、スクリプトがすべてのプロセッサコアを使用することを示しています。 Amazon EC2 への影響 脅威アクターは 2 つの起動テンプレート ( CreateLaunchTemplate ) と 14 の Auto Scaling グループ ( CreateAutoScalingGroup ) を作成しました。これらは最大サイズ 999 インスタンス、希望キャパシティ 20 という異常に大きいスケーリングパラメータで設定されていました。以下の CreateLaunchTemplate のリクエストパラメータ例では、インスタンスに暗号通貨マイニングを開始するよう指示する UserData が指定されています。 { "CreateLaunchTemplateRequest": { "LaunchTemplateName": "T-us-east-1-a1b2", "LaunchTemplateData": { "UserData": "<sensitiveDataRemoved>", "ImageId": "ami-1234567890abcdef0", "InstanceType": "c6a.4xlarge" }, "ClientToken": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } } 脅威アクターは、スポットインスタンスとオンデマンドインスタンスの両方を使用して Auto Scaling グループを作成し、両方の Amazon EC2 サービスクォータを活用してリソース消費を最大化しました。 スポットインスタンスグループ: 高性能 GPU および 機械学習 (ML) インスタンス (g4dn、g5、p3、p4d、inf1) を標的 オンデマンド割り当て 0%、キャパシティ最適化戦略で設定 20 から 999 インスタンスにスケールするよう設定 オンデマンドインスタンスグループ: コンピューティング、メモリ、汎用インスタンス (c5、c6i、r5、r5n、m5a、m5、m5n) を標的 オンデマンド割り当て 100% で設定 同様に 20 から 999 インスタンスにスケールするよう設定 Auto Scaling クォータを使い果たした後、脅威アクターは RunInstances を使用して追加の EC2 インスタンスを直接起動し、残りの EC2 インスタンスクォータを消費しました。 永続化 このキャンペーンで観測された興味深い手法は、脅威アクターが起動したすべての EC2 インスタンスに対して ModifyInstanceAttribute を使用して 終了保護を有効にしたことです。インスタンス終了保護はインスタンスの誤った終了を防ぐ機能ですが、インシデントレスポンスに追加の手順が必要となり、自動修復コントロールを妨害する可能性があります。以下の例は、 ModifyInstanceAttribute API のリクエストパラメータを示しています。 { "disableApiTermination": { "value": true }, "instanceId": "i-1234567890abcdef0" } すべてのマイニングワークロードをデプロイした後、脅威アクターは IAM 認証をバイパスしてパブリックな Lambda エンドポイントを作成する設定で Lambda 関数を作成しました。その後、任意のプリンシパルが関数を呼び出すことを許可する権限を Lambda 関数に追加しました。以下の例は、 CreateFunctionUrlConfig と AddPermission のリクエストパラメータを示しています。 CreateFunctionUrlConfig: { "authType": "NONE", "functionName": "generate-service-a1b2c3d4" } AddPermission: { "functionName": "generate-service-a1b2c3d4", "functionUrlAuthType": "NONE", "principal": "*", "statementId": "FunctionURLAllowPublicAccess", "action": "lambda:InvokeFunctionUrl" } 脅威アクターは、IAM ユーザー user-x1x2x3x4 を作成し、IAM ポリシー AmazonSESFullAccess をアタッチして永続化段階を完了しました ( CreateUser 、 AttachUserPolicy )。また、そのユーザーのアクセスキーとログインプロファイルも作成しました ( CreateAccessKey 、 CreateLoginProfile )。ユーザーにアタッチされた SES ロールから判断すると、脅威アクターは Amazon Simple Email Service (Amazon SES) を使用したフィッシングを試みていた可能性があります。 パブリックな Lambda 関数 URL の作成を防ぐために、組織は AuthType が "NONE" の Lambda 関数 URL の作成または更新を拒否するサービスコントロールポリシー (SCP) をデプロイできます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:*:*:function/*", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "NONE" } } } ] } GuardDuty による検出方法 GuardDuty の多層検出アプローチは、脅威インテリジェンス、異常検出、および最近リリースされた EC2 および ECS 向けの拡張脅威検出機能 を使用して、攻撃チェーンのすべての段階を特定するのに非常に効果的でした。 次に、これらの機能の詳細と、このような攻撃を検出するためにどのようにデプロイできるかを説明します。本ブログで説明したような暗号通貨マイニングキャンペーンに関するアラートを受け取るには、GuardDuty 基本保護プランを有効にしてください。検出機能をさらに強化するために、 GuardDuty Runtime Monitoring を有効にすることを強くお勧めします。これにより、Amazon EC2、Amazon ECS、および Amazon Elastic Kubernetes Service (Amazon EKS) のシステムレベルのイベントまで検出範囲が拡張されます。 GuardDuty EC2 の検出結果 Amazon EC2 の脅威インテリジェンスの検出結果は GuardDuty 基本保護プランの一部であり、インスタンスに関連する疑わしいネットワーク動作についてアラートを通知します。これらの動作には、ブルートフォース攻撃の試行、悪意のあるドメインや暗号通貨関連ドメインへの接続、その他の疑わしい動作が含まれます。サードパーティの脅威インテリジェンスと、 アクティブ脅威防御 や MadPot を含む内部脅威インテリジェンスを使用して、GuardDuty は以下の検出結果を通じて本ブログで説明した指標を検出します。( CryptoCurrency:EC2/BitcoinTool.B および CryptoCurrency:EC2/BitcoinTool.B!DNS ) GuardDuty IAM の検出結果 複数の戦術カテゴリ (PrivilegeEscalation、Impact、Discovery) にまたがる IAMUser/AnomalousBehavior の検出結果は、通常のユーザー動作からの逸脱を検出する GuardDuty の機械学習機能を示しています。本ブログで説明したインシデントでは、脅威アクターが異常なネットワークとロケーションから認証情報を使用し、アカウントにとって通常とは異なる API を呼び出したため、侵害された認証情報が検出されました。 GuardDuty Runtime Monitoring GuardDuty Runtime Monitoring は、拡張脅威検出の攻撃シーケンス相関において重要なコンポーネントです。Runtime Monitoring は、オペレーティングシステムの可視性などのホストレベルのシグナルを提供し、ホストおよびコンテナレベルでの悪意のあるプロセス実行を示すシステムレベルのログを分析することで検出範囲を拡張します。これには、ワークロード上での暗号通貨マイニングプログラムの実行も含まれます。 CryptoCurrency:Runtime/BitcoinTool.B!DNS および CryptoCurrency:Runtime/BitcoinTool.B の検出結果は、暗号通貨関連のドメインおよび IP へのネットワーク接続を検出し、 Impact:Runtime/CryptoMinerExecuted の検出結果は、実行中のプロセスが暗号通貨マイニングアクティビティに関連している場合に検出します。 GuardDuty 拡張脅威検出 AWS re:Invent 2025 でリリースされた AttackSequence:EC2/CompromisedInstanceGroup の検出結果は、 GuardDuty の最新の拡張脅威検出機能 の 1 つです。この機能は、AI と機械学習アルゴリズムを使用して、複数のデータソースにわたるセキュリティシグナルを自動的に相関させ、EC2 リソースグループの高度な攻撃パターンを検出します。EC2 の AttackSequence 検出結果タイプは GuardDuty 基本保護プランに含まれていますが、Runtime Monitoring を有効にすることを強くお勧めします。Runtime Monitoring は、コンピューティング環境からの重要なインサイトとシグナルを提供し、疑わしいホストレベルのアクティビティの検出と攻撃シーケンスの相関の改善を可能にします。 AttackSequence:ECS/CompromisedCluster の攻撃シーケンスでは、コンテナレベルのアクティビティを相関させるために Runtime Monitoring が必要です。 監視と修復の推奨事項 同様の暗号通貨マイニング攻撃から保護するために、お客様は強力な ID およびアクセス管理コントロールを徹底する必要があります。長期的なアクセスキーの代わりに一時的な認証情報を実装し、すべてのユーザーに多要素認証 (MFA) を適用し、IAM プリンシパルに最小権限を適用して必要な権限のみにアクセスを制限してください。AWS CloudTrail を使用して AWS サービス全体のイベントをログに記録し、ログを単一のアカウントに集約することで、セキュリティチームがアクセスして監視できるようにすることができます。詳細については、CloudTrail ドキュメントの 複数のアカウントから CloudTrail ログファイルを受信する を参照してください。 すべてのアカウントとリージョンで GuardDuty が有効になっており、包括的なカバレッジのために Runtime Monitoring が有効になっていることを確認してください。GuardDuty を AWS Security Hub および Amazon EventBridge またはサードパーティツールと統合して、自動応答ワークフローと重大度の高い検出結果の迅速な修復を可能にしてください。イメージスキャンポリシーや ECS タスク定義での異常な CPU 割り当てリクエストの監視など、コンテナセキュリティコントロールを実装してください。最後に、暗号通貨マイニング攻撃に対する具体的なインシデントレスポンス手順を確立してください。これには、終了保護が有効化されたインスタンスを処理するための文書化された手順が含まれます。これは、この攻撃者が修復作業を複雑にするために使用した手法です。 AWS アカウントが暗号通貨マイニングキャンペーンの影響を受けたと思われる場合は、GuardDuty ドキュメントの修復手順を参照してください。( 侵害された可能性のある AWS 認証情報の修復 、 侵害された可能性のある EC2 インスタンスの修復 、および 侵害された可能性のある ECS クラスターの修復 ) 最新の手法について最新情報を入手するには、 Threat Technique Catalog for AWS をご覧ください。 本ブログに関するご質問がある場合は、 AWS サポート にお問い合わせください。 Kyle Koeller Kyle は GuardDuty チームのセキュリティエンジニアで、脅威検出に注力しています。クラウドの脅威検出とオフェンシブセキュリティに情熱を持ち、CompTIA Security+、PenTest+、CompTIA Network Vulnerability Assessment Professional、SecurityX の認定資格を保有しています。仕事以外の時間は、ジムで過ごしたり、ニューヨーク市を探索したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 13 日に公開された AWS Blog “ AWS CIRT announces the launch of the Threat Technique Catalog for AWS ” を翻訳したものです。 AWS Customer Incident Response Team (AWS CIRT) よりお届けします。AWS CIRT は、 AWS 責任共有モデル においてお客様側で進行中のセキュリティイベントに対して、24 時間 365 日体制でグローバルに対応する Amazon Web Services (AWS) のスペシャリストチームです。本日 (2025 年 6 月 13 日)、AWS は Threat Technique Catalog for AWS の公開を発表しました。 AWS CIRT がセキュリティ調査中にお客様のインシデント対応を支援する際、脅威アクターが AWS のお客様に対して使用した戦術や技術の種類に関する AWS サービスメタデータを収集しています。AWS はこの情報を使用し、 侵害の痕跡 (IOC) と脅威パターンの内部データセットを構築しています。このデータセットにより、脅威アクターが設定不備のある AWS リソースや過度に許可されたアクセスをどのように悪用しているか、また目的を達成するためにどのような手法を使用しているかについての洞察が得られます。 AWS はこのメタデータを取得し、内部で活用して AWS サービスを継続的に改善しています。これにより、脅威アクターが不正なアクションを実行することをより困難にし、お客様にとってより安全なサービスを提供しています。例えば、脅威アクターが Amazon Bedrock サービスを使用して 大規模言語モデル (LLM) を呼び出してトークンを消費したセキュリティイベントの調査で AWS CIRT が取得したメタデータの一部は、 Amazon GuardDuty の IAM Anomalous Behavior 検出結果 の補完に使用されています。2025 年初頭に、AWS CIRT は、クライアント提供キーによるサーバー側暗号化 (SSE-C) と呼ばれる暗号化方式を使用した Amazon S3 でのデータ暗号化イベントの増加を特定しました 。AWS CIRT は Threat Technique Catalog for AWS を使用して、これらのセキュリティイベントで特定された新しい技術を分類し、内部および他の Amazon セキュリティチームと情報を共有しました。 AWS CIRT が観測した敵対的な戦術、技術、手順 (TTP) に関する情報が利用可能になれば、AWS リソースをより安全に設定するために活用できるため、価値があり役立つというフィードバックを AWS のお客様からいただいています。過去 1 年間、AWS は MITRE と協力して、これらの技術とサブテクニックをグローバルなセキュリティコミュニティに提供できるよう取り組んできました。この協力の結果、MITRE は 2024 年 10 月のアップデート で、これらの技術の一部を MITRE ATT&CK® に更新および追加しました (例: Data Destruction: Lifecycle-Triggered Deletion )。 「AWS が共有してくださった洞察に大変感謝しており、それが MITRE ATT&CK の 2024 年 10 月リリースにおける多くの技術の改善につながりました。ATT&CK が最新の脅威に対応し続けるためには、エコシステムに貢献するコミュニティの協力が必要であり、AWS が ATT&CK コミュニティの一員であることを高く評価しています。」 – MITRE Corporation MITRE ATT&CK プロジェクトリード Adam Pennington 企業、団体、組織は、オンプレミス環境への脅威を理解し、優先順位を付け、保護するために ATT&CK を使用しています。AWS は、これらの敵対的な技術を既存のフレームワークを活用して提示することで、AWS のお客様とグローバルなセキュリティコミュニティが、AWS CIRT と同じ方法で AWS インフラストラクチャ上の脅威を特定し分類できるようになると考えています。 MITRE ATT&CK Cloud に基づく Threat Technique Catalog for AWS は、これらの貢献を拡張し、AWS に固有で AWS CIRT が観測した敵対的な技術のカテゴリを含んでいます。さらに、それらの技術を軽減する方法と検出方法に関する情報も含まれています。例えば、Threat Technique Catalog for AWS にアクセスし、アカウント内の AWS サービスでフィルタリングして、環境をより安全にするのに役立つコンテンツを確認できます。 Getting started セクションには、Threat Technique Catalog for AWS を使用するその他の方法が含まれています。AWS は、AWS 環境をより安全にするためのガイドとなるよう、Threat Technique Catalog for AWS を継続的に更新し、追加の変更を提供していきます。また、新しいトレンドの脅威アクター技術について MITRE に情報提供するための協力も継続していきます。 このガイドを使用するには、 Threat Technique Catalog for AWS にアクセスしてください。 © 2025 The MITRE Corporation. この著作物は The MITRE Corporation の許可を得て複製・配布されています。 Steve de Vera Steve は AWS Customer Incident Response Team (CIRT) のマネージャーで、脅威リサーチと脅威インテリジェンスを担当しています。アメリカンスタイルの BBQ に情熱を持ち、BBQ コンテストの公認審査員でもあります。愛犬の名前は Brisket です。 Cydney Stude Cydney は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアで、インシデント対応とクラウドセキュリティを専門としています。技術的な深さと、複雑なクラウドの課題に対処する実践的な経験を重視しています。仕事以外では、サルサダンスやジャーマンシェパードとの冒険を楽しんでいます。 Nathan Bates Nathan は Global Services Security のシニアセキュリティエンジニアです。脆弱性管理、ポリシーコンプライアンス、アセット保証、インシデント対応、脅威インテリジェンスのためのデータ、分析、レポートサービスを専門としています。ハイパフォーマンスドライビング、レーシングカー、ギター演奏、音楽制作に情熱を持っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。