Codexでサイトを作る方法
初心者のための、
公開と運用の手引き。

1. 最初は「紹介だけの小さなサイト」を目標にする

初めてなら、自己紹介・作品一覧・問い合わせ先など、内容を読むことが中心のサイトから始めると進めやすくなります。完成の目安は「スマートフォンで読めて、作品へのリンクを押せて、誰かにURLを渡せること」です。

このGAME ROOMも、自作ゲームを紹介する個人サイトから始まりました。ブラウザゲームへの入口を置き、後からWindows版の配布リンク、Wiki、掲示板を加えています。最初からすべてを作る必要はありません。

HTML

見出しや文章、リンクなど、ページの内容。

CSS

色、余白、文字の大きさなどの見た目。

JavaScript

絞り込みやメニューなどの動き。

ホスティング

作ったファイルをインターネットで見られる場所に置くこと。

デプロイ

確認した変更を、その公開先へ反映すること。

紹介だけのページは、この3種類のファイルを中心に作れます。一方、投稿の保存やログインには、サーバー側の処理とデータベースが必要になることがあります。

2. Codexを使う準備と、最初に決めること

公式の OpenAI Docs：Quickstart で、利用するアプリや環境の案内を確認します。ローカルで作業する場合は、サイト専用の空のフォルダーを用意し、そのフォルダーを作業先に指定します。利用できる機能や利用枠は、契約・環境によって異なります。

1. 公式案内に沿って利用環境を準備し、自分のアカウントでログインする。
2. ローカル作業では、ほかの資料と分けたサイト専用フォルダーを作る。
3. Codexでそのフォルダーを作業先に指定し、新しいチャットから次の依頼文を送る。

Codexは、指示に沿ってファイルの作成・編集や確認を進めるAIです。記事中の依頼文は、希望を伝える出発点として使ってください。

• 誰に：例として、作ったゲームを遊んでほしい人。
• 何を：作品名、紹介文、実際の画像、遊ぶ・ダウンロードのリンク。
• どんな見た目で：例として、読みやすいドット絵・レトロゲーム風。
• どこまで：まず紹介ページだけ。アカウントや投稿機能は後から。
• 費用の条件：公開先は無料枠で始め、有料契約の前に料金を確認する。

プラグインのSitesが利用できる環境なら「Sitesでサイトを作って」と指定する方法もあります。利用できない場合は、作業フォルダーにHTML・CSS・JavaScriptを作る方針で依頼できます。

3. サイトを作る依頼文を、具体的に書く

文章がうまく書けなくても大丈夫です。用途、載せる内容、見た目、確認してほしいことをまとめて伝えます。「見やすくして」だけより、読む人が何をしたいかを添えると、確認する基準を共有できます。

個人の作品紹介サイトを作ってください。
対象：初めて作品を見る人。
内容：自己紹介、作品3件、作品ごとの画像・紹介・公開形式・リンク。
見た目：レトロゲーム風。スマートフォンでも読みやすくしてください。
条件：まずHTML・CSS・JavaScriptで作れる範囲にし、投稿・ログインは不要です。
開発中の作品には、その旨を表示してください。
不足する作品名や画像は質問し、実在しない実績やリンクは作らないでください。
最初にローカルで表示し、確認用URLと変更ファイルを教えてください。

作品名・画像・配布先は、自分の本当の情報へ置き換えます。他人の画像や文章を使う場合は利用条件も確認します。素材が未完成なら「画像準備中」として進める方が、別の作品の画像を載せるより誤解を減らせます。

依頼の組み立て方の参考：OpenAI Docs：Prompting。この記事の依頼文は、本サイトの制作経験をもとに作成した例です。

4. 公開前に、実際に見て・押して確認する

「コードを書けた」「ビルドが成功した」「画面が正しい」は、それぞれ別の確認です。パソコンだけでなく、細いスマートフォン幅でも見てみましょう。

1. タイトル、紹介文、開発中表示、画像が意図どおりか読む。
2. 遊ぶ・ダウンロード・ページ移動のリンクを押し、正しい公開先か確認する。
3. 小さい画面で文字やボタンがはみ出さないか確認する。
4. フォームを作った場合は、空欄・長い入力・エラー時の表示も確認する。
5. 公開するフォルダーに、パスワード、秘密鍵、.env、個人情報が入っていないか確認する。

スマートフォン幅で作品紹介のボタンがはみ出しています。
作品名・紹介文・配布URLは変えず、レイアウトだけ修正してください。
PCとスマートフォン幅で表示とリンクを確認し、確認できなかった項目も教えてください。

不具合を伝えるときは、どのページで、何を押すと、期待と違う何が起きるかを書きます。画像を添える場合は、アカウント情報などが映っていないか確認してから渡します。

5. Cloudflare Pagesでサイトを公開する

この個人サイトはCloudflare PagesのURLで公開しています。初心者の紹介サイトなら、まず公開先が提供するURLで動かし、独自ドメインが必要になった時点で検討する進め方ができます。

PagesのDirect Uploadは、完成した公開ファイルをアップロードする方式です。管理画面のドラッグ＆ドロップとWranglerというコマンドツールが使えます。Direct Uploadから同じプロジェクトのGit連携へは切り替えられないため、最初に運用方法を選びます。サーバー処理があるサイトでは、管理画面へファイルを置くだけでは公開できない場合があるので、構成をCodexに確認させましょう。Cloudflare公式：Direct Upload

このサイトをCloudflare Pagesで公開したいです。
静的ページか、Functionsやデータベースも必要かを確認してください。
無料枠で始め、利用する公開方式・公開対象フォルダー・制限を説明してください。
秘密情報を含めず、ローカルで確認した後に公開してください。
ログイン、本人情報、規約同意、料金が発生する操作が必要なら、その時点で教えてください。
公開後は実際のURLで表示とリンクを確認し、更新と元に戻す手順も残してください。

公開後は、ローカルの画面だけでなく、他の人へ渡す本番URLも確認します。無料のサブドメインと、自分で取得する example.com のような独自ドメインは別です。独自ドメインには通常、取得・更新の費用がかかります。

無料枠にも容量や回数の制限があります。2026年10月22日のPages公式資料では、Freeのファイル数上限は20,000、1ファイルは最大25MiBです。大きなゲームのZIPはページと分けた配布先を検討します。Functions・データベースなどの利用枠は別途確認してください。Cloudflare公式：Pagesの制限

6. Google検索に見つけてもらうための設定

公開URLを開けても、すぐ検索結果に出るとは限りません。この記事も、検索に載るための土台を用意して公開するものです。

1. 内容を明確にする：ページごとに具体的なタイトル・見出し・紹介文を用意し、画像だけでなく文章でも説明する。
2. 入口を作る：ホームから記事へ通常のリンクを置き、サイトマップにURLを追加する。
3. 公開URLをそろえる：canonicalで優先URLを示し、公開ページに意図しないnoindexやアクセス制限がないか確認する。
4. Search Consoleで確認する：公開先の所有権を確認し、サイトマップ送信とURL検査を行う。

本サイトでは公開先をWorkersからPagesへ変更しました。異なるホスト名のURLプレフィックスプロパティは別なので、新しい公開URLでも登録・確認が必要でした。すでに同じプロパティを確認済みなら、記事を増やすたびに新しいプロパティを作る必要はありません。

この記事をGoogleが読み取れるようにしてください。
固有のtitle・description・H1、canonical、本文と一致する記事・パンくずの構造化データを設定。
ホームからリンクし、XML/TXTサイトマップへ実際の公開URLを追加してください。
HTTP応答、robots.txt、noindex、リンク切れも確認してください。
検索順位や登録完了は、実際に確認できていなければ保証・断定しないでください。

基本設定の確認先：Google公式：SEOスターターガイド。

URL検査の「登録できます」は、登録済みという意味ではありません。再クロールには数日〜数週間かかることがあり、リクエストには上限があります。同じURLを繰り返し申請しても早まりません。Google公式：再クロールのリクエスト

7. 公開後は「小さく更新して、確認して戻せる」運用へ

作品が更新されたら、紹介文だけでなく画像、バージョン、ダウンロード先、Wikiも一緒に見直します。このサイトでも、ゲームだけ新しくなり説明が古い状態を避けるために、配布版と紹介内容を照合してきました。

これは運用の例で、監視や更新が自動で実行される設定ではありません。自動確認を使うなら、対象・頻度・通知条件・停止方法まで決めます。

作品Aの紹介を最新版へ更新してください。
指定したREADMEと配布済みバージョンを根拠に、紹介・画像・Wiki・配布リンクをそろえてください。
未公開の機能は公開済みと書かず、他の作品や既存データは変更しないでください。
変更前に戻せるように保存し、確認後にデプロイして公開URLを教えてください。

Gitのコミットや公開サービスの過去のデプロイを残すと、変更前へ戻しやすくなります。ただし、ページの版と、掲示板などの保存データのバックアップは別です。データベースがあるなら、復元方法も確認します。

アクセス集計・掲示板を追加するときの考え方

このサイトでは「今日の訪問者」を同じブラウザーで1日1回だけ数え、「累計」は日ごとの人数を合算しています。何を数えるかを先に決めることが、数字を正しく読む第一歩でした。

• ページビュー：ページが表示された回数。人の数とは異なります。
• 訪問者：識別方法と期間を決めて重複をまとめた数。別端末や保存情報の削除で、同じ人が別に数えられることがあります。
• アクティブ：直近の一定時間に反応があったブラウザーの数など。常に画面を見ている証明ではありません。

IPアドレスだけでは、人数や「人かボットか」は確定できません。User-Agentも書き換え可能な情報なので推定に使い、断定しない表示にします。ログを保存するなら、目的・保存期間・管理者だけが見られる仕組み・プライバシー説明を先に決めます。

掲示板には、入力の長さ制限、連投対策、不適切な投稿の削除、管理者認証が必要です。最初の紹介サイトに必須の機能ではないので、運用できる範囲で追加しましょう。実例は このサイトの交流掲示板 と プライバシーポリシー で確認できます。

広告を置くことと、広告収益が出ることは別

このサイトには広告枠がありますが、枠を作っただけで配信や収益が確定するわけではありません。広告サービスへの登録、サイトの確認・審査、必要な支払い情報・同意の設定を分けて考えます。

まず、読者が目的の内容を読めるページを用意します。広告で本文や「遊ぶ」「ダウンロード」の操作を紛らわしくせず、広告であることを示します。AdSenseを利用する場合は、Google公式のサイトに関する案内 を確認してください。

運営費を広告でまかなえるかは、実際の収益で判断します。手入力で計算するなら、ページRPM ＝ 収益 ÷ ページビュー × 1,000、必要ページビューの目安 ＝ 月の運営費 ÷ ページRPM × 1,000です。同じ期間・通貨の数字を使い、RPMが0や未確定のときに黒字化を予測しないようにします。

この式は目安で、アクセスが増えても同じRPMが続く保証はありません。自分で広告をクリックしたり、読者にクリックを頼んだりせず、まず必要な情報と使いやすさを充実させます。

表示速度は「点数」だけでなく、動きと読みやすさも見る

本サイトをPageSpeed Insightsで確認したところ、文字のコントラスト、アクセス数欄のHTML、画像の配信サイズに改善点が見つかりました。文字色を濃くし、構造を直し、表示幅に合うWebP画像を選ぶように変更しました。

2026年10月22日のデスクトップ測定では、ユーザー補助が92→100点、パフォーマンスが71→73点となりました。一方、表示後のずれを表すCLSは0.981のままで、解消したとは扱っていません。外部広告を遮断したローカルではCLSが0でも、本番の結果とは条件が異なりました。

この経験から、「テスト成功」と「本番の問題が直った」を区別することが大切です。結果が違うときは、測定条件・対象URL・広告や画像の読み込みを確認してもらいましょう。単回の点数は変動するため、すべてをその数字だけで決めないようにします。

本サイトの実測レポートを見る。新しい確認は PageSpeed Insights から行えます。

よくある質問

まずは、1ページを作って公開するところから

この記事の依頼文から、載せたい内容に合うものを選んで使ってみてください。最初の目標は、紹介が伝わり、リンクが正しく、更新方法が分かるサイトを1つ持つことです。