こんにちは、データサイエンティストの髙橋です。業務では企画/分析/機械学習モデル作成/プロダクション向けの実装/効果検証を一貫して行っています。 この記事では、BUYMA アプリのホーム画面に検索クエリレコメンドを導入し、ホームレコメンド経由の CVR の向上、アプリ全体の商品閲覧ユーザー率（商品詳細を閲覧したユーザー/全体ユーザー）の改善をした事例を紹介します。 レコメンドシステム全体としては、機械学習ロジックとバックエンド実装の両方がありますが、今回は前者の機械学習ロジックを中心に紹介します。バックエンド実装は別途紹介予定です。 施策の目的 新しいレコメンドイメージ 新しいレコメンドによる事業効果 レコメンドロジック 商品と検索クエリの類似度計算 ユーザーごとの検索クエリレコメンド作成 検索クエリ内の商品並び替え レコメンドの並び順に対するランダム性の導入 定性評価 AB テスト まとめ 施策の目的 弊社が運営している CtoC EC サービス BUYMA の iOS アプリのホーム画面には「あなたへのおすすめ」セクションがあり、ユーザーが閲覧した商品に基づいてレコメンドされた商品が表示されています。 しかし、個別商品のレコメンドのみを提供しているため、ユーザーに表示できる商品の幅が制限され、購入に結び付く商品にホームから出会いづらいのではという仮説がありました。そこで、個別商品のみではなく、検索クエリのレコメンドを実施することで、ユーザーに表示できる商品の幅を広げ、購入候補となる商品に出会いやすくできないかを検証しました。検索クエリのレコメンドでは、商品単体ではなく検索結果への導線を提示できるため、ユーザーがより広い候補の中から商品を探せるようになります。 最終目標は、 iOS アプリ全体の売上を上げることですが、アプリ全体の購入にホームレコメンドが占める割合はそれほど大きくなく、はじめからそれを実現するのは難しいと考え、まずはホームレコメンド経由の売上を増加させることを目標としました。 新しいレコメンドイメージ 既存の iOS アプリのホーム画面のレコメンドは個別商品を以下のように表示していました。 新しいレコメンドとして、以下のような検索クエリのレコメンドを既存の個別商品レコメンドの上部に追加しました。ここで、検索クエリごとに商品を何件か見せるようにしました。また、検索クエリごとに検索結果に遷移できるボタンを設けることで、ユーザーが検索結果に遷移してより広い商品を見ることができるようにしました。検索結果への導線は、検索ラベル名の横とカルーセル末尾の2箇所に設けました。 検索クエリとしては、商品カテゴリとブランドの組み合わせや、商品カテゴリとタグの組み合わせなどを用意しました。例えば「スニーカー × ブランド A」「Tシャツ × ストリート」など、商品カテゴリにブランドやタグを組み合わせた検索クエリ候補を作成しました。 新しいレコメンドによる事業効果 AB テストの結果、ホームレコメンド経由の CVR の上昇が見られました。ホームレコメンドからユーザーが閲覧できる商品の幅を広げ、購入候補となる商品に出会いやすくできたことが CVR 上昇に寄与したと考えられます。 また、iOS アプリ全体の商品閲覧ユーザー率にも上昇が見られました。検索クエリごとに複数の商品を表示し検索結果への導線を設けたことで、ホーム画面からの商品探索を促せたことが閲覧ユーザー率上昇に寄与した可能性があります。 詳細な数値などは後述のABテストセクションにて紹介します。 レコメンドロジック 実際に利用した検索クエリレコメンドのロジックについて紹介します。今回の検索クエリレコメンドでは、大きく以下の4つの処理を行いました。 商品と検索クエリの類似度計算 ユーザーの商品閲覧履歴から、関連性の高い検索クエリレコメンドを作成する 各検索クエリ内で表示する商品を、ユーザーの興味に近い順に並び替える 表示内容が固定化されないように、Gumbel-Top-k Trick によって一定のランダム性を加える 以降では、それぞれの処理について説明します。 商品と検索クエリの類似度計算 検索クエリのレコメンド自体に効果があるのかをクイックに検証するために、協調フィルタリングベースの実装負荷が低いロジックを採用しました。 通常の item-to-item 協調フィルタリングでは、ユーザーごとの閲覧有無をベクトルとみなし、商品同士の類似度をコサイン類似度で計算します。商品 の閲覧ベクトルを とすると、コサイン類似度は以下の式で表されます。 ここで、各次元をユーザー、値をそのユーザーが商品を閲覧したかどうかの の値とすると、 は両方の商品を閲覧したユーザー数、 と はそれぞれの商品を閲覧したユーザー数の平方根になります。 今回の検索クエリレコメンドでは、ユーザーの代わりにセッション を単位とし、商品と検索クエリの類似度を計算しました。具体的には、商品 の閲覧ベクトルを 、検索クエリ （例：商品カテゴリとブランドの組み合わせ）に該当する商品の閲覧ベクトルを とし、それぞれの次元をセッション、値をそのセッションで閲覧されたかどうかの の値とします。このとき、商品 と検索クエリ の類似度を と定義し、事前計算しました。これにより「ある商品を見たセッションでは、他にどのような検索クエリに該当する商品が見られているか」を集計しています。たとえば、あるスニーカーを閲覧したセッションで「ブランド A のスニーカー」に該当する商品もよく閲覧されていれば、 は高い値になり、その商品からそのクエリへの関連度が高いとみなします。 ユーザーごとの検索クエリレコメンド作成 これにより計算した商品×検索クエリの類似度 を元に、ユーザーごとの検索クエリレコメンドを作成しました。具体的には、ユーザー に対する検索クエリ の集約スコア を以下の式で計算し、その集約スコア上位の検索クエリをユーザーごとにレコメンドしました。 ここで、 はユーザー が直近 番目に閲覧した商品のID（ が最新の閲覧商品）を表します。 は、直近 件の閲覧商品それぞれについて、その商品と検索クエリ の類似度 （先ほどのコサイン類似度の式により事前計算済み）を、閲覧順に応じた指数減衰の重み で重み付けして合算したものです。同じ検索クエリが複数の商品から推薦された場合は加算され、直近の閲覧ほどユーザーの現在の興味を強く反映します。 は減衰率を表します。 今回は検索クエリのレコメンド自体に効果があるかをクイックに検証する目的だったため、 ・ は後述する定性評価アプリでの結果を見ながら調整しました。オフライン評価指標を設計して最適化するのが本来望ましいですが、まず施策の有効性を確認するフェーズとして定性評価による調整で十分と判断しました。 また、コールドスタート問題、具体的にはマイナーな商品が閲覧履歴に含まれる場合の対処として、レコメンド上位数件はルールベースで直近閲覧商品のブランド × カテゴリを出力するようにしました。マイナー商品は共閲覧セッション数が少なくスコアの信頼性が低くなるため、こうしたケースでも関連性が高いクエリを最上位に表示できるよう意図しています。先ほど述べたようにクイックに検証する目的上、ここへの深い投資は優先度を下げた判断です。 検索クエリ内の商品並び替え 新しいレコメンドイメージで説明したように、検索クエリごとに商品を何件か見せるようにしました。 ここで、単純に検索クエリで検索したときの人気商品を見せると、ユーザーが閲覧した商品との関連性が低い商品が表示され興味を惹きづらい問題がありました。そこで、 item-to-item 協調フィルタリングも作成し、その結果を元に各検索クエリ内の商品を並び替えるようにしました。 例えば、ユーザーがブランド A のピンクのバッグを閲覧していた場合を考えます。以下のように並び替え前は人気順上位の黒・白のバッグが表示されていました。これを item-to-item 協調フィルタリングの結果をもとに並び替えることで、ピンク系のバッグが表示されるようにしました。 並び替えには Solr のブーストクエリの仕組みを利用しました。具体的には、検索クエリに該当する商品の中で、ユーザーの直近閲覧商品との item-to-item 協調フィルタリング結果上位の商品にブーストをかけることで、ユーザーの興味に近い商品を上位に表示しました。Solr のブーストクエリの採用理由としては、検索エンジンとして Solr を利用しており、それに付随する機能を利用した方が開発工数を抑えつつ検索クエリ内の商品並び替えができると考えたためです。 レコメンドの並び順に対するランダム性の導入 ユーザーごとの検索クエリの集約スコアで検索クエリを並べて表示すると、アプリ訪問のたびに同じような検索クエリが表示される問題がありました。そこで、検索クエリの並び順に対するランダム性を導入し、アプリ訪問のたびに検索クエリの並び順が変化するようにし、より回遊を促せるようにしました。また、検索クエリ内の商品並び替えについても同様の理由でランダム性を導入しました。 ランダム性の導入には Gumbel-Top-k Trick を利用しました。スコアに Gumbel ノイズを加算して top k を取ることで、スコア上位の候補ほど選ばれやすくしつつ、一定のランダム性を持たせる手法です。実装では、スコアに温度パラメータをかけることで、関連性を重視する度合いとランダム性の強さを調整しました。これによりスコア上位の関連性の高い検索クエリは表示されやすくしつつも、時にやや意外性のある下位の検索クエリも表示されることで、ユーザーが飽きずに回遊を続けられることを意図しています。実際に結果を確認すると、関連性の高いクエリが多く表示されつつも、時折意外性のあるクエリが混ざるような挙動となりました。 定性評価 検索クエリレコメンドの精度を確認するために定性評価を実施しました。生成 AI をコーディング支援に利用し、閲覧した商品IDリストを入力すると検索クエリレコメンド結果を表示する Web アプリを素早く作成しました。これをチームメンバーにも使っていただき、フィードバックを得ながら細かな調整を実施しました。また、これにより Bot などの大量アクセスによりレコメンド結果が不自然になることに気づけ、それを防ぐための前処理を入れることもできました。具体的には、 以前弊社の技術ブログでも紹介した手法 を参考に、短時間で大量に商品閲覧しているセッションを除外する対応を行いました。 AB テスト AB テストは、iOS アプリのホーム画面を訪問したユーザーを対象に2週間実施しました。Treatment では検索クエリレコメンドを12件、既存の個別商品レコメンドの上部に追加表示しました。Control では既存の個別商品レコメンドのみを表示しました。 Control と Treatment の画面イメージ比較図は以下のとおりです。 AB テストの結果は以下の通りです。 指標 Treatment / Control 相対改善 備考 ホームレコメンド経由の CVR 138% +38% 主指標 ホームレコメンド経由の ARPPU 105% +5% 客単価が落ちていないことの確認 ホームレコメンド経由の ARPU 146% +46% 客単価が落ちていないことの確認 iOS アプリ全体の商品閲覧ユーザー率 100.4% +0.4% iOS アプリ全体の CVR 100.1% +0.1% ここでいうホームレコメンド経由の CVR は、iOS アプリのホーム画面を訪問したユーザーのうち、ホームレコメンド経由で購入に至ったユーザー割合として定義しています。また、ホームレコメンド経由の購入は、ホームレコメンド上の商品または検索結果導線を起点として商品詳細に到達し、購入に至ったケースとして集計しています。 AB テストでは、ホームレコメンド経由の CVR や ARPU が改善しました。また、ARPPU が大きく低下していなかったことから、CVR 改善の裏で購入単価が悪化しているわけではないことも確認できました。 一方で、アプリ全体の CVR には大きな変化は見られませんでした。ホームレコメンド経由の購入は増加したものの、その一部には他導線からホームレコメンド経由への購入経路の付け替わりが含まれていた可能性があります。そのため、今回の施策はアプリ全体の購入を大きく押し上げるというよりも、ホーム画面からの商品探索を促進し、ホームレコメンド経由の購入機会を増やす効果が大きかったと考えています。 iOS アプリ全体では商品閲覧ユーザー率の上昇が見られました。iOS アプリ全体の商品閲覧ユーザーを分解して確認すると、検索クエリレコメンドのみから商品閲覧をしたユーザーが増えていました。それらの多くは検索結果画面に遷移したうえで商品を閲覧していました。このことから、検索クエリをレコメンドすることで、ホーム画面から検索結果での回遊を促し、アプリ全体の商品閲覧ユーザー率の改善につながったと考えられます。 まとめ 今回、iOS アプリのホーム画面に検索クエリレコメンドを導入したことで、ホームレコメンド経由の CVR、iOS アプリ全体の商品閲覧ユーザー率の上昇が見られました。これらの結果から、検索クエリのレコメンドがユーザーの回遊を促し、購入に結び付く商品に出会う確率を上げることができたと考えられます。一方で、課題としては全体の CVR にあまり変化は無かったことがあります。そこで、購入経路の付け替えではなく、純増を生み出す方向のレコメンドロジックや UI/UX を追求していきたいと考えています。それに向けて現在も引き続き AB テストにて新たなレコメンドロジックや UI/UX を試しています。 株式会社エニグモ すべての求人一覧 hrmos.co

AWS Summit が各地で開催されており、多忙な日々を過ごしています。私は New York City Summit において、「Building AI architectures with AWS Serverless」というワークショップを開催しました。そして、ビルダーたちが、エージェントとサーバーレスサービスを組み合わせて、わずか半日で実際の課題を解決していく様子を見るのは、とても楽しいものでした。6 月 29 日週は Washington, DC Summit に向かいます。このイベントは、常に公共部門におけるイノベーションにスポットライトを当てています。現地にいらっしゃる方は、ぜひお声がけください。 これらのイベントで私がよく受ける質問の 1 つは、「エンジニアリングの長いバックログの解消を待つことなく、チームはどのように AI を業務で活用できるのか」というものです。そして、今週最大のリリースは、まさにその問いに応えるものでした。Amazon Connect Customer は、ビジネスチームがノーコードで AI を活用したカスタマーエクスペリエンスを自ら設計するための方法を提供します。それでは、6 月 29 日週の AWS ニュースを見ていきましょう。 主なトピック Amazon Connect Customer は、AI を活用したセルフサービスエクスペリエンスを設計およびデプロイするためのノーコードキャンバスである Agentic CX Designer (NLX) をプレビューとしてリリースしました。ビジネスチームは、エージェンティック AI と決定論的 AI を、ガバナンスの効いた単一のフローに統合した音声およびデジタルエクスペリエンスを構築してリリースできます。これにより、設計から、テスト、シミュレーション、そして本番対応のエクスペリエンスまでを、数か月間ではなく数週間で完了できるようになります。今回のリリースには、プレビュー版の Live Sync も含まれています。これは、顧客が話したり、入力したりするのに合わせて、ウェブやモバイルでのエクスペリエンスをリアルタイムで連動させる特許取得済みのテクノロジーです。発信者は、会話を中断することなく、フォームへの入力や適切な製品ページの表示を行うことができます。誰がカスタマーエクスペリエンスを設計するのかを、これがどのように変革するのかにを知るには、「 business user is the new architect of customer experience 」というブログ記事をお読みいただくとともに、 Amazon Connect Customer ページにアクセスしてください。 6 月 22 日週のリリース 6 月 22 日週のリリースのうち、私が注目したリリースをいくつかご紹介します: AWS Lambda MicroVMs – 各ユーザーまたはジョブ VM レベルの分離を提供する新しいサーバーレスコンピューティングプリミティブ。ほぼ瞬時の起動および再開速度に加えて、実行を一時停止し、最大 8 時間後に再開する機能も備えています。Firecracker を基盤として構築されており、仮想化インフラストラクチャの管理や、分離、速度、状態のトレードオフを強いられることなく、マルチテナントアプリケーション内でユーザーや AI が生成したコードを実行できるよう設計されています。 Amazon EC2 AMI ウォーターマーク – プライベート AMI にカスタム識別子を埋め込むことができます。この識別子は、コピー、リージョン、アカウント共有にわたって、派生するすべての AMI に自動的に引き継がれます。許可された AMI や宣言型ポリシーとウォーターマークを組み合わせることで、承認されたイメージに対してのみ起動するよう制限できます。これは、すべての AWS リージョンで追加コストなしでご利用いただけます。 AWS Outposts セルフサービスおよびライフサイクル管理 – コンソール、CLI、API から直接、セルフサービスの設定、見積り、注文、サブスクリプションの管理、更新、および廃止を追加します。新しい見積りツールは、数秒でリアルタイムのコスト見積りを生成し、お客様が注文を送信する前に、アカウントやリージョンレベルの制約を表示します。 Amazon MSK AI エージェントスキル – Kiro、Claude Code、Cursor などの AI コーディングアシスタントに、Amazon MSK の運用に関する専門的かつ最新のガイダンスを提供します。これは、トラブルシューティング、サイズ設定、設定、モニタリング、および外部 Kafka クラスターから MSK Express への移行をカバーします。かつては専門知識が必要だったタスクが、デベロッパーが自力で完了できるガイド付きのプロセスとなります。 Amazon OpenSearch Service の AI が支援する移行 – Migration Assistant にエージェントがガイドするエクスペリエンスが含まれるようになりました。これは、Kiro や Claude Code などのツールを利用して、セルフマネージド型の Apache Solr、Elasticsearch、または OpenSearch のデプロイを OpenSearch Serverless やマネージドクラスターに移行するのに役立ちます。また、Solr 向けに、ライブトラフィックキャプチャおよびリプレイのサポートも新たに追加されています。 Amazon GuardDuty の AI を活用した調査 (プレビュー) – 実際の脅威と無害なアクティビティを区別するのに役立つよう、ナレッジグラフや脅威インテリジェンスを使用し、直近 90 日間のコンテキストや関連アクティビティを調査して、検出結果とアカウントを自動的に分析します。各調査では、信頼度スコア、MITRE ATT&CK 分類、実用的なレコメンデーションを含む判定結果が数分で返されます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: MySQL 向けのオープンガバナンス – Oracle は、MySQL 向けのコミュニティガバナンスモデルを発表しました。これは、Oracle 以外の組織にもプロジェクトにおける明確な役割を与えるものです。これには、新たに設置される Steering Committee に Oracle 以外の組織向けの 4 つの席を設けることや、GitHub を一般公開することが含まれます。AWS も席を有しており、この取り組みを支持する理由や、MySQL を利用するすべてのユーザーのために、既にアップストリームへの修正を提供していることについて説明しています。 AWS 認定を最新の状態に保つ新しい方法 – 対象となる AWS 認定は、あらためて受験する代わりに、AWS Skill Builder において、厳選されたトレーニングとハンズオンラボを完了することで、有効期間をさらに 1 年間延長できるようになりました。このオプションは現在、一部の Associate および Professional 認定を対象にオープンベータ版として提供されており、年内には対象がさらに拡大される予定です。 2026 年応募者向け「All Builders Welcome Grant」完全ガイド – AWS Builder Center で公開されているコミュニティガイド。キャリア初期のビルダーを対象に、この助成金の申請方法を順を追って説明しています。これは、AWS re:Invent 2026 のフルカンファレンスパス、航空券、ホテル費用をカバーします。現在応募を受け付けており、締め切りは 7 月 14 日です。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 他のビルダーと直接交流する機会をお求めですか? お近くの都市で開催される AWS Summits をチェックしたり、世界中のユーザーグループが主催する地元の AWS Community Day を探したり、 AWS Builder Center でチュートリアル、コミュニティコンテンツ、スキルアップのための方法を探索したりしてみてください。 6 月 29 日週のニュースは以上です。7 月 6 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Micah 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今週も様々なアップデートが公開されています。特に、AWS Blogで紹介している AI エージェント対応のデータ基盤は、エージェントをデータに以下に紐づけるのかというイメージの湧くデモになっていますので、ぜひご一読ください。 生成 AI を活用したビジネス変革に取り組むお客様を支援する 生成 AI 実用化推進プログラム は引き続き参加企業を募集しています。ご興味のある方はぜひご覧ください。 それでは、5 月 18 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ:  3 か月で開発スピード 3 倍を達成：キヤノン IT ソリューションズ様が実践した AI Coding Agent 導入・普及の仕組みづくり キヤノン IT ソリューションズ株式会社様（以下、キヤノン ITS 様）は、SIer としての競争力強化と顧客への付加価値提供のため、AI 駆動開発の社内普及を推進しました。生成 AI ツールの導入は進んでいたものの、現場での活用の定着と全社的な広がりが課題でした。これを解決するため、AWS と共同でロードマップを敷き、9 月のキックオフイベント「AI Agent DAY」（参加者 250 名以上）から 3 か月間にわたり、Amazon Q Developer を 57 名で業務適用検証しました。エグゼクティブスポンサーである金澤社長の支援、生成 AI ビジネス推進室による予算負担、ハンズオン・オフィスアワー・Teams コミュニティでの情報共有を組み合わせ、PoC 開発で従来 2 週間かかっていた作業を 3 日で完了するなど、開発スピード 3 倍、工数 67% 削減を達成しています。今後は本検証で得た知見を活かして社内での活用パターンを整理し、AWS と連携してさらなる活用領域の拡大に取り組まれる予定です。 AWS 生成 AI 国内事例ブログ: 富士電機ITソリューションが挑戦する働き方の大変革 〜Amazon Q Developer 活用から Kiro による新しい企業価値創出へ〜 富士電機 IT ソリューション株式会社様（以下、FSL 様）は、製造・流通・金融・建設・公共・文教など幅広い業界向けに IT ソリューションを提供する SIer です。SIer としての競争力強化と顧客への付加価値提供のため、生成 AI による開発生産性向上が重要なテーマでした。FSL 様は 2025 年 12 月から金森 重晴 執行役員の指揮のもと Amazon Q Developer Pro サブスクリプションを 20 ユーザーで展開し、「まず使ってみる」を合言葉にボトムアップ型のアプローチで現場主導の活用文化を育てた結果、現在では 50 ユーザー以上に拡大しています。本記事では、テスト結果報告書の作成や障害情報のインサイト抽出（原田氏）、ソースコードのレビュー支援や既存プログラム理解（久保田氏）、リバースエンジニアリングや見積もりツールの内製開発（前田氏）など現場発の 3 つの活用事例が紹介されています。今後は利用者のさらなる拡大と、仕様駆動開発を実現する Kiro の導入により、SDLC 全体を再設計する取り組みを進めていかれる予定です。 ブログ記事「 AWS における AI エージェント対応のデータ基盤 (1) — ツールを配る時代から、データを返す時代へ 」を公開 AI エージェントに本番データを分析させるには、認可・ビジネスデータカタログ・ドメイン知識の 3 要素を揃える必要があります。本記事ではサンプルリポジトリ  aws-samples/sample-sagemaker-agentic-analyst  を題材に、これら 3 要素が Amazon SageMaker Catalog、Amazon Bedrock AgentCore、AWS Lake Formation、Amazon S3 Access Grants の組み合わせでどう実装されているかを俯瞰し、構造化データと非構造化データを束ねた分析や Subscribe 申請を仲介するデモシナリオを紹介しています。データ分析エージェントを企業データに安全に接続したい方にぜひお読みいただきたい記事です。 ブログ記事「 AWS における AI エージェント対応のデータ基盤 (2) — SageMaker Catalog で行・列レベルのアクセス権を透過的に適用する 」を公開 上記シリーズの第 2 回です。AI エージェント経由のデータアクセスに、SageMaker Catalog で設定した行・列・オブジェクトレベルのアクセス制御をユーザー本人の権限で透過的に効かせるための実装パターンを解説しています。Cognito トークンから Tool Lambda の手元にプロジェクトロールの一時認証情報を運ぶ 5 ステップの認証情報変換フローや、Policy in AgentCore による Cedar ポリシーでのツール単位認可など、AgentCore Gateway を使った認可設計の実装の中身を詳しく追える内容になっています。 ブログ記事「 【開催報告】ガバメントクラウドワークショップ 2026 春 ～ AI で実践する開発・モダナイズ・運用 ～ 」を公開 5 月 19 日に開催された、ガバメントクラウドに携わる事業者向けワークショップの開催報告です。NTT データ様の Step Functions を中核としたフルマネージド・ジョブ基盤の事例、アクロクエストテクノロジー様の Amazon Bedrock を用いたセキュアな生成 AI 構築、NTT 西日本様の  GenU  と Amazon Bedrock AgentCore を活用した自治体向け AI エージェント、デジタル庁様による全府省庁約 18 万人向け生成 AI 利用環境「源内」の構築、AI エージェント開発・モダナイズ・運用の 4 テーマ別ワークショップなど、公共分野で生成 AI を活用するヒントが詰まった内容です。 ブログ記事「 Amazon Bedrock が、新しい高度なプロンプト最適化および移行ツールを導入 」を公開 5 月 14 日に発表された Amazon Bedrock Advanced Prompt Optimization の使い方を解説したブログです。元のプロンプトと最適化されたプロンプトを最大 5 個のモデルで同時に比較しながら最適化を進められるツールで、Lambda 関数によるカスタムスコアリング、LLM-as-a-judge ルーブリック、自然言語による方向性基準の 3 通りの評価方法をサポートしています。新しいモデルへの移行や、既存モデルでの精度改善に取り組まれている方にお勧めの記事です。 ブログ記事「 OpenSearch Agent Skills で agentic IDE に組み込み型のインテリジェンスを 」を公開 Claude、Cursor、Kiro などの agentic IDE の中で OpenSearch の専門知識をそのまま活用できる、オープンで組み合わせ可能なスキル集 OpenSearch Agent Skills の発表ブログです。Search、Logs、Solr から OpenSearch への移行という 3 つの基本スキルにより、自然言語の意図から検索アプリケーションの構築、ログ分析、移行作業を数分で実行できます。npx skills add opensearch-project/opensearch-agent-skills でインストールでき、MCP サーバーや追加コンポーネントは不要です。 ブログ記事「 AWS Security Agent のフルリポジトリコードスキャン機能のプレビュー提供開始 」を公開 AWS Security Agent に追加された、コードベース全体をコンテキスト認識型で分析するフルリポジトリコードレビュー機能の解説ブログです。アプリケーションのプロファイリング、脆弱性の検索、トリアージと重複排除、独立した検証という 4 ステージで動作し、既知のパターンと照合する従来の SAST が見逃すような、検証関数の不整合や設計レベルのギャップも検出します。検出結果は Verified / Could not verify を区別した構造化された証拠付きで提示されます。プレビュー期間中は既存の Security Agent のお客様に追加料金なしで提供されています。 ブログ記事「 Sim-to-Real と Real-to-Sim: 高性能な Physical AI を支える原動力 」を公開 現実世界で知覚・推論・行動するロボット、いわゆる Physical AI システムを支える Sim-to-Real / Real-to-Sim パイプラインを解説した記事です。シミュレーションと現実のギャップを埋めるためのドメインランダム化、現実環境をシミュレーション対応のデジタル表現に変換する Real-to-Sim、合成データ生成とフィルタリングなどを取り上げ、Vision Language Action モデル (VLA) の品質がシミュレーションデータの品質に依存することなどが説明されています。製造業・自動運転・医療・エネルギー・小売などの業界応用にも触れられています。 ブログ記事「 AI、技術的負債、そして AI を使いこなす力への道筋 」を公開 エンタープライズが直面する 3 つの共通課題（自社の技術資産の把握不足、AI 導入の停滞、AI を実践的に使いこなす力のギャップ）に対し、AWS Transform custom のモダナイゼーションエージェントを活用してコードからリアルタイムにドキュメントアーティファクトを自動生成するアプローチを提案しています。技術的負債の可視化と AI を使いこなす力の習得を同時に実現し、ポートフォリオ全アプリケーションへの展開を OKR として組織に定着させる進め方を、元 CTO の視点から実践的に解説した記事です。 サービスアップデート Amazon Bedrock がリクエストレベルの使用量属性のサポートを拡大 これまで Converse / ConverseStream API でサポートされていたリクエストレベルのメタデータ付与が、InvokeModel および InvokeModelWithResponseStream API でも利用できるようになりました。チーム、アプリケーション、環境、実験などの単位でモデル推論の使用量を個別のリクエストレベルでタグ付けし、Bedrock のモデル呼び出しログで分析できます。社内の利用状況を細かく可視化してコストを最適化したり、内部関係者へ利用量を報告したりするのが容易になります。Amazon Bedrock が利用可能な全ての AWS リージョンで利用できます。 Amazon SageMaker AI が推論エンドポイントで OpenAI 互換 API をサポート Amazon SageMaker Inference が OpenAI 互換 API をサポートするようになりました。OpenAI SDK、LangChain、Strands Agents などの既存ツールから、エンドポイント URL を変えるだけで SageMaker エンドポイントに接続できます。カスタム連携コードや SDK ラッパーの書き直しは不要で、独自の GPU インスタンス選択、VPC 内でのデータ保持、任意のオープンソース・ファインチューニング済みモデルの実行といった SageMaker のメリットをそのまま享受できます。東京、ソウル、シンガポール、シドニーなど 14 のリージョンで利用可能です。 AWS Transform に新しいエージェンティック移行アセスメント機能が追加 AWS Transform で、What-if シナリオ、カスタマイズ可能な前提条件、柔軟なファイル形式サポート、複数の TCO（総所有コスト）アセスメント機能を含む高度な移行アセスメント機能が利用できるようになりました。RVTools のエクスポート、CMDB データ、AWS Transform 検出ツール、サードパーティのディスカバリーツールなど、手元にあるあらゆるデータからアセスメントを開始できます。リージョン、リソース使用率、サービスマッピングをカスタマイズした What-if シナリオを作成して比較し、EC2、FSx、S3、SQL Server on EC2、仮想デスクトップのコストモデリングや、人材生産性・運用レジリエンス・ビジネスアジリティ・サステナビリティといった Cloud Value Framework の追加要素も含めて評価できます。 AWS Security Agent がペネトレーションテスト検出結果の検証スクリプトを生成 AWS Security Agent で、ペネトレーションテストで発見された各脆弱性に対して、その場で実行可能な検証スクリプトが自動生成されるようになりました。これまでは検出結果の詳細にある再現手順を手作業でなぞる必要がありましたが、今後はセキュリティチームがスクリプトをダウンロードし、環境変数を設定して対象システムに対して実行するだけで脆弱性を独立して再現・検証できます。スクリプトにはセットアップ手順、ドキュメント化された環境変数、機微な値のリダクションが含まれ、トリアージの効率化と修復の加速につながります。AWS Security Agent がサポートされている全リージョンで利用できます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。