GitHub Advanced Security trial開始導線が変更｜risk assessment から何を確認して始めるべきか

先に結論

GitHub Advanced Security の今回の更新で大きいのは、trial を始める場所が Billing だけではなくなったことです。

eligible enterprise admins なら、Secret Protection か Code Security の risk assessment からそのまま trial を開始できます。評価を始めるまでの摩擦がかなり下がりました。

ただし、ここで見るべきなのは「始めやすくなった」ことだけではありません。

• あなたの enterprise が self-serve trial の対象か
• 先に見るべきなのが Secret Protection か Code Security か
• trial を始めた直後に、どの repository とどの指標を見るか

この3点を先に決めておかないと、無料で試せても判断材料が散ります。

何が変わったのか

GitHub の 2026-05-19 changelog では、eligible enterprise admins が Secret Protection または Code Security の risk assessment から GitHub Advanced Security trial を直接開始できるようになったと案内されています。

今までは「trial を始める方法」を別で探す感覚がありました。今回の変更で、リスクを見た流れのまま試用へ進めます。

もうひとつ大事なのは、self-serve trial の対象外でも手詰まりではないことです。

GitHub は changelog で、self-serve trial 対象外でも risk assessment から Secret Protection と Code Security を有効化できる導線があること、必要なら GitHub へ相談できることを案内しています。

要するに今回の更新は、trial の可否だけを変えた話ではありません。評価導線を risk assessment 起点に寄せたのが本質です。

まず最初に確認すべきこと

1. self-serve trial の対象か

GitHub Docs の planning guide は、self-serve trial を自力で始めたい組織向けの手順を用意しています。説明ぶりを見る限り、まずは小規模から中規模の組織が想定読者です。

trial の前にここを見ておくべきです。

• 自分が enterprise 側の管理権限を持っているか
• 自社が self-serve trial で進める想定に合っているか
• trial の目的を自力で切り分けられるか

この条件が弱いなら、risk assessment からすぐ始めるより、先に評価計画を固めたほうが安全です。

2. Secret Protection と Code Security のどちらから見るか

trial を始める前に、見る順番を決めたほうがいいです。

Secret Protection から入るべきなのは、すでに漏えいリスクが見えている組織です。

• access token の露出を洗いたい
• push protection を運用に入れたい
• bypass の監査や validity checks を見たい
• secret scanning alerts を security チームで見たい

Code Security から入るべきなのは、コードと依存関係の検出を整えたい組織です。

• code scanning の default setup を広く回したい
• dependency scanning の見え方を確認したい
• pull request での検出と修正導線を見たい
• Copilot Autofix をどこまで許可するか決めたい

両方見るにしても、最初の主語を1つに絞るほうが評価が速いです。

3. trial の成功条件を先に決める

GitHub Docs は、trial 前に次を決めるよう案内しています。

• 何を判断したいのか
• どのメンバーで見るのか
• どの organization と repository を対象にするのか
• 何をもって trial 成功とみなすのか

ここを決めずに始めると、alert が出たこと自体で満足しがちです。

本当に見たいのは、運用へ載せられるかです。検出精度、ノイズ、担当範囲、既存 GitHub フローとの整合性まで見る必要があります。

trial を始めたら最初に何を見るべきか

Secret Protection を先に見る場合

GitHub Docs の Secret Protection trial guide は、試用直後に次を確認する流れを示しています。

• 追加の access token を custom pattern で拾う必要があるか
• AI による password 検出や validity checks が効くか
• push protection を広く有効化したときの運用負荷はどうか
• bypass request を誰が監査するか
• security manager role を誰に渡すか

要するに、Secret Protection は「見つかるか」より、漏えい防止をどう現場運用に入れるかを早めに確認したほうがいいです。

Code Security を先に見る場合

Code Security trial guide では、default setup の結果を最初に確認する流れが分かりやすいです。

• 高 confidence query だけで十分な検出が出るか
• repository ごとに追加設定が必要か
• pull request での分析をどこまで強制するか
• Copilot Autofix をどの repository で許可するか
• dependency scanning と code scanning をどのチームが見るか

Code Security は、最初から全部細かく詰めるより、default setup でどこまで戦えるかを先に見るほうが早いです。

対象外でも何ができるのか

今回いちばん誤解されやすいのはここです。

self-serve trial の対象外でも、何もできなくなるわけではありません。

GitHub の changelog では、対象外でも risk assessment から Secret Protection や Code Security を有効化する導線があると案内されています。GitHub Docs 側でも、trial planning、trial setup、enterprise security configuration、各機能の評価ガイドが細かく分かれています。

つまり、対象外の組織がまずやるべきなのは、比較表を探すことではありません。

• risk assessment の結果を読む
• どちらの製品軸を先に見るか決める
• enterprise security configuration の設計を確認する
• trial を GitHub に相談すべきか、自力で進められるかを切り分ける

この順番です。

すぐ決めておくと楽な運用ポイント

repository の広げ方を最初に決める

GitHub Docs では、trial enterprise 向けに enterprise security configuration を作り、対象 repository に適用する流れが案内されています。

ここで大事なのは、最初から全 repository を同じ強さで縛らないことです。

Secret Protection は全体に広げやすい一方、Code Security は repository の言語や開発フローごとに追加設定が要ることがあります。最初は primary configuration を作り、必要な repository だけ細かく分ける考え方のほうが合います。

alert を誰が見るかを決める

Secret Protection でも Code Security でも、GitHub Docs は security manager role を誰に渡すかを意識させています。

機能を有効化しても、alert を見て triage する人が曖昧だと前に進みません。

• enterprise owner が全体を見るのか
• organization 単位で security manager を置くのか
• 開発チームへどこまで alert を返すのか

この役割分担は、trial の時点で一度決めておくべきです。

どんな組織に今すぐ刺さるか

今回の導線変更が一番効くのは、すでに GitHub Enterprise Cloud を使っていて、free risk assessment の結果を見たあと次の一歩で止まっていた組織です。

• 「試せるなら触りたいが、開始場所が分かりにくかった」
• 「Secret Protection と Code Security のどちらを先に見るか迷っていた」
• 「trial を始めても、どこまで見れば導入判断になるか曖昧だった」

この状態なら、今回の更新はかなり実務的です。risk assessment を見た直後の温度感で前に進めます。

一方で、まだ GitHub のセキュリティ機能全体を整理しきれていないなら、先に GitHub Actions security roadmap 2026 で何が変わるか や Codex Security、Snyk、Semgrep、GitHub Advanced Security の比較 を読んで、GHAS を全体の中でどこに置くかを見ておくと判断しやすいです。

まとめ

GitHub Advanced Security の今回の変更は、trial ボタンの場所が増えた話で終わりません。

重要なのは、risk assessment から評価開始までの導線が短くなったことです。

そのうえで、最初に見るべきなのは次の3つです。

• self-serve trial の対象か
• Secret Protection と Code Security のどちらを先に評価するか
• trial の成功条件と対象 repository をどう切るか

この3つが決まっていれば、今回の更新はかなり使いやすいです。逆にここが曖昧だと、trial を始めても導入判断がぼやけます。