WordPress記事はローカルで書いてから下書き投入した方が楽だった

WordPress の記事を毎回 wp-admin で直書きしていると、思ったより消耗します。構成メモも本文も途中の試行錯誤も、全部が投稿画面の中に閉じるからです。

最近は、ローカルで本文を作ってから wp-cli で下書き投入する運用に変えました。結論から言うと、WordPress 記事はこの方がかなり楽です。特に、AI を補助に使いながら記事を増やしたい人には相性がいいと感じました。

Obsidian の記事ネタから AI で構成を作り、ローカルの本文ファイルを wp-cli で WordPress の draft に流し込み、wp-admin で最終確認する流れの図解 — 本文作成と公開作業を分けると、テンプレート運用と AI 編集がかなりやりやすい。

結論: WordPress 記事はローカルで書いてから下書き投入した方が楽

WordPress の記事作成は、最初から wp-admin で書くより、ローカルで HTML か Markdown ベースの本文を作って、最後に wp-cli で draft 投入する方が運用しやすいです。

特に、記事を継続して増やしたい人、Obsidian にネタを貯めている人、AI を執筆補助に使いたい人にはこの方法が合います。本文の推敲と公開作業を切り分けるだけで、記事制作のストレスはかなり下がります。

理由は次の3つです。

本文作成と公開作業を分離できる
AI に下書きを作らせやすい
再利用しやすいテンプレート運用に向いている

比較項目	wp-admin 直書き	ローカル執筆 + draft 投入
構成メモの残しやすさ	低め	高い
AI 編集との相性	弱い	強い
複数記事の並行作業	やりにくい	やりやすい
最終レイアウト調整	強い	最後だけ使えばよい

なぜ wp-admin 直書きはしんどいのか

wp-admin のブロックエディタは便利ですが、毎回そこから書き始めると、次の問題が出ます。

構成メモと本文が混ざる
試行錯誤のログが残りにくい
AI に「ここを書き直して」と渡しにくい
複数記事を同時に仕込みにくい

Obsidian やローカルメモを記事ネタの母艦にしているなら、最初から最後まで wp-admin に閉じる必要はありません。

ローカルで書いてから WordPress の draft を作る流れ

今やっている流れはシンプルです。

ローカルで本文ファイルを作る
Obsidian やメモから構成を整える
wp-cli で draft を作る
必要なら最後だけ wp-admin で整える

たとえば、Xserver 上の WordPress に対しては、こんなコマンドで下書きを作れます。

~/bin/ichigoro-new-draft "記事タイトル" /tmp/post-content.html

これは、ローカルで作った本文ファイルをそのまま WordPress に入れるための小さなラッパーです。本文と公開作業を分けるだけで、運用のストレスはかなり減ります。

ローカル執筆から draft 投入に変えるメリット

1. AI を組み込みやすい

AI は管理画面の中より、テキストファイルの方が圧倒的に扱いやすいです。ローカルで本文を作る形なら、次のような流れが自然にできます。

記事ネタを Obsidian に残す
AI に構成案を作らせる
本文を書かせる
最後に WordPress に draft として流し込む

この形だと、記事作成そのものをかなり半自動化しやすくなります。

2. テンプレート運用がしやすい

記事の型があるサイトほど、この方法は強いです。たとえば次のようなテンプレートをそのまま使えます。

集客記事テンプレート
比較記事テンプレート
体験レビュー記事テンプレート

本文ファイルをテンプレートから起こして、そのまま draft にするだけなので、毎回ゼロから考えなくて済みます。

3. 記録がそのまま資産になる

これはかなり大きいです。ローカルで書く形にすると、没ネタも途中メモも残ります。あとで見返した時に、別の記事に育てやすいです。

管理画面の中だけで作業していると、この途中の思考が消えがちです。

実際にやる時の最小セット

この運用を始めるのに、最初から大がかりな仕組みは要りません。最低限、次の 3 つがあれば回せます。

ローカルで本文を書く場所
WordPress に draft を入れるコマンド
公開前に見た目を確認する手順

自分の場合は、Obsidian、ローカル HTML、wp-cli、最後の wp-admin 確認、という構成が一番素直でした。

この運用が向いている人

記事を継続して増やしたい人
Obsidian やメモアプリを使っている人
AI で記事作成を補助したい人
SSH と wp-cli に抵抗がない人

逆に向いていないケース

もちろん、全員にこれが最適というわけではありません。

毎回ブロックエディタで細かいレイアウト調整をしたい
画像配置を見ながらその場で書きたい
CLI を触りたくない

この場合は、wp-admin 直書きの方が早いです。

ただし、それでも「本文だけローカルで作って最後に貼る」というやり方は十分有効です。

ハマりやすいポイント

ファイルパスはローカルとサーバで違う

今回ハマったのはここでした。ローカルのファイルをそのままサーバ側コマンドで読もうとしても、当然ながら見えません。

なので、正しい流れは次のどちらかです。

先にサーバへ転送してから draft 作成
標準入力や別の転送方法を使う

このあたりをラップしておくと運用が安定します。

サーバの wp-cli が古いことがある

共有サーバでは、もともと入っている wp-cli が古いことがあります。今回もその問題があり、最終的には自前の WP-CLI 2.12.0 を使う形にしました。

ここはかなり重要です。ローカルで良い運用を作っても、サーバ側の入口が古いと途中で詰まります。

SEO の観点で見てもこのやり方は相性がいい

ローカルで書く方式にすると、公開前に見出し構造や導入文を落ち着いて見直せます。検索意図に合う H2 を先に置いたり、図解の alt テキストを用意したりしやすいのも利点です。

検索キーワードに寄せた見出しを組みやすい
図解や比較表を入れる位置を先に決めやすい
公開前に AI っぽい表現を削りやすい

よくある失敗

ローカル preview を作らずにそのまま流し込む

本文だけ作って即 draft 投入すると、図版サイズや表の崩れに気づきにくいです。WordPress へ入れる前に、最低でも一度はローカル preview を見た方が安全です。

画像パスをローカルのまま残す

本文だけを先に作る運用では、図版パスがローカル相対のまま残りやすいです。公開前には、画像を WordPress 側へアップロードして URL を差し替える必要があります。

wp-cli のバージョンを確認しない

共有サーバでは、標準の wp-cli が古いことがあります。本文の運用だけ整えても、サーバ側の入口が古いと最後で詰まります。

よくある質問

Markdown のまま WordPress に入れてもいいですか

環境によります。今回は HTML で流し込む形にしていますが、Markdown を途中原稿として使うのは問題ありません。公開前に最終的な出力形式だけ揃えれば十分です。

画像が多い記事でもこの方法は使えますか

使えます。ただし、画像配置を見ながら細かく調整したいなら、最後だけ wp-admin で仕上げる方が楽です。

ローカル執筆の最大の利点は何ですか

本文と公開作業を分けられることです。これだけで、AI の推敲、テンプレート運用、比較表や図解の挿入がかなりやりやすくなります。

まとめ

WordPress の記事作成を楽にしたいなら、wp-admin 直書きにこだわらない方がいいです。ローカルで本文を作ってから draft を入れる方が、AI との相性も良く、テンプレート化しやすく、継続運用もしやすいです。

特に、Obsidian で試行錯誤や記事ネタを貯めている人は、その資産をそのまま記事に変換しやすくなります。公開前に図解や推敲を挟みたい人にもこの流れは合います。

次にやること

もし WordPress の記事制作をもう少し自動化したいなら、次は wp-cli 側の下書き投入と画像アップロードを定型化すると効きます。本文をローカルで書く運用と相性が良く、公開前の確認だけに集中しやすくなります。

WordPress の運用基盤そのものを整えたいなら、Mac mini を起点に WordPress 運用を安定させる方法もあわせて読むとつながりやすいです。共有サーバ側の wp-cli や PHP をどう扱ったかまでまとめています。

さらに、Codex と wp-cli でブログ運用を自動化する考え方では、本文生成だけでなく、下書き投入や公開前確認まで含めてどう分業すると回しやすいかを整理しています。