ブログを長くやっていると、いつの間にか思考の順番が逆立ちしてくる。

本来は「作ったから書く」のはずだった。それがある時期から「書くために、何か作れることはないか」を探すようになっていた。ネタ帳を眺めて、PVが取れそうなキーワードから逆算して、その器に合う題材をひねり出す。記事が主で、行動が従。完全に主従が入れ替わっていた。

この記事は、その順番を元に戻した最初の一本だ。題材は大層なものではない。「自分が書いた記事のMarkdownを、コマンド一発でWordPressに下書き投入する道具」を作って動かした、それだけの話である。ただ、作る順番を正したら、副産物がそのまま記事になった。今あなたが読んでいるこの初稿も、その道具で投入されたものだ。

記事を「商品」だと思うのをやめた日

きっかけは、検索流入が静かに痩せていく体感だった。

数字の話は他所に詳しい人がいくらでもいるので深追いしないが、ざっくり言えば「『〜とは』『〜のやり方』で検索した人が、もう記事まで来ない」時代になりつつある。AIが検索結果の上で要約を返してしまうからだ。情報系の記事は、AIが無料で代わりに喋ってくれる。書き手としては「では私が書く意味は」と立ち止まらざるを得ない。

そこで考え方を一段ずらした。記事をPVで稼ぐ商品として扱うのをやめて、自分が実際に手を動かして作って動かしたものの記録に寄せる。AIが要約で溶かせるのは借り物の解説だけで、「私がこれを作って、こうハマって、こう直して、今も動いている」という痕跡は溶かせない。なら、そっちを書けばいい。

問題は、その路線だと「書くために作った感」が出た瞬間に嘘くさくなることだった。だから逆にした。作りたいものを作る。記録はそのおまけ。 今回はその実験第一号である。

思いつき：記事のMarkdownを、コマンド一発で流せないか

普段、文章はエディタでMarkdownで書いている。一方、公開先のWordPressは管理画面に貼り付けて整える。この「Markdownで書く」と「管理画面で貼る」の間に、地味に毎回手作業の谷がある。コピペして、ブロックがおかしくなって、直して、という例のやつだ。

ここをまたぎたかった。理想はこうだ。

手元のMarkdownファイルを指定して、コマンドを一回叩くと、WordPressに下書きとして記事が立つ。

公開はしない。あくまで下書きまで。最後の公開ボタンは自分の指で押したい。この線引きは後で効いてくるので覚えておいてほしい。

調べると、WordPressには標準でREST APIという出入口がある。外部からプログラムで記事を読み書きできる仕組みだ。これを使えば管理画面を経由せずに記事を投入できる。理屈の上では、の話だが。

まず疎通だけ確かめる：REST APIは本当に生きているか

新しい仕組みを相手にするとき、いきなり本番の機能を書き始めるのは悪手だと経験上知っている。まず「向こうが息をしているか」だけを確かめる。

WordPressのREST APIは、バージョン4.7以降は標準で有効になっている（※一次情報：WordPress REST API Handbook）。生きているかの確認はあっけないほど簡単で、ブラウザで 自分のドメイン/wp-json/wp/v2/posts を開いてJSONがズラッと返ってくれば、もう動いている。

次に認証だ。記事を読むだけなら認証は要らないが、書き込むには「お前は誰だ」を通す必要がある。ここで使うのが Application Password という仕組みだった。WordPress 5.6からコアに標準同梱されている機能で、プラグインを足さなくていい（※一次情報：Authentication — REST API Handbook）。管理画面の ユーザー → プロフィール編集 の下の方に、専用のパスワードを発行する欄がひっそり用意されている。

発行すると、スペース区切りの呪文みたいな文字列が一度だけ表示される。これを控えて、HTTPS経由でBasic認証として渡す。普段のログインパスワードとは別物なので、漏れても本体は無事だし、要らなくなったら個別に失効できる。よくできている。

ここまでで、まず「読む」だけの最小スクリプトを書いた。下書き一覧を取得するだけ。私の環境では、これがあっさり通った。向こうは確かに息をしていた。第一関門突破である。

つまずきメモ：認証・権限・SANGOブロックの三つの壁

……と、ここまで読むとスルスル進んだように見えるが、当然そんなわけはない。三回まあまあ派手に転んだ。供養も兼ねて書いておく。

壁その一：認証で401が返り続ける。 最初、Application Passwordをコピーするときに、表示されたスペースをご丁寧に全部詰めて貼っていた。あの呪文、スペースもセットで意味があるのか・ないのか確信が持てず、結果として認証が通らない。「公式に標準機能だと書いてあるのに通らない、ということは私の理解が間違っている」と腹をくくって素直に確認したら、渡し方の問題だった。新しい仕組みを疑う前に自分を疑え、という毎度の教訓。

壁その二：誰の権限で書いているのか問題。 読むのは通っても、書く権限があるかは別の話だ。投稿を作成・更新できるのは、その操作に足る権限を持ったユーザーに限られる。私の環境では管理者ユーザーで叩いていたので投稿・更新とも通ったが、これは「公式仕様」ではなく「私の環境ではこうだった」という実測である。同じことをやる人は、自分のユーザーの権限を一度確認した方がいい。

壁その三：SANGOブロックの呪い。 これが地味に一番効いた。set-ten.comは長らくSANGOというテーマを使っていて、過去記事の本文はSANGO独自のブロックで埋め尽くされている。最初、その作法に寄せて投入しようとして崩れた。考えてみれば当たり前で、テーマ固有のブロックはテーマを替えた瞬間に全部ただのゴミになる。今回は脱SANGOも見据えていたので、ここで方針を固めた——投入する本文は、テーマに依存しない標準的な形式に限る。 特定テーマに魂を売らない。これで、将来テーマを替えても本文は生き残る。怪我の功名だった。

3モード1スクリプトに落ち着いた理由

機能を考えていくと、欲しい動作は三つに整理できた。

1. read：今ある下書きの一覧を読む（疎通確認とデバッグ用）
2. post-test：ダミーの下書きを一件だけ投入してみる（書き込み権限の確認用）
3. from-md：指定したMarkdownファイルを下書きとして投入する（本番）

これを最初、別々のスクリプトに分けるか迷った。だが分けると、共通する認証処理や接続設定が三箇所に散らばってメンテが面倒になる。結局、一本のスクリプトに第一引数でモードを切り替える形に落ち着いた。read post-test from-md を引数で渡し分けるだけ。共通部分は一箇所、差分はモードごとの関数に閉じる。地味だが、後で自分が読み返したとき一番事故りにくい構成だと思っている。

派手なフレームワークは使っていない。Pythonの世界でHTTPを叩く定番ライブラリと、Markdownを変換する定番ライブラリの二つだけ。理由は次に書く。

安全装置：なぜ全部draft既定で、公開は人間がやるのか

このスクリプト、全モードで投入時のステータスを下書き（draft）に固定している。 公開（publish）は一切やらない。

REST APIの仕様上は、ステータスに publish（公開）も draft（下書き）も指定できる（※一次情報：Posts — REST API Handbook のステータス一覧）。つまり「コマンド一発で公開」も技術的には可能だ。だが、あえてやらない。

理由は単純で、自動化していい工程と、人間が最後に見るべき工程は違うからだ。Markdownを変換して投入する、という機械的な作業は自動化していい。だが「これを世に出すか」の最終判断は、コマンドの勢いで通していいものではない。誤字、事実誤認、出す前に気が変わる——どれも、公開ボタンを自分の指で押す一拍があれば防げる。

自動化の設計で一番大事なのは「どこまでを機械に渡し、どこからを人間が握るか」の線引きだと思っている。全部自動が偉いわけではない。今回はその線を「投入＝機械／公開＝人間」に引いた。

鍵をリポジトリに置かない：認証情報を環境変数に逃がす

もう一つの設計判断。認証情報（ユーザー名とApplication Password）を、スクリプトにもリポジトリにも一切書いていない。 環境変数から読む形にしている。

これは半ば常識だが、常識ほど事故が起きる。コードに直接パスワードを書くと、それをうっかりGitにコミットした瞬間に、履歴に永久に刻まれる。後から消しても履歴には残る。set-ten.comのリポジトリはプライベートだが、「プライベートだから大丈夫」で鍵を平文で置くのは、鍵を玄関マットの下に隠すのと同じ発想だ。

なので、スクリプトは起動時に環境変数を読みに行くだけ。鍵そのものは自分の手元の環境にしか存在しない。リポジトリには「環境変数から読みます」という事実しか書かれていない。これなら万一リポジトリが流出しても、鍵は流出しない。

実際に動かす：この記事の初稿を、その道具で下書き投入した

さて、ここが今回の一番の見どころだ。

このスクリプトの最初の本番投入対象は、ダミー記事でも過去記事でもなく、今あなたが読んでいる、この記事そのものだった。手元でこの原稿をMarkdownで書き終え、from-md モードにファイルを渡して、下書きとして投入した。

自分の作った道具で、その道具について書いた記事を、自分のブログに立てる。

ちょっとした再帰というか、蛇が自分の尻尾を咥えているような構図で、書いていて少し笑った。デモのためのデモではなく、実際の制作物が実際の仕事をこなした瞬間だ。設計書に書いた「作った副産物が勝手にネタになる」が、文字通り目の前で起きた。

正直に補足しておく。この道具がやったのは「初稿の投入」までだ。 投入後、この文章を管理画面で読み返し、手を入れて整えてから公開している。つまり今の完成形そのものをコマンドが吐いたわけではない。from-mdモードは投入専用で、投入後の更新は別の操作になる（更新自体はREST API上は POST /wp/v2/posts/<id> で可能だが、今回の道具にはまだ積んでいない）。「全自動でこの記事が出来上がった」と書いた方が話は派手だが、それは事実と違う。動く証拠で語ると決めた以上、ここは正確に書く。

一次情報メモ（出典）

この記事で技術仕様に触れた箇所の裏取り先を残しておく。執筆時点での確認である。

• WordPress REST API のエンドポイント・投稿ステータスの一覧：Posts – REST API Handbook
• Application Password とBasic認証での渡し方：Authentication – REST API Handbook

一方で、「管理者ユーザーで投稿・更新が通った」「セキュリティ系プラグインにブロックされなかった」「タイムゾーンが想定通りだった」といった点は、公式仕様ではなく私の環境での実測だ。サーバーの設定やプラグイン構成で変わりうるので、同じことを試す人は自分の環境で確かめてほしい。

次に作るもの、と方針の答え合わせ

冒頭で「作る順番を正したら副産物が記事になった」と書いた。実際にやってみての答え合わせをすると、想像以上に手応えがあった。

ネタを探して書いた記事は、書いている間ずっと「これ需要あるかな」という不安がつきまとう。だが今回は違った。まず自分が欲しい道具を作って、現に動いて、その過程をそのまま書いただけだ。需要を当てにいっていないから、外しても痛くない。そして借り物ではないから、AIに要約で溶かされない。少なくとも、書いていて嘘がなかった。

次は、この道具自身を育てる方向と、別の道具を作る方向、両方が見えている。投入だけでなく更新も叩けるようにするのか、画像の扱いをどうするのか——課題はまだある。だがそれも、作って動かして詰まったら、また記録すればいい。

作る。動かす。詰まる。直す。書く。この順番でしばらく回してみる。

Live long and learn.

The post 「ネタのために作る」のをやめた——自分で動かした道具が、勝手に記事になるまで first appeared on SetTen.

ローカルの config.yaml で published: false を true に書き換えて、Sync Changes のボタンを押すまでに、5 回くらい読み直しました。設定ミスで「全章無料公開」を一発でやらかすパターンを避けるため、というのは半分本当で、もう半分は、たぶん単に手を止めたかっただけです。

書きました、出ました。『Claude Code で LLM Wiki を育てる——第二の脳の作り方』、Zenn Book として公開されています。

出ました

Zenn Book ページを見る

• タイトル：Claude Code で LLM Wiki を育てる——第二の脳の作り方
• 全 9 章 / Freemium 構成（前半 3 章は無料）
• 価格：500 円
• 公開日：2026 年 5 月 10 日（日）

当初は 6 月末公開でアナウンスしていたのですが、執筆・推敲・レビューがすべて想定より早く片付いたので、前倒して今日にしました。「準備が整ったらすぐ出す」のは、一人開発・一人執筆の身軽な特権だと思っています。

この本は、何を実装した記録か

きっかけは Andrej Karpathy 氏が 2026 年 4 月 4 日に GitHub Gist で公開した llm-wiki.md という Markdown 1 枚です（原典 Gist はこちら）。

簡単に要約するとこうです（私の理解）。質問のたびに RAG でゼロから検索し直す代わりに、素材を読んだタイミングで LLM が構造化済みの「Wiki」に書き出しておけば、知識は読むほど複利で積み上がる、というアイデア。Karpathy 自身が idea file と呼ぶ形式で、実装は読み手の LLM エージェントに任せる、という前提の文書です。

本書は、その idea file を私なりに咀嚼して、Claude Code と Obsidian、cron、iCloud Drive で自分の Mac mini 上に実装し、1 週間動かしてみた運用記録です。Karpathy 公認でも Karpathy 監修でもありません。一人のエンジニアが Gist を読んで「これ、自分の環境で動かしたらどうなるか」を試した、それだけの本です。

ただ、動かしてみたら、思った以上に面白い変化が起きました。詳しい背景や設計思想は紹介記事にまとめているので、こちらもよろしければ。

公開してみての心境

執筆 9 章ぶん、推敲も一通り終わって、NotebookLM でのレビューも問題なし——という確認を経ても、「本当に出していいんだろうか」とは何度も思いました。

技術書を書くのは初めてではないですが、有料書籍として 500 円とはいえお金を取る形で出すのは初めてです。書いた本人としては「これで動く」「これで複利が回る」と確信を持って書いた内容ばかりですが、読み手にとってどう映るかは、実際に読まれてみないとわかりません。

最初の購入者が現れたら、たぶん挙動不審な顔で Zenn ダッシュボードを開いて、その人の存在を確認します。お金が動くのを確認するためではなく、「ああ、誰かが読み始めてくれた」という事実を実感するためです。

そういう種類の不安と高揚の混ざった気持ちを、いま味わっているところです。

これから出す補足記事の予告

書籍本体に書ききれなかった話や、本文を追加でどう活用するかの話を、補足記事として 3 本ほど予定しています。

• 第 5 章（RSS 自動収集）の実装小ネタ
• 第 6・7 章（Mac mini cron × デイリーダイジェスト）でハマったポイント
• 公開して 1 週間後の振り返り——読者反応や予想外の使われ方など

順次このブログで公開していきます。書籍を買わなくても読める内容にする予定なので、書籍が「自分には合わなさそう」と思った方も、補足記事だけ拾ってもらえれば嬉しいです。

ブックマークしてくれた方へ

紹介記事を読んで「ブックマークだけしておく」と言ってくれた方、ありがとうございます。当初の予告より少し早い公開になりましたが、その分、待たせる時間を最小化したかったというのが本音です。

書籍ページの「いいね」、または X で気になった引用ポストへのリアクション、感想ツイート、いずれの形でも反応を見つけたら、たぶん飛び上がって喜びます。タグは #LLMWiki に揃えてあります。

最後に

「読書×行動」の構造を、技術で自動化したらどうなるか——その問いに対する、現時点での自分の答えがこの 1 冊です。

公開直前まで悩んだ細部（章構成・無料範囲・価格）も、すべて含めて 9 章として並べてあります。気になる方はぜひ、無料章だけでも目を通してみてください。

Zenn Book ページを見る

class Publication:
    def __init__(self):
        self.title = "Claude Code で LLM Wiki を育てる——第二の脳の作り方"
        self.chapters = 9
        self.free_chapters = 3
        self.price = 500
        self.status = "draft"
        self.mood = "nervous_and_excited"

    def read_gist(self):
        self.inspiration = "karpathy/llm-wiki.md"
        print("Karpathy 氏の Gist を読む。「これ、自分で動かしたらどうなる？」")

    def implement(self):
        self.stack = ["Claude Code", "Obsidian", "cron", "iCloud Drive", "Mac mini"]
        print("Mac mini 上で第二の脳を 1 週間動かしてみる。")

    def write_book(self):
        self.status = "writing"
        print(f"運用記録を全 {self.chapters} 章にまとめる。")

    def proofread(self):
        print("推敲、NotebookLM レビュー、再推敲。")

    def publish(self):
        # config.yaml の published: false → true を 5 回読み直し
        for _ in range(5):
            assert self.free_chapters < self.chapters, "全章無料公開、回避！"
        self.status = "published"
        print("published: false → true、Sync Changes。")
        print(f"Zenn Book 公開：全 {self.chapters} 章 / 前 {self.free_chapters} 章無料 / {self.price} 円")

    def wait_for_first_reader(self):
        if self.status == "published":
            print("挙動不審な顔で Zenn ダッシュボードをリロード中…")

try:
    book = Publication()
    book.read_gist()
    book.implement()
    book.write_book()
    book.proofread()
    book.publish()
    book.wait_for_first_reader()
except Exception as e:
    print("公開直前にバグ発生。コーヒーを淹れ直して再挑戦します。")
finally:
    print("🖖 Live long and learn.")

Live long and learn.

The post 出版報告：『Claude Code で LLM Wiki を育てる——第二の脳の作り方』Zenn Book で公開しました first appeared on SetTen.

ブログ『スキルアップ専門学校』の看板にしている「読書×行動」を、ついに 自動化のレイヤーまで持ち込めるんじゃないか と思える本を書いています。タイトルは 『Claude Code で LLM Wiki を育てる——第二の脳の作り方』、Zenn Book で 2026 年 5 月 10 日（日）公開予定、500 円の Freemium 構成（前半 3 章は無料）です。

執筆と推敲は一通り終わり、いまは実機検証と補足記事（この記事もその 1 本目）を並走させながら、正式公開に向けて準備しているところです。

参考 Claude Code で LLM Wiki を育てる——第二の脳の作り方Zenn

書籍ページの方では現状メタ情報のみ公開していて、各章の本文はまだ並んでいません。気になる方は 事前にブックマークだけしておいてもらえると嬉しい です。以下、何を書いている本なのか、なぜ書いているのか、誰に届けたいのかをまとめます。

Karpathy が 2026 年 4 月に投げた「LLM Wiki」という石

きっかけは 2026 年 4 月 4 日、Andrej Karpathy 氏（OpenAI 創立メンバー・元 Tesla AI 部門ディレクター）が公開した GitHub Gist 1 枚でした。ファイル名は llm-wiki.md、ただのメモです。Karpathy 自身が idea file と呼ぶ形式——実装コードではなく、考え方だけを書いた Markdown 1 枚を、読み手の LLM エージェントに渡して各自の環境で実装してもらう、という前提の文書です。

主張を雑に要約するとこうなります。

知識を、質問のたびにゼロから検索し直すのをやめよう。LLM が読んで、書いて、育てる「Wiki」に一度コンパイルして、以降はそれを参照すれば、学びは複利で積み上がる。

これ、地味に強い提案です。RAG（Retrieval-Augmented Generation）は質問が来るたびに関連文書を検索しますが、回答は毎回その場限り で消えます。同じことを来月聞いたら、また同じ検索からやり直し。学びは積み上がりません。

LLM Wiki のアプローチは逆で、素材を読んだタイミングで構造化済みのページにしておき、質問が来たらその Wiki を引く。前払いするか後払いするかの違いですが、情報の積み上がり方が根本から変わります。エンジニア用語で言えば「実行時計算を事前計算に寄せる」「キャッシュを永続化する」、それだけです。

私が反応したのはこの 「複利」 の一点でした。氷河期世代で独学からエンジニアになり、以降ずっとリスキリングを繰り返してきた人間として、このブログでも一貫して「読書×行動でスキルアップ」と言ってきた。学んだものを読むだけで終わらせず、積み上げて次に繋げる——LLM Wiki が提案している構造は、この「積み上げ」をついに個人の情報収集レベルで実装可能にしたように見えました。

自分で 1 週間動かしてみたらこうなった

Gist を読んで「面白いな」で終わらせず、Claude Code を使って実装し、1 週間ほど動かしてきました。現在の状態はこんな感じです。

• 毎朝 7:00 に Mac mini の cron が起動、10 フィード・3 ジャンルから RSS を取得して raw/articles/ に自動保存
• 毎朝 7:30 にデイリーダイジェストが自動生成、当日の新着トップ 5 とブログネタ候補 3 件が outputs/ に書き出される
• 毎週日曜 6:00 にウィークリーレポートが自動生成、ジャンル別トップ・新規 Wiki ページ・壊れたリンクが一枚にまとまる
• 気になる記事を Claude Code に compile と頼むと、1 本の記事から 10〜15 の Wiki ページが連動して更新される
• MacBook・Mac mini・iPad で同じ Wiki が共有され、ソファで iPad を開けば昨夜追加された整理を読める

数字で言うと、100 本超の記事 から 74 ページの概念ネットワーク まで育っています。最初の 17 本を compile した夜に 30 ページが一気に生成され、そこから記事を足しながら育ててきた結果です。

仕組みとして使っているのは、特殊なサービスでも最新 SDK でもありません。Claude Code、Python（feedparser・markdownify）、cron、Obsidian、iCloud Drive——全部 2026 年以前から存在する枯れた部品ばかりで、月額数千円以下、または無料枠で回せる範囲に収まります。

派手な技術スタックではなく、ありもので組む というのが本書のスタンスです。

本書の中身——9 章 / Freemium 構成

全 9 章、3 ブロック構成です。

ブロック A: 概念と設計（無料）
  第1章 LLM Wiki とは何か——RAG の次に来たパラダイム
  第2章 全体像——3 層アーキテクチャと 3 つの操作
  第3章 環境構築——Claude Code × Obsidian × iCloud

ブロック B: 実装本編（有料）
  第4章 interest_profile を書く
  第5章 RSS 自動収集スクリプト
  第6章 Mac mini cron
  第7章 デイリーダイジェスト
  第8章 ウィークリーレポート + lint

ブロック C: 運用（有料）
  第9章 運用編——iOS 連携・トラブルシュート・拡張アイデア

ブロック A（1〜3 章）は無料 にしました。LLM Wiki の思想・アーキテクチャ・環境構築まで読めば、自分がこの仕組みを本当に欲しいか判断できる はずだからです。「面白そうだけど自分の運用には合わなさそう」と思ったら無料で離脱できる構造にしてあります。

実装に踏み込む段階で有料パートを買うかどうかを決めてもらえれば、書き手としては十分に納得感のある取引かなと思っています。

こんな人に届くと嬉しい

第一ターゲットは Claude Code に触れ始めた、あるいはこれから本格的に使いたい中級エンジニア です。具体的には：

• Web エンジニア・SE として 3〜8 年目くらい
• macOS・zsh・VS Code・Git は日常の道具
• Python は書ける、スクリプト化に抵抗がない
• Claude Code は触ったことはある。業務にどう組み込むかで悩んでいる
• 「LLM で何か実用的な自動化を組みたい」という技術的好奇心がある

逆に、Claude Code の基本操作から知りたい初学者には少し厳しい本です（公式ドキュメントの方が親切）。チームでのナレッジマネジメント検討にも向きません（あくまで個人用の設計）。

ただ、第 5 章・第 7 章・第 8 章の実装そのものは汎用的 なので、切り出して使ってもらう分には全く問題ないです。「RSS 集めて毎朝レポート出すスクリプトだけ拝借する」という読み方も大歓迎です。

公開予定と価格

• 公開予定: 2026 年 5 月 10 日（日）（全 9 章一括公開）
• 価格: 500 円（ブロック A の 1〜3 章は無料）
• 形式: Zenn Book

Zenn Book ページを見る

公開時点で「事前にブックマークしてくれていた人がいる」状態に持っていきたい、というのが正直な気持ちです。書籍ページの方は現状メタ情報のみですが、進捗があり次第、このブログで告知していきます。

set-ten.com 読者へ——「読書×行動」の技術的実装版

このブログを以前から読んでくれている方には、本書の位置付けを「いつもの『読書×行動』を、技術で自動化したらこうなった」と捉えてもらえると、たぶん一番しっくりきます。

「読書」は RSS 自動収集と Wiki への compile に置き換わり、「行動」は毎朝のダイジェスト＋ブログネタ候補を起点にした執筆・実装に置き換わる。スキルアップのループそのものを仕組み化する、というのが本書の隠れたメッセージです。

ループが回り始めると、「今日は何を書こう」と悩む時間が 構造的に消える——これが、1 週間動かしてみて一番効いた変化でした。

書籍が出たら改めて告知します。それまでに補足記事を 4 本ほど予定していて、第 5 章（RSS 収集）の実装小ネタや、Mac mini で cron を回すときのハマりどころ、公開直前のプレビューといったあたりを、このブログ側で順次出していくつもりです。

おまけ

class LLMWiki:
    def __init__(self):
        self.raw_articles = 0
        self.wiki_pages = 0
        self.interest_profile = "未記入"
        self.compound_factor = 1.0
        self.dream = "blog_idea_runs_out_of_stock"  # ブログネタ切れからの卒業

    def write_interest_profile(self):
        self.interest_profile = "AI / 副業 / 技術書 / Star Trek"
        print("自分の興味を Markdown 1 枚に言語化。")

    def ingest_rss(self, feeds=10):
        # 毎朝 7:00、Mac mini cron 起動
        self.raw_articles += feeds * 10
        print(f"RSS から {self.raw_articles} 本を raw/ に保存。")

    def compile_with_claude_code(self):
        # raw/ を Claude Code が読み、wiki ページに構造化
        new_pages = self.raw_articles * 4 // 10
        self.wiki_pages += new_pages
        self.compound_factor *= 1.05
        print(f"wiki/ に {self.wiki_pages} ページ。読むたび複利で育つ。")

    def generate_daily_digest(self):
        # 毎朝 7:30、outputs/ にブログネタが自動で出る
        if self.wiki_pages > 0:
            print("今日のブログネタ候補 3 件が outputs/ に書き出されました。")
            self.dream = "achieved"

    def write_zenn_book(self):
        if self.dream == "achieved":
            print("Zenn Book『Claude Code で LLM Wiki を育てる』執筆中 → 2026-05-10 公開。")
            print("価格: 500円 / Freemium (前半 3 章は無料)。")

try:
    wiki = LLMWiki()
    wiki.write_interest_profile()
    wiki.ingest_rss()
    wiki.compile_with_claude_code()
    wiki.generate_daily_digest()
    wiki.write_zenn_book()
except Exception as e:
    print("RAG で同じ質問を繰り返している場合は、Wiki にコンパイルしてください。")
finally:
    print("🖖 Live long and learn.")

wiki.compile_with_claude_code() のループが回り始めると、ブログネタ切れに悩む時間が 構造的に消えて いきます。本書はこのループを 1 週間で組み上げるための手順書です。

The post Zenn Book 執筆中：『Claude Code で LLM Wiki を育てる——第二の脳の作り方』 first appeared on SetTen.