shirokuronoir

AI検索を仕事で使う前の5確認

AI検索を仕事で使う前の5確認

AIエージェントへWeb検索を足せば、最新情報に強くなるように見えます。しかし、検索できることと、仕事で信用できる回答を返せることは別です。検索語に機密情報が混ざる、古いページを引用する、社内情報と公開情報を混同する、といった失敗は検索機能だけでは防げません。

先に結論

Web検索を仕事へ入れる前に、次の5点を決めます。

1. 検索クエリへ入れてよい情報

2. 公開Webと社内データの使い分け

3. 検索対象ドメインと引用ルール

4. 認証、費用、停止条件

5. 正解だけでなく失敗を測る評価セット

AWSはAmazon Bedrock AgentCoreのWeb Search Toolを、Gatewayへ接続するMCP互換の管理型コネクタとして案内しています。検索基盤や外部APIキーを自前で管理しなくてよい一方、どの質問を検索へ出し、どの結果を採用するかは利用側の責任です。

今回、公式情報で確認したこと

AWS公式ドキュメントでは、Web Search Toolは公開Webの最新情報を取得し、タイトル、URL、スニペット、公開日を返す機能として説明されています。AgentCore Gatewayへ`connectorId: “web-search”`のターゲットを追加し、MCPクライアントから通常のツールとして呼び出します。

検索クエリはAWSの管理する基盤内で処理され、第三者の検索エンジンへ送られない設計だと説明されています。また、対象ドメインを絞る設定も用意されています。

ただし、この記事では手元のAWSアカウントへWeb Search Toolを導入していません。実測の速度や請求額を示す記事ではなく、AWS公式ブログと開発者ガイドを照合し、導入前に決める項目を整理しています。

1. 検索クエリへ入れてよい情報を決める

検索結果だけでなく、検索語そのものがデータです。顧客名、未公開製品名、障害の内部情報、認証情報をそのまま検索へ渡さないルールを決めます。

例えば「顧客Aの契約トラブルに似た事例」ではなく、「SaaS契約の更新失敗に関する公開事例」のように、固有情報を一般化して検索します。検索前に個人名、メールアドレス、注文番号、秘密値を除く処理を挟むと、プロンプトだけに頼らず境界を作れます。

長期APIキーをエージェントへ渡さない考え方は、AIエージェントに長期APIキーを渡さないでも整理しています。Web検索も認証境界の外へ出さないことが重要です。

2. 公開Webと社内データを分ける

Web Search Toolは公開Webの最新情報を探すための機能です。社内規程、顧客契約、手順書の正解を探す用途とは分けます。AWSも、所有する企業データにはKnowledge Bases、公開Webの現在情報にはWeb Search Toolという使い分けを説明しています。

質問を受けたら、まず「社内の正解が必要か」「公開情報が必要か」を分類します。両方が必要な場合は、回答内で社内根拠と公開根拠を分けて表示します。混ぜたまま要約すると、どちらが正式な判断材料か分からなくなります。

3. 対象ドメインと引用ルールを決める

検索結果の上位だから信頼できるとは限りません。製品仕様は公式ドキュメント、法律や制度は所管機関、障害情報は公式ステータスページを優先するルールを作ります。

特定業務では、検索対象を許可ドメインへ絞ります。回答には最低でもページ名、URL、確認日を残し、数値や仕様を使う場合は該当ページを開いて本文と一致するか確認します。スニペットだけで断定しないことが重要です。

4. 認証、費用、停止条件を決める

管理型ツールでも、GatewayのIAM権限、呼び出せるエージェント、ログの保存範囲は設計が必要です。全エージェントへ一律に検索権限を与えず、必要なワークフローだけに接続します。

費用は「1回の検索単価」だけでなく、1質問あたりの検索回数、再検索、モデル入力トークンまで含めて測ります。1質問で許可する検索回数、タイムアウト、月次上限を決め、超えた場合は検索なしの回答か人手確認へ戻します。

処理時間とエラー分類は、AIエージェントが遅い時に見る5項目の監視表へ追加できます。

5. 失敗を含む評価セットを作る

正解が見つかる質問だけでは評価になりません。少なくとも次の5種類を用意します。

  • 公式情報が1件だけある質問
  • 複数の公式情報が食い違う質問
  • 古い記事が上位に出やすい質問
  • 信頼できる情報が見つからない質問
  • 検索してはいけない機密情報を含む質問

評価するのは回答の自然さではなく、一次情報を選べたか、URLが実在するか、日付が新しいか、見つからない時に断定を避けたかです。検索結果が0件の時に、架空の出典を作らず止まれることも成功条件に含めます。

30分で作る導入前チェック表

| 項目 | 決めること | 記録する値 |

|—|—|—|

| クエリ | 削除する機密情報 | 除外件数 |

| データ | 公開Webか社内情報か | 利用した経路 |

| 出典 | 優先ドメイン、確認日 | 一次情報率 |

| 実行 | 回数、時間、月次上限 | 検索回数、費用 |

| 品質 | 見つからない時の停止 | 誤引用、未回答率 |

最初から全業務へ入れず、更新情報の確認など、正解を人が検証しやすい1用途から始めます。5件から10件の質問を固定し、設定変更前後で同じ質問を再実行します。

今日から行う3つの作業

1. 検索前に除く個人情報、秘密値、社内固有語を列挙する

2. 公式サイトを優先する許可ドメイン一覧を1用途分だけ作る

3. URL、公開日、確認日、検索回数を同じログへ残す

検索を追加した後も、公開や業務判断の最終確認は残します。AI記事制作、最後に人が見る3項目の確認手順も、出典確認へ応用できます。

まとめ

Web Search Toolの価値は、AIへ最新の公開情報を渡しやすくすることです。一方で、検索語の安全性、社内データとの分離、引用の正確さ、費用上限、失敗時の停止は自動では決まりません。

まず1用途、許可ドメイン、固定質問、停止条件を決めます。検索できた件数より、一次情報を正しく示し、見つからない時に止まれた割合を重視してください。

関連記事

著者情報

しろのあ。AIとCodexを使ったWordPress、note、アプリ制作、ゲームサーバー運用の自動化を実践し、確認できた手順と判断材料を記録しています。

出典

1. Introducing Web Search on Amazon Bedrock AgentCore / AWS

2. Web Search Tool / AWS Documentation

3. Use a tool to complete an Amazon Bedrock model response / AWS Documentation

4. Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases / AWS Documentation