1. Cloudflare OSとは何か
⚠️ 注記: 本記事は執筆時点(2026年8月)の公式発表に基づきます。仕様・提供状況・提供範囲は今後変わる可能性があるため、最新情報は必ず公式サイトでご確認ください。
Cloudflareは2026年8月5日、公式ブログで「Cloudflare OS」を発表しました。公式ブログでは、次のように説明されています。
「社内の誰もがアプリを作り、業務を自動化し、社内システムに安全にアクセスできるようにする、組織が持つ知識と働き方に沿って形づくられたオープンソースのプラットフォーム」
(原文: "An open-source platform that lets everyone in your company build apps, automate work, and safely access internal systems, shaped around what your organization knows and how it operates.")
ポイントは、この説明のどこにも「エンジニア向け」という言葉が出てこないことです。むしろ主語は「社内の誰もが(everyone in your company)」であり、対象を非開発者・組織全体に広げていることが明確に打ち出されています。
Cloudflareがこの取り組みで解決しようとしている課題は、AIエージェントの能力を「コードを書くこと」の外側へ広げることだと説明されています。AIエージェントが実際に会社の仕事をこなすためには、単に賢いだけでは足りず、「その会社が持っている文脈(どんな業務があり、どんなルールで動いているか)」と「社内システムへのアクセス」の両方が必要になる、という問題意識です。つまり、汎用的に賢いAIを持ってくるだけでは、現場の実務では動かない。そこにどう橋を架けるかが、Cloudflare OSのテーマだと言えます。
具体的には、次のような要素で構成されているとされています。
- 組織の文脈とスキルに紐づいたエージェントのワークスペース
- 社内データに安全にアクセスするためのセキュリティ/ガバナンスの枠組み
- エージェントがチーム向けに作り、個人が手直しできるアプリ
- 決定論的なワークフローに、必要な箇所だけAIの判断を組み合わせる仕組み
- データソースに接続されたライブのダッシュボードやドキュメント
- Gatekeepers によるケイパビリティベースのアクセス制御
技術的な土台としては、Cloudflare Workers(Dynamic Workers、Durable Object Facets)の上に構築されており、既存のMCPサーバーは「MCP Server Portals」経由で利用でき、モデルの選択は「AI Gateway」を経由する設計になっているとのことです。
2. 何が新しいのか。"開発者だけ"から"全社員"へ

Cloudflare OSが象徴しているのは、AIエージェントの「使い手」が変わりつつあるという事実です。これまでAIエージェントというと、コードを自動生成したり、開発作業を助けたりする、エンジニア向けのツールという印象が強くありました。Cloudflare OSが打ち出しているのは、その対象を組織全体に広げるという方向性です。
公式ブログでは、社内で先行して使われてきた実績についても触れられており、あらゆる部門の数千人が、その多くはエンジニアリング以外の部門で、日常的に使っているとされています。これは「一部の技術者が試験的に使っている」という段階ではなく、非エンジニアを含む多くの社員が実務で使い続けている状態を示すものです。
作れるものの例としては、次のようなものが挙げられています。
- ドキュメントやスライドの作成
- 定型作業の自動化
- データ可視化アプリの作成
- データウェアハウスに接続したダッシュボード
- メールの要約
いずれも、エンジニアリングの知識がなくても価値が分かり、日々の業務の中で直接使える内容です。これまでの「AIエージェント」の話が、どちらかというと開発者コミュニティの中で盛り上がっていたのに対し、Cloudflare OSは「事務・営業・企画といった、これまでAIエージェントの主な使い手ではなかった人たち」を正面から対象にしている点が、大きな違いです。
この変化を整理すると、次のようになります。
| 観点 | これまでのAIエージェント像 | Cloudflare OSが示す方向性 |
|---|---|---|
| 主な使い手 | エンジニア中心 | 組織のあらゆる部門(非エンジニア含む) |
| できること | コード生成・開発作業の補助 | 資料作成・業務自動化・ダッシュボード・メール要約 など |
| 土台 | 個別のツールやスクリプト | 組織の文脈とデータに接続されたプラットフォーム |
| アクセスの考え方 | ケースごとの個別対応 | Gatekeepers によるアクセス制御を組み込み済み |
3. 全部AIに任せない、が正解

Cloudflare OSの構成要素を見ていて興味深いのは、「なんでもAIに丸ごと任せる」設計にはなっていないことです。構成要素の一つに「決定論的なワークフローに、必要な箇所だけAIの判断を組み合わせる仕組み」が挙げられています。決定論的なワークフローとは、あらかじめ決まった手順どおりに動く、いわば"通常の自動化"のことです。そこに、判断が必要な部分だけAIを組み込む、というのがこの設計の考え方です。
これは、AIエージェントを組織全体で安全に使ってもらうための、現実的な工夫だと読み取れます。すべての判断をAIに委ねてしまうと、予期しない動きや誤りが起きたときに、どこで何が起きたのか把握しづらくなります。逆に、決まった手順は決まった手順としてきっちり動かし、人間の判断が本当に必要な箇所だけにAIを使う形にすれば、動きが予測しやすく、問題があったときにも原因を追いやすくなります。
もう一つ重要なのが、「Gatekeepers」によるケイパビリティベースのアクセス制御です。これは、社内データへのアクセスを、エージェントごとに何ができて何ができないかという単位でコントロールする仕組みだと説明されています。AIエージェントの対象が全社員に広がるということは、それだけ多くのエージェントが社内の様々なデータやシステムに触れる可能性が出てくるということでもあります。だからこそ、「誰が・どのエージェントが・何にアクセスできるか」を管理する仕組みが、対象を広げるのと同時にセットで用意されている、と見ることができます。
つまりCloudflare OSが示しているのは、「AIエージェントを全社員に開放する」ことと、「何でも自律的にやらせる」ことは、必ずしもイコールではないという設計思想です。任せる範囲を賢く絞り、管理の仕組みを組み込んだうえで、使う人の裾野を広げる。この組み合わせ方は、AIエージェントを自社に取り入れようとするあらゆる会社にとって、参考になる考え方だと言えます。
4. なぜ今、この流れなのか
AIエージェントが開発者の外に広がっていく動きは、Cloudflare OSだけの話ではありません。ここ数年、AIと外部のデータやツールをつなぐための土台が、少しずつ整ってきた流れの延長線上にあります。
たとえば、AIと外部のデータ・ツールをつなぐ共通規格として「MCP(Model Context Protocol)」が2024年11月にオープンソースで発表され、多くのAIサービスで採用が広がってきました。Cloudflare OSも、既存のMCPサーバーを「MCP Server Portals」経由で利用できる設計になっており、こうした共通規格の上に成り立っています。
また、AIに業務の手順を教え、必要なときに読み込ませる「Agent Skills(SKILL.md)」という仕組みも、2025年10月に発表され、同年12月にはオープンな標準として公開されました。これも、AIエージェントが特定の会社・特定の業務の文脈に沿って動けるようにするための取り組みという点で、Cloudflare OSが目指す方向性と通じるものがあります。
こうした土台が積み上がってきたところに、Cloudflareのブログでは2026年8月3日から5日にかけて、AIエージェント関連のタイトルを持つ記事が短期間に集中して公開されています。個々の記事の中身についてはこの記事の執筆時点で内容を確認できていないため踏み込みませんが、少なくとも「AIエージェントをどう組織の中で安全に、広く使えるようにするか」というテーマに、業界としてまとまった関心が向けられているタイミングであることはうかがえます。
5. 今日から準備できること

ここまで読んで、「うちの会社はまだ関係ない話では」と感じた方もいるかもしれません。実際、Cloudflare OSは公開されたばかりのオープンソースの取り組みであり、日本の一般的な企業がすぐに同じ形で導入できるかどうかは、また別の話です。導入のしやすさや、日本語での運用のしやすさなども、今後見ていく必要があります。
ただし、そこで示されている「設計思想」そのものは、特別なツールがなくても、今日から自社の中で真似できるものです。AIエージェントの対象がエンジニアの外に広がっていくとすれば、非エンジニアの会社であっても、次のような準備を進めておく価値があります。
① 業務手順を言語化する。AIエージェントに何かを任せるには、まず人間側が「その業務をどういう手順で進めているか」を言葉にできている必要があります。マニュアルや手順書が整っていない業務は、AIに渡す以前に、そもそも引き継ぎや標準化がしづらい業務でもあります。
② AIに渡してよい情報の線引きをする。どの情報なら入力してよく、どの情報は入力してはいけないのか。会社としての判断基準を、対象が広がる前にあらかじめ決めておくことが重要です。
③ 不可逆な操作は必ず人が承認する運用にする。送信や削除、決済など、取り消しのきかない操作については、AIが提案し、最終的な実行は人が確認・承認するという流れを崩さないことです。これは、Cloudflare OSが「決定論的なワークフローに、必要な箇所だけAIの判断を組み合わせる」としている考え方とも重なります。
④ 小さく1業務から始める。いきなり全社的に広げるのではなく、まずは一つの業務、一つのチームで試し、うまくいった型を横展開していく。この進め方は、対象がエンジニアであっても非エンジニアであっても変わりません。
これらは、Cloudflare OSのような特定のプラットフォームを使うかどうかにかかわらず、AIエージェントを組織で広く使っていく上で共通して求められる土台です。むしろ、ツールを選ぶ前にこの土台を整えておくことこそが、後になって効いてきます。
6. 潮流を理解した先に必要なこと
Cloudflare OSが示しているのは、「AIエージェント=一部のエンジニアが使う先端技術」という段階から、「組織のあらゆる部門が日常的に使う基盤」という段階へ、AIエージェントの位置づけそのものが動き始めているという事実です。この流れは、Cloudflare一社の話にとどまらず、MCPやAgent Skillsといった土台の広がりとあわせて見ると、業界全体が向かっている方向性として捉えるほうが自然です。
とはいえ、こうした潮流を理解することと、実際に自社の業務でAIエージェントを成果につなげることの間には、まだ距離があります。どの業務から着手するか、どこまでをAIに任せ、どこは人が承認するか、どの情報を渡してよいか——こうした線引きは、会社ごとの業務や情報の性質によって変わるため、汎用的な正解をそのまま当てはめるだけでは機能しません。
私たちが提供している「Protostar AI Works」は、こうした潮流を踏まえたうえで、自社のどの業務にAIエージェントを取り入れ、どこまでを任せ、どう安全に運用するかを、現場に入り込んで一緒に設計・実装していく支援です。「話題は分かったが、自社では何から手をつければいいか分からない」という段階から、実際に成果につながる形まで、ご一緒します。
まとめ
AIエージェントは、これまで「開発者が使うもの」という印象が強い技術でした。Cloudflareが2026年8月5日に公開した「Cloudflare OS」は、その前提を更新する象徴的な取り組みです。
- Cloudflare OSは「社内の誰もがアプリを作り、業務を自動化し、社内システムに安全にアクセスできるようにする」オープンソースのプラットフォームだと説明されている
- 対象は明確に"everyone in your company"。社内では、非エンジニア部門を含む数千人が日常的に使ってきた実績があるとされる
- 設計思想は「全部AIに任せる」ではなく、決定論的なワークフローに必要な箇所だけAIの判断を組み合わせ、Gatekeepersでアクセスを制御するというもの
- この流れはMCPやAgent Skillsといった、AIと外部の情報・仕組みをつなぐ土台の広がりの延長線上にある
- 非エンジニアの会社が今日からできる準備は、①業務手順の言語化 ②AIに渡してよい情報の線引き ③不可逆操作は人が承認 ④小さく1業務から、の4つ
Cloudflare OSそのものをすぐ導入できるかどうかは会社によって異なりますが、そこに込められた設計思想は、今日から自社の中で参考にできます。まずは自社の業務を一つ選び、この考え方に沿って小さく試してみることから始めてみてください。
⚠️ 本記事は執筆時点(2026年8月)の公式発表に基づく内容です。仕様・提供状況・提供範囲は今後変わる可能性があるため、最新情報は必ずCloudflare公式サイトでご確認ください。

