目次
- はじめに
- 環境
- 公式リポジトリ版を選んだ理由
- インストール
- 認証
- ポイント1 WSLではブラウザが自動起動しない場合がある
- ポイント2 既存のSSH鍵がそのまま利用された
- ポイント3 Gitリポジトリ外ではIssueの対象を自動判定できない
- 認証状態を確認する
- 動作確認
- Claude Codeで利用する目的
- まとめ
- 関連記事
はじめに
Claude CodeからGitHub Issueを参照だけできるようにするため、まずは手動でGitHub CLIの動作を確認することにしました。
Issue本文を取得できるか試そうとして、次のコマンドを実行しました。
gh issue view 379
ところが、実行結果は次のとおりでした。
Command 'gh' not found
GitHub CLIがまだインストールされていないことが分かったため、Ubuntu 24.04（WSL2）へ導入しました。
この記事では、GitHub CLIのインストール手順だけでなく、実際に遭遇した次のポイントもまとめます。
- WSL環境でブラウザが自動起動しなかった
- 既存のSSH鍵がどのように扱われるか確認した
- Gitリポジトリ外で
gh issue viewを実行すると失敗した - Issue本文・コメント・Issue一覧を取得できるところまで確認した
環境
今回使用した環境
この記事では、次の環境でGitHub CLIを導入・検証しました。
- Windows 11
- WSL2
- Ubuntu 24.04.4 LTS
- GitHub CLI 2.96.0
この記事の手順に必要な条件
今回紹介するAPTを使った導入手順では、最低限次の環境が必要です。
- UbuntuまたはDebian系Linux環境
- パッケージをインストールできる
sudo権限 - GitHub CLI公式パッケージリポジトリへ接続できるインターネット環境
-
curlまたはwget - GitHub.comのアカウント
- GitHubへ認証するために利用できるWebブラウザ
この記事では、GitHub CLI公式が管理するDebian向けパッケージリポジトリからインストールします。
Ubuntu標準リポジトリにもコミュニティ管理のパッケージがありますが、GitHub CLI公式ドキュメントでは、公式Debianパッケージの利用が推奨されています。
公式情報は次のページを参照してください。
事前にUbuntuを更新しておく
古いパッケージ情報のまま作業すると、インストール時にエラーが発生する可能性があります。
先にUbuntuのパッケージ情報を更新しておきます。
sudo apt update
WSL2上のUbuntu自体を安全に更新する手順は、次の記事にまとめています。
Linuxコマンドの操作に慣れていない方は、次の記事も参考にしてください。
公式リポジトリ版を選んだ理由
Ubuntu標準リポジトリにもGitHub CLIはありますが、更新タイミングが異なる場合があります。
今回はGitHub公式ドキュメントでも案内されている公式APTリポジトリを利用しました。
理由は次の3つです。
- GitHub公式が提供・管理している
- 最新版を利用しやすい
- Claude Codeなど最新機能との組み合わせでも情報の差が出にくい
インストール
今回はGitHub CLI公式が提供しているAPTリポジトリを利用してインストールします。
Ubuntu標準リポジトリにもGitHub CLIのパッケージは存在しますが、公式ドキュメントではGitHubが管理するリポジトリからインストールする方法が案内されています。
最新版を利用できるため、今回は公式の手順で進めます。
パッケージ情報を更新する
まずはAPTのパッケージ情報を最新の状態へ更新します。
sudo apt update
GPGキー保存用ディレクトリを作成する
APTでは、パッケージの署名を検証するための公開鍵（GPGキー）を保存します。
Ubuntuでは /etc/apt/keyrings に保存する構成が推奨されているため、ディレクトリを作成します。
sudo mkdir -p -m 755 /etc/apt/keyrings
-
-p：ディレクトリが無ければ作成する -
-m 755：アクセス権を755で作成する
GitHub CLIの公開鍵を登録する
次にGitHub CLI公式リポジトリの公開鍵を取得します。
APTはこの鍵を使って、ダウンロードしたパッケージがGitHub公式のものかどうかを検証します。
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg \
| sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg >/dev/null
ダウンロードできたことを確認します。
ls -l /etc/apt/keyrings/githubcli-archive-keyring.gpg
例えば次のように表示されれば正常です。
-rw-r--r-- 1 root root ...
GitHub CLI公式リポジトリを登録する
続いてAPTへGitHub CLI公式リポジトリを登録します。
これにより、apt install gh を実行したときにUbuntu標準リポジトリではなく、GitHub公式リポジトリからパッケージを取得できるようになります。
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" \
| sudo tee /etc/apt/sources.list.d/github-cli.list >/dev/null
この設定では、
-
arch=$(dpkg --print-architecture)：現在のCPUアーキテクチャ（amd64など）を自動指定 -
signed-by=：先ほど登録した公開鍵で署名を検証する -
stable：安定版リポジトリを利用する
という意味になります。
リポジトリ情報を更新する
新しく追加したGitHub公式リポジトリをAPTへ認識させるため、再度パッケージ情報を更新します。
sudo apt update
GitHub CLIをインストールする
準備が整ったらGitHub CLIをインストールします。
sudo apt install gh
バージョンを確認する
最後に正常にインストールされたことを確認します。
gh --version
私の環境では次のバージョンがインストールされました。
gh version 2.96.0
認証
インストールが完了したら、GitHub CLIを自分のGitHubアカウントと関連付けます。
次のコマンドを実行します。
gh auth login
今回は、対話形式の質問に対して次の内容を選択しました。
- 接続先：
GitHub.com - Git操作で使用するプロトコル：
SSH - 認証方法：
Login with a web browser
Login with a web browser を選択すると、GitHub CLIはブラウザを利用した認証を開始します。
認証中や認証後に確認したポイントを、実際の流れに沿って紹介します。
ポイント1 WSLではブラウザが自動起動しない場合がある
Login with a web browser を選択すると、ターミナルにワンタイムコードが表示されます。
その後、本来は認証用ページがブラウザで自動的に開きますが、私のWSL環境では次のメッセージが表示されました。
Failed opening a web browser
ただし、ブラウザの自動起動に失敗しても、認証処理自体が中断されるわけではありません。
Windows側のブラウザで、次のGitHub公式ページを手動で開きます。
https://github.com/login/device
表示された画面に、GitHub CLIのターミナル上で発行されたワンタイムコードを入力します。
GitHubへログインしていない場合は、先にログインを求められます。
また、GitHubで二要素認証（2FA）を有効にしている場合は、認証アプリやGitHub Mobileなど、設定している方法で追加認証を行います。
最後に、GitHub CLIからGitHubアカウントへのアクセスを承認すると、ターミナル側の認証も完了します。
認証完了後は、GitHub CLIが利用する認証情報が保存されるため、通常はコマンドを実行するたびにログインする必要はありません。
ポイント2 既存のSSH鍵がそのまま利用された
認証の途中で、GitHub CLIがPC内にあるSSH鍵を検出しました。
私の環境では、次の用途で使用しているSSH鍵が表示されました。
- GitHub用
- XServer用
GitHub用のSSH鍵を選択すると、次のメッセージが表示されました。
SSH key already existed on your GitHub account
選択したSSH鍵がすでにGitHubアカウントへ登録されていたため、新しい鍵は作成されず、既存の鍵がそのまま利用されました。
既にGitHubへSSH鍵を登録している場合は、認証時に新しい鍵を作り直す必要はありません。
ポイント3 Gitリポジトリ外ではIssueの対象を自動判定できない
認証後、ホームディレクトリで次のコマンドを実行しました。
gh issue view 379
しかし、次のエラーが表示されました。
fatal: not a git repository
gh issue view は、--repo オプションを指定しない場合、現在いるGitリポジトリのリモート情報から対象のGitHubリポジトリを判定します。
そのため、Gitリポジトリではないホームディレクトリ上では、どのリポジトリのIssueを参照すればよいか判断できませんでした。
対象プロジェクトのディレクトリへ移動します。
cd ~/projects/xserver-log-analyzer
移動後、改めてIssueを表示します。
gh issue view 379
プロジェクトディレクトリ内では、リモートリポジトリが自動判定され、Issueの内容を正常に表示できました。
現在のディレクトリに関係なく対象リポジトリを明示したい場合は、--repo オプションも利用できます。
gh issue view 379 --repo honda-dev-jp/xserver-log-analyzer
自動処理やClaude Codeから実行する場合は、作業ディレクトリへの依存を避けられるため、--repo を明示する方法も有効です。
認証状態を確認する
最後に、GitHub CLIの認証状態を確認します。
gh auth status
このコマンドでは、主に次の内容を確認できます。
- GitHub.comへログイン済みか
- 使用しているGitHubアカウント
- Git操作で使用するプロトコル
- 認証トークンに付与されている権限
私の環境では、GitHub.comへログイン済みであり、Git操作にはSSHを使用する設定になっていることを確認できました。
動作確認
gh auth status
gh issue view 379
gh issue view 379 --comments
gh issue list --state open --limit 100
すべて正常動作しました。
Claude Codeで利用する目的
Claude CodeからGitHub Issueを確認する際、これまでは安全性を確認するために、gh issue view や gh issue list の実行ごとに許可を求める運用にしていました。
しかし、これらはIssueの内容や一覧を取得するだけの読み取り専用コマンドです。実際に何度も確認し、安全に利用できる操作だと判断できたため、今後は毎回手動で許可しなくても実行できるようにしたいと考えました。
対象とするコマンドは、次の2つです。
gh issue view
gh issue list
これらをClaude Codeの読み取り専用セッションで許可することで、次の作業を効率化できます。
- Issue本文を毎回プロンプトへ貼り付ける手間を減らす
- 最新のIssue内容をClaude Code側で直接確認できるようにする
- Issue一覧から対象Issueを探しやすくする
- 読み取り操作だけを許可し、Issueの作成・編集・クローズなどの変更操作は引き続き禁止する
単に操作を省略するのではなく、許可するコマンドを読み取り専用に限定したうえで、安全性を保ちながら確認作業を自動化することが目的です。
まとめ
- GitHub CLIは公式APTリポジトリから導入できる
- WSLでブラウザが自動起動しなくても、手動で認証を完了できる
- GitHubへ登録済みのSSH鍵は、そのまま利用できる
-
gh issue viewはGitリポジトリ内で実行するか、--repoを指定して実行する -
gh auth statusで認証状態を確認できる