規定はうまく答えるが、業務は答えられないAI
社内文書でRAGチャットボットを作ると、最初はかなり役立ちます。 休暇規定、福利厚生制度、業務マニュアル — 社員の質問にすぐ答えます。 しかし、しばらくすると役員からこのような質問が来ます。 "では、このAIが売上にどんな影響を与えるのですか？"
ここで行き詰まります。 社内文書だけを入れたRAGは会社内のことしか知らないためです。 競合他社が今回いくらで出したか、私たちの新製品のレビュー反応はどうか、市場でどんな話が広まっているか — 事業判断に必要なのはほとんどが会社の外のデータですが、それがRAGに一切ありません。
この記事はRAGを 'つなぐ方法'ではなく'何を入れるか、そしてどうやって古くならないか'を扱います。 技術統合に関するガイドはすでにたくさんありますので、ここでは企画する人の視点から見ます。
外部データがRAGをビジネスツールに変える
同じRAGでも何を入れるかによって答えられる質問の質が異なります。
| 入れたデータ | 答えられる質問 |
|---|---|
| 社内文書だけ | "出張費の規定はどうなっていますか？" |
| + 競合他社の価格・商品 | "競合他社と比べて私たちの価格はどこで負けていますか？" |
| + 顧客レビュー・VOC | "最近の私たちの製品不満はどの項目に集中していますか？" |
| + 市場・ニュース | "今週業界に私たちと関連した問題がありましたか？" |
下に行くほど役員が知りたがる質問であり、すべて外部データが必要です。 RAGの価値はモデルではなく入れたデータの範囲が決定します。
本当の問題は '新鮮さ' です
外部データを入れることに決めたら、次の罠は新鮮さです。 社内規定は数か月ごとに変わりますが、競合他社の価格は毎日変わり、レビューは毎時積み重ねられます。 一度入れて放置した外部データはすぐに有害になります。
- 3か月前の価格で答えるAIは間違った答えを自信を持って言います — 知らないよりも危険です。
- 古い答えが一、二度出ると現場はAIを信用しなくなり、運用サービスはその時点で事実上終了します。
そのため、外部データを入れるRAGは"入れるプロジェクト"ではなく "更新する運用"として設計する必要があります。 鍵は初回のデータ投入ではなく、継続的な更新です。
新鮮さを '収集サイクル' で設計する
新鮮さは単に "頻繁に更新しよう" ではなく、データの種類ごとに必要なサイクルを決定する問題です。
データの性質に応じてサイクルを分ける
- 急速に変化するもの（価格・在庫・ランキング）: 日単位以上の更新が必要です
- 中程度（レビュー・投稿）: 日〜週単位
- 遅いもの（企業情報・カタログ）: 週〜月単位
更新をパイプラインに委任する
決められたサイクルで収集 → 精製 → ベクタDBの更新が自動的に行われる構造を作る必要があります。 人が毎回手作業で入れる方法は数週間持ちません。
古さを検知する
最終更新時刻をデータに記録し、更新が途切れたら通知が届くようにします。 "いつ収集されたデータか"を回答根拠として一緒に表示すると信頼性も向上します。
これらの3つが整うと、新鮮さは管理可能な指標となり、RAGは時間が経っても古くなりません。
精製のない原本はRAGに直接入れない
もう1つ。 クローリングした原本をそのままベクタDBに押し込むと、検索品質が低下します。 重複文書が回答を汚し、形式がバラバラな値は比較できず、多言語レビューはそのままでは検索されません。
そのため、収集とRAGの間に精製レイヤーが必要です。 重複削除、形式の標準化、および感情・分類・翻訳などのAI分析によって原本に構造を与えると、検索が正確になり、フィルタリングも可能になります。 ハッシュスクレーパーは収集したデータにこの精製・分析を重ねてAPI・DBに渡すため、RAGに直接乗せられる形で受け取ることができます。 定期的な収集サイクルがすぐにRAGの新鮮さサイクルとなります。
よくある質問
Q. 外部データ連携は技術的な問題ではないですか？なぜ企画が先か？
連携自体は既存のガイドで解決されます。 しかし、 '何をどのサイクルで入れるか'を間違えると、技術が完璧でも古い答えが出ます。 新鮮さの設計は技術ではなく、企画の決定です。
Q. どれくらい頻繁に更新すればよいですか？
データの性質によって異なります。 価格・ランキングなど頻繁に変動するものは日単位、企業情報など遅いものは週・月単位が基準です。 対象ごとにサイクルを分けて設計すると、コストと新鮮さのバランスをとることができます。
Q. 収集したデータを私たちのベクタDBに直接入れることはできますか？
精製を経れば可能です。 重複削除・形式標準化・AI分析を施したデータをAPI・DBで受け取り、社内パイプラインでベクタDBに格納する構造が一般的です。
一緒に読むと良い記事
- ウェブクローリングデータをRAGに接続する実践ガイド
- AI PoCはなぜデモで止まるのか — 問題はモデルではなくデータ供給網にあります
- 収集したレビューにAI分析を付ける — 感情分析・分類・翻訳でVOCを読む方法
- クローリングデータが意思決定になるまで
今すぐ始める
RAGに入れる外部データが必要ですか？ どのデータをどのサイクルで新鮮に保つか、目的をお知らせいただければ、収集・精製・更新の構造を一緒に設計いたします。
