コーディングAIのプロンプトインジェクション対策：.env漏えいを防ぐ実践設計

トレンドシグナル

Qiitaで「Claude Codeはプロンプトインジェクションで.envを漏らすか？」という検証系記事が注目。
ZennではIssue駆動でプロンプトを管理する運用が広がっている。
現場導入が進み、AIが複数ファイル編集やコマンド実行を担うケースが増加。

これは“チャット問題”ではなく“実行境界問題”

プロンプトインジェクションを「会話AIの小ネタ」と捉えると失敗します。コーディングAIでは、モデルが実行権限を持つツール層に接続されるため、影響が一段深くなります。

リポジトリ読み取り
シェル実行
外部API呼び出し
CI連携

この構成では、悪意ある指示文が1つ混ざるだけで、情報流出や不正変更の入口になります。問題の本質はモデルの善悪ではなく、自然言語指示と特権操作をつなぐ制御面です。

攻撃面を4つに分けて考える

1. リポジトリ文脈面

README、コメント、生成ファイル、移行ガイドなどに埋め込まれた指示文をAIが参照する可能性があります。露骨な命令文だけでなく、文脈依存の誘導が実運用では厄介です。

2. Issue/PRメタデータ面

チケット本文やレビューコメントを“正しい指示源”として無条件に信頼すると危険。OSSや横断チーム環境では特に注意。

3. ツール境界面

モデル出力が一見無害でも、実行ラッパー側の許可範囲が広すぎると抜け道になります。コマンド許可・外向き通信制御が必須です。

4. ログ面

プロンプト全文や実行結果をそのまま保存し、ログ基盤自体が機密の二次漏えい源になるケースがあります。

実効性の高い防御レイヤ

レイヤ1: 秘密情報を“見せない”

最強の防御は、そもそもAIセッションに秘密を渡さないこと。

短命・最小権限の資格情報
必要工程だけへの限定注入
.envや鍵素材を読めるパスから外す

レイヤ2: 能力をプロファイル化

単一の万能エージェントを作らず、用途別プロファイルへ分離。

読み取り専用分析モード
ネットワーク無効のリファクタモード
コマンド制限付きテストモード
人手承認必須のリリースモード

レイヤ3: 入力の信頼階層

入力ソースを同列に扱わない。

Tier1（高信頼）: 署名済み社内テンプレ
Tier2（中信頼）: 社内Issue/コメント
Tier3（低信頼）: 外部PR本文、取り込み資料、生成物

低信頼入力は命令文抽出・無害化を強化する。

レイヤ4: 副作用境界で人手承認

外部送信、権限変更、公開操作などは必ず承認ゲートを置く。差分レビューだけでなく、実行意図とコンテキストも確認する。

推奨ワークフローテンプレート

タスク受領: チケット文面を正規化し、ノイズ命令を除去
計画提示: まず実行せず、計画だけ提出
ポリシー照合: 必要権限と許可プロファイルを照合
サンドボックス実行: ネットワーク/ファイル制限下で実施
来歴付きレビュー: 差分＋セッション来歴を確認
事後スキャン: ログ/成果物の機密パターン検査

初期は少し遅く見えますが、事故確率を大きく下げます。

監視すべき指標

出力・ログ内の秘密パターン検出件数
能力別ポリシーブロック件数
未遂（ブロック済み流出試行）件数
高リスク作業のレビュー所要時間

導入初期にブロック件数が増えるのは、むしろ可視化が効いてきたサインです。

2026年の注目点

能力契約（capability contract）を前提にしたコーディングAI
AI関与コミットの来歴証明（provenance）の標準化
CIでのプロンプトインジェクション擬似攻撃テスト

結論として、勝つチームは「最も自律的なAI」を持つチームではありません。最も明確な信頼境界を設計したチームです。