WordPressの保守、「触るのが怖い」ままにしていませんか——更新を仕組みにした話
「更新したいけど、壊したくない」
WordPressで作ったサイトを保守していると、こういう場面がありませんか。
テーマの文言をちょっと直したい。でも、前に触った人がもういない。どのファイルをどう上書きすればいいかも曖昧で、なんとなく怖い。結局「今は触らないでおこう」になる。
ある保守案件でまさにこの状態に出会いました。
サイト自体は動いている。でも更新のたびに手作業でファイルを転送していて、誰がいつ何を変えたかの記録もない。担当者が変わったら引き継ぎようがない。
これは技術の問題というより、「更新の仕組みがない」ことの問題です。
まず考えたこと——管理する範囲を決める
最初にやったのは、「全部を管理しようとしない」という判断でした。
WordPress本体やプラグインの更新は、管理画面からボタンひとつでできます。わざわざ仕組みに乗せる必要はありません。
管理するのは見た目を決めているテーマ部分だけ。ここだけ変更の履歴を残して誰が触っても安全に更新できるようにする。
手元の開発環境にもテーマフォルダだけを持ってくる形にしました。
WordPress全体を丸ごと管理するのではなく自分たちが実際に触る部分だけを切り出す。管理する範囲を絞ったことで仕組みはぐっとシンプルになりました。
最初の壁——「つながらない」
変更を確定したら自動で本番に反映される仕組みを作ろうとしたとき壁にぶつかりました。
サーバーへの接続が通らない。認証で弾かれる。手元のパソコンからは問題なくつながるのに自動化の処理からだけ通らない。
ここで判断を誤りました。
「サーバー側が海外からの接続をブロックしているからこの方式では無理だろう」と決めつけて、別の接続方式に切り替えたんです。
別の方式もうまくいかなかった
切り替えた方式ではサーバーへのログインまでは通りました。ところが、肝心のファイル転送のところでエラーが出る。データのやり取りをする経路がうまく確立できないという、また別の壁です。
しかも、この方式はファイルを毎回まるごと送る仕組みなので仮に動いたとしても時間がかかる。変更した部分だけを差分で送れる最初の方式のほうが、保守の運用としては明らかに優れていました。
ここで立ち止まって、最初の方式をもう一度ちゃんと調べ直すことにしました。
原因は、もっと手前にあった
成功している事例を調べていくと答えはあっさり見つかりました。
接続に使う鍵ファイルには複数の「書き方」があって、自動化の仕組みが受け付ける形式と手元で作った鍵の形式が合っていなかっただけ。形式を変換したら最初の方式で一発で通りました。
もうひとつ、サーバー側で海外からの接続を許可する設定も必要でした。これは管理画面からすぐに変更できるもので、難しいことではありません。
つまり、必要だったのは二つだけ。鍵の形式を合わせることと、接続制限を解除すること。最初からこの二つを押さえていれば、10分で終わる作業でした。
仕組みにしたことで変わったこと
今はテーマの変更を確定すると、変更された部分だけが数分で本番に反映される状態になっています。
変わったのは速さだけではありません。
- 「誰が何を変えたか」が全部残る。
- 前任者の作業も、外部パートナーの修正も、すべて履歴として追える
- 本番を直接触る必要がなくなった。
- 「うっかり上書き」の事故がなくなる
- 担当者が変わっても引き継げる。
- 仕組みがあるので、属人化しない
「触るのが怖い」がなくなるだけで保守に対する心理的なハードルがまったく変わります。
遠回りしたから言えること
今回の一番の学びは、「動かない」と「原因がわかった」は別だということでした。
接続エラーを見て、「サーバー側の制限だろう」と推測で動いてしまった。別の方式に逃げてそこでもつまずいて、ようやく最初の方式に戻ってきた。振り返れば、最初のエラーの時点でもう少し丁寧に原因を切り分けていれば、遠回りせずに済んでいました。
保守の現場ではこういうことがよくあります。目の前の問題を早く解消したくて、原因を追いきる前に回避策に飛びつく。それで動いてしまうと本当の原因が埋もれたままになる。
この構成は同じサーバーで運用している他の保守案件にも同じ型で展開できます。一度仕組みを作れば次からは使い回すだけです。
WordPressサイトの保守で「更新が怖い」「属人化している」「引き継ぎが不安」と感じているならまず管理する範囲を決めて、更新の流れを仕組みにするところから始めるのがいいと考えています。
そして仕組みを作るときは、「動いた」で終わらせず、「なぜこの構成なのか」まで詰めておく。それが、次の担当者への一番の引き継ぎになります。