Cloudflare OSの配置手順｜自社アカウントへ入れてログインできるまで

公開: 2026年8月19日最終更新: 2026年8月19日

要点：会社専用AIは、チャットツールを契約するだけでは作れません。誰がログインできるのか、AIはどの社内データを読めるのか、どの操作から人の承認が必要なのか。ここまで設計して初めて仕事を任せられます。このページのゴールは、自社のCloudflareアカウントへCloudflare OSを配置し、限られた社員だけがログインできる状態までです。社内データの接続はまだ行いません。

本ページは2026年8月時点のCloudflare OS v2を対象にしています。公式にはEarly Accessで開発途上です。本番導入では、アップデート前の変更確認と権限設計が必要です。手順の詳細は必ず公式Starterのドキュメントで最新版を確認してください。

最初から全社に配らない

結論から言うと、いきなり全社へ配る必要はありません。次の順序が、安全性と現場定着を両立しやすい進め方です。

まず1人で動かして、機能を確認する
次に、ログインできる社員を限定する
最後に、AIが触れる社内データと操作を一つずつ増やす

このページが扱うのは1と2です。3はGatekeeperガイドで扱います。

3つの始め方

方法1：自分のPCだけで動きを見る

機能を短時間で確認したい場合は、公式リポジトリを取得し、pnpmを入れたうえで次を実行します。

pnpm run-local

起動後、ブラウザで http://localhost:8787 を開きます。WranglerとCloudflare Workersのローカル実行環境（workerd）を使い、Cloudflare OS全体を手元で動かす方法です。

公式にも本番用途ではないと明記されています。社内データをつなぐ前の機能確認に限定してください。

方法2：公式のホスト型デプロイを使う

公式のデプロイページから配置する方法です。手早く動く状態にできますが、社内本番では入口と管理責任を自社で持つ方法3を推奨します。

方法3：公式Starterで自社アカウントへ配置する（推奨）

cloudflare-os-starter をベースに、自社のCloudflareアカウントへ配置します。以降はこの方法を前提に説明します。

導入前に必要なもの

公式READMEでは、次の環境が案内されています。

Cloudflareアカウント
Node.js 24
pnpm 11
Wrangler
Cloudflare Workers
KV / R2
Browser Rendering
Dynamic Worker Loaders

Workers AI、AI Gateway、Artifactsは任意です。Cloudflare OSはAIを有効にしない状態でも配置でき、後から利用モデルを設定できます。つまり、最初にモデル選定で悩む必要はありません。先にログイン・保存先・権限・監視の土台を確認できます。

費用の考え方は料金・費用ガイドで整理しています。

実際の導入手順

1. Starterを取得して、必要なパッケージを入れる

リポジトリを取得した後、Cloudflare OS本体を含むサブモジュールと依存関係を準備します。

git submodule update --init
pnpm install
pnpm --dir cloudflare-os install
pnpm exec wrangler login

最後のコマンドでブラウザが開き、利用するCloudflareアカウントをWranglerへ接続します。

2. 社員の入口をCloudflare Accessで守る

Cloudflare OSを、インターネットへ公開して誰でも入れる状態にしてはいけません。Starterの標準構成では、リクエストがCloudflare OSへ到達する前にCloudflare Accessが本人確認を行います。

os.example.com のような専用ドメインを決める
そのドメインを対象に、Cloudflare AccessのSelf-hosted applicationを作る
ログインを許可するメールアドレスや会社ドメインを設定する
AccessのApplication Audience Tagを取得する
deployment.jsonc にドメイン・Audience Tag・管理者メールを記入する

独自ドメインをまだ使わずに検証する場合は workers.dev を利用できます。ただし社内本番では、入口と管理責任を明確にするため、独自ドメインとAccessを使うほうが分かりやすくなります。

3. deployment.jsonc に会社の設定を書く

主に設定するのは次の項目です。

CloudflareのAccount ID
各Workerの名前
Cloudflare OSを開くホスト名
AccessのAudience Tag
管理者のメールアドレス
KVとR2の保存先
AI機能を有効にするか
Contextと独自Gatekeeperを有効にするか

KVやR2の項目を null のままにすると、Wranglerが必要な3つのKV NamespaceとR2 Bucketを自動作成します。既存の保存先を使う場合はIDやBucket名を明示します。

パスワードやAPIキーを設定ファイルへ直接書かないでください。公式Starterも、SecretをGit管理する設定へ入れない設計になっています。認証情報はWorkerのSecretとして登録します。

4. 設定を検査してから配置する

設定が終わったら、いきなり本番へ出さず先に検査します。

pnpm check
pnpm deploy

pnpm check が設定ミスを確認し、問題がなければ pnpm deploy が必要なWorkerを順番に配置します。配置時にはGatekeeperやError Reporterなどの裏側の仕組みを先に作り、その後で社員が使うCloudflare OS本体を配置します。

5. /admin で会社専用の設定に変える

配置できたらCloudflare OSのURLへアクセスし、Accessでログインできることを確認してから /admin を開きます。ここではコードを再配置せずに次を変更できます。

会社名とロゴ
アクセントカラー
社員向けのお知らせ
AIが守る共通ルール
最初に使ってほしいBlueprint
利用可能なコネクター
Contextと独自Gatekeeperの利用可否

ここで最初から全機能を有効にする必要はありません。社員が最初に行う1つの業務だけに絞ったほうが、使われ方と問題点を観察しやすくなります。

完了チェック

公式Starterでは、配置後に次の確認が案内されています。

想定した社員だけがAccessでログインできるか
管理者メールが正しく認識されるか
不要なContextやGatekeeperが無効になっているか
Error Reporterと各Workerのログを確認できるか
/admin から会社名・ロゴ・AIへの共通指示を変更できるか

ここまで確認できれば完了です。この時点では、まだ社内データを接続したり、AIへ書き込み操作を許可したりする必要はありません。

次のステップ

次は、AIとGitHub・Google Drive・顧客管理・社内データベースの間へGatekeeperを置く工程です。GatekeeperはOAuth認証、権限の制限、操作ログ、人間承認を担当する、AI用の「受付担当」にあたります。

「AIへAPIキーを渡す」のではなく、誰が、どのデータに、どの操作まで行えるかを業務単位で設計します。詳しくはGatekeeperガイドを参照してください。

また、技術的な配置と「価値の出る導入」は別物です。業務選定からPoC・部門展開までの組織側の進め方は導入の6ステップで整理しています。

出典

構築・初期設定の代行やハンズオン、Access設計からご支援できます。

導入の相談をする