GitHub Advanced Securityとは？主要機能や料金、選び方を解説

GitHub Advanced Security（GHAS）は、GitHub上のコードとリポジトリに対して脆弱性検出・シークレット漏えい防止・依存関係管理をシフトレフトで統合提供するセキュリティスイートです。

2025年4月に単一SKUから「GitHub Secret Protection」と「GitHub Code Security」の2つの独立SKUに分離し、2026年6月にAzure DevOps上のCopilot Autofixが限定プライベートプレビューで登場（7月には限定パブリックプレビューへ移行）、7月にはagentic autofixとGitHub Code Qualityが相次いでリリースされました。

本記事では、2製品それぞれの機能、active committer課金の料金体系、他社SAST/SCAやGitHub Code Quality・Copilotとの役割分担、Secret先行かCode先行かの選び方、導入手順とPoCの進め方、ZOZOやOptumの事例までを2026年7月時点の最新情報で体系的に解説します。

GitHub Advanced Securityとは？GHASの2製品体制と現在地

GitHub Advanced Security（GHAS）とは、GitHubが提供するリポジトリ向けの統合セキュリティスイートで、コード脆弱性検出・シークレット漏えい防止・依存関係管理を開発ライフサイクルの早期段階に組み込む役割を担います。

かつては単一SKUで提供されていましたが、2025年4月1日にGitHubはGHASを2つの独立SKU——「GitHub Secret Protection」と「GitHub Code Security」——に分離しました。

さらに2026年7月にはagentic autofixのpublic previewと、コード品質専用の新製品「GitHub Code Quality」のGAが相次ぎ、GHAS周辺のシフトレフト機能が一気に拡充されています。

2026年7月時点で見ると、GHASは「シフトレフトを買う」から「シフトレフトを2SKUで組み合わせる」フェーズに入ったといえます。

GHASのシフトレフト上の位置づけ

GHASの設計思想は、脆弱性やシークレット漏えいを「本番環境で発見して直す」のではなく、「開発者がコードを書く・PRを出す・pushするタイミングで止める」ことにあります。

• 書く時
  静的解析エンジンがPRのdiffを解析し、脆弱性を検出する
  
  

• PRを出す時
  AIが修正案をコメントとしてPRに提示する
  
  

• pushする時
  pushコミット単位でシークレット含有を検査し、含まれていればブロックする

リスクの発生源に近い3層で止める設計のため、後工程のSOC対応・インシデント調査・監査対応の負荷が下がります。

---

GitHub Secret Protectionの主な機能

GitHub Secret Protectionは、APIキー・パスワード・トークンなどの機密情報がリポジトリに漏えいするのを「発生前」と「発生後」の両面で押さえる製品です。

本セクションでは4つの主要機能を順に解説します。

Push Protectionで漏えい前ブロック

Push Protectionは、開発者がpushしようとするコミットの中身をGitHubがリアルタイムに検査し、AWSキーやGitHubトークンなど既知パターンの秘匿情報が含まれていた場合にpush自体を拒否する機能です。漏えいを「発生する前」に止めるため、事後対応のコスト（キーの失効・監査ログ調査・関係者通報）の発生を抑えられます。

なおバイパス運用や既に漏れているシークレットが残っているケースはSecret Scanning側でカバーする補完前提の設計になっています。

有効化範囲は2026年時点でパブリックリポジトリに無料、Secret Protection契約下ではプライベートリポジトリでも利用可能です。
ライセンスによって検出パターンや高度機能の範囲は異なるため、具体的な検知範囲は公式ドキュメントを参照してください。

Secret Scanningで過去分検出

Push Protectionが新規のpushだけを対象にするのに対し、Secret Scanningはリポジトリの全ブランチ・全コミット履歴をスキャンして過去に漏れた秘匿情報を検出し、alertを発火します。

M&A後にリポジトリを引き取ったケースや、Push Protectionを有効化する前のコードベースを持ち込むケースでは、この過去分スキャンが実務上の入口になります。

発火したalertは組織のセキュリティ管理画面に集約され、SIEM（Sentinel等）に連携すればSOCワークフローに載せられます。

AI generic secret detection

パスワードのように「文字列パターンが決まっていない」秘匿情報は、従来のregex型検出では見逃されてきました。

この空白を埋めるのがCopilot AI generic secret detectionで、LLMベースの検出モデルで非構造化シークレット（人間が決めたパスワードなど）を拾い上げる機能です。Secret Protectionライセンスに包含されているため追加契約は不要です。

Delegated Bypassで例外承認

Push Protectionは強力ですが、テスト用のダミーキーやCI環境変数のようにpushを許容したいケースは実務で発生します。ここで用意されているのがDelegated Bypassで、開発者がbypass申請を出し、セキュリティ管理者が承認して初めてpushが通る二段階の承認フローです。

「開発者の生産性」と「セキュリティ管理者のガバナンス」を両立させる仕組みとして、Push Protection導入時の現場摩擦を大きく下げる役割を担います。

---

GitHub Code Securityの主な機能

GitHub Code Securityは、コード脆弱性の「検出」と「修正」を一体で提供する製品です。CodeQLによる静的解析、Dependency Reviewや高度なDependabot機能（後述）、Copilot Autofixによる修正提案までを1つのSKUに束ねています。

本セクションでは主要機能を順に解説します。

CodeQLのセマンティック静的解析

CodeQLは、GitHubが買収したSemmle社の技術をベースにしたセマンティック静的解析エンジンで、コードを「クエリ可能なデータベース」として扱い、脆弱性パターンをSQLライクな言語で照会します。

対応言語は2026年7月時点でC/C++・C#・Go・Java・Kotlin・JavaScript・TypeScript・Python・Ruby・Swiftに加え、2025年4月にGitHub Actionsワークフローの解析がGA、2025年10月にRustのビルドレス解析がGAとなりました。

パブリックリポジトリでは無料利用が続いており、プライベートリポジトリはCode Security契約で有効化できます。導入経路はdefault setup（ワンクリック有効化）とadvanced setup（Actions YAMLで詳細制御）の2つが用意されています。

Dependency ReviewとDependabot

依存関係管理はGitHub全体の基本機能とCode Security同梱のプレミアム機能の2層構造です。

• 基本機能（全リポジトリで利用可）
  Dependabot alerts（脆弱性のあるバージョンを検出してalert）、Dependabot security updates（脆弱性を修正するPRを自動起票）、Dependabot version updates（依存関係のバージョン更新PR）は、パブリック・プライベート問わずGitHubの基本機能として利用できます
  
  

• Code Security同梱のプレミアム機能
  Dependency Review Action（PRで追加・更新される依存ライブラリのCVEをCIチェックとして弾く）、Dependabotのプレミアム機能（custom auto-triage rules等）などが含まれます

PoC段階でCode Security契約が難しい場合でも、Dependabotの基本機能はそのまま使えるため、依存関係管理の基本ラインはGHAS契約なしで組めます。

Copilot Autofix通常版のAI修正提案

Copilot Autofixは、CodeQLが検出した脆弱性alertに対してAIが修正コードの案を生成し、PRコメントとして提示する機能です。

開発者はワンクリックでcommit-suggestionを受け入れ、PRに反映できます。

ここで実務上押さえておきたいのは、通常版のCopilot AutofixはGitHub Copilotのサブスクリプション契約を必要としないという点です。
Code Securityライセンスさえあれば、Copilot契約なしでも利用できます。

Agentic Autofixの自律修正PR

Agentic Autofixは、2026年7月10日にpublic previewとなった新機能です。

Copilot cloud agentがCodeQL alertを割り当てられ、コードベースを自律的に探索して修正案を生成し、CodeQLを再実行して検証、必要に応じてiterateしながらdraft PRを作成する仕組みです。

処理時間は1件あたり2〜4分程度で、GitHubは「CodeQL再実行によって修正がalertをcloseすることを確認する」と説明しています。

ただしこの検証は対象クエリ範囲内での確認にとどまり、あらゆる副作用や別alertの誘発が起きないことまで保証するものではないため、レビュー・承認は必ず人間が担う運用が推奨されます。

要件は通常版のAutofixよりも重く、以下3点がすべて揃って初めて利用可能になります。

• GitHub Code Security（またはGHAS）ライセンス
  Agentic Autofixを利用するため
  
  

• GitHub Copilotライセンス
  cloud agentの実行主体としてCopilot契約が必要
  
  

• Copilot cloud agent の有効化とAI Credits・GitHub Actions minutesの消費枠
  1件のautofix実行ごとにトークンが消費され、まずCopilotライセンス付属の共有AI Creditsプールから引かれる。
  
  枯渇後は組織設定によって追加課金または利用停止となる。加えて処理中のGitHub Actions minutesも消費される

通常版Autofixとの違いを整理すると、以下の比較表の通りです。

機能	前提ライセンス	Copilot契約	追加消費	提供状況
Copilot Autofix（通常版）	Code Security	不要	不要	GA
Agentic Autofix	Code Security + Copilot license + cloud agent	必要	AI Credits + GitHub Actions minutes	2026-07-10 public preview

通常版とagentic版は「Code Securityライセンスの範囲内で追加のCopilot契約・AI Creditsなしで使える修正提案」と「Copilotライセンスの共有AI Creditsプール＋Actions minutesを消費してエージェントに委任する自律修正」という位置関係にあり、alertボリュームと運用体制で使い分ける設計です。

Security Campaignsのバックログ対応

Security Campaignsは、過去に蓄積したCodeQL alertを最大1,000件までキャンペーン単位でまとめ、対応可能なものについてCopilot Autofixを集中的に適用するための運用機能です（公式ガイド）。

「1,000件を全自動修正する」機能ではなく、あくまでキャンペーン化されたalert群に対してAutofixを適用しやすい状態を作る仕組みです。

技術的負債としてのalertバックログを抱える組織、特に「CodeQLを初めて有効化した際に既存コード分のalertがまとまって出てしまうケース」を段階的に減らす運用に向いています。

AI security detectionsで補完

2026年7月14日にpreview公開された新機能で、CodeQLでカバーしきれない言語やフレームワークについて、Copilotが検出した脆弱性をPRに助言的な形で表示する仕組みです（公式仕様）。

利用にはCode Security ライセンス、Copilot ライセンス、AI Credits、CodeQL default setup、組織側での有効化がすべて必要で、PR内のインライン助言に限定されます。

リポジトリ全体のバックログalertとして残る仕組みではないため、既存alertを網羅する用途ではCodeQL＋Autofixが主軸のままで、AI security detectionsは補完役です。

CodeQLの決定論的な検出とCopilotの柔軟なPR時点助言を1つのcode scanningストリームに統合する設計で、CodeQLが手薄な言語のPRレビュー品質を補強する位置づけです。

Copilot Autofixの対応範囲と限界

Copilot Autofix通常版は、公式が示す対象言語・対象クエリの範囲で動作します。CodeQLが検出したalertが全て自動的にAutofix対象になるわけではなく、公式が明示的にサポート対象と示したクエリ・言語に絞られる仕様です。

最新のサポート範囲は公式ドキュメントで確認するのが確実です。

対象alertの範囲は通常版とAgentic版で異なります。

• 通常版: CodeQLが検出したalertが主対象
• Agentic版: CodeQLに加え、第三者ツールからのcode scanning alertもベストエフォートで対象

一方で、ZOZOの導入運用レポートが指摘するように、SAST全般の宿命として以下のような検出は苦手領域として残っています。

• アクセス制御の不備
  仕様に依存する脆弱性のため、静的解析だけでは判定できない
  
  

• ビジネスロジック起因の脆弱性
  コードの文法パターンではなく業務ルール違反の話なのでSASTでは拾えない
  
  

• 多段プロセスをまたぐ脆弱性
  CodeQLが解析対象とする単一プロセス境界を越える攻撃はカバー範囲外

Autofixが機能するのは「code scanningでalertが出た事象」に対してのみで、SASTで拾えない脆弱性クラスは別途DAST・IAST・レビュー運用で補う前提になります。この前提を押さえておくと、期待値のズレを防げます。

---

GHASの料金と課金モデル

GHASの料金体系はactive committer課金という独特のモデルを採用しており、ユーザー数（seat）ではなく「その人のcommitが直近90日以内に対象リポジトリへpushされたかどうか」で請求額が決まります。

以下、active committerの数え方、Secret ProtectionとCode Securityの月額単価、パブリックリポジトリの無料範囲、購入経路の3パターン、月額の試算例の順に整理します。

active committerとは（課金対象の数え方）

GitHub公式ドキュメントでは、active committerは「Advanced Security機能を有効化したリポジトリに対して、そのユーザーのcommitが直近90日以内にpushされたユニークコミッター」と定義されています。

カウントのトリガーはユーザー本人の操作ではなく、あくまでそのユーザーのcommitが対象リポジトリにpushされた事実です。

したがってseat数（アカウント数）とは一致せず、GitHubに閲覧目的だけで参加しているメンバーやマネージャは課金対象外になります。
逆に外部委託先のエンジニアや退職者アカウントも、そのcommitが90日以内に対象リポジトリへpushされていれば課金対象に含まれ得ます。

:::message退職者が90日間必ず課金され続けるとは限らず、アカウントの資格状態（削除・無効化のタイミング）や契約方式（メーター課金 or ボリューム）によって扱いが変わります。

実際の請求に組み込む前に、公式ドキュメントで最新の挙動を都度確認しておくと事故が減ります。
:::

Secret Protection・Code Securityの月額単価

2026年7月時点の各プランの単価は以下の通りです。

プラン	単価（active committer 1名あたり月額）	主要機能
GitHub Secret Protection	$19	Push Protection / Secret Scanning / Copilot AI generic detection / Delegated Bypass / Security Campaigns（secret scanning alert向けはpublic preview）
GitHub Code Security	$30	CodeQL / Dependency Review Action / Dependabot premium features / Copilot Autofix / Security Campaigns
両方併用	$49（合計）	上記全機能

ここで注意したいのは、$49という独立SKUは存在しないという点です。

あくまで独立した2つのSKUを両方契約した場合の合計額が$49になる構造で、片方だけの契約も自由に選べます。

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

パブリックリポジトリでは、code scanning（CodeQL）・secret scanning・dependency reviewが無料で利用可能です。OSSプロジェクトや公開ドキュメント用リポジトリはこの範囲でカバーできるため、GitHub.comでのGHAS課金対象はprivate repositoryとEnterpriseのinternal repositoryに絞られます。

ただしGHE.com（GitHub Enterprise Cloudの専用データ環境）とGitHub Enterprise Server（GHES）は扱いが異なり、リポジトリの公開/プライベート/internalに関わらず全リポジトリがライセンス対象になります。

加えてPush Protectionもパブリックリポジトリでは無料で有効化できます。
2023年5月にパブリックリポジトリ向けの無料提供が始まり、2024年には無料ユーザーへのデフォルト有効化が段階展開されており、GitHub全体でセキュリティ底上げが進んでいる流れの一部です。

購入経路の3パターン（Team ／ Enterprise ／ Azure DevOps）

GHASを購入する経路は、GitHubの契約プランごとに3つに分かれています。

ただし製品単価はどこから買っても同じで、違いが出るのは「請求経路」「committer集計単位」「Autofixに関わるAI Credits調達先」の3点です。

以下の表で経路ごとの違いを整理しました。

経路	請求	committer集計単位	AI Credits調達先
GitHub Team plan	GitHub本体の請求	organization単位	Copilot Businessの共有プール
GitHub Enterprise	Enterprise請求	enterprise配下の全org合算	Copilot BusinessまたはEnterpriseの共有プール
Azure DevOps	Azureサブスクリプション経由	Azure subscription単位（同subscription配下のorgをまたいで重複排除）	Azureサブスクリプションに従量課金

Team plan経路は2025年4月から新たに開放されたルートで、中小規模チームがEnterprise契約なしにGHASを試せるようになりました。これが分離SKU化のもう一つの狙いです。

一方でAzure DevOps経路だけはAI Credits調達先がAzureサブスクリプション側になり、本家GitHubと課金経路が変わるため、見積もり時に見落とさないよう注意が必要です。

月額の試算例

例として、30名の開発チーム（うちactive committerが実質25名）でSecret ProtectionとCode Securityを両方導入する場合の試算を示します。

• Secret Protection: 25名 × $19 = $475/月
• Code Security: 25名 × $30 = $750/月
• 合計: $1,225/月（1ドル約155円換算で約19万円/月）

この試算にはAgentic Autofix利用時の消費（Copilotライセンス付属の共有AI Creditsプールからの消費＋GitHub Actions minutes）は含まれていません。

共有プールを超過した場合は組織設定によって追加課金または利用停止となるため、agentic版を本番運用する際はalertボリュームと合わせて別途見積もりが必要です。

---

GHASと他ツールの比較

GHASを検討する際、比較対象は3層に分かれます。同社他製品（GitHub Code Quality・GitHub Copilot）と、他社SAST/SCA（Snyk・SonarQube・Checkmarx）です。それぞれと役割がどう違うかを整理します。

Snyk・SonarQube等との違い

以下の表で、主要な他社セキュリティツールとGHASの位置づけを比較しました。

ツール	対応SCM	提供形態	提供機能	GitHub PR統合
GHAS	GitHub.com / GitHub Enterprise Server / Azure DevOps	SaaS / セルフホスト（GHES）	SAST(CodeQL) + SCA(Dependabot/Dependency Review) + Copilot Autofix（GitHub.com／Azure DevOps。GHESは対象外）	ネイティブ（同一UI）
Snyk	GitHub / GitLab / Bitbucket / Azure DevOps ほか	SaaS（一部セルフホスト）	SAST + SCA + Container + IaC	App/CIチェック経由
SonarQube	GitHub / GitLab / Bitbucket / Azure DevOps ほか	セルフホスト / SonarQube Cloud	SAST + Code Quality（品質軸が中心）	App/CIチェック経由
Checkmarx	主要SCM各種	SaaS / セルフホスト	SAST + SCA + IaC + API Security	連携アプリ経由

選定軸としては、GitHubに全リポジトリを集約している組織ならGHAS（Azure DevOps派生も含む）がPR運用にネイティブに乗ります。

一方、GitLab・Bitbucketなど複数SCMを併用する組織にはマルチSCM対応のSnyk・SonarQube・Checkmarxが選択肢に入ります。単純な優劣ではなく、対応SCM・提供形態・重視する機能軸で選ぶのが妥当です。

GitHub Code Qualityとの役割分担

2026年7月20日にGAとなったGitHub Code Qualityは、GHASとは別料金・別役割の新製品です。

Code Qualityは「セキュリティ脆弱性ではないコード品質問題」（重複コード・複雑度・命名・テストカバレッジ等）を対象としており、GHAS Code Securityが担う「脆弱性検出」とは責任範囲が異なります。

SonarQubeを社内で利用している組織は、Code QualityにSonarQube的役割を移管する検討の余地があります。

Code QualityはGHAS Code Securityとは独立した製品で単独契約が可能ですが、脆弱性検出の代わりにはならないため、セキュリティが必要ならCode Securityと併用する構成になります。

Copilot系との重複整理

GitHub CopilotシリーズにもCopilot Code Reviewというコードレビュー機能があり、GHASとの機能重複が意思決定を難しくします。

現行のCopilotプランはFree・Student・Pro・Pro+・Max・Business・Enterpriseで、Code Reviewはすべての有料プランで利用可能です。

• Copilotの有料プラン（Pro / Pro+ / Max / Business / Enterprise）
  コード補完・チャット・Code Review（PRのdiffに対するAIレビューコメント）が主機能
  
  

• GHAS Code Security
  CodeQLによるリポジトリ全体の網羅的脆弱性スキャンとAutofixが主軸

「Copilotを入れたからCode Securityは不要」という判断にはならず、Copilot Code Reviewはdiff中心のPRレビュー、Code SecurityはCodeQLによるリポジトリ全体スキャンと役割が分かれるため、両方を補完的に使うのが実務に沿います。

---

Secret ProtectionとCode Securityの選び方

GHASを検討する際に必ず出てくる3つの意思決定ポイントについて、ケース別の推奨を示します。中立的な情報整理ではなく、AI総研が導入支援で見てきた現場感覚を踏まえた立場で書きます。

Secret先行かCode先行か

結論から言うと、PoC段階の小規模チームはSecret Protection先行、既にコード脆弱性のインシデントを経験している組織はCode Security先行が現実的です。

Secret Protectionは単価が安く（$19）、Push Protection単体でも「シークレット漏えいの現場負荷を下げる」という効果が即座に見えるため、経営層への導入合意を取りやすいのが強みです。

一方、Code Securityは初回有効化時にCodeQLが現在の対象コードを解析するため、既存コード分のalertがまとまって出ることがあり、Security Campaigns・Autofix含めた運用設計が必要になります。

PoCの一発目でこれを走らせると現場が疲弊して撤退判断になるリスクがあるため、まずSecret ProtectionでGHAS運用の型を作ってからCode Securityを乗せる順序が推奨です。

Azure DevOps併用チームの選択軸

Azure DevOps版GHAS本体（Secret Scanning / Dependency Scanning / Code Scanning）は既に提供済みで、Azure DevOps上で本番運用が可能です。

ただし2026年7月時点でAzure DevOps上のCopilot Autofixは限定パブリックプレビュー（6月の限定privateから7月に限定publicへ移行）にとどまっており、この切り分けを押さえるのが判断の起点になります。

• 既存資産がAzure DevOpsに集約されている
  → Azure DevOps版GHASで本番運用可、Autofixは通常運用（GitHub.com版）でPoCする戦略も現実的
  
  
• AI駆動の修正提案（Autofix）を本番運用の必須条件にしたい
  → GitHub.com版で先行、Azure DevOps Copilot Autofixは限定パブリックプレビューを申請してキャッチアップ
  
  
• 両方の環境を持っている
  → コアリポジトリはGitHub.com版でAutofix含めて回し、周辺はAzure DevOps版で運用する棲み分けが可能

Azure DevOps側のGHASを選ぶ場合、Copilot Autofix以外の機能はGA済みです。

プレビュー扱いはAutofixに限定されるという前提でSKU選定を進めれば、戦略の幅が広がります。

Team plan vs Enterprise

GHASの購入経路として2025年4月からTeam plan経由が開放されました。

TeamとEnterpriseは公式に人数基準を示していないため、本記事では組織構造・ガバナンス要件を軸に整理します。

• 単一organization運用で足りる → Team plan経由で十分。契約はGitHub本体の請求に一本化される
• 複数org・複数事業部を横断してガバナンスを効かせたい → Enterpriseが前提。org横断のcommitter集計・enterprise policy・請求集約が可能
• SSO・SCIM・enterprise level auditingの要件がある → Enterprise（GitHub Enterprise Cloud）が必須

Team plan経由はGHASを試すハードルを下げる意味で画期的な変化ですが、複数org統制・SSO・SCIMなどのエンタープライズ機能が必要になった段階でEnterpriseへ移行するのが実務的な流れです。

AI総研の支援現場では、体感として20〜30名を超えたあたりでEnterprise移行の議論が入ることが多い印象ですが、これはあくまで独自の目安であり、公式の閾値ではありません。

---

GHASの導入手順とPoCの進め方

GHASの有効化自体はUI上の数クリックで完了しますが、順序を間違えると現場が疲弊するのがGHAS導入の落とし穴です。

以下のフェーズで進めることを推奨します。

有効化フローの全体像

GHASの有効化はorganization設定 → repository有効化 → 機能ごとの設定、の3段階で進みます。

• organization設定
  Billing画面でSecret Protection / Code Securityの購入 → active committer課金の同意
  
  

• repository有効化
  対象リポジトリごとに Settings → Code security から有効化。全リポジトリ一括か段階的か選択
  
  

• 機能ごとの設定
  CodeQL（default setup / advanced setup）、Push Protection、Secret Scanning、Autofixをそれぞれ設定

ここで注意したいのは、全リポジトリ一斉有効化は原則避けるべきという点です。CodeQLは有効化時点のコードを初回解析するため、既存コード分のalertが一気にまとまって出ることがあり、運用体制が整う前にこれを浴びると現場が対処しきれなくなります。

CodeQL初回alert対処のコツ

CodeQLはdefault setup（ワンクリック有効化）で走らせると、push・PR・スケジュールなど設定したイベントに応じて、その時点のコードのスナップショットを解析します。

過去のコミット履歴を古い順に辿り直す仕組みではないため、初回解析では現状のコードに残っている脆弱性がまとまってalertとして出てきます。

まずdefault setupで小規模に有効化し、標準設定でカバーできない解析要件（複雑なビルド、対象パス制御、クエリ制御、実行タイミング制御など）が出てきた段階でadvanced setup（Actions YAMLで詳細制御）に切り替えていく順序が現場で回しやすくなります。

• default setupを検討
  対応言語で標準ビルドの範囲なら、ワンクリックで有効化するのが最速
  
  
• advanced setupに切り替え
  Android/iOS等の複雑なビルド、Monorepo、対象パスやスケジュール制御が必要な場合
  
  
• Security Campaignsで既存alertを段階対応
  初回スキャンで発火したバックログalertはキャンペーン化して優先度をつけて片付ける

ZOZOの導入レポートでも、Android/iOSなどビルドが複雑なリポジトリはadvanced setupが必須と報告されています。リポジトリ特性に応じてdefault/advancedを使い分ける前提で導入設計しておくと詰まりが少なくなります。

Push→Secret Scanningの導入順序

Secret系機能は、Push Protection（新規コミット防御）から先に入れて、その後にSecret Scanning（過去分検出）を回す順序が推奨です。

理由は単純で、Push Protectionを先に入れないと、Secret Scanningの過去分alertを潰している間に新しい漏えいコミットが積み上がってしまうからです。

「漏えいの蛇口を止めてから溜まった水を抜く」順序をイメージすると理解しやすく、逆にすると運用工数がじわじわ増えていきます。

Copilot Autofix系の追加要件

Copilot Autofix通常版はCode Securityライセンスさえあればすぐ有効化できますが、Agentic Autofixは追加要件が必要です。

• Copilot licenseの付与（Business or Enterprise）
• Copilot cloud agentの有効化（org設定）
• AI Creditsの消費枠を紐付け（Copilot Business/Enterpriseの共有プールから消費）
• GitHub Actions minutesの消費枠（agent実行中に消費されるため）

Agentic版の導入は「便利機能の追加」ではなく「セキュリティ運用を Copilot Cloud Agent 経由でAIに委任する運用変更」なので、レビューフローの承認者ルールを再定義する必要があります。

Azure DevOps Autofix条件

Azure DevOps版GHAS本体（Secret Scanning / Dependency Scanning / Code Scanning）は既に提供済みで通常運用に投入できます。

2026年7月時点でAzure DevOps上のCopilot Autofixは限定パブリックプレビュー（6月の限定privateから7月に限定publicへ移行）にとどまるため、この切り分けを押さえた上で申請します。

Copilot Autofix限定パブリックプレビューの現時点の制約は以下の通りです。

• 対象alert: CodeQLベースのサポート対象alert
• 対応言語: C/C++・C#・Go・Java・Kotlin・JavaScript・TypeScript・Python・Ruby・Swiftの10言語
• 課金: GHAS単価はGitHub.com版と同じ、Autofix利用時はAI Credits従量課金が加算
• 提供状況: 限定パブリックプレビュー（申請ベース）

GHAS本体の運用はプレビューではないため、Autofix以外の脆弱性検出・シークレット漏えい防止は先行してAzure DevOps上で本番運用に載せられます。

そのうえでAutofixだけを段階的に取り込む二段構えが、実運用には馴染みやすい進め方です。

---

GHASの導入事例と効果データ

GHASの実務的な効果を、公開事例と全体統計データから整理します。事例2件はいずれも公式レポート・企業技術ブログを一次ソースとしています。

【ZOZO】Autofix 38%・163時間削減

ZOZOTOWNを運営するZOZOは、Code scanning・Secret scanning・Dependabotの全機能を導入し、情報セキュリティ部がSOC業務として運用しています。

Copilot Autofixに関する公開データは以下の通りです。

• 修正案提示率: 38%のalertに対してAutofixが修正案を提示
• 適用率: 提示された修正案のうち12.5%が実際に採用
• 削減時間: 累計約163時間（6日以上）の開発工数を削減

Push Protection有効化後も「開発体験が損なわれない」ことを確認したうえで全社展開し、alertはMicrosoft Sentinelに連携してSOCワークフローに載せる運用を確立しています。

一方で詰まったポイントとして、Android/iOSのビルド失敗対応でAdvanced Setup調整が必要だった点や、パストラバーサル・XSSなど「stored値の出力」検知は言語依存で実装差があった点も報告されています。

【Optum】レビュー時間60%削減

米ヘルスケア大手のOptumは、Copilot Autofix導入により以下の効果を報告しています（GitHub公式日本語ブログ）。

• セキュリティ関連コードレビュー時間: 60%削減
• 開発生産性: 25%向上

Optumはヘルスケア分野の大手で、公開情報上で数字ベースの効果を出しているCopilot Autofix採用企業の一つです。GHAS＋Autofixが規制産業を含む大規模ヘルスケア組織で採用された事例として参照できます。

【GitHub全体】Autofixで修正時間3〜12倍短縮

GitHubが2024年5〜7月のpublic beta期間で計測した顧客データは以下の通りです。個別事例ではなく、Autofix適用時と手動修正時の中央値を比較したデータになります。

対象	手動修正時間（中央値）	Autofix適用時間（中央値）	短縮倍率
すべての脆弱性クラス	1.5時間	28分	3倍
クロスサイトスクリプティング（XSS）	3時間	22分	7倍
SQLインジェクション	3.7時間	18分	12倍

XSS・SQLiでAutofixの短縮効果が桁違いに大きい理由はGitHub公式では説明されていませんが、これらの脆弱性クラスは修正パターンがテンプレート化されており、AIモデルにとって扱いやすい対象と考えられます。逆に業務ロジック依存の脆弱性でAutofixの効果は限定的なので、あくまで「よくある脆弱性を機械的に潰す」ツールとして評価する前提が必要です。

---

GHASで守った開発ラインの隣にAIエージェント基盤を置くなら

GHASはコード脆弱性とシークレット漏えいを開発ライフサイクルの入り口で止める仕組みです。ここまで押さえた組織が次に直面するのは、Copilotや自作エージェントを業務プロセス側に展開し始めた瞬間に生まれる「AIガバナンスの空白」です。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、業務特化Agent群を1つのダッシュボードで統合管理し、実行ログ・アクセス権限・セキュリティスキャンをまとめて可視化するインテリジェンス・レイヤーとして機能します。

• 自社Azureテナント内で完結
  Azure Managed Applicationsとして構築されるため、業務データが外部SaaSに出ない
  
  

• Teamsから業務エージェントを呼び出す
  開発ラインとは分離した業務プロセス側で、Teamsをエージェント実行の入口として統一
  
  

• AIガバナンスを1画面で
  Agent一元管理・実行ログ・シャドーAI防止までダッシュボードで統制
  
  

• GHASのシフトレフト思想を業務プロセスに拡張
  コードだけでなく業務プロセスのAI活用まで、同じ設計思想で統制を設計

AI総合研究所は600社以上の相談実績をもとに、GHASで守った開発ラインの隣にどんなAIエージェント基盤を置くべきか、要件整理から本番運用まで伴走支援します。AI Agent Hubのサービスページで、自社の業務プロセスにどう組み込めるかをご確認ください。

---

まとめ

本記事では、GitHub Advanced Security（GHAS）について、2製品体制の定義・機能・料金・GitHub Code Quality/Copilotとの役割分担・判断軸・導入手順・ZOZO/Optumの事例までを、2026年7月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• GHASは2025年4月にSecret Protection $19とCode Security $30の2つの独立SKUに分離し、併用時は合計$49/月/active committerの課金体系
• 主軸機能はPush Protection・CodeQL・Copilot Autofix（通常版/agentic版）で、agentic版はCopilot license+cloud agent+AI Credits+Actions minutesが別途必要
• 小規模ならSecret先行が現実的、脆弱性インシデント経験ありならCode先行が定石で、GitHub Code Quality（2026年7月GA）は置き換えではなく併用対象
  
  

まずはSecret ProtectionのPoCから始めて、Push Protectionで漏えい経路を止めつつ、Code Security側は脆弱性インシデントの実績や監査要件に応じて後から追加するのが、最も現実的な第一歩になります。ZOZO（Autofix 38%提示・163時間削減）・Optum（60%削減）・GitHub全体で3倍短縮といった実測が積み上がっており、単一SKUを買う時代から「2SKU+Copilot連携で組み合わせる」時代に入った点を選定設計に織り込むと、導入価値を最大化しやすくなります。