執筆：lab.ryukyu 編集部（監修：今ちゃん × ジェミ先生）
0. はじめに：なぜ「教科書通り」にいかないのか？
ITを学ぶ学生の皆さんは、講義で「SSLの設定方法」や「データベースの操作」を習うでしょう。しかし、現場で起きるトラブルは、それらが複雑に絡み合った「複合災害」としてやってきます。
本日、私たちのラボが直面した2つのWebサイト（WordPressとJoomla 6）の崩壊と復活の記録は、技術的な解決策だけでなく、**「AIという強力な助手を、人間がいかに制御し、判断を下すべきか」**という、これからのエンジニアに必須の態度を示しています。
1. 【第一戦】ima.okinawa：無限ループの迷宮とSiteGuardの牙
1.1 発生した事象：ERR_TOO_MANY_REDIRECTS
WordPressサイト ima.okinawa で、ロゴの微調整とSSL設定を行っていた際、突如としてサイトが閲覧不能になりました。ブラウザには「リダイレクトが多すぎます」という非情なメッセージ。
1.2 構造的な原因の特定
調査の結果、以下の「矛盾した命令」がループを生んでいることが判明しました。
この「Aへ行け」「いやBへ戻れ」という無限のキャッチボールが、サイトを麻痺させていたのです。
1.3 泥沼のトラブルシューティング
ここからが現場のリアルです。解決のために wp-config.php を編集した際、PHPの構文エラー（不要な閉じカッコ }）が混入し、サイトは Parse error（真っ白な画面）に。さらに、セキュリティプラグイン SiteGuard が、この混乱を「外部からの攻撃」と見なし、管理画面のURLを404エラーで封鎖してしまいました。
1.4 解決のタクティクス
AI（ジェミ先生）のアドバイスを受け、以下の手順で「隔離と復旧」を行いました。
-
物理的なプラグイン停止： ファイルマネージャーから plugins フォルダをリネームし、SiteGuardの「防御」を強制解除。
-
設定のハードコード： wp-config.php 内に直接、正しい wwwあり のURLを書き込み、DBの設定を上書き。
-
パーマリンクのフラッシュ： 管理画面復帰後、パーマリンク設定を保存し直すことで、サーバー上の道路標識（.htaccess）を最新の状態へ更新。
【学び】 サーバーの設定とアプリの設定が「1文字（wwwの有無）」でも食い違うと、システムは即座に崩壊する。
2. 【第二戦】lab.ryukyu：Joomla 6の鉄壁とWAFの誤認
2.1 発生した事象：管理者締め出し（Lockout）
ima.okinawaを救出した直後、本拠地 lab.ryukyu（Joomla 6）で管理画面のログイン情報を紛失するという、ある種の「ヒューマンエラー」が発生しました。
2.2 データベースへの直接介入（SQL Injection for Good）
Joomlaの管理画面に入れない以上、残された道はデータベースの直接操作のみ。phpMyAdminを使い、以下の高度な操作を試みました。
-
テーブルプレフィックスの特定： Joomlaはセキュリティのため、テーブル名にランダムな文字列（u01234_ など）を付けます。この「本名」を特定しなければSQLは通りません。
-
パスワードハッシュの互換性： Joomla 6が使用する最新の暗号化（Bcrypt）では、手動生成した文字列が拒絶されるケースがあります。ここで敢えて「MD5」という旧世代の技術を使い、ログイン時に自動アップデートさせるという「ダウングレード戦略」を採りました。
2.3 最後の壁：WAF（403 Forbidden）
パスワードをリセットし、いざ新パスワードを保存しようとした瞬間、サーバー（ヘテムル）が「403 Forbidden」を返しました。 これは、サーバーの防御壁（WAF）が「パスワードを書き換えようとする管理者」を「攻撃者」と誤認（False Positive）したためです。
2.4 解決のタクティクス
-
WAFの一時解除： ヘテムルのパネルで一時的にWAFをOFFにし、システムの「喉元」を緩める。
-
セッションの物理削除： _session テーブルを空（TRUNCATE）にし、失敗したログインの記憶を完全に消去。
-
シークレットモード： ブラウザに残ったCookieの影響を排除するため、まっさらな環境でログイン。
【学び】 セキュリティは「固める」だけでなく、管理者が「通れる」道も確保しなければならない（可用性の確保）。
3. 【特別講義】AIとの協働における「アキシム（公理）」の重要性
今回の救出劇で最も重要なのは、技術的な手順そのものではなく、**「人間とAIの役割分担」**にあります。
3.1 AIの「局所的な猛進」を理解する
AIは、提示された一つのエラーに対して、驚異的なスピードで解決策を提示します。しかし、AIはその問題を取り巻く「全容（サーバーの仕様、ユーザーの心理、前後の文脈）」を完全には感知していません。 AIの指示を盲信すると、一つのエラーを直すために別のエラーを生む「解決のループ」に陥ることがあります。
3.2 プロンプター（人間）の責任と分析
今回の成功は、今ちゃん先生が以下の「アキシム（公理・原則）」を保持していたからこそ成し遂げられました。
-
全容の分析： AIが出した答えをそのまま実行せず、「今のサーバー環境（ヘテムルか、お名前か）」に照らして判断した。
-
責任の所在： 最後に実行ボタンを押すのはAIではなく自分である、という「実行責任」を自覚していた。
-
問い続ける粘り強さ： AIが的外れな回答をしたとき、それを「使えない」と切り捨てるのではなく、より深い情報を与えて「正解」へ誘導し続けた。
AIは「点」を打つのが得意ですが、その点と点を結んで「線（解決のストーリー）」にするのは、今でも人間の役割なのです。
4. むすびに：未来のエンジニアへ
Web開発の世界では、明日にはまた新しいエラーが生まれます。Joomlaが7になり、WordPressが10になっても、この「技術の根源」と「人間と道具の付き合い方」は変わりません。
今回学んだ以下の3つのキーワードを、ノートの隅に留めておいてください。
-
Consistency（一貫性）： サーバーとアプリの設定を疑え。
-
Availability（可用性）： セキュリティで自分を縛りすぎるな。
-
Context Management（文脈管理）： AIに全体像を教え、最終判断は自分で下せ。
トラブルが起きたとき、パニックになるのはエンジニアとして正常な反応です。しかし、そこから一歩踏み出し、AIという鏡を使って自分の思考を整理し、データベースという「真実」にアクセスすれば、必ず道は開けます。
今ちゃん先生とジェミ先生が今日証明したように。
続きを読む：🚀 実践・Webサイト救出戦記：AIと人間が「真実」を奪還した12時間
