『その仕事、AIに任せた後は？ あなたの脳を整える、焙煎士の診断ガイド』
PR

【自律AI×第二の脳 第2部】なぜ中間DBを捨てたのか？1年後も爆速を維持する「Obsidian直結型（SSOT）」ダッシュボードの設計思想

社会人の勉強

個人開発で自動化ツールやログビューアを作る際、多くの人が「とりあえずJSONファイルに追記する」「SQLiteに溜める」という設計を選びます。

しかし、1年後（365日後）にそのシステムはどうなっているでしょうか？

  • ファイルサイズが数MBに肥大化し、開くたびにカクつく
  • 溜まったデータがツールの内部に閉じ込められ、普段のメモや執筆（Obsidian）で活かせない
  • JSONが壊れたら過去ログが全滅する

本記事では、この問題を根本から解決するために行き着いた「中間DBを完全撤去し、Obsidian（第二の脳）を唯一の正本（SSOT）とするオンデマンド・パース設計」のアーキテクチャとメリットを徹底解説します。

[!TIP]
【この記事の要約（TL;DR）】

  1. よくある失敗: 単一JSONへの追記は、1年後に読み込み速度低下とメモリ圧迫の元凶になる。
  2. SSOT（Single Source of Truth）原則: 中間データを廃止し、ObsidianのMarkdownノートだけを正本とする。
  3. オンデマンド・スライスパース: サーバーが必要な最新30件だけをその場で正規表現パースすることで、1年後も初日と同じ0.005秒の爆速レスポンスを維持。
  4. 知識の資産化: データがそのままObsidianの検索・相互リンク（[[ ]]）・Dataviewの対象になり、ブログやSNSの制作ネタへ直結する。

📌 【自律AI×第二の脳シリーズ（全3部作）】

1. 「とりあえずJSON」が1年後に破綻する3つの理由

  1. 通信量とDOM描画の爆発:
    1日3件のトピックでも、1年で1,000件超。全件を一度にブラウザに送ると、初期ロード時間が目に見えて悪化します。
  2. データの分断（サイロ化）:
    JSONやDBの中に閉じ込められたテキストは、私たちが最も愛用している「Obsidian」の検索バーやナレッジグラフからは見えません。
  3. 二重管理の破綻:
    「JSONにも保存し、Obsidianにもメモする」という二重持ちは、必ずどこかで同期ズレを起こします。

2. 解決策：Obsidian直結型（SSOT）アーキテクチャ

私たちが採用したのが、「ObsidianのMarkdownファイルそのものをデータベースとみなす」 アプローチです。

アーキテクチャの3大原則

  • 正本は1つだけ: データは Obsidian_Notes/00_Inbox/Daily_Tech_Brief_YYYYMMDD.md のみに書き込む。
  • オンデマンド・スライス: サーバーは全ファイルを読みに行かず、ファイル名の降順（最新日付順）で最新30件だけをスキャンする。
  • 軽量正規表現パース: Frontmatter（タイトル、日付、タグ）と見出し（H2, H3）をPythonの正規表現で瞬時に辞書化してブラウザに返す。

3. なぜ1年後も「0.005秒」で動くのか？（コード解説）

サーバー（dashboard_server.py）側の実装は非常にシンプルです。

# Obsidianフォルダ内の朝刊ノートを最新順に取得
obsidian_inbox = PROJECT_ROOT / "Obsidian_Notes/00_Inbox"
brief_files = sorted(list(obsidian_inbox.glob("Daily_Tech_Brief_*.md")), reverse=True)

# 1年分（365ファイル）あっても、最初の30件しか読み込まない
logs = []
for bf in brief_files[:30]:
    with open(bf, "r", encoding="utf-8") as f:
        content = f.read()

    # Frontmatterや見出しを正規表現で高速パース
    fm_match = re.search(r"^---\n(.*?)\n---", content, re.DOTALL)
    # ... 各フィールドを抽出 ...
    logs.append({
        "date": date_str,
        "headline": headline,
        "topics": topics,
        "advice": advice
    })

# 数KBの超軽量JSONとしてブラウザに即時返却
return json.dumps(logs)

この設計により、ファイルが100本あろうと10,000本あろうと、サーバーが処理するのは常に「最新の30ファイル（数KB）」だけです。計算量は常に $O(1)$（一定）となり、1年後も一切重くなりません。

4. 第二の脳（Obsidian）と組み合わせる最大のメリット

この設計の真価は、ダッシュボードが速いことだけではありません。「情報がそのままObsidianの資産になる」 ことです。

  1. ノート同士のリンク:
    ブログやSNSを書く際、[[Daily_Tech_Brief_20260830]] とリンクを貼るだけで、その日のインプットを出典として参照できる。
  2. Dataviewプラグインでの自在な集計:
    Obsidian側で TABLE headline, date FROM #daily_brief と書くだけで、ノート内でも瞬時に一覧表が作れる。
  3. 完全なポータビリティ:
    すべてのデータがプレーンテキスト（Markdown）なので、将来ツールやサーバーを乗り換えても、大切な知識資産が1文字も失われない。

5. よくある質問（FAQ）

Q1. ファイル数が数千件になったら、フォルダのglob（一覧取得）自体が遅くなりませんか？

A. OSのファイルシステム（APFSやNTFS）において、数千件程度のファイル名一覧取得（os.listdir / glob）は数ミリ秒以下で完了します。中身を開くのは最新30件だけなので、実用上のボトルネックにはなりません。数年単位で数万件を超える場合は、年別フォルダ（2026/, 2027/）に自動仕分けするだけで完全にスケールします。

Q2. なぜSQLiteではなくMarkdownなのですか？

A. SQLiteは高速ですが、人間がテキストエディタで直接読んだり編集したりすることができません。思考の整理やブログ執筆のプラットフォームであるObsidianで直接開いてリンクを繋げられる「手触り」こそが、個人開発者にとって最大の生産性を生むためです。

6. まとめ：ツールを作るな、知識のエコシステムを作れ

自動化ツールを作る際、データの保存先を安易に「専用DB」にしてしまうと、ツールが増えるたびにデータが孤立していきます。

「データはすべてObsidian（第二の脳）という1つの器に集め、ツール側はそれを覗き見して便利に動かすだけにする」。

このSSOT思想を取り入れることで、あなたの個人開発は劇的にシンプルで、永続的なものに進化します。

タイトルとURLをコピーしました