Googleで優先する情報源に追加
例えば、WooCommerceストアに新たにチャットボットを導入するとします。テストでは何の問題もなく動作しています。商品に関する質問に答え、買い物客の商品比較をサポートし、応答速度も十分。パフォーマンス上の問題はなさそうに見えます。
ところが、アクセスが増える時間帯になると問題が表面化します。決済処理に少し時間がかかるようになり、PHPスレッドが上限に達するにつれて応答時間も徐々に長くなります。一見するとアクセス急増による速度低下のように思えますが、訪問者数は前週とほぼ同じ。変化したのは、1回の訪問でサーバーが処理しなければならない作業量です。
チャットボットとのやり取りでは、その都度WordPressを経由するリアルタイムのAPI呼び出しが発生する可能性があります。このリクエストはページキャッシュを迂回し、AIモデルのプロバイダーが応答を生成するまでPHPスレッドを占有します。さらに、商品情報や会話履歴など、応答に必要なコンテキストを取得するためにデータベースへのクエリが発生することもあります。買い物客から見れば、2秒で回答が返ってくるだけですが、サーバー側では、その2秒間、1つのスレッドを他の処理に使用することができない状態です。
こうしたインフラ面の問題は、徐々に無視できないものになっていきます。WordPress 7.0では、特定のプロバイダーに依存しないAIクライアントをはじめ、Abilities APIやコネクタハブが導入され、WordPressコアにAIを組み込むための基盤が整備されました。
同様の負荷は、一見するとまったく異なる機能から生じることもあります。AI検索、商品レコメンド、パーソナライズされたコンテンツ、編集ツール、AIエージェントとの連携は、それぞれ異なる方法でWordPressとやり取りします。各機能が管理画面、フロントエンド、APIのどこで動作するのか、そしてそのリクエストをキャッシュできるのかを把握することで、必要となるサーバーリソースを適切に見積もることができます。
WordPressサイトでAI機能はどう動くのか
WordPressにおけるAIのワークロードは一様ではありません。機能がどこで、いつ実行されるのか、そして訪問者の操作によって実行されるのかによって、インフラにかかる負荷の特性も変わります。
AIチャットボットとサポートアシスタント
おそらくこの分野が最も目にする機会が多いでしょう。AI Engine（アクティブインストール数10万以上）、MxChat、Tidioなどのプラグインを追加すると、サイトのフロントエンドに対話型のインターフェースを導入できます。
メッセージが送信されるたびに、動的なリクエストの処理、コンテキストの取得、外部AIモデルの呼び出し、会話データの保存などが発生する可能性があります。問い合わせフォームの送信とは異なり、1回の会話でこうしたリクエストが短時間に何度も発生することもあります。
AIによるパーソナライズ、レコメンド、検索
パーソナライズ、レコメンド、AI検索は通常、フロントエンドで実行されます。WooCommerceストアであれば、買い物客がこれまでに閲覧した商品に基づいておすすめ商品を調整したり、検索語句との完全一致ではなく、その意図を解釈して検索結果を表示したりすることが考えられます。ページのその他の部分にはキャッシュを利用できる場合が多いものの、こうした結果は個々のリクエストに応じて生成する必要があります。
AIコンテンツ生成・編集ツール
Jetpack AI、Rank Math Content AI、Divi AI、GetGenieなどがこれにあたります。これらのツールは、主にWordPressの管理画面内で動作します。
管理画面内で動作するため、通常はフロントエンドのページ読み込み速度には影響しませんが、複数の編集者が同時に使用すると、サーバーに大きな負荷がかかる可能性があります。
AIエージェントとMCP連携
MCP連携は、誰かがサイトを訪問するのを待って動作するものではありません。AI EngineのMCPサポートや公式のWordPress MCP Adapterを使用すると、外部ツールをWordPressに接続し、サイトデータの読み取りや投稿の更新など、許可された操作を実行できます。各操作は認証済みのAPIリクエストとして処理されるため、サーバー負荷を考えるうえで、こうした処理も考慮する必要があります。
同じようにAIを使用するサイトでも、必要なサーバーリソースは大きく異なる可能性があります。たとえば、エディターで見出しの候補を生成するために時折AIを使用するサイトもあれば、訪問者一人ひとりに商品レコメンドを生成するサイトもあります。AI機能による影響を見積もるには、その機能がどこで動作し、どの程度の頻度でWordPressへのリクエストが発生するのかを確認することが重要です。
AI機能がサーバーに与える実際の影響
AI機能による負荷は、AIモデルが応答を生成すること自体ではなく、その前後で発生する一連の処理によって生じます。WordPressでは、リクエストの受信、プラグインコードの実行、必要なデータの取得、外部プロバイダーへの接続、結果の返却といった処理が必要です。この一連の処理の中でも、特にパフォーマンスへの影響が大きい要素が4つあります。
PHPスレッドの占有時間が長くなる
キャッシュされたコンテンツは、PHPスレッドを使用せずに配信できます。一方、動的なAIリクエストの処理にはPHPスレッドが必要で、各スレッドが一度に処理できるリクエストは1件のみです。たとえば、チャットボットが外部プロバイダーからの応答を2秒間待つ場合、そのやり取りを処理するPHPスレッドも2秒間占有される可能性があります。同時に複数の会話が発生して利用可能なスレッドがすべて使用されると、その他のキャッシュされていないリクエストは処理待ちになります。
この仕組みは、KinstaのAIボットに関するレポート「AI・ボット時代におけるトラフィックの実態」で取り上げたボットのパターンとよく似ています。ボットが検索やカートなどの動的なページにクセスすると、PHPスレッドが占有され、オリジンサーバーでの処理が必要になります。AI機能でも意図的に同じことが行われ、理想的にはサイトに有益な結果をもたらします。しかし、リクエスト1件あたりのインフラへの負荷という点では、両者に大きな違いはありません。
キャッシュを迂回するリクエストの増加
AIによる応答の多くは、リクエストを行ったユーザーごとに内容が異なるため、そのまま次の訪問者に再利用することはできません。メインの商品ページにはキャッシュを利用できても、商品レコメンドやAI検索の結果は個別に生成する必要があります。こうした処理が1回の訪問中に何度も発生するほど、オリジンサーバーで処理しなければならないリクエストも増加します。
データベース処理が複雑化
プロンプトを送信する前に、プラグインがWordPressから商品情報や過去のメッセージ、ユーザーに関する情報などを取得することがあります。こうしたデータはリクエストごとに変化するため、通常のページクエリよりもキャッシュが困難です。このようなリクエストが同時に多数発生すると、決済ページやアカウントページでも独自の処理が行われる中、データベースへの負荷がさらに高まります。
外部APIのレイテンシがサイトパフォーマンスに影響
AIプラグインでは、リクエストの処理を完了するまでに外部サービスからの応答を待つことがよくあります。たとえばOpenAIからの応答に3秒かかれば、その間WordPressも待機することになり、同期呼び出しの場合は処理を担当するPHPスレッドも占有されます。外部APIから応答がない状態がいつまでも続かないよう、プラグイン側でタイムアウトを設定することが重要です。ワークロードによってはキューやキャッシュを利用することもできますが、リアルタイムのチャットボットでは通常、外部プロバイダーからの応答を待つ必要があります。
WordPress 7.0でも、これに関連する事例がありました。リアルタイムコラボレーション機能は、テストの結果、サーバー負荷やメモリ使用量、競合状態に関する懸念が浮上したため、リリースから除外されています。機能自体には価値があるものの、WordPressコアに求められるパフォーマンス要件を満たした状態でリリースできる段階には達していないと判断されました。
AIを活用するWordPressサイトで特に重要な3つのサーバー特性
AIのワークロードには、動的で負荷が急増しやすく、サーバー環境外のサービスに依存することが多いという特徴があります。こうしたリクエストによる負荷を適切に制御して原因を特定できるか、それともサイトの他の部分にまで影響が及ぶかを左右する、特に重要なサーバー特性が3つあります。
1. 隔離コンテナアーキテクチャ
共用サーバーでは、1台のサーバーを複数のサイトで共有するため、これが問題になることがあります。AIによる処理が突然増加すると、同じサーバー上にある他のサイトが利用できるCPU、メモリ、データベースのリソースを圧迫する可能性があります。
Kinstaでは、すべてのWordPressサイトをそれぞれ独立したLinuxコンテナで実行し、Nginx、PHP、MySQLを含む専用のソフトウェアスタックを提供しています。また、サイトごとにPHPスレッドとメモリが割り当てられます。AIチャットボットで突然数十件の会話が同時に発生しても、そのワークロードはサイトのコンテナ内に留まり、別のサイトに割り当てられたリソースを消費することはありません。
このような分離は、特にクライアントサイトを複数管理する制作会社にとって大きなメリットがあります。あるクライアントサイトでAIプラグインの設定に問題があり、そのサイトのパフォーマンスが低下したとしても、管理する他のサイトにまで影響が波及することを防ぐことができます。
2. 最新のPHPバージョンと適切な設定
PHP 7.4でもWordPress 7.0を実行できますが、パフォーマンスを重視するのであれば最適な選択肢とは言えません。PHP 8.xではWordPressのコードをより高速に処理できるため、AIリクエストに伴う処理時間が短縮され、PHPスレッドもより早く次の処理に利用できるようになります。
新たなPHPバージョンを使用しても、OpenAIやAnthropic自体の応答速度が上がるわけではありませんが、。外部APIを呼び出す前後にWordPress側で行われる処理を短縮することはできます。KinstaではPHP 8.5までのバージョンをサポートしており、MyKinstaから本番環境またはステージング環境ごとにPHPバージョンを変更可能です。まずはステージング環境で変更をテストすることで、AIプラグインやテーマ、カスタムコードとの互換性に問題がないかを事前に確認できます。
3. リクエスト全体を可視化
AI関連のパフォーマンス問題は、プラグインのPHPコード、データベースクエリ、外部のAIモデルプロバイダー、PHPスレッドの不足など、さまざまな箇所で発生する可能性があります。リクエスト単位のデータを確認できなければ、いずれも単なるサーバー全体の速度低下に見えてしまいます。
Kinsta APMを使用すると、これらの要因を切り分けて確認することができます。
実際の調査では、たとえば以下のような手順で原因を絞り込んでいきます。
- 「分析」画面の「パフォーマンス」タブで、応答時間がいつから長くなったのかを確認
- 「APM」画面の「トランザクション」タブを開き、処理に最も時間がかかっているエンドポイントやリクエストを特定
- 「APM」画面の「外部」タブで、OpenAI、Anthropicなどの外部プロバイダーへの呼び出しにかかっている時間を確認
- 「APM」画面の「データベース」タブで、処理の遅いクエリや、パーソナライズに伴って繰り返し実行されているクエリがないかを確認
- 「サーバーキャッシュ除外上位パス」で、AI機能によるどのパスへのリクエストがキャッシュを迂回してオリジンサーバーに到達しているかを確認
どの処理に時間がかかっているのかが分かれば、適切な対策を講じることができます。WordPress側の処理が遅い場合と、データベースに処理が滞留している場合、AIモデルのAPIから応答が返るまでに数秒かかっている場合では、それぞれ必要な対策が異なります。
AI機能によって変化するトラフィックの特性
AIは、双方向からインフラへの負荷を高める可能性があります。WordPressサイトからAIモデルのプロバイダーに送信するリクエストが増える一方、自動化されたシステムからサイトへのリクエストも増加します。
AIを活用してコンテンツ制作を効率化すると、クローラーが巡回する範囲も急速に広がります。たとえば、メディア運営チームが週5本だった記事の公開数を20本に増やせば、それに伴ってURLや内部リンク、アーカイブ、ページネーションも増え、クローラーが巡回する対象が拡大します。クローラーにとって、そのコンテンツがAIを使って制作されたかどうかは関係ありません。更新頻度の高いコンテンツが増えたことで、サイトをより頻繁にクロールするようになります。
キャッシュされたページへの100万件のリクエストと、動的URLへの100万件のリクエストでは、サーバーにかかる負荷が大きく異なります。Kinstaが100億件以上のリクエストを分析したところ、クローラーは検索結果、絞り込み後の商品ページ、カート追加リンクなどのエンドポイントにも繰り返しアクセスしていることがわかりました。このようなリクエストはキャッシュを迂回し、PHPやデータベースでの処理を発生させる可能性があります。
その結果、自動トラフィックとサイト自身のAI機能が、同じサーバーリソースを取り合うことになります。チャットボットへのリクエストと、クローラーによる動的な商品絞り込みへのアクセスでは目的こそまったく異なりますが、どちらもPHPスレッドを占有する可能性があります。クローラーがサイトで利用可能な処理能力の多くを消費すると、正当なチャットボット、検索、レコメンドのリクエストに割り当てられるリソースが少なくなります。
AIを活用するサイトでは、実際の訪問者からのリクエストを処理できるだけの余裕を確保する必要があります。そのために役立つのがボット対策です。インデックス登録したいページには引き続きGooglebotのアクセスを許可する必要があり、AIクローラーについても、サイトにとって有益であれば許可することができます。一方で、動的なエンドポイントに繰り返しアクセスし、PHPスレッドを占有するだけで価値をもたらさないトラフィックは制限することが重要です。
Kinstaのボット対策機能では、環境単位で自動トラフィックを許可、検証、ブロックすることができ、AIクローラー専用の設定も用意されています。また、分析機能でリクエストがどのように分類・処理されているかを確認できます。
ボットの分析だけでは、全体像を把握することはできません。MyKinstaでAPMのトレース、キャッシュを迂回したリクエストのレポート、アクセス元IP上位などと照らし合わせることで、負荷の原因がサイト自身のAI機能にあるのか、外部のクローラーにあるのかを切り分けやすくなります。また、クローラーによるリクエストが、消費するリソースに見合う価値をもたらしているかどうかを判断するのにも役立ちます。
WordPressサイトにAI機能を導入する前に確認したいこと
AI機能を本番環境に導入する前に、現在のインフラ上でどのように動作するかをテストしておくことが重要です。まずは、以下の5つのポイントを確認してみてください。
1. プラグインはリクエスト処理のどの段階で動作するか
ここでは、リクエストがどのような経路で処理されるかが重要です。文章作成や編集を支援するツールは、通常wp-admin内で処理が完結します。一方、訪問者向けのツールは、決済ページやアカウントページを含むフロントエンドの他の処理とPHPの処理能力を共有します。AIエージェントの場合は、そのどちらも経由せず、APIから直接アクセスすることもあります。必要な処理能力を見積もる前に、プラグインのリクエストがどのような経路で処理されるのかを確認しておきましょう。
2. プラグインで何をキャッシュできるか
プラグインが具体的に何をキャッシュ対象外としているのかを確認します。AIの応答自体はプロンプトやユーザーによって変化するため、動的に生成する必要がありますが、会話の状態、検索結果、レコメンドなどの関連データは、短時間であれば再利用できる可能性があります。商品ページ全体を動的にするプラグインと比べれば、キャッシュ対象外となる専用のAPIエンドポイントだけを使用するほうが、サーバーへの負荷を大幅に抑えられます。
3. 外部APIの応答が遅い場合にどうなるか
応答が遅い場合だけでなく、API呼び出しに失敗した場合の動作もテストしておきましょう。ステージング環境で一時的に接続できない状態を作り、リクエストがいつ終了するかを確認します。プラグインによってはすぐに再試行するものもあれば、PHPによって処理が打ち切られるまで接続を維持するものもあります。複数のチャットボットリクエストでこれが同時に発生すると、決済ページやアカウントページへのリクエストがPHPスレッドの空きを待つことになる可能性があります。
4. APMツールを有効にして、まずステージング環境でテスト
ステージング環境にプラグインをインストールし、テスト中はKinsta APMを有効にします。通常想定される会話や検索、コンテンツ生成のワークフローを再現し、必要に応じて複数の処理が同時に発生する状況もテストします。「トランザクション」「外部」「データベース」の各タブを確認することで、リクエストの処理にかかる時間と、どの処理に時間を要しているかを把握できます。
5. PHPに追加の処理を行う余裕があるか
PHPを変更する前に、まずステージング環境の動作状況を記録しておきます。MyKinstaでは、PHPスレッドがすでに上限に達していないかを確認できるほか、応答時間やメモリ使用量のデータも確認できます。ステージング環境を最新のPHP 8.xに切り替えて同じワークフローを再度実行し、プラグインが問題なく動作することを確認してから、本番環境にも変更を適用します。
ステージング環境で本番環境の状況を完全に再現することはできません。それでも、プラグインによってキャッシュを迂回するリクエストが増えすぎていないか、外部APIからの応答に時間がかかっていないか、負荷の高いクエリが実行されていないか、サイトの他の処理に必要なPHPの処理能力が不足していないかを確認することができます。
AI機能の導入はインフラの変更として捉える
WordPress 7.0では、開発者がAIプロバイダーと連携し、WordPressからAIモデルを呼び出すための標準的な仕組みが提供されています。しかし忘れてはならないのは、AI機能を本番環境に導入すれば、それに伴うリクエストを処理するのはサーバーだということです。
サーバー環境の変更を検討する前に、まずAPMでいくつかのトレースを確認してみてくだしあ。プラグインの一覧を見てもサイトでどの程度の処理が発生しているかは分からず、PHPスレッド数だけを見てもリクエストが遅い原因までは特定できません。トレースを確認すれば、リクエストがキャッシュを迂回しているか、PHPでの処理にどの程度時間がかかっているか、遅延の原因がデータベースとAIモデルのAPIのどちらにあるのかを把握できます。その結果をもとに、プラグイン側の改善が必要なのか、サイトにより多くのリソースが必要なのかを判断できます。
AIプラグイン自体が問題なく動作していても、現在のサイトの処理能力には適していない可能性があります。クライアントサイトに導入する前に、ステージング環境でAPMを実行し、外部APIへのリクエストにかかる時間、キャッシュを利用できないリクエスト、環境で使用しているPHPバージョンを確認しておきましょう。本番公開後には、実際のトラフィックが発生している状態でも同じ指標を改めて確認します。
こうした確認を行うことで、PHPスレッドへの負荷、外部サービスによる遅延、負荷の高いデータベースクエリなどを、サイト全体の速度低下やクライアントとのトラブルにつながる前に発見できます。
