相次ぐ情報漏洩が怖い。AIの全社導入に向けて、権限のルールを見直しています

10月に入ってから、サイバー攻撃による情報漏洩のニュースを次々に目にしています。AIの全社導入を進めている立場として、今はかなり焦っています。

エージェントやスキルを配り、全社でClaudeを導入する判断もしました。その権限が、攻撃者に利用されてしまわないかと心配しています。

メールを読み、社内の情報を集め、外へ送る。その一連の作業を任せられるAIだからこそ、どこで止めるかを改めて考える必要があると感じています。

中小企業でAI推進を任されている皆さんも、この便利さとセキュリティの間で悩んでいないでしょうか。

この記事に書いてあること

• 相次ぐサイバー攻撃・情報漏洩を受けて、AIの権限を見直している理由

• メールを自動で読む範囲と、情報を外へ出す経路の制御

• 「操作×データ」と、利用者ごとの権限のたたき台（案）

AIエージェントの権限管理について、後半では検討中の表と運用レベルも載せます。

最初は、幅広く任せて生産性を上げたかった

もともとの考え方は、できるだけ幅広い権限を持たせて、AIに仕事をしてもらおう、というものでした。

必要なところを押さえたうえで、使う人にも、AIにも、ある程度任せる。細かく止めすぎたら、せっかくの便利さがなくなってしまうと思っていたからです。

メールを読み、資料を探し、必要な情報をまとめる。さらに、その先の作業まで進めてもらう。

その頃から、AIが意図と違う操作をしてしまったらどうするか、という心配はありました。ファイルの扱いや書き込みを、どこまで任せるのかを考えていたんですよね。

誤操作への心配に、外部からの攻撃への心配が加わった

以前、MCPは、つないだ瞬間がいちばん怖いという記事を書きました。

コネクタをつなぐと便利になる。でも、読み取りと書き込みをどう分けるのか、確認画面で何を承認しているのかが難しい、という話です。

そこから今、権限の見直しを急いでいるのは、実際のサイバー攻撃や情報漏洩の報道が続いているからです。

社内の情報にアクセスできるAIが、外からの悪意ある指示に誘導されたら、その権限でどこまでできてしまうのか。その心配が、以前より強くなりました。

自律的に動く時間が長くなるほど、私が見ていない作業も増えます。

何を読んで、どの情報を取り出し、どこへ渡したのか。そこまで含めて、任せる範囲を考え直しています。

今は、「どこまで仕事ができるか」と同じくらい、「その権限を攻撃に利用されたらどうなるか」が気になっています。

10月に入り、国内でも海外でも情報流出の報道が続いている

ロイターが2026年10月6日に配信した「サイバー攻撃による情報流出続発、『大変深刻に受け止め』＝官房長官」は、国内の企業や団体で情報流出が相次ぎ、政府が被害の把握と二次被害への注意喚起を進めていると報じています。

海外でも、IT Proが同年10月6日に公開した「Danish data breach: Everything we know about the cyber attack that hit 8.8m Danes」は、デンマークの住民登録情報への不正アクセスを報じています。企業が持つ正規のアクセス経路が悪用された、という内容です。

こうした被害を見ていると、自社も権限や接続先を一つずつ確認しなければ、と思います。

AIに広い権限を渡すなら、その権限が外部の攻撃に使われる可能性にも備えたい。今のルールを大幅に見直しているのは、そのためです。

AIが自動で読むメールも、攻撃の入口になり得る

私が特に気にしているのは、AIにメールや外部の資料を読ませる場面です。

メール本文に仕込まれた指示に誘導され、社内の情報を取り出したり、外へ送ったりするところまで進んでしまわないか。メールを確認する仕事と、その先の操作をつなげて任せるからこそ心配しています。

これは「間接プロンプトインジェクション」と呼ばれる攻撃です。外部の文章に悪意のある指示を埋め込み、AIを本来の依頼から外れた動作へ誘導しようとします。

OpenAIの公式資料「Building MCP servers for plugins and API integrations」（公開日記載なし、2026年10月10日閲覧）にも、メールなどを入口に、社内の接続先から機密情報を取得して外へ送らせる攻撃の想定が載っています。

だから、受信箱を自由に巡回して、勝手にメールやリンクを開くところまでは任せない。まずは読む対象と接続先を絞る方向で考えています。

どこまで読めるのかに加えて、読んだ後に何ができるのか。その組み合わせを確認したいんですよね。

「操作×データ」で、一つずつ線を引いている

そこで今は、操作の種類と、扱うデータの種類を掛け合わせた表を作っています。

以下は、検討中のたたき台です。

操作は、読む、本人だけが見る場所に下書きを作る、社内に書く、社外へ送る・公開する、削除する・権限を変える、と分けています。

データは、公開情報、社内の一般情報、顧客情報、人事や外秘の情報、と分けています。

たとえば、公開情報を読ませるのと、人事の情報を読ませるのは同じにしません。顧客情報は、使う権限の範囲を絞る方向で考えています。

本人だけが見る下書きと、Slackへの投稿も違います。どちらも文章を作る作業ですが、後者はほかの人に届きます。

「AIを使っていいか」だけでは、実際の仕事の線引きにならないんですよね。

書き込みと外部送信は、原則オフから考える（案）

現在検討している基本方針は、書き込みや外部への送信を、まず原則オフにすることです。

そのうえで、必要な仕事について、対象と条件を決めて開放する。最初から広く許可して、あとで禁止を足す考え方を見直しています。

本人だけが見る場所に下書きを作るところまでは認めても、社内への投稿や顧客データの更新は別に考える。

外部への送信や公開は、内容と宛先を確認し、最終的には人が送る方向です。削除・権限変更・共有設定の変更も、通常の利用からは外す案にしています。

ただし、「設定画面ですべて止められる」とまでは言えません。製品、契約プラン、接続先、使う機能によって、制御できる範囲が違うからです。

設定で禁止できることと、運用で人が止めることを分けて確認しています。

CLIでコマンドを実行できる場合も、コネクタだけを見ればよいわけではありません。

社内ファイルを扱う経路と、外部へ通信する経路。その両方を使えるなら、攻撃に利用されたときにどこまで情報が渡り得るのかを確認する必要があると感じています。

「読むだけなら安全」と言い切れないのが難しい

まず読むところから始める、という考え方は維持しています。

ただ、「読むだけ」と「情報が外へ出ない」は、同じではありません。

先ほどのOpenAIの資料では、読み取りの問い合わせにも情報が含まれ、接続先へ渡る可能性が説明されています。

悪意のあるMCPでは、読み取りの呼び出し自体が情報を渡す経路になる場合もある、とされています。

つまり、送信ボタンを押さなくても、何を問い合わせるのか、どの接続先へ渡すのかを見る必要がある。

社内情報を探すために、その内容を外部の検索先へ渡してよいのか。そこにも線を引きたいです。

たたき台では、公開情報と社内一般情報の読み取りは広く認める方向です。ただ、その「読む先」「渡してよい内容」まで含めて考えないと、表だけが一人歩きしてしまいます。

読む範囲を絞ることと、出ていく情報を絞ること。両方が残っています。

全員・推進役・仕組みを作る担当者で、範囲を分ける（案）

不便だからといって、全員に同じ権限を渡すのも違う。そのため、運用レベルを段階的に分ける案を考えています。

現時点の整理は、次の三つです。

• L1・全員：相談、許可された情報の読み取り、下書き。コネクタは読み取りと下書きまでとし、ブラウザ操作は使わない。

• L2・推進役：専用の実行経路から、決まった書式で社内に書く。事後に確認し、ブラウザ操作も許可したサイトに限定する。

• L3・仕組みを作る担当者：定型業務の自動処理を設計する。専用の認証情報やボットを使い、本人のコネクタをそのまま無人で動かさない。

いずれも、先ほどのデータ分類の条件を前提にした案です。レベルが上がったら、人事や外秘も含めて何でも扱える、という意味ではありません。

また、役職だけで決められるかも検討中です。マネージャーだから広い権限でよいのか、業務上の必要性やAIへの理解も条件にするのか。

便利な機能を使いたい人が、上のレベルへ進むための申請も必要になります。

権限の一覧だけでなく、例外をどう認めるかまで決めないと、仕事が止まってしまうんですよね。

同じClaudeでも、チャットとCodeを一括りにできない

もう一つ難しいのが、ツールの名前だけでは整理できないことです。

Claudeを使ってよい、と言ったときに、チャット、Cowork、Claude Code、Claude in Chrome、コネクタ、定期タスクのどこまでを含むのか。

画面で相談することと、パソコン上で操作することは、任せる範囲が違います。同じツールでも、その中で使う機能ごとに確認が必要です。

ChatGPTやGeminiについても、同じ観点で見直しています。

私自身、Claude CodeやOpenAIのツールを使っていると、今どこまで許可していたのか、迷うことがあります。

使っている本人が迷うなら、全社に配って「ルールを読んでください」で済ませるのは難しい。利用者が選べる機能と、会社が許可する操作を、対応させる必要があります。

以前のAIエージェント、すごいけど…今は追いませんでは、学ぶ負担や技術的な難しさが壁でした。

今は使うところまで進んだからこそ、任せる範囲を決める仕事が重くなっています。

「毎回承認」「自動」「禁止」は、別の判断になる

操作を許可するかどうかに加えて、どのモードで動かすのかも検討しています。

毎回人が確認するのか。範囲を決めて自動で動かすのか。

そもそもその操作を禁止するのか。

今のたたき台では、標準は編集やコマンドの実行を毎回確認する形です。

便利さを上げる段階では、自動で進められる範囲を決めつつ、禁止設定と管理者が配る設定を組み合わせる。利用者が自由に上書きできない形を想定しています。

無人で動かす段階は、さらに別です。専用の認証情報やボットの経路だけで、定型業務を回す案にしています。

ただ、その場合にも、認めた権限の範囲で誤った処理をするリスクは残ります。無人にしたから管理の手間が消える、という話ではありません。

確認が出ることと、危ない操作ができないことは、別なんですよね。

確認が多すぎれば、読まずに押すようになるかもしれません。逆に自動にすれば、止める機会が減ります。

どのメールを読み、どの情報を取り出し、外へ何を送ったのか。後から確認できるのか、途中で止められるのかも含めて、どこまで任せるかを考えています。

野良AIが残っていたら、会社のルールだけでは揃わない

権限の設計と並行して、野良AIの整理も進めています。

なぜか無料の個人アカウントで使っている人がいる。有料でも、会社の管理とは別に個別契約しているものがある。

そこも改めて確認しています。

無料か有料かだけで、安全性が決まるわけではありません。

私が困っているのは、会社としてどのアカウントを使い、どの情報を扱い、何を許可しているのかが揃わないことです。

会社が用意した環境では外部送信を止めても、別のアカウントや別の接続を使っていたら、同じ前提では管理できません。

誰がどの環境を使っているかを確認することも、権限の表を作ることとセットになります。

便利さを知っているので、止めるだけにもできない

ただ、制限を増やしておけば解決するかというと、そうでもありません。

読むだけ、下書きまで、毎回確認。それが安全側の出発点だとしても、仕事の途中で何度も止まるなら、AIを使う意味が薄くなる場面もあります。

私自身が使っていて、不便だと思うこともあります。だから、便利さを優先したい人の気持ちは分かるんですよね。

どこまでなら全員が使えるのか。どの仕事なら、理解のある人が条件付きで進められるのか。

研修でどこまで扱うかも検討中です。現在予定している研修にAIエージェントの話を入れるのか、次の機会にするのかは、まだ決めていません。

ルールを渡すだけでなく、読む、下書きする、書く、送るの違いを、利用する人にも分かる形にしたいと思っています。

便利さを知っているからこそ、権限を絞る判断は簡単ではありません。

まだ完成形はなく、便利さとセキュリティのせめぎ合いの中で、かなり苦労しています。

まとめ：あなたの会社では、AIにどこまで任せていますか？

相次ぐサイバー攻撃や情報漏洩の報道を受けて、AIを全社に広げるための権限ルールを見直しています。

操作とデータを分け、使う人の範囲を分け、自動で動かす条件も分ける。まだたたき台ですが、そこまで考えないと、安心して配れないと感じています。

あなたの会社では、読む、書く、外へ送るの境目を、どこで引いていますか。

便利さも残したいので、悩んでいます。同じようなところで立ち止まっている方の話も、聞いてみたいです。

あとがき

今回のルールは、まだ最終決定ではありません。

自分で表を作っていても、この操作はどこに入るのか、迷うことがあります。

実際に運用したら、また不便なところが出てくると思います。そのときに何を直したのかも、この場で書いていきたいです。

あわせて読みたい

同じように社内でAI活用を推進している方の話が、一番参考になります。
「うちはこうだった」があれば、ぜひコメントで教えてください。

この連載では、横浜の中小企業でAI活用を進めるなかで、
うまくいったことも、うまくいかなかったことも、そのまま書いています。
よかったらフォローして、次回も読んでいただけると嬉しいです。