1. まずCloudflareを一言でいうと
「自社のWebサービスとインターネットの間に入り、速く・安全に届ける会社」から始まり、今は“アプリを動かすためのクラウド基盤”まで持っている会社です。
昔から有名なのはDNS、CDN、DDoS対策、WAFなどです。つまり、Webサイトの前段に立って通信をさばき、攻撃を止め、世界中へ高速配信する役割です。ところが現在はWorkersというサーバーレス実行環境を中心に、SQLデータベースのD1、オブジェクトストレージのR2、KV、Durable Objects、認証のAccess、AI Gatewayなどまで揃っています。
DNS / CDN / Security
「どこへつなぐか」「近い場所から配る」「攻撃を止める」。Webの玄関・交通整理・警備員。
Pages / Workers
HTMLを公開したり、APIやWebアプリのプログラムを実行したりする。従来のレンタルサーバーに近い役割を、もっと分解・自動化したもの。
D1 / R2 / KV / DO
台帳、写真・PDF、設定値、リアルタイム状態などを置く。アプリに必要な“記憶”の部分。
HTMLをGitHubの
reports/ に置く → push → Cloudflare Pagesがbuild → 公開URLが更新される。サーバーへFTPでコピーしたり、Apache/Nginxを管理したりする作業がほぼ消えています。2. GitHubとCloudflareは、何が違う？
設計図・履歴・共同作業
コードやHTMLを保存し、「誰が・いつ・何を変えたか」を履歴として残す場所。壊しても戻せる。レビューやIssue、Actionsもある。
公開・実行・防御
GitHubにある成果物をビルドして公開し、必要ならAPIを動かし、DBやストレージにつなぎ、認証やセキュリティも掛ける。
GitHubは基本的に「ソフトウェアを作る側の中心」、Cloudflareは「作ったものをユーザーに届け、動かす側」です。重なる機能もありますが、初心者のうちはこの分け方で十分です。
今のレポート公開を例にすると
Cloudflare公式ドキュメントでは、PagesをGitHub/GitLabと接続すると、ブランチへのpushごとに自動でbuild/deployでき、preview deploymentも利用できます。
3. Cloudflare主要サービスの「使いどころ地図」
名前を暗記するより、「何を保存する？」「どこで処理する？」で選ぶ方が早いです。
Pages
静的サイト・フロントエンド公開。 HTML/CSS/JS、React等。Git連携が分かりやすい。今のshare-report-siteはここ。
Workers
サーバー側の処理。 API、認証判定、外部API連携、フォーム処理、定期処理など。「常時起動する自前サーバー」を持たずにコードを実行する。
D1
SQLで扱う台帳。 SQLite系。社員・工具・貸出記録・案件・点検結果など、行と列で検索・集計したい情報向き。
R2
ファイル置き場。 写真、PDF、添付ファイル、バックアップなど。S3互換APIを持ち、インターネットへのegress課金が原則ないのが特徴。
KV
小さな設定・高速参照。 「キー→値」で取り出す。頻繁な複雑更新より、設定値・キャッシュ・参照中心のデータ向き。
Durable Objects
状態を持つリアルタイム処理。 同じ部屋にいる複数人の同期、WebSocket、排他制御など。普通のCRUDより一段上の用途。
Access
社内向けページの門番。 「Google/Microsoftでログインした社員だけ」など、アプリ本体に複雑なログイン機構を作らず保護できる。
AI Gateway / Workers AI
AI呼出しの管理・実行。 複数モデルへのアクセス、ログ・コスト管理・レート制御など。AIを業務アプリへ組み込む時の交通整理役。
「Pages + Workers + D1 + R2 + Access」
で、画面・処理・台帳・添付・ログインまで一式をかなり薄いインフラ管理で作れます。
4. なんで、こんな便利なものが世の中にある？
「無料や格安でここまでやって、どこで儲けるの？」という感覚は正しいです。答えは慈善事業ではなく、開発者を入口にした巨大なプラットフォーム商売だからです。
① 無料枠は“試食”
個人・小規模開発なら無料枠内でかなり使えます。しかし利用が増え、企業として重要になれば、Workers Paid、上位セキュリティ、Zero Trust、サポート、Enterprise契約などへ広がります。
② 使い始めてもらう価値が大きい
Webアプリの土台は一度決めると長く使われます。最初の導入障壁を極端に下げ、「まずCloudflareで作る」開発者を増やすこと自体に大きな価値があります。
③ 規模の経済が効く
Cloudflareは世界規模のネットワークを既に運用しています。多数の利用者が同じ基盤を共有するサーバーレス方式では、小さな利用者1社を増やす追加コストを抑えやすい。
④ 便利になるほど周辺サービスも使う
Pagesだけだった利用者が、Workers、D1、R2、Accessへ進む。GitHubも同じで、無料リポジトリからActions、Copilot、Team/Enterpriseへ広がる構造があります。
オープンソースも同じ発想
Cloudflare OSをオープンソース化するのも、「ソフトそのものを売る」だけが商売ではないからです。OSを自社Cloudflareアカウント上で動かせば、結果的にWorkers、Access、AI GatewayなどCloudflare基盤の利用が増えます。一方、ユーザー側はソースを読める・改造できる・自社環境で持てるメリットがある。双方の利害が一致する場所がオープンソースになっています。
コードがオープンでも、D1固有API、Workers bindings、Durable Objectsなどを深く使うほど、他社クラウドへの移植コストは上がります。便利さと依存度はだいたい一緒に増えます。
5. 今回の記事「Cloudflare OS」は何が面白い？
2026年8月に公開されたCloudflare OSは、Cloudflare社内で実際に使ってきたAIワークスペースをオープンソース化し、自社Cloudflareアカウント上で動かせるようにしたものです。
単なるChatGPT風チャットではなく、「会社の情報や外部サービスに接続されたエージェント」「AIが作る小さな業務アプリ」「共有」「アクセス制御」まで一体化しようとしています。公式説明では、Cloudflare AccessによるZero Trust、Gatekeeperという管理された接続、AI Gatewayによるモデル選択・コスト管理が柱です。
調査・文書・自動化
AIが会社の許可されたデータに接続し、リサーチ、文書生成、反復作業を実行する。
その場で業務アプリ化
AIに頼んで小さなアプリを作り、DB・リアルタイム・アクセス制御付きで共有する思想。
権限を絞って接続
エージェントは初期状態で何でも触れるのではなく、必要なサービスだけ個別に許可するcapability-basedな考え方。
祐介さん目線で重要なのはここ
「AIチャットを導入する」から一段進んで、“会社の小さなシステムをAIにどんどん作らせ、同じ基盤で配る”方向へ寄せていることです。たとえば、工具持出、現場写真整理、点検台帳、KY記録、社内検索、定型帳票などを、毎回フルスクラッチのWebシステムとして発注するのではなく、小さなアプリとして短いサイクルで作る発想と相性があります。
6. 小規模な建設・電気工事会社なら、どこに効く？
大げさな「DX基盤」を作るより、Excel・紙・口頭・写真フォルダの隙間にある“小さな面倒”をWeb化するのが向いています。
共有レポート・社内資料ポータル
今のPages運用。HTMLをGitHubへ置くだけで公開。まずはここを「GitHub→自動build→Pages」の練習台として使うのが最も安全です。
QRで開く点検・KYフォーム
Pagesで画面、Workersで送信処理、D1へ記録。現場ごとのQRを貼り、スマホで入力。集計画面も同じWebアプリにできる。
工具・鍵・備品の貸出台帳
NFC/PC側からAPIを叩いてD1へ記録。管理画面はPages。社員だけに限定するならAccess。写真や説明書PDFはR2。
工事写真・PDFの簡易検索
実ファイルはR2、検索用メタデータはD1。案件番号、現場、日付、設備種別をDBに持たせる。生成AIによる要約・分類を後付けしやすい。
社内AIツール
Workers + AI Gateway、またはCloudflare OSを検証。社内規程・安全資料・案件情報などへ権限を絞ってつなぐ。最初から全社データを渡さず、小さな対象から始める。
「社内サーバーを買う」案との違い
社内サーバーは、LAN内高速処理、大容量データ、機器との直接通信、完全ローカル運用では強いです。一方Cloudflareは、外出先スマホアクセス、公開、TLS証明書、アクセス制御、インターネット越しAPI、冗長化などを自前で面倒見なくてよいのが強い。全部クラウドか全部社内かではなく、現場端末・NFC・大容量NASは社内、外部公開APIや軽いDB・認証はCloudflareというハイブリッドも現実的です。
7. 注意点。便利な分だけ「知らずに踏む穴」もある
APIキー、パスワード、リカバリーコード、個人情報をcommitしない。削除commitだけでは履歴に残る場合があります。秘密はCloudflare Secrets等へ。
Cloudflare公式も、GitHub Appは必要なrepositoryだけにアクセスを限定することを推奨しています。「全repo許可」は楽ですが事故範囲が広がります。
Pages無料枠はbuild回数、ファイル数、単一ファイル25MiBなど制限があります。R2やD1も無料枠超過後は課金または制限があります。
1 DBの最大サイズや同時実行特性があります。公式には個別DBはsingle-threadedで、Workers Paidでも1 DB最大10GB。巨大基幹DBの代用品と考えない。
V8ベースのランタイムで、Node.jsサーバーと似ていても完全に同じではありません。長時間常駐プロセスやOS依存ツールをそのまま置く用途ではない。
egressは原則無料でも、保存容量と操作回数には料金があります。大量の細かいファイルアクセスはoperation課金も見る必要があります。
ミスも一瞬で公開されます。重要なサイトではpreview branch→確認→main mergeの方が安全。公開物に機密が混ざらないルールが必要です。
Workers/Pages等の既存基盤と、2026年8月公開のCloudflare OSは同じ成熟度ではありません。OSは実験→限定業務→評価の順が無難です。
数字で見る現在の代表的な上限
料金・上限は変更されるため、実運用前に必ず公式Pricing / Limitsを再確認してください。
8. 使い慣れていない段階なら、この順で覚えるのがいい
今：Pages + GitHubを完全に理解
repo、commit、push、main、build、公開URL、rollback。この流れを身体で覚える。今のレポートサイトが教材として十分です。
次：Workersで「1本のAPI」を作る
例：フォームからJSONを受けて返す。これで「画面」と「サーバー処理」の境目が分かります。
D1を1つ足して、記録を残す
問い合わせ、点検、工具貸出など。SELECT / INSERT / UPDATEが分かれば、一気に業務アプリらしくなります。
Accessで社内限定にする
公開Webと社内Webの違いを体験。認証を自前実装しないメリットが分かります。
R2で写真・PDFを扱う
DBにはファイル本体ではなくメタデータ、実体はR2、という分離を覚える。
最後にCloudflare OSを検証
ここまでの部品感が分かってから触ると、Cloudflare OSが何をまとめてくれているのかが見えます。先にOSだけ触るより理解が深いです。
「サーバーを1台借りて、そこに全部載せる」ではなく、公開はPages、処理はWorkers、表データはD1、ファイルはR2、認証はAccessと、役割ごとの部品を組み合わせます。Cloudflareは、その部品同士の接続をかなり楽にしているプラットフォームです。
参考資料
- Impress Watch：オープンソースAIワークスペース「Cloudflare OS」が公開（2026-08-07）
- Cloudflare公式：Cloudflare OS 発表
- GitHub：cloudflare/cloudflare-os
- Cloudflare Pages：GitHub integration
- Cloudflare Pages：Limits
- Cloudflare Workers：Overview
- Cloudflare D1：Overview / Limits / Pricing
- Cloudflare R2：Pricing
本レポートは2026年8月8日時点の公式情報を中心に整理。Cloudflare OSは公開直後のため、仕様・導入方法・料金体系は今後変わる可能性があります。