エージェントにWebを読ませる前に、残す情報と捨てる情報を決める

木曜の夕方、営業のチャットが動きます。

「競合の発表、エージェントに読ませておいた。」 「要約、どこに残した？」 「……会話ログの奥？」

エージェントがWebを読めるようになると、現場の期待は一気に上がります。

最新の価格を見てほしい。 競合の発表を要約してほしい。 公開情報だけで下調べしてほしい。

期待は自然です。 ただ、ここで飛び越えやすいものがあります。

読めることと、残してよいことを同じにすることです。

Googleは2026年7月16日、Gemini Enterprise Agent Platform に Parallel Web Systems による Web grounding を統合した、と開発者向けに発表しています。引用付きでリアルタイムのWeb根拠付けを使う、という導線です。特定サービスの設定解説をするつもりはありません。

先に決めるのは、残す情報と捨てる情報の境界です。

「今読んだ」は、正しさの証明ではない

Webには、公式発表もあれば、古いページも、要約の要約もあります。

エージェントが読めるようになると、次の錯覚が起きやすいです。

今読んだから正しい。 引用があるから使える。 公開情報だから社内に保存してよい。

三つとも、別の判断です。

正しさは、出典の鮮度と範囲の問題です。 使えるかは、自社の用途と責任の問題です。 保存してよいかは、ライセンス、個人情報、キャッシュ方針の問題です。

仕組みを入れる前に、この三つを混ぜないでください。

詰まりは、「調べられない」から別の場所へ移る

Web grounding が入ると、仕事の詰まりは「調べられない」ではなくなります。

次の詰まりに移ります。

どの出典を残すか。 いつ捨てるか。 誰が再確認するか。 顧客に出す文に、どの引用を載せるか。

負荷の移動を設計しないと、現場は全部残します。 全部残すと、あとでどれが信頼できるか分からなくなります。

見える化が進むほど混乱する、という一般の話は別記事に任せます。 こちらは、エージェントの保持ルールに限定します。

機能一覧より先に、三行で足りる

機能一覧を眺める前に、三行で足ります。

残すのは、公式発表のURLと取得日時、要約の結論一行。 捨てるのは、本文の全文コピー、個人が特定できる記載、有料記事の本文。 人が見るのは、顧客提示文、金額・納期、法務に触れる断定。

この三行があると、エージェントは「読む係」になります。 三行がないと、エージェントは「社内倉庫係」になります。

倉庫係になると、検索は速くても、あと始末が重くなります。

渡す前の線引きと、外から入った情報の出口

AIに渡す前の線引きは、AIに渡す前の線引きの主題です。

こちらで足すのは、エージェントが外から取ってきた情報の扱いです。

渡す前の線引きが、内側の守りなら、 保持ルールは、外側から入った情報の出口です。

出口がないと、外の情報が社内にたまります。 たまった情報は、次のプロンプトの材料になります。 材料が増えるほど、出所不明の断定が増えます。

出所不明の断定は、あとから直すほど高くつきます。

誰が書いたか分からない。 いつ取得したか分からない。 どのページの要約か分からない。

この三点が空のまま残る情報は、便利なメモではなく、将来の手戻りです。 だから、残す条件を厳しくしてください。 厳しくするのは、検索を弱くするためではありません。 あとで説明できる状態を残すためです。

購読しただけでは、本番ではない

外部の検索や grounding を購読すると、導入した気分になります。

導入した気分と、本番で使ってよい状態は違います。

本番前に確認するのは、次のような項目です。

利用規約上、どこまで保存できるか。 ログに本文が残るか。 他のモデルへ結果を引き回してよいか。 引用を顧客に出してよいか。 古いキャッシュをいつ無効にするか。

料金やプランの詳細は、その時点の公式ドキュメントで確認してください。 ここでの要点は、購読完了を本番開始にしないことです。

引用がある、で止まらない

引用付き回答は、安心材料に見えます。 実際は、次の確認が残ります。

引用先は一次情報か。 日付は古くないか。 自社の用途に使える範囲か。 顧客にそのまま出してよいか。

引用は、確認の起点です。 確認の終了ではありません。

起点で止めると、エージェントは調べ係から、断定係へ変わります。 断定係になると、人が見る場所が消えます。

人が見る場所を消さないために、残す／捨てる／人が見る、の三行が要ります。

木曜に決める、仕組みの最小セット

仕組みは大きくしなくて構いません。

対象業務を一つ選ぶ。 残す／捨てる／人が見る、を三行で書く。 出典URLと取得日時を必須にする。 顧客提示前の人確認を一つ置く。 捨てるタイミングを週次で決める。

進捗の見え方は、長時間エージェントを入れる前に決める、進捗の見え方に任せます。

こちらは、見える化の前に、残さないものを決める、という順序です。

最小セットを飛ばすと、次の事故が起きます。

調べた内容が、どこに残ったか分からない。 誰かが顧客文に貼る。 出典を聞かれても、会話ログの奥にしかない。

この事故は、検索精度の問題ではありません。 保持ルールの問題です。

だから、強い検索を入れる週ほど、捨てる一行を先に置いてください。

業務で書くなら、この三行

営業の下調べなら。

残すのは、公式発表のURL、発表日、自社への影響一行。 捨てるのは、全文コピー、噂、出典不明の比較表。 人が見るのは、顧客に出す文、価格の断定、競合の評価。

サポートの公開情報確認なら。

残すのは、ヘルプページのURL、確認した時刻、該当手順の見出し。 捨てるのは、フォーラムの個人投稿全文、スクショの個人情報。 人が見るのは、お客様への回答文、補償や返金の言及。

社内調査メモなら。

残すのは、一次情報のリンク、要約三行、未確認事項。 捨てるのは、有料記事本文、ダウンロードした資料の無断保管。 人が見るのは、経営会議へ出す結論、投資判断に使う数値。

三行は、完璧である必要はありません。 決まっていないより、粗い三行のほうが運用できます。週次で見直して、捨てるタイミングだけ直せば足ります。

捨てるタイミングを書かないと、残すが増える

残すルールだけ書くと、現場は安全側に振って全部残します。

だから、捨てるタイミングも一行で置きます。

下調べメモは、案件終了後7日で捨てる。 引用URL一覧は残し、本文抜粋は当日中に捨てる。 顧客提示に使わなかった草案は、週次で捨てる。

捨てられない情報は、残さないでください。 上げた瞬間に、倉庫が始まります。

設計の問いは一つ

エージェントにWebを読ませる前に、残す問いはこれです。

保存してよい情報と、捨てる情報の境界は決まっているか。

決まっていないなら、検索を強くする前に、保持ルールを書いてください。 決まっているなら、その三行をエージェントの前提に置いてください。

前提に置く場所も、難しくしなくて構いません。

エージェントの説明文の先頭。 運用メモの一番上。 案件フォルダの README。

どこでもよいので、読む係が最初に見る場所へ置きます。 置かない三行は、会議で話しただけの三行です。

読めることは、強さです。 残してよいかは、設計です。

エージェントにWebを読ませる前に、残す情報と捨てる情報を決めてください。

決めたあとに増やすのは、検索先ではなく、捨てる習慣です。

残す情報は短く、根拠は追える状態にしてください。翌週の人が同じURLを開けるなら、それで十分です。URLと取得日時をセットで残す。それだけで、会話ログの奥に埋もれる事故は減ります。追えない根拠は、社内メモにも残さないでください。