articles.dbが生まれた経緯は、別の記事に書いた。
→ 記事リスト.txtをClaudeに渡したら、AIリサーチャーが生まれた
記事リストをDBにしたのは、毎回コピペするのが面倒だったからだ。
大した理由じゃない。
でもDBができてから、見えるようになったものがある。
感覚では気づけなかったものだ。
今日はその話をする。
ブログを感覚で見ていた頃と、台帳で見るようになってからの違いを書く。
この記事で見ているのは、公開後に1本ずつ登録する手順ではない。
ブログ全体を台帳として見られるようにしたことで、孤立記事やシリーズの抜けに気づけるようになった話である。
公開後に1本の記事を articles.db へ残した実例は、後の記事「投稿後にDB登録したら、記事が資産として残り始めた」で書いた。
感覚で見ていたころ、孤立記事に気づかなかった
記事が5本くらいのときは、頭の中に全部入っていた。
「S1-1が止まる話で、S1-2がオブジェクト指向で、S1-3が役職の話で」
目を閉じても順番が出てきた。
でも10本を超えたあたりで、おかしくなった。
「S1-3って、S1-1から内部リンク張ってたっけ」
「この記事、どこからも繋がってないかもしれない」
感覚の地図が、記事の増え方に追いつかなくなっていた。
あるとき、articles.dbをClaudeに読ませて「孤立している記事がないか確認して」と言った。
3本あった。
公開してから一度も内部リンクを張られていない記事が、3本あった。
存在を忘れていたわけじゃない。
でも「孤立している」という事実は、感覚には現れていなかった。
孤立記事は、台帳を開くまで見えない。
台帳とは「全体を一行で見ること」だ
台帳という言葉を使っているのには理由がある。
帳簿だ。
昔の商人は、仕入れた物・売った物・在庫を1行ずつ帳簿に書いた。
一覧にするから「今何があるか」「何が足りないか」が見えた。
俺がやっていることはそれと同じだ。
記事を「感覚で管理する」のは、在庫を頭の中だけで把握しようとするようなものだ。
10本くらいなら覚えていられる。
でも50本になったとき、どうする。
台帳は「全体を一行で見る」ための道具だ。
タイトルを並べたリストとは違う。
状態が見えること。それが重要だ。
どの記事が公開されていて、どこに繋がっていて、どこが孤立しているか。
それが一覧で見えること。
それが台帳だ。
在庫を頭で把握しようとするから、見えなくなる。
ブログ管理用のarticles.dbに何を持たせているか
記事1本につき、1行のデータがある。
| フィールド | 中身 |
|—|—|
| slug | 記事のURL末尾。一意な識別子 |
| title | 記事タイトル |
| status | published / draft / planned のどれか |
| publish_date | 公開日 |
| internal_links | この記事に張られた内部リンクの数 |
これだけだ。
SQLiteというデータベース形式で保存している。
要するに、Excelのような表をファイル1つに収めたものだ。
「もっと色々管理した方がよくないか」と思うかもしれない。
でも俺はこの5項目から始めた。
多くしすぎると、更新が面倒になって使わなくなる。
最小で始めて、必要になったら足す。
それだけの話だ。
最初は5項目で十分だった。
DBで見ると、「次に何をするか」が決まる
DBをClaudeに読ませるようになって、変わったことがある。
「次に何をするか」が、感覚ではなく数字で決まるようになった。
例えばこうだ。
- internal_linksがゼロの記事が3本 → 内部リンクを張る
- statusがdraftのまま2週間以上経っている記事がある → 仕上げるか削除するか判断する
- 最新の記事が公開されてから、前後の記事へのリンクが足りていない → 繋ぐ
感覚でも気づけることはある。
でも「確かに存在する問題」として数字で見えると、後回しにできなくなる。
「なんとなく気になっていること」が「対処すべきリスト」になる。
やることが、静かに決まる。
数字は、迷いを消す。
作るのは難しくない。SQLiteで1テーブル
「データベース」と聞くと難しそうに聞こえる。
でも俺はプログラマーじゃない。
トラックドライバーだ。
Claude Codeに「記事を管理するSQLiteのDBを作って。フィールドはslug、title、status、publish_date、internal_linksの5つ」と言っただけで、DBができた。
SQLite、要するにファイル1つで動くデータベースだ。
articles.dbというファイルが手元にあるだけ。
サーバーもクラウドも要らない。
作るのに半日かかったとか、プログラミングを勉強したとか、そういう話じゃない。
AIに「作って」と言って、10分で終わった。
難しい部分は、もうない。
難しくなる前に、AIが終わらせてくれた。
次は「投稿」を仕組みにする
台帳ができると、次の問題が見えてきた。
記事を公開するたびに、台帳を手で更新しなければならない。
最初はClaudeに「この記事が公開されたからDBに追加して」と毎回言っていた。
これも手動だった。
「毎回同じ作業が発生している。仕組みにできないか」と考えた。
そこで作ったのがpost_draft.pyだ。
要するに、MarkdownファイルをWordPressに下書き保存するスクリプトだ。
台帳の更新は、公開後に別の仕組みで動く。
手動の作業が、一つずつ減った。
設計が静かになるのは、全体が見えたときだ。
台帳がその入り口だった。
投稿を仕組みにした話は、次の記事に書く。
台帳の次は、仕組みだ。
コメント