【ITニュース解説】38 recipes, seven conditions, and the seven collection pages we did not build

Munchableというサービスは、手作りのレシピライブラリを公開しており、現在は38種類のレシピを提供している。これらのレシピは、それぞれが「お腹の調子」に関する7つの特定の条件（例えば、低FODMAPや逆流性食道炎向けなど）に適合するかどうかをチェックされている。このチェックは、Munchableのモバイルアプリ内でバーコードをスキャンする際に使われるのと同じルールエンジンが実行しており、ウェブサイトとアプリで一貫した結果が得られるようになっている。各レシピページは独立して公開され、それぞれが固有の検索キーワード（いわゆるロングテールキーワード）で検索エンジンに認識され、ランク付けされることを目指している。

通常、このようなレシピライブラリを公開する場合、検索エンジン最適化（SEO）の一般的なセオリーとしては、「低FODMAPレシピ」や「逆流性食道炎レシピ」といった、条件ごとの「コレクションページ」を7つ作成することが考えられる。これらのページは、それぞれの主要な検索キーワード（ヘッドターム）で上位表示を目指し、サイト内の関連レシピへの内部リンクのハブとして機能することが期待される。しかし、Munchableはこれらの7つのコレクションページを作成しなかった。これには明確な理由があり、システム設計やコンテンツ戦略を考える上で非常に重要な学びがある。

コレクションページを作成しなかった主な理由は、各条件に適合するレシピリストの「重複（オーバーラップ）」が非常に大きかったからだ。例えば、38種類のレシピのうち37種類が低FODMAPに適合し、最も適合レシピが少ない条件でも30種類が該当した。これは、7つの異なるコレクションページを作るというよりも、実際にはほとんど同じ内容のリストを7つの異なる見出しで表示するに過ぎない状況だった。検索エンジンはこのような「重複に近いコンテンツ」を非常に高く認識する。もし、ほとんど同じ内容の7つのページを作成していたら、検索エンジンはそれらを別々の価値あるページとは見なさず、検索結果のランキングが分散したり、サイト内のページ評価（内部リンクエクイティ）が薄まったりする可能性があった。また、検索エンジンがサイトを巡回する「クロールバジェット」という貴重なリソースを、すでに見た内容とほとんど変わらないページを読むために無駄に消費させてしまうことにもつながる。

この問題を避けるため、Munchableはコレクションページを作成する前に、「このリストが、それを見た読者が別のリストを見ても何か新しいことを学べるほど十分に異なるか？」という基準を設けた。現在の38レシピの規模では、この基準を満たさないと判断したのである。この判断は、「レシピライブラリが十分に大きくなり、条件ごとのリストが本当に異なる内容になったときに、コレクションページを構築する」という具体的な将来計画に繋がっている。例えば、レシピが300種類に増え、低FODMAPに適合するものが210種類、ガストロパレーシス（胃不全麻痺）に適合するものが60種類といった具合に、リスト間の内容が明確に異なる状態になれば、その時にコレクションページは価値を持つと判断される。

コレクションページの代わりにMunchableが採用したのは、レシピインデックスページでレシピを「食事タイプ」（朝食、昼食、夕食、おやつなど）でグループ化する方法だ。一つのレシピは複数の食事タイプに属することができるが、「朝食レシピリスト」と「夕食レシピリスト」は内容が大きく異なるため、重複の問題は生じない。条件ごとのレシピへの関連付けは、既存の「条件ガイドページ」から関連するレシピページへリンクを張り、逆に各レシピページからも適合する条件ガイドページへリンクを張ることで実現している。これにより、すでに主要キーワードでランク付けされている条件ガイドページがハブとして機能し、新たな重複に近いハブページを作成する必要がなくなった。

各レシピページに表示される「このレシピが誰に合うか」というブロックの情報は、手動で入力されているわけではない。これは、本番環境のルールエンジンがレシピデータを基に自動的に計算して生成されている。具体的には、toProduct(recipe)という関数を使ってレシピデータを、アプリがスキャンする製品データと同じ形式に変換する。これにより、ウェブサイトとアプリの両方で同じコードパス（処理手順）を使って適合性をチェックできるため、レシピの適合性に関する判断が食い違うことが絶対にない。つまり、ウェブサイトとアプリで全く同じ情報源から情報を得ているため、情報の信頼性が非常に高くなる。

さらに、この適合性チェックでは、例えば乳糖不耐症の「敏感度」設定をアプリで提供されている最も厳しい「高感度（sensitivity: 'high'）」に設定して結果を出している。これは、公開ページにはユーザーの個人プロファイルがないため、誰が見ても最も厳しい基準で判断された結果を表示することで、万が一アプリで「注意」と判断されるようなレシピをウェブページで「適合」と表示してしまうという矛盾を防ぐためである。ウェブサイトで「乳糖不耐症に適合」と書かれていても、アプリでは「注意」と表示されるような状況は、ユーザーの信頼を損ねてしまうため、これを避けるための重要な設計判断と言える。

アプリとウェブサイトで同じデータとエンジンを使っていながらも、情報の表示方法（インターフェース）が異なる点も重要だ。アプリ内では、ユーザーのプロファイルに基づいてレシピライブラリ自体がフィルタリングされているため、表示されているレシピはすでにユーザーに適合するものである。そのため、個々のレシピに対して改めて「適合/不適合」の評価（verdict）を表示するのは冗長であり、アプリがすでに下した決定と「議論している」ように感じられる可能性がある。一方、ウェブサイトの訪問者にはプロファイルがないため、「低FODMAPパターンに適合」といった表示は、その情報を求めて検索してきたユーザーにとって、レシピがどのようなものかを示す「指標ラベル」として不可欠となる。これは、同じ共有コンポーネントを使う場合でも、再利用すべきは「データ」なのか「インターフェース」なのかを、利用者の「コンテキスト（状況）」に応じて慎重に判断する必要があることを示唆している。

レシピが適合する条件を表現する際にも工夫が見られる。多くのレシピが7つの条件のうち6つまたは7つに適合するため、適合する全ての条件を列挙すると、表示が長くなり読みにくくなる。そこで、Munchableでは「最も短い真実」を伝えるアプローチを採用した。これは、適合しない条件が少ない場合（例えば1つか2つ）は、「ガストロパレーシスを除く全ての7つの条件に適合」というように、例外を先に述べる表現を使う。この方が、適合する6つの条件を全て列挙するよりも短く、かつガストロパレーシスの読者にとっては除外されている情報が明確にわかるため、より有用な情報となる。また、条件名を結合してリストを作成する際に、条件名自体にカンマが含まれていると、読者が条件数を誤解する可能性があるため、適切なラベルを使用するように修正するという細かい配慮もなされている。

さらに、検索結果に表示される「メタディスクリプション」も手書きではなく、ページの内容と同じ構造から自動生成されている。手書きのメタディスクリプションは、ページ内容が変更された際に更新が漏れる「メンテナンスの罠」になりがちだが、自動生成することで、レシピの概要、調理時間、提供人数、適合条件といった情報が常にページの内容と一致し、最新の状態を保つことができる。これにより、検索結果のスニペットもページ内容と同期して更新され、情報の正確性が保証される。Munchableのウェブサイトは完全に静的に生成されており、データもリポジトリに組み込まれているため、高いパフォーマンスと安定性を実現している。

最後に、Munchableのレシピライブラリは、意図的に「全てが完璧に適合する」内容にはなっていない。例えば、ある鮭料理は胆汁酸吸収不良症には「避けるべき」とされ、あるオートミールはガストロパレーシスには「注意」とされている。全てのレシピがあらゆる条件に適合するように作るのは簡単だったかもしれないが、それをしなかった。なぜなら、全てが適合するリストは、実際には何もチェックされなかったリストと見分けがつかないからだ。一部に適合しないレシピを含めることで、このライブラリが実際に厳密なチェックを受けているという信頼性を読者に与え、より実践的で学びのある情報を提供しているのである。このアプローチは、コンテンツの信頼性を高める上で非常に重要な戦略と言える。