APIキーをコードリポジトリに誤ってコミットするとどうなる？GitHubのシークレットスキャンの更新から見る2つの処理メカニズムと5つの防止策

著者注：GitHub secret scanning の最新の検出器更新をきっかけに、APIキーをコードリポジトリに誤ってコミットすると何が起きるのか、プラットフォームの検出でどこまでカバーできるのか、そして開発者自身にどんな対策が必要なのかを解説します。

2026 年 11 月 5 日、GitHub は changelog で secret scanning の更新を発表しました。SpaceX が新たなシークレットスキャンパートナーとなり、Starlink キーの検出器が追加されるとともに、Alibaba Cloud、AWS、Google、Tencent Cloud など複数の検出器に誤検知フィルターが導入されました。短い更新ですが、多くの開発者が十分に考えたことのない問題を浮き彫りにしています。APIキーをコードに書き込んでリポジトリにプッシュした後、いったい何が起きるのでしょうか？

これは不安をあおるためのセキュリティ解説ではありません。本記事の事実関係は GitHub の公式 changelog に基づいています。プラットフォームによる検出後の 2 つの処理方法を解きほぐし、検出がカバーできる範囲とできない範囲を明らかにしたうえで、AIモデルの APIキーを日常的に守る方法と、漏えい後の対処法を紹介します。

この記事のポイント：GitHub secret scanning がキーの種類によってどう異なる対応をするのかを 3 分で把握し、自分で防ぐ必要のあるリスクを知ることができます。そのまま使える環境変数の記述例と緊急時のチェックリストも紹介します。

GitHub secret scanning 今回のアップデートの要点

今回のアップデートは、新しいパートナーの参加、検出器の追加、既存の検出器における誤検知フィルタリングの改善の3点にまとめられます。changelog の主な内容は以下のとおりです。

secret scanning の誤検知フィルタリングの改善

誤検知フィルタリングは技術的に聞こえますが、アラートが「確認する価値のあるものかどうか」を直接左右します。アラートが多すぎて本物と誤検知が入り混じると、チームは次第にアラートを無視するようになり、本当の漏えいが埋もれてしまいます。今回の各検出器の改善内容は以下のとおりです。

ここでいう「ペア」について、もう少し説明します。クラウド事業者のアクセスキーは通常、Key ID と Secret で構成され、ID だけでは完全な認証情報にならないことがほとんどです。周辺で見つかった「ペアとなるキー」の候補が、ランダムな文字列に見えるだけの普通の単語ばかりであれば、その ID はサンプルか、偶然一致しただけの可能性が高くなります。そのような検出を抑制することで、不要なアラートを減らせます。

APIキーを誤ってコミットした場合の2つの対応フロー

changelogには、重要な説明があります。パートナーのキーが公開リポジトリで見つかると、キーの発行元に自動的に報告されます。一方、ユーザーキーが公開またはプライベートリポジトリで見つかった場合は、secret scanningのアラートが生成されます。この2つのフローでは、対応する主体が異なります。

図の説明：フローチャートは、プラットフォームによる検出後の2つのフローと、1つの「盲点」を示しています。AIのモデル呼び出しなどでは、キーを環境変数にまとめて保存し、APIYI apiyi.comのようなトークンの一元管理に対応したプラットフォームで利用状況を確認することをおすすめします。キーが複数の場所に散在することによる調査の手間を減らせます。

パートナーのキー：発行元に通知して対応

SpaceXのようなパートナーのキーが公開リポジトリに現れると、GitHubはそのパートナーに通知します。パートナーは、キーが悪用される前に認証情報を取り消すか、ローテーションできます。この仕組みの利点は、開発者が気づいて対応することに依存しない点です。コミットした本人がまったく気づいていなくても、発行元が早期に被害を抑えられる可能性があります。

ただし、適用条件には注意が必要です。対象はパートナープログラムに参加しているプロバイダーのキーで、公開リポジトリに限られます。プライベートリポジトリ内のパートナーのキーは、この通知フローの対象外です。

ユーザーキー：アラートを生成し、自分で対応

ユーザーキーの場合は、通知を受けた側が自分で対応する仕組みです。検出されると、プラットフォームはリポジトリにsecret scanningのアラートを生成します。公開リポジトリとプライベートリポジトリのどちらでも検出される可能性がありますが、具体的な有効化条件や閲覧できる範囲についてはGitHubの公式ドキュメントを確認してください。アラートが生成されただけではキーは無効にならないため、被害を抑えるにはリポジトリの責任者が認証情報をローテーションする必要があります。

APIキー漏洩の検出範囲：プラットフォームはどこまでカバーできるか

「プラットフォームが自動スキャンしてくれる」と聞いて安心する開発者は多いものです。しかし、それは非常に危険な誤解です。secret scanningは安全網であって、ファイアウォールではありません。その検出範囲には、いくつかの限界があります。

1つ目の限界は、サポート対象リストです。今回のchangelogには、OpenAIやAnthropicなどのモデル提供元のキーの種類は記載されておらず、各種API集約プラットフォームのトークンにも言及していません。それらがGitHubのサポート対象リスト全体に含まれているかどうかは、GitHubのドキュメントで確認する必要があります。確認できるまでは、「検出されない」と考えておくのが最も安全です。

2つ目の限界は、検出までのタイムラグです。公開リポジトリ内のキーは、自動化スクリプトによって非常に短時間で取得される可能性があります。プラットフォームによる検出から発行元による無効化までには、必ず時間差があります。最終的にキーが無効化されたとしても、その間に発生した呼び出し料金やデータへのアクセスは取り消せません。

3つ目の限界は、Gitの履歴です。漏洩に気づいたとき、まず該当する行を削除して再コミットする人は少なくありません。しかし、古いコミット内のキーは履歴に残ったままです。ツールで履歴を書き換えたとしても、すでにリポジトリをクローンした人の手元にはコピーが残っています。そのため、「先にキーをローテーションし、その後で履歴をクリーンアップする」のが正しい順序です。

AIモデルのAPIキー漏洩対策クイックスタート

大規模言語モデルを呼び出すアプリでAPIキーが漏洩すると、まず問題になりやすいのが請求額の異常です。第三者があなたのキーを使って大量のリクエストを送ると、その費用があなたに請求されます。ここでは、基本となる環境変数の使い方から紹介します。

最小限の例：環境変数からAPIキーを読み込む

import os
import openai

client = openai.OpenAI(
    api_key=os.environ["APIYI_API_KEY"],      # 環境変数から読み込み、コードにハードコードしない
    base_url="https://api.apiyi.com/v1"       # OpenAI互換インターフェース
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "你好"}]
)
print(resp.choices[0].message.content)

あわせて、プロジェクトのルートディレクトリにある .gitignore に .env を追加し、プレースホルダーだけを含む .env.example を共同開発者向けに用意しましょう。これにより、誤って git add . を実行しても、実際のAPIキーがステージングされるのを防げます。

import os
import logging
from typing import Optional

import openai
from dotenv import load_dotenv  # pip install python-dotenv

logging.basicConfig(level=logging.INFO)
load_dotenv()  # ローカルの .env を読み込む。本番環境ではデプロイ先の秘密情報管理機能を推奨


def mask_key(key: str) -> str:
    """ログには前後の数文字だけを残し、キー全体が記録されるのを防ぐ"""
    if len(key) <= 8:
        return "****"
    return f"{key[:4]}****{key[-4:]}"


def get_client() -> openai.OpenAI:
    api_key: Optional[str] = os.getenv("APIYI_API_KEY")
    if not api_key:
        raise RuntimeError("未找到 APIYI_API_KEY，请在环境变量或 .env 中配置")
    logging.info("使用密钥: %s", mask_key(api_key))
    return openai.OpenAI(
        api_key=api_key,
        base_url="https://api.apiyi.com/v1",
    )


def chat(prompt: str, model: str = "gpt-4o-mini", max_tokens: int = 500) -> str:
    client = get_client()
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": prompt}],
            max_tokens=max_tokens,
        )
        return resp.choices[0].message.content
    except openai.AuthenticationError:
        # キーの失効・ローテーション時は、キーを表示せずに設定の更新を促す
        return "鉴权失败：密钥可能已失效，请检查并更新配置"
    except Exception as e:
        return f"调用失败: {type(e).__name__}"


if __name__ == "__main__":
    print(chat("用一句话解释什么是密钥轮换"))

🚀 クイックスタート：プロトタイプを検証するなら、APIYI apiyi.com でAPIキーと無料テスト枠を取得し、上記の環境変数を使う方法ですぐに接続できます。1つのキーでOpenAI、Claude、Geminiなどの主要モデルを切り替えて呼び出せるため、複数の事業者ごとにキーを管理する手間も減らせます。

APIキーの漏洩を防ぐ5つの日常的な対策

中でも「用途別のキー分割」と「使用量の監視」は、初心者が見落としがちな対策です。すべての用途で1つのキーを使っていると、漏洩した際にすべてのサービスを停止してキーを交換するしかありません。キーを分けておけば、問題が発生したキーだけを交換できます。

APIキー漏えい後の緊急対応と影響分析

キーがリポジトリにコミットされていると判明したら、secret scanning の警告、発行元からの通知、コードを確認していて自分で発見した場合のいずれであっても、次の順序で対応しましょう。

1. 直ちに古いキーを無効化する：キー発行元のコンソールで、漏えいしたキーを削除または無効化します。これが被害を食い止めるために唯一確実な対応です。
2. 新しいキーを生成してデプロイを更新する：新しいキーを環境変数またはシークレット管理システムに登録し、サービスを再デプロイします。
3. 使用量と請求を確認する：漏えい期間中に不審な呼び出し、見覚えのないモデルの使用、料金の急増がないか確認します。
4. Gitの履歴をクリーンアップする：キーのローテーションが完了してから、履歴を書き換えるツールで古いコミットをクリーンアップし、共同作業者に再クローンを通知します。
5. 振り返りを行い、対策を追加する：.gitignore の設定やコミット前のスキャンなどを導入し、同じ問題の再発を防ぎます。

APIYIを通じてモデルを呼び出しているプロジェクトでは、コンソールでトークンと使用量を確認できます。異常な使用量が見つかった場合は、該当するトークンへの対応を優先しましょう。トークンの削除、再作成、利用上限の設定などの具体的な操作は、コンソールで実際に提供されている機能を確認してください。トークンに利用上限を設定できる場合は、作成時に設定しておくのがおすすめです。漏えいリスクに備える「安全装置」になります。

開発者への影響

• 警告の精度が向上：誤検知のフィルタリングによって、AWS、Alibaba Cloud、Tencent Cloudなどの一般的なクラウド認証情報に関する警告の信頼性が高まり、チームも一件一件の警告に真剣に対応しやすくなります。
• 検出を最後の頼みの綱にしない：AIモデルのキーがサポート対象に含まれているかは、自分で確認する必要があります。確認できるまでは「プラットフォームは検出してくれない」と考えましょう。
• 対応の順序を見直す必要がある：コードを削除するだけではなく、まずキーをローテーションしてから履歴をクリーンアップします。

業界への影響

• パートナープログラムが拡大を続ける：クラウド事業者からSpaceXのような新たな顔ぶれまで、キーを発見したらサービス提供元に引き渡す仕組みに参加する事業者が増えています。これにより、公開リポジトリでキーが露出する時間はさらに短くなることが期待されます。
• 検出の重点が「多く報告する」から「正確に報告する」へ：今回の変更の多くは誤検知の削減に集中しており、プラットフォームがカバー範囲の拡大だけでなく、警告に基づいて実際に対応できることをより重視し始めていることが分かります。

よくある質問 FAQ

APIキー漏えいと GitHub secret scanning の重要ポイント

• 2つの仕組み：公開リポジトリ内のパートナー発行キーは発行元に通知され、ユーザー向けのキーはアラートが生成されてユーザー自身が対応します
• 今回の更新：SpaceX がパートナーに加わり、6社の検出器に誤検知フィルターが追加され、アラートの精度が向上しました
• 検出の限界：サポート対象リストにないキーは識別できず、フロントエンドの生成物、ログ、スクリーンショットもスキャン対象外です
• 時間との勝負：スキャンで露出時間は短縮できますが、すでに取得されたキーを取り戻すことはできません
• 対応の順序：まずキーを無効化してローテーションし、次に使用量を確認してから、Git 履歴をクリーンアップします
• 始め方：APIYI apiyi.com で取得したキーを環境変数で管理し、環境ごとに分けて使用量を確認します

まとめ

今回の GitHub secret scanning の更新から、3つのポイントが見えてきます。

1. プラットフォームの検出力は向上している：パートナーが増え、誤検知が減ることで、公開リポジトリでキーが露出する時間が短くなっています。
2. 検出は防御と同じではない：サポート対象リストにないキーや、リポジトリ以外からの漏えいは、プラットフォームではカバーできません。
3. 被害を抑えるにはローテーションが重要：漏えいしたら、まず古いキーを無効化します。コードの削除や履歴のクリーンアップはその後に行います。

大規模言語モデルをアプリケーションに組み込む開発者にとって、最も現実的なのは、最初の1行からキーを環境変数で管理し、環境ごとに別のキーを用意することです。APIYI apiyi.com を使えば、この接続方法を手軽に試せます。1つのキーで複数の主要モデルを呼び出せるうえ、一元管理によって使用量の確認も容易になります。

📚 参考資料

1. GitHub Changelog – Secret scanning upgrades detectors， adds SpaceX as partner：今回のアップデートに関する公式説明
2. リンク： github.blog/changelog/2026-11-05-secret-scanning-upgrades-detectors-adds-spacex-as-partner

3. 内容： 新たなパートナー、検出器、誤検知フィルタリングの改善点を網羅した一覧

4. GitHub Docs – Secret scanning：機能の説明と対応対象の完全な一覧

5. リンク： docs.github.com/code-security/secret-scanning
6. 内容： 特定の種類のキーがサポートされているか、またアラートが有効になる条件を確認できます

著者：APIYI 技術チーム
技術交流：トークン管理や使用量の確認について詳しく知りたい方は、APIYI 公式サイトのトップページからお気軽にお問い合わせください