【結論】
困りごと： WordPressのトップページ改善をCodexに頼んだが、最後の「本文を管理画面へ入れる」ところで止まった。
AIへの相談内容： 小さな仕組みの作り方のトップページを、スマホで読みやすく、シンプルに改善してほしいと依頼した。
実際にやったこと： Codexが改善HTML、バックアップ、作業ログを作成。その後、WordPress管理画面へ反映しようとした。
結果： 管理画面へのログインやクリックはできたが、長文入力・貼り付けで停止。そこで、管理画面ではなくWordPress REST APIで更新する実験へ切り替えた。テスト固定ページでは作成・更新・復元まで成功し、その後、実際のトップページ更新にも成功した。
今どうなっているか： REST APIで投稿作成、投稿更新、公開、固定ページ更新、更新前バックアップ、公開ページ確認まで実行できた。EXP-007は成功候補として扱っている。
ひとこと： AIに作業を任せる時は、人間用の画面を触らせるより、AIが扱いやすい入口を用意した方が安定しそうです。
この実験について
今回の実験IDは、EXP-007。
テーマは、
WordPress更新を管理画面ではなくREST APIで実行できるか
です。
最初からこの実験をやるつもりだったわけではありません。
もともとは、サイトのトップページを少し整えるだけの作業でした。
スマホで見た時に、情報が増えてきて少し重たく感じたので、もっとシンプルにしたかった。
そこでCodexにトップページ改善を依頼しました。
Codexは、構成案を作り、HTMLを作り、バックアップも作りました。
ここまでは順調でした。
止まったのは、その後です。
WordPressの編集画面へ本文を入れるところで、作業が止まりました。
困っていたこと
WordPressにはログインできています。
固定ページの編集画面も開けます。
ボタンも押せます。
カテゴリー変更や保存のような作業も、これまで何度かできていました。
だから最初は、
今回もそのまま反映できるだろう
と思っていました。
ところが、本文欄に長いHTMLを入れようとすると止まる。
貼り付けようとしても止まる。
別の方法で入力しようとしても止まる。
クリックはできるのに、文章が入らない。
ここが今回の詰まりでした。
当時やりたかったこと
やりたかったこと自体は単純です。
- 最初におすすめ記事を1本見せる
- 困りごとから探しやすくする
- 実践済み、実験中、アイデアを分かりやすくする
- 投稿募集への導線を残す
- スマホでボタンが多すぎないようにする
内容そのものは難しくありません。
実際、Codexはローカル上で改善HTMLを作れました。
バックアップも作れました。
作業ログも作れました。
でも、最後の「WordPress管理画面へ反映する」ところだけがうまくいかなかった。
つまり、作業の本体ではなく、反映作業で止まったわけです。
方針を変えた
ここで一回、作業を止めました。
理由は、これが初めてではなかったからです。
以前にも、WordPressの入力や貼り付けで止まったことがありました。
そこで、
これは単なる失敗ではなく、研究材料にした方がいい
と考えました。
Codexには、今止まっている原因を調べさせました。
そこで見えてきたのは、WordPressの権限不足ではありません。
問題は、
AIが人間向けの管理画面へ長文を流し込もうとしていること
でした。
人間なら、コピーして貼り付けて保存すれば済む。
でもAIエージェントの場合、ブラウザの入力、クリップボード、本文欄の扱いが不安定になることがある。
今回も、
- ログインはできる
- 画面は見える
- ボタンは押せる
- でも長文入力で止まる
という状態でした。
REST APIで試すことにした
そこで、WordPress管理画面をそのまま操作するのではなく、REST APIで更新する方法へ切り替えました。
いきなり本番トップページを触るのは危ないので、まずはテスト固定ページで試しました。
手順はこうです。
1. テスト用の固定ページを作る 2. Application Passwordを一時的に使う 3. REST APIで現在の本文をバックアップする 4. 短いテスト本文を送る 5. 更新できたか確認する 6. バックアップから元に戻せるか確認する
この順番にしました。
「更新できる」だけでは足りません。
戻せることまで確認しないと、本番には使えません。
今日時点の結果
テスト固定ページでは、REST API更新に成功しました。
確認できたことは以下です。
- REST APIで下書き固定ページを作成できた
- REST APIで本文を更新できた
- 更新前バックアップを保存できた
- バックアップから元の本文へ復元できた
- REST APIでこの記事の下書き投稿も作成できた
- カテゴリーとタグも設定できた
- REST APIでこの記事を公開できた
- REST APIでトップページも更新できた
- 公開ページで主要文言を確認できた
Application Passwordは一時的に使用しました。
ただし、認証情報はローカルファイルや公開資料には保存していません。
ここはかなり重要です。
AIが勝手に認証情報を保存して、あとから何でもできるようにする運用にはしない。
使う時だけ使い、不要なら削除する。
この形が安全だと思います。
失敗した点
今回の失敗は、WordPressを更新できなかったことではありません。
本当の失敗は、
AIに人間向けの画面をそのまま操作させればよい
と考えていたことです。
人間が使う画面は、人間には便利です。
でもAIエージェントにとって便利とは限りません。
WordPressの編集画面は、見た目は普通の入力画面に見えます。
でも実際には、ブロックエディター、自動保存、HTML編集、クリップボード、保存ボタンなど、いろいろな仕組みが重なっています。
そこへAIが長文を入れようとすると、止まることがある。
これは今後も起きそうです。
もうひとつ、途中で別の詰まりもありました。
REST APIでトップページを更新しようとした時、最初は通信エラーのように見えました。
その後、ネットワーク許可を確認すると通信は戻りました。
しかし次に401エラーが出ました。
これはWordPress側の問題ではなく、ユーザー名の入力ミスでした。
つまり今回の詰まりは、ひとつではありません。
- 管理画面への長文入力が不安定だった
- Codex側のネットワーク許可が必要だった
- WordPressユーザー名を正確に扱う必要があった
小さなミスでも、自動化ではすぐ止まります。
ここも大きな学びでした。
学んだこと
今回分かったことは、かなり大きいです。
AIに作業を任せる時は、
人間と同じ画面を触らせる
よりも、
AIが扱いやすい入口を用意する
方が安定しそうです。
WordPressなら、管理画面ではなくREST API。
物件管理なら、記事本文だけでなくCSVやローカル台帳。
写真管理なら、フォルダと命名ルール。
AIを便利に使うには、AIそのものを賢くするだけでは足りない。
作業の入口を整える必要がある。
今回の詰まりは、そのことを教えてくれました。
今ならどうするか
今なら、最初からこうします。
まずWordPress管理画面で頑張らない。
Codexには、記事本文やトップページHTMLをローカルで作らせる。
次に、更新対象をテストページに限定する。
REST APIで短い文章を更新してみる。
バックアップと復元まで確認する。
その後に、本番ページへ進む。
「いきなり本番を触る」のではなく、
「小さく試して、戻せることを確認してから進む」
という順番です。
これはWordPressに限らず、AIエージェント運用全体に使える考え方だと思います。
研究メモ
状態： 成功候補
関連実験： EXP-007
使った道具： Codex、WordPress、REST API、Application Password
更新履歴
2026-06-17 初版公開 2026-06-17 トップページID 12のREST API更新成功、認証エラー原因、公開確認結果を追記
確認できたこと： テスト固定ページの作成、更新、復元。下書き記事の作成。カテゴリーとタグの設定。
未確認のこと： 本番トップページID 12の更新。スマホ表示・PC表示まで含めた本番反映。
次の一手： 本番トップページを触る前に、現在本文のバックアップ、差分確認、人間確認を挟む。
まとめ
今回の実験は、第一段階としては成功候補です。
WordPress管理画面で止まった作業を、REST APIへ逃がすことで、テスト固定ページの作成・更新・復元まで確認できました。
これは派手な自動化ではありません。
でも、今後100本、200本と記事や物件情報を扱うなら、かなり大事な分岐点になると思います。
AIに作業を頼む時、ただ「画面を操作して」と言うだけでは限界がある。
AIが動きやすい入口を作る。
今回の研究結果は、そこです。
2026年6月17日：本番運用で使える段階に近づいた
この実験は、その後も実際のサイト更新で使い続けている。
WordPress管理画面で止まりやすい作業について、REST APIを使うことで、固定ページ更新、投稿更新、公開済み記事への追記、更新前バックアップの保存まで実行できた。
特に大きかったのは、「パーソナルOS実験室」の固定ページ更新や、公開済み記事への追記を管理画面に頼らず進められたことだ。
これにより、EXP-007は単なる回避策ではなく、研究所OSの実運用ルートになりつつある。
ただし、毎回安全に使うには、以下の条件を守る必要がある。
- 更新前に必ずバックアップを取る
- いきなり本番記事を大きく書き換えない
- 人間が確認した記事だけ公開・更新する
- 認証情報をファイルに残さない
- 公開後にブラウザで表示確認する
つまり、REST APIは「完全自動化の道具」ではなく、「AIが詰まりにくい安全な作業入口」として扱うのがよさそうだ。
関連：パーソナルOS実験室
コメント