Codex Sitesで作ったサイトを公開品質へ改善するには？

結論：短い依頼は試作向け、公開品質には追加条件が必要

Sitesは、プロンプトからWebサイト、Webアプリ、ゲームを作成し、修正、保存、ホスティング、共有まで進められます。ただし「題材と一覧機能」だけの短い依頼では、情報の網羅性、権利、スマートフォン表示、更新方法、公開範囲が未指定になりがちです。初回生成を完成品ではなく、確認可能な試作として扱うのが堅実です。

最初の依頼に入れる7項目

日本語で、ゲーム更新情報を確認できるWebサイトを作成してください。
対象は復帰ユーザー。バージョン一覧、検索、メジャー版の絞り込み、詳細画面を用意します。
各情報には公式サイトの出典URLと確認日を付け、推測は表示しません。
画像は利用許諾を確認できるものだけを使い、確認できない場合は独自の代替画像にします。
375px幅からPCまで対応し、長い日本語でも横スクロールを発生させません。
まず保存版を作り、私が確認するまでdeployしないでください。

初回生成後に見る5画面

1. 検索結果が0件の時に説明と解除方法を表示する。
2. 戻る操作で検索語と絞り込み状態が維持されるか確認する。
3. リンク切れ、画像欠落、読み込み失敗時の表示を確認する。
4. キーボード操作、見出し順、色のコントラストを確認する。
5. 375px、768px、1280px付近で重なりと横はみ出しを確認する。

題材サイトでは「調べた」だけでなく根拠を残す

公式マニュアルは、Sitesへ意図した情報を使っているか確認するよう案内しています。更新履歴や製品情報を扱う場合は、各レコードへ出典URL、確認日、対象バージョンを持たせます。Wikiは探索に役立ちますが、最終的な日付や仕様は公式発表へ戻って確認します。

画像の差し替えだけでは権利確認の代わりになりません。公式画像、ファンWiki画像、生成画像にはそれぞれ異なる利用条件や誤認リスクがあります。利用できる根拠、クレジット、生成物であることの表示を整理します。

「動的に対応」ではなく、確認条件を数値で指定する

レスポンシブ対応は「スマホ対応にして」だけでなく、最小幅、主要ブレークポイント、長文、カード数、空状態を指定します。固定幅の表は横スクロール領域へ収め、ボタンのラベルは折り返しまたは短縮し、画像には安定した縦横比を設定します。

記録を残すならD1、ファイルを残すならR2

検索可能なアップロードでは、D1にメタデータ、R2に実ファイルを置く構成があります。テーマ選択や閉じた案内など、一時的な画面状態へ永続ストレージを追加する必要はありません。

SaveとDeployを分ける

Sitesのdeployment URLはすべて本番公開です。画面確認だけなら「保存版を作り、deployしない」と明示します。

公開前チェックリスト

1. タイトル、説明、対象者、収録範囲が一致している。
2. 各情報の出典URL、確認日、対象版がある。
3. 画像と文章の利用条件を確認した。
4. スマートフォンとPCで検索・絞り込み・詳細を操作した。
5. 空状態、通信失敗、リンク切れの表示を確認した。
6. 保存が必要な情報だけD1/R2へ置いた。
7. 共有範囲を最小にし、対象者と同じ条件で確認した。
8. 保存版を確認してからdeployした。

関連ページ

確認したOpenAI公式情報

• OpenAI：Sites
• OpenAI：Sites showcase

よくある質問