【PR】この記事には広告リンクが含まれています。
ブログの公開予定を30本並べても、各記事の中身が一般論だけなら、同じテーマの要約記事が増えるだけです。企画段階で必要なのは、検索ボリューム順に題名を並べることではなく、自分が実際に行ったこと、確認できる数字、迷った判断、現在の公式情報を、読者の具体的な疑問へ結び付けることです。
運営者は、ブログ1本目を約7,800字で公開した後、エックスサーバーとSWELLの実運用、WordPress下書き・アイキャッチ設定の自動化、Apps ScriptからWordPressへの公開を経験しました。ART-007の自動公開ではWordPress投稿ID41が発行され、成功1件・失敗0件を確認しています。一方で、品質ゲートに一度止められ、実体験IDの紐付けを直して再実行した経験もあります。この記事では、その事実をばらばらの思い出にせず、30本規模の企画へ変える手順を説明します。
結論：キーワードより先に実体験の部品を棚卸しする
企画の起点は「何を書けば検索されるか」だけではありません。最初に実体験を、出来事、数字、判断、本音、証拠、公開可否へ分解します。その後で、読者が検索する言葉と結び付けます。この順番なら、体験していないサービスを使ったように書いたり、競合記事の言い換えだけで本文を埋めたりする危険を減らせます。
- 実体験IDを全記事の共通キーにする
- 数字は出典と確認日を持つ
- 検索意図を一つの行動へ絞る
- 同じ体験でも切り口を変え、役割を重複させない
- 収益導線は提携済み・リンク取得済みだけを採用する
- 公開済み記事との内部リンク関係を先に決める
実体験DBに入れる6つの項目
1. 何をしたか
「ブログを運営した」では広すぎます。「初めて記事を公開した」「WordPressの非公開下書きを自動作成した」「公開後にstatusとURLを再取得した」のように、一つの行動へ分けます。行動が小さいほど、検索意図と対応させやすくなります。
同じ自動化でも、記事候補の選定、本文生成、品質ゲート、メディア登録、公開、再取得、エラー復旧は別の経験です。一つの巨大な体験として登録すると、どの事実がどの記事を支えるのか分からなくなります。
2. 確認できる数字
数字は印象を具体化しますが、最も誤りやすい部分でもあります。運営者の確認済み事実には、最初の記事が約7,800字だったこと、ART-007のWordPress投稿IDが41だったこと、処理結果が成功1件・失敗0件だったこと、週次処理の上限を4本にしたことがあります。これらは対応する実行ログや会話記録へ紐付けます。
逆に、執筆時間、売上、検索順位、成約率などを記録していないなら、もっともらしい数字を補いません。「短時間でできた」「多くのアクセスがあった」とも書かず、確認できる行動だけに戻します。
3. 迷った点と判断理由
失敗や迷いは、読者が検索する疑問へ直結します。品質ゲートで止まった、本文の注意書きが未解決マーカーと誤認された、公開処理の終了と4本公開の達成を分ける必要があった、といった判断は、単なる操作手順より独自性があります。
判断理由には、当時見えていた選択肢も残します。ただし、採用しなかった方法を使った体験のように書きません。「検討した」「採用しなかった」「実運用では未確認」を区別すると、誤解を防げます。
4. 証拠と検証状態
実行ログ、WordPress投稿記録、給与明細PDF、公式ページ、会話記録など、事実を確認できる場所を登録します。証拠があるだけでなく、「事実確認済み」「使用可」「要再確認」の状態を分けます。公開できない個人情報が含まれる資料は、本文へ貼らず、必要な事実だけを抽出します。
本人の氏名フル、家族の氏名、自宅住所や市区町村など、居住地を特定できる情報は企画段階で除外します。会社名の合同会社ArcStoryは公開できますが、個人の居住情報は必要に応じて東北地方などへぼかします。
5. 公開できる範囲
実体験には、公開可、条件付きで公開可、非公開があります。認証情報、アプリケーションパスワード、銀行口座番号、家族の個人情報は公開しません。操作画面のスクリーンショットも、名前や残高、IDが映る場合はそのまま使えません。
記事で必要なのは秘密情報そのものではなく、読者が再現できる判断の順序です。画面のどこを見たか、何を照合したか、どの状態なら止めたかを文章へ落とします。
6. 使える検索テーマ
一つの体験から複数のキーワードが生まれる場合があります。たとえばWordPress自動公開なら、GAS連携、REST API認証、複数記事の失敗分離、公開後確認、slug重複防止、5xx再試行などです。ただし、全部を一記事へ詰め込むと検索意図がぼやけます。
体験レコードには候補キーワードを複数持たせ、記事側では主要キーワードを一つに絞ります。補助キーワードは見出しの役割を持つものだけに限定します。
30本へ展開する5段階
段階1：実体験を一覧化する
最初に記事タイトルを考えず、実体験を時系列と分野別に並べます。会社設立、給与、社会保険、口座、会計、WordPress、広告、アクセス解析のように分類し、事実と感想を別の列にします。分類は読者向けカテゴリではなく、事実を探しやすくするための内部整理です。
経験が少ない分野を無理に30本へ引き伸ばしません。事実の密度が高い分野から企画し、薄いテーマは保留します。30本は公開ノルマではなく、向こう数か月の選択肢です。
段階2：検索意図を行動で書く
検索意図は「知りたい」だけで終わらせず、「何を判断し、何を実行したいか」まで書きます。「GAS WordPress 複数記事」なら、コードを知りたいではなく、1記事の失敗で残りを止めず二重投稿を避けたい、という行動にします。
この一文がタイトル、導入、結論、CTAの基準になります。複数の行動が入ったら記事を分ける候補です。
段階3：競合と公式情報の役割を分ける
競合記事は、読者が期待する論点、見出し、説明の不足を把握するために使います。事実の正本にはしません。仕様、制度、価格、画面操作は、公式サイトや公的機関で確認します。競合に書かれている数字をそのまま実体験へ混ぜないことが重要です。
Google Search Centralは、人の役に立つこと、直接経験や深い知識を示すこと、他の情報の単純な要約で終わらないことを自己評価項目として案内しています。これは「体験を書けば上位表示する」という保証ではなく、企画の品質を点検する基準です。
段階4：既存記事との差を一文で固定する
新しい企画ごとに、既公開記事と何が違うかを一文で記録します。本記事は、週4本運用の自動化を扱う記事ではなく、実体験DBから30本の候補を作る選定方法に限定しています。品質ゲートの記事とも、公開前検査ではなく企画前の材料整理で分けています。
差を説明できない企画は、既存記事へ追記する方がよい場合があります。新規記事にする理由をタイトルの言い換えではなく、読者の別の行動で示します。
段階5：収益導線と内部リンクを後付けしない
記事を作ってから広告を探すと、本文と関係の薄いCTAが入りやすくなります。企画時に、読者が次に必要とするサービスがあるか、提携済みか、リンク取得済みかを確認します。条件を満たさない案件は広告として置きません。
内部リンクも同じです。リンク先が公開済みで、読者の次の疑問へ答える場合だけ入れます。同じ週に公開予定の未公開URLは使いません。
優先順位を決める採点表
候補が30本できたら、感覚だけで公開順を決めません。実体験の強さ、検索意図の明確さ、一次情報の確認可能性、既存記事との差、収益導線、内部リンクの受け皿を点検します。得点は絶対的な検索需要ではなく、自分のサイトで安全に公開できる順番を決めるために使います。
- 実体験が事実確認済み・使用可か
- 主要キーワードと検索意図が一対一か
- 現行の一次情報へ到達できるか
- 同じslugや同じ結論の記事がないか
- 提携済み案件または自然な非広告導線があるか
- 公開済み内部リンクを2〜3本設定できるか
- 個人情報や未確認の数値を含まずに完成できるか
必須条件が一つでも欠ける記事は、点数が高くても公開キューへ入れません。調査待ち、実体験追加待ち、案件待ちを区別し、次に何を確認すれば進めるかを記録します。
記事ブリーフへ渡す内容
選定後は、タイトル、主要キーワード、検索意図、使用する実体験ID、使える数字、避ける表現、一次情報要件、ASP候補、内部リンク、カニバリ説明を一枚へまとめます。本文担当が変わっても、体験の境界を越えないためです。
特に「避ける表現」が重要です。成功率、収益、順位、作業時間など、記録がない成果を先に禁止します。事実関係が薄い部分を一般論で水増しせず、公式情報と運用判断の違いを明示します。
公開前に止める条件
企画が良くても、本文で体験表現と根拠がずれることがあります。一人称または運営者の行動を示す文に数字がある場合、対応する実体験レコードを確認します。根拠がなければ、数字を削るか、公式情報の文脈へ書き換えます。
- 未解決のメモや仮のURLが残っている
- 公式ページが404または410
- 広告リンクにsponsored nofollowがない
- 計測ピクセルが欠けている
- 内部リンク先が未公開
- 記事タイトルとslugが既存記事と重複する
- 本文が実体験DBにない成果を断定する
- 個人や家族を特定できる情報がある
実運用で30本を維持する方法
公開するたびに候補を4本減らすだけでは、計画が短期間で空になります。週次で、実体験DBの新規行、公開済み記事の派生疑問、GSCで見つかったクエリ、公式仕様の更新を確認し、30本前後へ補充します。ただし、数合わせの企画は追加しません。
公開済み記事は候補一覧から削除せず、公開済みとして残します。重複判定と内部リンク候補に必要だからです。企画、原稿、公開、評価を同じ記事IDでつなぐと、タイトル変更やリライトをしても履歴を追えます。
よくある失敗
検索ボリュームだけで選ぶ
需要がありそうでも、自分の事実がなければ一般論の再編集になります。体験がないテーマは、公式情報を解説する別タイプとして扱うか、公開を見送ります。
一つの体験を薄く分割する
タイトルを変えただけの記事が増えると、同じ検索意図を奪い合います。各記事の読者の行動、結論、内部リンク上の役割が違うかを確認します。
体験と公式仕様を混ぜる
運営者が実際に行った操作と、公式ページで確認した現行仕様を段落で分けます。利用画面が同じだったとしても、他の契約や時期にも必ず同じとは断定しません。
文字数を目標に一般論を足す
Googleは推奨文字数があるという考え方を否定しています。本サイトの8,000〜10,000字は内部の品質目安であり、検索順位の条件ではありません。読者の判断に必要な説明を揃えた結果として長さを確保します。
今すぐ作る実体験企画シート
- 実体験を一行一行動で10件登録する
- 各行へ証拠、検証状態、公開可否を付ける
- 検索意図を『何を判断・実行したいか』で書く
- 既公開記事との差を一文にする
- 一次情報、収益導線、内部リンクを確認する
- 必須条件を満たす順に並べ、30本前後まで補充する
この順番なら、先にタイトルだけを大量生成するより、事実のある企画を残しやすくなります。実体験が追加されたら、既存の候補へ紐付けるか、新しい検索意図へ分けます。
関連記事
公開工程全体はひとり社長ブログを週4本運用する自動化設計、公開前の停止条件はWordPress自動投稿の品質ゲート設計、AIと人の役割分担はAIとApps Scriptでブログを自動化する品質設計で詳しく整理しています。
実務補足：企画を原稿へ渡す前のレビュー
タイトルだけで体験の所在が分かるか
タイトルを読んだとき、誰のどの経験が中心なのかを編集者が説明できる状態にします。「おすすめ」「完全版」「徹底解説」のような抽象語では、体験の根拠が見えません。使用するサービス、行った作業、失敗や判断の対象を具体化し、本文に存在しない成果をタイトルへ入れないようにします。
一方で、実体験の細部をすべてタイトルへ詰め込みません。検索者が最初に解決したい問いを前半へ置き、会社の条件や実例は補助語として使います。長いタイトルを作った後は、同じ意味の語が重複していないか、検索結果の小さな表示でも主題が伝わるかを確認します。
導入文で約束する範囲を狭める
導入では、この記事で分かること、実体験として確認した範囲、読者によって変わる条件を短く示します。本文で触れない論点を並べると、読者は答えを探して最後まで行き来することになります。記事ブリーフの検索意図と見出しを照合し、約束した答えが結論にあるか確認します。
公的制度や製品仕様を扱う場合は、確認日を明示します。確認日は運営者の体験日とは別です。過去の経験を現在も同じ仕様だったように見せず、「当時行ったこと」と「現在の公式情報」を段落や見出しで分けます。
見出しごとに根拠の種類を決める
各見出しを、実体験、公式仕様、判断方法、注意点、手順のどれに分類します。実体験の見出しにはEXP ID、公式仕様の見出しには確認済みURL、判断方法には両者の関係を置きます。根拠が空の見出しは一般論だけになりやすいため、削除するか調査待ちへ戻します。
一つの段落で複数の根拠を混ぜると、どこまでが本人の経験なのか分からなくなります。「実際に確認した」「公式では案内されている」「この条件から判断した」を書き分けます。
数字の監査表を作る
本文に出る数字を抽出し、体験値、公式値、日付、記事構造上の番号に分けます。体験値は実体験DB、公式値は一次情報、日付は検証日、番号は単なる手順番号として扱います。数字の周辺に一人称や運営者の行動がある場合、対応する根拠があるかを重点確認します。
料金や制度の数値は変更される可能性が高いため、執筆時点の公式ページを確認します。固定値を載せる必要が薄い場合は、公式ページへ誘導し、記事内では判断軸を説明します。
競合との差を本文へ反映する
カニバリ説明を管理表へ書くだけでは足りません。既存記事が全体像を扱うなら、新記事は一つの工程や判断へ絞り、導入と結論でもその違いを示します。読者が両方読む理由がなければ、統合や追記を検討します。
競合との差は、情報量ではなく根拠や対象条件でも作れます。一般的な手順に対し、ひとり会社で実際に止まった箇所、確認した帳票、公開後に再取得した項目など、他の人が再現できる具体性を追加します。
収益記事と集客記事をつなぐ
すべての記事へ広告を入れる必要はありません。検索者がサービス比較や申込みに進む記事と、問題の原因を調べる記事では、CTAの役割が違います。広告が自然でない記事は、関連する収益記事への内部リンクを置き、読者の次の行動を助けます。
提携状況、リンク取得、飛び先、rel属性、計測要素を公開前に確認します。未提携案件を別の広告URLで代用しません。収益導線が未完成でも、読者の役に立つ記事なら通常リンクだけで公開する判断も持ちます。
公開順で内部リンクを設計する
記事同士の関係を先に決めても、リンク先が未公開なら本文へ入れられません。公開済み記事からリンクを選び、同じ週の記事同士は公開後の追加候補として管理します。最初の記事に将来URLを仮置きすると、リンク切れや誤slugの原因になります。
ハブ記事、詳細記事、収益記事の役割を持たせ、片方向だけでなく読者が戻れる導線を考えます。ただし、関連性の薄いリンクを数合わせで増やしません。
保留理由を次の作業へ変える
企画を保留するときは「情報不足」だけで終わらせず、必要な実体験、確認する公式URL、案件の提携状態、内部リンク先の公開予定などを記録します。次回の週次確認で、条件が満たされた候補だけを再評価できます。
事実関係が確定できない企画は、埋め合わせとして別の推測を足しません。使用可能な実体験がある別候補を繰り上げ、保留記事は正本の管理表へ残します。
公開後のクエリを次の企画へ戻す
公開後にSearch Consoleで見つかったクエリは、新規記事の種になります。ただし、既存記事へ追記すれば答えられる問いか、別の検索意図として独立すべきかを確認します。表示回数だけで記事を量産せず、実体験DBと一次情報が揃うものだけを候補にします。
この循環により、企画は最初の30本で固定されません。公開、評価、体験追加、公式更新を受けて入れ替わり、常に現実的な候補が残ります。
企画会議の記録を残す
候補を採用した理由だけでなく、見送った理由も残します。実体験が弱い、公式情報が確認できない、既存記事と検索意図が同じ、広告導線が不自然など、判断の根拠を短く記録します。後から状況が変わったとき、ゼロから検討し直さずに済みます。
候補の並べ替えでは、更新日時と評価者を残します。自動採点の結果だけを最終決定にせず、体験の公開可否と読者への価値を確認します。
記事IDを途中で変えない
タイトルや主要キーワードを調整しても、同じ企画の履歴を追うなら記事IDを維持します。企画、ブリーフ、原稿、WordPress投稿、GSC、リライト判定を同じIDで結び、別タイトルになっただけで新しい記事として数えません。
企画そのものを分割する場合は、新旧IDの関係と分割理由を記録します。既存のslugや公開URLがある記事を新規作成へ戻しません。
読者が実行できる終点を決める
記事の最後に、読者が次に行う一つの作業を置きます。設定画面を開く、通知書を照合する、公開状態を再取得するなど、検索意図と一致する行動です。単にサービス申込みだけを終点にせず、記事で学んだ判断を使える形にします。
この終点から逆算すると、本文に必要な説明と不要な一般論を分けやすくなります。
公開後の確認項目も終点から決めます。読者に操作を促す記事ならリンク先と画面、判断を助ける記事なら前提条件と例外、比較記事なら選択基準を重点確認します。企画時の約束と公開後の検査がつながることで、タイトルだけ魅力的で本文が追いつかない状態を防げます。
企画を承認した時点で、使用する実体験ID、公式情報の確認日、避ける表現を固定します。原稿の途中で新しい体験を加える場合は、先に実体験DBへ登録し、事実確認と公開可否を終えてから本文へ反映します。
ブログ運用の土台を整える
記事企画や評価を仕組みにしても、公開先のWordPressが安定して動かなければ運用は止まります。運営者が実際に利用しているエックスサーバーの現行プランや仕様は、申込み前に公式ページで確認してください。
確認した公式情報
仕様や画面は変わる可能性があるため、2026年9月26日に次の現行ページを確認しました。
- Google Search Central：有用で信頼性の高いユーザー第一のコンテンツ作成
- Google Search Central：SEOスターターガイド
- WordPress公式：Posts REST API
まとめ
実体験から30本を企画する要点は、数を先に埋めることではありません。行動、数字、判断、証拠、公開可否を実体験DBへ登録し、検索意図、一次情報、カニバリ、収益導線、内部リンクと照合します。
運営者自身も、最初の記事公開、WordPress自動化、品質ゲート停止と復旧という異なる経験を、別の検索意図へ分けてきました。確認できる事実を中心に企画すれば、一般論の言い換えを避けながら、公開後も記事IDで評価と改善を続けられます。
