SEO記事の量産は2026年に何が変わったか。工程を入力・処理・出力・確認で切り分け、一次情報を足す

2026年、SEO記事の量産が失う意味とまだ意味がある部分

結論から言うと、記事の本数を増やすこと自体にはもう意味がなく、量産の仕組みは「1本に一次情報を足す時間を作るため」に使うものに変わっています。

検索結果は、クリックされずに終わる割合が増えています。Click Visionの調査では、Google検索でクリックが起きない割合(ゼロクリック)が2024年5月の56%から2025年5月には69%になりました。AI Overviewsが表示される検索では、Ahrefsの2025年の調査で、情報系キーワードの1位のクリック率が7.6%から1.6%に下がっています。Googleが2026年に広げたAIモードでは、PikaSEOの集計でゼロクリックが約93%とされています。日本でも、AI検索の利用率が2026年春の時点で37%に達したという調査があります。

2026年最新 SEO・GEO完全ガイドでも触れられているとおり、AI検索で引用されやすいのは、定義が明確で根拠が確認でき、手順や比較、注意点が整理された記事です。構造化データだけを足しても引用にはつながりません。だからこそ、量産の仕組みは本数を増やすためではなく、工程のつなぎ目を自動化して浮いた時間を一次情報の追加に回すために組み直す、というのが私の考え方です。SEO記事は量産すべき？後悔しないための判断基準が指摘するように、量産するかどうかの判断は記事ごとに分かれて当然で、全部を同じやり方で増やす時代ではなくなっています。

自分のサイトで記事を減らして分かったこと

結論を先に言うと、私は生成AIで記事を増やしていた時期に検索経由の訪問がゼロのままだった経験から、記事を一次情報のある物だけに絞り、位置づけそのものを変えました。

生成AIで下書きを作り、毎週のように記事を増やしていた時期がありました。検索からの訪問は増えず、計測を始めてから数えても検索経由の訪問はゼロのままでした。本数を増やせば検索に拾われるはずだという前提そのものが、自分のサイトでは成り立っていなかったということです。

この結果を受けて、私は記事の本数を減らし、自分の運用で実際に確認できた事実のある記事だけを残しました。記事の役割も変えています。検索で見つけてもらうための記事としてではなく、相談や応募のやり取りの中で、相手に見せる材料として使う位置づけに変えました。記事を読んで検索から来てもらうことを前提にせず、すでに接点のある相手に、自分がどんな仕事をどう進めているかを示す資料として置いている、という状態です。この判断を境に、記事を作るときに優先する順番も変わりました。本数ではなく、1本の中に自社で確認した事実をどれだけ入れられるかを先に考えるようになっています。

SEO記事の5工程を「入力→処理→出力→人の確認」で切り分ける

結論は、キーワード調査・構成・執筆・校正・公開の5工程を、入力・処理・出力・人の確認という同じ型に当てはめて、どこまで機械に任せるかを工程ごとに決めておくことです。

私が案件対応の仕事で回している定時タスクは、案件収集・分類・下書き作成・計測までを、Webの収集、AIでの分類と下書き、LINEのwebhook、Cloudflare Worker、Supabaseを組み合わせてローカルPCの定時タスクで動かしています。公開や送信といった取り返しのつかない操作だけは、人が確認してから進める形にしています。

SEO記事の5工程に同じ型を当てはめると、次のようになります。

キーワード調査は、GSCのデータを入力にして、表示回数とCTRで絞り込む処理までは機械的に行い、出力はCSVなどの次工程にそのまま渡せる形式にします。人の確認は、絞り込んだ候補の中から実際に一次情報を足せる記事かどうかを見る1点に絞ります。
構成は、絞り込んだキーワード候補を入力にして、見出し構成の下書きまでは機械的に作らせます。人の確認は、見出しの並びが読者の疑問の順番と合っているかどうかです。
執筆は、構成を入力にして本文の下書きまでは機械に任せます。人の確認は、自社でしか書けない事実がどの段落に入っているかを見る工程として残します。
校正は、誤字脱字や見出しタグの階層、文字数といった機械的に判定できる項目は自動化し、本文の事実確認だけは人が行います。
公開は、予約時刻やカテゴリ・タグの設定までは自動で埋めてよいものの、公開ボタンを押す操作そのものは人が画面を見てから実行します。

どの工程も、出力の形式を次の工程がそのまま読み込める形にしておくことが前提です。ここが揃っていないと、結局は人がコピペで調整する作業が残り、工程を分けた意味が薄くなります。次の章から、キーワード調査の工程を実際にどう自動化しているかを見ていきます。

実装: GSC APIでCTR改善候補を自動抽出する

結論は、GSCのデータをAPIで取得し、表示回数が多いのにCTRが低いページを機械的に抽出するところから自動化を始めるのが、最も着手しやすいということです。

GSCの画面を毎回開いて目視でCTRの低い行を探す作業は、記事数が増えるほど時間がかかる割に、やっていることは単純な絞り込みに過ぎません。ここをスクリプト化しておけば、次に書く記事や直すべきタイトルの候補を、毎回同じ手順で洗い出せます。

Google Cloud Platformのコンソールで新規プロジェクトを作成し、「Search Console API」を有効化します。プロジェクトを作っただけでAPIの有効化を忘れると、後の実行時に「API has not been used in project」というエラーが出ます。
「OAuth同意画面」を設定します。公開ステータスは「テスト中」のままで構いませんが、自分のGoogleアカウントを「テストユーザー」として追加しておく必要があります。これを飛ばすと、認証画面で「このアプリは確認されていません」の先に進めず、認証そのものが止まります。
認証情報の作成画面で「OAuthクライアントID」を選び、アプリケーションの種類は「デスクトップアプリ」を選びます。「ウェブアプリケーション」を選ぶと、後述のローカル認証フローが動かないので、種類の選択を間違えないようにします。
作成されたクライアントIDのJSONをダウンロードし、ファイル名をcredentials.jsonとしてスクリプトと同じフォルダに置きます。
Pythonの実行環境で必要なライブラリをインストールします。

pip install google-auth google-auth-oauthlib google-auth-httplib2 google-api-python-client pandas

GSCの検索パフォーマンスデータを取得するスクリプトを用意します。SITE_URLは、GSCに登録してあるプロパティのURLと完全に一致させる必要があります。末尾のスラッシュの有無が違うだけでも、該当サイトが見つからずデータが0件で返ってきます。

import pandas as pd
from google_auth_oauthlib.flow import InstalledAppFlow
from googleapiclient.discovery import build

SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SITE_URL = 'https://example.com/'  # GSCに登録したプロパティと完全一致させる
START_DATE = '2025-01-01'
END_DATE = '2025-03-31'

def get_service():
    flow = InstalledAppFlow.from_client_secrets_file('credentials.json', SCOPES)
    creds = flow.run_local_server(port=0)
    return build('searchconsole', 'v1', credentials=creds)

def fetch_data(service):
    body = {
        'startDate': START_DATE,
        'endDate': END_DATE,
        'dimensions': ['page', 'query'],
        'rowLimit': 5000
    }
    res = service.searchanalytics().query(siteUrl=SITE_URL, body=body).execute()
    rows = res.get('rows', [])
    records = []
    for row in rows:
        page, query = row['keys']
        records.append({
            'page': page,
            'query': query,
            'clicks': row['clicks'],
            'impressions': row['impressions'],
            'ctr': round(row['ctr'] * 100, 2),
            'position': round(row['position'], 1)
        })
    return pd.DataFrame(records)

if __name__ == '__main__':
    service = get_service()
    df = fetch_data(service)
    df.to_csv('gsc_report.csv', index=False, encoding='utf-8-sig')
    print(f"出力完了: {len(df)}件 -> gsc_report.csv")

初回実行時はブラウザが自動で開き、Googleアカウントでのログインと権限の許可を求められます。先にテストユーザーの登録を済ませていないと、許可画面にたどり着けません。許可が済むとtoken.jsonのようなキャッシュファイルが作られ、2回目以降は自動で認証されます。
実行後に生成されたgsc_report.csvを開き、impressionsが多いのにctrが低い行を確認します。Excelで並べ替えるだけでも構いませんが、次の工程に渡す前提なら、Pandasで表示回数の上位かつCTRの下位を抽出するフィルタ処理を足しておくと、毎回同じ基準で候補を絞り込めます。

私の運用では、サイトはCloudflare Pagesで公開し、こうした定時の取得処理はWindowsのタスクスケジューラとPythonで動かし、データはSupabaseに貯めています。GSCから抽出したCTR改善候補も、このフローに乗せれば、タイトル改善の検討リストとして定期的に手元に届く状態を作れます。

抽出した候補を構成・執筆の工程に渡すところまでやる

結論は、gsc_report.csvから絞り込んだ候補を、次の構成案作成にそのまま渡せる形式で出力し、そこから先を人が判断する工程として明確に残すことです。前章の抽出だけで止めてしまうと、結局は候補の一覧を見ながら人が手でExcelをいじる作業に戻ってしまいます。

前章のスクリプトに続けて、次のようなフィルタ処理を足します。

import pandas as pd

df = pd.read_csv('gsc_report.csv')

# 表示回数が多いのにCTRが低いページを抽出する目安
candidates = df[(df['impressions'] >= 100) & (df['ctr'] <= 2.0)]
candidates = candidates.sort_values('impressions', ascending=False)

candidates.to_csv('ctr_candidates.csv', index=False, encoding='utf-8-sig')
print(f"候補 {len(candidates)}件 -> ctr_candidates.csv")

ここで出すctr_candidates.csvの列は、page・query・impressions・ctr・positionのままにしておき、次の構成作成の工程がこの列名をそのまま読み込む前提で揃えておきます。列名をその都度変えると、結局は構成作成のたびに列を探す作業が発生し、つなぎ目が切れます。

このctr_candidates.csvを開いたあとに人が見るべき判断は1つで済みます。それは「このページ・このクエリに、自社で確認した一次情報を足せるか」です。impressionsが多くCTRが低いページでも、足せる一次情報が手元にない場合は、構成を作り直すより先に、その事実を自分で確認できるかどうかを検討します。確認できる見込みがない候補は、リストから外して次の候補に進むほうが時間を無駄にしません。人が見るのはこの1点に絞り、候補の優先順位付けや表の並べ替えまでは機械の処理に任せておくのが、工程を途切れさせない組み方です。

非公式サイトのスクレイピングに依存させない理由と代わりの手

結論は、ラッコキーワードのような非公式サービスへの依存を避け、GSCの公式APIを軸にしたうえで、手元の非構造なメモはAI転記ツールで構造化してから処理に渡すことです。

非公式のWebサービスを自動でスクレイピングする構成は、今の時点では積極的には勧めません。サイト側のHTML構造が変わったり、アクセス制限がかかったりすると、スクリプトがそのまま止まるからです。私が運用している定時タスクの中にも、公式のAPIが提供されていないサイトの情報を取得する処理が含まれており、構造変更やアクセスブロックで止まった経験があります。止まるたびに該当箇所だけを手直しして復旧させる必要があり、記事を出すたびに必ず使うキーワード調査の処理をこの形に依存させると、止まったタイミングで記事制作全体が遅れる原因になります。

代わりに、次の2つを組み合わせています。

キーワードの候補出しは、前章で紹介したGSCのデータを軸にします。自社サイトで実際に検索されているクエリなので、公式APIから取れ、構造変更やブロックの心配がありません。
手元にあるキーワード候補のメモや、競合調査で控えた単語の一覧がPDFやスクリーンショットの形で残っているなら、それをAI転記ツールでCSVやTSVに変換してから、Pythonの処理にそのまま渡します。私が公開しているAI転記ツールは、請求書や領収書、名簿のPDF・写真から項目と明細を取り出してCSVやTSVにする用途で作ったもので、ファイルは保存しない作りにしています。手元にある非構造のデータをAIで読み取って構造化データに変換するという仕組みは、キーワード候補のメモを構造化する用途にもそのまま使えます。

非公式スクレイピングを完全に否定するわけではありませんが、月5〜10本という記事数であれば、毎回の調査を止まりやすい仕組みに依存させるより、公式APIと手元メモの転記という止まりにくい2つの経路を組み合わせたほうが、結果として安定して回ります。

公開前に人が見る場所を決めておく

結論は、公開や送信といった取り返しのつかない操作の直前だけ、人が確認する線を引いておくことです。2026年10月のガイダンスで、題名・説明文・構造化データ・画像の代替文まで公開前に事実確認するという文言が加わったことを踏まえると、この線引きはSEO記事でも同じように必要になります。

私がほかの自動化案件で採っている線引きも同じ考え方です。登録した内容だけをもとに答え、答えられない質問は担当者に回す問い合わせの自動返答は、受け答えの生成そのものは自動化していますが、初めて登録する内容は人が確認してから登録する作りにしています。

これをSEO記事の制作フローに当てはめると、次の工程に人の確認を置くことになります。

誤字脱字のチェックと、見出しタグの階層(H2のあとにH3が続いているかなど)の整合性チェックは、ルールが明確なので自動化してよい工程です。機械がチェックリストを出力し、人はその結果の一覧だけを確認します。
タイトル・メタディスクリプションの文字数、内部リンクの有無も、基準が数値や有無で判定できるため自動化してよい工程です。ただし、リンク先が文脈に合っているかどうかの判断は人の確認に残します。
本文の事実確認、特に独自の経験や自社の実測値を書いた部分の裏取りは、人が確認する工程として残します。AIが生成した文章はもっともらしい誤りを含むことがあるため、ここを飛ばして公開設定に進まないようにします。構造化データや画像の代替文の内容が本文の事実と食い違っていないかも、この工程で合わせて見ます。
公開ボタンを押す操作そのものは、最後に人が画面を見て実行します。予約投稿の時刻やカテゴリ・タグの設定は自動で埋めておいてよいですが、実行の最終トリガーは人の手に残すことで、誤った内容がそのまま公開される事故を防ぎます。

全部を自動化しようとすると、確認が甘くなった箇所から事故が起きます。どこを自動化し、どこを人の確認として残すかを工程ごとに先に決めておくことが、安定して回し続けるための分かれ目になります。

この型は他の定型業務にもそのまま使える

結論は、「入力→処理→出力→人の確認」という型は、SEO記事に限らず定型的に繰り返す業務であれば、そのまま当てはめられるということです。

私が回している他の定時タスクでも、同じ型を使っています。日本株の監視ボードであるfunnel.gpirot.comは、毎営業日、収集から採点・公開までを無人で動かしています。ここでは最終判断そのものを読者側に委ねる設計にしており、無人で回せる範囲と人に委ねる範囲を分けている点はSEO記事の工程と同じ考え方です。

サンプルとして公開している自動化の見本も、同じ構造でできています。シフト表から出勤簿や休出・有休の申請書を埋め、転記ミスを検算する出勤簿・申請書のサンプル、現場別の費用明細から見積書と請求予定を作り、合計の一致を自動で確かめる見積・請求予定のサンプルは、どちらも自分の表を貼って試せるようにしてあります。入力の形式が整っていれば処理と出力は機械に任せられ、最終的な数字の一致確認や提出の判断だけを人が担う、という点は共通しています。

自分の定型業務にこの型を当てはめる場合は、まず自分が繰り返している作業を一つ選び、どこまでが入力の受け取り、どこからが機械的な処理、どこで出力の形式を次の工程に合わせ、どの操作の直前に人の確認を置くかを、紙に書き出すところから始めるとよいと考えています。

業務自動化 API連携 Python 個人開発 Supabase