こんにちは、パレイド思想部です。
前回は ai-editor の全体像を紹介しました。今回は「一番最初に作って、一番使っている機能」である Markdown ↔ WordPress 双方向同期 の仕組みを解説します。
なぜ「同期」が最初の課題になったのか
ブログを Markdown で管理しようとすると、すぐにある問題にぶつかります。
「どっちが最新か分からない」
WordPress の管理画面で誤字を直す。ローカルの Markdown も直す。でも別々のタイミングで。気づいたら2つのファイルが微妙に食い違っている——この状態が続くと、「Markdown はもう信用できない」という判断になり、WordPress だけで編集するようになります。そうなると手元の Markdown は「使い捨て」になってしまいます。
問題の根本は、WordPress でしかできない作業が多いのに、編集性はローカルのエディタに大きく劣ること。 また、WordPressの拡張プラグインや、連携を謳う市販のエディタやアプリに、安心して使えるものがないことです。
以前は MarsEdit なども試したことがあり、ある程度快適に作業ができます。一定の利用では問題ありませんが、結局のところ WordPress 上での作業がつきまとい、あるタイミングで諦めました。 仕様変更が多いWordPress に、サードパーティのプロダクトが長期間追随するのは構造的な限界があると考えられます。
特に昨今は note, qiita, zenn といったプラットフォームも隆盛で、WordPress のポジションは微妙になっています。 それでも自由度を求めて自前で WordPress を運用したい、という層は徐々に減っているのでしょう。
編集性は割り切る
手元の編集は、Markdown形式を採用します。構造化が可能で昨今の生成 AI とも相性が良く、最低限の書式や装飾機能を備えます。 これ以上複雑な表現方法は、独自性と言えば聞こえが良いですが、必要な労力に見合う効果が得られるかは未知数です。 また、note や qiita が受け入れられている事実は、ある程度の標準的な「形式」が好まれている証左とも言えます。
今回は VS Code でタスクとしてツールを登録することで、ファイルシステムやMarkdown形式を活かす方向性としました。 また、その場で記事を書きながらツールを改修するスタイルも非常に重要です。
フロントマターで状態を双方向管理する
ローカルの Markdown と WordPress を同期させるには、WordPress にしかない管理情報を保存しておく必要があります。
ai-editor では、WordPress の管理情報を各 Markdown ファイルのフロントマターに同期状態を埋め込みました。
---
post_id: 1234
status: published
date_publish: '2026-03-20'
wp_modified: '2026-03-21T10:30:00' # WP側の最終更新日時
local_modified: '2026-03-21T09:00:00' # ローカルの最終更新日時
sync_status: synced # synced / local_newer / wp_newer / conflict
---これらのフィールド構造は手で打つ必要はなく、初回のアップロード時に WordPress からAPIで取得し、ツールが自動で挿入します。 WordPress に記事が保存され、POST_ID が振られると同期の対象となります。以降は同期コマンドを実行するたびに、WordPress 上のタイムスタンプを取得し、ローカルの値と比較して自動で更新します。
なお、初期は同期がうまくいかずデグレードが起きることも何度かありました。WordPress はリビジョン管理が可能で、またローカルのファイルは git でバージョンを管理しました。Claude や GitHub Copilot を利用していれば、困ったら AI に泣きつけばリビジョンを戻してくれるため非常に便利です。
同期については内容が濃くなるため、技術部の記事として詳細を説明します。
この一連の記事は実際に「AI編集者」を用いて作成しています。
差分同期の仕組み
同期自体は、丁寧に処理すれば安定的に可能です。無邪気にAIに実装を依頼すると不完全な実装が出力され、誤ってローカルのファイルが上書きされるなど何度か痛い目に遭うため、明示的な指示が重要です。
ポイントは、post_idを軸として事前に照合を行って処理を決めること、またタイムスタンプの比較でタイムゾーンやサーバーとローカルの微細なずれを意識した処理を行うことです。 AI は無邪気にファイル順に処理を行うループを組んできますが、IDを軸にしないと上書きや先祖返りのリスクが付きまといます。 このあたりは AI に一日の長がありそうなものですが、現時点では明確に指示するほうが安全なようです。
ローカル Markdown 一覧
↓
フロントマター読み込み (post_id 取得)
↓
WP REST API で post 一覧取得
↓
modified タイムスタンプを比較
↓
┌─────────────┬─────────────┐
local_newer synced wp_newer
↓ ↓
WPへアップロード ダウンロード確認「確認」としているのは意図的です。WP 側が新しい場合、自動で上書きはしません。代わりにターミナルに通知して、ユーザーに y/N を問う、または --download フラグをつけて明示的に処理を指示する設計になっています。
WP では、管理画面の「自動保存」や「リビジョン」が意図しない modified の更新を起こすことがあります。管理画面を開いて放置していただけで WP 側が更新されたと判定し、ローカルの編集が上書きされる事故が起きる場合があります。面倒でも、「WP が新しい」という情報を通知して、判断は人間に委ねることでこれが安全側に倒しています。
WP REST API の選定理由
WordPress の外部操作手段は大きく3つあります。
| 手段 | メリット | デメリット |
|---|---|---|
| WP-CLI | 高機能・高速 | サーバー SSH 必須 |
| XML-RPC | 旧来から使える | 非推奨、セキュリティリスク |
| REST API | HTTPS のみ・認証が標準的 | 一部機能が限定的 |
レンタルサーバー環境では SSH が使えないケースもあり、REST API がベターな選択でしょう。 認証には Application Password（WP 5.6 以降の標準機能）を使うため、プラグイン不要で動きます。 また、ほとんどの AI が REST API なら問題なくコーディング支援できることもポイントです。
実際のワークフロー
ツール導入後の典型的な1日の流れはこうなります。
# 朝: WP側に昨夜の変更がないか確認
python -m publish scan-dir blog/articles/ --check-wp
# 記事を書いて保存後: 即時アップロード
python -m publish sync blog/articles/2026-03-22_1234_new-article.mdチームで編集作業を行う場合は、ルールの示しあわせが必要かもしれません。
VS Code の tasks.json にも登録し、ファイルを開いた状態でショートカット1つで同期できるようにしました。
対話型の CLI でも、ターミナルで動作を確認しながら処理を進めることができます。
時間削減の効果
以前は「管理画面を開く→記事を探す→コピペで更新→プレビュー確認」を毎回繰り返していました。この一連の作業が、記事1本あたり5〜10分かかっていました。同期コマンドに置き換えた後は、30秒もかかりません。週に10〜15本の更新があるとすると、週1〜2時間の削減になります。また、WordPress上の操作トラブルが起こり、集中が途切れることがなくなるという効果も実感できました。
まとめ
双方向同期を安全に運用するポイントは3つです。
- フロントマターに同期状態を明記する（「どちらが最新か」を記録として残す）
- WP→ローカル方向は自動上書きしない（自動保存やリビジョンによる誤上書きを防ぐ）
- WP REST API + Application Password で認証する（SSH 不要・プラグイン不要）
「Markdown をソースオブトゥルースにする」というのは宣言だけでは機能しません。それを裏付けるツールが揃って初めて、ローカルファイルへの信頼が生まれます。
次回予告： 第3回は、同期済みの記事群を素材にした RAG（検索拡張生成）レビュー機能を解説します。「この記事、以前書いた内容と重複していないか？」をLLMに自動チェックさせる仕組みの設計と実装を紹介します。
