DEV Community

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

Posted on Originally published at apidog.com

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

APIテストはGUIだけで完結しません。現在は、ディスプレイのないCIコンテナ、SSH経由でしか触れないステージング環境、シェルだけを扱うAIエージェントなどでテストを実行します。人間が見守らなくても合格・失敗を判定し、終了コードを返せる場所はターミナルです。

Apidogを今すぐ試す

この記事では、シェルから実際にAPIテストを実行できるツールを比較します。ここでいう「ターミナルベース」とは、パッケージマネージャーでインストールし、単一コマンドで実行し、終了コードをCIで判定する一連のループがシェル内で完結することです。

評価では、次のポイントを重視します。

  • 組み込みアサーション
  • 複数ステップのフロー
  • CI向けレポート
  • メンテナンス状況

curlのような手動クライアントも、テスト実行の合間に使うため候補に含めます。GUIやホスト型ツールも含めた比較は、最高の無料APIテストツールを参照してください。

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

ターミナルクライアントはリクエストを送信し、レスポンスを表示します。一方、ターミナルテストツールはレスポンスを判定し、その結果をCIのゲートとして使える終了コードで返します。

テストツールとして使うなら、次の4点を確認してください。

  • アサーションが組み込まれていること

    ステータス、ヘッダー、ボディの検証を、jqを大量に組み合わせずに記述できること。

  • 意味のある終了コードを返すこと

    成功時は0、失敗時は非ゼロを返し、CIが自動でジョブを失敗扱いにできること。

  • 再現できること

    シェル履歴ではなく、Git管理できるファイルやプロジェクトとしてテストを保存できること。

  • レポートを出力できること

    人間向けのCLI出力に加え、JSON、JUnit、HTMLなどをCIやダッシュボードで利用できること。

この基準で、2026年に検討する価値がある10個のツールを紹介します。

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

Apidogは、API設計、テスト、モック、ドキュメント作成をまとめて扱うAPIプラットフォームです。apidog-cliはそのCLIで、ビジュアルエディターで作成したシナリオをターミナルやCIから実行できます。

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
Enter fullscreen mode Exit fullscreen mode

実装手順は次のとおりです。

  1. Apidogでテストシナリオを作成する。
  2. リクエスト間の値の受け渡し、変数抽出、アサーションを設定する。
  3. シナリオ画面のCI/CDタブを開く。
  4. 生成されたコマンドをCI設定に貼り付ける。

レポーターはcli、html、json、junitに対応し、結果はapidog-reports/に出力されます。CSVまたはJSONを使ったデータ駆動型実行にも対応しています。

出力にはagentHints.nextStepsを含む構造化JSONがあり、AIコーディングエージェントでもスクリーンスクレイピングなしに結果を処理できます。Node.js 16以降が必要です。

最適な用途: ビジュアルエディターで複雑な複数ステップシナリオを作り、ローカル、CI、エージェントで同じように実行したいチーム。

制限: オープンソースではなく、アドホックなHTTP送信専用ツールでもありません。シナリオはApidogプロジェクト内で管理されます。コマンドの詳細はApidog CLI完全ガイドを参照してください。

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

Hurlは、プレーンテキストでHTTPリクエストとアサーションを記述するテストツールです。libcurlをベースにRustで実装され、単一バイナリとして利用できます。

brew install hurl
# または: 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
Enter fullscreen mode Exit fullscreen mode

hurl --testはアサーション失敗時に非ゼロで終了するため、そのままCIジョブに組み込めます。

最適な用途: Gitで管理し、プルリクエストでレビューしやすい契約テストやスモークテスト。

制限: HTTP特化です。gRPCの実行や負荷生成には向きません。複雑なロジックはスクリプトではなく、複数の.hurlファイルで構成します。

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

Newmanは、PostmanコレクションをCLIから実行するオープンソースのランナーです。ライセンスはApache-2.0です。

すでにPostmanでコレクションとテストを作っている場合、JSONとしてエクスポートしてNewmanで実行できます。

npm install -g newman

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

実装時は、コレクションJSONと環境JSONをリポジトリまたはCIの安全なストレージで管理します。テスト失敗時は非ゼロ終了になるため、CIのゲートとして利用できます。

最適な用途: Postman資産を追加ライセンスなしでパイプラインに組み込みたいチーム。

制限: Postman形式のコレクションを実行するためのツールです。テストの作成自体はPostman GUI側で行います。

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

Postman CLIは、Postmanが提供するクローズドソースのCLIランナーです。Postmanアカウントにログインし、ワークスペース上のコレクションをID指定で実行できます。結果はPostmanクラウドに連携されます。

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

postman collection run <collection_id> -e <environment_id>
Enter fullscreen mode Exit fullscreen mode

最適な用途: JSONファイルをエクスポートせず、Postmanクラウドと連携した実行結果を使いたいチーム。

制限: クローズドソースであり、Postmanアカウントに紐付きます。NewmanとPostman CLIの使い分けは、Postman CLIとNewmanの比較を参照してください。

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

Brunoは、コレクションをフォルダ内のプレーンテキスト.bruファイルとして保存します。リクエスト、アサーション、スクリプトをアプリケーションコードと同じリポジトリで管理できます。

npm install -g @usebruno/cli

# 現在のコレクションフォルダ内のリクエストを実行
bru run --env staging
Enter fullscreen mode Exit fullscreen mode

CIではJSON、JUnit、HTMLレポートを出力できます。テスト定義をGitでレビューする運用に向いています。

最適な用途: クラウドアカウントなしで、Git管理されたコレクションをオフライン実行したいチーム。

制限: プレーンテキストでの作成は開発者向けです。エコシステムはPostmanより新しいため、導入前に必要な連携機能を確認してください。Bruno CLIとApidog CLIの比較も参考になります。

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

Schemathesisは、OpenAPIまたはGraphQLスキーマからテストケースを生成するツールです。PythonのHypothesisを利用したプロパティベーステストで、想定外の入力、500エラー、スキーマ違反、契約違反を検出します。

pip install schemathesis

schemathesis run https://api.example.com/openapi.json
Enter fullscreen mode Exit fullscreen mode

手作業でケースを列挙する代わりに、正確なAPIスキーマを入力として、境界値や異常系を広く探索させます。

最適な用途: リリース前に、手動テストでは見落としやすいエッジケースを見つけたい場合。

制限: 実用には正確なOpenAPIまたはGraphQLスキーマが必要です。大規模APIではノイズが多くなることがあるため、フックやオプションで対象を絞り込む必要があります。

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

Step CIは、APIワークフローを単一のYAMLファイルで記述します。ステップ、値のキャプチャ、チェックを定義し、REST、GraphQL、gRPC、tRPC、SOAPを扱えます。

npm install -g stepci

stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

ログイン後にトークンを取得し、そのトークンで次のAPIを呼び出すようなフローを、スクリプトなしで宣言的に表現できます。

最適な用途: 認証や値の引き継ぎを含む複数ステップのAPIフロー。

制限: Node.jsランタイムが必要です。リポジトリの最近のアクティビティを確認してから、長期運用するパイプラインに採用してください。

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

curlは、macOS、多くのLinuxディストリビューション、現在のWindowsに含まれています。追加インストールなしで使えるため、ロックダウン環境や単発調査では特に有用です。

# JSONをPOSTし、HTTPステータスだけを表示する
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}'
Enter fullscreen mode Exit fullscreen mode

簡易的なCIチェックにするなら、ステータスコードを判定して明示的に終了コードを返します。

status=$(curl -s -o /dev/null -w "%{http_code}" \
  https://api.example.com/health)

test "$status" = "200"
Enter fullscreen mode Exit fullscreen mode

最適な用途: 単発リクエスト、シェルスクリプト、新規ツールを導入できない環境。

制限: アサーションは完全にDIYです。JSONの検証にはjqなどを組み合わせ、比較と終了コードの管理を自分で実装します。テストランナーが必要になった場合は、REST APIテストのためのcurl代替ツールを確認してください。

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

HTTPieは、読みやすい構文と整形済みレスポンスを提供するターミナルHTTPクライアントです。xhは同様の構文をRustの単一静的バイナリとして実装しています。

http POST api.example.com/users name=acme plan=pro
xh   POST api.example.com/users name=acme plan=pro
Enter fullscreen mode Exit fullscreen mode

xhには、実行内容に対応するcurlコマンドを出力する--curlフラグもあります。

最適な用途: 実際のテストを別のランナーで管理しつつ、APIを手動で探索・デバッグする作業。

制限: どちらもテストランナーではなく、レスポンスに対するアサーションは行いません。HTTPieはPythonランタイムを必要とし、xhは機能セットを絞る代わりに高速な起動を提供します。

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

k6は、レスポンスが正しいかではなく、トラフィック下でAPIが耐えられるかを確認するための負荷テストツールです。Grafana製のGoバイナリで、JavaScriptでシナリオを記述します。

brew install k6

k6 run load.js
Enter fullscreen mode Exit fullscreen mode

スクリプト内で仮想ユーザー数、実行時間、閾値を定義します。閾値を超えるとk6は非ゼロで終了するため、CIで性能劣化を検出できます。

最適な用途: 機能テストと同じリポジトリで管理し、ローカルやCIから実行するパフォーマンスチェック。

制限: AGPL-3.0の負荷テストツールであり、機能テスト専用クライアントではありません。意味のあるシナリオを作るにはJavaScript APIを学ぶ必要があります。

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

シェルを離れずにPostmanのような操作感を使いたい場合は、TUIクライアントという別カテゴリがあります。atacやpostingのようなツールは、ターミナル内でリクエストエディターを表示します。

これらはAPI探索には便利ですが、通常はパイプラインをゲートするテストランナーではありません。詳しくは最高のターミナルおよびTUI REST APIクライアントを参照してください。

比較表

ツール 用途 組み込みアサーション インストール オープンソース
Apidog CLI CIで視覚的に作成されたシナリオを実行 はい npm i -g apidog-cli いいえ（無料プランあり）
Hurl プレーンテキストHTTPテスト はい brew install hurl Apache-2.0
Newman Postmanコレクションをヘッドレスで実行 はい npm i -g newman Apache-2.0
Postman CLI クラウド連携Postman実行 はい Postmanインストーラー いいえ
Bruno CLI Gitネイティブな.bruコレクション はい npm i -g @usebruno/cli MIT
Schemathesis スキーマからのファジング 生成される pip install schemathesis MIT
Step CI マルチステップYAMLフロー はい npm i -g stepci MPL-2.0
curl 生のリクエスト、スクリプト作成 DIY プレインストール済み はい
HTTPie / xh 読みやすい手動リクエスト いいえ brew install httpie / xh はい
k6 合格・不合格閾値による負荷テスト 閾値による brew install k6 AGPL-3.0

選び方

ツール名から選ぶのではなく、現在のテスト資産と目的から選びます。

  • Postmanのコレクションがすでにある: NewmanまたはPostman CLI
  • Gitでレビューできるテキスト形式にしたい: HurlまたはBruno CLI
  • OpenAPIスキーマが整備されている: Schemathesisを追加
  • 認証付きの複数ステップフローをYAMLで書きたい: Step CI
  • 単発調査や制限環境で使いたい: curl、HTTPie、xh
  • 性能・容量を検証したい: k6
  • ビジュアルで作成し、CIやエージェントで実行したい: Apidog CLI

Apidog CLIを使う場合は、まずエディターで1つのシナリオを作成し、CI/CDタブで生成されるapidog runコマンドをパイプラインに追加するのが最短です。設計、モック、ドキュメントも同じプロジェクトで管理したい場合は、Apidog CLI: ターミナルで動作するAPIクライアントを参照してください。

テスト全体のレイヤー設計については、APIテスト戦略も役立ちます。

よくある質問

APIを完全にターミナルからテストできますか？

はい。Hurl、Bruno、Step CIのようにテストをファイルとして記述する方法と、ApidogやPostmanのようにビジュアルエディターで作成してCLIでヘッドレス実行する方法があります。

重要なのは、ランナーが失敗時に非ゼロの終了コードを返すことです。CIはその終了コードを使ってジョブを失敗にできます。

ターミナルAPIクライアントとテストツールの違いは何ですか？

curl、HTTPie、xhのようなクライアントは、リクエストを送ってレスポンスを表示します。

Apidog CLI、Hurl、Newmanのようなテストツールは、レスポンスに対してアサーションを実行し、失敗を非ゼロ終了コードで返します。クライアントは探索用、テストツールはCIゲート用です。

どのツールがCIパイプラインで実行できますか？

テストランナーとして挙げたツールはすべてCIに組み込めます。

apidog run
hurl --test
newman run
postman collection run
bru run
schemathesis run
stepci run
k6 run
Enter fullscreen mode Exit fullscreen mode

いずれも失敗時に非ゼロで終了します。GitHub Actionsへの組み込み例は、GitHub ActionsでApidog CLIテストを実行する方法を参照してください。

負荷テストを処理できるツールはありますか？

負荷テスト向けはk6です。閾値を設定し、性能条件を満たせない場合にCIを失敗させられます。

他のツールは主に機能的な正しさを検証します。そのため、多くのチームは機能テストランナーとk6を組み合わせます。

OpenAPI仕様は必須ですか？

必須なのはSchemathesisです。スキーマからテストケースを生成するため、OpenAPIまたはGraphQLスキーマが必要です。

その他のツールでは、仕様は必須ではありません。ただし、ApidogはOpenAPI 3.x、Swagger 2.0、Postmanコレクションをインポートでき、Step CIはスキーマに対するレスポンス検証を行えます。

まとめ

ターミナルAPIテストでは、作成しやすさと実行しやすさを分けて考えると選びやすくなります。

  1. テストをどこで作成・管理するかを決める。
  2. CIから単一コマンドで実行できるようにする。
  3. 失敗時に非ゼロ終了コードを返すことを確認する。
  4. JSON、JUnit、HTMLなどのレポートをCIアーティファクトに保存する。

ビジュアル作成とヘッドレス実行を同じプラットフォームで行いたい場合は、Apidogをダウンロードし、シナリオを1つ作成して、そのapidog runコマンドをCIに追加してください。

Top comments (0)