ブログ記事を書き終えたあとに、毎回少しだけ面倒に感じる作業があります。
WordPressに本文を入れる。タイトルを整える。スラッグを決める。メタディスクリプションを書く。そして下書きとして保存する。
記事を書くこと自体よりも、この最後の細かい作業で手が止まることがありました。
特に、ChatGPTで記事案を作るようになってからは、「記事のたたき台は早く作れるのに、WordPressに入れる作業は結局手作業なんだよな」と感じることが増えました。
そこで今回は、PythonとGoogle Colabを使って、WordPressに下書き記事を作成する仕組みを試してみました。
この記事では、コードの細かい解説というより、WordPressブログを運営している初心者〜中級者向けに、「どこまで自動化できたのか」「どれくらい時間がかかったのか」「どの作業がラクになったのか」「なぜ完全自動公開ではなく下書きまでにしたのか」をまとめます。
この記事が向いている人
この記事は、次のような人に向いています。
- WordPressで個人ブログを運営している人
- 記事を書いたあとの投稿作業を少しラクにしたい人
- ChatGPTで記事案や構成案を作ることがある人
- PythonやGoogle Colabを使った自動化に興味がある人
- 完全自動公開までは怖いけれど、下書き作成までなら試してみたい人
逆に、WordPress REST APIのコードを細かく学びたい人や、完全自動公開まで一気にやりたい人には少し物足りないかもしれません。
この記事の中心は、あくまで「ブログ運営の地味な作業を、どこまで安全にラクにできるか」です。
今回できるようになったこと
今回の仕組みで、できるようになったのは次のような作業です。
- WordPressに下書き記事を作成する
- 記事タイトルを設定する
- スラッグを固定する
- 本文HTMLを入れる
- メタディスクリプションを設定する
- カテゴリを設定する
つまり、記事を書いたあとに毎回手作業で行っていた「WordPressに入れる作業」を、かなり減らせるようになりました。
もちろん、最後の確認や公開判断は人間が行います。ここは自動化しすぎない方が安心だと感じました。
実際にどれくらい時間がかかったのか
今回の仕組みは、最初からすぐに完成したわけではありません。
WordPress REST APIで下書きを作るところまでは比較的早く進みましたが、スラッグの固定、SEO SIMPLE PACKのメタディスクリプション設定、Code Snippetsでの調整などで、何度かつまずきました。
私の感覚では、全体の作業時間は次のようなイメージです。
- WordPress REST APIで下書きを作るところまで：約1〜2時間
- タイトル、スラッグ、本文を整えて投稿するところまで：約2〜3時間
- SEO SIMPLE PACKのメタディスクリプション対応：約1〜2時間
- エラー対応や細かい修正を含めた全体：約半日〜1日程度
もちろん、PythonやWordPress REST APIに慣れている人ならもっと早いと思います。逆に、WordPress側の設定やアプリケーションパスワードでつまずくと、もう少し時間がかかるかもしれません。
ただ、一度仕組みを作ってしまえば、次からはかなり楽になります。
今は、ChatGPTやマイGPTで作った記事情報をColabに貼り付けて実行すれば、WordPressに下書きが作られる状態になりました。
自動化してラクになった作業
今回の自動化で一番ラクになったのは、「記事を書いたあとの細かい登録作業」です。
これまでは、記事を作ったあとにWordPressの管理画面を開いて、本文を貼り付け、タイトルを入れ、スラッグを整え、メタディスクリプションを書き、カテゴリを選び、下書き保存する、という作業を毎回していました。
1つ1つは小さな作業ですが、記事を書くたびにやるとなると地味に面倒です。
今回の仕組みでは、次の作業をまとめて下書きに入れられるようになりました。
- 記事タイトルの入力
- スラッグの設定
- 本文HTMLの登録
- メタディスクリプションの設定
- カテゴリの設定
- WordPressへの下書き保存
特にありがたいのは、スラッグとメタディスクリプションまで一緒に入れられることです。
本文だけを貼り付けるなら手作業でもできますが、スラッグやメタディスクリプションは毎回忘れそうになります。ここを最初からセットで入れられるようになったのは、ブログ運営上かなり助かりました。
手作業と自動化後の違い
| 作業 | 手作業の場合 | 自動化後 |
|---|---|---|
| タイトル入力 | WordPress管理画面で入力 | ARTICLE_INFOから自動反映 |
| スラッグ設定 | 毎回手で確認・修正 | 固定スラッグを自動反映 |
| 本文登録 | 本文をコピーして貼り付け | HTML本文を自動登録 |
| メタディスクリプション | SEO欄に手入力 | REST API経由で反映 |
| カテゴリ設定 | WordPress管理画面で選択 | 指定カテゴリを自動反映 |
| 下書き保存 | 管理画面で保存 | Colab実行で作成 |
1記事あたりの作業時間はどれくらい減ったか
正確に測ったわけではありませんが、体感では1記事あたり5〜10分くらいの細かい作業を減らせたと思います。
「たった5分？」と思うかもしれませんが、ブログを続けていると、この5分が意外と大きいです。
特に、仕事や家事の合間に記事を書く場合、最後の投稿作業で手が止まることがあります。
その作業をColabの実行に寄せられるだけで、「とりあえず下書きまで入れておく」ハードルがかなり下がりました。
完全に手間がゼロになるわけではありません。最終確認、画像の設定、リンクの確認、文章の微修正は今でも必要です。
それでも、記事本文を作ったあとにWordPressへ入れるまでの流れが短くなったことで、ブログ更新の心理的な負担はかなり軽くなりました。
PythonとGoogle ColabでWordPress下書き作成を試した
今回使ったのは、PythonとGoogle Colabです。
Google Colabを使った理由は、手元のPC環境に大きく依存せずに動かせるからです。ブラウザ上でPythonを実行できるので、ちょっとした検証や自動化の試作にはかなり便利でした。
WordPressにはREST APIという仕組みがあります。
REST APIというと難しく聞こえますが、今回の使い方でいうと「PythonからWordPressに記事データを送るための入口」のようなものです。
普段はWordPressの管理画面で手入力しているタイトルや本文を、Pythonから送れるようにするイメージです。
なぜ完全自動公開ではなく、下書き作成までにしたのか
最初は、「せっかく自動化するなら、公開まで全部できたら便利では？」とも思いました。
ただ、実際に手を動かしてみると、完全自動公開はやはり怖いと感じました。
- 誤字や事実関係の確認が必要
- リンク切れや画像の確認が必要
- メタディスクリプションやスラッグを最後に見直したい
- 意図しない記事が公開されるとダメージが大きい
特にブログの場合、一度公開すると検索エンジンやSNSに拾われる可能性があります。
そのため、私の運用では「下書き作成までは自動化する。でも公開前には必ず自分で確認する」という形が一番しっくりきました。
完全自動公開を目指さなくても、下書き作成まで自動化できるだけで、ブログ運営は十分ラクになります。
WordPress REST APIで下書き投稿できたのが安心だった
やってみて一番安心だったのは、投稿ステータスを status: draft にできたことです。
この設定にしておけば、PythonからWordPressに記事データを送っても、いきなり公開されることはありません。WordPress上には下書きとして保存されます。
これは初心者にとってかなり大きいです。
自動化というと、うっかり操作で公開されてしまう不安があります。でも、まずは下書きとして保存されるだけなら、かなり安心して試せます。
ブログ運営の自動化を始めるなら、まずはこの「下書き作成」までで十分だと思います。
つまずいたこと：SEO SIMPLE PACKのメタディスクリプション設定
下書き投稿までは比較的スムーズに進みました。
ただ、意外とつまずいたのがSEO SIMPLE PACKのメタディスクリプション設定です。
記事タイトルや本文はREST APIで入るのですが、SEO SIMPLE PACKのメタディスクリプションは、そのままだとうまく更新できませんでした。
少なくとも私の環境では、通常の投稿フィールドのように簡単には扱えませんでした。
「本文もタイトルも入るのに、最後のSEO項目だけ手作業なのか」と感じて、ここは地味に困りました。
Code SnippetsでSEO項目を更新できるようにした
最終的に私は、Code Snippetsを使って、REST APIからSEO項目を更新できるようにしました。
やったことのイメージは次のような流れです。
- WordPress側に、SEO項目をREST APIで受け取る処理を追加する
- Python側から、投稿本文と一緒にメタディスクリプションを送る
- WordPress側で受け取った値を保存する
ただし、ここは慎重に扱った方がよい部分です。
WordPress側にコードを追加する場合、テーマやプラグインとの相性で想定外の動きが出る可能性があります。いきなり本番環境で大きく変えるのではなく、小さく試しながら進める方が安心です。
Gemini APIの無料枠に当たった話
記事本文の生成や整形にAIを使う場合、無料枠があるのはとてもありがたいです。
ただ、開発中に何度もテストしていると、思ったより早く利用上限に当たることがありました。
私の場合、動作確認のたびにAI生成を回していたのが原因でした。
最初は便利だからと何度も実行していましたが、よく考えると、開発中に毎回AI生成まで動かす必要はありません。
開発中はAI生成をOFF、本番だけONがよかった
やってみて感じたのは、開発中はAI生成をOFFにした方がよいということです。
まず確認すべきなのは、次のような部分です。
- WordPressに下書きが作成されるか
- タイトルが正しく入るか
- スラッグが固定されるか
- メタディスクリプションが入るか
- エラー時に止まってくれるか
こうした基本部分を先に固めて、最後の本番に近い確認だけAI生成をONにする方が現実的でした。
ブログ運営と仕事、家庭を両立しながら進めるなら、毎回フル自動で動かすよりも、必要なところだけ動かす方が管理しやすいです。
運用して分かった注意点
実際に試してみると、作る前には気づかなかった注意点もありました。
スラッグを固定しないとURLがぶれる
まず気になったのがスラッグです。
WordPressでは、タイトルから自動でスラッグが作られることがあります。ただ、自動生成に任せると、記事を作り直したときに微妙に違うスラッグになったり、連番がついたりすることがあります。
後から内部リンクを貼ることを考えると、URLはできるだけ安定していた方が管理しやすいです。
そのため、スラッグは自動生成に任せすぎず、あらかじめ決めておく方がよいと感じました。
テストのたびにメディア画像が増える
本文だけでなく、アイキャッチ画像や本文内画像までAPIで扱おうとすると、別の問題も出てきます。
テストのたびに画像をアップロードすると、WordPressのメディアライブラリに不要な画像がどんどん増えてしまいます。
- 同じ画像を何度もアップロードしてしまう
- テスト用画像が残り続ける
- あとから整理するのが面倒になる
これを避けるには、開発中は画像アップロードをOFFにする、またはテスト用メディアを定期的に削除するなど、ルールを決めておく必要があります。
まずは本文、タイトル、スラッグ、メタディスクリプションまでに絞って試す方が、原因の切り分けもしやすいです。
コード全文をブログで公開するのは危ないと思った
今回のような自動化の記事を書くと、「コードも全部載せた方が親切かな」と思うかもしれません。
ただ、私はコード全文をそのままブログで公開するのは危ないと感じました。
理由は、コードの中に認証まわりの情報や内部的な設定が混ざりやすいからです。
特に、WordPressのアプリケーションパスワードやAPIキーは、うっかり公開すると不正アクセスにつながる可能性があります。
もちろん、認証情報を削除してサンプルコードとして公開する方法もあります。ただ、初心者向けの記事では、コード全文よりも次のような内容を共有した方が安全で分かりやすいと感じました。
- どういう流れで動くのか
- どこでつまずきやすいのか
- どこまで自動化すると安心なのか
- 認証情報を公開しないために何に気をつけるべきか
コードをそのまま真似してもらうより、「こういう考え方で進めると安全」という部分を伝える方が、読者にも優しいと思います。
初心者が始めるなら、この順番がよさそう
実際にやってみて、いきなり全部を自動化しようとすると、かなり大変だと感じました。
初心者が試すなら、次の順番がよいと思います。
- まずはWordPress REST APIで下書き投稿だけ試す
status: draftで公開されないことを確認する- タイトル、本文、スラッグを入れられるようにする
- 必要に応じてメタディスクリプション対応を検討する
- AI生成や画像アップロードは最後に追加する
最初から完成形を目指すより、「今日は下書きが作れた」「次はスラッグを固定できた」というように、小さく進める方が続けやすいです。
私も、最初から全部きれいにできたわけではありません。途中でつまずきながら、少しずつ形にしていきました。
まとめ：下書き作成まででも、ブログ運営はかなりラクになる
PythonとGoogle Colab、そしてWordPress REST APIを使うことで、WordPressに下書き記事を作成するところまでは自動化できました。
特に、タイトル、スラッグ、本文、メタディスクリプションまで入れられるようになると、記事を書いたあとの細かい作業がかなり減ります。
一方で、SEO SIMPLE PACKのメタディスクリプション設定、スラッグの管理、メディア画像の増加、APIや認証情報の扱いなど、実際にやってみないと気づきにくい注意点もありました。
私の結論としては、完全自動公開を目指す必要はないと思います。
まずは「下書き作成まで」を自動化して、最後は自分で確認して公開する。このくらいの距離感が、WordPressブログ運営者にはちょうどよいと感じました。
ブログ運営は、記事を書くことだけでも十分エネルギーを使います。
だからこそ、投稿前の細かい作業を少しでも減らせるなら、それだけで続けやすくなります。
まずは小さく試して、安心できる範囲から自動化していくのがよいと思います。
コメント