無料で個人開発しようぜ！Cloudflareでサイトを作り直してみた

このサイトを、Renderで動かしていたRailsの構成から、Cloudflareへ移しました。

きっかけは、月1,000円ほどの運用費を見直したくなったことです。1,000円でも十分安いんですけどね。サイトの構成を作り直すなら、費用だけでなく、これからの開発の仕方も一緒に考えてみようと思いました。

今回はAIと相談しながら、Railsのコードを残すことにはこだわらず、TypeScriptで作り直しています。移行自体は1日かからず、自分が実際に画面を見て操作や確認をしていた時間は、体感で3時間くらいでした。

月1,000円の運用費と、これからの作り方

これまでは、RailsをRenderの無料Webサービスで動かし、データベースには有料のPostgreSQLを使っていました。

それでも、記事を読んでもらうことが中心の今のサイトなら、無料枠で動かせる構成もありそうです。記事や画像、管理画面を引き継いだうえで、もう少し費用を抑えられないかと考えました。

もう一つ大きかったのが、AIを使った開発です。

以前なら、別の言語や構成で作り直すこと自体に、かなり時間を取られていたと思います。今は既存のコードを見せながら、必要な機能を整理したり、別の実装に置き換えたりする作業をAIと進められます。もちろん確認は必要ですが、自分のサイトなら試してみたい。

そう考えると、今までRailsで書いていたからという理由だけで、Railsを残す必要はありませんでした。言語を固定するより、AIを使ってどこまで作り込めるのか、その幅を広げるほうが大事だと思ったのです。

Cloudflareは何をしてくれるのか

Cloudflareは、Webサイトを速く、安全に届けるためのサービスを提供している会社です。ドメインの接続先を管理するDNSや、コンテンツを配信するCDNに加えて、アプリを動かす環境、データベース、ファイルの保存先も揃っています。Cloudflareのサービス概要

今回使った中心的なサービスは、Workers・D1・R2の三つです。

Workers：サイトの処理を動かす場所

Workersは、アクセスに応じてプログラムを実行するサービスです。このサイトでは、記事の取得、ページのHTML生成、検索、管理画面などの処理を担当しています。サーバーそのものの準備や管理は、Cloudflare側に任せられます。Workersの概要

コードはTypeScriptで書き、URLごとの処理を組み立てるために、HonoというWebフレームワークを使っています。ページのHTMLはWorkers側で作って返しています。こうした仕組みをSSR（サーバーサイドレンダリング）と呼びます。

D1：記事などのデータを保存する場所

D1は、SQLite互換のSQLデータベースです。記事のタイトルや本文、ユーザー情報などを保存しています。以前PostgreSQLに任せていた役割を、今回はD1に移しました。D1の概要

「SQLite」と聞くとローカルのファイルを想像するかもしれませんが、ここではCloudflareが管理するデータベースに、Workersからアクセスしています。

R2：画像ファイルを保存する場所

R2は、画像などのファイルを保存するストレージです。このサイトでは、記事に使う画像の置き場所にしています。R2の概要

記事の本文や画像の情報はD1へ、画像ファイルそのものはR2へ、という分担です。

アプリ、データベース、画像の保存先をCloudflareで揃えられて、それぞれに無料枠がある。AIと作り直す前提で考えたとき、今回のサイトにはこの組み合わせが一番合いそうだと判断しました。

このサイトの構成

記事を見るときの主な流れは、次のようになっています。

flowchart TB
  accTitle: このサイトの記事表示の構成
  accDescr: 読者のブラウザからWorkersへアクセスし、WorkersがD1の記事データとR2の画像を取得して返します。
  browser["読者のブラウザ"]
  workers["Workers<br/>TypeScript・Hono"]
  database[("D1<br/>記事などのデータ")]
  images[("R2<br/>記事の画像")]
  browser -->|"アクセス"| workers
  workers -->|"データを取得"| database
  workers -->|"画像を取得"| images

ブラウザからのアクセスをWorkersが受け取り、必要なデータをD1やR2から取得して返します。CSSやJavaScriptなどの静的ファイルは、別途Workersの「Static Assets」という機能で配信しています。Static Assetsの概要

管理画面へのログインにはCloudflare Accessも使っています。これは、許可した人かどうかを確認してから、アプリのログインへ進めるための仕組みです。

変更した部分を並べると、こうなります。

役割	移行前	移行後
アプリの実行	Render上のRails	Workers上のTypeScript・Hono
記事などのデータ	PostgreSQL	D1
記事の画像ファイル	PostgreSQL内に保存	R2
DNSの管理	お名前.com	Cloudflare
ドメインの契約・更新	お名前.com	お名前.comのまま

ドメイン名は変えていません。サイトやDNSの移行と、ドメインの契約先を変えることは別なので、今回は契約まで移す必要はないと考えました。

無料で使えるのは、どのくらいまで？

今回の構成は、Workers Freeと、D1・R2の無料枠内で運用することを目指しています。主な無料枠は次のとおりです。同じアカウントで別のアプリも動かす場合は、その利用量も合わせて考えます。

サービス	主な無料枠
Workers Free	1日10万リクエスト。1回の処理に使えるCPU時間は10ms
D1 Free	1日500万行の読み取り・10万行の書き込み。保存容量はアカウント合計5GB、1データベースあたり500MB
R2 Standard	保存は月10GB-month。書き込み・一覧取得などは月100万回、読み取りなどは月1,000万回。外向きのデータ転送は無料

料金・制限は2026年10月14日に確認しました。Workersの料金・D1の料金・D1の制限・R2の料金

D1の「行数」は、ページが読まれた回数とは別です。一度の検索で多くの行を読むこともあるので、アクセス数だけでは判断できません。R2の「10GB-month」は、10GBのデータを1か月保存する量に相当します。

静的ファイルをStatic Assetsから直接配信するリクエストは、無料・無制限です。ただし、このサイトの記事画像はWorkers経由でR2から取得するため、そちらはWorkersやR2の利用量として考えます。Static Assetsの料金

無料枠に収まれば、アプリ・データベース・画像保存の利用料を0円にできる構成です。ドメインの更新費や、開発に使うAIの料金は別になります。まずはこの無料枠で運用しながら、実際の使用量と請求を見ていくつもりです。

なお、WorkersやD1の無料プランは上限を超えると処理が制限されますが、R2は無料枠を超えた分が課金対象です。予算通知も利用できますが、これは利用を自動で止める機能ではありません。Workersの制限・D1の無料枠を超えた場合・予算通知について

移行は1日かからず、画面を見ていたのは約3時間

今回の移行は、AIに既存コードを確認してもらい、必要な機能を作り直しながら進めました。自分は構成を決めたり、設定をしたり、実際の画面を見て確認したりする部分を担当しています。

移行自体は1日かからず、自分が画面を見て操作や確認をしていたのは、体感で3時間くらい。AIに作業を任せて待っている時間もありました。

データを移す前のバックアップや、移行先での記事・画像・ログインの確認は行いました。それでも、別の構成に作り直す作業としては、思っていたより短い時間で進められました。

移行後も、ページの見た目や使い勝手は少しずつ直しています。

TypeScriptで、これからもっと触っていきたい

移行後は、画面側もサーバー側もTypeScriptを中心に触れるようになりました。ページを移動するときのアニメーションや、各ページの細かい見せ方も、AIと相談しながら手を入れています。

RailsでもTypeScriptは使えますし、同じような画面表現はできます。今回よかったと感じているのは、今後やりたいことに合わせて構成を整理し直せたことです。画面の変更からサーバー側の処理まで、続けて相談しながら作り込みやすくなりました。

運用費を抑えたかったのが始まりですが、実際にやってみると、これから開発していくのが楽しみになったことも大きかったです。

Railsを使い続けるかどうか、最初に決めてしまわなくてもよかった。作りたいものに合わせて構成を変えられるなら、そのためにもAIを使っていきたいと思っています。