Windows版Visual Studioの「Add GitHub accounts to your keychain」が2026年7月8日に更新されたように見えても、この日付だけを理由に緊急対応する必要はありません。公式ドキュメントの変更履歴を確認すると、直近の更新は記事本文や製品仕様ではなく、ドキュメントの担当者情報を変更したものです。ページ上の実質的な更新日は、引き続き2026年2月18日となっています。(GitHub)
ただし、現在のVisual Studioでは複数のGitHubアカウントを登録でき、どのアカウントを「アクティブ」にするかによって、GitHub Copilot、リポジトリへのアクセス、Visual Studio内のGitHub認証に影響します。個人用と業務用のGitHubアカウントを併用している環境や、GitHub Enterpriseを利用している組織では、仕様を理解したうえで動作確認と運用ルールの整備が必要です。(Microsoft Learn)
2026年7月8日の更新で実際に変わったもの
公式ドキュメントのGitHubリポジトリでは、対象ページに対して2026年7月7日付で「Update authors」というコミットが行われています。日本時間では7月8日前後の更新として検知される可能性がありますが、変更されたのは次のメタデータだけです。
| 確認項目 | 変更内容 | 実務への影響 |
|---|---|---|
author | ghogenからnitinmeへ変更 | なし |
ms.author | ghogenからnitinmeへ変更 | なし |
ms.date | 02/18/2026のまま | 製品仕様の更新日ではない |
| 記事本文 | 変更なし | 手順、利用条件、認証動作に変更なし |
| Visual Studioの機能 | このコミットでは変更を確認できない | 緊急展開や設定変更は不要 |
つまり、2026年7月8日の更新は、少なくとも公開されている差分を見る限り、AI機能やGitHub認証機能のリリースではなく、ドキュメント管理上の変更です。(GitHub)
Microsoft Learnの更新通知を自動収集している組織では、「ページが更新された」という情報だけで対応チケットを起票すると、今回のようなメタデータ変更も製品変更として扱ってしまいます。更新監視では、次の3種類を分けて判定すると誤検知を減らせます。
- 本文、手順、要件の変更
- 対応バージョンや公開日などのメタデータ変更
- 著者、タグ、内部管理情報だけの変更
今回の更新は3番目に該当します。
Visual Studioの「キーチェーンにGitHubアカウントを追加」とは
ここでいうキーチェーンは、Visual Studioが利用するサインイン済みアカウントの集合です。ユーザーが行う操作はWindowsの資格情報管理画面ではなく、Visual Studio右上のプロファイルカード、または「ファイル」から開く「アカウント設定」で行います。
GitHubアカウントを追加すると、主に次の機能でそのアカウントが利用されます。
- GitHub Copilotのライセンス確認と認証
- GitHubリポジトリのクローン、取得、プル、プッシュ
- Visual Studio内の一般的なGitHub認証
- GitHub Actionsを使ったビルドやデプロイ作業
パブリックGitHubアカウントを追加するだけなら、Microsoftアカウント、職場アカウント、学校アカウントでVisual Studioにサインインしている必要はありません。また、1つのVisual Studio環境に複数のGitHubアカウントを登録できます。(Microsoft Learn)
アクティブアカウントが重要になる
複数のGitHubアカウントを登録すると、その中の1つが「アクティブアカウント」になります。アカウント設定から追加したGitHubアカウントは、追加直後にアクティブアカウントになるため、業務用アカウントを使用中に個人用アカウントを追加した場合は注意が必要です。
アクティブアカウントは、プロファイルカードまたはアカウント設定から切り替えられます。(Microsoft Learn)
既存の認証設定やGit実装との互換性
GitHubアカウントをVisual Studioへ追加しても、既存のMicrosoftアカウント、Git設定、資格情報ヘルパーがすべて置き換えられるわけではありません。次の要素を分けて考える必要があります。
| 既存の要素 | GitHubアカウント追加との関係 | 確認すべきこと |
|---|---|---|
| Microsoftアカウント | GitHubアカウントと併存可能 | Visual Studio設定を同期する場合はMicrosoftアカウントも必要 |
| 複数のGitHubアカウント | 登録可能 | どのアカウントがアクティブか |
| GitHub Copilot | アクティブなGitHubアカウントを参照 | 対象アカウントにCopilot利用権があるか |
| Gitのユーザー名・メール | Git設定として別に管理 | user.nameとuser.emailが正しいか |
| HTTPS認証 | Git資格情報ヘルパーが関与 | GCMまたはシステム設定のどちらを使っているか |
| 設定のローミング | GitHubアカウントだけではVisual Studio設定を同期できない | Microsoftアカウントによる同期が必要か |
| 別のWindows端末 | アカウントの構成はローミングする場合がある | 資格情報はローミングしないため再認証が必要 |
| Visual Studioからのサインアウト | 個別アカウント削除とは動作が異なる | 全アカウントが削除される点に注意 |
Visual StudioにGitHubアカウントを表示できたからといって、コミットの作成者情報まで自動的に正しくなるとは限りません。コミットに記録される名前とメールアドレスは、Gitのグローバル設定またはリポジトリ設定で管理されます。(Microsoft Learn)
また、Visual StudioがHTTPSリモートに対してGit操作を行う際は、credential.helperで指定された資格情報ヘルパーが利用されます。設定値がGCMならGit Credential Managerが使われ、未設定ならシステム構成で指定された資格情報ヘルパーが利用されます。GitHubアカウントを追加しただけで検証を終えず、実際のフェッチとプッシュまで確認することが重要です。(Microsoft Learn)
GitHubアカウントとコミット作者は別に確認する
個人用と業務用のGitHubアカウントを併用する場合は、対象リポジトリで次のコマンドを実行します。
git remote -v
git config --show-origin --get user.name
git config --show-origin --get user.email
git config --show-origin --get-all credential.helper確認するポイントは次のとおりです。
git remote -vが意図したGitHubまたはGitHub Enterpriseの接続先になっているuser.nameが業務上使用する名前になっているuser.emailが会社指定のメールアドレスになっているcredential.helperの設定元が想定どおりである- リポジトリ設定がグローバル設定を上書きしていない
業務用リポジトリでは、必要に応じてリポジトリ単位でメールアドレスを指定すると、個人用リポジトリへの影響を抑えられます。
git config user.name "業務用の表示名"
git config user.email "業務用メールアドレス"利用条件はVisual Studioのバージョンとアカウント種別で異なる
公式ページはVisual Studio 2022以降を対象としています。ただし、ドキュメントに記載されている17.13や17.14というバージョンは、GitHubアカウント追加機能全体の最低条件ではなく、主に初回起動時の操作に関する条件です。
| 機能 | 利用条件 |
|---|---|
| アカウント設定からGitHubアカウントを追加 | Visual Studio 2022以降の対象環境 |
| 初回起動時にGitHubアカウントでサインイン | Visual Studio 17.13以降 |
| 初回起動時にCopilot Freeを有効化 | Visual Studio 17.14以降 |
| 後からGitHubアカウントを追加 | プロファイルカード、アカウント設定、Copilot Chatから実行可能 |
| 管理者がCopilotを無効化している環境 | 初回起動時にもグループポリシーが反映される |
「17.14未満だからGitHubアカウントを追加できない」と判断するのは誤りです。17.14以降という条件は、Copilot Freeを初回起動時に有効化する操作に対するものです。(Microsoft Learn)
GitHub Enterpriseでは追加方法を選び分ける
Visual Studioでは、既定でパブリックGitHubアカウントだけが有効になっています。GitHub Enterprise Serverや.ghe.comのアカウントを使う場合は、Enterpriseアカウントを含める設定を事前に有効化します。
| 利用環境 | 選択する方法 | 注意点 |
|---|---|---|
通常のgithub.com | GitHubを選択 | Enterprise設定は不要 |
github.com/enterprises/配下のEnterprise Cloud | 通常のGitHubを選択 | GitHub EnterpriseではなくパブリックGitHubの手順を使う |
.ghe.comエンドポイント | GitHub Enterpriseを有効化 | Enterprise URLの入力が必要 |
| GitHub Enterprise Server | GitHub Enterpriseを有効化 | サーバーURLとブラウザー認証を確認 |
| Enterprise Managed User | GitHub Enterpriseを選択 | 組織から指定されたEMUユーザー名を正確に使用 |
現行Visual Studioでは、次の設定画面からEnterpriseアカウントを有効にします。
ツール
> オプション
> すべての設定
> 環境
> アカウントVisual Studio 2022では、次の場所を確認します。
ツール
> オプション
> その他のアカウントその後、「GitHub Enterprise CloudとGitHub Enterprise Serverアカウントを含める」を有効にします。(Microsoft Learn)
GitHub Enterprise Managed Userでは、ユーザー名にアンダースコアと企業・Enterpriseを識別する文字列が含まれる場合があります。個人用GitHubアカウントのユーザー名を入力せず、組織から割り当てられた認証情報を使用してください。(Microsoft Learn)
なお、GitHub Enterprise ServerのアカウントはVisual StudioのGit認証に利用できますが、GitHubの現行ドキュメントでは、GitHub CopilotはGitHub Enterprise Serverでは利用できないとされています。Enterprise Serverへのサインイン成功を、そのままCopilotの利用条件を満たしたものと判断しないようにしてください。(GitHub Docs)
Visual StudioにGitHubアカウントを追加する手順
事前に現在の状態を記録する
変更前に、次の情報を記録します。
- Visual Studioのバージョン
- 現在登録されているMicrosoftアカウントとGitHubアカウント
- 現在のアクティブなGitHubアカウント
- GitHub Copilotの状態
- 対象リポジトリのリモートURL
- Gitのユーザー名とメールアドレス
- 使用中の資格情報ヘルパー
画面のスクリーンショットだけでなく、前述のgit configコマンドの結果も保存しておくと、問題発生時に変更前後を比較できます。
パブリックGitHubアカウントを追加する
- Visual Studioを起動します。
- 「ファイル」を選択します。
- 「アカウント設定」を開きます。
- 「すべてのアカウント」で「追加」を選択します。
- 「GitHub」を選択します。
- 既定のブラウザーでGitHubにサインインします。
- 認証成功画面を確認してVisual Studioに戻ります。
- 追加したアカウントが「すべてのアカウント」に表示されていることを確認します。
- アクティブアカウントが意図したアカウントか確認します。
ブラウザー認証後に追加されたアカウントは、アクティブアカウントになることがあります。複数アカウント環境では、追加直後に必ずプロファイルカードを確認してください。(Microsoft Learn)
アクティブアカウントを切り替える
- Visual Studio右上のプロファイルアイコンを選択します。
- 使用するGitHubアカウントのメニューを開きます。
- 「アクティブなアカウントとして設定」を選択します。
- Copilotの状態とリポジトリアクセスを再確認します。
GitHub Copilotは、アクティブなGitHubアカウントに有効なCopilotサブスクリプションがない場合、非アクティブになることがあります。Copilotの契約を持つアカウントを登録済みでも、そのアカウントがアクティブでなければ利用できない点が重要です。(Microsoft Learn)
導入後に実施すべきテスト
アカウント一覧に表示されたことだけをもって、導入完了と判断してはいけません。認証、権限、コミット情報、Copilotを分けてテストします。
| テスト項目 | 確認方法 | 合格条件 |
|---|---|---|
| アカウント登録 | プロファイルカードを開く | 対象アカウントが表示される |
| アクティブアカウント | アカウントメニューを確認 | 業務で使用するアカウントがアクティブ |
| Copilot | 状態アイコンとチャットを確認 | 契約・ポリシーに応じた状態になる |
| リポジトリ取得 | テスト用リポジトリでフェッチまたはプル | 認証画面がループせず完了する |
| プッシュ | テスト用ブランチをプッシュ | 意図したアカウントの権限で成功する |
| 権限境界 | アクセス権のないリポジトリも確認 | 不正にアクセスできず、適切に拒否される |
| コミット作者 | テストコミットを作成 | 名前とメールアドレスが正しい |
| Actions連携 | 対象組織で使用する場合に確認 | ワークフローの参照・実行権限が正しい |
| 再起動 | Visual Studioを終了して再起動 | アカウントと認証状態が維持される |
| 別端末 | 別のWindows端末でサインイン | 必要に応じて再認証が求められる |
| ロールバック | 個別アカウントを削除 | 他のアカウントを残したまま削除できる |
プッシュテストは、本番ブランチではなく、削除可能なテストリポジトリまたは作業用ブランチで行います。クローンやフェッチだけでは、書き込み権限やブランチ保護との組み合わせを確認できません。
認証テストで失敗しやすいポイント
localhostのHSTS設定でブラウザー認証に戻れない
Visual StudioのGitHub認証では、既定のブラウザーを使ったサインイン後にVisual Studioへ戻ります。この処理で問題が起きる場合は、既定ブラウザーでlocalhostにHSTSが設定されていないか確認します。
Microsoft Edgeでは、次の内部ページを開きます。
edge://net-internals/#hstsGoogle Chromeでは、次の内部ページを開きます。
chrome://net-internals/#hstslocalhostに対するHSTSポリシーが登録されている場合は、組織のセキュリティ方針を確認したうえで削除し、認証を再実行します。(Microsoft Learn)
Visual Studioの実行ユーザーがWindowsのログオンユーザーと異なる
Windowsにサインインしているユーザーと、devenv.exeを実行しているユーザーが異なると、GitHubアカウントの追加に失敗する場合があります。
特に注意が必要なのは、次の環境です。
- Visual Studioを別の管理者アカウントで実行している
- 特権管理ツールがVisual Studioを昇格起動している
- 共有端末で別ユーザーのプロセスが残っている
- 開発ツールを自動起動する製品が別資格情報を使用している
タスクマネージャーの「詳細」タブでdevenv.exeを探し、実行ユーザーが現在のWindowsログオンユーザーと一致することを確認してください。(Microsoft Learn)
別端末では資格情報の再入力が必要になる
複数アカウントの構成が別の端末へローミングしても、アカウントの資格情報そのものはローミングしません。新しいPCや再構築した開発環境では、リポジトリへ初めてアクセスするときに再認証が求められることがあります。(Microsoft Learn)
VDI、非永続デスクトップ、端末を頻繁に初期化する開発環境では、再認証が通常動作なのか、資格情報の保存不良なのかを切り分ける必要があります。
「サインアウト」は個別アカウント削除ではない
プロファイルカードの「サインアウト」を実行すると、Visual Studioキーチェーン上のすべてのアカウントが削除されます。1つのGitHubアカウントだけを戻したい場合は、「アカウントの削除」を使用してください。
また、Microsoftアカウントが個人用設定アカウントになっている環境では、そのMicrosoftアカウントを削除すると、すべてのアカウントが削除される場合があります。ロールバック手順では、個別削除と全体サインアウトを明確に区別する必要があります。(Microsoft Learn)
組織での対応要否を判断する基準
| 利用状況 | 対応要否 | 推奨する対応 |
|---|---|---|
| 2026年7月8日の更新通知だけを検知した | 緊急対応不要 | メタデータ変更として記録する |
| パブリックGitHubを1アカウントだけ使用 | 原則として設定変更不要 | アクティブアカウントとGit操作を確認する |
| GitHub Copilotを個人契約で使用 | 確認推奨 | Copilot契約のあるアカウントがアクティブか確認する |
| 個人用と業務用GitHubを併用 | 対応推奨 | アクティブアカウントとコミットメールの運用ルールを定める |
| 組織がCopilotライセンスを割り当てている | 対応推奨 | ライセンス、アクティブアカウント、管理ポリシーをセットで確認する |
.ghe.comを使用 | 事前検証が必要 | Enterpriseアカウント設定とエンドポイントを確認する |
| GitHub Enterprise Serverを使用 | 事前検証が必要 | Git認証とCopilotの可否を別々に判定する |
| Enterprise Managed Userを使用 | 事前検証が必要 | EMU専用ユーザー名と認証経路を確認する |
| Visual Studioを管理者権限で起動 | 対応が必要な場合あり | devenv.exeの実行ユーザーを確認する |
| VDIや共有端末で使用 | 対応推奨 | 資格情報の保持、再認証、サインアウト動作を確認する |
管理ルールとして決めておきたいこと
複数アカウントを許可する組織では、最低限、次のルールを決めておくと運用事故を防ぎやすくなります。
- 業務リポジトリを操作するときは業務用GitHubアカウントをアクティブにする
- 業務用リポジトリでは
user.emailをリポジトリ単位で確認する - HTTPS認証で使用する資格情報ヘルパーを統一する
- アカウント追加後はフェッチだけでなくプッシュまで試験する
- Copilotの利用可否はアカウント、ライセンス、組織ポリシーの3点で判定する
- ロールバックでは全体サインアウトではなく個別アカウント削除を優先する
- ドキュメント更新監視では本文差分とメタデータ差分を分離する
GitHubアカウントはリポジトリアクセスにも利用されるため、Copilotをグループポリシーで無効化しているだけでは、GitHub認証全体の管理にはなりません。AI利用の管理と、ソースコードへのアクセス管理は分けて設計する必要があります。(Microsoft Learn)
今回の更新に対して取るべき対応
2026年7月8日前後に検知された「Add GitHub accounts to your keychain」の更新は、ドキュメントの著者情報変更であり、製品仕様の変更ではありません。そのため、更新日だけを理由としたVisual Studioの緊急アップデートや、全端末への設定変更は不要です。(GitHub)
一方で、現行仕様ではアクティブなGitHubアカウントがCopilotとGitHub認証に影響します。まず対象端末を1台選び、アクティブアカウント、Copilotの状態、Gitのuser.email、資格情報ヘルパー、フェッチとプッシュを確認してください。
単一アカウント環境で問題がなければ、確認結果を記録して対応を完了できます。複数アカウント、GitHub Enterprise、EMU、VDIを利用している場合は、テスト結果をもとにアカウント切り替えと再認証の運用手順を整備することが、実務上の適切な対応です。
コメント