ネタ出しのたびにClaudeに「何か書くことない？」と聞いていた。
でも答えはいつも浅かった。
材料を渡していないのだから、当然だ。
ある日、書いた記事のタイトルを全部テキストファイルにまとめてClaudeに渡してみた。
変わった。
「何が多くて、何が足りないか」が見えるようになった。
でも毎回全部渡していることに、すぐ気づいた。
無駄だ、と思った。
そのとき、articles.dbが生まれた。
これが、俺にとってのAIリサーチャーの始まりだった。
この記事は、Claude時代に `記事リスト.txt` を渡して、ネタ出しが変わったときの記録である。今なら同じ考え方を、Codexでも使っている。大事なのはツール名ではなく、AIに「これまで何を書いたか」を渡してから、次の記事を考えさせることだ。
現在は、単発の `記事リスト.txt` だけではなく、記事台帳や目次を見ながら、足りない記事を確認している。記事をDBで管理する話は、後の記事「articles.dbで記事を管理する。ブログを感覚ではなく台帳で見る」で詳しく書いた。
ブログのネタ出しが面倒になってきた
ブログを始めたころ、ネタに困ることはなかった。
書きたいことが積み上がっていた。
でも記事が増えてくると、「次に何を書けばいいか」がだんだんわからなくなってきた。
Claudeに聞いていた。
「次、何かネタない？」
答えは返ってくる。
でもなんとなく浅い。
「新NISAは今すぐ始めるべき」
「40代からでも投資は遅くない」
「節約するなら固定費を見直そう」
どこかで見たような切り口ばかりだった。
何回か繰り返して、気づいた。
Claudeが悪いわけじゃない。
俺が材料を渡していなかった。
「この人が何を書いてきたか」を知らないAIに、「次に何を書けばいいか」を聞いていた。
初対面の人に「俺の次の話題、何がいい？」と聞いているようなものだ。
何を書いてきたのか。
どのテーマが多いのか。
どこがまだ空いているのか。
そういう情報を一切持たせずに「ネタを出せ」と言っていた。
材料なしでは、AIも考えられない。
記事リスト.txtをClaudeに渡してみた
ある日、思いついて記事のタイトルを全部テキストファイルに書き出した。
タイトルと投稿日だけ。
`記事リスト.txt` という名前にした。
それをそのままClaudeに渡した。
「これが今まで書いた記事の一覧です。次に何を書いたらいいですか」
変わった。
「投資の記事は多い。
でも、なぜ相場を見ない設計にしたのかをまとめる入口がない」
「カードや口座の記事はある。
でも、それらを”管理しないお金の設計”として束ねる記事が必要」
「家電の記事はある。
でも、判断を減らす暮らしとして並べると流れが見える」
そういう視点が出てきた。
ネタが変わったんじゃない。
材料を渡したことで、Claudeが全体を見て考えられるようになった。
AIに渡す前提情報のことを、専門的にはコンテキストという。
記事リストは、
俺の書いてきた軌跡をClaudeに渡すための材料だった。
ただのテキストファイルが、AIの目になった。
リストを渡す前と後で、ネタの質が変わった。
材料があれば、AIは動く。
記事が増えるたびに全部上書きしていた
記事を書くたびに、`記事リスト.txt` を開いた。
新しいタイトルを追加して、上書き保存した。
次にClaudeに渡すとき、また全部貼り付けた。
最初の10本、20本のころはそれで問題なかった。
でも記事が増えるにつれて、ファイルは長くなっていった。
3本、5本、10本と増えるたびに、貼り付けるテキストも長くなっていった。
ある日、渡しながら気づいた。
「このうち、Claudeが知らないのは今日書いた1本だけじゃないか」
古い記事は前回も渡した。
その前も渡した。
同じ情報を何度も何度も送り続けていた。
コンテキストには上限がある。
記事が100本になったとき、毎回100本分を全部渡すのは、明らかに無駄だ。
毎回全部渡すのは、非効率だ。
新しい記事だけ追加すればいい、と気づいた
気づいたのはシンプルなことだった。
「今日書いた記事は、まだClaudeが知らない」
「でもそれ以外は、前回までに渡した」
だから今回追加するのは、新しい1本だけでいい。
全部渡さなくていい。
差分だけ渡せばいい。
でも俺にとっては、
新しい記事だけを足せばいい、というだけの話だった。
上書きじゃなく、追加する。
それだけのことだ。
「全部コピーして貼り付ける」という手間がなくなった。
俺がやることは、新しい記事をDBに追加するだけになった。
小さな気づきだった。
大発明じゃない。
ただ「全部じゃなくていい」と思っただけだ。
でもその一歩が、仕組みを変えた。
渡すのは「新しいもの」だけでいい。
articles.dbになって、AIリサーチャーが生まれた
`記事リスト.txt` は、やがて `articles.db` になった。
名前はちょっとかっこいいが、やっていることは同じだ。
記事のタイトルと日付を、データベースに保存しているだけだ。
違うのは、新しい記事を書いたとき自動でDBに追加される設計にしたことだ。
手動でコピペする必要がなくなった。
そのDBを読んで、「次に何を書くか」を考える役割が生まれた。
それがリサーチャーだ。
最初から「リサーチャーを設計しよう」と考えていたわけじゃない。
面倒くさいを一つひとつ減らしていったら、気づいたらそこにいた。
役割を先に決めたのではなく、仕組みが育つ中で役割が生まれた。
そういう順番だった。
テキストファイルを作ったのは、ただ渡しやすくしたかっただけ。
DBにしたのは、毎回コピペするのが嫌だっただけ。
でも結果として、記事リストを読んでネタを出す専門のAI社員が生まれた。
設計は、重ねるほど静かになる。
AI編集部がどんなふうに動いているかは、こちらに書いた。
→ AIでブログを書く前に、ブログ設計図を作ろう。初心者のためのAI編集部入門
このブログがHTMLファイルから会社になった経緯は、こちらに書いた。
→ 最初はHTMLファイルだった。AIブログ運営が会社になるまでの話
設計が育つと、そこに役割が生まれる。
コメント