本記事はアフィリエイト広告(PR)を含みます
ブログを書いていると、たまに「自動でブログ記事を書いてWordPressへの投稿までできればいいのに」と思うことがあります。
WordPressへ記事を投稿する場合、通常は管理画面を開いて記事を作成・投稿します。
一方で、WordPressにはREST APIが標準で用意されており、Pythonなどのプログラムから記事を投稿することも可能です。
ただ、自動投稿するためのシステムを一から作るとなると、WordPress REST APIの使い方や認証方法などを調べながら実装することになると思います。
そこで、今回はOpenAIのコーディングエージェント「Codex」をVisual Studio Codeにインストールして、PythonからWordPressへ記事を自動投稿するプログラムを作成してみます。
1. Codexとは
CodexはOpenAIが提供しているプログラミング向けのコーディングエージェントです。
通常のChatGPTでもプログラムの作成や修正はできますが、Codexはプロジェクトにアクセスして直接ファイルの作成や編集を行うことができます。
例えば
PythonでWordPress REST APIを使って記事を投稿するプログラムを作成してくださいと指示を出すと、必要なファイル作成、ライブラリインストール、テスト実行などを自動で行ってくれます。
また、Visual Studio Code(VS Code)の拡張機能としても利用できるため、普段の開発環境から指示を出すことも可能です。
今回はVS Codeにインストールして試してみます。
2. Claude CodeではなくCodexを使う理由
コーディングエージェントとしては、Anthropicの「Claude Code」もあります。
Claude CodeもCodexと同様にプロジェクト内のファイルを編集したり、コマンドを実行できるため、今回のWordPress自動投稿システムを作ることは可能です。
では、なぜ今回はClaude CodeではなくCodexを使うのか。
理由はシンプルで、私がChatGPT Plusユーザーだからです。
ChatGPT Plusを利用している場合、追加料金なしでCodexを利用することができます。
3. Codexを使用するときの注意点
CodexはChatGPT無料プランでも利用できますが、利用できる量に制限があります。
Plusプランでも利用上限はあるので、通常のChatGPTと同じ感覚で壁打ちしているとすぐに利用枠を使い切ってしまうかもしれません。
そこで、Codexを利用するときは最初に作りたいものや要件をある程度整理してからプロンプトを入力したほうが利用枠の節約にもなって効率的です。
4. Visual Studio CodeへCodexをインストール
まずはVS Codeの拡張機能からCodexをインストールします。
左のリストの中から拡張機能アイコンを選択し、検索まどに「codex」と入力すると、通常一番上に「Codex – OpenAI’s coding agent」が表示されるので、こちらを選択してインストールします。
インストールが完了すると、右側のチャット画面に「CODEX」タブが表示されるので、これを選択します。
CODEXタブに切り替えると、以下のような画面が表示されるので「ChatGPTを使用してサインイン」を選択します。
すると、ChatGPTへのログインを促されるのでログインします。
ログインするとこのような画面が表示されるので、画面を閉じてVS Codeに戻ります。
VS Codeに戻ると、「Windowsのセットアップを完了してください」というめせーじが表示されるので、「続ける」を押します。
セットアップが完了したら、まずは右下に表示されているモデルを確認してみます。
Codexでは使用するモデルや推論レベル、処理速度を変更することができます。
推論レベルを上げると複雑なタスクに対応しやすくなりますが、その分利用料も増える可能性があります。
また、「高速」を選択すると処理速度が向上しますが、通常より利用料が増えます。
今回は利用料を節約するため、デフォルトで設定されている
- GPT-5.6 Sol
- 推論レベル「軽」
- 速度「標準」
で試します。
5. CodexでWordPress自動投稿プログラムを作成
ここからは実際にCodexに指示を出して自動投稿プログラムを作成していきます。
ただ、コーディングエージェントは通常のChatGPTとは違い、ローカルファイルへのアクセスやコマンド実行権限を与えているので、
WordPress自動投稿プログラムを作成してといった大雑把な指示を出すのは危険です。
最低限動くものはできるかもしれませんが、使用言語、認証方法、仮想環境、セキュリティ対策などなにも指定していないのでCodex側で判断することになります。
特にWordPressのサイトを操作する場合、意図せず記事が公開されてしまったり、認証情報をソースコードへ直書きしてしまったりといったことが起こるかもしれません。
そのため、最初にある程度要件をまとめてからプロンプトを入力しました。
5.1. システム全体の設計
まずはこちらで要件を提示して、システム設計案をCodexに提案させます。
与えたプロンプトは以下の通りです。
WordPressブログの記事作成を半自動化するシステムをPythonで構築したいです。
対象サイト：
XXXXXX.com
最終的な目的は、
「記事テーマを入力 → AIで記事生成 → WordPress REST APIで下書き投稿」
までを自動化することです。
Windows 11で動作するシステムとして設計してください。
【重要】
いきなり全機能を実装しないでください。
最初に現在のワークスペースを確認し、
必要な機能、ディレクトリ構成、使用ライブラリ、
実装手順、WordPress側で必要な設定を提案してください。
私が確認してから実装を開始してください。
■ 基本要件
Pythonを使用してください。
以下の処理を行えるようにします。
1. 記事テーマを入力
2. AIで記事タイトルを生成
3. 記事構成（H2/H3）を生成
4. 本文を生成
5. meta descriptionを生成
6. WordPress向けHTMLを生成
7. WordPress REST APIを使用して投稿
8. 投稿結果をログに保存
■ WordPress連携
WordPress REST APIを使用してください。
投稿先：
XXXXXX.com
認証にはWordPressのApplication Passwordを使用します。
以下の情報は.envから取得してください。
WORDPRESS_URL
WORDPRESS_USERNAME
WORDPRESS_APP_PASSWORD
認証情報をPythonコードへ直接記述してはいけません。
.envは.gitignoreへ追加してください。
.env.exampleも作成してください。
■ 安全対策
開発中はWordPressの記事を絶対に自動公開しないでください。
投稿時のstatusは必ず
draft
としてください。
publishを指定する機能は現段階では実装しないでください。
APIエラーが発生した場合は投稿処理を中止してください。
既存のWordPress記事を変更・削除する機能も実装しないでください。
■ AI記事生成
将来的にはOllamaのローカルLLMを使用して、
API料金なしで記事を生成したいです。
そのため記事生成部分は、
ArticleGenerator
などの独立したクラスまたはモジュールにして、
後から使用するLLMを変更できる設計にしてください。
最初はOllamaを使用する前提で設計してください。
Ollamaの接続先は、
http://localhost:11434
を想定しています。
使用モデル名は.envまたは設定ファイルから変更できるようにしてください。
■ 記事生成ルール
AIは以下のルールを守るようにしてください。
・日本語で記事を書く
・初心者にも理解できる文章にする
・存在しない料金や機能を作らない
・確認できない情報を事実として断定しない
・実際に使用していないサービスについて
「使ってみた」「利用した」などと書かない
・架空の体験談を生成しない
・架空の口コミを生成しない
・過度なアフィリエイト訴求をしない
また、
[HUMAN_REVIEW_REQUIRED]
というマーカーを本文へ挿入できるようにしてください。
実体験、スクリーンショット、感想など、
人間による追記が必要な場所で使用します。
■ ローカル保存
生成した記事はWordPressへ送信する前に、
ローカルにも保存してください。
例えば、
output/
article-name/
article.md
article.html
metadata.json
のような構造を想定しています。
metadata.jsonには、
title
slug
description
keyword
created_at
wordpress_post_id
status
などを保存してください。
■ ログ
logsディレクトリを作り、
・記事生成
・WordPress接続
・投稿成功
・投稿失敗
・エラー内容
を記録してください。
パスワードやAPIキーなどの機密情報はログに残さないでください。
■ 将来的に追加したい機能
今回は実装しなくて構いませんが、
将来的に以下を追加できる構造にしてください。
・Google Search Console API連携
・既存記事との重複チェック
・キーワード管理
・アフィリエイト案件管理
・内部リンク候補生成
・アイキャッチ画像生成
・WordPressメディアアップロード
・カテゴリー自動設定
・タグ自動設定
・記事リライト候補抽出
・定期実行
■ 最初にやってほしいこと
まだコードを書かないでください。
まず、
1. システム全体の構成
2. ディレクトリ構成
3. 必要なPythonライブラリ
4. WordPress側で必要な設定
5. Ollama側で必要な設定
6. 実装する順番
7. セキュリティ上の注意点
を提示してください。
私が設計を確認した後で、
第1段階の実装を指示します。
最初に目的を明確にする
ここでは、最終的に何を作りたいかを伝えています。
単に「WordPressへ投稿するプログラム」と指定すると、固定文章を投稿するだけの簡単なプログラムになる可能性があります。
最終的な目的は、
「記事テーマを入力 → AIで記事生成 → WordPress REST APIで下書き投稿」
までを自動化することです。いきなりコードを書かせない
ここが重要で、最初から実装させるとこちらが想定していない構成になる可能性があります。
なので今回は設計→自分で確認→実装の流れになるようにしています。
いきなり全機能を実装しないでください。
最初に現在のワークスペースを確認し、
必要な機能、ディレクトリ構成、使用ライブラリ、
実装手順、WordPress側で必要な設定を提案してください。基本機能を具体的に列挙する
ここでは、Codexに「自動投稿」の意味を推測させないため、機能を明確に指定します。
1. 記事テーマを入力
2. AIで記事タイトルを生成
3. 記事構成（H2/H3）を生成
...認証情報をソースコードへ書かせない
WordPressのアプリケーションパスワードなどをPythonコードへ直接書き込むと、もしGitHubなどで公開した際に認証情報まで公開されてしまうリスクがあります。
そこで、認証情報は.envから読み込むように指定します。
WORDPRESS_URL
WORDPRESS_USERNAME
WORDPRESS_APP_PASSWORD
認証情報をPythonコードへ直接記述してはいけません。
.envは.gitignoreへ追加してください。draft固定にして事故を防ぐ
ここは特に重要な安全対策です。
WordPress REST APIはpublishを指定するとそのまま記事を公開できます。
開発途中のプログラムが誤動作して、記事がそのまま公開されてしまうのを防ぐため、下書き投稿に固定しています。
投稿時のstatusは必ず
draft
としてください。
publishを指定する機能は現段階では実装しないでください。さらに、
既存のWordPress記事を変更・削除する機能も実装しないと指示することで亀山記事への影響も抑えています。
Ollamaを後から差し替えられる設計にする
ここは将来的な拡張のための指示です。
今回はローカルLLMであるOllamaで記事を書くことを想定していますが、Ollama専用の処理をWordPressの処理と一体化させてしまうと、後から別のLLMへ変更する際の修正範囲が広がってしまいます。
そこで、LLMの部分を独立させることで後から差し替えられるようにします。
ArticleGenerator
などの独立したクラスまたはモジュールにして、
後から使用するLLMを変更できる設計にしてください。AIに体験談を作らせない
AIで記事を書かせた場合、エピソードを捏造してくる可能性があります。
そこで、事実と体験談を勝手に書かないように指定します。
・実際に使用していないサービスについて
「使ってみた」「利用した」などと書かない
・架空の体験談を生成しない
・架空の口コミを生成しない人間が追記する部分を残す
ここで、AIでは書けない部分を後から追記できるようにするマーカーを指定します。
[HUMAN_REVIEW_REQUIRED]例えば、
実際に使って感じたこと
[HUMAN_REVIEW_REQUIRED]としておけば、下書きを確認するときに自分の感想などを追記する部分が分かります。
WordPressへ送信する前にローカルへ保存する
WordPressへ送信した記事だけが残る設計にすると、投稿失敗時の確認や再利用が面倒になります。
そこで、ローカル保存→内容確認→WordPressという流れにします。
output/
article-name/
article.md
article.html
metadata.json将来追加する機能を先に伝える
今回は実装しませんが、将来追加したい機能をあらかじめCodexに伝えます。
これを入れることで、後から機能追加しやすい構造になるようにしてくれます。
・Google Search Console API連携
・既存記事との重複チェック
・アフィリエイト案件管理
・内部リンク候補生成
...最後に念押しする
一番最後に、もう一度「まだコードを書かないでください」と指示しています。
これはCodexが途中の要件を読んでそのまま実装へ進むのを防ぐためです。
まだコードを書かないでください。このプロンプトでは以下の3点を重視しました。
- いきなり実装させない
- WordPressへの投稿をdraft固定にする
- 認証情報を.envで管理する
そしてCodexから返ってきた返答を要約すると、
記事テーマを入力
↓
Ollamaで記事を生成
↓
内容を検証
↓
Markdown / HTML / metadata.jsonとして保存
↓
人間が内容を確認
↓
WordPress REST APIで下書き投稿
↓
投稿結果をログへ保存といった流れを提案されました。
また、記事生成を担当するArticleGenerator、WordPressとの通信を担当するWordPressClient、記事を保存するArticleRepositoryなど、機能ごとに処理を分ける構成が提案されました。
実装についても一度にすべて作るのではなく、
- 安全な基本部分を作成
- Ollamaによる記事生成
- ローカルへの保存・検証
- WordPressとの接続確認
- WordPressへの下書き投稿
- 総合テスト
と段階的に進める方針になりました。
WordPressへの投稿はdraftに固定し、既存記事の更新や削除機能は作らないなど、安全面も考慮されていました。
また、アプリケーションパスワードなどの認証情報は.envで管理し、ログやGitに認証情報が残らない構成になっています。
今回はまずWordPressへの自動投稿ができることを確認したいので、すべての機能を一度に実装せず、WordPressとの認証確認から進めていきます。
5.2. WordPressの認証確認だけ実装
最初のプロンプトでは、Codexにシステム全体の設計をしてもらいました。
ただし、いきなりすべて実装するとWordPress側の認証やREST API設定で問題があった際に原因の切り分けが難しくなります。
そこで、まずはWordPress REST APIへ正常に接続できるかどうかだけを確認するように指示します。
設計内容は問題ありません。
ただし実装順序を少し変更します。
まずWordPress REST APIとの接続可否を確認したいです。
第1段階として、以下だけを実装してください。
1. 最小限のPythonプロジェクトを作成
2. .env.exampleを作成
3. .gitignoreを作成し、.envを除外
4. pydantic-settingsまたはpython-dotenvで.envを読み込む
5. httpxを使用してWordPress REST APIへ接続する
6. GET /wp-json/wp/v2/users/me で認証確認できる機能を作る
7. 認証成功時はユーザーIDとユーザー名だけを表示する
8. Application Passwordなどの認証情報はログや画面に表示しない
9. この段階ではPOST、記事作成、更新、削除は一切実装しない
WordPress側で必要な設定についても手順を説明してください。
私が.envを設定して接続テストを実行するまで、
実サイトへの書き込み処理は追加しないでください。
Pythonプロジェクトと認証情報の管理
ここでは、WordPressへ接続するための最低限のPython環境を作成します。
WordPressのユーザー名やアプリケーションパスワードはソースコードに直接書かず、.envから読み込むようにします。
また、.envを.gitignoreへ追加することで、GitHubなどへ誤って認証情報を公開することも防ぎます。
1. 最小限のPythonプロジェクトを作成
2. .env.exampleを作成
3. .gitignoreを作成し、.envを除外
4. pydantic-settingsまたはpython-dotenvで.envを読み込むWordPress REST APIへの接続確認
httpxはPythonからHTTP通信を行うためのライブラリです。
今回はWordPress REST APIの
GET /wp-json/wp/v2/users/meへアクセスします。
このAPIは認証中のWordPressユーザー情報を取得するためのものです。
つまり、Python→WordPress REST API→アプリケーションパスワード認証が正常に動作しているかを確認できます。
5. httpxを使用してWordPress REST APIへ接続する
6. GET /wp-json/wp/v2/users/me で認証確認できる機能を作る認証情報を必要以上に表示しない
認証テストでは接続できたことが分かれば十分なので、成功時に表示する情報をユーザーIDとユーザー名だけに限定し、アプリケーションパスワードなどの機密情報がコンソールやログに表示されないようにします。
7. 認証成功時はユーザーIDとユーザー名だけを表示する
8. Application Passwordなどの認証情報はログや画面に表示しないWordPressへはまだ送信しない
WordPress REST APIでは、POSTを使用すると記事を新規作成します。
しかし、この時点では接続確認が目的なので読み取り専用のGETだけに限定します。
これにより問題があっても既存記事を書き換えたり新しい記事を作成したりすることはありません。
9. この段階ではPOST、記事作成、更新、削除は一切実装しないWordPressのような実サイトを操作する場合は最初から書き込み機能を実装せず、まず読み取り専用のAPIで認証確認を行うようにしました。
5.3. 仮想環境作成指示
指示を出した後、ライブラリインストールの承認確認画面が表示されました。
「一度だけ許可」を選択すれば、表示されているコマンドが実行されてライブラリがインストールされます。
ここで、仮想環境が作成されておらず、グローバル環境にそのままインストールしようとしていることに気づきました。
本来は仮想環境を作成し、その中にライブラリをインストールするのがセオリーなのですが、今回のプロンプトではその指示が抜けていました。
ここでは一旦「拒否」を選択して処理を停止させて、次のプロンプトを送信して仮想環境.venvを作成させました。
仮想環境を使用してください。
プロジェクト直下に .venv を作成し、
以降のPython、pip、pytestの実行には
必ず .venv 内のPythonを使用してください。
依存ライブラリもすべて .venv にインストールしてください。
また、
.venv/
を .gitignore に追加してください。
グローバルPython環境にはライブラリをインストールしないでください。5.4. WordPressの認証テスト
仮想環境が作成されたのを確認したら、改めてWordPress認証テストを行うため以下のプロンプトを送信しました。
次の段階として、WordPressへの読み取り専用認証テストを行います。
まず、.env.example を元に .env を作成してください。
ただし、認証情報そのものは私が手動で入力します。
.env 作成後は、必要な設定項目だけ説明してください。
その後、私が認証情報を入力したことを確認してから、
GET /wp-json/wp/v2/users/me の認証テストだけを実行してください。
重要：
・POST / PUT / PATCH / DELETE は実行しない
・記事の作成、更新、削除は行わない
・Application Passwordを画面やログに表示しない
・認証失敗時も認証情報を含むレスポンスを表示しない実行中に、再びライブラリインストールの認証画面が表示されました。
今回は.venvが指定されていることが確認できたので、「一度だけ許可」を選択してライブラリインストールを実行しました。
Codexが.envを作成してくれました。
この時点ではWordPressのユーザー名とアプリケーションパスワードは設定されていません。
認証情報はCodexに入力するのではなく、WordPressでアプリケーションパスワードを発行し、自分で.envに設定します。
5.4.1 WordPressでアプリケーションパスワードを設定
次に、.envに記載するためのアプリケーションパスワードを取得します。
まず、WordPressの管理画面に入り、ユーザーメニューからユーザー名を選択します。
ユーザー名を選択するとプロフィール設定画面に映るので、下の方へスクロールすると「アプリケーションパスワード」を設定する項目があります。
ここに、アプリケーションパスワードを識別する名前を付けて、「アプリケーションパスワードを追加」を選択します。
アプリケーションパスワードを追加すると、本物のパスワードが表示されます。
そして、.envを開き、取得したユーザー名とアプリケーションパスワードを入力します。
※ アプリケーションパスワードはスペースで区切られていると思いますが、そのまま記載します。
5.4.2. WordPressの認証テスト
.envにユーザー名とアプリケーションパスワードを設定したら、Codexに
設定完了と伝えます。
これにより、認証が成功したことが確認できました。
5.5. テスト記事投稿
最後に、WordPressへテスト記事の投稿を行います。
認証テスト成功を確認しました。
次の段階として、
WordPress REST APIを使用してテスト記事を1件だけ新規作成する機能を追加してください。
条件：
・POST /wp-json/wp/v2/posts のみ使用
・status はコード内部で必ず draft 固定
・publish は実装しない
・既存記事の更新、削除は実装しない
・PUT / PATCH / DELETE は実装しない
・投稿前に送信予定のタイトルと本文をコンソール表示する
・実行前に確認を求める
・成功時は WordPress の post ID と URL を表示する
・失敗時は認証情報をログや画面に表示しない
・重複実行で同じ記事が複数作成される可能性がある場合は警告する
テスト記事は以下です。
タイトル：
Codex WordPress REST API テスト
本文：
<p>Codexで作成したWordPress REST API連携のテスト記事です。</p>
投稿ステータス：
draft
まずコードを実装してテストしてください。
実サイトへPOSTする直前で私に許可を求めてください。新規投稿に限定
ここでは、WordPress REST APIで使える操作を新規投稿に限定しています。
POST /wp-json/wp/v2/postsは新しい投稿を作成するためのエンドポイントです。
一方、既存記事の編集や削除まで実装すると誤操作したときに既存記事に影響する可能性があります。
・POST /wp-json/wp/v2/posts のみ使用
・既存記事の更新、削除は実装しない
・PUT / PATCH / DELETE は実装しない公開ではなく下書き
前述したとおり、WordPressはstatusにpublishを指定するとそのまま公開できてしまいます。
今回は動作確認なので、記事が意図せず公開されてしまわないようにdraftで固定しています。
・status はコード内部で必ず draft 固定
・publish は実装しない投稿前に内容を確認できるようにする
WordPressへ送信する前に、
- タイトル
- 本文
- 投稿内容
を確認できるようにします。
これにより、Codexが想定外の内容をPOSTしようとしても事前に止められます。
・投稿前に送信予定のタイトルと本文をコンソール表示する
・実行前に確認を求める投稿後に結果を確認できるようにする
投稿成功後にWordPressから返ってきたpost IDやURLを表示させます。
これにより、API側では成功したが、どの記事が作られたのかわからないという状況を避けられます。
・成功時は WordPress の post ID と URL を表示する認証情報を表示させない
API通信エラーが発生したとき、デバッグ情報をそのまま表示するとアプリケーションパスワードなどが含まれてしまう可能性があります。
そこで、失敗しても認証情報を表示させないようにします。
・失敗時は認証情報をログや画面に表示しない二重投稿対策
POSTは実行するたびに新しい記事を作成します。
同じコマンドを2回実行すると
Codex WordPress REST API テスト
Codex WordPress REST API テストのように下書きが複数作成されてしまう可能性があります。
そこで、再実行時には警告を出すようにします。
・重複実行で同じ記事が複数作成される可能性がある場合は警告する固定したテスト記事で動作確認する
この段階では記事を書かせず、固定された短いテスト記事だけを投稿します。
これにより、記事投稿が失敗した場合の原因が切り分けやすくなります。
タイトル：
Codex WordPress REST API テスト
本文：
<p>Codexで作成したWordPress REST API連携のテスト記事です。</p>実サイトへのPOSTは最後に許可を求める
記事が完成したら、POSTするかどうかの承認を求めるようにします。
まずコードを実装してテストしてください。
実サイトへPOSTする直前で私に許可を求めてください。そして、上記のプロンプトを送信し、以下の返答が返ってきました。
問題がないことを確認し、「POSTを許可します」と返答しました。
そして下書きが投稿されたようです。
早速見に行ってみましょう。
WordPress側にも無事、下書きが投稿されているのが確認できました。
6. まとめ
今回はCodexをVS Codeに導入し、実際にPythonからWordPress連携を行い下書きを投稿するシステムを構築しました。
Codexに要件をまとめたプロンプトを入力することで、ファイルの作成からライブラリのインストール、テスト投稿まで進めることができました。
その間、.env以外のファイルは一度も開くことなくできてしまったのは驚きです。
今回のような認証を伴うシステムを構築する際には、セキュリティや安全を考慮したうえで指示内容を細かく指定する必要があると思います。
ただ、「WordPress自動投稿プログラムを作成して」とだけ指示した場合はどこまでやってくれるのか、興味はありますね。時間があれば試してみたいところ。
今後はOllamaなどで実際に記事投稿が自動化できるのか試してみたいと思います。
今回は以上です。
7. 参考サイト
ChatGPT プランで Codex を使う
https://help.openai.com/ja-jp/articles/11369540-using-codex-with-your-chatgpt-plan
WordPress の REST API でアプリケーションパスワードを使った認証を行う方法
https://wordpress.dyno.design/rest-api-http-auth-with-application-passwords/
コメント