【第2部】サーバー健康診断。スペックは足りているのに「なんとなく重い」正体をAIで見抜く

「アクセスが増えると、なぜか急に重くなる」 「サーバーが遅い気がするから、とりあえずプランを上げよう」

実はこれ、過去の私がやってしまった失敗です。 以前、運用しているサーバーがなんとなく重いと感じ、調査もせずにCPU/メモリ 1GBのプランから2GBのプランへアップグレードしました。 結果どうなったか？ 毎月の支払額だけが上がり、肝心の表示速度はほとんど変わらなかったのです。本当に後悔しました。

Webサーバーが「重い」原因は、スペック不足だけとは限りません。 むしろ、ボトルネックの正体が「設定ファイル」や「通信経路」にあることのほうが圧倒的に多いのです。

• スペック: メモリの割り当てバランスは適切か？
• 運用: 良かれと思って入れた監視プログラムが負荷になっていないか？
• ネットワーク: 通信経路が遠回りしていないか？

これらが複雑に絡み合っている中で、原因を特定せずに課金するのはギャンブルと同じです。 そこで今回は、サーバーの設定情報や稼働状況を丸ごとAI（Gemini）に渡し、「どこが足を引っ張っているか」を一瞬で特定する**「サーバー完全診断」**の手法をご紹介します。

---

診断準備

AIに的確なアドバイスをもらうコツは、情報を小出しにしないことです。「速度に関わりそうな要素」をまとめて渡すことで、AIは全体を俯瞰して診断できるようになります。

今回は、以下の5つの要素をセットで診断します。

1. 設定（Config）: NginxやApacheの接続数設定など。
2. 資源（Resources）: CPUやメモリの実装量と、空き状況。
3. 運用（Operations）: バックアップや監視などの定期実行タスク。
4. DB（Database）: WordPress等の速度を握るデータベース設定。
5. 通信（Network）: VPC（仮想ネットワーク）などの通信経路。

情報収集

まずは、AIに渡すための「カルテ」を作ります。

以下の表にあるコマンドを実行し、テキストファイルなどにまとめてください。設定ファイルの中身もコピペして準備します。

カテゴリ	対象	実行コマンド・確認ファイル	AIに見せるポイント
Web設定	Nginx/Apache	/etc/nginx/nginx.conf /etc/httpd/conf/httpd.conf	プロセス数、接続制限 リバースプロキシ設定
DB設定	MySQL/MariaDB	/etc/my.cnf	バッファサイズ (innodb_buffer_pool_size)
定期処理	運用タスク	crontab -l	実行頻度、重い処理の タイミング重複
スペック	ハードウェア	lscpu; free -h; df -h	CPUコア数、メモリ容量 ディスクの空き容量

※ コマンド解説:

• lscpu: CPUの性能を表示
• free -h: メモリの使用状況を表示（GB単位など）
• df -h: ディスクの空き容量を表示

---

診断手順

情報を集めたら、Gemini等のAIチャットに投稿します。

今回は、設定ファイルだけでなく「VPCを使っているか」「今のマシンスペックはどうか」という前提条件も伝えるのが成功の鍵です。

プロンプト

以下のテキストをコピーし、（ ）内をご自身の環境に合わせて書き換えて送信してください。

---

改善事例

実際に、私の環境（VPC利用・WordPress運用）でこの診断を行った結果、AIが見つけ出した「遅延の原因」を3つ紹介します。

1. 通信ロス（VPCの罠）

【AIの指摘】

「WordPressの設定でデータベース接続先にグローバルIPが指定されています。VPC内の同一ホストであれば、127.0.0.1 または localhost を指定すべきです。これにより通信のオーバーヘッドを最小化できます。」

【その原因】 wp-config.php の設定時に、うっかり外部からの接続用IPを書いていました。 これにより、**「同じサーバー内にあるDBへの通信なのに、わざわざ一度外に出て戻ってくる」**という無駄な経路が発生し、毎回数ミリ秒のロスが生じていました。修正後、管理画面のキビキビ感が劇的に変わりました。

2. メモリの取り合い

【AIの指摘】

「メモリ8GBの場合、今のApache設定では最大6GB消費してしまいます。DBに回すメモリが足りません。Apacheの接続数を〇〇まで下げ、浮いた分をDBのバッファ（innodb_buffer_pool_size）に回してください。」

【その原因】 Apacheの同時接続数を「多いほうがいいだろう」と安易に増やしすぎていました。 その結果、Webサーバーがメモリを確保しすぎてしまい、DBが使うべきメモリまで圧迫。結果としてDBの動作が遅くなり、サイト全体が重くなっていました。

3. 監視ツールの自爆

【AIの指摘】

「スクリプト内の du / は非常に高負荷です。監視が目的なら、一瞬で終わる df コマンドのみにするか、対象ディレクトリを限定してください。」

【実際の状況】 「ディスクがいっぱいになったら困る」と自作した監視スクリプトの中に、サーバー内の全ファイルサイズを計算する重いコマンド（du）が含まれていました。 これが5分おきに実行されるたび、サーバーのディスク性能が占有され、その瞬間にWebサイトが「プチフリーズ」していたのです。

---

まとめ

「サーバーの高速化」は、何かひとつの設定ファイルを書き換えれば劇的に速くなる魔法ではありません。

OS、Webサーバー、データベース、そしてネットワーク。これら「チーム全員」の連携が取れて初めて、最高のパフォーマンスが発揮されます。

第1部の「セキュリティ診断」と、今回の「パフォーマンス診断」。 この2つの視点でAIによる定期検診を行えば、あなたのサーバーは常に健康的で、本来の性能を発揮し続けられるはずです。ぜひ試してみてください。