WordPress（世界的に利用されているCMS、コンテンツ管理システム）にAI機能を組み込む案件を担当している、またはこれから検討しているエンジニアに向けた内容です。プラグインでLLM（大規模言語モデル）を呼び出す実装は一見簡単に見えますが、既存のWordPressの同期処理アーキテクチャとAIの非同期的な重い処理は本質的に相性が悪い部分があります。その衝突がどこで起きるのか、設計判断としてどう吸収するかを整理しました。
WordPressは元々、リクエストが来たらPHPがデータベースを問い合わせ、HTMLを組み立てて即座に返す、という同期処理を前提に作られています。ここにAIの呼び出しを素直に差し込むと、レスポンスタイムの前提が崩れます。OpenAIやClaudeのようなLLM APIは応答生成に数秒かかることが珍しくなく、通常のWordPressページ生成（多くはミリ秒〜1秒未満）とは桁が違います。
何が起きるか：504タイムアウトとリクエストブロッキング
管理画面の記事作成中に「SEO構造を自動生成する」ボタンを押し、その場でLLM APIを同期的に呼び出す実装を考えてみます。Webサーバー（Nginxやロードバランサー）には通常30〜60秒程度のタイムアウト設定があり、これを超えると504 Gateway Timeoutが返ります。
さらに深刻なのは、PHPの標準的な実行モデルでは1リクエストが1プロセス（またはPHP-FPMのワーカー）を占有する点です。LLM応答を待つ数秒間、そのワーカーは他のリクエストを処理できません。同時に複数の編集者がAI機能を使うと、サーバー全体のスループットが落ち、一般ユーザー向けのページ表示まで遅延する可能性があります。これは可用性の観点で見過ごせないリスクです。
段階的に見る対処のアーキテクチャ
最初に確認すべきは、AI呼び出しをリクエスト処理の同期パスから切り離せるかどうかです。具体的には次の3つの選択肢があります。
- 非同期ジョブキュー化：Action SchedulerやWP-Cron、あるいは外部のRedis/RabbitMQベースのキューにAI処理を委譲し、完了後にDBへ結果を書き戻す
- フロントエンドのポーリングまたはWebSocket通知：管理画面側でジョブの完了をポーリング（一定間隔で確認）し、UIを非同期に更新する
- 別プロセスへのオフロード：AI呼び出し専用のマイクロサービス（Node.jsやPythonの軽量APIサーバー）を立て、WordPressはリクエストを投げるだけにする
これらはいずれも「WordPressのPHPプロセスをLLMの応答待ちで塞がない」という一点に集約されます。WP-Cronは実際にはリクエストドリブン（誰かがサイトにアクセスした際に発火するタイマー）で、真のバックグラウンド実行ではない点には注意が必要です。負荷が読めないサイトでは、サーバーのcronでwp-cron.phpを直接叩く設定に切り替える、あるいは前述の別プロセス構成にする方が安定します。
次に確認すべきは、認証とAPIキー管理です。プラグイン内にカスタムのREST APIエンドポイント（例としてwp-json/v1/ai-tools/のような名前空間）を登録し、トークン検証と認可のロジックをそこに集約する設計が基本になります。管理画面のJavaScriptから直接OpenAIやClaudeのAPIキーを叩く実装は、キーがブラウザ側に露出するため避けるべきです。必ずサーバーサイドのエンドポイントを経由させ、キーはWordPressのwp-config.phpや環境変数、あるいはシークレット管理サービス側に置きます。
関連技術との比較：なぜプラグイン単体で完結させないのか
市販のAIプラグインの多くは、コンテンツ生成やチャットボットなど汎用機能を提供しますが、業務固有のワークフロー（在庫連動の回答、社内データに基づく分類など）には対応しきれません。WooCommerceのREST APIと連携してリアルタイムの価格・在庫情報をAIエージェントに渡す、といった構成は既製プラグインの守備範囲を超えます。
こうした要件では、コア機能をカスタムプラグインにカプセル化し、add_actionやadd_filterといったWordPress標準のフック機構でAI応答を各所に出力する設計が現実的です。フックは「特定のタイミングで自作の処理を差し込む仕組み」で、WordPressのコアやテーマを直接改変せずに機能拡張できる利点があります。テーマやコア本体を書き換えると、アップデート時に変更が消える、あるいは競合するリスクがあるため、プラグイン層に隔離するのは技術的負債を抑える基本方針です。
もう一つの比較軸は、モデル選定です。高精度だが遅く高コストなクラウドの上位モデル（GPT-4クラスなど）を使うか、レイテンシとコストを優先して軽量・ローカルモデルにするかは、機能ごとに判断が分かれます。記事の構造化データ生成のようにレスポンス時間の許容度が高い処理は上位モデルを同期・非同期どちらでも使いやすい一方、リアルタイムのチャット応答では応答速度がユーザー体験に直結するため、モデルサイズとインフラの両面で慎重な検討が要ります。
今日確認できること
自分のプロジェクトがこの問題を抱えているか、次の点を確認してみてください。
- 管理画面やフロント側でAI関連のボタンを押した際、レスポンスに3秒以上かかっていないか（ブラウザの開発者ツールのNetworkタブで確認可能）
- サーバーのNginx/Apacheのタイムアウト設定値と、実際のLLM API呼び出しにかかる時間の余裕があるか
- APIキーがJavaScript経由でクライアント側に露出していないか（ソースを表示して確認）
- AI処理がWP-Cronに依存している場合、アクセス頻度が低い時間帯でジョブが滞留していないか
- 同時アクセス数が増えた際にPHP-FPMのワーカー数上限に達していないか（
php-fpmの設定やサーバーのプロセス監視ツールで確認）
これらは特別なツールがなくても、既存の管理画面とサーバーログの確認だけで判断できる項目です。
まとめ
WordPressへのAI統合は、単なるプラグイン追加ではなく、同期型アーキテクチャに非同期処理をどう組み込むかという設計課題です。
要点を整理すると、まず504タイムアウトやワーカー枯渇はAI呼び出しを同期パスに置いたまま放置すると必ず表面化するリスクです。次に、ジョブキューや別プロセスへのオフロードでPHPプロセスをブロックしない構成に切り替えることが根本対策になります。そしてAPIキー管理とカスタムエンドポイントの設計は、性能だけでなくセキュリティ上の負債を減らす意味でも欠かせません。
まずは自社のAI機能付きページのレスポンスタイムを計測し、同期呼び出しになっていないかを確認するところから始めてみてください。