AIにAIの書いた文章を批評させたら60点だった話

AIチームで本を書いた。reviewer（技術チェック担当）はA判定（公開可）を出した。でも読者ペルソナAIに批評させたら 60点 だった。

技術的に正確な文章が、読者に刺さるとは限らない。それを実感した話と、60点を78点に改善したプロセスを書く。

Claude Codeを使っている方、またはAI執筆の品質管理に関心がある方向けの内容だ。

「AIにレビューさせる」手法自体はすでにある。この記事が異なるのは3点だ。

1. ペルソナを「疑い」の粒度まで掘り下げること（年齢・職業だけでは批判的レビューがぬるくなる）
2. 通常モード→批判的モードの2段階で依頼すること
3. 点数の変化（60→78）を定量的に追跡すること

この3点のうち1つだけでも取り入れれば、AIレビューの精度が変わる。

reviewer単体の限界

Claude Codeのマルチエージェント構成で、非エンジニア向けのnote本（Claude Code活用の実践入門）を書いた。この本を書いた全工程——人間の発言15回でAIが2,000行を出力した2日間の記録——は「人間の発言15回、AIの出力約2,000行——Claude Code で本を書いた2日間の全工程」に詳しく書きました。

reviewer（= ファクトチェック担当のサブエージェント）はこんな点を見つけた。

• ファクト誤り（1章の画像生成セクション）
• 章間の整合性の矛盾
• 法的リスクになりそうな表現

品質ゲートとしては機能している。でも reviewer が見つけられなかったものがある。

• 「第2章のGit/GitHubで離脱しそうになった」
• 「SE歴26年の人だからできたのでは？ 本当の素人でもできるのか半信半疑」
• 「1週間で6本って、嘘くさい」（実績値。経緯は別記事に書いた）

これらは技術的な正確性とは別の問題だ。reviewer に「読者が買いたくなるか」は聞けない。

読者ペルソナAIを作った

.claude/agents/reader.md に読者ペルソナを定義した。

ターゲットが非エンジニア向け本だったので、こんなペルソナを設定した。

ペルソナ: 田中美咲（38歳）

属性: 中小企業の総務・経理。Excel・ChatGPTは使える。
      ターミナルは「黒い画面で文字がバーッと流れるやつ」と認識している

動機: AIに仕事を任せたい。でも「エンジニア向けでしょ？」と思って
      Claude Codeには手を出せていない

疑い: 「SE歴26年の人だからできたのでは？」
      「1週間で6本って盛ってない？」
      「本当に自分にもできるの？」

年齢・職業だけでなく「どんな疑いを持つか」まで定義するのがポイントだ。疑いの設定が浅いと、批判的レビューがぬるくなる。

なお、このペルソナ定義自体もClaude Codeに作ってもらった。ターゲット読者の属性（「非エンジニア、ChatGPTは使える、Claude Codeには手を出せていない」）を伝えれば、疑いや動機まで含めたペルソナを提案してくれる。

年齢・職業だけだと、レビューが「初心者には難しいかもしれません」程度の一般論で止まる。「SE歴26年の人だからできたのでは？」という具体的な疑いを設定しておくことで、その疑いに対する回答が本文に含まれているかを自動的にチェックさせられる。疑いの解像度がレビューの解像度を決める。

「60点を食らった」が全てを変えた

最初に通常モードで reviewer とは別にreader（美咲さん視点）にレビューしてもらったときの評価は好意的だった。「概ね良い」「第7章の健康管理が特に刺さった」といった反応。

ただ「本当にこれで大丈夫か？」という不安が残った。そこで批判的モードでもう一度依頼した。

「この本に1,500円払って後悔する理由を5つ挙げて」

返ってきたのが 60点 だった。

採点は「購買意欲・再読意欲・友人推薦意欲・離脱リスク・信頼性」の5つの観点で100点満点の主観評価を依頼した。具体的には「この本に1,500円払って後悔する理由を5つ挙げて。最後に100点満点で採点してください」という形で依頼している。AIが「なんとなく60点」と答えているのではなく、減点の根拠が5項目ごとに明示される形式だ。なお、60点・78点はいずれも1回の評価セッションで得た主観的なスコアだ。複数回評価すれば数点の誤差は出る。「数値化することで改善の指針が得られる」という活用方法に意味があり、点数そのものの絶対値にはこだわらないでほしい。

減点の内訳はこうだ（主な減点を抜粋すると）。

指摘	減点
「SE歴26年の人だから察知できたのでは。本当の素人でもできるのか半信半疑」	-15点
「第2章のセットアップが重い。一章に詰め込みすぎ」	-8点
「1週間で6本って嘘くさい。もう少し丁寧にフォローしてほしい」	-5点
「第5章のAIチームは自分にはまだ早い」	-4点

これらが主な減点だが、他にも各章で細かい指摘が積み重なった。

これらは reviewer（技術チェック）からは絶対に出てこない指摘だ。技術的に正確であることと、読者が「自分にもできる」と思えることは、完全に別問題だった。

60点から78点へ — 何を変えたか

批判的レビューの結果を受けて、CEOが対策を策定してwriterに修正を指示した。優先順位の判断基準は「減点が大きい順」ではなく「修正コストに対してスコア改善が見込める順」だ（-15点の項目でも対処が1行で済むなら最優先になる）。

指示した修正内容:

1. 全章に「SEスキルは使っていない」フォローを追加。「問題を言語化できるのもSEスキルでは？」という疑いに先手を打つ
2. 各章にコピペ可能なセリフ集を追加（「私でも再現できる」という証拠を作る）
3. 3章/4章/6章/7章に「うまくいかなかったケース」を各1段落追加
4. 著者プロフィール（SE歴26年）を第0章からあとがきに移動（冒頭で「SEの人の話か」と引かれるリスク回避）
5. 5章冒頭に「応用編です。飛ばしてOK」の注釈追加

修正後に再評価してもらった結果: 78点（+18点）。なお、再評価は修正前の会話を引き継がない新しいセッションで実施した。同じセッションでの自己採点にならないようにするためだ。

ちなみに通常モードの評価では刺さった箇所も明確になった。

• 1位: 第7章「体重67.2kgと言うだけ」
• 2位: 第3章「頭の外に出す感覚」
• 3位: 第8章「なんか変と言えばいい」

これは「どこを強化すればさらに点数が上がるか」の指針になる。

うまくいかなかったこと

全ての指摘が的確なわけではなかった。

• 的外れだったフィードバック: readerが「第6章のニュースレポート例が著者の趣味に偏りすぎ」と指摘した。実際にはターゲット読者（非エンジニア）がカスタマイズの自由度を理解するための意図的な例示だった。取捨選択は人間の仕事だ。
• ペルソナ名の混同: 6章の具体例で「田中美咲」という名前を使ってしまい、readerペルソナと混同する問題が発生した。仮定形（「EC会社の広報担当の方なら」）に変更した。ペルソナ名と本文中の登場人物は分けるべきだ。
• 批判的モードが厳しすぎるケース: 「1日100円」の価格訴求を「スタバ比較は品がない」と指摘された。ターゲット読者には効果的な表現だったが、後に別の理由（特定ブランドとの比較リスク）で削除した。批判的レビューの指摘が全て正しいとは限らない。

reviewer × reader の2軸体制

reviewer と reader の役割分担を整理するとこうなる。

観点	reviewer	reader
ファクトの正確性	◎	-
法的リスク	◎	-
感情の流れ	-	◎
離脱ポイント	△	◎
「嘘くさい」検出	-	◎
購買意欲	-	◎

また、reader のレビュー過程で、reviewer が見逃していた読者視点の問題点（例: 説明の前提知識が高すぎる箇所）に気づくことがある。技術的に正しい記述でも、読者の目線から見ると「意味が分からない」「前提が自分には難しすぎる」という問題が潜んでいることがある。

reviewer = 品質ゲート、reader = 顧客の声。両方あってはじめて「技術的に正確で、かつ読者に刺さる」文章になる。

この2軸体制を支えるガバナンスの話——reviewerが見落とした定数不一致という事故が「trigger リスト付き憲法」の整備につながった経緯——は「Claude Code の憲法を書いたら、1日で法律になった話」で詳しく書いています。品質管理の多層化がなぜ必要かの実例として読んでもらえると理解が深まります。

自分のプロジェクトで使うには

なお、このアプローチはコンテンツ制作に限らない。技術仕様書・README・設計文書でも「この読者はどこで詰まるか」「どの前提知識が抜けているか」をペルソナレビューで先出しできる。

このreader/reviewerの体制が組み込まれたマルチエージェント構成の全体像（タスク管理・リサーチ・発信の4軸）は「タスク管理・リサーチ・記事公開を全部AIに振ったら、人間はどこで判断すればよくなったか」で整理しています。writer/reviewer/readerの役割分担を把握したい方はこちらもどうぞ。

ペルソナ定義テンプレート

.claude/agents/reader.md に以下のテンプレートを保存する。

# reader.md — 読者ペルソナ定義

## ペルソナ: {名前}（{年齢}歳）

**属性**: {職業}、{スキルレベル}
**動機**: {なぜこの記事/本/ドキュメントを読むのか}
**疑い**: {読みながら持つ疑念。例: 「本当にそんなうまくいく？」「自分の環境でも動く？」}

## レビュー指示
- 「この言葉、意味が分からない」→ フラグ
- 「ここで離脱しそう」→ フラグ
- 「読み終えて、やってみたいと思えるか？」→ 判定

ディレクトリ構成

プロジェクトルート/
├── CLAUDE.md          # プロジェクト全体の指示（ルート直下に置く）
└── .claude/
    └── agents/
        ├── writer.md      # 執筆担当
        ├── reviewer.md    # 技術チェック担当
        └── reader.md      # 読者ペルソナ（今回追加するもの）

呼び出しフロー（1サイクルの具体的な流れ）

1. writerに「この記事を書いて」と依頼
2. 完成したらreviewerに「ファクトチェックして」と依頼
3. reviewerの指摘を修正
4. readerに「美咲さん視点でレビューして」と依頼（通常モード）
5. readerに「この記事に○○円払って後悔する理由を5つ挙げて」と依頼（批判的モード）
6. 批判的レビューの指摘から対策を決め、writerに修正を依頼
7. 修正後、新しいセッションでreaderに再評価を依頼

※マルチエージェント構成が既にある前提。ゼロからの環境構築は含まない。まだ構成がない方は、.claude/agents/ に reader.md を1つ置くところから始められる。他のエージェントがなくても、この記事の手法は試せる。

批判的レビューの頼み方（そのまま使えるプロンプト3例）

「この記事に1,500円払って後悔する理由を5つ挙げて」

実際にこのプロンプトを使ったときの出力（抜粋）:

「SE歴26年の人だから察知できたのでは。本当の素人でもできるのか半信半疑」（-15点） 「第2章のセットアップが重い。一章に詰め込みすぎ」（-8点） 「1週間で6本って嘘くさい。もう少し丁寧にフォローしてほしい」（-5点） 総合評価: 60点

「この記事の最大の弱点を3つ、読者が離脱する順に並べて」

「この記事を友人に勧めない理由があるとしたら何？」

実際にこのプロンプトを使ったときの出力（抜粋）:

「Claude Codeを使いこなしている人向けの内容に見える。まだ使い始めていない友人には早い」 「自分の環境で本当に同じようにできるかが最後まで分からなかった。もう少し具体的な再現ステップが欲しい」

通常モードのレビューだと「概ね良い」で終わりがちだ。批判的モードで頼むと、読者が心の中で持っている「でも……」が出てくる。

ROI感

方法	時間
reviewerのみ体制（ファクトチェック後に直接公開）	0分（ただし読者視点のチェックゼロ）
readerエージェント追加（定義5分 + レビュー依頼→結果→修正）	約30分/サイクル

「約30分」の内訳: - 批判的レビュー依頼→結果を受け取る: 5分 - 指摘の分析→対策の策定: 5分 - writerへの修正指示→修正完了: 10分 - 新しいセッションでの再評価: 10分

今回は批判的レビュー1回で60点→78点（+18点）の改善だった。

なお「78点で十分なのか？」という疑問が出るかもしれない。78点は「買って良かった」と言える水準には達しているが、「友人に強く勧めたい」まではいかないラインでもある。次の改善案としては、ペルソナ複数化（非エンジニア + エンジニアの2軸）と、ネタ帳段階でのreaderレビュー（構成の問題を執筆前に潰す）を考えている。

まとめ

AIが書いた文章をAIにレビューさせるのは矛盾ではない。視点が違えば別の発見がある。

• reviewer（技術チェック）だけでは、読者が「自分にもできる」と思えるかは分からない
• 読者ペルソナを定義して批判的モードで頼むと、「嘘くさい」「SEだからでしょ」という心の声が出てくる
• 60点を食らったからこそ、78点に辿り着けた

ペルソナの粒度は「疑い」まで定義すること、そして批判的モードで頼むことの2点が、通常のAIレビューとの差になる。

このブログで書いてきたAIエージェントチームの設計・運用をまとめた電子書籍を出しています。

コードを書けない私が、AIに「チーム」を持たせるまで（序章・第1部無料）

Claude Codeのマルチエージェント活用をさらに深掘りしたい方には、こちらの書籍が参考になる。

実践Claude Code入門―現場で活用するためのAIコーディングの思考法（Kindle版）

関連記事

• AIチームに「批評家」を加えたら、自分では気づかなかった誤りが3件出てきた——レビュワー・読者ペルソナ追加の実演
• Claude Codeで役割を与えると結果はどう変わるか——writer + reviewer 二体構成の実践記録

この記事のテーマを深掘りした本

コードを書けない私がClaude Codeで「AIチーム」と書き続けるまで ネタの自動収集から公開まで、書き続ける仕組みの育て方（序章無料）

シリーズ全6冊: Vol.1 作るまで ／ Vol.2 回すまで ／ Vol.3 書き続けるまで ／ Vol.4 仕組みを渡すまで ／ Vol.5 仕事を任せるまで ／ Vol.6 1人エージェントチーム