開発効率化

CodexとWP-CLIでWordPressに下書き保存する方法｜作成・更新・確認の手順

WordPressの記事をAIで作るなら、最初に自動化したいのは「完成した原稿を、確認できる下書きとして入れるところ」です。本文生成から公開まで一気に任せるより、修正する場所と公開するタイミングを分けると扱いやすくなります。

この記事では、CodexなどのAIで原稿を整え、WP-CLIでWordPressへ下書き保存する最小の流れを紹介します。SSHとWP-CLIが利用できる環境を前提にしています。

先に決めるのは、原稿・投稿ID・公開の3つ

  • 原稿：本文はHTMLファイルとして保存する
  • 投稿ID：作成時に返されたIDを使い、修正は同じ記事に反映する
  • 公開：最初は下書き。WordPressのプレビューで確認してから公開する

繰り返し実行するたびに新しい記事を作らないことがポイントです。AIへの編集指示と、WordPressへの保存操作も分けておきます。

原稿作成、ローカルでの確認、WP-CLIによる下書き保存、WordPressでの公開前確認というブログ運用の流れ
原稿を作る工程と、サイトに反映する工程を分ける。

1. 本文をHTMLファイルにする

例えば、記事本文を article.html に保存します。WordPress側でタイトルを表示するため、本文に同じタイトルのH1を重ねず、セクションはH2から始めます。

<p>この記事で解決する困りごとを、最初に短く書きます。</p>
<h2>必要なもの</h2>
<p>前提条件と、対象外のケースを書きます。</p>
<h2>手順</h2>
<p>操作と確認方法を順に書きます。</p>

AIには「いい感じの記事にして」だけでなく、読者、解決したい問題、確認済みの事実を渡します。未確認の体験談や効果を足させないことも大切です。

原稿をファイルにしておくと、段落の入れ替えや差分の確認ができます。下書きの管理は手元のフォルダでも非公開リポジトリでも構いません。特定のノートアプリは必須ではありません。

2. WP-CLIで下書きを1本作る

次はWP-CLIの基本例です。対象サイトのWordPressディレクトリで実行し、article.htmlをその実行環境から読める場所に置きます。ローカルのファイルが、SSH接続先にも存在するとは限りません。

wp post create article.html \
  --post_type=post \
  --post_status=draft \
  --post_title='記事タイトル' \
  --post_name='article-slug' \
  --porcelain

--porcelain は作成した投稿IDだけを返す指定です。ここで返されたIDを控えます。コマンドの成功表示は、記事の品質や公開画面の見た目まで保証するものではありません。

引数の仕様は WP-CLI公式の wp post create で確認できます。

3. 修正は同じ投稿IDへ反映する

原稿を直したら、もう一度createするのではなく、対象の投稿IDを指定して更新します。次の123は例なので、実際に返されたIDへ置き換えてください。

wp post get 123 --fields=ID,post_title,post_status,post_name
wp post update 123 article.html --post_status=draft

これは下書きを編集するときの例です。公開済みの記事にそのまま使うと、下書きへ戻してしまいます。既存記事の改稿では、先に現在の状態と原本を保存し、意図した項目だけを更新します。

途中で通信が切れて結果が分からなくなった場合も、すぐにcreateし直さず、保存された投稿を確認します。二重投稿を防ぐためです。更新の指定方法は WP-CLI公式の wp post update を参照してください。

4. WordPress側で見た目と内容を確認する

ローカルのHTMLがきれいでも、WordPressではテーマの文字サイズ、余白、関連記事ブロックなどが加わります。下書きのプレビューを開き、スマホ幅でも確認します。

  • タイトルを読んで、何が分かる記事か伝わるか
  • 導入と「結論」の節で同じ説明を繰り返していないか
  • 図の文字とコードがスマホで読めるか
  • 画像URLに手元のファイルパスが残っていないか
  • 手順の前提条件と、失敗したときの確認方法があるか
  • 出典と関連記事のリンクが開くか
  • 未検証の数値や、実際にはしていない体験が入っていないか

保存用コマンドと公開操作を分けておけば、原稿を更新しただけで意図せず公開される事故を避けやすくなります。

Mac mini＋共有サーバーでは、実行する場所を分ける

このサイトでは、Mac miniから既存のSSH経路を使い、Xserver側のWordPressをWP-CLIで扱えることを確認しています。2026年10月3日の読み取り確認では、公開記事の一覧と保存本文を取得できました。

この確認は、読み取り経路が使えるという意味です。すべてのサーバーで同じコマンド構成が使える、プラグイン操作や更新も安全に自動化できる、という保証ではありません。PHPの選択やWP-CLIの入口は利用環境に合わせる必要があります。

認証情報を記事原稿やAIへの指示文へ貼り付ける必要はありません。既に設定した接続経路を使い、作業対象のサイトと投稿IDを明示します。

最初から増やさなくていい仕組み

まずは「原稿ファイル1つ、下書き1本、投稿ID1つ」で十分です。記事を継続して増やす必要が出てから、画像の取り扱いや共通テンプレートを整えます。

記事数が少なく、ブロックエディターだけで困っていないなら、CLIを導入しない選択もあります。自動化のための管理作業を増やさないことも大切です。

次に読む記事

2026年10月3日更新。コマンド例はWP-CLI公式仕様に基づく説明例です。個別環境での導入・書き込みテスト結果を示すものではありません。

-開発効率化