WordPress は REST API でどこまで書き出せる? GitHub で履歴管理

このブログは WordPress で動いている。記事も固定ページも設定も、全部 WordPress の中にしかない。プロフィールのページを書き換えたとき、ふと気づいた。直す前の中身を、手でコピーして控えるしかない。

情シスの仕事では、設定は記録に残し、変更は履歴で追えるようにする。それなのに、自分のサイトは「誰が・いつ・何を変えたか」を追えない状態だった。そこで、記事・固定ページ・設定を API で書き出して、GitHub で管理し始めた。あわせて、下書き・公開・X への告知・アイキャッチ画像の取得も API にした。この記事では、その仕組みと、やってみてわかった限界を書く。

この記事でわかること

  • ▶ WordPress の何が REST API で書き出せて、何が書き出せないか
  • ▶ 秘密情報をリポジトリに入れないための工夫
  • ▶ 下書き・公開・X 投稿・アイキャッチまでを API でつなぐ流れ
  • ▶ API ではどうしても触れなかったところ

▼何を書き出しているか

認証は WordPress の「アプリケーションパスワード」を使った。ユーザーのプロフィール画面から発行でき、ログイン用のパスワードとは別に、いつでも取り消せる。値はチャットにもファイルにも書かず、Mac のキーチェーンに入れてスクリプトから読む。

書き出すもの 形式
記事(下書き含む)・固定ページ 本文の HTML と、タイトル・状態・カテゴリなどの JSON を1件ずつ
カテゴリ・タグ・メニュー・ウィジェット JSON
サイトの設定・プラグインとテーマの一覧 JSON(秘密情報のキーは除く)
問い合わせフォーム(Contact Form 7)の定義 JSON
メディア URL などの一覧だけ(画像そのものは容量が大きいので入れない)

使い方は単純だ。サイトを変えたら、書き出して、差分を見て、コミットする。

python3 scripts/export.py git diff –stat git commit -am “Profile の配色を変更”

サイトの正はあくまで WordPress だ。リポジトリは「いつ・何が変わったか」を追うための写しと、変更前の控えとして使う。実際、固定ページのデザインを何度か作り直したが、気に入らなければ1つ前のコミットからそのまま戻せる安心感は大きかった。

▼秘密情報を入れないための工夫

設定の中に API キーが混ざっていた

サイトの設定を書き出したら、スパム対策プラグインの API キーと思われる項目が入っていた。キー名に api_key・secret・password・token などを含む項目は、書き出すときに捨てるようにした。ユーザー情報とコメントも、個人情報なので書き出さない。

コミット前のチェックが、記事のダミー値に反応した

コミットの前に、トークンらしき文字列が入っていないかを検査するフックを入れている。ところが、過去の記事で説明のために書いた xoxb-XXXX-XXXX-XXXX のようなダミー値に反応して、コミットが止まった。X だけでできたダミー値だけを検査の対象から外した。本物の形のトークンは引き続き止まる。

▼公開までを API でつなぐ

書き出しとは別に、記事を出す流れも API にした。

STEP1 原稿の HTML から、WordPress に下書きを作る(タイトル・抜粋・カテゴリつき)

STEP2 Unsplash の API で写真を探し、選んだものをダウンロードしてアイキャッチに設定する

STEP3 プレビューを確認してから公開する

STEP4 X の API で告知を投稿する(文字数は送る前に確認)

ブラウザを開かずに、ターミナルからコマンドだけで1本の記事を出せるようになった。ただし、公開と投稿は必ず自分の目で確認してからにしている。自動化したのは作業で、判断ではない。

X の API は無料ではない

2026年時点で、X の API は従量課金になっている。投稿1件 $0.015、URL つきの投稿は1件 $0.20。ブログの告知は必ず URL が入るので、1件 $0.20 で考える。初回にカードを登録すると無料クレジットがつき、1回の課金サイクルあたりの上限も設定できる。月に数本の告知なら費用はわずかだ。

ハマったのは認証だった。X の開発者画面には「OAuth 1.0」と「OAuth 2.0」のキーが並んでいる。自分のアカウントとして投稿するのに使ったのは、OAuth 1.0 の欄で発行するアクセストークンだった。OAuth 2.0 の欄のキーを入れて、401 エラーで止まった。

▼API では触れなかったところ

もの 理由と代わりの手
子テーマのファイル サーバー上のファイルで、REST API では取れない。FTP などで別に取る必要がある
カスタマイザーの設定・追加 CSS 同上
テーマ独自のページ設定(サイドバー非表示など) テーマの設定欄で、API に出てこない。管理画面の編集画面から変えるしかなかった

最後のものには少し手こずった。編集画面の設定欄は、見えているチェックボックスと、値を送る隠しフィールドの2つでできていた。しかも、ページの本文に変更がないと保存の処理そのものが走らない。仕組みがわかるまで、何度か「保存したのに変わらない」を繰り返した。

▼やってみて:情シスの「属人化させない」を、自分のサイトに

情シスの仕事の軸は、「自分がいなくても回る」状態をつくることだと考えている。設定を記録に残す。変更を追えるようにする。秘密情報は決まった場所に置く。誰かの手作業に頼らない。

今回やったのは、それを自分のブログに当てはめただけだ。手順をスクリプトにし、履歴を GitHub に残したことで、自分以外の人や AI に作業を任せても、何が起きたかを後から確かめられる。クライアントに勧めていることを、自分の足元でもやっておくのは大事だと感じた。

▼まとめ

  • ▶ 記事・固定ページ・設定・フォームは REST API で書き出せる。認証はアプリケーションパスワード
  • ▶ 設定に紛れる API キーは、キー名で捨てる。コミット前の検査も入れる
  • ▶ 下書き・アイキャッチ・公開・X 投稿まで API でつなげる。判断は人が持つ
  • ▶ テーマのファイルや独自の設定は API で取れない。別の手が要る
📄 AI エージェントのチームで情シスの仕事を回している話はこちらの記事で書いています。
📄 SaaS アカウントの台帳を CSV+git で自動化した記録はこちらの記事で書いています。

📅 30分無料相談、受け付けています

「社内の手作業を仕組みにしたいが、作った人がいなくなると止まりそうで怖い」——そういった段階からお気軽にどうぞ。引き継げる形での自動化と、AI を使った業務の仕組みづくりを支援しています。

📅 30分無料相談を予約する →