2026年4月9日、GitHubはセキュリティ評価（security assessments）の結果画面から直接 Ask Copilot を開けるようにしました。対象は Secret risk assessment と Code Security risk assessment で、組織管理者とセキュリティマネージャーは、結果に応じた説明と次に取るべき手順をその場で受け取れます。要するに、Ask Copilot は新しい検出機能というより、GitHub の高度なセキュリティで最初に悩みやすい「この結果をどう読み、何から直すか」を短くする改善です。 (The GitHub Blog)
GitHub の高度なセキュリティは GitHub Code Security と GitHub Secret Protection を中核とし、組織は無料のセキュリティ評価で現状の露出を把握できます。今回の Ask Copilot 追加は、その評価結果を“読むだけのレポート”から“すぐ動ける起点”へ寄せたアップデートと見ると分かりやすいです。 (GitHub Docs)
Ask Copilot が GitHub セキュリティ評価に登場したポイント
GitHub の 2026年4月9日付 Changelog では、Ask Copilot を Secret risk assessment と Code Security risk assessment の結果から直接起動できる と案内されています。公式の説明はシンプルですが、狙いは明確で、contextual explanations と guided next steps を評価画面の文脈つきで返すことにあります。 (The GitHub Blog)
この改善が効くのは、セキュリティ評価がもともと「何が多いか」は見えても、「結局どこから着手するか」で止まりやすい画面だからです。実際、Code Security risk assessment は脆弱性を 重大度・ルール種別・言語・Copilot Autofix 対象数 で要約し、Secret risk assessment は 総シークレット数・公開漏えい・防止可能漏えい・シークレット種別 を示します。Ask Copilot が入ることで、その集計値をその場で解釈しやすくなります。 (The GitHub Blog)
そもそも GitHub の高度なセキュリティの評価機能とは
GitHub の高度なセキュリティは、現在は主に GitHub Code Security と GitHub Secret Protection という製品群で提供されています。GitHub Team と GitHub Enterprise Cloud の組織は、これらを本格導入する前段として、無料のセキュリティ評価 を使って自組織の露出を把握できます。 (GitHub Docs)
- Secret risk assessment は、API キー、トークン、パスワードのようなハードコードされた認証情報を、組織のリポジトリ全体に対して時点スキャンし、総検出数・公開漏えい・push protection で防げた可能性がある漏えい・シークレットのカテゴリ を見せる機能です。 (GitHub Docs)
- Code Security risk assessment は、最大 20 リポジトリを対象にした無料のセルフサービス評価で、見つかった脆弱性、重大度、Copilot Autofix で修正可能な件数 を確認できます。既定では直近 90 日のコミット活動を基に、組織内の private / internal リポジトリから最大 20 件が事前選択されます。 (GitHub Docs)
レポートは、Organization > Security and quality > Assessments から表示し、Code Security タブと Secret Protection タブを切り替えて確認します。ドキュメント上では、評価レポートの実行・閲覧は organization owners と security managers が対象です。 (GitHub Docs)
Ask Copilot でトリアージはどう変わるのか
公開情報から言える本質は、評価結果から離れずに、意味づけと次アクションを引き出せるようになった ことです。以下は、GitHub が示している評価項目と、Ask Copilot の「文脈つき説明」「次の手順」という位置づけを踏まえた、実務上の変化です。 (The GitHub Blog)
数字の解釈にかかる往復が減る
Secret 側の評価では、公開リポジトリに漏えいしたシークレット数、push protection で防げた可能性がある件数、provider patterns と generic patterns の違いを読む必要があります。Code 側の評価では、最も脆弱なリポジトリ、言語別の偏り、複数リポジトリにまたがるルール、Copilot Autofix の適用余地を見る流れです。Ask Copilot が結果画面から直接使えることで、こうした指標の意味をその場で確認しやすくなります。 (The GitHub Blog)
優先順位づけが速くなる
GitHub の解釈ガイドでは、Secret 側は 公開リポジトリ上の provider patterns を最優先にし、その次に 公開リポジトリ上の generic patterns、さらに private リポジトリの漏えい を見る流れです。Code 側は、複数リポジトリに現れる Critical / High のルール を最優先にし、同じルールの多発や特定言語への偏りを、組織的な問題の兆候として見ます。Ask Copilot がここに入ると、集計表から初動の優先順位へ移るまでの時間を縮めやすくなります。 (GitHub Docs)
開発チームに渡す説明が作りやすい
GitHub Docs では、Copilot に対してセキュリティアラートの文脈で「How would I fix this alert?」のような質問ができる例が示されています。今回、それに近い Copilot 体験がセキュリティ評価の結果画面から直接使えるようになったので、セキュリティ担当が「この数字はなぜ重要か」「まず何をやるべきか」を開発チーム向けの言葉に落とし込みやすくなります。これは公式説明を踏まえた実務上の見立てですが、かなり自然な使い方です。 (GitHub Docs)
実務で使うなら、まずこの聞き方から始める
Ask Copilot の詳細なプロンプト例は今回の告知では公開されていません。ただし、評価の設計を見る限り、最初の質問は「これは何か」よりも 「何を先にやるべきか」 に寄せた方が、トリアージの時間短縮につながります。 (The GitHub Blog)
Secret Protection タブで聞くと効果が高い質問
- 公開リポジトリの漏えいの中で、最優先で無効化・ローテーションすべきシークレット種別はどれか
- Preventable leaks が多い理由から見て、先に push protection を有効化すべきチームやリポジトリはどこか
- 同じ種類のシークレットが複数リポジトリで見つかっているなら、共通原因になっている運用や CI/CD フローは何か
この聞き方が効くのは、Secret risk assessment が 公開漏えい・防止可能漏えい・シークレットカテゴリ を中心に構成されており、GitHub の解釈ガイドも 公開リポジトリの provider patterns を最優先に置いているからです。Ask Copilot の回答をたたき台にして、対象シークレットの無効化・ローテーション、push protection の展開、Secret Protection の有効化に進む流れが実務では自然です。 (GitHub Docs)
Code Security タブで聞くと効果が高い質問
- 複数リポジトリにまたがる Critical / High のルールのうち、最初に潰すべきものはどれか
- 脆弱性が特定言語に偏っているなら、共通フレームワークやコーディングパターンに原因がありそうか
- Copilot Autofix 対象が多いリポジトリから着手すると、どこまで修正効率を上げられそうか
- 最も脆弱なリポジトリを先に直すべきか、それとも複数リポジトリに広がる共通ルールを先に直すべきか
Code Security risk assessment は、最も影響を受けるリポジトリ、言語別の偏り、ルール別の内訳、Autofix 対象数 を見る設計です。GitHub の解釈ガイドでも、複数リポジトリに現れる Critical / High を最優先にし、必要なら GitHub Code Security を個別リポジトリまたは組織全体に有効化して Copilot Autofix を使う流れが示されています。 (GitHub Docs)
見落としやすい失敗ポイント
件数だけで追ってしまう
件数の多さだけで追うと、Secret 側では 公開リポジトリの provider patterns、Code 側では 複数リポジトリに広がる Critical / High のルール を後回しにしがちです。GitHub の解釈ガイドは、単純な総数よりも 露出の大きさ と 横展開の広さ を重視しています。 (GitHub Docs)
Code 側の評価を「全資産の棚卸し」と誤解する
Code Security risk assessment は便利ですが、既定では 直近 90 日の活動が多い private / internal リポジトリから最大 20 件 を選んで評価します。重要だが低活動のリポジトリが外れる可能性があるので、重要資産があるなら選択内容を見直してから実行した方が安全です。 (GitHub Docs)
評価レポートで満足してしまう
Secret risk assessment は point-in-time の露出確認であり、GitHub Secret Protection はそこから先の 継続監視、push protection、カスタムパターン、Copilot secret scanning を担います。Code 側も同様で、評価レポートは現状把握の入り口であり、継続的な修復は GitHub Code Security や Copilot Autofix の有効化につなげてこそ意味があります。 (GitHub Docs)
権限表記の差を見落とす
今回の Changelog では Ask Copilot の対象を organization admins and security managers と表現していますが、評価レポートの実行・閲覧ドキュメントでは organization owners and security managers と案内されています。表記に差があるので、自組織のロール設計では「誰が評価を見られ、誰が Ask Copilot を起動できるのか」を先に確認しておくと混乱しません。 (The GitHub Blog)
Ask Copilot の答えをそのまま確定判断にする
Ask Copilot は初動のスピードを上げますが、最終判断では リポジトリの重要度、実際の公開範囲、資格情報の有効性、修正の影響範囲 を人が確認した方が安全です。AI の説明は、優先順位をゼロから考える負担を減らすための補助として使うのがちょうどいい距離感です。
今すぐやること
- まず Organization > Security and quality > Assessments を開き、最新のレポートを確認します。Code Security と Secret Protection の両タブを切り替えて見られます。 (GitHub Docs)
- Secret Protection タブでは、Public leaks、Preventable leaks、繰り返し出る secret type を見て、Ask Copilot に「何を先に止めるべきか」を聞きます。 (GitHub Docs)
- Code Security タブでは、最も脆弱なリポジトリ、Critical / High の多発ルール、言語偏在、Copilot Autofix 対象数 を見て、Ask Copilot に「どの修正が横展開しやすいか」を聞きます。 (GitHub Docs)
- 回答をそのまま採用するのではなく、無効化・ローテーション、push protection、GitHub Code Security の有効化、Autofix の活用 という具体策に落とし込みます。 (GitHub Docs)
- 評価は継続運用の起点です。Code Security risk assessment も Secret risk assessment も再実行は 90 日ごと なので、次回の再実行タイミングを先に決めておくと改善の比較がしやすくなります。 (GitHub Docs)
Ask Copilot が GitHub のセキュリティ評価に登場したことで、GitHub の高度なセキュリティは「検出する」だけでなく、「どこから着手するかをその場で考えやすい」方向に一段進みました。すでに GitHub Advanced Security を使っている組織はもちろん、これから GitHub Code Security や GitHub Secret Protection を検討する組織にとっても、無料評価 → Ask Copilot で初動整理 → 継続機能を有効化 という流れが、最も失敗しにくい入り方です。 (The GitHub Blog)
コメント