【実録】なぜ私は WordPress の投稿画面を開かなくなったのか — Claude Code × ローカル Markdown 連携の話

非エンジニアAIラボ第4記事アイキャッチ。Editorial風デザイン、キャラクター入り。 Claude Code
2026.04.26

※将来的にアフィリエイトリンクを追加する予定です。

  1. はじめに
  2. TL;DR(忙しい人向けまとめ)
  3. 第1章:なぜ私は WordPress 管理画面で書かなくなったか
    1. きっかけは Markdown で書く習慣
    2. 第3記事で Application Password に出会った
    3. もう管理画面を開く理由がほぼない
  4. 第2章:いまの執筆フロー(時系列で)
    1. ① ローカルで Markdown を書く
    2. ② Claude Code に「投稿して」と頼む
    3. ③ Claude Code が裏で動く
    4. ④ 公開URLを開いて確認
  5. 第3章:Claude Code が裏でやっていること
    1. レイヤー1:Markdown を Gutenberg ブロックに変換する
    2. レイヤー2:画像をアップロードする
    3. レイヤー3:カテゴリーとタグを解決する
    4. レイヤー4:メタ情報をまとめる
    5. レイヤー5:REST API で投稿する
    6. 補足:Claude Code は「使い捨ての小さなプログラム」を書いている
  6. 第4章:この仕組みを使うために必要なもの
    1. 必要なもの一覧
    2. REST API は WordPress に最初から入っている
    3. Application Password の作り方は第3記事 第5章で解説
  7. 第5章:Markdown 投稿の弱点と、それでも選んだ理由(本音セクション)
    1. 弱点1:Cocoon の独自装飾は使えない
    2. 弱点2:画像の細かい配置はやりにくい
    3. 弱点3:書いてる途中の見え方がブラウザと違う
    4. それでも選んだ理由
  8. 第6章:この仕組みで何が変わったか
    1. 変化1:書く頻度が上がった
    2. 変化2:過去記事への内部リンクが増えた
    3. 変化3:「公開しないこと」が減った
  9. つまずきポイント・備忘録
    1. Application Password を生スクリプトに残しておかない
    2. Markdown→Gutenberg の変換ロスをゼロにはできない
    3. 画像のローカルパスとサーバーURL
    4. 表記揺れの一括チェック
    5. 下書きで投稿 → 後から公開、の運用がラク
  10. 終わりに
    1. 次の記事(第5記事)について
    2. 続編記事

はじめに

正直に書くと、この記事自体が、ローカルのテキストエディタで Markdown として書かれて、Claude Code 経由で WordPress に投稿されています。WordPress の管理画面を開かずに、です。

ブログを4本書いた今、自分の執筆フローはこうなっています。

1. ローカルのフォルダに articles/04-local-markdown-wordpress.md のような Markdown ファイルを作る 2. Claude Code に「これ投稿して」と頼む 3. しばらく待つと、公開された記事の URL が返ってくる

1記事目を書いていた頃は、WordPress の管理画面エディタにコピペしていました。装飾を整えて、カテゴリーを選んで、タグを付けて、公開ボタンを押す。15分から30分くらい、毎回かかっていました。

今は、Markdown を書き終えてから記事が公開URLとして返ってくるまで、私の作業は実質「投稿して」の一言だけ。

この記事は、その仕組みを「どう使っているか」と「なぜそう変えたか」、そして率直に「Markdown 投稿で困っていること」までを記録したものです。技術記事ではないので、コードは出てきません。仕組みの概念だけ書きます。

TL;DR(忙しい人向けまとめ)

執筆フローを、Before / After で並べてみます。

項目Before(管理画面で執筆)After(ローカル Markdown + Claude Code)
執筆環境ブラウザの管理画面エディタ好きなテキストエディタ(私は VS Code)
バックアップサーバー上の DB のみローカルにも .md ファイルが残る
過去記事の検索管理画面を開いて探すローカルフォルダで全文検索
公開時の作業コピペ・装飾・カテゴリ・タグ・公開ボタンClaude に「これ投稿して」
執筆と公開の摩擦高い(画面を開く心理コスト)低い
一記事あたりの公開作業15〜30分約3分(私が見てる時間)

切り替えの決め手は、「公開作業が重い」と感じる日が、書く意欲を削っていたことに気づいた瞬間でした。

第1章:なぜ私は WordPress 管理画面で書かなくなったか

第1記事から第3記事まで、徐々に管理画面から離れてきた、というのが正直なところです。一気に切り替えたわけじゃない。

きっかけは Markdown で書く習慣

第1記事を書き始めた頃、私はとりあえず Markdown でローカルにメモしていました。理由は単純で、Claude Code に渡しやすいから。Markdown は構造がシンプルで、AI が読みやすい。

ところが書き終えたあと、これを WordPress 管理画面のエディタに貼り付けると、見出しが太字テキストになっていたり、コードブロックが普通の引用になっていたり、装飾が崩れる。一行ずつ直す。30分くらいかかる。

ここで思いました。「この変換、毎回手作業でやるのは無駄じゃないか?」

第3記事で Application Password に出会った

第3記事で固定ページ4本を Claude Code に丸投げしたとき、Claude が WordPress を直接操作するために Application Password を発行しました。あの瞬間、「これ、記事投稿にも使える仕組みだ」と気付きました。

固定ページが REST API で作れるなら、投稿(記事)も同じやり方で作れる。Claude Code が裏で REST API を叩けば、私はローカルで Markdown を書くだけでよくなる。

そこから第3記事の公開作業を、初めて Claude Code 経由でやってみました。動いた。所要時間、3分。

もう管理画面を開く理由がほぼない

それ以来、私が WordPress 管理画面を開くのは:

  • アクセス解析を見たいとき
  • プラグインの更新通知が来たとき
  • スパムコメントが届いていないか確認するとき(コメントは OFF だけど一応)

くらいです。記事を書く・公開するために開くことはなくなりました。

ブログ運営の中心は、もうエディタとローカルフォルダにあります。

第2章:いまの執筆フロー(時系列で)

実際の1日の流れを、時系列で残します。

① ローカルで Markdown を書く

朝、コーヒーを淹れて PC を開く。articles/ フォルダに新しい .md ファイルを作って、書き始めます。

私は VS Code を使っています。理由は、無料で動作が軽くて、Markdown のプレビューが横に出せるから。Obsidian や、もっと軽量なメモアプリでも構いません。Markdown が書ければ何でもいい、というのが本音です。

執筆中は WordPress のことを忘れています。文字を書くことだけに集中できる。これが前後の心理コストを一気に下げてくれる体感の正体かもしれません。

📷 画像予定:スクショ予定:VS Code でローカル .md を編集している画面(後日追加します)

② Claude Code に「投稿して」と頼む

書き終えたら、Claude Code を立ち上げて、こう打ちます。

「articles/04-local-markdown-wordpress.md を WordPress に下書きで投稿して。アイキャッチも作って」

このとき指定するのは、ファイル名・公開状態(下書き or 公開)・必要ならカテゴリーやタグの希望。それくらい。

③ Claude Code が裏で動く

このあとは私の手から離れます。Claude Code が:

  • Markdown ファイルを読み込む
  • アイキャッチ画像を生成 → WordPress にアップロード
  • Markdown 本文を Gutenberg(WordPress 標準のブロックエディタ)用の形式に変換
  • カテゴリーとタグを照合(なければ作る)
  • スラッグ・概要文(抜粋)を設定
  • WordPress の REST API を Application Password で叩いて投稿を作成

ここまで一気に進めて、公開URLを返してくれます。約3分。

私はその間、コーヒーを淹れ直しながら、画面の進捗を眺めています。途中で「これでよろしいですか?」と聞かれることもあるので、その時だけ「OK」「進めて」と返します。

📷 画像予定:スクショ予定:Claude Code に「投稿して」と頼んだ瞬間のターミナル(後日追加します)

④ 公開URLを開いて確認

返ってきた URL をブラウザで開いて、表示崩れがないか目視チェック。崩れてたら Claude に「ここの装飾がおかしい」と伝えれば、その場で直してくれます。

これで終了。1日の執筆作業は、書いている時間+公開3分。

第3章:Claude Code が裏でやっていること

ここは概念だけ書きます。コードは出しません。

Claude Code が「投稿して」の一言を受けたあと、裏で何をしているか — 5つのレイヤーに分解できます。

📷 画像予定:スクショ予定:Markdown と Gutenberg の対応関係を示す概念図(後日追加します)

レイヤー1:Markdown を Gutenberg ブロックに変換する

Markdown と Gutenberg は、書き方が違うだけで意味は近い。

  • Markdown の ## 見出し → Gutenberg の見出しブロック
  • Markdown の - 項目 → Gutenberg のリストブロック
  • Markdown の表組み → Gutenberg のテーブルブロック
  • Markdown の > 引用 → Gutenberg の引用ブロック

これを1行ずつ照合して、Gutenberg 用の HTML(コメント付き)に書き換えていきます。地味な変換作業です。

レイヤー2:画像をアップロードする

Markdown の中に !alt のような画像参照があると、その画像ファイルを WordPress のメディアライブラリにアップロードして、サーバー上の URL を取得します。

そのうえで、本文中の参照を「ローカルパス」から「サーバーURL」に書き換える。読者がブラウザで開いたとき、画像がちゃんと表示されるのはこの処理のおかげです。

レイヤー3:カテゴリーとタグを解決する

「Claude Code」というカテゴリーを指定したら、まず WordPress に「このカテゴリーは既にある?」と聞きます。あれば再利用、なければ新規作成。タグも同じ流れ。

これがないと、毎回新しいカテゴリーが量産されてしまう。地味だけど大事な処理です。

レイヤー4:メタ情報をまとめる

スラッグ(URLの末尾)、抜粋(検索結果に出る短い説明)、アイキャッチ画像の ID、公開状態(下書き or 公開)— これらをまとめて1つのリクエストにします。

レイヤー5:REST API で投稿する

WordPress の REST API は、https://nonengineer-lab.com/wp-json/wp/v2/posts のような URL に対して、認証情報(Application Password)と本文を渡すと、投稿を作ってくれる仕組みです。

これに上で組み立てた本文+メタ情報をまとめて投げる。レスポンスが返ってきて、公開URLが手に入る。

私が見ているのは「OK」「進めて」を押した数回と、最後に出てくる公開URLだけ。中身はこの5レイヤーが順番に動いています。

補足:Claude Code は「使い捨ての小さなプログラム」を書いている

ここは初めて聞くと面食らう人もいる話なので、正直に書きます。

Claude Code は、上の5レイヤーを動かすために、その記事専用の小さな Python スクリプトを毎回その場で書いて、実行しているんです。次の記事のときは、また新しいスクリプトを書き直す。

「使い捨て」と言うとネガティブに聞こえますが、これは合理的な仕組みです。毎回の記事の事情(画像枚数、カテゴリー、内部リンクの貼り方)に合わせて柔軟に書けるメリットがある。固定の万能スクリプトを作り込むよりも、その都度 AI が書いたほうが速いし、間違いも少ない。

私はそのスクリプトを読みません。読まなくても動く。これが非エンジニアでも回せる仕組みの本質だと思っています。

第4章:この仕組みを使うために必要なもの

読者から「自分にもできるの?」と聞かれそうな点を、先回りして整理します。

必要なもの一覧

項目必要性月額追加コスト
WordPress(REST API は標準で有効)必須0円(既に動いていれば)
Application Password の発行ができる権限必須0円
Claude Code(CLI 版・ターミナルで動くコマンドライン版)必須サブスク料金(現状 月額 $20 程度。プラン更新で変動)
ローカルのテキストエディタ(VS Code 等。VS Code は Microsoft 製で無料)推奨0円
Markdown を書く慣れ推奨0円(慣れれば不要)

特別なプログラミング知識は要りません。Claude Code に「これを WordPress に投稿して」と日本語で頼めば動きます。

REST API は WordPress に最初から入っている

「REST API」と聞くと身構える人がいるかもしれませんが、WordPress には最初から入っている標準機能です。プラグインを追加で入れる必要はありません。

WordPress 4.7(2016年)以降は標準機能として常時有効です。むしろ無効化するほうが特殊な操作になります。Xサーバー等の主要レンタルサーバーで WordPress を立ち上げた場合、何もしなくても REST API は動いています。

Application Password の作り方は第3記事 第5章で解説

Application Password の発行方法・削除方法は、第3記事の第5章で「家の合鍵」の比喩を使って解説しました。再掲はしないので、そちらをどうぞ。

セキュリティ上の鉄則は1つ:作業が終わったら必ず削除する。発行したまま放置しない。

[アフィリ挿入:Xサーバー紹介(中盤)] — このフローは X サーバー上の WordPress 標準機能で動いています。REST API も Application Password もデフォルトで使えるので、特別な追加コストはゼロ。サーバー選びの判断軸は1記事目で詳しく書きました。

第5章:Markdown 投稿の弱点と、それでも選んだ理由(本音セクション)

ここからは、いいことばかりではない、という話です。

弱点1:Cocoon の独自装飾は使えない

Cocoon テーマには、囲み枠・吹き出し・タブ切替など、独自の装飾ブロックがたくさんあります。これらは Markdown には対応する記法がない。

私は今、こう割り切っています。

  • 囲み枠 → 引用 (>) で代用
  • 強調 → 太字 (〜) で代用

それでも見た目は整う。Cocoon の独自機能を使い倒したいなら、管理画面で書くほうがいい。

弱点2:画像の細かい配置はやりにくい

Markdown だと、画像は基本「行に1枚、左寄せ」しか出来ません。「文章の右側に小さい画像を回り込ませる」のような細かい配置は、Markdown 単独では書けない。

これも私は割り切っています。本文中の画像は1行1枚で十分、という方針。

弱点3:書いてる途中の見え方がブラウザと違う

VS Code で Markdown プレビューを見ていても、Cocoon テーマで装飾された最終形とは見た目が違います。最終形は公開後にブラウザで確認するしかない。

これがたまに気持ち悪い。書いた瞬間に「読者と同じ見え方」を確認できないのは、管理画面で書く頃にはなかったストレスです。

それでも選んだ理由

弱点を3つ書きました。それでも管理画面に戻らない理由は、こういう順序です。

1. 執筆中の集中が崩れない。WordPress を開いた瞬間に通知バッジ・更新通知・コメント数が目に入ってくる、あの感じが一切ない。 2. ローカルにファイルが残る。公開済みの記事を後から書き換えたいとき、ローカルの .md を書き換えて Claude に「これで上書きして」と頼むだけで反映できる。 3. 過去記事の整合性が取りやすい。フォルダで全文検索すれば、特定の用語を全記事から見つけられる。「あの話、何記事目で書いたっけ?」がすぐ解決する。 4. AI に渡しやすい。新しい記事のリサーチや構成案を AI に頼むときに、過去記事を Markdown のまま渡せる。形式変換のロスがない。

弱点はあるけど、自分にはメリット4つのほうが重い。これが現時点の判断です。読者の状況によっては、逆もあり得ると思います。

第6章:この仕組みで何が変わったか

3点だけ。

変化1:書く頻度が上がった

公開作業が「3分」になったので、「今日はちょっと疲れてるから明日にしよう」が減りました。書き終えたら、その勢いのまま投稿できる。鮮度が落ちない。

これは正直、自分でも驚いた効果です。15分の公開作業がブロッカーになっていたとは、減らしてみるまで気付かなかった。

変化2:過去記事への内部リンクが増えた

ローカルで全記事の .md を持っているので、新記事を書きながら過去記事を参照しやすい。「第2記事の第7章で書いた話」を引用するときに、その章を瞬時に開いて確認できる。

結果、内部リンクの密度が自然に上がりました。SEO 的にも記事間の文脈的にも、副次効果として効いています。

変化3:「公開しないこと」が減った

下書きのまま塩漬けになる記事が、ほぼゼロです。完成度が80%でも、Claude に「下書きで投稿して」と頼んでおけば、後でブラウザのプレビューで見ながら直せる。「完璧になったら公開」をやめて「公開してから磨く」に切り替わりました。

ブログ運営に厚みが出てきた手応えは、ここからきている気がします。

📷 画像予定:スクショ予定:ローカルの articles/ フォルダの一覧画面(.md が並んでいる)(後日追加します)

つまずきポイント・備忘録

雑多に置いておきます。

Application Password を生スクリプトに残しておかない

これは自分への戒めです。Claude Code が書いた使い捨てスクリプトの中に、Application Password がそのまま書き込まれているケースがあります。スクリプトを後から見返したとき、認証情報が平文で残っていることがある。

第3記事でも書いた通り、Application Password は使い終わったら必ず削除する。これを徹底すれば、仮にスクリプトファイルが残っていても、もう使えないキーになります。「使ってる間は短く、終わったら即削除」が鉄則。

将来的には、.env ファイルや環境変数に逃がす方式にする予定です(ここはまた別記事で書きます)。

Markdown→Gutenberg の変換ロスをゼロにはできない

太字や見出しレベル(##と###)は問題なく変換されますが、Markdown には対応しない装飾(Cocoon の囲み枠など)を使いたい場合は、後から管理画面で手作業の追加が必要になります。

「装飾ゼロでも記事として成立する書き方」を意識する、という方針転換も同時に起きました。

画像のローカルパスとサーバーURL

Markdown の中で ../images/04-XX.png のように相対パスを書きますが、公開後はサーバー上のフルURLに置き換わります。ローカルで開く時とブラウザで開く時で、参照先が物理的に違う。

これは Claude Code が自動でやってくれますが、自分で確認する習慣だけは持っておく。

表記揺れの一括チェック

第3記事で書いたのと同じ話。運営者名・サイト名・用語のブレは、ローカルに全記事があると一括検索で潰せます。週1で表記揺れを確認する時間を取っています。

下書きで投稿 → 後から公開、の運用がラク

下書き状態で投稿しておけば、ブラウザで見え方を確認しながら、最終的に管理画面で公開ボタンを押せる。最初から公開状態にせず、まず下書きで上げるのが、見た目チェックが最短になる運用です。

終わりに

この記事を書いている今も、私は VS Code で 04-local-markdown-wordpress.md を編集しています。書き終えたら、Claude Code に「これ下書きで投稿して」と頼むだけです。

1記事目で「ターミナルって何?」から始まった私が、4記事後にはこういう執筆フローを当たり前のように使っている。技術が上がったというより、AI に乗っかれる範囲が広がった、という感覚に近いです。

この仕組みは、私が技術を学んだから動いているんじゃなくて、Claude Code が私の代わりに技術を担当してくれているから動いています。私は日本語で「これ投稿して」と頼むだけ。

このブログは X サーバーのクイックスタートで立ち上げ・運用しています。REST API も Application Password も、X サーバー上の WordPress 標準機能で動いています。これから始める方は1記事目のサーバー契約編から読むとつながりが分かります。

次の記事(第5記事)について

第4記事までで、ブログの土台と執筆フローが揃いました。次回からは、いよいよコンテンツの中身に入っていきます。

第5記事は「ASP 申請をやってみた話」を予定。通るのか、落ちるのか、リアルタイムで実況します。固定ページ4本が揃ったので、A8.net、もしもアフィリエイトの審査に出して、その結果と理由を実体験ベースで記録。

つまずきも、葛藤も、判断の根拠も、引き続き全部記録していきます。同じ立場で何かを始めようとしている方の役に少しでも立てば。

続編記事

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