AI開発で秘密を漏らさない|.env・ログ・依頼文の確認リスト

AIコーディングでAPIキーやトークンを漏らさないために、.envと.gitignoreの使い方、ログや依頼文の伏せ方、漏えい疑いの初動、自動検査の考え方を解説します。

AIコーディングでは、コードだけでなくログや画面もAIへ渡すため、APIキーを一緒に貼り付けがちです。秘密をコードから分離し、送信前に伏せ、漏れた疑いがあれば値を無効化する最小手順を解説します。

秘密に含まれるもの

秘密情報とは、知られた相手に操作・閲覧・本人確認を許してしまう値です。APIキー、トークン、パスワード、秘密鍵、接続文字列、OAuthのクライアントシークレット、Webhook URL、Cookie、認証ヘッダー、復旧コードなどが該当します。

メールアドレス、顧客名、住所、非公開URLは資格情報とは限りませんが、個人情報や未公開情報として同様に扱います。迷った値は、権限、課金、個人情報、本番データへつながるかで判断します。

AIに「秘密です」と伝えるだけでは送信を取り消せません。実値を渡さなくても再現できる材料へ変えます。ファイル配置はClaude Codeで失敗しないフォルダ構成の基本も参考になります。

秘密情報の扱い早見表

対象共有してよい形避ける形漏えいが疑われる場合
APIキー・アクセストークン変数名と架空値実値、先頭や末尾だけ残した実値提供元で失効・ローテーション
.env・接続文字列キー名だけの.env.example実値入りファイル、DBのURLや認証情報値を無効化し、追跡範囲を確認
ログ・HTTPヘッダー[REDACTED]へ置換した必要行AuthorizationCookieを含む全文セッションやトークンを無効化
スクリーンショット必要範囲だけを撮った画像アドレスバー、通知、設定値を含む全画面写った資格情報を無効化
個人・顧客・本番データ架空データ、匿名化した最小例氏名、住所、注文情報、非公開URL管理者へ連絡し、影響範囲を確認

.envを追跡対象から外す

ローカル開発では、秘密をソースへ直書きせず、環境変数から読みます。.envを使う場合は、実値を置くファイルと、共有用の見本を分けます。

# 実値を含むファイル
.env
.env.*

# 共有できる見本だけ残す
!.env.example

.env.exampleにはOPENAI_API_KEY=replace_with_your_own_keyのような変数名とダミー値だけを書きます。アプリ側では実値を埋め込まず、環境変数を参照します。

const apiKey = process.env.OPENAI_API_KEY;

if (!apiKey) {
  throw new Error('OPENAI_API_KEY is not set');
}

Git公式資料によると、すでに追跡されている.envへ後から無視設定を加えても追跡は止まりません。まず確認します。

git status --short
git ls-files -- .env
git check-ignore -v .env

git ls-files -- .envに結果が出れば追跡済みです。Git公式は追跡を止める方法としてgit rm --cachedを案内していますが、過去のコミットに入った値は消えません。秘密が実在するなら、先に失効またはローテーションへ進みます。

.envが読み込めない場合も、確認のために実値を画面へ出す必要はありません。変数が存在するか、空か、読み込み処理が実行されたかを分けて確認します。具体的な切り分けは環境変数が読み込めないときの確認手順を参照してください。

ログとスクリーンショットを確認する

秘密はコードよりも、調査用の出力へ混ざりがちです。たとえば、リクエストヘッダー、環境変数一覧、設定画面、接続エラーには実値が表示されることがあります。

AIへ渡す前に、AuthorizationCookietokensecretを含む行、URLのクエリ、ターミナルの前後、ブラウザのアドレスバー、画面端の通知、画像の切り抜き範囲を確認します。

ログには実値を出さず[REDACTED]へ置き換えます。スクリーンショットも、撮影後の塗りつぶしだけに頼らず、秘密がある画面を閉じてから必要範囲だけ撮ります。

AIへ渡す前に伏せる

AIへは「秘密を除いた最小の再現例」を渡します。実値を架空値に交換し、交換したことを明記すると、AIがその文字列を本物として調査する誤解も減らせます。

依頼: API呼び出しの401を切り分けてください。
伏せた値: APIキー=sk-example-not-real
対象: 環境変数の読込とAuthorizationヘッダー

再現には変数名、型、発生した処理、HTTPステータス、秘密を除いたエラー文で足りることが多いです。リポジトリ全体ではなく対象ファイルを絞り、git diffで送る差分を確認します。Codexへの依頼テンプレートのように、対象・目的・完了条件を分けると安全です。

OpenAIの公式案内では、APIキーをブラウザやモバイルアプリへ埋め込まず、バックエンドサーバーを経由させること、リポジトリへコミットせず環境変数を使うことが推奨されています。チーム内でもキーを共有せず、メンバーごとに個別のキーを使います。AIサービスごとの保存条件や管理機能は変わり得るため、利用中サービスの現行設定も確認してください。

漏れた疑いがある時の初動

漏えいの疑いがあるときは、「投稿を消したから安全」と判断しません。GitHub公式資料は、パスワードやトークンなどを履歴から消す場合でも、最初にその秘密を失効またはローテーションするよう案内しています。

  1. 対象のキーを提供元で失効またはローテーションする
  2. 新しい値へ更新し、古い値が無効なことを確認する
  3. 利用履歴、課金、監査ログと露出箇所を調べる
  4. 必要な関係者へ値を引用せず状況を共有し、履歴修正は別途判断する

履歴の書き換えは共同作業者のクローンやフォークへ影響します。資格情報の無効化とは別作業として扱い、強制pushはチームで確認します。失効・再発行の場所はサービスごとに異なるため、提供元の公式手順を確認します。OpenAIは、漏えいが疑われるキーをAPI Keysページで直ちにローテーションし、利用状況も確認するよう案内しています。

チェックを自動化する

コミット前の短い確認を固定します。

git status --short
git diff --cached --stat
git diff --cached

差分ではapi_keyauthorizationpasswordsecrettokenなどを探します。単純な正規表現には誤検知と見逃しがあるため、自動削除せず人が確認します。

GitHubのpush protectionは、コマンドラインからのpushだけでなく、GitHub画面上のコミット、ファイルアップロード、REST APIなども検査対象にし、秘密の可能性がある値を検出するとリポジトリへ到達する前にブロックします。一方、リポジトリ単位の保護にはGitHub Secret Protectionの有効化が必要で、既定では無効です。利用できる範囲と設定状態を確認し、手作業の差分確認も残します。

自動検査を追加する前に、何を検出し、警告時にどう止めるかを決めます。AIコード健診チェックリストも、秘密検査を含む確認項目の整理に使えます。

最後に、次を終了条件へ加えます。

  • 実値をコード、見本、テストデータへ入れていない
  • .envが未追跡で、無視規則が効いている
  • 差分、ログ、画像、AIへ渡す範囲を確認した
  • 警告を理由なく回避せず、漏えい疑いでは先に値を無効化した

長い依頼へ設定やログを貼りすぎてしまう場合は、AIへの指示が長すぎるときの整理法も併用してください。秘密を「書かない」、送信前に「見つける」、疑いがあれば「無効化する」の三段階を毎回同じ順で回すことが、事故を小さくする基本です。

よくある質問

.env.gitignoreに追加すれば、すでにコミットした秘密も消えますか?

消えません。.gitignoreが対象にするのは、意図的に未追跡にするファイルです。追跡済みファイルは別途追跡を止める必要があり、過去の履歴に入った秘密はまず失効・ローテーションします。

プライベートリポジトリならAPIキーを置いても安全ですか?

置かない方が安全です。閲覧権限の誤設定、アカウント侵害、ログやバックアップからの露出があり得ます。公開・非公開にかかわらず、環境変数や用途に合うシークレット管理機能を使います。

AIへエラーログを貼るとき、どこまで伏せればよいですか?

認証ヘッダー、Cookie、トークン、接続文字列、URLのクエリ、個人情報を伏せます。エラーの種類、HTTPステータス、発生箇所、秘密を除いた前後数行から始め、不足分だけ追加します。

APIキーの一部だけならAIへ貼ってもよいですか?

識別に不要なら貼りません。調査ではsk-example-not-realのような明らかな架空値へ置き換えます。複数キーを区別したい場合は「開発用キーA」「本番用キーB」のようなラベルで足ります。

漏えいを疑ったら、投稿やコミットを削除するだけでよいですか?

削除だけでは不十分です。コピー、キャッシュ、クローンなどに残っている可能性があるため、最初に資格情報を失効・ローテーションします。その後、利用履歴と影響範囲を調べ、必要なら関係者と履歴修正を調整します。

一次情報

以下は2026年7月24日に確認した公式資料です。

続き(結論と実データ)はnoteに置いています

ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。

noteで続きを読む Xをフォローする