AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3894ä»¶

はじめに 生成 AI は、いたやあらゆる産業に新たな䟡倀創出の機䌚をもたらす基盀技術になり぀぀ありたす。文章の䜜成や芁玄、コヌドの生成、問い合わせ察応、専門的な調査の補助など、これたで人手に頌っおいた倚くの業務を支揎できるようになり、生産性向䞊ずむノベヌション創出のカギずしお倧きな期埅が寄せられおいたす。 その䞀方で、機密情報や個人情報を倖郚の生成 AI サヌビスに入力するこずぞの懞念から、本栌的な掻甚に螏み切れない䌁業も少なくありたせん。総務省の調査によれば、玄 7 割の䌁業が AI 掻甚における「セキュリティリスク」を懞念しおおり、産業デヌタの掻甚が十分に進んでいないこずが課題ずしお指摘されおいたす出兞総務省 「什和 6 幎版 情報通信癜曞」 。぀たり、生成 AI の可胜性は広く認識されおいる䞀方で、「安心しお自瀟のデヌタを預けられるのか」ずいう信頌の問題が、掻甚の倧きな壁になっおいたす。 䞀般瀟団法人 AI デヌタ䞻暩共創機構 CODAS : Co-creation Organization for Data Sovereignty & AI はこの課題の解決策ずしお日本発の「信頌できる AI」の構築を目指しおいたす。 CODAS は「秘匿性を基盀ずした産業特化型 AI 基盀の研究開発・実装・実蚌」に取り組む共創組織であり、䌁業・研究機関・行政が察等に参画しながら、日本の産業競争力の匷化ずデヌタ䞻暩の確保を目的ずしおいたす。AWS は、その研究開発を支える倧芏暡蚀語モデルLLMの孊習・掚論基盀の構築をご支揎しおいたす。 この取り組みは、 囜立研究開発法人 新゚ネルギヌ・産業技術総合開発機構NEDO の 「ポスト 5G 情報通信システム基盀匷化研究開発事業デヌタの秘匿性を考慮した効率的な AI 孊習手法の開発」 の䞀環ずしお進められおいたす。同事業では、生成 AI の性胜向䞊を支えおきたりェブ䞊の公開デヌタが孊習し尜くされ぀぀あるなか、今埌の AI 開発においおは䌁業や組織が保有する実デヌタを安党に掻甚するこずが䞍可欠になる、ずいう認識が背景にありたす。しかし、実デヌタの倚くは個人情報や機密情報を含むため、デヌタの秘匿性を考慮した孊習手法の確立が重芁な課題ずしお掲げられおいたす。 本ブログでは、 CODAS が目指す䞖界ず、そのビゞネス的な意矩、そしお、その実珟に向けた第䞀歩ずしお珟圚取り組たれおいる産業特化型 LLM の構築ず、それを支える AWS 䞊の孊習・掚論基盀に぀いおご玹介したす。なお、本蚘事でご玹介するのは、 CODAS の掻動のあくたで初期段階における取り組みのみです。 CODAS の構想はこの先、秘匿性技術の研究開発から瀟䌚実装、さらにはグロヌバルな゚コシステム圢成ぞず倧きな広がりを芋せおいく予定であり、本蚘事はその出発点をお䌝えするものずご理解いただければ幞いです。 CODAS が目指す、デヌタ秘匿性を考慮した産業特化型倧芏暡蚀語モデルの構築 なぜ「秘匿性」なのか 珟圚広く䜿われおいる汎甚的な生成 AI は玠晎らしい技術である䞀方、機密情報や個人情報の取り扱いずいう芳点では、䌁業に倧きな懞念を残しおいたす。 CODAS は、この課題を倧きく 3 ぀のリスクずしお敎理しおいたす。 第䞀に、機密情報・デヌタの流出リスクです。䌁業が倖郚の AI サヌビスに機密デヌタを入力する堎合、サヌビスの利甚条件や蚭定に応じお、入力デヌタの保存堎所、保持期間、孊習ぞの利甚有無などを十分に確認する必芁がありたす。䌁業にずっお、顧客デヌタ、取匕情報、技術情報ずいった競争力の源泉が、意図せず倖郚に流出するリスクは看過できたせん。 第二に、プラむバシヌ䟵害ずデヌタ䞻暩の喪倱リスクです。孊習デヌタからの個人特定メンバヌシップ掚論攻撃や孊習デヌタの再構成などや、自瀟デヌタが管理の及ばない環境で凊理・保存されるこずぞの懞念がありたす。加えお、各囜でデヌタ保護芏制が匷化されるなか、デヌタを囜内で管理し、芏制に準拠しながら掻甚するこずの重芁性が高たっおおり、芏制察応の負担も増しおいたす。デヌタがどこにあり、誰がアクセスでき、有事にも継続的に利甚できるのかずいう「デヌタ䞻暩」は、経営レベルの論点になり぀぀ありたす。 第䞉に、こうした懞念が日本䌁業を AI 掻甚に螏み切れなくさせおいる、ずいう珟実です。 䞀般瀟団法人 日本情報システム・ナヌザヌ協䌚JUAS の調査では、䌁業が AI 掻甚で懞念するリスクずしお、デヌタ挏掩リスク70.3%、AI の誀回答リスク65.2%、プラむバシヌ䟵害リスク65.0%、法什違反リスク50.5%が挙げられおいたす出兞JUAS 「䌁業 IT 動向調査 2025」 。懞念が先に立぀こずで、本来であれば倧きな䟡倀を生むはずのデヌタ掻甚が埌回しになっおしたう。この「もったいない」状況こそ、 CODAS が解こうずしおいる課題です。 CODAS は、この状況に察しお「デヌタは動かさない、モデルが動く」Privacy-First AIずいう発想の転換を掲げおいたす。デヌタを倖郚に送り出すのではなく、デヌタが自瀟の管理䞋に留たったたたで AI を掻甚できる䞖界を目指すものです。この発想は、単に情報挏掩を防ぐずいう守りの意味にずどたりたせん。これたで秘匿性ぞの懞念から掻甚が進たなかった高䟡倀なデヌタを、安心しお AI に掻かせるようにするこずで、日本䌁業のデヌタ掻甚そのものを前に進める攻めの䞀手でもありたす。守りず攻めを同時に成立させる。ここに、秘匿性を基盀ずする AI のビゞネス的な意矩がありたす。 ロヌドマップず珟圚のフェヌズ CODAS の最終目暙は、デヌタ挏掩防止、プラむバシヌ䟵害耐性、デヌタ䞻暩の確保ずいった秘匿性を担保しながら、産業の実務に耐えうる高性胜な AI を実珟するこずです。差分プラむバシヌや秘密蚈算などの秘匿性技術ず、産業に特化したモデルを組み合わせるこずで、汎甚モデルにはない「信頌性」ず「専門性」の䞡立を目指しおいたす。秘匿性を高めるほど性胜ずのトレヌドオフが生じやすいため、この䞡立には継続的な研究開発ず匷固な蚈算基盀が欠かせたせん。 秘匿性技術は、適甚先ずなる高性胜なベヌスモデルがあっお初めお実蚌・評䟡できたす。そのため CODAS は、たず秘匿性研究の土台ずなる産業特化型倧芏暡蚀語モデルを構築し、その䞊で秘匿性技術の研究開発を積み䞊げるアプロヌチを取っおいたす。 このベヌスモデルは領域特化の高床な凊理を担い、各䌁業のナヌスケヌスに特化した個瀟モデルず連携する 2 局構造を想定しおいたす。特に、情報挏掩リスクぞの懞念から慎重な刀断が求められる金融・保険領域を最優先の実装領域ず䜍眮づけ、瀟䌚実装の暙準を確立するこずを目指しおいたす。たた、特定のモデルに䟝存しない開発手法を採甚し、今埌さらに高性胜なモデルが登堎しおも柔軟に取り入れられるようにしおいたす。 CODAS では、倧孊や専門䌁業が秘匿性技術に関する耇数の研究テヌマを分担しおいたす。ベヌスずなる LLM の開発は ABEJA 様が担い、AWS は倧芏暡なモデル孊習を支える蚈算基盀の構築を支揎しおいたす。各研究テヌマ、ベヌスモデル、蚈算基盀を組み合わせる䜓制が、 CODAS の挑戊を支えおいたす。 産業特化型倧芏暡蚀語モデルの孊習ず評䟡に関する取り組み 産業特化型倧芏暡蚀語モデル開発の第䞀段階ずしお、 CODAS では、パブリックデヌタをベヌスずした倧芏暡コヌパスの構築、教垫付きファむンチュヌニング甚デヌタセットの合成、継続的事前孊習ず事埌孊習教垫付きファむンチュヌニングおよび匷化孊習、孊習枈みモデルの評䟡に取り組んでいたす。本節では、こうした孊習・評䟡の考え方ず䞻な怜蚌内容を玹介したす。 (1) 孊習枈みモデルの評䟡 モデルの性胜は、日本語・英語それぞれにおける汎甚的な胜力ず、金融分野に特化したタスクを遂行する胜力の䞡面から評䟡したす。このため、耇数のパブリックデヌタセットを遞定し、必芁に応じお察象タスクに合わせた改修を行いたした。 評䟡には、正解ずの䞀臎を確認する機械採点に加え、自由蚘述など単玔な正誀刀定が難しいタスクに察応するため、LLM-as-a-Judge を甚いおいたす。これにより、モデルが金融領域の知識を獲埗しおいるかだけでなく、汎甚的な蚀語胜力を維持できおいるかを継続的に確認したす。 図 1: JLM-Fin-Eval ず EDINET-Bench を甚いた、汎甚胜力ず金融分野の胜力を評䟡するベンチマヌクの䟋 (2) 倧芏暡コヌパスの䜜成ず事前孊習 継続的事前孊習に向けお、察象領域の知識を取り蟌むための倧芏暡コヌパスを準備しおいたす。コヌパスの品質や構成は、その埌のモデル性胜に倧きく圱響するため、デヌタの収集・敎圢・遞別を行ったうえで孊習に甚いたす。 たた、孊習の実斜を通じお、デヌタ構成や孊習条件がモデルの汎甚胜力および金融関連タスクの性胜に䞎える圱響を怜蚌しおいたす。 (3) 孊習甚デヌタセットの合成ず教垫付きファむンチュヌニング 事埌孊習では、教垫付きファむンチュヌニングSupervised Fine-Tuning、SFTに甚いる孊習デヌタセットを、生成 AI モデルを掻甚しお合成しおいたす。金融関連タスクの性胜を高めながら汎甚的な胜力も維持・向䞊させるため、金融特化型デヌタセットず汎甚デヌタセットを組み合わせたす。 怜蚌では、孊習察象モデルの系統を考慮し、SFT 甚デヌタの生成に甚いるモデルの違いが、SFT 埌の性胜に䞎える圱響を分析しおいたす。あわせお、金融特化型デヌタず汎甚デヌタの配合を倉え、汎甚胜力ず金融関連タスクの遂行胜力をバランス良く最適化する方法を怜蚎しおいたす。 図 2: 合成デヌタ生成モデルの系統差が SFT 埌の性胜に䞎える圱響を怜蚌する考え方 (4) 匷化孊習による論理的胜力の匷化ず指瀺远埓胜力の回埩 SFT に加えお、論理的胜力の向䞊を目的ずした匷化孊習Reinforcement Learning、RLにも取り組んでいたす。匷化孊習では数理的胜力の向䞊に加え、SFT 埌に生じ埗る指瀺远埓胜力の䜎䞋、特に指瀺に含たれる出力制玄を守る胜力の䜎䞋を改善するこずを目指したす。 評䟡の結果、SFT 埌に実斜する匷化孊習が、こうした指瀺远埓胜力の回埩に寄䞎するこずを確認したした。モデルの胜力を単䞀の指暙で評䟡するのではなく、論理性、指瀺远埓性、専門領域のタスク性胜を総合的に捉えながら、孊習方法を改善しおいたす。 図 3: SFT 埌に䜎䞋した指瀺远埓胜力ず、RL による性胜回埩の評䟡結果 デヌタセットの構成、実隓条件、評䟡方法、詳现な結果に぀いおは、今埌 ABEJA 様の技術ブログ にお公開予定です。 合成デヌタの䜜成、産業特化型倧芏暡蚀語モデルの孊習、および、孊習枈みモデルの評䟡を実行するためには、GPU を含む倧芏暡蚈算機リ゜ヌスが必芁ずなりたす。たた、倚くの GPU を甚いお効率的に分散孊習を行うには、ストレヌゞ・ネットワヌク通信の芳点でも怜蚎すべき事項がありたす。さらに、安党に開発を進めるうえでは暩限呚りの管理・運甚も䞍可欠です。 CODAS では、産業特化型倧芏暡蚀語モデル構築のための孊習・掚論基盀ずしお、72 台の p5en.48xlarge EC2 むンスタンスをコンピュヌトノヌドずしお利甚する、 AWS ParallelCluster を甚いた倧芏暡 GPU クラスタヌを AWS 䞊に構築しおいたす。次章では、AWS 䞊でのモデル孊習・掚論基盀の構築に぀いお玹介したす。 AWS 䞊で実珟する倧芏暡蚀語モデル孊習・掚論基盀 倧芏暡孊習基盀の蚭蚈方針 倧芏暡蚀語モデルの孊習・掚論基盀を構築するには、GPU の蚈算性胜だけでなく、ノヌド間通信、共有ストレヌゞ、ゞョブ管理、監芖を䞀䜓ずしお蚭蚈する必芁がありたす。そのために CODAS が初期構築の出発点ずしたのが、AWS Labs のオヌプン゜ヌスである awsome-distributed-ai 旧称 awsome-distributed-trainingです。同リポゞトリでは、倧芏暡モデル孊習向けのリファレンスアヌキテクチャ、孊習甚サンプル、怜蚌・オブザヌバビリティ甚ツヌルをたずめたものをオヌプン゜ヌスで提䟛しおいたす。 孊習・掚論基盀の実装時には、awsome-distributed-ai リポゞトリに含たれるリファレンスアヌキテクチャを VPC、共有ストレヌゞ、Elastic Fabric AdapterEFA、Slurm ずいった分散孊習基盀の䞻芁な構成芁玠を構築するための出発点ずしたした。これにより、䞀からすべお自分たちで組み立おるのではなく、耇数のチヌムで GPU クラスタヌを共同利甚する際のロヌルや暩限、接続方法、安定運甚のための蚭蚈を含む、独自の芁件に関する議論ず実装に泚力しやすくなりたした。リファレンスアヌキテクチャはあくたで汎甚的なものです。そのため、そのたた採甚するのではなく、実際の甚途ず運甚䜓制に合わせお、䞍芁な芁玠の削陀や、安党性向䞊などを目的ずしお必芁な仕組みを远加実装するこずが重芁です。 孊習・掚論基盀の党䜓像 クラスタヌの構築ず管理には AWS ParallelCluster を利甚し、ゞョブスケゞュヌラヌずしお Slurm を採甚しおいたす。ヘッドノヌドは Slurm のスケゞュヌリングずクラスタヌ制埡を担っおいたす。ナヌザヌは別途立ち䞊げたログむンノヌド䞊で通垞のコヌディング䜜業やゞョブ投入、コンテナの準備などを実斜するこずが可胜です。孊習ゞョブは EFA を備えた GPU コンピュヌトノヌド䞊で実行し、Enroot ず Pyxis を組み合わせお、Slurm からコンテナ化した孊習環境を起動しおいたす。珟圚は NVIDIA H200 を 8 基搭茉した p5en.48xlarge GPU むンスタンス 72 台をワヌカヌノヌドずする芏暡たでスケヌルしおいたす。 ストレヌゞは圹割に応じお䜿い分けを行っおおり、孊習デヌタやチェックポむントを扱うための高性胜な共有領域には Amazon FSx for Lustre 、ホヌム領域には Amazon FSx for OpenZFS を採甚しおいたす。たた、 Amazon S3 ず FSx for Lustre は Data Repository AssociationDRA で連携しおいたす。䞻芁コンポヌネントずデヌタの流れを 図 4 のアヌキテクチャ図に瀺したす。 図 4: AWS ParallelCluster ず Amazon EC2 GPU むンスタンスを甚いお構築した倧芏暡蚀語モデル甚孊習・掚論基盀のアヌキテクチャ図 組織独自の芁件を仕組みに萜ずし蟌む 倧芏暡 GPU クラスタヌを耇数のチヌムで継続的に利甚するには、GPU やネットワヌクの性胜だけでなく、誰が、どのように、安党に利甚できるかをあらかじめ蚭蚈しおおくこずが重芁です。そこで、本環境ではクラスタヌぞのナヌザヌアクセスを AWS Systems Manager Session Manager に䞀本化し、SSH キヌペアを前提ずしない構成を採甚しおいたす。さらに、SSH キヌペアが蚭定された堎合にはクラスタヌのデプロむを倱敗させるこずで、意図せずアクセス方針から逞脱した構成になるこずを防ぎたす。IAM 暩限に぀いおも、構築・運甚に必芁な暩限を敎理し、最小暩限の原則に沿っお蚭定しおいたす。 ノヌドごずに圹割を明確に分離しおいる点も、この基盀の特城です。ヘッドノヌドは Slurm のスケゞュヌリングずクラスタヌ制埡に専念させ、日垞的なコヌディング、コンテナの準備、ゞョブ投入はログむンノヌドで行いたす。これにより、ナヌザヌの䜜業がクラスタヌ制埡に圱響するこずを抑え、安定した運甚に぀なげたす。耇数のチヌムが利甚する環境では、チヌムごずにログむンノヌドのプヌルを甚意し぀぀、党ノヌドのナヌザヌ IDUIDずグルヌプ IDGIDを統䞀的に管理したす。共有ファむルシステム䞊の所有暩ず Slurm が認識する利甚者を敎合させるこずで、チヌムをたたぐデヌタセットやモデルの共同利甚も可胜にしおいたす。 たた、コンテナのビルドは䞀時的に倧きなディスク負荷を発生させるため、ログむンノヌドのルヌトボリュヌムに負荷が集䞭しない蚭蚈ずしおいたす。ルヌト EBS ボリュヌムの容量を確保するずずもに、成果物は FSx の共有ストレヌゞに配眮したす。ロヌカル NVMe を利甚する凊理に぀いおは、Slurm デヌモンの起動前に NVMe の準備ずマりント元の怜蚌を完了させたす。想定したストレヌゞを利甚できない堎合には凊理を停止するこずで、䞍完党な状態でノヌドが起動するこずを防ぎたす。 異垞の早期顕圚化ず蚈枬に基づく運甚 倧芏暡分散孊習では、単䞀ノヌドの異垞やストレヌゞ容量の䞍足、ネットワヌク通信の䞍調が、孊習ゞョブ党䜓の性胜や成吊に圱響したす。そのため、 Amazon CloudWatch 、 Amazon Simple Notification ServiceAmazon SNS 、 AWS Lambda 、Slack を組み合わせ、FSx for Lustre の容量しきい倀超過や GPU の故障を自動的に通知する仕組みを蚭けおいたす。クラスタヌの利甚者ず管理者は必芁な状況を速やかに把握し、ストレヌゞの拡匵やノヌドの切り離しずいった察応を刀断できたす。 ノヌド間通信では、コンピュヌトノヌドの構成時に EFA デバむスの存圚だけでなく、EFA プロバむダヌを実際に利甚できるこずたで確認したす。怜蚌に倱敗した堎合は、蚺断に必芁なログを残しおデプロむを停止したす。こうした事前怜蚌により、ゞョブは実行できおも通信性胜が十分に出ないずいう発芋しにくい問題を、孊習開始前に怜出できたす。 ストレヌゞに぀いおも、掚枬ではなく実枬したメトリクスに基づいおボトルネックを切り分け、必芁に応じお容量をスケヌルさせる運甚ずしおいたす。ノヌド障害、通信、ストレヌゞのいずれも䟋倖ずしお扱うのではなく、発生を前提に怜知・刀断・察応できるようにしおおくこずが、倧芏暡 GPU クラスタヌの継続的な利甚には䞍可欠です。 ここたで玹介した工倫に共通するのは、運甚䞊のルヌルや障害時の察応を手順曞にずどめず、クラスタヌのデプロむや起動の過皋で自動的に確認できる仕組みずしお実装しおいる点です。リファレンスアヌキテクチャを出発点にしながら、組織の利甚圢態や実運甚で埗られる知芋を構成ぞ反映し続けるこずで、耇数チヌムが倧芏暡蚀語モデルの孊習・掚論基盀を安定しお共同利甚できる環境を目指しおいたす。 おわりに 本ブログでは CODAS によるデヌタの秘匿性を考慮した AI 孊習手法の開発に関する倧芏暡蚀語モデル孊習・掚論基盀の構築に向けた取り組みに぀いお玹介したした。䞊述の通り、本ブログで玹介した内容は CODAS による初期段階の取り組みの䞀郚に関するもののみであり、 CODAS の掻動は今埌さらに倧きく広がりを芋せおいく予定です。AWS では CODAS 担圓アカりントチヌム、コンピュヌト・生成 AI スペシャリストチヌム、生成 AI むノベヌションセンタヌなど、耇数のチヌムが䞀䞞ずなっお、 CODAS の本掻動に察する支揎を行っおいたす。 著者プロフィヌル 原田 䌎誉 (Tomotaka Harada) 株匏䌚瀟ABEJA ゚ンタヌプラむズプラットフォヌム開発本郚デヌタサむ゚ンス郚所属。京郜倧孊倧孊院修了埌、金属メヌカヌでプラント゚ンゞニアリングずDX掚進に埓事し、蚭備自動化や画像凊理を掻甚した怜査自動化、デヌタ掻甚を掚進。圚職䞭にボストン倧孊でApplied Data Analyticsを修了し、米囜䌁業で画像AI開発も経隓。ABEJAではRAG、レコメンドシステム、スポヌツ動䜜解析、盎近はLLM開発に参画し、補造珟堎の理解ずAI開発力を䜵せ持぀゚ンゞニアずしおプロゞェクトを掚進しおいる。 久米 拓銬 (Takuma Kume) 株匏䌚瀟ABEJA 経営䌁画統括郚 情報システム・セキュリティグルヌプ所属。AWSでのむンフラ構築を専業ずするSierに8幎所属。むンフラの構築から運甚や蚭蚈提案を経隓し、新芏立ち䞊げからマむグレヌションなど幅広く察応。ABEJAでは情報システム郚門の運甚をメむンずし、前職での知芋を掻かしお単䜓プロゞェクトのむンフラ構築支揎を実斜。 長谷川 最 (Jun Hasegawa) CODAS の最高プロゞェクト責任者であり、創業者リサヌチャヌです。連続起業家ずしお、Omise決枈事業ず OMG Networkブロックチェヌン事業を創業し、いずれもナニコヌン䌁業ぞ成長させたした。これたでに环蚈 5 億ドル以䞊を調達し、珟圚は決枈・ブロックチェヌン・プラむバシヌ AI の 3 領域でグロヌバル事業を率いおいたす。 äž­è¶Š 掋(Hiroshi Nakagoe) CODAS の Technical Head および Archetype Digital の VPoE ずしお、プラむバシヌ保護技術に関する 7 件の研究プロゞェクト、1 ぀の統合型生成 AI プラットフォヌム、プラむバシヌ保護 AI システムを評䟡する耇数の PoC など、研究開発ず瀟䌚実装プロゞェクトをリヌドしおいたす。テクノロゞヌ業界で 20 幎以䞊の経隓を持ち、ML/AI サヌビス、デヌタ分析プラットフォヌム、IoT サヌビス、゚ンタヌプラむズストレヌゞ、゚ンタヌプラむズ向け運甚ツヌル、LSI の研究開発を通じお、専門知識を実瀟䌚の課題解決に応甚しおきたした。東京を拠点に掻動しおいたす。 黒柀 蓮 (Ren Kurosawa) AWS Startup Frontier AI ゜リュヌションアヌキテクトで、Startup 業界のお客様を䞭心にアヌキテクチャ蚭蚈や構築をサポヌトしおいたす。デヌタアナリティクスサヌビスや機械孊習の領域を埗意ずしおいたす。将来の倢は宇宙でポ゚ムを詠むこずです。 畔柳 竜生 (Tatsuo Azeyanagi) AWS Generative AI Innovation Center の Senior Applied Scientist です。生成 AI や機械孊習サヌビスを掻甚し、顧客の課題解決に取り組んでいたす。AWS に入瀟する前は、日本、アメリカ、フランス、ベルギヌの倧孊・研究機関にお、玠粒子論の研究をしおいたした。 束浊 倧茝 AWS Startup, Frontier AI Team の Account Manager です。生成 AI の基盀モデル開発䌁業からフィゞカル AI スタヌトアップたで、日本の最先端 AI 䌁業のクラりド掻甚ず事業成長をご支揎しおいたす。GPU クラスタヌを掻甚した倧芏暡孊習基盀の構築支揎や、業界暪断のコミュニティ圢成にも取り組んでいたす。
本蚘事は 2026 幎 9 月 8 日 に公開された「 Getting started with Oracle Database@AWS: A complete onboarding guide 」を翻蚳したものです。 Oracle Database@AWS (ODB@AWS) は、Oracle Exadata Database Service ず Oracle Autonomous Database を AWS デヌタセンタヌ内でネむティブに提䟛したす。Oracle ワヌクロヌドは専甚蚭蚈の Exadata むンフラストラクチャ䞊で動䜜し、 Amazon Bedrock 、 Amazon Redshift 、 AWS Key Management Service (AWS KMS) 、 Amazon CloudWatch 、 AWS CloudTrail ずいった AWS サヌビスに䜎レむテンシヌでアクセスできたす。同時に、Oracle デヌタベヌス゚ンゞン、Exadata のパフォヌマンス特性、そしおチヌムが珟圚䜿っおいる DBA ツヌルもそのたた維持できたす。 本蚘事では、Oracle Database@AWS のオンボヌディングを、サヌビスの遞定からプロビゞョニング可胜な環境が敎うたで通しお解説したす。必芁なサヌビスに応じお、簡略化されたパブリックオファヌの経路ず、5 ステップからなるプラむベヌトオファヌの経路のどちらかをたどりたす。どちらの経路も解説したす。 Autonomous Database Serverless (ADB-S) ず Exascale Infrastructure (ExaDB-XS) 䞊の Exadata Database Service に぀いおは、 AWS Marketplace でパブリックオファヌが提䟛されおおり、事前の調達手続きは芁りたせん。サブスクラむブすれば数分でプロビゞョニングを始められたす。ステップ 1 のサヌビス遞定衚で、適切な出発点がわかりたす。 オンボヌディングの党䜓像 サヌビスの遞定からプロビゞョニング可胜な環境が敎うたでの流れは、2 ぀のフェヌズに分かれたす。 調達 (ステップ 1〜2): サヌビスを遞び、オファヌ (パブリックたたはプラむベヌト) を確保し、AWS Marketplace で承諟したす。 オンボヌディング (ステップ 3〜5): アカりントの前提条件を確認し、OCI テナンシをリンクし、䞡クラりドで ID ずアクセス蚱可を蚭定したす。 ここたで終われば、プロビゞョニングの準備が敎いたす。ODB ネットワヌク、Exadata むンフラストラクチャ、VM クラスタヌの䜜成は「次のステップ」で扱いたす。 2 ぀のフェヌズに察応する 5 ぀のステップは次のずおりです。 サヌビスを遞定し、オファヌを確保する。 オファヌを承諟する。 前提条件を確認する。 OCI テナンシをリンクする。 AWS Identity and Access Management (IAM) のグルヌプずロヌルを蚭定する。 次の図は、5 ぀のステップを 2 ぀のフェヌズにグルヌプ分けしたものです。 図 1: 調達フェヌズずオンボヌディングフェヌズに分けた 5 ぀のオンボヌディングステップ ステップ 1: サヌビスを遞定し、オファヌを確保する たず、ワヌクロヌドに適した Oracle Database@AWS のサヌビスを芋極めたす。遞んだサヌビスによっお、䜿える機胜ずたどる調達経路の䞡方が決たりたす。 サヌビスず調達経路を遞ぶ サヌビス オファヌの皮類 遞ぶ堎面 Exadata Database Service on Dedicated Infrastructure (ExaDB-D) プラむベヌトオファヌ (ステップ 1〜5) 次のいずれかが必芁な堎合。完党なシングルテナント分離を備えた専甚 Exadata ラック、ノヌド数・ECPU・メモリを完党に制埡できる Oracle RAC、倧芏暡な統合環境向けの極めお高いスケヌラビリティ、Oracle COTS アプリケヌション (PeopleSoft、E-Business Suite、JD Edwards、Siebel、CC&B) 向けの認定 MAA アヌキテクチャ。 Exadata Database Service on Exascale Infrastructure (ExaDB-XS) パブリックオファヌ (ステップ 3 ぞ) たたはプラむベヌトオファヌ 専甚むンフラストラクチャなしで Exadata の性胜をフルに䜿いたい堎合。芏暡の異なる本番デヌタベヌス、サヌビス間 Data Guard による DR スタンバむ、開発・テスト環境、小さく始めお成長するワヌクロヌドに向いおいたす。むンフラストラクチャの最小コミットメントはありたせん。 Autonomous Database Serverless (ADB-S) パブリックオファヌ (ステップ 3 ぞ) たたはプラむベヌトオファヌ むンフラストラクチャに関する刀断が䞀切䞍芁なフルマネヌゞドの Oracle デヌタベヌスを䜿いたい堎合。パッチ適甚、チュヌニング、スケヌリング、可甚性は Oracle が担いたす。OLTP、分析、混圚ワヌクロヌド、アむドル時の自動䞀時停止に向いおいたす。 Autonomous Database on Dedicated Exadata Infrastructure (ADB-D) プラむベヌトオファヌ (ステップ 1〜5) 完党な専甚むンフラストラクチャ䞊で自埋運甚が必芁な堎合。パッチ適甚ずチュヌニングは Oracle が担い぀぀、メンテナンスりィンドりずシングルテナント分離の制埡は自瀟で保持したす。 ワヌクロヌドが ExaDB-XS たたは ADB-S に合っおいお、パブリックオファヌで芁件を満たせるなら、むンフラストラクチャのサむゞングや Oracle ずの事前調敎は芁りたせん。 Oracle Database@AWS の AWS Marketplace ペヌゞからサブスクラむブし、ステップ 3 に進んでください。パブリックオファヌで提䟛されるサヌビスの最新のリヌゞョン察応状況は、 Regional Availability for Oracle AI Database@AWS を参照しおください。 ExaDB-D たたは ADB-D をデプロむする堎合、あるいは亀枉䟡栌やコミット条件が必芁な堎合は、以降のセクションのプラむベヌトオファヌのプロセスに進みたす。 プラむベヌトオファヌをリク゚ストする プラむベヌトオファヌは、ワヌクロヌド芁件に合わせお自瀟ず Oracle の間で結ぶ亀枉ベヌスの契玄です。手順は次のずおりです。 AWS Management Console の Oracle Database@AWS 補品ペヌゞで Request private offer を遞びたす。OCI にリダむレクトされ、AWS リヌゞョン、ワヌクロヌド芁件、連絡先情報を入力したす。 あるいは、Oracle のアカりントチヌムか AWS チャネルパヌトナヌに盎接䟝頌しおリク゚ストを開始するこずもできたす。 最初に AWS アカりント ID を䌝えたす。Oracle が正しいアカりント向けにオファヌを生成するために必芁です。 ヒント: AWR Miner や Oracle 提䟛のサむゞングナヌティリティ (Cloud Premigration Advisor Tool ( CPAT )、 ORAchk ) を、移行元デヌタベヌスに察しお早い段階で実行しおおきたしょう。出力はそのたたサむゞング䜜業に䜿えるため、最初から粟床の高いオファヌを組み立おられたす。 賌入者アカりントを遞ぶ ODB@AWS を調達するず、゚ンタむトルメントは賌入者アカりント (buyer account) ず呌ばれる単䞀の AWS アカりントに玐付きたす。マルチアカりント環境では、組織の管理アカりントである必芁はありたせん。AWS のベストプラクティスずしおは、商甚契玄を保持する専甚の賌入者アカりントを掚奚したす。賌入者アカりントは AWS Resource Access Manager (AWS RAM) を䜿い、同䞀 AWS Organization 内のワヌクロヌドアカりントず゚ンタむトルメントを共有したす。調達のガバナンスずむンフラストラクチャのデプロむを分離でき、監査蚌跡も明確に保おたす。単䞀ワヌクロヌドのデプロむなら、賌入者アカりントずワヌクロヌドアカりントを同じにしおも構いたせん。 抂念 説明 ODB@AWS での圹割 賌入者アカりント プラむベヌトオファヌを承諟し、AWS Marketplace のサブスクリプションを保持する AWS アカりント ODB@AWS の゚ンタむトルメントを受け取り、OCI SKU の請求先ずなり、OCI テナンシずリンクされたす。プロビゞョニングはすべおこのアカりントから行うか、このアカりントから共有されたす。 管理アカりント 䞀括請求ず SCP を管理する AWS Organization のルヌトアカりント 賌入者アカりントである堎合もそうでない堎合もありたす。組織が専甚の調達アカりントを䜿っおいるなら、管理アカりントではなくそのアカりントが賌入者になりたす。 重芁: 賌入者アカりントは、オンボヌディング埌に OCI テナンシず恒久的にリンクされたす。埌から倉曎するには再オンボヌディングが必芁です。 オファヌをリク゚ストする前に、抂念実蚌 (PoC) の段階であっおもアカりントの遞定を枈たせおおきたしょう。本番で䜿う予定の賌入者アカりントで PoC を始めれば、プラむベヌトオファヌをその堎で远加するだけで本番ぞ移行できたす。OCI テナンシのリンク、ネットワヌク構成、既存のむンフラストラクチャはそのたた匕き継がれたす。オンボヌディング埌に賌入者アカりントを倉曎するず、再オンボヌディングを䞀からやり盎すこずになり、OCI テナンシの再マッピング、ネットワヌクの再構築、堎合によっおはデヌタ移行たで必芁になりたす。 マルチアカりント構成の組織では、 AWS License Manager を䜿い、賌入者アカりントから同䞀 AWS Organization 内のワヌクロヌドアカりントぞ ODB@AWS のサブスクリプションを共有できたす。アカりント間のリ゜ヌス共有には AWS Resource Access Manager (AWS RAM) を䜿いたす。オファヌをリク゚ストする前に、賌入者アカりントの方針を決めおおきたしょう。 シンプル構成: 賌入者アカりントずワヌクロヌドアカりントが同䞀。単䞀ワヌクロヌドや PoC のデプロむに向いおいたす。 ゚ンタヌプラむズ構成: 専甚の賌入者アカりントたたは調達アカりントを甚意し、License Manager で゚ンタむトルメントを共有したす。耇数のワヌクロヌドアカりントを持぀ランディングゟヌンのパタヌンに向いおいたす。 詳现な手順は Request Offer for Oracle AI Database@AWS を参照しおください。マルチアカりントでの共有に぀いおは Subscription Sharing for Oracle AI Database@AWS を参照しおください。 タヌゲットアヌキテクチャずサむゞングを決める (ExaDB-D ず ADB-D) 専甚むンフラストラクチャのサヌビスでは、サむゞングによっお SKU の数量が決たり、それがそのたたオファヌに反映されたす。サむゞングは Oracle、AWS、そしおチャネルパヌトナヌが関わる堎合はパヌトナヌも含めた共同䜜業です。移行元デヌタベヌスの AWR Miner の出力を Oracle に提䟛したす。そのデヌタをもずに、ワヌクロヌドの特性を Exadata の構成 (シェむプ、ECPU の割り圓お、ストレヌゞ容量、環境数) に萜ずし蟌む䜜業を Oracle が支揎したす。 デヌタベヌス局では、次の点を蚈画したす。 Exadata むンフラストラクチャの配眮 (アベむラビリティヌゟヌンの遞定)。 VM クラスタヌの構成。䞀般には本番クラスタヌ、マルチ AZ Data Guard 甚の DR クラスタヌ、1 ぀以䞊の非本番クラスタヌです。 Oracle のマルチテナントアヌキテクチャを䜿った CDB/PDB の統合方針。 Autonomous Recovery Service (ARS) 、Amazon Simple Storage Service (Amazon S3)、たたはその䞡方を䜿ったバックアップ方針。 Navigating backup and recovery options for Oracle Database@AWS を参照しおください。 クラむアントサブネットずバックアップサブネットの CIDR を含む ODB ネットワヌクの蚭蚈。 アプリケヌション局では、次の点を蚈画したす。 app-to-DB のレむテンシヌを 200 マむクロ秒未満にするため、ODB@AWS のプレむスメントグルヌプ内に EC2 むンスタンスを配眮する。 高性胜ネットワヌキングのプレむスメントグルヌプ を参照しおください。 Virtual Private Cloud (VPC) の蚭蚈、サブネット、セキュリティグルヌプ、ODB ピアリングの接続構成。 ロヌドバランシング (Application Load Balancer たたは Network Load Balancer) ず Auto Scaling グルヌプ。 コンテナ化したアプリケヌションコンポヌネント向けの Amazon Elastic Kubernetes Service (Amazon EKS) たたは Amazon Elastic Container Service (Amazon ECS)。 Amazon Elastic File System (Amazon EFS) による共有ストレヌゞ、Amazon CloudWatch によるモニタリング、Terraform たたは AWS CloudFormation による Infrastructure as Code。 オファヌの皮類を遞ぶ Oracle のプラむベヌトオファヌには、調達チャネルに応じお 2 皮類ありたす。 オファヌの皮類 仕組み 遞ぶ堎面 Marketplace Private Offer (MPPO) Oracle が賌入者アカりント向けに AWS Marketplace 䞊で盎接オファヌを生成したす。 すでに Oracle ず盎接取匕があり、条件を Oracle ず盎接亀枉したい堎合。 Channel Partner Private Offer (CPPO) チャネルパヌトナヌが、Oracle 提䟛のオファヌを AWS Marketplace から自瀟アカりントに提瀺したす。 チャネルパヌトナヌ経由で調達する堎合、たたはそのパヌトナヌ経由で請求をたずめたい堎合。 すでに Oracle ず盎接取匕があるなら MPPO を遞びたす。 チャネルパヌトナヌ経由で調達する堎合、たたはそのパヌトナヌ経由で請求をたずめたい堎合は CPPO が適しおいたす。 請求モデルを最初に確認しおおきたす。自瀟の AWS アカりントぞの盎接請求 (MPPO) か、パヌトナヌ経由 (CPPO) かです。 オファヌの前提情報を揃える: アカりント ID、SKU、契玄条件 Oracle たたはチャネルパヌトナヌがオファヌを生成する前に、次の情報を揃えたす。 AWS 賌入者アカりント ID: オファヌを承諟する 12 桁の AWS アカりント ID。 怜蚎察象の SKU: Exadata Cloud Infrastructure X11M および X11MV (デヌタベヌスサヌバヌずストレヌゞサヌバヌを含む固定むンフラストラクチャコスト)。 Exadata Database ECPU、License Included たたは BYOL (倉動するコンピュヌトコスト)。 Autonomous Database を䜿う堎合は Autonomous AI Database ECPU (LI たたは BYOL)。 パブリックオファヌのサヌビスを䜿う堎合は ExaDB-XS たたは ADB-S (埓量課金、最小コミットメントなし)。 バックアップ芁件に応じお Autonomous Recovery Service たたは Zero Data Loss Recovery。 OCI 偎のストレヌゞを远加で必芁ずする堎合は OCI Object Storage。 契玄期間: 通垞は 1 幎、3 幎、たたはカスタム期間。 SKU ごずのラむセンスモデル: License Included (LI) たたは Bring Your Own License (BYOL)。 各環境 (本番、DR、非本番) を、具䜓的な SKU の数量ず䜿甚時間に察応付けたす。ECPU コストを最適化するため、非本番環境の皌働時間を決めおおきたす。非本番環境では月 264 時間が䞀般的な目安です。 Oracle がオファヌを生成する 前提情報がすべお確定した埌、最終的な入力からオファヌが利甚可胜になるたでの目安は 2〜5 営業日です。流れは次のずおりです。 Oracle の営業担圓が、指定された賌入者アカりントを察象に AWS Marketplace 䞊でプラむベヌトオファヌを䜜成したす。 オファヌには、合意した SKU、数量、䟡栌、契玄期間が含たれたす。 CPPO の堎合、Oracle はチャネルパヌトナヌから提䟛された情報をもずにオファヌを生成したす。 オファヌは AWS Management Console の Oracle Database@AWS に衚瀺されたす。 View private offer を遞んで内容を確認し、承諟したす。 詳现な手順は Purchase Oracle AI Database@AWS を参照しおください。 ステップ 2: オファヌを承諟する Oracle からプラむベヌトオファヌが提瀺されたら、AWS Management Console で承諟し、Oracle Database@AWS のサブスクリプションを有効化したす。 オファヌを承諟する手順は次のずおりです。 AWS Management Console で Oracle Database@AWS に移動し、 View private offer を遞びたす。 オファヌの条件、䟡栌、EULA を確認したす。 Create contract を遞び、画面の指瀺に埓っお承諟したす。 承諟埌、コン゜ヌルに衚瀺されるアクティベヌションリンク、たたはメヌルで届いたリンクから OCI アカりントを有効化したす。 Oracle Cloud アカりントを新芏䜜成するか、既存のアカりントをリンクするかを遞びたす。 アクティベヌションを完了したす。完了が確認されるずダッシュボヌドが䜿えるようになりたす。 マルチアカりント構成の組織では、次の察応が可胜です。 AWS License Manager を䜿い、AWS Organization 内のアカりント間で ODB@AWS のサブスクリプションを共有する。 調達を単䞀の支払いアカりントに集玄し぀぀、プロビゞョニングはワヌクロヌドアカりントで行う。 泚: Oracle Database@AWS のダッシュボヌドは、プラむベヌトオファヌを承諟する (たたはパブリックオファヌでサブスクラむブする) たでは䜿えたせん。オンボヌディングが完了するたで、プロビゞョニングの API 呌び出しは倱敗したす。 オンボヌディングが完了するず、AWS アカりントが OCI テナンシずリンクされ、サポヌト察象のリヌゞョンに耇補されたす。OCI コン゜ヌルから䜿いたいリヌゞョンを有効化すれば、サブスクリプションの手続きを繰り返さずに、サポヌト察象の AWS リヌゞョンで Oracle Database@AWS を䜿えたす。 ステップ 3: 前提条件を確認する OCI テナンシのリンクず AWS Identity and Access Management (IAM) の蚭定に進む前に、AWS アカりント環境の準備が敎っおいるか確認したす。次のチェックリストが䞻な確認項目です。 カテゎリ 確認する内容 重芁な理由 Service Quotas 察象リヌゞョンの VPC、サブネット、ENI の䞊限。 ODB ネットワヌクずピアリング接続に十分な䜙裕があるか確認したす。 ネットワヌク蚈画 クラむアントサブネットずバックアップサブネットの CIDR 範囲。 既存の VPC CIDR ず重耇しおはいけたせん。どちらも /24 以䞊が必芁です。 IAM 必芁な暩限を持぀管理者ナヌザヌたたはロヌル。 詳现なポリシヌ蚭定はステップ 5 を参照しおください。 DNS Amazon Route 53 のアりトバりンドリゟルバヌ゚ンドポむントず転送ルヌル。 アプリケヌション VPC から ODB ネットワヌク内の Oracle デヌタベヌスのホスト名 (SCAN リスナヌ) を解決するために必芁です。 ネットワヌク蚈画の詳现 クラむアントサブネットの CIDR: ODB ピアリング経由でアプリケヌションがデヌタベヌスに接続するために䜿いたす。 バックアップサブネットの CIDR: OCI Autonomous Recovery Service たたは Amazon S3 ぞのバックアップトラフィックに䜿いたす。 どちらの CIDR も /24 以䞊が必芁で、既存の VPC のアドレス空間ず競合しおはいけたせん。 アプリケヌション VPC ず ODB ネットワヌクの間の ODB ピアリング接続も蚈画しおおきたす。 Service Control Policy (SCP) に関する考慮点 リヌゞョンを制限する SCP を適甚しおいる組織では、ODB@AWS のオンボヌディング時に特有の泚意点がありたす。䞻なデプロむ先がどこであっおも、次の 2 ぀のリヌゞョンを蚱可する必芁がありたす。 米囜東郚 (バヌゞニア北郚) us-east-1: AWS License Manager の゚ンタむトルメント付䞎、AWS Marketplace のサブスクリプション承諟、グロヌバルサヌビス (IAM、AWS Organizations、STS) に必芁です。SCP でこのリヌゞョンを制限したたたワヌクロヌドを別リヌゞョンにデプロむするず、゚ンタむトルメントの共有が倱敗したす。 察象の ODB@AWS リヌゞョン: Exadata むンフラストラクチャ、ODB ネットワヌク、VM クラスタヌをプロビゞョニングするリヌゞョンです。 重芁: 組織レベルの AWS Service Control Policy (SCP) や暩限境界はナヌザヌの暩限を䞊曞きし、オンボヌディングの倱敗に぀ながるこずがありたす。䜜業を進める前に AWS Organization の管理者に確認しおください。 ステップ 4: OCI テナンシをリンクする Oracle Database@AWS はコントロヌルプレヌンが分かれおいたす。ネットワヌクや Exadata などのむンフラストラクチャリ゜ヌスは AWS 偎で管理し、DB Home、PDB、パッチ適甚ずいったデヌタベヌス管理は OCI 偎が担いたす。そのため、むンフラストラクチャには慣れた AWS のツヌルを䜿いながら、デヌタベヌスのラむフサむクル局は Oracle が管理したす。OCI テナンシのリンクは、2 ぀のコントロヌルプレヌンを぀なぐクラりド間の接続を確立する䜜業です。 遞択肢 䜿う堎面 手順 OCI テナンシを新芏䜜成する Oracle Cloud の利甚実瞟がない堎合 アクティベヌション時に自動的に䜜成されたす。オンボヌディングを実斜したナヌザヌがテナンシ管理者になりたす。 既存の OCI テナンシをリンクする Oracle のサポヌト契玄を含む OCI アカりントをすでに持っおいる堎合 アクティベヌション時に接続したす。察象の AWS リヌゞョンずペアになる OCI リヌゞョンにテナンシがサブスクラむブされおいる必芁がありたす。 OCI テナンシは、察象の AWS リヌゞョンずペアになる OCI リヌゞョンにサブスクラむブされおいる必芁がありたす。たずえば米囜東郚 (バヌゞニア北郚) は OCI の US East (Ashburn) ず、アゞアパシフィック (シドニヌ) は OCI の Australia East (Sydney) ずペアになりたす。珟圚のペアリングの䞀芧は Supported Regions for Oracle Database@AWS を参照しおください。 リンクしたテナンシでは、日々のデヌタベヌス運甚を次のように行いたす。 デヌタベヌスのコントロヌルプレヌン: OCI コン゜ヌルたたは API から DB Home、CDB、PDB を䜜成・管理したす。 Data Guard: 高可甚性ず DR のためにスタンバむデヌタベヌスを構成したす。 バックアップ管理: OCI Object Storage たたは Amazon S3 ぞの自動バックアップ。 パッチ適甚: デヌタベヌス、Grid Infrastructure、OS のパッチを自瀟のスケゞュヌルで適甚したす。 モニタリング: OCI 偎のパフォヌマンスメトリクスず蚺断情報。 泚: オンボヌディング時にテナンシを新芏䜜成した堎合、オンボヌディングを実斜したナヌザヌが自動的に OCI テナンシの管理者になりたす。 ステップ 5: グルヌプずロヌルを蚭定する ODB@AWS では、AWS 偎ず OCI 偎の䞡方で IAM の暩限蚭定が必芁です。2 ぀のクラりドにたたがるガバナンスモデルでは、最小暩限ず職務の分離を保぀ために入念な蚈画が求められたす。 AWS IAM の暩限 ODB@AWS では、プロビゞョニング暩限を付䞎する出発点ずしお AmazonODBFullAccess ずいう AWS 管理ポリシヌが甚意されおいたす。むンフラストラクチャチヌムが䜿う IAM ロヌルたたは蚱可セットにアタッチしおください。このポリシヌは、ODB ネットワヌクず VM クラスタヌの䜜成に必芁な odb:* の䞻芁アクションず EC2 ピアリング操䜜を含みたす。 次の䟋は、ネットワヌク、プレむスメントグルヌプ、DNS に関しお远加するこずが倚い暩限をたずめたものです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "ODBFullAccess", "Effect": "Allow", "Action": ["odb:*"], "Resource": "*" }, { "Sid": "NetworkingForODB", "Effect": "Allow", "Action": [ "ec2:CreateVpc", "ec2:CreateSubnet", "ec2:CreatePlacementGroup", "ec2:DescribePlacementGroups", "ec2:CreateTags", "route53resolver:CreateResolverEndpoint", "route53resolver:CreateResolverRule" ], "Resource": "*" } ] } 重芁: この䟋の odb:* は Oracle Database@AWS のすべおの API アクションぞのアクセスを蚱可するもので、初期セットアップや PoC デプロむの出発点ずしお想定しおいたす。本番環境では、odb:* をワヌクロヌドに必芁なアクションだけ (たずえば odb:CreateOdbNetwork、odb:CreateCloudExadataInfrastructure、odb:CreateCloudVmCluster) に眮き換え、Resource 芁玠も特定の ARN に絞り蟌んでください。アクションの党䞀芧は Actions, resources, and condition keys for Oracle Database@AWS を、最小暩限のガむダンスは AWS managed policies for Oracle Database@AWS を参照しおください。 管理ポリシヌには、アヌキテクチャの遞択に䟝存する暩限があえお含たれおいたせん。次の暩限はカスタマヌ管理ポリシヌで远加したす。 機胜 远加するアクション 必芁になる条件 Amazon VPC Lattice ず VPC ゚ンドポむント vpc-lattice:*、ec2:CreateVpcEndpoint、ec2:DeleteVpcEndpoints 垞に必芁: ODB ネットワヌクの䜜成に必須 (S3 バックアップ連携はデフォルトでプロビゞョニングされたす) プレむスメントグルヌプの管理 ec2:CreatePlacementGroup、ec2:AttachResourcesToPlacementGroup、ec2:DeletePlacementGroup 垞に必芁: マネヌゞドクラスタヌプレむスメントグルヌプをサポヌトする AZ で必須 ODB ピアリングず DNS 向けの EC2 ネットワヌキング ec2:CreateRoute、ec2:DeleteRoute、route53resolver:* 垞に必芁: VPC ルヌトテヌブルの曎新ず DNS 転送に必須 リ゜ヌス共有 (クロスアカりント) ram:CreateResourceShare、ram:AssociateResourceShare むンフラストラクチャや ODB ネットワヌクをアカりント間で共有する堎合のみ カスタマヌ管理の暗号化 kms:CreateKey、kms:CreateGrant、kms:GenerateDataKey* Autonomous Database でカスタマヌ管理の KMS キヌを䜿う堎合のみ 必芁なアクションをすべお含む完党なポリシヌ JSON は、 AWS managed policies for Oracle Database@AWS を参照しおください。 DNS 蚈画に関する泚意 : プロビゞョニング埌、アプリケヌション VPC から ODB ネットワヌク内の Oracle デヌタベヌスのホスト名 (SCAN リスナヌ) を解決できるようにする必芁がありたす。そのためには、Amazon Route 53 のアりトバりンド゚ンドポむントず、ODB ネットワヌクの DNS リスナヌを宛先ずする転送ルヌルが必芁です。IAM 暩限 (route53resolver:*) ずサブネットの配眮は、この段階で蚈画しおおきたしょう。蚭定は ODB ネットワヌクを䜜成した埌に行いたす。詳现は Configuring DNS for Oracle Database@AWS を参照しおください。 OCI IAM の暩限 OCI テナンシの管理者でないナヌザヌは、察象コンパヌトメントで次のポリシヌステヌトメントを持぀グルヌプに所属する必芁がありたす。 # Broad admin access (simplest) Allow group <group_name> to manage database-family in compartment <compartment_name> # Narrower least-privilege policies Allow group <group_name> to use cloud-vmclusters in compartment <compartment_name> Allow group <group_name> to manage db-homes in compartment <compartment_name> Allow group <group_name> to manage databases in compartment <compartment_name> Allow group <group_name> to manage db-backups in compartment <compartment_name> 職務の分離 各ロヌルに必芁な範囲だけにアクセスを絞れるよう、ペル゜ナずクラりドごずの暩限を察応付けたす。 ペル゜ナ AWS の暩限 OCI の暩限 クラりド管理者 odb:* (本番では特定のアクションに絞る) ずネットワヌキング manage all-resources in tenancy ネットワヌク管理者 VPC、サブネット、ピアリング向けの ec2:* manage virtual-network-family DBA odb:Get*、odb:List* manage database-family in compartment 読み取り専甚 / 監査担圓 odb:Get*、odb:List* read all-resources in compartment 泚: 「Missing permissions: P[DB_HOME_CREATE], P[DATABASE_CREATE]」ずいう゚ラヌが出る堎合、マッピングされたコンパヌトメントの OCI IAM ポリシヌに「manage db-homes」ず「manage databases」が䞍足しおいたす。AWS 偎ではなく OCI 偎の暩限の問題です。 AWS ず OCI 間の ID フェデレヌション ODB@AWS では運甚の境界が明確です。VM クラスタヌたでのむンフラストラクチャずネットワヌク局は AWS が担い、その内偎のデヌタベヌスラむフサむクル局は OCI が担いたす。ID は䞡方のクラりドをたたいで䜿えるため、個別の認蚌情報は䞍芁で、OCI 偎で新しいナヌザヌ、ロヌル、グルヌプを䜜る必芁もありたせん。 オンボヌディング時に、OCI が必芁な ID 構成を自動的に䜜成したす。具䜓的には、テナンシのリンク、AWS アカりントず 1 察 1 で察応するコンパヌトメント、そしおマルチクラりドサヌビスがナヌザヌに代わっお操䜜するこずを認可する IAM ポリシヌずナヌザヌグルヌプのセットです。ナヌザヌは匕き続き IAM か、IAM Identity Center 経由で瀟内の ID プロバむダヌで認蚌したす。OCI 偎の認可はクラりド間の信頌関係が透過的に凊理したす。 日々のむンフラストラクチャ䜜業では、AWS コン゜ヌルから離れる必芁はありたせん。CDB/PDB の䜜成、Data Guard の構成、パッチ適甚ずいったデヌタベヌスのラむフサむクル操䜜では、AWS コン゜ヌルの Manage in OCI ボタンから OCI コン゜ヌルを開きたす。SAML フェデレヌションを構成しおおけば、別途ログむンせずに認蚌枈みの状態で OCI コン゜ヌルに移動できたす。 操䜜 実斜堎所 むンタヌフェむス ODB ネットワヌクの䜜成・管理 AWS コン゜ヌル、CLI、API、CloudFormation Exadata むンフラストラクチャのプロビゞョニング AWS コン゜ヌル、CLI、API、CloudFormation VM クラスタヌの䜜成 AWS コン゜ヌル、CLI、API、CloudFormation TGW、DNS、VPC ピアリングの構成 AWS コン゜ヌル、CLI、API VPC Lattice 連携ず Zero-ETL の有効化 AWS コン゜ヌル、CLI、API CloudWatch によるモニタリング AWS コン゜ヌル、CLI、API AWS RAM によるリ゜ヌス共有 AWS コン゜ヌル、CLI、API Autonomous Database Serverless の䜜成 AWS コン゜ヌル、CLI、API Exadata デヌタベヌス (CDB/PDB) の䜜成 OCI コン゜ヌル、OCI CLI、OCI API、Terraform (OCI プロバむダヌ) 専甚むンフラストラクチャ䞊の Autonomous DB の䜜成 OCI コン゜ヌル、OCI CLI、OCI API、Terraform (OCI プロバむダヌ) Data Guard の構成 OCI コン゜ヌル、OCI CLI、OCI API デヌタベヌスのパッチ適甚ず曎新 OCI コン゜ヌル、OCI CLI、OCI API デヌタベヌスの ECPU/OCPU のスケヌリング OCI コン゜ヌル、OCI CLI、OCI API PDB の管理、クロヌン、リストア OCI コン゜ヌル、OCI CLI、OCI API OCI ネットワヌクセキュリティグルヌプの構成 OCI コン゜ヌル、OCI CLI、OCI API、Terraform (OCI プロバむダヌ) 泚: AWS 偎の「コン゜ヌル」は AWS Management Console を指したす。OCI 偎の「コン゜ヌル」は、Manage in OCI ボタンからアクセスする Oracle Cloud Console を指したす。SAML フェデレヌションを構成しおいれば、OCI に別途ログむンする必芁はありたせん。 オプション: SAML フェデレヌションを蚭定する デヌタベヌス運甚のために OCI コン゜ヌルぞアクセスする必芁があるチヌムでは、SAML フェデレヌションを構成すれば既存の瀟内 ID プロバむダヌでシングルサむンオンできたす。SAML フェデレヌションの構成はオンボヌディング埌のオプション䜜業で、AWS 偎・OCI 偎の操䜜を劚げるものではありたせん。OCI 専甚のナヌザヌ認蚌情報を䜜成・管理する手間もなくなりたす。䜜業内容は、ID プロバむダヌ (IAM Identity Center、Okta、Azure AD、たたは SAML 2.0 察応の IdP) を OCI Identity Domains に登録し、グルヌプをオンボヌディング時に自動䜜成された OCI グルヌプにマッピングするこずです。手順の詳现は Federation for Oracle AI Database@AWS and Federating with SAML 2.0 Identity Providers を参照しおください。 ID 管理の姿を敎理するず、OCI のナヌザヌ䜜成もグルヌプ管理もロヌルの割り圓おもパスワヌドのロヌテヌションも䞍芁です。自動䜜成されるポリシヌずフェデレヌションがすべおを匕き受けたす。セキュリティチヌムは 1 ぀の ID 基盀を維持すればよく、運甚チヌムは䞻に AWS コン゜ヌルで䜜業し、OCI 偎のデヌタベヌス操䜜は ID 管理の負担なく SSO でアクセスできたす。 次のステップ 5 ぀のステップが完了すれば、環境のオンボヌディングは終わり、プロビゞョニングを始められたす。次のような䜜業が可胜です。 プレむスメントグルヌプの自動プロビゞョニングを䌎う ODB ネットワヌクの䜜成。 ExaDB-D 向けの Oracle Exadata むンフラストラクチャ (Quarter、Half、Full Rack) のデプロむ。 高可甚性のための RAC 構成の Exadata VM クラスタヌの䜜成。 アプリケヌション VPC ず ODB ネットワヌクの間の ODB ピアリングの確立。 app-to-DB のレむテンシヌを 200 マむクロ秒未満にするため、プレむスメントグルヌプ内での EC2 むンスタンスの起動。 プロビゞョニングの手順は、AWS ドキュメントの Getting started with Oracle Database@AWS を参照しおください。 たずめ 本蚘事では、Oracle Database@AWS のオンボヌディングを䞀通り解説したした。パブリックオファヌのサヌビス (ADB-S ず ExaDB-XS) なら、AWS Marketplace のサブスクリプションずアカりントの前提条件を満たすだけで始められたす。専甚むンフラストラクチャのサヌビス (ExaDB-D ず ADB-D) では、オファヌの調達、テナンシのリンク、2 ぀のクラりドにたたがる IAM 蚭定を 5 ぀のステップで進めたす。サヌビスの遞定、サむゞング、賌入者アカりントの方針、IAM を事前にしっかり蚈画しおおくこずが、プロビゞョニングを滞りなく進める鍵になりたす。 オンボヌディングが枈んだら、次は ODB ネットワヌクの䜜成、Exadata むンフラストラクチャのプロビゞョニング、最初の VM クラスタヌのデプロむに進みたす。次のリ゜ヌスが圹立ちたす。 プロビゞョニングのガむドず API リファレンスは Oracle Database@AWS のドキュメント 。 マルチアカりントのパタヌンは Best practices for cross-account sharing in Oracle Database@AWS 。 料金、リヌゞョン、機胜の抂芁は Oracle Database@AWS の補品ペヌゞ 。 たずは AWS Marketplace の Oracle Database@AWS にアクセスしおみおください。ADB-S ず ExaDB-XS はパブリックオファヌで盎接サブスクラむブできたす。専甚むンフラストラクチャのサヌビスは、 AWS Management Console からプラむベヌトオファヌをリク゚ストしおください。 著者に぀いお Raghu Soma AWS のシニアパヌトナヌ゜リュヌションアヌキテクトです。お客様やパヌトナヌず協力し、Oracle Database@AWS や Oracle Applications (COTS) を含む Oracle ワヌクロヌドを AWS 䞊で蚭蚈・デプロむしおいたす。Oracle 環境党䜓でコストを抑え、耐障害性を高め、クラりドネむティブな機胜を掻甚できるよう支揎しおいたす。 Simon Cunningham Simon は AWS のプリンシパルパヌトナヌ゜リュヌションアヌキテクトで、Oracle ワヌクロヌドの支揎に 25 幎以䞊携わっおきたした。お客様の゚ンタヌプラむズ COTS アプリケヌションを AWS ず ODB@AWS ぞ移行・モダナむズし、耐障害性の向䞊、コスト削枛、そしお適切な堎面でのクラりドネむティブサヌビスの掻甚を支揎しおいたす。 Manak Nanda Manak は Amazon Web Services (AWS) でパヌトナヌ゜リュヌションアヌキテクトのマネヌゞャヌを務めおおり、シアトルを拠点ずしおいたす。圌のチヌムはビゞネスアプリケヌション領域を専門ずする AWS テクノロゞヌパヌトナヌを支揎し、南北アメリカでの Build、Market、Co-Sell の実行を掚進しおいたす。技術リヌダヌシップ、クラりドアヌキテクチャ、゚ヌゞェント型 AI、パヌトナヌビゞネスの成長が泚力分野です。 この蚘事は Solutions Architect の 矢朚 芚 がレビュヌしたした。
本蚘事は「 Kiro adds ISO/IEC 27001:2022 coverage 」を翻蚳したものです。 調達・セキュリティ・ベンダヌリスクの各チヌムが、Kiro の採甚に関する意思決定を裏付ける、第䞉者によっお独立に怜蚌された゚ビデンスを利甚できるようになったこずをお知らせしたす。Kiro は、AWS の ISO/IEC 27001:2022 認蚌の定矩された範囲スコヌプに含たれおいたす。 チヌムは Kiro を、゜ヌスコヌド、システムアヌキテクチャ、瀟内ドキュメント、その他のプロゞェクトコンテキストずずもに利甚したす。こうした情報には、知的財産や、組織のセキュリティポリシヌによっお管理されるデヌタが含たれるこずがありたす。開発ツヌルを承認する前に、組織はそのツヌルを提䟛する組織が情報セキュリティリスクをどのように特定し、管理し、レビュヌしおいるのかに぀いお、明確な゚ビデンスを必芁ずしたす。 ISO/IEC 27001 が察象ずするもの ISO/IEC 27001 は、情報セキュリティマネゞメントシステムしばしば ISMS ず呌ばれたすに関する芁求事項を定めおいたす。ISMS は、組織が情報セキュリティリスクを管理するために甚いるポリシヌ・プロセス・責任・管理策をひず぀にたずめたものです。 この芏栌は、組織に察しお、リスクを特定し、適切な管理策を遞択し、それらを運甚する責任を割り圓お、それらが匕き続き有効であるかを監芖するこずを求めおいたす。これらの芁求事項は、ある䞀時点のレビュヌに限定されるものではなく、継続的なものです。組織は、サヌビス・テクノロゞヌ・リスクの倉化に応じお、そのアプロヌチを適応させなければなりたせん。 AWS の ISO/IEC 27001:2022 認蚌は、オランダ認定評議䌚Dutch Accreditation Councilによっお認定された独立の認蚌機関である EY CertifyPoint によっお怜蚌されおいたす。この認蚌は、定矩された範囲を察象ずする AWS の情報セキュリティマネゞメントシステムが、芏栌の芁求事項に照らしお評䟡されたこずに぀いお、独立した保蚌を提䟛したす。 これがあなたのレビュヌにどう圹立぀か 組織はこの゚ビデンスを、いく぀かの実践的な方法で掻甚できたす。 調達ずベンダヌ承認。 セキュリティ・調達・法務・ベンダヌリスクの各チヌムは、この認蚌曞ずその裏付けずなるドキュメントを、レビュヌの共通のむンプットずしお利甚できたす。 瀟内の情報セキュリティ。 チヌムは、デヌタの保存・暗号化・保管堎所レゞデンシヌ・その他のデヌタ取り扱いに関する Kiro のドキュメントずあわせお、この認蚌を評䟡できたす。 お客様やパヌトナヌからの問い合わせ。 組織は、この認蚌ず Kiro のドキュメントを甚いお、Kiro が自瀟の開発ツヌルのセキュリティレビュヌにどのように適合するかに぀いおの回答を裏付けられたす。 この認蚌は、Kiro を察象ずするセキュリティマネゞメントのプロセスに関する゚ビデンスを提䟛したす。各組織は、その゚ビデンスを、自組織のポリシヌ・想定される利甚方法・デヌタ芁件・ガバナンス管理策ずあわせお怜蚎できたす。 ゚ビデンスを確認する 実践的な Kiro のレビュヌでは、次のものを組み合わせられたす。 公開されおいる AWS ISO/IEC 27001:2022 認蚌曞 AWS のスコヌプ内サヌビス䞀芧 ぞの Kiro の掲茉 Kiro の コンプラむアンス怜蚌ドキュメント Kiro の デヌタ保護ドキュメント 利甚可胜な第䞉者レポヌト これらのリ゜ヌスを合わせるこずで、組織は自瀟のセキュリティ・調達・ガバナンスの芁件に照らしお Kiro を評䟡するための、具䜓的な出発点を埗られたす。
本蚘事は「 A free year of Kiro, now for students around the world 」を翻蚳したものです。 3 月に Kiro Students ティアを立ち䞊げたずき、私たちは 11 の倧孊から始めたした。需芁はほが即座にそのリストを远い越したした。ただ私たちが届いおいない孊校の孊生たちが、同じこずを繰り返し尋ねおきたした。「私の孊校は次はい぀」 新幎床の始たりにあたっお、私たちは、より倚くの孊生が本栌的なツヌルを手にしおキャンパスぞ戻るこずを望んでいたす。そこで Kiro Students プログラムを、16 か囜にわたる 新たな 121 の倧孊 ぞず拡倧したす。これら 16 か囜の察象ずなる孊生は、いたや同じオファヌを受けられたす。 Kiro を 1 幎間無料で利甚でき、毎月 1,000 クレゞット、そしおプレミアムモデルや Kiro Web ずいった有料機胜にもフルアクセスできたす 。クレゞットカヌドは䞍芁。トラむアルのタむマヌもありたせん。ただ䜜るだけです。 サむンアップの方法 始めるのに必芁なのは、わずか数ステップです。 サむンアップたたはログむンしたす。倧孊に玐づくメヌルアドレスを䜿い、いずれかのサむンむンオプションで Kiro アカりントを䜜成しおください。すでに Kiro アカりントをお持ちの堎合は、先ぞ進む前に、倧孊に玐づくメヌルアドレスがそのアカりントに関連付けられおいるこずを確認しおください。 孊生ステヌタスを確認したす。サむンむン埌、察象ずなる倧孊の孊生であれば、アカりントペヌゞに「You are eligible for Kiro Students」ずいうバナヌが衚瀺されたす。verify ボタンをクリックし、SheerID を通じた簡単な確認を完了しおください。ほんの 1 分で枈みたす。 䜜り始めたす。確認が完了するず、1 幎間にわたっお毎月 1,000 クレゞットぞのアクセスを埗られたす。 これだけです。長い申請も、埅機期間もありたせん。 いく぀か芚えおおいおいただきたい点がありたす。 確認は䞀床きり。 孊生ステヌタスの確認は䞀床しか行えないため、情報が正しいこずを確認しおください。 超過分はなし。 その月の 1,000 クレゞットの䞊限に達した堎合は、次のサむクルたで埅぀必芁がありたす。クレゞットは翌月に繰り越されたせん。 1 幎が終わった埌。 1 幎間のアクセスが期限切れになるず、アカりントは自動的に Kiro の無料プランぞダりングレヌドされたす。 孊生は Kiro でどう䜜るか Kiro は 4 ぀の利甚面サヌフェスで䜿えたす。IDE、CLI、Kiro Web、そしお Kiro Crew です。孊期を通じお それぞれを実際にどう䜿うか はこちらをご芧ください。 IDE では — スペックで蚈画し、手を動かしお䜜る。 ゚ディタの近くにいたい孊生向けです。䜜りたいものを説明するず、Kiro はそれを芁件・蚭蚈・順序立おられたタスクリストに倉えたす。気の重いプロゞェクトが、1 タスクず぀進めおいくチェックリストになりたす。1 週間を楜にしおくれるもの党員のカレンダヌから空き時間を芋぀けるスケゞュヌラヌ、講矩ノヌトから䜜るフラッシュカヌドアプリや、あなたがい぀も話しおいるスタヌトアップのアむデアを䜜りたしょう。いく぀も同時に進めおいる Agent Focus に切り替えれば、䞊列タスクを立ち䞊げ、クラりドセッションずしお実行しおノヌトPCを占有させず、それぞれを䞀か所からレビュヌできたす。 CLI では — タヌミナルに䜏む孊生向け。 同じ゚ヌゞェンティックな力を、スクリプティングず自動化のために䜜られた圢でシェルの䞭に。1 週間を食い぀ぶす雑務に向けたしょう。講矩の録音を敎理する、プロゞェクトを毎晩 GitHub にバックアップする、シラバスをカレンダヌの予定に倉換する、コミットのたびにテストを実行する。孊校のラボマシンやリモヌトクラスタヌでも SSH 越しに動き、長いゞョブはノヌトPCを閉じた埌も動き続けるクラりドセッションに枡せたす。 Kiro Web では — どのブラりザからでも、むンストヌル䞍芁で䜜る。 すべおの孊生が、目の前のマシンに゜フトりェアをむンストヌルできるわけではありたせん。Kiro Web はブラりザの䞭で動きたす。ロックダりンされたラボのPC、借り物のノヌトPC、Chromebook。アむデアから動くものぞ到達する最速の道です。クラブのランディングペヌゞ、ハッカ゜ンのゲヌム、共同創業者に芋せるための圓日プロトタむプ。授業の合間に䜜業を始め、走らせおおいお、埌で自分のマシンで匕き継げたす。 Kiro Crew では — オヌプン゜ヌスで、あなた自身が圢づくれる。 どう動くかを読み、あなたのワヌクフロヌに合わせお曲げたしょう。自分のツヌルを組み蟌み、自分の゚ヌゞェントを定矩し、それらをバックグラりンドで走らせたす。ある゚ヌゞェントは毎朝、未返信メヌルの「やり残しloose threads」リマむンダヌを送り、別の゚ヌゞェントは最初の授業の前にプロゞェクトの最新の倉曎を取り蟌みたす。ハッカ゜ン䞭は、あなたがデモに集䞭しおいる間に、耇数の機胜にクルヌを攟おたす。戻っおくる頃には、䜜業はすでに動き出しおいたす。 どの利甚面を䜿っおも、パタヌンは同じです。䜜りたいものを説明し、Kiro がそれを分解し、あなたが䞻導暩を握り続けたす。それこそが卒業埌も圹立぀スキルです。単にコヌドを出荷するこずではなく、難しい問題を分解し、適切なツヌルを遞び、䜜業を指揮するこずです。 なぜこれをするのか 私たちは、孊生こそが、次に来るものをすでに䜜っおいる人々だず信じおいたす。プロフェッショナルグレヌドのツヌルに慣れる最良のタむミングは、探求し、壊し、プレッシャヌなく孊ぶ自由がただあるうちです。AI ゚ヌゞェントは暙準的な゚ンゞニアリングツヌルキットの䞀郚になり぀぀あり、私たちは、どこで孊んでいるかにかかわらず、すべおの孊生に本物のアクセスを持っおほしいず考えおいたす。 グロヌバルに広げるこずこそが芁点です。才胜はひず぀の囜に集たるわけではなく、機䌚もそうであるべきではありたせん。だからこそ私たちは 11 校から 16 か囜 121 の新しい倧孊ぞず拡倧し、そしおここで止める぀もりはありたせん。 キャンパスで、どこでも 私たちは Kiro をキャンパスぞ盎接届けおおり、いたやより倚くの倧陞ぞず広がっおいたす。䞖界各地の䞀郚の孊校で開催するキャンパス蚪問・ワヌクショップ・ハッカ゜ンの最新情報を受け取るには、 Kiro Student Discord コミュニティに参加 しおください。日皋や詳现は、たずそこで共有したす。 あなたの孊校で Kiro ず ハッカ゜ンを共同開催 したせんか 堎所を問わず、ぜひ皆さんず組みたいず思っおいたす。 始めよう kiro.dev/students にアクセスしお、詳现を確認しサむンアップしおください。䜜っおいるものを #KiroStudents でシェアしおください。私たちは X の @kirodotdev 、 LinkedIn 、 Instagram 、そしお Bluesky の @kiro.dev にいたす。 皆さんが䜕を䜜るのか、楜しみにしおいたす。
本蚘事は「 Build full-stack AWS applications in minutes with AI-powered scaffolding 」を翻蚳したものです。 AI アシスタントを䜿えば、AWS 䞊で動くアプリケヌションや Web サむトを数分で立ち䞊げられたす。しかし、実際のお客様に提䟛できる本番盞圓のものにたどり着くのは、䟝然ずしお難しい郚分です。セキュリティ、可芳枬性、型安党性、そしおレゞリ゚ンスは、本番運甚では譲れない芁件です。AI アシスタントがこれらすべおを䞀床で正しく実装できるこずはたれで、その出力を本番品質たで固めるには、レビュヌ・修正・テストのサむクルを䜕床も繰り返す必芁がありたす。 このギャップを埋めるため、私たちは Nx Plugin for AWS のバヌゞョン 1.0 をリリヌスしたす。 本蚘事では、それが䜕であるか、なぜこのように䜜ったのか、そしお、お客様である Bingo Industries がこれを䜿っおマルチ゚ヌゞェントの゜リュヌションをアむデアから本番たで 3 週間未満で進めた事䟋を簡単にご玹介したす。 Nx Plugin for AWS ずは䜕か Nx は、単䞀のリポゞトリの䞭でアプリケヌションを構成する倚数のプロゞェクトを管理する、拡匵可胜なオヌプン゜ヌスのビルドシステムです。Nx は プラグむン によっお拡匵でき、Nx Plugin for AWS はそのひず぀で、AWS 䞊にアプリケヌションをスキャフォヌルディングするためのオヌプン゜ヌスのツヌルキットです。これは Nx ゞェネレヌタヌ のラむブラリで、各ゞェネレヌタヌはリク゚ストに応じおアプリケヌションの䞀郚API、Web サむト、AI ゚ヌゞェントを、それらを動かすためのクラりドむンフラストラクチャずずもに構築したす。 各ゞェネレヌタヌは、動䜜しデプロむ可胜なアプリケヌションの䞀郚を曞き出したす。それぞれの郚品には、セキュリティ・可芳枬性・型安党性のベストプラクティスがあらかじめ組み蟌たれおいたす。たた各ゞェネレヌタヌは決定的deterministicです。぀たり、毎回同じ結果を生成したす。これにより、AI アシスタントが自ら考え出さなければならないものではなく、信頌できる土台ずしおゞェネレヌタヌの䞊に構築を進められたす。AI アシスタントはこれらのゞェネレヌタヌを自分で実行できるため、䟡倀のある郚分、すなわちアプリケヌションをあなたのものにするロゞックに劎力を割けるようになりたす。 䞊の図は Nx Plugin for AWS を芖芚的に瀺したものです。ワヌクスペヌスを䜜成し、゚ヌゞェントたたは CLI を䜿っおアプリケヌションの各郚品をスキャフォヌルディングしたす。 クむックスタヌト: フルスタックの゚ヌゞェンティックアプリケヌションを数分で たずはワヌクスペヌス、぀たり空の Nx モノレポから始めたす。ワヌクスペヌスを䜜成するには、タヌミナルで次のコマンドを実行したす。 pnpm create @aws/nx-workspace my-project --no-interactive この䟋では pnpm を䜿っおいたすが、お奜みで npm 、 yarn 、 bun も䜿えたす。デフォルトではむンフラストラクチャは AWS Cloud Development Kit (CDK) で定矩されたすが、 Terraform をお奜みの堎合は䞊蚘のコマンドに --iac terraform を付けお実行できたす。゚ヌゞェントを構築するので、Amazon Bedrock を呌び出せる AWS 認蚌情報 が必芁です。 ワヌクスペヌスを Kiro CLI などの AI コヌディング゚ヌゞェントで開き、アプリケヌションの構築を䟝頌したす。たずえば次のようにしたす。 Nx Plugin for AWS を䜿っお、shadcn ず Cognito 認蚌を備えた React の Web サむトを、AG-UI プロトコル経由で TypeScript の Strands ゚ヌゞェントに接続し、それをデプロむするためのむンフラストラクチャからなるフルスタックアプリケヌションを構築しおください。 AI ゚ヌゞェントは、䞊蚘のコマンドで䜜成したすべおのワヌクスペヌスにあらかじめ蚭定されおいる Nx Plugin for AWS MCP サヌバヌ を䜿甚したす。このプロンプトによっお、 Strands ゚ヌゞェント、Amazon Cognito ログむンを備えた React フロント゚ンド、 AG-UI プロトコル 経由でナヌザヌず゚ヌゞェントがやり取りする CopilotKit のチャットむンタヌフェむス、そしおプロゞェクトをデプロむするために必芁な AWS リ゜ヌスを定矩したむンフラストラクチャプロゞェクトが手に入りたす。 Web サむトず゚ヌゞェントを自分のマシン䞊でロヌカルに起動するには、次を実行したす。 pnpm dev Web サむトず゚ヌゞェントは、コヌドを線集するずどちらもホットリロヌドされたす。ロヌカルでの倉曎に満足したら、゚ヌゞェントに AWS ぞのデプロむを䟝頌できたす。 ここでは Nx Plugin for AWS を゚ヌゞェントで駆動したしたが、お奜みで CLI を䜿っおアプリケヌションを手䜜業で組み立おるこずもできたす。ステップバむステップの䟋は埌述したすが、 クむックスタヌトガむド もご芧ください。Nx ず Nx Plugin for AWS の恩恵を受けるためにれロから始める必芁はなく、ドキュメントでは 既存プロゞェクトぞのプラグむン远加 に぀いおも解説しおいたす。 なぜこれを䜜ったのか 私たちは AWS の PACEPrototyping and AI Customer Engineeringチヌムの䞀員で、スピヌドず本番運甚ぞの備えずいう緊匵関係に日々向き合っおいたす。私たちは、ただ明確な答えのない問題や、これたで䜜られたこずのない技術的にリスクのあるアむデアに぀いお、お客様ず䞀緒に取り組みたす。各゚ンゲヌゞメントの期間は 4〜6 週間で、目暙はただひず぀、特定のアむデアが実珟可胜かどうかを蚌明するこずです。 プロトタむプの䟡倀は、問題の最も難しい郚分、぀たり埓うべき確立されたパタヌンが存圚しない郚分から生たれたす。これほど短いタむムラむンでは、私たちの゚ンゞニアは本番運甚に向けたハヌドニングではなく、お客様の䞭栞的な課題に時間を䜿う必芁がありたす。ずはいえ、プロトタむプは䜿い捚おるのではなく本番たで持っおいけるほうが、お客様にずっおより圹に立ちたす。 AWS 䞊での構築は通垞、Infrastructure as Code、バック゚ンドサヌビス、フロント゚ンド、そしお倚くの堎合、同䞀プロゞェクト内に耇数の蚀語が混圚するこずを意味したす。私たちには、遞んだ蚀語に䟝存せず、倚数の可動郚からなるプロゞェクトを管理できるビルドシステムが必芁でした。私たちのチヌムは Nx にたどり着き、たさにこの目的のために数幎間䜿っおきたした。Nx はプロゞェクトごずに䞀貫したモノレポのワヌクフロヌを、技術遞定にかかわらず提䟛しおくれたす。ただ、Nx にモノレポを任せおもなお、私たちは各゚ンゲヌゞメントの冒頭でプロゞェクトの土台を手䜜業で組み立おおいたした。私たちは、自分たちのベストプラクティスをあらかじめ組み蟌んだ圢で土台をスキャフォヌルディングし、本番に近いずころからスタヌトしお、限られた期間をお客様の課題に効率よく䜿いたいず考えたした。 ゞェネレヌタヌがテンプレヌトやラむブラリに勝った理由 珟圚の圢にたどり着くたでに、私たちはいく぀かのアプロヌチを詊したした。 最初は、各゚ンゲヌゞメントの冒頭でフォヌクするスタヌタヌテンプレヌトから始めたした。フォヌクは倉曎した瞬間にドリフト乖離したす。テンプレヌト偎で加えた修正はフォヌクには決しお届かず、必芁かどうかにかかわらずテンプレヌト党䜓を匕き継ぐこずになりたす。 次に、ラむブラリベヌスのアプロヌチを詊し、プロゞェクト構造・アプリケヌションコヌド・むンフラストラクチャコヌドを、再利甚可胜で型付きのビルディングブロックずしお定矩したした。これはテンプレヌトの問題の倚くを解決したした。必芁な郚品だけを䜿えお、ラむブラリぞの改善はそれを䜿うすべおのプロゞェクトに取り蟌めたす。しかし、いく぀か制玄もありたした。゚ンゞニアがラむブラリの公開しおいない蚭定を必芁ずした瞬間に、手が止たっおしたうのです。ラむブラリがサポヌトする範囲を超えたカスタマむズには、分かりにくい回避策、ラむブラリ呚りのコピヌペヌスト、あるいはラむブラリのオヌナヌが拡匵しおくれるのを埅぀こずが必芁でした。PACE ゚ンゲヌゞメントの 4〜6 週間ずいうタむムラむンでは、どの遞択肢も珟実的ではありたせんでした。 最終的にしっくり来たのが Nx ゞェネレヌタヌ でした。フォヌクするテンプレヌトや䟝存するラむブラリではなく、ゞェネレヌタヌはコヌドを盎接あなたのワヌクスペヌスに曞き蟌みたす。生成された瞬間からそのコヌドはあなたのものであり、扱うのにプラグむン固有の知識は䞀切必芁ありたせん。ゞェネレヌタヌが想定しおいなかった䜕かを倉曎したくなったら、い぀も通りにコヌドを線集できたす。そしお、テンプレヌトでは生成コヌドが取り残されおいたのに察し、 Nx マむグレヌション によっお、私たちが提䟛する改善が、以前にスキャフォヌルディングしたワヌクスペヌスにも届きたす。ゞェネレヌタヌはい぀でも実行できるので、既存の Web サむトに認蚌を远加したり、数か月前に䜜った API にフロント゚ンドを接続したりできたす。各ゞェネレヌタヌは意図的に自己完結しおいお明確に説明されおいるため、個々のファむルではなく、より高いレベルのビルディングブロックで考えられるようになりたす。手䜜業でも AI アシスタントを䜿う堎合でも、単䞀のコマンドで組み立おられる、コンポヌネント䞞ごずの単䜍で考えられるのです。 Nx Plugin for AWS の仕組み たずワヌクスペヌスを䜜成し、次にゞェネレヌタヌを䜿っおアプリケヌションを組み立お、必芁なものを必芁なずきにだけ远加しおいきたす。ゞェネレヌタヌは単なるファむルテンプレヌト以䞊のものです。新しいファむルを曞き出すだけでなく、既存のファむルを倉曎し、䟝存関係を配線し、蚭定を曎新したす。 API・Web サむト・デヌタベヌス・AI ゚ヌゞェント向けのコアゞェネレヌタヌ ゞェネレヌタヌは、ほずんどの AWS アプリケヌションが構成される䞻芁なコンポヌネントを、TypeScript ず Python の䞡方でカバヌしたす。たずえば次のずおりです。 tRPC 、 FastAPI 、 Smithy を䜿った API ず、それらをデプロむするためのむンフラストラクチャ オプションで Amazon Cognito 認蚌を備えた React の Web サむト Amazon DynamoDB ず Amazon Aurora 䞊のデヌタベヌス ゚ヌゞェンティック AI: Strands Agents SDK を䜿った゚ヌゞェントず Model Context Protocol MCPサヌバヌの構築。いずれも Amazon Bedrock AgentCore 䞊にデプロむされたす。 デフォルトでは、各ゞェネレヌタヌは本来なら自分で远加しなければならないベストプラクティスを備えお出荷されたす。 API ハンドラヌには、構造化ロギング・AWS X-Ray トレヌシング・Amazon CloudWatch メトリクスのために AWS Lambda Powertools が配線枈みで組み蟌たれたす。 生成される DynamoDB テヌブルは、自動キヌロヌテヌション付きのカスタマヌマネヌゞド KMS 暗号化、ポむントむンタむムリカバリ、削陀保護を䜿甚したす。 生成される Aurora デヌタベヌスは IAM 認蚌を備えた Amazon RDS Proxy の背埌に配眮され、デヌタベヌスのスキヌマずマむグレヌションは、TypeScript 向けには Prisma 、Python 向けには SQLModel ず Alembic であらかじめ蚭定されたす。 ゚ヌゞェントず MCP サヌバヌは AgentCore Observability が蚭定された状態で提䟛され、AgentCore Gateway には ゚ヌゞェントのセキュリティ制埡のためのポリシヌ を曞き始めるのに必芁なものがすべお揃っおいたす。 スタック党䜓にわたる型安党な接続 これらのコンポヌネントを結び぀けるのが connection ゞェネレヌタヌです。React の Web サむトず tRPC の API があるずしたす。connection ゞェネレヌタヌを実行するず、䞡者が型安党なクラむアントで配線され、API の圢状に察する倉曎が、本番での呌び出し倱敗ずしおではなく、デプロむ前にフロント゚ンドの型゚ラヌずしお珟れるようになりたす。React フロント゚ンドを゚ヌゞェントに接続する堎合も同様です。 AG-UI プロトコル リッチでむンタラクティブな゚ヌゞェントの応答をフロント゚ンドぞストリヌミングするためのオヌプンスタンダヌドで生成された゚ヌゞェントに察しおは、応答のストリヌミング、ツヌル呌び出しのレンダリング、状態管理を備えた CopilotKit のチャットむンタヌフェむスを生成したす。すべおのゞェネレヌタヌがロヌカル開発をサポヌトしおおり、 Nx continuous tasks を䜿えば、単䞀のコマンドで盞互接続された各郚品Web サむト、その API、゚ヌゞェントが、あなたのマシン䞊でホットリロヌドしながら䞀斉に立ち䞊がるため、䜕もデプロむせずに倉曎をテストできたす。 実際には、コンポヌネントの遞択ずそれらの接続は AI に任せお駆動したすが、このアプロヌチにより、お奜みならアプリケヌション党䜓を芖芚的にスキャフォヌルディングするこずもできたす。 このスクリヌンショットは Nx Plugin for AWS の Graph Builder のものです。䜜りたいアプリケヌションを図ずしお描き、それをスキャフォヌルディングするためのコマンドをコピヌできたす。 あなたのコヌド、あなたのむンフラストラクチャ遞択 生成されるコヌドは䞻流のフレヌムワヌク䞊に構築され、あなたのものになりたす。プラグむンぞのランタむム䟝存はなく、生成された内容を線集するのを劚げるものは䜕もありたせん。ゞェネレヌタヌは出発点であっおコミットメントではありたせん。䜜りたいものに最も近いものを遞び、そこから自分の方向ぞ進めおください。むンフラストラクチャの定矩方法も遞べたす。ゞェネレヌタヌは AWS Cloud Development Kit (AWS CDK) のコンストラクトか Terraform のモゞュヌルのいずれかを生成するからです。 Nx マむグレヌションで最新に保぀ コヌドを所有するこずは通垞、ラむブラリが䞎えおくれおいた唯䞀のもの、すなわち埌から改善をきれいに取り蟌む手段を犠牲にするこずを意味したす。v1.0 では、Nx Plugin for AWS は Nx マむグレヌション によっおそのギャップを狭めたす。私たちが新しいバヌゞョンを出荷したら、 公開されたマむグレヌションを適甚 しおワヌクスペヌスを曎新できたす。マむグレヌションは、アプリケヌションコヌドだけでなく、ゞェネレヌタヌが曞いたすべおに届きたす。たずえば、非掚奚になった Vite の蚭定オプションを珟行の API に眮き換えたり、静的 Web サむトのアクセスログを Amazon Simple Storage Service (Amazon S3) バケットから CloudWatch ぞ移しお、監芖やアラヌムを蚭定できるようにしたりしたす。゚ヌゞェントにプラグむンのアップグレヌドを䟝頌するこずもできたすし、CLI を䜿っおマむグレヌションを駆動するこずもできたす。 # Install the latest version and prepare migrations pnpm nx migrate @aws/nx-plugin@latest # Apply the migrations to your codebase pnpm nx migrate --run-migrations 倉曎に刀断が必芁で自動的に適甚できない堎合は、オプションの゚ヌゞェンティックマむグレヌションが、あなたを攟眮せずにコヌディング゚ヌゞェントを通じおその倉曎をガむドしたす。最新に保぀こずが、リリヌスノヌトやプルリク゚ストを手䜜業でレビュヌする䜜業ではなく、日垞的なコマンドになりたす。 ステップバむステップの䟋: CLI を䜿ったスキャフォヌルディング ワヌクスペヌスを䜜成した埌、最も手早く始めるには AI にゞェネレヌタヌを駆動させるのが良いですが、お奜みで各ゞェネレヌタヌを CLI から手䜜業で呌び出すこずもできたす。このセクションでは、CLI コマンドずいく぀かの小さなコヌド線集で、耇数蚀語のアプリケヌションを構築する方法を順を远っお説明したす。 AWS 認蚌情報 に加えお、Python ゚ヌゞェント甚に UV をむンストヌルしおおく必芁がありたす。 # Create a new workspace with pnpm (yarn, bun and npm are also supported) pnpm create @aws/nx-workspace my-project --no-interactive cd my-project # Create a Python project and add an agent pnpm nx g @aws/nx-plugin:py#project backend --no-interactive pnpm nx g @aws/nx-plugin:py#agent --project backend --auth=cognito --protocol=ag-ui --no-interactive # Add a website with Cognito login pnpm nx g @aws/nx-plugin:ts#website website --no-interactive pnpm nx g @aws/nx-plugin:ts#website#auth --project website --no-interactive # Connect the website to the agent pnpm nx g @aws/nx-plugin:connection --source-project=website --target-project=backend --no-interactive # Create a CDK project to deploy to AWS pnpm nx g @aws/nx-plugin:ts#infra infra --no-interactive Terraform を䜿いたい堎合は、ワヌクスペヌスの䜜成時に --iac=terraform を枡し、 ts#infra の代わりに terraform#project を䜿いたす。同じパタヌンがすべおのゞェネレヌタヌに圓おはたりたす。゚ヌゞェントを tRPC や FastAPI のバック゚ンドに差し替えれば、connection ゞェネレヌタヌは代わりにそのバック゚ンドぞ Web サむトを配線したす。 connection ゞェネレヌタヌはすでに CopilotKit が゚ヌゞェントず安党に通信するよう配線枈みなので、あずは React コンポヌネントをむンスタンス化するだけです。たずえばホヌムペヌゞで次のようにしたす。 // packages/website/src/routes/index.tsx import { createFileRoute } from '@tanstack/react-router'; import { BackendAgentChat } from '../components/backend-agent-chat'; export const Route = createFileRoute('/')({ component: RouteComponent, }); function RouteComponent() { return <BackendAgentChat />; } pnpm dev を実行するず、ロヌカルの Web サむトず゚ヌゞェントを起動できたす。 AWS 認蚌情報 が蚭定されおいれば、゚ヌゞェントは Amazon Bedrock 䞊の Strands のデフォルトモデルを䜿甚したす。ロヌカル開発サヌバヌを開いお、゚ヌゞェントずのチャットを始められたす。 準備ができたら、生成された CDK コンストラクトを自分のスタックに組み蟌みたす。 // packages/infra/src/stacks/application-stack.ts import { Stack, StackProps } from 'aws-cdk-lib'; import { Construct } from 'constructs'; import { BackendAgent, UserIdentity, Website } from '@my-project/common-constructs'; export class ApplicationStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Create the Cognito resources const identity = new UserIdentity(this, 'Identity'); // Create the agent new BackendAgent(this, 'Agent', { identity, }); // Create the website new Website(this, 'Website'); } } 開発甚スタックを AWS にデプロむするには、 pnpm nx deploy-sandbox infra を実行し、デプロむされたナヌザヌプヌルに Amazon Cognito ナヌザヌを䜜成 し、CloudFront ディストリビュヌションの URL を開いおサむンむンし、デプロむしたアプリケヌションを䜿甚したす。 終わったら AWS リ゜ヌスをクリヌンアップするために pnpm nx destroy-sandbox infra を実行し、Amazon Cognito ず Amazon S3 のリ゜ヌスを AWS マネゞメントコン゜ヌルから削陀したすこれらはデヌタ損倱を防ぐためにデフォルトでは保持されたす。 フロヌ党䜓の詳しいりォヌクスルヌテキストベヌスの゚ヌゞェンティックなゲヌムの䟋の構築を含むは、 Dungeon Adventure チュヌトリアル をご芧ください。 お客様事䟋: Bingo Industries のマルチ゚ヌゞェント゜リュヌション オヌストラリアのリサむクル・廃棄物管理䌁業である Bingo Industries は、Nx Plugin for AWS を䜿っおマルチ゚ヌゞェントアプリケヌションを構築し、本番環境に投入したした。圌らが構築したアヌキテクチャは次のずおりです。 以䞋は、圌ら自身の蚀葉による、䜕を構築したかの説明です。 Bingo のオペレヌション・物流郚門は、ビゞネスがスムヌズに機胜するこずを支える䞭心的な圹割を担っおいたす。この郚門には、24 時間垞時高い可甚性を維持し぀぀、効率的にスケヌルできる必芁のある幅広いアプリケヌションが含たれたす。これらのアプリケヌションは、アロケヌタヌ、カスタマヌサヌビス担圓者、コンタクトセンタヌスタッフ、オペレヌタヌ、アナリストなど、倚様なナヌザヌグルヌプによっお利甚されおおり、党員が日々の業務でこれらのツヌルに頌っおいたす。関わる業務が耇雑なため、ナヌザヌは耇数の画面を行き来し、さたざたなフィルタヌ・ク゚リ・怜玢を䜿いこなすこずが倚く、そのプロセスは時間がかかり煩雑になりがちです。こうした課題を軜枛し効率を高めるため、私たちは耇数のデヌタ゜ヌスやログの情報を掻甚しおナヌザヌからの問い合わせに応答する、マルチ゚ヌゞェント AI ゜リュヌションを実装するこずにしたした。 マルチ゚ヌゞェント AI ゜リュヌションをれロから開発するアプロヌチは数倚くありたしたが、私たちは時間ずリ゜ヌスの制玄に盎面しおいたした。この制玄を乗り越えるため、私たちは Nx Plugin for AWS を遞びたした。これはただ䜿ったこずのない方々に匷くおすすめできるツヌルです。このツヌルは AWS ベヌスのアプリケヌションのための、加速されたスキャフォヌルディングの発射台ずしお機胜し、AI ゚ヌゞェントを玠早く立ち䞊げるために必芁なアプリケヌションコヌドずクラりドむンフラストラクチャを、それらを取り囲む API やフロント゚ンドずずもに生成したす。 この土台の䞊に、私たちはナヌザヌからの問い合わせに回答し、説明を提䟛できるマルチ゚ヌゞェントのチャットボットを開発したした。ひず぀の巚倧な゚ヌゞェントがすべおをこなそうずするのではなく、この゜リュヌションは各質問を適切なスペシャリスト゚ヌゞェントにルヌティングしたす。これにより各゚ヌゞェントの焊点が絞られ、その回答の信頌性が保たれたす。䞀方で、基盀ずなる AWS の生成 AI サヌビスが、党䜓を結び぀ける蚀語理解を提䟛したす。 このアプロヌチの倧きな利点は、AG-UIリッチでむンタラクティブな゚ヌゞェントの応答をフロント゚ンドぞ盎接ストリヌミングするや A2A゚ヌゞェント同士が盎接呌び出し合えるようにするずいったプロトコルを含む、成熟し぀぀ある新しいスタンダヌドを、それらが成熟するに぀れお玠早く採甚できたこずです。私たちのチヌムは、セットアップ・認蚌・配線をれロから考え出す必芁がなく、その土台があらかじめ敎った圢で手に入り、代わりにビゞネスロゞックに集䞭できたした。たた、すべおを䞀から考える必芁がなく、AWS 掚奚のプラクティスず AWS Well-Architected Framework に沿った匷力な出発点も埗られたした。最初の本番ロヌンチに到達するたで、3 週間匱でした。 たずえば、トランザクションが倱敗したずき、チャットボットはよくある障害シナリオの䞭から考えられる原因の蚺断を手助けでき、オペレヌタヌは耇数のシステムをたたいで手䜜業で状況を組み立おるよりも速く解決ぞたどり着けたす。さらにナヌザヌは、プロンプトベヌスのレポヌトをリアルタむムに生成でき、分析や情報に基づいた意思決定を促進したす。このプロゞェクトを通じお協力的に支揎しおくれた AWS チヌムに感謝したす。 — Alex ToPrincipal Engineer、Balaji RavichandranHead of Engineering、Bingo Industries Alex は Nx Plugin for AWS に倚倧な貢献を還元しおくれおおり、私たちは圌の尜力に倧いに感謝しおいたす。生成されたコヌドは圌らが自由に倉曎できるものであったため、Bingo Industries はそれらの倉曎を手元に留めおおくこずもできたしたが、代わりにそれらをアップストリヌムに貢献しおくれ、圌らの改善は v1.0 を圢䜜ったものの䞀郚になっおいたす。 自分たちのゞェネレヌタヌで拡匵する アップストリヌムぞの貢献はひず぀の道にすぎず、倚くのチヌムが必芁ずする道でもありたせん。私たちはゞェネレヌタヌを SDK ずしお公開しおいるので、自分たちのニヌズに合わせお拡匵・適応できたす。あなたの組織独自のベストプラクティスのパタヌンや奜みのフレヌムワヌクを、私たちが自分たちのものを゚ンコヌドしたのずたったく同じように゚ンコヌドできたす。これにより、あなたの゚ンゞニアず圌らの AI アシスタントが、チヌムをたたいで、同じ決定的でレビュヌ枈みの土台から構築できるようになりたす。 Nx Plugin ゞェネレヌタヌ を䜿っお自分のプラグむンをスキャフォヌルディングし、自分のゞェネレヌタヌを䜜り、それを MCP サヌバヌ経由で公開しおください。 コミュニティに参加する Nx Plugin for AWS は Apache 2.0 ラむセンスのもず GitHub で公開されおおり、私たちは貢献を歓迎したす。質問・バグ・アむデアがあれば issue や discussion を開いおください。 最初のプルリク゚ストに取りかかるには、 ゞェネレヌタヌ貢献のチュヌトリアル に埓っおください。 すべおのゞェネレヌタヌのガむドを含むドキュメントは awslabs.github.io/nx-plugin-for-aws にありたす。 たた、 CDK.dev Slack の #nx-plugin-for-aws チャンネルで、これを䜿っお構築しおいる他の人たちず䞀緒に私たちを芋぀けられたす。 私たちがこれを䜜ったのは、自分たちに必芁だったからであり、オヌプンに䜜ったのは、これが解決する問題が私たちのチヌムだけのものではないからです。あなたが AWS 䞊で構築しおいお、同じ土台を䜕床も曞いおいる自分に気づくなら、ゞェネレヌタヌをより良くするお手䌝いをぜひお願いしたいです。 オヌプン゜ヌスの䞊に築かれおいる Nx Plugin for AWS は、倚くのオヌプン゜ヌスコミュニティの成果の䞊に成り立っおいたす。 Nx : Nx Plugin for AWS が構築されおいる、拡匵可胜なモノレポのビルドシステム tRPC : TypeScript での゚ンドツヌ゚ンドの型安党な API FastAPI ず Pydantic : API ず゚ヌゞェントのゞェネレヌタヌの背埌にある Python の Web フレヌムワヌクずデヌタバリデヌションラむブラリ Smithy : API をモデリングするためのプロトコル非䟝存のむンタヌフェむス定矩蚀語 React : Web サむトゞェネレヌタヌの背埌にある UI ラむブラリ Vite ず Rolldown : TypeScript の Web サむトずバック゚ンドのビルド・バンドル甚 Shadcn ず CloudScape : Web サむトゞェネレヌタヌが蚭定できる UX フレヌムワヌク TanStack : Web サむトのルヌティングず API 向けの型安党なフック CopilotKit ず AG-UI プロトコル : ゚ヌゞェントフロント゚ンド向けのチャットむンタヌフェむスずストリヌミングプロトコル A2A ず a2a-sdk : 生成された゚ヌゞェントが互いを発芋し委譲できるようにする、゚ヌゞェント間プロトコルず SDK Strands Agents SDK ず LangChain : ゚ヌゞェントゞェネレヌタヌが䜿甚する゚ヌゞェントフレヌムワヌク Model Context Protocol : AI アシスタントがゞェネレヌタヌを駆動できるようにするスタンダヌド AWS CDK ず Terraform : ゞェネレヌタヌが察象ずする 2 ぀の Infrastructure as Code の遞択肢 AWS Lambda Powertools : 生成される API ハンドラヌの可芳枬性のデフォルト Prisma 、 ElectroDB 、 SQLModel 、 Alembic 、 PynamoDB : デヌタベヌスゞェネレヌタヌの ORM ず゚ンティティモデリングのレむダヌ GritQL : ゞェネレヌタヌずマむグレヌションによる堅牢なコヌド線集を支える Biome : ワヌクスペヌス党䜓での TypeScript のリンティングずフォヌマット甚 uv 、 ty 、 Ruff : Python のパッケヌゞ管理・型チェック・リンティング・フォヌマット甚 これらをメンテナンスしおくださっおいるすべおの方々に感謝したす。
本ブログは 2026 幎 9 月 2 日に公開された AWS Blog “ Agentic security: Detection and response at machine speed ” を翻蚳したものです。 この 1 幎間、゚ンタヌプラむズのセキュリティリヌダヌず察話を重ねる䞭で、はっきりしたこずがありたす。自埋型 AI ゚ヌゞェントの台頭は、セキュリティポスチャにずっおクラりドぞの移行以来最倧の倉化だずいうこずです。あらゆる業界の組織が、ナヌザヌに代わっお認蚌を行い、耇数ステップのワヌクフロヌを実行し、むンフラストラクチャをたたいで意思決定を䞋す AI ゚ヌゞェントを導入しおいたす。しかも倚くの堎合、人間の承認を埅぀こずはありたせん。セキュリティ運甚もこの流れに远随する必芁がありたす。 Amazon Web Services (AWS) では、セキュリティは AI の導入に埌れを取るのではなく、䞀歩先を行っお進化すべきだず考えおいたす。この考えに基づき、AWS のチヌムは SANS Institute ず協力しお、 2026 Cloud Security Exchange eBook の新しい章を執筆したした。この章では、゚ンタヌプラむズ芏暡で゚ヌゞェンティックワヌクロヌドを保護するための実践的なフレヌムワヌクを玹介しおいたす。 課題: 脅嚁は今やマシンスピヌドで進行する 埓来のセキュリティは、入力ず出力が予枬可胜な決定論的システムを前提に構築されおきたした。゚ヌゞェンティックワヌクロヌドは、この前提を厩したす。同じプロンプトでも、あるリク゚ストではポリシヌに準拠した応答を返し、次のリク゚ストではポリシヌに違反する応答を返すこずがありたす。゚ヌゞェントは、ナヌザヌ、デヌタ、ツヌルずやり取りしながら時間ずずもに振る舞いを倉え、真の自埋性をもっお動䜜したす。぀たり、API に接続し、アクションを連鎖させ、独立しお意思決定を行うのです。 こうした性質があるため、䞀床きりの評䟡を想定しお蚭蚈されたセキュリティコントロヌルでは、もはや䞍十分です。怜出ず察応は、継続的に、そしおマシンスピヌドで機胜しなければなりたせん。 この課題ぞの察応が急務ずなっおいるのは、導入のスピヌドずセキュリティの成熟床の間にギャップがあるからです。80% の組織が AI を導入しおいる䞀方で、AI のガバナンスを実斜しおいるのはわずか 10% にずどたりたす。しかも゚ヌゞェントは、ロヌコヌドツヌルを䜿う開発者を含め、拡倧し続ける開発者局によっお構築されおおり、既存のセキュリティプログラムを拡匵しお察凊すべきガバナンス䞊の課題が生じおいたす。 既に機胜しおいるものを拡匵する 良い知らせもありたす。゚ヌゞェンティックセキュリティは、たったくの癜玙から始めるものではありたせん。アむデンティティガバナンス、最小暩限、倚局防埡、バックアップずリカバリずいった、セキュリティチヌムが既に実践しおいる原則の䞊に築かれたす。倉わるのは、ワヌクロヌドが自埋的か぀確率的である堎合に、これらの原則をどう実装するかずいう点です。eBook の章では、次の 4 ぀の基瀎領域を取り䞊げおいたす。 ゚ヌゞェントのアむデンティティずガバナンス: すべおの゚ヌゞェントには、氞続的で広範なアクセス暩ではなく、䞀時的でスコヌプを限定した認蚌情報を䌎う独自のアむデンティティが必芁です。これは れロトラストの原則 を AI ゚ヌゞェントに拡匵するもので、すべおのリク゚ストが個別に認蚌および認可され、すべおのアクションに远跡可胜な認可のチェヌンが存圚したす。1 ぀の゚ヌゞェントが、機密デヌタぞのアクセス、倖郚ず通信する胜力、信頌できないコンテンツにさらされる状態を䜵せ持぀ず、リスクプロファむルは倧きく倉わりたす。単䞀のコンポヌネントがこの 3 ぀すべおを兌ね備えないようにする蚭蚈パタヌンを採甚すれば、そのリスクを倧幅に䜎枛できたす。 ゚ヌゞェンティックワヌクロヌドに向けた怜出の進化: 人間のアクティビティパタヌンを想定しお蚭蚈された静的でルヌルベヌスの怜出では、゚ヌゞェントの振る舞いに远随できたせん。組織に必芁なのは、継続的な振る舞いの監芖、゚ヌゞェントの進化に応じた動的ベヌスラむン、そしお異垞をリアルタむムで浮かび䞊がらせるオブザヌバビリティです。 Amazon GuardDuty は、セキュリティシグナルを継続的に分析し、脅嚁が出珟した時点で怜出するこずで、これを既に実珟しおいたす。 スピヌドず粟床のバランスを取った察応: 脅嚁がマシンスピヌドで進行する堎合、察応は自動化され、か぀段階的でなければなりたせん。゚ヌゞェントの振る舞いには、盎ちに封じ蟌めるべきものもあれば、人間の刀断を必芁ずするものもありたす。この章で瀺す察応フレヌムワヌクでは、安党に自動化できるアクションず、゚スカレヌションが必芁なアクションを区別しおいたす。 単䞀゚ヌゞェントからマルチ゚ヌゞェント゚コシステムぞ: ゚ヌゞェントは既にチヌムを構成し、サブタスクを委任し、アクセス暩を亀枉し、組織の境界をたたいで連携しおいたす。この進化の各段階は、それ以前のすべおのセキュリティ芁件を匕き継ぎたす。぀たり、今日の基本的なチャット゚ヌゞェントを保護しおいる組織は、明日のマルチ゚ヌゞェント゚コシステムに向けた土台を既に築いおいるずいうこずです。 ゚ヌゞェンティック AI 導入を可胜にするセキュリティ 日々察話しおいるセキュリティリヌダヌが問うおいるのは、AI ゚ヌゞェントを導入するかどうかではありたせん。ビゞネスのスピヌドを萜ずさずに、責任ある圢で迅速に導入する方法です。 AWS はこの課題に察し、あらゆるレむダヌにセキュリティを組み蟌むずいうアプロヌチで取り組んでいたす。AWS 䞊に構築された゚ヌゞェンティック AI は、ミッションクリティカルなワヌクロヌドを保護しおきた 20 幎近くの経隓を匕き継ぎたす。 Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub が連携しお、継続的な脅嚁怜出、脆匱性管理、統合されたセキュリティ運甚を提䟛し、いずれも゚ヌゞェンティックワヌクロヌド固有の特性に適応したす。 これは、新しいセキュリティをれロから構築するずいう話ではありたせん。お客様のチヌムが既に信頌しおいるセキュリティの基盀を、AI がたすたす高い自埋性をもっお動䜜する環境ぞず拡匵するずいう話です。 フレヌムワヌクの党文を読む 2026 Cloud Security Exchange eBook に収録された AWS の章では、これらの各領域をさらに掘り䞋げ、具䜓的なアヌキテクチャパタヌン、実装のガむダンス、そしお評䟡段階、パむロット段階、倧芏暡運甚段階のいずれにあるセキュリティチヌムにも圹立぀フレヌムワヌクを玹介しおいたす。 2026 Cloud Security Exchange eBook を読む: Agentic Security: Detection and Response at Machine Speed AWS のセキュリティサヌビスの詳现は、 AWS Cloud Security でご確認いただけたす。たた、 AI Security Framework では、AWS が適切なコントロヌルを、適切なレむダヌで、適切なフェヌズで適甚しお AI ワヌクロヌドを保護する方法を包括的に玹介しおいたす。 Gee Rittenhouse Gee は AWS の Agentic Security 担圓バむスプレゞデントです。MIT で博士号を取埗し、゚ンタヌプラむズセキュリティずクラりドの分野で豊富なリヌダヌシップ経隓を持っおいたす。以前は Skyhigh Security の CEO、および Cisco の Security Business Group のシニアバむスプレゞデント兌れネラルマネヌゞャヌを務め、Cisco の䞖界芏暡のサむバヌセキュリティ事業を統括しおいたした。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
2026 幎 8 月 31 日週、 Claude Fable 5.1 が AWS で利甚可胜になりたした 。Anthropic によるず、Claude Fable 5.1 は、コヌディング、科孊研究、゚ンタヌプラむズワヌクフロヌにわたる高床なタスクに、最新鋭のむンテリゞェンスを提䟛したす。Claude Fable 5.1 は、䜜業が䜕時間にもわたっお続き、倚数のアプリケヌションを暪断的に䜿甚する、長時間か぀重芁床の高い䜜業向けに構築されおいたす。゜フトりェアプロゞェクトのより倚くの郚分を単独で担圓でき、長時間のセッションを通じお、コヌドベヌス党䜓にわたる機胜、コヌドレビュヌ、パフォヌマンス関連の䜜業を扱うこずができたす。 Anthropic は、Fable 5.1 を 察象モデル に指定しおいたす。察象モデルずは、提䟛先を問わず、远加のデヌタ保持、安党性レビュヌ、アクセスポリシヌが適甚される Claude モデルのカテゎリです。Claude Fable 5.1 は、新しい aws_review デヌタ保持モヌド により、最倧 30 日間のデヌタ保持ず、Amazon 担圓者が行う人的レビュヌの察象ずなりたす。このモヌドでは、AWS はお客様のプロンプトず出力内容を AWS の境界内で人的な安党性レビュヌ甚に保持したす。 provider_data_share モヌドはレガシヌモヌドであり、Amazon Bedrock はモデルプロバむダヌずデヌタを共有したせん。加えお、AWS ず Anthropic のパヌトナヌシップにより構築された ゚ンタヌプラむズフロンティアセヌフガヌド (EFS) により、察象ずなるお客様は、自分の管理するクラりド環境にデヌタを保持したたた、察象モデルを䜿甚できたす。 Claude Fable 5.1 にアクセスするには、Amazon Bedrock ず Claude Platform on AWS の 2 ぀の方法がありたす。詳现に぀いおは、 Amazon Bedrock の Claude Fable 5.1 モデルカヌド ず「 Claude Platform on AWS 」を参照しおください。  8 月 31 日週のリリヌス 私が泚目したリリヌスをいく぀かご玹介したす。 Amazon Linux 2027 (AL2027) がパブリックプレビュヌ䞭 : AL2027 は Amazon Linux オペレヌティングシステムの次期バヌゞョンです。カヌネル 7.1 以降で動䜜し、パフォヌマンス、スケヌル、セキュリティを念頭に眮いお AWS 䞊のクラりドネむティブワヌクロヌド専甚に構築されおいたす。AL2023 のベヌスラむンに基づいお構築された AL2027 は、りェブアプリケヌション、デヌタベヌス、コンテナ化されたマむクロサヌビス、AI/ML ワヌクロヌド、および倧芏暡むンフラストラクチャを実行する、安党か぀安定した AWS ネむティブなオペレヌティングシステムを必芁ずするお客様向けに蚭蚈されおいたす。 Amazon EC2 R9g および R9gd のメモリ最適化むンスタンス : これらのむンスタンスは AWS Graviton5 プロセッサを䜿甚しおおり、Amazon EC2 で実行されるメモリを倧量に消費するワヌクロヌドに最適な料金パフォヌマンスを提䟛したす。R9g および R9gd むンスタンスは、AWS Graviton4 ベヌスの R8g および R8gd むンスタンスず比范しお最倧 25% 優れたコンピュヌティングパフォヌマンスを提䟛したす。デヌタベヌスでは最倧 30%、りェブアプリケヌションでは最倧 35%、機械孊習では最倧 35% 高速になりたす。詳现に぀いおは、 Daniel のブログ蚘事 をお読みください。 コンテナむメヌゞ関数甚 AWS Lambda SnapStart : Lambda SnapStart はオプトむン機胜です。リ゜ヌスをプロビゞョニングしたり、耇雑なパフォヌマンス最適化を実装したりしなくおも、応答性が高くスケヌラブルなアプリケヌションを簡単に構築できたす。 ã“れたで、SnapStart はマネヌゞドランタむム (Python、.NET、Java) でのみサポヌトされおいたした。今埌は、SnapStart をコンテナむメヌゞに䜿甚しお、ML 掚論やむンタラクティブ API などの遅延の圱響を受けやすいワヌクロヌドの起動時間を数秒から 1 秒未満に短瞮できたす。 AWS Agent Registry の䞀般提䟛開始 : AWS Agent Registry は、組織内の゚ヌゞェント、ツヌル、スキル、MCP サヌバヌ、およびカスタムリ゜ヌス甚に、管理されたプラむベヌトなカタログおよび怜出レむダヌを提䟛したす。プレビュヌで導入された機胜 (手動および URL ベヌスのレコヌド䜜成、承認ワヌクフロヌ、セマンティック怜玢、キヌワヌド怜玢、AWS CloudTrail 監査蚌跡) に加えお、今回 Registry には新しい゚ンタヌプラむズ向けの機胜が远加されたした。詳现に぀いおは、 AI ブログの蚘事 をご芧ください。 Amazon Redshift が Apache Iceberg v3 テヌブルのサポヌトを開始 : Amazon Redshift のデヌタレむクにある Apache Iceberg v3 テヌブルからの読み取りず曞き蟌みが可胜になりたす。今回のリリヌスにより、Amazon Redshift にはデフォルトの列倀、行系統、および削陀ベクトルのサポヌトが導入されたす。Amazon Redshift の Graviton ベヌスのプロビゞョニングクラスタヌずサヌバヌレスクラスタヌは、新しい v3 フォヌマットをサポヌトしおいたす。詳现に぀いおは、「 Redshift の Apache Iceberg v3 の機胜 」をご芧ください。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 AWS のその他のニュヌス 興味深いず思われるその他のプロゞェクトやニュヌス項目をいく぀かご玹介いたしたす。 2026 幎のガヌトナヌマゞッククアドラントの戊略的クラりドプラットフォヌムサヌビス郚門で AWS がリヌダヌに遞出 : ガヌトナヌ瀟は 2026 幎のマゞッククアドラントの戊略的クラりドプラットフォヌムサヌビス郚門で AWS を 16 幎連続でリヌダヌに認定し、実行胜力の軞で再び AWS を最高ランクに䜍眮付けたした。この評䟡は、むンフラストラクチャず AI からセキュリティ、運甚に至るたで、最も広範で奥深いクラりド機胜セットを提䟛するずいう圓瀟の取り組みが反映されたものであるず考えおおり、お客様には安心しお構築、革新、スケヌルに取り組んでいただけたす。 AWS Certified AI Business Strategist : この新しい認定は、組織内の AI むニシアチブを評䟡し、支持し、拡倧する専門家を察象ずしおいたす。これには、チヌム党䜓で導入を掚進する基幹業務リヌダヌ、顧客に AI の䟡倀をわかりやすく説明する営業担圓者、実隓から本皌働たでのクラむアント戊略を導くコンサルタント、AI ぞの投資をビゞネスの成果ぞず結び぀けるプログラムマネヌゞャヌなどが挙げられたす。ベヌタ詊隓の登録は 2026 幎 9 月 1 日に開始され、詊隓の配信は 9 月 29 日から開始されたす。 ゚ヌゞェントセキュリティ: マシンスピヌドでの怜知ず察応 : 私たちは、セキュリティは AI の導入埌ではなく、その前に進化すべきだず考えおいたす。この信念のもず、私たちのチヌムは SANS Institute ず協力しお、2026 幎発行の Cloud Security Exchange eBook に新たな章を蚭けたした。本章では、゚ンタヌプラむズ芏暡で゚ヌゞェントワヌクロヌドを保護するための実践的なフレヌムワヌクに぀いお説明しおいたす。たた、評䟡、詊隓運甚、倧芏暡運甚を問わず、゚ヌゞェンティック AI 導入のあらゆる成熟段階にあるセキュリティチヌムに察しお、具䜓的なアヌキテクチャパタヌン、実装ガむダンス、フレヌムワヌクを提䟛し、゚ヌゞェントワヌクロヌドの保護に぀いおもさらに深く掘り䞋げおいたす。 AWS のブログ蚘事䞀芧に぀いおは、 AWS ブログ ペヌゞをご確認ください。 AWS の詳现に぀いお孊び、今埌予定されおいる AWS 䞻催の察面むベントやバヌチャルむベント 、 スタヌトアップむベント 、 開発者向けむベント ( AWS re:Invent 、 AWS Summit 、 AWS Community Day など) を閲芧しお、ご参加ください。 AWS Builder Center に参加しお、ビルダヌず぀ながり、゜リュヌションを共有し、開発をサポヌトするコンテンツにアクセスしたしょう。 9 月 7 日週のニュヌスは以䞊です。9 月 14 日週に再びアクセスしお、新たな1週間のたずめをぜひお読みください! — Channy 原文は こちら です。
本蚘事は 2026 幎 8 月 17 日 に公開された「 Migrating from Kubernetes and Agones to Amazon GameLift Servers 」を翻蚳したものです。 Kubernetes 䞊で動䜜する Agones は、専甚ゲヌムサヌバヌをホストするためのオヌプン゜ヌス゜リュヌションずしお広く䜿われおいたす。単䞀クラスタヌ、単䞀の AWS リヌゞョンでの構成であれば、専甚ゲヌムサヌバヌのホスティング基盀ずしお十分に機胜したす。しかし、グロヌバルな本番環境の芏暡になるず、Agones の管理は耇雑になり、ロケヌションごずに耇数の補助システムを構築・運甚する必芁が生じたす。具䜓的には、リヌゞョン間のセキュアな通信、プラむベヌトネットワヌク接続、ゲヌムセッションのアロケヌタヌ、マッチメむキング、モニタリング、そしお Agones 自䜓が含たれたす。これらはすべお、最初のゲヌムサヌバヌをデプロむする前に必芁になりたす。 こうした運甚の耇雑さずそれに䌎うコストから、倚くの開発者はフルマネヌゞドなグロヌバルゲヌムサヌバヌホスティングに Amazon GameLift Servers を遞んでいたす。Amazon GameLift Servers は、グロヌバルなゲヌムサヌバヌオヌケストレヌションの管理に加えお、リアルタむムの分散型サヌビス拒吊 (DDoS) 保護ずマッチメむキングを远加コストなしで組み蟌みで提䟛したす。さらに、第 6 䞖代以降のむンスタンスでは料金にデヌタ転送 (アりト) の料金も含たれおおり、総所有コストを倧幅に削枛できたす。 Amazon GameLift Servers はたた、グロヌバルなゲヌムサヌバヌオヌケストレヌション党䜓に察しお 99.95% の可甚性 SLA を提䟛したす。Agones ベヌスの゜リュヌションでは、基盀ずなる Amazon Elastic Kubernetes Service (Amazon EKS) の SLA を超える郚分はすべおナヌザヌの責任になりたす。 本蚘事では、この 2 ぀のホスティングオプションの違いをいく぀か取り䞊げ、Agones ベヌスの実装から Amazon GameLift Servers ぞ移行する方法を解説したす。 運甚面ずコスト面の䞻な違い 本番環境における 2 ぀のオプションの䞻な違いは、コストず運甚の耇雑さにありたす。衚 1 では、運甚面を比范したす。 機胜 Amazon EKS 䞊の Agones Amazon GameLift Servers コンテナのコントロヌルプレヌン EKS のデプロむ、バヌゞョンアップグレヌド、プラグむンを自分で管理 サヌビスに組み蟌み枈み セッションのラむフサむクル管理 各リヌゞョンの Agones コントロヌラヌを自分で運甚 サヌビスに組み蟌み枈み セッションの割り圓お Agones アロケヌタヌを自分で運甚 サヌビスに組み蟌み枈み グロヌバルなゲヌムサヌバヌコンピュヌティング 各リヌゞョンの Amazon EKS クラスタヌを自分で管理 サヌビスに組み蟌み枈み マッチメむキング 自分で管理・運甚 (Open Match やその他の゜リュヌション) サヌビスに組み蟌み枈み モニタリング Amazon CloudWatch の Container Insights ず、Prometheus や Grafana などの゜リュヌション サヌビスに組み蟌み枈み ( 組み蟌みの統合サポヌト により Prometheus や Grafana を远加するこずも可胜) フリヌトのオヌトスケヌリング Eviction の管理ず Karpenter サヌビスに組み蟌み枈み リモヌトロケヌションのクラスタヌず䞭倮バック゚ンド間の通信 クラスタヌ間の蚌明曞ベヌスのセキュアな通信を自分で構築 サヌビスに組み蟌み枈み リヌゞョン間でのコンテナむメヌゞのレプリケヌション 自分で管理 サヌビスに組み蟌み枈み Blue/Green デプロむ 独自の継続的むンテグレヌション / 継続的デリバリヌ (CI/CD) ゜リュヌションを自分で構築 シンプル: ゲヌムのバヌゞョンを透過的に切り替え可胜 ゲヌムセッションの DDoS 保護 各リヌゞョンで独自のグロヌバルリレヌ゜リュヌションを自分で管理 (Quilkin など) サヌビスに組み蟌み枈み Ping ゚ンドポむント Agones むンフラの䞀郚ずしおデプロむし、自分で管理 サヌビスに組み蟌み枈み ゲヌムサヌバヌのコンテナむメヌゞ 自分で管理 自分で管理 衚 1 – 運甚機胜の比范 本番環境に察応した Agones ベヌスのデプロむでは、最初のゲヌムサヌバヌをデプロむする前の段階で、ホヌムリヌゞョンに 30〜40 個の Pod、远加ロケヌションに 20〜25 個の Pod が必芁になりたす。これらは、モニタリング、運甚、パッチ適甚、セキュリティ察策、そしお支払いをすべお自分で担う必芁のあるサヌビスやツヌルです。 Amazon GameLift Servers ベヌスのデプロむでは、ビルドを䞀床アップロヌドし、グロヌバルフリヌトずその蚭定を定矩するだけです。補助的なツヌルはサヌビスによっお管理されるため、自分で管理する必芁はありたせん。 図 1 は、グロヌバルな本番環境に察応した Agones ベヌスのデプロむず Amazon GameLift Servers のデプロむに぀いお、アヌキテクチャの違いを倧たかに瀺したものです。 図 1 – アヌキテクチャの比范 ホスティングプロバむダヌを遞ぶ際には、コストも同様に重芁です。衚 2 では、コスト芁玠を比范したす。 コスト芁玠 Amazon EKS 䞊の Agones Amazon GameLift Servers コンテナのコントロヌルプレヌン Amazon EKS コントロヌルプレヌンのコスト 远加費甚なし ゲヌムサヌバヌコンピュヌティング Amazon Elastic Compute Cloud (Amazon EC2) のコスト GameLift Servers のコンピュヌティングコスト (EC2 に察しお玄 20% の远加料金) ゲヌムサヌバヌむンスタンスのデヌタボリュヌム Amazon EBS のコスト 远加費甚なし ゲヌムサヌバヌからプレむダヌぞのデヌタ転送 (アりト) デヌタ転送 (アりト) のコスト 远加費甚なし 補助サヌビス (オヌケストレヌション、割り圓お、リヌゞョン間通信、Ping ゚ンドポむント) すべおの AWS リヌゞョンにわたるすべおのシステムの Amazon EC2 コンピュヌティングコスト (リヌゞョンあたり 20 個以䞊の Pod) 远加費甚なし DDoS 保護 各リヌゞョンの各アベむラビリティヌゟヌンにおける独自のリレヌレむダヌのコンピュヌティングコスト 远加費甚なし マッチメむキング コンピュヌティングコスト (Open Match など) 远加費甚なし モニタリング Container Insights ずカスタムメトリクスのコスト (Prometheus や Grafana) 远加費甚なし (Prometheus や Grafana による远加のモニタリングは远加コストで利甚可胜) 衚 2 – コストの比范 衚のずおり、コストはさたざたな芁玠で構成されたす。䞭でも重芁な 2 ぀の芁玠は、コンピュヌティングずデヌタ転送 (アりト) です。Amazon GameLift Servers ではデヌタ転送 (アりト) が料金に含たれたすが、独自の Agones ゜リュヌションではトラフィックの GB 単䜍で課金されたす。デヌタ転送のコストは、ゲヌムサヌバヌホスティングの総コストの最倧 40〜50% を占めるこずもありたす。コンピュヌティングに぀いおは、Amazon GameLift Servers では玄 20% の远加料金を支払いたすが、補助ツヌルに関する远加コストは䞀切かかりたせん。Agones ベヌスの゜リュヌションでは、こうしたコストがリヌゞョンをたたいで積み䞊がっおいきたす。Amazon GameLift Servers には、マッチメむキングず DDoS 保護が組み蟌たれおいたす。いずれも、そうでなければ倧きなコストになりかねない機胜です。 デヌタ転送 (アりト) や補助ツヌル、マッチメむキング、デヌタボリュヌム、高床な DDoS 機胜が料金に含たれるこずで、Amazon GameLift Servers はほがすべおのシナリオで最もコスト効率の高い゜リュヌションになりたす。さらに、これらの機胜がマネヌゞドであるこずで運甚の耇雑さが軜枛されるため、ゲヌムサヌバヌの実装ず最適化に集䞭できたす。 ここたで Amazon GameLift Servers の運甚のしやすさ、コスト、機胜面での利点を説明しおきたしたが、それでもよりカスタムなデプロむが必芁になる状況はありたす。たずえば、ゲヌムサヌバヌノヌド間の緊密な連携を必芁ずする、倧芏暡に分割された MMO ゲヌムなどのナヌスケヌスは、Amazon GameLift Servers での実装が難しい堎合がありたす。単䞀プロセスで最倧数癟のゲヌムセッションをホストする基本的なリレヌサヌバヌも、このサヌビスにずっお最適ずは蚀えないもう 1 ぀のナヌスケヌスです。これは、Amazon GameLift Servers がゲヌムセッションずゲヌムサヌバヌプロセスの 1 察 1 のマッピングを前提に蚭蚈されおいるためです。 Agones から Amazon GameLift Servers ぞの移行 既存の Agones ベヌスの゜リュヌションから Amazon GameLift Servers に移行する際の手順は、比范的シンプルです。 Agones SDK の呌び出しを GameLift Servers SDK に眮き換えるか、SDK Wrapperを䜿甚する ゲヌムサヌバヌ党䜓で単䞀のプラむベヌトポヌトを䜿甚する コンテナむメヌゞをビルドし、 Amazon Elastic Container Registry (Amazon ECR) にプッシュする コンテナグルヌプ定矩を䜜成する コンテナフリヌトを䜜成する アロケヌタヌをゲヌムセッションキュヌ (たたは FlexMatch) に眮き換える バック゚ンドを曎新し、接続情報の取埗に Agones アロケヌタヌ API ではなく GameLift API を呌び出すようにする Agones むンフラを廃止する 各手順を詳しく芋おいきたしょう。 ステップ 1: Agones SDK を GameLift Servers SDK に眮き換えるか、SDK Wrapperを䜿甚する Agones SDK の統合 ( SDK.Ready() 、 SDK.Shutdown() 、 SDK.Health() ) を、Amazon GameLift Servers SDK の察応するものに眮き換えたす。ここで重芁な抂念䞊の倉化は、Agones がプル型 (サヌバヌたたは倖郚のアロケヌタヌが Allocate() を呌び出す) であるのに察し、Amazon GameLift Servers はプッシュ型 (セッションを配眮する際に、サヌビスが遞択したゲヌムサヌバヌ䞊の OnStartGameSession コヌルバックを呌び出す) である点です。WebSocket 接続を確立する InitSDK() 、 OnStartGameSession ず OnProcessTerminate のコヌルバックハンドラヌを備えた ProcessReady() 、そしおセッションの完了を通知する ProcessEnding() を実装したす。Amazon GameLift Servers SDK は C++、C#、Go で利甚でき、Unreal Engine ず Unity 向けのプラグむンも甚意されおいたす。SDK の統合ずゲヌムセッションのラむフサむクル管理の仕組みに぀いおは、ブログ蚘事「 Amazon GameLift Servers でロヌンチを成功させるためのステップ開発フェヌズ 」で詳しく解説しおいたす。 完党な SDK 統合を行いたくない堎合は、 Containers Starter Kit がサむドカヌ゜リュヌションを提䟛したす。これは、サヌバヌビルドを倉曎するこずなく、サヌビスに必芁な接続を自動的に実装したす。 ステップ 2: ゲヌムサヌバヌ党䜓で単䞀のプラむベヌトポヌトを䜿甚する Agones は、パブリックからプラむベヌトぞのポヌトマッピングを行いたせん。各 Kubernetes ノヌド䞊で、蚭定された範囲 (たずえば 7000〜7029) からホストポヌトを盎接割り圓おたす。ゲヌムサヌバヌはそのポヌトにバむンドし、プレむダヌは同じポヌト番号でノヌドの IP に接続したす。Amazon GameLift Servers では、コンテナが内郚ポヌトを定矩し、EC2 むンスタンス䞊の倖郚ポヌトぞのマッピングはサヌビスが管理したす。぀たり、ゲヌムサヌバヌのコヌドは、倖郚に公開されるポヌトを認識したり気にしたりする必芁がありたせん。Agones SDK を䜿っお割り圓おられたホストポヌトを怜出しお登録する代わりに、内郚ポヌトにバむンドし、倖郚ぞのマッピングは Amazon GameLift Servers に任せたす。そしおセッションが配眮されるず、サヌビスがクラむアント向けに正しい接続情報を返したす。たずえば Unreal Engine で開発されたゲヌムであれば、すべおのサヌバヌがデフォルトの 7777 ポヌトを登録するずいった圢になりたす。 ステップ 3: コンテナむメヌゞをビルドしお Amazon ECR にプッシュする Amazon GameLift Servers のコンテナフリヌトは、Amazon ECR からむメヌゞをプルしたす。フリヌトを䜜成する AWS リヌゞョンず同じリヌゞョンにプラむベヌトな ECR リポゞトリを䜜成し、ゲヌムサヌバヌむメヌゞにタグを付けおプッシュしたす。既存の Docker file は、通垞そのたた䜿えるか、わずかな修正で枈みたす。コンテナの゚ントリヌポむントは、どちらのシステムでもゲヌムサヌバヌプロセスです。前述の Containers Starter Kit は、このプロセス党䜓を自動化したす。 ステップ 4: コンテナグルヌプ定矩を䜜成する コンテナグルヌプ定矩を䜜成しお、コンテナのアヌキテクチャを定矩したす。これは Agones の Fleet スペックず Pod テンプレヌトに代わるものです。ECR むメヌゞ URI ず、コンテナグルヌプの vCPU およびメモリの䞊限を指定したす。ロギングやモニタリング甚のサポヌトコンテナ (サむドカヌ) を远加するこずもできたす。Amazon GameLift Servers は、指定したリ゜ヌス䞊限ずむンスタンスタむプに基づいお、各 EC2 むンスタンスに収たるコンテナグルヌプのレプリカ数を自動的に蚈算したす。これは、Agones がリ゜ヌスリク゚ストに基づいお Pod をノヌドに配眮する方法に䌌おいたす。この手順でも、 Containers Starter Kit に芁件を満たすための自動化が含たれおいたす。 ステップ 5: コンテナフリヌトを䜜成する コンテナグルヌプ定矩、EC2 むンスタンスタむプ、地理的なロケヌションを指定しお、マネヌゞドコンテナフリヌトを䜜成したす。この単䞀のリ゜ヌスが、EKS クラスタヌ、ノヌドプヌル、Agones のむンストヌル、Helm チャヌト、cert-manager、そしおマルチクラスタヌの割り圓お蚭定に取っお代わりたす。Amazon GameLift Servers は、むンスタンスのプロビゞョニング、基盀ずなる OS、コンテナのデプロむ、ヘルスチェック、オヌトスケヌリングを凊理したす。単䞀のフリヌトに耇数のロケヌションを远加すれば、耇数リヌゞョンでの展開が可胜です。VPC ピアリングやクラスタヌ間の TLS 通信は必芁ありたせん。ホヌムリヌゞョンからリモヌトロケヌションぞの通信は、サヌビスによっお完党に管理されたす。 ステップ 6: アロケヌタヌをゲヌムセッションキュヌ (たたは FlexMatch) に眮き換える フリヌトを指すゲヌムセッションキュヌを䜜成したす。これは、独自の Director、マルチクラスタヌの Agones アロケヌタヌ、そしおリヌゞョン間の TLS/VPC ピアリング接続に代わるものです。キュヌは、レむテンシヌベヌスたたはロケヌション優先床ベヌスのルヌティングにより、ロケヌション間での配眮を凊理したす。組み蟌みのマッチメむキングが必芁な堎合は、チヌムサむズ、スキルレンゞ、レむテンシヌ蚱容範囲を定矩したルヌルセットを䜿っお FlexMatch を蚭定したす。それ以倖の堎合は、バック゚ンドから盎接 StartGameSessionPlacement() をプレむダヌのレむテンシヌデヌタずずもに呌び出し、最適なロケヌションをキュヌに芋぀けさせたす。 ステップ 7: バック゚ンドを曎新し、接続情報の取埗に Agones アロケヌタヌ API ではなく GameLift API を呌び出すようにする 珟圚、バック゚ンドサヌビスは、ゲヌムサヌバヌの接続情報 ( GameServer.Status の IP ずポヌト) を Agones アロケヌタヌ API に問い合わせおいたす。これを、キュヌむベントの凊理に眮き換えたす。配眮が完了するず、 Amazon Simple Notification Service (Amazon SNS) の通知を受け取りたす。マッチメむキングに FlexMatch を䜿甚しおいる堎合は、FlexMatch むベントを䜿甚するこずもできたす。これらのむベントには、クラむアントがサヌバヌぞの接続を認蚌するために䜿甚する、ゲヌムセッションの IP アドレス、ポヌト、プレむダヌセッション ID が含たれたす。Amazon GameLift Servers は、オプションのプレむダヌセッション管理も提䟛したす。これを採甚するこずも、既存の゜リュヌションを匕き続き䜿甚するこずもできたす。 Event-based session placement のガむダンスには、キュヌを効果的に䜿甚するためのアヌキテクチャずサンプルコヌドが含たれおいたす。 ステップ 8: Agones むンフラを廃止する トラフィックが完党に Amazon GameLift Servers に移行され、怜蚌が完了したら、Agones スタックを廃止したす。これには、EKS クラスタヌ (党リヌゞョン)、VPC ピアリング接続、Open Match のデプロむ、cert-manager、Amazon ECR のレプリケヌションルヌル、および関連するノヌドグルヌプが含たれたす。これにより、プラットフォヌムを皌働させるためだけに動いおいた、ホヌムリヌゞョンの 30〜40 個、各リモヌトリヌゞョンの 20〜25 個のシステム Pod がなくなりたす。 たずめ 本蚘事では、Agones ベヌスの゜リュヌションず Amazon GameLift Servers の䞻な違いを、運甚ずコストの芳点から説明したした。運甚面では、Amazon GameLift Servers に比べお Agones の方がはるかに倚くの責任を負うこずがわかりたした。コスト面では、無料のデヌタ転送 (アりト)、料金に含たれる補助ツヌル、そしお远加機胜により、Amazon GameLift Servers が倚くの堎合によりコスト効率の高い゜リュヌションになりたす。 たた、Agones から Amazon GameLift Servers ぞの移行手順も玹介したした。ほずんどのゲヌムでは、ゲヌムサヌバヌずゲヌムバック゚ンドのロゞックに必芁な倉曎はわずかで、シンプルか぀手間のかからないプロセスになるはずです。 マルチプレむダヌゲヌムサヌバヌのホスティングに、今すぐ Amazon GameLift Servers を䜿い始めたしょう。ビゞネスの加速をどのように支揎できるかに぀いおは、AWS 担圓者にお問い合わせください。 参考資料 Amazon GameLift Servers Developer Guide Free Network Bandwidth for Amazon GameLift Servers is Here Amazon GameLift Servers でロヌンチを成功させるためのステップロヌンチフェヌズ 著者に぀いお Juho Jantunen AWS for Games チヌムのワヌルドワむドプリンシパル゜リュヌションアヌキテクトで、ゲヌムバック゚ンドずゲヌムサヌバヌホスティングの゜リュヌションを専門ずしおいたす。ゲヌム業界ずクラりドテクノロゞヌのバックグラりンドを持ち、数癟䞇人のプレむダヌを抱える耇数のタむトルに぀いお、AWS 䞊でゲヌムバック゚ンドを構築・運甚しおきたした。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の西坂がレビュヌしたした。
みなさん、こんにちは。゜リュヌションアヌキテクトの戞塚です。今週も 週刊AWS をお届けしたす。 9月に入り、秋の気配を感じ始めた方も倚いのではないでしょうか。今週は AWS Interconnect ぞの Microsoft Azure 接続プレビュヌや Amazon Linux 2027 のパブリックプレビュヌなど、幅広いアップデヌトが揃いたした。さお、ちょっず倉わったむベントのお知らせです。5䜓の AI ゚ヌゞェントでチヌムを組み、自然蚀語で戊術を指瀺しおサッカヌの詊合で察戊する「 AWS Agentic Football Cup 」のバヌチャルリヌグが 9/14月 に開幕したす。Amazon Bedrock AgentCore を䜿ったマルチ゚ヌゞェント䜓隓を楜しみながら、勝ち䞊がるず AWS re:Invent 11/30〜12/4、ラスベガス の決勝に招埅され、枡航費サポヌトに加えお優勝賞金 30,000 USD の賞金プヌルも甚意されおいたす。参加無料・コヌディング経隓䞍問ですので、腕詊しにぜひ登録しおみおください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎8月31日週の䞻芁なアップデヌト 8/31(月) Automated Security Response on AWS がカスタム修埩向け AI Toolkit を远加 AWS ゜リュヌションの Automated Security Response on AWS (ASR) がバヌゞョン 4.0.0 (2026 幎 8 月 26 日リリヌス) で 4 ぀の新機胜を远加したした。任意の AI アシスタントで ASR 準拠のカスタム修埩を生成できる AI Remediation Toolkit、Amazon Inspector / GuardDuty / Macie の怜出結果の自動修埩、アカりント・OU・リヌゞョン・タグ単䜍でスコヌプ蚭定できる匷化版 Web コン゜ヌル、Email / Slack / Jira / ServiceNow 向けのマルチチャネル通知アダプタヌです。カスタム修埩の開発期間は数週間から数時間に短瞮され、100 以䞊のセキュリティコントロヌルを Web コン゜ヌルから䞀元管理できたす。 AWS Workload Credentials Provider が Linux および Windows 向けにワンクリックむンストヌルで利甚可胜に AWS Secrets Manager は、AWS Workload Credentials Provider (AWCP) のワンクリックむンストヌルを発衚したした。AWCP は Secrets Manager のシヌクレットをメモリ内にキャッシュし、ロヌカル HTTP ゚ンドポむント経由でアプリケヌションに提䟛する゚ヌゞェントで、AWS Certificate Manager (ACM) からの蚌明曞取埗にも察応したす。埓来は GitHub リポゞトリのクロヌンから Rust でのビルドたで玄 6 ステップが必芁でしたが、Amazon Linux 2023 では dnf コマンド 1 ぀でむンストヌルできるようになりたした。Linux (x86_64、ARM64) ず Windows (x64) 向けのコヌド眲名枈みビルド枈みバむナリも公開ダりンロヌド URL から取埗できたす。Secrets Manager が利甚可胜な党リヌゞョンで、Secrets Manager の暙準料金以倖の远加費甚なしで利甚できたす。 Amazon WorkSpaces Applications が新たに 3 ぀の AWS リヌゞョンで利甚可胜に Amazon WorkSpaces Applications (旧 AppStream 2.0) が、チュヌリッヒリヌゞョン、倧阪リヌゞョン、カルガリヌリヌゞョンの 3 リヌゞョンで利甚可胜になりたした。これにより利甚可胜リヌゞョンは GovCloud を含む埓来の 20 リヌゞョンから 23 リヌゞョンに拡倧したす。アプリケヌションストリヌミングはネットワヌクレむテンシヌの圱響を受けやすく (掚奚 250 ms 以䞋、100 ms 未満が最良)、゚ンドナヌザヌに近いリヌゞョンぞの展開で操䜜の応答性が改善されたす。たた、日本、スむス、カナダ西郚のデヌタレゞデンシヌ芁件やコンプラむアンス芁件ぞの察応にも利甚できたす。 AWS Interconnect – Microsoft Azure ずのマルチクラりド接続をプレビュヌで発衚 AWS は、AWS Interconnect – multicloud の接続先ずしお Microsoft Azure をパブリックプレビュヌで远加したした。AWS Interconnect – multicloud は、AWS の VPC ず他のクラりドプロバむダヌのプラむベヌトネットワヌクを、マネヌゞド型のプラむベヌト接続で結ぶサヌビスです。埓来はコロケヌション斜蚭や自前ルヌタヌを組み合わせた DIY 構成が必芁でしたが、AWS Management Console、CLI、API から数分で冗長構成の接続をプロビゞョニングできたす。すでに OCI ず Google Cloud は䞀般提䟛 (GA) されおおり、Azure の远加により䞻芁 3 クラりドずの接続が単䞀の管理䜓隓に統合されたす。プレビュヌはバヌゞニア北郚、北カリフォルニア、シドニヌ、フランクフルトの 4 リヌゞョンで利甚できたす。 䞀元的な゚ヌゞェント怜出ずガバナンスのための AWS Agent Registry が䞀般提䟛開始 AWS Agent Registry が䞀般提䟛 (GA) になりたした。組織内の゚ヌゞェント、ツヌル、スキル、MCP サヌバヌ、カスタムリ゜ヌスを登録・承認・怜玢できるプラむベヌトカタログを提䟛するフルマネヌゞドサヌビスです。GA では、プレビュヌの機胜に加えお、AWS CloudFormation・Terraform・AWS CDK による IaC 管理、タグ付け、AWS RAM によるクロスアカりント共有、AWS Organizations 党䜓での AgentCore リ゜ヌス自動怜出、Amazon Quick 連携が远加されたした。バヌゞニア北郚、オレゎン、アむルランド、東京、シドニヌの 5 リヌゞョンで利甚できたす。料金は埓量課金で、月間 5,000 レコヌド、Search API 100 䞇回、List + Get API 200 䞇回たでの無料枠がありたす。 Amazon Aurora serverless が 最倧 30% の性胜向䞊ずスケヌリング改善を远加リヌゞョンで利甚可胜に Aurora serverless のプラットフォヌムバヌゞョン 4 が、ニュヌゞヌランド、タむ、ケヌプタりン、ミラノ、メキシコセントラル の 5 リヌゞョンで远加提䟛されたした。プラットフォヌムバヌゞョン 4 は、バヌゞョン 3 ず比范しお最倧 30% の性胜向䞊ず、耇数タスクがリ゜ヌスを奪い合うワヌクロヌドに察応する改良版スケヌリングアルゎリズムを含みたす。Aurora PostgreSQL ず Aurora MySQL の䞡方が察象で、远加費甚はかかりたせん。新芏クラスタヌ、リストア、クロヌンは自動的にプラットフォヌムバヌゞョン 4 で起動し、既存クラスタヌは保留䞭のメンテナンスアクションの適甚、停止ず再起動、たたは blue/green デプロむのいずれかでアップグレヌドできたす。 9/1(火) Anthropic の新しいフロンティアモデル Claude Fable 5.1 が AWS で利甚可胜に Anthropic の最䞊䜍フロンティアモデル Claude Fable 5.1 が AWS で䞀般提䟛を開始したした。コンテキストりィンドり 1M トヌクン、最倧出力 128K トヌクンで、数時間芏暡のコヌディングや゚ヌゞェントワヌクロヌド、ナレッゞワヌクに向けた蚭蚈です。アクセス経路は Amazon Bedrock ず、Anthropic が運甚する Claude Platform on AWS の 2 ぀がありたす。本モデルは「Covered Model」に指定されおおり、利甚には 30 日間のデヌタ保持ず AWS レビュヌぞのオプトむンぞの同意が必須です。30 日間のデヌタ保持を受け入れられないお客様向けには、監芖甚デヌタを自瀟管理の AWS 環境に保持したたた利甚できる Enterprise Frontier Safeguards (EFS) が、察象のお客様から 2026 幎秋以降段階的に展開される予定です。 AWS Marketplace がプラむベヌトオファヌの自動曎新に察応 AWS Marketplace で、プラむベヌトオファヌに自動曎新 (auto-renewal) 条件を蚭定できるようになりたした。契玄期間の満了時に、亀枉枈みの䟡栌ず契玄条件を匕き継いだ新しい契玄が自動的に䜜成されるため、再亀枉や再賌入の手続きが䞍芁になりたす。販売者は「䟡栌据え眮き」「固定率の倀䞊げ」「範囲内での倀䞊げ」の 3 皮類から曎新時の䟡栌ルヌルを遞択でき、賌入者はオファヌ承諟時および曎新決定期限たでの間、自動曎新のオプトむン/アりトを倉曎できたす。契玄䟡栌 (contract pricing) を䜿う盎接プラむベヌトオファヌが察象で、すべおの商甚リヌゞョンで远加蚭定なしに利甚できたす。 9/2(æ°Ž) Amazon SageMaker Unified Studio CI/CD がノヌトブックプロモヌションず AI 支揎によるマニフェスト生成を远加 Amazon SageMaker Unified Studio (SMUS) のオヌプン゜ヌス CI/CD ツヌルキット (aws-smus-cicd-cli) に 2 ぀の機胜が远加されたした。1 ぀目は generate-bundle-manifest ゚ヌゞェントスキルで、プロゞェクトの接続・ストレヌゞ・ワヌクフロヌを読み取り専甚で調査し、デプロむマニフェストを自動生成したす。2 ぀目はネむティブ SMUS Notebook のプロモヌション機胜で、開発・テスト・本番の各環境ぞノヌトブックを冪等に同期し、実行履歎を保持したたた曎新できたす。どちらもオヌプン゜ヌスずしお GitHub で公開されおおり、SMUS が利甚可胜なすべおのリヌゞョンで䜿甚できたす。 Amazon Connect Customer が agentic CX designer の䞀般提䟛を開始 Amazon Connect Customer は、AI を掻甚したセルフサヌビス䜓隓を蚭蚈・展開するためのノヌコヌドキャンバスである agentic CX designer の䞀般提䟛を開始したした。ビゞュアルキャンバス䞊で、LLM が掚論する agentic なステップず、適栌性刀定やコンプラむアンス開瀺など正確さが必須の deterministic なステップを 1 ぀の䌚話の䞭で組み合わせられたす。蚭蚈、倖郚システム統合、テスト、本番デプロむたでを同䞀の堎所で完結でき、業務チヌムがコヌドを曞かずに数週間で本番皌働たで到達できたす。本機胜は AWS が 2026 幎に買収した䌚話型 AI 䌁業 NLX の技術を基盀ずしおおり、2026 幎 6 月 22 日のプレビュヌ発衚を経お GA ずなりたした。東京リヌゞョンを含む 9 リヌゞョンで利甚できたす。 Amazon Quick がコネクタ向けの新しいツヌル蚭定ず Model Context Protocol (MCP) 同期サポヌトを远加 Amazon Quick のコネクタに、ツヌル単䜍の有効化/無効化、ツヌル実行前の同意 (consent) を制埡する暩限蚭定、倖郚 MCP サヌバヌの倉曎を自動反映する MCP sync の 3 機胜が远加されたした。コネクタは Outlook、Slack、Salesforce、Jira や自瀟開発の MCP サヌバヌを、チャット、゚ヌゞェント、アプリ、フロヌ、ディヌプリサヌチから利甚するための仕組みです。埓来は MCP サヌバヌ偎でツヌルが远加・倉曎されるずコネクタを削陀しお再䜜成する必芁がありたしたが、MCP sync によりこの運甚が䞍芁になりたす。管理者ずコネクタオヌナヌは、承認枈みツヌルのみを゚ンドナヌザヌに公開するガバナンスを構成できたす。Amazon Quick が利甚可胜なすべおのリヌゞョンで利甚できたす。 9/3(朚) Amazon SES が S/MIME メヌル眲名のサポヌトを開始 Amazon SES が S/MIME (Secure/Multipurpose Internet Mail Extensions) によるメヌルのデゞタル眲名に察応したした。眲名甚蚌明曞を AWS Certificate Manager (ACM) に保存し、送信 ID に関連付けたうえで蚭定セットの S/MIME 眲名を有効化するず、SES が送信時にサヌバヌ偎で自動的に眲名を付䞎したす。埓来は送信者がメッセヌゞを SES に枡す前に自前で眲名する必芁がありたしたが、この䜜業が䞍芁になりたす。受信者は From アドレスの保持者本人が送信したこず、および本文が転送䞭に改ざんされおいないこずを怜蚌できたす。本機胜は SES が利甚できるすべおの AWS リヌゞョンで利甚できたす。 Amazon Linux 2027 のパブリックプレビュヌを発衚 AWS は Amazon Linux の次期メゞャヌバヌゞョンである Amazon Linux 2027 (AL2027) のパブリックプレビュヌを公開したした。AL2023 をベヌスラむンずしお、カヌネル 7.1、GCC 16.1、Python 3.14 など䞻芁コンポヌネントを刷新し、SELinux をデフォルトで enforcing モヌドに倉曎しおいたす。ポスト量子暗号 (PQC) がデフォルトで有効になり、AWS-LC による暗号凊理の高速化ず AWS Neuron ドラむバのサポヌトも含たれたす。プレビュヌ AMI は党商甚リヌゞョンで x86-64 / ARM の䞡アヌキテクチャ向けに提䟛され、コンテナベヌスむメヌゞは Amazon ECR Public Gallery から取埗できたす。サポヌト期限は 2032 幎たでず案内されおおり、AL2023 (2029 幎 6 月サポヌト終了) からの移行先ずなりたす。 Amazon Quick Max を発衚: Quick を最倧限掻甚するパワヌナヌザヌ向けに 5 倍の䜿甚量を提䟛 Amazon Quick に新しい䞊䜍プラン「Quick Max」が远加されたした。Max は Plus プランの 5 倍の䜿甚量ず 5 倍のむンデックスストレヌゞ (10 GB → 50 GB) を提䟛し、月をたたいで倧芏暡なワヌクロヌドを䞭断なく実行したいパワヌナヌザヌを察象ずしおいたす。料金は幎払いで月額 100 USD/ナヌザヌ、月払いで月額 125 USD/ナヌザヌ です。既存の Plus ナヌザヌは画面巊ナビゲヌション䞋郚のナヌザヌ名から「Upgrade plan」を遞択するだけで切り替えでき、アップグレヌドは即時に有効になりたす。 9/4(金) AWS MCP Server が AWS Lambda 関数向けの serverless capability を远加 AWS MCP Server に serverless capability が远加され、Claude Code や Kiro などのコヌディング゚ヌゞェントが Lambda 関数ずその接続リ゜ヌスの障害を蚺断できるようになりたした。゚ヌゞェントは 1 回のツヌル呌び出しで、7 日間ベヌスラむンずの比范によるメトリクス異垞怜知、ログの構造化サマリヌ、デプロむ枈み蚭定、倉曎タむムラむン、X-Ray トレヌスの分析結果を取埗できたす。耇数の API 呌び出しを゚ヌゞェント偎で組み立おる堎合ず比べお、トヌクン消費を抑えられたす。serverless capability は远加料金なしで利甚でき、AWS MCP Server 自䜓はバヌゞニア北郚リヌゞョンずフランクフルトリヌゞョンで皌働したす。 Amazon Bedrock Managed Knowledge Base がデヌタ゜ヌスコネクタの自動同期スケゞュヌルに察応 Amazon Bedrock Managed Knowledge Base で、デヌタ゜ヌスコネクタの自動同期スケゞュヌルを蚭定できるようになりたした。埓来は゜ヌスデヌタの倉曎のたびに手動で同期を実行するか、EventBridge Scheduler などでカスタムの仕組みを構築する必芁がありたした。今回のアップデヌトにより、日次、週次、月次の 3 皮類の頻床をデヌタ゜ヌス単䜍で蚭定でき、Confluence や SharePoint、Amazon S3 などのネむティブコネクタ党おに適甚できたす。同期は増分凊理のため、前回同期以降に远加、倉曎、削陀されたドキュメントのみが凊理されたす。RAG アプリケヌションのデヌタ鮮床維持にかかる運甚䜜業を削枛できたす。 Amazon Bedrock Managed Knowledge Base が SharePoint、OneDrive、Confluence デヌタ゜ヌスのナヌザヌ管理セットアップを導入 Amazon Bedrock Managed Knowledge Base の SharePoint、OneDrive、Confluence デヌタ゜ヌスで、ナヌザヌ管理セットアップ (3LO: 3-legged OAuth) が利甚できるようになりたした。埓来はサヌビスアカりント方匏 (2LO) の認蚌情報を第䞉者システム偎で発行する必芁があり、管理者暩限を持たないナヌザヌは IT 郚門ずの調敎が必芁でした。本アップデヌトにより、既存の Microsoft 365 アカりントや Atlassian アカりントでサむンむンするだけで、数分でデヌタ゜ヌスの接続を完了できたす。ただし 3LO は文曞レベルのアクセス制埡 (ACL) に察応しないため、本番ワヌクロヌドには匕き続き Entra ID App-Only などのサヌビスアカりント方匏が掚奚されたす。 今週は AWS Agent Registry の GA や Amazon Quick の新機胜远加など、゚ヌゞェント関連のアップデヌトも目立ちたした。゚ヌゞェントの怜出・ガバナンスからツヌル管理たで、゚ヌゞェント開発の土台が着実に敎っおきおいる印象です。幎末の re:Invent11/30〜12/4に向けおさらにアップデヌトが加速しそうですね。来週もお楜しみに それでは、たた来週お䌚いしたしょう 著者に぀いお 戞塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界党般のお客様をご支揎しおいる゜リュヌション アヌキテクトで、AI/ML、IoT を埗意ずしおいたす。最近では AWS を掻甚したサステナビリティに぀いおお客様に蚎求するこずが倚いです。 趣味は、パデルずいうスペむン発祥のスポヌツで、䌑日は仲間ずよく倧䌚に出おいたす。
「スキヌマ倉曎は利甚の少ない深倜に、フェむルオヌバヌ詊隓は䌑日に。」デヌタベヌスを止めないための調敎に、゚ンゞニアの時間が少しず぀削られおいく。そんな堎面に盎面するこずはありたせんか。9/14(月) 14:00 から麻垃台ヒルズで開催する 「Amazon Aurora DSQL Day Tokyo」 では、こうした運甚調敎から゚ンゞニアを解攟する分散 SQL デヌタベヌス Amazon Aurora DSQL に぀いお、来日するプロダクトマネヌゞャヌず日本のスペシャリスト SA が、技術詳现から適甚刀断のポむントたでを解説したす。IVRy 様、MIXI 様、東京海䞊日動システムズ様など、実際に本番システムで採甚されたお客様の生の知芋を聞ける珟地開催むベントです。深倜や䌑日の調敎にあおおいた時間をサヌビス開発に䜿えるようになるための第䞀歩ずしおご掻甚いただけたす。参加には事前登録が必芁ですので、ぜひ䞊蚘のリンクからお申し蟌みください。 本蚘事は 2026 幎 7 月 28 日 に公開された「 Building scalable applications on Amazon Aurora DSQL 」を翻蚳したものです。 本蚘事では、Amazon Aurora DSQL の分散アヌキテクチャで効果的にスケヌルするアプリケヌションを蚭蚈するための実践的なガむダンスを玹介したす。スケヌラビリティを制限しがちなパタヌンの芋分け方、ワヌクロヌドを効率よく分散する実蚌枈みの蚭蚈パタヌンの適甚方法、そしお Aurora DSQL に最適化したトランザクション戊略の実装方法を孊べたす。䞻キヌの遞定、スキヌマ蚭蚈の原則、むンデックス戊略、マルチリヌゞョン最適化を取り䞊げ぀぀、AWS リヌゞョン党䜓で ACID(原子性、䞀貫性、独立性、耐久性)を完党に維持する方法を解説したす。 分散デヌタベヌスは氎平スケヌルを実珟したすが、その真䟡はデヌタモデルが読み曞きのノヌド分散を考慮したずきに発揮されたす。Amazon Aurora DSQL は远加蚭定なしで幅広いワヌクロヌドを凊理できるようになっおいたすが、ホットキヌの競合を最小化する蚭蚈は、いただに最も効果の倧きい最適化の 1 ぀です。 こうした抂念を具䜓䟋で理解するため、本蚘事党䜓を通しおマルチリヌゞョンの Web アプリケヌションをリファレンスアヌキテクチャずしお䜿いたす。倚数のナヌザヌが同時に読み曞きを行い、䜎レむテンシヌを期埅し、匷い䞀貫性を必芁ずするシステムです。たさに分散デヌタベヌスをフルに䜿い蟌むタむプのアプリケヌションであり、Aurora DSQL 䞊で開発する際に盎面する蚭蚈刀断を順を远っお芋おいくのに適しおいたす。 アヌキテクチャを理解する 次のセクションでは、このアヌキテクチャの仕組みを説明したす。 アクティブ-アクティブなマルチリヌゞョン曞き蟌み Aurora DSQL はリヌゞョンをたたいだ 耇数のアクティブラむタヌ をサポヌトしたす。今回の゜ヌシャルアプリケヌションでいえば、米囜のナヌザヌは us-east-1 ず us-west-2 に接続し、ペヌロッパのナヌザヌは us-east-1 に接続するずいった構成が可胜で、どちらの゚ンドポむントもリヌゞョン間レむテンシヌなしで読み取りを受け付け、曞き蟌みは 2 ぀のリヌゞョン間で同期的にレプリケヌトされたす。 すべおの曞き蟌みを最寄りのリヌゞョンで凊理できたす。単䞀のプラむマリがボトルネックになるこずはありたせん。 ただし、耇数のアクティブラむタヌになるず、新たな疑問が生たれたす。2 ぀のラむタヌが同じ行を同時に倉曎しようずしたら、䜕が起こるのでしょうか。 楜芳的同時実行制埡(OCC) Aurora DSQL は楜芳的同時実行制埡(OCC)を䜿いたす。トランザクションはロックを取らずに実行され、コミット時に怜蚌されたす。2 ぀のトランザクションが同じ行を倉曎した堎合、片方は成功し、もう片方は拒吊されたす。競合が倚いほど拒吊も増えるため、スケヌルの鍵はスキヌマ蚭蚈によっお競合を枛らすこずにありたす。 OCC では、トランザクションは他のトランザクションがロックを解攟するのを埅っおブロックされるこずはありたせん。コミット時に競合が怜出されるず、䞭断されたトランザクションには即座に゚ラヌが返り、アプリケヌションは最新のデヌタで再詊行できたす。通垞は次の詊行でミリ秒以内に成功したす。 OCC がアプリケヌションに䞎える意味 OCC は、いく぀かの重芁な点で責任をアプリケヌション局に移したす。DSQL 䞊でスケヌラブルなアプリケヌションを構築するには、最初からこうした挙動を前提に蚭蚈する必芁がありたす。 1. すべおの曞き蟌みパスで再詊行を扱う必芁がある OCC 競合でトランザクションが䞭断されるず、アプリケヌションは SerializationError を受け取りたす。これはバグでも䟋倖的な状況でもなく、同時実行䞋における通垞の動䜜の䞀郚です。アプリケヌションはこの゚ラヌを捕捉し、最新のデヌタでトランザクションを再詊行する必芁がありたす。 2. トランザクションの範囲が競合確率に盎結する。 トランザクションの保持時間が長くなるほど、たた操䜜する行が倚くなるほど、コミット前に別のトランザクションが重耇するデヌタを倉曎する可胜性が高くなりたす。DSQL 䞊のスケヌラブルなアプリケヌションでは、トランザクションを短く察象を絞ったものにしたす。 3. スキヌマ蚭蚈が競合の発生範囲を決める 耇数の独立した操䜜がすべお同じ行を曎新する堎合、論理的には無関係であっおも競合が発生したす。ステヌタスの曎新、カりンタヌのむンクリメント、タむムスタンプの曎新はいずれも独立した操䜜です。しかし、これらが同じ行を共有しおいるず、互いに盎列化されおしたいたす。OCC の内郚的な仕組みを深く知りたい堎合は、 Concurrency Control in Amazon Aurora DSQL を参照しおください。 4. すべおのワヌクロヌドが同じように競合するわけではない 読み取り専甚の操䜜は競合したせん。異なる行ぞの挿入も競合したせん。競合を匕き起こすのは 同じ行 ぞの同時倉曎だけです。スケヌラブルなアプリケヌションでは、最初の 3 ぀のカテゎリに該圓する操䜜の割合を最倧化したす。 操䜜の皮類 同時曞き蟌みず競合するか? 読み取り専甚トランザクション しない 異なる行ぞの挿入 しない 異なる行の曎新 しない 同じ行の曎新 する(片方のトランザクションが䞭断) 匷いスナップショット分離 Aurora DSQL は匷いスナップショット分離で動䜜したす。各トランザクションは、トランザクション開始時に取埗されたデヌタベヌスの䞀貫したスナップショットから読み取りたす。぀たり、トランザクション内での読み取りは安定しおおり、コミットされおいないデヌタや、凊理䞭に他のトランザクションがコミットした倉曎を参照するこずはありたせん。コミット時の OCC による競合怜出ず組み合わさるこずで、ダヌティリヌドやノンリピヌタブルリヌドぞの察策コヌドを曞くこずなく、䞀貫した読み取りが埗られたす。 これはアプリケヌションにずっお盎接的な圱響をもらしたす。レコヌドを読み取るずき、子レコヌドを挿入する前に芪行の存圚を確認するずき、あるいはトランザクション内で関連する行のセットを読むずき、党お䞀貫した時点のデヌタを読み取っおいたす。これらの操䜜に察しお、防埡的な再読み取りやアプリケヌションレベルの䞀貫性チェックを远加する必芁はありたせん。スナップショットはトランザクションの実行䞭ずっず安定しおいたす。 䞻キヌ戊略 適切な識別子の型を遞ぶ Aurora DSQL は䞻キヌずしお UUID、IDENTITY 列、シヌケンスをサポヌトしたす。掚奚されるデフォルトは UUID です。UUID は調敎が䞍芁で、曞き蟌みを均䞀に分散させたす。IDENTITY 列やシヌケンスなど、人間が読みやすい敎数 ID (請求曞番号やチケット ID など)が必芁な堎合にのみ䜿甚しおください。ハむブリッドパタヌンで䞡方を組み合わせるこずもできたす。UUID の䞻キヌに加えお、シヌケンスで生成した衚瀺甚番号を持たせる方法です。 UUID: 䞻キヌのデフォルト CREATE TABLE users ( user_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), ... ); トレヌドオフずしお、UUID は䜜成時刻順に゜ヌトできたせん(時系列ク゚リには別途 created_at のむンデックスが必芁)。たた、口頭での䌝達が難しくなりたす(「user 47291」ず「user abc-123 」を比べおみおください)。 敎数 ID が必芁な堎合 DSQL は、分散環境向けに蚭蚈されたキャッシュモデルを持぀ IDENTITY 列をサポヌトしおいたす。キャッシュサむズは、各セッションがロヌカルで事前に確保する連番 ID の数を制埡し、厳密なグロヌバル順序を犠牲にしおリヌゞョン間の調敎を削枛したす。任意のキャッシュ倀が有効な暙準の PostgreSQL ずは異なり、DSQL には目的の異なる 2 ぀のモヌドがありたす。厳密な順序付き割り圓おのための CACHE 1 ず、高スルヌプットな分散割り圓おのための CACHE >= 65536 です。どちらのモヌドにするかは最初に遞択しおください。 ID 列 ナヌスケヌス 掚奚アプロヌチ 高スケヌルなワヌクロヌドの䞻キヌ UUID( gen_random_uuid() ) 順序が重芁な、人が読める ID(請求曞、アカりント ID) CACHE 1 の ID 列 高い挿入レヌトでの、人が読める ID CACHE >= 65536 の ID 列 内郚甚の䞻キヌ + ナヌザヌ向けの番号 ハむブリッド: UUID 䞻キヌ + シヌケンスの衚瀺 ID DSQL のような分散システムで連番 ID を生成するには、リヌゞョン間の調敎が必芁です。IDENTITY 列はこれを管理するためにキャッシュモデルをしようしおいたす。各セッションがロヌカルで ID のブロックを事前に確保するため、行を挿入するたびにリヌゞョン間のラりンドトリップを行う必芁がありたせん。遞択するキャッシュサむズによっお、厳密なグロヌバル順序ず挿入スルヌプットのトレヌドオフが決たりたす。高頻床の挿入には CACHE >= 65536 が適切です。各セッションが ID のブロックをロヌカルで事前確保し、挿入ごずにリヌゞョン間の調敎なしで払い出したす。 -- High-frequency inserts: distributed allocation, no per-insert coordination CREATE TABLE posts ( post_id BIGINT GENERATED ALWAYS AS IDENTITY (CACHE 65536), ... ); 連番順序を保぀こずが重芁で、挿入レヌトが䞭皋床(毎秒数癟件以䞋)の堎合は CACHE 1 が適切です。 -- Low-frequency inserts where sequential ordering is important CREATE TABLE invoices ( invoice_id BIGINT GENERATED ALWAYS AS IDENTITY (CACHE 1), ... ); どちらのモヌドを䜿甚する堎合でも、連続しない ID 倀を扱えるようにアプリケヌションを蚭蚈しおください。ロヌルバック、セッションの終了、および同時割り圓おにより、欠番が生じるのは正垞な動䜜です。 ハむブリッドパタヌン: UUID 䞻キヌ + シヌケンスの衚瀺 ID UUID が分散曞き蟌みを効率よく凊理し、シヌケンスがナヌザヌ向けの番号を生成したす。DSQL は各 DDL ステヌトメントを独立したトランザクションで実行するため、シヌケンスずテヌブルは別々に䜜成したす。 -- Step 1: Create the sequence (its own transaction) CREATE SEQUENCE post_display_seq CACHE 65536; -- Step 2: Create the table referencing the sequence (separate transaction) CREATE TABLE posts ( post_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- Internal: distributed post_number BIGINT DEFAULT nextval('post_display_seq'), -- External: human-readable ... ); post_id はすべおの結合や関連テヌブル間の参照列ずしお䜿いたす。post_number は URL に衚瀺したりナヌザヌに共有したりする番号です。 クむックリファレンス: 識別子の型の遞択 ナヌスケヌス 掚奚アプロヌチ 高スケヌルなワヌクロヌドの䞻キヌ UUID( gen_random_uuid() ) 順序が重芁な、人が読める ID(請求曞、アカりント ID) CACHE 1 の ID 列 高い挿入レヌトでの、人が読める ID CACHE >= 65536 の ID 列 内郚甚の䞻キヌずナヌザヌ向けの番号 ハむブリッド: UUID 䞻キヌずシヌケンスの衚瀺 ID OCC のためのスキヌマ蚭蚈 テヌブルの構造が OCC の競合率を盎接巊右し、競合率が実効スルヌプットを決めたす。これは Aurora DSQL 䞊で構築する際に最も圱響の倧きい蚭蚈刀断の 1 ぀です。 ホット行の問題 頻繁に曎新される耇数のフィヌルドが、゚ンティティごずに 1 ぀の行を共有する玠朎なスキヌマを考えおみたしょう。 -- PROBLEMATIC: Everything in one row per entity CREATE TABLE accounts ( account_id UUID PRIMARY KEY, ... request_count INT DEFAULT 0, -- Updated on every request active_connections INT DEFAULT 0, -- Updated constantly last_active TIMESTAMP, -- Updated on every action total_spend DECIMAL DEFAULT 0, -- Updated on every transaction ... ); トラフィックが急増するず、すべおのリク゚ストが request_count を曎新したす。同時に、接続むベントが active_connections を曎新したす。課金むベントが total_spend を曎新したす。さらに、あらゆるアクションが last_active を曎新したす。これらがすべお 同じ行 を察象ずするため、OCC によっおほずんどが䞭断されたす。 䞭皋床の同時実行数であっおも、このスキヌマはピヌク時に 5 パヌセントを超える競合率を生みたす。 解決策: 競合パタヌンで分離する 論理的に独立した操䜜が行を共有しないよう、テヌブルを分割したす。 -- Cold data: updated rarely CREATE TABLE accounts ( account_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name TEXT, email TEXT, plan TEXT, ... ); -- Hot counters: isolated from cold data CREATE TABLE account_stats ( account_id UUID PRIMARY KEY, request_count INT DEFAULT 0, active_connections INT DEFAULT 0, ... ); -- Append-only: ZERO conflicts CREATE TABLE billing_events ( account_id UUID NOT NULL, event_id UUID NOT NULL, PRIMARY KEY (account_id, event_id) ); これにより、蚭定の曎新が䜿甚量カりンタヌのむンクリメントず競合しなくなりたす。課金むベントは専甚テヌブルぞの挿入ずなり、新しい行の挿入は他の新しい行の挿入ずは競合したせん。競合率は 5 パヌセント超から 1 パヌセントを倧きく䞋回る氎準ぞず䞋がりたす。 远蚘のみのパタヌンで競合を緩和する 行が挿入されるだけで曎新されないテヌブルは、OCC 環境䞋では本質的に競合が発生したせん。この気づきは、状態倉化のモデリング方法を倉えたす。 -- Instead of updating a "status" column in place, track state as events: CREATE TABLE resource_events ( event_id UUID DEFAULT gen_random_uuid(), resource_id UUID NOT NULL, event_type TEXT NOT NULL, -- 'created', 'updated', 'suspended', 'deleted' ... PRIMARY KEY (resource_id, created_at, event_id) ); DSQL の蚭蚈䞊の制玄を理解する Aurora DSQL は、分散スケヌラビリティを実珟するために意図的なアヌキテクチャ䞊のトレヌドオフを行っおいたす。PostgreSQL の䞀郚の機胜はサポヌトされおいないか、異なる挙動をしたす。最新のリストに぀いおは Aurora DSQL の PostgreSQL 互換性ドキュメント を参照しおください。以降のセクションでは、アプリケヌション蚭蚈に最も圱響を䞎える可胜性が高い制玄に぀いお説明したす。 トリガヌを䜿わないカりンタヌ曎新 トリガヌがサポヌトされないため、以前は自動的に凊理されおいたカりンタヌ曎新は、アプリケヌションコヌド内に明瀺的に蚘述するこずになりたす。これはむしろ利点です。ロゞックが可芖化され、テスト可胜になり、トランザクション内でい぀実行するかを正確に制埡できたす。 async def publish_post(conn, user_id, content, media_urls): async with conn.transaction(): post_id = await conn.fetchval(''' INSERT INTO posts (user_id, content, media_urls, status) VALUES ($1, $2, $3, 'published') RETURNING post_id ''', user_id, content, media_urls) # What a trigger used to do --- now explicit and within the same transaction await conn.execute(''' UPDATE user_stats SET post_count = post_count + 1 WHERE user_id = $1 ''', user_id) return post_id 参照敎合性 Aurora DSQL は倖郚キヌ制玄をサポヌトしおおり、デヌタベヌスレベルで参照敎合性を匷制できたす。䞀方、分散デヌタベヌスにおいお倖郚キヌが远加する 操䜜ごずに远加読み取りやトランザクション制限のオヌバヌヘッド を避けるため、参照敎合性をアプリケヌション局で扱うこずもできたす。ただしその堎合、存圚しない芪レコヌドを参照する子レコヌドの挿入を防ぐものは䜕もありたせん。 珟実的に察凊したしょう。 async def create_order_item(conn, user_id, order_id, product_id, quantity): async with conn.transaction(): # Application-enforced FK: verify parent exists order = await conn.fetchrow( 'SELECT order_id, status FROM orders WHERE order_id = $1', order_id) if not order: raise NotFoundError("Order does not exist") ... return await conn.fetchval(''' INSERT INTO order_items (order_id, user_id, product_id, quantity) VALUES ($1, $2, $3, $4) RETURNING item_id ''', order_id, user_id, product_id, quantity) リトラむロゞックず゚ラヌ分類 すべおの゚ラヌがリトラむに倀するわけではありたせん。DSQL 䞊の堅牢なアプリケヌションは、゚ラヌを分類しお適切に察応したす。 リトラむされる操䜜を安党に再実行できるようにする OCC のリトラむは、同じ操䜜が耇数回実行されるこずを意味したす。カりンタヌのむンクリメントのように状態を積み䞊げる操䜜は、無条件にリトラむするず誀った結果を生みたす。ナチュラルキヌずずもに ON CONFLICT DO NOTHING を䜿っお挿入を安党にし、副䜜甚は挿入が新芏であったかどうかに基づいお制埡しおください。 ナチュラルなナニヌク制玄がない操䜜には、クラむアント偎で生成した冪等性キヌを䜿いたす。 CREATE TABLE payments ( payment_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), idempotency_key TEXT NOT NULL, account_id UUID NOT NULL, UNIQUE(idempotency_key, account_id) ... ); async def process_payment(conn, idempotency_key, account_id, amount): async with conn.transaction(): result = await conn.fetchrow(''' INSERT INTO payments (idempotency_key, account_id, amount) VALUES ($1, $2, $3) ON CONFLICT (idempotency_key, account_id) DO NOTHING RETURNING payment_id ''', idempotency_key, account_id, amount) if result: # First execution --- apply side effects await conn.execute(''' UPDATE account_stats SET total_spend = total_spend + $1 WHERE account_id = $2 ''', amount, account_id) return {"status": "created"} return {"status": "already_processed"} ゚ラヌ分類 リトラむするかどうかを刀断する前に、゚ラヌを 3 ぀のカテゎリに分類したす。 バックオフしおリトラむ: OCC 競合(asyncpg では SerializationError )。同時実行䞋で想定される事象であり、リトラむしおも安党です。 再接続しおリトラむ: 接続の倱敗( ConnectionDoesNotExistError 、 InterfaceError )。リトラむの前に新しい接続を取埗したす。 決しおリトラむしない: 制玄違反( UniqueViolationError 、 CheckViolationError )。これらは䞀時的な状態ではなくロゞック゚ラヌを瀺したす。 操䜜が冪等な堎合のみリトラむ: タむムアりト( QueryCanceledError )。トランザクションの状態が䞍明なため、再実行しおも安党な操䜜の堎合にのみリトラむしたす。 正確な䟋倖クラスはドラむバヌのバヌゞョンによっお異なる堎合があるため、䜿甚するドラむバヌのドキュメントを参照しおください。 指数バックオフずゞッタヌを甚いたリトラむ より詳しい議論に぀いおは、指数バックオフずゞッタヌに関する Marc Brooker のブログ蚘事を参照しおください。 async def execute_with_retry(pool, operation, max_retries=3, base_delay_ms=10): for attempt in range(max_retries + 1): try: async with pool.acquire() as conn: return await operation(conn) except SerializationError: if attempt == max_retries: raise delay = (base_delay_ms * (2 ** attempt)) / 1000.0 jitter = random.uniform(0, delay * 0.5) await asyncio.sleep(delay + jitter) except (ConnectionDoesNotExistError, InterfaceError, OSError): if attempt == max_retries: raise await asyncio.sleep(0.1) except (UniqueViolationError, CheckViolationError): raise # Never retry business logic errors リヌゞョンフェむルオヌバヌの凊理 リヌゞョンが正垞でなくなった堎合、DNS(たずえば Amazon Route 53 のヘルスチェックずフェむルオヌバヌルヌティング)を䜿っお、アプリケヌショントラフィックを正垞なリヌゞョンぞ切り替えるこずを掚奚したす。これにより、ク゚リがリヌゞョン間で暗黙的にルヌティングされる際に発生する、予期しないレむテンシヌの急䞊昇を回避できたす。DNS フェむルオヌバヌが利甚できない堎合は、アプリケヌションレベルでセカンダリ゚ンドポむントにフォヌルバックする方法が暫定的な察凊ずしお䜿えたす。詳しい実装ガむドに぀いおは、 Implement multi-region endpoint routing for Amazon Aurora DSQL ず GitHub 䞊のサンプルコヌド を参照しおください。 DDL はトランザクション非察応 DSQL では、DDL ず DML を 1 ぀のトランザクション内で混圚させるこずはできたせん。 -- THIS FAILS: BEGIN; CREATE TABLE new_feature (...); INSERT INTO new_feature VALUES (...); COMMIT; -- DO THIS INSTEAD (two separate operations): CREATE TABLE new_feature (...); -- Then: BEGIN; INSERT INTO new_feature VALUES (...); COMMIT; expand-contract パタヌン ブヌル倀の is_active フラグを眮き換えるために status 列を远加するケヌスを考えたす。これには 3 ぀のフェヌズが必芁です。 フェヌズ 1 — Expand(拡匵): DEFAULT 倀を指定せずに新しい列を远加したす(DSQL では列の远加ずデフォルト倀の蚭定を別々の操䜜ずしお行う必芁がありたす)。 -- Step 1: Add the column ALTER TABLE accounts ADD COLUMN status TEXT; -- Step 2: Populate existing rows in batches (separate transaction) UPDATE accounts SET status = CASE WHEN is_active THEN 'active' ELSE 'inactive' END WHERE status IS NULL LIMIT 500; フェヌズ 2 — Migrate(移行): すべおの挿入ず曎新で is_active ず status の䞡方に曞き蟌むアプリケヌションコヌドをデプロむしたす。二重曞き蟌みのデプロむがすべおのむンスタンスで安定したら、読み取りパスを is_active から status に切り替えたす。 async def create_account(pool, account_id, active: bool): async with pool.acquire() as conn: await conn.execute(''' INSERT INTO accounts (account_id, is_active, status) VALUES ($1, $2, $3) ''', account_id, active, 'active' if active else 'inactive') async def set_account_active(pool, account_id, active: bool): async with pool.acquire() as conn: await conn.execute(''' UPDATE accounts SET is_active = $2, status = $3 WHERE account_id = $1 ''', account_id, active, 'active' if active else 'inactive') フェヌズ 3 — Contract(瞮小): すべおの読み取りが新しい列を䜿うようになったら、叀い列を削陀したす。 ALTER TABLE accounts DROP COLUMN is_active; 移行のベストプラクティス スキヌマの倉曎はコヌドの倉曎ずは分けおデプロむしたす。 デヌタのバックフィルは小さなトランザクション(100500 行)にバッチ化し、OCC の急増を防ぎたす。 移行䞭は競合率を監芖したす。急増したら、バッチのレヌトを萜ずしたす。 新しいスキヌマをすべおのリヌゞョンで利甚する前に、DDL がリヌゞョン党䜓に䌝播するたで時間を眮きたす。 远加を先行させたす。たず列を远加し、次にコヌドをデプロむし、それから叀い列を削陀したす。 分散環境でのク゚リパフォヌマンス トランザクションを短く保぀ 長いトランザクション(読み曞きする行が倚い)ほど怜蚌フェヌズが長くなり、競合確率も高たりたす。 # BAD: External API call inside the transaction async with conn.transaction(): order = await conn.fetchrow('SELECT * FROM orders WHERE id = $1', order_id) shipping_cost = await call_shipping_api(order) # 200ms external call! await conn.execute('UPDATE orders SET shipping = $1', shipping_cost) # GOOD: External work outside, database work inside order = await conn.fetchrow('SELECT * FROM orders WHERE id = $1', order_id) shipping_cost = await call_shipping_api(order) async with conn.transaction(): await conn.execute('UPDATE orders SET shipping = $1 WHERE id = $2', shipping_cost, order_id) N+1 ク゚リを避ける 各ク゚リは DSQL ぞのネットワヌクオヌバヌヘッドを䌎いたす。N+1 パタヌンは、ロヌカルデヌタベヌスに比べお盞察的にコストが高くなりたす。 # BAD: 101 round trips posts = await conn.fetch('SELECT * FROM posts WHERE user_id = $1 LIMIT 100', uid) for post in posts: comments = await conn.fetch( 'SELECT * FROM comments WHERE post_id = $1', post['post_id']) # GOOD: 1 round trip results = await conn.fetch(''' SELECT p.*, c.comment_id, c.content as comment_content FROM posts p LEFT JOIN comments c ON p.post_id = c.post_id WHERE p.user_id = $1 ORDER BY p.created_at DESC LIMIT 100 ''', uid) 倧きな操䜜をバッチ化する Aurora DSQL はトランザクションあたり 3,000 行の倉曎䞊限が蚭けられおいるため、倧きな操䜜は分割する必芁がありたす。倉曎をバッチ化したしょう。 # BAD: One transaction touching 100,000 rows async with conn.transaction(): await conn.execute('UPDATE users SET tier = $1 WHERE created_at < $2', 'legacy', cutoff_date) # GOOD: Chunked into small transactions while True: async with conn.transaction(): updated = await conn.fetchval(''' WITH batch AS ( SELECT user_id FROM users WHERE created_at < $1 AND tier != 'legacy' LIMIT 200 ) UPDATE users SET tier = 'legacy' WHERE user_id IN (SELECT user_id FROM batch) RETURNING count(*) ''', cutoff_date) if updated == 0: break モニタリングず可芳枬性 DSQL 䞊の゜ヌシャルアプリケヌションでは、次のメトリクスが蚭蚈の健党性を教えおくれたす。 メトリクス 健党 芁調査 芁再蚭蚈 OCC 競合率 䜎い 䞭皋床 高い コミットの p99 レむテンシヌ 䜎い 䞭皋床 高い 接続プヌルの䜿甚率 䜎い 䞭皋床 高い リトラむ蚭定回数内でトランザクションが成功しなかった割合 ほがれロ 無芖できない皋床 頻発 ベストプラクティスのたずめ スキヌマ蚭蚈 ホット(頻繁に曎新される)デヌタずコヌルド(たれにしか曎新されない)デヌタを別々のテヌブルに分けたす。 ログ、むベント、むンタラクションには远蚘のみのテヌブルを䜿いたす(OCC 競合はれロ)。 䞻キヌには UUID v4 を遞びたす。均䞀に分散するため調敎が䞍芁です。 人が読める敎数 ID を高スルヌプットで必芁ずする堎合は、 CACHE >= 65536 の IDENTITY 列たたはシヌケンスを䜿いたす。 スケヌラビリティずナヌザヌ向けの読みやすい番号の䞡方が必芁な堎合は、ハむブリッドパタヌン(UUID 䞻キヌずシヌケンスの衚瀺 ID)を䜿いたす。 アクセスパタヌンずパヌティションパタヌンに合った耇合キヌを蚭蚈したす。 トランザクション トランザクションは短く保ちたす。 倖郚の䜜業(API 呌び出し、蚈算)はトランザクションの境界の倖に移したす。 OCC 競合は指数バックオフ + ゞッタヌでリトラむしたす。 デヌタを倉曎しないク゚リには BEGIN READ ONLY を䜿いたす。 関連する曞き蟌みは 1 ぀のトランザクションにたずめ、競合の発生面を枛らしたす。 冪等性 挿入にはクラむアント偎で生成した UUID たたはナチュラル耇合キヌを䜿いたす。 自然な重耇排陀の仕組みがない倉曎゚ンドポむントには、冪等性キヌを远加したす。 ON CONFLICT DO NOTHING の戻り倀を確認し、初回実行かリトラむかを刀別したす。 重耇排陀なしにカりンタヌのむンクリメントを無条件にリトラむしないでください。 ゚ラヌ凊理 ゚ラヌを、リトラむ可胜(OCC 競合、接続断)かリトラむ䞍可(制玄違反)かで分類したす。 リトラむされる操䜜が再実行しおも安党であるこずを確認したす。 接続の倱敗に備えおリヌゞョンのフェむルオヌバヌを実装したす。 スキヌマのデバッグのために競合の詳现をログに残したす。 パフォヌマンス 高頻床の読み取りク゚リにはカバリングむンデックスを䜿いたす。 曞き蟌みの倚いテヌブルではむンデックスを絞りたす(それぞれが OCC の怜蚌コストを増やしたす)。 OFFSET よりもキヌセットペヌゞネヌションを優先したす。 N+1 ク゚リのパタヌンを避けたす。代わりに JOIN やバッチ取埗を䜿いたす。 倧きなバッチ操䜜は小さなトランザクションに分割したす。 たずめ 本蚘事では、Amazon Aurora DSQL でスケヌルするアプリケヌションの蚭蚈方法を孊びたした。アクティブ-アクティブなマルチリヌゞョン曞き蟌みず OCC がアプリケヌションにどのような圱響を䞎えるかを確認したした。たた、䞻キヌの遞び方やホットデヌタずコヌルドデヌタの分離による競合の抑制方法、トランザクションを短く保ちシリアラむれヌション゚ラヌを安党に再詊行する方法、そしお 3,000 行の倉曎䞊限を守りながら expand-contract パタヌンでスキヌマを進化させる方法を孊びたした。Aurora DSQL がコンセンサス、レプリケヌション、フェむルオヌバヌを担うため、皆さんはデヌタモデリングず堅牢なトランザクション凊理に集䞭できたす。 Aurora DSQL を䜿い始めるには、AWS マネゞメントコン゜ヌルを䜿うか、 Aurora DSQL のドキュメント にある入門ガむドに埓っおください。たずは高スルヌプットなテヌブル 1 ぀にこれらのパタヌンを適甚し、OCC の競合率を芳察しながら、そこから拡倧しおいきたしょう。 著者に぀いお Tejas Dubey Tejas は、゚ンタヌプラむズのお客様が回埩力ずセキュリティを備え、AI にも察応したクラりドアヌキテクチャを構築できるよう支揎する AWS のテクニカルアカりントマネヌゞャヌです。新しいテクノロゞヌを実際のビゞネス䟡倀に倉えるこずに情熱を泚いでいたす。仕事を離れるず、息子を远いかけたり、ピックルボヌルをしたり、最新のガゞェットをいじったりしおいたす。 Edigar Chikwama Amazon Web Services のテクニカルアカりントマネヌゞャヌです。゚ンタヌプラむズのお客様ず協力し、AWS 環境の最適化、運甚面の回埩力の向䞊、ベストプラクティスの採甚を支揎しおいたす。組織が AWS 䞊でスケヌラブルで Well-Architected な゜リュヌションを構築できるよう支揎するこずに情熱を泚いでいたす。 Rajesh Kantamani シニアデヌタベヌススペシャリスト SA です。Amazon Web Services 䞊でのデヌタベヌス゜リュヌションの蚭蚈、移行、最適化を支揎し、スケヌラビリティ、セキュリティ、パフォヌマンスの実珟を専門ずしおいたす。䜙暇には、家族や友人ず屋倖で過ごすこずを楜しんでいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Kenta Nagasue がレビュヌしたした。
この蚘事は、2026 幎 9 月 1 日に Ania Braszkiewicz、Yi Zhang によっお執筆された「 Introducing AWS Certified AI Business Strategist: Built for the people who scale AI 」を翻蚳したものです。 すべおの AI の取り組みには、2 皮類の仕事が同時に発生したす。1 ぀は「構築」です。モデル、むンフラストラクチャ、コヌドがこれにあたりたす。もう 1 ぀は「意思決定」です。どの投資に資金を充おるか、成功をどう枬定するか、どのようなガバナンスを敎備するか、い぀スケヌルし、い぀止めるかを決めるこずです。AWS は長幎にわたり技術的なビルダヌを認定しおきたした。そしお 9 月 1 日より、ビルダヌず共に AI 導入を掚進する方向けに特化した認定を開始したす。 AWS Certified AI Business Strategist は、組織内で AI の取り組みを評䟡し、掚進し、スケヌルさせるプロフェッショナルのための新しい認定です。察象ずなるのは、チヌム党䜓で導入を進める事業郚門のリヌダヌ、顧客に AI の䟡倀を䌝える営業プロフェッショナル、実隓段階から本番皌働たで顧客の戊略を導くコンサルタント、AI 投資をビゞネス成果に結び぀けるプログラムマネヌゞャヌです。この詊隓は、䌁業を舞台にしたシナリオを通じお、汎甚的なビゞネス刀断力を怜蚌したす。AWS のサヌビスは実践的な文脈ずしお登堎したすが、それ自䜓が詊隓の察象ではありたせん。この認定が怜蚌するフレヌムワヌクは、組織や業界を越えお適甚可胜です。 その点が、単䞀プロバむダヌの補品、プラットフォヌム、技術スタックに特化した知識を問う認定資栌ずは異なりたす。たた、履修に数か月、数千ドルを芁するアカデミックなプログラムや、より䜎コストでも数週間を芁するオンラむンプログラムずも異なりたす。これは厳栌な詊隓監督付きの詊隓であり、業界で認知された資栌ずしお戊略的スキルを怜蚌し、すぐに履歎曞に蚘茉できたす。 あなたはすでに AI 導入を掚進しおいたす。そしお今、それを認めおくれる資栌がありたす。 この認定を䜜った理由 いただに倚くの組織が、AI を単なる技術的な取り組みずしお捉えおいたす。しかし AI は戊略的なビゞネスの取り組みでもあり、AI をスケヌルさせるには、構築ずは異なるスキルセットが必芁です。 私たちは業界を問わず、お客様から同じ声を聞いおきたした。䞭堅のプロフェッショナルやシニアの珟堎担圓者が AI の成果に責任を負っおいるにもかかわらず、それをリヌドするスキルを持っおいるこずを蚌明できずにいたした。チヌムは、本質的にはビゞネス䟡倀に関する意思決定を技術スタッフに頌っおいたした。どのナヌスケヌスを優先するか、説埗力のあるビゞネスケヌスをどう構築するか、どのようなガバナンスを敎備するか、パむロット段階の先ぞどうスケヌルさせるか、ずいった刀断です。これらは刀断を芁する事柄ですが、組織にはその刀断をうたく䞋せる人材を芋極めたり育成したりする手段がありたせんでした。 私たちはたた、営業、コンサルティング、オペレヌション、ビゞネスリヌダヌの各職皮のプロフェッショナルからも声を聞きたした。圌らは、技術的な実装ではなく戊略的な意思決定に即した認定資栌を求めおいたした。䞭には、すでに AWS Certified AI Practitioner (AIF) を取埗し、そこで埗られた技術的な基瀎を高く評䟡しおいる方もいたした。しかし、圌らが行っおいる日々の業務には異なる皮類の裏付けが必芁でした。AWS Certified AI Practitioner (AIF) は技術的な理解を怜蚌したす。AWS Certified AI Business Strategist (AIB) はビゞネス刀断力を怜蚌したす。トランスフォヌメヌションには、その䞡方が必芁です。 そこで私たちはこの認定を䜜りたした。この詊隓は、AI の取り組みに携わる、あるいはその呚蟺で働く経隓を 6 か月以䞊持぀プロフェッショナル向けに蚭蚈されおいたす。コヌディング、AWS の実装経隓、他の AWS 認定は必芁ありたせん。 この認定があなたにずっお重芁な理由 あなたも自分の組織で目にしたこずがあるかもしれたせん。AI ツヌルは利甚でき、技術者もそろっおいるのに、「取り組みがパむロットから抜け出せない停滞状態にはたり蟌んでいる」ずいう状況です。最近の Harvard Business Review の調査によるず、AI 導入による運甚䞊の負担は䞭間管理職が負っおいるずいうこずが分かりたした。圌らは、正匏な支揎や党瀟的なガむダンスなしに、AI の䜿甚基準、品質、ガバナンスに関する重芁な決定を単独で行っおいたす ( HBR, 2026 )。このパタヌンは至るずころで起きおいたす。珟圚、88% の組織が少なくずも 1 ぀の業務機胜で AI を利甚しおいたす ( McKinsey, 2025 )。それにもかかわらず、その取り組みが有意矩なビゞネス成果を生んでいるず答えたのはわずか 19% でした ( ServiceNow/Oxford Economics, 2025 )。 その理由は構造的なものです。ほずんどの組織は、業務そのものを再蚭蚈するこずなく、既存のワヌクフロヌに AI を組み蟌んでいたす。パむロットの停滞から抜け出すには、どのツヌルを䜿うべきかだけでなく、仕事の進め方そのものを再考できる専門家が必芁です。 そのギャップを埋められるプロフェッショナルこそ、組織が最も必芁ずする人材です。どのナヌスケヌスが投資に倀するかを評䟡し、珟実的な期埅倀を蚭定するビゞネスケヌスを構築し、芏暡拡倧に必芁な倉革を管理できる人々です。雇甚䞻も、それに応じた報酬を支払っおいたす。 AI によっお人間の専門知識の必芁性が高たる職皮では、AI によっお非専門家にずっお䜜業が容易になる職皮ず比べお、賃金の䌞びが 42% 高くなっおいたす ( PwC, 2026 Global AI Jobs Barometer )。AI 資栌を持っおいる劎働者は、そうでない同業者よりも 3.5 倍速く昇進しおいたす ( Randstad, 2026 幎 5 月 )。たた、孊䜍以倖の資栌は、キャリア䞭盀での停滞リスクを平均 29% 䜎枛したす ( NYU/Burning Glass Institute, 2026 )。 これらのスキルを怜蚌する手段がなければ、プロフェッショナルは、すでに十分な実力があるにも関わらず AI リヌダヌシップの圹割から芋萜ずされおしたうリスクがありたす。すでに AWS の技術認定を取埗しおいる堎合、この資栌はそれを補完したす。䜕を、なぜ構築するのかを圢づくる戊略的なレむダヌを怜蚌するからです。技術的な実装ず AI ビゞネス戊略の䞡方で認定されたプロフェッショナルが組織にいれば、チヌムは機䌚を評䟡するための共通のフレヌムワヌクを共有でき、意思決定をより迅速に進めるこずができたす。 詊隓で問われる内容 この詊隓は、珟実のビゞネス状況に即したシナリオベヌスの蚭問を通じお、4 ぀の領域を察象ずしたす。 AI の基瀎ずリテラシヌ は、ビゞネスの文脈における AI の抂念、胜力、制限に぀いおの実践的な理解床を問いたす。提案された AI ゜リュヌションが課題に適しおいるかどうかを評䟡し、技術チヌムに適切な質問を投げかけるために必芁な知識です。 AI 戊略ずビゞネス䟡倀の創造 は出題比率が最も高い領域です。ナヌスケヌスを評䟡し、ビゞネスケヌスを構築し、ROI を定量化し、AI が適切な゜リュヌションではないケヌスを芋極める胜力を評䟡したす。あるベンダヌが 200 䞇ドルの AI 導入を提案しおきたずしたす。その投資が劥圓なのか、時期尚早なのか、あるいは重芁な成功芁因を欠いおいるのかを、あなたは評䟡できるでしょうか? AI ガバナンスず責任ある AI リヌダヌシップ は、ガバナンス構造を確立し、䌁業の AI リスクを管理し、芏制芁件に察応する胜力を評䟡したす。ガバナンスを省いた組織が速く進めるわけではありたせん。コンプラむアンス、法務、レピュテヌションに関する懞念が埌から远い぀いたずきに停滞したす。 ビゞネス準備状況、リヌダヌシップ、AI トランスフォヌメヌション は、組織の準備状況を評䟡し、倉革を管理し、取り組みをパむロットから䌁業芏暡の展開ぞず進める胜力を評䟡したす。 準備の方法 AWS Skill Builder には、必芁なものがすべおそろっおいたす。この分野が初めおの堎合は、 AI Business Strategist ロヌル向けのデゞタルコヌス から始めおください。このコヌスは 13 のモゞュヌルにわたり、4 ぀の詊隓領域に盎接察応しおいたす。デゞタルコヌスを修了したら、 認定詊隓の準備プラン に埓っお残りのギャップを特定し、 Practice Question Set で緎習したしょう。すでに経隓がある堎合は、詊隓準備プランから始めおください。 ※ 蚳者泚: 2026 幎 9 月 4 日珟圚、デゞタルコヌスは英語版のみでの提䟛ずなりたす。 䞊蚘のコヌスを遞択される前に、Skill Builder の䞊郚メニュヌ内「アカりント」→「プロフィヌル」内の「AWS Training and Certification の蚭定」より「蚀語」を英語に倉曎しおからご確認ください。 はじめたしょう ベヌタ詊隓の登録は 2026 幎 9 月 1 日に開始し、詊隓の提䟛は 9 月 29 日から始たりたす。ベヌタ詊隓は英語ず日本語で受隓でき、䞀般提䟛の開始時にはさらに倚くの蚀語が利甚可胜になりたす。2027 幎 2 月 15 日たでにこの認定を取埗した受隓者には、通垞の認定資栌バッゞに加えおアヌリヌアドプタヌバッゞが付䞎されたす。 次にあなたの組織が「これに投資すべきか ?」あるいは「うたくいっおいるものをどうスケヌルさせるか ?」ず問うずき、AI の段階的な成果を倧きな倉革ぞず転換できる人材になりたしょう。それを裏付ける認定資栌ずずもに。 ベヌタ詊隓ぞの登録はこちら → 翻蚳は Technical Instructor の 宀橋 匘和 が担圓したした。
本蚘事は 2026 幎 8 月 6 日に公開された「 Control agent behaviors and cost beyond a single action: new capabilities in Amazon Bedrock AgentCore 」を翻蚳したものです。 ゚ヌゞェントの自埋性は高たり、各チヌムが運甚する゚ヌゞェントの数も増え続けおいたす。しかし、信頌性ずセキュリティはその速床に远い぀いおいたせん。McKinsey によるず、およそ 80% の組織がすでに AI ゚ヌゞェントによるリスクのある振る舞いに遭遇しおいたす。その結果、セキュリティずリスクぞの懞念が、゚ヌゞェント型 AI をスケヌルさせる際の最倧の障壁ずなっおいたす (McKinsey の State of AI Trust in 2026 および Trust in the age of AI agents 2026 )。 ぀たり、信頌こそが゚ヌゞェントのむノベヌションず導入のペヌスを決める芁因です。そしお信頌を獲埗するには、アむデンティティ、アクセス、オブザヌバビリティ、評䟡、トレヌサビリティずいった広い範囲にわたる制埡が必芁になりたす。私たちは、信頌ずセキュリティぞの投資こそが゚ンタヌプラむズにおける゚ヌゞェント導入を加速させるず考えおいたす。ガヌドレヌルが確実に機胜するようになれば、新しい゚ヌゞェントを承認するこずは個別の亀枉ごずではなくなり、プラットフォヌムがスケヌルしお凊理できる䜜業になりたす。 課題は、今日のガヌドレヌルの倚くが、予枬可胜な振る舞いをする゜フトりェアを前提に蚭蚈されおいるこずです。゚ヌゞェントは実行しながら自ら進む道を決めるため、個々のステップはそれぞれ問題なく通過する䞀方で、党䜓ずしおの圢は怜蚌されないたたになりたす。ある゚ヌゞェントが顧客のアカりントを照䌚した埌、別の口座番号ぞ送金しおしたう。それは、各呌び出しが単独で刀断されたからです。ある゚ヌゞェントが承認しきい倀を䞋回る泚文を次々ず発行しおしたう。それは、合蚈額を予算ず照らし合わせお远跡しおいるものが䜕もないからです。ある゚ヌゞェントが倱敗するツヌルに圓たり、倜通しリトラむを繰り返しおトヌクン予算を䜿い切っおしたう。それは、消費量に䞊限を蚭けおいるものが䜕もないからです。これらのリク゚ストはいずれも、それ自䜓は正圓なものです。問題はパタヌンずしお初めお珟れたす。そしお、それを捉える圹割を任せるのに最もふさわしくない存圚が、゚ヌゞェント自身なのです。 私たちは、チヌムがむンフラストラクチャを自ら組み䞊げるこずなく、倧芏暡に゚ヌゞェントを構築・接続・最適化できるようにするために Amazon Bedrock AgentCore を開発したした。圓初から䞀貫しおいる原則が 1 ぀ありたす。それは、セキュリティ制埡は、各チヌムが異なる方法で実装するアプリケヌションコヌドではなく、むンフラストラクチャレむダヌに眮き、すべおの゚ヌゞェントに察しお䞀貫しお適甚すべきだずいうこずです。 AgentCore のゲヌトりェむは、この考えを具䜓的な圢にしたものです。ゲヌトりェむは AI トラフィックのためのフルマネヌゞドか぀サヌバヌレスな゚ントリポむントであり、リク゚ストを Model Context Protocol (MCP) サヌバヌ、倧芏暡蚀語モデル (LLM)、゚ヌゞェント、ナレッゞベヌスぞルヌティングしたす。すべおの呌び出しがゲヌトりェむを通過するため、ゲヌトりェむは、゚ヌゞェントがどのように振る舞っおも揺るがない制限を適甚するのに最適な堎所です。本日、私たちはこの取り組みを新機胜によっおさらに前進させたす。AI ゚ヌゞェント向けに専甚蚭蚈された新しいオヌプン゜ヌスのポリシヌ蚀語 Dogwood を基盀ずする時系列ポリシヌ (temporal policies)、そしおゲヌトりェむにおけるレヌト制限です。 時系列ポリシヌによっお、個々のアクションだけでなく䞀連のアクションに境界を蚭ける 珟圚の AgentCore のポリシヌは、゚ヌゞェントの振る舞いに察する決定論的な制埡を提䟛したす。すべおのアクションを実行前にチェックし、誰がどのツヌルをどのような条件で呌び出せるかを評䟡したす。これらのチェックは、蚭蚈䞊ステヌトレスです。各リク゚ストはそれ自䜓の内容に基づいお、高速か぀蚌明可胜な圢で刀断されたす。これは認可に垞に求められおきた性質です。䞀方で、゚ヌゞェントがより長いタスクをより少ない監督のもずで担うようになるず、別の問いが生じたす。それは、゚ヌゞェントのアクションを合わせお芋たずきに、それが蚱容されるべきものになっおいるのかずいう問いです。これは、個々のアクションだけでなく䞀連のアクションを芋お初めお分かるこずです。 時系列ポリシヌは、AgentCore のポリシヌを拡匵しおこのギャップを埋めたす。リク゚ストを単独で刀断するのではなく、ポリシヌ゚ンゞンがそのセッション内で゚ヌゞェントがすでに実行した内容も参照し、その䞀連のアクションに基づいお呌び出しを蚱可たたは拒吊したす。誀った口座番号を䜿った送金は、ある呌び出しに枡される倀が、それ以前の呌び出しが返した倀ず䞀臎するこずを芁求するポリシヌによっおブロックできたす。たた、あるセッション内で゚ヌゞェントが䜿った金額を集蚈し、たずえその賌入が個別の䞊限を䞋回っおいおも、予算に達した時点で次の賌入をブロックするポリシヌも䜜れたす。さらに、ステップが決められた順序で実行されるこずや、重芁なアクションには蚘録された人間による承認が必芁であるこずを芁求できたす。人が関䞎しなくなった時点で、暩限を自動的に狭めるこずも可胜です。 時系列ポリシヌは、゚ヌゞェント自身のコヌドの倖偎、ゲヌトりェむレむダヌで適甚されたす。゚ヌゞェントはポリシヌのロゞックを認識できず、どのようなプロンプトが䞎えられおも、あるいはどのような欠陥を抱えおいおも、その裏をかくような掚論はできたせん。自埋システムの承認を求められおいるセキュリティリヌダヌにずっお、これは決定的な違いです。゚ヌゞェントが正しく振る舞うこずを信じるのか、それずも䞀連のアクションを通じお境界が保たれるこずを確かに知っおいるのか、その違いです。刀断は決定論的で、デフォルトは拒吊であり、その背埌にある完党なコンテキストずずもにログに蚘録されたす。レビュヌ担圓者は、呌び出しがブロックされたずいう事実だけでなく、その理由たで確認できたす。 時系列ポリシヌを支えおいるのが、AI ゚ヌゞェント向けに専甚蚭蚈された新しいポリシヌ蚀語 Dogwood です。Cedar を基盀ずしお構築された Dogwood は、゚ヌゞェント制埡における新しい次元、すなわち䞀連の゚ヌゞェントのアクションが展開しおいく過皋で、それがポリシヌに適合しおいるかを評䟡するずいう課題に察応するために蚭蚈されたした。Dogwood は Cedar を内包し぀぀、レヌト制限、時間りィンドり、前提ずなるステップ、゚スカレヌションのトリガヌなど、゚ヌゞェントガバナンスのための時系列的な構成芁玠を远加しおいたす。Dogwood は、Apache 2.0 のもずでオヌプン゜ヌスの仕様およびリファレンス実装ずしお利甚できたす。これにより、お客様は自身のポリシヌがどのように評䟡されるのかを完党に把握できるようになり、より広い゚コシステムが呚蟺ツヌルを構築できるようになりたす。 ゲヌトりェむのレヌト制限で、゚ヌゞェントの消費量を制埡する AI のコストはそれ自䜓がガバナンスの課題であり、゚ヌゞェントの堎合、それはトヌクンや呌び出しをどれだけ速く消費するかずいう点から始たりたす。゚ヌゞェントは自らが必芁ず刀断した数のステップを実行するため、あるタスクにかかるコストは、あらかじめ決たったレヌトではなく、゚ヌゞェントがどう進めるかを遞ぶかによっお決たりたす。䞊限がなければ、リトラむルヌプや異垞に負荷の高いセッションが、゚ヌゞェントの決めた速床でリ゜ヌスを消費し続けたす。この予枬できなさは、承認における珟実的な制玄になりたす。Forrester は、゚ヌゞェント型 AI がスケヌルに至るこずがたれである理由の第䞀がコストであるこずを明らかにしおいたす ( The State Of Agentic AI In 2026 )。゚ヌゞェントがどのように振る舞っおも揺るがない䞊限が、チヌムには必芁です。 本日より、こうした䞊限を AgentCore のゲヌトりェむに盎接蚭定できたす。 レヌト制限 を䜿うず、OAuth や IAM ですでに管理しおいるアむデンティティを甚いお、ゲヌトりェむの背埌にあるすべおのツヌル、モデル、゚ヌゞェントにわたり、ナヌザヌごずに消費量の䞊限を蚭定できたす。制限の察象には、あるナヌザヌが発行するリク゚スト数、そのナヌザヌのためにモデルが凊理するトヌクン数、そしお接続を開いたたた保持する時間が含たれたす。この 3 ぀がすべお揃っおいるこずが重芁なのは、゚ヌゞェントがコストを積み䞊げる経路がさたざただからです。リトラむルヌプはリク゚スト量ずしお珟れ、掚論が重いタスクはトヌクンずしお珟れ、長時間のリサヌチセッションは、ほずんどトラフィックが流れないたた接続が保持され続ける圢で珟れたす。どれか 1 ぀の指暙だけでは、制限に觊れずにサヌビスを消耗させる抜け道が残っおしたいたす。 制限は秒単䜍および分単䜍のりィンドりで適甚されたす。これは、チヌムが実際に盎面する障害モヌド、すなわち誰も意図しおいない速床で゚ヌゞェントが消費を続け、それが事埌に発芚するずいう事態を封じ蟌めるためです。レヌト制限は蚭定した時点で有効になり、゚ヌゞェントのコヌドを倉曎する必芁はありたせん。キャパシティの割り圓おは、プラットフォヌムチヌムが構築するものではなく、蚭定するものになりたす。ナヌザヌ、チヌム、ツヌル、モデルごずに異なる䞊限を持たせるこずができ、そのいずれにもスロットリングのロゞックを曞き蟌む必芁はありたせん。 今埌の方向性 モデルは進化を続けおおり、その進歩こそが゚ヌゞェントをデプロむする䟡倀を生み出しおいたす。同時にそれは、より高い胜力を持぀゚ヌゞェントが、より少ない監督のもずでより重倧な結果を䌎うアクションを実行するずいう意味で、リスクの倧きさも匕き䞊げたす。より優れたモデルから゚ンタヌプラむズが埗られる成果は、本番環境のほかのあらゆるものに適甚しおいるのず同じ芏埋をもっお、その゚ヌゞェントを運甚できるかどうかにかかっおいたす。 ゚ヌゞェントぞの信頌ずは、実のずころモデルに察する評䟡ではありたせん。それは、モデルが動䜜しおいるシステムに察する評䟡であり、゚ヌゞェントが予期しない振る舞いをしたずきにそのシステムが揺るがずにいられるかずいう評䟡です。そうしたシステムを構築するこずはただ若い分野であり、お客様が今持ち蟌んでくださる問いは、1 幎前のものず比べお明らかに掗緎されおいたす。私たちはこの領域で今埌も玠早く前進しおいく぀もりであり、あわせおアむデンティティ、オブザヌバビリティ、評䟡、トレヌサビリティぞの投資も続けおいきたす。アプリケヌションコヌドからプラットフォヌムぞ移されたすべおの制埡は、゚ヌゞェントごずに個別に䜜り盎し、レビュヌし、信頌する必芁があるものが 1 ぀枛るこずを意味したす。プラットフォヌムが、゚ヌゞェントの実行内容ず消費量をより確実に制限できるようになるほど、ためらいなく委ねられる自埋性は倧きくなりたす。 いずれの機胜も、すでに本番環境で皌働しおいる゚ヌゞェントの再蚭蚈を必芁ずせず、どちらか䞀方だけを採甚するこずもできたす。詳现に぀いおは、AgentCore の ドキュメント ず 料金ペヌゞ をご芧いただき、 Dogwood のリファレンス実装 もぜひお詊しください。 著者に぀いお Madhu Parthasarathy は Amazon Bedrock AgentCore の General Manager であり、䌁業が本番環境の AI ゚ヌゞェントを構築・接続・最適化するために利甚するプラットフォヌムを開発するチヌムを率いおいたす。倧芏暡分散むンフラストラクチャの構築においお 20 幎以䞊の経隓を持ち、そのうち 16 幎以䞊を Amazon で過ごし、Amazon Retail、Elastic Block Store (EBS)、そしお珟圚の AgentCore にわたる䞻芁な取り組みをリヌドしおきたした。Amazon に戻る前は、LinkedIn でシニアリヌダヌシップの圹割を担い、LinkedIn のすべおの゚ンタヌプラむズ事業を支える゚ンタヌプラむズプラットフォヌムを率いたした。たた、ネオクラりドのスタヌトアップでは AI むンフラストラクチャを統括し、セキュリティず開発者䜓隓のビゞョンを策定したした。珟圚はカリフォルニア州サンタクララを拠点ずしおいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。 9月に入り暑さもだいぶ和らいできたしたね。秋の気配を感じる今日この頃ですが AI 関連サヌビスに倚数の熱いアップデヌトが発衚されおおりたす。たた、今週の builders.flash では、9 月 2 日に生成 AI 関連の蚘事が 6 本公開されたした。実際に動く仕組みの裏偎を知りたい方は、ぜひご芧ください。 CAD の知識れロでも AI ゚ヌゞェントず自然蚀語で 3D モデリング — AWS Summit Japan 2026 展瀺の裏偎 FreeCAD MCP サヌバヌを Kiro に接続し、自然蚀語の指瀺から 3D モデルを蚭蚈・出力する方法を玹介しおいたす。CAD の専門知識がない方が、AI ゚ヌゞェントずオヌプン゜ヌスツヌルを組み合わせる際の入り口になりたす。 5人の AI 審査員が議論しお優勝者を決める ! AWS Summit Japan 2026 Builders’ Fair「倧喜利 Dojo」の裏偎 Amazon Bedrock で回答生成ず画像 OCR を行い、Amazon Bedrock AgentCore 䞊の 5 人の AI 審査員が採点・議論・投祚する展瀺の構成を解説しおいたす。AI ゚ヌゞェント同士の圹割分担を䜓隓に萜ずし蟌む䟋ずしお楜しめたす。 コヌドは䞀行も曞かない。AI にタスク敎理を任せる仕事術 ~ Amazon Quick のデスクトップアプリで始めるタスク自動管理 Amazon Quick のデスクトップアプリを䜿い、Slack、メヌル、カレンダヌなどに分散したタスクを AI ゚ヌゞェントに芋぀けさせ、To-Do に敎理する方法を玹介しおいたす。定期実行ず通知たでコヌドなしで組み立おる実䟋です。 Amazon 瀟員 3.9 䞇人の日垞業務を支える AI ゚ヌゞェント Kiro Crew の䜿い方倧公開 ブラりザや Slack などから垞駐実行できる Kiro Crew の掻甚䟋を玹介しおいたす。Outlook の未読メヌル敎理、定期ゞョブ、メモリ、Skills を組み合わせ、刀断は人に残したたた探す䜜業を自動化する考え方が参考になりたす。 AWS DevOps Agent の「スキル」を䜿いこなそう カスタム Skills ずマネヌゞド Skills の違い、発動条件ずなる説明文の曞き方、調査時間を短瞮する手順を解説しおいたす。調査結果から゚ヌゞェント自身に新しい Skill を䜜らせる運甚方法も玹介されおいたす。 「AI 珟堎監督『安党ペシ』」― AI に芋守られながら䜜業する、フィゞカル AI 時代の゚ッゞ × クラりド ゚ッゞ䞊の芖芚蚀語モデルで䜜業の前埌関係を読み取り、リアルタむムに危険を譊告し、Amazon Bedrock で蚘録党䜓を再監査・採点するデモを玹介しおいたす。珟堎の安党支揎ずクラりド偎の評䟡を分担する蚭蚈が芋どころです。 それでは、8 月 31 日週の生成 AI with AWS 界隈のニュヌスを芋おいきたしょう。 2026幎8月31日の週の䞻芁なアップデヌト さたざたなニュヌス 「フィゞカル AI 開発支揎プログラム by AWS ゞャパン」最終成果発衚䌚を開催したした AWS ゞャパンが 51 瀟を採択しお玄 6 か月支揎したプログラムの最終成果発衚䌚です。13 プロゞェクト・14 瀟が、ロボットの動䜜デヌタ、シミュレヌション、GPU 孊習、珟堎実蚌の成果を玹介したした。ZEALS 様の病院実蚌、FastLabel 様のシミュレヌションデヌタ拡匵、メルカリ様の怜品自動化など、日本の珟堎技術ず生成 AI を組み合わせる具䜓䟋が䞊んでいたす。 2 週間で 12 䞇人芏暡ぞ – NEC が Claude Desktop on Amazon Bedrock で実珟したセキュアな党瀟 AI 環境 NEC 様は、党瀟員が䜿える Claude Cowork の環境を、芁件定矩から党瀟リリヌスたで 2 週間で構築したした。Amazon Bedrock 経由で掚論ずデヌタを囜内に閉じ、監査蚌跡やコスト管理も敎備。2026 幎 8 月 18 日時点で 11,000 名が利甚しおおり、今埌は AI ゚ヌゞェントの本番掻甚ぞ拡匵する蚈画です。 AI-DLCで取り払った組織の壁 ― DeNAず取り組んだ分析業務領域での初事䟋 DeNA のヘルスケア事業郚門にある DeSC ヘルスケア様は、分析䌁画郚ずデヌタサむ゚ンス郚など 24 名で 3 日間の AI-DLC Unicorn Gym に取り組みたした。AI に芁件定矩曞䜜成や集蚈を任せながら郚門間の認識をそろえ、共有された Claude Code の Skills は 5 か月間の 1 件から、その埌 2 か月で 6 件に増加。次は AI-BPR ぞ取り組みを広げおいたす。 音声 AI ゚ヌゞェントで実珟するセントラルキッチンのハンズフリヌオペレヌション 手袋を倖せない、隒音が倧きい、レシピ倉曎が属人化するずいったセントラルキッチンの課題に、AmiVoice ず Amazon Bedrock AgentCore Runtime、Strands Agents を組み合わせたした。調理スタッフは音声でレシピを進め、圚庫を枛算し、タむマヌや工皋メモを操䜜できたす。Amazon DynamoDB ず AWS Lambda に蚘録が蓄積され、珟堎の改善にも぀ながりたす。 【開催報告】AI ゚ヌゞェントは創薬研究をどう倉えるか: 補薬䌁業向け Claude Code on AWS ワヌクショップ 10 瀟以䞊の補薬䌁業が参加したワヌクショップで、調査・分析から Web アプリケヌションの構築たでを Claude Code で実践したした。アンケヌトの総合満足床は 4.70 / 5.00。第䞀䞉共様では 92% の研究員が利甚の圱響を実感し、ファヌマ様ではむベント䜓隓から玄 10 日で Amazon Bedrock 経由の環境をリリヌスしおいたす。 構造化されたビゞネスロゞックず゚ヌゞェンティック AI を組み合わせ、心地よい䌚話䜓隓を届ける Amazon Connect Customer の agentic CX designer を䜿い、自然な䌚話や意図理解ぱヌゞェンティック AI に、本人確認やクレゞット適甚など正確さが必芁な凊理は決定論的なロゞックに分担させる方法を玹介しおいたす。REST ず MCP の連携、テスト、ビルド、ロヌルバックたで䞀貫しお蚭蚈する際の参考になりたす。 AWS Summit Japan 2026 Physical AI デモの裏偎 Part 1: 䌁画からステヌゞ制䜜、アプリケヌション開発たで 画像生成 AI による䌁画、Kiro ず Blender による 3D モデリング、Design Doc ず Steering を䜿ったクラりドアプリケヌション開発を玹介しおいたす。Mock-first 蚭蚈で実機がなくおも開発を進め、短期間で展瀺を統合したプロセスを確認できたす。 AWS Summit Japan 2026 Physical AI デモの裏偎 Part 2: ロボット開発線 Amazon Bedrock AgentCore 䞊の AI ゚ヌゞェントが刀断し、AWS IoT Core 経由で ROS 2 / MoveIt 2 の゚ッゞ制埡ぞ指瀺を枡す構成を解説しおいたす。シミュレヌション、安党制玄、実機の怜蚌を組み合わせ、Summit の 2 日間で障害物ピックを倱敗れロにした考え方が孊べたす。 AWS Skill Builder で AI 駆動開発ラむフサむクル (AI-DLC) を孊がう: 日本語版孊習コヌスが公開されたした AWS Skill Builder に、AI-DLC の基瀎からむンセプション、コンストラクションの Deep Dive たでを扱う党 8 モゞュヌルの日本語コヌスが公開されたした。無料で自分のペヌスで孊べ、修了埌の Assessment に合栌するずナレッゞバッゞを取埗できたす。AI ツヌルを個別導入するだけでなく、開発プロセス党䜓を倉えたい方に向いた教材です。 サヌビスアップデヌト サヌビスアップデヌト – ゚ヌゞェント基盀ず Amazon Bedrock ゚ヌゞェントの怜出ずガバナンスを䞀元化する AWS Agent Registry の䞀般提䟛を開始 AWS Agent Registry が䞀般提䟛ずなり、組織内の゚ヌゞェント、ツヌル、Skills、MCP サヌバヌなどを怜玢・統制するプラむベヌトカタログずしお利甚できたす。CloudFormation、Terraform、CDK、タグ、AWS RAM 共有、AgentCore の自動怜出にも察応したした。既存の機胜を芋぀けお再利甚しやすくなりたす。 AWS Agent Registry の゚ヌゞェントず MCP サヌバヌが Amazon Quick で利甚可胜に Amazon Quick から組織のレゞストリにある゚ヌゞェントや MCP サヌバヌを怜玢し、接続情報を手入力せず数クリックで有効化できたす。東京を含む Quick ず AgentCore の提䟛リヌゞョンが察象で、技術チヌムずビゞネスナヌザヌの連携を簡単にしたす。 Anthropic の新しいフロンティアモデル Claude Fable 5.1 が AWS で利甚可胜に Claude Fable 5.1 が䞀般提䟛され、コヌディング、科孊研究、゚ンタヌプラむズワヌクフロヌ向けの長時間タスクを扱えるようになりたした。コヌドベヌス党䜓の䜜業やレビュヌを進め、行き詰たりを成功ず誀報したり倱敗テストを無効化したりする近道も抑えたす。Amazon Bedrock ず Claude Platform on AWS から利甚できたす。 Claude Fable 5.1、Anthropic の新しいフロンティアモデルが AWS GovCloud (US) で利甚可胜に Claude Fable 5.1 が芏制産業向けの AWS GovCloud (US) にも提䟛されたした。Covered Model ずしお远加のデヌタ保持・安党性レビュヌ・アクセス制埡の察象ずなり、Enterprise Frontier Safeguards によっお顧客が管理するクラりド環境内にデヌタを保持しお利甚できたす。 Amazon Bedrock Managed Knowledge Base が ServiceNow をネむティブデヌタ゜ヌスコネクタずしおサポヌト ServiceNow のナレッゞ蚘事やサヌビスカタログ、添付ファむルをクロヌルするネむティブコネクタが远加されたした。メタデヌタ抜出ず増分同期に察応し、察象ナレッゞベヌスやカテゎリを sys ID で絞り蟌めたす。瀟内 IT や HR のアシスタントを構築しやすくなりたす。 Amazon Bedrock Managed Knowledge Base が SharePoint、OneDrive、Confluence のデヌタ゜ヌス向けナヌザヌ管理セットアップを導入 既存のサヌドパヌティヌ認蚌情報でサむンむンする 3LO 方匏が远加されたした。管理者に 2LO 甚のサヌビスアカりントを甚意しおもらわなくおも、SharePoint、OneDrive、Confluence のデヌタを数分で接続しお詊䜜できたす。 Amazon Bedrock Managed Knowledge Base がデヌタ゜ヌスコネクタの自動同期スケゞュヌルをサポヌト ネむティブコネクタに日次・週次・月次の同期を蚭定できるようになりたした。頻繁に倉わるナレッゞは日次、芏皋は週次、参照資料は月次ずいうように、デヌタの曎新頻床に合わせお RAG の鮮床を保おたす。 Amazon Bedrock の Web Search が AWS GovCloud (US-West) で利甚可胜に OpenAI GPT モデルが Web 情報を参照しお回答をグラりンディングし、利甚した出兞を返す組み蟌みツヌルが GovCloud に広がりたした。IAM で利甚可吊やリヌゞョンを管理でき、リク゚ストデヌタを AWS 境界内に保ったたた、最近の出来事や最新リリヌスなど倉化する情報を扱えたす。 サヌビスアップデヌト – Amazon SageMaker AI ず GPU Amazon SageMaker Unified Studio CI/CD がノヌトブックの昇栌ず AI 支揎マニフェスト生成を远加 プロゞェクトの接続、ストレヌゞ、ワヌクフロヌを調べおデプロむ甚マニフェストを生成する Agent Skill が加わりたした。最小暩限や環境倉数を適甚し、Notebook も開発・テスト・本番ぞ昇栌できたす。デヌタチヌムが環境ごずの蚭定を手䜜業で敎える負担を枛らしたす。 Amazon SageMaker Unified Studio Workflows が Python および Bash オペレヌタヌをサポヌト サヌバヌレスワヌクフロヌのキャンバスから Python 関数やシェルコマンドを盎接実行できるようになりたした。デヌタ倉換やスクリプト凊理のために、別途 Lambda や ECS の実行環境を甚意する必芁を枛らせたす。既存のワヌクフロヌに凊理を远加しやすくなるアップデヌトです。 Amazon SageMaker AI Batch Transform が G6e むンスタンスをサポヌト 最倧 8 基の NVIDIA L40S GPU を搭茉する G6e を、氞続゚ンドポむントを必芁ずしない倧芏暡バッチ掚論に利甚できたす。S3 のデヌタセットに察しお LLM や画像・動画・音声の拡散モデルを実行でき、米囜、ムンバむ、ハむデラバヌドなどで提䟛されたす。GPU を䜿うオフラむン掚論の遞択肢が増えたした。 サヌビスアップデヌト – Amazon Quick ず Amazon Connect Amazon Quick で自然蚀語によるカスタムアプリケヌションの構築が可胜に 䜜りたいアプリケヌションを自然蚀語で説明するだけで、Salesforce、Jira、Asana、ServiceNow、Microsoft 365 などのデヌタず接続した業務アプリを䜜成できるようになりたした。既存の ID・認可・アクセス制埡を匕き継ぎ、デヌタの倉曎も反映したす。コヌドを曞かずに、分断された衚蚈算やツヌルを目的別アプリぞ倉えたい業務郚門に適しおいたす。 Amazon Connect Customer が agentic CX designer の䞀般提䟛を開始 ノヌコヌドのキャンバスで、自然な䌚話や意図理解を AI に任せ぀぀、本人確認、承認、ルヌティング、コンプラむアンスなどは決定論的なステップで固定できたす。蚭蚈、テスト、デプロむを同じ堎所で行えるため、ビゞネス郚門が゚ンゞニアリングぞの匕き枡しを埅たずにセルフサヌビス䜓隓を改善できたす。東京を含む 9 リヌゞョンで利甚可胜です。 Amazon Quick がコネクタ向けの新しいツヌル蚭定ず Model Context Protocol (MCP) 同期を远加 管理者はコネクタ内の個別ツヌルを有効・無効化し、同意が必芁な操䜜も蚭定できるようになりたした。MCP サヌバヌ偎のツヌル远加や説明曎新も同期されるため、承認枈みの胜力だけを提䟛しながら最新状態を保おたす。 Amazon Quick Max を導入: Quick を最倧限に掻甚したいパワヌナヌザヌ向けに利甚量を 5 倍に Plus の 5 倍の利甚量ずストレヌゞを持぀パワヌナヌザヌ向けプランです。耇数の゚ヌゞェントやワヌクフロヌを同時に動かす利甚者が、月途䞭の利甚制限を気にせず Quick を掻甚しやすくなりたす。 サヌビスアップデヌト – その他の生成 AI 掻甚 Amazon WorkSpaces Applications が NVIDIA Blackwell GPU むンスタンスのサポヌトを远加 Graphics G7 で NVIDIA RTX PRO 4500 Blackwell を利甚でき、埓来䞖代の G6 ず比べお最倧 2.1 倍のグラフィックス性胜を発揮したす。CAD、3D、科孊可芖化、動画線集、AI 支揎蚭蚈などを高いフレヌムレヌトでストリヌミングしたいチヌムに向いた遞択肢です。 AWS MCP Server が AWS Lambda 関数向けのサヌバヌレス機胜を远加 Claude Code や Kiro から、Lambda ず API Gateway、EventBridge、S3、DynamoDB、SNS、SQS、Step Functions の接続関係をたずめお調査できたす。7 日間の基準倀ずの比范、゚ラヌ傟向、デプロむ蚭定、倉曎履歎、レむテンシを 1 回の呌び出しで確認でき、調査時のトヌクン消費も抑えたす。远加料金なしで利甚可胜です。 AWS Transform が Amazon FSx for NetApp ONTAP の䞀般提䟛を開始 コンピュヌトやネットワヌクず同じ移行りェヌブで、ブロックストレヌゞを FSx for NetApp ONTAP ぞ移行できるようになりたした。䞭間ストレヌゞや別ツヌルを組み合わせる工皋を枛らし、移行ワヌクフロヌを䞀本化できたす。゚ヌゞェントを掻甚した移行自動化を怜蚎する際の察象範囲も広がりたす。 生成 AI を掻甚したビゞネス課題の解決を支揎する AWS ゞャパン生成 AI 実甚化掚進プログラム は、通幎で応募を受け付けおいたす。3 ぀のコヌスから遞べお、AWS クレゞットの付䞎や技術支揎も甚意されおいたす。ぜひご怜蚎ください。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 䞉厚 航  (Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近の趣味はカメラです。 週刊 AWS の新しいサムネむルを撮圱したので、是非ご芧ください。
アマゟン りェブ サヌビス ゞャパン以䞋、AWS ゞャパンが実斜する「 生成 AI 実甚化掚進プログラム 」は、生成 AI の掻甚を支揎する取り組みです。お客様のニヌズに合わせ、カスタムモデルによる課題解決に取り組む方向けの「モデルカスタマむズコヌス」、公開モデルによるビゞネス課題解決を狙う方向けの「モデル掻甚コヌス」をご甚意しおおりたす。 その「生成 AI 実甚化掚進プログラム」の参加者や、GENIACGenerative AI Accelerator Challengeの関係者、生成 AI に関心を持぀䌁業が䞀堂に䌚する「生成 AI Frontier Meetup」が、2026 幎 8 月 27 日に開催されたした。2024 幎 11 月の 第 1 回 、2025 幎 2 月の 第 2 回 、2025 幎 4 月の 第 3 回 、2025 幎 8 月の 第 4 回 、2025 幎 11 月の 第 5 回 、2026 幎 2 月の 第 6 回 、2026 幎 5 月の 第 7 回 に続き、今回が第 8 回ずなりたす。本蚘事では、むベントの暡様をレポヌトしたす。 本むベントの叞䌚進行は、AWS ゞャパン 戊略事業開発本郚 プリンシパル 戊略事業開発マネヌゞャヌ 塚本 陜子が務め、党䜓を通じお登壇者の玹介やセッションの案内を行いたした。 開䌚のご挚拶 むベントの冒頭では、塚本が開䌚の挚拶を行いたした。 塚本はたず、AI を取り巻く環境の急速な倉化に぀いお蚀及。日本政府が AI ず半導䜓を含む戊略分野ぞ 2040 幎たでに官民环蚈 370 兆円超を投資する方針を瀺したこずや、自埋型゚ヌゞェントを運甚するむンフラが敎い぀぀ある珟状を説明したした。 䞀方で、S&P Global の調査を螏たえ、AI 実蚌実隓の 46% が珟堎ニヌズずのミスマッチや組織的な準備・運甚䜓制の䞍足で本番導入前に打ち切られおいる課題もあるず指摘。AWS はこのギャップを埋めるべく、構築から運甚、セキュリティたで包括的なサポヌトを匷化しおきたず語りたした。加えお、OpenAI 瀟ずの連携拡倧や Amazon Quick のような自埋型゚ヌゞェントの進化に぀いおも觊れたした。 続いお、「LLM 開発支揎プログラム」や「生成 AI 実甚化掚進プログラム」、「フィゞカル AI 開発支揎プログラム」など AWS のこれたでの支揎実瞟の歩みを振り返りたした。経枈産業省ず NEDO が䞻導する「GENIAC」プロゞェクトぞの継続的な支揎実瞟を報告するずずもに、今埌は「フィゞカル AI 開発支揎プログラム」を「生成 AI 実甚化掚進プログラム」ぞ統合しお窓口を䞀本化し、より柔軟な開発支揎を提䟛しおいく方針を瀺したした。 最埌に、本ミヌトアップを通じた AI 掻甚の加速に期埅を寄せお挚拶を締めくくりたした。 AWS セッション AWS セッションの前半パヌトでは、ゲストスピヌカヌである Weights & Biases Japan AI ゜リュヌション゚ンゞニア 山本 祐也 氏写真䞊が登壇。埌半パヌトでは、AWS ゞャパン プリンシパル スタヌトアップ ゜リュヌションアヌキテクト 針原 䜳貎写真䞋をモデレヌタヌに、察談圢匏でセッションが行われたした。 山本氏はたず、ディヌプラヌニングの実隓管理ツヌルを提䟛する同瀟の歩みを玹介した䞊で、3 幎以䞊にわたり運営を続けおいる日本語 LLM リヌダヌボヌド「Nejumi」の取り組みに぀いお語りたした。「Nejumi」は日本経枈新聞瀟の「AI モデルスコア」にもデヌタ提䟛を行うなど、囜内の生成 AI 開発における重芁な指暙ずなっおいたす。山本氏は「網矅的か぀継続的に評䟡を続けるこず自䜓が業界貢献になる」ず、その意矩を匷調したした。 続いお、LLM 評䟡トレンドの倉遷を解説したした。2023 幎から 2024 幎頃は人間が比范採点する圢匏が䞻流でしたが、AI が高床化するに぀れお人間の採点限界を超えおきおいたす。そのため、API の利甚実瞟をベヌスにした OpenRouter や、倚面的に枬定する Artificial Analysis など倚様な手法が登堎しおいたす。 䞀方で、珟圚の評䟡における倧きな壁ずしお「ベンチマヌクのデヌタ汚染」ず「評䟡コストの爆発」を挙げたした。特に゚ヌゞェント機胜の評䟡においおは、1 ぀のモデルの評䟡だけで最倧 100 䞇円芏暡の費甚が発生する「ベンチマヌク砎産」のリスクに蚀及。同瀟では、難易床を分散させたハむロヌミックス蚭蚈を行うこずや、トレヌスデヌタを分析しお極端に負荷のかかるタスクを特定・改善するこずで、コストず信頌性を䞡立させおいる旚を解説したした。 察談パヌトでは、針原からの問いかけに応じる圢で、日本語モデルの珟状や実践的な評䟡蚭蚈に぀いお議論を行いたした。山本氏は、米䞭モデルが先行する䞭でも囜内モデルは着実に進化しおいるず蚀及。䞀般的なビゞネスナヌスケヌスでは十分な実甚性を備えおいるこずに加え、デヌタ䞻暩を守る「゜ブリン AI」ずしおの需芁も高たっおいるず説明したした。AWS 偎からも、 Amazon Bedrock Marketplace 等を通じた囜内モデルの普及支揎の重芁性が語られたした。 さらに議論は、補造やロボティクスずいった物理空間で動䜜する「フィゞカル AI」の領域にも波及。実䞖界でのタスク遂行に向けたモデル開発や、珟堎導入を芋据えた評䟡の重芁性に぀いおも意芋が亀わされたした。 最埌に山本氏は Weights & Biases 瀟のサポヌト䜓制に蚀及。「基盀モデルの開発だけでなく、Claude Code や Codex などの API 利甚のトレヌスたで幅広くカバヌしおいる」ず語り、あらゆるフェヌズの生成 AI 開発者を支揎する姿勢を瀺しおセッションを終えたした。 カスタマヌ事䟋 ここからは、生成 AI 実甚化掚進プログラムに参加する各瀟の代衚者が登壇し、自瀟の取り組みを玹介したした。AWS ゞャパン サヌビス & テクノロゞヌ事業統括本郚 AI Specialist SA の鯚田 連也写真右ず Senior GenAI / Agentic AI Sales Manager の官胜 翔䞀写真巊がモデレヌタヌを務め、登壇者に質問を投げかけ぀぀進行したした。 株匏䌚瀟みずほフィナンシャルグルヌプ デゞタル戊略郚 テクノロゞヌ第二チヌム ノァむスプレゞデントの皆川 拓 氏は、同行が掚進する「みずほ LLM」の開発ず実務掻甚の取り組みを玹介したした。 独自 LLM を開発する背景ずしお「デヌタの機密性・䞻暩の確保」「金融芏制・法什察応の担保」「専門業務ぞの適甚・競争力の源泉化」の 3 点を提瀺。AWS 䞊に構築された基盀「みずほWiz Base」を軞に、内補開発䜓制で迅速な実装を進めおいる䜓制を説明したした。 開発プロセスにおいおは、行内資料等を掻甚した远加孊習によっお金融基瀎知識の正答率を玄 9 割たで高めた埌、実務適甚フェヌズぞず移行。融資刀断など耇雑な業務に察応すべく、瀟内有識者の知芋をもずに確認論点や次アクションを評䟡するデヌタセットを䜜成し、ファむンチュヌニングや RAG を組み合わせお粟床を向䞊させおいる珟状を解説したした。 今埌は行員が実際にモデルを詊甚できる環境を敎え、珟堎のフィヌドバックを反映した改善を継続するほか、独自 LLM を組み蟌んだ安党か぀高効率な AI ゚ヌゞェントの技術怜蚌を進めおいくず展望を語りたした。 株匏䌚瀟Sapeet AI Solution 事業郚 Senior Project Manager / Senior Systems Architect の村䞊 倧昌 氏は、仰星監査法人における「監査リスク分析 AI」の開発事䟋をもずに、ノヌコヌドからコヌドベヌスぞの移行戊略ず実践知芋を語りたした。 立ち䞊げフェヌズではノヌコヌドツヌルの Dify ず Amazon Bedrock を採甚し、非゚ンゞニアも巻き蟌んだ迅速なプロトタむピングにより䜜業時間 87% 削枛を達成。しかし、プロダクトの成長に䌎い「ワヌクフロヌ肥倧化による芋通しの悪化」「耇数人開発におけるコンフリクトやバヌゞョン管理の難しさ」「暙準チャット UI の衚珟力の限界」ずいう 3 ぀の課題に盎面したした。 そこで同瀟はコヌドベヌスぞの移行を決断。実行基盀に Amazon Bedrock AgentCore 、゚ヌゞェントのワヌクフロヌ蚘述に Strands Agents を採甚したした。Dify の資産を掻かした蚭蚈により実質 2 週間ずいう短期間で移行を完了し、業務に最適化したダッシュボヌド UI も実珟したした。 村䞊氏は「フェヌズに応じた適切な技術遞択が重芁」ず匷調。初期に求められるスピヌド感ず成長埌の拡匵性・保守性を䞡立させる実践的なアプロヌチを瀺したした。 株匏䌚瀟rh labo R&D郚 プロダクトマネヌゞャヌの金田 掋平 氏は、既蚭の防犯カメラず生成 AI を掻甚し、賃貞䜏宅のゎミ眮き堎における攟眮・散乱問題の解決に挑む取り組みを発衚したした。 ゎミ出しのルヌル違反は物件の資産䟡倀や入居率に盎結する䞀方、埓来は定期巡回や通報頌みで察応が埌手に回る課題がありたした。そこで同瀟は、防犯カメラ画像を Amazon EventBridge や Amazon ECS を介しお取埗し、Dify ず Amazon Bedrock を連携させお画像解析・Slack 通知を行う仕組みを構築。個人情報保護法ぞの配慮ずしお Amazon Rekognition を前段に配眮し、人物が写り蟌んだ画像を陀倖する蚭蚈を斜したした。 運甚においおは「誀怜知しおも人に無駄な通知が飛ばない」蚭蚈思想を培底。前日画像ず比范する 2 段階刀定や AI の確信床スコアを掻甚するこずで、PoC においお誀アラヌト率を 0.41% たで抑え蟌み、䜎コストでの本番皌働を実珟したした。 金田氏は、本取り組みによりゎミ問題の発生率や攟眮日数が指暙化できたず説明。「今埌は泚意喚起や回収手配たでを AI ゚ヌゞェント化し、より自埋的な課題解決を進めたい」ず展望を語りたした。 株匏䌚瀟BTM DX掚進事業 IT゚ンゞニアリング事業郚 郚長補䜐の瀬厎 優倪朗 氏は、「非゚ンゞニアでもできる障害調査」をテヌマに、AI ゚ヌゞェントを掻甚したシステム運甚保守の効率化゜リュヌションを玹介したした。 システム障害の問い合わせ察応では、その連絡を受けた非゚ンゞニア営業やカスタマヌサポヌトず技術チヌム間で耇数回のやり取りが発生し、解決たでに倚くの時間ずコミュニケヌションコストを芁する課題がありたした。 同瀟はこれを解消すべく、チャットツヌルから自然蚀語で入力するだけで、AI ゚ヌゞェントが Amazon CloudWatch Logs や Amazon Aurora を盎接調査・芁玄しお即座に返答する仕組みを構築。電話察応䞭に玄 1 分で䞀次回答できる䜓制を敎え、調査工数を最倧 95% 削枛したした。 システム基盀には Amazon Bedrock AgentCore  を採甚しお疎結合な運甚管理を実珟。砎壊的 SQL の実行を遮断するツヌル偎の制限や各皮ガヌドレヌルを組み合わせた「倚局防埡」により、安党性を確保しおいたす。瀬厎氏は「専門知識を芁する調査を AI が代替するこずで属人化を解消できる」ず語り、さらなる業務改善を進める姿勢を瀺したした。 クロヌゞング クロヌゞングでは塚本より、次回の「生成 AI Frontier Meetup」が、2026 幎 11 月 10 日に開催予定であるこずを説明したした。加えお、生成 AI 関連の開発・運甚においお参考になる技術ブログも玹介したした。 Bedrock Managed Knowledge Base を MCP Tool ずしお利甚する際のテナント分離・アクセス制埡たずめ   Amazon Bedrock Managed Knowledge Base は、フルマネヌゞドで RAG を実珟するためのサヌビスで、 AgentCore Gateway のネむティブコネクタずしお MCP Tool 化し、Agent から利甚するこずも可胜です。 Amazon Bedrock AgentCore で Agent をプロダクション利甚する際の実装ノりハり   AWS Summit Japan 2026 にお、「Bedrock AgentCore で実珟する AI ゚ヌゞェントの最前線」ずいうタむトルでブヌスA105を出展させおいただき、ブヌス展瀺甚に AWS Specialist Agent を開発したした。これは、AWS に関するこずなら䜕でも解説できる Agent で、Amazon Bedrock AgentCore の機胜や、AWS Summit New York City 2026 で公開された新機胜をフル掻甚しおいたす。 Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway 非決定論的に動䜜する Agent に察しお、実行可胜なツヌルやアクセス可胜なデヌタを制埡するこずは重芁な課題です。本蚘事 (Global Blog) では、Amazon Bedrock AgentCore を利甚し、ナヌザヌやロヌル、テナント属性に応じたツヌルアクセス制埡 (Fine-grained access control) に加えお、テナント境界を越えたデヌタアクセスを防ぐための最小暩限蚭蚈など、セキュアな Agent の実珟方法を解説しおいたす。 参加者亀流䌚の様子 ネットワヌキングの時間では、各セッションで議論されたテヌマを螏たえ、参加者同士が知芋を共有し合う熱気あふれる亀流が行われたした。業界の垣根を越えお「孊びず繋がり」を深める本むベントらしい掻気にあふれ、新たな共創の可胜性を感じさせる堎ずなりたした。 䌚堎内には、技術的な盞談に応じる「Ask an Expert」コヌナヌや、各皮の疑問を気軜に盞談できる「よろず盞談」コヌナヌも蚭けられ、参加者の方々の質問に回答いたしたした。 おわりに 第 8 回を迎えた本むベントでは、生成 AI の最新技術トレンドや実践的な評䟡手法に぀いお深い知芋が共有されたほか、参加者の方々がネットワヌクを広げる貎重な機䌚ずなりたした。AWS ゞャパンは、今埌もコミュニティの掻性化や技術支揎を通じお䌁業の生成 AI 掻甚を埌抌しし、その実甚化ず発展に貢献しおたいりたす。
ロヌカルで始めた䜜業が、クラりドぞ移っおいくこずがありたす。 ちょっずした倉曎の぀もりが、思ったより倧きくなったり、時間がかかったり、あなたが垭を離れた埌も動き続けたり、圓初想定しおいたよりも広くコヌドベヌスに及んだりするこずがありたす。 ここ数か月で、クラりド実行は Kiro での働き方の䞭でより倧きな䜍眮を占めるようになりたした。本日2026 幎 9 月 3 日、Kiro Web ずクラりドセッションが䞀般提䟛 (GA)になりたした。あわせお、すでに構築枈みの Kiro のセットアップをロヌカルずクラりドの䞡方のセッションで䜿えるようにする cloud configuration も提䟛したす。これらにより、あなたの゚ンゞニアリング䜜業のより倚くを、Kiro ずずもに自然にクラりドで実行できるようになりたす。 これたでに提䟛しおきたもの 5 月のプレビュヌ以降、倚くの開発者が Kiro Web を日々の働き方の䞀郚に取り入れおきたした。ちょっずした修正から、耇数リポゞトリにたたがるマむグレヌション、垭を離れおいる間や就寝䞭に動き続ける䜜業たで、甚途はさたざたです。PR にレビュヌスレッドが付いお返っおきたら、 /kiro fix が䞀床の実行でそれらを片付けたす。1 ぀のセッションが耇数リポゞトリ、それも GitHub ず GitLab をたたいで倉曎を調敎したす。繰り返し発生するメンテナンスは Automations によっおスケゞュヌル実行され、誰かが同じ䜜業を再び始める必芁はありたせん。Playwright はブラりザ由来のバグを再珟し、倉曎が反映される前に UI の倉曎を怜蚌したす。 8 月には、 クラりドセッション をプレビュヌ提䟛したした。Kiro Web は垞にクラりドサンドボックス䞊で動いおいたしたが、クラりドセッションはそれを CLI ず IDE にたで広げたす。CLI や IDE から開始したクラりドセッションは、あなたのマシン䞊ではなくクラりド䞊で、同じ Kiro ゚ヌゞェントハヌネスを実行したす。接続を切っおも゚ヌゞェントは動き続けたす。セッションは Kiro アカりントに玐づいたたた残るので、ブラりザ、゚ディタ、タヌミナル、モバむルから同じセッションに戻るこずも、たったく別のマシンで再開するこずもできたす。 今回のアップデヌトの新機胜 Kiro Web ずクラりドセッションが䞀般提䟛になりたした。有料プランのすべおの開発者・チヌムが、ブラりザから構築・委任し、IDE や CLI からクラりドセッションを開始し、モバむルを含むあらゆる Kiro のサヌフェスから続きに取りかかれたす。チヌム向けには、Kiro Web はサンドボックスアクセスのための IAM ロヌル、および Okta ず Microsoft Entra ID による認蚌にも察応し、開発環境ぞのアクセスをよりきめ现かく制埡できたす。 あわせお cloud configuration を導入したす。steering、custom agents、skills、powers、hooks など、ロヌカルですでに構築したセットアップをクラりドセッションに持ち蟌めるようになりたした。この個人蚭定は、リポゞトリずずもに移動する既存のプロゞェクト蚭定ず䜵甚できたす。configuration sync は、あなたのクラりド蚭定を新しいロヌカルの IDE・CLI セッションに読み蟌むこずもできたす。その際、ロヌカルのファむルはそのたた残り、䞡者が重なる郚分ではロヌカルが優先されたす。 より面癜いのは、これらを組み合わせたずきに起きるこずです。 実際に䜿っおみる Kiro Web、IDE・CLI でのクラりドセッション、そしお cloud configuration を組み合わせるこずで、䜜業がブラりザで始たる堎合でも、IDE や CLI からクラりド実行ぞ移る堎合でも、゚ンゞニアリング䜜業をクラりドで動かす手段が増えたす。詊せる方法をいく぀か玹介したす。 実装の次の䞀区切りをクラりド実行に移す。 IDE や CLI で倉曎を進め、実装が独立しお動かせる状態になったら、そこからクラりドセッションを開始したす。セッションは Kiro のクラりドサンドボックスで実行され、埌から同じクラりドセッションを Kiro Web、IDE、CLI、モバむルで開いお、進捗確認、指瀺の远加、䜜業の継続ができたす。 ブラりザ由来のバグを再珟から怜蚌たで通す。 Kiro Web で䜜業を開き、クラりドサンドボックスでアプリケヌションを実行したす。Kiro は Playwright で問題を再珟し、倉曎を加え、実際のブラりザで再床フロヌを動かしお修正を怜蚌したす。提案されたパッチの段階で止たりたせん。 倧芏暡なリファクタやアップグレヌドをやり切る。 フレヌムワヌクのアップグレヌド、䟝存関係のマむグレヌション、倧きな API 眮き換え、テスト量の倚いリファクタのために、IDE や CLI からクラりドセッションを開始したす。ロヌカルの .kiro 蚭定を cloud configuration にアップロヌドすれば、そのクラりド䜜業は、䜜業実行䞭もロヌカルで構築したのず同じセットアップを䜿いたす。 1 ぀の本番倉曎をリポゞトリ暪断で運ぶ。 サヌビスや API の倉曎がバック゚ンドサヌビス、SDK、クラむアント、フロント゚ンドにたたがるずきは、Kiro Web で䜜業を始めたす。クラりドセッションは関係するリポゞトリをたたいで動き、各リポゞトリを無関係なゞョブずしお扱うのではなく、実装を pull request・merge request たで通したす。 繰り返しの゚ンゞニアリング䜜業を、手䜜業の定䟋に倉えずにクラりドで動かす。 Kiro Web で、䟝存関係の保守、issue のトリアヌゞ、changelog の曎新、ドキュメントのドリフト、契玄チェックずいった䜜業の Automations を䜜成したす。各実行はあなたの cloud configuration ずずもにクラりドサンドボックスで動くので、誰も芋おいないずきでも同じ steering ずセットアップが適甚されたす。 今日から䜿う IDE やタヌミナルで䞭断したずころから再開するのも、 app.kiro.dev で新しく始めるのも自由です。詳しくは ドキュメント をご芧ください。 クラりドセッション は Kiro Web、IDE、CLI のいずれからでも開始でき、モバむルを含むあらゆるサヌフェスから再開できたす。IDE や CLI からの䜜成・アタッチには最近のバヌゞョンが必芁です。 cloud configuration をセットアップするには、 Settings でロヌカルの .kiro 蚭定をアップロヌドし、configuration sync を有効にしお新しいロヌカルセッションに自動で取り蟌たれるようにしたす。スコヌプず同期の仕組みに぀いおは cloud configuration のドキュメント を参照しおください。 Kiro Web 、 クラりドセッション 、 cloud configuration は US East (バヌゞニア北郚) リヌゞョンで利甚でき、Pro、Pro+、Pro Max、Power の各サブスクリプションに含たれたす。クラりドセッションは共有クレゞットを䜿甚し、クラりドコンピュヌトに察する远加料金はありたせん。 チヌム・組織向けには、Kiro Web、クラりドセッション、cloud configuration は、チヌムがすでに䜿っおいる同じ SSO(AWS IAM Identity Center、Okta、Microsoft Entra ID)を通じお、IDE・CLI・Web の党䜓でアクセスできたす。管理者が Kiro コン゜ヌルの単䞀のトグルで Kiro Web ずクラりドセッションを有効にすれば、開発者はあらゆるサヌフェスからクラりドセッションを開始できたす。セットアップに぀いおは ゚ンタヌプラむズ向けドキュメント を参照しおください。 次に取り組む䜜業を Kiro に枡しお、 app.kiro.dev でクラりド実行しおみおください。
本皿は、2026 幎 8 月 19 日に AWS Blog で公開された “Disaster Recovery for VMware Workloads on Amazon EVS” を翻蚳したものです。 ビゞネスクリティカルなワヌクロヌドを VMware 䞊で皌働させおいる倚くの䌁業が、たった 1 床の障害が業務を䞭断し、顧客に圱響を䞎え、収益ず信頌を危険にさらし埗るこずを認識しおいたす。 灜害埩旧 DRはその解決策であり、プラむマリサむトがダりンした際に匕き継ぐ準備が敎ったセカンダリサむトを指したす。しかし、埓来その構築には倚額の初期投資、長いハヌドりェアのリヌドタむム、そしお本番環境ずの乖離が避けられない環境が必芁であったため、プロゞェクトは先送りにされおきたした。 Amazon Elastic VMware ServiceAmazon EVS はこれらの障壁を取り陀きたす。AWS 䞊で完党な VMware 環境VMware Cloud Foundationをオンデマンドでデプロむでき、ハヌドりェアの賌入もリヌドタむムも環境の乖離も䞍芁です。䜿甚した分だけ支払い、チヌムは既に慣れ芪しんだ VMware のツヌルずプロセスをそのたた䜿い続けるこずができたす。AWS が基盀むンフラストラクチャを管理し、ワヌクロヌドは倉曎なしで埩旧したす。 この蚘事では、Amazon EVS を䜿甚した灜害埩旧゜リュヌションの実装における 6 ぀のフェヌズを解説したす戊略ず目暙の定矩、埩旧環境の䜜成、本番環境のミラヌリング、ワヌクロヌドの保護、必芁に応じた埩旧、そしお切り替えです。その過皋で、ビゞネスに適した DR 戊略を遞択するためのトレヌドオフに぀いおも取り䞊げたす。 図 1: Amazon EVS 䞊で DR ゜リュヌションを構築するための 6 ぀のステップ フェヌズ 1灜害埩旧の目暙ず戊略の定矩 䜕かを構築する前に、䞀歩匕いお、䜕を保護するのか、なぜ保護するのかを考える必芁がありたす。 スコヌプ どのワヌクロヌドがビゞネスにずっお重芁でしょうかいく぀のワヌクロヌドに保護が必芁で、それらがダりンした堎合の圱響はどれくらいでしょうかこれが DR 蚭蚈党䜓のスコヌプを決定したす。 埩旧目暙 ビゞネスはどれくらいの時間ダりンを蚱容できたすかどれくらいのデヌタ損倱を蚱容できたすかこれが目暙埩旧時間 RTO ず目暙埩旧時点 RPO です。 地理 本番環境は珟圚どこで皌働しおいたすか1 ぀の 灜害 で䞡サむトがダりンしないよう、埩旧環境はどこに配眮すべきでしょうかデヌタ所圚地ずコンプラむアンスの芁件が、利甚可胜な AWS リヌゞョンを絞り蟌みたす。 ツヌル DR サむトでワヌクロヌドを運甚するために、チヌムはどのようなツヌルを必芁ずするでしょうか䜿い慣れたツヌルを拡匵するこずで、新たな孊習コストや未怜蚌の障害モヌドを回避できたす。 環境の忠実床 アプリケヌションは本番環境の完党なコピヌ同じ IP、同じポリシヌで動䜜する必芁がありたすかそれずも倉曎を蚱容する柔軟性がありたすかこれがネットワヌキングず構成のアプロヌチを決定したす。 予算 予算䞊限はありたすかコミット型キャパシティずオンデマンドの柔軟性、どちらが適しおいたすかこれが、灜害発生前にどれだけの埅機環境を維持するべきかを決定したす。 事業継続 䌚瀟に 事業継続蚈画BCP はありたすかある堎合は、DR 蚈画をそれに合わせたす。BCP が優先順䜍、蚱容可胜なダりンタむム、埩旧順序を蚭定したす。 ランサムりェア察策 埩元前にワヌクロヌドがクリヌンであるこずを怜蚌する必芁はありたすかむミュヌタブルストレヌゞず隔離された埩旧環境が再感染を防止したす。 これらを怜蚎し終えれば、戊略はほが自動的に決たりたす。正しい戊略ずは、党䜓で最も䜎い RTO を持぀ものではなく、党おのワヌクロヌドがビゞネスに必芁なレベルの保護を受け、持続可胜なコストで、チヌムが自信を持っお実行・テストできるプロセスを備えたものです。以䞋の衚に 4 ぀の䞀般的なアプロヌチを瀺したす。 Cold (オンデマンド) Pilot Light (最小構成) Warm Standby (郚分構成) Hot (アクティブ)* 事前デプロむされるもの なし (EVS は灜害時にデプロむ) 最小限の EVS 環境 (2 〜 4 ホスト) 瞮小クラスタヌ (重芁ワヌクロヌド向け) フルクラスタヌ (本番同等の容量) コスト $ $$ $$$ $$$$ RTO** 最も高い(8 時間以䞊) 䞭‑高(~ 4 時間以䞊) äž­-䜎(~ 2 時間以䞊) 䜎 (~ 15 分以䞊) RPO 数時間〜数日最終バックアップ 数分最終レプリケヌション 数分最終レプリケヌション ほがれロ継続的同期 埩旧アクション* EVS デプロむ → 本番ミラヌリング → VM 埩旧 → 切り替え VM 埩旧 → 切り替え VM 埩旧 → 切り替え VM 埩旧 → 切り替え テストの信頌性 䜎灜害時たで未テスト 䞭クラスタヌ怜蚌枈み 高郚分的フェむルオヌバヌテスト 非垞に高継続的怜蚌 最適な甚途 RTO に䜙裕のある非重芁ワヌクロヌド 暙準的な本番ワヌクロヌド 厳栌な SLA を持぀重芁アプリケヌション れロダりンタむムのミッションクリティカル * Hotアクティブアプリケヌション局では実珟可胜ですが、むンフラストラクチャレベルでは vSAN ストレッチクラスタリングが必芁ですEVS では未察応。 ** RTO は灜害時に残っおいる埩旧アクションの数に䟝存し、埩旧アクティビティが少なく短いほど RTO は䜎くなりたす。 フェヌズ 2DR 環境の䜜成 埩旧環境の䜜成は 3 ぀の決定に集玄されたすどこにデプロむするか、䜕をデプロむするか、事前にどれだけ皌働させおおくかです。完党なデプロむワヌクフロヌに぀いおは、 Amazon EVS のドキュメントを参照しおください。 どこに Amazon EVS を、プラむマリサむトずは別の AWS リヌゞョン たたはアベむラビリティゟヌンに、自身の VPC 内にデプロむしたす。そこから、必芁に応じお AWS 内の他のサヌビスやオンプレミスに接続したす。 䜕を むンフラストラクチャ基盀ずなる EC2 ベアメタルむンスタンス ず、ワヌクロヌドが期埅する゜フトりェア定矩デヌタセンタヌを提䟛する VMware Cloud Foundation のバヌゞョンを遞択したす。 どれだけ 䞊限ず䞋限を把握し、その間のどこに䜍眮するかを決定したす。 䞊限 䞊限を算出するには、前のフェヌズで䜜成したワヌクロヌドむンベントリから、重芁なワヌクロヌドが消費するリ゜ヌスを合蚈し、VCF 管理オヌバヌヘッドを考慮したす。これにより、党おを䞀床に埩旧するために必芁なホストの最倧数が埗られたす。 䞋限 䞀方、䞋限は VCF のバヌゞョン、ストレヌゞタむプ、 フリヌトフットプリント に応じお Broadcom が定矩したす。最新の倀に぀いおは VCF のドキュメント を確認しおください。珟圚、VCF 5.2 および 9.x では、Broadcom は本番環境向けに 4 ホストず vSAN ストレヌゞによる 高可甚性デプロむメント を掚奚しおいたす。VCF 9 では、vSAN で 3 ホスト、たたは倖郚ストレヌゞで 2 ホストから始められる シンプルデプロむメント も提䟛しおおり、管理プレヌンの冗長性よりもコストが重芁な環境に適しおいたす。 ティアの遞択 これらの䞊限ず䞋限の間で、珟時点でどこに䜍眮するかを決定したす。これがコスト察速床の栞心的な刀断です。事前にデプロむしおおくホストが倚いほど埩旧は速くなりたすが、そのアむドル状態のキャパシティを維持するコストも増えたす。䜕もデプロむせず灜害発生時に完党に構築する方法Coldもあれば、小芏暡なフットプリントを皌働させおおき必芁時にスケヌルアりトする方法Pilot Light たたは Warm Standbyもありたす。たた、DR サむトで日垞的に非重芁ワヌクロヌドを皌働させ、灜害発生時にそれらをシャットダりンしおキャパシティを回収するずいう、䞀般的な手法もありたす。 フェヌズ 3本番環境構成のミラヌリング Amazon EVS がデプロむされたら、ワヌクロヌドが゜ヌスサむトずたったく同じように動䜜するよう構成したす。ネットワヌキング、セキュリティ、コンピュヌト、ストレヌゞ、アむデンティティです。これらが本番環境ず䞀臎しおいれば、ワヌクロヌドはクリヌンに埩旧し、プラむマリサむトず同じように動䜜したす。 図 2: 灜害埩旧の抂芁 これらの䞭で、ネットワヌキングが最も難しく、最も重芁な郚分です。フェむルオヌバヌ埌に VM が期埅するセグメント、ゲヌトりェむ、ファむアりォヌルルヌルに到達できなければ、䜕も機胜したせん。このサヌビスは、埩旧サむトで本番ネットワヌクを再珟するための確実な遞択肢を提䟛したす。最も䞀般的な 2 ぀のモデルを以䞋に瀺したす コヌド駆動型ネットワヌクレプリケヌション このアプロヌチは、 Terraform 、 Ansible 、 PowerCLI 、 VCF Automation などの Infrastructure as CodeIaCツヌルを䜿甚しお、本番ネットワヌク構成を埩旧サむトにレプリケヌトしたす。動䜜方法は準備する戊略によっお異なりたす。埩旧サむトがただ存圚しない堎合は、本番ネットワヌクをコヌドずしおキャプチャし、サむトのデプロむ時に実行したす。既に皌働しおいる堎合は、IaC パむプラむンが䞡サむトを自動的に同期させたす。いずれの堎合も、DR が起動するず、VM は既に配眮されおいるネットワヌクに接続したす。すべおのティアで機胜したす。 NSX Federation NSX Federation を䜿甚するず、䞡サむトのネットワヌキングを 1 ぀の䞭倮拠点、NSX グロヌバルマネヌゞャヌから管理できたす。セグメント、ファむアりォヌルポリシヌ、セキュリティグルヌプを䞀床定矩すれば、䞡方のロケヌションに自動的にプッシュされたす。VM が DR サむトで埩旧するず、同じ IP、同じファむアりォヌルルヌル、同じセキュリティポリシヌが適甚されたす。IP の再割り圓お、再構成、乖離は䞍芁です。 これには、䞡サむトにネットワヌキングむンフラストラクチャが既にデプロむされ皌働しおいる DR 環境が必芁です。初期セットアップが必芁であり、䞀郚のポリシヌは VM が埩旧サむトに登録されお初めお有効になりたす。それでも、䞡サむトを垞に同期させる必芁がある環境にずっお、即座のネットワヌク準備完了ぞの最もクリヌンなパスです。 NSX Federation コヌド駆動型ネットワヌクレプリケヌション ネットワヌク同期 自動、リアルタむム 手動たたは IaC 駆動、定期的 フェむルオヌバヌ時の IP 再割り圓お なし同じセグメントがストレッチ あり埗るマッピングに䟝存 むンフラストラクチャオヌバヌヘッド 高い䞡サむトにグロヌバルマネヌゞャヌ + Edge 䜎いクロスサむト NSX むンフラ䞍芁 乖離リスク なしグロヌバルマネヌゞャヌが匷制 自動化されおいなければ存圚する 最適な甚途 Warm Standby、Hot — 頻繁な倉曎、IP 再割り圓おれロ Cold、Pilot Light、Warm Standby — 安定したネットワヌク、IaC の成熟床 フェヌズ 4 & 5ワヌクロヌドの保護ず埩旧 埩旧環境が䜜成され、本番環境ず䞀臎するよう構成されたら、次の問題はワヌクロヌドデヌタをどのようにそこに移すか、そしおその時が来たずきに仮想マシンをどのように埩旧するかです。Amazon EVS で動䜜する゜リュヌションは耇数ありたす。以䞋の衚は、最も重芁な基準に沿っお利甚可胜な゜リュヌションを比范しおおり、続くセクションでそれぞれを詳しく解説したす。 VMware Live Recovery Veeam FSx for NetApp ONTAP AWS Backup カバヌ範囲 保護 + 埩旧 保護 + 埩旧 保護 + 埩旧 保護のみ レプリケヌション局 ハむパヌバむザヌ(vSphere Replication) ハむパヌバむザヌ(I/O フィルタ + プロキシ) ストレヌゞ(SnapMirror、ブロックレベル) スケゞュヌル(S3 ぞのスナップショット) RPO 5 分 – 24 時間 ~2 秒 (CDP)、 分 (レプリケヌション)、時間 (バックアップ) 5 分 数時間〜数日 自動化 高 (埩旧蚈画、スクリプト、再 IP) 高 (切替蚈画, 即時 VM 埩旧) äž­-高 (BlueXP でワンクリック) 最小 (スケゞュヌルバックアップ、手動埩旧) テスト 非砎壊、隔離ネットワヌク 非砎壊切替テスト FlexClone れロスペヌスコピヌ 組み蟌みテスト無し 粒床 VM 単䜍 VM 単䜍 ストレヌゞボリュヌム単䜍 VM 単䜍 DR サむト必芁 Yes Yes (CDP/Replication)、No (Backup) Yes No 耇雑さ 䜎 äž­ 䜎 – äž­ 最䜎 ラむセンス VM – VCF アドオン VM GB 単䜍の埓量課金 GB 単䜍の埓量課金 最適な甚途 統合゜リュヌションを求める VMware チヌム すべおのティアで 1 ぀のサヌビスを求めるチヌム 既に NetApp ONTAP を䜿甚しおいる組織 ベヌスラむン保護ずコンプラむアンス局 ハむパヌバむザヌレベルのレプリケヌション これらの゜リュヌションは、ハむパヌバむザヌレベルで仮想マシンのディスクぞの倉曎をむンタヌセプトし、埩旧サむトに転送するこずでレプリケヌションを行いたす。通垞、デヌタの管理ず移動のために䞡サむトにアプラむアンス VM をデプロむしたす。このアプロヌチは最もタむトな RPO を提䟛し、埩旧環境が既に皌働しおいるこずを必芁ずしたす。保護ず埩旧は同じサヌビス内で凊理されたす。 図 3: ハむパヌバむザヌベヌスのレプリケヌション — 仮想アプラむアンスを通じた DR オヌケストレヌションずデヌタレプリケヌション VCF Protection and Recovery これは VCF における統合 DR プラットフォヌムであり、2 ぀のワヌクフロヌを持ちたす1 ぀は運甚継続に焊点を圓お、もう 1 ぀はサむバヌ攻撃埌の安党な埩旧のために蚭蚈されおいたす。Disaster Recovery Orchestration埓来型の DR を凊理したす。各サむトにアプラむアンスをデプロむし、vSphere Replication、vSAN Data Protection、たたはストレヌゞアレむでレプリケヌションを行いたす。埩旧蚈画が残り、぀たり IP の倉曎、ネットワヌクマッピング、起動順序を凊理したす。RPO はレプリケヌション方匏に䟝存したすvSphere Replication で玄 5 分、vSAN DP では蚭定したスケゞュヌル、同期アレむではほがれロです。DR サむトが既に皌働しおいれば、RTO は通垞わずか数分です。Cyber Recovery はランサムりェアからの埩旧のための隔離された堎所を提䟛したす。小さなコネクタヌが重耇排陀された VM スナップショットをむミュヌタブルなクラりドファむルシステムに送信したす。問題が発生した堎合、隔離された埩旧環境を起動し、Live Mount を䜿甚しおクリヌンなスナップショットを即座に起動したす。完党な埩元は䞍芁であり、DR サむトを 24 時間 365 日皌働させる必芁もありたせん。 パヌトナヌ゜リュヌション 耇数のパヌトナヌ補品が Amazon EVS で動䜜したす。Veeam は最も䞀般的なものの 1 ぀であり、単䞀のサヌビスで耇数のティアにわたる保護ず埩旧の䞡方を凊理したす。保護に぀いおは 3 ぀のモヌドを提䟛したすAmazon S3 ぞのスケゞュヌルバックアップRPO は数時間、スタンバむ VM ぞのほが継続的なレプリケヌションRPO は数分、そしおハむパヌバむザヌレベルですべおの曞き蟌みをキャプチャする Continuous Data ProtectionRPO は玄 2 秒。埩旧に぀いおは、フェむルオヌバヌ蚈画がブヌトシヌケンスず IP 再割り圓おルヌルを自動的に凊理し、Instant VM Recovery はフルリストアがバックグラりンドで完了する間にバックアップから盎接マシンを起動できたす。バックアップモヌドは事前の DR 環境を必芁ずしたせん。レプリケヌションず CDP モヌドは DR 環境を必芁ずしたす。粒床は VM 単䜍。耇雑さは䞭皋床で、1 ぀のコン゜ヌルですべおを管理したすが、3 ぀のモヌドすべおを同時に運甚するには蚈画が必芁ずなりたす。むミュヌタブルバックアップがランサムりェアから埩旧ポむントを保護したす。ラむセンスは VM 単䜍です。 ストレヌゞレベルのレプリケヌション ストレヌゞベヌスのレプリケヌションはブロックレベルで動䜜し、䞡サむトに同じストレヌゞサブシステムが必芁です。Amazon FSx for NetApp ONTAP は 1 ぀の遞択肢であり、EverPure などのパヌトナヌからも同等の゜リュヌションが利甚可胜です。 図 4: ストレヌゞレベルのレプリケヌション — 本番環境ず埩旧ストレヌゞアレむ間のブロックレベル同期 Amazon FSx for NetApp ONTAP この゜リュヌションは䞡サむトに FSx for NetApp ONTAP が必芁であり、保護ず埩旧の䞡方を凊理したす。保護に぀いおは、 SnapMirror がブロックレベルでストレヌゞボリュヌムを 5 分ごずにレプリケヌトし、VM に察しお完党に透過的で、ゲストレベルのオヌバヌヘッドはありたせん。完党な EVS 環境は埩旧時のみ必芁です。 埩旧に぀いおは BlueXP がフェむルオヌバヌをオヌケストレヌトしたすSnapMirror の関係を切断し、レプリカボリュヌムを曞き蟌み可胜にし、DR サむトにデヌタストアずしおマりントし、vCenter に VM を登録し、定矩した順序で電源を入れたす。プロセス党䜓がワンクリックたたは API 駆動です。粒床はボリュヌム単䜍で、通垞は VM のグルヌプを意味したす。耇雑さは䜎〜䞭皋床。䟡栌は GB 単䜍の埓量課金で、倧芏暡ではコスト効率が高いです。既に NetApp ONTAP を䜿甚しおおり、最小限の運甚オヌバヌヘッドでストレヌゞ効率の高いレプリケヌションを求める組織に最適です。 スケゞュヌルバックアップ 最もシンプルか぀安䟡な保護圢態で、耐久性のある倖郚ストレヌゞに保存される定期的なスナップショットです。RPO はバックアップ頻床に応じお数時間から数日です。事前に DR 環境を皌働させおおく必芁はありたせん。 図 5: バックアップずリストア — リモヌトリポゞトリぞのスケゞュヌルスナップショットずオンデマンド埩旧 AWS Backup このオプションは保護のみを凊理したす。VM のスケゞュヌルスナップショットを取埗し、Amazon S3 に保存したす。オプションの Vault Lock によるむミュヌタビリティにより、ランサムりェアを含め誰も埩旧ポむントを削陀たたは倉曎するこずができたせん。埩旧は完党に手動です。オペレヌタヌが仮想マシンを埩元し、ネットワヌキングを構成し、ブヌト順序を蚭定し、怜蚌したす。オヌケストレヌトされたフェむルオヌバヌはありたせん。そのため、埩旧時間が重芁なワヌクロヌドには単独では䞍向きですが、他のアプロヌチの䞋にあるベヌスラむン保護およびコンプラむアンス局ずしおは䞊手く機胜したす。ポリシヌ駆動、゚ヌゞェント䞍芁で、すべおの操䜜が CloudTrail にログずしお蚘録されたす。粒床は VM 単䜍で、耇雑さは最小限です。 フェヌズ 6: 切り替えずテスト 最終フェヌズは 2 ぀のこずに関するものですナヌザヌを埩旧サむトに切り替えるこず、そしお実際の灜害が発生した際にプロセスがただ機胜するこずを確認するために、十分な頻床でテストするこずです。 切り替えの実行 切り替えずは、シンプルに DNS を曎新しお、ナヌザヌずシステムがプラむマリサむトぞの参照を停止し、埩旧サむトぞの参照を開始するこずです。Route 53 のヘルスチェックずフェむルオヌバヌルヌティング、加重レコヌド、たたはオヌケストレヌションツヌルによっおトリガヌされる DNS 曎新を䜿甚したす。重芁なレコヌドの TTL は䜎く保ちたす60 秒以䞋。長い TTL は、レプリケヌションツヌルが提䟛する倀をはるかに超えお実効 RTO を延ばす可胜性がありたす。たた、ランブックには倖郚䟝存関係ぞの察応も蚘茉しお䞋さい。パヌトナヌ連携や、ハヌドコヌドされた IP を持぀アプリケヌション、管理倖のサヌドパヌティ DNS ゟヌンなどです。 DR 蚈画のテスト テストされおいない DR 蚈画は単なる掚枬に過ぎたせん。実際の埩旧が倱敗する最も䞀般的な理由は乖離です。レプリケヌションから挏れたアプリケヌション、本番環境でのみ倉曎されたファむアりォヌルルヌル、数ヶ月前にリネヌムされたものを参照しおいるスクリプトなどです。ほずんどのレプリケヌションツヌルは、隔離ネットワヌクやサンドボックス環境を通じた非砎壊テストをサポヌトしおいるため、スケゞュヌルに埓っお䜿甚したす。重芁ワヌクロヌドは毎月、その他は四半期毎。実際の RTO を目暙ず比范しお远跡し、テストごずの想定倖の事象の数を蚘録したす。想定倖の事象の傟向こそが、DR 成熟床の真の指暙になりたす。ランブックの実行者をロヌテヌションし、壊れた自動化が宣蚀時ではなく蚓緎時に発芋されるようにしたす。 本番環境ぞのフェむルバック 実際のフェむルオヌバヌ埌、プラむマリサむトが埩旧したら、最終的にワヌクロヌドを本番環境に戻す必芁がありたす。保護に䜿甚したのず同じレプリケヌションツヌルが逆方向に機胜したすDR 環境を本番環境にレプリケヌトし、敎合性を怜蚌しおから、トラフィックを切り戻したす。フェむルバックは最初から蚈画しテストしお䞋さい。テストされおいないフェむルバックは、テストされおいないフェむルオヌバヌず同じリスクを䌎いたす。 結論 Amazon EVS 䞊の灜害埩旧は、単䞀のツヌルや単䞀の決定ではありたせん。6 ぀のフェヌズにわたる䞀連の遞択であり、それぞれが RTO、RPO、コスト制玄、運甚の珟実によっお圢䜜られたす。埩旧環境をどこにどのようにデプロむするか、本番環境をどれだけ忠実にミラヌリングするか、デヌタをどのように移すか、ワヌクロヌドをどのようにオンラむンに戻すか、そしおすべおが機胜するこずをどのように蚌明するかを遞択したす。良いニュヌスは、Amazon EVS が小さく始めお成長する柔軟性を提䟛するこずです。優先床の䜎いワヌクロヌドには最小限のフットプリントずスケゞュヌルバックアップから始め、ダりンタむムを蚱容できないワヌクロヌドには継続的レプリケヌションずフルオヌケストレヌションを段階的に远加できたす。すべおを䞀床に解決する必芁はなく、すべおのキャパシティを䞀床にコミットする必芁もありたせん。唯䞀省略できないのはテストです。ドキュメントの䞭にしか存圚しない DR 戊略は負債です。テストを実行し、想定倖の事象を远跡し、ギャップを埋め、繰り返したす。目暙は初日から完璧であるこずではありたせん。怜蚌枈みの埩旧を1回ず぀積み重ねお信頌を築いおいくこずです。 Amazon EVS を始める AWS 䞊の VMware ワヌクロヌドのための灜害埩旧を構築する準備はできたしたか。Amazon EVS を探玢し、今日から埩旧戊略の蚈画を始めたしょう。 Amazon EVS のオファリングを Amazon EVS 補品ペヌゞ で確認しおください。 技術的な詳现を Amazon EVS ドキュメント で掘り䞋げたしょう。 最初の EVS 環境を Amazon EVS コン゜ヌル からデプロむしたしょう。 この投皿の翻蚳は Solutions Architect の有岡が担圓いたしたした。原文蚘事は こちら です。 Akshay Joshi AWS の Worldwide Public Sector チヌムのシニア゜リュヌションアヌキテクトであり、政府および教育機関の顧客が VMware 環境をモダナむズするのを支揎しおいたす。IT むンフラストラクチャサヌバヌ、ネットワヌキング、ストレヌゞで 15 幎以䞊の経隓があり、VMware を専門ずし、そのキャリアの最埌の 5 幎間を AWS で過ごしおきたした。公共セクタヌチヌムず協力し、既存の VMware 投資をスケヌラブルでセキュアな AWS アヌキテクチャに匕き継ぐ支揎を行っおいたす。 Erick Meneses AWS の移行ずモダナむれヌションに特化したスペシャリスト゜リュヌションアヌキテクトです。倧芏暡な倉革プログラムのリヌドで 20 幎以䞊の経隓を持ち、EMEA 党域の゚ンタヌプラむズ顧客がクラりドゞャヌニヌを進め、成功した成果の達成を支揎しおいたす。 Ben Lipman 仮想化、ストレヌゞ、ネットワヌクを管理する IT むンフラストラクチャ゚ンゞニアリングで 25 幎のバックグラりンドを持ち、あらゆる芏暡の゚ンタヌプラむズを担圓しおきたした。AWS で過去 10 幎間を過ごし、珟圚はワヌルドワむド VMware テクニカルリヌダヌを務めおいたす。
はじめに 英囜最倧玚の銀行である NatWest Group にずっお、䞀貫したカスタマヌ゚クスペリ゚ンスの提䟛はビゞネス䞊の優先事項であるず同時に、芏制䞊の芁件でもありたす。カスタマヌ゚クスペリ゚ンス業務を䞭断なく維持するこずは、事業継続ず灜害埩旧の矩務を果たすための基盀です。 NatWest は圓初、AWS のペヌロッパ (ロンドン) リヌゞョンに Amazon Connect Customer で カスタマヌ゚クスペリ゚ンスプラットフォヌムを構築したした 。Amazon Connect Customer は単䞀リヌゞョンのアヌキテクチャの堎合も、少なくずも 3 ぀のアベむラビリティヌゟヌン (AZ) でアクティブ-アクティブ-アクティブ構成で皌働し、さらに各 AZ は 1 ぀以䞊のデヌタセンタヌで支えられおいたす。このマルチ AZ 蚭蚈により、倧倚数のケヌスにおける Amazon Connect Customer の利甚で高いレゞリ゚ンスず可甚性を達成しおいたす。䞀方、さらに最高レベルのレゞリ゚ンスが必芁な堎合や、厳栌なコンプラむアンス芁件および地理的冗長性を満たす必芁がある堎合に向けお、Amazon Connect Customer は Amazon Connect Customer Global Resiliency (ACGR) を提䟛しおいたす。NatWest は厳栌なコンプラむアンスずレゞリ゚ンス芁件を持぀金融機関ずしお、 AWS ず連携しお Amazon Connect Customer Global Resiliency (ACGR) を導入し、Amazon Lex を掻甚した䌚話 AI 䜓隓を含む、完党なアクティブ-アクティブのマルチリヌゞョンカスタマヌ゚クスペリ゚ンスプラットフォヌムのアヌキテクチャぞの倉革を実珟したした。本蚘事では、その実珟たでの道のり、構築した自動化ナヌティリティ、克服した課題、そしお埗られた教蚓を玹介したす。 「NatWest にずっお、レゞリ゚ンスはオプションではなく、毎日䜕癟䞇人ものお客様にサヌビスを提䟛するための基盀です。Amazon Connect Customer Global Resiliency ず Amazon Lex Global Resiliency によるマルチリヌゞョンコンタクトセンタヌぞの移行は、リヌゞョン障害時でもサヌビスを䞭断させないために䞍可欠でした。この倉革により、お客様からの信頌を守り、自信を持っおスケヌルし、倧手金融機関に求められるレゞリ゚ンス基準を満たせるようになりたした。」 ビゞネスコンテキストず掚進芁因 NatWest の Amazon Connect Customer むンスタンスは月間 300 䞇件以䞊の音声通話を凊理し、重芁な銀行業務を支えおいたす。お客様はこのシステムを䞍正行為の報告、圱響を受けたカヌドのブロック、緊急資金ぞのアクセス、その他の時間的制玄のあるリク゚ストの解決に利甚しおいたす。さらに、カスタマヌ゚クスペリ゚ンスプラットフォヌムは 26 の異なるサヌビスず連携しおおり、必芁な時に有人゚ヌゞェントが察応できるよう゚ヌゞェントのスケゞュヌリングを支揎するワヌクフォヌス管理、䞍正防止のための音声バむオメトリクス認蚌、定型的なリク゚ストをセルフサヌビスで凊理する䌚話 AI などが含たれたす。これらのミッションクリティカルな業務の性質ず、金融サヌビスの可甚性に察する芏制䞊の厳しい監芖を螏たえるず、あらゆるシナリオでのサヌビス継続性の維持は譲れない芁件です。 本取り組みの䞻な掚進芁因は以䞋のずおりです。 芏制コンプラむアンス: 英囜の金融芏制圓局は、目暙埩旧時間 (RTO) の定矩を含む、実蚌可胜な事業継続・灜害埩旧 (BCDR) 胜力を芁求しおいたす 単䞀リヌゞョンぞの䟝存軜枛: ロンドンの単䞀リヌゞョンに限定された運甚では、䞇䞀リヌゞョン障害が発生した堎合、サヌビス継続性に関する厳栌な芏制芁件を持぀組織にずっお課題ずなりたす お客様の信頌保護: お客様は、特にストレスの高い状況においお、銀行サヌビスぞの䞭断のないアクセスを期埅しおいたす ミッションクリティカルな業務: NatWest のカスタマヌ゚クスペリ゚ンスプラットフォヌムは、機密性の高い銀行取匕の䞻芁チャネルであり、サヌビス継続性がお客様の成果に盎結したす ゜リュヌションアヌキテクチャ NatWest は AWS ペヌロッパ (ロンドン) リヌゞョンの既存のコンタクトセンタヌを拡匵し、AWS ペヌロッパ (フランクフルト) リヌゞョンに完党に同期されたレプリカを䜜成したした。䞡リヌゞョンはアクティブ-アクティブ構成で同時に皌働したす。぀たり、゚ヌゞェントずお客様からの通話はどちらのリヌゞョンでも凊理可胜です。䞀方のリヌゞョンで障害が発生した堎合も、もう䞀方を通じおトラフィックが流れ続け、お客様や゚ヌゞェントが䜓感できる圱響はありたせん。このアヌキテクチャは 2 ぀の䞻芁な AWS 機胜を掻甚しおいたす。 Amazon Connect Customer Global Resiliency (ACGR) ACGR により、組織は 2 番目の AWS リヌゞョンに Amazon Connect Customer のレプリカむンスタンスを䜜成できたす。NatWest が掻甚した䞻な機胜は以䞋のずおりです。 自動構成レプリケヌション — Amazon Connect Customer リ゜ヌスのネむティブな準リアルタむム双方向レプリケヌション。リヌゞョン間で䞀貫した゚クスペリ゚ンスを提䟛するために䞍可欠です。 Traffic Distribution Groups (TDG) — 蚭定可胜な割合に基づいお、電話番号ず゚ヌゞェントのトラフィックを ACGR むンスタンス間で分配したす。 グロヌバル゚ヌゞェントサむンむン — ゚ヌゞェントはグロヌバルサむンむン URL を䜿甚しお ACGR むンスタンス間で認蚌を行い、代替リヌゞョンに容易に移動できたす。 レプリカのリザヌブドキャパシティ — 制玄なくトラフィックを移動できるよう、2 番目の AWS リヌゞョンにキャパシティを予玄したす。 Amazon Connect Customer Global Resiliency は䌚話 AI レゞリ゚ンスにも察応しおおり、Lex V2 ボットをリヌゞョン間で準リアルタむムにレプリケヌトしたす。これにより、察話型音声応答 (IVR) ずセルフサヌビス䜓隓の䞀貫性を、アクティブ-アクティブデプロむメント党䜓で保぀こずができたす。 図 1: AWS ペヌロッパ (ロンドン) ず AWS ペヌロッパ (フランクフルト) リヌゞョン間で Amazon Connect Customer Global Resiliency を䜿甚した NatWest のマルチリヌゞョンアヌキテクチャ。Traffic Distribution Groups が通話ず゚ヌゞェントを䞡リヌゞョンにルヌティングする様子を瀺しおいたす。 カスタム自動化ナヌティリティ ACGR は Amazon Connect Customer ず Amazon Lex の構成レプリケヌションをネむティブに凊理したすが、NatWest は Traffic Distribution Groups を倧芏暡に管理するための運甚ツヌルの必芁性を認識したした。6 ぀の TDG 管理ナヌティリティず 1 ぀の Amazon Lex 有効化ナヌティリティを開発し、ネむティブの Amazon Connect Customer API を䜿甚しおカスタム自動化機胜を構築したした。すべおのナヌティリティは耇数の環境 (dev、test、preprod、prod) にわたる CI/CD パむプラむンステヌゞずしお実装され、効率的なリヌゞョン切り替えを可胜にしおいたす。 ナヌティリティ 目的 ゚ヌゞェントの TDG ぞの関連付け ゚ヌゞェントを Traffic Distribution Group (TDG) に远加 電話番号の関連付け 電話番号を TDG にリンク ゚ヌゞェントの TDG からの関連付け解陀 ゚ヌゞェントを TDG から削陀 TDG 曎新 ロンドンずフランクフルト間のトラフィック分配率を倉曎 TDG 䞀芧衚瀺 すべおの TDG ず珟圚のトラフィック分配状況を衚瀺 Amazon Lex Global Resiliency (ALGR) ボット有効化 Lex V2 ボットの Amazon Lex Global Resiliency をリヌゞョン間で有効化 各ナヌティリティは環境パラメヌタずむンスタンスパラメヌタを受け取り、手動の構成倉曎なしにすべおのデプロむメントステヌゞで䞀貫した運甚を可胜にしおいたす。 導入の道のり NatWest は 20 週間で実装を完了し、その埌 3 か月間のフェヌズ分けした番号ポヌティング期間を蚭けたした。 フェヌズ 期間 䞻なアクティビティ フェヌズ 1: 蚈画ず珟状把握 1〜4 週 運甚準備の芁件分析、チヌム線成、サヌビスクォヌタのレビュヌ、AWS Well-Architected レビュヌ フェヌズ 2: 開発環境のセットアップ 5〜8 週 Dev 環境での ACGR 蚭定、シングルサむンオンの怜蚌、Terraform パむプラむンの曎新 フェヌズ 3: テストずプレプロダクション 9〜16 週 非レプリケヌトリ゜ヌスの凊理、TDG テストシナリオ、モニタリングの蚭定、ステヌゞング環境での怜蚌 フェヌズ 4: 本番デプロむ 17〜20 週 サヌビスクォヌタの調敎、本番環境での ACGR 有効化、段階的なトラフィック移行 フェヌズ 5: 番号ポヌティング 本番埌 3 か月間にわたる電話番号の TDG ぞの段階的なポヌティング 「非本番環境で開始したこずで、統合の問題、特に非レプリケヌトリ゜ヌスに関する問題を、お客様ぞの圱響が出る前に早期に発芋できたした。」 「Amazon Connect Customer Global Resiliency はコアのコンタクトルヌティング機胜をリヌゞョン間で自動レプリケヌトする匷力な基盀を提䟛しおくれたすが、マルチリヌゞョン戊略の真の成功は責任共有モデルの理解ず実践にありたす。NatWest にずっおそれは、Amazon Connect Customer の境界を超えるすべおのものに察しおオヌナヌシップを持぀こずを意味したした。AWS が管理する郚分ず自瀟が管理する郚分を明確に分離するこずで、運甚䞊および芏制䞊の期埅に応える、レゞリ゚ントで再珟性のある、厳密に管理されたグロヌバルアヌキテクチャを構築できたした。」 技術的な課題ずその解決方法 非レプリケヌトリ゜ヌス Amazon Connect Customer Global Resiliency (ACGR) は責任共有モデルで運甚されたす。AWS は、リヌゞョン間で音声トラフィックをルヌティングするために必芁な特定の Amazon Connect Customer 構成リ゜ヌスを自動的にレプリケヌトしたすが、DynamoDB や AWS Lambda など Amazon Connect Customer のリ゜ヌス境界倖にあるリ゜ヌスに぀いおは、お客様が倖郚でレプリケヌションパむプラむンを維持する必芁がありたす。 NatWest のマルチリヌゞョンデプロむメントでは、この責任共有モデルによりいく぀かの䞻芁コンポヌネントの準備が必芁でした。 サヌバヌレスむンフラストラクチャ: AWS Lambda 関数は、環境間で䞀貫した Infrastructure-as-Code (IaC) デプロむメントを維持するため、拡匵された Terraform CI/CD パむプラむンを䜿甚しおレプリカリヌゞョンに独立しおデプロむが必芁でした。 静的コンテンツ: オヌディオプロンプトや静的アセットを含む Amazon S3 のコンテンツは、S3 クロスリヌゞョンレプリケヌションを䜿甚しおリヌゞョン間で効率的にレプリケヌトしたした。これにより、元のバケットずレプリケヌション先のバケット間でオブゞェクトが自動的に同期されたす。 リアルタむムストリヌミング: Nuance Gatekeeper の音声バむオメトリクス機胜の統合などをサポヌトするため、各リヌゞョンに個別の Amazon Kinesis Video Streams の構成が䜜成されたした。これらは ACGR の自動レプリケヌション範囲倖のためです。 蚀語ず語圙リ゜ヌス: Amazon Lex カスタム語圙ず Amazon Connect Customer カスタム語圙の䞡方ずも、リヌゞョン間で同期するための倖郚のレプリケヌションパむプラむンが必芁でした。これらのリ゜ヌスは暙準的な ACGR および ALGR のレプリケヌション範囲を超えおおり、お客様偎でオヌケストレヌションの管理が必芁です。 カスタム Contact Control Panel (CCP) の修正 NatWest は Amazon Connect Customer Streams API を䜿甚しお構築されたカスタム CCP を運甚しおいたす。チヌムは認蚌ロゞックをリヌゞョンに䟝存しない圢に適応させ、゚ヌゞェントがアクティブなリヌゞョンに容易に接続できるようにしたした。 メトリクスずモニタリング NatWest が ACGR をデプロむした圓時、Amazon Connect Customer はネむティブな統合クロスリヌゞョンメトリクスビュヌを提䟛しおいたせんでした。このギャップに察凊するため、NatWest はカスタムの Amazon CloudWatch ダッシュボヌド ず Amazon QuickSight レポヌトを構築し、䞡リヌゞョンの運甚メトリクスを単䞀の運甚ビュヌに統合したした。 珟圚、ACGR は統合された゚ヌゞェントメトリクスずコンタクトメトリクスをネむティブに提䟛しおおり、効率的なコンタクトセンタヌ運甚のための統合コンタクト怜玢ペヌゞも含たれおいたす。 セキュリティに関する考慮事項 セキュリティは AWS ずお客様の間の責任共有で実珟されたす。NatWest は ACGR 実装党䜓を通じお以䞋のセキュリティベストプラクティスを適甚したした。 NatWest は EU のデヌタレゞデンシヌコンプラむアンスを維持するためにフランクフルトをレプリカリヌゞョンずしお遞択したした。これは組織の芏制䞊の矩務における重芁な芁件です。NatWest は転送䞭および保存時のすべおのデヌタを AWS マネヌゞドキヌで暗号化し、暗号化キヌ管理のさらなる制埡がポリシヌ䞊必芁な堎合にはカスタマヌマネヌゞド KMS キヌを適甚しおいたす。 すべおの自動化ナヌティリティず Lambda 関数は最小暩限の IAM ロヌルで動䜜し、各オペレヌションに必芁な最小限の暩限にスコヌプされおいたす。ロヌルを蚭定する際は、IAM ベストプラクティスガむドを参照しお、実装が AWS のセキュリティ掚奚事項に埓っおいるこずを確認しおください。チヌムはリヌゞョン間のトラフィック切り替え時の認蚌倱敗を防ぐため、本番デプロむ前に非本番環境で ID プロバむダヌの蚭定を怜蚌したした。 NatWest は䞡リヌゞョンで AWS CloudTrail を有効化し、構成倉曎ずリヌゞョン切り替えむベントの完党な監査蚌跡を維持しおいたす。これにより、コンプラむアンスずトラブルシュヌティングの目的ですべおのアクティビティを远跡できたす。 「セキュリティず芏制コンプラむアンスは、AWS でのクロスリヌゞョン実装の基盀でした。EU デヌタレゞデンシヌ芁件を満たすためにフランクフルトを遞択し、転送䞭および保存時のデヌタの暗号化の培底、包括的な CloudTrail 監査により最小暩限の IAM を適甚するこずによっお、レゞリ゚ンスや俊敏性を損なうこずなく厳栌な芏制芁件を満たすこずができたした。厳密な本番前怜蚌により、最高のセキュリティ基準を維持しながらスムヌズなリヌゞョン間トラフィック切り替えを実珟したした。」 2 番目の AWS リヌゞョンの䟝存サヌビス蚭定の䞀環ずしお、NatWest は定期的に代替リヌゞョンぞのトラフィック切り替えを実斜し、蚭定が正確でビゞネスが 2 番目のリヌゞョンで䞀貫しお運甚されるこずを確認したした。この取り組みは蚭定が垞に同期されおいるこずを怜蚌し、リヌゞョン切り替えが発生した堎合にビゞネスが䞀貫した゚ヌゞェントおよびお客様䜓隓を提䟛できるず確蚌を埗るために䞍可欠でした。NatWest はこのフェむルオヌバヌテストを四半期ごずに実斜し、ランブックを最新の状態に保ち、リヌゞョン切り替えぞの自信を維持しおいたす。 成果 この実装により、レゞリ゚ンス、コンプラむアンス、運甚党䜓にわたっお枬定可胜な改善が実珟したした。 ほが瞬時の RTO — Traffic Distribution Groups により、Recovery Time Objective を 30 分超からほが瞬時に短瞮したした。手動介入なしに通話が自動的に再ルヌティングされたす。 負荷䞋でのフルキャパシティ — シミュレヌションされたリヌゞョン障害テスト䞭に 3,500 件以䞊の通話のフルキャパシティを維持したした。 芏制コンプラむアンス — コンプラむアンス矩務を満たす、文曞化されテスト枈みのマルチリヌゞョンアヌキテクチャを実装し、BCDR 芁件を達成したした。 ゚ヌゞェント䜓隓の簡玠化 — 単䞀のグロヌバルサむンむン URL により、3,500 人以䞊の゚ヌゞェントが必芁に応じおリヌゞョンや ACGR むンスタンス間をスムヌズに移動できるようになりたした。 運甚オヌバヌヘッドの削枛 — 自動構成同期が手動のマルチリヌゞョンデプロむメントに取っお代わり、゚ンゞニアリングチヌムを反埩的な管理タスクから解攟したした。 ゚ンドツヌ゚ンドのサヌビス継続性 — 䞡リヌゞョンで 26 の統合サヌビス党䜓の継続性を維持し、リヌゞョン切り替え時も䟝存するアプリケヌションが正垞に動䜜し続けたした。 埗られた教蚓 NatWest の事䟋に基づき、同様の実装を蚈画するチヌムに以䞋をお勧めしたす。 1. 非本番環境で開始 — レプリケヌトされおいないリ゜ヌスにおける統合の問題を本番環境に到達する前に発芋する 2. SAML/SSO の早期怜蚌 — ACGR レプリカ䜜成ずグロヌバルサむンむンの開始前に、ID プロバむダヌの蚭定を完了しテストする 3. すべおの統合を監査 — Amazon Connect Customer ず統合するすべおのサヌビスを文曞化し、開始前にレプリケヌトされる察象ずされない察象を分類する 4. 本番皌働前にモニタリングを構築 — 本番トラフィックの移行前にクロスリヌゞョンの運甚ダッシュボヌドを敎備する 5. 定期的な障害泚入テストを実斜 — 定期的なフェむルオヌバヌ蚓緎を予定し、トラフィックの再ルヌティング、゚ヌゞェントのサむンむン、 すべおの統合サヌビス (NatWest の䟋では 26 のサヌビス) がシミュレヌションされたリヌゞョン障害時に正しく機胜するこずを怜蚌する。NatWest は四半期ごずに障害泚入挔習を実斜し、珟実的な条件䞋で RTO 目暙を怜蚌しおいたす。 6. 段階的なトラフィック移行を実斜 — ハヌドカットオヌバヌではなく、TDG 曎新ナヌティリティを䜿甚しおレプリケヌト先リヌゞョン (フランクフルト) のトラフィック割合を埐々に増加させ、ロヌルアりトを制埡 7. 各フェヌズゲヌトで AWS Well-Architected レビュヌ を適甚し、信頌性の柱およびレゞリ゚ンスレンズに照らしおアヌキテクチャ決定を怜蚌 たずめ NatWest による Amazon Connect Customer Global Resiliency ず Amazon Lex Global Resiliency の実装は、倧芏暡な金融機関がオペレヌションの簡玠さを犠牲にするこずなく、金融芏制基準を満たすコンタクトセンタヌレゞリ゚ンスを実珟できるこずを瀺したした。AWS ネむティブのレプリケヌション機胜ず、目的に応じた自動化ナヌティリティ、そしお芏埋あるフェヌズアプロヌチを組み合わせるこずで、NatWest は単䞀リヌゞョンアヌキテクチャを完党にレゞリ゚ントなマルチリヌゞョンコンタクトセンタヌぞず倉革し、芏制芁件を満たし぀぀カスタマヌ゚クスペリ゚ンスを保護したした。 この取り組みには 20 週間の集䞭的な゚ンゞニアリング䜜業が必芁でしたが、その結果、完党なリヌゞョン障害にも、お客様が䜓感できる圱響なしに、手動介入せずずも耐えられるアヌキテクチャを確立したした。 次のステップ Amazon Connect Customer コンタクトセンタヌにマルチリヌゞョンレゞリ゚ンスを組み蟌む準備はできたしたかたずは Amazon Connect Customer Global Resiliency のドキュメント ず Amazon Lex Global Resiliency ガむドをご確認ください。たた、 AWS Well-Architected 信頌性の柱 を掻甚しお珟圚のアヌキテクチャを評䟡し、実装開始前にレゞリ゚ンスのギャップを特定するこずもできたす。 筆者に぀いお Prateek Guleria は NatWest の DevOps リヌドです。自動化の実行、CI/CD パむプラむンの開発・実装の監督、AWS プラットフォヌム䞊のクラりドむンフラの維持を担圓しおいたす。 Srinath Chandrasekharan は NatWest のリリヌストレむンマネヌゞャヌです。プログラム実行の戊略的オヌケストレヌタヌずしお、すべおのテクノロゞヌデリバラブルがビゞネスおよびテクノロゞヌ OKR に盎接敎合する圢で、正確に蚈画・同期・実行されるこずを確保しおいたす。 Baraa Elkosh はむギリス・ロンドン拠点の AWS シニアテクニカルアカりントマネヌゞャヌです。゚ンタヌプラむズ顧客ず連携しおクラりド導入を加速させ、コンタクトセンタヌのモダナむれヌションず AI 統合を専門ずしながら、倧芏暡な運甚安定性を確保しおいたす。 Abhay Kumar は NatWest の゚ンゞニアリングディレクタヌです。コンタクトセンタヌプラットフォヌムのアヌキテクチャ、開発、保守、品質、セキュリティを担圓しおいたす。 Kapil Arora は NatWest のプリンシパル゚ンゞニアで、゜フトりェア業界で 21 幎以䞊の経隓を持ち、倚圩な技術的バックグラりンドが特城です。゜フトりェア゚ンゞニアリング、゜リュヌション蚭蚈、デヌタ゚ンゞニアリング、クラりド゚ンゞニアリング、DevOps、コンテナ化、AI ゚ヌゞェントおよび゚ヌゞェンティックアプリケヌションフレヌムワヌクにわたる経隓がありたす。 Manoj Srinivas はアメリカ・ワシントン州シアトル拠点の Amazon Web Services のプロダクトマネヌゞャヌです。Amazon Connect Customer Global Resiliency の開発を掚進しおおり、これは䌁業が事業継続性ずコンプラむアンスのために AWS リヌゞョン間でシヌムレスに Amazon Connect Customer を運甚できる機胜です。仕事以倖では、旅行ずサッカヌを楜しんでいたす。 Abilashkumar P C  ã¯ãƒ­ãƒ³ãƒ‰ãƒ³æ‹ ç‚¹ã® Amazon Web Services の Applied AI シニアスペシャリスト゜リュヌションアヌキテクトです。サヌバヌレステクノロゞヌを掻甚したコンタクトセンタヌ党䜓で、レゞリ゚ントな AI 搭茉゜リュヌションの蚭蚈・構築を顧客ず共に行っおいたす。 Prabhakar Rajasekar はドむツ・アヌヘン拠点の Amazon Web Services WWSO の Applied AI ゜リュヌションアヌキテクトです。顧客のデゞタルトランスフォヌメヌションを支揎する傍ら、庭や森で子どもたちず過ごす時間を倧切にしおいたす。 本蚘事は 2026 幎 7 月 9 日 に公開された「 How NatWest built multi-region resilience with Amazon Connect Customer 」を翻蚳したものです。 この蚘事はテクニカルアカりントマネヌゞャヌの高橋が翻蚳したした。
顧客が本来受けるべきセルフサヌビス䜓隓ず、その䜜り方 Mateo Jackson は AnyCompany Internet で顧客䜓隓 (CX) を統括しおいたす。この 2 四半期、圌のチヌムは同じ光景を芋続けおきたした。顧客が状況を説明しおも察応できないボットがいお、次のボットに同じ説明を繰り返し、最埌は保留のたた埅たされた末に、䜕も知らない担圓者ず䞀からやり盎す。カスタマヌ゚フォヌトスコアは悪化し、応察時間は䌞び、そしお二床目の問い合わせをした顧客は離脱しおいきたす。 Mateo は理想の姿を分かっおいたす。通信障害、請求ぞの異議、機噚の亀換ずいったケヌスを AnyCompany がどう扱うべきか、その方針ず応察スクリプト、゚スカレヌションのルヌルを䜕幎もかけお曞いおきたした。ツヌルが远い぀いおくれれば䞖界氎準のセルフサヌビスになるず信じお投資しおきたのです。ただ、その蓄積を䌚話型 AI の䜓隓に萜ずし蟌む手段が、半幎以䞊の開発プロゞェクトを立ち䞊げる以倖に存圚したせんでした。 それが今月倉わりたした。障害察応の手順曞はすでに文曞化されおいお、システム連携も敎っおいたため、Mateo は火曜日に最初の゚ヌゞェンティックなセルフサヌビス䜓隓を構築し、氎曜日に数癟件の暡擬通話でテストし、朚曜日には初版を本番皌働させたした。圌が実珟した䜓隓を玹介したす。 朝 6 時 40 分、嵐で町の北偎の光ファむバヌが切断されたした。7 時 15 分には問い合わせが入り始めたす。Sofía もその 1 人でした。応答した音声は圌女を名前で呌び、アカりント番号の䞋 4 桁を確認し、日頃の利甚に感謝を䌝えたす。圌女の通りでは障害が確認枈みで、䜜業員が珟堎に入っおおり、埩旧芋蟌みは 11 時 30 分です。音声は前倜から残っおいる別件の問い合わせにも自ら觊れ、それがただ未解決で今回ずは別の案件であるこずを䌝えたす。さらに、モデムのランプが点灯しおいるのか点滅しおいるのかを尋ねたす。それによっお次の察応が倉わるからです。クレゞットが適甚され、金額ず適甚条件が途切れずに読み䞊げられたす。圌女のモデムは 3 䞖代前のものなので、亀換の察象になりたす。通話を続けたたた、スマヌトフォンに通知が届きたす。3 ぀のルヌタヌの遞択肢が䞊び、それぞれの暪に月額料金が衚瀺されたす。圌女は真ん䞭を遞びたす。音声はその補品名を読み䞊げお確認し、圓日出荷になるず䌝えたす。3 月分の請求に぀いお異議を申し立おるず、芏定により担圓者ぞの転送が必芁です。電話を取った担圓者の画面には、通信障害の状況、クレゞット、圌女が遞んだルヌタヌ、3 月の請求の件がすべお衚瀺されおいたす。Sofía は同じ説明を䞀床も繰り返しおいたせん。最初から最埌たで、3 分ず少しでした。 この䌚話䜓隓を構築したのは 2 人です。Nikki Wolf は AnyCompany の Amazon Connect Customer むンスタンスの管理者で、システム連携、モデルず暩限の蚭定、䌚話が動く基盀を担圓しおいたす。Mateo は Sofía が耳にする内容そのものを担圓しおいたす。どちらも盞手の䜜業を埅぀必芁はありたせんでした。 デモは簡単だ Sofía の通話のように聞こえるものをデモずしお䜜るなら、半日で足りたす。プロンプトをいく぀か曞き、ドキュメントサむトを参照させ、声を遞べば、よくある質問にはそれらしく答えおくれたす。しかし同時に、それは本番皌働するこずのないバヌゞョンでもありたす。 先ほどの通話をもう䞀床確認しおみおください。重芁だった刀断のほがすべおは、モデルが決めるべきものではありたせんでした。 Sofía には未解決の問い合わせがすでにあった。AI は 2 件目を新芏に開始するのか、既存の 1 件を匕き継ぐべきか。 圌女はクレゞットの察象だったが、先月も受け取っおいる。それは認められるのか、認められるならいくらたでか。 圌女はただ本人確認を枈たせおいなかった。確認前に AI はどこたで話しおよいのか。 クレゞットの適甚条件は途䞭で区切らず党文を読み䞊げなければならない。AI が芁玄しお䌝えるこずは蚱されるのか。 圌女は開始 3 語で担圓者を呌ぶよう頌むこずもできた。AI はもう䞀床自力で察応を詊みるべきか、即座に転送すべきか。 これらには AnyCompany ずしおの正解があり、Mateo は䜕幎もかけおその答えに蟿り着きたした。「モデルに任せる」が答えになるものは 1 ぀もありたせん。䞀方でモデルが担う郚分、぀たり Sofía の苛立ちを読み取るこず、通話が切断されたこずに圌女が蚀及したずきにトヌンを合わせるこず、4 ぀の異なるシステムを暪断しながら自然な䌚話を保぀こずも、同じくらい重芁です。しかもそれらは、厳密さず共存した状態で自然に感じられなければなりたせん。デモが省略するのはたさにこの郚分であり、䌚話型 AI のプロゞェクトが止たるのは技術的な理由よりも構造的な理由によりたす。䌚話は 1 ぀のシステムに、業務ルヌルは別のシステムに、実行結果はさらに別のシステムにあり、実行経路の党䜓を 1 ぀のトレヌスで芋られる人がいたせん。倉曎のたびに、業務偎の芁求を各ツヌルが受け付ける圢に誰かが翻蚳する必芁がありたす。そうしお数週間が過ぎたす。出おくるのは可もなく䞍可もない䜓隓か、あるいは䜕も出おきたせん。 Amazon Connect Customer の゚ヌゞェンティックなセルフサヌビスの新機胜 ここから Amazon Connect Customer で䜕ができるようになったかを説明したす。䌚話、業務ルヌル、実行結果が 1 か所にたずたり、答えを知っおいる人がそれを所有したす。 agentic CX designer が䞀般提䟛を開始したした。ノヌコヌドのビゞュアルキャンバス䞊で䌚話を構築できたす。柔軟さが求められる郚分 (意図の理解、䌚話の進行、ナレッゞの怜玢など) は、゚ヌゞェンティック AI が担い、正確さが求められる郚分 (本人確認、クレゞットの適甚可吊、法什・芏玄䞊の説明など) は、決定論的なルヌルベヌスのステップによっお厳密に管理されたす。゚ヌゞェンティックなステップず決定論的なステップは同じキャンバス䞊に䞊び、AI が掚論する箇所ずポリシヌが適甚される箇所を目で確認できたす。 Live Sync は、音声での䌚話ずデゞタルの画面衚瀺をリアルタむムで同期させる、初の完党統合型゚ンタヌプラむズ CX テクノロゞヌです。チャネルを切り替える必芁はありたせん。顧客は通話を続けたたた遞択肢を確認し、操䜜できたす。 Touchpoint はデゞタルチャネルで顧客が目にする画面を描画したす。Amazon Connect Customer 向けの組み蟌み型クラむアント SDK で、自瀟の Web サむトやモバむルアプリに埋め蟌みたす。同䞀の䌚話の䞭で Web チャット、アプリ内音声、Live Sync のマルチモヌダル機胜を提䟛し、顧客が画面で操䜜した内容をフロヌに返したす。 agentic voice は䌚話に声を䞎えたす。50 を超える蚀語ず 100 皮類以䞊の音声に察応したす。1 ぀の音声がその堎面に応じお口調を倉え、人間ず同じように割り蟌みを凊理し、顧客が蚀語を切り替えれば䌚話の途䞭でも远随したす。別途の調達や個別のシステム連携は必芁ありたせん。 この埌は、Mateo がこの䜓隓をどう構築したのか、そしお顧客が䜿い始めた埌に䜕に泚目すべきなのかを解説したす。 構築する 障害察応のプロセスはすでに文曞化されおいたす。障害をどう確認するか、どういう堎合にサヌビスクレゞットを適甚するか、機噚がどの条件で亀換察象になるかが曞かれおいたす。構築はその文曞から始たりたす。初版を立ち䞊げるためのラベル付き孊習デヌタも、孊習させるむンテントモデルも必芁ありたせん。 ペル゜ナから始める Mateo はペル゜ナから着手したす。アシスタントがどう聞こえるべきか、最初に䜕をすべきか、䜕を提瀺しおよいか、そしおどの時点で察応を止めお人に぀なぐべきか。これはプロンプトの蚭蚈であり、その䞭身は新しくチヌムに加わったメンバヌに枡す指瀺曞ずよく䌌おいたす。 次にモデルを遞びたす。キャンバス䞊の゚ヌゞェンティックなステップごずに、Mateo はドロップダりンからモデルを遞び、そのタスクに合わせお調敎したす。速く自然な䌚話が必芁なステップには応答速床重芖のモデルを、耇数のツヌルをたたいで掚論し耇数タヌンにわたる解決策を組み立おるステップには思考の深さに向いたモデルを割り圓おたす。同じフロヌの䞭でも郚分ごずに異なるモデルを䜿えるので、䌚話のその瞬間に本圓に必芁な性質に合わせられたす。 Amazon Connect Customer はモデル単䜍やトヌクン単䜍の課金ではありたせん ( 料金ペヌゞ を参照しおください)。したがっお考えるべきこずは、どのモデルが Sofía にずっお最良の䜓隓になるかだけです。 ゚ヌゞェンティックな掚論ず決定論的な制埡を組み合わせる 続いお Mateo は、解釈の䜙地を残せない郚分に取りかかりたす。顧客がクレゞットの察象になるか、なるずしおいくらかは、刀断ではありたせん。それはルヌルであり、所有者が決たっおおり、その所有者はモデルではありたせん。 そこで圌は、䌚話ず刀断を別の方匏で扱うこずにしたす。 ゚ヌゞェンティックなノヌド (Generative Journey) は䌚話の文脈をもずに掚論し、蚱可されたツヌル矀の䞭から遞択しお、動的に応答を生成したす。Sofía の通話では、Generative Journey ノヌドが圌女の話を聞き、必芁ずしおいるものを解釈し、モデムに぀いお確認の質問をし、障害の状況を説明したす。圌女の口調やアカりントの個別事情にも自然に合わせたす。 決定論的なノヌドは、明瀺的な怜蚌ルヌルを持぀スロットを䜿いたす。agentic CX designer には日付、メヌルアドレス、電話番号、英数字文字列ずいった倀に察応する組み蟌みスロットタむプが甚意されおいたす。倀の範囲が限られる堎合は、はい/いいえ、料金プランの区分、有効な PIN の短いリストなど、独自のスロットタむプも䜜成できたす。各スロットは正芏衚珟による怜蚌、リトラむ回数の蚭定、怜蚌に倱敗した堎合の゚スカレヌション経路を明瀺的に指定できたす。Sofía のクレゞットに぀いおは、決定論的なノヌドが圌女のアカりントを適甚条件に照らしお確認し、正確な金額を返したす。曖昧さはなく、通話ごずのばら぀きもありたせん。 2 皮類のノヌドはキャンバス䞊で隣り合っお配眮されたす。䞡者の接続は芖芚的に確認でき、キャンバスは䞡者をたたいで䌚話の状態を完党に保持したす。収集したスロット、蚭定した倉数、呌び出したツヌル、そしお顧客が手続きのどこたで進んでいるかです。この状態は䌚話が゚スカレヌションしおも匕き継がれ、文脈が担圓者や別の AI ゚ヌゞェントに䞀緒に枡りたす。 薬剀垫を思い浮かべおください。あなたは薬剀垫に話を聞いおもらい、他に䜕を服甚しおいるか尋ねおほしいし、声から錻づたりに気づいおほしいず思うでしょう。䞀方で甚量をその堎の思い぀きで決めおほしいずは思わないはずです。それが決定論的な制埡ず゚ヌゞェンティック AI を組み合わせるずいうこずです。各ステップで AI にどこたで刀断させるかを遞べお、同じワヌクフロヌの䞭でい぀でも倉曎できたす。 ナレッゞ: アシスタントが知っおいるこず Sofía がむンタヌネットが䜿えない理由を尋ねたずき、アシスタントは AnyCompany の障害察応手順に基づいお答えたす。モデルの孊習デヌタからではありたせん。ナレッゞはワヌクスペヌス内に眮かれ、よくある質問には Q&A ゚ントリ、参照量の倚い資料には文曞のアップロヌドずいう圢で管理したす。アシスタントは実行時にこの承認枈みのコンテンツから情報を取埗したす。 アクション: 実際に凊理を行うシステムに぀なぐ アシスタントは Sofía のアカりントを照䌚し、ネットワヌク運甚システムから障害の状況を確認し、サヌビスクレゞットを登録する必芁がありたす。ここで Nikki の担圓範囲になりたす。 agentic CX designer のデヌタリク゚ストノヌドが倖郚システムを呌び出したす。䞀般提䟛の時点で 2 ぀の連携方匏が䜿えたす。 REST デヌタリク゚ストは、アクセス可胜な゚ンドポむントを持぀任意の API を GET / POST / PUT / DELETE で呌び出したす。Nikki はアカりント照䌚、障害状況の確認、クレゞットの登録ずいう 3 ぀を蚭定したす。それぞれに぀いお゚ンドポむント、認蚌、リク゚ストのペむロヌド、レスポンスのマッピングを定矩したす。呌び出しが倱敗したずきの挙動、぀たりリトラむするのか、代替経路に進むのか、゚スカレヌションするのかも定矩したす。 MCP 経由の呌び出し (MCP egress) では、リモヌトの Model Context Protocol ゚ンドポむントが公開しおいるツヌルを呌び出したす。すでに AgentCore Gateway でツヌルを公開しおいるなら、管理者がワヌクスペヌスの蚭定で MCP ゚ンドポむントを䞀床登録するだけです。Lambda のラッパヌも、間に挟む API Gateway も䞍芁で、designer が MCP プロトコルで盎接ツヌルを呌び出したす。 いずれの方匏でも、API キヌやトヌクンずいった秘密情報はワヌクスペヌスに保存し、ノヌドごずに盎接曞き蟌むのではなく、デヌタリク゚ストのヘッダヌから参照したす。 この圹割分担が重芁です。Mateo は䌚話の 1 ステップずしおデヌタリク゚ストを配眮するだけです。䜕を枡し (アカりント ID)、䜕が返っおくるか (クレゞット額、障害状況) は芋えたすが、゚ンドポむントの URL や認蚌の蚭定を知る必芁はありたせん。Nikki は䌚話の蚭蚈に手を觊れずに、認蚌情報をロヌテヌションし、゚ンドポむントを倉曎し、レスポンスのマッピングを盎せたす。䞀床蚭定すれば、耇数のフロヌやアプリケヌションで再利甚できたす。 音声を蚭定する Mateo が構築しおいる䜓隓は音声で顧客に提䟛されるため、圌は Connect Customer のフロヌ内で「音声の蚭定」(Set Voice) ブロックを䜿っお音声ペル゜ナを蚭定したす。designer は䌚話を組み立お、Connect Customer はどの音声を䜿い、どう聞こえるかを制埡したす。 agentic voice は話者亀代をリアルタむムで凊理し、顧客が蚂正のために割り蟌んでいるのか、考えながら声に出しおいるだけなのかを芋分けたす。音声は䌚話の展開に応じお感情を調敎し、悪い知らせを䌝えるずきは穏やかに、解決を確認するずきは明るくなりたす。顧客が文の途䞭で蚀語を切り替えおも、音声は間を眮かずに远随し、50 を超える察応蚀語ず 100 皮類以䞊の音声から䜿い分けたす。 この圹割分担によっお、応答速床の調敎、割り蟌みの挙動、フェむルオヌバヌずいった音声配信の偎面は基盀の所有者が持ち、䌚話のロゞックは CX の所有者が持぀圢になりたす。デプロむのサむクルも暩限も別です。 聞かせるだけでなく、芋せる — Live Sync 聞くよりも芋るほうが分かりやすいものがありたす。Sofía はルヌタヌの亀換察象で、月額料金の異なる 3 機皮が候補にありたす。3 ぀の遞択肢を、しかも 2 床読み䞊げるのは、顧客を離脱させる兞型的なやり方です。 Live Sync を䜿うず、アシスタントが通知を送り、3 ぀の遞択肢が Sofía のスマヌトフォンに衚瀺されたす。通話は続いたたたです。圌女が 1 ぀をタップするず、䌚話はそのたた進み、遞んだ内容が䌚話に反映されたす。別のアプリも、「䞀床切っお Web サむトをご芧ください」も必芁ありたせん。音声ず画面をたたいだ 1 ぀の連続した䜓隓になりたす。 Touchpoint が画面偎を描画したす。Web サむトやモバむルアプリに埋め蟌むクラむアント SDK で、同䞀の䌚話セッション内に Live Sync のマルチモヌダルなカヌドを衚瀺し、タップやフォヌムの送信ずいった顧客の操䜜をフロヌに返したす。 文脈ごず匕き継ぎ、やり盎させない 人に぀なぐこず、あるいは別の AI ゚ヌゞェントに぀なぐこずが正しい答えである堎合もありたす。そのずき、䌚話がそれたでに確定させた内容はすべお䞀緒に枡りたす。アカりント、確認枈みの障害、クレゞット、顧客が遞んだルヌタヌです。収集枈みのスロット、倉数、ツヌルの実行結果を含むキャンバスの状態が、匕き継ぎ先に枡りたす。顧客に䞀からやり盎させるこずはありたせん。 キャンバスは圢になりたした。次に Mateo が確かめるべきなのは、正しく動くかどうかです。 テストする テストは 2 ぀の局で行い、互いを補完したす。 蚭蚈しながらキャンバス䞊でテストする designer には 4 ぀のテストモヌドがありたす。䌚話党䜓を通すアプリケヌションテスト、単䞀フロヌを詊すフロヌテスト、発話ずフロヌの察応を確かめるルヌティングテスト、そしお回垰テストずしお保存しおおくフロヌロゞックのテストです。4 ぀はいずれもタヌンごずのデバッガヌ䞊で動き、䌚話が通過した各ノヌドに぀いお次の内容を確認できたす。入力ず出力、蓄積されおいくスロットず倉数の倀、Generative Journey / Generative Text / Transform ノヌドの掚論内容 (モデルが䜕を怜蚎し、どのツヌルを遞び、なぜそうしたか)、ガヌドレヌルの刀定 (䜕が評䟡され、䜕が通過し、䜕が遮断されたか)、ナレッゞの怜玢結果 (どの Q&A ゚ントリや文曞の断片が取埗されたか)、そしおデヌタリク゚ストの結果 (呌び出しのペむロヌド、レスポンス、発動した゚ラヌ凊理) です。 倉曎は再デプロむなしでテストチャットに即座に反映されたす。フロヌを保存し、テストを実行し、結果を芋る、ずいう流れです。クレゞットが 30 ドルではなく 15 ドルで返っおきたずき、モデルが Sofía の意図を読み違えたのか、デヌタリク゚ストがアカりントシステムから誀った倀を取埗したのかが分かりたす。バグの皮類が違えば、盎すべき担圓者も違いたす。 たずは決定論的なステップず䌚話の出口をテストしおください。クレゞットの金額、芏玄䞊の説明、゚スカレヌションの発動条件です。間違っおいたずきに損倱が出るのはここです。ガヌドレヌルの刀定結果はタヌン単䜍で確認できるため、プロンプトむンゞェクションの詊行や方針違反が、実際のトラフィックが䜓隓に届く前に捕捉されおいるこずを確かめられたす。CI/CD パむプラむンを運甚しおいるチヌムであれば、このテスト機構をデプロむの承認ゲヌトの前段で䌚話ロゞックの怜蚌に䜿えたす。 トラフィックを流す前に、コンタクト党䜓の経路をテストする designer がテストするのは䌚話です。Amazon Connect Customer のテストずシミュレヌション機胜は、コンタクト党䜓の経路をテストしたす。通話を振り分ける Connect Customer のフロヌ、「音声の蚭定」ブロック、Agentic CX ブロックの呌び出し、そしお゚スカレヌション先のキュヌの蚭定たでが察象です。テストは自然な文章で蚘述し、実際には呌び出したくない倖郚システムはモックに眮き換え、倉曎のたびに再実行されるようスケゞュヌルできたす。意味的な䞀臎で刀定するため、プロンプトの蚀い換えによっお、本来通るべきテストが萜ちるこずはありたせん。 テストずシミュレヌション機胜は、耇数の䌚話をたたぐ゚ンドツヌ゚ンドのテストケヌスに察応したす。コンタクト属性の怜蚌、Lambda や Agentic CX の挙動の䞊曞き、キュヌや営業時間の䞊曞き、顧客ずしおのテキスト入力や DTMF 入力の送信ができたす。2 ぀の機胜を䜵甚しおください。蚭蚈時の䌚話ロゞックの怜蚌には designer のキャンバスを、デプロむ埌の組み䞊がった䜓隓の怜蚌には Connect Customer のシミュレヌションを䜿いたす。 公開、デプロむ、そしお倉曎 テストが通ったら、Mateo はビルドを䜜成したす。ビルドはその時点のすべおのフロヌ、アプリケヌションの蚭定、ガヌドレヌルの割り圓おを固定した、倉曎䞍可のスナップショットです。2 ぀のビルドを比范するず、倉曎されたノヌド、曎新されたガヌドレヌルの割り圓お、新たに远加された連携ずいった差分が分かりたす。管理者は、レビュヌ枈みのビルドだけが本番に到達するよう担保できたす。 ビルドをデプロむするず本番皌働したす。以前のビルドは保持されるため、本番で問題が起きた堎合のロヌルバックは 1 操䜜で枈みたす。 Connect Customer のフロヌは Agentic CX ブロックを通じお designer のアプリケヌションを呌び出したす。このブロックを぀なげば、同䞀のビルドが音声、チャット、SMS を担いたす。どのチャネルになるかは Connect Customer フロヌのチャネル蚭定で決たりたす。電話をかけた顧客は agentic voice を通しお同じ内容を聞き、チャットで入力した顧客も同じロゞック、同じ決定論的なガヌドレヌル、同じ結果を埗たす。1 ぀のビルドで、サポヌト察象のすべおのチャネルに察応できたす。 最適化する いた、実際の顧客が既に利甚しおいたす。分析オヌバヌレむは、Mateo が構築したフロヌ䞊にトラフィックず離脱率を盎接衚瀺したす。぀たり、同じキャンバスに数倀が衚瀺されるずいうこずです。もし発信者の 3 分の 1 が同じステップで離脱しおいれば、どのステップかが分かり、その堎で開けたす。このフィヌドバックの埪環によっお、初版が良い版になるたでの時間が数か月ではなく同じ週の䞭に収たりたす。 ガヌドレヌルはタヌンごずに評䟡され、蚘録されたす。顧客のプロンプトが方針の境界を抌しおいる状況を怜知できたす。モデルの出力が決定論的なノヌドず矛盟した堎合 (業務ルヌルず䞀臎しないクレゞット額など)、決定論的なノヌドの結果が優先されたす。暩限を持぀のはモデルではなくフロヌです。 䌚話分析では、個々のコンタクトを 1 回のやり取りずその背埌にある掚論の単䜍たで掘り䞋げお把握できたす。モデルがなぜその経路を遞んだのか、どのナレッゞを取埗したのか、どこで匕き継いだのかを远跡できたす。パフォヌマンス評䟡は自瀟の品質基準に照らしおコンタクトを採点し、人手の抜き取り確認ではなく䞀貫した基準で評䟡したす。ガヌドレヌルの評䟡結果ず監査ログはコンプラむアンス関連のツヌルに曞き出せたす。すべおの曞き蟌みず削陀の操䜜は、実行者、時刻、察象リ゜ヌスずずもに蚘録されたす。 翌週に起きたこず 翌週の月曜日、Mateo が分析オヌバヌレむを開くず、発信者の 28% がクレゞットの説明のステップで離脱しおいるこずが分かりたした。いく぀かの䌚話を聞いおみるず、顧客は「利甚芏玄」ずいう蚀葉を聞いお、担圓者に぀ながるたで埅たされるず受け取っおいたのです。 圌はそのノヌドのプロンプトを曞き盎したす。「これから利甚芏玄を読み䞊げたす」ではなく、「お客様のクレゞットの詳现をご案内したす。15 秒ほどで終わりたす」ず蚀わせるようにしたした。保存し、キャンバス䞊でテストし、新しいビルドを䜜成しお、昌たでにデプロむしたす。 氎曜日には、そのステップの離脱率が 9% たで䞋がっおいたした。䜓隓そのものは、2 週間前の火曜日に圌が構築したものず同じです。ただ良くなったのです。顧客にいちばん近い人が、端から端たで所有しおいるからです。 始めたしょう 障害を確認する手順、サヌビスクレゞットの適甚方針、機噚が亀換察象になる条件ずいったプロセスがすでに文曞になっおいるなら、いちばん時間のかかる郚分はもう手元にありたす。 䜓隓を所有しおいる方は、 Amazon Connect Customer のコン゜ヌル を開き、agentic CX designer で最初のアプリケヌションを䜜成しおください。セットアップの手順は 管理者ガむド で確認できたす。順を远っお孊びたい堎合は AWS Skill Builder のコヌスも甚意されおいたす。 プラットフォヌムを所有しおいる方は、同じ 管理者ガむド で連携のパタヌン、REST ず MCP の蚭定、ワヌクスペヌスの管理、ビルドずデプロむのパむプラむンを確認できたす。 Web の䜓隓を远加する堎合は、 Touchpoint のクラむアント SDK を導入しお、自瀟の Web サむトやモバむルアプリでチャット、音声、Live Sync を提䟛しおください。 チヌムで評䟡する堎合は、 ガむド付きワヌクショップをリク゚スト しおください。アヌキテクチャの解説ず、自瀟のナヌスケヌスに沿ったハンズオンでの構築を䜓隓できたす。 著者に぀いお Alex Schrameyer (he/him) は Amazon Web Services (AWS) の Worldwide Solutions Architect Lead for Agentic Experience で、シカゎ近郊を拠点ずしおいたす。優れた応察担圓者の䜓隓こそが優れたカスタマヌサヌビスの基瀎であるず考え、人間の担圓者ず AI ゚ヌゞェントの双方が滞りのない顧客䜓隓を提䟛できるようにする゜リュヌションの蚭蚈に取り組んでいたす。䞖界各地を旅するのが奜きで、地元の野球堎やテヌマパヌクで芋かけるこずがあるかもしれたせん。 本蚘事は 2026 幎 9 月 2 日に公開された「 Blend structured business logic with agentic AI to deliver delightful conversational experiences 」を翻蚳したものです。この蚘事は゜リュヌションアヌキテクトの倏堀京叞が翻蚳したした。
本ブログは 2024 幎 11 月 24 日に公開された AWS Public Sector ブログ Deploying AWS Modular Data Center: From ordering to delivery and installation を翻蚳したものです。 Amazon Web Services (AWS) Modular Data Center (MDC) ずは、AWS のマネヌゞドデヌタセンタヌを迅速にデプロむするサヌビスで、むンフラが限られた堎所でも、ロケヌション䟝存型アプリケヌションやレむテンシヌ䟝存型アプリケヌションの実行が可胜になりたす。遠隔地でのデプロむ時間を短瞮し、最倧 5 ラック の AWS Outposts や AWS Snow Family デバむスを収容したす。MDC は 20 フィヌトの茞送甚コンテナ 2぀で構成され、ICD-705 米囜の情報機関が機密情報を扱う斜蚭の物理的・技術的セキュリティ基準を定めた指什準拠のシヌルド筐䜓に配電機胜、冗長冷华 (N+1)、セキュリティ、監芖、消火蚭備など、重芁なむンフラ芁玠を備えたデヌタセンタヌずしお機胜する自己完結型゜リュヌションです。AWS MDC サヌビスは、珟堎で䜎遅延のアプリケヌションを実行する必芁があるものの、デヌタセンタヌを眮く十分なスペヌスがないお客様向けに蚭蚈されたものです。䟋えば、防衛、囜家安党保障、人道支揎機関では、MDC を導入するこずで蚈算負荷の高いワヌクロヌドやストレヌゞ負荷の高いワヌクロヌドをタクティカル゚ッゞで実行でき、AI や機械孊習によっお倧量のデヌタ凊理を行い、わずかな遅れも蚱されない状況でもリアルタむムの意思決定が可胜になりたす。 本投皿では、MDC を導入するための゚ンドツヌ゚ンドのプロセスに぀いおご説明したす。合わせお、 Amazon Web Services (AWS) ずお客様の圹割や責任の分担に぀いおも解説し、デプロむメントの成功、運甚可甚性の向䞊、セキュリティ䜓制の匷化に向けお明確な指針を提䟛したす。サむトぞの MDC の導入方法を 6 ぀のステヌゞで瀺しおおりたすので、ぜひ最埌たでお読みください。  6 ぀のデプロむステヌゞ 導入方法はお客様ごずに異なるものです。そのため、AWS はお客様ずプロセス党䜓で垞に緊密に連携し、MDC の玍入を確実か぀円滑に行いたす。MDC のデプロむプロセスは次の 6 ぀のステヌゞで構成されたす。 リク゚ストの送信 珟地調査結果の確認および珟地準備 発泚承認 玍品 蚭眮および詊運転 政府セキュリティ認定 図 1.MDC 導入の工皋: ゚ンドツヌ゚ンドの党 6 ステヌゞ。 以䞋では、各ステヌゞの詳现を説明したす。導入プロセスを理解いただくこずで、効率的な準備にお圹立おください。 泚以䞋のプロセスはアメリカ囜内のお客様を察象ずした説明ずなっおおり、たた、日本のお客様にはアクセスができないURL等がございたす。ご䞍明な点がありたしたらAWSアカりントチヌムたでお問い合わせ䞋さい ステヌゞ 1: リク゚ストの送信 このプロセスでは、お客様固有のニヌズに察応するためのコンサルティングを行いたす。たず、 AWS マネゞメントコン゜ヌル の AWS MDC ペヌゞからお問い合わせフォヌムに入力いただき、AWS に送信したす (図 2)。フォヌムを送信埌、2 営業日以内に AWS からプラむマリアカりントオヌナヌにご連絡いたしたす。組織内でプラむマリアカりントオヌナヌが䞍明の堎合は、AWS アカりントチヌムたでお問い合わせください。 このステヌゞでは、AWS はお客様ず連携しお、MDC のナヌスケヌスを明確にし、サむト準備アンケヌトなどで蚭眮サむトの情報を収集したす。これには、むンフラの䟝存関係を特定するために、導入堎所、気象条件、電力、ネットワヌク接続、セキュリティ芁件などのサむト特性に関する情報も含たれたす。たた、お客様のニヌズに最適な MDC 構成ず AWS Outposts たたは AWS Snowball Edge のデバむス容量を決定するためのお手䌝いもしたす。事前定矩された構成がお客様のニヌズに合わない堎合は、お客様の芁件に合わせたカスタム構成を䜜成するために協力させおいただきたす。 図 2.AWS マネゞメントコン゜ヌルのお問い合わせフォヌム。 ステヌゞ 2: 珟地調査結果の確認および珟地準備 お客様からのリク゚ストずサむト情報の確認埌、AWS の技術者たたは AWS の資栌を持぀技術者を掟遣し、サむト準備アンケヌトの内容を基に珟地調査を実斜したす。この珟地蚪問は、そのサむトが MDC の各芁件 (以䞋の䞀芧参照) に察応しおいるかを確認するこずが目的ずなりたす。そのため、珟地蚪問にあたり、お客様には AWS チヌムに珟地の連絡先ず立ち入り暩限をご提䟛いただく必芁がありたす。珟地では、蚭眮を進めるための情報を収集し、MDC 蚭眮前に解決すべき問題を特定したす。珟地調査を完了したのち、その結果を確認し、サむトの準備に向け远加察応が必芁な堎合はお客様にお知らせしたす。サむトの MDC 蚭眮芁件ぞの察応は、お客様の責任においお行っおいただくものですが、AWS は察応を完了しおいただくための必芁な情報を提䟛し、蚭眮前には珟地の状況を確認させおいただきたす。サむトでの MDC の蚭眮ず詊運転を行うにあたり、お客様には AWS のチヌムず協力の䞊、圓該サむトがすべおの芁件を満たしおいるかどうかを確認し、珟地調査結果の怜蚌をすべおクリアしおいただく必芁がありたす。 カテゎリ 芁件 蚭眮堎所 (据付面) 蚭眮には、20 フィヌト × 30 フィヌトのコンクリヌト基瀎面たたは砕石地盀が必芁。 離隔スペヌス MDC 蚭眮面積は 16 フィヌト × 20 フィヌト (4.9 m x 6.1 m)。党呚囲に少なくずも 8 フィヌト (2.4 m) の保守スペヌスを確保。ラック搬入を容易にするため、゚リア党䜓においおフォヌクリフトなどの荷圹機噚の移動が可胜であるこず。 耐荷重 MDC の蚭眮および撀去を行う堎所ず搬入動線は、MDC、荷圹機噚、配送車䞡の合蚈重量に耐えられるこず。蚭眮堎所の据付面そのものは、沈䞋するこずなく最䜎 50,000ポンドの耐荷重があるこず。 耐震補匷 斜蚭ぞの MDC 蚭眮期間䞭は、芏制たたは建築基準法で定める範囲においお、適切な耐震ブレヌスたたはアンカヌの蚭眮、維持が必芁。 斜蚭ぞのアクセス MDC 蚭備に察し、AWS による MDC ぞの物理的アクセス、保守、MDC の撀去を阻害するような倉曎を行わないこず。フェンスやセキュリティカメラなどの远加のセキュリティ察策が必芁な堎合は、AWS の担圓者たでご盞談ください。 枩床および湿床 呚囲の倖気枩は -20°F (-30°C)127°F (53°C) の範囲ずし、盞察湿床は 5%95% であるこず。MDC を屋内に蚭眮する堎合、十分な空気埪環を行い、動䜜䞭は䞀定の枩床ず湿床の範囲を維持するこず。 暙高 MDC の蚭眮堎所は、海抜 10,000フィヌト (3,050メヌトル) 未満の暙高にあるこず。 電源 二重化構成の堎合、MDC には䞉盞 400/480 VAC、50/60Hz、175A の電源が 2 系統必芁。冗長性を䞋げた構成の堎合は、単䞀の電源系統で動䜜可胜。 ネットワヌク MDC のネットワヌク芁件は、お客様のニヌズによっお異なる堎合がありたす。AWS の担圓者たでご盞談ください。MDC のネットワヌクラックには、お客様支絊のネットワヌク機噚および暗号化ハヌドりェアを最倧 10U たで収容可胜。ラックはUPSで保護された冗長A+B電源の䟛絊も可胜。 サむトの芁件に぀いお、より詳しくは AWS Modular Data Center User Guide をご参照ください。 ステヌゞ 3: 発泚承認 珟堎調査結果の確認埌、サヌビス利甚芏玄に同意いただき、発泚曞の発行をもっお発泚手続きを完了したす。そこから、MDC の構築、事前蚭定、出荷準備をサヌビスチヌムが行いたす。MDC は補造プロセス完了埌、お客様の珟地ご担圓者ず玍品日および蚭眮日を調敎したうえで出荷されたす。 ステヌゞ 4: 玍品 MDC の準備が敎い次第、ナニットを珟地に配送し、組み立おず蚭眮䜜業を行うための調敎をお客様ず進めたす。MDC は、䞍正開封防止シヌルや䞍透明梱包など、暙準的な商業甚セキュリティ察策を講じお非機密扱いずしお出荷されたす。機密扱いでの配送が必芁な堎合は、お客様ず連携のうえ、MDC を米囜本土 (CONUS) の空枯たたは出発枯たで護送する運送業者の手配もお手䌝いいたしたす。MDC の茞送は、車䞡、鉄道、船舶、軍甚機 (C-17 たたは C-5 のみ) から遞択できたす。 AWS は、運送業者ずの調敎、積み蟌みおよび荷降ろし䜜業、お客様のサむトぞの MDC の配送を含む、CONUS 内での茞送ず物流の統括責任を負いたす。たた、珟堎芁件を満たした氎平な据付面䞊に MDC を蚭眮するためのクレヌンやフォヌクリフトなどの重機も手配したす。サむトが米囜本土倖 (OCONOUS) である堎合、運送業者ずの調敎、積み蟌みおよび荷降ろし、配送、登録茞入者ずしおの手続きなど、茞送ず物流に関する察応はお客様にお行っおいただきたす。たた、MDC を氎平な据付面䞊に蚭眮するための機噚類もお客様手配ずなりたす。  ステヌゞ 5: 蚭眮および詊運転 MDC の蚭眮は、AWS チヌムがサむトに到着し、お客様の指定担圓者ず到着確認を行った埌すぐに開始されたす。荷解き䜜業を開始する前に、AWS チヌムが最終的なサむト確認を実斜し、珟地の状況が MDC の芁件に合臎しおいるかをあらためお確認したす。 ã‚µã‚€ãƒˆãŒå¿…芁な芁件を満たしおいない堎合、䜜業は延期ずなりたす。䜜業を延期するこずがないよう、お客様には MDC の玍品前にサむト準備䜜業をすべお完了いただくこずが極めお重芁です。 ãŸãŸã€AWS チヌムがサむトにアクセスするための蚱可手続きは、お客様偎で行っおいただく必芁がありたす。MDC をデプロむする堎所に AWS がアクセスできない堎合、AWS のサポヌトが限定される堎合がありたす。 AWS チヌムが MDC を指定のコンクリヌトたたは砕石基瀎に配眮し、組み立おず蚭眮を進めたす。所芁期間はサむトの状況にもよりたすが、通垞 1〜2 週間です。機噚類および電気システムを含むすべおの MDC コンポヌネントの組み立お、蚭眮、テストは、AWS にお管理したす。たた、AWS が提䟛する機噚に䜿甚するすべおの光ファむバヌは、AWS が準備し、MDC 内に敷蚭したす (電気蚭備の怜査やテストも含みたす)。お客様には、MDC を正垞に動䜜させるための、電源、ネットワヌク、緊急管理システム甚など、すべおの倖郚ファむバヌケヌブルず電源ケヌブルを甚意いただき、接続䜜業を察応いただきたす。蚭眮䜜業時においお MDC ぞの接続および通電は、お客様偎の有資栌電気技術者が実斜するこずが矩務付けられおいたす。お客様は、AWS 起動手順のほか、関連法什、電気芏皋、建築消防法芏に埓っお MDC ぞの通電ず接続を実斜する責任を担いたす。 詊運転が完了するず、メンテナンスサヌビスが開始されたす。MDC は物理的にお客様のサむトに蚭眮されおいるため、本䜓のメンテナンスは AWS ずお客様ずの責任共有ずなりたす。AWS は、AWS の技術者たたは AWS 認定の技術者による定期怜査や修理など、予防および是正保守を提䟛したす。重芁なスペアパヌツの準備、保管も行い、玍品に時間がかかる郚品類でもすぐに䜿えるよう垞備したす。さらに AWS は MDC 内に消火システムを蚭眮し、この保守も行いたす。お客様は MDC の定期的な怜査、監芖を行い、゚ラヌ状態が発生した際は AWS に速やかに報告する責任を負いたす。たた、問題発生時にはサむト垞駐担圓者にアラヌト発報するよう、消火・譊報システムずオペレヌションセンタヌを接続しおおき、即時察応を培底する必芁がありたす。MDC の物理的なセキュリティ維持もお客様偎の責任ずなりたす。なお、MDC にはモニタリングシステムが組み蟌たれおいたす。MDC を AWS リヌゞョン に接続するず、 Amazon CloudWatch ず連携でき、MDC の状態をリモヌト監芖できたす。 MDC は、ICD-705 に基づく機密情報隔離斜蚭 (SCIF) の芁件を満たすように蚭蚈されおおり、TS/SCI (Top Secret/Sensitive Compartmented Information ) レベルたでのデヌタをホストする認定を取埗するこずができたす。MDC は、電磁波盗聎察策 (TEMPEST)、無線呚波数 (RF) シヌルドに加え、音響や熱に関する各皮芁件に完党準拠した構築、詊隓が行われおいたす。MDC を SCIF ずしお認定する必芁がある堎合、AWS は詊運転の完了埌に、お客様の承認担圓者 (AO) が実斜する認定審査に察応できる状態に準備したす。適切な AO の遞定ず必芁な認定取埗は、お客様の責任にお進めおいただきたす。 ステヌゞ 6: 政府セキュリティ認定 特定の政府機関で MDC を䜿甚する堎合、お客様は適切な AO から必芁な運甚暩限 (ATO) や接続暩限 (ATC) を取埗する必芁がありたす。認定の手続きにおいお、AWS は必芁な曞類を提䟛し、お客様をサポヌトしたす。認定が必芁な堎合、MDC に収容する機密ワヌクロヌド甚の AWS ラックの蚭眮およびテストは、必ず認定取埗埌に実斜するこずになりたす。認定が䞋り次第、ラックの蚭眮が可胜になり、AWS が MDC 内の AWS ラックの組み立お、蚭眮、テストを行いたす。  たずめ 本投皿では、リク゚ストの送信から玍品、蚭眮たで、AWS Modular Data Center をデプロむするための 6 ぀のステヌゞに぀いお説明したした。MDC の導入をスムヌズに達成するためには、各ステヌゞで以䞋のポむントを抌さえるこずが重芁です。  リク゚ストの送信 — AWS マネゞメントコン゜ヌルのお問い合わせフォヌムにご蚘入ください。お客様の芁件をもずに、AWS ず連携しお MDC の構成を確定させたす。たた、サむト準備アンケヌトにもご回答いただきたす。 珟地調査結果の確認および珟地準備 — AWS ずずもに珟地調査を実斜したす。珟地調査の結果から、サむトに必芁な䜜業を行い、MDCの蚭眮ず詊運転の前に完了させたす。 発泚承認 — サヌビス利甚芏玄ぞの同意ず発泚曞の発行をもっお発泚を確定したす。AWS は MDC の構築、事前蚭定、出荷準備に進みたす。 玍品 — 茞送、物流は AWS ずの調敎が必芁です。サむトが米囜本土倖の堎合は、物流ず重機類はお客様にお手配いただきたす。たた、サむトが MDC の到着を受け入れ、蚭眮を開始できる状態にしおおきたす。 蚭眮および詊運転 — AWS がサむトに立ち入るためのアクセス暩を確保いただきたす。蚭眮チヌムが䜜業できるよう、電源接続をご準備ください。MDC の組み立お、蚭眮、テストは AWS が実斜したす。 政府セキュリティ認定 — 認定が必芁な堎合は、お客様の AO から ATO および/たたは ATC を取埗しおください。AWS はドキュメンテヌションを支揎し、認定取埗埌にラックの蚭眮を完了したす。 泚意: AWS Modular Data Center は珟圚、米囜 Joint Warfighting Cloud Capability (JWCC) 契玄に基づく政府機関のお客様のみがご利甚いただけたす。AWS Modular Data Center は珟圚、AWS GovCloud (米囜西郚) リヌゞョンず AWS GovCloud (米囜東郚) リヌゞョンでサポヌトされおいたす。 AWS Modular Data Center の詳しい情報は、お客様の AWS アカりント担圓者たでお問い合わせください。 タグ:  Amazon CloudWatch ,  AWS GovCloud (US) ,  AWS Management Console ,  AWS Outposts ,  AWS Public Sector ,  AWS Snow Family ,  AWS Snowball Edge ,  defense ,  government ,  security ,  storage ,  technical how-to
2026 幎 8 月 4 日、「補薬䌁業向け Claude Code on AWS ワヌクショップ 〜創薬研究を加速する AI コヌディング゚ヌゞェントの掻甚〜」を開催したした。10 瀟以䞊の補薬䌁業から創薬研究者ず研究 IT のご担圓者にお集たりいただき、ハンズオンを䞭心に、実際に Claude Code on AWS の導入を進める第䞀䞉共株匏䌚瀟ずファヌマ株匏䌚瀟、および Anthropic Japan 合同䌚瀟による登壇セッションも実斜したした。 参加者は、AI コヌディング゚ヌゞェントを初めお䜿う方から、既に研究業務で Claude Code を掻甚しおいる方たで様々でしたが、アンケヌト回答 47 件の総合満足床は 4.70 / 5.00 であり、「ワヌクショップに参加しお䞖界が倉わった」「わずか半日で欲しい研究アプリが䜜れたこずに感動した」「自瀟で利甚しおいく際のむメヌゞが掎めた」ずいった声をいただくなど高い評䟡をいただくこずができたした。 本蚘事では、むベントの背景や圓日の様子をお届けいたしたす。 目次 ワヌクショップのゎヌル 開催の背景AI for Science の珟圚地ず実践 ハンズオンの内容: 創薬研究の仕事はどう倉わるか ハンズオン実行環境Claude Code を組織で安党に掻甚するには お客様登壇: 先行する創薬研究珟堎での実践 第䞀䞉共株匏䌚瀟 ファヌマ株匏䌚瀟 Anthropic Japan 合同䌚瀟様登壇: 研究者自身が AI ゚ヌゞェントを䜿う意矩 䜓隓を組織の実践ぞ たずめ ワヌクショップのゎヌル 本ワヌクショップが目指したのは、Claude Code の现かな機胜やプロンプト技法の習埗ではありたせん。参加者自身の研究テヌマや興味のある題材を甚いお、AI ずずもに創薬研究の様々な業務に取り組み、研究の進め方や研究者の圹割がどう倉わるかを䜓感しおいただくこずです。䜕を AI に任せられ、䜕を人間が行うべきかは、実際の業務に近い領域で䜿い蟌んでこそ初めお芋えおきたす。そのため、いち早く実践を始め、 AI が創薬研究にもたらす可胜性ず人が担うべき圹割を芋極め、今埌の研究の進め方を考える契機にしおいただくべく、本ワヌクショップを䌁画したした。 開催の背景AI for Science の珟圚地ず実践 ラむフサむ゚ンス業界を取り巻く珟状ずしお、AI ãŒå…·äœ“的な創薬成果に぀ながり始める䞀方、組織展開には倧きな隔たりがありたす。  Deloitte ç€Ÿã®èª¿æŸ» によるず、ヘルスケア・ラむフサむ゚ンス䌁業を察象ずした調査で、AI ã‚’うたくスケヌルできたずの回答は 22%、AI ãžã®å–り組みで倧きなビゞネス成果を埗たずの回答はわずか 9% ã«ãšã©ãŸã‚ŠãŸã—た。その䞀方で、䟋えば Insilico Medicine は AI ã§å‰µå‡ºã—た特発性肺線維症の治療薬候補に぀いお  Phase III è‡šåºŠè©Šéš“を開始したず発衚 しおいるなど、AI æŽ»ç”šã‚’実際の創薬成果に繋げる䌁業ず展開に苊戊する䌁業ずの差が開き぀぀ありたす。 䞀床の回答から情報収集、蚈画、䜜業、怜蚌ずいう䞀連の仕事ぞず広げる AI ゚ヌゞェントは、仮説を立お解析や実隓を行う創薬研究ずも重なり、研究者は問いず刀断に集䞭するずいう新しい圹割分担を可胜にしたす。ただ倚くの䌁業が同じフロンティアモデルを利甚できるいた、差を生むのはモデル性胜やツヌル導入ではありたせん。自瀟の知芋や業務の型を AI ゚ヌゞェントに正確に䞎え、AI ゚ヌゞェントに䜕を任せどこで人が介入するかを蚭蚈しお初めお、研究珟堎で倧きな成果を生む圢になりたす。こうした蚭蚈の力は、実際に近い業務で詊行錯誀しなければ䜓埗できず、その第䞀歩になればず今回のむベントの䌁画に繋がりたした。 今回題材ずしたのは、Anthropic が開発する代衚的な AI コヌディング゚ヌゞェントである Claude Code です。コヌド生成に限らず、調査や分析、成果物の䜜成など研究の様々な業務で掻甚できたす。AWS ず Anthropic は戊略的協業を結んでおり、AWS は Anthropic のプラむマリクラりドプロバむダヌずしお、お客様が Claude をセキュアか぀倧芏暡に掻甚できる環境を提䟛しおいたす。 ハンズオンの内容: 創薬研究の仕事はどう倉わるか ハンズオンは二郚構成でした。前半では研究䞊の刀断を支える調査ずレポヌト䜜成を行い、埌半ではその刀断プロセスないし関心のある研究業務を Web アプリケヌションずしお AWS 䞊に構築したした。甚意されたプロンプトを順番に貌り付けるのではなく、参加者自身が目的ず基準を蚀葉にし、Claude Code に䜜業を任せ、結果を確かめながら方向を調敎したした。詳しいシナリオや圓日の操䜜手順に興味のある方は、 こちらの URL をご芧ください。 前半の題材は、薬の䜜甚先ずなる耇数の分子候補の䞭から研究で優先するものを遞定する「Target Prioritization ( 暙的の優先順䜍付け) 」です。䟋えば 「原発性高コレステロヌル血症」ずいう疟患では、 HMGCR、NPC1L1、PCSK9 などが暙的候補ずなりたすが、察象患者、既存治療ずの違い、安党性など、重芖する基準を耇数定めるこずによっおアプロヌチするべき候補の優先順䜍が倉わりたす。 今回、創薬研究者の方々には、関心のある疟患や実際の研究テヌマを自ら遞んでいただき、遞定基準ず 2〜5 ä»¶ã®æš™çš„候補を Claude Code ãšå¯Ÿè©±ã—ながら決めおいただきたした。創薬研究に銎染みのない方には、AWS åŽã§äº‹å‰ã«ã‚·ãƒŠãƒªã‚ªã‚’甚意したした。 テヌマず基準が固たるず、Claude Code が Open Targets、Europe PMC、ClinicalTrials.gov などの公開 API や、AWS が幅広いオヌプンデヌタの公開ず利甚を支揎する Registry of Open Data on AWS に掲茉されたデヌタセットも参照しながら根拠を集め、候補比范のレポヌトを䜜成したす。参加者は出兞や反蚌を確認し、条件を倉えた際の順䜍を怜蚌しながら、刀断の理由ず䞍確実性を刀断メモにたずめおいきたした。 実際のハンズオン操䜜画面。研究アシスタントずしお動く Claude Code右偎ず察話しながら、Target Prioritization の分析レポヌト巊偎を䜜成しおいきたす。 埌半では、前半の刀断プロセスや参加者が関心を持぀研究業務を題材に、AI ゚ヌゞェントが動くアプリケヌションを AWS 䞊に構築したした。Claude Code の質問に答えながら芁件を固め、蚭蚈曞を確認しお GO を出すず、コヌド䜜成、テスト、むンフラ構築、デプロむたでが進みたす。参加者はコヌドを曞かず、䜜るものを人ず AI で合意しおから実装ぞ進むプロセスを䜓隓したした。 ハンズオン実行環境Claude Code を組織で安党に掻甚するには 圓日は、Claude の呌び出しに Amazon Bedrock を利甚したした。Amazon Bedrock では、入力ず出力はモデル提䟛者に共有されず、基盀モデルの孊習にも䜿甚されたせん。 AWS IAM による暩限管理、 AWS CloudTrail による操䜜蚘録、 AWS PrivateLink によるプラむベヌト接続など、既存の AWS のセキュリティ統制の䞭で Claude Code を利甚できたす。さらに、デヌタレゞデンシヌ芁件がある堎合は、察応モデルで 日本囜内クロスリヌゞョン掚論 (Japan Cross Region Inference) を利甚するこずで、掚論凊理を囜内リヌゞョンに限定しデヌタを日本囜内に留めるこずもできたす。 䞀方、組織ぞの展開には、モデル利甚のガバナンスや、䌚瀟支絊 PC ãžã®å°Žå…¥ã€ç ”究デヌタの扱い、認蚌・暩限、利甚者ごずの環境差ずいった課題がありたす。研究郚門の方々ず普段お話しするなかでも、こうした点が個人の詊行から組織利甚ぞ進む際の壁ずしお挙がりたす。 それを解決する遞択肢の䞀぀が、今回利甚した RADS ( Remote AWS Development Station ) です。 RADS は、 Amazon EC2 ベヌスのクラりドワヌクステヌションを Web ポヌタルから構築・管理するこずができる AWS 公匏サンプル実装であり、 GitHub で公開 されおいたす。Web ポヌタルから Claude Code などがむンストヌルされた AI コヌディング環境を䜜成・起動・停止し、Amazon DCV によるリモヌトデスクトップ、ブラりザの Code Editor、SSH 等で接続しお䜿うこずができたす。以䞋のような特城がありたす。 AI 環境がプリセット枈みClaude Code などを Amazon Bedrock 向け蚭定蟌みで導入枈み API キヌ配垃や初期蚭定が䞍芁ワヌクステヌション (EC2) の IAM ロヌル経由で自瀟アカりント内の Bedrock を呌び出す PC を閉じおも皌働継続長時間タスクを゚ヌゞェントに任せられ、マシン性胜も倉曎可胜 ロヌカルに圱響しないサンドボックス: 各環境が独立した EC2 むンスタンスのため手元の PC に圱響が及ばない お客様登壇: 先行する創薬研究珟堎での実践 圓日は、ハンズオンでの䜓隓を実際の業務ぞ぀なげる材料ずしお、Claude Code on AWS の研究珟堎ぞの導入・展開を進める 2 瀟に、研究郚門ず IT 郚門それぞれの芖点からご登壇いただきたした。 第䞀䞉共株匏䌚瀟 第䞀䞉共株匏䌚瀟の田村様からは、「Coding Agent で倉わる創薬 DRY 解析」ず題しおご発衚いただきたした。田村様が所属されおいる研究郚門にお取られた DRY 研究員ぞの瀟内アンケヌトでは、92% が「Coding Agent がなくなるず業務に圱響する」、85% が「時間やスキルが理由で以前はできなかった業務を遂行できた」ず回答したずのこずです。具䜓䟋ずしお、十分な䜜業時間を確保できず、4 か月間着手できずにいた倧量の化合物デヌタの SAR 解析を Claude Code ずの察話で玄 1 時間で完了した事䟋や、100 件以䞊の非構造情報を含む文献や特蚱からデヌタを抜出した事䟋、 AWS Parallel Computing Service (AWS PCS) ず連携した解析の取組みなどを玹介いただきたした。たた、定型業務は Agent Skills や プラむベヌト Plugins ずしお GitHub 䞊のプラむベヌトレポゞトリで共有し、個人の成功パタヌンをチヌムで再利甚できる仕組みも敎備されおいたす。ハルシネヌションを 100% 防ぐこずは原理䞊できなくおも、埌段の解析や実隓で結果を怜蚌できるため、創薬研究は AI ゚ヌゞェントを掻甚しやすい領域ではないかずの芋解も瀺されたした。 ファヌマ株匏䌚瀟 ファヌマ株匏䌚瀟の東本様からは、「Claude Code on AWS で創薬研究・業務を加速する」ず題しおご発衚いただきたした。チャット型 AI では、提瀺された手順やコヌドの実行、゚ラヌ察応を利甚する人間偎が担わねばなりたせん。AI ゚ヌゞェントは、䜜成・テスト・修正たでを自ら進めたす。その様子を AWS から提䟛したワヌクショップで実際に䜓感されたこずで、自埋実行ぞの懞念から、埓来の手間を解決できるずいう芋方ぞ倉わったずいいたす。 導入には、自瀟の AWS 環境から Amazon Bedrock 経由で Claude を利甚する構成を遞択したした。囜内でのデヌタ保管、既存のセキュリティ運甚の螏襲、埓量課金で小さく始められるこずが決め手ずなり、AWS のむベントで䜓隓しおから玄 10 日でリリヌスに至りたした。研究者が環境構築や゚ラヌ察応から離れ、解析そのものに集䞭できる環境を敎えられたずのこずでした。実際に觊れるこずが、構成の刀断ず迅速な導入に぀ながった事䟋です。 詳しくはご寄皿いただいた こちらの蚘事 もご参照ください。 Anthropic Japan 合同䌚瀟様登壇: 研究者自身が AI ゚ヌゞェントを䜿う意矩 2 瀟の実践に続き、Anthropic Japan 合同䌚瀟の枡郚様には「信頌できるフロンティア AI」ず題しおご登壇いただきたした。Constitutional AI を含むモデル蚭蚈、胜力の向䞊に応じお安党察策を匷化する責任あるスケヌリング、顧客デヌタを孊習に䜿甚しない方針など、芏制産業で掻甚するための信頌性ぞの取り組みず、Anthropic が䞀般提䟛する䞭で最も高性胜なモデルである Claude Fable 5 の最新動向が玹介されたした。 Claude Code ã®ãƒãƒƒã‚«ã‚œãƒ³ã€ŒBuilt with Opus」では、入賞した䞊䜍 5 çµ„のうち 4 çµ„が職業゚ンゞニアではない非技術者だったずいいたす。実装の障壁が䞋がる珟圚、課題を深く理解しおいる人の知芋が成果を巊右するこずを瀺す 1 ã€ã®äº‹äŸ‹ãšèš€ãˆã‚‹ã§ã—ょう。創薬研究でも、ドメむン゚キスパヌトである研究者自身が゚ヌゞェントを䜿い、課題蚭定ず評䟡を担うこずが成果を生み出す鍵になりたす。 䜓隓を組織の実践ぞ クロヌゞングでは、このハンズオンの䞭で、䜕故短い指瀺から゚ヌゞェントが䞀連の䜜業を進められたのか、その背景をご玹介したした。今回のハンズオンでは、察象ずする業務の前提や刀断基準をコンテキスト CLAUDE.md などずしお䞎え、定型䜜業を Agent Skills ずしお登録し、MCP で研究デヌタベヌスや文献怜玢のツヌルに぀なぎ、蚈画・実行・怜蚌たでのルヌプを回す仕組みをあらかじめ蚭蚈し、参加者がハンズオンで利甚する操䜜環境のなかに組み蟌んでいたした。参加者には、その土台の䞊で Claude Code を䜿い䞀連の操䜜を進めおいただきたした。こうしたモデル呚蟺の仕組みは䞀般に「ハヌネス」ず呌ばれたす。 同じモデルを利甚できおも、瀟内の知芋、業務手順、システムずの接続は䌁業ごずに異なりたす。今回の環境のように、自瀟の知芋や業務の型をハヌネスに組み蟌み、実際に䜿いながら継続的に曎新するこずで、モデルの進化を研究珟堎の成果ぞ玠早く反映できたす。その準備には、今から䜿い、孊び、改善を重ねる時間が必芁です。 ゚ヌゞェントが䞀連の䜜業を担うず、人はルヌプの䞭ですべおの工皋を実行する立堎から、ルヌプの䞊で目的ず進め方を蚭蚈し、結果を監督する立堎ぞ移りたす。任せる範囲を決め、結果に責任を持぀のは匕き続き人です。目指すのは、䞀工皋ず぀数十 % ã®åŠ¹çŽ‡åŒ–ã‚’ç©ã¿äžŠã’ã‚‹ã ã‘ã§ãªãã€ä»•äº‹ã®åœ¢ãã®ã‚‚ã®ã‚’çµ„ã¿æ›¿ãˆãŠæ•°åå€ã®æˆæžœã‚’ç”Ÿã¿å‡ºã™ã“ãšã§ã™ã€‚ では、こうした倉化に向けお䜕から始めるべきでしょうか 今回の参加者には、䜓隓を各瀟ぞ持ち垰り、参加できなかった方も含めお、自瀟の研究テヌマで AI に䜕を任せ、人がどこで刀断するかを話し合う機䌚を䜜っおいただきたいずお願いしたした。察象者・人数・題材などを芁望に合わせお、AWS ずずもに個瀟向けワヌクショップを䌁画・実斜するこずも、その議論を具䜓化する遞択肢になりたす。 たた、今の人間䞭心の業務のやり方を倉えおいくこずも重芁です。業務プロセスを AI ã‚šãƒŒã‚žã‚§ãƒ³ãƒˆå‰æã«çµ„み替える  AI-BPR (AI-driven Business Process Re-Engineering)  や、開発サむクル党䜓を AI äž»å°Žã§é€²ã‚ã‚‹  AI-DLC(AI-driven Development Life Cycle; AI 駆動開発ラむフサむクル)  の実践が遞択肢の䞀぀です。さらに、今回利甚した RADS ãªã©ã‚’掻甚しお、 Claude Code on AWS ã‚’組織的に利甚・展開できる環境を早期に敎えるこずで、個人の䜓隓を組織の倉革ぞ぀なげられたす。 AWS は、お客様ずずもに課題ず目指す姿を敎理し、進め方の怜蚎から実践、展開たで支揎しおいきたす。 たずめ Claude Code ã®ã‚ˆã†ãª AI ã‚³ãƒŒãƒ‡ã‚£ãƒ³ã‚°ã‚šãƒŒã‚žã‚§ãƒ³ãƒˆãŒå€‰é©ã™ã‚‹ã®ã¯ã€è§£æžã‚³ãƒŒãƒ‰ã®æ›žãæ–¹ã§ã¯ãªãã€å‰µè–¬ç ”究の進め方そのものです。AI ãŒèª¿æŸ»ã‚„実装を担い、研究者が問いず刀断に集䞭する働き方は、すでに珟実になり぀぀ありたす。 その倉化を先取りするには、いち早く自らの研究テヌマで觊り、AI ãžã®ä»»ã›æ–¹ãšäººã®åˆ€æ–­ã‚’組織で孊ぶこずが欠かせたせん。AI コヌディング゚ヌゞェントが自瀟の創薬研究をどう倉え埗るのか、たずは実際の題材で確かめおみおください。 AWS は、こうしたワヌクショップを起点に、AI ゚ヌゞェントぞの理解ず掻甚を組織に広げ、プロセスの倉革ず創薬加速に぀なげる取り組みを今埌も支揎しおいきたす。ワヌクショップの実斜やその先の組織展開などにご関心をお持ちの方は、担圓の AWS アカりントチヌムたでご盞談ください。 執筆者 森䞋 裕介 (Yusuke Morishita) ラむフサむ゚ンス領域や医療機噚領域のお客様を担圓する゜リュヌションアヌキテクトです。医甚画像の機械孊習研究を経お、珟圚は生成 AI や AI ゚ヌゞェント領域を埗意分野ずしお掻動しおいたす。趣味は旅行ず映画鑑賞。 原田 裕平 (Yuhei Harada) 補薬・ラむフサむ゚ンス領域のお客様を担圓し、AI ゚ヌゞェントを掻甚した研究開発の高床化や、近幎は Physical AI 分野での掻動も粟力的に行っおいたす。 石尟 千晶 (Chiaki Ishio) 補薬・医薬品卞領域のお客様を担圓し、クラりドや生成 AI の掻甚の技術支揎を行っおいたす。 川合 広喜 (Hiroki Kawai) 䞻に補薬業界のお客様を䞭心に営業支揎を行っおおりたす。クラりド移行から生成 AI の掻甚たで、お客様の課題に応じたご支揎を心掛けおいたす。 亀田 俊暹 (Toshiki Kameda) ヘルスケア・ラむフサむ゚ンス事業開発郚 シニア事業開発マネヌゞャヌ。補薬業界で 20 幎以䞊の経隓を持ち、特にメディカルアフェアヌズ、コマヌシャルず補薬デゞタル戊略 (DTx 含む) を埗意ずしおいたす。慶應矩塟倧孊で医療政策・管理孊の博士号を取埗し、ポスドク研究員ずしお医療デヌタ分析、アりトカムリサヌチを孊びたした。趣味はドラむブず BBQ。