Amazon Bedrock Agentsで化粧品推薦AIを作ってみた！実際に使って月2500円節約できた話

アジャイル開発チームの塚越です。2023年にInsight Edge(以下、IE)に参画し、そろそろ2年が経過します。

前回はエンジニアとしてPMに挑戦した 記事 を書きました。PoCフェーズでPMを務め、無事に商用化フェーズを迎えました。現在もPM兼務のエンジニアとしてこの案件に関わり続けています。エンジニア専任の案件も同時進行しており、このような市場価値の向上を目指せる環境を提供してくれたIEの方々には感謝しています。

今回は 『使い物になる』化粧品推薦AIエージェントをAmazon Bedrock Agentsなどのクラウドベンダー製品を活用し、ローコードサクッと『簡単に』作ろうとした話 を書きます（簡単に作れたとは言っていない・・・）。

※本記事の内容や今回作成したシステムは、IEの業務および携わった案件とは無関係です。

本記事でわかること

• 品質の高さ:どれだけ使い物になる化粧品推薦AIエージェントが作れたか
  • 5.使い物になるのか検証してみた
• 精度向上への工夫:使い物にするためにはどんな工夫が必要だったか
  • 4.つまずき・工夫
• 簡単さ:Amazon Bedrock Agentsを使うことでどれだけ簡単に作れたか
  • 6.簡単に作れたか

※この記事では開発したシステムを重視しており、Amazon Bedrock Agentsの基本的な構築方法には焦点を当てていません。 詳細は　2. Amazon Bedrock Agentsをとりあえず動かしてみる　に記載します。

目次

• 1. 化粧品推薦AIエージェントの概要
• 2. Amazon Bedrock Agentsをとりあえず動かしてみる
• 3. 化粧品推薦AIエージェントの実装
• 4. つまずき・工夫
  • 4.1. 課題1『ステップ数の限界』
  • 4.2. 課題2『エージェントの出すレポートの品質が低い』
• 5. 使い物になるのか検証してみた
• 6. 簡単に作れたか
• 7. 残課題・更なる展望

1. 化粧品推薦AIエージェントの概要

ここでは、化粧品推薦AIエージェントを開発したいと思った背景、システムのユースケース、システムの実現方法について記載します。

1.1. 背景

私は購入時、コスパを重視します。安価という意味ではなく、 品質とコストのバランスが最適化されたものを選びます。 特に毎日使う化粧品は、身体や気分、そしてランニングコストに影響するため、最適な商品を探す初期投資をかける価値があると考えます。

優先順位は以下の通りです:

1. 体質に合うこと
   • 肌荒れせず、自分の肌質に合ったものを選びたい。
2. 期待する効果が得られること
   • 肌質改善やアンチエイジングなど、求める効果が実感できること。
3. 費用を抑えること
   • 金額に見合う効果が得られるなら投資する価値はあるが、できるだけ費用は抑えたい。

例えば化粧水の場合、 肌荒れを起こさないだけでなく、肌質改善やアンチエイジング効果も期待しています。 『安価で肌に合わない商品』や『効果の薄い商品』を使うと、肌荒れや早期老化といったリスクが生じ、結果的に病院代や美容クリニック代の出費につながることがあります。そしてなにより、肌の調子が悪いと毎日の気分も下がります。 しかし、高価な商品だからといって必ずしも自分にとって最適だとは限りません。例えば、効果の高い成分を含んでいても、今の自分の肌質ではその成分の最大限の効果を発揮できないこともあります。 肌荒れしないことを必須条件とし、その次にコストパフォーマンスを重視して化粧品を選んでいます。

以上の理由から、費用や労働力といった初期コストをかけてでも最適な化粧品を探して長く使うようにしています（サンプルやトライアルセットの試用、店頭でのタッチアップと相談等）。しかし、値上げ・廃盤や販路の縮小といった事態が度々起こり、その度にまた最適な化粧品探しが始まり・・・疲弊してしまいます。

この疲弊を解決するために、代替品の推薦に特化した化粧品推薦AIエージェントの開発を試みました。

1.2. システムのユースケース

システムのユースケースは次を想定しています。

• 現在使用中の化粧品よりも費用を抑えたい場合
• 使用中の化粧品が廃盤や販路縮小により入手困難になり、代替品を探している場合

※『体質の変化により現在の化粧品が合わなくなった』『自分に合う化粧品が全くわからないので一から選んでほしい』といったケースは今回のシステムの対象外としています。

1.3. システムの実現方法

どうやって化粧品推薦AIエージェントを作るか、ここでは実現に繋がる主な仮説3つについて記載します。

• 1.3.1. 提案のプロセス
• 1.3.2. データの取得方法
• 1.3.3. エージェント開発手法

1.3.1. 提案のプロセス

私が代替品を探すプロセスは次のとおりです。 『このプロセスを『提案のプロセス』としてエージェントに組み込めば、代替品の推薦に特化した化粧品推薦AIエージェントが作れる！』 と仮説を置きました。

【私が代替品を探すプロセス】

1. 私が高評価している化粧品がある。
2. その化粧品に高評価をつけた人は、私と体質が似ていると考える。
3. 体質が似ている人たちが高評価している他の化粧品は、私に合う可能性が高いと判断する。
4. また、成分や製造元が似ているほど、私に合う可能性が高いと判断する。
5. 以上から、次の3つの観点でランク付けして代替品を決定する。
   • 体質の類似度
   • 評価の高さ
   • 成分・製品元の類似度

製造元を観点に含めた理由は、『同じ材料でも作り手が違えば品質も変わる』と考えるからです。

料理に例えると、私の作る卵焼きと筒井さん（私の上長）が作る卵焼きは、全く同じ材料を使ったとしても同じにはならないでしょう。そして、筒井さんの卵焼きを好む人は、筒井さんの料理ノウハウを継承する(であろう)筒井家の方々の作った卵焼きを好む確率が高いはずです。

1.3.2. データの取得方法

前述の 1.3.1. 提案のプロセス の通り、レビューデータが必要です。案としては

• レビューサイトのAPI活用
• レビューのDBを構築して検索する(RAG)

といったことが考えられます。が、生成AIの発展により 「Deep Research APIを使うことでデータが取得できる！」 と仮説を置きました。

2025/05時点、Google CloudといったクラウドベンダーではDeep ResearchのAPIが提供されていないため、手元でDeep Researchを使って得た回答をモックデータとして実験に使用しました。今回手元で利用したのはGemini Deep Researchです。

補足:2025/06/27にOpenAIからDeep Research APIが出ましたね！Azure OpenAI Serviceで提供されるのが楽しみです！

1.3.3. エージェント開発手法

コーディングして 1.3.1. 提案のプロセス をエージェントに組み込むには、画像のようなロジックを自分で考える必要があります。また、1つ1つの処理についても様々なロジックを検討しなければなりません。

ロジックのイメージ

『わざわざ実装しなくてもサクッと作れる時代になっているのではないか』と考え、Amazon Bedrock Agentsといった 「ローコードエージェント開発ツールを使えば、複雑なロジックを組まずにAIエージェント開発ができる！」 と仮説を立てました。

2. Amazon Bedrock Agentsをとりあえず動かしてみる

まずはAmazon Bedrock Agentsを使い、最小限の構成（MVP:Minimum Viable Product）で『とりあえず動く』AIエージェントを作成しました。この段階では、複雑なロジックや本格的なデータ連携は行わず、エージェントが動作し、ユーザーの入力に対して何らかの応答を返せる状態を目指しました。ここで得られた知見をもとに、次章以降で本格的な機能追加や改修を進めていきます。この章ではAmazon Bedrock AgentsのMVP構築方法についてまとめます。

構築には、次の記事を参考にさせていただきました。 【初心者でもOK！】Amazon Bedrock Agentsで「自然言語＞Web検索＞PDFレポート生成」エージェント開発ハンズオン

次の差分に留意し、参考サイト通りに構築することでAmazon Bedrock AgentsのMVPが構築できます。

1. リージョン:

   • us-west-2 オレゴン(Claude 3.5 Sonnetが使えるなら何処でも)

2. アクショングループ『web-search』のLambda関数:

   • 下記コードの通り、ただのテキストを返すモックとして実装し、後ほど検索APIを実装しました（まず動くところが見たかった・・・）。 ※参考サイトではTaviryが使われていますが、私は別のAPIを使いました。Taviryでいいので実装は割愛します。
   • 参考サイトのコードをそのまま使うとレスポンスが文字化けしたので body 要素のコードを修正しました。

ソースコード(クリックで展開)

# lambda_handler.py
# Mockとして使えるサンプルコード。実際のWeb検索処理は走らず、固定のテキストが返される。

import json
import boto3
from botocore.exceptions import ClientError

client = boto3.client("bedrock-agent-runtime")

# Lambdaハンドラー
def lambda_handler(event, context):
    action_group = event.get("actionGroup")
    function = event.get("function")
    parameters = event.get("parameters", [])

    search_query = next((param["value"] for param in parameters if param["name"] == "search_query"), None)
    search_results = "これは検索結果のサンプルです。これ以外のWeb検索は現在できない状態です。" 

    response_body = {
        "TEXT": {
            "body": json.dumps({
                "query": search_query,
                "results": search_results # json.loads(search_results)
            }, ensure_ascii=False)  # Unicodeのエスケープを防ぐ
        }
    }
    return {
        "messageVersion": "1.0",
        "response": {
            "actionGroup": action_group,
            "function": function,
            "functionResponse": {
                "responseBody": response_body
            }
        }
    }

（任意）Lambda関数のテスト用のコード。

{
  "parameters": [
    {
      "name": "search_query",
      "value": "検索 キーワード"
    },
    {
      "name": "key2",
      "value": "value2"
    },
    {
      "name": "key3",
      "value": "value3"
    }
  ]
}

こんなに簡単に構築したのに、自律的に動くエージェントの挙動が実現できてびっくりしました！

3. 化粧品推薦AIエージェントの実装

では、前章で得られたAmazon Bedrock Agents MVPをもとに、『化粧品推薦AIエージェント』を本格的に構築していきます。機能追加や改修は次の4点です。

• 3.1. プロンプトを修正する
• 3.2. アクショングループ『research』を追加する
• 3.3. Max output tokensを最大にする
• 3.4. (任意)アイドルセッションタイムアウトを伸ばす

3.1. プロンプトを修正する

手順: - エージェントビルダー ＞ エージェント向けの指示(以下プロンプト) を次の内容に修正する。

プロンプト(クリックで展開)

# 立場

あなたは優秀な美容部員です。化粧品の成分といった科学の分野にも長けています。お客様が入力した化粧品の情報から、お客様に合う別の化粧品を提案することがタスクです。

# ルール

- タスク遂行の計画を立案してください。
　- step1:レポート(.mdファイル)の提出状況を確認する。
    - 提出済みの場合:step2に進む。
    - 未提出の場合:
      1. お客様の入力情報から『ブランド 商品名 商品カテゴリ』を特定し、Deep Research(research)ツールに入力する。特定できない場合はお客様に伺う。
      2. 『レポートのルール』に従ってレポートを作成する。
      3. レポートは『.mdファイルでダウンロードできる形式』で添付する形で提出する。
　- step2:タスクの完遂に必要なステップを全て羅列する。
　  - 提案の考え方は『提案のプロセス』に従うこと。
　  -『Session summaries』や会話の履歴を確認し、『提案のプロセス』を守っていない点を厳しく確認する。
　  - 確認した内容とお客様のご質問を踏まえて、タスクの完遂に必要なステップを全て羅列する。
- 次の場合、状況をユーザーに提示し、次にする内容に合意を得てください。
  - 提案が完成した。『提案のプロセス』を守っている理由を箇条書きで添えること。
  - Web検索(web-search)を3回以上実施したがまだ情報が足りていない。
- あなたができるアクションは次の2つです。それ以外については、すべて自らの判断と操作で進めてください。回数に制限はありませんので、必要なときに随時利用して構いません。
  1.Web検索(web-search):Web検索が実行できます。検索キーワードはあなた自身で考えてください。
  2.お客様に伺う:お客様が満足する回答をするために不明点を聞いたり、提案に対するレビューをいただくことができます。

# 提案のプロセス

以下の考え方を持って、お客様に合う別の化粧品をランキング形式で提案する。

1. 入力された化粧品はお客様が最も高評価している商品である。
2. 入力された化粧品に対して高評価レビューを付けている人物（複数可）はお客様と同じ**体質**を持っていると考える。
  - 後ほどレポートで使うため、人物情報(レビューをしたサイト名、レビュー内容、人物詳細）を詳細に取得する。
3. プロセス2で見つけた同じ体質を持った人物達が、高評価を付けている別の化粧品（複数用意する。**10商品**以上。）はお客様にも合う商品ではないかと考える。
  - 後ほどレポートで使うため、レビュー情報(レビューをしたサイト名、レビューした商品、レビュー内容、人物詳細）を詳細に取得する。
4. お客様の入力した化粧品と成分や製品元が類似しているほどお客様にとって良い商品と言えると考える。
  - 後ほどレポートで使うため、商品情報(成分一覧、製造元、その他商品情報）を詳細に取得する。
5. 複数の候補の中でも、**体質の類似度**の高さ、**評価**の高さ、**成分/製品元の類似度**の高さ、これらが高ければ高いほど良い商品と考え、レーティングする。
6. レーティングの結果から、ランクを付ける。

# レポートのルール
根拠を充実させ、化粧品のプロフェッショナルからの高度なレビューもクリアできるような、日本一を誇る高品質で洞察に満ちたレポートに仕上げる。
- レポートは日本語であること。
- 『提案のプロセス』1~6の順序で構成されており、次の根拠が明確に伝わるレポートにすること。
  - ①『提案のプロセス』1,2で1枚のレポートを提出する。(**report1.md**)
    - 『入力された化粧品』の情報をレポートに含ませること。そこには金額等、ランキングのカラムと記載する項目を一致させること。
    -  人物情報(レビューをしたサイト名、レビュー内容、人物詳細）を詳細に記載すること。
  - ②『提案のプロセス』3,4で1枚のレポートを提出する。(**report2.md**)
    -  人物情報(レビューをしたサイト名、レビューした商品、レビュー内容、人物詳細）を詳細に記載すること。
  - ③『提案のプロセス』5,6、1~4を踏まえて1枚のレポートをランキング形式で提出する。(**report3.md**)
    - ランキングは**表形式**で表現されており、次の仕様に従っていること。
      - **体質の類似度**、**評価**、**成分**、**製品元の類似度**のレーティング結果とその理由や根拠を記載するカラムを必ず含ませること。
        - 特に**成分**のレーティング理由には具体的な成分名をもとに論じること。
      - ランク付けには使わないが金額のカラムを必ず含ませること。
      - 商品名等の基本情報だけではなく、ランク付けの根拠や理由が明確に伝わるカラムを自分で考案して追加すること（①②で重要視した内容を入れる）。

これが、『化粧品推薦AIエージェントに特化したプロンプト』として最終的に辿り着いたプロンプトです。試行錯誤してこの形に落ち着きました。詳細は 4.つまずき・工夫 で述べます。

3.2. アクショングループ『research』を追加する

Deep ResearchのAPIを呼び出すLambda関数を追加します。アクショングループ『research』を作成します。 ※ 1.3.2. データの取得方法 の通り、Deep Research APIの呼び出しは実装されておらず、固定のテキストを返すモックです。

手順:

1. アクショングループ名／アクショングループ関数名／その説明: research
2. パラメータ: research_text、説明: Researchテキスト
3. Lambda関数:自動生成されたLambda関数にアクセスし、以下のコードを貼り付ける。

ソースコード(クリックで展開)

# lambda_handler.py
# Mockとして使えるサンプルコード。実際のDeep Research処理は走らず、固定のテキストが返される。
# SAMPLE_TEXTにDeep Researchした結果を貼り付ける。

import json
import boto3
from botocore.exceptions import ClientError

client = boto3.client("bedrock-agent-runtime")

SAMPLE_TEXT = """
（ここにDeep Researchした結果を貼り付ける）
"""

SYSTEM_PRONPT_TEMPRATE = """
を普段使っています。代替商品をランキング形式で提案して。なお、提案のプロセスは次に従って。

# 提案のプロセス

以下の考え方を持って、お客様に合う別の化粧品をランキング形式で提案する。

1. 入力された化粧品はお客様が最も高評価している商品である。
2. 入力された化粧品に対して高評価レビューを付けている人物（複数可）はお客様と同じ**体質**を持っていると考える。
  - 後ほどレポートで使うため、人物情報(レビューをしたサイト名、レビュー内容、人物詳細）を詳細に取得する。
3. プロセス2で見つけた同じ体質を持った人物達が、高評価を付けている別の化粧品（複数用意する。**10商品**以上。）はお客様にも合う商品ではないかと考える。
  - 後ほどレポートで使うため、レビュー情報(レビューをしたサイト名、レビューした商品、レビュー内容、人物詳細）を詳細に取得する。
4. お客様の入力した化粧品と成分や製品元が類似しているほどお客様にとって良い商品と言えると考える。
  - 後ほどレポートで使うため、商品情報(成分一覧、製造元、その他商品情報）を詳細に取得する。
5. 複数の候補の中でも、**体質の類似度**の高さ、**評価**の高さ、**成分/製品元の類似度**の高さ、これらが高ければ高いほど良い商品と考え、レーティングする。
6. レーティングの結果から、ランクを付ける。

# レポートのルール
根拠を充実させ、化粧品のプロフェッショナルからの高度なレビューもクリアできるような、日本一を誇る高品質で洞察に満ちたレポートに仕上げる。
- レポートは日本語であること。
- 『提案のプロセス』1~6の順序で構成されており、次の根拠が明確に伝わるレポートにすること。
  - ①『提案のプロセス』1,2で1枚のレポートを提出する。(**report1.md**)
    - 『入力された化粧品』の情報をレポートに含ませること。そこには金額等、ランキングのカラムと記載する項目を一致させること。
    -  人物情報(レビューをしたサイト名、レビュー内容、人物詳細）を詳細に記載すること。
  - ②『提案のプロセス』3,4で1枚のレポートを提出する。(**report2.md**)
    -  人物情報(レビューをしたサイト名、レビューした商品、レビュー内容、人物詳細）を詳細に記載すること。
  - ③『提案のプロセス』5,6、1~4を踏まえて1枚のレポートをランキング形式で提出する。(**report3.md**)
    - ランキングは**表形式**で表現されており、次の仕様に従っていること。
      - **体質の類似度**、**評価**、**成分**、**製品元の類似度**のレーティング結果とその理由や根拠を記載するカラムを必ず含ませること。
        - 特に**成分**のレーティング理由には具体的な成分名をもとに論じること。
      - ランク付けには使わないが金額のカラムを必ず含ませること。
      - 商品名等の基本情報だけではなく、ランク付けの根拠や理由が明確に伝わるカラムを自分で考案して追加すること（①②で重要視した内容を入れる）。
"""
# Lambdaハンドラー
def lambda_handler(event, context):
    action_group = event.get("actionGroup")
    function = event.get("function")
    parameters = event.get("parameters", [])
    
    research_text = next((param["value"] for param in parameters if param["name"] == "research_text"), "") + SYSTEM_PRONPT_TEMPRATE # Deep Research APIが使える場合を想定してクエリだけ実装。
    search_results = "Researchした結果を表示します。" + SAMPLE_TEXT

    response_body = {
        "TEXT": {
            "body": json.dumps({
                "query": research_text,
                "results":  search_results
            }, ensure_ascii=False)  # Unicodeのエスケープを防ぐ
        }
    }
    return {
        "messageVersion": "1.0",
        "response": {
            "actionGroup": action_group,
            "function": function,
            "functionResponse": {
                "responseBody": response_body
            }
        }
    }

コードの補足:モック実装ではあるものの、Deep ResearchのAPIが私の環境で使えるようになることを想定して作成しているので、Deep Researchに入力する文章作成のコーディングは終わっています。例えば、 research_text が『ディセンシア サエル 化粧水』だった場合『を普段使っています。代替商品をランキング形式で提案して。なお、提案のプロセスは次に従って。〜（略）〜』がDeep Researchに入力される仕様です。

これでエージェントが２つのアクショングループを使えるように改修できました！

3.3. Max output tokensを最大にする

アウトプットトークンを最大にします。2048トークンを超える場合があったので伸ばしました。処理が止まることはないものの、2048トークンで打ち切られて情報が欠けることは望ましくなかったからです。

手順:

1. エージェントビルダー ＞ Orchestration strategy にアクセス
2. オーケストレーション タブを選択
3. Max output tokens を最大値に変更（画像参照）※それ以外の設定はデフォルト

3.4. (任意)アイドルセッションタイムアウトを伸ばす

デフォルトは10分間です。概ね処理できる時間設定ですが、反復回数や処理の内容によって超過する可能性は0ではないため、アイドルセッションタイムアウトを20分に伸ばしました。手順は画像の通りです。

4. つまずき・工夫

ローコードツールを使ったため、思うように実現できない状況に苦しみました。理想や期待は次の通りです。

システムに対する理想や期待

本章では、つまずき(理想と現実のギャップ)に直面した代表的な2つの課題

• 4.1. 課題1『ステップ数の限界』
• 4.2. 課題2『エージェントの出すレポートの品質が低い』

について、それぞれ

• つまずきポイント
• 検討した工夫案と比較
• 各工夫案の実施方法
• 最終的に選択した工夫と理由

の流れで記載します。

4.1. 課題1『ステップ数の限界』

4.1.1. つまずきポイント

4章冒頭画像の理想①のように、エージェントに対する指示（以下、『プロンプト』）をすべて達成するまでステップを実行することを期待していました。しかし、私のエージェントは最大7回で停止し、『Sorry, I am unable to assist you with this request.』という応答を返してしまいます。トレースステップを確認すると、 Max iterations exceeded が停止理由だとわかります。2025/06/17時点の情報によると、次のように記載があり、ステップ数を伸ばすことができないとわかります。

Please note that this error is encountered because the maximum iterations limit for an agent is set by default. This currently is a hard limit and cannot be configured by users on a per-agent basis.

引用: AWS re:Post

4.1.2. 検討した工夫案と比較

私の目指す化粧品推薦AIエージェントは、プロンプトに指示したような、充実した提案レポートを作成することが目標です。そのため、ステップ数を最大7回に収めるような簡単なタスクへと変更することは、本来の目的から逸れることになります。トレースを確認すると、エージェントは自律的にステップを考え、指示を達成しようとしてくれていて、7回で収めようとはしていないようです。そこで、エージェントの持つ履歴情報を活用して擬似的にステップ数を伸ばす案を検討しました。

2つの工夫を考案・比較し、最終的に 案2:会話履歴を使う を選択しました。

• 案1:Session SummariesをONにする

  • メリット:エージェントのセッションを切ることで、前回までの要約（Session Summaries）を活用し、続きを実行できる
  • デメリット:毎回セッションを切る手間が発生する

• 案2:会話履歴を使う

  • メリット:ユーザーが「続きは？」と入力するだけで、前回の続きから再開できる
  • デメリット:『Sorry, I am unable to assist you with this request.』ではなく、エージェントがエラーを返す場合、解消できないことが多い

4.1.3. 各工夫案の実施方法

案1、2の実施方法と詳細を説明していきます。

案1:Session SummariesをONにする

Session Summariesとは、セッションをまたいで会話の履歴や文脈を記憶する機能のことです。プロンプトの指示を完遂する前に止まってしまった場合、Session Summariesを使えば、続きから処理を再開して完遂まで至れると考えました。

案1の実装方法:

1. エージェントビルダー画面＞Memoryセクション＞有効を選択する。
2. プロンプトにSession Summariesを使う前提で計画を立案させるように指示を記載した。

案1を使ったエージェントの実行手順:

1. テストできる状態にする（エージェントビルダー画面＞保存＞準備＞テスト）。
2. ユーザークエリに『{ブランド名} {商品名} {カテゴリ}の代替案を教えて。』と入力し、送信する。
3. エージェントからの応答『Sorry, I am unable to assist you with this request.』が返ってくる。
4. 一度セッションを切る（画像のアイコンを押下）。
5. Session Summariesに前回のsummaryが残っていることを確認する（反映に少し時間がかかる）。
6. ユーザークエリに『続きは？』と入力し、送信する。

3回程度繰り返すことでプロンプトの指示が完遂できました。

案2:会話履歴を使う

案2の実装方法:

• 特になし。

案2を使ったエージェントの実行手順:

1. ユーザークエリに『{ブランド名} {商品名} {カテゴリ}の代替案を教えて。』と入力し、送信する。
2. エージェントからの応答『Sorry, I am unable to assist you with this request.』が返ってくる。
3. ユーザークエリに『続きは？』と入力し、送信する。

こちらも3回程度繰り返すことでプロンプトの指示が完遂できました。

蛇足:うまくいかなかった工夫案

案2はうまくいったものの、『Sorry, I am unable to assist you with this request.』と表示されたり、『続きは？』と入力させる仕様は好ましくありません。あえて途中で止めてユーザーに再入力させることでシステムとして成立するのではと考え、プロンプトを工夫しました。Web検索が最も反復回数を消費するとトレースステップから確認できたため、次のように回数制限を設ける文言を記載しました。しかし、この指示を守ってくれることはありませんでした。

- 次の場合、状況をユーザーに提示し、次にする内容に合意を得てください。
  - Web検索(web-search)を3回以上実施したがまだ情報が足りていない。

※守ってくれる期待を込めて、プロンプトに記載は残しています。

4.2. 課題2『エージェントの出すレポートの品質が低い』

4.2.1. つまずきポイント

4章冒頭画像の理想②のように、エージェントの応答には.md形式のレポートが添付されることを期待していました。プロンプトの指示だけで、充実した内容のレポートが自動で生成されることを想定していましたが、実際には以下のように添付されたレポートの内容が薄いという課題がありました。

• ランキングの根拠が1行程度しか記載されていない
• 各商品の評価項目や得点、その理由が十分に説明されていない
• 「なぜその商品を薦めるのか？」という納得感のある説明が不足している

4.2.2. 検討した工夫案と比較

この課題を解決するため、以下の2つの工夫を実施しました。

• 案1:指示を細かく具体的に記載する
  • レポートの構成や記載項目、根拠の書き方などをより具体的にプロンプトへ明記
• 案2:段階的にレポートを出力させる
  • 一度に全てを出力させるのではなく、複数回に分けて段階的にレポートを生成させる

※これらの工夫でプロンプトの指示がさらに複雑になります。前述の課題1の通り、指示を完遂できなくなるため、課題1の工夫がより大事となります。

案1:指示を細かく具体的に記載する

2. Amazon Bedrock Agentsをとりあえず動かしてみる　の時点では、プロンプトに詳細な指示を記載しなくてもエージェントは自律的な行動をしてくれている印象がありました。そのため、目的だけ、例えば 根拠を充実させ、化粧品のプロフェッショナルからの高度なレビューもクリアできるような、日本一を誇る高品質で洞察に満ちたレポートに仕上げる。 といった文言で指示すればエージェントが自律的に行動し、充実したレポートを出力してくれることを期待していました。

そのような考えで記載した初期のプロンプトは次の通りです。

Markdown形式のレポート作成について:
- 収集した全ての情報を整理し、推薦する化粧品をランキング形式で記載してください。
- ランキングには必ず根拠を一緒に記載してください。
- レポート本文のテキストは日本語で記述してください。
- レポートは.md形式のファイルとして添付してください。添付できるようにコードも活用してください。
- 根拠を充実させ、化粧品のプロフェッショナルからの高度なレビューもクリアできるような、日本一を誇る高品質で洞察に満ちたレポートにしてください。

最終的な出力として、以下を全て1つのMarkdown形式のファイルに含めてください:
1. 日本語で正しく表示されるレポート本体（各セクションの詳細な説明を含む）。
2. レポート作成プロセスと各決定の根拠の説明
3. 与えられたタスクに沿った、ランキング決定とその根拠の詳細な記載

4.2.1. つまずきポイント の通り、期待したような高品質なレポートは生成できませんでした。そこで、プロンプトに指示を細かく具体的に記載することで解決できると考えて、次の赤枠のように記載方法の詳細を記載したプロンプトに落ち着きました。

結果、レポートに記載される項目の内容は高品質になりました。しかし、情報の『項目』が不足している状態でした。考えた追加の工夫案を次章で説明します。

案2:段階的にレポートを出力させる

案1のようなレポートの具体的な記載方法を詳細に指示したとしても、1回の出力量を増やすことは難しいため、項目数が不足する結果となったと仮説を置き、段階的にレポートを出力すればいいと考えました。

プロンプトに次の赤枠のような指示を記載しました。

応答が完了していない状態で、 report1.md と report2.md の生成が確認できました。応答が完了すると同時に report3.md が出力されました。段階的にレポートを出力させることで、出力量を増やすことに成功しました。

実際に出力された3つのレポートは以下の通りです。項目数、各項目の内容、どちらもプロンプトに指示したように充実した内容になっています。私の期待する高品質なレポートが出力できました。

蛇足:うまくいかなかった工夫案

『Claude 3.5 Sonnet』よりも新しいモデル『Claude 3.7 Sonnet』を使えば、期待する高品質なレポートを生成してくれるのではないかと考え、モデルの変更を試しました。

画像の通り、『Bedrock Agents optimized』という指定されたモデル群『以外』から選択することになります。その結果、エラー応答が頻発してしまいました。エラー応答で処理が止まった場合、課題1の工夫を実施することでエージェントは処理を再開できます。しかし、処理に過不足が生じたり、処理がループしてしまったりと、不具合が多発します。できる限りエラー応答は起きないようにした方がいいと考え、モデル変更はしないことにしました。

5. 使い物になるのか検証してみた

提案された化粧品を実際に購入・利用して有用な化粧品推薦AIエージェントが作れていたかを検証します。 各検証で「Before」はこれまで使用していた商品、「After」はエージェントの提案から選択した代替品を指しています。

5.1. 検証１:化粧水

Top1として提案された商品を1週間試してみました。

• Before:ディセンシア サエル
• After:オルビス ユードット

購入

検証結果

（化粧してない肌を載せるのはちょっと嫌ですが検証のために身を切ります。）

• 切り替えた初日は刺激を感じて焦った。2回目以降は問題もなく使えており、1週間使ってみても問題なく使えている。
• 肌の調子がずっといい(ゆらぎを感じない)のでより良い商品に出会えたのかもしれない。
• コストが削減できた。 ※いずれも私が購入した金額です。ネットの情報とは異なる可能性があります。
  • Before:120mlで5500円
  • After:180mlで3630円。

肌に合うだけでなくより調子が良くなる商品に出会えました。また、コスト削減もできたため、今後はこちらの商品を使用していこうと考えています。

5.2. 検証2:シャンプー

提案されたレポートを見てみると、レビュー情報や利用者情報が不足しているのか、エージェントはTop5までしか提案してくれませんでした。元々使用していた商品は1000円以内の価格帯でしたが、Top5以外の商品は1000円を超える価格だったため、仕方なくTop5の商品を検証することにしました。エージェントへの入力にはシャンプーのみを使用し、検証ではシャンプーだけでなくトリートメントも同じブランドに揃え、1週間試してみました。

• Before: P&G、ヘアレシピ (HAIR RECIPE)、ハニーアプリコット
• After: モイストダイアン、パーフェクトビューティー、エクストラダメージリペア

ドラッグストアで購入したので写真は割愛します。

検証結果

（髪の色味を合わせるために写真の彩度を調整しています。）

• 写真ではAfterがよく見えるが、若干パサつくようになって気分が下がったため利用者の私からの評価はBeforeに軍配。１週間使ってみて大きな問題はなく、写真を見る限り見た目は改善しているので、トータルで見ると許容範囲の商品。
• 今回Afterに選んだ商品はTop5と低めの順位のため、Top1を選べばさらに適した商品が見つかる可能性も感じる。
• コストが削減できた。※いずれも私が購入した金額です。ネットの情報とは異なる可能性があります。
  • Before:シャンプー651円。トリートメント623円。各330ml。
  • After:シャンプー、トリートメント各450mlで550円。

元々使用していた商品は、発売当初はドラッグストアで購入できたのですが、現在では入手が難しく困っていました。ドラッグストアで購入でき、髪のコンディションも許容範囲内で、コスト削減も実現できたため、今後はこちらの商品を使用していこうと考えています。

5.3. 検証結果まとめ

• 化粧水とシャンプー、いずれも体質に合う商品を見つけることができた。
• ランキング上位の商品の方が良い商品である可能性も考察できた。
• コストが月2547円削減できて嬉しい。内訳は次の通り。

項目	Before（1ヶ月あたり）	After（1ヶ月あたり）	コストダウン額
化粧水	5500円（120ml）	2420円（120ml換算）	2080円
シャンプー&トリートメント	1274円（各330ml）	807円（各330ml換算）	467円
合計			2547円

※Afterの金額は容量換算後の1ヶ月あたりのコストです。

以上から、意義のある化粧品推薦エージェントを作ることができたと考えています。これにより、廃盤や販路縮小の問題が起きた際に、 疲弊せずに代替商品を見つけることができるようになりました。 特に、化粧水の代替品は長年見つけることができていなかったので、今回の検証で見つけることができて非常に驚き・嬉しいです！

6. 簡単に作れたか

Amazon Bedrock Agentsの活用により、エージェントが簡単に作れたかというと・・・微妙です・・・。メリットもありましたが、4章で述べた通りそれなりに苦労やデメリットがありました。

メリット:

• ローコードで開発できる。
• プロンプトに記載するだけで指示に沿って自律的に行動してくれる。割と雑な指示でも行動自体は自律的にしてくれるので、ここは感動した。

デメリット:

• カスタマイズ困難な制限が多い。特に反復回数の制限は『自律的に行動してくれる』というメリットを妨げている印象がある。
• 出力形式（出力量の指示も含む）といった、指示に沿いづらい部分もある。

以上を踏まえると、タスクの完遂に多くの反復を要したり、出力内容にこだわりたい場合には、最初からコーディングした方が良いと感じました。一方で、単発で完遂できるタスクだったり、出力内容にそれほどこだわらないタスクであれば、Amazon Bedrock Agentsを有効活用できると感じました。また、別のクラウドベンダーが提供するローコード製品も検討すべきだと思いました。IEの熊田さんがAzure AI Foundry Agent Serviceをデモしてくれました。Amazon Bedrock Agentsと比較すると複雑性は増します。しかし、制約が少なく、より柔軟に対応できる印象を受けました。

7. 残課題・更なる展望

UI/UXの改善

『Sorry, I am unable to assist you with this request.』というエラーメッセージが表示される仕様や、ユーザーが『続きは？』と入力しなければならない仕様は理想的とは言えません。また、なぜか添付ファイルが2つになることもあり、これらの問題をフロントエンドの実装で解決したいと考えています。

アクショングループ『research』のAPI実装

現時点、Deep ResearchのAPI呼び出しを実装した際の品質が確認できていないのが懸念事項です。Deep ResearchのAPIを組み込んで品質の確認したいと考えています。トレースを確認したところ、エージェントは『research』でデータ収集を試みていますが、一度しか使えないため、代わりに『web-search』を使っていました。『research』利用の制約がない状況になれば、エージェントが『web-search』で代替していた情報収集処理を改善でき、品質向上が期待できます。

また、上長の筒井さんから「Deep Research単体で化粧品推薦のタスクを完遂できるのではないか」という指摘がありました。私としては、Amazon Bedrock Agentsが『research』結果をさらにブラッシュアップし、指定した形式でレポートすると所に優位性があると考えています。Deep ResearchのAPI呼び出しを実装することで、何度も呼び出してブラッシュアップすることが可能となるため、さらに優位性を高めたいと考えています。その際、『research』のプロンプトは情報収集に適した指示へと修正する予定です。※現在はエージェント用のプロンプトに記載したものと同じものを使っています。何度も呼び出せる前提なら改善の余地があると感じています。

ユースケースの拡張

少しの修正で次のような別のユースケースにも対応できる可能性があるため、試してみたいと考えています。

• 異なるカテゴリの提案例:高評価している化粧水を入力して、乳液を提案してもらう
• 化粧品以外の分野への応用:高評価しているレストランを入力して、代替となるレストランを提案してもらう

長くなりましたが、最後まで読んでいただきありがとうございました！