WordPressのトップページを少し直したかった。
そこでCodexに、トップページをスマホでも読みやすく、シンプルに整えてほしいと頼んだ。
HTMLを作るところまでは進んだ。バックアップも作った。作業ログも残った。
止まったのは、その後だった。
WordPressの管理画面へ本文を入れる段階で、長文の入力や貼り付けがうまく進まなかった。
そこで、人間用の管理画面をそのままAIに操作させる方法をやめた。
代わりに、WordPress REST APIという別の入口を使うことにした。REST APIは、人間用の管理画面を通さず、プログラムからWordPressへ情報を渡すための入口です。
いきなり本番トップページは触らなかった。
まずテスト用の固定ページで、作成できるか、更新できるか、そして元に戻せるかを確認した。
更新できるだけでは足りない。戻せることまで確認しないと、本番には使えない。
その確認をしてから、本番トップページの更新へ進んだ。結果として、トップページの更新にも成功した。
これは、AIにWordPress作業を頼んだら失敗して終わった話ではない。
止まったあとで入口を変えたら、作業が通った話だ。
AIにトップページの改善を頼んだ
最初にやりたかったことは、かなり単純だった。
サイトのトップページに情報が増えてきて、スマホで見た時に少し重たく感じていた。
最初におすすめ記事を1本見せる。困りごとから探しやすくする。スマホでボタンが多すぎないようにする。
そういう調整をしたかった。
そこでCodexに、トップページ改善を依頼した。
Codexは、構成案を作り、HTMLを作り、更新前のバックアップも作った。
ここまでは順調だった。
HTMLはできた。でも管理画面で止まった
問題は、WordPressの編集画面へ本文を入れるところで起きた。
WordPressにはログインできていた。
固定ページの編集画面も開けた。
ボタンも押せた。
カテゴリー変更や保存のような作業も、これまで何度かできていた。
だから最初は、今回もそのまま反映できるだろうと思っていた。
ところが、本文欄に長いHTMLを入れようとすると止まる。
貼り付けようとしても止まる。
別の方法で入力しようとしても止まる。
クリックはできるのに、文章が入らない。
ここが今回の詰まりだった。
なぜ止まったのか
ここで一回、作業を止めた。
これは単なる失敗ではなく、研究材料にした方がいいと思ったからだ。
見えてきたのは、WordPressの権限不足ではなかった。
問題は、AIが人間向けの管理画面へ長文を流し込もうとしていることだった。
人間なら、コピーして貼り付けて保存すれば済む。
でもAIエージェントの場合、ブラウザの入力、クリップボード、本文欄の扱いが不安定になることがある。
今回も、ログインはできる。画面は見える。ボタンは押せる。でも長文入力で止まる、という状態だった。
AIに人間と同じ画面を触らせればいい、と思っていたところに無理があった。
人間用の画面ではなく、別の入口を使うことにした
そこで、WordPress管理画面をそのまま操作する方法をやめた。
代わりに、REST APIで更新する方法へ切り替えた。
画面の入力欄に長い文章を貼るのではなく、WordPressへ直接データを渡す入口を使う。
そう考えると、作業の意味が少し変わった。
AIに無理やり人間用の画面を触らせるのではなく、AIが扱いやすい入口を用意する。
この方が安定しそうだった。
いきなり本番は触らなかった
ただし、いきなり本番トップページを触るのは危ない。
まずはテスト用の固定ページで試した。
確認したのは、主にこの流れだった。
- テスト用の固定ページを作る
- 更新前の本文をバックアップする
- REST APIで本文を更新する
- 更新できたか確認する
- バックアップから元に戻せるか確認する
ここで大事だったのは、更新できることだけを成功にしなかったことだ。
戻せることまで確認して、はじめて本番に使える。
ここを飛ばしていたら、ただ危ない自動化になっていたと思う。
戻せることまで確認してから、本番へ進んだ
テスト固定ページでは、REST APIで作成、更新、復元まで確認できた。
その後、実際のトップページ更新にも進んだ。
途中で通信許可やユーザー名の入力ミスのような別の詰まりもあった。
小さなミスでも、自動化ではすぐ止まる。
だからこそ、対象、権限、更新前の状態、戻し方を確認しながら進める必要があった。
最終的には、本番トップページの更新にも成功した。
公開ページで主要な文言も確認できた。
分かったこと
今回分かったことは、かなり大きい。
AIに作業を任せる時は、人間と同じ画面を触らせるより、AIが扱いやすい入口を用意した方が安定することがある。
WordPressなら、管理画面ではなくREST API。
写真管理なら、フォルダと命名ルール。
記事管理なら、更新前バックアップと差分確認。
AIを便利に使うには、AIそのものを賢くするだけでは足りない。
作業の入口を整える必要がある。
そして、もうひとつ大事なのは、戻せることだ。
本番の前に、テストページで戻せることまで確認する。
この記事で一番持ち帰ってほしいのは、そこです。
今も、この方法で更新している
この実験は、その後も実際のサイト更新で使い続けている。
WordPress管理画面で止まりやすい作業について、REST APIを使うことで、固定ページ更新、投稿更新、公開済み記事への追記、更新前バックアップの保存まで進められるようになった。
ただし、REST APIは完全自動化の道具ではない。
毎回安全に使うには、更新前にバックアップを取ること、本番記事をいきなり大きく書き換えないこと、公開後にブラウザで表示確認することが必要になる。
公開や再公開のように戻しにくい最後の操作は、人間が確認して進める。
つまりREST APIは、「AIが全部やってくれる魔法」ではなく、「AIが詰まりにくい安全な作業入口」として扱うのがよさそうだ。
AIにWordPress更新を頼んでみたいなら、最初から本番記事を触らせない方がいい。
まずはテスト用の下書きページで試す。
どの投稿か。公開か下書きか。戻せる状態か。
そこだけ確認してから、本番に近づける。
地味だけど、その順番がいちばん効いた。
コメント