2026.10.10 AI

Bedrock Web Searchとは：GPT-5.6で引用付き回答を返す設定とIAM・料金

Q: external_web_accessはtrueとfalseのどちらにすべきですか？

機密を扱う可能性があるなら false を明示します。キャッシュ済みのページは読めるため、多くの質問はこれで答えられます。 true にするのは、公開直後の資料のようにキャッシュに無いページを読む必要があり、かつ ExternalWebAccess 権限を付けた専用ロールで動かす場合だけです。省略すると既定の true になり、権限が無ければFetchが無言で失敗します。

Bedrock Web Searchとは：GPT-5.6で引用付き回答を返す設定とIAM・料金

Bedrock Web Searchは、Amazon Bedrock上のOpenAI GPTモデルが、AWSの運営するWeb索引を検索して引用付きで答えるための組み込みツールです。2026年8月4日に一般提供が始まり、8月19日には外部のWebページを直接取得するexternal_web_accessが加わりました。この記事では2026年10月時点の公式ドキュメントをもとに、検索とページ取得（Fetch）の仕組み、対応モデルと米国3リージョンという提供範囲、OpenAI SDKでの実装、IAM権限の組み合わせで起きる無言の失敗、1,000クエリ12ドルの料金を整理し、採用する案件と見送る案件を線引きします。

まとめ：Bedrock Web Searchは米国リージョンのGPTで使う検索の部品

使える条件は狭く、bedrock-mantleエンドポイントのResponses APIから、GPT-5.6 Sol・Terra・LunaとGPT-5.4・GPT-5.5の5モデルを呼ぶ場合に限られます。東京リージョンでは提供されておらず、ClaudeやNovaでは使えません。

実装はツール配列にweb_searchを1行足すだけです。ただしexternal_web_accessの既定値はtrueで、AmazonBedrockFullAccessには外部取得の権限が含まれません。この組み合わせではページ取得が失敗したまま応答だけが200で返るため、AWSの外にデータを出さない案件はfalseを明示します。

採用するのは、公開情報の鮮度が回答の質を決める社内アシスタントや調査エージェントです。社内文書の検索が主役の案件や、国内での処理が契約条件になっている案件では、Knowledge BasesのRAGを選びます。

Bedrock Web Searchの検索とFetchで引用付き回答が作られる仕組み

最初に、このツールがどこを検索し、何を返すのかをそろえます。外部APIを自前で呼ぶ検索とは、データの通り道が異なります。

AWSの運営するWeb索引から答えるサーバー側ツールとしての位置づけ

AWSのWeb Searchのユーザーガイドによると、Web SearchはAWSが構築・運営する組み込みツールで、検索索引やクローラーを利用者が持つ必要がありません。リクエストのツール配列に加えると、モデルが最新情報の要否を判断し、必要なときだけ検索を実行します。

検索結果の1件は「観測結果」と呼ばれ、タイトル・URL・本文の抜粋で構成されます。モデルは結果が足りなければ同じターンの中で検索語を組み替えて再検索し、根拠が見つからない場合は学習データで穴埋めせず、その旨を答えます。

ツール呼び出しのループをアプリ側で書かずに済む点が、自前の検索APIをFunction Callingでつなぐ構成との違いです。

検索とページ取得の役割の違いとexternal_web_accessが効く範囲

Web Searchの中身は2つの操作です。役割を取り違えると、権限設計を誤ります。

操作	取得元	返すもの	external_web_accessの影響
検索	AWSのWeb索引	タイトル・URL・抜粋	受けない（常に索引から）
Fetch（false）	AWSのキャッシュのみ	指定URLのページ内容	AWS境界の外へ出ない
Fetch（true）	キャッシュ優先、無ければ外部Web	指定URLのページ内容	キャッシュに無いときだけ外へ取りに行く

external_web_accessが左右するのはFetchだけです。検索は設定に関わらずAWSの索引とナレッジグラフから返るため、falseにしても検索そのものは止まりません。

2026年6月のAgentCore版から8月の外部取得追加までの提供経緯

同じ名前の機能が2つあるため、時系列で区別します。2026年6月16日に、AgentCore向けのWeb SearchがAgentCore GatewayのMCPコネクタとして一般提供されました（バージニア北部のみ）。

続いて8月4日、Bedrockの推論APIから使えるWeb Searchが一般提供になりました。この時点のFetchはキャッシュからの取得だけで、AWSの発表ブログも外部Webの直接取得は今後の更新で有効化するとしていました。

その更新が8月19日の外部Webアクセスの追加です。8月4日時点の情報だけを読むと「データはAWSの外に出ない」と理解しますが、現在は既定値がtrueで、権限を付ければ外へ出る経路が開きます。

Bedrock Web Searchの対応モデル5種と米国3リージョン限定の提供範囲

導入の検討で最初に当たる壁は、使えるモデルとリージョンの狭さです。

GPT-5.6 Sol・Terra・Lunaなど5モデルへの対応とClaudeの対象外

Web Searchのユーザーガイドに載る対応範囲は、2026年10月時点で次のとおりです。

区分	リージョン	対応モデル
米国の商用リージョン	バージニア北部・オハイオ・オレゴン	GPT-5.6の3種とGPT-5.4・5.5
AWS GovCloud（US）	us-gov-west-1	5.6のTerra・Lunaと5.4

リージョンコードはus-east-1・us-east-2・us-west-2、モデルIDはopenai.gpt-5.6-terraやopenai.gpt-5.4の形式です。

Anthropic・Amazon・Metaなど、OpenAI以外のモデルは対象外です。Bedrock上のClaudeは、Web検索を含むサーバー側ツールに対応していません（呼び出し経路の違いはBedrock Claudeの使い方：Messages API・InvokeModel・Claude Codeの設定で整理しています）。Claudeで最新情報を扱うなら、検索APIをクライアント側のツールとして自前でつなぎます。3つのGPT-5.6の性格の違いはGPT-5.6とは｜Sol・Terra・Lunaの3モデルを参照してください。

Web検索に必須のbedrock-mantleとResponses APIの接続条件

BedrockのResponses APIで選べる入口は2つです。AWSのResponses APIのページは新規アプリにbedrock-runtimeを推奨していますが、同じページで、サーバー側ツールはbedrock-runtimeでは使えないと明記しています。Web Searchを使う処理だけはbedrock-mantleに向けます。

もう1つの注意はURLのパスです。bedrock-mantleはモデルによってパスの接頭辞が/v1と/openai/v1に分かれ、Web Searchのサンプルは/openai/v1を使います。接頭辞を誤ると「isn’t supported on this route」で拒否されるため、モデルカードのProgrammatic Accessの表でベースURLを確かめます。Converse・InvokeModelからは使えません。

東京リージョン非対応で日本のデータが米国で処理される点の判断

Web Searchは厳密にリージョン単位で動き、検索語・取得・索引・結果は他のリージョンへ回されません。裏返すと、日本から使う場合は米国のリージョンへ直接リクエストを送ることになり、プロンプトも検索語も米国で処理されます。

国内処理の要件がある案件では、ここが採否を分けます。GPT-5.6には日本のjp.推論プロファイルもありません。個人情報や顧客の非公開情報をプロンプトに含む業務は、東京リージョンで提供が始まるまで対象から外す判断が妥当です。公開情報だけを扱う調査用途なら、米国処理を前提に設計して問題ありません。

OpenAI SDKによるBedrock Web Searchの環境設定とPython実装

以下は公式ドキュメントのサンプルを組み合わせ、引用の取り出しとデータ保持の設定を加えたコード例です。

短期APIキーとbedrock-mantleのベースURLを設定する準備コマンド

OpenAI SDKからBedrockを呼ぶには、OpenAIのAPIキーではなくAmazon BedrockのAPIキーを使います。APIキーのページによると、短期キーは最長12時間で、発行したIAM主体の権限を引き継ぎ、本番での利用が推奨されています。長期キーは検証用です。

# OpenAI SDK と短期キーの生成ライブラリを入れる
pip install -U openai aws-bedrock-token-generator

# Web Search は米国リージョンのみ。キーの発行と呼び先のリージョンをそろえる
export AWS_REGION=us-west-2
export OPENAI_BASE_URL="https://bedrock-mantle.us-west-2.api.aws/openai/v1"

# 呼び出す主体の確認（IAMロールやSSOプロファイルで認証しておく）
aws sts get-caller-identity

OpenAIのベースURL（api.openai.com）を残したままにすると、リクエストはBedrockではなくOpenAIへ直接届きます。環境変数の取り違えは、データの送り先が変わる事故につながるため、CIの設定でも明示的に上書きします。

web_search追加と引用url_citation取得のPython実装例

ツール配列にweb_searchを加え、応答の注釈から出典を取り出します。

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

# 短期キーは provide_token() が期限内ならキャッシュを返し、切れていれば作り直す
client = OpenAI(api_key=provide_token())  # ベースURLは OPENAI_BASE_URL から読む

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    input="Amazon Bedrock の今月の主な発表を、日付付きで3件挙げてください",
    tools=[{
        "type": "web_search",
        "search_context_size": "low",   # 観測結果は最大5件。単純な質問はここから始める
        "external_web_access": False,   # 取得をAWSの索引とキャッシュに閉じる
    }],
    store=False,  # 既定の true だと入出力が30日保存される
)

print(response.output_text)

# 出典（画面に必ず表示する）
for item in response.output:
    if item.type == "message":
        for block in item.content:
            if block.type == "output_text":
                for ann in block.annotations:
                    if ann.type == "url_citation":
                        print(f"- {ann.title}: {ann.url}")

# モデルが実行した検索・ページ取得の記録（取得の失敗はここに出る）
for item in response.output:
    if item.type == "web_search_call":
        print(item.status, getattr(item.action, "type", None))

注釈url_citationには、出典のタイトル・URLと、回答本文のどの文字範囲を裏付けるかが入ります。Web Searchのユーザーガイドの利用条件は、エンドユーザーに出す画面で出典とリンクを保持・表示することを求めています。出典を捨てて回答文だけを表示する実装は、この利用条件に反するものです。

ストリーミングでは本文がresponse.output_text.delta、出典がresponse.output_text.annotation.addedのイベントで届きます。

search_context_sizeの3段階で入力トークンと網羅性を調整する基準

search_context_sizeは、1回の検索でモデルに渡す観測結果の上限を決めます。lowは最大5件、既定のmediumは最大11件、highは最大25件です。

観測結果はモデルの入力トークンになるため、上限を上げるほどトークン料金も増えます。この設定は検索の回数を制限しません。社内のFAQボットのように1つの事実を確かめる用途はlow、複数の情報源を突き合わせる調査はhighから試し、回答の質と1件あたりの費用を見比べて決めます。

IAM権限とexternal_web_accessの設定によるFetchの無言の失敗

Web Searchで最も事故につながりやすいのは、IAMとパラメータの組み合わせです。エラーが返らないため、気づかないまま運用に入ります。

AmazonBedrockFullAccessでは外部取得が拒否される4通りの組み合わせ

AWSのWeb SearchのIAMページによると、アクションはbedrock-websearch:InvokeSearch・InvokeFetch・ExternalWebAccessの3つです。AmazonBedrockFullAccessなど汎用の管理ポリシーには前の2つだけが追加され、ExternalWebAccessは含まれません。

ExternalWebAccess権限	external_web_access	Fetchの結果
なし	true（既定）	キャッシュを読む前に認可で失敗
なし	false	キャッシュから取得
あり	false	キャッシュから取得
あり	true	キャッシュ優先、無ければ外部Webから取得

1行目が落とし穴です。パラメータを省略するとFetchは毎回失敗しますが、リクエスト全体はHTTP 200で完了し、モデルは検索の抜粋だけで答えます。classmethodの公開検証記事でも、この組み合わせではページ取得の記録がfailedになる一方、応答のerrorはnullのままでした。引用が付いていても、そのページを読んだ証拠にはなりません。

外部取得を許したときのデータ持ち出しリスクとSCPで止める設定

Web Searchのユーザーガイドは、external_web_accessをtrueにするとデータ持ち出しのリスクが生じると警告しています。エージェントが問い合わせ内容をURLに埋め込み、そのURLを外部から取得しようとする経路があるためです。

もう1つ見落としやすいのは、InvokeSearchを拒否しても参照先を絞れない点です。Fetchはモデルが自分で作ったURLにも働くため、検索だけ止めてもページ取得は続きます。組織全体で止めるための設定は、IAMページの例どおりbedrock-websearch:*をSCPで拒否する形です。リージョンで絞る場合は、条件キーaws:RequestedRegionを使います。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowWebSearchCachedOnlyInOregon",
      "Effect": "Allow",
      "Action": [
        "bedrock-websearch:InvokeSearch",
        "bedrock-websearch:InvokeFetch"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "us-west-2" }
      }
    }
  ]
}

このポリシーは検索とキャッシュ取得をオレゴンだけで許し、外部取得の権限は与えません。外部取得を許す管理ポリシーにはReadOnlyとFullAccessの2つがありますが、IAMページによると現行版の実効権限は同一で、ReadOnlyという名前でも外部取得は制限されません。名前で選ばず、必要なら独自ポリシーを書きます。

CloudTrailデータイベントのfetchedSourcesで取得元を監査する方法

Fetchの成否と取得元は、モデルの応答ではなくCloudTrailで確かめます。AWSのWeb Searchの監視ページによると、記録はデータイベントとして残り、既定では無効で、有効にすると追加料金がかかります。

InvokeFetchのイベントには、実際の取得モード（USE_CACHE_ONLYかUSE_CACHE_WITH_EXTERNAL_WEB_FALLBACK）、URL数、取得できなかったURL数、fetchedSourcesとしてキャッシュと外部Webそれぞれの件数が入ります。権限不足で拒否されたFetchはAccessDeniedとして残ります。一方で、検索語・URL・検索結果の本文は記録されません。「外部へ何回出たか」は追えても「何を調べたか」は追えない点を、監査要件と突き合わせておきます。

1,000クエリ12ドルの検索料金とトークン課金を合わせた費用の見積もり方

費用は、検索の回数にかかる料金とモデルのトークン料金の2本立てです。

検索料金の単価とFetchの本文でトークンが倍近くに増える例

Amazon Bedrockの料金ページは、Web Searchを検索リクエスト1回ごとの課金としています。AWSのPrice List APIで2026年10月6日版のオレゴンの単価を確認すると、1,000クエリあたり12.00ドル（1回0.012ドル）でした。1つの質問でモデルが3回検索すれば3回分かかります。

見積もりで外しやすいのはトークン側です。前述のclassmethodの検証では、同じ天気の質問で、ページ取得が発生した回は約24,451トークン、発生しなかった回は約12,700〜14,500トークンでした。Fetchの有無で入力が倍近くに増えるため、PoCではusageを記録し、1問あたりの実額を検索料金と分けて集計します。モデル別のトークン単価の試算はAWS Bedrockの料金と月額試算で扱っています。

store既定trueで応答が30日保存される点とデータ保持の設定

Responses APIのstoreは既定でtrueで、Responses APIのページによると、入力と出力を含む応答が30日間保存されます。previous_response_idで会話を続けるにはこの保存が前提です。

保存を避けたい業務では、リクエストごとにstore=Falseを指定するか、アカウントのデータ保持モードをnoneにします。noneにすると明示的なstore=trueは拒否されるため、会話を継続する機能は履歴をアプリ側で持つ設計に切り替えます。

Bedrock Web Searchを採用する案件と見送ってRAGを選ぶ案件の判断

ここまでの仕様を踏まえて、採否を言い切ります。

公開情報の鮮度が回答品質を決める社内アシスタントには採用する

採用するのは、製品の新版・料金・規制の動向など、公開Webにある情報の鮮度で回答の価値が決まる用途です。開発者向けの調査アシスタント、営業向けの競合動向の要約、運用チームのリリース情報の確認がこれに当たります。検索事業者との契約・APIキー管理・第三者の審査が不要になり、権限と監査をIAMとCloudTrailにまとめられる点は、自前で検索APIをつなぐ構成より明確に有利です。

ただし前提は3つです。プロンプトに機密を含めないこと、米国での処理を許容できること、出典を画面に表示する設計にすることです。どれか1つでも満たせないなら採用しません。

社内文書を主な検索対象とする案件や国内処理が条件の案件での見送り判断

社内規程や契約書など、非公開の文書から答えさせたい案件にWeb Searchは向きません。この用途はKnowledge BasesのRAGが正解で、東京リージョンで組めます。設計の違いはナレッジベースとRAGの違い、実装はAmazon BedrockでRAGを実装する手順にまとめています。

国内での処理が契約条件なら、現時点では見送りです。Claudeを使い続けたい案件も、Web SearchのためだけにGPTへ乗り換える理由にはなりません。エージェント基盤をAgentCoreで組むなら、Gateway経由のAgentCore版Web Searchを比べます（基盤の使い方はAmazon Bedrock AgentCore APIの使い方）。

Web検索とRAGを1つのアシスタントに同居させる設計や、IAM・SCP・監査ログまで含めた社内展開の進め方に迷う場合は、生成AI導入支援で要件の整理から対応しています。

Bedrock Web Searchの対応範囲・権限・料金でよくある質問

Bedrock Web Searchの検討段階で出やすい質問に、2026年10月時点の公式ドキュメントで答えます。

Bedrock Web SearchはClaudeやNovaのモデルでも使えますか？

使えません。対応しているのはOpenAIのGPT-5.6 Sol・Terra・Luna、GPT-5.4、GPT-5.5の5モデルだけです。Bedrock上のClaudeはWeb検索を含むサーバー側ツールに対応していないため、最新情報を扱うには検索APIをクライアント側のツールとしてつなぐ構成になります。モデルの選び分けはAWS Bedrockのモデル選定で比べています。

東京リージョンからBedrock Web Searchを使えますか？

東京リージョンでは提供されていません。商用で使えるのはバージニア北部・オハイオ・オレゴンの3リージョンです。日本のアプリからこれらのリージョンへリクエストを送れば動きますが、プロンプトと検索語は米国で処理されます。国内処理が要件の業務には使わず、公開情報だけを扱う用途に限ります。

external_web_accessはtrueとfalseのどちらにすべきですか？

機密を扱う可能性があるならfalseを明示します。キャッシュ済みのページは読めるため、多くの質問はこれで答えられます。trueにするのは、公開直後の資料のようにキャッシュに無いページを読む必要があり、かつExternalWebAccess権限を付けた専用ロールで動かす場合だけです。省略すると既定のtrueになり、権限が無ければFetchが無言で失敗します。

Bedrock Web Searchの料金は何にどれだけかかりますか？

検索1回ごとの料金と、モデルのトークン料金の合計です。オレゴンの検索料金は2026年10月6日版の価格データで1,000クエリあたり12.00ドルでした。検索結果やページ本文はモデルの入力に入るため、search_context_sizeを上げたりFetchが走ったりするとトークン料金が増えます。CloudTrailのデータイベントを有効にする場合は、その料金も別にかかります。

AgentCoreのWeb SearchとBedrockのWeb Searchは何が違いますか？

両者の違いは呼び出しの入口です。AgentCore版は2026年6月16日にAgentCore GatewayのMCPコネクタとして一般提供され、エージェントがツールとして呼びます。Bedrock版は8月4日に一般提供され、Responses APIのツール配列にweb_searchを加えてモデルに使わせます。AgentCoreでエージェントを組むなら前者、GPTモデルの推論APIに検索を足すだけなら後者です。