前回のおさらい
前回は、WordPressの認証エラーと、パーマリンクが「成功したのに変わっていない」という罠にハマった話をしました。土台はようやく整ってきました。
今回はいよいよ、ブログの見た目を作るテーマの話です。今回選んだのは、国産の有名テーマ「SWELL」。買い切り型で、デザインの完成度と表示速度の評価が高く、日本語ブログとの相性も良いという理由で選びました。
ここでも、地味だけど印象に残る出来事が一つありました。
テーマを買う、というアナログな一歩
SWELLの導入は、まず購入から始まります。この部分だけは、さすがにAPIというわけにはいきません。
購入先は、SWELL公式サイトからのほかに、実はXserverの管理画面からも購入できます。しかも今回のように既にXserverを契約している人なら、こちら経由での購入がお得です。Xserverは公式サイトの定価よりも数%安い割引価格でSWELLを提供しており、購入すると自動でサーバーにテーマが反映されるところまでセットになっています。今回はサーバーもXserverだったので、迷わずこちらの購入ルートを選びました。
購入後は、親テーマと子テーマのファイルをダウンロードします。ちゃんと壊れていないファイルかどうか、ハッシュ値を確認する一手間も挟みました。長年インフラをやっていると、こういう「一見地味だけど省略すると後で泣く」チェックは、つい手が動いてしまいます。
ここから先、実際にサーバーへテーマを配置して有効化する作業は、また自動化のフェーズに戻ります。
安全装置が仕事をした日
導入スクリプトを組んで、最初の本番投入を試しました。ところが、これがうまく走りません。
原因を辿っていくと、テーマの一覧を取得するコマンドの結果を解析する処理に、想定外のクセがあったことが分かりました。取得した一覧のJSONの構造が、想定していた形と少し違っていて、「SWELLがインストールされているかどうか」の判定を正しく行えていなかったのです。判定に失敗した結果、スクリプトに組み込んでいた安全装置が作動し、「想定外の状態なので元のテーマに戻す」というロールバック処理が走りました。
イメージをつかみやすいように、判定処理を簡略化して並べてみます。
一休みポイント:何がどう変わったか
❌ うまく判定できなかった書き方
テーマ一覧をまるごと取得 → 一覧の中からSWELLの行を自分で探す
(一覧の形が想定と少し違い、見つけられず「未導入」と誤判定)
✅ 直した書き方
「SWELLは入っているか?」を直接聞く
「SWELLのバージョンは?」を直接聞く正直、これを見た瞬間は少しヒヤッとしました。ただ、落ち着いて考えると、これはむしろ良い話です。判定が怪しいと分かった時点で、中途半端な状態のまま突き進むのではなく、安全な状態に戻る。まさに設計した通りに安全装置が動いてくれた、ということです。長年、大小さまざまなシステムの構築・運用に関わってきましたが、「トラブルが起きたこと」よりも「トラブルが起きたときに、想定通りに安全に振る舞ったかどうか」の方が、結局は現場の評価を分けます。今回はまさにそちらのケースでした。
判定処理そのものは、テーマの一覧をまるごと取得して解析するのではなく、「このテーマは入っているか」「このテーマの情報を取得する」というように、目的に合わせたより確実なコマンドの組み合わせに直しました。これで再度実行すると、今度は問題なく導入・有効化まで完了しました。
もう一つの小さなクセ
余談ですが、今回のようなコマンドの実行結果を扱う作業では、件数の数え間違いにも一度ならず遭遇しました。取得した結果が一件だけのとき、配列として扱うつもりで書いたコードが、意図せず「配列の中に配列が一つ」という入れ子の形になってしまい、件数を実際より少なく数えてしまう、というものです。
一休みポイント:件数がズレた理由
❌ 件数がズレる書き方
$plugins = (取得した結果)
"プラグイン数: $($plugins.Count)"
→ 結果が1件だけのときに限って、数え方が変わってしまう
✅ 直した書き方
$plugins = @(取得した結果) ← 明示的に「配列として扱う」と宣言
"プラグイン数: $($plugins.Count)"
→ 件数が1件でも複数でも、常に同じ数え方になる「件数が1件のときだけ挙動が変わる」バグは、テストのときにたまたま複数件のデータで確認していると気づきにくいという、地味に厄介な特徴があります。
地味な話ですが、こういう「件数一件のときだけ挙動が変わる」系のクセは、スクリプトを書く上で本当によく出会います。今回は、件数を数える処理を統一的な書き方に直すことで対応しました。
人がやるべき最後の一歩
技術的な導入作業が終わったあとに、もう一つだけ「人間がやるべき」工程が残っていました。SWELLのライセンス認証です。
これは意図的にAPIでは行っていません。ライセンスの本人認証は、購入した本人がWordPressの管理画面にログインして、自分の目で確認しながら行う。この工程だけは、AIエージェントに任せず、自分の手で完結させました。
今回の構築では、「対応するAPIが存在しない操作は仕方なく手動」という割り切りの他に、もう一つの手動の基準を持っています。それは「本人確認や最終承認の意味を持つ操作は、そもそもAPIがあっても人間がやる」というものです。SWELLのライセンス認証は、まさにこちら側の基準に当たります。効率化のためにすべてを自動に寄せるのではなく、「ここは人間がやる」という線を自分の意思で引いておくことも、AIエージェントと組む上では大事だと感じています。
今回の教訓
今回の一連の出来事から得た教訓は、「安全装置は、動いてくれてはじめて価値が分かる」ということです。事前に用意しておいたロールバック処理がなければ、判定ミスのまま中途半端な状態のサイトが世に出てしまっていたかもしれません。地味な安全装置に、あらためて助けられた回でした。
次回予告
サーバー、WordPress、テーマと、ひととおりの土台が揃いました。次回は、「SWELLの基本設計」の話です。サイトの見た目、ヘッダーやフッターの構成、公開に向けて何を決めていったのかをお伝えします。
次回、「基本設計編」でお伝えします。
コメント