このページでは、AIブログ実験室で実際に使っているCodex向けのブログ運営プロンプトを公開します。「Codex ブログ プロンプト」を探している人が、そのまま自分のブログ運営に使えるように、指示文、想定入力、実際の出力例までまとめています。
ここで紹介するのは、きれいに整えた理想論ではなく、私がこのブログを作るときに使っている指示文です。記事構成を作るとき、下書きを作るとき、公開後に内部リンクを直すとき、Search ConsoleやSite Kitの数字を見て月次レポートにまとめるときなど、実際の運用で使う前提で整理しています。
AIにブログ作業を任せると、たしかに作業は早くなります。ただし、何も考えずに「記事を書いて」と頼むだけでは、どこにでもある薄い記事になりやすいです。だからこのブログでは、Codexを「記事を量産する道具」としてではなく、「ブログ運営の判断を整理する相棒」として使っています。
このページの目的は、プロンプトをコピペして終わることではありません。読者が、自分のブログでも使えるように、どんな入力を渡すか、どんな出力を期待するか、失敗しやすいところをどう避けるかまでセットで見せることです。
目次：Codex ブログ プロンプト7種類
このページでは、ブログ運営で使うCodex ブログ プロンプトを次の7カテゴリに分けて掲載します。
- 記事構成案を作る
- 下書き生成
- リライト
- 内部リンク提案
- X投稿案
- 月次レポート生成
- メタディスクリプション最適化
どのプロンプトも、AIブログ実験室の運営ルールに合わせています。特に、体験談、実データ、公開前の人間確認を重視しています。
使う前に決めておくこと
プロンプトを使う前に、最低限次の情報を決めておくと、出力の質が安定します。
| 決めること | なぜ必要か |
|---|---|
| 想定読者 | 誰に向けた記事かが曖昧だと、一般論になりやすい |
| 狙うキーワード | 見出しやタイトルの軸がぶれにくくなる |
| 記事の役割 | 集客記事、収益記事、運営レポートなどの目的を分けられる |
| 一次情報 | 自分の作業ログ、スクリーンショット、計測値があると独自性が出る |
| 公開済み記事 | 内部リンク先を間違えにくくなる |
| 人間が確認する範囲 | AIに任せすぎる事故を防げる |
AIに渡す情報が少ないほど、AIは一般論で補おうとします。ブログ運営で本当に大事なのは、AIが書いた文章そのものより、AIに渡す材料をどこまで具体化できるかです。
1. 記事構成案を作るプロンプト
最初に使うのは、記事構成案を作るプロンプトです。
この段階では、本文を書かせるよりも、想定読者、検索意図、記事の役割、内部リンク候補を整理することを優先します。いきなり本文を作ると、見出しの順番が弱かったり、既存記事との役割が重複したりしやすいためです。
プロンプト本文
あなたはプロブロガー兼SEO編集者です。
以下の条件で、ブログ記事の設計書を作ってください。
【ブログの前提】
- サイト名：AIブログ実験室
- テーマ：AI・Codexを使ったブログ運営と副業自動化
- 目的：Codexを活用して個人ブログを月3万円まで育てる実験記録
- 方針：読者の悩み解決、一次情報、実験ログ、公開前の人間確認を重視する
【作りたい記事】
- 記事タイトル案：
- 狙うキーワード：
- 関連キーワード：
- カテゴリ：
- 想定読者：
- 既存記事との関係：
- 使える一次情報：
【出力してほしい内容】
1. 記事タイトル
2. スラッグ案
3. カテゴリ
4. 狙うキーワード
5. 関連キーワード
6. 想定読者
7. 検索意図
8. この記事の結論
9. 記事の役割
10. 収益導線
11. 内部リンク候補
12. 参考にすべき公式情報
13. 見出し案
14. 本文で入れる判断基準
15. スクリーンショット活用案
16. SWELL装飾方針
17. メタタイトル案
18. メタディスクリプション案
19. 公開前チェック
【制約】
- 根拠のない断定をしない
- 収益や検索順位を保証しない
- 未公開記事へリンクしない
- 実体験や作業ログを入れられる構成にする
- 初心者にもわかる言葉で書く想定入力
16記事目の設計では、次のような入力を渡しました。
記事タイトル案：
ブログ記事をいつリライトするか
狙うキーワード：
ブログ リライト タイミング
カテゴリ：
WordPress・SEO
想定読者：
ブログ記事を公開したあと、いつ直せばよいかわからない初心者。
Search ConsoleやAnalyticsの数字を見ても、リライト判断に使えていない人。
既存記事との関係：
12記事目のSearch Console数字解説、14記事目のAnalytics確認、15記事目のX投稿案作成を受けて、公開後の情報を記事改善に変える記事にしたい。
使える一次情報：
15記事公開後のSite Kit実測値、Search Console表示回数0、6記事目の内部リンク修正、アイキャッチ重複修正、トップページ導線修正。実際の出力例
実際に16記事目の設計書では、次のような出力になりました。
記事タイトル：
ブログ記事をいつリライトするか｜Search Console・Analytics・X反応から判断する方法
スラッグ：
blog-rewrite-timing-after-publish
カテゴリ：
WordPress・SEO
狙うキーワード：
ブログ リライト タイミング
想定読者：
- ブログ記事を公開したあと、いつ直せばよいかわからない初心者
- Search ConsoleやAnalyticsの数字を見ても、リライト判断に使えていない人
- 公開直後に焦って何度も記事を書き換えてしまう人
この記事の結論：
ブログ記事のリライトは、公開直後にすぐ直すものと、数日から数週間待って数字を見てから直すものに分ける。
記事の役割：
12記事目のSearch Console数字解説、14記事目のAnalytics確認、15記事目のX投稿案作成を受けて、公開後の情報を「記事改善」に変えるための記事にする。この出力があると、本文を書く前に「この記事は何のために書くのか」がはっきりします。特に、既存記事との関係を先に決めると、同じ内容を何度も書くことを避けやすくなります。
失敗パターンと回避策
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| キーワードだけ渡す | 競合記事のような一般論になる | 想定読者と使える一次情報も渡す |
| 既存記事を渡さない | すでに書いた記事と内容が重複する | data/articles.csv の公開済み記事を渡す |
| 収益導線だけ先に決める | 読者の悩みより売り込みが強くなる | まず悩みと検索意図を整理する |
| 見出しだけ作らせる | 記事の役割が弱くなる | 結論、内部リンク、公開前チェックまで出させる |
関連記事
2. 下書き生成プロンプト
記事構成案ができたら、次に下書きを作ります。
ここで大事なのは、AIに「完成原稿」を作らせようとしないことです。AIが作るのは、あくまで人間がレビューするための下書きです。体験談、実際の画面確認、商品レビュー、公開判断は人間が確認します。
プロンプト本文
あなたは、初心者向けブログ記事の編集者です。
以下の記事設計書をもとに、WordPressに入れる前の下書き本文を作成してください。
【記事設計書】
ここに記事設計書を貼る
【本文に必ず入れること】
- 冒頭で読者の悩みを示す
- 早い段階で結論を書く
- 実験ブログとして、実際に行った作業や計測結果を入れる
- 表、チェックリスト、手順を使って読みやすくする
- 関連記事への内部リンク候補を本文末尾に入れる
- 公開前に人間が確認する前提を残す
【出力形式】
- Markdown
- H1は記事タイトル
- H2とH3を使う
- 表はMarkdown表で書く
- コピペしやすいチェックリストを入れる
【制約】
- AIで楽に稼げると誤解される表現を避ける
- 収益、PV、検索順位を盛らない
- 公式情報が必要な内容は「公開前に確認」と明記する
- 未公開記事へのリンクは入れない
- 自分が実際に使っていない商品のレビューを書かない想定入力
下書き生成では、記事設計書に加えて、次のような作業ログを渡します。
使える実データ：
- 2026-05-21時点で15記事公開済み
- Site Kit Last 28 day の All Visitors は73
- Direct流入は93.2%
- Organic Searchは5.4%
- Search Console表示回数は0
- トップページPVは63
- 6記事目の内部リンク0本を修正した
- 15記事目はX投稿案を5本作成済み
本文で避けること：
- 検索流入が増えたと断定しない
- リライトすれば順位が上がると書かない
- X反応を成果のように盛らない実際の出力例
16記事目の下書きでは、冒頭が次のように整理されました。
ブログ記事を公開したあと、
「すぐ直したほうがいいのか」
「Search Consoleの数字が出るまで待つべきなのか」
「アクセスが少ない記事はリライトしたほうがいいのか」
と迷うことがあります。
特にブログを始めたばかりの時期は、記事を公開してもすぐに検索流入が増えるとは限りません。数字が少ない状態で毎日書き換えてしまうと、何が良くて何が悪かったのかも判断しにくくなります。また、実測値の扱いは次のように表で整理しました。
| 項目 | 2026-05-21時点 |
|---|---:|
| ユーザー数 | 73 |
| Direct流入 | 93.2% |
| Organic Search | 5.4% |
| Search Console表示回数 | 0 |
| Search Consoleクリック数 | 0 |
| トップページPV | 63 |このように、数字を入れるときは「成果が出た」と見せるためではなく、今どの段階なのかを判断する材料として使います。
失敗パターンと回避策
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| 設計書なしで本文を書かせる | 記事の主張が散らばる | 必ず設計書を先に作る |
| 実データを渡さない | どこにでもある一般論になる | 作業ログ、CSV、公開結果を渡す |
| 「SEOに強い記事にして」とだけ頼む | 断定が強くなりやすい | 「保証しない」「実測値だけ使う」と制約を書く |
| 下書きをそのまま公開する | 体験談や責任ある判断が抜ける | 人間レビュー項目を残す |
関連記事
- AIでブログ記事を書くときの注意点と失敗しない使い方
- ブログ記事を公開した後にやること｜初心者向け公開後チェックリスト
- Google Analyticsでブログ公開後に最初に見る数字｜初心者向けチェックリスト
3. リライトプロンプト
公開済み記事や下書きを直すときは、単に「読みやすくして」と頼むだけでは足りません。
リライトでは、何を直すのかを先に分けます。誤字やリンクミスを直すのか、検索意図とのズレを直すのか、一次情報を足すのかで、指示の出し方が変わります。
プロンプト本文
あなたはSEO編集者です。
以下の記事を、検索意図とこのブログの運営方針に合うようにリライトしてください。
【対象記事】
- タイトル：
- 公開URLまたは下書きファイル：
- 狙うキーワード：
- 想定読者：
- 現在の状態：
【リライト目的】
- 何を直したいか：
- なぜ直すのか：
- 使える一次情報：
- 残したい内部リンク：
- 追加したい内部リンク：
【出力してほしい内容】
1. 現在の記事の問題点
2. リライト方針
3. 残すべき内容
4. 削るべき内容
5. 追記すべき一次情報
6. 修正文
7. タイトル案
8. メタディスクリプション案
9. 公開前チェック
【制約】
- 未確認の実績を追加しない
- Codexを万能扱いしない
- AIで楽に稼げる表現にしない
- 未公開記事へリンクしない
- 事実と推測を分ける
- 人間が最終確認する前提を残す想定入力
3記事目のリライトでは、次のような方針を渡しました。
対象記事：
Codexでブログ運営を自動化する方法｜初心者向けにできることを解説
リライト目的：
Codexを万能に見せず、「完全自動化」ではなく「ブログ運営を型化して迷いを減らす」という軸に直す。
残したい内容：
1記事目・2記事目への内部リンク。
避けたい内容：
未設定のキャラクター名、未公開記事へのリンク、AIで楽に稼げると誤解される表現。実際の出力例
3記事目のリライト結果では、方針が次のように整理されました。
リライト方針：
- 未設定のキャラクター名は使用しない
- 未設定のキャラクター要素を入れない
- 記事全体の軸を「完全自動化ではなく、ブログ運営を型化して迷いを減らす」に整理する
- Codexを万能扱いしない
- 「AIで楽に稼げる」と誤解される表現を避ける
- 1記事目・2記事目への内部リンクは残す
- 未公開記事にはリンクしない主な変更点も、公開前に確認しやすい形になりました。
主な変更点：
- 冒頭を、読者の悩みから自然に入る形へ整理した
- 「半自動化」という考え方を追加した
- Codexに任せやすい作業と人間が確認する作業の線引きを明確にした
- WordPress作業を任せるときの安全ルールを整理した
- 基本プロンプトを読みやすく整えたここで重要なのは、リライト後の文章だけでなく「何をどう直したか」を残すことです。ブログ運営では、あとから見返したときに、なぜ直したのかがわからないと次の改善に使えません。
失敗パターンと回避策
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| 文章だけ渡して「改善して」と頼む | どこを直したか追えない | 問題点、方針、変更点を分けて出させる |
| 検索順位改善を目的にしすぎる | 根拠のないSEO断定になる | 実測値やSearch Consoleの状態を一緒に渡す |
| AIに体験談を書かせる | 実際にやっていない体験談になる | 体験談は人間が追記する前提にする |
| 内部リンクを任せきる | 未公開URLや存在しないURLが混ざる | 公開済みURLの一覧を渡す |
関連記事
- 内部リンクの貼り方｜記事公開後にやる6ステップとチェックリスト【初心者向け】
- Search Consoleで記事公開後に見る数字｜表示回数・クリック数・CTRの読み方
- ブログ記事を公開した後にやること｜初心者向け公開後チェックリスト
4. 内部リンク提案プロンプト
内部リンクは、AIブログ実験室で特に重視している作業です。
記事を増やすだけでは、読者が次に読む記事へ進めません。Search Console、Analytics、X投稿、リライトなど、記事同士の役割をつなぐことで、ブログ全体が読みやすくなります。
ただし、内部リンクはAIに丸投げすると危険です。未公開記事、存在しないURL、プレビューURL、WordPress管理画面URLが混ざる可能性があるため、公開済み記事の一覧を渡して、その範囲内で提案させます。
プロンプト本文
あなたはブログの内部リンク設計担当です。
以下の公開済み記事一覧と対象記事をもとに、自然な内部リンク候補を提案してください。
【ブログの前提】
- テーマ：AI・Codexを使ったブログ運営と副業自動化
- 読者：ブログ初心者、AIを使ってブログ運営を整理したい人
- 方針：読者が次の作業に進みやすい導線を作る
【公開済み記事一覧】
ここに data/articles.csv から status=published の記事だけを貼る
【対象記事】
- 記事ID：
- タイトル：
- 公開URL：
- 現在の内部リンク状況：
- 追加したい導線：
【出力してほしい内容】
1. 追加すべきリンク先
2. リンクを置く場所
3. アンカーテキスト
4. なぜ自然か
5. 逆方向リンクが必要か
6. 更新後に確認すること
【制約】
- 未公開記事へリンクしない
- 存在しないURLを作らない
- プレビューURLや管理画面URLを使わない
- 関係の薄い記事へ無理にリンクしない
- 読者の次の行動が自然になる導線だけ提案する想定入力
6記事目の内部リンク修正では、次のような入力になります。
対象記事：
GitHubでブログ運用ログを管理してオンライン編集できるようにする方法
現在の状態：
本文末尾の内部リンクが不足している。公開済み記事への「次に読む記事」を整理したい。
追加したい導線：
- Codexでブログ運営を自動化する方法
- ブログ記事を公開した後にやること
- 内部リンクの貼り方
制約：
公開済みURLだけを使う。未公開記事にはリンクしない。実際の出力例
内部リンクの更新記録では、次のように残しています。
source_id: 6
source_title: GitHubでブログ運用ログを管理してオンライン編集できるようにする方法
target_id: 3
target_title: Codexでブログ運営を自動化する方法｜初心者向けにできることを解説
location: 記事末尾：次に読む記事
notes: 2026-05-21に6記事目の内部リンク0本を修正。公開HTMLでURL確認済み。
target_id: 13
target_title: ブログ記事を公開した後にやること｜初心者向け公開後チェックリスト
location: 記事末尾：次に読む記事
notes: 2026-05-21に6記事目の内部リンク0本を修正。公開HTMLでURL確認済み。
target_id: 11
target_title: 内部リンクの貼り方｜記事公開後にやる6ステップとチェックリスト【初心者向け】
location: 記事末尾：次に読む記事
notes: 2026-05-21に6記事目の内部リンク0本を修正。公開HTMLでURL確認済み。10記事目のリンク計画では、リンクを置く場所まで具体化しました。
7記事目からのリンク：
- 「URLがGoogleに登録されていません」と出たらどうするか
- 「インデックス登録リクエストで注意すること」
- 「次に読む記事」
追加文案：
URL検査で「インデックス未登録」と表示された場合の具体的な確認手順は、以下の記事でチェックリスト形式にまとめています。内部リンクは「どの記事へリンクするか」だけでなく、「どの文脈でリンクするか」が大切です。記事末尾に置くだけでなく、読者が疑問を持つ場所に自然に置くと、リンクが押される理由が生まれます。
失敗パターンと回避策
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| 全記事に機械的にリンクする | 読者にとって不自然な導線になる | 関連性と次の行動で選ぶ |
| 未公開記事も候補に入れる | 404や公開前URLへのリンクになる | status=published のみ渡す |
| URLだけ確認して本文文脈を見ない | リンクの置き場所が不自然になる | 見出し単位で置き場所を指定させる |
| 片方向だけで終わる | 記事群の回遊が弱くなる | 必要に応じて戻りリンクも検討する |
関連記事
- 内部リンクの貼り方｜記事公開後にやる6ステップとチェックリスト【初心者向け】
- GitHubでブログ運用ログを管理してオンライン編集できるようにする方法
- Search Consoleでインデックス未登録が出たときの確認手順｜初心者向けチェックリスト
5. X投稿案プロンプト
記事を公開したあと、Xに何を書けばよいか迷うことがあります。
AIブログ実験室では、記事公開時のX投稿を「公開告知」「作業ログ」「学び」に分けています。さらに必要に応じて、チェックリスト投稿やスレッド起点も作ります。
大事なのは、記事URLを貼るだけの投稿にしないことです。SNS投稿の主役は記事そのものではなく、読者の悩み、失敗回避、具体的な判断基準です。
プロンプト本文
あなたはX運用担当です。
以下のブログ記事をもとに、X投稿案を作ってください。
【ブログの前提】
- サイト名：AIブログ実験室
- テーマ：AI・Codexを使ったブログ運営と副業自動化
- SNS方針：バズ狙いではなく、ブログ記事・作業ログ・失敗記録の再利用
【対象記事】
- 記事タイトル：
- 公開URL：
- 記事の要点：
- 実際にやった作業：
- 読者の悩み：
- 確認できた事実：
- まだ未確認のこと：
【作ってほしい投稿】
1. 公開告知
2. 作業ログ
3. 学び
4. チェックリスト
5. スレッド起点
【各投稿の条件】
- 1投稿1テーマ
- 1行目で読者の悩みに触れる
- 記事告知だけで終わらせない
- リンク付き投稿とリンクなし投稿を混ぜる
- 収益、PV、フォロワー数を盛らない
- 公開済み記事だけリンクする
- rawスクリーンショット利用を前提にしない
- 「AIで楽に稼げる」と誤解される表現を避ける
【出力形式】
投稿タイプ、投稿本文、リンク有無、投稿前チェックを表で出す。想定入力
15記事目のX投稿案では、次のような情報を渡しました。
記事タイトル：
ブログ公開後のX投稿案の作り方｜告知・作業ログ・学びに分ける
公開URL：
https://www.fukuro-ai.tech/blog-x-post-ideas-after-publish/
記事の要点：
ブログ記事を公開したあと、X投稿を公開告知、作業ログ、学びに分ける。
リンク付き投稿ばかりにせず、読者が投稿だけでも学べる形にする。
実際にやった作業：
15記事目の公開後に、X投稿案を5本作成し、data/sns_posts.csv に planned として記録した。
まだ未確認のこと：
実投稿は人間確認後。投稿後の反応は data/x_growth_metrics.csv に記録する。実際の出力例
15記事目では、次の5本を作りました。
公開告知：
ブログ記事を公開したあと、Xに何を書けばいいか迷いやすいです。「公開しました」だけでも投稿はできますが、毎回同じ告知になりがち。公開告知・作業ログ・学びに分けると、1本の記事から自然に複数の投稿案を作れます。
作業ログ：
15記事目は「ブログ公開後のX投稿案」をテーマにしました。公開告知だけでなく、作業ログや学びとして再利用する前提で整理。記事URLを入れる投稿と、URLなしでも読める投稿を分けると、告知だけのアカウントになりにくいです。
学び：
X投稿案をAIに頼むとき、「いい感じに作って」だけだと記事要約に寄りやすいです。記事タイトル、読者の悩み、実際にやった作業、確認できた事実、まだ未確認のことを分けて渡すと、盛らない投稿案になりやすい。
チェックリスト：
ブログ公開後のX投稿前チェック。1行目が読者の悩みから始まっているか。記事告知だけで終わっていないか。公開済み記事だけにリンクしているか。PVや収益を盛っていないか。rawスクショを使っていないか。
スレッド起点：
ブログ記事を公開したあとに作るX投稿案は、最初から何本も考えなくていいです。まずは3本で十分。1 公開告知、2 作業ログ、3 学び。この3つに分けるだけで、同じ記事からでも内容が重複しにくくなります。この5本は、すべて planned の状態で管理しています。実投稿は人間確認後に行い、反応が出たら別のCSVへ記録します。
失敗パターンと回避策
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| 「記事を宣伝して」とだけ頼む | 更新告知だけの投稿になる | 投稿タイプを分けて依頼する |
| リンク付き投稿だけ作る | 告知感が強くなる | リンクなしでも学べる投稿を混ぜる |
| 数字を盛る | 信頼を落とす | 確認できた事実だけ書く |
| AIに煽り文を作らせる | 「楽に稼げる」表現になりやすい | 禁止表現を明示する |
関連記事
6. 月次レポート生成プロンプト
月次レポートは、ブログ運営を続けるための記録です。
AIブログ実験室では、伸びた数字だけでなく、つまずいたこと、直したこと、まだ判断できないことも残す方針です。特に初期ブログでは、Search Consoleに数字が出ない期間もあります。その状態で成果を断定せず、次にやることを整理するのが月次レポートの役割です。
プロンプト本文
あなたはブログ運営レポートの編集者です。
以下の実測データと作業ログをもとに、月次レポートの下書きを作ってください。
【ブログの前提】
- サイト名：AIブログ実験室
- 目的：Codexを活用して個人ブログを月3万円まで育てる実験記録
- 方針：成功だけでなく、失敗、未確認、改善作業も記録する
【対象月】
- 年月：
【入力データ】
- 公開記事数：
- 累計記事数：
- PVまたはユーザー数：
- Search Console表示回数：
- Search Consoleクリック数：
- Organic Search：
- Direct流入：
- 収益：
- 作業時間：
- 公開した記事：
- リライトした記事：
- 内部リンク更新：
- SNS投稿：
- つまずいたこと：
- 来月やること：
【出力してほしい内容】
1. 今月の結論
2. 数字サマリー
3. 公開した記事
4. リライトした記事
5. 良かったこと
6. つまずいたこと
7. Codexに任せたこと
8. 人間が判断したこと
9. Search Consoleで見たこと
10. 来月やること
11. 記事内に入れる運営メモ案
【制約】
- 数字を盛らない
- 未計測の数値は空欄または要確認にする
- 収益がない場合はないと書く
- Search Consoleに数字が出ていない場合、失敗と断定しない
- 読者が自分のブログでも記録できる形にする想定入力
2026-05-21時点の初回実測では、次のようなデータを使いました。
計測元：
WordPress管理画面の Site Kit by Google ダッシュボード
期間：
Last 28 day
全体結果：
- All Visitors：73
- Direct：93.2%
- Organic Search：5.4%
- Unassigned：1.4%
- Search Console Total Impressions：0
- Search Console Total Clicks：0
- Unique Visitors from Search：4
Top content：
- トップページ：63 pageviews
- 1記事目：7 pageviews
- 11記事目：4 pageviews
- 15記事目：4 pageviews
- 2記事目：3 pageviews
- 4記事目：3 pageviews
- 記事一覧：3 pageviews
- 7記事目：2 pageviews実際の出力例
初回実測の判断は、次のように記録しました。
現時点では、検索流入はまだほぼ育っていない。
一方で、Analytics上はユーザー計測が始まっており、トップページ中心に閲覧が発生している。記事別では1記事目、11記事目、15記事目、2記事目、4記事目、7記事目、5記事目がSite KitのTop contentに表示された。
ただし、Site KitのTop contentに表示されなかった記事を0PVとは断定しない。全記事の正確なページ別数値は、GA4の「ページとスクリーン」詳細画面またはAPIで再確認する必要がある。次にやることも、成果ではなく改善作業として整理しました。
次にやること：
- GA4のページ別詳細で1〜15記事目の全ページ数値を確認する
- Search Consoleで13〜15記事目のインデックス状況を再確認する
- X投稿案を実投稿し、data/x_growth_metrics.csv に24時間後の反応を記録する
- 16記事目以降では、トップページに集中している閲覧を記事導線へ流す改善も検討する月次レポートでは、「数字が少ないから失敗」と短絡しないことが大切です。初期ブログでは、数字が少ない状態そのものも運営ログになります。
失敗パターンと回避策
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| PVだけで判断する | 記事改善の理由が浅くなる | 公開記事数、導線、Search Consoleも見る |
| 未計測値を推測で埋める | 実験ログとして信頼できなくなる | 空欄、未取得、要確認を使う |
| 良かったことだけ書く | 次の改善に使えない | つまずいたことも残す |
| AIに結論を盛らせる | 成果報告風になりすぎる | 実測値と判断を分ける |
関連記事
- ブログ運営レポートの書き方｜月3万円を目指すために記録する数字と改善ポイント
- ブログ月次レポートテンプレート｜初心者が記録すべき数字と改善メモ
- Google Analyticsでブログ公開後に最初に見る数字｜初心者向けチェックリスト
7. メタディスクリプション最適化プロンプト
メタディスクリプションは、検索結果で記事の内容を伝えるための短い説明文です。
ただし、ここでも煽りすぎは避けます。AIに任せると「完全解説」「劇的改善」「誰でも簡単」などの表現が入りやすいので、記事の内容と実際の状態に合うように制約を入れます。
プロンプト本文
あなたはSEO編集者です。
以下の記事に対して、メタタイトル案とメタディスクリプション案を作ってください。
【対象記事】
- タイトル：
- スラッグ：
- 狙うキーワード：
- 想定読者：
- 記事の結論：
- 本文で扱う内容：
- 入れてよい一次情報：
- 避けたい表現：
【出力してほしい内容】
1. メタタイトル案を3つ
2. メタディスクリプション案を3つ
3. 一番おすすめの案
4. おすすめ理由
5. 公開前に確認すること
【条件】
- メタタイトルは32文字前後を目安にする
- メタディスクリプションは90〜120文字前後を目安にする
- 狙うキーワードを自然に含める
- 記事内容と違う約束をしない
- 収益、順位、アクセス増加を保証しない
- 初心者にもわかる言葉にする想定入力
16記事目では、次のような入力になります。
タイトル：
ブログ記事をいつリライトするか｜Search Console・Analytics・X反応から判断する方法
狙うキーワード：
ブログ リライト タイミング
想定読者：
ブログ記事を公開したあと、いつ直せばよいかわからない初心者。
記事の結論：
公開直後に直すものと、数字を見てから判断するものを分ける。
避けたい表現：
リライトすれば順位が上がる、アクセスが増える、AIで自動改善できる、などの断定。実際の出力例
16記事目の公開前チェックでは、次の案を残しました。
メタタイトル：
ブログ記事をいつリライトするか｜初心者向け判断基準
メタディスクリプション：
ブログ記事をいつリライトすればよいかを初心者向けに解説。公開直後に直すこと、Search ConsoleやAnalyticsの数字を見て判断すること、X投稿の反応を記事改善に使う考え方を整理します。15記事目では、WordPress下書き時点でメタディスクリプション相当の抜粋を設定したことも記録しています。
SEO・導線チェック：
- スラッグ案を決めている
- メタディスクリプション相当の抜粋をブックマークレットに設定した
- 13記事目、14記事目、9記事目への内部リンクを入れている
- 未公開記事へのリンクは入れていないメタディスクリプションは、記事本文を大げさに見せる場所ではありません。読者が「この記事で何がわかるか」を検索結果で判断できるようにする説明文です。
失敗パターンと回避策
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| クリック狙いで煽る | 本文とのズレが出る | 記事の結論と扱う範囲だけを書く |
| キーワードを詰め込む | 不自然な説明文になる | 1回自然に入れば十分と考える |
| 実績を盛る | 信頼を失う | PV、収益、順位は確認済みだけ書く |
| 抜粋設定を忘れる | 検索結果やSNS表示で弱くなる | 公開前チェックに入れる |
関連記事
- Search Consoleで記事公開後に見る数字｜表示回数・クリック数・CTRの読み方
- ブログ記事を公開した後にやること｜初心者向け公開後チェックリスト
- AIでブログ記事を書くときの注意点と失敗しない使い方
このページを中心に内部リンクを集める方針
このページは、AIブログ実験室の中で「Codexをブログ運営にどう使うか」をまとめるピラーページにします。
今後は、既存記事からこのページへ内部リンクを集めます。特に、次の記事からリンクすると自然です。
| リンク元記事 | 置き場所の候補 | アンカーテキスト案 |
|---|---|---|
| 1記事目：Codexでブログ月3万円を目指す実験を始めます | Codexに任せる作業の説明付近 | 実際に使っているCodexブログ運営プロンプト集 |
| 3記事目：Codexでブログ運営を自動化する方法 | 基本プロンプトの説明付近 | Codexブログ運営プロンプト集 |
| 5記事目：AIでブログ記事を書くときの注意点 | AI下書きの使い方付近 | 下書き前に使うプロンプト例 |
| 8記事目：ブログ運営レポートの書き方 | 月次レポートの作り方付近 | 月次レポート生成プロンプト |
| 9記事目：ブログ月次レポートテンプレート | テンプレート活用の説明付近 | Codexで月次レポートを作るプロンプト |
| 11記事目：内部リンクの貼り方 | 内部リンク提案の説明付近 | 内部リンク提案プロンプト |
| 13記事目：ブログ記事を公開した後にやること | 公開後作業の説明付近 | 公開後に使うCodexプロンプト集 |
| 15記事目：ブログ公開後のX投稿案の作り方 | Codexに投稿案を頼む説明付近 | X投稿案を作るプロンプト |
この内部リンク更新は、このページを公開したあとに行います。公開前に既存記事へリンクすると、未公開URLへのリンクになってしまうためです。
コピペ前に確認するチェックリスト
最後に、プロンプトを使う前のチェックリストをまとめます。
- 想定読者を決めた
- 狙うキーワードを決めた
- 既存記事との役割を確認した
- 使える一次情報を用意した
- 公開済み記事だけを内部リンク候補にした
- 未確認の数字を盛らないようにした
- 公式情報が必要な内容は公開前確認にした
- 人間が確認する作業を残した
- WordPressに入れる前にプレビュー確認する
- 公開後は
data/articles.csvやSNS管理CSVを更新する
まとめ
Codexは、ブログ運営のすべてを自動でやってくれる道具ではありません。
ただ、考える順番を整理する、記事構成を作る、下書きのたたき台を作る、内部リンク候補を出す、X投稿案を分ける、月次レポートをまとめる、といった作業にはかなり使いやすいです。
このページで紹介したプロンプトは、AIブログ実験室で実際に使っている運営の型です。最初から完璧に使う必要はありません。まずは、記事構成案を作るプロンプトか、公開後チェック用の内部リンク提案プロンプトから試すと始めやすいです。
大事なのは、AIに丸投げしないことです。
AIには整理と下書きを任せ、人間は体験談、事実確認、公開判断、読者への責任を持つ。この分担を決めておくと、Codexはブログ運営の作業をかなり進めやすくしてくれます。