社内システムをAIエージェントに繋ぐ話は、たいてい「まずは参照だけ」から始まります。在庫を調べる、案件の状況を答える、書類の場所を教える。ここまでは合意が取りやすい範囲です。
問題は、繋いだ時点で更新もできる状態になっていることが多いことです。MCP サーバーが公開しているツールの一覧には、検索と並んで作成・更新・削除が入っています。エージェントに「参照だけしてください」とプロンプトで伝えても、それは指示であって制限ではありません。
そして事故が起きたとき、監査ログにはエージェントが使っている接続用アカウントの名前だけが残ります。 誰の依頼で、どのエージェントが、なぜその操作をしたのかは、ログから復元できません。
Cloudflare が2026年8月に私設ベータとして発表した WriteGuard は、ここを扱う仕組みです。製品そのものはまだ広く使える段階ではありませんが、何を分けようとしているかが、自社で設計するときの手がかりになります。
読み取りと書き込みでは、壊れ方がまったく違う
同じ「エージェントが間違えた」でも、読み取りと書き込みでは後始末が別物です。
読み取りの誤りは、間違った答えが返るだけです。人間が見て気づけますし、システム側の状態は変わっていません。やり直しが効きます。
書き込みの誤りは、状態が変わったあとに発覚します。取引先に誤ったステータスのメールが飛び、在庫が減り、レコードが消えます。しかも AI エージェントは同じ操作を短時間に何度も実行できるため、人間の作業ミスに比べて気づくまでの件数が桁で違います。
にもかかわらず、多くの接続では両者が同じ扱いになっています。「このシステムへのアクセスを許可する」という単位で権限を渡しているからです。
WriteGuard が分けているもの
WriteGuard は、Cloudflare の MCP サーバーポータルの背後に置かれ、入ってくる MCP のリクエストをすべて受けます。 対象のツールに紐づいたポリシーを読み込み、リクエストの文脈を評価して、次のいずれかに振り分けます。
- 読み取り — そのまま素通しする
- 許可された書き込み — エージェントの帰属情報（どのエージェントの操作か）を付け、監査イベントを記録したうえで通す
- 重要な操作 — ツールのハンドラが実行される前に止める
ここで効いているのは、判定の単位がツール1つずつである点です。「このシステムに繋いでよいか」ではなく「このシステムのこの操作を、この文脈で通してよいか」を見ます。ツールごとにリスクの階層を割り当て、有効・無効を個別に管理する形になっています。
もうひとつは、止める位置です。ハンドラが動く前に落とすので、「実行はされたがロールバックした」ではありません。外部サービスへの副作用が発生しません。
エージェントに社内システムを触らせる際の権限の渡し方は、Google Workspace 側でも同じ論点が出ています。プレビュー段階の MCP サーバーで権限のスコープをどう見るかはGoogle Chat の MCP サーバーで確認すべき権限範囲にまとめました。
ベンダーの機能を待たずに、先に決められる3つ
WriteGuard は私設ベータで、今すぐ自社に入れられるものではありません。ただし、この仕組みが前提にしている3つの整理は、いま自社でできます。 そして、これをやっていない状態で製品を入れても設定できません。
1. ツールの棚卸しを、操作の単位で行う。 接続しているMCPサーバーが公開しているツールを一覧にし、それぞれが「読むだけか」「状態を変えるか」「外部へ出るか」で分類します。システム単位ではなく操作単位です。 一覧を作ってみると、参照目的で繋いだはずのサーバーに削除系のツールが含まれていることがよくあります。
2. 止める操作を、業務側の言葉で決める。 技術的なリスク評価ではなく、「これが自動で実行されたら困る操作は何か」を業務の責任者に聞きます。金額が動く、外部に何かが届く、取り消せない——この3つに当たるものが最初の候補です。技術者だけで決めると、たいてい厳しすぎるか緩すぎるかのどちらかになります。
3. 記録の主語を決める。 監査ログに残る名前が接続用アカウントのままだと、あとから追えません。エージェントごとにアカウントを分けるのか、リクエストに識別子を付けて記録するのか、実装方針を先に決めます。事故が起きてから「誰の操作か分からない」と気づくのがいちばん高くつきます。
この3つ目は、エージェントの操作をどこまで人が承認するかという設計とセットになります。すべてに承認を挟むと運用が回らなくなる問題は承認疲れをどう避けるかで扱っています。
発注・検収の場で確認する一行
AI エージェントを組み込む開発を外部に依頼する場合、仕様書に次の一行を入れておくと、実装後の確認が具体的になります。
エージェントが実行できる操作を、読み取り・更新・不可逆な操作の3区分で一覧化し、更新以上の操作については実行者と実行時刻を監査ログに記録する。
この一行があると、検収時に見るものが決まります。「エージェントは安全に作られていますか」では答えようがありませんが、「更新系ツールの一覧と、その監査ログを見せてください」なら確認できます。
逆に、この整理がないまま「AIエージェントを導入しました」という状態になっている場合、動いている範囲が誰にも把握されていない可能性があります。エージェントに渡した認証情報の管理まで含めた棚卸しの進め方はAIエージェントの認証情報とインシデント対応に整理しました。
次にやること
すでに社内システムを AI エージェントに繋いでいるなら、接続先のMCPサーバーが公開しているツールの一覧を出力して、更新系がいくつあるかを数えてください。 想定より多いはずです。ここが今の実際の権限範囲で、プロンプトで「参照だけ」と書いていても変わりません。
これから導入する場合は、上記の3区分を先に作ってから接続方式を決めてください。 接続してから権限を絞るのは、動いているものを止める作業になり、業務側の合意を取り直すところからやり直しになります。
AI エージェントと社内システムの連携設計、権限と監査ログの設計、既存の導入状況の棚卸しについては、グリームハブの開発・AI・自動化のご相談で承っています。接続先のシステムと業務への組み込み具合によって確認範囲が変わるため、個別にご相談ください。お問い合わせからどうぞ。
