開発向け軽量CLIツールおすすめ

ターミナルで使えるバックエンドとAPI開発向け軽量CLIツール10選:curl、HTTPie、xh、jq、gh、ngrok、mkcert、watchexec、Docker CLI、apidog-cli。

INEZA Felin-Michel

INEZA Felin-Michel

13 7月 2026

開発向け軽量CLIツールおすすめ

Apidog エンタープライズ

オンプレミスデプロイ

SSO & RBAC

SOC 2 準拠

Apidog Enterpriseを見る

バックエンド開発者の1日の大半は、小さく素早いループです。エンドポイントにリクエストを送信し、JSONを読み込み、調整し、繰り返す。そのために重いGUIを使うと、作業をするよりも読み込みを待つ時間の方が長くなります。

軽量なCLIツールは、その状況を覆します。これらは単一のバイナリまたはnpxで実行可能なパッケージとして提供され、1秒もかからずに起動し、設定ウィザードなしで一つの仕事をこなします。シェルスクリプトやCIジョブに組み込むことができ、邪魔になりません。APIやバックエンド作業では、これらの小さなツールのキットで、リクエストの送信、レスポンスの解析、ローカルポートの公開、テストスイートの実行といったほとんどのループをカバーできます。

このガイドでは、バックエンド開発者のPATHに加えるべき10のツールを選定しました。各セクションでは、その動作を実証する一つのコマンドを示します。テーマはフットプリントです。つまり、高速にインストールされ、高速に起動し、役立つまでほとんど何も要求しないツールです。これらのツールがどのように連携するかをより広範に理解するには、API開発ガイドが背景を説明しています。

button

開発においてCLIツールが「軽量」であるとはどういうことか

軽量であるとは、ツールの機能がどれだけ詰め込まれているかではなく、フットプリントと摩擦のことです。自分のツールキットに何を含めるかを決めるときは、次の4つの点を考慮してください。

以下のツールは、おおよそ最小で単一目的のものから、より機能が豊富なものへと並んでいます。curlはすでにあなたのマシンに入っています。残りのツールもすぐにインストールできます。

curl

curlは、他のすべてのHTTPツールが比較される基準です。すでにほとんどのマシンに搭載されており、あなたが触れるすべてのプロトコルに対応し、指示したとおりに動作します。エンドポイントが生きているかどうかの素早いチェックには、これより速いものはありません。

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"}'

-sはプログレスメーターを非表示にし、レスポンスがクリーンにパイプされるようにします。ヘッダーを表示するには-iを、ステータスコードのみを出力するには-w '%{http_code}'を、そして4xxまたは5xxでcurlがゼロ以外の終了コードを返すようにするには--failを追加します。これはCIチェック内で望ましい動作です。

最適用途: スクリプティング、CIヘルスチェック、そしてコピー&ペーストして共有したいあらゆるリクエスト。curlコマンドはどのチームメイトのマシンでも動作します。

正直な制限: フラグの構文が密集しており、JSONボディの処理は手動です。素早いインタラクティブなリクエストには、次の2つのツールの方が使いやすいでしょう。

HTTPie

HTTPie (http) は、curlの鋭い部分を取り除き、人間が手作業でリクエストを入力するために作られたツールです。JSONがデフォルトであり、出力は色付けされフォーマットされており、フラグを覚える代わりにシンプルなkey=valueの項目からリクエストを構築できます。

http POST httpbin.org/post name=apidog role=api-tool active:=true

これは {"name": "apidog", "role": "api-tool", "active": true} というJSONボディを送信します。=は文字列を設定し、:=は生のJSON値を設定し、header:valueはヘッダーを設定します。JSONブロブを引用符で囲む必要も、-H-dを管理する必要もありません。レスポンスは整形されて返されます。

最適用途: 可読性が重視されるインタラクティブなAPI探索。

正直な制限: Pythonパッケージであるため、ネイティブバイナリよりもコールドスタートが遅く、マシンにPythonが必要です。起動速度が重要であれば、xhを使用してください。

xh

xhはHTTPieの構文を単一のRustバイナリで実装したものです。HTTPieのリクエストアイテム形式を再実装しているため、name=value:=は同じように機能しますが、ランタイムなしで静的にリンクされた単一ファイルとして提供され、約30%高速に起動します。HTTP/2とHTTP/3もサポートしています。

xh POST httpbin.org/post name=apidog age:=24

HTTPieと同じ操作性で、ほぼ瞬時に起動します。依存関係のない単一バイナリであるため、Pythonを別途インストールすることなく、スリムなCIイメージやコンテナに組み込むことができます。GitHub上のxhプロジェクトでは、Linux、macOS、Windows用のビルド済みバイナリが提供されています。

最適用途: HTTPieの操作感を好みながら、スクリプトやコンテナ向けにネイティブの速度と依存関係なしのインストールを求める開発者。

正直な制限: HTTPieの一般的な機能はカバーしていますが、すべてのプラグインを網羅しているわけではありません。ほとんどのリクエスト作業では、このギャップが問題になることはありません。

jq

jqは、他のすべてのHTTPツールをより便利にします。これは、コマンドラインでJSONをフィルタリングおよび再構築する単一のバイナリであり、APIレスポンス全体を目で確認する代わりに、1つのフィールドを抽出できます。

curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'

これは星の数だけを出力します。jqは完全なクエリ言語を持っています。.items[] | .nameは配列をマッピングし、select(.active)はフィルタリングを行い、-rは引用符なしの生出力を提供するため、シェル変数にパイプできます。これはAPI呼び出しとスクリプトの残りの部分をつなぐ接着剤です。

最適用途: スクリプトやCIでJSONレスポンスからフィールドを抽出し、変換すること。

正直な制限: クエリ構文には学習曲線があり、深くネストされた変換は難解になることがあります。シンプルなフィールドアクセスでは簡単です。

gh (GitHub CLI)

ghは、GitHubのAPIを、あなたがcurlコマンドを一度も書くことなく、ターミナルに持ち込みます。gh auth loginを介して一度認証を処理し、その後プルリクエスト、イシュー、リリース、リポジトリをシンプルなコマンドで操作できます。デプロイとレビューフローがGitHub上で行われるバックエンドチームにとって、これはループからブラウザタブを一つ減らします。

gh pr create --title "Add rate limiting" --body "Closes #42" --base main

これは現在のブランチからPRを開きます。gh pr checksはCIを監視し、gh run watchはワークフローのライブ状況を追跡し、gh apiは、ラップされたコマンドでカバーされていないエンドポイントに対して、認証済みでページネーション対応のクライアントを提供します。

最適用途: GitHub自体をスクリプト化すること:CIからのPRオープン、リリースの作成、トークンを手動で管理することなくAPIをクエリすること。

正直な制限: GitHub専用であるため、GitLabやBitbucketを使用している組織では何も得られません。

ngrok

ngrokは、セキュアなトンネルを介してローカルポートを公開URLに公開します。Webhookハンドラを構築する場合や、ネットワーク外から開発サーバーにアクセスする必要がある場合、localhostを一つのコマンドで共有可能なリンクに変えます。このエージェントは、どこでも実行できる依存関係ゼロのバイナリです。

ngrok http 8080

これは公開のhttps:// URLをローカルのポート8080に転送し、ターミナルに表示します。また、http://127.0.0.1:4040でトラフィックインスペクターも実行し、そこでは通過したすべてのリクエストを再生できます。これは、制御できない支払いまたはGitのWebhookをデバッグする際に、非常に時間を節約できます。

最適用途: Webhook開発、進行中の作業をチームメイトと共有すること、ローカルコードに対してサードパーティのコールバックをテストすること。

正直な制限: 無料枠がある商用サービスです。無料プランではセッションごとにURLが変更され、レート制限があります。固定された名前で安定したローカルHTTPSが必要な場合は、代わりにmkcertを使用してください。

mkcert

mkcertは、ゼロ設定でローカルで信頼されたHTTPS証明書を作成します。Filippo ValsordaによってGoで書かれており、ローカルの認証局を作成し、システム信頼ストアにインストールし、ブラウザが警告なしで受け入れる証明書を発行する単一のバイナリです。これにより、https://localhostを恐ろしい赤い南京錠なしでローカルで実行できます。

mkcert -install
mkcert localhost 127.0.0.1 myapp.local

最初の行でローカルCAを一度設定します。2番目の行は、リストした名前に対して証明書とキーを発行し、開発サーバーまたはリバースプロキシに渡せる状態にします。OpenSSLの呪文も、リロードごとにクリックして通過する自己署名証明書も不要です。OAuthリダイレクト、セキュアなクッキー、またはHTTPSで異なる動作をするあらゆるものをテストするのが非常に簡単になります。

最適用途: 本番環境と一致するように、ローカル開発環境で本物の信頼されたHTTPSを取得すること。

正直な制限: 開発専用です。mkcertの証明書を本番環境で使用しないでください。また、生成されるルートCAキーは厳重に保管してください。そのキーは、あなたのマシン上のあらゆる名前に対して署名できてしまいます。

watchexec

watchexecは、ファイルが変更されるたびにコマンドを再実行します。これは、ディレクトリを監視し、保存した瞬間にサーバーを再起動したり、テストを再実行したりする単一のRustバイナリです。デフォルトで.gitignoreを尊重するため、ビルド成果物でトリガーされることはありません。

watchexec -e py -r 'pytest tests/'

-e pyはPythonファイルにフィルタリングし、-rは新しいプロセスを積み重ねるのではなく、長時間実行中のプロセスを再起動します。任意のコマンドを指すことができます。例えば、Goサーバーの場合はwatchexec -r 'go run .'、JSスイートの場合はwatchexec 'npm test'です。言語に依存しないため、スタックごとのウォッチャーではなく、一つのツールですべてのプロジェクトをカバーできます。

最適用途: フレームワーク固有のウォッチモードなしで、ローカルサーバーやテストスイートでの密な編集・実行ループ。

正直な制限: 監視と再実行はしますが、ホットモジュールリロードやプロセス内の状態保存は行いません。

Docker CLI

Docker CLIはここにあるツールの中で最も重いですが、その地位にふさわしいものです。ローカル開発で本物のPostgres、Redis、または完全な依存関係が必要な場合、docker runコマンド一つで、使い終わったら破棄できる使い捨てインスタンスを提供します。システムレベルのインストールも、残されたサービスもありません。

docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16

--rmは終了時にコンテナを削除し、-eはパスワードを設定し、-pはポートをホストにマッピングします。あなたのアプリはlocalhost:5432に接続し、実行ごとにクリーンなデータベースが得られます。postgres:16redis:7や他のイメージに置き換えれば、このパターンはそのまま機能します。

最適用途: マシンを汚染することなく、再現可能な形でローカル開発および統合テスト用のバッキングサービスを立ち上げること。

正直な制限: バイナリの意味では軽量ではありません。実行中のデーモンと実際のディスクおよびメモリが必要です。しかし、CLIはスクリプト可能でターミナルファーストであり、再現可能なローカルインフラストラクチャにおいては他の追随を許しません。

apidog-cli

コマンドラインでAPI作業を行う際、不足しているのは実際のAPIプロジェクト、つまりエンドポイント、スキーマ、環境、テストシナリオです。Apidogは、ターミナルとそのプロジェクトを接続する軽量なCLIであるapidog-cliを提供しています。これは一つのnpmパッケージとしてインストールされ、デスクトップアプリを開くことなく、リソースを設計、インポート、モック、テストするためのスクリプト可能なパスを提供します。

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ゲートに直接組み込むことができます。テスト以外にも、CLIはendpointschemaによる設計、スペック(OpenAPI、Swagger、Postman)のインポートとエクスポート、mockによるモック期待値の設定、environmentvariablesによる設定など、実際のコマンドグループをカバーしています。出力はagentHints.nextStepsを含む構造化JSONであり、これがAIコーディングアシスタントによるAPI開発にも適している理由です。完全なコマンドリファレンスについては、完全なApidog CLIガイドを参照してください。Apidog CLIインストールガイドでは、最初の実行手順を説明しています。

最適用途: 特に、契約がすべてを推進する仕様ファーストのAPI開発ワークフローにおいて、CIでテストシナリオを実行したり、スクリプトからプロジェクトリソースを管理したりする場合。

正直な注記: Apidogはオープンソースではありません。無料枠がある商用製品です。しかし、その無料枠とCLIを組み合わせることで、リクエストクライアント、モックサーバー、テストランナーを自分で組み合わせる代わりに、すべて一つのプロジェクトで統合された代替手段が得られます。軽量な部分はapidog-cliバイナリであり、完全なApidogプラットフォームは、同じプロジェクトの上に構築されたGUIです。

選び方

これらのほとんどは、競合するものではなく、補完し合うものです。HTTPクライアント、jq、トンネル、ウォッチャー、テストランナーなど、いくつか併用することになるでしょう。

ツール 最適用途 インストール オープンソース?
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 いいえ (フリーミアム)

タスクに応じて使い分けましょう。リクエストの送信:インタラクティブな作業にはxhまたはHTTPie、スクリプトにはcurl。レスポンスの読み取り:常にjq。ポートの公開:ngrok。ローカルHTTPS:mkcert。保存時の再実行:watchexec。バッキングサービス:Docker。APIテストの実行とプロジェクト管理:apidog-cli。

まとめ

優れた軽量キットとは、それぞれ一つのことを行い、次へとパイプできる、小さく高速なツールの集まりです。curlとxhはリクエストを送信し、jqはそれを読み取り、ngrokとmkcertはローカルアクセスを処理し、watchexecは編集・実行ループを閉じ、Dockerは使い捨てのインフラストラクチャを提供します。どれも役立つ前に多くのものを要求することはありません。

apidog-cliは、ループを実際のAPIプロジェクトに結びつける部分であり、ターミナルから実行するエンドポイントやテストは、チームが設計し提供するものと同じです。Apidogをダウンロードしてプロジェクトをセットアップし、CIパイプラインでCLIを使ってコマンドラインからそれを駆動してください。一度に一つのリクエストではなく、APIライフサイクル全体に適用された、同じ速度とフットプリントの考え方です。

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる