Gatekeeperとは？AIに社内データを安全につなぐ仕組み

GatekeeperはAI用の「受付担当」

公式READMEでは、Gatekeeperを「強化版のMCPサーバー」に近いものとして説明しています。ただし役割は、APIを呼び出せるようにするだけではありません。主に次の5つを担当します。

• 本人のアカウントへ接続する：OAuthなどを使い、社員本人の権限で外部サービスへつなぎます。
• AIが扱いやすいAPIへ変換する
• 必要な範囲へ権限を絞る：指定したリポジトリや文書だけに限定します。
• 読んだ内容と実行した操作を記録する
• 外部へ影響する変更は、人が承認するまで実行しない

つまりGatekeeperは、AIへ道具を渡す場所であると同時に、その道具をどこまで使えるか制限する場所です。

アカウントではなく「対象」を渡す

一般的なAI連携では、最初にMCPサーバーやAPIキーを設定し、その後の会話で広い権限を使い回すことがあります。Cloudflare OSは逆です。AgentやGadgetは、最初は外部サービスへ何もアクセスできません。利用者が、仕事に必要な対象を一つずつ紹介します。

公開コードでは、たとえば次の単位を選べます。

「GitHubへ接続したから全リポジトリを自由に触れる」ではなく、「この仕事では、このリポジトリだけを使う」という単位で能力を渡す設計です。権限表にユーザー名を並べる発想ではなく、仕事に必要な対象そのものを手渡す発想で、Cloudflare OSはこれをCapability-based access controlとして説明しています。

OAuthの権限と、AIが使える範囲は別物

ここは見落としやすい点です。外部サービスのOAuth画面では、技術上必要な権限が比較的広く表示されることがあります。たとえばGitHub連携の公開実装は、接続時に repo 権限を要求します。そのうえでGatekeeperが、紹介された特定のリポジトリ・Issue・Pull Requestへ利用範囲を狭めます。

つまり安全性はOAuth画面だけでは判断できません。確認すべきなのは次の2層です。

1. 外部サービスがOAuthトークンへ認めた権限
2. GatekeeperがAgentやGadgetへ実際に公開する対象と操作

OAuthトークンはGatekeeper側で管理し、AgentやGadgetへ直接渡しません。利用者ごとの接続情報は、GatekeeperのUserAccountで保管・更新・失効を管理する設計です。本番導入では「OAuthを設定できた」で終わらせず、Gatekeeperの対象範囲と操作APIをレビューする必要があります。

読み取りと書き込みを、同じ扱いにしない

Gatekeeperでは、外部システムとのやり取りを大きく2種類に分けます。

読み取り（Observation）

文書を読む、Issueを検索する、データベースへSELECTを実行するなど、外部の状態を変えない操作です。公開実装では、読み取り結果を返す前に authorizeObservation() を通し、何を読んだかを記録します。

書き込み（Action）

Issueを作る、文書を編集する、予定を変更する、データベースへ書き込むなど、外部の状態を変える操作です。submitAction() へ送られ、人が承認して applyAction() が呼ばれるまで実際には反映されません。

「読み取りは記録する」「書き込みは承認する」。この二つを分けるだけで、運用ルールがかなり明確になります。

AIを止めずに、あとから承認する

一般的な承認フローには実務上の弱点があります。AIが一つ変更するたびに止まって承認を待つと、長い仕事は最初の操作で止まってしまいます。面倒になって自動承認へ寄せると、今度は安全性が落ちます。

Cloudflare OSのGatekeeperは、承認前の操作をローカルで仮実行します。たとえばAIがIssueのタイトルを変更し、その内容を前提に次のコメント案を作る場合、Gatekeeperは「変更されたように見える状態」をAIへ返します。AIは次の作業へ進めますが、GitHub上の本物のIssueはまだ変わっていません。

仕事が終わった後、人は操作を一つずつ、またはまとめて承認・拒否できます。実行を待たせるのではなく、外部への反映だけを待たせる設計です。

まず接続するなら、この3パターン

全社導入の最初から、すべての社内システムをつなぐ必要はありません。対象が明確で、失敗を確認しやすい仕事から始めます。

1. GitHub：一つのリポジトリでIssue整理

対象は一つのリポジトリに限定します。最初はIssueとPull Requestの読み取りだけを試し、その後にコメント下書き、ラベル変更、Issue作成へ広げます。Mergeまで許可する場合は、別の承認ルールを用意したほうが安全です。

2. Google Docs / Sheets：一つの文書を読む

Google連携はサービスごとにOAuthスコープが分かれています。Google Docsは選んだ文書を読み書きできますが、Google Sheetsの公開実装は読み取り専用です。Google Driveのメタデータ権限は、対象を選ぶ画面のために使われます。「Googleへ接続した」ではなく、「Docsの編集」「Sheetsの読み取り」のように、サービスと操作を分けて確認してください。

3. Supabase：一つのプロジェクトで読み取り分析

最初は query() だけを使い、SELECTとスキーマ確認に限定します。書き込みが必要になってから execute() を使い、人間承認と重複実行対策を確認します。組織全体ではなく特定のプロジェクト接続から始めるほうが、境界を説明しやすくなります。

Contextと、外部システム接続を分ける

Cloudflare OSには、Gatekeeper Contextという会社ナレッジの置き場もあります。Markdown、テキスト、JSON、CSV、コード、画像、PDFなどをコレクションへ保存し、Agentが検索・一覧・読み取りできます。公開コレクションと個人用の非公開コレクションを分けられ、Git互換ストレージから同期する構成も用意されています。

ただし、Contextと業務システムの接続は役割が違います。

• Context：会社のルール、手順、用語、過去の判断を読む
• 外部Gatekeeper：GitHub、Notion、Google、データベースなどの現在の状態を読み、必要に応じて変更する

社内マニュアルを毎回APIで探しに行くより、AIが必ず読む基準文書はContextへ整理したほうが扱いやすい場合があります。一方、最新の案件状況や顧客情報など、常に原本を確認すべき情報は元システムへの接続を残します。

実際の接続手順

配置手順を済ませている前提で進めます。

1. 業務を一つ決める

「Google Workspaceを使えるようにする」では広すぎます。次の形まで絞ります。

例：営業会議の前に、指定したスプレッドシートを読み、未対応案件を要約する

この一文から、対象データ・読み取り範囲・出力・人間承認の有無を決めます。

2. 接続対象のGatekeeperを選ぶ

公開リポジトリには、GitHub、Google、Notion、Supabase、Slack、Linear、Confluence、Cloudflare APIなどのGatekeeper実装があります。利用したいサービスがない場合は、Starterの packages/custom-gatekeeper を土台に自社用を作ります。サービス名だけで「対応済み」と考えず、公開実装の有無を確認してください。

3. 自社のOAuthアプリを作る

GitHubやGoogleなどの管理画面で自社のOAuthアプリを作成します。コールバックURLは、各Gatekeeperの説明にある形式と完全一致させます。

https://<自社のCloudflare OS URL>/gatekeeper/github/oauth
https://<自社のCloudflare OS URL>/gatekeeper/google/oauth

Client IDとClient Secretは、Git管理する deployment.jsonc や wrangler.jsonc へ書きません。Gatekeeper Workerが使うSecretとして登録します。

4. /admin でコネクターを段階的に有効化する

管理画面では、社員へ表示するコネクターと自動提供の方針を設定できます。最初は対象の一つだけを有効にし、その他は無効のままにします。接続数ではなく、1業務が安全に完了するかを検証します。

5. 対象を一つ紹介する

Cloudflare OS上で対象のURLを貼るか、接続画面からリソースを選びます。GitHubなら一つのリポジトリ、Googleなら一つの文書、Supabaseなら一つのプロジェクトです。

6. 読み取り・書き込み・共有を別々に試す

1. 読み取り結果が正しいか
2. Observationが記録されるか
3. 書き込みが承認前に外部へ反映されないか
4. 承認・拒否が想定どおり動くか
5. Gadgetを共有した相手が、本来見られないデータを見られないか

最後の確認は特に重要です。Cloudflare OSのGatekeeperは、共同利用者本人が同じデータへアクセスできるかをVerifierで確認する設計を持っています。Gmailのように個人性が高いデータは、共同利用者へ見せない方針の実装もあります。

導入時に決める6項目

各接続について、次の6項目を1枚の台帳へ残します。

1. 誰が使うか
2. どのサービスへ接続するか
3. どのリポジトリ・文書・プロジェクトを使うか
4. 読み取りと書き込みのどこまで許可するか
5. どの操作に人間承認が必要か
6. ログを誰が、いつ確認するか

さらに、APIキーやOAuth Secret、モデルへのプロンプト、社内文書そのものをログへ残さないルールも必要です。

「AIに何ができるか」ではなく、誰の仕事として、どの対象へ、どの操作まで許可したかを説明できる状態がゴールです。重要なのは、AIへ会社のデータを全部見せることではなく、必要な仕事に必要な対象と操作だけを渡すことです。

出典

• cloudflare-os（公式GitHub）
• Gatekeeper実装ガイド（公式）
• GitHub Gatekeeper / Google Gatekeeper / Notion Gatekeeper / Supabase Gatekeeper
• cloudflare-os-starter: Customization
• MCP Server Portals