AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3656ä»¶

8 月 6 日、 AWS re:Invent 䞭にプレビュヌした 新しい Amazon Bedrock のガヌドレヌル ポリシヌである自動掚論チェックの䞀般提䟛が開始されたこずをお知らせしたす。自動掚論チェックは、 基盀モデル (FM) によっお生成されたコンテンツの正確性をドメむンの知識に照らしお怜蚌するのに圹立ちたす。これは、AI のハルシネヌションを理由ずする事実誀認を防ぐのに圹立ちたす。このポリシヌは、数孊的ロゞックず圢匏怜蚌の手法を甚いお正確性を怜蚌し、AI の応答の正確性をチェックするための明確なルヌルずパラメヌタを提䟛したす。 このアプロヌチは、結果に確率を割り圓おるこずで䞍確実性に察凊する確率的掚論手法ずは根本的に異なりたす。実際、自動掚論チェックは最倧 99% の怜蚌粟床を実珟し、AI のハルシネヌションの怜出においお蚌明可胜な保蚌を提䟛するず同時に、モデルの出力に぀いお耇数の解釈が可胜である堎合の曖昧性の怜出にも圹立ちたす。 䞀般提䟛の開始に䌎い、次の新特城量をご利甚いただけたす: 1 回のビルドにおける、最倧 80,000 トヌクンの倧芏暡ドキュメントのサポヌト – 膚倧なドキュメントを凊理したす。これは、最倧 100 ペヌゞ分のコンテンツに盞圓したす 簡玠化されたポリシヌ怜蚌 – 怜蚌テストを保存しお繰り返し実行したす。これにより、時間が経過する䞭でポリシヌを維持および怜蚌するこずがより容易になりたす シナリオの自動生成 – 定矩からテストシナリオを自動的に䜜成するこずで、カバレッゞをより包括的なものずしながら、時間ず劎力を削枛できたす 匷化されたポリシヌフィヌドバック – ポリシヌの倉曎に関しお自然蚀語での提案を提䟛するこずで、ポリシヌの改善を簡玠化したす カスタマむズ可胜な怜蚌蚭定 – 特定のニヌズに合わせお信頌スコアのしきい倀を調敎するこずで、怜蚌の厳密さをより现かく制埡できたす これが実際にどのように機胜するのかを芋おみたしょう。 Amazon Bedrock のガヌドレヌルでの自動掚論チェックの䜜成 自動掚論チェックを䜿甚するには、たずナレッゞドメむンのルヌルを自動掚論ポリシヌに゚ンコヌディングしおから、そのポリシヌを䜿甚しお生成されたコンテンツを怜蚌したす。このシナリオでは、誰が䜏宅ロヌンの利甚資栌を埗るこずができるかを評䟡する AI アシスタントを保護するための䜏宅ロヌン承認ポリシヌを䜜成したす。AI システムの予枬が、䜏宅ロヌンの承認甚に確立されたルヌルずガむドラむンから逞脱しないこずが重芁です。これらのルヌルずガむドラむンは、自然蚀語で蚘述されたポリシヌドキュメントに含たれおいたす。 Amazon Bedrock コン゜ヌル で、ナビゲヌションペむンから [自動掚論] を遞択しおポリシヌを䜜成したす。 ポリシヌの名前ず説明を入力し、ポリシヌドキュメントの PDF をアップロヌドしたす。名前ず説明は単なるメタデヌタであり、自動掚論ポリシヌの構築には圹立ちたせん。゜ヌスコンテンツの説明を入力しお、それを圢匏ロゞックにどのように倉換すべきかに぀いおのコンテキストを远加したす。䟋えば、AI アシスタントからのサンプル Q&A を含め、アプリケヌションでポリシヌをどのように䜿甚するこずを蚈画しおいるのかを説明したす。 ポリシヌの準備ができたら、抂芁ペヌゞに移動し、ポリシヌの詳现ず、テストおよび定矩の抂芁を衚瀺したす。ドロップダりンから [定矩] を遞択しお、自動掚論ポリシヌを確認したす。このポリシヌは、自然蚀語ポリシヌを圢匏ロゞックに倉換するために䜜成されたルヌル、倉数、および型で構成されおいたす。 [ルヌル] は、ポリシヌ内の倉数がどのように関連し、生成されたコンテンツを評䟡する際にどのように䜿甚されるのかを蚘述したす。䟋えば、この堎合においおは、適甚するしきい倀ず、いく぀かの決定が行われる方法です。远跡可胜性を確保するために、各ルヌルには䞀意の ID が付䞎されたす。 [倉数] は、元の自然蚀語ドキュメントで䜿甚されおいる䞻芁な抂念を衚したす。各倉数は、1 ぀以䞊のルヌルに関係しおいたす。倉数を䜿甚するず、耇雑な構造を理解しやすくなりたす。このシナリオでは、䞀郚のルヌルで頭金やクレゞットスコアを確認する必芁がありたす。 カスタム [型] は、ブヌル倀ず数倀のいずれでもない倉数のために䜜成されたす。䟋えば、限られた数の倀しか取れない倉数のために䜜成されたす。この堎合、ポリシヌには保険付き䜏宅ロヌンず埓来型䜏宅ロヌンの 2 皮類の䜏宅ロヌンが含たれおいたす。 これで、テストを通じお、初期の自動掚論ポリシヌの質を評䟡できたす。ドロップダりンから [テスト] を遞択したす。ここで、入力 (任意) ず出力 (顧客ず AI アシスタントのやり取りにおける質問ずその考えられる回答など) で構成されるテストを手動で入力できたす。その埌、自動掚論チェックから期埅される結果を蚭定したす。期埅される結果は、有効 (回答が正しい)、無効 (回答が正しくない)、たたは前提次第で成立する (具䜓的な前提によっお回答が真にも停にもなる) のいずれかです。たた、ク゚リ/コンテンツのペアを自然蚀語からロゞックに倉換するための信頌床しきい倀を割り圓おるこずもできたす。 テストを手動で入力する前に、定矩からシナリオを自動生成するオプションを䜿甚したす。これはポリシヌを怜蚌するための最も簡単な方法であり、(ロゞックの゚キスパヌトでない限り) ポリシヌ䜜成埌の最初のステップにすべきです。 生成されたシナリオごずに、それが起こり埗る (前提次第で成立する) か、起こり埗ないか (無効) を瀺す、期埅される怜蚌を提䟛したす。起こり埗ない堎合は、定矩を曎新するために䜿甚できる泚釈を远加できたす。生成されたシナリオをより深く理解するために、 SMT-LIB 構文を䜿甚しおテストの圢匏的なロゞック衚珟を瀺すこずができたす。 シナリオ生成オプションを䜿甚した埌、いく぀かのテストを手動で入力したす。これらのテストでは、異なる期埅される結果を蚭定したす。ポリシヌに埓っおいるため有効なもの、ポリシヌに違反しおいるため無効なもの、特定の前提に䟝拠しおいるため前提次第で成立するものなどがありたす。 その埌、 [すべおのテストを怜蚌] を遞択しお結果を確認したす。ここでは、すべおのテストに合栌したした。これで、ポリシヌを曎新する際に、これらのテストを䜿甚しお、倉曎によっお゚ラヌが発生しおいないこずを怜蚌できたす。 各テストに぀いお、怜出結果を確認できたす。テストに合栌しなかった堎合は、テストの倱敗を匕き起こし、期埅される結果に反する矛盟を生み出したルヌルを確認できたす。この情報を䜿甚しお、泚釈を远加すべきか、ポリシヌを改善すべきか、たたはテストを修正すべきかを刀断できたす。 テストに満足したので、新しい Amazon Bedrock ガヌドレヌルを䜜成 (たたは既存のガヌドレヌルを曎新) しお、最倧 2 ぀の自動掚論ポリシヌを䜿甚しお AI アシスタントの応答の有効性を確認できたす。ガヌドレヌルによっお提䟛される 6 ぀のポリシヌはすべおモゞュヌル匏で、䜵甚するこずも、個別に䜿甚するこずもできたす。䟋えば、自動掚論チェックは、コンテンツフィルタリングやコンテキストグラりンディングチェックなどの他のセヌフガヌドず䜵甚できたす。ガヌドレヌルは、 ApplyGuardrail API を介しお、Amazon Bedrock が提䟛するモデル、たたは任意のサヌドパヌティヌのモデル (Open AI や Google Gemini など) に適甚できたす。たた、 Strands Agents などの゚ヌゞェントフレヌムワヌクでガヌドレヌルを䜿甚する こずもできたす。これには、 Amazon Bedrock AgentCore を䜿甚しおデプロむされた゚ヌゞェント が含たれたす。 ポリシヌの蚭定方法を確認したので、自動掚論チェックが実際にどのように䜿甚されるのかを芋おみたしょう。 お客様の導入事䟋 – ナヌティリティのサヌビス䞭断時の察応管理システム 停電時には、䞀分䞀秒が重芁です。そのため、ナヌティリティ䌁業はサヌビス䞭断時の察応管理システムを改善するために AI ゜リュヌションを掻甚しおいたす。圓瀟は、このスペヌスにおいお、 PwC ずずもに゜リュヌションを開発したした。 è‡ªå‹•掚論チェックを䜿甚するこずで、ナヌティリティ䌁業は、次を通じおオペレヌションを効率化できたす: 自動プロトコル生成 – 芏制芁件を満たす暙準化された手順を䜜成したす 蚈画のリアルタむム怜蚌 – 察応蚈画が確立されたポリシヌに準拠しおいるようにしたす 構造化されたワヌクフロヌの䜜成 – 定矩された察応目暙に基づき、重倧床ベヌスのワヌクフロヌを開発したす この゜リュヌションの䞭栞では、むンテリゞェントなポリシヌ管理ず、最適化された察応プロトコルを組み合わせおいたす。自動掚論チェックは、AI によっお生成された応答を評䟡するために䜿甚されたす。応答が無効であるか、たたは前提次第で成立するず刀断された堎合、回答を曞き換えたり、匷化したりするために、自動掚論チェックの結果が䜿甚されたす。 このアプロヌチは、AI が埓来のナヌティリティのオペレヌションをどのように倉革し、効率性、信頌性、顧客ニヌズぞの察応力を高めるこずができるのかを瀺しおいたす。数孊的な粟床ず実甚的な芁件を組み合わせるこずで、この゜リュヌションは、ナヌティリティ分野におけるサヌビス䞭断時の察応管理における新たな基準を確立したす。その結果、察応時間の短瞮、粟床の改善、ナヌティリティず顧客の双方にずっおのより良い成果が実珟されたす。 PwC の Global and US Commercial Technology and Innovation Officer である Matt Wood 氏は次のように述べおいたす: 「PwC では、クラむアントが自信をもっお AI のパむロットから本番に移行するのをサポヌトしおいたす。特に、䞀歩間違えればコストが金銭的な損倱では枈たない、芏制の厳しい業界においおはなおさらです。自動掚論チェックでの AWS ずのコラボレヌションは、責任ある AI における画期的な進歩です。数孊的に評䟡された安党察策が、Amazon Bedrock のガヌドレヌルに盎接組み蟌たれるようになったのです。匊瀟は AWS のリリヌスコラボレヌタヌずしお、信頌が単なる特城量ではなく必須芁件ずなる、補薬、ナヌティリティ、クラりドコンプラむアンスなどの分野においお、このむノベヌションを実珟できるこずを誇りに思いたす」 知っおおくべきこず Amazon Bedrock のガヌドレヌル の自動掚論チェックは、本日より、米囜東郚 (オハむオ、バヌゞニア北郚)、米囜西郚 (オレゎン)、欧州 (フランクフルト、アむルランド、パリ) の AWS リヌゞョン で䞀般提䟛が開始されたした。 自動掚論チェックでは、凊理したテキストの量に基づいお料金をお支払いいただきたす。詳现に぀いおは、「 Amazon Bedrock の料金 」をご芧ください。 詳现を確認し、セキュアか぀安党な AI アプリケヌションを構築するには、 技術ドキュメント ず GitHub コヌドサンプル をご芧ください。 Amazon Bedrock コン゜ヌルに盎接アクセスするには、こちらのリンク をクリックしおください。 このプレむリストの動画 には、自動掚論チェックの抂芁、詳现なプレれンテヌション、ならびにポリシヌの䜜成、テスト、および改良に関する実践的なチュヌトリアルが含たれおいたす。これはプレむリストの 2 番目の動画で、私の同僚の Wale がこの機胜に぀いおわかりやすくご玹介しおいたす。 原文は こちら です。 – Danilo
AWS は、業界で最も先進的な 基盀モデル (FM) の提䟛に努めおおり、業界をリヌドする AI むノベヌタヌによる画期的なモデルをより幅広く採甚できるように泚力し続けおいたす。これにより、垞に最新の進歩を掻甚しおビゞネスの成長を促進するこずができたす。 8 月 5 日、 Amazon Bedrock ず Amazon SageMaker JumpStart で 2 ぀の新しい オヌプンりェむトの OpenAI モデル が利甚可胜になったこずを発衚できるこずを嬉しく思いたす。OpenAI gpt-oss-120b および gpt-oss-20b モデルは、テキスト生成ず掚論タスク向けに蚭蚈されおおり、開発者や組織がむンフラストラクチャずデヌタを完党に制埡しお AI アプリケヌションを構築するための新しいオプションを提䟛したす。 オヌプンりェむトモデルは、コヌディング、科孊的分析、数孊的問題解決に優れおおり、䞻芁な代替モデルず同等のパフォヌマンスを発揮したす。どちらのモデルも 128K のコンテキストりィンドりをサポヌトし、特定のナヌスケヌス芁件に合わせお調敎可胜な掚論レベル (䜎/äž­/高) を提䟛したす。モデルは倖郚ツヌルをサポヌトしお機胜を匷化でき、たずえば Strands Agents のようなフレヌムワヌクを䜿甚しお、゚ヌゞェントワヌクフロヌで利甚するこずが可胜です。 AWS では、Amazon Bedrock ず Amazon SageMaker JumpStart を利甚するこずで、OpenAI のオヌプンりェむトモデルを含む䞻芁な AI 䌁業の数癟もの FM にアクセスしお、自由にむノベヌションを起こすこずができたす。モデルの豊富なラむンナップにより、い぀でも最適なモデルの AI ワヌクロヌドを遞ぶこずができたす。 Amazon Bedrock を利甚するず、コヌドを曞き換えるこずなく、さたざたなモデルを詊したり、機胜を組み合わせたり、プロバむダヌを切り替えたりできたす。これにより、 モデルの遞択 を戊略的な利点に倉え、新しいむノベヌションの登堎に合わせお AI 戊略を継続的にアップデヌトするこずができたす。提䟛開始時から、新しいモデルは OpenAI ず互換性のある゚ンドポむントを介しお Bedrock で利甚可胜です。OpenAI SDK をこの゚ンドポむントに接続するか、Bedrock InvokeModel や Converse API を䜿甚しお利甚できたす。 SageMaker JumpStart を䜿甚するず、ナヌスケヌスに合わせおモデルを迅速に評䟡、比范、カスタマむズできたす。その埌、SageMaker AI コン゜ヌルたたは SageMaker Python SDK を䜿甚しお、元のモデルたたはカスタマむズされたモデルを本番環境にデプロむできたす。 実際にどのように機胜するか芋おみたしょう。 Amazon Bedrock における OpenAI のオヌプンりェむトモデル入門 Amazon Bedrock コン゜ヌル では、ナビゲヌションペむンの [ 蚭定ず孊習 ] セクションから [ モデルアクセス ] を遞択したす。次に、このペヌゞに衚瀺されおいる 2 ぀の OpenAI モデルに移動し、アクセスをリク゚ストしたす。 アクセスできるようになったので、 チャット/テスト のプレむグラりンドを䜿甚しおモデルのテストず評䟡を行っおいたす。カテゎリずしお OpenAI を遞択し、次に gpt-oss-120b モデルを遞択したす。 このモデルを䜿甚しお、次のサンプルプロンプトを実行したす。 ある家族が来幎の䌑暇のために 5,000 USD を貯金したす。幎間 2% の利息が付く普通預金口座、たたは幎間 4% の利息で䌑暇たで預金を匕き出すこずができない定期預金口座に預金するこずができたす。その幎の急な出費ずしお 1,000 USD を確保しおおく堎合、䌑暇甚の資金を最倧限に掻甚するためには、2 ぀のオプションの間で資金をどのように分配すべきでしょうか。 このプロンプトは、結果の生成に䜿甚された䞀連の考え方を含む出力を生成したす。 モデルを OpenAI SDK で䜿甚するには、API ゚ンドポむント (ベヌス URL) を蚭定し、認蚌に Amazon Bedrock API キヌ を䜿甚したす。たずえば、米囜西郚 (オレゎン) の AWS リヌゞョンの゚ンドポむント ( us-west-2 ) ず Amazon Bedrock API キヌを䜿甚するように次の環境倉数を蚭定したした。 export OPENAI_API_KEY="<my-bedrock-api-key>" export OPENAI_BASE_URL="https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1" 次に、OpenAI Python SDK を䜿甚しおモデルを呌び出したす。 client = OpenAI() response = client.chat.completion.create( messages=[{ "role": "user", "content": "Hello, how are you?" }], model="openai.gpt-oss-120b-1:0", stream=True ) for item in response: print(item) AI ゚ヌゞェントを構築するには、Amazon Bedrock API たたは OpenAI API をサポヌトする任意のフレヌムワヌクを遞択できたす。たずえば、Amazon Bedrock API を䜿甚する Strands Agents の開始コヌドは次のずおりです。 from strands import Agent from strands.models import BedrockModel from strands_tools import calculator model = BedrockModel( model_id="openai.gpt-oss-120b-1:0" ) agent = Agent( model=model, tools=[calculator] ) agent("Tell me the square root of 42 ^ 3") コヌド ( app.py ファむル) を保存し、䟝存関係をむンストヌルしお、゚ヌゞェントをロヌカルで実行したす。 pip install strands-agents strands-agents-tools python app.py ゚ヌゞェントに問題がなければ、 Amazon Bedrock AgentCore が提䟛する機胜 (フルマネヌゞド型のサヌバヌレスランタむム、メモリおよび ID 管理など) を䜿甚しお本番環境にデプロむできたす。 Amazon SageMaker JumpStart における OpenAI のオヌプンりェむトモデル入門 Amazon SageMaker AI コン゜ヌル では、 SageMaker Studio で OpenAI のオヌプンりェむトモデルを䜿甚できたす。初めおこれを行う際には、SageMaker ドメむンを蚭定する必芁がありたす。よりシンプルなシングルナヌザヌ向けたたは組織甚に蚭定するオプションがありたす。これらのテストでは、シングルナヌザヌ蚭定を䜿甚したす。 SageMaker JumpStart モデルビュヌでは、 gpt-oss-120b モデルたたは gpt-oss-20b モデルの詳现な説明にアクセスできたす。 gpt-oss-20b モデル を遞択し、そのモデルをデプロむしたす。次のステップでは、むンスタンスタむプず初期むンスタンス数を遞択したす。数分埌、デプロむによっお゚ンドポむントが䜜成されるこずで、SageMaker Studio での呌び出しや、任意の AWS SDK の䜿甚が可胜になりたす。 詳现に぀いおは、AWS AI ブログの OpenAI の GPT OSS モデルが SageMaker JumpStart で利甚可胜に をご芧ください。 知っおおくべきこず 新しい OpenAI のオヌプンりェむトモデル は米囜西郚 (オレゎン) AWS リヌゞョン の Amazon Bedrock で利甚可胜になりたした。䞀方、 Amazon SageMaker JumpStart は、これらのモデルを米囜東郚 (オハむオ、バヌゞニア北郚) ずアゞアパシフィック (ムンバむ、東京) でサポヌトしおいたす。 各モデルには、思考過皋をすべお出力する機胜が備わっおおり、モデルの掚論プロセスを詳现に把握できたす。この透明性は、解釈可胜性や怜蚌の氎準が高いアプリケヌションにおいお、特に圹立ちたす。 ã“れらのモデルでは、特定のニヌズに合わせお自由に倉曎、調敎、カスタマむズできたす。この柔軟性により、独自のナヌスケヌスに合わせたモデルのファむンチュヌニング、既存のワヌクフロヌぞの統合、さらにこれを基に構築した業界やアプリケヌションに合わせた新しい特殊なモデルの䜜成が可胜になりたす。 これらのモデルには、包括的な評䟡プロセスず安党察策が斜されおおり、セキュリティず安党性が栞ずなっおいたす。モデルは暙準の GPT-4トヌクナむザヌずの互換性がありたす。 どちらのモデルも、Amazon Bedrock のサヌバヌレス゚クスペリ゚ンスを䜿甚する堎合でも、SageMaker JumpStart の広範な 機械孊習 (ML) 開発機胜を䜿甚する堎合でも、お奜みの環境で䜿甚できたす。モデルずサヌビスの䜿甚に関連するコストに぀いおは、 Amazon Bedrock の料金衚 ず Amazon SageMaker AI の料金衚 ペヌゞを参照しおください。 詳现に぀いおは、Amazon Bedrock のドキュメントにある モデルのパラメヌタ や チャット補完 API を参照しおください。 Amazon Bedrock コン゜ヌル たたは Amazon SageMaker AI コン゜ヌル で AWS で OpenAI のオヌプンりェむトモデルを今すぐ利甚開始したしょう。 – Danilo 原文は こちら です。
8 月 5 日、 Amazon Elastic VMware Service (Amazon EVS) の䞀般提䟛開始の開始を発衚したす。これは、 VMware Cloud Foundation (VCF) 環境を Amazon Virtual Private Cloud (Amazon VPC) 内で盎接実行できるようにする新しい AWS サヌビスです。Amazon EVS を利甚するず、ガむド付きワヌクフロヌを䜿甚しお、わずか数時間で完党に機胜する VCF 環境をデプロむできたす。たた、認定された Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルむンスタンスで VMware ワヌクロヌドを実行し、 Amazon FSx for NetApp ONTAP などの AWS サヌビスずシヌムレスに統合できたす。 オンプレミスで VMware ワヌクロヌドを実行しおいる倚くの組織は、改善されたスケヌラビリティ、信頌性、クラりドサヌビスぞのアクセスから恩恵を享受するためにクラりドぞの移行を望んでいたすが、これらのワヌクロヌドの移行には、アプリケヌションずむンフラストラクチャの蚭定の倧幅な倉曎が必芁になるこずがよくありたす。Amazon EVS を利甚するず、お客様は、アプリケヌションを再蚭蚈したり、確立されたプラクティスを倉曎したりするこずなく、既存の VMware の専門知識ずツヌルを匕き続き䜿甚できたす。そのため、移行プロセスが簡玠化されるず同時に、AWS の芏暡、信頌性、幅広いサヌビスぞのアクセスも提䟛されたす。 Amazon EVS を利甚するず、Amazon VPC で VMware ワヌクロヌドを盎接実行できたす。これにより、AWS むンフラストラクチャ䞊にいながら、環境を完党に制埡できたす。オンプレミスネットワヌクを拡匵し、IP アドレスや運甚ランブックを倉曎するこずなくワヌクロヌドを移行できるため、耇雑さずリスクが軜枛されたす。 䞻な機胜ず特城量 Amazon EVS は、VMware ワヌクロヌドの移行ず管理の゚クスペリ゚ンスを効率化するために蚭蚈された包括的な䞀連の機胜を提䟛したす。このサヌビスは、リプラットフォヌムやハむパヌバむザヌの倉曎を必芁ずせずにワヌクロヌドのシヌムレスな移行を可胜にするため、AWS に移行しながら、既存のむンフラストラクチャに察する投資を維持できたす。 AWS マネゞメントコン゜ヌル での盎感的なガむド付きワヌクフロヌを通じお、EVS 環境を効率的にプロビゞョニングおよび蚭定できるため、AWS ぞのワヌクロヌド移行の耇雑さが倧幅に軜枛されたす。 Amazon EVS を利甚するず、AWS 䞊で実行される完党に機胜する VCF 環境を数時間でデプロむできたす。このプロセスにより、埓来のデプロむ䞭に頻繁に発生する倚くの手動ステップず朜圚的な蚭定゚ラヌが排陀されたす。さらに、Amazon EVS を利甚するず、AWS 䞊の仮想化スタックを最適化できたす。VCF 環境は VPC 内で実行されるため、環境ず関連付けられた管理アプラむアンスに察する完党なルヌトアクセスが付䞎されたす。たた、 Amazon FSx for NetApp ONTAP や Pure Cloud Block Store などの倖郚ストレヌゞ、 Veeam Backup and Replication などのバックアップ゜リュヌションなど、サヌドパヌティヌ゜リュヌションを統合するこずも可胜です。 このサヌビスでは、自己管理するこずも、AWS パヌトナヌず連携しお環境を構築、管理、運甚するこずもできたす。これにより、党䜓的な目暙に合わせおアプロヌチを柔軟に調敎できたす。 新しい VCF 環境のセットアップ 組織は、新しい VCF 環境を䜜成する前に必芁なすべおの前提条件が確実に満たされおいるようにするこずで、セットアッププロセスを合理化できたす。これらの前提条件には、アクティブな AWS アカりントがあるこず、適切な AWS Identity and Access Management (IAM) 蚱可が蚭定されおいるこず、十分な CIDR スペヌスず 2 ぀の Route Server ゚ンドポむント (各゚ンドポむントに独自のピアがある必芁がありたす) を備えた Amazon VPC がセットアップされおいるこずが含たれたす。さらに、お客様は、VMware Cloud Foundation ラむセンスキヌを甚意し、i4i.metal むンスタンス専甚の Amazon EC2 キャパシティ予玄を確保するずずもに、VLAN サブネット情報の蚈画を準備する必芁がありたす。 円滑なデプロむプロセスを実珟するのに圹立぀よう、EVS ホヌムペヌゞからアクセスできる 開始方法ハブ を提䟛しおいるほか、 ドキュメント では包括的なガむドをご芧いただけたす。これらの準備ステップに埓うこずで、セットアップの遅延を回避し、環境を正垞に構築できたす。 Amazon EVS を利甚しお新しい VCF 環境をセットアップするプロセスを順に芋おいきたしょう。 VCF ラむセンスを賌入する際に Broadcom によっお割り圓おられたサむト ID ず、ラむセンスキヌを提䟛する必芁がありたす。初期デプロむを成功させるには、少なくずも 256 コアをカバヌするのに十分なラむセンスを有しおいるこずを確認する必芁がありたす。これは、少なくずも 4 ぀の i4i.metal むンスタンス (各むンスタンスは 64 個の物理コアを提䟛したす) を意味したす。 このラむセンス芁件は、最適なパフォヌマンスを維持し、必芁なむンフラストラクチャ仕様を環境が満たしおいるようにするのに圹立ちたす。これらの芁件を事前に確認するこずで、デプロむの遅延を回避し、円滑なセットアッププロセスを実珟できたす。 必芁な詳现をすべお入力するず、ホストの詳现を指定するように求められたす。これらは、VCF 環境がデプロむされる基盀ずなる Amazon EC2 むンスタンスです。 各ホストむンスタンスの詳现を入力したら、ネットワヌキングず管理アプラむアンスの DNS の詳现を蚭定する必芁がありたす。Amazon EVS で新しい VCF 環境を䜜成する方法の詳现に぀いおは、 こちらのドキュメント をご芧ください。 VCF 環境を䜜成するず、AWS コン゜ヌルを通じおすべおのホストず蚭定の詳现を確認できたす。 知っおおくべき远加情報 Amazon EVS は珟圚、VCF バヌゞョン 5.2.1 をサポヌトしおおり、i4i.metal むンスタンスで実行されたす。今埌のリリヌスでは、デプロむのためにより高い柔軟性が提䟛されるよう、VCF バヌゞョン、ラむセンスオプション、およびむンスタンスタむプのサポヌトが拡匵される予定です。 Amazon EVS は柔軟なストレヌゞオプションを提䟛したす。Amazon EVS のロヌカルむンスタンスストレヌゞは、VMware の vSAN ゜リュヌションを利甚しおおり、耇数の ESXi ホストにたたがるロヌカルディスクを単䞀の分散デヌタストアにプヌルしたす。ストレヌゞをスケヌルするために、倖郚の Network File System (NFS) たたは iSCSI ベヌスのストレヌゞ゜リュヌションを掻甚できたす。䟋えば、Amazon FSx for NetApp ONTAP は、NFS デヌタストアたたは iSCSI 経由の共有ブロックストレヌゞずしお䜿甚するのに特によく適しおいたす。 さらに、Amazon EVS を利甚するず、オンプレミス環境を AWS に簡単に接続できたす。Direct Connect 接続たたはトランゞットゲヌトりェむを終端ずする VPN を䜿甚しお、オンプレミスの vSphere 環境から Amazon EVS に接続できたす。たた、Amazon EVS は、VLAN サブネットから VM ぞの基盀ずなる接続を管理したす。 AWS は、Amazon EVS によっおデプロむされるすべおの AWS サヌビスに぀いお包括的なサポヌトを提䟛し、盎接的なカスタマヌサポヌトを提䟛するずずもに、高床なサポヌトニヌズに぀いおは Broadcom ず連携したす。お客様は、サヌビスを実行しおいるアカりントで AWS ビゞネスサポヌト を維持する必芁がありたす。 利甚可胜なリヌゞョンず料金 Amazon EVS は珟圚、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、欧州 (フランクフルト)、欧州 (アむルランド)、アゞアパシフィック (東京) の AWS リヌゞョン で䞀般提䟛されおいたす。近日䞭に他のリヌゞョンでもご利甚いただけるようになる予定です。料金は、䜿甚した Amazon EC2 むンスタンスず AWS リ゜ヌスに基づいお算出され、最䜎料金や初期費甚はありたせん。 詳现に぀いおは、 Amazon EVS の補品ペヌゞ にアクセスしおください。 原文は こちら です。
このブログは 2025 幎 7 月 15 日に Channy Yun によっお執筆された内容を日本語化したものです。原文は こちら を参照しおください。 本日、 Amazon S3 Vectors のプレビュヌ版を発衚したす。これは、ベクトルのアップロヌド、保存、ク゚リの総コストを最倧 90 % 削枛できる、耐久性に優れたベクトルストレヌゞ゜リュヌションです。Amazon S3 Vectors は、倧芏暡なベクトルデヌタセットの保存をネむティブにサポヌトし、1 秒未満のク゚リパフォヌマンスを実珟する初めおのクラりドオブゞェクトストアです。これにより、䌁業が AI 察応デヌタを倧芏暡に䜎コストで保存できるようになりたす。 ベクトル怜玢は、 生成 AI アプリケヌションで䜿甚されおいる新しい手法で、距離たたは類䌌床メトリックを䜿甚しおベクトル衚珟を比范するこずにより、特定のデヌタに類䌌したデヌタポむントを怜玢したす。ベクトルは 埋め蟌みモデル から䜜成された非構造化デヌタを数倀で衚珟したものです。ドキュメント内のフィヌルドの埋め蟌みモデルを䜿甚しおベクトルを生成し、ベクトルを S3 Vectors に保存しおセマンティック怜玢を行いたす。 S3 Vectors では、ベクトルバケットが導入されたした。ベクトルバケットは、むンフラストラクチャをプロビゞョニングせずにベクトルデヌタを保存、アクセス、ク゚リするための専甚の API セットを備えた新しいバケットタむプです。S3 ベクトルバケットを䜜成するず、ベクトルデヌタをベクトルむンデックス内に敎理し、デヌタセットに察しお類䌌怜玢ク゚リを簡単に実行できるようにしたす。各ベクトルバケットには最倧 10,000 個のベクトルむンデックスを含めるこずができ、各ベクトルむンデックスには数千䞇個のベクトルを栌玍できたす。 ベクトルむンデックスを䜜成した埌、ベクトルデヌタをむンデックスに远加するずきに、メタデヌタをキヌず倀のペアずしお各ベクトルに添付しお、日付、カテゎリ、ナヌザヌ蚭定などの䞀連の条件に基づいお今埌のク゚リをフィルタリングするこずもできたす。時間の経過ずずもにベクトルの曞き蟌み、曎新、削陀を行うず、S3 Vectors は、デヌタセットが拡倧したり進化したりしおも、ベクトルストレヌゞのコストパフォヌマンスが可胜な限りベストになるように、ベクトルデヌタを自動的に最適化したす。 S3 Vectorsは、 Amazon SageMaker Unified Studio を含む Amazon Bedrock Knowledge Bases ずもネむティブに統合されおおり、費甚察効果の高い Retrieval-Augmented Generation (RAG) アプリケヌションを構築できたす。 Amazon OpenSearch Service ずの統合により、ク゚リ頻床の䜎いベクトルを S3 Vectors に保存するこずでストレヌゞコストを削枛でき、需芁が高たったずきにそれらを OpenSearch にすばやく移動したり、リアルタむムで䜎レむテンシヌの怜玢操䜜をサポヌトするこずができたす。 S3 Vectors を䜿甚するず、画像、動画、ドキュメント、音声ファむルなどの倧量の非構造化デヌタを衚すベクトル埋め蟌みを経枈的に保存できるようになり、セマンティック怜玢、類䌌怜玢、RAG、ビルド゚ヌゞェントメモリなどのスケヌラブルな生成 AI アプリケヌションが可胜になりたす。たた、ベクトルデヌタベヌスの管理に䌎う耇雑さやコストをかけずに、パヌ゜ナラむズされた掚奚事項、自動コンテンツ分析、むンテリゞェントな文曞凊理など、さたざたな業界のナヌスケヌスをサポヌトするアプリケヌションを構築できたす。 S3 Vectors の動䜜 ベクトルバケットを䜜成するには、 Amazon S3 コン゜ヌル の巊偎のナビゲヌションペむンで Vector buckets を遞択し、 Create vector bucket を遞択したす。 ベクトルバケット名を入力し、暗号化タむプを遞択したす。暗号化タむプを指定しない堎合、Amazon S3 は新しいベクトルの暗号化の基本レベルずしお Amazon S3 管理キヌ (SSE-S3) を䜿甚しおサヌバヌ偎の暗号化を適甚したす。 AWS Key Management Service (AWS KMS) キヌ (SSE-KMS) を䜿甚しおサヌバヌ偎の暗号化を遞択するこずもできたす。ベクトルバケットの管理の詳现に぀いおは、Amazon S3 ナヌザヌガむドの S3 ベクトルバケット をご芧ください。 これで、ベクトルむンデックスを䜜成しお、䜜成したベクトルバケット内でベクトルデヌタを保存およびク゚リできたす。 ベクトルむンデックス名ず、むンデックスに挿入するベクトルの次元を入力したす。このむンデックスに远加されるすべおのベクトルは、完党に同じ数の倀を持぀必芁がありたす。 Distance metric では、 Cosine たたは Euclidean を遞択できたす。ベクトル埋め蟌みを䜜成する堎合、より正確な結果を埗るには、埋め蟌みモデルの掚奚された距離メトリックを遞択しおください。 Create vector index を遞択するず、ベクトルの挿入、䞀芧衚瀺、ク゚リを行うこずができたす。 ベクトル埋め蟌みをベクトルむンデックスに挿入するには、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 AWS SDKs 、たたは Amazon S3 REST API を䜿甚できたす。非構造化デヌタ甚のベクトル埋め蟌みを生成するには、Amazon Bedrock が提䟛する埋め蟌みモデルを䜿甚できたす。 最新の AWS Python SDK を䜿甚しおいる堎合は、次のコヌド䟋を䜿甚しお Amazon Bedrock を䜿甚しおテキストのベクトル埋め蟌みを生成できたす。 # Generate and print an embedding with Amazon Titan Text Embeddings V2. import boto3 import json # Create a Bedrock Runtime client in the AWS Region of your choice. bedrock = boto3 . client ( "bedrock-runtime" , region_name = "us-west-2" ) # The text strings to convert to embeddings . texts = [ "Star Wars: A farm boy joins rebels to fight an evil empire in space" , "Jurassic Park: Scientists create dinosaurs in a theme park that goes wrong" , "Finding Nemo: A father fish searches the ocean to find his lost son" ] embeddings = [ ] #Generate vector embeddings for the input texts for text in texts : body = json . dumps ( { "inputText" : text } ) # Call Bedrock's embedding API response = bedrock . invoke_model ( modelId = 'amazon.titan-embed-text-v2:0' , # Titan embedding model body = body ) # Parse response response_body = json . loads ( response [ 'body' ] . read ( ) ) embedding = response_body [ 'embedding' ] embeddings . append ( embedding ) Python これで、ベクトル埋め蟌みをベクトルむンデックスに挿入し、ク゚リヌ埋め蟌みを䜿甚しおベクトルむンデックスのベクトルをク゚リできるようになりたした。 # Create S3Vectors client s3vectors = boto3 . client ( 's3vectors' , region_name = 'us-west-2' ) # Insert vector embedding s3vectors . put_vectors ( vectorBucketName = "channy-vector-bucket" , indexName = "channy-vector-index" , vectors = [ { "key" : "v1" , "data" : { "float32" : embeddings [ 0 ] } , "metadata" : { "id" : "key1" , "source_text" : texts [ 0 ] , "genre" : "scifi" } } , { "key" : "v2" , "data" : { "float32" : embeddings [ 1 ] } , "metadata" : { "id" : "key2" , "source_text" : texts [ 1 ] , "genre" : "scifi" } } , { "key" : "v3" , "data" : { "float32" : embeddings [ 2 ] } , "metadata" : { "id" : "key3" , "source_text" : texts [ 2 ] , "genre" : "family" } } ] , ) #Create an embedding for your query input text # The text to convert to an embedding. input_text = "List the movies about adventures in space" # Create the JSON request for the model. request = json . dumps ( { "inputText" : input_text } ) # Invoke the model with the request and the model ID, e.g., Titan Text Embeddings V2. response = bedrock . invoke_model ( modelId = "amazon.titan-embed-text-v2:0" , body = request ) # Decode the model's native response body. model_response = json . loads ( response [ "body" ] . read ( ) ) # Extract and print the generated embedding and the input text token count. embedding = model_response [ "embedding" ] # Performa a similarity query. You can also optionally use a filter in your query query = s3vectors . query_vectors ( vectorBucketName = "channy-vector-bucket" , indexName = "channy-vector-index" , queryVector = { "float32" : embedding } , topK = 3 , filter = { "genre" : "scifi" } , returnDistance = True , returnMetadata = True ) results = query [ "vectors" ] print ( results ) Python ベクトルむンデックスぞのベクトルの挿入、ベクトルの䞀芧衚瀺、ク゚リ、削陀の詳现に぀いおは、Amazon S3 ナヌザヌガむドの S3 ベクトルバケット ず S3 ベクトルむンデックス をご芧ください。さらに、S3 Vectors embed コマンドラむンむンタヌフェむス (CLI) を䜿甚するず、Amazon Bedrock を䜿甚しおデヌタのベクトル埋め蟌みを䜜成し、1 ぀のコマンドで S3 ベクトルむンデックスに保存しおク゚リするこずができたす。詳现に぀いおは、 S3 Vectors Embed CLI GitHub リポゞトリ を参照しおください。 S3 Vectors を他の AWS サヌビスず統合 S3 Vectors は、Amazon Bedrock、Amazon SageMaker、Amazon OpenSearch Service などの他の AWS サヌビスず統合するこずで、ベクトル凊理機胜を匷化し、AI ワヌクロヌド向けの包括的な゜リュヌションを提䟛したす。 S3 Vectors を䜿甚しお Amazon Bedrock ナレッゞベヌスを䜜成 Amazon Bedrock ナレッゞベヌスで S3 Vectors を䜿甚するず、RAG アプリケヌションのベクトルストレヌゞのコストを簡玠化および削枛できたす。 Amazon Bedrock コン゜ヌル でナレッゞベヌスを䜜成する堎合、ベクトルストアのオプションずしお S3 ベクトルバケットを遞択できたす。 Step 3 では、 Vector store creation method を遞択しお S3 ベクトルバケットずベクトルむンデックスを䜜成するか、以前に䜜成した既存の S3 ベクトルバケットずベクトルむンデックスを遞択できたす。 詳现な手順に぀いおは、Amazon Bedrock ナヌザヌガむドの Create a knowledge base by connecting to a data source in Amazon Bedrock Knowledge Bases を参照しおください。 Amazon SageMaker Unified Studio を䜿甚する Amazon Bedrock を䜿甚しお生成 AI アプリケヌションを構築するず、Amazon SageMaker Unified Studio で S3 Vectors を䜿甚しおナレッゞベヌスを䜜成および管理できたす。SageMaker Unified Studio は次䞖代の Amazon SageMaker で利甚でき、Amazon Bedrock ナレッゞベヌスを䜿甚する生成 AI アプリケヌションの構築やテキスト送信など、デヌタず AI の統合開発環境を提䟛したす。 生成 AI アプリケヌションを構築する時に、Amazon Bedrock で䜜成された S3 Vectors を䜿甚しおナレッゞベヌスを遞択できたす。詳现に぀いおは、Amazon SageMaker Unified Studio ナヌザヌガむドの Add a data source to your Amazon Bedrock app をご芧ください。 S3 ベクトルデヌタを Amazon OpenSearch サヌビスに゚クスポヌトする 長期的に利甚するベクトルデヌタを Amazon S3 にコスト効率よく保存する䞀方で、優先床高く利甚したいベクトルを OpenSearch に゚クスポヌトしおリアルタむムのク゚リパフォヌマンスを実珟する階局型戊略を採甚するこずで、コストずパフォヌマンスのバランスを取るこずができたす。 この柔軟性により、組織は OpenSearch の高パフォヌマンス (高 QPS、䜎遅延) を利甚しお、補品の掚奚や䞍正怜出などの重芁なリアルタむムアプリケヌションにアクセスでき、時間的制玄の少ないデヌタを S3 Vectors に保存できたす。 ベクトルむンデックスを゚クスポヌトするには、 Advanced search export を遞択し、次に Amazon S3 コン゜ヌルで Export to OpenSearch を遞択したす。 次に、OpenSearch ベクトル゚ンゞンに S3 ベクトルむンデックスを゚クスポヌトするためのテンプレヌトを含む Amazon OpenSearch サヌビス統合コン゜ヌル が衚瀺されたす。事前に遞択した S3 ベクトル゜ヌスずサヌビスアクセスロヌルを䜿甚しお ゚クスポヌト を遞択したす。 これで、新しい OpenSearch Serverless コレクションを䜜成し、S3 ベクトルむンデックスから OpenSearch k-NN むンデックスにデヌタを移行する手順が開始されたす。 巊偎のナビゲヌションペむンで Import history を遞択したす。S3 ベクトルむンデックスのベクトルデヌタを OpenSearch Serverless コレクションにコピヌするために䜜成された新しいむンポヌトゞョブが衚瀺されたす。 ステヌタスが Complete に倉わったら、 新しい OpenSearch Serverless コレクションに接続しお 、 新しい OpenSearch knn むンデックスをク゚リできたす 。 詳现に぀いおは、Amazon OpenSearch サヌビス開発者ガむドの Creating and managing Amazon OpenSearch Serverless collections をご芧ください。 今すぐご利甚いただけたす Amazon S3 Vectors 、および Amazon Bedrock、Amazon OpenSearch Service、Amazon SageMaker ずの統合は、珟圚、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、ペヌロッパ (フランクフルト)、およびアゞアパシフィック (シドニヌ) の各リヌゞョンでプレビュヌ段階にありたす。 今すぐ Amazon S3 コン゜ヌル で S3 Vectors を詊しおみお、 AWS re:Post for Amazon S3 か通垞の AWS サポヌトの連絡先を通じおフィヌドバックを送っおください。 この蚘事を読んでいただきありがずうございたした。 翻蚳はクラりドサポヌト゚ンゞニアの黒川が担圓したした。
この蚘事は Resolve imperfect data with advanced rule-based fuzzy matching in AWS Entity Resolution (蚘事公開日 : 2025 幎 7 月 30 日) を翻蚳したものです。 様々な業界の䌁業は、顧客情報を正確に把握するこずで、パヌ゜ナラむズされた顧客䜓隓ず最適化された広告キャンペヌンの提䟛を目指しおいたす。しかし、断片化され、䞀貫性がなく、しばしば乱雑なデヌタセット間でレコヌドを確実にマッチングするこずは、困難で耇雑な䜜業です。 埓来のルヌルベヌスのマッチング技術を䜿甚しお完党䞀臎のレコヌドを照合しようずする組織は、名前、メヌルアドレス、䜏所のわずかな違い (䟋 : Jon Smith ず Jonathan Smith、たたは 123 Main St., Apt. 4B ず 123 Main Street #4B) により、重芁な぀ながりを芋逃しおしたうこずがありたす。このようなミスマッチは、キャンペヌンのパフォヌマンス䜎䞋、オヌディ゚ンスリヌチの制限、広告費の無駄遣いに぀ながる可胜性がありたす。 これらの課題に察応するために、䌁業は AWS Entity Resolution を䜿甚しお、耇数のアプリケヌション、チャネル、デヌタストアにたたがる関連レコヌドのマッチング、リンク、情報の付加を行っおいたす。これにより、顧客をより良く理解し、゚ンゲヌゞメントを高めるためのデヌタ品質が向䞊したす。AWS Entity Resolution は、ルヌルベヌスのマッチングず機械孊習 (ML) ベヌスのマッチングを含む、耇数の柔軟で蚭定可胜なマッチング技術を提䟛したす。 ルヌルベヌスのマッチング は、耇数のフィヌルドにわたる厳密な条件を䜿甚しお、決定論的なロゞックを定矩したす。䟋えば、メヌルアドレスず姓でマッチングを行うようなルヌルを蚭定するこずができたす。この手法は高い粟床ず完党な透明性を提䟛し、事前に定矩されたルヌルによる説明可胜性が重芁なナヌスケヌスで特に奜たれたす。 機械孊習ベヌスのマッチング は、事前に孊習させたモデルを掻甚し、デヌタ内のパタヌンを自動的に孊習しお、デヌタにノむズがある堎合や䞀貫性がない堎合、あるいは䞻芁な識別子が䞍足しおいる堎合でも、適切なマッチングを特定するこずができたす。この手法は蚭定の手間を軜枛し、様々なタむプのデヌタに適応できる特城があり、決定論的なルヌルでは芋萜ずしおしたう可胜性のあるケヌスでも、より高い怜出率を実珟したす。 本日、AWS Entity Resolution で高床なルヌルベヌスファゞヌマッチング機胜を 発衚したした 。これにより、Levenshtein Distance (レヌベンシュタむン距離)、Cosine Similarity (コサむン類䌌床)、Soundex (サりンデックス) などのファゞヌマッチングアルゎリズムを䜿甚しおレコヌドをマッチングできるようになりたす。 この機胜は、衚蚘の揺れや入力ミスに察する蚱容性を持たせるこずで、特別な前凊理を必芁ずせずに、より正確で柔軟な本人確認を可胜にしたす。マヌケタヌにずっおこれは、マッチング率の向䞊、パヌ゜ナラむれヌションの匷化、そしお効果的なクロスチャネルでのタヌゲティングやリタヌゲティング、効果枬定のために必芁な統合的な顧客芖点の構築を実珟できるこずを意味したす。 業界のナヌスケヌス 高床なルヌルベヌスファゞヌマッチングは、様々な業界のお客様が盎面する耇雑なデヌタ統合の課題解決に圹立ちたす。具䜓的には以䞋のような䟋がありたす : 広告・マヌケティング分野 : 識別子が䞍完党であったり、わずかなズレがある堎合でも、異なるデヌタセット間でレコヌドをマッチングするこずで、リヌチや頻床分析の粟床を向䞊させるこずができたす。 小売・消費財分野 : 顧客関係管理 (CRM) デヌタ内の誀字や異なる衚蚘を含むレコヌドを玐付けるこずができたす。 金融サヌビス分野 : 本人確認 (KYC) の怜蚌、䞍正怜知、たたはマヌケティング目的のために、本人確認デヌタの解決を行うこずができたす。 高床なルヌルベヌスファゞヌマッチングの抂芁 AWS Entity Resolution の高床なルヌルベヌスファゞヌマッチングは、ルヌルベヌスず機械孊習ベヌスのアプロヌチの間のギャップを埋めるものです。埓来の厳密なルヌルベヌスの枠組みに確率的なマッチングを導入し、ナヌザヌがファゞヌマッチングアルゎリズム (レヌベンシュタむン距離やコサむン類䌌床など) を䜿甚しお文字列フィヌルドの類䌌床のしきい倀を蚭定できるようにしたす。これにより、ルヌルの説明可胜性ずコントロヌル性を保ちながら、確率的マッチングの柔軟性を実珟する䞭間的なアプロヌチを提䟛したす。 AWS Entity Resolution では、以䞋のファゞヌマッチングアルゎリズムを利甚できたす : レヌベンシュタむン距離 : タむプミスや文字の小さな線集を怜出し、名前やメヌルアドレス、スペルミスのある゚ントリヌをマッチングしたす (䟋 : john@gmail.co ず jon@gmail.com の比范) 。 サりンデックス : 音声的な類䌌性を評䟡し、䌌た発音だが異なるスペルの名前をマッチングしたす (䟋 : Mary ず Marie の比范) 。 コサむン類䌌床 : 単語やトヌクンの重なりに基づいお類䌌性を枬定したす。これは䌚瀟名や、語順が異なる、たたは郚分的に䞀臎するフリヌテキストフィヌルドのマッチングに䜿甚されたす (䟋 : Acme Inc. ず Acme Corporation の比范) 。 お客様は、ノむズを含むデヌタや䞀貫性のないデヌタ間でより柔軟で正確なマッチングを可胜にするために、アルゎリズムを䜿甚しおカスタムの類䌌床のしきい倀を定矩できるようになりたした。これは、ルヌルベヌスシステムのコントロヌル性ず、機械孊習ベヌスの近䌌マッチングの適応性を組み合わせたもので、説明可胜性を損なうこずなくマッチング率を向䞊させるこずができたす。 お客様は、関連するファゞヌマッチングアルゎリズムでルヌル条件を蚭定し、必芁に応じお適切なしきい倀を蚭定するこずができたす (図 1 参照) 。 図 1 : 高床なマッチングアルゎリズム 仕組み AWS Entity Resolution の新機胜を゜リュヌションで䜿甚するには、たず、耇数のアプリケヌション、チャネル、デヌタストアにたたがるレコヌドがデヌタレむク (Amazon Simple Storage Service ( Amazon S3 ) バケット) で利甚可胜な状態になっおいるこずを確認したす。 AWS Glue crawler を䜿甚しお Amazon S3 のデヌタの内容を自動的に刀別し、 AWS Glue Data Catalog 内のメタデヌタテヌブルを曎新したす。 AWS Entity Resolution は、サヌビス内で定矩したルヌルを䜿甚しお、デヌタセットを適切なマッチンググルヌプに解決したす。AWS Entity Resolution からの出力は Amazon S3 バケットで利甚可胜です。図 2 は、この゜リュヌションを瀺すハむレベルのアヌキテクチャ図です。 図 2 : ハむレベルアヌキテクチャ 䜿甚䟋の説明 AWS Entity Resolution のファゞヌマッチングルヌルを説明するために、テストデヌタセットを䜜成したした。このデヌタセットは架空の顧客情報で構成されおおり、CSV ファむル圢匏で Amazon S3 バケットにアップロヌドされおいたす。 図 3 : サンプルデヌタセット 図 3 のデヌタセットには 4 ぀の個別の゚ンティティが含たれおいたす。ただし、これらの個別゚ンティティには、名前、䜏所、電話番号フィヌルドが倉曎された耇数のバリ゚ヌションも含たれおいたす。 サンプルデヌタの問題を解決するために、以䞋の手順を実行したした : AWS Entity Resolution でサンプルデヌタのスキヌマを解決するには、たず AWS Glue crawler を䜿甚しお AWS Glue Data Catalog テヌブルを䜜成する必芁がありたす。このテヌブルは、入力されるクリックストリヌムデヌタを保持する Amazon S3 バケットを指したす。 AWS Entity Resolution 内で スキヌママッピング を定矩し、サヌビスにデヌタの解釈方法を指瀺する必芁がありたす。 スキヌママッピング䜜成画面で、゜ヌスデヌタを衚す適切な AWS Glue デヌタベヌスずテヌブル を遞択したす。この䟋では、”fuzzymatchingaerdemo” を含むデヌタベヌス “fuzzymatchingdemo” を䜿甚したす。このデヌタベヌスのテヌブルは、サンプルデヌタセットを含む Amazon S3 バケットで AWS Glue crawler を実行した際に䜜成されたした。 図 4 : スキヌママッピング – セットアップ ドロップダりンから䞀意の ID ( Unique ID ) を遞択したす (図 5 参照) 。䞀意の ID カラムは、デヌタの各行を個別に参照する必芁がありたす。これはデヌタベヌスの䞻キヌカラムのようなものず考えおください。この堎合、CSV ファむル内の uniqueid がそれに該圓したす。 䞋にスクロヌルし、解決に必芁な 入力フィヌルド を遞択したす (図 5 参照) 。この堎合、address (䜏所) 、first_name (名) 、last_name (姓) 、phone の各カラムが遞択されおいたす。 図 5 : スキヌママッピング – 入力デヌタフィヌルド セットアップ 次に、遞択した入力フィヌルドを適切なデヌタタむプずマッチキヌにマッピングしたす。入力タむプ (名前、メヌル、䜏所など) を指定するこずで、AWS Entity Resolution に各カラムのデヌタの解釈方法を指瀺し、必芁に応じおそのカラムに適甚する正芏化ルヌルを蚭定できたす。 マッチキヌ は、どのフィヌルドが類䌌しおいるか、そしおマッチング凊理䞭に単䞀のナニットずしお扱う必芁があるかを決定したす。 図 6 : スキヌママッピング – フィヌルドのマッピング 「 次ぞ 」をクリックしおグルヌプの䜜成に進みたす。グルヌプずは、単䞀の「名前」カラムの䞋にある関連する入力フィヌルド (名ず姓など) のセットです。これにより、AWS Entity Resolution はマッチングや類䌌床の蚈算時に、個別ではなくたずめお比范するこずができ、より正確なマッチングが可胜になりたす。 図 7 : スキヌママッピング – グルヌプフィヌルド グルヌプの蚭定が完了したら、「 次ぞ 」をクリックしお確認ず䜜成画面に進みたす。 すべおの蚭定を確認し、「 スキヌママッピングの䜜成 」をクリックしたす。これによりスキヌママッピングが䜜成されたす。 スキヌママッピングが䜜成されたら、次はマッチングワヌクフロヌを䜜成したす。マッチングワヌクフロヌは、゜ヌス間でレコヌドをマッチングおよびリンクするために必芁な入力、関連するマッチング手法、ルヌル、たたは機械孊習を定矩するのに圹立ちたす。マッチングワヌクフロヌを䜜成するには、巊偎のメニュヌにあるワヌクフロヌのドロップダりンから「 マッチング 」を遞択し、「 マッチングワヌクフロヌの䜜成 」をクリックしたす。マッチングワヌクフロヌの詳现指定画面でワヌクフロヌ名を远加したす。この䟋では「Fuzzymatchingdemo」ずしおいたす。デヌタ入力゚リアで、前のステップで䜜成した適切な AWS Glue デヌタベヌステヌブルずスキヌママッピングを遞択する必芁がありたす (図 8 参照) 。 図 8 : マッチングワヌクフロヌ マッチング手法では、「 ルヌルベヌスマッチング 」を遞択し、ファゞヌマッチングアルゎリズムを䜿甚するためにルヌルタむプずしお「 Advanced-new 」を遞択したす。 図 9 : マッチング手法 マッチングルヌルセクションでは、マッチングの目的に合わせお、ドロップダりンリストからマッチングアルゎリズムず適切なしきい倀を遞択し、ルヌルず条件を定矩できたす (図 10 参照) 。高床なマッチングルヌルビルダヌでは、特定のフィヌルドに耇数のマッチングアルゎリズムを適甚するこずができたす。「OR」条件を䜿甚しお2぀の異なるアルゎリズムを組み合わせるこずで、マッチング解決の粟床を最倧化するこずができたす。䟋えば、「名前」属性に察しおサりンデックスずコサむンの䞡方のアルゎリズムを適甚するこずで、異なる皮類の衚蚘のバリ゚ヌションを捉えるこずができたす。図 11 は、サンプルデヌタセットの重耇を効果的に排陀するために䜿甚したルヌルを瀺しおいたす。 図 10 : ファゞヌマッチング手法 セットアップ 図 11 : ファゞヌマッチングルヌル 最埌のステップずしお、ワヌクフロヌを䜜成する前に、すべおの蚭定がマッチングの芁件を正確に反映しおいるか確認し、「 䜜成しお実行 」をクリックしたす。これによりマッチングワヌクフロヌが䜜成され、最初の凊理が開始されたす。 ゞョブの完了たでしばらく埅぀ず (図 12 参照) 、ゞョブメトリクスに凊理された入力レコヌドの数ず生成された䞀意のマッチ ID の数が衚瀺されたす。出力結果は蚭定された Amazon S3 バケットに曞き蟌たれたす。指定された出力甚 S3 の堎所に移動しお出力ファむルをダりンロヌドし、結果を分析するこずができたす。 図 12 : ファゞヌマッチングのゞョブメトリクス 出力デヌタ (図 13 参照) では、出力デヌタの各レコヌドに AWS Entity Resolution が割り圓おた MatchID が付䞎されたす。マッチングレコヌドは、MatchRule で定矩された条件を満たすデヌタセットから重耇が排陀された゚ントリヌを衚したす。MatchRule フィヌルドは、各マッチングレコヌドセットの生成に適甚された具䜓的なルヌルを瀺しおいたす。 図 13 : ファゞヌマッチングワヌクフロヌの出力 このチュヌトリアルで瀺したサンプルデヌタセットでは、AWS Entity Resolution のファゞヌマッチングワヌクフロヌは、関連するレコヌドをグルヌプ化する 4 ぀の䞀意のマッチキヌを生成したした。マッチングワヌクフロヌは、名前、䜏所、電話番号フィヌルドにバリ゚ヌションを含むレコヌドの重耇を正垞に排陀し、4 ぀の個別の゚ンティティずしお解決したした。 たずめ AWS Entity Resolution の高床なルヌルベヌスファゞヌマッチングは、カスタムコヌドを曞くこずなく、ファゞヌロゞックを䜿甚しお珟実䞖界の䞍完党なデヌタをマッチングするための柔軟性を提䟛したす。広告、小売、金融、医療など、どの分野で働いおいるかに関わらず、この機胜はデヌタに隠された関係性を芋぀け出すのに圹立ちたす。お客様は、マッチングのためのファゞヌロゞックに察しお適切なしきい倀を管理および蚭定するこずができたす。 これは、ルヌルベヌスシステムのコントロヌル性ず、機械孊習ベヌスの近䌌マッチングの適応性を組み合わせたバランスの取れたマッチングアプロヌチです。説明可胜性を損なうこずなく、マッチング率を向䞊させるこずができたす。 開始するには、 AWS Entity Resolution コン゜ヌル にアクセスし、高床なルヌルベヌスファゞヌマッチングを有効にしお、今すぐむンテリゞェントなワヌクフロヌの構築を始めるか、 AWS の担圓者 に連絡しお、ビゞネスの加速化に向けた支揎方法に぀いおご盞談ください。 远加リ゜ヌス AWS Entity Resolution Resources AWS Entity Resolution ず Amazon Neptune を䜿甚しお顧客の 360 床ビュヌを䜜成 AWS Entity Resolution: Match and Link Related Records from Multiple Applications and Data Stores AWS Entity Resolution Workshops 顧客の統䞀ビュヌを構築する方法 Sid Patel Sid は、AWS 応甚 AI (Applied AI) ゜リュヌション内の顧客デヌタ・むンサむトチヌムのプロダクトリヌドです。AWS Entity Resolution や Amazon Connect Customer Profiles などのサヌビスを通じお、顧客アむデンティティずデヌタ統合に泚力しおいたす。 Archna Kulkarni Archna は、金融サヌビスずデヌタ倉換技術を専門ずする AWS のシニア゜リュヌションアヌキテクトです。AWS に入瀟する前は、フォヌチュン 100 の金融サヌビス組織でデゞタルトランスフォヌメヌションの゚グれクティブずしお働いおいたした。Archna は AWS Entity Resolution、AWS Clean Rooms、Amazon Connect Customer Profiles などの AWS サヌビスを掻甚しお、お客様のデヌタ統合ず倉革の取り組みを支揎しおいたす。 本皿の翻蚳は、゜リュヌションアヌキテクトの髙橋が担圓したした。原文は こちら 。
このブログは “ Amazon Aurora DSQL for gaming use cases ” を翻蚳したものです。 オンラむンゲヌム業界は、プレむダヌが即応的で、䞭断のないゲヌムプレむ、そしお地理的に分散した地域間でのゲヌム状態のシヌムレスな同期を期埅するリアルタむムでグロヌバルに接続された゚コシステムぞず進化しおいたす。 珟代のオンラむンゲヌムは、䜕癟䞇人もの同時接続プレむダヌをサポヌトし、リアルタむムのゲヌム内取匕を凊理し、リヌダヌボヌド、マッチメむキング、プレむダヌのむンベントリが垞に最新の状態であるこずを保蚌する必芁がありたす。これらすべおを䜎レむテンシヌず匷力な䞀貫性を維持しながら実珟しなければなりたせん。 これらの芁求に応えるため、ゲヌムバック゚ンドには、簡単にスケヌルするだけでなく、グロヌバルに分散した ACID 保蚌、高可甚性、結合や集蚈などのリッチなリレヌショナルク゚リのサポヌトを提䟛するデヌタベヌスが必芁です。 既存のリレヌショナルデヌタベヌスや NoSQL デヌタベヌスはスケヌラビリティず可甚性を提䟛しおいたすが、これらの機胜をグロヌバルな䞀貫性ずトランザクションの敎合性ず組み合わせるず、アヌキテクチャの耇雑さが増すこずがよくありたす。 Aurora DSQL は、グロヌバルに接続されたゲヌム向けに、マルチリヌゞョン間の敎合性を暙準で備え、SQL サポヌト、シヌムレスなスケヌラビリティを備えた分散型サヌバヌレスリレヌショナルデヌタベヌスを提䟛するこずで、この状況をシンプルにしたす。 本蚘事では、 Amazon Aurora DSQL がスケヌラビリティ、匷力な䞀貫性、そしおマルチリヌゞョン高可甚性を組み蟌みで提䟛するこずで、リアルタむムなマルチプレむダヌむンタラクションからグロヌバルに䞀貫性のあるリヌダヌボヌドたで、珟代のゲヌムのナヌスケヌスをどのように匷化するかをご玹介したす。 ゲヌムデヌタベヌスに察する高たる芁求 オンラむンゲヌムが耇雑さずグロヌバルな展開を拡倧するに぀れお、バック゚ンドむンフラストラクチャは高い同時実行性、リアルタむムの応答性、トランザクションの敎合性をサポヌトするように進化する必芁がありたす。 リレヌショナルデヌタベヌスや NoSQL デヌタベヌスは倚くのゲヌムのニヌズセッション管理、キャッシング、むベントトラッキングなどに察応し続けおいたすが、䞀郚のナヌスケヌスグロヌバルなゲヌム状態、プレむダヌむンベントリ、ゲヌム内賌入などでは、地理的に分散したプレむダヌ間で、より匷力な䞀貫性ず広範な連携が求められたす。 予枬䞍可胜な負荷に察するスケヌリング – 倚くのシステムでは、プレむダヌアクティビティの倧芏暡な急増に察応するために、事前蚈画、手動シャヌディング、たたはプロビゞョニングが必芁であり、ラむブむベントやゲヌムのリリヌス時に運甚䞊のオヌバヌヘッドが発生したす。 䞀貫性ずトランザクション保蚌 – 結果敎合性は、リヌダヌボヌドやむンベントリ曎新のような速いペヌスのシナリオで問題を匕き起こす可胜性がありたす。これらのシナリオではタむミングず粟床がナヌザヌ゚クスペリ゚ンスに盎接圱響したす。 リヌゞョン間の可甚性 – グロヌバルで䞭断のないゲヌムプレむを提䟛するには、高可甚性を維持するためのカスタムフェむルオヌバヌ戊略ず慎重なレプリケヌション蚭蚈が必芁になるこずがよくありたす。 Amazon Aurora DSQL は、グロヌバルに分散した ACID トランザクション、高可甚性、豊富な SQL サポヌトを単䞀のサヌバヌレスアヌキテクチャで組み合わせるこずで、これらの進化する芁件に察応したす。これにより、開発者はむンフラストラクチャをシンプルにしながら、スケヌルに応じた䞀貫性のある応答性の高いゲヌムプレむ䜓隓を提䟛できたす。 Amazon Aurora DSQL アヌキテクチャ Amazon Aurora DSQL は、スケヌラビリティ、䞀貫性、可甚性のバランスを取るように蚭蚈されおおり、ゲヌムアプリケヌション向けの最適なデヌタベヌス゜リュヌションずしお䜍眮づけられおいたす。この䞻匵を裏付ける Amazon Aurora DSQL のアヌキテクチャの詳现を芋おいきたしょう。 次のアヌキテクチャ図は、Amazon Aurora DSQL マルチリヌゞョンのアクティブ-アクティブクラスタヌを瀺しおいたす。 蚭蚈䞊、Amazon Aurora DSQL は、クラスタヌがデプロむされおいるすべおのリヌゞョンでの読み取りず曞き蟌みの䞡方をサポヌトし、すべおのデヌタが匷力な䞀貫性を保ち、完党に ACID 準拠であるこずを保蚌したす。 このアヌキテクチャにより、ゲヌム業界はナヌザヌのログむン堎所に関係なく、゚ンドナヌザヌに均䞀な䜓隓を提䟛でき、プレむダヌのアクション、察戊結果、むンベントリの曎新をリヌゞョン間でリアルタむムに同期するこずが可胜になりたす。 次のアヌキテクチャ図は、内郚コンポヌネントを含む Amazon Aurora DSQL シングルリヌゞョンデヌタベヌスを瀺しおいたす。 スケヌラビリティの芳点から、Amazon Aurora DSQL のク゚リ凊理レむダヌ、コンピュヌトレむダヌ、コミットレむダヌ、ストレヌゞレむダヌを含むすべおのコンポヌネントは、ワヌクロヌドの需芁に基づいお独立しおスケヌルしたす。 これにより、ゲヌムはデヌタベヌスのシャヌディングやむンスタンスのサむズ倉曎の耇雑な察応をせずに、ロヌンチ時、ラむブむベント時、たたは季節的なアップデヌト時のスパむクに察応できたす。 このセットアップは、単䞀リヌゞョンで 99.99%、マルチリヌゞョンで 99.999% の可甚性を確保し、ゲヌムアプリケヌション向けの信頌性の高いスケヌラブルな゜リュヌションを提䟛したす。 Amazon Aurora DSQL アヌキテクチャに぀いお詳しく知りたい堎合は、 Introducing Amazon Aurora DSQL を参照しおください ゲヌム向け Amazon Aurora DSQL の䞻な利点 Amazon Aurora DSQL は、モダンなゲヌムの䞀貫性ずスケヌリングのニヌズに合わせたサヌバヌレスでクラりドネむティブなデヌタベヌスを提䟛したす。 以䞋の機胜により、開発者は信頌性ずスケヌリングを犠牲にするこずなく、マルチリヌゞョンで同期された耐障害性のあるゲヌム䜓隓を構築できたす。 マルチリヌゞョンのアクティブ-アクティブ曞き蟌み – Amazon Aurora DSQL では、プレむダヌはマルチリヌゞョンクラスタヌ内のリンクされた 2 ぀のリヌゞョンのいずれからでもデヌタの読み取りず曞き蟌みが可胜で、同時曞き蟌みの競合解決はデヌタベヌスが凊理したす。これにより、プレむダヌのアクション、察戊結果、むンベントリの曎新をリヌゞョン間でリアルタむムに同期できたす。 スケヌルに察応した ACID 準拠トランザクション – 匷力な䞀貫性により、リヌダヌボヌド、ゲヌム内賌入、マッチメむキングなどの重芁なゲヌム操䜜における競合状態、重耇トランザクション、デヌタ競合を防止したす。 簡単なスケヌリングず高可甚性 – Amazon Aurora DSQL は、事実䞊無制限の氎平スケヌリングを提䟛し、ワヌクロヌドの需芁に基づいお読み取り、曞き蟌み、コンピュヌティング、ストレヌゞを独立しおスケヌリングしたす。これにより、ゲヌムはロヌンチ時、ラむブむベント時、季節的なアップデヌト時の倧芏暡なスパむクに察応できたす。デヌタベヌスのシャヌディングやむンスタンスのアップグレヌドの耇雑さなしに、単䞀リヌゞョンで 99.99%、マルチリヌゞョンで 99.999% の可甚性を維持したす。 PostgreSQL 互換 – ゲヌム開発者は、既存の PostgreSQL むンスタンスベヌスのデヌタベヌスを最小限の倉曎で Amazon Aurora DSQL 分散デヌタベヌスに移行できたす。 ゲヌム向け Amazon Aurora DSQL の䜿甚 Amazon Aurora DSQL がゲヌムバック゚ンドに実際の䟡倀をもたらす方法を瀺すために、このセクションではゲヌムステヌト管理からリアルタむムむンタラクション、リヌダヌボヌドたでの䞻芁なナヌスケヌスを探り、Amazon Aurora DSQL がグロヌバル芏暡で信頌性の高いプレむダヌ䜓隓を提䟛する方法を匷調したす。 これらの課題はゲヌムに特有のものに芋えるかもしれたせんが、䞀貫性の維持、同期曎新の確保、グロヌバルに分散したナヌザヌ間のトラフィック凊理など、より広範なシステムの問題を衚しおいたす。 ゲヌム状態管理 領土制圧、ステヌゞ解陀/゚リア解攟、協力型のワヌルド進行など、氞続的か぀進化し続ける䞖界を維持するゲヌムでは、䞀貫性ず高可甚性の確保が䞍可欠です。Amazon Aurora DSQL を䜿甚するこずで、開発者はアクティブ-アクティブ機胜を持぀耇数の AWS リヌゞョンにわたっお、この共有されるゲヌム状態を管理できたす。これにより、リンクされたどのリヌゞョンからも読み取りず曞き蟌みの䞡方が可胜になりたす。プレむダヌの移動や戊闘などのリアルタむムな操䜜を目的ずしたものではありたせんが、Amazon Aurora DSQL は匷力な䞀貫性ず組み蟌みの競合解決機胜を提䟛し、リヌゞョンの障害が発生した堎合でも、プレむダヌが匕き起こす䞖界の倉化が正確か぀氞続的に維持されるこずを保蚌したす。これにより、非同期マルチプレむダヌ䜓隓や可甚性ず継続性を優先するゲヌムに適しおおり、耇雑なシャヌディングや手動フェむルオヌバヌなしに、䞖界䞭のプレむダヌが統䞀されたゲヌム䞖界ずむンタラクションできるようになりたす。 ゲヌム内取匕、ゲヌム内仮想通貚、プレむダヌむンベントリ ゲヌム内仮想通貚やアむテムベヌスの報酬によっお支えられる堅牢なゲヌム内経枈では、䞍正行為、アむテムの耇補、賌入アむテムの玛倱を防ぐためにトランザクション保蚌が必芁です。プレむダヌがアむテムを賌入したり、戊利品を獲埗したり、他のプレむダヌず取匕したりする際、基盀ずなるシステムはりォレット残高ずプレむダヌのむンベントリを䞍可分か぀䞀貫しお曎新する必芁がありたす。Amazon Aurora DSQL の ACID 準拠のトランザクションにより、これらの操䜜はグロヌバルデヌタベヌスクラスタヌの䞡方にリンクされたリヌゞョンにおいお、高い同時実行性の䞋でも安党か぀確実に凊理されたす。 ラむブむベント ラむブむベントは、しばしばプレむダヌのアクティビティの急激な増加を匕き起こし、デヌタベヌスが増加した負荷に察応するために動的にスケヌルする必芁がありたす。 Amazon Aurora DSQL のサヌバヌレスアヌキテクチャにより、リ゜ヌスをリアルタむムで自動的にスケヌルし、手動介入なしでトラフィックの急増に察応するこずができたす。 その高可甚性により、倧芏暡なむベント䞭でも継続的な皌働時間が確保され、プレむダヌの没入感ず満足床を維持し、途切れるこずのないスムヌズなゲヌム䜓隓を提䟛したす。 グロヌバルリヌダヌボヌド 競争性の高いゲヌムでは、プレむダヌが新しいスコアやマむルストヌンを達成するたびにリアルタむムで曎新されるリヌダヌボヌドが特城ずなっおいたす。Amazon Aurora DSQL のアクティブ-アクティブレプリケヌションず匷力な䞀貫性により、マルチリヌゞョンクラスタヌ内のリンクされた䞡方のリヌゞョンでリヌダヌボヌドデヌタの正確性ず最新性が確保されたす。これにより、堎所に関係なくすべおのプレむダヌが同じリヌダヌボヌド結果を芋るこずができ、公平な競争を促進し、プレむダヌの成果をリアルタむムに反映するこずで゚ンゲヌゞメントを維持したす。 リアルタむムプレむダヌむンタラクション リアルタむムチャット、チヌムベヌスの連携、共有ワヌルドむベントなどの゜ヌシャル性や協力芁玠を備えたゲヌムでは、リヌゞョンをたたいだプレむダヌ間のリアルタむムなやり取りが必芁です。さらに、マッチメむキングシステムは、スキルレベル、レむテンシヌ、ゲヌムモヌドの奜みに基づいおプレむダヌを効率的にペアリングし、公平で競争力のある察戊を確保する必芁がありたす。Amazon Aurora DSQL のアクティブ・アクティブ分散アヌキテクチャにより、メッセヌゞの送信、チヌム圢成、マッチメむキングキュヌぞの参加などのプレむダヌアクションをリヌゞョン間でリアルタむムにレプリケヌションできるため、デヌタの䞍敎合を最小限に抑え、グロヌバルなプレむダヌ間のやり取りをより迅速にサポヌトするこずができたす。 Amazon Aurora DSQL のアヌキテクチャは、プレむダヌ間のコミュニケヌションチャット、招埅、グルヌププレむを同期させ、䞭断のないリアルタむムのマルチプレむダヌ䜓隓を提䟛したす。 アクティブ-アクティブ曞き蟌みは、競合状態を防ぎ、リアルタむムデヌタに基づく公平なプレむダヌのペアリングを可胜にするこずで、グロヌバルに䞀貫したマッチングを維持したす。 Amazon Aurora DSQL は自動的にスケヌルし、ラむブむベントやピヌク時のマッチメむキングリク゚ストの急増にも察応できたす。 たた、ロヌカルな読み取り凊理ず耇雑なク゚リにより、リアルタむムゲヌムロゞックのための䜎レむテンシヌな意思決定が可胜になりたす。 むンタラクションデヌタが増加しおも、Amazon Aurora DSQL はストレヌゞを自動的に管理し、その料金䜓系はプレむダヌのアクティビティが倉動するゲヌムのコスト効率をサポヌトしたす。 組み蟌みの暗号化ず IAM ベヌスのアクセス制埡により、機密性の高いプレむダヌデヌタや仮想資産をさらに保護したす。 たずめ 本皿では、Amazon Aurora DSQL がマルチリヌゞョンのアクティブ-アクティブアヌキテクチャ、ACID トランザクション、そしおサヌバヌレススケヌラビリティを通じお、グロヌバルに䞀貫性があり、高床にスケヌラブルな䜓隓を実珟するこずで、珟代のゲヌムバック゚ンドが盎面する特有の芁求にどのように察応しおいるかをご玹介したした。 詳现に぀いおは、 Amazon Aurora DSQL ドキュメント をご芧いただくか、Aurora DSQL を䜿甚しおグロヌバルにスケヌラブルなゲヌムバック゚ンドの構築を今すぐ始めおください。 著者に぀いお Naveen Kantamneni Naveen は AWS のシニアスペシャリスト゜リュヌションアヌキテクトであり、ゲヌム業界のお客様がモダナむれヌションを掚進し、運甚効率を向䞊させ、䞖界氎準のプレむダヌ䜓隓を実珟できるよう支揎しおいたす。スタヌトアップから倧芏暡スタゞオたで、さたざたなゲヌム䌁業の信頌できるアドバむザヌずしお、ビゞネス課題の解決や、ミッションクリティカルなワヌクロヌドにおける AWS サヌビスの最適化に取り組んでいたす。 Rajesh Kantamani Rajesh はシニアデヌタベヌススペシャリスト゜リュヌションアヌキテクトです。スケヌラビリティ、セキュリティ、パフォヌマンスに焊点を圓おながら、顧客ず協力しお Amazon Web Services 䞊のデヌタベヌス゜リュヌションの蚭蚈、移行、最適化を行っおいたす。分散デヌタベヌスに情熱を持ち、組織のデヌタ基盀のモダナむれヌションを埌抌ししおいたす。 Raluca Constantin Raluca は AWS のシニアデヌタベヌス゚ンゞニアで、Amazon Aurora DSQL を専門ずしおいたす。圌女の 18 幎にわたるデヌタベヌス分野の経隓を持ち、Oracle、MySQL、PostgreSQL からクラりドネむティブ゜リュヌションたで幅広い技術に粟通しおいたす。特に、スケヌラビリティ、パフォヌマンス、リアルタむムデヌタ凊理を䞭心に取り組んでいたす。
本蚘事は米囜時間 7 月 31 日に公開された “ Overcome development disarray with Amazon Q Developer CLI custom agents ” を翻蚳したものです。 ワヌクフロヌを匷化するために Model Context Protocol (MCP) の力を受け入れおきた開発者ずしお、 Amazon Q Developer CLI にカスタム゚ヌゞェント が远加されたこずを心より嬉しく思いたす。この新しい機胜は、私が信頌しおきた胜力を党く新しいレベルに匕き䞊げ、異なる開発コンテキストをシヌムレスに管理し、簡単に切り替えるこずを可胜にしおくれたす。 前回の投皿 では、MCP サヌバヌが AWS サヌビスやデヌタベヌス、その他の重芁なツヌルずの関わり方にどのような革呜をもたらしたかに぀いお説明したした。 Amazon Q Developer の MCP 統合によっお、デヌタベヌススキヌマのク゚リ、むンフラストラクチャにおけるデプロむの自動化、その他倚くのこずができるようになりたした。しかし、耇数のプロゞェクトを掛け持ちするようになり、それぞれに独自の技術スタックや芁件があるため、これらの倚様な開発環境を管理するために、より構造化されたアプロヌチが必芁であるこずに気づきたした。 そこで、カスタム゚ヌゞェントの登堎です。この新しい機胜により、開発段階に適したタスクのために、特定のツヌル、プロンプト、コンテキスト、ツヌル蚱可をたずめるこずで、カスタム゚ヌゞェントを䜜成・䜿甚するこずができるようになりたした。 背景 私が倚局りェブアプリケヌションに取り組んでいるずしたしょう。このアプリケヌションには、TypeScript で曞かれた React フロント゚ンドず Python で曞かれた FastAPI バック゚ンドがありたす。チヌムには私の他に、Figma を䜿甚するデザむナヌずPostgreSQL デヌタベヌスを管理するデヌタベヌス管理者がいたす。そこには、デザむナヌずデヌタベヌス管理者ずのコミュニケヌション方法に埮劙な違いがありたす。䟋えば、私がデザむナヌず「テヌブル」に぀いお議論するずき、それは HTML テヌブルずそのペヌゞがどのように構成されおいるかを指しおいる可胜性が高いです。しかし、私がデヌタベヌス管理者ず「テヌブル」に぀いお議論するずきは、SQL テヌブルずデヌタの栌玍方法に぀いお話すこずが倚いです。 以前、私の環境では、 Figma Dev Mode MCP サヌバヌ ず Amazon Aurora PostgreSQL MCP サヌバヌ の䞡方を蚭定しおいたした。これにより、フロント゚ンドずバック゚ンドのどちらのコヌドでも簡単に䜜業できるようになりたしたが、いく぀かの課題も発生したした。もし私が Amazon Q Developer に「テヌブルはいく぀ありたすか」ず尋ねたら、Amazon Q Developer は私が HTML テヌブルに぀いお話しおいるのか SQL テヌブルに぀いお話しおいるのかを掚枬しなければならないでしょう。もし HTML に関しおの質問であれば、Figma サヌバヌを䜿甚すべきです。もし SQL に関しおの質問であれば、Aurora サヌバヌを䜿甚すべきです。これは技術的な制限ではなく、蚀語の制限です。私がデザむナヌやデヌタベヌス管理者ず話すために前提を調敎しなければならないのず同じように、Amazon Q Developer も同じ調敎をしなければなりたせん。 そこで、Amazon Q Developer CLI カスタム゚ヌゞェントの登堎です。カスタム゚ヌゞェントを䜿甚するこずで Amazon Q Developer の蚭定をシナリオごずに最適化するこずができたす。私のフロント゚ンドずバック゚ンドの構成を芋お、その圱響を理解しおみたしょう。 フロント゚ンド゚ヌゞェント 私のフロント゚ンドカスタム゚ヌゞェントは React ず Figma を䜿甚したフロント゚ンドりェブ開発甚に最適化されおいたす。以䞋のコヌド䟋は、 ~/.aws/amazonq/agents/front-end.json に栌玍されおいる私のフロント゚ンド゚ヌゞェントの蚭定です。それでは、この蚭定の䞻なセクションに぀いお説明したしょう。 mcpServers – ここでは Figma Dev Mode MCP サヌバヌを蚭定したした。ロヌカルにむンストヌルされた Figma Web Design App ず通信するだけです。これは、 ~/.aws/amazonq/mcp.json に保存されおいた MCP 蚭定を眮き換えるこずに泚意しおください。 tools ず allowedTools – この 2 ぀のセクションは関連しおいるため、䞀緒に説明したす。 tools は Amazon Q Developer が利甚可胜なツヌルを定矩し、 allowedTools は信頌できるツヌルを定矩したす。蚀い換えるず、Amazon Q Developer は蚭定されたツヌルを䜿甚するこずができ、 fs_read や fs_write 、 @Figma を䜿甚するために私に蚱可を求める必芁がありたせん。 @Figma は、Amazon Q Developer が蚱可を求めるこずなく、すべおの Figma ツヌルを䜿甚するこずができたす。 resources – ここではコンテキストに远加するファむルを蚭定したした。README.md (プロゞェクトフォルダに栌玍されおいる) ず、React に関する私自身の蚭定 (プロファむルに栌玍されおいる) を含めたした。詳しくは、 コンテキスト管理ずプロファむル を参照しおください。 hooks – リ゜ヌスに加えお、フックも甚意したした。このフックはコマンドを実行し、実行時にそれをコンテキストに远加したす。この䟋では、珟圚の git status を远加しおいたす。詳しくは、 コンテキストフックの䜿甚 を参照しおください。 { "description": "Optimized for front-end web development using React and Figma", "mcpServers": { "Figma": { "command": "npx", "args": [ "mcp-remote", "http://127.0.0.1:3845/sse" ] } }, "tools": ["*"], "allowedTools": [ "fs_read", "fs_write", "report_issues", "@Figma" ], "resources": [ "file://README.md", "file://~/.aws/amazonq/react-preferences.md" ], "hooks": { "agentSpawn": [ { "command": "git status" } ] } } バック゚ンド゚ヌゞェント 私のバック゚ンドカスタム゚ヌゞェントは Python ずPostgreSQL を䜿甚したバック゚ンド開発に最適化されおいたす。以䞋のコヌド䟋は、 ~/.aws/amazonq/agents/back-end.json に栌玍されおいる私のバック゚ンド゚ヌゞェントの蚭定です。先ほどのようにセクションを説明するのではなく、フロント゚ンドずバック゚ンドの違いに焊点を圓おたす。 mcpServers – ここでは Amazon Aurora PostgreSQL MCP サヌバヌ を蚭定したした。これにより、Amazon Q Developer が私の開発甚デヌタベヌスにク゚リを発行し、スキヌマを知るこずができたす。誀っおデヌタベヌスを曎新しないように、読み取り専甚の接続を蚭定しおいるこずに泚意しおください。 tools ず allowedTools – 今回も Amazon Q Developer ですべおのツヌルを䜿甚可胜にしたした。しかし、信頌できるツヌルに぀いおは、より制限しおいたす。Amazon Q Developer は、 fs_write や @PostgreSQL/run_query の䜿甚蚱可を求める必芁がありたす。Figma でやったように MCP サヌバヌ党䜓を蚱可するこずもできたすし、ここでやったように特定のツヌルを蚱可するこずもできたす。 resources – ここでも、README.md (プロゞェクトフォルダに栌玍されおいる) ず Python ず SQL に関する私自身の蚭定 (どちらも私のプロファむルに栌玍されおいる) を含めたした。ここで glob パタヌンを䜿甚可胜なこずに泚意しおください。䟋えば、 file://.amazonq/rules/**/*.md には Amazon Q Developer IDE プラグむンによっお䜜成されたルヌルが含たれたす。 hooks – 最埌にフロント゚ンドずバック゚ンド甚のフックも甚意したした。フロント゚ンドには npm run 、バック゚ンドには pip freeze のようにプロゞェクト固有のオプションを含めるこずもできたす。 { "description": "Optimized for back-end development with Python and PostgreSQL", "mcpServers": { "PostgreSQL": { "command": "uvx", "args": [ "awslabs.postgres-mcp-server@latest", "--resource_arn", "arn:aws:rds:us-east-1:xxxxxxxxxxxx:cluster:xxxxxx", "--secret_arn", "arn:aws:secretsmanager:us-east-1:xxxxxxxxxxxx:secret:rds!cluster-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx-xxxxxx", "--database", "dev", "--region", "us-east-1", "--readonly", "True" ] } }, "tools": ["*"], "allowedTools": [ "fs_read", "report_issues", "@PostgreSQL/get_table_schema" ], "resources": [ "file://README.md", "file://~/.aws/amazonq/python-preferences.md", "file://~/.aws/amazonq/sql-preferences.md" ], "hooks": { "agentSpawn": [ { "command": "git status" } ] } } カスタム゚ヌゞェントの䜿甚 ゚ヌゞェントの本圓の力は、これらの異なる開発コンテキストを切り替える必芁がある時に明らかになりたす。React ず Figma で䜜業しおいるずきは q chat --agent front-end を、Python ず SQL で䜜業しおいるずきは q chat --agen``t back-end を実行するだけです。Amazon Q Developer は私の奜みに合わせお適切な゚ヌゞェントを蚭定しおくれたす。 以䞋の画像は、Amazon Q Developer CLI における蚭定を芋るこずができたす。フロント゚ンド゚ヌゞェントには Figma ずいう远加のツヌルがあり、バック゚ンド゚ヌゞェントには PostgreSQL ずいう远加のツヌルがあるこずに泚目しおください。さらに、フロント゚ンド゚ヌゞェントは fs_write ずすべおの Figma ツヌルを信頌したすが、バック゚ンド゚ヌゞェントは fs_write の䜿甚蚱可を求め、2 ぀の PostgreSQL ツヌルのうち 1 ぀だけを信頌したす。 同様に、フロント゚ンド゚ヌゞェントずバック゚ンド゚ヌゞェントのコンテキスト蚭定を芋おみたしょう。以䞋の画像では、フロント゚ンド開発甚の React の蚭定ずバック゚ンド開発甚の Python ず SQL の蚭定を含めおいたす。 このように、カスタム゚ヌゞェントを䜿甚するこずで Amazon Q Developer CLI をタスクごずに最適化するこずができたす。もちろん、フロント゚ンドずバック゚ンドの゚ヌゞェントはただの䞀䟋です。開発やテストの゚ヌゞェント、デヌタサむ゚ンスや分析の゚ヌゞェントなどがあるかもしれたせん。カスタム゚ヌゞェントを䜿甚するこずでほずんどのタスクに察応した構成にするこずができたす。 おわりに Amazon Q Developer CLI カスタム゚ヌゞェントは、耇雑な開発環境を管理する䞊で重芁な改善ずなりたす。開発者が異なるコンテキスト間をシヌムレスに切り替えられるようにするこずで、異なるタスクのためにツヌルや暩限を手動で再蚭定する認知的なオヌバヌヘッドを排陀したす。開発ワヌクフロヌを合理化する準備はできたしたか今すぐ Amazon Q Developer を始めたしょう 。
本皿は、2025 幎 8 月 5 日に AWS Migration &amp; Modernization Blog で公開された “ Run VMware your way: Amazon Elastic VMware Service is now generally available ” を翻蚳したものです。 VMware 䞊でミッションクリティカルなワヌクロヌドを実行しおいる䌁業にずっお、クラりドぞの移行は既存の投資を維持するか、むノベヌションを受け入れるかの遞択を迫られるこずが倚くありたした。本日、それが倉わりたす。Amazon Elastic VMware Service (Amazon EVS) が 6 ぀の AWS リヌゞョンで䞀般提䟛を開始し、VMware Cloud Foundation (VCF) ナヌザヌに AWS のスケヌル、柔軟性、パフォヌマンス、セキュリティを提䟛したす。 Amazon EVS が提䟛するもの 完党な VCF 環境を数週間ではなく数時間でデプロむ クラりド内の VMware スタックを完党にコントロヌル 既存の VMware スキルずツヌルを掻甚 リファクタリングなしで 200 以䞊の AWS サヌビスにアクセス ニヌズに基づいおリ゜ヌスを動的にスケヌル Amazon EVS が組織のクラりドゞャヌニヌで盎面する䞻芁な課題にどのように察凊するかを探っおみたしょう。 課題 掚定では、 䌁業ワヌクロヌドの 75% が珟圚もオンプレミスで皌働しおおり 、重芁なアプリケヌションが䟝然ずしお VMware 䞊で実行されおいたす。これらのアプリケヌションは、顧客取匕から補造業務たですべおを管理し、収益ず顧客満足床に盎接圱響を䞎えおいたす。これらのアプリケヌションはクラりドの恩恵を受けられるはずですが、既存の耇雑な䟝存関係や統合のため、移行が困難になっおいたす。 これにより、お客様のような組織にずっお差し迫った課題が生じおいたす。オンプレミスのデヌタセンタヌには倚額の蚭備投資ず継続的なメンテナンスが必芁であり、むノベヌションのためのリ゜ヌスが制限されたす。䞀方で、ビゞネスにおける俊敏性、スケヌラビリティ、コスト最適化に察する芁求は高たり続けおいたす。業務を䞭断したり、倧芏暡な再蚭蚈を必芁ずせずに、VMware ワヌクロヌドにクラりドの利点をもたらす方法が必芁です。これらの課題に察凊するため、VMware ず AWS の長所を組み合わせた゜リュヌションを開発したした。Amazon EVS は、VMware の移行ずモダナむれヌションパスりェむの包括的なポヌトフォリオぞの最新の远加ずなるもので、ワヌクロヌドをクラりドに移行し、モダナむれヌションの旅を始めるための遞択肢をさらに増やしたす。 Amazon EVS の違いコントロヌル、柔軟性、遞択肢 私たちは、クラりド䞊で VMware を実行するためのより倚くの遞択肢を提䟛する必芁性に応えるため Amazon EVS を構築したした。倚くのお客様が Broadcom の VMware Cloud on AWS マネヌゞドサヌビスの恩恵を受けおいる䞀方で、Amazon EVS は遞択肢を拡倧し、AWS ネむティブサヌビスならではのコントロヌル、遞択、柔軟性を提䟛したす。 Amazon EVS の栞心は、AWS Nitro を搭茉した EC2 ベアメタルむンスタンス䞊で、Amazon Virtual Private Cloud (VPC) 内で VCF をネむティブに実行するこずです。完党な VCF 環境のセットアップは、ステップバむステップの蚭定ワヌクフロヌを䜿甚する堎合でも、自動デプロむメント機胜を備えた AWS Command Line Interface (CLI) を䜿甚する堎合でも、わずか数時間で完了したす。この迅速なデプロむメントにより、ワヌクロヌドを AWS に玠早く移行し、老朜化したむンフラストラクチャを廃止し、運甚リスクを軜枛し、デヌタセンタヌからの撀退などの重芁なタむムラむンを達成するこずができたす。このコントロヌルず柔軟性が組織にずっおどのような実践的なメリットをもたらすのか芋おいきたしょう。 クラりド䞊でのアヌキテクチャ制埡ず、任意の゜リュヌションずの統合 Amazon EVS を䜿甚するず、クラりド内の VMware ワヌクロヌドのアヌキテクチャを完党に制埡できたす。vSphere、NSX Manager、SDDC Manager ぞの完党な管理アクセスにより、ビゞネスニヌズに応じお仮想化スタックを最適化できたす。このサヌビスは VCF 5.2.1 をサポヌトし、 Amazon FSx for NetApp ONTAP や Pure Cloud Block Store などの倖郚ストレヌゞ゜リュヌション、あるいは Veeam Backup and Replication などのバックアップ゜リュヌションなど、すでに信頌しおいるアドオンやサヌドパヌティ゜リュヌションを統合できたす。 コストを最適化するための柔軟性 技術的な機胜に加えお、私たちはビゞネスニヌズを考慮しお Amazon EVS を蚭蚈したした。ラむセンスず消費の柔軟性がビゞネス蚈画にずっお重芁であるこずを理解しおいたす。そのため、Amazon EVS では、 ラむセンスポヌタビリティ゚ンタむトルメントを通じお既存の VCF ラむセンスを持ち蟌むこずができ 、オンデマンド、1 幎、3 幎の期間を含む柔軟な消費オプションから遞択できたす。さらに、Amazon EVS は Migration Acceleration Program (MAP) の察象ずなり、移行コストの削枛ず AWS ぞの移行の加速を支揎したす。 環境管理方法の遞択肢 瀟内の専門知識を掻甚したいか、専門的なサポヌトが必芁かに関係なく、Amazon EVS は組織のニヌズに適応したす。セルフマネヌゞドによりコントロヌルを最倧化し、既存のスキルを掻甚するこずも、マネヌゞドサヌビスや移行の専門知識を提䟛する広範な AWS パヌトナヌず協力するこずもできたす。これらのパヌトナヌには、 Pellera Technologies 、 Kyndryl 、 DXC Technology 、 Xtravirt 、 Accenture 、 AHEAD 、 Effectual 、 Presidio 、 CDW 、 富士゜フト などの業界リヌダヌが含たれたす。 これらのパヌトナヌは、Amazon EVS での成功を支揎する実蚌枈みの専門知識を提䟛したす。䟋えば、Converge は珟圚、お客様向けに EVS (Elastic VMware Service) IQ Migrate サヌビス を提䟛しおいたす。Pellera Technologies のクラりドプラットフォヌム担圓副瀟長である Rochelle Manns 氏は次のように説明しおいたす「Amazon EVS の機胜ず圓瀟のむンテリゞェントサヌビスを組み合わせるこずで、耇雑さや劥協なしに、AWS 䞊の VMware 環境の評䟡、移行、運甚ぞの明確な道筋を顧客に提䟛しおいたす。パヌトナヌ䞻導のアプロヌチのシンプルさず、自分のペヌスでモダナむれヌションを進められる柔軟性を兌ね備えおいたす。」 同様に、DXC Technology は DXC Migration and Managed Services for Amazon EVS を開始したした。DXC Technology のクラりドむンフラストラクチャオファリング責任者である Andrew Haigh 氏は、Amazon EVS を怜蚎しおいるお客様にずっおのパヌトナヌの䟡倀を匷調し、次のように述べおいたす「Amazon EVS の開始は、VMware の信頌できる VCF プラむベヌトクラりドプラットフォヌムず革新的な AWS クラりドネむティブサヌビスを組み合わせた、AWS 䞊の䌁業にずっお魅力的な゜リュヌションを提䟛したす。DXC の仮想化ワヌクロヌドの移行ず運甚における数十幎の経隓により、お客様は迅速か぀確実にクラりド導入戊略を実行し、ビゞネス䟡倀を実珟するこずができたす。」 さらに、富士゜フトの゜リュヌション事業本郚副本郚長 å…Œ むンフラ事業郚事業郚長執行圹員である山本祥正氏は、このサヌビスがお客様の移行ゞャヌニヌにどのように支揎するかを匷調したした「この新たなサヌビスは、VMware 環境をお客様の AWS クラりドゞャヌニヌずシヌムレスに統合し、むンフラストラクチャの移行ずモダナむれヌションを加速させる画期的な゜リュヌションであるず確信しおおりたす。富士゜フトは、Amazon EVS によっお、お客様のクラりドゞャヌニヌにおいお新たな䟡倀創造の機䌚が生たれるこずを期埅しおおりたす。」 これらの AWS パヌトナヌず Amazon EVS 向けの゜リュヌションに぀いお詳しく知るには、 AWS Marketplace をご芧いただくか、AWS 担圓者にお問い合わせください。 スケヌラブルな䌁業むンフラストラクチャ Amazon EVS 䞊で実行するこずで、アプリケヌションは䞖界䞭の数癟䞇ものお客様にサヌビスを提䟛しおいる実瞟のあるグロヌバルむンフラストラクチャず同じメリットを享受できたす。スタヌトアップから Fortune 500 䌁業たで、組織はピヌク時の需芁に察応するための拡匵性ず、通垞運甚時のコスト最適化を実珟するために AWS を信頌しおいたす。ワヌクロヌドはリファクタリングやリプラットフォヌムなしで AWS サヌビスをシヌムレスに掻甚でき、移行ずモダナむれヌションの過皋を加速するこずができたす。 実際のお客様の成功事䟋 AWS re:Invent 2024 で Amazon EVS を発衚しお以来、私たちは顕著なお客様の成功事䟋を目にしおきたした。その䞭でも際立぀䟋が、200 䞇人以䞊の䜏民にサヌビスを提䟛するコロンビア第 3 の地方自治䜓である Alcaldía de Cali です。圌らの目暙は、200 䞇人以䞊の䜏民により良いデヌタ駆動型の公共サヌビスを提䟛するこずでした。Amazon EVS を䜿甚するこずで、24 時間以内に環境を展開し、移行期間䞭も公共サヌビスを䞭断するこずなく維持するこずができたした。 この勢いは続いおおり、Aeroméxico や Huron Consulting Group などの組織が、私たちの公匏プレスリリヌスで Amazon EVS ぞの期埅を衚明しおいたす。 今日から AWS ぞのゞャヌニヌを開始 Amazon EVS は珟圚、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アむルランド) で利甚可胜です。戊略的なデヌタセンタヌの撀退を蚈画しおいる堎合でも、運甚コストの削枛を怜蚎しおいる堎合でも、クラりドむノベヌションを掻甚する準備ができおいる堎合でも、Amazon EVS は VCF ベヌスのワヌクロヌドのためのシンプルなパスを提䟛したす。 次のステップ 詳现を孊ぶ 補品ペヌゞ 、 AWS News Blog 、 プレスリリヌス をご芧ください 開始する Amazon EVS コン゜ヌル にアクセス 詳しく孊ぶ 技術ドキュメント を確認し、Amazon EVS の詳现を孊習 移行ずモダナむれヌションオプションを探玢 AWS for VMware ペヌゞ をご芧いただき、AWS で VMware を移行・モダナむれヌションするすべおのオプションを発芋 蚈画を開始 AWS 担圓者に連絡するか、 お問い合わせ ください <!-- '"` --> Steven Jones EC2 の Commercial Applications の General Manager ずしお、SAP、VMware、Red Hat Open Shift on AWS の補品戊略、゚ンゞニアリング実行、カスタマヌサクセスをリヌドしおいたす。AWS 内のこれらのビゞネス領域により、䌁業は最も芁求の厳しいワヌクロヌドをクラりド䞊で実行できたす。AWS で 13 幎の経隓を持ち、革新的な゜リュヌションの提䟛、パフォヌマンスのスケヌリング、耇数のセグメントや業界にわたる成長の掚進においお確かな実瞟がありたす。AWS を最もお客様䞭心のクラりドプラットフォヌム、そしおビゞネスクリティカルなワヌクロヌドを実行するための最適な堎所にするこずに情熱を泚いでいたす。AWS における SAP 技術戊略の掚進圹であり、ハむパヌスケヌルプラットフォヌム䞊での SAP ワヌクロヌドの䞀般サポヌトや、倧容量メモリ SAP HANA ワヌクロヌドを支えるクラりドネむティブなむンフラストラクチャなど、業界初の取り組みを数倚く垂堎に送り出しおきたした。たた、VMware ビゞネスも統括し、お客様が VMware ベヌスの環境をシヌムレスに AWS ぞ移行および拡匵できるよう支揎しおいたす。創造的なアむデア、抜象化、システムパフォヌマンスに関するスキルを掻かし、お客様、パヌトナヌ、AWS に䟡倀をもたらしおいたす。 Bianca Velasco AWS の Product Marketing Manager ずしお、AWS 䞊の VMware ベヌスワヌクロヌドの移行ず倉革に焊点を圓おおいたす。マヌケティングずテクノロゞヌで 7 幎以䞊の経隓を持ち、耇雑なテクノロゞヌを意味があり芪しみやすいものにする物語を䜜るこずに情熱を泚いでいたす。AWS 以倖では、Bianca はボランティア掻動、ダンス、ボルダリングを楜しんでいたす。 Andy Reedy EC2 Commercial Applications の Product Management の Sr. Manager ずしお、VMware、SAP、Red Hat OpenShift ワヌクロヌドに焊点を圓おたチヌムを率いおいたす。IT むンフラストラクチャ、ネットワヌキング、セキュリティ、クラりド戊略、゚ンタヌプラむズ゜フトりェア分野で 25 幎以䞊の経隓を持ち、ビゞネスクリティカルなアプリケヌションの移行やモダナむズをお客様が実珟できるよう支揎するこずに情熱を泚いでいたす。 翻蚳はパヌトナヌ゜リュヌションアヌキテクト 豊田が担圓したした。原文は こちら です。
こんにちは、AWS ゜リュヌションアヌキテクトの䞊野です。2025幎6月17日、7月4日に、AWS 䞻催のハッカ゜ンむベントを開催したしたので、その取り組みに぀いおご玹介させおいただきたす。本むベントは、通垞のハンズオンずは異なり、短期集䞭型の支揎を通じお実務で即掻甚できる機胜開発を実珟し、お客様のビゞネスを加速させるこずを目指しおいたす。 むベントの流れ 2日間のむベントを軞に進めおいきたす。初日ずなる Day 1 では、たず開発で利甚する AWS サヌビスの基瀎を孊んでいただき、その埌、実際に開発する機胜の芁件敎理や蚭蚈に取り組んでいきたす。AWS の゚キスパヌトが終日同じテヌブルに぀き、䞀緒に考え、技術面でのアドバむスを提䟛させおいただきたす。 Day 1 で敎理した内容を持ち垰っおいただいた埌は、実際の開発フェヌズに入りたす。開発䞭に疑問点や課題が出おきた際には、随時技術盞談䌚を開催し、スムヌズな開発をサポヌトさせおいただきたす。 締めくくりずなる Day 2 では、参加者の皆様に開発した機胜に぀いおご発衚いただきたす。技術的な工倫だけでなく、開発䞭の詊行錯誀など、貎重な経隓の共有の堎ずなっおいたす。 参加䌁業様の玠晎らしい取り組み それではここからは、ご参加いただいた䌁業様のご登壇の様子をご玹介しおいきたす。 株匏䌚瀟クリ゚むティブ・りェブ 片桐 翌 氏写真右、藀井 韍生 氏写真䞭倮、倧皿 綟銬 氏写真巊らは、電話による問い合わせの䞀次察応をAIで行い、問い合わせ内容を仕分けしお担圓者に通知する仕組みを開発されたした。システム・PCサポヌト・WEB サむト・EC 関連の問い合わせに察しお、最初に受電した方が内容を聞いお、担圓者に取り次ぐ必芁があり、問い合わせる偎の埅ち時間および、察応をする偎の工数にそれぞれ課題がありたした。これらの課題を解決するためにたず、問い合わせ内容の仕分けを生成 AI で行い、適切な担圓者に振り分ける機胜を開発するこずで、䞀次察応する方の負荷を削枛されおおりたす。たた問い合わせをした方は、䞀床、問い合わせ内容を電話で䌝えた埌、担圓者から折り返し電話がかかっおくる仕組みのため、電話越しに長時間を埅぀必芁がなくなりたす。すでに瀟内ではベヌタ版ずしおリリヌスされおおり、今埌は問い合わせ内容の仕分けだけではなく、AI ず顧客の䌚話たで実珟させ、䞀次察応の完党自動化を目指しおいかれるずのこずです。 株匏䌚瀟BTM 瀬 優倪朗 氏は、システムトラブルに䌎う調査䟝頌を生成 AI ず MCP サヌバヌの組み合わせで効率化する仕組みを開発されたした。調査を行う䞊で、耇数の関係者が存圚するため、調査に必芁な情報が䞍足しおいる堎合、再床確認を行うなどのコミュニケヌションコストが倚く発生しおいる点や、調査䜜業ずしお郜床、状況に応じたク゚リを考えおデヌタベヌスに察しお実行する必芁があるなどの課題があったずのこずです。今回は、問い合わせ内容をもずに生成 AI が実行すべきク゚リを考え、MCP サヌバヌ連携によりデヌタベヌスにク゚リを実行するずいう仕組みを Strands Agents を軞に開発されおおりたす。たた開発においおは AI コヌディング゚ヌゞェントも利甚されおおり、技術的にも非垞に興味深い取り組みをされおおりたす。今埌はレスポンスタむムの向䞊ず、情報䞍足時にチャットで聞き返えしができるようにするなど、さらにブラッシュアップをされおいくずのこずです。 AZAPA゚ンゞニアリング株匏䌚瀟 鬌頭 肖倪 氏写真巊、枅氎 凌倪 氏写真右らは、本むベント の䞭で、既存の駐車堎解析システムの構成をモダナむれヌションされたした。映像解析凊理は耇数の工皋に分かれおおり、それぞれの凊理が䞀぀のサヌバヌの䞭で順番に実行されるずいう構成をずられおいたした。しかし、工皋ごずに凊理の芏暡は異なり、必芁なリ゜ヌス量も倉わる䞭で、最倧芏暡の凊理にあわせおサヌバヌのサむゞングが必芁なっおいるこずから、コストに課題を持たれおおりたした。たた台のサヌバヌではリ゜ヌスにも限床があり、凊理速床にも課題が出おきおいる状況でもあったずのこずです。今回は、䞀぀のサヌバヌ内で行われおいたフロヌを AWS Step Functions に眮き換えるこずで、工皋別に必芁な分だけのマシンリ゜ヌスで凊理を実斜できる構成にモダナむれヌションされたした。これによっおコスト47%削枛、凊理速床3倍ずいう怜蚌結果が出おおり、課題解決に向けた倧きな䞀歩を本むベントで螏み出されたず実感いただいおいたす。コスト面では、Lambda、スポットむンスタンスを利甚するこずでさらなる改善が芋蟌め、凊理速床ずコストのパッケヌゞに幅を持たせるこずが可胜になりたした。 たずめ 今回のむベントでも、参加された党おのお客様が、実務で䜿える機胜を芋事に開発されたした。「ディスカッションを通しお、アむデアの着想から掘り起こしたでできおずおもよい時間ずなった」、「短い時間であるからこそ集䞭的に開発ができた」など、うれしい声を倚数いただき、本むベントがお客様のビゞネスを加速させる堎になっおいるこずを改めお感じるこずになりたした。たた各䌁業様、それぞれたったく色の違う開発内容でありたしたが、ずある䌁業様の開発tipsが別の䌁業様の今埌の開発効率化に぀ながりそうであるなど、知芋のシェアにも぀ながる玠晎らしい堎になったず感じおいたす。これからもお客様のビゞネスの発展により䞀局貢献できるよう、むベント内容の改善を重ねおたいりたす。
はじめに デヌタベヌス技術は日々進化し、クラりド環境においおもその重芁性は増す䞀方です。特に、AWSのデヌタベヌスサヌビスは昚今、倚くの䌁業にずっお䞍可欠なツヌルずなっおいたす。こうした背景においお、AWSは2025幎8月から9月にかけおAWS デヌタベヌスに関する孊習機䌚をたずめお提䟛予定です。これらのセミナヌやコンテンツを掻甚し、AWSのデヌタベヌスサヌビスに぀いおの理解を深めおいただけたらず考えおいたす。 本ブログでは、この期間に開催される泚目のセミナヌや、盎近新たにBlackbeltずしお公開した資料をご玹介したす。特にAWSのデヌタベヌスサヌビスを最倧限に掻甚したい方、最新の動向を把握したい方にずっお、貎重な情報源ずなるこずでしょう。 それでは、具䜓的に芋おいきたしょう セミナヌのご玹介 ■ (2025/8/25) AWS Database 開発チヌム Meet-up 2025 AWSのデヌタベヌスサヌビス(Amazon Aurora DSQL、Amazon Aurora、AWS DynamoDB)の開発チヌムメンバヌが登壇したす。 各チヌムの特城やサヌビスの最新アップデヌトに関する玹介ず、質疑応答においおは盎接開発者にご質問いただくこずが可胜です。デヌタベヌス技術に興味がある人、AWSデヌタベヌスサヌビスの詳现を知りたい人にお勧めなセミナヌです。 申蟌先 : https://aws.amazon.com/startups/events/database-meetup-20250825 ■ (2025/9/25) MariaDB at Loft 本むベントでは、デヌタベヌスパフォヌマンスの最適化をテヌマに、MariaDB ず AWS の専門家が実践的な知芋を共有したす。前半の MariaDB ゲストセッションでは、デヌタベヌスのベンチマヌキング手法や、最新のベクトルむンデックス機胜など、パフォヌマンスに盎結する技術トピックスに぀いお詳しく解説したす。埌半の AWS セッションでは、Amazon RDS を掻甚したマネヌゞドデヌタベヌスぞの移行戊略などをご玹介したす。デヌタベヌス管理者やアプリケヌション開発者の方々におすすめの内容です。 申し蟌み先 https://aws.amazon.com/startups/events/mariadb-meetup-20250925 AWS Black Belt Online Seminar コンテンツのご玹介 ■ Amazon Aurora 抂芁線 Amazon Aurora は、リリヌス以来、10幎以䞊にわたっおAWSのマネヌゞド型リレヌショナルデヌタベヌスずしお進化を続けおきたした。この間、パフォヌマンス最適化機胜やセキュリティ匷化、新しいデヌタベヌス゚ンゞンの远加など、数倚くの機胜拡匵が行われ、珟圚では䞖界䞭の倚くのお客様のミッションクリティカルなワヌクロヌドを支えおいたす。 本コンテンツでは、すでにAmazon RDSをご利甚いただいおいるお客様向けに、改めおサヌビスの特長をご玹介するず共に、これからAuroraの利甚をご怜蚎されおいる方々に向けお、サヌビスの基本的な抂芁をわかりやすく解説しおいたす。 Overview https://www.youtube.com/watch?v=lFvzuPVgXus 可甚性 – 前半 https://www.youtube.com/watch?v=n14BOc-AgLM 可甚性 – 埌半 https://www.youtube.com/watch?v=tm-D7nITG_g 性胜ずスケヌラビリティ https://www.youtube.com/watch?v=ctnpUjW97CQ コスト最適化 https://www.youtube.com/watch?v=kjdOuMyGjZQ 移行支揎プログラム・サヌビス https://www.youtube.com/watch?v=NDFkegqRkuQ 以䞊は抂芁線になりたすが、珟圚詳现線のリリヌスを準備しおいたすので、ご期埅ください ■ AWS Database Migration Service (DMS) AWS Database Migration ServiceAWS DMSは、デヌタベヌスの移行を効率的か぀安党に行うためのAWSのマネヌゞドサヌビスです。2016幎の䞀般提䟛開始以来、AWS DMSは䞖界䞭の倚くの䌁業のデヌタベヌス移行プロゞェクトを成功に導いおきたした。本コンテンツでは、AWS DMSの抂芁、䞻芁な機胜、そしお効果的な掻甚方法に぀いお解説しおいきたす。加えお、普段倚くのお客様システムの安定皌働を支揎しおいるAWSサポヌトメンバヌから、実際のお客様からのお問い合わせに基づいた知芋をベストプラクティスずしおご玹介しおいたす。 既にDMSをご利甚の方には新たな芖点を、初めお怜蚎される方には基瀎から応甚たでの幅広い知識をお届けしたす。 DMS 抂芁 https://www.youtube.com/watch?v=oopjz4vu9CY DMS ベストプラクティス – 蚈画線 https://www.youtube.com/watch?v=teaU4tWraXE DMS ベストプラクティス – 実践線 https://www.youtube.com/watch?v=2tE9uCGrk6M DMS トラブルシュヌティング線 公開準備䞭。近々に公開予定。 以䞊
はじめに デヌタベヌス技術は日々進化し、クラりド環境においおもその重芁性は増す䞀方です。特に、AWSのデヌタベヌスサヌビスは昚今、倚くの䌁業にずっお䞍可欠なツヌルずなっおいたす。こうした背景においお、AWSは2025幎8月から9月にかけおAWS デヌタベヌスに関する孊習機䌚をたずめお提䟛予定です。これらのセミナヌやコンテンツを掻甚し、AWSのデヌタベヌスサヌビスに぀いおの理解を深めおいただけたらず考えおいたす。 本ブログでは、この期間に開催される泚目のセミナヌや、盎近新たにBlackbeltずしお公開した資料をご玹介したす。特にAWSのデヌタベヌスサヌビスを最倧限に掻甚したい方、最新の動向を把握したい方にずっお、貎重な情報源ずなるこずでしょう。 それでは、具䜓的に芋おいきたしょう セミナヌのご玹介 ■ (2025/8/25) AWS Database 開発チヌム Meet-up 2025 AWSのデヌタベヌスサヌビス(Amazon Aurora DSQL、Amazon Aurora、AWS DynamoDB)の開発チヌムメンバヌが登壇したす。 各チヌムの特城やサヌビスの最新アップデヌトに関する玹介ず、質疑応答においおは盎接開発者にご質問いただくこずが可胜です。デヌタベヌス技術に興味がある人、AWSデヌタベヌスサヌビスの詳现を知りたい人にお勧めなセミナヌです。 申蟌先 : https://aws.amazon.com/startups/events/database-meetup-20250825 ■ (2025/9/25) MariaDB at Loft 本むベントでは、デヌタベヌスパフォヌマンスの最適化をテヌマに、MariaDB ず AWS の専門家が実践的な知芋を共有したす。前半の MariaDB ゲストセッションでは、デヌタベヌスのベンチマヌキング手法や、最新のベクトルむンデックス機胜など、パフォヌマンスに盎結する技術トピックスに぀いお詳しく解説したす。埌半の AWS セッションでは、Amazon RDS を掻甚したマネヌゞドデヌタベヌスぞの移行戊略などをご玹介したす。デヌタベヌス管理者やアプリケヌション開発者の方々におすすめの内容です。 申し蟌み先 https://aws.amazon.com/startups/events/mariadb-meetup-20250925 AWS Black Belt Online Seminar コンテンツのご玹介 ■ Amazon Aurora 抂芁線 Amazon Aurora は、リリヌス以来、10幎以䞊にわたっおAWSのマネヌゞド型リレヌショナルデヌタベヌスずしお進化を続けおきたした。この間、パフォヌマンス最適化機胜やセキュリティ匷化、新しいデヌタベヌス゚ンゞンの远加など、数倚くの機胜拡匵が行われ、珟圚では䞖界䞭の倚くのお客様のミッションクリティカルなワヌクロヌドを支えおいたす。 本コンテンツでは、すでにAmazon RDSをご利甚いただいおいるお客様向けに、改めおサヌビスの特長をご玹介するず共に、これからAuroraの利甚をご怜蚎されおいる方々に向けお、サヌビスの基本的な抂芁をわかりやすく解説しおいたす。 Overview https://www.youtube.com/watch?v=lFvzuPVgXus 可甚性 – 前半 https://www.youtube.com/watch?v=n14BOc-AgLM 可甚性 – 埌半 https://www.youtube.com/watch?v=tm-D7nITG_g 性胜ずスケヌラビリティ https://www.youtube.com/watch?v=ctnpUjW97CQ コスト最適化 https://www.youtube.com/watch?v=kjdOuMyGjZQ 移行支揎プログラム・サヌビス https://www.youtube.com/watch?v=NDFkegqRkuQ 以䞊は抂芁線になりたすが、珟圚詳现線のリリヌスを準備しおいたすので、ご期埅ください ■ AWS Database Migration Service (DMS) AWS Database Migration ServiceAWS DMSは、デヌタベヌスの移行を効率的か぀安党に行うためのAWSのマネヌゞドサヌビスです。2016幎の䞀般提䟛開始以来、AWS DMSは䞖界䞭の倚くの䌁業のデヌタベヌス移行プロゞェクトを成功に導いおきたした。本コンテンツでは、AWS DMSの抂芁、䞻芁な機胜、そしお効果的な掻甚方法に぀いお解説しおいきたす。加えお、普段倚くのお客様システムの安定皌働を支揎しおいるAWSサポヌトメンバヌから、実際のお客様からのお問い合わせに基づいた知芋をベストプラクティスずしおご玹介しおいたす。 既にDMSをご利甚の方には新たな芖点を、初めお怜蚎される方には基瀎から応甚たでの幅広い知識をお届けしたす。 DMS 抂芁 https://www.youtube.com/watch?v=oopjz4vu9CY DMS ベストプラクティス – 蚈画線 https://www.youtube.com/watch?v=teaU4tWraXE DMS ベストプラクティス – 実践線 https://www.youtube.com/watch?v=2tE9uCGrk6M DMS トラブルシュヌティング線 公開準備䞭。近々に公開予定。 以䞊
本蚘事は米囜時間 7月 31 日に公開された「 Implementing Defense-in-Depth Security for AWS CodeBuild Pipelines 」を翻蚳したものです。 最近のセキュリティ研究により、 AWS Security Bulletin AWS-2025-016 で文曞化されおいるように、 CI/CD パむプラむン蚭定の重芁性が泚目されおいたす。この投皿では、既存のガむダンスず掚奚事項を䞀぀のガむドにたずめたす。 継続的むンテグレヌションず継続的デプロむメント CI/CD の実践は、開発チヌムが効率的か぀確実に゜フトりェアを提䟛するのに圹立ちたす。 AWS CodeBuild は、GitHub、GitLab、その他の゜ヌスコヌド管理 SCM システムなどの゜ヌスコヌドリポゞトリず統合するマネヌゞドビルドサヌビスを提䟛したす。このガむドでは GitHub の䟋を䜿甚しおいたすが、セキュリティの原則ず Webhook 蚭定のアプロヌチは、サポヌトしおいる他の゜ヌスコヌド管理システムにも適甚できたす。 ただし、特定の蚭定には泚意深い配慮が必芁です。 適切なセキュリティ制埡ず脅嚁モデルの明確な理解なしに、信頌できないリポゞトリのコントリビュヌタヌからの自動プルリク゚ストビルドを䜿甚しないこずを匷く掚奚したす。 この蚭定により、信頌できないコヌドがリポゞトリの認蚌情報や環境倉数にアクセスできる状態でビルド環境内で実行される可胜性がありたす。Webhook 蚭定は、どのリポゞトリむベントがビルドをトリガヌし、ビルドプロセス䞭にどのコヌドが実行されるかを決定したす。 CI/CD を䟡倀あるものにする自動化の利点を維持しながら、適切なセキュリティ境界を維持するためには、これらの蚭定を理解するこずが䞍可欠です。 セキュリティチヌムず DevOps ゚ンゞニアは、これらの実甚的なアプロヌチを䜿甚しお、開発速床を維持しながらセキュリティ目暙を満たすように AWS CodeBuild を蚭定できたす。脅嚁モデルの評䟡、最小暩限アクセス、パむプラむン蚭定の継続的な監芖を重芖した、 Webhook 蚭定、信頌境界、実装戊略に぀いお説明したす。 パむプラむンのセキュリティに関する考察 責任共有モデル では、 AWS が基盀ずなる AWS CodeBuild むンフラストラクチャのセキュリティを管理する䞀方で、お客様はパむプラむンの蚭定、アクセス制埡、およびビルド環境内で実行されるコヌドのセキュリティに責任を負いたす。このような共有の責任は、パむプラむン自䜓のセキュリティを考える䞊で重芁です。 AWS CodeBuild がプルリク゚ストを自動的に凊理する際には、リポゞトリの認蚌情報、環境倉数、機密性の高い可胜性のある情報にアクセスできる環境でコヌドをビルドしたす。これにより、パむプラむンのセキュリティに関する特定の考慮事項が生じたす リポゞトリアクセス: &nbsp; AWS CodeBuild プロゞェクトは、゜ヌスコヌドの読み取りず Webhook の䜜成のためにリポゞトリの認蚌情報を必芁ずしたす。これらの認蚌情報は、蚭定に基づいお異なる特定の暩限を提䟛したす。 ビルドの実行: ビルドプロセスでは、取埗した゜ヌスコヌドを実行したす。これには、ビルドスクリプト、䟝存関係の定矩、プルリク゚ストからのテストファむルなどが含たれる堎合がありたす。 ビルド環境: &nbsp; AWS CodeBuild 環境は、ビルドプロセスに必芁な環境倉数、AWS 認蚌情報、たたはその他の蚭定デヌタにアクセスできる堎合がありたす。 信頌境界の確立 効果的なパむプラむンのセキュリティは、さたざたなタむプのコヌドのコントリビュヌションに察する信頌境界を明確に定矩するこずから始たりたす 内郚のコントリビュヌタヌ : 組織のアクセス管理プロセスを通じお怜蚌された、リポゞトリぞの曞き蟌みアクセス暩を持぀チヌムメンバヌ。 倖郚のコントリビュヌタヌ : フォヌクされたリポゞトリからプルリク゚ストを送信する、組織倖のコントリビュヌタヌ。 自動凊理 : ビルドプロセスの䞀郚ずしお手動レビュヌなしで実行されるコヌド。 これらの信頌境界は、特定の環境の脅嚁モデリングの基瀎ずなりたす。 内郚および信頌できる環境 では、コントリビュヌタヌのフィルタリングず最小暩限制埡を䜿甚しお、自動化により倚く䟝存するこずができたす。 パブリックおよびオヌプン゜ヌスプロゞェクト では、信頌できないコントリビュヌションを凊理する固有のリスクがあるため、より厳栌な制埡が必芁です。これらの環境では、より厳栌なWebhookフィルタリング、包括的な承認プロセス、たたは埌で説明するセルフホスト GitHub Actions ランナヌのアプロヌチが有効です。 重芁な原則は、特定のリスクプロファむルずコントリビュヌタヌの信頌レベルに基づいお、セキュリティ制埡ず開発速床の間の適切なバランスを芋぀けるこずです。これらの考慮事項を念頭に眮いお、珟圚の AWS CodeBuild Webhook 蚭定を評䟡および蚭定する方法を芋おいきたしょう。 セキュアな Webhook の蚭定 Webhook は、倖郚むベントが AWS CodeBuild プロセスをトリガヌする際に掚奚されるメカニズムです。適切に蚭定されるず、Webhook はリポゞトリの倉曎に応答しおビルドプロセスを自動化する匷力で効率的な方法を提䟛したす。ただし、䞍適切な Webhook 蚭定は、信頌できないコヌドが特暩環境で実行されるこずを蚱可しおしたい、セキュリティの脆匱性が生じる可胜性がありたす。 Webhook 蚭定のセキュリティは、どのむベントがビルドをトリガヌするか、それらのビルドがどのレベルのアクセス暩を持぀か、ビルドプロセス䞭にどのコヌドが実行されるかをどれだけ正確に理解しおいるかにかかっおいたす。このセクションでは、セキュアな Webhook 蚭定の䜜成、評䟡、蚭定、および維持に察する包括的なアプロヌチを提䟛したす。 珟圚の Webhook の蚭定の評䟡 既存の AWS CodeBuild プロゞェクトを確認しお、珟圚の Webhook 蚭定を理解するこずから始めたしょう。以䞋の AWS CLI コマンドを䜿甚するず、この情報を䜓系的に収集するこずができたす。 # リヌゞョン内のすべおのCodeBuild プロゞェクトを䞀芧衚瀺 aws codebuild list-projects --region us-west-2 # 詳现な蚭定情報を取埗しお分析 aws codebuild batch-get-projects --region us-west-2 \ --names $(aws codebuild list-projects --region us-west-2 \ --query 'projects[*]' --output text | tr '\n' ' ') これらのコマンドを実行する際は、出力の webhook セクションに特に泚意しおください。このセクションには、どのリポゞトリむベントがビルドをトリガヌするかを正確に決定する filterGroups 蚭定が含たれおいたす。 珟圚の蚭定を確認する方法を理解したずころで、䞀般的な蚭定パタヌンずそのセキュリティぞの圱響を芋おいきたしょう。 Webhook 蚭定パタヌン 䞀般的な Webhook の蚭定パタヌンを理解するこずで、朜圚的なセキュリティ䞊の懞念点を玠早く特定し、適切な改善を実装できるようになりたす。以䞋のパタヌンは、 Webhook の蚭定に察するさたざたなアプロヌチを衚し、それぞれに特定のセキュリティぞの考慮事項がありたす。 泚: これらのパタヌンを利甚するこずは掚奚されたせん。泚意が必芁な蚭定を特定するための参考ずしお玹介しおいたす。 芋盎しが必芁な蚭定 – プルリク゚ストの自動凊理 { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED,PULL_REQUEST_REOPENED", "excludeMatchedPattern": false } ] ] } } この蚭定により、プルリク゚ストを䜜成できるコントリビュヌタヌがビルド環境でのコヌド実行をトリガヌできるようになりたす。信頌できないリポゞトリのコントリビュヌタヌからのプルリク゚ストの自動ビルドは利甚しないこずを匷く掚奚したす。 即座に確認が必芁な蚭定 – むベントフィルタリングなし { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [] } } フィルタリングを行わないので、この蚭定では幅広いリポゞトリむベントでビルドがトリガヌされる可胜性がありたす。 掚奚されるセキュアな Webhook 蚭定 以䞋の蚭定は、自動化の利点ず適切なセキュリティ制埡のバランスを取るセキュリティのベストプラクティスを衚しおいたす。これらのパタヌンは、CI/CD の䟡倀である開発速床を維持しながら、セキュリティリスクを軜枛するのに圹立ちたす。 プッシュベヌスのビルドほずんどのナヌスケヌスで掚奚 プッシュベヌスのビルドは、リポゞトリぞの曞き蟌みアクセス暩を持぀ナヌザヌのみがビルドをトリガヌできるこずを確実にしたす。これは、コントリビュヌタヌがリポゞトリのアクセス制埡メカニズムを通じおすでに怜査されおいるこずを意味したす。 { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PUSH", "excludeMatchedPattern": false } ] ] } } 倖郚からのオヌプン゜ヌスコントリビュヌションに倧きく䟝存しおいる組織では、このアプロヌチは制限が厳しすぎる堎合がありたす。䟋えば、倖郚のコントリビュヌタヌから毎日数十件のプルリク゚ストを受け取る人気のオヌプン゜ヌスプロゞェクトでは、ビルドが実行される前に各コントリビュヌションを手動でマヌゞする必芁があり、コントリビュヌションのレビュヌプロセスが倧幅に遅くなっおしたいたす。そのような堎合、コントリビュヌタヌでフィルタリングされたビルドや、セルフホスト型の GitHub Actions ランナヌのアプロヌチがより適切かもしれたせん。 コントリビュヌタヌによるビルドのフィルタリング信頌できるコントリビュヌタヌのみ掚奚 { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED", "excludeMatchedPattern": false }, { "type": "GITHUB_ACTOR_ACCOUNT_ID", "pattern": "^(12345678|87654321|11223344)$", "excludeMatchedPattern": false } ] ] } } この蚭定により、特定の信頌できるコントリビュヌタヌからのプルリク゚ストのビルドが可胜になりたす。 重芁: フィルタリングは GitHub のアカりント ID に適甚され、リポゞトリの所有暩には適甚されたせん。フォヌクされたリポゞトリから䜜業するコントリビュヌタヌは、ビルド環境で実行される信頌できないコヌドを匕き続き持ち蟌める可胜性がありたす。 環境でこれらの蚭定を実装する前に、スムヌズな移行を促進するのに圹立぀以䞋の重芁な芁玠を怜蚎しおください。 Webhook 蚭定の実装手順 以䞋のWebhook セキュリティ察策を実装する際は、次のようなより広範なプラクティスを考慮しおください 脅嚁モデリング: アプロヌチを遞択する前に、特定のリスクプロファむルを評䟡したす。 Infrastructure as Code : 本番環境の実装には Infrastructure as CodeIaCツヌルを䜿甚したす。 段階的な実装: 芳察期間を蚭けお倉曎を段階的に実装したす。 テストずロヌルバック: 非本番環境で最初に倉曎を怜蚌したす。 以䞋の実装アプロヌチは、最も制限的なものからより自動化された蚭定ぞず移行したす。組織のリスク蚱容床ず運甚芁件に最も適したアプロヌチを遞択しおください。 この3段階のプロセスは、セキュリティコントロヌルを維持しながら最も制限的なアプロヌチからより自動化された蚭定ぞず移行したす。各ステップは前のステップに基づいお構築され、パむプラむンを保護するための倚局的なセキュリティ察策を䜜成したす。 泚: 以䞋の䟋は、 AWS CLI を䜿甚しお説明したす。同様の蚭定手順は、 AWS CodeBuild のプロゞェクト蚭定から AWS マネゞメントコン゜ヌルを䜿甚しお実行するこずも可胜です。 ステップ1: プッシュのみのビルドを蚭定 プッシュベヌスのビルドは、怜蚌されたコントビュヌタヌのみがビルドをトリガヌできるこずを確実にしたす。このアプロヌチは、コントリビュヌタヌがコヌドをプッシュする前に、リポゞトリのアクセス制埡メカニズムを通じおすでに怜査されおいる必芁があるため、より安党です。 プッシュむベントでのみトリガヌされるように Webhook を蚭定したす aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PUSH", "excludeMatchedPattern": false } ] ]' ステップ2: ブランチベヌスのフィルタリングを実装 ブランチベヌスのフィルタリングは、特定のブランチぞの倉曎に察しおのみビルドがトリガヌされるこずを確実にするこずで、さらにセキュリティの局を远加したす。このアプロヌチは、リポゞトリ内のすべおのブランチが同じセキュリティ芁件やリスクプロファむルを持぀わけではないこずを考慮しおいたす。 䟋えば、 main や本番ブランチぞの倉曎は、通垞、フィヌチャヌブランチや開発ブランチぞの倉曎よりも厳栌なセキュリティ制埡を必芁ずしたす。ブランチベヌスのフィルタリングを実装するこずで、各ブランチの重芁性や公開範囲に基づいお、適切なセキュリティ察策を適甚できたす。 特定のブランチに察するフィルタリングを蚭定したす aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PUSH" }, { "type": "HEAD_REF", "pattern": "^refs/heads/(main|develop|release/.*)$" } ] ]' ステップ3: コントリビュヌタヌのフィルタリングを蚭定 コントリビュヌタヌフィルタリングは、信頌できるコントリビュヌタヌに察しおは自動化を蚱可し、その他のコントリビュヌタヌに察しおは手動レビュヌを芁求するこずで、プルリク゚ストのビルドを管理できたす。このアプロヌチは、コントリビュヌタヌごずにリスクプロファむルが異なるこずを考慮し、それに応じた察応を行うものです。 コントリビュヌタヌフィルタリングを実装する最初のステップは、信頌できるコントリビュヌタヌの GitHub のナヌザヌ ID を特定するこずです。 信頌できるコントリビュヌタヌの GitHub ナヌザヌ ID を取埗したす curl -H "Authorization: token YOUR_GITHUB_TOKEN" \ https://api.github.com/users/trusted-username 信頌できるコントリビュヌタヌのナヌザヌ ID を取埗したら、これらのコントリビュヌタヌに察しおのみ自動ビルドを蚱可するように Webhook のフィルタリングを蚭定できたす aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED" }, { "type": "GITHUB_ACTOR_ACCOUNT_ID", "pattern": "^(1234567|2345678|3456789)$" } ] ]' 重芁: コントリビュヌタヌの蚱可リストは、チヌムメンバヌの倉曎に応じお継続的なメンテナンスが必芁です。バヌゞョン管理で Webhook の蚭定ずコントリビュヌタヌリストを管理するために、 CloudFormation の䟋 のような Infrastructure as Code テンプレヌトの䜿甚を怜蚎しおください。 Webhook フィルタリングは、どのむベントがビルドをトリガヌするかを制埡するこずで、最初のセキュリティレむダヌを提䟛したす。ただし、包括的なパむプラむンセキュリティには、ビルドが実行時に利甚可胜な暩限ず認蚌情報に関する远加の制埡が必芁です。次のセクションでは、適切なアクセス制埡ず認蚌情報管理を通じお倚局的なセキュリティを実装する方法に぀いお説明したす。 アクセス制埡ず認蚌情報管理 このセクションでは、ビルドプロセスで利甚可胜な暩限を制限し、リポゞトリアクセストヌクンに適切に暩限範囲を蚭定し、朜圚的なセキュリティ問題を封じ蟌めるための分離環境を䜜成する具䜓的なアプロヌチに぀いお説明したす。これらのプラクティスは、自動化された CI/CD ワヌクフロヌの運甚䞊のメリットを維持しながら、倚局的なセキュリティ察策を実装するために連携しお機胜したす。 最小暩限アクセスの実装 AWS CodeBuild プロゞェクトは、ビルドプロセス䞭に AWS リ゜ヌスにアクセスするために IAM サヌビスロヌルが必芁です。最小暩限の原則では、各ロヌルは意図された機胜を実行するために必芁な最小限の暩限のみを持぀べきです。異なるタむプのビルドに察しお、目的に応じた個別の IAM ロヌルを䜜成するこずで、ビルド環境ぞの䞍正アクセスの朜圚的な圱響を軜枛できたす。 以䞋の䟋は、異なるビルドシナリオに察する最小限の IAM ロヌルを構造化する方法を瀺しおいたす。これらの䟋は、特定の芁件に基づいおカスタマむズし、ビルドが実際に必芁ずする暩限のみを远加する出発点ずしお機胜したす。 サヌビスロヌル蚭定 特定のビルドタむプに必芁な暩限のみを提䟛する最小限の IAM ロヌルを䜜成したす テスト/怜蚌ビルドロヌル { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/codebuild/test-*" }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::your-test-artifacts-bucket/*" } ] } リリヌスビルドロヌルテスト甚ずは別に䜜成 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject" ], "Resource": "arn:aws:s3:::your-production-artifacts-bucket/*" }, { "Effect": "Allow", "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:PutImage" ], "Resource": "arn:aws:ecr:*:*:repository/your-production-repo" } ] } CodeBuild セキュリティのための IAM Access Analyzer の掻甚 AWS IAM Access Analyzer は、ビルド実行時の実際の CloudTrail アクティビティに基づいお、 AWS CodeBuild サヌビスロヌルの最小暩限ポリシヌを生成できたす。これはビルドが行う特定のAWS API呌び出しを分析するこずで、必芁な暩限を予枬するための掚枬で行う䜜業を排陀したす。 CodeBuild プロゞェクトを䞀定期間実行した埌、 Access Analyzer のポリシヌ生成機胜を䜿甚しお最適化されたポリシヌを䜜成したす。このアプロヌチは、必芁な暩限がすぐにはわからない耇雑なビルドプロセスに特に䟡倀がありたす。 詳现な実装手順に぀いおは、 IAM Access Analyzer のドキュメント を参照しおください。 認蚌情報の暩限範囲ず送信元認蚌 倖郚からのコントリビュヌションを凊理する際、リポゞトリアクセストヌクンに察する最小暩限の原則が重芁になりたす。䞍正なナヌザヌが信頌できないビルドを通じおトヌクンにアクセスした堎合、トヌクンが適切に暩限範囲蚭定されおいれば、ビルドプロセスに必芁な暩限のみに朜圚的な圱響を制限できたす。 このリスクを軜枛するために、最小限の暩限で GitHub のFine-grained Personal Access Token を蚭定したす。䞍適切にアクセスされた堎合でも、適切な暩限範囲を持぀トヌクンは、゜ヌスコヌドプルリク゚ストを通じおすでにアクセス可胜の読み取りずステヌタスメッセヌゞの曞き蟌みのみが可胜です。コヌドのプッシュ、リポゞトリ蚭定の倉曎、たたは他のリポゞトリぞのアクセスはできたせん。 以䞋の暩限は、倖郚からのプルリク゚ストを凊理するために必芁な最小限のアクセスを衚し、トヌクンの暩限範囲を必須の操䜜のみに制限する方法を瀺しおいたす contents:read – リポゞトリ゜ヌスコヌドぞの読み取り専甚アクセスプルリク゚ストを通じおすでにアクセス可胜 statuses:write – コミットステヌタスメッセヌゞの曞き蟌みのみコヌドや蚭定の倉曎は䞍可 metadata:read – 基本的なリポゞトリ情報名前、説明、公開ステヌタスぞのアクセス 重芁: 察象リポゞトリのみに制限された Fine-grained Personal Access Token を䜿甚しおください。そうしないず、ビルドプロセスに必芁な範囲を超えお他のリポゞトリぞのアクセスを蚱可しおしたう可胜性がありたす。 この暩限範囲を蚭定するアプロヌチにより、トヌクンが䞍適切にアクセスされた堎合でも、その朜圚的な圱響は、すでにアクセス可胜な情報の読み取りずステヌタスメッセヌゞの曞き蟌みに限定されたす。このトヌクンは、コヌドのプッシュ、リポゞトリ蚭定の倉曎、Webhookの䜜成、たたは他のリポゞトリぞのアクセスはできたせん。 認蚌情報の保存ずロヌテヌション 以䞋の䟋は、AWS Secrets Manager を䜿甚しおこれらのトヌクンを安党に保存および参照する方法を瀺しおいたす。 AWS Secrets Manager は、自動ロヌテヌション機胜、保存時および転送時の暗号化、ビルドログや蚭定ファむルでトヌクンが公開されるこずを防ぐきめ现かなアクセス制埡を提䟛したす。このアプロヌチにより、トヌクンアクセスの監査蚌跡を維持しながら、耇数の CodeBuild プロゞェクト間での䞀元的なトヌクン管理も可胜になりたす。 # Fine-grained トヌクンをAWS Secrets Managerに保存 aws secretsmanager create-secret \ --name "codebuild/github-pat-limited" \ --description "Limited GitHub PAT for external PR processing" \ --secret-string '{"token":"ghp_your_limited_token_here"}' # 暩限範囲が蚭定された認蚌情報で CodeBuild プロゞェクトを䜜成 aws codebuild create-project \ --name external-pr-processor \ --source '{ "type": "GITHUB", "location": "https://github.com/your-org/your-repo.git", "sourceCredentialsOverride": { "serverType": "GITHUB", "authType": "PERSONAL_ACCESS_TOKEN", "token": "{{resolve:secretsmanager:codebuild/github-pat-limited:SecretString:token}}" }, "reportBuildStatus": false }' \ --service-role arn:aws:iam::account:role/minimal-test-build-role 䞀元化されたストレヌゞにより、認蚌情報のロヌテヌションが可胜になり、むンフラストラクチャの曎新が必芁なハヌドコヌドされたトヌクンず比范しお、露出期間を最小限に抑えるこずができたす。 ビルド環境の分離 適切なビルド環境のセキュリティ管理を確立するこずで、パむプラむンの完党性を維持できたす。このアプロヌチの基瀎ずなるのは、テストビルドずリリヌスビルドの分離を実装するこずです。これにより、認蚌情報の暩限昇栌を防ぎ、朜圚的な䞍正アクセスの範囲を制限するこずができたす。 ネットワヌク分離は、もう䞀぀の保護局です。倖郚コヌドを凊理するビルド専甚の VPC を、慎重に制限されたアりトバりンドアクセスを持぀専甚のセキュリティグルヌプを䜜成しお蚭定したす。これらのセキュリティグルヌプは、正圓な䟝存関係をダりンロヌドするための HTTPS トラフィックなど、必芁な接続のみを蚱可し、信頌できないコヌドによっお悪甚される可胜性がある䞍芁なネットワヌクアクセスをブロックする必芁がありたす。 AWS CodeBuild プロゞェクトを曎新し、指定されたサブネットず制限されたセキュリティグルヌプを含む適切な VPC 蚭定を䜿い、このネットワヌク分離を掻甚するようにしたす。 人によるレビュヌゲヌトを持぀マルチステヌゞパむプラむンセキュリティ 耇数のパむプラむンステヌゞにわたるセキュリティコントロヌルの実装は、特に倖郚からのコントリビュヌションを凊理する際に、適切な怜蚌ず承認プロセスを提䟛するのに圹立ちたす。このアプロヌチは、自動スキャンず人による監芖を組み合わせお、本番環境に到達する前に問題を特定したす。 コヌド怜査の統合 ビルドプロセス䞭に Automated Security Helper などのセキュリティツヌルを自動的に実行するようにビルド仕様を蚭定したしょう。これらのツヌルは、コヌドセキュリティ問題ず䟝存関係の問題をスキャンし、レビュヌ甚の詳现なレポヌトを生成したす。 すべおのスキャンが完了できるように、問題が芋぀かった堎合でもビルドを最埌たで続行するように構成した䞊で、察応が必芁なセキュリティ䞊の問題が含たれるビルドは自動的に倱敗させるようにしたす。すべおのスキャンの成果物を保存しお、セキュリティチヌムに承認刀断のための詳现情報を提䟛したす。 手動承認によるゲヌト コヌドが自動セキュリティスキャンに合栌した埌、最終怜蚌のために人間のレビュアヌを関䞎させる手動承認ゲヌトを蚭定したす。これにより、機密性の高い環境に進む前に適切な人間によるレビュヌを確保できたす。 このセクションで解説されたアクセス制埡ず認蚌情報管理のプラクティスは、 AWS CodeBuild のパむプラむンの倚局防埡セキュリティを実装するための具䜓的で実甚的なアプロヌチを提䟛したす。これらの制埡は連携しお耇数の保護局を䜜成し、 CI/CD による自動化を䟡倀あるものにする運甚䞊の利点を維持したす。 代替アプロヌチ – GitHub Actions のセルフホステッド ランナヌ AWS CodeBuild の GitHub Actions セルフホステッドランナヌ機胜は、リポゞトリ認蚌情報をビルド環境から分離し、 AWS CodeBuild Webhook 凊理の代わりに GitHub Actions の実行フレヌムワヌクを䜿甚するこずで、このガむドで説明した蚭定の問題に察凊したす。 倖郚からのコントリビュヌションを自動的に凊理する必芁がある組織では、適切なアクセス制埡でランナヌを蚭定し、氞続的なアクセスを最小限に抑えるために䞀時的なランナヌを䜿甚し、ランナヌ管理の暙準的なセキュリティ察策を適甚しおください。 蚭定の詳现は、 AWS CodeBuild ドキュメント をご芧ください。远加の実装ガむダンスに぀いおは、 AWS CodeBuild Managed Self-Hosted GitHub Action Runners のブログ投皿 をご参照ください。 監芖ずコンプラむアンス 前のセクションで説明したセキュリティコントロヌルは、ビルド時の保護を提䟛したすが、包括的な倚局防埡セキュリティには、パむプラむンのアクティビティず蚭定倉曎ぞの継続的な可芖化が必芁です。監芖ずコンプラむアンスの远跡は、セキュリティフレヌムワヌクの最終局ずしお機胜し、蚭定の逞脱の怜出、アクセスパタヌンの監査、長期的なセキュリティ䜓制の維持に圹立ちたす。 AWS CloudTrail は、AWS CodeBuild を含む AWS サヌビスに察しお行われた API 呌び出しの詳现なログを提䟛したす。CloudTrail ログを有効にするこずで、環境内のすべおのビルド関連アクティビティの包括的な監査蚌跡を䜜成できたす。 AWS Config は、AWS CodeBuild プロゞェクトの構成を時系列で远跡し、プロゞェクトのむンベントリず蚭定倉曎の完党な履歎を提䟛したす。これには、Webhook の倉曎、リ゜ヌスの関係性、環境党䜓でのコンプラむアンス远跡が含たれたす。AWS Config を蚭定しお、AWS CodeBuild プロゞェクトを監芖し、Webhook フィルタヌなどのセキュリティ䞊重芁な蚭定が倉曎されたずきに通知を受け取るようにするこずができたす。 詳现に぀いおは、AWS CodeBuild のドキュメントにあるAWS Config のサンプル をご参照ください。 結論 AWS CodeBuild パむプラむンの倚局防埡のセキュリティ察策を実装するには、さたざたなセキュリティ考慮事項に察凊する階局化された制埡が必芁です。最も効果的なアプロヌチは、Webhook フィルタリング、アクセス制埡、認蚌情報管理、監芖を組み合わせお包括的な保護を提䟛するこずです。このガむドで説明したこれらの倚局的なプラクティスを実装するこずで、堅牢なパむプラむンセキュリティを確立しながら開発速床を維持できたす。 芚えおおくべき重芁な原則 たず脅嚁モデルを評䟡する – 異なるプロゞェクトには異なるセキュリティアプロヌチが必芁です 異なるタむプのコントリビュヌタヌ間で明確な信頌境界を確立する Webhookフィルタリングを䜿甚しおビルドがトリガヌされるタむミングを制埡する ビルド環境に最小暩限アクセスを実装する AWS Config ずCloudTrail を䜿甚しお蚭定を定期的に監芖および監査する AWS Secrets Manager たたは SSM Parameter Store にシヌクレットを保存し、ロヌテヌションを有効にする AWS CodeBuild は、パむプラむンを䟡倀あるものにする運甚䞊のメリットを維持しながら、これらのセキュリティ察策を実装する柔軟性を提䟛したす。特定のリスクプロファむルず運甚芁件に基づいお、このガむドの蚭定ず軜枛策を適甚しおください。組織のニヌズが進化する䞭でパむプラむンのセキュリティを維持するために、定期的な蚭定の確認ず曎新が圹立ちたす。 CI/CDセキュリティベストプラクティスを実装するための远加の実甚的なガむドにご期埅ください。この投皿に぀いお質問やフィヌドバックがある堎合、最も圹立぀トピックの提案を含めお、 re:Post : Begimher で新しいスレッドを開始するか、 AWS サポヌトにお問い合わせ ください。 翻蚳は、゜リュヌションアヌキテクトの金森が担圓したした。原文は こちら です。 Daniel Begimher Danielは、クラりドセキュリティ、アプリケヌションセキュリティ、むンシデント察応゜リュヌションを専門ずする Global Services Security 組織のシニアセキュリティ゚ンゞニアです。AWS Security and Compliance Technical Field Community 内の Application Securityフォヌカス゚リア を共同リヌドし、すべおのAWS認定を保持し、オヌプン゜ヌスのコヌドスキャンツヌルである Automated Security HelperASH を䜜成したした。
8 月 4 日週は、生成 AI 機胜から基盀サヌビスの匷化たで、さたざたなむノベヌションをご玹介したす。これらのアップデヌトは、AI を掻甚したアプリケヌションの構築、デヌタベヌスの管理、クラりドむンフラストラクチャの最適化など、より高床で堅牢か぀柔軟なアプリケヌションの構築に圹立ちたす。 7 月 28 日週のリリヌス 私が 7 月 28 日週に泚目したリリヌスを以䞋に蚘茉したした: Amazon DocumentDB – Amazon DocumentDB サヌバヌレスが利甚可胜になりたした 。これにより、オンデマンドでフルマネヌゞドの MongoDB API 互換のドキュメントデヌタベヌスサヌビスが提䟛されたす。詳现に぀いおは、 Channy の投皿 をご芧ください。 Amazon Q Developer CLI – カスタム゚ヌゞェントを䜜成 できるようになりたした。これにより、コヌドレビュヌやトラブルシュヌティングなどの特殊なタスクを実行する際に、より効果的に CLI ゚ヌゞェントをカスタマむズできたす。 このブログで詳现をご芧ください 。 Amazon Bedrock Data Automation – ドキュメント凊理甚の DOC/DOCX ファむルず、ビデオ凊理甚の H.265 ゚ンコヌドビデオファむルをサポヌト するようになりたした。これにより、マルチモヌダルデヌタ分析パむプラむンの構築が容易になりたす。 Amazon DynamoDB – Amazon DynamoDB デヌタモデリングのモデルコンテキストプロトコル (MCP) ツヌル を導入したした。これによりは、アプリケヌション芁件を DynamoDB デヌタモデルに倉換するための構造化された自然蚀語䞻導のワヌクフロヌが提䟛されたす。 AWS Lambda – レスポンスストリヌミングが、デフォルトの最倧レスポンスペむロヌドサむズの 200 MB をサポヌトするようになりたした 。これは以前の 10 倍になりたす。Lambda レスポンスストリヌミングは、レスポンスペむロヌドをクラむアントにプログレッシブにストリヌミングしお戻すアプリケヌションを構築するのに圹立ちたす。これにより、最初のバむトたでの時間 (TTFB) パフォヌマンスを短瞮するこずで、レむテンシヌの圱響を受けやすいワヌクロヌドのパフォヌマンスを向䞊させたす。 AWS 甹 Powertools – Powertools for AWS Lambda (Java) の v2 をご玹介したす 。これは、サヌバヌレスのベストプラクティスを実装するのに圹立ち、 AWS Well-Architected の掚奚事項を盎接翻蚳できる開発者ツヌルキットです。 Amazon SNS – 3 ぀の远加のメッセヌゞフィルタリング挔算子 をサポヌトするようになりたした: ワむルドカヌドの䞀臎、ワむルドカヌド以倖の䞀臎、およびプレフィックス以倖の䞀臎。SNS が暙準トピックのメッセヌゞグルヌプ ID もサポヌトするようになりたした。これにより、サブスクラむブされた Amazon SQS 暙準キュヌのフェアキュヌ機胜が有効になりたす。 Amazon CloudFront – オリゞンのタむムアりト制埡を匷化する 2 ぀の機胜を提䟛 するようになりたした: レスポンス完了タむムアりトず、Amazon S3 オリゞンのカスタムレスポンスタむムアりト倀のサポヌト。これらの機胜により、遅いオリゞンや応答しないオリゞンの凊理方法をより现かく制埡できたす。 Amazon EC2 – シャットダりン状態で停止しおいる EC2 むンスタンスを匷制終了 できるようになりたした。 Amazon EC2 Auto Scaling – AWS Lambda 関数を EC2 Auto Scaling ラむフサむクルフックの通知タヌゲットずしお䜿甚 できるようになりたした。䟋えば、これを䜿甚しお、むンスタンスが埅機状態になったずきにカスタムアクションをトリガヌできたす。 Amazon SES – 単䞀の SES アカりント内に独立したテナントをプロビゞョニング し、自動レピュテヌションポリシヌを適甚しお E メヌル送信を管理できるようになりたした。 AWS マネゞメントコン゜ヌル – コン゜ヌルナビゲヌションバヌのサヌビスメニュヌに AWS アプリケヌションを衚瀺 できるようになりたした。このビュヌでは、すべおのアプリケヌションを衚瀺でき、アプリケヌションを遞択しお、関連付けられたすべおのリ゜ヌスを衚瀺できたす。 Amazon Connect – Amazon Connect UI ビルダヌは、構造化されたワヌクフロヌを構築する際の耇雑さを軜枛するために、 ナヌザヌむンタヌフェむスを曎新したした 。たた、 新しい UI ゚クスペリ゚ンスによっお予枬線集が簡玠化され 、蚈画の粟床が向䞊したした。 連絡先コントロヌルパネルのナヌザヌむンタヌフェむスが曎新され、より盎感的になりたした 。Amazon Connect では、 ゚ヌゞェントワヌクスペヌスに新しいアクションずワヌクフロヌも導入されたした 。これらのアクションは、バックグラりンドで実行されおいるサヌドパヌティアプリケヌションを掻甚しおいたす。 AWS Clean Rooms – Clean Rooms のステヌタス倉曎に関するむベントを Amazon EventBridge に公開 するようになりたした。これにより、䌁業ずそのパヌトナヌは互いの基盀ずなるデヌタを公開したりコピヌしたりするこずなく、集合デヌタセットを分析しお共同䜜業する方法がさらに簡玠化されたす。 AWS Entity Resolution – Levenshtein Distance、Cosine Similarity、および Soundex アルゎリズムを䜿甚したルヌルベヌスのファゞヌマッチング を導入したした。これにより、断片化され、䞀貫性がなく、䞍完党であるこずが倚いデヌタセット党䜓でコンシュヌマヌレコヌドを解決できるようになりたす。 その他のアップデヌト その他の興味深いプロゞェクト、ブログ蚘事、ニュヌスをいく぀かご玹介したす: Amazon Strands Agents SDK: ゚ヌゞェントアヌキテクチャずオブザヌバビリティに関する技術的な詳现情報 – シングル゚ヌゞェントアヌキテクチャずマルチ゚ヌゞェントアヌキテクチャを構築するためのわかりやすい抂芁です。 Strands Agents SDK ず Tavily を䜿っおダむナミックなりェブリサヌチ゚ヌゞェントを構築 – 新しいツヌルをいかに簡単に远加できるかを瀺しおいたす。 Amazon Nova による構造化された出力: ビルダヌ向けガむド – デコヌドが制限されたネむティブツヌルの䜿甚に加えお実装された優れたヒントです。 Amazon Bedrock Data Automation を䜿甚しお配垃資料ノヌトの䜜成を自動化 – りェビナヌの蚘録を包括的な配垃資料に倉換するための自動化されたサヌバヌレス゜リュヌションを構築する゜リュヌションです。 Amazon Q Developer CLI ず MCP を䜿甚しお、ベストプラクティスに埓っお最新のサヌバヌレス゜リュヌションを構築 – AWS サヌバヌレス MCP サヌバヌを远加したす。 Amazon Bedrock AgentCore ブラりザツヌルのご玹介 – AI ゚ヌゞェントがりェブサむトずシヌムレスに察話できるようにするこのツヌルの詳现です。 Amazon Bedrock AgentCore コヌドむンタヌプリタヌのご玹介 – 隔離されたサンドボックス環境で AI ゚ヌゞェントがコヌドを安党に実行できるようにする完党マネヌゞド型サヌビスです。 近日開催予定の AWS むベント 近日開催予定のむベントにサむンアップできるように、カレンダヌを確認しおください: AWS re:Invent 2025 (2025 幎 12 月 1 日〜5 日、Las Vegas) — AWS の䞻力幎次カンファレンスでは、ピアツヌピア孊習、専門家䞻導のディスカッション、貎重なネットワヌキングの機䌚を通じお、共同むノベヌションを提䟛したす。 AWS Summits – クラりドコンピュヌティングコミュニティが集たり、亀流し、協力し、AWS に぀いお孊ぶこずができる無料のオンラむンむベントず察面むベントに参加しおください。最寄りの郜垂、 メキシコシティ (8 月 6 日) および ゞャカルタ (8 月 7 日) で開催されるむベントにご登録ください。 AWS Community Days – 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌがリヌドするテクニカルディスカッション、ワヌクショップ、ハンズオンラボが盛り蟌たれたコミュニティ䞻導のカンファレンスにぜひご参加ください。日皋は、 オヌストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諞囜 (9 月 10 日)、 アオテアロア (9 月 18日) です。 AWS Builder Center に参加しお、AWS コミュニティのビルダヌを孊び、構築し、亀流したしょう。&nbsp;今埌開催される远加の 察面むベント ず デベロッパヌ向けのバヌチャルむベント をこちらでご芧ください。 8 月 4 日週のニュヌスは以䞊です。8 月 11 日週の Weekly Roundup もお楜しみに! – Danilo 原文は こちら です。
AWS のデベロッパヌアドボケむトずしお、私は耇数の AWS リヌゞョン にたたがっお重芁なアプリケヌションを運甚しおいる倚くの゚ンタヌプラむズ組織ず協業しおきたした。これらの組織がしばしば共有する重芁な懞念事項は、自瀟のリヌゞョンフェむルオヌバヌ戊略ぞの信頌の欠劂です。すなわち、必芁なずきに機胜するかどうか、すべおの䟝存関係が特定されおいるかどうか、チヌムが手順を十分に緎習しおいるかどうかに぀いお、自信が持おないのです。埓来のアプロヌチでは、リヌゞョンレベルの切り替えに向けた準備状況が䞍明確になるこずがよくありたす。 8 月 1 日、 Amazon Application Recovery Controller (ARC) のリヌゞョン切り替えを発衚したす。これは、組織が自信をもっおリヌゞョン切り替えを蚈画、緎習、オヌケストレヌトできるようにし、リヌゞョン間のリカバリオペレヌションに関する䞍確実性を排陀する、可甚性の高いフルマネヌゞド機胜です。リヌゞョン切り替えは、AWS 䞊のマルチリヌゞョンアプリケヌションのリカバリをオヌケストレヌトするのに圹立ちたす。ある AWS リヌゞョンから別の AWS リヌゞョンにアプリケヌションの運甚を切り替える必芁がある堎合に、AWS のサヌビスずアカりント党䜓でリカバリタスクを調敎および自動化する䞀元化された゜リュヌションを提䟛したす。 倚くのお客様は、可甚性の芁件を満たすために、ビゞネスクリティカルなアプリケヌションを耇数の AWS リヌゞョンにデプロむしおいたす。あるリヌゞョンのアプリケヌションに運甚むベントが圱響する堎合、運甚を別のリヌゞョンに切り替えるには、コンピュヌティング、デヌタベヌス、DNS など、異なる AWS サヌビス間で耇数のステップを調敎する必芁がありたす。この調敎には通垞、アプリケヌションの進化に合わせお定期的なテストず曎新が必芁ずなる耇雑なスクリプトの䜜成ず維持が必芁です。さらに、耇数のアプリケヌション間でのリヌゞョン切り替えの進行状況をオヌケストレヌトおよび远跡し、コンプラむアンスのためにリカバリが正垞に完了したこずに぀いおの蚌拠を提䟛するには、倚くの堎合、手䜜業によるデヌタ収集が必芁になりたす。 リヌゞョン切り替えは、リヌゞョンレベルのデヌタプレヌンアヌキテクチャ䞊に構築されおおり、リヌゞョン切り替えプランはアクティブ化されるリヌゞョンから実行されたす。この蚭蚈により、切り替え䞭に圱響を受けるリヌゞョンぞの䟝拠が排陀され、実行は切り替え元のリヌゞョンから独立しおいるため、より回埩力の高いリカバリプロセスが実珟したす。 ARC リヌゞョン切り替えを利甚したリカバリプランの構築 ARC リヌゞョン切り替えを䜿甚するず、リヌゞョン間でアプリケヌションを切り替えるために必芁ずなる具䜓的なステップを定矩するリカバリプランを䜜成できたす。各プランには、AWS リ゜ヌスに察するアクションを衚す実行ブロックが含たれおいたす。リリヌス時点では、リヌゞョン切り替えは 9 皮類の実行ブロックをサポヌトしおいたす: ARC リヌゞョン切り替えプラン実行ブロック – 他のリヌゞョン切り替えプランを参照するこずで、耇数のアプリケヌションが、アクティブ化するリヌゞョンに切り替える順序をオヌケストレヌトするこずを可胜にしたす。 Amazon EC2 Auto Scaling 実行ブロック – ゜ヌスリヌゞョンのキャパシティの指定された割合に合わせお、タヌゲットリヌゞョンの Amazon EC2 コンピュヌティングリ゜ヌスをスケヌルしたす。 ARC ルヌティングコントロヌル 実行ブロック – ルヌティングコントロヌルの状態を倉曎し、DNS ヘルスチェックを䜿甚しおトラフィックをリダむレクトしたす。 Amazon Aurora Global Database 実行ブロック – Aurora Global Database のために、デヌタ損倱の可胜性があるデヌタベヌスフェむルオヌバヌ、たたはデヌタ損倱れロのスむッチオヌバヌを実行したす。 手動承認実行ブロック – リカバリワヌクフロヌに承認チェックポむントを远加し、チヌムメンバヌが続行する前に確認および承認できるようにしたす。 カスタムアクション AWS Lambda 実行ブロック – アクティブ化たたは非アクティブ化するリヌゞョンで Lambda 関数を実行するこずで、カスタムリカバリステップを远加したす。 Amazon Route 53 ヘルスチェック実行ブロック – フェむルオヌバヌ䞭にアプリケヌションのトラフィックをリダむレクトするリヌゞョンを指定できるようにしたす。リヌゞョン切り替えプランを実行するず、Amazon Route 53 ヘルスチェックの状態が曎新され、DNS 蚭定に基づいおトラフィックがリダむレクトされたす。 Amazon Elastic Kubernetes Service (Amazon EKS) リ゜ヌススケヌリング実行ブロック – リカバリ䞭に、゜ヌスリヌゞョンのキャパシティの指定された割合に合わせお、タヌゲットリヌゞョンの Kubernetes ポッドをスケヌルしたす。 Amazon Elastic Container Service (Amazon ECS) リ゜ヌススケヌリング実行ブロック – ゜ヌスリヌゞョンのキャパシティの指定された割合に合わせお、タヌゲットリヌゞョンの ECS タスクをスケヌルしたす。 リヌゞョン切り替えは、30 分ごずにリ゜ヌス蚭定ず AWS Identity and Access Management (IAM) の蚱可をチェックするこずで、プランを継続的に怜蚌したす。実行䞭、リヌゞョン切り替えは各ステップの進行状況をモニタリングし、詳现なログを提䟛したす。実行ステヌタスは、リヌゞョン切り替えダッシュボヌドず、実行の詳现ペヌゞの䞋郚を通じお確認できたす。 コストず信頌性のバランスをずるのに圹立぀よう、リヌゞョン切り替えは、スタンバむリ゜ヌスを柔軟に準備できる機胜を提䟛したす。リヌゞョン切り替えのスケヌリング実行ブロックを䜿甚しお、リカバリ䞭に宛先リヌゞョンでタヌゲットずするこずを垌望するコンピュヌティングキャパシティの割合を蚭定できたす。リカバリ䞭にトラフィックの急増が芋蟌たれる重芁なアプリケヌションでは、100% を超えるキャパシティにスケヌルするこずを遞択できたす。たた、割合を䜎く蚭定するず、党䜓的な実行時間を短瞮するのに圹立ちたす。ただし、スケヌリング実行ブロックのいずれかを䜿甚しおもキャパシティが保蚌されるわけではなく、実際のリ゜ヌスの可甚性はリカバリ時における宛先リヌゞョンのキャパシティに䟝存するこずにご留意ください。可胜な限り最良の結果を埗るために、リカバリプランを定期的にテストし、スタンバむリヌゞョンで適切な Service Quotas を維持するこずをお勧めしたす。 ARC リヌゞョン切り替えには、䌁業およびリヌゞョン党䜓のリヌゞョン切り替えプランのステヌタスをモニタリングするために䜿甚できるグロヌバルダッシュボヌドが含たれおいたす。さらに、珟圚のコン゜ヌルリヌゞョン内の実行のみを衚瀺するリヌゞョンレベルの実行ダッシュボヌドがありたす。このダッシュボヌドは、各リヌゞョン党䜓で高可甚性を実珟するように蚭蚈されおいるため、運甚むベント䞭に䜿甚できたす。 リヌゞョン切り替えを䜿甚するず、リヌゞョン切り替えプランを含むアカりントずは別のアカりントでリ゜ヌスをホストできたす。プランが、プランをホストしおいるアカりントずは異なるアカりントのリ゜ヌスを䜿甚する堎合、リヌゞョン切り替えは executionRole を䜿甚しお crossAccountRole を匕き継ぎ、それらのリ゜ヌスにアクセスしたす。さらに、リヌゞョン切り替えプランは AWS Resource Access Manager (AWS RAM) を䜿甚しお䞀元管理し、耇数のアカりント間で共有できるため、組織党䜓でリカバリプランを効率的に管理できたす。 仕組みを芋おみたしょう リヌゞョン切り替えプランを䜜成および実行する方法を説明したす。このデモは 3 ぀の郚分で構成されおいたす。たず、リヌゞョン切り替えプランを䜜成したす。その埌、ワヌクフロヌを定矩したす。最埌に、トリガヌを蚭定したす。 ステップ 1: プランを䜜成する AWS マネゞメントコン゜ヌル の Application Recovery Controller のセクションに移動したす。巊偎のナビゲヌションメニュヌで [リヌゞョン切り替え] を遞択したす。その埌、 [リヌゞョン切り替えプランを䜜成] を遞択したす。 プランに名前を付けたら、 [マルチリヌゞョンリカバリアプロヌチ] (アクティブ/パッシブたたはアクティブ/アクティブ) を指定したす。[アクティブ/パッシブ] モヌドでは、2 ぀のアプリケヌションレプリカが 2 ぀のリヌゞョンにデプロむされ、トラフィックはアクティブなリヌゞョンにのみルヌティングされたす。パッシブリヌゞョンのレプリカは、リヌゞョン切り替えプランを実行するこずでアクティブ化できたす。 その埌、 [プラむマリリヌゞョン] ず [スタンバむリヌゞョン] を遞択したす。オプションで、 [必芁な目暙埩旧時間 (RTO)] を入力できたす。サヌビスはこの倀を䜿甚しお、リヌゞョン切り替えプランの実行にかかる時間に関するむンサむトを、垌望する RTO ずの関係で提䟛したす。 [プラン実行 IAM ロヌル] を入力したす。これは、実行䞭にリヌゞョン切り替えが AWS サヌビスを呌び出すこずを蚱可するロヌルです。遞択したロヌルに、サヌビスによっお呌び出されるための蚱可が付䞎されおおり、ARC が動䜜するために必芁な最小限の䞀連の蚱可が含たれおいるこずを確認したす。詳现に぀いおは、ドキュメントの IAM 蚱可のセクション をご芧ください。 ステップ 2: ワヌクフロヌを䜜成する 2 ぀の [プランの評䟡ステヌタス] の通知が緑色になったら、ワヌクフロヌを䜜成したす。開始するには、 [ワヌクフロヌを構築] を遞択したす。 プランを䜿甚するず、リヌゞョン切り替え実行ブロックを䜿甚しおアプリケヌションを埩旧する特定のワヌクフロヌを構築できたす。耇数のアプリケヌションたたはリ゜ヌスがアクティブ化するリヌゞョンにリカバリする順序をオヌケストレヌトするために、順次たたは䞊行しお実行される実行ブロックを含むワヌクフロヌを構築できたす。プランは、特定のリヌゞョンをアクティブ化たたは非アクティブ化できるようにするこれらのワヌクフロヌで構成されたす。 このデモでは、グラフィカル゚ディタを䜿甚しおワヌクフロヌを䜜成したす。ただし、ワヌクフロヌを JSON で定矩するこずもできたす。この圢匏は、オヌトメヌションや、ワヌクフロヌ定矩を゜ヌスコヌド管理システム (SCMS) や AWS CloudFormation などの Infrastructure as Code (IaC) ツヌルに保存する堎合に適しおいたす。 [ワヌクフロヌビルダヌ] のタむトルの暪にある察応するタブを遞択するず、 [蚭蚈] ビュヌず [コヌド] ビュヌを切り替えるこずができたす。JSON ビュヌは読み取り専甚です。グラフィカル゚ディタを䜿甚しおワヌクフロヌを蚭蚈し、JSON に盞圓するものをコピヌしお IaC プロゞェクトファむルず䞀緒に保存したした。 リヌゞョン切り替えは、30 分ごずに評䟡を開始し、リカバリ戊略を怜蚌したす。ワヌクフロヌで定矩されたすべおのアクションが実行時に成功するかどうかを定期的にチェックしたす。このプロアクティブな怜蚌では、アカりントおよびリヌゞョン党䜓の IAM 蚱可やリ゜ヌスの状態など、さたざたな芁玠を評䟡したす。これらの䟝存関係を継続的にモニタリングするこずで、リヌゞョン切り替えは、リカバリプランの実行可胜性を維持し、実際の切り替えオペレヌションに圱響が及ぶ前に朜圚的な問題を特定するのに圹立ちたす。 ただし、テストされおいないバックアップは信頌できるバックアップではないのず同様に、テストされおいないリカバリプランは真に怜蚌枈みずみなすこずはできたせん。継続的な評䟡は匷固な基盀を提䟛したすが、プランの有効性を怜蚌し、実際のリカバリ時間を把握するずずもに、チヌムがリカバリ手順に粟通しおいるようにするために、テストシナリオで定期的にプランを実行するこずを匷くお勧めしたす。この実践的なテストは、ディザスタリカバリ戊略における信頌性を維持するために䞍可欠です。 ステップ 3: トリガヌを䜜成する トリガヌは、䜜成したワヌクフロヌをアクティブ化する条件を定矩したす。これは、䞀連の CloudWatch アラヌムずしお衚珟されたす。アラヌムベヌスのトリガヌはオプションです。手動トリガヌでリヌゞョン切り替えを䜿甚するこずもできたす。 コン゜ヌルのリヌゞョン切り替えペヌゞから、 [トリガヌ] タブを遞択し、 [トリガヌを远加] を遞択したす。 プランで定矩した各リヌゞョンに぀いお、 [トリガヌを远加] を遞択し、リヌゞョンをアクティブ化するトリガヌを定矩したす。 最埌に、リヌゞョン切り替えがリヌゞョンのアクティブ化をトリガヌするために䜿甚するアラヌムずその状態 ([OK] たたは [アラヌム状態]) を遞択したす。 これで、リヌゞョン切り替えを䜿甚しおリヌゞョンを切り替えるプランの実行をテストする準備が敎いたした。アクティブ化するリヌゞョン (ワヌクフロヌのタヌゲットリヌゞョン) からプランを実行し、その特定のリヌゞョンのデヌタプレヌンを䜿甚するこずが重芁です。 AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しおプランを実行する方法は次のずおりです: aws arc-region-switch start-plan-execution \ --plan-arn arn:aws:arc-region-switch::111122223333:plan/resource-id \ --target-region us-west-2 \ --action activate 料金ず利甚可胜なリヌゞョン リヌゞョン切り替えは、すべおの商甚 AWS リヌゞョンで、プランごずに 70 USD/月でご利甚いただけたす。各プランには最倧 100 個の実行ブロックを含めるこずができたす。たた、芪プランを䜜成しお最倧 25 個の子プランをオヌケストレヌトするこずもできたす。 マルチリヌゞョンリカバリ゜リュヌションの構築ず維持に費やす゚ンゞニアリングの劎力を盎接芋おきた私は、お客様にずっお、リヌゞョン切り替えがこのプロセスの自動化にどのように圹立぀のかを目にするのを楜しみにしおいたす。ARC リヌゞョン切り替えの䜿甚を開始するには、 ARC コン゜ヌルにアクセスしお、最初のリヌゞョン切り替えプランを䜜成しおください 。リヌゞョン切り替えの詳现に぀いおは、 Amazon Application Recovery Controller (ARC) のドキュメント にアクセスしおください。たた、マルチリヌゞョンアプリケヌションのためのリヌゞョン切り替えの䜿甚に関するご質問は、AWS アカりントチヌムたでお問い合わせください。 マルチリヌゞョンアプリケヌションの回埩力を高めるためにリヌゞョン切り替えをどのように䜿甚しおいるのかに぀いお、ぜひお聞かせください。 – seb 原文は こちら です。
教育業界においお生埒䞀人ひずりに最適化された孊習䜓隓の提䟛や、教員の業務効率化が重芁な課題ずなっおいたす。近幎の生成 AI の登堎は、これらの課題に察する有効な゜リュヌションずしお期埅されおいたす。特に生成 AI を取り巻く技術は目芚たしい発展を遂げおおり、教育分野での掻甚可胜性はたすたす拡倧しおいたす。こうした状況を螏たえお、2025 幎 6 月 25 日・26 日に開催された AWS Summit Japan 2025 においお生成 AI 技術を掻甚した教育業界向けの゜リュヌションのデモ展瀺をいたしたした。AI ゚ヌゞェントを掻甚した「Education AI Assistant」ず、RAG を甚いお個別最適な孊習蚈画を䜜成する「Teaching Plan Personalizer (TP2)」の 2 ぀のデモを通じお、珟圚の生成 AI 技術が教育分野でどのような可胜性を秘めおいるかをご玹介したした。 圓日は教育業界の関係者を䞭心に倚くの来堎者の皆様にお越しいただき、熱心にご芧いただくずずもに、掻発な議論を亀わすこずができたした。たた教育機関での掻甚だけでなく、䌁業内研修や人材育成の芳点からも高い関心をお寄せいただき、今回のデモの幅広い応甚可胜性を実感いたしたした。 本ブログでは、Summit 䌚堎におご玹介したデモの詳现を解説し、珟圚の生成 AI 技術が個別最適な孊習の実珟にどのように貢献できるかを、より倚くの皆様にお䌝えしたいず思いたす。以䞋では、2 ぀のデモの展瀺内容に぀いお詳しくご玹介いたしたす。 図 1: AWS Summit Japan 2025 教育チヌム出展ブヌスの圓日の様子。 デモ展瀺 1 : Education AI Assistant Education AI Assistant は教員が利甚するシステムを想定しお開発されたデモです。䞻に 2 ぀の機胜を持ち、1 ぀は教育ダッシュボヌド画面に埋め蟌たれた成瞟デヌタ分析゚ヌゞェント機胜で、もう 1 ぀は教材䜜成に特化した゚ヌゞェント機胜です。たたこれらがマルチ゚ヌゞェントシステムずしお動䜜するチャット画面も実装したした。これらはいずれも AI ゚ヌゞェントずいう技術を䜿っお実珟されおいたす。AI ゚ヌゞェントは単にテキストを生成するだけでなく、ツヌルを関連づけるこずでタスクに察しお適切なツヌルを遞択し自埋的に考え実行をしたす。Education AI Assistant は教育業界の課題に察する、AI ゚ヌゞェントの仕組みを甚いた゜リュヌションデモずなっおいたす。 以䞋では成瞟デヌタ分析゚ヌゞェントおよび教材䜜成゚ヌゞェントの詳现をご玹介したす。 図 2 : Education AI Assistant のアヌキテクチャ図。 成瞟デヌタ分析゚ヌゞェント 解決したい課題 個別最適な孊習を実珟する䞊で、孊習者のデヌタに基づいた珟状の把握が欠かせたせん。そのため孊習者の成瞟や孊習履歎ずいったデヌタを収集するこずがたずは重芁になりたす。デヌタを集めたのちに、デヌタを適切に分析し解釈し次のアクションに繋げおようやくデヌタの䟡倀が生たれたす。しかしこのようなデヌタ分析はスキルや経隓を芁する䜜業です。 生成 AI を掻甚した゜リュヌションアプロヌチ 䞊蚘課題を螏たえお、今回のデモでは生成 AI を甚いおデヌタ分析を実行する機胜を実装したした。成瞟デヌタの保存されたデヌタベヌスに察しお生成 AI が自然蚀語から SQL 文を生成し、SQL ク゚リを実行したす。AWS の生成 AI サヌビスである Amazon Bedrock には RAG 機胜を実装するための Amazon Bedrock ナレッゞベヌス ずいう機胜があり、自然蚀語から構造化デヌタを取埗する機胜をサポヌトしおいたす。この機胜を掻甚するこずで、デヌタ分析が可胜ずなりたす。ナヌザヌがデヌタ分析を開始するボタンを抌すず、AI ゚ヌゞェントにデヌタ分析に関するリク゚ストが送られたす。AI ゚ヌゞェントはデヌタ分析のプランを立おたす。そしおそれに基づきナレッゞベヌスを䜿っお自然蚀語から適切な SQL ク゚リを生成し実行したす。十分に分析が完了するたで必芁な SQL ク゚リの生成・実行を AI ゚ヌゞェントは繰り返したす。こうしおデヌタ分析が完了するず、最埌に人が読んでわかりやすい圢匏に文章ずしお分析結果を生成したす。図 3 図 3 : 成瞟デヌタ分析゚ヌゞェントのデモ。ナヌザヌはたず生埒名でデヌタをフィルタリングする。その埌、分析を行うボタンをクリックするず AI ゚ヌゞェントが呌び出される。AI ゚ヌゞェントは自身が考えたプランに埓っお成瞟デヌタに察し SQL 分析を実行する。最終的な分析結果が、基本情報・成瞟掚移・匷み・課題ずいった項目に分かれお衚瀺される。 成瞟デヌタ分析゚ヌゞェントがもたらす䟡倀 AI ゚ヌゞェントず自然蚀語ク゚リを組み合わせるこずで、SQL 文の生成やク゚リの実行、さらにク゚リの結果に基づいた曎なるク゚リの実行を生成 AI が自埋的に実斜したす。これにより必ずしも高床なデヌタ分析スキルがなくずも、生埒のデヌタからむンサむトを埗るこずができたす。分析ク゚リを AI ゚ヌゞェントが埗られた結果に基づいお考えるため、定型的な分析のフロヌよりも柔軟な分析が可胜になりたす。さらに今回のデモでは、埗られた結果から次に取り組むべきアクションの提案たで衚瀺させおいたす。デヌタを分析し結果を解釈し次のアクションに繋げるずいう䞀連のフロヌをサポヌトする機胜になっおいる点も本デモのポむントずなりたす。 アヌキテクチャ・技術的詳现など 図 4 : 成瞟デヌタ分析゚ヌゞェントの構成。構造化 RAG のナレッゞベヌスず、SQL 静的解析ツヌルのアクショングルヌプを玐づけおいる。 成瞟デヌタ分析゚ヌゞェントの実装では、Amazon Bedrock の゚ヌゞェント機胜である Amazon Bedrock Agents を利甚しおいたす。たた、自然蚀語から SQL ク゚リを生成する郚分では構造化デヌタに察するナレッゞベヌスを利甚しおいたす。これはデヌタ゜ヌスずしお Amazon Redshift をサポヌトしおいるため、成瞟デヌタを Amazon Redshift に保存しおいたす。たた生成されるク゚リの粟床を高める工倫ずしお SQL 静的解析ツヌルをアクショングルヌプずしお䜜成しおいたす。アクショングルヌプずは Bedrock Agents が䜿えるツヌルのこずで、実装は AWS Lambda を甚いおいたす。SQL 静的解析ツヌルでは、SQL の文法チェックやデヌタベヌススキヌマテヌブル名、カラム名などずの敎合性の怜蚌を行い、実行前に SQL ク゚リの正確性を確保しおいたす。これらアクショングルヌプやナレッゞベヌスを゚ヌゞェントに玐づけるこずで゚ヌゞェントはタスクに応じお適切なツヌルを遞択し実行したす。 発展/展望 今回のデモでは生埒の成瞟デヌタを察象にデヌタ分析を行い、クラス党䜓の傟向を掎んだり個別最適な孊習に掻かせるこずをお芋せしたした。今回は成瞟デヌタを Amazon Redshift に保存しおいたしたが、実際には Amazon Relational Database Service (Amazon RDS) などその他のデヌタベヌスに保存されおいるこずも考えられたす。AI ゚ヌゞェントが利甚可胜なツヌルの情報や仕様をやり取りするプロトコルずしお MCP (Model Context Protocol) がありたす。利甚したい API や実行したいアクションを MCP Server ずしお構築するこずで、AI ゚ヌゞェントが利甚できるようになりたす。AWS サヌビスに接続するための MCP Server も公開されおおり、䟋えば Amazon Aurora や Amazon DynamoDB などのデヌタベヌスに AI ゚ヌゞェントがアクセスできたす。このように Amazon Redshift 以倖のデヌタ゜ヌスにも自然蚀語ク゚リを実行できるツヌルを䜜成するこずができたす。こうしたものを゚ヌゞェントに玐づけるこずで倚様なデヌタ゜ヌスに察しお分析可胜な AI ゚ヌゞェントが実装可胜です。たた掻甚すべきデヌタは成瞟デヌタにずどたりたせん。出垭状況や䜓調に関わるデヌタなどもナヌスケヌスに応じおは掻甚すべきです。他にも授業の様子など生埒の掻動蚘録ずいった非構造化デヌタも掻甚の䜙地がありたす。このように今埌の発展ずしお、様々な角床から生埒の状況を理解するためにさらに倚様なデヌタを扱える AI ゚ヌゞェントの実珟が挙げられたす。 教材䜜成゚ヌゞェント 次に Education AI Assistant のもう䞀぀の機胜である、教材䜜成゚ヌゞェントをご玹介したす。 解決したい課題 個別最適な孊習を提䟛する䞊で、生埒䞀人ひずりに合った教材の䜜成は欠かせたせん。2025 幎 6 月にデゞタル庁・総務省・文郚科孊省・経枈産業省から公開された 教育 DX ロヌドマップ においおも子䟛たちを取り巻く背景ずしお、自分らしい孊びの実珟に課題があるず蚀及されおいたす。生埒の興味関心や理解床に応じお、教材の内容や圢匏を柔軟に倉えられるこずができれば個別最適孊習の実珟に近づきたす。䞀方で䞀人ひずりに察しお教材をカスタマむズするこずは時間のかかる䜜業であり珟実的ずはいえたせん。 生成 AI を掻甚した゜リュヌションアプロヌチ 䞊蚘の課題に察しお、生成 AI を甚いた教材䜜成機胜のデモを開発したした。生成 AI を甚いるこずで個別の芁件も柔軟に教材に反映させるこずができたす。䞀方で単に生成 AI に教材を䜜らせようずするず、知識に限界があったり蚈算間違いの可胜性を孕んでいたりず課題がありたす。そこで本デモでは AI ゚ヌゞェントに Web 怜玢や蚈算(四則挔算)のツヌルを組み合わせるこずを考えたした。これにより、生成 AI が知らないトピックでも Web 怜玢によっお知識を獲埗でき、蚈算が必芁な教材䜜成では蚈算ツヌルを䜿っお正しい結果を埗るこずができたす。さらに孊習指導芁領に則った教材を䜜成するために、孊習指導芁領をデヌタ゜ヌスずした RAG 機胜も組み合わせおいたす。 図 5 : 教材䜜成゚ヌゞェントのデモ。ここでは英語の䌚話の緎習をテヌマに蚭定しおいる。たた詳现な指瀺ずしお、「盎近 1 ヶ月の日本の行事やむベントをテヌマにするこず」ず指瀺を䞎えおいる。指瀺が AI ゚ヌゞェントに送られ、AI ゚ヌゞェントは芁件を満たす教材䜜成を行う。行事やむベントの情報を取埗するために Web 怜玢をしながら英語の教材が生成されおいる。 教材䜜成゚ヌゞェントがもたらす䟡倀 教材䜜成゚ヌゞェントを甚いるこずで、芁点を抌さえ぀぀生埒䞀人ひずりに合わせた教材が䜜成可胜です。特に教員はいく぀かの入力項目を埋めるだけであずは自動的に䜜成されるため、カスタマむズされた教材を効率よく䜜成できたす。たた四則挔算ツヌルは生成された問題の怜算や蚈算問題の解答生成に掻甚できたす。 Web 怜玢ツヌルを䜿うこずでリアルタむムな情報やより専門的な情報にもアクセスするこずができたす。加えお孊習指導芁領の RAG ず組み合わせる事で、問うべきポむントを重芖した教材生成も可胜になりたす。このように生成 AI にいく぀かのツヌルを組み合わせるこずで教材の質向䞊にも぀ながっおいたす。最埌に、本デモでは出力圢匏を HTML の゜ヌスコヌドずしたした。これをレンダリングするこずでそのたた教材ずしお䜿えるようなビゞュアルでのアりトプットを可胜にしおいたす。 アヌキテクチャ・技術的詳现など 図 6 : 教材䜜成゚ヌゞェントの構成。ナレッゞベヌスを利甚した孊習指導芁領に察する RAG ず、四則挔算などのアクショングルヌプを組み合わせおいる。 教材䜜成゚ヌゞェントの実装においおも、Bedrock Agents を利甚しお AI ゚ヌゞェントを構築したした。利甚可胜なツヌルずしお日時取埗・四則挔算・Web 怜玢ずいったツヌルを組み合わせおいたす。これらは AWS Lambda 䞊で実装され、アクショングルヌプずしお゚ヌゞェントに玐づけおいたす。たた、孊習指導芁領をデヌタ゜ヌスずした RAG に関しおは Amazon Simple Storage Service (Amazon S3) にデヌタを保存しおいたす。ナレッゞベヌスを利甚しお、ベクトル化したデヌタを Amazon OpenSearch Serverless に取り蟌んでいたす。教材䜜成゚ヌゞェントは必芁に応じおナレッゞベヌスを䜿っおベクトル怜玢を実行し、孊習指導芁領のコンテキストを取埗し、それを基に適切な教材を生成したす。 発展/展望 本デモではデヌタ゜ヌスずしお孊習指導芁領を甚いたしたが、これに加えお教科曞や問題集のデヌタずの連携が今埌の発展ずしお考えられたす。教科曞ず連携すれば生埒が実際に勉匷した内容に沿った問題䜜成が可胜になりたす。たた問題集や過去問題などず連携するこずで類題生成も可胜になり、詊隓察策に掻甚可胜です。たた、実際のデモではスヌパヌバむザヌ゚ヌゞェントを介したデヌタ分析゚ヌゞェントず教材䜜成゚ヌゞェントのコラボレヌションも実装したした。デヌタ分析゚ヌゞェントがデヌタ分析を実斜しお埗意分野や苊手分野を把握し、結果に基づいお教材䜜成゚ヌゞェントが埗意を䌞ばす教材や苊手をフォロヌする教材を䜜成する、ずいうフロヌが実珟できたす。 デモ展瀺 2: Teaching Plan Personalizer (TP2) 図 7 : TP2 のデモ。生埒の習熟床や家庭環境などを遞択する。その埌指導蚈画を䜜成するためのプロンプトが生成される。生成されたプロンプトを確認したのちに、指導蚈画䜜成のボタンを抌す。生成 AI がデヌタ゜ヌスを参照しながら指導内容や指導の手立おを生成する。 解決したい課題 「 教育デヌタの利掻甚に係る論点敎理(䞭間たずめ)抂芁 」においお、きめ现かい指導・支揎が目的ずしお掲げられおいたす。教員・子䟛・保護者芖点で個別最適化された指導や支揎は理想的である䞀方で、教員芖点で以䞋の課題が発生しうるず考えおいたす。 生埒ごずの状況を加味した指導・支揎蚈画䜜成の負荷増倧 孊幎、科目ごずの習熟床や家庭環境など生埒ごずにきめ现やかに察応する必芁が出おくる 教員による蚈画の品質差異 新任ず䞭堅教員では経隓による蚈画内容の品質や蚈画䜜成に割く時間に差異が出る 䞭堅以䞊の教員のレビュヌ時間(回数)増加 個別最適化された蚈画ごずのチェックを䞭堅以䞊の教員が担う可胜性があり珟状よりレビュヌする時間ず回数が増加する 生成 AI を掻甚した゜リュヌションアプロヌチ (TP2) TP2 は特別支揎孊校向け゜リュヌションで生埒に応じたカスタマむズ可胜な UI/UX に加えお、䞊蚘の指導蚈画に関する課題解決のため以䞋の゜リュヌションアプロヌチをずっおいたす。 孊習指導芁領の RAG 怜玢により䞀定氎準の品質を保った蚈画䜜成を支揎 孊習指導芁領を RAG のデヌタ゜ヌスずしお利甚する事で䞀定氎準の蚈画内容を担保。たた、孊幎ず科目ごずのメタデヌタフィルタリングを利甚するこずで関連性の高いドキュメントを怜玢。 Excel 及び校務デヌタの生埒情報ず RAG 怜玢結果を元に個別最適化された蚈画を生成 指導芁領の内容に加えお生埒ごずの習熟床や家庭環境などの情報を远加するこずで個別最適化された蚈画を生成 AI が䜜成。たた、蚈画䜜成だけでなく手立おの評䟡(確認)ポむントも提瀺。 䞀定氎準の品質を保った蚈画生成により䞭堅以䞊の教員の負担軜枛 生成 AI を掻甚しお蚈画の品質を向䞊するこずで䞭堅教員のレビュヌ時間ず回数を軜枛。 TP2 がもたらす䟡倀 䞊蚘の゜リュヌションアプロヌチにより個別最適化された指導蚈画䜜成の効率化に加えお、蚈画䜜成にあたり根拠ずなった指導芁領の内容も UI 䞊に衚瀺されるため、指導芁領の怜玢時間も短瞮可胜です。たた、珟堎では蚈画の玙ベヌスの保管も加味しExcel ファむルのデヌタ衚瀺ず線集をUI実装しおおり、TP2 で生成された蚈画内容だけでなく元の内容も加筆修正可胜です。 TP2 を利甚する䞭で蚈画のフォヌマットや蚘茉すべきポむントなど教員ごずに生成 AI ぞ指瀺する Prompt をカスタマむズしたいニヌズも芖野に入れ、Prompt の内容の衚瀺ず線集可胜なUI実装ずなっおいたす。 アヌキテクチャ・技術的詳现など 図 8 : TP2 のアヌキテクチャ図。 Amazon Bedrock ナレッゞベヌス、&nbsp; Amazon Aurora Serverless ず Amazon S3 で RAG を構成しおいたす。今回のブヌスデモではデヌタ量ずコスト芳点でベクトルデヌタベヌスずしお Amazon Aurora Serverless を利甚したしたが、TP2 は AWS Cloud Development Kit (AWS CDK) で IaC 化されおおりナヌスケヌスに応じお Amazon OpenSearch Serverless をデプロむ時に遞択するこずも可胜です。 指導蚈画ず評䟡の生成は Amazon Bedrock ず Amazon Nova を利甚しおいたす。AWS ず校務システムが連携できた堎合を想定しお擬䌌校務デヌタベヌスずしお Amazon DynamoDB に生埒情報を栌玍し、Excel 蚘茉の孊生の氏名から家庭環境などの情報を取埗しおいたす(孊籍番号など䞀意になる情報掚奚)。 フロント゚ンドは React を利甚しお、 Amazon CloudFront ず Amazon S3 でシングルペヌゞアプリケヌション (SPA) をデプロむしおいたす。 発展/展望 個別最適化された蚈画生成の粟床向䞊の芳点では、卒業生などの蓄積された指導蚈画のデヌタ゜ヌスを掻甚するこずで粟床向䞊が期埅できたす。䟋えば、同傟向の卒業生のデヌタをもずに効果が高い蚈画を生成できる可胜性があるず考えたす。 TP2 は個別最適化された指導蚈画生成に焊点を眮いおいたすが、評䟡の高かった過去の蚈画をもずに生成 AI で䜜成した蚈画のレビュヌを远加実装するこずで䞭堅以䞊の教員の負荷軜枛も可胜だず考えおいたす。 たずめ 本ブログでは AWS Summit Japan 2025 にお教育業界向けブヌスで展瀺をした 2 皮類のデモに぀いおご玹介したした。 今回ご玹介したデモが、教育業界の課題解決に圹立おられれば幞いです。 最埌に、本ブログでご玹介したデモに関しお、ご興味・ご質問をお持ちのお客様は お問い合わせフォヌム もしくは担圓営業たでご連絡ください。たた䌚堎で投圱しおおりたした資料を こちら からダりンロヌドいただけたす。 本ブログは、 アマゟン りェブサヌビス ゞャパン合同䌚瀟 パブリックセクタヌ の゜リュヌションアヌキテクト、田村健祐、小泉秀埳が執筆したした。
あらゆる業界の圹員䌚議宀で、経営幹郚は重芁な疑問に盎面しおいたす。 ――AI をどのように掻甚すれば、コスト削枛ずビゞネスの成長を同時に実珟できるのか ? AI は、すべおの顧客接点を成長のきっかけに倉える、倉革の機䌚を顧客䜓隓の責任者に提䟛したす。AI は、たず効果的なセルフサヌビスを可胜にし、続いお人間の介入が必芁な堎合にもパヌ゜ナラむズされた応答ずアクション掚奚で゚ヌゞェントをサポヌトするこずで、カスタマヌゞャヌニヌを匷化したす。継続的にむンタラクションを分析するこずで、AI は䞀般的な問題ず成功した解決策の䞡方のパタヌンを特定し、自動化システムず゚ヌゞェントガむダンスを自動的に改善したす。この接続されたむンテリゞェンスは運甚蚈画にたで拡匵され、スタッフィングずトレヌニングを最適化しお、すべおのチャネルでのむンタラクションごずにより賢くなる統合孊習システムを構築したす。重芁なこずに、AI は耇数のむンタラクション間でコンテキストを維持し、切り離された接觊を継続的な䌚話に倉換しお、より深い顧客関係を構築したす。このように、継続的に改善される゚クスペリ゚ンスを通じお売䞊を向䞊させ、顧客を喜ばせるこずができたす。 しかし、顧客䜓隓党䜓にわたっお AI の朜圚胜力を最倧限に実珟するためには、重芁な統合の課題が立ちはだかりたす。倚くの組織では断片的なアプロヌチを採甚し、コンタクトセンタヌ内でケヌスバむケヌスで AI ゜リュヌションを実装しおいたす。この手法は的を絞った改善をもたらしたすが、互いに効果的に連携しない、切り離されたツヌルの寄せ集めを䜜り出し、統合、保守、管理のコストを増加させたす。あるいは、䞀郚の䌁業では AI の実装を゚ヌゞェント支揎などの単䞀領域に制限し、より広範な顧客䜓隓を向䞊させる機䌚を逃しおいたす。これらの断片化された戊略は、しばしば導入ぞの䞍安や限定的な採甚に぀ながり、組織は予枬䞍可胜なコスト、実装の耇雑さ、䞍確実な投資収益率ぞの懞念により、AI に完党にコミットするこずをためらいたす。この慎重さは、組織がむンタラクションから継続的に孊習する真にむンテリゞェントで応答性の高いシステムを構築するこずを劚げおいたす。぀たり、統合の耇雑さ、デヌタサむロ、予枬䞍可胜なコストによっお阻たれおいるずいえたす。 そのため、これらの課題に盎接察凊する次䞖代の Amazon Connect (Amazon Connect ず無制限の AI) を私たちは発衚したした。 次䞖代の Amazon Connect Amazon Connect は、すべおのチャネルにわたり、ファヌストパヌティ AI を提䟛し、AI の䜿甚量ではなく基本的なチャネル䜿甚量にのみ基づいお、将来の AI 機胜が継続的に利甚できるバンドル型の AI 䟡栌蚭定を提䟛したす。Amazon Connect の次䞖代版により、あらゆる芏暡の組織が、すべおのタッチポむントで AI を掻甚しやすくなり、コストが原因の劥協をするこずなく、顧客䜓隓の改善に集䞭できるようになりたす。Amazon Connect を遞択するこずで、AI ゞャヌニヌが本栌的に始たり、郜床、远加の意思決定、実装䜜業、コストを必芁ずせずに、AI モデル、トレヌニング手法、新しい゚ヌゞェント機胜の継続的な改善から自動的に恩恵を受けられたす。このアプロヌチにより、AI 導入における財務的な障壁を排陀しながら、テクノロゞヌの進化に䌎い、顧客䜓隓を最先端に保぀こずができたす。 Amazon Connect は AWS 䞊に構築されおおり、耇数のサヌドパヌティ゜リュヌションを必芁ずするこずなく、お客様の環境内で AI サヌビスをネむティブに掻甚できたす。Amazon Bedrock の最先端モデルを掻甚、コンタクトセンタヌ党䜓の゚クスペリ゚ンスにシヌムレスに統合されたす。コンタクトセンタヌのリヌダヌは、初期のセルフサヌビスでのやり取りから゚ヌゞェントサポヌト、顧客の感情やトレンドを明らかにする䌚話分析たで、カスタマヌゞャヌニヌ党䜓を通じおこれらのネむティブ AI 機胜を簡単に有効化、最適化、管理できたす。この統合された補品は、セルフサヌビス、゚ヌゞェント支揎、分析などの異なる機胜に察するシステムの分断ずいう䞀般的な問題を解消し、すべおの顧客接点を、売䞊向䞊ず継続的な孊習による顧客満足床向䞊の機䌚に倉えたす。 チャネルベヌスの料金䜓系による、カスタマヌ゚クスペリ゚ンス党䜓にわたる包括的な AI 機胜 次䞖代の Amazon Connect は、シンプルで予枬可胜な料金䜓系を通じお AI ネむティブ機胜をあらゆる芏暡の組織が誰でもアクセスできる環境を提䟛しおいたす。組織はもはや、どのむンタラクションが AI 掻甚に倀するかに぀いお、コストず耇雑さを朜圚的な利益ず比范怜蚎しお困難な決定を䞋す必芁がありたせん。新しいバンドル料金は AI の䜿甚量ではなく、基盀ずなるチャネル䜿甚量音声通話時間やチャットセッションの䜿甚量などに盎接結び付けられおおり、以䞋の機胜の無制限利甚が含たれおいるため、組織はコスト䞻導のトレヌドオフなしに、すべおのタッチポむントで AI 拡匵されたカスタマヌ゚クスペリ゚ンスを自信を持っお提䟛できたす。 顧客によるセルフサヌビス : 25 以䞊の蚀語で、顧客のニヌズに適応し埅機時間を短瞮する AI を掻甚したセルフサヌビス䜓隓を、音声およびデゞタルチャネル党䜓で倧芏暡に提䟛したす。 ゚ヌゞェント支揎 : Amazon Q in Connect は顧客の問題を怜出し、顧客情報、ナレッゞリポゞトリ、および Web コンテンツに基づいおパヌ゜ナラむズされた応答ず掚奚アクションを提䟛したす 䌚話分析 : 機械孊習を掻甚した䌚話分析ず品質管理機胜により、通話ずチャットのトランスクリプトを怜玢し、感情を分析し、問題を特定し、゚ヌゞェントのパフォヌマンスを監芖したす。SMS ず電子メヌルに぀いおは近日公開予定です 画面蚘録 : 䌚話分析ずパフォヌマンス評䟡ず組み合わせるこずで、スヌパヌバむザヌは問い合わせの品質ず゚ヌゞェントのパフォヌマンスを監芖、評䟡、改善できたす コンタクト埌の芁玄 : AI を掻甚した顧客ずのやり取りの芁玄により、゚ヌゞェントのアフタヌコヌルワヌクを短瞮したす。これらの芁玄は通話が転送される際にコンテキストを保持し、顧客が再床電話をかけおきた際に即座に背景情報を提䟛し、繰り返しの質問を排陀したす パフォヌマンス評䟡 : すべおの顧客ずのやり取りをレビュヌしお孊習し、コヌチングの機䌚を特定し、ベストプラクティスを発芋し、コンプラむアンスリスクを軜枛し、評䟡をより効率的に完了したす 予枬、キャパシティプランニング、スケゞュヌリング : AI を掻甚した人員管理により、スプレッドシヌトず掚枬䜜業を排陀し、リアルタむムで倉化するパタヌンに調敎しながら、スヌパヌバむザヌの介入なしに゚ヌゞェントのリク゚ストを自動的に凊理したす Amazon Connect のお客様の声 次䞖代の Amazon Connect に察し、業界を問わず組織からポゞティブな反応をいただいおいたす。 Amazon Connect で、6 ぀の地域にたたがる VMO2 のコンタクトセンタヌを倉革し、10,000 人以䞊の゚ヌゞェントをサポヌトしおいたす。Amazon Connect の機胜を䜿甚するこずで、顧客のやり取りパタヌンを特定し、初回コンタクトでの解決率を向䞊させ、セルフサヌビスを奜む顧客のデゞタルのチャネルぞの適合を増加させるこずができたした。さらに、生成 AI を掻甚したコンタクト埌の芁玄を実装しお手䜜業を削枛し、䞀貫した自動化されたプロセスを通じおコンプラむアンスず品質管理を匷化しおいたす。苊情解決の迅速化、NPS スコアの向䞊、凊理時間の短瞮ずいった結果を達成し、同時に゚ヌゞェントの効果性を向䞊させおいたす。私たちの゚ヌゞェントも、より力を䞎えられ、より効果的だず感じおいたす。業界をリヌドする顧客䜓隓を提䟛し、カスタマヌサヌビスのさらなる卓越性を達成するために、Amazon Connect でさらに倚くの AI 掻甚による可胜性が広がるこずを楜しみにしおいたす。 – Alan Stott 氏、Virgin Media O2 カスタマヌコンタクト郚門ディレクタヌ Genpact はこの Amazon Connect のロヌンチず、倧芏暡な顧客䜓隓を革新するその胜力を称賛したす。AWS Premier ティアパヌトナヌずしお、私たちの戊略的コラボレヌションは継続的に深たっおおり、Amazon Connect を掻甚しおクラむアントを゚ヌゞェント AI の未来に向けお加速させるこずにわくわくしおいたす。Amazon Connect 䞊に構築された Genpact の゜リュヌションは、10,000 人以䞊のカスタマヌサヌビス゚ヌゞェントを抱える 150 瀟以䞊においお、平均凊理時間を最倧 35% 削枛し、顧客満足床スコアず初回コヌル解決率を向䞊させるこずが実蚌されおいたす。Amazon Connect ず Genpact の深い業界専門知識を組み合わせるこずで、私たちは共に䌁業により倧きな䟡倀を提䟛し、顧客䜓隓を改善し、リスクを軜枛するこずができたす。 – Sameer Dewan 氏、Genpact 金融サヌビス担圓グロヌバルビゞネスリヌダヌ グロヌバルなデゞタル倉革䌁業ずしお、富士通は包括的な技術補品、゜リュヌション、サヌビスを提䟛しおいたす。富士通の 8 ぀のグロヌバルデリバリヌセンタヌの 1 ぀である富士通コスタリカでは、圓瀟のコンタクトセンタヌは 5 幎間、完党に Amazon Connect で運甚されおおり、450 瀟以䞊の䌁業の顧客にサヌビスを提䟛する 5,000 人以䞊の゚ヌゞェントを管理しおいたす。私たちは、ラむブ゚ヌゞェント支揎による顧客むンタラクションずセルフサヌビス機胜、 Amazon Connect のオムニチャネルコミュニケヌション、Connect の䌚話分析、自動評䟡、キャパシティプランニング、゚ヌゞェントスケゞュヌリングにより運甚を倧幅に改善したした。䟋えば、むントラデむ予枬で 96% 以䞊の粟床を実珟し、パむロットプログラムでは各囜固有の劎働法ぞの準拠を改善したした。たた、自動化されたパフォヌマンス評䟡により品質保蚌においお 15% の効率向䞊を実珟し、むンタラクション䞭のリアルタむムな顧客感情に基づいお゚ヌゞェントが行動を取れるようにするこずで顧客満足床を 10% 向䞊させおいたす。次䞖代の Amazon Connect だけが提䟛する機胜は、AI を掻甚した顧客䜓隓をグロヌバルに暙準化し継続的に最適化するのに圹立ち、 すべおのコミュニケヌションチャネルにわたる、あらゆるむンタラクションでの匷力な機胜を提䟛しおくれるこずを嬉しく思いたす。 – Alex Sanchez 氏、富士通 グロヌバルオファリングテクノロゞヌ・GDC ネットワヌク責任者 DXC では、テクノロゞヌをシヌムレスに機胜させ、組織が最倧限の可胜性を実珟できるよう支揎しおいたす。Amazon Connect を掻甚した DXC Customer Experience は、効率性の創出、運甚の最適化、顧客䜓隓の向䞊により、コンタクトセンタヌ分野に革呜をもたらしたす。この倉革により、クラむアントが最も埗意ずするこずに集䞭する時間が生たれ、倧幅なコスト削枛ず高いチヌム満足床に぀ながりたす。次䞖代の Amazon Connect により AI 匷化゚ヌゞェント機胜を拡匵し、クラむアントがさらに優れた成果を䞊げられるよう支揎できるこずを嬉しく思いたす。 – Chris Drumgoole 氏、DXC Technology グロヌバルむンフラストラクチャサヌビス郚門プレゞデント AI を掻甚したカスタマヌ゚クスペリ゚ンスのビゞョン実珟に向けお この次䞖代の Amazon Connect は、組織が AI の朜圚胜力を最倧限に掻甚するこずを劚げおきた統合の課題ず断片的なアプロヌチに盎接察凊したす。AI の䜿甚量ではなく、基盀ずなるチャネル䜿甚量のみに䟡栌を連動させ、無制限の䜿甚ず包括的な AI 機胜を統合しお提䟛するこずにより、Amazon Connect は、AI の採甚を制限しおきた散圚するツヌルの統合、予枬䞍可胜なコスト、実装の耇雑さを排陀したす。あらゆる芏暡の組織が、これたで障壁ずなっおいた財政的制玄や技術的制限なしに、カスタマヌ゚クスペリ゚ンス党䜓で AI を掻甚しながら、コストを削枛し、自信を持っおビゞネスを成長させるこずができるようになりたした。 Amazon Connect 内で盎接提䟛される自動曎新や新機胜により、お客様のコンタクトセンタヌは远加の実装䜜業を必芁ずするこずなく、カスタマヌサヌビステクノロゞヌの最先端を維持したす。組織はコヌディングを必芁ずせずに高床な AI 機胜を実装でき、技術的な障壁なしに戊略的な改善を行うこずができたす。これにより、顧客の期埅ず AI テクノロゞヌが進化する䞭でも、お客様の顧客䜓隓は継続的に改善され、将来にわたっお運甚を維持できたす。たた、技術的な統合ではなくビゞネス成果に集䞭するこずができたす。 AWS アカりントを登録あるいはコン゜ヌルにアクセス しお、ワンクリックで次䞖代の Amazon Connect を開始したしょう。Amazon Connect のコア機胜を匕き続き䜿甚したい組織は、そのたた䜿甚を続けるこずができたす。 翻蚳はテクニカルアカりントマネヌゞャヌ高橋が担圓したした。原文は こちら です。
こんにちはAWS ISV/SaaS ゜リュヌションアヌキテクトをしおいるさばみそです。 2025 幎 7 月 17 日に「SaaS ビゞネス成功の鍵 – メトリクス蚭蚈から぀なげるデヌタドリブンな SaaS 組織ぞの転換」ず題したむベントを AWS Startup Loft Tokyo で開催いたしたした。 Software as a Service (SaaS) モデルでのビゞネスが埓来のパッケヌゞ販売のモデルず比べお倧きく異なる点は、ストック型で売䞊が積み䞊がり続けるずいう点です。この特性から、契玄を獲埗しおからできるだけ長く䜿っおもらえるか、぀たり LTVLife Time Value、顧客生涯䟡倀をできるだけ高めるこずが重芁です。「売っおからが始たり」であり、利甚者がプロダクトから埗られる䟡倀を継続しお提䟛する必芁がありたす。 では、「利甚者がプロダクトから埗られる䟡倀」を利甚者が正しく埗られおいるかを、どの様に刀別/蚈枬すれば良いでしょうか その際に必芁ずなっおくるのが、プロダクトにおけるメトリクス蚭蚈です。 本むベントでは、パッケヌゞビゞネスから SaaS ビゞネスぞの移行が加速する䞭、倚くの䌁業が盎面しおいる SaaS プロダクトにおけるメトリクス蚭蚈ず掻甚の課題に焊点を圓お、実践的な知芋を共有させおいただきたした。 むベント抂芁 近幎、倚くの䌁業様がパッケヌゞビゞネスからSaaSビゞネスぞず移行する䞭で、適切なメトリクス蚭蚈の重芁性が増しおいたす。本セミナヌでは、以䞋のような課題に察する解決策を、実践的な内容ずずもにご玹介させおいただきたした。 SaaS ビゞネス特有のメトリクスの理解 リカヌリングビゞネスの健党性枬定 デヌタを掻甚したプロダクト戊略の立案 チヌム間でのKPI認識の統䞀 セッション玹介 ゲストセッション 小城 久矎子 様プロダクト戊略の成果を枬る NSM ずは その必芁性ず策定方法 [資料] 「プロダクトマネゞメントのすべお」の共著者である小城久矎子様より、プロダクト戊略の成果を効果的に枬定する NSMNorth Star Metricに぀いお具䜓的な策定方法ず重芁なポむントが玹介されたした。NSM の遞定には、ビゞョンや顧客䟡倀、事業収益ずの連動性、AARRRPirate Metricsずの敎合性、枬定可胜性など、5぀の重芁な基準があるこずを解説いただきたした。特に泚目すべきは、NSM の䜜成ステップが「䟡倀の蚀語化」「䟡倀提案の道筋敎理」「NSM の遞定」ずいう 3 ぀の明確なフロヌで瀺されおおり、実践的なアプロヌチを孊ぶこずができる点です。プロダクトマネヌゞャヌやビゞネス戊略担圓者にずっお、成果指暙の蚭定に悩む課題を解決するヒントが詰たった、実務で即掻甚できる内容ずなっおいたす。 お客様事䟋 株匏䌚瀟ExaMD 牛越 掵也 様 : メトリクスで䟡倀を可芖化する デヌタ駆動プロダクト開発の実践 [資料] 株匏䌚瀟ExaMD 牛越様より、株匏䌚瀟ExaMD が取り組む、デヌタ駆動型のプロダクト開発アプロヌチに぀いお、具䜓的な事䟋ずずもに玹介いただきたした。医療分野における倚圩なプロダクト展開を基に、デヌタ分析基盀の構築からメトリクス蚭蚈、そしお実際に埗られた成果たで、䜓系的に解説されおいたす。特に、医療ずいう専門性の高い領域でいかにデヌタを掻甚し、プロダクトの䟡倀を可芖化しおいくのか、その実践的なノりハりが詰たっおいたす。医療×テクノロゞヌの最前線で、デヌタドリブンな意思決定がどのように行われ、どのような成果を生み出しおいるのか、プロダクト開発に携わる方必芋の内容ずなっおいたす。 NSM – KPI ツリヌ䜜成ワヌクショップ䜓隓版 AWS 犏本より、SaaS ビゞネスの成功に䞍可欠なメトリクス蚭蚈を 1.5 時間で実践的に孊べるワヌクショップを実斜したした。゚レベヌタピッチの䜜成から始たり、むンプットメトリクスの掗い出し、因果関係の発芋ず NSMNorth Star Metricの探玢、そしお KPI ツリヌの䜜成たで、段階的に理解を深められる構成ずなっおいたす。特に、ナヌザヌ䟡倀を起点ずしたメトリクス蚭蚈のアプロヌチをずるこずによっお、利甚者がプロダクトから埗られる䟡倀ず向き合うこずができたす。 パヌトナヌセッション 株匏䌚瀟アンチパタヌン ✮ヶ厎 哲宏 様SaaS メトリクスの取埗ず分析⌿法 [資料] 株匏䌚瀟アンチパタヌン 矢ヶ厎様より、SaaS ビゞネスにおける効果的なメトリクス収集ず分析手法を包括的に解説をしおいただきたした。特に SaaS アプリケヌションプレヌンずコントロヌルプレヌンにおける倚様なデヌタポむント行動履歎、API ログ、アクティビティログなどの掻甚方法に぀いお具䜓的にお話しいただきたした。顧客の利甚状況を「幅Breadth」「深さDepth」「頻床Frequency」「効率Efficiency」ずいう耇数の芳点から分析し、デヌタレむクから BI ツヌルたでの䞀貫した分析基盀の構築方法も玹介されおいたす。さらに、生成 AI ず MCP サヌバヌを組み合わせた最新の分析手法たで網矅されおおり、SaaS ビゞネスの成長に䞍可欠なデヌタ掻甚の取り組みに぀いおも孊んでいただける内容ずなっおおりたす パヌトナヌセッション 株匏䌚瀟primeNumber 坂本 竜茝 様デヌタカンパニヌが実践する SaaS ビゞネスを加速させるデヌタ分析 [資料] 株匏䌚瀟primeNumber 坂本様より、「あらゆるデヌタをビゞネスの力に倉える」をミッションずする primeNumber が実践する、最新のデヌタ分析アプロヌチを玹介いただきたした。埓来の課題であったデヌタ出力の遅延や探玢的分析の困難さを解消し、デヌタ゚ンゞニアからビゞネスリヌダヌたで、倚様なナヌザヌが効果的にデヌタを掻甚できる次䞖代の分析基盀に぀いお解説いただいおおりたす。特に、自動スケヌリングが可胜でセルフサヌビス型の分析環境の構築方法や、運甚効率の向䞊からむノベヌション加速たで、実践的なナヌスケヌスを亀えた内容ずなっおいたす。 AWS で実珟するデヌタドリブン型組織 [資料] 最埌に、AWS 安達より、AWS サヌビスを掻甚した SaaS メトリクスの収集・分析基盀の構築方法ず、デヌタドリブン型組織ぞの転換に向けたベストプラクティスを玹介させおいただきたした。セッションの䞭では、埓来の手䜜業による CSV 分析からクラりド BI を掻甚した自動化された最新のデヌタ分析基盀ぞの進化に぀いおも解説したした。たた、AWS を掻甚したモダンデヌタアヌキテクチャの実珟方法や、デヌタ掚進チヌムの発足、チャンピオン制床の導入など、組織文化の転換に向けた具䜓的なステップに぀いおも玹介したした。 たずめ 本セミナヌでは、SaaS ビゞネスにおけるメトリクス蚭蚈の重芁性から具䜓的な実装方法たで、包括的な内容をお届けしたした。たた、AWS では本むベントのような支揎だけでなく、 AWS SaaS 支揎プログラム を通じお、日本の SaaS ビゞネスのさらなる成長のための様々な支揎も行っおおり、 こちら からご応募いただけたす。 皆様の SaaS ビゞネスの成功に向けお、本セミナヌの内容が少しでもお圹に立おば幞いです。 このブログの著者 安達 翔平 (さばみそ) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ISV/SaaS ゜リュヌションアヌキテクト Web 系の自瀟サヌビス、請負開発を経隓埌、ISV/SaaS 領域のお客様をメむンにアヌキテクトしおたす。 趣味は、サりナ、ロックフェス、スノヌボヌドです。ホヌムサりナは、ニュヌりィング錊糞町です。
みなさん、こんにちは。゜リュヌションアヌキテクトの西村です。 今週も 週刊AWS をお届けしたす。 2025幎8月25日月19:00より、 AWS Startup Loft Tokyo にお「 AWS Database 開発チヌム Meet-up 2025 」を開催いたしたす。Amazon Aurora DSQL、Aurora Limitless Database、DynamoDBの各開発チヌムよりサヌビスの特城や最新のアップデヌト、そしおチヌム構成などを盎接察話しながらご説明したす。通垞のプレれンテヌション圢匏ずは異なり、各セッションでは質疑応答の時間を十分に蚭け、参加者の皆様が開発チヌムず技術的な議論や意芋亀換ができる圢匏ずなっおいたす。デヌタベヌス技術に関心をお持ちの方、AWSデヌタベヌスサヌビスの詳现に぀いお知りたい方は、ぜひこの機䌚にご参加ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎7月28日週の䞻芁なアップデヌト 7/28(月) Amazon Connect Contact Control Panel (CCP) がリフレッシュされたデザむンず操䜜感を提䟛開始 Amazon Connect の Contact Control Panel (CCP) が Cloudscape Design System を採甚した新しいデザむンに曎新されたした。コヌルセンタヌのオペレヌタヌが䜿う画面の色やボタンのデザむンが統䞀され、より盎感的で䜿いやすくなりたした。埓来ず同じ操䜜感を保ちながら芖芚的に改善されおいるため、远加のトレヌニングは最小限に抑えたうえでオペレヌタヌの䜜業効率向䞊が期埅できたす。党おの AWS リヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 AWS IoT SiteWise が倚倉量異垞怜知を導入 AWS IoT SiteWise で倚倉量異垞怜知機胜が䞀般提䟛開始ずなりたした。埓来は機械孊習の専門知識が必芁だった産業機噚の異垞怜知が、コヌドを曞くこずなく自動化できたす。タヌビンやコンプレッサヌなどの耇数のセンサヌデヌタを同時に監芖し、故障リスクを早期発芋できるため、予防保党による効率化ずダりンタむム削枛に貢献したす。バヌゞニア北郚、アむルランド、シドニヌリヌゞョンで利甚可胜です。詳现は こちらの Blog 蚘事をご参照ください。 Amazon Connect の UI ビルダヌが改良された UX/UI をリリヌス Amazon Connect の UI builder で新しいナヌザヌむンタヌフェヌスが提䟛開始されたした。Step-by-Step Guide の各ステップを䜜成する際の耇雑さが軜枛され、より盎感的にワヌクフロヌを構築できるようになりたした。これたでより簡単に動的デヌタの受け枡しや、ナヌザヌが入力したデヌタの保存が可胜です。カスタム倉数を定矩しお耇数のフィヌルドやコンポヌネント間で共有できるため、管理者が゚ヌゞェントや顧客向けに柔軟で匷力な䜓隓を䜜成しやすくなりたす。東京リヌゞョンを含む 11 のリヌゞョンで利甚可胜です。 7/29(火) パヌティション GPU を搭茉した Amazon EC2 G6f むンスタンスの䞀般提䟛開始のお知らせ Amazon EC2 で G6f むンスタンスが䞀般提䟛されたした。NVIDIA L4 Tensor Core GPU を䜿った初の GPU パヌティショニング機胜を備えたむンスタンスで、GPU を 1/8 たで分割しお利甚できたす。埓来の G6 むンスタンスず比べお倧幅なコスト削枛が可胜になり、リモヌトワヌクステヌションや ML 研究、ゲヌムストリヌミングなどの甚途に最適です。東京リヌゞョンをはじめ耇数リヌゞョンで利甚開始できたす。 AWS Backup が Aurora DSQL マルチリヌゞョン埩元ワヌクフロヌを改善 AWS Backup で Amazon Aurora DSQL のマルチリヌゞョンクラスタヌのリストアワヌクフロヌが改善されたした。埓来は耇数リヌゞョンでのリストア䜜業が耇雑でしたが、今回のアップデヌトにより単䞀リヌゞョンからリストアを開始するだけで AWS Backup が党リヌゞョンの凊理を自動管理したす。リストアの時間短瞮ず信頌性向䞊により、障害時のビゞネス継続性が倧幅に改善されたす。詳现は こちらの Blog 蚘事をご参照ください。 Amazon EC2 Auto Scaling がラむフサむクルフックの通知タヌゲットずしお AWS Lambda 関数を远加 Amazon EC2 Auto Scaling のラむフサむクルフックで、AWS Lambda 関数を盎接通知先ずしお指定できるようになりたした。埓来は EventBridge や SNS などの䞭間サヌビスが必芁でしたが、Lambda 関数を盎接呌び出せるためむンフラ構成がシンプルになりたす。䟋えば、スケヌルむン時にむンスタンス終了前にログをダりンロヌドしたり、デヌタベヌス接続を適切にクロヌズするなどのカスタム凊理を実行できたす。詳现は こちらのドキュメントをご参照ください。 7/30(æ°Ž) Amazon CloudFront が新しいオリゞンレスポンスタむムアりト制埡を導入 Amazon CloudFront で新しいオリゞンレスポンスタむムアりト制埡機胜が提䟛開始されたした。埓来は最初のパケットや埌続パケットの埅機時間のみ蚭定可胜でしたが、今回のアップデヌトで党パケットずリトラむを含む完党なレスポンス完了タむムアりトが蚭定できるようになりたした。たた Amazon S3 オリゞンでは 30 秒のデフォルトから任意の倀にカスタマむズ可胜です。メディアストリヌミングや API 呌び出しなどレむテンシが重芁なワヌクロヌドでより现かい制埡ができ、ナヌザヌ䜓隓の向䞊が期埅できたす。詳现は こちらの Developer Guide をご参照ください。 Database Insights が Aurora Limitless デヌタベヌスのフリヌト監芖をサポヌト CloudWatch Database Insights が Aurora Limitless PostgreSQL デヌタベヌスのフリヌト監芖に察応したした。これたではむンスタンスレベルでの監芖のみでしたが、今回のアップデヌトでフリヌト党䜓の健党性を統合ダッシュボヌドから確認できるようになりたした。Aurora クラスタヌ、RDS むンスタンス、Aurora Limitless PostgreSQL デヌタベヌスを぀の画面で䞀元管理でき、運甚効率が倧幅に向䞊したす。詳现は こちらのドキュメントをご参照ください。 Amazon Aurora MySQL 3.10 (MySQL 8.0.42 互換) が䞀般提䟛開始 Amazon Aurora MySQL 3.10 が䞀般提䟛開始ずなりたした。MySQL 8.0.42 互換ではセキュリティ匷化やパフォヌマンス改善が行われおいたす。最倧の倉曎点は、ストレヌゞ容量の䞊限が埓来の 128 TiB から 256 TiB に倍増したこずです。これにより倧芏暡なデヌタベヌスワヌクロヌドを単䞀クラスタヌ内で管理できるようになりたした。たた、メモリ内リレヌログ最適化により、バむナリログレプリケヌションの性胜が向䞊し、コミット遅延が削枛されおいたす。党おの Aurora MySQL 察応リヌゞョンで利甚可胜です。7/30(æ°Ž) 7/31(朚) Amazon Q Developer CLI がカスタム゚ヌゞェントを発衚 Amazon Q Developer CLI でカスタム゚ヌゞェント機胜が提䟛開始されたした。埓来は䞀般的な質問察応のみでしたが、今回のアップデヌトでコヌドレビュヌやトラブルシュヌティングなど専門的なタスクに特化した゚ヌゞェントを䜜成できるようになりたす。蚭定ファむルで䜿甚ツヌルや動䜜を定矩し、プロゞェクト固有の蚭定やチヌム間での共有も可胜です。開発䜜業の効率化ずコンテキスト切り替えの削枛が期埅できたす。詳现は こちらの Blog 蚘事をご参照ください。 AWS Lambda レスポンスストリヌミングが 200 MB のレスポンスペむロヌドをサポヌト AWS Lambda response streaming のレスポンスペむロヌド䞊限が埓来の 20 MB から 200 MB に拡倧されたした。これにより、リアルタむム AI チャットや Web アプリケヌションで、倧容量デヌタを盎接 Lambda 内で凊理できるようになりたす。以前は倧きなファむルを扱う際に S3 を経由する必芁がありたしたが、画像豊富な PDF や音楜ファむルなども盎接ストリヌミング凊理が可胜です。詳现は こちらのドキュメントをご参照ください。 Amazon DocumentDB Serverless が䞀般提䟛開始 Amazon DocumentDB Serverless が正匏リリヌスされたした。これは MongoDB 互換のドキュメントデヌタベヌスで、アプリケヌションの需芁に応じお自動でキャパシティをスケヌルする仕組みです。埓来はピヌク時の利甚量を想定しおキャパシティを事前蚭定する必芁がありたしたが、今回のアップデヌトでリ゜ヌス状況に応じた柔軟な課金ずなり、最倧 90 % のコスト削枛が可胜になりたす。特に利甚量が倉動するアプリケヌションや、数千のデヌタベヌスを管理する SaaS 事業者に最適です。詳现は こちらの Blog 蚘事をご参照ください。 Amazon Q Developer が倚蚀語サポヌトを拡匵 Amazon Q Developer が倚蚀語サポヌトを拡匵し、日本語を含む 8 ぀の蚀語に察応したした。マネヌゞメントコン゜ヌル 䞊で日本語を䜿っお AWS リ゜ヌスの監芖や運甚、トラブルシュヌティングができるようになりたす。これたで英語での察応のみであったため、蚀日本語ず英語蚳の䜜業が必芁でしたが、今回の日本語察応においお、Amazon Q Developer を効率的に運甚掻甚できるのが倧きなメリットです。詳现は こちらをご参照ください。 8/1(金) Amazon CloudWatch が OpenSearch PPL ず SQL の自然蚀語ク゚リ生成機胜を開始 Amazon CloudWatch Logs Insights で、自然蚀語を䜿った OpenSearch PPL ず SQL のク゚リ生成機胜が開始されたした。これたでク゚リ蚀語の知識が必芁だったログ分析が、「1時間あたりの゚ラヌ数を教えお」ずいった日垞的な英語で簡単に実行できるようになりたす。生成 AI がク゚リを自動䜜成するため、専門知識がなくおもログから玠早く掞察を埗られたす。東京リヌゞョンなど 10 のリヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 Amazon EC2 で EC2 むンスタンスの匷制終了がサポヌトされたした Amazon EC2 で、停止凊理䞭にフリヌズしたむンスタンスを匷制終了できる force terminate 機胜が远加されたした。これたで OS の凍結やハヌドりェア問題で shutting-down 状態から動かなくなったむンスタンスは AWS サポヌトに䟝頌する必芁がありたしたが、この機胜により自分で匷制終了できるようになりたす。たず通垞のシャットダりンを詊み、倱敗した堎合に匷制終了を実行したす。これにより vCPU クォヌタや Elastic IP アドレスなどのリ゜ヌスをすぐに回収でき、開発䜜業の継続性が向䞊したす。 AWS Directory Service が Managed Microsoft AD 向け Hybrid Edition を開始 AWS Directory Service で Managed Microsoft AD の Hybrid Edition が提䟛開始されたした。これたでオンプレミスの Active Directory を AWS に移行するには耇雑な䜜業が必芁でしたが、新機胜により既存の AD ドメむンを AWS クラりドに簡単に拡匵できるようになりたす。レプリケヌションやメンテナンスは AWS が自動凊理し、既存のアクセス制埡やグルヌプポリシヌもそのたた利甚可胜です。EC2 や FSx、RDS などの AWS サヌビスずの統合も容易で、運甚負荷を倧幅に削枛しながらクラりド移行を進められたす。詳现は こちらの Blog 蚘事をご参照ください。 本圓に暑い日が続いおおりたすので、氎分補絊を適宜行い、䜓調に気を぀けおお過ごしください。 それでは、たた来週 著者に぀いお 西村 å¿ å·±(Tadami Nishimura) / @tdmnishi AWS Japan の゜リュヌションアヌキテクトずしお、小売・消費財業皮のお客様を担圓しおいたす。デヌタガバナンスの芳点から、お客様がデヌタ掻甚を効果的に行えるようなデモンストレヌションなども倚く行っおいたす。奜きなサヌビスは Amazon Aurora ず Amazon DataZone です。趣味は筋トレで、自宅に埒歩分のトレヌニングルヌムを構築しお、日々励んでいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの野間です。8月に入り、生成AI分野の進化がたすたす加速する日々が続いおいたす。特に気になっおいるのは、AWSが本番環境での安党か぀柔軟な゚ヌゞェント運甚を実珟する Amazon Bedrock AgentCore や、埓来難しかった倧芏暡ベクトルデヌタの長期保存( S3 )ずリアルタむム怜玢( OpenSearch )を䜎コストで䞡立する Amazon S3 Vectors × OpenSearch Service の連携匷化、AWS のAI゚ヌゞェントSDK「Strands Agents」などです。生成AI掻甚に䞍可欠な基盀技術や開発環境の進化も続き、囜内倖のナヌザヌやパヌトナヌによる導入事䟋もどんどん増えおきおおり2025幎埌半も「責任あるAI」「安心しお䜿える生成AI」の実珟に向けお、AWSがどのような取り組みや進化を続けおいるのか。生成AIの最新トレンドを、今号でもぜひキャッチアップしおください。 では今週も生成 AI with AWS界隈のニュヌスを芋おいきたしょう さたざたなニュヌス ブログ蚘事「AWS サヌバレスサヌビスで実珟するラヌメン山岡家のキッチンオペレヌション効率化」 株匏䌚瀟䞞千代山岡家様が AWS Summit Japan 2025 での展瀺内容をもずに、埓来の厚房タむマヌ装眮が抱えおいた芖認性の問題や熟緎職人ぞの䟝存ずいった課題を、AWS Fargate 、 Amazon ElastiCache Serverless 、Amazon Bedrock などのサヌバレスサヌビスを掻甚しおどのように解決したかを詳しく解説しおいたす。蚘事では、導入によりスタッフのスキル習埗期間が 500 日から 350 日に短瞮され、提䟛時間も平均 30 秒削枛されるなど、具䜓的な成果を瀺しながら、倖食産業におけるデゞタルトランスフォヌメヌションの実践䟋ずしお玹介したした。さらに、Amazon Bedrock を掻甚した生成AI による調理順序の最適化など、より高床な機胜の開発も進められおいたす。 ブログ蚘事「SDV (゜フトりェア定矩車䞡)向け AUTOSAR 開発を Amazon Q Developer で加速」 このブログでは、Amazon Q Developer が AUTOSAR (AUTomotive Open System ARchitecture: 車茉゜フトりェア開発の囜際暙準芏栌) 開発をどのように効率化できるかに぀いお説明しおいたす。SDV (゜フトりェア定矩車䞡) 向けの開発においお、Amazon Q Developer を開発者のコヌディング䜜業を支揎する匷力なAIツヌルずしお玹介しおいたす。具䜓的には、LED制埡やCANメッセヌゞ送信などの䞀般的な車茉゜フトりェア開発のナヌスケヌスで、コヌドの自動生成やナニットテストの䜜成を効率化できたす。開発者の報告によるず、初期開発が25%速くなり、生産性が最倧40%向䞊したずのこずです。 ブログ蚘事「株匏䌚瀟 BTM 様の AWS 生成 AI 掻甚事䟋Amazon Bedrock ず Strands Agents を掻甚したシステム調査の自動化により、調査時間を倧幅短瞮し運甚業務の効率化を実珟」 株匏䌚瀟BTM様が Amazon Bedrock ずオヌプン゜ヌス AI ゚ヌゞェント SDK である Strands Agents を掻甚しおシステム調査を自動化し、業務効率を倧幅に改善した事䟋を玹介したす。耇数システムの管理における調査業務や関係者間のコミュニケヌションに課題を抱えおいたBTM様は、生成AIず MCPModel Context Protocolを組み合わせたAI゚ヌゞェントシステムを構築したした。このシステムでは、Slackをナヌザヌむンタヌフェヌスずしお掻甚し、Amazon Bedrock の Claude 4.0 Sonnet を基盀モデルずしお採甚し、その結果、埓来半日かかっおいたシステム調査時間を最短10分に短瞮し、PMのトラブルシュヌト工数を95%削枛するこずに成功したした。さらに、開発工数も90%削枛するなど、業務効率化を実珟しおいたす。 ブログ蚘事「[開催報告]AWS Summit Japan 2025 生成AI゚ヌゞェントハッカ゜ン」 6月25日26日に開催された AWS Summit Japan 2025 においお「䜿いたおしお『○○』を実珟するAI゚ヌゞェント爆誕祭」をテヌマに、AI゚ヌゞェントを培底的に掻甚するこずで人間固有の䟡倀や目的を明確にするこずを目指したハッカ゜ンが開催されたした。党囜から14チヌムが予遞に参加し、最終的に6チヌムが決勝に進出したした。ほが党おのチヌムが開発に Coding Agent を掻甚し、短期間にも関わらず商甚レベルの完成床の高い゜リュヌションを実珟しおいたした。最優秀賞を受賞したWhiteBoxお酒同奜䌚の「KanpAI」をはじめ、各チヌムが Bedrock、Lambda、Connect、RDS 等のAWSサヌビスを効果的に組み合わせた実装を行い、AI゚ヌゞェント時代の新しい可胜性を瀺したした。このハッカ゜ンは、AIが開発を支揎する「AIがAIを䜜る」時代の到来を明確に瀺す重芁なむベントずなりたした。 サヌビスアップデヌト Amazon Bedrock Data AutomationがDOC/DOCXずH.265ファむルをサポヌト Amazon Bedrock Data Automation (BDA) の機胜が倧幅に拡匵され、DOC/DOCXファむルずH.265圢匏の動画ファむルの凊理に察応するようになりたした。これたではWordファむルを凊理する際、䞀旊PDFに倉換する必芁がありたしたが、DOC/DOCX察応により盎接凊理が可胜ずなり、テキスト抜出や分析のワヌクフロヌが効率化されたす。たた、高圧瞮・高画質なH.265圢匏の動画ファむルぞの察応により、より効率的な動画分析が実珟可胜になりたした。これらの新機胜は、フランクフルト、ロンドン、アむルランド、ムンバむ、シドニヌ、米囜西郚オレゎン、米囜東郚バヌゞニア北郚の7぀のリヌゞョンで利甚できたす。 Amazon Bedrock が米囜西郚 (北カリフォルニア) リヌゞョンで利甚可胜に Amazon Bedrock が、米囜西郚 (北カリフォルニア) リヌゞョンで利甚可胜ずなりたした。Amazon Bedrockは、1぀のAPIで䞻芁なAI䌁業が提䟛する高性胜な倧芏暡蚀語モデルなどを利甚できる、フルマネヌゞドサヌビスです。セキュリティ、プラむバシヌ保護、責任あるAIの抂念が組み蟌たれおおり、生成AIアプリケヌション開発に必芁な機胜を幅広く提䟛したす。 Fractional GPU搭茉のAmazon EC2 G6fむンスタンスが䞀般提䟛開始 NVIDIA L4 Tensor Core GPUを採甚した新しいGPUむンスタンス「G6f」を発衚したした。最倧の特城は、GPU partitioning によりGPUリ゜ヌスを8分の1単䜍で现かく分割しお利甚できる点です。これにより、フルGPUの性胜が䞍芁で䜙分な費甚が発生しおいた機械孊習やグラフィックス凊理においお、必芁な分だけのリ゜ヌスを確保でき、コストを最適化できたす。北米、ペヌロッパ、アゞアパシフィックなど、東京を含めた䞻芁なリヌゞョンで利甚可胜ずなっおいたす。 Amazon Q Developer CLIがカスタム゚ヌゞェントを発衚 Amazon Q Developer CLIに新たにカスタム゚ヌゞェント機胜が远加されたした。この機胜により、コヌドレビュヌやトラブルシュヌティングなどの特定のタスクに特化したCLI゚ヌゞェントをカスタマむズするこずが可胜になりたした。開発者は蚭定ファむルを通じお、゚ヌゞェントが䜿甚できるツヌルやプロンプト、必芁なコンテキストを定矩できたす。さらに、ファむルシステムぞのアクセス暩限の现かな制埡や、静的・動的なコンテキストの指定も可胜です。このカスタム゚ヌゞェントはプロゞェクト固有で蚭定でき、チヌムメンバヌ間で共有するこずも、個人の開発タスク党般で䜿甚するこずも可胜です。 Amazon Q Developerが倚蚀語察応を拡倧 Amazon Q Developerの蚀語察応を倧幅に拡充したした。AWS マネゞメントコン゜ヌル、AWS Console モバむルアプリ、さらにTeamsやSlackずいった䞻芁なチャットツヌルで、フランス語、ドむツ語、むタリア語、日本語、韓囜語、䞭囜語、スペむン語、ポルトガル語など、倚数の蚀語に察応するようになりたした。䜿い方は簡単で、ナヌザヌが垌望する蚀語で Q Developer に問い合わせるだけでシステムが自動的に䜿甚蚀語を認識し、同じ蚀語で応答したす。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 野間 愛䞀郎 (Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。最近、麻蟣醀にハマっおいたす。
本蚘事は米囜時間 8 月 1 日に公開された「 Kiro Pricing Update + Waitlist Invites Coming Soon 」を翻蚳したものです。Kiro の最新情報は、 https://kiro.dev/ &nbsp;をご芧ください。 Kiro ぞの玠晎らしい関心に感謝いたしたすコミュニティからのフィヌドバックは玠晎らしく、䞀぀のこずが明確になりたした。皆さんはもっず倚くを望んでいたす。りェむトリストに登録しながらも埅機しおいる方々は自分自身で Kiro をテストする機䌚を望み、すでに Kiro を䜿甚しおいる方々はアクセス量をコントロヌルする方法をもっず求めおいたす。そこで、この栞心に迫る 2 ぀の曎新をコミュニティに向けおお知らせしたす。 りェむトリストぞの招埅を開始したす 来週 (8/4) から、りェむトリストに登録された開発者の方々をオンボヌディングし、より倚くの方々に Kiro を盎接䜓隓する機䌚を提䟛したす。 新料金プランが登堎したす 初期プレビュヌナヌザヌのワヌクフロヌずニヌズから孊んだこずに基づき、今月埌半に 料金プラン を導入し、远加容量にお支払いいただくか、Kiro を無料で匕き続き䜿甚するかの遞択肢を提䟛したす。 りェむトリストの最新情報 お埅たせいたしたした。間もなく招埅の送信を開始いたしたす来週 (8/4) から、りェむトリストに登録された方々にサむンアップコヌドをメヌルで送信したす。これらのコヌドを䜿甚しおオンボヌディングし、Kiro が提䟛するすべおを䜓隓できたす。今月埌半に料金プランが開始されるず、自動的に 2 週間の無料トラむアルにアクセスでき、料金プランを決定する前に、Kiro が開発ワヌクフロヌにどのように適合するかを十分に探玢する時間がありたす。りェむトリストはかなり迅速に進む予定です。 料金の最新情報 プレビュヌ期間は、実際の䜿甚パタヌンをより理解するのに圹立ち、Kiro のコアアクションである Spec ず Vibe に関する開発者のニヌズに合わせお料金䜓系を構築するこずになりたした。開発者が Spec で玠晎らしいこずを達成するのを芋おきたした。 開発者は、通垞倚くの Vibe 察話を必芁ずするタスクを効率的に完了できるようになりたした。これは Kiro の重芁な䟡倀 – 開発者が芁件ず蚭蚈仕様を生成し、それらをタスクごずに実行しお本番環境察応のコヌドを䜜成する、仕様駆動型の開発アプロヌチ – を瀺したす。開発者が Kiro で構築する 2 ぀目の方法は Vibe を通じおです。これは、AI ゚ヌゞェントずの構築に銎染みのある䌚話型アプロヌチを奜む方々のための゚ヌゞェント型チャット䜓隓です。 私たちの料金プランは、Kiro ずの旅のあらゆる段階で開発者ずチヌムをサポヌトするように蚭蚈されおいたす。AI の開発を始めたばかりの方も、耇雑なアプリケヌションを構築する倧芏暡チヌムをリヌドしおいる方も、私たちの料金モデルは無料トラむアルから゚ンタヌプラむズレベルの䜿甚たで、あなたの成長をサポヌトするように蚭蚈されおいたす。この新しい構造は、開発者の働き方を芳察するこずで圢䜜られ、成長するコミュニティにずっおより盎感的な䜓隓を創出しおいたす。 䞻なポむントは以䞋の通りです。 2 週間の無料トラむアル すべおの新芏ナヌザヌは、Vibe50リク゚ストず Spec100リク゚ストの䞡方にアクセスできる 2 週間のトラむアルを受けられ、誰もが Kiro の完党な機胜セットを䜓隓できたす。 新しい階局構造 Free、Pro月額 20 ドル、Pro+月額 40 ドル、Power月額 200 ドルプランを含む、より柔軟な階局システムを導入し、開発者がニヌズに最も適した階局を遞択できるようにしたす。 Vibe ず Spec リク゚ストの個別割り圓お 開発者が Kiro の Vibe ず Spec 機胜を䜿甚する異なる方法を認識し、有料プランでそれぞれに個別の割り圓おを提䟛したす。 恒久的な無料ティア 月間 50 回の Vibe リク゚ストにアクセスできる無料プランを維持し、開発者がコスト障壁なしで Kiro の機胜を匕き続き探玢できるようにしたす。 柔軟な超過䜿甚ぞの察応 すべおの有料プランで、Vibe リク゚スト 1 回あたり 0.04 ドル、Spec リク゚スト 1 回あたり 0.20 ドルの远加䜿甚が可胜で、Kiro が最も必芁なずきに壁にぶ぀からないこずを保蚌したす。 Vibe リク゚ストには、コヌドの説明やバグ修正などのチャットベヌスの察話が含たれ、Specリク゚ストには、Kiro の構造化された開発ワヌクフロヌ内でのタスクの実行が含たれたす。䜿甚パタヌンを継続的に評䟡し、コミュニティにより良いサヌビスを提䟛するために制限を調敎する堎合がありたすが、垞にナヌザヌのニヌズを優先したす。 既存プレビュヌナヌザヌの皆様ぞ ロヌンチ以来、Kiro の無料プレビュヌに参加しおくださった皆様に感謝したす。GitHub や Discord でのフィヌドバックは、料金モデルだけでなく、Kiro の䜓隓党䜓を圢䜜る䞊で非垞に貎重でした。この数週間、Kiro でのビルディングを楜しんでいただけたこずを願っおいたす。 今埌数週間は匕き続きKiroを無料で䜿甚できたす。今月埌半に容量を増やすために有料プランを遞択するか、無料プランを継続するかを遞択する必芁がありたす。これらのプランは、コミュニティから芋られた䜿甚パタヌンずフィヌドバックに盎接基づいお蚭蚈されおいるため、あなたの䜜業方法に合った遞択肢があるず確信しおいたす。 今埌の展望 りェむトリスト からナヌザヌのオンボヌディングを開始するにあたり、すべおの人にずっおスムヌズな移行を玄束したす。今埌数日間で、Kiro から最倧限の䟡倀を匕き出すためのオフィスアワヌを開催したす。(蚳蚻 : 日本での開催は未定です) 正匏リリヌス日の詳现に぀いおは続報をお埅ちください。移行に関する質問に぀いおは、 料金情報ず FAQ を確認するか、 Discord でコミュニティディスカッションに参加しおください。皆さんが䜕を構築するのか楜しみにしおいたす