「公開して大丈夫？」——この一言が出る時点で、品質チェックは機能していない。
大丈夫かどうかを人間の不安センサーに頼っている状態は、つまり仕組みがないということだ。私はWriters-hubで記事制作のパイプラインを組んでいるんだけど、品質チェックの自動化に本腰を入れたのは、ある失敗がきっかけだった。
米山さんに「これ、誰がOK出したの？」と聞かれて、誰も答えられなかった。チェックリストはあった。でも「チェックした」のチェックボックスが埋まっているだけで、何を見て何を判断したのかが残っていない。お願いベースの品質管理は、忙しい日に真っ先に崩壊する。
つまり、3ヶ月前の私たちだ。チェックリストを作って安心している人、レビュー依頼を出しても「LGTM」しか返ってこない環境にいる人、AIに書かせた文章をそのまま公開して冷や汗をかいたことがある人——この記事はそういう人に向けて書いている。
品質チェックは「工場の検品ライン」だ
検品を作業者の目視だけに頼っている工場はない。重量センサー、画像認識、抜き取り検査——複数のゲートを通過しないと出荷されない仕組みになっている。記事の品質チェックも同じ発想で設計した方がいい。
私たちが実際に回しているフローは、大きく3つのゲートで構成されている。
ゲート1: AI校正——機械が得意なことは機械にやらせる
ここ、大事。人間がやるべきじゃないチェックを人間にやらせるから、疲弊するし漏れる。
具体的に機械に任せているのはこういう項目だ。
- 誤字脱字・表記ゆれ: 「ユーザ」と「ユーザー」の混在、「Webサイト」と「WEBサイト」の揺れ
- 禁止表現の検出: 「画期的な」「革新的な」みたいな情報量ゼロの形容詞、「〜と言えるでしょう」の逃げ表現
- 構造チェック: H2/H3の階層が崩れていないか、リード文があるか、文字数が基準内か
これをClaude等のLLMに「スロップチェックリスト」として渡して自動検出させている。ポイントは禁止パターンを明示的にリスト化すること。「品質を高めてください」みたいな曖昧な指示では何も引っかからない。
悪い例:
この記事を校正してください。良い例:
以下の禁止表現が含まれていないかチェックし、該当箇所を行番号付きで報告してください:
- 「〜と言えるでしょう」「〜かもしれません」の連発（1記事3回以上で警告）
- 「画期的な」「革新的な」「注目すべき」（数値や事実に置き換え可能か判定）
- 「いかがでしたか」「参考になれば幸いです」（即削除）（まあ、禁止リストが長くなりすぎると今度は「何を書けばいいのかわからない」問題が出るんだけど、それは別の話）
ゲート2: ファクトチェック——数字とリンクは人間の記憶を信用しない
これもめちゃくちゃ大事。特にSEO記事でありがちなのが、「〇〇は年間△△億円の市場規模」みたいな数字が、出典なしで書かれているパターン。
私たちのルールはシンプルで、出典のない数値は書かない。書くなら出典URLを必ず併記する。AIに記事を書かせた場合、この部分は特に危険だ。もっともらしい数字を自信満々に出してくるけど、ソースを確認すると存在しない調査だったりする。
自動化している部分:
- 記事内のURLが全てアクセス可能か（404チェック）
- 引用元の日付が古すぎないか（2年以上前のデータに警告）
- 固有名詞の表記が公式サイトと一致しているか
手動で確認する部分:
- 数値の正確性（元データとの照合）
- 文脈の正しさ（数字は合っていても解釈が間違っているケース）
全部自動化できればいいんだけど、ファクトチェックの「文脈判断」は今のところ人間の仕事だ。ここを省略すると、正確だけど意味が違う——という最も厄介なミスが通過する。
ゲート3: 人間レビュー——「で、読んで面白い？」
AI校正とファクトチェックを通過した記事は、正確で構造的には整っている。でも「読みたいか」は別の話。
レビュアーに求めているのは3点だけ:
- 読者が途中で離脱しそうな箇所はどこか（具体的に行番号で指摘）
- 「で、結局何が言いたいの？」と思った箇所はどこか
- 自分がこのテーマを検索した人だとして、この記事で満足するか
「問題なし」だけのレビューは不合格にしている。何かしら指摘がある方が自然だし、指摘が出ないレビューは読んでいない可能性が高い。
（正直、このルールを導入した時は「厳しくない？」と言われた。でも「問題なし」レビューが通った記事で後から修正が発生する確率を数えたら、指摘ありレビューの3倍あった。データで黙らせた）
「チェックリストを作って満足」症候群を防ぐ設計思想
ここからが本題。ゲートを3つ設置しました、で終わりにすると半年後には形骸化する。チェックリストは作った瞬間が品質のピークで、あとは劣化する一方だ。
「お願いで守れることは仕組みで守る必要はないが、仕組みで守るべきことをお願いで済ませるな」——これが設計思想の核になっている。
具体的にやっていること:
チェック結果を「証拠付き」で残す
「チェックしました」ではなく「何を見て、何を判断したか」を残す。AI校正の出力ログ、ファクトチェックで照合した出典URL、レビュアーの指摘コメント——全部記事に紐づけて保存している。
これの何がいいかというと、問題が起きた時に「どのゲートが漏らしたか」が特定できる。犯人捜しではなく、仕組みの穴を塞ぐためだ。
レビュー→修正→再レビューのループを回す
一発OKを目指さない。修正が入ったら必ず再レビューを通す。「軽微な修正だから再レビュー不要」は禁止。軽微かどうかを判断するのも品質チェックの一部だから。
ループの上限は3回。3回修正しても通らない場合は、記事の方針自体を見直す。チェックで直すのではなく、設計からやり直す。
チェック項目は「失敗から逆算」で更新する
公開後に問題が見つかったら、その問題を検出できるチェック項目を追加する。逆に、半年間一度も引っかからなかった項目は削除を検討する。チェックリストは生き物だ。増え続けるだけだと、チェックする側が麻痺する。
私たちの場合、四半期に1回チェックリストの棚卸しをしている。追加した項目数と削除した項目数がだいたい同じくらいになるのが健全な状態。
まずはここから始めればいい
全部いきなりやる必要はない。段階的に導入するなら、この順番をおすすめする。
- 禁止表現リストを作る——自社の過去記事から「これはまずかった」という表現を10個集める。それをAIに渡して自動検出させる。これだけで公開前の不安が半分になる
- レビューに「証拠」を求める——「問題なし」禁止ルールを入れる。指摘が最低1件出るまで完了にしない
- 失敗ログからチェック項目を育てる——公開後のミスを記録して、チェックリストに反映する仕組みを作る
「公開して大丈夫？」が消えるのは、品質に自信がついた時じゃない。仕組みが「大丈夫」と証拠付きで答えてくれる時だ。人間の不安を消すのは人間の自信じゃなくて、仕組みの信頼性なんだよね。
まあ、全部完璧に回している会社があったら、それはそれで別の意味で心配だけど。大事なのは「お願い」から「仕組み」への移行を少しずつ進めること。最初の一歩は、禁止表現リスト10個からで十分だ。