データを置いても、誰に届けるかが設計されていなければ、コンテンツはスキルの独り言になる。 今日、自分のdatabase/を全面的に再設計しました。変わったのは「設計の哲学」だけではありません。DBが自律的に反応するようになりました。 今回の再設計で2つの変化を加えています。 ひとつ目：「誰が管理するか」から「誰に・何を・どのように届けるか」へ。構造にWHO・WHAT・HOWを埋め込む。 ふたつ目：データが更新されたら、DBが自動的に応答する。コマンドを叩かなくても次の推薦が更新される。 コードは出てきません。CSVとフォルダ構造の話です。それでも、この設計がなければ26スキルは正しく機能しません。
前回の設計では、database/を6ドメインに分離しました。
database/
├── content/ ← コンテンツ制作の中核
├── analytics/ ← パフォーマンスデータ
├── insight/ ← 課題・潜在ニーズの蓄積
├── research/ ← 外部情報収集
├── seminar/ ← セミナー固有データ
└── system/ ← スクリプト・ログ管理この構造はスキルの管轄を整理するのに有効でした。「このフォルダはどのスキルが使う」という所有権が明確になった。 ただ、欠落していたことがあります。 「誰に届けるか」がDB構造に存在しなかった。 atoms.csvにはコンテンツの種（claim）があります。pipeline.csvには展開計画があります。outputs.csvには公開済みコンテンツがあります。しかし、それが「どのペルソナの、どの痛みに対して」書かれたものかは、どこにも記録されていませんでした。 スキルは「どのテーマか」は知っていても「誰のための記事か」を毎回ゼロから考えていた。これは設計の抜けです。 コンテンツを量産しても、ペルソナとの接合がなければ刺さらない記事が積み上がるだけです。 Claude Code 知らないと損する40のワザ
ダイレクトレスポンスマーケティングの設計思想に基づいています。特定ターゲットに直接働きかけ、即行動を引き出す。その設計軸は3つです。
database/
└── insight/
├── persona.csv ← WHO（対象者）
├── pain.csv ← WHAT①（痛み・課題 — 反応を起こすトリガー）
├── what.csv ← WHAT②（解決策・価値提案）
└── how.csv ← HOW（届け方）従来のinsight/にあったのは problem.csv / solution.csv / how.csv でした。今回の再設計で persona.csv が追加され、problem.csv が pain.csv、solution.csv が what.csv に改名・再定義されました。
ドメイン名が変わったのではなく、思想が変わったのです。
persona_id, label, pain_domain, awareness_level, channel_affinity, description
PE001, フリーランサー・個人クリエイター, business/creator, problem_aware, post/note, 副業〜専業。価格設定・案件獲得・AI活用に悩む層
PE002, AIエンジニア志望・学習中, career/learning, solution_seeking, post/note, エンジニア転職・スキルアップ中。ロードマップ・採用基準を求める
PE003, 中小企業AI担当・経営者, ai_adoption/business, unaware, note/seminar/consulting, AI導入済みだが活用できていない。支援者不在の層
PE004, デザイナー（AI移行期）, creator/ai_adoption, problem_aware, post/note/instagram, Figma・グラフィック出身。AI×デザインのキャリア転換を模索
PE005, ナレッジワーカー全般, productivity, unaware, post, 仕事が終わらない感覚。生産性に課題があるが言語化できていない5つのペルソナが定義されています。重要なのは awareness_level（課題認識度）と channel_affinity（接触チャネル）です。
PE003（中小企業AI担当）は unaware。自分が困っていると気づいていない。このペルソナにはX投稿よりnoteかセミナーで届ける方が適切です。PE001（フリーランサー）は problem_aware。課題は認識している。postで刺さるコピーが機能します。
チャネル選択がペルソナ定義から導出できる。これが channel_affinity の意味です。
id, title, domain, severity, affected_scope, persona_ids
PR001, AIエージェント導入後の不活性化, ai_adoption, 5, 日本中小企業導入済み43%のうち約22%が放置状態, PE003
PR002, AIエンジニアへのスキルアップ経路が不明確, career, 4, エンジニア転職・スキルアップ志望層（国内年間数万人規模）, PE002痛みのレコードです。severity は1〜5。5は「放置すれば事業的損失に直結する」レベルです。記事・セミナー・コンサルの優先度判断に使います。persona_ids でどのペルソナが持つ痛みかが明示されます。
id, pain_id, title, description
W001, PR001, AI浸透診断コンテンツ, 導入済み・不活性化状態の企業向け「なぜ使われないか」の構造分析
W004, PR002, 2026年版AIエンジニア最短ルート記事, 学習ロードマップを採用基準まで落とし込んだnote記事解決策・価値提案のレコードです。pain_id で痛みと紐付いています。コンテンツとして形にする前に「何を提供するか」を明示するテーブルです。atom_ids でatoms.csvと接続され、価値提案が実際のコンテンツ素材に橋渡しされます。
id, what_id, persona_ids, channel, format, awareness_level, priority, status
H001, W001, PE003, note, 記事（調査数値付き・法人リード獲得目的）, problem_aware, 1, idea
H002, W002, PE003, consulting, 法人提案（3〜6ヶ月定額サポート）, solution_seeking, 1, idea届け方のレコードです。what_id・persona_ids に加え awareness_level が入っています。
このレコードが1件あるということは「PE003（中小企業AI担当）が持つPR001（AI不活性化問題）に対して、W001（AI浸透診断コンテンツ）をnote記事形式で届ける計画がある」ということです。
awareness_level はチャネル選択の根拠です。unaware のペルソナにはpost（問題提起型）、solution_seeking にはlab/consulting（解決策型）を当てます。
今回の再設計で最も重要な変更は、pain_id と persona_ids が content/ レイヤーまで伝播したことです。
database/
├── insight/
│ ├── persona.csv ← PE001〜PE005
│ ├── pain.csv ← PR001〜PR00N（persona_ids付き）
│ ├── what.csv ← pain_id付き
│ └── how.csv ← what_id/persona_ids/awareness_level付き
│
└── content/
├── atoms.csv ← persona_ids 256件全埋め
├── pipeline.csv ← persona_ids/pain_id 66件全埋め
└── outputs.csv ← persona_ids/pain_id 120件全埋めatoms.csvのレコードを見れば「このコンテンツ素材はどのペルソナ向けか」がわかります。pipeline.csvのレコードを見れば「この展開計画はどの痛みを解決するためか」がわかります。outputs.csvのレコードを見れば「この公開コンテンツは誰に当てたものか」がわかります。
「どの痛みを持つ誰に、何を、どのチャネルで届けたか」が全テーブルでトレースできる。
旧設計では insight/ と content/ は独立していました。インサイトが発見されても content/ には反映されなかった。コンテンツが公開されても「誰のための記事だったか」はどこにも記録されませんでした。
新設計では insight/ で定義された persona_id と pain_id が content/ の全テーブルに流れ込みます。
この設計と同時に、もう1つの変化を加えました。 atoms.csvが更新されたら、DBが自動的に応答する。 仕組みはシンプルです。macOSのlaunchdというジョブ管理機構に「ファイル監視」を設定しています。
atoms.csv または outputs.csv が変更
↓ (launchd WatchPaths)
score_atoms.py 自動実行
↓
database/content/atom_scores.csv ← 全249atomの5軸スコア更新
database/content/top_atoms.md ← 上位10件の推薦リスト更新5軸スコアとは、atom-suggestスキルが使っているスコアリングモデルです。
atom_scores.csv を読むだけです。
同じトリガーで build_cross_analytics.py も走ります。チャネル横断のパフォーマンス行列（後述）も自動更新されます。
0円で、コマンドを打たずに、データが変わるたびにDBが最新状態になる。
旧設計との最大の差は「命令駆動から反応駆動へ」の移行です。もう1つの追加機能が theme_channel_matrix.csv です。
database/analytics/theme_channel_matrix.csvテーマ × チャネルのパフォーマンス行列です。post・note・lab・trainingの全アウトプットを、テーマ軸で横断集計しています。 今日時点で見えていること：
theme channel output_count total_imp avg_engage
ai-philosophy post 20 1,051,547 3.68%
stitch post 8 894,735 6.54%
claude-code post 16 822,072 2.02%
ai-philosophy note 8 50,945 2.13%
stitch note 1 0 —stitch（Stitch AIシリーズ）は投稿数8本でengage_rate 6.54%。ai-philosophyの3.68%と比べて明確に高い。しかしnoteへの展開は1本しかない。
これは横断表がなければ見えなかった数字です。テーマ単独で見ると ai-philosophy の方が総imp数は多い。しかし反応率で見ると stitch が突出している。noteとlabへの未展開が残っている状態です。
どのテーマをどのチャネルで育てるかの意思決定が、横断行列があると数値ベースになる。
感覚で「このテーマは伸びてる気がする」と言っていたものが、テーブルを見れば「post/note双方で成立するかどうか」が判断できます。
この設計変更はスキルの動き方を変えます。
atom-suggest（コンテンツ推薦）は、スコアを再計算しなくなりました。atom_scores.csv を読んでフィルタリングと理由説明だけ行います。pain_idが一致するatoms.csvを優先推薦できるため、推薦の根拠が「テーマの人気」ではなく「まだ届けられていない痛み」になります。
writer-article（記事執筆）は、執筆前にhow.csvを参照すれば「この記事はPE003向けのPR001解決コンテンツ」という文脈がある状態で書き始められます。リード文・CTA・具体例がペルソナ文脈で揃います。
week-review（週次レビュー）は、「今週どのコンテンツがどのペルソナに刺さったか」を outputs.csv の persona_ids で集計できます。PE001向けとPE003向けでパフォーマンスを分離して分析できる。theme_channel_matrix.csv でテーマ健全性も横断確認できます。
スキルが増えるほど、この設計の恩恵は大きくなります。26スキルが同じ pain_id / persona_ids の軸でデータを参照・更新する。その結合がスキル間の引き継ぎを構造化します。
今回の設計変更を一言で言うと、DBが「静的な保存場所」から「動的に反応するシステム」に変わりました。 第1段階（旧設計）: 構造で管轄を表現する 誰がどのファイルを使うかを6ドメインで整理した。スキルの所有権が明確になった。 第2段階（今回前半）: 構造でWHO・WHAT・HOWを表現する insight/にpersona/pain/what/howの4層を置き、content/の全テーブルにpersona_ids/pain_idを伝播させた。誰に何を届けたかが全テーブルでトレースできるようになった。 第3段階（今回後半）: DBが自律的に反応する launchd WatchPathsでatoms.csv/outputs.csvの変更を検知。スコアリング・横断analytics・推薦リストを自動更新。命令駆動から反応駆動へ。 設計の原則は更新されます。「どのファイルを使うか」→「誰に届けるか」→「データが変わったら自動応答する」。 コンテンツを量産しても届かないと感じているなら、問題はスキルの精度ではなくDB設計にある可能性があります。誰に届けるかが構造化されていない状態でどれだけ書いても、ペルソナとのズレは縮まりません。
本記事は設計思想の解説まで。自分のMacで30分で動く状態にしたい人は完全実装版を別記事で公開予定です。