Gemini API × WordPress 自動投稿を“現場目線”で眺めた記録

生成AIで記事を書かせ、そのままWordPressに投稿する。発想としてはシンプルで、ブログ運用のコスト削減にも直結しそうに見える。実際、同じことを考える人は増えている。

ただ、現場でその手の自動化をやろうとすると、地味なところで足を取られる。今回、Gemini API を使って「商品名を入力 → 記事生成 → WordPressに自動投稿」までをつなごうとした試みを近くで見ていて、あらためて“自動化の難しさの種類”が整理できたので、観察メモとしてまとめておく。

1. 目指したものは「全部つながる一発ルート」

構想自体は分かりやすい。

この流れが成立すれば、「書く」工程を大幅に短縮できる。問題は、ここから先が“一本道じゃない”ことだった。

現象としては 400 / 404 / 429 といったHTTPエラーが出たり、JSONが崩れたり、WordPress側で弾かれたりする。よくあるやつだ。が、今回の学びは「エラーが出る理由が、同じ“API連携”の一言では片付かない」点にある。

生成AIとやり取りするとき、こちらは「だいたいこういう意味だよね？」という気持ちでパラメータを組みたくなる。でもAPIは意味を読まない。文字が合わないと、即死する。

特に、キャメルケース／スネークケースの違い、古いサンプルの写経、モデルごとの微妙な要求差分。こういう“人間には些細に見える違い”が、動かない理由になり続ける。

さらにやっかいなのは、AIに実装相談したとき。AIはそれっぽいコードを出すが、そのコードが“今の仕様の正解”とは限らない。ここで時間が溶ける。

「そのモデル名、存在しません」と言われるやつ。これもあるある。

面倒なのは、モデル名が正しい／間違いという単純な話ではなく、エンドポイントのバージョン（例：v1 / v1beta）と提供状況、さらには地域やプランなど、複数の条件で結果が変わりうる点だ。

つまり「ネットで見たモデル名を入れれば動く」という雑な期待が成立しにくい。モデル更新のスピードが速い領域ほど、この問題は起きやすい。

3,000文字級の記事をワンショットで生成して、しかもメタ情報もセットで返してもらう。これは体感として、**“重いリクエスト”**になりやすい。

すると、レート制限や利用枠に当たりやすくなる。もちろん回避策はある。例えば

みたいな段階処理。だが、段階処理を入れると今度は「統合時の整形」「JSONの整合」「途中失敗のリトライ戦略」など、システム設計が一気に難しくなる。自動化で減らしたい手間が、別の手間に変身する。

今回の試みで印象的だったのは、完全に詰まるというより、部分的に動いてしまう瞬間があることだ。

この「たまに成功」が最も厄介で、原因切り分けに時間がかかる。運用に入れるには再現性が必要だが、生成AIはそもそも出力が揺れる。揺れを吸収するガードレール（バリデーション、修復、再生成、フォールバック）を作るほど、結局プロダクトは重くなる。

技術的に通しても、運用面で別の壁が立つ。

最近は、一般情報をそれっぽくまとめた記事は評価されにくい。検索側の変化もあるし、ユーザー側も「どこでも読める情報」では動かない。クリックされる理由は、体験・検証・比較・失敗談みたいな一次性に寄る。

だから、仮に「自動投稿」ができても、量産自体が目的化すると、成果につながりにくい。ここは“自動化の成功”と“ブログ運用の成功”が別物という話だ。

外から見た結論は、わりと現実的になる。

今回の試みは、失敗というより「どこにコストが発生するか」を可視化した点に価値があったと思う。楽に見える一本道ほど、実際は舗装されていない。

自動化を諦める必要はない。ただし、狙いどころを変えると現実味が出る。