最新AIが解き明かす、VtigerCRMのパフォーマンス改善の秘訣

まず、何が遅いのかを測る

「営業担当者が顧客企業の一覧を開き、担当者で絞り込む」「サポート担当者が問い合わせの詳細を開く」のように、一つの操作を決めます。環境のバージョン、データ量、ユーザーの権限、検索条件、時間帯も控えます。例えば、管理者ではすぐ開くのに一般ユーザーで遅いなら、一般ユーザーで再現することが重要です。

1. 操作全体の時間を測る。 クリックから、必要な一覧や詳細が表示されて操作できるまでを記録します。数回の計測では全件の値と中央値を残し、十分な回数を取れる場合は遅い側の目安としてp95（95パーセンタイル）も比較します。
2. DevToolsのNetworkで、画面を待たせている通信を探す。 最初のHTMLに加え、一覧や関連タブのFetch/XHRを確認します。Waiting（TTFB） はネットワークの往復と応答の準備時間を含みます。ここが長ければ、同時刻のサーバー側の計測と照らし合わせます。
3. 通信後も操作できない場合はPerformanceを記録する。 JavaScriptの実行、画面の描画、大きな表の処理を調べます。比較では、同じ画面・権限・表示条件で測り、初回表示と再表示を分けます。

Chrome DevToolsのNetwork機能 ／ Performanceパネルの使い方

VtigerCRMを速くする6つの改善策

1．一覧・検索の対象を絞る

問い合わせが多い環境なら、普段開く一覧を「未完了」「自分の担当」「直近の一定期間」など、業務に必要な範囲に絞ります。全件検索は必要なときに選べるようにします。顧客企業だけを探す場面では、全体検索と顧客企業モジュール内の検索を同じキーワードで比較します。一覧の列数や表示件数、ダッシュボードの集計・ウィジェットも、使うものから見直します。列を減らした際は、SQLや通信量が実際に減ったかを確認します。

OSS 8.4.0の標準一覧では、config.performance.php の LISTVIEW_COMPUTE_PAGE_COUNT は既定で false です。true に変更されている環境では、一覧を開くたびに総件数を計算するコストを確認できます。すでに既定値なら、検索条件やSQL、拡張モジュールの処理に調査を進めます。 VtigerCRM OSS 8.4.0の配布コード

2．遅いSQLと、繰り返し実行されるSQLを見つける

MySQLでは、短い調査時間を決めてスロークエリログを確認します。単発で長いSQLに加え、1回は短くても何度も呼ばれるSQLが、画面全体を遅くすることがあります。利用できる環境では、Performance SchemaでSQLパターン別の実行回数と合計時間も確認します。

問題のSQLを絞り込んだら、MySQLの EXPLAIN で使用インデックス、推定行数、JOIN・並び替えを確認します。既存の索引を調べ、実際のWHERE・JOIN・ORDER BYに合う索引候補だけを検証します。EXPLAIN ANALYZE はSQLを実行するため、負荷を見積もったうえで検証環境の代表的なSELECTに使います。索引追加後は書き込み負荷も測り、絞り込み結果・閲覧範囲・表示順を照合します。 MySQLのスロークエリログ ／ SQLパターン別の集計 ／ EXPLAINの仕様

3．PHPの処理と待ち行列を分けて調べる

Webリクエストを処理するPHPで、OPcacheが有効か、キャッシュのメモリ不足や再起動が起きていないかを確認します。PHP-FPM環境なら、管理者だけが参照できる状態でステータスの待ち行列や max children reached を調べます。遅い処理の調査には、期間を区切ってFPMのスローログも使えます。

待ち行列が増えていても、DBや外部サービスを待つ処理がワーカーを占有している場合があります。ワーカー数の引き上げは、DBの負荷とサーバーの空きメモリも測ってから判断します。 PHP OPcacheの設定 ／ PHP-FPMステータス ／ PHP-FPMの設定

4．配信サイズとブラウザーの処理を減らす

CSS・JavaScript・画像などの公開静的ファイルは、更新時のURL管理に合わせてブラウザーキャッシュを設定します。テキスト系の配信は、サーバーが対応するgzipやBrotliの効果を転送量で確認します。大きな表・グラフや拡張モジュールのJavaScriptが重い場合は、初期表示する要素を減らしたり、必要なタブを開いた時点で読み込んだりします。

ログイン後の画面やユーザー別のAPI応答は、CDN・リバースプロキシの共有キャッシュの対象から外します。公開ファイル向けのルールが顧客データを含む応答にもかからないよう、設定と実際のレスポンスを確認します。 Cache-Controlの仕様 ／ 関連記事　フロントエンドの高速化

5．定期処理と外部連携の実行時刻を確認する

昼前だけ遅いなら、CRMのスケジューラーとサーバー側のCRONの実行記録を、遅くなった時刻に重ねます。大量取り込み、バックアップ、同期などが同時に走る場合は、業務上の期限を確認して実行時刻をずらすか、処理を分割します。通知や連携が必要なタイミングまでに終わること、ジョブが滞留していないことも比較します。

拡張モジュールで保存時に外部APIの応答を待っている場合は、まず連携先とVtigerCRM側の所要時間を分けて計測します。業務上その場で結果が不要な連携なら、バックグラウンド化も候補です。再試行による二重登録を防ぎ、失敗時の通知や処理状況を確認できる設計にします。 関連記事　CRONとスケジューラー

6．負荷が集中している資源に投資する

全体が重い時間帯に、CPU使用率、空きメモリとスワップ、ディスクI/Oの待ち、DBのロックを確認します。例えば、DBの読み取りでディスク待ちが続く場合は、I/O性能やInnoDBのバッファプールを調べます。PHPとDBが同居するサーバーでは、双方のピーク時のメモリを踏まえて調整します。DBのロックや外部API待ちが原因なら、先に処理の重なりや待機の原因を調べます。 MySQLのInnoDBディスクI/Oの解説

最新AIに渡す情報と、そのまま使える依頼文

AIには、画面全体の時間、長い通信、同時刻のサーバー計測を一緒に渡します。SQLは値を伏せた形と実行計画の要約にします。顧客名・メールアドレス・検索語・認証情報は取り除きます。Chromeのサニタイズ済みHARでもURLや本文にデータが残り得るため、社外のAIに渡す場合は、必要な時間や件数だけを抜き出した表が扱いやすくなります。 Chrome DevToolsのHAR出力

VtigerCRM OSSの遅延を調べています。以下の観測値だけを根拠に分析してください。

環境
VtigerCRMの版／PHPと実行方式／DBの種類と版／拡張の有無
対象操作
画面・操作／利用者のロール／絞り込み・並び順／発生時刻
測定値
画面が使えるまでの時間、測定回数と中央値（可能ならp95）
画面を待たせている通信のTTFB、転送量、ブラウザーの処理時間
同時刻のCPU・メモリ・I/O・PHP待ち行列・定期処理の記録
関連するSQLの実行回数・時間・伏せ字にした実行計画

回答してほしいこと
1. 観測できた事実と、原因の仮説を分けてください。
2. 有力な原因を3つまで、根拠と反証に必要な追加計測付きで示してください。
3. 最初に試す変更を1つ選び、検証環境での手順、判定基準、戻し方を示してください。
4. 未確認のVtigerCRM設定やSQLは、適用手順として断定しないでください。
   閲覧権限と業務上必要なデータを保ったまま検証する前提です。

例えばAIが「インデックス不足」を挙げても、実行計画で使用中の索引と処理行数を確認するまでは仮説です。判断材料が足りないときは、設定を変更する前に追加計測へ戻ります。

検証例　問い合わせ一覧の遅さを切り分ける

以下は手順を説明するための仮想例です。一般ユーザーで「担当者の未完了問い合わせ」を開くと遅く、画面を待たせている一覧取得の通信はTTFBが長い一方、通信後のブラウザー処理は短いとします。同時刻のSQLの計測で、並び替えを含む一覧取得が時間の大半を占めていることを確認します。

検証環境で実行計画を見て、既存の索引と重ならない候補を一つだけ試します。比較のため、同じデータ量・ロール・フィルター・並び順で、キャッシュが温まった状態を前後50回ずつ測ります。

速くなったら、担当者・管理者など複数のロールで一覧、検索結果、ページ送り、登録・更新を確認します。さらに同時利用が多い条件で効果を測ります。問題があれば、検証済みの手順で変更を戻し、次の仮説を試します。本番に反映する場合は、作業時間、バックアップと復元、戻す条件を先に決めます。 関連記事　DB・添付・設定のバックアップと復元