2026年8月19日、AWSはAmazon Bedrock AgentCoreのWeb Searchツールのアップデートを発表しました。エージェントは呼び出しごとに、結果を信頼できるドメインに絞り込んだり不要なドメインをブロックしたりできるようになり、さらに開始と終了の境界を含む特定の期間に結果を限定できるようになりました。管理者はゲートウェイレベルの許可リストにも対応できるようになり、一つのリストにつき最大100ドメインまで登録できます。また、このツールは当初バージニア北部のみで提供されていましたが、アイルランドと東京にも拡大されました。
プラットフォームの脚注のようにも読めます。しかし実際には、大手プロバイダーが、AIアシスタントについて重要な問いは「回答するかどうか」ではなく、「その回答がどこから来て、いつ書かれたのか」であると認めたということです。この問いは、どのプラットフォームであれ、顧客や従業員の前にアシスタントを置くすべての企業に関わるものです。
ウェブから回答するアシスタントを台無しにする二つの欠陥
アシスタントをオープンなウェブ検索に接続すると、自然には閉じない二つの扉が開きます。
- 信頼していない情報源:モデルは、公式の規制当局のページ、掲示板のスレッド、マーケティングブログ、競合他社のページを区別しません。すべてが単なるテキストです。その結果、あなたの顧客は、あなた自身のビジネスについて、あなたが所有も承認もしていない場所から得た情報を伝えられることになります。
- 正しいが期限切れの情報:こちらのほうが危険です。誤りのようには見えないからです。ある要件、手数料、期限について三年前に書かれたページが、その後要件が変わったにもかかわらず使われるのです。回答は正確で自信に満ちた表現ですが、正しいのはその年についてであり、あなたの年についてではありません。
二つ目の欠陥こそが、日付フィルターがおまけではない理由です。規制が毎年変わる市場では、「これは今年の情報か」のほうが「これは良いサイトの情報か」よりも重要です。
サウジアラビアでの実務上の意味
顧客や従業員からの質問に答えるアシスタントを運用している企業を考えてみましょう。そこに届く問い合わせには、必ず規制に関する事項が含まれます。電子インボイスの要件、ライセンスや契約の条件、政府プラットフォーム内の手順、労働法の条項などです。それぞれに、権威ある情報源はただ一つしかありません。ザカート・税・関税庁(ZATCA)、人的資源・社会開発省、通信・宇宙・技術委員会(CST)、サウジデータ・人工知能庁(SDAIA)です。
当局自身のサイトから回答できるのに、一般的なブログから税務や労務の質問に回答するアシスタントは、知能に問題があるのではありません。設定に問題があるのです。質問の種類ごとに許可する情報源のリストを定めることは、一度行えば済む管理上の判断であり、ベンダーがリリースするのを待つべき機能ではありません。
同じくらい重要な二つ目の側面があります。データの経路です。従業員や顧客の問い合わせ内容が自社のクラウド環境内にとどまるのか、それとも第三者の検索エンジンに送られるのかは、その問い合わせに顧客名、注文番号、契約の詳細が含まれる場合には重大な違いです。個人データを扱うアシスタントを構築する人は、ユーザーが入力するすべての言葉が最終的にどこへ行くのかを正確に把握しておくべきです。個人データ保護法(PDPL)は、意図ではなく経路であなたを判断するからです。
実際にコントロールできる三つの層
Amazonを使っていてもほかのプラットフォームであっても、回答品質をコントロールできるのは三つの層で、強いものから順に次のとおりです。
- まず自社の資料:製品ガイド、価格、ポリシー、承認済みの回答。すでに答えを持っている質問で、アシスタントにウェブ検索をさせるべきではありません。この層で実際の質問の大半が解決します。
- 定義済みの信頼できるドメインのリスト:社内に答えのない規制や市場に関する質問のために、公式サイトを記した短い書面のリストを用意し、四半期ごとに見直します。
- 日付で範囲を限定したオープン検索:一般的な質問のための最後の手段です。鮮度の制約を設け、常にリンクと日付をユーザーに表示します。
実務上のルールはこうです。下の層に行くほど誤りの確率は高くなり、情報源を示すことが不可欠になります。当局のリンクとページの日付を示すアシスタントは、ユーザーを確認者に変えます。情報源なしで自信に満ちた一文を返すアシスタントは、まだ得ていない信頼を求めているのです。
これらのコントロールで解決できないこと
ドメインと日付のフィルターは、情報がどこから来るかを管理するものです。アシスタントがそれを理解したことや、正しく伝えたことを保証するものではありません。現行の公式ページを読んでも誤解を招くように要約したり、一般的なルールを対象外のケースに当てはめたりする可能性は残ります。フィルタリングは誤りの範囲を狭めますが、なくすわけではありません。
だからこそ、二つのことは譲れません。センシティブな質問では人間への明確な引き継ぎを行うこと、そして何が質問され、何が回答され、どの情報源に基づいていたかを後から読み返せるログを残すことです。このログがなければ、顧客が苦情を言うまで、アシスタントが間違っていることに気づけません。
Origamiの見解
私たちはこのアップデートを、アシスタント市場が成熟しつつある兆しと捉えています。第一段階は、誰が最も速く、最も流暢に答えるかを競うレースでした。私たちが今入りつつある段階は、示すことができ、根拠を説明できる情報源から誰が答えるかを競うレースです。その違いこそが、印象的なデモと、顧客の前に置くシステムとの違いです。
今日アシスタントを構築するすべての人への私たちの助言は、上からではなく下から始めることです。まず承認済みの回答を一か所に集め、次に許可する公式情報源のリストを書き、最後に日付の範囲を設けて一般検索を開放します。この順序を逆にすると、よくしゃべるのに出典をほとんど示さないアシスタントになります。それはアシスタントがないよりも悪い状態です。あなたの名前で誤るからです。
結論
ドメインと日付によるフィルタリングは、一つのプラットフォーム内の細部のように見えますが、アシスタントを運用するすべての人に関わる問いを示しています。あなたのアシスタントがどこから回答しているのか、そしてその回答の裏にある情報がいつ書かれたのかを知っていますか。答えが「いいえ」なら、問題はモデルではなく設定にあります。そして解決策は、エンジニアリング上の判断である前に管理上の判断です。まず自社の資料、次に短い公式リスト、そして常にリンクを添えた期間限定の検索です。
出典
よくある質問
情報源を制限することは、自社データでアシスタントを学習させることとどう違うのですか?
アシスタントを自社のドキュメントに接続すると、自社の知識に基づいて回答するようになります。これが第一の、そして最も正確な選択肢です。情報源の制限はもう一方のケースを扱います。社内に答えがなく、アシスタントが外部を調べなければならないとき、インターネット全体を任せるのではなく、どこを調べるかをあなたが決めるのです。この二つは代替手段ではなく、組み合わせて使います。
これを行うには、Amazonのプラットフォームが必須ですか?
いいえ。この考え方はプラットフォームよりも広いものです。構築するどのアシスタントにも、許可された情報源のリストと鮮度の要件を与えることができます。プラットフォームの組み込み機能を使っても、アプリケーション自体に独自のレイヤーを書いても構いません。重要なのは、その判断をモデルに任せるのではなく、文書化してレビューできる状態にしておくことです。
リストには公式情報源をいくつ載せるべきですか?
正解となる数はありませんが、短くて見直されているリストは、長くて放置されたリストに勝ります。自社の事業や顧客からの繰り返される質問に本当に関係する当局から始め、必要に応じて追加してください。数か月ごとに誰も見直さないリストは、やがて安全策ではなく誤りの原因になります。
アシスタントが古い情報源から回答していることは、どうすればわかりますか?
回答ごとに、その根拠となったリンクとページの日付を保存するログを残し、定期的にサンプルを確認することです。そうしたログがなければ知ることはできず、顧客からの苦情で問題に気づくことになります。回答の中でリンクと日付をユーザーに示すと、ユーザーもあなたと一緒に確認するようになるため、第二の保護層になります。
GoogleでOrigamiをフォロー
Origamiを優先ソースに追加すると、Google検索やトップニュースで私たちの記事が優先的に表示されます。








