AIを業務のどこに組み込めば、現実的な効率化につながるか。私にとってその答えの一つが、WordPressでの執筆と公開でした。アイデア自体は早くからあったのですが、「日々の運用で迷わず使える手触り」を得るまでには試行錯誤が必要でした。

なぜ WordPress なのか

数あるブログサービスの中で WordPress を選んだ最大の理由は、公式の REST API が充実していることです。外部ツールからの連携余地が広く、AI と直接的にやり取りする構成を作りやすい。生成AIが作成したテキストを人間がコピペする形は、ワークフローとして洗練されていないため避けたいと考えました。

最初のアプローチ：GPTs による直接操作

はじめは GPTs にファンクションコールを定義し、チャットボットから WordPress を直接操作する実験をしました。固定料金で使えるのは魅力ですが、長文の保持・推敲が続く執筆フローではコンテキスト容量の制約がボトルネックになり、安定運用の観点では課題が残りました。

方向転換：CLI と組み合わせる

2025 年初頭、CLI 系の生成 AI が普及しはじめ、試してみると「仕様に沿った機械的な反復処理」に非常に強いことがわかりました。CLI に自作ツールを渡せば、README とヘルプを根拠に、一定品質の操作を一貫して行える。そこで本稿の主役となる WpAiCli を作りました。

フェーズ1：REST 直叩きのフル機能 CLI

最初の段階では、投稿・リビジョン・カテゴリ・タグ・メディアの作成／取得／更新／削除を網羅。WordPress運用に必要なコマンドをひと通り備えました。とはいえ、AI が“その場で取得したサーバーデータをどう扱うか”という判断は不得手で、レビューや改稿の流れが途切れやすい問題が残りました。

学び：API を叩く術よりも、編集対象の素材を手元に揃える設計のほうが、AI と人の分担に向いている。

フェーズ2：ローカル主体（キャッシュ & 双方向同期）へ

そこで設計を見直し、WordPress の状態をローカルに可視化。人がテキストファイルを直接編集し、差分だけをプッシュする形にしました。

双方向同期：サーバ → ローカルへ取り込み（sync）、ローカルの差分だけをサーバへ反映（push）
キャッシュ構造（例）
wp-ai-cache.db # 内部用SQLite（非編集） posts/ # 1投稿=1 Markdown（YAMLフロントマター＋本文） categories/*.yaml tags/*.yaml media/*.{bin, yaml}
競合時は明示解決：resolve local-wins / server-wins で方針を指定

この方針により、AI はローカルのファイル群を入力として整形・校正し、確定した差分を確実に反映できます。人は落ち着いて原稿と構成に集中でき、両者の役割が整理されました。

リビジョンは「一応」：本命はローカルGitの履歴運用

WordPress の REST API はリビジョン（過去版）をサポートしており、本ツールでも取得・復元には対応しています（必要十分の範囲で）。一方で、実務上の強みはキャッシュフォルダを Git で管理することにあります。

AI が自発的に過去版を参照できる：git log や git diff の文脈から、意図や推敲の流れを把握し、過去の良い表現を現在の構成に自然に接続できます。
フロントマターごと履歴化：タイトル・ステータス・カテゴリ/タグ・カスタムフィールドを含め、構造的に時系列を追える。
オフラインでも強い：ネットワークに依存せず、git show で即比較／差し戻し。画像は Git LFS を併用するか、メタだけ Git に入れるなど柔軟に運用可能。

.gitignore の一例

wp-ai-cache.db
media/*              # バイナリは LFS 推奨
!media/*.yaml

まとめると：WPのリビジョン機能は“保険”として確保しつつ、日々の執筆サイクルはローカルGitの履歴が中心。これにより、AI が自律的に過去版を読み込み、意図を踏まえた提案や調整を行えるようになります。

運用上のポイント（README 準拠）

接続情報の登録・切替、投稿/分類/メディアの CRUD と同期、--format table|json|raw などの出力形式切替に対応。
投稿のローカルキャッシュと双方向同期が基本。リビジョン取得、分類・メディアの同期も備えています。
Markdown の扱いは client/server モードに対応（サーバ側で Markdown 変換を行う場合は、_md_source メタの取り扱いに注意）。
競合検出時は resolve コマンドで明示的に解決。
（詳しいコマンド一覧やワークフローは README を参照してください。）

よく使う流れ（例）

サーバ → ローカルで posts sync。必要に応じて taxonomies sync / media sync。
posts/<ID>-<title>.md を編集（フロントマター含む）。
ローカルGitにコミット（AI が履歴を参照しやすくなる）。
確定分のみ push <ID>。必要に応じて revisions 機能を利用。

これから

wpai self-update（自己更新）
WordPress 側の補助プラグイン（_md_source の扱いを明確化）
API モックとローカル差分テストを含む自動テスト
署名・公証、テンプレート集の整備など

参考リンク

NuGet: https://www.nuget.org/packages/WpAiCli/
GitHub: https://github.com/aroooy/WpAiCli

おわりに
生成AIとWordPressの距離は、「素材をローカルに引き寄せる」だけで大きく縮まります。WpAiCli は、人が原稿を磨くプロセスを中心に据えながら、AI の反復処理と参照能力を引き出すための土台です。WP のリビジョンは保険として確保しつつ、ローカルGit履歴 × AI 参照を主軸に据えることで、安定した執筆サイクルが実現できました。