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