目次
は2026年11月5日、Amazon Bedrock AgentCoreのWeb Answerを一般提供しました。自然文の質問を渡すと、検索、関連ページの読解、回答の作成までをAWS側で行い、出典付きの回答をの1回で返します。既存のWeb Search Toolは、検索順位付きの結果を返し、その先の判断を呼び出し元に委ねる機能です。公開ドキュメントの特定の疑問に答える機能を作るなら、まずこの戻り値の違いから選べます。発表時の提供は米国東部（バージニア北部、us-east-1）です。AWS：Web Answerの一般提供発表
たとえば、サポート画面で「移行先のはこの実行環境をサポートするか」を確認するなら、Web Answerで公式資料のリンクを添えた回答を得る方法があります。一方、複数ベンダーの変更を収集して自社の対応表と突き合わせるなら、Web Searchで候補を取得し、どの資料を採用するかをアプリ側で決める方が向いています。以下ではAWSの公開仕様と、サポート機能を想定した本サイトの設計案を分けて説明します。応答時間や回答精度は実測していません。
スポンサーリンク
回答の作成を任せる範囲を決める
Web Answerは質問ごとに検索を計画し、複数の検索を並列に実行し、関連ページを読んで回答を組み立てます。呼び出し側で検索回数や選んだページごとの読解手順を構成する必要がありません。公開情報を答える処理をエージェント全体から切り離せるため、チケットの分類、顧客ごとの契約判定、回答文の整形といった自社固有の処理に開発を集中できます。ただし「ツール呼び出し1回」はアプリとGatewayの間の話で、内部の検索が1回で終わることや、全体の待ち時間が一定であることを意味しません。
Web Search Toolはタイトル、URL、関連箇所の抜粋、公開日などを返します。たとえば複数の告知を版や提供地域で分類したり、同じ告知の転載を除外したりするなら、その候補を保持できることに価値があります。抜粋だけで根拠が足りない場合の原文確認、選んだ資料の優先順位、最終回答の生成はアプリ側の設計になります。Web Searchがページの完全なHTMLを返す前提で実装しないでください。AWS開発者ガイド：Web Search Tool
両方を使うなら、最初から自由に選ばせるより、質問を三つに分けるところから始めます。公開資料から単一の事実を確認する質問はWeb Answer、候補の比較や一覧作成はWeb Search、契約ごとの上限や利用者の状態などは自社データへ送ります。同じ質問に毎回二つのツールを動かすと、どちらが回答に貢献したか測りにくくなります。最初の試験では分岐を記録し、後から誤った振り分けと検索後の失敗を分けて集計します。
Gatewayに接続して応答形式を確認する
Web AnswerはAgentCore Gatewayに組み込みコネクターのターゲットとして追加します。AWSの構成例では、受信側がAWS を使うGatewayをus-east-1に用意します。呼び出し元の権限はGatewayに対する bedrock-agentcore:InvokeGateway、GatewayのサービスロールはWeb Answerに対する bedrock-agentcore:InvokeWebAnswer です。役割が違うため、接続できても呼び出しが拒否される場合は、受信側とコネクターへの呼び出し側のどちらで失敗したかを確認します。AWS技術ブログ：Web Answerの設定と料金
ターゲット設定では connectorId に web-answer を指定し、GatewayのIAMロールを利用します。ターゲットが READY になったら、MCPの tools/list で対象名と入力を確認します。ツール名はターゲット名に ___WebAnswer が付いた形です。Gatewayのセマンティック検索を有効にすると、ツール検索用の項目が先頭に来ることがあるため、配列の順番ではなく設定済みのターゲット名で選びます。複数のWeb Answerターゲットを置く場合も同じ方法で区別できます。
次に tools/call で質問を一つ送ります。最初はフィルターなしで、正解と出典が分かっている公開情報を使い、応答の isError、本文、引用URLが扱えることを確認します。疎通とフィルターを同時に試すと、回答が得られない原因を切り分けにくいためです。ツールのエラーと、呼び出し元のタイムアウトや通信エラーも別の結果として扱います。最初の表示までに間に合わない場合に備え、引用を伴わない即答へ自動で切り替えるのではなく、確認中または未確認と示す表示を用意します。
スポンサーリンク
フィルターは対象版と資料の範囲から設計する
コネクター1.1.0以降では、管理側での許可・除外を設定し、リクエストでさらに範囲を絞れます。両方の許可リストを設定したときは共通の範囲に限られ、共通項がない場合は入力の検証エラーになります。除外はどちらかに含まれれば適用されます。ルートドメインの指定はにも一致します。1.0.0の呼び出しスキーマでは query だけが使えるので、最新のガイドを読んだだけでフィルターを送らず、実際に検出したスキーマも照合します。AWS開発者ガイド：Web Answerの入力と出力
製品の現行仕様を調べる例では、まず提供元のドキュメントや公式リリースを候補にして、質問には製品名、対象版、知りたい仕様を入れます。たとえば「製品Aのメジャー版3で、接続方式Bはセルフホスト版でも使えるか。条件と例外を公式資料で確認してほしい」とします。説明の見た目が似ている版とセルフホスト版を取り違えやすいので、出典が同じ提供元でも、リンク先がどの提供形態を対象にしているかを確認します。
公開日フィルターの from と to は境界を含み、で扱われます。日付だけで to を指定するとその日全体が含まれます。日本時間で「昨日の新着」を集める要件なら、アプリ側で時刻の境界を決めてオフセットを明示します。一方、旧版から存続している仕様や、公開日は古くても更新されたページを確認する場合、短い公開日フィルターを常用すると必要な資料が外れます。新着探索と現行仕様確認で設定を分け、範囲を変更した試行があれば記録します。
userLocation.country は検索結果を地域に合わせるための指定です。提供リージョンを切り替える設定ではありません。また、ドメインと期間は検索範囲を狭める指定であって、資料の内容が適用条件に合うことまで保証しません。たとえば発表時の対応地域と、現在の製品仕様に載る対応地域が異なるときは、発表日と確認日を区別し、最新の公式一覧で判断します。
引用を画面まで持ち運ぶ
公式ガイドの応答には、引用マーカーを含むMarkdownと、structuredContent.answer の回答ブロックがあります。構造化された回答を使う場合は全ブロックを読み、ブロックごとの本文と出典URLを対応させます。複数ブロックを一つの文字列に結合する前に引用を取り扱うと、別ブロックの同じ番号を誤って同一リンクへ割り当てる問題を避けられます。引用リストは任意項目なので、欠落を想定した分岐も必要です。
AWSの利用条件では、Web Answerの結果を使った出力を利用者に提示するときに、その結果の引用とリンクを保持して表示する必要があります。チャット本文では見えるのに、通知やチケットの要約を作ると消える設計では、この要件を満たせません。画面、通知、エクスポートなど結果を使う経路を一覧にして、同じ回答・出典の組を渡せるかを確認します。原文にある引用を単なるドメイン名の列へ置き換えず、読者が該当ページを開けるようにします。
本サイトの提案は、モデルによる要約を後段で行う場合も、文章に対応するリンクを表示層で保持することです。例えば、対応するOSの説明と提供地域の説明を一段落にまとめても、どちらの事実がどのページに基づくか確認できる形にします。リンク先が実際には旧版向けだった場合、URLが正常に開くだけでは合格にしません。結論に必要な記述が本文にあり、版や提供形態が一致するところまでを確認の単位にします。
スポンサーリンク
正答と費用を同じ質問セットで比較する
導入試験では、正解が一つの質問、条件で答えが変わる質問、新旧の資料で表現が異なる質問、公開資料では確認できない質問を用意します。開発元の原文を先に読んで、期待する結論と根拠を決めておきます。条件が揃わない場合に回答を保留できるかも評価します。たとえば公式ガイドにクラウド版の情報しかなければ、セルフホスト版でも使えると補わず、対象版の根拠不足として扱えるかを見ます。
Web Answerと、Web Searchから自前で回答する構成に同じ質問セットを渡します。判定を「結論が正しい」「リンク先がその結論を支える」「指定した版と時点が合う」の三つに分けると、文章はもっともらしいが出典がずれるケースを拾えます。検索対象が見つからない、資料間に矛盾がある、回答は合っているが引用が欠ける、という不合格理由も別々に残します。公開ウェブの内容は変わるため、評価日と参照先も記録します。
AWSの技術ブログでは、Web Answerは1,000ツール呼び出しあたり10米ドルと案内されています。試算では、1万件の問い合わせのうち2,000件で1回ずつ呼ぶならWeb Answer分は20米ドルです。これは単価を当てはめた例で、Gatewayや呼び出し側モデルなどの費用は別です。再試行や質問の分割で呼び出しが増えると金額も変わります。問い合わせ1件あたりの平均だけでなく、出典付きで採用できた回答1件あたりの費用を比較すると、安くても手直しが多い構成を見分けられます。
遅延はツール応答の _meta.latencyMs と、アプリの画面に回答が出るまでの時間を分けて見ます。後者には分岐、モデル処理、出典の組み立て、UIへの送信も含まれます。実運用に近い質問を繰り返し、通常時と遅いケースで待ち時間を確認します。応答が遅い場合に検索工程を替えるべきか、後段でのモデルによる再要約を減らすべきかは、どちらに時間がかかっているかで決まります。
最初の導入先は出典を確認しやすい一機能にする
最初は、公開ドキュメントの対応版や製品仕様を調べるなど、対象資料と正答を人が確認できる機能に絞ります。引用付きの回答をそのまま使える割合が高ければ、Web Answerで検索から回答までを委ねるメリットがあります。逆に、複数候補を比較した履歴が必要だったり、資料の優先順位が自社の基準で決まったりするなら、Web Searchの戻り値から自前で回答を組み立てる方が評価しやすくなります。
公開ページを検索しても、社内ナレッジ、契約書、利用者の権限に応じた情報の代わりにはなりません。顧客ごとの情報が必要なら別のデータ源へ振り分け、公開情報の回答と混ざらないよう表示します。利用者に提示する前に、回答の根拠が追えること、根拠が足りない場合に保留できること、待ち時間と費用を測れることを確かめてから対象を広げます。
関連記事
RAGの回答がずれるときに検索品質を確認する方法。社内文書も扱う場合に、検索結果と回答生成のどちらでずれたかを切り分ける参考になります。
