みなさん、こんにちは。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_

勝負が紙一重で決まる Formula 1 (F1) の世界では、継続的な成功にはイノベーションが不可欠です。何十年もの間、チームは自動車技術の限界に挑戦し、常に変わりゆく環境のなかで優位に立つことを模索してきました。 Scuderia Ferrari HP 社と Amazon Web Services (AWS) のコラボレーションは、データ主導型の製造によって組立プロセスを再定義しています。 イノベーションを求める共通の取り組みにより、製造データクラウド移行のためにAWS は Scuderia Ferrari HP 社と協力しました。これには、あらゆる F1 カーの生命線である、個々のパワーユニットの準備と組み立て中に生成される膨大な量のデータが含まれていました。 Amazon SageMaker AI による機械学習 (ML) の機能を活用することで、チームは新しく作成したデータレイクの上に高度な処理パイプラインを構築しました。このアプローチにより、チームは詳細を調べ、結果を過去のデータと相関させることができ、分析能力が向上しました。チームは、以前の手動による方法と比較して、少なくとも 4 倍の量のデータを処理できるようになり、さらに半分の時間で分析結果を得ることができるようになりました。 レギュレーションとスピードに合わせたパワーユニットの調整 トラック上で最速で規制車が登場する F1 は、最高レベルのモータースポーツレースであり、国際自動車連盟 (FIA) によって厳しく規制されています。毎シーズン、ドライバーは、内燃エンジン、2つの電気モーター、ターボチャージャーのほか、エネルギー装置、電子制御機器、排気装置など、F1 カーに欠かせないパワーユニットに一定の要素を割り当てられます。 F1 はビッグデータのスポーツですが、ごく僅かなデータポイントによってチームの勝利を逃すことがあります。部品が制限を超えるたびにドライバーはペナルティを課せられるため、チームは厳しいテストを行い、シーズン前とシーズン中のパワーユニットの変更について非常に戦略的に取り組む必要があります。 2024 Formula One Sporting Regulations によりますと、一度制限を超える部品を使用されると、10 グリッドのペナルティが発生し、車が表彰台を獲得する可能性が大幅に低下します。 「パワーユニットは非常に複雑なため、当社の技術チームはレースで潜在的な問題を引き起こしうる欠陥に対処し先手を打っています」と Scuderia Ferrari HP Power Unit Assembly の責任者である Alessio Simi 氏が述べています。「AWS を導入したことで、他の方法では見逃してしまう可能性のある異常を検出でき、メインイベントのかなり前に調整を行う機会を得ることができました。」 図1 : 組み立てプロセスの一部 機械学習と生成 AI によるエンジニアリングの強化 2024 年のレースシーズンに向けて、チームはアプローチを改善し、エンジニアがより良いデータ分析結果をより迅速に入手するための方法を模索し始めました。モータースポーツシーズンは通常 3 月から 12 月にかけて行われるため、エンジニアがプレシーズンのデータ分析を行う時間は限られており、各レースの合間に最適化や調整を行う時間はさらに短くなります。AWS の強力なデータ基盤により、Scuderia Ferrari HP 社はアセンブリを一貫して監視できるようになり、コンポーネントを過度に交換しなくてもパワーユニットが F1 シーズン全体の厳しい状況に耐えられるようにします。 AWS は Scuderia Ferrari HP 社と協力して、Amazon Simple Storage Service ( Amazon S3 ) を使用してデータレイクを構築しました。その後、チームは Amazon SageMaker AI を使用して処理パイプラインを構築し、複数の異なるソースからのデータを統合しました。製造中の包括的なテストと測定は、潜在的な欠陥や早期摩耗が発生しやすい部分を特定するのに役立ち、チームはコンポーネントが使用される前にこれらの問題に対処できます。 以前は、データが複数のシステムに分散している状態で、データ分析と評価は個々のエンジニアが手動で行っていたため、長期的に発生する故障につながる可能性のある問題の原因を突き止めることは困難でした。たとえば、ボルトが常に締めすぎているような僅かな違いにより、時間の経過とともにエンジンが不安定になり、トラック上に問題を引き起こすリスクが高まる可能性があります。各車に 300 個のセンサーが搭載されており、膨大な量のデータを手動で確認することはほとんど不可能になりました。「当社のエンジニアの専門知識は不可欠ですが、人間がテラバイト単位のデータを分析するのは合理的ではありません。」と Simi 氏は言います。 データが統合されると、データ分析を専門とする Scuderia Ferrari HP 社のエンジニアリングチームが Amazon QuickSight で一元化されたダッシュボードビューを作成しました。これにより、あらゆる専門分野のエンジニアが組み立てを監視し、潜在的な偏差をほぼリアルタイムで観察できるようになりました。このアクセスと可視性の向上により、チームはインサイトを得るまでの時間を平均 50% 短縮しました。「この反応性のおかげで、プロセスやコンポーネントに直接介入できるため、間違ったフィッティングを完成させたり、材料を無駄に浪費したりすることがなくなります。」と Simi 氏は付け加えます。 チームが監視する要素の 1つがドリフトです。ドリフトとは、部品の重要な測定値や性能パラメータが時間の経過とともに徐々に意図せず変化することです。たとえば、電力や燃料効率が徐々に低下したり、シーズンを通してセンサーの精度が徐々に低下したりすることがあります。「すべての情報が単一のデータレイクにあるため、傾向とドリフトを評価して異常値との関係を確認したり、製造プロセスにおける形状の差異を特定したりすることできます。」 図 2 : Amazon QuickSight ダッシュボード Amazon Q in QuickSight の新機能により、レーシングエンジニアは Q&A 回答で重要な洞察やトレンドを発見したり、自然言語プロンプトで独自のダッシュボードを作成したりして、継続的なメンテナンスとレビューを行うこともできます。「このスポーツではスピードが不可欠です。すでに当社のデータとインフラはAWS上で良好な状態にあり、より迅速かつ正確に問題を発見し、調整を行うことができます。」 まとめ 自動化されたデータ収集と処理を ML に委任することで、Scuderia Ferrari HP 社は洞察をより迅速に収集、分析、行動に移すことが可能になりました。このプロジェクトがパワーユニット製造で最初に成功したことを踏まえ、同様の戦略が性能に関連する他の用途にも展開しようとしています。「シーズン中に大幅なアップグレードを導入することは規制によって制限されていますが、私たちのデータアーキテクチャは将来のイノベーションへの道を開いています。」と Simi 氏はまとめました。 Scuderia Ferrari HP チームは、メルボルンで開催されるオーストラリアグランプリで始まる 2025 年シーズンの準備に懸命に取り組んできました。あらゆるテスト、シミュレーション、および実際のパフォーマンスデータポイントを取得できると、改善の余地がある領域に関する貴重な洞察が得られます。「これにより、次世代のパワーユニット設計の主要な開発領域を特定し、優先順位を付けることができ、競争の激しい F1 の世界で大きく有利なスタートを切ることができました。」 お客様がどのようにデータ主導型の AWS ソリューションを活用して、スポーツの観戦、プレー、管理の方法を改革しているかをこちらで確認できます。 Keely O’Neill Keely O’Neill は、Amazon Web Services (AWS) でスポーツマーケティングのシニア統合マーケティングマネージャーで、Formula 1、Ferrari 社、Bundesliga とのパートナーシップの統合マーケティングを率いています。体験型マーケティング、コミュニティエンゲージメント、デジタルマーケティングで 12 年以上の経験を持つ Keely は、独自の専門知識を持ち、好奇心とデータインサイトに基づいた戦略的なキャンペーンを通じて、インパクトのある顧客体験を生み出します。現在の役職に就く前は、AWS スタートアップのグローバルマーケティングを担当し、Brooks Running Company 社と Tableau Software 社で役職を歴任しました。 このブログの翻訳はソリューションアーキテクトのシャルノ ミカエルが担当しました。原文は「 How AWS supports Scuderia Ferrari HP to optimize Formula 1® power unit assembly process 」です。

4 月 7 日週から AWS Summit のシーズンが始まります! これらの無料のイベントは世界中で開催されており、AWS のクラウドコンピューティングコミュニティが一堂に会してつながり、コラボレートし、学んでいます。オンライン参加か現地参加かにかかわらず、これらの会合は AWS の知識を深める貴重な機会を提供します。私は、今週開催される、フランスで最も大きいクラウドカンファレンスの Paris Summit 、そして月末に開催される London Summit に出席する予定です。小さなポッドキャスト録音スタジオを用意し、そこでフランスとイギリスのお客様にインタビューして、 AWS Developers Podcast と 語の AWS ポッドキャスト の新しいエピソードを制作します。 いますぐご登録ください! それでは、3 月 31 日週の新しいお知らせを見てみましょう。 3 月 31 日週のリリース KubeCon London では、 EKS コミュニティアドオンカタログ をご紹介しました。Kubernetes ユーザーは、強力なオープンソースツールを使用して簡単に Amazon EKS クラスターを強化できるようになります。このカタログは metrics-server 、 kube-state-metrics 、 prometheus-node-exporter 、 cert-manager 、 external-dns などの重要なアドオンのインストールを合理化します。これらのコミュニティ主導型アドオンを EKS コンソールと AWS CLI に直接統合することで、お客様は柔軟性とセキュリティを維持しながら、運用の複雑さを軽減し、デプロイを迅速に行うことができます。今回の発表は、Kubernetes コミュニティに対する AWS の取り組みを反映したもので、手動によるインストールやメンテナンスの手間をかけることなく、信頼できるオープンソースソリューションへのシームレスなアクセスを実現します。 Amazon Q Developer が Amazon OpenSearch Service と統合 され、自然言語による探索と AI 支援のデータ視覚化が可能になり、運用分析が強化されました。この統合により、運用データのクエリと視覚化のプロセスが簡素化され、従来のクエリ言語やツールに関連する学習曲線が短縮されます。インシデント対応中、Amazon Q Developer は状況に応じた要約とインサイトをアラートインターフェイス内で直接提供し、迅速な分析と解決をサポートします。この進歩により、エンジニアはトラブルシューティングプロセスを合理化し、監視インフラストラクチャを改善することで、イノベーションにより集中できるようになります。 Amazon API Gateway は、商用リージョンと AWS GovCloud (米国) リージョンの両方において、すべてのエンドポイントタイプ、カスタムドメイン、管理 API でデュアルスタック (IPv4 と IPv6) エンドポイントのサポートを開始 しました。この拡張機能により、REST、HTTP、WebSocket API、カスタムドメインが IPv4 クライアントと IPv6 クライアントの両方からの要求を処理できるようになり、IPv6 へのスムーズな移行が容易となり、IPv4 アドレスの不足に対処できます。さらに、AWS は、IPv4 と IPv6 を介したシームレスな接続を実現する デュアルスタックのパブリックエンドポイントを取り入れた AWS Identity and Access Management (IAM) 、 お客様が IPv6 アドレスを使用してリソース共有を管理できるようにする AWS Resource Access Manager (RAM) などの最近の更新により、IPv6 の採用への取り組みを継続しています。 Amazon Security Lake のお客様も、新しいデュアルスタックのエンドポイントを介して、インターネットプロトコルバージョン 6 (IPv6) アドレスを使用してサービスを設定および管理 できるようになりました。これらの進歩により、ネットワークインフラストラクチャの互換性と将来にわたる保証が、より広範囲に及ぶようになります。 Amazon Simple Email Service (SES) は、v2 API の E メール添付ファイルのサポートを開始しました。ユーザーは、手動で MIME メッセージを作成しなくても、PDF や画像などのファイルをメールに直接含められるようになります。この機能強化により、情報量の多いメールコンテンツを送信するプロセスが簡素化され、実装の複雑さが軽減されます。SES は、サービスが利用可能なすべての AWS リージョンの添付ファイルをサポートします。 Amazon Neptune はサービスレベル契約 (SLA) を更新し、マルチ AZ DB インスタンス、マルチ AZ DB クラスター、マルチ AZ グラフ構成の月間稼働率を以前の 99.9% から 99.99% に引き上げ ました。この強化は、ミッションクリティカルなアプリケーションに対して、可用性と信頼性の高いグラフデータベースサービスを提供するという AWS の取り組みを示しています。改善された SLA は、Amazon Neptune が提供されているすべての AWS リージョンで利用できるようになりました。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 コラボレーションスペースであり、没入型エクスペリエンスでもある AWS GenAI Lofts  は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。  お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 近日開催予定のすべての AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 4 月 7 日週のニュースは以上です。4 月 14 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – seb この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

AWS Amplify Hosting では、より多くの Amplify アプリを 1 つのリポジトリに接続できるようになりました。この変更により、開発者が Git プロバイダーと統合する方法が改善され、特にモノレポアーキテクチャに有益です。 Amplify は、関連するすべてのアプリに対して 1 つのリポジトリにつき 1 つの Webhook を使用するようになり、開発ワークフローが効率化されました。具体的な制限の詳細については、 ドキュメント を参照してください。 以前は、Amplify ユーザーは Git プロバイダーが提供する Webhook の上限に制約されていました。Amplify はリポジトリに関連付けられた各アプリごとに新しい Webhook を作成したため、単一のリポジトリに複数の Amplify アプリをリンクしているユーザーは、その上限にすぐに達してしまい、アプリをさらに追加できませんでした。これは、複数のプロジェクト（複数のAmplifyアプリ）が単一のリポジトリ内に存在する、モノレポで作業しているチームにとっては特に難しいことでした。 Git プロバイダーによって許可される Webhook の具体的な数は異なりますが、これらの制限はプロジェクトを拡大したり、複雑なリポジトリ構造で作業を行ったりするチームにとって障害となっていました。 GitHub には 20 個の Webhook 制限 があります GitLab には 100 個の Webhook 制限 があります BitBucket には 50 個の Webhook 制限 があります 統合された Webhook Amplifyに関連するすべての Webhook を 1 つの統合された Webhook にまとめることで、この問題を解決します。これにより、リポジトリの管理が簡素化され、Webhook の制限に縛られることなく、すべての関連する Amplify アプリが更新とトリガーを受け取ることができます。 主な利点 Git プロバイダーの制限を克服: 現在の Webhook の制限を取り除き、必要な数の Amplify アプリを単一のリポジトリに接続できるようになります。 モノレポサポートの強化: 複数のプロジェクトが単一のリポジトリを共有するモノレポ構造で作業する際に、より柔軟性と効率性を得られます。 管理の簡素化: 単一のリポジトリの Webhook を利用して複数の Amplify アプリを管理でき、複雑さと潜在的な障害ポイントを減らすことができます。 ワークフロー統合の改善: 開発プロセスの他の重要なワークフローに Webhook スロットを解放できます。 統合された Webhook の概要 新しいアプリの場合 Amplify Hosting でウェブアプリをデプロイ します。Webhook 機能が組み込まれるので、リポジトリに自動的に実装されます。 既存の Amplify ユーザー向け この新機能を利用するには、リポジトリを Amplify アプリに再接続する必要があります。手順は次のとおりです。 AWS 管理コンソールで Amplify アプリに移動します。 アプリのリポジトリ設定を探します。 リポジトリ情報の横にある「再接続」ボタンをクリックします。 既存の Webhook を新しい統合された Webhook に置き換えるアクションを確認します。 手順 2 つの Amplify アプリ を含むリポジトリから、新しい統合された Webhook に切り替える例を示します。 各 Webhook は次のようになります。 次に Amplify Console に移動し、 App settings → Branch の Reconnect Repository ボタンを見つけてください。 Configure GitHub App と Complete installation をクリックしてください。 しばらくすると、リポジトリが統合された Webhook に切り替わったことがわかります。 これで準備は整いました。このリポジトリに接続された新しい Amplify アプリは、ここで同じ統合された Webhook を使用します。 重要な考慮事項 マイグレーション中の Webhook の制限: すでに Git プロバイダーが許可されている Webhook の最大数に達している場合、自動マイグレーションが機能しない可能性があります。この場合、事前に既存の Webhook 1 つ以上を手動で削除する必要な場合があります。 リージョン別の操作: Webhook の移行を含むすべての操作は、リージョン別に行われます。つまり、移行は Amplify アプリを再接続したリージョンの Webhook に対してのみ行われます。 まとめ AWS Amplify Hosting の統合された Webhook の導入により、リポジトリ管理が簡素化され、モノレポなどの複雑なプロジェクト構造のサポートが強化されました。 Webhook のオーバーヘッドを削減し、Git リポジトリと Amplify アプリの接続をストリーム化することで、開発者はインフラストラクチャの制限の管理よりも優れたアプリケーションの構築に集中できるようになりました。 私たちは、この機能が特に大規模で複雑なリポジトリを扱う際の開発ワークフローを改善することを心待ちにしています。 Amplify コンソール で Next.js、Nuxt、React、Angular、Vue、その他のフロントエンドアプリをデプロイし、 Discord の当社コミュニティに参加して、ご意見やご経験を共有してください。 本記事は、2025 年 3 月 10 日に公開された Simplifying Multi-App Management in AWS Amplify Hosting を翻訳したものです。翻訳は 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 Twitter @mauerbac. He previously worked in Developer Relations at Twitch, Optimizely & Twilio. Linsong Wang, Software Development Engineer, Amplify Hosting Linsong builds features that make it easier for customers to host front-end web applications backed by the reliability and convenience of AWS. In his free time, Linsong enjoys exploring cooking recipes, playing piano, and building life improvement prototype

本記事は 2025 年 4 月 9 日に公開された “ Speaking Your Language: Expanded language support in Amazon Q Developer ” を翻訳したものです。 ソフトウェア開発がますますグローバル化するなかで、多言語に対応したツールの必要性は最優先事項になっています。本日は、 Amazon Q Developer における言語サポートの拡張を発表できることを嬉しく思います。この投稿では、世界中の開発者が利用する強力なプラットフォームである Amazon Q Developer における、言語サポートの拡張についてご紹介します。Amazon Q Developer は、アーキテクチャの議論、ドキュメントの作成、インターフェイスのデザイン、アプリケーション開発など、さまざまな用途で活用されています。 プログラミングの共通言語として英語が使われているのは変わりませんが、現代のソフトウェア開発の実態はコードにとどまりません。世界中の開発者が Amazon Q Developer を活用して、アーキテクチャの意思決定を議論したり、ドキュメントを作成したり、ユーザーインターフェースを設計したり、世界中のユーザーを想定したアプリケーションを構築したりしています。言語サポートが拡張されたことにより、Amazon Q Developer は、システムアーキテクチャの設計、ドキュメントの生成、アプリケーションのローカライズ戦略の検討など、複雑な技術的概念についても、開発者がもっとも使いやすい言語で、より自然でスムーズに対話できるようになりました。 この言語サポートの拡張の効果は、以下の画像で示されています。私は「コンテナホスティングに関する質問」を英語・中国語・ヒンディー語・スペイン語で尋ねました。Amazon Q Developer は、それぞれの言語で正確かつ完全な回答を返すだけでなく、技術的な正確さを保ちつつ、言語ごとのニュアンスにも対応しています。さらに、Amazon Q Developer はユーザーが使用している言語に応じて、関連するフォローアップ質問を提案してくれるため、より直感的で自然な会話体験が可能になります。このように、どの言語でも自然にやり取りできることは、開発者の集中力を妨げず、言語の壁による精神的負荷を取り除く効果があります。 今回の言語サポート拡張は、 統合開発環境 (IDE) および コマンドラインインターフェース (CLI) ですでに利用可能で、 AWS マネジメントコンソール にも近日対応予定です。私の IDE では、 チャット 、 インラインチャット 、 インライン提案 、 エージェント などに対して、多言語をサポートしました。以下の例では、私はフランス語で Amazon Q Developer に「コードに TSDoc コメントを追加してほしい」とインラインチャットで依頼しました。 たとえば、韓国・ソウルで韓国語のドキュメントを書く開発者、スペイン・マドリードでスペイン語でアーキテクチャ設計を検討するスタートアップ、ポルトガル語でコラボレーションするブラジルのチームといったどなたに対しても、Amazon Q Developer は、あなたの開発の旅路と、あなたのお好きな言語をサポートできる準備が整いました。この言語サポートの拡張は、Free Tier と Pro Tier の両方のユーザーに本日より提供開始されます。ぜひ Amazon Q Developer の利用を開始し 、フィードバックをお寄せください。私たちは皆さんと共に、ソフトウェア開発の未来をより包括的でアクセスしやすいものにしていきます。 翻訳はApp Dev Consultantの宇賀神が担当しました。

はじめに AWS は、2024年12月13日に大阪リージョンに属する初のAWS Direct Connect ロケーションであるTelehouse OSAKA2(以後、OSAKA2)の開設を 発表 しました。これにより、 AWS Direct Connect を利用して関西地域に閉じたロケーション冗長を行うことが可能になり、AWS クラウドの大阪リージョンをメインリージョンとしたワークロードおよびハイブリッドネットワークをより最適化することができます。もちろん、東京や海外など他のリージョンへの接続にも利用できます。 関西地域のDirect Connect ロケーションは、Equinix OS1(以下、OS1)に続いて二つ目となります。しかし、ご存じでしょうか。 OS1 は古くからあるため、東京リージョンに属しています 。本記事では、この二つのDirect Connect ロケーションを活用したオンプレミスネットワークとAWS クラウドとの接続に関するアーキテクチャと、その考慮点について解説します。他のリージョンやDirect Connect ロケーションをお使いになる方も、参考となるよう記述しています。 なお、この記事はDirect Connect とeBGP の基礎知識を有した方を対象としています。 ロケーション冗長について Direct Connect では、お客様ネットワークとの接続点をDirect Connect ロケーションと呼称しています。これは、データセンター内で光ファイバーによる直接接続を行う物理的な場所を示しています。 こちらのページ を参照すると、そのリストを確認することができます。 ネットワークの物理レイヤーを検討する際、Direct Connect ロケーションの選定は重要です。WAN サービスなどのお客様ネットワークとAWS クラウドを接続する場合、地理的に近いほど高いパフォーマンスを期待できるためです。関西地域にデータセンターや本社機能を持つお客様や、大阪リージョンを主に利用しているお客様は、OSAKA2 の開設により、OS1と組み合わせてロケーション冗長を構成することが可能になりました。 Direct Connect では、お客様のルーターと、AWS のルーターとの間でeBGP を構成します。お客様のルーターは、ご利用の回線サービスにより、Direct Connect ロケーションと同一のデータセンターに設置することも、離れた別のデータセンターやオフィスなどに設置することもできます。この構成に関わる技術要件は、AWS ルーターとお客様ルーターをレイヤー2で接続し、eBGPピアを構成するためのPoint to Point の通信を行えることになります（eBGP マルチホップを利用することはできません）。 図1では、OS1 とOSAKA2 の二つのDirect Connect ロケーションと、4つのDirect Connect 接続を組み合わせて、データセンターレベルの障害にも対応できる可用性を実現する際の構成例を示しています。Direct Connect では、 回復性に関する推奨事項 や サービスレベルアグリーメント(SLA) にも示しているとおり、重要なワークロードに対しては複数のロケーションを活用することを推奨しています。 図1. 最大回復性を満たすアーキテクチャー例 シナリオ1 アクティブ /スタンバイ構成 複数のDirect Connect を活用して可用性を高めるには、きめ細かいトラフィックコントロールが必要になります。ここでは、理解しやすいよう4つのDirect Connect 接続にそれぞれ優先度を設定し、アクティブの接続が切断された場合、優先度順にフェイルオーバーを行うことを要件とします。つまり、4重の冗長をとる構成となります。図2は、その設計を示しています。なお、経路ごとに優先順位を制御することも可能です。 図2.アクティブ/スタンバイ構成の各接続の優先度設計 シナリオ1-1 AWSからお客様ネットワークに向かうトラフィックのコントロール AWS のBGP ルーターがお客様のBGPルーターから受信した経路情報は、図2の構成の場合Direct Connect Gateway やAWS Transit Gateway に伝搬されます。4つの回線のうちどの回線がベストパスとして採用されるかについては、受信した経路情報のBGP アトリビュートに依存します。なお、Direct Connect では、AWS ルーターのBGP アトリビュート値を明示的に設定をすることはできないことに注意してください。したがって、図2のような優先度になるようにBGP アトリビュートの設定をお客様ルーターで行う形になります。 では、具体的にどのようにアトリビュートを設定するべきでしょうか。ここで、BGP のベストパス選択アルゴリズムを振り返ります。このような構成の場合に考慮すべきは、ローカルプリファレンス、AS_PATH、Multi-Exit Discriminator (MED)の3つで、記載順で優先順位が高くなります。MED については優先度が低いことから、 ドキュメント に記載の通り、積極的な活用は推奨していません。 最もシンプルな方法は、お客様側のBGP ルーターで、AWS へ広告する経路にAS_PATH Prepend を使って優先度を操作することです。AWS側で暗黙に設定しているローカルプリファレンス値が同値であると仮定し、図3に示すようにAS_PATH 長によってベストパスを決定させる狙いです。このアプローチは、これまで多くのケースで採用されてきました。 図3 AS_PATHによる優先度設計のアプローチ ただし、注意してください。今回の構成例の場合、これだけではベストパス選択は期待通りに行われません。これは、 OS1が東京リージョンに属し、OSAKA2が大阪リージョンに属することに起因します 。 Direct Connect では、AWS からお客様ネットワークへのパスを最適化するため、ローカルプリファレンス 値が暗黙的に設定されます。これは、通信の発信元リージョンと、宛先のDirect Connect ロケーションがどのリージョンに属するかによって決定されます。例として、大阪リージョンから発信された通信は、大阪リージョンに属するOSAKA2を優先するようにローカルプリファレンス 値が設定されます。ローカルプリファレンス 値はAS_PATH 属性の前に評価されるため、OSAKA2がベストパスに採用されます。 では、OS1を優先したい場合どうするべきでしょうか。Direct Connect ではこのようなケースのため、暗黙的に設定されるローカルプリファレンス 値をお客様の意図通りに上書きするためのBGP Community タグ機能を提供しています。 お客様ルーターから受信した経路に、BGP Community アトリビュートの指定されたタグが設定されていると、AWS は以下のような優先順になるようローカルプリファレンスの値を上書きします。詳しくは、 ドキュメント をご参照ください。 7224:7100 : 優先設定: 低 7224:7200 : 優先設定: 中 7224:7300 : 優先設定: 高 上記の通り、3段階で設定することができます。今回の例では4回線あるため、3段階では不足です。しかしながら、AS_PATH Prepend を組み合わせることで、意図した制御を行うことができます。今回は、BGP Community タグを用いてローカルプリファレンス値を全て等コストになるよう上書きし、AS_PATH による評価で優先度1の接続をベストパスとして選択させるようにします。 図4は、その設定を図示しています。 図4. Community タグとAS PATH Prepend によるトラフィックコントロール このように、Community タグと AS PATH Prepend によってAWS からお客様ネットワークへのベストパスをコントロールできます。優先度1のBGPピアが切断された場合、優先度2にフェールオーバーします。優先2が切断されたら優先度3に・・という形で、順にフェールオーバーさせることができます。 シナリオ1-2 お客様ネットワークからAWS に向かうトラフィックのコントロール 続いて、お客様ネットワークからAWS に向かうトラフィックのコントロールについてです。優先度の要件は、前述の逆向きの通信と同様とします。 Direct Connect では、お客様のBGP ルーターに対して広告する経路のBGP アトリビュートをカスタマイズすることはできません。また、特別な設定があらかじめ行われていることもありません※1。したがって、AWS からの経路を受信するお客様のネットワークで自由にトラフィックコントロールを行うことができます。 どのように優先度を設定するかについては、お客様ネットワークの構成によってさまざまな方法が考えられます。例えば、お客様ネットワークはOSPF で構成され、Direct Connect のBGP 経路はOSPF ネットワークに再配布するようなケースも考えられます。お客様ネットワークが通信事業者のWAN サービス等である場合は、そのサービス仕様にも依存します。今回は、図に存在するCustomer WAN が、BGP アトリビュートによる制御に対応しているWAN サービスであると仮定し、AS_PATHにより制御する例をご紹介します。 図5では、AWSから受け取った経路をWANサービスに伝搬する様子を表現しています。 図5. お客様ネットワークからAWS 向けトラフィックのコントロール例 伝搬する際、AS_PATH により優先順位を設定しています。先ほどは、お客様ルーターがAWS に広告する経路に対して設定しましたが、今回はAWS から広告されてきた経路をWANサービスに伝搬する際にAS_PATH Prepend を設定しています。図5に示した表は、WAN サービスが持つBGPテーブルのイメージです。今回は特にローカルプリファレンスやMED は活用しませんでしたが、構成やご利用のWAN サービスによっては活用することもあります。 ※1 Public VIFについては、AWS が広告する経路にリージョン制御のためのCommunity タグがサポートされています。詳しくは ドキュメント をご参照ください。 シナリオ2 ロードバランス（ECMP）構成 Direct Connect は、Equal Cost Multi Path(ECMP) に対応しています。AWS がベストパス選択を行う際、最も優先度の高いパスが複数あった場合、それらはロードバランスされます。本シナリオは、すべてのDirect Connect 接続を等コストに設定し、トラフィックをロードバランスすることによって、突発的なトラフィック増に備えることを想定します。 Direct Connect 接続がすべて1Gbps だったとしましょう。その場合、シナリオ1では最大帯域幅は1Gbps になります。 4重の冗長構成が取られているため、障害に対して非常に堅牢な反面、スタンバイ側の回線は普段利用しないことになります。ECMP を利用すると、すべての回線を有効活用して最大4Gbps まで対応することができます。ただし、このような構成で普段から4Gbps のトラフィックを利用することは推奨しません。それは、以下のような理由によるものです。 ・ECMP によるロードバランスは各接続の最大帯域を考慮しない ・ECMP によるロードバランスはネットワーク機器に実装により、ある程度の偏りが生じることが想定される ・障害やメンテナンス時に最大帯域が減少し、重要なトラフィックが欠損する可能性がある 本構成を採用する場合、「突発的に1Gbps 以上のトラフィックが発生した場合」に対応できること、を要件とすることを推奨します。また、通信経路が行きと帰りで非対称になる可能性があるため、そのようなトラフィックをフィルタリングする機器が導入されていないかどうかも考慮する必要があります。 なお、有効帯域の増加を考える場合、Direct Connect はLink Aggregation Group (LAG) にも対応しています。 詳しくは ドキュメント をご参照ください。 さて、以下に示す図6は、ECMP の優先度設計の考え方を示しています。 図6 ECMPを行う際の優先度設計 全てを同じ優先度1としています。なお、例としてOS1 の二つの接続を優先度1、OSAKA2の二つの接続を優先度2として、最大帯域を 2Gbps としてロードバランスさせることもできます。要件により、さまざまな設計が可能です。 シナリオ2-1 AWSからお客様ネットワーク に向かうトラフィックのコントロール シナリオ1では、BGPのCommunity タグとAS_PATH 属性を組み合わせて優先度を決定しました。シナリオ2 では、等コストにすることを目的としますので、以下の通り、Commnunity タグのみ利用します。 図7 Community タグによる等コスト設定 この例では、Community タグによってAWS が暗黙に設定するローカルプリファレンス値を上書きし、すべて優先設定：中にすることによって等コストに設定しています。これにより、AWS からお客様ネットワークに向かうすべてのトラフィックは4 つの接続にロードバランスされます。シナリオ1で利用したAS_PATH Prepend を利用する必要はありません。 シナリオ2-2 お客様ネットワークからAWS に向かうトラフィックのコントロール 今回はWAN サービスを利用していることを想定しているため、ご利用のサービスがECMP に対応していれば、特に優先度をつけずにWAN サービスにAWS からの経路を伝搬させることでECMP を実現できます。ご利用の際は、必ずWAN サービスやルーターのサービス仕様をご確認ください。 まとめ 本記事では、大阪リージョンに属する初めてのDirect Connect ロケーションである Telehouse OSAKA2のご紹介と、これを活用した冗長構成とトラフィックコントロールの例をご紹介しました。今回ご紹介した内容は、例えば東京とアメリカであったり、異なるリージョンに属するロケーションが混在する際にも活用できます。また、例えばEquinix TY2とOS1など、同じリージョンに属するDirect Connect ロケーションのみ利用する際にも、今後の拡張に備えてBGP Community タグを利用することを推奨いたします。 本記事は、Network Specialist Solutions Architect の奥村が執筆しました。

本記事は 2025 年 4 月 7 日に AWS Machine Learning Blog で公開された Effectively use prompt caching on Amazon Bedrock を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。 Amazon Bedrock において、プロンプトキャッシュの一般提供が開始されました。Anthropic の Claude 3.5 Haiku と Claude 3.7 Sonnet に加え、 Nova Micro、 Nova Lite、 Nova Pro モデルで利用可能です。複数の API 呼び出しにおいて頻繁に使用されるプロンプトをキャッシュすることで、応答時間を最大 85% 短縮し、コストを最大 90% 削減します。 プロンプトキャッシュを使用すると、特定の連続したプロンプト部分 ( プロンプトプレフィックスと呼ばれます ) をキャッシュ対象として指定できます。指定されたプロンプトプレフィックスを含むリクエストが送信されると、モデルは入力を処理し、そのプレフィックスに関連する内部状態をキャッシュします。その後、同じプロンプトプレフィックスを含むリクエストがあると、モデルはキャッシュから読み取り、入力トークンの処理に必要な計算ステップをスキップします。これにより、最初のトークンが生成されるまでの時間 (time to first token, TTFT) が短縮され、ハードウェアがより効率的に利用されます。そのため、ユーザーはより安い価格でサービスを利用できます。 この記事では、Amazon Bedrock のプロンプトキャッシュに関する総合的な説明と、レイテンシー改善とコスト削減を実現するための効果的な活用方法を解説します。 プロンプトキャッシュの仕組み 大規模言語モデル (large language model, LLM) の処理は、主に 2 つの段階で構成されています。入力トークン処理と出力トークン生成です。 Amazon Bedrock のプロンプトキャッシュは、この入力トークン処理の段階を最適化します。 まず、プロンプトの関連部分にキャッシュチェックポイントを指定します。チェックポイントより前のプロンプト全体がキャッシュされるプロンプトプレフィックスになります。キャッシュチェックポイントで指定されたものと同じプロンプトプレフィックスを含むリクエストを送信すると、LLM はそのプレフィックスがキャッシュに既に保存されているかどうかを確認します。一致するプレフィックスが見つかった場合、LLM はキャッシュから読み取り、最後にキャッシュされたプレフィックスから入力処理を再開できます。これにより、プロンプトプレフィックスを再計算するために必要だった時間とコストを節約できます。 なお、モデルによってプロンプトキャッシュの対応状況が異なりますので、注意ください。対応しているモデル、サポートされているモデル、キャッシュチェックポイントあたりの最小トークン数とリクエストあたりの最大キャッシュチェックポイント数の詳細については、 関連ドキュメント を確認してください。 キャッシュヒットは、プレフィックスが完全に一致した場合にのみ発生します。プロンプトキャッシュのメリットを最大限に活用するには、指示や例などの静的コンテンツをプロンプトの先頭に配置することをお勧めします。ユーザー固有の情報などの動的コンテンツは、プロンプトの末尾に配置してください。この原則は画像やツールにも適用され、キャッシングを有効にするためにはリクエスト間で同一である必要があります。 次の図は、キャッシュヒットの仕組みを説明しています。 A、B、C、D はプロンプトの異なる部分を表しています。 A、B、C がプロンプトプレフィックスとして指定されています。後続のリクエストに同じ A、B、C のプロンプトプレフィックスが含まれている場合、キャッシュヒットが発生します。 プロンプトキャッシュを使うべき場面 Amazon Bedrock のプロンプトキャッシュは、複数の API 呼び出しで頻繁に再利用される長いコンテキストプロンプトを扱うワークロードに適しています。この機能を使うと、レスポンスのレイテンシーを最大 85% 短縮し、推論コストを最大 90% 削減できるため、繰り返し使用される長い入力コンテキストを持つアプリケーションに特に適しています。プロンプトキャッシュがユースケースに有益かどうかを判断するには、キャッシュするトークン数、再利用の頻度、リクエスト間の時間を見積もる必要があります。 プロンプトキャッシュに適したユースケースを以下に示します： ドキュメントを使ったチャット – 最初のリクエストでドキュメントを入力コンテキストとしてキャッシュすることで、各ユーザークエリの処理が効率化されます。これにより、ベクトルデータベースのような複雑なソリューションを使わなくても、よりシンプルなアーキテクチャが実現できます。 コーディングアシスタント – プロンプトで長いコードファイルを再利用することで、ほぼリアルタイムのインラインコード提案が可能になります。これにより、コードファイルを何度も再処理する時間を大幅に削減できます。 エージェントワークフロー – より長いシステムプロンプトを使用してエージェントの動作を洗練させても、エンドユーザーの体験を損なうことがありません。システムプロンプトや複雑なツール定義をキャッシュすることで、エージェントフローの各ステップの処理時間を短縮できます。 Few-shot 学習 – カスタマーサービスや技術的なトラブルシューティングなど、多数の高品質な例と複雑な指示を含める場合、プロンプトキャッシュが役立ちます。 プロンプトキャッシュの使用方法 プロンプトキャッシュを使用する際は、プロンプトの構成要素を「繰り返し使用される静的な部分」と「動的な部分」の 2 つのグループに分類することが重要です。プロンプトテンプレートは、次の図に示す構造に従う必要があります。 1 つのリクエスト内に複数のキャッシュチェックポイントを作成できます。ただし、モデルごとに制限があります。次の図に示すように、静的な部分、キャッシュチェックポイント、動的な部分という同じ構造に従う必要があります。 ユースケース例 プロンプトにドキュメントを含める「ドキュメントを使ったチャット」のユースケースは、プロンプトキャッシュに非常に適しています。この例では、プロンプトの静的な部分はレスポンスフォーマットに関する指示とドキュメント本文で構成されています。動的な部分はユーザーのクエリであり、これはリクエストごとに変わります。 このシナリオでは、プロンプトの静的な部分をプロンプトプレフィックスとして指定し、プロンプトキャッシュを有効にします。以下のコードスニペットは、 Invoke Model API を使用してこのアプローチを実装する方法を示しています。次の図に示すように、リクエスト内に 2 つのキャッシュチェックポイントを作成しています。1 つは指示用、もう 1 つはドキュメント本文用です。 以下のプロンプトを使用します： def chat_with_document(document, user_query): instructions = ( "I will provide you with a document, followed by a question about its content. " "Your task is to analyze the document, extract relevant information, and provide " "a comprehensive answer to the question. Please follow these detailed instructions:" "\n\n1. Identifying Relevant Quotes:" "\n - Carefully read through the entire document." "\n - Identify sections of the text that are directly relevant to answering the question." "\n - Select quotes that provide key information, context, or support for the answer." "\n - Quotes should be concise and to the point, typically no more than 2-3 sentences each." "\n - Choose a diverse range of quotes if multiple aspects of the question need to be addressed." "\n - Aim to select between 2 to 5 quotes, depending on the complexity of the question." "\n\n2. Presenting the Quotes:" "\n - List the selected quotes under the heading 'Relevant quotes:'" "\n - Number each quote sequentially, starting from [1]." "\n - Present each quote exactly as it appears in the original text, enclosed in quotation marks." "\n - If no relevant quotes can be found, write 'No relevant quotes' instead." "\n - Example format:" "\n Relevant quotes:" "\n [1] \"This is the first relevant quote from the document.\"" "\n [2] \"This is the second relevant quote from the document.\"" "\n\n3. Formulating the Answer:" "\n - Begin your answer with the heading 'Answer:' on a new line after the quotes." "\n - Provide a clear, concise, and accurate answer to the question based on the information in the document." "\n - Ensure your answer is comprehensive and addresses all aspects of the question." "\n - Use information from the quotes to support your answer, but do not repeat them verbatim." "\n - Maintain a logical flow and structure in your response." "\n - Use clear and simple language, avoiding jargon unless it's necessary and explained." "\n\n4. Referencing Quotes in the Answer:" "\n - Do not explicitly mention or introduce quotes in your answer (e.g., avoid phrases like 'According to quote [1]')." "\n - Instead, add the bracketed number of the relevant quote at the end of each sentence or point that uses information from that quote." "\n - If a sentence or point is supported by multiple quotes, include all relevant quote numbers." "\n - Example: 'The company's revenue grew by 15% last year. [1] This growth was primarily driven by increased sales in the Asian market. [2][3]'" "\n\n5. Handling Uncertainty or Lack of Information:" "\n - If the document does not contain enough information to fully answer the question, clearly state this in your answer." "\n - Provide any partial information that is available, and explain what additional information would be needed to give a complete answer." "\n - If there are multiple possible interpretations of the question or the document's content, explain this and provide answers for each interpretation if possible." "\n\n6. Maintaining Objectivity:" "\n - Stick to the facts presented in the document. Do not include personal opinions or external information not found in the text." "\n - If the document presents biased or controversial information, note this objectively in your answer without endorsing or refuting the claims." "\n\n7. Formatting and Style:" "\n - Use clear paragraph breaks to separate different points or aspects of your answer." "\n - Employ bullet points or numbered lists if it helps to organize information more clearly." "\n - Ensure proper grammar, punctuation, and spelling throughout your response." "\n - Maintain a professional and neutral tone throughout your answer." "\n\n8. Length and Depth:" "\n - Provide an answer that is sufficiently detailed to address the question comprehensively." "\n - However, avoid unnecessary verbosity. Aim for clarity and conciseness." "\n - The length of your answer should be proportional to the complexity of the question and the amount of relevant information in the document." "\n\n9. Dealing with Complex or Multi-part Questions:" "\n - For questions with multiple parts, address each part separately and clearly." "\n - Use subheadings or numbered points to break down your answer if necessary." "\n - Ensure that you've addressed all aspects of the question in your response." "\n\n10. Concluding the Answer:" "\n - If appropriate, provide a brief conclusion that summarizes the key points of your answer." "\n - If the question asks for recommendations or future implications, include these based strictly on the information provided in the document." "\n\nRemember, your goal is to provide a clear, accurate, and well-supported answer based solely on the content of the given document. " "Adhere to these instructions carefully to ensure a high-quality response that effectively addresses the user's query." ) document_content = f"Here is the document: <document> {document} </document>" messages_API_body = { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 4096, "messages": [ { "role": "user", "content": [ { "type": "text", "text": instructions, "cache_control": { "type": "ephemeral" } }, { "type": "text", "text": document_content, "cache_control": { "type": "ephemeral" } }, { "type": "text", "text": user_query }, ] } ] } response = bedrock_runtime.invoke_model( body=json.dumps(messages_API_body), modelId="us.anthropic.claude-3-7-sonnet-20250219-v1:0", accept="application/json", contentType="application/json" ) response_body = json.loads(response.get("body").read()) print(json.dumps(response_body, indent=2)) response = requests.get("https://aws.amazon.com/blogs/aws/reduce-costs-and-latency-with-amazon-bedrock-intelligent-prompt-routing-and-prompt-caching-preview/") blog = response.text chat_with_document(blog, "What is the blog writing about?") 上記のコードスニペットに対するレスポンスには、キャッシュの読み取りと書き込みに関するメトリクスを示す usage セクションがあります。以下は、最初のモデル呼び出しからのレスポンスの例です： { "id": "msg_bdrk_01BwzJX6DBVVjUDeRqo3Z6GL", "type": "message", "role": "assistant", "model": "claude-3-7-sonnet-20250219”, "content": [ { "type": "text", "text": "Relevant quotes:\n[1] \"Today, Amazon Bedrock has introduced in preview two capabilities that help reduce costs and latency for generative AI applications\"\n\n[2] \"Amazon Bedrock Intelligent Prompt Routing \u2013 When invoking a model, you can now use a combination of foundation models (FMs) from the same model family to help optimize for quality and cost... Intelligent Prompt Routing can reduce costs by up to 30 percent without compromising on accuracy.\"\n\n[3] \"Amazon Bedrock now supports prompt caching \u2013 You can now cache frequently used context in prompts across multiple model invocations... Prompt caching in Amazon Bedrock can reduce costs by up to 90% and latency by up to 85% for supported models.\"\n\nAnswer:\nThe article announces two new preview features for Amazon Bedrock that aim to improve cost efficiency and reduce latency in generative AI applications [1]:\n\n1. Intelligent Prompt Routing: This feature automatically routes requests between different models within the same model family based on the complexity of the prompt, choosing more cost-effective models for simpler queries while maintaining quality. This can reduce costs by up to 30% [2].\n\n2. Prompt Caching: This capability allows frequent reuse of cached context across multiple model invocations, which is particularly useful for applications that repeatedly use the same context (like document Q&A systems). This feature can reduce costs by up to 90% and improve latency by up to 85% [3].\n\nThese features are designed to help developers build more efficient and cost-effective generative AI applications while maintaining performance and quality standards." } ], "stop_reason": "end_turn", "stop_sequence": null, "usage": { "input_tokens": 9, "cache_creation_input_tokens": 37209, "cache_read_input_tokens": 0, "output_tokens": 357 } } cache_creation_input_tokens の値が 37,209 であることから、キャッシュチェックポイントが正常に作成され、 37,209 トークンがキャッシュされたことがわかります。この状態を次の図に示します。 次回のリクエストでは、別の質問をすることができます： chat_with_document(blog, "what are the use cases?") プロンプトの動的な部分は変更されましたが、静的な部分とプロンプトプレフィックスは同じままです。このため、続くモデル呼び出しではキャッシュが活用されることが期待できます。以下のコードをご覧ください： { "id": "msg_bdrk_01HKoDMs4Bmm9mhzCdKoQ8bQ", "type": "message", "role": "assistant", "model": "claude-3-7-sonnet-20250219", "content": [ { "type": "text", "text": "Relevant quotes:\n[1] \"This is particularly useful for applications such as customer service assistants, where uncomplicated queries can be handled by smaller, faster, and more cost-effective models, and complex queries are routed to more capable models.\"\n\n[2] \"This is especially valuable for applications that repeatedly use the same context, such as document Q&A systems where users ask multiple questions about the same document or coding assistants that need to maintain context about code files.\"\n\n[3] \"During the preview, you can use the default prompt routers for Anthropic's Claude and Meta Llama model families.\"\n\nAnswer:\nThe document describes two main features with different use cases:\n\n1. Intelligent Prompt Routing:\n- Customer service applications where query complexity varies\n- Applications needing to balance between cost and performance\n- Systems that can benefit from using different models from the same family (Claude or Llama) based on query complexity [1][3]\n\n2. Prompt Caching:\n- Document Q&A systems where users ask multiple questions about the same document\n- Coding assistants that need to maintain context about code files\n- Applications that frequently reuse the same context in prompts [2]\n\nBoth features are designed to optimize costs and reduce latency while maintaining response quality. Prompt routing can reduce costs by up to 30% without compromising accuracy, while prompt caching can reduce costs by up to 90% and latency by up to 85% for supported models." } ], "stop_reason": "end_turn", "stop_sequence": null, "usage": { "input_tokens": 10, "cache_creation_input_tokens": 0, "cache_read_input_tokens": 37209, "output_tokens": 324 } } 37,209 トークンはキャッシュから読み込まれたドキュメントと指示内容に対応し、ユーザークエリ部分は 10 トークンとなっています。この状態を次の図に示します。 別のブログ記事にドキュメントを変更してみましょう。ただし、指示内容は同じままにします。今回のリクエストの構造は指示部分がドキュメント本文よりも前に配置されているため、指示部分のプロンプトプレフィックスについてはキャッシュヒットが期待できます。以下のコードをご覧ください： response = requests.get(https://aws.amazon.com/blogs/machine-learning/enhance-conversational-ai-with-advanced-routing-techniques-with-amazon-bedrock/) blog = response.text chat_with_document(blog, "What is the blog writing about?") { "id": "msg_bdrk_011S8zqMXzoGHABHnXX9qSjq", "type": "message", "role": "assistant", "model": "claude-3-7-sonnet-20250219", "content": [ { "type": "text", "text": "Let me analyze this document and provide a comprehensive answer about its main topic and purpose.\n\nRelevant quotes:\n[1] \"When you're designing a security strategy for your organization, firewalls provide the first line of defense against threats. Amazon Web Services (AWS) offers AWS Network Firewall, a stateful, managed network firewall that includes intrusion detection and prevention (IDP) for your Amazon Virtual Private Cloud (VPC).\"\n\n[2] \"This blog post walks you through logging configuration best practices, discusses three common architectural patterns for Network Firewall logging, and provides guidelines for optimizing the cost of your logging solution.\"\n\n[3] \"Determining the optimal logging approach for your organization should be approached on a case-by-case basis. It involves striking a balance between your security and compliance requirements and the costs associated with implementing solutions to meet those requirements.\"\n\nAnswer:\nThis document is a technical blog post that focuses on cost considerations and logging options for AWS Network Firewall. The article aims to help organizations make informed decisions about implementing and managing their firewall logging solutions on AWS. Specifically, it:\n\n1. Explains different logging configuration practices for AWS Network Firewall [1]\n2. Discusses three main architectural patterns for handling firewall logs:\n - Amazon S3-based solution\n - Amazon CloudWatch-based solution\n - Amazon Kinesis Data Firehose with OpenSearch solution\n3. Provides detailed cost analysis and comparisons of different logging approaches [3]\n4. Offers guidance on balancing security requirements with cost considerations\n\nThe primary purpose is to help AWS users understand and optimize their firewall logging strategies while managing associated costs effectively. The article serves as a practical guide for organizations looking to implement or improve their network security logging while maintaining cost efficiency [2]." } ], "stop_reason": "end_turn", "stop_sequence": null, "usage": { "input_tokens": 9, "cache_creation_input_tokens": 37888, "cache_read_input_tokens": 1038, "output_tokens": 385 } } レスポンスを確認すると、指示部分は 1,038 トークンをキャッシュから読み取っており、新しいドキュメント本文については 37,888 トークンをキャッシュに書き込んでいるのがわかります。この状態を、次の図に示します。 コスト削減効果 キャッシュヒットが発生すると、Amazon Bedrock はコンピューティングの節約分をキャッシュされたコンテキストのトークンごとの割引としてお客様に還元します。潜在的なコスト削減効果を計算するには、まず Amazon Bedrock のレスポンスにあるキャッシュ書き込み / 読み取りメトリクスを使用して、プロンプトキャッシュの使用パターンを把握する必要があります。その後、1,000 入力トークンあたりの価格 (キャッシュ書き込み) と 1,000 入力トークンあたりの価格 (キャッシュ読み取り) を使って潜在的なコスト削減効果を計算できます。詳しい価格情報については、 Amazon Bedrock の料金 をご覧ください。 レイテンシーベンチマーク プロンプトキャッシュは、繰り返し使用されるプロンプトの TTFT パフォーマンスを向上させるために最適化されています。この機能は、チャットプレイグラウンドのような複数回のやり取りを伴う会話型アプリケーションに非常に適しています。また、大きなドキュメントを繰り返し参照する必要があるユースケースにも役立ちます。 ただし、2,000 トークンにも及ぶ長大なシステムプロンプトの後に、頻繁に内容が変わる長いテキストが続くようなワークロードでは、プロンプトキャッシュの効果があまり発揮されない場合があります。このような状況では、キャッシュによるメリットが限定的になってしまいます。 プロンプトキャッシュの使用方法とベンチマーク方法については、 GitHub リポジトリ にノートブックを公開しています。ベンチマーク結果は、入力トークン数、キャッシュされたトークン数、出力トークン数など、ユースケースによって異なります。 Amazon Bedrock クロスリージョン推論 プロンプトキャッシュは、 クロスリージョン推論 (CRIS) と組み合わせて使用できます。クロスリージョン推論は、推論リクエストを処理するために地理的に最適な AWS リージョンを自動的に選択し、リソースとモデルの可用性を最大化します。需要が高い時期には、これらの最適化によりキャッシュ書き込みが増加する可能性があります。 メトリクスとオブザーバビリティ プロンプトキャッシュのオブザーバビリティは、Amazon Bedrock を使用するアプリケーションのコスト削減とレイテンシー改善に不可欠です。主要なパフォーマンスメトリクスをモニタリングすることで、開発者は長いプロンプトの TTFT を最大 85% 削減し、コストを最大 90% カットするといった大幅な効率改善を達成できます。これらのメトリクスは、開発者がキャッシュパフォーマンスを正確に評価し、キャッシュ管理に関する戦略的な決定を行うために重要です。 Amazon Bedrock でのモニタリング Amazon Bedrock は API レスポンスの usage セクションでキャッシュパフォーマンスデータを提供しています。これにより開発者は、キャッシュヒット率、トークン消費量（読み取りと書き込みの両方）、レイテンシー改善などの重要なメトリクスを追跡できます。これらの情報を活用することで、チームはキャッシング戦略を効果的に管理し、アプリケーションの応答性を高め、運用コストを削減できます。 Amazon CloudWatch でのモニタリング Amazon CloudWatch は AWS サービスの健全性とパフォーマンスをモニタリングするための強力なプラットフォームです。 Amazon Bedrock モデル専用の新しい自動ダッシュボードも含まれています。これらのダッシュボードは主要なメトリクスに素早くアクセスし、モデルのパフォーマンスをより深く理解できるようになっています。 カスタムオブザーバビリティダッシュボードを作成するには、以下の手順を実行します： CloudWatch コンソールで新しいダッシュボードを作成します。詳しい手順については、 Improve visibility into Amazon Bedrock usage and performance with Amazon CloudWatch を参照ください。 データソースタイプ欄の CloudWatch を選択し、初期のウィジェットのタイプとして 円 を選択します ( これは後で調整可能です ) 。 メトリクスの時間範囲 ( 1 時間、 3 時間、 1 日など ) をモニタリングニーズに合わせて更新します AWS 名前空間で Bedrock を選択します 検索ボックスに「 cache 」と入力してキャッシュ関連のメトリクスをフィルタリングします モデルについては、 anthropic.claude-3-7-sonnet-20250219-v1:0 を見つけ、 CacheWriteInputTokenCount と CacheReadInputTokenCount の両方を選択します 「ウィジェットの作成」を選択し、その後「保存」を選んでダッシュボードを保存します 以下は、このウィジェットを作成するためのサンプル JSON 設定です： { "view": "pie", "metrics": [ [ "AWS/Bedrock", "CacheReadInputTokenCount" ], [ ".", "CacheWriteInputTokenCount" ] ], "region": "us-west-2", "setPeriodToTimeRange": true } キャッシュヒット率の把握 キャッシュヒット率を分析するには、 CacheReadInputTokens と CacheWriteInputTokens の両方のメトリクスを確認する必要があります。一定期間にわたってこれらのメトリクスを集計することで、キャッシング戦略の効率についての洞察を得ることができます。 Amazon Bedrock 料金ページ に掲載されているモデル固有の 1,000 入力トークンあたりの価格（キャッシュ書き込み）と 1,000 入力トークンあたりの価格（キャッシュ読み取り）を使用すれば、特定のユースケースの潜在的なコスト削減を見積もることができます。 まとめ この記事では、 Amazon Bedrock のプロンプトキャッシュについて、その仕組み、使用べき場面、効果的な活用方法を紹介しました。あなたのユースケースがこの機能の恩恵を受けるかどうかを慎重に評価することが重要です。プロンプトの構造を工夫すること、静的コンテンツと動的コンテンツの違いを理解すること、そして特定のニーズに合った適切なキャッシング戦略を選択することが重要です。CloudWatch メトリクスを使用してキャッシュパフォーマンスをモニタリングし、この記事で説明した実装パターンに従うことで、高いパフォーマンスを維持しながら、より効率的でコスト効果の高い AI アプリケーションを構築できます。 Amazon Bedrock のプロンプトキャッシュの使い方の詳細については、 Prompt caching for faster model inference を参照ください。 著者について Sharon Li は、マサチューセッツ州ボストンを拠点とする Amazon Web Services (AWS) の AI/ML スペシャリストソリューションアーキテクトです。最先端技術の活用に情熱を持ち、 AWS クラウドプラットフォームで革新的な生成 AI ソリューションの開発と導入に取り組んでいます。 Shreyas Subramanian は、プリンシパルデータサイエンティストとして、生成 AI とディープラーニングを活用して AWS サービスを使用したビジネス課題の解決を支援しています。大規模最適化と機械学習のバックグラウンドを持ち、最適化タスクの加速に機械学習と強化学習を使用しています。 Satveer Khurpa は、 Amazon Web Services のシニア WW スペシャリストソリューションアーキテクトであり、 Amazon Bedrock セキュリティを専門としています。クラウドベースのアーキテクチャに関する専門知識を活かし、さまざまな業界のクライアント向けに革新的な生成 AI ソリューションを開発しています。生成 AI 技術とセキュリティ原則への深い理解により、堅牢なセキュリティ体制を維持しながら、新たなビジネス機会を開拓し、実質的な価値を推進するスケーラブルで安全かつ責任あるアプリケーションの設計を行っています。 Kosta Belz は、 AWS Generative AI Innovation Center のシニア応用科学者として、お客様が主要なビジネス課題を解決するための生成 AI ソリューションの設計と構築を支援しています。 Sean Eichenberger は、 AWS のシニアプロダクトマネージャーです。

2025/3/31 – 4/4に世界最大規模の製造業展示会ハノーバーメッセが開催されました。AWS は「Built for Industrial AI」をテーマに、ものづくりの全プロセスにおける AI の活用を訴求しました。AWS ブースには、AWS のフォーカスエリアである「Smart Manufacturing」「Smart Products」「Engineering &amp; Design」「Supply Chain」「Sustainability」の５つのエリアに 13 の AWS キオスクと、39 のパートナーキオスクの計 52 のキオスクが設置されました。日本からも多くのお客様に来場頂き、私たち AWS Japan の製造業担当スペシャリスト、営業、ソリューションアーキテクトがブースツアーという形で AWS のブースをご紹介しました。 このブログでは AWS ブースの概要と展示ソリューションについてご紹介します。 AWSブース全体像 写真1：AWS ブース全景 こちらが AWS ブースの全景です。AWS 製造業向けにフォーカスエリアである「Smart Manufacturing」「Smart Products」「Engineering &amp; Design」「Supply Chain」「Sustainability」と生成 AI を活用したユースケースの実装例が入口近くに展示されていました。 昨年のハノーバーメッセでの AWS ブース からの変化点として大きく３つ挙げておきます。 ビジネスに貢献する生成 AI の実装 昨年までの生成 AI のコンセプト紹介やシンプルなチャットの展示からフェーズが進み、業務のユースケースにおける具体的な課題および「人手不足」「匠の技の伝承」などの業界課題を解決する手段として生成 AI の活用が進み、実装が進んでいます。AI エージェント形式での実装も進み、高度なタスクをこなせるようになってきています。 すぐに使える Vertical SaaS の増加 不確実で変化の早い市況に対応するためには新しい取り組みの PoC を早期に完了して業務活用に進める必要があります。産業機器接続、OT Security、データ基盤など製造業に特化した パートナー企業が提供する SaaS の増加によりすぐに価値検証や本番導入を進められる状況が整ってきています。 DataOps の加速 2 の SaaS の増加とも関連しますが、とりわけ Smart Factory は机上のコンセプトから実用フェーズに移り、単に機器からデータを吸い上げるだけではなく持続的な運用に必要なツールが増加しました。具体的にはデータの加工、統合、データモデリング、エッジ側での異常検知など高度な機能を持つソリューション（ HighByte 、 LITMUS 等）が増加しています。企業全体のデータ活用（Digital Thread）の実現も、生成 AI の登場により技術的な障壁は下がり始めています。 それでは、ここからは各ブースの注目展示についてご紹介していきます。 Smart Manufacturing 写真2：昨年に引き続き展示された e-Bike Smart Factory デモ 昨年のハノーバーメッセでは中央に鎮座していた e-Bike Smart Factory デモが今年も展示されていました。様々なベンダーの製品を組合せたリアルな工場ラインだけでなくエンジニアリングチェーンからサプライチェーンまで一気通貫で AWS 上で動かすというショーケース的なデモになっています。一方で今年は少し端の方に寄せられており、その代わりに中央に配置されていたのは、地元ドイツの企業である SYNAOS によるマルチベンダーの AMR/AGV コントローラーによるデモです。 写真3：SYNAOS によるマルチベンダーのAMR制御デモ KUKA と SHERPA のメーカーの異なる AMR を協調制御していました。既に VW 社において 40 メーカー 160 台を超える AGV / AMR / フォークリフトを制御していると紹介されていました。現在 45 メーカーに対応しており、日本のメーカーではオムロンに対応しているとのことで、テスト環境では最大 600 台まで制御可能とのことです。 写真4：AWS Industrial Data Fabric ブースと説明員の Scott 氏 DataOps に関連して数年前から AWS が提唱している Industrial Data Fabric ( 産業データファブリック ) に関しても様々なパートナーの参画によってパートナーソリューションを組み合わせたデモが行われていました。また、ハノーバーメッセ開催期間中には日立製作所様が 国内初の IDF パートナーとして登録 されました。産業データファブリックについては今年の 6 月に開催する AWS Summit Japan 2025 でも展示が行われますのでご期待下さい。 写真5：Process Manufacturing on AWS ブースと説明員の Mickael 氏と Miguel 氏 もう一つ、プロセス製造業における技術伝承や人材不足といった課題に対して、日々の口頭によるやり取りをノウハウとして蓄積し AI アシスタントとして業務に活用するデモを行いました。実はこちらは日本のソリューションアーキテクトが昨年の AWS Summit で作成して大好評だったデモ をベースに多言語化させたものになります。 Smart Products 写真6：Smart Products &amp; Service on AWS ブースと説明員の山本氏と新澤氏 Smart Products のブースでは製品の開発と運用の観点で２つの展示を行い、ソフトウェアの遠隔更新や、Amazon Q Developer, GitLab Duo といった生成 AI の活用により組み込みソフトウェア開発を加速する日本発のデモと、IoT の機能を組み込んだスマートプロダクトから得られた情報からアフターサービスをシームレスに行うデモを展示しました。このデモでは生成 AI エージェントを活用し、来場者の関心も高く、生成 AI の使い方が具体的でイメージが出来たと好評でした。 写真7：デバイスウォール 工場設備だけでなくスマートプロダクトを AWS に安全かつ簡単に繋ぐ方法として AWS IoT Greengrass 、 AWS IoT ExpressLink 、 FreeRTOS があります。これらに対応した認定デバイスがデバイスウォールとして展示されていました。開催場所がヨーロッパということもあり、日本ではあまり見かけることの少ないメーカーも多くありました。またデバイスウォールの左上にあるデバイスは既存の通信機能がない製品に組み込んで使って頂くようなデバイスとなっており、こんなものまで出しているんだと驚きの声が聞かれました。パートナーデバイスに興味のある方は是非 こちら からご覧ください。 Engineering &amp; Design 写真8：Engineering &amp; Design on AWS ブースと説明員の Patrice 氏 Engineering &amp; Design のブースで注目を浴びていたのは、生成 AI を活用し 2D の写真から 3D のモデルを生成してシミュレーションまで行うというデモです。 こちら はワークショップの形で公開されています。ご興味がある方は一度トライしてみては如何でしょうか？またシミュレーションの分野では今までインプット条件に対して大量のコンピューターリソースと時間を掛けてアウトプットとなるシミュレーション結果を生成していたものを、サロゲートモデルと呼ばれる機械学習を用いてシミュレーション結果を予測することで、従来のシミュレーションに比べて時間とコンピュータリソースの削減を行うデモも行っていました。大量のシミュレーション条件を微調整して頻繁に行うことが多いユースケースにおいては有効な手段となる可能性があります。日本のお客様でも取組みを始めていらしゃるようですが、まだまだ知られていないこれからの技術だと思います。 Supply Chain 写真9：AWS Supply Chain のブースと説明員の Pawel 氏 Supply Chain のブースは昨年に引き続き AWS Supply Chain を中心に e-Bike Smart Factory と連携した展示を行っていました。AWS Supply Chain は、AWS では珍しいビジネスアプリケーションとして提供されており、既存のシステムの外付けで在庫の可視化や分析及び最適化を行うことができるサービスとなっています。昨年との大きな違いとしては、 昨年末に reInvent で発表された BMW との協業 による Catena-X への対応です。2025 年中の正式リリースに向けて、今回は画面イメージを説明していました。 Build for Industrial AI 写真10：毎日盛況だった Build for Industrial AI のコーナー AWS ブースの入り口にあった 4 つのユースケースを想定した生成 AI の実装例が展示されていたコーナーには常に人だかりが出来ていました。 昨年末にリリース された AWS IoT SiteWise Assistant による設備から取得されたデータの内容を生成 AI が人が理解しやすく自然言語でサマリーしてくれるデモ。生成 AI アシスタントである Amazon Q Business を使った製造現場のドキュメントを使ったデモ。クラウド上でファインチューニングされた生成 AI モデルをエッジデバイスで動かし製造現場での利用を想定したアシスタントのデモ。などの展示を行いましたが、このブログでは最もお客様からの反響が大きかった生成 AI を使った外観検査のデモについてご紹介します。 写真11：Amazon Nova を使った外観検査のデモ これまでの機械学習モデルによる外観検査では、良品 / 不良品の画像を事前学習し、その物体専用の機械学習モデルを作成する必要がありました。最新の生成 AI のモデルでは、マルチモーダルと呼ばれるテキストだけでなくインプットされた画像を理解出来るようになってきているのはご存じの方も多いと思います。マルチモーダルに対応した Amazon Nova を使って事前学習無しで、様々な物体の外観検査をプロンプト（生成 AI への指示文章）だけで行うというデモです。検出精度やスピードに驚かれているお客様が多かったです。実際の現場でさっそく試してみたいという声も聞かれました。 まとめ このブログでは 2025 年のハノーバーメッセにおける AWS ブースの概要と注目の展示をポイントを絞ってお届けしました。熱気に満ちた 5 日間のハノーバーメッセの雰囲気が少しでも伝わったでしょうか？今回のブログは速報という形でお届けしましたので、パートナーブース含めて、まだまだお伝えしきれないことが沢山あります。そちらについては、4 月 24 日にハノーバーメッセに関する無料ウェビナーを開催致しますので、ぜひそちらも合わせてご覧ください（お申込みは こちら ）。我々日本のスタッフは、日本の製造業の皆さんの発展をサポートさせて頂きます。気になった内容があれば、担当営業もしくは、 こちら までお問い合わせ下さい。 来年のハノーバーメッセ（2026/4/20 – 4/24）では、日本の製造業の事例などが展示できることを期待しています。また今年の AWS Summit Japan（2025/6/25 – 6/26） でも製造業の皆さんに向けた展示や事例セッションなどが多数企画されています。こちらも是非早めの エントリー をお願いします。皆様にお会いできるのを楽しみにしています。 このブログは製造業担当のソリューションアーキテクト水野貴博が担当しました。 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。 <!-- '"` -->

AWS の生成 AI ワークロードのコスト最適化に関するシリーズの第 2 回目のブログへようこそ。 最初のブログ では、生成 AI を適用するためのさまざまな実装アプローチとクラウド財務管理の原則に関する概要を説明しました。今回は、Amazon Elastic Compute Cloud ( Amazon EC2 ) と Amazon SageMaker AI を使用し、カスタム AI モデルの構築とデプロイに関するコスト最適化戦略について詳しく説明します。大規模な言語モデルをトレーニングする場合、既存のモデルをファインチューニングする場合や推論エンドポイントをデプロイする場合いずれにも関連する、Amazon EC2 のインスタンスタイプの選定、キャパシティ管理やコミットメントプランニングなどの主要なコスト要因を説明します。また、Amazon SageMaker AI のモデル最適化、トレーニング効率やデプロイ戦略についても説明します。これらのプラクティスは、独自の AI インフラストラクチャーの管理に伴う柔軟性と制御を維持しながら、パフォーマンス要件とコスト効率のバランスを取るのに役立ちます。 Amazon EC2 と SageMaker AI は、生成 AI の基盤となる AWS サービスのうちの 2 つです。Amazon EC2 はトレーニングと推論に必要なスケーラブルなコンピューティングを提供し、SageMaker AI はモデル開発、デプロイや最適化のための組み込みツールを提供します。生成 AI ワークロードには高性能アクセラレーター (GPU、 Trainium や Inferentia ) と膨大な処理が必要であり、効率的なリソース管理がないとコストが高くなる可能性があるため、コスト最適化は非常に重要です。以下のコスト最適化戦略を活用することで、パフォーマンスとスケーラビリティを維持しながらコストを削減できます。 画像 1「Amazon EC2 と SageMaker AI のコスト最適化戦略:コスト削減 vs 労力」このグラフは説明のみを目的としています。実際に必要な労力と達成されるコスト削減は、実装規模、インフラストラクチャー、およびチームの専門知識に基づいて変わる場合があります。 Amazon EC2 1. 最適なインスタンスタイプの選択 Amazon EC2 インスタンスは自分でデプロイを管理する主要コンポーネントであり、適切なインスタンスタイプを選択することが重要です。 AWS Graviton 搭載のような CPU ベースのインスタンスタイプでは、 AWS Compute Optimizer を使用してインスタンスを簡単に分析し、適切なサイズを設定できます。生成 AI ソリューションには通常、NVIDIA GPU または Tranium や Inferentia などの AWS AI チップを搭載した高速インスタンスが必要です。AWS Trainium および Inferentia ベースのインスタンスは、トレーニングと推論のコストパフォーマンスが最大 30 – 50% 向上し、ワークロードにおいて費用対効果の高いオプションとなります。GPU ベースのインスタンスを適切なサイズにするには、 CloudWatch エージェントを使用した NVIDIA GPU の利用率の有効化 を参照してください。これにより、AWS Compute Optimizer は NVIDIA GPU の使用率を収集し、適切なサイズの推奨事項を提示できます。 データセット、ワークロードやモデルに対するインスタンスのパフォーマンスをより包括的に分析するには、コンテキストテストを使用する必要があります。 FM Bench などのツールは、さまざまなインスタンスタイプとサービングスタックのパフォーマンスを分析することで、このテストを合理化するのに役立ちます。推論レイテンシー、1 分あたりのトランザクション数、エラー率やトランザクションあたりのコストを示すマークダウンレポートを通じて、最も費用対効果の高い構成を特定するのに役立ちます。レポートには、説明文、表や図が含まれており、インスタンスを適切なサイズに設定し、必要な分だけを支払っていることを確認するのに必要な情報が記載されています。 2. スマートキャパシティ管理 使用するインスタンスタイプを理解したら、次のステップはキャパシティ管理戦略を理解することです。考えるべきよくある質問は次のとおりです。 インスタンスはいくつ必要ですか? どれくらいの頻度で実行する必要がありますか？ どれくらいの期間必要ですか？ オンデマンドキャパシティ予約 (ODCR) ODCR では、特定のアベイラビリティーゾーン (AZ) にある Amazon EC2 インスタンスのコンピューティングキャパシティを予約できます。機械学習 (ML) モデルのトレーニングとファインチューニングのために ODCR を使用することで、予約した高速インスタンス (GPU、Trainium や Inferentia) に中断されることなくアクセスできます。キャパシティ要件が厳しい場合や、ソリューションでキャパシティの確保が必要な場合は、ODCR の使用を検討してください。 ODCR は長期コミットメントを必要とせず、いつでも変更またはキャンセルできます。キャパシティー予約は、予約されているキャパシティーでインスタンスを実行するかどうかにかかわらず、同等のオンデマンド料金が請求されます。アカウントに ODCR がプロビジョニングされるとすぐに請求が開始され、キャパシティ予約がアカウントにプロビジョニングされている間も請求は継続されます。 ODCR を効率的に使用するには、使用率を監視することが重要です。これを実現する方法の 1 つは、Amazon CloudWatch を利用することです。CloudWatch では、「AvailableInstanceCount」などのメトリクスを監視するアラームを設定できます。このメトリクスは、ODCR 内の未使用のインスタンスの数を判断するのに役立ちます。ODCR を監視するもう 1 つの方法は、 AWS Cost Explorer または Cost and Usage Reports (CUR) を利用することです。これらのツールを使用すると、「UnusedBox」または「UnusedDed」を含む使用タイプをフィルタリングできます。これにより、キャパシティ予約したが使用されていないインスタンスの数が表示されます。さらに、アカウントの ODCR のキャパシティ使用率が 20% を下回ると、 AWS Health Dashboard から E メールが送信されます。 インスタンススケジューリング ワークロードを年中無休で実行する必要がない場合は、AWS Instance Scheduler の使用を検討する必要があります。 AWS Instance Scheduler は、Amazon Elastic Compute Cloud (EC2) と Amazon Relational Database Service (RDS) インスタンスの起動と停止を自動化するように設計されたソリューションです。この自動化は、必要なときにのみリソースを実行できるようにすることで、オペレーションコストの削減に役立ちます。Instance Scheduler は複数の AWS アカウントで動作するように設定できるため、大規模な組織での有用性が高まります。スケジューラーは AWS CloudFormation テンプレートを用いてインストールされ、スケジュール、サービス (Amazon EC2 または Amazon RDS) やタイムゾーン設定などのさまざまなパラメータをカスタマイズできます。この柔軟性により、スケジューラーを特定のニーズに合わせて調整できるため、効率的なリソース管理とコストの最適化が可能になります。 キャパシティ確保の目的でインスタンスをシャットダウンまたはリリースできない場合は、ODCR と共に Instance Scheduler を使用することを検討してください。そうすれば、予備のキャパシティを他のアカウント、チーム、またはワークロードに一時的にシフトできます。この方法ではコスト削減にはならないかもしれませんが、利用しているインスタンスからより多くの価値を引き出すことができます。 3. 戦略的コミットメント計画 AWS コミットメント戦略を策定する際には、ワークロードの存続期間 (1 年または 3 年)、インスタンスファミリーの要件やリージョンの柔軟性といった要素が節約効果を最大化するのに役立ちます。 Savings Plans Purchase Analyzer は、過去の利用パターンを調べるのに役立ち、これらの要因に基づいて最適なコミットメントを推奨してくれます。特定のリージョンで特定のインスタンスファミリーを必要とする場合には、 EC2 Instance Savings Plans (EC2SPs) が最も大きな割引を提供します。また、Compute Savings Plans (CSPs) では、割引率が下がりますが、インスタンスの世代やリージョンを問わない高い柔軟性を提供します。CSPs を使用すると、コミットされた割引特典を失うことなく、リージョン間でワークロードを移動したり、新しいインスタンスファミリーにアップグレードしたりできます。どちらを選択するかにもよりますが、オンデマンド料金と比較して最大 72% 節約できます。そのため、Savings Plans は AWS インフラストラクチャーにとってインパクトのあるコスト最適化プランとなっています。 4. リソース効率の最大化 アクセラレーター (GPU、Trainium や Inferentia) の使用率を追跡することで、リソースがどの程度効率的に利用されているかをより理解できます。GPU 使用率メトリクスは、インスタンス要件の検証、効率の最大化、またチームやプロジェクト間でのリソース共有の機会特定に役立ちます。CPU 使用率の監視は比較的簡単ですが、GPU 監視には独特の課題があります。前述したように、最適なインスタンスタイプを選択する際、GPU 使用率としてより詳細なメトリクスが必要になります。GPU の使用率を推定するために使用できる指標は、温度と消費電力の 2 つです。これらのメトリクスは CloudWatch エージェント から取得でき、このアプローチにより GPU 飽和度を推定できるため、リソースの使用パターンに関する重要な洞察が得られます。この見積もりにより、既存のインフラストラクチャーからより大きな効用を得ることができ、総所有コスト (TCO)の削減につながります。 （画像内訳：生成 AI の効率性を評価する上で最も難しい側面の 1 つは、リソースがどれだけうまく利用されているかを理解することです。特に GPU に関しては、従来のパフォーマンス指標だけでは必ずしもすべてを把握できるとは限りません。消費電力や熱出力などの要素を評価することで、スループットやレイテンシだけでなく、実際の効率をより深く把握できます。生成 AI ワークロードの最適化は、リソースをどれだけ長く使用しているかだけでなく、リソースの機能を最大限に活用しているかどうかも重要です。 Brent Segner, Distinguished Engineer, Capital One） Amazon SageMaker AI AI/ML の取り組みを加速させていると、戦略的な決定を迫られることになります。機械学習インフラストラクチャーの構築とメンテナンスにリソースを投資すべきか、それともビジネス成果の推進に向けて努力を振り向けるべきか、というものです。 Amazon SageMaker AI はこのジレンマに対する理想的なソリューションであり、必要な柔軟性を維持しながら、差別化されていない重い作業を排除するフルマネージドサービスを提供します。 SageMaker JumpStart は、構築済みのソリューション、すぐに導入できるモデルやサンプルノートブックを提供することで、すぐに使い始めるのに役立ちます。SageMaker AI への取り組みを始めたばかりでも、既存の実装の最適化を検討している場合でも、これらの戦略は、より効率的で費用対効果の高い AI および 機械学習ソリューションの構築に役立ちます。 1. 成功のためのライトサイジング SageMaker AI インスタンスのタイプとサイズを最適化すると、ソリューションのパフォーマンスとコスト効率の両方に効果がある場合があります。使用パターンを注意深く分析し、SageMaker AI インスタンスを戦略的に適切なサイズにすることで、機械学習インフラストラクチャーのコストを削減できます。ワークロードに適したインスタンスタイプとサイズを選択するには、テストが重要です。前述した FM Bench は、このプロセスを簡単にするための貴重なツールです。 2. モデルのキャパシティとコストバランス 機械学習ワークロードに適したモデルを選択することは、効果的な SageMaker AI プロジェクトを構築する上で最も重要な決定の 1 つです。慎重にモデル選択をすることで、パフォーマンスとコスト効率の両方を最大 45% 向上させることができます。次の 3 つの重要な要素を評価する体系的なアプローチをお勧めします。1) 特定のユースケース要件、2) 利用可能な計算リソース、3) 予算。たとえば、大規模言語モデル (LLM) は優れた機能を備えていますが、 単純なモデルで事足りる簡単なタスクでは必ずしも最も費用対効果の高いソリューションであるとは限りません。SageMaker Jumpstart のモデルから始めることで、最適な結果を得ることができます。SageMaker Jumpstart は、基盤モデル、組み込みアルゴリズムやビルド済みの機械学習ソリューションを備えたハブです。その後、より高度な (そして多くの場合より高価な) モデルによって得られるメリットが、追加の計算コストと財務コストを正当化するかどうかを評価できます。このような反復的なモデル選択アプローチは、多くの場合、技術的に優れ、より持続可能なソリューションにつながります。 3. SageMaker AI Savings Plans の活用 機械学習ソリューションを大規模に運用するには、運用の柔軟性を維持しながらコストを最適化することが重要です。 Machine Learning Savings Plans (MLSPs) は、従量制の価格設定モデルよりも、SageMaker AI の料金を最大 64% 節約できるコミットメントです。これらのプランでは、1 年または 3 年の期間にわたって一定量の使用量（1 時間あたりの金額で算出）のコミットメントが必要です。MLSPs を特に強力にしているのは、その柔軟性です。割引は、SageMaker Studio ノートブック、SageMaker オンデマンドノートブック、SageMaker Processing、SageMaker Data Wrangler、SageMaker トレーニング、SageMaker リアルタイム推論や SageMaker バッチ変換の対象となる SageMaker ML インスタンスの使用に自動的に適用されます。つまり、コミットメントによる削減効果を失うことを心配することなく、機械学習インフラストラクチャーを自由に革新して調整できるということです。MLSPs は、特に継続的な機械学習の運用において、手間をかけずに大幅なコスト最適化を実現できます。コスト効率を維持しながら機械学習の取り組みを拡大したいと考えている場合、MLSPs はシンプルかつ効果的であるため欠かせません。 4. スポットインスタンスによるトレーニングのコスト最適化 Amazon SageMaker AI のマネージドスポットトレーニング は、機械学習ワークロードのコスト最適化戦略を提供します。スポットインスタンス価格を活用することで、オンデマンドインスタンスと比較してトレーニングコストを最大 90% 削減できるため、予算が限られているプロジェクトにとって価値のあるオプションとなります。この費用対効果の高いアプローチは、時折中断しても許容できる、時間にセンシティブではないトレーニング作業に特に適しています。AWS Graviton プロセッサと組み合わせると、コストパフォーマンスの面でさらに大きなメリットが得られます。このプロセスを使いやすくするために、SageMaker AI ではスポットインスタンスのライフサイクルを自動的に管理できます。これは、インスタンスが再利用された場合でもトレーニングの進行状況が維持されるように、 チェックポイントを使用して、モデルの状態を保存する ことで実現されます。そのため、開発やテストの環境、およびトレーニング時間に柔軟性があるその他の環境に最適なソリューションになります。 5. 適切な推論戦略の選択 Amazon SageMaker AI は、様々なユースケースとコスト構造に合わせて設計された推論デプロイのオプションをいくつか提供しています。詳細については、 推論コスト最適化のベストプラクティス を参照してください。リアルタイム推論ではレイテンシーは低くなりますが、インスタンスが常時実行されるため、継続的なコストが発生します。リアルタイム推論は、即時対応が必要なアプリケーションに最適です。断続的なワークロードのコストを削減するために導入された Amazon SageMaker Serverless Inference は、使用していないときは自動的に エンドポイントをゼロまでスケールダウンさせ、呼び出し中に使用されたコンピューティング時間に対してのみ課金されます。バッチ処理の場合、 SageMaker AI バッチ変換 は、永続的なエンドポイントを維持せずに大規模なデータセットを一括処理することにより、最も費用対効果の高いソリューションを提供します。最後に、 非同期推論 は、リクエストを非同期で処理するため、ペイロードが大きく、処理時間が長く、またリアルタイムに近いレイテンシーが必要な場合に最適です。アイドル時にインスタンスを自動的に停止することでコストを削減できるため、リクエストが処理されているときにのみ支払いが発生します。 これらの最適化戦略を実装することで、高いパフォーマンスとスケーラビリティを維持しながら、インフラストラクチャーのコストを大幅に削減できます。成功の鍵は、これらの選択肢を特定のユースケースやビジネス要件に合わせて調整し、コストを削減するだけでなく、機械学習運用の長期的な成功に向けて最適化することです。 結論： この投稿では、Amazon EC2 と SageMaker AI を使用してカスタム AI モデルを開発するためのコスト最適化戦略について説明しました。次回のブログでは、スマートモデル選択、ナレッジベースの最適化やキャッシュ戦略など Amazon Bedrock のコスト最適化手法について詳しく説明します。コストを抑えながら基盤モデルの価値を最大化する方法について、次回のブログをお楽しみに。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトです。この役職では、Adam は AI コスト最適化と FinOps プラクティスを専門としています。Amazon Q Business や Amazon Q Developer などの顧客向け機能に貢献したほか、AWS re:Invent やその他の業界プラットフォームでの講演を通じてオピニオンリーダーとしての役割を果たしてきました。 Bowen Wang Bowen は AWS 請求およびコスト管理サービスの主任プロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウドファイナンス管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。以前のキャリアでは、テック系スタートアップの中国市場への参入を支援しました。