Cloudflare OSで何が実装されているのか｜Gadgets・Gatekeepers・ワークフローから見る会社AIの現実解

発表から数日で見えてきたのは「会社用AI実行基盤」だった

Cloudflare OSのREADMEは、これを通常のコンピュータOSではなく、会社が安全にAIで生産性を上げるためのOS、そしてAIワークロードを管理するためのOSだと説明しています。ここでのOSは、画面やファイルシステムというより、権限、実行環境、共有、監査、アプリ配布をまとめる層です。

Cloudflare公式Blogでは、公開版は社内で使ったv1の学びを踏まえたv2として位置づけられています。v1では個人ワークスペース、静的なアプリ、スキルの再実行が中心でした。しかし、共有したときに「その人が見てよいデータだけが見えるのか」という問題が出てきたため、セキュリティをアプリ作者任せにしない基盤として作り直した、と説明されています。

つまり、Cloudflare OSを見るときは「WindowsやmacOSの代わりか」ではなく、「社内でAIが仕事をするとき、どこに権限を置き、どこに実行環境を置き、どこに監査ログを置くか」と読む方が実務に近いです。

実装1：Gadgetsは、チャットを一回きりの回答で終わらせない

Cloudflare OSの中心にあるのがGadgetsです。READMEでは、スライド作成、共同ホワイトボード、三目並べ、GitHub issue dashboard、Google Docの誤字修正といった例が挙げられています。単にAIが文章を返すのではなく、ユーザー専用の小さなアプリや出力物を作り、そこから使い続けられる形にするのが特徴です。

公式Blogによると、Gadgetのサーバー側はDynamic Workerとしてオンデマンドに読み込まれ、Durable Object Facetとしてインスタンス化されます。各アプリは自分のSQLiteデータベースを持ち、Cloudflare OS本体とは分離されます。これは「AIが作ったコードを全社共通の巨大アプリへ混ぜる」のではなく、「小さな個別アプリとして隔離して動かす」設計です。

会話 → Gadget化 → 個別の実行環境 → 必要なら共有
      ↑
      チャット履歴だけでなく、UI・状態・接続・出力を持つ

中小企業に置き換えると、これは「毎回AIに同じ依頼をする」の次の段階です。見積もりチェック、問い合わせ分類、社内FAQ検索、営業資料のたたき台作成などを、担当者ごとの小さな業務アプリへ変えていく発想に近いです。

実装2：Gatekeepersは、AIにAPIキーを渡さないための安全弁

企業利用で一番危ないのは、AIに強いAPIキーを渡してしまうことです。Cloudflare CIOの記事でも、営業部門のメンバーが「SuperApp」を作るために複数システムの本番APIキーとデプロイ権限を求めてきた話が紹介されています。Cloudflare OSは、この問題への答えとしてGatekeepersを実装しています。

Gatekeeperは、外部サービスのOAuth、リソースの範囲、操作ログ、副作用のある操作の承認を受け持つ小さなサービスです。GitHubなら特定リポジトリだけ、Googleなら特定DocumentやSpreadsheetだけ、BigQueryなら読み取りやdry-runを前提にする、といった粒度へ狭めます。

海外ブログのJamie Lord氏は、この設計を「architecture of distrust」と表現しています。AIを信頼し切るのではなく、AIが間違える前提で、鍵を渡さず、承認前の副作用を直接世界へ反映しない。この見方は、中小企業がAI自動化を始めるときにも重要です。

実装3：Blueprintsは、うまくいった小さなアプリを社内テンプレートにする

Blueprintsは、Gadgetのソースコード、必要な接続、メタデータを共有する仕組みです。重要なのは、チャット履歴、SQLiteの中身、認証情報、実際の接続は含めない点です。つまり「設計図」は共有し、各ユーザーは自分の権限と接続で新しいGadgetを作る、という考え方です。

これは、社内AI活用でよくある「Aさんが作った便利なプロンプトが、AさんのPCやアカウントに閉じている」問題への答えになります。うまくいった営業レポート、会議用スライド、問い合わせ分析、社内チェックリストをBlueprintとして残せば、個人の一回きりの工夫が組織の資産になります。

実装4：共有権限は、リンクを送るだけでは終わらない

Cloudflare OSで面白いのは、Gadgetの共有をかなり細かく考えている点です。GitHubのsharing.mdでは、collaboratorにbuild/useのroleを持たせ、permission graphで誰が誰に共有したかを管理し、revocationをlazyに扱う仕組みが説明されています。

さらに、share linkのキーは128-bit randomで生成され、サーバー側にはHMAC-SHA-256のhashだけを保存します。リンクを再コピーすると新しいキーを発行し、revocation時はリンク配下のアクセスを無効化します。これは「URLを知っている人なら誰でもずっと見られる」という雑な共有ではありません。

またobservers.mdでは、共有相手がGadgetの過去に読んだ情報を見てよいか、Gatekeeper側で検証する構想が記録されています。たとえば、あるGadgetが機密テーブルを読んで作ったダッシュボードなら、そのダッシュボードを共有された人も、その元データを見る権限があるかを確認する必要があります。AI時代の共有は、出力物だけでなく「何を見て作られたか」まで考える必要があるということです。

実装5：ワークフロー化で、AIを毎回呼ぶのではなく必要な場所だけに使う

Cloudflare公式Blogでは、Cloudflare OS v2の大きな変化として、自然言語で説明したワークフローをAIがコード化し、オンデマンド、スケジュール、イベントトリガーで実行できる方向が説明されています。すべてを毎回LLMに考えさせるのではなく、決まりきった部分はコードで、判断が必要な部分だけモデルや人間を使う設計です。

CIO記事では、IT help deskのチケットキュー確認、回答案作成、procurement bottleneckの診断、laptop replacement tracking workflow agentなどの例が紹介されています。さらに直近30日で、sales teamが10,000時間超を節約し、4,000以上のapps/toolsが作られたとされています。

この数字は、単に「AIが文章を書いた」ではなく、業務の繰り返しが小さなアプリやワークフローに変わっていることを示しています。中小企業でも、最初に狙うべきは壮大なAI社員ではなく、毎週・毎月・毎朝発生している小さな作業です。

実装6：Starterリポジトリは、自社OSとして運用するための外枠

Cloudflare OS本体とは別に、cloudflare-os-starterリポジトリも公開されています。これは、pinned upstream releaseを自社ブランド、サインイン、独自ドメイン、storage、integrations、observability、upgrade control付きで運用するためのwrapperです。

READMEでは、branding、identity、routing、data、integrations、AI、operationsといった「会社が所有する部分」が整理されています。ブランドだけ変えるならhosted deployでよいが、custom Gatekeepers、独自エラー報告、自社ドメイン、Email Gatekeeperなどが必要ならstarterを使う、という分け方です。

またobservability docsでは、Workers Observability、structured logs、private Error Reporter Worker、OTLP export、sampling、browser reporting off by defaultなどが説明されています。AIエージェント基盤は、作って終わりではなく、失敗を検知し、誰が見るかを決め、ログに秘密を出さない運用まで必要です。

海外記事の評価：名前への批判より、信頼しない設計が本質

Hacker Newsでは公式Blogの投稿が大きく伸び、Algolia APIで確認した時点では659 points、331 commentsが付いていました。議論では「OSという名前は大げさではないか」という声も目立ちます。Phoronixも、traditional OSではないがApache 2.0のopen-source AI operating systemとして紹介しています。

一方で、Techstrong.aiは、Cloudflare OSをenterprise AI workspace、agentic automation platform、Zero Trust stackの重なりとして捉えています。Jamie Lord氏の記事はさらに踏み込み、Cloudflare OSを「AIを信用しない前提で作られたアーキテクチャ」と評価しています。

この評価は、実務的にはかなり大切です。AI活用の失敗は、「AIが賢くない」よりも、「AIが触ってよい範囲を決めていない」「失敗時の戻し方がない」「誰が出力責任を持つかが曖昧」という形で起きます。Cloudflare OSの実装は、その周辺をOS的に扱おうとしている点に価値があります。

中小企業が読むべき導入順序

Cloudflare OSはearly accessで、READMEにもheavy development、rough edgesがあると明記されています。そのため、今すぐ本番の中核業務へ入れるというより、設計思想と実装部品を自社のAI活用に翻訳するのが現実的です。

i-Styleとしては、Cloudflare OSを「すぐ使うべき新ツール」ではなく、「会社でAIエージェントを安全に増やすときの設計図」として見るのがよいと考えます。チャット画面の便利さより、権限、共有、監査、再利用を先に整える。そこが、AI活用を一過性で終わらせない分かれ目です。

よくある質問

まとめ

• check_circleCloudflare OSは、AIチャットではなく、会社の文脈・権限・実行環境・共有・監査をまとめる会社AI基盤として実装されています。
• check_circleGadgetsはチャットを小さなアプリへ変え、Blueprintsはうまくいった作業を再利用可能にします。
• check_circleGatekeepersとobserver/permission graphは、AIが触るデータと共有時の権限を管理するための重要な部品です。
• check_circleCloudflare社内では、直近30日で4,000以上のapps/tools作成、sales teamの10,000時間超削減など、業務アプリ化の成果が報告されています。

AIエージェントの本番活用は、モデル選びだけでは決まりません。誰の文脈で動き、どの権限で読み、何を承認し、どこにログを残すか。Cloudflare OSの実装は、その問いに対する現実的な設計例として読む価値があります。

参考リンク

• 参考: Cloudflare OS: an open platform for agents, apps, and work（Cloudflare Blog / 2026-08-09確認）
• 参考: How we’re rethinking work at Cloudflare with Cloudflare OS（Cloudflare Blog / 2026-08-09確認）
• 参考: cloudflare/cloudflare-os（GitHub / 2026-08-09確認）
• 参考: cloudflare/cloudflare-os-starter（GitHub / 2026-08-09確認）
• 参考: Blueprints（GitHub docs / 2026-08-09確認）
• 参考: Sharing（GitHub docs / 2026-08-09確認）
• 参考: AI Gateway billing（GitHub docs / 2026-08-09確認）
• 参考: Observability and error reporting（Starter docs / 2026-08-09確認）
• 参考: Cloudflare Announces Open-Source Cloudflare OS As AI "Operating System"（Phoronix / 2026-08-05）
• 参考: Cloudflare Has Open-Sourced Cloudflare OS for AI Agents（Techstrong.ai / 2026-08-05）
• 参考: Cloudflare OS is an architecture of distrust（Jamie Lord / 2026-08-05）

関連記事