バックエンド開発では、エンドポイントへリクエストを送り、JSONを確認し、実装を調整して再実行する短いループを何度も繰り返します。重いGUIを毎回起動するより、すぐに実行できてスクリプトやCIにも組み込めるCLIツールを揃えると、このループを大幅に短縮できます。
この記事では、バックエンド開発者がPATHに追加しておきたい10個のCLIツールを紹介します。リクエスト送信、JSON解析、ローカルポート公開、HTTPS証明書の作成、ファイル監視、テスト実行、ローカル依存サービスの起動までをカバーします。API開発全体の流れについては、API開発ガイドも参照してください。
開発における「軽量なCLIツール」の基準
軽量さは機能数ではなく、導入と実行の摩擦の少なさで判断します。ツールを選ぶときは、次の4点を確認してください。
インストール形式とサイズ
単一バイナリや小さなnpxパッケージは、ランタイムや大量の依存関係を必要とするツールより導入しやすいです。起動速度
エディタに戻る前にコマンドが実行されている状態が理想です。RustやGoのバイナリはコールドスタートが速く、繰り返し実行するループで効果が出ます。最初の結果までの手順
アカウント作成、プロジェクト設定、ダッシュボード操作なしで使い始められるかを確認します。ゼロ設定で役立つデフォルトがあるツールは強力です。パイプ可能か
標準入力を読み、標準出力へ書き出し、適切な終了コードを返すツールは、他のCLIやCIと組み合わせやすくなります。
以下では、単機能で小さなツールから、ローカル開発基盤を扱うツールまで順に見ていきます。curlは多くの環境にすでに入っています。
curl
curlはHTTPリクエストを送るための基本ツールです。スクリプト、CI、障害調査で同じコマンドを再利用できるため、最初に覚えておく価値があります。
curl -s -X POST https://api.github.com/repos/curl/curl/issues \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"title":"Test issue"}'
実運用やCIでは、次のオプションもよく使います。
curl --fail --silent --show-error \
--write-out '%{http_code}\n' \
https://example.com/health
-
-s/--silent: プログレスメーターを非表示にする -
--show-error:--silent使用時もエラーを表示する -
-i: レスポンスヘッダーを表示する -
-w '%{http_code}': HTTPステータスコードを出力する -
--fail: 4xx・5xxでゼロ以外の終了コードを返す
最適用途: スクリプト、CIヘルスチェック、共有しやすいHTTPリクエスト。
制限: フラグが多く、JSONボディを手で組み立てる必要があります。
HTTPie
HTTPieのhttpコマンドは、人間が手作業でAPIを試すために設計されたHTTPクライアントです。JSONをデフォルトで扱え、レスポンスも整形して表示します。
http POST httpbin.org/post name=apidog role=api-tool active:=true
このコマンドは次のJSONを送信します。
{
"name": "apidog",
"role": "api-tool",
"active": true
}
指定方法は次のとおりです。
-
name=value: 文字列値 -
active:=true: JSON値 -
Authorization:Bearer: HTTPヘッダー
たとえばBearerトークン付きのGETリクエストは次のように書けます。
http GET https://api.example.com/users Authorization:"Bearer $TOKEN"
最適用途: 読みやすさを重視したインタラクティブなAPI探索。
制限: Pythonパッケージのため、ネイティブバイナリより起動が遅く、Python環境が必要です。
xh
xhはHTTPie互換の構文を提供するRust製CLIです。name=valueや:=といったHTTPieの使い心地を維持しながら、単一バイナリとして高速に起動します。
xh POST httpbin.org/post name=apidog age:=24
HTTPieと同様に、ヘッダーやJSON値を簡潔に指定できます。
xh GET https://api.example.com/users \
Authorization:"Bearer $TOKEN" \
page:=1
Pythonを別途導入せずに利用できるため、コンテナやスリムなCIイメージにも組み込みやすい選択肢です。GitHub上のxhプロジェクトでは、Linux、macOS、Windows向けのビルド済みバイナリを提供しています。
最適用途: HTTPie風の操作性と、ネイティブバイナリの速度を両立したい場合。
制限: HTTPieのすべてのプラグインを網羅しているわけではありません。
jq
jqはJSONレスポンスをフィルタリング、変換、抽出するためのCLIです。HTTPクライアントと組み合わせることで、APIレスポンスから必要な値だけを取り出せます。
curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'
文字列をシェル変数へ入れる場合は、-rを使います。
REPO_NAME=$(curl -s https://api.github.com/repos/stedolan/jq | jq -r '.name')
echo "$REPO_NAME"
よく使うフィルターは次のとおりです。
# 配列からnameだけを取り出す
jq '.items[] | .name'
# activeがtrueの要素だけを選ぶ
jq '.items[] | select(.active)'
# 必要なフィールドだけで新しいJSONを作る
jq '{id, name, status}'
最適用途: スクリプトやCIでJSONレスポンスを抽出・変換すること。
制限: 複雑な変換ではクエリ構文の学習が必要です。
gh(GitHub CLI)
ghはGitHub操作をターミナルから行うための公式CLIです。最初に一度だけ認証すれば、PR、Issue、Actions、リリース、GitHub APIをコマンドで扱えます。
gh auth login
現在のブランチからPRを作成する例です。
gh pr create \
--title "Add rate limiting" \
--body "Closes #42" \
--base main
CIの状況確認には次を使えます。
# 現在のPRのチェック結果を確認
gh pr checks
# GitHub Actionsの実行状況を監視
gh run watch
ラップされたコマンドにないAPIはgh apiで呼び出せます。
gh api repos/OWNER/REPO/issues --paginate
最適用途: GitHub上のPR、CI、リリース、API操作の自動化。
制限: GitHub専用です。GitLabやBitbucketには対応しません。
ngrok
ngrokはローカルポートを公開URLとして外部に公開するトンネルツールです。Webhook開発や、ローカルで動かしているAPIをチームメイトに見せるときに便利です。
ngrok http 8080
実行すると、ローカルのlocalhost:8080へ転送される公開https:// URLが表示されます。
Webhookを受ける開発では、表示されたURLを外部サービスに登録します。
https://<generated-subdomain>.ngrok.app/webhooks/payment
トラフィックはローカルのインスペクターでも確認できます。
http://127.0.0.1:4040
ここでは受信したリクエストを確認・再送できるため、支払いWebhookやGit webhookのデバッグに役立ちます。
最適用途: Webhook開発、ローカルサーバーの共有、外部コールバックのテスト。
制限: 無料プランではURLがセッションごとに変わり、レート制限があります。
mkcert
mkcertは、ブラウザやOSが信頼するローカルHTTPS証明書を作成するツールです。自己署名証明書の警告を回避しながら、https://localhostを使った開発とテストができます。
まず、ローカルCAをインストールします。
mkcert -install
続いて、必要なホスト名とIPアドレスの証明書を生成します。
mkcert localhost 127.0.0.1 myapp.local
生成された証明書とキーを、開発サーバーやリバースプロキシに設定します。OAuthリダイレクト、Secure Cookie、HTTPS必須のブラウザAPIなどをローカルで確認するときに有効です。
最適用途: 本番に近い信頼済みHTTPSをローカル環境で使うこと。
制限: 開発専用です。生成したルートCAキーは厳重に管理し、証明書を本番環境で使わないでください。
watchexec
watchexecはファイル変更を監視し、変更時に指定コマンドを再実行するRust製CLIです。フレームワーク固有のウォッチモードがないプロジェクトでも、保存・テスト・再起動のループを作れます。
Pythonテストを.pyファイル変更時に実行する例です。
watchexec -e py -r 'pytest tests/'
-
-e py:.pyファイルだけを監視する -
-r: 実行中プロセスを終了してから再起動する
ほかのスタックでも同じように使えます。
# Goサーバーを再起動
watchexec -r 'go run .'
# JavaScriptのテストを再実行
watchexec 'npm test'
デフォルトで.gitignoreを尊重するため、ビルド成果物などに不要に反応しにくい点も実用的です。
最適用途: 保存時にローカルサーバーやテストスイートを再実行すること。
制限: ホットモジュールリロードやプロセス内の状態保持は行いません。
Docker CLI
Docker CLIは単一バイナリという意味では軽量ではありませんが、ローカル依存サービスを使い捨てで起動するには非常に実用的です。Postgres、RedisなどをホストOSへ直接インストールせずに利用できます。
Postgres 16を起動する例です。
docker run --rm \
-e POSTGRES_PASSWORD=dev \
-p 5432:5432 \
postgres:16
アプリケーションは次のような接続情報で利用できます。
host: localhost
port: 5432
user: postgres
password: dev
Redisならイメージを差し替えるだけです。
docker run --rm -p 6379:6379 redis:7
-
--rm: コンテナ終了時に削除する -
-e: 環境変数を渡す -
-p: コンテナポートをホストへ公開する
最適用途: ローカル開発や統合テスト用のPostgres、Redisなどを再現可能に起動すること。
制限: Dockerデーモンとディスク・メモリが必要です。
apidog-cli
CLIだけでAPI作業を進める際に不足しやすいのは、エンドポイント、スキーマ、環境、テストシナリオといったAPIプロジェクトのコンテキストです。Apidogのapidog-cliは、ターミナルからAPIプロジェクトのリソースを操作し、テストシナリオを実行するためのCLIです。
インストールと認証は次のように行います。
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
保存済みのテストシナリオを特定環境に対して実行するには、次を使います。
apidog run -t <scenario_id> -e <env_id> -r cli
apidog runは実行結果をターミナルに表示し、すべてのアサーションが成功すると終了コード0、失敗時はゼロ以外の終了コードを返します。そのため、CIの品質ゲートに組み込めます。
apidog run -t "$SCENARIO_ID" -e "$ENV_ID" -r cli
CLIでは、テスト以外にも次の操作を扱えます。
-
endpoint、schema: API設計リソースの操作 - OpenAPI、Swagger、Postman仕様のインポート・エクスポート
-
mock: モック期待値の設定 -
environment、variables: 環境設定と変数の管理
出力はagentHints.nextStepsを含む構造化JSONで、AIコーディングアシスタントによるAPI開発にも適しています。コマンドの詳細は完全なApidog CLIガイド、導入手順はApidog CLIインストールガイドを参照してください。
最適用途: CIでのテストシナリオ実行、スクリプトからのプロジェクトリソース管理、仕様ファーストのAPI開発。
注記: Apidogはオープンソースではなく、無料枠のある商用製品です。apidog-cliは、リクエストクライアント、モック、テストを同じAPIプロジェクトと接続する選択肢になります。完全なApidogプラットフォームは、同じプロジェクトをGUIから扱うための環境です。
選び方
これらのツールは競合するよりも、組み合わせて使うものです。
| ツール | 最適用途 | インストール | オープンソース? |
|---|---|---|---|
| curl | スクリプトによるリクエスト、CIヘルスチェック | プリインストール済み | はい(curl license) |
| HTTPie | 読みやすいインタラクティブなリクエスト | pip install httpie |
はい(BSD) |
| xh | HTTPieの使い心地、ネイティブ速度 |
cargo install xh / バイナリ |
はい(MIT) |
| jq | JSONレスポンスのフィルタリング |
brew install jq / バイナリ |
はい(MIT) |
| gh | GitHub PRおよびCIのスクリプト化 |
brew install gh / バイナリ |
はい(MIT) |
| ngrok | localhostの公開、Webhook | バイナリをダウンロード | いいえ(フリーミアム) |
| mkcert | 信頼されたローカルHTTPS証明書 |
brew install mkcert / バイナリ |
はい(BSD) |
| watchexec | ファイル変更時の再実行 | cargo install watchexec-cli |
はい(Apache-2.0) |
| Docker CLI | 使い捨てのバッキングサービス | Dockerをインストール | はい(Apache-2.0) |
| apidog-cli | テストシナリオの実行、プロジェクト管理 | npm install -g apidog-cli |
いいえ(フリーミアム) |
まずは、現在の課題に合わせて次の組み合わせから始めるとよいでしょう。
APIリクエスト:
手作業の確認 → xh または HTTPie
スクリプト・CI → curl
JSONの処理:
jq
Webhookの受信:
ngrok
ローカルHTTPS:
mkcert
保存時の再実行:
watchexec
ローカル依存サービス:
Docker
APIテスト・プロジェクト操作:
apidog-cli
まとめ
軽量な開発環境は、それぞれが一つの仕事に集中し、標準入出力や終了コードを通じて連携するツールの集合です。
-
curlとxhでリクエストを送る -
jqでJSONを読む -
ngrokとmkcertでローカルアクセスを扱う -
watchexecで編集・実行ループを回す - Dockerで使い捨ての依存サービスを起動する
-
apidog-cliでAPIプロジェクトに紐づくテストとリソースを操作する
apidog-cliを使うと、ターミナルで実行するテストやエンドポイント操作を、チームが設計・管理するAPIプロジェクトと接続できます。Apidogをダウンロードしてプロジェクトをセットアップし、CIパイプラインからCLIを実行してください。単発のリクエストだけでなく、APIライフサイクル全体にCLIの速度と再現性を適用できます。
Top comments (0)