2026年最新 ターミナルベースAPIテストツール おすすめ

APIテストはGUIから移行しました。現在、テストはディスプレイが接続されていないCIコンテナ、SSH経由でしかアクセスできないステージング環境、シェルしか扱わないAIエージェントの下で実行されます。これらすべての場所で、人間が監視することなくテストが合格または失敗する場所はターミナルです。

このまとめ記事では、シェルプロンプトから実際のテスト作業を実行するツールを評価しています。ここで言う「ターミナルベース」とは、パッケージマネージャーからのインストール、単一コマンドの実行、終了コードの読み取りといった一連のループ全体がシェル内で実行されることを意味します。このランキングでは、組み込みアサーション、複数ステップのフロー、CI対応レポート、およびメンテナンス状況を重視しています。curlのような手動クライアントも、すべてのターミナルワークフローがテスト実行の合間にそれらに依存するため、依然として最後に近い位置にランクインしています。GUIおよびホスト型ツールを含むより広範な調査については、「最高の無料APIテストツール」のまとめ記事をご覧ください。

テストツールとクライアントを分けるもの

ターミナルクライアントはリクエストを送信し、レスポンスを表示します。ターミナルテストツールはレスポンスを判断し、パイプラインがゲートとして使用できる終了コードとして結果を報告します。この2番目のグループがこのリストの中心であり、4つの特徴がそれを定義します。

• アサーションが組み込まれていること。 ステータス、ヘッダー、ボディのチェックは、jqのつなぎ合わせの山ではなく、ツール内に存在すること。
• 意味のある終了コード。 成功時はゼロ、失敗時は非ゼロなので、CIが自動的にビルドを失敗させる。
• 再現性。 テストはシェル履歴ではなく、バージョン管理され再実行可能なファイルまたはプロジェクトに存在する。
• レポート。 ターミナルで人間が読み取れ、ダッシュボードがJSON、JUnit、またはHTMLとして解析できる出力。

これらの基準を設定した上で、2026年に時間をかける価値のある10のツールを紹介します。

1. Apidog CLI: ビジュアルで作成し、どこでもヘッドレスで実行

Apidogは、設計、テスト、モック、ドキュメント作成を網羅するオールインワンのAPIプラットフォームです。Apidog CLI（npmではapidog-cli）はそのターミナル部門です。ビジュアルエディターで、リクエストの連鎖、変数抽出、アサーションを含むテストシナリオを構築し、apidog runであらゆるシェルからそれらを実行し、パイプラインにクリーンな終了コードを渡します。

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

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

IDを推測する必要はありません。Apidogでシナリオを開き、CI/CDタブに移動して、生成されたコマンドをコピーします。レポーターはcli、html、json、junitに対応しており、apidog-reports/に書き込まれるため、同じ実行結果がターミナル、ダッシュボード、アーティファクトストアに提供されます。データ駆動型実行では、CSVまたはJSONファイルからイテレーションをプルします。出力はagentHints.nextStepsを含む構造化されたJSONであり、これによりAIコーディングエージェントがスクリーン・スクレイピングなしでスイートを実行し、次の動きを決定できます。Node.js 16以降が必要です。

最適な用途: エディターで複雑な複数ステップのシナリオを作成し、ラップトップ、CI、エージェントで同じように実行したいチーム。正直な制限: オープンソースではなく、アドホックな送信ツールではありません。シナリオはApidogプロジェクト内に存在するため、これは純粋なHTTPツールではなく、統合プラットフォームのオプションです。「Apidog CLI完全ガイド」には、すべてのコマンドセットが記載されています。

2. Hurl: 1つのRustバイナリでプレーンテキストテスト

Hurlは、プレーンテキスト形式で記述されたHTTPリクエストを実行し、レスポンスに対してアサーションを行います。libcurlをベースにRustで構築されており、単一のバイナリとして提供されるため、ランタイムをインストールする必要がありません。テストはほとんど生のHTTPのように読めるため、プルリクエストでのレビューが容易です。

brew install hurl   # or: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

hurl --test login.hurl   # non-zero exit if an assertion fails

最適な用途: バージョン管理された読みやすいテキストとして保持する、契約スタイルのチェックやスモークテスト。--testフラグは、CIゲートとして自然に機能します。正直な制限: HTTPに特化しているため、gRPCを駆動したり負荷を生成したりすることはできません。複雑なロジックはスクリプト言語ではなく、より多くの.hurlファイルを意味します。

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

Newmanは、Postmanコレクション用のオープンソースコマンドラインランナー（Apache-2.0）です。チームがすでにPostmanでリクエストとテストを作成している場合、NewmanはGUIなしでターミナルからそのコレクションを正確に実行します。コレクションと環境をJSONとしてエクスポートし、Newmanにファイルを指定します。

npm install -g newman

newman run collection.json -e staging.json

最適な用途: Postmanに投資しており、追加のライセンスなしで既存のコレクションをパイプラインで実行したいチーム。テストが失敗すると非ゼロで終了するため、CIはきれいにゲートします。正直な制限: Postman形式のコレクションのみを実行し、オーサリングはPostman GUIで行われます。テストを実行しますが、テストの作成は支援しません。

4. Postman CLI: Newmanの公式代替ツール

Postman CLIは、Postman独自のクローズドソースランナーです。Newmanとは異なり、Postmanアカウントにサインインし、ワークスペースから直接IDでコレクションを実行でき、結果はPostmanのクラウドに報告されます。

postman login --with-api-key <YOUR_API_KEY>

postman collection run <collection_id> -e <environment_id>

最適な用途: JSONファイルをエクスポートせずにクラウドにリンクされた実行を希望するPostmanチーム。正直な制限: クローズドソースであり、Postmanアカウントに紐付いています。2つの公式ランナーがあるため、どちらを採用すべきかについて混乱が生じる可能性があります。Postman CLIとNewmanの比較記事では、それぞれがいつ意味をなすかを解き明かしています。

5. Bruno CLI: Gitネイティブコレクション、`bru`で実行

Brunoは、コレクションを通常のフォルダ内のプレーンテキスト.bruファイルとして保存するため、リクエストは他のコードと同様にリポジトリ内に存在します。そのCLI、@usebruno/cliは、クラウドアカウントなしでbruコマンドを使用してターミナルからこれらのコレクションを実行します。

npm install -g @usebruno/cli

# Run every request in the current collection folder
bru run --env staging

最適な用途: プルリクエストでレビューされ、アサーションとスクリプトが同じファイルで処理されるコレクションをオフラインで実行したいチーム。CI用にJSON、JUnit、HTMLレポートを出力します。正直な制限: プレーンテキストでのオーサリングは、多様なチームよりも開発者向きであり、エコシステムはPostmanよりも新興です。Bruno CLIとApidog CLIの比較で、Apidogのランナーとどのように比較されるかを確認してください。

6. Schemathesis: スキーマがテストを作成する

Schemathesisは異なるアプローチを取ります。OpenAPIまたはGraphQLスキーマを読み込み、PythonのHypothesisに基づいたプロパティベーステストを使用して、そこから何千ものテストケースを生成します。各ケースを記述する代わりに、入力をファズして、500エラー、スキーマ違反、ドキュメントが約束する契約を破るレスポンスを見つけさせます。

pip install schemathesis

schemathesis run https://api.example.com/openapi.json

最適な用途: リリース前など、誰もテストを書くことを考えなかったエッジケースのバグを発見すること。正確なスキーマを維持するための最も強力な理由の一つです。正直な制限: 動作するには実際のスキーマが必要であり、大規模なAPIではフックやオプションでフィルタリングする必要があるノイズが発生する可能性があります。

7. Step CI: マルチステップフローごとに1つのYAMLファイル

Step CIは、APIワークフローを単一のYAMLファイルで記述します。ステップ、キャプチャされた値、チェックが含まれます。REST、GraphQL、gRPC、tRPC、SOAPを1つのワークフローでカバーし、OpenAPIスキーマに対して検証します。同じファイルがラップトップとパイプラインで実行されます。

npm install -g stepci

stepci run workflow.yml

最適な用途: スクリプトなしで宣言的に記述された、ログイン後にトークンを使用するシーケンス。正直な制限: Nodeランタイムを必要とし、リリース頻度が遅くなっているため、これに基づいてパイプラインを構築する前にリポジトリの最近のアクティビティを確認してください。

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

curlはmacOS、ほとんどのLinuxディストリビューション、および現在のWindowsに付属しているため、最も軽いインストールは「インストール不要」です。他のすべてのツールが自身を比較する基準となるクライアントであり、-wとシェルスクリプトを組み合わせることで、最小限のテストハーネスとして機能します。

# POST JSON and print only the HTTP status
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"sku":"A-102","qty":2}'

最適な用途: 一回限りのリクエスト、スクリプト、および新しいものをインストールできないロックダウンされた環境。正直な制限: アサーションは完全にDIYです。jqにパイプして値を自分で比較し、終了コードを手動で管理します。送信して表示するだけで、テストは行いません。それが十分でなくなったときに何を選ぶべきかについては、「REST APIテストのためのcurl代替ツール」ガイドがカバーしています。

9. HTTPieとxh: 人間が読みやすい手動リクエスト

HTTPieはターミナルリクエストを読みやすくしました。コマンドはhttp、JSONフィールドはkey=valueペアで、レスポンスは色付けされ整形されて返されます。xhは、同じ構文をRustで単一の静的バイナリとして再実装しており、起動が高速で、同等のcurlコマンドを出力する--curlフラグを備えています。

http POST api.example.com/users name=acme plan=pro   # HTTPie
xh   POST api.example.com/users name=acme plan=pro   # same syntax, one binary

最適な用途: 他の場所で実際のテストを構築しながら、APIを手動で探索すること。正直な制限: どちらもクライアントであり、ランナーではありません。HTTPieはPythonランタイムを必要とし、xhはより少ない機能セットと引き換えに速度を提供します。どちらもレスポンスに対するアサーションは行いません。

10. k6: 負荷が問題となる場合

k6は、「このレスポンスは正しいか」ではなく「トラフィック下で耐えられるか」という異なる問いに答えます。Grafana製の単一のGoバイナリであり、JavaScriptでスクリプトが記述され、負荷テストを合格/不合格ゲートに変える閾値が設定されています。閾値を超えるとk6は非ゼロで終了し、CIはそれを失敗として認識します。

brew install k6

k6 run load.js   # vus, duration, and thresholds defined in the script

最適な用途: 機能テストと同じリポジトリに存在し、ラップトップまたはパイプラインから実行されるパフォーマンスチェック。正直な制限: AGPL-3.0下のロードツールであり、機能テストクライアントではありません。意味のあるシナリオを作成するには、そのJavaScript APIを学ぶ必要があります。

インタラクティブなものが好みですか？

シェルを離れることなくPostmanのようなインターフェースを望むなら、それは別のカテゴリです。atacやpostingのようなTUIクライアントは、ターミナル内で完全なリクエストエディタを描画します。これらはAPIを探索しますが、パイプラインをゲートしません。「最高のターミナルおよびTUI REST APIクライアント」のまとめ記事では、その側面を詳しくカバーしています。

比較表

選び方

ツールからではなく、目的から始めましょう。Postmanにすでにテストが存在する場合、NewmanまたはPostman CLIはすぐにそれらを実行できます。リポジトリでレビュー可能なテキストとしてテストを管理したい場合、HurlとBruno CLIが最も有力な選択肢です。堅固なOpenAPIスキーマがあるなら、Schemathesisを追加して、予測できなかったバグを検出させましょう。手動レイヤーにはcurlとxhを保持し、正確性から容量へと問題が変わる日にはk6を導入します。

ビジュアルエディターでシナリオを作成し、他の場所で実行したい場合は、Apidog CLIを選択してください。これは、同じプロジェクトでAPI設計、モックデータ、ドキュメントも管理できる唯一の選択肢であり、その利点は「Apidog CLI: ターミナルで動作するAPIクライアント」で説明されています。これらの選択肢の背後にあるより広範なテストの全体像については、「APIテスト戦略」ガイドで各レイヤーがどのように適合するかを示しています。

よくある質問

APIを完全にターミナルからテストできますか？ はい、できます。テストをファイル（Hurl、Bruno、Step CI）として作成するか、ビジュアルエディター（Apidog、Postman）で作成し、対応するCLIでヘッドレスで実行します。このリストのすべてのランナーは終了コードを返すため、CIが必要とするのはそれだけです。

ターミナルAPIクライアントとテストツールの違いは何ですか？ クライアント（curl、HTTPie、xh）はリクエストを送信し、レスポンスを表示します。テストツール（Apidog CLI、Hurl、Newman）はレスポンスに対してアサーションを行い、非ゼロの終了コードで失敗を報告します。クライアントは探索し、テストツールはゲートとして機能します。

これらのうち、どれがCIパイプラインで実行されますか？ すべてのランナーが該当します。apidog run、hurl --test、newman run、postman collection run、bru run、schemathesis run、stepci run、そしてk6 runはすべて、失敗時に非ゼロで終了します。動作するパイプラインの例については、「GitHub ActionsでApidog CLIテストを実行する方法」を参照してください。

これらの中で負荷テストを処理できるものはありますか？ ここでの負荷テストの専門家はk6で、合格/不合格のゲートとして閾値を使用します。他のツールは正確性をチェックし、容量をチェックしないため、多くのチームは機能的なランナーの1つとk6を組み合わせて使用します。

これらのツールを使用するにはOpenAPI仕様が必要ですか？ Schemathesisのみが必要とします。これはスキーマからテストを生成するためです。他のすべてのツールでは、仕様はゲートではなく補助的な役割を果たします。ApidogはOpenAPI 3.x、Swagger 2.0、およびPostmanコレクションをインポートでき、Step CIはスキーマに対してレスポンスを検証できます。

これら10のツールすべてに共通するパターンは同じです。作成には快適さが求められ、実行にはシェルが求められます。テストを作成する場所を選択し、その後、ランナーがパイプラインに終了コードを渡すことを確認してください。両方を1つのプラットフォームで実現したい場合は、Apidogをダウンロードし、エディターで1つのシナリオを構築し、そのapidog runコマンドをCIに組み込んでループを閉じます。