Amazon Bedrock の Web Search を英語と日本語で試す

先端技術開発グループ（WAND）の伊賀です。**

2026年8月、Amazon Bedrock に Web Search** が追加されました（Introducing Web Search on Amazon Bedrock for foundation model grounding）。

推論リクエストにパラメータを 1 つ追加するだけで、モデルが Web 検索で回答を裏付けてくれる（グラウンディングする）ようになる、という機能です。

発表を読んで気になったのは、検索基盤が Amazon の自前運用で、クエリの組み立てからページの取得までがAWS内で完結するという点でした。

モデルがどんなクエリで検索し、どのソースを引いてくるかは利用者側から指定できないため、日本語で質問したときにこの一連の検索がどう動くのかは、実際に動かして観察するしかありません。

そこで、同じ内容の質問を英語と日本語で投げて、発行された検索クエリと引用されたソースの違いを観察し、回答が事実と整合するかを検証してみました。

本記事で扱う内容は次のとおりです。

• Web Search の概要とセットアップ手順

• 英語の質問と日本語の質問での検索結果の比較、回答の妥当性の検証

• 試すなかで確認した、利用前に知っておきたい制約と注意点

Web Search on Amazon Bedrock とは

Web Search は、Amazon Bedrock に組み込まれた Web 検索ツールです。

リクエストの tools 配列に {"type": "web_search"} を追加すると、モデルは質問に最新情報が必要かどうかを自分で判断し、必要なら検索を実行して、検索結果に基づいた回答を引用（citation）付きで返します。

これまで LLM の回答を最新の Web 情報で裏付けたい場合、外部の検索プロバイダーと契約し、API キーの管理、検索結果をプロンプトへ詰め込む処理、引用の組み立てを自前で用意するのが一般的でした。

Web Search ではこの一連の処理を Bedrock がサーバーサイドで実行するため、アプリケーション側は 1 回の API 呼び出しで引用付きの回答を受け取れます。

検索の背後には、Amazon が運用する数百億ドキュメント規模の Web インデックスとナレッジグラフがあり、継続的に更新されています（What's New）。

検索は 2 つの操作から構成されます（Web Search - Amazon Bedrock User Guide）。

• Search：Web インデックスとナレッジグラフから、タイトル、URL、スニペットを返す

• Fetch：特定 URL のページ本文をキャッシュから取得する

どちらもデフォルトでは AWS 境界内のインデックスとキャッシュから提供され、リクエストのデータが AWS の外へ出ることはありません。

2026年8月時点の対応状況は次のとおりです。

• 対応モデル：openai.gpt-5.4、openai.gpt-5.5、openai.gpt-5.6（sol / terra / luna）

• 対応 API：bedrock-mantle エンドポイントの Responses API

• 対応リージョン：us-east-1、us-east-2、us-west-2

つまり現時点では、Bedrock 上の OpenAI モデル専用の機能です[[1]](#fn-3df0-1)。

セットアップ

必要なものは次の 3 つです。

• US リージョン（us-east-1 / us-east-2 / us-west-2）の Bedrock を呼び出せる AWS 認証情報

• Web Search の IAM 権限

• Python パッケージ openai と aws-bedrock-token-generator

pip install openai aws-bedrock-token-generator

IAM 権限は、サービスプレフィックス bedrock-websearch の 3 アクション（InvokeSearch、InvokeFetch、ExternalWebAccess）で制御されます。

3 つすべてを含むマネージドポリシー AmazonBedrockExternalWebSearchReadOnly も用意されています。

今回の検証は管理者相当のロールで行ったため個別のポリシー設定は不要でしたが、ExternalWebAccess の扱いには注意点があります（後述します）。

呼び出しコードは次のようになります。

bedrock-mantle エンドポイントは OpenAI SDK 互換なので、base_url と API キーを差し替えるだけで普段の OpenAI SDK のコードがそのまま使えます。

API キーには aws-bedrock-token-generator が AWS 認証情報から生成する短期トークンを渡します。

from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-east-1"

client = OpenAI(
    base_url=f"https://bedrock-mantle.{REGION}.api.aws/openai/v1",
    api_key=provide_token(region=REGION),
)

response = client.responses.create(
    model="openai.gpt-5.4",
    input="What were the key announcements at AWS re:Invent 2025?",
    tools=[{"type": "web_search", "external_web_access": False}],
    store=False,
)

print(response.output_text)

Web Search の有効化は tools の 1 行だけです。

external_web_access は AWS 境界の外へのアクセスを許可するかのフラグで、ここでは明示的に False にしています（理由は後述します）。

あわせて store も False にしています。

Responses API は OpenAI の仕様に合わせて store のデフォルトが true で、そのままだと会話の継続用に、入力と出力が呼び出し先リージョンに 30 日間保存されます（How the Responses API stores conversation state）。

Web Search でデータが AWS 境界の外に出ないことと、データが保存されないことは別の話です。

今回のように状態の保持が不要な単発の呼び出しでは、False を明示すると保存自体を避けられます。

レスポンスの output には、モデルの回答（message）に加えて、検索の実行記録（web_search_call）が含まれます。

どんなクエリで検索し、どのページを開いたかをここから確認できます。

for item in response.output:
    if item.type == "web_search_call":
        if item.action.type == "search":
            print(f"search: {item.action.queries}")
        elif item.action.type == "open_page":
            print(f"open_page: {item.action.url}")

引用は回答テキストの annotations に url_citation として付きます。

どの文がどのソースに裏付けられているかが文字位置（start_index / end_index）付きでわかります。

for item in response.output:
    if item.type == "message":
        for block in item.content:
            if block.type == "output_text":
                for ann in block.annotations or []:
                    if ann.type == "url_citation":
                        print(f"[{ann.title}] {ann.url}")

上のコードを実行すると、次のような結果が返ってきました。

search: ['AWS re:Invent 2025 key announcements official blog re:Invent 2025']
open_page: https://aws.amazon.com/blogs/aws/top-announcements-of-aws-reinvent-2025

検索を 1 回実行し、ヒットした AWS 公式ブログのまとめ記事を開いて、その内容から Graviton5 や Trainium3 UltraServers、AI Factories といった発表を引用付きで要約してくれました。

セットアップから最初の応答まで、問題なく実行することができました。

Web Search なしだと何が起きるか

比較のため、同じモデルに Web Search なしで質問してみます。

題材は「AWS Summit Japan 2026 の開催日と場所」と「日本銀行の現在の政策金利」の 2 つで、質問文は次節の日本語版と同じものです。

Summit の質問には、次のように返ってきました。

AWS Summit Japan 2026 は、2026年6月17日（水）・18日（木）の2日間、
幕張メッセ（千葉県千葉市）で開催されていました。

実際の開催日は 2026年6月25日〜26日です。

存在しない開催日を、曜日まで添えて断定してきました。

政策金利も同様です。

2026年8月12日現在、日本銀行の政策金利（無担保コール翌日物金利の誘導目標）は、
0.75％程度です。

実際の政策金利は、2026年6月16日の金融政策決定会合で引き上げられて 1.0% になっています（日本銀行の公表文、PDF）。

質問を定型的な言い回し（「いつ、どこで開催されましたか?簡潔に教えてください。」）に変えて試すと、今度は Summit には「開催情報は確認できません」と答え、政策金利には 0.25% というさらに古い値を返しました。

言い回し次第で、正直に知らないと言うこともあれば、誤った答えを作ることもあり、挙動は予測できません。

「知らない」と答えてくれるとは限らないことが、グラウンディングが必要になる理由をそのまま示しています。

Web Search を有効にして同じ質問をすると、どちらも正しい答え（2026年6月25日〜26日に幕張メッセで開催、政策金利は 1.0%）が引用付きで返ってきました。

英語と日本語で検索結果を比較する

本題の言語比較です。

性格の異なる 4 カテゴリの質問を用意し、それぞれ同じ内容を英語と日本語で openai.gpt-5.4 に投げました。

external_web_access は False、つまり AWS 境界内のインデックスとキャッシュのみを使う設定です。

質問文は、「〜を教えてください」のような定型文ではなく、実際にチャットで質問するときの、文脈を含んだ文章にしました。

日本語版の質問文は次の 4 つです。

• グローバルな技術ニュース：「昨年12月の re:Invent には参加できず、まだ情報を追いきれていません。AWS re:Invent 2025 の発表の中で、特に重要だったものを3つ挙げるとしたら何でしょうか?」

• 日本のイベント情報：「同僚が AWS Summit Japan 2026 に参加していたのですが、私は行きそびれてしまいました。いつ、どこで開催されていたのでしょうか?」

• 日本語コミュニティ情報：「同僚から JAWS DAYS 2026 というイベントがとても良かったと聞きました。これはどんなイベントで、いつ開催されたものなのでしょうか?」

• 最新の時事情報：「住宅ローンを組もうか考えていて、金利の動向が気になっています。日本銀行の政策金利は、今いくらになっていますか?」

英語版は、同じ内容を自然な英文にしたものです。

たとえば政策金利の質問は "I'm thinking about taking out a mortgage in Japan, so I've been watching interest rates. What is the Bank of Japan's policy rate right now?" としています。

回答の妥当性

結論から書くと、今回選んだ 4 題では、日英とも事実と整合する回答が得られました。

• AWS Summit Japan 2026：「2026年6月25日（木）〜26日（金）、幕張メッセ」と回答。AWS 公式 FAQ の記載と一致しています。

• JAWS DAYS 2026：「JAWS-UG による全国規模の AWS コミュニティイベント、2026年3月7日（土）開催」に加え、日本語版は会場（池袋サンシャインシティ）まで回答。公式サイトの告知と一致します。

• 日銀の政策金利：「2026年6月に 0.75% から 1.0% へ引き上げ、7月末の会合でも維持」と回答。日本銀行の公表文（6月16日、PDF、7月31日、PDF）と一致します

• re:Invent 2025：英語版と日本語版のどちらも、AWS 公式のまとめ記事に含まれる発表（エージェント関連、Trainium3 / AI Factories など）を挙げました。この題は「最重要 3 つ」の選択に主観が入るため、厳密な正誤ではなく公式まとめとの整合で見ています

なお re:Invent の「最重要 3 つ」の選択は、英語版が Nova 2 の拡張を、日本語版が Graviton5 を 3 位に選び、完全には一致しませんでした。

どちらも公式まとめに含まれる主要発表なので誤りではありませんが、順位づけのような主観の入る質問では、言語間で回答が揃うとは限らないようです。

Web Search なしでは開催日も政策金利も間違えていたわけですから、検索を挟むだけで正しい値に変わる効果は、並べて見るとはっきりわかります。

質問に含めた文脈も回答に反映されます。

住宅ローンを検討しているという文脈を付けて政策金利を聞くと、金利の値に加えて、変動金利と固定金利のどちらが政策金利の影響を受けやすいかまで補足してくれました。これは英語版でも同じでした。

検索結果の要約がそのまま返ってくるのではなく、質問の文脈に沿った回答になることはわかります。

モデルが発行した検索クエリの言語

web_search_call の記録から、モデルが実際に発行した検索クエリを観察できます。

次の表は、今回の比較実行で発行されたクエリです。

文章で質問しても、検索クエリはキーワードを並べた形に変換されます。

検索エンジンに投げるクエリとしてはこれが普通の形で、英語版では site:aws.amazon.com のような検索演算子を使うケースもありました。

クエリの言語に注目すると、この比較実行では、日本のトピック（Summit Japan、政策金利）を日本語で質問したときは日本語のクエリが、re:Invent や JAWS DAYS では日本語で質問しても英語のクエリが発行されました。

質問の言語をそのまま引き継ぐのではなく、トピックに応じてクエリの言語が選ばれているように見えます。

質問の言い回しを定型文に変えたセットでも、この分かれ方は同じでした。

この比較実行の JAWS DAYS では、英語クエリで検索したにもかかわらず、返ってきた引用ソースは jaws-ug.jp と Qiita の日本語参加レポートでした。

クエリの言語にかかわらず、インデックスが日本語コンテンツを返せることを示しています。

ただし、この使い分けが固定されているわけではありません。

公開前の再実行では、JAWS DAYS の同じ日本語質問から「JAWS DAYS 2026 イベント 開催日 公式」と「JAWS DAYS 2026 official event date」という日英両方のクエリが生成されました。

クエリの言語は実行ごとに変わりうるものとして見る必要があります。

引用された日本語ソース

Amazon の自前インデックスと聞くと、日本語のソースがどの程度インデックスされているのかが気になります。

一連の検証で実際に引用された日本語ソースは次のとおりです。

• AWS 日本語ブログ（aws.amazon.com/jp/blogs/news/ の開催報告記事）

• JAWS-UG 公式サイト（jaws-ug.jp）

• Qiita の参加レポート記事

• 日本銀行の日本語ページ（boj.or.jp）

• NHK、TBS、朝日新聞のニュース記事

• note.com の記事

公式サイト、報道、コミュニティ記事のいずれのタイプも引用され、参加レポートや note の個人記事まで引けてきました。

少なくともこれらの日本語ソースがインデックスに入っていることは、引用から確認できます。

ただし、そこから「日本語コンテンツが十分にカバーされている」とまでは言えません。

今回の 4 題はいずれも英語のソースでも答えられるトピックなので、仮に日本語ソースに欠けがあっても、回答は英語ソースで成立してしまい、欠損として観察できないためです。

カバレッジそのものを確かめるなら、個人ブログや地方イベントの告知のような、日本語にしかソースがない情報をどこまで引けるかを試す必要があります。

これは今後の宿題にしようと思います。

言語の対応関係にも触れておくと、日本語で質問したときは日本語ソースが優先的に引用され、英語で質問すると同じトピックでも英語ソース（日銀の英語ページなど）に寄る傾向がありました。

回答の言語は、今回の比較実行ではいずれも質問の言語と一致していました。

ただし後日の再実行では、日本語の回答に他言語の単語が紛れ込むケースもあったため、常に一致するとまでは言えません。

レイテンシとトークン消費

計測した範囲では、Web Search なしの応答が 2〜8 秒程度だったのに対し、有効にすると 7〜35 秒程度でした。

検索 1 回で短く答えられる質問（Summit Japan の開催日など）は 7 秒前後、検索を 3 回実行してページも開き、長い回答を生成したケース（re:Invent の振り返りなど）では 30 秒前後です。

検索結果はモデルのコンテキストに入るため、入力トークンも増えます。

今回の検証では 1 質問あたり入力 7,700〜19,200 トークンでした。

対話的な用途に組み込むならストリーミング（Responses API の stream=True）と併用するのがよさそうです。

インデックスの鮮度

ドキュメントによれば、現時点の Web Search はライブの Web にアクセスせず、すべて AWS 内のインデックスとキャッシュから結果を返します。

それならインデックスの更新頻度が実用性を左右するはずなので、鮮度が問われる質問として「今日の東京の天気」を、external_web_access を False にしたまま聞いてみました。

search: ['東京 今日 天気 気象庁']
answer: 今日の東京は、晴れベースで、午後はにわか雨や雷雨の可能性ありです。
最高気温は33〜34℃前後、最低気温は26℃前後の予報です。（tenki.jp）

AWS 境界内のインデックスだけを使う設定にもかかわらず、当日の予報が tenki.jp を引用して返ってきました。

1 回の実行なので具体的な更新間隔まではわかりませんが、少なくともこの実行では当日の情報を取得でき、「継続的に更新される」という公称と矛盾しない結果でした。

利用前に知っておきたい制約と注意点

これから試す人が知っておくとよさそうな点を 3 つ挙げます。

最初の 2 つは検証中に実際にエラーとして遭遇したもの、3 つ目はドキュメントで確認した挙動です。

Chat Completions API では使えない

Web Search は Responses API 専用です。

既存のコードが Chat Completions API（client.chat.completions.create）で書かれている場合、tools に web_search を渡しても次のエラーになります。

Error code: 400 - invalid request body: Invalid 'tools':
unknown variant `web_search`, expected `custom` or `function`

OpenAI SDK を使い慣れているほど Chat Completions で書き始めてしまいがちなので、最初から Responses API（client.responses.create）を使う前提で組むのが安全です。

なお、本記事のように /openai/v1 を base_url にした状態では、client.models.list()（/openai/v1/models）も 404 を返します。

モデル一覧が必要な場合は、共通パスの /v1 を base_url にすると取得できました（bedrock-mantle のドキュメントでも案内されているのはこちらのパスです）。

東京リージョンでは使えない

対応リージョンは US の 3 リージョンのみです。

ap-northeast-1 の bedrock-mantle エンドポイントに同じリクエストを投げると、Web Search 以前にモデルの時点で 404 になります。

Error code: 404 - The model 'openai.gpt-5.4' does not exist

external_web_access のデフォルト値と IAM 権限の食い違い

ツール定義の external_web_access パラメータは、OpenAI の Responses API と互換にするためデフォルトが true です。

一方、Bedrock の標準的なマネージドポリシーである AmazonBedrockFullAccess は、bedrock-websearch:InvokeSearch と InvokeFetch は許可するものの、ExternalWebAccess を含みません。

つまり、AmazonBedrockFullAccess だけを付けたロールで {"type": "web_search"} とだけ書くと、デフォルト値との組み合わせで認可エラーが発生します。

このとき、ドキュメントによればリクエスト自体は失敗せず、モデルはインデックス検索だけで回答を作ったうえで、外部アクセスができなかった旨を回答内で報告してくる、という挙動になります（Controlling external web access）。

今回の検証では管理者相当の権限を使ったためこの状況には遭遇しませんでしたが、エラーで止まらないぶん、気づかずに運用してしまいそうな挙動です。

対処は 2 通りです。

• "external_web_access": false を明示する。追加の権限は不要で、AWS 境界内で完結する

• bedrock-websearch:ExternalWebAccess を明示的に許可し、デフォルトの true のまま使う

紛らわしいのですが、現時点では true にしてもライブの Web への直接アクセスは行われず、取得はすべて AWS 内のインデックスとキャッシュから行われます。

ExternalWebAccess 権限は、将来ライブアクセスが有効になったときのための明示的なオプトインという位置づけです。

将来の仕様変更で挙動が変わらないようにする意味でも、当面は false を明示しておくのが説明しやすい構成だと思います。

料金と利用条件

Web Search の料金は Amazon Bedrock の料金ページで確認できます。

検索結果がコンテキストに入ることによる入力トークンの増加は前述のとおりなので、モデルの利用料と合わせて見積もりに入れておくのがよいと思います。

引用の扱いには利用条件があります。

エンドユーザーに回答を表示する場合、回答に含まれるソースの引用とリンクを保持して表示することが求められます。

また、検索結果の大量抽出や、競合するインデックスの構築への利用は禁止されています（Acceptable use）。

url_citation として構造化された形で引用が返ってくるので、表示要件を満たす実装は難しくありません。

監査面では CloudTrail のデータイベントに対応しており、誰がいつ検索を実行したかを記録できます。

データイベントはデフォルトでは記録されないため、trail か event data store 側での明示的な有効化が必要で、データイベントの追加料金も発生します（Monitor Web Search）。

なお、検索クエリの本文や取得したページ内容はログに記録されない設計になっています。

まとめ

Web Search on Amazon Bedrock を、英語と日本語の比較を中心に検証しました。

• セットアップは実質 tools への 1 行追加で、公式ブログのコードがそのまま動いた

• 今回選んだ 4 題では、日英とも事実と整合する回答が引用付きで返ってきた

• 検索クエリの言語はトピックに応じて日英が使い分けられた（ただし実行ごとに変わる）。日本語の公式サイト、報道、コミュニティ記事が引用されており、これらがインデックスされていることを確認できた

• モデル自身の知識では誤答した質問（Summit Japan の開催日、日銀の政策金利）が、検索ありでは正しい値になり、グラウンディングの効果がはっきり確認できた

• 利用前に知っておきたいのは、Responses API 専用であること、US リージョン限定であること、external_web_access のデフォルト値と IAM 権限の食い違いの 3 点

外部の検索プロバイダーとの契約なしに、既存の Bedrock の認証と権限管理の枠内でグラウンディングを追加できるのは、構成としてかなり導入しやすいと感じました。

今回試した範囲では日本語の質問にも引用付きで妥当な回答が返ってきたので、社内のユースケースでも試す価値がありそうです。

東京リージョン対応と、Claude をはじめとする他モデルへの展開に期待しつつ、続報を追いかけていきます。

脚注

• Amazon Nova 系には Web Grounding という別のグラウンディング機能が 2025 年 10 月から提供されています（Web Grounding for Nova models）。本記事で扱う Web Search とは別機能です。 ↩︎