買い物客が目にするのは、1つの決済ページですが、その裏側では、WordPressサイトが複数の外部サービスと通信し、決済処理、在庫確認、送料の計算、CRMの更新などを行っていることがあります。プラグインを使えば、こうした外部サービスとの連携は簡単に設定可能です。とはいえ、連携先のサービスの応答が遅くなったり、応答しなくなったりした場合に、サイトにどのような影響が及ぶのかは、必ずしも明確ではありません。

外部サービスとの連携やAI機能が増えるにつれ、サイト管理の日常的な処理はますますAPIに依存するようになります。したがって、単なるWordPressサイトとして運用しているつもりでも、APIとの連携を考慮してサーバー環境を選ぶことが重要です。

この記事では、WordPressがAPIをどのように利用しているのか、サーバー環境が外部サービスとの連携のパフォーマンスにどう影響するのか、APIの応答遅延やエラーによってサイト全体に問題が及ぶのを防ぐにはどうすればよいのかを解説していきます。また、監視すべき項目や、Web制作・運用会社が新たな外部サービスを連携する前に確認しておきたいポイントも見ていきます。

WebサイトがAPIを利用する仕組み

サイトがAPIを通じて別のシステムから情報を取得したり、特定の処理を依頼したりする場合、そのサイトは「APIを利用する側」になります。例えば、配送サービスから送料の見積もりを取得したり、メール配信サービスに注文確認メールの送信を依頼したりするケースがこれにあたります。

APIと聞くと、WordPress REST APIを思い浮かべるかもしれませんが、WordPress REST APIは、外部のプログラムがWordPressサイトからコンテンツを取得したり、許可された操作を実行したりするための仕組みです。WordPressがAPIを利用する場合は、WordPress側から外部サービスにリクエストを送信し、そのサービスから応答を受け取ります。1つのサイトで両方の仕組みを利用することも可能です。

普段よく使われる以下のようなサイトの機能にも、外部APIが数多く利用されています。

  • 決済： 決済サービスに取引情報を送信し、決済処理を依頼する

  • 在庫管理： 倉庫管理システムに商品の在庫状況を問い合わせる

  • 配送・税金： 購入者の所在地に基づいて送料や税率を取得する

  • 見込み顧客の獲得： フォームに入力された情報をCRMに送信する

  • メール： パスワードリセットや購入確認のメール送信を依頼する

  • 検索・AI： 検索結果の取得、文章の生成、コンテンツの分析を行う

こうしたAPIへのリクエストでは、どこから、どのタイミングで送信されるかが重要です。例えば、送料の見積もりは、購入者が決済を完了する前に取得する必要がある一方で、CRMへの情報の反映は、フォームの送信完了後に行っても問題ない場合があります。

APIへのリクエストには、訪問者のブラウザから直接送信されるものと、サーバー上のWordPressを経由して送信されるものがあります。後者は、訪問者の操作に応じて実行される場合もあれば、バックグラウンドで定期的に実行される場合もあります。また、外部サービスからWebhookを通じて、決済完了などのイベントがサイトに通知され、それをきっかけに別のAPIリクエストが実行されることもあります。

WordPressはサイトが依存する外部サービスとの連携を担う

日常的な作業の多くをWordPress管理画面で行っていると、サイトのすべての処理がWordPress内で完結しているように感じるかもしれません。しかし実際には、ユーザーのログインを許可する前にプラグインが外部の決済サービスで支払い情報を確認し、別のサービスでサブスクリプションの契約状況を確認している場合もあります。これらの機能はWordPress上で管理できますが、処理の一部は外部サービスが担っています。

WordPressは、こうした外部サービスとの連携を調整する役割を果たします。必要な情報を収集して適切なサービスに送信し、その応答に基づいて次の処理を決定します。サイトがどの外部サービスと通信しているかを調べると、クライアントの事業のさまざまな領域に関わっていることがわかります。

  • EC： 決済処理、サブスクリプションの更新、送料の見積もり取得、在庫確認など

  • マーケティング： メール配信リストへの連絡先の追加、CRMへの見込み顧客情報の送信、アクセスの追跡、見込み顧客情報の補完など

  • コンテンツ： 外部の検索サービスの利用、翻訳サービスへのページの送信、別のプラットフォームを利用した画像のリサイズや動画のホスティングなど

  • 認証： 外部サービスのアカウントを使用したログインや、外部の会員管理システムと連携したアクセス権限の確認など

  • AI： チャットボットによるAIモデルへの問い合わせや、AIを活用した商品のおすすめ、不適切な投稿の検出、コンテンツの下書き作成など

例えば、会員制サイトでは、WordPressで会員アカウントを管理し、サブスクリプションの決済は外部サービスで処理することがあります。この場合、両者の継続的な連携が必要になります。決済が成功したか失敗したかによって、WordPress側で会員のアクセス権限を維持するかどうかを判断する必要があるためです。こうした情報のやり取りは、新規登録時だけでなく、契約期間中も継続して行われます。

Web制作・運用会社にとって、これは「サイトが正常に動作している」という状態の捉え方にも関わります。ページが素早く表示されていても、外部サービスとのデータ同期に問題があれば、会員がサイトにアクセスできなくなったり、ECサイトに古い在庫情報が表示されたりする可能性があります。つまり、WordPress自体が正常に動作していることを確認するだけでは不十分です。

サイトがどの外部サービスに依存しているのか、それぞれの連携がどのような役割を担っているのか、そして期待した応答が返ってこなかった場合に何が起こるのかまで把握しておく必要があります。

AIの導入によってAPIの利用がさらに増えている

サイトにAI機能を追加する場合、多くは外部サービスとの連携が必要になります。例えば、AIを活用したサポートアシスタントは、ユーザーからの質問をAIモデルのAPIに送信します。翻訳ツールはコンテンツを送信し、翻訳結果を取得します。また、AI検索機能では、回答を生成する前に検索サービスとAIモデルの両方に問い合わせることもあります。

WordPressは、日常的なさまざまな処理で外部サービスと通信していますが、AI機能には従来とは異なる特徴があります。例えば、AIによる回答の生成には、送料の取得よりも時間がかかる場合があり、一つの質問に対して複数のAPIリクエストが発生することもあります。サポートアシスタントであれば、注文情報を取得し、返品ポリシーを確認したうえで、それらの情報をAIモデルに送信して回答を生成するといった処理が考えられます。

また、ワークフローの自動化によって、短時間に大量のAPIリクエストが発生することも。例えば、数十件の商品説明を一括処理するツールでは、通常のサイト閲覧時よりもはるかに多くのリクエストが同時に送信される可能性があります。各サービスには、それぞれ処理できるリクエスト数などに制限が設けられています。

こうした変化は、以前から徐々に進んでいるAPIを中心とした開発への移行を象徴しています。5,700名以上を対象としたPostmanの「2025 State of the API Report」によると、82%の組織が何らかの形でAPIファーストの開発手法を採用しています。

そこで重要になるのが、APIとの通信中にサイトがどのように動作するかという点です。WordPressはAPIからの応答を待つ必要があるのか、処理をバックグラウンドで実行できるのか、AI機能の処理中でも決済やログインなどの通常の操作を問題なく行えるのか。こうした点を考慮する必要があります。

サーバー環境が外部サービスとの連携に影響する理由

API自体は外部サービスのインフラ上で動作しますが、そのAPIと通信するための処理はWordPressサイト側でも発生します。WordPressはリクエストを準備して送信し、返ってきた応答を処理します。必要に応じて、その結果をデータベースに保存することもあります。こうした一連の処理を支えているのが、サイトのサーバー環境です。

例えば、フォームから送信された見込み顧客の情報をCRMに登録し、その後に送信完了メッセージを表示する場合、次のような処理が行われます。

  1. 訪問者がフォームを送信すると、サーバーがそのリクエストをPHPスレッドに割り当てる

  2. フォームプラグインが入力内容を確認し、CRMにAPIリクエストを送信

  3. 同期処理の場合、PHPスレッドはCRMからの応答が返ってくるまで待機

  4. プラグインが応答を処理し、WordPressが送信完了またはエラーメッセージを返す

CRMからの応答に数秒かかる場合、その間もPHPスレッドは占有されたままになります。待機中はCPUをほとんど使用していない場合でも、別のリクエストを処理することはできません。

KinstaのPHPに関するドキュメントでもご説明していますが、各PHPスレッドが一度に処理できるリクエストはひとつです。利用可能なPHPスレッドがすべて使用中になると、PHPによる処理が必要な後続のリクエストは待機することになります。そのため、CRMからの応答が遅いリクエストが複数発生すると、ユーザーのアカウントページの表示や決済情報の送信など、直接関係のない操作にも影響が及ぶ可能性があります。

サイトに必要なサーバーリソースを判断する際に、月間訪問数だけでは不十分なのは、こうした理由もあります。ただし、考慮すべきなのはPHPスレッド数だけではありません。サーバー環境は、リクエストの準備、定期的な処理の実行、問題の原因調査などにも影響します。

  • CPUとメモリ： WordPressがAPIに送信するデータを準備し、応答を処理してデータベースの情報を更新するには、CPUとメモリのリソースが必要。

  • スケジュール実行： サーバー側で処理の実行スケジュールを設定すれば、サイトへのアクセスがない時間帯でも、指定したタイミングで外部サービスとの連携処理を実行できる。

  • ログと監視： フォームの送信完了までに10秒かかるような場合、ログや監視ツールを使って、外部APIへのリクエストが遅延の原因になっていないか調査可能。

  • アクセス集中時の処理能力： 複数の外部サービスとの連携処理が、決済やログインなどの操作と同時に実行されることもある。利用可能なサーバーリソースによって、同時に処理できる作業量が変わる。

CRMへの情報送信をバックグラウンドで実行すれば、訪問者を待たせずにフォームの送信を完了できます。ただし、CRMへの送信処理自体が不要になるわけではありません。バックグラウンドでの処理が正常に完了したか、失敗した場合はどう検知するかも考えておく必要があります。

サーバーが外部のCRMサービスの応答速度や稼働状況を制御することはできませんが、外部サービスとの連携に必要な処理能力や、問題が発生した際に状況を確認するためのツールを提供することは可能です。

APIに問題が発生すると起こること

APIに問題が発生しても、必ずしもサイト全体が停止するわけではありません。トップページは正常に表示されていても、購入者が送料を確認できなかったり、新規見込み顧客の情報がCRMに送信されなかったりすることがあります。訪問者からすれば、必要な機能が使えない以上、サイトが正常に動作していないことに変わりはありません。

具体的にどのような問題が発生するかは、外部サービスが担っている処理によって異なります。

  • 配送： 配送サービスから送料の見積もりが返ってくるまでに時間がかかり、購入者が配送方法の表示を待たされる

  • 決済： 決済自体は完了していても、その結果がWordPressに通知されないため、決済状況を確認せずに再試行すると、購入者に二重請求が発生する可能性がある

  • CRM： 訪問者がフォームに情報を入力して送信しても、CRM側で受け付けられない。WordPressには見込み顧客の情報が残っていても、営業担当者が利用するCRMには登録されない

  • AI： 外部のAIサービスの利用上限に達し、サイトのAI機能が新たなリクエストを受け付けなくなる

  • 在庫管理： 在庫情報が更新されなくなり、購入者が商品の正確な在庫状況を確認できなくなる

  • Webhook： 外部サービスから同じ通知が2回送信され、連携先で両方が処理されることで、注文情報の更新やメール送信が重複する可能性がある

こうした問題の中には、明確なエラーが表示されるものもあれば、処理結果を詳しく確認しない限り、正常に完了したように見えるものもあります。

特に注意したいのが、タイムアウトが発生した場合です。WordPress側では応答の待機を終了していても、外部サービス側ではリクエストの処理が続いている可能性があるため、処理が実際に完了したかどうか判断できません。決済やデータの更新を再試行する前に、まず外部サービス側での処理状況を確認することが重要です。

また、問題が発生した際にサイトがどのように対応するかも、処理の内容に応じて検討する必要があります。例えば、CRMへの情報送信であれば、時間をおいて再試行しても問題ない場合がほとんどです。一方、決済時にエラーが発生した場合は、購入者に状況がわかるメッセージを表示する必要があります。決済が完了したかどうか不明な場合には、担当者による確認が必要になることもあります。

APIの応答遅延やエラーに備えよう

購入者が注文確認画面を見るために、メール配信サービスへの連絡先の登録が完了するまで待つ必要はありません。しかし、プラグインが決済時にすべての処理を完了しようとすると、こうした状況が発生する可能性があります。まずはサイトが送信するAPIリクエストを確認し、すぐに応答が必要なものと、後から処理しても問題ないものを整理しましょう。後者をバックグラウンドで実行することで、購入者を待たせずに済む場合があります。

その際は、以下の点を確認しておくことが重要です。

  • すぐに処理する必要があるか： CRMへの情報送信やレポート作成などは、可能であればバックグラウンドの処理キューに移す。ただし、バックグラウンドで処理が失敗しても、誰も気づかなければ意味がないため、処理が正常に完了したかどうかを確認できる仕組みも必要。

  • 応答をどのくらい待つか： プラグインやカスタムコードのタイムアウト設定を確認。デフォルトの設定が、必ずしもその機能に適しているとは限らない。例えば、検索候補の表示を待つユーザーと、夜間に実行される定期的なデータインポートでは、許容できる待機時間が異なる。

  • 再試行の回数を制限する： プラグインによっては、同じリクエストを必要以上に繰り返し送信することがあるため、まずは返されたエラーの内容を確認。外部サービスが混雑している場合や一時的に利用できない場合は、再試行の間隔を徐々に延ばし、サービス側から待機時間が指定されていればそれに従う。また、再試行が無制限に続かないよう、上限を設定しておく。

  • 決済のタイムアウト時の対応を決める： 決済完了の通知がWordPressに届いていなくても、外部の決済サービスでは請求処理が完了している可能性がある。再度請求する前に、必ず取引状況を確認すること。APIが冪等性キー（Idempotency key）に対応している場合は、同じ処理を再試行する際に元のキーを再利用。また、Webhookの重複にも注意が必要です。イベントIDを記録しておけば、通知を受信した際に、すでに処理済みかどうかを確認できる。

  • データの鮮度をどこまで求めるか： おすすめ商品の情報は、ページが開かれるたびに更新する必要がない可能性がある。その一方で、在庫情報は頻繁な更新が必要になる場合も。情報の更新頻度や用途に応じて、キャッシュの有効期限を設定すること。

  • APIリクエストが失敗した場合の表示を決める： おすすめ商品を取得するサービスが応答しない場合は、代わりに通常の商品一覧を表示できる。決済結果を確認できない場合は、その状況を購入者に伝え、注文状況の確認方法を案内しなければならない。処理の完了を確認できた場合にのみ、成功メッセージを表示するようにする。

  • 認証情報の管理方法を確認する： 秘密のAPIキーはサーバー側で管理し、連携に必要な最小限の権限のみを付与。ブラウザ側のコードやログにAPIキーを含めないようにし、テスト環境では本番環境とは異なる認証情報を使用すること。

変更を加えたら、ステージング環境でAPIの応答を意図的に遅らせたり、タイムアウトを発生させたりしてテストしましょう。その間に決済やログインを試し、ほかの機能にも遅延の影響が及ばないか確認してみてください。また、同じWebhookを2回送信し、サイト側で処理が重複しないことも確かめます。

さらに、リクエストの送信から最終的な処理結果までを確認することも大切です。注文が二重に作成されていないか、見込み顧客の情報がCRMに正しく登録されているかを確認してください。バックグラウンド処理が失敗した場合には、原因を特定できるように記録を残し、処理を重複させずに再試行できる仕組みを整えておく必要があります。

処理量に応じてサーバーリソースを増やすことも有効ですが、その前に、不要なAPIリクエストや長すぎる待機時間、過剰な再試行によって、現在のリソースが無駄に消費されていないかをチェックしてみてください。

リクエストの処理全体を監視する

クライアントから決済処理が遅いと報告された場合、まずはどの処理に時間がかかっているのかを特定する必要があります。WordPressのプラグインの実行、データベースへのクエリ、配送サービスからの応答待ちなど、原因はさまざまで、それぞれ対処方法も異なります。

まずは問題が発生している操作を再現し、どのようなリクエストが送信されるかを確認しましょう。特に、以下の点を調べることが重要です。

  • 応答時間： どの外部サービスからの応答に最も時間がかかっているか

  • エラーとタイムアウト： どのリクエストが失敗し、外部サービスからどのような応答が返されているか

  • レート制限と再試行： 外部サービスからリクエストの送信を控えるよう指示されているにもかかわらず、連携機能がリクエストを繰り返し送信していないか

  • バックグラウンド処理： スケジュールされたタスクが正常に完了しているか、それとも失敗しているか

  • Webhook： 各イベントの通知をサイトが正しく受信し、処理できているか

  • リクエストの発生元： どのプラグイン、スケジュールされたタスク、訪問者の操作がリクエストのきっかけになっているか

ブラウザの開発者ツールを使えば、訪問者のブラウザから送信されたリクエストを確認できます。また、サーバーからの応答に時間がかかっていることも把握できますが、その間にWordPress内部でどのような処理が行われているかまではわかりません。詳しく調べるには、サーバー側の監視が必要です。

Kinsta APMでは、PHPの処理、データベースクエリ、外部HTTPリクエストを記録し、問題の原因を調査できます。「外部」タブでは、サーバー側で実行されたリクエストのうち、応答に時間がかかっているものを確認できます。また、トランザクショントレースを使えば、それらのリクエストがWordPressのどの処理で発生しているかを把握できます。

Kinsta APMで確認できるGemini APIへの2つの呼び出しの所要時間
Kinsta APMで確認できるGemini APIへの2つの呼び出しの所要時間

これらの処理時間をアプリケーションのログやタスクの実行記録と照らし合わせることで、問題の全体像を把握できます。APMではリクエストのどこで遅延が発生しているかを確認でき、連携機能自体のログでは、データが送信先に正しく届いているか、Webhookによって注文情報が更新されているかなどを確認できます。

連携方法を変更した後は、できるだけ同じ条件で一連の処理を再度テストしましょう。応答時間だけでなく、処理結果も確認することが重要です。確認画面の表示が速くなっても、その裏側で必要な処理が正常に完了していなければ、問題を解決したことにはなりません。

プラグインだけでなく連携先のサービスも把握する

プラグインの一覧を確認するだけでは、注文情報が出荷処理システムに届かない原因や、フォームから送信された見込み顧客の情報がCRMに登録されない原因まではわかりません。そのため、サイトの点検や定期メンテナンスでは、プラグインだけでなく、その裏側で連携している外部サービスも確認することが重要です。

クライアントのサイトごとに、以下の点を確認しましょう。

  • WordPressから外部サービスにどのような処理を依頼しているか

  • どのAPIリクエストが訪問者を待たせる原因になり、どの処理なら後から実行できるか

  • 外部サービスの応答が遅くなったり、サービスが停止したりした場合、サイトにどのような影響があるか

  • 外部サービスからの応答を待つ時間はどのくらいに設定されているか

  • 失敗したリクエストは自動的に再試行されるか。その際、二重請求やデータの重複登録、メールの重複送信が発生する可能性はないか

  • どのデータを再利用でき、どのくらいの頻度で更新する必要があるか

  • APIの認証情報はどこに保存され、誰が取得・変更できるか

  • スケジュールされたタスクやWebhookの処理が正常に完了したか、どこで確認できるか

  • リクエストの処理に時間がかかっている場合、送信元のプラグインや処理を特定できるか

  • ステージング環境でのテストに、APIリクエストの失敗や複数リクエストの同時実行も含まれているか

確認した内容は、各連携の管理担当者とあわせて、サイトの技術ドキュメントに記録しておきましょう。

Kinstaでは、ステージング環境、調整可能なPHPリソース、サーバー側でのcronジョブ、ログ、APMなど、Web制作・運用会社がこうした処理をテストし、問題を調査するための機能を提供しています。これらを活用して各サイトに必要なリソースや設定を見極め、クライアントが新たな外部サービスを追加したり、既存の連携方法を変更したりした際には、改めて確認することが大切です。

サイトの安定稼働には外部サービスとの連携も重要

一見シンプルなWordPressサイトでも、想像以上に多くの外部サービスと連携していることがあります。商品の購入や会員登録、検索などの処理を最初から最後まで追ってみると、その過程で複数の外部サービスが利用されていることに気づくかもしれません。各サービスにはそれぞれ処理速度や利用上限があり、応答が遅くなったり、応答しなくなったりした場合にも、サイト側で適切に対応できる必要があります。

だからといって、サイト全体を作り直す必要はありません。まずは決済や会員登録など、利用者にとって重要な操作を一つ選び、どこで処理が滞る可能性があるかを確認してみてください。外部サービスから応答が返ってこなかった場合、利用者に状況がわかるメッセージが表示されるか、あるいは担当者に問題が通知されるか。こうした点を確認するだけでも、改善すべき箇所が見えてきます。

サーバー環境も、こうした対策を支える重要な要素です。WordPressがリクエストを処理するためのリソースや、遅延の原因を調査するためのツールを提供します。そして、外部サービスとの連携を適切に設計することで、それらのリソースをより効率的に活用できます。

サイトが担う業務が増えるにつれ、その裏側で動作する外部サービスとの連携も考慮することが重要になります。KinstaのWordPress専用マネージドクラウドサーバーでは、こうしたサイト運用を支えるインフラと開発者向けツールをすべてのプランで標準提供しています。

Carlo Daniele Kinsta

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