AIコーディングで気をつけたい秘密情報の扱い｜APIキーや個人情報を守る運用

AIコーディングツールは、開いているファイルやリポジトリの内容を読み取って、コードの提案や修正を行います。便利な反面、読み取られる範囲に秘密情報が含まれていると、意図しない形で外部のサービスに送られる可能性があります。

ここでいう秘密情報とは、外部に出ると困る情報のことです。APIキー（外部サービスを使うための鍵となる文字列）やデータベースのパスワード、顧客の個人情報、取引先との契約内容などが含まれます。開発の現場では、こうした情報が設定ファイルやテスト用データの中に混ざっていることも珍しくありません。

この記事では、AIコーディングツールを使うときの秘密情報の扱い方を、開発チームで決めておきたい順に説明します。ツールがどの範囲のデータを読み取り、どう扱うかは製品や契約によって異なります。導入時は各製品の公式情報を確認してください。

AIコーディングで秘密情報が出ていく場面

秘密情報が出ていく場面は、大きく分けて三つあります。一つ目は、ツールが作業のためにファイルを読み取るときです。環境変数を書いた設定ファイルがリポジトリ内にあると、作業の流れで読み取られることがあります。

二つ目は、人が指示文に貼り付けるときです。エラーの原因を調べたくて、ログをそのまま貼り付けることもあるでしょう。そのログに接続情報や利用者のメールアドレスが含まれていれば、それもツールに渡ります。

三つ目は、AIが作ったコードに秘密情報が入るときです。説明用の例として書かれた値や、読み取ったファイルの中身が、生成されたコードに残ることがあります。そのままコミットすると、リポジトリの履歴に秘密情報が残ってしまいます。

扱う秘密情報を書き出す

対策の最初は、チームで扱っている秘密情報を書き出すことです。何が秘密情報にあたるのかが人によって違うと、注意の向け方もばらばらになります。種類と置き場所、誰が管理しているかを一覧にしましょう。

書き出してみると、テスト用のデータに本番のデータを複製して使っている、といった状態が見つかることがあります。テストに架空のデータを使うようにするだけでも、ツールに渡る秘密情報を減らせるはずです。

一覧は一度作って終わりにせず、新しい外部サービスを使い始めたときなどに更新します。誰が更新するかも決めておくと、一覧が古いまま放置されるのを防げます。

ツールに読ませない仕組みを作る

「気をつけて使う」だけでは、秘密情報を守り続けるのは難しいものです。忙しいときほど確認が抜けるため、仕組みで防ぐことを考えます。

基本になるのは、秘密情報をリポジトリに置かないことです。接続情報は環境変数や専用の管理サービスに置き、リポジトリには値を含まない見本のファイルだけを置きます。もともとリポジトリに秘密情報がなければ、ツールが読み取る機会も減るでしょう。

AIコーディングツールの中には、読み取らせないファイルを指定できるものがあります。指定の方法や対象になる範囲は製品ごとに異なり、変更されることもあります。公式情報で確認してから設定し、実際に対象のファイルが読み取られないかを試しておくと安心です。

組織で契約するプランを選ぶ場合は、入力したデータの扱いや保存の有無も確認します。データの取り扱いは製品や契約によって異なるからです。自社の情報管理の方針と照らし合わせ、使ってよいプランと使ってはいけないプランをチームに伝えておきましょう。

開発者が使う端末の管理も関係します。個人の端末で業務のリポジトリを扱うと、どのツールが入っているかを組織で把握しにくくなります。業務で使ってよいツールと端末を決めておけば、秘密情報がどこに送られうるかを説明しやすくなるでしょう。

コードへの混入を防ぐ確認

AIが作ったコードに秘密情報が入るのを防ぐには、コミットの前に自動で確認する仕組みが役立ちます。秘密情報らしい文字列を検出するツールを、コミット時やプルリクエストの作成時に動かす方法があります。

レビューでも確認しましょう。設定値がコードに直接書かれていないか、ログの出力に個人情報が含まれていないかを見る項目として加えます。AIが作ったコードでは、例として書かれた値がそのまま残ることもあります。見慣れない文字列があれば、変更者に由来を尋ねてください。

指示文に貼り付ける情報についても、ルールを決めておきます。ログやエラーメッセージを貼る前に、接続情報や個人情報を伏せ字にする習慣をつけるとよいでしょう。チームの運用ルール全体については、AIコーディングツールをチームで使うための運用ルールで整理しました。

漏れたかもしれないときの対応

対策をしていても、秘密情報が外に出た可能性に気づくことはあります。そのときに慌てないよう、連絡先と手順を事前に決めておくことが大切です。

APIキーやパスワードが漏れた可能性がある場合は、まず値を無効にして新しい値に切り替えます。リポジトリの履歴から消すだけでは、すでに複製されたものが残るかもしれません。値そのものを変えることを先に行い、そのうえで誰がいつ気づき、何をしたかを記録しましょう。

個人情報や取引先の情報が関わる場合は、社内の担当部署に早めに相談してください。法令や契約上の対応が必要になることもあります。対応の要否は状況によって異なるため、最新の情報は公的機関や専門家に確認することをおすすめします。

手順は文書にして、チームの誰でも見られる場所に置いておきましょう。年に一度など時期を決めて、連絡先が変わっていないかを確かめると、いざというときに迷わずに済みます。

エラー調査に渡すログを作り直す例

架空の外部API連携で、認証エラーを調べる場面を考えます。開発者が渡したいのは、要求した処理、エラーの種類、発生した条件です。実際の認証情報や顧客名は、原因を説明するために必要とは限りません。

次の表は、AIへ渡す前の置き換え方の例です。例示の文字列はいずれも実在する認証情報ではありません。

置き換え後は、再現条件が失われていないかを確認します。たとえば文字数や空欄の有無が原因なら、その条件は架空の値でも再現できるようにします。「顧客名を削ったら直った」といった場合は、元の値をそのまま送る前に、文字種や長さをそろえた架空データで確かめてください。

文章中の氏名を消しても、添付ファイル、URL、識別番号、自由記述から元の情報が分かる場合があります。固有名詞の置き換えだけで入力可能と判断せず、会社が認めた情報とツールの範囲に収まるかを確認します。

環境変数や除外設定だけでは防げない経路

接続情報をコードから環境変数へ移すことは、ソースへの混入防止に役立ちます。ただし、AIツールがコマンドを実行でき、そのプロセスに秘密情報を渡している場合は、実行結果を通じて値を読めることがあります。環境変数に移しただけで、AIから見えなくなるわけではありません。

リポジトリの管理対象から外したファイルも、端末上には存在します。Gitの除外設定と、AIツールが読み取れる範囲は分けて考えてください。ツール固有の除外設定についても、ファイル検索には効いていても別の操作経路を許していないか、利用機能ごとに確認します。

作業用の環境には、本番の認証情報を渡さず、必要な場合だけ用途を限定したテスト用の接続先を用意します。端末のファイルだけでなく、課題管理、ストレージ、データベースなどの接続先にも注意してください。コードを読ませるだけのつもりでも、連携機能に広い権限があれば扱える情報が増えます。

読取り範囲は無害な見本で確認する

設定を試すために、本物の秘密情報を置く必要はありません。開発用の隔離したフォルダに、秘密情報ではないと明記した見本を用意し、通常の作業で対象外の内容が参照されないかを確認します。目的は、どの操作経路で何が読めるかを把握することです。

一つの操作で読まれなかった結果を、すべての機能で防げる証拠にはしません。ファイル参照、コマンド実行、外部サービスへの接続を、それぞれ権限設定と照らし合わせます。使用しない連携を外すなど、業務に不要な経路を減らしてから試用を始めます。

漏えいが疑われるときに残す記録

担当者への連絡では、何の情報が、どの操作で、どのサービスへ渡った可能性があるかを整理します。発見した時刻、関係するアカウント、停止した作業、認証情報を無効化した時刻を残します。事故の説明資料へ秘密の値そのものを再び貼り付けないようにしてください。

会話やコードから値を消したことと、認証情報を無効にしたことは別の対応です。認証情報は管理担当者と連携して失効・再発行し、関連する処理が新しい値で動くかを確かめます。利用履歴の確認や関係部署への連絡も、社内の対応手順に従って進めます。

再発防止では「気をつける」を追加するだけで終わらせず、入り口を直します。ログへ認証値を出していたなら出力内容を変え、広すぎる接続権限を渡していたなら権限を絞ります。修正後は、同じ情報を使わない再現例で、問題の経路がふさがれたかを確認してください。

まとめ

AIコーディングツールで秘密情報を守るには、扱う情報を書き出し、読ませない仕組みと自動の確認を組み合わせることが大切です。指示文に貼る情報のルールと、漏れたかもしれないときの手順も、試用を始める前に決めておきましょう。

e-Grantsでは、Codex・Claude Code・GitHub Copilotの導入にあたり、チームで使うための運用ルールの整備を支援しています。秘密情報の扱いを含めて導入を進めたい場合は、AI開発環境の導入・整備をご覧ください。