この記事で解決すること
動画「え、まだ社外秘コードをそのままAIに貼ってるんですか？」の補足記事です。
動画では時間の都合で触れられなかった詳細を解説します。
問題：なぜこれが危険なのか
え、まだ社外秘コードをそのままAIに貼ってるんですか？
解決策：明日から使えるベストプラクティス
貼る前に社名や鍵をマスキングするか、学習に使われない設定のAIだけ使いましょう
はい。ここは「気をつけましょう」だけではなく、実際にどうマスキングするか／どういうコードに置き換えるか／AI利用時に何を確認するかまで示します。
1. まず「そのまま貼る」のが危険な理由について
特に危険なのは、次のような情報です。
| 情報 | 例 | リスク |
|---|---|---|
| APIキー | sk-xxxxxxxx |
不正利用・課金 |
| DB接続情報 | mysql://user:password@... |
DBへの不正アクセス |
| JWT秘密鍵 | JWT_SECRET=... |
なりすまし |
| Firebase秘密鍵 | private_key: "-----BEGIN..." |
認証基盤への不正利用 |
| 社名・顧客名 | ABC株式会社 |
情報漏えい |
| 社内URL | https://intra.example.local |
内部構成の漏えい |
| 個人情報 | 氏名・メール・電話番号 | 個人情報漏えい |
| 未公開ソースコード | 業務システムのコード | 技術・営業上の機密漏えい |
そして重要なのは、「コードだから秘密ではない」と考えないことです。
例えば、このコードは一見ただの設定処理ですが、
const client = new ApiClient({
baseURL: "https://api.example.co.jp",
apiKey: "sk-xxxxxxxxxxxxxxxx"
});
apiKey が本物なら、その時点で秘密情報です。
2. AIに貼る前にマスキングする
例えば実際のコードが、
const firebaseConfig = {
apiKey: "AIzaSyXXXXXXXXXXXXXXXX",
authDomain: "my-company-prod.firebaseapp.com",
projectId: "my-company-prod",
privateKey: "-----BEGIN PRIVATE KEY-----\nXXXX..."
};
だったとします。
AIに渡すなら、こう変えます。
const firebaseConfig = {
apiKey: "[REDACTED_API_KEY]",
authDomain: "[COMPANY]-prod.firebaseapp.com",
projectId: "[PROJECT_ID]",
privateKey: "[REDACTED_PRIVATE_KEY]"
};
重要なのは、単に文字列を XXX にするだけではなく、AIが問題を理解できる程度の構造を残すことです。
例えば、
apiKey: "[REDACTED_API_KEY]"
なら、
APIキーが設定されている
ことはAIに伝わります。
3. 社名・顧客名も置き換える
悪い例：
const companyName = "株式会社○○商事";
const customerEmail = "yamada@customer-company.co.jp";
AIに相談するときは、
const companyName = "[自社名]";
const customerEmail = "[CUSTOMER_EMAIL]";
とします。
さらに、複数の会社が登場する場合は、
[自社]
[顧客A]
[顧客B]
のように一貫した名前を付けると、AIもコードの関係性を理解しやすくなります。
4. .env は絶対に丸ごと貼らない
特に注意したいのが .env です。
例えば、
DATABASE_URL=mysql://admin:SuperSecretPassword@db.example.com:3306/company
JWT_SECRET=xxxxxxxxxxxxxxxx
OPENAI_API_KEY=sk-xxxxxxxx
FIREBASE_PRIVATE_KEY="-----BEGIN PRIVATE KEY-----..."
これを、
この環境変数がおかしいので見てください
とそのままAIに貼るのは避けます。
代わりに、
DATABASE_URL=mysql://[USER]:[PASSWORD]@[HOST]:3306/[DATABASE]
JWT_SECRET=[REDACTED_JWT_SECRET]
OPENAI_API_KEY=[REDACTED_API_KEY]
FIREBASE_PRIVATE_KEY=[REDACTED_PRIVATE_KEY]
とします。
さらに、.env をGitにコミットしないことも重要です。
.env
.env.local
.env.*.local
5. コード側でも「秘密情報を直書きしない」
例えば、これは避けます。
const apiKey = "sk-xxxxxxxxxxxxxxxx";
const client = new ApiClient({
apiKey
});
環境変数を使います。
const apiKey = process.env.API_KEY;
if (!apiKey) {
throw new Error("API_KEY is not configured");
}
const client = new ApiClient({
apiKey
});
.env 側：
API_KEY=実際のAPIキー
AIに相談するときは、
API_KEY=[REDACTED_API_KEY]
です。
6. 「AIに貼ってよいコード／ダメなコード」の基準を作る
現場では、毎回判断するのが面倒なので、簡単なルールを決めてしまうのがおすすめです。
🟢 そのまま相談しやすい
Reactコンポーネント
TypeScriptの型定義
一般的なアルゴリズム
エラーメッセージ
公開済みのドキュメント
ダミーデータ
🟡 マスキングしてから
社内ソースコード
社内URL
会社名
顧客情報
DBテーブル名
APIレスポンス
ログ
設定ファイル
🔴 原則そのまま貼らない
APIキー
パスワード
秘密鍵
アクセストークン
JWT Secret
Firebase秘密鍵
AWS Access Key
個人情報
本番DBの認証情報
7. 実際のAI相談テンプレート
例えばエラーについてAIに質問するときは、こんな形にします。
【目的】
Next.jsのAPI呼び出しで401エラーが発生しています。
【環境】
Next.js 14
TypeScript
Node.js 20
【エラー】
401 Unauthorized
【コード】
const client = new ApiClient({
baseURL: "[API_BASE_URL]",
apiKey: "[REDACTED_API_KEY]"
});
const response = await client.get("/users");
【確認したいこと】
401になる原因として考えられる箇所を教えてください。
これなら、AIに問題解決に必要な情報を与えながら、秘密情報は渡さないというバランスを取れます。
8. 「学習に使われないAIなら安全」も注意
ここは記事を書くなら、少し表現を修正した方がいいです。
「学習に使われない設定のAIだけ使いましょう」
だけだと、**「学習に使われなければ何を貼ってもOK」**と誤解される可能性があります。
実際には、
学習利用の有無だけでなく、入力データの保存期間、管理者によるアクセス、契約内容、データ所在地、会社の情報セキュリティポリシーなども確認する
という考え方が安全です。
例えば社内でAIを利用するなら、
① AIサービスの利用規約を確認
↓
② 入力データの取り扱いを確認
↓
③ 学習利用の設定を確認
↓
④ 保存期間・削除方法を確認
↓
⑤ 会社のAI利用規程を確認
↓
⑥ それでも秘密情報は原則マスキング
という運用にします。
9. さらに一歩進めるなら「AI投入前チェック」
実務では、こんなチェックリストを用意しておくと便利です。
□ APIキーを削除した
□ パスワードを削除した
□ 秘密鍵を削除した
□ JWT Secretを削除した
□ DB接続情報を削除した
□ 個人情報を削除した
□ 顧客名を置き換えた
□ 社内URLを置き換えた
□ 本番環境の情報を削除した
□ AIサービスのデータ利用条件を確認した
□ 社内のAI利用ルールに違反していない
そして一番大事なルール
「AIに貼る前に秘密情報を消す」ではなく、「秘密情報を最初からコードに直書きしない」ことです。
つまり、
秘密情報をコードに直書き
↓
Gitにコミット
↓
AIに貼る
という事故ルートを、
秘密情報
↓
環境変数・Secret Manager
↓
アプリケーション
↓
AIには [REDACTED] のみ渡す
に変える。
この部分まで入れると、単なる「AIに気をつけよう」という話ではなく、エンジニアが明日から実践できるセキュリティ対策になります。
まとめ
無料版と有料版、「どの設定を切れば安全か」だけで判断していませんか？
AIに社外秘コードや機密情報を入力するなら、重要なのは料金プランだけではありません。
- APIキー・パスワード・秘密鍵はAIにそのまま貼らない
- 社名・顧客名・個人情報はマスキングする
.envや本番環境の設定を丸ごと貼らない- AIサービスの学習利用・保存期間・データ管理を確認する
- 会社のAI利用ルールに従う
- 可能なら秘密情報を環境変数やSecret Managerで管理する
そして、「学習に使われない設定だから大丈夫」と考えるのも危険です。
AIに入力する前に、そもそもその情報を外部サービスへ渡してよいのか？
この視点を持つことが、最も重要なセキュリティ対策です。
迷ったら、貼らない。
貼るなら、まずマスキングする。
AIを便利な開発パートナーとして使うためにも、「何を入力してよいか」を決めてから使う習慣を身につけましょう。
#まだやってるんですか #コードの女神はみた #プログラミングスキル
動画で見る
YouTubeショート動画でも同じテーマを解説しています👇
チャンネル登録・高評価もよろしくお願いします 🔔
この記事は「コードの女神は見た！」チャンネルの連動記事です。