AIでSEO記事の構成を作る方法｜見出し設計の流れ

AIで記事構成を作るとき、検索語だけを渡してH2を並べても、見出しの数だけ整った一般論になりやすくなります。先に検索者が読み終えてできること、判断に必要な材料、本文で独自に提供できる具体物を決め、その後で見出しへ組み立てます。構成の完成条件は見出し一覧ではなく、各節の役割が重複せず、読者の疑問を必要な順番で解消できることです。

はじめに確定するのは読者の到達点

記事を作る前に、次の一文を埋めます。

読者はこの記事を読んだあと、＿＿＿を選ぶ／作る／確認できる。

空欄に「SEOを理解する」のような広い言葉しか入らない場合、検索意図か対象読者を絞ります。たとえば「AIでSEO構成を作る」なら、到達点は「候補見出しを得る」ではなく、「根拠と読者の疑問を満たし、書き始められる構成を選ぶ」です。ここが曖昧だと、AIは説明項目を増やしても作業完了には近づけません。

次に、対象Query、読者、前提知識、利用できる材料、制約を分けて記録します。材料には公式資料、Search Consoleの実績、社内データ、取材や検証結果などが含まれます。まだ確認していない情報は「未確認」と記し、AIに事実として補わせません。

構成に使う材料を4種類に分ける

表は横にスクロールできます

材料	例	Outlineへどう使うか
Reader question	何を選ぶか、どこで失敗するか	回答が必要な節の候補
Evidence	公式仕様、社内記録、観察結果	事実を説明・制限する節
Decision point	AならA、条件Bなら別案	比較表や判断フロー
Unique artifact	入力例、完成例、QA表、手順	記事独自の価値を示す箇所

材料を揃えたら、まず「必須」「差別化」「不要・別ページ向き」の3群へ仕分けます。必須はReader Jobを完了するため欠かせない論点、差別化は自分が根拠を持って追加できる価値、不要は記事の範囲外または他ページのJobです。競合に書かれているというだけで採用せず、読者の到達点に必要かを考えます。

Google Search Centralは、読者の役に立つ独自の情報や分析、十分で信頼できる説明を自己評価するよう案内しています。競合の項目を平均して並べても独自価値にはなりません。何を自分で追加できるかが決まらない場合は、アウトラインを生成する前に情報収集を続けます。

見出しを組み立てる工程

最初に一文回答を置きます。読者が最初に知りたい結論が条件付きなら、条件も短く示します。その後、前提、選択・操作に必要な論点、実例や検証、例外・失敗対応、次の行動のうち、対象記事に必要な順で配置します。すべてを入れる必要はありません。たとえば単純な用語解説に料金比較を足したり、料金ページに一般的なSEO入門を長く置いたりしません。

各候補見出しには「ここで答える問い」を一つ添えます。問いが他の見出しと同じなら統合を検討します。見出しだけを順に読んで、同じ概念を言い換えていないか、結論前に判断材料が揃うかを確認します。H2やH3の固定個数、文字数から逆算した見出し数は使いません。Googleのガイドも見出しを読みやすさとページ構造のために使う考え方を示していますが、特定の見出し数を順位条件として定めてはいません。

AIへ渡すOutline brief

テーマとQueryだけでなく、次の入力を用意します。

Primary Query：

Reader Job：

読者の前提・利用環境：

読み終えたときにできること：

公式資料・確認済みFact：

未確認事項：

自分が追加できる例・データ・手順：

既存記事と重なりそうなJob：

この情報から、必要な見出し案を作ってください。各見出しに「答える質問」「根拠または必要なArtifact」「前節から受け取る情報」「次節へ渡す判断」を付けてください。入力にない事実・体験・数値を追加しないでください。節の数を固定せず、重複候補と範囲外の論点を最後に示してください。

出力をそのまま採用せず、見出しを一つずつ読み、質問と回答がずれていないかを確認します。AIが出した架空のFactや競合にありそうな論点を混ぜず、根拠を確認できる節だけ本文候補にします。

具体例：同じQueryから別構成を選ぶ

「AIで画像を作る」という語でも、検索者が「初めて生成する」なら入力準備と修正手順が中心です。「商用利用できるか」なら利用条件、素材権利、出力の扱いが中心になります。テーマが同じでもReader Jobが違うので、同じ構成へ押し込めません。一方、「プロンプトの書き方」と「画像生成の手順」が同じ一枚の画像を作る作業を説明し、結論・Artifact・次Actionも同じなら、別記事を増やすより一記事内で分けて答える方法があります。

この判断を表に残します。

表は横にスクロールできます

観点	構成案A	構成案B	決定
読者が完了する作業	＿＿＿	＿＿＿	同じ／異なる
必要な根拠	＿＿＿	＿＿＿	共通／別
固有Artifact	＿＿＿	＿＿＿	統合可能／別
次の行動	＿＿＿	＿＿＿	同じ／異なる
既存記事の担当	＿＿＿	＿＿＿	維持／再確認

この表で「異なる」とした箇所には、本文で本当に回答できる差が必要です。Titleの語尾だけが違うなら、別構成の理由としては弱いです。

書き始める前の構成テスト

30秒で確認する

見出しだけを見て、誰のどの問題を解くか、一番大事な答えは何か、独自の具体物は何かが分かるか確認します。分からない場合は構成を短く要約し直し、不要な節を外します。

3分だけ本文を想定して読む

最初の数節で実際に使える判断材料や具体例が得られるか、抽象説明だけが続かないかを見ます。本文を書くときに各節が同じ説明へ戻るなら、問いを分け直します。

Task Completionを確認する

構成の最後から、読者が次に行う作業を一つ述べられるか確認します。操作記事なら実行と成功確認、比較記事なら条件別の選択、料金記事なら契約前に見る項目が必要です。構成だけでは実行できない部分があれば、手順・入力例・チェックリストなどの記事固有Artifactを足します。

構成を組み直すケース別の判断\n\nHow-to記事なら、完成状態を先に示せるか、前提条件を説明する必要があるか、操作後の確認まで必要かを見ます。作業の途中で誤操作が起きると復旧が難しい場合、注意点を該当手順の直前に置き、最後だけにまとめないようにします。比較記事なら、候補名の説明より先に読者が重視する条件を整理し、条件ごとに候補が変わる理由を示します。料金記事なら、無料・有料の境界、対象プラン、地域や更新日などを混同せず、確認できない条件を残します。概念解説なら、用語の一文定義と混同しやすい概念の違いを前半に置き、最後は使う場面の判断へつなげます。\n\n技術記事では、構成にContractやInput/Output、失敗経路、検証方法を含める必要があるかを考えます。これらを「まとめ」へ押し込むと、読者が実行中に必要な情報を見失います。個人情報や権利を扱う記事では、公式条件、例外、未確認事項、利用前ChecklistのどれがReader Jobに必要かを先に分けます。構成の形は記事Typeの名前だけで決まらず、検索者が直面する判断と失敗時の影響で変わります。\n\n## 作成後に戻る条件

AIが作ったOutlineに架空の前提、根拠がない比較、読者が行わない作業が含まれていたら、見出し文を直すだけでは不十分です。まず入力元を確かめ、追加情報を検索するか、その論点を範囲外として外します。公式Sourceが一つの条件しか説明していないのに、Outlineが複数プランの優劣を説明しようとしている場合は、公式条件を追加で調査するか、記事の結論を条件付きに変えます。見出しを埋めるために事実を想像してはいけません。

また、構成を確定してから本文を書き始めても、執筆中に必要な質問が見つかることがあります。その場合は、既存の到達点とArtifactを保ったまま、追加する節がどの問いに答え、どの根拠を必要とするかを設計メモへ戻して確認します。見出しを増やすだけでなく、不要になった節を減らす判断もします。読者の手順が変わる新情報なら構成全体の順序を見直し、補足だけなら該当箇所へ短く加えます。

公開前に残す設計メモ

完成した構成の横に、Primary Query、Reader Job、到達条件、必須Evidence、Unique Artifact、既存ページとの役割、未確認事項、確認日を残します。執筆途中で範囲が広がったとき、このメモが脱線を見つける基準になります。根拠が後から変わった場合も、どの節へ影響するかを追いやすくなります。

構成を作っただけで検索順位や流入増を予測しないでください。Googleの説明は、検索システムに理解されやすくするための一般指針であり、個別ページの掲載順位を約束するものではありません。公開後にSearch Consoleで実際のQueryとPageを観察し、検索者の意図と本文が外れているなら、その差を次の更新に使います。

AIものさしの判断

よいSEO構成は、よくある見出しを揃えたものではなく、読者が到達する順番を設計したものです。Reader Job、根拠、判断点、記事固有Artifactを先に決め、節の問いが重複しないことを確認してから本文へ移ります。記事に必要な見出し数は、そのJobに必要な回答から決まります。