目次
AIへエラーを相談するために設定ファイルを貼る。生成されたコードを、そのままリポジトリーへ追加する。開発を速くする行動の中に、APIキーや接続用の秘密情報を別の場所へ複製する機会が増えています。見つけた文字列を削除するだけで、対応を終えていないでしょうか。
情報確認日：2026年10月15日。本記事はOWASPとGitHubの公式資料に基づく運用解説です。特定のAIサービスから漏えいが発生したというニュースではありません。以下の例は架空の構成であり、対応の順序と台帳の項目は本サイトからの提案です。 根拠資料：GitHub Docs：Removing sensitive data from a repository。
スポンサーリンク
秘密の値と、秘密ではない識別子を分ける
APIのクライアントID、サービスのURL、アカウント名は、必ずしも認証に使う秘密そのものではありません。一方、APIキー、アクセストークン、秘密鍵、更新トークン、Webhookの署名用シークレットなどは、所持するだけで操作できる場合があります。
どれが秘密かは、名前の印象だけで決めず、提供元の仕様で確認します。AIが「これは公開してよい」と説明しても、サービスの権限や失効方式まで調べた証拠にはなりません。運営者は値の全文ではなく、用途と種類を区別できる状態にしておくと対応しやすくなります。
本サイトでは、用途、所有者、保存場所、利用システム、付与権限、発行日、有効期限、無効化手順を台帳へ記録する方法を提案します。台帳に秘密の値を直接一覧表示する必要はありません。事故時に、どの資格情報を止めるかを特定できる識別情報が重要です。
漏えいした値は、消す前から使われ得る
公開リポジトリーや共有ログから文字列を削除しても、すでに複製された値は消えません。表示を非公開へ戻したことや、チャットの履歴を削除したことだけで、その資格情報が無効になるわけではありません。
GitHubの公式資料も、露出した情報が資格情報なら、まず失効や差し替えを行うことを説明しています。履歴の書き換えには、コミットIDの変更、共同作業への影響、別の複製からの再混入などの問題があります。履歴をきれいにすることと、アクセスを止めることは別です。
「悪用された形跡が見つからない」ことも、値を使い続ける十分な理由とは限りません。ログの保存期間や記録項目によって、確認できる範囲は異なります。露出した資格情報の権限と到達先に応じて、失効と利用履歴の確認を進めます。
スポンサーリンク
まず影響を抑え、次に使われた範囲を調べる
OWASPのSecrets Managementは、露出したキーの迅速な失効、差し替え、露出先からの除去、関連する記録の確認を扱っています。本サイトでは、発見者が一人で判断を抱えず、責任者と提供元の管理画面へつなぐ短い連絡経路を用意することを提案します。 根拠資料：OWASP：Secrets Management Cheat Sheet。
資格情報を止めると業務が止まることもあります。しかし、稼働を保つために広い権限の漏えいキーを放置するのは、影響を拡大するおそれがあります。悪用が進行している疑いが強いときは封じ込めを優先し、代替手段や復旧を並行して進める判断が必要です。
確認する対象は、API呼び出し、権限変更、新規資格情報、データ出力、請求や利用量などです。キー自体のログだけでなく、それを使って別の永続的なアクセス手段が作られていないかも調べます。提供元で取得できる記録と、自社に残る記録の範囲を区別してください。
差し替えは、依存先を把握してから完了とする
説明用に、サイトの問い合わせ通知と夜間の集計が同じAPIキーを使っている構成を考えます。Webサーバーだけ新しい値へ変更しても、夜間処理は古い値のままかもしれません。通常画面の確認だけでは、差し替え漏れを見つけられないことがあります。
サーバー、CI、定期実行、キュー、外部連携、開発環境を確認し、設定の参照元を整理します。複数の値を一時的に有効にできるサービスでは、通常の計画的な更新に段階的な移行を使える場合があります。ただし、漏えいした古い値を残す期間は、その分だけ危険が残ります。
本サイトでは、更新後の成功確認と、古い資格情報での拒否確認を別の合格条件にする方法を提案します。正常な通信が通っただけでは、古い値がまだ使える問題を見落とします。古い値をテスト用に貼り回さず、許可された検証手順で失効状態を確認します。
スポンサーリンク
AIへの相談に使う資料を、先に整える
エラーの調査には、全文の設定ファイルや全ヘッダーが必ず必要とは限りません。秘密の値を除き、エラーコード、発生時刻、ソフトウェアの版、対象処理、再現条件をまとめた相談用の資料を作ると、不要な複製を減らせます。
置換は、実際の値を残さない固定の例示文字列で行います。末尾だけ隠す方法では、必要以上の識別情報が残ることがあります。URLのクエリーや署名付きダウンロードリンク、Cookie、スクリーンショット、接続文字列にも注意してください。
ただし、機械的なマスキングだけで漏れがなくなるとは限りません。名前が違う秘密や、エンコードされた値、複数行の鍵などが対象になります。AIへ渡す前の確認担当と、渡してよい資料の範囲を決め、実際の本番資格情報を再現用のサンプルに使わない運用を提案します。
環境変数へ移しても、出力すれば露出する
コードへ直接書かず、環境変数や秘密管理サービスから読み込むことは改善になります。しかし、デバッグ出力、例外メッセージ、外部コマンドの結果に含まれれば、ログへ複製される可能性があります。保存場所だけでなく、読み込んだ後の経路を確認します。
GitHubの資料は、自動のログ伏字を過信しないよう説明しています。変形した値や構造化されたデータでは、想定どおり隠れない場合があります。正常系だけでなく、認証失敗や接続エラー時に何が標準出力とエラー出力へ出るかを、検証用の値で確認します。 根拠資料：GitHub Docs：Secure use reference。
AIエージェントの作業記録も同じです。ツールの引数、HTTP応答、生成した設定、失敗時の要約へ値を再掲しない設計が必要です。調査が便利になるという理由で、秘密を含む全応答を長期保存する運用にしないでください。
共有するキーを減らすと、失効しやすくなる
一つのキーを全システムで共有すると、誰が使ったか分かりにくく、止める影響も広がります。用途や環境ごとに分け、必要な権限だけを与える方法を提案します。開発環境と本番環境を分けると、試行中の誤送信の影響も狭めやすくなります。
対応するサービスでは、長期間有効な秘密を配布する代わりに、短命な資格情報やワークロードの認証を検討できます。ただし、短命であることだけで、その間の操作権限が適切になるわけではありません。対象と実行できる操作の制限も必要です。
秘密管理を担当者一人の端末に依存させないことも重要です。交代や不在のときに失効できる権限、連絡先、復旧手順を整えます。緊急用のアクセス手段も、利用履歴と管理責任を明確にし、普段の共有パスワードへ戻らないようにします。
古い値が残る場所を、種類ごとに探す
差し替え後の設定ファイルだけでなく、デプロイ成果物、ジョブの引数、キャッシュ、古いコンテナー、サポート用の添付資料なども確認します。生きた資格情報が残っていれば、後からその環境が動いたときに使われる可能性があります。本サイトでは、台帳の利用先と、実際の設定の参照元を照合する方法を提案します。
また、バックアップに古い設定が含まれる場合、復旧後に失効済みの値へ戻ることがあります。値を有効に戻すのではなく、新しい資格情報を安全な経路で注入する復旧手順を用意します。失効を成功させることと、再び古い構成へ戻さないことは別の確認です。古い値を検出した際の通知にも、その値の全文を載せないようにします。
スポンサーリンク
チームへ広めるのは、秘密ではなく対応手順
事故の第一報へAPIキーをそのまま貼ると、対応のための連絡が新しい露出先になります。連絡には、種類、用途、管理画面の対象、発見場所、発見時刻、現在の停止状態を使うことを提案します。秘密を確認する必要がある担当者だけが、許可された保管先で扱います。
委託先や複数部署が関わる場合は、誰が失効し、誰が設定を更新し、誰が利用記録を確認するかを分けます。全員がそれぞれ新しいキーを発行すると、不要な資格情報が増えて追跡しにくくなります。作業完了時には、利用中の値の識別情報と権限を台帳へ反映し、未使用の値を残さないことまで確認します。
削除・証拠保全・再発防止を両立する
露出した値を除去する際は、事故の発生時刻や対象、対応経緯を残します。証拠が必要だからといって、秘密の全文を誰でも見られる報告書へコピーする必要はありません。調査用の保全物と、通常の進捗記録を分けて管理します。
リポジトリーの履歴修正が必要なら、共同作業者や影響範囲を確認して計画します。公開済みの複製をすべて回収できると保証するべきではありません。まず資格情報を無効化し、その後、露出先ごとの除去と再混入の防止を進めます。
- 発見：資格情報の種類、露出先、発見時刻を、値を広めずに記録する。
- 封じ込め：該当の資格情報を失効し、必要なら連携機能を一時停止する。
- 復旧：用途別の新しい値へ移行し、全依存先と古い値の拒否を確認する。
- 調査：操作履歴、追加された権限、データ出力、利用量を照合する。
- 再発防止：相談用資料、保存経路、検知と連絡手順を更新する。
訓練では実際の漏えいを起こさず、検証用資格情報を使って停止から復旧までの時間と漏れを確認します。AIを使う開発でも、秘密情報の管理は「貼らない」だけで終わりません。万一露出したときに、その値を止めて安全に戻せる仕組みまで持つことが重要です。
スポンサーリンク
