New Relic の APM（アプリケーション性能監視）を WordPress で使うには、サーバーに New Relic の PHP エージェントを入れ、ライセンスキーとアプリ名を設定して PHP-FPM を再起動します。数分でリクエストごとの処理時間、遅いデータベースクエリ、外部 API の呼び出し、エラーが New Relic の画面に表示されるようになります。この記事では、導入の前提、インストールと設定、複数サイトの分け方、画面の読み方、個人情報と負荷への配慮、止め方までを説明します。
PHP エージェントの仕組みと前提条件
PHP エージェントは2つの部品で動きます。
- PHP 拡張（newrelic.so）：PHP の処理の中で関数の呼び出し時間やクエリを計測する
- デーモン（newrelic-daemon）：拡張が集めたデータを受け取り、まとめて New Relic に送る
拡張は計測結果をデーモンに渡すだけなので、New Relic との通信が遅くてもページの応答には影響しにくい作りです。WordPress はエージェントが対応しているフレームワークの1つとして自動判別され、WordPress 向けの名前付けや計測が有効になります。
導入には次の条件がそろっている必要があります。
- サーバーに root 権限があること：PHP 拡張のインストールと PHP-FPM の再起動が必要なため、一般的な共有レンタルサーバーでは導入できません。マネージド WordPress ホスティングの中には New Relic との連携を独自に提供しているところもあるので、その場合はホスティング会社の案内に従います。
- New Relic のアカウントとライセンスキー：データ送信用のキー（画面上では「ingest - license」などと表示される種類）を使います。ユーザー用の API キーとは別物です。
- 外部への HTTPS 通信：サーバーから New Relic のデータ受信先へ 443 番で通信できる必要があります。送信先を制限するファイアウォールを使っている場合は、公式ドキュメントのネットワーク要件を確認します。
New Relic には無料で使える範囲がありますが、データ量や利用者数の条件は変更されることがあるため、料金ページで最新の条件を確認してください。また、対応する PHP のバージョンや OS もエージェントの版ごとに変わります（2026年10月現在）。
作業前に、PHP-FPM の設定ディレクトリをバックアップし、可能ならステージング環境で先に試します。
エージェントをインストールする
New Relic の画面にはサーバーの種類を選んでコマンドを生成する導入ガイドがあり、まずはそれに従うのが簡単です。手動で入れる場合は、公式ドキュメントの手順に沿って New Relic のパッケージリポジトリと署名鍵を登録してから、パッケージをインストールします。リポジトリの登録方法は OS の版によって推奨手順が変わるため、古い記事のコマンドをそのまま使わず、公式ドキュメントの最新の手順をコピーしてください。
Debian/Ubuntu の場合、パッケージ名は歴史的な経緯で newrelic-php5 のままですが、PHP 8 系にも対応しています。
sudo apt update
sudo apt install newrelic-php5
# ライセンスキーを画面に表示させず、シェルの履歴にも残さずに渡す
read -rs NR_KEY
sudo NR_INSTALL_SILENT=1 NR_INSTALL_KEY="$NR_KEY" newrelic-install install
unset NR_KEYnewrelic-install は、サーバー上の PHP を探して各 PHP の設定ディレクトリに newrelic.ini を配置します。PHP が複数バージョン入っている場合、意図しない PHP にだけ設定されることがあるので、インストール後に配置先を確認します。
ls /etc/php/*/fpm/conf.d/ | grep -i newrelic
php-fpm8.3 -m | grep -i newrelic # FPM で拡張が読み込まれるかnewrelic.ini を設定する
最低限見直すのは、ライセンスキーとアプリ名です。アプリ名は New Relic の画面上での表示名になり、既定のままだと「PHP Application」のような汎用の名前になって、複数サーバーのデータが混ざります。
; /etc/php/8.3/mods-available/newrelic.ini など（配置先は環境で異なる）
newrelic.enabled = true
newrelic.license = "your-license-key"
newrelic.appname = "example.com (production)"
newrelic.logfile = "/var/log/newrelic/php_agent.log"
newrelic.loglevel = "info"
newrelic.daemon.logfile = "/var/log/newrelic/newrelic-daemon.log"
; SQL 文は値を伏せた形で記録する（既定値）
newrelic.transaction_tracer.record_sql = "obfuscated"sudo chmod 640 /etc/php/8.3/mods-available/newrelic.ini
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpmnewrelic.ini にはライセンスキーが入るため、一般ユーザーが読めない権限にし、Git などで管理する場合はキーを含めないようにします。設定後、サイトのページを何度か開くと、数分で New Relic の APM の一覧にアプリ名が表示されます。
複数サイトをアプリごとに分ける
1台のサーバーで複数の WordPress を動かしている場合、すべてが同じアプリ名に集計されると、どのサイトが遅いのか分かりません。newrelic.appname はサイトごとに上書きできるので、PHP-FPM のプールをサイトごとに分けている場合はプール設定に書きます。
; /etc/php/8.3/fpm/pool.d/site-a.conf
php_value[newrelic.appname] = "site-a.example (production)"Apache の mod_php を使っている場合は、バーチャルホストの設定で php_value newrelic.appname "..." と書く方法もあります。
表示されないときの確認手順
数分待ってもアプリが表示されない場合は、次の順に確認します。
- 拡張が読み込まれているか：
php-fpm8.3 -mにnewrelicが出なければ、newrelic.iniが FPM のconf.dから読まれていません。CLI のphp -mは別の設定を読むので、FPM 側で確かめます。 - デーモンが動いているか：
ps aux | grep newrelic-daemonでプロセスを確認します。既定では、最初のリクエストを受けた PHP がデーモンを起動します。 - ログにエラーが出ていないか：
/var/log/newrelic/のエージェントログとデーモンログを見ます。ライセンスキーの誤りや、データ受信先に接続できないといった原因はここに出ます。 - アクセスがあるか：エージェントはリクエストを処理したときにデータを作るため、アクセスのないステージングでは表示されません。自分でページを開いて確認します。
画面の読み方と WordPress での使い方
データが届いたら、まず APM のトランザクション一覧を「合計の処理時間が長い順」に並べます。1回あたりが遅いページより、そこそこ遅くて回数の多いページのほうが、サーバー全体の負荷への影響が大きいことがよくあるためです。
- トランザクション：WordPress では、読み込まれたテンプレートなどを基準に名前が付きます。管理画面の
admin-ajax.phpやwp-cron.phpが上位に来ていたら、ハートビートや予約処理が負荷の原因になっていないかを疑います。 - データベース：時間のかかっているテーブルや操作の種類が分かります。
wp_optionsの自動読み込みやwp_postmetaを絞り込むクエリが目立つ場合は、プラグインの設定やクエリの書き方を見直します。 - 外部サービス：外部 API の呼び出しにかかった時間です。プラグインのライセンス確認や SNS の埋め込み取得などが応答を遅らせていないかが分かります。
- トランザクショントレース：一定時間を超えた遅いリクエストの、関数単位の内訳です。
WordPress のフックやプラグインごとの処理時間を集計する機能もあり、newrelic.framework.wordpress.hooks という設定で制御されます。既定で有効ですが、集計の細かさに関する追加の設定はエージェントの版によって異なるので、使っている版の newrelic.ini のコメントと公式ドキュメントで確認してください。どのプラグインが重いかの見当を付けたら、ステージングでそのプラグインを止めて差を測り、原因を確かめてから対処します。
個人情報と負荷への配慮
APM は、サイトの訪問者のリクエストを計測する仕組みです。導入にあたって次の点を確認しておきます。
- SQL 文の記録：
record_sqlは既定のobfuscatedのままにし、rawには変更しないことをおすすめします。rawにすると、クエリに含まれるメールアドレスなどの値がそのまま送られます。 - リクエストのパラメーター：URL のクエリやフォームの値は既定では送られませんが、属性の設定で送る対象を増やすと個人情報が含まれることがあります。
- ブラウザ監視：エージェントは既定で、ページに New Relic のブラウザ監視用の JavaScript を自動で挿入できます。訪問者の閲覧情報を外部に送ることになるので、使う場合はプライバシーポリシーに記載し、同意管理の仕組みとの整合を確認します。使わない場合は
newrelic.browser_monitoring.auto_instrument = falseで止められます。
負荷については、エージェントによる処理時間の増加は通常小さいものの、ゼロではありません。導入前後でページの応答時間を比べておくと、影響を把握できます。
一時的に計測を止めたいときは newrelic.enabled = false にして PHP-FPM を再起動します。エージェントを取り除く場合は sudo newrelic-install uninstall を実行してからパッケージを削除し、再度 PHP-FPM を再起動します。
まとめ
- New Relic の PHP エージェントは、PHP 拡張とデーモンで動きます。root 権限のあるサーバーが前提で、WordPress は自動で判別されます。
- リポジトリの登録は公式ドキュメントの最新手順に従い、ライセンスキーは履歴や Git に残さないように扱います。
newrelic.appnameをサイトごとに分けると、どのサイトが遅いのかを区別できます。- トランザクションは合計の処理時間順に見て、データベースや外部サービスの内訳から原因を絞り込みます。
- SQL の記録は伏せ字のまま使い、ブラウザ監視を使うならプライバシーポリシーに反映します。