Codexでランディングページを作る使い方と公開前の確認

Codexでランディングページ制作を進める考え方

ランディングページ制作でCodexが力を発揮するのは、きれいな画面を一度で生成する場面だけではありません。既存ファイルの構造を読み、要件に沿って部品を追加し、表示結果を確認して修正する連続した作業に向いています。一方で、誰に何を伝えるか、どの行動を成果とするかは依頼者が決める必要があります。Codexを制作担当として使い、人が目的と判断基準を握る関係にすると、見栄えだけは良いものの成果につながらないページを避けやすくなります。

生成の速さより判断できる差分を重視する

一度にページ全体を書き換えると、どの変更が表示崩れや訴求のずれを生んだのか追いにくくなります。最初に構成だけを決め、次にヒーロー、実績、機能説明、よくある質問、最後の案内という単位で実装を進めると、差分と表示を対応させられます。Codexの価値はコード量ではなく、目的に沿う変更を確認可能な大きさで積み上げられる点にあります。

2026年7月はサイト本体と素材を分けやすくなった

OpenAIの2026年7月23日の更新情報では、ローカルプロジェクトへ複数の関連フォルダーを追加できるようになったと案内されています。Projects and chatsによれば、主要フォルダーを新しい会話とコード操作の起点にしながら、副フォルダーも検索、読み取り、編集の対象にできます。サイト本体、文章原稿、承認済み素材が別の場所にある制作でも、関係する範囲だけを一つの案件へまとめやすくなりました。

CodexとSitesは制作と公開で役割が異なる

Codex CLIやエディタ拡張は、ローカルのソースを編集し、検査する入口として使えます。OpenAIのSites公式資料は、Sitesをウェブサイトやウェブアプリの作成、ホスティング、改善、共有を扱う機能として説明しています。ローカルで十分に作り込んでからSitesへ渡すことも、Sitesから新しいページを始めることもできます。どちらを選んでも、制作中の確認と一般公開の判断を分けることが重要です。

着手前に決める目的・素材・実装範囲

良いランディングページは、コードを書き始める前に半分が決まります。訪問者が抱える課題、ページで約束する価値、読み終えた後に取ってほしい行動が曖昧だと、Codexは不足をもっともらしい文章や部品で補おうとします。その結果、要素は多いのに焦点が弱いページになりがちです。依頼文には目的、利用できる事実、変更してよい場所、維持する要素、表示上の合格条件を記し、分からないことを推測で埋めないよう明示してください。

訪問者と主要な案内を一文で表す

まず「誰が、どんな悩みを解決するために、このページを読むのか」を一文にします。続けて、資料請求、問い合わせ、試用開始、購入など、最も重要な案内を一つ選びます。複数の行動を同じ強さで並べると、訪問者もCodexも優先順位を判断できません。主な案内と補助的なリンクを分け、ボタン文言、遷移先、完了後の状態まで合格条件に含めます。

事実として使える原稿と数字を区別する

製品名、料金、導入実績、利用者の声、性能値は、Codexに創作させてはいけない情報です。承認済みの原稿や根拠を渡し、未確定部分には明確な仮文を置くよう依頼します。数字の出典、引用の許諾、商標表記も人が確認してください。魅力的な表現を作る仕事と、事実を確定する仕事を分けることで、公開直前に文章を全面修正する事態を防げます。

主要フォルダーと参照用フォルダーを分ける

複数フォルダーを使う場合は、実装対象のサイトを主要フォルダーにし、文章や画像の置き場を参照用として追加します。公式資料では、主要フォルダーが新しい会話の開始位置になり、設定や指示の探索でも基準になると説明されています。参照用フォルダーまで無条件に変更させず、「素材は読んでよいが書き換えない」のように境界を伝えると、原本を保ったまま制作できます。

参考画像は見る場所と変えない場所を伝える

OpenAIのImage inputs公式資料は、画像だけに依頼内容を任せず、何を確認し、どんな結果にしたいかを文章でも示すよう案内しています。参考画像を添えるなら、「見出しの強弱と余白だけを参考にし、色と文言は既存のまま」のように対象を限定します。複数画像では、基準となる画面、現在の画面、比較したい表示幅を名前で区別すると認識のずれを減らせます。

Codexでランディングページを作る手順

実作業は、要件の固定、現状確認、構成作成、部品ごとの実装、ブラウザ確認、最終検査の順に進めます。各段階でCodexに結果を説明させ、次へ進む前に人が判断すると、早い段階で方向を直せます。以下では個別の段階をH3に分けています。別の案件で使うときも、技術構成やページ規模に合わせて一段ずつ適用し、一つの依頼へ大量の目的を詰め込まないようにしてください。段階ごとの出力を残しておけば、方向がずれたときも正しかった状態から再開できます。

Step 1: 目的と合格条件を渡す

最初の依頼には、対象の訪問者、解決したい課題、主要な案内、必須セクション、利用できる事実、変更禁止の範囲を書きます。合格条件には、指定した表示幅で横にはみ出さないこと、すべての案内先が正しいこと、既存の検査が通ることなど、結果として確認できる内容を置きます。好みを示す「いい感じ」ではなく、見て判定できる条件へ言い換えるのが要点です。

Step 2: 既存構成と再利用できる部品を調べる

既存サイトへ追加する場合は、入口となるページ、共通レイアウト、ボタン、色や余白の定義、画像の扱い、検査方法をCodexに調べさせます。この段階では変更せず、再利用できる部品と新規作成が必要な部分を報告させてください。既存の設計を無視して似た部品を増やすと、見た目の微差と保守箇所が増えます。調査結果に納得してから実装範囲を確定します。

Step 3: 文章構成を先に組み立てる

コードの前に、各セクションの役割、見出し、本文の要点、主要な案内の位置を文章で出させます。訪問者の課題から価値、根拠、利用方法、不安の解消、次の行動へ自然につながるかを読み、不要な重複を削ります。この構成を確認しておけば、後から文章を大きく入れ替えてレイアウトまで崩す事態を減らせます。未確定の実績や数値は仮文だと明記させます。

Step 4: セクション単位で実装する

ヒーローから始め、次のセクションへ一つずつ進めます。各依頼で変更対象、再利用する部品、維持する振る舞い、検査方法を指定します。実装後は差分を読み、余計な依存関係や対象外の書き換えがないか確認してください。小さな単位なら、期待と違う場合もその部分だけ戻して指示を修正できます。ページ全体の統一感は、共通の色、文字、余白の定義を再利用して保ちます。

Step 5: Browserで実際の表示を確認する

OpenAIのBrowser公式資料によれば、デスクトップアプリのBrowserはローカルページを開き、表示状態の確認、クリック、入力、画面撮影を行えます。開発用のページを表示し、対象のURL、確認したい状態、期待する結果を具体的に伝えてください。表示上の問題には対象箇所へコメントを残し、修正後に同じ条件で見直すと、コードと画面の往復を短くできます。

Step 6: 公開候補として最終検査する

最後に、表示幅、リンク、フォーム、キーボード操作、画像の代替文、読み込み失敗時の状態、検査結果をまとめて確認します。この段階では新しい装飾を足さず、公開を妨げる問題だけを直します。変更ファイルと検査結果をCodexに要約させ、人が実際のページと差分の両方を見て採否を決めてください。完成という言葉ではなく、合格条件をすべて満たしたかで公開候補を判定します。

公開前に確認したいランディングページの品質

ランディングページの不具合は、ページが表示されない場合だけではありません。スマートフォンで重要な文言が隠れる、ボタンの遷移先が違う、フォーム送信後に反応がない、画像の読み込みでレイアウトが大きく動くといった小さな問題も、成果を失う原因になります。見た目、操作、内容、計測を別の観点として確認し、Codexの報告だけでなく実際の表示と入力結果を人が確かめてください。確認結果は画面幅と操作条件を添えて記録し、再修正後にも同じ条件を使います。

スマートフォンと広い画面で優先順位を保つ

狭い画面では、見出し、価値の説明、主要なボタンが最初の範囲で読めるかを確認します。文字が小さすぎないか、ボタン同士が近すぎないか、長い日本語が不自然に切れないかも重要です。広い画面では、行が長くなりすぎず、要素間の視線移動が大きくなりすぎないようにします。幅ごとの画面を並べて比較し、内容の優先順位が変わっていないかを見ます。

キーボード操作と読みやすさを確かめる

リンクやフォームへキーボードで移動でき、現在位置が見えることを確認します。見出しの順序、入力欄の名前、画像の代替文、文字色と背景色の差も見落とせません。装飾的な画像と内容を伝える画像では、必要な説明が異なります。Codexに機械的な検査を頼むだけでなく、実際に最初から最後まで読み、操作して、初めて訪れた人が迷わないかを確かめます。

フォームと案内先は成功・失敗の両方を見る

問い合わせや登録フォームでは、正常に送れる場合だけでなく、必須項目が空、形式が誤り、通信に失敗した場合の表示も確認します。送信ボタンを繰り返し押したときの挙動や、完了後に次の行動が分かるかも重要です。外部ページへ移る案内は、URL、開き方、戻りやすさを実際に試します。主要な案内が一つでも壊れていれば、ページ全体の完成度が高くても公開を止める判断が必要です。

内容の根拠と公開権限を確認する

料金、比較、実績、利用者の声は、承認済みの情報と一致しているかを読み合わせます。使用する画像、ロゴ、引用には公開できる権利があるかを確認し、内部用の文言や個人情報が残っていないかも検索してください。参考ページの表現をそのまま写さず、自社が説明できる根拠へ置き換えます。Codexは文章の自然さを整えられますが、公開責任や権利関係を引き受けるわけではありません。

Sitesで保存・公開するときの注意点

Sitesを使うと、作成したランディングページをホスティングし、共有先を管理できます。ただし、公式資料はすべての公開URLを本番の公開先として扱うと説明しています。確認用のつもりで公開すると、意図しない相手が見られる状態になる可能性があります。まず保存した版を確認し、対象者、公開範囲、収集する情報を見直してから公開してください。利用可否や上限はプラン、地域、組織設定によって異なるため、自分の画面で現在の提供状況も確認します。

公開前に保存した版を確認する

Sites公式資料では、公開可能な版を保存する段階と、その版を本番へ公開する段階が分かれています。見直しが必要なら、公開せず版の保存までにとどめます。対象の版、変更内容、表示確認の結果が一致しているかを確かめ、古い版や途中の版を選ばないようにしてください。公開判断を別の段階にすることで、制作完了の勢いで未確認のページを外へ出す事故を防げます。

公開範囲は必要な相手だけに絞る

新しいSiteは、公開範囲を変更するまで所有者と組織管理者に限られると公式資料で案内されています。確認中は狭い範囲を保ち、社内限定、指定した相手、一般公開のどれが目的に合うかを選びます。一般公開する場合は、外部の人が見ても問題ない内容だけで構成されているか、もう一度確認してください。閲覧できることと編集できることは別の権限なので、共有後の見え方も実際の訪問者として試します。

公開後は閲覧状況と主要な行動を分けて見る

Sitesには、訪問者数とページ閲覧数を確認できる分析画面があると公式資料に記載されています。閲覧が増えたことだけで成果とせず、主要なボタンやフォームの結果と分けて読みます。見出し、ボタン文言、セクション順などを変更するときは、一度に一つの仮説へ絞り、変更前後の期間と対象を記録してください。複数箇所を同時に変えると、どの修正が結果へ影響したか判断できなくなります。

Codexへの依頼文を具体的にする例

依頼文は長ければよいのではなく、判断に必要な情報がそろっていることが大切です。対象の訪問者、目的、事実として使える情報、変更範囲、維持する仕様、確認方法を一つの文章へまとめます。また、最初から制作と公開を同時に頼まず、構成確認、実装、表示確認、公開候補の作成を別の依頼に分けてください。以下の例は、そのまま使う定型文ではなく、自分のページの事実へ置き換えるための骨組みです。依頼の終わりには、変更内容と検査結果を分けて報告するよう求めると確認しやすくなります。

新規ページの構成を作る依頼

最初はコードを書かせず、構成と不足情報を出させます。たとえば「対象は小規模な開発チーム。目的は無料相談の予約。承認済みの原稿だけを使い、ヒーロー、課題、提供内容、根拠、よくある質問、最後の案内で構成する。未確定情報は補わず質問として列挙する」と伝えます。これなら、事実の不足と構成の良し悪しを実装前に判断できます。

既存ページを狭い範囲で直す依頼

改修では「料金ページのヒーローだけを対象に、主要な案内をスマートフォンでも最初の範囲に表示する。既存のボタン部品と色の定義を再利用し、文言と遷移先は変えない。対象外のファイルは変更せず、実装後に指定した二つの幅で表示を確認する」のように書きます。変更対象と禁止事項を同時に示すことで、意図しない全面改修を防げます。

表示確認を依頼するときの書き方

Browserでの確認は「ページを見て」だけで終わらせず、URL、表示幅、状態、期待結果を指定します。「ローカルの料金ページを狭い画面と広い画面で開き、ヒーローの見出し、主要なボタン、料金カードの横はみ出しを確認する。問題があれば画面と原因を報告し、修正後に同じ条件で再確認する」と依頼すれば、検査結果を比較しやすくなります。

よくある失敗と立て直し方

失敗の多くは、Codexの能力不足より、目的と確認方法を一度に省いたことから起こります。完成ページを一回で求める、参考画像だけを渡す、表示確認を行わずコードの完成だけで判断する、公開範囲を確認しないといった進め方は、後半で大きな手戻りを生みます。問題が起きたら依頼を長くして押し切るのではなく、最後に正しかった段階へ戻り、ずれた判断を一つずつ直してください。立て直す際は、残す部分と直す部分を言葉で分け、変更範囲を狭く戻します。

一度で全部作らせて修正箇所が分からない

全面生成の結果が期待と違う場合は、見た目の好みを追加して作り直す前に、構成、文章、実装、表示のどこからずれたかを切り分けます。構成が正しいならコードだけを小さく直し、文章が違うなら原稿を確定してから再配置します。完成品同士を何度も比べるより、判断点を一つ前へ戻す方が、残したい部分を守りながら早く立て直せます。

参考画像に似ているが自社らしくない

参考画像から何を取り入れるかを指定しないと、色、余白、構成、文体まで同時に引っ張られます。参考にするのは文字階層と余白だけ、色と写真は承認済み素材を使う、セクション順は自社の訴求に合わせる、というように要素を分けてください。似せることを目的にせず、訪問者が理解しやすい設計上の特徴だけを抽出すると、自社の情報に合うページへ戻せます。

コードは正しいのに成果へつながらない

表示も操作も問題がないのに主要な行動が増えない場合は、技術的な修正より、訪問者、約束する価値、根拠、案内文言の仮説を見直します。閲覧状況、主要なボタンの利用、フォーム完了を分け、どの段階で離れているかを確認してください。Codexには観測できた事実と変更したい一項目を渡し、前後を比べます。結果の出ない理由を推測だけで埋めないことが重要です。

目的と確認基準を握ればCodexで制作を進めやすい

Codexでランディングページを作るときは、訪問者と主要な案内を決め、承認済みの原稿と素材を渡し、構成からセクション単位の実装へ進めます。参考画像には見る場所を説明し、BrowserではURL、表示幅、状態、期待結果を指定して、同じ条件で修正前後を確かめてください。Sitesを使う場合は、保存した版と本番公開を区別し、公開範囲を必要な相手だけに絞ります。Codexへ任せる範囲を小さく切り、人が目的、事実、権利、公開判断を握れば、速さを保ちながら確認可能なランディングページ制作を進められます。