Googleで優先する情報源に追加
例えば、予約管理ソフトウェア会社を経営するクライアントのWordPressヘルプセンターを運用しているとします。サポートには、定期予約の日程変更に関する問い合わせが繰り返し寄せられている状態です。変更方法はすでにヘルプセンターで案内しているものの、「金曜日の予約を別の日に変更したい」と検索しても、該当する記事が表示されません。
このような理由から、クライアントはAI検索の導入を検討しています。AI検索なら、記事に使われている言葉と完全に一致しなくても、質問の意味を理解して関連する記事を表示することができます。そこでまずは、既存のヘルプ記事へのリンクを検索結果として表示するシンプルな仕組みから始めることにしました。
ただし、ここで問題になるのが、どのAI検索サービスを選ぶかという点です。現在は最適と思えるサービスでも、1年後にはより優れた選択肢が登場しているかもしれません。だからこそ、特定のサービスを使い続けることを前提とせず、将来的な変更にも対応できる仕組みを考える必要があります。
例えば、既存のヘルプ記事はWordPressで管理し、検索サービスを変更してもヘルプセンター全体を作り直さずに済むように連携部分を設計する方法があります。
この記事では、このプロジェクトを例に、小規模な試験導入から本格的な運用へと移行するまでの流れを見ていきます。また、開発・運用において自社で管理すべき要素や、AIツールや技術トレンド、外部サービスの変化に柔軟に対応できるサーバー環境の重要性についてもご紹介します。
確実な答えを待つ必要はない
例えば、開発担当者がAI検索サービスの比較を始めた矢先に、別のベンダーが新しい検索製品を発表したとします。それを知ったクライアントから「このサービスを待った方がいいのか」と相談されます。
その間も、サポートチームには同じ問い合わせが寄せられ、そのたびに該当するヘルプ記事のリンクを案内し続けています。
新しいサービスの導入を決める前に、まずは既存の検索機能で必要な記事が見つからない原因を調べることができます。例えば、ヘルプ記事がカスタム投稿タイプで管理されており、現在の検索設定では検索対象に含まれていない可能性があります。あるいは、記事では定期予約を「予約シリーズの管理」と表現しているものの、実際の利用者はそのようなキーワードで検索していないのかもしれません。
当然ながら、原因によって対処方法は異なります。たとえば開発担当者は、WordPressの検索機能がヘルプ記事を検索対象に含めているかを確認できます。コンテンツ担当者は、利用者が実際に使う言葉を記事に取り入れたり、どのバージョンのソフトウェアに対応した手順なのかを明確にしたりすることができます。
検索機能の検証には、最近のサポートへの問い合わせが役立ちます。実際に寄せられた質問をそのまま検索してみることで、利用者の検索語句を推測することなく、どこに問題があるのかを確認できます。サポートチームは各質問に対応するヘルプ記事も把握しているため、検索結果が適切かどうかも判断しやすくなります。
検索精度を高めるもう一つの方法が、セマンティック検索（意味検索）です。機械学習を活用し、検索語句と表現が異なっていても、意味の近いコンテンツを見つけることができます。例えば、「金曜日の予約を別の日に変更したい」という検索から、「定期予約の日程変更」に関する記事を見つけられるようになります。
ただし、検索技術だけで解決できるわけではなく、たとえば予約管理ソフトウェアの異なるバージョンについて説明した記事が複数ある場合、検索サービスがそれらを区別できるよう、記事側にも適切な情報が必要です。
このように、導入するサービスが決まっていなくても、既存のコンテンツの問題を解消することはできます。あらかじめ記事を整理し、実際の問い合わせに基づくテスト用の質問を用意しておけば、AI検索を試験導入する際にも、より正確に効果を検証できます。
コンテンツの管理は引き続きWordPressで
検索サービスを解約しても、クライアントのWordPressサイトからヘルプ記事が失われることはありません。記事の作成や編集は引き続きWordPressで行い、検索サービス側には、連携機能を通じて送信されたコンテンツのコピーが検索用のインデックスとして保存されます。
この仕組みは、将来的に検索サービスを切り替える際に重要になります。移行前のサービスからコンテンツを取り戻す必要がないよう、WordPressに保存された元の記事を使って、新しい検索インデックスを構築できるようにしておくことが大切です。
今回のヘルプセンターでは、カスタム投稿タイプを使って、ヘルプ記事と通常のブログ記事を分けて管理できます。また、カスタムフィールドやタクソノミーを利用すれば、各記事が対応する予約管理ソフトウェアのバージョンも明示できます。こうした情報もWordPress側で管理することで、コンテンツ担当者が記事とあわせて更新できるようになります。
検索インデックスを作成するコードは、記事の本文や関連するメタデータを検索サービスに送信します。その際、WordPressの投稿IDも紐づけておくことで、検索結果から正しいヘルプ記事にアクセスできるようにします。
ただし、検索サービス側に保存される設定にも注意が必要です。例えば、サービスの管理画面で類義語や検索結果の表示順位に関するルールを設定している場合、解約前にそれらの設定を別途エクスポートするか、記録しておく必要があります。一方、各記事がどのバージョンのソフトウェアに対応しているかといった重要な情報は、検索サービスだけに保存するべきではありません。
また、WordPressでの記事の更新を検索インデックスにも反映させる仕組みが必要です。コンテンツ担当者が古い手順を修正した場合、連携機能によって検索インデックス内の該当データも更新または削除しなければなりません。そうしないと、ヘルプセンターではすでに修正された古い情報が、検索結果に表示され続けてしまいます。
最初の試験導入では、一般公開されているヘルプ記事だけを対象にすることで、比較的シンプルな構成にできます。ただし、将来的に会員限定のドキュメントを追加する場合は、アクセス権限の管理も必要になります。閲覧制限のある記事を検索結果に表示したり、回答生成AIにその内容を送信したりする前に、WordPress側のアクセス制御ルールを適用しなければなりません。ユーザーがログインしているというだけでは、そのユーザーがどの記事を閲覧できるかまでは判断できないためです。
検索サービスの切り替えを容易にする設計
検索ボックスはWordPressテーマ内に設置したまま、検索サービスのAPIとの連携はプラグインで処理する構成が考えられます。テーマからプラグインに検索クエリを渡し、プラグインが検索サービスにリクエストを送信します。返ってきた検索結果もプラグイン側で、サイトが扱える形式に変換します。
例えば、検索サービスが返すドキュメントIDをWordPressの投稿IDに対応付けることができます。これにより、テーマ側ではWordPressに登録された記事タイトルやパーマリンクを使って、該当するヘルプ記事を表示できます。将来的に検索サービスを変更する場合も、主に連携部分を修正すればよく、ヘルプセンターのレイアウトはほぼそのまま維持できます。
ただし、開発工数を見積もるには、まず「AI検索」が具体的にどのような仕組みを指すのかを明確にする必要があります。
例えば、埋め込みを利用した検索では、モデルが記事のテキストを「埋め込みベクトル」と呼ばれる数値データに変換し、検索インデックスに保存します。ユーザーが検索すると、その検索語句も同じ形式のデータに変換され、意味的に関連性の高いコンテンツが検索されます。
さらに、検索で見つかった記事の一部を大規模言語モデル（LLM）に渡し、回答文を生成する仕組みを組み合わせることもできます。ただし、関連する記事へのリンクを表示するだけであれば、AIによる回答生成は必要ありません。
こうした機能は、マネージド検索サービスを利用してまとめて導入することも、複数のサービスを組み合わせて構築することもできます。いずれの場合も、サービスの変更がシステムのどの部分に影響するのかを、開発担当者が把握しておくことが重要です。
例えば、回答文を生成するモデルだけを変更するのであれば、既存の検索インデックスをそのまま利用できる場合が多くあります。一方、埋め込みモデルを変更する場合は、通常、記事の埋め込みベクトルを再生成し、検索インデックスを再構築する必要があります。また、検索結果の関連度を示すスコアの算出方法もサービスによって異なるため、既存のしきい値で適切な検索結果を抽出できるかどうかも検証しなければなりません。
参考になるのが、Andreessen Horowitzが2025年に実施した、企業のCIO（最高情報責任者）100名を対象とする調査です。この調査によると、5種類以上のAIモデルを利用しているCIOの割合は、前回調査の29%から37%に増加しています。今回の例では一つの検索サービスで十分かもしれませんが、将来的に別のサービスへ切り替える場合、どのような作業が必要になるのかを把握しておくことが大切です。
そのために、あらゆる検索サービスに対応できる大規模な仕組みを構築する必要はありません。小規模なプラグインでも、WordPressと外部サービスの連携部分を適切に分離することは可能です。重要なのは、将来のサービス変更時に必要な修正内容を把握し、作業工数を見積もれるよう、コードや設定を整理しておくことです。
試験導入の範囲を適切に設定する
まずは、予約管理に関する一般公開のヘルプ記事20本を対象にすれば、初期段階の検証に十分なコンテンツを確保できます。サポート担当者には、実際に顧客から寄せられた質問と、それぞれの質問に対応するヘルプ記事を用意してもらいます。
開発担当者は、これらの質問を既存の検索機能と試験導入するサービスの両方で検索し、結果を比較します。適切な記事が検索結果の上位に表示されるか、また、単発の予約変更と、それ以降のすべての定期予約の変更を正しく区別できるかなどを確認します。
テストには、ヘルプ記事に答えがない質問も含める必要があります。例えば、ソフトウェアが対応していない機能について検索された場合、単に言葉が似ているという理由で、無関係な操作手順が案内されることは避けなければなりません。
AIによる回答生成も試す場合は、検索精度とは別に、生成された回答の正確性も検証します。正しいヘルプ記事を参照していても、手順を誤って説明している可能性があるためです。サポート担当者が回答内容を確認し、その説明に従って実際に操作を完了できるかを確かめることが重要です。
試験期間を4週間に設定すれば、クライアントはそのサービスを継続利用するかどうかを判断できます。また、予算にも上限を設けておく必要があります。サービス側に利用料金の上限を設定する機能がない場合は、あらかじめ合意した予算を超えないよう、有料リクエストを停止する仕組みを用意します。メールによる通知だけでは課金を止められないため、事前の対策が欠かせません。
Deloitteが発表した「2026 State of AI in the Enterprise」調査によると、AIの試験的な取り組みの約40%を本番運用に移行できている回答者は、全体のわずか25%にとどまります。今回の試験導入でも、必ずしも期待どおりの成果が得られるとは限りません。その可能性も踏まえたうえで、導入の効果を見極めることが大切です。
利用増加に備える
試験導入で一定の成果が得られたため、クライアントは新しい検索機能を顧客向けニュースレターで紹介することにしました。しかし、サポート担当者数名が会議中に検索機能を試す程度では、多くの利用者がアクセスした際の動作までは確認できません。
例えば、WordPressプラグインが検索のたびに外部APIへ同期リクエストを送信する仕組みだとします。この場合、外部サービスからの応答を待つ間、PHPスレッドが占有されます。応答に時間のかかる検索が同時に複数発生すると、キャッシュされていない他のリクエストを処理する余力が減ってしまう可能性があります。
そのため、ニュースレターを配信する前に、複数の検索が同時に実行された場合の動作を検証しておくことが重要です。開発担当者は、検索結果が返されるまでの時間を測定するとともに、サイトの他の機能に影響が出ないかを確認します。また、外部サービスのAPIに設定されているリクエスト数の制限も、テストに含める必要があります。
利用料金についても同様です。一人の訪問者が複数回検索することも考えられます。また、AIによる回答生成を利用する場合は、モデルに送信するテキストと生成される回答の長さによって、トークン単位の料金が変わることがあります。そのため、訪問者数に検索1回あたりの料金を掛けるだけでは、正確な費用を見積もれません。試験導入中に記録した実際のリクエストデータを活用することで、より現実的な費用を算出できます。
また、検索インデックスの更新処理は、サイト訪問者による検索とは別に発生します。通常、一つのヘルプ記事を更新した場合は、その記事に対応するインデックスだけを更新すればよく、ヘルプセンター全体の埋め込みベクトルを再生成する必要はありません。コンテンツ担当者がWordPressで「更新」をクリックした際、使用するプラグインや検索サービスが実際にどのような処理を行うのか、開発担当者が確認しておくことが大切です。
機能の拡張も、必要性に応じて段階的に進められます。例えば、利用者が検索結果の記事リンクを活用している一方で、AIが生成した要約はほとんど読まれていない場合、セマンティック検索は維持しつつ、回答生成機能だけを無効にすることもできます。それぞれの機能を個別に設定できるようにしておけば、利便性を損なわずに運用コストを削減することが可能です。
サービスの見直しが必要になるタイミング
現在利用している検索サービスがAPIの提供終了を発表した場合は、切り替えに向けた対応が必要になります。一方、新しいAIモデルが発表されたからといって、すぐに乗り換えを検討する必要はありません。
ここでも、システムの各機能を分離しておくことが役立ちます。Web制作会社が特定のAIモデルを直接選択して利用している場合は、そのモデルの提供状況を継続的に確認する必要があります。一方、マネージド検索サービスでは、内部で使用するモデルの変更をサービス側が管理する場合もあります。その場合、制作会社はAPIに関する通知や検索結果の品質を監視することになります。
試験導入時に用意した質問は、その後の回帰テストにも活用できます。検索サービスに大きなアップデートがあった場合や、別のサービスへの切り替えを検討する際に、同じ質問で検索結果を比較します。期待する結果があらかじめ明確になっていれば、検索精度が改善したかどうかを具体的に判断できます。
例えば、定期予約の日程変更に関する質問では、現在の操作手順を説明した記事が引き続き検索結果の上位に表示されるかを確認します。AIによる回答生成を利用している場合は、単発の予約変更と定期予約全体の変更を正しく区別できているかも重要な確認項目です。
ただし、比較する際は、検索対象となるコンテンツの条件を揃える必要があります。一方のサービスでは先月の記事を使用し、もう一方では書き直した記事を使用していては、サービス自体の性能を正しく比較できません。テストの記録には、使用したコンテンツのバージョンや、関連するAIモデル、検索サービスの設定も残しておきます。
また、サポートへの問い合わせから新たな質問をテスト項目に追加することもできます。実際に利用者が困ったケースを反映することで、サービスを切り替える際にも、そのサイトにとって重要な検索機能が適切に動作するかを確認できます。
コストもサービスを見直す理由の一つです。例えば、生成される回答の正確性を維持できるのであれば、より低コストなAIモデルへの変更が適しているかもしれません。その判断には、一般的なベンチマークスコアよりも、クライアントの実際のヘルプ記事を使った検証結果の方が役立ちます。
変化に柔軟に対応できるサーバー環境を選ぶ
ステージング環境を利用すれば、本番サイトの検索機能を稼働させたまま、別の検索ツールの導入や動作検証を行うことができます。Kinstaでは、このような作業に利用できるステージング環境を提供しており、より多くのリソースが必要なテストには、プレミアムステージング環境も利用できます。
外部の検索サービスについても、本番環境とテスト環境を分離する必要があります。WordPressサイトを複製すると、本番環境の検索インデックスを参照するプラグイン設定までコピーされる場合があります。そのため、ステージング環境でインデックスの作成・更新処理を実行する前に、テスト用のインデックスと適切なアクセス権限を持つ認証情報を設定しておくことが重要です。これを怠ると、ステージング環境でのテストが本番サイトの検索結果に影響を及ぼす可能性があります。
また、KinstaのAPMツールは、WordPress側で発生するパフォーマンスの問題を調査する際に役立ちます。APMを有効にすると、サーバー側で実行される外部APIへのリクエストやデータベースクエリのうち、処理に時間がかかっているものを調査できます。一方、ブラウザ側から送信されるリクエストについては、ブラウザの開発者ツールなどを使った調査が必要です。APMですべてのブラウザリクエストを確認できるわけではありません。
APMのトレースデータを分析すれば、検索処理に時間がかかっている原因が、WordPress側での外部サービスからの応答待ちにあるのかを確認できます。外部サービスの応答自体が遅い場合、サーバーのリソースを増やしても、その応答時間を短縮することはできません。
一方、テストによってPHPの処理能力がボトルネックになっていることが判明した場合は、MyKinstaから、利用中のプランで選択可能な範囲でPHPリソースを調整できます。PHPスレッドを増やすと、より多くのリクエストを同時に処理できるようになります（同じメモリ容量をより多くのスレッドで共有することになるため、各スレッドが使用できるメモリは少なくなる）。また、パフォーマンスを正しく比較するには、ステージング環境のリソースやキャッシュ設定も、できる限り本番環境に近づける必要があります。
さらに、複数のサイトで試験導入を進める場合は、Kinsta APIを活用して、環境情報の取得やステージング環境の作成を自動化できます。これにより、外部の検索サービスにサーバーアカウントの管理権限を与えることなく、社内ツールからテスト環境を準備できます。
最終的に、新しい検索サービスの性能が本番環境への導入に十分かどうかを判断するのは、Web制作会社です。サーバー環境は、その判断に必要な検証や、テスト結果の分析を支える役割を担います。
提案書で明確にしておくべきこと
「AI検索の導入」という説明だけでは、作業範囲について認識のずれが生じる可能性があります。制作会社は関連するヘルプ記事へのリンクを表示する機能を想定していても、クライアントは質問に対して回答文を生成するチャットボットを期待しているかもしれません。
そのため、提案書には、利用者が実際にどのような機能を使えるようになるのかを具体的に記載することが重要です。今回のプロジェクトであれば、まずは一般公開されている20本のヘルプ記事を対象としたセマンティック検索の導入を提案し、AIによる回答生成機能については別途検討する形が考えられます。
また、以下の点を明確にしておくと、作業範囲や責任の所在について認識を揃えやすくなります。
-
試験導入で解決したい課題は何か：利用者が予約管理に関する最新の操作手順を見つけられないことが課題。実際にサポートへ寄せられた問い合わせをもとに、検証に使用する検索語句を決める。
-
クライアント側で管理するものは何か：ヘルプ記事の原本とメタデータはWordPressで管理。検索サービスの管理画面でしか設定できない項目については、制作会社側で内容を記録しておく。
-
外部サービスに依存する範囲はどこか：ヘルプセンターの検索機能と、そこから呼び出すAIモデルのAPIなど、外部サービスに依存する部分を提案書に明記。サイトのその他の部分では、引き続き既存の検索機能を使用する。
-
試験導入を終了するにはどうするか：設定を切り替えるだけで、既存の検索機能に戻せるようにする。また、終了時には定期的なインデックス更新処理を停止し、不要になった有料サービスも解約する手順を用意する。
-
本格導入に進むための判断基準は何か：どのような検索結果を適切とみなすか、検索結果の表示までに許容できる時間はどの程度かを、あらかじめクライアントと合意しておく。また、試験期間中の利用状況をもとに、継続運用にかかる費用を見積もる。
本格導入に進む場合は、残りのヘルプ記事のインデックス作成や、アクセス増加を想定した負荷テストなども必要になります。これらの作業を試験導入とは分けて見積もることで、クライアントは検証結果を確認したうえで、追加投資を判断できます。
さらに、4週間の試験期間が終了した時点で、誰が結果を評価し、継続の可否を判断するのかも提案書に明記しておくのがおすすめです。判断する担当者やタイミングが決まっていないと、十分な検証が行われないまま、次の契約更新を迎えてしまう可能性があります。
将来の選択肢を残しておく
今回の予約管理ソフトウェア会社の例では、今後5年間使い続ける検索サービスを決めなくても、セマンティック検索によって利用者が必要なヘルプ記事を見つけやすくなるかどうかを検証できます。
元のヘルプ記事は引き続きWordPressで管理します。試験導入で期待した成果が得られなかった場合も、改善した記事はそのまま残し、検索機能を元に戻すことができます。十分な効果が確認できた場合は、その結果を根拠に本格導入を提案できます。
もちろん、将来的に検索サービスを変更する際には、一定の作業が必要です。APIとの連携部分を修正し、検索結果が適切かどうかを改めて検証しなければなりません。変更内容によっては、検索インデックスの再構築に時間や追加費用がかかることもあります。ただし、こうした処理をサイトの他の機能から切り離しておけば、必要な作業や費用を見積もりやすくなります。
クライアントにとってもこれは大きなメリットです。現時点で何を導入し、どこまで費用をかけるのか、また、将来別のサービスを選ぶ場合にどのような対応が必要になるのかを、あらかじめ明確にできます。
KinstaのWordPress専用マネージドクラウドサーバーでは、こうした判断を支えるステージング環境やパフォーマンス分析ツールをご利用いただけます。クライアントのニーズが変化しても柔軟に対応できる環境を整えることで、将来の選択肢を狭めることなく、今必要なAI機能の導入を進められます。
