GitHub Advanced Securityとは？機能・料金・使い方を徹底解説

GitHub Advanced Security（GHAS）は、GitHub本体に統合されたセキュリティ機能群で、コード脆弱性・シークレット漏洩・依存関係の問題を開発フローの内側で検出・修正します。

2025年4月にはGHASが「GitHub Secret Protection」（$19/月・active committer）と「GitHub Code Security」（$30/月・active committer）の2製品に分離し、従来Enterprise契約が必須だった機能をGitHub Teamプランでも購入できるようになりました。

本記事では、2製品の機能内訳・Copilot Autofixの効果測定・料金体系・導入手順・Snyk/SonarQube等の他社ツールとの比較・選定で見落としやすい観点までを、2026年7月時点の最新情報で体系的に解説します。

GitHub Advanced Securityとは？Secret ProtectionとCode Securityに分かれた2製品体制

GitHub Advanced Security（GHAS）とは、GitHub本体に統合された開発フロー組み込み型のセキュリティ機能群です。

コード脆弱性・シークレット漏洩・依存関係の問題を、開発者がプルリクエストを書いている段階で検出し、そのままGitHub上で修正まで完了させる設計になっています。

2025年4月1日、GHASはSecret Protection・Code Securityの2製品に分離され、それまでEnterprise契約が必須だった機能がGitHub Teamプランからでも個別購入可能になりました。

「シークレット漏洩をまず止めたい組織」はSecret Protection、「コード脆弱性対策を主軸に据えたい組織」はCode Securityという選び方が可能な構成です。

単一SKUから2製品への分離とその意味

GHASは2025年4月の分離まで単一SKUで「機能一式を$49/月で導入する」構成でした。
シークレット漏洩対策だけ欲しい組織にとってはコード解析まで込みの料金構造がハードルになっていましたが、分離後は組織の優先課題に合わせて片方だけ導入・段階的追加が可能になっています。

• GitHub Secret Protection
  Push Protection・Secret Scanningなどのシークレット漏洩阻止レイヤー。$19/月・active committer
  
  

• GitHub Code Security
  Code Scanning・Copilot Autofixなどのコード脆弱性対策レイヤー。$30/月・active committer

ここでのポイントは、シークレット対策と脆弱性対策を別々に予算化できるようになった、という点です。

各製品の詳細機能・料金内訳は、後段のセクションで詳しく整理します。

GitHub Secret Protection　——　シークレット漏洩を「発生前に止める」層

GitHub Secret Protection（$19/月・active committer）は、APIキー・アクセストークン・DBパスワードといったシークレットがリポジトリに紛れ込む前後で検出・遮断する機能群です。開発者が誤って認証情報をコミットしたとき、これを本番稼働中の資産として悪用させないためのレイヤーが集約されています。

本セクションでは、Secret Protectionが持つ主要機能を1つずつ整理し、それぞれの導入インパクトを解説します。

Push Protectionによるコミット段階の遮断

Push Protectionは、開発者が「git push」を実行したタイミングでコミット内容をスキャンし、シークレットが検出された場合にpushそのものを止める機能です。

従来のSecret Scanningが「漏洩したものを事後に検出する」設計だったのに対し、Push Protectionは「漏洩そのものを発生させない」ためのゲートとして機能します。

公式のsupported patterns一覧では、現時点で500以上の対応パターンが掲載されており、AWS・Azure・GCPの主要クラウドプロバイダーの認証情報はもちろん、SlackボットトークンやStripeシークレットキーなども検出対象です。

2026年6月には新パートナー統合・Push Protection既定範囲の拡張・validity checks追加が公式Changelogで発表され、「漏洩した資格情報がまだ有効かどうか」まで開発者が即座に判別できるようになりました。有効なcredentialsが優先的にダッシュボードで強調表示されるため、トリアージの初動速度が上がります。

Secret Scanningによる履歴全体の監視

Secret Scanningは、現在のブランチだけでなくgit履歴全体をスキャンして漏洩したシークレットを検出する機能です。過去のコミットに紛れ込んだ古いAPIキーが、リポジトリを公開した瞬間に脅威になるケースを防ぎます。

2026年3月には、15プロバイダー・28検出器の追加・39件のPush Protection既定化・validity checks追加が公式Changelogで発表されました。

GitHub側では検出対象のsecret typeが継続的に拡張されており、AIコーディングエージェント経由のクレデンシャル漏洩など新たな攻撃面にも対応範囲が広がっています。

また、validity checks（有効性チェック）を通じて、検出されたシークレットが「まだアクティブか」を判別できます。

対応するパターンでは、オーナー識別子や発行元メタデータが追加で表示される場合もあります（対応可否はsecret typeや提供元パートナーごとに異なる）。「誰が発行したトークンで」「まだ生きているのか」を待たずに判定でき、緊急度の高いものから対応できます。

Copilot Secret Scanningの非構造化検知

正規表現ベースの従来型検知では、構造化されていないパスワードや任意形式のトークンは取りこぼしがちでした。Copilot Secret Scanningは、GitHub CopilotのAI能力を利用して、非構造化シークレット（パスワード・独自認証文字列など）を検出します。

これは特に、開発者が自作したカスタム認証システムや、社内ツールから漏れ出す独自トークンに対して効果を発揮します。パターンマッチだけでは追いつかない領域を、AIによる文脈判断で補う設計です。

Custom Patternsで組織固有のシークレットを検出

自社独自の秘密情報（社内サービスのトークン、独自暗号化キーなど）は、GitHubのデフォルト検出パターンに含まれません。Custom Patternsは、組織側で正規表現ベースのカスタム検出ルールを追加できる機能です。

「社内で共有しているサービス連携用のトークン」「独自形式のセッションキー」といった組織固有の資産を、GitHubの検出ロジックに載せられます。金融機関・製造業など、独自認証システムを持つ企業ほど価値が高い機能です。

Delegated Bypassで誤検知対応を統制

Push Protectionが誤検知（False Positive）を出したとき、開発者が独断でスキップできてしまうと、Push Protectionの意味が薄れます。Delegated Bypassは、「Push Protectionを回避したい」という要求をレビュー承認フローに載せる仕組みです。

セキュリティ管理者側で「誰が承認できるか」を設定でき、開発者はbypassリクエストを発行してレビューを受けます。2025年12月にはEnterprise Teamsとorg rolesにも対応が広がり、大規模組織でもガバナンスを保ちながらPush Protectionを運用できるようになりました。

Security Campaignsで蓄積アラートを一括対応

Security Campaignsは、Secret ProtectionとCode Securityの両側で使える機能で、蓄積した過去のアラートに対して「キャンペーン」を作成し、担当者を割り当てて一括対応する仕組みです。Secret Protection側では、リポジトリ横断で発見された数百件規模のシークレット漏洩に対し、優先順位を付けて短期間で片付ける運用ができます。

「気づいてはいるが手が回らない」古いアラートを、キャンペーン化して集中対応するのが典型的な使い方です。

GitHub Code Security　——　コード脆弱性を「検出」から「修正」まで押し込む層

GitHub Code Security（$30/月・active committer）は、コード自体に潜む脆弱性を検出し、Copilot Autofixで修正提案を生成する機能群です。

CodeQLによる静的解析エンジン、AIによる修正提案、Security Campaigns、Dependabotの拡張などが1つのアドオンにまとめられています。

本セクションでは、Code Securityが持つ主要機能を整理し、Secret Protectionとどう役割が違うのかを解説します。

Code Scanning（CodeQL）による静的解析

Code Scanningは、GitHubが2019年に買収したSemmleのCodeQL技術をベースにした静的アプリケーションセキュリティテスト（SAST）機能です。SQLインジェクション・クロスサイトスクリプティング（XSS）・パストラバーサルなどの脆弱性パターンを、コード構造の意味を理解したうえで検出します。

CodeQLの強みはセマンティック解析にあり、単純な正規表現やパターンマッチではなく「入力値がどこから来て、どのAPIに渡されるか」というデータフローを追跡します。

false positive率を下げつつ、実際に悪用可能な脆弱性を優先的に検出できる設計です。

公式CodeQLドキュメントによれば、対応言語はC/C++・C#・Go・Java/Kotlin・JavaScript/TypeScript・Python・Ruby・Rust・Swift、およびGitHub Actions workflowsです。

PHPやShell・Dockerfile・TerraformなどのInfrastructure as Code系はCodeQLネイティブでは非対応で、これらを扱う場合は第三者SASTツールのSARIF連携などGHASの外側にある枠組みで検出結果を取り込む形になります。

Copilot Autofixが修正提案を生成

Copilot Autofixは、**CodeQLが検出した対応alertに対して、GitHub Copilotが修正提案を生成する機能**です。開発者は「Generate fix」ボタンで修正提案を受け取り、必要に応じてCommit autofixで直接適用するか、Copilot cloud agentにPR作成を依頼する形で運用します。対応alertはCodeQLクエリのうち一部で、全てのalertでAutofixが提案されるわけではありません。

効果測定については本記事の別セクションで詳述しますが、公開ベータ期間の集計では中央値28分でPRレベルのalertを解決（手動比較で1.5時間・3倍高速化）という結果がGitHubブログで報告されています。

Security Campaignsで最大1000件をキャンペーン化

Code Security側のSecurity Campaignsは、最大1000件の履歴コードスキャンalertをキャンペーン化し、担当者を割り当てて計画的に片付ける機能です。

キャンペーン内の各alertには対応可能な範囲でCopilot Autofixの修正提案が付与され、開発者がその提案をCommit autofixで適用するか、Copilot cloud agentにPR化を依頼するかを選べます。

「セキュリティ負債」と呼ばれる、過去に検出されたが手を付けられずに残っているalertを、まとめて修正フローに載せられます。

個別対応が難しかった数百件規模のalertに対し、キャンペーン作成手順に従って担当者を割り当てることで、修正率を短期間で引き上げる運用が可能です。

Dependabot Custom Auto-triageによる自動振り分け

Dependabot自体は無料で使える依存関係監視機能ですが、Code SecurityではCustom Auto-triageルールを設定して、大量のDependabot alertを優先度別に自動振り分けできます。

「本番環境で使っているprod依存だけをHighに」「dev依存はLowに落として自動クローズ」といったルールを組織側で設計でき、開発者が対応すべきalertだけを絞り込めます。

中規模以上のプロジェクトでDependabotを運用していると、alertが日々数十件単位で増えるため、この振り分け機能が実質的な運用可能性を左右します。

Dependency ReviewでPR時に依存追加を審査

Dependency Reviewは、プルリクエスト上で追加された依存パッケージのライセンス・脆弱性状況を可視化する機能です。マージ前に「このライブラリは既知の脆弱性を持っているか」「ライセンスは自社ポリシーに準拠するか」を確認できます。

新しいライブラリを気軽に追加してしまう開発者に対して、レビュー段階で判断材料を提示できるため、依存関係管理を「事後の棚卸し」から「事前のガードレール」に移せます。

Copilot Autofixの実力と限界——効果測定データと対応言語

GHASの中でもCopilot Autofixは、他社製品との差別化に直結する目玉機能です。「脆弱性を検出する」だけの静的解析ツールと違い、AIが修正コードを提案してPRまで作る設計は、開発者の実装工数を大きく変えます。

本セクションでは、Copilot Autofixの効果測定データ・対応言語・限界を整理します。

公開ベータでPR時alertを中央値28分で解決

GitHubは2024年5〜7月の公開ベータ期間に、Copilot Autofixが有効なリポジトリで検出された新規CodeQL alertについて、実際に修正がコミットされるまでの時間を計測しました。

以下の表で、手動修正とAutofix利用時の差を整理します。

この差が大きく出るのは、Autofixが「脆弱性を検出したうえで、修正コードのdiffまで提案する」ためです。開発者は「どこが脆弱か」を理解する時間と「どう直すか」を考える時間の両方を圧縮できます。

Optum社の主任エンジニア Kevin Cooper氏は、Copilot Autofix導入後にセキュリティ関連コードレビュー時間が60%削減、全体開発生産性が25%向上したと報告しています。

個人単位の生産性ではなく組織全体の指標に効いてくる点が、大規模開発チームにとって重要です。

Copilot Autofixが対応する言語

Copilot Autofixの修正提案生成は、CodeQLが検出できる言語のうち以下がサポート対象です。

• C#、C/C++、Go、Java/Kotlin、JavaScript/TypeScript、Python、Ruby、Rust、Swift

対応言語であっても、Autofix提案は「対応CodeQLクエリ由来のalertに限る」best-effort運用です。PHP・Shell・Dockerfile・TerraformなどのIaC系はCodeQLネイティブでは非対応で、Autofixの修正提案生成も対象外です。

IaC領域を扱いたい場合は、tfsec・checkov等の第三者SASTツールの結果をSARIFでCode Scanningに取り込み、GHASのアラート管理面のみを共通化する運用が現実的です。

Copilot Autofixが万能ではない領域

一方で、Copilot Autofixはbest-effortベースで動作します。

GitHub公式は責任ある利用ガイドの中で、「全てのalertに対して修正を生成できるわけではない」と明示しています。

具体的には以下のようなケースで、修正提案が生成されない・または不完全なコードが生成される可能性があります。

• 修正に大規模なアーキテクチャ変更が必要なケース（データフロー全体の再設計を要する脆弱性など）
• テストコードやモック実装の中で検出されたalert（本質的にAutofixが「直す必要のないコード」を書き換えてしまう）
• 独自DSL・独自ライブラリを多用したコード（Copilotの学習範囲を超える）

Autofixが提案するdiffは必ず開発者がレビューしたうえでマージする運用が前提です。「Autofixが生成した修正PRをそのままauto-mergeする」設計はGitHubも推奨していません。

AI総研の支援現場では、Autofixが生成した修正PRを人間レビューに載せる際、「同じalert種類に対してAutofixが繰り返し似たようなdiffを生成する」ケースが多いという知見を得ています。

定型的な脆弱性（SQLi・XSS・パストラバーサル）はAutofixで大幅に高速化できる一方、アーキテクチャに関わる脆弱性は依然として開発者の判断領域として残ります。

GitHub Advanced Securityの料金体系——active committer課金と2製品のSKU

GHASの料金は、「active committerあたりの月額」で製品ごとに課金される構造です。

本セクションでは、料金プランの内訳・active committer課金の仕組み・パブリックリポジトリでの無料範囲を整理します。

Secret ProtectionとCode Securityの料金

2製品の料金は以下のとおりです。

両方を購入した場合の実効単価は分割前のGHAS単一SKU（$49/月）と同水準ですが、片方だけを選べる柔軟性が新体制の本質的な価値です。

「シークレット漏洩だけまず止めたい」組織はSecret Protectionだけを$19で導入でき、後からCode Securityを追加する形にできます。

active committer課金の仕組み

GHASの課金モデルは月額固定ではなく、過去90日以内にpushされたコミットを持つユニークユーザー数でカウントされます。

GitHub公式ドキュメントでは、active committerを『GHASが有効なリポジトリに、過去90日以内にpushされたコミットがあるユニークなactive committer』と定義しています。

つまり、以下のようなケースで課金額が動きます。

• 新規参画メンバーがGHAS有効リポジトリにpushすると、90日窓に入るため課金対象に含まれる可能性がある
• リポジトリで最後にpushされたコミットから90日が経過したcommitter は課金対象から外れる
• 1人の開発者が複数のGHAS有効リポジトリにpushしても、その組織全体で1人としてカウント

予算計画上のポイントは、「登録ユーザー数」ではなく「過去90日窓のユニークpush実績」で課金されることです。

100人の開発チームでも、直近90日でGHAS有効リポジトリに一度もpushしていない開発者は課金対象に含まれません。実効コストは月次で変動するため、後述するAdvanced Security billing insightsで実績を継続的にモニタリングする必要があります。

パブリックリポジトリの無料範囲

パブリックリポジトリでは、機能ごとに「無料範囲」と「デフォルト挙動」が異なります。以下の3点を切り分けて理解しておく必要があります。

• Secret Scanning: パブリックリポジトリに対して自動で無料実行される
• ユーザー単位のPush Protection: パブリックリポジトリへのシークレットpushをデフォルトで止める（公式docs参照）
• Code Scanning（CodeQL）: パブリックリポジトリで無料利用できるが、リポジトリ側で有効化設定が必要（公式docs参照）

オープンソースプロジェクトのメンテナーは、GHASの契約なしにこれらの機能を使い続けられます。

ただし「Push protection for repositories」（リポジトリ単位のpush protection）はSecret Protection契約が必要で、こちらはパブリックでもデフォルト無効です。

一方、プライベートリポジトリと社内リポジトリではSecret Protection・Code Securityの契約が必須です。

パブリックとプライベートを混在させているアカウントの場合、パブリック側は無料・プライベート側は有料という切り分けになります。

GitHub Teamプラン購入可の意味

2025年4月の製品分離により、GitHub Teamプラン（$4/ユーザー/月）でもSecret ProtectionとCode Securityが購入できるようになりました。

分割前は「GHASを使うにはGitHub Enterprise Cloud（$21/ユーザー/月）契約が必須」で、Enterprise契約のライセンス費と合わせるとハードルが高い構造でした。

Teamプラン購入可になったことで、中小規模開発チーム（数十名程度）でもGHASを試験導入できるようになっています。

「GHASを使いたいがEnterpriseへの切り替えは重い」という組織が、Teamプランのままセキュリティ強化を進められる選択肢が生まれました。

GitHub Advanced Securityの導入手順

GHASの導入は、Secret ProtectionとCode Securityそれぞれの有効化フローに分かれます。本セクションでは、実際にリポジトリでGHASを使い始めるまでのステップを整理します。

GHASの購入とリポジトリ有効化

GHASの契約は、Organization設定のBillingセクションから行います。GitHub Team・Enterprise Cloudのいずれかのプランに追加する形で、Secret Protection・Code Securityを個別または同時に購入します。

契約後、Organization設定のCode security and analysisでリポジトリごとに機能を有効化します。「All new private repositories」を選択すれば、今後作成されるリポジトリに自動的にGHASが適用される設定も可能です。

Secret Protectionの有効化フロー

Secret Protectionは、有効化ボタンを押すだけで即座に稼働します。Push Protectionを最初に有効化することで、これから発生するシークレット漏洩を止められます。

続いてSecret Scanningを有効化し、既存のgit履歴を対象にスキャンを実行します。過去のコミットに紛れ込んだシークレットが検出されるため、検出されたalertはSecurity Campaignsで担当者を割り当てて一括対応する流れです。

Copilot Secret Scanningは、非構造化シークレット（パスワード等）の検出精度を上げる補助機能として、Secret Scanningと同時に有効化しておくのが標準的な運用です。

Code SecurityとCodeQL setupの選択

Code Securityの導入では、CodeQL analysisの設定がメインです。Organization設定の「Code security and analysis」で「Default setup」を選ぶと、GHAS側が自動的にCodeQL workflowを生成してくれます。

Advanced setupを選ぶ場合は、リポジトリの「.github/workflows/」に配置するYAML（「codeql-analysis.yml」）を直接編集します。以下のようなワークフロー定義で、pushとPR時にCodeQLが自動実行されます。

name: "CodeQL"
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  schedule:
    - cron: '0 0 * * 1'
jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    strategy:
      matrix:
        language: [ 'javascript', 'python' ]
    steps:
    - uses: actions/checkout@v4
    - uses: github/codeql-action/init@v3
      with:
        languages: ${{ matrix.language }}
    - uses: github/codeql-action/analyze@v3

このワークフローは、mainブランチへのpush・PR・週次スケジュールでCodeQL解析を実行します。

Default setupを選べばこのYAMLは自動生成されるため、多くの組織はまずDefault setupから始めるのが標準的な導入経路です。

Copilot Autofixで既存alertを片付ける

Code Scanningを有効化すると、既存コード全体を対象にした初回スキャンが走り、大量のalertが検出されます。ここでSecurity Campaignsを作成して担当者にalertを割り当て、対応可能な範囲でCopilot Autofixの修正提案を受け取りながら計画的に片付けていきます。

キャンペーン作成時は、優先度の高いalert（例：本番環境のリポジトリ、Critical severityの脆弱性）から絞り込むのが実務的です。全てのalertを同時に処理しようとすると、開発者側のレビュー負荷が過剰になります。

DependabotとDependency Reviewの設定

Dependabotは「.github/dependabot.yml」で有効化します。Code SecurityのCustom Auto-triageルールをOrganization設定で追加し、依存関係alertを優先度別に自動振り分けする設定を入れます。

Dependency Reviewは、PR上で自動的に動作するため追加設定はほぼ不要ですが、Organization設定で「特定のライセンスを持つ依存を拒否する」ポリシーを事前に定義しておくと、レビュー時の判断が明確になります。

他社セキュリティツールとの比較——Snyk・SonarQube・Dependabot単体との判断軸

GHASの選定では、Snyk・SonarQube・Dependabot単体などの他社ツールとの比較が避けられません。本セクションでは、それぞれの守備範囲と選定軸を整理します。

主要製品との機能比較

以下の表で、GHAS（Secret Protection + Code Security）・Snyk・SonarQube・Dependabot単体の特性を整理しました。

この比較から分かるのは、「GitHubを主要リポジトリとして使っている組織」ならGHASが最も統合コストが低いという点です。

SnykやSonarQubeはGitLab・Bitbucketなど他社リポジトリにも対応する強みがある一方、GitHub上での動作は「連携設定が必要」であり、GitHub Actionsに深く統合されたGHASと比べるとCI/CD設計の手間が増えます。

ケース別の選定軸

3つの典型ケース別に、選定軸を整理します。

• GitHubを主要リポジトリとして使っており、CI/CDもGitHub Actions中心
  GHASが第一候補。他社ツールと統合するコストを払わずに、PRチェック・Autofix・Security Campaignsまで一気通貫で扱える。
  
  

• GitHubとGitLabまたはBitbucketを併用している開発体制
  Snykが有力候補。複数リポジトリプラットフォームを横断してAppSec機能を統一できる。GHASを併用する場合は「GitHub側はGHAS・他リポジトリはSnyk」の切り分けが必要。
  
  

• 静的解析の品質を最優先し、脆弱性検出だけでなくコード品質も同時に見たい
  SonarQubeが有力候補。Code smellsやtech debtの分析が強く、SASTツールとしては業界最大の導入実績を持つ。シークレットスキャン・AI CodeFix・SCA拡張はSonarQube Advanced Security等のプランに含まれる形で提供される。

AI総研の実装支援経験では、GitHub Enterprise Cloudに移行済みの組織はGHASを選ぶケースが多く、既存でSnyk・SonarQubeを長年運用している組織は「GHASに置き換える工数が正当化できるか」を細かく検討する傾向があります。

既存契約のsunk costと、GHASの統合メリットを天秤にかける判断が必要です。

GHAS for Azure DevOpsの対応状況

2026年6月には、GitHub Advanced Security for Azure DevOpsでCopilot Autofixが限定プライベートプレビューに入りました。

CodeQLで検出したalertに対して「Generate fix」ボタンでAIによる修正提案を生成し、PRとして扱える設計で、利用には対象組織としての事前登録と段階的な有効化が必要です。

Azure DevOps環境を使っている組織にとっては、GHAS本体の機能をGitHub外で使う経路が正式に整いつつあります。
「開発ツールをGitHubに全面移行するのは重いが、AppSec機能だけAzure DevOps上で使いたい」というケースの選択肢として現実的になってきました。

GitHub Advanced Security選定・移行で見落としやすい観点

GHASの選定で失敗しがちな論点は、機能一覧の比較よりも**「どちらのSKUを先に入れるか」「active committerの実効課金」「他契約との整合」**にあります。

本セクションでは、SIerとしての支援現場から見えるケース別の判断軸を整理します。

Secret先行かCode先行か、業態別の判断軸

2製品体制になった以上、まず問われるのは「どちらを先に導入するか」です。ケース別の推奨は以下のとおりです。

• 公開リポジトリを持つSaaS事業者・OSSメンテナー
  Secret Protection先行が第一候補。「今すぐシークレット漏洩を止めたい」ニーズが強く、Push Protectionを入れるだけで漏洩リスクが即日下がる。Code Securityの導入は、Secret Protectionの運用が落ち着いてから追加検討で十分。
  
  

• 金融・製造業などレガシーコードベースを抱える企業
  Code Security先行が第一候補。長年蓄積された脆弱性がSecurity Campaignsで一括修正できるインパクトが大きい。「セキュリティ負債の見える化と削減」が最初のKPIになる。Secret Protectionは並行導入が理想だが、優先度としては後回しでも構わない。
  
  

• GitHub Copilot Enterpriseを既に導入している開発チーム
  両方の同時導入を推奨。Copilot AutofixはGitHub Copilot Enterpriseの一部機能と重なるため、投資効果を測るうえで両方が揃っている状態がベースラインになる。

「まず何を止めたいか」「どこの負債が痛いか」を組織側で明確にできれば、SKU選択で迷うことは減ります。

開発停滞リポジトリでの課金の落とし穴

active committer課金は、GHASを使う限り必ず理解しておくべき論点です。特に見落としやすいのが、「アクティブ開発が止まっているリポジトリ」の扱いです。

GHASを有効化したまま開発が停滞したリポジトリで、開発者が「たまにhotfix pushする」だけの状態でも、その開発者はactive committerとしてカウントされます。90日以内にpushがあれば課金対象なので、過去プロジェクトのメンテナンス要員が想定外にコストを引き上げるケースが発生します。

対策としては、Organization設定で「GHASを有効化するリポジトリを明示的にリスト管理する」運用が現実的です。「All new repositories」設定を有効にしたまま放置すると、レガシーリポジトリで思わぬ課金が発生します。

GitHub Copilot Enterpriseとの機能重複

GitHub Copilot Enterpriseにも、コードレビュー支援機能・脆弱性チェック機能が含まれています。GHAS Code Securityとの機能重複が生じる領域があり、「両方契約するとコストが二重になるのでは」という懸念が現場で出ることが多いです。

現時点での整理は以下のとおりです。

• Copilot EnterpriseのCode Reviewは汎用的なコード品質レビュー（バグ・設計・可読性）
• GHAS Code Security（Copilot Autofix含む）はセキュリティ脆弱性の検出と修正に特化

両者は補完関係にあり、大規模開発チームでは両方導入するケースが標準です。ただし予算制約がある場合、開発生産性重視ならCopilot Enterprise優先・脆弱性管理重視ならGHAS優先の順で導入していくのが実務的な進め方になります。

CodeQL初回有効化時のalert対処

CodeQLは強力な静的解析エンジンですが、大規模レガシーコードベースに初回適用すると数千件のalertが検出されるケースが典型です。全てを修正するのは非現実的で、Security Campaignsで優先度別に絞り込む運用が必須になります。

導入前に想定しておくべきことは以下の3点です。

• 初回スキャンで検出される件数のオーダー（数百〜数千件）
• 「無視してよいalert」の判定ルール（テストコード・生成コード・legacy branchなど）
• Security Campaignsの担当者アサインとレビューフロー

これを事前に設計しておかないと、「導入初日に大量alertが表示されて開発チームが萎縮する」パターンに陥ります。CodeQLの有効化は、Security Campaignsの運用体制と一体で設計するのが原則です。

Advanced Security billing insightsで課金を可視化

GHAS導入後は、Advanced Security billing insightsというダッシュボードで、リポジトリ別・機能別のactive committer数と課金額を可視化できます。

「どのリポジトリが最も課金を消費しているか」を月次で確認できるため、思わぬコスト超過を早期に把握するためのモニタリング対象として運用に組み込むのが標準的です。

特に導入初期は月次でこのダッシュボードを確認し、想定と実績のズレを追う必要があります。

GitHub Advanced Securityの導入と並行してAI活用を業務に定着させる

GHASによる脆弱性検出・シークレット漏洩防止・Copilot Autofixによる自動修正は、AIを開発現場に組み込む取り組みの一部として位置づけられます。

一方で、多くの組織にとっての現実的な課題は、GHAS単体の導入ではなく**「AIを業務プロセスにどう定着させるか」という運用設計**にあります。PoC段階で成果は出せても、全社展開・部門横断での定着に失敗するパターンが多いのが実態です。

AI総合研究所では、PoCから全社展開までの設計、部門別ユースケース、AI運用における統制・セキュリティのチェックポイントを220ページにまとめた「AI業務自動化ガイド」を無料で公開しています。GHAS導入と並行して、AI活用全体の設計を整理する第一歩として活用ください。

GHAS導入と並行してAI活用を業務に定着させる

PoCから全社展開までの設計を1冊で

GHASによる脆弱性検出・自動修正は、AIを開発現場に組み込む取り組みの一部です。AI業務自動化ガイド（220ページ）では、PoC段階から全社展開までの進め方、部門別ユースケース、AI運用における統制・セキュリティのチェックポイントを整理しています。

▶ 無料でダウンロード

まとめ

本記事では、GitHub Advanced Securityについて、2025年4月のSecret Protection・Code Security分割・機能内訳・Copilot Autofixの効果測定・料金体系・導入手順・他社ツール比較・選定観点まで、2026年7月時点の最新情報で解説しました。要点を整理します。

• GHASは2025年4月にSecret Protection（$19/月）とCode Security（$30/月）の2製品に分離し、GitHub Teamプランでも購入可能になった。両方まとめて購入した場合の実効単価は分割前と同水準だが、片方だけを選べる柔軟性が新体制の本質的な価値。
  
  

• Secret Protectionは「シークレット漏洩を発生前に止める」層として、Push Protection・Secret Scanning・Copilot Secret Scanning・Custom Patterns・Delegated Bypass・Security Campaignsを提供。2026年3月には28検出器、6月にはvalidity checksなど拡張が続く。
  
  

• Code Securityは「コード脆弱性を検出から修正まで押し込む」層として、CodeQL・Copilot Autofix・Security Campaigns・Dependabot Custom Auto-triage・Dependency Reviewを提供。Copilot AutofixはPR時点alertを中央値28分で解決（手動比較で3倍高速）。
  
  

• 料金はactive committer課金で、月ごとに変動する。「直近90日でGHAS有効リポジトリにpushされたコミットを持つユニークcommitter数」がベースなので、開発停滞リポジトリの取り扱いに注意が必要。パブリックリポジトリではSecret Scanning自動実行・ユーザー単位Push Protection・CodeQL（要有効化）が無料で使える。
  
  

• 選定は「Secret Protection先行かCode Security先行か」がまず問われる。公開リポジトリを持つSaaS事業者・OSSメンテナーはSecret Protection先行、レガシーコードベースを抱える企業はCode Security先行が第一候補。GitHub Copilot Enterpriseとは補完関係で、大規模開発チームでは両方導入が標準。

GHASは「開発フローの中で脆弱性を検出・修正する」層としては、GitHub上で使う限り最も統合コストの低い選択肢です。まずはSecret ProtectionでPush Protectionを有効化し、シークレット漏洩リスクを即日下げる取り組みから着手することが、多くの組織にとって最も実用的な第一歩になります。