ChatGPTやClaudeに、仕事のコードや資料をそのまま貼り付けていませんか?
GitHubに上げたリポジトリ、本当に「鍵」が入っていないと言い切れますか?
今回は、AIとGitHubを毎日使うエンジニア目線で、情報漏えいにつながりやすいポイントと対策を、実際に起きた事例とあわせて解説します。
- AIに入れてはいけない情報と、学習に使わせない設定
- AIが書いたコードに潜む「実在しないパッケージ」の罠
- Claude CodeやCodexなどのAIエージェントに渡す権限の考え方
- GitHubで秘密情報を漏らさないための設定とチェックリスト
なぜ今、AIとGitHubのセキュリティなのか
生成AIのおかげで、コードを書くのも、資料を作るのも一気に速くなりました。
でもその分、「情報がどこに送られて、どこに残るのか」を意識しないまま、大量の情報を外部サービスに渡すようになっています。
さらに攻撃する側もAIを使います。自然な日本語のフィッシングメールや、それっぽい偽のパッケージを、以前よりずっと安く・大量に作れるようになりました。
「便利になった分、漏れる経路も増えた」というのが今の状況です。

道具が強くなった分、使う側のルールも一段上げないとね。
AIに入力してはいけない情報
実際に起きたこと:2023年、韓国のサムスン電子で、エンジニアが社内のソースコードをChatGPTに貼り付けて相談していたことが問題になりました。入力した内容は外部のサービスに送られるため、同社は社内での生成AIの利用を制限しています。
なぜ問題になるのか:AIに入力した内容は、サービス提供元のサーバーに送られて保存されます。設定やプランによっては、モデルの改善(学習)に使われることもあります。チャットの「共有リンク」を作れば、そのリンクを知っている人なら誰でも読めてしまいます。
入力してはいけないのは、たとえばこんな情報です。
- お客さんの個人情報(名前・住所・メールアドレス・購入履歴など)
- APIキー、パスワード、アクセストークン
- 未公開の社内情報や、社外秘のソースコード
- 契約で「第三者に渡さない」と決まっている情報
対策:
- 学習に使わせない設定にする(ChatGPTは「データコントロール」の「すべての人のためにモデルを改善する」をオフ。Claudeも設定のプライバシー項目で選べます)
- 仕事で使うなら、会社が契約している法人向けプランを使う
- どうしても貼りたいときは、名前やキーをダミーに置き換えてから貼る
- 共有リンクは、用が済んだら削除する

「学習オフ」にしても、送った情報がサーバーに届くことは変わらない。だから「そもそも入れない」が一番大事だね。
AIが書いたコードの落とし穴|存在しないパッケージ
AIにコードを書いてもらうと、ときどき実在しないライブラリを「これを使えばOKです」と自信満々に提案してきます。
実際にわかっていること:2025年に発表された研究では、AIが生成した約57万6,000件のPythonとJavaScriptのコードを調べたところ、約2割に実在しないパッケージが含まれていました。しかも、存在しないパッケージ名の半分以上は、似た質問をすると何度も同じ名前で出てきたそうです。
なぜ危ないのか:「AIが繰り返し提案する、存在しないパッケージ名」がわかれば、攻撃者はその名前で悪意のあるパッケージを先に公開しておけます。開発者がAIの提案どおりに pip install や npm install を実行すると、攻撃者のコードが入ってしまうわけです。この手口は「スロップスクワッティング(slopsquatting)」と呼ばれています。
対策:
- 知らないパッケージは、入れる前に公式サイト・リポジトリ・ダウンロード数・更新日を確認する
- 名前が有名パッケージと1文字違い、というものは特に疑う
- ロックファイル(package-lock.json や composer.lock)をコミットして、勝手に中身が変わらないようにする
AIが書いたコードそのものにも、SQLインジェクションなどの穴が普通に入ります。レビューするときのチェックポイントは、こちらの記事にまとめています。
▶ SQLインジェクションとは?Webアプリの脆弱性9選を実例でやさしく解説

AIの「これが定番です」は、裏を取るまで信じないくらいがちょうどいいよ。
AIエージェントに任せるときの「権限」の考え方
Claude CodeやCodexのように、AIが自分でコマンドを実行したり、ファイルを書き換えたりする「AIエージェント」も一気に普及しました。私もブログの記事投稿を自動化するのに使っています。
▶ 【実践】Claude CodeでWordPressに記事を自動投稿する仕組みを作った話
便利な反面、エージェントはあなたと同じ権限で動くので、渡した権限の範囲で何でもできてしまいます。気を付けたいのは次の点です。
- 本番環境の認証情報を渡さない:本番DBのパスワードや、管理者権限のAPIキーは、作業ディレクトリに置かない
- 専用の弱いアカウントを作る:たとえばWordPressなら、管理者ではなく「投稿者」権限の専用ユーザーを作り、そのユーザーでアプリケーションパスワードを発行する
- 危ないコマンドは自動承認しない:
git push、ファイルの一括削除、本番へのデプロイは、人間が確認してから実行する - 読み込ませる情報を疑う:Webページやファイルの中に「この指示に従え」という文章が仕込まれていて、AIがそれに従ってしまう攻撃(プロンプトインジェクション)があります。知らないサイトの内容を読ませて、そのまま操作させない

エージェントは優秀な新人さんと同じ。いきなり金庫の鍵は渡さないよね。
GitHubで秘密情報を漏らさない
実際に起きたこと:2022年、トヨタ自動車の「T-Connect」で、開発委託先がソースコードの一部を公開設定のままGitHubに上げていたことが発覚しました。コードにはデータサーバーへのアクセスキーが含まれていて、約5年間、誰でも見られる状態に。約29万6,000件のメールアドレスなどが漏えいした可能性があると発表されています。
なぜ起こるのか:
- 非公開のつもりのリポジトリを、公開設定で作ってしまう
- 動作確認のために、コードにキーを直接書いたままコミットする
- 気づいてファイルを消しても、Gitの履歴やフォーク先に残り続ける
対策:
- 秘密情報は
.envに分けて、.gitignoreに入れる - GitHubのpush protectionを有効にする(キーっぽい文字列を含むpushをブロックしてくれる機能)。2024年3月から、個人アカウントで新しく作る公開リポジトリでは最初からオンになっていますが、それより前に作ったリポジトリや非公開リポジトリは、Settingsの「Code security」から設定を確認しましょう
- コミット前に、gitleaksなどのツールで秘密情報が入っていないかチェックする
- もし漏れたら、履歴を消すより先に、そのキーを無効化して作り直す
# .gitignore の例
.env
.env.*
*.pem
*.key
wp-config.php

「公開リポジトリには、見られて困るものは1文字も置かない」。これが一番シンプルなルールだね。
GitHubアカウントそのものを守る
リポジトリの中身だけでなく、アカウントが乗っ取られたら全部終わりです。
- 2段階認証をオンにする(GitHubは2023年から、コードを公開している開発者に2段階認証を順次必須化しています)。パスキーにも対応しています
- 個人アクセストークンは「Fine-grained(細かく権限を絞れる方式)」で、必要なリポジトリ・必要な権限だけ・有効期限つきで発行する
- SSH鍵にはパスフレーズを付ける
- 使っていないOAuthアプリや、連携したまま忘れているサービスを外す
- Dependabotのアラートをオンにして、依存ライブラリの脆弱性を知らせてもらう

トークンの「有効期限なし」「全権限」は、合鍵を作って玄関マットの下に置いてるのと同じだよ。
チェックリスト
最後に、今日からできることをまとめます。
- AIのチャットに個人情報・キー・社外秘を貼っていない
- AIの「学習に使う」設定を確認した
- AIが提案したパッケージは、実在と評判を確認してから入れている
- AIエージェントに本番の認証情報や管理者権限を渡していない
- .env を .gitignore に入れている
- GitHubのpush protectionとDependabotをオンにした
- GitHubの2段階認証をオンにした
- アクセストークンに有効期限と最小限の権限を設定した
まとめ
AIもGitHubも、もはや手放せない道具です。だからこそ、「何を渡しているか」「どこに残るか」を一度立ち止まって確認しておくことが大切です。
- AIには、個人情報・キー・社外秘を入れない
- AIの提案するパッケージとコードは、必ず裏を取る
- エージェントには必要最低限の権限だけ渡す
- GitHubには鍵を置かない。漏れたら即、無効化
個人でできるセキュリティ対策の全体像は、こちらにまとめています。
▶ 個人情報の流出・乗っ取りを防ぐセキュリティ対策まとめ|エンジニアが優先度順に解説

便利な道具ほど、最初にルールを決めておくのが長く付き合うコツだね。

コメント