【自動生成】PythonとREST APIを使ったWordPress自動投稿の検証

2026.09.19

日々のブログ更新や、溜まっていくアイデアメモの整理、もっとスマートに自動化できないかと考えたことはありませんか？

エンジニアたるもの、単純なルーティンワークはプログラムに任せ、自分はよりクリエイティブな作業や設計、あるいは新しい技術のインプットに時間を割きたいものです。しかし同時に、実用に耐えない「おもちゃのシステム」を作っても意味がありません。

今回は、システム開発に携わってきた経験を活かし、Pythonと最新のGemini APIを組み合わせて、雑多なテキストメモを一瞬で「HTML装飾済みのWordPress記事」へと変換・送信する自動執筆システムを構築してみました。本記事では、このシステムの設計思想と、実装時に直面したリアルなトラップの解決法をシェアします。

今回実現した作業フロー

 

「完全自動公開」の罠と、プロの設計思想

ネット上を見渡すと、「AIでブログを完全自動更新！」や「寝ている間に記事を自動投稿！」といった、甘い言葉が溢れています。しかし、私のようなベテランエンジニアから見れば、それは非常にリスクの高い「危うい設計」に映ります。

私は長年、「絶対に止まらない、ミスが許されない」堅牢なシステムを開発してきました。そこでの鉄則は、「フェールセーフ（安全側に倒す設計）」です。どんなに優れたシステムであっても、必ず例外やエラー、そして予期せぬ挙動が発生することを前提に設計しなければなりません。

生成AIは極めて優秀ですが、時としてハルシネーション（もっともらしい嘘）をつきます。また、プロンプトのわずかなブレで、WordPressのレイアウトを崩してしまうような不適切なHTMLを出力することもあります。これらを無人のまま「公開（本番デプロイ）」してしまうのは、システム運用としてあまりにも無防備です。信頼性を失うだけでなく、Googleから低品質なスパムコンテンツと判定されるリスクもあります。

そのため、今回のシステム設計において、私はあえて完全自動化を避け、WordPressへの投稿ステータスを意図的に“draft”（下書き）で寸止めする設計にしました。

これは、現代の高度なAIシステム運用でも重視されている「Human-in-the-Loop（人間の判断を介在させる）」というアプローチです。

  • AIの役割（95%の自動化）： 構成の組み立て、HTMLタグによる装飾、リード文やまとめの作成、WordPressへのAPI送信。
  • 人間の役割（5%の最終確認）： スマホやPCで下書きプレビューを確認し、事実確認（ファクトチェック）と微調整を行い、最後に「公開」ボタンをタップする。

作業の95%を自動化して泥臭い作業から解放されつつ、最後の5%で品質を担保する。これこそが、信頼性を最優先する私が選ぶべき、最も現実的で安全な業務自動化の最適解です。

API連携の実装手順と、2つのトラップ

システム全体の構成は非常にシンプルです。ローカルのPythonスクリプトからGemini APIを呼び出して記事本文（HTML形式）を生成し、それをWordPress REST API（requestsライブラリを使用）経由で送信します。

しかし、実際に手を動かしてみると、仕様書を読んだだけでは気付きにくい「2つのトラップ」に遭遇しました。これらは、ブログ自動化を試みる多くのエンジニアが挫折しやすいポイントです。

トラップ1：WordPress REST APIの「カテゴリ指定」の罠

最初の罠は、生成した記事を特定のカテゴリに分類しようとしたときに発生しました。直感的には、APIパラメータにカテゴリ名（例: 「プログラミング」や「ガジェット」）を指定したくなりますが、WordPress REST APIは文字列を受け付けてくれません。

正解は、「カテゴリID（数値）」を「リスト（配列）形式」で渡す必要があります。例えば、カテゴリーIDが「5」の場合、以下のようなペイロードにする必要があります。

# 誤った指定（エラーまたは無視される）
payload = {
    "title": "記事タイトル",
    "categories": "プログラミング"
}

# 正しい指定
payload = {
    "title": "記事タイトル",
    "categories": [5]  # 数値のリストで渡す
}

事前にWordPress管理画面、またはAPI（/wp-json/wp/v2/categories）から対象カテゴリのIDを調査し、プログラム側でIDのマッピングを行うロジックが必要になります。ここを見落とすと、すべて「未分類」カテゴリとして投稿されてしまうため注意が必要です。

トラップ2：AIモデル指定の罠（404エラーの発生）

2つ目の罠は、記事の執筆を担うGemini APIの呼び出し部分で起こりました。インターネット上の少し古いサンプルコードを参考に、従来の google.generativeai ライブラリを使用して最新の gemini-1.5-flash などのモデルを指定したところ、無情にも「404 Model not found」のエラーが返ってきました。

GoogleのAI周辺SDKは進化のスピードが非常に早く、頻繁にアップデートが行われています。この問題は、以下のステップで解決しました。

  1. 古い google-generativeai パッケージから、最新の統合クライアントライブラリである google-genai へ移行。
  2. ライブラリを通じて、現在自分のAPIキーで利用可能なモデル一覧（models.list）をプログラム上で再取得・確認。
  3. 現在推奨されている最新のモデル名（例: gemini-3.5-flash や gemini-2.5-flash などの正確な識別子）を正しく指定。(2026年9月時点、modelリストで確認したところ「gemini-3.8-flash」が最新のようでした)

技術の過渡期においては、ドキュメントの記述が追いついていないことも多々あります。エラーが出た際は「一次情報（APIが返す生のエラーや利用可能モデル一覧の出力）」に立ち返るという、デバッグの基本が活きた瞬間でした。

まとめ

APIの仕様変更やライブラリのバージョン問題など、細かなつまずきポイントはありましたが、要件定義から実装、そしてエラー解決までを一気通貫で組み上げるプロセスは、やはりシステム開発ならではの醍醐味です。

実は、いま皆さんが読んでいるこの記事自体も、私が作成した構成メモをベースに、この自動化システムを使って下書きを生成し、私が最終的な調整を行って公開したものです。

これまで1時間以上かかっていた「WordPressへのコピペ、HTMLタグでの装飾、カテゴリ設定、プレビュー確認」という一連の作業が、わずか数分に短縮されました。この圧倒的な効率化によって生まれた「時間のゆとり」を使って、私はさらに新しい技術の検証や、より深い設計思想のアウトプットに注力できる、というわけですね。

完全自動化という甘い言葉に惑わされず、「Human-in-the-Loop」による安全な仕組みを構築すること。これこそが、ベテランエンジニアが提供できる真の価値であり、長く愛されるシステムを作るための秘訣です。ぜひ皆さんも、自分専用の「頼れるAIアシスタント」を開発してみてはいかがでしょうか。

コメント

タイトルとURLをコピーしました