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

ほとんどのAPIテストツールは、1つのリクエストを送信する前に、ウィンドウを開き、サインインし、ワークスペースをあちこちクリックすることを求めます。それは最初に見る分には問題ありません。しかし、ターミナルでは、1行入力し、応答を読み、次に進みたいので、これは適していません。軽量なコマンドラインツールは順序を逆転させます。ツールは邪魔にならず、リクエストがやり取りのすべてになります。

ここで言う「軽量」とは、具体的な意味を持ちます。それは、通常1つのバイナリ、または簡単なnpxによる小さなインストール。高速な起動で、エンドポイントにアクセスする感覚が即座であること。最初のリクエストを実行するための設定がほとんど、あるいはまったくないこと。jqやgrepにパイプできるターミナルファーストの出力であること。「どのツールがオープンソースか」とか「どのツールが最も機能が多いか」といった質問とは異なります。これはフットプリントと摩擦に関するものです。ホスト型GUIも網羅したより広範な調査については、最適な無料APIテストツールのまとめをご覧ください。

以下に、RESTおよびHTTP APIをテストするための8つの軽量CLIツールを紹介します。これらは、最小限で手動なものから、CIで完全なテストスイートを実行するものまで、おおよそ順に並べられています。各項目には、実際のインストールコマンド、動作を示すコマンド、得意なこと、そして正直な制限が記載されています。最後のApidog CLIは、視覚的に構築したシナリオを実行し、その終了コードに基づいてパイプラインをゲートする軽量バイナリです。

APIテストにおいてCLIツールを「軽量」にするもの

多くのツールがターミナルで動作します。しかし、すべてが軽量に感じられるわけではありません。このリストにおいて、ツールは次の4つの点で評価されます。

• 小さいフットプリント。 単一のバイナリ、pip/npmによるインストール、またはnpxによるワンライナー。まず設定する必要があるランタイムがなく、理想的にはデーモンもありません。
• 高速起動。 ツールがウォームアップなしで起動し、リクエストを送信します。RustおよびGoのバイナリがここで優位に立ちます。重いランタイムを起動するものは劣ります。
• 低またはゼロ設定。 プロジェクトファイル、アカウント、ログインなしで最初の要求を送信できます。設定は、保存して繰り返したい場合にオプトインです。
• ターミナルネイティブ出力。 結果は一目で読める形式で出力され、別のコマンドにパイプできます。終了コードには意味があり、CIでそれらをゲートできます。

最初の3つのポイントがツールの主要な特徴であり、後の2つのツールは4番目のポイントに重点を置いています。なぜなら、軽量バイナリがパイプラインでその役割を果たすのはそこだからです。インタラクティブで手動でエンドポイントを操作する側についてさらに詳しく知りたい場合は、REST APIテストのためのcurlの代替品ガイドで、手動クライアントについて詳しく説明しています。

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

curlは、あなたがほぼ確実にすでに持っているツールです。macOS、ほとんどのLinuxディストリビューション、および最新のWindowsに搭載されているため、最も軽量なインストールは「インストールなし」です。HTTP、HTTPS、その他多くのプロトコルをサポートしており、他のすべてのクライアントが自分自身を比較する基準となっています。

# すでにマシンにインストールされています。バージョンを確認します
curl --version

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

最適な用途：一時的な簡単なリクエスト、スクリプト、新しいものをインストールできないあらゆる環境。正直な制限：人間工学が古いです。ヘッダーは手動で設定し、JSONはきれいに整形されず、レスポンスをアサートするにはjqにパイプして自分で終了コードを確認する必要があります。送信して表示するだけで、テストはしません。

HTTPie: 人間のためのcurl

HTTPieは、curlと同じリクエストを、人向けに構築された構文で実行します。コマンドはhttpで、ヘッダーとJSONフィールドはシンプルなkey=valueのペアで、出力はデフォルトで色付けされ整形されています。Pythonで書かれているため、Pythonランタイムが必要であり、単一バイナリよりは重くなりますが、それでも1行でインストールできます。

python -m pip install httpie   # または: brew install httpie

# JSONをPOST: age:=24は数値を送信し、name=は文字列を送信します
http POST httpbin.org/post name=acme age:=24 plan=pro

最適な用途：フラグなしで読みやすい出力が必要な場合に、APIを手動で探索する。正直な制限：Pythonの起動はコンパイルされたバイナリよりも著しく遅く、クリーンなシステムにインストールする場合は、PythonがなければPythonを導入することになります。curlと同様に、これはクライアントでありテストランナーではありません。レスポンスを読み取るだけで、それに対してアサートはしません。

xh: 単一バイナリで実現するHTTPieの速度

xhは、HTTPieの使いやすい構文をRustで再実装し、1つの静的にリンクされたバイナリとして提供されます。これにより、同じkey=valueの人間工学と色付きの出力が得られ、起動が高速で、バイナリ自体以外に何もインストールする必要がありません。HTTP/2をサポートし、--curlオプションで同等のcurlコマンドを出力することもできます。

brew install xh   # または: cargo install xh --locked

# HTTPieと同じ構文、より高速な起動
xh POST httpbin.org/post name=acme age:=24 plan=pro

最適な用途：HTTPieの使い心地が好きだが、ランタイムなしで単一の高速バイナリを求める開発者。正直な制限：HTTPieの全機能を実装しているわけではなく、プラグインシステムもありません。HTTPieよりも新しいため、そのエコシステムは小さいです。依然としてクライアントであり、アサーションエンジンではありません。

Hurl: CIで実行されるプレーンテキストテスト

Hurlは、このリストが「リクエストの送信」から「レスポンスのテスト」へと移行する地点です。これはプレーンテキストの.hurlファイルで書かれたHTTPリクエストを実行し、その結果をアサートします。Rustで書かれており、内部ではlibcurlによって動作し、ランタイムなしで単一のバイナリとして提供されます。テストはリクエスト自体のように読めるため、プルリクエストでのレビューが容易です。

brew install hurl   # または: cargo install --locked hurl

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

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

hurl --test login.hurl   # アサーションが失敗した場合、ゼロ以外の終了コード

最適な用途：バージョン管理下に読みやすいテキストとして保持する、契約スタイルのチェックやスモークテスト。--testフラグによりクリーンなCIゲートとなり、アサーションの失敗はゼロ以外の終了コードを返します。正直な制限：HTTPに特化しているため、gRPCを駆動したり、実際の負荷を生成したりすることはありません。複雑なフローは、スクリプト言語ではなく、より多くの.hurlファイルを意味します。

Step CI: 多段階フローのための単一YAMLファイル

Step CIは、単一のYAMLファイルで記述されたAPIワークフローを実行します。1つのワークフローでREST、GraphQL、gRPC、tRPC、SOAPをカバーし、OpenAPIスキーマに対して検証できます。npmからインストールし、同じファイルをローカルおよびCIで実行します。ログイン、トークンのキャプチャ、次の呼び出しでの使用、結果の確認など、テストが実際に一連のシーケンスである場合に読みやすくなります。

npm install -g stepci

# workflow.yml はステップ、キャプチャ、チェックを記述します
stepci run workflow.yml

最適な用途：マルチステップAPIフローを記述する宣言型ファイルを1つ持ち、ラップトップとパイプラインで同じように実行したいチーム。正直な制限：Nodeパッケージであるため、RustやGoのバイナリよりも重く、ランタイムを伴います。リリースサイクルが遅くなっているため、これに基づいてパイプラインを構築する前にリポジトリの最近のアクティビティを確認してください。これらの要素がより完全なテスト計画にどのように適合するかについては、APIテスト戦略をご覧ください。

k6: ターミナルからの軽量負荷テスト

k6は、「このレスポンスは正しいか」ではなく「負荷に耐えられるか」という異なる問いに答えます。Goで書かれており、単一の静的バイナリとして提供され、スクリプトはプレーンなJavaScriptです。リソース使用量を最小限に抑えるように設計されているため、ラップトップから実際のトラフィックをプッシュできます。しきい値により、負荷テストが合否判定のゲートになり、違反するとk6は終了コード99で終了し、パイプラインはこれを失敗と読み取ります。

brew install k6   # またはDocker経由で実行: docker run grafana/k6

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

最適な用途：クラスターを立ち上げずにCIでスクリプト化して実行したいパフォーマンスおよび負荷チェック。正直な制限：これは負荷ツールであり、機能テストクライアントではありません。単一のレスポンスを目で確認するためにこれを使用することはないでしょう。意味のあるシナリオを作成するには、そのJavaScript APIを学ぶ必要があります。

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

NewmanはPostmanコレクション用のコマンドラインランナーです。チームがすでにPostmanでリクエストやテストを構築している場合、NewmanはGUIなしでターミナルからそのコレクションを正確に実行します。これはCIで必要な機能です。コレクション（およびオプションで環境）をJSONとしてエクスポートし、Newmanに指定します。

npm install -g newman

# Postmanからエクスポートされた collection.json; -e は環境を渡します
newman run collection.json -e staging.json

最適な用途：既存のコレクションをパイプラインでヘッドレス実行したいPostmanに投資しているチーム。Newmanはテストが失敗するとゼロ以外の終了コードを返すため、CIをきれいにゲートします。正直な制限：Nodeパッケージであり、Postman形式のコレクションのみを実行するため、すでにそのエコシステムにいる場合に最も役立ちます。誰かがGUIで構築したテストを実行するものであり、オーサリングは依然としてGUIで行われます。

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

Apidog CLIは、Apidogの軽量な部分です。apidog-cliというnpmパッケージで、Apidogで視覚的に設計したテストシナリオをターミナルから直接実行します。テスト構築部分はGUIに残され、リクエストの連結、変数の抽出、アサーションの記述が迅速に行えます。CLIは、これらのシナリオの1つをヘッドレスで実行し、終了コードを返す小さな部分です。Apidogはオープンソースではありませんが、無料ティアとこのCLIを組み合わせることで、個別のクライアント、ランナー、ロードツールを組み合わせる統合された代替手段を提供します。

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# シナリオのCI/CDタブから正確なコマンドをコピーします
apidog run -t <scenario_id> -e <env_id> -r cli

シナリオIDや環境IDを推測する必要はありません。Apidogでテストシナリオを開き、CI/CDタブに移動して、IDがすでに記入されたapidog runコマンドをコピーしてください。-r cliレポーターは、ターミナルにステップバイステップの結果と概要を出力します。CIダッシュボードで結果を解析する必要がある場合は、-r cli,junitを追加してください。上記のツールと同様に、apidog runはすべてのアサーションが成功すると0で終了し、何らかの失敗があるとゼロ以外で終了するため、パイプラインはこれをクリーンなゲートとして扱います。その出力はagentHints.nextStepsを含む構造化されたJSONであり、AIコーディングエージェントが実行して読み取るのも容易にします。

最適な用途：複雑な多段階シナリオをビジュアルエディタで作成し、CIやエージェントからヘッドレスで実行したいチーム。正直な制限：curlやxhとは異なり、Apidogプロジェクトに保持するシナリオに結びついています。そのため、これは統合プラットフォームのオプションであり、単なるHTTPクライアントではありません。完全なコマンドセットについては、Apidog CLI完全ガイド、apidog runコマンドリファレンス、およびApidog CLIを使用してコマンドラインからREST APIをテストする方法のチュートリアルをご覧ください。

選び方

適切なツールは、「1つのリクエストを送信する」という点からどれだけ先に進む必要があるかによって異なります。

手動作業にはリストの上位から始めてください。エンドポイントを試すにはcurlやxhを使います。それらのチェックをバージョン管理で実行したい場合はHurlに移行します。負荷に関する問題になったらk6を導入し、テストがすでにPostmanにある場合はNewmanを使用します。エディタで複雑なシナリオを構築し、他のすべての場所でヘッドレスで実行したい場合はApidog CLIを選択してください。これらを完全にGUIなしのワークフローと比較検討している場合、ヘッドレスAPIテストツールガイドでは、まったくインターフェースなしでテストを実行する方法を解説しています。

軽量ツールの利点

軽量CLIツールは、GUIがあなたを遅くする日にこそ真価を発揮します。それは、ターミナルに深く没頭しているとき、人間を介さずにCIでテストを実行する必要があるとき、そしてますますAIエージェントがチェックを実行するときです。curlとxhは手動ループを迅速に保ちます。HurlとStep CIはアドホックなリクエストを再現可能なテストに変えます。k6は負荷の問題に答えます。NewmanはPostmanですでに構築したものを実行します。

Apidog CLIは、テストの構築と任意の場所での実行との間のギャップを埋めます。シナリオをApidogで一度設計すると、apidog runがターミナル、パイプライン、またはエージェントからそれを実行し、終了コードがビルドが成功するかどうかを決定します。Apidogをダウンロードし、1つのシナリオを構築して、そのapidog runコマンドをCI構成に含めることで、全体のループが完結する様子を確認できます。