なぜWordPressをMCPで直接動かさなかったのか
前回、ブログを書くのが面倒なので、考えたことをChatGPTに話せば、そのままWordPressの下書きになる仕組みを作った。
最終的には、こんな構成になった。
ChatGPT ↓ GitHub Issue ↓ GitHub Actions ↓ FTP ↓ cron ↓ WordPress
ぱっと見では、少し大げさである。
そこで当然、こう思う。
ChatGPTからWordPressを触りたいなら、MCPで直接動かせばよかったんじゃないのか。
自分もそう思った。
というか、最初はそのつもりだった。
MCPでWordPressを操作できれば一番楽そうだった
MCPを使ってChatGPTからWordPressを直接操作できれば、かなり楽である。
「この記事をWordPressの下書きにして」
と言えば、そのまま投稿される。
ブログを書くのが面倒だから自動化しようとしているのに、自動化するための操作まで増やしたくない。
なので、まずはMCPで何とかしようと考えた。
GitHubを使うならCodexでいいのでは？
ここでもうひとつ疑問が出る。
GitHubを操作するなら、Codexを使えばいいのではないか。
これはその通りである。
実際、自分もプログラムを作るときには、CodexもClaude Codeも使う。
コードを書いたり、リポジトリを修正したり、開発作業を進めたりするなら、そちらを使うことも多い。
ただ、今回やりたいことは少し違った。
ブログの記事は、コードを書いている最中だけに生まれるわけではない。
普段ChatGPTと仕事の話をしていたり、何かを考えていたりする途中で、
「これ、ブログに書けるな」
と思う瞬間がある。
そのときに、CodexやClaude Codeを開いて、さっきまでの話を説明し直して、記事にして、WordPressに送って……となると、そこでまた一手間増える。
それでは、せっかく「ブログを書くのが面倒だから自動化する」という話なのに、あまり意味がない。
自分がやりたかったのは、
ChatGPTとの会話の途中で、そのまま「これ記事にして」と言えば終わること。
GitHubは記事を書く場所ではなく、そのための中継地点にすぎない。
CodexやClaude Codeができないから使わなかったわけではない。
記事が生まれる場所がChatGPTだったから、そこから動かしたかった。
できるだけ画面を移動したくない。
これも立派なものぐさである。
WordPress.comのMCPを試してみた
ChatGPT側からWordPressを操作できる仕組みを試してみた。
ところが、「ものくさたろう」はWordPress.comで運営しているサイトではない。
レンタルサーバーに自分でWordPressを設置している、いわゆるセルフホスト型のWordPressである。
今回試した仕組みでは、WordPress.com側との連携が前提になっていて、そのまま自分のWordPressを直接操作できるわけではなかった。
別の方法でつなぐことも考えられる。
ただ、ブログの記事を作るためだけに、そこへさらに仕組みを足すのも面倒だった。
ここでMCPはいったん諦めた。
ならWordPress REST APIでいい
次に考えたのがWordPress REST APIだった。
WordPressには投稿を作成するAPIがある。
なので、
GitHub Issue ↓ GitHub Actions ↓ WordPress REST API ↓ 下書き作成
なら、かなり素直な構成になる。
実際に作ってみた。
ところが、うちのサーバーではREST APIへのアクセスが途中で止められた。
返ってきたのはWordPressのエラーではなく、
Please wait while your request is being verified...
というブラウザ確認用の画面だった。
WordPressに届く前に、サーバー側のセキュリティ機能に止められていたらしい。
ブラウザからアクセスする人間なら通る。
しかしGitHub Actionsはブラウザではない。
JavaScriptを実行して、人間らしく待ってくれるわけでもない。
困った。
REST APIにこだわる必要、なくない？
ここでようやく思った。
別にREST APIにこだわる必要なくない？
やりたいことは、WordPressのAPIを使うことではない。
WordPressに下書きを作りたいだけである。
サーバーにはFTPで普通にファイルを置ける。
それなら、
- GitHub ActionsからFTPでJSONを送る
- サーバー側のcronでPHPを動かす
- PHPからWordPressを読み込む
wp_insert_post()で下書きを作る
これでいい。
外からWordPressを操作するから止められる。
だったら、WordPressが置いてあるサーバーの中からWordPressを操作すればいい。
結果として、
ChatGPT ↓ GitHub Issue ↓ GitHub Actions ↓ FTP ↓ サーバー内のPHP ↓ WordPress
という仕組みになった。
結局、MCPが悪かったわけではない
ここは少し重要だと思っている。
MCPを使わなかったのは、MCPが役に立たなかったからではない。
今回のWordPress環境では、MCPを使うために別の仕組みを足すより、すでに使えるFTPを使った方が早かっただけである。
REST APIも同じ。
普通ならREST APIを使う方がきれいだと思う。
でも、きれいな構成を作ることが目的ではない。
ブログを書くのを面倒ではなくすることが目的である。
その目的を達成できるなら、FTPでもcronでも構わない。
むしろ、昔からある地味な仕組みの方が、こういうとき妙に強かったりする。
ものぐさになるために、結構苦労した
ブログを書くのが面倒だった。
だから、自動化しようと思った。
自動化するためにMCPを試した。
うまくいかなかったのでREST APIを試した。
今度はWAFに止められた。
結局、FTPとcronを使う仕組みを作った。
振り返ってみると、
ブログを1本書くより、はるかに面倒なことをしている。
これは少しおかしい。
ただ、一度仕組みを作ってしまえば、次からは、
「これブログにしよう」
と言うだけで下書きができる。
同じ面倒を何度も繰り返さなくて済む。
どうやら自分は、面倒なことが嫌いなのではなく、
同じ面倒を何度もやるのが嫌いらしい。
ものぐさを実現するには、意外と苦労する。
それでも、その苦労を一度で終わらせられるなら、たぶんその方が楽なのである。