社内の業務データをAIに扱わせる仕組みを作り始めると、たいてい同じ場所で手が止まります。エージェントに、どこまで鍵を渡すか。在庫データベースを参照させたいならDBの接続情報が要る。顧客管理システムを見せたいならAPIキーが要る。そこで「読み取り専用のキーを発行して環境変数に置く」という判断をした瞬間、その鍵はエージェントが生成するコードの中に現れる可能性を持ちます。
生成されたコードがログに出るかもしれない。エラーメッセージに混ざるかもしれない。外部の文書を読ませた際に指示を仕込まれ、鍵ごと外に送られるかもしれない。鍵を渡した時点で、この不安は設計では消せなくなります。
Cloudflare が2026年8月5日に Apache 2.0 ライセンスで公開した Cloudflare OS は、この構造そのものを変えにいったものです。名前に反して Linux や Windows のような OS ではなく、AIエージェントとアプリと業務フローを載せるための基盤です。
資格情報がエージェントに届かない構造
Cloudflare OS の中核にある前提は明快です。エージェントが受け取るのは、生のAPIキーでも OAuth トークンでもデータベースの接続情報でもありません。特定のポリシーのもとで特定のリソースにアクセスできる、範囲を限定した「能力の参照」だけを受け取ります。
実際の資格情報は Cloudflare が Gatekeeper Worker と呼ぶ層の内側に留まり、エージェント本体にも、エージェントが生成したコードにも到達しません。エージェントは「この操作をしてほしい」と依頼し、Gatekeeper が権限を確認したうえで実行する。鍵は最後まで外に出ません。
この設計が効くのは、事故の種類が変わるからです。鍵を渡す構成では、漏れた瞬間に被害範囲は鍵の権限すべてに広がります。能力の参照だけを渡す構成では、漏れてもその参照が許可している操作の範囲を超えられません。エージェントが乗っ取られる可能性を前提に置いたときに、差が出るのはこの部分です。
「開発者がいなくても作れる」の中身
もうひとつの柱が、ブラウザから使えるエージェントワークスペースです。社員が調べ物をし、実データにつながった資料を作り、業務フローを自動化し、小さな社内アプリを組み立てて共有する。組み立てたアプリには専用のデータベース、リアルタイム機能、アクセス制御がそれぞれ付きます。
ここで注目すべきは「開発者不要」という売り文句そのものではなく、独立したデータベースとアクセス制御が最初から付いてくるという点です。社内の小さな業務ツールが増えていくとき、たいてい問題になるのは機能ではなく、誰が何を見られるかが後から分からなくなることです。それを個別に設計させず、基盤側が持つ形にしてあります。
エージェントがコードを書いて実行する場も、隔離されたランタイムとして分けられています。組織が用意した文脈とスキルの範囲で動く、という制約が先にあり、その内側で自由に動く。自由の範囲を基盤が決めるという考え方は、前節の資格情報の扱いと一貫しています。
Cloudflare 自身は2026年5月に全社員へ初期版を配り、8月の時点でエンジニア以外も含む数千人が日常的に使っている、としています。ドキュメント作成、スライド作成、細かな社内アプリの作成が主な用途とされます。
自前で作るか、既存のSaaSで済ませるか
Cloudflare OS がオープンソースになったからといって、自社で立てるのが最善とは限りません。判断は、扱うデータと運用体制で決まります。
| 選択肢 | 向いている状況 | 引き受けるコスト |
|---|---|---|
| 既存のSaaSを使う | 扱うデータが機密でなく、業務が標準的 | データの所在と権限がベンダー側の設計に依存する |
| Cloudflare OS のような基盤を自社に立てる | 社内システムとの接続が多く、権限設計を自分で持ちたい | 基盤の運用・アップデート・障害対応を抱える |
| 個別に社内ツールを作る | 対象業務が1〜2種類に限られる | ツールが増えたときに権限が散らばる |
「エージェントに鍵を渡さない」という原則だけは、どの選択肢でも持ち帰れます。既存SaaSを選ぶ場合でも、そのサービスが社内システムへどう接続するのか、接続情報がどこに保存されるのかは確認すべき項目です。
社内で誰がどのAIツールを使っているか把握できていない段階なら、基盤の議論より前にそちらの整理が要ります。着手の順序はシャドーAIとクラウドAIガバナンスで扱っています。
また、エージェントに権限を渡す設計では、実行時に人が承認する形を安全装置として数えないことが前提になります。承認画面の限界についてはAIエージェントの承認は安全装置にならないにまとめました。業務そのものを言語モデルだけで解こうとすると別の壁に当たるため、決定的な処理との組み合わせ方は業務AIは言語モデルだけでは成立しないを参照してください。
次にやること
いま社内で動いている、あるいは検討中のAI連携をひとつ選び、そこで使われる資格情報がどこに保存され、誰が読める状態にあるかを書き出してみてください。環境変数に平文で置いてある、という答えが返ってくるなら、機能の追加より先に手を付ける場所はそこです。
そのうえで、鍵を渡さずに済ませる方法があるかを検討します。多くの場合、間に薄い層を1つ置くだけで構造は変えられます。
社内AI基盤の設計や、既存システムとの安全な接続方法を含めて相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。接続先の数や扱うデータの機密度によって適切な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- Cloudflare OS Is the First AI Workspace Built Around How Companies Actually Work — Cloudflare
- Cloudflare launches Cloudflare OS: an open-source AI agentic workspace for the enterprise — SiliconANGLE
- Cloudflare OS: Here’s What’s Inside the Open-Source AI Agent Platform — Decrypt
- Cloudflare、組織の業務知識やシステム、アプリをエージェントが活用できるAIワークスペース「Cloudflare OS」をオープンソースとしてリリース — gihyo.jp
- Cloudflare Announces Open-Source Cloudflare OS As AI “Operating System” — Phoronix
