気になる更新、覚えておきたいこと。

CHANGELOG

気になった GitHub の更新をピックアップ。押さえておきたいポイントと、現場で役立つ補足を日本語で。

44 件のピックアップ ↓ 新しい順

  1. セキュリティ Public preview Public monitoring：トリアージ、有効性チェック、API、Webhook に対応

    GitHub 全体の公開リポジトリに漏れたシークレットを Enterprise 専用画面で管理。有効な認証情報を優先して対応し、検出結果をインシデント対応ツールに連携できます。

    何が変わる？

    • アラート管理：Dismissed または Fixed としてクローズし、任意のコメントを追加できます。再オープンや、アクティビティタイムラインでの履歴確認にも対応します。
    • 絞り込み：リポジトリ、コミッター、シークレットの種類、関連付け方法（Enterprise メンバーシップまたは検証済みドメイン）、オープンまたはクローズ状態でフィルターできます。
    • 常時の有効性チェック：対応するシークレットは継続的に自動チェックされます。Active、Inactive、Unknown の表示で、まだ使える認証情報への対応を優先できます。
    • REST API と Webhook：GET /enterprises/{enterprise}/secret-scanning/public-monitoring-alerts で検出結果を取得できます。Enterprise レベルの secret_scanning_public_monitoring_alert イベントでは、自社に関連付けられた新たな漏えいの通知を受け取れます。

    通常のアラート一覧とは別の Enterprise 専用画面

    Octodemo Enterprise で Security and quality → Public monitoring を左サイドバーから開きます。

    Enterprise レベル限定の画面で、Organization やリポジトリのタブではありません。Enterprise メンバーや、メールアドレスが Enterprise の検証済みドメインに一致するユーザーに関連付けられたシークレットを表示します。自社が所有していない公開リポジトリでの漏えいも対象です。

    事前に Enterprise → Settings → Advanced Security → Additional Settings → Public monitoring で有効化しておく必要があります。

    利用条件と修復時の注意

    GitHub Enterprise Cloud（データ所在地を含む）向けのパブリックプレビューです。GitHub Advanced Security または GitHub Secret Protection に追加料金なしで含まれます。Enterprise 管理者と Enterprise セキュリティマネージャーが有効化やアラート設定を管理できます。

    アラートを閉じても、変わるのは自社 Enterprise での状態だけです。 認証情報の失効や、公開リポジトリからの削除は行われません。

    Public monitoring アラートの表示と管理 / Public monitoring の有効化

    公式の更新情報を読む

  2. 管理 Copilot impact dashboard：同業他社とエージェント活用を比較

    同程度の企業規模や同じ業種の集計ベンチマークと、エージェント活用率や PR マージ率の比率を比較できます。参加はオプトイン方式で、既定では無効です。

    何を比較できる？

    • Agentic adoption：アクティブユーザーのうち、agent-first または multi-agent に分類されるユーザーの割合。
    • Leverage：エージェントを活用するユーザーの PR マージ率が、活用していないユーザーと比べてどの程度高いか。
    • 他社ベンチマーク：28 日間のレポート期間について、比較対象グループの中央値と自社スコアを比較。参加企業が増えると、上位 10% のベンチマークやランキングも表示されます。
    • 企業規模と業種：比較対象を選び、自社の業種と全業種を切り替えられます。同業種の参加数が不足する場合は、同じ企業規模の全業種へ比較対象を広げ、実際に使ったグループを表示します。

    どこで確認する？

    Octodemo Enterprise で Insights → Copilot impact → Industry comparison を開きます。

    Enterprise オーナーはウィジェットから参加を開始し、Industry type と Company size を選択して確定します。ウィジェットと Copilot metrics industry comparison ポリシーは同じ設定を操作します。Copilot usage metrics ポリシーも有効である必要があります。

    押さえておきたい制約

    参加すると、集計メトリクスの提供と比較結果の閲覧の両方が有効になります。オプトアウトすると比較表示は即時に停止し、次の日次更新からデータが除外されます。集計ベンチマークに識別情報は含まれず、30 日後に削除されます。

    比較対象が少ない場合や自社スコアを計算できない場合、ランキングは表示されません。比較結果はダッシュボード限定で、usage metrics API、NDJSON エクスポート、ダウンロードには含まれません。

    Enterprise と Enterprise に属さない Organization が参加できます。Enterprise 配下の Organization は Enterprise 経由で参加します。Copilot Business ライセンスの割り当て専用 Enterprise は対象外です。データ所在地を利用する場合、同じリージョン内だけで比較します。

    Copilot impact dashboard の利用手順

    公式の更新情報を読む

  3. セキュリティ Public preview GitHub CLI：再ログインを繰り返さず、短命な OAuth トークンを使う

    有効期限付きのアクセストークンを選択すると、gh が自動更新します。漏えいしたアクセストークンは数時間で使えなくなり、通常の CLI 操作や設定済みの HTTPS Git 操作は継続できます。

    これまでと何が違う？

    これまで：GitHub CLI の標準の対話型ログインでは、有効期限のない長期利用の OAuth トークンを使っていました。繰り返しログインする必要はない一方、漏えいしたトークンは失効させるまで使われる可能性がありました。

    オプトイン後：gh が短命なアクセストークンと、ローテーションするリフレッシュトークンを保存し、必要なときに自動更新します。ログインの利便性を保ちながら、盗まれたアクセストークンは数時間で使えなくなります。保存されたリフレッシュ用の認証情報の保護と、侵害時の失効は引き続き必要です。

    有効化するには

    GitHub CLI v2.103.0 以降で実行します。

    gh auth login --expiring
gh auth status

    gh auth status でアクセストークンの有効期限を含む認証状態を確認できます。以後のログインで毎回フラグを付けずに有効期限付きの認証情報を要求するには、次を設定します。

    gh config set expiring_credentials enabled

    既存のログインが自動的に変換されるわけではありません。 手動で渡したトークンの動作も変わらず、PAT や環境変数のトークンが更新可能な OAuth 認証情報になるわけではありません。

    切り替え前に確認する 2 点

    • HTTPS の Git 操作：gh auth setup-git を実行し、gh を Git の認証情報ヘルパーとして使います。gh が認証情報の提供と更新を担当します。有効期限を超えたキャッシュを防ぐため、Git 2.46 以降を推奨します。SSH キーとは別の話です。
    • トークンをコピーするスクリプト：gh auth token の結果を一度だけ取得して保存するスクリプトや拡張機能は、期限切れで動かなくなります。できるだけ gh を直接呼び出すか、外部ツールで必要になるたびに gh auth token で新しい値を取得します。ログには出力しないでください。固定の長期トークンを必要とする処理は、移行を見合わせます。

    後から gh auth refresh でスコープを追加する際も、--expiring を付けるか設定を有効にしておきます。そうしないと、有効期限のない認証情報に置き換わることがあります。

    利用条件

    2026-10-22 時点では github.com と ghe.com で利用できるオプトインのパブリックプレビューです。GHES は 3.23 以降で対応します。非対応のサーバーでは有効期限のないトークンにフォールバックするため、フラグだけで判断せず、実際の認証状態を確認してください。

    認証と有効期限付きトークン / GitHub CLI v2.103.0

    公式の更新情報を読む

  4. セキュリティ Public preview Package firewall：危険な npm パッケージをインストール前にブロック

    Enterprise のポリシーで危険な npm パッケージのダウンロードをブロックし、開発者、コーディングエージェント、CI を保護します。

    Package firewall は、インストール前にダウンロードをブロックします。 Dependabot のアラートや PR チェックを補完するもので、置き換えるものではありません。

    何をブロックできる？

    • 公開直後のバージョン：最低経過日数を設定し、既知のアドバイザリがなくてもブロック。
    • 既知のマルウェアと脆弱性：GitHub Advisory Database と照合。脆弱性の重要度のしきい値を設定可能。
    • アテステーションの後退：以前あった SLSA アテステーションが欠落したバージョンをブロック。
    • 新たなインストールスクリプト：新しく追加された postinstall などをブロック。

    導入方法

    Enterprise → Policies → Package firewall でルールを設定し、接続方法を選びます。

    • Artifactory がある場合：公開 npm パッケージの取得を、共通レジストリ側で firewall 経由にします。同じ仮想リポジトリを使う端末や CI の設定変更は不要です。実験的な対応です。 設定手順。
    • 共通レジストリがない場合：開発端末、エージェント環境、CI ランナーの ~/.npmrc で接続先を firewall に変更します。端末管理、初期設定スクリプト、共通 CI ワークフローで配布でき、一台ずつ手作業で設定する必要はありません。設定手順。

    どちらも Enterprise メンバーのトークンが必要です。シークレットとして安全に管理します。

    ポリシーを有効にするだけでは、通信経路は変わりません。 firewall を通るダウンロードだけが対象で、公開レジストリへの直接接続は迂回できます。

    ブロック時は例外申請用リンクが表示され、Enterprise 管理者またはセキュリティマネージャーが審査します。

    利用条件

    2026-10-22 時点：npm のみ、GitHub Enterprise Cloud（データ所在地を含む）向けのパブリックプレビュー。プレビュー中は無料、一般提供時は従量課金の予定です。

    ポリシーと例外申請

    デモで試すこと デモを開く
    公式の更新情報を読む

  5. 管理 GA Copilot モデルポリシー API：既存のモデル制御を自動化

    モデルの利用可否を REST API で取得、更新できるようになりました。設定画面での繰り返し操作を減らし、ポリシー確認、承認済みの展開、Enterprise 全体の制限を自動化できます。

    これまでできなかった何ができる？

    新しいのは正式な REST API であり、モデルを制限する機能そのものではありません。 管理者は以前から GitHub の設定画面でモデルの利用可否を制御できました。今回、Enterprise、Organization、Enterprise チーム、エージェントアプリを対象とする GET と PATCH のエンドポイントが一般提供されました。

    手動で設定変更を繰り返す代わりに、次のような自動化を構築できます。

    • 設定のずれを検出：現在の設定を取得し、承認済みの基準と比較して、差分を定期的に報告します。
    • レビュー済みの変更を適用：意図する設定をリポジトリで管理し、PR で承認後、権限を持つワークフローから PATCH を呼び出します。API を使って構築できる運用例であり、GitOps 機能が標準搭載されたわけではありません。
    • 対象を絞って段階的に展開：委任済みのモデルを承認された Organization、またはチームモードの試行用 Enterprise チームに有効化し、同じ自動化で対象を広げます。
    • 一括で利用を停止：コンプライアンス上の判断に応じて Enterprise レベルでモデルを無効化し、委任先ごとの変更を不要にします。

    既存のポリシー階層は変わらない

    Organization モードでは Organization に判断を委任します。Enterprise チームモードは引き続き別途オプトインが必要なプレビューです。有効化すると Organization レベルのモデル設定は無効になり、Enterprise チームとアプリへの委任に切り替わります。4 つのスコープを独立した階層として自由に組み合わせるものではありません。

    チームから Enterprise レベルの制限を上書きすることはできません。チームモードでは、ユーザーが所属する各チームの許可が加算されます。API の応答は設定値と継承状態を表すもので、個々のユーザーが最終的に利用できるモデルの確定レポートではありません。

    まずは読み取りだけ試す

    必要な権限を持つアカウントで、ENTERPRISE を Enterprise のスラッグに置き換えます。

    gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  /enterprises/ENTERPRISE/copilot/model-policies

    更新を準備する際は、応答に含まれるモデル識別子を使い、対象エンドポイントの必要権限と編集可能な状態を確認します。

    Enterprise AI controls REST API / Organization の Copilot REST API / モデルの利用可否と委任

    公式の更新情報を読む

  6. セキュリティ GA オープンソースのライセンスコンプライアンスが一般提供

    依存関係のライセンスポリシーを Enterprise 全体で定義し、ルールセットと PR 上の指摘でマージ前に適用。例外申請も一元的に審査できます。

    何が変わる？

    • ライセンスポリシーを一元管理：Dependency Review Action のライセンスチェックを拡張し、Enterprise 全体のポリシーを定義できます。ブランチルールセットで、マージ前に準拠結果を必須にするリポジトリとブランチを指定します。
    • PR 時点で適用：追加または変更された依存関係を、検出された推移的依存関係も含めてチェックします。非準拠の依存関係は PR 上に指摘され、依存関係の削除や置き換え、ポリシーの変更、承認済みの例外で解消します。
    • 審査を担当者に委任：新しい Enterprise Open-Source License Manager ロールを個人やチームに割り当て、例外申請を審査できます。保留中の申請は Enterprise の管理画面に表示され、メールでも通知されます。
    • API と監査ログ：Enterprise ポリシーのダウンロード、更新、置き換えに対応。パッケージの準拠状況を確認する API も追加され、コーディングエージェントが依存関係を採用する前に確認できます。ポリシー変更は監査ログに記録されます。
    • データ所在地に対応：データ所在地を指定した GitHub Enterprise Cloud でもライセンス情報を利用でき、依存関係グラフと SBOM エクスポートにも反映されます。

    利用条件と段階的な導入

    GitHub Enterprise Cloud（データ所在地を含む）が対象で、リポジトリで GitHub Code Security を有効化する必要があります。無料の Dependabot 基本機能とは別の機能です。

    Active モードのルールセットは、非準拠の依存関係を含む PR のマージをブロックします。Evaluate モードではチェックと PR 上の指摘だけを行い、直接マージをブロックしません。ただし、会話の解決を必須にするブランチ保護がある場合、その指摘がマージを妨げることがあります。

    ライセンスコンプライアンスの概要 / ライセンスポリシーの設定 / Dependency graph REST API

    デモで試すこと
    octodemo → 既定のライセンスポリシー
    公式の更新情報を読む

  7. セキュリティ GA コードスキャンアラートの Agentic Autofix が一般提供

    コードスキャンアラートを Copilot に割り当てると、コードベースを調査して修正案を作成し、CodeQL で検証したうえでレビュー用のドラフト PR を開きます。

    何が変わる？

    • 修正から検証まで：Copilot が関連ファイルを調査し、修正案を作成して CodeQL を再実行。必要に応じて修正を繰り返し、ドラフト PR を開きます。PR には修正内容と検証手順の説明が含まれます。
    • 個別でも一括でも割り当て可能：アラートの Assign to Copilot を使うか、リポジトリのアラート一覧や Security campaign で最大 25 件を選択し、1 つの PR でまとめて修正できます。
    • デフォルトブランチが対象：PR や他のブランチでのみ検出されたアラートは Copilot に割り当てられません。
    • REST API：Update a Code Scanning Alert エンドポイントで assignees: ["copilot-swe-agent[bot]"] を指定して割り当てられます。

    利用条件と課金

    GitHub Enterprise Cloud（データ所在地を含む）の GitHub Code Security または GitHub Advanced Security 利用者が対象です。Enterprise 管理者が Agentic Autofix ポリシーを許可し、その後 Organization またはリポジトリの管理者が機能を有効化します。Copilot の支払い方法の設定が必要です。

    有効化すると、個別アラートの無料の Generate Fix が Assign to Copilot に置き換わります。Agentic Autofix は Code Security AI Credits と GitHub Actions の実行時間を消費します。AI Credits の使用量は Enterprise の課金画面の AI usage に Advanced Security として表示されます。

    パブリックプレビューを利用していた Organization も再度有効化する必要があります。提案された変更は、必ずレビューとテストを行ってからマージします。

    Autofix の公式ドキュメント / アクセスの管理

    デモで試すこと
    octodemo → Advanced Security の Global settings
    1. octodemo の Settings → Advanced Security → Global settings を開き、Code scanning にある Agentic Autofix を見せる。設定は変更しない。
    2. 導入の流れを説明する。まず Enterprise の Policies → Advanced Security で Agentic Autofix を許可する。その後 Organization で対象リポジトリ向けに有効化でき、リポジトリ管理者は個別にオプトアウトできる。
    3. 成果物とコストを説明する。Copilot は CodeQL で修正を検証してドラフト PR を作成する。セッションを開始すると Code Security AI Credits と GitHub Actions の実行時間を消費する。
    公式の更新情報を読む

  8. Copilot Slack / Teams の Copilot：1 つの会話で複数リポジトリを操作

    Slack や Teams の同じ会話から、@GitHub で複数リポジトリの Issue 作成、PR 作成、PR の確認、不具合調査ができます。

    覚えておきたいこと

    • 1 つの会話で複数リポジトリに対応：会話を新しく始めることなく、Issue 作成、コード修正と PR 作成、自分の未完了 PR の確認、フロントエンドとバックエンドをまたぐ不具合調査を依頼できます。
    • より自然なやり取り：@GitHub はメッセージの先頭だけでなく、どこに記載しても利用可能。リポジトリの切り替えもスムーズになりました。
    • 文脈と信頼性を改善：共有された Slack のメッセージやスレッドを文脈として活用。Slack と Teams の両方で、タスク開始、エラー処理、中断からの復旧を改善しました。

    以前のアップデート

    9 月 25 日のアップデートでは、Slack のファイルやメッセージリンク、Teams の画像、転送メッセージ、会話履歴を文脈として活用できるようになりました。会話中に選択を維持するモデル切り替え、Issue 作成前の類似 Issue の確認、元の会話へのリンクも追加されています。

    デモで試すこと
    1. Slack で @copilot settings を送信し、設定画面を開く。
    2. 利用可能な設定項目を紹介し、会話から直接 Copilot の各種設定を変更できることを見せる。
    公式の更新情報を読む

  9. Actions パブリックプレビュー Actions ワークフローの依存関係をロックファイルで固定

    ワークフローが使うアクションを、.github/workflows/actions.lock に記録したコミットに固定できるようになりました。タグやブランチが後から動かされても、レビューしたコードだけが実行されます。

    何が変わる？

    • これまでの問題：actions/checkout@v4 の v4 のようなタグやブランチは、後から別のコミットに付け替えられます。アクションが乗っ取られると、自分のリポジトリを一切変更していなくても、次の実行で別のコードが動きます。
    • ロックファイル：.github/workflows/actions.lock に、各アクション（推移的依存と再利用ワークフローを含む）の参照先コミットを記録します。ワークフローには @v4 のような参照を残したまま、実行されるのは記録したコミットです。owner_id と repo_id で、同名の別リポジトリにすり替わっていないかも確認されます。
    • gh actions-lock 拡張：ロックファイルの生成と更新に加え、CI 向けの --verify と、オフラインで pre-commit に使える --verify-local があります。ワークフローは 1 つずつ導入できます。
    • Require lockfile ポリシー：Enterprise、Organization、リポジトリの Actions ポリシーで、ロックファイルに載っていないワークフローの実行をブロックできます。
    • Dependabot：導入済みワークフローのアクションを更新するとき、同じ PR でロックファイルも更新します。未導入のワークフローを自動で導入することはありません。

    注意点

    ロックは「いつも同じコード」を保証するだけで、そのコードが安全かどうかは保証しません。 ロックする前に依存関係をレビューします。初回は @v4 が @v4.4.0 のように書き換わるので、差分も確認します。許可するアクションを指定している場合、許可リストはロック済みの SHA で照合されるため、タグで指定したエントリは一致しなくなります。GitHub Enterprise Cloud（データ所在地を含む）、Team、Free でパブリックプレビューです。

    ワークフロー依存関係のロックファイル（公式ドキュメント） / ロックファイルの作成手順 / Require lockfile の段階的な導入 / gh-actions-lock

    デモで試すこと
    このサイトの actions.lock theomonfort-org → Actions ポリシーを作成
    1. このサイトの actions.lock を開き、workflows（deploy.yml が使うアクション）と dependencies（各タグが指すコミット SHA と owner_id / repo_id）の 2 つのセクションを見せる。upload-pages-artifact の下に、推移的依存の upload-artifact が記録されている点も見せる。
    2. deploy.yml では actions/checkout@v4 が @v4.4.0 のような完全なバージョンに書き換えられている。ターミナルで gh actions-lock --verify .github/workflows/deploy.yml を実行し、ロックファイルが最新であることを確認する。
    3. theomonfort-org の Settings → Actions → Policies → New policy で Require lockfile をオンにする。まず Evaluate モードで対象リポジトリとワークフローを絞り、Policy insights でブロックされる run を確認してから Active にする。
    公式の更新情報を読む

  10. Copilot リサーチプレビュー HydraFusion の更新と HydraFusion Max の登場

    HydraFusion のモデルプールが最新のフロンティアモデルに更新され、推論エフォートの調整と Cascade / Critique のワークフローも改善。より難しいタスク向けに、高い推論エフォートを使う HydraFusion Max が加わりました。

    HydraFusion の変更点

    • 最新のフロンティアモデル：モデルプールが更新され、Claude Opus 5.5、GPT-6 Astra、GPT-6.1 Sol、GPT-6 Luna が含まれるようになりました。タスクごとに使うモデルはワークフローによって変わります。
    • ステップごとの推論エフォート：これまでは各モデルの既定値のみ。今回から、下書きは medium、レビューは high と段階ごとに調整し、下書きは効率よく、確認と改善には深い推論を使います。
    • Cascade：最初の回答を判定するステップが入り、必要なときだけ修正を依頼するようになりました。
    • Critique：テキストの要約に頼らず、ツールでワークスペースを直接確認。複数の批評モデルが並列でレビューします。

    HydraFusion Max とは

    HydraFusion と同じ仕組みとワークフローを使い、より難しいタスクでのフロンティア級の性能に合わせて調整したオプションです。深さが重要な場面では、より高い推論エフォート（extra high）を使いつつ、オーケストレーションでトークン効率も考慮します。

    • HydraFusion：速度、コスト、性能のバランス型で、トークンも適度に節約。一般的なエージェントタスク向け。
    • HydraFusion Max：最も深い推論と徹底した分析が必要なタスク向け。

    導入前に確認したいこと

    • 利用環境：VS Code、Copilot App、Copilot CLI のすべてで両方を選べます。
    • 対象プラン：Copilot Pro、Pro+、Business、Enterprise で、実験的機能またはプレビュー機能を有効にしている場合。Organization のモデルポリシーが適用されます。
    • 課金：これまでと同じく、使われた各モデルの通常料金で課金され、Auto の割引は適用されません。Max の使用量の目安は公表されていないため、同じタスクで HydraFusion と比べて確認するのがおすすめです。
    • リサーチプレビュー：SLA はなく、本番ワークロード向けではありません。

    3 つのワークフローと Auto との違いは 9 月 10 日の HydraFusion（CLI 版）、VS Code と Copilot App での有効化は 9 月 30 日の HydraFusion を参照。

    HydraFusion の使い方（公式ドキュメント） / フィードバック（GitHub Community）

    デモで試すこと
    1. 準備：Copilot CLI は copilot --experimental で起動して /model から、VS Code は chat.copilot.hydraFusion.enabled を有効にしてモデルピッカーから、Copilot App は Settings → Experimental で HydraFusion をオンにしてモデルピッカーから HydraFusion Max を選ぶ。
    2. デモ用リポジトリで、原因調査が必要なバグ修正など、目的と完了条件が明確な難しめのタスクを 1 つのプロンプトで依頼。進捗表示で、選ばれた実行パターン（Single / Cascade / Critique）と各ステップを見せる。
    3. 同じタスクを HydraFusion でも実行し、品質、所要時間、使用量を比べる。Copilot CLI では /usage でモデルごとの AI クレジット消費を確認できる。
    公式の更新情報を読む

  11. セキュリティ パブリックプレビュー Security overview で AI Scan の指標を確認

    Organization と Enterprise の security overview で、PR 向け AI Scan の検出数、解決数、修復率、Autofix 提案の適用状況を確認できるようになりました。

    覚えておきたいこと

    • ページ名と構成の変更：「CodeQL pull requests」は「Code scanning on pull requests」に名称変更され、CodeQL と AI Scan のタブに分かれました。これまでの指標は CodeQL タブにあります。
    • AI Scan タブの指標：検出数（Autofix 提案あり / なし）、解決数、修復率、検出のあったリポジトリ、選択期間のトレンド、開発者が Autofix 提案を適用した頻度。
    • 使い道：個々の PR を確認せずに AI Scan の効果と開発者の対応状況を把握し、展開範囲や投資の判断材料にできます。
    • 提供範囲：GitHub Code Security または GitHub Advanced Security の利用者向けのパブリックプレビュー。github.com（GitHub Enterprise Cloud を含む）で利用でき、GitHub Enterprise Server は対象外です。AI Scan タブはまだ CSV エクスポートに対応していません。

    AI Scan の有効化を API で管理する方法は 9 月 10 日の AI Scan API を参照。

    PR のコードスキャン指標の確認（公式ドキュメント） / AI Scan for PR / AI Scan Community discussion

    デモで試すこと デモを開く
    1. octodemo の Security and quality → Insights → Code scanning on pull requests を開き、CodeQL と AI Scan のタブを切り替える。
    2. AI Scan タブで検出数（Autofix 提案あり / なし）、解決数と修復率、リポジトリ別の内訳、期間内のトレンドを見せる。日付ピッカーで期間を変える。
    公式の更新情報を読む

  12. 管理 Enterprise 管理設定：起動時の強制更新とクライアントの最小バージョン

    Copilot クライアントの起動時に、キャッシュではなく最新のサーバー管理設定の取得を必須にできるようになりました。sandbox キーでは、クライアントの最小バージョンも強制されます。

    覚えておきたいこと

    • 強制更新：managed-settings.json に "forceRemoteSettingsRefresh": true（JSON の Boolean）を設定。Copilot CLI、VS Code、GitHub Copilot App が対応。有効な間はキャッシュでは起動できないため、ポリシー変更が Copilot の起動前に反映されます。
    • フェイルクローズ：最新のポリシーを確認できない場合、古いポリシーのまま動作しません。Copilot CLI は該当する操作を制限し、VS Code は更新が成功するまで Copilot 機能をブロック。起動時にネットワーク接続が必要です。
    • 適用タイミング：MDM やファイル配布なら、初回起動時（サインイン前）から適用。サーバー管理設定（.github-private）なら、一度受信した後の次回起動から適用。このキーがなければ、通常のキャッシュ（約 1 時間）を使用。
    • sandbox の最小バージョン：管理設定に sandbox キーがある場合、古いクライアントは更新するまでブロックされます。VS Code 1.141.0、Copilot CLI 1.0.93、GitHub Copilot App 1.1.26。

    Playbook：Copilot managed settings（スライド 11）

    起動時に最新設定を必須にする（公式ドキュメント） / forceRemoteSettingsRefresh リファレンス / sandbox のクライアント最小バージョン

    デモで試すこと
    1. theomonfort-org/.github-private → copilot/managed-settings.json を開き、sandbox キーと並んで "forceRemoteSettingsRefresh": true が設定されていることを見せる。
    公式の更新情報を読む

  13. セキュリティ Secret scanning：Anthropic キーを push protection で既定ブロック、Salesforce がパートナーに

    Anthropic の API キー 2 種類を新たに検出し、push protection で既定でブロックします。Salesforce が secret scanning パートナーに加わり、Cloudsmith の API キーも検出対象になりました。

    覚えておきたいこと

    • Anthropic キーを既定でブロック：anthropic_service_api_key と anthropic_user_api_key を新たに検出し、push protection の既定対象に追加。secret scanning が有効なリポジトリ（無料の public リポジトリを含む）では、これらを含むコミットの push が自動でブロックされます。
    • Salesforce がパートナーに：public リポジトリで salesforce_marketing_cloud_api_oauth2_token が見つかると、GitHub が Salesforce に通知し、Salesforce 側で失効やローテーションができます。
    • Cloudsmith も検出：cloudsmith_api_key がリポジトリ内で自動検出されるようになりました。
    • Partner と User の違い：Partner secret は public リポジトリで見つかると発行元に自動通知されます。User secret は public / private リポジトリでアラートを作成します。

    Playbook：何を検出するのか（スライド 4）

    サポートされている secret パターン（公式ドキュメント） / Secret scanning について / Secret scanning パートナープログラム

    デモで試すこと デモを開く
    1. octodemo の Pattern configurations を開き、anthropic で検索して anthropic_service_api_key と anthropic_user_api_key の GitHub default を見せる。設定は変更しない。
    2. 同じ画面の Enterprise setting 列で、既定値をパターン単位で上書きできることを説明する。本物の Anthropic キーは push しない。
    公式の更新情報を読む

  14. コードレビュー 一般提供 Copilot コードレビュー：Organization への課金とレビュー依頼の制限

    Copilot ライセンスを持つメンバーのコードレビューを、メンバーの利用枠ではなく Organization に課金できるようになりました。レビューを依頼できる人を、Organization または Enterprise が付与したライセンスの保有者に限定することもできます。

    覚えておきたいこと

    • Organization に課金：既定では、Copilot ライセンスを持つメンバーのレビューはそのメンバーの利用枠を消費し、枠を使い切るとレビューは失敗します。Organization を選ぶと、リポジトリを所有する Organization に課金され、メンバーの枠を消費しません。
    • 前提条件：Organization への課金には AI クレジットの有料利用（paid usage）の有効化が必要で、予算の設定は任意です。手動と自動の両方のレビューに適用されます。変わるのは課金先のみで、Copilot コードレビューの利用権限は付与されません。
    • 外部ライセンスを制限：既定では、有料の Copilot ライセンス（個人ライセンスや他の Organization のライセンスを含む）を持つ人なら、アクセスできるリポジトリでレビューを依頼できます。Only allow Copilot code review to be triggered by authorized users をオンにすると、自社の Organization または Enterprise が付与したライセンスのみ受け付けます。
    • 制限の範囲：権限のない人にはレビュアーとして Copilot が表示されず、API からの依頼でもレビューは始まりません。その人の個人設定による自動レビューも実行されませんが、リポジトリや Organization のルールセットによる自動レビューは実行されます。

    設定方法

    • Enterprise：AI controls → Agents → Copilot code review → Choose how members with a Copilot license are billed（Member / Organization / Let organizations decide）
    • Organization：Settings → Copilot → Code review → Choose how members with a Copilot license are billed と Only allow Copilot code review to be triggered by authorized users。後者をこの階層でオンにすると全リポジトリに適用され、リポジトリ管理者はオフにできません。
    • リポジトリ：Settings → Copilot → Code review → Only allow Copilot code review to be triggered by authorized users

    レビュー 1 回あたりの費用の目安は 10 月 2 日のコードレビュー を参照。

    コードレビューの設定（公式ドキュメント） / コードレビューの課金 / 外部ライセンスによるレビュー依頼

    デモで試すこと
    1. Organization の Settings → Copilot → Code review を開き、Choose how members with a Copilot license are billed（Member / Organization）を見せる。設定は変更しない。
    2. 同じ画面で Only allow Copilot code review to be triggered by authorized users を見せ、Organization でオンにするとリポジトリ管理者はオフにできないことを説明する。
    3. リポジトリの Settings → Copilot → Code review を開き、リポジトリ単位の同じトグルを見せる。
    公式の更新情報を読む

  15. コードレビュー 一般提供 Copilot コードレビュー：API からの依頼と Balanced の既定化

    REST / GraphQL API から Copilot のコードレビューを依頼し、リクエストごとにレビューの深さを指定できるようになりました。レビューの深さの Default は Balanced になりました。

    覚えておきたいこと

    • API でレビューを依頼：REST / GraphQL API から Copilot にレビューを依頼可能。レビューの深さはリクエストごとに任意で指定できます。独自のスクリプト、ワークフロー、社内ツールからレビューを開始できます。
    • Balanced が既定に：8 月 28 日の予告どおり、9 月 28 日から Default は Balanced を使用。新規と既存のリポジトリ、Organization が対象で、明示的に Lite を選んでいた設定はそのまま。
    • 費用に注意：Balanced は Lite より深く分析するぶん、AI クレジットの消費が増えます。目安は Lite が $0.05〜$1、Balanced が $0.25〜$5（レビュー 1 回あたり、Actions の実行時間は別）。
    • 対象プラン：Copilot Pro、Pro+、Max、Business、Enterprise。

    Lite に戻すには

    管理する階層で Default を Lite に変更します。各階層は上位の設定を上書きできます。

    • Enterprise：AI controls → Agents → Copilot code review
    • Organization / リポジトリ：Settings → Copilot → Code review
    • 個人：プロフィール → Copilot settings → Copilot → Code review

    個人設定と Enterprise の既定値は 9 月 23 日のコードレビュー設定 を参照。

    コードレビューの設定（公式ドキュメント） / レビューの深さと費用の目安

    デモで試すこと デモを開く
    1. 準備：Copilot コードレビューが使えるデモ用リポジトリで、小さな変更を含む PR を 1 件用意し、gh CLI にログインしておく。
    2. gh api -X POST repos/OWNER/REPO/pulls/NUMBER/requested_reviewers -f 'reviewers[]=copilot-pull-request-reviewer[bot]' を実行（OWNER / REPO / NUMBER はデモ用 PR に置き換える）。PR の Reviewers に Copilot が追加され、レビューが始まることを見せる。
    3. レビュー完了後、概要コメントで重大度と使われた effort level を確認する。
    4. Organization の Settings → Copilot → Code review を開き、Default（Balanced を使用）と Lite の選択肢を見せる。設定は変更しない。
    公式の更新情報を読む

  16. Copilot パブリックプレビュー Copilot がデスクトップアプリを操作できるように

    Copilot CLI / Copilot App の computer use で、クリック、入力、スクロールなどのアプリ操作を任せられます。API、CLI、MCP がない GUI 専用ソフトの作業も自動化の対象に。

    覚えておきたいこと

    • 既定はオフ：明示的な有効化が必要。macOS / Windows のローカルセッションが対象。
    • 操作前の承認：アプリを操作する前に承認を求めるかは、App / CLI それぞれのツール権限設定に従う。Always allow は同じ PC の App と CLI で共有され、App の設定から個別に削除可能。拒否ルールが常に優先。
    • 管理者が無効化できる：Enterprise の managed settings で features.computerUse を false にすると、ローカル設定では上書き不可。
    • 使いどころ：API、MCP、ターミナル、ブラウザ専用ツールで済む作業は、そちらの方が結果が安定。computer use は画面操作しか手段がない作業向け。UI の変化で誤ったボタンを押すこともあるため、データを変更する操作は必ず確認。画面に映る内容は Copilot のコンテキストになります。

    computer use の仕組みと制限（公式ドキュメント） / Copilot CLI での使い方

    デモで試すこと デモを開く
    1. 準備：Copilot App の Settings → Computer Use で Enable Computer Use をオン（CLI では /computer on、状態確認は /computer show）。macOS では Accessibility と Screen Recording の権限を付与。
    2. 機密情報を含まないデモ用アプリを開き、求める結果、対象アプリ、制約をまとめて依頼する。次のプロンプトの APP_NAME はインストール済みのアプリ名に置き換える。
    3. APP_NAME を開き、メインウィンドウに表示されているステータス情報を要約してください。値の変更やフォームの送信はしないでください。
    4. 承認プロンプトで、アプリと操作が依頼内容と合っているか確認してから Allow を選ぶ（デモでは Always allow を避ける）。セッション内のツール実行履歴を見せる。途中で止めるときは Stop または Esc。
    公式の更新情報を読む

  17. Copilot パブリックプレビュー Dynamic workflows：マルチエージェントの手順をコードで定義

    Copilot CLI / Copilot App / Copilot SDK で、自動化された手順と複数のエージェントの作業を組み合わせた処理の流れをコードで定義できます。同じ手順で繰り返し実行でき、一時停止や再開も可能です。

    覚えておきたいこと

    • 何ができる？：コマンドやツールの実行、タスクの並列実行、次のステージへの構造化された結果の受け渡し、サブエージェント同士の相互検証、確認のための一時停止と再開。
    • /fleet との違い：/fleet は分担のしかたを Copilot が毎回決める。dynamic workflow は、手順、条件、引き継ぎをワークフローの作者がコードで決める。
    • 作成と共有：Copilot に作成を依頼するか、組み込みのガイダンスを見ながら自分で書く。実体は Copilot の拡張機能で、既定ではそのセッション限り。個人またはリポジトリの拡張機能ディレクトリにコピーすると再利用や共有ができる。
    • 上限を設定：同時実行数、サブエージェントの総数、実行時間、AI クレジットの上限を指定可能。クレジットの上限は目安で、超えることもあるため、まず小さい範囲で試す。
    • 提供範囲：すべての Copilot プランで利用可能。CLI では copilot workflow run でターミナルやスクリプトから直接実行できる（権限は事前に付与が必要）。

    dynamic workflows の仕組み（公式ドキュメント） / autopilot、/fleet との違い

    デモで試すこと デモを開く
    1. 準備：Copilot App は設定不要。CLI では /update で最新版にし、/experimental on（または --experimental で起動）。デモ用リポジトリで、変更済みのファイルが数件ある状態にしておく。
    2. 変更されたファイルを一覧にし、エージェントにレビューさせて、指摘をまとめる review-changed という dynamic workflow を作成してください。
    3. 作成しただけでは実行されないことを伝え、「使える dynamic workflow は？」と聞いて登録を確認。次に、対象を 2〜3 ファイルに絞り、AI クレジットの上限を指定して実行を依頼する。
    4. CLI の /workflows または App の Workflows ボタンで、フェーズ、サブエージェント、AI クレジットの使用量を見せる。実行中のランは一時停止して、あとから再開できる。
    公式の更新情報を読む

  18. Copilot VS Code 1.136〜1.140 VS Code 9 月リリース：定期タスクから PR マージまでエージェントに

    VS Code 1.136〜1.140 のまとめ。Agents ウィンドウに Automations と Agent merge が登場し、実装から PR のマージまでをエージェントに任せやすくなりました。

    Agents ウィンドウ

    • Automations（プレビュー）：定型タスクを毎時 / 毎日 / 毎週、または手動で実行。テンプレートか独自のプロンプトから作成し、.automation.md ファイルでチームと共有可能。
    • Agent merge（プレビュー）：レビュー指摘、失敗したチェック、マージコンフリクト、ワークフローの再実行にエージェントが対応し、マージ可能になるまで繰り返す。chat.agentMerge.enabled を有効にし、Agents ウィンドウのセッションから開始。
    • PR 作成フォーム：Copilot、Claude、Codex のセッションから、タイトルと説明を確認、編集し、ドラフトやマージ設定を選んで PR を作成。
    • Dev Container でセッション実行：プロジェクトで設定したツールと依存関係でエージェントが作業。SSH、Tunnel、WSL のリモートホストにも対応。
    • セッション整理：PR マージ後の Mark as Done 提案、自動クリーンアップ、対応が必要なセッションのアプリバッジ（いずれもプレビュー）。

    チャットと GitHub 連携

    • Issue / PR をコンテキストに追加：Add Context から追加するか、新規セッションの入力欄に URL を貼り付け。説明文やコメントのコピペが不要に。
    • クイックチャットを後からプロジェクトへ：ワークスペースなしで始めたチャットに、会話を保ったままローカルフォルダーを紐づけ。
    • HydraFusion も VS Code で：対象ユーザーはプレビュー機能を有効にすると、モデルピッカーで選択可能（リサーチプレビュー）。詳しくは 9 月 30 日の HydraFusion を参照。

    VS Code 1.136〜1.140 の更新から、エージェント関連の主な機能をピックアップしました。プレビュー機能は順次展開中のため、設定が既定で有効になっていない場合があります。

    VS Code リリースノート / Agent merge の使い方

    デモで試すこと デモを開く
    1. 準備：VS Code を最新版に更新し、Agents ウィンドウを開く。サイドバーに Automations が表示されなければ、chat.automations.enabled を有効化。
    2. Automations → Create Automation を選び、デモ用リポジトリのワークスペースを指定。最初は Schedule を Manual にして、次のプロンプトで作成する。
    3. 現在のブランチで過去 24 時間のコミットを要約してください。機能追加、修正、メンテナンスに分け、コミットへの参照を付け、ドキュメント更新が必要そうな変更を指摘してください。ファイルは変更しないでください。
    4. Run now で実行し、History から結果のセッションを開いて見せる。そのあと Schedule を Daily に変更できることを示す。実行中は PC が起動していて VS Code または Agent Host が動いている必要があり、実行ごとに利用量を消費する。
    公式の更新情報を読む

  19. Copilot リサーチプレビュー HydraFusion が VS Code と Copilot App でも利用可能に

    Copilot CLI に続き、VS Code と Copilot App のモデルピッカーでも HydraFusion を選べるように。各ステップで何をしているかが見やすくなり、長いタスクでも進捗がリアルタイムに表示されます。

    何が新しい？

    • VS Code と Copilot App に対応：これまでは Copilot CLI の /experimental のみ。早期のフィードバックで最も要望が多かった点です。
    • 処理内容が見やすく：ワークフローの各ステップで何をしているかが、より明確に表示されます。
    • リアルタイムの進捗：進捗の更新頻度が上がり、長いタスクでもまだ処理中であることがわかります。

    導入前に確認したいこと

    • 対象プラン：Copilot Pro、Pro+、Business、Enterprise。Business / Enterprise では、Organization または Enterprise の設定でプレビュー機能の許可が必要。
    • 課金：使われた各モデルの通常料金で課金。Auto の割引は適用されず、1 つのタスクで複数のモデルを使うと AI クレジットの消費が増えることがあります。
    • モデルポリシーを尊重：プランと Organization / Enterprise のポリシーで許可されたモデルだけを使用。使うモデルは選べません。
    • リサーチプレビュー：SLA はなく、本番ワークロード向けではありません。

    Single / Cascade / Critique の 3 つのワークフローと Auto との違いは、9 月 10 日の HydraFusion（CLI 版） を参照。

    HydraFusion の使い方（公式ドキュメント） / フィードバック（GitHub Community）

    デモで試すこと デモを開く
    1. 準備（VS Code）：1.140 以降または Insiders で chat.copilot.hydraFusion.enabled を有効にし、Copilot Chat のモデルピッカーで Auto の下にある HydraFusion を選ぶ。
    2. 準備（Copilot App）：最新版に更新し、Settings → Experimental で HydraFusion をオンにして、モデルピッカーで選ぶ。Business / Enterprise では、管理者がプレビュー機能を許可している必要がある。
    3. デモ用リポジトリで、複数ファイルにまたがる修正など、目的と完了条件が明確なタスクを 1 つのプロンプトで依頼。各ステップの進捗を見せ、完了後に回答にカーソルを合わせて、使われたモデルを確認する。
    4. 同じタスクを Auto でも実行し、品質、所要時間、使用量を比べる。常に安い、常に高品質とは決めつけない。
    公式の更新情報を読む

  20. セキュリティ パブリックプレビュー Agentic Autofix が Copilot Memory で修正パターンを再利用

    Copilot Memory が有効なら、Agentic Autofix が既存のメモリを参考にセキュリティアラートを修正。新しい修正パターンも保存し、次の対応に活用します。

    覚えておきたいこと

    • 既存の知識を活用：リポジトリ固有の安全な開発パターンを、メモリから参照して修正に役立てます。
    • 修正から学習：新しい修正パターンを保存。後続のアラート対応や Copilot コードレビュー、Copilot cloud agent でも活用できます。
    • Copilot Memory の有効化が必要。Agentic Autofix と Copilot Memory は、どちらもパブリックプレビューです。

    Copilot Memory（公式ドキュメント）

    公式の更新情報を読む

  21. 管理 Enterprise の Copilot 管理設定を画面上で検証

    JSON の構文エラー、未対応の設定、無効なチーム割り当てなど、Copilot のポリシー適用を妨げる不備を検出できるようになりました。

    覚えておきたいこと

    • 確認場所：Enterprise → AI controls → Agents → Copilot settings validation。問題のあるファイルと JSON パスを表示。不備がなければ、このセクションは表示されません。
    • 検証対象：copilot/managed-settings.json、copilot/team-mappings.json と、チーム割り当てから参照される設定ファイル。
    • 修正方法：.github-private リポジトリの既定ブランチに修正をコミットし、Agents ページを再読み込みして確認。

    Playbook：Copilot managed settings（スライド 11）

    公式の更新情報を読む

  22. 管理 Usage metrics API に PR レビュー段階別の所要時間を追加

    リポジトリ単位の Copilot usage metrics に PR レビュー段階別の所要時間が追加。レビュー待ち、レビュー中、承認後マージ待ちのどこで時間がかかっているかを、中央値と 90 パーセンタイルで把握できます。

    何が測れる？

    Enterprise / Organization の repos-1-day レポートの各行に pull_request_review_times 配列が追加されました。3 つの段階それぞれについて、中央値と 90 パーセンタイル（分単位）を返します。

    • Ready for review → 最初のレビュー：誰かが見てくれるまでの待ち時間。
    • 最初のレビュー → 最後のレビュー：レビュアーとのやり取りにかかる時間。1 回のレビューで終わった場合は 0。
    • 最後のレビュー → マージ：承認後、マージされずに残っている時間。

    authored_by / reviewed_by（今回はどちらも human）、対象の件数 total_merged も含まれます。所要時間は マージされた日 に計上され、既存の pull_requests フィールドは変わりません。

    覚えておきたいこと

    • 人のレビューだけを計測：人が作成し、作成者以外の人が 1 人以上レビューした PR が対象。Copilot code review、その他の bot、作成者自身のレビューは除外されます。そのため total_merged は通常 pull_requests.total_merged より少なくなります。
    • バックフィルなし：データはリリース日以降のみ。2026 年 9 月 21 日より前に ready for review になった PR は対象外です。
    • 空配列はゼロではない：対象 PR がマージされなかった日は [] になります。
    • 利用条件：Copilot usage metrics policy の有効化が必要。Enterprise owner / billing manager、Organization owner、または View Copilot Metrics を持つカスタムロールでアクセスできます。

    Copilot usage metrics API

    公式の更新情報を読む

  23. Issues 一般提供 Issues に自分専用ビュー、Relates to が一般提供

    リポジトリの Issues 一覧に、自分専用の保存ビューが追加。「Relates to」による Issue の関連付けも一般提供になりました。

    覚えておきたいこと

    • よく使う一覧を保存：リポジトリの Issues ページで自分用のビューを保存。同じ検索を毎回やり直さずに戻れます。
    • 自分だけに表示：個人用の保存ビューなので、チーム全体には共有されません。
    • Relates to：Issue の関連付けが REST / GraphQL API、Webhook、タイムラインイベント、Issues / Projects の検索に対応。
    公式の更新情報を読む

  24. 管理 10 月 22 日適用 Copilot Business / Enterprise：GA 機能が既定で有効に

    このポリシーは 10 月 22 日から適用されます。管理者が既定ポリシーを変更しない限り、対象の GA 機能のうち未設定のものが自動で有効になります。

    覚えておきたいこと

    • 今から設定可能：AI Controls → Copilot → Default policy for new features で、有効、無効、組織に委任を選択。
    • 既存と今後の対象 GA 機能に適用。Copilot コードレビューと MCP サーバーも対象。
    • 明示的な機能設定は維持。プレビュー機能は引き続きオプトイン。

    対象範囲と例外（公式ドキュメント）

    デモで試すこと デモを開く
    公式の更新情報を読む

  25. セキュリティ パブリックプレビュー 重要な操作の前に Proof of presence で本人確認

    トークン作成、Webhook 編集、セキュリティ設定変更などの重要な操作の前に、IdP での再認証または MFA を必須にできます。

    覚えておきたいこと

    • 対象：Microsoft Entra ID を SSO の IdP（SAML / OIDC）として使う、github.com または GHEC-DR の EMU Enterprise。
    • 確認後 2 時間は再確認不要：同じブラウザーセッションでの重要な操作に適用。
    • PR マージはまだ対象外：今後対応予定。

    設定画面

    Enterprise の Settings → Authentication security → Proof of presence で、Sudo actions のポリシーを No policy / Re-authentication / MFA から選びます。

    Proof of presence の Sudo actions ポリシー選択画面

    設定方法（公式ドキュメント）

    デモで試すこと デモを開く
    公式の更新情報を読む

  26. コードレビュー 一般提供 Copilot コードレビュー：個人設定と Enterprise の既定値

    自動レビューとレビューの深さの個人設定が、Business / Enterprise を含むすべての Copilot プランで利用可能になりました。

    覚えておきたいこと

    • 個人設定：プロフィール → Copilot settings → Copilot → Code review。自分が作成または共同作成した PR の自動レビューを設定。ドラフトと追加 push は個別に切り替え可能。
    • レビューの深さの既定値：Lite または Balanced を選択。手動でレビューを依頼する際は変更可能。
    • Enterprise の既定値：Enterprise → AI controls → Agents → Copilot code review → Default review effort level。組織所有のリポジトリに Lite、Balanced、GitHub の既定値を設定。組織やリポジトリで上書き可能。
    公式の更新情報を読む

  27. Copilot パブリックプレビュー Copilot App にローカルサンドボックス

    Copilot App のローカルリポジトリ / ワークツリーセッションで、ファイル、ネットワーク、認証情報へのアクセスをプロジェクトごとに制限できます。

    覚えておきたいこと

    • 既定はオフ：デスクトップアプリの Settings → [project name] → Sandbox → Sandbox new sessions で、新規ローカルセッション向けに有効化。[project name] は対象プロジェクト名。実行中のローカルセッションでは /sandbox on でそのセッションだけを有効化。
    • 制限の変更：ファイル、ネットワーク、認証情報の設定変更は、新規セッションまたは再起動後に反映。
    • 保護なしで続行しない：OS がポリシーを適用できない場合、シェルはエラーで停止。
    • ローカルの App セッションのみ：クラウドやリモートホストは対象外。Copilot CLI の設定とは別。

    設定手順（公式ドキュメント）

    公式の更新情報を読む

  28. Copilot Copilot App の動きを OpenTelemetry で確認

    Copilot App のエージェントの動作データを、組織の監視ツールに送信できるようになりました。Enterprise の管理設定で一元的に構成します。

    覚えておきたいこと

    • 何をしたか追える：モデルへのリクエストやツールの利用を、OpenTelemetry 対応の監視ツールで順に確認。予期しない動作の調査に役立ちます。
    • 設定は一元管理：managed-settings.json の telemetry で送信を有効化し、送信先のエンドポイントを指定。
    • 内容は既定で収集しない：プロンプト、応答、ツールの引数は、有効化しない限り対象外。内容の収集を有効にする前に、機密情報への影響を確認してください。

    OpenTelemetry によるエージェント監視（公式ドキュメント）

    公式の更新情報を読む

  29. Copilot Copilot CLI の C++ コード探索が高速に

    C++ プロジェクト全体の関数やクラス、そのつながりを「地図」のように保存して再利用。開いていないファイルも対象です。

    覚えておきたいこと

    • 開発者にとってのメリット：「この関数はどこにある？」「どこで使われている？」を調べる待ち時間を短縮。アプリ自体の実行速度を上げる機能ではありません。
    • 使える場所：Windows、macOS、Linux の GitHub Copilot CLI。Microsoft C++ Language Server プラグインと、プロジェクトのビルド情報（compile_commands.json）の設定が必要。
    • セットアップ後は既定で有効：初回の索引作成には時間と追加メモリが必要。その後は再利用しながら更新されます。進行状況は /lsp logs で確認。

    セットアップと前提条件（公式ドキュメント）

    公式の更新情報を読む

  30. セキュリティ Enterprise 全体の認証情報一覧をエクスポート

    SSH キー、PAT、アプリの認証情報を Enterprise 全体で一覧化。アクセスの棚卸しやセキュリティインシデントの調査に活用できます。

    覚えておきたいこと

    • 画面と API に対応：Enterprise 設定から全件を CSV 出力し、ダウンロード後にユーザー、アプリ、種類、組織で絞り込み。ページネーション対応の REST API でレポートも自動化できます。
    • 秘密の値ではなくメタデータ：所有者、権限、作成日、有効期限、最終利用日を確認。トークンの値自体は含まれません。
    • 権限と提供範囲：Enterprise owner または View enterprise credentials 権限が必要。GitHub Enterprise Cloud で利用可能。Enterprise Server は今後のリリースで対応予定。

    認証情報の確認方法（公式ドキュメント）

    認証情報一覧のエクスポート（REST API）

    デモで試すこと デモを開く
    1. Settings → Authentication security → Credentials を開き、Overview の件数と Export CSV ボタンを見せる。CSV の絞り込みを実演する場合は、機密情報を除いたサンプルを使う。
    公式の更新情報を読む

  31. コードレビュー 一般提供 新しい PR 一覧が一般提供に

    リポジトリの新しい Pull requests ページが全 GitHub ユーザー向けに一般提供。高度な検索、一括操作、一覧で確認できる情報が充実しました。

    覚えておきたいこと

    • 検索条件を覚えなくても使える。 Content assist がフィルター入力を補助。AND / OR と入れ子の検索で条件を組み合わせられます。
    • 自分に関係する PR へ直行。 折りたたみ可能なサイドバーから「Authored by me」「Involves me」などを選べます。
    • 一覧だけで状況をつかみやすい。 ステータスチェック、スタック、未読更新、マイルストーン、関連 Issue を確認。コンパクト表示なら、より多くの PR を並べられます。
    • プレビューから進化：クローズ、ラベル、マイルストーンの一括操作に対応。レビュー状態をクリックして一覧を絞り込めます。
    デモで試すこと デモを開く
    1. サイドバーで「Authored by me」と「Involves me」を切り替え、自分が作成した PR と、自分が関わる PR を探す。
    2. 検索欄に「is」と入力して少し待ち、Content assist の候補からフィルターを選ぶ。
    3. 検索欄に入力：label:stacked-pr OR label:enhancement
    4. 一覧でスタックの表示とステータスチェックの件数や成功状況を確認する。
    5. コンパクト表示に切り替え、表示できる PR の数を比べる。
    6. PR を選択して一括操作メニューを見せる（変更は適用しない）。レビュー状態をクリックして一覧を絞り込む。
    公式の更新情報を読む

  32. コードレビュー 一般提供 Copilot レビューの進捗表示と修正提案が改善

    再レビューごとの指摘の変化を追いやすく。コメントを残す依頼を尊重し、修正提案の一括適用では変更に合ったコミットメッセージを生成します。

    覚えておきたいこと

    • 概要が見やすく：指摘を Open、Resolved since last review、Previously missed に分類。重大度とレビューに使った effort level も確認できます。
    • Previously missed：既存の変更から再レビューで新たに見つかった指摘は、概要内だけに表示。追加のインラインコメントは作成されません。
    • 自動解決が改善：コメントを開いたままにするよう返信すると、その依頼を尊重。後続コミットに応じて Won't Fix や Incorrect の理由付きで解決することもあります。
    • 修正提案の一括適用：対象となるバッチをすべてまとめてコミットすると、選んだ変更に合ったコミットタイトルと必要に応じた説明を生成します。
    公式の更新情報を読む

  33. 管理 Copilot impact dashboard に機能別の利用状況を追加

    開発者がどの Copilot 機能を継続的に使っているか、ダッシュボードと Enterprise / Organization のレポート API で確認できます。

    覚えておきたいこと

    • 画面で確認できる：機能ごとに、28 日間のうち 2 日以上利用したアクティブユーザー数を表示。追加のトレーニングが必要な機能を見つけやすくなります。
    • 機能別の内訳：コード補完、agent edit、コードレビュー（active / passive）、cloud agent、CLI、app。同じユーザーが複数の機能にカウントされる場合があります。
    • API も更新：copilot_feature_engagement で同じ件数を 28 日間の集計レポートに追加。ユーザー別レポートは対象外。users_in_phase_28d は当日の利用者だけでなく、各 AI adoption phase に属する直近 28 日間の全ユーザー数を返します。
    • 利用条件：Copilot usage metrics policy の有効化が必要。Enterprise owner / billing manager、Organization owner、または View Copilot Metrics を持つカスタムロールでアクセスできます。

    Copilot usage metrics API

    公式の更新情報を読む

  34. 管理 一般提供 Copilot の予算増額リクエストが一般提供

    Copilot の AI credits を使い切ったメンバーが予算増額を申請可能に。管理者は設定画面から承認、金額の調整、却下ができます。

    覚えておきたいこと

    • 対象：従量課金の Copilot Business / Enterprise。Enterprise Managed Users（EMU）は対象外です。
    • 承認者：Organization owner、Enterprise owner、billing manager。申請先は予算の支払元アカウントで、常に Enterprise に届くわけではありません。

    設定方法

    1. 申請を確認：支払元の Organization または Enterprise で Settings → Requests from members を開きます。
    2. 承認または金額を調整：変更後の予算総額を入力し、対象の申請を選んで Approve and increase をクリック。入力額は従来の上限を置き換える金額で、追加分ではありません。変更は即時反映されます。却下も可能です。
    3. 予算自体の設定は別画面：Billing & Licensing → Budgets and alerts を開きます。ユーザー単位の予算を作る場合は New budget → Bundled AI credits budget を選び、Budget scope を Users にします。

    支出の制御：ユーザー単位の予算は上限に達すると必ず利用を停止。それ以外の対応する予算では、Stop usage when budget limit is reached をオンにすると利用を停止し、オフでは停止しません。ユーザーの予算を増やしても、他の予算上限による停止は解除されません。

    増額リクエストの管理 / 予算の設定

    公式の更新情報を読む

  35. セキュリティ Advanced Security の設定を Organization にも強制

    Enterprise のセキュリティ構成を、Organization 管理者にも上書きさせない設定が追加。従来はリポジトリの owner だけが制限対象でした。

    Enforcement の選択肢

    Enterprise のセキュリティ構成で、Enforcement ドロップダウンから選びます。

    • Don't enforce：権限のある管理者が設定を変更できます。
    • Enforce for repository owners：リポジトリの owner は上書きできませんが、Organization owner は変更できます。
    • Enforce for repository and organization owners：今回追加された選択肢。Organization owner による上書きも防ぎ、Enterprise 全体でセキュリティポリシーを統一できます。

    セキュリティ構成（公式ドキュメント）

    公式の更新情報を読む

  36. Copilot 順次展開中 Auto のモデル選択に、コストと品質の優先度を指定

    Copilot Auto に Efficiency、Balance、Intelligence の 3 つの選択肢が追加。モデルの自動選択で何を優先するかを指定できます。

    覚えておきたいこと

    • Efficiency：コストを重視。短く、単純なタスク向け。
    • Balance：コスト、品質、応答時間のバランスを重視。日常的な作業向け。
    • Intelligence：品質を重視。複雑なタスク向け。

    3 つのモデルセットではない

    候補となるモデルは 3 つとも同じで、選択時の優先度が異なります。

    VS Code、Copilot CLI、GitHub Copilot app に順次展開中。料金は選んだ優先度ではなく、Auto が実際に選択したモデルに基づきます。有料サブスクライバー向けの Auto 利用分の 10% 割引は継続します。

    Hydra と HydraFusion

    Auto はモデルのルーティングに HyDRA を使用します。 HydraFusion はこの仕組みを発展させ、単独実行、上位モデルへの引き継ぎ、別モデルによるレビューといった処理の流れも選びます。Copilot CLI で実験的なリサーチプレビューとして利用できます。

    モデルが切り替わるタイミング

    以前はキャッシュを維持するため、セッション開始時とコンパクション後に再評価していました。現在の CLI と Copilot App は、会話中もモデルを定期的に再評価します。毎ターンではなく、最新のプロンプトと直近の会話を基に判断します。

    Auto model selection（公式ドキュメント）

    HydraFusion：モデル選択から処理の流れの自動選択へ（公式ブログ）

    Playbook：モデル選びと Auto モード（スライド 9）

    公式の更新情報を読む

  37. コードレビュー Copilot レビューが、対応済みコメントを自動で解決

    指摘を修正したコミットを push すると、Copilot が再レビュー時に自分のコメントを解決。修正提案のコミットメッセージと、レビュー内部の分析も改善されました。

    覚えておきたいこと

    • 自動解決は再レビュー時。 後続のコミットで指摘の原因が解消されると、Copilot が自分のコメントを解決します。単に push しただけで、全スレッドが閉じるわけではありません。
    • 未対応の指摘は残る。 開いているコメントから、まだ対応が必要なものを追いやすくなります。
    • 修正提案のコミットメッセージも改善。 一律の定型文ではなく、変更に応じた候補が生成されます。

    裏側の分析も変わる

    Copilot SDK のシェルツールを、Copilot agent firewall の内側で利用するようになりました。ビルド、テスト、対象を絞ったスクリプトなどでコードを検証する手段が増えます。ただし、毎回すべてのテストを実行する保証ではありません。

    Lite のレビューも複数エージェントで分析。 観点を集約して 1 つのレビューを返します。公式発表の品質向上やコスト削減の数値は実験結果であり、個々のレビューへの保証ではありません。レビューの依頼方法は変わりません。

    デモで試すこと
    1. デモ準備済み。用意した非公開デモリポジトリで、Copilot のレビューコメントを確認する。
    2. 指摘の一部だけを修正して push し、再レビュー後に対応済みコメントが解決され、未対応の指摘は残ることを見せる。
    3. Copilot の修正提案を適用し、変更内容に応じたコミットメッセージの候補を確認する。
    公式の更新情報を読む

  38. 管理 一般提供 VS Code Agents ウィンドウの利用を Metrics API で把握

    Copilot usage metrics に、VS Code の専用 Agents ウィンドウの利用者数、セッション数、ユーザーメッセージ数が追加。Organization と Enterprise の導入状況を追えます。

    「VS Code Agents」とは？

    VS Code の 専用 Agents ウィンドウ のことです。エージェントを中心に、複数のセッションやプロジェクトの作業を管理するための画面です。普段のエディターの Chat で使う Agent Mode とは別 で、今回の指標もエディター内の Agent Mode や一般的な利用集計とは分けられています。

    何が測れる？

    • Enterprise / Organization の集計レポート：daily_active_vscode_agent_users は日ごとのユニーク利用者数。totals_by_vscode_agent には session_count と total_user_messages が入ります。
    • ユーザー別レポート：used_vscode_agent は利用の有無。totals_by_vscode_agent で、そのユーザーのセッション数とメッセージ数を確認できます。
    • 1 日、28 日の両方に対応。 追加項目は任意で、対応するデータがなければ未出力または null のままです。

    対象者と読み方

    対象は導入率や利用傾向を把握したい管理者です。Enterprise owner / billing manager、Organization owner、または View Copilot Metrics を持つカスタムロールでアクセスでき、Copilot usage metrics policy の有効化が必要です。セッション数やメッセージ数は活動量であり、そのまま生産性や成果の評価にはなりません。

    Copilot usage metrics API / VS Code のエージェント体験

    デモで試すこと
    1. 専用 Agents ウィンドウと、通常のエディター内の Agent Mode を見比べる。今回の指標が対象にするのは前者のみ。
    2. 権限のある検証環境で 1 日と 28 日のレポートを取得し、集計レポートとユーザー別レポートの項目を確認する。実在ユーザーのデータを公開デモに出さない。
    3. フィールドが欠けている、または null の場合を確認する。データがない状態を、利用者ゼロと同一視しない。
    公式の更新情報を読む

  39. Actions 一般提供 Actions のキャッシュ権限を cache-mode で制御

    ワークフローやジョブごとに、キャッシュの復元と保存を制限できます。必要最小限の権限で、キャッシュ汚染のリスクを減らすための設定です。

    4 つのモード

    • read：復元のみ。保存は禁止。pull_request_target などの低信頼イベントの既定値。
    • write：復元と保存の両方を許可。「保存のみ」ではない点に注意。push などの信頼されたイベントの既定値。
    • write-only：保存のみ。復元は禁止。
    • none：復元も保存も禁止。

    ここがポイント

    ジョブ設定はワークフロー設定より優先されます。制限はキャッシュサービス側で強制され、再利用ワークフローにも引き継がれます。呼び出される側に、呼び出し元が許可した以上の権限を渡すことはできません。

    明示的な指定は、安全な既定値も上書きします。 低信頼イベントで write や write-only を指定するとキャッシュ汚染のリスクが増すため、警告が表示されます。未指定なら従来の安全な既定値が維持されます。github.com の全プランで一般提供です。

    cache-mode のワークフロー構文（公式ドキュメント）

    デモで試すこと
    1. デモは未検証。テスト用ワークフローで read、write-only、none を指定し、復元と保存の可否を確認する。
    2. ジョブ単位の指定がワークフロー単位より優先されることと、再利用ワークフローに渡せる権限の上限を確認する。
    3. pull_request_target などの低信頼イベントには、デモのためだけに書き込み権限を追加しない。
    公式の更新情報を読む

  40. セキュリティ パブリックプレビュー AI Scan for PR の有効化を API で管理

    Organization とリポジトリの AI Scan 設定を REST API で取得、更新できるように。対象リポジトリへの段階的な展開を自動化できます。

    覚えておきたいこと

    • 今回の追加は設定管理 API。 /orgs/{org}/code-scanning/ai-scan と /repos/{owner}/{repo}/code-scanning/ai-scan で、有効化状態を取得、更新できます。スキャンの即時実行や結果取得の API という意味ではありません。
    • 上位の設定を回避できない。 Organization 側が無効なら、リポジトリ設定で上書きしてスキャンを実行することはできません。
    • github.com 向け。 このリリースは GitHub Advanced Security の利用者向けで、GitHub Enterprise Server は対象外です。

    AI Scan 自体は何をする？

    CodeQL がカバーしていない言語やフレームワークの PR を AI で調べ、検出範囲を補完します。例は PHP、Shell/Bash、Terraform、Dockerfile など。現行ドキュメントでは、プレビューの利用に GHAS と Copilot のライセンス が必要で、AI クレジットを消費します。

    検出結果は助言であり、マージをブロックしません。 リポジトリ全体のスキャンや Security 画面のバックログアラートではなく、PR 上に表示されます。Fork 由来の PR と Dependabot の PR も対象外です。シークレットの Merge protection とは別の機能です。

    AI Scan の条件と制約（公式ドキュメント）

    デモで試すこと
    1. デモは要検証。まず Enterprise の許可、必要なライセンス、code scanning と AI Scan の設定を確認する。
    2. Organization とリポジトリの設定を API で取得し、Organization 側が無効ならリポジトリ側だけでは有効化できない点を確認する。
    3. 検証環境で段階的な有効化と無効化を試す。利用量と PR 上の検出結果も確認する。
    公式の更新情報を読む

  41. Copilot リサーチプレビュー HydraFusion：モデルだけでなく、解き方も自動で選ぶ

    Copilot CLI の /experimental に Project HydraFusion が登場。タスクに応じてモデルと実行パターンを選び、品質、コスト、待ち時間のバランスを取ります。

    覚えておきたいこと

    • Single：選んだ 1 つのモデルで直接解く。
    • Cascade：効率的なモデルでまず回答を作り、品質の基準を満たさなければ、より強力なモデルへ引き継ぐ。
    • Critique：別のモデルファミリーによる読み取り専用のレビューを挟み、元のモデルが 1 回修正する。

    Auto との違い

    HydraFusion は Auto のモデル選択をさらに発展させたものです。Auto がタスクに合うモデルを選ぶのに対し、HydraFusion は上位モデルへの引き継ぎや別モデルによるレビューなど、処理の流れまで選びます。現在は独立したリサーチプレビューであり、Auto の置き換えが発表されたわけではありません。常に複数モデルを使うわけでもありません。

    週次リリースの中から HydraFusion に絞ったピックアップです。品質やコストの公開評価は、特定条件でのオフライン実験の結果であり、実際のタスクで同じ効果を保証するものではありません。機能や名称も今後変わる可能性があります。

    HydraFusion の仕組みと評価結果（公式ブログ）

    Playbook：モデル選びと Auto モード（スライド 9）

    デモで試すこと
    1. Copilot CLI の /experimental で HydraFusion を有効にし、モデル選択で HydraFusion を選ぶ。
    2. 最初は、目的と完了条件が明確な実装タスクを 1 つのプロンプトで依頼する。長い対話を重ねる使い方より、単発のまとまったタスクが今回のプレビューの推奨対象。
    3. 通常の Auto と同じ課題で比較し、完了品質、所要時間、使用量を確認する。常に安い、常に高品質とは決めつけない。
    公式の更新情報を読む

  42. セキュリティ パブリックプレビュー シークレットを含む PR をマージ前にブロック

    Rulesets にシークレット検出アラートの解決を必須にするルールが追加。Push protection に加え、マージ時にもチェックを設けられます。

    覚えておきたいこと

    • Push とマージで、守るタイミングが違う。 Push protection はリポジトリに届く前に止める仕組み。新しいルールは PR のマージ時に追加のチェックを行います。
    • スキャン完了とアラート解決を確認。 PR の先頭コミットのシークレットスキャンが完了し、PR のコミットで新たに持ち込まれたシークレットの未解決アラートがないことが条件です。バイパス権限のない開発者は、各アラートの解決が必要です。
    • 対象を広げられる。 既定は Provider パターン。Custom や Generic パターンもマージのブロック対象に設定できます。

    ここがポイント

    たとえば、Push protection の対象を Provider のみにしつつ、重要なリポジトリではマージ時に Provider / Custom / Generic をチェックする構成が取れます。Push protection を置き換えるのではなく、補完する使い方です。

    GitHub Secret Protection または GitHub Advanced Security の利用者向けパブリックプレビューです。リポジトリ、Organization、Enterprise の Rulesets 設定で Require secret scanning alerts are resolved を有効にします。

    デモで試すこと
    1. 未紹介のデモ：Push protection は Provider パターンのみを対象にした構成を用意する。これはデモ用の設定で、製品の対応範囲を意味するものではない。
    2. 重要なリポジトリの Ruleset で「Require secret scanning alerts are resolved」を有効にし、Provider に加えて Custom と Generic もブロック対象にする。
    3. 安全なテスト用データを使い、Push 時には止まらないケースでも、PR のマージ時にはブロックされることを確認する。実際の認証情報は使わない。
    公式の更新情報を読む

  43. セキュリティ 一般提供 Copilot App / CLI がコンテンツ除外に対応

    Copilot App / CLI が Enterprise、Organization、リポジトリのコンテンツ除外ポリシーに対応。エージェントの作業でも、除外ファイルをコンテキストに使わなくなります。

    Agent mode でも使える？

    • Copilot App / CLI のエージェント作業は対象：従来の対応するコード補完やチャットに加え、今回これらのエージェントツールにも対応が広がりました。
    • VS Code の Agent / Edit mode は別：公式ドキュメントでは、VS Code などのエディター内のこれらのモードは引き続き対象外。すべての Copilot エージェントに対応したという意味ではありません。

    覚えておきたいこと

    • Business / Enterprise 向け：管理者が設定した除外ポリシーを App / CLI が尊重します。
    • ファイルアクセスを隔離する sandbox とは別：Copilot がコンテキストに使う内容を制御する機能です。シンボリックリンク、リモートファイルシステム、IDE が間接的に渡す型情報などには、引き続きドキュメント上の制限があります。

    対応範囲と制限 / コンテンツ除外の設定

    公式の更新情報を読む

  44. コードレビュー パブリックプレビュー Copilot code review が PR を承認可能に

    すべての Copilot レビューに承認可否の評価を表示。管理者は実際の承認も有効化でき、マージに必要な承認数へ含めるかを選べます。

    覚えておきたいこと

    • 評価と承認は別：概要コメントに Copilot の判断が表示されますが、それだけではマージ要件を満たしません。実際の承認は既定でオフです。
    • 新しいコミットには再レビューが必要：追加コミットを push すると Copilot の承認は取り消されます。改めてレビューを依頼して、新しい承認を得ます。
    • 対象プラン：Copilot Pro、Pro+、Max、Business、Enterprise のパブリックプレビュー。

    設定方法

    対象リポジトリに適用される階層で設定します。

    1. Enterprise 配下の場合：AI controls → Copilot code review を開き、Allow Copilot to approve pull requests を Let organizations decide に設定（特定の Organization だけを有効にすることも可能）。
    2. Organization 配下の場合：Settings → Copilot → Code review → Approvals を開き、Count Copilot approvals toward merge requirements を Let repositories decide に設定。
    3. Repository：Settings → Copilot → Code review → Auto-approval で Allow Copilot to approve pull requests を有効化。
    4. 承認数に含めたい場合：別途 Allow Copilot approvals to count toward merge requirements も有効化。承認を投稿する設定と、マージ要件に数える設定は別です。
    5. 対象を絞る：File paths に docs/** などの glob を 1 行ずつ入力。承認がカウントされるには、変更されたすべてのファイルがいずれかの glob に一致する必要があります。空欄なら全ファイルが対象。最大 15 個まで設定できます。

    設定手順（公式ドキュメント）

    公式の更新情報を読む