DEV Community

Cover image for APIテストにおすすめの軽量CLIツール
Akira
Akira

Posted on • Originally published at apidog.com

APIテストにおすすめの軽量CLIツール

ほとんどのAPIテストツールでは、最初のリクエストを送るまでにウィンドウを開き、サインインし、ワークスペースを操作する必要があります。GUIでの確認には便利ですが、ターミナルでは「1行入力してレスポンスを確認し、次へ進む」方が効率的です。軽量なCLIツールなら、ツール自体は最小限に留まり、HTTPリクエストとレスポンスの確認に集中できます。

今すぐApidogを試す

ここでいう「軽量」は、単に機能が少ないという意味ではありません。単一バイナリや小さなnpmパッケージで導入できること、起動が速いこと、最初のリクエストに設定やログインが不要なこと、さらに出力をjqやgrepへ渡せることが重要です。GUIを含む選択肢も比較したい場合は、最適な無料APIテストツールも参照してください。

この記事では、REST/HTTP API向けの軽量CLIツールを8つ紹介します。手動リクエスト向けの最小ツールから、CIでアサーションや負荷テストを実行するツールまで、用途ごとに実装例と選び方を整理します。

APIテストでCLIツールを「軽量」にする条件

ターミナルで動くことと、軽量であることは同じではありません。この記事では、次の4点を基準にします。

  • 小さいフットプリント

    単一バイナリ、pip/npmでのインストール、またはnpxのワンライナーで使えること。追加ランタイムやデーモンが不要であるほど扱いやすくなります。

  • 高速な起動

    起動直後にリクエストを送信できること。RustやGo製バイナリは、この点で有利です。

  • 低設定または設定不要

    プロジェクトファイル、アカウント、ログインなしで最初のリクエストを実行できること。繰り返し利用する設定だけを後から追加できるのが理想です。

  • ターミナルネイティブな出力

    結果を読みやすく表示でき、別コマンドへパイプできること。CIでは、終了コードで成功・失敗を判定できることも重要です。

最初の3点は手動でAPIを確認する際に特に重要です。4点目は、CLIをCIパイプラインに組み込むときに効いてきます。手動APIクライアントの比較を深掘りしたい場合は、REST APIテストのためのcurlの代替品も確認してください。

curl: すでにインストールされているベースライン

curlは、macOS、多くのLinuxディストリビューション、最新のWindowsで利用できます。つまり、最も軽量な導入方法は「何もインストールしない」ことです。

まずはバージョンを確認します。

curl --version
Enter fullscreen mode Exit fullscreen mode

JSONをPOSTし、HTTPステータスコードだけを取得する場合は次のように書けます。

curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'
Enter fullscreen mode Exit fullscreen mode

レスポンス本文をjqで確認する例です。

curl -s https://httpbin.org/get \
  -H "Accept: application/json" \
  | jq '.headers'
Enter fullscreen mode Exit fullscreen mode

最適な用途

  • 一時的なHTTPリクエスト
  • シェルスクリプト
  • 新しいツールを導入できない環境

制限

  • ヘッダーやボディを手作業で指定する必要があります。
  • JSONの整形はjqなどに任せる必要があります。
  • アサーションやテスト結果の判定は、自分で実装します。

curlは「送信して確認する」ための基準ツールです。テストランナーではありません。

HTTPie: 人間のためのcurl

HTTPieは、curlと同じHTTPリクエストを、より読みやすい構文で実行するCLIです。ヘッダーやJSONフィールドをkey=value形式で書けて、レスポンスもデフォルトで色付け・整形されます。

python -m pip install httpie
# または
brew install httpie
Enter fullscreen mode Exit fullscreen mode

JSONをPOSTする例です。

# age:=24 は数値、name=acme は文字列として送信されます
http POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

認証ヘッダーを指定する場合も、コマンドが比較的読みやすくなります。

http GET https://httpbin.org/bearer \
  Authorization:"Bearer $API_TOKEN"
Enter fullscreen mode Exit fullscreen mode

最適な用途

  • APIを手動で探索する
  • curlより読みやすいコマンドを使いたい
  • レスポンスを整形して確認したい

制限

  • Pythonランタイムが必要です。
  • コンパイル済みバイナリと比べると起動が遅くなる場合があります。
  • curlと同様に、レスポンスを読むクライアントであり、アサーションを実行するテストランナーではありません。

xh: 単一バイナリで使うHTTPie風クライアント

xhは、HTTPie風の構文をRustで実装したCLIです。key=value形式の使いやすさを維持しながら、単一バイナリとして高速に起動できます。

brew install xh
# または
cargo install xh --locked
Enter fullscreen mode Exit fullscreen mode

HTTPieとほぼ同じ感覚でPOSTできます。

xh POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

実行するリクエストに相当するcurlコマンドを確認したい場合は、--curlを使えます。

xh --curl POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

最適な用途

  • HTTPieの構文が好き
  • Pythonランタイムなしで使いたい
  • 高速に起動する単一バイナリが必要

制限

  • HTTPieの全機能やプラグインシステムを実装しているわけではありません。
  • HTTPieよりエコシステムは小さめです。
  • アサーションエンジンではなく、HTTPクライアントです。

Hurl: CIで実行するプレーンテキストHTTPテスト

Hurlは、HTTPリクエストとアサーションをプレーンテキストの.hurlファイルに記述し、CLIから実行するツールです。単発のリクエスト確認ではなく、レスポンスを検証するテストへ進みたい場合に向いています。

brew install hurl
# または
cargo install --locked hurl
Enter fullscreen mode Exit fullscreen mode

ログインリクエストをテストするlogin.hurlを作成します。

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF
Enter fullscreen mode Exit fullscreen mode

--testを指定して実行します。

hurl --test login.hurl
Enter fullscreen mode Exit fullscreen mode

アサーションが失敗すると、Hurlはゼロ以外の終了コードを返します。そのままCIのジョブを失敗させられます。

# 例: CIジョブ内のステップ
- name: Run API smoke tests
  run: hurl --test tests/*.hurl
Enter fullscreen mode Exit fullscreen mode

最適な用途

  • バージョン管理できるHTTPスモークテスト
  • 契約テストに近いチェック
  • プルリクエストでレビューしやすいテスト定義

制限

  • HTTP向けのツールです。
  • gRPCの実行や本格的な負荷生成には向きません。
  • 複雑なフローでは、スクリプトではなく複数の.hurlファイルを管理する形になります。

Step CI: 多段階フローをYAMLで定義する

Step CIは、APIワークフローを単一のYAMLファイルで記述して実行します。REST、GraphQL、gRPC、tRPC、SOAPをカバーし、OpenAPIスキーマに対する検証も可能です。

npm install -g stepci
Enter fullscreen mode Exit fullscreen mode

ワークフローを実行します。

stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

ログイン後にトークンを取得し、後続リクエストで使うような多段階フローでは、YAMLでステップ・値の取得・検証をまとめると管理しやすくなります。

# workflow.yml のイメージ
steps:
  - name: login
    request:
      url: https://example.com/login
      method: POST

  - name: get-profile
    request:
      url: https://example.com/me
      method: GET
Enter fullscreen mode Exit fullscreen mode

最適な用途

  • ログイン、トークン取得、後続API呼び出しを含むフロー
  • ローカルとCIで同じテスト定義を実行したいチーム
  • 宣言的なYAML形式でワークフローを管理したい場合

制限

  • Node.jsランタイムが必要です。
  • RustやGoの単一バイナリと比べるとフットプリントは大きくなります。
  • 導入前にリポジトリの最近のアクティビティを確認してください。

テスト種別を含めた設計については、APIテスト戦略も参考になります。

k6: ターミナルから実行する負荷テスト

k6は、機能テストではなく負荷・パフォーマンスの確認向けツールです。「レスポンスが正しいか」ではなく、「一定の負荷に耐えられるか」を検証します。

brew install k6
# またはDocker経由
docker run grafana/k6
Enter fullscreen mode Exit fullscreen mode

次のスクリプトでは、10 VUで30秒間リクエストを送り、p95レスポンスタイムが500ms未満であることをしきい値として設定します。

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 10,
  duration: '30s',
  thresholds: {
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get('https://httpbin.org/get');

  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}
EOF

k6 run load.js
Enter fullscreen mode Exit fullscreen mode

しきい値に違反すると、k6は終了コード99で終了します。CIではこの終了コードを失敗として扱えます。

最適な用途

  • CIでのパフォーマンスチェック
  • APIの負荷テスト
  • しきい値を使った性能劣化の検知

制限

  • 単一レスポンスを手動確認する用途には向きません。
  • 意味のある負荷シナリオを作るには、k6のJavaScript APIを学ぶ必要があります。
  • 機能テスト用クライアントではなく、負荷テストツールです。

Newman: Postmanコレクションをヘッドレス実行する

Newmanは、PostmanコレクションをCLIから実行するランナーです。すでにPostmanでリクエストやテストを管理しているチームなら、GUIを開かずに同じコレクションをCIで実行できます。

npm install -g newman
Enter fullscreen mode Exit fullscreen mode

Postmanからエクスポートしたコレクションと環境ファイルを指定します。

newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

CIでは、次のようにそのまま実行できます。

- name: Run Postman collection
  run: newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

コレクション内のテストが失敗すると、Newmanはゼロ以外の終了コードを返します。

最適な用途

  • 既存のPostmanコレクションをCIで再利用する
  • Postman上で作成済みのテストをヘッドレス実行する
  • 環境ファイルを切り替えながらテストする

制限

  • Node.jsランタイムが必要です。
  • Postmanコレクション形式に依存します。
  • テストの作成は主にPostman GUIで行うワークフローになります。

Apidog CLI: 構築したシナリオを実行し、終了コードでCIをゲートする

Apidog CLIは、Apidogで視覚的に設計したテストシナリオを、ターミナルからヘッドレス実行するためのCLIです。リクエストの連結、変数の抽出、アサーションの作成はGUIで行い、実行はCIやローカル環境からCLIで行えます。

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
Enter fullscreen mode Exit fullscreen mode

シナリオを実行します。

# シナリオのCI/CDタブから、ID入りのコマンドをコピーします
apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

シナリオIDや環境IDを手入力で推測する必要はありません。Apidogで対象シナリオを開き、CI/CDタブからIDが入力済みのapidog runコマンドをコピーします。

-r cliを指定すると、各ステップの結果と概要がターミナルに出力されます。CIシステムでJUnit形式の結果も利用したい場合は、レポーターを追加します。

apidog run -t <scenario_id> -e <env_id> -r cli,junit
Enter fullscreen mode Exit fullscreen mode

すべてのアサーションが成功するとapidog runは終了コード0を返し、失敗があればゼロ以外で終了します。そのため、CIのゲートとして直接利用できます。出力にはagentHints.nextStepsを含む構造化JSONも含まれ、AIコーディングエージェントが実行結果を読み取る用途にも対応します。

- name: Run Apidog scenario
  run: apidog run -t $SCENARIO_ID -e $ENV_ID -r cli,junit
Enter fullscreen mode Exit fullscreen mode

最適な用途

  • 複雑な多段階シナリオをビジュアルエディタで作成したい
  • 作成済みシナリオをCIやエージェントからヘッドレス実行したい
  • 終了コードでパイプラインを確実にゲートしたい

制限

  • curlやxhのような単体HTTPクライアントではありません。
  • Apidogプロジェクト内で管理するシナリオに紐付きます。
  • Apidogはオープンソースではありませんが、無料ティアとCLIを組み合わせて利用できます。

詳しい使い方は、Apidog CLI完全ガイド、apidog runコマンドリファレンス、Apidog CLIを使用してコマンドラインからREST APIをテストする方法を参照してください。

選び方

必要なのが単一リクエストなのか、再現可能なテストなのか、負荷テストなのかで選びます。

ツール 最適な用途 インストール オープンソース？ 備考
curl 一時的なリクエスト、スクリプト プリインストール はい (MIT/curl) ユニバーサル。アサーションは自作
HTTPie 読みやすい手動リクエスト pip install httpie はい (BSD-3) フレンドリーな構文。Pythonランタイム
xh HTTPie風の構文と高速起動 brew install xh はい (MIT) 単一のRustバイナリ
Hurl プレーンテキストHTTPテスト brew install hurl はい (Apache-2.0) --testでCIをゲート
Step CI 多段階YAMLフロー npm i -g stepci はい (MPL-2.0) REST/GraphQL/gRPC。Node.jsランタイム
k6 負荷とパフォーマンス brew install k6 はい (AGPL-3.0) JSスクリプト。しきい値で実行を失敗
Newman CIでのPostmanコレクション実行 npm i -g newman はい (Apache-2.0) Postman JSONをヘッドレス実行
Apidog CLI 視覚的に作成したシナリオのヘッドレス実行 npm i -g apidog-cli いいえ (無料プラン) 終了コードゲート。エージェント向け構造化JSON

実務では、次の順で選ぶと判断しやすくなります。

  1. 単発のエンドポイント確認: curlまたはxh
  2. バージョン管理できるHTTPアサーション: Hurl
  3. ログインから後続API呼び出しまで含むフロー: Step CI
  4. 負荷・レイテンシの検証: k6
  5. Postmanコレクションを既に持っている: Newman
  6. GUIで複雑なシナリオを設計し、CIで実行する: Apidog CLI

完全にGUIなしのワークフローも比較したい場合は、ヘッドレスAPIテストツールも確認してください。

軽量CLIツールを使う利点

軽量CLIツールは、ターミナル中心の開発、CIでの自動テスト、AIエージェントによるチェック実行で特に役立ちます。

  • curlとxhは、手動確認のループを速くします。
  • HurlとStep CIは、アドホックなリクエストを再現可能なテストに変えます。
  • k6は、APIが負荷に耐えられるかを検証します。
  • Newmanは、Postmanで作成済みのテストをCIで再利用します。
  • Apidog CLIは、視覚的なシナリオ作成とヘッドレス実行をつなぎます。

Apidogを使う場合は、Apidogで1つのシナリオを作成し、そのapidog runコマンドをCI設定へ追加するところから始めてください。Apidogをダウンロードして、ローカル実行からCIゲートまでの流れを確認できます。

Top comments (0)