「AIに書かせた記事を、このまま出していいものか」。手を動かすほど、この問いは重くなります。
速く書けることは分かった。では、その速さのまま、間違いをどこで止めるのか。チェック項目を並べた表は作れても、それが本当に効いているかどうかは、差し戻された記録を見るまで分かりません。
この記事は、運営元WEBMARKSがAGI Journalの記事に通している公開前のラインを、そのまま開示します。執筆・独立ファクトチェック・機械検証・批評・修正の5段階です。うまくいった話だけを書くつもりはありません。実際に差し戻された15件の指摘と、5段のどこでも捕まらなかった数字の誤りまで出します。
こんなふうに調べていませんか
- AIに記事を書かせたが、そのまま公開してよいのか判断がつかない
- 社内でAI記事のチェック体制を作れと言われたが、何をどう分ければいいか分からない
- 「ファクトチェック済み」と報告は上がってくるが、何をどこまで見たのかが見えない
この記事を読み終えたときに手に入るもの
- 誤りの型ごとに、どの段が捕まえる担当なのかを線引きできるようになります
- 自社のチェック体制のどこに隙間があるかを、項目ごとに点検できるようになります
- 「確認した」という報告を、確認の手段まで含めて疑えるようになります
結論30秒でわかる、この記事の結論
- AI記事の品質管理は、書いた本人とは別の目を段に分けて置くことで担保します。
- 段ごとに捕まえられる誤りの型が違います。1つの段に寄せると、その担当の外が丸ごと素通りします。
- 弱いのは段の数ではなく、段と段の継ぎ目です。抜けるのはいつも同じ3か所でした。
進行役は3人です。若葉さん（Web担当2年目）が用語のそもそもを聞き、高梨課長が自分の手で回すときの段取りを聞き、鈴木さん（本誌監修）が答えます。
01AIエージェントに記事を書かせるとき、品質管理はどこから始めるんですか？
若葉さんAIが書いた記事って、そもそも何から見ればいいんでしょうか。誤字を探す、という話ではないですよね。
鈴木さんそこは順番があります。最初にやるのは、書いた本人以外の目を用意することです。項目を足すより先に、見る人を分けるほうが効きますよ。
結論を先に置きます。AI記事の品質管理は、チェック項目を増やすところからではなく、見る担当を分けるところから始めます。
同じ担当が2つの段を兼任すると、その担当の見落としが2回連続で素通りします。項目を10個に増やしても、見る目が1つなら、その目に映らないものは映らないままです。
WEBMARKSでは、公開前のラインを執筆・独立ファクトチェック・機械検証・批評・修正の5段階に分けています。全段を通過した記事だけがstatus: reviewedになります。
Claudeの公式ガイドは、引用元となる文を直接引かせ、裏づけが見つからない主張は取り下げさせる方法を、ハルシネーション対策として挙げています（出典: Anthropic公式）。独立ファクトチェックは、この裏づけ探しを記事1本ごとにやり直す工程です。
検索エンジンの品質ガイドラインも、AI生成を含む自動化の使用を読者に分かるようにしているかを、自己点検の項目に挙げています（出典: Google公式）。制作体制を記事として開示するのは、この点検に対する自社の回答でもあります。
この章のまとめ
品質管理の入口は、見る目を増やすことではなく、見る目を分けることです。
02AI記事の品質管理で、ファクトチェックはAI社員の誰が担当するんですか？
5段階は、担当を分けて初めて機能します。誰が何を見るのかを、実装できている範囲まで含めて開示します。
| 段階 | 担当 | 何を見るか | 2026-07-28時点の実装状況 |
|---|---|---|---|
| ①執筆 | 執筆担当のAI | 規約に沿って初稿を作る | 実装済み |
| ②独立ファクトチェック | 執筆担当とは別のAI | primary_sourcesの原典と、本文の実測記述の突合 | 独立工程としては未分離。④へ統合実施 |
| ③機械検証 | build.pyとqa配下のスクリプト | リンク切れ・frontmatter必須項目・図解プレースホルダ数など | 一部実装済み。字数・タイトル幅・H2内キーワード被覆は未実装 |
| ④批評 | 別人格の批評役AI | 規約逸脱・出典の正確性・情報の薄さを横断的に見る | 実装済み |
| ⑤修正 | 執筆担当のAI | 指摘を1件ずつ潰す | 実装済み |
Claude Codeのサブエージェントは、役割ごとに独立した文脈で作業し、要約だけを親へ返す設計です（出典: Claude Code公式）。②から④の分業は、この考え方を記事の審査へ当てはめたものです。
表の実装状況が示すとおり、②は独立した工程になっていません。実務では④の批評担当が、原典照合と横断チェックをまとめて1回で行っています。
「5段階」は、公開前の審査だけを切り出した数え方です。記事の構成を決める工程や、公開可否を最終判断する監修は、この5段階の前後にあります。数え方が違っても、②から④が果たす役割は変わりません。
この章のまとめ
担当表は、実装できている範囲まで書いて初めて使えます。未分離の段は、肩代わりしている担当を明記します。
03生成AIが書いた記事の誤りを、品質管理のどの段が実際に捕まえたんですか？
高梨課長表のとおりに割り当てれば、そのとおりに捕まるものなんでしょうか。実際どうだったのかを知りたいです。
鈴木さんそこは正直に出します。設計と実際は、うちでもずれていました。7つの型のうち、想定どおりの段が捕まえたのは2つだけでした。
誤りの型ごとに担当を決めても、実際にどの段が捕まえたかは設計と一致するとは限りません。パイロット記事（AGIM-701初稿）で起きたことを、型ごとに並べます。
| 誤りの型 | 本来の担当段階 | 実際に捕まえた段階 | 実例（AGIM-701初稿） |
|---|---|---|---|
| 自社実績の誤断定 | 独立ファクトチェック | 批評（launchctlを実行して確認） | 稼働していない常駐処理を「動いている」と現在形で記述 |
| 公式仕様の誤読 | 独立ファクトチェック | 批評（公式ドキュメントを再照合） | フックの判定を実在しない自律度の段階として説明 |
| 社内規約からの逸脱 | 機械検証 | 批評（字数と図解点数を数え直す） | 字数上限・図解点数・タイトル幅の超過 |
| 参照整合性エラー | 機械検証 | 機械検証（想定どおり） | 存在しない記事への参照8件がすべてリンク切れ |
| 情報密度不足 | 批評 | 批評（想定どおり） | 動作原理の説明が本文にも図解にも無い |
| 架空の出典 | 独立ファクトチェック | 批評（社内文書を全文検索） | 存在しない社内文書を根拠として引用 |
| 数字の未検証な継承 | どの段にも割り当てがない | どの段でも捕まらず、後日の台帳整備で発覚 | ある数字が改稿2回を通過し残り続けた |
7つの型のうち5つは、本来②か③が担当のはずの誤りを、④の批評が肩代わりして捕まえています。想定どおり本来の段が捕まえたのは2つだけでした。
②を独立工程として分離していない現状では、④が拾い損ねると誰も拾いません。肩代わりが起きること自体は悪ではありません。危ないのは、肩代わりに気づかないまま「段は5つある」と説明してしまうことです。
この章のまとめ
設計上の担当と、実際に捕まえた担当を並べて書きます。そのずれの大きさが、体制の弱点そのものです。
04AIエージェントが差し戻した15件のうち、重大4件はどこが危なかったんですか？
批評ログを実測すると、この初稿は15件の指摘でREJECTと判定されました。内訳は重大4件・重要6件・中4件・軽微1件です（2026-07-28に批評ログを直接確認）。
重大と判定された4件は、いずれも公開後に読者から指摘されうる種類の誤りでした。
1つ目は、稼働実績の誤断定です。常駐実行の処理を現在形で「動いている」と書いた箇所を、批評担当がlaunchctl list | grep com.webmarksで実測しました。実際にロードされていた自社ジョブは1本だけで、記述した処理は稼働していませんでした。
2つ目は、公式仕様の誤読です。フックの判定について、全面停止と全面自動化の中間に4段階の自律度がある、という趣旨の説明をしていました。原典を当たり直すと、判定はallow（許可）・deny（拒否）・ask（確認）の3つで返す設計でした。自律度の段階という説明そのものが誤りでした。
3つ目は、社内規約からの無申告の逸脱です。当時の規約は字数上限・図解点数・タイトル幅を数値で定めていましたが、初稿はいずれも上限を超えていました。破ったこと自体より、破った事実を記録せずに超えていたことが問題でした。
4つ目は、参照整合性のエラーです。本文中で他記事8本を名指ししていましたが、8本とも執筆前で存在しませんでした。機械検証のスクリプトを実行すると、8件ともリンク先が存在しないと判定されました。
4件に共通するのは、書いた本人には見えていなかった点です。稼働実績と公式仕様は原典に当たらないと分からず、規約からの逸脱は数え直さないと分からず、リンク切れは記憶ではなく機械的な突合でしか分かりません。
この章のまとめ
重大な誤りは、書き手の注意力ではなく、書き手が持っていない道具でしか見つかりません。
05AI社員の批評ログには、品質管理の指摘がどんな形で残るんですか？
高梨課長指摘は、どんな形で残しているんですか。伝えて終わりでは、次に活きない気がします。
鈴木さん1件ずつ、決まった項目で残します。うちは4項目です。何が問題かだけでなく、どう直すかまで書かせるところが肝ですね。
批評ログは、指摘1件をseverity（重大度）・where（該当箇所）・problem（何が問題か）・fix（どう直すか）の4項目で記録しています。さきほどの稼働実績の誤断定は、実際には次の形で残っています。
{
"severity": "重大",
"where": "H2-3「具体例」本文（常駐実行の段落）",
"problem": "現在形で稼働を断定しているが、launchctlの実測と一致しない",
"fix": "3層の実例を公開前にすべて実測し、動いていなければ時制を過去形にするか状態を明記する"
}whereに該当箇所が入っているので、書いた本人でなくても同じ場所を開けます。fixがあるので、指摘を消しただけなのか、書き方そのものを変えたのかが後から分かります。
実際の修正はこうなりました。動いていない処理の時制は、過去形に変えました。フックの判定はallow・deny・askの3値として、そのまま書き直しました。規約の上限は、特例を追加したうえで超過した事実を明記しました。存在しない8本の参照は、いったん本文から外しました。
この章のまとめ
指摘は、該当箇所と直し方まで含めて1件と数えます。項目が決まっていれば、担当が替わっても同じ読み返し方ができます。
06AI記事の品質管理もファクトチェックもすり抜けた数字を、AIエージェントはなぜ見逃したんですか？
高梨課長15件も出たのなら、もう漏れは無さそうに思えます。実際はどうだったんでしょう。
鈴木さん1つだけ、改稿を2回通過して最終稿の直前まで残った数字があります。しかもその数字は、確認済みという体裁を持っていました。
姉妹メディアの公開本数という数字です。最初の記録では、案件管理台帳の古い表記だけを根拠に、1本も公開されていないと報告していました。これに気づいた人が本番URLを開き、189本へ訂正しました。
一見、正しい訂正に見えます。しかし189という数字は、本番ページを取得したときに要約ツールが返した数字をそのまま使ったもので、実際に数えた値ではありませんでした。
初稿では、この数字のすぐ上の段落に、常駐実行の誤断定がありました。批評担当はその誤断定を捕まえましたが、すぐ下に続く189本という数字までは、検証の対象に入りませんでした。改稿2回目でも、数字はそのまま残りました。
正しい値の251本が判明したのは、後日、自社実例を記録する台帳を作る過程で、sitemap.xmlを実際に取得して件数を数え直したときです。
ここで効いているのは、注意力の差ではありません。訂正が入った直後の数字は、もう検証済みだと見なされて、次の担当が触らなくなります。「確認した」という記述があっても、確認の手段そのものが甘ければ、独立ファクトチェックも批評も同じ数字を素通りさせます。
この章のまとめ
訂正された数字は、訂正されたという事実だけで信用されます。訂正の手段まで書かれていなければ、まだ検証されていません。
07AI導入の現場で、同じ誤りを繰り返さない品質管理はどう作るんですか？
もう1つの漏れは、規約そのものでした。字数・タイトル幅・H2内のキーワード配置を機械的に判定するスクリプトは、2026-07-28時点でまだ実装されていません。今回は批評担当が数え直して気づきましたが、この段を素通りしても機械検証は止まりません。
規約は、書かれた時点では効きません。数値まで決めて、判定するコードになって、初めてその場で止まります。文章のままの規約とは、読み飛ばされたときに誰も止められない状態のことです。
もう1つは、指摘を1回限りの修正で終わらせないことです。15件の指摘を型に分類して次の記事へ持ち越さなければ、同じ型の誤りが別の記事でまた起きます。
だから品質ラインの成果は、直した記事の数ではなく、繰り返さなくなった誤りの型の数で測るべきだと考えています。
この章のまとめ
繰り返しを止めるのは、指摘の数ではなく、指摘を型に変えて次へ渡す経路です。
08AI活用のチームが小さくても、ファクトチェックの担当は分けられますか？
高梨課長うちは私を入れて数人です。5段も担当を置けません。それでも真似できるものでしょうか。
鈴木さん段の数から入らないほうがいいですよ。まず、書く担当と原典を開く担当を分けるところだけ試してください。別セッションでも、人でも構いません。
役割を分けるところからなら始められます。執筆と原典照合を別の担当にするだけで、この記事で挙げた漏れの一部は防げます。
ここでいう別の担当は、別の人である必要はありません。同じ人でも、書くときと検証するときでセッションを分け、検証側には初稿と一次資料だけを渡す。それだけで、書いた文脈に引きずられる度合いは下がります。
つまずきやすいのは、1つの担当に役割を寄せすぎることです。独立ファクトチェックと批評を分けずに運用すると、批評担当の注意が向いた箇所だけが厚く検査され、向かなかった箇所は素通りします。
もう1つは、「確認した」という記述を、中身を見ずに信じることです。体裁は、検証の中身とは無関係に整います。
この章のまとめ
小さなチームでも、書く担当と原典を開く担当を分けるところから始められます。
09エージェントの判定に頼りきらないために、品質管理では何を残すんですか？
LLM同士で出力を評価させる手法には、位置バイアスや、自己を甘く評価するバイアスが伴うという指摘があります（出典: LLM-as-judge論文）。批評担当も別のAIである以上、この限界と無縁ではありません。
だからこそ、「確認した」という記述には、確認の手段まで書かせています。「本番URLを開いた」ではなく「sitemap.xmlを取得し、/articles/を含むURLの数を数えた」まで書きます。そこまで書けば、次の担当が確認の精度を再現できます。
残すのは、判定の結果ではありません。判定に使った手段です。手段が残っていれば、判定した相手がAIでも人でも、後から精度を測り直せます。逆に手段が書かれていなければ、合格という記録だけが積み上がります。
この章のまとめ
残すのは結論ではなく、確認の手段です。手段が書かれていない確認は、まだ確認されていません。
10AI社員に記事を任せる前に、品質管理のどこを確認しておけばいいんですか？
ここまでの内容を、自社の体制へ当てはめる項目にまとめます。「いいえ」が1つでもあれば、記事を任せる前に、そこを埋めるほうが先です。
- 執筆担当と、原典照合を行う担当が別人格になっているか
- 原典照合の結果を、機械検証とは別の記録として残しているか
- 機械検証が実際に判定しているのは規約のうちどこまでか、書き出しているか
- 批評担当が、原典照合と機械検証の担当外まで肩代わりしていないか
- 「確認した」という記述について、確認の手段そのものを疑っているか
- 差し戻された指摘を型に分類し、次の記事の執筆前チェックへ反映しているか
- 規約の数値を、文章だけでなく判定コードとして実装する計画があるか
最初に効くのは1つ目です。担当が分かれていないと、残りの項目はすべて同じ目で見ることになります。
冒頭に挙げた3つの継ぎ目も、この項目のどこかに対応しています。担当と担当のあいだ、規約と判定コードのあいだ、指摘と次の記事のあいだ。抜けるのは、担当や規約が無いところではなく、その境目でした。
この章のまとめ
点検するのは、体制の有無ではなく継ぎ目の有無です。担当・規約・記録の3か所が、いつも同じ場所で抜けます。
11よくある質問
独立ファクトチェックと批評は、同じAIが兼任してもいいですか
兼任は避けたほうが安全です。同じ視点で2回見ても、最初に見落とした箇所は2回目も見落とす確率が高いままです。この記事で示したとおり、兼任している段では、批評担当の注意が向いた箇所だけが厚く検査されました。どうしても分けられないときは、検証側へ渡す材料を初稿と一次資料だけに絞ってください。
AI記事の品質管理を全部自動にすれば、人の確認は要らなくなりますか
いいえ。WEBMARKSでも、公開の可否は最終的に人が判断します。5段階は公開前の下ごしらえであって、公開の決定そのものは別の工程です。自動化できるのは、判定基準が言葉で書ける範囲までです。この記事の数字の誤りのように、「確認した」という報告の中身を疑うかどうかは、いまのところ人が決める場所に残っています。
機械検証が整えば、批評は要らなくなりますか
なりません。機械検証が判定できるのは、数値化できるルールだけです。稼働実績の誤断定や公式仕様の誤読のような事実の正しさは、原典に当たる工程がないと拾えません。字数やタイトル幅がすべて通っても、中身の薄い記事はそのまま素通りします。逆に、参照先が実在するかどうかは記憶では判定できないので、批評だけでも足りません。
小さなチームでも5段階の品質ラインは真似できますか
役割を分けるところから始められます。執筆と原典照合を別の担当にするだけで、この記事で示した漏れの一部は防げます。別の担当は別の人でなくてもよく、同じ人がセッションを分けるだけでも効果はあります。まず2つに分け、そこで拾えなかった誤りの型が出てから、次の段を足す順番をおすすめします。
差し戻された指摘は、後の記事にどう活かしていますか
指摘を誤りの型に分類し、次の記事の提出前チェックリストへ反映しています。稼働実績の誤断定・公式仕様の誤読・参照整合性のような型は、以後の執筆時に自分で確認する項目として引き継がれます。分類しないまま個別に直すと、同じ型が別の記事でまた出ます。この記事の項目リストも、そうやって差し戻しの記録から起こしたものです。
12まとめ｜今日やる3つのこと
弱いのは段の数ではなく、段と段の継ぎ目でした。担当のあいだ、規約と判定コードのあいだ、指摘と次の記事のあいだ。この3か所を、今日この順で埋めてください。
今日この順で手をつけます
書く担当と、原典を開く担当を分ける
見る目が1つのままでは、項目を増やしても同じ場所が抜けます
「確認した」の横に、確認の手段を書かせる
手段が残っていれば、次の担当が精度を測り直せます
規約の数値を判定コードにする予定日を決める
文章のままの規約は、読み飛ばされたときに止まりません
AI検索では、こう聞かれています
AIが書いた記事は、公開前にどこまでチェックすればいいんですか？
「AIエージェントに記事を書かせるとき、品質管理はどこから始めるんですか？」の章で説明しています
AI記事のファクトチェックは、誰が担当すればいいんですか？
「AI記事の品質管理で、ファクトチェックはAI社員の誰が担当するんですか？」の章に担当表があります
AIのチェックをすり抜ける誤りには、どんなものがありますか？
「AI記事の品質管理もファクトチェックもすり抜けた数字を、AIエージェントはなぜ見逃したんですか？」の章で扱っています
小さなチームでも同じ体制は作れますか？
「AI活用のチームが小さくても、ファクトチェックの担当は分けられますか？」の章で答えています
次に読むなら、この記事です
