2026年8月22日、私はCodexに長い依頼文を渡しました。
作りたかったのは、AIやWeb制作に興味を持った初心者が、実際に手を動かすための情報サイトです。サイト名は「AI副業実践ノート」。白を基調にして、記事はMDXで管理し、GitHubからCloudflare Pagesへ公開する。必要なページやSEO設定も、最初から細かく指定しました。
その日のうちに、最初の公開版は動きました。
ただし、公開できたことと、読みたくなるサイトになったことは別でした。日付の不整合、実態に合わない広告表記、輪郭の薄い運営者情報。そして、間違いではないけれど妙に整いすぎた文章。公開後に気づき、直したものがいくつもあります。
この記事は、完成までのきれいな手順書ではありません。このサイトを実際に作り、公開してから手直しした記録です。
この記事の制作について
構成整理、実装、推敲にはChatGPTとCodexを使っています。掲載している作業内容は運営者が実際に行ったものに限り、事実確認と公開の判断は運営者が行っています。AIを使っていないように見せるのではなく、どこで人が判断したかまで残す方針です。
最初の依頼は、かなり具体的だった
最初にCodexへ伝えた条件の一部が、こちらです。
AI・ChatGPT・Codex・Web制作・副業に興味がある初心者向けの
日本語メディアを作る。
技術はAstroとTypeScript。
記事はMarkdownまたはMDXで管理する。
GitHubで変更履歴を残し、Cloudflare Pagesで公開する。
白を基調にした、信頼感のあるビジネスメディア風のデザイン。
スマートフォンで読みやすく、高速に表示できること。
最初はアフィリエイトリンクを入れない。
SEOを目的に記事を大量生成しない。このほか、トップ、記事一覧、カテゴリ、運営者情報、法務ページなどのページ構成も指定しました。canonical、OGP、サイトマップ、RSS、構造化データ、関連記事も必要。広告コードは記事へ直接書かず、後から管理しやすい形にする——というところまで決めています。
細かく書いたのは、技術に詳しいふりをするためではありません。「いい感じのサイトを作って」だけでは、完成したかどうかを私自身が判断できないからです。
読者は誰か。最初に広告を置くのか。記事をどう増やすのか。譲れない条件だけでも言葉にすると、Codexとのやり取りはかなり進めやすくなりました。
技術より先に、続け方を決めた
Astro、TypeScript、MDXを選んだ理由は、流行しているからではなく、少人数で更新しやすいと考えたからです。
| やりたいこと | 選んだもの | 今回の理由 |
|---|---|---|
| 記事中心のサイトを軽く表示する | Astro | 静的なHTMLとして公開しやすい |
| 設定の抜けを早めに見つける | TypeScript | 記事データの形をチェックできる |
| 本文をファイルで管理する | MDX | 記事の中で共通部品も使える |
| 変更履歴を残す | GitHub | 何を直したか後から追える |
| 更新を自動で公開する | Cloudflare Pages | GitHubと連携してビルドできる |
たとえば記事には、タイトル、説明文、公開日、更新日、カテゴリ、タグ、著者、アイキャッチ、下書き状態を設定できます。記事ファイルを追加すると、記事一覧やカテゴリ、RSSにも反映されます。
運営を続けるうえで、この「後から迷わない仕組み」はデザインと同じくらい重要でした。
Codexが作ったのは、トップページだけではない
Codexには、ページの見た目だけでなく、サイト全体の土台を作ってもらいました。
- トップ、記事一覧、カテゴリ、記事詳細
- 運営者情報、プライバシーポリシー、免責事項、お問い合わせ
- スマートフォン用メニューとレスポンシブ表示
- canonical、OGP、Twitter Card
- ArticleとBreadcrumbListの構造化データ
- sitemap.xml、robots.txt、RSS
- パンくず、関連記事、内部リンク
- 共通のPR表記と、広告コードを別ファイルで管理する仕組み
作業中、私はコードを一行ずつ受け取って貼り付けていたわけではありません。Codexがプロジェクト内のファイルを作り、必要な場所を修正し、型チェックとビルドを実行しました。エラーが出れば、その原因をたどって直すところまで進めています。
この工程は速かったです。一方で、速いからこそ見落としやすいこともありました。
初回公開はできた。でも、そのままにはしなかった
GitHubへ保存したファイルをCloudflare Pagesと連携し、初回版を公開しました。
Cloudflare側の主な設定は、次の三つです。
| 設定 | 内容 |
|---|---|
| Production branch | main |
| Build command | npm run build |
| Build output directory | dist |
CloudflareとGitHubへのログイン、本人確認、連携の許可は私が行いました。どの項目を設定するか、反映後に何を確かめるかはCodexと一緒に進めています。
その後、取得した独自ドメイン aijissen-note.com をCloudflare Pagesへ接続。canonical、OGP、サイトマップ、robots.txt、RSSも新しいURLへそろえました。
ここまでで、サイトは表示されます。リンクも動きます。ビルドも通ります。
けれど公開画面を読み直すと、コードの検査では見つからない違和感が残っていました。
公開後に直したのは、こういうところ
| 見つかった問題 | なぜ気になったか | 実際に直したこと |
|---|---|---|
| 初期記事の公開日がばらばら | 存在しなかった過去まで演出する必要はない | 5本とも実際の初回公開日、2026年8月22日に統一 |
| 運営者名が「編集部」だけ | 誰が何を試しているサイトなのか見えない | 実際にAIとWeb制作を試す運営者としてプロフィールを変更 |
| 広告がないのに「広告を利用しています」 | 表示と実態が合っていない | 「利用する場合があります」へ変更 |
| 一部の改行や句読点が不自然 | スマートフォンで読むと文章の癖が目立つ | 段落の切り方と文の長さを見直した |
| 横幅の狭い画面で表示が崩れる箇所があった | 本文より操作のしづらさが先に来る | 横方向のはみ出しを修正 |
どれも、派手な機能追加ではありません。それでも、公開日や広告表記はサイトの信用に直結します。「動いているから完成」と区切らず、公開された画面を読者と同じ順番で見る必要がありました。
ロゴの一文字と、ASPの書き方も変えた
ヘッダーのロゴには、当初「実践ノート」の頭文字として「実」を入れていました。ところが実際の画面で見ると、このサイトが何を扱うのか一目では伝わりません。
そこで、ロゴの記号を「AI」に変更しました。小さな修正ですが、今はこちらの方がサイト名と素直につながります。
もう一つ、文章の中で特定のASP名を前面に出すのもやめました。将来は複数のサービスを使う可能性があります。サイトの仕組みや方針を説明する場所では「アフィリエイトサービス」「ASP」と書き、個別のサービス名は必要な記事で扱うことにしました。
最初に決めた言葉を守り続けるより、運営方針に合わなくなったら直す。公開後の作業は、その繰り返しになりそうです。
一番大きな修正は、この文章そのものだった
初稿にも、嘘は書いていませんでした。手順は整理され、見出しもそろい、結論もわかりやすくまとまっていました。
それなのに読み返すと、面白くない。
困ったのは誤字よりも、私がどこで迷い、何を見て直したのかがほとんど残っていなかったことです。正しい説明だけが並んでいても、それなら公式ドキュメントを読めば足ります。このサイトまで来てもらう理由にはなりません。
そこでこの記事を、一般的な「サイト公開の6ステップ」から、実際の日付と修正内容が残る制作記録へ書き換えました。AIを使った事実も明記しています。
AIに下書きを任せること自体は、今後もあります。ただし、体験していないことを体験談にしない。判断した理由を削らない。きれいにまとめるためだけの結論を足さない。この三つは、記事を公開するときの基準にします。
現時点で、実際にできていること
2026年8月23日時点では、次の状態まで確認できています。
- 独自ドメインで公開され、HTTPSで表示できる
- 主要な32ページが静的に生成される
- 20本の公開記事をMDXで管理している
- 型とコンテンツの確認で、エラー・警告・ヒントはいずれも0件
- 記事一覧、カテゴリ、パンくず、関連記事、RSSが動作する
- canonicalとサイトマップが独自ドメインを指している
- 提携が完了したサービスの広告コードを専用ファイルで管理している
- 広告のある記事と法務ページに、現在の運営状態を反映している
反対に、まだできていないこともあります。
- 契約して使ったサービスの操作画面や使用感を含む比較記事
- 検索流入や読了率をもとにした改善
- 収益の発生
「サイトを公開した」と「副業として成果が出た」の間には、かなり距離があります。今書けるのは前者までです。収益が出ていない段階で、成功談のようには見せません。
Codexが得意だったこと、人が決めたこと
今回の作業で、Codexは実装と確認を大きく前へ進めてくれました。ただ、任せられる作業と、私が引き受ける判断ははっきり分かれました。
| Codexが得意だったこと | 運営者が決めたこと |
|---|---|
| ファイル構成の設計と実装 | 誰に何を届けるサイトか |
| Astro・MDX・SEOの設定 | どの記事を公開するか |
| 共通部品の作成 | 文章の温度と残す体験 |
| 型チェックとビルド | 外部サービスとの連携を許可するか |
| 修正箇所の洗い出しと反映 | 表示内容に責任を持てるか |
コード経験が少なくても、Codexを使えば公開までの距離は短くできます。ただし、最終的な内容まで自動で良くなるわけではありません。むしろ実装が速くなったぶん、「なぜこの表現にするのか」を決める時間が目立ちました。
これからは、記事数を急いで増やすより、実際に試した内容を一つずつ足していきます。次に同じ記事を更新するときは、公開後に起きたことや、うまくいかなかったことも追記するつもりです。
公開記事が15本になった時点で、入口から広告記事までのつながりも見直しました。アフィリエイト記事の導線を組み直した記録に、追加したリンクと今後記録する数字を載せています。
Codexそのものを先に知りたい場合は、Codexとは？初心者が最初に知っておきたいことへ。一般的な制作手順は、CodexでWebサイトを作るには？丸投げしない6つの手順にまとめています。
サイト制作を学びながら進めたい人には、Web制作は独学できる？AIを先生に変える学び方も参考になるはずです。
更新記録
- 2026年8月22日：サイトと記事の初回版を公開
- 2026年8月23日：独自ドメイン、ロゴ、ASP表記、文章方針を反映し、制作記録として全面改稿
- 2026年8月23日：初めての広告掲載と収益記事の追加を反映