※この記事は2026年8月11日時点の情報をもとにしています。Codex、GitHub、Cloudflare Pages、Googleの画面や機能は今後変わる可能性があります。
「副業で進めている案件に、きちんとしたホームページが必要だ」
そう思ったものの、私はプログラミング未経験でした。HTMLとCSSの違いもよく分からず、GitHub、DNS、SSL、デプロイと言われても、最初は何の話か分かりませんでした。
それでも最終的には、通常ページ5ページと独自の404ページを備えたホームページを独自ドメインで公開できました。ファイルはGitHubで管理し、Cloudflare Pagesから配信。HTTPS、www付きURLからの転送、Google Search Console、アクセス解析の同意設定、パソコンとスマートフォンの表示まで確認しています。
最終確認では、6ページ・38ファイルを対象に機械検査を行い、ローカル版と公開版の一致まで確かめました。
ただし、これは「AIへ1行頼めば、5分で完璧なサイトができた」という話ではありません。実際に分かったのは、AIがコードを書けることと、ホームページを安全に公開できることは別だということでした。
この記事では、私とOpenAIのコーディングエージェント「Codex」が何を分担し、どの順番で公開まで進めたのかをまとめます。
結論｜コードを書けなくても、目的と完成条件は決められる
プログラミング未経験でも、Codexと一緒ならホームページの公開まで進められました。ただし、AIへの丸投げではありません。
私が担当したのは、次の判断です。
- 何のためにホームページを作るのか
- 誰に見てもらいたいのか
- どのページが必要か
- 何を載せ、何を載せないか
- どの文章や画像を採用するか
- どこまでできたら完成か
- 外部へ公開してよい状態か
- 個人情報や秘密情報が混ざっていないか
Codexには、その判断をHTML、CSS、JavaScriptなどへ変換し、ファイルの編集、検査、修正を進めてもらいました。
たとえるなら、Codexが大工で、私は施主です。大工は家を建てられますが、誰が使い、何部屋必要で、どこまで作るかは施主が決めます。
コードを書けなくても、目的と完成画面への違和感は伝えられます。この2つを言葉にできたことが、公開まで進めた大きな理由でした。
Codexは、コード例を答えるだけのAIではなかった
普通のチャットAIからコード例をもらっても、初心者には次の壁があります。
- どのファイルへ入れるのか分からない
- 既存部分を消してよいのか判断できない
- エラーの原因を追えない
- 作ったファイルを公開する方法が分からない
- 修正前へ戻す方法が分からない
Codexは、作業フォルダやリポジトリを調べ、必要なファイルを編集し、ローカルのコマンドや検査を実行し、何を変えたかを示せます。私の感覚では、やり方を説明する相談相手というより、同じ作業場で手を動かす担当者に近い存在でした。
OpenAIも現在、Codexの利用例として、リポジトリ、スクリーンショット、デザイン案などからWebサイトを作り、ローカル検査後にプレビューURLを確認する流れを案内しています。
もちろん、Codexが触れられる範囲は、利用環境、権限、接続しているサービスで異なります。「Codexなら何でも勝手に公開できる」という意味ではありません。
チャット型AIとエージェント型AIの違いから確認したい場合は、エージェント型AIとチャット型AIの違いも参考にしてください。
制作前に決めたのは、技術ではなく4つの設計
制作前は、最大の難所はプログラミングだと思っていました。実際に時間がかかったのは、「初めて訪れた人が迷わないサイトとは何か」を決めることでした。
最初に整理したのは、次の4項目です。
- 目的：副業案件の全体像と各活動への入口を伝える
- 想定読者：初めて案件や活動を知った人
- 取ってほしい行動：内容を理解し、必要な記事やサービスへ移動してもらう
- 今回は作らないもの：会員機能、決済、ログイン、問い合わせフォーム
作るものだけでなく、今は作らないものを決めたことが重要でした。機能が増えるほど、設計、保守、個人情報管理、セキュリティの負担も増えるからです。
ページも先に役割を分けました。
- トップページ
- 活動内容を紹介するページ
- 運営者や背景を紹介するページ
- 今後の構想を紹介するページ
- プライバシーや免責事項を掲載するページ
- 存在しないURLを開いたときの404ページ
目次を作らずに記事を書き始めると話が重複するように、ページ構成を決めずに実装を始めると、同じ説明やリンクが増えます。ホームページにも、コードを書く前の目次が必要でした。
ゼロから公開までに行った9つの工程
今回の制作は、次の9工程で進めました。途中で画面を確認し、必要なら前の工程へ戻っています。
要件を整理し、実装前に質問してもらう
最初から「ホームページを作って」と頼まず、目的、読者、必要なページ、掲載内容、更新頻度、個人情報の扱いを伝え、不足情報を質問してもらいました。
分からないまま実装を始めるより、先に問いをそろえる方が、大きな作り直しを減らせます。
ページごとの文章と順番を決める
デザインより先に、各ページが何を伝えるかを整理しました。文章づくりもCodexに手伝ってもらいましたが、次の点は私が1文ずつ確認しています。
- 本当に自分が考えていることか
- 実際に行っていることだけが書かれているか
- 将来構想を現在の実績のように見せていないか
- 強すぎる断定がないか
AIが整えた文章でも、本人の実感や事実確認までは自動で保証されません。
静的サイトを選ぶ
今回は、HTML、CSS、JavaScriptを中心とした静的サイトにしました。毎日記事を追加する場所ではなく、活動案内を中心とした比較的固定的なサイトだったからです。
会員登録、決済、コメント、データベースは不要でした。Cloudflare Pagesはフレームワークを使わないサイトにも対応しているため、必要以上に複雑な構成を避けられました。
ローカルで作り、画面を見て直す
Codexが初期版を作った後も、すぐ公開しませんでした。自分のパソコンで表示し、画面上の違和感を具体的に伝えます。
「スマートフォンで見出しが不自然に折り返す」「画像が大きく、その下の情報が見えない」「同じリンクが多い」など、CSSの用語を知らなくても問題は説明できます。
GitHubへ公開用ファイルだけを置く
完成に近づいたファイルは、公開専用のGitHubリポジトリで管理しました。GitHubのリポジトリには、コードやファイルと、それぞれの変更履歴を保管できます。
ただし、作業用フォルダ全体をそのまま公開してはいけません。現在のファイルだけでなく過去の履歴も確認できるため、公開してよいファイルだけを分離しました。
Cloudflare Pagesから配信する
GitHubとCloudflare Pagesを接続し、指定したブランチへ変更を送るとサイトが更新される構成にしました。
役割を簡単に言えば、GitHubはファイルと履歴を管理する場所、Cloudflare PagesはWebサイトとして配信する場所です。Cloudflare Pagesでは、デプロイ結果、プレビューURL、関連するコミットも確認できます。
独自ドメイン、DNS、HTTPSを設定する
Cloudflare側の仮URLで表示を確認した後、独自ドメインを接続しました。DNSは、ドメイン名でアクセスした人を配信先へ案内する仕組みです。
さらにHTTPS接続を有効にし、独自ドメイン、www付きURLからの転送、存在しないURLの404表示を確認しました。設定画面で有効と表示されることと、実際のURLが正しく開くことは別々に確かめます。
検索とアクセス解析を設定する
サイトマップを用意し、Google Search Consoleへ登録しました。サイトマップは重要なページを検索エンジンへ伝える助けになりますが、送信すればすべてのページが必ず登録されるわけではありません。
アクセス解析では、訪問者が選択する前の同意状態と、選択後の更新を分けました。計測したいからといって、利用者への説明や選択肢を省いてよいわけではありません。
公開URLの実物を検査する
Cloudflare Pagesのデプロイ成功だけでは完成にしませんでした。公開URLで、全ページ、リンク、画像、404、転送、パソコン表示、スマートフォン表示、ブラウザエラー、ローカル版との一致を確認しました。
最終的には、6ページ・38ファイルを検査対象として明文化しました。大切なのは数の多さではなく、何を確認したかを曖昧にしないことです。
私、Codex、外部サービスの役割を分けた
役割を混ぜると、「誰が判断するのか」「どこまで終わったのか」が分かりにくくなります。今回の分担を表へまとめると、次のようになります。
Codexは、私の代わりに目的を決める存在ではありません。私の判断を、実際に動くファイルへ翻訳する担当者でした。
公開して初めて分かった3つの落とし穴
制作から公開までは一直線ではありませんでした。特に大きかったのは、次の3点です。
デプロイ成功は、表示成功ではない
公開処理が成功しても、画像の比率、文章の切れ、スマートフォンの横はみ出し、リンク先の誤りまでは保証されません。
そこで完成状態を、次の5段階へ分けました。
- 実装済み
- ローカル検証済み
- GitHub反映済み
- デプロイ済み
- 公開版の同等性を検証済み
「デプロイ済み」で止めず、公開された実物を確認して初めて完成とします。これはAIでブログを作るときにも同じです。AIでブログ記事を公開する前に確認することでも詳しく整理しています。
新しいHTMLと古いCSSが混ざった
実際に起きたのが、ブラウザのキャッシュによる画像の縦伸びでした。新しいHTMLは読み込まれているのに、古いCSSが一時的に残り、横幅と高さの条件がかみ合わなくなったのです。
原因を確認した後、CSSのURLへ版番号を付け、版番号がない状態を検査で止める仕組みを追加しました。
一度直した不具合は、「次は気をつける」ではなく、機械検査へ組み込んで再発を防ぐ方が確実です。
現在のファイルだけでは、公開安全の確認にならない
GitHubでは、現在のファイルから消した情報が過去の履歴に残ることがあります。確認対象は本文だけではありません。
- ファイル名
- Gitの変更履歴
- コミット作成者名とメールアドレス
- コミットメッセージ
- 自動処理のログ
- 公開用成果物
- README
- ローカル環境の絶対パス
「個人情報がないか確認して」だけではなく、どこまで確認したのかを答えてもらう必要がありました。
AIへ任せる作業と、人が承認する作業を分ける
Codexが操作できても、すべてを自動実行させるべきではありません。
ローカルの文章修正、余白調整、検査などは、対象フォルダを限定して進めやすい作業です。一方で、次は人が内容を確認し、対象を指定して承認する必要があります。
- 有料サービスへの申し込み
- ドメインの購入や契約変更
- DNS設定の変更
- 公開リポジトリの作成
- 本番環境への公開
- アクセス解析の設定
- 外部アカウントの権限変更
- ファイルや履歴の削除
- 個人情報や秘密情報の送信
OpenAIの公式案内でも、Codexの安全設定は、技術的に触れられる範囲を決めるサンドボックスと、範囲を越えるときに確認する承認方針を組み合わせる考え方です。
AIができることと、AIに判断させてよいことは別です。最初は読み取りやローカル修正から始め、外部変更は1件ずつ対象と完了条件を固定すると安全です。
最初にCodexへ渡す指示文
同じようにホームページを作るなら、最初から実装を頼むより、要件を整理する質問から始める方が安全です。
私はプログラミング未経験です。
副業案件の公式ホームページを作りたいと考えています。
最初の段階では、まだファイルを作成・編集しないでください。
まず、目的、想定読者、必要なページ、掲載内容、
必要な機能、不要な機能、更新頻度、公開方法について、
不足している情報を質問してください。
質問への回答後、次を提案してください。
1. サイトの目的と想定読者
2. 推奨するページ構成
3. 各ページの役割
4. WordPress、静的HTMLなど実装方式の候補と選定理由
5. 使用する外部サービス
6. 私が用意する文章・画像
7. 制作から公開までの工程
8. 想定されるリスクと注意点
実装時は、次の条件を守ってください。
・確認できないURL、ID、アカウント情報、外部設定を推測しない
・個人名、住所、電話番号、個人メール、認証情報を公開ファイルへ入れない
・作業用フォルダ全体を公開しない
・変更したファイルと変更理由を毎回示す
・専門用語は初心者向けの日本語で説明する
・ローカルで表示確認するまで公開しない
・パソコンとスマートフォンの両方を確認する
・外部設定、課金、DNS変更、リポジトリ公開、push、
デプロイ、削除は、私の明示承認なしに行わない
公開前には、次を別々に確認してください。
・実装済み
・ローカル検証済み
・GitHub反映済み
・デプロイ済み
・公開版の同等性検証済み
個人情報確認では、現在のファイルだけでなく、
ファイル名、Git履歴、作成者名、メールアドレス、
コミットメッセージ、自動処理ログ、公開成果物も確認してください。
公開完了と報告する前に、実際の公開URLを開き、
全ページ、リンク、画像、404、リダイレクト、
パソコン表示、スマートフォン表示、
ブラウザエラーを確認してください。
この指示文だけで、どのサイトも自動的に完成するわけではありません。実際のフォルダ、利用サービス、公開先に合わせて、作業範囲と承認条件を変えてください。
特に、確認できないIDやURLを推測させないこと、外部変更とローカル作業を分けることが重要です。
まとめ｜未経験でも「違和感を言葉にする力」から始められる
私は、プログラマーになってからホームページを作ったわけではありません。
必要なものを言葉にし、Codexに実装してもらい、画面を確認し、違和感を伝え、修正し、安全性を確認しながら公開まで進みました。
DNSやGitHubなど、初めて聞く言葉は何度も出てきます。表示が崩れ、公開後に直したこともありました。AIの提案をそのまま採用できない場面もあります。
それでも、「分からないから始められない」状態から、分からないことを確認しながら前へ進める状態へ変われました。
最初の一歩は、コードの勉強を全部終えることではありません。「誰のために、何を伝えるサイトを作りたいか」を1文で書き、Codexへ不足情報を質問してもらうことです。
参考にした公式情報
- OpenAI｜Deploy an app or website
- OpenAI｜Agent approvals & security
- GitHub Docs｜About repositories
- Cloudflare Pages Docs｜Git integration
- Cloudflare Pages Docs｜Custom domains
- Cloudflare Pages Docs｜Serving Pages
- Cloudflare Docs｜Universal SSL
- Google Search Central｜What Is a Sitemap
- Google for Developers｜Set up consent mode on websites
コメント