---
title: "ghコマンド（GitHub CLI）とは？インストール方法と使い方・コマンド一覧【v2.101対応】"
url: "https://www.issoh.co.jp/tech/details/3547/"
published: 2024-09-10
updated: 2026-10-01
categories: ["GitHub"]
publisher: "株式会社一創"
---

# ghコマンド（GitHub CLI）とは？インストール方法と使い方・コマンド一覧【v2.101対応】

ghコマンドは、GitHubが公式に開発しているコマンドラインツール「GitHub CLI」の実行ファイル名です。プルリクエストの作成やレビュー、Issueの起票、GitHub Actionsの実行結果の確認といった、普段はブラウザで行うGitHub上の操作をターミナルから実行できます。ライセンスはMITで、ソースは `cli/cli` リポジトリで公開されています。

この記事では、2026年9月27日時点の最新版であるv2.101.0（9月15日公開）を手元で実行し、ヘルプの出力と公式ドキュメントを突き合わせて、インストール手順・認証・よく使うコマンドを整理しました。Ubuntuの標準パッケージが古すぎる問題や、Linux向けリポジトリの署名鍵切り替え、v2.91.0から既定で有効になったテレメトリなど、古い解説記事には載っていない注意点も扱います。

## まとめ：ghコマンドの導入と使い方の要点

- ghはGitHub上の操作（PR・Issue・Actions・リリース）を担当し、コミットやブランチ操作は従来どおりgitが担当します。`gh branch` というコマンドは存在しません。
- 公式の推奨インストール方法は、WindowsがWinGet、macOSがHomebrew、Linuxが公式のAPT・RPMリポジトリです。ghを動かすPowerShell 7本体の入れ方と版の選び方は[PowerShellのインストール手順｜7.6 LTSをwinget・MSI・Linux・macOSで入れる](https://www.issoh.co.jp/tech/details/17921/)で解説しています。ScoopとChocolateyはコミュニティ提供の扱いです。
- Ubuntuで `sudo apt install gh` を実行すると、24.04 LTSでは2.45.0、26.04 LTSでは2.46.0が入ります。この系列は廃止されたAPIに依存しているため動かない箇所があり、開発元は公式リポジトリの利用を強く勧めています。
- 公式APT・RPMリポジトリの署名鍵は、旧鍵の期限切れ（2026年9月5日）に合わせて切り替わりました。2026年4月8日より前に登録した環境では、鍵を更新しないと `apt update` が失敗します。
- 認証は `gh auth login` のブラウザ認証が既定です。`--with-token` でclassic PATを渡す場合の最小スコープは `repo`・`read:org`・`gist` です。
- v2.91.0（2026年4月22日）からテレメトリが既定で有効です。`gh config set telemetry disabled` または環境変数 `GH_TELEMETRY=false` で止められます。

## ghコマンド（GitHub CLI）でできることとgitとの違い

gitはローカルのリポジトリを操作する分散バージョン管理ツールで、GitHubに限らずGitLabや自社サーバーでも同じように動きます。ghはGitHubのREST APIとGraphQL APIを呼び出すクライアントで、GitHubというサービス固有の機能を扱います。両者は競合せず、日常の作業では併用します。

| やりたい操作              | 使うコマンド                         |
| ------------------- | ------------------------------ |
| コミット・ブランチ作成・切り替え    | git commit / git switch        |
| push・pull           | git push / git pull            |
| リポジトリの作成・複製・フォーク    | gh repo create / clone / fork  |
| プルリクエストの作成・レビュー・マージ | gh pr create / review / merge  |
| Issueの起票・一覧・クローズ    | gh issue create / list / close |
| Actionsの実行・監視・再実行   | gh workflow run / gh run watch |
| リリースの作成・アセット取得      | gh release create / download   |
| 任意のAPI呼び出し          | gh api                         |

gitの基本コマンドを整理したい場合は[Gitコマンドの用途別早見表](/tech/details/2787/)を先に確認しておくと、境界がはっきりします。ghはgithub.comのほか、GitHub Enterprise Cloud（ghe.com）とGitHub Enterprise Serverにも接続できます。Enterprise Serverへは `gh auth login --hostname` で接続先を指定します。

導入を見送ってよいのは、GitHubの操作が週に数回程度で、Web画面で困っていない場合です。逆に、PRを1日に何本も出してCIの結果を待つ開発者や、Issueやリリースをスクリプトで一括処理したい運用担当者は、導入した日から往復の手間が減ります。

## ghコマンドのインストール方法（Windows・Mac・Linux）

[GitHub CLI公式のインストール手順](https://github.com/cli/cli/tree/v2.101.0/docs)（`docs/install_windows.md`・`install_macos.md`・`install_linux.md`）は、方法を「Recommended（公式）」「Community（非公式）」「Discouraged（非推奨）」の3段階に分けています。非公式の方法について、開発チームは安定性・安全性・可用性を保証しないと明記しています。

| OS            | 公式の推奨          | 非公式・非推奨                |
| ------------- | -------------- | ---------------------- |
| Windows       | WinGet・exe/msi | Chocolatey・Scoop・Conda |
| macOS         | Homebrew・pkg   | MacPorts・Conda・Spack   |
| Debian・Ubuntu | 公式APTリポジトリ     | OS標準のgh（非公式）           |
| Fedora・RHEL等  | 公式RPMリポジトリ     | Fedora標準のgh（非公式）       |
| Linux全般       | Homebrew・バイナリ  | Snap（非推奨）              |

### WindowsはWinGetでインストール

WinGetのパッケージはMicrosoftが管理し、`microsoft/winget-pkgs` 経由で更新されます。PowerShellかコマンドプロンプトで次を実行します。

```
winget install --id GitHub.cli --source winget
# 更新
winget upgrade --id GitHub.cli --source winget
```

インストーラーは環境変数PATHを書き換えます。Windows Terminalでは新しいタブではなく新しいウィンドウを開かないと `gh` が見つかりません。公式手順にもこの注意書きがあります。社内標準がChocolateyなら `choco install gh` でも入りますが、公式手順ではコミュニティ提供の扱いで、更新はChocolatey側のパッケージ管理者に依存します。

### MacはHomebrewでインストール

```
brew install gh
# 更新
brew upgrade gh
```

Releasesページのpkgインストーラーも使えますが、公式手順には「macOSのpkgは現在署名されていない」との注記があります。社内の端末管理で未署名のインストーラーを禁止している場合は、Homebrewを使うほうが無難です。

### Linuxの公式APT・RPMリポジトリによるインストール

Ubuntuでは、OS標準のリポジトリから入るghのバージョンに注意が必要です。Launchpadの公開情報では、Ubuntu 24.04 LTSのghは2.45.0、26.04 LTSは2.46.0です。公式手順は2025年11月付けで「コミュニティ配布の2.45.x・2.46.xは廃止されたGitHub APIに依存しているため壊れている」と注記しています。Debian系は、公式のAPTリポジトリを登録してから入れます。

```
(type -p wget >/dev/null || (sudo apt update && sudo apt install wget -y)) \
  && sudo mkdir -p -m 755 /etc/apt/keyrings \
  && out=$(mktemp) && wget -nv -O$out https://cli.github.com/packages/githubcli-archive-keyring.gpg \
  && cat $out | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
  && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
  && sudo mkdir -p -m 755 /etc/apt/sources.list.d \
  && 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 \
  && sudo apt update \
  && sudo apt install gh -y
```

Fedora 41以降などDNF5の環境では、次の3行です。DNF4（RHEL・CentOS・Fedora 40以前）では `config-manager --add-repo` の書式が異なるので、公式手順のDNF4節に従ってください。

```
sudo dnf install dnf5-plugins
sudo dnf config-manager addrepo --from-repofile=https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf install gh
```

Snapは公式手順の「Discouraged」節で、開発チームが「ghをSnapで入れないこと」を勧めています。

### 2026年9月の署名鍵切り替えでapt updateが失敗するときの対処

公式APT・RPMリポジトリの旧署名鍵（末尾 `23F3D4EA75716059`）は2026年9月5日に期限を迎え、新しい鍵（末尾 `5612B36462313325`）へ切り替わりました。v2.101.0のリリースノートは、2026年4月8日より前に公式リポジトリから入れて鍵を更新していない環境では、インストールや更新が失敗する可能性があると告知しています。`apt update` で `EXPKEYSIG 23F3D4EA75716059` や `NO_PUBKEY 5612B36462313325` が出たら、この件です。[署名鍵更新の公式告知（cli/cli issue #13118）](https://github.com/cli/cli/issues/13118)に沿って、APTのソース設定にある `signed-by` の参照先を確認してから、鍵束ファイルを取り直します。以下は参照先が `/etc/apt/keyrings/githubcli-archive-keyring.gpg` の場合です。旧配置の `/usr/share/keyrings/` などを参照している場合は、以下の保存先もそのパスに合わせてください。

```
sudo mkdir -p -m 755 /etc/apt/keyrings
sudo wget -qO /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg \
  && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
sudo apt update
sudo apt install gh
```

`gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg` で公開鍵を表示し、新鍵のフィンガープリント `7F38BBB59D064DBCB3D84D725612B36462313325` が含まれることを確認します。WindowsとmacOS、Homebrewやバイナリで入れた環境は影響を受けません。古い鍵束を焼き込んだDockerイメージも同じ理由で壊れるため、ビルド手順を見直してください。

### バージョン確認と更新の頻度

インストール後は `gh --version` で版を確認します。v2.101.0なら `gh version 2.101.0 (2026-09-15)` と表示されます。2026年7月2日のv2.96.0から9月15日のv2.101.0まで、公開間隔は2〜29日と一定ではありません。このうちv2.96.0・v2.97.0・v2.98.0はいずれもセキュリティ修正を含んでいました。v2.97.0で直った脆弱性の1つは、`gh auth status` が `github_pat_` 形式などのトークンの一部を平文で表示してしまうものです。ghは24時間に1回新しい版を確認し、見つかると標準エラーに更新通知を出すので、通知が出たらパッケージマネージャーで更新します。

## gh auth loginでの認証とトークン管理

ghは認証しないとほとんどのコマンドが動きません。未認証で `gh pr list` を実行すると「To get started with GitHub CLI, please run: gh auth login」と表示され、終了コード4で終わります（v2.101.0で確認）。

### ブラウザ認証とトークン認証の違い

```
gh auth login                          # 対話形式（既定はブラウザ認証）
gh auth login --hostname ghe.example.com   # Enterprise Serverへ接続
gh auth login --with-token < mytoken.txt   # トークンを標準入力から渡す
gh auth status                         # 接続先・アカウント・保存先を確認
```

ブラウザ認証では、端末に表示されるワンタイムコードをブラウザで入力します。v2.101.0からこのコードが既定でクリップボードへコピーされるようになりました。不要なら `gh config set clipboard disabled` で止められます。途中でgitの通信方式を聞かれた際に `ssh` を選ぶと、既存のSSH鍵を検出してGitHubへ登録するか、鍵が無ければ新規作成を提案されます。

`--with-token` で渡すのはPersonal Access Token（classic）が前提で、最小スコープは `repo`・`read:org`・`gist` です。fine-grained tokenは権限がリソース単位に限られるため、ヘルプは `--with-token` でなく環境変数 `GH_TOKEN` で渡すよう勧めています。トークンの種類とスコープの選び方は[GitHub PATの作成方法とclassic・fine-grainedの違い](/tech/details/7545/)で詳しく扱っています。組織がSAML SSOを必須にしている場合、classic PATは作成後に対象組織へのSSO認可が必要です。fine-grained PATのSSO認可はトークン作成時に行われます。手順は[GitHub SSOの設定手順とPAT・SSH認可の落とし穴](/tech/details/5717/)を参照してください。

### トークンの保存先と環境変数の優先順位

取得したトークンは、macOSのキーチェーンやWindowsの資格情報マネージャーといったOSの資格情報ストアに保存されます。ストアが使えないと平文ファイルへ書き込まれるため、共有サーバーでは `gh auth status` で保存先を必ず確認してください。

環境変数を設定すると、保存済みの資格情報より優先されます。github.comとghe.com向けは `GH_TOKEN` → `GITHUB_TOKEN`、Enterprise Server向けは `GH_ENTERPRISE_TOKEN` → `GITHUB_ENTERPRISE_TOKEN` の順です。ログイン済みの端末で `GITHUB_TOKEN` が別の値で残っていると、意図しないアカウントで操作が走ります。

### 複数アカウントの切り替えとスコープの追加

同じホストに個人用と業務用の2アカウントでログインしている場合は、`gh auth switch` で有効なアカウントを切り替えます。操作が権限不足で止まったときは、`gh auth refresh -s スコープ名` で不足分を追加します。`gh auth token` を使うと、現在のトークンを他のツールへ渡せます。

## よく使うghコマンド一覧と使い方

v2.101.0の `gh --help` には、主要コマンドとしてauth・browse・codespace・discussion・gist・issue・org・pr・project・release・repo・skillの12個、Actions用としてcache・run・workflowの3個が並びます。日常でよく使うのは次のコマンドです。

| コマンド                     | 用途                 |
| ------------------------ | ------------------ |
| gh repo clone OWNER/REPO | リポジトリを複製           |
| gh repo create           | 新規リポジトリを作成         |
| gh repo fork / sync      | フォークと上流への追従        |
| gh pr create             | プルリクエストを作成         |
| gh pr list / status      | PR一覧と自分の担当分        |
| gh pr checkout 番号        | PRのブランチを手元に取得      |
| gh pr checks             | CIの結果を確認           |
| gh pr merge              | PRをマージ             |
| gh issue create / list   | Issueの起票と一覧        |
| gh run list / watch      | Actionsの実行一覧と監視    |
| gh release download      | リリースのアセットを取得       |
| gh status                | 担当PR・Issue・通知を横断表示 |
| gh browse                | 現在のリポジトリをブラウザで開く   |

各コマンドの引数は `gh コマンド サブコマンド --help` で確認できます。全コマンドを1画面で見るなら `gh help reference` です。

### プルリクエストを作成してマージするまでの流れ

```
git switch -c fix-login
# ここで追跡済みファイルの文言を編集する
# 新規ファイルを含める場合は、先に対象ファイルをgit addする
git commit -am "ログイン画面の文言を修正"
git push -u origin fix-login
gh pr create --fill --base main       # コミット内容からタイトルと本文を作成
gh pr checks --watch &&           # CIが成功した場合だけ次のマージを実行
gh pr merge --squash --delete-branch
```

レビューする側は、`gh pr checkout 123` でPRのブランチを手元に取得し、`gh pr diff` で差分を読み、`gh pr review --approve` で承認します。v2.98.0からは `gh pr checkout 123 --worktree ../wt-123` のように、作業中のブランチを切り替えずに別のworktreeへ取り出せます。v2.99.0では `gh pr create --attach ./before.png` で画像や動画を本文に添付できるようになりました（github.comとGitHub Enterprise Cloudのみ）。テンプレートやCODEOWNERS、マージ方式の選び方まで含めたPRの運用は[GitHubのPull Requestの作り方とマージ方式の決め方](https://www.issoh.co.jp/tech/details/18004/)で解説しています。

### Issueの起票から作業ブランチの作成まで

```
gh issue create --title "CSV出力で文字化け" --label bug --assignee @me
gh issue list --label bug --state open
gh issue develop 42 --checkout       # Issueに紐づくブランチを作成して切り替え
gh issue close 42 --comment "v1.3.2で修正"
```

`gh issue develop` で作ったブランチはIssueの画面に紐づいて表示されるため、誰がどのIssueに着手しているかがWeb側からも見えます。Issueの書き方やラベル運用は[GitHub Issueの使い方と運用のベストプラクティス](/tech/details/5898/)にまとめています。

### JSON出力とjqによるスクリプト連携

```
gh pr list --json number,title,author --jq '.[] | "\(.number) \(.author.login) \(.title)"'
```

一覧系のコマンドの多くは `--json` で出力する項目を選べ、`--jq` で絞り込めます。jqを別途インストールしなくても動くため、CIのステップ内でも使いやすい機能です。`--jq` に渡すフィルタの書き方は[jqコマンドの使い方｜JSONの抽出・整形・CSV変換を実行例で覚える](https://www.issoh.co.jp/tech/details/17923/)で解説しています。

## GitHub Actionsとgh apiで自動化する方法

GitHubのドキュメントによると、ghはGitHubホストランナーのすべてにプリインストールされています。ワークフローから呼ぶときは、ステップごとに環境変数 `GH_TOKEN` を設定します。次の例はIssueイベントで起動するジョブの `steps` に置く断片です。たとえば `on: {issues: {types: [opened]}}` で起動し、ジョブの `permissions` に `issues: write` を指定してください。

```
- run: gh issue comment "$ISSUE" --body "受け付けました"
  env:
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    ISSUE: ${{ github.event.issue.html_url }}
```

ワークフローの組み方は[GitHub Actionsでビルドと自動テストを設定する方法](/tech/details/2497/)、手動実行のinputsをghから渡す方法は[GitHub Actionsの手動実行（workflow\_dispatch）の解説](/tech/details/16931/)で扱っています。

### ワークフローの実行監視と失敗検知

```
gh workflow run deploy.yml -f env=staging
gh run list --workflow deploy.yml --limit 5
# 1234567890は、一覧で確認した監視対象の実行IDに置き換える
gh run watch 1234567890 --exit-status   # 失敗したら0以外で終了
gh run download 1234567890 -n build-output
```

ghの基本的な終了コードは、成功が0、失敗が1、キャンセルが2、認証が必要な場合が4です（`gh help exit-codes`）。ただし、コマンド固有の終了コードもあり、`gh pr checks` はチェック保留中に8を返します。`gh run watch` は既定では実行が失敗しても0で終わるため、シェルスクリプトで失敗を拾うなら `--exit-status` が必要です。なお、`gh run watch` はfine-grained PATによる認証には対応していません。

### gh apiによるREST・GraphQL APIの呼び出し

```
gh api repos/cli/cli/releases/latest --jq .tag_name
gh api --paginate "repos/{owner}/{repo}/issues?state=open" --jq '.[].title'
gh api graphql -f query='query { viewer { login } }'
```

`gh api` は認証ヘッダーを自動で付け、`{owner}` と `{repo}` をカレントディレクトリのリポジトリから埋めます。専用のサブコマンドが無い操作も、APIのエンドポイントさえ分かれば実行できます。

## プロキシ環境・社内ネットワークでghを使う設定

ghは設定ファイルにプロキシ用の項目を持っていません。HTTP通信にGo標準の `http.DefaultTransport` を使うため（go-gh v2.16.1の `pkg/api/http_client.go`）、環境変数 `HTTPS_PROXY`・`HTTP_PROXY`・`NO_PROXY` がそのまま効きます。v2.101.0で、つながらないプロキシを指定して動作を確認しました。

```
$ HTTPS_PROXY=http://127.0.0.1:9 gh release download v2.101.0 -R cli/cli -p 'gh_2.101.0_checksums.txt'
Get "https://api.github.com/repos/cli/cli/releases/tags/v2.101.0": proxyconnect tcp: dial tcp 127.0.0.1:9: connect: connection refused

$ HTTPS_PROXY=http://127.0.0.1:9 NO_PROXY=github.com,api.github.com,.githubusercontent.com gh release download v2.101.0 -R cli/cli -p 'gh_2.101.0_checksums.txt'
（成功・終了コード0）
```

1つ目はプロキシ経由で接続しようとして失敗し、2つ目は `NO_PROXY` で除外したため直接つながりました。社内プロキシがTLSを復号して検査している場合は、プロキシのルート証明書をOSの証明書ストアへ登録する必要があります。なお、v2.100.0で追加された `api_host` 設定はAPI通信をゲートウェイへ振り向ける実験的な機能で、リリースノートは「セキュリティ境界ではない」と明記しています。プロキシの代わりにはなりません。

## ghのテレメトリ送信の中身と停止方法

v2.91.0（2026年4月22日）から、ghは仮名化したテレメトリを既定で送信しています。[テレメトリの公式説明](https://docs.github.com/en/github-cli/github-cli/github-cli-telemetry)では、エージェントからの利用が増えるなかで機能の使われ方を把握するため、と理由が説明されています。GitHub Enterprise Serverに接続している場合は収集されません。

送信内容は `GH_TELEMETRY=log` を付けると、送信せずに標準エラーへ表示されます。macOS・amd64の未認証環境で、v2.101.0の `gh repo view cli/cli --json name` をログモードで実行したところ、コマンド自体は認証エラーになりましたが、送信予定のデータにはコマンド名（`gh repo view`）、フラグ名（`json`）、OSとCPUアーキテクチャ、端末ID、CI内かどうか、呼び出し元のコーディングエージェント名などが含まれていました。フラグの値やリポジトリ名は含まれていませんでした。

```
gh config set telemetry disabled   # 設定ファイルで停止
export GH_TELEMETRY=false          # 環境変数で停止（設定より優先）
export DO_NOT_TRACK=true           # 共通の慣習でも停止できる
```

社内の標準端末へ配布する場合は、導入手順の中に停止設定を入れておくのが確実です。この設定はgh本体だけが対象で、拡張機能や `gh copilot` が起動するCopilot CLIの利用データは別扱いだと公式ドキュメントに書かれています。

## 補完・エイリアス・拡張機能で入力を減らす設定

シェル補完は `gh completion -s zsh` のように、シェルを指定して補完スクリプトを出力します（bash・zsh・fish・PowerShellに対応）。ヘルプによると、パッケージマネージャーで入れた場合は追加設定なしで補完が効くことがあります。手動設定する場合、bashでは先にパッケージマネージャーで `bash-completion` をインストールし、`~/.bash_profile` に `eval "$(gh completion -s bash)"` を追記します。

```
gh alias set pv 'pr view'          # gh pv 123 で gh pr view 123
gh alias set bugs 'issue list --label=bugs'
gh extension install OWNER/gh-EXTNAME   # 拡張機能を追加
```

拡張機能は名前が `gh-` で始まるリポジトリとして配布され、組み込みコマンドを上書きできません。`gh copilot` はv2.101.0の時点でプレビュー扱いで、実行するとCopilot CLI本体を起動します（未インストールなら自動でダウンロード）。Copilot CLIそのものの機能と料金は[GitHub Copilot CLIの動作モードと料金の解説](/tech/details/11137/)を参照してください。`gh skill` と `gh agent-task` もプレビューで、仕様が変わる前提で試す位置付けです。

## ghコマンドに関するよくある質問

### ghコマンドとは何ですか？

GitHub公式のコマンドラインツールGitHub CLIの実行ファイル名です。プルリクエスト・Issue・Actions・リリースなどGitHub上の操作をターミナルから実行します。gitの代わりではなく、gitと併用するツールです。

### GitHub CLIはWindowsで使えますか？

使えます。公式の推奨は `winget install --id GitHub.cli --source winget` です。インストール後はWindows Terminalの新しいウィンドウを開いてから `gh --version` を実行してください。

### ghコマンドでブランチを作成できますか？

`gh branch` は存在せず、実行すると`unknown command "branch" for "gh"` というエラーで終わります。ブランチの作成は `git switch -c` を使います。Issueに紐づくブランチなら `gh issue develop` で作れます。

### 「GitHub CLIの認証の有効期限が切れました」と表示されたらどうすればよいですか？

`gh auth status` で状態を確認し、`gh auth login` で認証し直します。`GH_TOKEN` や `GITHUB_TOKEN` に期限切れのトークンが残っていると、再ログインしても環境変数が優先されるため、変数を削除するか新しいトークンに差し替えてください。

### プロキシ環境でGitHub CLIを使うにはどうすればよいですか？

環境変数 `HTTPS_PROXY` にプロキシのURLを設定します。ghにはプロキシ用の設定項目がなく、Go標準の仕組みで環境変数を読みます。除外したいホストは `NO_PROXY` に書きます。

## 関連記事

- [Gitコマンド一覧｜用途別早見表とよく使う基本コマンドの使い方を解説](/tech/details/2787/)
- [GitHub PAT（Personal Access Token）とは？作成方法・classic／fine-grainedの違い・スコープ・有効期限を解説](/tech/details/7545/)
- [GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方](/tech/details/2497/)
- [GitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説](/tech/details/11137/)
- [GitHubとGitLabの違い｜料金・Free枠・CI/CD・セルフホストを比較【2026年版】](/tech/details/4219/)

---

出典: [ghコマンド（GitHub CLI）とは？インストール方法と使い方・コマンド一覧【v2.101対応】](<https://www.issoh.co.jp/tech/details/3547/>)（株式会社一創）