このブログのネタは、AIと一緒に洗い出しています。ただし「思いついたそばから記事にして即公開」という流れにはしていません。ネタ出しと執筆と保管を、あえて別の工程として分けています。
まず「ネタの棚卸し」だけをする工程
最初の工程では、記事を書くことを目的にせず、リポジトリの実装・設計判断・経歴情報を洗い出して、記事になりうる要素をリストアップするだけに専念します。この段階で執筆まで一気にやってしまうと、量よりも「今思いついた1本」に意識が向いてしまい、後から見返すと似たテーマばかりになりがちです。棚卸しを独立した工程にすることで、実装の細部（星空生成のロジックなど）から経歴の抽象化（海外拠点での制約下判断など）まで、粒度も分野もばらけたリストを作れます。
執筆はリストが確定してから
ネタのリストができた後、初めて執筆に入ります。この順序を守ることで、「このネタは前に出した別のネタと内容が被っていないか」を書く前にチェックできます。実際、CSSカスタムプロパティのムード設計というアイデアは、書く直前に既存記事と内容が近いことに気づき、光の質感(box-shadow/drop-shadow)という別の切り口に絞り直しました。先にリストを固定してから書き始めることで、こうした重複の調整が執筆の途中で発生せずに済みます。
GitHub issueを「非同期の下書きキュー」として使う
書き上げた記事は、すぐに src/content/blog/ へコミットするのではなく、まずGitHub issueに全文を保管しています。issueにしておくことで、公開前に見直す・編集する・優先順位を入れ替える、といった判断を後回しにできます。コードの変更と違い、記事の採否は好みや文脈に左右される部分が大きいので、「一旦全部書き出しておいて、選ぶのは後」という順序の方が、書く側も選ぶ側も身構えずに済むと感じています。
分業のコストより、量と多様性のメリットが上回る
工程を分けることで、当然ながら一気通貫でやるより手数は増えます。それでも、ネタ出しに集中する工程を独立させたことで、最終的に出てきたアイデアの数と幅は、最初から執筆を意識しながら考えていたら出てこなかった量になりました。何かを「大量に、多様に」出したいときは、生成する工程と絞り込む工程を分けること自体が、量と質のどちらも底上げする、というのが今回の実感です。