【2026年最新】GitHub CLI（gh）の複数アカウントをワンコマンドで切り替える方法（gh auth switch ＆プロファイル管理）

📅 作成日: 2023/02/11, 更新日: 2026/11/01 ⏱️ 読了目安約9分 (4,477文字)

GitHub CLI（gh）で個人用・業務用の複数GitHubアカウントを瞬時に切り替える方法を解説。公式組み込みコマンド「gh auth switch」と「gh auth setup-git」の使い方に加え、任意の名前で管理できるhosts.ymlエイリアス設定も紹介します。

改訂履歴
先に結論：いま GitHub CLI で複数アカウントを切り替える最短コマンド
1. 公式コマンド gh auth switch によるマルチアカウント登録と切り替え
2. git push / git clone の認証を gh auth switch に完全連動させる
1. なぜ gh auth switch したのに git push で Permission denied が出るのか？
2. 解決策： gh auth setup-git と既存ヘルパーのリセット
3. 【重要】 gh auth switch では切り替わらない「Git コミット Author」の分離設計
1. ① ~/.gitconfig にディレクトリ分岐（ includeIf ）を定義
2. ② 環境別の設定ファイルを作成
4. 現場でハマったトラブルシューティングと原因切り分けフロー
1. ハマりどころ①： GH_TOKEN / GITHUB_TOKEN 環境変数が残っていると gh auth switch が効かない
2. ハマりどころ②：AI コーディングエージェント（Claude Code / Antigravity）での非対話実行
5. ロール名（ personal / work ）で切り替えるカスタムエイリアス設定
1. パターンA：公式 gh auth switch -u をロール名にマッピングする軽量エイリアス（推奨）
2. パターンB： hosts.yml.${プロファイル名} をファイル単位で分離・退避するエイリアス（従来方式）
6. まとめ：方式別の比較と現在の運用スタイル
1. 参考リンク
あわせて読みたい関連記事
1. 本番運用の設定ファイル＆自動化スクリプト一式をダウンロード

改訂履歴

日付	更新内容
2026/10/26	・GitHub CLI 公式ネイティブコマンド `gh auth switch` （v2.40.0 以降）および OS キーリング保管方式をメイン手順として全面刷新・Git HTTPS 認証ヘルパー連携（ `gh auth setup-git` ）とディレクトリ別コミット Author 自動分離（ `~/.gitconfig` の `includeIf` ）の二層設計を追加・環境変数 `GH_TOKEN` 競合や `git push` 時の `Permission denied` 切り分けフロー（Mermaid）および AI エージェント向けロール別エイリアス運用を追記
2025/06/18	・エイリアス設定コマンド（ `yq` ）のクォート記述およびエラー出力例を修正
2023/12/31	・1Password CLI プラグインを利用したアカウント切り替えの参考情報を追記
2023/02/21	・ `!gh auth git-credential` による Git クレデンシャルヘルパー連携の挙動を追記

先に結論：いま GitHub CLI で複数アカウントを切り替える最短コマンド

僕がこの記事を最初に書いた 2023年2月当時は、GitHub CLI（ gh ）に複数アカウントを保持・切り替える公式機能が存在しなかったため、 ~/.config/gh/hosts.yml を別名で退避・上書きコピーする自作エイリアスでしのいでいました。

その後、GitHub CLI v2.40.0（2023年12月リリース） で公式のマルチアカウント管理機能 gh auth switch が実装されました。現在（2026年時点、 gh version 2.102.0 で検証）は、設定ファイルを直接書き換えることなく、以下の標準コマンドだけで複数の GitHub アカウント（個人用と会社・案件用など）を即座に切り替えられます。

# 1. 2つ目以降のアカウントを追加ログイン（既存アカウントは上書きされず追加保持される）
gh auth login

# 2. 現在のログイン済みアカウント一覧とアクティブ状態を確認
gh auth status

# 3. アカウントを切り替える（2アカウントのみなら引数なしで即トグル切り替え）
gh auth switch

# 4. アカウント名を指定して非対話で一発切り替え（スクリプト・3アカウント以上の場合）
gh auth switch -u kanji-shinohara

# 5. Git (git push / pull / clone) の HTTPS 認証にも GitHub CLI の切り替えを連動させる
gh auth setup-git

単に gh pr create や gh issue list の実行アカウントを切り替えたいだけなら、上記の gh auth switch だけで完結します。

ただ、実際に 1 台の Mac で「会社の業務リポジトリ」と「個人の開発リポジトリ」を毎日行き来していると、 gh auth switch だけでは防げない 3 つの実務上の落とし穴 に何度もハマりました。

git push の認証は通ったのに、コミットの Author （ user.name / user.email ）に会社のメールアドレスが混ざる問題
環境変数 GH_TOKEN / GITHUB_TOKEN が残っていて gh auth switch が効かない・拒否される問題
AI コーディングエージェント（Claude Code や Antigravity 等）や共通スクリプトで、具体的なユーザー名ではなく personal / work といった「役割（ロール名）」で切り替えを統一したい問題

本記事では、公式の gh auth switch の基本操作から、これら 3 つの落とし穴を防ぐ「認証トークンとコミット Author の二層分離設計」、そして僕が手元の環境で今も併用しているロール別エイリアス設定までまとめて解説します。

▲ GitHub CLI (gh auth switch) による API/HTTPS 認証切り替えと Git includeIf による Author 分離の全体像

1. 公式コマンド `gh auth switch` によるマルチアカウント登録と切り替え

① 複数アカウントの追加登録（ `gh auth login` ）

すでに 1 つ目のアカウント（例：会社用アカウント work-user ）でログインしている状態で、そのままもう一度 gh auth login を実行し、2 つ目のアカウント（例：個人用アカウント kanji-shinohara ）で認証を通します。

gh auth login -h github.com -p https -w

現在の GitHub CLI は、デフォルトで認証トークンを OS 標準のセキュアストレージ（macOS の Keychain、Windows の Credential Manager、Linux の Secret Service）に暗号化して保存します。以前のように ~/.config/gh/hosts.yml の中に平文の oauth_token が書き込まれないため、ドットファイルを管理する上でも安全性が大幅に向上しています。

② 登録状態とアクティブアカウントの確認（ `gh auth status` ）

gh auth status を実行すると、現在保持されているすべてのアカウントと、どちらがアクティブ（ Active account: true ）になっているかが一目で確認できます。

$ gh auth status
github.com
  ✓ Logged in to github.com account kanji-shinohara (keyring)
  - Active account: true
  - Git operations protocol: https
  - Token: gho_************************************
  - Token scopes: 'gist', 'read:org', 'repo', 'workflow'

  ✓ Logged in to github.com account work-taro (keyring)
  - Active account: false
  - Git operations protocol: https
  - Token: gho_************************************
  - Token scopes: 'gist', 'read:org', 'repo', 'workflow'

シェルスクリプトや CI チェックなどで「現在アクティブなアカウントだけ」を確認したい場合は、 --active （ -a ）フラグ、または JSON 出力オプションが便利です。

# アクティブなアカウントのみを表示
gh auth status --active

# 現在アクティブな GitHub ユーザー名だけを文字列として取得（スクリプトでの事前チェック用）
gh api user --jq '.login'

③ アカウントの切り替え（ `gh auth switch` ）

アカウントを切り替える際は、以下の 3 通りの呼び出し方を使い分けます。

# パターンA：登録が2アカウントのみの場合（実行するたびに交互にトグル切り替え）
gh auth switch

# パターンB：ユーザー名を明示して切り替え（3アカウント以上ある場合や自動化スクリプト向け）
gh auth switch -u kanji-shinohara

# パターンC：GitHub Enterprise Server (GHES) のホストを指定して切り替え
gh auth switch --hostname github.company.internal -u work-taro

実行すると、 ✓ Switched active account for github.com to kanji-shinohara と出力され、即座にアクティブアカウントが切り替わります。

2. `git push` / `git clone` の認証を `gh auth switch` に完全連動させる

なぜ `gh auth switch` したのに `git push` で `Permission denied` が出るのか？

僕が現場でよく遭遇したのが、「 gh auth switch -u kanji-shinohara で個人アカウントに切り替えたのに、いざ git push origin main を叩くと remote: Permission to kanji-shinohara/repo.git denied to work-taro. （または Repository not found ）と怒られる」という現象です。

原因はシンプルで、Git 本体（ git push / git pull ）が参照するクレデンシャルヘルパー（ osxkeychain や manager ）が古いキャッシュを掴んでおり、GitHub CLI 側のアクティブアカウント変更を参照していないためです。

解決策： `gh auth setup-git` と既存ヘルパーのリセット

まず公式コマンド gh auth setup-git を実行します。

gh auth setup-git

それでも macOS の osxkeychain 等が先に介入して古いアカウントで通信してしまう場合は、 ~/.gitconfig の https://github.com 用ヘルパーを一度空文字 '' でリセットした上で、 !gh auth git-credential のみを使うよう明示的に設定します。

# 既存のシステムデフォルトの credential helper を github.com に対して無効化
git config --global --replace-all 'credential.https://github.com.helper' ''

# GitHub CLI のアクティブアカウントをそのまま Git 認証に使うよう追加
git config --global --add 'credential.https://github.com.helper' '!gh auth git-credential'

これにより、 ~/.gitconfig には以下の設定が書き込まれ、 gh auth switch で切り替えた瞬間に git push / git pull の HTTPS 認証トークンも 100% 同期して切り替わるようになります。

[credential "https://github.com"]
    helper = 
    helper = !/opt/homebrew/bin/gh auth git-credential

3. 【重要】 `gh auth switch` では切り替わらない「Git コミット Author」の分離設計

ここが一番の注意点です。 gh auth switch が切り替えるのは「GitHub API および HTTPS 通信の認証トークン」だけであり、Git コミットに記録される user.name と user.email は一切変更されません。

そのため、認証だけ個人アカウントに切り替えてそのまま git commit すると、個人リポジトリのコミット履歴に会社のメールアドレスが残ってしまう（あるいはその逆）という事故が起きます。

手動で毎回 git config user.email を打ち直すのは確実に忘れるため、僕は作業ディレクトリ（ ~/workspace/personal/ と ~/workspace/work/ ）に応じて Git 設定を自動切り替えする includeIf を組み合わせています。

① `~/.gitconfig` にディレクトリ分岐（ `includeIf` ）を定義

# ~/.gitconfig（デフォルトは安全のため個人用、または空にしておく）
[user]
    name = Kanji Shinohara
    email = kanji.shinohara@example.com

# 個人開発ディレクトリ配下のリポジトリでは個人用設定を適用
[includeIf "gitdir:~/workspace/personal/"]
    path = ~/.gitconfig-personal

# 業務・クライアント案件ディレクトリ配下のリポジトリでは業務用設定を適用
[includeIf "gitdir:~/workspace/work/"]
    path = ~/.gitconfig-work

[credential "https://github.com"]
    helper = 
    helper = !/opt/homebrew/bin/gh auth git-credential

② 環境別の設定ファイルを作成

# ~/.gitconfig-personal
[user]
    name = Kanji Shinohara
    email = kanji.shinohara@gmail.com

# ~/.gitconfig-work
[user]
    name = Kanji Shinohara
    email = kanji.shinohara@company.co.jp

（※ 注意： gitdir:~/workspace/personal/ の末尾のスラッシュ / を忘れるとサブディレクトリに適用されないため、必ず末尾に / を付けてください）

これで、「どのフォルダで作業しているか」によってコミットの Author が自動で切り替わり、うっかり社用メールアドレスを個人 OSS リポジトリにコミットしてしまう手戻りをゼロにできます。

4. 現場でハマったトラブルシューティングと原因切り分けフロー

gh auth switch を導入した後に「なぜかアカウントが切り替わらない」「 Failed to log in が出る」と詰まったときの判断フローをまとめました。

        flowchart TD
    A["gh コマンドや git push で<br/>アカウント不一致 / Permission denied が発生"] --> B{"gh auth status を実行して<br/>GH_TOKEN 環境変数の警告が出るか？"}
    B -- "Yes (環境変数が優先されている)" --> C["unset GH_TOKEN GITHUB_TOKEN を実行<br/>（.envrc / direnv や .zshrc の export を確認）"]
    B -- "No" --> D{"gh auth switch を実行した際<br/>write operations エラーが出るか？"}
    D -- "Yes" --> E["読み取り専用トークン等が干渉しているため<br/>unset GH_TOKEN 後に gh auth switch -u <user>"]
    D -- "No" --> F{"gh pr / repo 系は通るのに<br/>git push だけ 403 / 404 になるか？"}
    F -- "Yes" --> G["Git が別ヘルパー(osxkeychain等)を参照中<br/>git config --global credential.https://github.com.helper ''<br/>の後に gh auth setup-git を再実行"]
    F -- "No" --> H["トークン期限切れ・スコープ不足<br/>gh auth login -h github.com -s repo,workflow,read:org"]
       

ハマりどころ①： `GH_TOKEN` / `GITHUB_TOKEN` 環境変数が残っていると `gh auth switch` が効かない

MCP サーバーの設定や direnv （ .envrc ）などでシェルの環境変数に GH_TOKEN または GITHUB_TOKEN が設定されていると、GitHub CLI は設定ファイル（キーリング）よりも 環境変数を最優先 します。

この状態で gh auth switch を叩くと、以下のようなエラーが出るか、切り替えたつもりでも元のトークンが使われ続けます。

$ gh auth switch
X Active account on github.com cannot be switched while GH_TOKEN environment variable is set

gh auth status を叩いて - Token: gho_*** (from GH_TOKEN) と表示されている場合は、 unset GH_TOKEN GITHUB_TOKEN で環境変数を解除してから切り替えてください。

ハマりどころ②：AI コーディングエージェント（Claude Code / Antigravity）での非対話実行

僕は普段、Claude Code や Antigravity などの AI コーディングエージェントに複数のプロジェクト（個人プロジェクトと業務プロジェクト）を跨いで作業させています。

このとき、AI エージェントがバックグラウンドのサブシェルから git push や gh pr create を実行すると、直前に別タスクで切り替えたアカウントが残っていて Permission denied で止まることがありました。また、プロジェクト共通のルールファイル（ .agent/rules/git_workflow.md 等）に生の GitHub ユーザー名（ kanji-shinohara 等）をハードコードするよりも、 personal / work という抽象的なロール名（プロファイル名）で呼び出せた方が、ルールやスキルを全リポジトリで共通化できます 。

そこで、以前から使っていた gh switch-profile <プロファイル名> というエイリアスインターフェースを維持したまま、裏側で切り替えを行う設定を引き続き活用しています。

5. ロール名（ `personal` / `work` ）で切り替えるカスタムエイリアス設定

「具体的な GitHub ユーザー名ではなく gh switch-profile personal や gh switch-profile work のように役割名で切り替えたい」「アカウントごとに hosts.yml ファイル自体を物理分離して管理したい」という場合は、 ~/.config/gh/config.yml の aliases 機能が便利です。

パターンA：公式 `gh auth switch -u` をロール名にマッピングする軽量エイリアス（推奨）

~/.config/gh/config.yml の aliases に、ロール名から実際の GitHub ユーザー名へのマッピングを 1 行追加するだけです。

# ~/.config/gh/config.yml
git_protocol: https
aliases:
    switch-profile: >-
      !case "$1" in
        personal) gh auth switch -h github.com -u kanji-shinohara ;;
        work)     gh auth switch -h github.com -u work-taro ;;
        *)        echo "[ERROR] Usage: gh switch-profile <personal|work>" && exit 1 ;;
      esac && gh auth status --active

これで、人間が手元で叩くときも、AI エージェントがプッシュ前フックで叩くときも、常に以下のコマンドで統一できます。

gh switch-profile personal && git push origin HEAD

パターンB： `hosts.yml.${プロファイル名}` をファイル単位で分離・退避するエイリアス（従来方式）

OS キーリングを使わず（ gh auth login --insecure-storage ）、以前のように ~/.config/gh/hosts.yml.${プロファイル名} として設定ファイルごとバックアップ・切り替えしたい場合は、以下の 4 つのエイリアス（ create-profile , switch-profile , delete-profile , list-profiles ）を ~/.config/gh/config.yml に登録します。

git_protocol: https
aliases:
    create-profile: '![ -z "$1" ] && echo "[ERROR] Please specify the profile name." && exit 1; gh auth status && read -p "Do you create this profile? (y/N): " yn; case "$yn" in [yY]*) cp ~/.config/gh/hosts.yml ~/.config/gh/hosts.yml.$1 && echo "New hosts file created: ~/.config/gh/hosts.yml.$1";; esac'
    switch-profile: '![ -z "$1" ] && echo "[ERROR] Please specify the profile name." && exit 1; if [ -e ~/.config/gh/hosts.yml.$1 ]; then cp ~/.config/gh/hosts.yml.$1 ~/.config/gh/hosts.yml && gh auth status && echo "[INFO] Hosts file switched"; else echo "[ERROR] Hosts file not found: ~/.config/gh/hosts.yml.$1"; fi'
    delete-profile: '![ -z "$1" ] && echo "[ERROR] Please specify the profile name." && exit 1; read -p "Do you delete this profile? (y/N): " yn; case "$yn" in [yY]*) rm -f ~/.config/gh/hosts.yml.$1 && echo "Hosts file deleted: ~/.config/gh/hosts.yml.$1";; esac'
    list-profiles: '!ls ~/.config/gh/hosts.yml.* | sed -e "s|^.*hosts.yml.||" | sed -e "s|^|  - |"'

yq コマンドで config.yml に一括追加する場合のコマンド＆実行例（クリックで展開）

# プロファイル作成コマンド
yq -o yaml -i '.aliases += {
  "create-profile": "![ -z \"$1\" ] && echo \"[ERROR] Please specify the profile name.\" && exit 1; gh auth status && read -p \"Do you create this profile? (y/N): \" yn; case \"$yn\" in [yY]*) cp ~/.config/gh/hosts.yml ~/.config/gh/hosts.yml.$1 && echo \"New hosts file created: ~/.config/gh/hosts.yml.$1\";; esac"
}' ~/.config/gh/config.yml

# プロファイル切り替えコマンド
yq -o yaml -i '.aliases += {
  "switch-profile": "![ -z \"$1\" ] && echo \"[ERROR] Please specify the profile name.\" && exit 1; if [ -e ~/.config/gh/hosts.yml.$1 ]; then cp ~/.config/gh/hosts.yml.$1 ~/.config/gh/hosts.yml && gh auth status && echo \"[INFO] Hosts file switched\"; else echo \"[ERROR] Hosts file not found: ~/.config/gh/hosts.yml.$1\"; fi"
}' ~/.config/gh/config.yml

# プロファイル削除コマンド
yq -o yaml -i '.aliases += {
  "delete-profile": "![ -z \"$1\" ] && echo \"[ERROR] Please specify the profile name.\" && exit 1; read -p \"Do you delete this profile? (y/N): \" yn; case \"$yn\" in [yY]*) rm -f ~/.config/gh/hosts.yml.$1 && echo \"Hosts file deleted: ~/.config/gh/hosts.yml.$1\";; esac"
}' ~/.config/gh/config.yml

# プロファイルリストコマンド
yq -o yaml -i '.aliases += {
  "list-profiles": "!ls ~/.config/gh/hosts.yml.* | sed -e \"s|^.*hosts.yml.||\" | sed -e \"s|^|  - |\""
}' ~/.config/gh/config.yml

各エイリアスの実行コマンドは以下の通りです。

# 現在の認証状態でプロファイルファイルを作成
gh create-profile personal

# プロファイル一覧を表示
gh list-profiles

# プロファイルを切り替え
gh switch-profile personal

# 不要になったプロファイルを削除
gh delete-profile personal

6. まとめ：方式別の比較と現在の運用スタイル

最後に、GitHub CLI で複数アカウントを扱うアプローチを比較表に整理します。

比較観点	① 公式 `gh auth switch` （標準）	② 公式 `gh auth switch` ＋ Git `includeIf` ＋ロールエイリアス（僕の本番構成）	③ 旧方式（ `hosts.yml` コピー）
導入の手軽さ	◎ 追加設定なしですぐ使える	○ 初回のみ `~/.gitconfig` とエイリアス設定が必要	△ `hosts.yml` の手動退避が必要
トークン保管の安全性	◎ OS キーリング（Keychain 等）で暗号化	◎ OS キーリング（Keychain 等）で暗号化	△ 平文ファイル（ `--insecure-storage` ）が前提になりやすい
`git push` 認証の連動	○（ `gh auth setup-git` 実行時）	◎ クレデンシャルヘルパー明示指定で確実	○
コミット Author メール分離	✕ 切り替わらない（要注意）	◎ 作業ディレクトリ単位で自動分離	✕ 切り替わらない
AI エージェント / 自動化適性	○（ `-u <user>` 指定が必要）	◎ `gh switch-profile personal` で統一可能	○

現在の僕自身の結論としては、認証基盤そのものは公式の gh auth switch （キーリング保管）＋ gh auth setup-git に完全移行しつつ、コミット Author の事故防止に ~/.gitconfig の includeIf を張り、さらに AI エージェントからの呼び出し用に gh switch-profile エイリアス を被せる構成が一番ストレスなく回っています。

ただ、今後もし GitHub CLI 本体で「リポジトリのディレクトリパスに応じて使用するアカウントを自動選択する機能（ gh 版の includeIf のような仕組み）」が公式サポートされれば、プッシュ前の切り替えコマンドすら不要になるはずです。そのあたりの公式アップデートは引き続き追いかけていきたいと思います。

参考リンク

あわせて読みたい関連記事

【2026年11月】LLMベンチマーク＆API料金比較：Claude Opus 5.5 vs GPT-6 vs Gemini 4

コーディング首位はClaude Opus 5.5（SWE-bench 86.8%・Terminal-Bench 66.4%）とGemini 4 Carbon（Terminal-Bench 65.2%・ ... [続きを読む]

【2024-2026年史】AIコーディングエディタの進化と未来予想：CopilotからClaude Code、Antigravity、Kiroまで──「チャット」から「自律協働（コワーク）」への大転換

2024年から2026年にかけてのAIコーディングの進化史を総括。GitHub CopilotからClaude Code、Antigravity、Replit、Bolt.newまでの変遷、Webアプリ ... [続きを読む]

AIエージェントの記憶アーキテクチャをLanceDB＋SQLiteのハイブリッドGraphRAGへ刷新した話

⏳ 近日公開予定

本番運用の設定ファイル＆自動化スクリプト一式をダウンロード

本記事で解説した 4大AIエージェント（Antigravity, Kiro, Claude Code, Codex）完全対応の AGENTS.md テンプレート、hooks.json、Gitガードスクリプト一式をGumroadにて配布準備中です。

Starter Kit を入手する（準備中） ※ 現在 Gumroad にて公開準備中です。公開次第リンクが有効化されます。

🚀 運営サービス・関連ソリューション（Cont-Aid LLC）

CLOUD ARCHITECTURE & ADVISORY

AWS / Google Cloud 設計標準化・セキュリティ自動化支援（合同会社Cont-Aid）

AWS Organizations / Control Tower マルチアカウント設計、IAM Identity Center、Prowler 統制自動化、Terraform / CI/CD 構築を実務アーキテクトが直接支援します。

アーキテクチャ相談・お問い合わせ

LIVE CLOUD & AI SHOWCASE

Alpha Radar & CandidLens — サーバーレスAI実践プロダクト

Google Cloud / Firebase 上で稼働する自社AIプロダクト群。AIクオンツ市場分析「Alpha Radar」およびAI印象診断「CandidLens」を公開中です。

プロダクトを見る