※本記事はアフィリエイトプログラムを利用しています（PR）
この記事は、AIに直接WordPressを操作させている人間が書いています。
記事の投稿も、タイトルの修正も、メタディスクリプションの書き換えも、管理画面をほとんど開かずにやっています。私が「この記事のタイトルが検索結果で切れてる」と言えば、数分後には直っている——そういう運用です。
ただし、ここに至るまでにけっこう深い落とし穴がありました。特にレンタルサーバー側の仕様で、教科書どおりの方法が動かなかった話は、同じ構成で詰まる人がいると思うので詳しく書きます。
- AIに記事を書かせるだけでなく、投稿まで任せたい
- WordPressのREST APIを試したが、認証で401が返ってきて詰まっている
- AIにサイトを触らせることの、危ない部分も含めて知っておきたい
最後まで読めば、AIとWordPressをつなぐ全体像と、つまずきやすい認証の壁、そして絶対にやらせてはいけないことが分かります。
全体像：何と何をつないでいるのか
やっていることは、拍子抜けするほどシンプルです。
- WordPress側：もともと備わっている「REST API」という窓口を使う
- AI側：その窓口に対して、記事データを送ったり受け取ったりする
WordPressには最初からREST APIという仕組みが入っていて、記事の取得・作成・更新をプログラムから行える窓口が用意されています。プラグインを入れる必要はありません。
試しに、自分のサイトのURLの末尾に /wp-json/wp/v2/posts をつけてブラウザで開いてみてください。公開済み記事のデータがずらっと返ってくるはずです。読み取りは認証なしでも動きます。
最初の壁：アプリケーションパスワードが動かない
書き込みには認証が要ります。WordPressの標準的なやり方はアプリケーションパスワードという機能です。管理画面のユーザー設定から発行して、リクエストのAuthorizationヘッダーに載せて送る——これが教科書どおりの手順です。
ところが、私の環境ではこれがどうやっても401（認証エラー）で弾かれました。パスワードを再発行しても、書式を変えても通らない。
原因を突き止めるのに、ずいぶん時間がかかりました。結論はこうです。
使っているレンタルサーバーのWebサーバー設定（nginx）が、AuthorizationヘッダーをPHPに渡す前に落としていたのが原因でした。WordPress側から見ると「認証情報が最初から付いていないリクエスト」に見えるので、当然401になります。
つまりWordPressの設定をいくらいじっても直りません。壁はもっと手前にありました。
この症状、ネット上の情報が驚くほど少ないです。「アプリケーションパスワードが401になる」で検索しても、たいていはパスワードの入力ミスやプラグインの干渉の話に行き着いてしまう。サーバーの構成が原因というケースは、なかなか候補に挙がってきません。
同じ症状の方は、まず以下を疑ってみてください。
- 読み取り（GET）は通るのに、書き込み（POST）だけが401になる
- ユーザー名もパスワードも確実に合っている
- プラグインを全部止めても症状が変わらない
この3つが揃っていたら、WordPressではなくサーバー側の設定を見に行くのが近道です。根本的な解決は、契約しているサーバーのサポートに設定変更を依頼することになります。
私が取った回避策と、その正直なリスク
サポートへの依頼と並行して、私は別の方法で動かすことにしました。専用の認証を自分で追加するという方法です。
WordPressにはmu-plugins（must-use plugins）という仕組みがあり、ここに置いたPHPファイルは常に有効になります。そこに「決められた合言葉が一致したときだけ書き込みを許可する」という小さな処理を置きました。
これでAuthorizationヘッダーを使わずに認証が通るようになり、投稿も更新も動くようになりました。
ただし——ここは正直に書きます。
- 合言葉をURLに載せる方式にすると、サーバーのアクセスログに残ります
- 合言葉が漏れた時点で、誰でも記事を投稿・削除できる状態になります
- 本来の正道はあくまでアプリケーションパスワード＋Authorizationヘッダーです
私の場合は「サーバー側が直るまでの回避策」と割り切って使っています。恒久的な構成としては勧めません。同じことをするなら、合言葉は十分に長くして、定期的に変えてください。
つないだ結果、実際にできるようになったこと
認証さえ通れば、あとはかなり自由に動かせます。私が日常的にやってもらっているのはこのあたりです。
| 作業 | これまで | つないだ後 |
|---|---|---|
| 記事の下書き作成 | 管理画面で貼り付け | そのまま下書きとして生成 |
| 検索用タイトルの修正 | 1本ずつ手作業 | 複数本まとめて数分 |
| メタディスクリプション | 入力欄を探して入力 | 本文と同時に設定 |
| 公開状態の確認 | 1本ずつ開いて目視 | 全記事を一括で照会 |
| 予約投稿の確認 | カレンダーを見る | 一覧で抜けを検出 |
いちばん効いたのは、実は執筆そのものではなく「確認」と「直し」でした。
100本を超えたあたりから、人力では全記事の状態を把握しきれなくなります。「公開したつもりで検索エンジンに拒否設定が残っていた記事」を、私は実際にやらかしていました。一括で照会できると、この種の事故がすぐ見つかります。
AIにやらせてはいけないこと
ここは強調しておきたい部分です。つないだ結果、AIは記事を消すこともできる状態になります。だからこそ線を引いています。
- 削除は任せない：下書きに戻す・非公開にするで代替できます。消すのは人間の判断で
- URL（パーマリンク）は変えさせない：既存の評価を捨てることになります
- 使っていない製品の感想は書かせない：これは技術の話ではなく、信頼の話です
- 外部サービスの申請ボタンは押させない：取り消せない操作は人間がやる
「取り消せる操作はAI、取り消せない操作は人間」——この一本で、たいていの事故は防げます。
下書き化は取り消せる。削除は取り消せない。だから前者は任せて、後者は自分でやる。それだけです。
これから試す人へ：順番のおすすめ
いきなり書き込みから始めると、認証で詰まって心が折れます。この順番を勧めます。
- 1. 読み取りから：
/wp-json/wp/v2/postsをブラウザで開いて、データが返るのを確認する - 2. テスト用の下書きで書き込み：本番記事ではなく、消してもいい下書きで試す
- 3. 401が出たら、サーバー側を疑う：WordPressの設定をいじり続けても直らない場合があります
- 4. 動いたら、まず「確認」の作業から任せる：投稿より先に、抜けや事故の検出をやらせると効果が分かりやすい
私が2サイトとも動かしているのはConoHa WINGです。この記事で書いた認証の壁も、実際にこの環境で踏んだものでした。
つまずいた話まで書けるのは、自分で使っているからこそだと思っているので、都合の悪いところも隠さずそのまま置いています。REST APIを本格的に使う予定があるなら、契約前にその点を調べておくと、私と同じだけの時間を溶かさずに済みます。
※プラン内容や仕様は変更されることがあります。最新の情報は公式サイトでご確認ください。
なお、この記事で書いたサーバー側の仕様は契約しているサーバーやプランによって異なります。これから環境を選ぶ方は、REST APIを使う前提があるなら、その点も含めて調べておくと後で楽です。
まとめ
- WordPressは標準でREST APIを持っていて、AIとつなぐのに追加プラグインは不要
- 読み取りは簡単。壁は書き込みの認証
- GETは通るのにPOSTだけ401なら、サーバー側でヘッダーが落とされている可能性を疑う
- 回避策はあるがリスクを理解した上で応急処置として使うこと
- いちばん効くのは執筆より「確認」と「直し」
- 線引きは「取り消せる操作はAI、取り消せない操作は人間」
実際にこの構成で8ヶ月運営して、いくらかかっていくら稼げたのかはAIにブログ運営を任せて8ヶ月。月3万円かけて、売上は55円だったに実額のまま書いています。技術的に動くことと、儲かることは、まったく別の話でした。
コメント