Obsidian → LLM Wiki → HTML → AI Deploy
Obsidian のメモが、勝手に記事になる。
毎日 daily/ にラフを投げ続けるだけで、AI が裏で wiki を育て、HTML Artifact を ja / en で書き、Web に公開してくれる。書く労力は最小、出てくるものは最大。第二の脳の発信パイプラインを AI で爆速化するメモ。
CONTENTS10 sections
Obsidian のメモを毎日投げ続けるだけで、勝手に記事になって外に出ている。AI が裏で wiki を育て、HTML を ja / en で書き、公開先まで運んでくれる。
- Obsidian は 雑多に放り込む入力場。daily ノートを毎日ラフに書き散らす。
- それを Claude Code が LLM Wiki（Karpathy 式 第二の脳）として育てる。
- 発信は Zenn / Qiita ではなく、AI に HTML Artifact を生成させて静的ホストにデプロイ。
- 同じ仕組みで ja / en の多言語化 もワンソースから無料で手に入る。
- Markdown / YAML / グラフは AI 用、HTML / SVG は人間用という役割分離が起きている（Anthropic Claude Code チームも同趣旨を発信）。
なぜ Zenn / Qiita を「最終出力」にしないのか
Zenn / Qiita は強い。SEO もあるし、技術コミュニティの導線にもなる。ただし「最終的に読まれる Artifact」としては、いくつかの限界がある。
| Markdown 記事（Zenn/Qiita） | HTML Artifact（自前） | |
|---|---|---|
| 図の自由度 | 低い（画像差し込み） | SVG / アニメ / インタラクティブ |
| 構造の見せ方 | 線形（上から下） | グラフ / hover / zoom / 段階表示 |
| デザイン制 | テーマ固定 | 完全自由 |
| AI 生成 | テキスト中心 | Artifact 丸ごと生成可能 |
| 多言語化 | 記事を別途書き直し | ワンソースから ja / en 同時生成 |
| 更新コスト | 手で書く | LLM Wiki から再生成 |
ポイントは「AI 時代の強い表現は HTML / SVG / Interactive UI であり、Markdown はその入力に位置を下げた」こと。Zenn / Qiita は廃止しない。問題提起・1 枚図・軽い導入を置き、本体は自前 HTML へ誘導する役割分担にする。
AI が読む形式 / 人間が読む形式
これは Anthropic Claude Code チーム（Thariq 氏ら）も発信している論点で、ざっくりこう整理されている：
AI エージェントの出力が大規模化（1000 行超）するにつれ、Markdown の「長文壁」が深刻化した。100 行を超えるとほぼ読まれない。
Markdown は AI が読む資料、HTML は人間が読む資料、という棲み分けが進んでいる。
これを少し抽象化すると、こういう二分法になる。
| AI が読む形式 | 人間が読む形式 | |
|---|---|---|
| 代表例 | Markdown / YAML / JSON / グラフ | HTML / SVG / React / UI |
| 強み | トークン効率、構造解析、差分管理 | 視覚密度、レイアウト、即時理解 |
| 弱み | スクロール量、図の弱さ、読む努力 | トークン重い、git 差分しづらい |
| 役割 | AI への入力 / AI 間の中間表現 | 人間への最終 Artifact |
AI が育てる層は Markdown / YAML / グラフで保ち、人間が読む層だけ HTML / SVG に変換する。 同じ情報を両方で持たず、変換可能な単一ソースから都度生成する。
全体像：4 フェーズのパイプライン
ここからは、Obsidian の雑多な入力が Web 上の HTML Artifact になるまでを、4 つのフェーズに分けて見ていく。
- Phase 1 — Obsidian で雑多に集める：daily に殴り書き。AI は触らない
- Phase 2 — LLM Wiki 化（Karpathy 式 第二の脳）：Schema / Wiki / Raw の 3 層で Claude が育てる
- Phase 3 — HTML 化 ＋ 多言語化：AI に Artifact を書かせる。ja / en をワンソースから
- Phase 4 — AI でデプロイ：CLI / MCP で公開、人間はダッシュボードを開かない
Phase 1 ── Obsidian で雑多に集める
>1-1グラフを「未来の設計図」として使う
Obsidian の Graph View は、書いたノートの関係を表示するためのものとして扱われがちだが、もっと面白い使い方がある。
書いた瞬間に[[未作成のリンク]]を貼っておくと、Graph に "🌱 まだ存在しないノード" が芽吹く。
後から芽の濃いものだけを実体ノートに育てればいい。
これは Karpathy が示唆した「LLM Wiki は dangling link を起点に育てる」運用と整合する。グラフは過去の蓄積を眺める道具ではなく、未来のノードを設計する道具になる。
>1-2daily/ に殴り書く
- 階層は浅く
daily/<YYYY>/<YYYYMMDD>/*.mdだけ - タグもリンクも frontmatter も書かないで OK
- 整形しない、誤字も気にしない、矛盾も OK
「汚いラフな方が入力の意欲はわく」というのが現場の真実で、ここを AI に整理させた瞬間、入力意欲が死ぬ。
>1-3AI には「サジェストのみ」させる
整理・タグ付け・リンク張りは AI が提案、人間が採用 という構造にする。これにより daily/ は常に「自分の脳の一次出力」のまま残り、LLM Wiki 側が二次的に育つ。
Phase 2 ── LLM Wiki 化（Karpathy 式 第二の脳）
ここから AI が能動的に動く。Andrej Karpathy が提唱した LLM Wiki の構成をそのまま採用する。
>2-13 層アーキテクチャ
役割分担：人間はキュレーション・分析・良い問いを立てる、LLM は要約・リンク・整合性維持・矛盾記録。
>2-23 つのコア操作
>2-3矛盾は「消さずに並列保持」する
同じテーマで違う日付の違うノートが出てきても、統合・削除しない。知識の変化として両方残し、各 MOC の「日付別ノード」に追記する。どちらが「正」かはユーザーが決める。
AI に整理を任せると、便利な一方で「自分の思考の履歴」が消える。Karpathy 式は 複利的に蓄積する ことを最重要視する。矛盾そのものが思考の足跡になる。
Phase 3 ── HTML 化 ＋ 多言語化
>3-1なぜ HTML か
「読む努力」を要求するコンテンツは AI 時代に弱い。読む → 理解するから 見る → 触る → 必要箇所だけ深掘る へとシフトしている。HTML は以下を 1 枚に同居できる：
- インタラクティブな図（SVG、hover、zoom）
- 段階表示（クリックで展開）
- アニメーション（概念の動きを見せる）
- グラフ構造（ノード間の関係を可視化）
- 埋め込み Playground（その場で試せる）
>3-2AI に丸ごと書かせる
Claude Code に LLM Wiki と一緒に「この MOC を HTML 1 枚に変換して」と指示すると、構造化済み Markdown を読み、図示できる箇所を SVG で起こし、ナビゲーション付きの 1 枚 HTML を吐く、ところまで一気に行ける。人間は構造設計と最終チェックだけ。
Claude Code Fancy HTML Hook のような PostToolUse hook で md → HTML を自動生成する仕組みまで足せば、md を保存した瞬間にビジュアル化された HTML が並走する。
>3-3多言語化は「おまけ」でついてくる
もともと「個人の発信を海外にも届けたい」という動機があったが、AI に HTML を書かせる仕組みを組んだ瞬間、多言語化は無料の副産物になった。
同じ MD ソースから AI が HTML を生成するなら、その途中で言語切替も同時にやれる。
機械翻訳は文構造を引きずるので、英語として自然な記事にならない。LLM Wiki に蓄えた構造化された一次情報を渡し、「英語圏読者向けに en.html を書け」と命じると、AI は言語ごとに記事を再構成する。トピック順、例示、たとえ話まで言語文化に合わせて差し替わる。
>3-4配置ルール
vault 内に専用フォルダ（例：external-cloudflare/）を切り、公開していい HTML だけをここに入れる。knowledge/ や daily/ は機密性が高いので、絶対にここへコピーしない。
Phase 4 ── AI でデプロイする
生成された HTML は、最終的に AI から CLI または MCP を叩いてホスティングに上げるだけで公開できる。Netlify / GitHub Pages / Vercel / Cloudflare Pages / S3 + CloudFront など、静的サイトを CLI または MCP で扱えるホストならどれでもいい。自分の手に馴染んでいるサービスを選べばいい。
ここで重要なのは「手順」より「人間がダッシュボードを開かない」という体験のほうで、書き手から見た流れはこうなる：
人間 → daily/ にラフ投入
↓
Claude → knowledge/ を更新
↓
人間「これ HTML にして公開して」
↓
Claude → ja.html ＋ en.html を生成 → 任意のホストに CLI/MCP でデプロイ → 公開 URL を返す
人間が触るのは「自然言語の指示」と「ラフな daily 入力」だけ。デプロイの具体的な設定手順は別記事に分離する。
雑多を貯め続けるだけで、勝手に記事が降りてくる
このパイプラインが本当に強いのは、「記事を書く」という意識をしなくていいところにある。
毎日 daily/ に思いついたことを殴り書く。それだけ。文章として整っている必要も、リンクが張られている必要もない。続けていくと、Claude が裏で勝手にテーマを束ねて MOC を作り、矛盾を並列保持し、グラフを育てる。
ある日「最近この話どうなった？」と尋ねると、AI が wiki から抽出して清書済みの HTML 記事を ja / en で返してくる。気づくと、自分の脳の一部が静かに Web 上の Artifact として常時公開されている。
これは「ブログを書く」というワークフローではなく、自分の思考そのものを、AI が日々清書し続けてくれる状態。書く側の認知負荷はほぼゼロ、出てくる成果物は HTML / 多言語 / インタラクティブ。
ノートを書くこと＝発信になる。
Zenn / Qiita との使い分け
旧来の「Zenn / Qiita に長文を書く」は捨てない。役割を変える。
Zenn や Qiita を 最終出力 にするのは前述のとおり弱いが、入口としては今でも強い。検索や技術コミュニティ経由で初めて読み手に届くのは、自前ホストの URL より圧倒的にこれらのプラットフォームのほう。SEO もコミュニティ濃度もこちらに優位がある。
なので運用としては、Zenn / Qiita には「要点だけ短く・1 枚図入り・問題提起寄り」の導入記事を置き、本体の HTML Artifact へ誘導する形にする。Zenn / Qiita 側で 到達を稼ぎ、自前 HTML 側で 深い体験を出す、という二段構え。
「同じ記事を 2 か所に書くのは無駄では？」と思うかもしれないが、入口と本体は表現の粒度が違うので二重投稿にはならない。入口は 「読まれるための圧縮版」、本体は 「触られる完全版」。役割を分けるとそれぞれ無理なく書ける。
Zenn / Qiita に置く 導入記事：問題提起 + 結論の 1 文 + 重要な 1 枚図 + 自前 HTML への CTA。500〜1000 字程度。
自前 HTML 側の 本体：図解・SVG・インタラクティブ要素・多言語版・コードサンプル込みのフルバージョン。LLM Wiki から AI が組み立てる。
まとめ：本質的に何が変わったか
| 旧 | 新 | |
|---|---|---|
| 書く | 人間が PowerPoint / HTML / 記事を作る | AI が Artifact を生成する |
| 集める | 整理しながら書く | 雑多に投入し、AI が整理する |
| 出す | Markdown 記事を Zenn / Qiita に手で書く | HTML を AI に書かせて CLI / MCP でデプロイ |
| 翻訳 | 記事ごとに別作業 | ワンソースから ja / en 並列生成 |
| 読む | 上から下に読む | 見る・触る・必要箇所だけ深掘る |
第二の脳（Obsidian ＋ LLM Wiki）から Web 上の HTML Artifact までを1 本のパイプラインとして組み上げると、
- 入力意欲が落ちない（ラフでいい）
- 知識が複利で貯まる（消さずに並列保持）
- 発信が爆速（AI が Artifact 化＋多言語化＋デプロイ）
という三つが同時に手に入る。これは「ブログを書く」のではなく、自分の脳の一部を Web に常時投影するという新しい発信のあり方だと思っている。