エラーの内容
fatal: Authentication failed for 'https://github.com/username/repo.git/'
これは突然やってくるエラーです。何ヶ月も同じリポジトリにプッシュし続け、ずっと問題なく動いていたのに、ある朝突然すべての git push と git pull がこのエラーで失敗するようになる。コードの変更もなし。設定の変更もなし。何も心当たりがない。
Windows の場合、原因はほぼ確実に Windows 資格情報マネージャーが古くなった GitHub トークン、またはGitHub が受け付けなくなったパスワードをキャッシュしていることです。そのキャッシュエントリを削除すれば、2分以内に元通りになります。
なぜこのエラーが発生するのか
Windows 資格情報マネージャーは、初回認証時に GitHub の認証情報を保存します。これにより、プッシュのたびに入力する手間が省けます。しかし、保存された認証情報が古くなると問題が起きます。よくあるトリガーは以下の通りです：
- GitHub 上で個人アクセストークン（PAT）をローテーションまたは削除した
- GitHub アカウントのパスワードを変更した
- パスワード認証から PAT に移行した（GitHub は 2021 年 8 月にパスワードベースの HTTPS 認証を廃止）
- 同じマシンで複数の GitHub アカウントを切り替えた
これらのいずれかが発生すると、Git は古い認証情報を黙って送り続けます。GitHub はその都度拒否します。それが fatal: Authentication failed の原因です。
修正手順
方法 1: Windows 資格情報マネージャーの UI から削除する（最も簡単）
- スタート を開いて 資格情報マネージャー を検索し、起動します。
- Windows 資格情報 タブをクリックします。
git:https://github.comまたはGitHubで始まるエントリを探します。- エントリをクリック → 削除 をクリック → 確認します。
- 再度
git pushを実行すると、Windows が新しい認証情報の入力を求めます。
方法 2: コマンドラインから削除する（より素早い）
PowerShell またはコマンドプロンプトを開き、以下を実行します：
cmdkey /delete:LegacyGeneric:target=git:https://github.com
正確なターゲット名がわからない場合は、GitHub 関連のエントリを先に一覧表示します：
cmdkey /list | findstr /i github
出力からターゲット名をコピーし、削除します：
cmdkey /delete:LegacyGeneric:target=git:https://github.com
方法 3: Git の資格情報ヘルパーを直接使う
Git Credential Manager には独自の削除コマンドがあります。ターミナルで以下を実行します：
git credential-manager erase
次に、以下を正確にそのまま入力し、Enter を 2 回押して EOF を送信します：
protocol=https
host=github.com
GCM が利用できない古い Git バージョン（2.29 未満）では、代わりに下位レベルのコマンドを使います：
git credential reject
protocol=https
host=github.com
username=your-github-username
PAT で再認証する
古い認証情報を削除した後、次の git push でユーザー名とパスワードの入力を求められます。ここで注意が必要です — GitHub アカウントのパスワードは入力しないでください。GitHub は 2021 年 8 月に HTTPS のパスワード認証を廃止しました。代わりに個人アクセストークンが必要です：
- GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic) に移動します。
- Generate new token (classic) をクリックします。
- 名前を付け、有効期限を設定し（90 日が妥当なデフォルト）、
repoスコープにチェックを入れます。GitHub Actions の設定をプッシュする場合はworkflowも追加します。 - トークンをすぐにコピーします — GitHub は一度しか表示しません。
- Git がパスワードを求めたら、そこにトークンを貼り付けます（ユーザー名フィールドではありません）。
Windows 資格情報マネージャーが新しいトークンを自動的に保存します。次回以降のプッシュはプロンプトなしで通るようになります。
方法 4: SSH に切り替える（恒久的な解決策）
トークンの有効期限に悩まされたくない場合、SSH にはこの問題がありません。コマンド一つでリモートを切り替えられます：
git remote set-url origin git@github.com:username/repo.git
事前に SSH キーを GitHub アカウントに登録する必要があります。それ以降は、認証が自動的に行われ、トークン不要で無期限に使えます。
修正の確認
小さなものをプッシュして確認します：
git push origin main
または、何もプッシュせずにテストします：
git ls-remote origin
エラーなしで refs（HEAD、ブランチ、タグ）が一覧表示されれば、解決しています。資格情報マネージャーに今何が保存されているか確認したい場合は：
cmdkey /list | findstr /i github
新しいエントリが表示されるはずです。古い古くなったエントリは消えています。
補足
PAT の有効期限が最も多い再発原因です。 トークン作成時、GitHub では 7 日、30 日、60 日、90 日、または無期限を選べます。有効期限なしのトークンは便利ですが、セキュリティ上のリスクがあります。私は 90 日に設定し、有効期限の 10 日前にカレンダーリマインダーを追加しています。そうしないと、プッシュの途中、デモの最中、最悪のタイミングでこのエラーに遭遇することになります。
PAT はパスワードと同様に厳重に管理してください。 repo スコープを持つトークンは、すべてのプライベートリポジトリへの完全な読み書きアクセス権を持ちます。Slack に貼り付けたり、スクリプトにハードコードしたり、どこかにコミットしたりしないでください。API キーやテスト用シークレットなど、他の用途で強力なランダムトークンを生成する必要がある場合は、ToolCraft のパスワードジェネレーターを使っています。ブラウザ上で完全に動作し、サーバーへのアップロードは一切ありません。
1 台のマシンで複数の GitHub アカウントを使うのは別の悩みどころです。資格情報マネージャーはホストごとに 1 エントリしか保持できないため、アカウントが互いに干渉します。~/.ssh/config で異なるホストエイリアスを使った SSH がこれをうまく解決します — 各プロジェクトが異なるエイリアスを参照し、各エイリアスが異なるキーにマッピングされるため、認証情報の衝突が起きません。
認証情報を削除した後も問題が繰り返し発生する場合は、資格情報ヘルパーの設定を確認してください：
git config --global credential.helper
最新の Git for Windows では manager と表示されるはずです。wincred、store、または何も表示されない場合、それが不安定なキャッシュ動作の原因である可能性が高いため、次の有効期限切れが来る前に修正しておく価値があります。