Cloudflare OSとは 使い方と非エンジニアへの配り方

「社内の非エンジニアにもAIを配りたい。でも権限とログが怖くて踏み切れない」。

この状態で止まっている組織、けっこうあると思ってます。

Cloudflareが2026年8月5日にオープンソースで公開した Cloudflare OS は、社内で数千人（多くはエンジニア以外の職種）が毎日使っている道具を、そのまま外に出したものです。

Cloudflare OSとは 会話型AIと何が違うのか

公式の説明は「社内の全員がアプリを作り、業務を自動化し、社内システムに安全にアクセスできるようにするオープンソースのプラットフォーム」。

組織固有の知識と仕事のやり方に沿って形づくる前提が置かれています。

要素で割ると3つです。

1. 会社がキュレーションした文脈とスキルを持ち、コードを書いて実行できる隔離ランタイムを備えたエージェントの作業場
2. 社内データとサービスへの安全なアクセスを担うセキュリティとガバナンスの層。既存のMCPサーバーも MCP Server Portals 経由で繋がる
3. 1ファイルがそのまま1アプリになる、個人・プロジェクト・チーム単位のアプリ基盤

会話型AIに社内資料を貼る運用との違いは、返ってくるものが出力ではなくソフトウェアだという点にあります。

スライドの「案」ではなく、開けば動くスライドが返ってくる。

READMEはこれをOSに例えています。

カーネルがバックエンド、デバイスドライバがGatekeeper、シェルがフロントエンド、プロセスがGadget、実行ファイルがBlueprint。

この対応で眺めると設計思想が一気に掴めます。

Cloudflareはエージェント関連の発表が続いていて、開発者向けの Agents SDK や、長時間走るエージェント向けの Project Think と混同されやすい。

Cloudflare OSは作る人ではなく、使う人全員に向いた製品です。

ライセンスはApache 2.0で、公開直後のHacker Newsでは430ポイントを超え、GitHubのスターも2.3kまで伸びました。

エージェント周辺の基盤をCloudflareが固めにきている流れは、AIエージェントが「顧客」になった話から地続きです。

ハマる組織 見送ったほうがいい組織

刺さるのはこのあたりです。

• 内製ツールが乱立している組織。スプレッドシートとGASと誰かの個人スクリプトで業務が回っている状態
• Notion、Slack、GitHub、Google Workspaceがバラバラに使われていて、横断で見たい要求が溜まっている組織
• 情シスが薄く、「これ作ってほしい」の依頼が詰まっている中堅企業やスタートアップ

逆に、いま追わなくていい組織も2パターンあります。

金融や医療のようにデータの経路と処理先に重い審査が要る業界は、自社アカウントに載せられるとはいえ審査工数が別途かかる。

もう1つはCloudflareをまだ使っていない組織で、Workers前提の設計なので、この製品のためだけに基盤を1本増やすのは割に合いにくい。

判断軸はシンプルで、「AIを配ること」より「野良ツールが増える速度」のほうが問題になっている組織ほど効きます。

使い方 ローカル起動から最初のGadgetまで

最短は3手です。

1. リポジトリを取ってきて pnpm run-local。http://localhost:8787 で立ち上がります
2. 画面ごと触りながら試すなら pnpm dev-server と pnpm dev-client を別ターミナルで動かして http://localhost:3000
3. 自社に載せるときは os.cloudflare.app/deploy のオンラインフロー、または社内運用の構成に寄せたサンプル cloudflare-os-starter

GitHub - cloudflare/cloudflare-os: Agent workspace built on Cloudflare Workers for creating documents, building apps, and running agents with your company’s context and systems.

Agent workspace built on Cloudflare Workers for creating documents, building apps, and running agents with your company’s context and systems. - cloudflare/cloudflare-os

github.com

立ち上がったあと何を打ち込むのか。

公式が挙げている例が、そのまま実務のイメージになります。

• 「今度の顧客ミーティング用のスライドを作って」
• 「このGitHubリポジトリのIssueダッシュボードを作って」
• 「このGoogleドキュメントの誤字を直して」
• 「共同編集のホワイトボードアプリを作って」

全部ブラウザで完結するので、開発者である必要もターミナルを触れる必要もない、と公式が明言しています。

社内展開を考えるときの前提条件が、ここで1段変わります。

Gatekeepersで権限をコードに落とす

Gatekeeperは、Cloudflare OSと外部サービスのあいだに立つサービス専用のWorkerです。

OAuth、認証情報の保持、ポリシーの適用、操作ログの記録をここが引き受けます。

エージェント本体は認証情報を持ちません。

効いているのは初期状態の設計です。

各エージェント、各Gadgetは、デフォルトでは何にもアクセスできない。

使わせたいリソースは1つずつ明示的に引き合わせる必要があり、ゼロから足していく方式なので権限の付けすぎが起きにくい。

窓口はGitHub、Google、Slack、Notion、Confluence、Supabaseなどが用意済みで、社内システム向けは自分で足せます。

ここで前に扱った話と繋がります。

AIエージェントに長文ポリシーは効かない Handbook.md論文の衝撃で見たのは、ルールを文章で書いても守られないという問題でした。

Gatekeepersはその裏返しで、守らせる場所を文章から実行経路に移しています。

書いたルールは「お願い」ですが、権限は「通れない」。

両方要るとはいえ、後者を先に作ったほうが事故は確実に減ります。

操作ログが残る点も、監査ログ付きの永続メモリを扱ったときと同じ方向を向いています。

誰のエージェントが何を触ったかを後から説明できない状態では、社内展開の合意形成はまず進みません。

非エンジニアに配るならBlueprintから設計する

配布の鍵はBlueprintです。

作ったGadgetをテンプレートとして共有すると、受け取った人は自分のコピーを動かします。

1つのサービスに全員がぶら下がる形ではないので、誰かがカスタマイズして壊しても、その人の中で閉じる。

実務で決めることは3点あります。

1. 最初のBlueprintは、情シスではなく業務で一番詰まっている人に作らせる。何を自動化すべきかを知っているのはそこです
2. Gatekeeperのスコープを配布前に決める。読み取りだけか、特定リポジトリだけか、書き込み前に人の承認を挟むか
3. ロールアウトは1業務、1チーム、全社の順。最初から全社に配ると、権限設計のミスまで全社にコピーされます

導入支援のパートナーとしてPresidioとHappy Cogが入っています。

自前で回すつもりなら、最初の1チームで運用の型を作ってから広げるほうが安全ですね。

料金と現時点の限界

価格表は出ていません。

オープンソースなので自社のCloudflareアカウントで動かす形になり、かかるのは推論と実行のコストです。

コスト管理はAI Gatewayに寄せてあります。

すべての推論呼び出しがここを通るため、どのモデルを使えるようにするか、どの仕事にどのモデルを当てるかを1か所で決められる。

しかもリクエストは個人・チーム・ワークスペース単位で紐づくので、管理者は支出の内訳を見て、予算とレート制限を設定し、上限に達したときの挙動まで指定できます。

全社に配る前提の製品でこれが最初から入っているのは、稟議の通しやすさに直結します。

一方、未成熟な部分は公式がはっきり書いています。

v2は全面書き直しの直後で、「非常に高機能だが荒削りな部分が多く、early accessだと思ってほしい」という表現。

外部からのPRも、十数行を超えるものは出さないでほしいという方針です。

バグを踏んだときに自分たちで直して本流に返す道は、いまのところ狭い。

入れるなら、止まっても業務が死なない領域からになります。

まとめ 今すぐ試すか様子見か

今すぐ触る価値があるのは、すでにCloudflareを使っていて、社内に「自分で作っちゃう人」がいる組織です。

pnpm run-local を1回叩けば動くので、判断材料はその日のうちに揃います。

追加検証してからにすべきなのは、規制の重い業界と、Cloudflare未導入の組織。

ただしその場合でも、設計そのものは持ち帰る価値があります。

初期権限ゼロ、サービスごとの仲介レイヤー、リクエスト単位のコスト帰属。

この3つは、どのAI基盤を選んでも要件として効いてくるからです。

社内のAI議論が「どのモデルを使うか」で止まっているなら、論点を1つ先に進める材料になります。

決めるべきは、誰に何を触らせるかのほうですから。