機密をAIエージェントに渡さない｜gitignoreとフォルダ構成

AIエージェントに機密情報を渡してよいかどうかは、読ませる前にpublic・internal・restrictedへ分離し、境界を決めておく必要があります。本記事は、情報を3段階に分離する判定軸と、保管領域をgitignoreとフォルダ構成で物理的に隔てる手順を、自社Vaultの実例で示します。

01この記事でできるようになること：AIエージェントに渡す前に機密情報を分離する境界線

この記事を読むと、AIエージェントに読ませてよい情報とよくない情報の境界を、public・internal・restrictedの3段階で引けるようになります。判定は保管場所の物理的な分離と、gitignoreによるGit除外、出力時のマスキング規約の3層で行います。1つの層が抜けても、残り2層が機密情報の露出を止める設計です。

3段階の分離基準は次のとおりです（WEBMARKSの運用ルールより）。

02AIエージェントへ渡す前の前提：権限と情報の境界をどこに引くか

AIエージェントの既定の読み取り範囲は、作業ディレクトリ配下のほぼ全ファイルに及びます。読み取り権限の絞り方は『Claude Codeの権限設定｜allow・ask・denyの配分と設定例』で扱います。本記事の境界はその手前の判断で、AIが読めるかどうかではなく、読ませてよい場所に機密情報を置くかどうかを保管設計の時点で決めます。

保管設計を後回しにすると、その日追加した一時ファイルの分類が追いつかないまま、AIの読み取り範囲に入ります。分類漏れの下書きにrestricted相当の内容が紛れ込む失敗経路です。WEBMARKSはファイルを作った時点で保管フォルダを先に決め、権限設定は後段の防御として重ねます。

読み取り後に送信・公開・削除を止める仕組みは、境界とは別の話です。詳しくは『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』で扱っています。本記事は、その手前の「そもそも渡すかどうか」だけに絞ります。

03手順1｜機密情報をpublic・internal・restrictedの3段階へ仕分ける

1. 会社の外に出してよい内容かを判定します。顧客名・取引先名・経営数値・認証情報のいずれかを含めば、publicの対象から外します。
2. 残りを社内限定かrestricted相当かに分けます。議事録や社内マニュアルはinternal、決算書・契約書・口調サンプルの生データ・人事情報はrestrictedに置きます。
3. 判定結果どおりの物理フォルダへ置きます。設計の考え方が伝わるよう仮名化した一般例は次のとおりです。

vault/                          ← リポジトリルート（Gitリポジトリ）
├ 01-public/                    ← 公開情報（public寄り。internal箇所はfrontmatterで明示）
│  └ company-facts/
├ 02-internal/                  ← 社内向け文書・業務定義（internal）
├ 03-resources/                 ← 制作物・成果物（internal〜public混在、案件ごとに判定）
├ 99-secret/                    ← restricted。.gitignoreでGit追跡から完全除外
└ .gitignore

internalの中には、公開してよい文書も混ざります。判定は場所だけで決め切らず、frontmatterのconfidentiality: internalを個別ファイルにも付けます。restrictedだけは場所そのものが境界線です。

04手順2｜.gitignoreで機密情報をGit履歴から物理的に締め出す

restrictedと判定した情報は、.gitignoreへパターンを書いてGitの追跡対象から外します。Git公式ドキュメントは、.gitignoreが未追跡のファイルにのみ効くと明記しています（出典: Git公式ドキュメント）。既に一度コミットしたファイルは、.gitignoreへ追加しただけでは履歴から消えません。

自社の.gitignoreと同じ考え方を一般化した例は次のとおりです（フォルダ名は仮名化しています）。

# --- 秘匿（restricted）: リポジトリ追跡から完全除外 ---
99-secret/

# --- 環境変数・秘密鍵（念のため）---
.env
.env.*
!.env.example

# 部署・案件単位のrestricted区分（レビュー待ちの機密ドラフトなど）
**/restricted-review-needed/
**/restricted/

末尾に/を書くとディレクトリのみに一致し、同名のファイルには一致しません（出典: Git公式ドキュメント）。99-secret/はディレクトリ指定なので、配下に何を置いても再帰的に除外されます。

既に追跡済みのファイルを止めるには、git rm --cached <ファイル>でインデックスから外してから.gitignoreへ追加します（出典: GitHub公式ドキュメント）。

gitignoreには3段階の適用範囲があります（出典: GitHub公式ドキュメント）。

リポジトリ直下の.gitignoreは共有前提のパターンを書きます。マシン単位・個人リポジトリ単位は、共有したくない個人的な除外に使います。

アプリの仕様で機密パスを固定パスに置かざるを得ない場合は、実体をrestrictedへ移し、通常パスからシンボリックリンクを張る方法があります。一部のプラグインや拡張機能は、OAuthトークンやAPIキーを設定ファイルへそのまま保存する仕様のものがあります。該当する設定ファイルを.gitignoreに個別登録し、「認証情報を保持し得る」とコメントで残しておくと、あとから見た人が誤って追跡対象へ戻すのを防げます。自社でもこの前提でコメントを残していますが、2026-07-29時点で該当パスにファイル自体が生成されておらず、シンボリックリンクも未設置です。

05機密情報の分離でつまずきやすい3つの落とし穴

1. .gitignoreに追加すれば安全だと思い込む：GitHub公式ドキュメントは、認証情報が漏れた場合の優先順位を明記しています。履歴から消す作業より前に、その認証情報自体を無効化・再発行すべきだとしています（出典: GitHub公式ドキュメント）。除去より前に、鍵とパスワードを止めます。
2. 親ディレクトリを除外した状態で!パターンを使う：Git公式ドキュメントは、親ディレクトリが除外されている場合、その配下のファイルを!で個別に復活させることはできないと明記しています（出典: Git公式ドキュメント）。99-secret/配下の一部だけ例外的に追跡したい場合、この制限にぶつかります。
3. internal領域を読ませたところで安心し、出力時のマスキングを省略する：internalはAIの読み取り自体を許可した領域です。社外向けの文面に流用するときは、個人名や社内限定の数値を伏せる作業が別途要ります。保管場所の分離と出力時のマスキングは、別工程として両方とも要ります。

06機密情報はAIエージェントに渡す前に消えているか、どう確認するか

設計だけでは、実際に除外されたかは分かりません。次の3つで確認します。

# 1. restrictedフォルダがGitの追跡対象から外れているかを確認する
git status --ignored | grep 99-secret

# 2. 追跡済みファイルの中にrestricted配下が紛れていないかを確認する
git ls-files | grep -c 99-secret   # 0以外が出たら要修正

# 3. 直近のコミット差分に機密パターンが混ざっていないかを確認する
git diff --cached --name-only | grep -E "\.env$|restricted"

1. git status --ignoredの結果を確認する：99-secret配下のパスが表示されれば、ignoredとして正しく認識されています。
2. git ls-filesの件数を確認する：結果が0であれば、追跡ファイルへの混入はありません。
3. git diff --cachedの該当行を確認する：該当行が出た場合は、コミット前にステージングから外します。

gitとは別に、出力時のマスキングも確認します。生成した文面から個人名・取引先名・売上や単価の数値を検索し、1件でも残っていれば公開前に差し戻します。Anthropicも、リスクの高い用途では隔離環境での十分なテストと防護策の併用を挙げています（出典: Anthropic公式）。ここでの防護策は、gitによる物理隔離と出力マスキングの両方を指します。

07FAQ