AIエージェントに機密情報を渡さない｜3段階の分離と検査

「このフォルダ、AIに読ませて大丈夫でしょうか」。作業を任せ始めた直後に、この質問が必ず出てきます。

そして多くの場合、答えを権限設定から探しにいきます。ところが読める・読めないを1つずつ決めていっても、話は片づきません。そもそも機密情報がどこに置いてあるのかが決まっていないからです。置き場が決まらないまま権限だけを絞っても、翌日に増えた下書きが同じ場所へ積み上がります。

この記事が扱うのは、その手前の線引きだけです。情報をpublic・internal・restrictedの3段階へ分け、restrictedをフォルダ構成と.gitignoreで物理的に締め出し、出力の直前に伏せ字を通す。この3層を、公式ドキュメントの記載と自社Vaultの実例で組み立てます。

本記事の検証環境：Git公式ドキュメント（2026-07-28時点の記載）／GitHub公式ドキュメント（2026-07-28時点の記載）／自社Vaultの.gitignore実測（2026-07-29確認）。

進行役は3人です。高梨課長が自分の手で設定を書く立場から聞き、大森部長が体制の判断を持ち込み、鈴木さん（本誌監修）が答えます。近い立場の人の質問から読んでいただいて構いません。

01AIエージェントに機密情報を渡さない分離は、どこから手をつけるんですか？

高梨課長

高梨課長の発言

読ませたくないファイルを1つずつ指定していたら、きりがなくて。どこから手をつけるのが早いんでしょう。

鈴木さん

鈴木さんの発言

指定する側ではなく、置く側から手をつけると早いですよ。書類を金庫に入れるか机の上に置くかを、書いた瞬間に決めておく。あとから「これは見ないで」と言い続けるより、ずっと軽く済みます。

結論を先に置きます。渡してよいかどうかは、AIが読めるかどうかではなく、読ませてよい場所に置いてあるかどうかで決めます。判断のタイミングは、ファイルを作った瞬間です。

守りは3層で組みます。第1層が分類、第2層が物理的な隔離、第3層が出力時の伏せ字です。分類を誤ればrestricted相当のものが公開領域に残り、隔離を怠ればGit履歴に機密情報が刻まれ、伏せ字を省けば出来上がった文面に個人名がそのまま出ます。

この3層は、順番に並んだ検問所です。手前で見落としたものを、後ろが拾います。裏を返せば、1層だけで守ろうとした設計は、その1層が破れた瞬間に何も残りません。

02AIエージェントは、既定でどこまでのファイルを読んでいるんですか？

既定の読み取り範囲は、作業ディレクトリ配下のほぼ全ファイルに及びます。名指しで渡したファイルだけを見ているわけではありません。

ここで起きるずれが厄介です。読める範囲は作業ディレクトリの形で決まるのに、渡してよい範囲は情報の中身で決まります。この2つは自動では一致しません。

ずれをいちばん広げるのが、保管設計の後回しです。その日追加した一時ファイルの分類が追いつかないまま、AIの読み取り範囲へ入ります。分類漏れの下書きに、restricted相当の内容が紛れ込む。これが典型的な失敗経路です。

WEBMARKSは、ファイルを作った時点で保管フォルダを先に決めています。権限設定は、そのあとに重ねる後段の防御という位置づけです。読み取り権限の絞り方そのものはClaude Codeの権限設定で扱います。

03機密情報をpublic・internal・restrictedへ分離する判定は、AI活用の現場でどう回すんですか？

高梨課長

高梨課長の発言

3段階と言われても、目の前の議事録がどれに当たるのか、その場で迷いそうです。

鈴木さん

鈴木さんの発言

迷ったら、質問を2つに減らしてみてください。「会社の外に出して困るか」と「Gitの履歴に残って困るか」。この2つだけで、たいていの書類は行き先が決まります。

まず、WEBMARKSが運用している3段階の基準を出します。自社に写すときは、保管先の欄を自社のフォルダ名に置き換えてください。

仕分けの手順は、上から順に落としていく形になります。

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

04分けた3段階は、AIエージェントが読むフォルダ構成にどう落とすんですか？

判定の軸が決まったら、次はそれを目に見える形にします。設計の考え方が伝わるよう、仮名化した一般例を置きます。

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だけは扱いが違います。場所そのものが境界線です。ここに置いた時点でGitの追跡から外れる、という約束にしておくと、個別の判断が要らなくなります。

05.gitignoreでAIエージェントから機密情報を分離するには、何を書けばいいんですか？

restrictedと判定した情報は、.gitignoreへパターンを書いてGitの追跡対象から外します。自社の設定と同じ考え方を一般化した例が、次の形です。

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

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

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

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

この対応を頭に入れておくと、書き方を迷わなくなります。封じたい単位が棚なのか、書類1つなのか。そこが決まれば記号も決まります。

06すでにコミットしてしまった機密情報は、AI社員の運用でどう始末するんですか？

高梨課長

高梨課長の発言

もう入ってしまっていた場合は、何から手をつければいいでしょうか。

鈴木さん

鈴木さんの発言

履歴を消す作業より先に、鍵を止めてください。GitHubの公式ドキュメントも、認証情報が漏れたときはまず無効化と再発行を優先すべきだと書いています。玄関の合鍵が出回ったなら、まず鍵そのものを交換する。落とした合鍵を探し回るのは、そのあとです。

高梨課長

高梨課長の発言

消す作業のほうを先にやりたくなりますが、順番が逆なんですね。

順番を決めておくと、あわてずに済みます。

追跡済みのファイルを止める操作そのものはgit rm --cached <ファイル>です。インデックスから外してから.gitignoreへ追加します（出典: GitHub公式ドキュメント）。この順序を逆にすると、パターンを書いても追跡が続いたままになります。

そして、外したあとも履歴には残ります。ここを「消した」と言い換えないでください。止めたのは鍵であって、記録ではありません。社内へ報告するときも、この2つは分けて書きます。

07gitignoreの3つの適用範囲は、AIエージェントの機密情報の分離のどの場面で使い分けるんですか？

除外の書き場所は、1か所ではありません。適用範囲の違う3つが用意されています（出典: GitHub公式ドキュメント）。

使い分けの軸は「他の人にも同じ判断をさせたいか」です。

restrictedの棚を除外する設定は、チーム全員に同じく効いてほしい内容です。だからリポジトリ直下の.gitignoreに書きます。共有されない場所へ書くと、別のメンバーの環境では追跡されたままになります。

逆に、自分のエディタが吐く一時ファイルは、他の人には関係ありません。ここをリポジトリの.gitignoreへ足していくと、共有すべきルールと個人の都合が混ざって読めなくなります。

08設定ファイルにトークンが残る道具は、AIエージェントの機密情報の分離でどう扱うんですか？

棚を分けても、道具のほうが固定パスを要求してくることがあります。

一部のプラグインや拡張機能は、OAuthトークンやAPIキーを設定ファイルへそのまま保存する仕様です。置き場を選べないため、分類のルールだけでは追いつきません。

対処は2つあります。1つは、実体をrestrictedへ移し、通常パスからシンボリックリンクを張る方法です。道具からは元の場所に見えたまま、中身は秘匿の棚に置けます。

もう1つは、該当する設定ファイルを.gitignoreへ個別に登録し、「認証情報を保持し得る」とコメントで残しておくことです。あとから見た人が、意味を知らずに追跡対象へ戻してしまうのを防げます。

自社でもこの前提でコメントを残していますが、2026-07-29時点で該当パスにファイル自体が生成されておらず、シンボリックリンクも未設置です。備えを書いた状態であって、動かして確かめた状態ではありません。ここは正直に書き分けておきます。

09生成AIへの出力マスキングは、機密情報の分離とどう役割が違うんですか？

大森部長

大森部長の発言

保管の分離まで整えたなら、出力のほうは省略できませんか。工数を二重にかける理由が知りたいです。

鈴木さん

鈴木さんの発言

防いでいる事故が別物なんです。保管の分離はリポジトリや共有先に記録が残るのを止めます。伏せ字は、出来上がった文面が社外の目に触れるのを止めます。片方だけだと、もう片方の経路が素通りになります。

とくに抜けやすいのが、internal領域を読ませたあとです。

internalは、AIの読み取り自体を許可した領域です。だから読ませた時点では何の問題も起きません。ところがその内容を社外向けの文面へ流用するとき、個人名や社内限定の数値を伏せる作業が別途要ります。

restricted配下についても考え方は同じです。読み取り自体は許可される場合がありますが、出力に含めるときは伏せ字を通します。WEBMARKSはAIによる読み取りを許可しつつ、restricted配下への書き込みや、出力へのそのままの転記を別のルールで止めています。

10AIエージェントの機密情報の分離でつまずくのは、どんなときですか？

ここまでの内容を踏まえると、つまずきどころは3つに整理できます。

1つ目は、.gitignoreに追加すれば安全だと思い込むことです。 GitHub公式ドキュメントは、認証情報が漏れた場合の優先順位を明記しています。履歴から消す作業より前に、その認証情報自体を無効化・再発行すべきだとしています（出典: GitHub公式ドキュメント）。除去より前に、鍵とパスワードを止めます。

2つ目は、親ディレクトリを除外した状態で!パターンを使うことです。 Git公式ドキュメントは、親ディレクトリが除外されている場合、その配下のファイルを!で個別に復活させることはできないと明記しています（出典: Git公式ドキュメント）。99-secret/配下の一部だけ例外的に追跡したい、という要望はここでぶつかります。除外の単位を先に設計しておくほうが早く済みます。

3つ目は、internal領域を読ませたところで安心し、出力時のマスキングを省略することです。 前章のとおり、保管場所の分離と出力時の伏せ字は防ぐ事故が違います。読ませてよいことと、出してよいことは別の判断です。

3つとも、共通しているのは「1つの層で守れたつもりになる」形です。層を数えて、どれが効いているのかを言葉にできるかどうかが分かれ目になります。

11AIエージェントに渡す前に機密情報が消えているか、どう確かめるんですか？

高梨課長

高梨課長の発言

設計したつもりでも、本当に外れているのか不安が残ります。手元で確かめる方法はありますか。

鈴木さん

鈴木さんの発言

あります。設計図ではなく、いまの状態を見にいくのがこつです。健康診断と同じで、生活を改めた自覚ではなく、数値を測って確かめます。

確かめる操作は短く済みます。

# 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"

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

Gitとは別に、出力時のマスキングも確認します。生成した文面から個人名・取引先名・売上や単価の数値を検索し、1件でも残っていれば公開前に差し戻します。

Anthropicも、リスクの高い用途では隔離環境での十分なテストと防護策の併用を挙げています（出典: Anthropic公式）。ここでの防護策は、Gitによる物理隔離と出力マスキングの両方を指します。

12よくある質問

13まとめ｜今日やる3つのこと

境界は権限設定ではなく保管設計で決まる、というのがこの記事の主旨でした。分類・物理隔離・出力の伏せ字。この3層を、今日この順で自分の環境へ当てはめてください。