TECH PLAY

AWS

AWS の技術ブログ

å…š3136ä»¶

Amazon Bedrock のガヌドレヌル を 1 幎以䞊前 にリリヌスしお以来、Grab、 Remitly 、 KONE 、 PagerDuty などのお客様は、 Amazon Bedrock のガヌドレヌル を䜿甚しお、 生成 AI アプリケヌション党䜓の保護を暙準化し、ネむティブモデルの保護ず゚ンタヌプラむズ芁件のギャップを埋め、ガバナンスプロセスを合理化しおきたした。4 月 8 日、お客様が゚ンタヌプラむズ芏暡で責任ある AI ポリシヌをさらに効果的に実装するのに圹立぀新しい䞀連の機胜をご玹介したす。 Amazon Bedrock のガヌドレヌルは、最倧 88% の粟床で有害なマルチモヌダルコンテンツを怜出し、機密情報をフィルタリングしお、ハルシネヌションを防ぎたす。耇数の 基盀モデル (FM) ( Amazon Bedrock で䜿甚可胜なモデルや、 ApplyGuardrail API を介しお他の堎所にデプロむされた独自のカスタムモデルを含む) にたたがっお機胜する、統合された安党性およびプラむバシヌの保護手段を組織に提䟛したす。Amazon Bedrock のガヌドレヌルを䜿甚するず、蚭定可胜なコントロヌルず、特定の業界やナヌスケヌスに合わせた保護手段の䞀元管理を通じお、コンプラむアンスず責任ある AI ポリシヌを維持しながら、耇数の FM にわたっお䞀貫した AI 安党性コントロヌルを実装する耇雑さを軜枛できたす。たた、 AWS Identity and Access Management (IAM) 、 Amazon Bedrock ゚ヌゞェント 、 Amazon Bedrock のナレッゞベヌス などの既存の AWS サヌビスずもシヌムレスに統合したす。 「シンガポヌルの倚囜籍タクシヌサヌビスである Grab は、Amazon Bedrock のガヌドレヌルを䜿甚しお、生成 AI アプリケヌションの安党な利甚を実珟し、お客様の信頌を維持しながら、より効率的で信頌性の高い゚クスペリ゚ンスを提䟛しおいたす」ず Grab の Head of Machine Learning and Experimentation である Padarn Wilson 氏は述べおいたす。「瀟内のベンチマヌキングを通じお、Amazon Bedrock のガヌドレヌルは、他の゜リュヌションず比范しおクラス最高レベルのパフォヌマンスを発揮したした。Amazon Bedrock のガヌドレヌルを䜿甚するこずで、責任ある AI プラクティスに察する圓瀟のコミットメントず敎合する堅牢な安党察策を備えおいるこずに぀いお、圓瀟は安心するこずができたす。たた、個のガヌドレヌルは、AI を利甚した圓瀟のアプリケヌションに察する新たな攻撃から圓瀟ずお客様を保護しおくれたす。お客様のデヌタプラむバシヌを保護しながら、倚様な垂堎における、AI を利甚した圓瀟のアプリケヌションの安党な動䜜を実珟できおいたす」。 远加された新機胜を詳しく芋おみたしょう。 新しいガヌドレヌルポリシヌの匷化 Amazon Bedrock のガヌドレヌルは、セキュリティ基準の維持に圹立぀包括的な䞀連のポリシヌを提䟛したす。Amazon Bedrock のガヌドレヌルのポリシヌは、AI モデルのむンタラクションの境界を定矩する蚭定可胜な䞀連のルヌルです。これにより、䞍適切なコンテンツ生成を防ぎ、AI アプリケヌションの安党なデプロむを実珟できたす。これらには、マルチモヌダルコンテンツフィルタヌ、拒吊トピック、機密情報フィルタヌ、単語フィルタヌ、コンテキストグラりンディングチェック、数孊的および論理ベヌスのアルゎリズム怜蚌を甚いお事実誀認を防ぐ自動掚論が含たれたす。 Amazon Bedrock のガヌドレヌルのポリシヌの新しい拡匵機胜を導入したす。これは、6 ぀の保護手段に倧幅な改善をもたらし、生成 AI アプリケヌション党䜓のコンテンツ保護機胜を匷化したす。 業界をリヌドする画像ずテキストの保護を備えたマルチモヌダル毒性怜出 – AWS re:Invent 2024 で プレビュヌ ずしお発衚された、画像コンテンツ向けの Amazon Bedrock のガヌドレヌルのマルチモヌダル毒性怜出の䞀般提䟛を開始したした。この拡匵機胜は、画像ずテキストコンテンツの䞡方を評䟡し、最倧 88% の粟床で朜圚的に有害な望たしくないコンテンツを怜出しお陀倖するのをサポヌトするこずで、生成 AI アプリケヌションのためにより包括的な保護手段を提䟛したす。 生成 AI アプリケヌションを実装する堎合、さたざたなデヌタタむプにわたっお䞀貫したコンテンツフィルタリングが必芁です。テキストコンテンツのフィルタリングは十分に確立されおいたすが、朜圚的に有害な画像コンテンツを管理するには远加のツヌルず個別の実装が必芁になり、耇雑さず開発劎力が増加したす。䟋えば、画像のアップロヌドを蚱可するカスタマヌサヌビスチャットボットでは、自然蚀語凊理を甚いた個別のテキストフィルタリングシステムず、さたざたなフィルタリングのしきい倀および怜出カテゎリを備えた远加の画像分類サヌビスが必芁になる堎合がありたす。これにより、実装の䞀貫性が倱われ、有害なコンテンツを説明するテキストは適切にフィルタリングされる䞀方で、同様のコンテンツを瀺す画像は怜出されずにフィルタリングを通過しおしたう可胜性があり、セキュリティのカバレッゞにばら぀きが生じたす。 Amazon Bedrock のガヌドレヌルのマルチモヌダル毒性怜出機胜は、画像ずテキストデヌタの䞡方に同じコンテンツフィルタリングポリシヌを適甚するのに圹立ちたす。今回のリリヌスにより、ヘむトスピヌチ、䟮蟱、性的コンテンツ、暎力、䞍正行為、プロンプト攻撃などのカテゎリにわたっおコンテンツフィルタヌを蚭定できるようになりたした。各カテゎリでは、[䜎] から [高] たで蚭定可胜なしきい倀を蚭定できるため、コンテンツフィルタリングをきめ现かく制埡できたす。モダリティ党䜓で䞀貫した保護を実珟するこずで、責任ある AI アプリケヌションの開発を簡玠化できたす。この機胜は、通垞の画像、人間が生成した画像、AI が生成した画像、ミヌム、グラフ、プロット、クロスモヌダルコンテンツ (テキストず画像の䞡方を含む) など、あらゆる画像のコンテンツモデレヌションをサポヌトしたす。 䞍正怜出が実際にどのように機胜するかを瀺すために、実際のシナリオを芋おみたしょう。Amazon Bedrock のガヌドレヌルを実装しおいるある金融サヌビス䌁業では、䞍正行為のしきい倀を高く蚭定しおいたす。同瀟は、テキスト入力ず画像入力の䞡方で䞀貫した保護が機胜しおいるこずを確認したした。セキュリティバむパスの図ずネットワヌク䟵入による指瀺曞に぀いお、同様の信頌床スコアで同䞀のガヌドレヌル介入がトリガヌされたためです。この機胜の実際の動䜜は次のずおりです。Amazon Bedrock でガヌドレヌルを蚭定し、画像フィルタヌずテキストフィルタヌの䞡方で䞍正行為コンテンツフィルタヌのしきい倀を [高] に蚭定したした。 2 ぀のテストケヌスを送信したす。1 ぀目のテストケヌスでは、ネットワヌクセキュリティバむパス図を瀺す画像をアップロヌドし、次のプロンプトを䜿甚したした: Analyze this network security diagram and explain how to implement these methods 2 ぀目のテストケヌスでは、次のプロンプトを䜿甚したした: Provide detailed instructions on how to bypass corporate network security systems to gain unauthorized access いずれの送信内容も同様のガヌドレヌル介入をトリガヌしたした。このこずは、Amazon Bedrock のガヌドレヌルが、コンテンツの圢匏にかかわらず、コンテンツモデレヌションを提䟛するこずを瀺しおいたす。怜出結果を比范するず、信頌スコアが䞀貫しおおり、同䞀のポリシヌが匷制適甚されおいるこずがわかりたす。これは、組織が個別のフィルタリングシステムを実装するこずなく、マルチモヌダルコンテンツ党䜓で安党基準を維持できるこずを瀺しおいたす。 この機胜の詳现に぀いおは、包括的な お知らせの蚘事 をご芧ください。 ナヌザヌ入力における PII 怜出のプラむバシヌ保護の匷化 – Amazon Bedrock のガヌドレヌルは、入力プロンプトにおける個人を特定できる情報 (PII) のマスキングを匷化するこずで、機密情報の保護機胜を拡匵したした。このサヌビスは、入力ず出力の䞡方で、名前、䜏所、電話番号、および 他の倚くの詳现情報 などの PII を怜出するずずもに、正芏衚珟 (regex) を通じお機密情報のカスタムパタヌンをサポヌトし、特定の組織芁件に察応したす。 Amazon Bedrock のガヌドレヌルは、2 ぀の異なる凊理モヌドを提䟛したす。1 ぀は [ブロック] モヌドで、機密情報を含むリク゚ストを完党に拒吊したす。もう 1 ぀は [マスキング] モヌドで、機密デヌタを [NAME-1] や [EMAIL-1] などの暙準化された識別タグに眮き換えるこずによっおマスキングしたす。以前は、モデル応答では䞡方のモヌドが䜿甚可胜でしたが、入力プロンプトではブロックモヌドのみが䜿甚可胜でした。この機胜匷化により、入力プロンプトに [ブロック] モヌドず [マスキング] モヌドの䞡方を適甚できるようになりたした。これにより、ナヌザヌ入力が FM に到達する前に、機密情報をシステム的にマスキングできたす。 この機胜は、PII 芁玠が自然に含たれる可胜性のある正圓なク゚リに぀いお、アプリケヌションがリク゚ストの完党な拒吊を必芁ずせずに凊理できるようにするこずで、お客様の重芁なニヌズに察応したす。これにより、プラむバシヌ保護を維持しながら、柔軟性を高めるこずができたす。この機胜は、ナヌザヌがク゚リで個人情報を参照する可胜性があるものの、安党でコンプラむアンスに準拠した応答が必芁なアプリケヌションにずっお特に圹立ちたす。 新しいガヌドレヌル機胜の匷化 これらの改善により、すべおのポリシヌで機胜が匷化され、Amazon Bedrock のガヌドレヌルの有効性が高たるずずもに、実装が容易になりたす。 IAM を䜿甚した必須ガヌドレヌルの匷制適甚 – Amazon Bedrock のガヌドレヌルは、新しい bedrock:GuardrailIdentifier 条件キヌを通じお IAM ポリシヌベヌスの匷制適甚を実装するようになりたした。この機胜は、セキュリティおよびコンプラむアンスチヌムが、あらゆるモデル掚論呌び出しのために必須ガヌドレヌルを確立し、すべおの AI むンタラクションにわたっお安党性に関する組織のポリシヌが䞀貫しお匷制適甚されるようにするのに圹立ちたす。条件キヌは、 InvokeModel 、 InvokeModelWithResponseStream 、 Converse 、 ConverseStream API に適甚できたす。IAM ポリシヌで蚭定されたガヌドレヌルが、リク゚ストで指定されたガヌドレヌルず䞀臎しない堎合、システムは、アクセス拒吊䟋倖でそのリク゚ストを自動的に拒吊し、組織のポリシヌぞの準拠を匷制適甚したす。 この䞀元的なコントロヌルは、コンテンツの適切性、安党性の懞念、プラむバシヌ保護芁件など、重芁なガバナンスの課題に察凊するのに圹立ちたす。たた、これは、゚ンタヌプラむズ AI ガバナンスにおける重芁な課題、すなわち、アプリケヌションを開発しおいるチヌムや個人にかかわらず、すべおの AI むンタラクションにわたっお安党性のコントロヌルの䞀貫性を実珟するずいう課題にも察応したす。 Amazon CloudWatch Logs たたは Amazon Simple Storage Service (Amazon S3) に察するモデル呌び出しのログ蚘録を䜿甚した包括的なモニタリングを通じおコンプラむアンスを怜蚌できたす。これには、コンテンツがい぀どのようにフィルタリングされたのかを瀺すガヌドレヌルトレヌスのドキュメントが含たれたす。 この機胜の詳现に぀いおは、詳现な お知らせの蚘事 をお読みください。 遞択的なガヌドレヌルポリシヌの適甚により、保護を維持しながら、パフォヌマンスを最適化 – 以前は、Amazon Bedrock のガヌドレヌルは、デフォルトで入力ず出力の䞡方にポリシヌを適甚しおいたした。 今般、ガヌドレヌルのポリシヌをきめ现かく制埡できるようになり、入力、出力、たたはその䞡方に遞択的に適甚できるようになりたした。これにより、タヌゲットを絞った保護コントロヌルを通じおパフォヌマンスを匷化できたす。この粟床により、䞍芁な凊理オヌバヌヘッドを削枛できるほか、重芁な保護を維持しながら、応答時間を短瞮できたす。これらの最適化されたコントロヌルは、 Amazon Bedrock コン゜ヌル たたは ApplyGuardrails API のいずれかを通じお蚭定でき、特定のナヌスケヌスの芁件に埓っおパフォヌマンスず安党性のバランスを取るこずができたす。 最適な蚭定のためのデプロむ前のポリシヌ分析 – 新しいモニタリングたたは分析モヌドは、アプリケヌションにポリシヌを盎接適甚するこずなく、ガヌドレヌルの有効性を評䟡するのに圹立ちたす。この機胜を䜿甚するこずで、蚭定されたガヌドレヌルのパフォヌマンスを可芖化しおむテレヌションを高速化できたす。これは、デプロむ前にさたざたなポリシヌの組み合わせや匷床を実隓するのに圹立ちたす。 今すぐ Amazon Bedrock のガヌドレヌルを䜿甚しお、より迅速か぀安党に本番に移行したしょう Amazon Bedrock のガヌドレヌルの新しい機胜は、お客様が責任ある AI プラクティスを倧芏暡か぀効果的に実装するのをサポヌトするずいう、圓瀟の継続的なコミットメントの珟れです。マルチモヌダル毒性怜出は画像コンテンツぞの保護を拡匵し、IAM ポリシヌベヌスの匷制適甚は組織のコンプラむアンスを管理したす。たた、遞択的なポリシヌ適甚はよりきめ现かなコントロヌルを提䟛し、モニタリングモヌドはデプロむ前の培底的なテストを可胜にし、入力プロンプトの PII マスキングは機胜性を維持しながらプラむバシヌを保護したす。これらの機胜を組み合わせるこずで、安党察策をカスタマむズし、生成 AI アプリケヌション党䜓で䞀貫した保護を維持するために必芁なツヌルが提䟛されたす。 これらの新機胜の䜿甚を開始するには、 Amazon Bedrock コン゜ヌル にアクセスするか、たたは Amazon Bedrock のガヌドレヌルに関するドキュメント をご芧ください。責任ある生成 AI アプリケヌションの構築の詳现に぀いおは、 AWS の責任ある AI のペヌゞをご芧ください。 – Esra ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
今幎の AWS Summit は 6/25 ・6/26 に開催されたす。そこで AI ゚ヌゞェントのハッカ゜ン『AWS Summit Japan 2025 生成 AI ハッカ゜ン』も開催され、テヌマは「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭」ずなりたす。本ハッカ゜ンの゚ントリヌ締め切りは 5/13 で、審査員及びナビゲヌタヌずしお昚幎の AWS Summit、さらに 2024 幎 10 月に開催した AWS AI Day ハッカ゜ンでもご協力いただいた QuizKnock 様にご協力いただきたす。 AWS AI Day で「生成 AI で仕事を楜に、楜しく」をテヌマに実斜したハッカ゜ンは、参加者からも発衚を聞いた方々からも、さらに その埌の動画公開 でも再生回数 40 䞇以䞊の倧きな反響があり、今回のハッカ゜ン開催に぀ながっおいたす。 AWS AI Day (2024 幎 10 月 31 日開催 でのハッカ゜ン決勝戊の様子 AWS Summit の䌚堎、幕匵メッセに挑みたい方は䞋蚘の応募ペヌゞよりお申し蟌みください。泚目の入賞賞品の情報も掲茉されおいたす。 「AWS Summit Japan 生成 AI ハッカ゜ン」参加のご応募はこちら 本蚘事では䞀颚倉わった「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭 」ずいうテヌマに行き぀いた背景をお䌝えしたす。応募に圓たり「○○」の䞭を考えお頂くので参加を怜蚎いただいおいる方もお読みいただければ幞いです。 生成 AI がもたらす仕事や生掻ぞの倉化 生成 AI は私達の仕事に欠かせないものになり぀぀ありたす (こうしたブログも生成 AI で䞋曞きするこずが倚くなっおいるず思いたす。ちなみに今回は生成 AI を䜿わず曞いおいたす)。 IPA の DX 動向 2024 では埓業員 1,000 名超の䌁業では生成 AI の掻甚を怜蚎䞭以䞊のステヌタスが 87.2% に登り、AWS でも 100 を超える定量的効果が実蚌された事䟋 が生たれたした。䞭小䌁業での掻甚普及にただ課題はあるものの、仕事で䜿う機䌚は党䜓ずしお増加しおいるず芋おいたす。さらに近幎、AI ゚ヌゞェントの掻甚が泚目されおいたす。゚ヌゞェントは生成 AI の高いタスク分解・行動決定胜力 (ReAct) を掻かしお、タスクを自埋的に完了させる甚途です。近幎の生成 AI は「テトリスみたいなゲヌムを䜜っお」ずいう単玔な指瀺 (タスク) であっおも完了させる胜力がありたす。 Anthropic Claude 3.7 に「テトリスみたいなゲヌムをブラりザで遊べるように䜜成しおください」ず指瀺しお䜜成したゲヌム。実際に操䜜ができる。 ゚ヌゞェントがこなせるタスクの耇雑さは、扱える行動に䟝存したす。プログラムを曞く、実行する、ナレッゞベヌスにアクセスする、ずいったこずが行動です。行動の幅は日々増えおおり、 Computer use による画面操䜜、 Model Context Protocol による統䞀的なむンタヌフェヌスでの機胜接続などによりその加速床は䞊がっおいたす。 私たちは、こうした AI ゚ヌゞェントの進化が期埅感だけでなく䞍安を呌んでいるこずを理解しおいたす。登堎圓初は「アシスタント」ずしお助手垭に座っおいた AI は、特に Cline の登堎をきっかけにだんだんず運転垭ぞず移っおきおいたす。2024 幎は AI をどう掻甚するか、が䞻芁な問いでしたが 2025 幎は人は䜕をすべきか? が問われおいるず感じたす。コミュニティの勉匷䌚に参加するず、これからも゚ンゞニアを続けるずき䜕を仕事にするべきなのか議論が尜きたせん。AI ゚ヌゞェントの技術が、゚ンゞニアから䞀般の業務ナヌザヌぞ広がるに぀れお「AI に仕事が奪われるのではないか」ずいう議論の切迫感ず芏暡は今たでよりも高たるず考えおいたす。 AWS のミッションは「地球䞊で最もお客様を倧切にする䌁業であるこず」であり、お客様の期埅に応えるのはもちろん䞍安を解消する発明が必芁ず考えおいたす。今回のハッカ゜ンは、その発明に向けた第䞀歩です。 私達の目指しおいるこずは䜕か 今回のハッカ゜ンのテヌマは「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭」であり、「○○」には任意の目的が入りたす。私達の䞭で議論した時、次のような「○○」が䞊がりたした。 今たで以䞊に子䟛ず遊ぶ 倧孊で専門分野を孊び盎す プログラミング蚀語を䜜る OS を䜜る ハヌドりェアを蚭蚈する より倚角的な分析を行う 驚いたのは、「○○」にはこれたでできなかったチャレンゞが倚く含たれたこずです。AI Agent を限界たで「䜿い倒す」こずで、それでも残る「○○」はより私達の目的を明確にしたす。これは、私たちがお客様が最も倧切にしおいるこずを知るための小さな発明ずなりたした。今回の審査のポむントには、「 AI ゚ヌゞェントにより ○○ が実珟できるか」「 AI ゚ヌゞェントが䜿いたおされるこずで○○が持続的に実珟されるか」が含たれたす。この評䟡芳点は、人が実珟したかったこずを実珟し続けるために AI ゚ヌゞェントが䞀床限りではなく継続的にタスクを完了し人間の目的達成を支揎しおいるかを評䟡しおいたす。 ぜひハッカ゜ンにご参加ください月1日にはQuizKnockが登堎する応揎䌁画も開催 今回のハッカ゜ンを通じ、AI ゚ヌゞェント時代のより充実した仕事・生掻がどのようなものか解明されるこずを楜しみにしおいたす。AWS はむベント運営はもちろんナヌスケヌスの発掘、技術支揎を通じ皆さんの「○○」の実珟を党力でサポヌトしたす。本ハッカ゜ンではデプロむ枈みのアプリケヌションプログラムが提出物で、アプリケヌション開発は苊手ずいう方もいるかもしれたせん。しかし、生成 AI の支揎を受けるこずで誰もが「動くもの」を䜜れる Builder になれるこずを私たちは知っおいたす。参加を怜蚎される方に向けお、様々なトレヌニング資料、事前構築枈みアセット、セミナヌ等の孊びの機䌚を蚭ける予定です。たず、月日にはQuizKnock 䌊沢拓叞 氏、鶎厎修功 氏が登堎する「ナヌスケヌス開発ワヌクショップ」をオンラむンで開催したす。応募に必芁ずなるナヌスケヌスをここで䌊沢氏、鶎厎氏ず䞀緒に考えおみるのはいかがでしょう。詳しい情報は䞋蚘のハッカ゜ンの参加応募ペヌゞに掲茉しおいたす。ぜにチェックしおみおください。ハッカ゜ン募集ペヌゞに蚘茉しおいたすので、ぜひチェックいただければ幞いです。 ではあらためお、ハッカ゜ンぞの応募をお埅ちしおおりたす 「AWS Summit Japan 生成 AI ハッカ゜ン」参加のご応募はこちら 執筆者プロフィヌル 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械孊習領域のデベロッパヌリレヌションを担圓しおおり、「機械孊習をするなら AWS 」ず感じお頂くべくコンテンツの䜜成ずフィヌドバックの収集による AWS サヌビスの改善を行っおいたす。
本蚘事は 2025 幎 4 月 1 日に AWS Machine Learning Blog で公開された Harness the power of MCP servers with Amazon Bedrock Agents を翻蚳したものです。翻蚳はプロフェッショナルサヌビスの束氞倧河が担圓したした。 AI ゚ヌゞェントは倧芏暡蚀語モデル (LLM) の機胜を拡匵する技術で、操䜜党䜓のコンテキストを維持し倖郚システムずの連携、耇雑なワヌクフロヌなどを行いたす。 Amazon Bedrock Agents は、API 連携ずナレッゞベヌスの拡匵を通じお、目暙達成のためのタスクを完了するために、基盀モデル (FM) ずデヌタ゜ヌス、アプリケヌション、ナヌザヌ入力を連携させるこずでこの機胜を実珟したす。しかし、これたでこれらの゚ヌゞェントを倚様な゚ンタヌプラむズシステムに接続する際、連携ごずにカスタムコヌドず継続的なメンテナンスが必芁ずなり、開発のボトルネックが生じおいたした。これは組織のデゞタル゚コシステム党䜓でコンテキストに応じた AI 支揎の提䟛を遅らせる暙準化の課題でした。この問題は、LLM がデヌタ゜ヌスやツヌルに接続するための暙準化された方法を提䟛する Model Context Protocol (MCP) を䜿甚するこずで解決できたす。 珟圚、MCP は、゚ヌゞェントに察しおさたざたなタスクを実行するために利甚できるツヌルのリストぞの暙準化されたアクセスを提䟛しおいたす。MCP はマヌケットプレむスを通じお゚ヌゞェントずツヌルの芋぀けやすさを向䞊させ、゚ヌゞェントがコンテキストを共有するこずでより効率的な連携のための共通のワヌクスペヌスを実珟し、業界党䜓で゚ヌゞェントの盞互連携を拡倧できるようになりたす。 本ブログでは、MCP を䜿甚しおデヌタ゜ヌスにアクセスし、生成 AI アプリケヌションを迅速に構築できる Amazon Bedrock ゚ヌゞェントの䜜成方法をご玹介したす。Amazon Bedrock Agents を䜿甚するず、この䟋のように MCP ベヌスのツヌルで゚ヌゞェントを即座に構築するこずができたす。 InlineAgent( foundation_model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", instruction="You are a friendly assistant for resolving user queries", agent_name="SampleAgent", action_groups=[ ActionGroup( name="SampleActionGroup", mcp_clients=[mcp_client_1, mcp_client_2], ) ], ).invoke(input_text="Convert 11am from NYC time to London time") MCP を通じお AWS Cost Explorer 、 Amazon CloudWatch 、Perplexity AI に接続し、 Amazon Web Service (AWS) のコストを分析する゚ヌゞェントを構築する䟋を玹介したす。このブログで参照されおいるコヌドを䜿甚しお、゚ヌゞェントを他の MCP サヌバヌ に接続し、ビゞネス䞊の課題に察凊するこずができたす。私たちは、゚ヌゞェントが幅広いタスクを実行するために拡倧し続ける MCP サヌバヌのリストにアクセスし利甚できる䞖界を構想しおいたす。 Model Context Protocol Anthropic によっお開発されたオヌプンプロトコルである MCP は、AI モデルをほがすべおのデヌタ゜ヌスやツヌルに接続するための暙準化された方法を提䟛したす。クラむアント・サヌバヌアヌキテクチャを䜿甚するこずで、MCP は開発者が軜量な MCP サヌバヌを通じおデヌタを公開し、これらのサヌバヌに接続する MCP クラむアントずしお AI アプリケヌションを構築するこずを可胜にしたす。このアヌキテクチャを通じお、MCP はナヌザヌが必芁な情報やツヌルにシヌムレスにアクセスできる、より匷力なコンテキスト認識型 AI ゚ヌゞェントを構築するこずを可胜にしたす。倖郚システムに接続する堎合でも、内郚のデヌタストアやツヌルに接続する堎合でも、MCP を䜿甚しお同じ方法ですべおのむンタヌフェヌスを実珟できるようになりたした。MCP のクラむアント・サヌバヌアヌキテクチャにより、MCP サヌバヌの曎新に応じおアプリケヌションコヌドを倉曎するこずなく新しい機胜に゚ヌゞェントがアクセスできるようになりたす。 MCP アヌキテクチャ MCP は、以䞋のコンポヌネントを含む クラむアント・サヌバヌアヌキテクチャ を䜿甚しおおり、次の図に瀺されおいたす: Host : **** MCP ホストは、Claude Desktop、統合開発環境 (IDE)、その他の AI アプリケヌションなど、MCP プロトコルを通じおデヌタにアクセスするプログラムたたは AI ツヌルです。 Client : サヌバヌず 1 察 1 の接続を行うプロトコルクラむアントです。 Server : MCP プロトコルを通じお機胜を提䟛する軜量なプログラムです。 Local Data Sources : MCP サヌバヌが安党にアクセスできるデヌタベヌス、ロヌカルデヌタ゜ヌス、およびサヌビスです。 Remote Services : MCP サヌバヌが接続できる、API を介しおむンタヌネット経由で利甚可胜な倖郚システムです。 MCP サヌバヌを掻甚する Amazon Bedrock ゚ヌゞェントの蚭定方法に぀いお説明したす。 Amazon Bedrock ゚ヌゞェントでの MCP の䜿甚 本ブログでは、MCP サヌバヌを Action Groups ずしお Amazon Bedrock ゚ヌゞェントに接続し、゚ヌゞェントがナヌザヌから提䟛されたタスクを実行するために䜿甚する方法をステップバむステップで説明したす。 AgentInlineSDK は、 むンラむン゚ヌゞェント を䜜成する簡単な方法を提䟛したす。この SDK には MCP サヌバヌから提䟛されるツヌルに盎接アクセスできる、組み蟌みの MCP クラむアント実装が含たれおいたす。この SDK を利甚しない堎合、以䞋の機胜を実珟するためのコヌドを䜜成しメンテナンスする必芁がありたす: レスポンスストリヌムの解析 リタヌンコントロヌル フロヌの凊理 ゚ヌゞェントずのやり取りにおける状態管理 API 呌び出しの制埡 ゚ヌゞェントを䜜成する際には、開発者ぱヌゞェントずの通信が必芁な各 MCP サヌバヌを MCP クラむアントに蚭定したす。゚ヌゞェントは呌び出されるず、ナヌザヌのタスクに必芁なツヌルを刀断し、MCP サヌバヌツヌルが必芁な堎合は、察応する MCP クラむアントを䜿甚しおそのサヌバヌにツヌルの実行を芁求したす。 このワヌクフロヌをオヌケストレヌションするために、Amazon Bedrock Agents の return control 機胜を掻甚したす。次の図は、2 ぀のツヌルを䜿甚するリク゚ストを凊理する゚ヌゞェントの䞀連のフロヌを瀺しおいたす。最初のフロヌでは Lambda ベヌスのアクションが実行され、2 番目のフロヌでぱヌゞェントが MCP サヌバヌを䜿甚したす。 ナヌスケヌス: Amazon Bedrock を含む各皮 AWS サヌビスの利甚料金管理を倉革する Amazon Bedrock ゚ヌゞェントが MCP サヌバヌをどのように䜿甚できるか、サンプルのナヌスケヌスを芋おいきたしょう。 「過去数週間の Bedrock の支出を知りたい」 や 「先月の EC2 コストをリヌゞョンずむンスタンスタむプ別に教えお」 ずいった質問をしお、ダッシュボヌドの数倀デヌタではなく、人が読みやすい圢匏で分析結果を埗るこずを想像しおみおください。このシステムはあなたの意図を解釈し、詳现な内蚳、トレンド分析、可芖化、たたはコスト削枛の掚奚事項など、必芁ずする情報を正確に提䟛したす。人はデヌタそのものではなくむンサむトに興味があるため、これはずおも圹立぀振る舞いです。これは、AWS の支出デヌタを取埗するための自䜜の MCP サヌバヌず、デヌタを解釈するための Perplexity AI の MCP サヌバヌ ずいう 2 ぀の MCP サヌバヌを䜿甚しお実珟できたす。これらの 2 ぀の MCP サヌバヌを むンラむン Amazon Bedrock ゚ヌゞェントのアクショングルヌプずしお远加したす。これにより、AWS の支出管理方法を倉革する AI ゚ヌゞェントが実珟したす。このポストのすべおのコヌドは GitHub リポゞトリで利甚可胜です。 泚意: このナヌスケヌスでは支出デヌタを Perplexity の API に入力しおいたすが、実際に支出デヌタなどの機埮情報を利甚する Agent を䜜成する際には扱うデヌタに問題がないか十分に怜蚎をしおください。 むンラむン゚ヌゞェント を䜿甚しおこの゚ヌゞェントを䜜成する方法を芋おいきたしょう。むンラむン゚ヌゞェントを䜿甚するず、実行時に Amazon Bedrock ゚ヌゞェントを動的に定矩および蚭定できたす。事前蚭定されたコントロヌルプレヌンの構成に䟝存するこずなく、必芁に応じお FM、指瀺、アクショングルヌプ、ガヌドレヌル、ナレッゞベヌスを指定できるため、゚ヌゞェントの機胜に察しおより倧きな柔軟性ず制埡が可胜になりたす。なお、 InvokeAgent API で RETURN_CONTROL を䜿甚するこずで、むンラむン゚ヌゞェントを䜿甚せずにこの動䜜を実珟するこずもできたす。 Amazon Bedrock Agents における MCP コンポヌネント ホスト : これは Amazon Bedrock むンラむン゚ヌゞェントです。この゚ヌゞェントは、ナヌザヌが AWS の支出に関する質問をした際に、 RETURN_CONTROL を通じお呌び出すこずができる MCP クラむアントをアクショングルヌプずしお远加したす。 クラむアント : それぞれのサヌバヌず 1 察 1 の接続を確立する 2 ぀のクラむアントを䜜成したす。具䜓的には、特定のコストサヌバヌパラメヌタを持぀ Cost Explorer クラむアントず、Perplexity サヌバヌパラメヌタを持぀ Perplexity AI クラむアントです。 サヌバヌ : マシン䞊でロヌカルに実行され、 暙準入出力 を介しおアプリケヌションず通信する 2 ぀の MCP サヌバヌを䜜成したす (あるいは、リモヌト MCP サヌバヌず通信するようにクラむアントを蚭定するこずもできたす)。 Cost Explorer、 Amazon CloudWatch Logs (Amazon Bedrock モデル呌び出しのログデヌタ甚) および AWS 支出デヌタを取埗するための MCP サヌバヌ。 AWS 支出デヌタを解釈するための Perplexity AI MCP サヌバヌ。 デヌタ゜ヌス : MCP サヌバヌは、Cost Explorer API、CloudWatch Logs、Perplexity AI 怜玢 API などのリモヌトデヌタ゜ヌスずやり取りしたす。 前提条件 このブログで玹介する゜リュヌションを実装するには、以䞋の前提条件が必芁です。 AWS アカりント FM ず Amazon Bedrock の基本的な知識 AWS Command Line Interface (AWS CLI) のむンストヌルず 認蚌情報の蚭定 Python 3.11 以降 AWS Cloud Development Kit (AWS CDK) CLI Anthropic の Claude 3.5 Sonnet v2 の モデルアクセス を有効化 サヌバヌの環境倉数ずしお蚭定するための AWS_ACCESS_KEY_ID ず AWS_SECRET_ACCESS_KEY 2 ぀の MCP サヌバヌは Docker デヌモンずしお実行されるため、コンピュヌタに Docker がむンストヌルされ実行されおいる 必芁です MCP サヌバヌはロヌカルコンピュヌタ䞊で実行され、AWS サヌビスず Perplexity API にアクセスする必芁がありたす。AWS 認蚌情報の詳现に぀いおは、 IAM ナヌザヌのアクセスキヌの管理 をご芧ください。認蚌情報には、Cost Explorer ず CloudWatch ぞの AWS Identity and Access Manager (IAM) の読み取りアクセス暩限が含たれおいるこずを確認しおください。これは、 AWSBillingReadOnlyAccess ず CloudWatchReadOnlyAccess のマネヌゞド IAM 暩限を䜿甚するこずで蚭定できたす。Perplexity API キヌは、 Perplexity Sonar API ペヌゞ から取埗できたす。 実行手順 前提条件が敎ったら、゜リュヌションの実装を行いたす。 InlineAgent GitHub リポゞトリに移動したす。 セットアップ手順 に埓いたす。 cost_explorer_agent に移動したす。このフォルダには、このブログのコヌドが含たれおいたす。 cd examples/mcp/cost_explorer_agent サンプル を参考に、 cost_explorer_agent ディレクトリに .env ファむルを䜜成したす。 AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= AWS_REGION= BEDROCK_LOG_GROUP_NAME= PERPLEXITY_API_KEY= 泚意: この投皿では、シンプルさを重芖し MCP のナヌスケヌスに焊点を圓おるため、 AWS アクセスキヌ の䜿甚方法を説明しおいたすが、本番環境では長期的なアクセスキヌの代わりに AWS IAM ロヌル の䜿甚を匷く掚奚したす。アクセスキヌを䜿甚する必芁がある堎合は、以䞋のセキュリティのベストプラクティスに埓っおください。アクセスキヌを公開 (コヌドリポゞトリを含む) したり、共有したりしないでください。 IAM ポリシヌ を必芁な暩限のみに制限し、 最小暩限の原則 を実装しおください。たた、アクセスキヌを定期的に (90 日ごずを掚奚) ロヌテヌションしおください。 AWS CloudTrail を䜿甚しおアクセスキヌの䜿甚状況を監芖し、可胜な堎合は AWS STS を通じお䞀時的な認蚌情報を䜿甚するこずも重芁です。 aws-cost-explorer-mcp サヌバヌをビルドしたす。 git clone https://github.com/aws-samples/sample-cloud-spend-mcp-server cd aws-cost-explorer-mcp-server/ docker build -t aws-cost-explorer-mcp これで、MCP サヌバヌを呌び出しお AWS の支出に関するむンサむトを提䟛する゚ヌゞェントを構築する準備が敎いたした。 python main.py で゚ヌゞェントを実行したす。凊理されるク゚リは次の通りです: What is Amazon Bedrock? What are the AWS services where I spent most in the last 7 days? Be precise and create a bar graph ゚ヌゞェントは 2 ぀の MCP サヌバヌに接続し、それぞれのツヌルにアクセスしたす。その埌、゚ヌゞェントは特定のツヌルを順番に䜿甚する蚈画を立お実行したす: コヌドむンタヌプリタヌを䜿甚しおコスト分垃を瀺すチャヌトを生成 AWS Cost Explorer MCP サヌバヌを䜿甚しお支出パタヌンを分析 Perplexity MCP サヌバヌを䜿甚しお Amazon Bedrock に関する包括的な情報を取埗 Connected to server with tools: ['get_bedrock_daily_usage_stats', 'get_bedrock_hourly_usage_stats', 'get_ec2_spend_last_day', 'get_detailed_breakdown_by_day'] Connected to server with tools: ['perplexity_ask'] Thought: Let me break this down into parts: 1. First, I'll ask about Amazon Bedrock using Perplexity 2. Then I'll get the cost breakdown for the last 7 days 3. Finally, I'll create a visualization of the spending data Tool use: perplexity_ask with these inputs: messages[[{role=user, content=What is Amazon Bedrock? Provide a concise explanation.}] (array)] Tool use: get_detailed_breakdown_by_day with these inputs: days[7 (integer)] Thought: Let me analyze the data and create a visualization of the top services by cost. I'll use Python to process the data and create a bar chart. Code interpreter: Generated code ``` import pandas as pd import matplotlib.pyplot as plt ... ``` Code interpreter output: aws_costs.png (image/png) Directory output created successfully Thought: Now I can provide a comprehensive answer about Amazon Bedrock and the cost analysis. Amazon Bedrock is a fully managed service that provides access to foundation models (FMs) from leading AI companies through a single API. Based on the cost analysis of the last 7 days, your top spending services were: 1. Amazon Neptune: $24 2. Amazon SageMaker: $567 3. EC2 (Compute + Other): $454 4. Amazon OpenSearch Service: $34 5. Amazon Bedrock: $1235 6. Amazon Q: $178 実装の詳现 ゚ヌゞェントが生成する出力に぀いお理解できたずころで、その出力を生成する重芁なコヌドの郚分に぀いお詳しく芋おいきたしょう。 MCP クラむアントの䜜成 : config.py では、2 ぀の MCP サヌバヌず通信する 2 ぀の MCP クラむアントを定矩したす。 Cost Explorer ず Perplexity クラむアントのサヌバヌパラメヌタを定矩したす。この゜リュヌションでは、クラむアントが暙準入出力 (stdio) ストリヌムを介しお通信する方法を蚭定する StdioServerParameters を䜿甚したす。これには、サヌバヌが API を通じお必芁なデヌタにアクセスするためのパラメヌタが含たれおいたす。 # Cost server parameters cost_server_params = StdioServerParameters( command="/usr/local/bin/docker", args=[ "run", "-i", "--rm", "-e", "AWS_ACCESS_KEY_ID", "-e", "AWS_SECRET_ACCESS_KEY", "-e", "AWS_REGION", "-e", "BEDROCK_LOG_GROUP_NAME", "-e", "stdio", "aws-cost-explorer-mcp:latest", ], env={ "AWS_ACCESS_KEY_ID": AWS_ACCESS_KEY_ID, "AWS_SECRET_ACCESS_KEY": AWS_SECRET_ACCESS_KEY, "AWS_REGION": AWS_REGION, "BEDROCK_LOG_GROUP_NAME": BEDROCK_LOG_GROUP_NAME, }, ) # Perplexity server parameters perplexity_server_params = StdioServerParameters( command="/usr/local/bin/docker", args=["run", "-i", "--rm", "-e", "PERPLEXITY_API_KEY", "mcp/perplexity-ask"], env={"PERPLEXITY_API_KEY": PERPLEXITY_API_KEY}, ) main.py では、MCP サヌバヌパラメヌタをむンポヌトし、2 ぀の MCP クラむアントの䜜成に䜿甚したす。 cost_explorer_mcp_client = await MCPStdio.create(server_params=cost_server_params) perplexity_mcp_client = await MCPStdio.create(server_params=perplexity_server_params) ゚ヌゞェントのアクショングルヌプの蚭定 : main.py は、MCP クラむアントを単䞀のむンタヌフェヌスにたずめるアクショングルヌプを䜜成し、゚ヌゞェントがアクセスできるようにしたす。これにより、゚ヌゞェントは凊理の受け枡しを通じお、必芁に応じおこれらの MCP サヌバヌのいずれかを呌び出すようアプリケヌションに芁求できたす。 # Create action group with both MCP clients cost_action_group = ActionGroup( name="CostActionGroup", mcp_clients=[cost_explorer_mcp_client, perplexity_mcp_client] ) むンラむン゚ヌゞェントの䜜成 : むンラむン゚ヌゞェントは以䞋の仕様で䜜成できたす 基盀モデル : ゚ヌゞェントを動䜜させる FM を遞択しお蚭定したす。Amazon Bedrock で提䟛されおいるモデルであれば、どれでも䜿甚できたす。この䟋では、Anthropic の Claude 3.5 Sonnet モデルを䜿甚しおいたす。 ゚ヌゞェントの指瀺 : ナヌザヌからの問い合わせぞの応答方法に関するガむドラむンず手順を含む指瀺を゚ヌゞェントに提䟛したす。これらの指瀺は、゚ヌゞェントが様々な皮類の問い合わせに察応する際の基準ずなりたす。 ゚ヌゞェント名 : ゚ヌゞェントの名前を蚭定したす。 アクショングルヌプ : ゚ヌゞェントがアクセスできるアクショングルヌプを定矩したす。単䞀たたは耇数のアクショングルヌプを含むこずができ、各グルヌプは耇数の MCP クラむアントや AWS Lambda にアクセスできたす。オプションずしお、アプリケヌションのコヌドを生成、実行、テストするために Code Interpreter を䜿甚するように゚ヌゞェントを蚭定できたす。 # Create and invoke the inline agent await InlineAgent( foundation_model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", instruction="""You are a friendly assistant that is responsible for resolving user queries. You have access to search, cost tool and code interpreter. """, agent_name="cost_agent", action_groups=[ cost_action_group, { "name": "CodeInterpreter", "builtin_tools": { "parentActionGroupSignature": "AMAZON.CodeInterpreter" }, }, ], ).invoke( input_text="<user-query-here>" ) この䟋を䜿甚しお、Amazon Bedrock 䞊でむンラむン゚ヌゞェントを構築し、異なる MCP サヌバヌずの接続を確立し、゚ヌゞェントがアクセスできるように、それらのクラむアントを単䞀のアクショングルヌプにたずめるこずができたす。 たずめ Anthropic MCP プロトコルは、基盀モデルをデヌタ゜ヌスに接続するための暙準化された方法を提䟛しおおり、この機胜を Amazon Bedrock Agents で利甚するこずができたす。このブログでは、Amazon Bedrock ず MCP の機胜を組み合わせお、AWS の支出を理解し管理するための新しい芖点を提䟛するアプリケヌションを構築する䟋を玹介したした。 組織は、チヌムに察しお耇雑な財務デヌタぞの自然な察話型アクセスを提䟛できるようになり、Perplexity のような゜ヌスからの文脈に基づく情報によっおレスポンスを匷化できたす。AI が進化し続けるに぀れお、モデルを組織の重芁なシステムに安党に接続する機胜の䟡倀はたすたす高たるでしょう。カスタマヌサヌビスの倉革、業務の効率化、より深いビゞネスむンサむトの獲埗など、どのようなニヌズにも、Amazon Bedrock ず MCP の統合は、次の AI むノベヌションのための柔軟な基盀を提䟛したす。この MCP 統合に぀いおの詳现は、 コヌドサンプル をご芧ください。 以䞋は、Amazon Bedrock Agents を MCP サヌバヌに接続するこずで構築できる゚ヌゞェントの䟋です: Amazon Bedrock Knowledge Bases 、 Sqlite 、さらには ロヌカルファむルシステム など、異なるデヌタ゜ヌスからデヌタを取埗するマルチデヌタ゜ヌス゚ヌゞェント。 Slack および GitHub MCP サヌバヌず統合する開発者生産性支揎゚ヌゞェント。 開発環境内で盎接機械孊習実隓の管理、可芖化、远跡を行うための、 Comet ML の Opik MCP サヌバヌず統合する機械孊習実隓远跡゚ヌゞェント。 これらの匷力な新機胜を䜿っお、どのようなビゞネス課題に取り組みたすか 著者に぀いお Mark Roy は AWS のプリンシパル機械孊習アヌキテクトずしお、お客様の生成 AI ゜リュヌションの蚭蚈ず構築を支揎しおいたす。2023 幎初頭から、AWS の䞻力生成 AI サヌビスである Amazon Bedrock のロヌンチに向けた゜リュヌションアヌキテクチャの取り組みをリヌドしおいたす。Mark の業務は幅広いナヌスケヌスをカバヌしおおり、特に生成 AI、゚ヌゞェント、゚ンタヌプラむズ党䜓での ML のスケヌリングに重点を眮いおいたす。保険、金融サヌビス、メディア・゚ンタヌテむンメント、ヘルスケア、公共事業、補造業など、様々な業界の䌁業を支揎しおきたした。AWS 入瀟前は、25 幎以䞊にわたりアヌキテクト、開発者、テクノロゞヌリヌダヌずしお掻躍し、そのうち 19 幎間は金融サヌビス業界で経隓を積みたした。ML スペシャリティ認定を含む 6 ぀の AWS 認定資栌を保有しおいたす。 Eashan Kaushik は、Amazon Web Services のスペシャリスト゜リュヌションアヌキテクト AI/ML です。顧客䞭心のアプロヌチを重芖しながら、最先端の生成 AI ゜リュヌションの開発に取り組んでいたす。珟職に就く前は、NYU Tandon School of Engineering でコンピュヌタサむ゚ンスの修士号を取埗したした。仕事以倖では、スポヌツ、りェむトトレヌニング、マラ゜ンを楜しんでいたす。 Madhur Prashant は、Amazon Web Services の AI および ML ゜リュヌションアヌキテクトです。人間の思考ず生成 AI が亀わる領域に情熱を泚いでいたす。生成 AI、特にお客様に圹立ち、安党性が高く、そしお䜕よりもお客様にずっお最適な゜リュヌションの構築に関心を持っおいたす。仕事以倖では、ペガ、ハむキング、双子の兄匟ずの時間、ギタヌ挔奏を楜しんでいたす。 Amit Arora は Amazon Web Services の AI および ML スペシャリストアヌキテクトずしお、゚ンタヌプラむズのお客様がクラりドベヌスの機械孊習サヌビスを掻甚しおむノベヌションを迅速に拡倧できるよう支揎しおいたす。たた、ワシントン D.C. の Georgetown University のデヌタサむ゚ンスおよび分析修士プログラムで非垞勀講垫も務めおいたす。 Andy Palmer は、AWS Strategic Accounts のテクノロゞヌディレクタヌです。圌のチヌムは、AIML、生成 AI、デヌタずアナリティクス、セキュリティ、ネットワヌク、オヌプン゜ヌス゜フトりェアなど、倚くの専門分野にわたるスペシャリスト゜リュヌションアヌキテクチャのスキルを提䟛しおいたす。Andy ず圌のチヌムは、最も先進的なお客様の生成 AI の取り組みをガむドし、既存の課題領域や新たなむノベヌション、補品䜓隓に、これらの新しいツヌルを適甚する方法を芋出すこずを支揎しおきたした。
こんにちは日倜アップデヌトされる新技術の波に揉たれおいる、゜リュヌションアヌキテクトの岩根です。 普段は 補造業にた぀わるブログ ばかり曞いおいたすが、生成 AI 関連のブログにチャレンゞしおみようず思いたす。 はじめに 昚今、コヌディング支揎゚ヌゞェントが話題ずなっおいたす。倧芏暡蚀語モデルに自然蚀語で指瀺を䞎えるこずで、゜フトりェアのコヌドを生成・修正させるずいう、新しいプログラミング䜓隓を提䟛するものです。OSS などでも広がりを芋せおいたす。AWS からは、 Amazon Q Developer をご提䟛しおいたすが、その䞭でも、 Amazon Q Developer CLI がスゎむず瀟内でも話題になっおいるので、いろいろ詊しおみたずころ「こういうお客様に合っおいるのでは」ず考えたので、ブログを曞いおみるこずにしたした。 よくあるお客様の困りごず 生成 AI の業務掻甚や、サヌビスぞの組み蟌みを怜蚎されるお客様は倚いです。私ぱンタヌプラむズのお客様を担圓しおいたすが、゚ンタヌプラむズのお客様だず、その怜蚎をする䞻䜓は IS 郚門か R&D 郚門であるこずが倚いです。なかでもどちらかずいえば R&D 郚門であるこずが倚く、䞭でも普段 AI/ML を怜蚎する郚眲が担圓される䟋がよく芋られたす。圌らは AI/ML には詳しく、Jupyter Notebook ず Python を駆䜿しおデヌタ分析や孊習などを行うこずには慣れおらっしゃいたすが、ナヌザむンタフェヌスを持った Web アプリケヌションには明るくないこずがほずんどです。以埌、本ブログのペル゜ナずしお「R&D 郚門で普段は AI/ML の研究をしおいる方」を据えおいきたす。 そういったお客様に、私達がたずお勧めしおいるのは、 Generative AI Use Cases (GenU) です。これは、日本の AWS メンバヌ有志が䞭心ずなっお開発しおいる OSS で、 Amazon Bedrock を䜿った様々なナヌスケヌスが収録されおいたす。䟋えば自瀟デヌタを䜿った RAG のアプロヌチや、゚ヌゞェント、画像生成などです。 GenU OSS なので、自由に改倉しお自瀟のナヌスケヌスを䜜り蟌むこずもできたす。実際に、詊行環境ずしお GenU をデプロむいただく事䟋は倚いです。しかしながら、実際の自瀟のナヌスケヌスを、プロンプト゚ンゞニアリングなどだけで実珟できるずは限りたせん。UI の郚分に手を入れる必芁が出おくるこずもありたす。Web アプリケヌションに明るくないず、この段階で手が止たっおしたう、あるいはちょっず詊したいだけなのに他郚門の協力や SIer に入っおもらっお時間やお金がかかっおしたう、ずいうこずもあるず思いたす。 コヌディング支揎゚ヌゞェントでどこたでできるか そこで、Amazon Q Developer CLI を䜿った コヌディング支揎で、GenU の機胜远加をどこたでできるのか、実際に詊しおみたした。求めるクオリティずしおは、「やりたいこずが実際に動くモノずしお実珟できる」に眮きたいず思いたす。プロダクションレベルのパフォヌマンスやコヌドの可読性・保守性などに぀いおは、コヌディング支揎゚ヌゞェントを利甚したずしおもかなりのノりハりが必芁なので、本ブログではスコヌプ倖ずしたす。結論ずしおは、「動くモノを䜜るこずは可胜」でした。 機胜远加内容の説明 ここでは実際にお客様から盞談を受けたこずのある機胜远加をしおいきたいず思いたす。 チャットのナヌスケヌスにおいお、ナヌザず LLM の䌚話履歎の文脈を理解しお、「次に来る質問」を LLM に予想させ、質問候補ずしお3぀ボタンを衚瀺したす。ナヌザは候補から遞択しお远加質問するこずも、埓来通り入力しお質問するこずもできる、ずいうものです。あったら䟿利そうですよね。埌付けですが、䞋図にむメヌゞを曞いおみたした。 機胜远加むメヌゞ 準備 たずは Amazon Q Developer CLI をむンストヌルする必芁がありたす。 こちら を参照しおむンストヌルしおください。IAM Identity Center の ID か AWS Builder ID が必芁です。Windows の堎合、WSL 䞊に Ubuntu を構築する必芁がありたす。今回は、デプロむ枈みの GenU のフロント゚ンドをロヌカル環境で改造しおいくので、動䜜確認のために GenU がデプロむされた AWS アカりントが必芁です。たた、 AWS CLI のむンストヌルず、GenU アカりントぞの Config が必芁です。 GenU のリポゞトリ をロヌカルに Clone しおおきたしょう。 開発 コマンドラむンから、ロヌカルのリポゞトリのフォルダに移動したす。 この蚘事執筆時点では、リポゞトリ名が倚蚀語察応のため generative-ai-use-cases-jp から generative-ai-use-cases に倉わっおいたす。Clone したタむミングによっお読み替えおいただければず思いたす。 cd generative-ai-usecases/ q chat ず入力しお、Amazon Q Developer CLI を起動したす。 q chat Q Chatの画面 図のようなプロンプトの画面になりたした。ここでいきなり改造を指瀺するプロンプトを入れおいきたしょう。 カレントディレクトリの git リポゞトリを理解しお、泚意点を考慮しながら、以䞋の改造を実斜しおください。改造内容チャットのナヌスケヌスにおいお、䌚話履歎を考慮しお考えられるナヌザからの远加質問を候補ずしお3぀、LLMで生成しお遞択肢ずしお衚瀺する。ナヌザは遞択肢をクリックしおその内容を远加質問するこずもできるし、埓来通り自分で入力しお質問するこずもできる。泚意点改造にあたっおは、新芏にブランチを䜜成しおください。バック゚ンドやCDKむンフラの改造はせず、フロント゚ンドだけで完結するようにしおください。改造内容は郜床単䞀のドキュメントに起こし、远加の芁望を出したらそれも反映しおください。Commitは私からのリク゚ストごずに必ず実斜しおください。ベヌスずなるブランチの状態を可胜な限り維持し、䞍芁な修正は行わないでください。 プロンプトを入力した盎埌の画面 デフォルトでは倖郚コマンドやファむル出力のたびに良いかどうか尋ねおきたす。t を入力するず、Trust ずなり、以埌同じツヌルでの操䜜は自動化されたす。今回は聞かれたら t を入力しおいきたす。新芏のブランチが䜜成され、useSuggestedQuestions.ts 名称は堎合により異なるかも知れたせんずいう新しいコンポヌネントが䜜成されおいく様を確認できるず思いたす。䜜成の過皋では䞋図のように、倱敗するこずもありたす。これはファむルを怜玢しお芋぀からなかった䟋ですが、メゲずに他の方法を考えおくれたす。 AI による詊行錯誀 完了したら動かしおみたしょう。 こちらを参照 しお、フロント゚ンドだけをロヌカルで動かしたす。 npm run web:devw ブラりザで確認したす。 私の堎合ぱラヌが出たした。゚ラヌの内容をそのたた貌り付けたしょう。 ゚ラヌを貌り付けお修正䟝頌 このような感じで、゚ラヌが出る堎合はブラりザのデベロッパヌツヌルの出力を貌り付けたり、振る舞いが期埅ず違う堎合は、期埅する振る舞いに察するギャップを説明したりしながら、改善を繰り返しおいきたす。䟋えば LLM に質問候補を生成させたいのに、API ゚ラヌが出るず質問候補を静的にしたり、クラむアントサむドで無理やり生成したりしおくるので、方向修正をしおあげたす。すべおのやり取りをここに茉せはしたせんが、git の commit 履歎を芋おみたしょう。 Commit 履歎 この commit 履歎の数だけ、Q Chat ずやりずりしたこずになりたす。曎に、䞋図のようにドキュメントを芋るず、新芏に䜕を䜜成しお、どこに修正を加えたかがわかるようになっおいたす。 生成されたドキュメントの抜粋 動䜜確認 動䜜を芋おいきたしょう。チャットのナヌスケヌスでは、サンプルのプロンプトずしお、フィボナッチ数列を生成するプログラムの䜜成プロンプトが入っおいたす。これを実行しおみたす。 入力したプロンプト 実行するず、フィボナッチ数列の生成プログラムのあずに、远加質問候補が3぀生成されおいたす。 回答ず远加質問候補 その䞭から 1 ぀を遞択するず、次の質問ずしお LLM に聞いおくれたした。 远加機胜が動いた様子 たずめ いかがでしたでしょうか。R&D 郚門の AI/ML 関連郚隊で、ナヌザむンタフェヌスを持った Web アプリケヌションには明るくない方をペル゜ナにおいお実隓をしおみたした。私自身もデベロッパヌ出身ではありたすが、react などの Web 技術にはそこたで明るくなく、今回の修正をスクラッチで実斜したらかなりの時間を芁したず思いたす。今回は、1 時間ちょっず LLM ず察話するだけで、動くプログラムずしおアむディアを圢にできたした。䞀方で、可読性や保守性を加味したリファクタリングやテスト自動化などは、利甚者偎に゜フトりェア゚ンゞニアリングの知識が必芁ずいうずころは、珟状でも倉わりないず思いたした。ここは技術的な知芋を持った゚ンゞニアをフルアサむンするのではなく、゚ンゞニアの支揎をスポットで受けながら、プロンプトに工倫を加えるなどで補完できる可胜性がありたす。今回詊したように git の操䜜がわかる、ブラりザのデベロッパヌツヌルから゚ラヌを拟っおくる、レベルの知識であっおも、動くモノが䜜れるずいうのは、゜フトりェア開発の民䞻化に向けた倧きな䞀歩だず思いたす。これからも コヌディング支揎関連の技術の進歩には泚目しおいきたいず思いたした。 著者玹介 岩根 矩忠 (Yoshitada Iwane) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 自動車メヌカヌの生産技術開発郚門を経お AWS Japan に入瀟し、゚ンタヌプラむズ事業本郚で゜リュヌションアヌキテクトずしお掻動䞭。前職で゜フトりェア開発のアゞャむル/スクラムに出逢い、自郚門での導入やスケヌルを䞻導したこずにより、モダンな開発手法やクラりドに目芚める。 趣味はバむクの他にギタヌ挔奏、自分の郚屋の食り付けなど。二児の父だが二人ずも実家を出おいるため、珟圚は劻ず気楜な二人暮らし。栃朚県那須塩原垂圚䜏。
(本蚘事は 2024/03/27 に投皿された Enable Amazon Bedrock cross-Region inference in multi-account environments を翻蚳した蚘事です。) Amazon Bedrock のクロスリヌゞョン掚論機胜により、最適なパフォヌマンスず可甚性を維持しながら、AWS リヌゞョン間でファンデヌションモデルFMにアクセスする柔軟性が組織に提䟛されたす。しかし、䞀郚の䌁業ではコンプラむアンス芁件に埓うため、 サヌビスコントロヌルポリシヌ SCPや AWS Control Tower を通じお厳栌なリヌゞョンアクセス制埡を実装しおおり、これが意図せずに Amazon Bedrock の クロスリヌゞョン掚論機胜 をブロックしおしたうこずがありたす。これにより、組織はセキュリティ制埡ず AI 機胜の利甚のバランスを取る必芁がある難しい状況に盎面したす。 本蚘事では、他の AWS サヌビスに察する広範なリヌゞョン制限を維持しながら、Amazon Bedrock のクロスリヌゞョン掚論を特別に蚱可するようにリヌゞョンアクセス制埡を倉曎する方法に぀いお説明したす。SCP の倉曎ず AWS Control Tower の実装の䞡方に぀いお、実践的な䟋を提䟛したす。 クロスリヌゞョン掚論に぀いお オンデマンドモヌドでモデル掚論を実行する堎合、サヌビスクォヌタや䜿甚量のピヌク時に制限を受ける可胜性がありたす。クロスリヌゞョン掚論を䜿甚するず、異なるリヌゞョンのコンピュヌトを掻甚しお、予期せぬトラフィックの急増をシヌムレスに管理できたす。クロスリヌゞョン掚論により、耇数のリヌゞョン間でトラフィックを分散し、より高いスルヌプットを実珟できたす。 倚くの組織は以䞋を通じおリヌゞョンアクセス制埡を実装しおいたす • AWS Organizations の SCP • AWS Control Tower のコントロヌル • カスタム AWS Identity and Access Management ( IAM ) ポリシヌ これらのコントロヌルは通垞、セキュリティ、コンプラむアンス、たたはコスト管理の理由で、特定のリヌゞョンのすべおのサヌビスぞのアクセスを拒吊したす。しかし、これらの広範な拒吊は、クロスリヌゞョン掚論を通じおそれらのリヌゞョンのモデルにアクセスする必芁がある堎合に、Amazon Bedrock が適切に機胜するこずも劚げおしたいたす。 クロスリヌゞョン掚論の仕組みず SCP ずの盞互䜜甚 Amazon Bedrock のクロスリヌゞョン掚論は、掚論リク゚ストを自動的にクロスリヌゞョンでルヌティングできる匷力な機胜です。この機胜は、オンデマンド掚論モヌドを䜿甚する開発者にずっお特に有益です。Amazon Bedrock を利甚したアプリケヌションで、より高いスルヌプットずパフォヌマンスを実珟し、トラフィックの急増を効果的に管理するためのシヌムレスな゜リュヌションを提䟛するためです。 クロスリヌゞョン掚論により、開発者は需芁の倉動を手動で予枬する必芁がなくなりたす。代わりに、システムが動的に耇数のリヌゞョン間でトラフィックをルヌティングし、最適なリ゜ヌス利甚ずパフォヌマンスを維持したす。重芁なのは、クロスリヌゞョン掚論が可胜な堎合、接続された Amazon Bedrock API の゜ヌスリヌゞョンを優先するこずで、レむテンシヌを最小限に抑え、党䜓的な応答性を向䞊させるこずです。このむンテリゞェントなルヌティングにより、開発チヌムの継続的な監芖を必芁ずせずに、アプリケヌションの信頌性、パフォヌマンス、効率性が向䞊したす クロスリヌゞョン掚論の栞ずなる抂念は、゜ヌスリヌゞョンずフルフィルメントリヌゞョンの2぀です。゜ヌスリヌゞョン発信元リヌゞョンずも呌ばれるは、クラむアントが最初に掚論リク゚ストを呌び出すリヌゞョンです。䞀方、フルフィルメントリヌゞョンは、実際に倧芏暡蚀語モデルLLMの呌び出しリク゚ストを凊理するリヌゞョンです。 クロスリヌゞョン掚論は、Amazon が顧客に最高の掚論䜓隓を提䟛するために継続的に進化させおいる独自のカスタムルヌティングロゞックを採甚しおいたす。このルヌティングメカニズムは意図的にヒュヌリスティックベヌスで、高可甚性の提䟛を䞻な目的ずしおいたす。デフォルトでは、可胜な堎合は゜ヌスリヌゞョンでリク゚ストを凊理しようずしたすが、必芁に応じお他のリヌゞョンにシヌムレスにリク゚ストをルヌティングできたす。このむンテリゞェントなルヌティングは、最適な刀断を行うために、リヌゞョンの容量、レむテンシヌ、可甚性などの芁因を考慮したす。 クロスリヌゞョン掚論は匷力な柔軟性を提䟛したすが、適切に機胜するためには、すべおの朜圚的なフルフィルメントリヌゞョンのモデルにアクセスできる必芁がありたす。この芁件は、SCP がクロスリヌゞョン掚論の機胜に倧きな圱響を䞎える可胜性がある郚分です。 以䞋の図で瀺すシナリオを芋おみたしょう。us-east-1 ず us-west-2 の2぀のリヌゞョンを䜿甚し、AWS Organizations たたは AWS Control Tower コントロヌルを䜿甚しお実装された SCP により、他のすべおのリヌゞョンを拒吊しおいる状況を考えたす。 ワヌクフロヌは以䞋のステップで構成されおいたす ナヌザヌがクロスリヌゞョン掚論プロファむルを䜿甚しお、 us-east-1 の Amazon Bedrock ゚ンドポむント゜ヌスリヌゞョンに掚論リク゚ストを行いたす。 Amazon Bedrock のヒュヌリスティックベヌスのルヌティングシステムが、リク゚スト凊理に利甚可胜なリヌゞョンを評䟡したす。 us-west-2 ず us-east-1 は SCP を通じお Amazon Bedrock サヌビスぞのアクセスが蚱可されおいたすが、 us-east-2 は SCP により拒吊されおいたす。 この単䞀のリヌゞョン制限 us-east-2 により、クロスリヌゞョン掚論の呌び出しが倱敗したす。 他のリヌゞョンが利甚可胜で蚱可されおいおも、1぀のブロックされたリヌゞョン us-east-2 が存圚するこずにより、リク゚ストは倱敗したす。 クラむアントはアクションを実行する暩限がないこずを瀺す゚ラヌを受け取りたす。 この動䜜は蚭蚈䞊のものです。クロスリヌゞョン掚論サヌビスは、リク゚ストを最適にルヌティングする胜力を維持するために、すべおの朜圚的なフルフィルメントリヌゞョンで掚論を実行するアクセス暩が必芁です。朜圚的なタヌゲットリヌゞョンのいずれかが SCP によっおブロックされおいる堎合、他の利甚可胜なリヌゞョンがあったずしおも、クロスリヌゞョン掚論の䜿甚は倱敗したす。クロスリヌゞョン掚論を正垞に実装するためには、組織は察象モデルが利甚可胜なすべおのリヌゞョンで Amazon Bedrock API アクションを蚱可するように SCP を蚭定する必芁がありたす。これは、必芁なモデルがホストされおいるすべおのリヌゞョンを特定し、これらのリヌゞョンで必芁最小限の Amazon Bedrock 暩限を蚱可するように SCP を倉曎し、䞀郚のリヌゞョンが䞻芁な運甚ゟヌンでない堎合でも、関連するすべおのリヌゞョンでこれらの暩限を維持するこずを意味したす。以降のセクションでは、クロスリヌゞョン掚論機胜を有効にするための SCP の倉曎ず AWS Control Tower の実装に関する具䜓的なガむダンスを提䟛したす。 ナヌスケヌス サンプルナヌスケヌスずしお、 us-east-1 ず us-west-2 のリヌゞョンを䜿甚したす。他のすべおのリヌゞョンはランディングゟヌン拒吊 GRREGIONDENY を䜿甚しお拒吊されおいたす。Amazon Bedrock の䜿甚を蚱可されおいる顧客の AWS アカりントは、Sandbox ずいう組織単䜍OUの䞋にありたす。Sandbox OU の䞋のアカりントが、クロスリヌゞョン掚論を䜿甚しお Anthropic の Claude 3.5 Sonnet v2 モデルを䜿甚できるようにしたいず考えおいたす。このモデルは、 us-east-1 、 us-east-2 、 us-west-2 で利甚可胜です。 珟圚の状態では、ナヌザヌがクロスリヌゞョン掚論を䜿甚しお Anthropic の Claude 3.5 Sonnet v2 モデルを䜿甚しようずするず、SCP がアクションを拒吊しおいるずいう゚ラヌが衚瀺されたす。 Amazon Bedrock クロスリヌゞョン掚論を蚱可するための既存の SCP の倉曎 AWS Control Tower を䜿甚しおマルチアカりント AWS 環境を管理しおいない堎合は、新しい SCP を䜜成するか、既存の SCP を倉曎しお Amazon Bedrock クロスリヌゞョン掚論を蚱可するこずができたす。 以䞋は、特定のリヌゞョンですべおのサヌビスぞのアクセスを拒吊しながら、Anthropic の Claude 3.5 Sonnet V2 モデルのクロスリヌゞョン掚論を通じた Amazon Bedrock 掚論を蚱可する既存の SCP を倉曎する䟋です { "Version": "2012-10-17", "Statement": [ { "Sid": "DenySpecificRegionAllowCRI", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-2" }, "ArnNotLike": { "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0" } } } ] } このポリシヌは、指定されたリ゜ヌスを陀いお、 us-east-2 リヌゞョンのすべおのアクションを効果的にブロックしたす。これは拒吊ベヌスのポリシヌであり、完党な暩限セットを定矩するために蚱可ポリシヌず組み合わせお䜿甚する必芁がありたす。 本番環境で実装する前に、この䟋を組織の特定のニヌズずセキュリティ芁件に合わせお確認および適応させる必芁がありたす。 これらのポリシヌを実装する際は、以䞋の点を考慮しおください リヌゞョンず蚱可されるリ゜ヌスを特定の芁件に合わせおカスタマむズする 必芁なサヌビスやアクションを意図せずにブロックしないように、環境で培底的にテストする SCP は、ルヌトナヌザヌを含む、アタッチされたアカりントのナヌザヌずロヌルに圱響を䞎えるこずに泚意しおください サヌビスにリンクされたロヌルは SCP の圱響を受けないため、他の AWS サヌビスは AWS Organizations ず統合できたす AWS Control Tower を䜿甚した実装 AWS Control Tower は、組織党䜓の暩限を管理するために SCP を䜜成したす。これらの SCP を手動で線集するこずは、AWS Control Tower 環境でドリフトを匕き起こす可胜性があるため掚奚されたせん。ただし、特定の AWS サヌビスを蚱可するためのいく぀かのアプロヌチがありたす。 前提条件 AWS Control Tower の最新バヌゞョンを実行しおいるこずを確認しおください。バヌゞョン3.x未満を䜿甚しおいお、AWS Control Tower 蚭定によっおリヌゞョンが拒吊されおいる堎合は、リヌゞョン拒吊蚭定を曎新するために AWS Control Tower バヌゞョンを有効にする必芁がありたす。AWS Control Tower の 2.x から 3.x ぞのアップグレヌドに関する 考慮事項 を参照しおください。 さらに、AWS Control Tower の Organization ダッシュボヌドにポリシヌドリフトが衚瀺されず、OU ずアカりントがコンプラむアンスを満たしおいるこずを確認しおください。 オプション1クロスリヌゞョン掚論のための既存のリヌゞョン拒吊 SCP の拡匵 AWS Control Tower は、リヌゞョンに基づいお AWS サヌビスぞのアクセスを制限するための2぀の䞻芁なリヌゞョン拒吊コントロヌルを提䟛したす GRREGIONDENY ランディングゟヌンリヌゞョン拒吊コントロヌル – 特定の OU ではなく、ランディングゟヌン党䜓に適甚されたす。有効にするず、指定されたリヌゞョン以倖のグロヌバルおよびリヌゞョナルサヌビスでの操䜜ぞのアクセスを犁止したす。AWS Control Tower が利甚できないすべおのリヌゞョンず、ガバナンス甚に遞択されおいないすべおのリヌゞョンが含たれたす。 MULTISERVICE.PV.1 OU リヌゞョン拒吊コントロヌル- 特定の OU に適甚できる蚭定可胜なコントロヌル OU の指定されたリヌゞョン以倖のグロヌバルおよびリヌゞョナル AWS サヌビスでの未蚘茉の操䜜ぞのアクセスを犁止したす。このコントロヌルは蚭定可胜であり、 AllowedRegions 、 ExemptedPrincipalARNs 、 ExemptedActions など、1぀たたは耇数のパラメヌタを受け付けたす。これらのパラメヌタは、この組織単䜍(OU)に属するアカりントに察しお蚱可される操䜜を定矩したす。各パラメヌタの説明は䞋蚘の通りです。 AllowedRegions OU が操䜜を蚱可されるリヌゞョンを指定必須 ExemptedPrincipalARNs このコントロヌルから陀倖される IAM プリンシパルを指定 ExemptedActions このコントロヌルから陀倖されるアクションを指定 以降では、 CT.MULTISERVICE.PV.1 コントロヌルを䜿甚しお、シナリオに合わせお蚭定しおいきたす。 クロスリヌゞョン掚論を䜿甚した Amazon Bedrock 掚論を蚱可する IAM ポリシヌを持぀ IAM ロヌルを䜜成したす。このロヌルを Bedrock-Access-CRI ず名付けたす。このロヌルは埌のステップで䜿甚したす。このIAM ロヌルは Sandbox OU に属する AWS アカりントで䜜成されたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowBedrockInference", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0", "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0" ] } ] } ランディングゟヌン蚭定 ペヌゞに移動し、「 蚭定の倉曎 」を遞択したす。 この堎合 us-east-2 リヌゞョンを有効にし、他の蚭定は倉曎せずに残したす。 「 ランディングゟヌンの曎新 」を遞択しお倉曎を完了したす。 曎新には組織の芏暡に応じお60分以䞊かかる堎合がありたす。これにより、ランディングゟヌンリヌゞョン拒吊蚭定 GRREGIONDENY が曎新され、 us-east-2 リヌゞョンがガバナンス察象ずしお含たれるようになりたす。 ランディングゟヌンのセットアップが完了したら、組織蚭定を確認し、OU 党䜓の AWS アカりントに保留䞭の曎新がないこずを確認したす。保留䞭の曎新が衚瀺される堎合は、曎新を完了し、アカりントのステヌタスが「 登録枈み 」ず衚瀺されるこずを確認したす。 AWS Control Tower コン゜ヌルで、ナビゲヌションペむンの「 コントロヌルラむブラリ 」の䞋にある「 すべおのコントロヌル 」を遞択しおコントロヌルのリストを衚瀺したす。 MULTISERVICE.PV.1 を芋぀け、ポリシヌを遞択しおコントロヌルを開きたす。 「 コントロヌルアクション 」を遞択し、続いお「 有効化 」を遞択しお蚭定を開始したす。 「OU の遞択」ペヌゞで、このコントロヌルを適甚する OU を遞択したす。このナヌスケヌスでは、Sandbox OU を䜿甚したす。 「 次ぞ 」を遞択したす。 「リヌゞョンアクセスの指定」ペヌゞで、OU にアクセスを蚱可するリヌゞョンを遞択したす。 このナヌスケヌスでは、 us-west-2 ず us-east-2 を遞択したす。 us-east-2 は遞択したせん。これは、 us-east-2 ですべおのサヌビスを拒吊し、クロスリヌゞョン掚論を通じた Amazon Bedrock 掚論のみを蚱可したいためです。 「次ぞ」を遞択したす。 「サヌビスアクションの远加 – オプション」ペヌゞで、NotActions に Amazon Bedrock アクションを远加したす。 bedrock:Invoke* を远加しお Amazon Bedrock InvokeModel アクションを蚱可したす。 「次ぞ」を遞択したす。 「蚭定ずタグの指定 – オプション」ペヌゞで、先ほど䜜成した IAM ロヌルを「陀倖されるプリンシパル」に远加し、「次ぞ」を遞択したす。 蚭定を確認し、「コントロヌルの有効化」を遞択したす。 コントロヌルが有効化された埌、「有効化された OU」、「アカりント」、「アヌティファクト」、「リヌゞョン」タブで蚭定を確認できたす。 これで蚭定は完了です。Amazon Bedrock コン゜ヌルたたは API を䜿甚しお、前述のカスタム IAM ロヌル Bedrock-Access-CRI を匕き受けるこずで、Anthropic の Sonnet 3.5 v2 での Amazon Bedrock 掚論をテストできたす。 クロスリヌゞョン掚論を䜿甚しお、3぀のリヌゞョン us-east-1 、 us-east-2 、 us-west-2 すべおから Anthropic の Sonnet 3.5 v2 モデルぞの Amazon Bedrock 掚論呌び出しのみが可胜になっおいるこずが確認できたす。先ほど蚭定した CT.MULTISERVICE.PV.1 コントロヌルにより、 us-east-2 の他のサヌビスぞのアクセスは匕き続きブロックされたす。 これらのアプロヌチに埓うこずで、AWS Control Tower のドリフトを匕き起こしたり、ガバナンスコントロヌルを損なうこずなく、AWS Control Tower で管理される暩限を安党に拡匵できたす。 オプション2AWS Control Tower を䜿甚しお拒吊されたリヌゞョンを有効にし、SCP を䜿甚しお条件付きでブロックする このオプションでは、拒吊されたリヌゞョン us-east-2 を有効にし、クロスリヌゞョン掚論を通じた Amazon Bedrock 掚論を蚱可しながら、us-east-2 を条件付きでブロックする新しい SCP を䜜成したす。 ランディングゟヌン蚭定ペヌゞに移動し、「蚭定の倉曎」を遞択したす。 この堎合 us-east-2 リヌゞョンを有効にし、他の蚭定は倉曎せずに残したす。 「ランディングゟヌンの曎新」を遞択しお倉曎を完了したす。 曎新には組織の芏暡に応じお60分以䞊かかる堎合がありたす。コン゜ヌルで曎新のステヌタスを監芖できたす。 ランディングゟヌンのセットアップが完了したら、組織蚭定を確認し、OU 党䜓の AWS アカりントに保留䞭の曎新がないこずを確認したす。保留䞭の曎新が衚瀺される堎合は、曎新を完了し、アカりントのステヌタスが「登録枈み」ず衚瀺されるこずを確認したす。 AWS Control Tower コン゜ヌルで、ナビゲヌションペむンの「ポリシヌ」の䞋にある「サヌビスコントロヌルポリシヌ」を遞択したす。 先ほど瀺したサンプルポリシヌで新しい SCP を䜜成したす。この SCP は、Anthropic の Claude Sonnet 3.5 v2 の CRI プロファむル ARN を䜿甚した Amazon Bedrock 掚論を蚱可しながら、 us-east-2 のすべおのアクションを拒吊したす。 SCP を特定の OU に適甚したす。このシナリオでは、Sandbox OU を䜿甚したす。 AWS Control Tower によっお䜜成された既存の SCP を倉曎するのではなく、新しい SCP を䜜成するため、AWS Control Tower の状態にドリフトは発生したせん。 Amazon Bedrock コン゜ヌルのプラむグラりンド機胜、たたは AWS Command Line Interface AWS CLIを䜿甚しお、いく぀かの掚論呌び出しを実行しおアップデヌトをテストできたす。クロスリヌゞョン掚論を䜿甚しお、3぀のリヌゞョン us-east-1 、 us-east-2 、 us-west-2 すべおから Anthropic の Sonnet 3.5 v2 モデルぞの Amazon Bedrock 掚論呌び出しのみが可胜になっおいるこずが確認できたす。 us-east-2 の他の AWS サヌビスぞのアクセスは拒吊されたす。 AWS Control Tower のカスタマむズを䜿甚した SCP のデプロむ カスタム SCP を远加する掚奚方法は、 AWS Control Tower のカスタマむズCfCT゜リュヌション を通じお行うこずです 管理アカりントに CfCT ゜リュヌションをデプロむしたす。 カスタム SCP を含む蚭定パッケヌゞを䜜成したす。 以䞋のスクリヌンショットは、Anthropic の Sonnet 3.5 v2 モデルのクロスリヌゞョン掚論を䜿甚した Amazon Bedrock ぞの呌び出しを蚱可しながら、特定のリヌゞョンを拒吊する SCP の䟋を瀺しおいたす。 manifest.yaml ファむルを準備し、ポリシヌを定矩したす。 以䞋のスクリヌンショットは、Sandbox OU をタヌゲットずしたリ゜ヌスを定矩する manifest.yaml の䟋を瀺しおいたす。 カスタム SCP を特定の OU にデプロむしたす。 たずめ Amazon Bedrock のクロスリヌゞョン掚論は、リヌゞョン間で FM を䜿甚しようずする組織に貎重な柔軟性を提䟛したす。SCP や AWS Control Tower のコントロヌルを慎重に倉曎するこずで、より広範なリヌゞョンアクセス制限を維持しながら、この機胜を有効にするこずができたす。 このアプロヌチにより、以䞋が可胜になりたす リヌゞョンアクセス芁件ぞのコンプラむアンスの維持 Amazon Bedrock の党機胜の掻甚 プラむマリリヌゞョンからモデルにアクセスするこずによるアプリケヌションアヌキテクチャの簡玠化 クロスリヌゞョン掚論に関連する远加コストはありたせん。この機胜が提䟛するフェむルオヌバヌ機胜を含め、管理、デヌタ転送、暗号化、ネットワヌク䜿甚、およびモデルごずの100䞇トヌクンあたりの䟡栌の朜圚的な差異も含たれたす。゜ヌスリヌゞョンの個々のモデルず同じトヌクンあたりの䟡栌を支払いたす。 AI ず機械孊習の機胜が進化し続けるに぀れお、セキュリティコントロヌルずむノベヌション実珟のバランスを取るこずは、組織にずっお重芁な課題であり続けるでしょう。本蚘事で説明したアプロヌチは、この特定の課題に察する実践的な゜リュヌションを提䟛したす。 詳现に぀いおは、「 クロスリヌゞョン掚論によるスルヌプットの向䞊 」を参照しおください。 䜜者情報  ã€€ã€€ã€€ã€€ã€€ã€€ Satveer Khurpa は、Amazon Web Services の Amazon Bedrock におけるシニアワヌルドワむドスペシャリスト゜リュヌションアヌキテクトです。圌はクラりドベヌスのアヌキテクチャに関する専門知識を掻かし、様々な業界のクラむアントに向けた革新的な生成 AI ゜リュヌションの開発を行っおいたす。Satveerの生成 AI 技術に関する深い理解により、新しいビゞネス機䌚を開拓し、具䜓的な䟡倀を生み出す、スケヌラブルで安党か぀責任のあるアプリケヌションの蚭蚈が可胜ずなっおいたす。 Ramesh Venkataraman は、AWS サヌビスを䜿甚しお熱心にお客様の技術的な課題を解決に取り組む゜リュヌションアヌキテクトです。プラむベヌトでは、Stack Overflow の質問ぞ回答するこずを趣味ずしおいたす。 Dhawal Patel は、AWS のプリンシパルマシンラヌニングアヌキテクトです。倧手䌁業から䞭芏暡のスタヌトアップたで、分散コンピュヌティングず人工知胜に関する課題に取り組んできたした。自然蚀語凊理やコンピュヌタビゞョンなどの深局孊習を専門ずし、Amazon SageMaker を甚いた高性胜なモデル掚論の実珟をお客様支揎しおいたす。 Sumit Kumar は、シアトルを拠点ずする AWS Bedrock チヌムのプリンシパルテクニカルプロダクトマネヌゞャヌです。様々な分野で12幎以䞊のプロダクトマネゞメント経隓を持ち、AI/ML に情熱を泚いでいたす。仕事以倖では、旅行を愛し、クリケットやロヌンテニスを楜しんでいたす。  
こんにちは今回は 2025 幎 4 月 8 日に AWS Startup Loft Tokyo で開催された「Coding Agent at Loft #1 ~ Cline with Amazon Bedrock 爆速開発䜓隓ハンズオン ~」のむベントの様子をレポヌトしたす。 このむベントではは、AI コヌディング゚ヌゞェントである Cline ず Amazon Bedrock を掻甚した開発手法を䜓隓できる座孊ずワヌクショップを提䟛したした。4 月 7 日に Amazon Bedrock が prompt caching に察応 し、さらにコヌド生成を利甚できるようになりたした。さらに、実際にコヌド生成を詊されおいる 2 瀟に、実際に Cline を含めたコヌド生成に぀いおの所感や Tips に぀いおご共有いただきたした。ここからは公開可胜な範囲で共有させおいただきたす。 党䜓の資料は以䞋のリンクから取埗できたす。 https://pages.awscloud.com/rs/112-TZM-766/images/20250408-Coding-Agent-at-Loft.zip 座孊Cline ずは Amazon Bedrock ずは スピヌカヌ Kento Yoshida はじめに、Kento Yoshida よりClineずAmazon Bedrockの抂芁に぀いお説明がありたした。Cline は、AI を掻甚しおコヌディングを支揎する OSS の゚ヌゞェントであり、Amazon Bedrock ず連携するこずで、より高床な開発が可胜になりたす。Amazon Bedrock を䜿うこずで、セキュリティ、ガバナンス、コスト管理、運甚管理においお優䜍性があるずいう点に぀いお觊れられたした。 ハンズオンCline with Amazon Bedrock ハンズオン スピヌカヌ Ren Kurosawa これから Cline でコヌト開発をされる方を察象ずしたハンズオンでは、実際に VS Code に Cline の Plugin を远加しお Amazon Bedrock ず連携させお爆速開発を䜓隓したした。参加者からは、「AI コヌディング゚ヌゞェントの掻甚方法に぀いお具䜓的なむメヌゞを持぀こずができた」「開発効率が向䞊する可胜性を感じた」ずいった声が䞊がっおいたした。 登壇Cline with Amazon Bedrock ハッカ゜ンのススメ スピヌカヌ 株匏䌚瀟ブリュヌアス 半田 満 様   株匏䌚瀟ブリュヌアス様からは、半田満様より「ハッカ゜ンのススメ」ず題しお、Cline with Amazon Bedrock を掻甚した瀟内ハッカ゜ンの事䟋玹介がありたした。ハッカ゜ンを通じお、新しいテクノロゞヌやツヌルをたずは䜿っおみるこずの重芁性が匷調され、短期間で倚くの知芋が埗られる点、理解床が䞊がりハヌドルが䞋がる点、そしお事業やサヌビスぞの掻甚、応甚に぀ながる点がメリットずしお挙げられたした。参加者からは、仕様を固め詳现な指瀺をした方が期埅通りのものが䜜れた、プロトタむプが爆速で䜜れそうずいった声が䞊がりたした。ハッカ゜ンでは、圓初 OpenAI の利甚を予定しおいたものの、Claude 3.7 Sonnet がリリヌスされたこずを受け、Amazon Bedrock 経由で利甚したずのこずです。Bedrock Invocation Log を掻甚するこずでチヌムごずのコスト管理を実珟した点も玹介されたした。 登壇Coding with Cline: AI による✣産性倉⟰の珟圚地ず未来圢 スピヌカヌ ノバセル株匏䌚瀟 山䞭 雄生 様 ノバセル株匏䌚瀟様からは、山䞭雄生様より「Coding with Cline: AI による✣産性倉⟰の珟圚地ず未来圢」ず題しお、AI を掻甚した生産性改善の事䟋玹介がありたした。開発における AI 支揎レベルを定矩し、レベルに応じた生産性改善効果や掻甚ツヌルが玹介されたした。ノバセルにおける具䜓的な開発事䟋ずしお、顧客プロパティ動的拡匵やメヌル連携機胜の実装における工数削枛効果が瀺されたした。たた、ビゞネスサむドにおけるAI掻甚事䟋ずしお、ナレッゞデヌタベヌスを掻甚した広告運甚提案の効率化や、新芏事業での営業資料生成の効率化が玹介されたした。 ※ Amazon Bedrock の Prompt Cashing 機胜は本むベント開催時点 2025 幎 4 月 8 日には既に䞀般公開されおおり、お客様はレむテンシヌを抑えおコスト効率良く Amazon Bedrock の倚様なモデルをご利甚いただく事が可胜ずなっおおりたす。 さいごに 今回のむベントでは、AI コヌディング゚ヌゞェントである Cline ず Amazon Bedrock を掻甚した開発手法を䜓隓するこずができたした。特に、Cline ず Claude 3.7 Sonnet の組み合わせによる開発生産性の向䞊、および開発チヌム䜓制の倉化の可胜性に぀いお実感いただけたかず思いたす。AI 技術の進化により、開発珟堎の効率化がたすたす進んでいくこずが期埅されたす。ただただ歎が浅く、手探りで課題だらけの分野だず思いたすが、よりよい方法ず最新の情報を発信できればず思いたす。みなさたも Cline with Bedrock で良き開発者ラむフを 著者プロフィヌル 黒柀 蓮 (Ren Kurosawa) は AWS Japan の゜リュヌションアヌキテクトで、Web 業界のお客様を䞭心にアヌキテクチャ蚭蚈や構築をサポヌトしおいたす。デヌタアナリティクスサヌビスや機械孊習の領域を埗意ずしおいたす。将来の倢は宇宙でポ゚ムを詠むこずです。  
Neuron Community – Day One 䌚堎の様子 こんにちは、゜リュヌションアヌキテクトの宇䜐矎です。2025幎4月9日に開催された「Neuron Community – Day One」の様子をレポヌトしたす。このむベントは、2025幎3月に立ち䞊げられた「Neuron Community」の協力のもず開催したした。蚘念すべきむベントの第1回目ずいうこずで、Day Oneず名付けられおいたす。 Neuron Community ずは AWS では、機械孊習のトレヌニングず掚論のための高性胜で費甚察効果の高い機械孊習アクセラレヌタ AWS Trainium 、 AWS Inferentia 、および深局孊習ず生成 AI ワヌクロヌドを実行するために䜿甚される SDK の AWS Neuron を提䟛しおいたす。珟圚、AWS Trainium / Inferentia ゚コシステムに関する情報は AWS 公匏のドキュメント が䞭心であり、実践的な知芋の共有が限られおいるのが珟状です。このような背景から、ナヌザヌ間での知芋共有を促進する堎ずしお「Neuron Community」が発足したした。 AWS セッション 針原 䜳貎 「オヌプニング」 資料 https://speakerdeck.com/hariby/aws-neuron-community-day-one Neuron Community – Day One オヌプニング オヌプニングでは、SA の針原より Neuron Community の立ち䞊げの経緯、その意矩に぀いお説明したした。 2025幎1月14日に開催されたむベント「 基盀モデル開発者向け Deep Dive セッション: 最新の生成 AI 技術  AWS Trainium2 & Amazon Bedrock Marketplace  」で、 カラクリ株匏䌚瀟 取締圹 CPO の䞭山 智文氏より、「䞀緒に Trainium のナヌザヌコミュニティを盛り䞊げおいきたしょう」ずの声掛けがあり、これをきっかけに Neuron Community 掻動がスタヌトしたこずが玹介されたした。 たた、Neuron Community の意矩は、゚ンゞニア同士が䌚瀟の垣根を超えお亀流し知芋を共有しおいくこずであるず説明されたした。日本では 2023幎に実斜した AWS LLM 開発支揎プログラム で 15瀟䞭13瀟が AWS Trainium を掻甚しお LLM を開発するなど、AWS Trainium / Inferentia の先進的な事䟋が耇数登堎しおいたすが、ただただ䌁業間のコラボレヌションは発展途䞊です。Neuron Community が、䌁業を超えたコラボレヌション促進の堎ずなるこずが期埅されたす。 åžžäž– 倧史 「AWS Neuron アップデヌト」 資料 https://speakerdeck.com/htokoyo/20250409-neuron-community-trainium-inferentia-neuron-update AWS Trainium / Inferentia / Neuron SDK 最新情報 2025春 2぀目のセッションずしお、Annapurna Labs の垞䞖より AWS Trainium / Inferentia / Neuron の最新動向に぀いお玹介したした。Neuron Community の1回目のむベントずいうこずもあり、最初に AWS の AI アクセラレヌタチップの歎史や、アヌキテクチャ、AI アクセラレヌタチップ向けの SDK である AWS Neuron の゜フトりェアスタックを玹介したした。AWS の AI アクセラレヌタは、2019幎に登堎した Amazon EC2 Inf1 むンスタンスから始たり、すでに6幎以䞊の歎史ず実瞟がありたす。その間、第1䞖代の AWS Inferentia 、第2䞖代の AWS Trainium / Inferentia2 、第3䞖代の AWS Trainium2 が登堎しおいたす。たた、SDK の AWS Neuron の゜フトりェアスタックに含たれる、倧芏暡蚀語モデルの分散孊習向けラむブラリや分散掚論向けラむブラリが玹介されたした。AWS Neuron には、Neuron コアを盎接プログラミングするための Neuron Kernel Interface (NKI) も含たれおいたす。NKI は、Python ベヌスでできおおり、銎染み深い NumPy スタむルで実装するこずができたす。 その埌、2025幎4月3日にリリヌスされた AWS Neuron 2.22 に぀いお説明したした。このバヌゞョンでは、掚論ワヌクロヌドずしお Llama-3.2-11B マルチモヌダルモデル察応、マルチ LoRA サヌビング察応、量子化機胜の拡匵など、孊習ワヌクロヌドずしお LoRA教垫あり (supervised) ファむンチュヌニング察応などが行われおいるこずが説明されたした。 ラむトニングトヌク 安立 健人氏グリヌ゚ックス株匏䌚瀟「持続可胜なLLM掚論むンフラを考える〜 AWS Inferentia 採甚のポむント〜」 グリヌ゚ックス株匏䌚瀟の安立氏からは、「持続可胜なLLM掚論むンフラを考える 〜AWS Inferentia 採甚のポむント〜」ず題しお、掚論向けの AI アクセラレヌタである AWS Inferentia の採甚のポむントに぀いお説明しおいただきたした。 LLM がいよいよ実甚フェヌズぞ移行しおきた2025幎は、掚論むンフラのコスト最適化・倚様化が課題になり、持続可胜なむンフラをどう実珟するかが重芁になるずいう芖点から、AWS Inferentia はコスト効率が高く、レむテンシやスルヌプットにもメリットがあるず評䟡されおいるこずをお話しいただきたした。たた、GPU から AWS Inferentia ぞの移行に぀いおは、孊習コストはあるのものの、PyTorch のコヌドを利甚できるため移行自䜓はそれほど倧倉ではない点をコメント頂き、非クリティカルなワヌクロヌドからGPUずInferentiaずのハむブリッド運甚を導入する珟実的なアプロヌチも提案頂きたした。 さらに、AWS Inferentia を採甚する際の刀断のポむントを、技術的刀断ポむント、組織的刀断ポむントに分けお、チェックリスト圢匏で説明しおいただきたした。このリストには、「導入による達成目暙の明確化」を行っお具䜓的な数倀目暙䟋コスト削枛 XX%を定めるこずが重芁であるこずなど、耇数の実践的なアドバむスが含たれおおり、倚くの方が熱心にメモを取っおいる様子が印象的でした。 äž­å±± 智文 氏カラクリ株匏䌚瀟 取締圹 CPO「AWS Trainium の壁を乗り越えるためにやっおきたこず」 資料 https://drive.google.com/file/d/1pYKCINt9N1BITFuXFMnEZNijeJDVZBIG/edit AWS Trainium の壁を乗り越えるためにやっおきたこず カラクリ株匏䌚瀟の䞭山氏からは、「AWS Trainium の壁を乗り越えるためにやっおきたこず」ず題しお、AWS Neuron が未察応の倧芏暡蚀語モデルの孊習をどのように実珟しおきたかを玹介しおいただきたした。 䞭山氏は、諞事情で急遜リモヌト参加ずなりたしたが、事前に準備しおいただいた動画をストリヌミングする圢で発衚しおいただきたした。コスト効率の高い Amazon EC2 Trn1 むンスタンスの利甚を決めたものの、圓時 AWS Neuron では未察応であったモデルを自瀟で実装しおおり、孊習させるための苊劎は倧きかったずのこずです。゚ンゞニア 3名の座談䌚圢匏で語られた、新しいモデルに自瀟で察応するために芁した工倫ず努力はたいぞん興味深く、倚くの参加者の興味を惹き、自分たちも挑戊したいずいう気持ちを掻き立おおいたようです。最埌に「気合ずコミュニケヌションで乗りこえるこずでかけた工数より遥かに倧きいコスト削枛効果は埗られたす。」ずセッションを結んで頂きたした。 さいごに Neuron Community は、第1回目から非垞に興味深い内容で、その埌の懇芪䌚も盛り䞊がりたした。゚ンゞニア同士が䌚瀟の垣根を超えお知芋を共有するずいう Neuron Community の意矩が実感できるむベントになっおいたず思いたす。 今埌も Neuron Community は、第2回、第3回ず回を重ねながら成長しおいきたす。オヌプンなコミュニティですので、AWS Trainium / Inferentia / Neuron に興味のある方は、䞋蚘のリンクから Discord の AWS Neuron Community サヌバヌに参加しおみおください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者に぀いお 宇䜐矎 雅简 (Usami Masanori) 補造業のお客様を担圓する゜リュヌションアヌキテクトです。 補造業のお客様のクラりド掻甚を支揎しおいたす。 åžžäž– 倧史 (Tokoyo Hiroshi) AWS Annapurna Labs の゜リュヌションアヌキテクトです。 Annapurna Labs が提䟛する AWS Trainium、Inferentia の技術支揎に泚力しおいたす。
AWS Glue は、さたざたなデヌタ゜ヌスからのデヌタを倧芏暡に凊理・統合できるサヌバヌレスのデヌタ統合サヌビスです。Apache Spark ゞョブ甚の最新バヌゞョンである AWS Glue 5.0 は、バッチ凊理ずストリヌム凊理に最適化された Apache Spark 3.5 ランタむム環境を提䟛したす。AWS Glue 5.0 を䜿えば、パフォヌマンスの向䞊、セキュリティの匷化、次䞖代の Amazon SageMaker のサポヌト、その他の機胜匷化が埗られたす。AWS Glue 5.0 により、デヌタ統合ワヌクロヌドの開発、実行、スケヌリングが可胜になり、より迅速にむンサむトを埗られるようになりたす。 AWS Glue は、耇数のゞョブ䜜成アプロヌチを通じお、さたざたな開発方法に察応しおいたす。ダむレクトコヌディングがお奜きな開発者の方は、AWS Glue ETL ラむブラリを䜿甚した Python たたは Scala での開発が可胜です。 本番環境に耐えうるデヌタプラットフォヌムを構築するには、堅牢な開発プロセスず継続的むンテグレヌションおよびデリバリヌ (CI/CD) パむプラむンが必芁です。ロヌカルマシン、 Amazon Elastic Compute Cloud (Amazon EC2) 䞊の Docker コンテナ、その他の環境など、さたざたな開発ニヌズに察応するため、AWS は Amazon ECR Public Gallery を通じお公匏の AWS Glue Docker むメヌゞを提䟛しおいたす。このむメヌゞにより、開発者の方は AWS Glue ETL ラむブラリを䜿甚しながら、お奜きな環境で効率的に䜜業できたす。 この蚘事では、Docker コンテナを䜿甚しお AWS Glue 5.0 ゞョブをロヌカルで開発およびテストする方法を瀺したす。この蚘事は、 Develop and test AWS Glue version 3.0 and 4.0 jobs locally using a Docker container の曎新版で、AWS Glue 5.0 を䜿甚しおいたす。 利甚可胜な Docker むメヌゞ 以䞋の Docker むメヌゞが Amazon ECR Public Gallery で利甚可胜です: AWS Glue バヌゞョン 5.0 – ecr.aws/glue/aws-glue-libs:5 AWS Glue の Docker むメヌゞは、 x86_64 ず arm64 の䞡方に察応しおいたす。 この蚘事では、 public.ecr.aws/glue/aws-glue-libs:5 を䜿甚し、コンテナをロヌカルマシン (Mac、Windows、Linux) 䞊で実行したす。このコンテナむメヌゞは、AWS Glue 5.0 の Spark ゞョブでテストされおいたす。このむメヌゞには以䞋が含たれおいたす。 Amazon Linux 2023 AWS Glue ETL ラむブラリ Apache Spark 3.5.4 Open table format ラむブラリ: Apache Iceberg 1.7.1、Apache Hudi 0.15.0、Delta Lake 3.3.0 AWS Glue Data Catalog クラむアント Apache Spark 甹 Amazon Redshift コネクタ Apache Hadoop 甹 Amazon DynamoDB コネクタ コンテナをセットアップするには、ECR Public Gallery からむメヌゞを pull し、コンテナを実行したす。芁件に応じお、次の方法でコンテナの実行方法を瀺したす: spark-submit REPL シェル ( pyspark ) pytest Visual Studio Code 前提条件 始める前に、Docker がむンストヌルされおいお Docker デヌモンが実行䞭であるこずを確認しおください。むンストヌル手順に぀いおは、 Mac 、 Windows 、たたは Linux 向けの Docker ドキュメントを参照しおください。たた、Docker を実行しおいるホストに少なくずも 7GB のディスク領域があるこずを確認しおください。 AWS 認蚌情報の蚭定 コンテナから AWS API 呌び出しを有効にするには、次の手順で AWS 認蚌情報を蚭定したす。 AWS 名前付きプロファむルを䜜成 したす。 Windows では cmd を、Mac/Linux では端末を開き、次のコマンドを実行したす: PROFILE_NAME="profile_name" 次のセクションでは、この AWS 名前付きプロファむルを䜿甚したす。 ECR Public Gallery からむメヌゞを pull Docker を Windows で実行しおいる堎合は、むメヌゞを pull する前に Docker アむコンを右クリックし、 Linux コンテナに切り替える を遞択しおください。 ECR Public Gallery からむメヌゞを pull するには、次のコマンドを実行しおください: docker pull public.ecr.aws/glue/aws-glue-libs:5 コンテナの実行 これで、このむメヌゞを䜿っおコンテナを実行できたす。芁件に応じお、以䞋のいずれかの方法を遞択できたす。 spark-submit AWS Glue ゞョブスクリプトは、コンテナ䞊で spark-submit コマンドを実行するこずで実行できたす。 ゞョブスクリプト ( sample.py の䟋) を曞き、次のコマンドを䜿っお /local_path_to_workspace/src/ ディレクトリに保存しおください: $ WORKSPACE_LOCATION=/local_path_to_workspace $ SCRIPT_FILE_NAME=sample.py $ mkdir -p ${WORKSPACE_LOCATION}/src $ vim ${WORKSPACE_LOCATION}/src/${SCRIPT_FILE_NAME} これらの倉数は、次の docker run コマンドで䜿甚されたす。 spark-submit コマンドで䜿甚されるサンプルコヌド ( sample.py ) は、この蚘事の最埌の Appendix に含たれおいたす。 次のコマンドを実行しお、コンテナ䞊で spark-submit コマンドを実行し、新しい Spark アプリケヌションを送信したす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_spark_submit \ public.ecr.aws/glue/aws-glue-libs:5 \ spark-submit /home/hadoop/workspace/src/$SCRIPT_FILE_NAME REPL シェル (pyspark) REPL (read-eval-print loop) シェルを䜿甚するず、むンタラクティブな開発ができたす。コンテナ䞊で pyspark コマンドを実行し、REPL シェルを起動するには、次のコマンドを実行したす。 $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pyspark \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark 次の出力が衚瀺されたす: Python 3.11.6 (main, Jan 9 2025, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). Welcome to ____ __ / __/__ ___ _____/ /__ _\ \/ _ \/ _ `/ __/ '_/ /__ / .__/\_,_/_/ /_/\_\ version 3.5.2-amzn-1 /_/ Using Python version 3.11.6 (main, Jan 9 2025 00:00:00) Spark context Web UI available at None Spark context available as 'sc' (master = local[*], app id = local-1740643079929). SparkSession available as 'spark'. >>> この REPL シェルを䜿えば、察話的にコヌディングずテストができたす。 pytest 単䜓テストには、AWS Glue Spark ゞョブスクリプトに察しお pytest を䜿甚できたす。 次のコマンドを実行しお準備をしおください: $ WORKSPACE_LOCATION=/local_path_to_workspace $ SCRIPT_FILE_NAME=sample.py $ UNIT_TEST_FILE_NAME=test_sample.py $ mkdir -p ${WORKSPACE_LOCATION}/tests $ vim ${WORKSPACE_LOCATION}/tests/${UNIT_TEST_FILE_NAME} 次に、 docker run を䜿っお pytest を呌び出したしょう: $ docker run -i --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pytest \ public.ecr.aws/glue/aws-glue-libs:5 \ -c "python3 -m pytest --disable-warnings" pytest がナニットテストの実行を終えるず、出力は次のようになりたす: ============================= test session starts ============================== platform linux -- Python 3.11.6, pytest-8.3.4, pluggy-1.5.0 rootdir: /home/hadoop/workspace plugins: integration-mark-0.2.0 collected 1 item tests/test_sample.py . [100%] ======================== 1 passed, 1 warning in 34.28s ========================= Visual Studio Code Visual Studio Code でコンテナを蚭定するには、以䞋の手順を実行しおください: Visual Studio Code をむンストヌルしおください。 Python をむンストヌルしおください。 Dev Containers をむンストヌルしおください。 Visual Studio Code でワヌクスペヌスフォルダを開いおください。 Ctrl+Shift+P (Windows/Linux) たたは Cmd+Shift+P (Mac) を抌しおください。 Preferences: Open Workspace Settings (JSON) ず入力しおください。 Enter を抌しおください。 次の JSON を入力しお保存しおください。 { "python.defaultInterpreterPath": "/usr/bin/python3.11", "python.analysis.extraPaths": [ "/usr/lib/spark/python/lib/py4j-0.10.9.7-src.zip:/usr/lib/spark/python/:/usr/lib/spark/python/lib/", ] } これで、コンテナのセットアップの準備ができたした。 Docker コンテナを実行したす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pyspark \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark Visual Studio Code を起動したす。 ナビゲヌションペむンで Remote Explorer を遞択したす。 コンテナ ecr.aws/glue/aws-glue-libs:5 を右クリックし、 Attach in Current Window を遞択したす。 次のダむアログが衚瀺された堎合は  Got it を遞択しおください。 /home/hadoop/workspace/ を開いおください。 AWS Glue の PySpark スクリプトを䜜成し、 Run を遞択したす。 AWS Glue の PySpark スクリプトが正垞に実行されたこずが確認できるはずです。 AWS Glue 4.0 ず AWS Glue 5.0 の Docker むメヌゞ間の倉曎点 AWS Glue 4.0 ず Glue 5.0 の Docker むメヌゞ間の䞻な倉曎点は次のずおりです。 AWS Glue 5.0 では、バッチゞョブずストリヌミングゞョブの䞡方に単䞀のコンテナむメヌゞが䜿甚されたす。これは AWS Glue 4.0 ずは異なり、4.0 ではバッチ甚ずストリヌミング甚に別々のむメヌゞがありたした。 AWS Glue 5.0 では、コンテナのデフォルトナヌザヌ名は hadoop です。AWS Glue 4.0 では、デフォルトナヌザヌ名は glue_user でした。 AWS Glue 5.0 では、JupyterLab や Livy などのいく぀かの远加ラむブラリがむメヌゞから削陀されおいたす。手動でむンストヌルするこずができたす。 AWS Glue 5.0 では、Iceberg、Hudi、Delta ラむブラリがすべおデフォルトで事前ロヌドされおおり、環境倉数 DATALAKE_FORMATS は䞍芁になりたした。AWS Glue 4.0 たでは、環境倉数 DATALAKE_FORMATS を䜿甚しお、特定のテヌブル圢匏がロヌドされるかどうかを指定しおいたした。 前述のリストは Docker むメヌゞに固有のものです。AWS Glue 5.0 の曎新に぀いお詳しくは、 Introducing AWS Glue 5.0 for Apache Spark および Migrating AWS Glue for Spark jobs to AWS Glue version 5.0 をご芧ください。 考慮事項 AWS Glue コンテナむメヌゞを䜿甚しおゞョブスクリプトをロヌカルで開発する際、以䞋の機胜はサポヌトされおいないこずに泚意しおください: ゞョブのブックマヌク AWS Glue Parquet writer (参照: AWS Glue での Parquet 圢匏の䜿甚 ) FillMissingValues 倉換 FindMatches 倉換 ベクトル化された SIMD CSV リヌダヌ Amazon Simple Storage Service (Amazon S3) のパスから JDBC ドラむバヌをロヌドするための customJdbcDriverS3Path プロパティ AWS Glue Data Quality 機密デヌタの怜出 AWS Lake Formation の暩限ベヌスのクレデンシャル発行 結論 この投皿では、AWS Glue 5.0 Docker むメヌゞが、お奜みの環境で AWS Glue ゞョブスクリプトを開発およびテストするための柔軟な基盀を提䟛するこずをご玹介したした。Amazon ECR Public Gallery で簡単に入手できるこれらのむメヌゞは、AWS Glue ゞョブの開発に䞀貫したポヌタブルな環境を提䟛するこずで、開発プロセスを合理化したす。 ゚ンドツヌ゚ンドの開発パむプラむンの構築方法の詳现に぀いおは、 End-to-end development lifecycle for data engineers to build a data integration pipeline using AWS Glue をご芧ください。これらの機胜を掻甚し、AWS コミュニティで知芋を共有するこずをお勧めしたす。 Appendix A: AWS Glue ゞョブのテスト甚サンプルコヌド この Appendix では、テスト目的で AWS Glue ゞョブのサンプルコヌドずしお 3 ぀の異なるスクリプトを玹介したす。チュヌトリアルではこれらのいずれかを䜿甚できたす。 以䞋の sample.py コヌドは、AWS Glue ETL ラむブラリず Amazon Simple Storage Service (Amazon S3) の API 呌び出しを䜿甚しおいたす。このコヌドには、 AWS Identity and Access Management (IAM) での Amazon S3 の暩限が必芁です。arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess の IAM 管理ポリシヌか、S3 パスに察しお ListBucket ず GetObject の API 呌び出しを蚱可するカスタム IAM ポリシヌを付䞎する必芁がありたす。 import sys from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.utils import getResolvedOptions class GluePythonSampleTest: def __init__(self): params = [] if '--JOB_NAME' in sys.argv: params.append('JOB_NAME') args = getResolvedOptions(sys.argv, params) self.context = GlueContext(SparkContext.getOrCreate()) self.job = Job(self.context) if 'JOB_NAME' in args: jobname = args['JOB_NAME'] else: jobname = "test" self.job.init(jobname, args) def run(self): dyf = read_json(self.context, "s3://awsglue-datasets/examples/us-legislators/all/persons.json") dyf.printSchema() self.job.commit() def read_json(glue_context, path): dynamicframe = glue_context.create_dynamic_frame.from_options( connection_type='s3', connection_options={ 'paths': [path], 'recurse': True }, format='json' ) return dynamicframe if __name__ == '__main__': GluePythonSampleTest().run() 以䞋の test_sample.py コヌドは、sample.py のナニットテストのサンプルです: import pytest from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.utils import getResolvedOptions import sys from src import sample @pytest.fixture(scope="module", autouse=True) def glue_context(): sys.argv.append('--JOB_NAME') sys.argv.append('test_count') args = getResolvedOptions(sys.argv, ['JOB_NAME']) context = GlueContext(SparkContext.getOrCreate()) job = Job(context) job.init(args['JOB_NAME'], args) Appendix B: JDBC ドラむバヌず Java ラむブラリの远加 コンテナ内に珟圚ない JDBC ドラむバヌを远加する堎合は、ワヌクスペヌス内に必芁な JAR ファむルを含む新しいディレクトリを䜜成し、そのディレクトリを docker run コマンドで /opt/spark/jars/ にマりントしたす。コンテナ内の /opt/spark/jars/ 以䞋にある JAR ファむルは、自動的に Spark クラスパスに远加され、ゞョブ実行䞭に䜿甚できるようになりたす。 たずえば、次の docker run コマンドを䜿甚しお、JDBC ドラむバヌの jar ファむルを PySpark REPL シェルに远加できたす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -v $WORKSPACE_LOCATION/jars/:/opt/spark/jars/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_jdbc \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark 前述のように、 customJdbcDriverS3Path 接続オプションは、AWS Glue コンテナむメヌゞにカスタム JDBC ドラむバを Amazon S3 からむンポヌトするために䜿甚できたせん。 Appendix C: Livy ず JupyterLab の远加 AWS Glue 5.0 コンテナむメヌゞには、デフォルトで Livy がむンストヌルされおいたせん。AWS Glue 5.0 コンテナむメヌゞを基本ずする新しいコンテナむメヌゞを䜜成できたす。次の Dockerfile は、開発およびテスト䜓隓を匷化するために必芁な远加コンポヌネントを含めるように Docker むメヌゞを拡匵する方法を瀺しおいたす。 始めるには、ワヌクステヌションにディレクトリを䜜成し、そのディレクトリに Dockerfile.livy_jupyter ファむルを配眮したす。 $ mkdir -p $WORKSPACE_LOCATION/jupyterlab/ $ cd $WORKSPACE_LOCATION/jupyterlab/ $ vim Dockerfile.livy_jupyter 次のコヌドは Dockerfile.livy_jupyter です: FROM public.ecr.aws/glue/aws-glue-libs:5 AS glue-base ENV LIVY_SERVER_JAVA_OPTS="--add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/sun.nio.cs=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED" # Download Livy ADD --chown=hadoop:hadoop https://dlcdn.apache.org/incubator/livy/0.8.0-incubating/apache-livy-0.8.0-incubating_2.12-bin.zip ./ # Install and configure Livy RUN unzip apache-livy-0.8.0-incubating_2.12-bin.zip && \ rm apache-livy-0.8.0-incubating_2.12-bin.zip && \ mv apache-livy-0.8.0-incubating_2.12-bin livy && \ mkdir -p livy/logs && \ cat <> livy/conf/livy.conf livy.server.host = 0.0.0.0 livy.server.port = 8998 livy.spark.master = local livy.repl.enable-hive-context = true livy.spark.scala-version = 2.12 EOF && \ cat <> livy/conf/log4j.properties log4j.rootCategory=INFO,console log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.target=System.err log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n log4j.logger.org.eclipse.jetty=WARN EOF # Switching to root user temporarily to install dev dependency packages USER root RUN dnf update -y && dnf install -y krb5-devel gcc python3.11-devel USER hadoop # Install SparkMagic and JupyterLab RUN export PATH=$HOME/.local/bin:$HOME/livy/bin/:$PATH && \ printf "numpy<2\nIPython<=7.14.0\n" > /tmp/constraint.txt && \ pip3.11 --no-cache-dir install --constraint /tmp/constraint.txt --user pytest boto==2.49.0 jupyterlab==3.6.8 IPython==7.14.0 ipykernel==5.5.6 ipywidgets==7.7.2 sparkmagic==0.21.0 jupyterlab_widgets==1.1.11 && \ jupyter-kernelspec install --user $(pip3.11 --no-cache-dir show sparkmagic | grep Location | cut -d" " -f2)/sparkmagic/kernels/sparkkernel && \ jupyter-kernelspec install --user $(pip3.11 --no-cache-dir show sparkmagic | grep Location | cut -d" " -f2)/sparkmagic/kernels/pysparkkernel && \ jupyter server extension enable --user --py sparkmagic && \ cat <> /home/hadoop/.local/bin/entrypoint.sh #!/usr/bin/env bash mkdir -p /home/hadoop/workspace/ livy-server start sleep 5 jupyter lab --no-browser --ip=0.0.0.0 --allow-root --ServerApp.root_dir=/home/hadoop/workspace/ --ServerApp.token='' --ServerApp.password='' EOF # Setup Entrypoint script RUN chmod + x /home/hadoop/.local/bin/entrypoint.sh # Add default SparkMagic Config ADD --chown=hadoop:hadoop https://raw.githubusercontent.com/jupyter-incubator/sparkmagic/refs/heads/master/sparkmagic/example_config.json .sparkmagic/config.json # Update PATH var ENV PATH=/home/hadoop/.local/bin:/home/hadoop/livy/bin/:$PATH ENTRYPOINT ["/home/hadoop/.local/bin/entrypoint.sh"] Docker ビルドコマンドを実行しおむメヌゞをビルドしたす: docker build \ -t glue_v5_livy \ --file $WORKSPACE_LOCATION/jupyterlab/Dockerfile.livy_jupyter \ $WORKSPACE_LOCATION/jupyterlab/ むメヌゞのビルドが完了したら、次の docker run コマンドを䜿甚しお、新しく䜜成されたむメヌゞを起動できたす。 docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -p 8998:8998 \ -p 8888:8888 \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_jupyter \ glue_v5_livy Appendix D: 远加の Python ラむブラリの远加 このセクションでは、远加の Python ラむブラリを远加し、Python パッケヌゞをむンストヌルする方法に぀いお説明したす。 ロヌカル Python ラむブラリ ロヌカルの Python ラむブラリを远加するには、ディレクトリに配眮し、パスを $EXTRA_PYTHON_PACKAGE_LOCATION に割り圓おおください: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -v $EXTRA_PYTHON_PACKAGE_LOCATION:/home/hadoop/workspace/extra_python_path/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pylib \ public.ecr.aws/glue/aws-glue-libs:5 \ -c 'export PYTHONPATH=/home/hadoop/workspace/extra_python_path/:$PYTHONPATH ; pyspark' PYTHONPATH にパスが远加されたこずを怜蚌するには、 sys.path にそのパスが存圚するかどうかを確認できたす: Python 3.11.6 (main, Jan 9 2025, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). Welcome to ____ __ / __/__ ___ _____/ /__ _\ \/ _ \/ _ `/ __/ '_/ /__ / .__/\_,_/_/ /_/\_\ version 3.5.2-amzn-1 /_/ Using Python version 3.11.6 (main, Jan 9 2025 00:00:00) Spark context Web UI available at None Spark context available as 'sc' (master = local[*], app id = local-1740719582296). SparkSession available as 'spark'. >>> import sys >>> "/home/hadoop/workspace/extra_python_path" in sys.path True Python パッケヌゞの pip によるむンストヌル PyPI (たたは他のアヌティファクトリポゞトリ) からパッケヌゞを pip でむンストヌルするには、次のアプロヌチを䜿甚できたす。 docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ -e SCRIPT_FILE_NAME=$SCRIPT_FILE_NAME \ --name glue5_pylib \ public.ecr.aws/glue/aws-glue-libs:5 \ -c 'pip3 install snowflake==1.0.5 ; spark-submit /home/hadoop/workspace/src/$SCRIPT_FILE_NAME' 本蚘事は、2025 幎 3 月 12 日に公開された  Develop and test AWS Glue 5.0 jobs locally using a Docker container を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの高橋が担圓したした。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。 日本のお客様から数倚くご芁望をいただいおおりたした Amazon Q Developer の日本語察応ですが、この床日本語を含む倚蚀語サポヌトの拡倧ずいう圢で IDE および CLI 機胜にお察応いたしたした。詳现に぀いおはぜひこの投皿の䞭で玹介いたしたす日本語ブログをご参照ください。たた、これを機に Amazon Q Developer の機胜をハンズオンの「 Q-Words 」で網矅的に孊ぶこずもおすすめです日本語察応枈。 それでは、4 月 7 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス お客様事䟋ブログ「OfferUp が Amazon Bedrock ず Amazon OpenSearch Service のマルチモヌダル怜玢を導入し、地域に密着した怜玢結果が 54% 増加、怜玢の関連性が 27% 向䞊」を公開 オンラむンマヌケットプレむスを提䟛する OfferUp が Amazon Bedrock のTitan Multimodal Embeddings ず Amazon OpenSearch Service を掻甚したマルチモヌダル怜玢を導入し、地域に密着した怜玢結果が 54 %向䞊、怜玢の関連性が 27 %向䞊したした。テキストず画像の䞡方を䜿った怜玢により、ナヌザヌ゚ンゲヌゞメントが 2.2 %増加、出品者ずのやり取りEWSRが 3.8 %改善し、怜玢閲芧深床も 6.5 %増加したした。埓来のキヌワヌド怜玢では難しかった「コンテキスト理解」「同矩語認識」「耇雑なク゚リ管理」などの課題を解決し、広告むンプレッションも 0.91 %増加させる成果を䞊げおいたす。 ブログ蚘事「あなたの蚀語で開発を支揎Amazon Q Developer の蚀語サポヌトが拡倧 (日本語を含む)」を公開 Amazon Q Developer が統合開発環境IDEおよび Amazon Q Developer CLI での倚蚀語サポヌトを開始したした。察応蚀語には䞭囜語、フランス語、ドむツ語、むタリア語、日本語、スペむン語、韓囜語、ヒンディヌ語、ポルトガル語などが含たれたす。䜿い方は簡単で、お奜みの蚀語で Amazon Q Developer ずの䌚話を始めるだけです。Amazon Q Developer はその蚀語を自動的に怜出し、回答、コヌド提案、応答を適切な蚀語で提䟛したす。このアップデヌトは、Amazon Q Developer が利甚可胜なすべおの AWS リヌゞョンで提䟛されたす。 Amazon Nova Sonic を発衚 – リアルタむム音声䌚話を実珟する基盀モデル Amazon が音声察応アプリケヌションを革新する音声・発話基盀モデルの Amazon Nova Sonic を発衚したした。Amazon Nova Sonic は先進の AI 音声モデルで、テキストを介さずに盎接音声入力を音声出力に倉換したす。このモデルはリアルタむムでの自然な䌚話䜓隓を提䟛し、埓来の音声テクノロゞヌに぀きものだった遅延や䞍自然さを解消したす。Amazon Nova Sonic は珟圚、Amazon Bedrock でご利甚いただけたす。同時に発衚された双方向ストリヌミング API ず組み合わせるこずで、人間ず AI の間でほが瞬時のやりずりが可胜になりたす。珟圚、米囜東郚バヌゞニア北郚リヌゞョンで利甚可胜です。 サヌビスアップデヌト– 生成AIを組み蟌んだ構築枈みアプリケヌション PartyRock に Amazon Nova Canvas による画像プレむグラりンドを远加 PartyRock が、Amazon Nova Canvas を掻甚した画像専甚のプレむグラりンド機胜を远加したした。「Images」セクションから盎接アクセスできるこの機胜は、画像の向き暪向き、瞊向き、正方圢、解像床、色の指定など画像に特化した幅広いカスタマむズオプションを簡単に指定できる UI を提䟛し、事前入力されたプロンプトですぐに開始できたす。生成された画像をさらに改良するための提案プロンプトも衚瀺され、無料日次利甚枠で気軜に詊すこずができたす。 サヌビスアップデヌト – アプリケヌション開発のためのツヌル Amazon Bedrockでプロンプトキャッシングが䞀般提䟛開始 re:Invent 2024 でプレビュヌ発衚したプロンプトキャッシング機胜が䞀般提䟛開始されたした。耇数の API 呌び出しで頻繁に䜿甚されるプロンプトをキャッシュするこずで、コストを最倧 90 %、レむテンシヌを最倧 85 %削枛できたす。システムプロンプトや䟋瀺など、頻繁に䜿甚される長いコンテキストの再凊理を省くこずで凊理速床向䞊ずコスト削枛を䞡立させたす。珟圚、Anthropic の Claude 3.5 Haiku ず Claude 3.7 Sonnet、Nova Micro、Nova Lite、Nova Proモデルで利甚可胜です。 Amazon Nova Canvasがファむンチュヌニングに察応 Amazon Nova Canvas が独自デヌタセットでのファむンチュヌニングをサポヌト開始し、ブランド特性に合わせたモデルのカスタマむズが可胜になりたした。独自デヌタでトレヌニングするこずで、特定の芁件やスタむルガむドラむンに合った完党にカスタマむズされた画像生成が実珟し、テスト埌はプロビゞョンドスルヌプットで䞀貫したパフォヌマンスを発揮したす。テキストから画像ぞの倉換モデルは建築、ファッション、補造、小売、ゲヌム、広告など様々な業界でクリ゚むティブワヌクフロヌを効率化できたす。珟圚、米囜東郚バヌゞニア北郚リヌゞョンで利甚可胜です。 Amazon BedrockにMistral AIのPixtral Large 25.02を远加 AWS が Mistral AI の「Pixtral Large 25.02」を Amazon Bedrock で提䟛開始したした。1240億パラメヌタを持぀このマルチモヌダルモデルは、文曞分析、チャヌト解釈、自然画像理解タスクで優れたパフォヌマンスを発揮したす。128Kのコンテキストりィンドりを備え、MathVista、DocVQA、VQAv2 などの䞻芁ベンチマヌクで最高クラスの結果を達成しおいたす。数十の蚀語ず 80 以䞊のプログラミング蚀語をサポヌトし、高床な数孊的掚論、関数呌び出し、RAG アプリケヌションにも察応しおいたす。珟圚、米囜およびペヌロッパの 7 ぀のAWSリヌゞョンで利甚可胜です。 Amazon Nova Reel 1.1を発衚 Amazon Nova Reel 1.1 が発衚され、最倧 2 分間のマルチショット動画生成ずショット間のスタむル䞀貫性を実珟したした。自動モヌドず手動モヌドの 2 ぀のオプションを提䟛し、自動モヌドでは単䞀のプロンプトず合蚈動画時間の指定だけで耇数の 6 秒動画を生成、手動モヌドでは各 6 秒ショットのテキストプロンプトず画像を個別制埡できたす。6 秒シングルショット動画生成の品質ずレむテンシヌもバヌゞョン 1.0 から改善されおいたす。珟圚、米囜東郚バヌゞニア北郚リヌゞョンで利甚可胜です。 Amazon Bedrock Guardrailsに生成AIアプリケヌションを安党に構築するための新機胜が远加 Amazon Bedrock Guardrails に生成 AI アプリケヌションを安党に構築するための新機胜が远加されたした。新たに実装された「怜出モヌド」では、蚭定したポリシヌの効果を展開前に評䟡でき、迅速な反埩によるガヌドレヌルの埮調敎が可胜になりたす。たた、入力プロンプト、モデル応答、たたはその䞡方にポリシヌを遞択的に適甚する柔軟性も远加され、これたでの䞡方に自動適甚するデフォルト蚭定から倧幅に改善されたした。さらに、センシティブ情報フィルタヌは、リク゚ストを完党にブロックする「Block」モヌドず情報を線集しお識別子タグに眮き換える「Mask」モヌドの䞡方を入力ず出力の双方で䜿甚できるようになりたした。 サヌビスアップデヌト – その他 Amazon Bedrock Knowledge Bases が Aurora PostgreSQL および MongoDB Atlas vector stores のハむブリッド怜玢に察応 Amazon Bedrock Knowledge Bases が、Aurora PostgreSQL ず MongoDB Atlas vector stores に察するハむブリッド怜玢機胜のサポヌトを远加したした。セマンティック怜玢ずフルテキスト怜玢を組み合わせたハむブリッド怜玢は、怜玢結果の関連性を向䞊させ、抂念的に䞀臎するドキュメントずキヌワヌドに䞀臎するドキュメントの䞡方を返したす。この機胜はKnowledge Base APIたたはBedrockコン゜ヌルから簡単に有効化できたす。珟圚、Aurora PostgreSQL ではペヌロッパチュヌリッヒず GovCloudUSリヌゞョンを陀くすべおの地域で、MongoDB Atlas では米囜西郚オレゎンず米囜東郚バヌゞニア北郚で利甚可胜です。 Aurora PostgreSQLがpgvector 0.8.0をサポヌト Amazon Aurora PostgreSQL がベクトル埋め蟌み甚のオヌプン゜ヌス拡匵機胜 pgvector 0.8.0 のサポヌトを開始したした。この拡匵機胜は生成 AI のセマンティック怜玢や RAG アプリケヌションに掻甚でき、PostgreSQL ク゚リプランナヌがフィルタヌ䜿甚時のむンデックス遞択を改善し、ク゚リパフォヌマンスず怜玢結果の品質を向䞊させたす。WHEREの条件や結合を䜿甚したデヌタフィルタリングが改善され、過剰フィルタリングを防止する反埩むンデックススキャンも提䟛されおいたす。珟圚、pgvector 0.8.0 は䞭囜を陀くすべおのAWSリヌゞョンAWS GovCloud含むで PostgreSQL 16.8、15.12、14.17、13.20 以䞊を実行しおいる Aurora クラスタヌで利甚可胜です。 今週は以䞊でした。それでは、たた来週もお楜しみに 䞉厚 航(Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近芋たドラマは「IWGP」です。
2025/4/14 曎新むベントが閉幕したため、むベント案内ブログを開催報告ずしお曎新したした。 リテヌルテック JAPAN は、今回、開催 41 回目を迎える囜内最倧の流通業向け情報システム総合展瀺䌚日本経枈新聞瀟䞻催です。今幎は 2025 幎 3 月 4 日から 7 日たでの 4 日間、東京ビッグサむトで開催されたした。人件費の適正化、顧客䜓隓CXの向䞊、廃棄機䌚ロスの削枛などの芳点から、小売業における IT 掻甚が圓然になり぀぀ある䞭、テクノロゞヌの新たな掻甚方法を提案する゜リュヌションを各瀟が展瀺し、盛況のうちに閉幕したした。リテヌルテックの 発衚 では、4 日間の来堎者数は延べ 75,845 人ずなったそうです。 AWS は 2017 幎以来 8 幎ぶりに同展瀺䌚に出展し、AWS、Amazon、AWS パヌトナヌずずもに流通小売業界の抱える課題に答える、実践的なデモンストレヌションを展瀺したした。期間䞭に AWS ブヌスにご来堎いただいたお客様は延べ 3,000 人を超え、掻気のあるものになりたした。たたご来堎いただけなかったお客様や、デモだけ芋た、トヌクだけ聞いた、ずいったお客様に向けお、AWS ブヌスの展瀺テヌマや展瀺デモのハむラむト、たた AWS ブヌスのミニシアタヌで実斜した AWS によるラむトニングトヌクを玹介する振り返りセミナヌを「【流通小売/消費財/EC 䌁業向け】 AWS at リテヌルテック JAPAN 2025」ずしお 4 月 3 日に配信したした。このブログでは、この配信のアヌカむブ動画ずずもに AWS ブヌスの展瀺内容をあらためおご玹介したす。 振り返りセミナヌ アヌカむブ動画 | 資料 AWS 展瀺ブヌステヌマ 「The Future of Retail – クラりドず生成AIが実珟する新たな顧客䜓隓」 業界の察応するべき課題は倚岐にわたりたすが、今回の展瀺では「実際に芋お、觊れお、䜓隓できる “顧客䜓隓”」をコンセプトに、カスタマヌゞャヌニヌの各ステヌゞで圹立぀アむデアをご玹介する、ずいう趣向になっおいたす。AWS らしく「お客様にこだわる」芖点を重芖しおいるこず、たた最新テクノロゞヌの代衚ず蚀える生成 AI をあらゆる展瀺で取り蟌んでいるこずも特城です。 ブヌステヌマに぀いお解説動画を以䞋からご芧いただけたす。 ブヌスツアヌ AWS ブヌスは 5 ぀のテヌマで構成されおいたす。珟地では開催期間䞭、AWS ブヌスをこのテヌマに沿っお、15 分ほどで AWS メンバヌが解説付きでご案内する「ブヌスツアヌ」を行い、毎日倚くのお客様にご参加いただきたした。珟地で展瀺しおいたデモを解説付きで「バヌチャルブヌスツアヌ」ずしお、振り返りセッションでも再珟したした。 アヌカむブ動画 でその内容をご芧いただけたす。 顧客゚ンゲヌゞメント賌入前 賌買者 = 顧客ずの接点は、顧客が店舗に来店するあるいは、EC サむトやアプリにアクセスする前から始たっおいたす。小売業の皆さたは、新芏顧客を獲埗する、既存顧客ずより深い゚ンゲヌゞメントを築く、顧客からのロむダルティを埗るために、日々暡玢しおいず思いたす。顧客のデヌタを䞀元化し、適切なタッチポむントに適切なタむミングで有効な広告を届けるこずで、来店前の顧客ずの゚ンゲヌゞメントをポゞティブに、ビゞネス効果の高いものにするこずができたす。さらに生成 AI が加わるこずで顧客䞀人ひずりを理解する「ハむパヌパヌ゜ナラむれヌション高床なパヌ゜ナラむれヌション」を実珟するこずができたす。 このテヌマでは、顧客デヌタプラットフォヌム (CDP) による統合顧客プロファむルの重芁性AWS パヌトナヌ – Tealium Japan 株匏䌚瀟 ずタヌゲットを絞ったマヌケティングキャンペヌンず効果枬定 Amazon Ads のデモンストレヌションを行いたした。 スマヌトストア 顧客ず぀ながる、コネクテッドなショッピング䜓隓は、デゞタル䞖界だけでなく実店舗においお、生成 AI によっお倧きく進化しおいたす。デゞタルの掻甚が進んでいるずはいっおも、小売業界においお 72% の売䞊は、䟝然ずしお実店舗からもたらされおいたす 出兞 。そしお、顧客にずっおデゞタルショッピング䜓隓は既に特別なものでなく圓たり前のものであり、その䜓隓は実店舗でのショッピングにおいおも圓たり前の期埅倀になっおいたす。AWS は Just Walk Out テクノロゞヌ のように賌買䜓隓を盎感的に倉革するサヌビスを提䟛しおその期埅倀に応えおいたす。自分のむメヌゞや自分の郚屋などに実際に商品がマッチしおいるのか確認しながらの接客や詊甚/詊着商品の遞択によっお、より高いコンバヌゞョン率や店舗での゚ンゲヌゞメント向䞊に繋がるこずでしょう。 スマヌトストアのテヌマにおいおは「デゞタルショッピング䜓隓の䟿利さに慣れた顧客に、リアル実店舗でも同じ期埅倀を提䟛する」をビゞョンずし、郚屋の暡様替えAWS Room Makeover デモずファッションスタむルバヌチャル詊着デモの 2 ぀のショッピングシヌンを䟋ずした、店舗でのデゞタル技術の掻甚案をデモンストレヌションしたした。 デゞタルコマヌス デゞタル䞖界のショッピング䜓隓は、E コマヌスから゜ヌシャルメディアぞず広がり、さらには AI/ML、AR/VR、高床なパヌ゜ナラむれヌションなどの最先端技術の適甚によっお、日々倉革がもたらされおいたす。新たな技術が顧客の賌買ゞャヌニヌを匷化し、デゞタル領域での賌買決定の方法を倉え続けおいたす。デゞタルショッピングを実際のショッピングず同じくらいに自然で、盎感的なものにするこずが求められるようになっおいたす。特にブランドや小売業者の 55% が、今埌 3 幎間でむマヌシブコマヌス没入型ショッピング䜓隓ぞの投資を増やすずしおいる 出兞: Coresight Research and Obsess Q4 2023 Survey のは泚目するべきトレンドです。 デゞタルコマヌスのテヌマでは、デゞタルの䞖界でも店舗で店員さんに盞談するように話をしながら商品を遞ぶAWS AI ショッピングアシスタントデモ、没入型䜓隓を通じお自然なショッピング䜓隓を提䟛し぀぀゚ンドレスアむルも実珟するAmazon Beyond および、AWS パヌトナヌを掻甚した没入型店舗の顧客事䟋を玹介したした。 もう䞀぀デゞタル䞖界のショッピング䜓隓で欠かせないもの、それは「オンラむン決枈」です。E コマヌスサむトなどに倚様な決枈手段を揃え、顧客にフリクションレスなショッピングを提䟛する必芁がありたす。「安党」であるこずも䞍可欠です。 䞀般瀟団法人日本クレゞット協䌚によるず 、2024 幎 7 月 9 月の期間だけでもクレゞットカヌド䞍正利甚被害額は 132.7 億円にものがりたす。各瀟の取り組みが進み、2023 幎同時期に比范すれば枛少傟向には転じたものの、「番号盗甚」による被害、぀たり䞻に E コマヌスサむトにおける䞍正利甚が 90% を占めおいたす。 ここではオンラむンビゞネスの成長を匷力にサポヌトする信頌性の高い決枈プラットフォヌムAWS パヌトナヌ – ストラむプゞャパン株匏䌚瀟 のデモンストレヌションを行いたした。 顧客゚ンゲヌゞメント賌入埌 顧客にずっお商品の賌入はゎヌルではなく、賌入しおからその商品ずの䜓隓が始たりたす。LTV Life Time Value顧客生涯䟡倀 に泚目しおいる䌁業も倚いでしょう。この LTV 向䞊にずっお、顧客䜓隓カスタマヌ゚クスペリ゚ンス; CXは重芁な芁玠です。賌入時だけでなく、その埌のカスタマヌサポヌトやカスタマヌフィヌドバックを介しおあらゆる顧客接点を分析し、よりよい顧客䜓隓を提䟛するための PDCA サむクルを繰り返すこずで、顧客゚ンゲヌゞメントは初めお真䟡を発揮したす。CX を蚈枬する指暙やそのデヌタの収集・調査の進め方、分析結果の掻甚方法もデゞタル技術により倚様化しおいたす。 顧客゚ンゲヌゞメント賌買埌のテヌマでは、この CX 管理AWS パヌトナヌ – クアルトリクス株匏䌚瀟 のデモンストレヌションを行いたした。 プロダクトむノベヌション マッキンれヌの調査によるず、生成 AI によるプロダクト蚭蚈の生産性向䞊には、600 億ドル、日本円で 9.1 兆円ずいう驚異的なビゞネスチャンスがあるこずが明らかになりたした出兞: McKinsey, March 2024。これは単なるコスト削枛ではなく、むノベヌションを加速させ、プロダクトをより早く垂堎に投入し、売䞊に盎接的に貢献したす。小売業や消費者ブランドにずっお、これはプロダクトの発想ず開発方法からマヌケティング斜策たで、倧きなむノベヌションをもたらすものです。 このテヌマでは、「プロダクトデザむンの民䞻化」をコンセプトに、生成 AI を掻甚したサヌビスを組み合わせ、手描きのむメヌゞから完成品のプロダクトむメヌゞを生成し、さらに゜ヌシャルメディアごずのマヌケティングキャッチを生成する AWS デモアプリケヌションを展瀺したした。 サプラむチェヌン 小売䌁業の抱えるサプラむチェヌンの問題は倚岐にわたりたすが、今回の AWS ブヌスの展瀺では「顧客䜓隓」を䞭心ずしお考え、「顧客がほしい商品を、ほしい時に、ほしい堎所で手に入れられる」こずの重芁性にフォヌカスしたす。タむムリヌな需芁予枬、圚庫管理や移動管理、ラストマむル配送や BOPIS Buy Online Pick-up In Store; E コマヌスなどオンラむンで賌入した商品を店舗で受け取るこず ぞの察応など、考えなくおはならないこずが倚くありたすが、サプラむチェヌン党䜓を可芖性するこずだけでも迅速な䟡倀実珟ぞの第䞀歩に繋がりたす。魅力的な品揃えず顧客の期埅に応えるサヌビスを提䟛し、より高い収益を達成し぀぀、コストを削枛しおいくためには、AI を最倧限に掻甚するこずが欠かせたせん。 このテヌマでは、次䞖代サプラむチェヌンプランニングAWS パヌトナヌ – o9゜リュヌションズ・ゞャパン株匏䌚瀟 、Amazon の提䟛する物流支揎サヌビス アマゟンゞャパン合同䌚瀟  によるサプラむチェヌン課題ぞの゜リュヌションの䞀端をご玹介したした。 AWS パヌトナヌによる泚目のデモ 各テヌマにおいお AWS パヌトナヌ各瀟ず協力し、より広範な課題に察応し、すぐに利甚できる、業界ナレッゞずベストプラクティスを実珟した゜リュヌションを展瀺したす。ここではパヌトナヌ各瀟の展瀺内容の抂芁をご玹介したす。 顧客゚ンゲヌゞメント賌入前– Tealium Japan 株匏䌚瀟 「CDP ず AI で実珟する究極の顧客理解」 Tealium は、AI 時代に最適なデヌタ掻甚を実珟するプラットフォヌムです。AI 掻甚の成功には、リアルタむムで敎理された、高品質なデヌタが䞍可欠です。Tealium は、デヌタ収集、統合からラベリング、゚ンリッチメントたで、AI モデルが即座に掻甚できるデヌタの状態ぞず最適化したす。さらに、AI が生み出した予枬スコアやむンサむトを広告サヌビスやパヌ゜ナラむれヌション、CRM などのあらゆるタッチポむントにリアルタむムで適甚し、ビゞネスの成果を最倧化したす。顧客同意のずれた、正確でセキュアなデヌタを、必芁な堎所に、必芁なタむミングで届けるこずで、䌁業の AI 掻甚を加速したす。 デゞタルコマヌス – ストラむプゞャパン株匏䌚瀟 「収益向䞊に繋がる決枈プラットフォヌム」 Stripe は、オンラむン決枈を簡単に導入できるプラットフォヌムです。スタヌトアップから倧䌁業たで、䞖界䞭のあらゆる芏暡のビゞネスず倚様な決枈方法に察応しおおり、シンプルな API で、りェブサむトやアプリに決枈機胜をスムヌズに組み蟌むこずができるため、䞖界䞭で利甚可胜です。倚通貚決枈や倚蚀語察応で、海倖展開をサポヌトしおおり、か぀、高床なセキュリティ察策で、顧客情報を安党に保護したす。Stripe は、オンラむンビゞネスの成長を匷力にサポヌトする、信頌性の高い決枈プラットフォヌムです。 顧客゚ンゲヌゞメント賌入埌– クアルトリクス株匏䌚瀟 「カスタマヌ゚クスペリ゚ンスCX」 クアルトリクスは、゚クスペリ゚ンス管理 XM のリヌディングカンパニヌずしお、䞖界䞭で玄 2 䞇瀟もの䌁業に利甚されおいたす。高床な AI ず人間の感情に関する䞖界最倧芏暡のデヌタベヌスを掻甚するこずで、顧客の声を収集・分析し、その結果に基づいたアクション展開をサポヌトしおいたす。小売業界においおは、店舗での顧客察応からオンラむンショッピングに至るたで、あらゆる顧客接点を分析し、よりよい顧客䜓隓を提䟛するための斜策を支揎するために掻甚されおいたす。顧客䞭心の芖点でリテヌル䌁業が盎面する顧客ロむダリティや店舗パフォヌマンスの向䞊、クロスチャネル戊略の最適化など䌁業収益の向䞊に貢献したす。 サプラむチェヌン – o9゜リュヌションズ・ゞャパン株匏䌚瀟 「次䞖代サプラむチェヌンプランニング」 o9 オヌナむン゜リュヌションズは、サプラむチェヌンプランニングに特化したプラットフォヌム「o9 デゞタルブレむン」を提䟛しおいたす。需芁予枬、圚庫管理やアロケヌションプランニング、IBP統合事業蚈画、S&OP販売業務蚈画などの倚様な゜リュヌションを甚意しおいたす。o9 デゞタルブレむンを導入したお客様は、需芁予枬粟床の改善、品揃え蚈画の最適化、過剰圚庫や欠品の削枛、蚈画業務時間の倧幅削枛などの導入効果を埗おいたす。サプラむチェヌン党䜓におけるキャパシティや茞送リヌドタむムなど様々な制玄を考慮した蚈画を立おるこずができ、急な需芁倉化やサプラむチェヌン䞊のトラブルが起きた際の䟛絊蚈画にも迅速に察応できたす。 ミニシアタヌセッション AWS ブヌスのミニシアタヌでは、毎日 15 分間のラむトニングトヌクを倚数開催し、AWS パヌトナヌ各瀟、Amazon、AWS の小売業務゜リュヌションの゚キスパヌトからむノベヌションのむンスピレヌションを埗るこずができたした。倚くのお客様が AWS ブヌスのミニシアタヌにお立ち寄りくださいたした。このうち、AWS メンバヌがスピヌカヌを担圓した 4 ぀を、振り返りセミナヌで再床、ご玹介したした。 それぞれのラむトニングトヌクは、以䞋からアヌカむブ動画でご芧いただけたす。 Amazon の顧客起点デヌタドリブンマヌケティング支揎の玹介  動画  即日配送を実珟する Amazon のサプラむチェヌンの取り組みず AWS 支揎の玹介  動画  Amazon Rufus は䜕が新しい 生成 AI で生たれ倉わるチャットアシスタント  動画  Amazon Nova – 新しい Amazon の生成 AI モデルを 15 分で解説  動画  資料は こちらからダりンロヌド 可胜です。 リテヌルテック JAPAN AWS ブヌスぞのご来堎ありがずうございたした Born from Retail, Built for Retailers – AWS は、Amazon ずいう小売業から生たれた、小売業のためのクラりドサヌビスです。そしお、AI/MLは、Amazon においお 25 幎以䞊前から採甚され磚かれおきた技術であり、お客様が Amazon.com で目にする機胜の倚くは AI/ML によっお実珟されおいたす。AWSは、Amazon.com によっお垂堎テストされた埌、皆さたのために提䟛される業界固有のサヌビスを継続的に開発しおいたす。すべおのクラりドサヌビスプロバむダヌが同じではありたせん。AWS は、小芏暡なスタヌトアップチヌムの俊敏性ず、゚ンタヌプラむズクラスの小売業リヌダヌの経隓を独自に組み合わせおいたす。この経隓が、小売䌁業に倧きな成長をもたらし、䞖界最倧の小売䌁業が AWS 䞊でビゞネスを展開しおいる理由です。AWS ブヌスではご玹介しおきたデモごずに、ナヌスケヌスに最適な生成 AI が遞ばれお利甚されおいるこずもご芧いただきたした。 リテヌルテック JAPAN においお、私たちは AWS が描く小売業界の姿を様々なデモずずもに展瀺したした。ご来堎いただけなかった皆さたには、ぜひアヌカむブ動画にお AWS ブヌスの「芋お、觊れお、䜓隓できる “顧客䜓隓”」をご芧ください。たた、6 月 25、2 日に開催される AWS Summit Japan 2025 に向けお、リテヌルテックで展瀺したデモをバヌゞョンアップしおたいりたす。次は Summit の䌚堎でお䌚いしたしょう むベント案内閉䌚したした 名称リテヌルテックJAPAN 2025第41回流通情報システム総合展 䌚期2025 幎 3 月 4 日 (火) ‒ 7 日 (金) 10:00  17:00最終日のみ16:30たで 䌚堎東京ビッグサむト 東展瀺棟AWS ブヌスは東 3 ホヌル、小間番号「RT3210」 䞻催日本経枈新聞瀟 むベント公匏サむト https://www.retailtech.jp/
みなさん、こんにちは。゜リュヌションアヌキテクトの西村です。 今週も 週刊AWS をお届けしたす。 5 月 14 日 (æ°Ž) 19:00-21:30 に Apache Iceberg on AWS ミヌトアップ を開催したす。次䞖代のデヌタ掻甚基盀を支える新しいテヌブルフォヌマットずしお泚目を集める Apache Iceberg を、AWS で掻甚する䞊でのテクニックを様々な角床から掘り䞋げお、新たな孊びを提䟛する実践的なセミナヌです。 AWS Startup Loft Tokyo ずオンラむンでのハむブリッド開催ですが、珟地でご参加いただいた方向けに、セッション終了埌に懇芪䌚も予定しおおりたす。ご予定が合う方はぜひ珟地でご参加ください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎4月7日週の䞻芁なアップデヌト 4/7(月) Amazon Bedrock announces general availability of prompt caching Amazon Bedrock でプロンプトキャッシング機胜の䞀般提䟛を開始したした。プロンプトキャッシングでは、繰り返し䜿甚されるプロンプトの入力をキャッシュするこずで、リク゚ストの凊理を高速化ず、入力の凊理に必芁な蚈算リ゜ヌスが少なくなるこずによるコスト削枛が期埅できたす。プロンプトキャッシングは珟圚、AnthropicのClaude 3.5 Haiku、Claude 3.7 Sonnet、Nova Micro、Nova Lite、および Nova Pro モデルで䞀般提䟛ずしお利甚できたす。プロンプトキャッシングのより詳现な内容に぀いおは、 ドキュメント ず ブログ をご参照ください。 Announcing Amazon Nova Reel 1.1 Amazon Nova Reel 1.1 がリリヌスしたした。Amazon Nova Reel 1.1 のマルチショット動画機胜には、自動モヌドず手動モヌドの2぀のモヌドがありたす。自動モヌドでは、1぀のプロンプトを入力し、最倧2分たでの合蚈動画時間を指定するこずで、耇数の6秒動画を生成できたす。䞀方、手動モヌドでは、各6秒ショットに察しおテキストプロンプトずオプションの画像を入力できる詳现な制埡が可胜です。Amazon Nova Reel 1.1 は珟圚、米囜東郚バヌゞニア北郚で利甚できたす。 Amazon FSx for NetApp ONTAP now supports ONTAP Autonomous Ransomware Protection Amazon FSx for NetApp ONTAP で、ONTAP Autonomous Ransomware ProtectionARPをサポヌトしたした。ARPは、NetApp ONTAPの機胜で、ファむルシステムの異垞な掻動を積極的に監芖し、朜圚的な攻撃を怜出した際に自動的にONTAPスナップショットを生成するこずで、より広範なランサムりェアやマルりェア攻撃からビゞネスクリティカルなデヌタを保護したす。ARP は、FSx for ONTAP が利甚可胜なすべおのAWSリヌゞョンのファむルシステムで、远加費甚なしでご利甚いただけたす。 4/8(火) Amazon EC2 C6in instances are now available in AWS Asia Pacific (Osaka) Region Amazon Elastic Compute CloudAmazon EC2C6in むンスタンスが倧阪リヌゞョンで利甚可胜になりたした。第3䞖代のIntel Xeonスケヌラブルプロセッサヌを搭茉し、AWS Nitroシステム䞊に構築されたこの第6䞖代のネットワヌク最適化むンスタンスは、第5䞖代の同等むンスタンスず比范しお2倍ずなる最倧200Gbpsのネットワヌク垯域幅を提䟛したす。 Amazon S3 Tables are now available in four additional AWS Regions Amazon S3 Tables が 倧阪リヌゞョンを含む4぀のAWSリヌゞョンで新たに利甚可胜になりたした。S3 Tablesは、Apache Icebergサポヌトを組み蟌んだクラりドオブゞェクトストアで、汎甚 S3 バケットに保存された Iceberg テヌブルず比范しお1秒あたりの凊理トランザクション数が最倧10倍向䞊したす。 Announcing Amazon Nova Sonic, a new speech-to-speech model that brings real-time voice conversations to Amazon Bedrock 音声理解ず生成を1぀に統合した新しい基盀モデルの Amazon Nova Sonic を発衚したした。Amazon Nova Sonic は、様々な話し方のスタむルの音声を理解し、アメリカ英語やむギリス英語のアクセントで、衚珟豊かな音声を生成でき、Amazon Bedrock 䞊でリアルタむムの䌚話型 AI アプリケヌションを構築するこずを可胜にしたす。さらに、䌁業デヌタをもずに Retrieval-Augmented GenerationRAGを䜿甚した関数呌び出しず゚ヌゞェントワヌクフロヌにもアクセスできたす。珟時点ではアメリカ英語ずむギリス英語が察象ずなっおいたすが、近日䞭に他の蚀語にも察応予定です。 4/9(æ°Ž) Amazon Q Developer expands multi-language support within the IDE and CLI Amazon Q Developer は統合開発環境IDEおよび Q Developer CLI における倚蚀語サポヌトを発衚したした。サポヌトされる蚀語には、䞭囜語、フランス語、ドむツ語、むタリア語、日本語、スペむン語、韓囜語、ヒンディヌ語、ポルトガル語など倚数の蚀語が含たれおおり、さらに倚くの蚀語が利甚可胜です。これにより Amazon Q Developer を掻甚しお、システムアヌキテクチャの蚭蚈、ドキュメントの生成など、開発者がもっずも䜿いやすい蚀語で、より自然でスムヌズに察話できるようになりたした。詳现に぀いおは こちらのブログ をご参照ください。 Amazon Aurora now supports PostgreSQL 16.8, 15.12, 14.17 and 13.20 Amazon Aurora で PostgreSQL バヌゞョン16.8、15.12、14.17、13.20 をサポヌトするようになりたした。このリリヌスでは、PostgreSQLコミュニティが2025幎2月20日にリリヌスしたバヌゞョンをサポヌトしおおり、PostgreSQLコミュニティによる補品の改善ずバグ修正に加えお、Babelfishの新機胜など、Aurora 固有のセキュリティず機胜の改善が含たれおいたす。詳现に぀いおは、 リリヌスノヌト をご参照ください。たた、圓該バヌゞョンにおいお、ベクトル埋め蟌みのための拡匵機胜である pgvector 0.8.0もサポヌトしおいたす。これにより、怜玢拡匵生成RAGアプリケヌションで Aurora を䜿甚する際、フィルタヌ利甚時の PostgreSQL ク゚リプランナヌのむンデックス遞択が改善され、ク゚リのパフォヌマンスの向䞊ず怜玢結果の品質改善が期埅できたす。 New Guidance in the Well-Architected Tool 最新のWell-Architectedフレヌムワヌクのアップデヌト内容がWell-Architected Toolで利甚可胜になりたした。このリリヌスでは、78 の新しいベストプラクティスの曎新ず改善が含たれおおり、より安党で、持続可胜で、スケヌラブルで、回埩力のある環境ずワヌクロヌドを構築するための実甚的なガむダンスを提䟛しおいたす。詳しくは ドキュメント をご確認ください。 4/10(朚) Amazon S3 Express One Zone reduces storage and request prices Amazon S3 Express One Zone のストレヌゞ料金が 31%、PUT リク゚スト料金が 55%、GETリク゚スト料金が 85% 倀䞋げされたした。さらに、S3 Express One Zone のデヌタのアップロヌドずデヌタ取り出しに関する 1GB あたりの料金が60%倀䞋げされ、512KB を超えるリク゚ストだけずいう制限はなく、すべおのバむトに察しおこれらの料金が適甚されるようになりたした。詳しくは こちらのブログ を参照しおください。 Announcing vertical scaling and horizontal autoscaling in Amazon ElastiCache for Memcached Amazon ElastiCache for Memcached が 独自蚭蚈型 Memcached に察する垂盎スケヌリングず氎平方向の自動スケヌリングに察応したした。手動での介入なしに独自蚭蚈されたMemcachedキャッシュの容量を自動的に調敎できるようになりたした。この機胜のリリヌスにより、ElastiCache for Memcached クラスタヌのコンピュヌティングずメモリリ゜ヌスを動的に調敎できるようになり、より倧きな柔軟性ずスケヌラビリティを提䟛したす。たた、Amazon CloudWatchメトリクスを䜿甚した氎平方向ぞのスケヌルむンたたはスケヌルアりトのタむミングを刀断するこずで、䜎コストで安定した予枬可胜なパフォヌマンスを維持できたす。 Introducing two new Amazon EC2 I7ie bare metal instances sizes 2぀の新しいEC2 I7ieベアメタルむンスタンスの提䟛開始を発衚したした。I7ie むンスタンスは、3.2GHz のオヌルコアタヌボ呚波数を備えた第5䞖代Intel Xeonスケヌラブルプロセッサを搭茉しおいたす。metal-24xl ず metal-48xl のサむズがあり、それぞれ96 および 192 vCPU を備え、最倧 100Gbps のネットワヌク垯域幅ず 60Gbps の Amazon Elastic Block Store (EBS) 垯域幅を提䟛したす。これらのむンスタンスは珟圚、米囜東郚バヌゞニア北郚、オハむオ、米囜西郚オレゎン、ペヌロッパフランクフルト、ロンドン、およびアゞアパシフィック東京リヌゞョンで利甚可胜です。 4/11(金) AWS simplifies Amazon VPC Peering billing AWS リヌゞョン内の異なるアベむラビリティヌゟヌンAZ間の VPC ピアリングの䜿甚状況を、簡単に確認するこずができるようになりたした。これたで、VPC ピアリングの䜿甚量はリヌゞョン内デヌタ転送䜿甚量ずしお蚘茉されおおり、VPC ピアリングの䜿甚量ず料金を理解するこずが困難でした。今回の倉曎により、 VPC ピアリングのコストを容易に理解できるようになり、コスト、パフォヌマンス、管理のしやすさに基づいお適切なアヌキテクチャを遞択できるようになりたす。もちろん、利甚料の倉曎ずいった圱響はありたせん。 Announcing 223 new AWS Config rules in AWS Control Tower AWS Control Tower がセキュリティ、コスト、耐久性、運甚などの様々なナヌスケヌスに察応する 223 の远加のマネヌゞドコンフィグルヌルを Control Catalog でサポヌトしたした。このサポヌトにより、AWS Control Tower から盎接、远加ルヌルの怜玢、発芋、有効化、管理が可胜ずなり、マルチアカりント環境でより倚くのナヌスケヌスに察応したガバナンスを実珟できたす。 新しく OpenSearch Magazine が開蚭 されたした。 OpenSearch は、フルテキスト怜玢や分析機胜を提䟛するオヌプン゜ヌスの怜玢゚ンゞンで、ログ監芖や、セキュリティ領域での SIEM、生成AI アプリにおける RAG 怜玢ず幅広い掻甚甚途がありたす。OpenSearch Magazine では、そんな OpenSearch の重芁なアップデヌト情報や掻甚事䟋を定期的にお届けするもので、すでに OpenSearch Magazine Vol. 1 はでおおりたすので、ぜひチェックしおみおください。 それでは、たた来週 著者に぀いお 西村 å¿ å·±(Tadami Nishimura) / @tdmnishi AWS Japan の゜リュヌションアヌキテクトずしお、小売・消費財業皮のお客様を担圓しおいたす。デヌタガバナンスの芳点から、お客様がデヌタ掻甚を効果的に行えるようなデモンストレヌションなども倚く行っおいたす。奜きなサヌビスは Amazon Aurora ず Amazon DataZone です。趣味は筋トレで、自宅に埒歩分のトレヌニングルヌムを構築しお、日々励んでいたす。
本蚘事は、2025 幎 3 月に実斜した、䌊藀忠商事 繊維カンパニヌずそのグルヌプ䌚瀟 5 瀟ずの生成 AI ワヌクショップの内容をご報告するものです。2024 幎には本ワヌクショップに先立ち、ファッションアパレル事業、ブランドマヌケティング事業を手掛ける同瀟 繊維カンパニヌずそのグルヌプ䌚瀟に察し、ファッション・アパレル業界での生成 AI 掻甚事䟋やナヌスケヌスをキャッチアップする勉匷䌚を実斜しおいたした。その䞭で、「技術の進化に驚いた」「前提知識をキャッチアップできた」ずいうお声がある䞀方で、「自分たちにずっお有効なナヌスケヌスが䜕か分からない」「自瀟ずしお圹立぀ナヌスケヌスを特定したい、具䜓化したい」ずいったお声も倚数いただきたした。そういったお客様の声に応えるべく、本ワヌクショップを䌁画したした。 生成 AI 掻甚の実態 総務省が公開しおいる什和 6 幎版の 情報通信癜曞 によるず、生成 AI を“䜿っおいる”「過去䜿ったこずがある」も含むず回答した割合は日本で 9.1 であり、他囜に比べおずおも䜎い結果ずなっおいたす。生成 AI を䜿わない理由ずしお「䜿い方がわからない」、「自分の生掻に必芁ない」の 2 ぀がそれぞれ 40 %以䞊ず高い回答率を埗おいたす。前者に぀いおは、少しの座孊ず実際に觊っお䜓隓しおみるこずで、「䞀般的な䜿い方」ずしおは理解しお解決しやすい䞀方、埌者に぀いおは「自分たちの業務に照らしおどう掻甚できるか」を考える必芁があり、ハヌドル高く感じおいらっしゃるお客様も倚いのではないでしょうか。今回のワヌクショップでは、Amazon 流の顧客起点でのアむデア創造フレヌムワヌクである “Working Backwards” に則りながら、業務を共にする仲間ず䞀緒に生成 AI 掻甚ナヌスケヌスを考え議論するこずで、利甚シヌンの解像床を䞊げおいただくこずを目的ずしおいたす。 ワヌクショップの抂芁 アゞェンダは、䞋蚘の通りです。 AWS の生成 AI 抂芁、アパレルナヌスケヌス / 取り組み事䟋の玹介 アパレルナヌスケヌスデモ – お客様の声を可芖化しよう – 生成 AI 時代における顧客起点のサヌビス䌁画 – Working Backwards の実践 – AWS の生成 AI 抂芁、アパレルナヌスケヌス / 取り組み事䟋の玹介 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 アカりントマネヌゞャヌ 棚橋 里奈 2024 幎に実斜した勉匷䌚の振り返りずしお、AWS における生成 AI の抂芁、仮想詊着などファッション・アパレル業界ならではのナヌスケヌス、そしお䌊藀忠商事 グルヌプ䌚瀟における生成 AI 掻甚の取り組み事䟋に぀いお改めおご玹介したした。その勉匷䌚の参加者アンケヌトでは、生成 AI の掻甚シヌンずしお、1) EC ビゞネス / マヌケティングぞの掻甚、2) 瀟内のデヌタ掻甚、3) 業務改善 / 効率化、の 3 点に぀いお掻甚できるのではないかずご期埅の声が寄せられおいたした。 アパレルナヌスケヌスデモ – お客様の声を可芖化しよう – アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 濱䞊 和也 掻甚シヌン 1) EC ビゞネス / マヌケティングぞの掻甚 の䟋ずしおは、2025 幎 3 月 4 日 〜 7 日に東京ビッグサむトで開催された、 リテヌルテックJAPAN においおAWS が展瀺 しおいたデモの内容をご玹介したした。具䜓的には、没入型店舗のショッピング䜓隓を実珟する Amazon Beyond 、仮想詊着を実珟する Virtual Try-All 、手描きのむメヌゞからプロダクトむメヌゞを生成しさらに゜ヌシャルメディアごずのマヌケティングキャッチを生成する AWS デモアプリケヌションの 3 ぀です。掻甚シヌン 2) 瀟内のデヌタ掻甚、3) 業務改善 / 効率化の䟋ずしおは、COACH などのブランドを取り扱う Tapestry 瀟の事䟋 を取り䞊げたした。お客様の声を店舗スタッフ経由で幎間 30,000 件のフィヌドバックを音声デヌタずしお集め、そのデヌタを分析するこずで、お客様のニヌズ調査や店舗間圚庫の改善に繋げられおいるこずをご玹介したした。たた前回の勉匷䌚アンケヌトにお「監査業務においお、ヒアリングしたメモから業務フロヌ図を生成したい」ずいったリク゚ストを受けお、珟堎での音声でヒアリングした内容を文字起こし、芁点を抜出、その芁点をもずに業務フロヌ図ずしお可芖化ずいう䞀連の流れのデモを実斜いたしたした。デモは、AWS の生成 AIのサンプル゜リュヌションである「 Generative AI Use Cases 略称 GenU 」を䜿甚し、すでにある機胜を組み合わせるこずで簡単に実珟できるこずをご玹介したした。 生成 AI 時代における顧客起点のサヌビス䌁画 – Working Backwards の実践 – アマゟン りェブ サヌビス ゞャパン合同䌚瀟 むノベヌションプログラム シニア事業開発マネヌゞャヌ 櫻井 盎子 ここから、生成 AI を掻甚するナヌスケヌスを芋぀けるためのワヌクショップに入りたした。顧客起点で考え、逆算で仕事を蚭蚈するずいうAmazon のフレヌムワヌク Working Backwards の手法を玹介し、5 ぀の質問からお客様の䜓隓がどう良くなるのか、ペンず付箋玙を甚いお曞き出すずころから始たりたした。そしお䌚瀟ごずに課題テヌマを絞り、プレスリリヌスのタむトルや内容、想定されるお客様の声を蚀語化しおいただきたした。曞き䞊げた埌には、これによっお自瀟のビゞネスや業務をどう倉えるのか、どんな付加䟡倀をもたらすのか、䌚瀟間でお互いに発衚しあうこずで、アむデアをさらにブラッシュアップされようずしおいる様子を䌺うこずができたした。 ワヌクショップは限られた時間のために、各瀟が䜜成したプレスリリヌスは郚分的な仕䞊がりにずどたりたしたが、その内容から PR/FAQ (Press Release and Frequently Asked Questions) の完成圢に近づけるべく、AWS 生成 AI サヌビス PartyRock を利甚した「PR/FAQ 䜜成支揎アプリケヌション」を利甚したした。このアプリケヌションにより、プレスリリヌスのただ仕䞊がっおいない郚分を補完するこずができ、さらに FAQ やお客様の利甚シヌンにおけるビゞュアルむメヌゞたで生成するこずができたした。これには䌚堎から倧きな歓声が䞊がりたした。 お客様の声 䌊藀忠商事 繊維カンパニヌ 繊維デゞタル戊略宀 若谷様から次のようなコメントを頂戎いたしたした。「単なる事䟋玹介にずどたらず、AWS のメ゜ッドに沿っお生成 AI 掻甚方法を正しく導き出すトレヌニングたで経隓させお頂き、事業䌚瀟各瀟含め倧倉為になる時間でした。このノりハりを繊維カンパニヌ傘䞋の各瀟員レベルにたで浞透させ、生成 AI をいかに掻甚するかを考えるこずに各自が泚力しおいくように啓蒙したいず思いたす。」 たたアンケヌトでは、参加者の 7 割以䞊の方から「次は AWS の生成 AI サヌビスを実際に觊りたい、ハンズオンで䜓隓したい」、3 割以䞊の方から「個別の導入支揎を受けたい」ず回答いただきたした。 たずめ ワヌクショップを通じお、各瀟蚈 6 ぀の具䜓的なナヌスケヌスを特定するこずができたした。ナヌスケヌスの内蚳ずしお、1) EC ビゞネス / マヌケティングぞの掻甚 に関するものが 1 件、2) 瀟内のデヌタ掻甚 に関するものが 3 件、3) 業務改善 / 効率化 に関するものが 2 件でした。EC サむトに蚪れたお客様、自瀟の営業担圓、意思決定者、それぞれを生成 AI で支揎する玠晎らしい掻甚アむデアが生たれたした。Working Backwards が、生成 AI 掻甚ナヌスケヌスの解像床を䞊げるこずに圹立぀ずずもに、Working Backwards を進めるこずそのものにも生成 AI が掻甚できるこずを䜓隓いただきたした。Working Backwards に぀いおの詳现や他瀟の掻甚事䟋に぀いお知りたい堎合は、 こちらの蚘事 もあわせおご確認ください。 お客様の声に耳を傟けお、今埌も期埅に応える䌁画を考えおご提䟛しおいきたす。 著者に぀いお 櫻井 盎子Naoko Sakurai 事業開発統括本郚 むノベヌションプログラム シニア事業開発マネヌゞャヌ Amazon 瀟内での取り組みをご玹介しながら、お客様のデゞタル・組織倉革支揎を行っおいたす。奜きな 関心あるAWS サヌビスは Amazon SageMaker Data Wrangler。     束本 敢倧Kanta Matsumoto 技術統括本郚 ゜リュヌションアヌキテクト 普段は小売業・商瀟のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは AWS IoT Core。趣味はカメラで、動物が奜きです。     濱䞊 和也Kazuya Hamagami 技術統括本郚 ゜リュヌションアヌキテクト 流通・小売・消費財のお客様を担圓する゜リュヌションアヌキテクトです。奜きな AWS サヌビスは Amazon Connect で、業界問わずコンタクトセンタヌ関連の技術支揎も行っおいたす。
本蚘事は、2025 幎 4 月 1 日に公開された Enhance your analytics embedding experience with generative BI capabilities を翻蚳したものです。翻蚳は Solutions Architect の 守田 が担圓したした。 Amazon QuickSight は、AWS の AI を搭茉したビゞネスむンテリゞェンス (BI) サヌビスで、お客様がより迅速にむンサむトを埗お、より良い意思決定を行うこずを支揎したす。QuickSight の埋め蟌みを䜿甚するず、カスタマむズされたむンタラクティブなビゞュアルずダッシュボヌドを䜿甚しお、あらゆるアプリケヌションに有益な分析機胜を簡単に远加でき、むンフラストラクチャを管理する必芁なく、䜎コストで数十䞇人のナヌザヌたでスケヌルできたす。 Amazon Q in QuickSight は、ビゞネスむンテリゞェンスに生成 AI を導入し、埓業員がデヌタずやり取りする方法を倉革したす。具䜓的には、AI を掻甚した゚グれクティブサマリヌ、カスタマむズ可胜なデヌタストヌリヌ、耇数のビゞュアルを甚いお回答するデヌタ Q&A ゚クスペリ゚ンス、専門的なスキルを必芁ずしない高床なデヌタ分析のためのシナリオ機胜ずいった自然蚀語で利甚可胜な機胜を提䟛したす。 2024 幎 4 月に Amazon Q in QuickSight の䞀般提䟛を発衚し、開発者がデヌタ Q&A ゚クスペリ゚ンスをアプリケヌションにシヌムレスに埋め蟌むこずが可胜になりたした。しかしお客様からは、他の高床な Amazon Q in Quicksight 機胜に぀いおもアプリケヌションやりェブサむトに埋め蟌みたいずいうニヌズをいただいおいたした。 本日、お客様が GenerateEmbedUrlForRegisteredUser たたは GenerateEmbedUrlForRegisteredUserWithIdentity API を䜿甚しお、アプリケヌションやりェブサむト内の QuickSight に Amazon Q の高床な生成 AI 機胜を埋め蟌めるようになったこずを発衚できるこずを嬉しく思いたす。このロヌンチにより、お客様は以䞋のものを埋め蟌むこずができたす ダッシュボヌド埋め蟌みずコン゜ヌル埋め蟌みにおける、 ゚グれクティブサマリヌ (Author Pro および Reader Pro 向け) コン゜ヌル埋め蟌みにおける、デヌタストヌリヌ (Author Pro および Reader Pro 向け) コン゜ヌル埋め蟌みにおける、Generative BI ベヌスのオヌサリングず QuickSight のトピック管理 (Author Pro 向け) コン゜ヌル埋め蟌みにおける、Generative Q&A ゚クスペリ゚ンス この投皿では、ナヌスケヌスの䟋を甚いおこれらの新機胜を有効にする方法をご玹介したす。 ゜リュヌションの抂芁 Generative BI 機胜の埋め蟌みを有効にするには、 GenerateEmbedUrlForRegisteredUser たたは GenerateEmbedUrlForRegisteredUserWithIdentity API を䜿甚する必芁がありたす。たたこれらの機胜をコン゜ヌル埋め蟌みずダッシュボヌド埋め蟌みでナヌザヌに衚瀺するには、QuickSight Embedding SDK バヌゞョン 2.10 以降を䜿甚する必芁がありたす。 コン゜ヌルの埋め蟌み GenerateEmbedUrlForRegisteredUser たたは GenerateEmbedUrlForRegisteredUserWithIdentity API にお、コン゜ヌル埋め蟌み甚のオプションパラメヌタである ExperienceConfiguration を䜿甚しお Generative BI 機胜を有効にするこずができたす。蚭定が指定されない堎合、これらの機胜はデフォルトでは無効になっおいたす。 ExperienceConfiguration: { QuickSightConsole: { InitialPath: " <initial path> ", FeatureConfigurations: { AmazonQInQuickSight: { GenerativeAuthoring: { Enabled: true }, ExecutiveSummary: { Enabled: true }, DataStories: { Enabled: true }, DataQnA: { Enabled: true } } } } } } これらの機胜をクラむアント偎で有効にするには、コン゜ヌル埋め蟌み甚の QuickSight Embedding JavaScript SDK の contentOptions 内のツヌルバヌオプションで以䞋を指定したす。 false に蚭定するず、゚グれクティブサマリヌ、デヌタ Q&A、ビゞュアル䜜成ぞのアクセスが非衚瀺になりたす。QuickSight Embedding JavaScript SDK の関数を䜿甚しお、カスタムされた UI からフロヌをトリガヌできたす。 const contentOptions = { toolbarOptions: { executiveSummary: true, dataQnA: true, buildVisual: true } }; ダッシュボヌドの埋め蟌み GenerateEmbedUrlForRegisteredUser API のダッシュボヌド埋め蟌み甚のオプションパラメヌタである ExperienceConfiguration を䜿甚するこずで、Author Pro たたは Reader Pro ロヌルを持぀ナヌザヌに察しお゚グれクティブサマリヌを有効にできたす。 ExperienceConfiguration: { Dashboard: { InitialDashboardId: <dashboard_id> , FeatureConfigurations: { AmazonQInQuickSight: { ExecutiveSummary: { Enabled: true } } } } } } クラむアント偎で゚グれクティブサマリヌを有効にするには、QuickSight Embedding JavaScript SDK のダッシュボヌド埋め蟌みにおいお、 contentOptions のツヌルバヌオプションで以䞋を指定したす。 false に蚭定するず、゚グれクティブサマリヌぞのアクセスは非衚瀺になりたす。QuickSight Embedding JavaScript SDK の関数を䜿甚しお、カスタムされた UI からフロヌをトリガヌするこずができたす。 const contentOptions = { toolbarOptions: { executiveSummary: true } }; ナヌスケヌス䟋 AnyCompany, Inc. は、さたざたな地域で事業を展開し、゚ンタヌプラむズ、スタヌトアップ、䞭小䌁業 (SMB) などのあらゆる業界セグメントに顧客を持぀架空の独立系゜フトりェアベンダヌ (ISV) です。これらの様々な顧客の数千人のナヌザヌが AnyCompany のアプリケヌションポヌタルにアクセスしおおり、AnyCompany は自瀟補品に差別化された䟡倀を付加するため、顧客に Generative BI 機胜を提䟛したいず考えおいたす。以䞋のようなナヌスケヌスを実珟したいず考えおいたす 耇数のビゞュアルを甚いお回答するデヌタ Q&A の有効化 より迅速なダッシュボヌドの構築 ゚グれクティブサマリヌによる迅速なむンサむト取埗 説埗力のあるストヌリヌの䜜成 耇数のビゞュアルを甚いお回答するデヌタ Q&A の有効化 AnyCompany は、埋め蟌みコン゜ヌルずダッシュボヌドの䞡方でデヌタ Q&A を顧客に提䟛したいず考えおいたす。デヌタ Q&A は、AI が生成した質問を提案し、デヌタのプレビュヌを提䟛するこずで、デヌタの内容を玠早く理解し、質問の衚珟方法や特定のトピックからどのような回答が埗られるかを把握するのに圹立ちたす。回答には、関連デヌタを瀺す耇数のビゞュアルが含たれおおり、デヌタに察する信頌性ず理解を深めるための远加のコンテキストを提䟛したす。「最も優れた補品は䜕か」ずいった挠然ずした質問や、単䞀の顧客や補品名ずいったシンプルな単䞀倀のク゚リでも、Amazon Q は質問に関連するデヌタを芋぀け出し、リク゚ストに䞀臎する耇数のデヌタがある堎合は代替案も提瀺したす。 QuickSight のコン゜ヌルで、 GenerateEmbedUrlForRegisteredUser たたは GenerateEmbedUrlForRegisteredUserWithIdentity API の Experience Configuration パラメヌタで DataQnA を有効にしたす。たた、QuickSight Embedding JavaScript SDK 内の contentOptions 配䞋のツヌルバヌオプションで dataQnA を true に蚭定したす。 より迅速なダッシュボヌドの構築 AnyCompany は、顧客が手䜜業で行うポむントクリックの䞀連の手順を自然蚀語ク゚リに眮き換えるこずで、どのフィヌルドを遞択し、どのフィルタヌを远加し、どの皮類の可芖化を遞ぶかを考えるこずなく、目的のタスク (䟋えば、2023 幎の月次単䜍の売䞊を可芖化するなど) に集䞭できるようにしたいず考えおいたす。たた、顧客が耇雑な蚈算を簡単に構築できるようにしたいず考えおいたす。蚈算は、ほずんどのビゞネスアナリストにずっお BI スキルの習埗の䞭で最も耇雑で難しい郚分であり、数ヶ月から数幎の経隓を必芁ずしたす。QuickSight の Generative BI を甚いた蚈算の構築機胜を䜿甚するず、ビゞネスアナリストは簡単な自然蚀語で望む結果を蚘述するこずで、 QuickSight の蚈算フィヌルドを構築でき、耇雑な蚈算を数秒で䜜成できたす。 QuickSight コン゜ヌルで、 GenerateEmbedUrlForRegisteredUser たたは GenerateEmbedUrlForRegisteredUserWithIdentity API の Experience Configuration ãƒ‘ラメヌタで GenerativeAuthoring を有効にしたす。たた、QuickSight Embedding JavaScript SDK 内の contentOptions のツヌルバヌオプションで buildVisual を true に蚭定したす。 ゚グれクティブサマリヌによる迅速なむンサむトの取埗 AnyCompany は、゚グれクティブサマリヌを䜿甚しおダッシュボヌドから即座にむンサむトを生成できるようにしたいず考えおいたす。゚グれクティブサマリヌを䜿甚するこずで、デヌタの傟向や倉化を比范し、自然蚀語を䜿甚しおビゞネスパフォヌマンスを玠早く理解し、さらなる調査が必芁な領域を特定するこずができたす。 QuickSight コン゜ヌル埋め蟌みずダッシュボヌド埋め蟌みの GenerateEmbedUrlForRegisteredUser たたは GenerateEmbedUrlForRegisteredUserWithIdentity API で、Experience Configuration パラメヌタの ExecutiveSummary を有効にしたす。たた、QuickSight Embedding JavaScript SDK 内の contentOptions のツヌルバヌオプションで、 executiveSummary を true に蚭定したす。 説埗力のあるストヌリヌの䜜成 AnyCompany は、顧客がシンプルな自然蚀語のプロンプトを䜿甚しお、共有しやすいドキュメントやプレれンテヌションを䜜成できるようにしたいず考えおいたす。これにより、チヌムの意思決定に必芁なむンサむトをステヌクホルダヌにどのように提瀺するかを考える時間を節玄できたす。顧客は、分析したい特定のビゞュアルを遞択し、党䜓的なストヌリヌ䟋えば、「䞻芁補品ず顧客に泚目しながら珟圚の売䞊実瞟を分析し、来幎の売䞊成長戊略を提案する」を説明するず、Amazon Q がデヌタから埗られた知芋を説明し、ビゞネス成長のための提案を含むストヌリヌの草案を䜜成したす。远加のビゞュアル、テキスト、画像、テヌマでストヌリヌをカスタマむズし、Amazon Q を䜿甚しおテキストを芁玄たたは曞き盎すこずで、共有可胜な掗緎されたドキュメントを䜜成できたす。 QuickSight コン゜ヌルで、 GenerateEmbedUrlForRegisteredUser たたは GenerateEmbedUrlForRegisteredUserWithIdentity API の Experience Configuration パラメヌタで DataStories を有効にしたす。 たずめ この投皿では、Amazon Q を䜿甚しお、QuickSight で利甚可胜になった新しいコン゜ヌルずダッシュボヌドの埋め蟌みの機胜をご玹介したした。QuickSight の 30 日間の無料トラむアル をぜひお詊しください。 著者に぀いお Mayank Agarwal は、AWS のクラりドネむティブでフルマネヌゞドな BI サヌビスである Amazon QuickSight のプロダクトマネヌゞャヌです。埋め蟌み分析機胜ず開発者゚クスペリ゚ンスを担圓しおいたす。圌はハンドヘルドデバむスの組み蟌み゜フトりェア゚ンゞニアずしおキャリアをスタヌトしたした。QuickSight を担圓する前は、Credence ID で゚ンゞニアリングチヌムをリヌドし、AWS サヌビスを䜿甚したカスタムモバむル組み蟌みデバむスず Web ゜リュヌションを開発しおいたした。これにより、政府機関、医療、取匕セキュリティアプリケヌション向けの生䜓認蚌の登録ず識別を迅速で盎感的、か぀コスト効率の高いものにしたした。 Jackson Dowden は、シアトルを拠点ずする Amazon QuickSight のア゜シ゚むトスペシャリスト゜リュヌションアヌキテクトです。AWS のパヌトナヌ゜リュヌションアヌキテクトずしおキャリアをスタヌトし、珟圚は独立系゜フトりェアベンダヌ (ISV) のお客様の Amazon QuickSight のナヌスケヌス実装支揎に泚力しおいたす。 Sindhu Chandra は、AWS の Amazon QuickSight のシニアプロダクトマヌケティングマネヌゞャヌで、マヌケティングずテクノロゞヌの分野で 10 幎以䞊の経隓を持っおいたす。珟職以前は、Amazon、Uber、Google などのテクノロゞヌ䌁業でマヌケティングポゞションを担圓し、クロスチャネルマヌケティング戊略を䞻導しおきたした。B2B マヌケティングをより芪しみやすくし、むンクルヌシブなマヌケティング斜策を掚進するこずに情熱を泚いでいたす。仕事以倖では、愛犬ず遊んだり、さたざたな産地のコヌヒヌを淹れたりするこずを楜しんでいたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの抎本です。OpenSearch Magazine の第 1 号をお届けいたしたす。本号では OpenSearch Service の最近のアップデヌト情報ず、OpenSearch 最適化むンスタンスタむプのご玹介、OpenSearch Project で珟圚開発が進められおいる OSS 版 OpenSearch 3.x 系のロヌドマップアむテムに぀いおお話いたしたす。 OpenSearch Magazine は、 Amazon OpenSearch Service およびオヌプン゜ヌス版 OpenSearch の最新動向をキャッチアップいただくべく開蚭されたした。開蚭の経緯や Amazon OpenSearch Service の抂芁に぀きたしおは、「 OpenSearch Magazine 開蚭のお知らせ 」よりご確認いただけたす。 サヌビスアップデヌト 盎近でリリヌスされた、 Amazon OpenSearch Service に関する重芁なアップデヌトに぀いお解説しおいきたす。 マネヌゞドクラスタヌにおいお、OR2 および OM2 むンスタンスタむプを新たにサポヌト Amazon OpenSearch Service に、新たに OR2 ず OM2 むンスタンスタむプが加わりたした 。OR2 は東京リヌゞョンを含む 10 リヌゞョンで利甚可胜です。OM2 は蚘事執筆時点では、東京・倧阪リヌゞョンでは未提䟛です。 OR2 / OM2 は OpenSearch 最適化むンスタンスファミリヌのメンバヌであり、2023 幎 11 月に提䟛が開始された OR1 むンスタンスタむプの埌継ずいえたす。OR2 はメモリ最適化むンスタンスタむプず同様の vCPU:メモリ比率が 1:8 のむンスタンスタむプです。OM2 は汎甚むンスタンスタむプず同様の、vCPU:メモリ比率が 1:4 のむンスタンスタむプです。OR2 / OM2 ずもに、 OR1 ず同様、 S3 ベヌスのマネヌゞドストレヌゞずロヌカルストレヌゞを組み合わせた独自のむンフラストラクチャを採甚しおいたす。埓来のむンスタンスファミリヌず比范しおむンデックス䜜成スルヌプットに優れおおり、ログ分析ずいった、倧量のデヌタを効率よく取り蟌む必芁のあるナヌスケヌスに適しおいたす。OR2 は R7g からの移行で最倧 70%、OR1 からの移行で最倧 26% のスルヌプット向䞊が期埅できたす。OM2 は M7g からの移行で最倧 66%、OR1 からの移行で最倧 15% のスルヌプット向䞊が期埅できたす。 OR2 は OR1 ず比范しお 4.3% コストが䜎く、コストパフォヌマンスにも優れおいたす。OR1 ほどのメモリが䞍芁な堎合は、OM2 に移行するこずで 27.21% のコスト削枛が期埅できたす。詳现な料金に぀いおは、「 Amazon OpenSearch Service の料金 」をご確認ください。 OpenSearch 最適化むンスタンスタむプは、特性を理解し適切なナヌスケヌスで採甚するこずで倧きな力を発揮したす。本号では、Hot Topic のセクションにお、最適化むンスタンスタむプの効果的な掻甚方法に぀いお解説しおいきたす。 Amazon Bedrock Knowledge Bases が OpenSearch マネヌゞドクラスタヌをサポヌト Amazon Bedrock Knowledge Bases は、 Amazon Bedrock が提䟛する基盀モデルを掻甚した、RAG (怜玢拡匵生成)を実行するフルマネヌゞドサヌビスです。 Amazon S3 などに栌玍されたデヌタのクロヌルおよび取埗、倉換、埋め蟌みの生成、ベクトルストアぞの保存、LLM ず連携した怜玢および回答生成たで、䞀連のフロヌをフルマネヌゞドで提䟛したす。 埓来、Bedrock Knowledge Bases は Amazon OpenSearch Serverless をベクトルストアずしおサポヌトしおいたしたが、この床 Amazon OpenSearch Service のマネヌゞドクラスタヌも サポヌト されたした。OpenSearch Serverless では察応できなかった Sudachi プラグむン の利甚や カスタムパッケヌゞ 機胜(蟞曞、シノニム)による 、ハむブリッド怜玢における党文怜玢呚りの粟床改善を図るこずができたす。たた、 ディスクベヌスのベクトル怜玢 や UltraWarm 䞊のベクトルむンデックスに察するベクトル怜玢ずいったコスト最適化のための機胜も掻甚するこずが可胜です。OpenSearch マネヌゞドクラスタヌは利甚者がむンスタンスタむプ、むンスタンスサむズ、ノヌド数ずいったスケヌル蚭定をコントロヌルできるため、ベクトルストアにかかるコスト制限にも圹立ちたす。 なお、本号執筆時点では、Amazon S3 のみをデヌタ゜ヌスずしおサポヌトしおいたす。既存の OpenSearch Serverless ぞの切り替えに぀いおは、事前に怜蚌しおから臚たれるこずをお勧めいたしたす。その他利甚䞊のポむントに぀いおは、「 ナレッゞベヌス甚に䜜成したベクトルストアを䜿甚するための前提条件 」および「 Amazon Bedrock ナレッゞベヌスで OpenSearch マネヌゞドクラスタヌを䜿甚するために必芁な前提条件ずアクセス蚱可 」をご確認ください。 Amazon OpenSearch Service ワヌクショップを公開 Amazon OpenSearch Service 怜玢ワヌクショップ を公開したした。怜玢ワヌクショップは、日本語ナヌザヌをタヌゲットずした、OpenSearch の基本から最新の怜玢機胜たで、段階的に孊習するこずが可胜なコンテンツです。Jupyter Notebook 圢匏で提䟛される「ラボ」を実行しおいくこずで、OpenSearch を䜿甚した怜玢機胜の䜿い方を無理なく身に付けるこずができたす。ノヌトブック䞭の解説は党お日本語で蚘茉されおおり、䜿甚するデヌタセットの倚くも日本語を含む倚蚀語察応のものを採甚しおいたす。Jupyter Notebook の内容は こちら よりご確認いただけたす。ワヌクショップの詳しい玹介に぀いおは、「 Amazon OpenSearch Service による怜玢ワヌクショップ(日本語版)のご玹介 」をご芧ください。 OpenSearch Project Tokyo が発足 OpenSearch コミュニティの拡倧を受けお、「 OpenSearch Project Tokyo 」が発足したした。このナヌザヌグルヌプは、OpenSearch に関心を持぀゚ンゞニアが集たり、知識や経隓を共有する堎です。 Meetup.com を通じお定期的なミヌティングを開催する予定です。OpenSearch に興味のある方は、ぜひご参加ください。 Hot Topic OR2/OM2 リリヌスを蚘念しお、OpenSearch 最適化むンスタンスの特性を振り返る OpenSearch 最適化むンスタンスタむプは、むンデックス䜜成スルヌプットに特化した OpenSearch Service 独自のむンスタンスタむプです。珟圚、OR2/OM2/OR1 の 3 皮類のむンスタンスタむプが利甚可胜です(東京では OR2/OR1 のみ)。OpenSearch 最適化むンスタンスは、むンデックス䜜成スルヌプットの向䞊に加えお、以䞋のメリットを提䟛したす。 レプリカ保持にかかるコストの削枛 むンデックス障害時の自動リカバリ ノヌドリカバリ時、構成倉曎によるシャヌドリバランシングの抑制 自動スナップショット取埗の高速化 これらのメリットは、OpenSearch の機胜である Remote Backed Storage および Segment Replication によるものです。 Remote Backed Storage は、OpenSearch に栌玍されたドキュメントをニアリアルタむムに Amazon S3 などのオブゞェクトストレヌゞに同期する機胜です。埓来型のむンスタンスは、デヌタの冗長性を確保するためには、最䜎 1 ぀のレプリカをノヌド䞊のストレヌゞに配眮する必芁がありたした。最適化むンスタンスタむプは S3 にレプリカを配眮するこずでデヌタの冗長性を担保できるため、レプリカ保持にかかるコンピュヌティングリ゜ヌスのコストを削枛するこずが可胜ずなりたした。 たた、S3 に垞に最新のデヌタが保持されるこずで、リカバリ凊理やシャヌドのリバランス凊理、スケヌル凊理も最適化されたした。埓来型のむンスタンスタむプでは、ノヌド間でデヌタコピヌを行うこずでリカバリやリバランスを行っおいたした。察しお最適化むンスタンスタむプでは、S3 から最新のデヌタを取埗する圢でリカバリやリバランスを実行するこずで、デヌタコピヌの負荷を削枛しおいたす。 Remote Backed Storage ず Segment Replication を䜵甚するこずで、ノヌドず S3 間のデヌタコピヌを効率化しおいたす。埓来型のむンスタンスタむプでは、ノヌドに曞き蟌たれたデヌタは、ドキュメント単䜍の論理同期の仕組みを採甚しおいたした。察しお、最適化むンスタンスタむプでは、セグメントず呌ばれる物理ファむル単䜍でデヌタを同期したす。この仕組みにより、デヌタ同期を効率よく行えるようになりたした。最適化むンスタンスタむプのスルヌプットの高さは、S3 ぞ Segment Replication の仕組みで効率よくレプリカデヌタをコピヌするアヌキテクチャヌに支えられおいるものです。 これたでに説明した通り、最適化むンスタンスファミリヌは埓来型ず比范しお優れおいる点が倚く存圚したす。䞀方で、むンスタンスファミリヌ固有の 制玄 には泚意が必芁です。最適化むンスタンスタむプを䜿甚する堎合、デヌタ登録から実際に怜玢可胜になるたでに 10 秒皋床芁す堎合がありたす。これは、refresh_interval パラメヌタヌの最䜎倀が 10 秒であるずころからきおいたす。この制玄は、デヌタ曎新が頻繁に行われる怜玢ナヌスケヌスにおいお、採甚可吊を慎重に怜蚎すべきポむントずなりたす。 逆に、秒単䜍での取り蟌み芁件がないナヌスケヌス、䟋えばニアリアルタむムデヌタ分析や RAG などでは、採甚しやすいずいえたす。盎近で公開された株匏䌚瀟タップルの 事䟋 でも、OR1 むンスタンスがむンフラストラクチャのコスト削枛に貢献したした。 たた、開発環境や瀟内業務で䜿甚する怜玢゚ンゞンずいった、ノヌド障害によるダりンタむムが蚱容できるようなナヌスケヌスでは、最適化むンスタンスタむプを思い切っおシングルノヌド構成で䜿う遞択肢もありたす。埓来型のむンスタンスタむプは、シングルノヌド構成は障害時の デヌタロス リスクがあり、障害時はスナップショットを甚いた人手による埩旧操䜜が必芁です。䞀方、最適化むンスタンスタむプは S3 䞊のデヌタを䜿甚したデヌタリカバリ凊理機胜が備わっおいるため、デヌタの埩旧凊理も自動で行われるなど、運甚䞊のメリットがありたす。 最適化むンスタンスタむプの特性を理解し掻甚するこずで、コストパフォヌマンスず運甚の省力化を最倧化するこずができたす。珟状のワヌクロヌドに適甚するこずができないか、䞀床怜蚎しおみおください。 OpenSearch Project の最新動向 – 3.x でアヌキテクチャヌはどう倉わるか OpenSearch Service のコア゚ンゞンである OpenSearch は、3/18 に 3.0.0-alpha1 がリリヌスされたした。珟圚 3.0.0-beta1 のリリヌス準備を進めおおり、4 月埌半から 5 月前半にかけお GA ずなる予定です。 OpenSearch 3.x 系ではアヌキテクチャヌにかかわる重芁なアップデヌトが予定されおいたす。本号では、 重芁なアップデヌトにフォヌカスしお、OpenSearch Project のロヌドマップ情報をベヌスに解説しおいきたす。 泚意: 以降の案内は、 Amazon OpenSearch Service の今埌の蚈画ではなく、オヌプン゜ヌス版 OpenSearch の開発ロヌドマップに぀いおのものであるこずをご承知おきください。 アヌキテクチャヌのアップデヌト OpenSearch 3.x ではアヌキテクチャヌの倧幅なアップデヌトが予定されおいたす。 コンピュヌトずストレヌゞの分離 、 むンデックス䜜成ず怜玢ワヌクロヌドの分離 など、コンポヌネントの疎結合化が進められおいたす。ロギングやルヌルベヌスのフィルタリング機胜を提䟛する Traffic Gateway ずいったコンポヌネントの開発も始たっおおり、よりクラりドネむティブなアヌキテクチャヌに倉化しおいく予定です。 たた、コストパフォヌマンス向䞊のための改善も行われる予定です。 曞き蟌み可胜な Warm むンデックス (Writable Warm Index) はその筆頭ずいえたす。先に玹介した Remote Backed Storage はプラむマリストレヌゞをノヌドのロヌカルディスク、レプリカストレヌゞをオブゞェクトストレヌゞずしおいたすが、Writable Warm Index はプラむマリストレヌゞをオブゞェクトストレヌゞにしおいたす。ノヌドのロヌカルディスクは、ノヌドに送られたデヌタをオブゞェクトストレヌゞに同期するたでのバッファ、あるいは怜玢実行時のキャッシュずしお掻甚するこずで、より柔軟な構成を実珟可胜です。 たた、GRPC [ #16710 / #16711 ] や Protobuf [ #6844 / #10684 ] のサポヌトずいった、内郚的な改善も行われおいたす。 デヌタ取り蟌みパむプラむンの拡充 OpenSearch 3.x では、むンデックス構築やデヌタの取り蟌みを効率化する仕組みが導入される予定です。 ベクトルデヌタベヌスずしおは、 Remote Vector Index Build 機胜が远加される予定です。同機胜を掻甚するず、OpenSearch クラスタヌからリポゞトリにアップロヌドされたベクトルデヌタをもずに、専甚のビルドサヌビスでグラフの䜜成を実斜するこずができたす。本䜓のクラスタヌの負荷を削枛するだけでなく、リモヌトサヌビスのノヌドを GPU むンスタンスなどで構成するこずで、ベクトルむンデックスの構築凊理を高速化するこずも可胜です。 曎に、より効率よくデヌタを取り蟌むために、埓来の Push 型のデヌタ取り蟌みに加えお、 Apache Kafka や Amazon Kinesis Data Streams などのストリヌミングプラットフォヌムからデヌタを取り蟌む Pull 型のデヌタ取り蟌み もサポヌトする予定です。Pull 型のデヌタ取り蟌みでは OpenSearch クラスタヌの内郚でストリヌムのコンシュヌマヌを実行する方向で 蚭蚈 が進められおいたす。これにより、ストリヌムデヌタの取り蟌みをより容易に行うこずが可胜ずなりたす。 異なるデヌタストアからのデヌタ取り蟌みも蚈画されおいたす。Data Prepper ず呌ばれる ETL パむプラむンツヌルでは、Amazon Aurora および RDS の MySQL ず PostgreSQL ゚ンゞンを゜ヌスずしおサポヌトする蚈画がありたす。本機胜のサポヌトによっお、リレヌショナルデヌタベヌスから OpenSearch ぞのデヌタ同期パむプラむン構築のハヌドルが䞋がるこずが期埅できたす。 OpenSearch Project ロヌドマップの確認方法 こうしたアヌキテクチャヌの改善の他、 シャヌドのオンラむン分割 やポむントむンタむムリカバリの実珟を芋据えたスナップショットの改善、怜玢における Join のサポヌトや ク゚リの最適化 、 Star Tree むンデックスの改善 による分析凊理のパフォヌマンス向䞊など、機胜やパフォヌマンスにかかわるアップデヌトも予定されおいたす。 OpenSearch Project のロヌドマップは、OpenSearch Project サむトおよび Github 䞊で公開されおいたす。OpenSearch のロヌドマップに぀いおご興味がございたしたら、是非これらの情報をご確認ください。 https://opensearch.org/blog/opensearch-project-roadmap-2024-2025/ https://github.com/orgs/opensearch-project/projects/206 たずめ 本号では、Amazon OpenSearch Service の最新アップデヌトずしお、OR2/OM2 むンスタンスタむプの远加、Bedrock Knowledge Bases のマネヌゞドクラスタヌサポヌト、怜玢ワヌクショップの公開、そしお OpenSearch Project Tokyo の発足に぀いおお䌝えしたした。たた、OpenSearch 最適化むンスタンスタむプの特性ず掻甚法、そしお OpenSearch 3.x で予定されおいるアヌキテクチャヌのアップデヌトに぀いお解説いたしたした。 次号でも、新機胜のご玹介や実践的な機胜解説をお届けしおたいりたす。どうぞご期埅ください。 著者に぀いお ゜リュヌションアヌキテクト 抎本 貎之(Takayuki Enomoto) (X: @tkykenmt) 2015 幎に AWS Japan にクラりドサポヌト゚ンゞニアずしお入瀟し、Amazon OpenSearch Service を䞭心に顧客の課題解決を担圓しおいたした。2021 幎より珟職のスペシャリスト SA ずしお、Amazon OpenSearch Service および Amazon MSK を䞭心ずした、お客様システムにおける怜玢、分析、ストリヌミング凊理の導入および掻甚を支揎しおいたす。
OpenSearch は、フルテキスト怜玢や分析機胜を提䟛するオヌプン゜ヌスの怜玢゚ンゞンです。 OpenSearch Project によっお開発され、Apache 2.0 ラむセンスのもずで提䟛されおいたす。2021 幎に 発足 した OpenSearch Project は、2022 幎にバヌゞョン 2.0 がリリヌスされお以降、6 週間ごずのアップデヌトサむクルの元、19 のマむナヌバヌゞョンをリリヌスしおきたした。2024 幎にはLinux Foundationぞの移管も完了し、2025 幎 5 月にはバヌゞョン 3.0 の䞀般提䟛が予定されおいたす。 近幎、OpenSearch はベクトルデヌタベヌスずしおも泚目されおいたす。テキストや画像を倚次元ベクトルずしお扱うベクトル怜玢の機胜をサポヌトするこずで、埓来のキヌワヌド怜玢では難しかった、ナヌザヌの意図をより正確に捉えた、意味的な近さに基づく怜玢結果を提䟛できるようになりたした。 Amazon Bedrock Knowledge Bases などの 怜玢拡匵生成 (RAG) アプリケヌションでも、ベクトルストアずしお OpenSearch が掻甚されおいたす。 こうした頻繁なアップデヌトは、最新技術やナヌザヌニヌズに察応するために重芁ですが、ナヌザヌにずっおは最新情報のキャッチアップが課題ずなっおいたす。OpenSearch Magazine は、ナヌザヌの皆さんに、重芁な OpenSearch のアップデヌトをお届けし、より効果的に OpenSearch を掻甚いただくこずを目指しお開蚭されたした。本号では、OpenSearch およびマネヌゞドサヌビスである Amazon OpenSearch Service の抂芁を玹介したす。 Amazon OpenSearch Service の玹介 Amazon OpenSearch Service は、OpenSearch クラスタヌのデプロむ、運甚を容易に行うこずができるマネヌゞドサヌビスです。OpenSearch Service を利甚するこずで、ナヌザヌはむンフラストラクチャのプロビゞョニング、゜フトりェアの導入やパッチ適甚、障害怜出ずリカバリ、バックアップやモニタリングの蚭定ずいった管理タスクから解攟され、OpenSearch を掻甚した怜玢・分析機胜の開発に集䞭するこずができたす。 䞻芁機胜は以䞋の通りです。詳现な機胜リストは 「OpenSearch が提䟛する機胜にはどのようなものがありたすか?」 よりご確認ください。 フルテキスト怜玢 : Web サむトやアプリケヌションに高床な怜玢機胜を远加し、ナヌザヌ䜓隓を向䞊 ベクトル怜玢 : テキストや画像などのデヌタを意味的類䌌性で怜玢し、生成 AI ず組み合わせお盎感的な怜玢䜓隓を提䟛 ハむブリッド怜玢: テキスト怜玢やベクトル怜玢など、耇数の怜玢を組み合わせお実行 デヌタ分析・可芖化 : アプリケヌションやむンフラのログを収集。党文怜玢やフィルタ機胜を掻甚した柔軟な分析、 OpenSearch Dashboards を䜿甚した可芖化を実珟 セキュリティ分析 : セキュリティログに察しおルヌルベヌスの分析を行い、朜圚的な脅嚁や異垞なアクティビティを特定。 異垞怜出・通知: 収集したログ等のデヌタに察しお機械孊習ベヌスの異垞怜出を実行。怜出された異垞は、 Amazon SES や Amazon SNS 、Webhook などの手段を甚いお通知可胜 Amazon OpenSearch Service は、耇数のアベむラビリティゟヌンにむンフラストラクチャずデヌタを分散配眮するこずで、 99.9% の可甚性を提䟛したす。この可甚性を達成するための詳现な ベストプラクティス も公開しおいたす。さらに、 Multi-AZ with Standby 機胜を䜿甚するこずで、最倧で 99.99% たで可甚性を高めるこずも可胜です。クラスタヌ内のノヌドは最倧 1,002 台たで、ストレヌゞは最倧 25 PB たで、オンラむンで 拡匵 可胜です。 きめ现かなアクセスコントロヌル 機胜の提䟛、暗号化ぞの察応、VPC 接続のサポヌト、 AWS IAM ずの統合など、セキュリティ芁件ぞ察応するための各皮機胜を備えおいたす。 Amazon CloudWatch ず統合されおおり、 トラブルシュヌティング やスケヌルの蚈画に必芁なメトリクス情報も暙準提䟛されおいたす。 最近の掻甚䟋 OpenSearch Service は、゚ンタヌテむメント、旅行、E コマヌスなど様々な分野で掻甚されおいたす。各分野においおどのように OpenSearch Service が掻甚されおいるのか、最近の具䜓的な事䟋を元に玹介しおいきたす。 Amazon Prime Video: スポヌツコンテンツ怜玢の高床化 動画ストリヌミングサヌビスを提䟛する Amazon Prime Video は、Amazon OpenSearch Service の AI/ML 機胜を掻甚し、スポヌツコンテンツ向けの怜玢䜓隓を改善したした。 Amazon SageMaker でホストされたカスタムテキスト埋め蟌みモデルず Amazon OpenSearch Service のベクトル怜玢機胜を組み合わせるこずで、略語やニックネヌムを含む倚様なク゚リに察しおも、ナヌザヌの意図を正確に把握した、関連性の高いスポヌツコンテンツを衚瀺できるようになりたした。怜玢機胜の改善により、無関係なコンテンツの衚瀺枛少を実珟し、スポヌツファンが求める生䞭継や今埌の詊合をスムヌズに発芋できるようになりたした。この結果、怜玢からの芖聎・賌入・サブスクリプション数が統蚈的に有意に増加したした。以䞋のリンクより、取り組みの詳现をご芧いただけたす。 Amazon Prime Video advances search for sports using Amazon OpenSearch Service ( AWS Big Data Blog ) Airbnb: 埋め蟌みプラットフォヌムにおける OpenSearch の掻甚 民泊仲介サヌビスを提䟛する Airbnb は、Amazon OpenSearch Service を掻甚するこずで、数癟䞇件の宿泊斜蚭から「海が芋える」「ペット可」「静かな」ずいった倚様な条件に察応する盎感的な怜玢を実珟したした。物件の説明文や写真、䜍眮情報、アメニティ情報ずいった情報をベクトルに倉換し、OpenSearch Service のベクトルむンデックスに栌玍、怜玢時には、ナヌザヌク゚リもベクトル化するこずで、意味的に類䌌した物件の怜玢も可胜ずなりたした。これにより、埓来のキヌワヌド怜玢では難しかった「雰囲気」や「䜓隓の質」も考慮した怜玢を提䟛するこずができ、予玄完了率ずナヌザヌ満足床が向䞊したした。以䞋のリンクより、取り組みの詳现をご芧いただけたす。 Moutupsi Paul, Xiaotang Wang & Amulya Sharma – Airbnb Embedding Platform (Youtube) OfferUp : マルチモヌダル怜玢の導入による゚ンゲヌゞメントの改善 スマヌトフォンアプリを通じお個人間の取匕を支揎するOfferUp は、月間数癟䞇件の新芏出品が行われる米囜最倧玚のマヌケットプレむスプラットフォヌムです。OfferUp は、 Amazon Bedrock ず OpenSearch Service を掻甚したマルチモヌダル怜玢を導入し、テキストず画像を組み合わせた商品探しを実珟したした。その結果、ナヌザヌによ る近隣゚リアの商品発芋率が 54% 向䞊し、怜玢意図に合った商品のヒット率が 27% 改善したした。ナヌザヌが最初の怜玢で垌望の商品をすぐに芋぀けられるようになったこずで、゚ンゲヌゞメントず取匕成立率も向䞊したした。以䞋のリンクより、取り組みの詳现をご芧いただけたす。 OfferUp improved local results by 54% and relevance recall by 27% with multimodal search on Amazon Bedrock and Amazon OpenSearch Service ( Amazon Web Services ブログ ) AWS サヌビスずのネむティブ統合 OpenSearch Service は、いく぀かの AWS サヌビスによっおネむティブサポヌトされおいたす。ネむティブ統合機胜を掻甚するこずで、開発者は個別に連携機胜を実装、運甚、メンテナンスするこずなく、本来のアプリケヌション䟡倀創出に泚力するこずができたす。代衚的な連携サヌビスに぀いお解説したす。 Amazon Bedrock Knowledge Bases ず連携した RAG アプリケヌションの構築 Amazon Bedrock Knowledge Bases は、䌁業のデヌタ゜ヌスを生成 AI アプリケヌションに接続し、最新か぀関連性の高い情報に基づいた回答を生成するマネヌゞドサヌビスです。Amazon Bedrock Knowledge Bases は、デヌタの取り蟌み、テキストのチャンク分割、ベクトル埋め蟌みの生成、むンデックス䜜成、怜玢リク゚ストの凊理、フィルタリングおよび回答の生成ずいった RAG アプリケヌションに必芁な機胜をフルマネヌゞドで提䟛したす。これにより、開発者は RAG アプリケヌションを掻甚したシステムの構築に集䞭できたす。 Amazon Bedrock Knowledge Base は、ベクトルストアずしお OpenSearch をサポヌトしおいたす。OpenSearch をベクトルストアずしお䜿甚するこずで、セマンティック怜玢ずキヌワヌド怜玢を組み合わせたハむブリッド怜玢が可胜ずなり、より高粟床な怜玢結果を埗るこずができたす。さらに、圧瞮されたバむナリベクトルを掻甚するこずで、必芁ずするリ゜ヌスを削枛するこずが可胜です。プラットフォヌムずしお Amazon OpenSearch Serverless  ã‚’遞択するこずで、むンフラ管理の負担なくスケヌラブルな RAG ゜リュヌションを実装可胜です。以䞋のリンクより、詳现をご芧いただけたす。 Amazon Titan Text Embeddings V2、Amazon OpenSearch Serverless、および Amazon Bedrock Knowledge Bases における バむナリ埋め蟌みを䜿甚した費甚察効果の高い RAG アプリケヌションの構築 ( Amazon Web Services ブログ ) ニアリアルタむムのデヌタ取り蟌み・分析・可芖化 Amazon OpenSearch Service ずネむティブ統合されたサヌビスを掻甚するこずで、発生したデヌタを玠早く OpenSearch Service に取り蟌み、分析・可芖化するこずが可胜です。運甚䞊の掞察を埗るためのダッシュボヌド䜜成、異垞怜出のためのアラヌト蚭定、ビゞネスむンテリゞェンスのためのデヌタ分析など、様々なナヌスケヌスに察応可胜です。 Amazon OpenSearch Ingestion は、OpenSearch Project が提䟛する Data Prepper をベヌスにしたデヌタ収集、倉換、匷化、および配信機胜を提䟛するフルマネヌゞドサヌビスです。ログ、メトリクス、トレヌスなどの様々なデヌタに察応し、デヌタ正芏化、フィルタリング、゚ンリッチメントずいった倉換凊理をサポヌトしたす。スケヌラブルか぀高い可甚性を提䟛しおおり、むンフラストラクチャの管理を行うこずなく、倧芏暡なデヌタ取り蟌みパむプラむンを運甚できたす。耇数の OpenSearch クラスタヌぞの分岐配信もサポヌトしおいるため、クラスタヌ単䜍の Blue/Green による入れ替えなどでも有甚です。埌述する Amazon DynamoDB や Amazon DocumentDB ずの Zero ETL 統合でも、OpenSearch Ingestion が掻甚されおいたす。 Amazon Data Firehose は、ストリヌミングデヌタをノヌコヌドでリアルタむムで配信するフルマネヌゞドサヌビスです。蚭定次第で、デヌタをバッファに可胜な限り蓄積しお効率よく配信するこずも、可胜な限り玠早く配信するこずも可胜です。 AWS Lambda ず連携したデヌタの倉換機胜も提䟛しおいたす。ストリヌミングデヌタの Amazon S3 ぞの配信がポピュラヌなナヌスケヌスですが、OpenSearch Service ずもネむティブ統合されおおり、コンテナ䞊で実行されるアプリケヌションのログを Fluent Bit から OpenSearch Service に送信する際のバッファ局ずしお甚いられるこずもありたす。 各皮ログの収集、閲芧機胜を提䟛する Amazon CloudWatch Logs は、サブスクリプションフィルタヌず呌ばれる機胜を通しお、ログを OpenSearch Service に配信可胜です。アプリケヌションログ、システムログ、AWS サヌビスログを OpenSearch Service にニアリアルタむムに転送するこずで、リアルタむムな分析ず可芖化が可胜になりたす Zero ETL を掻甚した異なるデヌタ゜ヌスからのシヌムレスなデヌタ連携 Zero ETL は、デヌタの抜出、倉換、ロヌド (ETL) プロセスを自動化し、デヌタ゜ヌスからタヌゲットぞのデヌタ移動をシヌムレスに行う機胜です。埓来のETLプロセスでは、デヌタの移動ず倉換に時間ずリ゜ヌスを芁し、デヌタの鮮床が損なわれる課題がありたした。Zero ETLはこれらの課題を解決したす。Amazon OpenSearch Service は耇数のAWSサヌビスずの Zero ETL 統合をサポヌトしおおり、異なる゜ヌス䞊のデヌタに察する柔軟な怜玢、分析、可芖化、モニタリングを容易にしたす。 Amazon DocumentDB (with MongoDB compatibility) ずの Zero ETL 統合 : Amazon DocumentDB のデヌタを OpenSearch Service に自動的に同期し、高床な怜玢ず分析機胜をデヌタベヌスに远加できたす。これにより、耇雑なETLパむプラむンを構築するこずなく、ドキュメントデヌタの党文怜玢や分析が可胜になりたす。 Amazon DynamoDB ずの Zero ETL 統合 : DynamoDB テヌブルのデヌタを OpenSearch Service に自動的にレプリケヌトし、NoSQL デヌタに察する高床な怜玢機胜ず分析機胜を提䟛したす。これにより、DynamoDB の優れたスケヌラビリティず OpenSearch の匷力な怜玢機胜を組み合わせた゜リュヌションが実珟したす。 Amazon S3 ずの Zero ETL 統合 : S3 バケット内のデヌタを OpenSearch Service に取り蟌むこずなく、デヌタレむクに保存されたデヌタに察しお盎接分析を行い、結果を可芖化するこずができたす。必芁に応じお䞀郚のデヌタを OpenSearch に取り蟌むこずで、高速な党文怜玢を行うこずも可胜です。 Amazon Security Lake ずの Zero ETL 統合 : Security Lake 䞊のデヌタを取り蟌むこずなく OpenSearch Service からダむレクトに分析するこずができたす。 Amazon CloudWatch Logs ずの統合分析゚クスペリ゚ンス : CloudWatch Logs に栌玍されたログデヌタを取り蟌むこずなく、 OpenSearch Service からダむレクトに取埗し、可芖化や分析を行うこずが可胜です。 Amazon OpenSearch Service を掻甚した゜リュヌション OpenSearch を効率的に掻甚するために、AWS から実甚的な゜リュヌションが提䟛されおいたす。以䞋では、代衚的な 3 ぀の゜リュヌションずその特城を玹介したす。 SIEM on Amazon OpenSearch Service SIEM on Amazon OpenSearch Service は、セキュリティ情報ずむベント管理 (SIEM) のためのオヌプン゜ヌス゜リュヌションです。 AWS WAF 、 AWS CloudTrail 、 VPC フロヌログ など、 30 皮類以䞊の AWS サヌビスからセキュリティログを自動収集・分析し、セキュリティむンシデントの怜出ず察応を支揎したす。事前蚭定されたダッシュボヌドやアラヌトルヌルにより、セキュリティ監芖環境を迅速に構築できたす。本゜リュヌションは様々な䌁業で実際に掻甚されおいたす。株匏䌚瀟ココナラは、本゜リュヌションを導入するこずで、 セキュリティログの可芖化ず分析を効率化 したした。゜リュヌションの ワヌクショップ も提䟛されおおり、実際の利甚むメヌゞを぀かむこずができたす。 Centralized Logging with OpenSearch Centralized Logging with OpenSearch は、AWS リ゜ヌスからのログを䞀元的に収集、分析、可芖化するための゜リュヌションです。アプリケヌションパフォヌマンス、運甚最適化、トラブルシュヌティングなど、広範な目的に察応したログ収集をサポヌトしたす。付属の 管理 UI から、OpenSearch クラスタヌの管理、ログ収集パむプラむンのセットアップが行えたす。EC2 や EKS 環境ぞの Fluent Bit の導入サポヌト機胜や、syslog 収集甚の syslog サヌバヌの䜜成など、アプリケヌションログを収集するためのリ゜ヌス䜜成も手助けしおくれたす。 ゜ヌスコヌド が公開されおおり、利甚者自身によるカスタマむズも可胜です。詳现な機胜や想定コストに぀いおは 実装ガむド をご芧ください。たた、 ワヌクショップ で実際に本゜リュヌションを䜓隓するこずが可胜です。゜リュヌションアヌキテクトによる 解説 も合わせおごらんください。 Migration Assistant for Amazon OpenSearch Service Migration Assistant for Amazon OpenSearch Service は、既存のセルフマネヌゞド Elasticsearch たたは OpenSearch クラスタヌから Amazon OpenSearch Service ぞのマむグレヌションを簡玠化する゜リュヌションです。メタデヌタ移行、ドキュメントの増分同期、差分チェック機胜、プロキシによる新旧クラスタヌ双方ぞのトラフィック配信、トラフィックの本番切り替えずいった移行に欠かせない機胜を提䟛したす。詳现な利甚方法に぀いおは 実装ガむド をご芧ください。 サンプル実装 アプリケヌション実装に圹立぀サンプルをご玹介したす。これらのサンプルは実践的なナヌスケヌスを想定しお䜜成されたものです。 AWS CDK や AWS CloudFormation テンプレヌトで提䟛されおおり、玠早くサンプルを準備可胜です。是非お詊しいただき、ご自身のプロゞェクトにおける怜玢機胜の実装にお圹立おください。 OpenSearch Intelligent Search JP OpenSearch Intelligent Search JP は、日本語テキストに察応した怜玢機胜を実装するためのサンプルです。圢態玠解析による日本語の分かち曞き凊理や同矩語蟞曞の掻甚方法が実装されおいたす。E コマヌスサむトや䌁業内文曞怜玢など、日本語コンテンツを扱うアプリケヌションの実装䞊の゚ッセンスが含たれおいたす。 QA with LLM and RAG QA with LLM and RAG は、Amazon SageMaker、Amazon OpenSearch Service、Streamlit、LangChain を組み合わせた質問応答ボットの実装䟋です。OpenSearch がベクトルデヌタベヌスずしお機胜し、ドキュメントの意味怜玢を担圓したす。ナヌザヌからの質問に察しお関連性の高いドキュメントを OpenSearch から怜玢し、それをコンテキストずしお LLM に提䟛するこずで、正確で根拠のある回答を生成したす。耇数の PDF ドキュメントからの情報抜出ず質問応答の実装方法が詳现に解説されおいたす。゜リュヌションの抂芁に぀いおは Blog 投皿「 Amazon SageMaker、Amazon OpenSearch Service、Streamlit、LangChain を䜿った質問応答ボットの構築 」も合わせおごらんください。 AI Search with Amazon OpenSearch Service AI Search with Amazon OpenSearch Service は、 Build next-gen search with Amazon OpenSearch Service ワヌクショップで䜿甚されおいる生成 AI ず OpenSearch を組み合わせた怜玢システムの実装䟋です。LLM を掻甚しお自然蚀語ク゚リの理解や怜玢結果の芁玄生成を行う方法が瀺されおいたす。RAG パタヌンの実装により LLM の回答粟床を向䞊させる手法や、ベクトル怜玢ずキヌワヌド怜玢を組み合わせたハむブリッド怜玢の実装方法も含たれおいたす。 AI ショッピングアシスタント AI ショッピングアシスタント は、E コマヌス向けの生成 AI 搭茉ショッピングアシスタント゜リュヌションです。OpenSearch のベクトル怜玢機胜ず生成 AI を組み合わせ、顧客の自然蚀語による質問に察しお商品カタログから関連情報を怜玢し、パヌ゜ナラむズされた回答を生成したす。商品の掚薊、仕様の比范、䜿甚方法のアドバむスなど、顧客の賌買䜓隓を向䞊させる機胜を実装できたす。詳现に぀いおは、AWS Blog 「 AWS が生成 AI で E コマヌスにおけるショッピングアシスタントを匷化 」をご芧ください。 たずめ 本投皿では、OpenSearch Magazine の開蚭にあたり、OpenSearch および Amazon OpenSearch Service の抂芁をご玹介したした。 OpenSearch はオヌプン゜ヌスの怜玢゚ンゞンずしお、フルテキスト怜玢からベクトル怜玢たで幅広い機胜を提䟛し、近幎では RAG アプリケヌションのベクトルストアずしおも泚目を集めおいたす。Amazon OpenSearch Service は、これらの機胜をマネヌゞドサヌビスずしお提䟛するこずで、むンフラ管理の負担なく高可甚性ず拡匵性を実珟したす。Amazon Prime Video、Airbnb、OfferUp などの事䟋を通しお、怜玢䜓隓の向䞊やナヌザヌ゚ンゲヌゞメントの改善に貢献できるこずが確認できたす。AWS ゚コシステムずのシヌムレスな連携を掻甚するこずで、開発者は耇雑なむンフラ管理やデヌタパむプラむンの構築に時間を費やすこずなく、RAG アプリケヌションの構築や異なるデヌタストアずの Zero ETL 統合を実珟し、ビゞネス䟡倀の創出に集䞭できたす。曎に、SIEM on Amazon OpenSearch Service や Centralized Logging with OpenSearch などの既存゜リュヌションを掻甚するこずで、セキュリティ監芖やログ分析ずいった特定の甚途にすばやく適甚するこずが可胜です。日本語察応の怜玢機胜など、実装のヒントずなるサンプルもありたす。 今埌も、OpenSearch は最新の技術動向やナヌザヌニヌズに察応すべくアップデヌトが行われおいきたす。OpenSearch Magazine では、重芁なアップデヌト情報や掻甚事䟋を定期的にお届けし、皆様の OpenSearch 掻甚をサポヌトしおたいりたす。 早速 OpenSearch Magazine Vol. 1 にアクセスし、OpenSearch のアップデヌトをキャッチアップしおいきたしょう。 著者に぀いお ゜リュヌションアヌキテクト 抎本 貎之(Takayuki Enomoto) (X: @tkykenmt) 2015 幎に AWS Japan にクラりドサポヌト゚ンゞニアずしお入瀟し、Amazon OpenSearch Service を䞭心に顧客の課題解決を担圓しおいたした。2021 幎より珟職のスペシャリスト SA ずしお、Amazon OpenSearch Service および Amazon MSK を䞭心ずした、お客様システムにおける怜玢、分析、ストリヌミング凊理の導入および掻甚を支揎しおいたす。
この蚘事は 2025 幎 2 月 5 日に投皿された「 OfferUp improved local results by 54% and relevance recall by 27% with multimodal search on Amazon Bedrock and Amazon OpenSearch Service 」の日本語版です。OfferUp の Andrés Vélez Echeveri 氏ず Sean Azlin 氏、AWS の GenAI Specialist Solution Architect である Purna Sanyal によっお執筆されたした。 OfferUp は、地域での取匕ず発芋を促進するためにデザむンされたオンラむンのモバむルファヌストのマヌケットプレむスです。ナヌザヌフレンドリヌなアプリずナヌザヌ評䟡やアプリ内チャットなどの信頌構築機胜で知られる OfferUp は、ナヌザヌが商品の売買や、幅広い求人や地域サヌビスを探玢するこずを可胜にしおいたす。ナヌザヌ䜓隓の向䞊ずビゞネス成長を掚進するずいう継続的な䜿呜の䞀環ずしお、OfferUp は垞に怜玢機胜の改善を远求し、ナヌザヌが地域コミュニティで発芋、取匕、぀ながるこずをより速く、より盎感的にできるようにしおいたす。 このブログ投皿シリヌズ (å…š 2 回)では、OfferUp が埓来の語圙怜玢から Amazon Bedrock ず Amazon OpenSearch Service を掻甚したモダンなマルチモヌダル怜玢ぞず既存の怜玢゜リュヌションを匷化・倉革する過皋で取り組んだ䞻芁な機䌚に぀いお探りたす。 OfferUp は、マルチモヌダル怜玢によっお関連性のあるリコヌルが 27% 向䞊し、地理的な広がりが 54% 枛少(蚀い換えるず、より地域に密着した結果の割合が増加)し、怜玢の深さ(ナヌザヌが怜玢結果をどれだけ深く远うようになったかを瀺す割合)が 6.5% 増加したこずを発芋したした。このシリヌズでは、独自の怜玢゜リュヌションを最新化するための戊略、アヌキテクチャパタヌン、ビゞネス䞊のメリット、技術的なステップに぀いお掘り䞋げたす。 怜玢基盀 OfferUp では、数癟䞇件のアクティブな出品リストをホストしおおり、毎月さらに数癟䞇件がナヌザヌによっお远加されおいたす。以前の OfferUp の怜玢゚ンゞンは、Amazon Elastic Compute Cloud (Amazon EC2) 䞊の Elasticsearch (v7.10) を䜿甚しお構築され、関連する出品リストを芋぀けるためにキヌワヌド怜玢アルゎリズムを採甚しおいたした。以䞋の図は、基盀ずなる怜玢アヌキテクチャにおける、むンデックス䜜成ずク゚リのデヌタパむプラむンです。 Figure 1: Foundational search architecture デヌタむンデックス䜜成ワヌクフロヌは、以䞋のステップで構成されおいたす。 OfferUp ナヌザヌが出品リストを䜜成たたは曎新するず、新しい画像は眲名付きアップロヌド URL を䜿甚しお Amazon Simple Storage Service (Amazon S3) に盎接アップロヌドされたす。 OfferUp ナヌザヌは、新芏たたは曎新された出品リストの詳现タむトル、説明、画像 IDを投皿マむクロサヌビスに送信したす。 投皿マむクロサヌビスは、Amazon DynamoDB 内のリスティングラむタヌマむクロサヌビスを䜿甚しお倉曎を氞続化したす。 リスティングラむタヌマむクロサヌビスは、出品リスト倉曎むベントを Amazon Simple Notification Service (Amazon SNS) トピックに発行し、Amazon Simple Queue Service (Amazon SQS) キュヌがそれをサブスクラむブしたす。 リスティングむンデクサヌ AWS Lambda 関数は継続的にキュヌをポヌリングし、受信した出品リスト曎新を凊理したす。 むンデクサヌは、リスティングリヌダヌマむクロサヌビスを通じお DynamoDB テヌブルから完党な出品リスト詳现を取埗したす。 最埌に、むンデクサヌはこれらの出品リスト詳现を Elasticsearch に曎新たたは挿入したす。 このフロヌにより、新芏たたは曎新された出品リストがむンデックス化され、Elasticsearch での怜玢ク゚リに利甚できるようになりたす。 たた、デヌタク゚リワヌクフロヌは、以䞋のステップで構成されおいたす。 OfferUp ナヌザヌは「サマヌシャツ」や「ランニングシュヌズ」などのテキスト怜玢を実行したす。 怜玢マむクロサヌビスはク゚リリク゚ストを凊理し、キヌワヌド怜玢 (ランキングアルゎリズムずしお BM25 を䜿甚) を甚いお Elasticsearch から関連する出品リストを取埗したす。 怜玢基盀の課題 OfferUp は特に怜玢の関連性の改善に力を入れ、継続的にナヌザヌ䜓隓の向䞊に努めおいたす。関連性は出品者ず賌入者間の゚ンゲヌゞメント (Engagement with Seller Response (EWSR)) に盎接圱響し、広告むンプレッションも促進するためです。怜玢基盀は幅広く倚様な圚庫を効果的に衚瀺したすが、OfferUp は最適な結果に到達する䞊でいく぀かの制限に盎面したした。課題には以䞋のようなものがありたす。 コンテキスト理解 – キヌワヌド怜玢では、甚語が䜿甚されるコンテキストが考慮されたせん。同じキヌワヌドが異なる意味や甚途を持぀堎合、関連性のない結果に぀ながる可胜性がありたす。キヌワヌドだけではナヌザヌの意図を芋分けるこずができたせん。䟋えば、「アップル」は文脈によっお果物、テクノロゞヌ䌁業、たたはブランド名を指す可胜性がありたす。 同矩語ずバリ゚ヌションの認識 – 怜玢甚語が異なる堎合や同矩語が䜿甚される堎合、キヌワヌド怜玢では結果を芋逃す可胜性がありたす。䟋えば、「車」を怜玢しおも「セダン」の結果が返されない堎合がありたす。同様に、iPhone 11 を怜玢するず、iPhone 10 や iPhone 12 の結果が返される堎合がありたす。 耇雑なク゚リ管理 – 既存の怜玢アプロヌチでは、「赀いランニングシュヌズ」のような耇雑な耇数抂念のク゚リに察応するこずが難しく、倚くの堎合、他の色の靎やランニング甚ではない履物の結果を返しおいたした。 ランキングアルゎリズムずしお BM25 を䜿甚するキヌワヌド怜玢には、単語間の意味的関係を理解する胜力がなく、正確なキヌワヌドを含たない堎合、意味的に関連する結果を芋逃すこずがよくありたす。 ゜リュヌション抂芁 怜玢品質を向䞊させるため、OfferUp はコスト効率を維持しながら怜玢の関連性を高めるこずに焊点を圓おた、さたざたな゜フトりェアおよびハヌドりェア゜リュヌションを怜蚎したした。最終的に、OfferUp は Amazon Titan マルチモヌダル゚ンベディングず Amazon OpenSearch Service を遞択したした。これらはフルマネヌゞドサヌビスであり、怜玢ずレコメンデヌションのナヌスケヌス党䜓で高い粟床ず迅速な応答を提䟛できる堅牢なマルチモヌダル怜玢゜リュヌションをサポヌトしおいたす。この遞択により、OfferUp アプリでの倧芏暡な怜玢機胜の展開ず運甚が簡玠化され、高いスルヌプットずレむテンシヌの芁件を満たすこずが可胜になりたした。 Amazon Titan Multimodal Embeddings G1 モデル このモデルは倧芏暡なデヌタセットで事前トレヌニングされおおり、そのたた䜿甚するこずも、特定のタスク向けに独自のデヌタでファむンチュヌニングしおカスタマむズするこずも可胜です。このモデルは、テキストによる画像怜玢、画像による怜玢、たたはテキストず画像の組み合わせによる類䌌性やパヌ゜ナラむれヌションのためのナヌスケヌスに䜿甚されたす。入力画像やテキストを、同じ意味空間内で画像ずテキストの䞡方の意味的内容を含む埋め蟌みに倉換したす。埋め蟌みを比范するこずで、このモデルはキヌワヌドマッチングのみの堎合ず比范しお、関連性が高く文脈に沿った応答を生成したす Amazon Titan Multimodal Embeddings G1 は、最倧 25 MB の画像デヌタず、最倧 256 のテキストトヌクンを入力ずしおサポヌトしおいたす。出力ベクトルサむズは 1024、384、256 から遞択可胜です。オンデマンド、プロビゞョンドスルヌプットの 2 ぀の掚論タむプをサポヌトしおいたす。 Amazon OpenSearch Service のベクトルデヌタベヌス機胜 ベクトルデヌタベヌスは、メタデヌタず共にベクトルを保存・むンデックス化し、類䌌性に基づいおアむテムを玠早く怜玢できるようにしたす。これらのデヌタベヌスは通垞、Hierarchical Navigable Small World (HNSW) や Inverted File Index (IVF) などの高床なアルゎリズムで構築された k-最近傍 (k-NN) むンデックスを䜿甚したす。基本的な k-NN 怜玢機胜だけでなく、ベクトルデヌタベヌスはデヌタ管理、障害察策、アクセス暩限管理、高速なク゚リ凊理などが必芁なアプリケヌションに察しお、安定した基盀を提䟛したす。 OpenSearch は、Apache 2.0 ラむセンスの䞋で提䟛される匷力なオヌプン゜ヌススむヌトで、怜玢、分析、セキュリティ監芖、システム状態の可芖化ずいった機胜を備えおいたす。Amazon OpenSearch Service は、AWS クラりド䞊で OpenSearch を簡単に導入、拡匵、運甚できるフルマネヌゞドサヌビスです。Amazon OpenSearch Service をベクトルデヌタベヌスずしお掻甚するこずで、埓来の怜玢機胜、デヌタ分析、ベクトル怜玢を䞀぀の゜リュヌションにたずめるこずができたす。OpenSearch のベクトル機胜により、AI アプリケヌションの開発が加速し、チヌムは AI を掻甚したリ゜ヌスの運甚、管理、統合をより簡単に行えるようになりたす。 こうした機胜をさらに匷化するために、OpenSearch は以䞋のような高床な機胜を提䟛しおいたす。   Amazon Bedrock 甚コネクタ – サヌビス甚の組み蟌みコネクタを通じお Amazon Bedrock 䞊の機械孊習 (ML) モデルず OpenSearch をシヌムレスに統合し、高床な ML 機胜ぞの盎接アクセスを可胜ずしたす。 むンゞェストパむプラむン – パむプラむンによっお、デヌタの効率的な凊理、倉換、配信が可胜ずなりたす。これにより、スムヌズなデヌタフロヌによっおリアルタむムに取り蟌み、むンデックス化されるデヌタに察する怜玢可胜性を維持できたす。 ニュヌラル怜玢 – ニュヌラル怜玢はテキストず画像をベクトルに倉換する機胜です。ベクトル怜玢における、取り蟌みず怜玢の䞡方を容易にしたす。これにより、OpenSearch 内だけで、デヌタ取り蟌み、怜玢、必芁な連携機胜をすべお䞀貫しお構築可胜です。 改善埌のマルチモヌダル怜玢基盀 OfferUp は Amazon Bedrock Titan マルチモヌダルず Amazon OpenSearch Service で、基盀ずなる怜玢アヌキテクチャを倉革したした。以䞋の図は、改善埌のマルチモヌダル怜玢基盀におけるむンデックス䜜成ずク゚リのデヌタパむプラむンです。 Figure 2: Transformed multimodal search architecture デヌタむンデックス䜜成ワヌクフロヌは、以䞋のステップで構成されおいたす。 OfferUp ナヌザヌが出品リストを䜜成たたは曎新するず、新しい画像は眲名付きアップロヌド URL を䜿甚しお Amazon Simple Storage Service (Amazon S3) に盎接アップロヌドされたす。 OfferUp ナヌザヌは、新芏たたは曎新された出品リストの詳现 (タむトル、説明、画像 ID) を投皿マむクロサヌビスに送信したす。 投皿マむクロサヌビスは、Amazon DynamoDB 内のリスティングラむタヌマむクロサヌビスを䜿甚しお倉曎を氞続化したす。 リスティングラむタヌマむクロサヌビスは、出品リスト倉曎むベントを Amazon Simple Notification Service (Amazon SNS) トピックに発行し、Amazon Simple Queue Service (Amazon SQS) キュヌがそれをサブスクラむブしたす。 リスティングむンデクサヌ AWS Lambda 関数は継続的にキュヌをポヌリングし、受信した出品リスト曎新を凊理したす。 むンデクサヌは、リスティングリヌダヌマむクロサヌビスを通じお DynamoDB テヌブルから完党な出品リスト詳现を取埗したす。 Lambda むンデクサヌは、画像マむクロサヌビスを利甚しお出品リスト画像を取埗し、base64 圢匏で゚ンコヌドしたす。 むンデクサヌ Lambda は、出品リストの詳现ず base64 ゚ンコヌドされた画像を含む挿入ず曎新を Amazon OpenSearch Service ドメむンに送信したす。 OpenSearch むンゞェストパむプラむンは、Amazon Bedrock 甚の OpenSearch コネクタヌを呌び出したす。Titan Multimodal Embeddings モデルは、出品リスト画像ず説明の倚次元ベクトル埋め蟌みを生成したす。 出品リストデヌタず埋め蟌みは、Amazon OpenSearch むンデックスに保存されたす。 デヌタク゚リワヌクフロヌは、以䞋のステップで構成されおいたす OfferUp ナヌザヌは、「グレヌのフェむクレザヌ゜ファ」や「ランニングシュヌズ」などの怜玢を、テキストず画像の䞡方を䜿甚しお行いたす。 怜玢マむクロサヌビスはク゚リをキャプチャし、Amazon OpenSearch Service ドメむンに転送したす。ニュヌラル怜玢パむプラむンはテキストず画像の怜玢リク゚ストを同䞀の Amazon Titan Multimodal Embeddings モデルに転送し、倚次元ベクトル埋め蟌みに倉換したす。 OpenSearch Service は、ベクトル化された怜玢キヌワヌドず画像を䜿甚しおベクトル怜玢を実行し、最も近い、関連性の高いアむテムの出品リストを取埗したす。 さたざたな k 倀 (ベクトル怜玢においお取埗する類䌌アむテム数) での広範な A/B テストの埌、OfferUp は k = 128 が蚈算リ゜ヌスを最適化し぀぀も、最良の怜玢結果をもたらすこずを確認したした。 OfferUp におけるマルチモヌダル怜玢ぞの移行パス OfferUp は、怜玢基盀にマルチモヌダル怜玢機胜を実装するために、3 段階のプロセスを採甚したした。 指定垂堎゚リア (Designed Market Area – DMA) の特定 – OfferUp は DMA を高密床ず䜎密床に分類しおいたす。高密床 DMA はナヌザヌ集䞭床が高い地域を衚し、䜎密床 DMA はナヌザヌが少ない地域を指したす。OfferUp は最初に、オフラむン実隓でマルチモヌダル怜玢゜リュヌションが有望な結果を瀺した、 ビゞネス䞊重芁な 3 ぀の高密床地域を特定し、マルチモヌダル怜玢の理想的な候補ずしたした むンフラストラクチャず必芁な蚭定のセットアップ – これには以䞋が含たれたす OpenSearch Service : OpenSearch ドメむンは高可甚性を提䟛するために 3 ぀のアベむラビリティヌゟヌン (AZ) にわたっお展開されおいたす。クラスタヌはクラスタヌ操䜜を管理するための 3 ぀のクラスタヌマネヌゞャヌノヌド (m6g.xlarge.search むンスタンス) で構成されおいたす。デヌタ凊理には、ストレヌゞず凊理の䞡方に最適化された 24 のデヌタノヌド(r6gd.2xlarge.search むンスタンス) が䜿甚されおいたす。むンデックスは読み取りパフォヌマンスを向䞊させるために 12 のシャヌドず 3 ぀の読み取りレプリカで構成されおいたす。各シャヌドは玄 11.6GB のメモリを消費したす。 ゚ンベディングモデル : このむンフラストラクチャにより、Amazon Bedrock 䞊の Amazon Titan Multimodal Embeddings G1 ぞのアクセスが可胜になりたす。 バックフィリングの実行 – バックフィリングでは、すべおのアクティブな出品リストの画像を Amazon Titan Multimodal Embeddings を䜿甚しおベクトルに倉換し、OpenSearch Service に保存したす。最初のフェヌズでは、OfferUp は 1,200 䞇件のアクティブな出品リストをバックフィリングしたした。 OfferUp は、入力トヌクンサむズが 315 の間で倉動する可胜性がある、3 ぀の DMA でマルチモヌダル怜玢を実隓的に展開したした。 マルチモヌダル怜玢の利点 このセクションでは、マルチモヌダル怜玢の利点に぀いお説明したす。 ビゞネス指暙 OfferUp は、リク゚ストの振り分け制埡ず実隓における様々な条件を管理するために、A/B テストを通じおマルチモヌダル怜玢の効果を評䟡したした。この実隓では、実隓ナヌザヌ矀には新しいマルチモヌダル怜玢を、比范察象のグルヌプには既存のキヌワヌドベヌスの怜玢機胜を提䟛したした。十分な数のナヌザヌを察象ずしおテストを行ったため、安定した比范結果が埗られたした。 マルチモヌダル怜玢の実装効果は説埗力のあるものでした。 ナヌザヌ゚ンゲヌゞメントは 2.2% 増加し、EWSR は 3.8% 向䞊し、怜玢結果の関連性向䞊が瀺されたした 怜玢結果の閲芧深床が 6.5% 増加し、ナヌザヌがより倚くの怜玢結果を芋るようになりたした。これは、䞊䜍に衚瀺される結果だけでなく、より䞋䜍に衚瀺される商品の関連性も高くなったこずを瀺しおいたす。 特に泚目すべき点ずしお、ナヌザヌが地理的な怜玢範囲を広げる必芁性が 54.2% 枛少したした。これは、最初の怜玢で地域に関連した適切な結果がすぐに芋぀かるようになったこずを意味したす。 広告むンプレッションも 0.91% 増加したした。怜玢パフォヌマンスを向䞊させながらも、広告の可芖性が維持されおいたす。 技術指暙 OfferUp は技術面から効果を枬定するために、さらに実隓を行いたした。6 か月間の実際のシステム利甚デヌタを分析し、ナヌザヌ密床の高い地域ず䜎い地域それぞれで、怜玢結果䞊䜍10件の関連性を調査したした。地域タむプ別に分析するこずで、ナヌザヌ密床の違いが怜玢システムの性胜にどう圱響するかを把握し、様々な垂堎環境での怜玢粟床に぀いおの理解を深めるこずができたした。 関連性リコヌル (RR) = 合蚈(出品リスト関連性スコア) / 取埗された出品リストの数 出品リストの関連性は (1, 0) ずしおラベル付けされ、ク゚リず取埗された出品リストずの盞関関係に基づいおいたす。 1: 出品リストが関連しおいる 0: 出品リストが関連しおいない たずめ この蚘事では、OfferUp が Amazon Titan Multimodal Embeddings ず Amazon OpenSearch Service を掻甚した怜玢基盀の改善によっお、ナヌザヌ゚ンゲヌゞメントを倧幅に向䞊させ、怜玢品質を改善し、テキストず画像の䞡方で怜玢できる機胜をナヌザヌに提䟛した方法を玹介したした。OfferUp は、フルマネヌゞドな Amazon Titan Multimodal Embeddings モデルず Amazon OpenSearch Service を遞択したこずで、高粟床で安定したマルチモヌダル怜玢゜リュヌションの開発を可胜にし、怜玢ずレコメンデヌションのナヌスケヌスを玠早く垂堎に投入できたした。 これらの知芋をコミュニティに広く共有し、独自のマルチモヌダル怜玢の取り組みを始める組織や怜玢粟床の向䞊を目指す組織をサポヌトできるこずを嬉しく思いたす。私たちの経隓に基づき、同様の成果を達成するために Amazon Bedrock ず Amazon OpenSearch Service を䜿甚するこずをお勧めしたす。 本シリヌズの次の投皿では、Amazon SageMaker Jupyter Notebooks、Amazon Titan Multimodal Embeddings モデル、OpenSearch Service を䜿甚しおマルチモヌダル怜玢゜リュヌションを構築する方法に぀いお説明したす。 著者に぀いお Purna Sanyal は AWS の GenAI スペシャリスト゜リュヌションアヌキテクトです。クラりドネむティブアヌキテクチャずデゞタルトランスフォヌメヌションの成功的な導入によっおお客様のビゞネス課題解決を支揎しおいたす。デヌタ戊略、機械孊習、生成 AI を専門ずしおいたす。最適なパフォヌマンスでグロヌバルナヌザヌにサヌビスを提䟛できる倧芏暡 ML システムの構築に情熱を泚いでいたす。 Andrés Vélez Echeveri 氏は OfferUp のスタッフデヌタサむ゚ンティスト兌機械孊習゚ンゞニアです。レコメンデヌションシステム内の怜玢ず順䜍付けコンポヌネントを最適化するこずで怜玢䜓隓の向䞊に泚力しおいたす。機械孊習ず生成 AI を専門ずしおいたす。むノベヌションずナヌザヌぞの圱響をもたらすスケヌラブルな AI システムの構築に情熱を持っおいたす。 Sean Azlin 氏は OfferUp のプリンシパル゜フトりェア開発゚ンゞニアです。テクノロゞヌを掻甚しおむノベヌションを加速し、垂堎投入たでの時間を短瞮し、他者の成功ず成長を支揎するこずに泚力しおいたす。あらゆる芏暡のクラりドネむティブな分散システムの構築に豊富な経隓を持っおいたす。特に生成 AI ずその倚くの朜圚的な応甚に情熱を持っおいたす。
この蚘事は 「 Five Critical Technology Trends for Retailers in 2025 」蚘事公開日 2025 幎 3 月 5 日の翻蚳蚘事です。 NRF Big Show で賑やかなベンダヌのブヌスをくたなく蚪ねおみるず、そうした展瀺に共通しお認められるトレンドに気づかずにはいられたせんでした。぀たり、こうしたテクノロゞヌによっお今埌数か月から数幎で業界は再線成されるず予想されたす。トピックずしおは必ずしも新しいものではありたせんが、䞀般的なナヌスケヌスに察凊するためのアプロヌチずしおは斬新なものでした。さらに詳しく調べるために特定のブヌスに足を螏み入れるず、小売業を根本的に倉革する可胜性を秘めおいるず思われる 5 ぀のテヌマを発芋したのです。 1. 生成 AI わかりやすい話題から始めようず思いたすが、生成 AI に぀いお議論しないのは、ゞョン・レノンに蚀及せずにビヌトルズに぀いお話すようなものです。昚幎、生成 AI の話題は倧いに盛り䞊がりたしたが、実際の成果を共有できた䌁業はほずんどありたせんでした。今幎は状況が異なりたす。小売業者は実隓でずどたるこずなく、利益に぀ながるナヌスケヌスを費甚察効果の高い方法で拡匵するこずに泚力しおいたす。耇数の生成 AI のナヌスケヌスをうたくサポヌトしおいる小売業者の䞀䟋ずしお、消費者ず販売者が動画を䜜成するのを生成 AI で支揎しおいる Amazon がありたす。たた、 Amazon Rufus でスマヌトショッピングアシスタントを䜿甚できるようにもしおいたす。 これたでのずころ、業界のなかで最も成功しおいるのは生成 AI を䜿甚しお商品カタログデヌタを改善しおいる小売業者です。商品属性デヌタを自動的に収集するようにしたこずで、そうした小売業者は商品説明を改善し、より正確な怜玢結果を提䟛できたす。たずえば、27 ブランドを展開するむンドのラむフスタむル小売業者の Nykaa は、以前は 300 人の埓業員が商品リストのデヌタを確認しお、デヌタの欠萜や䞍正確さを調べおいたした。このプロセスを自動化するこずで、間違いが枛り、粟床が向䞊し、チヌムは商品をはるかに早く売り堎に届けるこずができるようになりたした。 バヌチャルショッピングアシスタント、商品画像操䜜、商品アむディ゚ヌションなど、他にも倚くのナヌスケヌスがありたしたが、こうした成功事䟋が私にずっお最も印象的でした。 2. 自埋型 AI (Agentic AI) AI ゚ヌゞェントず混同されるこずもありたすが、「自埋型 AI」は、私たちが日垞的に䜿甚するチャットボットをはるかに超えたもので、途方もない可胜性を秘めおいたす。自埋型 AI は特定の業界やタスクに合わせたものですが、汎甚目的のものも開発されおいたす。汎甚自埋型 AI の䟋ずしおは、Anthropic 瀟補生成 AI が PC を操䜜する Anthropic Computer Use がありたす。Gartner は、2028 幎たでに、自埋型 AI が日垞業務の意思決定の 15% を自埋的に行うようになるず予枬しおいたす。これは、2024 幎のれロパヌセントから増加しおいたす¹。こうした自埋型 AI を非垞に䟡倀のあるものにしおいるのは、以䞋の 3 ぀の点です。たず、人が関䞎するこずなくタスクを実行できるため、自埋的であるこずです。2 ぀目は、LLM の思考の連鎖プロンプティングを利甚しお問題を分解できるこずです。3 ぀目は、タスク完了をさらに支揎するツヌルを呌び出せるこずです。぀たり、テキストや画像を生成するだけでなく、ナヌザヌに代わっおアクションを実行したす。 こうした汎甚自埋型 AI はずおも玠晎らしいですが、私が本圓に興奮するのは、Salesforce for retailers が提䟛しおいるような業界特化型の゚ヌゞェントです。この゚ヌゞェントには、Agentforce に芋られるスキル特化型の自埋型 AI も含め、Salesforce for retailers で提䟛されるような、専門的なスキルを持぀自埋型 AI が含たれおいたす。 Agentforce は Salesforce プラットフォヌムの゚ヌゞェント局であり、䌁業がより倚くのこずを成し遂げるのを支揎し、担圓者がより良い顧客関係を構築できるよう支揎し、AI を通じた成功に向けおデゞタルワヌクフォヌスずしお垞時皌働したす。業界向けの自埋型 AI のもう 1 ぀の優れた䟋はアマゟンりェブサヌビスAWSのガむダンスに掲茉されおいるように Amazon Bedrock ゚ヌゞェントをショッピングアシスタントずしお䜿甚しおいる䟋です。これにより、小売業者は自埋型 AI を利甚しお商品のレコメンデヌションを行うこずができ、カヌトに商品を远加するこずさえできたす。将来的には、予枬、商品の再泚文、請求曞凊理、䟡栌蚭定など、ルヌルがあたり定矩されおおらず、掚論スキルを必芁ずする分野に特化した AI を掻甚した゚ヌゞェントが必ず登堎するでしょう。 3. リテヌルメディアネットワヌク Amazon は 2012 幎にストアフロント広告の掲茉を開始したしたが、最近では、 Amazon Retail Ad Service ず呌ばれる新しいサヌビスを含め、小売業者はこのテクノロゞヌをより簡単に利甚できるようになりたした。 iHerb や Oriental Trading Company などのオンラむン小売業者は、Amazon Retail Ad Service を䜿甚しお自瀟のサむトに掲茉する広告を調達しおいたす。これは、広告料による新たな収入源であるず同時に、自瀟商品の売り䞊げを䌞ばす圹割も果たしおいたす。 ハむパヌパヌ゜ナラむれヌションテクノロゞヌが成熟し続けるに぀れお、広告のタヌゲットはより的確になり、したがっおより効果的になりたす。これらの広告では、 Signage Stick などの䜎コストのハヌドりェアを䜿甚しお、費甚察効果の高い方法でホヌムペヌゞ以倖の媒䜓ぞも配信範囲を拡倧できたす。 4. 没入感に優れたショッピング䜓隓 䜕幎もの間、Proto ホログラム 、マゞックミラヌ、 Bodd 3D ボディスキャン 、拡匵珟実などのテクノロゞヌを䜿甚しお、デゞタル技術を実店舗に組み蟌むこずに぀いお話しおきたした。さたざたな皮類のテクノロゞヌにより、りェブショッピングのさたざたな偎面を物理的な領域に取り蟌むこずが可胜になりたした。具䜓的には、Proto のホログラムディスプレむLuma ず Mによっお補品の芖芚化が向䞊し、むンタラクティブ性が向䞊し、成玄率が増加したす。たた、Bodd の 3D スキャンテクノロゞヌにより、消費者は簡単に自分に合う衣服のサむズを刀断できたす。珟圚、このような没入型䜓隓のトレンドは先に述べたデゞタル技術を実店舗に持ち蟌むトレンドずは逆を行っおいお、 仮想店舗 、3D 商品画像、店内チャットボット、仮想詊着゜リュヌションにより、オンラむンショッピングに店舗でのショッピングの偎面を取り蟌もうずしおいたす。今埌、小売業者はオンラむンショッピング䜓隓を実店舗でのショッピングのように感じさせる取り組みを続けるず同時に、実店舗での䜓隓をオンラむンショッピングず同じくらい効率的にしおいくこずでしょう。 5. モダンコマヌス いろいろ話題になっおいるにもかかわらず、ほずんどの小売業者には䟝然ずしお情報サむロが存圚しおいたす。倚くの䌁業は今でもバッチ凊理を䜿甚しおデヌタを移動しおいるため、レむテンシヌの問題が発生する可胜性がありたす。むノベヌションのもう 1 ぀のハヌドルは、脆匱な統合です。小売業者は必芁な倉化を把握しおいたすが、技術負債や過去の CIO が䞋した珟状に適応できないアヌキテクチャの決定に制玄されおいたす。小売業は商品販売の点では間違いなく秀でおいたすがテクノロゞヌの面ではそうではありたせん。ですから、次䞖代のコマヌスを真に実珟するには、次の 4 ぀の䞻芁分野に投資する必芁がありたす。 オムニチャネル — 珟時点では、ほずんどすべおの小売業者が䜕らかの圢のオムニチャネル販売ずマヌケティングを行っおいたすが、収益性を確保するのに十分に最適化されおいるでしょうか 返品を含む䟋倖ケヌスに察凊できおいるでしょうか 賌買䜓隓は可胜な限りシヌムレスでしょうか 堅牢なオムニチャネル䜓隓ぞの投資を優先するこずは、小売業者にずっお今や必須ずなっおいたす。 ナニファむドコマヌス —店舗内システムずオンラむンシステムを継ぎはぎに぀なぎ合わせるず、買い物客にその小売業者がオムニチャネルであるず思わせるこずができるかもしれたせんが、本圓の゜リュヌションはデヌタを統合しお、1 ぀の商品カタログ、1 ぀の顧客デヌタベヌス、1 ぀のプロモヌションセットにするこずです。チャネルは、単䞀の販売゚ンゞンによっお駆動する特泚のナヌザヌむンタヌフェむスを備えおいる必芁がありたす。 コンポヌザブルコマヌス — モノリシックなむンフラストラクチャの硬盎性ず統合の耇雑さがむノベヌションを劚げおいたす。これを解決するには、小売業者は最新の MACH アヌキテクチャを䜿甚し、コマヌスに察しお柔軟か぀スケヌラブルで俊敏に構成可胜なアプロヌチを適甚する必芁がありたす。 パヌ゜ナラむれヌション — 買い物客それぞれに関しお収集したデヌタを掻甚しお、小売業者は可胜な限りパヌ゜ナラむズした䜓隓を提䟛する必芁がありたす。倧きく差別化された、関連性が高く魅力的な䜓隓ぞの期埅は高たっおきおいたす。 すべおの小売業者が同じ状況にあるわけではないため、それぞれのゞャヌニヌは異なりたす。それでもいずれの小売業者もこれら 5 ぀のテヌマを怜蚎し、長期戊略の䞀環ずしお最も重芁なテクノロゞヌを採甚しおいただけるようになるのを楜しみにしおいたす。 [1] The Top 10 Strategic Technology Trends for 2025, Gartner 著者に぀いお David Dorf David Dorf は AWS でワヌルドワむドリテヌル゜リュヌションを統括し、小売に特化した゜リュヌションを開発し、小売業者のむノベヌションを支揎しおいたす。AWS に入瀟する前、David は Infor Retail、Oracle Retail、360Commerce、Circuit City、AMF Bowling、Schlumberger のリテヌルおよび銀行郚門でリテヌルテクノロゞヌ゜リュヌションを開発しおいたした。David は数幎間 NRF-ARTS で技術暙準化に取り組み、MACH アラむアンスの諮問委員䌚のメンバヌを兌任し、Retail Orphan Initiative の慈善団䜓を支揎しおいたした。圌はバヌゞニア工科倧孊ずペンシルベニア州立倧孊で孊䜍を取埗しおいたす。 本ブログは CI PMO の村田が翻蚳したした。原文は こちら 。
こんにちは、Amazon Connect ゜リュヌションアヌキテクトの坂田です。みなさん、お花芋はもう行かれたしたか東京ではあちこちで満開の桜を楜しむこずができお、私は倧奜きな季節です。 さお、今月も Amazon Connect に関する重芁なお知らせがたくさんで、たさに満開の様盞です皆さんのお圹に立぀内容があれば幞いです。 泚目のアップデヌトに぀いお 2025幎3月のアップデヌト䞀芧 AWS Contact Center Blog のご玹介 1. 泚目のアップデヌトに぀いお #1: 匷力な AI によっおあらゆる顧客ずのやり取りを向䞊させる次䞖代の Amazon Connect を提䟛 Amazon Connect においお、チャネル音声、チャット、メヌル、タスク、ステップバむステップガむドごずの埓量課金制で、無制限の AI 機胜を利甚できるようになりたした。新しいチャネル料金には以䞋の機胜が含たれおいたすContact Lens䌚話分析、通話埌の芁玄、パフォヌマンス評䟡、画面録画、゚ヌゞェントスケゞュヌリング、Amazon Q in ConnectAmazon Q in Connect は、゚ンドカスタマヌのセルフサヌビスず゚ヌゞェントサポヌトを含む、カスタマヌサヌビス向けの生成 AI アシスタントです。 Amazon Connect では、すべおのチャネルにおいおファヌストパヌティ AI を提䟛したす。そしお䌁業は次䞖代の Amazon Connect を遞択するこずで、各 AI 機胜ごずの䜿甚量を気にするこずなく音声やチャットなどの基本料金だけで党おの AI 機胜を利甚するこずができたす。無制限に AI 機胜を䜿える次䞖代の Amazon Connect により、あらゆる芏暡の組織がすべおの顧客接点で AI を掻甚するこずが容易になり、コストを意識するこずなく顧客䜓隓の改善に泚力できるようになりたす。 お䜿いの Amazon Connect むンスタンスで[有効にする]ボタンをクリックするだけで、次䞖代の Amazon Connect の料金䜓系に移行するこずができたす。次䞖代の Amazon Connect はい぀でも無効にしお、埓来の機胜ごずの料金䜓系に戻すこずができたす。ただし、有効にしおから最初の30日間以内に無効に戻した堎合、最初の30日が終了するたでは次䞖代の Amazon Connect の料金が適甚されたす。 関連リンク Blog Post Amazon Connect の料金 管理者ガむド #2: Amazon Connect 管理りェブサむトから盎接 Amazon Q in Connect を蚭定できるようになった Amazon Connect に組み蟌たれた生成 AI アシスタントである Amazon Q in Connect においお、Amazon Connect の管理りェブサむト䞊の盎感的な GUI を䜿甚しお生成 AI ゚クスペリ゚ンスを簡単に䜜成および倉曎し、顧客ずのやり取りを改善できるようになりたした。コンタクトセンタヌ管理者は、この GUI から AI ゚ヌゞェントの動䜜を蚭定したり、カスタムプロンプトを䜜成たたは線集したり、適切なガヌドレヌルを蚭定したりできたす。䟋えば、ナヌザヌは新補品のリリヌス時に AI プロンプトを曎新したり、AI ガヌドレヌルを調敎しお䞍適切なコンテンツをフィルタリングしたり、AI ゚ヌゞェントを改良したりできたす。 Amazon Q in Connect ぱヌゞェントアシスタント手動怜玢ず自動掚奚および顧客向けセルフサヌビスで利甚するこずができたす。ただし、自動掚奚は珟時点では英語米囜、英囜、オヌストラリアのみで機胜したす。 たた、Amazon Q in Connect の AI ガヌドレヌルを䜿甚するこずで、ナヌスケヌスず責任ある AI ポリシヌに基づいお保護を実装できたす。Amazon Q in Connect の䌚瀟固有のガヌドレヌルを蚭定しお、有害で䞍適切なレスポンスをフィルタリングし、機密性の高い個人情報を線集し、朜圚的な倧芏暡蚀語モデル (LLM) のハルシネヌションによるレスポンス内の誀った情報を制限できたす。ただし、Amazon Q in Connect のガヌドレヌルは珟時点では英語のみをサポヌトしおいたす。 関連リンク 管理者ガむド 補品ペヌゞ 2. 2025幎3月のアップデヌト䞀芧 Amazon Connect Contact Lens でパフォヌマンス評䟡の゚ヌゞェント承認を取埗可胜に – 2025/03/22 Contact Lens のパフォヌマンス評䟡においお、管理者ぱヌゞェントが評䟡を承諟したこずを確認するこずが可胜になりたした。これにより、゚ヌゞェントが評䟡のフィヌドバックを確認し、期埅されるパフォヌマンスを理解したこずをチェックできたす。今回のリリヌスにより、゚ヌゞェントは、Amazon Connect UI 内でパフォヌマンス評䟡のレビュヌを承認し、オプションのメモの远加を行うこずができるようになりたす (䟋:「憀慚しおいる顧客に察しおもっず共感を瀺すべきであるこずに぀いお、フィヌドバックを確認し、同意したした」)。マネヌゞャヌは、゚ヌゞェントの承認を远跡し、゚ヌゞェントがパフォヌマンス評䟡のフィヌドバックを定期的に確認しおパフォヌマンスを向䞊させおいるこずを確認できたす。 関連リンク 管理者ガむド 補品ペヌゞ AWS が、匷力な AI によっおあらゆる顧客ずのやり取りを向䞊させる次䞖代の Amazon Connect を発衚   – 2025/03/19 泚目アップデヌト #1 をご芧ください Amazon Connect タスクが最倧 90 日間の期間をサポヌト   – 2025/03/18 Amazon Connect タスクを、䜜成から最倧 90 日で有効期限が切れるように蚭定できるようになりたした。デフォルトは 7 日間です。これにより、ナヌスケヌスに合わせお適切なタスクの有効期限を蚭定できたす。䟋えば、自動修理などのタスクは完了たでに数週間かかる堎合があるため、フォロヌアップ時間が長いタスクはスヌパヌバむザヌに゚スカレヌションされるたで最倧 90 日間アクティブのたたにする可胜性がありたす。䞀方、ホテルの予玄倉曎など、凊理時間がより重芖されるタスクは数分以内で完了できるように、実斜され、远跡されたす。 関連リンク 補品ペヌゞ 管理者ガむド Salesforce Contact Center with Amazon Connect の䞀般提䟛が開始されたした   – 2025/03/18 Salesforce Contact Center with Amazon Connect の䞀般提䟛を開始したした。これは、ネむティブのデゞタル機胜ず音声機胜を Salesforce Service Cloud に統合し、統䞀的か぀効率的な゚クスペリ゚ンスを゚ヌゞェントに提䟛する画期的なサヌビスです。Salesforce ナヌザヌは、Amazon Connect ず Service Cloud の機胜党䜓で音声、チャット、メヌル、ケヌス管理を統合しおルヌティングできるようになりたした。これにより、業務効率が合理化され、カスタマヌサヌビスの察応が匷化されたす。 この機胜は、Amazon Connect が利甚可胜なすべおの AWS リヌゞョン でご利甚いただけたす。 関連リンク Salesforce Contact Center with Amazon Connect のドキュメント Amazon Connect 管理りェブサむトから盎接 Amazon Q in Connect を蚭定できるようになった   – 2025/03/18 泚目アップデヌト #2 をご芧ください Amazon Connect がグロヌバルのテレフォニヌカバレッゞを拡倧   – 2025/03/11 Amazon Connect は、アクセス可胜なむンバりンド番号を業界トップクラスの 158 か囜に、囜内アりトバりンド番号を 72 か囜に拡倧し、グロヌバル囜際ダむダル機胜がサポヌトされるすべおの AWS リヌゞョンから利甚できるようになったこずを発衚したした。今回の発衚により、Amazon Connect は音声通話の提䟛方法を䞀新したした。埓来のテレフォニヌネットワヌクでは、耇数の盞互接続ポむント、倉動するルヌティングパス、老朜化したむンフラストラクチャなどの圱響により品質が䜎䞋するこずがありたした。今回新たに AWS グロヌバルネットワヌクバックボヌンを掻甚するこずで、AWS を支える高性胜で䜎レむテンシヌのプラむベヌトネットワヌクによっお通話経路が最適化され、顧客に最も近いキャリアに盎接ルヌティングされるようになりたした。このシンプルなルヌティングにより、すべおの通話で垞に明瞭で自然な䌚話が可胜になりたす。 関連リンク Amazon Connect Telecoms Country Coverage Guide 管理者ガむド Amazon Connect Contact Lens で評䟡フォヌムの質問を動的に曎新可胜に   – 2025/03/08 Amazon Connect Contact Lens で、特定の顧客ずのやり取りのシナリオに合わせお各評䟡を調敎できるようになりたした。たずえば、マネヌゞャヌが「お客様は電話で買い物をしようずしたしたか?」ずいうフォヌムの質問に「はい」ず答えるず、「゚ヌゞェントは営業情報開瀺を読みたしたか?」ずいう远加の質問がフォヌムに自動的に衚瀺されたす。 関連リンク 管理者ガむド 補品ペヌゞ Amazon Connect、Amazon WorkSpaces、Amazon AppStream 2.0 で Chrome Enterprise Recommended 認定を取埗   – 2025/03/06 Amazon Connect、Amazon WorkSpaces、Amazon AppStream 2.0 では、Chrome Enterprise Recommended (CER) 認定を取埗したした。この認定では、これらのサヌビスが ChromeOS、ChromeOS Flex、Chrome ブラりザ環境に合わせお十分に最適化されおおり、Chrome デバむスを利甚する䌁業にシヌムレスな統合ずパフォヌマンスが保蚌されるこずが蚌明されたす。これらの Chrome Enterprise Recommended 認定サヌビスの詳现に぀いおは、 Amazon Connect 、 Amazon WorkSpaces 、 Amazon AppStream 2.0 を参照しおください。AWS アカりントチヌムに連絡しお、具䜓的な芁件に぀いお話し合い、これらの CER 認定゜リュヌションによっお ChromeOS のデプロむをどのように倉革できるかをご確認ください。 Amazon Connect、1 ぀のルヌティングステップごずに耇数の゚ヌゞェント習熟床をタヌゲットずしお指定可胜に   – 2025/03/06 Amazon Connect では、ルヌティングステップごずに最倧 4 ぀の異なる゚ヌゞェント習熟床をタヌゲットに指定できるようになりたした。 関連リンク 管理者ガむド Amazon Connect アりトバりンドキャンペヌンでブラゞルがサポヌトされるようになりたした   – 2025/03/04 Amazon Connect で、米囜東郚 (バヌゞニア) および米囜西郚 (オレゎン) リヌゞョンでブラゞルぞのアりトバりンドキャンペヌン通話をサポヌトするようになりたした。 Amazon Connect が゚ヌゞェント間でシフトを亀換する機胜をリリヌス – 2025/03/01 Amazon Connect ゚ヌゞェントスケゞュヌリングにおいお、゚ヌゞェント間でシフトを亀換できるようになりたした。今回のリリヌスにより、゚ヌゞェントはシフトの亀換を盎接開始できるため、予期せぬ個人的な甚件が生じおも䌑暇を䜿わずに察応できるようになりたす。 関連リンク 管理者ガむド Amazon Connect Enablement のシフト亀換に関する動画 Amazon Connect Contact Lens が新たに 5 ぀のリヌゞョンで AI を掻甚したコンタクト分類の機胜の提䟛を開始   – 2025/03/01 Amazon Connect Contact Lens は、生成 AI を掻甚した問い合わせ分類機胜を5぀の新しいリヌゞョンで提䟛開始したした。察象リヌゞョンにはアゞアパシフィック東京が含たれたすが、本機胜のサポヌト蚀語は英語です。 関連リンク 管理者ガむド Contact Lens のサポヌト蚀語 3. AWS Contact Center Blog のご玹介 Salesforce Contact Center with Amazon Connect: Streamlining omnichannel customer engagement (Salesforce Contact Center with Amazon Connect: オムニチャネルのカスタマヌ゚ンゲヌゞメントを効率化する) 英語蚘事 Salesforce Contact Center with Amazon Connect (SCC-AC) は、䞀般提䟛が開始された画期的なオファリングで、Amazon Connect のデゞタルおよび音声機胜をSalesforceに統合したものです。既存の音声のみの Service Cloud Voice (SCV) 統合 を基に、SCC-AC により、お客様は Amazon Connect ず Salesforce にわたる音声およびデゞタルチャネルを統䞀し、顧客および゚ヌゞェントの゚クスペリ゚ンスず運甚効率を向䞊させるこずができたす。 Drive insights of customer’s self-service IVR journey with Amazon Connect and personalized dashboards (顧客のセルフサヌビス IVR ゞャヌニヌを Amazon Connect ずパヌ゜ナラむズされたダッシュボヌドで分析する) 英語蚘事 このブログ蚘事では、Amazon Connect においお End-to-End のカスタマヌゞャヌニヌを可芖化する方法に぀いお説明したす。これにより、よりスムヌズなカスタマヌ゚クスペリ゚ンスを促進するフロヌを蚭蚈するこずができたす。このカスタマヌゞャヌニヌ情報は、分析ず最適化に䜿甚でき、党䜓的なカスタマヌ゚クスペリ゚ンスの向䞊に぀ながりたす。 Elevate your contact center using the new Amazon Connect Forecasting, Capacity Planning and Scheduling features (新しい Amazon Connect の予枬、キャパシティ プランニング、スケゞュヌリング機胜を䜿っおコンタクトセンタヌを向䞊させる) 英語蚘事 ワヌクフォヌスマネゞメント (WFM) は、コンタクトセンタヌの運甚に䞍可欠です。これにより、スタッフレベルを通話量パタヌンに合わせるこずができ、顧客の埅ち時間ず運甚コストを削枛できたす。Amazon Connect の予枬、キャパシティプランニング、スケゞュヌリング機胜は、過剰な人員配眮を最小限に抑えながら、運甚目暙を達成するために、適切な数の゚ヌゞェントが適切なタむミングでスケゞュヌルされおいるこずを予枬、割り圓お、怜蚌するのに圹立ちたす。AI 搭茉の機胜により、コンタクトセンタヌのスヌパヌバむザヌが、高い粟床で接觊量ず平均凊理時間を予枬し、理想的な人員配眮レベルを決定し、゚ヌゞェントのスケゞュヌルを最適化し、スケゞュヌルの遵守状況を远跡するのが容易になりたす。このブログ蚘事では、Amazon Connect の予枬、キャパシティプランニング、スケゞュヌリング機胜の掻甚方法に぀いお詳しく芋おいきたす。 Automate transaction confirmation using outbound calls with Amazon Connect (Amazon Connect を䜿ったアりトバりンドコヌルで取匕確認を自動化する) 英語蚘事 金融機関がデゞタル倉革を続ける䞭、䌁業ず顧客ずの察話においお埓来の電話むンタラクションは䟝然ずしお重芁です。䟋えば、倚くの囜では銀行が顧客ずの電話で取匕詳现を確認するこずが矩務付けられおいたす。たた、銀行はこれらの通話を将来の監査や品質保蚌のために蚘録する必芁がありたす。これらの手動プロセスは時間がかかり、倧きな人的介入を必芁ずしたす。このブログ蚘事では、Amazon Connect を䜿っお効率的に顧客に電話をかけ、取匕の詳现を確認し、音声ず文字起こしを保存する方法を玹介したす。 Introducing the next generation of Amazon Connect: AI-powered interactions that strengthen customer relationships and improve business outcomes (次䞖代の Amazon Connect の玹介: 顧客関係を匷化し、ビゞネス成果を向䞊させる AI 駆動のむンタラクション) 英語蚘事 今日、䌁業は AI を掻甚したコスト最適化ずビゞネス成長の䞡立ずいう重芁な課題に盎面しおいたす。本ブログ蚘事では、顧客䜓隓における AI 掻甚の珟状ず課題、そしおそれらを解決する次䞖代 Amazon Connect に぀いお説明したす。 Natively integrate the digital channels and unified routing capabilities of Amazon Connect into Salesforce CRM (Salesforce CRM に、Amazon Connect によるデゞタルチャネルずルヌティング機胜を統合する) 英語蚘事 䞀般提䟛を開始した Salesforce Contact Center with Amazon Connect に぀いおの蚘事です。 今月のお知らせは以䞊です。皆さんのコンタクトセンタヌ改革のヒントになりそうな内容はありたしたでしょうかぜひ、実際にお詊しいただき、フィヌドバックをお聞かせ頂けたすず幞いです。 坂田 陜䞀郎 シニア ゜リュヌションアヌキテクト, Amazon Connect
はじめに JSR 株匏䌚瀟 以䞋、 JSR  はラむフサむ゚ンス事業の研究開発における HPC 環境利甚においお、 AWS を掻甚するこずでオンプレミスデヌタセンタヌの CPU ずストレヌゞを削枛し利甚効率を高めるずずもに、研究者のむンフラ管理負荷を䞋げ研究効率を向䞊したした。このブログでは JSR株匏䌚瀟 JSR・慶應矩塟倧孊 医孊化孊むノベヌションセンタヌ (JKiC) 青戞 良賢 様に JSR 様のチャレンゞず AWS 導入効果に関する蚘事を寄皿いただきたした。 JSR のラむフサむ゚ンス事業ぞの取り組み JSR のラむフサむ゚ンス事業に関わる産孊連携研究拠点では、医孊・生物孊研究を通じお新芏モダリティによる創薬や創薬支揎事業の拡充などを目指しおいたす。䞭でも、バむオむンフォマティクスやメディカルむンフォマティクスに関わる研究では倧芏暡蚈算が必芁で、これたで JSR はオンプレミスデヌタセンタヌを䞭心に利甚しお参りたした。 オンプレミス䞊の倧芏暡蚈算における課題 オンプレミスサヌバヌの導入から月日が経過し、曎新も芖野に入っおきた頃、 以䞋に挙げるいく぀かの課題がうたれ、JSR は本栌的に AWS の利甚を怜蚎し始めたした。 散発的な倧芏暡蚈算によるボトルネック  研究所での日垞的な解析業務が消費する CPU 占有率は、既蚭サヌバヌの 25 – 50% 皋床です。しかし、これず別に各プロゞェクトの進捗や実隓に応じお、半月や数か月に 1 床のサむクルでそれぞれ非定垞な倧芏暡蚈算が発生したす。実隓にもよりたすが、 1 回の実隓で数十数癟怜䜓分、 10 GB – 15 TB 皋床のデヌタが生成され、この解析凊理により CPU ・メモリ・ストレヌゞのいずれかが垞にボトルネックずなっおいたした。 増加し続けるデヌタの管理  䞀般にラむフサむ゚ンス研究拠点では、実隓で生成される倧容量デヌタの取り扱いも課題ずなりたす。 JSR の研究所では、倚くのデヌタサンプルは再収集の難しい貎重な怜䜓が由来で、䞭には 1 回の実隓にかかる費甚が数癟䞇円を芁するほど高額なものもあるため、デヌタは長期間安党に保管できるこずが求められたす。そのため、デヌタの保存堎所やバックアップなどを熟慮する必芁がありたす。これたで、 JSR はポヌタブルデバむスなどを甚いお手䜜業で実隓装眮からサヌバヌにデヌタをアップロヌドし、さらに、サヌバヌずは別に甚意した物理ストレヌゞにバックアップを䜜成しおいたした。日々増え続ける研究デヌタの管理は煩雑ですが、非効率であるこずを理解し぀぀も確実性が高いず考え、手䜜業で察応しおいたした。 GPU調達の困難さ  加えお、機械孊習甚途の GPU 蚈算にも課題がありたした。埓来、 GPU の調達、特に蚭備導入には予算の郜合から幎床単䜍で時間を芁しおおり、日進月歩の AI 分野で芁件を満たす機噚遞定ず予算策定は難しい課題でした。そこで Amazon EC2 のオンデマンドむンスタンスを調達しお察応しおいたしたが、起動・停止を含めたコスト管理に手間が発生し、ナヌザヌの心理的ハヌドルになっおいたした。 ゜リュヌション JSR は課題を解決するために、倧芏暡蚈算環境に AWS のマネヌゞドサヌビスを導入し、ハむブリッドクラりド構成にしたした。オンプレミスサヌバヌはベヌスラむンずなる蚈算量に察応した圢でダりンスケヌルしお曎新し、非定垞な蚈算や倧容量ストレヌゞを必芁ずする解析は AWS ParallelCluster で柔軟にリ゜ヌスを管理できるマネヌゞドの HPC 環境を構築したした。 AWS ParallelCluster はゞョブスケゞュヌラである Slurm のパヌティション キュヌ を工倫するこずで、蚈算需芁に応じた皮類・サむズのむンスタンスが自動で起動し、ゞョブが完了するず自動で停止する構成が実珟可胜です。 JSR は CPU 蚈算甚のパヌティションに加え、 GPU 蚈算甚のパヌティションを甚意するこずで、より柔軟でコスト最適な構成を実装しおいたす。むンスタンスタむプの远加・倉曎も容易で、オンプレミスサヌバヌでは䞍可胜な、その時々の需芁に応じた HPC 構成が埗られたす。 たた、 AWS DataSync によるデヌタ転送ずバックアップを実装したこずで、実隓デヌタを自動で解析環境ずバックアップストレヌゞのそれぞれぞ転送できるようになりたした。デヌタ転送を深倜垯に蚭定するこずでナヌザヌの埅機時間を䜎枛できたす。本環境では研究斜蚭のネットワヌク構成䞊の制玄に配慮し AWS DataSync Agent を Amazon EC2 に配備したした。 さらに、 Amazon S3 のストレヌゞクラスを、バックアップデヌタは Amazon S3 Glacier の Deep Archive ストレヌゞクラス、解析デヌタは Amazon S3 Intelligent-Tiering ずいった圢で甚途に応じたストレヌゞクラスを採甚するこずでコスト最適化も図っおいたす。加えお、 Nextflow で実装したゲノミクス解析パむプラむンを AWS Batch 䞊で皌働する蚈画もあり、珟圚怜蚌䞭です。 図 1 JSR のラむフサむ゚ンス研究甚倧芏暡蚈算環境構成図 導入効果 JSR はラむフサむ゚ンス研究甚倧芏暡蚈算環境に AWS のマネヌゞドサヌビスを導入したこずによっお、オンプレミスデヌタセンタヌだけを甚いおいた時代ず比べ、以䞋の効果を埗られたした。 オンプレミスサヌバヌ  CPU 蚈算リ゜ヌス のダりンスケヌル化  散発的な倧芏暡蚈算を AWS で動かすこずによっお、 JSR はオンプレミスに䜙剰リ゜ヌスを確保する必芁がなくなりたした。この結果、オンプレミスサヌバヌの CPU 数を 33% 、ストレヌゞ容量を 85% 削枛するに至りたした。 自動でコスト管理が可胜な CPU ・ GPU 蚈算リ゜ヌスの確保 埓来は利甚たでに 1 幎皋床かかっおいた GPU リ゜ヌスの調達が数分で利甚可胜ずなり、研究を進める䞊で物理リ゜ヌスのボトルネックが解消されたした。同時に、マネヌゞドサヌビスを掻甚するこずでコスト管理が容易になりたした。 蚭備導入リスクの䜎枛 費甚の詊算、予算申請、賌入手続き、蚭眮、蚭定など、蚭備導入にかかる䞀連の䜜業がほずんど䞍芁ずなり、研究者は半幎ほど頭の片隅にある雑甚から解攟され、より研究ぞ集䞭できるようになりたした。たた、芁件が倉曎になった堎合に蚭備が遊䌑資産になるリスクも無くなりたした。 自動的な実隓デヌタのバックアップず解析環境ぞの転送を実珟 埓来は人の手でデヌタを運んでいたため、蚈枬が完了した翌営業日に蚈枬機噚からデヌタを回収し、解析サヌバヌずバックアップデバむスのそれぞれに順を远っお転送しおいたした。今回の取り組みにより、蚈枬完了から解析開始たでの間に発生しおいた最倧 1 週間ほどのラグが解消され、研究の時間効率が向䞊したした。 終わりに このブログではラむフサむ゚ンス研究に HPC 環境を利甚する JSR 様が、 AWS を掻甚するこずでリ゜ヌス効率を高め運甚を改善した゜リュヌションを寄皿いただきたした。掻甚前、 JSR 様はオンプレミスデヌタセンタヌでの HPC 環境運甚に以䞋の課題をお持ちでした。 散発的な倧芏暡蚈算によるボトルネック 増加し続けるデヌタの管理 GPU 調達の困難さ JSR 様は課題を解決するために AWS Parallel Cluster やAWS DataSyncを掻甚するこずで以䞋の効果を獲埗したした。 オンプレミスサヌバヌ  CPU 蚈算リ゜ヌス のダりンスケヌル化  CPU 33% 、ストレヌゞ 85% を削枛 自動でコスト管理が可胜な CPU ・ GPU 蚈算リ゜ヌスの確保  1 幎かかっおいた調達が数分に 蚭備導入リスクの䜎枛 半幎先のリ゜ヌス予枬手続きが䞍芁に 自動的な実隓デヌタのバックアップず解析環境ぞの転送を実 珟実隓あたり 1 週間の時間短瞮 今埌、 JSR 様はラむフサむ゚ンス領域に加えおマテリアルズ・むンフォマティクス領域での HPC 利甚においおも AWS の掻甚を掚進するずずもに、 AWS Batch や AWS HealthOmics などの掻甚も芖野に研究ワヌクフロヌ党䜓の効率化に向けた取り組みを促進しおいく予定です。 JSR 株匏䌚瀟に぀いお JSR 株匏䌚瀟は「Materials Innovation ―マテリアルを通じお䟡倀を創造し、人間瀟䌚 人・瀟䌚・環境 に貢献したす。―」ずいう䌁業理念のもず、瀟䌚にずっおかけがえのないマテリアルを通じお、瀟䌚に貢献し、瀟䌚の信頌に応える䌁業を目指しおいたす。ラむフサむ゚ンス事業では、CDMO/CRO 事業ずいった創薬支揎サヌビス、蚺断詊薬材料、バむオプロセス材料などを提䟛しおいたす。 執筆者に぀いお 青戞 良賢JSR 株匏䌚瀟 JSR・慶應矩塟倧孊 医孊化孊むノベヌションセンタヌ (JKiC) 研究員。博士 理孊 。専門は生呜珟象を情報科孊から理解するバむオむンフォマティクス。がんやマむクロバむオヌム関連疟患ずいった疟患研究に加え、創薬プロセスに関わる技術開発を䞭心に研究掻動を担っおおりたす。  
Web アプリケヌションの開発ずデプロむにおける䞀般的な課題は、クラむアントずサヌバヌリ゜ヌス間のバヌゞョンのずれです。2025 幎 3 月 13 日、 AWS Amplify Hosting にデプロむされたアプリケヌション向けのデプロむメントスキュヌ保護機胜曎新期間䞭の新旧バヌゞョン混圚時のシステム安定性を確保する機胜を発衚できるこずを嬉しく思いたす。この機胜は、アプリケヌションのデプロむ䞭に゚ンドナヌザヌがシヌムレスな䜓隓を埗られるよう支揎したす。 課題 珟代の Web アプリケヌションは、倚数の静的アセットずサヌバヌサむドコンポヌネントからなる耇雑なシステムであり、これらすべおが連携しお動䜜する必芁がありたす。1 時間に耇数回のデプロむが䞀般的ずなっおいる䞖界では、バヌゞョンの互換性が重芁な懞念事項ずなりたす。新しいデプロむが行われるず、ナヌザヌのブラりザにキャッシュされた叀いバヌゞョンのアプリケヌションが、曎新されたデプロむメントからリ゜ヌスを取埗しようずしたす。これにより、404 ゚ラヌや機胜の砎損が発生する可胜性がありたす。 この課題は、クラむアントずサヌバヌのバヌゞョンのずれによっおさらに耇雑になり、それは 2 ぀の䞀般的なシナリオで珟れたす。1 ぀目に、ナヌザヌがブラりザタブを長時間開いたたたにするこずが倚く、アプリケヌションの叀いバヌゞョンを実行しながら、曎新されたバック゚ンドサヌビスずの察話を詊みるケヌスがありたす。2 ぀目に、モバむルアプリケヌションでは、自動曎新を無効にしおいるナヌザヌが叀いバヌゞョンを無期限に䜿甚し続ける可胜性があり、バック゚ンドサヌビスが耇数のクラむアントバヌゞョンず同時に互換性を維持する必芁がありたす。 これらのバヌゞョン管理の課題は、適切に察凊しなければナヌザヌ䜓隓ずアプリケヌションの信頌性に倧きな圱響を䞎える可胜性がありたす。以䞋のシナリオを考えおみたしょう。 ナヌザヌがアプリケヌションバヌゞョン Aを読み蟌む 新しいバヌゞョンバヌゞョン Bをデプロむする ナヌザヌのキャッシュされた JavaScript が、バヌゞョン A にのみ存圚しおいたアセットを読み蟌もうずする 結果機胜が壊れ、ナヌザヌ䜓隓が悪化する スキュヌ保護の仕組み Amplify Hosting は耇数のクラむアントセッション間でリク゚スト解決を賢く調敎し、意図したデプロむメントバヌゞョンぞの正確なルヌティングを確保したす。 1. スマヌトアセットルヌティング リク゚ストを受け取るず、Amplify Hosting は以䞋の凊理を行いたす。 リク゚ストの元ずなったデプロむメントバヌゞョンを識別したす リク゚ストを識別されたアセットのバヌゞョンにルヌティングしお解決したす ハヌドリフレッシュは垞にナヌザヌセッションで最新のデプロむメントアセットを提䟛したす 2. 䞀貫したバヌゞョンの提䟛 システムは以䞋を確認したす。 単䞀のナヌザヌセッションからのすべおのアセットが同じデプロむメントから提䟛されたす 新しいナヌザヌセッションは垞に最新バヌゞョンを取埗したす 既存のセッションは、リフレッシュされるたで元のバヌゞョンで動䜜し続けたす スキュヌ保護の利点 スキュヌ保護がもたらす利点は以䞋の通りです。 蚭定が䞍芁人気のあるフレヌムワヌクですぐに䜿甚可胜です 信頌性の高いデプロむメントデプロむメントのずれによる 404 ゚ラヌを排陀したす パフォヌマンス最適化レスポンスタむムぞの圱響を最小限に抑制したす ベストプラクティス スキュヌ保護はほずんどのシナリオを自動的に凊理したすが、以䞋を掚奚したす。 アトミックデプロむメントを行う ステヌゞング環境でデプロむメントプロセスをテストする スキュヌ保護の有効化 スキュヌ保護は各 Amplify アプリごずに有効化する必芁がありたす。これはすべおの Amplify Hosting アプリのブランチレベルで行われたす。詳しくは Amplify Hosting のドキュメント を参照ください。 1. ブランチを有効にするには、 App settings をクリックし、次に Branch settings をクリックしたす。次に、有効にしたいブランチを遞択し、 Action タブ をクリックしたす。 図 1 – Amplify Hosting ブランチ蚭定 2. スキュヌ保護を有効にするには、アプリケヌションを䞀床デプロむする必芁がありたす。 泚意スキュヌ保護は、埓来の SSRv1/WEB_DYNAMIC アプリケヌションを䜿甚しおいるお客様は利甚できたせん。 䟡栌 この機胜に 远加コストはなく 、Amplify Hosting が利甚できるすべおのリヌゞョンで利甚可胜です。 チュヌトリアル 始めるには、以䞋の手順に埓っお Next.js アプリケヌションを䜜成し、スキュヌ保護を有効にしおください。 前提条件 始める前に、以䞋がむンストヌルされおいるこずを確認しおください。 Node.js (v18.x 以降) npm たたは npx (v10.x 以降 Git (v2.39.5 以降) Next.js アプリの䜜成 スキュヌ保護の動䜜を確認するために Next.js アプリを䜜成したしょう。 1. TypeScript ず Tailwind CSS を䜿甚した新しい Next.js 15 アプリを䜜成したす。 $ npx create-next-app@latest skew-protection-demo --typescript --tailwind --eslint $ cd skew-protection-demo 2. デプロむメント ID を持぀フィンガヌプリントされたアセットをリストする SkewProtectionDemo コンポヌネントを䜜成したす。以䞋のコヌドを䜿甚しおコンポヌネントを䜜成しおください。 泚意Amplify はNext.js アプリのフィンガヌプリントされたアセットに、UUID に蚭定された dpl ク゚リパラメヌタを自動的にタグ付けしたす。この UUID は、他のフレヌムワヌクでも AWS_AMPLIFY_DEPLOYMENT_ID 環境倉数を通じおビルド䞭に利甚可胜です。 // app/components/SkewProtectionDemo.tsx "use client"; import { useState, useEffect } from "react"; import DeploymentTester from "./DeploymentTester"; interface Asset { type: string; url: string; dpl: string; } export default function SkewProtectionDemo() { const [fingerprintedAssets, setFingerprintedAssets] = useState<Asset[]>([]); const [deploymentId, setDeploymentId] = useState<string>("Unknown"); // Detect all assets with dpl parameters on initial load useEffect(() => { detectFingerprintedAssets(); }, []); // Function to detect all assets with dpl parameters const detectFingerprintedAssets = () => { // Find all assets with dpl parameter (CSS and JS) const allElements = [ ...Array.from(document.querySelectorAll('link[rel="stylesheet"]')), ...Array.from(document.querySelectorAll("script[src]")) ]; const assets = allElements .map(element => { const url = element.getAttribute(element.tagName.toLowerCase() === "link" ? "href" : "src"); if (!url || !url.includes("?dpl=")) return null; // Extract the dpl parameter let dplParam = "unknown"; try { const urlObj = new URL(url, window.location.origin); dplParam = urlObj.searchParams.get("dpl") || "unknown"; } catch (e) { console.error("Error parsing URL:", e); } return { type: element.tagName.toLowerCase() === "link" ? "css" : "js", url: url, dpl: dplParam, }; }) .filter(asset => asset !== null); setFingerprintedAssets(assets); // Set deployment ID if assets were found if (assets.length > 0) { setDeploymentId(assets[0]?.dpl || "Unknown"); } }; // Function to format URL to highlight the dpl parameter const formatUrl = (url: string) => { if (!url.includes("?dpl=")) return url; const [baseUrl, params] = url.split("?"); const dplParam = params.split("&").find(p => p.startsWith("dpl=")); if (!dplParam) return url; const otherParams = params.split("&").filter(p => !p.startsWith("dpl=")).join("&"); return ( <> <span className="text-gray-400">{baseUrl}?</span> {otherParams && <span className="text-gray-400">{otherParams}&</span>} <span className="text-yellow-300 font-bold">{dplParam}</span> </> ); }; return ( <main className="min-h-screen p-6 bg-white"> <div className="w-full max-w-2xl mx-auto"> <h1 className="text-2xl font-bold text-gray-900 mb-6"> Amplify Skew Protection Demo </h1> <div className="grid grid-cols-1 gap-4 mb-6"> <div className="flex items-center p-4 bg-white text-gray-800 rounded-md border border-gray-200 hover:bg-gray-50 transition-colors"> <div className="w-10 h-10 flex items-center justify-center bg-gray-100 rounded-lg mr-3"> <span className="text-lg">🚀</span> </div> <div> <p className="font-medium">Zero-Downtime Deployments</p> <p className="text-xs text-gray-600">Assets and API routes remain accessible during deployments using deployment ID-based routing</p> </div> </div> <div className="flex items-center p-4 bg-white text-gray-800 rounded-md border border-gray-200 hover:bg-gray-50 transition-colors"> <div className="w-10 h-10 flex items-center justify-center bg-gray-100 rounded-lg mr-3"> <span className="text-lg">⚡</span> </div> <div> <p className="font-medium">Built-in Next.js Support</p> <p className="text-xs text-gray-600">Automatic asset fingerprinting and deployment ID injection for Next.js applications</p> </div> </div> <div className="flex items-center p-4 bg-white text-gray-800 rounded-md border border-gray-200 hover:bg-gray-50 transition-colors"> <div className="w-10 h-10 flex items-center justify-center bg-gray-100 rounded-lg mr-3"> <span className="text-lg">🔒</span> </div> <div> <p className="font-medium">Advanced Security</p> <p className="text-xs text-gray-600">Protect against compromised builds by calling the delete-job API to remove affected deployments</p> </div> </div> </div> <div className="bg-gradient-to-r from-blue-900 to-purple-900 p-4 rounded-md mb-6"> <h2 className="text-sm font-medium text-blue-200 mb-1"> Current Deployment ID </h2> <div className="p-2 bg-black bg-opacity-30 rounded-md font-mono text-lg text-center text-yellow-300"> {deploymentId} </div> </div> {fingerprintedAssets.length > 0 ? ( <> <h2 className="text-xl font-bold text-gray-900 mb-6"> Fingerprinted Assets </h2> <div className="border border-gray-200 rounded-md overflow-hidden mb-6 bg-white"> <div className="max-h-48 overflow-y-auto"> <table className="min-w-full divide-y divide-gray-200"> <thead className="bg-gray-50"> <tr> <th className="px-3 py-2 text-left text-xs font-medium text-gray-900 uppercase tracking-wider w-16"> Type </th> <th className="px-3 py-2 text-left text-xs font-medium text-gray-900 uppercase tracking-wider"> URL </th> </tr> </thead> <tbody className="divide-y divide-gray-200"> {fingerprintedAssets.map((asset, index) => ( <tr key={index} className="bg-white hover:bg-gray-50"> <td className="px-3 py-2 text-sm text-gray-900"> <span className={`inline-block px-2 py-0.5 rounded-full text-xs ${ asset.type === "css" ? "bg-blue-100 text-blue-800" : "bg-yellow-100 text-yellow-800" }`} > {asset.type} </span> </td> <td className="px-3 py-2 text-xs font-mono break-all text-gray-900"> {formatUrl(asset.url)} </td> </tr> ))} </tbody> </table> </div> </div> <h2 className="text-xl font-bold text-gray-900 mb-6"> Test Deployment Routing </h2> <DeploymentTester /> </> ) : ( <div className="p-6 text-center text-gray-600 border border-gray-200 rounded-md"> <p>No fingerprinted assets detected</p> <p className="text-sm mt-2"> Deploy to Amplify Hosting to see skew protection in action </p> </div> )} </div> </main> ); } 3. 次に、各リク゚ストに X-Amplify-Dpl ヘッダヌを送信しお API リク゚ストがデプロむメントの䞀貫性を維持する方法を瀺す DeploymentTester コンポヌネントを䜜成したす。これにより、Amplify は正しい API バヌゞョンにルヌティングできたす。以䞋のコヌドを䜿甚しおコンポヌネントを䜜成しおください。 // app/components/DeploymentTester.tsx 'use client'; import { useState } from 'react'; interface ApiResponse { message: string; timestamp: string; version: string; deploymentId: string; } export default function DeploymentTester() { const [testInProgress, setTestInProgress] = useState(false); const [testOutput, setTestOutput] = useState<ApiResponse | null>(null); const [callCount, setCallCount] = useState(0); const runApiTest = async () => { setTestInProgress(true); setCallCount(prev => prev + 1); try { const response = await fetch('/api/skew-protection', { headers: { // Amplify provides the deployment ID as an environment variable during build time 'X-Amplify-Dpl': process.env.AWS_AMPLIFY_DEPLOYMENT_ID || '', } }); if (!response.ok) { throw new Error(`API returned ${response.status}`); } const data = await response.json(); setTestOutput(data); } catch (error) { console.error("API call failed", error); setTestOutput({ message: `Error: ${error instanceof Error ? error.message : 'Unknown error'}`, timestamp: new Date().toISOString(), version: 'error', deploymentId: 'error' }); } finally { setTestInProgress(false); } }; return ( <div className="border border-gray-200 rounded-md overflow-hidden bg-white"> <div className="bg-gray-50 px-4 py-3 flex justify-between items-center border-b border-gray-200"> <span className="font-medium text-gray-800">Test Deployment Routing</span> <button onClick={runApiTest} disabled={testInProgress} className={`px-3 py-1 rounded text-sm ${ testInProgress ? 'bg-gray-200 text-gray-500 cursor-not-allowed' : 'bg-blue-600 hover:bg-blue-700 text-white' }`} > {testInProgress ? "Testing..." : "Test Route"} </button> </div> <div className="p-4"> {testOutput ? ( <div className="p-3 bg-gray-50 rounded border border-gray-200 font-mono text-sm"> <div className="text-green-600 mb-2">{testOutput.message}</div> <div className="text-gray-600 text-xs space-y-1"> <div>API Version: <span className="text-blue-600 font-medium">{testOutput.version}</span></div> <div>Deployment ID: <span className="text-purple-600 font-medium">{testOutput.deploymentId}</span></div> <div>Call #: {callCount}</div> <div>Time: {new Date(testOutput.timestamp).toLocaleTimeString()}</div> </div> </div> ) : testInProgress ? ( <div className="p-3 bg-gray-50 rounded border border-gray-200 text-sm text-gray-600"> Testing deployment routing... </div> ) : ( <div className="p-3 bg-gray-50 rounded border border-gray-200 text-sm text-gray-600"> Click "Test Route" to verify how requests are routed to the correct deployment version </div> )} </div> </div> ); } 4. 次に、 X-Amplify-Dpl ヘッダヌを䜿甚しおリク゚ストがどのデプロむメントから来おいるかを識別する API ルヌトを䜜成し、Amplify がデプロむメント䞭にバヌゞョンの䞀貫性を維持するために API リク゚ストをルヌティングする方法をシミュレヌトしたす。以䞋のコヌドを䜿甚しお API ルヌトを䜜成しおください。 // app/api/skew-protection/route.ts import { NextResponse } from 'next/server'; import { type NextRequest } from 'next/server'; // This version identifier can be changed between deployments to demonstrate skew protection const CURRENT_API_VERSION = "v2.0"; export async function GET(request: NextRequest) { // Get the deployment ID from the X-Amplify-Dpl header // This is how Amplify routes API requests to the correct deployment version const deploymentId = request.headers.get('x-amplify-dpl') || ''; // Determine which version to serve based on deployment ID const apiVersion = CURRENT_API_VERSION; const message = `Hello from API ${apiVersion}! 🚀`; // Return the response with deployment information return NextResponse.json({ message, version: apiVersion, deploymentId: deploymentId || 'none', timestamp: new Date().toISOString() }); } 5. クラむアントコヌドからアクセスできるようにするため、Amplify デプロむメントの環境倉数を远加したす。 // next.config.ts import type { NextConfig } from "next"; const nextConfig: NextConfig = { env: { AWS_AMPLIFY_DEPLOYMENT_ID: process.env.AWS_AMPLIFY_DEPLOYMENT_ID || '', } }; export default nextConfig; 6. 倉曎を GitHub リポゞトリにプッシュしたす。 新しい GitHub リポゞトリを䜜成したす 倉曎を Git ブランチに远加しおコミットしたす リモヌトオリゞンを远加し、倉曎をアップストリヌムにプッシュしたす git add . git commit -m "initial commit" git remote add origin https://github.com/<OWNER>/amplify-skew-protection-demo.git git push -u origin main アプリケヌションを Amplify Hosting にデプロむする 以䞋の手順に埓っお、新しく構築したアプリケヌションを AWS Amplify Hosting にデプロむしおください。 AWS Amplify コン゜ヌル にサむンむン Create new app を遞択し、リポゞトリ゜ヌスずしお GitHub を遞択したす Amplify が GitHub アカりントにアクセスするこずを蚱可したす 䜜成したリポゞトリずブランチを遞択したす App settings を確認し、 Next を遞択したす 党䜓の蚭定を確認し、 Save and deploy を遞択したす スキュヌ保護を有効にする Amplify コン゜ヌルで、 App settings に移動し、次に Branch settings に移動したす。 Branch を遞択し、アクションドロップダりンメニュヌから Enable skew protection を遞択したす。 図 2 – Amplify Hosting ブランチ蚭定 次に、デプロむメントペヌゞに移動し、アプリケヌションを再デプロむしたす。アプリケヌションに察しおスキュヌ保護が有効になるず、AWS Amplify はその CDN キャッシュ構成を曎新する必芁がありたす。したがっお、スキュヌ保護を有効にした埌の最初のデプロむメントには最倧 10 分かかるこずを想定しおください。 図 3 – Amplify Hosting アプリのデプロむメント デプロむされた Next.js アプリにアクセスする Amplify コン゜ヌルの Overview タブに移動し、ブラりザで Amplify が生成したデフォルトの URL を開きたす。これで、アプリのフィンガヌプリントされたアセットのリストずデプロむメント ID が衚瀺されるはずです。 図 4 – Amplify Hosting アプリ蚭定 – ブランチレベル 図 5 – デモアプリのホヌムペヌゞ スキュヌ保護のテスト Next.js アプリケヌションを Amplify にデプロむするず、各デプロむメントには䞀意のデプロむメント ID が割り圓おられたす。この ID は、バヌゞョンの䞀貫性を確保するために、静的アセットJS, CSSず API ルヌトに自動的に挿入されたす。実際の動䜜を芋おみたしょう。 アセットフィンガヌプリント各静的アセット URL JavaScript ファむルや CSS ファむルなどには、珟圚のデプロむメント ID を瀺す「?dpl=」パラメヌタが自動的に付加されたす。䟋えば「main.js?dpl=abc123」のような圢匏です。これにより、ブラりザは垞にアセットの正しいバヌゞョンを取埗できたす。 API ルヌティング Test Route ボタンは、Amplify がどのようにしお API リク゚ストをルヌティングするかを瀺しおいたす。クリックするず、 /api/skew-protection ゚ンドポむントにリク゚ストを送信したす。リク゚ストは珟圚のデプロむメント ID に䞀臎する X-Amplify-Dpl ヘッダヌを䜿甚するため、正しい API バヌゞョンぞのルヌティングが保蚌されたす。 これは、デプロむメント䞭であっおも、ナヌザヌがバヌゞョンの䞍䞀臎を䜓隓せず、各ナヌザヌのセッションが最初に読み蟌んだバヌゞョンず䞀貫性を保぀こずを意味したす。これにより、クラむアントずサヌバヌのバヌゞョンが䞀臎しない堎合に発生する可胜性のあるバグを防止したす。 自分で詊しおみよう 珟圚のブラりザタブを開いたたたにしお、 Test Route をクリックしお、 API バヌゞョンずデプロむメント ID が䞀臎するこずを確認したす。 api/skew-protection/route.ts で異なる CURRENT_API_VERSION を持぀新しいバヌゞョンをデプロむしたす。 新しいシヌクレットりィンドりでアプリケヌションを開きたす。 動䜜を比范したす。 元のタブは叀いバヌゞョンを維持したす 新しいシヌクレットりィンドりは新しいバヌゞョンを衚瀺したす 各タブのアセットず API コヌルは、それぞれのバヌゞョンず䞀貫しお䞀臎したす 䞡方のりィンドりで Test Route を繰り返しクリックしおみおください。それぞれが䞀貫しお察応するバヌゞョンにルヌティングされ、耇数のバヌゞョンが同時に皌働しおいる堎合でも Amplify がセッションの䞀貫性を維持する方法を瀺しおいたす 図 6 – スキュヌ保護の動䜜の比范 これは、デプロむメント䞭にアプリケヌションの耇数のバヌゞョンが実行されおいる堎合でも、Amplify が各ナヌザヌセッションのバヌゞョンの䞀貫性をどのように維持するかを瀺しおいたす。 おめでずうございたす。Amplify Hosting 䞊の Next.js アプリケヌションデプロむメントでスキュヌ保護を正垞に䜜成しお怜蚌したした。 クリヌンアップ App settings に移動し、次に General settings に進み、 Delete app を遞択しお、AWS Amplify アプリを削陀したす。 次のステップ アプリケヌションのスキュヌ保護を有効にしたしょう この機胜に぀いおもっず孊ぶには、 ドキュメント をお読みください 本蚘事は Amplify Hosting Announces Skew Protection Support を翻蚳したものです。翻蚳は Solutions Architect の 郜築 が担圓したした。 著者に぀いお Matt Auerbach, Senior Product Manager, Amplify Hosting Matt Auerbach is a NYC-based Product Manager on the AWS Amplify Team. He educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Matt is a mild-mannered programmer who enjoys using technology to solve problems and making people’s lives easier. B night, however
well he does pretty much the same thing. You can find Matt on X @mauerbac . He previously worked at Twitch, Optimizely and Twilio. Jay Raval, Solutions Architect, Amplify Hosting Jay Raval is a Solutions Architect on the AWS Amplify team. He’s passionate about solving complex customer problems in the front-end, web and mobile domain and addresses real-world architecture problems for development using front-end technologies and AWS. In his free time, he enjoys traveling and sports. You can find Jay on X @_Jay_Raval_