AIが書いた記事をAIが差し戻す｜公開前チェック5段階の中身

AI記事の品質管理は、書いたAI自身の判断だけに任せていません。執筆・独立ファクトチェック・機械検証・批評・修正という5段階のラインを通し、全段を通過した記事だけをreviewedにします。本記事は各段が捕まえる誤りの対応表と、実際に差し戻された15件の指摘、そしてどの段でも捕まらなかった漏れを、自社の記録（2026-07-28確認）から公開します。

01結論：AI記事の品質管理は、執筆とファクトチェックを分けた5段階で担保します

結論は3点です。

1. AI記事の品質管理は、書いた本人とは別の目で見る仕組みを5段階に分けて実装しています。
2. 各段が担当する誤りの型は違います。1段だけに頼ると、担当外の誤りが素通りします。
3. 段の数より、段と段の継ぎ目に隙間がないかを見ることが、実物の品質管理です。

5段階は、執筆（Write）→独立ファクトチェック（原典照合）→機械検証（build.py）→批評（悪魔の代弁者）→修正、の順に並びます。修正が終わると独立ファクトチェックへ戻り、指摘がゼロになるまで繰り返します。全段を通過した記事だけがstatus: reviewedになります。

この記事自体が、5段階を扱う自社ラインをそのまま開示する記事です。2026-07-28時点で、案件フォルダに残る批評ログ・改稿履歴・機械検証スクリプトを直接確認しました。本文の数字はすべてそこからの実測です。

検索エンジンの品質ガイドラインも、AI生成を含む自動化の使用を読者に分かるようにしているかを自己点検項目に挙げています（出典: Google公式）。制作体制を記事として開示するのは、この点検に対する自社の回答です。

02AI記事の品質ラインは、5段階をどの順番で・誰が担当するか

5段階は、担当を分けて初めて機能します。同じ担当が2つの段を兼任すると、その担当の見落としが2回連続で素通りします。

Claudeの公式ガイドは、引用元となる文を直接引かせ、裏づけが見つからない主張は取り下げさせる方法をハルシネーション対策として挙げています（出典: Anthropic公式）。②の独立ファクトチェックは、この裏づけ探しを記事単位でやり直す工程です。

Claude Codeのサブエージェントは、役割ごとに独立した文脈で作業し、要約だけを親へ返す設計です（出典: Claude Code公式）。品質ラインの②〜④も、この分業の考え方を記事審査にそのまま当てはめています。

表の「実装状況」が示すとおり、②は現時点で独立した工程になっていません。実務では④の批評担当が、原典照合と横断チェックをまとめて1回で行っています。次の章で、その1回がどこまで拾えたかを見ます。

「5段階」は、公開前の審査だけを切り出した数え方です。記事の構成を決める工程や、公開可否を最終判断する監修は、この5段階の前後にあります。審査の中身を独立で数えると5段階、審査の前後まで含めて数えると別の数え方になります。数え方が違っても、②〜④が果たす役割は変わりません。

03AI記事の品質管理表｜5段階がファクトチェックでどの誤りを捕まえるか

5段階を設計どおりに割り当てると、誤りの型ごとに担当が決まります。ただし実際にどの段が捕まえたかは、設計と一致するとは限りません。

7行のうち5行は、本来②か③が担当のはずの誤りを、④の批評が肩代わりして捕まえています。想定どおり本来の段が捕まえたのは2行だけです。②を独立工程として分離していない現状では、④が拾い損ねると誰も拾いません。

批評ログを実測すると、この初稿は15件の指摘でREJECTと判定されました。内訳は重大4件・重要6件・中4件・軽微1件です（2026-07-28に批評ログを直接確認）。次の章で、重大4件の中身を見ます。

04品質ラインで実際に差し戻された15件｜重大4件の中身

重大と判定された4件は、いずれも公開後に読者から指摘されうる種類の誤りでした。

1つ目は、稼働実績の誤断定です。「常駐実行で動いている社内チャットの応答支援は」と現在形で書いた箇所を、批評担当がlaunchctl list | grep com.webmarksで実測しました。実際にロードされていた自社ジョブは1本だけで、記述した処理は稼働していませんでした。

2つ目は、公式仕様の誤読です。Claude Codeのフックの判定について、全面停止と全面自動化の中間に4段階の自律度がある、という趣旨の説明をしていました。原典を当たり直すと、判定はallow（許可）・deny（拒否）・ask（確認）の3つで返す設計でした。判断しないときはdefer（通常の権限フローへ戻す）を使うだけで、自律度の段階という説明自体が誤りでした。

3つ目は、社内規約からの無申告の逸脱です。当時の規約は字数上限・図解点数・タイトル幅を数値で定めていましたが、初稿はいずれも上限を超えていました。規約を破ること自体より、破った事実を記録せずに超えていたことが問題でした。

4つ目は、参照整合性のエラーです。本文中で他記事8本を名指ししていましたが、8本とも執筆前の記事で存在しませんでした。機械検証のスクリプトを実行すると、8件とも「リンク先が存在しない」でNGと判定されました。

4件に共通するのは、書いた本人には見えていなかった点です。稼働実績と公式仕様は原典に当たらないと分からず、規約逸脱は数え直さないと分からず、リンク切れは記憶ではなく機械的な突合でしか分かりません。

批評ログは、指摘1件をseverity（重大度）・where（該当箇所）・problem（何が問題か）・fix（どう直すか）の4項目で記録しています。1つ目の指摘は、実際には次の形で残っています（2026-07-28に案件フォルダから直接確認）。

{
  "severity": "重大",
  "where": "H2-3「具体例」本文（常駐実行の段落）",
  "problem": "現在形で稼働を断定しているが、launchctlの実測と一致しない",
  "fix": "3層の実例を公開前にすべて実測し、動いていなければ時制を過去形にするか状態を明記する"
}

4件とも、指摘だけでなく直し方までがログに残ります。修正では、動いていない処理の時制を過去形に変えました。フックの判定はallow・deny・ask・deferの4値として、そのまま書き直しました。

規約の上限は、特例を追加したうえで超過した事実を明記しました。存在しない8本の参照は、いったん本文から外しました。指摘を消すだけでなく直した理由まで残すことが、次の記事の執筆チェックに戻せる形にする条件です。

05品質ラインをすり抜けた漏れ｜数字はなぜ二重に間違っていたのか

15件の指摘は、書いた本人が気づけない誤りを広く拾いました。それでも、1つの数字だけは2回の改稿を通過し、最終稿の直前まで残りました。

姉妹メディアの公開本数という数字です。最初の記録では、案件管理台帳の古い表記だけを根拠に「1本も公開されていない」と報告していました。これに気づいた人が本番URLを開き、「189本」へ訂正しました。

一見、これは正しい訂正に見えます。しかし「189」という数字は、本番ページをWebFetchで取得したときに要約ツールが返した数字をそのまま使ったもので、実際に数えた値ではありませんでした。

初稿では、この数字のすぐ上の段落に、常駐実行の誤断定がありました。批評担当はその誤断定は捕まえましたが、すぐ下に続く「189本」という数字までは、検証の対象に入りませんでした。改稿2回目でも数字はそのまま残りました。

正しい値の251本が判明したのは、後日、自社実例を記録する台帳を作る過程で、sitemap.xmlを実際に取得して件数を数え直したときです。「確認した」という記述があっても、確認の手段そのものが甘ければ、独立ファクトチェックも批評も同じ数字を素通りさせます。

もう1つの漏れは、規約そのものです。字数・タイトル幅・H2内のキーワード配置を機械的に判定するスクリプトは、2026-07-28時点でまだ実装されていません。今回は批評担当が電卓で数え直して気づきましたが、この段を素通りしても機械検証は止まりません。

LLM同士で出力を評価させる手法には、位置バイアスや自己を甘く評価するバイアスが伴うという指摘があります（出典: LLM-as-judge論文）。批評担当も別のAIである以上、この限界と無縁ではありません。

だからこそ、「確認した」という記述には確認の手段まで書かせています。「本番URLを開いた」ではなく「sitemap.xmlを取得し、/articles/を含むURLの数を数えた」まで書きます。そこまで書けば、次の担当が確認の精度を再現できます。

06品質管理でつまずきやすい点｜自社でも起きた4つの誤り

1つ目は、1つの担当に役割を寄せすぎることです。②独立ファクトチェックと④批評を分けずに運用すると、④の注意が向いた箇所だけが厚く検査され、向かなかった箇所は素通りします。

2つ目は、「確認した」という記述を、確認の中身を見ずに信じることです。189という数字は「本番URLで確認した」という体裁を持っていたため、次の担当がそれ以上疑いませんでした。

3つ目は、規約を文章として書いた時点で満たしたと考えることです。字数やタイトル幅の上限は、機械的に判定するコードとして実装するまで、読み飛ばされても誰も止められません。

4つ目は、指摘を1回限りの修正で終わらせることです。15件の指摘を型に分類せず次の記事へ持ち越さなければ、同じ型の誤りが別の記事でまた起きます。品質ラインの成果は、直した記事の数ではなく、繰り返さなくなった誤りの型の数で測るべきです。

4つとも、担当や規約が「無い」から起きたのではありません。担当は5つとも決まっており、規約も数値で存在していました。抜けたのは、担当同士の境界と、規約とコードの間と、指摘を次へつなぐ経路でした。

07品質ラインを公開前に確認するチェックリスト

• 執筆担当と、原典照合を行う担当が別人格になっているか
• 原典照合の結果を、機械検証とは別の記録として残しているか
• 機械検証が実際に判定しているのは規約のうち何割か、書き出しているか
• 批評担当が、原典照合と機械検証の担当外まで肩代わりしていないか
• 「確認した」という記述について、確認の手段そのものを疑っているか
• 差し戻された指摘を型に分類し、次の記事の執筆前チェックへ反映しているか
• 規約の数値を、文章だけでなく判定コードとして実装する計画があるか

08FAQ