Claude Codeでブログを書き始めた頃、俺には発注書という考え方がなかった。
記事を書いてと言ったら、記事はできた。
でも何かがおかしかった。
Claude Codeを使い始めた頃、俺はとにかくAIに「書いて」と言っていた。
毎回その場で指示を組み立てて、AIが生成して、俺が手直しする。
記事は確かに出てきた。
でも積み上がった記事は、バラバラだった。
シリーズのはずなのに、シリーズになっていなかった。
前の記事を引用したくても、どこに何を書いたか俺自身も覚えていなかった。
AIはもっと知らなかった。
原因は「書く前に何も決めていない」ことだった。
AIにいきなり「書いて」と言っていた頃の話
夜、帰ってきてパソコンを開いた。
「次の記事を書いて。AIで記事を作る方法の話。読者は学生で、ブログ初心者向けで、2000字くらいで、トーンは落ち着いた感じで」
そのまま打ち込んだ。
これが当時の俺の発注文だ。
要するに、その場でプロンプトを作っていた。
毎回、思いついた設定を口頭で説明する。
毎回、AIが生成して、俺が手直しする。
記事は確かにできた。
品質もそれなりだった。
でも気になることが二つあった。
一つは、説明のたびにかかる時間だ。
「トーンは落ち着いた感じで」「体言止めを使って」「読者への助言は入れないで」——毎回同じことを言っていた。
AIはセッションをまたぐと忘れる。
俺の指示もリセットされる。
もう一つは、記事のブレだ。
俺が毎回少し違う言い方をするから、毎回少し違う記事が出てきた。
AIが悪いわけじゃない。
毎回違う指示を出していたのは俺の方だ。
記事はできるのに、シリーズになっていなかった
10本くらい書いたとき、気づいた。
記事が互いに知らない他人みたいだった。
以前の記事「ブログ運営に役職を作った。編集長・ライター・リサーチャーで記事を書く」でClaude Codeのフォルダ構成を書いた。
でも、その次の記事「役職ごとの仕事が重くなったので、メソッドで分けた」を書くとき、AIはそれを知らない。
「前の記事でこの話は書いた」という情報がない。
内部リンクを張ろうとしても、「あの記事のどのあたりに、何のキーワードで何を書いたか」をAIが把握していない。
把握していないまま書くから、前の記事と似たような説明が重複して入ってくる。
俺自身も、正直どこまで書いたかよく覚えていなかった。
シリーズ記事の問題は、記事の品質じゃなかった。
書く前の設計がなかったことだ。
「どの記事で何を書くか」を先に決めないと、どの記事も単体完結になる。
単体で完結した記事は、シリーズにならない。
AIブログを書く前に作るもの。「発注書」という名の設計書
今は記事を書く前に「発注書」を作る。
発注書という言葉は俺が使っているだけで、正式な名前はない。
要するに「この記事を書く前に決めること全部」をまとめたファイルだ。
中身はこんな感じだ。
- タイトル（仮）とslug
- シリーズの番号（前の記事・次の記事）
- 対策キーワードとLSI
- H2の構成（見出しと、各H2の役割）
- 差別化の切り口
- ずみの実体験メモ（AIに捏造させないための確認欄）
- やらないこと（スコープ外）
これを毎回同じ順番で埋めるようにした。
この発注書を先に作ると、「前の記事で何を書いて、次の記事で何を書くか」が見える。
発注書を並べると、シリーズ全体の設計になる。
発注書は記事の設計書だ。
編集長は本文を書かない。構成と順番だけを決める
前の記事で書いた話の続きだ。
俺のブログ運営には「編集長（henshucho）」という役割がある。
henshucho、要するに「どの記事を書くか」「どんな構成にするか」「どこに内部リンクを張るか」を判断する担当だ。
編集長がやることは一つ。
発注書を作ることだ。
本文は書かない。
書くのはライター（writer）の仕事だ。
この分け方にした理由がある。
「何を書くか」を考えながら「どう書くか」も考えていると、どちらもブレた。
企画と執筆を混ぜると、どこかで「書きやすい方向」に引っ張られる。
「読者に伝えるべきこと」より「書きやすいこと」が先に来る。
発注書を作るフェーズと、本文を書くフェーズを分けた。
決める人と書く人を、役割として切り分けた。
AIへの説明が不要になった。設計書を渡すだけになった
今の俺の発注は、こうだ。
「発注書（2026-07-01_order_s1-5.md）を読んで。一気に書いて。」
それだけだ。
毎回「読者は学生で」「トーンは静かに」「体言止めを使って」「説教臭をなくして」と説明していた頃とは違う。
発注書にすべてが書いてある。
AIはそれを読んで、俺の説明なしに書き始める。
説明の時間がゼロになった。
副産物もある。
俺自身が書く前に内容を整理するから、書き終わったあとで「これを入れ忘れた」が減った。
発注書を作る段階で、記事の構造は8割完成している。
書く前に設計する。
それだけで、AIへの指示がほぼなくなった。
この時点では、俺はそれを発注書と呼んでいた。今の運用では、発注書だけを別に作るより、記事の狙い、構成、レビュー、進行状況を article_state というカルテ1枚に残している。その移行は、後の記事「発注書をやめて、カルテ1枚にした。AI編集部の引き継ぎで迷わなくなった」で書いた。
この次に必要になったのが「台帳」だった
発注書の仕組みができると、次の問題が出てきた。
記事が増えてくる。
「今どんな記事がある？」「S1シリーズはどこまで書いた？」「内部リンクはどこに張ったか？」
発注書はあくまで1記事ぶんの設計書だ。
複数の記事を横断して管理する仕組みじゃない。
記事が5本のうちは頭で把握できた。
10本を超えてくると、もう無理だった。
俺が次に作ったのは、記事の台帳だった。
articles.db。
要するに記事の情報をデータベースとして管理するファイルだ。
公開日・タイトル・slug・内部リンクの状態を一元管理できる。
発注書が1記事ぶんの設計書なら、台帳はシリーズ全体の地図だ。
その話は、次の記事「articles.dbで記事を管理する。ブログを感覚ではなく台帳で見る」に書く。
コメント