Notion 発信アーカイブDB 構築テンプレート（汎用モジュール版）
全発信が媒体別に資産として溜まっていくNotionデータベース設計図 — 自分の事業構成に合わせて組み立てる
0. この資料の使い方
この資料は、SNS・配信の発信コンテンツを媒体別にNotionへ蓄積し、資産化するためのデータベース設計テンプレートです。完成形を丸写しする資料ではなく、部品（モジュール）を選んで自分の事業に合わせて組み立てる資料です。実際に2年以上運用されているNotion環境（以下「元システム」）の構造調査をもとに汎用化しています。
進め方は3ステップです。
- STEP 1: 自分の「発信軸」を決める（§2）
- STEP 2: 必要なモジュールを選ぶ（§3のモジュール一覧）
- STEP 3: DBを作る — まず全員必須のコア基盤（§4）、次に選んだモジュール（§5〜§8）
- 含まれるもの: 設計思想／モジュール別のDB仕様（プロパティ・選択肢・ビュー）／組み立てパターン例／運用ルール
- 含まれないもの: 実データ、自動化スクリプトやAI連携の実装（接続を想定した設計メモは§9に記載）、顧客管理・自社サービス管理のDB（本テンプレートは発信コンテンツの蓄積に特化しています。必要になったら別途拡張）
- 前提: Notionの基本操作（ページ作成・DB作成・プロパティ追加）ができること
- 所要目安: 最小構成（コア＋SNS1媒体）で1〜2時間、フル構成で半日
表記ルール
- プロパティ表の「型」はNotionのプロパティ種別。Notion画面上の名称との対応:
title＝タイトル（各DB必須）／text＝テキスト／select＝セレクト／multi_select＝マルチセレクト／date＝日付／number＝数値／url＝URL／checkbox＝チェックボックス／files＝ファイル&メディア／relation＝リレーション／created_time＝作成日時／last_edited_time＝最終更新日時 - 「トンマナ」＝トーン&マナー（文体・世界観の一貫性）の略
- 選択肢のうち
【自分用に定義】とあるものは読者が自分の事業に合わせて決める箇所。それ以外の選択肢は分類の「型」として設計されているため、まずそのまま使うことを推奨 {軸名}はSTEP 1で決めた発信軸の名前が入るプレースホルダ
1. 設計思想（全モジュール共通の5原則）
個々のDBより、この5つの考え方が本体です。ここを外すとただのメモ帳の集合になります。
原則1: 情報のマスターはNotion一箇所
ルール・データ・発信コンテンツのすべてをNotionに集約し、「あの情報どこだっけ」を無くす。ローカルファイルやチャットログを正としない。AI（Claude等）と連携する場合も、AIに覚えさせるのではなくNotionを毎回読ませる方式にする。
原則2: 「発信軸」は自分で定義する（1個でも3個でもいい）
発信軸＝事業の顔・ペルソナの単位。ここがこの設計で唯一、人によって大きく変わる部分なので、最初に自分で決めます（決め方は§2）。
- 同じ媒体でも発信軸が違えばDBを分ける（例: A軸InstagramDBとB軸InstagramDBは別DB）
- どの軸にも属さない横断DB（Q&A・ナレッジ等）は1つだけ作り、「発信軸」プロパティで振り分ける。このプロパティの選択肢＝
自分の軸名すべて＋「共通」（例外: 活動ログ・チェックポイントのような運用ログは軸をまたぐ前提のため発信軸プロパティ不要。タグ／プロジェクトで代替する）
原則3: DBは役割で3分類する
| 分類 | 役割 | 更新の性質 |
|---|---|---|
| ① 参照専用（教材） | 自分の過去発信＝文体・トンマナの教師データ | 蓄積したら基本触らない |
| ② 制作物アーカイブ（台帳） | 媒体ごとの投稿・配信の成績表。ネタ被り防止・実績出典 | 投稿のたびに追記、指標を採取 |
| ③ 蓄積・横断ログ | 事業をまたぐ資産（Q&A・ナレッジ・タスク）。コンテンツ量産の源泉 | 日常的に追記、ステータスで回す |
原則4: フラット設計（リレーション・関数を最小限に)
richなNotion機能はあえて使いません。
- relationは原則、Q&A⇄記事生成物の1箇所だけ。他のDBはすべて独立させ、つながりは運用フローで作る
- formula・rollupは原則ゼロ。数値（再生数・いいね等）はすべて手入力またはスクリプト入力
- 理由: DB単体で完結するので1個ずつ作れる・壊れない。API・AIからの読み書きが単純になり自動化しやすい
原則5: 選択肢＝分析の「型」辞書
select／multi_selectの選択肢は単なるタグではなく、分析軸の固定辞書として設計する（例: フック型＝結論先出し／問いかけ／実績提示…）。投稿のたびに型を記録すると「どの型が当たるか」を後から集計できる。共通パターンは次の2つ。
- バズ判定:
バズ／高／普通— 成果の3段階評価 - 活用ステータス:
未活用／再利用済／改善案あり／アーカイブ— 過去投稿の再利用サイクル管理
2. STEP 1: 発信軸を決める
「発信軸」は次の質問で決めます。
発信のトーン・ターゲット・売り物が変わる単位はどこか？
媒体（Instagram/YouTube）は軸ではありません。同じ人格で複数媒体をやるなら軸は1つです。
構成パターン例
| パターン | 軸の例 | ハブ構成 |
|---|---|---|
| A. 単一軸（最小構成） | 「自分」1軸のみ | トップハブ直下にDBを並べる。軸ハブ省略可 |
| B. 2軸（元システムの構成） | 「料理発信」×「ビジネス発信」 | トップハブ → 軸ハブ2枚 → 各DB |
| C. 事業体×個人 | 「店舗・会社公式」×「個人アカウント」 | 同上 |
| D. 3軸以上 | 「本業」×「趣味」×「スクール」 | 軸ハブを軸の数だけ複製 |
迷ったら1軸で始めて、後から分けるのが安全です。横断DBに「発信軸」プロパティさえ付けておけば、軸が増えてもデータは分けられます。
ページ構成（完成形の骨格）
📋 トップハブ（全リソースの入口・1枚）
├─ 📐 運用ルールページ（§9の内容をここに明文化）
├─ 🅰 {軸A}ハブ ──┐
│ ├─ 選んだSNSモジュールのDB群（軸Aぶん）
│ ├─ 💌 配信アーカイブDB／📨 ニュースレター原稿DB（配信モジュール採用時）
│ └─ 💭 発信タグの戦略意図（ページ）
├─ 🅱 {軸B}ハブ ──┘ ※軸の数だけ複製（1軸なら省略可）
│ └─ …
└─ 横断DB群（軸をまたいで1つずつ）
├─ 📚 Q&Aデータベース
├─ 📝 記事生成物DB
├─ 💡 ナレッジDB
├─ 📺 競合ウォッチDB
├─ 📓 活動ログDB
└─ ✅ チェックポイントDB
ハブページの作り方: 各ハブは「参照専用（教材）」「制作物の置き場（台帳）」「ログ・蓄積DB」のセクション見出しで区切り、各DBへのリンクをcallout（役割の1行説明つき）で並べます。DBの実体はハブ配下に置き、callout はナビとして機能させます。
3. STEP 2: モジュールを選ぶ
| モジュール | 内容 | 必要な人 | 参照 |
|---|---|---|---|
| コア基盤 | ハブ／チェックポイントDB／活動ログDB | 全員必須 | §4 |
| 投稿台帳（フィード・リール・ストーリーズ）＋ストーリーズ教材DB | Instagram運用者 | §5-A | |
| YouTube | 投稿台帳（本編・ショート）＋文字起こし管理 | YouTube運用者 | §5-B |
| TikTok | 投稿台帳（時点別スナップショット） | TikTok運用者 | §5-C |
| 短文SNS | X／Threads投稿台帳（簡易） | 短文SNSを資産化したい人 | §5-D |
| 配信アーカイブ | LINE公式・メルマガの配信文アーカイブ | リスト配信をしている人 | §6-A |
| ニュースレター | 原稿→（翻訳）→公開のパイプライン管理 | note/Substack等の定期発行者 | §6-B |
| リサーチ | 競合ウォッチDB＋ナレッジDB | 競合分析・学習を資産化したい人 | §7 |
| コンテンツエンジン | Q&A DB＋記事生成物DB | コンテンツ量産したい人（強く推奨） | §8 |
SNS台帳系モジュールは「軸ごとに複製」（DB名を「{軸名}Instagramデータベース」のように付ける）。横断系（リサーチ・エンジン・コア基盤）は全体で1つだけ作ります。
4. コア基盤モジュール（必須）
4-1. ✅ チェックポイントDB 〔タスク・引継ぎ台帳〕
役割: 進行中タスクの現在地を1行で持つ台帳。特にAIと作業する場合、「タスク開始時に行を作る → 毎ステップ『次のアクション』を更新 → 完了にして定期的に削除（残したい場合はアーカイブ用ページへ移動）」の運用で、セッションが切れても続きから再開できる。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タスク名 | title | |
| ステータス | select | 進行中／中断／確認待ち／完了 |
| プロジェクト | select | 【自分用に定義】自分のプロジェクト名＋「全プロジェクト共通」「その他」 |
| 次のアクション | text | 次にやること（短文・最重要） |
| 最終更新 | last_edited_time | 自動 |
ビュー: Default（table）／🔴 棚卸し（table・フィルタ: ステータス=確認待ち、最終更新 昇順）
4-2. 📓 活動ログDB 〔日々の記録〕
役割: 商談・気づき・決定事項・学び・アイデアなど活動全般の時系列ログ。発信・配信のネタ元。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タイトル | title | |
| カテゴリ | select | 商談／気づき／決定事項／学び／アイデア／その他 |
| タグ | multi_select | 【自分用に定義】事業領域のタグ（例: SNS／サービス／{軸名}…） |
| 内容 | text | |
| 日付 | date | |
| 関連人物 | text | 自由記述（relationにしない） |
ビュー: Default（table・日付 降順）のみ。
5. SNSモジュール（軸ごとに複製する台帳群）
5-A. Instagramモジュール
Instagramはリール・フィード・ストーリーズを1つの台帳DBにまとめ、「投稿タイプ」プロパティで分けるのが基本形です（媒体としては1つなので、DBを型別に割らない）。加えて、ストーリーズを文体教材として使いたい場合のみ、教材DBを別に作ります。
5-A-1. 📸 {軸名}Instagramデータベース 〔台帳〕
役割: Instagram投稿の成績表。指標記録・型分析・再利用管理。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タイトル/キャプション | title | |
| 投稿URL | url | ※プロパティ名を「URL」だけにしない（§9の技術メモ参照） |
| 投稿タイプ | select | フィード／リール／ストーリーズ ※ストーリーズ教材DB（5-A-2）を併用する場合、ストーリーズは教材DB側のみに記録し、この台帳では扱わない（指標列がストーリーズに合わないため） |
| 投稿日 | date | |
| タグ/キーワード | multi_select | 【自分用に定義】発信テーマの辞書（5〜8個。例: レシピ／ノウハウ／マインド…） |
| バズ判定 | select | バズ／高／普通 |
| 活用ステータス | select | 未活用／再利用済／改善案あり／アーカイブ |
| フック文 | text | 冒頭・1枚目の文言 |
| 本文 | text | キャプション全文 |
| いいね数／コメント数／保存数／シェア数／リーチ数／再生数／エンゲージメント／平均視聴時間(秒)／スキップ率(%) | number | 指標9列（手入力またはスクリプト入力。関数にしない） |
ビュー: Default（table・投稿日 降順）から開始。件数が増えたら「バズのみ」（フィルタ: バズ判定=バズ）と「リール保存数ランキング」（フィルタ: 投稿タイプ=リール、保存数 降順）を追加推奨。
5-A-2. 🗂 {軸名}ストーリーズ教材DB 〔参照専用・オプション〕
役割: ストーリーズを1投稿=1レコードで全件蓄積する、文体・トンマナの教師データ。AI連携で「自分らしい文章」を生成させる場合の必須参照元。台帳（5-A-1）が成績表なのに対し、こちらは全文アーカイブ。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タイトル | title | 投稿の要約 |
| トンマナタグ | multi_select | 【自分用に定義】発信内容の分類を10個前後（例: ノウハウ／哲学／日常・家族／問いかけ／告知／雑談／学び・反省…）。※「どんな顔で発信しているか」の棚卸しになるので、過去投稿を眺めて帰納的に決める |
| 本文 | text | 投稿本文の全文 |
| メディア種別 | select | 画像／動画 |
| メディアパス | text | 元ファイルのパス（スクリプト投入用。手動運用なら省略可） |
| メディアファイル | files | |
| 投稿日時 | date | |
| メモ | text |
ビュー: Default（table・投稿日時 降順）のみ。
運用ルール: 教師データとして有効な期間を決める（例: 文体が確立した日以降のみ有効）。タグ別の「ねらい」は別ページ「発信タグの戦略意図」に文章で書き、DBとセットで参照する。
5-B. YouTubeモジュール
5-B-1. 🎬 {軸名}YouTubeデータベース 〔台帳〕
役割: YouTube投稿（本編長尺・ショート）を1本=1レコードで管理。用途は（1）成績表として傾向把握（2）新規企画前のネタ被り防止（タイトル検索）（3）営業・LPで使う実績の出典（4）文字起こしの格納庫（後述）。
プロパティは7グループ構成です。基本情報・企画の型・指標・再利用管理・文字起こしは必須、制作進行とファネル成果は任意で足してください。
| グループ | プロパティ | 型 | 選択肢・詳細 |
|---|---|---|---|
| 基本情報 | タイトル | title | |
| 公開日 | date | ||
| チャンネル | select | 【自分用に定義】メイン／サブ等、自分のチャンネル名 | |
| 形式 | select | 本編（長尺）／ショート | |
| 動画URL／サムネURL | url | ||
| 動画ID | text | YouTube動画ID（自動化する場合のキー） | |
| 動画尺(秒) | number | ||
| 企画の型辞書 | シリーズ名 | select | 【自分用に定義】自分の企画シリーズ名＋「単発」 |
| 企画フォーマット | select | 【自分用に定義・例】ノウハウ解説／実演デモ／比較実験／失敗解剖／対談・事例／裏話／Vlog | |
| タイトル型 | select | 数字／逆張り／権威性／好奇ギャップ／ベネフィット／断言／問いかけ | |
| フック型 | select | 【自分用に定義・例】結論先出し／問いかけ／実績提示／失敗ネタ／完成形チラ見せ（制作系向け）／工程ジャンプ（制作系向け） | |
| 狙い | select | 検索／Browse／Suggested／Shorts（狙う流入面） | |
| サムネ要素 | multi_select | 【自分用に定義・例】成果物ドアップ／プロセス／ビフォーアフター／顔あり／顔なし | |
| テーマ／切り口／ターゲット視聴者／フック文／検索クエリTOP3 | text | 企画メモ5列 | |
| 指標 | 再生回数／インプレッション数／CTR(%)／視聴維持率(%)／15秒残存率(%)／平均視聴時間(秒)／高評価／コメント数／登録者増 | number | YouTube Studio指標。投稿後の採取タイミングを決めて記録（例: 24時間後＋30日後） |
| Search比率(%)／Browse比率(%)／Suggested比率(%)／Shorts Feed比率(%)／External比率(%) | number | 流入内訳（任意） | |
| 再利用管理 | バズ判定 | select | バズ／高／普通 |
| 活用ステータス | select | 未活用／再利用済／改善案あり／アーカイブ | |
| 制作進行（任意） | ステータス | select | 構成中／撮影済／編集中／公開済 |
| 公開状態 | select | 公開／限定公開／非公開 | |
| ファネル成果（任意） | 概要欄クリック数／リスト登録数／説明会参加数／申込数 | number | 【自分用に定義】自分の導線に合わせて命名 |
| 文字起こし | 文字起こし状態 | select | 未／済 |
ビュー（推奨5つ）: Default／📅 投稿カレンダー（公開日）／🥇 再生回数ランキング（降順）／📈 視聴維持率トップ（降順）／🗂 企画フォーマット別ボード（board・グループ化）
5-B-2. 本編動画の文字起こし運用（このモジュールの重要ポイント）
本編動画の文字起こしはコンテンツ量産の最重要原料です。次のルールで運用します。
- 格納場所: 文字起こし全文は台帳レコードのページ本文に貼る（プロパティのtext欄は長文の扱いに不向き。本文なら見出し付きで整形でき、検索にもかかる）
- 状態管理: プロパティ「文字起こし状態」を
未／済で管理。未の動画を順に処理する - 二次利用への接続: 文字起こしから「質問と回答」の形になる部分を抽出 → Q&Aデータベース（§8）へ転記（ソース種別=本人動画、ソース参照=動画URL）。記事・教材はQ&A経由で量産する
- ショートへの展開: 本編の文字起こしから切り抜き候補を拾い、ショートとして再投稿 → 台帳に形式=ショートで記録
文字起こしの取得自体（Whisper等の音声認識、YouTube字幕のダウンロード）はこの資料の範囲外ですが、上記の器はツールを問わず機能します。
5-C. TikTokモジュール
🎵 {軸名}TikTokデータベース 〔台帳〕
役割: TikTok投稿の指標を時点別スナップショットで追跡する台帳。TikTokは公開後の伸び方が時間差で来るため、同一投稿を「24h/72h/7d/最終」の複数行で記録できる設計にしている（1投稿1行で最終値だけ記録する運用でも可）。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タイトル/キャプション | title | |
| 投稿URL | url | |
| 本文／フック文／ハッシュタグ／使用音源 | text | |
| 投稿日／採取日時 | date | 採取日時＝指標を記録した時点 |
| 投稿タイプ | select | 動画／フォトモード／LIVE／Series |
| 採取タイミング | select | 24h／72h／7d／最終 |
| バズ判定 | select | バズ／高／普通 |
| フック型 | select | 【自分用に定義・例】断言／反論／問いかけ／結論先出し／驚き／完成形ショーケース（制作系向け）／工程ジャンプ（制作系向け） |
| 活用ステータス | select | 未活用／再利用済／改善案あり／アーカイブ |
| タグ/キーワード | multi_select | 【自分用に定義】Instagramモジュールと同じ辞書を使い回す |
| 再生数／いいね数／コメント数／シェア数／保存数／フォロワー増加／動画長(秒)／平均視聴時間(秒)／視聴完了率(%)／再視聴率(%)／フォロー外視聴率(%)／おすすめ流入率(%)／エンゲージメント率(%) | number | TikTok指標13列 |
ビュー: Default（table・投稿日 降順）のみ。
5-D. 短文SNSモジュール（X／Threads・簡易）
短文SNSは量が多く1件の価値が小さいため、全件記録ではなく「当たり投稿と型のストック」として小さく運用します（不要ならこのモジュールごと省略）。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| 本文冒頭 | title | |
| 媒体 | select | X／Threads |
| 本文 | text | 全文 |
| 投稿URL | url | |
| 投稿日 | date | |
| 型 | select | 【自分用に定義・例】断言／リスト／ストーリー／問いかけ／実績公開 |
| インプレッション／いいね／リポスト／ブックマーク／フォロワー増 | number | |
| バズ判定 | select | バズ／高／普通 |
| 活用ステータス | select | 未活用／再利用済／改善案あり／アーカイブ |
ビュー: Default（table・投稿日 降順）のみ。
6. 配信モジュール
6-A. 💌 配信アーカイブDB（LINE公式・メルマガ）
役割: リスト配信（LINE公式・メルマガ）の配信文を全件アーカイブ。過去配信の参照・反応が良かった配信の分析・文体教材を兼ねる。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| 配信タイトル | title | |
| 配信日 | date | |
| アカウント | select | 【自分用に定義】自分の配信アカウント名（LINE公式が複数あるなら全部） |
| 用途 | select | 顧客向け／集客（リスト教育） ※自分のファネルに合わせて調整 |
| 本文 | text | 配信本文の全文 |
| 文字数 | number |
ビュー: Default（table・配信日 降順）のみ。軸をまたいで配信している場合は「発信軸」selectを追加して1DB運用でも、軸ごとに複製してもどちらでも可。
6-B. 📨 ニュースレター原稿DB（note定期便・Substack等／オプション）
役割: 「原稿を書く→（翻訳・変換する→）承認する→公開する」の直列パイプラインを1行で管理。多言語展開しないなら翻訳系プロパティを省いて使う。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タイトル | title | |
| タイトル（変換後） | text | 翻訳版・リライト版のタイトル（不要なら省略） |
| ステータス | select | draft／translated／approved／published／failed ※日本語運用なら「下書き／変換済／承認済／公開済／失敗」 |
| ソース種別 | select | YouTube／ストーリーズ／記事／新規書き下ろし |
| ソースID | text | 元コンテンツの識別子 |
| 公開フェーズ | select | 無料／有料（paywall）／お知らせ |
| 公開予定日 | date | |
| 原文／変換後本文 | text | |
| 公開URL | url | |
| メモ | text |
ビュー: Default（table・公開予定日 降順）のみ。
7. リサーチモジュール（全体で1セット）
※「1セット」＝軸ごとには複製しない、の意味です。競合ウォッチDBを媒体別（YouTube用・Instagram用）に複製するのは可。
7-A. 📺 競合ウォッチDB
役割: 競合アカウントの投稿パフォーマンスをスナップショット記録し、「フォロワー規模の割に伸びているコンテンツ」を発見するウォッチリスト。YouTube以外（Instagram・TikTok）を見る場合も同じ構造で複製できる。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タイトル | title | 対象コンテンツのタイトル |
| 競合名 | select | 【自分用に定義】ウォッチする競合を5〜10個 |
| ステータス | select | 未確認／確認済／お気に入り（確認フロー） |
| コンテンツURL／サムネURL | url | |
| 公開日／スナップ日 | date | スナップ日＝指標を記録した日（数値は時点値として扱う） |
| 再生数／高評価／コメント数／フォロワー数 | number | |
| フォロワー比 | number | 再生数÷フォロワー数。手入力（関数にしない）。伸び発見の主指標 |
| 冒頭3秒 | text | フックのメモ |
ビュー（推奨4つ）: Default（公開日 降順）／🥇 フォロワー比ランキング（降順）／📊 競合別ボード／📅 月次カレンダー
7-B. 💡 ナレッジDB
役割: 外部由来の学び（勉強会・書籍・記事）と競合リサーチの気づきを蓄積。自分の発信（ストーリーズ教材DB）とは混ぜない。「入れたら終わり」を防ぐため、ステータスで施策への反映まで追跡する。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タイトル | title | |
| 要約 | text | |
| アクション | text | そこから取るべき行動 |
| ソース | text | 出典（URL・媒体名） |
| 対象 | text | リサーチ対象（競合アカウント等） |
| 日付 | date | 全ビューのソートキー |
| ステータス | select | 未処理／確認済／施策反映済／アーカイブ |
| 種類 | select | 勉強会／競合分析／書籍・記事／SNS観察／市場トレンド／その他 |
| 投入元 | select | 本人／AI（AI自動投入と本人の厳選を区別する） |
| 発信軸 | multi_select | 【自分の軸名】＋共通 ※学びは複数軸にまたがることがあるため、このDBのみmulti_select |
| 領域 | multi_select | SNS運用／マーケティング／ブランディング／デザイン／コピーライティング／動画編集・撮影／AI・自動化／経営・組織／その他 |
ビュー（推奨5つ）: Default／🆕 未処理（ステータス=未処理）／軸別（軸の数だけ）／🔍 競合分析（種類=競合分析）／⭐ 本人厳選（投入元=本人）。すべてtable・日付 降順。
運用の型: 新規は必ず「未処理」で投入 → 中身を確認したら「確認済」→ 施策に使ったら「施策反映済」。
8. コンテンツエンジンモジュール（Q&A＋記事生成物）
このテンプレートの本丸です。あらゆる接点で発生した「質問と回答」を1つのプールに集め、そこから記事・教材を量産するエンジンで、各SNSモジュールの台帳とつながります。
8-A. 📚 Q&Aデータベース
役割: 面談・DM・コメント・講義・ストーリーズ質問など、全チャネルの問答を一元蓄積するプール。ここがコンテンツ量産の上流。元システムでは約4,000件蓄積され、システム全体の最重要資産になっている。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| 質問（Q） | title | 質問文 |
| 回答（A） | text | 回答本文 |
| 発信軸 | select | 【自分の軸名】＋共通 |
| カテゴリ | multi_select | 【自分用に定義】質問ジャンルの辞書10個前後（例: ノウハウ／理論／機材／集客／マインド／運営…） |
| ソース種別 | select | 個別面談／グループ講義／Discord等コミュニティ／DM／ストーリーズ質問／動画コメント／本人動画（文字起こし由来）／自己生成／その他 |
| ソース参照 | url | 出典URL（動画・投稿へのリンク） |
| 対象 | multi_select | 【自分用に定義】読者区分（例: フォロワー／会員・受講生／見込み客／一般） |
| 活用ステータス | select | 未活用／記事化済／教材化済／要整理／アーカイブ |
| 記事化先 | relation | → 記事生成物DB（双方向。相手側プロパティ名「Q&A参照」） |
| 作成日 | date | 手動入力のdate型にする（自動のcreated_timeにしない。過去データ移行時に本来の日付を入れられるようにするため） |
ビュー（推奨3種。軸別ビューは軸の数だけ複製）:
| ビュー名 | 種類 | 設定 |
|---|---|---|
| Default | table | 全列 |
| 📝 記事化候補 | table | フィルタ: 活用ステータス=未活用、作成日 降順（軸別に分けるならビューを複製） |
| 軸別・全件 | table | フィルタ: 発信軸={軸名}（軸の数だけ複製） |
8-B. 📝 記事生成物DB
役割: Q&A・動画文字起こし等を原料に生成した記事（ブログ・SEO・教材）の完成品台帳。品質評価と公開ワークフローを持つ。記事本文はレコードのページ本文に置く。
| プロパティ | 型 | 選択肢・詳細 |
|---|---|---|
| タイトル | title | SEOキーワードを含む想定 |
| 記事タイプ | select | ブログ記事／SEO記事／教材／その他 |
| 構成タイプ | select | 【自分用に定義】自分の記事フォーマット名＋「Q&A記事」「ノウハウ解説」「その他」 |
| 発信軸 | select | 【自分の軸名】＋共通（Q&A DBと同じ選択肢・配色にする） |
| 対象読者 | multi_select | 【自分用に定義】Q&A DBの「対象」と揃える |
| ソース種別 | multi_select | 動画／音声収録／Q&A／ストーリーズ／自己生成／その他 |
| ソース参照 | text | 動画URL・ファイル名等 |
| Q&A参照 | relation | → Q&Aデータベース（双方向） |
| 公開ステータス | select | ドラフト／執筆中／レビュー中／公開済み／非公開 |
| トンマナ評価 | select | A／B／C／未評価（自分の文体ルールとの整合性を人が評価） |
| ベネフィット | text | 読者が得る変化を一言で |
| 文字数 | number | |
| 公開URL | url | |
| 公開日 | date | |
| 作成日／最終更新 | created_time／last_edited_time | 自動 |
ビュー: Default（table）／📋 公開パイプライン（board・公開ステータスでグループ化）を推奨。
8-C. エンジンの回し方（全モジュールの接続図）
[入力] 面談・DM・コメント・講義・ストーリーズ質問・本編動画の文字起こし
↓ 問答の形に切り出して都度記録
📚 Q&A DB（活用ステータス=未活用）
↓ 候補ビューから拾って記事化
📝 記事生成物DB（トンマナ評価 → 公開）
↑ 文体の参照元: 🗂 ストーリーズ教材DB ＋ 💭 戦略意図ページ
↓ 公開した記事はSNS・配信で告知
📸🎬🎵 各SNS台帳（投稿を記録 → バズ判定 → 当たりの型を次の企画へ）
一方通行のサイクルです。リレーションでつなぐのはQ&A⇄記事生成物の1箇所だけで、残りの接続はすべて「運用の順番」で実現します。
9. 共通運用ルール（構築後にトップハブへ明文化する）
- 置き場ルール: 媒体×発信軸でDBは固定。迷ったら入れない（例: Instagram投稿をYouTube台帳に入れない）
- 自動算出値は手動編集しない: スクリプト連携する場合、バズ判定などの自動算出プロパティを手で直さない（次回同期で消えるか、集計が狂う）
- 同じテーマの情報が複数あるときは最新版が正。古い方をアーカイブ
- ストーリーズ教材DBの有効期間を決める: 文体が変わる前の古い発信を教師データに使わない
- チェックポイントDBは溜めない: タスク開始時に行を作り、完了にしたら定期的に削除する（残したい場合はアーカイブ用ページへ移動）。「確認待ち」の棚卸しビューを週次で見る
- 選択肢の追加は自由、改名・削除は慎重に: ビューのフィルタや自動化が選択肢名を文字列で参照しているため、改名すると静かに壊れる
- モジュール追加の指針: 新しい媒体を始めたら「台帳DBを軸ごとに複製」「タグ辞書は既存モジュールと揃える」「バズ判定・活用ステータスの共通パターンを踏襲」の3点を守って増設する
AI・API連携する場合の技術メモ
※以下の最初の3点は、AI連携ツール（Notion MCP・SQL変換系）経由での挙動です。Notion公式APIを直接使う場合は該当しません（URLという名前もそのまま扱え、checkboxはtrue/false）。
- プロパティ名を
URLにすると、一部のAI連携ツールではuserDefined:URLという内部名に変換される。連携予定があるなら「投稿URL」「動画URL」など固有名にしておくと安全 - 日付プロパティはSQL変換系ツールからは
date:プロパティ名:start / :end / :is_datetimeの3カラムに展開される - checkboxはSQL変換系ツール上
__YES__ / __NO__で扱われる - 「作成日」を自動のcreated_timeにせず手動dateにするのは、過去データ移行時に本来の日付を入れるための意図的な設計
- AIに文体を再現させる構成は「①ストーリーズ教材DB（実例）＋②戦略意図ページ（ねらいの言語化）＋③トンマナ評価（人の合否判定）」の3点セット。どれか1つでは精度が出ない
10. 組み立てチェックリスト
（§0の3ステップを、作業しやすいよう4フェーズに分解しています）
フェーズ1 — 設計（＝STEP 1・2） - [ ] 発信軸を決めた（1個でも可。軸名を書き出した） - [ ] 使うモジュールを§3の表から選んだ - [ ] 横断DBの「発信軸」selectに入れる選択肢（軸名＋共通）を確定した
フェーズ2 — コアとエンジン（＝STEP 3前半） - [ ] トップハブページを作成した - [ ] チェックポイントDB・活動ログDBを作成した - [ ] Q&A DBと記事生成物DBを作成し、「記事化先」⇄「Q&A参照」のリレーションを接続した
フェーズ3 — 選んだモジュール（＝STEP 3後半） - [ ] SNS台帳DBを軸ごとに複製して作成した（DB名に軸名を入れた） - [ ] 【自分用に定義】の選択肢（タグ辞書・シリーズ名・競合名・プロジェクト名）をすべて自分用に決めた - [ ] （該当者）YouTube台帳に「文字起こし状態」を付け、文字起こし全文の置き場＝ページ本文のルールを決めた - [ ] （該当者）配信アーカイブDBを作成し、過去の配信文を数件入れてみた
フェーズ4 — 仕上げ - [ ] 各DBの推奨ビュー（特にQ&Aの記事化候補ビュー、チェックポイントの棚卸しビュー）を作成した - [ ] トップハブに運用ルール（§9）を明文化した - [ ] テストレコードを各DBに1件入れ、ビューのフィルタが機能することを確認した
本テンプレートは、実際に約4,000件のQ&A・約6,400件のストーリーズ・複数SNS台帳を2年以上運用している実環境の構造調査をもとに汎用化したものです（2026-07-04時点）。