0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

お題は不問！Qiita Tech Festa 2026で記事投稿！
Qiita Tech Festa20262026年7月13日まで開催中！
@Takayyyy

Amazon Bedrock AgentCore Web Searchを日本語で試して分かった、得意な検索と苦手な検索

0
Posted at

はじめに

Amazon Bedrock AgentCoreでWeb Searchが利用できるようになったため、実際に日本語の検索をいくつか試してみました。

Web Searchは、AmazonのWebインデックスや構造化された情報を利用し、検索結果のURL、タイトル、公開日、クエリに関連するスニペットを返すマネージドサービスです。

外部の検索APIを別途契約せず、AgentCore GatewayからMCPツールとして利用できます。AWSの認証やガバナンスの中で検索機能を組み込めるため、既存のAWS環境へ統合しやすそうです。

2026年7月11日時点ではus-east-1でのみ提供されています。日本からも利用できますが、東京リージョンを含む他リージョンへの展開が待ち遠しいところです。

今回は単純な疎通確認だけでなく、次の点を検証しました。

  • 日本語の検索結果は実用になりそうか
  • 最近のニュースを探せるか
  • 日付やサイトを指定した検索はできるか
  • 返されるtextには何が入っているか
  • どのようなクエリで精度が上がるか

検証日は2026年7月11日です。

検索結果やサービス仕様は今後変わる可能性があるため、この記事の内容は検証時点のものとしてご覧ください。

検証結果の概要

先に結果をまとめると、次のようになりました。

検証内容 結果 評価
日本語検索 検索できるが、広いテーマではノイズが多い △
公式情報の検索 既知の製品名を含めると公式ページを見つけやすい ○
最近のニュース 新しい記事は返るが、期間を厳密には限定できない △
自然言語による日付指定 指定期間外のページも返る ×
after: 日付フィルターとしては機能しなかった ×
site: 指定外のドメインも返った ×
固有名詞や数値の追加 対象記事や関連記事の検索精度が改善した ○
textスニペット モデルへ渡しやすいが、原文確認は必要 ○

Web Search単体で「今日のニュースを漏れなく収集する」といった用途には工夫が必要です。

一方で、企業名、製品名、機能名、バージョン番号など、ある程度の固有情報が分かっている状態から関連情報を探す用途では、使いやすいと感じました。

Web Searchの概要

Web Searchは、AgentCore Gatewayに組み込みコネクタとして追加します。

入力はシンプルで、指定できるのは検索文字列と最大結果数です。

{
  "query": "Amazon Bedrock AgentCore Web Searchの最新情報",
  "maxResults": 5
}

queryは200文字以内、maxResultsは1〜25です。デフォルトは10件です。

2026年7月11日時点ではus-east-1で提供されており、料金は1,000クエリあたり7 USDです。AgentCore Gateway、モデル、ログなどの料金は別途発生します。

参考:

検証環境

今回は次の構成で試しました。

  • AgentCore Gateway
  • Inbound AuthはAWS IAM
  • Web Search ToolをMCP targetとして追加
  • CloudShell上のPythonから呼び出し
  • MCP Python SDK
  • mcp-proxy-for-awsによるSigV4署名

GatewayやIAMロールの具体的なIDは省略します。

IAM認証のGatewayへ接続する部分は、次のような形です。

import asyncio

from mcp import ClientSession
from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client


GATEWAY_URL = (
    "https://YOUR_GATEWAY_ID.gateway."
    "bedrock-agentcore.us-east-1.amazonaws.com/mcp"
)


async def main():
    async with aws_iam_streamablehttp_client(
        endpoint=GATEWAY_URL,
        aws_region="us-east-1",
        aws_service="bedrock-agentcore",
    ) as (read_stream, write_stream, _):
        async with ClientSession(read_stream, write_stream) as session:
            await session.initialize()

            tools = await session.list_tools()

            for tool in tools.tools:
                print(tool.name)

            web_search = next(
                tool
                for tool in tools.tools
                if "websearch" in tool.name.lower()
            )

            result = await session.call_tool(
                web_search.name,
                arguments={
                    "query": (
                        "Amazon Bedrock AgentCore "
                        "Web Searchの最新情報"
                    ),
                    "maxResults": 5,
                },
            )

            print(result)


if __name__ == "__main__":
    asyncio.run(main())

GatewayをIAM認証で作成した場合、クライアントIDやクライアントシークレットではなく、SigV4でリクエストを署名します。

レスポンスは少し二重構造になっている

Web SearchのレスポンスはMCP形式で返ります。

構造を簡略化すると、次のようになります。

MCPレスポンス
└─ content[0].text
   └─ JSON文字列
      └─ results[]
         ├─ title
         ├─ url
         ├─ publishedDate
         └─ text

content[0].textには、検索結果そのものではなくJSON文字列が入っています。

そのJSON文字列をデシリアライズすると、results配列を取得できます。

import json

payload = json.loads(result.content[0].text)

for item in payload.get("results", []):
    print("title:", item.get("title"))
    print("url:", item.get("url"))
    print("publishedDate:", item.get("publishedDate"))
    print("text:", item.get("text"))
    print()

検索結果1件のイメージは次のような形です。

{
  "title": "記事タイトル",
  "url": "https://example.com/article",
  "publishedDate": "...",
  "text": "検索クエリに関連する箇所のスニペット"
}

各結果に含まれるtextには、ページ全文ではなく、検索クエリとの関連性をもとに抽出されたスニペットが入ります。

実際に試したところ、数行程度の短い文章だけでなく、記事の主要な数値や調査条件を含む、比較的長いスニペットが返る場合もありました。

ページ全体をモデルへ渡すよりも、必要な箇所を少ないトークンで渡せる点は便利です。

一方で、次の点には注意が必要です。

  • ページ全文を確認できるわけではない
  • スニペットに抽出されなかった記述は分からない
  • 一覧ページでは別の記事の情報が混ざることがある
  • publishedDateとスニペット内の日付が一致しない場合がある
  • Knowledge Graph由来と思われる結果ではurlがない場合がある

価格、規約、事故情報、法令など、正確性が重要な情報を扱う場合は、スニペットだけで断定せず、元ページを確認した方が安全です。

まずは公式情報を検索してみる

最初に、AgentCore Web Search自身の公式発表を検索しました。

Amazon Bedrock AgentCore Web Search latest official announcement

上位にはAWS News Blog、AWS What's New、AWS Machine Learning Blogなどが並びました。

既知の製品について公式情報を探す用途では、素直に使えそうです。

ただし、少し気になる点もありました。

  • 英語で検索してもAWSブログの別言語パスが上位に来る場合があった
  • 発表記事のスニペットに古い料金説明が残っていた
  • 関連性の低いKnowledge Graph由来と思われる結果が混ざった

公式情報そのものを見つけることはできましたが、検索結果のスニペットをそのまま最終回答へ利用するのは避けた方がよさそうです。

検索サービス側の問題だけでなく、検索対象となるWebページ自体に古い情報が残っている場合もあります。

特に料金や仕様については、ローンチ時のブログではなく、現在の料金ページや最新のドキュメントを優先する必要があります。

料金を検索してみる

次に、現在の料金を調べました。

Amazon Bedrock AgentCore Web Searchの現在の料金

1位にはAgentCoreの公式料金ページが返りました。

ただし、返されたスニペットにはWeb Searchの具体的な料金が含まれていませんでした。また、別の検索結果として返されたAWS News Blogには、「追加料金なし」という説明が含まれていました。

一方、AWS Blogでは、Web Searchの料金は1,000クエリあたり7 USDと説明されています。

このように、料金に関する検索ではAWS公式ページ同士でも説明が一致していませんでした。検索結果のスニペットだけをモデルへ渡して回答を生成すると、どちらか一方の説明をそのまま採用してしまう可能性があります。

料金や利用条件のように正確性が重要な情報は、検索結果の順位やスニペットだけで断定せず、最新の料金ページや複数の公式資料を確認する必要があると感じました。

最近のニュースを探してみる

今回、特に確認したかったのがニュース検索です。

以下の検索クエリは、実際の検証で確認した検索特性を、技術ニュースの文脈に置き換えて示したものです。公開にあたり、検索対象や固有名詞を一部一般化していますが、記載している挙動や評価は実際の検証結果に基づいています。

例えば、次のような複数条件を含む広いクエリです。

直近1か月に発表された生成AIサービスの新機能と対応リージョンを調査

実際の検証では、このような広いニュース検索に対して、対象となるニュース記事だけでなく、次のようなページも混在する傾向が確認できました。

  • 製品のトップページ
  • 一般的な機能紹介
  • 過去のアップデート記事
  • イベント告知
  • Knowledge Graph由来と思われる構造化情報

Web Searchは、入力された文章をタスクとして分解し、複数の調査を自動的に実行するわけではありません。

複雑な依頼をそのまま検索クエリへ入れるより、次のような短い検索へ分ける必要がありそうです。

  • 2026年7月 生成AIサービス 新機能 GA
  • 2026年7月 クラウドサービス 対応リージョン 追加
  • 2026年7月 AIエージェント 新サービス 提供開始

日付を明示してみる

次に、期間とテーマをクエリへ明示しました。

2026年6月1日から2026年7月11日
生成AI 新サービス 新機能 対応リージョン 発表

しかし、指定期間より前の記事や、対象サービスのトップページ、一般的な機能紹介なども結果に含まれました。

Web Searchの入力スキーマには、開始日、終了日、国、言語、ニュース種別などの専用パラメータがありません。

日付をクエリへ書くことはできますが、厳格なフィルターとして扱われるわけではなさそうです。

after:を試してみる

Google検索のようにafter:が使えるかも確認しました。

以下は、実際の検証クエリを技術ニュースの文脈へ置き換えた例です。

after:2026-06-01 生成AI 新サービス 新機能 対応リージョン

実際の検証では、after:2026-06-01を含めても、publishedDateが2021年や2024年として返されたページが検索結果に含まれました。

少なくとも今回の検証では、after:は日付フィルターとして機能しませんでした。

ページ自体は古くても、本文中に新しい日付の一覧や更新情報が含まれているケースもありました。

after:は公式にサポートされている検索演算子ではないため、今後も同様の挙動になるとは限りません。

厳密な日付絞り込みを前提に実装するのは避けた方がよさそうです。

site:も試してみる

次に、特定の公式サイトや技術ブログへ限定できるか試しました。

site:<URL>/path "2026年7月" 生成AI 新機能 GA

結果には指定外のドメインが含まれ、指定サイトの個別記事は返りませんでした。

こちらも今回の検証では、Google検索のようなサイト限定演算子としては機能しませんでした。

公式に提供されているドメイン制御は、Gateway target単位で設定するdenylistであり、allowlistではありません。

そのため、特定の公式サイトや技術メディアだけを検索対象にする用途には向かないようです。

「今日のニュース」も試してみる

日付をそのまま検索語へ含める方法も試しました。

2026年7月11日 生成AI 新機能 GA 対応リージョン 発表

実際の検証では、当日の日付を含むクエリでも新しいページは返りましたが、指定した日付・テーマ・対象をすべて満たすニュースは確認できませんでした。

publishedDateが7月11日になっている結果でも、スニペット内で説明されているイベントの日付は7月9日というケースがありました。

publishedDateが、必ずしも記事本文中の出来事の発生日を表しているとは限らない点は、実装時に意識する必要がありそうです。

今回の検証だけでは、どの日時を基にpublishedDateが設定されているかまでは判断できませんでした。そのため、publishedDateだけで記事の公開日や出来事の発生日を判断しない方がよさそうです。

厳格に日付を制御したい場合は、検索結果を取得した後に、次のような後処理が必要です。

  • publishedDateを確認する
  • スニペット内の日付表現を抽出する
  • ページ本文を取得し、公開日を確認する
  • 対象期間外の結果を除外する

ただし、検索結果の段階で必要な記事を拾えていなければ、後処理だけでは解決できません。

日付による後処理と、クエリの分割や再検索を組み合わせる必要がありそうです。

固有情報を増やすと結果が改善した

広いニュース検索では苦戦しましたが、検索対象に関する固有情報が分かっている場合は、結果が改善しました。

実際の検証では、企業名、調査名、固有の数値などを組み合わせることで、元となった記事が1位に返り、主要な事実や関連報道までスニペットから確認できました。

これを技術ニュースの文脈に置き換えると、例えば次のような情報を組み合わせる方法が考えられます。

企業: あるクラウドベンダー
発表: 新しいAI機能
サービス名: あるマネージドサービス
提供形態: 一般提供
固有情報: 対応リージョンと機能名

これらを組み合わせ、次のようなクエリにします。

企業名 サービス名 機能名
一般提供 対応リージョン 2026年7月

このように、広いテーマだけで検索するのではなく、固有名詞、提供形態、時期などを組み合わせることで、対象記事を見つけやすくなると考えられます。

一方で、必ずしも公式ドキュメントや一次情報が最上位に返るとは限りませんでした。

一次資料が検索インデックスに含まれていない、検索順位が低い、またはクエリとの関連度が低い場合には、固有情報を増やしても見つからないことがあります。

それでも、広いテーマだけで検索した場合と比べると、結果は明確に改善しました。

Web Searchが得意そうな使い方

今回の結果を見る限り、Web Searchは次のような用途で使いやすそうです。

  • 既知の企業や製品について関連情報を探す
  • 記事タイトルや固有名詞を手掛かりに元記事を再発見する
  • クエリに関連する箇所をスニペットとして取得する
  • 同じテーマの類似事例や関連報道を探す
  • モデルの学習時点より後に公開された情報を補う
  • Knowledge Graphの情報から次の検索語を作る

反対に、次の用途では工夫が必要です。

  • 今日のニュースを漏れなく列挙する
  • 直近1か月だけに厳密に限定する
  • 特定の国や企業だけを検索対象にする
  • 特定の公式サイトや技術メディアだけを対象にする
  • 一次資料を必ず取得する
  • 価格、法令、規約をスニペットだけで断定する

使い方のイメージ

Web Searchへ最初から「今日のニュースを全部探して」と依頼するより、あらかじめ得られた情報を手掛かりに検索する方がよさそうです。

外部情報から候補となる出来事を取得
  ↓
企業名・製品名・発表名・数値を抽出
  ↓
AgentCore Web Searchで関連情報を検索
  ↓
返されたURLとtextスニペットを整理
  ↓
重要な情報だけ元ページを確認

Web Searchには「ニュースを見つける役割」だけを求めず、「得られた固有情報を基に、関連するWeb情報を広げる役割」を持たせると使いやすくなりそうです。

実装時に入れておきたい処理

実際にエージェントへ組み込む場合は、検索結果をそのままモデルへ渡すのではなく、簡単な前処理を入れた方がよさそうです。

URLがない結果を引用候補から除外
一覧ページや低関連ページを除外
同じURLを重複排除
publishedDateと本文の日付を確認
公式ドメインや官公庁を優先
価格・規約・事故情報は元ページを再確認

Knowledge Graph由来の結果は、引用には使えなくても、企業名や製品名の候補抽出には利用できる可能性があります。

完全に捨てるのではなく、次の検索クエリを作る材料として扱う方法も考えられそうです。

元ページの確認も別途必要

Web Searchが返すのは、ページ全文ではなく関連スニペットです。

そのため、最終的に正確な回答や引用を生成する場合は、URLから元ページを取得する処理も必要になります。

例えば、次のように役割を分けられます。

Web Search
  → 候補ページと関連スニペットを取得

ページ取得処理
  → 候補ページの本文を取得

モデル
  → スニペットと本文を比較して回答を生成

すべての検索結果の本文を取得すると、処理時間やトークン消費が増えます。

そのため、Web Searchのスニペットを使って候補を絞り込み、重要なページだけ本文を取得する構成がよさそうです。

コストについて

Web Searchは1検索あたり約0.007 USDです。

単発検索であれば小さい金額ですが、クエリを分解し、企業や製品ごとに再検索すると、1回の調査で5〜10検索程度になる可能性があります。

1検索: 約0.007 USD
5検索: 約0.035 USD
10検索: 約0.070 USD

これにAgentCore Gateway、モデル、ログ、必要に応じてページ確認用の処理などが加わります。

エージェントへ自由に検索させる場合は、1リクエストあたりの最大検索回数、タイムアウト、再試行上限を決めておいた方が安心です。

まとめ

AgentCore Web Searchは、Google検索APIのような検索演算子や構造化フィルターを備えた検索サービスとは、少し性格が異なります。

今回の検証では、次のような結果になりました。

  • Gateway経由のMCPツールとして問題なく利用できた
  • 日本語でも検索結果を取得できた
  • 公式情報や既知の企業・製品を探す用途では良好だった
  • textスニペットはモデルへ渡す情報として使いやすかった
  • 自然言語による日付指定は厳格なフィルターにならなかった
  • after:とsite:は今回の検証では期待どおり機能しなかった
  • 日本語の広いニュース検索ではノイズが多かった
  • 企業名、製品名、機能名、数値などの固有情報を増やすと品質が改善した
  • 正確性が重要な情報では、元ページを確認する処理が必要だった

個人的には、Web Search単体でニュース検索を完結させるよりも、既知の情報を起点に関連情報とスニペットを取得するツールとして使うのが合っていると感じました。

Amazonが提供するWeb検索機能をAWSサービスとして利用でき、検索結果がモデル向けのスニペットとして返る点は魅力的です。

一方で、検索結果の公開日、料金、規約、一次資料の確認が重要な用途では、検索結果だけで回答を生成せず、元ページを取得して確認する処理も組み合わせる必要がありそうです。

まだ提供が始まったばかりの機能なので、今後の検索品質や入力オプションの拡張にも期待したいところです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?