この記事の実施記録（2026年9月時点）: AI（Claude Code）に記事を書かせる仕組みを2026年4月に整備し、約5ヶ月間運用した。差し戻し理由を蓄積するルールファイル（writing-guidelines.md）は、整備直後の5セクション構成（構想メモの記録）から、2026年9月5日実測で23セクション（更新履歴セクションを除く）・257行まで育っていた。増えた18セクションの大半は、公開後の品質チェックで実際に指摘された問題を抽象化したものだ（出典: 同ファイル末尾の更新履歴、2026-05-05〜08-08の12件）。この記事では、その仕組みを「書く前に何を設計しておくか」という4段階に分けて説明する。
AIに記事を書かせたことがある人なら、こんな経験がないだろうか。ある記事はほとんど直さずに公開できたのに、別の記事は同じように依頼したはずなのに何度も差し戻しになる。プロンプトの書き方を変えても、モデルを変えても、ムラは消えない。
私も同じことで悩んでいた。そして5ヶ月運用してわかったのは、ムラの原因は「書いている最中」ではなく「書く前」にあったということだ。書き始める前に何を渡しておくかで、差し戻しの量がほぼ決まる。
これは記事執筆に限った話ではない。コードを書かせる、レビューさせる、要約させる——AIに何かを任せる作業全般で同じムラが起きる。この記事では説明の都合上「記事執筆」を例に進めるが、特にStage 3・4はコード生成やコードレビューを任せているエージェントの運用にもそのまま当てはまる。
「それ、結局はレビューAIを作った話の焼き直しでは？」と思われたかもしれない。以前書いた「AIにAIの書いた文章を批評させたら60点だった話」は、読者ペルソナAIを作って書いた後にレビューさせる話だった。今回はその前工程、つまり書く前に何を設計しておけば差し戻し自体が減るか、という話だ。
全体像：書く前に設計する4段階
私が整備した仕組みは、大きく4段階に分かれる。
| 段階 | 何をするか | タイミング |
|---|---|---|
| Stage 1 | 読者ペルソナを設計する | 企画時 |
| Stage 2 | ペルソナの「疑い」を書き手に渡す | 企画→執筆の引き継ぎ時 |
| Stage 3 | 過去の差し戻し理由をルールとして蓄積する | 恒常的（毎回の品質チェック後） |
| Stage 4 | 創作してはいけないことを明文化する | 恒常的 |
Stage 1・2は「今回の記事のために何を用意するか」、Stage 3・4は「二度と同じ差し戻しを起こさないために何を積み上げるか」の話だ。順に説明する。
Stage 1: ペルソナ設計——架空ペルソナは都合よくなる
「ペルソナを作ってAIにレビューさせればいい」というのはよく聞く話だ。ただ、ペルソナの作り方には落とし穴がある。
架空のペルソナ（例えば「中小IT企業の取締役」のような設定）を自分で設計すると、無意識のうちに「この記事に好意的に反応してくれる人」を作ってしまいやすい。結果としてレビューが甘くなる。本当にリアルな読者なら、そもそもこの記事にたどり着かなかったり、「AIの話か」で数秒で離脱したり、「面白いね」で終わって何も行動しなかったりする可能性のほうが高い。
これを実感したのが、私の友人（マーケティングコンサルタントの経営者）にペルソナ役を頼んだときだった。架空のペルソナでは出てこなかった指摘が飛んできた。
「ミンツバーグの使い方が違う」
即座にそう指摘された。さらに「研修で使えるか？」という、架空のペルソナ設計では想定していなかった評価軸も持っていた。「友人だから最後まで読む。ただし忖度はしない」という自然な動機があったからこそ、鋭いレビューになったのだと思う。
この経験から、ペルソナ設計には年齢・職業・スキル・動機だけでなく、次の項目を加えるようにしている。
- この記事を読まない理由（読む理由より、実は重要）
- どこで知るか（導線）——内容以前に、そもそも届くかどうか
- 趣味・生活スタイル——いつ・どこで読むかのシチュエーション
- 最大の疑い——記事に対して最初に浮かぶネガティブな反応
「仕事終わりにバーで一人飲みながらPCを開く習慣がある」のような具体的なディテールが1つ入るだけで、ペルソナのリアリティが変わる。
架空ペルソナと実在人物ベースのペルソナは、使い分けるのがよいと考えている。架空ペルソナは「広いターゲット層の代表例」として都合よくなるバイアスを意識しながら使い、実在人物ベースは専門領域の正確性検証や、忖度なしの鋭い指摘を得たいときに使う。ペルソナ定義の具体的なテンプレートや呼び出しフローは、前の記事にまとめてあるので、ここでは繰り返さない。
この考え方は記事執筆に限らないはずだ。コードレビューを任せているエージェントなら、「忖度なく指摘するシニアエンジニア」のようなペルソナを定義し、命名規則・エラーハンドリング・テストカバレッジのどこを疑うかを実装前に渡しておく形になる。ペルソナが検証する対象が文章かコードかの違いだけで、「都合のいいペルソナを自分で作ってしまう」という落とし穴も同じように起きるだろう。もっとも、私自身はまだコード側で試していない。
Stage 2: 疑いの先渡し——今は「追加ステップ」ではなく標準工程になった
Stage 1で作ったペルソナには、必ず「疑い」をセットで定義している。「SE歴が長い人だからできたのでは？」のような、読者が記事を読みながら心の中で持つ疑念のことだ。
「ペルソナを作ればレビューはできる」と思われがちだが、私の仕組みでは、疑いリストを書き手が執筆前に受け取っておくところに重心を置いている。書いた後に指摘されて直すのと、最初から疑いに答える構成で書くのとでは、直す量が目に見えて違った。
この工程は、整備した当初は企画フローに追加した特別なステップだった。今は独立したステップとしてではなく、企画段階の標準工程（企画フローの「疑いリストの抽出と書き手への引き渡し」）に組み込まれている。さらに、構成レビューの段階（章立てを読む時点でのチェック）でもペルソナと疑いをセットで評価し、感情レビュー（読者がどう感じ、どこで離脱するかを検証する工程）の通常レビュー観点にも「疑いへの回答」がチェック項目として入っている。「追加でやること」ではなく、企画→構成レビュー→執筆→感情レビューという通常の流れの各所に疑いが埋め込まれている状態になった。
効果として感じているのは、「なぜそう言えるの？」という読者の疑問に、本文が先に答えている状態を作れることだ。Q&A的にまとめて末尾に置くよりも、疑いが生まれそうな章の冒頭で1文答えておくほうが、読者の離脱を防ぎやすい（この記事でも、いくつかの章の冒頭でその方式を使っている）。
コード側なら、レビュアー役のエージェントには過去のレビューで繰り返し出た指摘パターンを、テスト担当のエージェントには「このコードのどこを疑うべきか」を、それぞれ実装前に渡しておく形になるだろう。Stage 1と同じく、記事執筆側からの類推の域を出ていない。
Stage 3: 差し戻し理由の蓄積——5セクションが23セクションに育った
ここがこの記事で一番伝えたいことだ。
Stage 1・2は「今回の記事」のための準備だが、Stage 3は「二度と同じ差し戻しを起こさないため」の仕組みだ。過去のレビューで繰り返し発生した指摘を、1つのルールファイル（writing-guidelines.md）に蓄積している。
整備した2026年4月時点の記録では、このファイルは「数字の根拠」「バランス」「構成」「再現性」「創作禁止」の5セクション構成だった。2026年9月5日に実測したところ、23セクション・257行に増えていた。
「ルールを増やしただけで、実際に運用してるって言えるの？」という疑いはもっともだ。それに答える材料は、このファイル末尾の更新履歴にある。2026-05-05〜08-08の間に12件記録されており、どのセクションが・いつ・どの記事の品質チェックの何件の指摘から生まれたかが分かる。一部を紹介する。
| 日付 | 追加内容 | 出典 |
|---|---|---|
| 2026-05-14 | 「速報系・未確認情報の留保レベル」「問題提起型記事の締め」を新設 | ある記事の品質チェックで指摘2件（すべて必須修正）を抽出 |
| 2026-06-20 | 「Zenn Book CTA（次の問い予告型）」を新設 | 品質チェックの指摘ではなく、アクセス解析（GA）データを見た改善セッション由来 |
| 2026-07-15 | 「ハブ記事の総数表現とリンク実数の突合」「引用元の自己言及表現の書き換え」を追加 | 別記事の品質チェックで指摘2件（必須修正1件・推奨修正1件）を抽出 |
| 2026-08-08 | 「非公式な手法・内部APIの扱い」「修正時の伝播確認」を新設 | 2記事の品質チェックで指摘17件（うち必須修正5件）を抽出 |
18セクションの増加のうち、出自を更新履歴から確認できるのは15。内訳は、公開後の品質チェックで指摘された問題から生まれたものが14、上の表の2026-06-20のようにアクセス解析を見た改善から生まれたものが1だ。
実際にどんな中身なのか、代表的な2セクションを引用する。1つは「非公式な手法・内部APIの扱い」だ。
公開ドキュメントのないAPI・非公式な手法・規約上の位置づけが曖昧な操作を紹介する場合、以下3点に必ず触れる。
- 規約上の可否は読者各自で確認すべきこと（「自分のデータだから問題ない」という誤解を先回りして否定する）
- 予告なく仕様変更・停止されうること
- 対象は自分自身のアカウント・データに限ること
このルールが生まれたきっかけは手厳しい。ある記事の初回品質チェックで、内部エンドポイントのURL・メソッド・パラメータ名まで説明していながら、本文に「規約」「ToS」「禁止」という言葉が1件も出てこないという理由で、法的リスクの評価軸が10点満点中0点、公開不可の判定になった。この一件から抽出されたルールが、今は別の記事を書くときの事前チェック項目になっている。
もう1つは「修正時の伝播確認」だ。
固有名詞・用語・年号・数値を修正したら、同一ファイル内の関連表現を grep して伝播漏れを確認する。
1箇所直して満足すると、離れた位置の言及が古いまま残り、記事内で自己矛盾する。
これも実例つきだ。ある記事で経歴年の誤りを1回目の指摘で修正したところ、直後の別の言及と食い違ったまま2回目の指摘を受けた。同じ箇所から2回連続で指摘が出たことが、このルールが生まれた理由になっている。
このルールがどう積み上がるかの仕組みにも触れておく。品質チェックの指摘全部がルール化されるわけではない。「同種の記事で再発しうるか」と「ルール化・チェックリスト化できるか」の両方を満たした指摘だけを抽出する運用にしている。個別の誤字修正のような話は記事側で直して終わりにし、抽象化できる教訓だけをルールファイルに積む。ここは「気づいたら追記する」ではなく、承認を経て積み上げる形にしている。
では、このルールで差し戻しは実際に減ったのか。その問いは最後の「なぜ効果測定（差し戻し率の推移）にまだ手をつけていないのか」で扱う。
Stage 4: 創作禁止の明文化——6項目はどこへ集約されたか
整備した当初、創作禁止のルールは書き手（writer）の役割定義ファイルに直接書いていた。事実に基づかないエピソードの創作禁止、過去記事・ログに裏付けのない主張の禁止など、6項目を明記していた。
2026年9月5日時点でその役割定義ファイル（76行、実測）を確認すると、6項目はそのままの形では残っていない。代わりにあるのは次の1行だ。
writing-guidelines.mdを遵守すること（数字の根拠・バランス・構成・再現性・創作禁止）
創作禁止の実体は、Stage 3のルールファイル側の「創作の禁止」セクションに移っている。中身も当初の6項目とは少し違う。今のセクションは4項目で、うち1つは「執筆担当が参照する調査素材にない情報を独自に補完しない」という項目に置き換わっている。これは、素材にない情報を書き手が創作してしまった実際の事故を踏まえて追加された項目だ。
なぜ役割定義ファイルへの直接記載から、ルールファイルへの一本化に変わったのか。恥ずかしながら、この判断をした瞬間の記録を自分で探した記憶がない。コミット履歴やIssueを遡れば残っている可能性はあるが、今回はそこまで確認できていない。ただ、同じルールが複数のファイルに分散していると、一方だけ更新して他方が古いまま残る、という状態になりやすいことは経験上想像がつく。実際、この記事のStage 3で紹介した「修正時の伝播確認」ルール自体が、まさに「1箇所直して満足すると別の箇所が古いまま残る」問題を扱っている。ルールを1箇所に集約する判断も、同じ問題意識の延長線上にあったのではないかと思う。
4段階を整えても、まだ終わっていないこと
ここまで4段階を紹介してきたが、「これで差し戻しがゼロになった」という話ではない。
- Stage 1・2は、記事ごとに新しく設計し直す手間が残っている
- Stage 3のルールは23セクションまで増えており、今後も増え続ける前提の仕組みだ。増えすぎたときにどう整理するかは、これからの課題になっている
なぜ効果測定（差し戻し率の推移）にまだ手をつけていないのか
正直に書いておく。Stage 3のルールを積み上げてから、差し戻しの回数が実際に減ったかどうかを定量的に追跡した記録は、今のところない。証明できているのは「同じ壊れ方を二度と見逃さないための記録が23個ある」というところまでだ。
理由は単純で、ルールを1つ追加するたびに「この追加の前後で同じ性質の指摘が再発していないか」を記事単位で追跡する仕組みを、作っていないからだ。
それでも、書く前の設計に手をかけるようになってから、「同じ理由で二度差し戻される」ということは減った実感がある。感覚の話にとどめず、次はこの実感を数字で裏付けたい。
「AIに書かせる」という営みは、書いている最中のプロンプトの工夫よりも、書く前にどれだけ土台を整えられるかで決まる——5ヶ月回してみて、私はそう考えるようになった。ペルソナと疑いを渡すStage 1・2、過去の失敗を蓄積するStage 3・4。この4つを揃えて、ようやく「差し戻しが起きにくい状態」に近づいてきた、というのが今の手応えだ。
4段階を整えていくと、次に浮かぶ問いがある——1本の記事の品質を設計する仕組みが回るようになったら、それを複数のエージェントが分担する「組織」としてどう運用すればいいのか、という問いだ。
書く前の設計、書いた後のレビュー、そして両方を回す役割分担をどう組んだかは、Zenn Booksシリーズ Vol.3「コードを書けない私がClaude Codeで『AIチーム』と書き続けるまで」（序章無料）に書いている。
執筆・レビューの役割分担そのものは「AIにAIの書いた文章を批評させたら60点だった話」（書いた後のレビュー体制の話）に、仕組み全体がどう品質に効いたかの分析は「Claude Code × Opus 4.7でZennブックを書いたら品質が上がった——でも半分は仕組みの話だった」に書いているので、あわせてどうぞ。
Claude Codeでのマルチエージェント運用そのものをもう少し体系的に学びたい方には、こちらの書籍も参考になる。
実践Claude Code入門――現場で活用するためのAIコーディングの思考法（西見 公宏・吉田 真吾・大嶋 勇樹）
この記事は はてなブログ からのクロスポストです。