Blog

検索—自分でやらなければならないまで、実装することがたくさんあるとは想像もできません。ヘッドレスCMSを使用する場合の既知の検索機能の課題とその解決方法は何ですか？

コンテンツに焦点を当てたすべてのWebサイトまたはアプリケーションは、検索機能を提供する必要があります。ヘッドレスコンテンツ管理システムの導入により、検索を実装すると、準備が必要な新しい課題が発生します。この記事では、これらの課題とは何か、そしてそれらにどのように対処できるかを探ります。

ヘッドレスCMSにより、コンテンツをさまざまな場所で公開できます。また、コンテンツをモジュール化できるため、コンテンツインスタンスを表示される場所ごとに複製する必要がありません。私たちの目標は、次のことができる堅牢な検索を提供することです。

• コンテンツが表示される場所を見つけて表示する
• どこでも最新の状態

コンテンツの実際の検索とインデックス作成を処理する外部検索インデックスとしてAlgoliaを使用します。また、検索インデックスは、編集者がKontentで行ったコンテンツの変更と自律的に同期されるため、訪問者には常に最新のコンテンツが表示されます。

検索に「ただ」外部サービスを使用することは不必要な余分なステップのように思えるかもしれませんが、複雑なコンテンツ構造を処理する必要があるエンタープライズレベルの検索ソリューションを実装する場合、これが実際に推奨されるアーキテクチャである必要があることを説明します。使用される言語はいくつでもあり、優れたパフォーマンスと安定性が必要です。

ヘッドレスCMSに保存されているコンテンツのインデックス作成

ヘッドレスコンテンツとその構造を操作する場合の主な違いは、検索インデックスでコンテンツにインデックスを付ける方法にあります。 Kontentのコンテンツモデルと、検索インデックス内に作成することを決定した構造との間の変換を意味します。この変換プロセスは検索専用ではありませんが、コンテンツの推奨事項やパーソナライズを実装する場合（基本的に、コンテンツインベントリとサードパーティのデータストレージサービス間でコンテンツを同期する場合）、非常によく似た課題に直面する可能性があります。

大規模なプロジェクトのコンテンツ構造は複雑になる傾向があります。多くの場合、コンテンツは非常にモジュール化されています。つまり、階層的であり、さまざまなコンテンツがインベントリ全体で再利用されます。また、多言語または地域固有であるため、コレクションだけでなく、 さまざまな言語のバリエーションを操作することになります。さらに、定期的なコンテンツ制作は業界標準になっているため、コンテンツの一部は非常に動的になり、編集者は新しいコンテンツを頻繁に制作する可能性が高くなります。

推奨されるすべてのコンテンツモデリングのベストプラクティスに従うと、ヘッドレスCMSで作成したコンテンツモデルが検索シナリオにあまり適合していないことがすぐにわかります。心配しないでください、本当にそうすべきではありません。典型的なコンテンツモデルは通常、従来の検索ソリューションが処理するように設計されているよりも洗練されています。次の段落は、インデックス作成の課題に取り組む方法と、複雑なコンテンツモデルの検索機能を実装するときに注意すべき点を理解するのに役立ちます。

モデル化されたものと提示されたものは何ですか？

従来のCMSは、ページを操作するように構築されています。ページには構造があり、事前定義された方法で特定のURLに表示されます。ページがモジュール式でさまざまなもので構成されている場合でも、プレゼンテーション層（つまり「ヘッド」 ）がシステムの他の部分と結合されているため、何をどこでどのようにレンダリングするかを簡単に確立できます。ヘッドレスCMSでは、プレゼンテーション層がコンテンツ構造から切り離されているため、完全なコンテンツ構造に関する情報があるにもかかわらず、CMS自体はどのコンテンツがどこに表示されているかを知る方法がありません。このプレゼンテーション情報の欠如は、コンテンツモデルのどの部分で情報が実際に見つかるかを気にしないため、コンテンツのインデックス作成に関連する基本的な課題の1つです。本当に必要なのは、訪問者が見つけようとしているコンテンツにナビゲートするために、情報がWebサイトまたはアプリケーションに表示されているすべての場所を見つけることです。

実際には、モデルとプレゼンテーション層の間に完全な切断があることはめったにありません。開発とコンテンツ編集を容易にするためにさまざまな方法がよく使用されるため、多くのプロジェクトには、ページなど、プレゼンテーションまたは実装構造を具体的に参照するコンテンツタイプが含まれています。 または、一部のタイプには、URLスラッグや特別な分類法など、ナビゲーションに使用される特別な要素が含まれます。この構造情報をインデックス作成の取り組みに活用します。

「シンプルな」アプローチ

ヘッドレスCMSのコンテンツ構造をミラーリングすることにより、ヘッドレスで検索を実装する簡単な（単純な）方法があります。一部の競合他社は、これを、提供されている検索エンドポイントを備えたすぐに使用できる機能として提示しています。いくつかの単純なシナリオでは、このアプローチは実際に正常に機能し、機能する検索を生成できます。これらのシナリオのコンテンツ構造はフラットである必要があり（たとえば、単純なブログ投稿の検索）、前のセクションに戻って、レンダリングされたページに簡単に変換する必要があります。簡単な例を簡単に見てみましょう。

上の画像で視覚化されArticleコンテンツタイプを使用しているとしましょう。私たちは、訪問者がそのような記事のリストを検索できるようにしたいだけです。コンテンツモデル自体（左側）にもいくつかのリンクされたコンテンツプロパティ（つまり、作成者に関する詳細）が含まれている場合がありますが、そのようなコンテンツを検索機能に含めたくないと判断することは十分にできます。訪問者がフレーズを検索するときはいつでも、検索インデックスは受信したクエリに基づいて記事を一覧表示できるため、これはうまく機能します。

ここで、検索インデックスを常に最新の状態にしたいので、コンテンツの同期についても説明する必要があります。上記の単純なアプローチは、通常の変更通知システム（Webhookなど）でうまく機能します。新しい記事がCMSによって公開されたことが通知されたときはいつでも、基本的にそのまま、または最小限の変換作業で、検索インデックスに追加するだけで済みます。同じことが、既存のコンテンツの非公開または変更にも当てはまります。何を変更する必要があり、それをどのように達成するかは常に明確です。

シンプルでフラットなコンテンツの検索は簡単です。しかし、コンテンツがより洗練されると、検索アプローチもより洗練される必要があります。

モジュラーコンテンツはどうですか

モジュラーコンテンツを含めたい場合、つまり、複数のアイテムをリンクしてページに表示される最終的なコンテンツを構成したい場合、上記の単純なアプローチではもはや十分ではありません。すべてのコンテンツアイテムを個別のエンティティとして検索インデックスに転送するだけだとしましょう。それでもすべてのアイテムを検索することはできますが、結果は、上記のクエリに一致するさまざまなコンテンツアイテムで構成されます。現在モジュラーコンテンツを扱っているため、結果コンテンツアイテムが実際にウェブページのどこに表示されているかについての情報がない可能性があり、その結果、訪問者を見つけたコンテンツにナビゲートできない可能性があります。そのような検索結果は通常かなり役に立たないです。

この問題を示すために、別のより複雑な例を見てみましょう。

Feature use-case 、 testimonial 、 case study 、 partnerなど、さまざまなコンテンツタイプへのリンクが含まれています。検索インデックスの構造をミラーリングし、検索クエリの結果としてpartnerコンテンツアイテムを取得した場合、このコンテンツは実質的にどこにでもレンダリングできるため、Webサイトのどこに実際に表示されているかはわかりません。

最も簡単な解決策は、（単純なアプローチのように）ナビゲートできるアイテムのみにインデックスを付け、リンクされたすべてのモジュラーコンテンツをそれに埋め込むことです。これは検索自体には機能しますが、そのような構造を最新の状態に保ち、CMSと同期させようとすると、別の課題が発生します。

モジュラーコンテンツの同期

モジュラーコンテンツを使用すると、コンテンツを複数の場所で再利用できます。このiscontentがどこで使用されているかをどうやって知ることができますか？

基本的な通知の原則は、モジュラーコンテンツにも適用されます。変更があるたびに、どのモジュラーコンテンツがどのように変更されたかが通知されます。ただし、特定のコンテンツアイテムがどこからリンクされているかについての情報は受け取りません。検索インデックスを効率的に同期できるようにするには、変更されたモジュラーコンテンツが存在するすべての場所を検索し、それらを一度に部分的に更新できる構造を導入する必要があります。そうすれば、インデックスは常に最新の状態に保たれます。

一部のプロジェクトでは、すべてのアイテムがどこからリンクされているかを示すコンテンツインベントリマップを利用しています。ただし、非常に大規模なコンテンツインベントリ用にこのようなマップを作成、維持、および更新することは、複雑な作業です。

私たちが提案する解決策は、前述のマップとして機能できるように検索インデックスをモデル化することです。変更通知が来るたびに、インデックス付きの構造自体が、インデックスのどの部分を更新するかを決定します。これにより、提示されたすべての問題が解決されるだけでなく、検索インデックスへの負担が軽減されます。

推奨される検索インデックス構造

要約すると、次の重要な要件を満たすように検索インデックスをモデル化する必要があります。

• インデックス付けされたすべてのアイテムは、訪問者が特定のアイテムのコンテキストで検索できるようにするすべてのコンテンツ（たとえば、コンポーネントおよびリンクされたアイテムのすべてのコンテンツ）を埋め込む必要があります。
• インデックスに登録されたすべてのアイテムに移動できる必要があります（たとえば、アイテムをURLにマップする）。
• コンテンツが複数の異なるアイテムに埋め込まれている場合でも、実際の配置に関する情報がなくても、コンテンツを部分的に更新できる必要があります。

このような検索インデックスをモデル化する方法は次のとおりです。

コンテンツモデルの特定の部分を省略することもできます（たとえば、ここでcase study
最も重要なことは、含まれている各埋め込みアイテムに関するメタ情報を保持することです。これにより、更新のリクエストがあったときに、特定のコンテンツアイテムのすべてのオカレンスを検索できます。

モジュラーコンテンツの更新のリクエストがある場合、Algoliaでは正確なファセット値を検索できるため、検索インデックス自体がそれを処理し、埋め込まれたコンテンツアイテムのすべてのコピーを更新できることがわかります。

変換プロセスの次のステップは、コンテンツ階層をフラット化して、インデックス付きの構造を均一に検索できるようにすることです。簡単に言えば、コンテンツがコンテンツモデルのどの深さまで存在するかはあまり気にしません。重要なのは、トップレベルページのどこかに表示されることだけです。

説明されている原則に従ってモデル化された実際の検索インデックスアイテムのスクリーンショットを次に示します。

この特定のコンテンツアイテムの元のコンテンツタイプは、実際には非常に階層的です。ここでは、検索インデックスでモデル化するために2レベルの階層のみを使用しています。トップレベルには、URL（ slugプロパティを介して）とすべての標準コンテンツアイテムメタデータを含むアイテムがあるため、特定の言語またはコレクションを操作できます。さらに、 contentプロパティの下に、アイテムの実際のコンテンツ、およびリンクされているすべてのアイテムとそのコンテンツを表示できます。コンテンツ自体（この場合、各アイテムのリッチテキストとテキストプロパティの連結）がcontents プロパティ。これは、訪問者が実際に検索しているプロパティの1つでもあります。その上で、我々はまだ我々は（一致による具体的な内容一片見つけるために使用できる他のすべてのメタデータが持っているcontent.codename 、およびcontent.languageプロパティ）。

検索と同期

これで、この構造を全文検索に使用する場合、各アイテムのcontent.contentsすべてのモジュラーコンテンツが埋め込まれたトップレベルのコンテンツアイテムのテキストコンテンツのみ。

このアプローチは、モジュラーコンテンツとその同期に関する問題にも対処します。このようなモデルでは、新しい変更要求が来るたびに、変更されたコンテンツアイテムを含むトップレベルのアイテムを見つけるのが非常に簡単になります。 content配列で更新されたアイテムのコードネームと言語を持つアイテムを検索しているだけで、変更する必要のある親アイテムのリストがすぐに表示されます。 Algoliaは部分的な更新も提供しているため、変更された部分だけを変更することが可能であり、インデックスは常に最新の状態になります。

やってみよう

実際に、KontentとAlgoliaの統合例を作成しました。リポジトリは、GitHubで確認できます。例には次のものが含まれます。

• 簡単なドキュメント
• 初期インデックス同期のためのサーバーレス機能
• 部分的なコンテンツ更新のためのサーバーレス機能
• KontentUIから直接新しく構築された検索を試すことができるカスタム要素

テストするには、Algoliaアカウントのみが必要です。このアカウントは、 ここから無料で入手できます。

この統合により、検索を構築してすぐにテストできます。これにより、複数の言語とモジュラーコンテンツがすぐにサポートされます。質問がある場合、または他のKontent開発者とチャットしたい場合は、試してみて、 Discordでお知らせください。