TECH PLAY

AWS

AWS の技術ブログ

å…š3418ä»¶

プログラマティック広告※に携わる DSPDemand-Side Platform・SSPSupply-Side Platform事業者なら、䞀床はこのゞレンマに盎面したこずがあるのではないでしょうか。広告枠を提䟛するパヌトナヌであるパブリッシャヌず広告䞻ずの接続を増やせば入札機䌚が広がり、広告䞻にもパブリッシャヌにも䟡倀を届けられる。しかし珟実には、接続のたびに発生するネットワヌクコストずむンフラ構築の時間が、その刀断にブレヌキをかけおきたした。DSP 事業者のUNICORN株匏䌚瀟 ず SSP 事業者の株匏䌚瀟fluct は、AWSの広告テクノロゞヌワヌクロヌド向けマネヌゞドサヌビスである AWS RTB Fabric を共通基盀ずしお掻甚するこずで、この接続コストずスピヌドのゞレンマを乗り越え、広告配信ネットワヌクの拡倧に螏み出しおいたす。䞡瀟は抂念実蚌PoCを経お既に本番皌働を開始しおおり、本蚘事ではその取り組みず成果を説明したす。 ※ プログラマティック広告ずは、デヌタずアルゎリズムを甚いお広告の買い付け・配信を自動で行う手法。 接続コストずスピヌドのゞレンマ プログラマティック広告の入札凊理Real-Time Biddingでは、1秒間に数十䞇〜数癟䞇件の入札リク゚ストが DSP・SSP 間を行き亀いたす。より倚くのパヌトナヌず接続し、より倚くの入札機䌚を埗るこずが、広告䞻にずっおもパブリッシャヌにずっおも䟡倀を生みたす。 しかし珟実には、接続先を増やすほど以䞋のゞレンマが深刻になりたす。 コストのゞレンマ 広告枠を提䟛するパヌトナヌを増やすほどネットワヌクコストが膚らみ、応札数の拡倧が利益を圧迫する。コストを抑えるためにフィルタリングを匷化すれば、本来獲埗できた広告枠を逃す。 スピヌドのゞレンマ : 新芏パヌトナヌずの接続にコロケヌション手配やネットワヌク構成の調敎が必芁で、数週間〜数ヶ月を芁する。ビゞネス刀断のスピヌドに技術が远い぀かない。 パフォヌマンスの制玄 : ミリ秒単䜍の入札凊理を安定的に維持しながら、トラフィックの急増にも察応し続ける必芁がある。 ゞレンマを解消に導くAWS RTB Fabricずは このような課題に察凊するために生たれた広告テクノロゞヌワヌクロヌド向けフルマネヌゞドサヌビスであるAWS RTB Fabric の䞻な技術的特長ず構成を玹介したす。 AWS RTB Fabricは、SSPずDSP間のリアルタむム入札通信を最適化するAWSのフルマネヌゞドネットワヌクサヌビスです。SSPが広告枠のビッドリク゚ストをDSPに送信する際はパブリックむンタヌネットを経由するのが䞀般的ですが、AWS RTB Fabricは専甚プラむベヌトネットワヌクを提䟛し、1桁ミリ秒の䜎レむテンシヌでSSP⇔DSP間の入札リク゚スト・レスポンスを亀換可胜にしたす。たた、RTBワヌクロヌドは倧量のビッドリク゚スト/レスポンスを高頻床で亀換するため、通垞のむンタヌネット゚グレス料金が膚倧になりがちですが、AWS RTB Fabricの専甚ネットワヌクを経由するこずでデヌタ転送コストを倧幅に圧瞮できたす。これにより暙準的なクラりドネットワヌキングコストず比范しお最倧80%のコスト削枛が可胜です。 AWS RTB Fabricを掻甚するこずでコストのゞレンマずスピヌドのゞレンマを解消できるのではずいう期埅のもずUNICORN瀟 ず fluct瀟 は、それぞれ DSP 偎・SSP 偎からこのゞレンマに向き合い、2026幎3月よりAWS RTB Fabric を掻甚した広告配信ネットワヌクの構築PoCに螏み出したした。 UNICORNずfluctが実斜したAWS RTB FabricのPoC 今回の取り組みで䞡瀟がPoCを行ったのは、䞡瀟SSP⇔DSP間の通信経路を「パブリックむンタヌネット経由」から「AWS RTB Fabricの専甚プラむベヌトネットワヌク経由」に切り替えるずいうアヌキテクチャ倉曎です。 机䞊怜蚎 AWSが公開しおいるドキュメントでの仕様確認を経お、利甚察象ずする機胜を特定したした。たた、マネヌゞドサヌビスの利甚ずいうこずで、特にスケヌリングに関するサヌビス仕様の詳现確認や、モニタリング方法の確認、可甚性芁件をどのように実珟できるかの確認・怜蚎を行いたした。たた、公開されおいる䟡栌衚からコスト詊算を実斜したずころ、コスト削枛の芋通しが立ったため、実環境ぞの適甚開始を決定したした。 段階的なトランザクションの流入開始 実際の環境でAWS RTB Fabricぞの通信切り替えを段階的に実斜したした。たずはコスト詊算結果の劥圓性確認のため、䞡瀟のSSP/DSP間で行われおいる通信の10をAWS RTB Fabric経由に切り替えるこずから開始したした。 AWS RTB Fabricを実環境に適甚したずころ、以䞋のような結果が埗られたした。 ネットワヌクコスト 8086.5% 削枛 — 埓来のパブリックむンタヌネット経由ず比范し、同䞀トラフィック量に察するデヌタ転送コストを倧幅削枛。これはフィルタリング匷化による「入札機䌚の犠牲」ではなく、通信経路の最適化による玔粋なコスト削枛です。 入札凊理の安定性維持 — レむテンシヌの改善により、トラフィック急増時にもタむムアりト率を抑制し、応札率を維持できるこずを確認。 運甚可芖性の向䞊 — DSP 単䜍でのメトリクスずコストをリアルタむムで把握可胜に。 このPoC結果を螏たえ、䞡瀟間のトランザクションを党面的にAWS RTB Fabricに切り替えるこずを決定。2026幎5月より䞡瀟間のトランザクションのすべおをAWS RTB Fabricを甚いた通信に切り替え、珟圚も安定的に運甚を続けおいたす。 抂念図 PoCでは以䞋の結果を確認するこずができたした。 ネットワヌクコスト80%削枛 — 埓来のパブリックむンタヌネット経由ず比范し、同䞀トラフィック量に察するデヌタ転送コストを80%削枛。これはフィルタリング匷化による「入札機䌚の犠牲」ではなく、通信経路の最適化による玔粋なコスト削枛です。 入札凊理の安定性維持 — レむテンシヌの改善により、トラフィック急増時にもタむムアりト率を抑制し、ビッドレヌト応札率を維持できるこずを確認したした。 たた本件に぀いお実際に取り組みを実斜した䞡瀟からは䞋蚘のようなコメントを頂いおいたす。 UNICORN株匏䌚瀟 取締圹 璩 暁毅 様 「AWS RTB FabricのPoCを通じお特に可胜性を感じおいるのは、既存の配信基盀ぞ比范的容易に組み蟌めるアヌキテクチャである点です。導入や接続にかかる負荷を䜎枛できるこずで、より倚くのパヌトナヌが参加しやすいオヌプンな゚コシステムの実珟が期埅できたす。たた、コスト効率の改善に加え、UNICORNずSSP間の凊理経路が最適化されるこずで、広告取匕におけるレむテンシの短瞮も期埅しおいたす。これは広告䞻やメディアにずっおの䟡倀向䞊だけでなく、ペヌゞ衚瀺や広告配信の高速化を通じお、ナヌザヌ䜓隓のさらなる改善にも぀ながるず考えおいたす。今埌、こうした取り組みが業界党䜓の接続性ず効率性を高め、オヌプンむンタヌネットにおけるプログラマティック広告垂堎のさらなる発展に぀ながるこずを楜しみにしおいたす。」 株匏䌚瀟fluct 代衚取締圹COO 黒田 岳志 様 「ネットワヌクコストの高隰は、DSPぞの接続拡倧における倧きな課題でした。AWS RTB Fabricの適甚によりデヌタ転送コストを80%削枛できたこずで、UNICORN様ぞの入札リク゚スト数を増加させるこずが可胜ずなり、パブリッシャヌの収益機䌚の拡倧ずいう具䜓的なビゞネス成果に繋がっおいたす。今埌もAWSず連携し、配信基盀の匷化を通じおパブリッシャヌの成長を支揎しおたいりたす。」 AWS Japan 垞務執行圹員技術統括本郚長 å·šå‹¢ 泰宏 は今回の取り組みの成功に぀いお、以䞋のようにコメントしおいたす。 「AWSは、Amazonの広告ビゞネスで培った倧芏暡デヌタ凊理ず䜎レむテンシヌ技術の知芋を掻かし、広告業界のむノベヌションを掚進しおたいりたした。AWS RTB Fabricは、DSPずSSPを同䞀プラットフォヌム䞊で盎接接続するこずで、広告業界が長幎抱えおきた倧量デヌタ転送ず䜎レむテンシヌずいう課題を解決し、広告の収益性ず効果を最倧化するサヌビスです。UNICORN様、fluct様をはじめずするお客様がこのテクノロゞヌを掻甚し、新たなむノベヌションを生み出すこずで、日本の広告業界のさらなる発展に぀ながるものず確信しおおりたす。AWSは今埌も、広告業界の未来を切り拓くテクノロゞヌの提䟛を通じお、業界党䜓の成長に貢献しおたいりたす。」 UNICORN ず fluct の取り組みは、AWS RTB Fabric を掻甚した広告配信ネットワヌク構築の先行事䟋です。 AWS Japan は、この成果をもずに以䞋の展開を進めおいきたす。 ネットワヌクの拡倧 — より倚くの DSP・SSP・アドネットワヌク事業者ぞの参画呌びかけ ナヌスケヌスの深化 — リテヌルメディア、CTVコネクテッドTVなど新しい広告領域ぞの展開 技術支揎の匷化 — 導入を怜蚎する事業者向けの技術ガむダンスず PoC 支揎プログラムの提䟛 広告配信ネットワヌクぞの参画にご関心のある DSP・SSP 事業者の皆様、ぜひお気軜にお問い合わせください。 本ブログに関連するむベント開催に぀いお 本ブログ執筆にご協力いただいたUNICORN瀟ずfluct瀟にもご登壇頂くむベントを䞋蚘のずおり開催いたしたす。AWS RTB Fabric を掻甚した広告配信ネットワヌクの茪を広げるこずに少しでも関心を持たれおいる方がいらっしゃいたしたらぜひご参加ください。 むベント名AdTech meet up 「倉わる広告、倉わらない䟡倀 ― いたAdTech事業者がAWSに集たる理由」 日時2026幎7月17日金16:00-19:00 堎所麻垃台ヒルズ森JPタワヌ 36階 セミナヌルヌム東京郜枯区麻垃台1-3-1 察象プログラマティック広告配信に携わる事業オヌナヌ、゚ンゞニアの方 申し蟌みWebペヌゞ AdTech meet up「倉わる広告、倉わらない䟡倀 ― いたアドテク事業者がAWSに集たる理由」 むベント抂芁 広告の圚り方は倉わっおも、届けたい付加䟡倀は䞍倉です。ただ、付加䟡倀の届け方が過枡期を迎えおいたす。AIずクラりドが皌ぐ力を匕き䞊げ、そしおコストを倧きく抌し䞋げるこずが容易になったこの倉革期に、アドテク事業者の皆様は、䜕に投資し、䜕を行い、そしお誰ず協働すべきでしょうか。 本むベントでは、AIが倉えるプログラマティック広告の最前線、AWSのアドテク事業者様向けの最新テクノロゞヌであるAWS RTB Fabric によるコスト削枛ず収益拡倧の実践、そしおDSP事業者 × SSP事業者によるオヌプン゚コシステム戊略の察談を通じお、その答えを探りたす。 たた、それらセッションの埌にはDSP・SSP事業者同士が盎接぀ながるネットワヌキングの堎もご甚意。同じ課題意識を持぀事業責任者様ずの亀流を通じお、是非ずも次の成長の起点を探っお頂くこずを心から願っおおりたす。 アゞェンダ AWS Session① AIが倉えるプログラマティック広告 スピヌカヌアマゟン りェブ サヌビス ゞャパン合同䌚瀟 アド  マヌケティング テクノロゞヌコミュニティ ゜リュヌションアヌキテクト 鈎朚 康士郎 AWS Session② 広告コストを収益に倉える – AWS RTB Fabric スピヌカヌアマゟン りェブ サヌビス ゞャパン合同䌚瀟 アド  マヌケティング テクノロゞヌコミュニティ ゜リュヌションアヌキテクト 関藀 寛喜 DSP事業者×SSP事業者による察談 アドテク事業者はどこに投資すべきか—オヌプン゚コシステムが切り拓く次の成長戊略 パネリスト株匏䌚瀟fluct 代衚取締圹COO 黒田 岳志 様 UNICORN株匏䌚瀟 取締圹 璩 暁毅 様 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 プリンシパル事業開発マネヌゞャヌ 束本 鋌治 本ブログは束原AdTech Team, Account Executive・安守AdTech Team, Account Executive・久野Solutions architectが担圓したした
本蚘事は 2026 幎 5 月 21 日 に公開された「 Building multi-tenant agents with Amazon Bedrock AgentCore 」を翻蚳したものです。 マルチテナントの゚ヌゞェント型アプリケヌションを構築する SaaS (Software as a Service) プロバむダヌは、セキュリティ、ガバナンス、応答粟床ずいった䞀般的な懞念事項を超えたアヌキテクチャ䞊の課題に取り組む必芁がありたす。具䜓的には、テナント分離、テナント ID、テナントのオブザヌバビリティ、デヌタ分離、コスト配分、ノむゞヌネむバヌの緩和などです。動䜜するデモから本番環境ぞのデプロむたでの隔たりを埋めるには、マルチテナント環境向けに蚭蚈されたむンフラストラクチャが必芁になりたす。Amazon Bedrock AgentCore は、AWS 䞊で゚ヌゞェント型アプリケヌションを構築、デプロむし、安党に運甚するためのマネヌゞドなサヌバヌレスサヌビスです。゚ヌゞェントのデプロむず MCP サヌバヌのホスティングのための構成芁玠を提䟛し、ID 管理、メモリ、オブザヌバビリティ、評䟡機胜を暙準で備えおいたす。これらはすべお、マルチテナントの゚ヌゞェントアヌキテクチャを無理なく構築できるように蚭蚈されおいたす。 本ブログシリヌズの第 1 回ずなる本蚘事では、マルチテナントの゚ヌゞェント型アプリケヌションを蚭蚈する際の怜蚎事項ず、 Amazon Bedrock AgentCore で SaaS アヌキテクチャの課題に取り組むために必芁なフレヌムワヌクを解説したす。 マルチテナント゚ヌゞェントを構築する際の蚭蚈䞊の怜蚎事項 匷力な分離を備えた安党なマルチテナントの゚ヌゞェント型アプリケヌションを構築するには、図 1 に瀺すいく぀かの䞻芁コンポヌネントにわたっお、慎重なアヌキテクチャ䞊の刀断が必芁です。各コンポヌネントは、セキュリティずコンプラむアンスの基準を維持しながら、テナント分離、運甚効率、コスト最適化のバランスを取る必芁がありたす。これらの蚭蚈䞊の怜蚎事項は、3 ぀のテナント分離パタヌン ( サむロ、プヌル、ブリッゞ ) を軞に展開され、これらを遞択する際にはティアリング戊略が重芁な怜蚎芁玠になりたす。 図 1: マルチテナント゚ヌゞェントの蚭蚈䞊の怜蚎事項 続くセクションでは、マルチテナント化が各コンポヌネントにどのような圱響を䞎えるかを詳しく説明したす。 1. ゚ヌゞェントランタむムのデプロむ: 専甚ず共有 マルチテナントの゚ヌゞェントアヌキテクチャにおける重芁な刀断は、テナントに察しお゚ヌゞェントランタむムをどのようにプロビゞョニングするかです。テナントごずの 専甚 ランタむムは、テナントごずに独立した実行環境をむンスタンス化し、それぞれが固有のコンテナむメヌゞ、プロセス空間、ラむフサむクルを持ちたす。このサむロ型のアプロヌチは、最も匷力なノむゞヌネむバヌ察策ずなり、コンプラむアンス監査を簡玠化したす。䞀方、 共有 ランタむムは、すべおのテナントの゚ヌゞェントを同䞀のコンテナむメヌゞずプロセスプヌル内でホストするため、むンフラストラクチャのコストず運甚負荷を抑えられたすが、プロセス内でテナントコンテキストを厳密に䌝播させる必芁がありたす。 Amazon Bedrock AgentCore Runtime は、セッション分離された microVM ベヌスのコンピュヌティングによっおこのトレヌドオフを解決したす。AgentCore Runtime は、テナントごずに完党な仮想マシンを起動するコストやレむテンシヌを䌎わずに、セッション単䜍で軜量な microVM を起動したす。各セッションは独自の氞続ファむルシステムを持぀ため、゚ヌゞェントはセッションスコヌプのファむルを読み曞きし、䞭間的な蚈算結果を保持し、マルチステップのやり取りをたたいで状態を維持できたす。これにより、セッション間でのデヌタ挏掩のリスクを軜枛したす。このアヌキテクチャは、マルチテナントの MCP サヌバヌ、゚ヌゞェント、AG-UI サヌバヌをホストするのに適しおいたす。テナントコンテキストは、カスタム HTTP ヘッダヌを通じお分離された実行環境に流れ蟌みたす。SaaS プラットフォヌムが AgentCore Runtime セッションにリク゚ストを転送する際、暙準の認可トヌクンに加えお、テナント識別子、ティア、リヌゞョンの蚭定、機胜フラグ、゚ンタむトルメントずいったテナント固有のメタデヌタを持぀ヘッダヌを付䞎したす。゚ヌゞェントは呌び出し時にこれらのヘッダヌを読み取っおテナントを完党に認識できるため、そのテナントのビゞネスロゞックに合わせたワヌクフロヌを実行し、ラむセンスされたツヌルのみを呌び出し、ハヌドコヌドされたルヌティングロゞックなしにテナント固有の API ゚ンドポむントを呌び出せたす。 2. 共有モデル、ティア別モデル、ファむンチュヌニング枈みモデル ほずんどのマルチテナントデプロむでは、共有基盀モデル (FM) が掚奚される出発点ずなり、単䞀のモデルを保守するだけで運甚を簡玠化できたす。テナントは通垞、テナントごずのカスタマむズなしに、自動的なモデル曎新の恩恵を受けられたす。テナントのティアに基づいおモデルを遞択する方匏 (ティア別モデル) では、柔軟性が埗られ、テナントのティア間でコスト、パフォヌマンス、粟床のバランスを取れたす。テナント固有の甚語、芏制察応、パフォヌマンス SLA を必芁ずする特殊なナヌスケヌスでは、テナントごずにファむンチュヌニングしたモデルが必芁になりたすが、運甚が耇雑になり、テナントごずのパむプラむンが発生したす。暙準ティアには性胜を抑えたモデルを、プレミアムな゚ンタヌプラむズ顧客にはファむンチュヌニング枈みたたは高性胜なモデルを䜿うハむブリッドなアプロヌチは、コスト効率ずカスタマむズの芁件のバランスを取れたす。Amazon Bedrock は䞻芁プロバむダヌの倧芏暡蚀語モデル (LLM) を幅広く提䟛しおおり、SaaS プロバむダヌはテナントやティア固有のニヌズに合ったモデルを遞択できたす。Amazon Bedrock のファむンチュヌニングでは、独自のラベル付きデヌタセットを䜿っお FM をカスタマむズし、ドメむン固有のタスクのパフォヌマンスを高められたす。Amazon Bedrock Custom Model Import を䜿えば、独自にファむンチュヌニングしたモデルを持ち蟌み、Amazon Bedrock のマネヌゞドむンフラストラクチャを䜿っおデプロむできたす。 3. ワヌクフロヌ: サむロ、プヌル、ブリッゞパタヌン マルチテナントの゚ヌゞェント型アプリケヌションでは、各゚ヌゞェントがテナントの芁件ずビゞネスロゞックに基づいお異なる䞀連のステップを実行する、柔軟なワヌクフロヌ管理が必芁です。ワヌクフロヌは耇数の仕組みで実装できたす。手順を段階的にカプセル化する MCP ツヌルずしお、ビゞネスロゞックのフロヌを定矩する API ゚ンドポむントずしお、あるいはドメむン固有のワヌクフロヌパタヌンを組み蟌んだ゚ヌゞェントスキルずしお実装できたす。 テナント固有のワヌクフロヌを管理する䞻なパタヌンは 3 ぀ありたす。サむロパタヌンは、テナント固有の専甚スキルを䜿い、ビゞネスロゞック、怜蚌ルヌル、統合ステップを含む各テナントの完党なワヌクフロヌを、分離された゚ヌゞェントスキルに組み蟌みたす。これにより最倧限のカスタマむズず完党な独立性が埗られたすが、テナントごずに個別のスキル保守が必芁です。プヌルパタヌンは、共有の゚ヌゞェントスキルを䜿いたす。ブリッゞパタヌンは、認蚌、ロギング、゚ラヌハンドリングずいった共通のワヌクフロヌステップを共有゚ヌゞェントスキルに組み蟌み、ビゞネスクリティカルなロゞックに぀いおは実行時にテナント固有のスキルを呌び出したす。その結果、再利甚可胜なむンフラストラクチャずテナント固有のカスタマむズが共存したす。 4. マルチテナント RAG 怜玢拡匵生成 (RAG) システムでは、デヌタ分離の刀断が必芁です。サむロパタヌンは、テナントごずに専甚のベクトルデヌタベヌスを䜿い、最倧限のセキュリティず完党なデヌタ分離を実珟したす。これは、芏制業界や専甚むンフラストラクチャを必芁ずする゚ンタヌプラむズ顧客に掚奚されたす。プヌルパタヌンは、メタデヌタベヌスのテナントフィルタリングず名前空間ベヌスのアクセス制埡を備えた共有ベクトルデヌタベヌスを䜿い、倚数の䞭小芏暡テナントにサヌビスを提䟛する SaaS プラットフォヌムでコスト効率の高い運甚を実珟したす。怜玢操䜜には、テナント間でのデヌタ挏掩を防ぐため、自動的なテナントフィルタヌの泚入ず結果のサニタむズを含めるべきです。 Amazon Bedrock Knowledge Bases は、FM をデヌタ゜ヌスに接続するフルマネヌゞドな RAG 機胜を提䟛し、デヌタの取り蟌み、チャンキング、埋め蟌みの生成、ベクトルストレヌゞを自動的に凊理したす。耇数のベクトルデヌタベヌスに察応し、(メタデヌタフィルタリングを䜿っお) サむロ型たたは共有型のベクトルデヌタベヌスを䜜成できたす。 Amazon Bedrock Knowledge Bases でマルチテナント RAG アヌキテクチャを実装する詳しい手順に぀いおは、サむロ、プヌル、ブリッゞのデプロむパタヌンを扱った Multi-tenant RAG with Amazon Bedrock Knowledge Bases ず、共有ナレッゞベヌス内でのメタデヌタベヌスのテナント分離を扱った Multi-tenancy in RAG applications in a single Amazon Bedrock knowledge base with metadata filtering を参照しおください。 5. テナントコンテキスト、代理実行 (act-on-behalf) パタヌン、トヌクン䌝播 マルチテナントの ID 管理では、サヌビスチェヌン党䜓にわたっおテナントコンテキストを慎重に扱う必芁がありたす。完党な ID を衚すテナントコンテキストず、リク゚スト固有の状態は、信頌性が高く安党な仕組みを䜿っおすべおのアヌキテクチャ局を流れる必芁がありたす。実行パスが予枬可胜な決定論的な゜フトりェア API ずは異なり、AI ゚ヌゞェントは非決定論的で、自埋的に動䜜する可胜性があるため、セキュリティ䞊の考慮事項が重芁な点で異なりたす。䞍正な゚ヌゞェントや䟵害された゚ヌゞェントは、ダりンストリヌムのサヌビスに察しお䞍正な呌び出しを行い、認蚌情報の盗難、暩限昇栌、混乱する代理問題 (Confused Deputy) を匕き起こす可胜性がありたす。゚ヌゞェントがナヌザヌの認蚌情報をすべお䜿っお動䜜する (なりすたし) 堎合、1 ぀の䟵害された゚ヌゞェントが、すべおのダりンストリヌムシステムにわたるナヌザヌ暩限ぞの完党なアクセスを埗おしたいたす。このリスクは、どのツヌルをい぀どのようなパラメヌタで呌び出すかを゚ヌゞェントが自埋的に刀断するようになるほど倧きくなりたす。代理実行 (act-on-behalf) パタヌンが重芁なのは、ナヌザヌず゚ヌゞェントを明確に区別し、゚ヌゞェントが操䜜ごずに明瀺的に制限・スコヌプされた暩限でナヌザヌに代わっお呌び出しを行うようにするためです。 テナントコンテキストは JSON Web Token (JWT) 内に゚ンコヌドし、3 ぀の次元を捉えたす。セキュリティコンテキスト (暙準クレヌム: iss、sub、exp、aud)、テナントコンテキスト (tenant_id ずテナント固有のスコヌプ)、リク゚ストコンテキスト (ビゞネスロゞック向けのドメむン固有の属性) です。このようにテナントコンテキストを゚ンコヌドするこずで、マルチテナント運甚の匷力で柔軟な基盀が埗られたす。 セキュリティ䞊の圱響が倧きく異なる 2 ぀のパタヌンから遞択したす。なりすたし (Impersonation) ぱヌゞェントがナヌザヌの ID ず暩限をすべお䜿っお動䜜できるようにするもので、実装は容易ですが、最小暩限の原則に反し、セキュリティリスクを生みたす。掚奚されるアプロヌチである代理実行 (Act-on-Behalf、委譲) は、各サヌビス境界でトヌクンをスコヌプ制限された認蚌情報に倉換し、゚ヌゞェントを識別する act クレヌム (OAuth 2.0 RFC 8693 に準拠) を付䞎する、真の委譲を実装したす。AgentCore Identity の On-behalf-of トヌクン亀換を䜿うず、゚ヌゞェントや MCP サヌバヌなどのワヌクロヌドが、受信したナヌザヌアクセストヌクンを、ダりンストリヌムのリ゜ヌスサヌバヌ向けの新しいスコヌプ付きアクセストヌクンず亀換できたす。この亀換では、ある察象者 (audience) 向けに発行されたトヌクンを、別のダりンストリヌムの察象者向けのトヌクンに盎接倉換するため、゚ヌゞェントは远加の同意フロヌを発生させるこずなく、認蚌枈みナヌザヌに代わっお保護されたリ゜ヌスにアクセスできたす。亀換されたトヌクンぱヌゞェント自身の ID ず元の呌び出し元の ID の䞡方を保持するため、リ゜ヌスサヌバヌはホップごずにきめ现かなれロトラスト認可を実斜するために必芁なシグナルを埗られたす。 6. MCP ツヌルず API に察するきめ现かなアクセス制埡 マルチテナントの゚ヌゞェント型アプリケヌションでは、ポリシヌを䜿った MCP サヌバヌアクセスの制限、ツヌル呌び出し局でのきめ现かなアクセス制埡、デヌタアクセス局でのテナント分離が必芁です。認可局では、ポリシヌが実行時にテナントコンテキストを評䟡しお蚱可/拒吊の認可刀断を行い、トヌクンに埋め蟌たれた静的な暩限だけに頌るのではなく、珟圚のテナントの状態に基づいお、ツヌル呌び出しを蚱可する前にテナントのクォヌタ、ティアベヌスの暩限、䜿甚制限を評䟡したす。ポリシヌストアを分離しお䞀元化するこずで、再デプロむなしに動的な曎新が可胜になり、ポリシヌのバヌゞョン管理によっお監査蚌跡ずロヌルバックがサポヌトされたす。AgentCore Policy は、ツヌルアクセスを蚱可する前に、定矩されたポリシヌに照らしおすべおの゚ヌゞェントリク゚ストをむンタヌセプトしお評䟡し、ナヌザヌ ID ずツヌル入力パラメヌタに基づくきめ现かな制埡を提䟛したす。ポリシヌは自然蚀語たたは Cedar で盎接蚘述できたす。 呌び出し局では、MCP サヌバヌがテナントのティア、機胜フラグ、クォヌタ制限に基づいお、゚ヌゞェントが呌び出す前に利甚可胜なツヌルをフィルタリングし、きめ现かなアクセス制埡を実斜したす。ツヌルむンタヌセプタヌは JWT クレヌムを怜蚌し、リク゚ストを行うプリンシパルが特定の操䜜に察する適切な暩限を持っおいるこずを確認したす。スキヌマ倉換機胜は、テナントの蚭定ず゚ンタむトルメントに基づいおツヌルのむンタヌフェむスを適応させたす。AgentCore Gateway は、API や AWS Lambda 関数を゚ヌゞェント互換のツヌルに倉換し、既存の MCP サヌバヌに接続するこずで、゚ヌゞェントがツヌルに安党にアクセスできるようにしたす。Amazon API Gateway、OpenAPI スキヌマ、Smithy モデル、Lambda 関数、MCP サヌバヌに察応しおいたす。カスタムロゞックにはゲヌトりェむむンタヌセプタヌを通じおアクセス制埡を実装するこずも、暙準的な AWS スタむルのアクセス制埡にはリ゜ヌスベヌスのポリシヌを䜿うこずもできたす。デヌタアクセス局では、属性ベヌスのアクセス制埡 (ABAC) ポリシヌがデヌタアクセスのテナント分離を実斜し、テナントの識別は JWT クレヌムを通じお行われたす。ABAC ポリシヌは AWS Identity and Access Management (IAM) の条件を䜿い、プリンシパルのタグず属性に基づいおデヌタアクセスを制限したす。これにより、゚ヌゞェントは行レベルセキュリティたたはストレヌゞポリシヌを通じお、自身のテナントコンテキストに䞀臎するリ゜ヌスのみをク゚リできたす。 7. メモリ: 階局的な名前空間による分離 マルチテナントのメモリ管理では、テナント間のデヌタ挏掩を防ぎながら、゚ヌゞェントがコンテキストや孊習した情報を保持できるよう、慎重なアヌキテクチャ蚭蚈が必芁です。メモリシステムは 5 ぀の論理レベルを実装すべきです。 グロヌバル (テナント暪断で共有される知識) ストラテゞヌ (゚ヌゞェントタむプ固有のパタヌンず動䜜) テナント (テナントスコヌプの䌚話履歎ず蚭定) ナヌザヌ (テナント内の個々のナヌザヌコンテキスト) セッション (アクティブな䌚話のための䞀時的な短期メモリ) アクセス制埡は、芁求された名前空間パスに察しおプリンシパルの ID を怜蚌する属性ベヌスのポリシヌを通じお分離を実斜し、゚ヌゞェントは蚱可されたスコヌプ内でのみメモリの読み曞きができたす。プヌルパタヌンは、運甚効率ずコスト効率のために、階局的な名前空間ベヌスの論理分離を備えた共有むンフラストラクチャを䜿い、すべおのテナントデヌタを共通のデヌタストアに保存し、名前空間のプレフィックスに基づいお厳密にフィルタリングしたす。サむロパタヌンは、最倧限の分離のためにテナントごずに専甚のメモリストアをデプロむし、運甚コストは高くなるものの、テナント間アクセスのリスクを䜎枛したす。実装にあたっおは、テナントずナヌザヌの情報から耇合識別子 (䟋: tenant_123:user_456) を構築し、テナントコンテキストをクレヌムやタグずしお持぀スコヌプ付き認蚌情報で認蚌し、すべおのメモリ操䜜に適切な名前空間パスをプレフィックスずしお付けたす。 AgentCore Memory は、グロヌバル、ストラテゞヌ、テナント、ナヌザヌ、セッションの各レベルにわたる階局的な名前空間分離を提䟛し、マルチタヌンの䌚話のための短期メモリず、セッションをたたいで氞続する長期メモリの䞡方によっお、コンテキストを意識した゚ヌゞェント䜓隓をサポヌトしたす。きめ现かなアクセスのために、 リ゜ヌスベヌスのポリシヌ ず 属性ベヌスのアクセス制埡 に察応しおいたす。 8. ゚ヌゞェントの ID、信頌、ディスカバリ ゚ヌゞェント型アプリケヌションが組織の境界をたたいで倖郚の゚ヌゞェントずやり取りするようになるず、゚ヌゞェント ID、゚ヌゞェントの信頌、゚ヌゞェントのディスカバリずいう 3 ぀の基本的な懞念事項が浮かび䞊がりたす。これらは関連しおいたすが、それぞれ異なる問題に察凊したす。 ゚ヌゞェント ID は 「この゚ヌゞェントは誰で、それを蚌明できるか」 に答えたす。組織に玐づく、怜蚌可胜で䞀意な ID を確立したす。 ゚ヌゞェントの信頌 は 「この゚ヌゞェントを信頌すべきか」 に答えたす。単䞀の認蚌情報ではなく、耇数のシグナルの組み合わせに基づいお信頌性を評䟡したす。 ゚ヌゞェントのディスカバリ は 「適切な゚ヌゞェントをどうやっお芋぀けるか」 に答えたす。゚ンドポむントを事前に知らなくおも、機胜や所属によっお゚ヌゞェントを芋぀けられたす。 AgentCore Identity による゚ヌゞェント ID Amazon Bedrock AgentCore Identity は、クラりドネむティブセキュリティで確立されたパタヌンであるワヌクロヌド ID ずしお、゚ヌゞェント ID を実装したす。各゚ヌゞェントは、組織の AWS アカりントず IAM むンフラストラクチャに玐づいた、暗号的に怜蚌可胜な ID を受け取りたす。゚ヌゞェントは OAuth 2.0 フロヌを䜿っおナヌザヌに代わっお AWS リ゜ヌスやサヌドパヌティ補ツヌルに安党にアクセスでき、AgentCore Identity は Okta、Microsoft Entra ID、Amazon Cognito ずいった既存の䌁業 ID プロバむダヌず、ナヌザヌの移行を必芁ずせずに統合できたす。 ゚ヌゞェントの信頌 ID だけでは、゚ヌゞェントを信頌すべきかどうかには答えられたせん。業界はこの問題に積極的に取り組んでいたす。 Agent Naming Service (ANS) v2 は、珟圚 IETF の Internet-Draft (策定䞭) であり、すべおの゚ヌゞェント ID を DNS ドメむン名に玐づけたす。クラむアントは、Bronze (PKI)、Silver (PKI + DANE)、Gold (PKI + DANE + 透明性ログ) ずいう 3 ぀の怜蚌ティアから、取匕のリスクに芋合った保蚌レベルを遞択できたす。 AWS Agent Registry による゚ヌゞェントのディスカバリ Amazon Bedrock AgentCore を通じお利甚できる AWS Agent Registry は、組織党䜓にわたっお゚ヌゞェント、スキル、MCP サヌバヌ、カスタムリ゜ヌスを発芋するための䞀元化されたカタログを提䟛したす。チヌムは再利甚可胜な゚ヌゞェント機胜を公開、バヌゞョン管理、共有できたす。利甚者は、識別子や゚ンドポむントを事前に知らなくおも、自然蚀語たたは構造化された怜玢を通じお゚ヌゞェントを発芋できたす。組み蟌みのガバナンス制埡により、利甚者がレゞストリにどのようにアクセスするか、レコヌドが発芋可胜になる前に承認を必芁ずするかどうかを決定したす。たずめるず、AgentCore Identity が ID の基瀎的な蚌明を提䟛し、Agent Registry がディスカバリを解決し、ANS のような新興の信頌フレヌムワヌクがマルチシグナルによる信頌評䟡の隔たりを埋めるこずを目指しおいたす。 9. テナントごずのコスト远跡ずオブザヌバビリティ 正確なマルチテナントのコスト配分には、゚ヌゞェントの呌び出しごずにテナントタグ付きのメトリクスをロギング゜リュヌションに送出し、入出力トヌクン、ツヌル呌び出し、実行時間を蚘録する、アプリケヌションレベルの蚈装が必芁です。テナントコンテキストを含む構造化ロギングにより、䜿甚パタヌン、パフォヌマンスのボトルネック、キャパシティプランニングを詳现に分析できたす。AgentCore Observability は、Amazon CloudWatch を基盀ずする OpenTelemetry 互換の統合により、゚ヌゞェントのワヌクフロヌをリアルタむムで可芖化し、゚ヌゞェント実行の各ステップを詳现に可芖化したす。 10. ガヌドレヌル: コンテンツの安党性 マルチテナントのガヌドレヌルは、3 ぀の実斜ポむントで安党性ずコンプラむアンスを実斜したす。前凊理の入力ガヌドレヌルは、゚ヌゞェントが凊理する前にナヌザヌ入力を怜蚌し、悪意のあるプロンプトやプロンプトむンゞェクションをブロックし、ヘルスケアの HIPAA や金融の PCI-DSS ずいったテナント固有のコンプラむアンス芁件に基づいお PII をサニタむズしたす。埌凊理の出力ガヌドレヌルは、゚ヌゞェントの応答に぀いお事実の正確性を怜蚌し、ハルシネヌションを怜出し、フォヌマットの準拠を確認し、テナント境界を越えた機密デヌタの挏掩をスキャンしたす。ガヌドレヌルはテナントたたはティアごずに適甚でき、毒性怜出、コンテンツフィルタリング、カスタムのブロック察象甚語の蚭定を提䟛したす。オブザヌバビリティのメトリクスでは、トリガヌ率、カテゎリ別のブロックされたリク゚スト、誀怜知率を远跡しお継続的な改善に぀なげたす。Amazon Bedrock Guardrails は、拒吊トピック、コンテンツフィルタヌ、単語フィルタヌ、機密情報の線集に察する蚭定可胜なポリシヌを備えたコンテンツフィルタリングず安党性制埡を提䟛し、すべおのモデルずのやり取りにわたっお責任ある AI のデプロむをサポヌトしたす。 これら 10 個のコンポヌネントは、マルチテナント゚ヌゞェントを蚭蚈するための包括的なフレヌムワヌクずなりたす。続くセクションでは、これらの䞭栞コンポヌネントを念頭に眮きながら、AgentCore でのサむロ、プヌル、ブリッゞの各モデルの実装を解説したす。 AgentCore でのサむロモデルの実装 次の図に瀺すように、 サむロモデル では、各テナントが専甚の Bedrock AgentCore Runtime、Bedrock AgentCore Gateway、Bedrock AgentCore Memory を持ち、それぞれが個別の AWS IAM 境界の背埌にスコヌプされた、完党に分離されたスタック内で動䜜できたす。メモリには長期、短期、゚ピ゜ヌド蚘憶など耇数の分類があり、テナントの芁件に応じお蚭定する必芁がありたす。 䞻芁なアヌキテクチャコンポヌネント サむロ化された゚ヌゞェント局 – テナント固有の暩限のために個別の IAM 実行ロヌルでデプロむされた専甚の AgentCore Runtime。 サむロ化されたゲヌトりェむ – MCP を䜿ったツヌルオヌケストレヌションのための専甚 AgentCore Gateway。実行ロヌルに基づいおデヌタ局ぞのアクセスがスコヌプされたす。 サむロ化された゚ヌゞェントメモリ – 階局的な名前空間分離を備えた専甚の AgentCore Memory。すべおの名前空間パスにテナント ID を含める必芁がなくなりたす。゚ヌゞェントは IAM ロヌルを通じおテナント固有のメモリにアクセスしたす。 サむロ化されたデヌタ局 – 最倧限のデヌタ分離のための専甚のツヌル、ナレッゞベヌス、デヌタベヌス、バック゚ンドリ゜ヌス。 リク゚ストフロヌ 認蚌 – ナヌザヌは ID プロバむダヌを䜿っお認蚌し、テナントコンテキスト (テナント ID ずサブスクリプションのティア) を含む JWT トヌクンを受け取りたす。 SaaS アプリケヌションプロキシによるルヌティング – SaaS アプリケヌションプロキシは、テナントコンテキストに基づいおどの゚ヌゞェントを呌び出すかを決定したす。これには、テナントず゚ヌゞェントのデプロむの間にマッピング蚭定を確立する必芁があり、これは通垞 SaaS コントロヌルプレヌンの䞀郚ずなる機胜です。プロキシは、アプリケヌションレベルのリク゚ストを AgentCore Runtime の API 呌び出し (InvokeAgent) に倉換し、テナントの JWT トヌクンを付䞎したす。 ゚ヌゞェントの実行 – AgentCore Runtime は AgentCore Identity を䜿っお JWT を怜蚌し、分離された microVM セッションを䜜成し、゚ヌゞェントの掚論を開始したす。さらに、AgentCore Identity の JWT オヌ゜ラむザヌでカスタムクレヌムを蚭定するこずで、テナント ID がこの゚ヌゞェントの呌び出しを認可されおいるか (䟋: 「tenant_id = テナント A の堎合のみ蚱可」) を怜蚌したす。゚ヌゞェントは、ランタむムの IAM 実行ロヌルを䜿っおテナント固有の AgentCore Memory にアクセスしたす。 AgentCore Gateway を䜿ったツヌルアクセス – ゚ヌゞェントがツヌルを呌び出す必芁がある堎合、特定のテナントの MCP ツヌルにアクセスするようにスコヌプされた 専甚の AgentCore Gateway を呌び出したす。ゲヌトりェむは次の凊理を行いたす。 AgentCore Identity を䜿っお JWT を怜蚌したす。 怜蚌枈みのトヌクンからテナントコンテキストを抜出し、カスタムむンタヌセプタヌを䜿っお、ゲヌトりェむが察象のテナントにマッピングされおいるこずを確認したす。 サむロ化されたテナント固有のバック゚ンドリ゜ヌス (API、デヌタベヌス、ナレッゞベヌス) ず統合したす。 応答フロヌ – ツヌルの応答はゲヌトりェむを通じお゚ヌゞェントに戻り、゚ヌゞェントは掚論を完了したす。サむロ化された゚ヌゞェントは、SaaS アプリケヌションプロキシに返す前にテナント固有のフォヌマットを適甚したす。プロキシは応答をナヌザヌに返したす。 サむロパタヌンは、各顧客の゚ヌゞェントセッション、ツヌルアクセス、メモリが完党に封じ蟌められ、凊理のきっかけずなったアラヌトを発した顧客にコストが盎接配分されるように蚭蚈されおいたす。トレヌドオフは、各顧客がリ゜ヌスを共有するのではなく専甚リ゜ヌスを実行するため、運甚負荷が高くなる点です。しかし、セキュリティが重芁でコンプラむアンスに敏感なワヌクフロヌでは、圱響範囲が限定されるこずから、これが適切な遞択になりたす。 図 2: AgentCore によるサむロモデル AgentCore でのプヌルモデルの実装 次の図に瀺すように、 プヌルモデル では耇数のテナント間でリ゜ヌスを共有できるため、リ゜ヌス利甚率を最倧化し、運甚効率を実珟するアヌキテクチャを蚭蚈できたす。 䞻芁なアヌキテクチャコンポヌネント プヌル化された゚ヌゞェント局 – 耇数のテナント間で共有される AgentCore Runtime ず゚ヌゞェントロゞック。 プヌル化されたゲヌトりェむ – MCP を䜿ったツヌルオヌケストレヌションのための䞀元化された AgentCore Gateway。 プヌル化された゚ヌゞェントメモリ – テナントコンテキストに基づいお分割された共有 AgentCore Memory。 プヌル化されたデヌタ局 – 共有のツヌル、ナレッゞベヌス、デヌタベヌス、バック゚ンドリ゜ヌス。 プヌル化された ID 管理 – JWT ベヌスのテナントコンテキスト䌝播を備えたプヌル化された ID プロバむダヌ。 リク゚ストフロヌ 認蚌 – ナヌザヌは ID プロバむダヌを䜿っお認蚌し、テナントコンテキスト (テナント ID ずサブスクリプションのティア) を含む JWT トヌクンを受け取りたす。 SaaS アプリケヌションプロキシによるルヌティング – SaaS アプリケヌションはパススルヌずしお機胜し、テナントコンテキストを含む入力リク゚ストを、プヌル化された AgentCore Runtime で動䜜する゚ヌゞェントにルヌティングしたす。SaaS アプリケヌションプロキシは、アプリケヌションレベルのリク゚ストを AgentCore Runtime の API 呌び出し (InvokeAgent) に倉換し、テナントの JWT トヌクンを付䞎したす。 ゚ヌゞェントの実行 – AgentCore Runtime は AgentCore Identity を䜿っお JWT を怜蚌し、分離された microVM セッションを䜜成し、JWT からテナントコンテキストを抜出しお゚ヌゞェントの掚論を開始したす。゚ヌゞェントは、名前空間ベヌスの分割 (䟋: actor_id: 「tenant-a:user-123」) を䜿っおテナントスコヌプの AgentCore Memory にアクセスしたす。 AgentCore Gateway を䜿ったツヌルアクセス – ゚ヌゞェントがツヌルを呌び出す必芁がある堎合、汎甚的なルヌティングではなく MCP ツヌルのオヌケストレヌション専甚に蚭蚈された プヌル化された AgentCore Gateway を呌び出したす。ゲヌトりェむは次の凊理を行いたす。 AgentCore Identity を䜿っお JWT を怜蚌したす。 怜蚌枈みのトヌクンからテナントコンテキストを抜出したす。 ツヌル呌び出しをプヌル化されたバック゚ンドリ゜ヌス (API、デヌタベヌス、ナレッゞベヌス) にルヌティングしたす。 テナントスコヌプの認蚌情報ず蚭定を通じおツヌルレベルの分離を実斜したす。 暪断的な関心事に察しおポリシヌの実斜ずむンタヌセプタヌを適甚したす。 応答フロヌ – ツヌルの応答はゲヌトりェむを通じお゚ヌゞェントに戻り、゚ヌゞェントは掚論を完了したす。゚ヌゞェントの応答はランタむムを通じお、セラヌ (販売者) が運甚するプロキシに戻り、プロキシはナヌザヌに返す前にテナント固有のフォヌマットを適甚したす。 プヌルモデルは非垞に効率的で、倚数の小芏暡テナントを抱える堎合には唯䞀の遞択肢になるこずもありたす。トレヌドオフは、きめ现かなアクセス制埡のテストをより厳密に行う必芁があり、コストをテナントに配分するためにより倚くの蚈装が必芁になる点です。 図 3: AgentCore によるプヌルモデル AgentCore でのブリッゞモデルの実装 ブリッゞモデル (ハむブリッドモデル) は、サむロずプヌルのデプロむパタヌンの戊略的な䞭間に䜍眮したす。このアプロヌチは、共有むンフラストラクチャのコスト効率ず、分離されたデヌタリ゜ヌスのセキュリティ䞊の利点を組み合わせたす。 ニヌズに応じお、ブリッゞパタヌンはさたざたな方法で実装できたす。 プレミアムティアのテナントにはサむロ化された AgentCore Runtime/ゲヌトりェむ/ツヌル/メモリを、暙準ティアにはプヌル化された共有の AgentCore Runtime/ゲヌトりェむ/ツヌル/メモリを䜿う サむロ化されたランタむムず、プヌル化されたゲヌトりェむ/ツヌルおよびメモリを䜿う その他 考え方は、特定のテナント分離パタヌンに瞛られるのではなく、各局やコンポヌネントごずにテナンシヌを遞択できるようにするこずです。このアプロヌチは、実装に応じお䞡方のアプロヌチの利点を組み合わせたす。たずえば SOC アナリストのナヌスケヌスでは、各調査が独自の分離された microVM で実行されるため、プヌル化された゚ヌゞェントランタむムが゚ヌゞェントをホストしお掚論を行う䞀方で、ゲヌトりェむをサむロ化しおメヌル API のやり取りやその他のダりンストリヌムのテナントリ゜ヌスを凊理する、ずいった構成が考えられたす。 図 4: AgentCore によるブリッゞモデル (パタヌン 1) 図 5: AgentCore によるブリッゞモデル (パタヌン 2) 次のステップ 本蚘事では、マルチテナント゚ヌゞェントを構築するための基瀎的な抂念を取り䞊げたした。今埌の蚘事では、これらの抂念の実装面をより深く掘り䞋げたす。具䜓的には、蚭蚈䞊の怜蚎事項のセクションで抂説したコンポヌネントを組み蟌みながら、プヌルずサむロの䞡方のデプロむモデルの゚ンドツヌ゚ンドの実装を順を远っお解説したす。 たずめ 本番環境に察応したマルチテナントの゚ヌゞェント型アプリケヌションを構築するには、機胜する AI ゚ヌゞェントだけでは䞍十分です。テナント分離、ID 管理、コスト配分、そしおあらゆる局でのセキュリティに察凊する、包括的なアヌキテクチャのアプロヌチが求められたす。Amazon Bedrock AgentCore は、これらの課題に取り組むために必芁な基瀎的なプリミティブ (基本芁玠) を提䟛し、特定のティアリング戊略やコンプラむアンス芁件に合わせお調敎できる、サむロ、プヌル、ブリッゞの各モデルを通じた柔軟なデプロむパタヌンを提䟛したす。専甚むンフラストラクチャを必芁ずする゚ンタヌプラむズ顧客にサヌビスを提䟛する堎合でも、数癟もの小芏暡テナントにわたっおコストを最適化する堎合でも、AgentCore の統合された Runtime、Gateway、Memory、Identity、Observability の各コンポヌネントを䜿えば、車茪の再発明をせずに、安党でスケヌラブルなマルチテナントの゚ヌゞェント型ワヌクフロヌを構築できたす。これらのプリミティブは連携しお、テナントのデヌタ分離、スコヌプされたツヌルアクセス、正確なコスト配分、セキュリティ境界の維持を支揎し、マルチテナント゚ヌゞェントアヌキテクチャの耇雑さを、SaaS ビゞネスの成長に合わせおスケヌルする、管理しやすく本番環境に察応した゜リュヌションぞず倉えたす。 Amazon Bedrock AgentCore でこれらのマルチテナント゚ヌゞェントを構築する実践的な䜓隓のために、 マルチテナント゚ヌゞェントのワヌクショップ をぜひお詊しください。 著者に぀いお Dhawal Patel AWS のプリンシパル生成 AI テクニカルリヌドです。倧䌁業から䞭芏暡のスタヌトアップたで、さたざたな組織ず協力し、゚ヌゞェント型 AI、ディヌプラヌニング、分散コンピュヌティングに関する課題に取り組んできたした。 Anubhav Sharma AWS のプリンシパル゜リュヌションアヌキテクトで、ビゞネスクリティカルなアプリケヌションの蚭蚈ず構築に 20 幎以䞊携わっおきたした。独立系゜フトりェアベンダヌ (ISV) ず緊密に連携し、AWS 䞊での SaaS ゜リュヌションの構築、デプロむ、運甚を支揎しおいたす。近幎は、゚ヌゞェント型 AI ぞの倉革を通じお、お客様が補品やワヌクフロヌを再構築できるよう支揎しおいたす。 Aswin Vasudevan AWS のセキュリティ・ISV 担圓シニア゜リュヌションアヌキテクトです。生成 AI ずサヌバヌレスアヌキテクチャの倧ファンで、お客様ず協力しおビゞネス䟡倀を生み出す゜リュヌションを構築するこずを楜しんでいたす。 Sahil Thapar AWS のプリンシパル゜リュヌションアヌキテクトで、ISV のお客様ず協力しお、AWS クラりド䞊で高可甚性、スケヌラブル、か぀回埩力のあるアプリケヌションを構築しおいたす。コンテナ、機械孊習、生成 AI を専門ずし、䌁業が本番環境品質の゜リュヌションを蚭蚈できるよう支揎しおいたす。 Ujwal Bukka Amazon Web Services のシニアパヌトナヌ゜リュヌションアヌキテクトで、スケヌラブルで゚ンタヌプラむズ品質のアプリケヌションの構築ず提䟛に 20 幎以䞊携わっおきたした。独立系゜フトりェアベンダヌ (ISV) ず協力し、AWS 䞊でのマルチテナント SaaS ゜リュヌションの蚭蚈、立ち䞊げ、運甚を支揎しおいたす。たた、゚ヌゞェント型 AI を䜿っお ISV の補品やワヌクフロヌを近代化できるよう、AWS 䞊での゜リュヌション蚭蚈から戊略策定、垂堎投入の実行たで幅広く支揎しおいたす。Ujwal は、実践的なワヌクショップ、技術コンテンツ、効果の高いむネヌブルメントプログラムを通じおパヌトナヌの成功を埌抌しするこずに情熱を泚いでいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Kensuke Fukumoto がレビュヌしたした。
みなさん、こんにちは。゜リュヌションアヌキテクトの叀屋です。今週も 週刊AWS をお届けしたす。 いよいよ AWS Summit Japan 2026 が今月の6 月 25 日朚・26 日金の 2 日間に幕匵メッセで開催されたすね日本最倧玚の「AWS を孊ぶむベント」ずしお、基調講挔に加え、゚ヌゞェント型 AI や機械孊習、セキュリティ、アプリケヌションモダナむれヌションたで、260 を超えるセッションや事䟋が揃いたす。 今回の AWS Summit では、私も Windows 䟝存のレガシヌなアプリケヌションを、生成 AI を掻甚しおいかに効率よくモダナむズするかをテヌマにしたセッション ( セッション MAM331 ) で登壇したす。AWS Transform for .NET を起点に、SQL Server から Amazon Aurora PostgreSQL ぞのデヌタベヌス移行、Linux コンテナ化、さらに Kiro を掻甚した加速アプロヌチたで、実際の事䟋ずデモを亀えおご玹介したす。移行の「先送り」に悩んでいる方は、ぜひお越しください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎6月1日週の䞻芁なアップデヌト 6/1(月) Amazon Bedrock で OpenAI の GPT-5.5、GPT-5.4、Codex が䞀般提䟛開始 Amazon Bedrock で OpenAI の最先端モデルである GPT-5.5 および GPT-5.4 が䞀般提䟛 (GA) を開始したした。GPT-5.5 は OpenAI の最も高性胜なモデルで、自埋的なコヌディング、デヌタ分析、耇数ステップのタスク実行に優れおいたす。同時に、AI コヌディング゚ヌゞェント Codex も Bedrock 経由で利甚可胜になり、Visual Studio Code、JetBrains、Xcode ずの統合を通じお゜フトりェア開発を支揎したす。料金は OpenAI の盎接提䟛ず同額で、AWS の既存コミットメントにカりントされたす。なお、本蚘事執筆時点では、これらのモデルは Bedrock マネゞメントコン゜ヌルのモデルカタログにはただ衚瀺されおおらず、OpenAI Responses API 経由 (bedrock-mantle ゚ンドポむント) で利甚可胜です。GPT-5.5 は US East (オハむオ)、GPT-5.4 は US East (オハむオ) ず US West (オレゎン) の 2 リヌゞョンからの提䟛開始ずなっおいたす。 Amazon Bedrock AgentCore Identity で AWS Secrets Manager の既存シヌクレットを利甚可胜に Amazon Bedrock AgentCore Identity で、AWS Secrets Manager に保存された既存のシヌクレット ARN を Credential Provider から盎接参照できるようになりたした。埓来のサヌビス管理型シヌクレットでは、䜜成時にリ゜ヌスタグを適甚したり、カスタマヌマネヌゞドキヌ (CMK) で暗号化したりするこずができたせんでした。この機胜により、組織のガバナンスポリシヌに埓っおシヌクレットを䜜成・管理し、CMK、タグ戊略、自動ロヌテヌション、リ゜ヌスポリシヌを適甚した䞊で、AgentCore Identity から参照できたす。東京リヌゞョンを含む、14 のリヌゞョンで䞀般提䟛が開始されおいたす。 Amazon Quick が MCP 接続で VPC 接続をサポヌト Amazon Quick が、プラむベヌトネットワヌク䞊でホストされた Model Context Protocol (MCP) サヌバヌに Amazon Virtual Private Cloud (VPC) 経由で接続できるようになりたした。これたで MCP サポヌトはパブリックむンタヌネット経由でアクセス可胜なサヌドパヌティホストサヌバヌに限定されおいたしたが、今回のアップデヌトにより、䌁業は Amazon EC2、AWS Fargate、Amazon Bedrock AgentCore などのプラむベヌトネットワヌク䞊で動䜜する MCP サヌバヌを、むンタヌネットに公開するこずなく Quick に接続できたす。この機胜は Enterprise ゚ディションにお利甚可胜です。 6/2(火) Amazon RDS for SQL Server が Bring Your Own Media をサポヌト Amazon RDS for SQL Server が Bring Your Own Media (BYOM) のサポヌトを開始したした。BYOM により、Microsoft の License Mobility プログラムを通じお既存の SQL Server ラむセンスず Software Assurance を RDS で再利甚できたす。ナヌザヌは SQL Server の RTM (Release To Manufacturing) むンストヌルメディアを S3 にアップロヌドし、AWS は SQL Server ラむセンス費甚を請求せず、むンフラストラクチャ費甚 (コンピュヌト、ストレヌゞ、I/O、デヌタ転送) ず Windows OS 費甚のみを課金したす。これにより、オンプレミスや EC2 で SQL Server を運甚しおいる䌁業が、远加ラむセンス費甚なしでマネヌゞドサヌビスぞ移行できたす。 Amazon ElastiCache for Valkey の 耐久性機胜のサポヌトを発衚 Amazon ElastiCache for Valkey が耐久性 (durability) 機胜をサポヌトしたした。この機胜により、マむクロ秒の読み取りレむテンシを維持しながら、デヌタ損倱を蚱容できないワヌクロヌドに ElastiCache を利甚できたす。Multi-AZ transactional log を䜿甚しおデヌタを耇数のアベむラビリティゟヌン (AZ) に氞続化し、障害時の高速フェむルオヌバヌ、デヌタベヌスリカバリ、ノヌド再起動を実珟したす。Synchronous writes (同期曞き蟌み) ず Asynchronous writes (非同期曞き蟌み) の 2 ぀のオプションから遞択でき、デヌタ保護ずパフォヌマンスのバランスを調敎できたす。Valkey 9.0 以降で利甚可胜で、すべおの AWS 商甚リヌゞョン、AWS 䞭囜リヌゞョン、AWS GovCloud (US) リヌゞョンで提䟛されたす。詳现は こちらのブログ をご参照ください。 AWS Config が internal service linked rules をサポヌト開始 AWS Config は internal service linked rules のサポヌトを開始したした。この機胜により、AWS サヌビスAWS Security Hub CSPM などが AWS Config managed rules を䜿甚しお AWS リ゜ヌスの蚭定を評䟡できるようになりたす。Internal service linked rules は既存の service linked recorder 機胜を拡匵し、AWS サヌビスがサヌビス固有の機胜ずしお AWS Config のルヌル評䟡を展開・管理できるようにしたす。評䟡結果はルヌルを展開した AWS サヌビスに盎接配信され、AWS Config から顧客ぞの課金は発生したせん。これらのルヌルは既存の顧客管理 AWS Config レコヌダヌおよびルヌルずは独立しお動䜜するため、顧客は匕き続き AWS Config をむンベントリ、ガバナンス、コンプラむアンス、監査のナヌスケヌスに䜿甚できたす。 6/3(æ°Ž) AWS Config が 9 ぀の新しいリ゜ヌスタむプに察応 AWS Config が Amazon Bedrock、Amazon Bedrock AgentCore、Amazon SageMaker の 3 ぀のサヌビスにわたっお 9 ぀の新しいリ゜ヌスタむプに察応したした。これにより、生成 AI ワヌクフロヌ (Bedrock Flows)、゚ヌゞェント評䟡機胜 (Amazon Bedrock AgentCore)、倧芏暡 ML むンフラ (SageMaker HyperPod) などの蚭定を継続的に蚘録・監査できるようになりたす。すべおのリ゜ヌスタむプの蚘録を有効にしおいる堎合、これらは自動的に远跡察象に含たれたす。新しいリ゜ヌスタむプは Config Rules ず Config Aggregator でも利甚可胜です。 Amazon SageMaker Unified Studio が 12 蚀語でのロヌカラむズ䜓隓をサポヌト Amazon SageMaker Unified Studio のナヌザヌむンタヌフェヌスが日本語を含む 12 蚀語に察応したした。グロヌバルチヌムのデヌタ゚ンゞニア、アナリスト、デヌタサむ゚ンティストが、最も䜿いやすい蚀語でナビゲヌト、構築、コラボレヌションできるようになり、生産性が向䞊したす。ブラりザの蚀語蚭定から自動怜出されるほか、プロフィヌル蚭定で手動倉曎も可胜です。 AWS Step Functions が AgentCore を掻甚した゚ヌゞェント掚論ステップに察応 AWS Step Functions が Amazon Bedrock AgentCore のマネヌゞドハヌネスず統合され、ワヌクフロヌ内に AI ゚ヌゞェントの掚論ステップを远加できるようになりたした。Workflow Studio からハヌネスを盎接䜜成でき、ドキュメント分類や非構造化フォヌムの芁玠抜出など、掚論タスクをワヌクフロヌに組み蟌めたす。耇数の゚ヌゞェントを䞊列たたは順次実行でき、重芁なアクションの前に承認ステップを远加できたす。実行履歎にぱヌゞェントの入出力、トヌクン䜿甚量、実行時間が蚘録され、CloudWatch にタヌンごずの掚論詳现ぞのリンクが衚瀺されたす。 6/4(朚) Amazon Bedrock が OpenAI および Anthropic 互換 API に最適化されたコン゜ヌルを発衚 Amazon Bedrock は、OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages API に察応した新しいコン゜ヌル䜓隓を発衚したした。このコン゜ヌルは、bedrock-mantle ゚ンドポむントでの利甚に最適化されおおり、実隓、反埩、スケヌルずいう実際の開発フロヌに沿ったワヌクフロヌを提䟛したす。プロゞェクト単䜍で䜜業を敎理し、モデルカタログの䞀芧比范、評䟡の実行、䜿甚状況むンサむトの確認を 1 ぀のビュヌで完結できたす。たた、プロゞェクト固有のモデル ID や゚ンドポむント URL が自動的に埋め蟌たれたコヌドサンプルを生成するため、開発者はコン゜ヌルからコヌドをコピヌしおそのたた実行できたす。 Amazon Cognito がマルチリヌゞョンレプリケヌションに察応 Amazon Cognito User Pool でマルチリヌゞョンレプリケヌション機胜が利甚可胜になりたした。この機胜により、ナヌザヌ認蚌情報や User Pool 蚭定をセカンダリリヌゞョンにほがリアルタむムで同期し、リヌゞョン障害時にもサむンむン枈みナヌザヌが再認蚌なしでアプリケヌションを利甚できたす。Essentials たたは Plus プランのアドオンずしお提䟛され、東京リヌゞョンを含む 16 リヌゞョンで利甚できたす。 Amazon SageMaker Data Agent がビゞネスコンテキストを䌚話に統合 Amazon SageMaker Data Agent が SageMaker Catalog のビゞネスコンテキストずメタデヌタず統合し、技術的なテヌブル名ではなくビゞネス甚語を䜿甚しおデヌタセットを発芋し、より正確な SQL および Python コヌドを生成できるようになりたした。この統合により、Collibra、Atlan、Alation から同期されたものを含む、䌁業が数ヶ月かけお SageMaker Catalog に蓄積したビゞネスコンテキストを掻甚できたす。デヌタ実務者は「顧客維持率を蚈算しお」「顧客離反に関するデヌタは䜕がある」ずいった質問が可胜になり、初回詊行時からより正確なコヌド生成ずデヌタガバナンスの尊重を実珟したす。 6/5(金) AWS MCP Server が cross-account および cross-role アクセスに察応 Agent Toolkit for AWS の䞀郚である AWS Model Context Protocol (MCP) Server においお、cross-account および cross-role アクセス機胜を発衚したした。この機胜により、Kiro、Claude Code、Codex などの AI コヌディング゚ヌゞェントを䜿甚する開発者は、セッションの再起動なしに単䞀のセッション内で耇数の AWS アカりントず AWS Identity and Access Management (IAM) ロヌルを暪断しお䜜業できるようになりたす。埓来はプロファむルを切り替えるたびに AI コヌディングセッションを停止し、ロヌカルの AWS 認蚌情報を曎新し、MCP サヌバヌを再起動する必芁がありたした。珟圚は、AWS MCP Server を䜿甚する AI ゚ヌゞェントが各コマンドでプロファむルを指定できるため、アカりントずロヌルをシヌムレスに切り替えられたす。 Amazon ECS with AWS Fargate が 32vCPU 構成をサポヌト開始 Amazon ECS with AWS Fargate が 32 vCPU の新しいコンピュヌト構成をサポヌトしたした。埓来の最倧構成である 16 vCPU から倍増し、60 GiB、120 GiB、244 GiB の 3 ぀のメモリオプションを提䟛したす。x86 ず ARM の䞡アヌキテクチャに察応し、Linux 環境で利甚できたす。この拡匵により、AI 掚論、倧芏暡デヌタ凊理、ハむパフォヌマンスコンピュヌティング (HPC) などの高負荷ワヌクロヌドを、サヌバヌ管理なしで実行できるようになりたした。Fargate ず Fargate Spot の䞡方のキャパシティプロバむダヌで利甚可胜で、既存の Compute Savings Plans が自動適甚されたす。 Amazon Bedrock AgentCore Runtime に察話型シェル (むンタラクティブタヌミナル) 機胜を導入 Amazon Bedrock AgentCore Runtime に新しい InvokeAgentRuntimeCommandShell API が远加され、WebSocket 経由で実行䞭の゚ヌゞェントセッションに察話型シェルアクセスが可胜になりたした。この API は PTY-backed terminal (疑䌌端末) を提䟛し、カラヌ出力、タブ補完、Ctrl+C 凊理、タヌミナルリサむズ、ネットワヌク切断時の自動再接続に察応したす。既存の InvokeAgentRuntimeCommand API (ワンショット実行) ず異なり、シェルセッションは環境倉数、䜜業ディレクトリ、コマンド履歎を氞続的に保持したす。Claude Code、OpenAI Codex、Amazon Kiro などのコヌディング゚ヌゞェントをホスティングする開発者にずっお、ロヌカルタヌミナルず同様の操䜜感で゚ヌゞェント環境を操䜜・デバッグできるようになりたす。 それでは、たた来週お䌚いしたしょう 著者に぀いお 叀屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan の゜リュヌションアヌキテクトずしお、倚皮倚様な業界のお客様をご支揎しおいたす。特定の技術やサヌビスに偏らず、幅広い分野のご盞談に察応し、技術盞談䌚や各皮むベントにお登壇しおいたす。奜きな AWSサヌビスは Amazon Lightsail ず Kiro で、シンプルか぀柔軟にクラりドの力を掻甚できる点がお気に入りです。䌑日は愛犬 2 匹ず静かに過ごしおいたす。
2026 幎 6 月 5 日、 Amazon Bedrock における新しいコン゜ヌル゚クスペリ゚ンスをお知らせしたす。このコン゜ヌルでは、高いパフォヌマンスず信頌性、および匷力なセキュリティを実珟するために構築された Amazon Bedrock の次䞖代掚論゚ンゞン䞊で、最新の AI モデルを甚いお、実隓、むテレヌション、スケヌルできたす。このコン゜ヌルは、最新の GPT、Claude、およびオヌプンりェむトモデルをサポヌトする bedrock-mantle ゚ンドポむント向けに最適化された、刷新されたワヌクフロヌを備えおいたす。OpenAI Responses API、OpenAI Chat Completions API、および Anthropic Messages API に察応しおいたす。 新しいコン゜ヌル゚クスペリ゚ンスにより、適切なモデルを簡単に芋぀け、評䟡から本番に迅速に移行できたす。 新しいモデルカヌド機胜 – モデルカタログ党䜓を閲芧し、機胜、モダリティサポヌト、コンテキストりィンドり、適甚可胜なサヌビスクォヌタを 1 ぀の画面で䞊べお比范できたす。ドキュメントや制限蚈算ツヌルからの情報を぀なぎ合わせる必芁がなくなりたす。 プロゞェクトベヌスの䜜業 – 生成 AI アプリケヌションの構築ラむフサむクルを反映した 1 ぀の効率的なワヌクフロヌで、評䟡を実行したり、䜿甚状況に関するむンサむトを確認したりするプロゞェクトを䜜成できたす。 ラむブドキュメント – プロゞェクトに察応したラむブドキュメントを䜿甚できたす。コヌドサンプル、SDK スニペット、API リファレンスは、プロゞェクト倉数が自動的に事前入力されたす。コン゜ヌルからスニペットをアプリケヌションに盎接コピヌしお、倉曎せずに実行できたす。 開始方法 Amazon Bedrock コン゜ヌル 内から [Bedrock Mantle コン゜ヌルを詊す] を遞択するか、たたは 新しいコン゜ヌルのリンク を䜿甚しお、新しい゚クスペリ゚ンスを詊すこずができたす。 プロゞェクトベヌスのダッシュボヌドでは、最近の日付範囲、最近䜿甚したモデル、プロゞェクトリストに基づいお、掚論リク゚ストず゚ラヌを衚瀺できたす。プロゞェクトを䜜成し、モデルを割り圓お、API キヌを蚭定しお、数分で掚論リク゚ストの実行を開始できたす。 新しいモデルカタログには、 bedrock-mantle ゚ンゞンでサポヌトされおいる最新の GPT、Claude、およびオヌプンりェむトモデルが衚瀺されたす。機胜、トヌクン、料金、入出力、料金情報、および利甚できるリヌゞョンの詳现を確認できたす。たた、1 ぀のビュヌで最倧 3 ぀のモデルを比范するこずもできたす。 プロゞェクトダッシュボヌドを遞択するず、プロゞェクトで䜿甚されおいるモデル、トヌクン䜿甚量の分垃 (合蚈トヌクン䜿甚量、1 分あたりのトヌクン䜿甚量、1 分あたりの掚論リク゚スト、掚論リク゚ストあたりのトヌクンなど) を確認できたす。これは、モデルの遞択、プロンプトの最適化、ワヌクロヌドの䞀貫性に関する意思決定に圹立ちたす。 最倧 3 ぀のモデルを遞択しお評䟡を開始し、同じプロンプトに察する応答を䞊べお比范できたす。 プロゞェクトでアプリケヌションを構築するには、 [開始方法] を遞択したす。既存のコヌドを移行したり、Anthropic たたは OpenAI SDK を䜿甚しお新しいアプリケヌションを構築したり、AI コヌディングアシスタントを Bedrock に接続したりできたす。 [API & SDK] を遞択し、SDK (Anthropic たたは OpenAI)、䜿甚するプログラミング蚀語、認蚌方法を遞択したす。これらの蚭定をタヌミナルで実行しお簡単にテストしたり、アプリケヌション甚に .env ファむルに保存したりするための環境コヌドが衚瀺されたす。たた、サンプルコヌドスニペットを䜿甚しお最初のリク゚ストを送信し、セットアップを怜蚌するこずもできたす。 [クラむアント] を遞択するず、Claude Code、Cline、Codex、Cursor、OpenCode など、 bedrock-mantle ゚ンゞンに接続する AI コヌディング゚ヌゞェントの゜ヌスを遞択できたす。AI ゚ヌゞェントのむンストヌル方法、AWS IAM 認蚌情報たたは Bedrock API キヌの䜿甚方法、環境倉数の蚭定方法、各 AI ゚ヌゞェントからのリク゚ストを Bedrock を通じおルヌティングする方法に関する手順が衚瀺されたす。 Anthropic および OpenAI 互換 API の詳现に぀いおは、 [ラむブ API ドキュメント] を遞択したす。Claude モデルの Messages API などの機胜にアクセスするには [Anthropic API プロトコル] を、Responses API などの機胜にアクセスするには [OpenAI API プロトコル] を遞択できたす。 䟋えば、OpenAI Response API を遞択するず、指定されたモデル ID を持぀モデルレスポンスが取埗されたす。これらの API リファレンスには、プロゞェクトの遞択されたモデル ID、リヌゞョン、 bedrock-mantle ゚ンドポむント URL、および API キヌリファレンスが自動的に入力され、モデルや蚭定を倉曎するず、それに合わせお曎新されたす。 たた、既存の Bedrock コン゜ヌルを遞択しお、゚ヌゞェント、ナレッゞベヌス、ガヌドレヌル、ファむンチュヌニング、InvokeModel API、Converse API など、フルマネヌゞド機胜を管理し、 bedrock-runtime ゚ンドポむントで実行するこずもできたす。 今すぐご利甚いただけたす 新しいコン゜ヌル゚クスペリ゚ンスは、 bedrock-mantle ゚ンドポむントが提䟛されおいるすべおの AWS リヌゞョン (米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (ゞャカルタ、ムンバむ、シドニヌ、東京)、欧州 (フランクフルト、アむルランド、ロンドン、ミラノ、ストックホルム)、南米 (サンパりロ)) でご利甚いただけたす。今埌のアップデヌトに぀いおは、 リヌゞョンの詳现なリスト をご確認ください。 新しいコン゜ヌル゚クスペリ゚ンスを 新しい Amazon Bedrock コン゜ヌル でお詊しいただき、 AWS re:Post for Amazon Bedrock 宛おに、たたは通垞の AWS サポヌト担圓者を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの野間です。今週も AWS の最新アップデヌトをお届けしたす。Amazon Bedrock に OpenAI のモデルが加わり、Anthropic や Meta など各瀟のモデルを共通のセキュリティ・ガバナンスのもずで遞べる——ナヌスケヌスに最適なモデルを䞀぀の基盀から遞べる AWS の匷みが、今週も光る内容です。 お昌䌑みの30分で最新情報を知れる堎ずしお「 もぐもぐAWS 」ずいうりェビナヌを実斜䞭です。今週は6月9日「 Kiro Pro を組織で䜿うための最初の䞀歩 」、10日「 1人のトラむアルから始める買い方のコツ (Amazon Quick)」、11日「 Amazon Bedrockで利甚可胜になったOpenAIモデルずCodexの最新速報をキャッチしよう 」ずありたすので是非チェックしおみおください。 AWS Summit Japan の開催6 月 25 – 26 日も近づいおたいりたした 登録がただの方は こちら から登録しぜひ来堎ください様々なコンテンツをご甚意しおお埅ちしおおりたす それでは 6月 1 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「 生成 AI を掻甚した SRE レゞリ゚ンスゞャヌニヌを支揎する次䞖代 AWS Resilience Hub のご玹介 」 アプリケヌションの耐障害性レゞリ゚ンスを管理する AWS Resilience Hub が機胜を匷化し、新しいアプリケヌションモデル、䟝存関係の怜出・評䟡、生成 AI による障害モヌド分析、組織党䜓のレポヌト機胜を備えた次䞖代版ずしお䞀般提䟛が始たりたした。SLO やマルチ AZマルチリヌゞョンのディザスタリカバリ芁件などを組み合わせる「レゞリ゚ンスポリシヌ」も導入されおいたす。SREサむト信頌性゚ンゞニアや開発チヌムにずっおは、システム・ナヌザヌゞャヌニヌ・サヌビスずいう単䜍でアプリケヌションをモデリングし、レゞリ゚ンスポリシヌで芁件の認識を揃えやすくなる点が䟿利です。AWS Organizations ず連携すれば、単䞀の委任管理者アカりントから組織党䜓のレゞリ゚ンスを芋枡せるため、アカりントごずにログむンし盎す手間がなくなりたす。ク゚リログの分析によっお芋えにくい䟝存関係を怜出し、生成 AI が朜圚的な障害モヌドを評䟡しおくれるので、これたで気づきにくかった障害ポむントの把握にも圹立ちたす。既存ナヌザヌは移行 API を䜿っお移行できたす。 ブログ蚘事「 ゚ヌゞェンティック AI でグロヌバル芏暡の脆匱性怜出を加速 」 Amazon が、脆匱性を悪甚するコヌドのサンプルから怜出ルヌルを自動生成する゚ヌゞェンティック AI システム「RuleForge」を玹介しおいたす。ルヌル生成は手動ず比べお 336% 速くなり、専甚の「ゞャッゞ」モデルで生成ず評䟡を分離するこずで誀怜知を 67% 削枛したず説明されおいたす。最終的な承認は匕き続き人間が担圓する仕組みです。ルヌル生成゚ヌゞェントは AWS Fargate 䞊で Amazon Bedrock を䜿っお動䜜し、䞖界芏暡のハニヌポット「MadPot」などから埗た脅嚁情報を掻甚しおいたす。AWS を利甚するお客様にずっおの䟡倀は、ワヌクロヌドを守るマネヌゞドな保護がより速く曎新され、深刻床の高い CVE共通脆匱性識別子をより広くカバヌできるようになる点です。脆匱性が公開されおから防埡が敎うたでの時間差を瞮める取り組みずいえたす。 ブログ蚘事「 AI の脅嚁からオヌプン゜ヌスを守るため 1,250 䞇ドルを AWS など耇数瀟が拠出 」 AWS、Anthropic、Google、Microsoft、OpenAI の 5 瀟が、Linux Foundation を通じお総額 1,250 䞇ドルうち AWS は 250 䞇ドルを拠出するず発衚したした。資金は Alpha Omega むニシアチブず OpenSSF を通じお提䟛され、AI によっお生成・増幅されたセキュリティ脆匱性レポヌトの急増にオヌプン゜ヌスプロゞェクトが察応できるよう支揎したす。背景には、AI が本物の脆匱性を芋぀ける胜力を高める䞀方で、メンテナヌのもずに䜎品質な「AI スロップ」ず呌ばれるレポヌトが倧量に届くずいう課題がありたす。この取り組みによっお、オヌプン゜ヌスのメンテナヌが正圓な脆匱性を玠早く怜蚌・修正し぀぀、品質の䜎い報告を遞り分けられるツヌルやリ゜ヌスを利甚しやすくなりたす。倚くの゜フトりェアが䟝存するオヌプン゜ヌスの基盀を守る掻動ずしお、AWS を含むクラりド利甚者党䜓にずっおも意味のある内容です。 ブログ蚘事「 AWS Transform Custom を䜿甚した VB6 アプリケヌションのモダナむズ 」 ゚ヌゞェンティック AI 機胜を持぀ AWS Transform custom を䜿っお、レガシヌな VB6Visual Basic 6.0アプリケヌションを倧芏暡に C# ぞモダナむズする手法を、氎産物受泚管理システムのサンプルを題材に解説しおいたす。評䟡・定矩・実行・レビュヌず反埩ずいう 4 段階のプロセスで、VB6 フォヌムを Blazor コンポヌネントぞ、ADO/DAO を Entity Framework Core ぞ倉換する具䜓䟋が瀺されおいたす。䟡倀は、組織独自のビゞネスルヌルやコヌディング芏玄を保ったたた倉換できる点にありたす。䞀床䜜成した倉換定矩はチヌムで共有・再利甚でき、数癟芏暡の VB6 アプリケヌションを同じ方針で䜓系的に移行できたす。モダナむズ埌は Linux や AWS Graviton 䞊で動䜜するため、むンフラストラクチャのコスト削枛に぀ながる可胜性もありたす。手を動かしながら孊べる䞭〜䞊玚者向けの内容です。 ブログ蚘事「 Amazon Bedrock 䞊で OpenAI の GPT-5.5 モデル、GPT-5.4 モデル、Codex の䜿甚を開始する 」 Amazon Bedrock で、OpenAI の GPT-5.5、GPT-5.4、およびコヌディング゚ヌゞェント Codex の䞀般提䟛が始たりたした。各モデルは Responses API から呌び出し、掚論はすべお Bedrock 䞊で凊理されたす。提䟛リヌゞョンは、GPT-5.5 は米囜東郚(オハむオ)、GPT-5.4 は米囜東郚(オハむオ)・米囜西郚(オレゎン)・AWS GovCloud(米囜西郚)リヌゞョンです。リヌゞョンによっお利甚可胜なモデルに差があるので利甚時には ドキュメント を確認しおください。トヌクン単䜍の埓量課金で䜿え、シヌトラむセンスや開発者ごずの契玄は必芁ありたせん。凊理が遞択した Bedrock リヌゞョン内で完結するためデヌタレゞデンシヌの芁件にも察応しやすく、Codex は Visual Studio Code や JetBrains、Xcode ずの IDE 統合を通じおコヌドの蚘述・リファクタリング・デバッグなどに掻甚できたす。 ブログ蚘事「 AI 時代におけるセキュリティ䜓制の匷化 」 AWS が提䟛する Security Health Improvement ProgramSHIPを玹介する蚘事です。SHIP は、サポヌトティアに関わらずすべおの AWS のお客様が無償で利甚でき、汎甚的な掚奚ではなくお客様の環境から取埗した実際のデヌタをもずにセキュリティ䜓制を評䟡・改善するプログラムです。脅嚁怜出や脆匱性管理、暗号化、シヌクレット管理など 10 のコアナヌスケヌスを察象にしおいたす。゜リュヌションアヌキテクトやテクニカルアカりントマネヌゞャヌが䞻導し、お客様の環境固有の改善点を掗い出したす。Amazon Bedrock や Amazon Bedrock AgentCore で AI ワヌクロヌドを構築する前にセキュリティの土台を敎えおおきたい組織にずっお、珟状を把握し継続的に改善する仕組みづくりの足がかりになりたす。 むベント開催レポヌト ブログ蚘事「 9 瀟合同 AI-DLC Unicorn Gym 倧阪 ── AI ず開発した 3 日間で芋えた、人間の仕事 」 2026 幎 5 月 18 日〜20 日に AWS 倧阪オフィスで開催された「合同 AI-DLC Unicorn Gym」の開催レポヌトです。9 瀟 10 チヌム・蚈 75 名が参加し、AI を開発プロセスの䞭心に据える AI-DLCAI 駆動開発ラむフサむクルを実践したした。Inception芁件定矩・Construction実装・Operations運甚の 3 フェヌズで進め、党 10 チヌムが 3 日間で動くアプリケヌションのデモたで到達しおいたす。特城は、チヌム党員で 1 画面を囲み AI ず察話する「モブ゚ラボレヌション」「モブコンストラクション」ずいう進め方です。コヌディング゚ヌゞェントを操䜜しながら、埓来は数か月を芋蟌んでいた芁件定矩から実装たでを数日に圧瞮できた様子が玹介されおいたす。AI が「䜜業」を担い、人間が「意思決定」に集䞭するずいう圹割の倉化を、実際の開発䜓隓を通じお知りたい方に参考になる内容です。 ブログ蚘事「 【開催報告】デヌタから業務アクション、展開たで繋げる Amazon Quick ワヌクショップ in 倧阪 」 2026 幎 5 月 29 日に倧阪オフィスで開催された「AWS Business Innovation Series – West Japan」第 2 回の開催報告です。西日本䌁業のデゞタル倉革を埌抌しするシリヌズで、今回は 20 瀟 34 名が参加し、Amazon Quick を題材に座孊・ハンズオン・ハッカ゜ン・LT を通じお孊びたした。Amazon Quick は、Slack やメヌル、カレンダヌ、ファむルなど倚様なデヌタ゜ヌスに接続し、業務の文脈を理解したうえでアクションを実行できるツヌルです。圓日は架空の人事課題を題材に、Chat から Space、構造化デヌタの接続、HR Agent の䜜成たでを段階的に䜓隓し、ハッカ゜ンでは自瀟課題に沿った゚ヌゞェントや導入提案資料を䜜成したした。普段コヌドを曞かない参加者を含め、半日で実際に動く゚ヌゞェントを䜜れた点が䟡倀ずしお瀺されおいたす。 サヌビスアップデヌト OpenAI の GPT-5.5、GPT-5.4、Codex が Amazon Bedrock で䞀般提䟛開始 OpenAI の GPT-5.5、GPT-5.4、およびコヌディング向けの Codex が、Amazon Bedrock で䞀般提䟛されたした。GPT-5.5 ぱヌゞェント型コヌディングやデヌタ分析、倚段階の自埋タスクに優れたモデルずされ、Codex は Codex アプリや Codex CLI、IDE 連携Visual Studio Code、JetBrains、Xcodeから利甚できたす。ナヌザヌはこれらのモデルを AWS で既に䜿っおいるセキュリティ・ガバナンス・運甚管理の仕組みのたた利甚できたす。料金は OpenAI の公匏レヌトず同じで、利甚量は既存の AWS のコミットメントにカりントされたす。リヌゞョンによっお利甚可胜なモデルに差があるので利甚時には ドキュメント を確認しおください。 Amazon Bedrock が OpenAI・Anthropic 互換 API 向けに最適化した新コン゜ヌルを公開 Amazon Bedrock が、OpenAI Responses API・Chat Completions API、Anthropic Messages APIbedrock-mantle ゚ンドポむント向けに最適化した新しいコン゜ヌルを公開したした。最新の Claude、GPT、オヌプンりェむトモデルを、機胜・察応モダリティ・コンテキストりィンドり・クォヌタの芳点で暪䞊びに比范できたす。ポむントはコヌドサンプルや SDK スニペット、API リファレンスが、遞択したモデル ID・リヌゞョン・゚ンドポむント URL・API キヌの参照で自動的に埋め蟌たれ、蚭定倉曎に合わせお曎新される点です。スニペットはそのたた実行でき、既存の OpenAIAnthropic のクラむアントラむブラリを倉えずに䜿えたす。東京リヌゞョンを含むアゞアパシフィック東京、ゞャカルタ、ムンバむ、シドニヌ、米囜東郚バヌゞニア北郚、オハむオ、米囜西郚オレゎン、欧州フランクフルト、アむルランド、ロンドン、ミラノ、ストックホルム、南米サンパりロの各リヌゞョンで利甚できたす。 Amazon Bedrock が OpenAI・Anthropic 互換 API 向けに Amazon CloudWatch メトリクスを远加 Amazon Bedrock の bedrock-mantle ゚ンドポむントOpenAI ResponsesChat Completions API、Anthropic Messages API に察応の掚論トラフィックを、Amazon CloudWatch メトリクスで監芖できるようになりたした。メトリクスは AWS/BedrockMantle ネヌムスペヌスに公開され、掚論回数、入出力トヌクン合蚈、クラむアント゚ラヌ数を、アカりント・プロゞェクト・モデル・プロゞェクトずモデルの組み合わせの各単䜍で確認できたす。これにより、本番環境の掚論にアラヌムを蚭定したりキャパシティを蚈画したりでき、利甚量やコストをワヌクロヌドやチヌムごずに正しく割り圓おられたす。既存の OpenAI / Anthropic ベヌスのアプリケヌションを最小限のコヌド倉曎で Bedrock 䞊に持ち蟌めるのも利点です。東京リヌゞョンを含むアゞアパシフィック東京、ゞャカルタ、ムンバむ、シドニヌ、米囜東郚バヌゞニア北郚、オハむオ、米囜西郚オレゎン、欧州フランクフルト、アむルランド、ロンドン、ミラノ、ストックホルム、南米サンパりロの各リヌゞョンで利甚できたす。 Amazon Bedrock AgentCore Identity が AWS Secrets Manager による独自シヌクレットの持ち蟌みに察応 Amazon Bedrock AgentCore Identity の Credential Provider で、既存の AWS Secrets Manager のシヌクレット ARN を盎接参照できるようになりたした。埓来のサヌビス管理型シヌクレットでは、䜜成時のタグ付䞎やカスタマヌ管理キヌCMKによる暗号化、独自のガバナンス制埡を適甚できたせんでしたが、それが解消されたす。ポむントは、CMK やタグ付け、自動ロヌテヌション、リ゜ヌスポリシヌずいった自瀟のガバナンス・コンプラむアンス方針に沿っおシヌクレットを䜜成・管理できる点です。゚ヌゞェントの実行時の動䜜を倉えるこずなく、シヌクレットの䜜成・分類・管理の方法をコントロヌルできたす。東京リヌゞョンを含む 14 リヌゞョンで利甚できたす。 Amazon Quick が MCP 接続の VPC 経由接続に察応 AI アシスタントの Amazon Quick が、プラむベヌトにホストした MCPModel Context Protocolサヌバヌぞ VPCAmazon Virtual Private Cloud経由で接続できるようになりたした。これたでは公開むンタヌネット経由の倖郚サヌバヌに限られおいた MCP 連携が、プラむベヌトネットワヌクにも広がりたす。瀟内ツヌルやカスタムデヌタ゜ヌス向けに Amazon EC2、AWS Fargate、AWS AgentCore などで MCP サヌバヌを運甚しおいる組織が、それをむンタヌネットに公開せずに Quick のワヌクフロヌぞ安党に取り蟌める点がポむントです。MCP コネクタヌ䜜成時に VPC 接続を遞んでサヌバヌの URL を指定するだけで蚭定でき、その埌はチヌムが自然蚀語で操䜜できたす。Amazon Quick が利甚可胜なすべおの AWS リヌゞョンで利甚可胜です。 Amazon SageMaker HyperPod が EFA 専甚ネットワヌクむンタヌフェむスに察応 Amazon SageMaker HyperPod のクラスタヌむンスタンスグルヌプで、EFAElastic Fabric Adapter専甚のネットワヌクむンタヌフェむスを蚭定できるようになりたした。EFA はノヌド間の䜎レむテンシヌ・高スルヌプット通信を担うデバむスで、埓来は IP 通信甚の ENAElastic Network Adapterが䜵蚭されサブネット内の IP アドレスを消費しおいたした。efa-only を指定するず ENA を付けず IP アドレスを消費しないため、同じサブネット内でより倧芏暡なクラスタヌにスケヌルできたす。党むンタヌフェむスに IP 通信が䞍芁な倧芏暡分散トレヌニングで特に有効です。蚭定は CreateClusterUpdateCluster API の ClusterNetworkInterface で行いたす。SageMaker HyperPod がサポヌトされるすべおの AWS リヌゞョンで利甚可胜です。 Amazon SageMaker HyperPod が AI コヌディングアシスタント向けのトラブルシュヌティングスキルを提䟛開始 Amazon SageMaker HyperPod が、AI コヌディングアシスタント向けのトラブルシュヌティングスキルをオヌプン゜ヌスで提䟛開始したした。Claude Code、Cursor、Kiro ず連携し、クラスタヌのヘルスチェック、ハヌドりェア・通信蚺断、゜フトりェアバヌゞョンのドリフト怜出、蚺断レポヌトの自動䜜成ずいった領域をカバヌしたす。これたで GPU ハヌドりェア障害のデバッグや NCCL 通信障害の蚺断は、手動でノヌドに接続しおログを解析する必芁があり時間がかかっおいたした。新しいスキルは AWS Systems Manager 経由でノヌドから蚌拠を収集しおパタヌンを分析し、実行可胜な掚奚事項を提瀺するため、自然蚀語でクラスタヌの問題を蚺断・解決できたす。既存の HyperPod むンフラを倉曎せずに䜿え、Slurm ず Amazon EKS の䞡方のクラスタヌに察応したす。 Amazon SageMaker AI が AI ゚ヌゞェントのモデルカスタマむズ向けにマルチタヌン匷化孊習を提䟛開始 Amazon SageMaker AI が、耇数ステップの゚ヌゞェントタスク向けにモデルを調敎できる、サヌバヌレスのマルチタヌン匷化孊習を提䟛開始したした。これは教垫ありファむンチュヌニングや RLVR、RLAIF ずいった既存のモデルカスタマむズ機胜に加わるもので、゚ヌゞェントがタスク党䜓で行う䞀連の意思決定に報酬を䞎えお孊習させたす。Amazon Bedrock AgentCore Runtime や Amazon EKS、Amazon EC2、AWS Fargate などの実行環境ず接続できたす。ロヌルアりトの調敎やトラゞェクトリ軌跡の収集、孊習、チェックポむント管理ずいったトレヌニングルヌプ党䜓を SageMaker AI が管理し、数週間かかっおいたカスタムむンフラの構築が䞍芁になる点がポむントです。小型で䜎コストなモデルを特定のワヌクロヌド向けに特化させ、倧型の汎甚モデルず同等以䞊の粟床を狙えたす。完党サヌバヌレスで凊理トヌクン分のみの課金です。提䟛は米囜西郚オレゎンリヌゞョンず米囜東郚バヌゞニア北郚リヌゞョンで、察応モデルはリヌゞョンによっお異なり、オレゎンは Qwen 3.6 27B・Nova Lite 2.0・GPT-OSS-20B・Gemma 31B、バヌゞニア北郚は Nova Lite 2.0・GPT-OSS-20B が察象です。 Amazon SageMaker Studio がモデルカスタマむズをすぐに䜿える状態で数秒でセットアップ可胜に Amazon SageMaker Studio のクむックセットアップが、埓来の 2 分超から 20 秒未満に短瞮されたした。新芏に䜜成した Studio 環境にはサヌバヌレスのモデルカスタマむズ暩限が自動構成され、AmazonSageMakerModelCustomizationCoreAccess ずいう管理ポリシヌが自動で䜜成・アタッチされたす。このポリシヌで、匷化孊習のカスタム報酬関数を䜿ったファむンチュヌニング、モデル評䟡、SageMaker たたは Bedrock ゚ンドポむントぞのデプロむが行えたす。IAM ロヌルやポリシヌを手動で䜜る必芁がなくなり、サむンむンからほが即座に実隓を始められるのが利点です。 AWS Step Functions が AgentCore を掻甚した゚ヌゞェント掚論ステップを远加 AWS Step Functions に、AI ゚ヌゞェントの掚論ステップをワヌクフロヌぞ盎接組み蟌める機胜が远加されたした。プレビュヌ䞭の Amazon Bedrock AgentCore Managed harness ず統合し、モデル・ツヌル・動䜜を蚭定で宣蚀しお゚ヌゞェントを定矩できたす。ポむントは、ドキュメントの分類や非構造化フォヌムからの芁玠抜出ずいった掚論タスクを自動化でき、耇数の゚ヌゞェントを䞊列・盎列でワヌクフロヌ内の刀断ポむントに配眮できる点です。重芁なアクションの前に人による承認ステップを挟むこずもでき、実行履歎で゚ヌゞェントの入出力・トヌクン䜿甚量・実行時間を確認し、Amazon CloudWatch で個々の刀断をトレヌス・監査できたす。統合自䜓に远加料金はかかりたせんが、ワヌクフロヌ実行には暙準の Step Functions 料金が、モデル掚論ず関連 AgentCore リ゜ヌスには暙準の Amazon Bedrock・AgentCore 料金が適甚されたす。提䟛は米囜東郚バヌゞニア北郚、米囜西郚オレゎン、欧州フランクフルト、アゞアパシフィックシドニヌの各リヌゞョンです。 Kiro トランスクリプトの゚クスポヌト、タヌミナルタむトル、モデル蚭定の氞続化 Kiro CLI 2.6 では、䜜業の持ち運びず玠早い再開に焊点を圓おた機胜が远加されたした。/transcript save で䌚話党䜓を markdown・プレヌンテキスト・JSON のいずれかで曞き出せるようになり、チヌムぞの共有やチケットぞの添付ができたす。/title でタヌミナルりィンドりにラベルを付けられるようになり、どのセッションがどこで動いおいるか把握しやすくなりたした。さらに /model ず /effort が遞択を自動的に蚘憶するようになり、䞀床倉曎すれば以降のセッションにも匕き継がれたす。起動時に掚論レベルを指定する –effort フラグlowmediumhighxhighmaxも远加され、簡単な怜玢は高速に保ち぀぀、耇雑な䜜業には最初から深い掚論を䜿えたす。 リポゞトリなしで開始、い぀でもモヌド切替 Kiro web で、GitHub リポゞトリを接続しなくおもセッションを開始できるようになりたした。たずやりたいタスクを蚘述し、必芁になったら埌からリポゞトリを接続する流れになりたす。たた、Vibe セッションの途䞭でも Autonomous モヌドに切り替えられるようになり、開始時だけでなく最初のプロンプト送信埌の任意のタむミングで゚ヌゞェントに䜜業を匕き枡せたす。最初からやり盎す必芁はありたせん。セッションのメッセヌゞには盞察的なタむムスタンプが衚瀺され、ホバヌで絶察時刻も確認できるため、長時間のタスクでむベントの発生時刻を远いやすくなっおいたす。 「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も匕き続き実斜䞭ですので怜蚎しおみおください。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 野間 愛䞀郎 (Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。最近燻補づくりにハマっおたす。
本ブログは “ Capacity-aware inference: Automatic instance fallback for SageMaker AI endpoints ” を翻蚳したものです。 組織が本番環境で生成 AI ワヌクロヌドをスケヌルさせおいく䞭で、信頌性の高い GPU コンピュヌトを確保するこずは、最も根匷い運甚䞊の課題の 1 ぀になっおいたす。倧芏暡蚀語モデル (LLM) やマルチモヌダルアヌキテクチャは特定のむンスタンスタむプを必芁ずし、そのキャパシティが利甚できない堎合、゚ンドポむントは 1 件のリク゚ストも凊理する前に倱敗しおしたいたす。 Amazon SageMaker AI でリアルタむム掚論゚ンドポむントを構築する際は、これたで䜜成時に単䞀のむンスタンスタむプを指定する必芁がありたした。そのむンスタンスタむプのキャパシティが䞍足しおいるず、゚ンドポむントは実行状態に到達できたせん。蚭定を曎新し、別のむンスタンスタむプを遞択しお再詊行する、ずいうサむクルをプロビゞョニングが成功するたで繰り返すこずになりたす。 本日、Amazon SageMaker AI は、新芏および既存の掚論゚ンドポむント向けに キャパシティ察応むンスタンスプヌル を導入したす。優先順䜍付きのむンスタンスタむプリストを定矩しおおけば、SageMaker AI はキャパシティが制玄されおいるずき (䜜成時、スケヌルアりト時、スケヌルむン時) に、自動的にそのリストを順に凊理したす。゚ンドポむントは手動の介入なしで、利甚可胜な AI むンフラ䞊にプロビゞョニングされたす。この機胜は、シングルモデル゚ンドポむント、掚論コンポヌネントベヌスの゚ンドポむント、非同期掚論゚ンドポむントで利甚できたす。 本蚘事では、むンスタンスプヌルの仕組みず、新芏゚ンドポむントの䜜成や既存゚ンドポむントの移行を含めた䜿い始め方に぀いお説明したす。 これたでの課題 SageMaker AI 掚論゚ンドポむント (リアルタむムたたは非同期) にモデルをデプロむするずき、単䞀のむンスタンスタむプを指定したす。そのむンスタンスタむプの利甚可胜なキャパシティがない堎合、゚ンドポむントの䜜成は倱敗したす。この制玄は、゚ンドポむントのラむフサむクルのあらゆる段階で珟れたす。 キャパシティ䞍足による゚ンドポむント䜜成倱敗 垌望するむンスタンスタむプが利甚できない堎合、SageMaker AI は Insufficient Capacity ゚ラヌを返したす。゚ンドポむントを皌働状態にするには代替のむンスタンスタむプを手動で詊行し続ける必芁があり、結果がわかるたで毎回かなりの時間を芁したす。 Auto Scaling がフリヌトを拡匵できない スケヌルアりトむベントが発生し、むンスタンスタむプにキャパシティが䞍足しおいる堎合、Auto Scaling は同じむンスタンスタむプを際限なくリトラむしたす。トラフィックが増加し続ける䞀方で、゚ンドポむントのサむズは珟状のたたです。 スケヌルダりンに優先順䜍の抂念がない 単䞀のむンスタンスタむプでは、優先 (preferred) ずフォヌルバック (fallback) のハヌドりェアずいう抂念がありたせん。すべおのむンスタンスが区別なく削陀候補ずなりたす。 オブザヌバビリティが集玄されおしたい、察凊に぀なげにくい Amazon CloudWatch メトリクスぱンドポむントレベルで集玄されたす。レむテンシやキャパシティの問題を調査する際、メトリクスは「䜕かがおかしい」こずは瀺しおも、「どのむンスタンスタむプが原因か」たでは瀺しおくれたせん。 優先順䜍ベヌスのむンスタンスプヌルの仕組み ゚ンドポむント蚭定の䞭で、 instance pools ず呌ばれるむンスタンスタむプの優先順䜍付きリストを定矩したす。SageMaker AI はキャパシティが制玄されたずきに、自動的にそのリストを順番に凊理したす。 ゚ンドポむントが立ち䞊がる SageMaker AI は最初の遞択肢のむンスタンスタむプを詊したす。キャパシティが利甚できない堎合、ただちに 2 番目の遞択肢、次に 3 番目の遞択肢を詊したす。手動でリトラむする必芁はありたせん。゚ンドポむントは数分以内に、最初に利甚可胜な AI むンフラ䞊で InService に到達したす。 ゚ンドポむントが皌働し続ける Auto Scaling がトリガヌされ、優先するむンスタンスタむプが制玄されおいる堎合、SageMaker AI は優先順䜍リストの次に利甚可胜なむンスタンスタむプでスケヌルアりトするため、トラフィックが流れ続けたす。 フリヌトは優先ハヌドりェアに収束する傟向を持぀ スケヌルむン時、SageMaker AI は最も優先床の䜎い (フォヌルバック) むンスタンスから先に削陀したす。その埌のスケヌルアりトむベントでは、再び最も優先床の高いタむプから詊行したす。優先するハヌドりェアが利甚可胜になるに぀れお、フリヌトは時間ずずもに自然にそちらぞ戻り、手動の介入は必芁ありたせん。 すべおを可芖化できる 既存のすべおの CloudWatch メトリクスに InstanceType ディメンションが远加されおいるため、1 ぀の゚ンドポむント内のむンスタンスタむプごずに、レむテンシ、スルヌプット、GPU 䜿甚率、むンスタンス数を远跡できたす。 詳现に぀いおは、 Amazon SageMaker AI のドキュメント を参照し、 GitHub のサンプルノヌトブック を詊しおみおください。 各むンスタンスタむプに適切なモデルを圓おる フォヌルバック先のむンスタンスタむプは、GPU メモリ、コンピュヌト性胜、アヌキテクチャが異なるこずがよくありたす。高メモリのマルチ GPU むンスタンス向けに最適化されたモデルが、より小さなシングル GPU のフォヌルバックで必ずしも動䜜するずは限りたせん。プヌルリスト内の各むンスタンスタむプを、正しく構成されたモデルずマッチングさせる方法は 2 ぀ありたす。 オプション 1: 自分で最適化したモデルを持ち蟌む タヌゲットのむンスタンスタむプがすでに分かっおいる堎合、それぞれに察しおモデルアヌティファクトを準備したす。プラむマリのハむ゚ンドむンスタンスでは、耇数 GPU にわたるテン゜ル䞊列を䜿うかもしれたせん。䞭䜍のフォヌルバックでは、掚論を高速化するために投機的デコヌディング (speculative decoding) を適甚するこずが考えられたす。最も優先床の䜎いフォヌルバックでは、メモリ予算に収めるために INT4 量子化を䜿うかもしれたせん。 各構成に぀いお個別の SageMaker AI モデルを䜜成し、それぞれの InstancePools ゚ントリ (Single Model Endpoint の堎合) たたはむンスタンスタむプごずの Specifications (InferenceComponent ベヌスの゚ンドポむントの堎合) で、 ModelNameOverride を䜿っお参照したす。SageMaker AI が優先床の䜎いプヌルにフォヌルバックするず、そのハヌドりェア甚に準備したモデルがデプロむされたす。 オプション 2: SageMaker AI 掚論レコメンデヌション機胜を䜿う 各ハヌドりェアタヌゲットを手動で最適化するのが手間な堎合は、 SageMaker AI 掚論レコメンデヌション によっおハヌドりェア固有の構成を生成できたす。ベヌスモデルを䞎えるず、投機的デコヌディングや量子化などの技術を䜿っお、タヌゲットのむンスタンスタむプ党䜓にわたる最適化された構成を SageMaker AI が生成したす。 レコメンデヌションゞョブはタヌゲットのむンスタンスタむプごずに 1 ぀の結果を返したす。各結果には AIRecommendationModelDetails のレスポンス内に ModelPackageArn ず InferenceSpecificationName が含たれおおり、それぞれ特定のハヌドりェア向けの構成を瀺しおいたす。䞡方のフィヌルドを䜿っお結果ごずに 1 ぀の SageMaker AI モデルを䜜成し、察応するプヌル゚ントリで ModelNameOverride を介しお参照したす。これはオプション 1 ず同じパタヌンですが、最適化䜜業はサヌビス偎が凊理したす。 MODEL_PACKAGE_ARN = "arn:aws:sagemaker:us-west-2:123456789012:model-package/MyModelPkgGroup/1" # AIRecommendationModelDetails の䞡フィヌルドを䜿っおむンスタンスタむプごずに 1 ぀のモデルを䜜成。 sm.create_model( ModelName="my-llm-for-p5", PrimaryContainer={ "ModelPackageName": MODEL_PACKAGE_ARN, "InferenceSpecificationName": "p5-48xlarge-optimized", }, ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerRole", ) sm.create_model( ModelName="my-llm-for-g6", PrimaryContainer={ "ModelPackageName": MODEL_PACKAGE_ARN, "InferenceSpecificationName": "g6-48xlarge-optimized", }, ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerRole", ) # その埌、埌述の「セットアップ」のずおり、プヌル゚ントリごずに ModelNameOverride で各モデルを参照する。 混圚フリヌトでの Auto Scaling Auto Scaling は、䜜成時に定矩したのず同じ優先順䜍ロゞックに埓いたす。スケヌルアりトはたず最も優先床の高いプヌルを詊し、キャパシティが利甚できない堎合は次のプヌルにフォヌルバックしたす。スケヌルむンは最も優先床の䜎いむンスタンスから先に削陀し、フリヌトが瞮小しおも優先するハヌドりェアを枩存したす。 加重スケヌリングメトリクスを構築する フリヌトには異なるスルヌプットキャパシティを持぀むンスタンスタむプが含たれおいるため、デフォルトの集玄メトリクスは実際の䜿甚状況を正しく衚珟できないこずがありたす。たずえば p5 むンスタンスが 18 件の同時リク゚ストを凊理し、g6 が 7 件凊理しおいるずき、これらの生の数倀を平均しお 12.5 にしおも、どちらのむンスタンスタむプの負荷も正確には反映されたせん。 CloudWatch のメトリクス蚈算 (metric math) を䜿うず、タむプごずの䜿甚率( per-type utilization ratios )に基づいた加重メトリクスを構築できたす。各項はそのタむプで芳枬された䞊列実行数を最倧キャパシティで割っお、0.0 〜 1.0 の倀を生成したす。それらの比率を平均するこずで、 TargetValue ず同じ 0.0 〜 1.0 のスケヌルでフリヌトレベルの䜿甚シグナルが埗られたす。 TargetValue を 0.7 に蚭定するず、「フリヌト内のすべおのむンスタンスタむプにわたる加重平均がキャパシティの 70% を超えたらスケヌルアりトする」ずいう意味になりたす。 aas = boto3.client("application-autoscaling") aas.put_scaling_policy( PolicyName="weighted-utilization-scaling", ServiceNamespace="sagemaker", ResourceId="endpoint/my-heterog-endpoint/variant/primary", ScalableDimension="sagemaker:variant:DesiredInstanceCount", PolicyType="TargetTrackingScaling", TargetTrackingScalingPolicyConfiguration={ "TargetValue": 0.7, # 加重フリヌト䜿甚率が 70% を超えたらスケヌルアりト "CustomizedMetricSpecification": { "Metrics": [ { "Id": "p5_concurrency", "MetricStat": { "Metric": { "Namespace": "AWS/SageMaker", "MetricName": "ConcurrentRequestsPerModel", "Dimensions": [ {"Name": "EndpointName", "Value": "my-heterog-endpoint"}, {"Name": "VariantName", "Value": "primary"}, {"Name": "InstanceType", "Value": "ml.p5.48xlarge"}, ], }, "Stat": "Average", }, "ReturnData": False, }, { "Id": "g6_concurrency", "MetricStat": { "Metric": { "Namespace": "AWS/SageMaker", "MetricName": "ConcurrentRequestsPerModel", "Dimensions": [ {"Name": "EndpointName", "Value": "my-heterog-endpoint"}, {"Name": "VariantName", "Value": "primary"}, {"Name": "InstanceType", "Value": "ml.g6.48xlarge"}, ], }, "Stat": "Average", }, "ReturnData": False, }, { "Id": "weighted_utilization", # タむプごずの䜿甚率比 = 芳枬倀 / 最倧キャパシティ、それを平均する "Expression": "(p5_concurrency / 20 + g6_concurrency / 8) / 2", "ReturnData": True, }, ], }, }, ) この匏の 20 ず 8 は、各むンスタンスタむプで枬定された最倧同時䞊列数です。この䟋では p5 は最倧 20 リク゚スト、g6 は最倧 8 リク゚ストを凊理したす。これらの倀は、負荷テストでお䜿いのモデルに぀いお枬定した最倧倀に眮き換えおください。次の衚は、トラフィックレベルごずにこのメトリクスがどう反応するかを瀺しおいたす。 トラフィックレベル p5 リク゚スト g6 リク゚スト 加重䜿甚率 アクション 䜎 5 2 (0.25 + 0.25) / 2 = 0.25 スケヌルむン äž­ 12 5 (0.60 + 0.63) / 2 = 0.61 維持 高 18 7 (0.90 + 0.88) / 2 = 0.89 スケヌルアりト タヌゲット付近 14 6 (0.70 + 0.75) / 2 = 0.73 タヌゲット付近 — 維持 泚 : すべおのむンスタンスタむプのスルヌプットキャパシティが同皋床のワヌクロヌドでは、既存のスケヌリングポリシヌを倉曎せずにそのたた䜿甚できたす。加重䜿甚率メトリクスは、プヌルメンバヌの GPU キャパシティが倧きく異なる堎合に最も䟡倀を発揮したす。 フリヌトをモニタリングする 既存のすべおの CloudWatch メトリクスに InstanceType ずいう新しいディメンションが远加されたした。 ModelLatency 、 ConcurrentRequestsPerModel 、 GPUUtilization 、 InstanceCount 、 InvocationsPerInstance を、1 ぀の゚ンドポむント内のハヌドりェアタむプごずに分解できたす。各むンスタンスタむプを独立しお远跡するダッシュボヌドやアラヌムを構築できたす。 DescribeEndpoint はプヌルごずの珟圚のむンスタンス数を返すため、フリヌトの構成を垞に把握できたす。 response = sm.describe_endpoint(EndpointName="my-heterog-endpoint") pools = response["ProductionVariants"][0]["InstancePools"] # 出力䟋: # [ # {"InstanceType": "ml.p5.48xlarge", "CurrentInstanceCount": 4}, # {"InstanceType": "ml.g6.48xlarge", "CurrentInstanceCount": 2}, # ] トラフィックルヌティング むンスタンスプヌルを䜿う゚ンドポむントでは、 ProductionVariant の RoutingConfig を蚭定するこずで、Least Outstanding Requests (LOR) ルヌティングを有効化するこずを掚奚したす。LOR は受信リク゚ストごずに、モデルコピヌあたり凊理䞭のリク゚ストが最も少ないむンスタンスぞルヌティングしたす。キャパシティの倧きいむンスタンスはリク゚ストを高速に凊理するためキュヌが速やかに解消され、定垞状態では凊理䞭のリク゚スト数が少なく保たれたす。これにより、手動の重み付け蚭定なしで、キャパシティの倧きいむンスタンスは自然に倚くのトラフィックを受け取るようになりたす。 "RoutingConfig": {"RoutingStrategy": "LEAST_OUTSTANDING_REQUESTS"} この蚭定がない堎合、゚ンドポむントはデフォルトで RANDOM ルヌティングを䜿甚し、むンスタンスの負荷に関係なくリク゚ストを均等に分散したす。プヌルメンバヌ間でスルヌプットキャパシティが倧きく異なる堎合、これは最適ではありたせん。詳现に぀いおは、 ProductionVariant API リファレンスの RoutingConfig を参照しおください。 曎新ずロヌルバック むンスタンスプヌルは、Blue/Green デプロむ ず ロヌリングデプロむ の䞡方をサポヌトしおいたす。 Blue/Green デプロむ  ã§ã¯ã€ãƒˆãƒ©ãƒ•ィックを切り替える前に、同じ優先順䜍ベヌスのフォヌルバックロゞックを䜿っお、新しい (グリヌン) フリヌト党䜓をプロビゞョニングしたす。ヘルスチェックがパスしたらトラフィックがカットオヌバヌされたす。倱敗した堎合は自動ロヌルバックによっおブルヌフリヌトが保持され、゚ンドポむントは終始 InService を維持したす。 ロヌリングデプロむ では、蚭定可胜なバッチ (䞀床に 5〜50% のむンスタンス) でフリヌトを曎新したす。Blue/Green 党䜓ほどの远加キャパシティを必芁ずしないため、特に倧芏暡モデルや需芁の高い GPU むンスタンスタむプで䟡倀がありたす。SageMaker AI は新しい各バッチをプロビゞョニングする際に、優先順䜍ベヌスのフォヌルバックロゞックを適甚したす。ベヌキング期間䞭に CloudWatch のアラヌムが発火した堎合、トラフィックは自動的にロヌルバックされたす。蚭定の詳现は Use rolling deployments を参照しおください。 前提条件 開始する前に、以䞋を確認しおください。 sagemaker:CreateEndpointConfig 、 sagemaker:CreateEndpoint 、 sagemaker:UpdateEndpoint の IAM 暩限を持぀ AWS アカりント Amazon S3 にアヌティファクトを持぀少なくずも 1 ぀の SageMaker モデル Boto3 1.43.1 以降 (Python SDK での InstancePools サポヌトのため) (任意) タヌゲットのむンスタンスタむプごずに最適化された個別のモデルアヌティファクト、たたは SageMaker AI 掚論レコメンデヌション からの ModelPackage SageMaker AI 掚論゚ンドポむントのむンスタンスプヌルサポヌトは、すべおの商甚 AWS リヌゞョンで利甚可胜です。 AWS マネゞメントコン゜ヌル 、AWS Command Line Interface (AWS CLI)、たたは AWS SDK から始められたす。 むンスタンスプヌルで゚ンドポむントを構成するワヌクフロヌ むンスタンスプヌルを構成する方法は 2 ぀ありたす。Amazon SageMaker AI で新芏゚ンドポむントを䜜成する堎合ず、既存の゚ンドポむントを移行する堎合の 2 通りです。 新芏゚ンドポむントを䜜成する堎合、以䞋の図がワヌクフロヌを説明したす。 むンスタンスタむプを遞択し、優先順䜍を割り圓おる (1 が最高)。 各むンスタンスタむプ向けに最適化したモデルを準備する、たたは SageMaker AI 掚論レコメンデヌションを実行しお生成する。 優先順䜍を持぀ InstancePools をリスト化した゚ンドポむント蚭定を䜜成する。 ゚ンドポむントを䜜成する。SageMaker AI が自動的にキャパシティの確保を凊理する。 新しい InstanceType ディメンションを䜿っお、むンスタンスタむプごずの CloudWatch モニタリングを蚭定する。 既存の゚ンドポむントを移行する堎合、以䞋の図がワヌクフロヌを説明したす。 新しい゚ンドポむント蚭定を䜜成する。 InstanceType を InstancePools に眮き換え、珟圚のむンスタンスタむプを Priority: 1 に保぀。 UpdateEndpoint を呌び出す。゚ンドポむントは Blue/Green 移行䞭も InService を維持する。 フォヌルバック先のむンスタンスタむプ間でスルヌプットキャパシティが倧きく異なる堎合は、加重䜿甚率スケヌリングメトリクスを任意で远加する。 セットアップ むンスタンスプヌルの導入は、゚ンドポむント蚭定の 1 フィヌルドを倉曎するだけで枈みたす。 ProductionVariant の単䞀の InstanceType フィヌルドを InstancePools リストに眮き換えおください。モデル、スケヌリングポリシヌ、モニタリングダッシュボヌドは倉曎なしで動䜜し続けたす。 既存゚ンドポむントの移行 移行前: 単䞀むンスタンスタむプ import boto3 sm = boto3.client("sagemaker") sm.create_endpoint_config( EndpointConfigName="my-config", ProductionVariants=[{ "VariantName": "primary", "ModelName": "my-llm", "InitialInstanceCount": 2, "InstanceType": "ml.g6e.48xlarge", # 単䞀タむプ — キャパシティフォヌルバックなし }], ) 移行埌: 優先順䜍付きむンスタンスプヌル sm.create_endpoint_config( EndpointConfigName="my-config-v2", ProductionVariants=[{ "VariantName": "primary", "ModelName": "my-llm", "InitialInstanceCount": 2, "VariantInstanceProvisionTimeoutInSeconds": 1200, # 埌述の泚を参照 "InstancePools": [ {"InstanceType": "ml.g6e.48xlarge", "Priority": 1}, # 珟圚のタむプ {"InstanceType": "ml.g6.48xlarge", "Priority": 2}, # 同ファミリ、最初のフォヌルバック {"InstanceType": "ml.p4d.24xlarge", "Priority": 3}, # より広いフォヌルバック ], }], ) Blue/Green 移行䞭も゚ンドポむントは InService を維持したす。 sm.update_endpoint( EndpointName="my-endpoint", EndpointConfigName="my-config-v2", ) 泚 : VariantInstanceProvisionTimeoutInSeconds は、むンスタンスプヌルサポヌトで導入された新しいフィヌルドです。プヌルからむンスタンスを調達する党䜓の時間枠を蚭定したす。SageMaker AI はこの時間枠の䞭で Insufficient Capacity ゚ラヌに察しおリトラむを続け、タむムアりト埌に次のプヌルぞ移りたす。有効な範囲は 300 〜 3600 秒です。倧芏暡 GPU むンスタンスタむプでは、1200 秒が劥圓な開始倀です。このタむマヌはむンスタンス調達のみをカバヌしたす。モデルダりンロヌドずコンテナ起動時間は、既存の ModelDataDownloadTimeoutInSeconds ず ContainerStartupHealthCheckTimeoutInSeconds フィヌルドで個別に管理されたす。むンスタンスタむプごずに異なる最適化枈みモデルをデプロむするには、任意のプヌル゚ントリに ModelNameOverride を远加したす。モデル蚭定オプションは前のセクションで確認できたす。 InferenceComponent ベヌスの゚ンドポむント sm.create_inference_component( InferenceComponentName="my-ic", EndpointName="my-heterogeneous-endpoint", VariantName="primary", Specifications=[ { "InstanceType": "ml.p5.48xlarge", "ModelName": "my-model-p5-optimized", "ComputeResourceRequirements": { "NumberOfAcceleratorDevicesRequired": 8, "MinMemoryRequiredInMb": 65536, }, }, { "InstanceType": "ml.g6.48xlarge", "ModelName": "my-model-g6-optimized", "ComputeResourceRequirements": { "NumberOfAcceleratorDevicesRequired": 8, "MinMemoryRequiredInMb": 32768, }, }, ], RuntimeConfig={"CopyCount": 4}, ) 非同期掚論゚ンドポむント 非同期掚論 ゚ンドポむントでもむンスタンスプヌルは同じように動䜜したす。 InstancePools の定矩ず䞊べお CreateEndpointConfig の呌び出しに AsyncInferenceConfig ブロックを远加するだけで、優先順䜍ベヌスのプロビゞョニングずフォヌルバックロゞックがそのたた適甚されたす。これは、むンスタンス数 0 たでスケヌルダりンする非同期ワヌクロヌドで特に有甚です。゚ンドポむントが再びスケヌルアップしおキュヌむングされたリク゚ストを凊理する際、SageMaker AI はたず最も優先床の高い利甚可胜なプヌルを䜿っおプロビゞョニングし、手動介入なしで耐障害性のあるコヌルドスタヌト挙動を提䟛したす。 たずめ Amazon SageMaker AI Instance Pools は、掚論゚ンドポむント向けにむンスタンスタむプの優先順䜍付きリストを定矩するこずを可胜にし、SageMaker AI がその順序に基づいおキャパシティを自動的に管理したす。 ゚ンドポむント䜜成時、スケヌルアりト時、スケヌルむン時にわたっお、SageMaker AI は優先するむンスタンスタむプを順に凊理するため、第 1 候補のハヌドりェアが利甚できないずきでもデプロむを手動でリトラむする必芁がありたせん。始め方は簡単です。゚ンドポむント蚭定の InstanceType を InstancePools に眮き換えお UpdateEndpoint を呌び出したす。既存のモデル、Auto Scaling ポリシヌ、モニタリングダッシュボヌドは倧きな倉曎なしに動䜜し続けたす。 むンスタンスタむプごずの CloudWatch メトリクスず DescribeEndpoint からの詳现なプヌル数によっお、どのむンスタンスタむプがフリヌトを支えおいるかをリアルタむムに明確に把握できたす。コスト最適化、GPU キャパシティ制玄ぞの察応、れロからコヌルドスタヌト可胜な耐障害性の高い非同期パむプラむンの構築など、どの目的であっおも、むンスタンスプヌルは運甚負荷を抑えながら ML 掚論をスムヌズに動かし続けるための柔軟性ず自動化を提䟛したす。 この機胜は本日から远加費甚なしで利甚可胜です。実際にプロビゞョニングされたむンスタンスタむプに察しおは、暙準の単䞀タむプ゚ンドポむントず同じ料率で課金されたす。詳现に぀いおは、 Amazon SageMaker AI のドキュメント ず GitHub のサンプルノヌトブック を参照しおください。 著者に぀いお Kareem Syed-Mohammed Kareem Syed-Mohammed は AWS のプロダクトマネヌゞャヌです。SageMaker HyperPod 䞊での生成 AI モデル開発ずガバナンスの実珟に泚力しおいたす。それ以前は Amazon QuickSight で組み蟌み分析ず開発者゚クスペリ゚ンスをリヌドしたした。QuickSight に加えお、AWS Marketplace ず Amazon Retail でもプロダクトマネヌゞャヌを務めおきたした。Kareem はコヌルセンタヌ技術の開発者ずしおキャリアをスタヌトし、Expedia の Local Expert ず広告、McKinsey の経営コンサルタントずしおの経歎を持ちたす。 Dmitry Soldatkin Dmitry Soldatkin は AWS の SageMaker Inference におけるスペシャリスト゜リュヌションアヌキテクチャのワヌルドワむドリヌダヌです。゚ンタヌプラむズ党䜓にわたる生成 AI および AI/ML ゜リュヌションの蚭蚈、構築、最適化を支揎する取り組みを率いおいたす。圌の仕事は幅広い ML ナヌスケヌスに及び、生成 AI、ディヌプラヌニング、倧芏暡な ML のデプロむメントに重点を眮いおいたす。金融サヌビス、保険、通信などの業界の䌁業ず協業しおきたした。Dmitry ずは LinkedIn で぀ながるこずができたす。 Johna Liu Johna Liu は Amazon SageMaker チヌムの゜フトりェア開発゚ンゞニアです。効率を高め新たな機胜を可胜にする AI/LLM 駆動のツヌルを構築し探求しおいたす。仕事以倖では、テニス、バスケットボヌル、野球を楜しんでいたす。 Xu Deng Xu Deng は SageMaker チヌムの゜フトりェア゚ンゞニアリングマネヌゞャヌです。Amazon SageMaker 䞊でお客様の AI/ML 掚論䜓隓の構築ず最適化を支揎するこずに泚力しおいたす。䜙暇には旅行ずスノヌボヌドを楜しんでいたす。 Mona Mona Mona Mona は珟圚、Amazon でシニア AI/ML スペシャリスト゜リュヌションアヌキテクトずしお勀務しおいたす。以前は Google でリヌド生成 AI スペシャリストずしお働いおいたした。『Natural Language Processing with AWS AI Services: Derive strategic insights from unstructured data with Amazon Textract and Amazon Comprehend』および『Google Cloud Certified Professional Machine Learning Study Guide』の 2 冊の著者であり、AI/ML ずクラりド技術に関する 19 本のブログを執筆、CORD19 Neural Search に関する研究論文の共著者ずしお、暩嚁ある AAAI (Association for the Advancement of Artificial Intelligence) カンファレンスで Best Research Paper 賞を受賞しおいたす。 翻蚳は Solutions Architect 片山掋平 が担圓したした。原文は こちら です。
本ブログは 2026幎 5月 1日に公開された、 Security posture improvement in the AI era を翻蚳したものです。 Anthropic が Claude Mythos Preview モデルを発衚し、AWS およびその他の䞻芁組織ず共に Project Glasswing を立ち䞊げおから、ただ数週間しか経っおいたせん。これにより、サむバヌセキュリティの将来ず、基盀モデルの胜力が急速に向䞊するこずが組織にずっお䜕を意味するのかに぀いお、倚くの議論が生たれおいたす。 AWS CISO の Amy Herzog が Project Glasswing の 発衚 で指摘したように、「AWS では、カスタムシリコンからテクノロゞヌスタック党䜓にわたっお、脅嚁が顕圚化する前に防埡を構築しおいたす。セキュリティは私たちにずっお単なる䞀フェヌズではなく、継続的にすべおの取り組みに組み蟌たれおいるものです。」 この詳现に぀いおは、Amy が執筆した Building AI defenses at scale: Before the threats emerge をご芧ください。 サむバヌセキュリティの将来に぀いおの議論は重芁ですが、確実に蚀えるこずは、AI がテクノロゞヌやビゞネス党般にもたらす急速な倉化に、組織が迅速に察応できる必芁があるずいうこずです。そしお、セキュリティの基本が確立されおいなければ、迅速な察応は䞍可胜です。 セキュリティ基本察策のギャップ 基本的なセキュリティ芁玠がカバヌされおいるず思い蟌んだり、䞀郚を芋萜ずしたりするこずは珍しくありたせん。アむデンティティ管理、脅嚁怜出、脆匱性管理、デヌタ保護、ネットワヌクセキュリティずいった基本的なセキュリティのナヌスケヌスは、クラりド環境党䜓で䞀貫しお実装されおいないこずがありたす。AI がセキュリティの状況を倉革し぀぀ある䞭でも、匷固なセキュリティの基瀎は、芏暡や業皮を問わず、すべおの組織にずっお匕き続き䞍可欠です。 これらは、AI を導入するかどうかに関わらず重芁なセキュリティの基本事項です。具䜓的には、䞀貫したパッチ適甚、最小暩限アクセスの培底、ログ蚘録ずモニタリングの有効化、保存デヌタおよび転送䞭デヌタの暗号化、そしお定期的なセキュリティ蚭定のレビュヌが挙げられたす。これらの基本事項が敎っおいれば、AI 駆動のツヌルを掻甚し、発芋元を問わず新たに発芋された脆匱性に察応できる䜓制が敎いたす。 セキュリティの基本原則は普遍的なものですが、実際の環境ぞの適甚は、組織固有のコンテキストを理解した䞊で行うこずが重芁です。そのため、 AWS Well-Architected Framework など、適切な質問を行い環境に倉曎を加えるために掻甚できる倚数の無償資料を提䟛しおいたす。たた、 Security Health Improvement Program (SHIP) のようなプログラムも提䟛しおおり、具䜓的なガむダンスず継続的な改善を通じおセキュリティ䜓制の向䞊を支揎しおいたす。 Security Health Improvement Program (SHIP) ずは SHIP は、サポヌトティアに関わらず、すべおの AWS のお客様が無償で利甚できるプログラムです。SHIP は、以䞋を実珟するための実瞟ある、デヌタ䞻導の方法論を提䟛したす。 AWS 環境のデヌタを䜿甚しお、珟圚のセキュリティ䜓制を評䟡する 10 のコアセキュリティナヌスケヌスにわたる具䜓的な改善機䌚を特定する 環境に合わせた優先床付きアクションプランを構築する 継続的なセキュリティ改善のための仕組みを確立する このプログラムは、AWS ゜リュヌションアヌキテクトずテクニカルアカりントマネヌゞャヌが䞻導し、パヌ゜ナラむズされたレポヌトを通じおご案内し、お客様の環境に合わせた調査結果の解説ず、優先順䜍付けされたアクションプランの策定をサポヌトしたす。 AI 時代における SHIP の重芁性 Project Glasswing は重芁な倉化を浮き圫りにしおいたす。AI を掻甚したツヌルが脆匱性の発芋を加速させおおり、組織はこれたで以䞊に迅速に調査結果や倉化する状況を評䟡・察応できる䜓制を敎える必芁がありたす。倖郚芁因に加え、組織が基盀モデルのデプロむ、゚ヌゞェント型ワヌクフロヌの構築、AI を掻甚したサヌビスの利甚など、AI を採甚するにあたっお、セキュリティコントロヌルの実装方法も倉えおいく必芁がありたす。匷固なセキュリティ基盀こそが、自信を持っお AI を採甚するための土台ずなりたす。 SHIP がどのように圹立぀かを以䞋に瀺したす。 基盀ずなるセキュリティのギャップに先手を打っお察凊する SHIP は、デヌタ䞻導の手法を甚いお、脅嚁怜出、クラりドセキュリティ態勢管理、アプリケヌションセキュリティテスト、構成管理、アクセスガバナンス、脆匱性管理、アプリケヌション保護、ネットワヌクセキュリティ、暗号化、シヌクレット管理ずいう 10 のコアセキュリティナヌスケヌスにわたる改善・最適化の機䌚を特定したす。このプログラムには、珟圚のセキュリティ態勢に関連する重芁なセキュリティ䞊の問題を特定するための SHIP アセスメントが含たれおおり、チヌムがお客様の環境に合わせた優先床付きの改善ロヌドマップを構築できるようになりたす。 AI ワヌクロヌドに必芁なセキュリティベヌスラむンを確立する Amazon Bedrock に最初のモデルをデプロむする前、あるいは Amazon Bedrock AgentCore で゚ヌゞェント型ワヌクフロヌを構築する前に、基盀ずなるむンフラストラクチャがセキュリティのベストプラクティスに埓っおいるこずを確認する必芁がありたす。SHIP は、汎甚的なセキュリティ掚奚事項ではなく、お客様の環境から取埗した実際のデヌタを䜿甚しお、具䜓的な指針を提䟛したす。AI を掻甚した脆匱性発芋ツヌルがより広く普及し぀぀ある珟圚、これは特に重芁です。匷固なベヌスラむンを持぀組織は、新たな発芋事項に察しお迅速か぀効果的に察応できるようになりたす。 継続的なセキュリティ改善のための仕組みを構築する AI の胜力が進化するに぀れ、組織はセキュリティ䜓制を継続的に評䟡・匷化するための再珟可胜なプロセスを持぀こずで恩恵を受けられたす。SHIP は、チヌムが継続的に評䟡、優先順䜍付け、改善を行うための方法論ずメカニズムを確立したす。この運甚胜力を構築するこずで、組織の適応力が匷化され、業界党䜓のレゞリ゚ンス向䞊にも貢献できたす。サむバヌセキュリティコミュニティが AI を防埡戊略に統合しおいく䞭で、SHIP は基本的なベストプラクティスの維持を支揎し、これらのむノベヌションを効果的か぀自信を持っお採甚できるようにしたす。 始め方はシンプルです SHIP は珟圚、すべおの AWS のお客様に無料でご利甚いただけたす。始め方は以䞋の通りです。 AWS アカりントチヌムにご盞談ください。 SHIP ゚ンゲヌゞメントのスケゞュヌル調敎に぀いおご盞談いただくか、 SHIP ペヌゞ から盎接リク゚ストしおください。 SHIP Activation Day に参加しおください。 AWS では定期的にハンズオンワヌクショップを開催しおおり、AWS ゜リュヌションアヌキテクトず共に SHIP アセスメントを実斜し、改善蚈画の策定を開始できたす。 具䜓的なガむダンスを参照しおください。 今すぐ掻甚できるドキュメント、リファレンスアヌキテクチャ、および実装ガむドに぀いおは、 AWS Well-Architected Framework – Security Lens をご参照ください。 次のステップを共に螏み出したしょう AWS は、Project Glasswing ぞの参加から、むンフラストラクチャのあらゆる局に組み蟌たれたセキュリティに至るたで、最もセキュアなクラりドであり続けるこずに取り組んでいたす。セキュリティは共有責任であり、SHIP のようなプログラムは、お客様がセキュリティの基盀を匷化するためのツヌル、ガむダンス、サポヌトを提䟛したす。これにより、お客様はどのような状況においおも自信を持っお構築できるようになりたす。 セキュリティ䜓制を匷化する準備はできおいたすか SHIP ゚ンゲヌゞメントのスケゞュヌルを組むには AWS アカりントチヌムにお問い合わせいただくか、詳现に぀いおは SHIP リ゜ヌスペヌゞ をご芧ください。 Celeste Bishop Celeste is a Senior Security Specialist at AWS, based in Austin, Texas. Over the past five years, she has held a range of security-focused roles spanning field and product marketing, developer relations, and executive engagement. She partners closely with customers, security leaders, and field teams to help organizations operate securely in the cloud. Celeste holds a Bachelor’s in Economics from the University of Texas at Austin. 翻蚳は Solutions Architect の 日吉 康仁、束厎 博昭 が担圓したした。
りェブアプリケヌションおよびモバむルアプリのデベロッパヌず連携するデベロッパヌアドボケヌトずしお、私は、リヌゞョンレベルのサヌビスが䞇が䞀䞭断した堎合に備えお、䞀貫したナヌザヌ認蚌を維持する必芁性に぀いお、しばしば耳にしおきたした。゚ヌゞェンティック AI、マむクロサヌビス、オヌトメヌション、サヌビスアカりントの利甚拡倧に䌎っお、マシン間認蚌に぀いおの同様のニヌズが高たっおいたす。本日、Amazon Cognito の 2 ぀の重芁なアップデヌトに぀いおお知らせしたす。1 ぀は回埩力を高めるための マルチリヌゞョンレプリケヌション 、もう 1 ぀は暗号化コントロヌルをより詳现に制埡できる カスタマヌマネヌゞドキヌ のサポヌトです。 倚くのアプリケヌションは、ナヌザヌ認蚌およびマシン間認蚌の凊理やナヌザヌプロファむルの管理に Amazon Cognito を利甚しおいたす。高可甚性を実珟するために構築するには、異なる AWS リヌゞョン間でデヌタの䞀貫性を実珟するこずが䞍可欠ですが、これたでその䞀貫性を実珟するには倧きな課題が䌎っおいたした。゚ンゞニアリングチヌムは、リヌゞョン間で蚭定を同期するために、カスタムレプリケヌション゜リュヌションの構築ず維持に倚倧な時間を費やしおいたした。リヌゞョン間でのナヌザヌデヌタの手動゚クスポヌトずむンポヌトは、朜圚的なデヌタ挏えいによるセキュリティリスクを生み出し、デヌタの䞍敎合を匕き起こす可胜性をはらんでいたした。リヌゞョンレベルの移行時には、゚ンドナヌザヌは、匷制パスワヌドリセットや再認蚌などの䞭断を経隓しおいたした。マシン間通信では、チヌムは、セカンダリリヌゞョンで新しいアプリケヌションクラむアントを䜜成する必芁があり、そのためにはアプリケヌションを再蚭定し、新しいリヌゞョンレベルの発行者によっお発行されたアクセストヌクンを受け入れるように OAuth で保護されたリ゜ヌスを曎新する必芁がありたした。これらの課題により、リヌゞョン間で䞭断のない運甚を維持するこずが困難ずなっおいたした。 マルチリヌゞョンレプリケヌションを䜿甚するこずで、Amazon Cognito は、任意のセカンダリ AWS リヌゞョンにナヌザヌデヌタずマシンシヌクレットの同期コピヌを自動的に維持したす。レプリケヌションは、プラむマリリヌゞョンからセカンダリリヌゞョンぞの䞀方向で行われたす。これには、ナヌザヌプロファむル、認蚌情報、およびプヌル蚭定が含たれたす。セカンダリリヌゞョンは読み取り専甚モヌドで動䜜し、認蚌機胜の維持に重点を眮きたす。既存のセッションは䞭断されずに継続されたす。 トラフィックをセカンダリリヌゞョンにルヌティングする必芁がある堎合、既存のナヌザヌは、䞭断なく既存の認蚌情報を䜿甚しおサむンむンを継続でき、珟圚サむンむンしおいるナヌザヌは、䞡方のリヌゞョンがどちらのリヌゞョンによっお発行されたアクセストヌクンも認識するため、認蚌された状態が維持されたす。マルチリヌゞョンレプリケヌションは、゜ヌシャルプロバむダヌ (Amazon、Google、Apple、Facebook) を通じたフェデレヌションサむンむン、Security Assertion Markup Language (SAML) ず OpenID Connect (OIDC) の統合、API 認蚌フロヌなど、すべおの認蚌方法をサポヌトしたす。このアプロヌチにより、顧客向けアプリケヌションずバック゚ンドサヌビスにおけるマシン間通信の䞡方で可甚性が維持されたす。認蚌は䞭断なく継続されたすが、フェむルオヌバヌ䞭は新芏ナヌザヌ登録やプロファむル曎新などの操䜜は利甚できたせん。 マルチリヌゞョンレプリケヌションを蚭定する前に、 AWS Key Management Service (AWS KMS) に保存されおいるマルチリヌゞョンカスタマヌマネヌゞドキヌを蚭定し、保管䞭のナヌザヌデヌタを暗号化する必芁がありたす。これらのキヌは、リヌゞョン間で䞀貫した暗号化を提䟛するず同時に、暗号化戊略を制埡できるようにしたす。 実際の動䜜 us-west-2 (オレゎン) リヌゞョンにある既存の Cognito ナヌザヌプヌルを䜿甚しおこのデモを開始したす。 us-east-1 (バヌゞニア北郚) ぞのレプリケヌションを蚭定したいず考えおいたす。たた、これらの 2 ぀のリヌゞョンにレプリケヌトされたカスタマヌマネヌゞドキヌもありたす。 マルチリヌゞョンレプリケヌションの蚭定は、わずか 3 ぀のステップで完了したす。 AWS マネゞメントコン゜ヌル は、暗号化のためのカスタムキヌの蚭定、マルチリヌゞョン OIDC ゚ンドポむントの蚭定、レプリケヌション自䜓の蚭定ずいうステップを通じおガむドしおくれたす。 たず、保管䞭のデヌタを暗号化するためにカスタム AWS KMS キヌをセットアップしたす。 䜜成したカスタムキヌを遞択したす。たた、Amazon Cognito がキヌにアクセスしお䜿甚できるように、キヌポリシヌを曎新したす。コン゜ヌルには、キヌポリシヌに远加すべき正しい IAM ポリシヌステヌトメントが衚瀺されたす。 カスタムキヌが遞択され、正しく蚭定されたこずをコン゜ヌルが確認したす。 次に、コン゜ヌルの指瀺に埓っお OIDC 発行者タむプを蚭定したす。 [ステップ 2 – オプション] で、 [蚭定] を遞択したす。 これらの新しい゚ンドポむントを䜿甚しおクラむアントアプリケヌションを曎新したす。これは必須の倉曎であり、サヌバヌ偎のアプリケヌションの再デプロむず、App Store および Google Play におけるモバむルアプリの曎新申請が必芁ずなりたす。゚ンドポむントを曎新しないず、叀い゚ンドポむントに察するリク゚ストが正しくルヌティングされなくなるため、ナヌザヌに障害が発生したす。 次の画面で、 [曎新枈み] を遞択したす。新しい URL をメモしおおきたす。倉曎内容を確認し、 [発行者タむプを倉曎] を遞択したす。 最埌に、レプリケヌションのタヌゲットリヌゞョンを遞択したす。カスタム暗号化キヌがレプリケヌトされおいるリヌゞョンのみを遞択できたす。タヌゲットリヌゞョンを遞択したら、 [䜜成] を遞択したす。 サヌビスがレプリケヌションのために準備したす。必芁な時間は、ナヌザヌプヌル内のデヌタ量によっお異なりたす。 レプリケヌトされたナヌザヌプヌルの準備が敎ったら、手動で [アクティブ化] したす。 レプリケヌションステヌタスは [アクティブ] になりたす。これで、トラフィックをレプリカにルヌティングする準備が敎いたした。 远加の蚭定 コン゜ヌルは、蚈画する必芁のある远加の蚭定を远跡するのに圹立ちたす。たた、 カスタム認蚌フロヌ や SMS たたは E メヌル通知のために Lambda 関数 を䜿甚する堎合は、新しいリヌゞョンでこれらのリ゜ヌスをデプロむしお蚭定する必芁がありたす。 同様に、認蚌トラフィックをタヌゲットリヌゞョンにルヌティングする前に、ログストリヌミングや AWS WAF の蚭定をそのタヌゲットリヌゞョンで手動蚭定する必芁がありたす。 ヘルスチェックずフェむルオヌバヌ プラむマリリヌゞョンレベルずセカンダリリヌゞョンレベルの゚ンドポむントは、垞にアクティブな状態を維持し、い぀でもトラフィックを凊理できる準備が敎っおいたす。システムの正垞性をモニタリングし、フェむルオヌバヌを管理するには、アプリケヌション固有の芁件ずセキュリティ䜓制に敎合的な戊略を蚭蚈する必芁がありたす。ヘルスチェックを実装するこずで、プラむマリリヌゞョンの認蚌サヌビスのステヌタスをモニタリングし、フェむルオヌバヌを開始する条件を定矩できたす。これらのチェックでは、゚ラヌ率、レむテンシヌパタヌン、特定のサヌビスアラヌトなどを確認できたす。 モニタリングシステムがフェむルオヌバヌの条件を満たす問題を怜出した堎合、DNS 曎新を通じおトラフィックをセカンダリリヌゞョンにリダむレクトできたす。このアプロヌチにより、セキュリティを維持しながら、フェむルオヌバヌプロセスを制埡できたす。ピヌク時以倖の時間垯に、トラフィックの䞀郚をリダむレクトし、セカンダリリヌゞョンで認蚌が想定どおりに機胜し続けるこずを怜蚌するこずで、フェむルオヌバヌ戊略をテストするこずをお勧めしたす。 カスタムドメむンでマネヌゞドログむンずフェデレヌションを䜿甚する堎合、 Amazon Route 53 ヘルスチェック ID を指定するこずで、組み蟌みのトラフィックルヌティング機胜も利甚できたす。 料金ず利甚可胜なリヌゞョン マルチリヌゞョンレプリケヌションは、Essentials および Plus 階局をご利甚の Amazon Cognito のお客様向けのアドオン機胜ずしお、本日よりご利甚いただけたす。ナヌザヌ認蚌では、アドオン料金は、Essentials 階局のお客様の堎合、レプリカリヌゞョンごずに月間アクティブナヌザヌあたり 0.0045 USD、Plus 階局のお客様の堎合、レプリカリヌゞョンごずに月間アクティブナヌザヌあたり 0.006 USD です。マシン間 (M2M) 認蚌では、アドオンに぀いおは、正垞に発行されたトヌクンの暙準ボリュヌムベヌス料金に 30% が加算されたす。料金に関する詳现に぀いおは、 「Amazon Cognito の料金」をご芧ください 。 マルチリヌゞョンレプリケヌションは珟圚、米囜東郚 (オハむオ、バヌゞニア北郚)、米囜西郚 (カリフォルニア北郚、オレゎン)、アゞアパシフィック(ムンバむ、゜りル、シンガポヌル、シドニヌ、東京)、カナダ (䞭郚)、欧州 (フランクフルト、アむルランド、ロンドン、パリ、ストックホルム)、南米 (サンパりロ) のリヌゞョンでご利甚いただけたす。 これらのリヌゞョンはいずれも、レプリケヌション元たたはレプリケヌション先ずしお䜿甚できたす。 Essentials および Plus 階局では、カスタマヌマネヌゞドキヌのサポヌトをご利甚いただけたす。次のリヌゞョンでご利甚いただけたす: 米囜東郚 (オハむオ、バヌゞニア北郚)、米囜西郚 (北カリフォルニア、オレゎン)、アフリカ (ケヌプタりン)、アゞアパシフィック (銙枯、ハむデラバヌド、ゞャカルタ、マレヌシア、メルボルン、ムンバむ、ニュヌゞヌランド、倧阪、゜りル、シンガポヌル、シドニヌ、タむ、東京)、カナダ (䞭郚)、カナダ西郚 (カルガリヌ)、欧州 (フランクフルト、アむルランド、ロンドン、ミラノ、パリ、スペむン、ストックホルム、チュヌリッヒ)、むスラ゚ル (テルアビブ)、メキシコ (䞭郚)、南米 (サンパりロ)、および AWS GovCloud (米囜東郚、米囜西郚) お客様ずの䌚話から、リヌゞョンレベルのむンシデントの発生時であっおも、セキュリティ芁件を満たしながら事業継続性を維持するこずが優先事項であるこずがわかりたした。マルチリヌゞョンレプリケヌションにより、耇雑なレプリケヌションロゞックを自瀟で管理するこずなく、より堅牢なアプリケヌションを構築できたす。ナヌザヌデヌタず蚭定の自動同期により、セキュリティを維持しながら運甚䞊のオヌバヌヘッドを削枛できたす。 芏制が厳しい業界のお客様向けに、カスタマヌマネヌゞドキヌの新たなサポヌトは、デヌタ暗号化に察する远加のコントロヌルを提䟛したす。独自の暗号化キヌを䜿甚しお保管䞭のナヌザヌデヌタを保護できるようになりたした。これは、ヘルスケアや金融サヌビスなどの業界における芏制芁件に察応するのに圹立ちたす。 マルチリヌゞョンレプリケヌションずカスタマヌマネヌゞドキヌ暗号化の䜿甚を開始するには、 Amazon Cognito コン゜ヌル にアクセスしおください。たた、詳现なセットアップ手順に぀いおは、 ドキュメント をご芧ください。この機胜を掻甚しおアプリケヌションアヌキテクチャを匷化する方法に぀いお、ぜひお聞かせください。 – seb 原文は こちら です。
「What’s Next with AWS 2026」でプレビュヌしたずおり 、 Amazon Bedrock における OpenAI の GPT-5.5 モデル、GPT-5.4 モデル、および Codex の䞀般提䟛の開始をお知らせしたす。これにより、フロンティアモデルず゜フトりェア開発のためのコヌディング゚ヌゞェントにアクセスできるようになりたす。 OpenAI によるず、GPT-5.5 モデルず GPT-5.4 モデルは、コヌディング、掚論、゚ヌゞェンティックワヌクフロヌ、耇雑か぀専門的な業務で優れたパフォヌマンスを発揮したす。極めお負荷の高いワヌクロヌドでは GPT-5.5 を、料金パフォヌマンスを重芖する堎合は GPT-5.4 を利甚できたす。これらのモデルは、高いパフォヌマンスず信頌性、および匷力なセキュリティを実珟するために構築された Amazon Bedrock の次䞖代掚論゚ンゞン䞊で、 Responses API を通じお呌び出すこずができたす。 Codex は、AI を利甚した゜フトりェア開発のための OpenAI コヌディング゚ヌゞェントです。OpenAI によるず、毎週 400 䞇を超えるデベロッパヌが Codex を䜿甚しお、倧芏暡なコヌドベヌス党䜓で、コヌドの蚘述、リファクタリング、デバッグ、テスト、怜蚌を行っおいたす。GPT-5.5 を利甚する掚論を備えた Codex は、耇雑で長期的なデベロッパヌワヌクフロヌ向けに最適化された、新しいクラスのむンテリゞェンスを提䟛したす。Codex アプリ、Codex CLI、および Visual Studio Code、JetBrains、Xcode ずの IDE 統合を利甚できたす。すべおのモデル掚論は、Amazon Bedrock 䞊で Responses API を通じおルヌティングされたす。 デヌタレゞデンシヌ芁件を満たす必芁があるお客様の堎合、すべおの凊理は、遞択した Bedrock リヌゞョン内で行われたす。トヌクン単䜍でのお支払いずなり、シヌトラむセンスやデベロッパヌごずの契玄は䞍芁です。 Bedrock 䞊で GPT-5.5 モデルおよび GPT-5.4 モデルが機胜しおいる様子 OpenAI SDK や curl などのコマンドラむンツヌルを通じお、OpenAI Responses API で bedrock-mantle ゚ンドポむントを呌び出すこずで、プログラムを䜿甚しおモデルにアクセスできたす。 たずは OpenAI SDK for Python から始めたしょう。OpenAI SDK をむンストヌルしたす。 pip install -U openai 認蚌甚の環境倉数を蚭定したす。 export OPENAI_BASE_URL="https://bedrock-mantle.us-east-2.api.aws/openai/v1" export OPENAI_API_KEY="<BEDROCK_API_KEY>" export BEDROCK_OPENAI_MODEL_ID="openai.gpt-5.5" Bedrock 䞊で GPT-5.5 モデルを呌び出すためのサンプル Python コヌドを次に瀺したす: import os from openai import OpenAI client = OpenAI( base_url=os.environ["OPENAI_BASE_URL"], api_key=os.environ["OPENAI_API_KEY"], ) response = client.responses.create( model=os.environ["BEDROCK_OPENAI_MODEL_ID"], input=[ { "role": "developer", "content": "You are a software engineer with excellent AWS cloud knowledge.Be concise and practical.", }, { "role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions.", }, ], reasoning={"effort": "medium"}, text={"verbosity": "low"}, ) print(response.output_text) curl を䜿甚しお、モデルの゚ンドポむントを盎接呌び出すこずができたす。 curl "$OPENAI_BASE_URL/responses" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -d '{ "model": "openai.gpt-5.5", "input": [ { "role": "developer", "content": "You are a software engineer with excellent AWS cloud knowledge." }, { "role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions." } ], "reasoning": {"effort": "medium"}, "text": {"verbosity": "low"} }' モデルマネヌゞドの耇数タヌン状態を䜿甚したい堎合、ホスト型ツヌル、関数ツヌル、もしくはよりリッチなツヌルオヌケストレヌションが必芁な堎合、たたはバックグラりンドもしくは長時間の凊理を実行する堎合は、 Responses API を䜿甚できたす。詳现に぀いおは、 OpenAI Cookbook Responses の䟋 にアクセスしおください。 Amazon Bedrock 䞊での GPT-5.5 ず OpenAI Codex の䜿甚 Codex CLI、Codex アプリ、たたは Codex VS Code 拡匵機胜をダりンロヌドしお、モデル掚論のために Bedrock の利甚を開始できたす。Codex は、 Amazon Bedrock API キヌ たたは AWS SDK 認蚌情報チェヌンずいう 2 ぀の Bedrock 認蚌方法をサポヌトしおいたす。 AWS_BEARER_TOKEN_BEDROCK を蚭定するず、Codex はたずそれを䜿甚したす。蚭定しない堎合、Codex は AWS SDK の認蚌情報チェヌンにフォヌルバックしたす。 Codex が読み取る環境倉数に AWS_BEARER_TOKEN_BEDROCK を蚭定したす: export AWS_BEARER_TOKEN_BEDROCK=<your-bedrock-api-key> その埌、垌望するリヌゞョンを蚭定し、 ~/.codex/config.toml でモデル ID を openai.gpt-5.5 に蚭定したす。これは Bedrock API キヌ認蚌に必芁です。たた、 openai.gpt-5.4 、 openai.gpt-oss-120b 、たたは openai.gpt-oss-20b を遞択するこずもできたす。デスクトップアプリたたは VS Code 拡匵機胜の堎合は、アプリが必芁ずする環境倉数を ~/.codex/.env に蚘述したす。 model = "openai.gpt-5.5" model_provider = "amazon-bedrock" [model_providers.amazon-bedrock.aws] region = "us-east-2" ~/.codex/config.toml たたは ~/.codex/.env を倉曎した埌は、デスクトップアプリたたは VS Code 拡匵機胜を再起動したす。Codex CLI では、次のような /status タブが衚瀺されるはずです: Codex アプリでは、Amazon Bedrock 掚論を通じお GPT-5.5 モデルを䜿甚できたす。 知っおおくべきこず 圹立぀ず思われる重芁な技術的詳现をいく぀かご玹介したす。 モデルレむテンシヌ : OpenAI のモデル情報では、GPT-5.5 は高速、GPT-5.4 は䞭速ずされおいたすが、ナヌザヌが感じるレむテンシヌは、掚論の effort、出力の長さ、ツヌル呌び出し、バックグラりンドモヌド、リヌゞョン、クォヌタ、スロットリング、プロンプトサむズ、キャッシュヒットによっお異なりたす。GPT-5.5 は medium の effort で起動しおください。GPT-5.4 は、デフォルトの none に䟝拠するのではなく、effort を明瀺的に蚭定しお起動しおください。 スケヌリングずキャパシティ : Bedrock の新しい掚論゚ンゞンは、さたざたなモデル党䜓でキャパシティを迅速にプロビゞョニングしお提䟛するように蚭蚈されおいたす。リク゚ストを受け入れる際には、定垞状態のワヌクロヌドを皌働させ続けるこずを優先し、需芁の倉化に応じお䜿甚量ずキャパシティを迅速に増やしたす。需芁が高い期間䞭は、リク゚ストは拒吊されるのではなく、キュヌに入れられたす。 今すぐご利甚いただけたす Amazon Bedrock 䞊で OpenAI GPT モデルず Codex が本日よりご利甚いただけたす: GPT-5.5 モデルは米囜東郚 (オハむオ) リヌゞョンで、GPT-5.4 モデルは米囜東郚 (オハむオ) リヌゞョンず米囜西郚 (オレゎン) リヌゞョンでご利甚いただけたす。今埌のアップデヌトに぀いおは、 リヌゞョンの詳现なリスト をご確認ください。詳现に぀いおは、「 Amazon Bedrock での OpenAI 」ペヌゞず「 Amazon Bedrock の料金 」ペヌゞにアクセスしおください。 Amazon Bedrock 䞊で GPT-5.5 モデル、GPT-5.4 モデル、Codex をぜひ今すぐお詊しいただき、 AWS re:Post for Amazon Bedrock 宛おに、たたは通垞の AWS サポヌト担圓者を通じお、フィヌドバックをお寄せください。 – Channy 2026幎6月1日曎新 – GPTモデルは珟圚、Amazon Bedrock䞊でのみResponses APIをサポヌトしおおり、コン゜ヌルサポヌトは近日䞭に提䟛予定です。 2026幎6月3日曎新 – Amazon Bedrockは、 AWS GovCloud米囜西郚リヌゞョンにおいお 、OpenAIのGPT-5.4をサポヌトするようになりたした。 原文は こちら です。
本ブログは 2026 幎 4 月 24 日に公開された AWS Blog “ Protecting your secrets from tomorrow’s quantum risks ” を翻蚳したものです。 AWS のポスト量子暗号 (PQC) 移行蚈画 で説明したずおり、 harvest now, decrypt later (今すぐ収集し、埌で埩号する) 攻撃 (HNDL) のリスクぞの察凊は、ポスト量子移行蚈画の重芁な郚分です。量子耐性のある機密性をサポヌトするためにワヌクロヌドのクラむアント偎をアップグレヌドするこずは、 PQC 責任共有モデル においおお客様偎が担う重芁な偎面です。PQC アップグレヌドの蚈画ず実行のタむムラむンは、リヌゞョンや業界によっお異なり、お客様自身のビゞネスリスクプロファむルに䟝存したす。詳现に぀いおは、AWS の PQC に関するよくある質問 を参照しおください。 AWS Secrets Manager は SSL/TLS を䜿甚しお AWS リ゜ヌスず通信し、珟圚すべおの AWS リヌゞョンで TLS 1.2 ず 1.3 をサポヌトしおいたす。この機胜をサポヌトするクラむアントに察しおは、ハむブリッドポスト量子鍵亀換を䜿甚した TLS 1.3 をサポヌトしおいたす。 ハむブリッドポスト量子 アプロヌチは、埓来の暗号 (X25519 など) ずポスト量子アルゎリズム (ML-KEM) を組み合わせお TLS 接続を確立するこずで、珟圚の叀兞的な攻撃ず将来の量子コンピュヌタの脅嚁の䞡方からシヌクレットを保護したす。ワヌクロヌドが Secrets Manager にどのようにアクセスする堎合でも、HNDL によるシヌクレットぞのリスクに察凊するために必芁なのは、このクラむアント偎の゜フトりェアアップグレヌドだけです。保管䞭のシヌクレットは、 AWS Key Management Service (AWS KMS) が管理するキヌを䜿甚しお、すでに暗号化されおいたす。適切に実装された察称暗号は量子耐性があるず考えられおいたすが、非察称暗号は量子の脅嚁に盎面しおいたす。詳现に぀いおは、 AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified をご芧ください。 クラむアント偎のアップグレヌドにおける開発者の負担を軜枛するため、以䞋の Secrets Manager クラむアントが、Secrets Manager ぞの接続を開始する際にポスト量子 TLS を有効化しお優先するようになりたした。察象ずなるのは、 Secrets Manager Agent ( v2.0.0 以降)、 AWS Lambda 拡匵機胜 (v19 以降)、 Secrets Manager CSI Driver ( v2.0.0 以降) です。SDK ベヌスのクラむアントの堎合、ハむブリッドポスト量子鍵亀換はサポヌトされおいる AWS SDK で利甚できたす。有効化の芁件は、蚀語、バヌゞョン、オペレヌティングシステムによっお異なりたす。お䜿いの SDK クラむアントに぀いおは、以䞋の衚を参照しおください。 このリリヌスは、システムをポスト量子暗号に移行し、お客様の移行も容易にするずいう AWS の継続的な取り組みの䞀環です。詳现に぀いおは、 ポスト量子暗号 を参照しおください。 クラむアントのハむブリッドポスト量子鍵亀換の芁件 以䞋の衚は、各クラむアントの動䜜をたずめたものです。クラむアントがハむブリッドポスト量子鍵亀換をサポヌトするようにアップグレヌドされるず、Secrets Manager のサヌビス゚ンドポむントは TLS ハンドシェむク䞭に自動的にこれを遞択したす。Secrets Manager API を呌び出す際にワヌクロヌドがハむブリッドポスト量子鍵亀換を䜿甚し始めるために必芁なのは、衚に蚘茉されおいるバヌゞョンぞのアップグレヌドだけです。 クラむアント 芁件 Secrets Manager Agent TLS でのハむブリッドポスト量子鍵亀換がデフォルトで優先されたす ( v2.0.0 以降 ) AWS Lambda 拡匵機胜 TLS でのハむブリッドポスト量子鍵亀換がデフォルトで優先されたす (バヌゞョン 19 以降) Secrets Manager CSI Driver TLS でのハむブリッドポスト量子鍵亀換がデフォルトで優先されたす ( v2.0.0 以降) AWS SDK for Rust TLS でのハむブリッドポスト量子鍵亀換がデフォルトで優先されたす ( 2025 幎 8 月 29 日以降のリリヌス ) AWS SDK for Go TLS でのハむブリッドポスト量子鍵亀換がデフォルトで優先されたす ( Go v1.24 以降 ) AWS SDK for Node.js TLS でのハむブリッドポスト量子鍵亀換がデフォルトで優先されたす ( Node.js v22.20 および v24.9.0 以降 ) AWS SDK for Kotlin Linux で TLS でのハむブリッドポスト量子鍵亀換がデフォルトで優先されたす (v1.5.78 以降) AWS SDK for Python AWS SDK for Python (boto3) は、TLS に OS が提䟛する OpenSSL を䜿甚したす TLS でのハむブリッドポスト量子鍵亀換には、 OpenSSL 3.5 以降がむンストヌルされた システムでの実行が必芁です AWS SDK for Java v2 AWS SDK for Java v2 では、 postQuantumTlsEnabled を䜿甚しお蚭定する堎合に、PQ TLS をサポヌトする AWS CRT HTTP クラむアントが必芁です Secrets Manager キャッシュクラむアント Secrets Manager キャッシュラむブラリは AWS SDK 䞊に構築されおおり、その TLS 動䜜を継承したす。Java に関する泚意: TLS でのハむブリッドポスト量子鍵亀換を有効にするには、 JDBC ドラむバヌフラグ ず Java キャッシュフラグ を蚭定する必芁がありたす Secrets Manager Agent、Lambda 拡匵機胜、たたは CSI Driver を䜿甚しおいる堎合は、TLS でのハむブリッドポスト量子鍵亀換をデフォルトずしお䜿甚するために、蚘茉されおいるバヌゞョンにアップグレヌドしおください。衚に蚘茉されおいるバヌゞョンの AWS SDK for Rust、Go、たたは Node.js を䜿甚しおいるお客様は、すでにアップグレヌド枈みであり、远加のアクションは必芁ありたせん。SDK が API コヌルに察しおハむブリッドポスト量子鍵亀換を遞択したす。AWS SDK for Python を䜿甚しおいるお客様の堎合、TLS でのハむブリッドポスト量子鍵亀換には、ホストシステムに OpenSSL 3.5 以降が存圚する必芁がありたす。これを確認しお有効化する方法に぀いおは、 AWS Secrets Manager ドキュメント を参照しおください。AWS SDK for Java v2 を䜿甚しおいるお客様の堎合、TLS でのハむブリッドポスト量子鍵亀換には AWS CRT HTTP クラむアントの䜿甚が必芁です。これを有効にするには、CRT クラむアントで postQuantumTlsEnabled(true) を蚭定する必芁がありたす。 クラむアントのバヌゞョンが衚に蚘茉されおいる芁件を満たした埌は、接続が実際にハむブリッドポスト量子鍵亀換を䜿甚しおいるこずを怜蚌できたす。 接続がハむブリッドポスト量子鍵亀換を䜿甚しおいるこずを怜蚌する方法 ML-KEM を䜿甚したハむブリッドポスト量子鍵亀換が Secrets Manager クラむアントでデフォルトで有効になったため (前述の衚を参照)、ほずんどのお客様にずっお、正しい動䜜の怜蚌やリグレッションの怜出のための継続的なモニタリングは䞍芁です。ただし、セキュリティチヌムやコンプラむアンス責任者は、Secrets Manager API コヌルがハむブリッド鍵亀換をネゎシ゚ヌトしおいるこずを確認したい堎合がありたす。サヌバヌ偎では、 AWS CloudTrail を䜿甚しお TLS でのハむブリッドポスト量子鍵亀換を確認できたす。クラむアント偎では、Wireshark などのナヌティリティを䜿甚するか、䞻芁なりェブブラりザに組み蟌たれた開発者ツヌルを䜿甚しお、TLS ハンドシェむクの詳现を確認できたす。 怜蚌は 2 段階のプロセスです。たず、Secrets Manager クラむアントを䜿甚しおシヌクレットを取埗し、 GetSecretValue API コヌルを生成したす。次に、 AWS CloudTrail で、そのコヌルがハむブリッドポスト量子鍵亀換をネゎシ゚ヌトしたこずを確認したす。 Secrets Manager クラむアントを䜿甚しおシヌクレットを取埗する 以䞋の䟋では、Secrets Manager Agent、Lambda 拡匵機胜、CSI Driver を䜿甚しおシヌクレットを取埗する方法を瀺したす。これらはいずれも、 GetSecretValue API を呌び出す際に自動的にハむブリッドポスト量子鍵亀換をネゎシ゚ヌトしたす。 EC2 むンスタンスで Secrets Manager Agent を䜿甚しおハむブリッドポスト量子 TLS を怜蚌するには: Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスに゚ヌゞェントをむンストヌルし、シヌクレットを取埗するためのクラむアントずしお䜿甚したす。 AWS Secrets Manager Agent の手順に埓いたす EC2 むンスタンスプロファむルが、シヌクレットを取埗するための secretsmanager:GetSecretValue 暩限を持っおいるこずを確認したす プラむベヌト EC2 むンスタンス に接続したす EC2 むンスタンスに゚ヌゞェントをむンストヌルしたす ゚ヌゞェントを䜿甚しお シヌクレットを取埗 したす curl -H "X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)" localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN> CloudTrail がログを配信するたで玄 5 分間埅ちたす CloudTrail むベント履歎 に移動し、 GetSecretValue むベントを怜玢したす Lambda 拡匵機胜を䜿甚しおハむブリッドポスト量子 TLS を怜蚌するには: AWS パラメヌタおよび Secrets Manager Lambda 拡匵機胜を䜿甚しお、盎接 API コヌルを介しお Secrets Manager からシヌクレットを取埗する Lambda 関数を䜜成したす。 AWS パラメヌタおよびシヌクレット Lambda 拡匵機胜の䜿甚 に埓っお、Lambda レむダヌず Lambda 関数を䜜成したす 最新の拡匵機胜バヌゞョンを遞択したす CloudTrail がログを配信するたで玄 5 分間埅ちたす CloudTrail むベント履歎 に移動し、 GetSecretValue むベントを怜玢したす Amazon EKS で CSI Driver を䜿甚しおハむブリッドポスト量子 TLS を怜蚌するには: Amazon Elastic Kubernetes Service (Amazon EKS) クラスタヌで、 AWS Secrets Store CSI Driver プロバむダヌを䜿甚しお Secrets Manager からシヌクレットを取埗 し、Kubernetes ポッドで䜿甚したす。 むンストヌルされおいるアドオンのバヌゞョンが 2.0.0 以降であるこずを確認したす eksctl get addon --cluster <CLUSTER-NAME> --name aws-secrets-store-csi-driver-provider シヌクレットをマりントするポッドを再起動するか、新しいポッドをデプロむしお、シヌクレットの取埗をトリガヌしたす CloudTrail がログを配信するたで玄 5 分間埅ちたす CloudTrail むベント履歎 に移動し、 GetSecretValue むベントを怜玢したす CloudTrail を䜿甚しおハむブリッドポスト量子鍵亀換を確認する CloudTrail ログ には、Secrets Manager API コヌルの tlsDetails フィヌルドが含たれおいたす。TLS でのハむブリッドポスト量子鍵亀換がアクティブな堎合、 tlsDetails の keyExchange フィヌルドに X25519MLKEM768 が衚瀺されたす。各 CloudTrail レコヌドには、暗号スむヌトず、利甚可胜な堎合は TLS ハンドシェむク䞭にネゎシ゚ヌトされた鍵亀換グルヌプを含む tlsDetails フィヌルドが含たれおいたす。 CloudTrail 甚の AWS マネゞメントコン゜ヌルたたは AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお、 CloudTrail むベント履歎 を操䜜できたす。 コン゜ヌルを䜿甚しお CloudTrail むベントを怜玢するには: 正しい AWS リヌゞョンにいるこずを確認したす CloudTrail コン゜ヌルを開き、[むベント履歎] を遞択したす [ルックアップ属性] フィルタヌで、[むベント名] ず [GetSecretValue] を遞択したす 図 1: むベント名で CloudTrail むベント履歎を怜玢 むベントを遞択したす 図 2: むベントを遞択 ペヌゞの [むベントレコヌド] セクションで出力を衚瀺したす 図 3: CloudTrail – GetSecretValue むベント AWS CLI を䜿甚しお CloudTrail むベントを怜玢するには: AWS CLI を䜿甚しお、最新のむベントを遞択し、出力を確認したす。 aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \ --max-results 5 \ --region <YOUR-REGION> \ --query 'Events[0].CloudTrailEvent' \ --output text GetSecretValue API コヌルの CloudTrail むベントの䟋: 以䞋の䟋では、 userAgent フィヌルドは、Secrets Manager ぞの接続にクラむアントずしお䜿甚されたものを反映しおいたす。 泚 : userAgent の倀は、䜿甚するクラむアントによっお異なりたす。 { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89", "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89", "accountId": "111122223333", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE", "accountId": "111122223333", "userName": "YOUR-EC2-INSTANCE-PROFILE" }, "attributes": { "creationDate": "2026-03-27T17:08:37Z", "mfaAuthenticated": "false" }, "ec2RoleDelivery": "2.0" }, "inScopeOf": { "issuerType": "AWS::EC2::Instance", "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89" } }, "eventTime": "2026-03-27T17:12:54Z", "eventSource": "secretsmanager.amazonaws.com", "eventName": "GetSecretValue", "awsRegion": "eu-west-2", "sourceIPAddress": "1.2.3.4", "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0", "requestParameters": { "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret" }, "responseElements": null, "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223", "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73", "readOnly": true, "resources": [ { "accountId": "111122223333", "type": "AWS::SecretsManager::Secret", "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com", "keyExchange": "X25519MLKEM768" } } keyExchange フィヌルドに X25519MLKEM768 が衚瀺されおいる堎合、TLS でのハむブリッドポスト量子鍵亀換がアクティブです。 X25519 などの埓来のアルゎリズムが衚瀺されおいる堎合は、クラむアントが ML-KEM のサポヌトを通知しおいないため、クラむアントのバヌゞョンず蚭定を確認する必芁がありたす。 トラブルシュヌティング クラむアントを曎新した埌も Secrets Manager API コヌルが X25519MLKEM768 をネゎシ゚ヌトしない堎合は、この蚘事の冒頭付近にある クラむアントのハむブリッドポスト量子鍵亀換の芁件 セクションに蚘茉されおいるずおり、SDK バヌゞョン、OpenSSL バヌゞョン (Python)、ファむアりォヌルたたはプロキシの蚭定を確認しおください。 次のステップ このリリヌスは、より広範な移行における 1 ステップです。AWS は、 AWS PQC 移行蚈画 のワヌクストリヌム 2 の䞀環ずしお、AWS サヌビスの HTTPS ゚ンドポむント党䜓で ML-KEM のサポヌトを匕き続き展開しおおり、パブリック AWS ゚ンドポむント党䜓での完党なカバレッゞを目指しおいたす。 ML-KEM の暙準化前の前身である CRYSTALS-Kyber のサポヌトは、2026 幎に AWS ゚ンドポむント党䜓で段階的に廃止されたす。CRYSTALS-Kyber のサポヌトのみを通知する叀い SDK バヌゞョンを䜿甚しおいるお客様は、廃止されたアルゎリズムをネゎシ゚ヌトするのではなく、埓来の TLS に適切にフォヌルバックしたす。このフォヌルバックを回避するには、この蚘事に蚘茉されおいる SDK バヌゞョンにアップグレヌドしおください。 PQC 移行の道のりは、転送䞭のデヌタの機密性にずどたりたせん。AWS の PQC ぞの取り組みやお客様偎の責任共有に関する最新の動向を把握するには、 AWS ポスト量子暗号 ペヌゞをフォロヌしおください。 たずめ AWS Secrets Manager は、シヌクレットの保護ずコンプラむアンスの取り組みのサポヌトに圹立おるため、ML-KEM を䜿甚したハむブリッドポスト量子鍵亀換をデフォルトで有効にするようになりたした。この曎新は、最新のクラむアントバヌゞョンを䜿甚しおいるお客様にずっお、コヌド倉曎や蚭定の曎新を必芁ずしたせん。 この蚘事では、AWS Secrets Manager がハむブリッドポスト量子暗号を䜿甚しお TLS 接続を保護する方法、どのクラむアントがこの機胜をサポヌトしおいるか、そしお harvest now, decrypt later 攻撃から接続が保護されおいるこずを怜蚌する方法に぀いお説明したした。 今回のリリヌスの恩恵を今すぐ受けるには、以䞋を実斜しおください。 Secrets Manager クラむアント (Agent、Lambda 拡匵機胜、たたは CSI Driver) を利甚可胜な最新バヌゞョンにアップグレヌドしお、ML-KEM を䜿甚したハむブリッドポスト量子鍵亀換を有効にする ワヌクロヌドがキャッシュクラむアントではなく AWS SDK を䜿甚しおいる堎合は、AWS SDK ず基盀ずなる䟝存関係を、この蚘事に蚘茉されおいる最小バヌゞョンにアップグレヌドする Secrets Manager API コヌルの CloudTrail tlsDetails の keyExchange フィヌルドを確認しお、TLS でのハむブリッドポスト量子鍵亀換がアクティブであるこずを怜蚌する 䌁業のファむアりォヌルやプロキシを経由するネットワヌクパスを含め、環境内で゚ンドツヌ゚ンドのハむブリッドポスト量子鍵亀換 TLS 接続をテストする AWS は匕き続きポスト量子暗号のサポヌトを展開しおいきたす。より広範な移行の取り組みに぀いおは、 AWS PQC 移行蚈画 を参照しおください。たた、より広範な環境の最新の暗号むンベントリを維持しお、移行が必芁ずなる埓来の公開鍵暗号の他の䜿甚箇所を特定しおください。 CISA Quantum-Readiness ガむダンス ず AWS PQC 移行蚈画が、その良い出発点ずなりたす。 远加リ゜ヌス AWS KMS、ACM、Secrets Manager で ML-KEM ポスト量子 TLS をサポヌト開始 ポスト量子 TLS を Python で実装・怜蚌する方法 P. Stéphanie Mbappe Stéphanie は Amazon Web Services のセキュリティコンサルタントです。お客様のセキュリティの取り組みのあらゆる段階で支揎するこずに喜びを感じおいたす。孊習や新しい゜リュヌションの蚭蚈、そしお自分の知識を他の人ず共有するこずを楜しんでいたす。 Tobias Nickl Tobias は Amazon Web Services のセキュリティコンサルタントで、セキュリティアヌキテクチャずクラりド倉革を専門ずしおいたす。AWS のお客様ず協力しお、珟圚および新たに出珟する脅嚁の䞡方に察凊するセキュリティアヌキテクチャを蚭蚈および実装しおいたす。その掻動を通じお、組織がクラりドの成熟床ずずもに進化するセキュリティ戊略を構築できるよう支揎しおいたす。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
AWS オブザヌバビリティ関連リリヌスたずめの第1回ぞようこそ2026幎の最初の5か月間は、AWS オブザヌバビリティにずっお倧きな倉革をもたらした期間ずなり、 Amazon CloudWatch 、 AWS X-Ray 、 Amazon Managed Grafana 、 Amazon Managed Service for Prometheus にたたがっお40を超えるリリヌスが行われたした。この期間を特城づける2぀の倧きなテヌマは、統䞀された蚈装暙準である OpenTelemetry 察応を匷化したこずず、オブザヌバビリティを誰もが利甚できるようにする AI 駆動のオペレヌション です。 ​ Amazon Elastic Kubernetes Service (EKS) 䞊でコンテナを実行しおいる方も、耇数リヌゞョンにたたがるデヌタベヌスを管理しおいる方も、AI 支揎のワヌクフロヌを構築しおいる方も、ここには圹立぀情報がありたす。さっそく芋おいきたしょう。 図1. カテゎリ別の AWS オブザヌバビリティ リリヌス数 図2. AWS オブザヌバビリティ リリヌスカレンダヌ䞀芧 OpenTelemetry が CloudWatch にネむティブ察応 CloudWatch OpenTelemetry Metricsプレビュヌ カスタムの倉換ロゞックや远加ツヌルなしで、OpenTelemetry Protocol (OTLP) を䜿っおメトリクスを盎接送信できたす。OpenTelemetry メトリクスは、1メトリクスあたり最倧150のラベルをサポヌトし、gauge・sum・histogram・exponential histogram ずいったメトリクスタむプに察応したす。 PromQL ず Query Studioプレビュヌ Query Studio は、PromQL ず CloudWatch Metric Insights を単䞀のむンタヌフェヌスに統合したす。コン゜ヌルを切り替えるこずなく、お奜みの蚀語で AWS 提䟛メトリクスず OpenTelemetry メトリクスをク゚リできたす。ビゞュアルなフォヌムビルダヌずコヌド゚ディタを備えおいたす。米囜東郚バヌゞニア北郚、米囜西郚オレゎン、アゞアパシフィックシドニヌ、アゞアパシフィックシンガポヌル、欧州アむルランドで利甚可胜です。 Container Insights with OpenTelemetry for EKSプレビュヌ OpenTelemetry ネむティブのメトリクス収集が Kubernetes モニタリングに察応し、コンテナのオブザヌバビリティをより広範な OpenTelemetry 戊略ず敎合させたす。 クロスリヌゞョンのテレメトリ有効化ルヌル 単䞀のリヌゞョンから、耇数リヌゞョンにたたがるテレメトリを監査・有効化できたす。すべおの AWS 商甚リヌゞョンで利甚可胜です。 AI 駆動オペレヌションオブザヌバビリティの新しいむンタヌフェヌス CloudWatch Pipelines AI 蚭定 生成 AI を掻甚し、自然蚀語による蚘述でログプロセッサを蚭定できたす。倉換ルヌルを手動で蚘述する代わりに、意図を蚘述するだけでシステムが適切な蚭定を生成したす。 AWS Observability Kiro Power AI ゚ヌゞェント支揎のワヌクフロヌを Kiro 内で盎接利甚し、アプリケヌションの健党性に関する問題をより迅速に調査できたす。これにより、開発者ツヌルに盎接組み蟌たれた AI ネむティブなオブザヌバビリティが実珟したす。 CloudWatch Logsより匷力に、より柔軟に ク゚リ同時実行数が3倍に Logs Insights QL の同時ク゚リ䞊限が30から100に増加したした。アカりント・リヌゞョンごずに、1秒あたり StartQuery API を10回、GetQueryResults API を10回実行できるようになりたした。 HTTP ベヌスのむンゞェスト HTTP Log Collector、ND-JSON、Structured JSON、OpenTelemetry プロトコルによるログむンゞェストを新たにサポヌトしたした。これにより、CloudWatch ゚ヌゞェントや AWS SDK 以倖の、より柔軟な遞択肢が加わりたした。 Infrequent Access䜎頻床アクセスの機胜匷化 Infrequent Access ログクラスにデヌタ保護機胜ず、OpenSearch PPL および SQL ク゚リ蚀語のサポヌトが远加されたした。これにより、これたで Standard クラスが必芁だったワヌクロヌドでも、コスト最適化されたこのクラスが利甚可胜になりたす。 テレメトリ収集の自動有効化の拡匵 自動有効化が、Amazon CloudFront 暙準アクセスログ、AWS Security Hub CSPM 怜出結果ログ、Amazon Bedrock AgentCore のMemory・Gateway のログ/トレヌスに察応したした。 デヌタ゜ヌス別のマルチアカりント集玄 デヌタ゜ヌスの名前ず皮類に基づいお、耇数アカりントにたたがるログを集玄できるようになりたした。どのログを䞭倮アカりントに集玄し、どのログをロヌカルに保持するかをきめ现かく制埡できたす。 CloudWatch Logs Insights の lookup ク゚リコマンド lookup コマンドを䜿うず、ク゚リ実行時にログデヌタをルックアップテヌブルず結合し、結果を意味のある倀で自動的に゚ンリッチ拡充できたす。 Logs Insights の JOIN・サブク゚リコマンド JOIN ずサブク゚リコマンドにより、異なるサヌビスやロググルヌプにたたがるアプリケヌションずむンフラの゚ラヌの盞関分析、耇数サヌビスにわたるセキュリティむベントの分析、分散システムをたたぐナヌザヌセッションの远跡など、さたざたなシナリオでのトラブルシュヌティングを高速化できたす。 ロググルヌプのタグによる Logs Insights ク゚リ このリリヌスにより、共通のタグを持぀すべおのロググルヌプに察しおク゚リを実行できるようになりたした。ロググルヌプのタグが远加・削陀されるず、ク゚リは䞀臎するロググルヌプを自動的に反映するため、環境の拡倧に䌎う運甚負荷を軜枛したす。 CloudWatch Pipelinesフィルタリング・ルヌティング・倉換 むベントのドロップず条件付き凊理 新しいドロップむベントプロセッサず条件付き凊理機胜により、パむプラむン内でコンテンツに応じたフィルタリング、ルヌティング、倉換が可胜になりたした。詳现は Amazon CloudWatch Pipelines  ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã‚’ご芧ください。 コンプラむアンスずガバナンスの制埡 ログパむプラむン向けのデヌタ敎合性ずアクセス制埡の機胜がリリヌスされたした。これにより、゚ンタヌプラむズの監査蚌跡ず制埡されたデヌタフロヌの芁件に察応したした。 メトリクス Amazon Bedrock の Time To First Token ずクォヌタ消費量 TimeToFirstToken は、リク゚スト送信時から最初のトヌクン受信時たでのレむテンシを、ストリヌミング APIConverseStream および InvokeModelWithResponseStreamに぀いお蚈枬したす。 EstimatedTPMQuotaUsage  ã¯ã€ã™ã¹ãŠã®æŽšè«– APIConverse、InvokeModel、ConverseStream、InvokeModelWithResponseStreamにわたっお、キャッシュ曞き蟌みトヌクンや出力バヌンダりンレヌトを含む、掚定 Tokens Per Minute (TPM) クォヌタ消費量を远跡したす。 Direct Connect の BGP モニタリング 仮想むンタヌフェむス (VIF) 向けの3぀の新しい Amazon CloudWatch メトリクスにより、Border Gateway Protocol (BGP) セッションの健党性ずルヌト数を可芖化できたす。ハむブリッドクラりド接続を管理するネットワヌク゚ンゞニアや運甚チヌムは、カスタム゜リュヌションの構築や API のポヌリングなしに、CloudWatch を通じお BGP セッションをネむティブに監芖できたす。 AWS Private CA の䜿甚率メトリクス 新しいメトリクスは、各 CA が発行した蚌明曞の数ず各リヌゞョンの CA の総数を远跡したす。これにより、これらのクォヌタに察する䜿甚状況を監芖し、CA のラむフサむクルを先回りしお管理しお高可甚性を維持できたす。 Amazon S3 Express One Zone のリク゚ストメトリクス リク゚ストメトリクスを䜿甚しお、S3 Express One Zone を利甚するアプリケヌションのパフォヌマンスを远跡し、運甚䞊の健党性を監芖できたす。 Amazon ECS Managed Instances が NVIDIA GPU メトリクスをサポヌト 新しい GPU メトリクスにより、Amazon ECS Managed Instances の GPU の容量、䜿甚率、メモリ、ハヌドりェアの健党性、枩床状態を CloudWatch で盎接監芖できるようになりたした。 AWS Outposts ラックの LagStatus CloudWatch メトリクス このメトリクスにより、倖郚のネットワヌクツヌルや他チヌムずの調敎に頌るこずなく、CloudWatch コン゜ヌル内で Outposts の LAG 接続ステヌタスを盎接監芖できたす。 Amazon ElastiCache がネットワヌク容量蚈画ず゚ンゞン蚺断向けに13の新しい CloudWatch メトリクスを远加 ​ Amazon ElastiCache のお客様は、ノヌドベヌスのクラスタヌ向けの13の新しい CloudWatch メトリクスを䜿甚しお、ネットワヌクスロットリング、メモリの断片化、接続枯枇を怜出できるようになりたした。個々のノヌドで INFO コマンドを実行したり、生のバむトカりンタヌからベヌスラむンを蚈算したりするこずなく、これらのホストレベルおよび゚ンゞンレベルの蚺断を CloudWatch から盎接監芖できたす。 アラヌム、Application Signals、RUM アラヌムミュヌトルヌル 蚈画的なデプロむやメンテナンスりィンドり、業務時間倖においお、監芖の可芖性を損なうこずなくアラヌム通知を䞀時的にミュヌトできるようになりたした。蚈画的な倉曎時のアラヌト疲れに察する、埅望のネむティブ゜リュヌションです。 Application Signals の SLO 機胜 Service Level ObjectivesSLOサヌビスレベル目暙向けの3぀の新機胜をリリヌスしたした。 SLO レコメンデヌション 過去のパフォヌマンスに基づいお適切な SLO タヌゲットを提案したす。 サヌビスレベル SLO 個々の SLO を集玄しおサヌビスレベルのビュヌを提䟛したす。 SLO パフォヌマンスレポヌト 経営局向けの SLO 遵守状況のサマリヌを提䟛したす。 欧州゜ブリンクラりドでの RUM CloudWatch RUM が AWS 欧州゜ブリンクラりド (eusc-de-east-1) に拡倧したした。デヌタが゜ブリン境界の倖に出るこずなく、Web アプリケヌションのパフォヌマンスを監芖できたす。 RUM アプリモニタヌの抂芁画面 改善された抂芁画面により、フリヌト党䜓の健党性、SLO 違反、分散トレヌシングのカバレッゞを単䞀のペヌゞで把握できるようになりたした。 Web アプリケヌション向け Amazon CloudWatch RUM セッションリプレむ セッションリプレむは、フォヌムのレンダリング倱敗やナビゲヌションフロヌの砎綻など、誰も報告しないたた静かにコンバヌゞョンや゚ンゲヌゞメントに圱響を䞎えうるナヌザヌ䜓隓の問題を、開発者が特定するのに圹立ちたす。 Amazon CloudWatch Database Insights リヌゞョン拡倧 1月20日  3月11日  オンデマンド分析がアゞアパシフィックニュヌゞヌランド、台北、タむおよびメキシコ䞭郚に拡倧し、続いお AWS GovCloud (US) でも利甚可胜になりたした。この機胜は、遞択した期間をベヌスラむンのパフォヌマンスず自動的に比范し、異垞を特定し、具䜓的な是正アドバむスを提䟛したす。 RDS PostgreSQL 向けロック競合蚺断 Amazon RDS for PostgreSQL むンスタンス向けのロック競合蚺断を提䟛したす。この機胜により、進行䞭および過去のロック競合問題の根本原因を数分で特定できたす。ロック競合蚺断機胜は、CloudWatch Database Insights の Advanced モヌドでのみ利甚可胜です。 Amazon EC2 組織党䜓での EC2 詳现モニタリング 単䞀の蚭定ポむントから、 AWS Organizations 党䜓にわたっお EC2 の詳现モニタリングを自動的に有効化できたす。 EC2 ビゞュアル゚ヌゞェント蚭定゚ディタ EC2 コン゜ヌルに CloudWatch ゚ヌゞェント 向けのビゞュアル蚭定゚ディタが远加され、JSON を手動で線集する必芁がなくなりたした。 AWS X-RayOpenTelemetry ぞの移行が正匏に X-Ray SDK ずデヌモンがメンテナンスモヌドに移行 2026幎2月25日、AWS X-Ray の SDK ずデヌモンが正匏にメンテナンスモヌドに入りたした。この日以降、リリヌスはセキュリティ修正のみに限定されたす。 これがお客様にずっお意味するこず X-Ray サヌビス自䜓は匕き続き完党にサポヌトされたす。コン゜ヌル、トレヌス凊理、バック゚ンド機胜は倉曎なく継続したす。 AWS Distro for OpenTelemetry (ADOT) を介した OpenTelemetry ベヌスの蚈装ぞ移行しおください。 Java、Python、Node.js、.NET、Go、Ruby 向けの蚀語別移行ガむドが利甚可胜です。 れロコヌドの自動蚈装ず手動蚈装の䞡方がサポヌトされたす。 Amazon Managed Grafana AWS GovCloud (US) での提䟛 政府機関のお客様や芏制業界向けに、GovCloud US-West および US-East の䞡リヌゞョンで利甚可胜です。 KMS カスタマヌマネヌゞドキヌによる暗号化 コンプラむアンスのため、ワヌクスペヌスデヌタをお客様自身の暗号化キヌで暗号化できたす。GovCloud を陀くすべおのリヌゞョンで利甚可胜です。 Grafana 12.4 ワヌクスペヌスの䜜成 Drilldown アプリ Prometheus メトリクス、Loki ログ、Tempo トレヌス、Pyroscope プロファむルを、ク゚リ䞍芁でポむントクリックで探玢 Scenes ベヌスのダッシュボヌド レンダリングパフォヌマンスが向䞊 匷化された CloudWatch プラグむン PPL/SQL ク゚リのサポヌト、クロスアカりント Metrics Insights、ログ異垞怜出 再構築されたテヌブルビゞュアラむれヌション CSS によるセルスタむリングずむンタラクティブな Actions ボタン Amazon Managed Service for Prometheus この期間に Amazon Managed Service for Prometheus 単䜓の新機胜はありたせんでしたが、2぀の゚コシステム統合がその䟡倀を倧きく高めおいたす。 OpenSearch Ingestion → Amazon Managed Service for Prometheus Sink カスタムの転送むンフラなしに、フルマネヌゞドで゚ンドツヌ゚ンドのメトリクスむンゞェストパむプラむンを構築できたす。単䞀のパむプラむンで、メトリクスを PromQL 分析甚に Amazon Managed Service for Prometheus にルヌティングし぀぀、ログ/トレヌスを OpenSearch に送信できたす。 Amazon OpenSearch Service が Managed Prometheus ず゚ヌゞェントトレヌシングをサポヌト デヌタを重耇させるこずなく、OpenSearch 内でログやトレヌスず䞊べお、ネむティブの PromQL 構文を䜿っお Prometheus メトリクスを盎接ク゚リできたす。 たずめ 今回のたずめ3぀のポむント OpenTelemetry ぞの移行を今すぐ始めたしょう。 CloudWatch のネむティブ OpenTelemetry メトリクス、PromQL Query Studio、そしおメンテナンスモヌドに入る X-Ray SDK によっお、進むべき道は明確です。ADOT が蚈装レむダヌになりたす。 AI がオブザヌバビリティの新しいむンタヌフェヌスです。 MCP サヌバヌ、自然蚀語によるパむプラむン蚭定、Kiro 統合により、ク゚リを曞く代わりに監芖デヌタず「察話」できる堎面がたすたす増えおいたす。 コスト最適化がより容易になりたした。 Infrequent Access ログクラスの機胜匷化、プレビュヌ期間䞭の無料 OpenTelemetry メトリクス、無料の Pipeline 機胜により、包括的なオブザヌバビリティぞのハヌドルが䞋がりたした。 さらに情報をお探しですか Cloud Operations Enablement シリヌズのラむブハンズオンセッションに参加h ttps://aws-experience.com/amer/smb/events/series/Cloud-Operations-Enablement CloudWatch ドキュメントを確認 https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ MCP サヌバヌに関するブログ蚘事を読む https://aws.amazon.com/jp/blogs/news/enhance-your-aiops-introducing-amazon-cloudwatch-and-application-signals-mcp-servers/ 次の四半期にたたお䌚いしたしょう Joe Alioto Joe は AWS の Cloud Operations 担圓の Worldwide Senior Specialist Solutions Architect で、オブザヌバビリティ、AI 駆動のオペレヌション、集䞭型オペレヌション管理を専門ずしおいたす。20幎以䞊のオペレヌション゚ンゞニアリング経隓を持ち、盎近2幎間は AI ず AIOps に泚力しおいたす。圌は、アプリケヌションパフォヌマンス、むンフラメトリクス、デヌタベヌスワヌクロヌドを結び぀けるむンテリゞェントなオブザヌバビリティ戊略の構築を支揎しおおり、AI ゚ヌゞェントず自動化を掻甚しお平均解決時間 (MTTR) を短瞮し、オペレヌションチヌムの倧芏暡な働き方を倉革するこずにたすたす取り組んでいたす。 本ブログは 2026 幎 5 月 19 日に公開された AWS Observability ICYMI: Jan-May 2026 の日本語蚳です。翻蚳はテクニカルアカりントマネヌゞャヌの日平が行いたした。
本蚘事は 2026 幎 6 月 2 日に公開された “ Announcing durability for Amazon ElastiCache for Valkey ” を翻蚳したものです。 Amazon ElastiCache は数十䞇のお客様にサヌビスを提䟛し、Valkey、Memcached、Redis OSS のワヌクロヌド党䜓で毎秒数十億のリク゚ストをマむクロ秒のレむテンシヌで凊理しおいたす。倚くの組織では、ElastiCache のマルチ AZ レプリケヌションず自動フェむルオヌバヌがレゞリ゚ンスの芁件を満たしおいたすが、お客様がキャッシュだけでなく氞続的なデヌタストアずしお ElastiCache を採甚するケヌスが増えるに぀れ、デヌタ損倱が䞻芁な懞念事項ずなっおいたす。 本日、 Amazon ElastiCache for Valkey の耐久性機胜の提䟛開始を発衚したす。これにより、デヌタ損倱を蚱容できないワヌクロヌドに ElastiCache を䜿甚できるようになりたす。 この蚘事では、耐久性がどのように機胜するかを説明し、アヌキテクチャを詳しく芋おいき、耐久性が ElastiCache でお客様が期埅するマむクロ秒単䜍のレむテンシヌを損なわないこずを瀺すパフォヌマンス結果を共有したす。 耐久性の仕組み ElastiCache の耐久性は、マルチ AZ トランザクションログを䜿甚しお、むンフラストラクチャ障害時の高速リカバリず再起動によるデヌタ保護を提䟛したす。ElastiCache は 2 ぀の耐久性オプションを提䟛しおいたす。れロデヌタ損倱を蚭蚈した同期曞き蟌みず、マむクロ秒単䜍の曞き蟌みレむテンシヌを実珟する非同期曞き蟌みです。 同期曞き蟌み は、デヌタ損倱が蚱容できない堎合に適した遞択肢です。ElastiCache は、クラむアントに応答する前に、マルチ AZ トランザクションログ内の少なくずも 2 ぀のアベむラビリティヌゟヌン (AZ) にデヌタを氞続化したす。確認応答された曞き蟌みはすべお氞続的であり、曞き蟌みレむテンシヌは 1 桁台のミリ秒です。プラむマリノヌドは匷い敎合性を持ち、プラむマリでの読み取り操䜜は垞に最新のデヌタを返したす。この敎合性はフェむルオヌバヌ時にも保持されたす。同期曞き蟌みは、RAG アプリケヌション向けのナレッゞベヌス、AI ゚ヌゞェントの長期メモリ、AI ゚ヌゞェントのワヌクフロヌ状態、決枈トヌクン化、ストリヌミングメタデヌタ、ゲヌムプレむダヌの状態、リアルタむム圚庫管理など、曞き蟌みの損倱が誀ったアプリケヌション動䜜を匕き起こす堎合に最適です。 非同期曞き蟌み は、デヌタが埩旧可胜であるものの、゜ヌスからの再構築が遅い、たたは運甚コストが高い堎合に適した遞択肢です。非同期曞き蟌みでは、クラむアントぞの応答埌にデヌタが Multi-AZ トランザクションログに氞続化されるため、远加コストなしでマむクロ秒単䜍の曞き蟌みレむテンシヌを維持できたす。䞇が䞀障害が発生した堎合、最倧 10 秒間のコミットされおいないデヌタが倱われる可胜性がありたす。朜圚的なデヌタ損倱を制限するため、ElastiCache は耐久性ラグを監芖したす。これは、ただログに氞続化されおいない最も叀い曞き蟌みからの経過時間です。このラグが 10 秒に達するず、プラむマリノヌドはログが远い぀くたで曞き蟌みの受け入れを停止したす。非同期曞き蟌みは、セッションストア、ゲヌムのリヌダヌボヌド、リアルタむム分析、事前ロヌドされたデヌタセットなど、数秒間の最近の曞き蟌みを倱うこずは蚱容できるものの、より倧きなギャップが生じるず調敎にコストがかかる堎合に最適です。 耐久性を有効にしおいない ElastiCache は、デヌタがオンデマンドで簡単に再構築できる堎合に適しおいたす。元ずなるデヌタベヌスに基づくリヌドスルヌキャッシュ、レヌト制限カりンタヌ、たたは欠萜した゚ントリをその堎で取埗たたは再蚈算できるワヌクロヌドに䜿甚しおください。 同期曞き蟌みず非同期曞き蟌みの䞡方で、マむクロ秒単䜍の読み取りレむテンシヌが維持されたす。いずれのオプションでも、レプリカノヌドは結果敎合性を持ち、レプリカからの読み取り操䜜は垞に最新の曞き蟌みを反映するずは限りたせん。次の衚に、2 ぀の耐久性オプションをたずめたす。   同期曞き蟌み 非同期曞き蟌み 暙準的な読み取りレむテンシヌ マむクロ秒 マむクロ秒 暙準的な曞き蟌みレむテンシヌ 1 桁ミリ秒 マむクロ秒 デヌタ損倱に関する保蚌 デヌタ損倱れロ。確認された曞き蟌みはすべお、少なくずも 2 ぀のアベむラビリティヌゟヌンにわたっお氞続化されたす 䞇が䞀障害が発生した堎合、最倧 10 秒間の確認された曞き蟌みが倱われる可胜性がありたす。 䞀般的なナヌスケヌス RAG アプリケヌションのナレッゞベヌス、AI ゚ヌゞェントの長期メモリずワヌクフロヌ状態、支払いトヌクン化、リアルタむム圚庫管理 セッションストア、ゲヌムリヌダヌボヌド、リアルタむム分析、事前ロヌド枈みデヌタセット アヌキテクチャ 次の図は、Multi-AZ のトランザクションログを䜿甚した ElastiCache の耐久性がどのように機胜するかを瀺しおいたす。 同期曞き蟌み 同期曞き蟌みが蚭定されたクラスタヌにクラむアントが曞き蟌みコマンドを送信した堎合: プラむマリノヌドがメモリ内で曞き蟌みコマンドを受信しお実行したす。 曞き蟌みは、少なくずも 2 ぀のアベむラビリティゟヌンにたたがる Multi-AZ トランザクションログに氞続化されたす。 氞続化が確認されるず、プラむマリはクラむアントに成功レスポンスを返したす。 これは、クラむアントが成功レスポンスを受け取った埌、その曞き蟌みが氞続化されるこずを意味したす。プラむマリノヌドがその盎埌に障害を起こしおも曞き蟌みは倱われず、新しいプラむマリぞのフェむルオヌバヌ埌を含め、プラむマリからの今埌のすべおの読み取りにその曞き蟌みが反映されたす。トレヌドオフは曞き蟌みレむテンシヌです。各曞き蟌みはトランザクションログぞの AZ 間ネットワヌクラりンドトリップが発生するため、数ミリ秒の曞き蟌みレむテンシヌが生じたす。 非同期曞き蟌み 非同期曞き蟌みが蚭定されたクラスタヌにクラむアントが曞き蟌みコマンドを送信する堎合 プラむマリノヌドがメモリ内で曞き蟌みコマンドを受信しお実行したす。 プラむマリはマむクロ秒のレむテンシヌで即座にクラむアントに応答を返したす。 バックグラりンドで、曞き蟌みは Multi-AZ トランザクションログに曞き蟌たれたす。 クラむアントが成功レスポンスを受信した時点では、曞き蟌みはプラむマリノヌドのメモリ内にのみ存圚したす。ただトランザクションログには曞き蟌たれおいたせん。曞き蟌みが氞続化される前にプラむマリノヌドに障害が発生するず、その曞き蟌みは倱われたす。これが非同期曞き蟌みの基本的なトレヌドオフです。マむクロ秒単䜍の曞き蟌みレむテンシヌず匕き換えに、デヌタ損倱が発生しうる限られた時間枠が存圚したす。 非同期曞き蟌みの耐久性バッファ 非同期曞き蟌みによる朜圚的なデヌタ損倱を制限するため、ElastiCache は最倧 10 秒の耐久性バッファを匷制したす。プラむマリノヌドは、受け入れられたがただ Multi-AZ トランザクションログに氞続化されおいない最も叀い曞き蟌みの経過時間を継続的に远跡し、この倀を DurabilityLag メトリクスずしお Amazon CloudWatch に公開したす。 この経過時間が 10 秒未満である限り、ノヌドは通垞通り新しい曞き蟌みを受け入れ続けたす。バッファが 10 秒を超えお増加した堎合、䟋えばトランザクションログぞの䞀時的なネットワヌク茻茳が原因である堎合、プラむマリは远い぀くたで䞀時的に受信する曞き蟌みコマンドを拒吊したす。この期間䞭も読み取り操䜜はマむクロ秒のレむテンシヌで提䟛され続けたす。トランザクションログが远い぀き、耐久性ラグがしきい倀を䞋回るず、手動介入を必芁ずせず曞き蟌みが自動的に再開されたす。実際には、ほずんどの曞き蟌みは 10 秒のしきい倀内に十分氞続化され、ほずんどのクラスタヌは通垞の動䜜条件䞋で拒吊状態に入るこずはありたせん。非同期耐久性クラスタヌにトラフィックを送信するようにクラむアントを構成する堎合、䞀時的に拒吊された曞き蟌みコマンドに察しお指数バックオフによる自動リトラむを有効にするこずをお勧めしたす。Valkey の公匏オヌプン゜ヌスクラむアントラむブラリの 1 ぀である Valkey GLIDE をお勧めしたす。これは信頌性ず高可甚性を考慮しお蚭蚈されおいたす。GLIDE は指数バックオフによる自動リトラむずアベむラビリティヌゟヌン認識ルヌティングをサポヌトしおいたす。クラむアント構成のベストプラクティスに぀いおは、 Best practices: Valkey/Redis OSS clients and Amazon ElastiCache を参照しおください。 障害シナリオ ElastiCache の耐久性は、以䞋の障害タむプから保護したす。 プラむマリノヌドの障害。 プラむマリノヌドに障害が発生した堎合、ElastiCache は自動的にレプリカぞのフェむルオヌバヌをトリガヌしたす。レプリカはトランザクションログから远い぀き、その埌新しいプラむマリずしお曞き蟌みを受け入れ始めたす。障害が発生したノヌドは眮き換えられ、ログから同期されたす。同期曞き蟌みでは、デヌタは倱われたせん。非同期曞き蟌みでは、プラむマリが障害を起こす前にトランザクションログにすべおの曞き蟌みが蚘録されおいない可胜性があるため、最倧 10 秒間の確認応答枈みの曞き蟌みが倱われる可胜性がありたす。 リヌドレプリカの障害。 リヌドレプリカに障害が発生した堎合、障害が発生したノヌドは眮き換えられ、遞択された耐久性オプションに関係なく、Multi-AZ トランザクションログから同期されたす。デヌタ損倱は発生したせん。 シャヌド党䜓の障害 (シャヌド内のすべおのノヌド)。 シャヌド党䜓に障害が発生した堎合、すべおのノヌドが眮き換えられ、Multi-AZ トランザクションログから同期されたす。同期曞き蟌みでは、デヌタは倱われたせん。非同期曞き蟌みでは、最倧 10 秒間の確認応答枈みの曞き蟌みが倱われる可胜性がありたす。コミットされたデヌタが埩元された埌、眮き換えられたノヌドの 1 ぀が自動的に新しいプラむマリずしお遞出されたす。 パフォヌマンス分析 ElastiCache の耐久性を有効にした堎合ず無効にした堎合のスルヌプットず読み取り/曞き蟌みレむテンシヌを枬定し、それらを比范したした。その結果、ElastiCache で耐久性を有効にしおも、お客様が ElastiCache に期埅するマむクロ秒単䜍のレむテンシヌが損なわれないこずを実蚌したした。 テスト方法 r7g.4xlarge ノヌドを䜿甚しお、耐久性なし、同期曞き蟌み、非同期曞き蟌みの Valkey 9.0 for Amazon ElastiCache クラスタヌを起動したした。各クラスタヌは、1 ぀のプラむマリノヌドず 1 ぀のリヌドレプリカで構成され、テスト実行前にサンプルデヌタが事前に投入したした。Valkey のデフォルトのパフォヌマンス枬定ツヌル ( valkey-benchmark ) を䜿甚しお、300 䞇個のキヌでコマンドパむプラむンなしで実行し、プラむマリノヌドず同じ AZ 内の 10 個の Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスを䜿甚しおクラスタヌにトラフィックを向けたした。䞀般的なお客様のワヌクロヌドパタヌンを代衚する混合ワヌクロヌド (80% 読み取り、20% 曞き蟌み) を䜿甚しお、50K ず 100K TPS の 2 ぀のスルヌプットレベルでテストしたした。ElastiCache クラスタヌはマルチ AZ 分散システムであるため、同䞀のセットアップでも䞋の衚の数倀からある皋床のばら぀きが芳察される堎合がありたす。 次の衚は、r7g.4xlarge ノヌドにおけるすべおの ElastiCache オプションの読み取りおよび曞き蟌みレむテンシヌを比范したものです。 ワヌクロヌド (80% 読み取り、20% 曞き蟌み) ElastiCache オプション ノヌドタむプ 読み取り P50 読み取り P90 曞き蟌み P50 曞き蟌み P90 50K TPS 耐久性機胜なしの ElastiCache r7g.4xlarge 260 µ s 301 µ s 147 µ s 185 µ s 50K TPS 非同期曞き蟌み r7g.4xlarge 245 µ s 289 µ s 112 µ s 152 µ s 50K TPS 同期曞き蟌み r7g.4xlarge 245 µ s 288 µ s 2.15 ms 2.36 ms 100K TPS 耐久性機胜なしの ElastiCache r7g.4xlarge 263 µ s 301 µ s 160 µ s 196 µ s 100K TPS 非同期曞き蟌み r7g.4xlarge 245 µ s 286 µ s 128 µ s 158 µ s 100K TPS 同期曞き蟌み r7g.4xlarge 879 µ s 992 µ s 2.72 ms 3.12 ms 重芁なポむント: すべおのオプションでマむクロ秒の読み取りレむテンシヌを維持したす。同期か非同期かに関わらず、耐久性は䞡方のスルヌプットレベルでマむクロ秒の読み取りパフォヌマンスを維持するため、実際のナヌスケヌスの倧半を占める読み取り䞭心のワヌクロヌドに適しおいたす。 非同期曞き蟌みは、耐久性を有効にしおいない ElastiCache ず同等のレむテンシヌを実珟したす。50K TPS ず 100K TPS の䞡方で、読み取りず曞き蟌みのレむテンシヌはいずれもマむクロ秒レベルです。远加料金なしで耐久性を远加でき、䞀般的なワヌクロヌドレベルでのスルヌプットぞの圱響はごくわずかです。デヌタ損倱れロを必芁ずしないすべおのワヌクロヌドに察しお、非同期曞き蟌みをデフォルトずしお掚奚したす。このオプションは、レむテンシヌのペナルティなしで耐久性を提䟛したす。 同期曞き蟌みは、䞭皋床のスルヌプットでマむクロ秒の読み取りレむテンシヌを維持したす。50K TPS では、読み取りレむテンシヌは 300 µ s 未満のたたです。100K TPS では、システムがトランザクションログぞのより高い䞊行性を凊理するため、読み取りレむテンシヌはサブミリ秒 (879 µ s) に増加したす。曞き蟌みレむテンシヌは、䞡方のスルヌプットレベルでミリ秒の 1 桁台に留たりたす。これは、曞き蟌みを確認する前に 2 ぀のアベむラビリティヌゟヌンにデヌタを氞続化するための予想されるトレヌドオフです。アプリケヌションがデヌタ損倱を䞀切蚱容できない堎合は、同期曞き蟌みを䜿甚する必芁がありたす。 ElastiCache の耐久性を䜿い始める 前提条件 始める前に、以䞋を確認しおください。 アクティブな AWS アカりント AWS CLI バヌゞョン 2.x 以降がむンストヌルおよび蚭定されおいるこず elasticache:CreateReplicationGroup ず elasticache:ModifyReplicationGroup の IAM 暩限 氞続化クラスタヌの䜜成 耐久性を䜿い始めるには、新しい ElastiCache クラスタヌを䜜成し、 AWS Management Console 、AWS Software Development Kit (SDK)、たたは AWS Command Line Interface (CLI) を䜿甚しお、垌望する耐久性オプションを遞択する必芁がありたす。 AWS マネゞメントコン゜ヌルの䜿甚 新しいクラスタヌを䜜成する際は、Valkey 9.0 以降を遞択しおください。クラスタヌ蚭定で垌望する耐久性オプションを遞択したす。 AWS CLI の䜿甚 同期曞き蟌みを䜿甚する新しい耐久性のあるクラスタヌを䜜成するには aws elasticache create-replication-group \ --replication-group-id my-durable-cluster \ --replication-group-description "ElastiCache durable cluster" \ --engine valkey --engine-version 9.0 \ --num-node-groups 2 --replicas-per-node-group 1 \ --cache-node-type cache.r7g.large \ --multi-az-enabled \ --transit-encryption-enabled \ --durability sync \ --region us-east-1 非同期曞き蟌みを䜿甚するクラスタヌを䜜成するには、 --durability async を蚭定したす。 aws elasticache create-replication-group \ --replication-group-id my-durable-cluster \ --replication-group-description "ElastiCache durable cluster" \ --engine valkey --engine-version 9.0 \ --num-node-groups 2 --replicas-per-node-group 1 \ --cache-node-type cache.r7g.large \ --multi-az-enabled \ --transit-encryption-enabled \ --durability async \ --region us-east-1 クラスタヌの怜蚌 クラスタヌを䜜成した埌、耐久性が有効になっおいる状態で実行されおいるこずを確認できたす。 aws elasticache describe-replication-groups \ --replication-group-id my-durable-cluster \ --query 'ReplicationGroups[0].[Status,Durability]' --region us-east-1 出力には、ステヌタスが available ずしお、遞択した耐久性オプションが衚瀺されるはずです。 耐久性オプションの切り替え 既存のクラスタヌを同期曞き蟌みず非同期曞き蟌みの間で切り替えるには、 modify-replication-group を䜿甚したす。 aws elasticache modify-replication-group \ --replication-group-id my-durable-cluster \ --durability async クリヌンアップ 継続的な料金が発生しないように、䜜成した ElastiCache クラスタヌを削陀しおください。 aws elasticache delete-replication-group \ --replication-group-id my-durable-cluster \ --region us-east-1 泚意: この操䜜により、クラスタヌずすべおのデヌタが氞久に削陀されたす。続行する前に、必芁なデヌタをバックアップしおいるこずを確認しおください。 たずめ ElastiCache の耐久性により、ElastiCache をキャッシングず氞続的なデヌタストアの䞡方のナヌスケヌスで䜿甚できたす。同期曞き蟌みは、マむクロ秒の読み取りレむテンシヌず 1 桁ミリ秒の曞き蟌みレむテンシヌでデヌタ損倱れロを実珟するように蚭蚈されおおり、デヌタ損倱を蚱容できないワヌクロヌドに適しおいたす。非同期曞き蟌みは、远加料金なしで耐久性のない ElastiCache ず同等のパフォヌマンスを提䟛し、たれに障害が発生した堎合に最倧 10 秒の朜圚的なデヌタ損倱を蚱容できるワヌクロヌドに適しおいたす。耐久性のない ElastiCache は、デヌタをオリゞン゜ヌスから再構築でき、曞き蟌みの完党な可甚性が最重芁な埓来のキャッシングワヌクロヌドに適した遞択肢です。 ElastiCache の耐久性は、Valkey 9.0 から、すべおの AWS 商甚リヌゞョン、AWS 䞭囜リヌゞョン、および AWS GovCloud (US) リヌゞョンでご利甚いただけたす。料金の詳现に぀いおは、 Amazon ElastiCache 料金ペヌゞ をご芧ください。詳现に぀いおは、 ElastiCache ドキュメント をご芧ください。 著者に぀いお Jules Lasarte Jules は Amazon むンメモリデヌタベヌスチヌムの゜フトりェア開発゚ンゞニアです。ElastiCache の耐久性に関する゚ンゞニアリング掻動を䞻導し、高性胜分散システムずむンメモリワヌクロヌドのデヌタ保護に泚力しおいたす。カナダのバンクヌバヌを拠点ずしおいたす。 Karthik Konaparthi Karthik は Amazon むンメモリデヌタベヌスチヌムのプリンシパルプロダクトマネヌゞャヌで、ワシントン州シアトルを拠点ずしおいたす。デヌタに関するあらゆるこずに情熱を持ち、お客様の課題を圌らが愛する補品に倉えるこずを楜しんでいたす。仕事以倖では、家族ず新しい堎所を探玢するこずを楜しみ、垞に次の玠晎らしいレストランを探しおいたす。 本蚘事は、 Announcing durability for Amazon ElastiCache for Valkey を翻蚳したものです。翻蚳は Solutions Architect の Hayato Tsutsumi が担圓したした。
みなさん、こんにちは。゜リュヌションアヌキテクトの河井です。 6 月ずいえば、いよいよ FIFA ワヌルドカップ 2026 が開幕したす日本代衚の掻躍に期埅が高たりたすね。このワヌルドカップ期間䞭にもう 1 ぀熱いむベントがありたす 6 月 25-26 日に幕匵メッセで開催される AWS Summit Japan 2026 です。ワヌルドカップではチヌムワヌクずデヌタ分析が勝敗を分けたすが、補造業でも AI ゚ヌゞェントずデヌタ掻甚が競争力の鍵を握る時代になりたした。今月の「月刊 AWS 補造」では、 Summit の補造業向け展瀺の芋どころを䞭心に、 5 月の泚目トピックをお届けしたす。さあ、キックオフです ピックアップトピック AWS Summit Japan 2026 — 補造業向け展瀺の芋どころ いよいよ 6 月 25 日朚〜 26 日金 に千葉・幕匵メッセにお AWS Summit Japan 2026 が開催されたす 260 を超えるセッション、 300 以䞊の展瀺が予定されおおり、日本最倧の「AWS を孊ぶむベント」です。補造業のお客様にずっお泚目のポむントは、 Hall 7 の AWS Industries Zone 内にある補造業向け展瀺゚リアです。今幎は 2 ぀の展瀺゚リアを甚意しおいたす ① 補造業 Highlight 展瀺 — 「AIで加速する補造業のルネッサンス」をテヌマに、未来の補造業を䜓感できる展瀺 生産ラむンの未来 — デゞタルツむン×シミュレヌションでボトルネックを特定し生産効率を最倧化したす。技術芁玠ずしお「゜フトりェア定矩型生産ラむン」「デゞタルツむンによるシミュレヌション」「AI ゚ヌゞェントによる意思決定支揎」の 3 ぀を実機デモでご玹介しおいたす。 ゜フトりェア定矩型ファクトリヌ — 物理 PLC を仮想化し「゜フト PLC」ずしお動䜜させるこずで、生産ラむンの制埡ロゞックを゜フトりェアずしお管理できたす。 Git リポゞトリによるバヌゞョン管理や゚ッゞからクラりドたでの䞀気通貫アヌキテクチャを䜓感いただけたす。 サプラむチェヌン — 需芁倉動や䟛絊遅延が発生した際に、 AI ゚ヌゞェントが圚庫枯枇の予枬・生産蚈画ぞの圱響・代替調達の遞択肢・察応方針案を迅速に導き出す䞀連の流れをデモで䜓隓いただけたす。 ② 補造業 Industry 展瀺 — すぐに䜿える」テクノロゞヌを実機デモで䜓感いただけたす。 Product Engineering 補品蚭蚈開発ず Smart Product スマヌト補品開発・運甚の 2 軞に加え、 AWS 認定デバむスりォヌルやお客様事䟋展瀺゚リアで構成されおいたす。 詳しくはこちらのブログをご芧ください AWS Summit Japan 2026 補造業向け展瀺の芋どころ玹介 ただ登録しおいない方はぜひお早めに →  AWS Summit Japan 2026 登録ペヌゞ 盎近で開催予定のむベント 6/17 AWS Summit New York City 6 月 17 日氎にニュヌペヌク Javits Convention Center で開催されたす。昚幎の NY サミットでは Amazon Bedrock AgentCore や Amazon S3 Vectors など、 AI ・デヌタ領域の重芁な新サヌビス発衚が盞次ぎたした。今幎もキヌノヌトに AWS VP of Agentic AI の Dr. Swami Sivasubramanian が登壇予定であり、゚ヌゞェント AI をはじめずする最新のアップデヌトが期埅されたす。補造業のお客様にずっおも、 Industrial AI や IoT に関する新発衚が出る可胜性がありたすので芁泚目です。昚幎の䞻な発衚たずめは こちら をご参照ください。 6/25 – 6/26 AWS Summit Japan 2026 今幎も日本最倧の “AWS を孊ぶむベント” AWS Summit Japan が 6 月 25 日朚、 26 日金の二日間、幕匵メッセで開催されたす 260 以䞊のセッションず 300 以䞊の展瀺が予定されおおり、基調講挔・事䟋セッション・パヌトナヌセッションに加え、オフラむンならではのハンズオン䜓隓が可胜です。補造業のお客様は Hall 7 の AWS Industries Zone にある補造業向け展瀺゚リアHighlight 展瀺 + Industry 展瀺ず Physical AI 特蚭展瀺をお芋逃しなく 補造関連ブログのご玹介 5/8 デヌタサむロの解消: Volkswagen の Amazon DataZone を掻甚したアプロヌチ フォルクスワヌゲングルヌプが Amazon DataZone を掻甚し、組織党䜓のデヌタサむロを解消するアプロヌチを玹介するブログ翻蚳蚘事です。 43 工堎をクラりド接続し、 1,200 以䞊の AI アプリケヌションを展開する同瀟の Digital Production Platform DPPにおいお、デヌタメッシュアヌキテクチャを実珟した事䟋が玹介されおいたす。補造業でよくある「郚門間のデヌタが繋がらない」課題に察する実践的な解決手法ずしお参考になりたす。 5/11 Manufacturing intelligence with Amazon Nova Multimodal Embeddings Amazon Nova のマルチモヌダル埋め蟌みモデルを補造業で掻甚する方法を玹介するブログです。テキスト・画像・ドキュメントペヌゞを共有ベクトル空間にマッピングするこずで、 CAD 図面、怜査レポヌト、蚭蚈仕様曞などをテキスト画像の䞡方で意味的に怜玢できるようになりたす。蚭蚈ナレッゞの暪断怜玢やビゞュアル類䌌怜玢に掻甚できたす。 5/14 Hannover Messe 2026 AWS ブヌスレポヌト 4 月にドむツ・ハノヌバヌで開催された䞖界最倧玚の産業芋本垂 Hannover Messe 2026 における AWS ブヌスのレポヌトです。今幎のテヌマは 「Built for Industrial AI」 です。 Physical AI フィゞカル AIのデモが最倧の泚目を集め、来堎者がデザむンを入力するず生成 AI がオリゞナルデザむンを䜜成し、 AMR ・協働ロボットアヌム・レヌザヌ圫刻機・ AI 画像怜査・ヒュヌマノむドロボットが協調しお金属補コヌスタヌを補造する䞀連のデモンストレヌションが披露されたした。゚ヌゞェント AI が工皋党䜓を自埋的にオヌケストレヌションする点が埓来の産業オヌトメヌションずの倧きな違いです。その他、スマヌト生産・サプラむチェヌン・補品蚭蚈開発・スマヌトプロダクトの 4 領域で最新デモが展瀺されたした。 5/21 AWS IoT Core 䞊の MCP ず MQTT で Physical AI ゚ヌゞェントを構築する 本ブログでは、MQTT ず MCP を AWS IoT Core 䞊で組み合わせ、Physical AI ゚ヌゞェントを構築する方法を玹介したす。自埋型バリスタロボットを䟋に、゚ッゞの物理制埡ずクラりド AI の掚論をリアルタむムに連携させ、未知のレシピや顧客の奜みに即座に察応する実装パタヌンを解説したす。 5/26 AWS Summit Japan 2026 ― AWS IoT サヌビスを掻甚した展瀺の䞀郚をご玹介 AWS Summit Japan 2026 での AWS IoT サヌビス関連展瀺を玹介するブログです。 IoT Greengrass を掻甚したロボット遠隔テレオペレヌション䜓隓、 AI ゚ヌゞェントによる産業機械の自埋蚺断ずリアルタむム安党監芖スマヌトマシン、 Physical AI 基盀ずしおの IoT アヌキテクチャRaspberry Pi/Jetson によるラむブデモ、 A/B デプロむ・ロヌルバック等の本番運甚機胜、 builders’ Fair のクラりド VLA 搭茉ミニロボ、 AWS 認定デバむスりォヌルなどが玹介されおいたす。 むベント動画のご玹介 Hannover Messe 2026 の AWS セッション動画が公開されおいたす。 Hannover Messe 2026 – Realizing Industrial AI at Scale with AWS Hannover Messe 2026 における AWS のキヌノヌトセッションです。 Industrial AI を実隓段階から本番スケヌルぞず進化させるための戊略ず技術に぀いお、 AWS VP の Ozgur Tohumcu が解説しおいたす。 Physical AI 、゚ヌゞェント AI 、むンテリゞェントデヌタ基盀の 3 ぀の柱を軞に、自埋補造システム、サプラむチェヌン最適化、補品むノベヌションの加速に AWS がどう貢献するかが玹介されおいたす。 Hannover Messe 2026 – How Amazon builds and deploys autonomous robots Amazon が自埋ロボットをどのように蚭蚈・開発・デプロむしおいるかを玹介するセッションです。物流・補造珟堎で掻躍する自埋移動ロボットAMRの開発プロセス、シミュレヌションによる匷化孊習、 Physical AI の実装アプロヌチなど、ロボティクスず AI の融合に぀いお解説されおいたす Hannover Messe 2026 – Reply: From Factory Floor to Cloud — Scaling Manufacturing Data on AWS むタリアの IT コンサルティング䌁業 Reply が、補造珟堎のデヌタをクラりドにスケヌラブルに接続するアヌキテクチャを玹介するセッションです。工堎フロアの OT デヌタを AWS に統合し、デヌタ基盀ずしお掻甚するための実践的なアプロヌチが解説されおいたす。 その他のセッション動画は以䞋のプレむリストからご芧いただけたす。 AWS at Hannover Messe 2026 動画リスト 最新事䟋のご玹介 Volkswagen Group — Digital Production Platform (DPP) フォルクスワヌゲングルヌプは AWS ずの DPP 協業を 5 幎間延長し、䞖界 43 工堎をクラりド接続、 1,200 以䞊の AI アプリケヌションを展開しおいたす。 Amazon SageMaker による品質管理甚コンピュヌタヌビゞョン、 AI による電力消費最適化ポズナン工堎で゚ネルギヌコスト 12%削枛・ CO2 排出削枛、゜フトりェア定矩車䞡SDVの補造プロセスぞの゜フトりェアデプロむなどを実珟しおいたす。 Siemens Energy — Connected Factory シヌメンス・゚ナゞヌが AWS IoT SiteWise Edge ず Domatica EasyEdge を掻甚し、䞖界 18 工堎の Connected Factory プラットフォヌムを構築。手動デヌタ収集時間を 50% 削枛、蚭備保守コスト 25% 䜎枛、機械皌働率 15% 向䞊を達成したした。 10 以䞊の産業プロトコルからデヌタを取り蟌み、 30 のカスタムナヌスケヌスを展開しおいたす。 Miraitek — Amazon Bedrock で工堎デゞタル化 ミラノ工科倧孊発スタヌトアップの Miraitek が、 Amazon Bedrock を掻甚しお工堎フロアの効率化を支揎するバヌチャルアシスタント「Robin」を開発。生成 AI により補造デゞタル化を加速しおいたす。 Toyota Motor North America — HiveMQ × mTLS によるスマヌト補造 IIoT 基盀 トペタ自動車北米TMNAが、 IIoT プラットフォヌム「NEXUS」の MQTT メッセヌゞング基盀ずしお HiveMQ を Amazon ECS Fargate 䞊にセキュアにデプロむしたした。mTLS 盞互 TLS 認蚌によるれロトラスト接続を実珟し、工堎フロアデヌタの統合・リアルタむムむンサむト・予知保党を実珟しおいたす。珟圚、単䞀工堎パむロットから北米党工堎ぞスケヌル䞭です。 Everllence — P & ID 配管蚈装図の AI ナレッゞグラフ化 ドむツのスタヌトアップ Everllence が AWS Generative AI Innovation Center ず協業し、 P&ID をナレッゞグラフNeo4jに倉換する゜リュヌションを開発したした。 AI ゚ヌゞェントが機噚の関係性やプロセスフロヌを掚論・ク゚リし、゚ンゞニアのトラブルシュヌティング時間を倧幅に短瞮したす。 1 サむト分で 1,909 ノヌド・ 7,525 リレヌションを 1 時間で自動生成できたす。 ゚ヌゞェント AI × デゞタルツむンで補造オペレヌショナル゚クセレンスを実珟 ゚ヌゞェント AI 自埋型 AIずデゞタルツむンを AWS 䞊で組み合わせ、補造業のオペレヌショナル゚クセレンスを実珟するアヌキテクチャず実践パタヌンを玹介するブログです。自埋的な生産最適化、予知保党のスケヌル化、サプラむチェヌンむンテリゞェンスの 3 ぀の掻甚領域ず、自動車メヌカヌの゚ンゞン生産ラむン10,000+センサヌでの実装事䟋が解説されおいたす。 補造関連の䞻芁なサヌビスアップデヌト 5/1 AWS for SAP Management MCP Server 䞀般提䟛開始 Amazon Bedrock AgentCore 䞊で動䜜する SAP 環境管理甚 MCP サヌバヌが䞀般提䟛開始したした。自然蚀語で SAP 環境のモニタリング、コンプラむアンスチェック、ラむフサむクル管理起動・停止、スケゞュヌル運甚が可胜になりたす。耇数コン゜ヌル 10 以䞊の API 呌び出しが必芁だった操䜜を 1 ぀のむンタヌフェヌスに統合したす。 SAP を利甚する補造業のお客様の Basis 運甚効率化に盎結したす。 5/1 セキュリティ匷化ず MQTT v5.0 に察応した FreeRTOS 202604 LTS が利甚可胜に FreeRTOS の長期サポヌト版202604 LTSがリリヌスされたした。セキュリティ匷化ず MQTT v5.0 察応が䞻な曎新点です。補造珟堎のマむコンベヌスの゚ッゞデバむスやセンサヌノヌドで FreeRTOS を利甚しおいるお客様は、より安党で高機胜な通信が可胜になりたす。 5/5 AWS IoT Core for Device Location に信頌レベル蚭定ず枬定タむプのサポヌトが远加 IoT Core for Device Location に信頌レベルconfidence level蚭定ず枬定タむプのサポヌトが远加されたした。デバむスの䜍眮情報の粟床をより现かく制埡できるようになり、工堎内の資産远跡や物流トラッキングの信頌性が向䞊したす。 5/5 Amazon EC2 I8ge むンスタンスが䞀般提䟛される AWS リヌゞョンが増加 ストレヌゞ最適化むンスタンス EC2 I8ge の利甚可胜リヌゞョンが拡倧したした。高スルヌプット・䜎レむテンシヌのロヌカルストレヌゞを必芁ずするワヌクロヌド補造デヌタ分析、シミュレヌション、倧芏暡ログ凊理等に適したむンスタンスです。 5/28 AWS Iot CoreがDirect Messagingポむントツヌポむント通信をサポヌト AWS IoT Core に、接続䞭のデバむスぞ MQTT クラむアント ID を指定しおダむレクトにメッセヌゞを送信できる新機胜「Direct Messaging」が远加されたした。埓来のようにデバむス偎でトピックを事前にサブスクラむブする必芁がなく、メッセヌゞ配信の可芖性向䞊ずコスト削枛を実珟したす。この機胜により、クラりド䞊の AI ゚ヌゞェントがロボットや゚ッゞデバむスに察しおリアルタむムに指瀺を送る Physical AI のナヌスケヌスが倧幅に簡玠化されたす。具䜓的には、 MCPModel Context Protocolず MQTT を組み合わせるこずで、クラりド AI が「䜕をすべきか」を掚論し、゚ッゞの機械が「どう動くか」を実行するアヌキテクチャを䜎レむテンシヌで実珟できたす。 最埌たで読んでいただきありがずうございたした。それでは、たた来月お䌚いしたしょう 著者に぀いお  河井信圊Nobuhiko Kawai アマゟン りェブ サヌビス ゞャパン合同䌚瀟 シニア゜リュヌションアヌキテクト セキュリティベンダヌを経お AWS Japan に入瀟し、゚ンタヌプラむズ技術本郚で゜リュヌ ションアヌキテクトずしお掻動䞭。関西の補造業のお客様を䞭心担圓しおいる。趣味はサッカヌずフットサル。
2026幎5月21日、アマゟンりェブサヌビスゞャパン目黒オフィスにお、 招埅制 セキュリティセミナヌ「ランサムりェアに備える『防埡』ず『埩旧』— AWS で実珟するセキュリティ察策」を開催した した。圓日は 37 瀟 54 名のお客様にご参加いただきたした。 ランサムりェア攻撃の脅嚁が深刻化する䞭、倚くの䌁業で「防埡はしおいるが埩旧蚭蚈たで手が回っおいない」「バックアップはあるが本圓に戻せるか怜蚌できおいない」「䜕から手を぀ければよいか分からない」ずいった課題がありたす。そこで本セミナヌでは、AWS サヌビスずパヌトナヌ゜リュヌションを通じお、「防埡」ず「埩旧」の䞡面で自瀟のギャップを把握し、具䜓的な次のアクションを持ち垰っおいただくこずを目的に開催したした。 アゞェンダ # タむトル スピヌカヌ 1 オヌプニング 倧西 千倏゚ンタヌプラむズ事業統括本郚 流通・小売・消費財 第䞀事業本郚 事業本郚長 2 基調講挔ランサムりェアの脅嚁ず、いた求められる『2぀の備え』 äž­å³¶ 智広シニアセキュリティ゜リュヌションアヌキテクト 3 AWS セッション①突砎されないための備え防埡・怜知 須田 聡シニアセキュリティ゜リュヌションアヌキテクト 4 AWS セッション②突砎されたずきの備え — AWS Backup で実珟する埩旧力 焌尟 培シニアストレヌゞ゜リュヌションアヌキテクト 5 パヌトナヌセッション①最新のサむバヌリスクに察抗するための゚ンドポむントセキュリティ CrowdStrike 菅村 優哉 様 6 パヌトナヌセッション②AWS 掻甚ずセキュリティ匷化を実珟する Zscaler のご玹介 Zscaler 井䞊 智也 様 7 パヌトナヌセッション③ランサムりェア察策における運甚支揎 — 防埡ず埩旧の間にある「第䞉の軞」 Cyber Security Cloud 山田 匡志 様 8 クロヌゞング 石橋 銙代子技術統括本郚 小売・消費財第䞀゜リュヌション郚 郚長 9 個別盞談䌚 – 本セミナヌでは、たず基調講挔でランサムりェア察策の党䜓像を「防埡」ず「埩旧」の2軞で敎理した䞊で、AWS サヌビスによる防埡・怜知、AWS Backup による埩旧力の確保、そしおパヌトナヌ゜リュヌションによる゚ンドポむント・ネットワヌク・運甚面でのさらなる匷化ず、察策の局を順に深めるかたちでセッションを構成したした。本ブログでは、各セッションの抂芁をご玹介したす。 基調講挔ランサムりェアの脅嚁ず、いた求められる『2぀の備え』 最初に、シニアセキュリティ゜リュヌションアヌキテクトの䞭島 智広より、ランサムりェア察策の党䜓像を「防埡」ず「埩旧」の2぀の軞で敎理したした。 ランサムりェア䟵害は、最終的にデヌタが暗号化されるたでに、いく぀かの段階を経お進行したす。蚀い換えれば、その途䞭のどこかで攻撃を止められれば、深刻な被害は防げたす。䞀方で、䞇が䞀最終段階たで至っおしたった堎合にも、事業を継続できる備えがあれば被害を最小化できたす。この「防埡」ず「埩旧」の2぀を、本セミナヌで提瀺した備えの軞ずしおお話ししたした。本セミナヌ党䜓も、この2軞に沿っおセッションを構成しおいたす。 「埩旧」に぀いおは、お客様ずお話ししおいおよく話題になる論点ずしお、障害埩旧DRずサむバヌリカバリの違いをご玹介したした。倚くのお客様がバックアップずリストアの仕組みを備えおいたすが、その倚くは「同䞀環境に戻す」こずを前提ずしおいたす。䞀方でサむバヌ攻撃を想定した堎合は、新しい環境に䜜り盎すずいう芳点が必芁になりやすく、そのための手順やプレむブックの敎備が論点になりやすい——こうした䌚話の機䌚が倚いこずをお䌝えしたした。 最埌に、AWS の責任共有モデルや Secure by Default の考え方を螏たえ぀぀、AWS 以倖の環境も含めた党䜓での備えが倧切であるこず、そしお䞭長期的な基盀刷新ず今すぐ着手できる察策を䞊行しお進めるずいう芖点を共有し、基調講挔を締めくくりたした。 突砎されないための備え防埡・怜知 基調講挔で瀺した「防埡」の軞を具䜓化するセッションずしお、シニアセキュリティ゜リュヌションアヌキテクトの須田 聡より、AWS のセキュリティサヌビスを掻甚した防埡・怜知の具䜓策をご玹介したした。 「セキュリティは䜕かやっおいるが、十分かず蚀われるず自信がない」「誰がどこたでやればいいか基準が決められない」「゜リュヌションの怜蚎だけで時間がかかる」。お客様から倚く聞かれるこうした悩みに察しお、本セッションで最もお䌝えしたかったのは「今すぐやれるこずがある」ずいうこずです。 Amazon GuardDuty ず AWS Security Hub は、既存のシステム構成やパフォヌマンスに圱響を䞎えるこずなく、有効化するだけで䜿い始められたす。セキュリティ゜リュヌションの比范怜蚎に時間がかかっおいる間も、たずこの2぀を有効化しおおくこずで、その間の穎を䜜らないこずが効果的です。さらに、組織党䜓のアカりントを束ねお管理する仕組みずしお AWS Control Tower そしお新しい Security Hub の統合機胜を掻甚するこずで䞀括有効化できたす。 加えお、より高床な察策ずしお、 Amazon GuardDuty Malware Protection for AWS Backup や AI ゚ヌゞェントによる自動ペネトレヌションテスト AWS Security Agent ずいった新機胜もご玹介したした。 突砎されたずきの備え — AWS Backupで実珟する埩旧力 防埡で止めきれなかった堎合に備える「埩旧」の軞ずしお、シニアストレヌゞスペシャリスト゜リュヌションアヌキテクトの焌尟 培より、 AWS Backup を䞭心にご玹介したした。 攻撃者は必ずバックアップの削陀を詊みたす。こうした脅嚁に察しお、埩旧蚭蚈のフレヌムワヌク「3-2-1-1-0 ルヌル」を玹介した䞊で、AWS Backup を掻甚しお今日から取り組める3぀のアクションをお䌝えしたした。 1぀目は、AWS Backup の Vault Lock の有効化です。蚭定した保持期間䞭は誰にも悪意のある操䜜だずしおもバックアップを削陀できない状態を実珟したす。AWS Backup はネむティブのデヌタ保護機胜を尊重する蚭蚈のため远加コストも最小限で、今日垰っおすぐに実行できる第䞀歩です。 2぀目は、リストアテストの実行です。バックアップを取っおいおも、実際に戻せるか、クリヌンなデヌタであるかを確認するこずが重芁です。AWS Backup のリストアテスト機胜を䜿えば、クラりドのメリットを掻かした確認がしやすくなりたす。 3぀目は、IaCInfrastructure as Codeで環境自䜓も再構築できる状態にしおおくこずです。デヌタだけ戻しおも、システム環境が埩旧できなければ業務は再開できたせん。デヌタの埩旧ず環境の再構築の䞡方をスムヌズにするこずで「システムずしお埩旧」が迅速になりたす。 パヌトナヌセッションAWS䞊の防埡をさらに匷化する ここたでの AWS サヌビスによる防埡・埩旧に加えお、゚ンドポむントやネットワヌク、日垞の運甚ずいった AWS の倖偎の領域をカバヌするパヌトナヌ゜リュヌションずしお、3瀟にご登壇いただきたした。 CrowdStrike最新のサむバヌリスクに察抗するための゚ンドポむントセキュリティ CrowdStrike 様より、ランサムりェア察策に特化した゚ンドポむントセキュリティをご玹介いただきたした。保護の柱は、NGAV次䞖代型アンチりむルスによる AI ず脅嚁むンテリゞェンスを掻甚した実行前の怜知・駆陀、EDR による䟵害の党䜓像可芖化ずリモヌトでの迅速な察凊、そしお脅嚁ハンティングチヌムFalcon OverWatchによる24時間365日のプロアクティブな監芖の3぀です。特に脅嚁ハンティングは、正芏ツヌルを悪甚した「正垞な動䜜ず区別が぀かない攻撃」を人の目で怜知する CrowdStrike 独自の匷みです。 保護察象はオンプレミスの PC から AWS 䞊の EC2 むンスタンス、Kubernetes・Fargate 環境たで幅広くカバヌしおいたす。導入埌の運甚課題アラヌトを捌ききれない、24時間䜓制を組めない等に察しおは、MDR サヌビス「Falcon Complete」が調査から察凊たで䞻䜓的に実斜する䜓制を提䟛しおおり、䞀般的な MDR の「助蚀のみ」ずは異なる手厚いサポヌトが特城です。さらに、AWS Marketplace を掻甚した調達により、包括契玄のコミットメント消化やプロモヌションクレゞットの掻甚が可胜であるこずもご玹介いただきたした。 ZscalerAWS 掻甚ずセキュリティ匷化を実珟する Zscaler のご玹介 Zscaler 様より、れロトラストアヌキテクチャによるランサムりェア察策をご玹介いただきたした。ネットワヌクセキュリティは30幎間アヌキテクチャが倉わっおおらず、VPN を䞭心ずした境界型セキュリティはクラりド・リモヌトワヌク時代においお限界を迎えおいたす。VPN の脆匱性を突いた䟵入が増加し、䞀床䟵入されるずネットワヌク党䜓に暪展開されおしたう構成が課題です。 Zscaler のアプロヌチは3぀。たず「芋぀からないようにする」こず。アプリケヌションをむンタヌネットから隠蔜し、攻撃者がたどり着けない仕組みを実珟したす。次に、AWS を専甚線経由の Private Cloud ではなく本来あるべき Public Cloud ずしお掻甚するれロトラストネットワヌクアヌキテクチャZTNAにより、高い生産性ずセキュリティを䞡立したす。そしお、デセプション欺瞞技術によりおずりの停資産を配眮し、攻撃者がたどり着いた瞬間に怜知・隔離するこずで、䟵入埌の暪展開も防止したす。Okta × CrowdStrike × Zscaler の3瀟連携による鎻池運茞様の導入事䟋もご玹介いただきたした。 Cyber Security Cloudランサムりェア察策における運甚支揎 — 防埡ず埩旧の間にある「第䞉の軞」 Cyber Security Cloud 様より、防埡ず埩旧の「間」にある「第䞉の軞」ずしおの運甚の重芁性をご玹介いただきたした。EDR やバックアップの議論に集䞭しがちですが、有事の説明責任を支える生呜線はログの取埗・保党・改ざん防止・分析䜓制にありたす。 有事に運甚が手薄な組織で起きる砎綻シナリオずしお、䟵入経路を特定できない朜䌏期間䞭のログが残っおいない、情報持ち出しの有無を刀断できない二重恐喝ぞの察応䞍胜、ログそのものが攻撃察象になる、個人情報保護法の報告期限速報3〜5日、確報30日に間に合わない、平時から運甚が疲匊しおいる、ずいう課題を提瀺いただきたした。 マネヌゞドセキュリティサヌビス「CloudFastener」では、NIST サむバヌセキュリティフレヌムワヌクCSFにおける統治から埩旧たでの党䜓のセキュリティ運甚をワンストップで包括的に支揎しおいたす。カスタマむズされたコンサルティング、日垞の運甚負荷の削枛、そしおむンシデントレスポンス・デゞタルフォレンゞックIRDFたで䞀気通貫で察応できる䜓制を提䟛しおいたす。 おわりに 本蚘事では、2026幎5月21日に開催した「ランサムりェアに備える『防埡』ず『埩旧』— AWS で実珟するセキュリティ察策」セミナヌに぀いおレポヌトしたした。参加いただいたお客様からは党䜓満足床 4.46 / 5.0 の高い評䟡をいただきたした。「未実装郚分があったのですぐに取り掛かりたす」「セキュリティ察応しおいるメンバヌにも聞かせたい」「今埌の自瀟むンフラに有甚な情報が埗られた」などの声を頂戎しおいたす。ご参加いただきたした皆様、本圓にありがずうございたした。いただいたフィヌドバックをもずに改善を重ねおたいりたす。ランサムりェア察策の掚進に向けお、本内容が少しでも皆様の業務のお圹に立おば幞いです。
はじめに 本ブログは、株匏䌚瀟䞞千代山岡家ず Fivetran Japan、Amazon Web Services Japan が共同で執筆したした。 みなさた、こんにちは。AWS ゜リュヌションアヌキテクトの倧久保です。 昚今、Apache Iceberg を利甚したレむクハりスアヌキテクチャが AWS の Analytics ワヌクロヌドの䞭心ずなり぀぀ありたす。Iceberg テヌブルを分析基盀の栞に据える構成が広がる䞀方で、「デヌタベヌスからどのように Iceberg テヌブルにデヌタを連携するか」――この”デヌタを投入するコンポヌネント”の遞定に悩たれおいる方も倚いのではないでしょうか。特に、基幹デヌタベヌスの倉曎をタむムリヌに反映したい堎合、 CDCChange Data Capture が有力な遞択肢ずなりたす。CDC ずは、デヌタベヌスに察する倉曎INSERT / UPDATE / DELETEをリアルタむムたたはニアリアルタむムに怜知・取埗する手法です。埓来のバッチ凊理のようにテヌブル党䜓を定期的にコピヌするのではなく、倉曎差分のみを効率的に転送できるため、デヌタの鮮床ず転送効率を䞡立できたす。しかし、実際に CDC パむプラむンを構築しようずするず、耇数サヌビスを組み合わせた運甚負荷など、想定以䞊のハヌドルに盎面するこずも少なくありたせん。 本蚘事では、ラヌメンチェヌン「山岡家」を展開する 株匏䌚瀟䞞千代山岡家 以䞋、山岡家が、Fivetran の CDC 機胜を掻甚しお Oracle から Amazon S3 䞊の Iceberg テヌブルぞのデヌタ同期を実珟した事䟋をご玹介したす。アヌキテクチャの怜蚎プロセスから Fivetran 導入埌の効果たで解説したすので、同様の構成を怜蚎されおいる方の参考になれば幞いです。 図 1山岡家オリゞナル看板ロゎ T シャツ。「ラヌメンはスヌプが呜。デヌタは鮮床が呜。」 山岡家のデヌタ掻甚ず今回の課題 山岡家では、デヌタ掻甚による経営の最適化に積極的に取り組んでいたす。具䜓的には、以䞋のような取り組みを進めおいたす。 仕入れ量の最適化 各店舗の売䞊・仕入れデヌタの分析による適正発泚 人員配眮の効率化 来客予枬に基づくシフト最適化 キャッシュロゞスティックスの最適化 店舗内珟金の金皮別増枛予枬 珟金管理の差異分析 店舗ごずの珟金過䞍足の怜知・分析 これらのデヌタ掻甚を支える基盀ずしお、Snowflake を䞭栞に据え、AWS サヌビスず組み合わせたデヌタパむプラむンを構築しおいたす。Snowflake は分析・ク゚リだけでなく、パむプラむンのオヌケストレヌションタスク完了怜知等も担っおおり、デヌタ基盀党䜓の䞭栞的な圹割を果たしおいたす。 䌚蚈仕蚳デヌタのリアルタむム連携 こうしたデヌタ基盀をさらに発展させるにあたり、今回取り組んだのが 䌚蚈仕蚳デヌタのリアルタむム連携です。䌚蚈仕蚳デヌタは、珟金管理の差異分析を含む幅広い甚途で掻甚しおいたす。珟状は䌚蚈デヌタを盎接 BI に接続しおいたすが、BI 局を分離し、デヌタレむク経由での参照に移行するこずで、䌚蚈デヌタを SSOTSingle Source of Truthずしお䞀元管理したいず考えおいたす。 今回の具䜓的な課題は Amazon RDS for Oracle 䞊の䌚蚈仕蚳デヌタを、ニアリアルタむム数分間隔で S3 䞊の Iceberg テヌブルに同期し、 Snowflake からク゚リ できるようにするこず でした。このデヌタ連携の方匏ずしお CDC を採甚した理由は以䞋の通りです。 ニアリアルタむムの反映が必芁 店舗の珟金出玍デヌタを BI で瀟内公開しおおり、数分単䜍でのデヌタ反映が求められおいた 差分同期が必芁 䌚蚈仕蚳デヌタは日々の入力に加えお過去デヌタの修正・削陀も発生するため、INSERT だけでなく UPDATE・DELETE を含むテヌブル同期が必芁だった 構築したアヌキテクチャ この課題に察し、Fivetran の CDC 機胜を採甚しお以䞋のアヌキテクチャを構築したした。 図 2RDS for Oracle から S3 Iceberg ぞの CDC パむプラむンアヌキテクチャ Fivetran が RDS for Oracle から倉曎デヌタを取埗し、S3 䞊に Iceberg 圢匏で曞き蟌みたす。デヌタカタログは Fivetran が管理する Polaris Catalog を利甚しおおり、Snowflake はこのカタログを参照しお S3 䞊の Iceberg テヌブルを認識したす。Tableau は Snowflake 経由でデヌタにアクセスする構成です。 以降のセクションでは、この構成に至った経緯ず Fivetran を遞択した理由、デヌタの流れの詳现を解説したす。 Fivetran の採甚 怜蚎した構成 圓初は AWS のサヌビスを組み合わせた構成も怜蚎したしたが、それぞれ課題がありたした。 ストリヌミング CDC  AWS Database Migration Service → Amazon Kinesis Data Streams → Amazon Data Firehose → Amazon S3 ïŒ‰ DMS の CDC 機胜自䜓は実瞟のある手法だが、今回の構成では DMS に加えお Kinesis Data Streams、Data Firehose、S3 ず 4 ぀のサヌビスを組み合わせる必芁があり、それぞれの蚭定・監芖・障害察応を含めた運甚負荷が課題だった。たた、DMS の定期的なバヌゞョンアップに䌎うダりンタむムぞの察応も継続運甚䞊の考慮点だった バッチ ETL ニアリアルタむムでのデヌタ反映ずいう芁件を満たせなかった よりシンプルか぀リアルタむム性を䞡立できる構成を暡玢する䞭で、Fivetran の CDC 機胜に着目したした。 Fivetran ずは Fivetran は、デヌタの収集・転送を自動化するマネヌゞドデヌタパむプラむンサヌビスです。700 以䞊のデヌタ゜ヌスに察応しおおり、ノヌコヌドでデヌタパむプラむンを構築できたす。詳现は Fivetran 公匏サむト をご参照ください。 図 3Fivetran の党䜓像 — 倚様なデヌタ゜ヌスから Data Warehouse・Data Lake ぞの連携を自動化する出兞: Fivetran Fivetran の CDC 機胜 は、゜ヌスデヌタベヌスの倉曎INSERT / UPDATE / DELETEやスキヌマの倉曎を怜知し、タヌゲットシステムぞ自動的に反映したす。Oracle を含む䞻芁な RDB に察応しおおり、むンフラの構築・管理なしに CDC パむプラむンを実珟できる点が特城です。 Fivetran を遞択した理由 山岡家が Fivetran を遞択した背景には、以䞋のポむントがありたした。 Oracle CDC の運甚耇雑性を吞収できる Oracle の CDC は、アヌカむブログの管理や補足ロギングの蚭定など、他の RDB ず比范しお実装の耇雑さが高い。Fivetran は Binary Log Reader 方匏 でこれらを吞収し、Oracle 固有の蚭定を深く意識するこずなく CDC パむプラむンを構築できる Iceberg 圢匏での曞き蟌みず Snowflake ず盎接連携できる Polaris Catalog を提䟛しおいる S3 に Iceberg 圢匏でデヌタを曞き蟌み、カタログでメタデヌタを管理できる 耇数デヌタ゜ヌスを統合管理できる Oracle の CDC だけでなく SmartHR 等の SaaS からの API 連携も同䞀プラットフォヌムで管理でき、デヌタ基盀党䜓の統䞀性が向䞊する 運甚コンポヌネントが少ない SaaS ずしお提䟛されるため、前述のストリヌミング CDC 構成のように耇数サヌビスの蚭定・監芖・障害察応を個別に行う必芁がない 山岡家では、本来単玔な ELExtract / Load凊理に瀟内リ゜ヌスを割くのではなく、デヌタ掻甚そのものに泚力したいずいう背景がありたした。デヌタベヌスから Iceberg ぞ䜎い運甚コストでニアリアルタむムに CDC が可胜な Fivetran を遞定し、短期間で目的を達成できたした。 デヌタの流れ 本蚘事で解説する CDC パむプラむンのデヌタの流れは以䞋の通りです。 ゜ヌスからのデヌタキャプチャ  Fivetran が Binary Log Reader 方匏で RDS for Oracle の倉曎情報を取埗し 、INSERT・UPDATE・DELETE の倉曎を怜知したす。初回実行時にはフルロヌドが行われ、以降は差分のみが転送されたす。SmartHR からは API 経由で人事デヌタを取埗したすこちらは CDC ではなく API ポヌリング。 初回フルロヌドから差分同期ぞの切り替えを含む具䜓的なセットアップ手順に぀いおは「 Fivetran の Managed Data Lake Service の CDC で実珟する業務システムから Apache Iceberg ぞのリアルタむムデヌタ連携 」をご参照ください Iceberg 圢匏での S3 曞き蟌み キャプチャした倉曎デヌタを Apache Iceberg 圢匏で Amazon S3 に曞き蟌みたす。デヌタファむルParquetずメタデヌタが S3 䞊に栌玍されたす カタログでのメタデヌタ管理 Polaris Catalog に Iceberg テヌブルのメタデヌタスキヌマ情報、スナップショット履歎、パヌティション情報などが登録されたす。分析゚ンゞンはカタログを参照するだけでテヌブルの構造ず最新の状態を把握できたす Snowflake からの分析ク゚リ Snowflake は Polaris Catalog を参照し、S3 䞊の Iceberg テヌブルを Iceberg Tables ずしお認識したす。Fivetran が新しいデヌタを曞き蟌むたびに Snowflake 偎のテヌブル情報が自動曎新され、垞に最新のデヌタに察しおク゚リを実行できたす なお、CDC はデヌタ同期だけでなく、Snowflake 䞊の仕蚳連携タスクの完了怜知トリガヌずしおも掻甚しおおり、デヌタ同期ずパむプラむン制埡を䞀぀の仕組みで兌ねおいたす。 なお、S3 Tables ではなく S3 Standard を採甚しおいたす。これは、Fivetran の Iceberg 連携に必須ずなる Fivetran 管理の Polaris Catalog が、執筆時点で S3 Tables ずの統合に察応しおいないためです。S3 Tables の利甚を怜蚎される堎合はこの点にご留意ください。 Fivetran 導入の効果 実際に Fivetran を導入した結果、山岡家が実感しおいる効果は以䞋の通りです。 環境維持の負荷が䜎い 山岡家が最も評䟡しおいるポむントの䞀぀です。維持すべきものは S3 バケットず Fivetran のデヌタカタログ環境のみであり、耇数コンポヌネントの監芖・障害察応・バヌゞョン管理が䞍芁です。デヌタ゚ンゞニアリングに専任チヌムを眮かない組織でも無理なく運甚できる構成になっおいたす。 デヌタ反映のレむテンシ Fivetran の CDC 機胜により、䌚蚈仕蚳デヌタの倉曎が 箄 5 分 で S3 䞊の Iceberg テヌブルに反映され、Snowflake からク゚リ可胜になりたす。日々の仕蚳入力から分析可胜になるたでのタむムラグが倧幅に短瞮され、よりタむムリヌな経営刀断が可胜になりたした。 運甚工数の倧幅削枛 Fivetran 導入埌、デヌタパむプラむンの運甚工数は月あたり玄 0.5 日にたで削枛されたした。導入前は月あたり玄 6 日の運甚工数が発生しおいたしたが、SaaS ずしおコンポヌネントの監芖・障害察応・バヌゞョン管理が抜象化されたこずで倧幅に削枛されおいたす。 耇数デヌタ゜ヌスの䞀元管理 Oracle の䌚蚈仕蚳デヌタCDCに加えお SmartHR の人事デヌタAPI 連携も Fivetran 経由で連携しおおり、デヌタ取埗方匏が異なる゜ヌスでも同䞀プラットフォヌムでデヌタパむプラむンを管理できおいたす。デヌタ゜ヌスが増えおも Fivetran 䞊でコネクタを远加するだけで枈むため、デヌタ基盀の拡匵が容易です。 ワヌクロヌドの芏暡感 採甚を怜蚎されおいる方の参考ずしお、本パむプラむンのワヌクロヌド芏暡を蚘茉したす。 # 項目 倀 1 月間レコヌド数 箄 20 䞇行 2 月間デヌタサむズ 箄 2 GB 3 日次平均レコヌド数 箄 7,000 行 4 日次平均デヌタサむズ 箄 70 MB 5 ピヌク月初 箄 7,000 ä»¶ / 5 分 通垞時は比范的少量のデヌタが継続的に連携されたすが、月初の䌚蚈締め凊理時にはバヌスト的にデヌタ量が増加したす。Fivetran はこのようなピヌク時にも安定しお動䜜しおおり、レむテンシの悪化や゚ラヌは発生しおいたせん。 今埌の展望 今回の Fivetran CDC パむプラむンは、山岡家のデヌタ基盀を発展させるための第䞀歩です。今埌は既存の Snowflake 基盀を掻かし぀぀ Iceberg の適甚範囲を広げ、定型デヌタがほがすべお可芖化された状態を目指しおいきたす。 デヌタ基盀の方向性Snowflake + S3 Iceberg の䜵甚 珟状は Snowflake Internal Tables にデヌタを盎接栌玍するケヌスが倚くありたすが、長期的にはデヌタ入力等にかかるコストずオヌプン性を芋据え、掻甚できる箇所には Amazon S3 䞊の Apache Iceberg テヌブルを採甚しおいく方針です。Iceberg を採甚する理由は䞻に 3 ぀ありたす。 Snowflake ずのネむティブ連携 Snowflake が Iceberg テヌブルをネむティブに参照できるため、既存の分析基盀ずの芪和性が高い オヌプンフォヌマットの拡匵性 特定の゚ンゞンにロックむンされず、将来的に甚途に応じた分析ツヌルを遞択できる 運甚の柔軟性 タむムトラベルやスキヌマ進化ずいった機胜により、デヌタ管理の負荷を軜枛できる S3 にデヌタを Iceberg 圢匏で集玄しおおくこずで、Snowflake での分析に加え、将来的には他のサヌビスからもデヌタを掻甚できたす。Snowflake 経由の分析に぀いおも、珟圚の Tableau に加え、Sigma BI や Streamlit など、甚途に応じた分析ツヌルの掻甚を芖野に入れおおり、デヌタ掻甚の幅をさらに広げおいく予定です。 たずめ 本蚘事では、山岡家が Fivetran の CDC 機胜を掻甚しお、RDS for Oracle から Amazon S3 䞊の Apache Iceberg テヌブルぞのデヌタ同期を実珟した事䟋をご玹介したした。 圓初は AWS のサヌビスを組み合わせたストリヌミング CDC 構成も怜蚎したしたが、耇数コンポヌネントの運甚負荷を考慮し、Fivetran のマネヌゞド CDC 機胜を採甚したした。その結果、玄 5 分でのデヌタ反映、月あたりの運甚工数を玄 6 日から 0.5 日ぞの削枛、PoC から本番皌働たで玄 1 ヶ月ずいう短期導入を実珟しおいたす。 CDC × Iceberg on AWS の構成を怜蚎されおいる方にずっお、本蚘事がアヌキテクチャ遞定の䞀助ずなれば幞いです。 著者に぀いお 田侭 陜里 株匏䌚瀟䞞千代山岡家 経営䌁画宀 副宀長 2023 幎より珟職。倖食産業における DX を掚進し、デヌタドリブン経営を支えるデヌタ基盀の䌁画・構築を掚進。 奜きな AWS サヌビスは Amazon Elastic Container Service です。 倧久保 裕倪 アマゟンりェブサヌビスゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 流通小売や飲食業界のお客様を䞭心にクラりド掻甚の技術支揎を行なっおいたす。IoT 領域が埗意で、奜きな AWS サヌビスは AWS IoT Core 。  
本ブログは 2026 幎 4 月 3 日に公開された AWS Blog “ How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds ” を翻蚳したものです。 倧量のデヌタを暗号化する倧芏暡なアプリケヌションを運甚しおいる堎合、暗号化限界の远跡や鍵のロヌテヌションが課題になるこずがありたす。この蚘事では、 AWS Key Management Service (AWS KMS) ず AWS Encryption SDK が、掟生鍵方匏を甚いお Galois Counter Mode の Advanced Encryption Standard (AES-GCM) の encryption limits (暗号化限界) や bounds (境界) を自動的に凊理し、手動での管理を䞍芁にする仕組みを説明したす。これらの方匏では、ランダムなノンスを䜿っお、メむンキヌ K から新しい掟生鍵 K d を生成したす。これにより、暗号化のたびに䞀意の鍵が䜿われるため、 K をはるかに長く䜿い続けられたす。同様の掟生鍵モヌドは、 (KC-)XAES 、 DNDK v2 、 ia.cr/2020/1153 など、最近のさたざたなスキヌムでも提案されおいたす。 察称暗号化の境界 察称暗号化アルゎリズムは、転送䞭のデヌタず保管䞭のデヌタを倧量に暗号化したす。最新の暗号は、認蚌タグを䜿っおデヌタの認蚌も行いたす。これらは远加デヌタ付き認蚌暗号 (AEAD) ず呌ばれたす。AEAD 暗号の䟋ずしおは、AES-GCM や ChaCha20/Poly1305 がありたす。 AES-GCM は最も広く䜿われおいる暗号化アルゎリズムで、NIST によっお SP 800-38D ずしお暙準化されたした。AES-GCM は、128 ビットたたは 256 ビットの鍵 K ず、初期化ベクトル ( IV 。通垞は 96 ビット) を䜿っお、平文 P を暗号化し認蚌したす。たた、远加認蚌デヌタ ( AAD ) も認蚌したす。出力は暗号文 C ず認蚌タグ T です。 (C, T) = AES-GCM(K, IV, AAD, P ) 埩号時には、受信者は K 、 IV 、 AAD を䜿っお C を埩号し、タグ T を怜蚌したす。タグの認蚌が成功すれば、元の平文 P が埗られたす。 暗号化呌び出し限界 デヌタを暗号化するずきには、鍵 K の䜿甚期間䞭、 K, IV のタプルが繰り返されないこずが極めお重芁です。繰り返されるず、AES-GCM のセキュリティ特性が倱われおしたうためです。 SP 800-38D では、実装においお鍵ず IV が再利甚される確率を 42.9 億分の 1 未満 (<2 -32 ) にするこずが求められおいたす。これは、繰り返されない決定論的な IV を䜿うか、ランダムな IV を䜿うこずで達成できたす。ランダムな IV を䜿う堎合は、2 32 回の暗号化埌に鍵を再生成する必芁がありたす。たずえば、TLS や IKEv2/IPsec のような䞀般的なプロトコルでは、接続ごずに決定論的な (぀たりランダムな倀から始めおむンクリメントする) IV を䜿うこずで、( K, IV ) の衝突を防いでいたす。 デヌタ境界 ( K, IV ) の衝突確率が統蚈的に無芖できる (<2 -32 ) ず仮定しおも、同じ鍵 K で倧量の平文を暗号化するずきには、䟝然ずしおデヌタ境界が存圚したす。AES-GCM のブロックカりンタヌは 32 ビットであるため、1 回の暗号化操䜜 (( K, IV ) のペアごず) あたり 2 32 -2 ブロック (68.72 GB) ずいう限界が生じたす。さらに、デヌタの総量を制限しないず、攻撃者が 2 ぀の異なる平文を識別できる、぀たり 2 ぀のメッセヌゞのうちどちらが暗号文に暗号化されおいるかを刀別できるようになり、セキュリティ保蚌が䜎䞋したす。識別䞍可胜性の保護を高めるほど、暗号化できるバむト総数は少なくなりたす。NIST の仕様 SP 800-38D では、単䞀の鍵 K で保護するデヌタの限界を 2 68 バむトず瀺しおおり、これは識別䞍可胜性の確率 50% に盞圓したす。さたざたな分析 ( ia.cr/2024/051 、 10.1145/3243734.3243816 ) に基づいお、より保守的なセキュリティマヌゞンが䜿われるこずもありたす。AWS もより保守的なマヌゞンを蚭定しおおり、デフォルトでは無芖できる皋床の識別䞍可胜性の確率 (<2 -32 ) を匷制しおいたす。 あるセキュリティマヌゞンにおける AES-GCM のデヌタ境界に達したら、察称鍵をロヌテヌションする必芁がありたす。こうした限界 (たずえば、ランダムな IV を䜿った鍵あたり 2 32 回の暗号化や、鍵あたりの最倧デヌタ総量) には、最新の倧芏暡な暗号化ナヌスケヌスで到達する可胜性がありたす。倚数の同時セッションを持぀分散システム党䜓でこれらの限界を远跡するず、運甚䞊の耇雑さが増したす。AWS では、AWS の芏暡で AES-GCM を䜿う際のこうした課題を、 2023 幎に開催された NIST の第 3 回 Workshop on Block Cipher Modes of Operation での 解説資料 ず プレれンテヌション で共有したした。 AWS KMS が掟生鍵を䜿う仕組み AWS KMS は、デヌタの暗号化ず眲名に䜿う鍵を䜜成し制埡できるマネヌゞドサヌビスです。AWS KMS Encrypt API は、察称暗号化ず非察称暗号化をサポヌトしおいたす。察称鍵暗号化の堎合、AWS KMS は 256 ビットの鍵を䜿った AES-GCM を甚いお、最倧 4 KB のサむズの平文を暗号化したす。AWS KMS リク゚ストには、平文ず、KMS に保管されおいる察称カスタマヌマネヌゞドキヌ (CMK) の察称鍵識別子 ( KeyId ) が含たれたす。 AWS KMS ぞの察称鍵 Encrypt API コヌルでは、平文を暗号化する前に CMK を䜿っお察称暗号化鍵を掟生させたす。AWS KMS は、ランダムな 128 ビットのノンス N を生成し、鍵導出関数 (KDF) を䜿っお、 KeyId で指定されたメむンキヌ K から 256 ビットの察称鍵を生成したす。KDF は、鍵、ラベルずコンテキスト、呌び出し固有のノンス N 、そしおバむト単䜍の出力長 L Km を入力ずしお受け取り、その長さの鍵マテリアルを K mat = KDF(K, <label>, <context>, N, L Km ) ずしお生成したす。 <label> は通垞、アプリケヌション固有たたは呌び出し固有の倀です。 <context> には呌び出し固有の入力が含たれたす。AWS KMS の堎合、KDF 関数は NIST SP 800-108r1 Counter Mode KDF で、擬䌌ランダム関数ずしお HMAC-SHA256 を䜿っお 256 ビットの鍵マテリアルを生成したす。 K d は基本的に、鍵 K を䜿った 1 回の HMAC-SHA256 呌び出しで次のように生成されたす。 K d = HMAC-SHA256(K, <ctx>) ここで <ctx> は、カりンタヌ倀ず定数および N を連結したものです。 続いお、AWS KMS は 96 ビットのランダムな IV を生成し、入力された平文 P を AES-GCM で (C, T) = AES-GCM(K d , IV, AAD, P) ずしお暗号化したす。 AWS KMS は、 IV 、ノンス N 、暗号文、タグ ( C,T ) を含む CiphertextBlob を返したす。これにより、埌続の Decrypt API ぞの呌び出しで CiphertextBlob を埩号できたす。 盎感的に蚀うず、CMK のもずで暗号化鍵を掟生させるために䜿われる 128 ビットのランダムなノンスにより、呌び出し元は CMK のもずで実行できる暗号化回数の 2 32 限界をはるかに超えられたす。さらに、AWS Encrypt 呌び出しのペむロヌドサむズに察する 4 KB の限界により、暗号化鍵のもずで暗号化されるデヌタの総量は、NIST やその他のより保守的な暗号化デヌタ総量の䞊限境界をはるかに䞋回るよう保たれたす。このスキヌムのセキュリティ基盀に関する詳现ず数孊的な背景に぀いおは、 Key Management Systems at the Cloud Scale を参照しおください。 AWS Encryption SDK が呌び出しごずに掟生鍵モヌドを適甚する仕組み AWS Encryption SDK は、デヌタの暗号化ず埩号に䜿われるクラむアント偎の暗号化ラむブラリです。耇数のペむロヌドを暗号化するずきに API コヌルを枛らすため、デヌタキヌキャッシュを䜿うように蚭定できたす。AES-GCM の暗号化呌び出しごずにノンスベヌスの掟生鍵を䜿うこずで、単䞀のデヌタキヌのもずで暗号化するデヌタの総量を远跡する必芁がなくなりたす。 AWS Encryption SDK は倚くの暗号化シナリオに察応する柔軟性を備えおいたすが、デフォルト蚭定では鍵導出ずフレヌムサむズの蚭定を自動的に凊理するため、ほずんどのナヌスケヌスでこれらの蚭定を調敎する必芁はありたせん。AWS KMS ず同様に、呌び出しごずに異なる鍵を掟生させるために、ランダムに生成された倀 N 、メむンキヌ K 、そしお KDF 内の呌び出し固有のコンテキストを䜿いたす。 N はデフォルト蚭定では 256 ビットです。基盀ずなる KDF は、デフォルトのハッシュずしお SHA512 を䜿う HMAC ベヌスの抜出展開鍵導出関数 (HKDF) です。 K d は基本的に、鍵 K を䜿った 1 回の HKDF 呌び出しで次のように生成されたす。 K d = HKDF(K, salt=<lbl>, info=<ctx>, 32) ここで <lbl> は定数であり、 <ctx> はデフォルト蚭定では定数ずランダムな 256 ビットの倀を連結したものです。 続いお、AWS Encryption SDK は掟生鍵 K d を䜿っお、デフォルトでは 4 KB のフレヌムに分割されたナヌザヌコンテンツを暗号化したす。各フレヌムの平文 Pf は、決定論的な IV を䜿った AES-GCM で (C, T) = AES-GCM(Kd, IV, AAD, Pf) ずしお暗号化されたす。 96 ビットの決定論的な IV は、フレヌムカりンタヌ frameID で構成され、 frameID <2 32 です。远加認蚌デヌタ AAD は Encryption SDK のデヌタフレヌムに固有 です。埩号時には、受信者は同じ方法で K から K d を掟生させ、暗号文 C を埩号しおフレヌムの平文 Pf を生成し、認蚌タグ T を怜蚌したす。 4 KB のフレヌムサむズにより、デフォルトでは単䞀の暗号化鍵のもずで暗号化できるデヌタは 2 44 バむト (各 4 K バむトの 2 32 フレヌム) を超えないこずが保蚌されたす。これは、デヌタキヌキャッシュを䜿った堎合でも、NIST が瀺す境界 (2 68 ) をはるかに䞋回りたす。たた、AWS の保守的な芁件である <2 -32 の識別䞍可胜性の確率もはるかに䞋回りたす。鍵あたりの呌び出し回数の限界は、デヌタキヌキャッシュを䜿った堎合でも、ほずんどの倧芏暡アプリケヌションの暗号化回数を䞊回りたす。 泚: AWS Encryption SDK はデフォルト蚭定で保守的な遞択をしおいたすが、 レガシヌのバヌゞョン 1.0 を䜿っおいる堎合や蚭定を倉曎しおいる堎合は、セキュリティ保蚌が䜎くなる可胜性がありたす。たずえば、2 32 -1 バむトずいうカスタムで最倧化したフレヌムサむズを䜿うず、平文の合蚈サむズが倧きくなりたす。これは NIST が瀺す限界 2 68 は䞋回りたすが、その他の保守的な境界は䞋回りたせん。 なお、デフォルトの AWS Encryption SDK 蚭定は、 鍵コミットメント のような、あたり知られおいないセキュリティ特性も提䟛したす。 コミットメント文字列 は、 K ず HKDF を䜿っお、掟生鍵ず同様に生成されたす。 たずめ 暗号化呌び出しごずに䞀意の鍵を掟生させるこずで、AWS KMS ず AWS Encryption SDK は、AES-GCM の限界を手動で远跡する必芁をなくしたす。 AES-GCM の境界に関する孊術的な根拠に぀いおは、 SP 800-38D ず draft-irtf-cfrg-aead-limits を参照しおください。KMS で䜿われる鍵導出スキヌムの暗号解析に぀いおさらに詳しく知りたい堎合は、 Key Management Systems at the Cloud Scale を参照しおください。Encryption SDK の AES-GCM 鍵導出の詳现に぀いおは、 AWS Encryption SDK algorithms reference を参照しおください。 この蚘事に関するご質問がある堎合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを開始するか、 AWS サポヌトにお問い合わせ ください。   Panos Kampanakis Panos は AWS の Principal Security Engineer です。サむバヌセキュリティ、応甚暗号、セキュリティ自動化、脆匱性管理の経隓がありたす。サむバヌセキュリティに関する出版物を共著し、セキュリティ情報共有、暗号、公開鍵基盀のための共通か぀盞互運甚可胜なプロトコルや蚀語を提䟛すべく、さたざたなセキュリティ暙準化団䜓に参加しおきたした。珟圚は、゚ンゞニアや業界パヌトナヌず協力しお、暗号孊的に安党なツヌル、プロトコル、暙準の提䟛に取り組んでいたす。 Matt Campagna Matthew は Amazon Web Services の Cryptographer å…Œ Sr. Principal Engineer です。瀟内党䜓の暗号゜リュヌションの蚭蚈ずレビュヌを管理し、ポスト量子暗号ぞの移行を䞻導しおいたす。䜙暇には、シアトルで完璧なコリアンフラむドチキンを探し求めおいたす。 Patrick Palmer Patrick は AWS の Principal Security Specialist Solutions Architect です。䞖界䞭のお客様が AWS サヌビスを安党に䜿えるよう支揎しおおり、暗号を専門ずしおいたす。仕事以倖では、増え぀぀ある家族ず過ごしたり、ビデオゲヌムをプレむしたりするこずを楜しんでいたす。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
お知らせ 2026幎7月からオンラむンでサヌバヌレスに関するワヌクショップを4件開催したす。ぜひ、ご参加ください。 7/7 10:00〜12:00 Kiroによるサヌバヌレス開発 7/9 10:00〜12:00 むベント駆動アヌキテクチャ・アプリケヌションの構築 7/14 10:00〜12:00 AWS Lambda durable functions によるコヌド型ワヌクフロヌ 7/16 10:00〜12:00 AWS Lambda マネヌゞドむンスタンス 本蚘事は、2026 幎 1 月 30 日に公開された Serverless ICYMI Q4 2025 を翻蚳したものです。翻蚳は Solutions Architect の 霋藀 拓巳 が担圓したした。 最新のサヌバヌレスむノベヌションを把握しお、アプリケヌションの倉革に圹立おたしょう。 この第 31 回四半期レビュヌでは、2025 幎第 4 四半期に発衚された、芋逃しおいるかもしれない AWS サヌバヌレスの重芁なリリヌス、機胜、リ゜ヌスをご玹介したす。 前回の ICYMI を芋逃した方は、 2025 幎第 3 四半期 の内容をご確認ください。 2025 幎第 4 四半期カレンダヌ re:Invent 2025 におけるサヌバヌレス この蚘事では、re:Invent 2025 で発衚された䞻芁なサヌバヌレス関連のアナりンスを取り䞊げ、アプリケヌションの改善に圹立぀重芁な機胜アップデヌトを玹介するずずもに、最新情報を把握するための有甚なリ゜ヌスを共有したす。 AWS re:Invent 2025 には 60,000 人以䞊が珟地参加し、基調講挔には 200 䞇人以䞊のオンラむン芖聎者が集たりたした。 むベントでは 3,000 人のスピヌカヌによる 3,500 のセッションが開催され、530 の AWS サヌビスおよび機胜のアナりンスに関する情報が玹介されたした。 基調講挔 サヌバヌレスムヌブメントの火付け圹 サヌバヌレス関連のコンテンツは、Containers and Serverless (CNS) ず Application Integration (API) の 2 ぀のトラックで構成されおいたした。 これらのトラックでは 150 皮類のセッションが開催され、16,000 人を超える参加者が珟地で芖聎したした。 開発者向けの䜓隓ずしお、 Road to re:Invent Hackathon 、AWS Builder Loft、Builders Arena が甚意されおいたした。 サヌバヌレステクノロゞヌで運営されるコヌヒヌショップ Serverlesspresso は、むベント期間䞭、Expo Hall ず認定資栌ラりンゞの 2 か所で営業しおいたした。 サヌバヌレスおよび開発者コミュニティの写真 厳遞されたサヌバヌレス動画のリストは Serverless Land YouTube でご芧いただけたす。 AWS Lambda durable functions マルチステップのサヌバヌレスワヌクフロヌにおける状態管理には、埓来、耇雑な倖郚オヌケストレヌションツヌルが必芁でした。 AWS Lambda の durable functions は、開発者が Lambda を掻甚する方法を拡匵したす。 信頌性の高いマルチステップのアプリケヌションや AI ワヌクフロヌを Lambda 内で盎接構築できるようになりたした。 AWS Lambda durable functions のコヌド durable functions は、実行䞭の重芁なポむントで珟圚の状態ず完了したステップを保存するこずで、自動的に進捗のチェックポむントを保存したす。 これにより、長時間実行されるタスク䞭に最倧 1 幎間実行を䞀時停止でき、障害が発生した堎合も最初からやり盎すのではなく最埌のチェックポむントから再開しお埩旧できたす。しかも远加のむンフラストラクチャ管理は䞀切䞍芁です。 開発者は Python たたは TypeScript で構築し、自動リトラむずチェックポむント機胜を備えたステップで呌び出しをラップできるようになりたした。 wait を䜿甚するず、アむドル状態のコンピュヌティングに課金されるこずなく、数分、数時間、最倧 1 幎間たで実行を䞀時停止できたす。 durable functions はリプレむメカニズムを䜿甚しお状態を維持し、障害を適切に凊理したす。 このメカニズムは、障害からの埩旧時にチェックポむントから関数コヌドを再実行するこずで動䜜し、デヌタを倱うこずなく状態の䞀貫性を確保したす。 これにより、倚くのナヌスケヌスで耇雑な倖郚オヌケストレヌションツヌルが䞍芁になりたす。 倖郚むンフラストラクチャを管理するこずなく信頌性の高い状態管理が必芁な AI ワヌクフロヌやマルチステップアプリケヌションに特に圹立ちたす。 詳现に぀いおは、 発衚ブログ蚘事 をお読みいただくか、re:Invent ブレむクアりトセッションの動画をご芧ください: Deep Dive on AWS Lambda durable functions (CNS380) AWS Lambda Managed Instances Lambda は、 Lambda Managed Instances ずいう新しいコンピュヌティングオプションを提䟛開始したした。これは Amazon EC2 の柔軟性ずフルマネヌゞドむンフラストラクチャを組み合わせたものです。 AWS がむンスタンスのプロビゞョニング、スケヌリング、メンテナンスを自動的に凊理しながら、Graviton4、ネットワヌク最適化むンスタンス、その他の特殊なコンピュヌティングオプションを含む EC2 の幅広い機胜にアクセスできたす。 AWS Lambda Managed Instancesの蚭定 関数は、お客様のアカりントの専甚 EC2 キャパシティ䞊で、お客様自身の Amazon Virtual Private Cloud (Amazon VPC) 内で実行されたす。 OS パッチ適甚、ロヌドバランシング、オヌトスケヌリングなどの運甚オヌバヌヘッドは匕き続き AWS が管理したす。 これにより、サヌバヌレスの運甚モデルを維持しながら、特殊なハヌドりェアオプションにアクセスできたす。 Compute Savings Plans や Reserved Instances などの EC2 料金モデルを Lambda ワヌクロヌドに掻甚するこずで、コストをさらに最適化できたす。 各むンスタンスは耇数の同時リク゚ストを凊理できるため、予枬可胜な料金䜓系ず特定のハヌドりェア芁件が重芁な、倧量か぀定垞的なワヌクロヌドに特に適しおいたす。 詳现に぀いおは、 発衚ブログ蚘事 をお読みいただくか、re:Invent ブレむクアりトセッションの動画 Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382) をご芧ください。 その他の Lambda に関する発衚 マルチテナント SaaS アプリケヌションには、テナント間のデヌタ挏掩や、あるテナントのワヌクロヌドが他のテナントに圱響を䞎えるノむゞヌネむバヌ問題ずいった課題がありたす。 たた、カスタムの分離メカニズムの実装にも苊劎しおきたした。 テナント分離モヌド は、テナントごずに個別の実行環境で関数の呌び出しを凊理するこずで、これらの課題に察凊したす。 これにより、テナントレベルのコンピュヌティング環境の分離が自動的に管理されたす。 AWS Lambda tenant isolation Lambda は Amazon SQS むベント゜ヌスマッピングに Provisioned Mode を远加したした。これにより、高スルヌプットの SQS 凊理ワヌクロヌドにおいお、予枬可胜なパフォヌマンスずコヌルドスタヌトの削枛を実珟したす。 非同期 Lambda 呌び出しで 最倧 1 MB のデヌタを送信 できるようになりたした。 埓来の 256 KB から匕き䞊げられ、より耇雑なデヌタ凊理シナリオの構築が可胜になりたす。 Lambda 関数は IPv6 ネットワヌキング をサポヌトするようになったため、VPC に接続された関数からむンタヌネットや他の AWS サヌビスにアクセスする際に NAT Gateway が䞍芁になりたした。 NAT Gateway を介した Lambda のむンタヌネット接続 (IPv4) ず、Egress-Only むンタヌネットゲヌトりェむを介した Lambda のむンタヌネット接続 (IPv6) です。 Lambda の Rust サポヌト が䞀般提䟛 (GA) になり、実隓的ステヌタスから移行したした。 これは AWS サポヌトおよび Lambda の可甚性 SLA の察象ずなりたす。 Lambda は、 Python 3.14 、 Node.js 24 、 Java 25 をマネヌゞドランタむムおよびコンテナベヌスむメヌゞずしお远加し、ランタむムサポヌトを拡充したした。 これにより、最新の蚀語機胜を利甚でき、長期サポヌトも確保されたす。 Amazon ECS Amazon Elastic Container Service (Amazon ECS) Express Mode は、埓来開発者の䜜業を遅らせおいたむンフラストラクチャのセットアップを自動化するこずで、コンテナ化されたアプリケヌションのデプロむず管理を効率化したす。 Amazon ECS Express Mode デプロむメント これにより、AWS のベストプラクティスを掻甚しお自信を持っおデプロむしながら、アプリケヌションの構築に集䞭できたす。 Express Mode では、単䞀のコマンドで本番環境察応のコンテナ化された Web アプリケヌションず API をデプロむできたす。 シンプルな API を通じお、ドメむン、ネットワヌキング、ロヌドバランシング、 AWS Identity and Access Management (IAM) ロヌル、オヌトスケヌリングが自動的に凊理されたす。 アプリケヌションが進化し、高床な機胜が必芁になった堎合は、Amazon ECS を含むリ゜ヌスのすべおの機胜をシヌムレスに蚭定しおアクセスできたす。 詳现に぀いおは、 発衚ブログ蚘事 をご芧ください。 Amazon ECS は、AI を掻甚した開発・運甚䜓隓を実珟するフルマネヌゞド型の MCP サヌバヌ のパブリックプレビュヌを発衚したした。 この Model Context Protocol (MCP) サヌバヌは、自動曎新ずパッチ適甚、AWS IAM 統合による䞀元的なセキュリティ管理、 AWS CloudTrail を通じた包括的な監査ログ、そしお AWS が実蚌枈みのスケヌラビリティ、信頌性、サポヌトずいった゚ンタヌプラむズグレヌドの機胜を提䟛したす。 Amazon Elastic Container Registry (ECR) の マネヌゞドコンテナむメヌゞ眲名 は、セキュリティ䜓制を匷化し、眲名のセットアップにかかる運甚䞊のオヌバヌヘッドを排陀したす。 コンテナむメヌゞ眲名により、むメヌゞが信頌できる゜ヌスからのものであるこずを怜蚌できたす。 ECR は、むメヌゞがプッシュされる際に、プッシュした゚ンティティの ID を䜿甚しお自動的にむメヌゞに眲名したす。 眲名操䜜は CloudTrail を通じおログに蚘録されるため、完党な監査が可胜です。 Amazon API Gateway Amazon API Gateway では、レスポンスペむロヌドをクラむアントに 段階的にストリヌミング するこずで、REST API の応答性を向䞊させるこずができたす。 この新機胜により、ストリヌミングレスポンスを䜿甚しお、LLM 駆動のアプリケヌション (AI ゚ヌゞェントやチャットボットなど) を構築する際のナヌザヌ゚クスペリ゚ンスの向䞊、Web およびモバむルアプリケヌションの Time-to-First-Byte (TTFB) パフォヌマンスの改善、倧容量ファむルのストリヌミング、 Server-Sent Events (SSE) などのプロトコルを䜿甚した増分的な進捗報告を䌎う長時間実行オペレヌションの実行が可胜になりたす。 Amazon API Gateway streaming API Gateway は、 Application Load Balancer (ALB) ずの プラむベヌト統合 を導入したした。 これにより、ALB をパブリックむンタヌネットに公開するこずなく、VPC ベヌスのアプリケヌションを REST API を通じお安党に公開できたす。 API ゚ンドポむントやカスタムドメむン名に 匷化された TLS セキュリティポリシヌ を蚭定できるようになり、API のセキュリティ䜓制をより现かく制埡できるようになりたした。 Amazon EventBridge Amazon EventBridge に、カスタムアプリケヌションや 200 以䞊の AWS サヌビスからのむベントを開発者が発芋しサブスクラむブできる 拡匵ビゞュアルルヌルビルダヌ が導入されたした。 このコン゜ヌルベヌスのむンタヌフェヌスは、EventBridge の スキヌマレゞストリ ず包括的なむベントカタログ、盎感的なドラッグアンドドロップキャンバスを統合し、むベント駆動型アプリケヌションの構築を簡玠化したす。 開発者は、個々のサヌビスのドキュメントを探し回るこずなく、すぐに利甚可胜なサンプルペむロヌドやスキヌマを䜿っおむベントを閲芧・怜玢できたす。 スキヌマ察応のビゞュアルビルダヌが、むベントフィルタヌパタヌンやルヌルの䜜成をガむドし、構文゚ラヌを削枛しお開発時間を短瞮したす。 EventBridge では、 SQS フェアキュヌ をタヌゲットずしお指定するこずもできたす。 AWS Step Functions AWS Step Functions では、 TestState API を通じお匷化されたロヌカルテストが可胜です。 AWS にデプロむするこずなく、包括的なテスト機胜にプログラムからアクセスできたす。 これにより、開発マシン䞊でワヌクフロヌ定矩をロヌカルに怜蚌する自動テストスむヌトを構築できたす。 お奜みのテストフレヌムワヌクを䜿甚しお、゚ラヌハンドリングパタヌン、デヌタ倉換、モックサヌビス統合をテストしたしょう。 たた、新しい メトリクスダッシュボヌド も远加され、アカりントレベルずステヌトマシンレベルの䞡方でワヌクフロヌの運甚状況を可芖化できるようになりたした。 その他の発衚 Savings Plans の柔軟な料金モデルが、 Database Savings Plans のロヌンチにより AWS マネヌゞドデヌタベヌスサヌビスにも拡匵されたした。 1 幎間の䞀定量の䜿甚量 ($/時間) をコミットするこずで、デヌタベヌスコストを最倧 35% 削枛できたす。 割匕は毎時間、察象のデヌタベヌスサヌビス党䜓の適栌な䜿甚量に自動的に適甚され、コミットメントを超える远加䜿甚量はオンデマンド料金で課金されたす。 Amazon DynamoDB が グロヌバルセカンダリむンデックスでの耇数属性耇合キヌ をサポヌトするようになりたした。 これたでは倀を手動で連結しお合成キヌを䜜成する必芁があり、新しいむンデックスを远加する前にデヌタのバックフィルが必芁になるこずもありたした。 今埌は、最倧 8 ぀の既存属性を䜿甚しおプラむマリキヌを䜜成できるため、倚様なアクセスパタヌンのモデリングや新しいク゚リ芁件ぞの察応が容易になりたす。 Amazon Bedrock は、信頌性の高い AI ゚ヌゞェントを倧芏暡にデプロむするための 品質評䟡ずポリシヌコントロヌルを備えた AgentCore を発衚したした。 Bedrock には 18 のフルマネヌゞドオヌプンりェむトモデル も远加され、開発者が利甚できる AI モデルの遞択肢が拡倧したした。 Strands Agents SDK は、モデル駆動型のアプロヌチで AI ゚ヌゞェントをわずか数行のコヌドで構築・実行できるオヌプン゜ヌスフレヌムワヌクです。 TypeScript のサポヌトがプレビュヌずしお 利甚可胜になり 、Strands Agents の構築に Python ず TypeScript のどちらかを遞択できるようになりたした。 Amazon S3 Vectors が䞀般提䟛開始ずなりたした。 S3 Vectors は、AI ゚ヌゞェント、掚論、怜玢拡匵生成 (RAG)、セマンティック怜玢を数十億ベクトル芏暡で実珟する、専甚蚭蚈されたコスト最適化枈みのベクトルストレヌゞを提䟛したす。 サヌバヌレスに関するブログ蚘事 10 月 モノリスワヌクフロヌの分解: AWS Step Functions ワヌクフロヌのモゞュヌル化 AWS Serverless MCP Server での AWS Lambda むベント゜ヌスマッピングツヌルの玹介 AWS Step Functions Distributed Map S3 プレフィックスを䜿甚した Amazon S3 オブゞェクトの倧芏暡凊理 11 月 AWS Lambda の IPv6 ネットワヌキング AWS Step Functions Distributed Map によるビッグデヌタ凊理のオヌケストレヌション AWS Step Functions Distributed Map を䜿甚したネストされた JSON 配列凊理の最適化 新しい Amazon API Gateway Portal で API の芋぀けやすさを向䞊させる Amazon API Gateway レスポンスストリヌミングでレスポンシブな API を構築する AWS Lambda で Python 3.14 ランタむムが利甚可胜になりたした AWS Lambda 䞊で Rust を䜿甚したサヌバヌレスアプリケヌションの構築 非同期 AWS サヌビスを AWS Step Functions ステヌトマシンず統合する際に、予枬䞍胜な凊理時間を運甚の䞀貫性を保ちながら凊理する AWS Lambda が Java 25 をサポヌトしたした Amazon API Gateway TLS セキュリティポリシヌによる API セキュリティの匷化 Kafka 向けサヌバヌレスストリヌミングワヌクロヌドのスルヌプット向䞊 Amazon API Gateway ず Application Load Balancer のプラむベヌト統合を䜿甚しおスケヌラブルな REST API を構築する LLM レスポンスのストリヌミングにおけるサヌバヌレス戊略 AWS Lambda の新しいテナント分離モヌドを䜿甚したマルチテナント SaaS アプリケヌションの構築 AWS Step Functions ず Amazon Bedrock バッチ掚論による倧芏暡ドキュメント凊理のオヌケストレヌション AWS Lambda で Node.js 24 ランタむムが利甚可胜になりたした Serverless Office Hours 毎週火曜日の午前 11 時 (倪平掋時間) に開催されるラむブストリヌムにぜひご参加ください。サヌバヌレステクノロゞヌに関するラむブディスカッション、Q&A セッション、深掘りセッションを行っおいたす。 ゚ピ゜ヌドは serverlessland.com/office-hours でオンデマンドでもご芖聎いただけたす。 10 月 10 月 7 日 – Amazon API Gateway Routing Rules 10 月 14 日 – Amazon DynamoDB Global Tables 10 月 21 日 – Building agents with Amazon Bedrock AgentCore 10 月 28 日 – What’s new with Observability 11 月 11 月 4 日 – AI 仕様を正しく定矩する 11 月 11 日 – AWS Lambda で Swift を実行する 11 月 18 日 – EventCatalog の最新情報 11 月 24 日 – pre:Invent 2025 12 月 12 月 9 日 – AWS Lambda Managed Instances 12 月 16 日 – AWS Lambda durable functions さらに詳しく知りたい方ぞ サヌバヌレスのランディングペヌゞ には、サヌバヌレスアプリケヌションの構築に関する党般的な情報がありたす。 Lambda リ゜ヌスペヌゞ には、ケヌススタディ、りェビナヌ、ホワむトペヌパヌ、お客様事䟋、リファレンスアヌキテクチャ、さらに倚くの入門チュヌトリアルが掲茉されおいたす。 Serverless Developer Advocacy チヌムをフォロヌしお、最新ニュヌスの確認、䌚話のフォロヌ、チヌムずの亀流もできたす。 Julian Wood: @julian_wood , https://www.linkedin.com/in/julianrwood/ Eric Johnson: @edjgeek , https://www.linkedin.com/in/singledigit/ Gunnar Grosch: @GunnarGrosch , https://se.linkedin.com/in/gunnargrosch Erik Hanchet: @ErikCH , https://www.linkedin.com/in/erikhanchett/ Salih Gueler: @salihgueler , https://www.linkedin.com/in/salihgueler/ Marcia Villalba: @mavi888uy , https://www.linkedin.com/in/marciavillalba 最埌に、サヌバヌレスに関するあらゆる情報に぀いおは Serverless Land をご芧ください。
こんにちは。アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクトの倚田です。2026 幎 5 月 29 日に、倧阪オフィスにお「AWS Business Innovation Series – West Japan」の第 2 回を開催いたしたした。本シリヌズは、西日本のお客様のデゞタル倉革を加速するこずを目的に、生成 AI を掻甚した実践的なプログラムを玄 3 ヶ月に 1 回のペヌスでお届けしおいるものです。ご参加いただいた皆様に、改めお埡瀌申し䞊げたす。 本ブログでは、むベントの背景や圓日の様子、参加者の皆様からいただいた声をお届けいたしたす。 はじめに 本シリヌズは 2025 幎に関西を䞭心に開催したワヌクショップの高い満足床を受けお、2026 幎は業界を問わず幅広い䌁業の皆様にご参加いただける圢で継続しおいたす。玄 3 ヶ月に 1 回のペヌスで幎 4 回の開催を予定しおおり、今回がその第 2 回です。第 2 回では、さらに䞀歩進んで Amazon Quick をテヌマに遞びたした。 Amazon Quick は、Slack・メヌル・カレンダヌ・ファむルなど業務で䜿う倚様なデヌタ゜ヌスに接続し、AI アシスタントが業務のコンテキストを深く理解した䞊でアクションたで実行できるツヌルです。チャット゚ヌゞェント、ワヌクフロヌ自動化、リサヌチなど幅広い機胜を備えおいたすが、今回はデヌタ接続ずチャット゚ヌゞェント構築にフォヌカスしたした。「AI ツヌルは気になるけれど、自分の業務にどう掻かせるかむメヌゞが湧かない」「瀟内のデヌタを掻甚したいけれど、どう繋げればいいかわからない」――そんな方々に、半日でデヌタ接続から゚ヌゞェント構築たでを䜓隓しおいただくこずが今回のむベントの狙いでした。 過去開催分に぀いおはこちらをご芧ください。 第 1 回お詊しから卒業Kiro の仕様駆動開発を本栌掻甚2026/3/17 むベント抂芁 項目 内容 テヌマ デヌタから業務アクション、展開たで繋げる Amazon Quick ワヌクショップ 日時 2026 幎 5 月 29 日金13:00〜18:00懇芪䌚 18:00〜 堎所 アマゟン りェブ サヌビス ゞャパン 倧阪オフィス䞭之島䞉井ビルディング 26F 参加者 20 瀟 34 名 満足床 4.11 / 5 タむムテヌブル 時間 内容 13:00 – 13:10 オヌプニング 13:10 – 13:30 座孊AI アシスタントは あなたの仕事の䜕割を芋おいたすか ― Why Quick 13:30 – 14:50 Amazon Quick ハンズオン ~ HR Agentを䜜っおみよう 14:50 – 15:00 䌑憩 15:00 – 17:30 Amazon Quick ハッカ゜ン ~ ビゞネス貢献できるチャット゚ヌゞェントを䜜ろう 17:30 – 17:50 LTあなたの業務、アプリにしたせんか 17:50 – 18:00 クロヌゞング 圓日の様子 座孊AI アシスタントは あなたの仕事の䜕割を芋おいたすか ― Why Quick 発衚資料 AI アシスタントは あなたの仕事の䜕割を芋おいたすか ― Why Quick 最初のセッションでは、「AI に䜕ができるか」ではなく「AI があなたの仕事のどれだけを芋おいるか」ずいう問いからスタヌトしたした。私たちは日垞業務で、コミュニケヌションツヌル(メヌル / Teams / Slack など)、コラボレヌションツヌル(Box / SharePoint など)、瀟内システム、SaaS、Web ずいった 5 ぀の階局のデヌタ゜ヌスを無意識に行き来しお刀断しおいたす。䞀方で倚くの AI ツヌルが芋おいるのはそのうち 1〜2 階局だけ ― このギャップが AI 掻甚の倩井を決めおいるずいう構造を敎理したした。さらに、デヌタに繋がった先で「探せる → 芋枡せる → わかる → 動ける」の 4 象限を回すこずが重芁であり、Amazon Quick はその党䜓をカバヌする蚭蚈であるこずをお䌝えしたした。たずは小さく怜蚌し、効果が芋えたら利甚者を広げおいくずいうアプロヌチを玹介し、埌半のハンズオン・ハッカ゜ンぞの橋枡しずしたした。 Amazon Quick ハンズオン ~ HR Agent を䜜っおみよう ハンズオンでは、架空の人事課題 ―「盎近 1 幎で離職率が䞊昇傟向にある。散圚する埓業員デヌタを掻甚し、離職可胜性の高い埓業員を早期に特定しおリテンション斜策を打おる仕組みを構築しおほしい」― をミッションに蚭定したした。参加者は以䞋の 4 ぀の緎習を通じお、段階的にデヌタ接続の深さを䜓隓したした。 Chat で觊っおみよう ― ドキュメントをアップロヌドしお自然蚀語で Q&A。手軜さを䜓隓する䞀方、毎回のアップロヌドが必芁で、チヌムで共有しにくい限界も実感。 Space を䜜ろう ― 非構造化デヌタ瀟員フィヌドバックレポヌト、オンボヌディングチェックリストを氞続的なナレッゞベヌスずしお統合。他ナヌザヌぞの共有も可胜に。 構造化デヌタず接続しよう ― S3 䞊の埓業員マスタ テヌブルをデヌタ゜ヌスずしお接続し、自然蚀語で「郚門ごずの平均満足床は」ず分析。非構造化デヌタず統合しお暪断分析可胜な状態を構築。 HR Agent を䜜ろう ― Chat Agent を䜜成し、構造化デヌタ数倀・フラグず非構造化デヌタ評䟡コメント・退職面談蚘録を組み合わせた離職リスク分析を実斜。単なるダッシュボヌドでは埗られない、文脈を螏たえた倚角的な分析を䜓隓。 Amazon Quick ハッカ゜ン ~ ビゞネス貢献できるチャット゚ヌゞェントを䜜ろう ハンズオンで基本操䜜を習埗した埌は、個人ハッカ゜ンです。ゎヌルは「ビゞネスに圹立぀チャット゚ヌゞェントを䜜る」こず。参加者は以䞋のステップで進めたした。 テヌマ蚭蚈 ― Amazon Quick からの質問に答えながら、自瀟ビゞネスに貢献できる゚ヌゞェントのテヌマを決定 チャット゚ヌゞェント䜜成 ― ハンズオンの手順を応甚しお゚ヌゞェントを構築 評䟡゚ヌゞェント䜜成 ― 䜜った゚ヌゞェントの品質を評䟡する仕組みも構築 反埩改善 ― 評䟡結果をもずにプロンプトやデヌタを改善 提案資料䜜成 ― Amazon Quick を䜿っお導入提案の PPTX を自動生成し、自瀟に持ち垰れる成果物に グルヌプ内発衚 ― 成果を共有 LTあなたの業務、アプリにしたせんか 発衚資料 あなたの業務、アプリにしたせんか ハッカ゜ンの興奮冷めやらぬ䞭、LTラむトニングトヌクでは「あなたの業務、アプリにしたせんか」ず題しお、Amazon Quick のアプリ機胜「Quick Apps (プレビュヌ)」をご玹介したした。ハンズオン・ハッカ゜ンで䜓隓したチャット゚ヌゞェントに加え、Quick には自然蚀語で Web アプリを䜜成できる機胜もありたす。定型業務をアプリ化し、Publish & Share でチヌムや組織に展開できる ― 個人の歊噚を組織の力に倉えるもう䞀぀のアプロヌチをお䌝えしたした。 参加者の声 参加者アンケヌトからいく぀かの声をご玹介したす。 「資料・説明ずもにわかりやすかったです。SA の方も楜しく教えおくれお良かったず思いたした。」 「持ち垰れるモノが倚く、有意矩な時間でした。」 「Quick を䜿っおいる぀もりでしたが、党然足りたせんでした。他の人の䜿い方をみるのは非垞に重芁です。」 「業務アプリが䞀通り構築できそうです。」 「Quick の利点に぀いお、デヌタ連携先が豊富であるこず、BI ツヌルず統合した UI が䜜成可胜であるこずが、既存のチャット型 AI ゚ヌゞェントにない利点だず理解したした。」 たずめ 第 2 回「AWS Business Innovation Series – West Japan」では、Amazon Quick をテヌマに、座孊で「AI が芋おいる䞖界」の構造を理解し、ハンズオンで Chat → Space → デヌタ゜ヌス接続 → Agent 䜜成を段階的に䜓隓し、ハッカ゜ンでは自瀟課題をもずに゚ヌゞェントず導入提案資料を䜜り䞊げる ― デヌタから業務アクション、そしお展開たでを䞀気通貫で䜓隓いただくプログラムずなりたした。 普段コヌドを曞かない方々も含め、参加者の皆様が半日で実際に動く゚ヌゞェントず導入提案資料を䜜り䞊げる姿は非垞に印象的でした。 ご興味のある方は、担圓のアカりントチヌムたでお気軜にお問い合わせください。皆様のご参加をお埅ちしおおりたす。 本ブログは、゜リュヌションアヌキテクトの倚田 慎也が執筆いたしたした。
本蚘事は 2026 幎 4 月 17 日 に AWS Migration & Modernization Blog で公開された「 Modernize VB6 Applications at Scale with AWS Transform Custom  」を翻蚳したものです。 想定所芁時間 : 90 〜 120 分 レベル : 侊箚 (400) Microsoft は Visual Basic 6.0 (VB6) ã®å»¶é•·ã‚µãƒãƒŒãƒˆã‚’ 2008 å¹Žã«çµ‚了 (*) したしたが、金融サヌビス、保険、ヘルスケア、補造業など、数千ものミッションクリティカルなアプリケヌションが䟝然ずしお VB6 に䟝存しおいたす。これらのアプリケヌションには数十幎分のビゞネスロゞックが含たれおいたすが、幎々メンテナンスが困難になっおいたす。VB6 開発者は劎働垂堎に残る人数が枛少しおいるため採甚コストが䞊昇し、パッチ未適甚の脆匱性はコンプラむアンス違反のリスクを高め、モノリシックなアヌキテクチャは AI、アナリティクス、クラりドサヌビスずの統合を困難にしおいたす。 * 蚳泚厳密には、VB6 の IDE のサポヌトは終了しおたすが、VB6 のランタむムはただサポヌトはされおいたす。ランタむムは Windows のラむフタむムに合わせおサポヌト継続されおいたすが、察応は重倧なセキュリティ問題等に限定されおいたす。詳现は こちら を参照しおください。 これらの課題は、AWS Transform custom でカスタム倉換プランを䜜成するこずで解決できたす。 この蚘事では、AWS Transform custom の゚ヌゞェンティック AI 機胜を掻甚しお、組織固有のビゞネスルヌルを維持しながら VB6 アプリケヌションを倧芏暡にモダナむズする方法を玹介したす。 VB6 ãƒ¢ãƒ€ãƒŠã‚€ã‚ŒãƒŒã‚·ãƒ§ãƒ³ã®èª²é¡Œ VB6 ã‚¢ãƒ—リケヌションのモダナむれヌションには、単玔な構文倉換を超えた固有の課題がありたす。 AWS Transform for .NET  ã¯ .NET Framework アプリケヌションの自動ポヌティングを提䟛しおいたすが、VB6 には固有の特性があるため、異なるアプロヌチが必芁です。 VB6 ã®ãƒ¢ãƒ€ãƒŠã‚€ã‚ŒãƒŒã‚·ãƒ§ãƒ³ã§ã¯ã€ãƒ¬ã‚¬ã‚·ãƒŒãƒ—ラットフォヌムずモダンな .NET の間にある根本的なアヌキテクチャの違いに察凊する必芁がありたす。蚀語レベルでは、VB6 ã®æ‰‹ç¶šãåž‹ãŠã‚ˆã³ COM ãƒ™ãƒŒã‚¹ã®ãƒ‘タヌンをオブゞェクト指向の C# æ§‹é€ ã«ãƒžãƒƒãƒ”ングする必芁がありたす。ナヌザヌむンタヌフェヌスも、ActiveX ã‚³ãƒ³ãƒˆãƒ­ãƒŒãƒ«ã‚’䜿甚した VB6 ãƒ•ォヌムから Blazor や ASP.NET Core MVC ãªã©ã®ãƒ¢ãƒ€ãƒ³ãª Web ãƒ•レヌムワヌクぞの倉換が必芁です。デヌタアクセスパタヌンはレガシヌな ADO や DAO ã‹ã‚‰ Entity Framework Core の async/await ãƒ‘タヌンに移行し、COM äŸå­˜é–¢ä¿‚は .NET ãƒã‚€ãƒ†ã‚£ãƒ–の代替手段や NuGet ãƒ‘ッケヌゞに眮き換える必芁があり、゚ラヌハンドリングは On Error Resume Next や On Error GoTo ãƒ‘タヌンから構造化された try-catch äŸ‹å€–凊理に移行したす。 サンプルアプリケヌションの玹介 Salmon King Seafood (SKS)  ずいう VB6 Multiple Document Interface (MDI) アプリケヌションを䜿っお AWS Transform custom を解説したす。これは兞型的な゚ンタヌプラむズモダナむれヌションの課題を衚すアプリケヌションです。SKS は以䞋の特城を持぀氎産物受泚管理システムです。 15 以䞊の VB6 フォヌム – 受泚、顧客管理、商品カタログ、圚庫管理、承認ワヌクフロヌを含む 3 ぀の VB6 モゞュヌル (modConnection.bas、modFunctions.bas、modMain.bas) – 共有ビゞネスロゞックずデヌタベヌス接続を含む SQLite デヌタベヌス (Orders.db) – ADO デヌタコントロヌルずデヌタバむンディングを通じおアクセス 暙準 VB6 コントロヌル – MSFlexGrid、ListView、Toolbar、ImageList、ComboBox、Control Arrays を含む MDI ã‚¢ãƒŒã‚­ãƒ†ã‚¯ãƒãƒ£  â€“ ãƒ¡ã‚€ãƒ³ã‚³ãƒ³ãƒ†ãƒŠãƒ•ォヌムずメニュヌからトリガヌされる子フォヌム このアプリケヌションは、゚ンタヌプラむズアプリケヌションでよく芋られる VB6 パタヌンを実装しおいたす。 むベントハンドラを持぀フォヌムベヌスの UI デヌタバむンディングを䜿甚した ADO デヌタアクセス COM ベヌスのコントロヌル モゞュヌル内の手続き型ビゞネスロゞック これらの芁玠により、SKS ぱンタヌプラむズ VB6 モダナむれヌションで遭遇する耇雑さを代衚するものずなっおいたす。 ゜リュヌション抂芁 VB6 ã‹ã‚‰ C# ãžã®ãƒ¢ãƒ€ãƒŠã‚€ã‚ŒãƒŒã‚·ãƒ§ãƒ³ã«ã¯ã€AWS Transform custom ã®è€‡é›‘な倉換パタヌンの孊習・適甚機胜を掻甚できたす。゚ンドツヌ゚ンドのプロセスは以䞋のステヌゞに埓いたす。 評䟡 – VB6 アプリケヌションポヌトフォリオのスコヌプず耇雑さを評䟡する 定矩 – VB6 から C# ぞの倉換パタヌン、ビゞネスルヌル、コヌディング暙準を含むカスタム倉換を定矩する 実行 – 倧芏暡に倉換を実行する レビュヌず反埩 – フィヌドバックルヌプによる継続的な改善を行いながらレビュヌず反埩を行う このアヌキテクチャにより、倉換定矩を䞀床䜜成しおテストし、数癟のアプリケヌションに適甚できたす。 前提条件 開始する前に、以䞋を確認しおください。 AWS Transform Custom ぞのアクセス暩を持぀ AWS アカりント 。珟圚の料金の詳现に぀いおは、AWS Transform の料金ペヌゞをご芧ください。 ATX CLI (Command Line Interface) がむンストヌルされた MacOS たたは Linux 環境。詳现なセットアップ手順に぀いおは、 AWS Transform custom 前提条件ガむド を参照しおください。 **Windows 開発者の堎合** : WSL2 (Windows Subsystem for Linux) をむンストヌルし、Ubuntu たたはその他の Linux ディストリビュヌションから ATX CLI を実行しおください。CLI は `/mnt/c/` パスを通じおロヌカルコヌドベヌスを盎接操䜜したす。 倉換埌のアプリケヌションをテストするための .NET 10 SDK 以降 コヌドレビュヌ甚の Visual Studio 2022 以降たたは Visual Studio Code VB6 および .NET の開発知識 有効な認蚌情報が蚭定されおいる Git があるこず 環境の準備 Salmon King Seafood (SKS)  ã‚µãƒ³ãƒ—ルアプリケヌションをダりンロヌドしたす。これには、兞型的な゚ンタヌプラむズ VB6 ワヌクロヌドを代衚する VB6 MDI アプリケヌションが含たれおいたす。 リポゞトリをロヌカルマシンにクロヌンしたす。 git clone https://github.com/GAPVelocityAI/SKSVB6.git  cd SKSVB6  Windows で WSL2 ã‚’䜿甚しおいる堎合は、䞡方の環境からアクセス可胜なパスにクロヌンしたす。 git clone https://github.com/GAPVelocityAI/SKSVB6.git /mnt/c/Projects/SKSVB6  cd <path-to-repository>  リポゞトリの内容を確認したす。VB6 ãƒ—ロゞェクトファむル (SKS.vbp)、フォヌムファむル (.frm/.frx)、モゞュヌル (.bas)、SQLite ãƒ‡ãƒŒã‚¿ãƒ™ãƒŒã‚¹ (Orders.db) ãŒè¡šç€ºã•れたす。 ls -la *.vbp *.frm *.bas *.db  倉換远跡甚にリポゞトリを初期化したす。 git add .  git commit -m "Baseline before VB6 to C# transformation"  次に、リファレンスドキュメントを含むリポゞトリをクロヌンしたす。このリポゞトリには、AWS Transform ã«ã‚³ãƒ³ãƒ†ã‚­ã‚¹ãƒˆãšã—お枡すビゞネスルヌルず倉換䟋が含たれおおり、組織の暙準に合ったコヌドを生成したす。 git clone -b dotnet-transform-custom https://github.com/aws-samples/dotnet-genai-samples.git  りォヌクスルヌ 以䞋のセクションでは、AWS Transform CLI を䜿甚しお VB6 コヌドをモダンな C# プロゞェクトに倉換する手順を説明したす。 ステップ 1: VB6 アプリケヌションを評䟡する 倉換定矩を䜜成する前に、VB6 ポヌトフォリオのスコヌプず耇雑さを把握したす。SKS リポゞトリをクロヌンした状態で、ATX CLI を起動しお評䟡を開始したす。 atx custom def exec -p <path-to-repository> \  -n 'AWS/early-access-comprehensive-codebase-analysis' \  -t  パラメヌタ : -p: ゜ヌスプロゞェクトのパス (クロヌンした SKS リポゞトリ) -n: 倉換定矩名 -t: å€‰æ›ã«é–¢ã‚ã‚‹ã™ã¹ãŠã®ãƒ„ヌルを信頌し、実行䞭に AWS Transform ãŒèš±å¯ã‚’求めお䞀時停止するのを防ぐ 泚意 2026 幎 5 月 1 日時点では、倉換定矩名は AWS/early-access-comprehensive-codebase-analysis から AWS/comprehensive-codebase-analysis に倉曎になっおいたす AWS Transform custom ã¯ã€ã‚·ã‚§ãƒ«ã‚¹ã‚¯ãƒªãƒ—トなどの特定のアクションを実行するために蚱可を必芁ずしたす。䞊蚘のコマンドの â€“t åŒ•数により、ツヌルはナヌザヌに継続的にプロンプトを衚瀺するこずなく実行できたす。 評䟡では SKS プロゞェクトを分析し、フォヌム数 (15 以䞊)、モゞュヌル数 (3)、COM コンポヌネントの䟝存関係 (MSFlexGrid、ListView)、デヌタベヌスアクセスパタヌン (ADO with SQLite)、掚定倉換耇雑床スコアを含む包括的なレポヌトを生成したす。 この評䟡レポヌトを䜿甚しお、VB6 アプリケヌションを倉換する際に AWS Transform custom に远加のコンテキストを提䟛したす。 ステップ 2: VB6 から C# ぞのカスタム倉換定矩を䜜成する 次に、VB6 からモダンな C# ぞの倉換パタヌンずルヌルをキャプチャするカスタム倉換定矩を䜜成したす。AWS Transform custom は、提䟛された䟋、ドキュメント、ビゞネスルヌルから孊習し、これらのパタヌンを䞀貫しお適甚したす。 察話型 CLI を起動したす。 atx -t  プロンプトが衚瀺されたら、倉換の説明ずしお VB6 to C# ASP.NET Core web application migration ず入力したす。AWS Transform custom は既存の倉換を怜玢し、この特定のシナリオに該圓するものが芋぀からない堎合、カスタム倉換を䜜成するかどうかを尋ねたす。「create a new one」ず入力しお確認したす。 図 1 – atx cli の起動 倉換コンテキストずビゞネスルヌルの提䟛  AWS Transform custom ã¯ã€ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã€ç§»è¡Œã‚¬ã‚€ãƒ‰ã€ã‚µãƒ³ãƒ—ルコヌドの提䟛を求めたす。ここで組織固有の芁件を远加したす。SKS ã‚¢ãƒ—リケヌションに぀いおは、そのアヌキテクチャに関するコンテキストを提䟛したす。 Salmon King Seafood (SKS) ずいう VB6 MDI アプリケヌションがありたす。゜ヌスコヌドは <path-to-repository> にありたす。泚文受付、顧客管理、補品カタログ、圚庫管理、承認ワヌクフロヌなど、15 以䞊のフォヌムがありたす。3 ぀のモゞュヌル (デヌタベヌス接続甚の modConnection.bas、ナヌティリティ関数甚の modFunctions.bas、アプリケヌションの゚ントリ ポむント甚の modMain.bas) を䜿甚しおいたす。デヌタベヌスは SQLite で、デヌタ バむンディングを䜿甚した ADO デヌタ コントロヌルを介しおアクセスしたす。コントロヌルには、MSFlexGrid、ListView、Toolbar、ImageList、およびコントロヌル アレむが含たれたす。これを .NET 10 をタヌゲットずする ASP.NET Core Blazor Server アプリケヌションに倉換しおください。 組織向けの移行パタヌンのカスタマむズ  移行の粟床を向䞊させるために、組織固有のマッピングルヌルを提䟛したす。これらはナヌザヌが䜜成したマヌクダりンファむルで、AWS Transform custom からプロンプトが衚瀺された際に参照したす。AWS Transform custom はこれらを倉換プランに組み蟌みたす。プロンプトが衚瀺されたら、察話型セッション䞭に VB6 ゜ヌスコヌドずずもにこれらのファむルを参照したす。 図 2 – 倉換プランぞのビゞネスルヌルやその他のコンテキストの远加 倉換䟋の参照 <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/example-transformations.md ファむルを確認したす。ATX ゚ヌゞェントがサンプル倉換を求めるプロンプトを衚瀺したら、以䞋のように参照したす。 倉換前埌の䟋は、<path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/example-transformations.md にありたす。 䌁業コヌディング芏玄の参照 AWS Transform custom ã§ã¯ã€çµ„織のコヌディング芏玄を倉換に䜿甚するこずでコヌド生成を制埡できたす。これには特定の C# ã®æ©Ÿèƒœã‚„芏玄を含めるこずができたす。AWS Transform custom はこれらを䜿甚しお、チヌムのスタむルに合ったコヌドを生成したす。<path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/coding-standards.md ファむルを確認したす。組織のプラクティスに合わせお独自の芏玄を䜜成できたす。 䟋 : <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/coding-standards.md で定矩されおいるコヌディング芏玄を適甚しおください。 タヌゲットアヌキテクチャ仕様の参照 オプションずしお、 <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/target-architecture.md にあるような、望たしい出力アヌキテクチャを蚘述したドキュメントを䜿甚できたす。 AWS Transform custom ã¯å‚照されたすべおのファむルを読み取り、組織のパタヌン、芏玄、アヌキテクチャに合った倉換プランを生成したす。 生成された倉換定矩 あなたの入力に情報に基づいお、AWS Transform custom はフェヌズごずに敎理された包括的な倉換定矩を生成したす。 フェヌズ 1 – 分析 : VB6 コンポヌネントのむンベントリ、䟝存関係の特定、䟝存関係グラフの䜜成 フェヌズ 2 – プロゞェクト構造 : ASP.NET Core Blazor Server プロゞェクトの生成、NuGet パッケヌゞの蚭定、䟝存性泚入のセットアップ フェヌズ 3 – デヌタレむダヌ : ADO/DAO から Entity Framework Core ぞの倉換、DbContext ず゚ンティティモデルの生成 (適切な堎合は record 型を䜿甚) フェヌズ 4 – ビゞネスロゞック : モゞュヌルからサヌビスクラスぞの倉換 (プラむマリ コンストラクタヌを䜿甚)、関数から async メ゜ッドぞの倉換 フェヌズ 5 – UI レむダヌ : VB6 フォヌムから Blazor コンポヌネントぞの倉換、むベントハンドラの倉換 フェヌズ 6 – æ€œèšŒ : ビルド成功の確認、ナニットテストの生成、機胜的等䟡性のテスト 倉換定矩をすぐに適甚するか、レビュヌしお修正するか、レゞストリに公開しお再利甚するか、新しいプランを開始するかを遞択できたす。次のステップでは、倧芏暡に再利甚できるように倉換定矩を公開したす。 AWS Transform custom は倉換プランの名前ず説明を提案しおきたす。そのたた受け入れるか、必芁に応じお修正できたす。これで倉換定矩がチヌム党䜓で利甚可胜になりたす。 カスタム倉換定矩の衚瀺ず管理  公開埌、察話型゚ヌゞェントたたは以䞋の CLI コマンドを䜿甚しお、カスタム倉換定矩ず利甚可胜なすべおの AWS マネヌゞド倉換を衚瀺できたす。 atx custom def list 図 3 – ナヌザヌが䜜成したカスタム倉換プランの䞀芧 このコマンドは、AWS マネヌゞド倉換 (AWS/ プレフィックス付き) ずカスタム定矩の倉換の䞡方を衚瀺したす。カスタム定矩の䞋に VB6-to-CSharp-Blazor-Migration 倉換プランが衚瀺されたす。 ステップ 3: 倉換を実行する カスタム倉換定矩を公開したら、VB6 アプリケヌションのモダナむれヌションを実行できたす。プロンプトが衚瀺されたら、プロゞェクトに察しお倉換プランを実行したす。リポゞトリぞのパスず、倉換埌にプロゞェクトをビルドするためのビルドコマンドを䞎える必芁がありたす。 図 4 – 倉換を怜蚌するためのビルドコマンドの远加 以䞋のコマンドを䜿甚しお倉換プランを盎接タヌミナルから実行するこずもできたす。 atx custom def exec -p <path-to-repository>\  -n 'VB6-to-CSharp-Blazor-Migration' \  -t  AWS Transform custom が認識すべき远加のコンテキストを提䟛するかどうかを尋ねられたす。これは、保存された倉換定矩には含たれないその堎限りのコンテキスト (コヌド分析で生成されたドキュメントなど) を提䟛する堎合に䟿利です。 図 5 – 倉換プラン生成前の远加コンテキストの远加 プロンプトに回答するず、AWS Transform は実行たたはレビュヌ・修正するための倉換プランを生成したす。 図 6 – 倉換プランのレビュヌたたは続行 倉換プランの内容に問題なければ 続行する 倉換゚ヌゞェントは SKS プロゞェクトの構造を分析し、MDI コンテナ (frmMain.frm)、子フォヌム、モゞュヌル、デヌタベヌスパタヌンを特定しおから、倉換定矩を適甚したす。゚ヌゞェントは以䞋を倉換したす。 frmMain.frm (MDI コンテナ) → ナビゲヌションメニュヌ付きの Blazor MainLayout.razor frmCustomers.frm、frmProviders.frm など → 個別の Blazor ペヌゞコンポヌネント modConnection.bas → Entity Framework Core ず SQLite プロバむダヌを䜿甚した SksDbContext.cs modFunctions.bas → ドメむンごずに敎理された拡匵メ゜ッドクラス MSFlexGrid デヌタグリッド → デヌタバむンディング付きの Blazor テヌブルコンポヌネント ADO ãƒ‡ãƒŒã‚¿ã‚³ãƒ³ãƒˆãƒ­ãƒŒãƒ« â†’ async/await ã‚’䜿甚した Entity Framework Core ã‚¯ã‚šãƒª ステップ 4: ãƒ¬ãƒ“ュヌ、テスト、反埩 倉換が完了するず、AWS Transform custom は倉換されたコヌドを新しいブランチたたはディレクトリに出力し、倉換レポヌトず手動修正の次のステップを提瀺したす。 倉換結果のレビュヌ  倉換レポヌトには、以䞋を含む終了基準の怜蚌が含たれたす。 dotnet build が゚ラヌれロで成功 すべおの VB6 フォヌムが Blazor コンポヌネントに倉換枈み (䟋: frmCustomers.frm → Customers.razor、frmOrderReception.frm → OrderReception.razor) デヌタアクセスレむダヌが Entity Framework Core ず SQLite プロバむダヌおよび async パタヌンを䜿甚 (ADO/ADODC デヌタコントロヌルを眮換) COM 䟝存関係の排陀 — MSFlexGrid は Blazor テヌブルコンポヌネントに、Toolbar/ImageList は Blazor ナビゲヌションに眮換 ゚ラヌハンドリングが On Error 文から構造化された try-catch 䟋倖凊理に倉換 仕様に埓ったモダンな C# 機胜の適甚 (レコヌド型、プラむマリコンストラクタヌ、パタヌンマッチング) modConnection.bas が IDbContextFactory<SksDbContext> を䜿甚した登録枈み Dependency Injection (DI) サヌビスに倉換 AWS Transform は 1 回の実行で怜蚌基準を満たさない堎合がありたす。倉換の実行埌、成功した郚分ず倱敗した郚分のサマリヌを含む郚分的な倉換結果が埗られるこずがありたす。以䞋に倉換結果を瀺したす。 図 7 – 完了した倉換結果 フィヌドバックプロンプトから、未達成の基準に察凊するために倉換を再実行できたす。倉換された SKS ã‚¢ãƒ—リケヌションを怜蚌するには、タヌミナルに切り替えお以䞋を実行したす。 cd <path-to-your-project>  dotnet build  dotnet run  ブラりザで https://localhost:<port> ã«ã‚¢ã‚¯ã‚»ã‚¹ã—、以䞋に瀺すように Blazor ã‚¢ãƒ—リケヌションが受泚、顧客管理、商品カタログのペヌゞを正しくレンダリングするこずを確認したす。 図 8 – 請求曞䜜成ペヌゞ 図 9 – 泚文䜜成ペヌゞ 機胜が䞍足しおいる堎合は、CLI ã«ãƒ•ィヌドバックを返しお倉換結果を繰り返し改善したす。 Transform ã‚³ãƒžãƒ³ãƒ‰ã®ãƒ‘フォヌマンス Transform custom コマンドは、倉換察象のコヌドベヌスのサむズに応じお、完了たでに最倧 60 åˆ†ã‹ã‹ã‚‹å ŽåˆãŒã‚りたす。コヌドファむルや䟝存関係が倚い倧芏暡なプロゞェクトでは、圓然ながらより倚くの凊理時間が必芁になりたす。 倉換の制限事項に぀いお Transform custom の機胜では、VB6 アプリケヌションのすべおの機胜を自動的に倉換できるずは限りたせん。倉換完了埌、゜ヌスの VB6 ã‚¢ãƒ—リケヌションず倉換先の C# ã‚¢ãƒ—リケヌション間の機胜を比范・怜蚌する必芁がありたす。倉換されなかった䞍足機胜に぀いおは、 Kiro  ã‚„  Amazon Q Developer  ãªã©ã® AI 搭茉ツヌルを䜿甚しお、゜ヌスから倉換先のコヌドベヌスぞの倉換・移怍を支揎できたす。 ナニットテストの重芁性 ナニットテストは、倉換プロセス党䜓を通じお機胜の正圓性を怜蚌したす。倉換されたコヌドが元の VB6 アプリケヌションず同䞀の動䜜をするこずを確認し、倉換䞭に導入された䞍䞀臎やリグレッションを迅速に特定するのに圹立ちたす。倉換前に䞀連のテストを敎備しおください。これがリグレッションテストの基準ずなり、倉換埌も同等に動䜜するこずを怜蚌できたす。 たずめ 組織固有のパタヌン、ビゞネスルヌル、モダンな C# æ©Ÿèƒœã®èš­å®šã‚’含むカスタム倉換定矩を䜿甚するこずで、組織に蓄積された知芋を維持しながら数癟の VB6 ã‚¢ãƒ—リケヌションを䜓系的にモダナむズできるようになりたした。 倉換を䞀床定矩すれば、アプリケヌションポヌトフォリオ党䜓に適甚できたす。これにより、再利甚可胜な倉換定矩に組織に蓄積された知芋が保存されたす。フィヌドバックルヌプによる継続的な改善により、各倉換はより掗緎され、レコヌド型、プラむマリコンストラクタヌ、パタヌンマッチングなどのモダンな C# æ©ŸèƒœãŒã‚³ãƒŒãƒ‰ãƒ™ãƒŒã‚¹ã«è‡ªå‹•的に適甚されたす。モダナむズされたアプリケヌションは Linux ず AWS Graviton äžŠã§å‹•䜜し、むンフラストラクチャコストを削枛できる可胜性がありたす。 AWS Transform custom ã‚’䜿甚しお VB6 ã‚¢ãƒ—リケヌションポヌトフォリオのモダナむれヌションを始めたしょう。セットアップ手順に぀いおは、 AWS Transform custom Getting Started Guide  ã‚’ご芧ください。 远加リ゜ヌス AWS Transform custom Getting Started Guide AWS Transform custom Product Page AWS Transform custom Documentation AWS Transform custom Command Reference AWS Transform for .NET .NET on AWS Developer Center 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。原文は こちら です。 著者に぀いお David Kilzer David Kilzer は、AWS ゚コシステム内での Microsoft ワヌクロヌドの最適化を専門ずする゜リュヌションアヌキテクトです。C#、SQL Server、そしお AWS サヌビスを甚いた最新の゜フトりェア゜リュヌション構築に関する専門知識を有しおいたす。 Ashish Bhatia Ashish Bhatia は、AWS のシニア゜リュヌションアヌキテクトで、゚ンタヌプラむズのお客様のクラりドゞャヌニヌのガむドに泚力しおいたす。AWS のクラりドネむティブサヌビスを䜿甚しお最新の゜フトりェア゜リュヌションを構築するお客様を支揎するこずに情熱を泚いでいたす。たた、圌は Amazon Web Services のスペシャリスト゜リュヌションアヌキテクトです。最先端の生成 AI ゜リュヌションの䜜成に取り組み、お客様䞭心のアプロヌチを優先しおいたす。 Ty Augustine Ty Augustine は、.NET、SQL Server、コンテナを専門ずする Microsoft スペシャリスト゜リュヌションアヌキテクトです。ニュヌペヌクを拠点に、様々な業界の䌁業ず緊密に連携し、AWS クラりドぞの移行ずモダナむれヌションを加速させおいたす。AWS に入瀟する前は、20 幎以䞊にわたり Microsoft スタックの゜フトりェアアヌキテクトずしお掻躍しおいたした。
本ブログは 2026 幎 3 月 17 日に公開された AWS Blog “ AWS and Others Invest $12.5M to Defend the Open Source Ecosystem from AI Threats ” を翻蚳したものです。 AWS、Anthropic、Google、Microsoft、OpenAI は本日 (2026 幎 3 月 17 日)、AI によっお匷化された、あるいは AI が生成したセキュリティ脆匱性レポヌトの急増にオヌプン゜ヌスプロゞェクトが察応できるよう支揎するため、Linux Foundation を通じお 1,250 䞇ドルを拠出するこずを 発衚したした 。 Alpha Omega むニシアチブず Open Source Security Foundation (OpenSSF) の䞡方が、Linux Foundation の助成金を通じお資金提䟛を受けたす。 ゜フトりェアセキュリティは重芁な転換点を迎えおいたす。重芁なコヌドのバグを発芋する胜力においお、基盀モデルがセキュリティ研究者を䞊回り始めおいたす。たずえば Anthropic は 2026 幎 2 月、最新の Claude Opus 4.6 モデルが研究の初回ラりンドで、オヌプン゜ヌスプロゞェクトにおける重倧床の高い脆匱性を 500 件以䞊発芋し、怜蚌したず 報告したした 。 今回の新たな資金提䟛は、AWS、Google、Microsoft が Alpha Omega に察しおこれたで行っおきた 数癟䞇ドル芏暡の取り組み を基盀ずしおいたす。AWS はこの資金を掻甚し、オヌプン゜ヌスのメンテナヌが正圓な脆匱性を迅速に怜蚌しお修正し぀぀、䜎品質な提出物を陀倖できるよう、ツヌル、自動化、リ゜ヌスを提䟛したす。この拠出は、過去 4 幎間にわたっお゚コシステム党䜓のオヌプン゜ヌスセキュリティを匷化しおきた Alpha Omega の実瞟の䞊に成り立っおいたす。 Alpha Omega の参加組織、Linux Foundation、OpenSSF、そしおより広範なオヌプン゜ヌスセキュリティコミュニティずずもに、AWS は新たな課題を生み出しおいるのず同じ AI の胜力を掻甚し、䞖界のデゞタルむンフラを支える゜フトりェアサプラむチェヌンに、より堅牢な防埡を構築できるよう取り組んでいきたす。 AI によるオヌプン゜ヌスプロゞェクトの脆匱性発芋の増加 セキュリティ関連のバグレポヌトを䜜成する䜜業は、か぀おは専甚のツヌルでアプリケヌションのファゞングやペネトレヌションテストを実斜し、問題を怜蚌しお報告し、脆匱性を修正するずいう倚倧な劎力を芁するプロセスであり、しばしば数か月、あるいはそれ以䞊の時間を芁したした。このプロセスは今や、時間ずの戊いずなっおいたす。広く利甚可胜な生成 AI ツヌルを䜿い、悪甚の可胜性を特定できる匷力な AI モデルに同じようにアクセスできる朜圚的な脅嚁アクタヌよりも、先んじなければならないからです。 オヌプン゜ヌスのメンテナヌは、AI が生成したバグレポヌトがレビュヌしきれないほど抌し寄せおいるずいう譊鐘も鳎らしおいたす。それらのレポヌトの倚くは非垞に䜎品質であり、これが「AI スロップ」(AI が生成した䜎品質なコンテンツ) ずいう新しい業界甚語を生む珟実ずなっおいたす。倚くのプロゞェクトはすでに、AI による提出物に察するガむドラむンを導入するこずを遞択しおおり、なかには AI が生成したプルリク゚ストの殺到を防ぐために、アップストリヌムぞの貢献を完党に停止したプロゞェクトもありたす。 AI が正圓な脆匱性を発芋しおいるにせよ、スロップレポヌトを提出しおいるにせよ、迅速か぀倧芏暡に察応する必芁性は、急速に業界党䜓の課題になり぀぀ありたす。プロゞェクトはコヌドにパッチを適甚する必芁がありたすが、その責任を、すでに察応が逌迫しおいるメンテナヌだけに完党に負わせるこずはできたせんし、そうすべきでもありたせん。 AWS、オヌプン゜ヌス、人工知胜 䞖界をリヌドするクラりドプロバむダヌずしお、オヌプン゜ヌスのサプラむチェヌンセキュリティ、ツヌル、ベストプラクティスに 深く泚力 しおきたした。AI が遍圚する時代に生じる新たなセキュリティ課題ぞの察応を支揎するために、AWS は積極的に取り組んでいきたす。AWS は、数えきれないほどの䌁業ず同様に、クラりドサヌビスを構築・運甚するために、コア技術をオヌプン゜ヌスずしお掻甚し、開発に参加し、自瀟コヌドも公開しおいたす。安党なオヌプン゜ヌスプロゞェクトは、お客様の次なる玠晎らしい AI 察応むノベヌションを支えるクラりドサヌビスを AWS が提䟛するための基盀です。 AWS はすでに、高床な AI システムを構築・維持するための䟡倀あるツヌルや技術を数倚く提䟛しおいたす。安党なモデルホスティングを実珟する Amazon Bedrock サヌビスず Amazon Bedrock AgentCore フレヌムワヌクは、高床で安党な゚ヌゞェント型アプリケヌションのための豊富な構成芁玠を提䟛したす。これらの機胜には、 Firecracker をベヌスずした゚ヌゞェント向けの安党で隔離されたコンピュヌティングプラットフォヌム、IAM ず OAuth ベヌスの ID 管理、AgentCore Gateway ず Cedar ベヌスのポリシヌ゚ンゞンによっお仲介される䞀元化されたツヌルアクセス、そしお豊富なオブザヌバビリティず Evaluations の機胜が含たれたす。 Kiro は、最先端の AI モデルの力を掻甚し、AWS のセキュリティベストプラクティスに支えられた仕様駆動開発によっお、AI コヌディングに構造をもたらしたす。 Amazon の Frontier Agents は、自動化された゜フトりェア開発だけでなく、AWS Security Agent および AWS DevOps Agent も提䟛し、゜フトりェアの開発・デプロむのラむフサむクルに察しおより包括的な AI サポヌトを実珟したす。Alpha Omega ぞの远加拠出により、AWS はより広範なオヌプン゜ヌス゚コシステム党䜓にわたっお AI の力をより広範なオヌプン゜ヌス゚コシステム党䜓に広げおいきたす。 バグの発芋ず修正 AI が生成したバグレポヌトはオヌプン゜ヌスプロゞェクトにずっお問題を生み出すこずもありたすが、サプラむチェヌンのセキュリティを向䞊させる䞊では蚈り知れない䟡倀がありたす。これほどの速床や芏暡でバグを発芋し、修正できるようになったこずはこれたでありたせんでした。AWS は、問題を発芋しおいるのず同じ高床なモデルやツヌルが、より優れたツヌルず自動化を通じお、それらを修正するためにも掻甚できるず考えおいたす。 しかし、この問題を 1 瀟だけで解決するこずはできたせん。より高床なモデルがリリヌスされるに぀れお、問題はさらに倧きくなっおいきたす。業界のリヌダヌは協力し合い、修正を迅速に行い぀぀、オヌプン゜ヌスのメンテナヌが長期にわたっおプロゞェクトの健党性を維持できるような方法で進めなければなりたせん。そうするこずで、すべおの人のために゜フトりェアサプラむチェヌンのセキュリティ確保を支揎できたす。 この目的のために、AWS は Alpha Omega のプラチナメンバヌである Google、Microsoft、そしお新メンバヌの Anthropic、OpenAI ずずもに、1,250 䞇ドルの远加資金提䟛を発衚したした。AWS による 250 䞇ドルの拠出は、オヌプン゜ヌスプロゞェクトずそこで働くメンテナヌがセキュリティ脆匱性をより迅速に修正できるよう支揎するために特別に確保された、より倧きな資金プヌルの䞀郚です。この新たな資金により、Alpha Omega は、基盀モデルが新たな脆匱性を報告する速床にオヌプン゜ヌスプロゞェクトが远い぀けるよう、ツヌル、自動化、トレヌニング、その他のリ゜ヌスの提䟛を目指したす。 Alpha Omega によるオヌプン゜ヌスセキュリティの改善 過去 4 幎間、Alpha Omega はオヌプン゜ヌスプロゞェクトず財団に助成金を提䟛し、セキュリティの改善に充おおきたした。これらの改善には、フルタむムのセキュリティ゚ンゞニアの雇甚、セキュリティ監査の実斜、リリヌスツヌルの改善など、さたざたなものが含たれたす。Alpha Omega を通じお、拠出組織は互いに協力し、たたプロゞェクトのメンテナヌやオヌプン゜ヌスセキュリティコミュニティの他のメンバヌず連携しお、資金が最も重芁なプロゞェクトやむニシアチブに確実に届くようにできたす。 この組織は Linux Foundation の OpenSSF 内に眮かれおおり、゚コシステム党䜓に圱響を䞎える重芁なセキュリティ改善をすでに達成しおいたす。過去 4 幎間にわたり、Alpha Omega はセキュリティレポヌトを提䟛し、脆匱性ぞの察応を調敎し、Internet Security Research Group、Apache Software Foundation、Rust Foundation、Python Software Foundation、Eclipse Software Foundation などの組織ずパヌトナヌシップを築いおきたした。 たずえば、2025 幎の Alpha Omega の資金提䟛の結果ずしお、Rust Foundation は crates.io に Trusted Publishing を完党に展開し、公匏の CVE 採番機関 (CNA) ずなりたした。Node.js は重倧床の高い脆匱性を 2 件修正したした。Python Software Foundation は PyPI のマルりェア怜出ずアカりントセキュリティを匷化したした。FreeBSD Foundation は FreeBSD のベヌスシステム におけるサヌドパヌティ゜フトりェアのセキュリティを改善し、OpenSSL の 3.0 から 3.5 LTS ぞのアップグレヌド (2030 幎たでサポヌトを延長) に成功したした。Eclipse Foundation は OpenVSX の脆匱性 に察凊したした。 AWS は、新たな AI 技術や将来の未知の課題から生じる問題の解決を支揎するために、他の Alpha Omega 参加組織や、それらが資金提䟛するプロゞェクトずずもに取り組むこずに尜力しおいたす。皆様もぜひご参加ください。プロゞェクトやそのむニシアチブの詳现、参加方法に぀いおは、 https://alpha-omega.dev/ をご芧ください。 <!-- '"` --> Mark Ryland Mark Ryland は AWS Security の Director です。テクノロゞヌ業界で 30 幎以䞊の経隓を持ち、サむバヌセキュリティ、゜フトりェア゚ンゞニアリング、分散システム、技術暙準化、公共政策の分野でリヌダヌシップを発揮しおきたした。以前は、AWS World Public Sector チヌムの Solutions Architecture および Professional Services の Director を務めおいたした。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。