AIコーディングで秘密情報を守る｜権限・ログ・入力データの管理

秘密情報というと、チャット欄へAPIキーを貼らない対策が先に浮かびます。しかし、AIコーディングツールは会話だけでなく、作業ディレクトリのファイル、シェルの実行結果、Gitの差分、MCPなどで接続したサービスからも情報を取得し得ます。.envを直接貼らなくても、設定ファイルの読み取りやテスト失敗時の標準出力を通じて秘密がコンテキストへ入る可能性があります。

秘密を含むリポジトリでAIを使う余地はあります。ただし、コードの機密性だけを見ても安全性は判断できません。どの情報へ到達でき、どの操作を実行でき、どこへ送信できるかを明確にする必要があります。Codex公式文書は、ローカル実行について、OSが強制するサンドボックスと承認ポリシーを別の制御として説明しています。Claude Code公式文書も、ツールやパスを制御する権限と、Bashおよび子プロセスをOSレベルで制限するサンドボックスを補完関係に置いています。

管理対象は、プロンプト、添付ファイル、画像、貼り付けたログに限りません。リポジトリやIDEで開いた内容などの参照範囲、シェルやテストの実行、インターネットやMCPサーバーへの接続、会話・コマンド・CIの記録までを一つの経路として扱います。ツールの利用規約やデータ保持・学習利用の条件も契約プランや設定で異なり得るため、導入時と変更時に公式文書と契約条件を確認します。

最初の統制は、秘密情報をツールの手前で分離することです。APIキー、アクセストークン、秘密鍵、Cookie、接続文字列、本番データを禁止対象として明示します。個人情報や顧客コードなど、認証情報以外にも外部送信や二次利用を制限すべき情報は別区分にします。分類がなければ、担当者は毎回その場で判断することになり、同じデータでも扱いが揺れます。

禁止と書くだけでは足りません。サンプル設定はダミー値に置き換え、障害ログは必要な行だけを切り出し、識別子をマスクし、再現用データは合成データへ変えます。AIに渡すのは課題を解くための最小断片です。リポジトリ全体の探索が必要な作業と、一つの関数を直す作業を同じ権限で始めないことが重要です。

環境変数への移動も、それだけで保護を完了させる措置ではありません。エージェントが環境変数を表示するコマンドを実行できれば、値は出力へ現れます。クラウド実行でも秘密の注入方法と利用可能なフェーズを確認します。Codex公式文書では、クラウド環境に設定したsecretはセットアップスクリプトだけで利用でき、セットアップ後に削除されると説明されています。秘密鍵や本番認証情報を入力せず、設定値をダミー化し、必要な断片だけを渡す判断に加えて、どの工程で誰が値を読めるかまで決めます。

安全な初期値は、対象リポジトリだけを読み書きでき、ネットワークは閉じ、破壊的操作や境界外アクセスでは人の承認を求める状態です。Codexの公式文書では、CLIとIDE拡張の既定としてネットワークアクセスなし、書き込みはアクティブなワークスペースに限定されると説明されています。計画や相談だけならread-onlyに切り替えられます。具体的な既定値は更新され得るため、確認時点の製品挙動を固定的な保証とは扱わず、組織設定で明示します。

承認ダイアログがあれば安全だと考えるのも危険です。回数が増えると、内容を読まずに許可する運用になりやすいためです。普段の編集とテストは狭いサンドボックス内で実行し、依存関係の取得、外部APIへの接続、作業範囲外への書き込みだけを例外にします。Claude Code公式文書は、権限がツール利用やファイル・ドメインへのアクセスを制御し、サンドボックスがBashと子プロセスのファイルシステム・ネットワークアクセスをOSレベルで制限すると説明しています。片方だけで代替はできません。

Codexでファイル、承認、ネットワークの境界を分ける実例は、Codexのサンドボックスと承認の設計で確認できます。

例外には目的、対象、期限を持たせ、一時許可として扱います。調査はread-only、実装は作業ツリー内の編集とテスト、依存更新は必要な宛先への接続という具合にプロファイルを分けます。MCPやクラウドCLIには、読み取り専用ロールや対象プロジェクト限定のサービスアカウントを割り当てます。本番デプロイ、IAM変更、secret参照はAIの提案から切り離し、人がレビューして実行します。必要な操作だけを通せば、誤操作やプロンプトインジェクションが起きた際の影響範囲を狭められます。

ログには会話の全文より、誰が、どの対象に、どの権限で、何を実行し、例外を承認したかを残します。最低限、利用者、時刻、対象リポジトリ、ツールと実行環境、権限プロファイル、承認された操作、外部接続先、結果を記録します。組織の監査基盤へ集約する場合も、閲覧権限と保存期間を決めます。

一方、完全なプロンプト、ソース断片、コマンド出力を無条件で集めると、監査ログ自体が秘密情報の集積場所になります。認証情報らしい値は収集前にマスクし、本文を保存する必要がなければイベント情報だけを残します。インシデント調査に必要な粒度と、漏えい時の影響を比較して決めるべきです。

定期レビューでは、拒否や境界外アクセスの回数に加え、恒久許可へ変わった例外、使われていない強い権限、同じ宛先への反復承認、管理設定の変更を確認します。頻出する正当な操作は狭い許可ルールへ整理し、不自然な要求は閉じます。追跡性、ログ自体の機密性、改変を防ぐ完全性、保存と削除の基準がそろって初めて、承認疲れを抑えながら最小権限を維持できます。

人が秘密を貼らない運用にも漏れは起きます。生成コード、設定例、テスト用ファイル、履歴へ資格情報が混入する可能性を前提に、コミット前、プッシュ時、リポジトリ側のsecret scanningを重ねます。GitHubの公式文書によると、secret scanningはGit履歴の全ブランチを走査し、既知のsecret形式や追加設定したパターンを検出してアラートを作成します。利用できる機能や対象はリポジトリの公開範囲、ライセンス、設定で異なるため、管理画面で有効化状況を確認します。

スキャンは、漏れた秘密を安全な状態へ戻す機能ではありません。アラートを見つけたら、まず提供元で資格情報を失効または更新し、影響範囲と利用履歴を確認します。ファイルやGit履歴から文字列を消す作業はその後です。履歴を書き換えても、既に複製された値は無効になりません。誤検知を閉じる際も理由を残し、検出対象外の社内形式はカスタムパターンや別の検査で補います。

AIが生成した差分にも通常のレビューとCIを適用します。秘密をリポジトリ外で保管し、コミット前、プッシュ時、サーバー側で段階的に走査します。検知後は失効・更新、利用履歴の調査、文字列の除去、混入経路の改善という順序を崩しません。手作業を含むすべての変更へ同じ検査を適用することで、入力経路に左右されない停止基準になります。差分を受け入れる際の確認順は、AI生成コードのレビュー観点で7つの境界に分けています。

導入判定では、製品名ごとの安全・危険を決めるより、実際の作業経路を確認します。同じツールでも、ホームディレクトリから起動する場合と隔離した作業ツリーから起動する場合、ネットワークを全面許可する場合と宛先を限定する場合では、到達できる情報が違います。公式機能があっても、組織設定で有効にし、変更を管理しなければ統制にはなりません。

開始前には、データ分類、利用可能なリポジトリ、禁止入力、権限プロファイル、例外承認者、ログの管理者、secret検知時の連絡先を決めます。小さな対象で境界外アクセスと復旧手順を試し、期待どおり拒否・記録されることを確かめます。製品更新時には既定値や設定項目の変更も再確認します。

導入可否は、秘密情報と機密データの分類、作業別権限、サンドボックスの試験、秘密を残さない監査、secret検知時の連絡と失効手順、例外の期限を確認して決めます。冒頭に残した条件への答えは、作業単位の権限プロファイルです。調査、実装、依存更新、外部連携、本番変更を分ければ、日常操作をサンドボックス内で進め、強い権限だけを例外として審査できます。入力を減らし、到達範囲を閉じ、例外をログに残し、混入をスキャンする。この四つがつながったとき、AIコーディングの秘密情報管理は注意喚起から再現可能な運用へ変わります。