最終更新: 2026/06/22 18:56
commonid: rq-105-conversation-archive-rag-archit…type: researchstatus: active

会話アーカイブの検索・RAG・分析基盤 — GCP 構成の 3モデル ディープリサーチ統合

調査: 2026-06-16、OpenAI o3-deep-research / Gemini deep-research-preview-04-2026 / Claude opus-4-7(managed-agent)。各 1 回・3社並行。総コスト概算 $6.52(o3 $3.19 / Claude $2.21 / Gemini $1.12)。生結果は rq-105-result-{openai,gemini,claude}.md。 問い: GCS に保全済みの単一ユーザ・多源(Claude Code JSONL ~1,130 セッション + claude.ai chat ~102 会話/2,612 メッセージ、将来 Gemini/ChatGPT)・機密(取引先名・金額)・東京リージョンの会話アーカイブ ~10⁴–10⁵ chunk に対し、検索(全文+意味)と臨時分析を同時に成立させる GCP 構成はどれが最適か。評価軸は「検索・RAG・分析の同時実現」+ 運用容易性 + 拡張性(コストより能力の幅を優先)。

0. 結論(先に要点)

BigQuery を母艦とするハブ構成が妥当(3社一致)。原設計の骨格は通った。ただし機密データの東京リージョン residency を守るための修正が要る。フルスタック(Vertex AI Search 等の managed 層)は実用には不要だが技術検証(GCP RAG スタックの hands-on 学習)を兼ねるため、目的別 2 トラックに分けて扱うのが結論。

1. 3モデルが一致した核心

  1. 検索 + RAG + 分析を 1 箇所で満たせるのは BigQuery のみ。Vertex AI Search は分析ができず、専用ベクトル DB も分析を持たない。BQ は全文 SEARCH() + VECTOR_SEARCH() + SQL 集計を同一ストアで提供する。
  2. 専用ベクトル DB(Vertex Vector Search / Matching Engine)は単一ユーザに不適。インフラ課金が常時発生し(o3/Claude: アイドルでも月 $700+ 規模・最低 2〜3 レプリカ)、sub-100ms の低遅延は個人 RAG に無意味。BQ の 1〜10 秒は MCP/RAG 用途には十分。
  3. ベクトル索引は IVF + STORING(メタ列)+ COSINE。単一クエリ用途には IVF が正解(TreeAH/ScaNN は小バッチで brute-force に戻りうる)。STORING でフィルタ列を索引内に複製し pre-filter する(post-filter は recall が崩壊する)。
  4. hybrid 検索(全文 ⊕ ベクトル を RRF・k=60 で融合)が dense 単独を明確に上回る(o3/Claude: recall@10 が 78% → 91% 級)。生スコアの正規化を避け順位だけを使う RRF は単一 SQL で表現できる。
  5. 正規化は source 付き 1 スキーマ + 無損失 raw JSON 列。chunk は会話ターン群(user + assistant + 隣接 tool 呼び)を一次単位に、長すぎる場合のみ 300–500 トークン窓(50–100 重複)で二次分割。tool 呼びは独立 chunk にしてメタで絞れるようにする。
  6. 全部 asia-northeast1 に閉じる。

2. 相違点と裁定

  • Claude(最も厳格): Vertex AI Search は ML 処理が US/EU でのみ実行=東京 residency を破る。機密会計データには致命的なので「redacted mirror でのみ使え」。
  • Gemini: asia-northeast1 は Vector Search・text-embedding-004(GA)・Agent Platform を備えるが、PAYG の Gemini 推論は global endpoint へ動的ルートされうると警告。厳密 residency には Provisioned Throughput か地域固定モデルが必要。
  • o3: 高品質な Gemini 埋め込みは US/EU マルチリージョンのみ → 東京で埋め込むなら in-region モデルか自前生成を推奨。

裁定: 埋め込みは in-region モデルの明示選択で解決可能(text-multilingual-embedding-002〔日本語可〕/ embeddinggemma-300m〔データが BQ から出ない〕/ text-embedding-004〔Tokyo GA〕)。residency の地雷は Vertex AI Search(managed Q&A)層に集中しており、BQ ハブ本体は東京に完全に閉じられる。

2.2 全文 SEARCH の転置索引は本規模では加速しない

  • Claude の指摘: 全文 SEARCH の転置索引は基底テーブル 10GB 未満では populate されない。~10万 chunk は遥かに下回るので、SEARCH 関数は動くが brute scan になる(機能はするが加速はしない)。一方ベクトル索引は populate される(5,000 行以上 かつ 10MB 以上=両方クリア)。
  • Gemini の対立データ: 「10万行で索引により 5秒→725ms・294GB→60MB」。これは広い(大きい行の)テーブルの例で 10GB 閾値をクリアした事例。本件の小コーパスには当てはまらない。
  • 裁定: 主役はベクトル索引。全文は brute scan で機能的には十分だが加速を当てにしない。hybrid は RRF を単一 SQL で。

2.3 grounded Q&A をどう作るか

  • o3/Gemini は Vertex AI Search の turnkey な引用付き回答(layout parser・ランカー)に強気。
  • Claude は「自前化せよ — BQ hybrid retrieve → Gemini in 東京 → 任意で Vertex Ranking API(stateless で外部候補に使える)+ Check Grounding API」。Vertex AI Search を使うなら redacted mirror のみ。
  • 裁定: 機密・東京固定・単一ユーザの本件では Claude の自前化が residency-safe。Vertex AI Search は「便利だが必須でない」。

3. 原設計への修正(実用最適化)

  1. grounded Q&A は自前化: BQ hybrid retrieve → Gemini in asia-northeast1 → 任意で Vertex Ranking API + Check Grounding。Vertex AI Search はコアから外す(or redacted mirror のみ)。
  2. 埋め込みは in-region モデルを明示選択(text-multilingual-embedding-002 / embeddinggemma-300m / text-embedding-004)。US/EU のみの Gemini 埋め込みは回避。
  3. ベクトル索引 = IVF + STORING(source/date/role 等)+ COSINE。pre-filter で絞る。
  4. 全文 SEARCH 索引の加速は当てにしない(<10GB で非 populate)。
  5. スキーマ = 1 messages fact + 無損失 raw JSON 列・ターン群 + トークン窓 chunk・tool 呼びは独立 chunk。

4. 二目的フレーム — 実用 vs 技術検証(重要)

純粋な「幅 ÷ コスト」最適化なら lean BQ ハブで Vertex AI Search は外す。しかしフルスタックの構築は技術検証(GCP RAG スタックの hands-on 学習)を兼ねる第二の目的を持つ。これを織り込むと「外す一択」ではなく目的別 2 トラックになる:

トラック中身residency機密データ
① 実用(アーカイブ)lean BQ ハブ・in-region・自前 grounded Q&A東京に完全に閉じる本物をここだけで扱う
② 技術検証(学習)Vertex AI Search / grounding / Ranking / managed AgentUS/EU 処理でも可redacted or 合成 mirror(配管検証に本物の取引先名は不要)

規律: (a) 機密コーパスは ① に閉じる、(b) 「実用の出費」と「検証の出費」をラベル分けしてコストを正しい目的に紐づける。こうすれば「technically over-built」が「学習投資」に転じ、residency も汚さない(② に本物データを入れない限り US/EU 処理は検証目的では問題にならない)。② で得た patterns は本番アーキ(CF Workers SaaS / 証憑管理 dogfood)へ転用できる。

5. 推奨ターゲット構成

asia-northeast1 (Tokyo)
GCS(既存・正本) → Cloud Run job(日次) → BigQuery `archive`:
  raw_messages(JSON 無損失) → messages(typed・PARTITION BY DATE(ts)・CLUSTER BY source,conversation_id)
                            → chunks(text + embedding)
                              └ VECTOR INDEX IVF/COSINE STORING(source,role,ts,…)
  derived_facts(AI.GENERATE_TABLE 出力 — 将来の分析用)
Cloud Run `archive-mcp`: BQ MCP server + /retrieve(hybrid RRF) + /answer(Gemini in 東京 + Check Grounding)
   ↑ MCP: Claude Code / 任意の MCP クライアント
[② 技術検証トラック] redacted/合成 mirror に Vertex AI Search を別途(US/EU 可)

6. PoC 手順(Phase 0・①実用トラック)

  1. asia-northeast1 に BQ データセット + 接続。接続 SA に roles/aiplatform.user。
  2. Cloud Run job: GCS → raw_messages / messages(無損失 JSON 列)。
  3. SQL MERGE で chunks 生成(ターン群 + トークン窓ルール)。
  4. in-region モデルで埋め込み(text-multilingual-embedding-002、task_type=RETRIEVAL_DOCUMENT。最強 residency なら embeddinggemma-300m)。
  5. CREATE VECTOR INDEX ... OPTIONS(index_type='IVF', distance_type='COSINE') STORING(...)。
  6. 20 問の golden set で recall@10 を brute force と比較・fraction_lists_to_search を調整。
  7. hybrid RRF のストアドプロシージャ(全文 ⊕ ベクトル)。
  8. BQ MCP server を Claude Code(.mcp.json)に配線 + 自前 Cloud Run MCP(/retrieve・/answer)。
  9. Gemini(東京)回答 + Check Grounding で引用スコア。
  10. (任意・②トラック)redacted mirror 上に Vertex AI Search — 実用では skip 可。

7. 優先順位

  • Must: 東京の BQ データセット / source + tool 構造を持つ正規化スキーマ / in-region 多言語埋め込み / IVF + STORING ベクトル索引 / BQ MCP を Claude Code に配線 / SA の IAM 厳格化・機密の非外部化。
  • Should: hybrid RRF retrieve / 自前 Cloud Run MCP(retrieve・answer)/ Vertex Ranking API による上位再ランク / golden set 評価 / AI.GENERATE_TABLE の派生ファクト / Check Grounding。
  • Nice: ②技術検証トラック(redacted mirror の Vertex AI Search)/ 対話遅延が実害化したらホット埋め込みを Vector Search へ昇格 / Looker Studio ダッシュボード / 日本語トークナイザ調整。

8. 各モデルの寄与と限界

  • o3-deep-research(68KB・最詳細): 決定マトリクス・BQ の制約と運用 gotcha・埋め込みリージョン制約・PoC 手順を網羅。実装の一次資料として最も使える。
  • Claude(12.6KB・最も鋭い): 「全文索引は <10GB で非 populate」「Vertex AI Search は residency を破る」「Vertex Ranking API を単体で BQ 候補に使える」など、本件の制約に直結する非自明な指摘を最短で出した。架構裁定の主軸。
  • Gemini(53KB): 2026 の Gemini Enterprise Agent Platform の課金体系・RRF の数理・residency の動的ルート警告に強い。ただし汎用 agentic RAG エッセイ寄りに drift し決定マトリクスを出さなかったため、architecture 裁定では o3 + Claude を重視し、Gemini は pricing と residency nuance で採用。

参照

  • 調査プロンプト: RQ-105_conversation_archive_rag_architecture_prompt
  • 生結果: OpenAI o3 / Gemini / Claude
  • 関連: 会話アーカイブ正本 = GCS gs://bizlp-claude-conversations(非公開・versioned・日次同期)。次フェーズ = D1 審査 telemetry / git・ADR メタを source 別テーブル + キー join で繋ぐ多源ハブ(本 synthesis のスキーマがその基盤)。