個人開発のホームページはCloudflare+GitHubで。AIで更新する静的サイトの作り方と料金
D-U-N-S番号の取得やアプリ紹介をきっかけに、個人開発の事業サイトを準備。静的サイトとCMSの違い、AIでの記事更新、GitHub Actionsによる公開、Cloudflare Pagesの登録手順と費用を解説します。
個人でアプリを作っていると、アプリ本体の開発以外にも、事業紹介やサポートのためのホームページが必要になります。
SANGE Studioでも、D-U-N-S番号の取得に向けた準備や、アプリの紹介ページを用意するために、Webサイトが必要になりました。できるだけ費用をかけず、日々の管理にも時間を取られない構成にしたい。そこで選択肢になるのが、Cloudflareで静的サイトを公開し、GitHubでファイルを管理する方法です。
記事を更新するときは、AIにHTMLの作成や修正を手伝ってもらい、人間が内容と表示を確認してから公開します。個人規模の事業サイトなら、この構成で十分な場面は多いと考えています。
この記事では、選ぶ理由から公開手順、費用までを説明します。料金・仕様は2026年10月27日確認時点の情報です。
1. D-U-N-S番号の取得とアプリ紹介をきっかけに、サイトを準備する
D-U-N-S番号は、企業や事業体を識別するための9桁の番号です。Google Playの組織アカウントを作成する場合、原則としてこの番号が必要になります。
Google Playは、組織アカウントの登録情報として、D-U-N-S番号に加えて「組織のウェブサイト」も求めています。[1]
ここは混同しやすいところです。Google Playがウェブサイトを求めることと、すべてのD-U-N-S番号の申請でサイトが一律必須であることは、別の話です。 D-U-N-S番号を申し込む際の必要情報は、利用する窓口の案内を確認してください。
いずれにしても、事業の実態を説明できるページと、アプリの紹介・サポートページは、その後の運営でも役立ちます。まずは次の内容を用意すれば、小さく始められます。
| ページ | 掲載する内容 |
|---|---|
| トップ | 屋号、取り組んでいる事業、アプリへの案内 |
| 事業者紹介 | 運営者・事業内容など、申請情報と矛盾しない説明 |
| アプリ紹介 | 機能、画面画像、Google Playへのリンク |
| サポート | 問い合わせ方法、よくある質問 |
| プライバシーポリシー | 実際のデータ取得や外部サービスの利用に即した説明 |
サイトを用意すれば審査に通る、という意味ではありません。掲載する情報は、実際の事業や申請内容と整合させることが大切です。
2. 費用と管理の手間を抑えるなら、静的サイトが候補になる
ホームページを持つために、必ずしもレンタルサーバーを契約したり、WordPressを設置したりする必要はありません。
Cloudflare Pagesは、HTMLや画像などを公開できるサービスです。無料プランから利用でき、サービスが用意する ○○.pages.dev というURLでも公開できます。[2]
GitHubは、サイトのファイルと変更履歴を管理する場所として利用します。「いつ、どこを直したか」を確認でき、問題があれば過去の状態に戻すための手掛かりも残せます。
役割を整理すると、次のようになります。
| 役割 | 利用するもの |
|---|---|
| 文章やHTMLの作成・修正 | AIと人間 |
| ファイルと変更履歴の管理 | GitHub |
| 確認後の公開作業の自動化 | GitHub Actions |
| 閲覧者へのページ配信 | Cloudflare Pages |
Cloudflareが唯一の最安サービスというわけではありません。同様に無料から利用できるサービスはあります。そのうえで、個人開発の紹介サイトを低コストで始める、という目的に合う選択肢です。
- AI+人間記事・HTMLの作成と確認
- GitHubファイルと変更履歴を管理
- GitHub Actions承認した変更の公開処理
- Cloudflare PagesHTML・画像を読者に配信
GitHubで管理し、Actionsで公開。読者へページを届けるのはCloudflare Pagesです。
3. 静的ホスティングとCMSの違い
静的ホスティングは、あらかじめ作ったHTMLや画像を、そのまま閲覧者に届ける仕組みです。
CMSは、記事や画像を管理し、更新しやすくする仕組みです。WordPressが代表的な例です。管理画面から記事を書き、公開日時を設定する、といった操作ができます。
厳密には、この2つは対義語ではありません。CMSで記事を管理し、完成したページを静的サイトとして配信する構成もあります。ここでは分かりやすく、HTMLをGitHubで管理する構成と、一般的なWordPressを自分で設置・運用する構成を比べます。
| 比較する項目 | HTMLを管理する静的サイト | 一般的なWordPressの自己運用 |
|---|---|---|
| 更新方法 | ファイルを修正して公開 | 管理画面から編集・公開 |
| 閲覧時の処理 | 用意したファイルを配信 | PHPやデータベースなどが動作。キャッシュを使う構成もある |
| 保守 | ファイル、公開経路、利用ツールなどを管理 | 本体、テーマ、プラグイン、実行環境なども管理 |
| 予約投稿 | 公開を制御する仕組みを別途用意 | 標準の予約投稿機能を利用可能 |
| 向いている用途 | 事業紹介、アプリ紹介、少人数のブログ | 編集者が多いサイト、頻繁な更新、編集機能が重要なサイト |
HTMLはページの構造を記述するファイルです。従来は、記事を追加するたびにコードを触ることが、静的サイトの負担になりやすい部分でした。AIにその作業を手伝ってもらえると、選びやすくなります。
4. 脆弱性への対応とAIの進化を考えると、公開する仕組みを小さくしたい
Webサイトは、公開して終わりではありません。利用するソフトウェアに脆弱性が見つかれば、更新や確認が必要になります。WordPressの公式資料でも、本体・プラグインなどの更新や、権限・認証の管理が説明されています。[3]
個人開発では、その保守に使える時間が限られています。事業紹介とアプリ紹介が中心なら、閲覧時に動くプログラムやデータベース、一般公開された記事編集用ログイン画面を、自分で運用する必要を減らしたいと考えました。
純粋な静的ファイル配信に絞れば、そうした部分を狙う攻撃の入口を減らせます。ただし、静的サイトでも、GitHubやCloudflareのアカウントが乗っ取られたり、不正なJavaScriptが混入したりすれば被害につながります。安全性は構成と運用の両方で決まります。
私が静的サイトを選びたい理由は、「最近の脆弱性はすべてCMSが原因だから」ではありません。必要な機能に対して、管理するものを少なくできるからです。
さらに、AIがHTMLやCSSの作成を補助できるようになり、ファイルを直接編集する負担も下がりました。セキュリティ上の構成を単純にしながら、更新の手間も抑えられる。この組み合わせが、個人規模では魅力です。
5. 記事はAIでHTML化し、人間が確認してから公開する
想定する更新の流れは、次の6段階です。
- 記事のテーマ、伝えたい内容、体験を整理する。
- AIに、既存のデザインに合わせた記事ページの作成を依頼する。
- GitHubに変更案を登録する。
- 人間が文章・根拠・画面表示・変更内容を確認する。
- 確認できた変更を、公開用の
mainブランチに取り込む。 - GitHub ActionsがCloudflare Pagesへ公開する。
GitHub上で変更案を確認する仕組みを「プルリクエスト」、確認した変更を取り込む操作を「マージ」と呼びます。1人で運営する場合でも、作成と公開の間に確認する段階を置けます。
AIへの依頼は、たとえば次のように具体化します。
既存の記事ページを参考に、この原稿をHTML化してください。見出し、表、参考リンクを整え、スマートフォンでも読みやすくしてください。記事一覧とサイトマップも更新してください。原稿にない体験談や数字は追加せず、確認が必要な記述は指摘してください。
公開前には、文章の正確さ、スマートフォンでの表示、リンク先、画像の権利、個人情報や秘密情報の混入を確認します。AIのレビューも補助に使えますが、AI同士で確認させるだけで正しさが保証されるわけではありません。
記事が増えたら、Markdownで本文を書いてHTMLを生成する仕組みに移ることもできます。最初から大きな仕組みを作らず、更新が負担になった段階で導入すればよいと考えています。
- 1. 原稿を用意伝えたい内容を整理
- 2. AIでHTML化既存デザインに合わせる
- 3. 人間が確認文章・根拠・表示をチェック
- 4. mainへ反映ActionsがPagesへ公開
AIによる作成と公開の間に、人間が内容・表示を確認する段階を置きます。
6. 公開予約や編集機能が必要になったら、サービスを追加する
静的サイトでは、HTMLに未来の日付を書いただけでは公開予約になりません。ファイルをアップロードすると、記事一覧に載せていなくても、URLから閲覧できる場合があります。
予約公開が必要になったら、公開日時を管理できるヘッドレスCMSや、予約デプロイに対応するサービスなどを検討します。ヘッドレスCMSとは、記事の管理機能を提供し、ページの見た目や配信とは切り離して使えるCMSです。
この場合は、指定日時になるまで記事を公開用ファイルに含めず、指定時刻の公開処理と組み合わせる必要があります。非公開原稿がプレビューや公開リポジトリに露出しないかも確認します。
GitHub Actionsの定期実行で組む方法もありますが、実行が遅れることがあるため、厳密な時刻の保証が必要な用途には向きません。[8]
複数人での編集、承認、画像管理、予約公開が日常的に必要なら、CMSの価値は大きくなります。必要な編集機能が増えたときに、構成を見直す方針です。
7. Cloudflareへの登録からWebページ公開まで
ここでは、Cloudflare Pagesの「Direct Upload」を使い、GitHub Actionsから公開する方法を紹介します。Cloudflare公式にも、この組み合わせの手順が用意されています。[4]
CloudflareにはWorkers Static Assetsという静的配信の選択肢もありますが、この記事の設定・コマンドはPages用です。画面名は変更されることがあるため、サービス名と設定内容を確認しながら進めてください。
手順1:CloudflareとGitHubのアカウントを作る
CloudflareとGitHubでアカウントを作成し、メール認証を済ませます。両方で多要素認証を設定しておきます。
まずは無料プランから始められます。既存の独自ドメインを持っていても、公開確認はPagesが用意するURLから始められます。
手順2:独自ドメインを取得する
独自ドメインは、example.com のような、自分で取得して継続利用するWeb上の名前です。サイトのファイルを置くCloudflare Pagesとは別に契約します。独自ドメインの取得には費用がかかり、取得後も継続して利用するには更新料金が必要です。無料の pages.dev でも公開できますが、事業サイトとして継続利用するなら、屋号に合った独自ドメインを用意すると案内しやすくなります。すでに持っている場合は、新たな取得は不要です。
取得先には、Cloudflare Registrarや他社のドメイン登録サービスがあります。Cloudflareでまとめて管理したい場合は、次の流れで取得できます。[11]
- Cloudflareにログインし、「Domain Registration(ドメイン登録)」の「Register Domains(ドメインを登録)」を開きます。
- 希望するドメイン名を検索し、取得できる候補を確認します。屋号に近く、短くて入力しやすい名前を選びます。
- 取得料金・契約年数・次回更新日を確認します。初年度の安さだけでなく、更新料金、税金、決済通貨も含めて比較します。
- 登録者の氏名・住所・電話番号・メールアドレスを正確に入力し、支払い方法を登録します。Cloudflareの登録者情報はASCII文字での入力が必要なため、日本語の氏名・住所はローマ字などで入力します。
- 規約と支払い金額を確認し、購入を確定します。
- 登録確認メールを確認し、求められたメールアドレス認証を完了します。自動更新の設定と、支払い方法の有効期限も確認しておきます。
Cloudflare Registrarで取得したドメインはCloudflareのネームサーバーを利用します。取得後に、他社DNSのネームサーバーへ自由に切り替えられるサービスではありません。また、希望するドメイン末尾を扱っていない場合は、対応する他社サービスで取得します。[11]
ドメインを取得しただけでは、Webページは表示されません。 この後でPagesにサイトを公開し、手順8で独自ドメインと結び付けます。他社で取得した場合も、ドメインの登録先をCloudflareへ移管せずに、Pagesと組み合わせて利用できます。
ドメインの契約には、そのドメインのメールボックスが必ず含まれるわけではありません。info@example.com などでメールを送受信したい場合は、メールサービスを別途検討します。
手順3:GitHubにリポジトリを作る
リポジトリは、サイトのファイルと変更履歴を入れる保管場所です。GitHubの「New repository」から、たとえば sange-studio-web という名前で作成します。
非公開原稿を扱うなら、Privateを選ぶと管理しやすくなります。ただし、非公開リポジトリでも、公開用フォルダに入れたファイルはサイトへ配信されます。
公開するファイルだけを public フォルダに入れます。例として、public/index.html をトップページ、public/apps/index.html をアプリ一覧、public/privacy/index.html をプライバシーポリシーにします。これにより、原稿や設定ファイルを誤ってサイトへ配信する範囲を絞れます。
最初は public/index.html だけでも構いません。AIに事業紹介ページを作成してもらい、手元のブラウザで表示を確認します。
手順4:Cloudflare Pagesのプロジェクトを作る
Cloudflareの管理画面で「Workers & Pages」からアプリケーションの作成に進み、Pagesのファイルアップロード(Direct Upload)を選びます。プロジェクト名を決め、public フォルダの中身をアップロードして初回公開します。[5]
この時点で表示される https://プロジェクト名.pages.dev にアクセスし、トップページを確認します。プロジェクト名とAccount IDは、後の設定で使います。
Direct Uploadで作ったプロジェクトは、後からGit連携型に切り替えられません。切り替える場合は、新しいプロジェクトの作成が必要です。[5]
手順5:公開用のAPIトークンを作る
APIトークンは、GitHub ActionsからCloudflareへ公開するための認証情報です。
CloudflareのAPI Tokens画面からカスタムトークンを作成し、権限に「Account → Cloudflare Pages → Edit」を設定します。対象アカウントも必要なものに絞ります。[4]
作成したトークンは、HTMLやGitHubのファイルに直接書きません。
手順6:GitHubのSecretsに認証情報を登録する
GitHubのリポジトリで「Settings → Secrets and variables → Actions」を開き、次の2つをRepository secretsとして追加します。
| 名前 | 登録する値 |
|---|---|
CLOUDFLARE_API_TOKEN | 作成したAPIトークン |
CLOUDFLARE_ACCOUNT_ID | 公開先のCloudflareアカウントID |
Secretsは、公開処理で使う認証情報を保管する機能です。[4]
手順7:GitHub Actionsの公開設定を追加する
リポジトリに .github/workflows/deploy.yml を作成し、次の内容を保存します。your-pages-project は、自分のPagesプロジェクト名に置き換えてください。
name: Deploy website
on:
push:
branches: [main]
workflow_dispatch:
permissions:
contents: read
concurrency:
group: production-website
cancel-in-progress: false
jobs:
deploy:
runs-on: ubuntu-latest
timeout-minutes: 10
steps:
- name: Checkout
uses: actions/checkout@v6
- name: Check entry page
run: test -f public/index.html
- name: Deploy to Cloudflare Pages
uses: cloudflare/wrangler-action@v4
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
command: pages deploy public --project-name=your-pages-project --branch=main
公式例をもとに、main の更新時だけ公開する最小構成にしています。[4] HTMLの生成処理がないため、ビルドの設定は不要です。この例のチェックはトップページの存在確認だけなので、内容や表示のレビューは別途行います。
初回にPages側の本番ブランチが main になっていることも確認してください。main に設定ファイルを反映したら、GitHubの「Actions」で実行結果を確認し、成功後にサイトを開きます。
上記は読みやすさを優先したバージョンタグ指定です。継続運用では、Actionを確認済みのコミットSHAに固定し、更新もレビューすると公開経路の管理を強化できます。
手順8:取得した独自ドメインをPagesに設定する
Pagesプロジェクトの「Custom domains → Set up a domain」から、利用したいドメインを追加します。[6]
Cloudflare Registrarで取得したドメインは、CloudflareのDNSを利用する状態になっています。他社で取得した example.com のようなルートドメインを利用する場合は、そのドメインをCloudflareに追加し、登録業者の管理画面で指定されたネームサーバーへ変更します。既存メールを利用している場合は、変更前にMXやTXTなどのDNSレコードも引き継ぎます。
www.example.com のようなサブドメインは、外部のDNSサービスにCNAMEを設定する方法もあります。いずれも、DNSレコードの追加だけで済ませず、先にPagesのCustom domainsで関連付けてください。[6]
有効化後は、HTTPSで開けること、画像・リンク・スマートフォン表示が正しいことを確認します。独自ドメインを正式なURLにする場合は、canonicalやサイトマップのURLも合わせます。
もっと少ない設定で始める方法もある
GitHub Actionsでの公開制御が不要なら、PagesでGitHubリポジトリを直接連携する方が設定は少なくなります。Pagesの作成画面でGitリポジトリの取り込みを選び、本番ブランチを main、フレームワークをなし、ビルドコマンドを exit 0、出力先を public に設定する構成です。[9]
この方式なら、GitHubへの変更をCloudflareが検知して公開するため、公開用APIトークンやActionsの設定を省けます。Actions方式と直接連携方式の自動公開を同時に動かす必要はありません。
- 独自ドメイン例:example.com
- DNSの設定ドメインの接続先を指定
- Pagesの設定Custom domainsで関連付け
- サイトを表示HTTPSで公開を確認
ドメインの取得とページの公開は別の作業です。DNS設定とPages側の関連付けをそろえます。
8. 料金はいくらかかる?
この記事のように、HTML・CSS・画像を配信する小規模サイトなら、ホスティングとファイル管理は月額0円から始められます。
| 項目 | 費用 | 補足 |
|---|---|---|
| Cloudflare Pages Free | 月額0米ドル | 静的サイトの公開に利用 |
| GitHub Free | 月額0米ドル | ファイル・変更履歴の管理 |
| GitHub Actions | 無料枠内なら0米ドル | GitHub Freeの非公開リポジトリは月2,000分、Artifact保存500MBの枠。所有アカウントの他用途と共有 |
| Pages提供のURL | 追加費用0円 | ○○.pages.dev |
| 独自ドメイン | 取得・更新料金が別途必要 | ドメイン末尾、登録業者、契約条件により異なる |
| AI | 利用サービス次第 | 無料枠、月額契約、API利用料など |
| 予約公開・フォームなど | 利用サービス次第 | 必要になった機能だけ追加 |
CloudflareはPagesのリクエスト数・帯域を無制限と案内していますが、ファイル数などの制限や利用条件はあります。FreeプランのGit連携ビルドは月500回、ファイル数は最大20,000です。GitHub Actionsで処理してDirect Uploadする場合は、Cloudflare側のビルド枠とGitHub側の実行枠を区別して考えます。[2][7]
GitHub Actionsは、公開リポジトリの標準GitHubホストランナーなら実行時間が無料です。非公開リポジトリでは無料枠の超過に注意します。大型ランナーや保存容量などは別条件です。[10]
たとえば、非公開リポジトリで1回3分の公開処理を月30回実行すると、合計90分です。他の用途で枠を使い切っておらず、保存容量なども枠内なら、月2,000分に収まります。
独自ドメインをすでに持っている場合、サイト追加によるドメインの新規取得費用は不要です。ただし、既存ドメインの更新料は継続してかかります。独自ドメインの価格は初年度の割引だけで判断せず、更新時の金額も確認してください。
なお、APIやデータベース、Pages Functionsなどを追加した場合の費用は、この静的サイトの見積もりには含めていません。
個人開発では、運営を続けられる構成を選ぶ
事業紹介、アプリ紹介、サポート、少人数で更新するブログ。こうした用途なら、CloudflareとGitHubで静的サイトを運営する方法は、有力な選択肢です。
AIにページの作成や修正を手伝ってもらい、人間が確認し、承認した内容を自動公開する。必要な編集機能が増えたら、その段階でCMSや外部サービスを足す。
SANGE Studioのような個人規模の運営では、アプリ開発に使う時間を確保しながら、事業の情報を継続して届けられる構成を選びたいと考えています。