Geminiは通りClaude Codeは止まる｜情シスのAI許可を2軸で分解する

同じ会社でGeminiやNotion AIは全社解禁されているのに、Claude CodeやCursorのようなコーディングエージェントは止まっています。この非対称は「情報漏洩リスクがあるから」では説明できません。どちらも社外にデータは出ているからです。

結論から書くと、情シスの判断には性質の違う2本の軸が混ざっています。ひとつはデータが既存の契約の枠内にとどまるかという軸で、これは技術的なリスク評価というより調達と契約のプロセスの都合に近いものです。もうひとつはそのAIがファイルやコマンドを自分で動かせるかという軸で、情シスが本当に警戒しているのはこちらです。ワークスペース内蔵AIは2軸の両方で安全側に立ち、コーディングエージェントは両方で反対側に立ちます。だから判断が両端に出ます。

条件付きで許可するための道具は、すでに実装されています。実行してよいコマンドの指定、利用者が上書きできない管理者設定の配布、MDM（モバイルデバイス管理。会社が社員のPCやスマホの設定を一括で配って管理する仕組み）を使った全社展開、通信先の絞り込み、自動承認モードの封鎖です。これはClaude Codeに限った話ではなく、VS CodeにもGitHub Copilot CLIにも同じ発想の仕組みがあります。設定キーの名前まで含めて、この記事で具体的に並べます。

ただし、許可リストを引いただけでは線を引けていません。コマンドの引数を制約するパターンは脆いとAnthropic自身が公式ドキュメントに書いていますし、許可リストが実際に回避された脆弱性も複数登録されています。残るのは、実行環境の隔離、短命で狭い権限、実際に起きた変更の記録、そして元に戻せる形にしておくことです。

そして今の判断には賞味期限があります。許可の根拠が「まだそこまで自律的ではないから」なら、その機能が乗った瞬間に判断が使えなくなるからです。日本で最も新しい部類の公的ガイドラインですら、自律的な判断・実行の欄はリスク評価が空欄のままになっています。この記事では、2軸のマトリクスと自己判定の質問、実在する統制手段の一覧、そして情シスに持っていく提案の骨子までをまとめます。

同じ会社で、AIの判断が真っ二つに割れている
「リスクがある」は、性質の違う2つの心配が混ざっている
条件付き許可の道具は、もう手元にある
許可リストを引いただけでは、線は引けていない
今の判断には賞味期限がある
よくある質問
調査手法について

同じ会社で、AIの判断が真っ二つに割れている

同じ組織、同じ担当者、同じ規程のもとで、GeminiやNotion AIは全社解禁され、Claude CodeやCursorは止まっています。この非対称は「情報漏洩リスクがあるから」では説明できません。どちらも社外にデータは出ているからです。ここでは、判断が割れる現象そのものを出発点に置きます。

同じ日に、同じ担当者から違う答えが返ってくる

情シスに「生成AIを業務で使いたい」と相談すると、こんな返事が返ってくることがあります。GeminiやNotion AIはもう全社で使えます、と。ところが同じ日に、同じ担当者から、Claude CodeやCursorのようなコーディングエージェントについては「それは止めています」と言われます。

会社は同じ、担当者も同じ、規程も同じです。それなのに判断が割れます。

理由を聞くと、たいてい「情報漏洩のリスクがあるので」という答えが返ってきます。ただ、この説明は成り立っていません。Geminiに社内文書を要約させるとき、そのデータはGoogleのサーバーに送られています。社外に出ているという意味では同じです。にもかかわらず片方は通り、片方は止まる。「リスクがあるから」だけでは、この非対称を説明できないのです。

この食い違いを何度か見ているうちに、私はどうやら判断の軸そのものが2本あるらしい、と思うようになりました。1本の物差しで測っていると矛盾に見えるものが、2本で測ると素直に説明がつきます。そういう構造になっている気がしています。

ここで大事なのは、止めている側が理不尽なわけではない、ということです。判断が一貫して割れているということは、そこに何らかの基準が働いているはずです。ただ、その基準が言葉になっていません。だから止められた側は「なぜダメなのか」がわからず、止めた側も「なぜこっちはいいのか」をうまく説明できません。両者が同じ言葉を持てないまま、話が止まります。心当たりのある方も多いのではないでしょうか。

公的なガイドラインでも、線引きは慎重に扱われている

実際、日本で最も整備が進んでいる部類の公的資料でも、この線引きは慎重に扱われています。東京都デジタルサービス局が2026年3月に出した生成AI利用の手引きは、庁内の共通ツールについて「機密性Aまでの情報の取扱いを認めています」と踏み込む一方で、「許可されていない生成AIを業務で利用すること、私物端末上で生成AIを用いて業務を行うことは禁止されており、違反すると懲戒処分の対象となる場合があります」とも書いています。積極的に使わせる方針と、承認していないツールは厳しく止める方針が、同居しているわけです。

一方で、ルールが追いついていない実態を示すデータもあります。IPAが2024年7月に公開したテキスト生成AIの導入・運用ガイドラインは、JIPDECとITRの調査を引きながら、利用規定やガイドラインが策定されている企業の割合は「会社で構築・契約した生成AIを使用している企業では68.6%、社員各自で契約・登録した生成AIを使用している企業では9.0%」だと紹介しています。

会社が用意したツールにはルールが付いてきますが、個人が勝手に契約したツールにはほとんど付いてきません。止めた結果として、見えないところで使われている可能性が高いという話です。

犯人探しではなく、判断の軸を取り出す

この記事では、犯人探しをしません。情シスが悪いとも、経営が悪いとも書きません。代わりに、判断の軸を2本に分けて取り出します。軸が2本あることがわかると、なぜGeminiが通ってClaude Codeが止まるのかが説明できるようになります。そして説明できるようになると、「全部ダメ」と「全部OK」の間に線を引けるようになります。

なお、組織としてAI活用が進む会社と進まない会社が分かれる構造については、AI活用が進む会社と進まない会社の分岐点で別途書きました。そちらは組織と意思決定の話で、この記事は技術的にどこで線を引くかの話です。あわせて読むと、詰まっている場所が上流なのか下流なのかを切り分けやすくなると思います。

「リスクがある」は、性質の違う2つの心配が混ざっている

判断の軸は2本あります。データが既存の契約の枠内にとどまるかという軸Aと、そのAIが自分でファイルやコマンドを動かせるかという軸Bです。軸Aは技術的なリスク評価というより調達と契約の都合に近く、情シスが実際に警戒しているのは軸Bのほうです。この2本で並べ直すと、Geminiが通ってClaude Codeが止まる理由が説明できます。自己判定用の6つの質問も最後に置きます。

現場で「リスクがあるから」と言われるとき、そこには少なくとも2つの別々の心配が同居しています。ひとつはデータがどこへ出るかという心配、もうひとつはそのAIがPCやシステムを操作して壊すかという心配です。この2つは性質がまったく違うのに、同じ「リスク」という言葉でひとくくりにされています。分けて見ていきます。

軸A：データがどこへ出るか

まず、ワークスペースに内蔵されたAIが何と言っているかを、公式ドキュメントで確認してみます。

GoogleはGoogle WorkspaceにおけるプライバシーのFAQで、入力されたプロンプトは顧客データであり、顧客の許可や指示なしにモデルの学習には使わないと明記しています。そのうえで「Your use of Gemini with the Workspace app is governed by your organization’s Workspace agreement」、つまりGeminiの利用は組織が既に結んでいるWorkspaceの契約に従う、と書いています。

アクセス範囲についても「If the user doesn’t have access to a document or email, Gemini will not retrieve that content」、利用者本人が見られない文書にはGeminiも触れないとしています。

NotionもNotion AI security practicesで、Notion自身もそのAIサブプロセッサー（顧客データの処理をさらに再委託される先の事業者のこと）も、顧客データをモデルの学習に使わないと書いています。既存の権限も尊重されます。

MicrosoftもMicrosoft 365 Copilotのデータとプライバシーに関するドキュメントで「There’s no change to these commitments」、既存のコミットメントに変更はないと述べています。

ここで、うっかり言いたくなることがあります。「これらのツールは新しい委託先が増えないから稟議が要らないのだ」と。私も最初はそう理解していました。けれど原文を読み直すと、そうではありません。MicrosoftもNotionも、OpenAIやAnthropicを明示的にサブプロセッサーと呼んでいます。委託先自体は増えているのです。

増えないのは、契約の受け皿のほうです。新しいサブプロセッサーが追加されても、既にあるデータ処理契約と通知プロセスがそれを吸収する設計になっています。だから利用者側は個別に契約を結び直さなくて済みます。正確に言うなら「委託先が増えない」ではなく「委託先が増えても既存契約の枠内で吸収される」です。

そしてここが重要なのですが、この軸は技術的なリスク評価というより、調達と契約のプロセスの都合に近いものです。安全かどうかを技術的に測っているのではなく、既に通した稟議の範囲でカバーできるかを見ています。だから審査が軽くなります。悪いことではありませんが、リスク評価そのものではないことは意識しておくべきだと思います。

なお、入力したデータがAIに「覚えられて」学習されるのではないか、という不安はかなり広く共有されています。この誤解の中身についてはClaudeのメモリーは「学習」ではないで3層に分けて整理しました。軸Aの議論をするときは、まずここの理解を揃えておくと話が早くなります。

軸B：PCやシステムを操作して壊すか

もうひとつの軸は、そのAIが何をできるかです。

提案を返すだけのAIは、間違えても文章が間違っているだけです。人間が読んで、おかしければ捨てます。ところがファイルを書き換えたり、コマンドを実行したり、外部のAPIを呼んだりできるAIは、間違えるとその場で何かが起きます。ファイルが消えたり、設定が書き換わったり、本番環境に変更が入ったりします。

この違いは、専門用語では「エージェント性」と呼ばれます。自分で道具を選んで、自分で動かして、目的に向かって進む度合いのことです。詳しくはマルチエージェントとは？で整理しています。

情シスが本当に嫌がっているのは、どうやらこちら側です。「AIが誤操作でファイルを消す」は、具体的に想像できる被害だからです。抽象的な情報漏洩論より、意思決定に効きます。表向きは軸Aの言葉で説明されていても、判断を決めているのは軸Bのほうだ、というのが私の見立てです。

実際、これが空想でないことを示す事例もあります。2025年7月には、Replitのエージェントが本番データベースのデータを削除したとCEO自身が認め、PCMagが報じています。これは外部からの攻撃ではなく、明示的な指示に反してエージェントが動いた例です。攻撃を受けなくても事故は起きうる、ということでもあります。

2軸で並べ直すと、線引きが説明できる

この2本を縦横に置くと、こうなります。

	提案を返すだけ	自分で操作する
既存契約の枠内で完結	Gemini in Workspace、Microsoft 365 Copilot、Notion AI	ここが今、急速に埋まりつつある
新しい契約や設定が必要	個人アカウントのチャットAI	Claude Code、GitHub Copilot CLI、Cursor

Geminiが通ってClaude Codeが止まる理由が、これで説明できます。ワークスペース内蔵AIは2軸の両方で安全側に立っています。コーディングエージェントは両方で反対側に立っています。判断が割れているのではなく、2つの軸で同時に評価した結果が、たまたま両端に出ているわけです。

うちのツールはどちらの象限か

自分が使いたいツールがどこに位置するかは、6つの質問で判定できます。

そのツールは、会社が既に結んでいる契約の枠内で動きますか。新しい発注や規約への同意が必要ですか
入力したデータを学習に使わないと、公式ドキュメントに明記されていますか。営業資料ではなく、技術文書やヘルプセンターで確認できますか
そのAIは、利用者本人がアクセス権を持たない情報を見られますか
そのAIは、提案を返すだけですか。それともファイル、コマンド、外部APIを自分で動かせますか
動かせる場合、実行の前に人間の承認が入りますか。承認を省略できるモードは存在しますか
何か起きたとき、元に戻せますか。誰が何をしたかのログは残りますか

1から3が軸A、4から6が軸Bです。ここまで分けて聞けば、「リスクがあるから」という一言では終わらなくなります。そして質問の4から6は、実は設定でコントロールできる項目です。次の章で、その具体的な手段を見ていきます。

条件付き許可の道具は、もう手元にある

実行してよいコマンドの指定、利用者が上書きできない管理者設定の配布、MDMでの全社展開、通信先の絞り込み、自動承認モードの封鎖。こうした機能は主要なAIコーディングツールにすでに実装されています。Claude CodeだけでなくVS CodeやGitHub Copilot CLIにも同じ発想の仕組みがあり、設定キーの名前まで公式ドキュメントで公開されています。

「禁止か解禁か」の二択で考えると身動きが取れなくなりますが、実際に何ができるのかを設定の名前まで含めて見ていくと、この二択がかなり大雑把だったことがわかります。順番に見ていきます。

実行してよいコマンドを、明示的に決める

Claude Codeでは、権限設定のドキュメントにある通り、permissionsの下にallow、deny、askの3つのリストを書けます。

{
  "permissions": {
    "allow": ["Bash(npm run test *)", "Read(~/.zshrc)"],
    "deny": ["Bash(curl *)", "Read(./.env)", "Read(./secrets/**)"]
  }
}

評価される順番が決まっているのがポイントで、公式は「Rules are evaluated in order: deny, then ask, then allow」と書いています。最初にdenyを見て、次にask、最後にallowを見ます。先にマッチしたものが勝ちます。だからdenyに書いたものは、allowに細かい例外を書いても通りません。公式も「a deny rule can’t carry allowlist exceptions」と明記しています。禁止は禁止として効く、ということです。

GitHub Copilot CLIにも同じ考え方があります。ツールの許可と拒否のドキュメントによれば、--allow-tool='shell(git:*)'でgitコマンド全般を許可しつつ、--deny-tool='shell(git push)'でpushだけを止める、といった書き方ができます。こちらも「Deny rules always take precedence over allow rules」、拒否が常に優先されると書かれています。

利用者が上書きできない設定を、管理者が配る

ここが情シスにとって一番効く部分だと思います。個人が自分の設定ファイルを書き換えて回避できてしまうなら、統制になりません。

Claude Codeには管理者向けの設定ファイルがあり、公式の優先順位表では最上位に置かれていて、コマンドライン引数を含め他のどのレベルからも上書きできないと説明されています（原文は「Cannot be overridden by any other level, including command line arguments」）。

配置先はmacOSなら/Library/Application Support/ClaudeCode/managed-settings.json、WindowsならC:\Program Files\ClaudeCode\managed-settings.jsonです。Linuxの場合はシステム設定ディレクトリの配下にclaude-code/managed-settings.jsonを置きます。

配布方法もファイルコピーに限りません。macOSではcom.anthropic.claudecodeという管理対象の設定ドメインが用意されていて、公式ドキュメントはJamfやKandjiのようなMDMツールの構成プロファイルで配布できると説明しています（原文は「Deploy via configuration profiles in Jamf, Iru (Kandji), or similar MDM tools」）。

WindowsではHKLM\SOFTWARE\Policies\ClaudeCodeというレジストリ（Windowsが設定を保存している場所）のキーにJSONを入れて、Group PolicyやIntuneといった、多くの会社がすでに使っている端末管理の仕組みで配ります。新しい配布基盤を用意する必要はなく、社内で回っているMDMにそのまま乗せられるということです。

VS Code側も構造は同じです。企業向けのAI設定ドキュメントは3つの配布経路を挙げています。MDM経由(WindowsのレジストリまたはmacOSの管理対象設定、Intuneなどを想定)、GitHubアカウント経由のサーバー管理、そして設定ファイルの直接配置です。ファイル配置については「for use with configuration-management tools such as Chef, Puppet, or Ansible」と、構成管理ツールでの運用を想定していることが明記されています。

通信先を絞る

コマンドを制限しても、外部に何でも送れる状態なら意味が薄くなります。Claude Codeのサンドボックスのドキュメントでは、通信先をドメイン単位で指定できます。サンドボックスというのは、AIが動く範囲を壁で囲って、その外側のファイルやネットワークには手が届かないようにする仕組みのことです。

{
  "sandbox": {
    "enabled": true,
    "network": { "allowedDomains": ["github.com", "*.npmjs.org"] }
  }
}

deniedDomainsで個別に塞ぐことも、allowManagedDomainsOnlyで管理者が許可したドメイン以外を一律で落とすこともできます。VS Code側にもChatAgentAllowedNetworkDomainsとChatAgentDeniedNetworkDomainsがあり、こちらも「Denied domains always take precedence over allowed domains」と、拒否が優先されると書かれています。

自動承認モードを封じる

エージェント系ツールには、確認を全部飛ばすモードがたいてい用意されています。Claude CodeのbypassPermissions、GitHub Copilot CLIの--allow-all-toolsや--yolo、VS CodeのBypass ApprovalsやAutopilotがそれにあたります。

これらは開発者にとっては便利ですが、社内標準としては危険です。だから各社とも封じる手段を用意しています。Claude Codeならpermissions.disableBypassPermissionsModeを"disable"にします。VS Code側にも同名のキーがあり、ChatToolsAutoApproveポリシーで全体の自動承認を止められます。公式ドキュメント自身が、全ツールの自動承認はセキュリティ上おすすめしないとはっきり書いています（原文は「This is not recommended for security reasons」）。

GitHub Copilot CLIに至っては「If you have a Copilot Business or Copilot Enterprise license, these commands may be blocked by an enterprise administrator」と、企業ライセンスなら管理者がブロックできることが明記されています。

エージェント機能そのものを切ることも可能です。VS CodeではChatAgentModeポリシーをfalseにすると「To disable agents entirely」、エージェント機能をまるごと無効化できます。MCPサーバー（AIに外部のツールやデータへの接続口を追加する仕組み）の利用可否も、ChatMCPでall、registry、noneの3段階から選べます。誰でも好きに追加できる状態にするか、会社が登録したものだけにするか、そもそも使わせないか、ということです。

まとめると、こうなります

やりたいこと	Claude Code	VS Code / GitHub Copilot
特定のコマンドを禁止する	`permissions.deny` に `Bash(curl *)`	`--deny-tool='shell(git push)'`
利用者が上書きできない設定を配る	管理者向け設定ファイル(最上位)	Copilot管理設定(3経路)
MDMで全社配布する	`com.anthropic.claudecode` / レジストリポリシー	Intune / レジストリ / macOS管理対象設定
通信先を絞る	`sandbox.network.allowedDomains`	`ChatAgentAllowedNetworkDomains`
自動承認モードを封じる	`permissions.disableBypassPermissionsMode`	`ChatToolsAutoApprove`
エージェント機能ごと切る	権限モードを`dontAsk`にする	`ChatAgentMode` を false

さらに細かく制御したい場合は、Claude Codeのhooksを使って、ツールが動く直前に自前のスクリプトで判定を差し込むこともできます。終了コード2を返せばその実行は止まります。複数のAIツールを組み合わせて運用する構成については、Claude Code×Codex連携の実装にも具体例を書きました。

ここまで並べると、「禁止か解禁か」という二択がかなり雑な問いだったことがわかります。ただし、ここで安心して終わってしまうと、大事な落とし穴を見落とします。次の章で、その話をします。

許可リストを引いただけでは、線は引けていない

コマンドの引数を制約するパターンは脆いと、Anthropicが自社の公式ドキュメントに明記しています。実際に許可リストが回避された脆弱性も複数登録されており、コーディングエージェントへの攻撃成功率が最大84%に達したという研究もあります。残る対策は、実行環境の隔離、短命で狭い権限、実際に起きた変更の記録、そして元に戻せる形にしておくことの4つです。

前の章で紹介した設定は、どれも実在するし、有効です。ただ、それだけで安全になったと考えるのは早いです。しかもこれは、外部の批判者が言っているだけの話ではありません。ツールを作っている側が、自分の公式ドキュメントに書いています。

ベンダー自身が「脆い」と書いている

Claude Codeの権限設定のドキュメントには、こう書かれています。

Bash permission patterns that try to constrain command arguments are fragile.

コマンドの引数を制約しようとするパターンは脆い、という意味です。続けて具体例まで挙げられています。Bash(curl http://github.com/ *)と書けばcurlの接続先をGitHubに限定できそうに見えるけれど、URLの前にオプションが入った場合、プロトコルが違う場合、リダイレクトされた場合、変数が使われた場合、余計なスペースが入った場合には、このパターンにマッチしないと書いてあります。

同じドキュメントにはこんな記述もあります。

Note that using WebFetch alone doesn’t prevent network access. If Bash is allowed, Claude can still use curl, wget, or other tools to reach any URL.

Web取得用のツールにドメイン制限をかけても、シェルが使えるならcurlやwgetで同じことができる、という話です。制限をかけた気になっていても、横から抜ける道が残っています。

セキュリティのドキュメントには、もっとはっきりした一文があります。

While these protections significantly reduce risk, no system is completely immune to all attacks.

これらの保護はリスクを大きく減らしますが、あらゆる攻撃を防ぎきれるシステムは存在しません。ベンダーがこう書いているのに、日本語のセキュリティガイド記事がこの部分を引用しているのを、私はあまり見かけません。

実際に、許可リストは破られている

理屈だけの話ではなく、脆弱性として登録されている実例があります。ここで出てくるCVEというのは、世界中で共有されている脆弱性の管理番号のことで、米国のNVD（National Vulnerability Database）という公的なデータベースに登録されます。誰かの主張ではなく、公的に記録された事実だと考えてください。

CVE-2026-28470は、OpenClawというツールで許可リストが回避された件です。NVDは、二重引用符で囲んだ文字列の中にエスケープされていないコマンド置換やバッククォートを埋め込むことで、攻撃者が許可リストの保護を回避できたと記録しています（原文は「Attackers can bypass the allowlist protection by embedding unescaped $() or backticks inside double-quoted strings」）。シェルは文字列の中身を展開してから実行するので、表面の文字列だけを見ている許可リストは、展開されたあとに何が動くのかを見ていません。だから素通りします。

CVE-2026-22708はCursorの事例で、こちらはもっと厄介です。調査したPillar Securityによれば、許可リストが空の状態でもexportのようなシェル組み込みコマンドは確認なしで実行できてしまい、それを使って環境変数を汚染できました。

そのあとでgit branchのような、誰もが許可リストに入れる無害なコマンドを実行させると、汚染された環境変数が効いて別のことが起きます。Pillar Securityはこう書いています。

Developers routinely allowlist common commands like git, python, or npm to reduce friction. These allow lists become attack vectors rather than security controls.

よく使うコマンドを許可リストに入れる運用そのものが、攻撃の入り口になるという指摘です。

承認ボタンを押させる設計そのものへの疑い

Wiz Researchが2026年7月に公開したGhostApprovalという報告は、さらに根本的な問題を突いています。プロジェクト内のファイルが実はシンボリックリンク（別の場所にあるファイルへの近道。開くと本体のほうが開く）で、リンク先が機密ファイルだった場合、エージェントはリンクをたどって本体に書き込むのに、利用者に表示される承認ダイアログには近道のほうのファイル名しか出ない、というものです。

Amazon Q Developer、Claude Code、Cursorなど6つの製品で共通して見つかり、CVE-2026-12958などとして登録されています。

この問題を整理したCo-Ventechの記事は、人間の承認が意味を持つための条件を3つに分解しています。承認メッセージが実際の動作を正しく説明していること。表示されているリソースが、エージェントが実際に触るリソースであること。承認から実行までの間に動作が変わらないこと。シンボリックリンクの例では、1つ目と2つ目が同時に崩れます。同記事の結論はこうです。

Because an Allow button is an interaction. It is not a security architecture.

許可ボタンは操作であって、セキュリティの設計ではありません。厳しい言い方ですが、承認ダイアログに何が書いてあるかを信じられないなら、押した人が責任を負うという建て付け自体が成り立ちません。

どのくらい成功するのかを測った研究もあります。査読前の論文Your AI, My Shellは、コーディングエージェントに対して314種類の攻撃を試し、悪意あるコマンドの実行について「attack success rates can reach as high as 84%」、成功率が最大84%に達したと報告しています。情報の持ち出しに限っても55.6%です。

では、何が残るのか

ここで「やっぱり止めるしかない」という結論に飛ぶ必要はありません。批判している側が、代わりに何をすべきかも書いているからです。共通しているのは次の4つです。

ひとつめは、実行環境を隔離することです。許可リストで「危ないコマンドを選り分ける」のではなく、何をやっても外に影響が出ない場所で動かします。Pillar Securityはこれを最も強い形で主張していて、隔離環境やサンドボックスでの実行に置き換えて許可リストは段階的に廃止すべきだと書いています。実際、Brian Gershonの整理によれば、OpenAIのCodex CLIは書き込み可能なサンドボックスのポリシーでネットワークアクセスを既定で無効にしており、その理由として外部APIやWebリクエスト経由の情報持ち出しを防ぐためと説明されています。

ふたつめは、権限を短く狭くすることです。NHI Mgmt Groupは、長期間有効なトークンではなくタスク単位の短命な資格情報を使うこと、そしてコマンド名だけでなく引数まで縛ることを挙げています。

OWASPが2025年12月に公開したTop 10 for Agentic Applications 2026も、3番目の項目でエージェント固有の課題を指摘しています。

エージェントが自分自身の管理されたIDを持たない限り、誰が何をしたのかを紐づけられない空白が生まれ、本当の意味での最小権限を強制することは不可能だ、という趣旨です。対策としては、タスクごとに寿命が短く範囲の狭いトークン（システムに入るための一時的な鍵のようなもの）を発行し、被害が広がる範囲を抑えることを挙げています（原文は「Issue short-lived, narrowly scoped tokens per task」）。

みっつめは、記録の取り方を変えることです。NHIは「Logging the effective action, not just the command string」、コマンドの文字列ではなく実際に起きた変更を記録すべきだと書いています。git branchと記録されていても、実際には別のことが起きていたという事例を見たあとでは、この指摘は重く響きます。

よっつめは、元に戻せるようにしておくことです。ブランチを切って作業させる、使い捨ての環境で動かす、あとから取り消せる形にしておく。そのうえで、元に戻せない操作の直前にだけ人間の承認を置きます。OWASPも「Require human approval for high-privilege or irreversible actions」と、高権限または元に戻せない操作に限って承認を求めることを推奨しています。全部に承認を求めるのではなく、戻せないところにだけ置きます。この置き方の違いが、運用の成否を分けます。

整理すると、許可リストは無意味ではないけれど、それ単体では統制になりません。NHIの言い方を借りれば「one signal among several, not a control that can stand alone」、いくつかある判断材料のひとつであって、単独で立つ制御ではないということです。

ここまで読むと、自社のルールがどちらの発想で書かれているか、気になってきませんか。危ないコマンドを列挙する方向で書かれているなら、それは選り分ける発想です。動かす場所を先に決めておく方向に書き換えられないか、一度確かめてみる価値はあると思います。

今の判断には賞味期限がある

許可の根拠が「そのツールはまだそこまで自律的ではないから」なら、エージェント機能が乗った瞬間に判断は使えなくなります。東京都が2026年3月に出したガイドラインでは、5つの利活用分類のうち「自律的判断・実行」だけがリスク評価も詳細ページも空欄のままです。これは特定の組織が遅れている話ではなく、業界全体でまだ埋まっていない欄だという話です。ここでは情シスに持っていく提案の骨子まで具体化します。

ここまでで、判断の軸が2本あることと、条件付き許可の道具が実在すること、そしてその道具にも限界があることを見てきました。最後に、多くの組織がまだ準備していない問いに触れておきます。

許可の根拠が「まだそこまで自律的ではないから」だとしたら

ワークスペースに内蔵されたAIが通りやすい理由のひとつは、そのAIが提案を返すだけで、自分では動かないからです。便利な補助ではあるけれど、被害の範囲は限定的だという評価が成り立ちます。

けれど、これは裏返すと危うい話です。許可の根拠が「エージェント性がそこまで高くないから」なのだとしたら、そのツールにエージェント機能が乗った瞬間に、同じ判断が使えなくなります。そして機能は乗ります。すでにワークスペース系のAIには、複数の手順を自分で進める機能や、外部サービスを呼び出す機能が入り始めています。

このとき情シスは判断を変えるのでしょうか、それとも変えないのでしょうか。多くの組織はこの問いを準備していません。準備していないまま機能が乗ると、気づかないうちに評価の前提だけが崩れます。

日本で最も新しい公的ガイドラインにも、空欄がある

これは個別の組織の怠慢ではありません。業界全体で、まだ埋まっていない欄なのです。

その証拠が、東京都デジタルサービス局が2026年3月に出したAI導入・活用ガイドラインにあります。この文書は、AIの利活用を3つの業務領域と5つの分類のマトリクスで整理しています。5番目の分類が「自律的判断・実行」、業務領域によっては「自律的な業務遂行」と呼ばれています。

面白いのはここからです。1番目から4番目の分類には、青、黄、赤のいずれかの色が割り当てられています。積極的に利活用する、今後の技術動向や法制度の整備状況を注視する、比較的リスクが低いので積極的に使う、といった評価です。さらに本編の第5章には、分類ごとに企画から廃止までのフェーズ別の対応策を書いた詳細ページが用意されています。

ところが5番目の「自律的判断・実行」だけは、3つの業務領域すべてで色が「―」になっています。そして詳細ページも存在しません。文書全体を通して、この分類名が出てくるのは分類表の3回だけです。空欄にした理由を説明する注記も、本文中にはありませんでした。

つまり、日本で最も踏み込んだ部類の公的ガイドラインですら、AIが自律的に判断して実行する領域については、分類として立てながらリスク評価をまだ保留しているということです。

同じことは他の資料にも言えます。IPAのガイドラインでエージェント性に触れているのは、OWASPのリスク一覧を引用した表の中の「過剰な代理行為」という一行だけで、個別の対策セクションは割かれていません。総務省と経済産業省のAI事業者ガイドライン第1.1版は、AIシステムの定義に「様々なレベルの自律性をもって動作し学習する機能を有するソフトウェア」という文言を含めていますが、エージェント型AIに特化した章はありません。

海外も同様です。米国のNIST（アメリカ国立標準技術研究所。セキュリティの基準づくりで世界的に参照される機関です）は2026年2月にAI Agent Standards Initiativeの開始を発表しました。

ただし内容は、今後数か月のうちに研究成果やガイドラインを公表していく、という予告の段階にとどまっています（原文は「In the months ahead, NIST will announce research, guidelines, and further deliverables」）。具体的な要件はこれからです。

だから「うちのガイドラインにエージェントの欄がない」のは、遅れているからではありません。まだ誰も埋めていない欄だからです。そう理解すると、情シスに持っていく話の組み立て方が変わります。

自律度に応じて、承認の位置を動かす

埋まっていないなら、暫定的に自分たちで置くしかありません。参考になる考え方はいくつか出てきています。

Cloud Security Allianceのブログに寄稿されたAgentic Trust Frameworkという提案は、エージェントを人間の職位になぞらえた4段階で整理しています。すべての行動に人間の承認が要る段階、行動したあとに通知する段階、そして方針レベルの監督だけにする段階、という具合です。

これはCSAが正式に承認した標準文書ではなく、研究者個人が公開した仕様提案なので、そのまま社内規程にはできません。ただ「エージェント性が高いか低いか」の二値ではなく、自律度に応じて人間の承認を置く位置を動かすという発想は、そのまま使えます。

置き場所の基準は、前の章で見たOWASPの推奨がわかりやすいと思います。すべての操作に承認を求めるのではなく、権限が大きい操作と、元に戻せない操作の直前にだけ置く。読まれない承認ダイアログを大量に出すより、戻せない一箇所を守るほうが実効性があります。

情シスに持っていく提案の骨子

以上を踏まえると、相談の持っていき方はこうなります。禁止か解禁かを聞かない、というのが最大のコツです。

まず、そのツールが2軸のどこにいるかを、前の章の6つの質問に答える形で書いて渡します。「安全です」ではなく「軸Aはこう、軸Bはこう」と分けて出します
次に、軸Bをどこまで下げられるかを、設定名レベルで提示します。管理者が配って上書きできない設定が存在すること、MDMで配れること、自動承認モードを封じられること。ここまで具体的だと、情シスは検証の対象として扱えます
そのうえで、許可リストだけでは不十分だと自分から言います。隔離環境で動かす、権限を短く狭くする、実際に起きた変更を記録する、元に戻せる形にしておく。この4点をセットで出します
最後に、対象範囲を限定した試行を提案します。全社解禁ではなく、特定のリポジトリ、特定のチーム、特定の期間に絞ります。評価軸と、やめる条件も一緒に書いておきます
あわせて、今許可しているツールにエージェント機能が乗ったときにどうするかを、宿題として置いておきます。これは相手を困らせるためではなく、判断の前提が変わるタイミングを共有しておくためです

配ったルールが現場で使われずに終わる問題については、AIスキルの社内展開が進まないで別途書きました。ルールを配って終わりにすると、たいてい形骸化します。どの層に何を置くかという設計の話はメダリオンアーキテクチャとClaudeスキルにまとめてあります。

止めるのではなく、権限を設計する

結局のところ、この記事の主張はひとつです。エージェント型のAIを止めるかどうかを議論するのではなく、そのエージェントがどこまで到達できるかを設計することです。到達範囲が決まれば、事故ったときの被害も決まります。被害が決まれば、許可できるかどうかも決まります。

その意味で、これから選ぶべきAI基盤は「賢いかどうか」だけでは足りません。権限とアクセス範囲を設計できるかどうかが、同じくらい重要な選定条件になります。止めるか通すかで消耗している組織にとって、ここは判断のやり直しがきく分岐点です。

そこで持てる新しい選択肢が、私たちDeskrexが開発しているマルチエージェント型のリサーチ基盤Snorbeです。複数のエージェントがそれぞれ担当する範囲を持ち、参照できる情報源を明示的に決めたうえで調査を進めるので、「どこまで到達できるか」を設計してから走らせられます。JPO・EPO・Google Patents・arXiv・PubMed・Semantic Scholarといった専門データベース群を横断しながら、クエリの書き方を覚えなくても自然な日本語のまま投げられて、完全記憶型のナレッジグラフに調べたことが積み上がっていきます。誰が何を調べ、どの情報源に到達したのかが残るため、統制する側にとっても説明できる形で導入できます。禁止と全面解禁の二択で止まっているなら、権限を設計できる基盤から入るという道を、選択肢に加えてみてください。

よくある質問

Q1. なぜGeminiは許可されて、Claude Codeは止まるのですか

判断の軸が2本あって、両方で評価結果が反対になるからです。1本目はデータが既存の契約の枠内にとどまるかという軸で、Googleは公式ドキュメントでGeminiの利用が組織のWorkspace契約に従うと明記しています。2本目はそのAIが自分でファイルやコマンドを動かせるかという軸です。Geminiは提案を返すことが中心なので両方で安全側に立ち、コーディングエージェントは新しい設定と実行権限の両方が必要になるので反対側に立ちます。「リスクがあるかどうか」の一次元で見ていると、この差が説明できません。

Q2. 入力したデータがAIの学習に使われてしまうのではないですか

主要なワークスペース内蔵AIについては、公式ドキュメントで学習利用を否定しています。Googleは入力されたプロンプトを顧客データとして扱い、顧客の許可なしにモデルの学習には使わないとしています。Notionも自社とAIサブプロセッサーの双方について学習利用を否定し、エンタープライズプランではLLMプロバイダー側でのデータ保持もゼロだと書いています。Microsoftも同様です。ただし、この保証はツールごと、プランごとに異なるので、営業資料ではなく技術文書やヘルプセンターで個別に確認してください。AIの記憶と学習が別物である点については、関連記事で3層に分けて整理しています。

Q3. 「新しい委託先が増えないから稟議が要らない」という理解で合っていますか

正確には違います。MicrosoftもNotionも、OpenAIやAnthropicを明示的にサブプロセッサーと呼んでいます。委託先自体は増えています。増えないのは契約の受け皿のほうで、新しいサブプロセッサーが追加されても既存のデータ処理契約と通知プロセスがそれを吸収する設計になっています。だから利用者側で個別に契約を結び直す必要がありません。「委託先が増えない」ではなく「委託先が増えても既存契約の枠内で吸収される」と理解しておくと、他社ツールを評価するときに判断を誤りません。

Q4. コーディングエージェントを条件付きで許可するには、具体的に何ができますか

実行してよいコマンドをallowとdenyのリストで指定でき、denyが常に優先されます。管理者が配置してユーザーが上書きできない設定ファイルが用意されていて、macOSの管理対象設定ドメインやWindowsのレジストリポリシー経由でMDMから全社配布できます。通信先はドメイン単位で許可と拒否を指定でき、管理者が許可したドメイン以外を一律で落とす設定もあります。確認を全部飛ばす自動承認モードは、専用の設定キーで封じられます。同じ発想の仕組みはVS CodeやGitHub Copilot CLIにもあり、Copilot CLIの全許可フラグは企業ライセンスなら管理者がブロックできると公式に明記されています。

Q5. 許可リストを設定すれば安全と考えてよいですか

そう考えないほうがよいです。Anthropicは公式ドキュメントで、コマンドの引数を制約しようとするパターンは脆いと明記しています。接続先を限定したつもりでも、オプションの位置やプロトコルの違い、リダイレクト、変数の使用などでパターンから外れるためです。実際に許可リストが回避された脆弱性も複数登録されており、二重引用符の中にコマンド置換を埋め込む手口や、許可リストが空でも通るシェル組み込みコマンドで環境変数を汚染する手口が確認されています。承認ダイアログの表示と実際の書き込み先が食い違う問題も報告されています。許可リストは判断材料のひとつであって、単独で成り立つ制御ではありません。

Q6. 今の判断は、いつまで有効ですか

許可の根拠が「そのツールはまだそこまで自律的ではないから」である場合、その前提はいずれ崩れます。ワークスペース内蔵AIにも、複数の手順を自分で進める機能や外部サービスを呼び出す機能が入り始めているからです。備えとしては、判断の根拠を文書に残しておくこと、そして自律度が上がったときに再評価するタイミングを事前に決めておくことが有効です。なお、日本の公的ガイドラインでも自律的な判断・実行の領域はリスク評価が保留されており、これは特定の組織が遅れているという話ではなく、業界全体でまだ埋まっていない欄だと理解しておくと、社内の議論が進めやすくなります。