プログラムのコードを生成AIに貼るとき

エラーの原因が分からないときにコードを貼って聞くのは、もう普通の作業です。ただ、コードには本人が意識していないものが同梱されています。

コードは、貼った瞬間に何が出るか

不具合の原因が分からない。エラーメッセージの意味が分からない。そういうときにコードを貼って聞くのは、いまや普通の作業です。

ただ、コードには本人が意識していないものが同梱されています。

貼っているつもりなのはロジックだけ。実際には接続情報と業務構造が付いてくる。エラーログは特に危険で、実データがそのまま入る。

APIキー、データベースの接続文字列、アクセストークン。設定ファイルやコードの冒頭に書いてあるものです。

これらが外部に出た場合、学習に使われるかどうか以前に、その鍵自体を無効化する必要があります。送信してしまった時点で、安全だと見なせなくなるからです。

⚠ 入れてしまったら

該当のキーやトークンを失効させて、新しいものに差し替えてください。会話を削除しても、送信した事実は変わりません。「たぶん大丈夫」で使い続けるのが一番まずい判断です。

公開リポジトリに鍵を上げてしまった場合の対応と同じ考え方です。経路が違うだけで、やることは変わりません。

見落としやすいのがこれです。スタックトレースやログの出力には、処理中のデータがそのまま入ります。

顧客名、メールアドレス、注文番号、金額。「エラーメッセージを貼っただけ」のつもりが、個人データを貼っていることがあります。

貼る前に、ログの中身を上から読んでください。固有名詞が入っていたら置き換える。面倒ですが、ここは飛ばせません。

認証情報ほど直接的ではないものの、設計情報の流出にあたります。

テーブル名、カラム名、APIのエンドポイント名。これらを並べると、その会社がどういう業務を、どういう構造で回しているかが分かります。競合に見せたい情報ではありません。

対策は簡単で、質問に関係ないなら名前を変えて貼ればいい。t_customer_credit_limit を table_a にしても、構文エラーの原因は同じように分かります。

慣れると30秒で終わります。

6番は副産物として効きます。最小化する過程で、原因が自分で分かることがかなりあります。

✓ 置き換えを自動化する

エディタのスニペットや簡単な置換スクリプトを用意しておくと、毎回の手間が消えます。社内で1つ作って共有すれば、全員が使えます。

GitHub CopilotやIDE組み込みのAI補完は、構造が違います。貼るのではなく、編集中のファイルや周辺のコードが自動で送られます。

つまり、自分で選んでいません。開いているファイルに認証情報が書いてあれば、それも対象になり得ます。

確認しておくことを挙げます。

確認する点	なぜ
送信されるコードの範囲	開いているファイルだけか、リポジトリ全体か
除外設定ができるか	設定ファイルや秘密情報のあるディレクトリを外せるか
法人プランの学習ポリシー	個人版と法人版で扱いが違うことが多い
生成されたコードのライセンス	公開コードに酷似した出力が混ざる可能性

4番は情報漏洩とは別の論点ですが、受託開発では無視できません。納品物に出所の分からないコードが混ざると、後から問題になります。

ここまで書いてきて何ですが、根本的にはこれです。

認証情報を環境変数や秘密情報の管理サービスに置いていれば、コードを貼っても鍵は出ません。AIの話が出る前から言われてきたことで、今さら新しくはない。

ただ、生成AIの普及で、この基本ができていない会社の損害が一段大きくなりました。昔なら「リポジトリを公開しなければ大丈夫」で済んだものが、今は日常の質問で外に出ます。

設定ファイルの扱いを見直す、いい機会だと思っています。やることは増えません。順番が前に来ただけです。

社内ルールへの落とし込みはガイドラインのひな形、入れてしまった場合の初動はこちらの記事を見てください。