顧客の開発案件を受けていれば、一度は似た場面に出くわしているはずだ。
「個人PCでの開発はセキュリティ上NGです」。「本番データをそのまま使わないと動作確認できません」。「弊社の開発環境に入ってもらわないと進めようがありません」。
こちらとしては、本番データを一切受け取らず、構造（スキーマや設計ファイル）だけを外に出してもらい、成果物をファイルで納品する方が、データ漏洩のリスクは構造的に低い——と説明する。だが、話が通りにくい。賛同の声もほとんど届いてこない。
「外から内へ」という設計は、技術的には成立している。ISO/IEC 27002:2022のControl 8.33は「合成データを本番データよりも優先して使用すること」を明示しており、日本でも経産省が令和7年改正版の情報セキュリティ管理基準でこれを引用している。個人情報保護法第25条の委託先監督義務も、本番データを外に出さない設計であれば根本から負担が消える。制度的にも技術的にも、筋は通っている。
それでも公の声が上がらない。なぜか。
安心感と安全は、同じではない
セキュリティ研究者のBruce Schneierは2003年の著書『Beyond Fear』の中で、「security theater（保安劇場）」という概念を定義した。「安全を実質的に向上させることなく、より安全と感じさせるセキュリティ対策」のことだ。Schneierは後年のブログでも補足している——「security theaterが完全に無意味だとは言っていない。愚かな攻撃者を追い払う効果はある。だが、形式的な安心感と実質的な安全改善は、別物として理解する必要がある」と。
日本の企業セキュリティによく見られる「持込PC禁止」「入館時に誓約書」「外部委託先に本番データコピーを渡してアクセス管理」という形式は、この視点で見ると興味深い位置に立つ。
本番データへのアクセス経路を構造的に絶つのではなく、「誰がどの端末で触るか」という人・機器の管理で安心感を作っている。委託先に本番データを渡しながら、渡した後の取り扱いを誓約書で縛る。これは「データを外に出さない」設計ではなく、「出した後のリスクを証書で管理する」設計だ。
形式的な安全と実質的な安全の混同——Schneierの言葉を借りれば、これがsecurity theaterの構造に近い。禁止系のルールが全く無意味だと言いたいわけではない。ただ、「見た目で勝つが実質で負ける」と「実質で勝つが見た目で負ける」の二択を迫られたとき、どちらが選ばれやすいかは、もう少し考える必要がある。
なぜ採用を罰する構造になっているのか
「外から内へ」の設計を採用しようとした方針決定者を想像してみてほしい。
もし本番データが漏洩したとき、その決定者は責任を問われる。採用前のやり方と違うことを選んだ判断として、批判の的になる。一方で、設計が機能してデータ漏洩が「起きなかった」場合、その成果は目に見えない。ゼロのままだ。生産性が上がっても、その恩恵は現場エンジニアか事業部門が受け取り、方針決定者のパフォーマンス評価には反映されにくい。
下振れリスクは決定者が個人で負い、上振れの果実は組織に拡散する——こうした誘因の非対称があるとすれば、「前例のないやり方を採用しない」という判断は、個人として合理的だ。構造的に推測できる話として、公の賛成表明が出にくいのはここに原因の一端があると見ている。
加えて、セキュリティ業界そのものの経済構造も関係している。本番データへのアクセス管理・暗号化・通信監視といったソリューションは、「本番データが外に出ることを前提とした上で、どう守るか」というモデルで設計されている。「そもそも本番データを外に出さない」設計が普及すると、このモデルの一部は需要を失う。逆説的だが、「本番データを出さない」方向の需要は急速に膨らんでいる。合成テストデータの市場規模は2024年時点で18億ドル超、2029年には82億ドルへの成長が予測されており（GlobeNewsWire, 2026年1月）、NVIDIAが合成データスタートアップのGretel.aiを2025年3月に買収したことも、その潮目を示している。技術の方向性は変わりつつある。制度的な慣性が、そこへの移行を遅らせている。
多重下請けの構造が、ファイル一個を拒む
日本で特にこの設計が普及しにくい理由が、もう一層ある。
公正取引委員会が2022年6月に発表した「ソフトウェア業の下請取引等に関する実態調査報告書」は、約4,700社の回答と大手・中堅ITベンダー16社へのヒアリングに基づく調査だ。この報告書は、ソフトウェア開発業務において4次下請け・準委任契約（SES）で最大5社が中間に入るケースを確認している。エンドユーザーへの質問が途中の業者で止まる、メール連絡がたらい回しになる——こうした実態が記録されている。
この構造の中で、「個人が構造ファイル1個を直接顧客に納品する」というモデルはどうなるか。中間に入るベンダーにとって、それは自社の存在意義を問い直す話になる。人月で工数を積み上げ、複数社が中間で利益を抜く商習慣は、「一人がファイル1個を直接届ける」モデルとは利益構造として相性が悪い。
啓蒙や説明では動かないのは、ここに理由がある。情報が届いていないのではない。構造が動くことへのインセンティブが、関係する多くのプレイヤーに存在していないのだ。
技術が先行し、制度が追いつかない
一方で、開発の技術環境は別のスピードで変わっている。
元OpenAIのAndrej Karpathyが「vibe coding」という言葉をXに投稿したのは2025年2月のことで、「自然言語で開発の意図を渡し、コードの存在を忘れる」という開発スタイルを描いたその投稿は4,500万回以上閲覧された。彼は同年6月のYCombinator講演でも「自然言語が新しいプログラミングインターフェース」になるというパラダイムを論じた。ソロ開発者のPieter Levelsは月収25万ドル超のポートフォリオを一人で運営し、Sam Altmanは「AIなしでは不可能だった一人で10億ドル企業が生まれる」という予測を2024年に語っている。
技術的な可能性は急速に現実に近づいている。「外から内へ」設計——本番データを受け取らず、構造だけを持ち出し、成果物をファイルで納品する——はそのモデルと親和性が高い。障壁は技術にない。制度的な誘因と慣行の慣性にある。
律速は理解ではなく前例だ
では、どう動くか。
「正しいと思うなら声を上げればいい」という話ではない。構造を前にして個人が声を上げても、現状の誘因構造では個人が批判のリスクを引き受けるだけになる可能性が高い。
有効なのは、小さく実証し、前例を作ることだ。「見た目の安全」チェックも通る形で実装する——別名スキーマで設計し、納品前の出庫スクラブ（本番識別子の除去確認）を記録に残し、完了後の削除証明を添える。ISO 27002:2022 Control 8.33が要求する「別途承認手続き・監査証跡」の仕組みは、まさにこの見た目の安全チェックと重ねて使える。
制度的チェックをクリアした上で、実質的な安全も確保する——その組み合わせの前例が積み上がったとき、慣行は動く。
Schneierの言葉を引き返せば、安心感と安全は同じではない。だが、動き出すためには安心感も必要だ。実質だけを主張して動かないより、見た目のチェックも添えて前例を一つ作る方が、律速は早く解除される。
今週末の1時間：自分が関わっている案件で「本番データを受け取らなくても設計できる部分」を一つ特定してみる。スキーマだけ外に出して構造を組む試作を、個人PC上で動かしてみる。前例は説明から生まれるのではなく、動いた実績から生まれる。
関連記事：顧客環境に拘束された時間は、あなたの資産にならない——「外から内へ」設計の実務戦略版
関連記事：開発環境への本番データ持ち込み、氏名マスク済みで安全と言い切れるか——本番データ識別子設計の技術版
関連記事：AIを使った成果物納品、キーもPIIも渡さない設計——build/bindの実務 how