2026年のディレクトリ&マーケットプレイスサイト向けベストテックスタック
ディレクトリとマーケットプレイスサイト向けのベストテックスタック
ほとんどの「ベストテックスタック」の記事は、誰かが午後の数時間Product Huntを閲覧して、その結果を書き上げたように読める。Reactとおそらく Postgres を使い、Stripe を追加して、完了と言う。それは、137,000 のリスティングページをレンダリングする必要があり、50マイル半径内のジオサーチをサポートし、自然言語クエリを使用してユーザーが結果を見つけられるようにするディレクトリウェブサイトを構築しようとするときは役に立たない。
私は過去 2 年間、まさにこれらの種類のサイトを構築してきた。おもちゃのプロジェクトではなく、数十万件のレコードを扱う本番のディレクトリおよびマーケットプレイスプラットフォーム、複数国の決済処理（ゼロ小数点通貨のような楽しい端事例を含む）、全文検索、セマンティック AI、地理クエリを同時に組み合わせる検索システムである。この記事では、Social Animal で使用しているスタックのすべてのレイヤーについて、各部分を選択した理由、およびそれらの決定をサポートする本番データについて説明します。
目次
- ディレクトリとマーケットプレイスサイトが建築的にユニークな理由
- 10 層スタック概要
- レイヤー 1: フロントエンド -- Next.js 15
- レイヤー 2: データベース -- Supabase PostgreSQL
- レイヤー 3: 認証 -- Supabase Auth
- レイヤー 4: 決済 -- Stripe Connect
- レイヤー 5: 検索 -- トリプル検索パターン
- レイヤー 6: メディア -- Supabase Storage + Next.js Image
- レイヤー 7: ホスティング -- Vercel
- レイヤー 8: メール -- Brevo API
- レイヤー 9: AI -- Claude API
- レイヤー 10: 監視 -- Vercel Analytics + PostHog
- フルスタック比較表
- 本番環境でのこのスタックのコスト
- FAQ
ディレクトリとマーケットプレイスサイトが建築的にユニークな理由
ディレクトリおよびマーケットプレイスウェブサイトは、表面上はシンプルに見える。何かをリストアップし、人々が検索できるようにし、おそらく支払いを処理する。しかし、実際のデータで構築を開始すると、標準的な SaaS アーキテクチャがあなたを準備していない問題にぶつかる。
まず、ページ数の問題がある。100K 以上のリスティングを持つディレクトリには、100K 以上のページが必要である。すべてをリクエストのたびにサーバーレンダリングすることはできず、ビルド時にすべてを静的に生成することもできない（ビルドに数時間かかる）。より賢いもの -- Incremental Static Regeneration（ISR）またはオンデマンド再検証が必要である。
第二に、検索は多次元である。ユーザーはテキスト（「家族療法士」）、意味（「関係不安を助ける誰か」）、および位置（「オースティンから 20 マイル以内」）で検索したい。ほとんどのスタックはこれらのいずれかを処理する。これら 3 つすべてを同時に処理するには、特定のデータベースアーキテクチャが必要である。
第三に、マーケットプレイスは単純なチェックアウトをはるかに超える支払いの複雑さを持っている。プラットフォーム手数料、サブスクリプション階層、マルチ通貨価格設定、国間の規制上の違いを扱っている。これらのいずれかを誤ると、お金を失うか法律を破るかのどちらかである。
これらの制約は、スタック内のすべての決定を形作った。各レイヤーを説明しよう。
10 層スタック概要
深く掘り下げる前に、ここに全体像がある：
| レイヤー | ツール | 理由 |
|---|---|---|
| フロントエンド | Next.js 15 (App Router) | 100K+ ページの ISR、サーバーコンポーネント |
| データベース | Supabase PostgreSQL | pgvector + PostGIS + 1 つの DB 内の全文検索 |
| 認証 | Supabase Auth | 行レベルセキュリティ、ロールベースのアクセス |
| 決済 | Stripe Connect | マーケットプレイス手数料、マルチ通貨 |
| 検索 | トリプルパターン (tsvector + pgvector + PostGIS) | テキスト + セマンティック + ジオ同時実行 |
| メディア | Supabase Storage + Next.js Image | 最適化された配信、シンプルなアップロード |
| ホスティング | Vercel | エッジ展開、ISR サポート、プレビュー URL |
| メール | Brevo API | API ルートからのトランザクションとマーケティング |
| AI | Claude API | セマンティック検索、コンテンツ拡張、チャットボット |
| 監視 | Vercel Analytics + PostHog | トラフィック + ユーザー動作追跡 |
ここのすべてのレイヤーは、複数のプロジェクト全体で本番環境で実行されている。それが実際にどのようなものであるかを示す。
レイヤー 1: フロントエンド -- Next.js 15
ディレクトリサイトは Next.js と Astro の両方で構築している。どちらも優れている。しかし、ディレクトリとマーケットプレイスの場合、Next.js 15 with App Router が勝つ理由は 1 つの機能である：Incremental Static Regeneration。
これが実際のシナリオである。私たちのディレクトリプロジェクトの 1 つは 137,000 のリスティングページをレンダリングする。別のものは 91,000 を扱う。これらすべてをビルド時に静的に生成することはできない -- ビルドに永遠に時間がかかり、Vercel の関数実行制限を超えてしまう。そして、すべてのリクエストにおいてサーバーレンダリングすることはできない。サーバーコストは莫大になり、Time to First Byte が低下する。
ISR は両方の最高のものを与える。ページへの最初の訪問者がサーバーレンダリングをトリガーし、これはエッジでキャッシュされる。その後の訪問者は静的バージョンを取得する。再検証間隔を設定し（リスティングページに対しては通常 3600 秒を使用）、キャッシュはバックグラウンドで更新される。
// app/listings/[slug]/page.tsx
export const revalidate = 3600; // 1時間ごとに再検証
export async function generateStaticParams() {
// 最も訪問数の多い上位 1000 件のリスティングのみを事前生成
const { data } = await supabase
.from('listings')
.select('slug')
.order('view_count', { ascending: false })
.limit(1000);
return data?.map((listing) => ({ slug: listing.slug })) ?? [];
}
export default async function ListingPage({ params }: { params: { slug: string } }) {
const { data: listing } = await supabase
.from('listings')
.select('*, categories(*), reviews(*)')
.eq('slug', params.slug)
.single();
// サーバーコンポーネント -- このために客側に React をシップしない
return <ListingDetail listing={listing} />;
}
サーバーコンポーネントはもう 1 つの大きな勝ち。リスティング詳細ページはほとんどが静的コンテンツ -- 名前、説明、写真、レビュー。それのために React のランタイムをクライアントに送信する理由はない。サーバーコンポーネントはサーバーで レンダリングされ、純粋な HTML を送信する。リスティングページは高速に読み込まれ、JavaScript バンドルは小さいままである。
クライアントコンポーネントは控えめに使用する：検索バー、インタラクティブマップ、ブッキングフォーム、およびユーザーインタラクションが必要な何か。他のすべてはサーバーに留まる。
Astro を使用しない理由
Astro は、相互作用が最小限のコンテンツ指向のディレクトリに適している。ドキュメンテーションサイトとコンテンツ指向のプロジェクトで使用している。しかしマーケットプレイスサイトは認証済みの状態、リアルタイム機能、および複雑なフォームが必要である。Next.js はこれらをより自然に処理する。ディレクトリがほぼ読み取り専用の場合（例えば、静的ビジネスディレクトリの考え）、Astro は考慮する価値がある -- Astro 開発機能を確認する。
レイヤー 2: データベース -- Supabase PostgreSQL
これはスタック内で最も独創的な選択であり、最も自信を持っている選択である。Supabase は PostgreSQL とそのすべての拡張機能を提供する -- ディレクトリ/マーケットプレイスサイトの場合、3 つの拡張機能が極めて重要である：pgvector、PostGIS、および PostgreSQL の組み込み全文検索。
私たちのディレクトリプロジェクト全体で、Supabase で 253,000 以上のレコードを管理している。これにはリスティング、ユーザープロフィール、レビュー、ブッキング、およびサブスクリプションデータが含まれる。PostgreSQL はこれを息吹かずに処理する -- 桁違いに大きいデータセット用に設計されている。
本当の洞察はこれである：全文検索、ベクトル埋め込み、および地理データを同じデータベース内に保つことで、複数のサービス間でデータを同期するアーキテクチャの複雑さを避ける。テキスト検索に Elasticsearch は不要。ベクトル検索に Pinecone は不要。別のジオサービスは不要。1 つのデータベース。1 つの真実のソース。
-- テキスト検索、ベクトル類似性、およびジオ近接を組み合わせる単一クエリ
SELECT
l.id,
l.name,
l.description,
ts_rank(l.search_vector, plainto_tsquery('english', 'family therapist')) AS text_rank,
1 - (l.embedding <=> $1::vector) AS semantic_similarity,
ST_Distance(
l.location::geography,
ST_MakePoint(-97.7431, 30.2672)::geography
) / 1609.34 AS distance_miles
FROM listings l
WHERE
l.search_vector @@ plainto_tsquery('english', 'family therapist')
AND ST_DWithin(
l.location::geography,
ST_MakePoint(-97.7431, 30.2672)::geography,
80467 -- メートル単位の 50 マイル
)
ORDER BY
(text_rank * 0.3) + (semantic_similarity * 0.5) + ((1 - distance_miles/50) * 0.2) DESC
LIMIT 20;
それは 1 つのクエリ。全文ランキング、セマンティック類似度スコアリング、および地理距離フィルタリング -- すべて PostgreSQL で起こっている。3 つの別々のサービス全体でそれを実行してから結果を首尾一貫させるようにしてみる。
ディレクトリのデータベースオプションに関するより深い情報については、ヘッドレス CMS およびデータベース比較を参照。
Supabase 行レベルセキュリティ
RLS は独自の言及に値する。マーケットプレイスバックエンドを困らせる問題を解決するため：データベースレベルでのデータアクセス制御。すべての API エンドポイントで認可チェックを記述する代わりに、データベース自体のポリシーを定義する。
-- セラピストは独自のクライアントレコードのみを表示できます
CREATE POLICY "therapists_own_clients" ON client_records
FOR SELECT USING (
auth.uid() = therapist_id
OR auth.jwt() ->> 'role' = 'admin'
);
API コードにバグがあり、誤ってクエリを公開しても、RLS は不正なデータアクセスを防止する。機密ユーザーデータを扱うマーケットプレイスサイトの場合、これは必須である。
レイヤー 3: 認証 -- Supabase Auth
データベース用に Supabase エコシステムに既にいるため、Supabase Auth を使用することは自然な選択である。しかし、マーケットプレイス用にそれを使用する本当の理由は、RLS と直接統合されるロールベースのアクセスである。
私たちのマーケットプレイスプロジェクトの 1 つは、3 つの異なるユーザータイプ全体でロールベースの認証を実行している：管理者、サービスプロバイダー、およびクライアント。各ロールは異なるデータを表示し、異なる許可を持ち、異なる機能にアクセスする。別のプロジェクトでは、各階層がプログレッシブにより多くの機能をロック解除する 4 階層のメンバーシップシステムを実行している。
実装は、ユーザーのロールを JWT メタデータに保存する。つまり、RLS ポリシーは追加のデータベースクエリなしでそれを参照できる：
// サインアップ中にロールを割り当てる
const { data, error } = await supabase.auth.signUp({
email,
password,
options: {
data: {
role: 'therapist',
tier: 'professional'
}
}
});
Supabase Auth は OAuth プロバイダー（Google、Apple など）、魔法のリンク、およびメール/パスワード -- すべてを箱から出した状態でサポート。B2C マーケットプレイスの場合、ソーシャルログインはほぼ必須。メール/パスワードと一緒に Google OAuth が利用可能な場合、サインアップ変換率が 30～40% 増加したことを見てきた。
レイヤー 4: 決済 -- Stripe Connect
支払い処理は、マーケットプレイスプロジェクトが真に複雑になる場所である。「支払いを受け入れる」と「支払いを受け入れ、プラットフォーム手数料を取り、払い戻しを処理し、30 カ国間でサブスクリプションを管理し、ゼロ小数点通貨を扱う」の間には大きな違いがある。
Stripe Connect がマーケットプレイス支払いフロー -- プラットフォームとサービスプロバイダー間の分割を処理する。私たちのプロジェクトの 1 つはすべてのトランザクションで手数料を処理し、プラットフォーム手数料とプロバイダーのカットを自動的にルーティング。
しかしサブスクリプション側はそれが興味深い場所である。30 以上の国にわたる地域価格を持つ 4 階層のサブスクリプションシステムを実行している。これは異なる通貨地域用に個別の Stripe Price オブジェクトを維持することを意味する。
ゼロ小数点通貨バグ
これは実際のお金を節約した私たちが共有する話である（そして私たちのクライアント）。Stripe は最小単位でほとんどの通貨を処理する -- だから USD 10.00 ドルは 1000（セント）。しかし日本円（JPY）やウォン（KRW）のような一部の通貨には小数単位がない。¥1000 は単に 1000 であり、100000 ではない。
コードが盲目的に 100 を乗算して最小単位に変換する場合、日本のユーザーに意図された金額の 100 倍を請求する。テストでこれを検出したが、これを実行しなかった本番マーケットプレイスを見てきた。
const ZERO_DECIMAL_CURRENCIES = [
'BIF', 'CLP', 'DJF', 'GNF', 'JPY', 'KMF', 'KRW',
'MGA', 'PYG', 'RWF', 'UGX', 'VND', 'VUV', 'XAF', 'XOF', 'XPF'
];
function formatAmountForStripe(amount: number, currency: string): number {
if (ZERO_DECIMAL_CURRENCIES.includes(currency.toUpperCase())) {
return Math.round(amount);
}
return Math.round(amount * 100);
}
地域的なトライアル除外
別の落とし穴：詐欺率が東南アジアの地域でトライアル経済的に実行不可能にしたため、無料トライアルオファーから特定の東南アジア国を除外する必要があった。Stripe の API を使用すると、カスタマー税の場所チェックでこれを設定できるが、まずそれが問題であることを知る必要がある。これは本番のマルチ国マーケットプレイスを実行することによってのみ学べるようなことである。
レイヤー 5: 検索 -- トリプル検索パターン
これはおそらくこの記事で最も価値のあるアーキテクチャパターン。ほとんどのディレクトリサイトは基本的なテキスト検索を提供。良いものは場所のフィルタリングを追加。3 つのすべての検索タイプを同時に実行し、結果をブレンド。
全文検索（PostgreSQL tsvector）：完全な単語と語幹の確認キーワード一致を処理。誰かが「配管工」を検索する場合、また「配管」と一致する。高速、よく理解される、Postgres に組み込まれている。
セマンティック検索（pgvector + Claude 埋め込み）：意味に基づいたクエリを処理。「私の関係について不安を感じることを助けることができる人」は単語「セラピスト」を含まないが、セマンティック検索は意図を理解している。Claude API を使用して各リスティング用の埋め込みを生成し、pgvector にベクトルとして保存。
地理検索（PostGIS）：近接クエリを処理。「ダウンタウンシカゴから 25 マイル以内」は空間クエリになる。インデックス付きかつ高速。
ブレンディングはそれが興味深い場所である。クエリに応じて異なる検索タイプに重み付け：
interface SearchWeights {
textWeight: number;
semanticWeight: number;
geoWeight: number;
}
function calculateWeights(query: string, hasLocation: boolean): SearchWeights {
const isNaturalLanguage = query.split(' ').length > 4;
if (hasLocation && isNaturalLanguage) {
return { textWeight: 0.2, semanticWeight: 0.5, geoWeight: 0.3 };
} else if (hasLocation) {
return { textWeight: 0.4, semanticWeight: 0.2, geoWeight: 0.4 };
} else if (isNaturalLanguage) {
return { textWeight: 0.2, semanticWeight: 0.7, geoWeight: 0.1 };
}
return { textWeight: 0.7, semanticWeight: 0.2, geoWeight: 0.1 };
}
短いキーワードクエリは全文検索に頼る。長い自然言語クエリはセマンティック検索に頼る。位置コンポーネントを持つクエリは地理的な重み付けを増加。私たちのディレクトリサイトの 1 つは 137K 以上のリスティング全体でこのトリプルパターンを実行し、検索結果は基本的なテキスト照合を使用する競合他社よりも著しく良い。
レイヤー 6: メディア -- Supabase Storage + Next.js Image
ディレクトリサイトは画像が重い。リスティング写真、プロフィール画像、ロゴ -- 蓄積される。アップロード用に Supabase Storage を使用し、最適化された配信用に Next.js <Image> コンポーネントを使用。
主な構成は、適切なアクセスポリシー（リスティング写真用のパブリック、ユーザー文書用のプライベート）で Supabase Storage バケットを設定し、Next.js Image 最適化を使用して右側の寸法で WebP/AVIF フォーマットを配信：
<Image
src={`${process.env.NEXT_PUBLIC_SUPABASE_URL}/storage/v1/object/public/listings/${listing.image_path}`}
alt={listing.name}
width={800}
height={600}
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
loading="lazy"
/>
Vercel にデプロイされると、Next.js は形式変換、サイズ変更、およびキャッシング自動的に処理。元のアップロード直接配信と比較して、画像ペイロード削減 60～70% を見た。
レイヤー 7: ホスティング -- Vercel
すべての本番ディレクトリとマーケットプレイスサイトは Vercel で実行。理由は単純：Vercel は Next.js が最高に実行される場所。ISR、サーバーコンポーネント、エッジミドルウェア、プレビューデプロイメント -- すべて設定なしで動作。
ディレクトリサイトの場合、エッジネットワークが重要。東京のユーザーがディレクトリを検索しているのに、バージニアのサーバーからではなく、近くのエッジノードからキャッシュされたリスティングページを取得するべき。Vercel のエッジキャッシングは ISR ページ用にこれを自動化。
プレビューデプロイメントも複数のステークホルダーを持つマーケットプレイスプロジェクトにとって巨大。すべてのプルリクエストは独自の URL を取得。クライアントはリアルデータを持つ実際の URL で新しい検索 UI をレビューできます。その前に本番環境へのものは何もない。
Vercel の Pro プラン月 20 ドルはチームメンバーごとに、ほとんどのディレクトリプロジェクトをカバー。大きなサイト（100K+ ページ）は ISR 限度を高くするため Enterprise プランが必要な場合がある。専用サポート。
レイヤー 8: メール -- Brevo API
マーケットプレイスプロジェクトのメールは 2 つのカテゴリーに分割：トランザクション（ブッキング確認、パスワードリセット、支払い領収書）およびマーケティング（ニュースレター、機能発表、再エンゲージメント）。
Next.js API ルートから呼び出された両方に Brevo を使用：
// app/api/send-booking-confirmation/route.ts
import { NextResponse } from 'next/server';
export async function POST(request: Request) {
const { to, bookingDetails } = await request.json();
const response = await fetch('https://api.brevo.com/v3/smtp/email', {
method: 'POST',
headers: {
'api-key': process.env.BREVO_API_KEY!,
'content-type': 'application/json',
},
body: JSON.stringify({
to: [{ email: to }],
templateId: 12, // ブッキング確認テンプレート
params: bookingDetails,
}),
});
return NextResponse.json({ success: response.ok });
}
Brevo の無料階層は 1 日 300 メールを処理し、これは初期段階のマーケットプレイスに十分。有料プランは月 9 ドルで 5,000 メールから始まる。SendGrid または Mailgun と比較して、Brevo の配信可能性レート比較可能であり、成長プロジェクトのための価格予測可能。
レイヤー 9: AI -- Claude API
AI はディレクトリスタック内のギミックではない -- 3 つの異なるジョブを処理するコアインフラストラクチャコンポーネント。
セマンティック検索埋め込み：すべてのリスティングは Claude で生成される埋め込みを取得し、その意味をキャプチャ。これは上記で説明したセマンティック検索層を強化。
コンテンツ拡張：ユーザーが送信したリスティングを持つディレクトリの場合、品質は大きく変動。Claude を使用して説明を正規化し、構造化データ（時間、専門、サービス地域）を抽出し、SEO フレンドリーな要約を生成。
インタラクティブ機能：私たちのプロジェクトの 1 つは、ユーザーが異なるタイプのガイダンスのために相談できる「Oracle Council」-- 5 つの異なる AI ペルソナを実行。異なるシステムプロンプト、個性、および専門分野を持つ各ペルソナ。見掛けは気まぐれに聞こえるが、著しいエンゲージメントを駆動し、サイトの最も人気のある機能の 1 つである。
2025-2026 年時点の Claude API 価格：Claude 3.5 Sonnet は入力トークン百万あたり 3 ドル、出力トークン百万あたり 15 ドル。100K リスティングディレクトリでの埋め込み生成に対して、1 回の費用は約 50～80 ドル。検索クエリおよびチャットボット相互作用に関する継続費用は通常トラフィックに応じて月 100～300 ドル。
レイヤー 10: 監視 -- Vercel Analytics + PostHog
ディレクトリサイト用に 2 つのタイプの監視が必要：パフォーマンスメトリックおよびユーザー動作分析。
Vercel Analytics は Web Vitals（LCP、CLS、INP）、リアルユーザー監視、およびトラフィックデータを提供。Vercel ダッシュボード内に組み込まれており、ゼロ構成が必要。ディレクトリサイトの場合、リスティングページで LCP を密接に監視 -- 2.5 秒以上に這い出す場合、ISR 構成または画像最適化に問題があることを知ります。
PostHog は製品分析を処理：ゼロ結果を返す検索クエリ（コンテンツギャップを埋める場合を知るため）、最も多くのビュー取得するリスティングカテゴリー、ユーザーがブッキングまたはサインアップフローで脱落する場所。PostHog の無料階層は月 100 万のイベントカバー、これはほとんどの初期段階マーケットプレイスを処理。
組み合わせは両方「サイトは高速か」と「ユーザーが彼らが必要とするものを見つけているか」を与える -- 2 つの非常に異なるが同じくらい重要な質問。
フルスタック比較表
| レイヤー | 当社選択 | 代替案 | 当社選択の理由 |
|---|---|---|---|
| フロントエンド | Next.js 15 | Astro、Remix | 100K+ ページの ISR |
| データベース | Supabase PostgreSQL | PlanetScale、Neon | 1 つの DB 内に pgvector + PostGIS |
| 認証 | Supabase Auth | Clerk、Auth.js | ネイティブ RLS 統合 |
| 決済 | Stripe Connect | Paddle、LemonSqueezy | マーケットプレイス分割、マルチ通貨 |
| 検索 | トリプルパターン (DB 内) | Algolia、Elasticsearch | 外部同期なし、低いコスト |
| メディア | Supabase Storage | Cloudinary、S3 | 同じエコシステム、シンプルな請求 |
| ホスティング | Vercel | Netlify、AWS Amplify | 最高 Next.js ISR サポート |
| メール | Brevo API | SendGrid、Resend | 価格/配信可能性比 |
| AI | Claude API | OpenAI、Gemini | コンテンツタスクのための最高の推論 |
| 監視 | Vercel + PostHog | Datadog、Mixpanel | フリー階層が初期成長をカバー |
本番環境でのこのスタックのコスト
~50K リスティング及び中程度のトラフィック（月 50K 訪問者）を持つディレクトリサイトの実数について話そう：
| サービス | プラン | 月額費用 |
|---|---|---|
| Vercel | Pro | $20 |
| Supabase | Pro | $25 |
| Stripe | 従量制 | トランザクションあたり 2.9% + 30¢ |
| Brevo | スターター | $9 |
| Claude API | 従量制 | ~$150 |
| PostHog | フリー階層 | $0 |
| 合計固定コスト | ~$204/月 |
それはマーケットプレイスプラットフォーム用の本番のための驚くほど手頃。Supabase Pro プラン 8GB のデータベーススペース、250GB の帯域幅、100GB のストレージを与える -- 50K リスティング持つディレクトリに対して十分以上。
100K+ リスティングを超えてスケーリングし、高いトラフィックに入る場合、約 500～800 ドル/月の費用を期待。献身的なサーバー、管理 Elasticsearch クラスター、別のベクトルデータベースを実行する古いアプローチよりもまだ劇的に安い。
ディレクトリまたはマーケットプレイスプロジェクトを計画している場合、詳細に価格設定を理解するため、価格ページをチェックするか、連絡を取得するプロジェクト固有の推定。
FAQ
2026 年のディレクトリウェブサイト向けのベストデータベースは何か？
Supabase を通じた PostgreSQL は当社の最高の推奨事項。セマンティック検索用の pgvector、地理クエリのための PostGIS、および組み込み全文検索の組み合わせは、外部サービスなしで 3 つのすべての検索寸法を処理できる。253K 以上のレコードを持つ本番プロジェクト全体で、ディレクトリスケールのデータをしっかり処理。PlanetScale（MySQL ベース）のような代替案は PostGIS サポートを欠く。ジオ検索を著しく難しくする。
Next.js は 100,000 以上のページディレクトリサイト用のページを処理できるか？
はい、しかし ISR（増分静的再生成）が必要。すべての 100K ページをビルド時に生成しない。代わりに、最高トラフィックページ（おそらく上位 1,000～5,000）を事前生成し、ISR が残りをオンデマンド生成するようにさせる。本番環境で 137K ページでこれを行った。鍵は適切な再検証間隔を設定 -- リスティングページに 3600 秒（1 時間）を使用し、カテゴリー/検索ページより短い間隔。
セマンティック検索はディレクトリウェブサイトでどのように機能するか？
各リスティングは Claude のような AI モデルを使用した数値ベクトル（「埋め込み」）に変換され、その意味をキャプチャ。ユーザーが自然言語で検索するとき -- 「ADHD を持つ子供を助ける誰か」 -- そのクエリもベクトルに変換。データベースは pgvector のコサイン類似度演算子を使用する、クエリベクトルに数学的に近いリスティングを見つける。これは、リスティングが検索クエリから正確な単語を含まない場合でも機能。
マーケットプレイスのために Stripe Connect が必要か、それとも私が定期的な Stripe を使用できるか？
マーケットプレイスが買い手と売り手（またはクライアントとサービスプロバイダー）間の支払い関与する場合、Stripe Connect が必要。定期的な Stripe は独自のアカウントへの支払いのみ受け入れることができます。Connect は分割を処理 -- プラットフォーム手数料を取り、サービスプロバイダーへの残りをルーティング。また、米国ベースの売り手に対する 1099 レポートを処理し、コンプライアンスの要件それはあなた自分を構築するしたくない。
ゼロから作成するため、ディレクトリウェブサイト構築にはどのくらいの費用がかかるか？
スタックの概説を使用し、本番環境でのインフラコスト月 200 ドルから始まる。開発コストは特徴に基づく幅広く変動するが、検索、ユーザーアカウント、およびリスティング管理を持つ本番対応ディレクトリ通常 8～16 週かかる構築。支払い、ブッキング、およびサブスクリプションを持つ完全なマーケットプレイスは別の 4～8 週を追加。詳細については ディレクトリおよびマーケットプレイス開発機能を検索できます。
内データベース検索代わりに Algolia または Elasticsearch を使用するべきか？
ほとんどのディレクトリサイトの場合いいえ。プライマリデータベースと別の検索サービス間でデータ同期の複雑さはバグを作成し、レイテンシーを追加し、コストを増加。Algolia は検索操作に基づいて請求 -- スケーリング時、これは高速取得（Build プランで 1,000 検索リクエスト 1 ドルから始まる価格）。PostgreSQL の組み込み検索機能、特に pgvector と組み合わせ、ディレクトリスケール検索をよく処理。例外：数百万レコード全体で 10 ミリ秒以下の応答時間を使用した誤字許容度および多面フィルタリングが必要な場合、Algolia は複雑さの価値がある。
ディレクトリ構築対マーケットプレイス構築の違いは何か？
ディレクトリはするものをリストし、ユーザーが見つけられるようにする。マーケットプレイスはトランザクション -- 支払い、ブッキング、手数料、およびしばしばプロバイダーとの 2 側相互作用とコンシューマー間を追加。テック スタックはほぼ同じだが、マーケットプレイスは Stripe Connect（または同等）を追加し、より複雑な認証ロール、およびトランザクションメールフロー。データベースシェマも注文、請求書、およびペイアウト追跡テーブルで複雑になる。
AI 機能を既存のディレクトリサイトに追加できるか？
確かに。当社スタック内の AI レイヤーは添加的、基本的ではない。セマンティック検索を追加するため、既存リスティング用埋め込みを生成（1 回のバッチジョブ）、pgvector 列に保存し、セマンティック検索エンドポイントを既存テキスト検索と並べて追加。コンテンツ拡張およびチャットボット機能は独立 API ルートとして追加できます。最難しい部分は通常大きな既存データセット用埋め込み生成 -- 処理時間数時間をバジェットし、API コスト 100K リスティングのための 50～100 ドル。