AIで作ったアプリを公開する手順|Cloudflareなら費用はドメイン代だけ

Claude Code や ChatGPT などの AI を使えば、アプリを「作る」ハードルは劇的に下がりました。でも作ったアプリをローカルに置いたままにしていませんか? 実は公開のハードルも同じくらい下がっていて、かかる費用はドメイン代(年1,000〜2,000円ほど)だけです。

夜明け前の滑走路を中心線に沿って低い位置から撮った写真。誘導灯が奥へ続いている
作ったものを、外に出すところまでが1セット

この記事では、AI で作ったアプリを独自ドメインで公開するまでの手順を、実際に私が個人開発アプリ(ポートフォリオで紹介しています)を公開したときの構成でまとめます。

目次

この記事の前提

  • 対象: これから初めてアプリを公開する人(スタートアップ向け)
  • 想定アプリ: 静的サイト、React/Vite などで作った SPA、軽量な Web アプリ
  • ゴール: 独自ドメイン + HTTPS で誰でもアクセスできる状態にする

公開までの5ステップ

全体の流れは次の5ステップです。慣れれば1時間かかりません。

STEP
アプリを GitHub に push する

作ったアプリを Git リポジトリにして GitHub へ push します。あとで Cloudflare と連携すると、push するだけで自動デプロイされるようになります。

STEP
ドメインを取得する(Cloudflare Registrar)

Cloudflare のダッシュボードからドメインを検索して購入します。ここで払うドメイン代が、今回の構成で唯一の費用です。ネームサーバーの設定や WHOIS 情報公開代行は、Cloudflare が勝手にやってくれるので何も考えなくて大丈夫です。

STEP
Cloudflare にデプロイする

Cloudflare の Workers & Pages で「リポジトリと接続」を選び、STEP 1 の GitHub リポジトリを指定します。ビルドコマンド(Vite なら npm run build)と出力ディレクトリ(dist など)を入力すれば、数分で 〜.pages.dev の URL でアプリが動きます。

STEP
独自ドメインを接続する

デプロイしたプロジェクトの「カスタムドメイン」に STEP 2 で取得したドメインを追加します。ドメインも Cloudflare 管理なら DNS レコードも SSL 証明書も自動設定。これが「ドメインも Cloudflare で取る」最大のメリットです。

STEP
動作確認して公開完了

独自ドメインにアクセスして、表示・主要機能・スマホ表示を確認したら公開完了です。以降は GitHub に push するたびに自動で本番へ反映されます。

サーバーは Cloudflare がおすすめ

無料でアプリを公開できるサービスは Vercel や Netlify などいくつもありますが、私のおすすめは Cloudflare です。理由はシンプルで、完全無料で動かせて、商用利用にも制限がないからです。

たとえば Vercel も無料プラン(Hobby)で公開自体はできますが、無料プランは非商用利用が前提です。つまり広告を貼ったり課金機能を付けたり、収益化しようと思った時点で有料プラン(Pro: $20/月〜)への加入が必要になります。「せっかく伸びてきたのに月20ドル固定費が発生する」のは個人開発にはなかなか重い出費です。

CloudflareVercel(Hobby)
無料で公開できるできる
商用利用・収益化無料のまま OK有料プラン($20/月〜)が必要
独自ドメイン + SSL無料無料
自動デプロイ(GitHub 連携)ありあり

最初から Cloudflare で始めておけば、収益化のタイミングで「乗り換えるか、固定費を払うか」を迫られずに済みます。

設定しなくても、妥当な既定値が入っている

実際に運用しているサイトのヘッダを見ると、Cloudflare Pages はこちらが何も設定しなくても、次の2つを最初からやってくれていました。

http でアクセスされても https に飛ぶ

独自ドメインを当てたサイトは、設定しなくても http から https へ301で転送されます。

$ curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}' http://keireki.dev/
301 -> https://keireki.dev/

自前サーバーだと .htaccess やリバースプロキシで書く部分なので、ここを考えなくていいのは地味に大きいです。

HTML にキャッシュ指定が付く

3つの Pages サイトはすべて HTML に public, max-age=0, must-revalidate が付いていました。「毎回サーバーに確認するが、中身が変わっていなければ再ダウンロードしない」という、静的サイトとして妥当な既定値です。

$ curl -sI https://keireki.dev/            # Pages + .dev
cache-control: public, max-age=0, must-revalidate
strict-transport-security: max-age=31536000     ← 頼んでいないのに付く

$ curl -sI https://it-nyumon.com/          # Pages + .com
cache-control: public, max-age=0, must-revalidate
(strict-transport-security は無い)

$ curl -sI https://wadokon.com/            # WordPress + Cloudflare
(cache-control が無い)
cf-cache-status: DYNAMIC

対して、レンタルサーバーで動かしている WordPress のほうは Cache-Control が1つも付いておらず、cf-cache-status: DYNAMIC(エッジにキャッシュされていない)でした。同じ Cloudflare を通していても、配信元が何を返すかで結果はまったく違います。

Pages を選ぶ実質的な利点は、料金より「妥当な既定値が最初から入っていること」かもしれません。 自分で用意するとなると、証明書・HTTPS転送・キャッシュ指定をそれぞれ設定して、そのあと本当に効いているか curl -I で確認する、という作業が発生します。

かかる費用はドメイン代だけ

この構成で必要な費用はドメイン代だけです。目安として .com なら年1,500円前後、.dev や .blog などでも年1,000〜2,000円程度。サーバー代・SSL 証明書代・デプロイ費用はすべて0円です。

「月額いくら」ではなく「年額ワンコイン〜2枚」で自分のサービスが世界に公開できると考えると、やらない理由がないと思っています。

1日あたり7,700リクエスト配信して、課金は0円

手元で動かしている3サイトの、ある1日(2026年9月8日)の実績です。

3サイトの1日あたりのリクエスト数と転送量を並べた表と、配信元ごとにCache-ControlやHSTSの有無が違うことを比べた表
上:この日の合計は7,721リクエスト・122.8MBで課金は0円。下:同じCloudflareでも配信元でヘッダが違う
  • it-nyumon.com(Pages)… 1,100リクエスト / 14.7MB
  • keireki.dev(Pages)… 517リクエスト / 8.4MB
  • wadokon.com(レンタルサーバー+Cloudflare)… 6,104リクエスト / 99.7MB

合計 7,721リクエスト / 122.8MB。3つとも Cloudflare は Free プランのままで、この日の請求は0円です。個人開発の規模なら、本当にドメイン代しかかかりません。

ちなみに転送量がいちばん多い wadokon.com は Pages ではなくレンタルサーバー配信ですが、前段の Cloudflare を通す分にはやはり無料です。

pages.dev のサブドメインのままなら0円。でもおすすめしない

実は Cloudflare にデプロイした時点で 〜.pages.dev のサブドメインが払い出されるので、これをそのまま使えばドメイン代すらかからず完全無料で運用できます。ただし、この使い方はおすすめしません。理由は2つあります。

  • SEO 的に不利
    借り物のサブドメインは独自ドメインに比べて検索評価の面で不利になりやすい
  • あとからの切り替えが高くつく
    途中で独自ドメインに切り替える場合、切り替え前のドメインへのリダイレクト設定が必要になるうえ、SEO 的なドメイン評価は1からやり直しになる

「あとで切り替えればいいや」の代償が意外と大きいので、それなら最初からドメインを買ってしまったほうがいい、というのが私の結論です。年1,000円くらいの出費はケチらず、自己投資と考えて使いましょう。

とはいえ、私自身も3つのうち1つは pages.dev のまま運用しています。

$ npx wrangler pages project list

┌───────────────────────┬────────────────────────────────────────────────┐
│ Project Name          │ Project Domains                                │
├───────────────────────┼────────────────────────────────────────────────┤
│ it-nyumon             │ it-nyumon.pages.dev, it-nyumon.com, www...     │
│ career-sheet-generate │ career-sheet-generate.pages.dev, keireki.dev...│
│ nipponseiha           │ nipponseiha.pages.dev                          │
└───────────────────────┴────────────────────────────────────────────────┘

違いは人に見せるかどうかでした。公開して読んでもらうつもりのものには独自ドメインを当て、動作確認用や自分だけが使うものは pages.dev のままにしています。

おすすめしない理由は上の2つ(SEO と、あとからの切り替え)で、どちらも人に見せることが前提の話です。逆に言えば、最初から人に見せる予定が無いものは、無理にドメインを取らなくていい、というのが実際に運用してみての実感です。

ドメイン取得も Cloudflare がおすすめ

ドメインはお名前.com など国内レジストラでも取れますが、これも Cloudflare Registrar をおすすめします。

  • シンプルでわかりやすい
    管理画面に余計なオプションの勧誘がなく、検索して買うだけ
  • ネームサーバー設定が不要
    取得した瞬間から Cloudflare の DNS に載っているので、設定作業ゼロでデプロイ先に接続できる
  • WHOIS 情報公開代行も自動
    登録者情報の保護(プライバシー保護)が追加料金なしで最初から有効
  • 更新料が卸値
    Cloudflare は上乗せなしの原価で販売しているので、2年目以降に更新料が跳ね上がる心配がない

サーバー(デプロイ先)とドメインが同じ Cloudflare 管理になることで、STEP 4 のドメイン接続が実質ワンクリックになるのも大きいです。

.dev ドメインは HTTPS が強制される

これは取る前に知っておいたほうがいいです。.dev は TLD 全体がブラウザの HSTS プリロードリストに入っているので、HTTPS でしかアクセスできません。

上で載せたヘッダの比較でも、同じ Pages 配信なのに .dev のほうだけ Strict-Transport-Security が付いていました。

Cloudflare Pages は証明書を自動で用意してくれるので実害はありませんが、「ローカルの検証環境を http で立てて同じドメインを当てる」といったことはできなくなります。安さで .dev を選ぶなら、この性質はセットで覚えておくといいです。

補足: アクセスが伸びてきたら

最後に補足です。この記事の構成はあくまでスタートアップ(公開の最初の一歩)向けです。ありがたいことにアクセス数が伸びてきたら、無料枠の上限(リクエスト数や CPU 時間など)に近づく前に、サーバーの増強を検討しましょう。Cloudflare なら Workers の有料プラン($5/月〜)に上げるだけでそのままスケールできますし、その頃には収益や手応えがあるはずなので、必要になってから払えば十分です。

まとめ

  • AI でアプリを作ったら、公開まであと一歩
    費用はドメイン代だけ。1日7,700リクエスト配信しても Free プランのままだった
  • pages.dev のサブドメインなら0円だが、人に見せるものには非推奨
    SEO 面で不利、あとからの切り替えも高くつく。自分用・検証用ならそのままでいい
  • サーバーは Cloudflare
    完全無料で動き、収益化しても無料のまま(Vercel は収益化時に有料プランが必要)。HTTPS への転送やキャッシュ指定も最初から入っている
  • ドメインも Cloudflare
    ネームサーバー設定も WHOIS 公開代行も自動で、接続がワンクリック。.dev は HTTPS 必須になる点だけ覚えておく
  • 公開したら一度 curl -I でヘッダを見ておく
    何が自動で付いていて、何が付いていないかが分かる
  • アクセスが伸びてきたら増強を検討
    それまでは無料で十分

「ヘッダを見ておく」は、この記事のために実際に測ってみて初めて気づいたことです。公開できた時点で満足してしまい、実際に何が返っているかは見ていませんでした。

作ったものは公開してこそ。この記事が最初の一歩の後押しになればうれしいです。

次に読む記事

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

わどこんのアバター わどこん

実務12年のバックエンド・インフラエンジニア。バックエンド開発からクラウド・インフラの設計・構築・運用まで担当しています。主要言語は Java・Kotlin・PHP・Python。運用の現場で拾った知見を、再現できる手順に落として残すのがこのブログのテーマです。

目次