ブログ記事を書くとき、意外と時間がかかるのが「WordPressへ入稿する作業」です。
原稿そのものが完成していても、WordPressの管理画面を開き、タイトルと本文を貼り付け、カテゴリーやタグを選び、画像をアップロードし、表示を確認する必要があります。
一つひとつは小さな作業ですが、記事を継続的に発信しようとすると、この積み重ねが負担になります。
そこで今回、CodexとWordPressを接続し、会話の中で作成した記事をWordPressへ下書き入稿できる仕組みを構築しました。
重要なのは、完全自動公開ではなく、人間が最終確認できる「下書き入稿」までを自動化したことです。
この記事では、実際に構築した仕組み、費用、安全面での工夫、途中で発生した問題、今後の運用方法を記録します。
今回実現したこと
今回の仕組みでは、Codexから次の操作ができます。
- WordPressとの接続・認証確認
- WordPressに登録されているカテゴリーの取得
- WordPressに登録されているタグの取得
- 記事タイトル・本文・抜粋・スラッグの設定
- カテゴリーとタグを指定した下書き作成
- 既存の下書き記事の更新
- 画像のメディアライブラリへのアップロード
- アイキャッチ画像の設定
- WordPress編集画面とプレビューURLの取得
一方で、意図しない公開を防ぐため、記事を公開する機能はあえて実装していません。
Codexができるのは、WordPressへ下書きを作成・更新するところまでです。最終的な確認と公開はWordPressの管理画面で人間が行います。
なぜ完全自動公開にしなかったのか
技術的には、WordPress REST APIを使って記事を直接公開することもできます。
しかし、ブログ記事には次のような最終確認が必要です。
- 事実関係に誤りがないか
- 個人情報や勤務先を特定できる情報が含まれていないか
- 見出し構成が崩れていないか
- 画像の表示や代替テキストが適切か
- カテゴリーとタグが正しいか
- 内部リンク・外部リンクが正しいか
- 公開日時に問題がないか
この確認までAIに任せて自動公開すると、誤りや意図しない情報がそのまま外部へ出る可能性があります。
そのため今回は、次のように役割を分けました。
- Codexが記事を整理する
- CodexがWordPressへ下書き入稿する
- 人間がプレビューを確認する
- 人間がWordPress管理画面から公開する
自動化の目的は、人間の判断をなくすことではありません。判断が必要ない転記作業を減らし、人間が内容の確認に集中できる状態をつくることだと考えています。
システムの全体構成
今回の構成はシンプルです。
記事の素材・指示
↓
Codex
↓
個人用WordPress連携プラグイン
↓ HTTPS
WordPress REST API
↓
WordPressの下書き記事・メディアライブラリCodexに個人用プラグインを追加し、そのプラグインからWordPress標準のREST APIを呼び出しています。
外部の自動化サービスを中継せず、Codexと自分のWordPressサイトが直接通信する構成です。
WordPress REST APIとは
WordPress REST APIは、WordPressの記事やカテゴリー、タグ、画像などを外部プログラムから扱うための標準機能です。
たとえば、記事の下書き作成には次のようなエンドポイントを利用します。
POST /wp-json/wp/v2/posts画像のアップロードには、次のエンドポイントを利用します。
POST /wp-json/wp/v2/media今回の仕組みでは、記事作成時のステータスを必ず draft に固定しています。
{
"title": "記事タイトル",
"content": "記事本文",
"status": "draft"
}また、プラグイン側には公開用の操作自体を用意していません。単に運用ルールで禁止するだけでなく、システム上も公開できないようにしています。
認証にはApplication Passwordを使用
WordPressへの接続には、通常のログインパスワードではなく、WordPressのApplication Passwordを使用しました。
Application Passwordは、外部ツールやアプリケーションからWordPressへ接続するための専用認証情報です。
主な利点は次のとおりです。
- 通常のログインパスワードを外部ツールへ渡さずに済む
- 用途ごとに個別の認証情報を発行できる
- 不要になった認証情報だけを失効できる
- 通常のWordPressログインには利用できない
今回は、Codex連携専用のApplication Passwordを新しく発行しました。
認証情報をファイルへ保存しない
Application Passwordをソースコードや設定ファイルへ直接書くと、バックアップやGitへのコミット、画面共有などを通じて漏れる可能性があります。
そこで認証情報は、macOSのキーチェーンへ保存しました。
WordPress連携プラグインは、実行時にキーチェーンから認証情報を読み出します。
Codexプラグイン
↓
macOSキーチェーンから認証情報を取得
↓
WordPressへHTTPS接続これにより、Application Passwordを次の場所へ残さずに運用できます。
- Codexとの会話
- Markdown原稿
- プラグインのソースコード
- 通常の設定ファイル
- シェルのコマンド履歴
秘密情報は便利さよりも管理方法が重要です。特に自動化では、一度設定すると存在を忘れやすいため、後から個別に失効できる認証方式が適しています。
実際に発生したTLS証明書の問題
構築中、WordPressの公開ページはブラウザで正常に表示できる一方、プログラムからHTTPS接続すると証明書の検証に失敗する問題が発生しました。
原因を調べると、サイトではLet’s Encryptの新しいGeneration Y系の証明書チェーンが使われていました。実行環境側の標準的な信頼ストアが新しいルート証明書へまだ追随しておらず、接続先の正当性を検証できない状態でした。
ここで、TLS証明書の検証を無効化すれば接続自体はできます。
しかし、その方法では通信相手が本物のWordPressサイトであることを保証できません。認証情報を送信する用途では採用すべきではないと判断しました。
今回は、Let’s Encrypt公式の新しいルート証明書を接続時に明示し、次の条件を守る形で対応しました。
- TLS証明書の検証を無効化しない
- 接続先ホスト名を検証する
- 公式の認証局証明書だけを利用する
- 認証情報を暗号化されたHTTPS通信で送る
最終的に、証明書が正しく検証された状態でWordPress REST APIへの接続に成功しました。
自動化では「動くこと」に目が向きがちですが、認証情報を扱う処理では、動かすことより安全に動かすことが重要だと改めて感じました。
接続テストで確認したこと
Application PasswordをmacOSのキーチェーンへ登録したあと、書き込みを行わない接続テストを実施しました。
確認結果は次のとおりです。
- WordPressサイトへの接続：正常
- Application Passwordによる認証：正常
- 認証されたユーザー：想定どおり
- 投稿に必要な権限：あり
- 記事・メディアへの書き込み：未実行
いきなりテスト記事を投稿するのではなく、最初に読み取り専用の接続確認を行いました。
これにより、サイトURL、ユーザー名、認証情報、TLS通信、WordPress側の権限がすべて正しく設定されていることを、WordPressの内容を変更せずに確認できました。
実際の利用イメージ
今後はCodexに、たとえば次のように依頼できます。
この記事をWordPressへ下書き入稿して。
入稿前にタイトル、スラッグ、カテゴリー、タグを確認させて。想定する処理の流れは次のとおりです。
- Codexが記事をMarkdownまたはHTMLとして整える
- WordPressからカテゴリーとタグの一覧を取得する
- 記事に適したカテゴリー・タグを提案する
- タイトル、スラッグ、カテゴリー、タグを人間が確認する
- 必要な画像をWordPressへアップロードする
- 記事を下書きとして作成する
- 編集画面とプレビューURLを返す
- 人間が最終確認して公開する
この形であれば、記事の内容を確認する前に勝手に入稿されたり、公開されたりすることを防げます。
費用はかかるのか
今回利用したWordPress REST APIは、WordPressの標準機能です。REST APIの呼び出し自体に追加料金はかかりません。
また、外部の有料自動化サービスや、別契約のOpenAI APIキーを中継する仕組みも使用していません。
そのため、今回の構成で新たに必要になった従量課金サービスはありません。
ただし、次の費用は別です。
- 既存のWordPressサーバー・プラン料金
- 独自ドメイン料金
- 利用中のCodexプランまたは利用枠
- 将来、有料の画像生成・校正・SEOサービスなどを追加した場合の料金
「WordPressへ入稿するためのAPI利用料」が別途発生するわけではない、という理解です。
この仕組みで減らせる作業
今回の自動化で減らしたいのは、主に次のような作業です。
- 完成原稿をWordPressへ貼り付ける
- 見出し構造を再調整する
- スラッグを入力する
- カテゴリーとタグを探して設定する
- 画像をメディアライブラリへ登録する
- アイキャッチ画像を指定する
- 入稿後の編集画面を探す
一方、次の判断は人間が行います。
- その内容を本当に発信するか
- 事実と解釈が適切に分かれているか
- 個人や組織を特定する情報が含まれていないか
- 読者に誤解を与えないか
- いつ公開するか
自動化する部分と、人間が責任を持つ部分を明確に分けることが、このシステムの中心です。
今後追加したい機能
現時点では、安全性を優先して下書き入稿までに限定しています。
今後は、運用しながら次の機能を検討します。
- MarkdownからWordPressブロックへの変換改善
- 記事内画像の自動配置
- 既存記事との内部リンク候補の提案
- カテゴリー・タグの重複防止
- SEOタイトルとメタディスクリプションの下書き
- アイキャッチ画像の候補生成
- 入稿前チェックリストの自動実行
- 下書き記事の差分確認
- 記事公開後のリンク切れ確認
ただし、公開処理まで自動化するかどうかは慎重に判断します。
効率だけを追うと、誤った情報を高速で公開する仕組みにもなり得ます。まずは下書き入稿を安定させ、人間の確認を含めた運用を定着させる予定です。
まとめ
今回、CodexとWordPress REST APIを接続し、ブログ記事の下書き入稿を自動化する個人用システムを構築しました。
ポイントは次のとおりです。
- WordPress標準のREST APIを利用した
- 外部の有料自動化サービスは利用していない
- 通常のログインパスワードは使わず、Application Passwordを利用した
- 認証情報はmacOSのキーチェーンへ保存した
- TLS証明書の検証を無効化せずに接続した
- 記事は必ず下書きとして保存する
- 公開機能は意図的に実装していない
- 最終確認と公開は人間が行う
AIによる自動化というと、すべてを任せるイメージがあります。
しかし実際には、どこまで機械に任せ、どこから人間が判断するかを設計することが最も重要でした。
今回つくったのは、記事を勝手に公開するシステムではありません。
思考や経験を発信できる形に整え、面倒な転記作業を減らしながら、最後の責任は自分で持つための仕組みです。
これから実際の記事で運用し、どこまで負担が減るのか、どんな改善が必要になるのかも継続して記録していきます。
この記事の内容はnoteにもまとめています。あわせて、note版の記事もご覧ください。
