この話の結論（3つだけ）
- Cloudflareは「土台の一式」が1社で揃う
Webアプリ(Workers)・DB(D1)・ファイル(R2)・ログイン制御(Access)・セキュリティ(WAF/DDoS)・AI(Workers AI)を組み合わせて使える。ただしノーコードではなく、コードを書く（＝AIに書かせる）前提
- 中小企業にとっての“効く2点”は Access と Tunnel
「M365/Googleアカウントで社員だけに限定」(Access)と「既存の社内サーバーを残したまま安全に公開」(Tunnel)。ここは後述のVercelに同等機能がない、明確な差別化点
- Vercelとは得意分野が違う
Vercelは対外的なモダンWeb（Next.js等）とデプロイ体験に強い。社内システムの“基盤”としての幅はCloudflareが広い。優劣ではなく用途で選ぶ
CHAPTER 1
Cloudflareとは（社内システムの「土台」）
Cloudflareは元々「Webサイトを速く・安全にする」ネットワーク会社として知られていますが、いまは「開発者向けプラットフォーム（Developer Platform）」として、アプリを動かす・データを保存する・ログインを制御する・AIを動かす、といった社内システムに必要な部品一式を提供しています。
この教材でいう「土台」とは、自社で社内アプリ（商品検索・在庫確認・申請・見積管理など）を作るときの下地のことです。Cloudflareは、その下地を1社のサービスの中で組み合わせて用意できるのが特徴です。
たとえ話
家を建てるときの「土地＋基礎＋電気・水道・鍵」を、業者ごとにバラバラに手配せず1つの窓口でまとめて用意できるイメージです。上に建てる“家”（実際の社内アプリ）は、自分たち（またはAI）で設計・建築する必要があります。
先に正直な前提
Cloudflareはノーコードツールではありません。土台は揃いますが、その上のアプリはプログラミング（またはClaude Code等のAIコーディング）で作る前提です。「置くだけ・つなぐだけで社内システムが完成」ではない点を最初に押さえてください。
CHAPTER 2
「デプロイ」とどう違う？（置くだけ→動くアプリ）
「これまでのデプロイと違うの？」——よくある疑問です。答えは「デプロイという動作は同じ。でも“何をデプロイするか”の中身が段違いに広がる」。別物ではなく上位互換だと捉えてください。
これまで慣れている「デプロイ」は、多くの場合完成したファイルを置いて“見せる”こと（静的サイト）。Cloudflareの“土台”は、そこにデータを覚え・処理し・ログインで守り・AIを呼ぶ“生きたアプリ”を動かし続けるまで含みます。
たとえ話
これまでのデプロイ＝チラシを掲示板に貼る（見せるだけ・一方通行・記録は残らない）。土台でアプリを作る＝受付・カウンター・台帳・鍵のある“店”を開いて営業し続ける（やり取りし・記録が残り・関係者だけ入れる）。
同じ「デプロイ」の延長で、載せられるものは次のように段階的に広がります。①が従来のデプロイで、Cloudflareの土台は①で止まらず②〜⑤を同じ場所で積み上げられる、という意味です。
| 段階 | できること | 使う部品 | 例 |
|---|
| ①置くだけ（従来のデプロイ） | 情報を見せる（静的） | Pages/静的 | 教材サイト・会社案内 |
| ②動く | 入力を受けて処理する | Workers | 申込フォーム・計算ツール |
| ③覚える | データを保存・呼び出す | ＋D1・R2 | 顧客台帳・在庫・見積 |
| ④守る | 社員だけに限定 | ＋Access | 社内専用の管理画面 |
| ⑤賢い | AIで検索・分類・生成 | ＋Workers AI | 社内資料AI検索・問い合わせ分類 |
| ⑥量産 | 社員が自分でアプリを作る | Cloudflare OS | 会社OS（第8章） |
効く理由
普通は②〜⑤を別々のサービス（実行はA社・DBはB社・ログインはD社…）で契約して繋ぎます。Cloudflareの“土台”は②〜⑤が最初から同じ場所に揃っているのが売り。だから非エンジニアがAIに「社員だけ見れる在庫管理を作って」と頼んでも、AIが同じ土台の中だけで完結させやすい＝作りやすい・壊れにくい・安い、につながります。
CHAPTER 3
何がまとまっているか（プロダクト早見表）
①の「いろいろな機能が1つにまとまっている」を、正確なプロダクト名で分解すると次のとおりです。名前は難しく見えますが、「何をするもの？」だけ掴めば十分です。
| 用途 | プロダクト名 | 何をするもの？ | 状態 |
|---|
| Webアプリを動かす | Workers（ワーカーズ） | サーバーレスでコード（JS/TS等）を動かす実行環境。社内アプリの本体はここ | GA |
| フロント/静的サイト配信 | Pages（ページズ） | 画面（HTML/フロント）のホスティング。Workersへの統合が進行中（新規はWorkersが公式推奨） | GA |
| データベース | D1（ディーワン） | SQLiteベースのSQLデータベース。商品・顧客・在庫・価格などの表形式データ | GA |
| ファイル保存 | R2（アールツー） | S3互換のファイル置き場。PDF・画像・CSVなど。ダウンロード転送料が無料 | GA |
| 簡易データ保存 | Workers KV | 設定値やセッションなど、小さなデータを高速に読み書き | GA |
| 状態を持つ処理 | Durable Objects | 整合性が要る処理（順番・排他など）を扱う実行単位 | GA |
| 既存DBの高速化 | Hyperdrive | 今ある外部のPostgres/MySQLに“繋いで速くする”。既存DBを残したままの段階移行の橋渡しに | GA |
| ログイン/アクセス制御 | Access（Zero Trust） | 「社員だけ」に限定するログイン制御。M365/Googleと連携 | GA |
| セキュリティ | WAF / DDoS対策 | 攻撃の遮断。DDoS対策は無料で標準装備（WAFは後述の注意あり） | GA |
| 既存サーバーの公開 | Tunnel（cloudflared） | 今ある社内サーバーを、ポート開放せず安全にWeb公開 | GA |
| AI推論 | Workers AI | LLM・画像認識・埋め込みなどを従量課金で実行 | GA |
| 意味検索/RAG | Vectorize / AI Search | 社内文書のAI検索の下地。Vectorize（ベクトルDB）はGA、AI Search（旧AutoRAG＝RAG自動構築）は試験提供 | GA/ベータ |
| AIの中継・管理 | AI Gateway | OpenAI等への中継・キャッシュ・利用分析・レート制限 | GA |
※「状態」は2026-08-08時点。GA＝正式提供／ベータ＝試験提供（使えるが仕様が変わりうる）。旧Pagesはそのまま使えますが、新規プロジェクトはWorkersで作るのが公式推奨です。
読み方のコツ
全部を覚える必要はありません。最初はWorkers（アプリ）＋D1（表データ）＋R2（ファイル）＋Access（社員限定）の4つだけ頭に入れれば、小さな社内アプリの土台像がつかめます。
CHAPTER 4
12のメリットを正確に整理する
よく挙がる「中小企業がCloudflareを使うメリット①〜⑫」を、公式ドキュメントで裏どりし、正確な言い換えにそろえた一覧です。◎＝そのまま正しい／○＝おおむね正しい（表現に注意）／△＝条件つき・誇張しやすい、で判定しています。
| # | 元の言い分 | 判定 | 正確にいうと（対応機能・注意） |
|---|
| ① | 機能が1つにまとまっている | ◎ | Workers/Pages/D1/R2/Access/WAF/Workers AIを1社で組み合わせ可。ただし「全部入りワンクリック」ではなく必要なものを組む形 |
| ② | サーバー管理がほぼいらない | ○ | Workersはサーバーレス。台数・OS更新は不要。ただしコード・設定・料金の管理は必要（“一切ゼロ”ではない） |
| ③ | 最初からセキュリティが強い | △ | DDoS対策は無料で標準装備＝強い。WAFは無料だと基本ルールのみ・本格ルールは有料。アクセス制限はAccessの設定で。「全部が最初から強い」は言い過ぎ |
| ④ | M365/Googleでログインできる | ◎ | AccessがMicrosoft Entra ID（旧Azure AD）/Google Workspaceに対応。SSOで社内アカウントをそのまま使える |
| ⑤ | 社内ドメインの人だけ利用可 | ◎ | Accessのポリシーで「@自社ドメインのメールだけ」「特定グループだけ」を画面上で設定可能 |
| ⑥ | DB・ファイル保存もできる | ◎ | D1（表データ）＋R2（PDF/画像/CSV）。小規模なら無料枠で試せる（数値は変動・要公式確認） |
| ⑦ | 小さな社内アプリを作りやすい | ○ | Workers+D1+R2+Accessで土台は少ない構成で組める。ただしコーディング（またはAIに書かせる）が前提 |
| ⑧ | 今のシステムを少しずつ移行できる | ◎ | Tunnelで既存社内サーバーを残したまま安全に公開・段階的Web化が可能（Cloudflareの強み） |
| ⑨ | Access/Excelからの移行先に良い | △ | “受け皿”としては妥当だが、Cloudflare固有の自動移行機能はない。作り直し（開発）が前提。「移行が簡単」は誤解を招く |
| ⑩ | Codex/Claude Codeと相性が良い | ○ | 標準のJS/TSとWeb標準API＋Wrangler CLIなので、AIコーディングが扱いやすいのは妥当。さらに公式のClaude Code連携（セットアップ手順・雛形コマンド）やMCPサーバー（AIに“道具”を渡す仕組み）も用意されており、AIエージェント前提の作りに寄っている |
| ⑪ | 外部業者に毎回頼らなくてよい | △ | 社内にコード/AIを扱える人がいれば外注依存は減る。“完全に不要になる”わけではない（条件つき） |
| ⑫ | AI機能も追加しやすい | ○ | Workers AI/Vectorize/AI Search（旧AutoRAG）/AI Gatewayで、社内文書のAI検索・問い合わせ対応・書類読み取りを後から追加できる |
この章の要点
12個のうち、③⑨⑪は特に“盛りやすい”ところです。「セキュリティは全部最初から強い」「Access/Excelから簡単に移行」「業者が完全に不要」——このあたりはそのまま口説き文句にすると後で食い違いが出ます。上の表の「正確にいうと」の温度感で話すのが安全です。
CHAPTER 5
いちばん効く2点 — Access と Tunnel
12個のメリットの中でも、中小企業の“社内システム”という文脈でCloudflareが本当に効くのは2つです。ここは後述のVercelにも同等機能がなく、差がつくポイントです。
① Access ＝「社員だけ使える」を安く・簡単に
Cloudflare Access（Zero Trust）を使うと、社内アプリの前に「ログインの関所」を置けます。Microsoft 365やGoogle Workspaceのアカウントでログインさせ、「@自社ドメインのメールを持つ人だけ」あるいは「特定の部署グループだけ」に利用を絞る——といった設定を、プログラムを書かずにダッシュボードで作れます。
社内アプリ（在庫確認・見積管理 など）
↑ この手前に「関所」を置く
Cloudflare Access（Zero Trust）
↑ ログインは会社のアカウントで
Microsoft 365 / Google Workspace
↓ 許可条件（ポリシー）
「@会社ドメインのメール」の人だけ通す
FIG. Accessで「社員だけ」に絞るイメージ
1つだけ注意
Google Workspace “そのもの” をAccessの背後に置く特殊な構成では、認証がループしないよう別のIdP（ログイン元）が必要になる制約が公式にあります。通常の「社内アプリをGoogle/M365ログインで守る」用途では問題になりません。
② Tunnel ＝ 既存の社内サーバーを残したまま公開
Cloudflare Tunnel（cloudflared）は、社内サーバーに軽いソフトを1つ入れるだけで、「外向きの接続」だけを使ってCloudflareにつなぎます。グローバルIPもポート開放も不要で、今ある社内サーバーやデータベースを作り直さずに、安全にWeb公開できます。前述のAccessと組み合わせれば「社員だけがアクセスできる社内サーバー」になります。
なぜ“段階的移行”に効くのか
⑧の「少しずつ移行できる」の正体がこれです。全部を一気に作り直さず、まず今のサーバーをTunnelで安全に社内公開し、余裕のある部分から順にWorkers+D1+R2へ置き換えていく——という現実的な移行の道が引けます。
CHAPTER 6
自社に必要？——「作る人／使う人」で決まる
「社員に作らせる土台までは要らない。自分が作って社内で使えればいい」——この場合にCloudflareが要るのかを、はっきりさせます。ここは2つを分けて考えると迷いが消えます。
- 社員にも“作らせる”土台 ＝ Cloudflare OS（第8章）。→ 自分だけが作るなら不要。
- Cloudflareそのもの（Workers/D1/R2/Access） ＝ 作ったアプリを“動かして・社員に届けて・社員だけに絞る”場所。→ 作る人が誰かとは無関係。むしろ「自分で作って社内で使わせる」ときの本命の使い道。
つまり「社員に作らせない＝Cloudflare不要」ではありません。本当の分かれ目は“社内で使えるように”が何を要求するかです。
| あなたの使い方 | 必要なもの | Cloudflareは？ |
|---|
| 自分のPCで、自分だけが動かすツール | 何も要らない（ローカルで完結） | 不要 |
| 社員が複数・別PCから・ブラウザで・常時・データ共有して使う | 常時起動の置き場＋DB＋社員だけログイン | ここが出番 |
後者（複数人・別PC・ブラウザ・共有）なら、あなたが唯一の作り手でもCloudflareはちょうど良い土台です。①常時動かし②各自のPCから開けて③M365/Googleで社員だけに絞れる——これは「誰が作ったか」に関係なく必要になるからです。
正直な比較：ノーコードの方が速いことも
小さな社内ツールを“自分で作るだけ”なら、ノーコードの内製ツール（kintone・AppSheet・Retoolなど）の方が手早い場面もあります。Cloudflareが勝つのは——席課金なし（社員が増えても安い）／データが自社保有／AIを組み込みやすい／社員だけログインが綺麗（Access）／AI（Claude Code）に作らせやすい、の5点。逆に言えば、これらが要らない小規模ならノーコードでも十分です。
ひとことで
「作る人＝あなた1人」でも、「使う人＝社員複数」ならCloudflareの価値は残る。それは“作らせる土台”ではなく“動かして社員に安全に届ける土台”の側です。「それすら要らない」のは、自分だけがローカルで使うときだけ。
CHAPTER 7
Vercelとの比較
Cloudflareとよく比較されるのがVercel（ヴァーセル）です。VercelはWebフレームワーク「Next.js」の開発元で、フロントエンド／フルスタックのデプロイに強いサービス。Git連携で自動ビルド・プレビュー・本番公開ができ、開発体験の良さとモダンなWeb制作で人気があります。Cloudflare Pagesとは「フロント配信」の領域で競合します。
ただし「中小企業の社内システムの土台」という観点で見ると、両者は得意分野がはっきり違います。
| Cloudflare | Vercel |
|---|
| いちばんの得意 | 社内システムの“基盤一式”（実行・保存・認証・公開） | 対外的なモダンWeb（Next.js等）と開発・デプロイ体験 |
| アプリ実行 | Workers（サーバーレス） | Vercel Functions（サーバーレス） |
| データベース | D1（自社提供のSQL DB） | 自社DBは終了。現在はNeon等をマーケットプレイス連携で使う |
| ファイル保存 | R2（下り転送料無料） | Vercel Blob |
| 社員だけに限定（SSO） | Accessで汎用的に。M365/Google連携が安価に使える | デプロイ保護は有るが、外部SSO限定はEnterpriseプラン必須 |
| 既存社内サーバーの公開 | Tunnelで可能 | 同等機能はなし（Secure Computeは逆向き＝自社DBへ繋ぐ用途） |
| 無料枠の商用利用 | 無料枠でも商用可（Workers 10万req/日 など） | 無料(Hobby)は非商用・個人利用のみ。商用はPro〜 |
| グローバル配信 | あり（世界規模のエッジ） | あり（世界規模のエッジ） |
Vercelを語るときの誤情報に注意
「Vercel Postgres（Vercel純正のDB）」は2024年12月に終了し、既存分はNeonへ移行済みです。現行機能として「Vercelにも純正DBがある」と書くと誤りになります。今のVercelは「DB/ストレージは外部サービスをマーケットプレイスでまとめて契約」という形です。
使い分けの結論
社員限定の社内アプリ・イントラ的な用途／既存サーバーを活かした段階移行なら Cloudflare。お客様向けのモダンなWebサイト・製品フロント・SaaSの見た目側を素早く作るなら Vercel。「どちらが上」ではなく、作りたいものが“社内向け基盤”か“対外向けWeb”かで選ぶのが実態に合っています。
ただし「対外向けなら必ずVercel」ではありません
会社概要や実績を
表示するだけのコーポレートサイトやLPは、
対外向けでもCloudflareが素直です。サーバー側で何も動かないためVercelの強みを使わず、静的ファイルの配信は
無料プランでも無料・無制限だからです（コーポレートサイトは商用なので、Vercelなら月20ドルが確定します）。
つまり本当の分かれ目は
「社内か対外か」ではなく「サーバー側で何が動くか」です。この判断軸は姉妹教材「
作ったアプリをどこに置く？」で詳しく扱っています。
「で、結局どっちに置けばいい？」だけ知りたい人へ
土台の話まで踏み込まず、
作ったアプリの置き場所をどちらにするかだけ決めたい場合は、姉妹教材「
作ったアプリをどこに置く？ — Vercel と Cloudflare Workers」を読んでください。
料金の早見表（
Vercelの無料プランは非商用・個人利用のみという落とし穴つき）、3つの質問で決める判断フロー、そして
「画面はVercel・処理はCloudflare」と分ける構成を最初は真似してはいけない理由を扱っています。
CHAPTER 8
Cloudflare OS という新しい動き（会社OS）
2026年8月、Cloudflareは社内で使っていた仕組みを「Cloudflare OS」としてオープンソース公開しました（Apache 2.0）。パソコンのOSではなく、Workersの上に建てた“会社の仕事場”——社員がブラウザでAIに頼み、社内資料や業務システムを使わせ、小さな業務アプリまでその場で作らせるための土台です。ここまでの章の「①〜⑥の段階」でいう⑥量産にあたります。
登場人物は4つだけ掴めば十分です。
| 役 | 呼び名 | 中身 |
|---|
| 画面 | Agent Workspace | 社員が「〜する画面を作って」と頼むチャットUI |
| アプリ | Gadget（ガジェット） | AIがその場で作る小さな個人アプリ。1つずつ完全に隔離されたWorker＋専用SQLiteを持つ |
| 門番 | Gatekeeper（ゲートキーパー） | 社内システムやSaaSへの接続を仲介する係。鍵（認証情報）は門番が握り、AIには渡さない。重要操作は人間承認を挟める |
| 土台 | Kernel（Workshop Backend） | 全体をサンドボックス化し、誰が何を見て・変えられるかを権限管理・監査ログ化 |
いちばんの肝
設計の核心は「AIに鍵を渡さない」こと。AIが暴走・誤作動・乗っ取られても、鍵は門番の中にあり、重要操作には人間承認を挟めます。だから社員全員に配っても事故が広がりにくい——これが「社内でAIを安全に使える」の技術的な正体です。
正直な現在地
まだ初期版で荒い部分が残ります。オープンソースで自社のCloudflareアカウント上で動く＝データは自社保有、マネージド版（Cloudflareが運用する版）は今後。社内実績としては数千人が日常使いし、営業チームだけで直近30日に1万時間超を削減した、という数字が出ています（＝“荒いが実用段階に入りつつある”）。本番業務を丸ごと載せるより、まず実験して知見を貯めるのが現実的です。
位置づけを整理すると——普通のCloudflare＝あなたが作って社員に届ける土台（第6章）／Cloudflare OS＝社員自身がアプリを量産する土台。教材「会社OSとFDE」で扱った“会社OSを現場に実装する”話の、具体的な載せ場所の一つがこれです。
CHAPTER 9
AIモデルとお金（作る＝サブスク／動かす＝API従量）
使うAIモデルは「選べる」
Cloudflareは中でAIを固定で持たず、AI Gateway経由で好きなモデルに振り分けます。Claude / GPT / Gemini など20社超から選べ、あなたの既存のClaude契約（API）をそのまま挿すことも、「簡単な処理は安いモデル、難所だけClaude」とタスクで振り分けることもできます。Cloudflare純正の軽量モデル（Workers AI）も内蔵。「Cloudflare独自モデルに縛られる」心配は不要です。
お金は「作る」と「動かす」で別勘定
非エンジニアがいちばん不安がる所なので、正直に。AIの費用は2種類あり、混同すると怖く見えます。
| 何の費用か | どの課金？ |
|---|
| 作るとき | Claude Codeでアプリを組む・直す | 既存のClaude Code契約（Pro/Max等）でOK |
| 動かすとき | 完成アプリが利用者の操作ごとにAIを呼ぶ | API従量課金（サブスクとは別） |
チャットの月額サブスク（Claude Pro/Max等）はサーバー上のアプリからは使えません。アプリからのAI呼び出しはAPI（トークン従量）を使うので、サブスクとは別にAPI代が乗る——ここは正しい理解です。ただし過度に怖がる必要はありません。
- 従量＝使った分だけ。社員数人が使う小さな社内ツールなら、月あたり小さな額で収まることが多い。“青天井”になるのは利用者が多い・大量文書を毎回読ませる等のヘビーな使い方のときだけ。
- 上限で蓋ができる。API側の支出上限やAI Gatewayの予算・レート制限で「月◯◯円まで」と設定でき、予想外の高額請求を防げる。
- 安くする定番。キャッシュ（同じ質問の答えを使い回す＝再課金しない）／モデル振り分け／Workers AIの無料枠。
要点
「作る＝サブスク／動かす＝API従量」と分け、API代は使った分だけ・上限で蓋。小さく始めるぶんには怖い金額になりにくく、全社でヘビーに使う段階で初めて設計（キャッシュ・振り分け・上限）が効いてきます。金額は変動が速いので、固める前に必ず各公式の最新料金を確認。
CHAPTER 10
正直な注意点（できないこと・誇張の訂正）
営業でも社内説明でも、盛りすぎると後で食い違います。裏どりで分かった「そのまま言うと危ないポイント」をまとめます。
- ノーコードではない。土台は揃うが、アプリ本体はコーディング（またはClaude Code等のAI）で作る前提。「置くだけで完成」ではない。
- 「サーバー管理が一切ゼロ」は言い過ぎ。台数・OS更新は不要でも、コード・設定・料金の管理は残る。
- 「セキュリティが最初から全部強い」は分けて言う。DDoS対策は無料で強力／WAFは無料だと基本ルールのみ（本格ルールは有料）。
- 「Access/Excelから簡単に移行」は誇大。自動移行機能はなく、作り直し（開発）が必要。“受け皿にはなる”が正確。
- 「外部業者が完全に不要になる」は条件つき。社内にコード/AIを扱える人がいて初めて内製の幅が広がる。
- 無料枠・料金の数字は変わりやすい。本資料の数値は2026年8月時点。契約・見積もり前に必ず公式で最新を確認。
それでも土台として優秀
これらを差し引いても、「社員限定アクセス(Access)」と「既存サーバーの安全な公開(Tunnel)」を安価に汎用的に使えるのは、中小企業の社内システムにとって大きな武器です。誇張せず、この2点＋無料枠で試せる点を軸に説明するのが、いちばん信頼される話し方です。
CHAPTER 11
まとめ
中小企業にとってCloudflareは、「安く・安全に・自分たちでも改善できる社内システム」を作るための土台として、確かに使いやすくなってきています。ポイントを最後に3行で。
- 土台一式が1社で揃う（Workers・D1・R2・Access・Workers AI）。ただしノーコードではなくAIコーディング等で作る前提。
- 効くのはAccessとTunnel。社員限定ログインと既存サーバーの安全公開は、Vercelに同等がない差別化点。
- Vercelとは用途が違う。社内基盤ならCloudflare、対外モダンWebならVercel、で棲み分ける。ただし「対外向けなら必ずVercel」ではなく、表示するだけの静的なサイトは対外向けでもCloudflareが素直（第7章の注記を参照）。
はじめの一歩
いきなり全社システムを作り替えるのではなく、
「社員だけがログインできる小さな社内アプリ」を1つ、無料枠でAIと一緒に作ってみる——これがCloudflareの実力を測るいちばん安全な入り口です。作らせる前の頼み方は
「AIに仕組みを作らせるコツ」を、AIへの依頼文は
「プロンプトの作り方」を参照してください。
用語ミニ辞典
用語ミニ辞典
- サーバーレスserverless
- 自分でサーバーの台数やOSを管理せず、コードを置けば必要なだけ自動で動く仕組み。保守は不要だが、コード・設定・料金の管理は残る。
- Zero Trust / Accessゼロトラスト
- 「社内ネットワークだから信用」ではなく、アクセスのたびに“誰か”を確認する考え方。Cloudflare Accessはこれをアプリ単位で簡単に設定できる仕組み。
- SSOシングルサインオン
- M365やGoogle Workspaceなど、会社で使っているアカウント1つで各アプリにログインできる仕組み。
- Tunnel（cloudflared）トンネル
- 社内サーバーから“外向きの接続だけ”でCloudflareにつなぎ、ポート開放なしで安全にWeb公開する仕組み。
- D1 / R2 / KV
- D1＝SQLの表データベース、R2＝ファイル置き場（PDF/画像/CSV）、KV＝小さなデータの高速保存。
- RAG / AI Search（旧AutoRAG）ラグ
- 社内文書“だけ”を根拠にAIが答える仕組み。AI Searchはその構築を自動化するCloudflareのサービス（旧称AutoRAG）。
- デプロイdeploy
- 作ったものをサーバーに載せて公開する動作。「置くだけ（静的）」から「データ・認証・AI付きの動くアプリ」まで、載せる中身は段階的に広がる（第2章）。
- Cloudflare OSクラウドフレアOS
- Workersの上に建てた“会社の仕事場”。社員がAIに頼んで社内アプリを作れる土台。2026年8月にオープンソース公開（初期版）。
- Gadget / Gatekeeperガジェット／ゲートキーパー
- Gadget＝Cloudflare OSでAIが作る小さな個人アプリ（隔離Worker＋専用SQLite）。Gatekeeper＝鍵を握りAIに渡さず、社内システム/SaaSへの接続を仲介する門番。
- AI Gatewayエーアイ・ゲートウェイ
- 複数のAIモデル（Claude/GPT/Gemini等）への“中継所”。モデルの振り分け・キャッシュ・利用分析・上限設定でコストと安全を管理する。
- API従量課金じゅうりょうかきん
- 使った分だけ（トークン量など）で払う仕組み。アプリが実行時にAIを呼ぶ費用はこれ＝チャットの月額サブスクとは別勘定。上限設定で蓋ができる。
- Vercelヴァーセル
- Next.jsの開発元。フロント／フルスタックの開発とデプロイに強いサービス。Cloudflare Pagesと配信領域で競合する。