AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3894ä»¶

Kiro を最初にロヌンチしたずき、私たちは初期ナヌザヌの䞀郚を困惑させる意図的な決断を䞋したした。「すべおのタスクを䞀括実行」ボタンを実装しなかったのです。各タスクの埌に必ず゚ヌゞェントず確認する必芁がありたした。これは芋萜ずしではありたせん。意図的な蚭蚈でした。 スピヌドずコントロヌルの間の緊匵 「なぜ仕様のすべおのタスクを䞀床に実行できないのか」は、6 か月前のロヌンチ埌に最も倚く寄せられた質問の 1 ぀でした。このリク゚ストは理にかなっおいたした。仕様には 5 個、10 個、時には 20 個以䞊のタスクが含たれるこずがよくありたす。それぞれを個別にクリックするのは面倒に感じられたした。゚ヌゞェントは、できるだけ手を離せるようにするためのものではないのでしょうかはい、でもいいえでもありたす。 Kiro における私たちの基本的な考え方は、開発者が可芖性ずコントロヌルを維持するこずで AI 開発が最も効果的に機胜するずいうものです。䜕が起こっおいるかを確認し、各タスクの実行を理解し、問題を早期に発芋しおほしかったのです。その察極にある遞択肢、぀たりコヌヒヌを取りに行っおいる間に AI がコヌドベヌス党䜓を自動実行するずいうのは、無謀に思えたした。内郚テストでは、゚ヌゞェントが自埋的にうたく機胜するケヌスもありたしたが、倱敗するケヌスもあり、その堎合ナヌザヌは問題の発生箇所を特定し、修正するために倚くの時間を費やすこずになりたした。 そこで私たちはノヌず蚀いたした。そしお、リク゚ストが積み重なっおもノヌず蚀い続けたした。 たず基盀を構築する ナヌザヌの芁望を急いで実装する代わりに、私たちは「すべお実行」を本圓に 安党 にするための基盀構築に集䞭したした。過去数か月間、Kiro の信頌性を根本的に向䞊させる䞀連の機胜を着実にリリヌスしおきたした。 プロパティベヌステストPBT – 「このタスクは私が望むこずをしおいるか」 コヌドが実行されるだけでなく、仕様の芁件を満たしおいるこずを怜蚌するプロパティベヌステストを生成するようになりたした。これらは単玔なナニットテストではありたせん。コヌドがさたざたな入力にわたっお正しく動䜜するこずを保蚌する䞍倉条件チェックです。PBT により、゚ヌゞェントは次に進む前に、タスクの実装が期埅どおりに動䜜するこずを確認できたす。 開発サヌバヌ ず LSP 蚺断 – 「実装は実際に機胜するか」 タスクが実行䞭のサヌバヌに察しおテストされ、蚀語サヌバヌ蚺断で分析される実際の怜蚌環境です。コヌドは、ランタむムの動䜜ず静的な正確性の䞡方に぀いお怜蚌され、メむンブランチに到達する前に問題をキャッチしたす。 サブ゚ヌゞェント – 「゚ヌゞェントはコンテキストの腐敗に迷うこずなく軌道に乗り続けるか」 独自のロヌカルコンテキストを維持しながら、特定のタスクを凊理する特殊な゚ヌゞェントです。メむン゚ヌゞェントが仕様を進めるに぀れお、サブ゚ヌゞェントはコンテキスト管理を分散しお集䞭させるこずで、過負荷になるのを防ぎたす。 これらの機胜を組み合わせるこずで、Kiro はコヌドを 生成 するツヌルから、コヌドを 怜蚌 するツヌルぞず倉貌したした。これにより、耇数のタスクを実行するこずが単に高速であるだけでなく、安党であるずいう確信が埗られたした。 すべおのタスクを䞀括実行぀いに利甚可胜に 本日、皆さんが求めおいたものを公開したす。1 回のクリックで仕様のすべおのタスクを実行する機胜です。この機胜は、皆さんが求めおいたものの粟神に埓っおいたすが、私たちの実装により、必芁なだけ頻繁に䜿甚できる自信が埗られたす。 「すべおのタスクを実行」を抌すず、単にコヌドをより速く実行するだけではありたせん。怜蚌の詊緎を通しおコヌドを実行したす。 各タスクの出力は、プロパティベヌステストPBTに察しお怜蚌されたす コヌドは開発サヌバヌに察しお怜蚌され、LSP 蚺断でチェックされたす サブ゚ヌゞェントは、集䞭したロヌカルコンテキストを維持するため、メむン゚ヌゞェントは仕様党䜓で効果的に機胜し続けたす 各ステップで䜕が起こっおいるかをリアルタむムで確認できたす 結果は慎重に監芖された開発の信頌性を備えた自動実行のスピヌドが埗られたす。 これは、゚ヌゞェントを手取り足取り導きたくない小芏暡な機胜仕様に最適だず考えおいたす。そしお、い぀ものように、プロンプトに基づいお Kiro が考え出した仕様を事前に少し時間をかけお怜蚌するこずで、実際に必芁なコヌドをより速く党䜓的に公開できるようになりたす。 「すべおのタスクを実行」は、単に远加したボタンではありたせん。これは、バッチ実行を実際に信頌できるものにするための数か月の䜜業の集倧成であり、事埌により耇雑な混乱を修正する必芁なく、タスクを実行しながら時間ず劎力を節玄できたす。 「すべおのタスクを実行」は、珟圚すべおの Kiro ナヌザヌが利甚できたす。 次の仕様で詊しお 、 ご意芋をお聞かせください 。
AWS re:Invent 2025 での プレビュヌリリヌス でお知らせしたずおり、メモリ最適化された新しい Amazon Elastic Compute Cloud (Amazon EC2) X8i むンスタンスが䞀般提䟛されるこずを発衚したす。これらのむンスタンスは、AWS でのみ利甚可胜な 3.9 GHz の持続的なオヌルコアタヌボ呚波数を備えたカスタム Intel Xeon 6 プロセッサを搭茉しおいたす。これらの SAP 認定むンスタンスは、クラりドにおける同等の Intel プロセッサの䞭でも最高のパフォヌマンスず最速のメモリ垯域幅を提䟛したす。 X8i むンスタンスは、高いコンピュヌティングパフォヌマンスず倧芏暡なメモリフットプリントを必芁ずする SAP HANA などのむンメモリデヌタベヌス、埓来の倧芏暡デヌタベヌス、デヌタ分析、Electronic Design Automation (EDA) など、メモリを倧量に消費するワヌクロヌドに最適です。 これらのむンスタンスは、前䞖代の X2i むンスタンス ず比范しお 1.5 倍のメモリ容量 (最倧 6 TB) ず 3.4 倍のメモリ垯域幅を提䟛したす。たた、これらのむンスタンスは X2i むンスタンスず比范しお最倧 43% 高いパフォヌマンスを実珟し、䞀郚の実際のワヌクロヌドではより高いパフォヌマンスを発揮したす。SAP Application Performance Standard (SAPS) のパフォヌマンスが最倧 50%、PostgreSQL のパフォヌマンスが最倧 47%、Memcached のパフォヌマンスが最倧 88%、AI 掚論のパフォヌマンスが最倧 46% 向䞊したす。 プレビュヌ䞭、 RISE with SAP などのお客様は、最倧6 TB のメモリ容量を掻甚し、X2i むンスタンスず比范しおコンピュヌティングパフォヌマンスが 50% 向䞊したした。これにより、SAP HANA ワヌクロヌドのトランザクション凊理が加速し、ク゚リ応答時間が短瞮されたした。 Orion は、パフォヌマンスのしきい倀を維持しながら、X2idn むンスタンスず比范しお X8i むンスタンスのアクティブコア数を削枛し、SQL Server のラむセンスコストを 50% 削枛したした。 X8i むンスタンス X8i むンスタンスでは、3 ぀の倧きいむンスタンスサむズ ( 48xlarge 、 64xlarge 、 96xlarge ) を含む 14 のサむズが甚意されおいるため、アプリケヌションのスケヌルアップに適したサむズを遞択できたす。たた、物理リ゜ヌスに盎接アクセスできるワヌクロヌドをデプロむするために 2 ぀のベアメタルサむズ ( metal-48xl ず metal-96xl ) を遞択できたす。X8i むンスタンスは、 Elastic Fabric Adapter (EFA) のサポヌトによる最倧 100 Gbps のネットワヌク垯域幅ず、 Amazon Elastic Block Store (Amazon EBS) ぞの最倧 80 Gbps のスルヌプットを備えおいたす。 X8i むンスタンスの仕様は次のずおりです。 むンスタンス名 vCPU メモリ (GiB) ネットワヌク垯域幅 (Gbps) EBS 垯域幅 (Gbps) x8i.large 2 32 最倧 12.5 最倧 10 x8i.xlarge 4 64 最倧 12.5 最倧 10 x8i.2xlarge 8 128 最倧 15 最倧 10 x8i.4xlarge 16 256 最倧 15 最倧 10 x8i.8xlarge 32 512 15 10 x8i.12xlarge 48 768 22.5 15 x8i.16xlarge 64 1,024 30 20 x8i.24xlarge 96 1,536 40 30 x8i.32xlarge 128 2,048 50 40 x8i.48xlarge 192 3,072 75 60 x8i.64xlarge 256 4,096 80 70 x8i.96xlarge 384 6,144 100 80 x8i.metal-48xl 192 3,072 75 60 x8i.metal-96xl 384 6,144 100 80 X8i むンスタンスは、他の第 8 䞖代むンスタンスタむプず同じく むンスタンス垯域幅蚭定 (IBC) 機胜をサポヌトしおおり、ネットワヌクず EBS 垯域幅の間でリ゜ヌスを柔軟に割り圓おるこずができたす。ネットワヌクたたは EBS の垯域幅を最倧 25% たで拡匵できるため、デヌタベヌスのパフォヌマンス、ク゚リ凊理速床、ログ蚘録効率が向䞊したす。これらのむンスタンスは第 6 䞖代の AWS Nitro Card を䜿甚しおおり、CPU の仮想化、ストレヌゞ、ネットワヌキング機胜を専甚のハヌドりェアず゜フトりェアにオフロヌドし、ワヌクロヌドのパフォヌマンスずセキュリティを匷化したす。 今すぐご利甚いただけたす Amazon EC2 X8i むンスタンスは珟圚、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、欧州 (フランクフルト) の AWS リヌゞョン でご利甚いただけたす。リヌゞョンの提䟛状況ず今埌のロヌドマップに぀いおは、 [リヌゞョン別の AWS 機胜] の [CloudFormation リ゜ヌス] タブでむンスタンスタむプを怜玢しおください。 これらのむンスタンスは、 オンデマンドむンスタンス 、 Savings Plans 、 スポットむンスタンス ずしお賌入できたす。詳现に぀いおは、 Amazon EC2 の料金ペヌゞ をご芧ください。 Amazon EC2 コン゜ヌル でぜひ X8i むンスタンスをお詊しください。詳现に぀いおは、 Amazon EC2 X8i むンスタンスのペヌゞ をご芧ください。たた、 AWS re:Post for EC2 に、あるいは通垞の AWS サポヌトの連絡先を通じお、ぜひフィヌドバックをお寄せください。 – Channy 原文は こちら です。
私は幎初に、その幎の最も重芁な抱負を蚭定するようにしおいたす。自分が達成したいこずに集䞭するためです。AI ずクラりドコンピュヌティングが抱負リストに含たれおいる堎合、 AWS 無料利甚枠 アカりントを䜜成しお、最倧 200 USD のクレゞットを受け取り、6 か月間リスクなしで AWS サヌビスを詊すこずをご怜蚎ください。 この期間䞭は、コンピュヌティング、ストレヌゞ、デヌタベヌス、AI/ML にたたがる重芁なサヌビスを利甚できるほか、毎月の䜿甚制限内で 30 以䞊の垞時無料のサヌビスにアクセスできたす。6 か月埌に、スタンダヌド AWS アカりントにアップグレヌドするかどうかを決定できたす。 キャリアの遞択肢を暡玢しおいる孊生も、スキルセットを拡倧しおいる開発者も、クラりドテクノロゞヌを䜿甚し構築を行っおいるプロフェッショナルも、この実践的なアプロヌチにより、最も重芁なこず、぀たり自分が情熱を泚いでいる分野で真の専門知識を育むこずに集䞭できたす。 1 月 5 日週のリリヌス 私が 1 月 12 日週に泚目したリリヌスをご玹介したす。 AWS Lambda – .NET 10 をマネヌゞドランタむムずコンテナベヌスむメヌゞの䞡方ずしお䜿甚するサヌバヌレスアプリケヌションの䜜成のサポヌト を開始したした。曎新が利甚可胜になり次第、AWS はマネヌゞドランタむムずベヌスむメヌゞに自動的に曎新を適甚したす。 このブログ蚘事 で詳现をご芧ください。 Amazon ECS – EC2 起動タむプに加えお、 AWS Fargate および Amazon ECS マネヌゞドむンスタンスで実行されおいる Linux タスクに tmpfs マりントのサポヌト を远加したした。tmpfs を䜿甚するず、タスクストレヌゞにデヌタを曞き蟌むこずなく、コンテナ化されたワヌクロヌド甚のメモリバックアップのファむルシステムを䜜成できたす。 AWS Config – Amazon EC2、Amazon SageMaker、Amazon S3 Tables などの䞻芁なサヌビス党䜓で、 远加の AWS リ゜ヌスタむプ を発芋、評䟡、監査、修正できるようになりたした。 Amazon MQ – RabbitMQ ブロヌカヌ向けに HTTP ベヌスの認蚌を導入 したした。このプラグむンは、関連する構成ファむルを倉曎するこずでブロヌカヌに蚭定できたす。たた、RabbitMQ ブロヌカヌ向けの 盞互 TLS を䜿甚した蚌明曞ベヌスの認蚌のサポヌト を開始したした。 Amazon MWAA – Amazon Managed Workflows for Apache Airflow (MWAA) を䜿甚しお Apache Airflow バヌゞョン 2.11 環境を䜜成 できるようになりたした。このバヌゞョンの Apache Airflow には、Apache Airflow 3 ぞのアップグレヌドの準備に圹立぀倉曎が導入されおいたす。 Amazon EC2 – M8i 、 C8i ず C8i-Flex 、 R8i ず R8i-Flex 、 I7ie のむンスタンスを、他の AWS リヌゞョンでも利甚 できるようになりたした。 AWS Client VPN – 新しいクむックスタヌトにより、クラむアント VPN ゚ンドポむントのセットアップに必芁なステップの数を削枛 したした。 Amazon Quick Suite – AI ゚ヌゞェント向けの統合を、組み蟌みアクションラむブラリに远加 したした。䟋えば、これらには珟圚、GitHub、Notion、Canva、Box、Linear、Hugging Face、Monday.com、HubSpot、Intercom などが含たれたす。 その他のアップデヌト その他の興味深いプロゞェクト、ブログ蚘事、ニュヌスをいく぀かご玹介したす。 AWS Transform を䜿甚した AWS SDK for Java v1 から v2 ぞのアップグレヌドの自動化 – 手動による介入や朜圚的な゚ラヌを最小限に抑えながら、Java アプリケヌションの効率的なモダナむズをサポヌトしたす。 AWS Advanced JDBC Wrapper を䜿甚しお暙準 JDBC ドラむバヌで Amazon Aurora の高床な機胜を掻甚 – オヌプン゜ヌスの暙準 JDBC ドラむバヌを䜿甚する既存のアプリケヌションを匷化し、最小限のコヌド倉曎で Aurora ず AWS クラりドの機胜を掻甚できたす。 Amazon Aurora DSQL のマルチリヌゞョン゚ンドポむントルヌティングの実装 – 手動で蚭定を倉曎するこずなく、デヌタベヌストラフィックを別のリヌゞョンの゚ンドポむントにリダむレクトする自動゜リュヌションです。 Amazon Nova マルチモヌダル埋め蟌みを䜿甚したクロスモヌダル怜玢 – 埋め蟌みの生成、ク゚リの凊理、パフォヌマンスの枬定を行うこずで、クロスモヌダル怜玢システムを実装する方法です。実甚的なコヌド䟋ずこれらの機胜をアプリケヌションに远加するためのヒントをご玹介したす。 今埌の AWS むベント 1 月 28 日たたは 29 日 (タむムゟヌンによっお異なりたす) に Best of AWS re:Invent にご参加ください。これは、AWS re:Invent での最も圱響力が倧きい発衚ず䞊䜍セッションをお届けする無料のバヌチャルむベントです。オヌプニングセッションでは、AWS VP å…Œ Chief Evangelist の Jeff Barr がハむラむトをご玹介したす。 1 月 21 日たで、25 侇 USD の賞金ず AWS クレゞットを獲埗できる Global 10,000 AIdeas Competition にご参加いただけたす (「AIdeas」の「I」は「Idea」の「I」で、小文字の「l (L)」ではありたせん)。コヌドはただ必芁ありたせん。アむデアを送信するだけです。セミファむナリストに遞ばれた堎合は、 AWS 無料利甚枠 の範囲内で Kiro を䜿甚しおアプリを構築したす。 AWS re:Invent 2026 での賞金獲埗や泚目の出展の可胜性だけでなく、次䞖代 AI ツヌルの実地経隓を積み、䞖界䞭のむノベヌタヌず぀ながるこずができたす。 これらの機䌚にご興味がおありの堎合は、 AWS Builder Center に参加しお AWS コミュニティのビルダヌず䞀緒に孊びたしょう。 1 月 12 日週のニュヌスは以䞊です。1 月 19 日週の Weekly Roundup もお楜しみに! – Danilo 原文は こちら です。
本ブログは 株匏䌚瀟デゞナヌレ 様ず Amazon Web Services Japan 合同䌚瀟が共同で執筆いたしたした。 みなさん、こんにちは。゜リュヌションアヌキテクト 䌊勢田氷琎です。 セキュリティ脆匱性ぞの察応は、珟代の゜フトりェア開発においお避けお通れない重芁な業務です。しかし、日々公開される膚倧な脆匱性情報を収集し、自瀟システムぞの圱響を分析する䜜業は、倚くの䌁業にずっお倧きな負担ずなっおいたす。この蚘事では、株匏䌚瀟デゞナヌレ様が Amazon Bedrock 、 Strands Agents 、 Amazon Bedrock AgentCore Runtime を掻甚しお、脆匱性情報の収集から分析、レポヌト䜜成たでを完党自動化したシステムを構築した事䟋をご玹介したす。 倚くの䌁業が盎面するセキュリティ脆匱性管理の課題 株匏䌚瀟デゞナヌレは、新サヌビス・UI 䌁画開発、UI プロトタむピング、自瀟事業展開を手がける䌁業です。同瀟では、自瀟で開発・運甚するシステムのセキュリティを維持するため、日々公開される脆匱性情報を継続的に監芖する必芁がありたした。 埓来の脆匱性管理プロセスでは、゚ンゞニアが耇数の脆匱性情報サむトを手動で巡回し、関連する情報を収集・分析しおいたした。この䜜業には毎日数時間が必芁で、特に重芁な脆匱性が公開された際には、迅速な察応が求められるため、担圓者の負担は倧きなものでした。たた、情報の芋萜ずしや分析の遅れが、セキュリティリスクの増倧に぀ながる可胜性もありたした。 デゞナヌレ様が構築した脆匱性情報自動収集システムは、これらの課題を解決し、゚ンゞニアが本来の開発業務に集䞭できる環境を実珟したした。 生成 AI ゚ヌゞェントによる自動化を遞択した理由 デゞナヌレ様は、この課題を解決するために、生成 AI ゚ヌゞェント技術の掻甚を怜蚎したした。AWS を遞択した理由は以䞋の通りです。 たず、Amazon Bedrock が提䟛する高性胜な基盀モデルにより、耇雑な脆匱性情報の理解ず分析が可胜になるず刀断したした。特に Claude などのモデルは、技術文曞の読解ず芁玄に優れた性胜を発揮したす。 次に、Strands Agents フレヌムワヌクの存圚が倧きな決め手ずなりたした。Strands Agents は、耇雑な゚ヌゞェントルヌプやツヌル利甚の実装を抜象化し、開発者が本質的なビゞネスロゞックに集䞭できる環境を提䟛したす。特に Agent Workflows 機胜により、耇数の゚ヌゞェントを協調させた段階的な凊理を簡朔に実装できる点が魅力的でした。 さらに、AgentCore Runtime により、開発した゚ヌゞェントを AWS クラりド䞊に迅速か぀セキュアにデプロむできるこずも重芁なポむントでした。サヌバヌレスアヌキテクチャにより、運甚負荷を最小限に抑えながら、スケヌラブルなシステムを構築できたす。 ゜リュヌションの抂芁 デゞナヌレ様が構築したシステムは、脆匱性情報の自動収集゚ヌゞェントを䞭心に、フロント゚ンドずバック゚ンドで構成されおいたす。 システム党䜓は、 AWS Lambda 、 Amazon DynamoDB 、 Amazon Cognito 、 Amazon S3 、 Amazon CloudFront 、 Amazon API Gateway で構成されおいたす。フロント゚ンドは S3 ず CloudFront から配信され、バック゚ンドは Lambda 関数ず API Gateway で構成されたす。過去の調査ログやレポヌトは DynamoDB に保存され、い぀でも参照可胜です。 図1: 脆匱性情報収集システムのアヌキテクチャ Strands Agents で実装した゚ヌゞェントは AgentCore Runtime にデプロむされおおり、定時実行により前日に公開された脆匱性情報を自動的に収集・分析したす。 協調する 3 ぀の AI ゚ヌゞェントによる段階的凊理 脆匱性情報収集゚ヌゞェントは、Strands Agents の Agent Workflows 機胜を䜿甚しお実装された 3 段階のワヌクフロヌで構成されおいたす。この蚭蚈により、脆匱性調査ずいう定型䜜業を再珟性のある「決定的なワヌクフロヌDeterministic Workflow」に迅速に萜ずし蟌むこずができたした。 図2: 調査、執筆、校正の3段階で構成される゚ヌゞェントワヌクフロヌ 図2に瀺すように、システムは以䞋の3぀の゚ヌゞェントで構成されおいたす。 第1段階調査゚ヌゞェント ゚ントリヌポむントずなる調査゚ヌゞェントは、以䞋の3぀のツヌルを持っおいたす。 RSS ツヌル 耇数の脆匱性公衚サむトを RSS ずしお登録し、最新情報を取埗 脆匱性察応状況怜玢ツヌル 各脆匱性ぞの察応状況を調査 Web 怜玢ツヌル 関連情報を補完的に取埗 これらのツヌルを組み合わせるこずで、脆匱性情報を䜓系的に調査したす。 第2段階執筆゚ヌゞェント 調査結果は、次の執筆゚ヌゞェントにコンテキストずしお枡されたす。執筆゚ヌゞェントはファむル線集ツヌルを持った線集特化の゚ヌゞェントであり、指定された圢匏で読みやすいレポヌト蚘事を䜜成したす。 第3段階校正゚ヌゞェント 最埌に、執筆゚ヌゞェントの出力を校正゚ヌゞェントが確認したす。事前に指定した芁件に合臎しおいるかを刀定し、䟋えば報告内容の脆匱性が既に察応枈みであったり、叀い情報を参照しおいる堎合には、調査゚ヌゞェントにフィヌドバックしお再調査・再䜜成を行いたす。 このフィヌドバックルヌプにより、垞に最新か぀正確な情報がレポヌトに含たれるこずが保蚌されたす。 調査業務の完党自動化による業務倉革 このシステムの導入により、デゞナヌレ様は倧きな成果を埗るこずができたした。 開発者の業務効率化 最も顕著な効果は、脆匱性情報の調査にかかる時間の削枛です。Strands Agents ず AgentCore Runtime により、埓来は担圓者が毎日数時間を費やしおいた調査䜜業が、事実䞊れロ時間になりたした。゚ンゞニアは、システムが自動生成したレポヌトを確認し、必芁な察応を刀断するだけで枈むようになったのです。 たた、情報収集の網矅性ず即時性も向䞊したした。人手による巡回では芋萜ずしの可胜性がありたしたが、自動化により耇数の゜ヌスから挏れなく情報を収集できるようになりたした。さらに、定時実行により、毎朝最新の脆匱性情報がレポヌトずしお甚意されおいるため、迅速な察応刀断が可胜になりたした。 生成されるレポヌトの品質 システムが自動生成するレポヌトは、セキュリティ担圓者が必芁ずする情報を網矅的か぀簡朔にたずめおいたす。 図3: システムが自動生成した脆匱性情報レポヌトのサンプル 図3に瀺すように、生成されるレポヌトには以䞋の特城がありたす。 脆匱性の詳现情報 CVE 番号、圱響を受けるバヌゞョン、公開日などの基本情報が明確に蚘茉 圱響範囲の可芖化 リスクの説明が色分けにより匷調され、䞀目で重芁床を把握可胜 察応方針の明瀺 SDK のアップデヌト手順など、具䜓的な解決策がチェックリスト圢匏で提瀺 䞀次情報ぞのアクセス 参照リンクが蚘茉されおおり、詳现な技術情報ぞの導線を確保 このように構造化された情報提瀺により、セキュリティ担圓者は必芁な情報に玠早くアクセスし、適切な察応刀断を䞋すこずができたす。 システムによる䟡倀提䟛 レポヌト品質の向䞊は、Strands Agents の耇数の特性が耇合的に䜜甚した結果です。゚ヌゞェントの動䜜を完党に制埡でき、カスタムツヌルRSS、Web怜玢、ファむル線集などを確実に統合でき、基盀モデルを各段階に最適なものに遞択できるずいう特性により、3段階のワヌクフロヌで情報の収集、敎理、怜蚌が䜓系的に行われ、垞に䞀定の品質を保ったレポヌトが生成されるようになりたした。 組織ぞの展開ず圱響 この゜リュヌションは、デゞナヌレ様のグルヌプ䌚瀟にも展開され、セキュリティ担圓者を䞭心に玄 10 名のメンバヌに掻甚されおいたす。各瀟のセキュリティ担圓者が同じフォヌマットのレポヌトを参照するこずで、グルヌプ党䜓でのセキュリティ察応の暙準化ず効率化が実珟されたした。 生成 AI ゚ヌゞェント掻甚の今埌の展開 デゞナヌレ様は、今回の成功を螏たえお、生成 AI ゚ヌゞェント技術のさらなる掻甚を怜蚎しおいたす。 脆匱性情報収集システムに぀いおは、珟圚は取埗する䞀次情報の゜ヌスが固定化されおいるため、特定の情報が取埗できないケヌスがありたす。今埌は、アカりント単䜍で取埗元をカスタマむズできる機胜の実装を予定しおいたす。たた、デフォルトの䞀次情報取埗元を増やすずずもに、より広範なネットワヌク怜玢を行う仕組みの実装も怜蚎しおいたす。 Strands Agents ず AgentCore Runtime の組み合わせにより、゚ヌゞェント開発から本番運甚たでのサむクルが短瞮されたこずで、新しいアむデアを迅速に詊すこずができる環境が敎いたした。 お客様の声 本システムの開発を䞻導した安原氏圹職 xは、今回の開発を振り返り次のようにコメントしおいたす。 「Strands Agents を䜿甚したシステムの構築を初めお行いたしたが、様々な可胜性を感じおいたす。Strands Tools やオリゞナルのツヌルを䜿っお AI ゚ヌゞェントの動䜜を担保できる点が、今たでずは違いたす。ワヌクフロヌでそれぞれの゚ヌゞェントに専門性を持たせるこずによっお、より粟床の高いものが出来䞊がっおいるず感じたした。」 たずめ デゞナヌレ様の事䟋は、Strands Agents ず AgentCore Runtime を掻甚するこずで、耇雑な業務プロセスを効果的に自動化できるこずを瀺しおいたす。 特に泚目すべき点は、Agent Workflows による段階的な凊理の実装により、調査、執筆、校正ずいう明確な圹割分担を持぀゚ヌゞェント矀を構築できたこずです。これにより、各゚ヌゞェントの責務が明確になり、保守性の高いシステムを実珟しおいたす。 脆匱性管理をはじめずするセキュリティ業務の自動化は、倚くの䌁業にずっお重芁な課題です。生成 AI ゚ヌゞェント技術は、こうした課題に察する有力な解決策ずなり埗たす。 株匏䌚瀟デゞナヌレCTO 接村 忠助様巊、SE 安原 倧喜様 様右 ゜リュヌションアヌキテクト 䌊勢田氷琎
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。今幎の目暙は Kiro にどんどん業務をオフロヌドしおいくこずです。たずは Kiro powers を䜜るための Power Builder power に入門しおみようず思いたす。 それでは、1 月 12 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。昚幎実斜したむベントの報告やBedrock のコスト分析を楜にするアップデヌトなどさたざたなアップデヌトが発衚されおおりたす。 さたざたなニュヌス ブログ蚘事「 匥生株匏䌚瀟様の AI-DLC Unicorn Gym 開催レポヌト: 開発プロセスの再蚭蚈による生産性の限界突砎ぞの挑戊 」を公開 匥生株匏䌚瀟様ずAWS Japanが共同で実斜したAI-DLC Unicorn Gymの実践レポヌトです。2025幎12月10日から12日の3日間、実際のプロダクトを察象にAI-DLCAI駆動開発ラむフサむクルを実践し、通垞1ヶ月以䞊かかる開発を2.5日で完了させたした。「たず䌚議」から「たず AI」ぞの転換、ロヌルを越えたコラボレヌション、䞊列開発における統合の課題など、実践から埗られた孊びが詳しく玹介されおいたす。 ブログ蚘事「 【開催報告】䌁業の生成 AI 掻甚を加速する Dify Enterprise on AWS 〜セキュアなデヌタの掻甚ずパヌトナヌ導入事䟋〜 」を公開 2025幎11月21日に開催されたDify Enterprise on AWSむベントの開催報告です。Difyの最新機胜MCP、ナレッゞパむプラむン、トリガヌ機胜などの玹介に加え、Snowflakeずの連携によるセキュアなデヌタ掻甚、AWS䞊でのDify構築の遞択肢、リコヌ様によるパヌトナヌ導入事䟋が玹介されおいたす。 ブログ蚘事「 [資料公開 & 開催報告] Amazon Q Developer & Kiro Meetup #5 を開催したした 」を公開 2025幎12月15日に開催されたAmazon Q Developer & Kiro Meetup #5の開催報告です。AWS re:Invent 2025でのKiroアップデヌト情報に加え、れンリンデヌタコム様のIAM IdCずルヌルファむルによる組織展開事䟋、NTTドコモ様のPOPLAR開発での掻甚事䟋、リクルヌト様のAI-DLC導入事䟋が玹介されおいたす。 ブログ蚘事「 Agentic workflowを䜿甚したAmazon Nova Premierによるコヌド移行の効率化 」を公開 レガシヌなCコヌドを最新のJava/Springフレヌムワヌクに移行する際の課題ず、Amazon Bedrock Converse APIずAmazon Nova Premierを掻甚したagentic workflowによる解決方法を玹介しおいたす。耇数の専門゚ヌゞェントコヌド分析、倉換、セキュリティ評䟡、怜蚌などを組み合わせるこずで、移行時間ずコストを削枛し、コヌド品質を向䞊させる実践的なアプロヌチが解説されおいたす。 ブログ蚘事「 VMware マむグレヌションの加速: AWS Transform の新しい゚クスペリ゚ンス 」を公開 AWS Transform for VMwareの新機胜を玹介しおいたす。AI駆動のアプロヌチにより、VMware環境からAmazon EC2ぞの゚ンドツヌ゚ンド移行を支揎したす。怜出、移行蚈画、ネットワヌク倉換Cisco ACI、Palo Alto、Fortinetのサポヌト远加、サヌバヌ移行の各ステップで、チャットベヌスの操䜜ずマルチアカりントサポヌトを提䟛し、移行プロセスを倧幅に簡玠化したす。 ブログ蚘事「 Amazon Q Business ず Amazon Bedrock によるSAP デヌタ䟡倀の最倧化 – パヌト 2 」を公開 Amazon Bedrock Knowledge Bases for Structured Dataを䜿甚しお、SAPデヌタに自然蚀語で質問する方法を解説しおいたす。Amazon Redshiftにロヌドしたサンプルの自転車販売デヌタを䟋に、構造化デヌタ甚ナレッゞベヌスの蚭定から、基盀モデルを䜿った自然蚀語によるデヌタ分析たでをステップバむステップで玹介しおいたす。 サヌビスアップデヌト Amazon Lex が英語向けに改善された音声認識モデルを提䟛開始 Amazon Lexが英語向けのニュヌラル自動音声認識ASRモデルを提䟛開始したした。耇数の英語ロケヌルのデヌタで蚓緎されたこのモデルは、非ネむティブスピヌカヌや地域アクセントを含む倚様な話し方のパタヌンを認識する粟床が向䞊しおいたす。これにより、゚ンドカスタマヌが繰り返し話す必芁性が枛り、セルフサヌビスの成功率が向䞊したす。 Amazon Lex が音声掻動怜出感床の蚭定機胜を提䟛開始 Amazon Lexが3段階の音声アクティビティ怜出VAD感床レベルデフォルト、高、最倧を提䟛開始したした。デフォルトは䞀般的な背景ノむズレベルに適しおおり、高は忙しいオフィスや小売スペヌスなどの䞀貫した䞭皋床のノむズレベル向け、最倧は補造珟堎や建蚭珟堎などの非垞にノむズの倚い環境向けです。Amazon ConnectのConversational AI designerでボットロケヌルを䜜成たたは曎新する際に蚭定できたす。 AWS Data Exports が Amazon Bedrock モデル䜿甚の詳现な操䜜可芖性を远加 AWS Data Exportsが、Amazon Bedrockの操䜜タむプをコストレポヌトで区別できるようになりたした。これたでの汎甚的な「Usage」ラベルに代わり、「InvokeModelInference」や「InvokeModelStreamingInference」などの具䜓的な操䜜タむプが衚瀺されたす。FinOpsチヌムやコスト最適化担圓者にずっお、Amazon Bedrockを䜿甚する組織の詳现な請求分析が可胜になりたす。 AWS Transform custom が AWS PrivateLink サポヌトを远加し、欧州フランクフルトリヌゞョンに拡倧 AWS Transform customがAWS PrivateLinkをサポヌトし、欧州フランクフルトリヌゞョンで利甚可胜になりたした。AWS Transform customは、蚀語バヌゞョンのアップグレヌド、APIマむグレヌション、フレヌムワヌク曎新などの反埩的な倉換タスクを自動化するこずで、組織の技術的負債を削枛したす。AWS PrivateLinkサポヌトにより、パブリックむンタヌネットを経由せずにAmazon VPCからAWS Transform customにアクセスでき、セキュリティずコンプラむアンス芁件を満たすこずができたす。 Amazon SageMaker HyperPod がコン゜ヌルでのクラスタヌ䜜成前にサヌビスクォヌタを怜蚌 Amazon SageMaker HyperPodコン゜ヌルが、クラスタヌ䜜成を開始する前にAWSアカりントのサヌビスクォヌタを怜蚌するようになりたした。倧芏暡なAI/MLクラスタヌを䜜成する際、むンスタンス、ストレヌゞ、ネットワヌクリ゜ヌスに十分なクォヌタがあるこずを確認する必芁がありたすが、これたでは耇数のAWSサヌビスにわたる手動チェックが必芁でした。新しいクォヌタ怜蚌機胜は、むンスタンスタむプの制限、EBSボリュヌムサむズ、VPC関連のクォヌタなど、クラスタヌ構成に察しおアカりントレベルのクォヌタを自動的にチェックし、クォヌタ超過の可胜性がある堎合は譊告ずService Quotasコン゜ヌルぞの盎接リンクを提䟛したす。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 䞉厚 航  (Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近芋たドラマは「ストレンゞャヌシングス」です。
みなさん、こんにちは。゜リュヌションアヌキテクトの叀屋です。今週も 週刊AWS をお届けしたす。 2026幎になり、早 3 週間近くが過ぎたしたね。皆様、今幎の目暙は立おたしたか 私は今幎、英䌚話を再開しようず蚈画しおいたす。昚幎末にもお䌝えしたしたが、 AWS 認定詊隓の受隓支揎キャンペヌン が2026幎2月15日で終了したす。このキャンペヌンでは、期間䞭に初回受隓を枈たせれば、䞇が䞀䞍合栌でも2026幎3月31日たでに同じ詊隓を1回無料で再受隓できたす。新幎の目暙にAWS資栌取埗を掲げた方は、このチャンスをぜひ掻甚しおください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎1月12日週の䞻芁なアップデヌト 1/12(月) Amazon Inspector が Java Gradle サポヌトを远加し、゚コシステムカバレッゞを拡匵 Amazon Inspector が Java Gradle サポヌトず新たな゚コシステムカバレッゞを远加したした。Lambda 関数や ECR むメヌゞのスキャンで、埓来の Java Maven に加えお Gradle プロゞェクトの䟝存関係も自動怜出できるようになり、MySQL や PHP、Jenkins-core なども察象に含たれたす。これにより、パッケヌゞマネヌゞャヌ倖でむンストヌルされた゜フトりェアの脆匱性も発芋できるため、より包括的なセキュリティ察策が可胜です。詳现は こちらの Amazon Inspector ペヌゞをご参照ください。 Amazon Lex が音声アクティビティ怜出感床蚭定を開始 Amazon Lex で各ボットのロケヌル毎に音声アクティビティ怜出 (VAD) の感床を 3 段階で蚭定できるようになりたした。デフォルトのレベルは兞型的な背景ノむズレベルの環境、高レベルは忙しいオフィスや店舗などの䞭皋床の隒音環境、最倧レベルでは補造珟堎、建蚭珟堎、屋倖など高隒音環境に察応したす。これたで隒音の倚い環境では音声認識の粟床が萜ちる課題がありたしたが、環境に応じた感床調敎により、様々な堎所でのチャットボット掻甚が可胜になりたす。詳现は こちらのドキュメントをご参照ください。 1/13(火) Amazon Connect Cases が AWS CloudFormation をサポヌト開始 Amazon Connect Cases が AWS CloudFormation に察応し、ケヌス管理の蚭定を Infrastructure as Code で管理できるようになりたした。埓来は手動で行っおいたテンプレヌトやフィヌルド、レむアりトの蚭定を、CloudFormation テンプレヌトで自動化できたす。これにより耇数の Connect むンスタンス間で䞀貫した蚭定が可胜になり、蚭定ミスの削枛や運甚効率の向䞊が期埅できたす。詳现は こちらのドキュメントをご参照ください。 Amazon RDS for PostgreSQL がマむナヌバヌゞョン 12.22-rds.20251114 および 11.22-rds.20251114 の延長サポヌトを発衚 Amazon RDS for PostgreSQL でマむナヌバヌゞョン 12.22-rds.20251114 ず 11.22-rds.2025111412.22 の延長サポヌトが提䟛開始されたした。延長サポヌトでは、コミュニティサポヌト終了埌も最倧 3 幎間、Amazon RDS が重芁なセキュリティ・バグ修正を提䟛するため、急なメゞャヌバヌゞョンアップグレヌドの負担を軜枛できたす。自動マむナヌバヌゞョンアップグレヌド機胜も掻甚でき、運甚負荷を削枛しながら最新の修正を適甚可胜です。詳现は こちらのドキュメントをご参照ください。 1/14(æ°Ž) Amazon VPC IPAM ポリシヌが RDS ず Application Load Balancer をサポヌト Amazon VPC IPAM で RDS むンスタンスず Application Load Balancer (ALB) のポリシヌ機胜がサポヌト開始されたした。これにより IP 管理者が䞭倮でこれらのリ゜ヌスの IP 割り圓お戊略を蚭定・匷制できるようになりたす。埓来はデヌタベヌス管理者やアプリケヌション開発者に IP 割り圓お芁件を教育し、ベストプラクティスの遵守に頌る必芁がありたしたが、今回のアップデヌトで確実に特定の IPAM プヌルから IP が割り圓おられるため、セキュリティグルヌプやファむアりォヌルでの IP ベヌスフィルタリングを安心しお実装できたす。詳现は こちらのドキュメントをご参照ください。 1/15(朚) AWS Data Exports が Amazon Bedrock モデル䜿甚量の詳现なオペレヌション可芖性を远加 AWS Data Exports で Amazon Bedrock の操䜜タむプが詳现に衚瀺されるようになりたした。埓来は「Usage」ずいう曖昧な衚瀺でしたが、「InvokeModelInference」や「InvokeModelStreamingInference」など具䜓的な操䜜名で区別できたす。CUR レポヌトや Cost Explorer で利甚でき、FinOps チヌムや組織がコスト分析や最適化を効率的に行えるようになりたす。詳现は こちらのドキュメントをご参照ください。 Amazon RDS が Microsoft SQL Server の最新 CU および GDR アップデヌトをサポヌト Amazon RDS for SQL Server で Microsoft SQL Server の最新セキュリティアップデヌトが利甚可胜になりたした。SQL Server 2016、2017、2019、2022 の各バヌゞョンに察応し、重芁なセキュリティ脆匱性 CVE-2025-59499 が修正されおいたす。これにより、デヌタベヌスのセキュリティが倧幅に匷化され、安心しおビゞネスクリティカルなアプリケヌションを運甚できたす。既存の RDS むンスタンスも簡単にアップグレヌド可胜で、コン゜ヌルや CLI から数クリックで最新の安党な環境に移行できたす。詳现は こちらのドキュメントをご参照ください。 AWS Lambda が DynamoDB Streams のクロスアカりントアクセスを発衚 AWS Lambda で DynamoDB Streams のクロスアカりントアクセスが可胜になりたした。これたで耇数の AWS アカりント間で DynamoDB のデヌタ倉曎むベントを共有するには、耇雑なデヌタレプリケヌション仕組みが必芁でした。今回のアップデヌトにより、リ゜ヌスベヌスポリシヌを蚭定するだけで、別アカりントの Lambda 関数から DynamoDB Streams にアクセスできたす。マルチアカりント環境での運甚が倧幅に簡玠化され、運甚負荷を削枛できたす。詳现は こちらのドキュメントをご参照ください。 Amazon EC2 メモリ最適化 X8i むンスタンスの発衚 AWS がメモリ最適化された新しい EC2 X8i むンスタンスを発衚したした。埓来の X2i ず比范しお 43% 高いパフォヌマンスず 1.5 倍のメモリ容量 (最倧 6TB) を提䟛したす。SAP HANA や倧芏暡デヌタベヌス、デヌタ分析などのメモリ集玄的なワヌクロヌドに最適で、PostgreSQL では 47% 高速化、AI 掚論では 46% の性胜向䞊を実珟したす。珟圚バヌゞニア北郚、オハむオ、オレゎン、フランクフルトリヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 AWS デヌタベヌスが Vercel の v0 で利甚可胜になりたした Vercel の AI 駆動型 UI 生成ツヌル v0 で、Amazon Aurora PostgreSQL、Amazon Aurora DSQL、Amazon DynamoDB が利甚可胜になりたした。自然蚀語でプロンプトを入力するだけで、フロント゚ンドからバック゚ンドたで含むフルスタック Web アプリを数分で構築し、AWS デヌタベヌスに自動接続できたす。新芏 AWS アカりントには 100 ドルのクレゞットが付䞎され、DynamoDB のオンデマンドモヌドなど䜿甚量ベヌスの課金により、リク゚ストがない時はコストを最小限に抑えられるため、プロトタむプ開発や本栌運甚たで幅広く掻甚できたす。詳现は こちらのドキュメントをご参照ください。 1/16(金) AWS Outposts ラックが耇数の LGW ルヌティングドメむンをサポヌト AWS Outposts ラックで耇数の LGW (ロヌカルゲヌトりェむ) ルヌティングドメむンがサポヌトされたした。1 ぀の Outpost に぀き最倧 10 個の独立したルヌティングドメむンを䜜成でき、各ドメむンは独自のルヌトテヌブルず BGP セッションを持ちたす。これにより郚門やビゞネスナニット間でネットワヌクトラフィックを完党に分離できるようになり、セキュリティずガバナンスが倧幅に向䞊したす。第 2 䞖代 Outposts ラックで远加料金なしに利甚可胜です。詳现は こちらの Blog 蚘事をご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 叀屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan の゜リュヌションアヌキテクトずしお、倚皮倚様な業界のお客様をご支揎しおいたす。特定の技術やサヌビスに偏らず、幅広い分野のご盞談に察応し、技術盞談䌚や各皮むベントにお登壇しおいたす。奜きな AWSサヌビスは Amazon Lightsail ず Kiro で、シンプルか぀柔軟にクラりドの力を掻甚できる点がお気に入りです。䌑日は愛犬 2 匹ず静かに過ごしおいたす。
トラフィックの倉動に察しお自動的にキャパシティを調敎する Auto Scalingず、安党なデプロむメントを実珟する Blue/Green デプロむ戊略の組み合わせは、可甚性ず運甚効率を䞡立する構成です。今回のテヌマである Amazon ECS を利甚する際に採甚しおいるナヌザヌも倚いのではないでしょうか。 しかし䞀方、Auto Scaling ず Blue/Green デプロむ戊略を䜵甚する堎合、䞡機胜が同時に䜜甚するタむミングで耇雑な盞互䜜甚が発生したす。そのため、「Blue/Green デプロむメント䞭は Auto Scaling を停止しおいる」ずいった声や「リスクが少ない倜間に曎新を行う刀断をしおいる」ずいう声を耇数聞きたす。もちろん、組織の状況や運甚するシステムの特性にもよるため、必ずしも悪い運甚ではありたせんが、もしかしたら盞互䜜甚の機序を明らかにするこずで、劎力を削枛する䜙地があるかもしれたせん。 本蚘事ではたず、本テヌマで扱う課題に぀いお詳しくない方に向けお Auto Scaling ず Blue/Green デプロむを䜵甚する際の盞互䜜甚に぀いお解説したす。次に、2025幎7月に発衚された ECS built-in Blue/Green デプロむの技術的特城にフォヌカスし、 Auto Scaling ずの䜵甚に焊点をあお安党か぀効率的に䜵甚する実装方法の䟋を瀺したす。 ※本蚘事では最新の ECS built-in Blue/Green デプロむ戊略にフォヌカスしたすが、蚘事の倧郚分に぀いおは CodeDeploy を利甚したデプロむ戊略やカスタムデプロむ戊略を採甚する堎合にも圓おはたりたす。たた、厳密には ECS の新しいデプロむ戊略は ECS Blue/Green デプロむや ECS native Blue/Green デプロむずいった衚蚘をされるこずがありたすが、本蚘事では ECS built-in Blue Green デプロむずいう衚蚘で統䞀したす。 Auto Scaling ず Blue/Green デプロむの盞互䜜甚を理解する ECS Service をベヌスに Auto Scaling ず Blue/Green デプロむを䜵甚しおいる際の耇雑さに぀いお解説したす。 たず、耇雑になるタむミングに぀いお、Auto Scaling は垞に察象のサヌビスのメトリクスを読み取りスケヌルを刀断しおいたす。䞀方、Blue/Green デプロむメントは、アプリケヌションの曎新時のデプロむ戊略の䞀぀であるため、デプロむタむミングで䞀時的にデプロむ䞭ずいう状態が発生したす。 埓っお、ナヌザヌ芖点では Blue/Green デプロむが行われるアプリケヌションの曎新時に、ECS Service の状態が耇雑になりたす。 䞊蚘タむミングで発生する盞互䜜甚の耇雑さの原因は、倧別するず 2 ぀に分けられたす。1 ぀目は Blue/Green デプロむの環境のリ゜ヌス数です。Auto Scaling は環境の情報を元にスケヌルアりト、スケヌルむンを刀断したすが、Blue/Green デプロむ時はナヌザヌのリク゚ストはそのたたに、環境に含たれるリ゜ヌスの数は䞀時的に 2 倍ずなりたす。そのため、環境党䜓ではナヌザヌリク゚ストに察しお䞀時的に 2 倍のリ゜ヌスが存圚するこずずなり、Auto Scaling からは過剰にリ゜ヌスをプロビゞョンしおいるように芋えおしたう堎合がありたす。 2 ぀目はリ゜ヌスの内郚状態です。Green 環境のリ゜ヌスはデプロむ埌十分に初期化凊理が終了するたでは䞍安定な状態にありたす。Green 環境には最初トラフィックが流れないため、リ゜ヌスの䜿甚量が少ないこずが想定されたすが、初期化凊理によっおはリ゜ヌスが激しく消費され、远加のリ゜ヌスが必芁、ず刀断されおしたう可胜性がありたす。 なお、2 ぀の耇雑さを説明したしたが、倚くの堎合 1 ぀目の耇雑さ、぀たり Blue/Green 䞭のリ゜ヌス数の䞀時的な増加による、本来より小さいメトリクスの倀の報告の方が重芁床が高い堎合が倚いです。埌者はスケヌルアりトを招く可胜性がある䞀方、前者であるこれはスケヌルむンを招くこずから、サヌビスの提䟛そのものに圱響を䞎える可胜性があるからです。 ECS Service における Application Auto Scaling ず Blue/Green デプロむメント戊略の詳现 前章では、䞀般的な Blue/Green ず Auto Scaling の䜵甚による耇雑さに぀いお説明したした。 具䜓的なサヌビスや機胜ではこれらの点を郚分的にカバヌしおいる堎合もありたす。ECS で本テヌマに぀いお考える際には、以䞋 5 ぀の点を抌さえる必芁がありたす。 1. デフォルトのメトリクスは Blue 環境ず Green 環境のリ゜ヌスを統合的に扱う ECS のタヌゲット远跡ポリシヌで提䟛するデフォルトのメトリクス蚭定のうち、「ALBRequestCountPerTarget」は珟時点で Blue/Green デプロむに察応しおいたせん。残りの「ECSServiceAverageMemoryUtilization」、「ECSServiceAverageCPUUtilization」は、いずれも ECS Service がディメンションであるメトリクスです。぀たり ECS Service に含たれる、各 ECS Task のリ゜ヌス䜿甚率の平均を元にスケヌルを刀断したす。぀たり、Blue/Green 䞭はタスクが 2 倍になるこずで本来の倀より䜎い倀ずなる可胜性がありたす。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html ブルヌ/グリヌンデプロむタむプでは、タヌゲット远跡スケヌリングポリシヌの ALBRequestCountPerTarget メトリクスはサポヌトされたせん。 2. ECS はデプロむメント䞭はスケヌルむンのみ無効化する ECS Service のデプロむ䞭は、倖郚デプロむコントロヌラヌを䜿甚する堎合を陀き、スケヌルむンのみ無効化されたす。これは Application Auto Scaling による意図しないタスク削陀を防ぐための保護メカニズムで、スケヌルアりトは通垞通り動䜜を継続したす。 察象ずなる ECS Service における Blue/Green の切り替えにかかる時間が非垞に短い堎合、こちらの性質を掻甚するだけで十分な可胜性もありたす。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-auto-scaling.html#service-auto-scaling-deployments Application Auto Scaling は、 Amazon ECS デプロむの進行䞭 にスケヌルむンプロセスをオフにしたす。ただし、スケヌルアりトプロセスは、䞭断しない限り、デプロむ䞭に匕き続き発生したす。 泚意点ずしお、デプロむが終了した時点からスケヌルむンのプロセスも有効になりたす。スケヌルむン実斜刀断に䜿甚されるメトリクスは Blue/Green 䞭に出力されたメトリクスを含むため、厳密にはデプロむ完了盎埌においお本来必芁のないスケヌルむンが発生するリスクが存圚したす。こちらは 4 で解説したす。 3. ロヌルバック機胜 Blue/Green デプロむメントではロヌルバックの機胜がありたすが、これはデプロむメントプロセス䞭の䞭で行われたす。したがっおロヌルバックが終了するたでがデプロむメントの範囲ずなるため、スケヌルむンは無効化されたす。 そのため、ロヌルバックの発生に関しお特別な蚭定は必芁ありたせん。しかし、ロヌルバックを遞択する際は、通垞のデプロむが意図通り成功しなかったず蚀うこずであり、デプロむにかかっおいる時間が増加しおいる可胜性がありたす。そういった堎合に意図せずスケヌルむンされないかに぀いおは確認する必芁がありたす。 4. タヌゲット远跡スケヌリングの参照範囲ずデプロむ時間の関係 ECS のタヌゲット远跡ポリシヌで提䟛するデフォルトのメトリック蚭定を適甚した堎合、スケヌルアりト方向には過去3デヌタポむント3分間のメトリックが、スケヌルむン方向には過去15デヌタポむント15分間のメトリックを察象に基準倀ずの盞違点や距離を刀定したす。 Blue/Green によるデプロむ時間が短い堎合は問題ないず考えられる䞀方、15分以䞊デプロむに時間がかかる堎合、本来より䜎いメトリックの倀が15分以䞊蚘録されるこずになりたす。 2. で述べたずおり ECS ではデプロむ䞭のスケヌルむンは無効化されおいるものの、デプロむ明け盎埌にはスケヌルむンが可胜ずなるため、デプロむ明け盎埌にスケヌルむンが走るリスクがある堎合は、ポリシヌを芋盎す必芁があるでしょう。 5. ECS で掚奚されるナヌザヌのカスタマむズ範囲 以䞋の通り、ECS Service に察しお Auto Scaling を蚭定する際は、事前定矩された蚭定を利甚する、もしくは Auto Scaling でカスタムのメトリクスを利甚する方法の 2 皮類になりたす。   この際、以䞋の通り自動で䜜成される Amazon CloudWatch Alarm の蚭定の倉曎に぀いおは掚奚されおいたせん。぀たり、アラヌムの発火に䜿甚するデヌタポむント数の蚭定などの倉曎が珟状は非掚奚であるため、スケヌルむンに䜿甚されるデヌタポむントの期間の範囲が15分であるこずの倉曎等は珟時点では難しい、ずいった状況に泚意する必芁がありたす。なお、ステップスケヌリングではデヌタポむントの数の倉曎に぀いおは明蚘されおいたせんので泚意しおください。 タヌゲットメトリクスを䜿甚しお Amazon ECS サヌビスをスケヌルする https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html タヌゲット远跡スケヌリングポリシヌのためにサヌビスの自動スケヌリングが管理する CloudWatch アラヌムを線集たたは削陀しないでください。スケヌリングポリシヌを削陀するずきに、サヌビスの自動スケヌリングはアラヌムを自動的に削陀したす。 ECS Service における Application Auto Scaling ず Blue/Green デプロむメント戊略の䜵甚の䟋 ここたでの内容を螏たえるず、たずは ECS のデフォルトの仕組みで十分察応可胜であるかどうかに぀いお怜蚎する必芁がありたす。倱敗時のケヌス等を含め、デプロむ時間が十分に短い等、リスクを蚱容し䜵甚するずいった意思決定もありうるず思いたす。 スケヌルむン等のリスクが蚱容できない堎合、Green リ゜ヌスの远加による䞀時的なリ゜ヌスの増加に察応する必芁がありたす。ここからは特にスケヌルむンのリスクに察する察応の䟋を3぀瀺したす。これらの䟋で察応可胜な堎合は䜵甚を採甚し、それでも芁件䞊難しい堎合は䜵甚しないずいった意思決定をずるこずになりたす。 なお、以䞋説明で頻出する、ECS Service におけるカスタムのメトリクスやアラヌムを蚭定する具䜓的な方法に぀いおは以䞋のブログを参考ください。 カスタムメトリクスに基づいた Application Auto Scaling による Amazon ECS サヌビスのオヌトスケヌル | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/autoscaling-amazon-ecs-services-based-on-custom-metrics-with-application-auto-scaling/ パタヌン1: 「本来のタスク数をベヌスずしたリ゜ヌス䜿甚率を算出するカスタム蚭定されたアラヌム」を䜿甚するタヌゲット远跡スケヌリングポリシヌを蚭定する この方法は、スケヌルむンの懞念に察する察応ずしお有効です。 ECS のメトリクスでは、Blue/Green 䞭も倀が倉化しないメトリクスずしお、DesiredTaskCount が利甚可胜です。そのため、䟋えば Container Insights のメトリクスを利甚し、以䞋のような匏に察しおアラヌムを蚭定するこずで、本来のタスク数を分母ずした CPU 䜿甚率に近い倀を導出するこずができたす。 匏 CPUUtilization * RunningTaskCount / DesiredTaskCount 各メトリクスの説明 DesiredTaskCount: ECS Service で蚭定した必芁なタスクの数 RunningTaskCount: 珟圚 RUNNING 状態にあるタスクの数 CPUUtilization サヌビスに属するタスクで䜿甚されおいる CPU ナニットの総数を、サヌビスに属するタスク甚に予玄されおいる CPU ナニットの総数で割った倀 パタヌン2: 「バック゚ンド ECS Task に䟝存しないカスタムメトリクスを掻甚するカスタムアラヌム」を䜿甚するタヌゲット远跡スケヌリングポリシヌを蚭定する ECS Task の前段に配眮される ALB の TargetResponseTime や NewConnectionCount などのメトリクスは、Blue/Green 䞭もリ゜ヌスの状態が倉化したせん。そのため、実際のリ゜ヌス䜿甚状況ではなく間接的な倀ずなるものの、これらを利甚するこずで この方法は、 ECS Task の状態に䟝存しないため、スケヌルむン方向、スケヌルアりト方向いずれの方向においおも䞀貫した倀をベヌスにBlue/Green 䞭もスケヌルを刀断するこずができたす。 匏 TargetResponseTime NewConnectionCount パタヌン3: ECS Service に察しお耇数のタヌゲット远跡スケヌリングポリシヌを蚭定する ECS では䞀぀の ECS Service に察しお耇数のタヌゲット远跡スケヌリングポリシヌを蚭定できたす。この堎合、スケヌルアりト方向にはいずれか 1 ぀のメトリックが閟倀を超えれば良いのに察し、スケヌルむンでは党おのメトリックが条件を満たす必芁がありたす。 タヌゲットメトリクスを䜿甚しお Amazon ECS サヌビスをスケヌルする – Amazon Elastic Container Service https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html Amazon ECS サヌビスに察しお耇数のタヌゲット远跡スケヌリングポリシヌを蚭定できたす。ただし、各ポリシヌがそれぞれ異なるメトリクスを䜿甚しおいる必芁がありたす。サヌビスの自動スケヌリングの目的は垞に可甚性を優先するこずであるため、その動䜜は、スケヌルアりトたたはスケヌルむンに察するタヌゲット远跡ポリシヌの準備が敎っおいるかどうかに応じお異なりたす。タヌゲット远跡ポリシヌのいずれかでスケヌルアりトする準備ができるず、サヌビスがスケヌルアりトされたすが、すべおのタヌゲット远跡ポリシヌ (スケヌルむン郚分がオン) でスケヌルむンする準備ができおいる堎合にのみスケヌルむンされたす。 埓っお、珟圚蚭定しおいるポリシヌに远加で、Blue/Green 䞭に発火しにくい、䜎い倀のタヌゲット远跡スケヌリングポリシヌを蚭定するこずで、スケヌルアりト方向にはこれたでず同じ速床である䞀方、スケヌルむンに぀いおはより緩やかな実斜を実珟するこずが可胜です。この方法はこれたでのパタヌンず䜵甚するこずが可胜です。 たずめ 本蚘事では、ECS built-in Blue/Green デプロむメントずApplication Auto Scaling の効果的な䜵甚方法に぀いお包括的に解説したした。埓来の運甚では、Auto Scaling ず Blue/Green の䜵甚時に発生する技術的課題を回避するため、デプロむ䞭の Auto Scaling 停止ずいう察凊法が䞀般的でしたが、これによりトラフィック増加ぞの察応䞍可、デプロむ頻床の制限、運甚工数の増加ずいった新たな課題が生じおいたした。 本蚘事では、サヌビスによっおは既存の ECS の仕組みに任せたり、カスタムのメトリクスを蚭定するこずで Auto Scaling ず ECS Blue/Green デプロむを蚭定倉曎せず䜵甚する䜙地があるこずを瀺したした。たた、その背景ずなる Auto Scaling ず Blue/Green デプロむの盞互䜜甚の仕組みを明らかにし、ナヌザヌのより高床な掻甚の基瀎ずなる芁玠を瀺すこずができたず考えおいたす。 ECS built-in Blue/Green デプロむメントず Auto Scaling の組み合わせは、珟代のクラりドネむティブアプリケヌション運甚においお、可甚性、効率性、アゞリティのすべおを同時に向䞊させる匷力な゜リュヌションです。ビゞネスやサヌビスの芁件に応じお適切な遞択をする際に、本蚘事がその䞀助ずなれば幞いです。
ニフティ株匏䌚瀟では、ネットワヌクサヌビス事業ず 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 の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。今幎はコロコロを続けたいず思いたす。