GPT Sitesを活用して、ニッチなデータベースサイトを設計・公開した話

最近、特定サイズの靴だけを扱う、小規模なデータベースサイトを制作しました。

ブランド公式サイトやECモールに分散している商品情報を整理し、条件に合う商品を品番から探せるようにしたサイトです。

制作にはChatGPTのSites（以下、Sites）とNext.jsを利用しました。企画からUI設計、実装、コンテンツ登録、テスト、公開までを一つの流れで進めています。

今回は、AIと一緒に画面を作ったという話だけではなく、ニッチな情報を扱うデータベースサイトとして、どのように情報を整理し、公開できる品質まで整えたのかをまとめます。

課題を「検索しやすさ」に置き換える

このサイトの出発点は、欲しい商品が存在しないことではなく、存在していても見つけにくいという課題でした。

検索結果には近い条件の商品も多く表示されます。同じモデル名でも、カラーや販売時期によってサイズ展開が異なることがあります。また、商品ページが見つかっても、必要なサイズが現在も選べるのか、どの品番を探せばよいのかが分かりにくいケースもあります。

そこで初期版では、機能を増やすより先に、掲載基準を絞りました。

対象サイズを確認できた商品のみを掲載し、モデル名ではなく品番単位で管理します。ブランド、靴の種類、ウイズ、価格、キーワードから絞り込めるようにし、詳細ページでは確認元と確認日を表示する設計にしました。

何でも検索できる総合サイトではなく、特定の条件で困っている人が迷わず候補を見つけられることを優先しています。

初期版はDBを持たず、Markdownで管理する

データベースサイトと呼んでいますが、初期版ではデータベースサーバーやCMSを導入していません。

公開時点では運営者が一人で、更新量も限られています。会員登録やユーザー投稿、在庫の自動同期もありません。この段階で管理画面やAPIを先に作ると、商品情報を更新する作業よりも、システムを維持するための作業が増えてしまいます。

そこで、商品とブランドの情報はMarkdownで管理しています。MarkdownのFront Matterに、ブランド名、モデル名、品番、カテゴリー、公式サイズ、ウイズ、価格、在庫の確認状況、出典URL、確認日、購入先、試着記録などを持たせました。

ビルド前には専用の生成処理を実行し、Markdownをアプリケーション用の型付きデータへ変換します。この処理では、対象サイズ以外が混ざっていないか、品番・出典・確認日が入力されているか、出典URLがHTTPSになっているかを確認しています。

また、試着記録がない商品に、サイズ感や足幅との相性が入力されていた場合はエラーにしています。更新者の注意力だけに頼らず、掲載方針をコードでも守るためです。

将来microCMSなどへ移行する場合も、現在の項目をコンテンツモデルへ置き換えやすい構造にしています。最初から大きな仕組みを持つのではなく、現在の更新量に合う方法を選びました。

SSGで一覧と詳細をページとして生成する

フロントエンドはNext.jsのApp RouterをReactとTypeScriptで実装し、出力方式にはSSGを採用しました。

商品詳細、ブランド別一覧、カテゴリー別一覧、ページネーション、このサイトについて、プライバシーポリシーなどを、ビルド時に静的ページとして生成しています。

一覧画面の絞り込みは、Reactのクライアント側の状態として実装しています。ブランド、靴の種類、ウイズ、価格上限、キーワード、並び順を変更すると、その場で結果が切り替わります。

一方で、商品詳細やブランド別一覧など、検索エンジンから直接訪れてほしいページには固有のURLを持たせています。操作性のためのクライアント側フィルターと、検索されるための静的ページを分けて考えた構成です。

完成したサイトはSitesでバージョンを保存してから公開し、独自ドメインを接続しています。更新時は、Markdownの変更、データ生成、静的ビルド、テスト、バージョン保存、公開という順序で反映します。

分からない情報を埋めない

商品データを増やす際に、最も重視したのは、確認できていない情報を推測で補わないことです。

公式商品ページで対象サイズを確認できても、実際の在庫や履き心地まで分かるとは限りません。未試着の商品については、サイズ感、足幅、甲との相性を「不明」として表示しています。在庫を確認できていない場合も、その状態を明記しています。

試着記録を掲載できるデータ構造と画面は用意していますが、実際に履いていない商品にはレビューを作りません。現時点の公開データにも、架空の試着レビューは含めていません。

商品画像についても、許諾状況を確認できていない他社画像の転載は避けました。初期版では、ブランドカラーや品番を使った抽象的なビジュアルをCSSで表示しています。将来、必要に応じて自分で撮影した画像や、利用条件を確認できた素材へ置き換える想定です。

情報量を多く見せるよりも、どこまで確認できているのかが分かることを優先しました。

日本語で読みやすいUIを詰める

デザインでは、情報量の多いECモールのような見え方を避け、比較に必要な項目だけを追いやすいUIを目指しました。

ベースカラーは白に近いグレー、アクセントにはブルーとライムを使っています。日本語フォントにはNoto Sans JPのVariable Fontを採用し、本文、見出し、ラベルでウェイトを調整しました。

日本語の改行も、単に画面幅に任せるのではなく、禁則処理と対応ブラウザでの文節単位の改行を指定しています。見出しの文字サイズだけでなく、行間、字間、一行の長さまで含めて調整しました。

スマートフォンでは、ロゴとボタンの下にメニューを一行分確保し、項目が収まらない場合は横スクロールできるようにしています。一覧カードはカード全体をリンクにし、ページネーションの現在位置は押せない表示にしました。

詳細ページでは、「購入先を見る」を押したあとにスクロールしづらくなる問題も発生しました。固定表示とスムーススクロールの組み合わせを見直し、ヘッダーの高さを考慮した通常スクロールへ変更しています。

こうした調整は、最初の生成結果だけでは見つかりません。PCとスマートフォンの両方で、実際の操作を繰り返しながら詰めていきました。

SEOとAI検索を意識して情報構造を整える

SEOでは、トップページだけではなく、商品、ブランド、カテゴリー、一覧の各ページが独立して理解される構造を意識しました。

各ページに固有のtitle、description、canonical URL、OGPを設定し、商品詳細にはProductとBreadcrumbList、トップページにはWebSiteの構造化データを出力しています。サイトマップとrobots.txtも、Markdownからコンテンツを生成するタイミングで更新します。

HTMLはレイアウトの都合だけで要素を選ばず、情報の意味と文書構造がマークアップから読み取れるように設計しました。header、nav、main、article、section、asideでページ内の役割を明確にし、商品情報や確認日にはdl、data、timeを使い分けています。

また、インデックス対象ページではmainを一つに限定し、ページの主題を示す表示上のh1も一つに統一しました。スクリーンリーダーや検索エンジンが構造を解釈しやすく、コンポーネントが増えても見出し階層を維持しやすいHTMLを目指しています。

AI検索については、Sitesを使っただけで評価されるとは考えていません。品番、対象サイズ、出典、確認日、在庫の確認状況を一つのページ内で明確にし、未確認の情報を推測しないことが、検索エンジンやAIに内容を伝えやすくするための土台になると考えています。

ただし、こうした実装が検索順位やAI回答への掲載を保証するものではありません。効果は現時点では確認できていないため、公開後のアクセス解析や検索状況を見ながら、ページ内容を継続して改善していく必要があります。

公開前に生成後のHTMLをテストする

今回は、コンポーネント単位の確認だけでなく、SSG後に出力されたHTMLを対象にテストを行いました。

セマンティックな要素が出力されているか、各ページのh1とmainが一つになっているか、canonical URLやOGPがページごとに変わっているか、構造化データに品番が含まれているかなどを確認しています。

そのほか、現在のページ番号がリンクになっていないこと、未試着の商品にサイズ感が入っていないこと、権利処理前の商品画像がHTMLに含まれていないこと、プライバシーポリシーにGoogle Analyticsの利用が反映されていることもテストしています。

公開前には、公開対象となる静的ページが生成され、自動テストがすべて通ることを確認しました。画面の見た目だけではなく、公開後も守りたい方針をテストとして残しています。

Sitesを使って感じたこと

Sitesを使うことで、企画段階の会話から、実装、修正、テスト、公開までを一つの制作フローとして進められた点は便利でした。

一方で、最初から公開品質のサイトが自動的に完成するわけではありません。文章が説明的になりすぎる、英語表記が増える、日本語の文字が小さくなる、スマートフォンで要素が見切れるなど、生成後に見直すべき点も多くありました。

また、SEOやAI検索への対応も、公開基盤だけで決まるものではありません。誰のどの課題を解決するのかを絞り、データの単位を決め、情報の出典と更新日を管理し、それをHTMLの構造へ落とし込む必要があります。

今回の制作を通して、AIによって作るスピードが上がったからこそ、何を載せ、何を載せないかを決める設計がより重要になると感じました。

今後は、掲載件数と更新頻度を見ながらCMSへの移行を検討し、実際に試着できた商品の記録も少しずつ追加していく予定です。まずは小さく公開し、運用しながら育てられるデータベースサイトとして改善を続けていきます。

※本記事は個人の制作事例であり、OpenAIによる公式解説ではありません。Sitesは執筆時点でパブリックベータのため、最新の仕様や提供状況はOpenAIの公式ドキュメントをご確認ください。