WordPress自動入稿の実装事例|Claude Code × WP REST API
WordPressの入稿作業に毎回30分〜1時間も取られていませんか?本文の貼り付けや見出し調整、カテゴリ・タグ設定、メタディスクリプション入力、サムネイル登録など……。記事の価値を上げる作業ではなく『整える作業』ばかりに時間が消えていくことに不満を感じている方も多いはずです。
私自身、Webライターとして仕事を増やしたいのに、入稿に時間を取られて執筆量が伸びない時期が続きました。私は工場勤務20年からWebライターに転身したばかりで、業界歴は数年と浅い人間です。だからこそ「仕組みで効率化しないと先輩ライターには追いつけない」と考え、Claude Codeに自動入稿スクリプトを実装してもらいました。
本記事では実際に使っているWordPress自動入稿の実装事例を、私というWebライターの視点でまとめます。記事を読めば、煩わしいWordpressへの入稿時間を短縮でき、本当に価値あることに自分の時間を使うことが可能です。
Claude CodeとWP REST API(外部のサービスをプログラムから呼び出す接続方式)を組み合わせれば、Markdown(文章の見出しや箇条書きを記号で書く軽量記法)原稿から下書き登録までを素早く終えられます。
効果的にClaude CodeからのWordpress自動入稿の環境を整える鍵は、『下書きまで自動/公開判断は人間』の線引きをすることです。完全自動公開はリスクが大きく、入稿作業だけ自動化するほうが安全だと実装の中で痛感しています。
↓実際に私が実装した流れ、Claude Codeへの指示を詳細に書いています↓

WordPress入稿で毎回30分消えていた理由と自動化を決めた経緯

最初に、私がWordPress自動入稿を実装した動機をお話しします。リアルな体験の共有と読者の皆さんにの気づきのきっかけになる話として、以下の項目に分けて解説します。
- 入稿のたびに30分が消えていた現実
- 『整える作業』より『確認する作業』に時間を使いたかった
入稿のたびに30分が消えていた現実
私が普段請けているSEO記事は、1本あたり5,000〜10,000字ほどの分量があるのが普通です。執筆そのものはClaude Codeとペアで進めれば数時間で形になるのですが、問題は入稿でした。以下の一連の作業に毎回30分、長いときは1時間ほど消えていました。
- Markdown原稿をWordPressのブロックエディターに貼り付け
- 見出しを整える
- 内部リンク差し込み
- カテゴリ・タグ選び
- メタディスクリプション入力
- アイキャッチや見出し画像挿入
特につらかったのは、原稿の品質と関係なくこの時間が必ず発生する点です。執筆スキルを上げても入稿時間は減りません。記事の本数を増やそうとすると、入稿時間が線形に増えていきました。
Webライターを本業にしている以上、入稿にかかる時間を単修することが、月の収入に大きく関係します。
「整える作業」より「確認する作業」に時間を使いたかった
入稿で消えていた30分を分解すると、ほとんどが『手で整える作業』でした。見出しレベルを揃える、リストを調整する、画像をアップして本文に挿し込む、といった機械的な操作です。一方で本当に時間をかけたいのは、公開前の『確認する作業』のほうだと感じていました。
確認する作業とは、事実関係に間違いがないか、内部リンクの飛び先が正しいか、メタディスクリプションが検索意図とずれていないかといった判断系の作業です。判断系は私の仕事の価値に直結しますが、整える作業はそうではありません。
Claude Codeに記事の入稿まで任せることができれば、整える作業を全部任せて私は確認する作業だけに集中できる。そう思ったことが自動化を決めた最大の理由です。
WordPressへ自動で記事を送れる仕組みとClaude Codeの使い方

WordPress自動入稿は『WP REST APIに必要な情報をJSON(プログラム間でデータをやり取りするための共通フォーマット)で送る』ことで成立しています。Claude CodeによるWordpress自動入稿の仕組みと買い方について、以下の3点に分けて解説します。
- WordPressにClaude Codeを用いて自動で送れる情報の種類
- Claude Codeがどうやって自動入稿を動かしているか
- 設定ファイルでサイトURLとパスワードを分けて管理する理由
WordPressにClaude Codeを用いて自動で送れる情報の種類
Claude CodeからWordPressに記事を送るときは、「WP REST API」という仕組みを使います。WP REST APIはWordPressが用意している『記事の受付窓口』のようなもので、POST /wp/v2/postsというアドレスに情報を送ると、新しい記事を作ってくれます(※1)。
WP REST APIを用いて送れる情報は以下のとおりです。
- タイトル
- 本文
- 公開ステータス(下書き・公開など)
- カテゴリ
- タグ
- スラッグ(URLに使われる記事の名前)
- メタディスクリプション(検索結果に表示される説明文)
- アイキャッチ画像のID
なかでも重要なのが公開ステータスで、指定できる種類は以下の5つです。
- publish(すぐに公開)
- future(予約投稿)
- draft(下書き)
- pending(承認待ち)
- private(非公開)
私は必ず『draft』で送る設計にしています。下書きで送れば、自分の目で記事内容を確認してから安全に公開できます。AIが書いた文章をそのまま世に出してしまうと、誤情報が広がるリスクも。一度下書きに置くワンクッションを挟むことで、リスクをゼロにできます。
なお、カテゴリやタグは名前ではなく『ID』という番号で管理されている点に注意が必要です。私のスクリプトでは、まず既存のカテゴリやタグをAPIで検索し、見つからなければ新しく作ってIDを取得する、という処理を自動で行うようにしています。
※1 参考:WordPress Developer Resources「REST API Handbook」(外部サイト)
Claude Codeがどうやって自動入稿を動かしているか

私のスクリプトは、Python(Web開発で広く使われるプログラミング言語)で書かれた publish_article.py という1ファイルです。Claude CodeにMarkdown原稿のパスとカテゴリ名・タグ名を伝えると、以下の作業を一気に実行してくれます。
- 原稿をHTMLに変換
- 内部リンク挿し込み
- サムネイルをアップロード
- WP REST APIへPOST(サーバーへデータを送信する操作)
私が普段Claude Codeに伝えているのは『原稿のパス』『公開先サイト』『カテゴリ』『タグ』の4点だけです。あとはClaude CodeがPythonスクリプトを呼び出し、API応答を確認し、エラーがあればリトライ(失敗時の自動再試行)までしてくれます。私は最終的に管理画面でプレビューを開き、装飾と内部リンクの飛び先を確認するだけで済みます。

Claude Codeに毎回スクリプトを書き直してもらうのではなく、1本のPythonスクリプトを再利用する設計にしておきましょう。Wordpress自動入稿の挙動が安定して再現性が高くなります。
設定ファイルでサイトURLとパスワードを分けて管理する理由
スクリプト本体には、サイトURLや認証情報を直接書いていません。代わりに .env(APIキーやパスワードを安全に管理するための設定ファイル)に切り出して、Pythonの os.getenv で読み込む構造にしています。.envに切り出す理由は単純で、認証情報を直接Claudeが読み取ってしまうと、APIのキーが漏洩してしまう恐れがあるからです。
設定の分離は『使い回しのしやすさ』にも関係します。私は本サイトのほかにWebライターとしてのポートフォリオサイトを持っており、.env を差し替えるだけでスクリプト本体は一切変えずに流用できる構造です。
汎用設定ファイルとClaude Codeへ投げるプロンプト集は、noteにまとめる予定です。公開したらこの記事にもリンクを追記します。
Claude Codeに頼んで自動入稿を動かす3つの処理

私のスクリプトは大きく3つの処理に分かれており、それぞれのキーとなるコードを抜粋しながら順番に紹介します。扱う処理は以下のとおりです。
- 接続|WordPressへの接続を設定する(専用パスワードの発行方法)
- 投稿|カテゴリとタグを自動で設定できるようにする
- サムネイル設定|下書きとして保存しサムネイル画像も一緒に登録する流れ
接続|WordPressへの接続を設定する(専用パスワードの発行方法)
WordPressでは『アプリケーションパスワード』という専用の認証方式が使えます。私は管理者アカウントとは別に、自動入稿専用ユーザーを作り、そのユーザーにアプリケーションパスワードを発行する設計にしています。管理者アカウントとは別に入稿用ユーザーを設定することで、万が一アプリケーションパスワードが漏洩しても被害範囲を限定できるからです。
発行方法はシンプルで、WordPress管理画面の『ユーザー → プロフィール』下部に『アプリケーションパスワード』という項目があり、名前を入力すると24文字の英数字が払い出される仕組みです。
アプリケーションパスワードを .env に入力し、.envを絶対に読み込まないようにClaude Codeに入稿の仕組みを整えてもらいます。スクリプト本体には1文字も認証情報を書かない、という方針を徹底しています。
投稿|カテゴリとタグを自動で設定できるようにする

接続ができたら、次は投稿処理です。WP REST APIではカテゴリとタグをID(内部の管理番号)で渡す必要があるので、文字列のカテゴリ名を一度IDに変換するステップが入ります。といっても、詳細はClaude Codeが良い感じに設定してくれます。
記事内容を読み込み、存在しないタグは自動で作られます。手動でタグ管理をする手間が消えるため、私の場合はWordPress入稿時間を数分短縮できました。

タグの命名規則をClaude Code側に一覧として渡しておけば、表記揺れも防げます。
サムネイル設定|下書きとして保存しサムネイル画像も一緒に登録する流れ
最後がサムネイル登録です。WP REST APIでは、画像ファイルを POST /wp/v2/media で先にアップロードし、返ってきたメディアIDを反映するという2段階の流れになります。ただ、サムネイル設定に関する操作もClaude Codeにお任せすればよいので、詳細をユーザーが知る必要はありません。
Claude Codeに『下書き保存して』と依頼すれば自動で走ります。私は管理画面でプレビューを開いて装飾と内部リンクの最終確認だけ行えば、入稿が完了する流れです。
» AIでブログ・メディアを自動化する完全ガイド
私がつまずいた3つの失敗と対策

WordPress自動入稿の仕組みを紹介しましたが、実装の途中で何度も失敗しました。私と同じミスをしないために、以下の失敗事例を共有します。
- パスワード管理|パスワードをファイルに直書きしていたセキュリティミス
- サーバー制限|レンタルサーバーの制限と権限設定のミス
- テーマ装飾|テーマ専用の装飾が自動変換できなかった問題
パスワード管理|パスワードをファイルに直書きしていたセキュリティミス
最初に犯したのが、認証情報を publish_article.py の中に直接書いてしまうミスです。実装初期はとにかく動かしたくて、WordPressのアプリケーションパスワードをスクリプト本体に直接書き込みする設定にしていました。
動作確認は問題なく終わり、しばらくその状態で運用していました。しかし、あるときClaude Codeに「セキュリティ面は大丈夫なのかチェックして」と伝えると、アプリケーションパスワードを直接書いている点を指摘されました。Claude Codeに指摘された後に、すぐにアプリケーションパスワードを.envファイルに移動します。
ところが、.env に移しただけでは十分ではありませんでした。私はClaude Codeに作業を任せている以上、Claude Codeが .env を読み込んでチャット履歴に取り込むリスクが残っていたのです。
.claudeignore(Claude Codeへの読み込みから除外するファイルを指定する設定ファイル) と .gitignore(Gitへのアップロードから除外するファイルを指定する設定ファイル) の両方に .env を追記するまで、本当の意味では安全になっていない状態でした。
安全にアプリケーションパスワードを管理するための正しい対処は以下の4ステップです。
- 認証情報を
.envに切り出す .claudeignoreに.envを追記してClaudeから読み込ませない.gitignoreに.envを追記してGit(コードのバージョン管理ツール)に乗せない.claude/settings.local.jsonのpermissions.denyで.envのRead操作をブロックする

Claude Codeを使うときは『Gitに上げない』だけでは不十分です。Claude自身からも隠す設定を、最初に必ず仕込んでおきましょう。
サーバー制限|レンタルサーバーの制限と権限設定のミス

2つ目の失敗は、サーバー側の制限を見落としたことです。私はConohaサーバーを使っており、初期設定ではWordPress REST APIへの国外IPアクセス制限が有効になっていました。なぜ入稿できないのかがわからず、原因特定に半日かかりました。
権限設計でもミスをしました。最初は自動入稿用に管理者権限(WordPressのすべての設定を変更できる最上位の権限)のユーザーを作っていましたが、漏洩時の被害範囲を考えると過剰だと気付き、現在は『投稿者』権限(記事の作成・公開ができるWordPress権限)まで絞っています。
下書き作成だけなら『寄稿者』権限(下書きの作成のみ可能なWordPress権限)でも足りますが、自分の記事を公開まで行う運用なら投稿者で十分です。自動入稿専用アカウントには絶対に管理者権限を与えない、というのが私の運用ルールになりました。
テーマ装飾|テーマ専用の装飾が自動変換できなかった問題
3つ目はテーマ固有ブロックの問題です。私が使っているJIN:R(WordPressの有料テーマ)には、独自の装飾のブロックが多数あります。Markdownから単純にHTML変換しただけでは、JIN:Rの固有装飾が再現できませんでした。
対策として、Claude Codeに『JIN:R装飾HTMLを生成するルール』をMarkdownでまとめて渡し、原稿の段階で装飾HTMLを埋め込んだ状態でWP REST APIに送る設計に切り替えました。テーマ固有ブロックはWP REST APIの一般的な変換では再現できないので、装飾HTMLを先に生成しておき、そのHTMLをそのままClaude Codeに渡して再現してもらう形が一番確実でした。
↓実際に私が実装した流れ、Claude Codeへの指示を詳細に書いています↓

完全自動公開より「下書きまで」が安全な理由と運用フロー

実装を進める中で痛感したのが、『どこまで自動化するか』の線引きでした。技術的には完全自動公開もできますが、私は意図的に下書きまでで止めています。本H2では、その理由と私が実際に使っている8ステップの運用フローを紹介します。
AI自動公開を避けるべき理由
完全自動公開を避けている理由は、責任判断を人間が持つべきだと考えているからです。誤情報が公開された瞬間に、私のWebライターとしての信頼は大きく傷つきます。Claude CodeはMarkdownの整形やAPI送信は完璧にこなしますが、「この記事を世に出していいか」という最終判断は、現役Webライターである私自身がやるべき仕事です。
自動化するのは入稿作業であって、責任判断ではない。積金の線引きを明確にしてから、WordPress自動入稿の運用が安定しました。Claude Codeを単なる作業者として扱い、判断と責任は人間が握る。私のClaude Code運用の根本にある考え方です。
私が実際に使っている8ステップの運用フロー
参考までに、私の運用フローを公開します。Markdown原稿の作成から公開までを、以下の8ステップで回しています。
- 原稿をMarkdownで作成する(Claude Codeとペアで執筆)
- AIまたはスクリプトでWordPress用HTMLへ変換する
- カテゴリ・タグ・スラッグ・メタディスクリプションを自動設定する
- WP REST APIで
draftまたはpending(承認待ちを意味するステータス) として投稿する - 私がプレビューで確認する
- 画像・装飾・内部リンク・出典・事実関係を確認する
- 問題がなければ公開する
- 公開後にSNSやお知らせメールへ自動配信する
上記のフローのうち自動化されているのは1〜4と8です。5〜7は必ず私の目で確認します。Claude Codeに任せるのは整える作業だけで、判断する作業は私が担う、というルールが守られている限り、自動化のメリットだけを享受できます。
まとめ:WordPress自動入稿でライター本来の仕事に集中しよう

WordPress自動入稿は、Webライターの非生産作業を一気に減らす仕組みです。Claude CodeとWP REST APIを組み合わせ、認証・投稿・サムネイル登録の3処理をClaude Codeにまかせれば、面倒な入稿作業が数分で終わります。私の場合は1記事あたり30分前後を捻出でき、空いた時間を確認作業や次の執筆に回せるようになりました。
実装で気を付けたい3つのポイントは以下のとおりです。
- 認証情報を .env と .claudeignore で二重に守ること
- 専用ユーザーは投稿者権限まで絞ること
- テーマ固有装飾は装飾HTMLで先回りして設定すること
完全自動公開ではなく『下書きまで』で止めれば、誤情報が世に出るリスクを抑えながら自動化のメリットを取れます。
あくまで私のやり方なので、もっと良い方法や別の実装パターンがあれば、ぜひコメントやXのリプライで教えてください。Webライター仲間でClaude Codeの活用ノウハウをシェアしながら、お互いに本来の仕事に集中できる環境を作っていきたいです。
↓実際に私が実装した流れ、Claude Codeへの指示を詳細に書いています↓


