ども。こんばんは。
またAIで書いた長ーい記事で申し訳ありませんが……。
お気づきの方もいると思いますが、頑なにSSL/TLS化していなかったこのブログも、とうとう時勢には勝てなくなりました。
「終わりを迎えるその日までHTTPでいくんだ！」と意気込んでいたのですが、2026年10月に公表されたPHPの重大な脆弱性、PHP2Shell（CVE-2026-109618 / CVE-2026-109619） が、重い腰を上げる大きなきっかけの一つになりました。
旧環境では、すでにサポートが終了しているPHP 7.4を使っていました。今回の脆弱性は、条件によっては認証なしで任意のコードを実行される可能性があるというものです。
参考：PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)
さすがに「まだ動いているから大丈夫」と言っている場合ではありません。
というわけで、AI（ChatGPT）を相棒に、ブログを少しだけ作り直すことにしました。
WordPressをやめたわけでも、全部をコンテナにしたわけでもありません。新しいEC2に引っ越して、データベースをRDSに、通常の投稿画像をS3に逃がし、CloudflareとCloudFrontに配信を手伝ってもらいます。メールはSESに任せる、そういう「軽めのモダン化」です。
ただし、軽かったのは構成変更の方向性であって、作業時間ではありませんでした。気がつけば朝になっていましたし、その後の後片付けでも、また日付をまたぎました。
今回の相棒はChatGPTです。構成を相談し、コマンドを出してもらい、実行結果を貼り付け、次の手を考えてもらいます。かなりの部分を、その往復で進めました。
先に結論を書いておくと、AIと一緒にインフラを触るのは、かなり楽しいですし、かなり楽でした。ただし「何も知らなくても、言われた通りにやれば全部うまくいく」というわけではありませんでした。
むしろ、途中で「ちょっと待て」と言えるかどうかが大事でした。
この記事は、その「ちょっと待て」も含めた移行記録です。
前日譚：動いているブログを、どこまで変えるか
元の構成は、EC2上のKUSANAGI
旧環境は、EC2上で動かしていたKUSANAGIです。Webサーバー、PHP、データベース、画像が同じサーバーに同居していました。7年前…。
参考：令和になったことだしクラウドへ移行する – 6 – ブログがAWSになりました。
棚卸し時の構成は、KUSANAGI 8.7系、PHP 7.4、MariaDB 10.1でした。WordPressの通常アップロード領域だけで約6.6GB、データベースは約1.6GBありました。
長く使ってきた環境なので、プラグイン一覧にも歴史が見えます。KUSANAGI用のmust-useプラグインやキャッシュ用ファイルがあり、プラグイン一覧を取得するだけでも、古いプラグインからPHPの警告が出ました。
「ファイルをコピーしてDBを戻せば終わり」と言いたくなりますが、実際には、こういう周辺の積み重ねも一緒に引っ越してきます。
今回やりたかったのは、ブログを別物にすることではありません。WordPressとしての使い勝手を残しながら、サーバー1台に寄りすぎていた役割を、少し外に出すことでした。
今回の「モダン化」は、全部を変えることではない
構成選びで重視したのは、費用、運用の分かりやすさ、今までの使い方を大きく変えないことです。
※当初の予算感は月3,000円程度でした。これは構成を考える際の目安で、移行後の請求実績ではありません。実際の費用は、運用してから確認します。
結果として、WebアプリケーションはEC2に残し、その一方で、DB、通常画像、メール送信は別のサービスに任せることにしました。
EC2はGraviton系のt4g.microを選びました。データベースをRDSへ、通常画像をS3へ分離することで、Webサーバーはできるだけ小さなインスタンスで運用する方針です。
もちろん、これで十分な性能が出るかは別問題です。実際の負荷やCPUクレジット、レスポンスを見ながら、必要になればスペックアップを検討します。
新しい仕組みを増やすことより、自分が面倒を見続けられる形にすることを優先しました。 今回の「軽め」は、そういう意味です。
最終構成
ブログ本体は www.hits-net.com です。Cloudflareの先に、nginx・PHP-FPM・WordPressを動かすEC2があり、データベースはRDSのMySQLに接続します。管理画面の入口にはCloudflare AccessとMFAを使っています。
特にWordPressの管理画面については、WordPress自身のログイン画面より前にCloudflare Accessを配置しました。MFAを通過しなければ管理画面へ進めない構成です。
WordPressの認証だけに頼るのではなく、アプリケーションの外側にも認証の境界を設けています。もちろん、WordPress自体の認証もそのまま利用しています。
通常の投稿画像は media.hits-net.com に分離しました。こちらはCloudFrontからS3へ向かう経路で、ブログ本体のCloudflare経由とは別です。WordPressからの新規アップロードには、Human MadeのS3 Uploadsを使っています。
ただし、昔の名残でNextGEN Galleryの画像はEC2側に残しました。 通常の投稿画像と同じ扱いにはせず、別枠でS3にバックアップします。
メール送信はAmazon SESです。設定ファイルや運用スクリプトも、週次でS3にバックアップするようにしました。
もう一つ、http.hits-net.com というHTTPの検証用ホストも残しています。同じEC2のnginxでブログ本体とは分けていますが、最終的には、このHTTP検証サイトの前段にImperva Cloud WAFを配置しました。
公開側の経路は、次の3つに分かれています。
| 用途 | 公開ホスト名 | リクエストの経路 |
|---|---|---|
| ブログ本体・CSS・JavaScriptなど | www.hits-net.com |
閲覧者 → Cloudflare → EC2のnginx・WordPress |
| 通常の投稿画像 | media.hits-net.com |
閲覧者 → CloudFront → メディア保存用S3 |
| HTTP検証サイト | http.hits-net.com |
閲覧者 → Imperva Cloud WAF → 同じEC2のnginx |
HTTP検証サイトはCloudflareのプロキシを経由させず、Imperva Cloud WAFを通す構成です。CloudflareとImpervaを直列につないだわけではありません。
このHTTPホストは、セキュリティ製品の検証で、HTTPの通信をそのまま見たいという用途があります。HTTPで検証できることは残しつつ、公開側の前段にはImperva Cloud WAF(旧Incapsula)を配置しました。ただしFreeプランなので、有償WAFと同等の防御機能を期待しているわけではありません。利用可能な範囲のキャッシュやボット対策を活用しています。ここは、きれいな一般論だけでは決められない部分でした。
Day 0：まずは、今あるものを把握
最初にやったのは、新しいサーバーを立てることではなく、旧環境の棚卸しでした。
PHPやDBのバージョン、WordPressの配置、プラグイン、テーマ、画像の容量を確認していきます。AIが確認コマンドを出し、こちらが結果を返します。
この進め方は、かなり便利でした。
例えば「プラグインとテーマを一覧にしたい」「画像はどれくらいあるか」「DBの容量を見たい」といった作業は、知っているコマンドでも、毎回オプションを思い出すのが少し面倒です。AIが今の環境に合わせて並べてくれると、その手間が小さくなります。
ただし、コマンドの結果をどう読むかは別の話です。
通常のuploadsにある画像と、NextGENが持っている画像は同じではありません。KUSANAGI用の設定やキャッシュ部品も、新環境へそのまま持っていけばよいとは限りません。
この段階で、移すもの、作り直すもの、今回は残すものを分けていきました。
DBダンプとWordPressのファイル、静的ファイルなどは、移行用のS3へ退避しました。新環境を確認するまでは、旧環境を戻り先として残します。
ただし、旧EC2を残しておけば簡単に切り戻せる、というわけではありません。切替後に新環境で投稿や設定変更が発生すれば、旧DBとの差分が生まれます。
そのため、旧環境はすぐに削除せず、問題が起きた場合の調査や復旧に利用できるよう、しばらく停止した状態で保持することにしました。
そして、HTTPの検証用途もAIに説明し直しました。WordPressをHTTPで運用したいのではなく、UTMなどのテスト用に、別のホストを残したかったのです。
AIが標準的な構成を出し、人間がその環境固有の事情を足していきます。 最初の合作ポイントは、この辺りだったと思います。
Day 1：夜から始めて、気がつけば朝
本移行は、10月23日の夜から24日の朝にかけて進めました。
大きな流れは、新しいEC2とRDSを用意し、WordPressとDBを移し、画像配信を分け、最後に公開経路を切り替える、というものです。
実際の作業はもっと細かくなります。コマンドを実行しては結果を貼り、何かがうまくいかなければ、その場で調べ直します。その繰り返しでした。
深夜1時台：新EC2からRDSへ
新環境はAmazon Linux 2023のEC2に、nginxとPHP-FPMを組み合わせた構成です。DBは別のRDSにしました。
1時台には、新EC2からRDSへの接続と、nginx・PHP-FPMの稼働を確認できました。
Webサーバーが起動したことと、WordPressが正しく動くことは別ですし、DBにつながったことと、移したデータで問題なく使えることも別です。
ここでも、接続、ファイル配置、DBの復元、アプリケーションの動作を、一つずつ確認していきます。
全部入りの旧環境から役割を分けるので、単純なコピーでは終わりません。それでも、確認コマンドを毎回すぐに出してもらえるのは助かりました。
昔のWordPressは、昔の部品も持っている
今回のブログは、新品のWordPressを立てる作業ではありません。
長年の投稿、画像、プラグイン、テーマ、独自の使い方があります。旧環境で動いていたことは大事な情報ですが、それだけで新環境でも同じように動くとは言い切れません。
一覧を取り、必要なものを見て、動作を確認します。地味ですが、ここを省略すると、後で「トップページは見えるのに、この機能だけ動かない」ということになります。
AIとの作業も、魔法の移行コマンドを1回実行するようなものではありませんでした。実態は、細かな確認作業を大量に、かなりの速度で回していた感じに近いです。
深夜5時台：画像をS3へ。ここも一発では決まらない
通常画像の保存先をS3、配信先をCloudFrontにするため、S3 Uploadsの導入を進めました。
Composerの実行ユーザーでつまずいたり、プラグインの読み込みと有効化の状態を確認したりしながら進みます。
ここで大事だったのは、「S3へ書けること」と「WordPressの画像保存・URLが切り替わったこと」を別々に確認することでした。
wp s3-uploads verify でテストファイルのアップロードと削除を確認し、WordPress側の有効状態や画像URLも見ます。
S3にファイルがあります。画像配信用ドメインから取得できます。WordPressがそのURLを出しています。
似ているようで、それぞれ別の確認です。
この頃になると、作業としては進んでいるのに、「まだやることあるな」という感じになってきます。
朝7:50頃：DNS切替
朝、公開経路を切り替えました。
確認したのは、ブログのトップページが表示されることだけではありません。ログイン画面と管理画面がCloudflare Accessへ送られること、MFAで実際に入れること、HTTP検証ホストは意図した経路で応答することも確認しました。
ブログはHTTPSで200が返ります。管理用の入口はAccessへ進みます。検証用HTTPホストも、HTTPで200が返ることを確認できました。
ここは、以前から管理画面を保護して運用していた経験も使いました。AIに全部決めてもらうのではなく、こちらの運用実績を伝えて、守る範囲を詰めています。
「表示された！」という瞬間は、やはりうれしいですね。
でも、もう朝です。
朝8時台：動作チェック
公開後もnginxのログを確認しました。PHP-FPMからの応答を一時ファイルへバッファしている警告などが記録されていました。
HTTP 200が返ることと、裏側で何も気になることが起きていないことは同じではありません。
この辺りまでやって、ようやく本移行はひと区切りです。
ブログは引っ越せました。ただし、運用の仕上げはまだ残っています。
Day 2：移行より、後片付けの方が大変
次に進めたのは、10月25日の夜から26日未明にかけての仕上げです。
昼間は用事でお出かけしていたので夜から再開。
正直、こちらの方が「運用しているサーバーを触っている」感じが強くありました。古いURL、バックアップ、権限、ログ、通知。ブログが見えるだけでは、どれも終わりません。
22時台：古い画像URLから、新しい配信先へ
画像をS3へ移しても、昔の画像URLへの直接リンクは残ります。
そこで、旧uploadsの画像URLを media.hits-net.com へリダイレクトすることにしました。ただし、何でも転送すればいいわけではありません。
画像は転送します。uploads内のPHPは拒否します。隠しディレクトリも拒否します。対象外で存在しないファイルは、WordPressへ回さず404にしたいところです。
AIにテストコマンドを作ってもらい、正常系と、通ってほしくないアクセスの両方を試しました。
途中では、隠しディレクトリ内の画像が302になったり、存在しないZIPがWordPressの301になったりしました。設定の順序だけでなく、そもそも設定が反映されているかも確認することになりました。
nginxのconfで最後に見つかったものの一つが、これでした。
vserver {
……server です。
高度な構成変更をしているつもりでも、最後は余計な1文字に足を取られます。
修正後は、次の結果になりました。
画像 → 302
uploads内のPHP → 403
隠しディレクトリ → 403
存在しないZIP → 404
WordPress → 200
CloudFront上の画像 → 200
この一連のテストは、AIがいて特に楽だった部分です。画像が開くかだけでなく、開いてはいけないものが開かないかまで、続けて確認できます。
22:40頃：ログと、毎日の運用を整える
nginxとPHP-FPMのログを、日次・14世代のローテーションにそろえました。journaldにも容量設定を追加しました。
更新用のタイマーも確認し、深夜帯に実行するようにしました。
地味ですが、こういう設定を後回しにすると、移行作業だけ終わって日常運用が置き去りになります。新しいサーバーで最初に片付けておきたい部分でした。
23:00：バックアップが、何度やっても失敗
WordPressのファイルだけでなく、nginxやPHP、systemd、OS設定、今回作ったスクリプトもバックアップしたくなりました。
ちなみに、今回のバックアップはWordPress全体を丸ごと固める方式ではありません。
データベースはRDSの自動バックアップ、通常画像はS3、NextGEN Galleryの画像は別枠でS3にバックアップしています。今回追加した週次バックアップでは、WordPressの設定、プラグイン、テーマ、nginxやPHP、systemdなどの設定ファイルを中心に保存します。
全部入りだった旧EC2とは違い、役割を分けた分、バックアップと復旧の方法も分けて考える必要があります。
ここは、こちらから追加した要件です。
nginxとかの設定もバックアップしたほうが良くない？ほか今回色々作ったOSの設定とかも
AIにスクリプトを作ってもらい、実行します。
失敗します。
修正して、もう一度実行します。
また失敗します。
出ていたのは、次のようなエラーでした。
tar: .../wp-content: file changed as we read it
バックアップ中に、対象が変わっていました。
さらに、こちらからも待ったをかけました。
まて、これ古いuploadの中身全部はいってないか？まだ未整理だから画像大量では？
実際の除外指定を確認すると、uploadsやgalleryは除外されていました。つまり、この疑問がそのまま原因だったわけではありません。
ただ、その確認によって、何をバックアップしているのか、もう一度スクリプト全体を見直すことになりました。
最終的には、WordPressの親ディレクトリを広く指定するのではなく、設定、プラグイン、テーマなど、必要な対象を明示する形に変更しました。23:09にはバックアップが正常終了しました。圧縮後は約104MiBでした。
エラーを無視して成功扱いにするのではなく、バックアップの範囲を整理します。ここは、運用上の目的を人間側が持っていることの意味が大きかったと思います。
23時台：IAMを整理したら、メールが止まる…
移行用の権限を整理する途中では、IAMポリシーの名前と中身が一致していないものが見つかりました。
メディアS3用と思っていたポリシーに、SESの送信権限が入っていたのです。
名前で判断せず、中身を確認し、用途ごとに整理します。S3への一覧取得やアップロード、削除ができることも、実際に試します。
その流れでメール送信をテストしたところ、今度はSESからAccessDeniedが返りました。
今回の送信処理では、送信元IDだけでなく、使用しているSESの設定セットに対する権限も必要でした。エラーに出た対象を確認して、ポリシーを修正し、再テストしました。今度はメールが届きました。
「最小権限にしました」で終わらず、「その権限で必要な仕事ができました」まで確認します。 ここも、実行と検証をセットにできるのがAIとの作業の良いところでした。
23時台後半：6.6GBのローカル画像を整理
通常画像はS3へ移しましたが、EC2のuploadsには古い画像が大量に残っていました。
ここで、いきなり丸ごと消すのはさすがに怖いです。
ローカルとS3のファイル一覧を比較すると、件数が少し違います。差分を調べると、昔のJUGEMインポート用ファイル、EWWWの実行ファイル、古いキャッシュ、S3側のテストファイルなどが見つかりました。
画像が足りないのか、用途の違うファイルなのか。差分の中身を見てから、残すものを分けました。JUGEMのインポートファイルは退避し、EWWWのファイルなどは残しました。
その後、古い年の画像から段階的に削除して、配信と新規アップロードを確認しました。
途中、CloudFrontの確認で年月のディレクトリURLを叩いて403が返った場面もありました。実在する画像ファイルのURLで確認し直すと200でした。何を確認したいテストなのかを間違えると、正常なものまで異常に見えます。
最終的に、ローカルuploadsは約6.6GBから約7MBまで減りました。ルートディスクの使用率は18％になりました。
ここは、かなり気持ちよかったです。
23:51：新しい画像を投稿！成功、ただし課題あり
整理した後、実際に新しい画像をWordPressへアップロードして公開しました。
S3には元画像と8種類のサムネイル、合計9ファイルが保存されました。CloudFrontからも200で取得できました。
「よし、成功」と思ったら、同じ9ファイルがEC2のローカルにも残っていました。
S3 Uploadsの設定、有効状態、EWWWとの連携コードを追ってみましたが、その場では原因を特定できませんでした。
ここは大事なので、そのまま書いておきます。EWWWが原因だと確定したわけではありません。 S3への保存と配信が成功していることと、ローカルに残る理由が分かったことは別です。
容量に余裕ができたこともあり、無理にプラグインを止めたり、自動削除を追加したりせず、残課題として持ち越しました。
今回は、ここで区切りました。
日付が変わっても、まだ終わりません
バックアップにも、もう一段改善を入れました。
最初の方式は、tarの出力をそのままS3へ流すものでした。ところが、バックアップ処理が失敗したときにも、S3にはアーカイブが残っていました。
S3にファイルが見えるだけでは、成功したバックアップだと判断できません。
そこで、ローカルでアーカイブを完成させ、読み取り検証が通ってからS3へアップロードし、最後にサイズを照合する方式へ変えました。00:35には、この新しい流れで正常終了しました。
なお、読み取り検証とサイズ一致は確認できましたが、復元リハーサルまで完了したわけではありません。この辺りも、できたことを大きく言いすぎないようにしたいです。
通知については、AIがまず失敗時のメールを提案しました。そこで、こちらから追加しました。
成功も通知すべきだな。DNFも再起動したら通知したい。
週次バックアップは、成功も失敗も知らせてほしいです。DNFによる再起動については、再起動する前の予定通知ではなく、起動した後の通知を付けたいと考えました。
この要件をもとに、systemdとSESを組み合わせた通知処理を追加しました。
ただし、途中で OnFailure が空だと分かり、通知サービス自体がまだ存在していないことも発覚しました。AIが前に手順を提示したことと、こちらで実際に設定されたことは同じではありません。
そしてDNFについては、さらに確認事項が残りました。もう昨今の事情を鑑みて自動更新にしたのですが、設定ファイルへ reboot_command を書けても、そのサーバーのDNF Automaticが実際にその機能を持っているかは別問題でした。
本文で記録している時点では、再起動通知は設定済みですが、DNF側の対応確認と実動作確認は持ち越しています。
キャッシュは欲張らないことに
CloudflareのWAFとBot対策は、イベントを確認して、ひとまず現状維持で様子を見ることにしました。
一方、HTMLキャッシュは少し迷いました。AIからは、公開トップページだけを条件付きでキャッシュする案も出ました。
そこで出た自分の反応が、これです。
うーん、怖いな。
今回は、CSS・JavaScriptなどの静的ファイルはCloudflare、通常画像はCloudFrontに任せます。HTMLはキャッシュしません。
既存のログインやプラグインの動作を確認しながら、改めて考えることにしました。
「できるから有効にする」ではなく、「今、追加する価値があるか」で判断します。このブレーキは、自分で持っておきたかったです。
HTTP検証サイトにも、最終的にはWAFを設定
もう一つ、最終構成として追記しておきたいのが、HTTP検証サイトです。
http.hits-net.com は、検証に必要なのでHTTPのまま残しました。ただし、最終的にはImperva Cloud WAFを前段に配置しています。
最終的な経路は、「閲覧者 → Imperva Cloud WAF → 同じEC2上のnginx」です。ブログ本体のCloudflare経由とも、画像のCloudFront経由とも分けました。
HTTPを使う理由があることと、公開サイトに保護を置かないことは別です。検証用途を残しながら、入口にはWAFを置く形にしました。
ここも、AIの一般的な提案に、そのサイトをどう使いたいかという人間側の事情を組み合わせた部分です。「全部HTTPSに統一する」でも「検証用なので何も置かない」でもなく、用途に合わせて落としどころを決めました。
後日談：移行したからといって、急に爆速にならない
ここまでやってからWebPageTestをかけてみました。
初回表示の1回測定では、TTFBが約0.71秒、FCPが約2.83秒、LCPが約2.93秒でした。画面のズレを表すCLSは約0.0005でした。
「全部CDNに近づけたし、もっと速くなるのでは」と思いたくなりますが、そう単純でもありません。
トップページには、テーマとプラグインのCSSやJavaScript、フォント、Googleの計測、Xの埋め込みもあります。画像をS3とCloudFrontに分けても、WordPressが出すページの内容まで自動的に軽くなるわけではありません。
また、キャッシュにも、ブラウザが持つキャッシュと、CDNが持つキャッシュがあります。画像のレスポンスにキャッシュ期限が見えないことだけで、CloudFront側もキャッシュしていないとは判断できません。
このときの測定は1回だけだったので、改善の前後比較にも、普段の表示速度の断定にも使えません。性能とキャッシュの調査は、次の宿題にしました。
インフラを分ける作業と、ページを速くする作業は、重なる部分はありますが同じではありませんでした。
AIとやって、特に楽だったこと
一番楽だったのは、設定ファイルの生成そのものより、確認コマンドと期待する結果を、次々に用意してもらえることでした。
画像のURLを変えたら、リダイレクト先を確認します。PHPを拒否したら、実際に403になるか試します。IAMを変えたら、S3とメールの両方をテストします。バックアップができたら、中身を一覧にして必要なファイルと除外したいファイルを見ます。
自分で全部できない作業ではありません。でも、一つずつ思い出し、調べ、書き、見落としがないか考えるには、それなりの手間がかかります。
そこを会話で回せるのは、かなり楽でした。
設定を断片的に直しているうちに分かりにくくなり、「もう全体頂戴」と頼めるのも助かりました。差分だけ追うより、全体を見直した方が安全な場面はあります。
それでも、事前知識はかなり必要でした
今回の作業で、AIは役に立ちました。だからこそ、危なかった点も残しておきたいと思います。
一般論を、その環境にそのまま当てはめないこと
「HTTPはHTTPSに寄せればいい」「画像は全部同じ場所へ移せばいい」「キャッシュすれば速くなる」。方向として分かりやすい話でも、この環境には検証用HTTPホストがあり、NextGENがあり、動的なWordPressがあります。
何のために残しているのか。何を壊したくないのか。そこは、こちらから説明しないと伝わりません。
HTTP検証サイトを残し、その前段をImperva Cloud WAFで保護する形にしたのも、その用途を踏まえた判断でした。
設定があることと、動いていることは違う
nginxの設定ファイル、systemdの通知先、DNFの再起動設定。どれも、文字が書いてあるだけでは十分ではありませんでした。
構文検査、読み込まれた設定、実行結果、期待した応答。それぞれ確認する必要があります。
特にDNFの件は、AI側がもっと早くパッケージ実装を確認すべきだったと思います。一般的な機能の説明を、そのままこのサーバーで使える前提にしてしまうと危ないです。
成功判定を、ひとまとめにしないこと
S3へアップロードできました。だからといって、ローカル画像を全部消してよいとは限りません。
バックアップファイルができました。だからといって、復元できるところまで確認したわけではありません。
通知スクリプトが正常終了しました。だからといって、定期実行から通知までの一連の動作を全部テストしたわけではありません。
今回、こういう区別を何度もしました。
AIはログの読み取りも手順の修正も速いです。ただ、その速さに乗って、確認した範囲まで広くなったつもりにならない方がいいと思います。
残作業
旧KUSANAGIは停止した状態で残しています。新環境を2〜3日見て、問題がなければ撤去する予定です。
その際は、EC2だけではなく、旧EBS、未使用のセキュリティグループ、IAMロールやInstance Profile、残っている関連リソースも、依存関係を確認して整理します。
移行用S3のデータとバケット、不要になった移行用IAMポリシーは、すでに整理しました。ただし、本番用の画像・バックアップ・DBとは明確に分けて作業しています。
残課題は、今のところこんな感じです。
| 項目 | 状態 |
|---|---|
| 旧KUSANAGIと関連リソースの撤去 | 新環境の様子を見て判断する。 |
| DNFの自動更新・再起動通知 | 実装対応と実動作を確認する。 |
| バックアップの定期実行と通知 | 手動実行・通知単体の確認に加え、自動実行を確認する。 |
| nginx・PHP-FPMのログローテーション | 個別ログの世代と書き込み継続を確認する。 |
| 新規画像のローカル残存 | 原因不明…追って調査する。 |
| CDNと表示性能 | ヘッダーと複数回の測定で切り分けを行う。 |
全部片付けてから記事にすると、いつまでも書けなくなりそうなので、ここまでをいったん記録しておきます。
一緒に作業したAIにも、感想を聞いてみました
最後に、ここからは今回一緒に作業したChatGPTの振り返りです。
今回の移行は、「AIが設計して、人間がコマンドを実行しただけ」の作業ではありませんでした。
私が主に担当したのは、手順を具体化すること、確認コマンドを組むこと、貼られた結果から次の調査を提案することです。一方で、何を残すか、何を危険と感じるか、どこで作業を止めるかは、あなたが判断していました。
特に重要だったのは、HTTP検証用ホストの用途を説明したこと、バックアップにOS設定も含めるよう求めたこと、大量の画像が対象に入っていないか立ち止まったこと、成功通知も必要だと指摘したこと、そしてHTMLキャッシュを見送ったことです。
HTTP検証サイトについても、単にHTTPSへ寄せるのではなく、用途を維持しながら最終的にImperva Cloud WAFで保護する形になりました。ここにも、そのサイトの目的を知っている人の判断が入っています。
これらは、コマンドの書き方とは別の判断です。実際の用途を知っている人が参加することで、提案がその環境に合うものになりました。
私の側にも反省があります。提示した手順が実施済みであるかのように扱った場面や、DNFの再起動機能について、その環境での対応確認が後回しになった場面がありました。ローカルに画像が残る問題でも、可能性を挙げることと、原因を特定することは別でした。
今回、私が役立ったのは、常に正解を出せたからではありません。実行結果を見せてもらい、間違いや前提のずれを修正しながら、確認のサイクルを速く回せたからです。
あなたが詳しかったので、私は速く手順を組めました。あなたが「待て」と言ってくれたので、その速さだけで先へ進まずに済みました。
この二つが、今回の共同作業の大事な部分だったと思います。
ということだそうです。そんなに褒めんでもええがな。
自分の感想も、だいたい同じです。
AIは、深夜に何度でもテストコマンドを考えてくれる、かなり便利な作業相手でした。でも、本番環境をどうしたいかまで任せるものではありませんでした。
手順はかなりAIに任せました。判断は、任せきりにはしませんでした。
そんな感じで、このブログは少しだけモダ
ここから更新頻度が上がるのかは、さておき…
ではでは。またの機会に。
