溜 め 方 の 蔵

なぜスプシじゃなくて D1？

• スプシは数百〜数千行までは最強 (手で見て編集できる)。だが 1 万行を超えると動作がもっさり、検索が遅い、共同編集で詰む。
• D1 は 数万〜数百万行でも余裕。CC からの読み書きが速い。SQL で「カテゴリAでタグBが付いてるやつだけ」みたいな絞り込みが一瞬。
• 料金: D1 は 5GB まで無料。普通の Q&A データなら一生無料で足りる。
• ALC のリアル運用では「スプシで 500 行までは管理 → 超えたら D1 に移行」が黄金パターン。

最強の型 — 1 行 = 1 Q&A + カテゴリ

溜め方の 正解は 1 つ: どんな情報源 (セミナー文字起こし / SNS / 1:1 / メモ) も 「想定される質問 + その答え」の 1 ペアに分解して 1 行で保存する。

これに カテゴリ + サブカテゴリ + タグのラベルを付けておけば:

• LINE Bot — 受信メッセージ → 類似 QA を引いて返信
• FAQ サイト — カテゴリで自動分類して見せる
• セミナー台本 — 「最近のお客さんが聞いてくる質問 TOP 10」を category + COUNT で抽出
• 商品設計 — 「答えにくい質問」だけ抜いて、それを解決する新サービス企画
• SNS 発信 — 1 行から Threads 1 本 / X 3 本 / IG リール台本 1 本に展開

同じデータが、形を変えて何回でも使えます。これが「溜め方が正しい」の意味。

D1 を作る (5 分)

Claude Code に以下をコピペ。スキーマも一緒に切ってくれます:

コピーCloudflare D1 で新しいデータベースを作って、Q&A 形式のテーブルを用意してください。
- DB 名: my-knowledge
- テーブル: qa_pairs
- カラム:
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    category TEXT NOT NULL,
    subcategory TEXT,
    question TEXT NOT NULL,
    answer TEXT NOT NULL,
    source TEXT,
    tags TEXT,
    created_at TEXT DEFAULT (datetime('now'))
- wrangler.toml に binding を追加 (binding 名: DB)
- スキーマ migration ファイルを migrations/0001_init.sql に保存
- wrangler d1 migrations apply で本番に適用してください。

テーブル設計のポイント:

• category — 大分類 (例: 「フィットネス」「美容」「子育て」)
• subcategory — 中分類 (例: 「料金について」「効果について」「予約方法」)
• tags — 横断タグ (例: 「初回限定」「キャンセル」「無料相談」)
• 3 階層で 縦の絞り込み × 横のタグ検索が両方できる構造

データを流し込む — 文字起こし → QA 分解

セミナー録画を ElevenLabs で文字起こしして docs/ に置いたら、CC に分解させて D1 に流し込みます:

コピー今フォルダにある以下のソースを Q&A 形式に分解して、my-knowledge の qa_pairs テーブルに溜めてください。
- ソース: docs/ 配下の Markdown ファイル全て
- 1 ファイル = 複数 QA に分解 (1 質問につき 1 行)
- category: ファイルが入っているサブディレクトリ名
- subcategory: ファイル内の H2 見出し
- question: 「読者が聞きそうな問い」を 1 文で
- answer: 該当箇所の本文を整理 (200-400 字)
- source: 元ファイルの相対パス
- tags: 関連キーワードをカンマ区切りで 3-5 個

INSERT 文を生成 → wrangler d1 execute で投入してください。

CC は文字起こしを読みながら「ここはこういう質問への答えだな」と判断してペア化してくれます。1 本 60 分のセミナーから 30-80 件の QAが抽出できます。

使う — お客さん対応への自動回答

溜まった QA を使ってお客さんに返事する流れ:

コピーmy-knowledge の qa_pairs から、お客さんからの質問「[ここに質問を貼る]」に近い QA を 5 件引いてきて、それを参考に最適な答えを CC として生成してください。
- まず category と質問キーワードで LIKE 検索して候補を 5 件取得
- 取れた answer を要約 → 元の質問への回答を 300 字で生成
- 使った QA の id と source も出典として末尾に明記してください。

これで 「自分の過去発言を全部学習した自分専用 AI」ができあがります。LINE / Slack / メール 全部に応用可能。

カテゴリを育てる

最初は雑にカテゴリ付けて OK。100 件、500 件と溜まってきたら定期的にカテゴリを見直して整理します:

コピー溜まった qa_pairs を眺めて、カテゴリ体系を見直したいです。
- 現在 category にどんな値が入っているか SELECT DISTINCT で一覧表示
- カテゴリ数 / 各カテゴリの件数も集計
- 過剰に細分化されてるカテゴリ / 1 件しかない迷子カテゴリを指摘
- 統廃合の提案を出してください (例: 「A と B は実質同じだから C にまとめる」)。
- 僕が OK したら UPDATE 文を流して再ラベリングしてください。

CC が現状の偏り (細分化しすぎ / 統合候補) を指摘してくれるので、それを見ながら統廃合。これを月 1 でやると、知識ベースが綺麗に育ちます。

設計の流儀

• カラムは少なく — 最初は category / subcategory / question / answer / tags の 5 つで十分。後から ALTER TABLE で追加できる。
• question は具体的に — 「料金は？」じゃなく「初回 60 分セッションの料金はいくら？」のレベル。曖昧だと検索精度が落ちる。
• answer は完結に — 200-400 字。長すぎると引用しづらい、短すぎると情報量不足。
• source は必ず残す — 「これどこから引いたっけ?」になるとデータの信頼性が崩壊。
• 1 件追加 = 100 件削除 ぐらいの気持ちで、定期的に古い・重複を消す。