インフラ屋、AIエージェントと二人三脚でブログを立てた話 第2回:WordPress導入・SSL・認証編

前回のおさらい

前回、サーバーとドメインの土台を作りました。Cloudflareにネームサーバーを渡した途端、SSLの自動設定APIが使えなくなるという、地味だけどしっかり効いてくる落とし穴を踏んだところまでお話ししました。

今回は、いよいよWordPressのインストールです。ここも一筋縄ではいかなかったので、じっくり書いていきます。

WordPressを入れる、そこまでは順調

WordPress自体のインストールは、サーバー側のAPIで一発でした。サイト名を決めて、管理者アカウントを作って、実行。数十秒待つと、もうブログの入り口ができあがっています。長年インフラをやってきた身としては、この手軽さに正直びっくりします。オンプレでミドルウェアを一つ入れるだけでも、依存関係の確認やらバックアップやら、それなりの段取りが必要だった時代を知っているので。

ただし、ここでも一つだけ小さな「間」がありました。インストールのAPIリクエスト自体は成功したのに、その結果が一覧で確認できるようになるまで、体感で数十秒ほどの時間差があったのです。二重にインストールしてしまう事故を避けるため、スクリプト側は「一定時間内に確認が取れなければ、いったん安全に停止する」という作りにしていました。実際にこの安全停止が働き、最初は「あれ、失敗した?」と一瞬身構えましたが、状態だけを確認する別の処理で見直すと、インストール自体はきちんと完了していました。焦って作り直そうとせず、確認用のリクエストだけを投げ直す。地味ですが、こういう「待てる」設計のありがたみを感じた場面でした。

URLの設定も、httpからhttpsへ、忘れずに直します。ここまでは特に問題なし。「意外とスムーズに進むもんだな」と思っていました。この手の油断が、だいたいフラグになるんですよね。

401の壁

次にやりたかったのは、WordPressのREST API経由での操作です。手作業ではなく、AIエージェントがAPIを叩いて設定を進めていく、今回の「API-first」の本領発揮の場面です。

認証には、WordPress標準のApplication Passwordという仕組みを使います。管理画面で発行したパスワードをAPIリクエストに載せるだけの、シンプルな仕組みのはずでした。

ところが、何度やっても401(認証エラー)が返ってきます。パスワードは合っている。ユーザー名も合っている。それでも通らない。

こういうとき、長年の癖でまず疑うのは「本当に自分の設定ミスか、それとも環境側の問題か」の切り分けです。CloudflareのプロキシとWordPress側のオリジンサーバー、両方で試して、どちらもダメ。ということは、パスワードやコード側の問題ではなく、もっと手前の層で何かが起きている可能性が高い。

調べていくと、原因はサーバーの`.htaccess`にありました。Application Password認証は、HTTPリクエストの「Authorization」ヘッダーにパスワード情報を載せて送るのですが、レンタルサーバーの初期設定によっては、このヘッダーがPHPまで届かず、途中で握りつぶされてしまうことがあります。今回のサーバーも、まさにこのパターンでした。

対応としては、`.htaccess`に、このヘッダーをきちんとPHPへ引き渡すための1行を追加するだけです。原因が分かれば拍子抜けするほど小さな修正ですが、原因不明の401エラーに向き合っている間は、なかなか気が抜けませんでした。この手の「見えないところで握りつぶされている」系のトラブルは、インフラをやっていると本当によく出会います。今回もその一つでした。

一休みポイント:何が起きていたか

❌ 直前まで
ブラウザ・APIクライアント → Authorizationヘッダー付きリクエスト
                           → サーバーの初期設定で握りつぶされる
                           → PHP(WordPress)には何も届かない
                           → 「認証情報がない」ものとして401

✅ 修正後
.htaccessに1行追加
                           → AuthorizationヘッダーがそのままPHPへ転送される
                           → WordPressが正しく認証情報を受け取れる

パスワードもコードも合っているのに、そもそも「情報がWordPressまで届いていない」。この視点に切り替えられたのが、遠回りの末の突破口でした。

修正を反映して、改めてAPIを叩くと、今度は無事に200が返ってきました。地味ですが、この瞬間の安心感は何度経験しても良いものです。

「成功した」のに、変わっていない

次にぶつかったのは、もっとタチの悪いパターンです。

WordPressのパーマリンク(記事URLの形式)を、日付が入らないシンプルな形に変更しようとしました。REST API経由で設定を送ると、レスポンスは「200 OK」。エラーもなし。「よし、これで完了」と思いました。

ところが、実際にサイトを見てみると、URLの形式が変わっていません。何度見直しても、リクエストは成功しているように見えるのに、結果は反映されていない。

これは正直、一番厄介なタイプの不具合です。エラーが出ていれば、そこを直せばいい。でも「成功したように見えて、実は何も起きていない」場合、まず「本当に何も起きていないのか」を疑うところから始めなければなりません。

原因を調べていくと、WordPressのREST API(の一般公開されている設定エンドポイント)には、そもそもパーマリンク構造を変更するための項目が用意されていない、ということが分かりました。つまり、こちらが送ったデータは、エラーにもならず、単に無視されていたのです。行儀の良いAPIであれば、対応していない項目にはエラーを返してほしいところですが、現実はそう甘くありません。

一休みポイント:見た目は同じ「成功」でも中身が違う

❌ 起きていたこと
APIへ「パーマリンクを変更して」と送信
  → 200 OK(成功のレスポンス)
  → でも実際は「知らない項目」として黙って無視されただけ

✅ 実際に効いた方法
WP-CLIで直接コマンドを実行
  → その場でパーマリンクの設定ファイルまで書き換わる

「200 OKが返ってきた」=「やりたいことが実行された」ではない。この一件で、この思い込みを強く意識するようになりました。

面白いのは、これが「新しい機能だからまだ実装が粗い」という話ではないことです。WordPressのREST APIは基盤部分が2015年、主要なエンドポイントが2016年にコアへ統合されていて、2026年の今となってはもう10年近い歴史を持つ、十分に枯れた仕組みです。それでもパーマリンクという項目だけは、最初から一度もこの公開APIの対象に加えられていません。おそらく、この設定を変えるとサーバー側の`.htaccess`まで書き換わるという、単なる値の保存では済まない副作用があるからでしょう。長く安定して使われてきたAPIほど、「なんでも公開しない」という枯れた判断がどこかに残っている。そんな見方もできる気がします。

最終的には、WordPressのコマンドライン管理ツール(WP-CLI)を使って、サーバーに一時的な作業用の鍵を発行し、そこから直接コマンドで設定を変更する形に切り替えました。作業が終わったら、この鍵はきちんと削除しています。

ここで、ちょっと面白い挙動にも気づきました。この一時鍵を消したところ、鍵を使った接続機能そのものだけでなく、連動して「海外からのアクセスを制限する」設定まで一緒に無効化されていたのです。元の制限を慌てて戻そうとしたところ、今度はエラーが返ってきました。鍵が1つもない状態では、この制限だけを先に有効化することができない仕様だったようです。結局、鍵を消した時点で両方とも無効になっているのが「正しい状態」だと理解し、実害がないことを確認して次に進みました。機能同士が思わぬところで連動している、というのも、実際に手を動かしてみないと分からない類の発見でした。

必要な範囲だけ、必要な時間だけ、権限を開ける。この基本は、AIエージェントに作業を任せる場合でも変わらず大事だと感じました。

今回の教訓

「HTTPステータスが200なら成功」という思い込みは、想像以上に根深いものです。今回のように、対応していない項目が黙って無視されるケースがある以上、変更後は必ず実際の状態を取得して確認する、というワンクッションが欠かせません。今回の一連の構築作業でも、「変更前に現状を取得し、変更後にもう一度取得して答え合わせをする」という手順を徹底したことで、この見えにくい不具合にも気づくことができました。

次回予告

WordPressの土台が整ったところで、次はいよいよ見た目を作るテーマ、SWELLの導入です。ここでも、テーマの判定処理がうまく動かず、せっかく入れたはずのテーマが元に戻されてしまうという、ちょっとしたヒヤリとする出来事がありました。

次回、「SWELL導入編」でお伝えします。