本文へスキップ
tech公開更新9分で読めます

AIエージェントにAPIキーを渡すのをやめる ー Cloudflare OSが示した権限設計と、コンタクトセンターへの含意

シェア

2026年8月5日、Cloudflareは社内向けAI業務基盤「Cloudflare OS」の新バージョンをApache-2.0ライセンスで公開した。Cloudflareの公式発表が繰り返し強調するのは生成の精度ではなく、エージェントに「何を渡すか」という権限設計そのものだ。エージェントには生のAPIキーやOAuthトークンではなく、特定のリソースへの特定ポリシー下でのアクセス権だけを表す「ケーパビリティ」オブジェクトを渡す。なぜ鍵をそのまま渡す従来方式が危ういのか、ケーパビリティ方式に切り替えると何が変わるのか。本稿の立場を先に言えば、この権限設計は通話ログ・顧客情報・CRMへAIエージェントを接続する際にコンタクトセンターが確認すべき項目に、そのまま翻訳できる、である。

1. 何が公開されたか ー 「無料で使える」と早合点しない

GitHubリポジトリのREADMEによれば、Cloudflare OSはApache-2.0ライセンスで公開されており、READMEには「Cloudflare OS is in a state of heavy development」「2026年8月リリース時点のv2は非常に機能的だが、still has many rough edges」との但し書きがあり、現状は「early access」として扱うよう案内されている。

OSSと聞くと無料で自社導入できると思われがちだが、そうではない。Cloudflareの料金ページでは、Workers・Durable Objects・KV・Hyperdriveをまとめてカバーする有償プラン「Workers Paid」が月額5ドルからと案内されており、Cloudflare OSを動かすにはこのプランが実質の前提になる。加えてusecarlyの解説記事は、実際の負担額は「Cloudflareの請求とモデルの請求の合計」であり、金額を左右するのは基盤側の月5ドルではなくモデル利用料の方だと指摘する。

explainx.aiの技術解説は、無料のWorkersプランでは生成アプリの実行に使う「Dynamic Workers」が動かないと報告している(複数メディアの伝聞ベースであり、Cloudflare自身の一次記述は確認できていない点は留保する)。

当て馬として一般的なSaaSの無料枠を考えるとわかりやすい。無料枠は「機能制限つきだが使える」ことが多いが、Cloudflare OSはOSS化イコール無償運用ではなく、基盤費とモデル費という2階建てのコストが最初から乗る設計だ。

2. なぜ鍵を直接渡すと危ういのか ー ケーパビリティと観察ログ

エージェントに顧客DBやCRMのAPIキーをそのまま渡す方式の弱点は、キーを持った時点でエージェントがそのシステム全体にアクセスできてしまうことにある。プロンプト経由の誤動作や設計ミスが起きたとき、被害範囲を絞る手立てがない。

Cloudflare OSはここを「Gatekeeper」という専用のWorkerに集約する。Help Net Securityの解説記事によれば、認証情報はGatekeeperだけが保持し、エージェント側は「a small TypeScript API」しか見えず、鍵そのものには一切触れない。ホテルの客室に例えると、フロントがマスターキーを渡すのではなく、宿泊期間中その部屋だけ開くカードキーを渡す設計に近い。マスターキーを預けてしまえば、悪意がなくても操作ミス1つで全客室にアクセスできてしまうが、カードキーなら被害は最初からその部屋に閉じる。もっとも、鍵をそのまま渡す方式が常に危険というわけではない。信頼境界が完全に閉じた社内ツール同士の連携であれば、鍵共有でも実害は出にくい。問題になるのは、エージェントが外部のプロンプト入力や複数システムの橋渡しを担う、境界が曖昧な場面である。

もう1つの柱が「Policy follows what the agent has seen」、つまり観察ログだ。同記事によれば、エージェントが読んだリソースはすべて記録され、その記録は生成された成果物に付随する。誰かがその成果物を開こうとすると、システムはその人自身が同じリソースへのアクセス権を持つかを都度確認してから表示する。要約を作らせたら権限のない担当者にまで個人情報が流れた、という事故パターンに直接効く設計だ。

Model Context Protocol(MCP)との違いも整理しておく必要がある。同記事は、MCPがエージェントの呼び出せる「ツール」を定義する接続言語であり、実際にどのデータを読んだかまでは追跡しないと説明する。Cloudflare OSはこの死角を観察ログで埋める形で、MCPと競合するのではなく粒度の異なる層として積み重なる。実際、Cloudflareの公式発表では既存のMCPサーバーをそのままGatekeeper経由で使う「MCP Server Portals」という仕組みにも触れられている。整理すると、MCPはツール単位の接続言語、Gatekeeperはリソース単位・フィールド単位・操作単位の統制層という役割分担になる。

3. コールセンターAI導入への適用 ー 鍵配布方式から抜け出す4つの確認項目

3. コールセンターAI導入への適用 ー 鍵配布方式から抜け出す4つの確認項目

この権限設計をそのまま、通話ログ・顧客情報・CRMへAIエージェントを接続する際の確認項目に翻訳する。

①キー配布方式かケーパビリティ方式か。 ベンダーの導入資料で「CRMのAPIキーを発行してエージェントに設定してください」と書かれていたら、それは鍵配布方式だ。特定のオブジェクト・特定の操作だけに絞ったスコープ付きトークンを発行できるか、ベンダーに確認する。

②読み取り範囲がリソース単位・フィールド単位で絞れるか。 「顧客テーブルへのアクセス」ではなく「この案件の対応履歴だけ」「氏名・電話番号は見せず要約のみ」まで絞れるか。テーブル単位でしか絞れない設計は、Gatekeeperが目指す粒度に届いていない。

③出力を共有した瞬間に受け手の権限を再評価する仕組みがあるか。 エージェントが作った通話要約や分析レポートを社内共有するとき、共有先の担当者が元データへのアクセス権を持つかを都度確認する仕組みがあるか。無ければ、要約経由での情報漏えいという先述の事故パターンをそのまま抱え込む。

④書き込み操作の承認フローが即時ブロックか、非同期のバッチ承認か。 explainx.aiの技術解説は、Gatekeeperが読み取りは即時許可する一方、CRM更新のような書き込みは人間の承認を要求し、承認待ちの間もエージェントが結果を先にシミュレートして動作を止めずに次のアクションを積み、人間が最後にまとめて承認できる設計だと説明する。コールセンターのCRM更新・返金処理・エスカレーション起票のような書き込み系オペレーションを自動化する際、この非同期承認の設計は「毎回人間を待たせて自動化の速度を殺す」か「人間の目を通さず一括自動実行する」かの二択を避ける、第三の選択肢になる。

4. ここからは私の見立て ー 補完関係であり、自社完結にはまだ早い

ここからは私の見立てとして書く。Cloudflare OSはMCPを置き換えるものではなく、MCPが担う接続層の上に、リソース・フィールド・操作単位の統制層を重ねる補完関係だと見ている。MCPで社内システムとエージェントをつなぐ動きはこの1年で急速に広がったが、「つながった後にどこまで見せるか」の設計は各社の実装依存で、標準がなかった。Cloudflare OSのGatekeeperと観察ログは、その空白を埋める1つの具体案として業界に参照される可能性がある。

自己反証もしておく。「OSSでApache-2.0公開されたのだから自社で完結できる」と考えるのは早計だ。GitHubのREADMEは自前サーバーへのworkerdデプロイを「COMING SOON」と明記しており、現時点ではCloudflareのホスト版が実質の前提になる。加えて前述の通り「still has many rough edges」の早期アクセス品質で、SLAの明示も見当たらない。通話録音や与信情報のような機微データを扱うコンタクトセンター業務をいきなり本番接続するには早すぎる。workerdでの完全セルフホスト対応・SLAの明示・実運用でのトラブル事例の蓄積、この3条件が揃うまでは、社内ナレッジ検索のような書き込みを伴わない低リスク用途で権限設計だけを検証する使い方が妥当だろう。

まとめ

第一に、Cloudflare OSはエージェントに生のAPIキーを渡さず、Gatekeeperが管理するケーパビリティだけを渡す権限設計を核に据えたOSSであり、OSS化は無償運用を意味しない。第二に、この設計の要は「読ませた記録が出力に付随し、共有時に受け手の権限を再評価する」観察ログと、書き込みだけ人間承認を挟む非同期承認の2点にあり、コールセンターの通話ログ・CRM接続チェックリストにそのまま翻訳できる。第三に、workerdでの完全セルフホストが未提供で早期アクセス品質である以上、機微データを扱う本番接続への採用は時期尚早で、まずは低リスク用途での検証にとどめるべきだ。

自社がAIエージェントに接続を許しているシステムのうち、生のAPIキーをそのまま渡しているものはいくつあるだろうか。


注記: 本稿の事実関係は2026年8月11日時点で各出典URLを確認した。コスト試算・無料プランの制限に関する一部の記述は第三者メディアの伝聞であり、Cloudflare自身の一次記述を確認できていないため留保付きで扱った。4章は筆者個人の見解である。


出典

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと隔週ニュースレターを受け取れます。

無料で会員登録する
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア