ブラウザを閉じろ。GitHub CLI (`gh`) でCI/CDパイプラインを完全掌握する高度自動化術
開発チームの生産性を測る最も分かりやすい指標の一つに、「エンジニアがマウスに手を伸ばす頻度」がある。
PRを作成するためにブラウザを開き、CIのビルドがコケた理由を知るためにGitHubのUIを彷徨い、失敗したジョブをポチポチと再実行する――。この数秒のコンテキストスイッチの積み重ねが、フロー状態にあるエンジニアの脳を容赦なく破壊する。
もし君がチームのテックリードであるなら、今すぐそのマウスを捨てさせろ。そして、ターミナルから一歩も出ずにGitHub Actionsのすべてを支配するGitHub CLI (`gh`) の真の力を叩き込め。
今回は、単なるコマンドの紹介にとどまらない。APIの裏側までハックし、シェルスクリプトやcronと組み合わせて「社内のCI運用を完全に自動化・最適化する」ための実践的な知見を共有する。
—
1. 現場のスピードを劇的に上げる `gh` 隠しコマンドとキーボードショートカット
まずは、日常の開発フローにおいて「ブラウザを開く理由をゼロにする」ための基本と、プロが使っている高速化のテクニックだ。
インストールと初期認証の極意
言わずもがなだが、最新の `gh` CLIを入れろ。パッケージマネージャー（Homebrewなど）で入れるのが定石だ。
macOSの場合
brew install gh
認証（トークン権限は workflow を必ず含めること）
gh auth login -h github.com -p ssh –scopes “repo,workflow,read:packages”
1秒でCIの生死を判定する `gh run` の神エイリアス
CIが落ちたとき、君はログを見るために何クリックしている？ `gh run` を使えば、ターミナル上で完結する。
直近のワークフロー実行状況を一覧で確認（インタラクティブ）
gh run list –limit 10
【神コマンド】直近で失敗したワークフローを即座に再実行する
gh run rerun –failed
これを `.zshrc` や `.bashrc` に以下のエイリアスとして登録しておけ。チーム全員に強制しろ。世界が変わる。
失敗したCIの再実行
alias ghrf=”gh run rerun –failed”
実行中のCIをリアルタイムでウォッチ
alias ghw=”gh run watch”
—
2. 絶対に入れるべき神拡張機能（Extensions）
`gh` CLIの真骨頂は、公式機能だけではない。コミュニティ製（あるいはGitHub公式開発）の拡張機能（Extensions）にこそ、真の魔術が隠されている。
以下の2つは、CI/CDを扱う上でインフラレベルの必須ツールだ。
① `ghwf` (Workflow管理の拡張)
ワークフローファイルのバリデーションや、ローカルでのテスト実行を補助する。
gh extension install yusukebe/gh-wf
② `gh-dash` (ターミナル版GitHubダッシュボード)
これを入れた瞬間から、君のターミナルはNASAのコントロールルームになる。PR、Issue、そしてGitHub Actionsの実行ステータスがリアルタイムでマトリクス表示される。
gh extension install dlvhdr/gh-dash
設定ファイル (`~/.config/gh-dash/config.yml`) をチューニングし、自分のアサインされているPRと関連するCIのステータスを常時監視できるようにしておこう。ブラウザのタブはもう2度と開く必要がない。
—
3. 実践：APIを直接叩き、CIを制御・ハックするシェルスクリプト
ここからが本題だ。GitHub Actionsの標準機能だけでは実現できない「痒い所に手が届く自動化」を、`gh api` とシェルスクリプトを組み合わせて実装する。
ケーススタディ：夜間バッチの「孤児ラン（Orphan Runs）」を全抹消するスクリプト
開発が活発なリポジトリでは、PRの乱立によってキャンセルし忘れた古いワークフローや、テスト用のゴミランがストレージとAPIレートリミットを圧迫する。
これをcronで毎晩自動クリーンアップするスクリプトを記述する。
!/usr/bin/env bash
==============================================================================
clean-stale-runs.sh
実行中の古いワークフローや、キューに溜まったままのジョブを強制キャンセル・削除する
==============================================================================
set -euo pipefail
REPO=”your-org/your-mission-critical-repo”
WORKFLOW_NAME=”CI/CD Pipeline”
echo “==> Fetching queued or in_progress runs for ${REPO}…”
1. gh api を使って、JSON形式でターゲットのrun IDを取得する
状態が ‘queued’ または ‘in_progress’ のものをフィルタリング
RUNS_JSON=$(gh api \
-X GET \
“repos/${REPO}/actions/runs?status=in_progress&per_page=50” \
–jq ‘.workflow_runs[] | select(.name == “‘”${WORKFLOW_NAME}”‘”) | .id’)
if [ -z “$RUNS_JSON” ]; then
echo “==> No active runs found for ‘${WORKFLOW_NAME}’.”
exit 0
fi
2. 取得したIDに対してキャンセルリクエストを送信する
for RUN_ID in $RUNS_JSON; do
echo “Cancelling run ID: ${RUN_ID}…”
gh api \
-X POST \
“repos/${REPO}/actions/runs/${RUN_ID}/cancel” \
–silent
echo “Successfully cancelled run ${RUN_ID}.”
done
echo “==> Cleanup completed successfully.”
これをサーバの `crontab` に登録しておけば、野良CIの暴走によるリソース枯渇とは永遠にオサラバだ。
—
4. チーム開発における設定の共有化ルールと自動化パイプライン
個人がCLIを使いこなすだけでは、組織の生産性は頭打ちになる。チーム全体で「CLIファースト」な開発文化をスケールさせるためのルール作りを伝授する。
1. `gh` を前提とした Makefile の共通化
プロジェクトのルートに `Makefile` を配置し、複雑なCI操作やローカル検証コマンドを抽象化する。これにより、メンバーはコマンドを覚える必要すらなくなる。
==============================================================================
Makefile for CI/CD Operations via GitHub CLI
==============================================================================
.PHONY: ci-status ci-logs ci-retry
直近のCIステータスを確認
ci-status:
@gh run list –limit 5
直近の失敗したCIのログをターミナルに直接吐き出す（トラブルシューティング用）
ci-logs:
@FAILED_RUN_ID=$$(gh run list –status failure –limit 1 –json databaseId –jq ‘.[0].databaseId’); \
if [ -z “$$FAILED_RUN_ID” ]; then \
echo “No failed runs found.”; \
else \
echo “Fetching logs for failed run: $$FAILED_RUN_ID”; \
gh run view “$$FAILED_RUN_ID” –log-failed; \
fi
失敗したCIをピンポイントで再実行
ci-retry:
@gh run rerun –failed
@echo “Retriggered failed jobs. Watching status…”
@gh run watch
開発者は `make ci-logs` と叩くだけで、ブラウザを開いてログの折り畳みを展開する苦行から解放される。
2. ワークフロー定義のベストプラクティス（YAML構成例）
CLIからの制御性を高めるためには、GitHub Actions側のYAML設計もそれに最適化されている必要がある。特に `concurrency` の設定は、CLIから手動実行（`gh workflow run`）する際の二重実行を防ぐために不可欠だ。
.github/workflows/deploy.yml
name: Production Deployment
on:
workflow_dispatch:
inputs:
environment:
description: ‘Target environment to deploy’
required: true
default: ‘staging’
type: choice
options:
- staging
- production
force_migrate:
description: ‘Force DB migration’
required: false
type: boolean
default: false
【重要】CLIからの手動実行も含め、同一ブランチ/環境での競合を防ぐ
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}-${{ inputs.environment }}
cancel-in-progress: true
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Execute Deployment
run: |
echo “Deploying to ${{ inputs.environment }}…”
echo “Force Migrate: ${{ inputs.force_migrate }}”
# デプロイ処理の実態…
このワークフローに対し、CLIから以下のようにパラメータ付きでキックできる。
gh workflow run “Production Deployment” \
-f environment=production \
-f force_migrate=true
もはや、GitHubのWeb UIにある「Run workflow」のボタンをクリックするためにブラウザに切り替える理由は1ミリも存在しない。
—
5. 終わりに：ツールを使い倒す者だけが、開発の主導権を握る
CI/CDツールに振り回されるな。ツールを使い倒せ。
今回紹介した `gh` CLIを用いたワークフロー制御は、単なる「効率化のテクニック」ではない。開発のフィードバックループを極限まで圧縮し、エンジニアリングの集中力を保つための防衛策である。
明日からチームの定例でこう宣言しろ。
「これより我がチームのCI/CD操作は、すべてターミナル経由に移行する」と。
その瞬間から、君たちの開発スピードはネクストステージへと突入するはずだ。