🧪

ChatGPTレビューを仕組み化する — 3ペルソナreviewer agentの観点設計

に公開
Markdown
AI駆動開発
Claude Code
エージェント設計
記事レビュー
tech

はじめに

技術記事を書くたびに ChatGPT や Gemini に構成レビューをもらっていましたが、同じような指摘を毎回もらっている ことに気づきました。

「冒頭に要約ブロックを入れたほうが良い」「詳細の前に全体像を」「英語用語に日本語副題を」――。これらは一度ルール化してしまえば、次の記事から自動適用できるはずです。

この記事は、外部 LLM の一回性レビューを、内製の reviewer agent（記事レビュー用エージェント）に観点として移植する アプローチを共有するものです。

3 ペルソナで記事を見る

記事レビューを「1 人の目」でやると、どうしても漏れが出ます。対象読者・編集者・ディレクターでは見るポイントが違うので、3 ペルソナに分けて観点を整理 します。

Zenn 向け 3 ペルソナ

実装ソース（.claude/agents/article-reviewer.md）のペルソナ定義をベースに、本記事の運用ではタイトル訴求 / 目次設計 / Zenn 表現規約などを各視点に拡張しています。

  • Webディレクター視点: 構成・読みやすさ・対象読者整合性・SEO最適化（本記事ではタイトル訴求 / 目次設計 / 想定読者を拡張観点として追加）
  • Webサイト編集者視点: 誤字脱字・表現統一・文章明確性・重複表現（本記事では Zenn 表現規約（Front Matter / 言語指定 / :::message）を拡張観点として追加）
  • Webエンジニア読者視点: 技術的正確性・コード検証・実装可能性

note 向け 3 ペルソナ

  • noteディレクター: タイトルフック / スマホ可読性 / note 内発見性
  • note編集者: JTF スタイル準拠 / 段落リズム / 表記揺れ
  • 想定読者: オピニオン / 体験 / 解説 の記事タイプごとに変動

ペルソナごとにチェックリストを持たせることで、1 人の先入観に寄らない評価 ができます。

観点の構造化（ChatGPT レビューから移植）

ChatGPT に記事を見てもらった時の指摘を「構成 / 圧縮 / 段落・セクション / 表現」の 4 カテゴリに分類し、Zenn 8 観点 + note 10 観点 として番号付きで整理しました。

Zenn 8 観点

  1. 冒頭で記事の価値を先出ししているか（構成）
  2. 詳細群の前に全体像を提示しているか（構成）
  3. 派生論点が本筋の後ろに配置されているか（構成）
  4. コマンド / コード断片が本文を埋めていないか（圧縮）
  5. 英語ラベルに日本語副題が添えられているか（圧縮）
  6. 各セクションの要点が 1 行で先出しされているか（段落）
  7. まとめ前に記事の主張を再掲しているか（段落）
  8. 硬い漢字タイトルを柔らかく言い換えているか（表現）

note 固有の +2 観点

  1. 段落の呼吸が作れているか / 2 スペース改行の過不足がないか
    • note は 2 スペース改行が <br /> として解釈されるため、Markdown を別プラットフォームから持ち込むと余白が倍増しやすい。Zenn には存在しない note 固有の落とし穴
  2. 対象読者への呼びかけが冒頭にあるか
    • note はタイムライン / 検索 / ハッシュタグ経由の初見読者が多く、「誰向けの記事か」をリードで明示しないと離脱しやすい

Zenn / note の観点差分（一覧）

# 観点 Zenn note
1 冒頭で記事の価値を先出し ✅ ✅
2 詳細群の前に全体像 ✅ ✅
3 派生論点は本筋の後ろ ✅ ✅
4 コード断片で本文を埋めない ✅ ✅
5 英語ラベルに日本語副題 ✅ ✅
6 セクション要点を 1 行で先出し ✅ ✅
7 まとめ前に主張を再掲 ✅ ✅
8 硬い漢字タイトルを柔らかく ✅ ✅
9 対象読者への呼びかけ — ✅（note 固有）
10 2 スペース改行の過不足 — ✅（note 固有）

上記をエージェントの SKILL（Claude Code の Skill 仕様に沿った運用手順）/ 定義ファイル（.claude/agents/article-reviewer.md および .claude/agents/note-article-reviewer.md）に記述し、レビュー時に毎回チェックする運用にしています。

エージェント化のメリット

ChatGPT に毎回頼むのに比べて、内製エージェント化すると以下が効きます。

  • 再現性: 同じ観点が毎回適用されるので、記事ごとの評価がブレない
  • オフライン: 外部 API 無しで評価できる
  • プロジェクト文脈: 著者の他記事との整合性や、リポジトリ規約（AGENTS.md / CLAUDE.md）を知っている
  • 回帰検出: 過去に同じパターンで指摘されたのを覚えている

一方、外部 LLM には「自分の記事を外の目で見る」という強みがあるので、内製エージェントで通した後に外部レビューで仕上げる 2 段構成が現実的です。

出力フォーマット

エージェントは reviews/zenn/<slug>.md または reviews/note/<state>/<slug>.md に以下の構造で出力します。

  • チェック結果（3 ペルソナ × 観点の表）
  • 共通チェックリスト（☑ 形式）
  • 指摘コメント（行番号 + 引用 + 問題点 + 提案）
  • 総合評価（良い点 / 改善点 / 推奨アクション）
  • SEO / 発見性改善提案

reviews/ の成果物は PR で管理し、本文への反映は別のスキル（review-applier）が採用/保留/却下の分類と共に diff を作ります。

まとめ

  • ChatGPT のような一回性レビューは、観点として抽出すればエージェントに移植できる
  • 3 ペルソナに分けて観点を整理することで、評価のブレが減る
  • Zenn 8 観点 / note 10 観点の差分を明示して、プラットフォーム固有の運用をカバー
  • 内製エージェント + 外部 LLM の 2 段構成が実用的

記事の品質を「気合い」ではなく「仕組み」で担保する方向に運用を寄せると、継続的な執筆が軽くなります。

関連記事

実装リファレンス

  • Zenn 用: .claude/agents/article-reviewer.md
  • note 用: .claude/agents/note-article-reviewer.md
  • 反映フロー: .claude/agents/review-applier.md

Discussion