人手量産か、AI×編集体制か：月数十本ペースのSEOコンテンツを崩さず回す中小企業の運用アーキテクチャ選択
中小企業のSEO運用で起きる「人手では本数が伸びない／AI生成だけでは品質が崩れる」の両極を抜けるためのAI×編集体制を、企画・執筆・レビュー・公開の4工程に分解して提示する。月数十本ペースを崩さないパイプライン設計、E-E-A-TとGoogleスパム対策に耐える品質設計、稟議書素材までを一気通貫で言語化した運用設計書。
このホワイトペーパーで分かること
- 自社のSEOコンテンツ運用が「人手量産」「放任AI生成」「AI×編集体制」のどの位置にあるかを診断する基準
- 企画・執筆・レビュー・公開の4工程をAIと人手で役割分担する標準アーキテクチャ
- 月数十本ペースを崩さない5工程パイプライン（Topic Cluster設計から内部リンク仕込みまで）
- E-E-A-T／Googleスパム対策／独自データ／内部リンクの4軸で品質を担保する設計
- 「人手量産」と「AI×編集体制」を経営会議で比較するための稟議用1ページサマリー
対象読者
- BtoB SaaS／専門サービス／人材／医療／士業／教育のオウンドメディアを運用する従業員30〜300名規模の中小企業のマーケ責任者で、人手だけでは月8〜12本で停滞している層
- マーケと営業を両管掌する事業責任者で、AI生成で量を稼いだ後に品質と検索順位が落ちて止まっている層
- 編集長または1人マーケ兼任の編集責任者で、内部リンクの整備が手作業で追いつかなくなっている層
- 経営層から「コンテンツ運用のROIは」「結局AIで効率化したのか」と問われ、本数と商談数のつながりを言語化したい責任者
このWPの結論（Executive Summary）
課題と緊急性
2024〜2026年の検索環境は、GoogleのHelpful Content System、Spam Policies、AI Overview導入で大きく変わった。独自性のないAI生成コンテンツを順位から外す方向に強く傾いている（Google検索セントラル「Spam policies for Google web search」公式発表）。
一方で中小企業のオウンドメディア競争は激化している。人手のみで月10本前後の運用では、競合との累積本数差と内部リンク密度で年単位で差が開く。両極のどちらに振っても詰む構造に経営判断が追いついていない。
アプローチ
「人手量産」と「放任AI生成」の両極ではなく、企画・執筆・レビュー・公開の4工程を「AIに振る領域」と「人手判断を残す領域」に分離するAI×編集体制で組む。
パイプラインは5工程に標準化し、月数十本ペースを崩さない。品質はE-E-A-T・Googleスパム対策・独自データ・内部リンクの4軸で担保する。
主要発見
- 月数十本ペースは人員数ではなくパイプラインの設計問題。同じマーケ専任2〜3名でも、自動化工程と人手判断の分離度で本数は数倍変わる（自社seo-factory運用の観察値）
- AI生成の品質崩れの一次原因は執筆プロンプトではなく、企画段階のTopic Cluster設計と検索意図定義の粗さに集中している
- Google検索評価が下落するAI生成は「人手レビュー未実施」「独自データ・一次情報なし」「内部リンク孤立」の3要件のいずれかが欠けたパターンに偏る
- レビューは「人手による全文精読」から「独立AIエージェントによる自動レビュー＋人手最終承認」に切り替えると、本数を増やしつつ品質を維持できる
- 内部リンクは量産時こそ崩れる工程。AI＋構造化データ＋Topic Cluster地図で半自動化しないと、サイト全体の評価が積み上がらない
目次
- SEO競争激化とAI生成の品質問題：両極のどちらも詰む構造
- 2026年の検索評価：E-E-A-TとAI Overviewが変えた前提
- AI×編集体制の標準アーキテクチャ：4工程の役割分担
- 月数十本ペースのパイプライン：5工程の標準型
- キーワード戦略：Topic Cluster・検索意図・重複回避の3軸
- 内部リンク設計：量産時こそ崩れる工程を半自動化する
- 品質を担保するレビュー型：独立レビュー＋自動修正＋人手最終承認
- ツール選定の現実解：Claude／ChatGPT／Perplexity／Ahrefs／Surfer SEOの組み合わせ
- E-E-A-TとAI生成の折り合い：一次データ・著者性・独自視点の3要件
- 失敗事例：量だけ追ってGoogle評価が落ちる3パターン
- 稟議用1ページサマリー：人手量産 vs AI×編集体制の経営判断
- 次のアクション：30分でできるSEO運用アーキテクチャ自己診断
1. SEO競争激化の構造：両極のどちらも詰む
中小企業のオウンドメディア運用は、今2つの停滞パターンに分裂している。
一つは「人手で月8〜12本を死守するが、累積本数と内部リンク密度で競合に負ける」パターン。もう一つは「AI生成で量だけ取った結果、品質ブレで検索順位が落ち、稟議が通らなくなる」パターン。経営会議の議題として、どちらにも明確な答えが出ていない。
なお1人マーケでの運用設計は別WP（content-ops-saito-method）で扱った。本WPは月数十本ペースを目指す「スケール側」の運用設計に絞る。1人運用との混同を避けるため最初に明示しておく。
従業員30〜300名規模で内製ライター1〜2名＋外部編集者数名の体制。月8〜12本で頭打ちになり、競合との本数差が年単位で開く。採用は半年単位、育成も半年単位。本数を倍にするには人件費を倍にする発想しか出ない。
ChatGPTやClaudeで量を稼ごうとしたら、初稿の品質が章ごとにブレ、レビュー工数で結局時間を食う。AI生成比率を上げた数ヶ月後にGoogle順位が一部記事で下落し、稟議で「結局効果あったのか」と詰められる。
企画・執筆・レビュー・公開の4工程を「AIに振る領域」と「人手判断を残す領域」に分離する。月数十本ペースを崩さず、品質はE-E-A-T・独自データ・内部リンクの軸で担保する。
1.1 人手量産はなぜ本数で詰むのか
人手量産は、ライティングだけでなく企画・キーワード調査・内部リンク整備・公開作業の全工程に人手判断が入る前提で設計されている。1本あたりの平均工数は、企画1〜2時間、執筆4〜6時間、編集2〜3時間、内部リンク・公開1時間で、合計8〜12時間が一般的な感覚値である。
マーケ専任2名が月160時間ずつ動いても、SEO以外の業務を引いた稼働は半分以下。本数だけ見れば月8〜12本が現実的な上限になる。本数を倍にしようとすると、外部編プロ・ライターを追加する以外の打ち手が出ず、編集ディレクションの工数が逆に増える。
1.2 放任AI生成はなぜ品質で詰むのか
AI生成の品質崩れは、執筆プロンプトの精度ではなく、上流の企画段階で発生していることが多い。Topic Cluster設計が曖昧で、検索意図の定義が浅く、競合との重複回避が事前にできていない状態でAIに執筆させると、章ごとに主張がブレ、結論が後出しになる。
人手レビューで全文精読する前提でこの上流の粗さを補おうとすると、レビュー工数が執筆工数を超え、月本数は人手量産と変わらないか、それ以下に落ちる。さらに人手レビューを省略すると、独自データのない一般論記事がGoogleの評価を取れず、検索順位が下落する。
2. 2026年の検索評価：前提が変わった
Google検索の評価ロジックは2022〜2026年で大きく変わった。AI生成を見抜き、独自性のないコンテンツを順位から外す方向に強く傾いている。AI×編集体制を設計する前に、この前提変化を経営層に説明できる粒度で押さえる必要がある。
Googleは「人のために作られた、満足度の高いコンテンツ」を評価する仕組みを導入。検索順位を狙うためだけのコンテンツは評価しないと公式に明文化した（Google検索セントラル「Helpful content system」）。
2024年3月のコアアップデートで、低品質な大規模生成コンテンツへの対応が強化された。スケーラブルコンテンツアビューズ、サイトレピュテーションアビューズ、エクスパイアードドメインアビューズの3類型が公式にスパム認定された（Google検索セントラル「Spam policies for Google web search」）。
生成AIによる検索結果サマリー（AI Overview）が検索面の上部に表示される領域が広がった。被引用される記事の特性（独自データ・著者性・FAQ構造化）が、従来のSEOとは別の評価軸として浮上している。
2.1 「AI生成だから順位が落ちる」のではない
Google公式は「AI生成だから問答無用で評価を下げる」とは明言していない。順位下落が起きるのはAI生成かどうかではなく、「人のために作られたか／満足度が高いか／独自性があるか」の評価軸を満たさないコンテンツである（Google検索セントラル「AI生成コンテンツに関するGoogle検索のガイダンス」）。
つまり、AI生成それ自体は問題ではない。問題は「独自データのないAI出力をそのまま公開する」「人手レビューを通さない」「内部リンクが孤立する」といった運用上の手抜きである。経営会議では「AI生成は禁止すべきか」ではなく「AI生成にどの品質ゲートをかけるか」を議論軸にする。
2.2 AI Overviewの構造的影響
AI OverviewはBtoB／専門領域の検索結果でも表示頻度が増えており、被引用される記事は「独自データ」「明確な主張」「構造化された見出し」を備えるものに偏る傾向が報告されている（Search Engine Land、Search Engine Journal各レポート）。
つまり、AI Overview時代に勝ち残る記事は、AI生成の表面的な滑らかさではなく、「Googleの生成AIが引用したくなる独自性」を持つ。これは人手レビューでしか担保できない軸である。
経営層への説明は、Google公式の整理を起点にすると稟議が通りやすい。「AI生成かどうか」ではなく「コンテンツの品質と独自性」を評価する、というシンプルな建付けである。この公式整理を1枚スライドに落として、社内の論点を「AI生成の可否」から「品質ゲートの設計」に移すのが最初の一手になる。
3. AI×編集体制の標準アーキテクチャ：4工程の役割分担
AI×編集体制の核は、企画・執筆・レビュー・公開の4工程を「人手判断の重さ」と「上流／下流」の2軸で分けることにある。両軸の組み合わせでAIに振る領域と人手判断を残す領域が明確になる。
Topic Cluster設計、キーワード意図の解釈、独自視点の角度設計、競合との重複回避判断は人手中心。マーケ責任者または編集長が30分〜2時間で意思決定する領域。
公開前の最終承認は人手。E-E-A-T要件（著者性・一次データ・独自視点）の最終確認と、Google公式のSpam Policies照合を1記事10〜15分で行う領域。
構成案からのドラフト生成、書き直し、章構造の整理、見出しのリライトはAIに振る。執筆プロンプトの設計が上流で固まっていれば、ドラフトのブレは大幅に減る。
内部リンクの候補抽出、構造化データの生成、メタディスクリプション作成、画像のalt属性生成はAIに振る。人手は最終確認のみ。
3.1 「人手判断が重い」工程を上流に寄せる
人手判断が重い工程は上流（企画・最終承認）に集中させ、下流（ドラフト生成・公開作業）はAIに振り切る。この役割分担で月本数が伸びる理由は、上流の意思決定品質がドラフトの品質を決定するからである。
つまり、企画段階のTopic Cluster設計で「この記事は誰が何を知りたくて検索しているか」「Pillarとの関係はどうか」「自社内でカニバリゼーションは起きないか」を30分で確定すると、AIが出すドラフトは章構造のブレが少なくなる。
3.2 「人手判断が軽い」工程をAIに振り切る
人手判断が軽い下流工程（ドラフト生成、公開作業）は、人手で触る限り月本数の上限が決まる。逆に言えば、ここをAIに振り切る覚悟がつけば、本数は数倍に伸ばせる。
ただし「振り切る」は「品質ゲートを抜く」ではない。AIドラフト生成の後に独立AIレビュー、その後に人手最終承認を必ず通す。下流工程を高速化することと、品質ゲートを省くことは別物である。
4. 月数十本ペースのパイプライン：5工程の標準型
月数十本ペースを崩さないパイプラインは、5工程に標準化される。各工程の入出力と「AIに振る／人手判断を残す」の境界を事前に決め、属人化を避ける。
Pillar記事と複数のSpoke記事の構造を地図化する。検索意図ごとに記事を割り当て、自社内のカニバリゼーションを事前に避ける。マーケ責任者または編集長が30分〜2時間で意思決定。
1記事ずつ「誰が／何を知りたくて／どのフェーズで検索しているか」を3要素で確定する。Ahrefs／Semrush／GSCの一次データで検索ボリュームと競合の上位記事を確認。
構成案からドラフトをAIで生成する。執筆プロンプトには「対象読者の業種×規模×役職」「自社の独自視点」「一次データ／自社事例の候補」を含める。
ドラフト生成と別の独立AIエージェントでレビューする。E-E-A-T／Spam Policies／内部リンク／独自性の4軸で自動採点した後、人手で最終承認。
構造化データ、メタディスクリプション、内部リンク候補をAIで生成し、人手で最終確認して公開する。Topic Cluster地図に新記事を追加し、関連Spoke記事の被リンクを更新。
4.1 「月数十本」の根拠と定性化
「月数十本」という規模感は、自社のseo-factory運用で観察した経験値である。FULLFACTのseo-factory運用では、マーケ専任2〜3名体制でこの5工程パイプラインを回し、月数十本ペースで公開を継続している（自社観察値、N=数社／継続中）。
ただし、業界一般のベンチマークとして「中小企業は月数十本が標準」という統計が存在するわけではない。本数は「上流の意思決定品質」と「下流のAI自動化度」の組み合わせで決まる変数であって、固定値ではない。
Ahrefs／Semrush公開レポートでも、業界別のコンテンツベロシティは大きく分散している（Ahrefs Blog「Content Velocity」レポート参照）。自社の前提に合わせた本数目標を、業界平均ではなく自社のパイプライン設計から逆算する必要がある。
4.2 工程標準化の3段階で立ち上げる
工程標準化は一度に5工程を仕上げる発想ではなく、段階を踏んで組み立てる。最初は「Topic Cluster設計」と「独立レビュー」の2工程を標準化するだけで、月本数の伸びは観察できる。
次に「AIドラフト生成プロンプト」を社内テンプレ化して3工程までを定着させると、属人化していた執筆品質が安定する。最後に「公開・内部リンク仕込み」をAIに振って5工程まで揃えると、月数十本ペースを崩さない運用に近づく。
人員を倍にしても工程の標準化がされていなければ本数は線形にしか伸びない。月本数を伸ばす経路は「人員追加」ではなく「工程の段階的な標準化」にある。
パイプラインの工程定義は「3ヶ月で完成させる」のような固定期間で訴求するものではない。自社の運用に合わせて段階的に組み立てる。1工程→3工程→5工程と段階を踏むほど、人員数に依存しない本数の伸びが観察しやすくなる。
5. キーワード戦略：3軸で重複を避ける
AI×編集体制で月数十本ペースを回す前提では、キーワード戦略の段階で「重複させない」設計が必須になる。3軸で重複を避ける。
第一にTopic Cluster構造でPillarとSpokeの関係を地図化する。第二に検索意図ごとに記事を割り当てる。第三に自社内・競合との重複を事前にチェックする。この3軸が崩れると、AIドラフトの章構造もブレる。
広い検索クエリで網羅的に解説するPillar記事を1テーマにつき1本配置。SpokeからPillarへの内部リンクを集約し、サイト全体の権威性を高める。例：「BtoB SaaS マーケティング 完全ガイド」。
PillarのサブトピックをそれぞれSpoke記事として深掘り。検索意図が明確で、商談化に近いキーワードを優先する。例：「BtoB SaaS リード獲得 5施策」。
特定の課題・ツール・業種に絞ったLong-tail記事。検索ボリュームは小さいが、商談化率が高い層に届く。例：「BtoB SaaS HubSpot 導入 落とし穴」。
5.1 検索意図の3分類で記事を割り当てる
各キーワードについて、検索意図を「情報収集型／比較検討型／意思決定型」の3分類で確定する。情報収集型はPillar記事に寄せ、比較検討型と意思決定型はSpoke／Long-tailに寄せる。
検索意図の分類はGSCのクエリデータとAhrefsのSERPデータで一次データから確定できる。AIに依頼するのではなく、人手判断で確定する領域である。ここを曖昧にすると、AIドラフトの導入文と結論文がズレる。
5.2 自社内カニバリゼーションを事前に避ける
月数十本ペースで公開していると、過去記事と新記事で同じキーワードを狙ってしまうカニバリゼーションが起きやすい。事前にTopic Cluster地図と公開済み記事の一覧を照合し、重複候補は記事統合または角度変更で回避する。
キーワード戦略の3軸チェック（Topic Cluster配置／検索意図分類／カニバリ回避）は1記事あたり30分以内に終わる設計にする。ここに時間をかけすぎると上流がボトルネックになり、月本数が伸びない。30分という時間的上限を運用ルールに組み込んでおく。
6. 内部リンク設計：量産時こそ崩れる
内部リンクは月10本までは人手で追いつく工程である。だが月数十本ペースに入ると、確実に崩れる。Topic Cluster地図の更新と新規記事からの被リンク設計が、人手の追跡限界を超えるためである。
公開ごとに編集者が関連記事を3〜5本選び、手動で被リンクを追加する。月本数が増えるとTopic Cluster地図の更新が遅れ、新規記事と既存記事のリンク漏れが発生する。サイト全体のリンク密度が薄くなり、検索評価が積み上がらない。
Topic Cluster地図をデータとして構造化し、新規記事の公開時にAIが関連候補を自動抽出する。人手は最終確認のみで、5〜10分で完了する。Pillar記事へのリンク集約も自動化され、サイト全体の評価が積み上がる構造を維持できる。
6.1 Topic Cluster地図を「データ」として持つ
内部リンクの半自動化の前提は、Topic Cluster地図を「ドキュメント」ではなく「データ」として持つことである。各記事に対して「Pillarか／Spokeか／Long-tailか」「親Pillarのslug」「関連キーワード」をメタデータで持つ。
このデータがあれば、新規記事公開時に「同じPillarに紐づくSpoke記事」「同じキーワードグループのLong-tail記事」をAIが自動抽出できる。人手は「この候補で正しいか」を確認するだけで済む。
6.2 構造化データで検索評価を補強する
内部リンクと並んで重要なのが、schema.orgの構造化データである。Article、FAQPage、BreadcrumbListの3種類を最低限実装すると、検索結果の表示形式（リッチリザルト）が改善され、AI Overviewでの被引用候補にも入りやすくなる（Google検索セントラル「構造化データ全般のガイドライン」）。
構造化データの生成はAIに振れる工程である。記事公開時にAIで生成し、人手で最終確認する流れを定常化する。
7. 品質を担保するレビュー型：4ステップで設計する
レビュー工程は「人手による全文精読」では月10本でも限界に達する。月数十本ペースに耐えるレビュー型は、4ステップで設計される。
ライターまたはAIドラフト生成プロンプト側に組み込んだ自己点検を最初に通す。見出しの先頭11文字、段落200字以内、出典の有無、用語ルール違反の4項目を機械的にチェック。
ドラフト生成とは別の独立AIエージェントでレビュー。E-E-A-T／Spam Policies／内部リンク／独自性の4軸で自動採点し、改善点をリストアップ。1記事あたり3〜5分で完了。
独立AIレビューの指摘を、ドラフト生成側のAIに戻して自動修正。最大3周まで回し、合格基準（自社rubric.mdに該当）を満たすまで継続。修正のたびに人手は介入しない。
自動修正後の最終ドラフトを編集責任者が10〜15分で精読し、E-E-A-T要件（著者性・一次データ・独自視点）の最終確認とSpam Policies照合を行う。承認後に公開。
7.1 「全文精読を捨てる」決断
レビュー型の最大の転換点は、人手による全文精読を捨てる決断である。全文精読は1記事あたり30〜60分かかり、月本数のボトルネックになる。
代わりに、独立AIエージェントによる自動レビューで品質の8割を担保し、人手最終承認では「AIが見逃す可能性のある軸」（著者性・独自視点・経営判断レベルの主張整合性）だけを10〜15分で確認する設計にする。
7.2 独立AIエージェントの分離が肝
独立AIエージェントは、ドラフト生成側と別プロンプト／別文脈で動かす必要がある。同じAIに「書け」と「レビューしろ」を連続で頼むと、自分の出力に対するレビューが甘くなる傾向が報告されている（Anthropic公式ドキュメント「Multi-agent collaboration」参照）。
別プロンプト・別文脈・別ロールで分離することで、ドラフトの粗を独立した視点で検出できる。これがAI×編集体制の品質担保の核心になる。
自社のwp-factoryでは、writer／reviewerのスクリプトを完全に分離している。reviewerはrubric.mdとlessons.mdだけを参照し、writerのプロンプトには触れない設計。この分離が品質担保の決定要因になる。
8. ツール選定の現実解：単一ツールでは回らない
月数十本ペースの運用は、単一ツールでは回らない。工程ごとに最適なツールを組み合わせる前提で設計する。
| 工程 | 主要ツール | 役割 |
|---|---|---|
| 企画・一次情報収集 | Perplexity／Ahrefs／Google Search Console | キーワード調査、検索意図確定、競合分析 |
| ドラフト生成 | Claude／ChatGPT | 構成案からのドラフト生成、章構造の整理 |
| 独立レビュー | Claude／ChatGPT（writerと別プロンプト） | E-E-A-T／Spam Policies／独自性の自動採点 |
| 最適化 | Surfer SEO／Ahrefs | コンテンツスコア、内部リンク候補抽出 |
| 公開・配信 | WordPress／Next.js／HubSpot | CMS公開、構造化データ生成 |
8.1 ツール単体ではなく「組み合わせ」を設計する
各ツールには得意領域がある。Perplexityは一次情報の収集と出典付きサマリーに強い。Claudeは長文の構造化と論理整合性に強い。Ahrefsはキーワードギャップ分析とバックリンク追跡に強い。Surfer SEOはコンテンツスコアと競合上位記事との比較に強い。
単一ツールで全工程を回そうとすると、必ずどこかで品質が頭打ちになる。工程ごとに最適なツールを当てる「組み合わせ設計」が、月数十本ペースの前提条件になる。
8.2 外部伴走と内製の役割分担
ツール選定と並んで重要なのが、外部伴走と内製の役割分担である。中小企業のマーケ専任2〜3名体制では、ツール選定・初期構築・運用立ち上げの全工程を内製でカバーするのは現実的でない。
外部伴走が初期段階で標準パイプラインの設計を担い、その後は内製で運用を回す形が現実解になることが多い。FULLFACTでは経営・事業診断（D01・1ヶ月）からマーケ基盤構築（B03・3ヶ月）、SEO運用（R05・継続）への移行をこの前提で設計している。
ツール名は経営層への説明で曖昧になりやすい。「ChatGPTを使う」「Claudeに振る」「Perplexityで一次情報を集める」のように、動詞レベルで何をするかを書くと稟議が通りやすい。
9. E-E-A-TとAI生成の折り合い：3要件で担保する
E-E-A-T（Experience／Expertise／Authoritativeness／Trustworthiness）はGoogleが品質評価ガイドラインで明文化した4軸である（Google「General Guidelines」公式PDF）。
AI生成コンテンツでもこの4軸は満たせる。ただし「一次データ／著者プロフィール／独自視点」の3要件を人手で差し込む必要がある。3要件のそれぞれを順に整理する。
記事内に最低1つの自社事例または一次データを差し込む。「自社の運用でN=数社の観察値」「業界レポートのデータ引用」「公開済みの自社案件データ」のいずれかが該当する。E-E-A-T 4要素の中でAI生成で最も埋まりにくい柱であり、人手の差し込み箇所を明示的に確保する設計が必要。
記事末尾に著者名・経歴・専門領域を明示する。著者ページ（/author/）を整備し、各記事から内部リンクを張ると、サイト構造としても評価される。著者表記がない記事は「誰が書いたか分からない」と判定される可能性がある（Google検索セントラル「E-E-A-T」公式説明）。
出典は本文中または節末に明示する。一般論をAIで生成しただけの記事は信頼性の柱が弱い。自社の経営判断レベルの独自視点を最低1つ含めることで、Trustworthinessの評価軸が満たされる。Google公式の品質評価ガイドラインでも、信頼性は最終的に最も重要な軸として位置づけられている。
9.1 Experience（経験）：自社事例または一次データを差し込む
E-E-A-Tの4要素のうち、AI生成で最も埋まりにくいのがExperience（経験）である。AIは一般論を生成できるが、自社の運用観察値や個別案件での経験値は持たない。
つまり、E-E-A-T対策の重心はExperienceに置く。各記事で「自社で観察したN=数社の経験値」「業界レポートのデータ引用」のいずれかを最低1つ含める設計にする。AI出力をそのまま公開すると、ここが空洞になり、E-E-A-Tの最初の柱が崩れる。
9.2 Expertise・Authoritativeness（専門性・権威性）：著者プロフィールを明示
著者プロフィールの明示はゼロコストで実装できる対策である。記事末尾に「執筆：マーケ責任者○○（業界経験X年）」のようにシンプルに添えるだけで、E-E-A-TのExpertise／Authoritativenessの評価が改善する余地が残る。
サイト全体の著者ページ（/author/）を整備し、各記事から著者ページへの内部リンクを張ると、ドメイン全体の権威性の積み上げにも寄与する。著者ページにはSNS、過去登壇、発表論文・著作などの一次根拠を1〜2点添えるのが望ましい。
9.3 Trustworthiness（信頼性）：出典と独自視点を併記
出典付きの統計と、自社の独自視点を組み合わせることで、Trustworthinessの評価軸が満たされる。出典のみだと「一般論の整理」で終わり、独自視点のみだと「裏付けのない主張」と読まれる。両者を併記する設計が肝である。
独自視点は「自社で観察した運用知見」「業界の標準解釈と異なる立場」「事業現場での意思決定基準」のいずれかで成立する。AI出力に独自視点を差し込む工程は、人手最終承認で確保する。
AI生成のみで著者表記なし／独自データなし／著者ページなしの記事は、2024年以降のコアアップデートで順位を落としやすい。E-E-A-Tは「あれば良い」ではなく「ないと評価から外れる」軸として扱う。
10. 失敗事例：量だけ追って評価が落ちる3パターン
AI生成で順位が落ちた事例は、3つの典型パターンに集中する。経営会議で「AI生成は危険か」を議論する前に、この3パターンに自社が該当するかを点検する。
構成案からAIドラフト生成までを自動化し、人手の独自視点・自社事例・一次データを差し込まずに公開した記事群。検索順位は半年〜1年で全体的に下落する傾向がある。Google公式の「Helpful Content System」基準で「人のために作られていない」と判定される。
AI生成→AIレビュー→自動公開のフルオートメーション設計。Spam Policiesの「スケーラブルコンテンツアビューズ」に該当しやすく、March 2024 core updateで順位を大きく落とした事例が複数報告されている（Search Engine Land／Search Engine Journalレポート参照）。
10.1 パターン3：内部リンク孤立（Topic Cluster崩壊）
月数十本ペースで公開した記事が、Topic Cluster地図に紐づけられず、孤立した状態で公開され続けたパターン。各記事のPV・順位は当初取れるが、サイト全体の評価が積み上がらず、半年〜1年で個別記事の順位も連動して落ちる。
Topic Cluster地図の更新が「あとで」になっているサイトでよく起きる。月10本までは人手で追えるが、月数十本に入ると地図の更新が追いつかず、内部リンクの密度が薄くなる構造的な問題である。
3パターンに共通するのは「上流の意思決定品質を下げて下流の本数を稼ぐ」設計である。AI×編集体制の核心は逆で、上流の意思決定品質を上げて下流をAIに振る。順序を間違えると本数も品質も両方崩れる。
10.2 失敗事例から逆算する品質ゲート
3パターンを回避する品質ゲートは、最低限「独自データの差し込み」「人手最終承認」「Topic Cluster地図への登録」の3点である。この3点を抜くと、AI×編集体制ではなく放任AI生成に転落する。
この3点の品質ゲートはチェックリスト化して各記事の公開前に必ず通す。チェックリストは独立AIレビューに組み込み、自動採点する設計が現実的である。
11. 稟議用1ページサマリー：経営判断の3択
「人手量産」「放任AI生成」「AI×編集体制」の3択を、投資根拠・撤退ライン・同規模事例の3点セットで提示する。経営会議で1ページで判断できる粒度に圧縮した。
| 観点 | 人手量産 | 放任AI生成 | AI×編集体制 |
|---|---|---|---|
| 月の目標本数 | 月8〜12本 | 月数十本（品質ブレ） | 月数十本（品質維持） |
| 主要コスト | 人件費（採用・育成） | ツール利用料＋順位下落リスク | ツール利用料＋編集体制構築 |
| 品質担保 | 人手による全文精読 | なし（公開後に問題顕在化） | 独立AIレビュー＋人手最終承認 |
| 立ち上げ期間 | 採用・育成で半年〜1年 | 1〜2ヶ月で立ち上がるが半年で破綻 | 工程標準化で段階的に立ち上げ |
| 検索順位リスク | 低（ただし累積本数で負ける） | 高（Spam Policiesで落ちる） | 中（独自データで担保） |
| 経営層への説明 | 「人を増やす」で稟議が通りやすい | 「AIで効率化」で通すが効果証明困難 | 「品質と本数の両立」で論拠を出せる |
| 撤退ライン | 月本数が9ヶ月停滞したら見直し | 順位下落が3ヶ月続いたら即停止 | 独立レビュー合格率50%未満で見直し |
11.1 投資根拠：本数と商談数の接続を言語化する
AI×編集体制への投資根拠は「本数を倍にする」ではなく「本数と商談数の接続を言語化できる状態を作る」である。本数のKPIだけで稟議を通すと、半年後に「結局商談は増えたのか」で詰められる。
GSCの一次データ（インプレッション・クリック・順位）と、自社CRM（HubSpot等）のリード化率・商談化率を接続し、記事1本あたりのリード貢献を数値で出せる状態を目標に置く。マーケ基盤構築（B03・3ヶ月）でこのKPIツリーの整備から入ることが多い。
11.2 同規模事例：N=数社の経験値で語る
中小企業のSEO運用事例は、業種・規模・スタート地点で大きくばらつく。自社観察値ではN=数社のサンプルで、マーケ専任2〜3名体制から5工程パイプラインを段階的に組み立て、月数十本ペースの公開に到達したケースを確認している。
ただし、この経験値は「どの中小企業でも同じ本数に到達する」という保証ではない。Topic Cluster設計の難易度、業界の競合密度、内製ライターの有無で変数は大きく動く。自社の前提で再評価する必要がある。
稟議の論点は「本数」「コスト」「リスク」の3軸を1枚に並べることで通りやすくなる。「人手量産は安全だが負ける」「放任AI生成は速いが落ちる」「AI×編集体制は中道で論拠を出せる」の整理が、経営層の意思決定の起点になる。
12. 次のアクション：30分でできる自己診断
WPを読み終えた読者が、自社の現在地を30分で診断する10問チェックリストを提示する。診断結果に応じて次の具体的な一手が変わる。
12.1 SEO運用アーキテクチャ自己診断（10問チェックリスト）
- 自社のSEO記事は月何本公開しているか（8本未満／8〜12本／12本超）
- 企画段階でTopic Cluster地図を持っているか（はい／いいえ）
- 検索意図を3分類で確定してから執筆に入っているか（はい／いいえ）
- ドラフト生成はAIで行っているか（はい／いいえ）
- 独立AIエージェントによるレビューを実施しているか（はい／いいえ）
- 各記事に自社事例または一次データを最低1つ含めているか（はい／いいえ）
- 著者プロフィールを記事末尾に明示しているか（はい／いいえ）
- 内部リンクの追加を半自動化しているか（はい／いいえ）
- 構造化データ（Article／FAQPage／BreadcrumbList）を実装しているか（はい／いいえ）
- GSCと自社CRMを接続し、リード化率を記事別に見られるか（はい／いいえ）
12.2 診断結果別の次の一手
「はい」が3個以下なら、まず企画段階のTopic Cluster設計と検索意図確定の標準化から入る。マーケ基盤構築（B03・3ヶ月）でKPIツリーとパイプラインの初期設計を行う領域である。
「はい」が4〜7個なら、独立AIレビューと内部リンクの半自動化が次の打ち手になる。SEO運用（R05・継続）またはオウンドコンテンツ運用（R10・継続）の継続伴走で工程を埋めていく領域である。
「はい」が8個以上なら、E-E-A-T対策の深掘り（著者ページ整備、独自データの公開、構造化データの拡張）と、生成AI検索面（AI Overview）への対応が次の論点になる。LLMO／GEO（R06・継続）の領域に踏み込む段階である。
次のステップ
本WPで提示したAI×編集体制を自社に適用する3階層の入口を用意した。
- 情報継続：上記10問チェックリストで自社の現在地を確定。30分以内に診断結果が出るので、まず社内で共有
- 疑似体験：自社のTopic Clusterに5工程パイプラインを当てはめる初期診断を、SEO運用（R05・継続）またはオウンドコンテンツ運用（R10・継続）の入口として実施
- 直接対話：マーケ単独ではなく営業・CS・バックオフィスを横断した業務全体から再設計するなら、業務診断パッケージ（B01・1ヶ月）で30分の業務棚卸しから開始
「AI×編集体制で月数十本ペースを崩さず回す」運用は、ツール選定でも、プロンプト設計でもなく、経営判断レベルの工程設計から始まる。本WPの整理を稟議書素材として組み立て直していただきたい。