---
name: project-knowledge-store-dual-sqlite-json-2026-08-14
description: 知識ストアが 2 つある (SQLite STEP 151 dead + JSON research-radar alive) — A/B/C 設計選択肢 pending、 私の推奨は C (JSON=SoT + SQLite=materialized view)、 藤本さん判断待ち
metadata: 
  node_type: memory
  type: project
  originSessionId: d2082c05-0e81-4fc9-9613-331ad2f49b5b
  modified: 2026-08-14T14:42:06.620Z
---

# 知識ストア dual state (SQLite dead vs JSON alive) — 設計判断 pending (2026-08-14)

## 発見された状況

Rei-AIOS には **知識ストアが 2 つ** 存在し、 片方だけが生きている:

| ストア | 場所 | 状態 |
|---|---|---|
| **SQLite (STEP 151)** | `rei-aios.db` の 7 テーブル (arxiv_papers / knowledge_cache / knowledge_fetch_log / wikipedia_articles / wikidata_persons / oeis_sequences / sep_topic_log) | **全て 0 件、 一度も書かれていない** (production writer 呼び出し元ゼロ、 [[feedback-success-signal-decoupled-from-operational-state-2026-08-14]] 例 2) |
| **JSON (research-radar)** | `data/research-radar/arxiv-*.json` + the-conversation / philsci-archive / kalai / n-cat-cafe / hal / doaj / gdelt 等 | **稼働中**、 arxiv 125 件/日 (但し 2026-08-09 以降 4 日停止中)、 他 source は 08-13 まで |

## 選択肢 (A/B/C)

### 案 A: SQLite 知識層を生かす

- research-radar の fetcher から `ArxivCache.save()` 等を呼ぶ配線を追加、 両ストアを一本化
- コスト: 中 (radar fetcher に save 追加、 各 source ごとに schema 統一)
- リスク: 二重管理 (JSON と SQLite が drift 可能)、 手当てが continuous
- 利点: MCP tools の SQL query 力が生きる、 STEP 151 全 investment 生きる

### 案 B: SQLite 知識層を廃用

- MCP tools 側 (`get_knowledge_stats` 等) を research-radar JSON を読む向きに変更
- SQLite テーブル 7 種を明示的に退役 (schema DROP / migration record)
- コスト: 中 (MCP tools 書き換え、 退役 doc)
- リスク: MCP tools が 将来 relational query を要る場合 再構築が必要
- 利点: 単一 pipeline (JSON)、 STEP 1334 で開通した reader は不要になる

### 案 C: JSON=SoT + SQLite=materialized view (推奨)

- `data/research-radar/` の JSON を single source of truth に固定
- SQLite 知識テーブル群は 「JSON から再構築可能な query 用 view」 に格下げ
- 「JSON → SQLite」 rebuild script を用意 (idempotent、 全消し再構築)
- MCP tools は SQLite を読む
- Actions 内で毎日 rebuild + Cache API で持ち回り (or local on-demand rebuild)
- コスト: 小-中 (rebuild script 1 本 + Actions cache 設定)
- リスク: rebuild script の schema drift を watch する必要
- 利点: (i) radar が事実上の SoT に育っているのを追認する形で自然、 (ii) STEP 1334 で開通した KnowledgeApi 8 route reader を捨てずに済む、 (iii) SQLite は rebuild 可能な derived state = gitignore で正しい、 (iv) drift risk なし (JSON が唯一の書き手)

### 「今の中途半端」 が最悪

現状 (テーブルと API は存在、 永遠にゼロを返す) が一番悪い、 は A/B/C の 3 案共通の前提として確定。 藤本さん引用: 「今の中途半端な状態 (テーブルと API は存在するが永遠に 0 を返す) が一番良くない」

## 私 (Claude Code) の推奨 と 未決事項

**推奨: C** (JSON=SoT + SQLite=materialized view)。 A/B は 2 択の対比、 C は radar が SoT に育っている現状を追認する 第 3 の道。

**藤本さん判断が要る点**:
1. A / B / C どれを採るか (設計方針)
2. C 採用時、 rebuild script を いつ・誰が走らせるか (Actions daily / on-demand local / 他)
3. arxiv radar 4 日停止 (2026-08-09 以降) を 同 STEP で扱うか 別 STEP か

## 前提 / 順序

- STEP 1334 (reader 配線) commit 4bbb1ae84 push 済。 A/B/C 判断は commit 完了後の 別 STEP。
- Finding 3 (discovery engine 15 理論ハードコード + 340 件 137 回重複) は 本 STEP と独立、 別 memory / 別判断。 [[project-step1334-knowledge-api-wiring-and-deeper-disconnect-2026-08-14]] 参照。
- arxiv radar 4 日停止も独立、 別 STEP 化推奨。

## 関連

- [[project-step1334-knowledge-api-wiring-and-deeper-disconnect-2026-08-14]] (dual state 発見 origin session)
- [[feedback-success-signal-decoupled-from-operational-state-2026-08-14]] (SQLite writer 未呼出の 欠陥 pattern)
- [[project-session-2026-08-14-step1334-arc-close-state]] (次 session 引継 queue)
- [[feedback-all-research-site-reflection-default]] (site 反映 対応 protocol)
- [[feedback-no-rush-publication]] (急がずゆっくりと、 A/B/C 判断を 焦らない)

## 藤本さん 案 C 支持理由の追加 insight (2026-08-14 追記、 arc close 前)

藤本さん C 同意応答で 私 (Claude Code) が 書けていなかった 重要 insight 提示:

**「C は Finding 2 を『修正』ではなく『消滅』させる」**

案 C 実装後の 帰結:
- SQLite が JSON から derived な view = **gitignore が正しい状態**になる (現状の `*.db` は correct、 workflow が間違っていた)
- `.github/workflows/rei-learning-cycle.yml:126` の `git add rei-aios.db || true` は **修正対象ではなく削除対象**
- 「75MB を git に載せるか」 の問い自体が **消える** (DB は いつでも再構築可能な使い捨て)

これは A/B との real value 差別化 point。 A (SQLite 生かす) では Finding 2 は 「add -f で 強制 track する」 = 75MB を git に載せる方向の 修正が必要、 B (SQLite 廃) では workflow yaml + MCP tool 書き換え、 C だけが Finding 2 を nature 上 消滅させる。 A/B は 2 択の対比、 C は radar が SoT に育っている現状を 追認する 第 3 の道。

## OEIS / Wikidata / SEP の scope caveat (私 Claude Code が見落としていた点)

藤本さん scope 指摘: JSON 側で **日次生きている** のは arXiv (`data/research-radar/arxiv-*.json`、 但し 2026-08-09 以降 4 日停止中) + Wikipedia 系のみ。 `data/oeis/` + `data/wikipedia-unsolved-problems/` 等は **単発の分析 md file** で 日次 fetch されていない。

**帰結**: 案 C 実装後も **OEIS / Wikidata / SEP テーブルは 0 のまま**。 rebuild script が投影する source が無い。 選択肢:

- **(a) 「投影元なし、 空 by design」 明示保持**: 将来 OEIS radar が JSON で立ち上がる可能性を残す設計、 但し テーブルは 継続的に 0 = 「中途半端が最悪」 原則違反 risk
- **(b) schema ごと DROP**: 「中途半端が最悪」 を これらの 3 テーブルにも適用、 実装 pipeline に沿った schema に一貫化、 将来 radar 立ち上がった時に 別 STEP で schema 再導入

藤本さん見解: 「中途半端が最悪 原則をここにも適用するなら、 後者寄り」 = (b) DROP 寄り。 但し 判断は C 実装 STEP 内の sub-question として 実装時再確認。

## 次 session 引継

案 C 実装 STEP 起動時の 前提:
1. OEIS / Wikidata / SEP 3 テーブル判断 = (a) 空 by design 明示 or (b) schema DROP (藤本さん 最終判断)
2. rebuild script を いつ・誰が走らせるか (Actions daily / on-demand local)
3. arxiv radar 4 日停止の 修復と 同 STEP で扱うか 別 STEP か
4. **前提**: 段 1 (「非致命的 skip」 38 箇所 audit) が **先に完了していること** (計器が壊れたことを知る手段がない状態で C を実装すると、 rebuild script が silent 死んでも気付かない = 3 例目 pattern を そのまま踏む)。 [[project-session-2026-08-14-step1334-arc-close-state]] 順序 table 段 1 → 段 2 の理由。