Codexを使うと、SEO記事の本文を書くだけでなく、キーワード選定、検索意図と競合の調査、構成、画像作成、WordPressへの下書き入稿までを一つの流れとして進められます。
ただし、この記事でいう自動化は、AIへ任せて無人で公開することではありません。私はCodexへ制作工程を任せながら、記事の目的、自分の主張、事実確認、最終的な公開判断は人間が担当する形で運用しています。
この記事自体も、今回紹介する流れで制作しています。キーワードを調整し、上位記事を確認し、構成と本文を作り、各H2の画像、SWELL装飾、SEO設定を用意してから、WordPressへ下書き入稿します。
ここでは、1stWritingで実際に使っている方法を基に、CodexでSEO記事を作成する9工程、必要な準備、人とAIの分担、運用してわかった課題を解説します。

取得資格
- SEO検定1級
- SEOマーケティングアドバイザー
2020年からブログを始めて、エンタメ系のジャンルは約1年で月間10,000PVほど。2021年にWebライターとして独立しSEOメディア運用ディレクターとして現在も活動中。田舎に戻りHP製作やSNS運用マーケティング支援なども対応。
CodexでSEO記事制作を自動化できる9つの工程

Codexでは、キーワード候補の整理からWordPress入稿後の確認まで、SEO記事制作の複数工程を続けて処理できます。
| 工程 | Codexへ任せている作業 | 人が判断する内容 |
|---|---|---|
| 1. KW候補 | カテゴリとロングテールKWを整理する | 自分が書く意味のあるテーマを選ぶ |
| 2. クエリ統合 | 同じ検索意図のKWをまとめる | 一記事で答える範囲を決める |
| 3. SERP調査 | 上位記事のタイトル・見出し・論点を整理する | 読者に本当に必要な情報を判断する |
| 4. 構成 | 読者の疑問へ答える順にH2・H3を作る | 自分の主張と一次情報を割り当てる |
| 5. 執筆 | ルールと構成に沿って本文を作る | 体験・言い回し・事実を確認する |
| 6. 画像 | 各H2の内容を表す差し込み画像を作る | テイスト、文字、内容を確認する |
| 7. 装飾・SEO設定 | SWELL、FAQ、タイトル、説明文を整える | 誇張や不自然なKW挿入がないか確認する |
| 8. WordPress入稿 | 記事と画像を下書きとして登録する | 公開状態と対象記事を確認する |
| 9. 読み戻し | H2、画像、FAQ、リンク、SEO設定を照合する | プレビューを見て公開を判断する |
一般的なAIチャットでも、構成案や本文は作れます。一方、Codexは作業フォルダ内のファイルを確認・編集し、ローカルのツールを実行できるため、文章を受け取った後の作業までつなげられます。Codex CLI公式ドキュメント
私が重視しているのは、作業数を増やすことではなく、前の工程で決めた内容を次の工程へ引き継ぐことです。キーワード設計で決めた読者像を構成へ渡し、構成で決めた見出しを本文・画像・入稿確認まで一貫させます。
SEO記事の自動化を始める前に用意する4つのもの

SEO記事制作を安定して自動化するには、プロンプトを工夫する前に、作業場所と判断基準を用意します。
- 記事制作専用のプロジェクトフォルダ
- SEO・媒体・WordPressの制作ルール
- 著者の一次情報と公開済み記事
- 下書きだけを作れるWordPress接続
1. 記事制作専用のプロジェクトフォルダ
私は、1stWritingの記事制作専用に「1stWriting_SEO_Automation」というプロジェクトフォルダを用意しています。その中で、制作ルール、記事ごとの成果物、画像、WordPress入稿スクリプトを分けています。
1stWriting_SEO_Automation/ ├─ .agents/skills/ 制作ルール ├─ deliverables/ 記事ごとの本文・画像・確認記録 ├─ scripts/ WordPress入稿・検証処理 ├─ .env.local 認証情報 └─ wordpress-site.json サイト共通設定
記事の本文だけを会話に残すより、ファイルとして保存した方が、タイトル、構成、画像、SEO設定の対応関係を確認しやすくなります。記事ごとにフォルダを分けると、別の記事へ誤って上書きするリスクも減らせます。
どの業務をAIへ任せるか決まっていない場合は、先にAIを使える業務を15分で棚卸しする方法で、繰り返し作業を書き出してみてください。
2. SEO・媒体・WordPressの制作ルール
毎回の指示文だけで品質を揃えるのは難しいため、繰り返し使う判断をルールとして保存します。
1stWritingでは、次のようなルールを蓄積しています。
- 各H2の直下へ内容に合う画像を1枚置く
- H2配下に複数のH3がある場合は、表または箇条書きで全体像を先に示す
- FAQはSWELLの専用ブロックへ変換する
- プロンプトはコピー範囲が枠でわかる共通UIにする
- 結論だけのH2を機械的に置かず、KWごとに必要性を判断する
- WordPressでは公開せず、最初は下書きにする
修正内容をその記事だけで終わらせず、次の記事でも使うルールへ変えることで、記事を重ねるほど確認の往復を減らせます。
3. 著者の一次情報と既存記事
AIは文章を整えられますが、著者本人の経験を勝手に作ることはできません。記事を作る前に、自分が実際に行ったこと、感じたこと、確認できる数字、紹介できる画面を用意します。
今回の記事では、私がCodexと一緒に1stWritingの記事を制作してきた工程そのものが一次情報です。特に、記事執筆だけでなく、KWの統合判断、H2画像、SWELL FAQ、AIOSEO、入稿後の読み戻しまで行っている点を中心にしています。
既存記事のURLも先に確認します。公開済みの記事だけを内部リンクに使い、下書き記事へ読者を送らないようにしています。
4. 下書きだけを作れるWordPress接続
WordPressへの入稿には、REST APIとアプリケーションパスワードを使っています。WordPress REST APIは、外部のアプリケーションがJSON形式で投稿などのデータを作成・更新できる公式の仕組みです。WordPress REST API Handbook
ただし、記事制作用のWordPressユーザーと権限は必要な範囲へ限定します。認証情報を記事本文やスクリプトへ直接書かず、公開対象外の環境設定ファイルへ保存します。
Codexには、作業できるフォルダやコマンドの範囲を制限するサンドボックスがあります。技術的な境界と確認ルールを組み合わせ、どこまで任せるかを決めることが大切です。Codexのサンドボックス公式説明
Codexでキーワード選定から記事構成まで進める方法

記事の上流工程では、検索されそうな言葉を大量に出すだけでなく、「誰が何を知りたいか」を一記事単位まで整理します。
- キーワード候補をカテゴリ別に整理する
- 同じ検索意図のKWを一記事へまとめる
- 上位記事で必要な論点を答え合わせする
- 読者と一次情報を先に決めて構成する
キーワード候補をカテゴリ別に整理する
最初に、自分の経験、サービス、既存記事からテーマを広げます。今回なら、`Codex SEO記事 作成`、`Codex SEO記事 自動化`、`Codex WordPress 自動化`などが候補になりました。
ここでは検索されそうかだけでなく、自分が具体例を出せるかも確認します。私は現在の制作フォルダ、記事ファイル、生成画像、WordPress下書き、検証結果を示せるため、このテーマを優先しました。
同じ検索意図のKWを一記事へまとめる
言葉が違っても、読者と欲しい成果物が同じなら、一記事で回答できる場合があります。
たとえば「CodexでSEO記事を作成したい人」と「CodexでSEO記事制作を自動化したい人」は、どちらもKW選定から完成までの流れを知りたいと考えられます。そこで、今回の1本でまとめて狙います。
一方、`WordPress REST API 投稿`を検索する人は、認証方法、リクエスト、エラー処理など技術的な情報を求めています。読者と必要な詳しさが異なるため、別記事候補にします。
上位記事で必要な論点を答え合わせする
KWから検索意図を仮説化した後、実際の検索結果を確認します。上位記事に共通していたのは、工程分割、記事構成、本文、画像や校正、WordPress下書き、人による最終確認でした。
ただし、上位記事の見出しをそのまま並べるわけではありません。共通論点を「読者が答えを必要としている問い」へ置き換え、自分の一次情報を加えます。
今回の記事では、競合で説明が少なかったクエリ統合、各H2画像、SWELL・AIOSEO、サーバー読み戻しを追加しました。
読者と一次情報を先に決めて構成する
構成前に、対象読者、主な悩み、記事の結論、著者の一次情報、読後の行動を決めます。これらが曖昧なまま「上位記事より詳しく書いて」と依頼すると、一般論が増えやすくなります。
最初の依頼は、次のように記事の範囲と確認方法まで含めています。
KW「Codex SEO記事 作成」で、非エンジニアのサイト運営者向けの記事を作成してください。
最初に検索意図を仮説化し、Google検索上位3記事以上のタイトルと主要見出しで答え合わせしてください。見出しをコピーせず、読者の問いとして整理します。
私の一次情報は、キーワード選定、クエリ統合、競合調査、構成、執筆、各H2画像、SWELL FAQ、AIOSEO、WordPress下書き入稿、サーバー読み戻しまでを実際に行っていることです。
1stWritingの既存ルールを適用し、各H2直下へキャッチ入り画像を1枚置いてください。WordPressは必ず下書きにし、入稿後にH2・画像・FAQ・内部リンク・SEO設定を読み戻して確認してください。公開はしないでください。記事執筆・H2画像・SWELL装飾をまとめて作る方法

構成が決まったら、本文だけでなく、画像、SEO設定、入稿仕様、最終確認を同じ記事フォルダで管理します。
- 本文と制作管理情報を別ファイルにする
- 各H2直下の画像を同じテイストで作る
- SWELL装飾とFAQを入稿形式へ変換する
- SEOタイトル・説明文・内部リンクを設定する
本文と制作管理情報を別ファイルにする
公開する本文と、制作担当者だけが見る情報は分けます。私のプロジェクトでは、一記事ごとに次のファイルを作っています。
| ファイル | 内容 |
|---|---|
| `00-brief.md` | KW、読者、検索意図、一次情報、要確認事項 |
| `05-serp-review.md` | 検索結果で確認した競合と構成判断 |
| `10-seo-settings.md` | SEOタイトル、H1、slug、説明文、内部リンク |
| `20-outline.md` | H2・H3と各見出しの目的 |
| `30-article.md` | WordPressへ入れる公開本文 |
| `40-image-prompts.md` | 各H2画像のキャッチと制作指示 |
| `90-final-check.md` | 公開前の検証結果と残る確認事項 |
この分け方なら、本文へ「競合では」「要確認」といった制作メモが混ざりません。修正するときも、SEO設定、構成、本文のどこを変えるか判断しやすくなります。
各H2直下の画像を同じテイストで作る
1stWritingでは、すべてのH2直下へ内容を表す画像を1枚ずつ配置しています。画像は数だけ合わせず、見出しの要点がひと目でわかる短いキャッチを入れます。
制作前にH2の数を数え、画像名、alt属性、キャッチを一覧にします。生成後は、画像サイズだけでなく、日本語の誤字、テイスト、見出し直後への配置も確認します。
SWELL装飾とFAQを入稿形式へ変換する
Markdown本文をそのまま貼るのではなく、WordPressのブロック形式へ変換します。表は既存記事と同じ中央寄せにし、重要な文章へSWELLのマーカーを付けます。
FAQは通常のH3と段落のまま入稿せず、SWELLのFAQ親ブロックとFAQ項目へ変換します。画面に表示する質問・回答と構造化データの内容を一致させます。
プロンプトがある記事では、枠内全体を1クリックでコピーできる共通UIを使います。コピー範囲を示す説明文を重ねず、枠とボタンだけで判別できるデザインにしています。
SEOタイトル・説明文・内部リンクを設定する
SEOタイトル、H1、slug、メタディスクリプション、フォーカスキーフレーズを記事ごとに用意します。キーワードは自然に含め、SEOツールの点数を上げるためだけに見出しへ繰り返しません。
内部リンクは、存在するURLではなく、公開済みで読者の次の疑問に合う記事だけを使います。今回もWordPressの投稿状態を確認し、下書きの関連記事はリンク対象から外しました。
CodexからWordPressへ下書き入稿する方法

WordPress入稿は、認証情報を分離し、投稿状態を下書きへ固定してから実行します。
- アプリケーションパスワードを環境設定へ保存する
- 公開ではなく下書きで投稿する
- H2画像とアイキャッチをメディアへ登録する
- サーバーから読み戻して件数と設定を確認する
アプリケーションパスワードを環境設定へ保存する
WordPress 5.6以降には、REST APIなど外部連携用のアプリケーションパスワードが組み込まれています。WordPress公式資料では、ユーザー編集画面から発行し、HTTPS経由のBasic認証で利用する方法が説明されています。WordPress REST APIの認証方法
私は記事入稿専用ユーザーを用意し、ユーザー名とアプリケーションパスワードを`.env.local`へ保存しています。このファイルを記事フォルダへコピーしたり、本文へ貼ったりしません。
公開ではなく下書きで投稿する
入稿設定では、投稿状態を`draft`へ固定します。既存記事を更新するときは、slug、投稿ID、作業フォルダを照合し、別の記事へ上書きしないようにします。
自動化の目的は、公開ボタンをなくすことではありません。人が確認しやすい状態まで作業を進めることです。新規記事は下書きで作り、管理画面のプレビューを確認してから公開します。
H2画像とアイキャッチをメディアへ登録する
記事フォルダ内の画像をWordPressメディアへ登録し、それぞれに見出し内容と一致するalt属性を設定します。1枚目はアイキャッチにも設定します。
同じ画像を作り直した場合は、どの版を使うかを明確にします。ファイルが存在するだけでは、WordPressの記事へ正しく反映された証明にならないためです。
サーバーから読み戻して件数と設定を確認する
入稿後は、WordPressから投稿データを読み戻します。私の検証では、次の項目を機械的に照合しています。
| 確認項目 | 見る内容 |
|---|---|
| 投稿情報 | 投稿ID、slug、状態、カテゴリー |
| 見出し・画像 | H2数、画像数、すべてのH2直後に画像があるか |
| 装飾 | 表、マーカー、コピーUI、共通CSS |
| FAQ | SWELL FAQ親ブロック、項目数、JSON-LD |
| SEO | SEOタイトル、説明文、フォーカスキーフレーズ |
| リンク | 予定した内部リンクがすべて入っているか |
機械的な確認で問題がなくても、文字切れ、スマートフォン表示、画像内の日本語、文章の流れはプレビューで確認します。
自動化しても人が担当する5つの判断

Codexで工程をつないでも、記事の責任までAIへ移るわけではありません。私は、次の5つを人の仕事として残しています。
- 誰に何を伝える記事か決める
- 自分の経験と主張を提供する
- 事実・数字・最新仕様を確認する
- 認証情報・個人情報・画像の権利を確認する
- 最後に公開するか判断する
誰に何を伝える記事か決める
キーワードから読者像を考える作業はCodexも支援できます。ただし、自分が誰を助けたいか、記事を読んだ人に何をしてほしいかは、運営者が決めます。
今回も、WordPress入稿だけを知りたい人ではなく、SEO記事制作全体を仕組み化したい非エンジニアを読者にしました。この判断によって、記事の主題を入稿から制作全体へ修正しています。
自分の経験と主張を提供する
自分の体験は、音声入力や箇条書きでも構いません。AIに一般論を増やしてもらう前に、「実際に何をしたか」「どこで困ったか」「何を大切にしているか」を渡します。
私は、記事制作では学ぶことも必要ですが、まず触って出力を確かめる姿勢を重視しています。AIの使い方を体系的に学びたい場合は、AIを仕事で使うための独学ロードマップも参考にしてください。
事実・数字・最新仕様を確認する
製品機能、料金、法律、統計、固有名詞、日付などは、最新の一次情報を確認します。競合記事に書かれている内容を、そのまま事実の根拠にはしません。
Googleは生成AIの利用自体ではなく、正確性、品質、関連性を優先し、価値を加えず大量にページを生成する行為はスパムポリシーへ抵触する可能性があると説明しています。生成AIコンテンツに関するGoogle検索のガイダンス
認証情報・個人情報・画像の権利を確認する
アプリケーションパスワード、APIキー、顧客情報、未公開情報を本文や画像へ含めません。画面キャプチャを使う場合も、URL、投稿ID、ユーザー名など公開不要な情報を確認します。
AI生成画像を使う場合は、第三者のロゴ、キャラクター、人物を無断で似せないようにします。画像が作れたことと、公開に使えることは分けて判断します。
最後に公開するか判断する
CodexにはWordPressへ投稿する処理を任せられますが、公開状態へ変更する操作は人が判断します。記事の結論、一次情報、引用、画像、内部リンク、スマートフォン表示まで見てから公開します。
確認できない情報が残るなら、下書きのまま止めます。自動化は、止まらず公開する仕組みではなく、確認すべき箇所を明確にする仕組みとして使う方が安全です。
1stWritingで実際に運用してわかったメリットと課題

実際に運用して最も変わったのは、文章を書く速さだけでなく、調査、制作、修正、入稿を同じルールで続けられるようになったことです。
- 人が手を動かす時間を15〜20分程度まで減らせる記事もある
- 修正内容をルールとして次の記事へ反映できる
- 初期設定と公開前確認はなくならない
人が手を動かす時間を15〜20分程度まで減らせる記事もある
以前は、自分で一から記事を書くと丸1日、内容によっては3〜5日ほどかけることもありました。サイト設計やキーワード選定を含めると、さらに長くなります。
現在は、自分の記事であれば、大枠を作るために私が手を動かす時間が約5分、その後の確認と修正を含めて合計15〜20分程度になる記事もあります。AIが調査・生成している時間や、画像生成の待ち時間は別です。また、専門性、調査量、記事の長さによって所要時間は変わります。
短縮できた理由は、一度に文章を書く速度より、以前の記事で決めたルール、ファイル、入稿スクリプト、確認項目を再利用できるようになったためです。
修正内容をルールとして次の記事へ反映できる
最初の数記事では、導入、見出し、プロンプトUI、FAQ、画像などに細かな修正が必要でした。ただ、指摘を共通ルールへ変えると、次の記事では最初から反映できます。
たとえば、「H2に複数のH3がある場合は全体像を先に示す」「コピー範囲は枠だけでわかるようにする」といったルールは、現在の記事制作へ引き継いでいます。
SEO記事以外にどのような作業を短縮できたかは、AIで実際に短縮できた業務5例で紹介しています。
初期設定と公開前確認はなくならない
この仕組みを作るまでには、制作ルール、WordPress接続、SWELLブロック、SEO設定、画像、読み戻し処理を一つずつ整えました。最初の記事から15〜20分で完成したわけではありません。
WordPressやCodexの仕様が変われば、スクリプトや確認項目の見直しも必要です。また、自分の体験や新しい事実を記事へ入れる作業は、記事ごとに残ります。
そのため、「一度設定すれば何もしなくてよい」ではなく、「繰り返し作業を減らし、人が判断する時間へ集中する仕組み」と考えています。
CodexによるSEO記事作成でよくある質問

ここでは、CodexでSEO記事制作を自動化するときによくある疑問へ答えます。
- 非エンジニアでも始められるか
- ChatGPTだけで書く場合との違い
- WordPressへ自動公開してよいか
- すべての記事に同じ仕組みを使えるか
- AI記事はSEOで不利になるか
- 非エンジニアでもSEO記事制作を自動化できますか?
-
小さな範囲からなら、非エンジニアでも始められます。最初はWordPress接続まで行わず、専用フォルダで構成と本文をファイルへ保存するところから試してください。
ただし、認証情報、コマンド、WordPress APIを扱う段階では、実行範囲と結果を確認する必要があります。わからない処理をそのまま公開環境で動かさないことが大切です。
- ChatGPTだけで記事を書く場合と何が違いますか?
-
ChatGPTでも、検索意図の壁打ち、構成、本文作成はできます。Codexの違いは、記事ファイル、画像、制作ルール、検証スクリプトを同じプロジェクト内で扱い、複数工程をつなげやすい点です。
文章だけ必要ならチャットで十分な場合もあります。ファイル管理やWordPress入稿まで繰り返すなら、Codexを使う意味が大きくなります。
- WordPressへ自動公開してもよいですか?
-
最初から自動公開することはおすすめしません。記事、画像、リンク、装飾、SEO設定を下書きとして入れ、人がプレビューを確認してから公開してください。
特に法律、医療、金融、製品仕様、料金などを扱う記事は、一次情報や専門家確認が必要になる場合があります。
- すべての記事制作に同じ自動化を使えますか?
-
共通の制作工程は再利用できますが、記事ごとに検索意図、必要な根拠、見出し、画像、CTAは変わります。前の記事の構成をそのまま複製しないようにします。
比較記事、レビュー、法律記事、体験記事では確認内容も異なります。共通ルールと記事固有の指示を分けて管理してください。
- AIで作った記事はSEOで不利になりますか?
-
AIを使ったという理由だけで不利になるとは限りません。重要なのは、読者に役立つ内容、正確性、独自の経験、検索意図との関連性です。
AIが作った一般論を確認せず大量公開するのではなく、自分の一次情報を入れ、事実とリンクを確認し、読者の問いへ過不足なく答えているかを見てください。
まとめ|CodexでSEO記事制作全体を仕組み化する

Codexを使えば、キーワード候補、クエリ統合、競合調査、構成、執筆、H2画像、SWELL・SEO設定、WordPress下書き入稿、読み戻し確認までを一つの流れとして進められます。
ただし、記事の目的、一次情報、事実確認、権利・安全、公開判断は人が担当します。この境界を先に決めることで、AIへ任せる作業を増やしても、内容を確認できる状態を保ちやすくなります。
最初から全工程を作る必要はありません。まず自分の記事制作工程を書き出し、一記事だけ、構成と本文を専用フォルダへ保存するところから試してください。次に画像、WordPress下書き、読み戻し確認を一つずつ追加すると、自分に合うSEO記事制作の仕組みを作れます。
