生成AIの情報漏洩対策を「社内ルール」でやるのをやめた — スタッフ専用AIで引いた3本の線

社内で生成AIを使うことになったとき、最初に作ろうとするのは、たいていルールだと思います。機密情報は入力しない。個人情報は貼らない。入力した内容が学習に使われる可能性がある以上、第三者に見られて困るものは書かない。出力をそのまま社外に出さない。セキュリティの説明資料に、こうした箇条書きが並びます。

私たちも同じことをやろうとして、途中でやめました。

理由は単純で、そのルールが守られたかどうかを、あとから誰も確認できないからです。「入力しないでください」と書いた紙は、入力された瞬間には何もしてくれません。担当者が悪意なく、急いでいて、判断に迷って、一度貼ってしまえばそれで終わりです。

この記事は、その反省から出発して、当社がスタッフ1人の手元PCに専用のAIを1台置いたときの設計の記録です。全社導入の話ではありません。担当者1人に1台から始めて、何を渡し、何を渡さなかったか。生成AIの情報漏洩対策を「お願い」ではなく「構造」で作るとどうなるか、という話です。

うまくいった話だけでなく、遠隔操作が別のアプリに着弾しかけた日と、「開通しました」と報告したものが実は一度も動いていなかった日についても書きます。

「賢いAI」ではなく「安全な作業場」を渡す

最初に決めるのは、できることではなく「できないこと」

スタッフに渡すものを考えるとき、私たちは最初「何ができると便利か」から入りました。これが遠回りでした。

考える順番を逆にして、できることを増やす前に、できないことを技術的に不可能にするところから固め直しました。渡すのは万能のAIではなく、その人の仕事の範囲だけに閉じた作業場である、という位置づけです。

具体的には、設置時に必ず4点セットを作ることにしました。

1. 作業場フォルダ — 入力・出力・参考資料・記憶・作業ログを分けて置く場所
2. AGENTS.md — 人格、仕事の流れ、してよいこと、してはいけないことを書いた1枚
3. 専用のアカウント権限 — その業務に必要な最小限だけ。スタッフごとに別ユーザーにする
4. 読み取り専用のデータ接続 — 判断に必要な社内データは見せる。書き込むツールは入れない

3番目をスタッフごとに別ユーザーにしているのは、万一その認証情報が外に出たときに、その人の分だけを止められるようにするためです。全員で1つのアカウントを共有していると、事故のたびに全社が止まります。アカウント管理の手間は増えますが、増えるのは平常時の手間だけで、減るのは事故時の被害範囲です。

権限の中身も具体で決めました。当社のケースでは、社内データの読み取りは全域で許可、書き込みは指定した1つのフォルダの下だけ、削除は不可です。削除できないのではなく、削除という操作がそのアカウントには存在しない状態にしています。

全社導入ではなく、1人に1台から始めた

いきなり全社に配らなかったのは、慎重さというより、1台目を実験台にして設計を固めたかったからです。

担当者をTさんとします。Tさんの手元PCに作業場を置き、デスクトップにダブルクリック1回で開くランチャーを配置しました。黒い画面のコマンドラインは渡していません。渡したのは、普段使いのエディタの画面と、日本語で頼めるチャット欄だけです。

使い方として伝えたのは3行です。

1. デスクトップのアイコンをダブルクリック
2. 普通の日本語で頼む
3. 帰る前に「今日はここまで」と言う

3行目が地味に効きます。この合言葉がないと、その日の記録も学びも残りません。

3層で縛る — 社内ルールだけの対策が破れる理由

設計を整理したとき、縛り方には3つの層があり、強さがまったく違うことが分かりました。

層	手段	破られ方
第1層	権限・ツール選択・認証の分離	AIには破れない
第2層	行動ルール（AGENTS.mdの文章）	AIが誤読・逸脱しうる
第3層	人間の確認	人が承認を忘れると通る

冒頭で「ルールを作るのをやめた」と書いたのは、多くの生成AIの情報漏洩対策が第2層と第3層だけで組まれているからです。この2つは、うまくいっているときは機能しますが、失敗したことに気づけません。

「書き込まないでね」ではなく、書き込む機能を渡さない

原則はひとつに絞りました。危険な操作ほど第1層で殺す。第2層に頼らない。

たとえば社内のスプレッドシートを見せる必要があったとき、「書き込まないでください」とAGENTS.mdに書くのではなく、書き込み用のツールを最初から接続しないという形にしました。文章で禁止すれば誤読の余地が残りますが、機能が存在しなければ誤読しようがありません。プロンプトに書いた指示は、うまく効いているうちは万能に見えます。 効かなかった日にだけ、それがお願いでしかなかったことが分かります。

アクセスできる範囲も同じ考え方で決めました。「見えてもいいもの」を積み上げるのではなく、その業務で見る必要があるものだけを開けて、残りは最初から見えない状態にしています。

機密データの扱いも同じ考え方です。当社では担当業務の都合上、原価の数字を画面で見られるようにしました。ただし見せる可否とは別問題として、書き込める先を先に塞いでいます。

• 見せる: 画面上の相談にだけ使ってよい
• 塞ぐ: 外部に共有されるファイルに書かない、社外に出る保存先へアップロードするものに含めない

判断の基準は「見せてよいか」ではなく、その情報が社外に出る経路をすべて挙げて、先に閉じたかです。閲覧の可否は、その後で決めれば足ります。

実際に踏んだ失敗3つ

失敗1: 「開通しました」は、動く証拠ではなかった

設定をひとつ変えたあと、起動時の表示に「機能が有効」というメッセージが出たので、開通したと判断して報告しました。

実際には、一度も動いていませんでした。 そのあと実際に処理を走らせてみたら、起動から2秒で落ちていたのです。表示は設定が読み込まれた証拠であって、動く証拠ではありませんでした。

これは生成AIに限らずシステム全般に言えることですが、AIが絡むと成功を示すメッセージを読んで安心してしまう頻度が上がります。以来、設定を変えたら、報告する前に必ず1本通すをルールにしました。

失敗2: 遠隔操作が、別のアプリに着弾しかけた

私たちは本社のPCを手元から確認する仕組みを持っています。動作確認のため、「40秒後に自動で送信」という遅延実行を仕掛けました。

その40秒のあいだに、Tさんが出勤して自分のPCを使い始めました。最前面のウィンドウが変わり、AI宛てのつもりだった入力とEnterが、別のアプリに向かって飛びました。 幸い実害はありませんでした。

原因ははっきりしています。遅延実行を仕掛けた瞬間から、画面の状態を保証できなくなるのに、そこを想像していませんでした。

再発防止として決めたのは次の3つです。

• 遠隔操作の直前に、必ず画面を確認して在席の有無を見る。使っていたら中止
• 遅延実行は仕掛けない
• 業務時間中の検証は、画面を触らない方法（結果をファイルに書き出して回収する）に切り替える

AIの権限設計は社内向けの話ですが、遠隔操作は担当者の作業を直接奪います。 ここは分けて考える必要がありました。

失敗3: 外に出られないことが、そのまま安全装置になった

作業場のAIは、サンドボックスという隔離された環境で動いています。この中からは社外のネットワークに出られません。

最初、これは不便だと思いました。必要なデータを取りに行けないからです。ネットワークを開ける方向で解決しようとして、うまくいかず、結局あきらめました。

代わりに採用したのが、外側が先にデータを集めてファイルで渡すという形です。AIが「これが要る」と1行書くと、外側の仕組みが1分以内にそれを取ってきて所定のフォルダに置く。AI本人は、いつもと同じコマンドを打つだけで、内部で経路が切り替わります。

やってみて分かったのは、これが副作用として最強の情報漏洩対策になっていることでした。

AIが外部に何かを送信することが、技術的に不可能になっているのです。 ルールで禁止しているのではありません。経路が存在しません。同じ考え方で、日報メールの送信機能もAI本人には渡していません。AIはファイルを書くだけで、送信は外側の仕組みが行います。

不便だと思っていた制約が、実は一番強い第1層でした。

縛りすぎたAIは使われない — ゆるめる順番

しばらく運用したあと、「少し縛りすぎではないか」という話になりました。棚卸ししてみると、縛りすぎていたのは権限ではなく判断でした。

現場から上がってきた要望9件を分類したところ、権限が原因で止まっていたものは1件もありませんでした。詰まりの正体は「その機能がまだ無い」「上限の設定値が低い」という能力不足です。第1層は破られない上に、仕事の邪魔もしていませんでした。

一方で、「失敗したら2回まででやめる」といった判断を止めるルールが積み上がっていました。2回で止まると、担当者の手が空いて作業が進みません。

そこで原則を1行にしました。安い失敗は自由にさせ、高い失敗は技術的に不可能にする。

種類	扱い
試行（捨てる前提の作業領域の中）	上限を設けない
納品（成果物として出す）	合格のみ。合否は本人に判定させる（基準は3つ以内）
対外・不可逆（送信・本番反映・削除）	第1層で不可能なまま。ここは絶対にゆるめない

ゆるめてよいのは第2層だけです。第1層は摩擦ではなく保険なので、詰まったときに「一時的に権限を全開にする」という解き方はしません。実際に作業が詰まった日、権限を外せば5分で済むところを、2〜3分待つ迂回路を選びました。

承認ダイアログも「縛り」のうち

もうひとつ、見落としていたことがあります。ルールをゆるめても、毎回の承認ダイアログが古いままだと、体感は何も変わりません。

「試行は無制限」と書いておきながら、1回試すたびに承認ボタンを押させていたら、実質は上限があるのと同じです。道具を足したら、その場で承認の設定も足す。 これをセットにしました。

続くようにする — 記憶とフィードバック

記憶を2つに割る

作業場には、AIが学んだことを書き足していく記憶ファイルを置いています。設置から6日目に中身を読んで、少し困りました。

28行のほぼ全部が、個別の事実だったのです。「この案件ではこうだった」という記録としては品質が高いのですが、他の人に渡せる形になっていません。

決定的だったのが1件あります。ある作業でAIが「全部やり直したら、うまくいっていた部分まで壊れた」という失敗を身をもって踏みました。ところが記憶に残ったのは、その案件固有の失敗だけでした。「作り直すと直っていた所が壊れる。だから部分だけ直す」という一般則に昇格させたのは、こちら側の手作業でした。

原因は、置き場が1つで種類の区別がなかったことです。そこで記憶を2つに割りました。

ファイル	中身	判定
記憶ノート	その案件・その人だけの事実	文に固有名詞が入る
コツ	対象が変わっても通じる法則	固有名詞を消しても意味が通る

判定基準を1行で言える形にしたのがポイントです。「分類の哲学」を書くと守られません。「名前を消しても意味が通るか」だけなら、その場で判断できます。

そして2台目以降に渡せるのは、「コツ」の中身だけです。最初から割っておけば、横展開する材料が自動的に溜まります。混ぜて積むと、渡すときに人力で選り分けることになります。

現場の要望が「言っても無駄」にならないように

もうひとつ手当てしたのが、フィードバックの向きです。

こちらがAIを改良しても、翌朝の担当者は何が変わったか知らないまま作業を始めていました。担当者の視点では「要望を書く → 何も起きない（ように見える）」です。改善要望は、言っても無駄だと思われた瞬間に出てこなくなります。 おまけに、挙動が黙って変わるのは故障にも見えます。

対処として、作業場に「成長記録」というファイルを1つ足しました。改良したら必ず日付と数行を書き、AIがセッションの開始時に未読分を担当者へ報告するという形です。書き方も決めました。**「何が変わったか」ではなく「頼み方がどう変わるか」**で書きます。

×「部分修正の機能を追加しました」 ○「一部分だけ直せるようになりました。全部やり直さなくて大丈夫です」

機能は、存在するだけでは使われません。使い方の一言が毎朝届いて、はじめて使われます。

よくある質問

中小企業でもAIエージェントは導入できますか

当社は全社導入から始めていません。担当者1人・1台から始めて、そこで設計を固めました。全社ルールの整備よりも、1人分の権限設計のほうが先に終わります。

生成AIの社内ルールは何から作ればいいですか

禁止事項の一覧から作ると、守れたかどうかを確認できない対策になります。先に「その情報が社外に出る経路」を書き出して、技術的に閉じられるものから閉じるほうが、結果的に短いルールで済みます。文章で禁止するのは、権限で閉じられなかったものだけです。

スタッフが使いこなせないのではありませんか

コマンドラインは渡していません。デスクトップのアイコンをダブルクリックして、普通の日本語で頼む形にしています。実際の運用で難しかったのは操作ではなく、帰り際に「今日はここまで」と言う習慣のほうでした。

どの業務から渡すのが安全ですか

送信・本番反映・削除の権限を渡さなくても成立する業務からです。当社が次に検討しているのは、返信文の作成（送信は人）と、指示書やCSVの作成（確定操作は人）です。どちらも成果物を作るところまでで止められます。

結局、何を設計していたのか

振り返ると、私たちがやっていたのは「AIに何をさせるか」の設計ではありませんでした。社外に出る経路を先に塞いだうえで、その内側で担当者に自由に動いてもらうための設計です。

生成AIの情報漏洩対策は、突き詰めるとリスクの高い操作を、そもそも存在させないという一点に集約されます。そこさえ固めれば、あとは現場の要望に合わせて、いくらでもゆるめられます。順番を逆にすると、いつまでも怖くて何も渡せません。

経営者の立場から見て意外だったのは、生産性の話と安全の話が対立しなかったことです。業務効率化のために縛りをゆるめる、という場面は一度も来ませんでした。ゆるめる必要があったのは判断を止めるルールのほうで、権限は最後まで課題になっていません。

当社は10以上のモールを運営しながら、社内ツールも業務の自動化もほぼ内製で回しています。同じように、現場の業務にAIをどう組み込むかで迷っている事業者の方に、この設計の考え方がそのまま使えるはずです。

EC運営や物流まわりの業務設計についてはサービスページにまとめています。自社の業務のどこからAIに渡せるか整理したい、という段階のご相談も承っていますので、お問い合わせからお気軽にご連絡ください。