AI でブログ運用を楽にしたいと思っても、実際には「どこまで自動化して、どこを人間が見るか」で止まりがちです。記事本文は書けても、画像、下書き投入、公開前確認まで含めると、急に運用が雑になりやすいからです。
最近は、Codex と wp-cli を組み合わせて、ブログ運用のかなりの部分を定型化しています。結論から言うと、WordPress 運用は AI で本文を書く だけではなく、ローカル原稿、下書き投入、公開前確認 をまとめて設計した方がうまく回ります。
結論: Codex と wp-cli は、記事制作より「運用の分離」に効く
Codex と wp-cli を組み合わせる一番の価値は、本文を自動で量産することより、記事制作と WordPress 管理画面の役割を分けられることです。
具体的には、次の流れを分離できます。
- ネタ出しと構成整理
- 本文作成と推敲
- WordPress への下書き投入
- 画像アップロードと差し替え
- 公開前の見た目確認
この分離があるだけで、AI の出力が多少荒くても、どこを直せばいいかがかなり明確になります。
| 工程 | Codex 向き | 人間が見るべき点 |
|---|---|---|
| 構成づくり | 強い | 検索意図のズレ |
| 本文初稿 | 強い | 温度感、冗長さ、言い切り方 |
| 下書き投入 | 強い | カテゴリ、slug、excerpt |
| 画像差し替え | 半自動向き | alt、表示崩れ、キャプション |
| 公開判断 | 補助まで | 品質と責任の最終確認 |
なぜ「本文だけ AI」では足りないのか
AI にブログ記事を書かせる話は多いですが、実運用では本文だけ整っても足りません。実際には、次のようなところで詰まりやすいです。
- 図版の文字が崩れる
- 画像パスがローカルのまま残る
- WordPress に入れた途端に表が読みにくくなる
- slug や excerpt が雑なままになる
- 公開前確認を飛ばしてしまう
つまり、AI で本文を書くこと自体は一部でしかありません。公開までの流れを一緒に設計しないと、結局どこかで手戻りが増えます。
今の自分の運用フロー
今は次のように分けています。
Obsidianやメモで記事ネタをまとめるCodexに構成案を作らせる- ローカルの
fragment.htmlを正本として本文を詰める - preview HTML を生成してブラウザで確認する
wp-cliで WordPress に draft 投入する- 必要なら画像をアップロードして本文 URL を差し替える
- 最後だけ
wp-adminと実ブラウザで確認して公開する
この流れにすると、AI は「雑に全部やる道具」ではなく、「下書きと整形を速くする道具」になります。
Codex が特に効くところ
1. 構成の初速が速い
検索意図が分かっている記事なら、見出し構成の初速はかなり速いです。白紙から組み立てるより、まず叩き台を出してもらって直す方が早いです。
2. ローカル原稿との相性がいい
wp-admin の中で AI を使うより、ローカルの HTML や Markdown を相手にした方が圧倒的に扱いやすいです。差分も見やすく、文章の修正も指示しやすいです。
3. 周辺作業までまとめて整えやすい
タイトル、excerpt、slug、図版キャプション、内部リンクなど、本文の外側もまとめて触れるのは大きいです。ここを人力だけで毎回詰めるのは意外と重いです。
wp-cli が効くところ
WordPress 管理画面を作業場にしなくて済む
wp-cli があると、WordPress は「最後に流し込む場所」になります。これだけで、構成メモと公開作業が混ざりにくくなります。
定型化しやすい
下書き投入、更新、メディア操作などをスクリプトに寄せやすいので、記事数が増えても手順が崩れにくいです。
共有サーバでも再現性を作れる
共有サーバは標準の PHP や wp-cli が古いことがありますが、自前の入口を整えれば、かなり安定した流れに寄せられます。
自動化しすぎない方がいい部分
逆に、全部を自動化しようとしない方がいいところもあります。
- タイトルの最終判断
- 導入の温度感
- 比較表や図版の意味の伝わり方
- 公開タイミング
- 公開後に残る記事として恥ずかしくないか
ここは、AI に任せるより、人間が責任を持って見る方がいいです。少なくとも自分はそうしています。
ハマりやすいポイント
HTML を shell に直接埋め込む
これは壊れやすいです。記事本文はファイルとして持って、転送してから更新した方が安定します。
画像 URL の差し替えを忘れる
ローカル preview では見えていても、WordPress 上ではローカル相対パスのままだと当然壊れます。公開前に必ず確認が必要です。
プレビューと本番の見え方が違う
WordPress テーマ側の CSS や関連記事ブロックが入ると、ローカル preview と完全には一致しません。最後は live 表示を見た方が安全です。
この運用が向いている人
- 記事を継続的に増やしたい人
- WordPress を使っている人
- AI を本文作成だけでなく運用改善にも使いたい人
- ローカルでメモや下書きを管理したい人
向いていないケース
- 記事を年に数本しか出さない
- 毎回 WordPress のブロックエディタで完結したい
- CLI やファイル管理を増やしたくない
この場合は、無理にフローを増やさない方が楽です。
まとめ
Codex と wp-cli を組み合わせる価値は、記事本文の自動生成より、ブログ運用の役割分担を整理できることにあります。ローカル原稿、下書き投入、画像差し替え、公開前確認を分けるだけで、かなり安定します。
AI をブログで使うなら、本文だけでなく運用全体に組み込んだ方が効きます。逆に言うと、そこまで設計しないと、単に下書きが増えるだけで終わりやすいです。
関連記事
実際の本文制作フローは、WordPress 記事をローカルで書いてから下書き投入する方法 にまとめています。運用の基盤側は、Mac mini を起点に WordPress 運用を安定させる方法 がつながります。どの AI ツールに課金するか迷っているなら、エンジニア向けAIツールおすすめ比較 も続けて読むとつながりやすいです。