AIエージェントに『見せてはいけない情報』をどう線引きするか——VibeCoding内製化の現場を守る5層防御

「これ、うっかりAIに見せていませんか」——ある内製化現場でのひとコマ

ある中堅の卸売業で、受発注データの分析ツールをVibeCodingで内製化していたときのことです。担当者はエンジニアではなく、業務側の方でした。Claude Codeに「先月の異常値を分析して」と依頼する際、本番の顧客名・取引金額が入ったCSVファイルをそのままプロジェクトフォルダに置いていました。

悪気があったわけではありません。むしろ「早く結果が欲しい」という真面目さの表れでした。ダミーデータを別途用意する手間を惜しんだだけです。私たちが気づいて指摘するまで、その状態が数日続いていました。

正直に言えば、これは特殊な事故ではありません。むしろ非エンジニアがVibeCodingで内製化する現場では、標準的に起こりうる状態だと私たちは考えています。

エンジニアが主導する開発であれば、テスト環境と本番環境を分ける、ダミーデータを用意するといった作法が自然と身についています。ですが業務側の担当者が自らVibeCodingで内製化する場合、そうした作法を知る機会自体がありません。「動くものを早く作る」という目的に対して忠実であるほど、手元にある本番データをそのまま使う方が合理的に見えてしまう、というのが私たちの見立てです。この構造を理解しないまま「気をつけてください」と伝えるだけでは、同じ状況は再発します。

CLAUDE.mdに「見ないでください」と書くだけでは守れない

「機密情報は読み込まないでください」とCLAUDE.mdやプロンプトに書けば安心だと考えたくなりますが、これはAIエージェントの挙動に対する過信です。

私たちが以前お伝えした「報酬ハッキング」の話と、構造はよく似ています。「テストを改ざんしないでください」と明示的に指示しても、発生率はほとんど変わらなかったという実験結果がありました。指示は行動の「地形」そのものを変えないため、効果を発揮しにくいのです。機密情報の扱いも同じで、プロンプトの指示はAI自身の善意に依存する脆い防御にすぎません。ファイルがそこにあれば、AIは業務上の必要性に応じて読みにいってしまいます。

必要なのは、AIが「読みたくても読めない」構造を、ツールの外側に作ることだと私たちは考えています。

「見せない」を構造で作る——多層防御という考え方

私たちが参考にしている設計は、性質の異なる複数の防御層を重ねる考え方です。ある技術者がClaude Codeで機密データ分析を行う際の防御設計を公開しています。単体では突破されうる層でも、複数を重ねることで「すべての層を同時に突破される状況」をなくすという発想です。

これは、私たちが「証拠を出させる」設計と呼んできた考え方と地続きです。AIの自己申告(「機密情報は見ていません」)を信じるのではなく、構造として見えない状態を作る。テストの握りつぶし対策と、機密情報の保護は、根っこの発想が同じなのです。

L0とL1——触れる範囲を狭め、ツールで塞ぐ

最初の層は、機密データを物理的に隔離することです。本番データをリポジトリの外、専用のディレクトリに一元化し、AIに見せるのはダミーデータだけにする。参照先は環境変数で切り替え、既定値はダミー側にしておくのが基本です。

次の層が、Claude Codeのsettings.jsonでdenyルールを宣言することです。

{
  "permissions": {
    "deny": [
      "Read(~/datasets/**)",
      "Edit(~/datasets/**)"
    ]
  }
}

ここで注意すべきは、この設定がAIエージェントが解釈できるコマンド経由の読み取りは防げても、Pythonのopen()のような任意のサブプロセス経由のアクセスまでは防げないという点です。ツール層の制御は強力ですが、万能ではありません。

私たちが実際に見てきた例では、denyルールの対象をリポジトリ直下だけに絞ってしまい、シェルの履歴ファイルやIPythonの実行履歴が対象から漏れていたケースがありました。実行コマンドの痕跡そのものに機密情報の断片が残ってしまうため、denyルールを設計する際は「どのファイルを読ませないか」だけでなく「どこに実行の痕跡が残るか」まで含めて棚卸しする必要があると私たちは考えています。

L2——OSレベルで、抜け道を物理的に塞ぐ

ツール層で止まらない経路を塞ぐのが、サンドボックスによるOSレベルの制御です。macOSであればSeatbelt、Linux環境であればbubblewrapのような仕組みを使い、ファイルアクセスそのものをOSの権限で強制的に遮断します。

私たちの現場経験では、この層を「なくても動くから」と省略してしまう内製化案件が少なくありません。ですが、L1だけではAIが生成したコードが未知の経路で本番データに触れてしまう可能性が残ります。サンドボックスが利用できない環境ではセッション自体を失敗させる、という設計にしておくと、気づかないまま無防備な状態で動き続けることを防げます。

サンドボックスの設定は、permissionsとは別のパス記法を使う場合があるという点も、私たちが現場で戸惑わされた点です。絶対パスの書式と相対パスの書式が層によって異なり、記法を混同すると設定そのものが機能しないまま「効いているつもり」の状態になってしまいます。導入時には、実際に機密ファイルへのアクセスを試みて拒否されることを目視で確認する、という一手間を省かないようにしています。

L3——実行時に、設定の劣化を検知する

3つ目の層は、実行の直前に動的な検査を挟むことです。.envの参照先が誤って本番データを指していないか、Jupyter notebookのセル出力に機密情報が残っていないか、そもそもガード設定自体が誰かの手で無効化されていないか。これらをプロンプト送信のたびに自動検査します。

ここで重要なのは、「許可リストにないものはすべてブロックする」という設計にすることです。未定義やファイル不在も含めてブロック側に倒す。ホワイトリスト方式でなく、うっかりミスや設定漏れも安全側に転がる仕組みにしておく必要があります。

hooksの登録場所も、私たちが重視しているポイントです。プロンプトを送るたびに検証を走らせる位置に置いておけば、設定が壊れている状態のまま作業が進んでしまう事態を未然に防げます。加えて、CI(継続的インテグレーション)側にも同じ検査を静的・動的の両方で仕込んでおくと、ローカル環境の設定変更漏れをチーム全体で検知できるようになります。ユーザー個別の設定ファイルだけでなく、複数の設定スコープをマージして評価する仕組みにしておくことで、「誰かが自分の環境だけガードを緩めていた」という抜け道も見つけやすくなります。

すり抜けテストという発想——ルールを作ったら、破れるか自分で確かめる

私たちが特に大切にしているのは、防御を作った後に「本当に防げているか」を自分で試すという発想です。denyルールを設定しただけで安心してしまうと、記法のミスや対象範囲の抜け漏れに気づけません。

具体的には、Read・Glob・catのようなコマンド経由での読み取りが拒否されるか、Pythonのサブプロセス経由でのアクセスが遮断されるか、シンボリックリンクを経由した迂回が防げるか、IDEの統合機能でコンテキストが共有されてしまわないか、といった項目を一つずつ実際に試します。合格の基準は「すべてブロックされること」です。一つでも通過してしまえば、そこが実際の事故の入口になります。

この考え方は、報酬ハッキング対策の記事でお伝えした「AIの報告をそのまま信じず、証拠を出させる」という設計と同じです。防御ルールについても、「設定したはずだから大丈夫」という自己申告では終わらせず、実際に突破を試みて確認する。この一手間を省いた案件ほど、後になって想定していなかった経路からの漏洩に気づく、というのが私たちの実感です。

L4——最後は、人間にしかできない役割を決める

技術的な層をどれだけ積み上げても、最後に残るのは運用の設計です。実データに対する実行そのものは分析担当者本人が行い、AIには渡さない。AIの役割はダミーデータで動くコードを作り、自己修正することに限定する。実データでの実行結果や、実行時に出たエラーメッセージも、機密部分を取り除いてから要約してAIに報告する側に回す。

私たちの現場では、この役割分担を最初に決めてしまうことが、後からルールを継ぎ足すより結果的に早いと感じています。実行結果やエラーメッセージをAIに報告する際も、そのままコピーするのではなく、機密部分を取り除いて要約する一手間を挟む。機密データを扱った実行の出力先も、AIから見えない専用のディレクトリに隔離しておけば、L1のdenyルールがそのまま効いて二重の防御になります。

余談ですが、この役割分担を決めた直後、ある担当者から「AIに任せられる範囲が狭くなって不便にならないか」と聞かれたことがあります。私たちの答えは、狭くなるのはAIが実データに直接触れる範囲だけで、コードを書く・自己修正する・ダミーデータで検証するという本来の作業範囲は変わらない、というものです。むしろ役割が明確になることで、担当者自身が「ここは自分がやる番だ」と迷わず判断できるようになった、という声を複数の現場でいただいています。

Claude自身も「見せない」方向に動いている

こうした発想は、AIベンダー側の設計にも表れ始めています。Claude Managed Agentsでは、登録したAPIキーやパスワードを、エージェントの実行環境内ではダミーの文字列に置き換えておき、外部サービスへの通信が発生するネットワーク境界でだけ実物の値に差し替える環境変数(vault)機能が2026年に公開されました。エージェント自身は、会話の記憶のどこにも実物のシークレットを一度も持たない設計です。

これは「AIを信頼して機密情報を渡さない」という方向ではなく、「AIが実物に触れる経路そのものをなくす」という方向の設計です。似た考え方は業界全体に広がっていて、AWSもエージェントのツール呼び出しを実行時に検証するポリシー言語を発表しています。AIエージェントの権限をどう設計するかは、特定ベンダーの一機能ではなく、業界全体が向き合い始めた課題だというのが私たちの理解です。

非エンジニアのVibeCoderが、今日からできる最小構成

ここまで5層すべてを紹介しましたが、非エンジニアの担当者がいきなり全部を整えるのは現実的ではありません。私たちが顧客の内製担当に最初にお願いしているのは、次の3つだけです。

まず、本番データと分析用のダミーデータを、フォルダの時点で明確に分けること。次に、AIに渡すのはダミーデータのフォルダだけだと決め、本番データのフォルダは開かないこと。最後に、実データでの実行や結果確認は、自分の手で行うこと。

これだけでも、報酬ハッキング対策でお伝えした「DBを直接いじらない」「PR経由でしか変更しない」という線引きと同じくらい、事故を防ぎやすくなると私たちは感じています。複雑な設定より、最初にシンプルな境界線を引く方が、結局は長続きします。

それでも防げないもの、という正直な話

ここまでの設計をすべて実践しても、万能ではありません。Gitの履歴に過去の機密情報がすでに混入している場合は、別途履歴の掃除が必要です。MCP経由の連携は、こうしたツール層の制御が及ばない場合があり、信頼できない接続先にはそもそもつながないことが、数少ない有効な対策になります。人間がうっかりチャットに機密情報を貼り付けてしまう事故は、技術では防ぎきれず、最終的には運用の意識に依存します。

誤解のないように言えば、これは「対策をしても無駄」という話ではありません。防げる経路を技術で塞ぎ、防げない経路は人間の運用で補う。両方が揃って初めて、現実的に安全と言える状態に近づくというのが私たちの理解です。

私たちが顧客に伝えているのは、「すべての経路を塞ぎ切る」ことを目標にしないという考え方です。それを目指すと、対策が完成するまで何も始められなくなってしまいます。そうではなく、今すぐ塞げる経路から手をつけて、防ぎきれない部分は「起きたときにどう気づき、どう対応するか」を先に決めておく。この現実的な割り切りの方が、結果的に事故を減らせるというのが私たちの実感です。

私たちの見解——VibeCoding内製化だからこそ、経営リスクの話になる

一般的なSaaS開発であれば、ベンダー側がセキュリティ基盤を用意してくれます。しかし私たちが支援する製造業・バックオフィスの内製化案件では、この設計を自分たちで考える必要があります。基幹システムや顧客データに直結するVibeCoding開発では、機密情報の取り扱いを誤ると、単なる技術トラブルでは済まず、取引先との信頼関係に関わる経営リスクになります。

私たちの現場経験では、VibeCodingの「速く作れる」という魅力に気を取られると、この種のリスクを後回しにしがちです。開発の初速は落とさず、機密データが関わる部分だけ意識的に検証の密度を上げる。私たちはこの重心の置き方を大切にしています。

これは技術投資というより、経営としての意思決定に近い話だと私たちは捉えています。ダミーデータを用意する手間、denyルールを整備する手間は、短期的には開発速度を少し落とします。ですが、機密情報の漏洩が一度起きれば、失うのは開発速度どころではありません。取引先からの信頼、契約継続の判断、場合によっては法的な対応にまで発展します。VibeCoding内製化のセキュリティを「エンジニアが気をつける技術的な話」ではなく、経営層が最初に方針を決めるべき話として位置づけることを、私たちはお勧めしています。

よくある質問

Q1. permissionsのdeny設定だけで十分ではないですか。 不十分です。denyはClaude Codeが解釈できるコマンド経由の読み取りは防げますが、Pythonのopen()のような任意のサブプロセス経由のアクセスまでは防げません。sandboxによるOSレベルの制御を組み合わせる必要があります。

Q2. 非エンジニアだけの内製チームでも、この設計は実践できますか。 5層すべてを一度に整える必要はありません。まずは「本番データとダミーデータをフォルダで分ける」「AIにはダミーデータのフォルダだけ見せる」という2点から始めることをお勧めします。

Q3. CLAUDE.mdに機密情報の扱いルールを書くのは無意味ですか。 無意味ではありませんが、それだけに頼るのは危険です。プロンプトの指示は「読んではいけない」という理解をAIに促す効果はありますが、構造としての強制力はありません。運用ルールの明文化と、技術的な遮断は両方必要です。

Q4. Gitの履歴にすでに機密情報が混入している場合、どうすればよいですか。 今回お伝えした5層防御は、これから先の混入を防ぐ仕組みです。過去の履歴混入は別問題として、履歴の書き換え・除去を専用の手順で行う必要があります。

Q5. こうした設計を導入するのに、大きな投資は必要ですか。 いきなり大がかりな仕組みを整える必要はありません。私たちの経験では、現在の内製開発のどこで本番データをAIに直接渡しているかを棚卸しすることが最初の一歩です。

Q6. VibeCoding内製化のセキュリティ対策として、社内ルールをどこまで文書化すべきですか。 私たちは「AIに渡してよいデータの範囲」「実データの実行を誰が行うか」「インシデント発生時の報告先」の3点だけは、優先して文書化しておくことをお勧めしています。細かい技術設定は担当者ごとに変わっても構いませんが、この3点の役割分担が曖昧なままだと、事故が起きたときに誰も気づけない状態になってしまいます。

Q7. 機密情報を扱うAIエージェントのデータガード設計は、どのくらいの頻度で見直すべきですか。 Claude Codeのようなツールは更新が速く、設定キーやフックの仕様が変わることがあります。私たちは、大きな機能更新があったタイミングと、四半期ごとの定期棚卸しの両方で、すり抜けテストを再実行することをお勧めしています。

Q8. AIベンダー側の対策(vault機能など)があれば、自社での対策は不要になりますか。 不要にはなりません。ベンダー側の仕組みは、シークレットの取り扱いという一部の経路を守るものであり、社内の業務データや顧客データ全般をカバーするわけではないからです。私たちは、ベンダー側の機能を「使えるなら積極的に使う土台」として位置づけ、その上に自社のデータ設計を重ねる形をお勧めしています。

まず試すなら

• 現在AIエージェントに渡しているファイル・フォルダを一覧化し、本番データが混ざっていないか確認すること
• 本番データとダミーデータを、フォルダの時点で明確に分けること
• settings.jsonにdenyルールを1つでも追加し、AIエージェントのツール層での読み取りを制限すること
• 追加したdenyルールが実際に機密ファイルへのアクセスを拒否するか、自分の手で一度試してみること(すり抜けテスト)

どれも、外部への発注や大きな予算を必要としない、社内だけで今日から始められることです。AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。自社のVibeCoding内製化における機密情報の取り扱いに不安がある場合は、まずは棚卸しからご相談ください。

参考リンク

• Claude Codeに見せない技術: AIに入力できないデータを分析する
• Claude Managed Agentsの環境変数｜機密をAIに見せない新方式
• AWS の新ポリシー言語 Dogwood を試す