個人開発のホームページはCloudflare+GitHubで。AIで更新する静的サイトの作り方と料金

D-U-N-S番号の取得やアプリ紹介をきっかけに、個人開発の事業サイトを準備。静的サイトとCMSの違い、AIでの記事更新、GitHub Actionsによる公開、Cloudflare Pagesの登録手順と費用を解説します。

公開 更新
  • Cloudflare
  • GitHub
  • 個人開発

個人でアプリを作っていると、アプリ本体の開発以外にも、事業紹介やサポートのためのホームページが必要になります。

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が唯一の最安サービスというわけではありません。同様に無料から利用できるサービスはあります。そのうえで、個人開発の紹介サイトを低コストで始める、という目的に合う選択肢です。

公開の仕組みと、それぞれの役割
  1. AI+人間記事・HTMLの作成と確認
  2. GitHubファイルと変更履歴を管理
  3. GitHub Actions承認した変更の公開処理
  4. 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段階です。

  1. 記事のテーマ、伝えたい内容、体験を整理する。
  2. AIに、既存のデザインに合わせた記事ページの作成を依頼する。
  3. GitHubに変更案を登録する。
  4. 人間が文章・根拠・画面表示・変更内容を確認する。
  5. 確認できた変更を、公開用の main ブランチに取り込む。
  6. GitHub ActionsがCloudflare Pagesへ公開する。

GitHub上で変更案を確認する仕組みを「プルリクエスト」、確認した変更を取り込む操作を「マージ」と呼びます。1人で運営する場合でも、作成と公開の間に確認する段階を置けます。

AIへの依頼は、たとえば次のように具体化します。

既存の記事ページを参考に、この原稿をHTML化してください。見出し、表、参考リンクを整え、スマートフォンでも読みやすくしてください。記事一覧とサイトマップも更新してください。原稿にない体験談や数字は追加せず、確認が必要な記述は指摘してください。

公開前には、文章の正確さ、スマートフォンでの表示、リンク先、画像の権利、個人情報や秘密情報の混入を確認します。AIのレビューも補助に使えますが、AI同士で確認させるだけで正しさが保証されるわけではありません。

記事が増えたら、Markdownで本文を書いてHTMLを生成する仕組みに移ることもできます。最初から大きな仕組みを作らず、更新が負担になった段階で導入すればよいと考えています。

記事を書いてから公開するまで
  1. 1. 原稿を用意伝えたい内容を整理
  2. 2. AIでHTML化既存デザインに合わせる
  3. 3. 人間が確認文章・根拠・表示をチェック
  4. 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]

  1. Cloudflareにログインし、「Domain Registration(ドメイン登録)」の「Register Domains(ドメインを登録)」を開きます。
  2. 希望するドメイン名を検索し、取得できる候補を確認します。屋号に近く、短くて入力しやすい名前を選びます。
  3. 取得料金・契約年数・次回更新日を確認します。初年度の安さだけでなく、更新料金、税金、決済通貨も含めて比較します。
  4. 登録者の氏名・住所・電話番号・メールアドレスを正確に入力し、支払い方法を登録します。Cloudflareの登録者情報はASCII文字での入力が必要なため、日本語の氏名・住所はローマ字などで入力します。
  5. 規約と支払い金額を確認し、購入を確定します。
  6. 登録確認メールを確認し、求められたメールアドレス認証を完了します。自動更新の設定と、支払い方法の有効期限も確認しておきます。

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方式と直接連携方式の自動公開を同時に動かす必要はありません。

独自ドメインとサイトのファイルを結び付ける
  1. 独自ドメイン例:example.com
  2. DNSの設定ドメインの接続先を指定
  3. Pagesの設定Custom domainsで関連付け
  4. サイトを表示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のような個人規模の運営では、アプリ開発に使う時間を確保しながら、事業の情報を継続して届けられる構成を選びたいと考えています。

参考資料

  1. Google Play Consoleアカウントの作成に必要な情報
  2. Cloudflare Pages 製品案内
  3. WordPress公式:Hardening WordPress
  4. Cloudflare公式:Direct UploadとCIの連携
  5. Cloudflare公式:Direct Upload
  6. Cloudflare公式:Custom domains
  7. Cloudflare Pagesの制限
  8. GitHub公式:scheduleイベント
  9. Cloudflare公式:Static HTML
  10. GitHub Actionsの料金と無料枠
  11. Cloudflare公式:新しいドメインの登録
← 開発ブログの記事一覧へ