コンテンツ制作 効率化 完全ガイド 2026年版 — 量産パイプライン設計

「コンテンツ制作 効率化」と検索する人の本音は、たいてい「人手は増やせない、でも検索流入は伸ばしたい」です。月10本でも息切れする体制で、競合は月100本を出している。AI を使えば速くなると聞くが、雑に流すとE-E-A-Tが崩れて順位が落ちる、という板挟みです。実際 Google は2024年3月のコアアップデート以降、「scaled content abuse（量産で価値を提供しないコンテンツ）」を明示的にスパムポリシーへ追加しており、人間と AI のどちらが書いたかではなくページが読者に役立っているかで評価する姿勢を変えていません。本ガイドは、その制約の中で月数十本〜百本規模のコンテンツを安全に回すための、トピッククラスター設計・pSEOの組み立て・AI執筆の分業・編集ゲート・出典監査・内部リンク自動化を、量産パイプラインの教科書として現場視点で整理しました。

※ 出典: Google Search Central「March 2024 core update and new spam policies」（取得 2026-05）

Chapter 1: 量と質を両立する設計思想 — pSEO の現実と限界

「AIで量産」は失敗の最短ルート

「とにかく AI に書かせれば月100本いける」と社内で語られている会社の多くは、半年後に検索流入が落ちます。Google が2024年3月コアアップデート以降にスパムポリシーへ追加した3項目は、スケールド・コンテンツ・アビューズ／サイト評判の不正利用／期限切れドメインの不正利用で、特に1つ目は「人間が書いたか AI が書いたかは問わず、量産されただけで読者に価値を提供しないコンテンツ」と明確に定義されています。

※ 出典: Google Search Central「March 2024 core update and new spam policies」（取得 2026-05）

うちの観測でも、テンプレに数字を差し替えただけのページや、出典なき断定数字を並べたページは、公開後3〜6ヶ月で順位が剥がれていきます（※ Tufe Company 内部観察 / 2026-05時点）。逆に読者が次の一歩を決められる材料（チェックリスト・テンプレ・公式リソース・失敗パターン）を含むページは、AI で下書きを作っても残っています。

Google の言う「helpful content」を分解する

Google Search Central の「Helpful Content」ガイダンスは、量産そのものを否定していません。問われているのは (1) 一次経験の有無、(2) 専門性の根拠、(3) 検索意図への合致、(4) 読み終わった後の満足度 の4点です。AI 執筆を導入するときも、この4点で品質ゲートを設ければ量と質は両立できます。

※ 出典: Google Search Central「Creating helpful, reliable, people-first content」（取得 2026-05）

pSEO の本来の意味

pSEO（プログラマティックSEO）は本来「テンプレートと構造化データを組み合わせ、検索需要のあるロングテール KW を網羅的にカバーする」手法です。Airbnb・Tripadvisor・Zapier・Wise などが代表例で、Backlinko のロングテール調査では、全クエリの約94.74%が月間検索数10回以下のロングテールであり、ここに刺すのが pSEO の本懐です。

※ 出典: Backlinko「We Analyzed 4 Billion Keywords. Here's What We Learned About Google Searches」（取得 2026-05）

つまり pSEO は「同じテンプレで100ページ作れば100倍刺さる」ものではなく、「ユーザーが本当に検索しているロングテール意図に、テンプレで応える設計」です。意図のない自動生成は scaled content abuse の方に振れます。

量産が崩れる典型的な3つの分岐点

1. テンプレに具体差分がない — 杉並と練馬で何が違うのか書かれていないエリアページ
2. 数字に出典が無い — 「Map Pack の CTR は2〜3割」のような俗説の孫引き（実証は約 17.6%、※ 出典: Backlinko「Google Local Pack & Maps Click-Through Rate」（取得 2026-05））
3. 内部リンク網が育っていない — 100本生成しても孤立島になり、評価が集まらない

このガイドは、この3つの分岐点それぞれに対する対処法を Chapter 2 以降で具体化しました。

Chapter 2: トピッククラスター設計 — pillar guide + cluster pages

Pillar Page と Cluster の役割分担

トピッククラスターは HubSpot が2017年に体系化した概念で、pillar page（柱）が広い概念を網羅し、cluster page（衛星）が個別の詳細を扱い、両者を内部リンクで強固に結ぶ設計です。Google が文脈理解を強める中で、単発記事より相互リンクされた一群のページのほうが評価されやすくなっています。

※ 出典: HubSpot Blog「Topic Clusters: The Next Evolution of SEO」（取得 2026-05）

用語整理

クラスター設計の標準手順

1. Pillar 候補の選定 — メインキーワードの月間検索ボリュームが概ね1,000以上、CPC が高い、上位サイトが pillar 型である、の3条件で絞る
2. Cluster の洗い出し — Ahrefs / Semrush の Keyword Explorer で関連 KW を300〜1,000個取得し、検索意図でグルーピング
3. クラスター・サイロの設計 — 1 pillar + 20〜50 cluster が目安。クラスター内で重複意図のページが2本以上あればマージ
4. 内部リンク網の設計 — 各 cluster は必ず pillar に戻るリンクを持ち、関連 cluster 同士も最低2本リンク
5. URL 設計 — pillar は /guides/{topic}-complete-2026、cluster は /glossary/{slug}・/compare/{slug}・/industries/{slug} のような階層分離

Tufe のクラスター実例

うちの場合、たとえば「LLMO」というテーマでは、pillar として LLMO/GEO 完全ガイド を中心に置き、cluster として LLMO・GEO・LLM 引用率・llms.txt・ChatGPT Search・Tufe vs Answer.io・手動 vs AI生成 llms.txt を相互リンクしています。pillar が変動軸（年次アップデート）、cluster が安定軸（用語定義・比較）という役割分担で、新しい話題は cluster で先に書き、pillar に取り込むタイミングを月次でレビューしています（※ Tufe Company 内部運用 / 2026-05時点）。

クラスター設計シート（テンプレ）

実務で使えるよう、最低限のスプレッドシート列構成を共有します。

このシートを月次で見れば、「pillar に取り込み忘れている cluster」「cluster から pillar への戻り線が無い孤立ページ」が一目でわかります。

Chapter 3: pSEO の実装 — テンプレ + データソース + 自動生成

pSEO の最小構成は「テンプレ × データ × 検証ゲート」

pSEO が機能するのは、(1) ユーザー検索意図に合致したテンプレが存在し、(2) ページごとに具体差分を埋められる構造化データソースがあり、(3) 公開前に品質を担保する検証ゲートが回っているとき、の3要素が揃っている場合です。1つでも欠けると scaled content abuse 側に振れます。

テンプレ設計の3条件

1. ユーザーが選ぶ「軸」が固有差分を作る — 「エリア × サービス」「業種 × サービス」「比較」「用語定義」など、軸ごとに本当に検索意図が分かれているかを確認
2. 共通骨格 + 固有差分 — 共通骨格と固有差分（地域固有の規制・業種固有の数値・比較先固有の特徴）は概ね半々が目安。固有差分が薄いテンプレは scaled content の疑いが濃い（※ Tufe Company 社内基準 / 2026-05時点）
3. テンプレ自身に出典枠を組み込む — 数字スロットの隣に「出典脚注」スロットを必ず設計し、空欄で公開できないバリデーションを通す

データソースの調達ルート

自動生成のワークフロー

# pseo-queue.yaml（生成キューの例）
- type: areas
  area_slug: suginami
  service_slug: meo
  pillar: /guides/meo-complete-2026
  data_sources:
    - https://www.city.suginami.tokyo.jp/...  # 自治体統計
    - https://www.e-stat.go.jp/...            # 国勢調査
  cluster_links:
    - /industries/dental-clinic-meo
    - /glossary/map-pack
  status: planned

このキューを writer エージェント → reviewer エージェント → auditor エージェント に流すだけで、人手は「最終 OK ボタンを押す」役割に集約できます。Tufe では writer に渡す前に「pillar への戻り線」「cluster 間リンク」「データソースの実在確認」を done として記録し、空欄では writer が起動しない設計にしています。

量より「公開可否ゲート」の運用

pSEO の本当の難所は「生成する力」ではなく「公開させない力」です。Tufe では audit_numbers.sh --file=<path> を pSEO 生成時の事前審査ゲートとして使い、出典のない具体数値が1つでも残っているとファイルが公開キューに進めない仕組みにしています。詳細は Chapter 6 で。

Chapter 4: AI執筆の役割分担 — 人間が書く部分・AIに任せる部分

Google 公式は「人間 vs AI」ではなく「人 first」

Google Search Central の AI 生成コンテンツに関するガイダンスは、**「AI を使ったかどうかではなく、ページが読者ファーストで作られているかを評価する」**と明言しています。AI で下書きしても、読者にとって価値があれば問題視されません。逆に人間が書いても、量産で価値が薄ければ scaled content abuse 扱いになり得ます。

※ 出典: Google Search Central「Google Search's guidance about AI-generated content」（取得 2026-05）

AI に任せていい部分・人間が握るべき部分

ハルシネーション対策

LLM のハルシネーション（事実誤認）は、特に数値・固有名詞・URL で発生します。OpenAI の公式評価でも GPT-4 系の数値質問における正答率は人間より顕著に低い領域があるとされ、「AI が出した数字をそのまま信じない」が大原則です。

うちでは writer エージェントに以下の3つを必ずやらせています。

1. 具体数値を書いたら、その場で WebFetch で一次出典 URL を取得する
2. URL の HTTP ステータスが 200 でない場合は、出典なしと判定して数値を削除し定性表現に置き換える
3. 固有名詞（会社名・サービス名）は公式サイトの会社概要 URL でクロスチェックする

これだけで誤帰属・誤会社名・404 URL の混入はうちの観測では大幅に減ります（※ Tufe Company 内部観察 / 2026-05時点）。

モデル選定の現実

「AI執筆で10倍速」のような派手な数字は、書き手・テーマ・品質要件で大きくぶれます。うちの場合、用語集（1,500〜2,500字）は writer エージェント単発で1本あたり数分、pillar guide（8,000字以上）は writer + reviewer + auditor の3段階で1本あたり数時間というのが現実値です（※ Tufe Company 内部実測 / 2026-05時点）。生産性数値を社内提案に使う場合は、必ず自社実測に置き換えてください。

Chapter 5: 編集ワークフロー — 段階ゲートで品質崩壊を止める

段階ゲート設計

量産は「同時並行で何本も流れている」状態が常態です。段階ゲートを設計しないと、出典なき数字や内部リンクの抜けが本番に出ます。うちで運用している5段階ゲートを共有します。

1. G1: 構成案レビュー — 構成、固有差分、内部リンク網、データソース URL が揃っているか
2. G2: ドラフト執筆 — writer エージェント or 人間ライターが本文を書く
3. G3: ファクトチェック — 数字に ±5行以内の出典脚注があるか、URL は実在するか
4. G4: コードレビュー — frontmatter の必須項目、内部リンクの正当性、Article schema の必須プロパティ
5. G5: 公開判断 — 最終 OK は人間が押す。誤情報の責任は会社が負うため

各ゲートで「不合格なら前ゲートに差し戻す」を厳格にしないと、量産品質は壊れます。差し戻しを許容できないと、不合格でも公開されてしまうからです。

編集チェック30項目（コピペテンプレ）

公開前にこの30項目を1つずつ潰してください。半数以上の no が出たら G2 に差し戻しが妥当です。

構成（5項目）

• 検索意図（informational / commercial / transactional / navigational）が1つに絞られている
• pillar から派生する位置づけが明確
• H2 が5〜10個、H3 が各H2に2〜4個
• 冒頭リードで結論を先出ししている
• 章末で「次に何をすべきか」が読者に伝わる

事実検証（10項目）

• 具体数値（%・倍・件・秒・分・時間・年・万・億・円）すべてに出典脚注がある
• 出典脚注は対象行から ±5行以内に配置されている
• 出典 URL は政府統計・業界団体公式・主要調査会社のいずれか
• Wikipedia・個人ブログ・出典なき他社記事を引用していない
• 「弊社調べ」「業界標準的に」のような曖昧な逃げが無い
• 警戒数字パターン（Map Pack CTR・FAQ リッチリザルト・LCP・GPT-4o 価格等）が最新値
• 会社名・サービス名の運営元を一次確認した
• 古い API 価格を引用していない
• 統計値の取得年月が出典直後に書かれている
• 自社実測値には Tufe Company 内部実測 / YYYY-MM時点 注釈がある

内部リンク（5項目）

• glossary への内部リンクが最低8本
• compare への内部リンクが最低2本
• services / tools への内部リンクが最低2本
• industries / areas への内部リンクが最低3本
• pillar 同士の相互リンクが最低3本

CTA・コピー（5項目）

• CTA は漸進式の5段階（無料ツール → 無料診断 → 単発商品 → サービス → 相談）
• 英語 CTA が混入していない
• 「研究所」「編集的リサーチ会社」のようなポジショニング詐称が無い
• CTA に時間・形態・契約前提の有無のような具体が入っている
• 「詳しくはお問い合わせください」で読者を棚上げにしていない

Article schema・公開設定（5項目）

• frontmatter に reviewedBy / wordCount / dateModified が入っている
• 字数が宣言と実測で乖離していない
• OG image は /api/og 経由（layout の上書きを避ける）
• proxy.ts validPaths を手動編集していない（app/ ルート追加で自動生成）
• FAQPage JSON-LD があれば本文 FAQ と一致している

コラボレーションツール

うちでは GitHub Pull Request を編集ワークフローの中心に据え、PR チェックリストとして上記30項目を automated check + human review で分担しています。pSEO は1本ずつ PR を立てるとレビュー疲労が起きるため、5〜10本まとめて1 PR にし、reviewer エージェントが先に走ってから人間が見るフローです。

Chapter 6: 出典確認の自動化 — audit_numbers.sh のような検証スクリプト

スクリプトで止められるのは「明らかな違反」

CSV 監査で検出できるのは、(1) 数字がある行から ±5行以内に出典脚注が無い、(2) 「弊社調べ」「Tufe調べ」のような禁止フレーズ、(3) ※ 出典: の語が無い具体数値 の3パターンです。検出できないのは「数字は合っているが帰属先が違う」「会社名は出ているが運営元が違う」のような誤帰属で、ここは人間レビューで埋めます。

監査スクリプトの設計指針

うちでは scripts/audit_numbers.sh という Bash スクリプトで content 配下を一括スキャンしています。設計のポイントは次の通りです。

1. 正規表現で数字行を抽出 — [0-9]+(\.[0-9]+)?(%|倍|円|万|億|分|秒|時間|年|件|本|個|回|名|社|店) のパターン
2. ±5行以内に ※ 出典: または ※ Tufe Company 内部実測 の語が無ければ違反
3. 違反は severity を high / medium / low で分類 — 一次出典が必要な数字（市場シェア・CTR 等）は high、年号・自社価格は medium 等
4. single-file モードを用意 — audit_numbers.sh --file=<path> で writer エージェントの事前ゲートに使える
5. high 違反が1件でもあれば exit 1 — CI で公開を止められる

実行例

# 全体監査
bash scripts/audit_numbers.sh

# ディレクトリ指定
bash scripts/audit_numbers.sh --target=guides

# 単一ファイル監査（writer の事前ゲート）
bash scripts/audit_numbers.sh --file=content/guides/content-ops-pipeline-complete-2026.mdx

出力 CSV には path, line, snippet, severity, reason が並び、SUMMARY 行と top_20_offending_files も自動生成します。pSEO 生成5〜10本ごとに実行して、違反密度 top 10 のファイルを修正発令するという運用です。

スクリプトの限界 — 必ず人間が見る3点

1. 誤帰属 — 数字は合っているが運営元・出典元の名前が違う
2. 混同合成 — 別々の研究の数値を1つの文脈に混ぜている
3. 意味のすり替え — 「離脱率」と「CVR 低下率」を取り違えている等

これらは Chapter 8 の品質監査エージェントで多角レビューします。スクリプトは品質維持の天井ではなく、最低ラインを守るための床と捉えてください。

Chapter 7: 内部リンク自動化 — internal-linker と topic modeling

内部リンクは pSEO の生命線

外部被リンクが集まりにくい新規ドメインでも、内部リンクの設計次第でクラスター内の権威伝播は起こせます。Ahrefs は内部リンクの重要性を継続的に発信しており、「pillar に向かう内部リンクが多いページほど検索順位が上がる」傾向を観測しています。

※ 出典: Ahrefs Blog「Internal Links for SEO: An Actionable Guide」（取得 2026-05）

内部リンク自動化の3手法

Tufe の internal-linker 設計

うちでは data/glossary-terms.json に「キーワード→ slug」のマッピング辞書を持ち、writer エージェントが本文ドラフトに glossary 用語を出すたびに自動でリンク化する仕組みです。compare / industries / areas / guides のリンクは、writer エージェントが配置済みクラスター情報を見ながら手動配置していますが、配置候補は事前にプロンプトで提示しています。

// data/glossary-terms.json（一部抜粋イメージ）
{
  "LLMO": "llmo",
  "GEO": "geo",
  "JSON-LD": "json-ld",
  "Schema.org": "schema-org",
  "ChatGPT Search": "chatgpt-search",
  "Perplexity": "perplexity",
  "Map Pack": "map-pack",
  "E-E-A-T": "eeat"
}

内部リンク密度の目安

上限を超えると、Google の SEO スターターガイドが推奨する「読者にとって自然な数」を超え、リンク評価が薄まる懸念があります。

※ 出典: Google Search Central「Search Engine Optimization (SEO) Starter Guide」（取得 2026-05）

リンク先の品質管理

リンクを増やせば良いわけではありません。(1) リンク先が公開済み（404 にならない）、(2) リンク先のテーマが文脈と合致、(3) 同一ページから同一リンク先への重複が無い の3条件は最低限自動化で守ります。うちでは proxy.ts の validPaths 自動生成と組み合わせ、lib/valid-paths.ts に存在しないルートへのリンクは CI でエラーにしています。

Chapter 8: 品質監査の仕組み — 複数エージェントによる多角レビュー

1人のレビュアーでは見落としが出る

レビューは多角化するほど精度が上がります。うちでは6種の専門エージェント（bug-investigator / code-reviewer / bug-fixer / system-auditor / test-runner / qa-pro）で役割分担し、コンテンツも複数の視点から見るフローを組んでいます。

エージェント分業の例

「同じ視点で2回見る」より「違う視点で1回ずつ見る」ほうが、誤情報や設計欠陥は見つかりやすいというのが、うちの運用観察です（※ Tufe Company 内部観察 / 2026-05時点）。

多角レビューの最小構成

エージェントを全部用意できなくても、最低限以下の3点を別レビュアー（人間でも可）に分けると効きます。

1. 構成・読者価値の視点 — 「この記事を読み終えた読者は次に何ができる？」
2. 事実・出典の視点 — 「この数字の一次出典 URL は何？」
3. コード・配線の視点 — 「frontmatter・schema・内部リンク・OG image は配線されている？」

監査の運用頻度

• pSEO 生成5〜10本ごと — fact-checker と internal-linker 走査
• 週次 — system-auditor で全体ヘルスチェック
• 月次 — 全数監査で違反率レビュー、リフレッシュ対象を選定
• リリース直前 — フル監査

監査の頻度が下がると、量産の負債が静かに溜まります。Chapter 9 の失敗パターンの大半は、監査頻度の低下から始まります。

Chapter 9: 失敗パターン10 — 品質崩壊の兆候・カニバリゼーション

ここまでに散りばめた失敗を、再現性の高いチェック用に10個に集約します。

1. テンプレに固有差分がない — 「杉並 MEO」「練馬 MEO」で差し替え部分が地名のみ。Google の scaled content abuse 判定に直行する典型。固有差分は最低でも文章の半分以上が必要（※ Tufe Company 社内基準 / 2026-05時点）。
2. 数字の孫引き — 競合記事の数字を出典確認せずコピー。Map Pack CTR「20-30%」のような俗説は、Backlinko の実証で約 17.6% に下方修正されています（Backlinko）。古い俗説を引用すると会社の信用が崩れます。
3. カニバリゼーション — 同一検索意図のページが複数存在し評価が分散する状態。「SEO とは」「SEO 意味」「SEO 定義」がそれぞれ独立ページになっているなど。月次でクラスター内の重複意図ページを検出し、マージする運用が必要。
4. 内部リンクの一方通行 — cluster から pillar に戻る線が無く、pillar から cluster への一方通行になっている。pillar の権威が cluster に流れず、cluster の検索シグナルが pillar に集まらない。
5. dateModified の更新忘れ — リライトしたのに dateModified が古いまま。AI 検索エンジンの鮮度判定が上がらず、引用率に悪影響。書き換えを CI で強制するのが安全。
6. 出典 URL の404放置 — 公開時は実在した URL が後に削除され、リンク先が404に。月次の自動リンクチェッカーで検出し、代替 URL に差し替えるか出典を変更する。
7. AI 出力をそのまま公開 — writer エージェントの出力を人間レビューなしで公開。誤帰属・古い数字・推測 URL が混入する典型ケース。公開判断は必ず人間が握る。
8. CTA の文体崩れ — 「Request a consultation」「Schedule a meeting」のような英語 CTA が日本語ページに混入。AI ドラフトに引きずられやすいので、編集チェックの定型項目に入れる。
9. scaled content の量産依存 — 「とにかく月100本」を目標化してしまい、品質ゲートが空洞化。Google が2024年3月以降に scaled content abuse をスパムポリシーに追加（Google Search Central）して以降、量だけ追うと半年〜1年で順位が剥がれます。
10. 誤情報拡散 — 1つの古い数字が pillar に書かれ、cluster が pillar を出典として孫引きし、別の pillar に転写される負の連鎖。1箇所の誤りが30箇所に広がる前に、月次の全数監査で根本を直す。

※ Map Pack CTR の参考: Backlinko「Google Local Pack & Maps Click-Through Rate」（取得 2026-05）

Chapter 10: うちの量産パイプラインを一部開示

ここから先は具体的な顧客固有情報は伏せたうえで、Tufe 自身がどのように量産パイプラインを設計しているかを、参考のために共有します。

エージェント生態系

うちでは Claude Code 上で次のような分業を組んでいます。

• pseo-orchestrator — 生成キューを管理し、各種 writer に指示を出す上位エージェント
• glossary-writer / area-writer / industry-writer / compare-writer / guide-writer — pSEO タイプ別の writer
• content-reviewer — 文体・構成・読者価値レビュー
• system-auditor — リポジトリ全体のヘルスチェック
• bug-investigator / bug-fixer / code-reviewer / test-runner — 配線・実装系の点検

エージェント名はうちの内部規約で、外部に公開する仕様ではありません。考え方として「役割を分けて多角レビューする」が肝で、エージェントでなく人間チームでも同じ分業は組めます。

生成キューの粒度

うちの場合、1日10〜20本程度のキューを流し、エージェントの並列度を上げすぎないように制御しています（※ Tufe Company 内部運用 / 2026-05時点）。並列度を上げると monitoring が追いつかず、不合格ファイルが公開キューに混ざるリスクが上がるためです。

audit_numbers.sh の運用

pSEO 生成のたびに audit_numbers.sh --file=<path> を writer エージェントの事前審査ゲートとして走らせています。high 違反が一度でも残っていれば writer が起動を止めるため、出典なき数字が公開キューに進むことが構造的に防がれます。詳細は Chapter 6 のスクリプト設計指針を参照してください。

監査の循環

• 新規生成: writer → reviewer → auditor → 人間最終確認
• 既存リフレッシュ: 月次で全数監査 → 違反密度 top 10 を修正発令
• 警戒数字パターン: パターン辞書を更新するたびに該当箇所を一括検出して修正

「生成する」と「治す」を同じ重みで回すのが、量産が崩壊しないコツです。生成 : 監査 ＝ 7 : 3 くらいの工数配分が現実的だと観察しています（※ Tufe Company 内部観察 / 2026-05時点）。

公開・配信

公開後は IndexNow で Bing / Yandex に即時通知し、Google には Search Console のサイトマップ更新で検出を促します。AI 検索エンジンへの認識を早めたい場合は llms.txt の更新も同時に走らせます。詳しくは llms.txt と AI 検索完全ガイド と LLMO/GEO 完全ガイド を参照してください。

量産前準備チェックリスト 20項目

公開前の最終チェックではなく、量産パイプラインを動かす前にすべて埋まっているかを見るチェックです。

戦略・設計（5項目）

• pillar guide のテーマ・スラッグ・章立てが確定している
• クラスター設計シート（pillar / cluster / KW / status / 内部リンク）が存在
• 検索意図の分類ルールがチーム内で共有されている
• カニバリゼーション検出の月次運用が決まっている
• 量と質のトレードオフをチームで合意（月X本上限など）

データ・テンプレ（5項目）

• テンプレに固有差分スロットが半分以上ある
• テンプレに出典脚注スロットが組み込まれている
• データソース URL のリスト（政府統計・業界団体・自社実測）が整備
• 警戒数字パターン辞書が最新値で更新済み
• AI 出力ハルシネーション対策の3手順がプロンプトに入っている

編集ワークフロー（5項目）

• 段階ゲート（G1〜G5）が定義され、差し戻しルールが共有
• 編集チェック30項目が PR テンプレートに組み込まれている
• 公開判断は必ず人間が押す仕組み
• 英語 CTA・ポジショニング詐称の禁止リストが共有
• 「詳しくはお問い合わせください」の禁止が共有

監査・自動化（5項目）

• 出典監査スクリプト（audit_numbers.sh 相当）が稼働
• 内部リンク自動化（辞書方式 or 意味的類似度）が稼働
• dateModified 書き換えが CI で強制されている
• 公開後の IndexNow 通知 / サイトマップ更新が自動
• 月次の全数監査スケジュールが確定

トピッククラスター設計シート（コピペ用）

スプレッドシートにそのまま貼って使ってください。

このシートを月次で見て、internal_links_to_pillar = 0 や last_refresh が半年以上前のページを優先的にリフレッシュ対象にする運用が回ります（※ Tufe Company 社内運用基準 / 2026-05時点）。

公的・一次情報リソース集

社内 Slack に貼って共有してください。コンテンツ運用の意思決定で必ず参照したい一次情報です。

Google 公式

• Google Search Central（公式ドキュメントトップ）
• Search Engine Optimization (SEO) Starter Guide
• Creating helpful, reliable, people-first content
• Google Search's guidance about AI-generated content
• March 2024 core update and new spam policies
• Article structured data
• Google Search Status Dashboard
• Latest Google Search Documentation Updates

業界調査・実証データ

• Backlinko（オリジナル調査）
• Ahrefs Blog
• Semrush Blog
• Search Engine Land
• Search Engine Journal
• HubSpot Blog（トピッククラスター概念の発祥）

関連 schema・配信

• Schema.org
• Schema Markup Validator
• Rich Results Test
• IndexNow

まとめ — 5つの要点

1. 量と質は両立できる — ただし scaled content abuse の3条件（固有差分薄い・出典なし・孤立島）を避ける設計が前提
2. トピッククラスター設計が骨格 — pillar + cluster + 相互内部リンクの3点セットで権威を集約
3. AI 任せ vs 人間が握るの境界を決める — 公開判断と一次出典確認は必ず人間
4. 段階ゲートと自動監査で品質を守る — G1〜G5 の差し戻しを許容できないと、量産品質は壊れる
5. 生成 : 監査 ＝ 7 : 3 の工数配分 — 「治す」工数を確保しないと、誤情報が静かに30箇所に広がる

よくある質問

Q. pSEO は Google にペナルティを受けますか？

pSEO（プログラマティックSEO）そのものはペナルティ対象ではありません。Google が問題視するのは scaled content abuse、つまり「量産されただけで読者に価値を提供しないコンテンツ」です。テンプレに固有差分があり、出典のある数字と読者が次の一歩を決められる材料を含んでいれば、量産自体は許容されます。詳しくは Chapter 1（量と質を両立する設計思想）を参照してください。

※ 出典: Google Search Central「March 2024 core update and new spam policies」（取得 2026-05）

Q. AI 執筆と人間執筆、どちらが SEO に強いですか？

Google 公式は「AI を使ったかどうかではなく、ページが読者ファーストで作られているかを評価する」と明言しており、人間か AI かは評価軸ではありません。実務的には、構成案・本文ドラフト・内部リンク挿入は AI が得意、一次出典確認・公開判断・固有差分の追加は人間が担うのが現実解です。詳しくは Chapter 4（AI執筆の役割分担）を参照してください。

※ 出典: Google Search Central「Google Search's guidance about AI-generated content」（取得 2026-05）

Q. 月に何本くらいまでなら量産しても安全ですか？

絶対的な本数の上限は無く、(1) 検索意図に合致したテンプレがあるか、(2) 1本ごとの固有差分が半分以上あるか、(3) 公開前ゲートで品質を担保できるか、の3条件が満たされていれば月数十本〜数百本でも問題ありません。逆に上記が守れないなら少数本でも順位は剥がれます。本数より「公開させない力」のほうが重要です。詳しくは Chapter 3（pSEO の実装）と Chapter 5（編集ワークフロー）を参照してください。

Q. 出典が見つからない数字はどうすべきですか？

書かない、または定性表現に落とすのが大原則です（「約〜規模」「〜の傾向」「ケースによる」）。自社実測値は ※ Tufe Company 内部実測 / YYYY-MM時点 の注釈で明示します。「弊社調べ」「業界標準的に」のような曖昧な逃げは禁止です。詳しくは Chapter 6（出典確認の自動化）を参照してください。

Q. 古いコンテンツは消したほうがいいですか？

カニバリゼーション（同一意図ページが複数存在し評価が分散）が起きているなら統合か削除、起きていなければリフレッシュ（数字更新・出典更新・dateModified 書き換え・内部リンク追加）が原則です。AI 検索エンジンの鮮度判定でも dateModified の更新は効きます。詳しくは Chapter 9（失敗パターン10）を参照してください。

関連ガイド

シリーズの他のガイドも併読してください（各ガイドは Google Search Central の同じ一次情報を共有しています）。

• SEO 完全ガイド 2026年版 — pillar/cluster 設計と SEO 戦略全体像
• LLMO/GEO 完全ガイド 2026年版 — AI 検索引用率を上げる設計
• 構造化データ完全ガイド 2026年版 — Article schema / FAQ schema 実装
• E-E-A-T 実装完全ガイド 2026年版 — author / reviewedBy の信頼性設計
• llms.txt と AI 検索の完全ガイド — AI 検索エンジンへの自己宣言

※ 出典: Google Search Central「Creating helpful, reliable, people-first content」（取得 2026-05）

関連用語集

• ロングテール SEO / コンテンツマーケティング / コンテンツ SEO
• 内部リンク / E-E-A-T / テクニカルSEO
• LLMO / GEO / LLM 引用率 / llms.txt
• ChatGPT Search / Search Console / GSC

関連業種・エリア

• B2B SaaS × LLMO — コンテンツ運用が成果に直結する業種の例
• 税理士 × SEO コンテンツ — 士業のコンテンツ運用
• 美容室 × SEO コンテンツ — 店舗系のコンテンツ運用
• 杉並 × MEO — エリア型 pSEO の実装例

関連比較

• インハウス vs アウトソース SEO — 量産体制の内製化判断
• ヘッドレス CMS vs WordPress プラグイン LLMO — pSEO の CMS 基盤選定
• 手動 vs AI 生成 llms.txt — AI と人間の役割分担の参考
• Surfer SEO vs Frase（日本） — コンテンツ最適化ツールの比較

まずは現状把握から

量産パイプラインは「やる気になれば自社で組める」領域です。Tufe Company に依頼する必要は必ずしもありません。以下は段階別の選択肢です。

1. 無料で試す — LLMO 無料診断 で現状の AI 検索適合度を5軸100点で可視化
2. 書面で診る — AI Search Health Check（¥14,800） でコンテンツ運用を含む5軸の改善方針書を取得
3. 継続支援が必要なら — SEO & Content サービス で月次の量産パイプライン設計と運用支援
4. 個別相談 — 無料相談（オンライン・契約前提ではない） で量産設計のロードマップをすり合わせ（※ Tufe Company 提供サービス目安 / 2026-05時点）
5. 記事を読む — 関連ガイドを併読して社内で議論の土台を作る