ネタを渡すだけで、生成AIは「書きたかった記事」を書けるか
ども！龍ちゃんです。
生成AIに「このネタで書いて」って投げると、それらしい記事はすぐ出てきます。でも読むと、自分が書きたかったのとは違う。というか自分が絶対言わなそうな論理の展開とかするって経験ありませんか？
誰に向けるのか、どの角度で切るのか、制約なしで書かせると、当たり障りのない記事になります。読み物としては面白いですが、これだと公開はできないですよね。
この現象はAIが噛んでいなくても起きてました。勢いで頭から書くときも一緒で、途中で「あれも、これも」と足したくなって、後付けで詰め込んで、読み返すと「結局、何が言いたいんだっけ」。ネタはあったのに、出来上がっていると別の話しているみたいなこともありました。
そんな背景から、最近はアウトラインを設計してから書きます。「何を・どの順で話すか」を先に決めておけば、後から湧いた要素も置き場所が決まって、流れが崩れません。今日の話は、この「アウトラインを設計してから書く」が前提になります。そうするとAIの暴走も少しは抑制できて、快適な爆速執筆ライフが送れるという形です。
今回は、アウトラインをAIとレビューしながら進めて手戻りを減らす話です。レビューって「書いた後」にやるものだと思ってません？ アウトラインの段階、つまり書く前に、方向をエージェントに検算させる方法の解説です。
アウトラインが「流れ」を守り、エージェントが「方向」を守る。実物で見せていきますね。
そもそも、アウトラインに何を書くのか
「アウトラインを設計する」って言っても、じゃあ何を書くのか。実例が早いので、いま読んでもらってるこの記事のアウトラインから、決めてる項目を抜き出してみます。
## メタデータ
- 狙う検索クエリ: 「技術ブログ アウトライン AI」「ブログ 書く前 レビュー」
- 読者像: 書き上げてから「方向がズレてた」と気づいて書き直す、手戻りに消耗しているエンジニア
- 記事の核（主張）: レビューは書いた後じゃない。書く前にアウトラインをエージェントにかけると手戻りが消える
## 構成案
1. いきなり書いて流れが崩壊した話（フック）
2. アウトラインに何を書くか／書く前に検算するのは2つ
3. ① 競合調査で「角度」／② 読者代弁で「読者」
4. 書く前に回すとどうなるか（Before / After）
5. まとめ
これは、いま読んでもらってる記事そのもののアウトラインです。決めてることを言葉にすると、だいたいこの4つですね。
- 誰に届けるか（読者像）
- どの角度で書くか（記事の核）
- どんな検索で来てほしいか（狙うクエリ）
- 何を、どの順で話すか（構成）
このうち「構成」は、さっき話した「流れ」そのものなんですよね。ただ1つ注意しておきたいのが、さっき載せたこの記事の構成案、あそこに書いてあるのは章タイトルじゃなくて「話がどう転がるか」っていう展開の方です。文言そのままが見出しになるわけじゃなくて、例えば1番の「いきなり書いて流れが崩壊した話（フック）」は、実際の見出しだと「ネタを渡すだけで、生成AIは『書きたかった記事』を書けるか」に変わってます。見出しは、この後で記事本文を書くタイミングで話の切れ目に立てるものなんで、構成案の段階では展開だけ決めておけば十分なんですよね。
あともう1つ、構成案とセットで「何を話さないか」（範囲）も決めてます。ただこれも「流れ」を守る側の話なんで、今日は深追いしません（付録のルールには入れてるので、気になる方はそっちで）。
じゃあこの4つ、実際どうやって作ってるかって話なんですが、手でゼロから書いてるわけじゃないんですよね。書きたい内容のメモとか、検証してわかったこと、動かしたログ、声メモを文字起こししたやつとか、手元にある材料をまずAIに渡して、そこにアウトラインのテンプレート（メタデータ3項目＋構成案の型）を当てて成形してもらいます。テンプレートを1個持っておくと、材料を放り込むだけでそれなりの形になるんですよね。
ただ、出てきたものをそのまま使うわけじゃないです。特に読者像と記事の核は、必ず自分の言葉に書き換えます。AIが出す読者像って当たり障りのない一般論に寄りがちで、それだと後で話す2体の検算が効かなくなるんですよね。「狙うクエリ」は、書きたいネタと前提知識でほぼ自然に決まるんで、ここはAIの出力をそのまま使うことが多いです。
そうやって引き算していくと、書く前に「検算」したい方向の本体は、誰に（読者像） と どの角度で（記事の核） の2つに絞れるんですよね。
「誰に・どの角度で」を2体のエージェントに検算させる
- どの角度で書くか（誰も書いてない角度があるか）＝競合調査エージェントに、判断材料を出し切ってもらう
- 誰に届くか（読者が置いていかれないか）＝読者代弁エージェントに問いを投げさせて、判定は自分でやる
ここで1つだけ強調しておきたいんですが、これは「品質チェックの分割」ではないです。「企画判断の分割」です。世の中のレビュー分割って、読みやすさのチェックとかAI臭さ検出とか、だいたい執筆後の品質軸で観点を割ってるんですが、今回話す2体は違います。「誰に・どの角度で書くか」を決める、企画そのものの要素で割ってるんですよね。
あと前提として、この2体はどっちも Claude Code のサブエージェント（
.claude/agents/に定義ファイルを置いてます）で、書く前に呼び出してます。とはいえ肝は実装じゃなくて「アウトラインを2つの角度で検算する」って考え方の方で、ここは ChatGPT でも Gemini でも、なんなら手動プロンプトでも流用できます。エージェントの設計論そのものは別記事に譲るとして、ここでは「書く前にどう使うか」だけ見せますね（2体の定義ファイルは、公開用に整形したうえで記事末尾に付録として置いてます）。以下、実際の使い方です。
競合調査エージェントに「誰も書いてない角度」を探させる
1体目は competitor-reviewer。検索上位の競合記事を集めて、タイトルの構造・パワーワードの使い方・技術的な深さを分析して、差別化戦略を提案してくれる担当です。まず「何を入れて何を得るのか」を1枚にするとこうです。
処理の流れはこんな感じです。入力はアウトラインで決めた「狙う検索クエリ（キーワード）」。そこから WebSearch で上位5〜10件を拾って、WebFetch で上位5件を詳細に読みにいって、最後に review/competitor-{日時}.md というファイルに出力してくれます。核になるのは「競合が扱っていないトピック＝差別化の余地」の表です。
使うタイミングも明快で、このエージェントの定義自体に「記事執筆の最初（競合を把握してから書く）」と書いています。まさに書く前に使う道具として作られてます。
実物を見てもらうのが一番早いので、貼りますね。この記事を書く前に、まさにこの競合調査を自分の記事にかけたんです。返ってきた「差別化の機会」表から、この章に関わる1行を、文言そのままで抜き出します。
| トピック | 差別化の狙い目 |
|---|---|
| 競合調査＝角度決めの道具（go/no-goではない） | 競合分析系の記事は軒並み「ホワイトスペース発見＝書く価値の有無」の文脈。「被っても出す、角度だけ変える」という逆張りの明言は競合ゼロ |
| 答えを出さず問いを投げるエージェント（reader-advocate） | 英語圏ペルソナ系記事も含め、AIに audience nuance・修正案まで生成させる設計が主流。「問いだけ投げて答えは人間が持つ」という記事は見当たらない |
これが実際の出力です（表記もそのまま）。上が競合調査そのものの角度、下が次章で話す読者代弁の角度です。この2行のほかにも「そもそもレビューを書く前に持ってくる発想自体が競合ゼロ」「企画判断のための分割も競合ゼロ」といった行が並んでて、それを見て「じゃあこの『書く前レビュー』と『問いを投げる設計』を軸にしよう」って角度を決めたのが、いま読んでもらってる記事そのものなんですよね。
競合調査は「書くか書かないか」を決める道具ではないです。僕が書こうとした記事が既にどこかで出てたことなんて何度もあるし、被ってても出します（うちのドメインに無ければ）。じゃあ何のために使うかというと「どの角度で書くか」を決めるため。返ってくる「誰も埋めてない角度」に寄せれば、被っても二番煎じにはならないし。世の競合記事は暗に「隙間が無いなら書くな」って含みを持ってる気がするんですけど、僕は逆で多少被っていても出します。ただ書き方や検証事項を追加したりはします。
ここが今回の記事の差別化ポイントらしいですねww。競合を調べると、ネタやアウトラインを補強する角度が見えることも多いです。
② 読者代弁エージェントに「読者の置き去り」を問わせる
2体目は reader-advocate-agent。読者の代弁者です。このエージェントの一番の特徴は、「答え」つまり修正案とか評価点を出さないことなんですよね。問いを投げるだけです。こちらも1枚で見てみます。
冒頭3秒チェック→読者像→前提知識→動機→価値、という順番で、「ここで離脱しそう」「ここで意味わからんくなりそう」を言葉にしてくれます。
調査から見えた傾向として世の中のAIレビューって、修正案や評価点をAIに出させる設計がほとんどなんですよね。でも問いだけ投げて、答えは人間が持つ、というスタイルはあまりないんですよね（僕調べ）。
僕がこの実装にしている理由はシンプルで、読者像のズレって、最終的には人間が判断すべきことだと思ってるからです。AIに「この読者にはこう書け」まで決めさせると、逆に読者像がAIの想像で固定されてしまう。だから答えは渡さず、問いだけ渡してもらってます。ざっとあらを探してもらってディスカッションするって感じですね。
というのは僕の体感なんですが、①の競合調査も同じ結論でした。さっきの「差別化の機会」表の下の行、あれがまさにこの設計についての行です（文言そのまま乗っけてます）。つまり「問いだけ投げる」は思いつきじゃなく、競合調査で「空いてる」と裏が取れた角度なんですよね。
なぜこれが書く前に効くかというと、「この用語、説明なしで出てないか」「読者はそもそもなぜこの記事を開くのか」を、アウトラインの段階で潰せるからなんですよね。書き上げてから読者像のズレに気づくと、直すのが本当に大変です。構成ごと組み直しになったりする。アウトラインの段階で潰しておけば、そこまで巻き戻ることはほぼなくなります。
副次的な効果として、前提知識の存在に気付けるということですね。前提となっている知識って自分がこれまで積み上げてきたものそのものだと思います。ただ、自分の前提知識って意外と自然に流しちゃうんですよね。相手も知っている体でブログを書いちゃう、みたいなことが起きがちで。まれに前提知識だけで一本のブログになったりするんでネタの発掘にもいいですよ。
実物を見てもらうのが早いです。この記事のアウトラインに、まさにこの reader-advocate-agent をかけたら、こんな問いが返ってきました（出力そのままです）。
- 「手戻りに消耗している」読者は、冒頭の何行目で「これは自分の話だ」と気づけますか？ 音声入力のエピソードは、読者が自分ごと化する前に必要な前置きですか、それとも省略しても成立する自分語りですか？
- 核心の逆転主張（レビューは書く前にやる）まで、何行分の前置きなら読者は待ってくれると思いますか？
見ての通り、ひたすら問をしてきます。「このエピソード要らない」みたいな評価もしない。ただ問うだけです。で、答えるのは僕。実はこの記事、最初の書き出しは音声入力でいきなり喋りながら書き始めた失敗談から入ってたんです。でもこの「音声入力のエピソードは自分ごと化の前に必要か？」って問いを見て、「確かに、読者が『自分の話だ』と気づく前に、僕の自分語りを聞かせてるな」と。それで冒頭を丸ごと組み直しました。いま読んでもらってる書き出しは、その結果なんですよね。もし答えまで渡されてたら、この気づきは自分のものにならなかった気がします。
実運用としては、1回起動して「冒頭3秒チェック＋問い1〜2個」まで出してもらうところで一旦止めてます。そこから先の対話は、メインの執筆セッションで自分が引き継ぐ形です。
書く前に回すと、どうなるか
改めて Before/After で見てみます。
Before：勢いでいきなり書く→書いてる途中で要素が後から湧く→後付けで詰め込む→話がとっちらかる。あるいは、流れ自体は綺麗に整っていても、方向がズレていて刺さらない。
After：outline で流れを整備して、書く前に2体（競合調査＝角度、読者代弁＝読者目線）を回して方向を確定させる。そうすると、執筆が「もう決めた流れと方向をなぞる作業」になるんですよね。だから手戻りが消える。
ただ、正直に限界も言っておきたくて。エージェントがやってるのは方向を「固める」ことなんです。「決める」のは、あくまで人間です。どの角度を採るか、被っても出すかどうか。ここの最終判断は、さすがに自分でやってます。エージェントに全部委ねてるわけじゃない。ここは削らずに残しておきたいポイントです。
まとめ：レビューを前に倒すと、書くのがラクになる
今回の話は、書く前、アウトラインの段階でエージェントにかけると、手戻りがぐっと減ります。決めるのはたった2つ。誰も書いてない角度か、そして読者が置いていかれないか。この2つだけです。
今回話したのは、執筆全体の中の1工程です。検証から執筆、仕上げ、公開まで含めた全体の流れは、別記事でまとめてます。気になる方はそちらも覗いてみてください。
ほなまた〜
付録：この記事で使っている定義
「作り方・設計論」は別記事に譲りますが、「実物の定義」はここに置いておきます（公開用に少しだけ整形してます）。雰囲気とスコープの参考にどうぞ。
1. アウトライン設計のルール（CLAUDE.md 抜粋）
アウトラインを作るときに効いてるルール。メタデータの雛形と、「レビューは通す前に通る状態を作る」という制作順序が本体です。
## アウトラインのメタデータ
アウトライン冒頭に、この3つを必ず書く。
- 狙う検索クエリ: この記事で狙う検索キーワード
- 読者像: どんな人が読むか。抱えているペインや状況を具体的に
- 記事の核: この記事で一番伝えたいこと。一文で
## 制作の順序（レビューは「通す」前に「通る状態」を作る）
順序自体が品質を担保するので崩さない。
1. 被り発見 → 角度発明: 既存資産と被ったら、畳む前に角度を変えられないか（標準/競合を敵役に据える逆張り等）。
2. 書く前に三重検証: ①主張の真偽（一次ソースで裏取り）②市場の空き（競合・SEOを本文を書く前に偵察）③一次ソース固め（バージョン・公式見解は公式 docs で確定、二次ブログに頼らない）。
3. outline に読者像・狙うクエリ・核・裏取りと、「展開（話がどう転がるか）」「範囲（話す／話さない）」を明記し、読者像を尖らせる。
4. 本文を書く前に著者の実体験を取りにいく。声メモ（生文字起こし）が効果大。体温（実体験）は推敲では足せないので素材の中心に据える。
5. ノイズ除去（AIっぽさ削り）を構造レビューより先に。ノイズが残ると読者/論理レビューが表面に気を取られ本質を見落とす。
6. 最後に構造レビュー（論理 / 読者目線）。
## outline の分割判断（1記事に詰め込まない）
- 小見出し（H3）で「方法を N 個並べる」構造になったら、各方法のメンタルモデルが同じか確認する。抽象度・読者に要求する思考が違えば別記事に切り出す。「ペインが同じ」はまとめる理由にならない。
- 分割した各 outline 冒頭に「棲み分けメモ」（対症療法 vs 体質改善 等の対の構図）を固定し、越境・重複を防ぐ。
2. 競合調査エージェント competitor-reviewer
---
name: competitor-reviewer
description: 競合記事のタイトルとコンテンツを分析します。検索上位記事の構造・パワーワード・技術的深さを評価し、差別化戦略を提案します。結果はファイル出力します。
tools: [Read, WebSearch, WebFetch, Write]
model: sonnet
---
# Competitor Reviewer Agent
あなたは競合記事の**タイトルとコンテンツ**を分析するエージェントです。
## 主な責務
1. 検索上位の競合記事を収集
2. タイトル構造・パワーワード・数値使用を分析
3. コンテンツの深さ・構成・技術的価値を評価
4. 差別化戦略の提案
## 使うべきタイミング
- 記事執筆の最初（競合を把握してから書く）
- 記事公開前（差別化ポイントの最終確認）
## 評価プロセス（4段階）
### Phase 1: 分析対象の把握
入力（ファイル or キーワード）から、記事タイトル・H2見出し・技術スタック・メインキーワードを抽出。
### Phase 2: 競合記事の収集
メインキーワードで検索クエリを設計し、WebSearch で各クエリ5〜10件収集 → WebFetch で上位5件を精読。
各記事から「タイトル/文字数・H2構造・扱う技術・コード例の質と量・図解・対象読者・独自性」を抽出する。
### Phase 3: 分析
- タイトル分析: 文字数・キーワード配置（前半/後半）・パワーワード・数値使用
- コンテンツ分析: 網羅性・技術的深さ・実用性・独自性・構成
### Phase 4: レポート作成とファイル出力
分析結果を {対象ディレクトリ}/review/competitor-{YYYY-MM-DDTHHMM}.md に出力する。
## 出力形式（要点）
- タイトル分析（競合タイトル一覧＋サマリー）
- コンテンツ分析（記事ごとの強み・弱み）
- 全体傾向（競合の共通パターン / **競合で扱われていないトピック＝差別化の機会**）
- 差別化戦略（タイトル戦略・コンテンツ戦略）
- 推奨される次のアクション
**重要**: 会話への直接出力ではなく、必ずファイルに書き出す。
## 評価原則
- データに基づく分析（収集したタイトル・コンテンツから客観的に）
- 具体的な推奨（すぐ活用可能な形式で）
- 差別化の視点（競合と異なるアプローチの機会を特定）
- 中立的な評価（強み・弱みを公平に）
3. 読者代弁エージェント reader-advocate-agent
---
name: reader-advocate-agent
description: 読者の代弁者として「ここで離脱する」「ここで意味わからん」を具体的に言語化し、書き手に問いを投げるエージェント。答え（修正案・評価）は出さず、問いだけを投げる。
tools: [Read]
model: sonnet
---
# Reader Advocate Agent - 読者の代弁者
あなたは**読者の代弁者**として、書き手と対話するエージェントです。
## 重要な制約
1. **答えを出さない**: 修正案や評価を出さない。問いを投げる
2. **めげない**: 「大丈夫です」「良いと思います」で終わらせない
3. **読者側に立つ**: 書き手ではなく、読者の「わからない」を代弁する
4. **対話を続ける**: 書き手が「あ、確かに」と気づくまで掘り下げる
## やらないこと
- 記事の評価をしない / 修正案を出さない / 褒めない / 1回の質問で終わらせない
## 想定読者: 刺激に慣れた読者層
冒頭で惹きつけないと離脱する / 長い前置きは読まない / 「何が嬉しいか」が最初にないと興味を持たない / 文章の壁を見た瞬間に閉じる。**この層の目線で「ここで離脱する」「ここで意味わからん」を具体的に言語化する。**
## 実行スコープ
1回の実行で「Step 0（冒頭3秒チェック）」と「次に投げる問い1〜2個」までを担当する。それ以降の対話はメインセッションが引き継ぐ。
## 対話の進め方
### Step 0: 冒頭の3秒チェック
読者として記事を見た瞬間の反応を言語化する。
- 躓き例: 「ここで閉じます。理由は〇〇」「この単語で『自分向けじゃない』と判断します」「文字多すぎ。スクロールする気力ない」
- 問い: 「最初の2-3行で『自分に関係ある』と思えますか？」「スクロールせずに見える範囲で価値が伝わりますか？」
### Step 1: 対象読者の確認
「誰に向けて書いてますか？」「その人は普段どんなツール使ってますか？」「この技術を触ったことありますか？」
### Step 2: 前提知識の確認
- 躓き例: 「『〇〇』って何？説明なしで出てきた」「この使い方、普通じゃないけど普通として話が進んでる」
- 問い: 「この用語、読者は知ってますか？」「この使い方、読者にとって『普通』ですか？」
### Step 3: 動機の確認
- 躓き例: 「タイトルで期待したことと違う話が始まった」「課題感に共感できない」「コピーがセンセーショナルすぎて一歩引く」
- 問い: 「読者はなぜこの記事を開くと思いますか？」「このコピー、読者の8割が頷けますか？」
### Step 4: 価値の確認
- 躓き例: 「読み終わって『で？』ってなる」「情報はあるけど行動に移せない」
- 問い: 「読者はこれを読んで何ができるようになりますか？」「『ふーん』で終わらないですか？」
## 対話スタイル
まず躓きを言語化し、その後1〜2個の問いを投げる。書き手の回答を受けてさらに掘り下げる。沈黙しない。
## 実行時の出力形式
```
## 読者視点チェック（初回）
### Step 0: 冒頭3秒チェック
[躓きポイントの具体的な言語化]
### 最初の問いかけ
[1〜2個の問い]
---
*続きの対話はメインセッションで。書き手が回答したら Step 1〜4 の順で掘り下げます。*
```
