01結論：AI併用記事の品質ゲートは「本数」でなく「差し戻し理由の可視化」で設計する
AI併用記事の品質ゲートは、AIが書いたかどうかを判定する仕組みではありません。差し戻す理由を明文化し、機械で検出できる形に落とし込む設計です。品質ゲートは、『AIで記事を作る工程設計｜構成から入稿までの分業表』が示す入稿ゲート工程を、具体的に掘り下げたものです。
2026年5月15日、Googleはスパムポリシーの前文を改訂し、生成AIの回答の操作も対象にしました（出典: Search Engine Land）。大量生成されたコンテンツの不正使用とは、ランキング操作を主目的に大量ページを作ることです（出典: Google Search Central・2026-05-18更新）。
ボリュームと価値の欠如が同時に成立したときに違反になりうるとも説明しています（出典: Google Search Central・2025-12-31更新）。本誌の品質ゲートも、本数ではなく価値の欠如を検出する設計にしています。
Google公式のAI検索最適化ガイドも、生成AIで簡単に作れる内容の量産を避けるよう求めています（出典: Google Search Central・2026-07-14更新）。検証環境は、これらのGoogle Search Central公式ドキュメントとSearch Engine Landの記事を2026-08-08に確認しています。本誌のQAスクリプト群の挙動も同日にあわせて確認しています。
この記事で分かることは次の3点です。
- 本誌の品質ゲートが何段で構成されているか
- 品質ゲートが実際に何件、何を差し戻したか
- 品質ゲート自身の検査ロジックが誤っていた実例
02AI併用記事の品質ゲートは何段で構成されているか
本誌の品質ゲートは、独立した7本のスクリプトと、人による2段階のレビューで構成されています（自社実測・2026-08-08確認）。
| スクリプト | 検査内容 |
|---|---|
| check_sources.py | 数値主張に出典が対応しているかを検査する |
| check_density.py | 型別の字数下限・要素数下限・KW充足率を検査する |
| verify_diagrams.py | 図解SVGのフォントサイズ・要素数を検査する |
| check_internal_refs.py | 記事間参照の死にリンクを検査する |
| verify_quote_rendering.py | 引用ブロックが正しく描画されているかを検査する |
| verify_prepublish.py | 禁止表現・効果の断定・未実測の自社数値を検査する |
| verify_site.py | サイト全体のリンク・画像参照の整合性を検査する |
品質ラインは、次の5段階で進みます。
- 執筆：型のテンプレートに沿って下書きを作る
- 独立ファクトチェック：執筆者とは別人格が一次情報と原典照合する
- 機械検証：7本のスクリプトがエラー0件になるまで差し戻す
- 批評：悪魔の代弁者が甘さを具体指示つきで指摘する
- reviewed判定：全段通過を編集部が確認する
どの段階で問題が残っても、次の段階が止める設計です。1人がすべてを確認する体制では、確認したつもりの箇所が誰の担当でもなくなります。
7本のスクリプトを1本にまとめない理由もここにあります。1本の巨大なスクリプトにすると、どの条文がどの検査に対応しているかが読み手に分かりにくくなります。条文と検査を1対1で対応させておけば、規約を改定したときに直すべきスクリプトも1つに絞れます。
03品質ゲートは実際に何を、何件差し戻したか
check_density.pyを2026-08-08に本誌50記事へ実行したところ、3本が例外なくFAILしました（自社実測）。原因は記事側ではなく、規約の型別下限とピラー特例の組み合わせが矛盾していたことでした。
規約側を是正した結果、記事本文には触れていないのに新たな差し戻し対象が2本見つかりました。矛盾する条文の陰に隠れていた、本物の違反です。あわせて、意味を持たない警告は18本から0件へ減りました。
66記事まで書けた時点で、要素数の下限も実測に基づき再校正しました。B型記事42本の実測分布から、「具体的な数値」の下限を6件から4件へ調整しています（自社実測・2026-08-08）。この再校正で、差し戻し件数は111件から87件へ、対象記事は43本から30本へ減りました。
この再校正の考え方は「全記事が通る値まで下げる」ではありません。分布の自然な区切りを見て、明らかに具体性を欠く記事だけが落ちる水準を選びます。B型42本の実測は、値が連続的に増える分布で明確な谷が無かったため、下位25%点を新しい下限にしました。
04検査ロジックのどこが誤っていたか｜品質ゲート自身の3つの実例
品質ゲートを設計していると、検査そのものが誤っていることに気づく場面があります。本誌で実際に起きた3つの実例です。
規約自身の自己矛盾は、型Bの下限とピラー特例の上限が同時に成立し、下限が上限を上回っていました。3本の記事がどう書いても合格できない状態でした（自社実測・2026-08-08確認）。
KW重複検査の誤検知も見つかりました。13件の重複うち11件が誤検知で、真の重複は1件でした（自社実測・2026-08-08是正）。「AI」「SEO」のような全記事に共通する語を主語として抽出していたことが原因でした。
公開前検査の404誤判定もありました。実在するGoogleサポートのURLを、検査スクリプトが誤って「リンク切れ」と判定していました。ブラウザのネットワークログでGET 200 OKを確認し、検査側の誤りだと特定しています（自社実測・2026-08-08確認）。
3つの実例に共通するのは、検査を書いた直後は正しく見えても、対象が増えるほど想定していなかったパターンに当たるということです。KW重複検査は13件という少数の実行結果を人が1件ずつ中身まで確認したからこそ、11件が誤検知だと分かりました。検査の出力を件数だけで見て終わらせていたら、この誤りには気づけませんでした。
| 実例 | 誤りの中身 | 是正内容 |
|---|---|---|
| 規約の自己矛盾 | 型Bの下限と特例の上限が同時に成立し、下限が上限を上回る | ピラー特例に専用の下限を新設 |
| KW重複の誤検知 | 一般語を主語として抽出し、無関係な記事同士を衝突判定 | 主語の抽出元を執筆者が確定する語へ変更 |
| 404の誤判定 | 実在するURLを検査スクリプトがリンク切れと誤判定 | ブラウザでの実測確認を検査手順に追加 |
05ブリーフや報告の誤りを品質ゲートより先に人が捕捉した実例
機械検証だけでは捕まえられない誤りもあります。本誌のディレクターブリーフでは、Meta発表の数値を「CTR+3.5%」と伝えていました。しかし一次ソース原文の表現はクリック数の増加であり、クリック率ではありませんでした（自社実測・2026-08-08確認）。この差異は、原典を直接確認した執筆担当が発見しました。
同じ記事IDに複数の担当が同時着手し、二重投入が起きたこともあります。後発の担当が既存ファイルの存在に気づき、上書きせず既存ドラフトを監査するにとどめました。被害はゼロでした。以後、バッチで記事IDを割り当てる際は担当の重複を避ける運用にしています。
一次情報の取得方法そのものが誤りを生んだ例もあります。WebFetchでは本文が取得できず「公式には記載がない」と誤判断していた箇所を、ブラウザで実ページを開いたところ本文冒頭に明記されていました。取得方法の限界を「事実が無い」と誤解しないための教訓です。
これら3つの実例は、いずれも品質ゲートの機械検証より前か、機械検証と並行して人が気づいたものです。機械は「検査対象になっている項目」しか判定できません。ブリーフの数値の取り違えや取得方法の限界は、そもそも検査項目として設計されていない範囲でした。
06品質ゲートの判定そのものを疑う運用ルール
品質ゲートは、記事だけでなく自分自身も疑われる対象に含めています。姉妹誌AGI Journalでは、実在しない条番号「§11.3.4 S5」が指摘の根拠に使われたことがありました。同誌は§10までしかなく、grepの結果は0件でした（自社実測・2026-08-08確認、記事フォーマット標準.md §0参照）。
本誌はこの教訓から、条番号を根拠に指摘する場合は実在確認をしてから書くという規律を明文化しています。実在しない条番号を根拠にした指摘は、反映担当が確認したうえで却下します。
品質ゲートを疑う姿勢は、検査を通した記事についても同じです。悪魔の代弁者による批評は、機械検証を通過した記事にも甘さが残っていないかを問い直します。機械検証は正しさの一部を担保するだけで、それ以上の水準は別の観点で確認します。
条番号の実在確認という規律を、規約書自体にも明文化しているのは意味があります。指摘の中身が正しくても、存在しない条番号を根拠にするのは誤りです。反映担当は、条番号が実在するかを機械的に確認してから、指摘の中身を検討する順序を守ります。
07自社で品質ゲートを設計するときつまずきやすい点
- 検査項目を規約に書いた時点で満足し、機械化を後回しにしてしまう。書いたのに検査されない条文は守られているか誰にも分からない
- 検査項目の判定基準を主観的な分類に頼ってしまう。「独自性がある」のような曖昧な条件は機械化できず、誤検知の温床になる
- 検査が出したFAILを鵜呑みにし、検査ロジック自体を疑わない。本誌でも3種類の誤りが検査側にあった
- 閾値を決め打ちしたまま、実測に基づく再校正をしない。後で再校正すると予告した値ほど期限が来ても放置されやすい
- 「訂正済み」という報告を鵜呑みにする。本誌では報告と実ファイルの状態が食い違っていた例をgit履歴の突合で見つけている
- 誤検知の件数を集計せず、ノイズの多い検査を放置する。ノイズが多いと本物の警告が読まれなくなる
- 機械検証だけで公開判断を完結させる。本誌は機械検証のあとに人による批評の工程を挟んでいる
08品質ゲート設計のチェックリスト
- 検査項目は規約の条文と1対1で対応しているか確認したか
- 機械検証をすり抜けた実例をログとして残しているか
- 検査ロジック自体を疑い、誤検知を人が確認する工程を持っているか
- 閾値は実測分布に基づいて再校正しているか
- 「訂正済み」等の報告を、実ファイルの状態と突合してから信じているか
- 執筆担当とファクトチェック担当を分けているか
- 機械検証を通過した記事にも、甘さを問い直す工程があるか
- 条番号を根拠にする指摘は、実在確認をしてから書いているか
- 検査ロジックの改定履歴を残し、なぜ変えたかを後から追えるようにしているか
09FAQ
品質ゲートは何本のスクリプトで構成されていますか
7本のスクリプトと、独立ファクトチェック・批評という人による2段階のレビューで構成されています（自社実測・2026-08-08確認）。どの段階で問題が残っても、次の段階が止める設計です。
AI併用記事の品質ゲートで最も差し戻しが多いのはどこですか
本誌の実測では、字数の型別下限割れと、具体的な数値の要素数下限割れが多い傾向にあります。規約自身の自己矛盾で例外なくFAILした期間もありました。書き手の力量よりも、規約と検査の整合が原因になることも珍しくありません。
品質ゲートの検査ロジック自体が誤っていることはありますか
あります。本誌では規約の自己矛盾・KW重複の誤検知・公開前検査の404誤判定という3種類の誤りが見つかっています。検査側を疑う姿勢が必要です。
機械検証を通過すれば公開してよいですか
いいえ。機械検証のあとに、悪魔の代弁者による批評という人の工程が入ります。機械は正しさの一部しか担保しません。
品質ゲートの閾値はどう決めればよいですか
暫定値から始め、実測が一定数たまった時点で分布に基づき再校正します。本誌はB型記事42本の実測から、下限の1項目を再校正しています。再校正すると自ら予告した値は、期限が来たら実際に見直すところまでを運用に含めます。
品質ゲートはAIが書いた記事だけに必要ですか
いいえ。本誌の品質ゲートは、価値を付加しているかどうかを見る設計です。作成方法がAIか人かは、検査項目そのものには含めていません。人だけで書いた記事でも、出典の欠落や字数不足があれば同じ基準で差し戻します。
品質ゲートを設計する際、最初に着手すべき項目はどれですか
規約の条文と検査項目を1対1で対応させる表を作ることです。本誌でも「条文にはあるが検査されていない項目」が後から見つかっており、対応表が無いと同じ抜けが起きます。
