AIに記事のチェックやレビューを任せているのに、思ったほど楽になっていない——そう感じている方に向けた記録。一人で運営しているこのサイトでは、実験LPの第2弾を作るときに、複数のAIレビュアーでチームを組むやり方を初めて導入した。その後は記事レビューにも同じ体制を広げている。
導入当初は記事1本の執筆時間は5時間が4時間になった程度で、負担が減った実感は薄かった。そこから「AIに何をさせるか」「指摘をどんな形で戻させるか」を決めていったら、最終的に2.5時間程度まで縮み、それ以上に自分の頭の疲れ方が変わった。その過程と設計の考え方を、AIへの任せ方を見直すひとつのきっかけとして読んでもらえたら。
記事レビューを任せているAIチームの全体像
このサイトは執筆も校正も公開作業も一人でやっている。そのうちレビューを、Claude Code（AIに文章やコードの作業を任せられるツール）のサブエージェント——役割を決めて呼び出せる、専任のAIレビュアーのような機能——に任せている。
きっかけは、レビュー工程の効率化だった。サイトの運用を始めて半月ほど、記事を書くたびにレビューを複数の視点で回していて、「この工程はもっと効率化できないか」と考えたのが立ち上げの出発点になっている。初めてチームとして組んだのは、実験LP第2弾の制作。その後、記事レビューにも広げて、今の在籍は6体になっている。
| レビュアー | 見ているもの | 主な出番 |
|---|---|---|
| 編集者 | 文体・禁止表現・記事構成をライティングルールと照合する | 記事 |
| 想定読者 | 「自分ごとに感じられるか」「業務に持ち帰れるか」を読者目線で評価する | 記事 |
| 懐疑的な読み手 | 根拠の薄い記述や論理の飛びを指摘する | 記事・LP |
| ターゲット顧客 | LPをWebに詳しくない発注者の目で読む | LP |
| 競合 | 差別化が効いているか、真似されやすくないかを見る | LP |
| コード担当 | LPやテーマのHTML/CSSをレビューする | LP・実装 |
このメンバーを、作るものとフェーズに合わせて組み替えている。在籍の6体で足りない視点は、その場で役割を指定する臨時のレビュアーで補う形だ。
| フェーズ | チーム編成 |
|---|---|
| 記事レビュー | 編集者＋想定読者＋懐疑的な読み手 |
| LP骨子 | ターゲット顧客＋懐疑的な読み手＋競合 |
| LPコピー | コピー担当（臨時）＋問い合わせ獲得担当（臨時） |
| LP実装後 | コード担当＋使い勝手担当（臨時） |
役割を分けているのは、1人のAIに「全部まとめて見て」と頼むと、指摘が広く浅くなりがちだったから。「編集者として文体だけを見る」のように役割を絞ると、同じAIでも指摘の深さが変わった。
仕組みとしてはClaude Codeの機能だが、「役割を絞って頼む」「直してよいものと判断が要るものを分けて返させる」という考え方自体は、特定のツールに依存しない。普段ChatGPTなどを使っている方にも、頼み方の設計の話として読んでもらえたらと思う。
導入直後：指摘が増えた分、自分の確認作業も増えた
導入してすぐ、指摘は十分すぎるほど出るようになった。ただ、指摘が増えるのと同時に、それを確認する自分の工数も増えていった。指摘を受け取った後の判断が、すべて自分に残っていたからだ。
当時の運用は「レビューして」と頼み、返ってきた指摘リストを上から読んでいくだけ。1件ずつ「直すか、直さないか」を自分で決める必要があり、しかもその判断のたびに「この指摘を採用したら、記事が誰向けなのかぶれないか」を、サイトのペルソナ設計（想定読者の設定）に照らして確認し直していた。レビューを増やすほど、この確認作業も増える。指摘の量と作業の進みが比例しなかった。
執筆時間で言えば、5時間が4時間になった程度。レビューの下書きをAIがやってくれる分は確かに速くなったが、指摘リストを前にした自分の判断の作業は、導入前とほとんど変わっていなかった。
当時、実際にAIへ戻したフィードバックがログに残っている。
- フィードバックが1回で終わってしまう。1回の修正反映だけでは文章の精度が低い。修正が終わったら、再度自分で全体レビューまでやってほしい
- 全体の完成度が9割を超えるまで、レビュー完了にしない
- 直しているうちに、方針のぶれた指摘が混ざることがある。軸はぶらさない
- 2回以上出てくる汎用的な指摘は、私の承認を取ったうえでライティングルールに追加
今読み返すと、これはAIへの不満というより、「レビューの終わり方」と「指摘の戻し方」のルールを自分が決めていなかった、という話だった。
ルール整備：「AIが直すもの」と「自分が判断するもの」を分けた
そこで、レビューの結果を2つのリストに分けて返ってくるようにした。
- 修正アクションリスト：私のチェックなしで、AIがそのまま直してよいもの
- 要判断リスト：私が決めてから直すもの。選択肢（A案／B案）・根拠・影響範囲をセットで添える
分ける基準は「正解がルールで決まっているか」。表記の統一や禁止表現のように、ルールファイルに正解が書いてあるものはAIが直して構わない。記事の構成を変える、トーンを変える、施策レベルの判断が絡む——そういうものは要判断リストに回す。
もうひとつ、指摘を使い捨てにしないフローも足した。2回以上繰り返し出てくる汎用的な指摘は、私が承認したらライティングルールのファイルに追記する。次の記事からは「指摘されて直す」のではなく「最初からそう書いてある」状態になる。
やってみて分かったのは、この線引きをするには、まず「自分は何を基準に採否を決めているのか」を言語化しないといけない、ということ。ルール整備の実態は、AIの設定作業ではなく、自分の判断基準の棚卸しだった。
それでも残った作業：複数の指摘リストの突き合わせ
ルールを整えて、レビューはかなり回るようになった。自分が判断する機会も、要判断リストに絞られて確実に減った。ただ、レビュアーが複数いると、指摘リストも複数返ってくる。一人のレビュアーのときにはなかった問題が出てくる。
- 重複：同じ箇所を、編集者と想定読者が別の言い方で指摘してくる。同じ問題なのか別の問題なのかの見極めは私がやる
- 矛盾：「説明を足したほうがいい」と「冗長だから削ったほうがいい」が同じ段落に同時に付く。どちらに倒すかは私が決める
この突き合わせを、自分で細かくやっていたわけではない。設計の時点から、共通する指摘と意見が割れた箇所を整理して、対立には対応案も付けて返すところまで、レビュー側に任せていた。私に残るのは「どちらに倒すか」の最終判断だけ。ただ、この統合の段取りは記事のたびにその場で指示して組んでいたので、次はここを型として固定したくなった。
チーム化の設計：並列レビューと「議事録係」
レビュアーは当初、チームではなく単体で動かすことから始めた。1体ずつ回していけば、レビュアーごとの個別のフィードバックが出てくる。それぞれの精度をチューニングしたうえでチームにしたい、という考えがあった。ここまでの期間は、いわば1体ずつの試用期間だった。
チューニングが一段落したところで、レビュアーを1体ずつ呼ぶのをやめ、複数のレビュアーを同時に走らせて、結果の統合まで含めて任せる形に組み替えた。統合の型はこう決めた。
- 共通指摘（複数のレビュアーが同じ箇所を指摘）→ 最優先で対処
- 意見対立（評価が割れた箇所）→ 要判断リストへ。私が決める
- 1視点のみの指摘 → 見逃せないものだけ抜粋
あわせて、フィードバックで要望していた「完成度9割」を仕組みにした。9割そのものを測る方法はないので、完了条件は「指摘が0件になること」に置き換えている。修正を反映したら自動で再レビューに回し、指摘がなくなるまでレビューと修正を繰り返させる。実際、少し前に公開した実験ログの記事では、当時の編成だった編集者と想定読者の2体で、レビューが4巡走った。第1回で出た禁止表現の指摘を直したら、第2回では「直した後の表現」がまた引っかかり、第4回でようやく指摘0件。この間、私がやったのは方針の確認と、最後の通し読みだけだった。
もうひとつ、レビューの最後に「振り返り」の工程を足した。
記事を書き終えたら、今回のやり取りの中から、①次の記事のネタになりそうな気づき、②校閲ルールに追加できる指摘、がないかをチームに拾わせて、私が承認したものだけ蓄積していく。記事を作れば作るほどルールが増えて次の記事の精度が上がり、同時にネタ集めも進む——そういう循環になるように組んでいる。
記事1本の執筆時間は、導入前が約5時間、導入だけの時期は4時間止まりで、ルール整備とチーム化を経て2.5時間程度になった。数字は体感の記録で厳密に計測したものではないが、直近で公開した2本の記事は、執筆から公開作業まで含めて2.5〜3時間に収まっている。記事のテーマや長さもばらばらなので、書き慣れの影響も混ざっていると思う。それでも内訳を振り返ると、AIを入れたことそのものの寄与は1時間ほどで、残りの1.5時間分を縮めたのは「AIが直すもの」と「自分が判断するもの」の線引きだった。そして時間以上に変わったのは、「指摘リストを前に自分が考え込む時間」——判断の負担のほうだった。
体制づくりにかかった手間も書いておく。レビュアーの定義と最初のルールファイルの整備は、もともとあった文体ガイドを流用できたこともあり数時間で済んだ。ただ、それで完成にはならず、記事を書くたびにフィードバックで直す調整が3週間ほど続いている。導入した日から楽になるものではなかった、というのが正直なところ。
設計するうえで判断したことが3つある。
- 裁定の基準を先に文章化する。「足せ」と「削れ」の矛盾をAIに裁かせるには、「迷ったら削る。ただし読者の判断材料になる情報は残す」のような基準を、先に言葉にして渡す必要があった。AIに任せる範囲を広げる作業は、ここでも結局、自分の判断基準の言語化だった。
- 記事を書くこと自体は自動化しない。レビューと統合は任せるが、本文の生成までAIに寄せることはしなかった。このサイトの記事の価値は「何を考えてどう判断したか」の記録で、そこを自動化したら書く意味がなくなると考えたから。
- 「議事録係」を1体に決める。複数のAIを同時に走らせると、レビュー結果を同じファイルに書き込もうとしてぶつかることがある。結果をまとめて記録する係を1体に固定し、他のレビュアーは報告だけ返す形にした。人間のチームで「誰が議事録を書くか」を決めるのと、やっていることは変わらなかった。
まとめ：観察して分かったこと
- AIレビューを入れただけでは、執筆時間は5時間→4時間止まりだった。2.5時間程度まで縮めたのは、「AIが直すもの」と「自分が判断するもの」の線引きのほうだった
- AIレビュアーを増やすと、指摘の統合と裁定という仕事が新しく人間側に残る。そこを任せるには、自分の判断基準を先に文章化する必要があった
- レビューは任せても、記事を書くこと自体は自分に残した。「何を任せないか」を決めるのも設計のうちだと感じている
この体制も、運用しながらまた形を変えていくと思う。新しい気づきや大きな変更があれば、そのときにまた記事として残す。
実験の経過はX（@AO_weblab）で発信しています。気になる方は、フォローしてもらえたら。