AIが生成したコンテンツをレビューするシステムを作ってみた

何が課題だったのか

私たちは普段、エディタとしてCursorを活用しながら、Claude Codeを使っています。

MTGデータやこれまで作ってきたコンテンツをクレンジングして活用しやすいようにし、5-7の工程ごとのプロンプトを繋いだりして1本の記事のクオリティを上げる。

それを一気に走らせていく上で、CursorやClaude Codeを使えば記事の骨格から本文まで、あっという間に生成できますし、並列も可能。

でも、レビューとなると話が別でした。

まず、Markdownファイルを1つずつ開く手間があります。フォルダの中に10本の記事があったら、10回ファイルを開いて、それぞれ確認していく。地味に面倒です。

次に、プレビューが見づらい。Markdownの生テキストを見ても、実際にどう表示されるかが分かりにくい。タイトルが長すぎないか、見出しの階層は適切か、読みやすい構成になっているか。確認するには、実際にビルドするか、頭の中で変換するしかない。

そして、メタ情報のチェック。slug、カテゴリ、タグ、著者、アイキャッチ画像...。これらが正しく設定されているかを、frontmatterを見ながら確認する必要がある。

さらに、アイキャッチ画像の作成。できれば同一エディタ内でワンクリックで作成したい...。

コンテンツを作る生産性が上がっても、レビューや後工程がボトルネックになっていたんです。

解決策：Cursorのブラウザで、ローカルのWebアプリを開くだけ

ここがミソです。

やっていることは、Cursorのブラウザパネルで、ローカルで立ち上げたWebアプリを表示しているだけ。それだけ。

Cursorにはブラウザパネルがあります。普通はドキュメントを見たり、参考サイトを開いたりするのに使う。でも、ローカルホストも開ける。

だから、レビュー用のWebアプリをNext.jsで作って、ローカルで立ち上げて、Cursorのブラウザで開く。これで、エディタとレビューシステムが1画面に収まる。

ファイルを編集しながら、同じ画面でプレビューを確認できる。わざわざブラウザを切り替える必要がない。ちょっとしたことなら直接、大きく変えるならClaude Codeで大幅に修正させて、その結果をすぐにプレビューで確認できる。

この「1画面で完結する」というのが、思った以上に快適でした。

起動も一瞬

起動はClaude Codeのスキルを作っているので、コマンド一発で立ち上がります。毎回コマンドを打つ必要すらない。

レビューシステムの全体像

技術スタックはこんな感じです。

• Next.js 15（App Router）
• React 19
• Tailwind CSS v4
• gray-matter（frontmatter解析）
• remark/rehype（Markdown変換）
• diff（差分検出）
• Playwright（アイキャッチ生成）

構造は至ってシンプルです。

生成フォルダ（AIが生成したコンテンツが貯まる）
    ↓
レビューシステム（Webアプリでレビュー）
    ↓
FIXフォルダ（レビュー完了したコンテンツ）
    ↓
公開フォルダ（自動で公開処理）

AIが生成したコンテンツは生成フォルダに入ります。レビューシステムはそのフォルダを監視していて、中にあるMarkdownファイルを一覧表示する。

レビューが終わったらFIXフォルダに移動して、あとは自動で公開処理が走ります。

画面構成を詳しく解説

レビューシステムの画面は、4カラム構成になっています。

左カラム：ファイル一覧

生成フォルダ内のMarkdownファイルを一覧表示します。更新日時順に並んでいるので、最近生成されたコンテンツが上に来ます。ファイルをクリックすると、中央のエディタにその内容が表示されます。

中央左：Markdownエディタ

シンタックスハイライト付きのテキストエディタです。frontmatterの部分はYAML形式で、本文はMarkdown形式で色分け表示されます。

ここで直接編集することもできますが、後述するように、VSCodeやClaude Codeで編集してもOKです。

中央右：プレビュー

Markdownをリアルタイムでプレビュー表示します。編集するとすぐにプレビューが更新されるので、「この書き方で読みやすいかな」がすぐに分かります。

スクロール連動も実装しています。エディタをスクロールすると、プレビューも同じ位置にスクロールする。逆も然り。長い記事でも、今見ている箇所がすぐに分かります。

右カラム：設定パネル

ここが操作の中心です。

• メタ情報の編集：slug、カテゴリ、タグ、著者をドロップダウンで選択できます。frontmatterを直接編集しなくても、UIから変更できる。
• 編集開始ボタン：学習機能のトリガー。これを押すと、現在の状態がスナップショットとして保存されます。
• 保存ボタン：変更をファイルに保存します。
• 公開ボタン：差分を分析して学習データを保存し、ファイルをFIXフォルダに移動します。
• アイキャッチ生成ボタン：ワンクリックでアイキャッチ画像を自動生成します。

学習機能の仕組み

レビューで毎回同じような修正をしていることに気づきました。

「私たち」を「俺たち」に変える。語尾を柔らかくする。特定の表現を別の言い回しに置き換える。こういった修正が、何度も繰り返し発生していました。

これをAIに学習させれば、次回から自動で直してくれるはずです。そこで、学習機能を組み込みました。

フローはこうなっています

[ファイル選択]
     ↓
[編集開始ボタン] ← スナップショットを保存
     ↓
  編集（UI / VSCode / Claude Code など、どの方法でもOK）
     ↓
[公開ボタン]
     ↓
  差分分析 ← スナップショットと現在の状態を比較
     ↓
  レビュー種別に分類（taste / fact / quality）
     ↓
  学習データを保存
     ↓
  ファイルをFIXフォルダに移動

レビュー種別について

差分は、今のところ3つの種別に分類されます。

種別	説明	例
taste	テイスト・文体の修正	「私」→「俺」、敬体→常体、表現の調整
fact	ファクト・正確性の修正	「2010年」→「2025年」、固有名詞、数値
quality	クオリティ・構成の修正	段落の入れ替え、大幅な書き換え、論理の改善

この分類があると、「テイストの修正は自動化できそうだけど、ファクトチェックは人間がやるべき」といった判断ができます。

保存される学習データの形式

学習データは、種別 × カテゴリ ごとにファイルが分かれています。

learnings/
├── taste/
│   ├── knowhow.md       # ノウハウ記事のテイスト修正
│   ├── ai-thinking.md
│   └── create.md        # 作ってみた記事のテイスト修正
├── fact/
│   └── ...
└── quality/
    └── ...

学習データの中身はこんな感じです。

## 2026-02-06: AIが生成したコンテンツをレビューするシステムを作ってみた

### 変更箇所
| 元 | 後 |
|---|---|
| 私たちは〜と考えています | 俺たちは〜と考えている |
| 〜することができます | 〜できる |

### 学習ポイント
- 一人称は「俺たち」を使用
- 可能表現は「〜できる」に簡略化
- 敬体より常体を好む

このデータが蓄積されていくので、次にAIでコンテンツを生成するときに「過去の修正履歴を参考にして」と指示できます。または、編集ガイドラインや生成プロンプトの中に組み込めるようにして、以後同じようなレビューが発生しないベースを作ることも可能。

ポイント：学習するかどうかを選べる

「編集開始」ボタンを押さないと、学習されません。

ちょっとした誤字を直すだけなら、ボタンを押さずにそのまま保存すればいい。学習させたい修正のときだけ、ボタンを押して記録する。

この切り分けができるので、不要なノイズが学習データに入り込みません。「この修正は例外的なもので、次回以降は参考にしてほしくない」というケースにも対応できます。

直接編集とAI編集、両方対応

レビューシステムを作るとき、最初は「この画面だけで完結させよう」と考えていました。

でも、それは違うなと思い直しました。

大幅に書き直したいときは、Claude Codeを使いたい。「この記事、論理構成がおかしいから全体的に直して」みたいな指示を出したい。ディテールだけ直すなら、直接編集した方が速い。状況によって、最適な編集方法は変わります。

だから、どの方法で編集してもOKという設計にしました。

使い方

1. レビューシステムでファイルを選択
2. 「編集開始」ボタンを押す（スナップショット保存）
3. 設定パネルからファイルパスをコピー
4. Claude Codeで開いて、大幅に修正させる
5. レビューシステムに戻って、プレビューを確認
6. 細かい調整はレビューシステム上で直接編集
7. 「公開」ボタンを押す

学習機能は差分を取る仕組みなので、どの方法で編集しても、変更点は記録されます。レビューシステム上で編集しても、VSCodeで編集しても、Claude Codeで編集しても、最終的な差分が学習データになります。

変に機能を縛らなかったのが、結果的に使いやすさにつながりました。

アイキャッチ自動生成が想像以上に楽

設定しておけば、ボタンを押して3秒で生成から挿入まで完了。これが一番時間短縮になった機能です。

従来、アイキャッチ画像を作るのは、地味に手間がかかる作業でした。

1. Figmaを開く
2. テンプレートをコピーする
3. タイトルを入れる
4. フォントサイズや改行位置を調整する
5. 画像として書き出す
6. 適切なファイル名を付ける
7. 所定のフォルダに保存する
8. 記事のfrontmatterにファイル名を登録する

1枚作るのに、最低でも3〜5分はかかっていました。10本の記事があれば、30分以上がアイキャッチ作成に消えていく。

自動化の仕組み

これを3秒で終わらせる仕組みを作りました。

[アイキャッチ生成ボタン]
     ↓
  記事のカテゴリを判定
     ↓
  カテゴリに応じたHTMLテンプレートを選択
     ↓
  タイトルをテンプレートに挿入
     ↓
  Playwrightでスクリーンショット撮影
     ↓
  ファイル名を自動生成（slug.png）
     ↓
  所定のフォルダに保存
     ↓
  frontmatterのicatchフィールドを自動更新

テンプレートの仕組み

アイキャッチのデザインは、HTMLとCSSで作っています。

テンプレートごとにデザインが違います。「作ってみた」は工作っぽいイメージ、「使ってみた」は実験っぽいイメージ、「考えてみた」は思索的なイメージ。カテゴリを見て、自動でテンプレートが選ばれます。

HTMLテンプレートの中身はこんな感じです。

<div class="card">
  <div class="category-badge">つくってみた</div>
  <h1 class="title">{{TITLE}}</h1>
  <div class="logo">KAAAN</div>
</div>

{{TITLE}} の部分に、記事のタイトルが挿入されます。

Playwrightでスクリーンショット

HTMLをブラウザで開いて、Playwrightでスクリーンショットを撮ります。

const browser = await playwright.chromium.launch();
const page = await browser.newPage();
await page.setViewportSize({ width: 1200, height: 630 });
await page.goto(`file://${templatePath}`);
await page.screenshot({ path: outputPath });
await browser.close();

OGP画像の推奨サイズ（1200×630px）でビューポートを設定して、そのままスクリーンショット。これだけで、きれいなアイキャッチ画像ができあがります。

実際の操作

レビューシステムで「アイキャッチ生成」ボタンを押すだけ。

3秒くらい待つと、プレビューにアイキャッチ画像が表示されます。frontmatterのicatchフィールドも自動で更新されているので、何もしなくてOK。

デザインを変えたければ、HTMLテンプレートを編集するだけ。新しいカテゴリが増えたら、テンプレートを追加するだけ。メンテナンスも楽です。

15分で作れる

このレビューシステム、初回版は15分くらいで作りました。

Next.jsのプロジェクトを立ち上げて、ファイル一覧を表示するAPIを作って、Markdownをプレビューするコンポーネントを作って。Claude Codeに「こういうの作って」と指示すれば、基本的な形はすぐにできあがります。

そこから、使いながらチューニングを繰り返している感じです。「スクロール連動があると便利だな」と思ったら追加する。「学習機能があると次が楽になるな」と思ったら追加する。

最初から完璧なものを作ろうとしなくていい。まず動くものを作って、使いながら改善していく。AIを使った開発では、このサイクルが回しやすいです。

それだけでもレビューがかなり効率的になりました。学習機能があるとAIの出力品質も上がっていくので、おすすめです。

今後やりたいこと

現状は記事（Markdown）のレビューに特化していますが、今後は拡張していきたいと思っています。

あらゆるタイプのコンテンツに対応する

動画、画像、音声など、Markdown以外のコンテンツもレビューできるようにしたい。プレビューの仕方は変わりますが、「生成 → レビュー → 公開」というフローは同じです。

公開先を複数持つ

今はひとつのサイトに公開していますが、同じコンテンツを複数のプラットフォームに展開したいケースもあります。note、Qiita、自社サイト...。レビューシステムから、どこに公開するかを選べるようにしたい。

複数人で使えるようにする

今は一人で使うバージョンですが、チームで使えるようにも設計したい。誰がどの記事をレビュー中か、どこまで進んでいるか、が可視化されると、チームでのコンテンツ制作がもっとスムーズになるはずです。

例えばですが...

毎日アメリカ、日本で話題になった情報を取得、自身の考えとX投稿のロジックを組み立ててることで、毎朝Xの投稿が出来上り、レビューして良いものだけ予約投稿したら、Xにその時間に公開される...

みたいなのも作ったのですが、これ個人アカウントだとちょっと心苦しくなってやめました。

が、こういうのがさまざまにできるといいね、と思ってます。

最後に

改めて、ポイントをまとめます。

Cursorのブラウザで、ローカルのWebアプリを開くだけ。

これだけで、エディタとレビューシステムが1画面に収まる。ファイルを編集しながら、プレビューを確認できる。Claude Codeで修正させて、結果をすぐに見られる。

特別な技術は使っていません。Next.jsで普通のWebアプリを作って、ローカルで動かしているだけ。でも、それを「どこに表示するか」を工夫するだけで、ワークフローが大きく変わりました。

AIの生産性を活かすために、周辺の仕組みも一緒にアップデートしていく。

そういう発想で、これからも「作ってみた」を続けていきます。