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 参照を主軸に据えることで、安定した執筆サイクルが実現できました。