ニフティ株式会社では、ネットワークサービス事業と Web サービス事業の 2 軸でビジネスを展開しています。 @nifty光など、各種サービスの申込みや開通状況の確認など接続サービスで使用しているデータベースを 2024 年 5月に Amazon RDS for Oracle へ移行しました。本ブログでは、 Amazon RDS for Oracle への移行検討から移行後の効果について、お客様の声を紹介いたします。 移行検討の背景と課題 同社は、長年利用していたレガシーシステムに課題を抱えており、これらを解決するためにアマゾン ウェブ サービス (AWS) への移行を進めています。Web サービスを提供している約 800 台のサーバーの移行を終え、現在はネットワークサービス事業用の基幹システムの移行を進めています。その中の 1 つの接続サービスで使用しているデータベースが稼働しているサーバーのハードウェア老朽化と保守期限が迫ってきていたため、早期の移行が必要でした。また、高額なランニングコストや、そのコストに見合う機能を使い切れていないという課題を抱えていました。運用面では、データベースのメンテナンスタイミングをサービス都合で選択できず、ベンダーの指定タイミングに従わざるを得ない制約があり、さらにメモリ不足による予期せぬフェイルオーバーが発生するなど、安定性にも問題を抱えていました。 AWS での構築システムが多く、親和性が高かったため、Amazon RDS for Oracle を選択しました。また、同種エンジンの Amazon RDS for Oracle の最適なライセンスモデルを移行先とすることで、コスト最適化を目指すとともに、クラウドの弾力性を活かし、適切なサイジングにより、更なるコスト最適化を目指しました。ライセンスやサイジングの最適化を行えた理由としては、移行後、万が一性能要件を満たせないことが判明した場合でも、直ぐにスペックアップにより対応できることも判断理由の一つです。また、課題となっていたメンテナンスタイミングは、メンテナンスウィンドウの調整により実現しました。 アーキテクチャと移行プロセス ニフティの回線サービスに関するデータ ( 顧客の申込情報や契約進捗状況など ) は、統合データベースで一元管理されています。このデータベースには、各回線サービスシステムからアクセスが可能です。システムは AWS だけでなく、他のクラウド環境にも構築されているため、VPN 経由でアクセスが行われます。 2022 年 から移行検討を開始し、AWS のデータベース移行支援プログラムを活用し、Statspack レポート分析や AWS Schema Conversion Tool レポート分析を AWS の Solutions Architect とともに実施し、移行難易度の調査やサイジングを行い、事前に移行難易度が低いことを確認しました。 2023 年 6 月から移行の本格検討を開始し、2023 年 9 月から 3 か月間 PoC を実施し、2023 年 12 月から 2024 年 2 月にかけて、データベースの設計、構築、データ移行の準備を進めました。そして、 2024 年 2 月から 5 月にかけて、段階的に移行を進めました。データベース移行のデータ移行では、約 4000 のオブジェクト ( 内 プロシージャ 150 ) 、約 1 TB のデータを、マテリアライズドビューを使用して、Amazon RDS へ移行しました。 移行方式採用の理由としては、データサイズが大きいため、ダウンタイムが長くなる懸念がありました。差分移行を行う上で、ネイティブ機能を利用した移行のほうが、安全性が高いと判断し、マテリアライズドビューを使用して、高速リフレッシュにより差分データを移行し、移行当日にマテリアライズドビューをテーブルに切り替えて行う移行方式を採用しました。この移行方式により、本番データベースの CPU 使用率が通常時から比べ 30% ほど上昇しましたが、業務処理への影響はありませんでした。 また、移行時の課題として、サービス影響を最小限にするため、アプリケーション移行対象スキーマが約 50 あり、スキーマ間で参照権限が設定されている箇所が多数あったため、移行順序を精査しながら、移行計画を作成しました。また、移行完了後、移行元環境に残っているアプリケーションとデータベース間のネットワークレイテンシーの増加により、処理時間が延びる事象は発生しましたが、PoC で予め検知できていたため、今後、AWS 環境に移行することで改善される事象として、課題管理できており、大きな問題にはなりませんでした。 Amazon RDS への移行の効果 2023 年 6 月 から、今回のシステムのデータベースの移行を検討し始め、約 1 年で移行を完了しました。移行した結果、ライセンス最適化によるライセンスコストの削減だけでなく、スペック最適化により、ランニングコストの削減に成功しました。 また、マネージドサービスを活用することで、運用・保守作業の大幅な効率化ができ、バックアップ運用やパッチ準備などの運用負荷が下がっただけでなく、ベンダー都合によるメンテナンス対応に追われることがなくなり、任意のスケジュールでメンテナンスが可能になりました。また、最適なサイジングの結果、移行前のような予期せぬフェイルオーバーも発生しなくなり、安定性も向上しました。マネージドサービスの活用により、サーバーへ直接ログインした不正アクセスの防止など潜在的に潜んでいたセキュリティリスクの低減だけでなく、データベースの構築・運用作業が簡素化されたことにより、これまでベテランエンジニアの専任領域となっていたデータベース関連の作業に、若手エンジニアも積極的に携われるようになりました。結果として、エンジニアのスキル育成にも良い影響を与えています。その流れに合わせて、運用手順の整備や業務効率化をする機会にでき、クラウド移行を前向きな良い機会とすることができています。 コスト面では、Amazon RDS 移行によりシステム環境のランニングコストを 77 % 削減という効果を出せています。 今後に向けて ニフティ株式会社 基幹システムグループ 中廣 可奈子氏からのコメント： まだ、他にも WEB やバッチなどのアプリケーション環境が旧環境に残っているため、引き続き移行を推進していきます。 AWS への移行完了後、マイクロサービス化など、更なるアーキテクチャ最適化を目指していきます。 まとめ ニフティ株式会社では、Amazon RDS に移行することで、システム環境のコストを77%削減しました。また、運用・保守作業の効率化、メンテナンス時期の柔軟な選択が可能になり、システムの安定性とセキュリティも向上しました。さらに、若手エンジニアの育成機会の創出にもつながっています。

Amazon Multi-Channel Fulfillment and Buy with Prime Accelerators for SAP S/4HANA のご紹介 本日、 Amazon Multi-Channel Fulfillment（MCF）and Buy with Prime Accelerators for SAP S/4HANA の提供開始を発表できることを嬉しく思います。この強力な統合により、SAPのお客様は既存のSAP S/4HANA実装を活用してAmazon MCFおよびBuy with Primeを利用できるようになります。これにより、Amazonのフルフィルメントインフラストラクチャの潜在能力を最大限に活用し、ビジネスを成長させ、カスタマーエクスペリエンスを向上させることができます。 この発表は、地球上で最もお客様を大切にする企業であるという私たちの使命に貢献するいくつかの取り組みの中心に位置しています。 オンラインショッピング: 私たちは、Amazon.comを通じて何百万ものお客様に利便性、品揃え、低価格を提供することで最もよく知られています。これにより、世界最大のフルフィルメントネットワークを構築し、何百万もの商品を提供できるようになりました。その多くは、Primeメンバー向けに無料の2日配送、さらには当日配送も可能です。 マーチャントの支援: また、マーチャントがAmazon.com、自社のウェブサイト、他のオンライン小売業者、ソーシャルメディアチャネルでビジネスを構築・拡大できるよう支援するプログラムの作成にも力を入れています。 クラウドでのミッションクリティカルなアプリケーションの実行: 同様に、AWSはこのお客様第一の取り組みから生まれました。ITを民主化し、企業がデータセンター管理ではなくコアビジネスに集中できるよう支援しています。お客様は、AWSでミッションクリティカルなSAPシステムを実行している何千ものお客様を含め、事実上すべてのアプリケーションとユースケースにAWSを使用しています。 AWSのお客様からは、Amazonのグローバルな規模、サプライチェーン、運用のベストプラクティスを活用して、フルフィルメントとeコマース業務を変革する方法について、ますます多くのお問い合わせをいただいています。Amazon MCFやBuy with Primeなどのソリューションにより、私たちは世界クラスの物流ネットワークを自社のストアを超えて拡張し、ブランドがまさにそれを実現できるよう支援しています。 マーチャントがAmazon MCFとBuy with Primeを愛用する理由 Amazon Multi Channel Fulfilment（MCF） は、マーチャントがAmazonのフルフィルメントネットワークを活用して、すべての販売チャネルで注文のピッキング、梱包、発送、配送を行えるようにするサードパーティロジスティクス（3PL）ソリューションです。Amazon MCFを使用することで、マーチャントはAmazonのフルフィルメントネットワーク内の単一の在庫プールを活用して、在庫切れ率を削減し、在庫回転率を向上させ、運用効率を高めることができます。マーチャントは、 Amazon以外の小売チャネルにMCFを追加して以来、平均で売上または収益が約19%増加した と報告しています。 Buy with Prime は、ブランドが自社のウェブサイトで直接、迅速で無料の配送、簡単な返品、24時間年中無休のショッパーサポート、Amazonからのレビューなど、Primeショッピングの特典を提供することで、ビジネスを成長させるのに役立ちます。Amazonは、お客様が知っていて、愛し、信頼しているショッピング体験をブランドが提供できるよう支援することで、マーチャントが新しいショッパーを引き付け、既存のお客様を維持するのを支援します。実際、 Buy with Primeを使用したショッパーの95%が再度使用する可能性が非常に高いと回答し*、マーチャントはBuy with Primeを提供することで、平均してショッパーあたりの収益が16%増加しました** 。 SAP S/4HANA向けAmazon MCFおよびBuy with Primeアクセラレーターは、SAP Business Technology Platform（SAP BTP）とSAP Integration Suite、およびAmazonの事前構築されたAPIを活用して、必要な統合作業を最大75%削減し、多くのお客様が6週間以内に本番稼働できるようにします。 「お客様は単なるクラウドプロバイダーを求めているのではなく、成長を支援し、運用の回復力を向上させ、お客様により良いサービスを提供できる変革パートナーを求めています」 と、AWSのWW SAP Go-To-Market担当ゼネラルマネージャーであるSara Alligoodは述べています。 「私たちは、SAPとのパートナーシップを拡大し、マーチャントがSAP S/4HANAで実行されている既存のビジネスプロセスに破壊的な変更を加えることなく、Amazon Multi-Channel FulfilmentとBuy with Primeの力を活用できるよう支援できることを嬉しく思います。」 「Buy with PrimeとSAP S/4HANAをSAP Integration Suiteと統合することで、お客様はAmazonのグローバルネットワークと運用のベストプラクティスにアクセスでき、業界を超えた小売業者が注文管理を最適化し、運用コストを削減しながらカスタマーエクスペリエンスを向上させることができます」 と、SAP BTPのプレジデントでありSAP SEの拡大役員会メンバーであるDr Michael Amelingは述べています。 仕組み この統合は、 SAP BTP を活用して既存のシステムを接続するというシンプルさを念頭に設計されています。Multi-Channel Fulfilment APIとBuy with Prime APIは、組織の既存の注文管理およびeコマースシステムがeコマースとフルフィルメントをサポートするAmazonシステムと対話するためのプログラマティックな方法を提供します。APIを使用するマーチャントは、検索、商品ページ、カート、チェックアウトなど、既存のウェブサイトエクスペリエンスにBuy with Primeおよび/またはMCFを追加し、日々の注文データをバックエンドアプリケーションに統合できます。 従来、MCFとBuy with Primeを活用したいSAPのお客様は、SAP S/4HANAシステムがAmazonの注文データの受け入れ、Prime商品がAmazonによってフルフィルされるようにフルフィルメントリクエストを分割する、または注文後の更新を受信するなどの機能を実行できるようにするために、いくつかのバックエンド変更を行っていました。SAPのお客様からは、初期実装を簡素化し、SAP S/4HANAシステムとAmazonのBuy with Prime APIとの統合を容易にする方法について、ますます多くのお問い合わせをいただいています。 SAP S/4HANA向けAmazon MCFおよびBuy with Primeアクセラレーターは、このプロセスを劇的に簡素化します。これらは、既存のSAPワークフローと構成とシームレスに連携する、さまざまなeコマースフルフィルメントのユースケースをサポートする、すぐに使える一般的なインタラクションを提供します。アクセラレーターにはSAP Integration Suiteが必要です。お客様は、既存のSAP Integration Suiteへの投資を活用するか、 AWS MarketplaceからSAP Integration Suiteをサブスクライブ できます。 SAP S/4HANAシステムをAmazonのMCFおよびBuy with Prime APIに接続するだけで、Amazonのフルフィルメントネットワークの力を活用し始めることができます。この統合により、SAP S/4HANAでレコードを取得、作成、更新できます。 現在、以下のモジュールが利用可能です： モジュール 機能 Fulfill with Customer すべてのeコマース注文をCustomerでフルフィル Fulfill with Customer 選択した商品のeコマース注文をCustomerでフルフィル Fulfill with Customer フルフィルメントのキャンセルを許可 Fulfill with Customer 注文ステータスの更新をCustomerに送信 Customer Fulfillment Status Updates パッケージフルフィルメントの更新を受信 Customer Fulfillment Status Updates パッケージキャンセルの更新を受信 Customer Fulfillment Status Updates パッケージ配送マイルストーンステータスを受信 Returns through Customer Customerを通じて返品を受信 Returns through Customer 返品注文の更新を受信 Returns Outside Customer 返品詳細をCustomerと同期 Customer Refund Updates Customerから返金準備完了通知を受信 Customer Refund Updates Customerが発行した返金の詳細を受信 Synchronize issue refunds 発行された返金を同期 Customer Inventory Updates Customerからリアルタイムの在庫更新を受信 Customer Inventory Updates Customerから定期的な在庫更新を受信 前提条件 アクセラレーターをインストールする前に、以下の前提条件を満たしていることを確認してください。 eコマースサイトで注文が行われた場合、SAP S/4HANAは、eコマースサイトによって生成された注文詳細をキャプチャするように設定されている必要があります。 生成された注文詳細に、Buy with Primeを通じてPrime配送で購入された商品がタグ付けされるように、eコマースサイトを変更する必要があります。 SAP Integration Suiteをサブスクライブします。 オプションで、Buy with Primeを通じて提供される商品を、Amazonでのみフルフィルしたい場合は、そのような商品にタグを付けることもできます。 今すぐ始めましょう SAPランドスケープを変革し、優れたカスタマーエクスペリエンスを提供する準備はできていますか？ Amazon MCF and Buy with Prime Accelerators for SAP S/4HANA は、SAP Business Accelerator Hubからダウンロードできます。 eコマースと注文フルフィルメント機能のモダナイゼーションについて詳しく知りたい場合は、 AmazonのMCFページ および Buy with Primeページ をご覧ください。SAP BTPがエンタープライズ向けに構築されたテクノロジープラットフォームで、ミッションクリティカルなビジネスプロセスのためのAI、データ、アプリケーションの潜在能力を最大限に引き出す方法については、 SAP BTP をご覧ください。 AWSは、このプロジェクトとブログ投稿へのサポートについて、Aaron Graberと拡大SAPチームに感謝します。 *出典：Buy with Prime購入後カスタマー調査、2024年8月 **このデータポイントは、2023年7月から2024年6月の間に167のマーチャントから収集されたA/Bテスト結果に基づいており、同じ期間中にBuy with Primeが購入オプションであった場合とそうでなかった場合に生成された収益の平均増加を測定しています。 リソース SAP on AWS Case Studies SAP on AWS FAQ Contact Us Find a Partner 本ブログはAmazon Bedrockによって翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本ブログは 2025 年 11 月 21 日に公開された AWS Blog “ Accelerate investigations with AWS Security Incident Response AI-powered capabilities ” を翻訳したものです。 セキュリティイベントの調査で、 AWS CloudTrail のログを何時間もかけて手動で調べ、 AWS Identity and Access Management (IAM) の権限を確認し、タイムラインをつなぎ合わせた経験がある方なら、インシデント調査に必要な時間と労力をよくご存知でしょう。本日 (2025 年 11 月 21 日)、 AWS Security Incident Response に AI を活用した調査機能を追加したことを発表します。この機能により、証拠収集と分析作業が自動化されます。 AWS Security Incident Response は、セキュリティイベントへの準備、対応、復旧をより迅速かつ効果的に行えるよう支援するサービスです。今回追加された AI を活用した調査機能は、セキュリティ検出結果の自動監視・自動トリアージや封じ込めといった既存機能、そして AWS Customer Incident Response Team (CIRT) への 24 時間 365 日のダイレクトアクセスと組み合わせて提供されます。 不審な API コールや異常なネットワークアクティビティを調査する際には、何が起こったのか全体像を把握する必要があります。そのためには、複数のデータソースへのクエリ、タイムスタンプの照合、関連イベントの洗い出しなど、多くの作業が求められます。セキュリティオペレーションセンター (SOC) のアナリストは、各調査に多大な時間を費やしており、その約半分は様々なツールや複雑なログから証拠を手動で収集してつなぎ合わせる作業に費やされています。この手作業が、分析と対応を遅らせる原因となっています。 AWS は Security Incident Response に調査エージェントを導入し、この状況を変え、効率を飛躍的に高めます。調査エージェントにより、潜在的なセキュリティイベントの検証と対応に必要な時間を大幅に短縮できます。セキュリティの問題についてケースが作成されると (お客様が作成した場合でも、Security Incident Response が自動的に作成した場合でも)、調査エージェントはまず状況を正確に把握するための確認質問を行います。その後、CloudTrail イベント、IAM 設定、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの詳細から自動的に証拠を収集し、コスト使用パターンも分析します。数分以内に、証拠を相関付け、パターンを特定し、明確な調査サマリーを提示します。 実際の動作 例を見る前に、調査エージェントの使い方と、その目的・機能について説明します。調査エージェントは、Security Incident Response に標準で備わっており、ケースを作成すると自動的に利用可能になります。その目的は、最初の対応者として機能することです。証拠を収集し、AWS サービス全体のデータを相関付け、イベントの包括的なタイムラインを作成することで、検出から復旧まで迅速に進めることができます。 例えば、アカウント内の IAM ユーザーの AWS 認証情報がパブリックな GitHub リポジトリで公開されていることを発見したとします。その認証情報でどのようなアクションが実行されたかを把握し、ラテラルムーブメント (横方向への移動) や偵察活動を含め、影響範囲を特定する必要があります。作成された可能性のある永続化メカニズムを特定し、適切な封じ込め手順を決定する必要があります。開始するには、 Security Incident Response コンソール でケースを作成し、状況を説明します。 ここで、エージェントのアプローチが従来の自動化と異なる点があります。まず状況を正確に把握するための確認質問を行います。 認証情報が最初に公開されたのはいつですか? IAM ユーザー名は何ですか? すでに認証情報をローテーションしましたか? 影響を受けている AWS アカウントはどれですか? このインタラクティブなステップにより、証拠収集を開始する前に適切な詳細とメタデータを収集します。つまり、汎用的な結果ではなく、個々のインシデントに特化した調査が行われます。 エージェントが必要な情報を得ると、調査を開始します。CloudTrail イベントを調べて、侵害された認証情報を使用してどのような API コールが行われたかを確認し、IAM ユーザーとロールの詳細を取得してどのような権限が付与されていたかを確認し、新しく作成された IAM ユーザーやロールを特定し、コンピューティングリソースが起動された場合は EC2 インスタンス情報を確認し、異常なリソース消費がないかコストと使用パターンを分析します。お客様が各 AWS サービスに個別にクエリを実行する必要はありません。エージェントがこれらを自動的にまとめて処理します。 数分以内に以下の図に示すような調査サマリーが得られます。調査サマリーには、概要と重要な検出結果が含まれます。重要な検出結果には、認証情報の公開パターン、観察されたアクティビティとその発生期間、影響を受けたリソース、調査における制約事項が含まれます。 図 1 – 調査サマリー このレスポンスは AWS の生成 AI 機能を使用して生成されました。特定のコンテキストで推奨事項を評価し、適切な監視とセーフガードを実装する責任はお客様にあります。 AWS の責任ある AI の要件の詳細をご覧ください 。 注 : 上記の例は代表的な出力です。実際のフォーマットは検出結果によって異なります。 調査サマリーには、以下の図に示すようなイベントタイムラインを含む技術的な検出結果など、詳細情報を表示するための様々なタブが含まれています。 図 2 – セキュリティイベントのタイムライン 一刻を争う状況で迅速かつ的確に対応するには、この透明性が不可欠です。AWS の専任セキュリティエキスパートグループである AWS CIRT にエスカレーションする必要がある場合や、経営陣に調査結果を説明する必要がある場合にも、関係者全員が同じ画面でインシデントを確認できます。 調査が完了すると、何が起こったかの高解像度の全体像が得られ、封じ込め、根絶、復旧について十分な情報に基づいた意思決定ができます。上記の認証情報公開シナリオでは、以下の対応が必要になる可能性があります。 侵害されたアクセスキーを削除する 新しく作成された IAM ロールを削除する 不正な EC2 インスタンスを終了する 関連する IAM ポリシーの変更を確認して元に戻す 他のユーザー用に作成された追加のアクセスキーがないか確認する AWS CIRT と連携する際、エージェントが収集した証拠に基づいて、封じ込め戦略に関する追加のガイダンスを受けることができます。 セキュリティ運用への影響 認証情報漏洩のシナリオでは、単一のインシデントに対してエージェントができることを示しました。しかし、エージェントがもたらすメリットはそれだけではありません。日々のセキュリティ運用にも大きな効果があります。 証拠収集にかかる時間を削減できます。 調査エージェントは、調査で最も時間のかかる部分である複数のソースからの証拠収集と相関付けを自動化します。手動のログ分析に 1 時間費やす代わりに、その時間の大部分を封じ込めの意思決定と再発防止に費やすことができます 自然言語で調査できます。 調査エージェントは自然言語処理 (NLP) を使用しており、 unusual API calls from IP address X や data access from terminated employee's credentials のように、調査内容を自然言語で記述できます。エージェントがそれを必要な技術的クエリに変換します。AWS のログ形式に精通していたり、CloudTrail をクエリするための正確な構文を知っている必要はありません 高精度で正確な調査の基盤が得られます。 調査エージェントは、証拠の収集、パターンの特定、包括的なサマリーの提供といった初期調査を処理します。ケースでより深い分析が必要な場合や、複雑なシナリオに関するガイダンスが必要な場合は、AWS CIRT と連携できます。AWS CIRT は、エージェントがすでに行った作業をすぐに活用できるため、対応時間が短縮されます。同じ証拠とタイムラインを確認できるため、ゼロから始めるのではなく、高度な脅威分析と封じ込め戦略に集中できます 開始方法 すでに Security Incident Response を有効にしている場合、AI を活用した調査機能は今すぐ利用可能です。追加の設定は必要ありません。次のセキュリティケースを作成すると、エージェントが自動的に動作を開始します。 Security Incident Response を初めて使用する場合は、以下の手順でセットアップします。 AWS Organizations の管理アカウントから Security Incident Response を有効にする。 AWS マネジメントコンソールから数分で完了し、アカウント全体をカバーできます ケースを作成する。 調査内容を記述します。Security Incident Response コンソールまたは API から行うか、 Amazon GuardDuty または AWS Security Hub のアラートから自動的にケースを作成するよう設定することもできます 分析結果を確認する。 エージェントは Security Incident Response コンソールを通じて検出結果を提示します。 Jira や ServiceNow などの既存のチケットシステムからもアクセスできます 調査エージェントは、AWS サポートの サービスリンクロール を使用して AWS リソースから情報を収集します。このロールは AWS アカウントのセットアップ時に自動的に作成され、サポートツールが CloudTrail イベント、IAM 設定、EC2 の詳細、コストデータをクエリするために必要なアクセス権を提供します。エージェントが実行したアクションは、完全な監査可能性のために CloudTrail に記録されます。 調査エージェントは Security Incident Response に追加費用なしで利用できます。Security Incident Response は現在、毎月最初の 10,000 件の検出結果の取り込みをカバーする 無料利用枠付きの従量課金 を提供しています。それを超える検出結果は、ボリュームに応じて低減する料金で課金されます。この従量課金制のアプローチにより、ニーズの成長に合わせてセキュリティインシデント対応機能をスケールできます。 既存ツールとの連携 Security Incident Response のケースは、お客様が作成することも、サービスが自動的に作成することもできます。調査エージェントは新しいケースが作成されると自動的にトリガーされ、ケースはコンソール、API、または Amazon EventBridge 統合 を通じて管理できます。 EventBridge を使用すると、GuardDuty、Security Hub、Security Incident Response 自体からのセキュリティイベントをルーティングする自動化されたワークフローを構築し、ケースを作成して対応計画を開始できます。これにより、検出から調査までのエンドツーエンドのパイプラインが実現します。調査エージェントが作業を開始する前に、サービスの自動トリアージシステムが GuardDuty およびサードパーティのセキュリティツールからのセキュリティ検出結果を Security Hub を通じて監視およびフィルタリングします。既知の IP アドレスや IAM エンティティなどのお客様固有の情報を使用して、予想される動作に基づいて検出結果をフィルタリングし、アラートボリュームを削減しながら、即座の対応が必要なアラートをエスカレーションします。これにより、調査エージェントは実際に調査が必要なアラートに集中できます。 まとめ この記事では、AWS Security Incident Response の新しい調査エージェントが証拠収集と分析を自動化し、セキュリティイベントの調査に必要な時間を数時間から数分に短縮する方法を紹介しました。エージェントは、状況を正確に把握するための確認質問を行い、複数の AWS データソースに自動的にクエリを実行し、証拠を相関付け、完全な透明性と監査可能性を維持しながら、包括的なタイムラインと調査サマリーを提示します。 調査エージェントの追加により、Security Incident Response のお客様は、必要に応じて AWS セキュリティエキスパートの専門知識と監視に支えられた、AI を活用した自動化のスピードと効率性を得られるようになりました。 AI を活用した調査機能は、Security Incident Response が運用されているすべての商用 AWS リージョンで本日 (2025 年 11 月 21 日) から利用可能です。料金と機能の詳細、または開始方法については、 AWS Security Incident Response 製品ページ をご覧ください。 Daniel Begimher Daniel は Global Services Security のシニアセキュリティエンジニアで、クラウドセキュリティ、アプリケーションセキュリティ、インシデントレスポンスを専門としています。AWS Security and Compliance Technical Field Community 内の Application Security フォーカスエリアを共同でリードし、すべての AWS 認定を保有しています。また、オープンソースのコードスキャンツールである Automated Security Helper (ASH) の作成者でもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 11 月 25 日に公開された AWS Blog “ AWS Secrets Manager launches Managed External Secrets for Third-Party Credentials ” を翻訳したものです。 AWS Secrets Manager は Amazon Web Services (AWS) のシークレットライフサイクルを効果的に管理できます。しかし、クラウドアプリケーションの利用拡大に伴い、サードパーティソフトウェアプロバイダーの認証情報管理が組織にとって新たな課題となっています。複数のサードパーティサービスを利用する組織では、各プロバイダーの認証情報を管理する標準的な方法がなかったため、プロバイダーごとに異なるセキュリティアプローチを開発することがよくあります。これらのサードパーティの認証情報を Secrets Manager に保存する際、サービス接続を容易にするために、シークレット値内に追加のメタデータを保持することが一般的です。このアプローチでは、メタデータが変更されるたびにシークレット値全体を更新する必要があり、プロバイダー固有のシークレットローテーションプロセスを実装する必要がありますが、これは手動で時間がかかります。シークレットローテーションの自動化を検討している組織は、通常、各サードパーティソフトウェアプロバイダーに合わせたカスタム関数を開発しますが、これにはサードパーティと AWS の両方のシステムに関する専門知識が必要です。 お客様がサードパーティのシークレット管理を効率化できるよう、AWS Secrets Manager に新機能「マネージド外部シークレット」を導入しました。このブログでは、この新機能がセキュリティのベストプラクティスを維持しながら、サードパーティソフトウェアの認証情報の管理とローテーションをどのように簡素化するかを説明します。 マネージド外部シークレットの紹介 AWS Secrets Manager は、 Amazon Relational Database Service (Amazon RDS) や Amazon DocumentDB などの AWS サービスのシークレットを、マネージドローテーション機能を通じて安全に管理してきた実績があります。この実績を基に、Secrets Manager はマネージド外部シークレットを導入しました。これは、Salesforce などのサードパーティソフトウェアアプリケーションにも同じシームレスな体験を提供する新しいシークレットタイプで、標準化されたフォーマットと自動ローテーションによってシークレット管理の課題を簡素化します。 この機能を使用すると、サードパーティソフトウェアプロバイダーが発行するシークレットを事前定義されたフォーマットで保存できます。これらのフォーマットは、信頼できる統合パートナーと協力して開発され、シークレットの構造とローテーションに必要なメタデータの両方を定義しているため、独自の保存方法を設計する必要がありません。マネージド外部シークレットは、ソフトウェアプロバイダーと直接統合することで自動ローテーションも提供します。ローテーション関数を維持する必要がないため、運用オーバーヘッドを削減しながら、 AWS Identity and Access Management (IAM) を使用した きめ細かなアクセス許可管理 、 Amazon CloudWatch と AWS CloudTrail によるシークレットアクセスの監視、 Amazon GuardDuty による自動化されたシークレット固有の脅威検出など、重要なセキュリティコントロールの恩恵を受けることができます。さらに、AWS とサードパーティの両方のシークレットに対して、単一のサービスから一元化された一貫したシークレット管理プラクティスを実装できるため、組織で複数のシークレット管理ソリューションを運用する必要がなくなります。マネージド外部シークレットは標準の Secrets Manager の料金 に従い、この新しいシークレットタイプの使用に追加コストはかかりません。 前提条件 マネージド外部シークレットを作成するには、Secrets Manager への適切なアクセス権を持つアクティブな AWS アカウントが必要です。アカウントには、シークレットを作成および管理するための十分なアクセス許可が必要で、 AWS マネジメントコンソール へのアクセス、または AWS Command Line Interface (AWS CLI) や AWS SDK を介したプログラムによるアクセスが可能である必要があります。最低限、以下のアクションに対する IAM アクセス許可が必要です: secretsmanager:DescribeSecret 、 secretsmanager:GetSecretValue 、 secretsmanager:UpdateSecret 、 secretsmanager:UpdateSecretVersionStage 。 AWS にシークレットを管理させる予定のサードパーティソフトウェアプロバイダーの有効な認証情報と必要なアクセス許可を持っている必要があります。 シークレットの暗号化については、 AWS Key Management Service (AWS KMS) の AWS マネージドキー を使用するか、 カスタマーマネージドキー を使用するかを決定する必要があります。カスタマーマネージドキーの場合は、必要なキーポリシーが設定されていることを確認してください。 AWS KMS キーポリシー では、Secrets Manager が暗号化と復号化の操作にキーを使用できるようにする必要があります。 マネージド外部シークレットの作成 現在、マネージド外部シークレットは Salesforce、Snowflake、BigID の 3 つの統合パートナーをサポートしています。Secrets Manager はパートナーリストを継続的に拡大しており、今後さらに多くのサードパーティソフトウェアプロバイダーが追加される予定です。最新のリストについては、 統合パートナー を参照してください。 マネージド外部シークレットを作成するには、以下のセクションの手順に従ってください。 注: この例では Salesforce External Client App の認証情報を取得する手順を示していますが、Secrets Manager と統合された他のサードパーティベンダーの認証情報についても同様の手順で設定できます。 シークレットタイプの選択と詳細の追加 AWS マネジメントコンソールで Secrets Manager サービスに移動し、[新しいシークレットを保存] を選択します [シークレットタイプ] で [マネージド外部シークレット] を選択します [AWS Secrets Manager 統合サードパーティベンダー] セクションで、利用可能なオプションからプロバイダーを選択します。このウォークスルーでは、[Salesforce External Client App Credential] を選択します [Salesforce External Client App Credential シークレットの詳細] セクションで設定を入力します。Salesforce External Client App の認証情報は、いくつかの主要なコンポーネントで構成されています コンシューマーキー (クライアント ID) は、OAuth 2.0 の認証情報識別子として機能します。コンシューマーキー は Salesforce External Client App Manager の OAuth 設定から直接取得できます コンシューマーシークレット (クライアントシークレット) は、OAuth 2.0 認証のプライベートパスワードとして機能します。コンシューマーシークレットは Salesforce External Client App Manager の OAuth 設定から直接取得できます ベース URI は、Salesforce 組織のベース URL ( https://MyDomainName.my.salesforce.com の形式) で、Salesforce API との連携に使用されます アプリ ID は、 Salesforce External Client Apps (ECA) を識別するもので、Salesforce OAuth 使用状況エンドポイントを呼び出すことで取得できます コンシューマー ID は、Salesforce ECA を識別するもので、Salesforce OAuth credentials by App ID エンドポイントを呼び出すことで取得できます。コマンドの一覧については、Salesforce ドキュメントの Stage, Rotate, and Delete OAuth Credentials for an External Client App を参照してください ドロップダウンメニューから [暗号化キー] を選択します。AWS マネージドキーまたはカスタマーマネージドキーを使用できます [次] を選択します 図 1: シークレットタイプの選択 シークレットの設定 このセクションでは、シークレットの設定情報を入力します [シークレットの名前] にわかりやすい名前を入力し、オプションでシークレットの目的と用途を識別するのに役立つ詳細な [説明] を入力します。追加の設定オプションも利用できます。リソースを整理しやすくするための [タグ] の追加、アクセスを制御するための特定の [リソースのアクセス許可] の設定、 マルチリージョンの耐障害性のためのシークレットのレプリケート の選択が可能です [次] を選択します 図 2: シークレットの設定 ローテーションとアクセス許可の設定 (オプション) オプションの [ローテーションを設定する] ステップでは、新しいシークレット設定でメタデータ管理に焦点を当てた 2 つの主要なセクションが導入されています。これらはシークレット値とは別に保存されます。 [ローテーションメタデータ] で、Salesforce アプリが使用している API バージョンを指定します。API バージョンを確認するには、Salesforce ドキュメントの List Available REST API Versions を参照してください。 注: 必要な最小バージョンは v65.0 です [管理者シークレット ARN] を選択します。これには、Salesforce クライアントシークレットのローテーションに使用される管理者 OAuth 認証情報が含まれています [シークレットローテーションのサービス権限] セクションでは、Secrets Manager がシークレット値をローテーションするために必要なアクセス許可を持つロールを自動的に作成します。これらのデフォルトのアクセス許可は、[アクセス許可の詳細を表示] を選択するとインターフェースに表示され、確認できます。シークレットローテーション管理をよりきめ細かく制御するために、デフォルトのアクセス許可の選択を解除することもできます [次] を選択します 図 3: ローテーションの設定 レビュー 最後のステップでは、シークレットの設定の概要が表示されます。[レビュー] ページで、シークレットを作成する前にパラメータを確認できます。 設定が正しいことを確認したら、[保存] を選択してプロセスを完了し、指定した設定でシークレットを作成します。 図 4: レビュー 正常に作成されると、シークレットが [シークレット] タブに表示されます。設定、ローテーションステータス、アクセス許可など、シークレットのさまざまな側面を表示、管理、監視できます。作成後は、暗号化設定やクロスアカウントアクセス用のリソースポリシーなどのシークレット設定を確認し、さまざまな AWS SDK 向けに提供されているサンプルコードを調べて、シークレットの取得をアプリケーションに統合できます。[シークレット] タブでは、シークレットの概要が表示され、シークレットを一元管理できます。シークレットを選択して [シークレットの詳細] を表示します。 図 5: シークレットの詳細を表示 これで、マネージド外部シークレットが Secrets Manager に正常に作成されました。このシークレットには、Secrets Manager コンソールから、または AWS API を使用してプログラムでアクセスおよび管理できます。 Secrets Manager の統合パートナーとしてオンボーディングする 新しいマネージド外部シークレットタイプにより、サードパーティソフトウェアプロバイダーは Secrets Manager と統合し、AWS 上で提供するシークレットをプログラムで安全に管理する方法をお客様に提供できます。この統合により、お客様は AWS とサードパーティ両方のシークレットのライフサイクルを一元管理でき、シークレット作成時から自動ローテーション機能を利用できます。Salesforce などのソフトウェアプロバイダーは、すでにこの機能を活用しています。 「Salesforce では、セキュリティはイノベーションの障壁ではなく、イノベーションを可能にするものであるべきだと考えています。マネージド外部シークレットに関する AWS とのパートナーシップは、セキュリティ・バイ・デフォルトの実践であり、エンタープライズグレードの保護を提供しながら、お客様の運用負担を軽減します。AWS Secrets Manager がパートナーにも拡張され、自動化されたゼロタッチローテーションによって人的リスクが排除されることで、専門知識や追加コストなしに安全な認証情報をシームレスに利用できる新しい業界標準を確立しています。」— Salesforce プロダクトマネジメント担当シニアバイスプレジデント Jay Hurst 氏 統合パートナーとして Secrets Manager にオンボーディングするための追加コストはかかりません。開始するには、 パートナーオンボーディングガイド に記載されているプロセスに従ってください。統合パートナーになることについてご質問がある場合は、 aws-secrets-mgr-partner-onboarding@amazon.com まで、件名を「[パートナー名] Onboarding request」としてお問い合わせください。 まとめ このブログでは、Secrets Manager の新しいシークレットタイプ「マネージド外部シークレット」を紹介しました。この機能は、事前定義されたフォーマットと自動ローテーションを通じて、サードパーティシークレットのライフサイクルを安全に管理するという課題に対応します。独自の保存方法の設計や複雑なローテーション関数の開発が不要になり、AWS サービス、カスタムアプリケーション、サードパーティプロバイダーのいずれのシークレットも、単一のサービスから一貫して管理できるようになりました。マネージド外部シークレットは、きめ細かなアクセス許可管理、オブザーバビリティ、コンプライアンスコントロールなど、標準の Secrets Manager シークレットと同じセキュリティ機能を提供しながら、追加コストなしで信頼できるパートナーとの組み込み統合を追加しています。 開始するには、 技術ドキュメント を参照してください。既存のパートナーシークレットをマネージド外部シークレットに移行する方法については、 既存のシークレットの移行 を参照してください。この機能は、すべての AWS 商用リージョンで利用できます。Secrets Manager が利用可能なリージョンの一覧については、 AWS リージョン表 を参照してください。このブログについてご質問がある場合は、 Secrets Manager re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 Rohit Panjala Rohit は AWS のセキュリティスペシャリストで、データ保護と暗号化サービスに注力しています。AWS データ保護サービスの市場投入 (GTM) 戦略の策定と実行、およびグローバル規模でのお客様とパートナーの導入促進を担当しています。AWS 入社前は、IBM でセキュリティプロダクトマネジメント、および電気エンジニアリングの職務に従事していました。オハイオ州立大学で工学の学士号を取得しています。 Rochak Karki Rochak は AWS のセキュリティスペシャリストソリューションアーキテクトで、脅威検出、インシデント対応、データ保護に注力し、お客様が安全な環境を構築できるよう支援しています。米国陸軍の退役軍人で、ワイオミング大学で工学の学士号を取得しています。仕事以外では、家族や友人と過ごしたり、ハイキングや旅行を楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは！ アマゾン ウェブ サービス ジャパンのソリューションアーキテクト馬渕です。普段は交通業界のお客様の技術支援を担当していますが、その他にも業界問わず Dify や Amazon Bedrock を活用したお客様の AI 活用推進をご支援しております。 2025年11月21日（金）15:30-17:00に「企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜」を開催し、多くのお客様にご参加いただきました。今回のイベントでは、Dify の最新機能や、 Dify Enterprise とプラグインによるセキュアなデータ活用、Dify on AWS のメリット、パートナー企業による実践的な導入事例をテーマにプレゼンテーションを実施しました。 本ブログでは、イベント内容を簡単にご紹介しつつ、当日のセッションの様子を共有いたします。また、各セッションで紹介された内容のポイントもお伝えしますので、今後の Dify 活用の参考にしていただければと思います。 イベント概要 本イベントは以下のような形で実施しました。 日時 : 2025年11月21日（金）15:30-17:00（開場 15:00） 場所 : アマゾンジャパン合同会社目黒オフィス 参加対象 : 社内の生成 AI 活用を推進している IT 部門責任者、機密度の高い重要な企業システムの管理者、データ活用に生成 AI を活かしたいデータ基盤管理者 時間 セッション 資料 15:30 – 15:35 Opening – 15:35 – 15:55 Agentic AI 開発の実力 – 最先端技術で安全なDX変革を実現 (Dify アップデート紹介) 株式会社 LangGenius 田口太一様 PDF 15:55 – 16:15 Dify プラグイン & Enterprise 株式会社 LangGenius 橋本龍生様 PDF Dify Enterprise でセキュアなデータも扱おう – Snowflake と連携してインサイトを生む – アマゾンウェブサービスジャパン合同会社 阿部拓也 PDF 16:15 – 16:30 Dify on AWS の選択肢 〜 Why Dify on AWS？ 〜 アマゾンウェブサービスジャパン合同会社 関谷侑希 SpeakerDeck PDF 16:30 – 16:50 パートナーと進める Dify 活用 株式会社リコー 萩原智様 PDF 16:50 – 17:00 Q&A / Closing – 17:00 – 18:00 懇親会 – Agentic AI 開発の実力 – 最先端技術で安全なDX変革を実現(Dify アップデート紹介) 最初のセッションでは、株式会社 LangGenius の田口様より、Dify の最近の新機能群について発表いただきました。新機能である MCP（Model Context Protocol）やナレッジパイプライン、トリガー機能のご紹介や、現在開発中の Human In The Loop 機能の解説をいただきました。 いずれの機能も注目の新機能ですが、特にアンケートで注目が集まっていたのはトリガーと Human-in-the-loop 機能でした。Dify で生成 AI ワークフローは作りきっているものの、そのワークフローの定期実行等のために別のワークフローツールを併用している……というお客様も多くいましたが、今回のトリガー機能により Dify で完結できるようになりました。 Dify Enterprise でセキュアなデータも扱おう – Snowflake と連携してインサイトを生む – 次のセッションは、前半を株式会社 LangGenius 橋本様にお話いただき、後半をアマゾンウェブサービスジャパン合同会社の阿部からお話する共同セッション形式でお送りしました。 前半では、株式会社 LangGenius 橋本様より、Dify Enterprise の機能とプラグインエコシステムについてお話いただきました。多くのお客様が、 Dify をプラグイン経由で外部システム接続できるエコシステムを活用して生成 AI 活用に役立てています。このエコシステムは非常に便利な一方、ユーザが好き放題にプラグインを導入してしまうとセキュリティ・ガバナンス上のリスクたりえるため、その統制が重要となります。Dify Enterprise ではかねてよりマルチテナント・SSO ・アプリの権限管理等のガバナンス機能を有していましたが、さらにプラグイン管理機能も備えるようになり、プラグインを安全に導入できるようになりました。 後半では、プラグインエコシステムを活かした Dify Enterprise の実践的なユースケースとして、Snowflake と Dify の連携について AWS 阿部よりお話しました。Dify の公式プラグインである Snowflake SQL プラグイン を介して安全に連携し、企業 DWH データを自然言語で自在にクエリするユースケースとアーキテクチャを、実際の動作デモを交えてご紹介しました。企業の重要なデータが格納された DWH を Dify に連携して生成 AI でクエリする場合、閲覧権限の適切なコントロールがネックになりがちですが、Dify Enterprise であればマルチテナント機能・アプリ権限管理機能によりセキュリティを保って連携できる点は注目すべきポイントとなります。 なお、このプレゼンテーションで登場した Snowflake プラグインは、今回のイベントに合わせて LangGenius に開発いただきました。 Dify on AWS の選択肢 〜 Why Dify on AWS？ 〜 続いて、アマゾンウェブサービスジャパン合同会社の関谷より、AWS 上で Dify を構築する際の選択肢と、AWS を選ぶメリットについて詳しく解説しました。 Dify を on AWS で構築する際、選択肢としては大きく ① OSS 版を単一 VM 上に構築、② OSS 版をマネージドサービス上に構築、③ Enterprise 版を Kubernetes 上に構築、という 3 つの方法があります。それらの詳細なメリット・デメリットの比較についてお伝えしたうえで、Dify を AWS 上に構築するメリットについてもお伝えしました。Dify の SaaS 版が on AWS で構築されているという実績や、Dify を AWS 上に迅速に構築できるアセットについてご紹介したほか、AWS Marketplace での Dify Enterprise ライセンス購入により、基盤費用とライセンス費用の効率的な管理が可能であることもお伝えしました。 パートナーと進める Dify 活用 最後のセッションでは、株式会社リコーの萩原様より、 Dify パートナーとしての豊富な社内実践をもとにした価値提供についてご紹介いただきました。 リコー様は、自社内向けの生成 AI 活用環境として、 Dify Enterprise を AWS 環境上に構築して展開しています。AWS 上の Dify のアーキテクチャ観点と、社内普及のための AI 活用推進の観点の両面で知見をご共有いただきました。特に、Dify Enterrprise 機能の社内ガバナンス観点の活用方法や、社員一人一人が Dify を活用していく市民開発を促すための仕組みづくりなど、自社で使い倒しているからこその知見をもとにお客様をご支援できる点が注目すべきポイントでした。 まとめ 今回のイベントでは、Dify Enterprise の最新機能から AWS との連携によるセキュアなデータ活用、そしてパートナー企業による実践的な導入事例まで、幅広い内容をカバーすることができました。 参加者の皆様からは「Dify のアップデートを詳細に説明してもらえて理解が深まった」「エンタープライズ版の機能紹介が参考になった」「市民開発を推進するにあたり環境面、運用面で素晴らしい事例だった」といった声を多数いただき、大変好評でした。 企業における生成 AI の活用は、技術的な実現可能性だけでなく、セキュリティやガバナンスの観点からも慎重な検討が必要です。今回のイベントで紹介された Dify Enterprise と AWS の組み合わせは、これらの課題を解決しながら、効果的な AI 活用を実現するための有力な選択肢となることを改めて確認できました。 ご参加いただいた皆様、ありがとうございました。 Dify Enterprise on AWS の導入にご興味がございましたら、 AWS の営業担当者までお声がけください。また、Dify 未活用のお客様も、まずは ワンクリックで Dify を AWS 上に構築し 、生成 AI 活用の第一歩を踏み出しましょう。 今後も AWS では、Dify を通じたお客様の生成 AI 活用を継続してご支援してまいります。 関連リンク Dify on AWS with CDK サンプル AWS Generative AI Solution Box Dify での生成 AI アプリケーション構築ワークショップ AWS Marketplace – Dify Enterprise   馬渕 俊介 (Mabuchi, Shunsuke) 交通業界のお客様を支援するソリューションアーキテクト。前職では性能のスペシャリストとして従事していたため、好きな AWS ソリューションは AWS での分散負荷テスト ソリューションです。最近は Dify にハマり、 Dify on AWS に関する様々な知見を発信しています。

本記事は 2025 年 12 月 24 日 に公開された「 Accelerating VMware migration: AWS Transform’s new experience 」を翻訳したものです。 2025 年初めの画期的なローンチに続き、 AWS は新しい強力な AI 機能を追加 し、 AWS Transform for VMware マイグレーションエージェントを強化しました。AWS Transform for VMware は、お客様のビジネス優先度を理解し、環境に適応し、マイグレーションの各ステップでより良い制御を提供します。エージェントは、依存関係マッピング、インテリジェントなウェーブプランニング、複数のターゲットアカウントにわたるネットワーク構成の変換など、移行プロセスをオーケストレーションします。マイグレーションエージェントのネットワーク機能は、Cisco ACI、Palo Alto、Fortinet ネットワークを含む新しいベンダーでのセキュリティグループ変換をサポートするようになりました。 VMware 環境のすべてのワークロードを Amazon EC2 へエンドツーエンドの移行を計画している場合でも、VMware インフラストラクチャの特定のワークロードやサーバーをターゲットにしている場合でも、AWS Transform の AI 駆動アプローチは実行において柔軟性を実現します。必要に応じて移行計画を変更し、インフラストラクチャの進化に合わせて検出ステップを繰り返し、完了した作業の整合性を維持しながら選択的にマイグレーションウェーブを実装できます。このインテリジェントなアプローチにより、移行のリスクが軽減され、移行期間を短縮できます。統一された Web インターフェースと AI アシスタンスにより、マイグレーション全体を通じて一貫性を維持できます。AWS Transform for VMware は 追加料金なしで利用が可能 です。この新しいソリューションは、 AWS Transform が提供されているすべての AWS リージョン で利用可能になり、 16 の AWS リージョン へのサーバーとネットワークのマイグレーションをサポートします。 このブログでは、環境分析のための検出、移行計画、インフラストラクチャ適応のためのネットワーク変換、Amazon EC2 へのワークロード変換のためのサーバー移行を行うエンドツーエンドの移行について説明いたします。 前提条件 セットアップを開始するには、以下が必要です: AWS Organizations のセットアップ AWS IAM Identity Center のセットアップ AWS アカウント: 移行計画アカウント – 移行のアクティベーションとオーケストレーションのコントロールセンターとして機能します。AWS Transform はこのアカウントで実行されます。 ターゲットアカウント – ワークロードの移行先となるアカウントです。 エンタープライズ規模のマイグレーションでは、上記のように特定の目的のために異なるアカウントを持つことを推奨しますが、機能を 1 つのアカウントに統合することも可能です。すべてのアカウントは同じ AWS Organizations に属している必要があります。 開始方法 移行計画アカウントで AWS Transform を有効にし、ユーザーを割り当てるには以下の手順に従います: AWS Transform セットアップ AWS コンソールで、 AWS Transform に移動します 使用を開始 を選択します 暗号化キーを選択し、 AWS Transform 機能を有効にする を選択します ユーザーを管理 を選択します IAM Identity Center から AWS Transform にユーザーまたはグループを追加します 左ペインから Settings に移動し、 ウェブ アプリケーション URL をコピーします ユーザーは Web アプリケーション URL を使用して AWS Transform にログインできます 最初の AWS Transform ジョブを作成する Transform コンソールで、 Create workspace を選択して新しいワークスペースを作成します Create job を選択し、 Migration > VMware Migration を選択して VMware マイグレーションジョブを作成します 利用可能なジョブオプションのリストからジョブを選択します チャットでの後続のプロンプトに従って、移行プロセスを続行します 図 1: AWS Transform for VMware ジョブオプション 検出 AWS Transform はソースデータを分析し、パターンを自動的に識別し、データの競合を解決し、重複エントリを排除して、VMware 環境のよりクリーンで正確なビューを提供します。マイグレーションエージェントの検出機能は、複数のデータコレクターによって生成されるさまざまな種類のエクスポートに対応します。 検出の中核となるのは AWS Transform discovery tool で、VMware vCenter の一元管理された Discovery Collector OVA (Open Virtualization Format Archive) ファイルを通じてデプロイされます。AWS 接続を必要とせずにオンプレミス環境内で完全に動作し、このツールはサーバー仕様やネットワーク依存関係を含む環境に関する詳細情報を自動的に検出および収集します。このツールは基本的なインベントリ収集にとどまらず、適切なサイジング推奨のためのリソース使用率、SQL Server データベースメタデータ、依存関係マッピングのためのサーバー間接続などの重要なデータポイントをキャプチャします。収集されたすべてのデータは、マイグレーションを進めることを選択するまで、オンプレミスインフラストラクチャ内に安全に保存されます。 図 2: AWS Transform for VMware Discovery tool 既存のツールとプロセスについて、AWS Transform は柔軟なデータ取り込みオプションを提供します。vSwitch、ポートグループ、VLAN を含む VMware 環境に関する詳細情報を提供する CSV または XLSX 形式の RVTools エクスポートを活用できます。エージェントは、既存のインフラストラクチャ管理ソリューションと統合して、ModelizeIT や Cloudamize などの 一部のサードパーティツールからのデータインポート もサポートします。 さらに、AWS Transform 検出ステップでは、Large Language Model (LLM) を使用してコンテンツを分析し、任意の形式のファイルを処理できます。処理に成功すると、既存のインベントリレコードを更新するか、新しいエントリを作成するためのサーバー情報を抽出します。 図 3: マイグレーションジョブデータ取り込み 検出ステップでは、検証済みのインフラストラクチャインベントリを作成し、データ品質の問題を特定し、対応が必要なギャップや不整合を浮き彫りにします。この環境の包括的な理解は、移行計画、ネットワーク変換、サーバー移行を含む後続のマイグレーションステップの基盤となります。 図 4: マイグレーションジョブ検出サマリー 移行計画の作成 エンドツーエンドマイグレーションの次のステップは、 移行ウェーブ計画の作成 です。AWS Transform は、AI を活用した新しい移行計画機能を導入し、お客様の VMware 移行計画へのアプローチを刷新します。この機能は、会話型インターフェースを通じて、複雑なインフラストラクチャデータを実用的な移行戦略へと変換します。構造化された検証とインテリジェントな依存関係分析を組み合わせることで、AWS Transform は、お客様が移行プロセスをコントロールしながら、計画プロセスにおける変化するビジネス要件に適応できるよう支援します。 これはデータ処理とインフラストラクチャ分析から始まります。AWS Transform は、通常 CSV または XLSX 形式のインフラストラクチャインベントリファイルを処理し、サーバー名、オペレーティングシステム、設定、CPU、メモリ、ストレージ割り当て、ネットワーク依存関係の詳細を抽出します。この分析により、検証済みインフラストラクチャインベントリが生成され、データ品質の問題が特定され、明確化が必要なギャップや不整合がハイライトされます。 図 5: インフラストラクチャインベントリ分析 移行計画ステップでは、AWS Transform は 3 段階のプロセスを実装します。まず、アプローチを定義し、アプリケーションに関連するビジネスインプットをエージェントと共有します。次に、エージェントはこれらのルールを適用してアプリケーション定義を作成し、各サーバーが正確に 1 つのアプリケーションに割り当てられることを保証します。第三に、アプリケーションはビジネスクリティカリティ、技術的複雑さ、リスク許容度などの要因に基づいて優先度スコアを受け取り、移行の順序付けを促進する構造化されたポートフォリオが作成されます。 図 6: 移行計画 – アプリケーションのグループ化 次の段階は移行グループの作成です。各移行グループには、一緒に移行する必要がある関連アプリケーションが含まれます。AWS Transform はアプリケーション間の依存関係を分析して、アプリケーションが依存関係より前に移行されるシナリオを回避します。移行グループは、データベースアプリケーションをまとめて管理したり、開発環境と本番環境を分離したりするなど、定義済みのサイズ設定ルールと構成要件に従います。 図 7: 移行計画 – 移行グループ 移行計画の作成は、ウェーブの作成で終了します。AWS Transform は、移行グループを順次ウェーブに整理することで移行タイムラインを作成します。各ウェーブには 1 つ以上の移行グループが含まれ、定義された順序で実行されます。AWS Transform は依存関係を考慮しながらスケジュールを最適化します。依存関係のない移動グループは並行して実行でき、依存関係のあるものは特定の順序に従う必要があります。エージェントは、月あたりの最大ウェーブ数やウェーブ間の必要なバッファなどのビジネス制約を組み込んで、実行可能なマイグレーションスケジュールを作成します。 図 8: 移行計画 – ウェーブ計画 移行計画のステップ全体を通して、AWS Transform はあらゆるフェーズで反復的な改善をサポートします。アプリケーションのグループ化の変更は移行グループとウェーブの再生成をトリガーし、移行グループの変更はウェーブ計画のみを再生成します。このターゲットを絞った再生成により、完了した作業を中断することなく、効率的な更新が保証されます。 ネットワーク変換とマイグレーション マイグレーションウェーブを確定した後、AWS Transform for VMware は、ソースネットワーク設定を変換し、ターゲット AWS アカウント全体にデプロイすることで、ネットワーク設定のマイグレーションを自動化します。VMware vSphere と VMware NSX のサポートに加えて、以下のネットワークインフラストラクチャソースのサポート範囲を拡大し、既存のネットワーク構成を AWS ネットワーク構成にシームレスに変換できるようになりました。 Cisco Application Centric Infrastructure (ACI) ネットワークポリシー設定 Palo Alto Networks ファイアウォールセキュリティポリシー Fortinet FortiGate ファイアウォールセキュリティポリシー ネットワーク変換は ターゲット AWS アカウントの接続 から始まり、単一アカウントまたは 複数アカウントの移行 を定義できます。ターゲットアカウントを接続した後、ソースネットワーク設定をインポートできます。AWS Transform は VMware NSX と VMware vSphere の RVTools エクスポートからの複数のファイル形式をサポートします。ファイル検証後、セキュリティグループ設定に進み、 サポートされているセキュリティアプライアンスからの追加設定データを組み込む ことでセキュリティ体制を強化できます。これはオプションですが、ターゲット環境で一貫したセキュリティポリシーを維持するために推奨されます。 図 9: セキュリティグループ設定のためのネットワーク構成入力 セキュリティグループ設定を完了した後、AWS Transform はネットワークトポロジー選択をガイドし、2 つのアーキテクチャパターンを提示します。どちらのトポロジーについてもサンプルアーキテクチャを説明するためにチャットすることもでき、実装前にネットワーク設計を理解するのに役立ちます。 分離された仮想プライベートクラウド (VPC) 独立して動作する VPC を作成 各 VPC は独自のインターネットゲートウェイとルーティング設定を持つスタンドアロンネットワークとして機能 シンプルなデプロイメントと VPC 間通信のニーズが最小限の環境に最適 VPC 間の接続を手動で追加変更および設定することを計画しているカスタムネットワーク設計に最適 ハブアンドスポーク VPC AWS Transit Gateway を作成し、ルートテーブルを使用してすべての VPC を接続 すべての VPC 間トラフィックは Transit Gateway を通じてルーティングされ、集中化されたネットワーク管理と共有サービスを提供 集中制御、共有サービス、または頻繁な VPC 間通信を必要とする環境に最適 図 10: ネットワークトポロジーの説明 これにより、オンプレミスネットワークアーキテクチャの AWS ネットワーキングコンポーネントへの変換が自動化されます。ソースネットワーク設定を分析し、VPC、サブネット、セキュリティグループ、ルーティングテーブルを含むターゲット AWS ネットワーク環境を定義する Infrastructure as Code (IaC) テンプレートを生成します。 Landing Zone Accelerator (LZA) on AWS 互換 YAML、 AWS CloudFormation 、 AWS Cloud Development Kit (CDK) 、 HashiCorp Terraform を含む複数の IaC 形式を活用でき、デプロイメントアプローチの柔軟性を提供します。これらのテンプレートは簡単にアクセスできるよう S3 バケットに自動的に保存されます。 AWS Transform は、さまざまな組織のニーズに対応するため、自動化と手動の両方のデプロイメントオプションを提供します。ネットワーク構成時に、AWS Transform では 生成された VPC の CIDR 範囲を指定および編集 でき、ネットワークの重複を回避し、IP アドレス指定ポリシーに準拠し、すべての計画されたサブネットとワークロードに十分な IP アドレス空間を確保できます。さらに、ネットワークのデプロイメント要求には AWS Transform の Approvals タブを通じた明示的な承認が必要で、 AWS Transform ワークスペース管理者 による検証後にのみデプロイメントが進行します。AWS Transform がネットワークをデプロイするために使用される場合、 VPC Reachability Analyzer サービス を使用してデプロイされたネットワーク全体の接続性を検証します。この柔軟なネットワーク構成と、様々な IaC ソリューションによるデプロイのサポートを組み合わせることで、安全で適切に設計されたネットワーク基盤が保証されます。 図 11: 生成された VPC 設定の確認と編集 このエージェントの強みは、その汎用性にあります。ネットワーク変換を単独の移行として実行することも、複数のターゲットアカウント間での検出、ウェーブプランニング、サーバー移行などの他のステップと統合することもできます。プロセス全体を通じて、提案されたネットワーク設定を確認および検証し、必要に応じて調整し、一貫したコンプライアンス要件を維持でき、最終的に潜在的な接続性の問題を最小化し、移行リスクを軽減します。 サーバー移行 移行プロセスの最終ステップとして、AWS Transform は AWS でネイティブに実行するようにサーバーを変換する自動化されたリホスティング機能でサーバー移行を効率化します。マイグレーションエージェントは、実績のある AWS Application Migration Service (AWS MGN) を活用してデータレプリケーションを処理しながら、ウェーブレベルと個別サーバーレベルの両方でマイグレーションの制御を提供します。 AWS MGN は、ソースサーバーあたり継続使用の最初の 90 日間は無料で利用できます。レプリケーション中およびテストまたはカットオーバーインスタンスを起動する際、AWS 料金プランに従って、Amazon EC2 インスタンスや Amazon EBS ボリュームなどのプロビジョニングされた AWS リソースに対して標準料金 が発生します。 サーバー移行は EC2 インスタンスの推奨 から始まり、AWS Transform はワークロード使用率に基づいてインテリジェントな適切サイジングオプションを提供します。平均または最大使用率メトリクスを選択して最適なインスタンスサイズを決定し、 専用または共有テナンシーオプション を選択し、考慮から除外する EC2 インスタンスタイプを指定できます。このカスタマイズ可能なアプローチにより、移行されたワークロードがパフォーマンスとコスト効率の両方に適切にサイズ設定されることが保証されます。 図 12: サーバーの EC2 推奨 AWS Transform は、移行ウェーブごとに 柔軟な IP アドレス指定オプション を提供し、ネットワーク要件に基づいて静的または動的 IP 割り当てを選択できます。以下を含む、マイグレーション予定のサーバーの包括的なインベントリを生成します: ターゲット EC2 インスタンスタイプの推奨 ターゲットサブネットの割り当て セキュリティグループ設定 前に選択した IP アドレス指定スキーム 移行を進める前に、インベントリを確認および変更して正確性を確保できます。マイグレーションエージェントのチャットベースのインターフェースは、粒度の細かいサーバーレベル制御を提供し、注意が必要な特定のケースに対してテストの復元やカットオーバーアクションなどの個別サーバー操作を管理できます。 AWS Transform は、次のようなサーバー移行の重要な側面を自動化します。 サーバーレプリケーション 互換性チェックと変換 テストと検証 カットオーバーオーケストレーション 自動化により、手作業によるエラーが大幅に削減され、アプリケーションの安定性を維持しながら移行期間が短縮されます。ステップ全体を通じて、AWS Transform は一般的な問題の詳細なエラー検出と説明を含む、強化されたエラーハンドリング機能を提供します。 図 13: サーバーのレプリケーションステータス AWS Transform は MGN を使用するため、プライベートデータ転送の場合サーバーは AWS Direct Connect または Site-to-Site VPN を通じてレプリケーションでき、パブリックインターネット接続の必要性を排除します。AWS Transform と AWS サービス間の通信に TLS 1.2 以上の暗号化を利用し、Amazon S3 バケットに保存されたデータに AWS 管理暗号化キーを使用して、転送中および保存中のデータの 包括的な暗号化を維持 します。 AWS Transform のモジュール型アプローチにより、サーバー移行を独立したプロジェクトとして実行することも、オーケストレーションされたマイグレーション戦略の一部として実行することもできます。ウェーブレベルと個別サーバーレベルの両方でサーバー移行テストとカットオーバーインスタンスを制御でき、サーバーを AWS に移行する方法を管理できます。 クリーンアップ クリーンアッププロセスは、本番環境の移行を実行したか、移行をテストしたかによって異なります。 本番移行の場合、必要に応じて AWS Transform コンソール から Transform ジョブを削除します。Transform ジョブを削除すると、ネットワーク IaC テンプレートや移行計画ドキュメントを含む、生成されたすべてのアーティファクトが永続的に削除されることに注意してください。削除を進める前に、必要なアーティファクトをバックアップしてください。マイグレーションされたリソースは本番環境で実行されているため、削除しないでください。 マイグレーションをテストしている場合は、以下を実行してリソースをクリーンアップします: AWS Transform コンソール に移動し、AWS Transform ジョブを削除し、ワークスペースを削除します (オプション) Amazon VPC コンソール に移動し、デプロイされたネットワークリソース (VPC、サブネット、セキュリティグループ) を削除します カットオーバーの完了後、AWS MGN サービスはステージングエリアのリソース (Amazon EC2 レプリケーションインスタンス、Amazon EBS ボリューム) をクリーンアップします。カットオーバーを完了していない場合は、手動で AWS MGN レプリケーションエージェントをアンインストール できます。 Amazon EC2 コンソール に移動し、レプリケーションリソースが終了していることを確認し、起動されたテスト/カットオーバーインスタンスを終了します。 まとめ この最新リリースのエージェント機能は、移行目標の達成に必要なインテリジェンスと柔軟性をお客様に提供するという AWS のコミットメントを表しています。要約すると、AWS Transform for VMware には以下の機能が追加されました: 複雑な移行タスクを簡素化するチャットベース操作 エンタープライズ規模のマイグレーションのためのマルチアカウントサポート リアルタイム変更を可能にする動的な移行計画 Cisco ACI、Palo Alto、Fortinet を含む拡張されたネットワークインフラストラクチャサポート 複数形式をサポートする柔軟な Infrastructure as Code (IaC) 生成 ウェーブレベルと個別サーバーレベルの両方での強化されたサーバー移行制御 これらの機能は連携して、制御を維持しリスクを軽減しながらマイグレーションジャーニーを加速するのに役立ちます。新機能は、エンドツーエンドのインフラストラクチャ移行から特定のワークロード移行まで、さまざまな移行シナリオをサポートし、ニーズに最適なアプローチを選択できます。 詳細については、 AWS Transform for VMware ページをご覧いただき、 最新機能について学び 、 AWS Transform を開始 してください。 Suhail Fouzan Suhail Fouzan は、IT 業界で 15 年以上の経験を持つ Amazon Web Services (AWS) の Specialist Solutions Architect です。Microsoft ワークロード、マイグレーションサービス、AWS Systems Manager を使用した運用管理を専門とし、お客様のインフラストラクチャの AWS への成功的なマイグレーションを支援しています。仕事以外では、クリケットをプレイし、家族と時間を過ごすことを楽しんでいます。 Bianca Velasco Bianca Velasco は AWS の Product Marketing Manager で、AWS での VMware ベースワークロードのマイグレーションと変革に焦点を当てています。マーケティングとテクノロジーで 7 年以上の経験を持ち、複雑なテクノロジーを意味のある関連性のあるものにするナラティブの作成に情熱を注いでいます。AWS 以外では、ボランティア活動、ダンス、ボルダリングを楽しんでいます。 Pedro Calixto Pedro Calixto は AWS の Senior Solutions Architect で、ワークロードのマイグレーションとモダナイゼーションを専門としています。企業がオンプレミス環境を AWS 内で拡張、マイグレーション、保護することを支援し、AWS サービスを使用したアプリケーションモダナイゼーションの加速に焦点を当てています。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

本稿は弥生株式会社様と AWS Japan の共同執筆により、AI 駆動開発ライフサイクル（AI-DLC）Unicorn Gym の実践を通じて得られた学びと今後の取り組みをお伝えするものです。 はじめに 2025年、生成 AI の台頭により開発現場は大きな変革期を迎えました。弊社 (弥生株式会社) でも AI ツールの導入を推進してきましたが、従来の開発手法と AI のポテンシャルをどう融合させるべきか、プロダクトごとに異なる環境の中で最適な手法を模索している段階にありました。 こうした中、AWS が提唱する「 AI 駆動開発ライフサイクル（AI-DLC） 」が、開発プロセスを再定義する鍵になると考え、2025年12月10日から12日の3日間にわたって「AI-DLC Unicorn Gym」を AWS と共同で実施しました。本記事では、その実践から得られた学びを共有します。 これまでの課題 弥生株式会社では「AI 駆動開発」を掲げ、全社的に AI を活用してプロダクト開発の効率化を進めています。 一方で、個々のチームや個人の工夫に依存している部分がいまだに大きく、要件整理・設計・実装・テスト・運用までを一気通貫で支える “開発プロセスそのもの” の標準化にはまだ踏み込めていませんでした。 AI-DLC Unicorn Gym の実施内容 この課題に対し、弥生株式会社と AWS Japan は共同で「 AI-DLC Unicorn Gym」を開催しました。実際のプロダクトを対象として 3日間にわたって AI-DLC を実践し、その効果や導入に至るまでのギャップの検証に取り組みました。 今回の AI-DLC Unicorn Gym では、参加者が「AI チーム」と「サブスクチーム」の 2つの独立したチームに分かれ、それぞれ異なるプロダクトに対する機能の開発を通じて AI-DLC の効果を検証しました。ツールとしては AI IDE「 Kiro 」 を用いました。 チーム名 取り組み内容 参加者構成 成果 開発所要期間 (推定値→実績値) AI チーム 分析用 AI チャットツール、データ連携基盤および情報受け渡しフローの実装 エンジニア・ビジネス・デザイナー・マーケター・QA (計 12 名/ 3サブチーム) 動作するモックの完成 (一部 API 連携を除く) 1 ヶ月以上 → 2.5 日 サブスクチーム ユーザー登録・製品利用ライセンスの付与・認可 エンジニア・マーケター (計 8 名/2サブチーム) 動作するモックの完成 1 ヶ月以上 → 2.5 日 ※品質比較未実施 AI-DLC Unicorn Gym の学び 実質 2.5 日という限られた時間の中で、AI-DLC を実際のプロダクトに投入することで見えてきた「理想と現実のギャップ」がありました。これらは単なる失敗ではなく、今後の開発プロセスの改善に対する重要な学びでした。参加者からは「既存製品の仕様や制約をどのようにインプットさせるかの障壁は高いですが、導入しないと時代の流れに取り残されそうな強い危機感を覚えました。」といった感想が挙がりました。 「まず会議」から「まず AI」へ: AI-DLC Unicorn Gym の冒頭で私たちは「何を作るか」という議論で足踏みをしていました。正解のない不確実な領域で机上の議論にとどまり、多くの時間を費やしていました。この停滞に対し、 「もっと早い段階から AI を活用しましょう」 との助言を AWS メンバーからいただいたことが転換点となりました。自分たちだけで仕様を完璧に固めてから AI に渡すのではなく、言語化できていないモヤモヤした状態のまま AIに具体化してもらうフローへと切り替えました。 AI のアウトプットを議論の起点にすることで、不確実な状況下での意思決定が大幅に加速しました。人間だけで悩み続ける前に、AI に叩き台を作らせて判断することが会議の時間を短縮し、判断スピードを上げるための鍵となりました。 ロールの壁を越えるコラボレーション: 実装工程では、ロール（役割）の重要性を再認識しました。例としてフロントエンド実装において、デザイナーが書くプロンプトの解像度の高さには、エンジニア目線にはなかった視点が含まれていました。エンジニアでは言語化しにくい UI の勘所が、デザイナーの巧みなプロンプトによって具体化されました。同時に、ビジネスサイドが仕様の細部をその場で決断し、実装に反映させるサイクルも実現しました。並列でユニットの実装を進めることによる効率性と、上流工程における複数ロール間の協働こそが、AI-DLC を成功させるポイントであると実感しました。 一方でビジネスサイドやデザイナーも実作業に加わる中で、開発環境のセットアップで予想以上の時間をロスしてしまったことは大きな反省点です。また、作業が本格的なコーディングフェーズへ移行すると、エンジニア以外のメンバーがプロセスの詳細を追いきれず、議論から距離ができてしまう状況も発生しました。AI-DLC のメリットを最大化するためには、「誰もが即座にアウトプットに関与できる土台」と、「実装の進捗をチーム全員が直感的に理解できる共有の仕組み」が不可欠であることを認識しました。 AI 駆動の爆速並列開発を阻んだ「つなぎ込み」の壁: AI チームにおいて、最大の学びとなったのは「ユニット統合（つなぎ込み）」における課題でした。 今回は開発の並列度を高めるため、一つの機能を、フロントエンド・AI エージェント・バックエンドの 3 つのユニットに分割し、サブチームに分かれて並列で実装を進めました。しかし、各ユニットを統合するフェーズでいくつかの課題が明らかになりました。 並列開発における最大の課題は、バックエンドとの最終結合まで、各ユニット間でのこまめなマージや中間共有が十分にできていなかったことです。人間同士の開発であれば、日々のコミュニケーションで補完し合えていた「認識のズレ」が、AI が圧倒的な速度でアウトプットを出し続ける環境ではコードの不一致として積み上がり、最終的な統合コストを増大させてしまいました。事前の Pact (契約テストフレームワーク) によるガードレール整備や、マージ前の取り込みが不十分だったこと、規約の不備によるコードの衝突と命名規則の不一致が主な要因でした。 AI-DLC の爆速開発を支えるのは、「自由」ではなく「規約」でした。初期段階でインターフェースを厳密に定義し、こまめな同期によって認識のズレを解消すること、この「ガードレールを敷きながら走る」開発プロセス設計の徹底が重要であると感じました。 今後の取り組み AI-DLC Unicorn Gym で得た知見を単なる体験に留めず、実務へ還元していくために検討したいポイントをまとめました。 モブワークとスウォーミングによる停滞しない開発フローの構築: 同期的に意思決定を行う「モブワーク」と、自律的に並列実行する「スウォーミング」をシームレスに切り替える開発フローの適用を検討しています。 上流工程で複数ロールによるモブワークを徹底し、全員の認識を揃えた「ユニットオブワーク」へと落とし込みます。タスクを分解したのちに各メンバーが独立して動く「スウォーミング」へと移行することで、AI を休ませることなくフローを最大化するサイクルを構築していきたいと考えています。 AI との整合性を高める「ナレッジの資産化」: 人間と AI の協働によるポテンシャルを最大限活用するためには、AI が自律的に参照できる「共通のガードレール」の整備が不可欠です。 今後は、DDD（ドメイン駆動設計）に基づく業務知識や、TDD（テスト駆動開発）の指針などを Markdown 形式等で集約する “ Docs-as-Code” の考え方を取り入れたいと考えています。AI エージェントが常に最新の設計方針や規約を参照できる状態を整えることで、人間はタスクの推奨案の提示や軌道修正といった、より高度な判断に専念できる環境を目指します。 判断のための専門スキルとマインドセットの底上げ: AI が実装段階の大部分を担うようになることで、エンジニアの職能を「書くスキル」から「レビュー・判断するスキル」へとアップデートしていく必要があります。AI のアウトプットが正しいかを判定するには、これまで以上に深い専門知識が求められます。AI の回答を盲信するのではなく、その意図を正しく解釈し、的確に介入できるメタな視点でのスキルセットの構築を、個人・組織の両面で検討していきます。 まとめ AI-DLC は単なるツール導入ではなく、「プロセスそのものを再設計する」意思決定が必要となるアプローチです。 机上の議論に時間を費やしてしまう前に、まずは AI と共に見えるものを高速に作り上げ、壊し、また作る。試行回数を増やすことが AI 時代の開発における重要な戦略であると感じました。 今回の AI-DLC Unicorn Gym は対面形式で行われ、チーム全員が常に画面を共有しながら意思疎通を続けるプロセスを実践しました。このワーク形式は常に脳をフル回転させ続ける、大きな疲労感を伴うものでもありました。しかし、その濃密な時間の中でその場ですぐに方針を決定し、プロダクトが猛スピードで形になっていく様子を体験できたことは、非常に大きな収穫でした。 今回の学びは個人に留まらず、チームとして AI をどう活用し、開発プロセスをどうアップデートすべきかという点に集約されています。すべてを明日からそのまま適用できるわけではありませんが、既存プロダクトや環境との違いを考慮しながら、一つずつ現場への適用を模索していきます。AI-DLC Unicorn Gym で得た新しい考え方・経験を、弥生株式会社の新しい開発文化へと繋げていきたいと考えています。 著者 yuki sekiguchi 関口 勇樹 (Yuki Sekiguchi) 弥生株式会社 クラウドプロダクト開発部 エンジニア 受託開発にて様々なシステム構築を経験した後、2024年10月より弥生株式会社にエンジニアとして参画。現在は「AI を活用したプロダクト開発」を探求のテーマとし、プライベートでも AI エージェントによるライブラリ開発のトライアンドエラーを繰り返すなど、実践的な技術活用に注力している。また、 Zenn や note にて技術情報の発信も行っている。 futa kimura 木村 風太 (Futa Kimura) 弥生株式会社 クラウドプロダクト開発部 エンジニア バックオフィス職からエンジニアへ転身し、事業会社での開発経験を経て2023年8月から現職へ。現在は新製品開発に携わり、バックエンド中心にフルスタックで開発。全社的な AI 駆動開発推進の PM も担当しています。 yamazaki hiroki profile-20250806 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用をご支援しています。Kiro CLI や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。

本稿は、株式会社日本取引所グループ（以下「JPX」）傘下の株式会社東京証券取引所（以下「東証」）による「膨大な取引データの処理 – AWS 活用で実現した次世代データ分析基盤」について、インフラ開発をリードされた齋藤 尚樹様に寄稿いただきました。 イントロダクション 東証は、株式売買システム arrowhead4.0 の稼働に伴い、膨大な注文や約定等の取引データに係るトランザクションを効率的に蓄積・分析するための新しいデータ分析基盤を構築しました。 arrowhead は、東証及び富士通が開発してきた世界最高水準の高速性・信頼性・拡張性を兼ね備えた株式売買システムで、2010 年の初代システムから進化を続け、2024 年 11 月 5 日には、市場利用者の利便性や国際競争力、レジリエンスをさらに高めることを目的とした arrowhead 4.0 が稼働しました。 近年、活況なマーケットや取引処理の高速化にともない、1 日に数億件という膨大なトランザクションを安定的に処理するキャパシティが求められると同時に、ピーク時には 1 秒間に 10 万件を超える高いスループットでデータが発生し続けるため、遅延なくリアルタイムでデータ処理できる性能も、データ分析基盤に求められます。 図：arrowheadの1日注文処理件数の推移（億件/日） 従来のデータ分析基盤では、こうした両面の要件を同時に満たすことが難しく、スケーラビリティや処理性能に限界がありました。こうした課題を解決するため、東証は AWS のクラウド技術を活用し、システムリソースやトランザクションログを蓄積・分析する高性能かつ柔軟なデータ分析基盤を AWS 上に整備しました。 背景と課題 近年、取引データの発生件数増加に伴い、arrowhead では日々数億件規模のデータが生成・蓄積され、それらの大量データが分析対象となっています。従来のデータ分析基盤では Excel VBA や個別開発したツール等を駆使していましたが、膨大なデータを扱うには非効率的であり 、半日以上に及ぶデータ抽出・集計処理が端末を占有するなど、日々の解析処理やレポート作成に多大な時間と労力を要していました。また、オンプレミス環境ではサーバ増設やストレージ拡張に時間がかかり、急速な市場変化や突発的な取引量の増加に柔軟に対応することが困難でした。さらに、システム全体の安定運用や障害発生時の迅速な原因特定、キャパシティ計画の高度化といった運用面での課題にも対応する必要がありました。 ソリューション概要 上記課題の解決に向けて AWS の各サービスをどのように活用したかについて、下図のアーキテクチャ図と共に解説します。 オンプレミス領域から AWS へのデータ連携においては、特にリアルタイム性と大規模データ処理能力が重視されます。arrowhead で1秒間に数万件単位で発生する各種電文ログやリソース監視データは、オンプレミス環境のサーバ上に集約されます。これらのデータは、サーバ上で稼働する Amazon Kinesis Agent によって取得され、 AWS Direct Connect や AWS Transit Gateway などの専用線ネットワークを経由して、安全かつ高速に AWS クラウド環境へ転送されます。その後、 Amazon Data Firehose を用いてリアルタイムで AWS 環境に連携されたのち Amazon S3 に蓄積され、 AWS Lambda による ETL 処理を経て Amazon Redshift に格納されます。この一連の処理を通じて、多種多様な膨大なデータを、セキュアかつ遅滞なく連携することを可能にしました。 このリアルタイム連携の主な対象となるのが「電文ログ」と「リソース監視データ」です。電文ログは、業務観点での分析や障害発生時のトラブルシューティングなど多岐にわたる用途で活用されます。また、リソース監視データは、CPU やメモリ、ネットワーク帯域、ディスク I/O など各種リソースの監視やボトルネック分析、将来的なキャパシティ拡張計画の根拠データとして利用されています。 Amazon Redshift は数億件規模のデータを高速かつ並列に処理することができ、ピーク時の高スループットにも耐えうるスケーラビリティを実現しています。これにより、電文ログやリソース監視データの大量集計・分析が短時間で可能となり、システム部門はリアルタイムに近い形で状況把握や性能解析を実施できます。 また、Amazon Redshift 上での分析結果は、ダッシュボードやレポートとして可視化され、JPX グループ全役職員が常時閲覧可能なかたちで展開されるとともに、異常検知や将来的なキャパシティ計画の根拠データとしても活用されています。例えば、過去の取引量やリソース使用状況の推移をもとに、将来的なシステム増強のタイミングや必要スペックを予測したり、障害発生時のリソース逼迫状況を迅速に特定することが可能となりました。 導入効果 AWS 上にデータ分析基盤を構築することによって、従来の手法では数時間要していたデータ分析処理が、Amazon Redshift を中心とした並列処理や AWS Lambda や AWS Step Functions による自動化により数分で完了するようになりました。これにより、運用担当者は日々の業務負荷を大幅に軽減し、より高度な分析や障害対応、改善活動にリソースを集中できるようになりました。また、AWS を使用することにより、必要なリソースをオンデマンドで追加できるため、突発的な取引データの増加や新たな分析ニーズにも柔軟に対応できるようになっています。さらに、性能監視やキャパシティ計画を自動化することで、システムの安定性と信頼性が向上し、障害発生時の影響範囲の特定や復旧対応の迅速化にも寄与しています。 今後の展望 今後、さらなる取引データの増加に対しても、安定した市場運営を継続するのはもとより、AI などによる異常検知や予測など、分析基盤としての一層の強化を AWS を活用して進めていく予定です。 執筆者 齋藤 尚樹 (株式会社東京証券取引所 IT開発部トレーディングシステム 調査役) 日本取引所グループに入社後、東京証券取引所のシステム部門において、株式売買システム「arrowhead」のインフラ開発のほか、RFQ プラットフォーム「CONNEQTOR」の初期開発からローンチ、運用まで一貫して担当し、取引インフラの高度化を推進。また、AWS を活用したデータ分析基盤を開発し、クラウド技術を活用したキャパシティ監視の運用効率化などを主導。

本ブログは 2025 年 12 月 15 日に公開された AWS Blog “ What AWS Security learned from responding to recent npm supply chain threat campaigns ” を翻訳したものです。 AWS のインシデント対応チームは、お客様、AWS クラウド、AWS グローバルインフラストラクチャを保護するために 24 時間体制で活動しています。この活動を通じて、さまざまな課題から学び、特徴的な傾向を発見しています。 ここ数か月、サードパーティのソフトウェアリポジトリに関連する注目度の高いソフトウェアサプライチェーン攻撃キャンペーンが発生し、あらゆる組織にとってソフトウェアサプライチェーンを保護することの重要性が浮き彫りになりました。この記事では、Nx パッケージの侵害、Shai-Hulud ワーム、Amazon Inspector が 15 万件を超える悪意のあるパッケージを特定したトークンファーミングキャンペーン (オープンソースレジストリで確認された最大規模の攻撃の 1 つ) など、最近の脅威に AWS がどのように対応したかをご紹介します。 AWS Security は、この記事で紹介する各事例に対して、一貫した体系的なアプローチで対応しました。AWS のインシデント対応アプローチの重要な部分は、将来のインシデントに備えてセキュリティを向上させるために、対応ワークフローとセキュリティシステムを継続的に改善することです。また、お客様とグローバルなセキュリティコミュニティの改善を支援することにも深くコミットしています。この記事の目的は、これらのインシデントへの対応経験と、そこから得た教訓を共有することです。 生成 AI を通じて拡散を試みた Nx の侵害 2025 年 8 月下旬、サードパーティソフトウェアの生成 AI プロンプト実行における異常なパターンが検出され、インシデント対応チームへ即時にエスカレーションが行われました。30 分以内にセキュリティインシデントの指揮体制が確立され、AWS の世界各地のチームが連携して調査を開始しました。 調査の結果、 侵害された 人気の npm パッケージ Nx を通じて、生成 AI コマンドラインツールを悪用するように設計された JavaScript ファイル「telemetry.js」の存在を特定しました。 AWS のチームはマルウェアを分析し、攻撃者が GitHub を通じて機密性の高い設定ファイルを窃取しようとしていたことを確認しました。しかし、有効なアクセストークンの生成に失敗したため、データが侵害されることはありませんでした。この分析により、AWS とお客様を保護するための直接的な対策に役立つ重要なデータが得られました。 インシデント対応プロセスの中で、AWS のチームが実施した主なタスクには以下が含まれます。 AWS サービスとインフラストラクチャの包括的な影響アセスメントを作成しました。このアセスメントは、インシデントの範囲を定義し、対応の一環として検証が必要な環境の領域を特定するマップとして機能します 侵害された npm パッケージへのさらなる露出を防ぐために、リポジトリレベルでの npm パッケージのブロックリスト登録を実施しました 影響を受けた可能性のあるリソースを特定し、他の攻撃ベクトルを探すための詳細な調査を実施しました 影響を受けたホストの調査、分析、修復を行いました 分析から得た知見を活用して、環境全体の検出機能を改善し、Amazon Q のセキュリティ対策を強化しました。これには、認証情報の窃取を拒否する新しいシステムプロンプトガードレール、システムプロンプトの抽出を防ぐ修正、権限の高い実行モードに対する追加の強化対策が含まれます この作業から得られた知見は、インシデント対応プロセスに取り込まれ、異常なふるまいを監視する方法と複数のインテリジェンスソースを相互参照する方法を改善することで、検出メカニズムを強化しました。これらの取り組みは、その後の npm サプライチェーン攻撃キャンペーンの特定と対応において重要な役割を果たしました。 Shai-Hulud とその他の npm キャンペーン その後、わずか 3 週間後の 2025 年 9 月上旬に、他の 2 つの npm サプライチェーンキャンペーンが始まりました。最初のキャンペーンは 18 の人気パッケージ (Chalk や Debug など) を標的とし、2 番目の「Shai-Hulud」と呼ばれるキャンペーンは、最初の波で 180 のパッケージを標的とし、2025 年 11 月下旬には第 2 波の「Shai-Hulud 2」が発生しました。これらのタイプのキャンペーンは、信頼された開発者のマシンを侵害して開発者がアクセス可能なシステムへの足がかりを得ようとします。 Shai-Hulud ワームは、npm トークン、GitHub パーソナルアクセストークン、クラウド認証情報を窃取しようとします。npm トークンが見つかると、Shai-Hulud は、それらのトークンが npm レジストリでアクセスできるパッケージの更新として、感染したパッケージを公開することで、その範囲を拡大します。侵害されたパッケージは postinstall スクリプトとしてワームを実行し、新しいユーザーがダウンロードするたびに次々と感染していきます。また、このワームは GitHub リポジトリを改ざんして悪意のあるワークフローを使用し、すでに感染したリポジトリで足がかりを維持しつつ、感染拡大を試みます。 これらのイベントはそれぞれ異なるアプローチを取りましたが、Nx パッケージの侵害への対応から AWS Security が学んだ教訓は、これらのキャンペーンへの対応に効果を発揮しました。Shai-Hulud の影響を受けたパッケージが公開されてから 7 分以内に、AWS は対応プロセスを開始しました。これらの対応中に実施した主なタスクには以下が含まれます。 影響を受けたパッケージを Open Source Security Foundation (OpenSSF) に登録し、セキュリティコミュニティ全体での連携対応を可能にしました > 詳細は AWS Security Blog 「サプライチェーン攻撃への防御策: Chalk/Debug 侵害と Shai-Hulud ワームの対応事例から」 をご参照ください。Amazon Inspector チームの検出システムがこれらのパッケージをどのように発見し、OpenSSF と連携してセキュリティコミュニティがこのようなインシデントに対応できるよう支援しているかについて説明しています。 異常なふるまいを検出するための監視を実施しました。疑わしいアクティビティが検出された場合、 AWS Personal Health Dashboard 通知、AWS サポートケース、アカウントのセキュリティ連絡先への直接メールを通じて、影響を受けたお客様に即座に通知しました ワームの完全な機能をより深く理解するために、侵害された npm パッケージを分析しました。この分析では、生成 AI を使用してカスタムデトネーションスクリプト (マルウェア実行スクリプト) を開発し、制御されたサンドボックス環境で安全に実行しました。この作業により、マルウェアが GitHub トークン、AWS 認証情報、Google Cloud 認証情報、npm トークン、環境変数を標的にするために使用する手法が明らかになりました。この情報を基に、AI を使用して難読化された JavaScript コードを分析し、既知の指標と影響を受けたパッケージの範囲を拡大しました 認証情報の窃取と一致する異常なふるまいの検出方法、npm リポジトリ全体のパターン分析方法、そして複数のインテリジェンスソースとの相互参照を改善することで、AWS Security はこれらのタイプの組織的なキャンペーンについての理解を深めることができました。これにより、正当なパッケージアクティビティとこれらのタイプの悪意のあるアクティビティを区別できるようになりました。この取り組みにより、わずか 1 か月後にはチームがさらに効果的に対応できるようになりました。 tea[.]xyz トークンファーミング 10 月下旬から 11 月上旬にかけて、Amazon Inspector チームが以前のインシデントで改良した手法により、侵害された npm パッケージの急増を検出しました。tea[.]xyz は、オープンソースソフトウェアの開発者やメンテナーに対して、プロジェクトの利用状況に応じて暗号資産の Tea トークンを付与するプラットフォームです。改良した検出システムは、このトークンを不正に取得しようとする新たな攻撃を検出しました。 チームは、脅威アクターのキャンペーン中に 15 万件の侵害されたパッケージを発見 しました。検出のたびに、チームは 30 分以内に悪意のあるパッケージを OpenSSF の悪意のあるパッケージレジストリに自動的に登録することができました。この迅速な対応により、Amazon Inspector を使用しているお客様を保護しただけでなく、これらの結果をコミュニティと共有することで、他のチームやツールも自社の環境を保護できるようになりました。 AWS Security チームは、脅威を検出するたびに、新しいことを学び、それをインシデント対応プロセスに取り込んで検出機能をさらに強化しています。このキャンペーンの独自のターゲットである tea[.]xyz トークンは、AWS Security チームが導入しているさまざまな検出と保護を改良する新たな機会となりました また、この記事をまとめていた 2025 年 12 月に、npm パッケージを標的とした新たな攻撃を確認しました。1 週間で npm レジストリで約 1,000 件の疑わしいパッケージを検出しました。”elf-” と呼ばれるこの攻撃は、機密性の高いシステムデータと認証情報を窃取するように設計されていました。AWS の自動防御メカニズムはこれらのパッケージを迅速に特定し、OpenSSF に報告しました。 組織を保護する方法 この記事では、AWS がインシデント対応プロセスからどのように学んでいるか、そして npm レジストリを標的とした最近のサプライチェーンキャンペーンが、AWS の内部システムと、お客様が責任共有モデルにおける責任を果たすために使用する製品の改善にどのように役立ったかを説明しました。お客様ごとに規模やシステムは異なりますが、 AWS Well-Architected フレームワーク と AWS Security Incident Response テクニカルガイド を組織の運用に組み込み、以下の戦略を採用して、このような攻撃に対する組織のレジリエンスを強化することをお勧めします。 継続的な監視と強化された検出を実装し、異常なパターンを特定して早期の脅威検出を可能にしてください。複数の信頼できるソースと結果を比較し、セキュリティツールの検出カバレッジを定期的に監査してください。 AWS Security Hub などの AWS サービスは、クラウド環境、セキュリティの検出結果、コンプライアンスチェックの包括的なビューを提供し、組織が大規模に対応できるようにします。また、 Amazon Inspector はソフトウェアサプライチェーンの継続的な監視を支援します 多層防御を採用してください。自動化された脆弱性スキャンと管理 ( Amazon GuardDuty や Amazon Inspector など)、パッケージの異常なふるまいの監視 ( Amazon CloudWatch と AWS CloudTrail など)、認証情報管理 ( IAM のセキュリティベストプラクティス )、データ漏洩を防ぐためのネットワーク制御 ( AWS Network Firewall ) を組み合わせて実装します 間接的な依存関係やデプロイ場所を含む、すべてのオープンソース依存関係の包括的なインベントリを維持し、脅威が特定されたときに迅速に対応できるようにしてください。 Amazon Elastic Container Registry (ECR) などの AWS サービスは、 コンテナイメージの脆弱性を自動スキャン でき、 AWS Systems Manager [1] [2] はセキュリティとコンプライアンスの目標を達成するように設定できます 疑わしいパッケージをメンテナーに報告し、業界グループと脅威インテリジェンスを共有し、集団防御を強化するイニシアチブに参加してください。最近投稿されたセキュリティ速報の詳細については、 AWS セキュリティ速報 ページをご参照ください。パートナーシップとグローバルなセキュリティコミュニティへの貢献は重要です セキュリティツール、専門家、実践的な対応手順を組み合わせた、プロアクティブなリサーチ、包括的な調査、連携した対応 ( AWS Security Incident Response など) を実装してください この記事で紹介した例が示すように、サプライチェーン攻撃は巧妙さと規模において進化し続けています。これらのキャンペーンには共通のパターンがあります。オープンソースネットワーク内の信頼関係の悪用、大規模な運用、認証情報の窃取と不正なシークレットアクセス、そして従来のセキュリティ制御を回避するための高度な手法の使用です。 これらのイベントから得られた教訓は、多層的なセキュリティ制御の実装、継続的な監視の維持、そして協調的な防御活動への参加が極めて重要であることを示しています。これらの脅威が進化し続ける中、AWS は包括的なセキュリティアプローチを通じてお客様に継続的な保護を提供し続けます。AWS は、自社の業務改善、お客様への支援、そしてセキュリティコミュニティへの貢献のために、継続的な学習に取り組んでいます。 この記事への貢献者: Mark Nunnikhoven、Catherine Watkins、Tam Ngo、Anna Brinkmann、Christine DeFazio、Chris Warfield、David Oxley、Logan Bair、Patrick Collard、Chun Feng、Sai Srinivas Vemula、Jorge Rodriguez、Hari Nagarajan この記事に関するご質問がある場合は、 AWS サポート にお問い合わせください。 Nikki Pahliney Nikki は AWS Security Messaging Manager として、外部のお客様向けのセキュリティコミュニケーションのキュレーション、AWS Security Blog および aws.amazon.com/security のウェブコンテンツの管理に携わるセキュリティメッセージングスペシャリストのチームを率いています。IT セキュリティとセキュリティメッセージング、業務プロセスの再設計、テクニカルプログラムマネジメント、財務モデリング、ビジネスマネジメント、採用など、幅広い経験を持っています。 David Magnotti David Magnotti は Amazon Threat Intelligence のプリンシパルセキュリティエンジニアです。Amazon のサイバー脅威インテリジェンス機能を支える調査プログラムの設計と運用を担当しています。国家支援型や高度な犯罪活動を含むサイバー脅威アクティビティの分析に注力し、調査結果を Amazon と AWS 全体で実行可能な保護策に変換しています。 Jeff Laskowski Jeff は、エンタープライズトランスフォーメーションと戦略的イノベーションにおいて 30 年以上の経験を持つ、サイバーセキュリティと IT のベテランエグゼクティブです。現在は AWS のシニアマネージャーとして、グローバルな企業サイバーセキュリティ対応に注力しています。注目度の高いサイバーインシデント調査の指揮、サイバー攻撃からの復旧の指揮、戦略的イニシアチブの推進など、輝かしいキャリアを持っています。バージニア州ハーンドンを拠点とし、Old Dominion University でコンピュータサイエンスを専攻しました。ソフトウェア開発、エンタープライズアーキテクチャ、セキュアな IT 環境に関する専門知識を持っています。 Ryan Tick Ryan は AWS のシニアセキュリティエンジニアで、大規模な脅威検出とインシデント対応に注力しています。AWS 入社前は、コンサルタントとして AWS における潜在的なセキュリティイベントの予防、準備、対応についてお客様を支援していました。仕事以外では、家族との時間を過ごしたり、Notre Dame Fighting Irish のフットボールチームを応援したり、旅行を楽しんでいます。 Charlie Bacon Charlie は AWS の Amazon Inspector のセキュリティエンジニアリングおよびリサーチ責任者です。Amazon Inspector やその他の Amazon Security 脆弱性管理ツールを支える脆弱性スキャンとインベントリ収集サービスのチームを率いています。AWS 入社前は、金融およびセキュリティ業界で 20 年間、リサーチと製品開発の両方でシニアロールを務めていました。 Chi Tran Chi は Amazon Web Services のシニアセキュリティリサーチャーで、オープンソースソフトウェアのサプライチェーンセキュリティを専門としています。オープンソースソフトウェアの悪意のあるパッケージを検出する Amazon Inspector のエンジンの研究開発を主導しています。Amazon Inspector の SME として、複雑なセキュリティ実装や高度なユースケースについてお客様に技術的なガイダンスを提供しています。クラウドセキュリティ、脆弱性リサーチ、アプリケーションセキュリティにわたる専門知識を持っています。OSCP、OSCE、OSWE、GPEN などの業界認定資格を保有し、複数の CVE を発見し、オープンソースセキュリティイノベーションに関する特許を出願中です。 Dan Dutrow Dan は AWS Security のソフトウェア開発マネージャーです。Amazon が AWS 全体のネットワーク、アプリケーション、認証情報の悪用を特定し阻止するためにセキュリティテレメトリを分析する内部ツール Sonaris を率いています。ソフトウェアエンジニアリング、データサイエンス、セキュリティ分析を活用してクラウドセキュリティの課題を解決する、学際的なチームの経験豊富なエンジニアリングリーダーです。 Stephen Goodman Stephen は Amazon アクティブディフェンスのシニアマネージャーとして、AWS のお客様とインターネットを脅威アクターから保護するためのデータ駆動型プログラムを主導しています。 Albin Vattakattu BlackHat および DEFCON のスピーカーである Albin は、AWS のシニアセキュリティエンジニア兼チームリードです。ネットワークおよびアプリケーションセキュリティにおいて 10 年以上の専門知識を持っています。AWS 入社前は、北米および南米でインシデント対応チームを率いていました。ニューヨーク大学でサイバーセキュリティの修士号を取得し、CISSP を含む複数のセキュリティ認定資格を保有しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 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 の調達・利活用に係るガイドライン