はじめに
今回紹介するのはPHPやWordPressに踏み込んだ技術的な話ではなく、AIを用いたレガシーコード（プロジェクト）のリファクタリングや改善に関する情報共有です。
本記事におけるレガシーコード（プロジェクト）のリファクタリングや改善とは「第三者が開発した詳細不明プロジェクトを早急にカバーする事態になった際の応急措置（エラーハンドリング）」を指します。
具体的には、予備知識やドキュメントがないまま第三者が作ったWordPressテーマがPHP8系で動かなくなった（サイトダウンした）──そんな時、AIをどう活用して復旧にこぎつけたのかを紹介します。
本来こういった事態にならないよう一般的にはCI/CDや監視ツール、社内ワークフローなどできちんとコントロールすべきです。
しかしながら、人的資源や知見の乏しい弊社のような環境も世の中には少なくないのではと思い、以下のような対象読者を想定して記事にしていきます。
対象読者
- テストコードや詳細情報が無い中で緊急性の高い対応を求められている方やチーム
- フロント側（例：開発者ツールのConsoleパネル内）にエラー情報が出ておらず途方に暮れている初学者
- HTML,CSS,JSは学んだものの、サーバーサイドについて少し苦手意識のある方
- AIを用いたデバッグ方法や問題究明、課題解決に興味のある方
- AIの利活用において無料ユーザーを貫いている方
結論： 情報・状況把握して、それらをAIに投げて壁打ちしながら仮説出し及びコード改修を進める
先にも書きましたが、こういった事態にならないよう一般的にはCI/CDや監視ツール、社内ワークフローなどできちんとコントロールすべきです。
そして普段からこまめにメンテナンスやバックアップを取っておくなど予防的措置も効果的です。
以下はこうした予防措置フェーズを超えてしまって、実害発生フェーズに突入している状況で話を進めます。
最も大事なのはまずは落ち着いて情報・状況把握することです。
詳しくは後述しますが、AIを活用するにはAIに提供するための情報がかなり大事になってきます。
その次に大事になるのが、自分の知識や経験を総動員して問題の発生源を考えて（仮説を出して）、いくつかの可能性を箇条書きでも良いので言語化しておくことです。
しかし現実的には、時間上の制約や問題の切り分け方法、実際の開発環境、クライアントの事情など複合的な要因で「仮説出し及び言語化」に時間が取れないケースもあるかと思います。
こういった現実的対処を素早く行う上では「情報・状況把握して、それらをAIに投げて壁打ちしながら仮説出し及びコード改修を進める」という方法が、今回の筆者の場合はうまくはまりました。
ちなみに、今回の筆者のケースはこのようにして発生しました。
- 社内にて、グラフィックデザイナーに対してweb開発にチャレンジするようお達しが出る
- デザイナーがWordPressサイトを開発し、 既存WPサイトのサブディレクトリにホスティング及びサーバー設定を調整したところ、既存サイト内の一つがサイトダウンした
- 補足：既存WPサイトは多言語サイトで、今回デザイナーが開発した新規サイト含めて合計9つのWPサイトが一つのドメイン配下に設置されているという状況です
- 筆者が定期メンテナンスで確認した際にサイトダウンしていることが発覚
当問題の原因は「PHP8系に準拠した記述になっていなかったり、非推奨の関数やメソッドを使っていたりした」ことでした。
余談ながら上長報告した際に、筆者は初めて今回デザイナーが制作していることを知りました。
筆者確認の3日前にホスティングしたそうで最低でも3日間もサイトダウンしており、その間に誰も把握できていなかったということになります。
サイトが真っ白になって──
まずは開発者ツールのログ（Consoleパネル）を確認したのですが何もエラーや警告が表示されておらず、ネットワークパネルにも別段変なところはありませんでした。
しかしElementsパネルでDOMツリーを確認したところ body内に何もレンダリングされていなかった のです。
サーバーを見に行くと数日前に見慣れないディレクトリが追加されていることに気づき、一瞬ドキッとしたのですが中身をみるとwp-content, wp-adminなど標準的なWordPressのディレクトリ構成でした。
- 補足： この問題が起きる2カ月ほど前──
テスト環境用サーバーのPHPを7系から8系にアップグレードした際に一部サイトが同様の事態に陥りました。
当時は別作業に追われていることもあって「テスト環境でかようなことが起きました」という報告程度で原因究明は行っていませんでした。
今回、こまめにチェックする予防的措置のおかげで本環境でのアクシデント発生時も大体のアタリを付けられたので、予防的措置の実施や習慣化は面倒ですが効果的だと思います。
この時は一旦7系にダウングレードして復元し、上長に詳細を伝えて対応終了という感じでした。
今後については「対策や対応を考えておく」という返答で保留状態となっていました。
上長にサイトがダウンしている状態を伝えたところ、上記を思い出されたようでした。
筆者は一旦、以前に伝えたテスト環境で起きたことの再報告と、知らないWordPressサイトが追加されていることを報告。
すると、デザイナーがWordPress開発しており数日前にホスティングした事実を伝えられました。
ことの起こり（顛末）
- グラフィックデザイナー
- 初めてWordPressサイトを開発：PHPのverは最新PHP8系
- ホスティングしたところ「PHPのバージョンが古いから更新してね」的な通知が出てきたのでそれに従って更新し、上長に報告
- 上長
- 報告を受けて 上長判断および上長自身が操作してサーバーパネルで当該サブディレクトリのみをPHP7系から8系にアップグレードしたそう
するとなぜか、 サーバー内でPHPが7系から8系にすべて自動的にアップグレードされていて、9つあるうちの1つが落ちていた。という顛末です。
上長の考えでは「サブディレクトリだけアップグレードしたので当然そこだけがPHP8系になると思っていた」ということだそうです。
今となっては真相は闇の中ですが、もしかすると操作を間違えて全体アップグレードしてしまっていたのかもしれません。
取り急ぎグレードダウンして対応
落ちているサイトはクライアント側でもぼちぼち使っているものだったので取り急ぎPHPを7系に戻しました。
無事に落ちているサイトも表示されるようになったのですが、一つのサイトのためだけにPHPを7系のまま運用していくのも良くないです。
そこで上長は「特にSEOが重視されているようなサイトでもなかったので、当該サイトのみ別ドメインを取得してPHP7系で運用する」という現実的な判断を下しました。
ただしこれでは根本的解決には至っていないですし、そのサイトの無理な延命処置のためにドメイン費用や通知に関する手間などコストがかかるのが少し嫌だったのです。
そこで、タイトルにあるようにテーマをPHP8系に対応する改修作業を行うことにしました。
情報・状況把握を行う
サイトダウンした改修対象サイトの詳細は以下です。
サイトの詳細情報
- 10年ほど前に
BizVektorというLightningの前身？テーマをもとに作成されている- ※子テーマではなく、当該テーマの中身を別途複製した別テーマとして作成されている（そもそもそんなテーマをずっと使い続けるなという話でもあるのですが……）
- 外部ベンダーが一部開発を請け負っており、そこが提供する機能との兼ね合いでサイトの大規模リファクタリング・修正などは厳しい
- 開発者は既に退職していて当然ドキュメントなど必要情報もない（あっても使用プラグインの説明などメモ書き程度）
-
BizVektorの開発は2018年で止まっている（※Lightningに移行推奨を通知してくれていた）
今回、不幸中の幸いで原因がある程度は判明しているものでしたが、AIへの情報提供において整理しておくのは重要です。
サイトダウンした原因
BizVektorテーマの中身を別途複製した別テーマがPHP8系に対応できていなかった。
- 実際の改修箇所のうち根本的要因になっていた部分
class WP_Widget_ChildPageList extends WP_Widget {
// 修正: PHP8対応： __construct() に変更
+ function __construct() {
- function WP_Widget_childPageList() {
$widget_ops = array(
'classname' => 'WP_Widget_childPageList',
'description' => __( 'Displays list of child page for the current page.', 'biz-vektor' ),
);
$widget_name = biz_vektor_get_short_name() . '_' . __( 'child pages list', 'biz-vektor' );
+ parent::__construct('childPageList', $widget_name, $widget_ops);
- $this->WP_Widget('childPageList', $widget_name, $widget_ops);
}
...
..
.
この同じような調整が必要となるファイルたちが深い階層にあるもの含めて数ファイルほどありました。
AIに投げて壁打ちしながら仮説出し及びコード改修を進める
今回、GitHub Copilotと共に進めながら、途中でブラウザ版のClaudeを使用しました。
理由はどちらも無料ユーザーであるためです。
筆者は無料ユーザーなので以下のようなことをしていますが、有料ユーザーの場合はClaude CodeやGitHub Copilotを存分に利用したりしてもっとスムーズに解決できると思います。
まずGitHub CopilotはAskモードにして自律行動しないようにします。
先述したサイト詳細情報のほか、これまでの経緯やテスト環境での出来事を、マークダウン形式のプロンプトにしました。
この時、以下の内容を制約として明記しました。
- まずはプロジェクトの全体像を把握して、どんなサイト・サービスかを言語化して
- ステップバイステップで作業フェーズを考えて、フェーズごとのタスクを想定および選定して
- フェーズが変わるタイミングやタスク実施時は随時確認して
- 不明点や疑問点があれば作業を止めて聞いて
そして、GitHub Copilotが理解してくれたところでAgentモードに切り替えて作業に進んでもらいます。
今回の対応がそこまで複雑なケースではなかったのか、結構こんなプロンプトでも期待通りに働いてくれました。
最初の問題検知フェーズで、Copilotが原因となるPHP8系に準じていないファイルやコードの選定を行ってくれました。
その次に、具体的な解決策（タスク想定および選定）を行ってくれて、根本原因が非推奨な記述が要因であることと、その修正方法を提示してくれました。
あとは次のフェーズに移って各タスクを実行してもらい、こちらで処理結果をチェックするだけです。
少し脱線しますが、今回筆者は作業フェーズを分けてもらうのを大事にしました。
フェーズを分けるメリットとしては互いに情報整理と把握がしやすくなるところです。
フェーズを分けていないと、例えば壁打ちしたくとも情報が埋もれたり、どうしても散らかったりしてしまいます。
この段階で壁打ちしてコード理解やプロジェクト構造理解をしっかり深められないと、次フェーズのタスク実施の判断もしづらくなるのでフェーズを分けていることで安心して壁打ち及び次のタスク実施をお願いできました。
とはいえ、この壁打ちのせいで無料枠を使い切ってしまい、途中でブラウザ版のClaudeに頼ることにもなりました。
途中で使用ツールが変わったものの、ClaudeにもGitHub Copilotに渡した情報を提供し、先のプロンプトでお願いしました。
ClaudeにはさらにGitHub Copilotの生成物（提示してくれた原因と対策、タスク割り、必要ファイルの情報）も渡していたのでスムーズな作業以降とレガシーコードの改修作業が行えました。
サイトは3日ほど落ちていましたが、改修対応にかかった時間で言えば3〜4時間ほどです（そのうちコード改修に至っては30分〜1時間半程度）。
今回のAI協業で得た学びのまとめ
今回のレガシーコード（プロジェクト）の対応や改修作業を通じて筆者が感じた学びを箇条書きにします。
- 情報・状況把握して、それらをAIに投げて壁打ちしながら仮説出し及びコード改修を進める
- AIと協業することで言語やフレームワークをはじめ、プロジェクトの構造理解も捗るので作業効率が良い
- GitHub Copilotの場合： タスク選定からフェーズ構築をはじめ、壁打ち時は
Askモードで進めてAIの自律行動を抑制し、実際の作業開始時にAgentモードに切り替える - AI自身に対応箇所（タスク）を選定してもらい、作業フェーズも構築してもらう
- フェーズを分けていないと壁打ちを続ける内に情報が埋もれたり、どうしても散らかったりしてしまうが、分けておくことで互いに情報整理と把握がしやすくなる
- タスク実行前のフェーズで壁打ちして、コード理解やプロジェクト構造理解をしっかり深められないと次のタスク実施の判断もしづらくなる
- 汎用的なプロンプトの「制約」部分
- まずはプロジェクトの全体像を把握して、どんなサイト・サービスかを言語化して
- ステップバイステップで作業フェーズを考えて、フェーズごとのタスクを想定および選定して
- フェーズが変わるタイミングやタスク実施時は随時確認して
- 不明点や疑問点があれば作業を止めて聞いて
最後に
正直書いていて恥ずかしい部分も多く、内容的にもやらかしカレンダーの方が合っている気がして、そちらに掲載しようか迷いました。
実際、AIがなければ上長判断の「当該サイトのみ別ドメインを取得してPHP7系で運用する」という現実的だが良くない選択になっていたと思います。
これだけ短期間で対応できたのはAIの力はもちろんですが、それを十分に発揮するには「情報・状況把握して、それらをAIに投げて壁打ちしながら仮説出し及びコード改修を進める」ことが大事だと強く実感しました。
こうした体験を経て、レガシーコード（プロジェクト）の対応や改修作業はAIと協業することで言語やフレームワークをはじめ、プロジェクトの構造理解も捗るので作業効率が良いと感じました。
このような実感もあって当カレンダーに載せることにした次第です。
本記事が少しでもお役に立てれば幸いです。
ここまで読んでいただき、ありがとうございました。