SNSを眺めていると、ときどきこういう趣旨の投稿が流れてきます。
「AIにコードを書かせるなんて、情報漏洩そのものだ」「機密を外部のAIに送るなんてありえない」。一見、とてももっともな警告です。実際、企業のデータが外に出るのは多くの現場でご法度ですし、その感覚自体は正しい。
でも、見るたびに小さな違和感がありました。この主張、何かいろいろなレイヤーが混同している気がするんです。
僕は独立する前、5年ほどエンタープライズ開発の現場にいました。交通・製造・エネルギー — いわゆる「データを外に出せない」の代表みたいな業界です。その頃の記憶を引っ張り出しながら、この違和感の正体を書いてみます。結論を先に言うと、僕が現場で本当に守っていたのは、コードじゃなかったという話です。
二つの「データ」を分けないと、話が全部つぶれる
まず、ここを分けないと議論が成立しません。AI駆動開発で「外に出したくないデータ」には、実は性質の違う二種類があります。
一つは、開発時のデータです。ソースコード、設計書、スキーマ。これが漏れて困るのは、知的財産や競争優位が毀損するからです。
もう一つは、本番のデータです。顧客の個人情報、稼働ログ、制御系の実データ。これが漏れると、法令違反や事故に直結します。
この二つは、守る理由も、漏れたときの被害も、まったく違います。脅威モデルが別物なんです。
そして、コーディング支援がまず向き合うのは前者 — コードと設計のほうです。「AIに本番データを食わせて分析させる」（いわゆるRAGやデータ分析）は、目的からして別の営みです。
ここを混ぜると、「AI＝全部ご法度」という乱暴な結論になってしまう。まず現場が解くべきなのは、前者のほうなんです。
現場で、僕が本当に守っていたもの
ここで自分の話をします。僕が関わっていたのは、点検記録を扱う業務システムでした。設備を点検して、その記録を残し、次の保守につなげる。そういう類のシステムです。
正直に言うと、そのシステムのコード自体は、秘密でも何でもありませんでした。
業務システムのコードって、そのドメイン専用にガッチリ組まれています。だから外に出ても、他社が再利用して競争優位を崩す、みたいな価値はほとんどないと評価しています。SIの現場で書かれるコードの大半は、いわゆる「秘伝のタレ」ではないんです。汎用的な技術の組み合わせで、その会社の業務に合わせて成形しただけ。もちろん、すべての業務システムがそうであるわけではないので、その点は誤解のないように。
じゃあ何を守っていたのか。点検記録のデータそのものでした。
考えてみてください。点検記録には、「どの設備が」「いつ」「どういう状態で」「いつ保守に入るか」が全部入っています。これは競争情報ではありません。もっと厄介な、重要インフラのセキュリティ情報です。
攻撃者の目線に立つと、これは「どこが弱っていて、いつ人がいなくなるか」の地図になる。だから外に出せない。コードが惜しいんじゃなくて、この地図が命だったんです。
当時の僕は、ここまで言葉にできていませんでした。でも肌感覚としては、守るべきものの中心が「コード」ではなく「記録の中身」だったのは、間違いありません。
「外部送信は一律禁止」という鈍器
ところが、現場のルールはこう書かれていました。「外部への送信を、一律禁止」。
これ、よくよく考えると不思議なんです。本当に守りたいのは点検記録データなのに、規則が縛っているのは「あらゆる外部送信」。コードも、テスト用のダミーデータも、何もかもが同じバケツに放り込まれている。
なぜこうなるかというと、規則は「データの中身」で線を引けないからです。「重要な本番データだけ送信禁止」と書いても、現場でそれを一件ずつ判定するのは無理がある。だから「送信という行為」で一律に引くしかない。運用としては、そうなる。
でも、その結果として、リスクの実体（本番データ）と、規則の対象（あらゆる送信）がズレてしまう。秘密でもないコードが、命綱の点検記録と同じ扱いで縛られる。
これは、リスク管理でいう「鈍器」の典型です。細い針で刺すべきところを、大きなハンマーで面ごと叩いている。コードのAI活用は、この鈍器にたまたま巻き込まれていた側でした。
当時の僕は、このルールに不便さは感じていましたが、一度も疑いませんでした。決められたものとして、ただ従っていた。この話は最後にもう一度戻ってきます。
ただし、いまのAIは本番データベースに手が届く
ここで、正直に一段深く掘ります。さっき僕は「コーディング支援が向き合うのは、まずコードと設計だ」と書きました。この「まず」に、含みを持たせていました。
「コーディング支援が触るのはコードだけ」というのは、ひと昔前なら正しい説明でした。入力補完の時代のAIは、エディタの中のコードファイルを読むだけ。それ以上のことはできなかった。開発時データと本番データの分離は、放っておいても勝手に成り立っていたんです。
でも、いまのエージェント型のツールは違います。ターミナルを叩けます。（MCPのような仕組みで）データベースに接続できます。本番の認証情報が入った設定ファイルを読めるし、その気になれば本番データベースに直接クエリを投げられる。つまり、やろうと思えば、AIは本番データそのものに手が届くんです。
これは、僕のここまでの前提を静かに崩します。「コーディング支援は開発時データしか触らない」は、もう道具の性質ではありません。分離は、設計して初めて成立する規律に変わったんです。
何もしなければ、エージェントは境界を越えられます。だから、読み取り専用の権限しか渡さない。本番ではなく、開発・検証用のダミーデータベースに向ける。接続先やコマンドの範囲を絞る。認証情報を、プロンプトの届く場所に置かない。こうした設計を敷いて、はじめて「前者しか触らない」が本当になります。
面白いのは、これで冒頭のSNSの警告が「半分だけ」当たっていた理由が見えることです。「AIに本番データが渡る」危険は、空想ではありません。実在します。ただ、それはAIにコードを書かせること自体のリスクではなく、エージェントの到達範囲を設計していないことのリスクなんです。危ないのは同じでも、線を引く場所がまるで違う。
じゃあ、どうやって「外に出さず」に使うのか — 三つの隔離レベル
では、データを守りながらAIを開発に使うには、どうすればいいのか。ここで、隔離には二つの軸があることを分けておきます。 モデルをどこで動かすか（送信の軸） と、 エージェントに何を触らせるか（到達の軸） です。さっきの本番データベースの話は後者。ここからは前者 — 送信の軸を、隔離の強さで三段階に分けて見ていきます。
（余談ですが、以前別の記事で書いた三層武装ガイドの「三層」は、モデルの可用性とコストのヘッジの話でした。今回の三段階はデータ隔離の話で、まったくの別物です。混同しないように名前を変えておきます）
レベル1は、契約で縛るやり方です。データは外部のAIに送るけれど、応答を返した後は保持されず、モデルの学習にも使われない。いわゆる ゼロデータ保持（ZDR） と、学習非使用の契約条項です。Claude Codeにも企業向けのゼロデータ保持の枠があります。ただしこれは「送信という行為そのもの」は消えない。金融や制御系では、契約でどれだけ縛っても、外部送信という行為自体が監査で通らないことがあります。
レベル2は、自社のクラウド境界の中でモデルを動かすやり方です。これが今、いちばん現実的な主戦場だと思っています。データをモデルの元へ送るのではなく、モデルを自社が既に信頼しているクラウドの中に持ってくる、という発想の反転です。
たとえばAzureやAmazon Bedrockの上でAIを動かすと、推論は自社が指定したリージョンの中で完結します。専用線接続（VPC・PrivateLink）でインターネットへの経路を塞げば、データは外に出ません。入力も出力もベースモデルの学習には使われない。理屈としては 「AWSやAzureは元々使っていて監査も通している。その境界の中で完結するなら、新しく外部送信が増えるわけではない」 となる。既存のクラウド監査の資産を、そのまま再利用できるのが効いています。
ひとつだけ、地味ですが実務で効く注意点があります。このクラウド経由では、個人向けの定額サブスク（Claude や Codex の月額プラン）は使えません。BedrockやAzure経由は、そのクラウドの従量課金として、使った分だけAWSやAzureの請求に乗ります。一見デメリットに見えますが、エンプラの現場ではむしろ逆です。既存のクラウド契約・請求・調達のレールに、そのまま乗るということだからです。新しい定額契約を情シスや購買に通す手間がいらない。境界の話だけでなく、お金の流れの面でも「新しいものを増やさない」で通せる。これも、レベル2が主戦場になっている理由のひとつです。
レベル3は、完全にオンプレミス、あるいはネットワークから物理的に切り離した環境で、モデルを自前で持つやり方です。外部通信をゼロにする層です。近年はQwen系のように、自前で動かせる公開モデルのコーディング性能がだいぶ上がってきて、この選択肢が現実味を帯びてきました。
トレードオフは、はっきりしています。能力のギャップです。最前線のモデルは基本クラウド側にいて、自前で動かせるモデルはコード生成でもまだ一段落ちる。差は縮んでいますが、消えてはいません。
| 隔離レベル | やり方 | 外部送信 | 主なトレードオフ |
|---|---|---|---|
| 1 | ZDR＋学習非使用の契約 | 送るが保持しない | 送信自体が監査で通らない業界がある |
| 2 | 自社クラウド境界内で動かす | 経路を塞げばゼロ | クラウドを信頼している前提が要る |
| 3 | オンプレ・自前ホスト | 物理的にゼロ | 最前線モデルとの能力ギャップ |
ただし、この三段階はあくまで送信の軸の話です。どれを選んでも、さっきの到達の軸（エージェントに本番を触らせない権限設計）を掛け合わせないと、隔離は完成しません。モデルを社内に置いても、そのモデルが本番データベースに自由に繋げるなら、意味がない。この二つは両輪なんです。
多くの現場が実際に落としどころにしているのは、レベル2です。「AIは一律ご法度」だった時代の答えが、いま静かに書き換わっている最中なんだと思います。
じゃあ、一律禁止は間違いだったのか
と、ここまで書いて、自分にブレーキをかけます。
「だから外部送信の一律禁止は時代遅れの過剰規制だった」 と書きたくなる。でも、それはそれで早とちりです。ここは正直に削っておきます。
思い出すのが、2023年のSamsungのChatGPT禁止です。報道によれば、エンジニアが社内のソースコードを外部のAIに貼り付けてしまう事故が起きて、Samsungは生成AIの社内利用を全面的に禁止しました。データを外部のAIに送ると、その企業のサーバーに保存されて簡単には消せない、というのが理由でした。
この事例、僕の主張を二つの方向から揺さぶってきます。
一つ目。Samsungでは、コードが秘密でした。
半導体メーカーにとって、製造プロセスのコードは競争優位そのものです。つまり「コードは秘密じゃないことが多い」という僕の話は、あくまで業務システムを外注する事業会社に限った話であって、プロダクト自体がコードやアルゴリズムでできている会社には当てはまらない。ここは正直に認めます。守るべきものが何かは、その会社が何で食べているかで変わるんです。
二つ目。そして、この事故は人間が起こしました。
漏れたのは、AIが勝手に何かをしたからではありません。人間が、公開されているAIツールに、自分の手で機密を貼り付けたからです。
ここが効いてきます。仮にコードが秘密でない現場でも、開発者がデバッグ中に、本番の点検記録データをコピペしてプロンプトに貼るという事故は起こりうる。コードは安全でも、人間が境界を越えてしまう。しかも今は、人間が貼らなくても、エージェント自身が本番データベースに繋いで引いてくる経路まである。境界を越える手は、むしろ増えているんです。
そう考えると、あの「外部送信は一律禁止」という鈍器ルールは — 鈍器ではあるけれど — 「人間が事故る余地を、物理的に消す」という意味では、ちゃんと仕事をしていたとも言えるんです。細かく線を引けば引くほど、判断ミスの隙間が生まれる。全部塞いでしまえば、少なくともその隙間はない。
鈍器には、鈍器なりの合理性があった。これは認めないといけない。
見えなかった線は、技術ではなく立ち位置が見せてくれた
それでも、最後にこう言えると思います。
問われているのは「禁止か、許可か」の二択ではありません。データの種類で、線を引き直せるかです。コードと本番データを分け、本番データの中でも「漏れると事故になるもの」を見極め、そこにだけ強い隔離をかける。開発時のAI活用は、レベル2のような形で、リスクを増やさずに通せる余地がある。今はその選択肢が、現実に手の届くところにあります。
そういう意味で、SNS上で発信されている注意喚起そのものは、間違っていません。「AIに機密が渡る危険がある」 — これは事実です。エージェントが本番に手を伸ばせる以上、むしろ鳴らされるべき警鐘だと思います。僕がこの記事で引き直したかったのは、その警戒を否定することではなくて、警戒を向ける先のほうです。危ないのは「AIに開発させること」の全部ではなく、そのうちの「本番データにAIを触れさせてしまう、設計の穴」だ、と。そこさえ分けられれば、警戒はもっと正確に、もっと効くようになります。
ただ、本当に書きたかったのは、そこじゃありません。
独立して、AIを毎日の道具として使うようになって、はじめてあの頃の景色の中に、引けたはずの線が見えるようになりました。面白いのは、それを見せてくれたのが新しい技術そのものではなかったことです。技術は前からありました。見え方を変えたのは、自分の立ち位置でした。従う側から、設計する側へ。バケツの中身を疑っていい側へ。
そして、これを書きながら気づいたのは、この線を引けること自体が、SEという経験の価値なんじゃないか、ということです。
どのデータが命綱で、どのコードはただの成形物か。エージェントを本番のどこに触れさせてはいけないか。その線は、システムがどう組まれ、どう運用され、何が監査で見られるかを、内側から知らないと引けません。それはまさに、現場でシステムを設計し、つくり、守ってきた経験そのものです。
少し前に、プログラミングスクールに通う意味はまだあるのかで、「『書ける』の値段が下がって、『読めて判断できる』の値段が上がる」と書きました。今日の話は、その「判断」を、データ隔離という現場の一点まで下ろしたものでもあります。AIが「書ける」を安くしていくほど、SEの価値は薄まると言われます。でも僕は、逆だと感じています。書く仕事が安くなるほど、「どこに線を引くか」を判断できる経験の値段は、むしろ上がる。AIに安全に開発させられるかどうかは、結局、その線を引ける人がそばにいるかで決まるからです。
「守るべきはコードじゃなかった」と言い切れること。それ自体が、あの5年間の現場が残してくれたものでした。当時は自分にとって透明で、価値だと気づいてすらいなかった経験が、AIの時代になって、いちばん効く場所にせり出してきた。そんな感覚が、いまはあります。
FAQ
「AIにコードを書かせる＝情報漏洩」は間違いなのですか？
一律には言えません。この記事の主張は「開発時データ（コード・設計）と本番データ（顧客情報・稼働記録など）は分けて考えるべきで、コーディング支援が触るのは基本的に前者」というものです。ただしSamsungのように、プロダクト自体がコードやアルゴリズムでできている会社では、コードそのものが競争情報になります。「何を守るか」は、その会社が何で食べているかで変わります。
「開発時データ」と「本番データ」はどう違うのですか？
開発時データはソースコードや設計書で、漏れると知的財産や競争優位が損なわれます。本番データは顧客の個人情報や稼働ログ・制御系の実データで、漏れると法令違反や事故に直結します。守る理由も被害も異なる、別々の脅威です。コーディング支援がまず向き合うのは前者ですが、いまのエージェント型ツールは権限次第で本番データベースにも手が届くため、この分離は”道具の性質”ではなく”設計して守る規律”になっています。
データを外に出さずにAIを開発に使う方法は？
隔離の強さで三段階あります。（1）ZDR＋学習非使用の契約で縛る、（2）AzureやAmazon Bedrockなど自社が信頼するクラウド境界の中でモデルを動かし、専用線で外部経路を塞ぐ、（3）オンプレやネットワーク遮断環境で自前のモデルを持つ。多くの現場の現実解は（2）で、既存のクラウド監査資産を再利用できるのが利点です。（3）は外部送信ゼロと引き換えに、最前線モデルとの能力差を受け入れます。
「外部送信は一律禁止」という規則は過剰なのですか？
鈍器ではありますが、合理性もあります。規則はデータの中身で線を引くのが難しいため、「送信という行為」で一律に縛らざるを得ない。その結果、秘密でないコードまで巻き込まれます。ただしSamsungの事故が示すように、漏洩の多くは人間が公開ツールに自分で機密を貼り付けて起きます。全部塞ぐ規則は「人間が事故る余地を物理的に消す」意味では機能していた、という側面も見ておくべきです。
エージェント型のAIは本番データベースに接続できてしまうのでは？
できます。そこがまさに本文の肝です。いまのエージェント型ツールはターミナルを操作し、データベースに接続し、本番の認証情報を読むこともできる。だから危険なのは「AIにコードを書かせること」ではなく、「エージェントの到達範囲を設計しないこと」です。読み取り専用の権限に絞る、本番ではなく開発・検証用のダミーデータベースに向ける、接続先やコマンドの範囲を制限する、認証情報をプロンプトの届く場所に置かない — こうした設計で到達範囲を絞って、はじめて分離が成立します。
参考ソース
– Zero data retention – Claude Code Docs
– Protect your data using Amazon VPC and AWS PrivateLink – Amazon Bedrock
– Amazon Bedrock FAQs（入出力はベースモデルの学習に使われない）
– Samsung Bans ChatGPT Among Employees After Sensitive Code Leak – Forbes（2023年5月）
この記事が参考になったら
Share