Abilities APIとAI Clientの登場により、WordPressは単なるコンテンツ管理システム(CMS)から、さまざまなアプリケーションと任意のAIモデルを連携させ、処理を実行できるプラットフォームへと進化しました。

これは、WordPressのあり方を根本から変える大きな進歩と言えます。しかしその一方で、WordPressを取り巻く環境はますます複雑化しており、サイトを適切に管理するには、処理の実行状況を把握し、パフォーマンスを監視することがこれまで以上に重要です。

今回は、AIによるアクセスが増える中で、サイトの動作を監視する重要性を説明するだけでなく、こうした新しいAI機能がサイトのリソースに実際にどのような影響を与えるのか、具体的なデータを使って検証します。

検証には、MyKinstaで利用できる2つのツール、アプリケーションパフォーマンス監視ツールの「Kinsta APM」とサーバーのアクセスログを使用します。どちらの機能も、Kinstaではすべてのプランで標準提供されています。

それでは早速、AIがWordPressサイトにどれほどの負荷をかけているのかを見ていきましょう。

WordPressサイトでAIによる処理の負荷を監視する方法

WordPressサイトは、さまざまな形でAIとやり取りしています。AIボットやクローラーによる巡回をはじめ、AI Clientを通じてプラグインが内部で実行する処理や、外部アプリケーションやAIエージェントがAbilities APIを介してサイトに送信するリクエストなどがあります。

例えば、AIによる画像生成や音声の文字起こしには、数秒以上かかることも珍しくありません。こうした処理の実行中は、PHPスレッドが占有され、人間のユーザーやボットなどからの他のリクエストを処理できなくなります。

すべてのサイトで問題になるわけではありませんが、アクセス数の多い企業サイトや、数百〜数千点の商品を扱うECサイトでは、こうした処理による負荷を注意深く監視することが重要です。

アプリケーションパフォーマンス監視(APM)ツールを使用すると、AIによる処理がWordPressサイトのパフォーマンスに与える影響を正確に測定できます。

例えば、New Relicのようなツールを使えば、WordPressのトランザクション、フック、プラグイン、テーマ、データベースクエリ、外部リクエストなどを監視し、パフォーマンスの問題がどこで発生しているのかを特定できます。

Kinstaをご利用の場合は、MyKinstaからアプリケーションパフォーマンス監視(APM)ツールをご利用いただけます。

MyKinstaでKinsta APMツールを利用
MyKinstaでKinsta APMツールを利用

Kinsta APMを有効にするには、「サイト」>(サイト名)>「APM」に移動し、「APMを有効化」をクリックします。希望する間隔を選択し、ツールにサイトのアクティビティを記録させます。

監視が完了すると、結果ページへのリンクを記載したメールが自動送信されます。結果ページでは、トランザクション、プラグイン、テーマ、フック、処理に時間がかかっているデータベースクエリ、外部リクエストなどに関する詳細なグラフを確認できます。

Kinsta APMの「最も遅い外部リクエスト」タブ
Kinsta APMの「最も遅い外部リクエスト」タブ

アクセスログやエラーログも、サーバーの内部で何が起きているのかを把握するための貴重な情報源です。通常、サーバーログはサーバーサービスのコントロールパネルから確認するか、FTPやSSHを使用してサーバーのファイルシステムから取得できます。

これらのログには、エラーの原因調査やパフォーマンスのボトルネックの特定、主なアクセス元の把握に役立つ詳細な情報が記録されています。

Kinstaでは、SFTPまたはSSHを使用してサーバーから直接ログファイルをダウンロードできるほか、MyKinstaのファイルマネージャーからも取得できます。また、MyKinstaの「ログ」画面では、エラーログ、キャッシュログ、アクセスログを直接確認することも可能です。

MyKinstaログビューアのaccess.logファイル
MyKinstaログビューアのaccess.logファイル

以下では、実際のAI処理を例に、サイトでのAI利用がパフォーマンスに与える影響を測定する方法を見ていきます。また、AIを活用するうえで、十分な性能を備えたサーバー環境と適切な監視体制がなぜ重要なのかもご説明します。

具体例として、AIモデルを使ってブログ記事のアイキャッチ画像を生成するケースを取り上げます。

WordPressでAIを使って画像を生成する

今回のテストでは、WordPress.org公式のAIプラグインを使用し、ブログ記事のアイキャッチ画像を生成しました。同じテストを行うには、以下の手順に従ってください。

ステップ 1. WordPress管理画面の「コネクタ」ページでコネクタを設定する

まず、利用するAIプロバイダーのAPIキーを取得します。ここでは取得手順は割愛しますが、詳しくは各プロバイダーの公式ドキュメントをご確認ください。

APIキーを取得したら、WordPress管理画面の「設定」>「コネクタ」に移動します。利用するAIプロバイダーの「有効化」をクリックし、APIキーを入力します。

WordPress管理画面の「コネクタ」ページ
WordPress管理画面の「コネクタ」ページ

ステップ2. WordPress.org公式のAIプラグインをインストールして有効化する

WordPressには、AI機能を利用するためのAPIや基本的な仕組みが用意されていますが、AIによる画像生成機能をサイトに追加するには、これらを活用したプラグインが必要です。今回は、WordPress.orgが提供する公式AIプラグインを使用します。

このプラグインをインストールすると、複数のAI機能が追加されます。追加された機能は、WordPress管理画面の「ツール」>「Abilities Explorer」で確認できます。

WordPress.orgのAIプラグインによって生成された「Abilities Explorer」ページ
WordPress.orgのAIプラグインによって生成された「Abilities Explorer」ページ

登録された機能の中に「Image Generation and Editing(画像の生成と編集)」があります。この機能を使うと、投稿の内容や独自のプロンプトに基づいてアイキャッチ画像を生成できます。メディアライブラリから利用することも可能です。

ステップ3. Kinsta APMを有効にし、MyKinstaでアクセスログを監視する

MyKinstaで「サイト」>(サイト名)>「APM」に移動し、Kinsta APMを有効にします。監視時間を2時間に設定し、「監視を有効にする」をクリックします。

Kinsta APMの監視時間を設定
Kinsta APMの監視時間を設定

Kinsta APMでパフォーマンスを監視しながら、「サイト」>(サイト名)>「ログ」に移動し、「access.log」タブを選択します。設定はデフォルトのままでOKです。

ステップ4. 新規投稿を作成し、AIでアイキャッチ画像を生成する

WordPress管理画面に戻り、新しい投稿を作成します。タイトルと本文を入力したら、画面右側にある「Generate featured image(アイキャッチ画像を生成)」をクリックします。

ブロックエディターでアイキャッチ画像を生成
ブロックエディターでアイキャッチ画像を生成

しばらくすると、投稿設定のサイドバーにAIが生成したアイキャッチ画像が表示されます。

AIによって生成されたアイキャッチ画像
AIによって生成されたアイキャッチ画像

これで、監視対象となるAI処理が完了しました。続いて、取得したデータを詳しく分析していきます。

AIによる画像生成のリソース消費量を測定する

ここからは、WordPress Abilities APIを使用した画像生成リクエストが、サーバーのリソースにどの程度の負荷をかけるのかを測定していきます。テスト結果は、利用するAIプロバイダーのAPI処理時間や応答時間、リクエスト送信時にプラグインが実行する処理などによって大きく変わります。

今回の目的は、AI処理に伴うリソース消費量や実行時間を測定するための手順と方法をご紹介することです。同じ手順を使用すれば、ご自身のステージング環境でも簡単に検証できます。

分析には、サーバー側とブラウザ側の両方のデータを使用します。サーバー側では、Kinsta APMでトランザクションを分析し、MyKinstaのログビューアでHTTPリクエストを確認します。ブラウザ側では、開発者ツールを使って、バックグラウンドでどのような処理が行われているかを調べます。

それでは、実際の測定結果を見ていきましょう。

Kinsta APMでの分析

AIによるアイキャッチ画像の生成が完了したら、数分待ってからMyKinstaの「APM」画面に戻り、各タブのデータを確認します。

「トランザクション」タブには、「合計トランザクション時間」のグラフと「最も遅いトランザクション」の表が表示されます。ここでいうトランザクションとは、WordPressサイトへのリクエストを処理するためにサーバー側で実行される一連の処理を指します(詳しくはドキュメントをご覧ください)。

以下の画像は、2分間のトランザクション時間を示しています。この間、PHPの実行に約27秒、MySQLの処理に271ミリ秒、外部トランザクションに19秒以上かかっていることがわかります。

Kinsta APMの合計トランザクション時間
Kinsta APMの合計トランザクション時間

以下の「最も遅いトランザクション」の表を見ると、/wp-jsonへのリクエストに最も多くの処理時間が費やされていることがわかります。

Kinsta APMで見る最も遅いトランザクション
Kinsta APMで見る最も遅いトランザクション

「WordPress」タブでは、「最も遅いWordPressプラグイン」と「最も遅いWordPressフック」の表を確認できます。予想どおり、最も処理に時間がかかっていたプラグインは「ai-provider-for-google」と「ai」で、この2つが全体の処理時間の約90%を占めていました。

Kinsta APMで見る最も遅いWordPressプラグイン
Kinsta APMで見る最も遅いWordPressプラグイン

「外部」タブには、「最も遅い外部リクエスト」が「合計処理時間」の長い順に表示されます。

Kinsta APMで見る最も遅い外部リクエスト
Kinsta APMで見る最も遅い外部リクエスト

各項目の意味は以下のとおりです。

  • 合計処理時間(%):選択した期間内に、特定のURLへのすべてのリクエストが費やした時間の割合です。個々のトランザクションの処理時間ではなく、同じURLへのすべてのリクエストの処理時間を合算した値です。今回の例では、generativelanguage.googleapis.comへのPOSTリクエストが外部トランザクション全体の95.51%、同じURLへのGETリクエストが3.94%を占めていました。

  • 合計処理時間:選択した期間内に、特定のURLへのリクエストに費やされた時間の合計です。こちらも個々のリクエストではなく、同じURLへのすべてのリクエストの処理時間を合算した値です。今回の例では、generativelanguage.googleapis.comへのPOSTリクエストの合計処理時間は18秒を超えていました。

  • 最大処理時間:選択した期間内で最も処理に時間がかかったトランザクションサンプルの処理時間です。

  • 平均処理時間:選択した期間内のすべてのトランザクションサンプルの平均処理時間です。

  • 1分あたりの実行回数:トランザクションが1分間に実行された平均回数です。

特定のリクエストをクリックすると、「トランザクションの例」のウィンドウが開き、選択したPOSTリクエストが実行された際のサンプルを確認できます。

Kinsta APMで見るトランザクションの例
Kinsta APMで見るトランザクションの例

最も処理時間の長いトランザクションサンプルをクリックすると、「トランザクショントレースのタイムライン」が表示されます。ここでは、特定のトランザクションで実行されたPHP処理、MySQLデータベースへのクエリ、外部サービスへのリクエストなどを、スパンと呼ばれる単位で時系列に確認できます(詳しくはドキュメントをご覧ください)。

トランザクショントレースのタイムライン
トランザクショントレースのタイムライン

タイムライン内のスパンをクリックすると、その処理の詳細と完全なスタックトレースが表示されます。

スタックトレースでは、実行されたPHPコードを、ファイル名や行番号まで詳しく確認できます(詳しくはドキュメントをご覧ください)。

画像生成を実行したトランザクションのスタックトレース全体は、以下のようになります。

トランザクショントレースタイムライン上のスパンの詳細
トランザクショントレースタイムライン上のスパンの詳細

以下、処理の流れを順番に見ていきます。

ステップ1. リクエストの初期化

WordPressがHTTPリクエストを受信すると、wp-blog-header.phpを介してWordPressのコアシステムを起動します。その後、REST APIコントローラー(WP_REST_Server)に処理を引き継ぎ、受信したリクエストを同期的に処理します。

HTTPリクエストの初期化
HTTPリクエストの初期化

ステップ2. アビリティの呼び出し

Generate_Image.phpがWordPress\AI\Abilities\Image名前空間内のgenerate_imageアビリティを呼び出し、投稿用の画像を生成します。

generate_imageアビリティのトリガー
generate_imageアビリティのトリガー

ステップ3. AI Clientへの処理の引き継ぎ

class-wp-ability.phpがコールバックを実行し、WP_AI_Clientモジュールに処理を引き継ぎます。

実行をAIクライアントにルーティング
実行をAIクライアントにルーティング

ステップ4. プロンプトの構築

PromptBuilder.phpがプロンプトを構築し、GoogleTextGenerationModel.phpがその指示をGemini APIに対応したリクエスト形式に変換します。

プロンプトを構築
プロンプトを構築

ステップ5. HTTP通信処理への引き継ぎ

HttpTransporter.phpがWordPress HTTP API(http.php -> WP_Http->request)に処理を引き継ぎます。

HTTPトランスポート層への引き渡し
HTTPトランスポート層への引き渡し

ステップ6. HTTP接続の確立

WP_Httpが同期的なHTTP接続を確立します。Googleからレスポンスが返されるまで、PHPスレッドは占有されたままになります(詳しくはWordPress公式ドキュメントをご覧ください)。

同期接続を開く
同期接続を開く

分析からわかったこと

今回の分析で重要なのは、測定した画像生成処理が、同期的に実行されるブロッキング処理であるという点です。

同じHTTPリクエストの処理中に、WP_REST_ServerからWP_Http->requestへと処理が進みます。そのため、画像の生成と返却が完了するまで、PHPスレッドは待機状態になります。

今回の例では、リクエストを処理するPHPスレッドが8秒以上占有されていました。その間も、空いている別のPHPスレッドで他のリクエストを処理することは可能です。しかし、AIを使った処理が同時に複数実行されると、PHPのメモリプールが不足し、リクエストの待ち時間や応答時間が長くなったり、タイムアウトが発生したりするリスクが高まります(KinstaによるPHPスレッドとメモリ使用量の管理についてはこちらをご覧ください)。

サーバーログの分析

スタックトレースには、特定のリクエストを処理する際に実行されたPHPの関数やメソッド、ファイル、コードの行番号などが順番に記録されます。一方、アクセスログには、Webサーバーレベルで処理されたHTTPリクエストの情報が記録されます。

アクセスログからは、リクエストの送信元(IPアドレスやユーザーエージェント)、リクエスト先(URLやAPIのURL)、レスポンスのステータスコード、リクエスト全体の処理時間などを確認できます。

つまり、ログを分析することで、今回のアイキャッチ画像の生成のようなAIを使った処理が実行されている間、サーバー内部で何が起きているのかを詳しく把握できます。

今回、WordPressは1枚の画像を生成するために、Abilities APIを介して4つのリクエストを順番に実行しました。

以下は、Google APIとの通信を記録したログです。

1. プロンプトの生成

POST "/wp-json/wp-abilities/v1/abilities/ai/image-prompt-generation/run?_locale=user" HTTP/2.0 200
PHP execution time: 5.432s
MyKinstaにおけるプロンプト生成のログ
MyKinstaにおけるプロンプト生成のログ
  • このログからわかること:プラグインがimage-prompt-generationアビリティを使用して投稿の内容をGeminiに送信し、画像生成用の具体的なプロンプト(例:「洗練された近未来的なロボットと握手する人物…」)を生成しています。

  • 応答時間:Google APIとの通信に5.43秒

2. 画像生成

POST "/wp-json/wp-abilities/v1/abilities/ai/image-generation/run?_locale=user" HTTP/2.0 200
PHP execution time: 9.795s
MyKinstaにおける画像生成ログ
MyKinstaにおける画像生成ログ
  • このログからわかること:このログは、Kinsta APMのセクションで分析したトランザクションのサンプルとスタックトレースに直接対応しています。プラグインがimage-generationアビリティを使用し、生成されたプロンプトをGoogleの画像生成モデル(Imagen)に送信しています。

  • PHPの実行時間:画像のバイナリデータ(Base64形式)の受信待ちに9.79秒

3. 代替テキストの生成

POST "/wp-json/wp-abilities/v1/abilities/ai/alt-text-generation/run?_locale=user" HTTP/2.0 200
PHP execution time: 11.305s
代替テキスト生成のログ
代替テキスト生成のログ
  • このログからわかること:画像の生成が完了すると、Abilities APIへの別のリクエストが自動的に送信されます。このリクエストでは、Geminiを呼び出して生成された画像を分析し、その内容を説明する代替テキストを生成します。

  • PHPの実行時間:合計11.30秒

これで画像の生成が完了しました。次は、生成された画像をWordPressのメディアライブラリに登録します。

4. メディアの統合

POST "/wp-json/wp-abilities/v1/abilities/ai/image-import/run?_locale=user" HTTP/2.0 200
PHP execution time: 0.839
MyKinstaにおける画像インポートのログ
MyKinstaにおける画像インポートのログ
  • このログからわかること:WordPressがimage-importアビリティを使用して外部APIから画像ファイルのデータをダウンロードし、メディアライブラリに登録しています。

  • PHPの実行時間:0.839秒

5. 画像のダウンロード

GET "/wp-content/uploads/2026/09/a-person-shaking-hands-with-a-sleek-futuristic-robot-inside-a-glass-dome-1024x559.jpg" HTTP/2.0 200
PHP execution time: 0.000
画像のダウンロードログ
画像のダウンロードログ
  • このログからわかること: ブロックエディターが、インポートされた画像ファイルをuploadsディレクトリから直接取得し、画面に表示しています。画像はWebサーバーから直接配信される静的ファイルであるため、PHPによる処理は発生しません。

  • PHPの実行時間: 0.000秒

アクセスログからわかること

1回の画像生成に伴う各処理の実行時間を合計すると、プロンプトの生成、画像の生成、代替テキストの生成、WordPressへの画像のインポートまで、一連の処理にかかった合計時間を把握できます。

今回の例では、アクセスログから以下の実行時間が確認できました。

  • image-prompt-generation(プロンプトの生成):5.43秒

  • image-generation(画像の生成):9.79秒

  • alt-text-generation(代替テキストの生成):11.30秒

  • image-import(画像のインポート):0.84秒

PHPスレッドの累積処理時間は、合計でなんと約27.36秒に達しました。

この結果から、当初の想定が裏付けられました。リソースに制限のある従来型のサーバー環境では、AIを使用する処理が2〜3件同時に実行されるだけでも、PHPスレッドがすぐに不足し、他のサイト訪問者からのリクエストに数秒間応答できなくなる可能性があります。

MyKinstaの分析画面で確認できるPHPスレッドの上限
MyKinstaの分析画面で確認できるPHPスレッドの上限

サイトに複数のAI機能を導入している場合は、それらの処理を支えるサーバー環境がさらに重要になります。また、Kinsta APMやMyKinstaのアクセスログを活用すれば、AIによる処理がサイトに与える負荷を測定し、パフォーマンスのボトルネックを特定して、適切な最適化を行うことができます。

クライアント側のHTTPリクエストを分析する

Kinsta APMやサーバーのアクセスログを使用すると、AIによる処理がサイトのインフラに与える影響を把握できます。一方、ブラウザの開発者ツールを使えば、クライアント側から一連の処理を詳しく分析できます。

ネットワークリクエストを分析するには、以下の手順に従ってください。

  1. WordPress管理画面を開き、新規投稿を作成します。

  2. F12キーを押すか、右クリックして「検証」を選択し、ブラウザの開発者ツールを開きます。Macの場合は「Cmd + Option + I」でも開くことができます。

  3. 「Network」タブを選択し、「Fetch/XHR」でフィルタリングして、非同期リクエストとREST APIリクエストのみを表示します。

  4. 準備ができたら、ブロックエディターで「Generate featured image」ボタンをクリックします。

「Network」パネルに、Abilities APIの各URLへのリクエストが表示され始めます。Firefoxの開発者ツールでは、処理に時間がかかっているリクエストに亀のアイコンが表示されます。

各リクエストを順番にクリックし、「Request」「Response」「Timings」タブで、それぞれのリクエスト内容、レスポンス、処理時間を確認してください。

1. プロンプトの生成

最初のリクエストでは、Google AI APIを使用してプロンプトを生成します。このリクエストには、投稿のタイトルと本文が含まれます。

プロンプト生成リクエストのペイロード
プロンプト生成リクエストのペイロード

APIからのレスポンスは、画像生成モデルのImagenに送信するプロンプトです。

Google APIのレスポンス
Google APIのレスポンス

次に、「Timings」タブに切り替えて処理時間を確認します。今回の画像生成に使用するプロンプトの作成には、5.52秒かかりました。

プロンプト生成には5.52秒の待ち時間が発生
プロンプト生成には5.52秒の待ち時間が発生

2. 画像生成

続いて、画像生成のリクエストが行われます。リクエストのペイロードは、前のリクエストで受け取ったプロンプトです。

画像生成リクエストで受信したプロンプト
画像生成リクエストで受信したプロンプト

Google APIからのレスポンスは、画像のBase64エンコードされたペイロードとなります。

Google AIから返された画像のBase64形式のデータ
Google AIから返された画像のBase64形式のデータ

[Timings]タブには、画像生成の合計実行時間が表示されます。リクエストの待機時間は9.92秒でした。

画像生成の待機時間は約10秒
画像生成の待機時間は約10秒

3. 代替テキストの生成

3つ目のリクエストでは、Abilities APIからGoogle APIに画像の代替テキストの生成を依頼します。このリクエストには、Base64形式でエンコードされた画像データが含まれます。

Abilities APIによる画像の代替テキスト生成リクエスト
Abilities APIによる画像の代替テキスト生成リクエスト

APIからのレスポンスには、生成された画像の代替テキストが含まれています。

Google APIから返された画像の代替テキスト
Google APIから返された画像の代替テキスト

生成されるテキスト自体は短いものの、画像のデコードとテキストの生成には時間がかかり、7.32秒を要しました。

altテキスト生成の待機時間
altテキスト生成の待機時間

4. 画像のダウンロード

Abilities APIを介した4つ目のリクエストでは、バイナリデータを処理して画像ファイルをダウンロードし、画像の切り抜き版を生成した後、WordPressのメディアライブラリに登録します。この最後のリクエストの待機時間は1.79秒でした。

画像ダウンロードの待機時間
画像ダウンロードの待機時間

それでは、アイキャッチ画像の生成にあたり、Abilities APIを介して実行された4つのリクエストの待機時間を合計してみましょう。

  • プロンプトの生成:5.52秒
  • 画像の生成:9.92秒
  • 代替テキストの生成:7.32秒
  • 画像のダウンロードと登録:1.79秒

合計待機時間は、なんと24.55秒にも達しました。

AIがサイトのインフラに与える影響

サードパーティ製プラグインを使用する場合も、独自のコードを実装する場合も、サイトにAI機能を導入する際には、サーバーのパフォーマンスやリソース消費にどのような影響があるのかを把握することが重要です。

リソースの管理が不十分だったり、コードの設計に問題があったりすると、サーバーに過剰な負荷がかかり、PHPリソースの不足、サーバーのタイムアウト、帯域幅の過剰消費、HTTP 5xxエラー、さらにはサイトのダウンにつながる可能性があります。

コンテナ化されたインフラ、多層キャッシュ、データベースの自動最適化、柔軟に拡張できるPHPスレッドなどを備えた高性能なクラウドサーバーでも、AIによる処理の負荷そのものをなくすことはできません。しかし、十分なリソースを確保できる環境であれば、ボトルネックの発生を防ぎ、アクセスの急増によるパフォーマンスへの影響がサイト訪問者に及ぶ前に対処しやすくなります。

ブラックフライデーのようなアクセスが集中する時期に、サイトの表示が遅くなる事態は避けたいものです。特に、サイトの稼働状況が売上に直結する企業にとって、サーバーのタイムアウトは大きな損失につながりかねません。AIがサイトの機能や処理においてますます重要な役割を担うようになる中、高いパフォーマンスと拡張性を備えたホスティングサービスの選択は、もはや欠かせないものとなっています。

Kinstaは、AI時代のWordPressサイトに求められるパフォーマンス、セキュリティ、監視機能を提供しています。Kinstaのサーバーにご興味がありましたら、ぜひプラン一覧をご覧ください。

Carlo Daniele Kinsta

ウェブデザインとフロントエンド開発をこよなく愛し、WordPress歴は10年以上。イタリアおよびヨーロッパの大学や教育機関とも共同研究を行う。WordPressに関する記事を何十件も執筆しており、イタリア国内外のウェブサイトや雑誌に掲載されている。詳しい仕事情報はXとLinkedInで公開中。