APIテスト用無料オープンソースCLIツール

ほとんどのAPIテストチュートリアルはGUIを推奨していますが、ターミナルを使い、CIでテストを実行し、またはソースコードを読めるツールを求めるなら、APIテストはコマンドラインでこそ面白くなります。オープンソースのCLIツールは、ホスト型製品では得られないものを提供します。それは、監査可能なライセンス、セルフホスト可能なバイナリ、そしてコードと一緒にコミットできる設定ファイルです。

これは「最速のツールは何か」や「最小のバイナリは何か」といった問いとは異なります。ここでの焦点はライセンスと制御です。アカウントなしで、自社ネットワーク内で実行できますか？ソースコードは、OSI承認の正式なライセンスの下、GitHubで公開されていますか？ベンダーが次四半期に価格を変更しても、問題なく動作し続けますか？これらが、このリストが答える質問です。

以下に、REST、GraphQL、HTTP APIをテストするための8つの無料かつソースコードが利用可能なCLIツールを紹介します。それぞれに正確なライセンス、実際のインストールコマンド、および動作を示すコマンドが記載されています。ホスト型ツールを含むより広範な調査が必要な場合は、ベストフリーAPIテストツールまとめをご覧ください。エンドポイントを手動で操作する純粋なターミナルファーストのアプローチについては、REST APIテストのcurl代替ガイドがインタラクティブな側面を解説しています。

button

APIテストにおけるCLIツールの「オープンソース」とは何か

多くのツールは無料でダウンロードできます。しかし、それはオープンソースとは異なります。このリストにおけるツールは、以下の3つの点で条件を満たします。

正式なライセンス。ソースコードはOSI承認のライセンス（MIT、Apache-2.0、MPL-2.0、AGPL-3.0、BSD）の下で公開されています。ソースコードを読み、フォークし、どのような利用が許可されているかを把握できます。
セルフホスト可能、アカウント不要。何も登録することなく、自身のマシンやCIランナーで完全に実行できます。シートコストやベンダーへの接続要求はありません。
メンテナンスされており、検証可能。リポジトリはGitHub上にあり、コミット履歴やイシューが公開されているため、それに基づいてパイプラインを構築する前に、そのプロジェクトが活発であるかどうかを判断できます。

以下に挙げるすべてのツールは、最初の2つの条件を満たしています。3番目の条件を満たさなくなったツールにはフラグを付けています。ライセンスの選択は見た目以上に重要です。AGPL-3.0 (k6) は、それを用いてサービスを構築する場合、コピーレフトの義務が発生しますが、MITやApache-2.0はより寛容です。製品にツールを組み込む前に、ライセンスを確認してください。

Hurl: プレーンテキストHTTPテスト、単一のRustバイナリ

Hurlは、プレーンテキスト形式で記述されたHTTPリクエストを実行し、そのレスポンスを検証します。これはOrange-OpenSourceによってRustで開発され、内部ではlibcurlが利用されており、単一のバイナリとして配布されます。テストはリクエストそのもののように読めるため、プルリクエストでのレビューが容易です。

ライセンス： Apache-2.0。ソース： github.com/Orange-OpenSource/hurl。

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

# login.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

最適な用途：バージョン管理下に、読みやすいテキストとして保持したい契約スタイルのチェックやスモークテスト。正直な限界：HTTPに特化しているため、gRPCのテストや負荷生成には対応していません。単純なアサーションチェーンを超えるテストでは、スクリプト言語に頼るよりも、より多くの`.hurl`ファイルを記述することになるでしょう。

Step CI: CI向けに構築されたYAML APIワークフロー

Step CIは、継続的インテグレーション向けに設計されたYAML設定のワークフローランナーです。単一のワークフローファイルでREST、GraphQL、gRPC、tRPC、SOAPに対応し、OpenAPIスキーマに対する負荷テストやバリデーションを実行できます。ランナーとCLIは永続的に無料です。

ライセンス： MPL-2.0。ソース： github.com/stepci/stepci。

npm install -g stepci

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

最適な用途：マルチステップAPIフローを記述し、ローカル環境でもCI環境でも同じように実行できる単一の宣言型ファイルを求めるチーム。正直な限界：MPL-2.0は「弱いコピーレフト」であるため、Step CI自身のファイルを変更した場合、それらの変更を公開する必要があります。アプリケーションのテストにこれを使用する限り、そのような義務は発生しません。

Schemathesis: スキーマからのプロパティベーステスト

Schemathesisは、OpenAPIまたはGraphQLスキーマを読み込み、PythonのHypothesisライブラリに基づいたプロパティベースのテストを利用して、数千ものテストケースを生成します。各テストケースを自分で記述する代わりに、入力に対してファジングを行い、500エラー、スキーマ違反、そしてドキュメントの記述と一致しないレスポンスを発見します。

ライセンス： MIT。ソース： github.com/schemathesis/schemathesis。

uv pip install schemathesis   # または: pip install schemathesis

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

最適な用途：特にリリース前に、テストを書くことすら思いつかないようなエッジケースのバグを捕捉すること。正確なスキーマを維持する強力な理由の一つとなります。正直な限界：動作には実際のスキーマが必要であり、大規模なAPIでは、フックやオプションでフィルタリングが必要となる多くのノイズを生成する可能性があります。

Dredd: API記述に対する契約テスト

Dreddは、稼働中のAPIがその記述ドキュメントと実際に一致していることをチェックします。OpenAPI（またはAPI Blueprint）ファイルと稼働中のバックエンドを対象とし、ドキュメントに記載されたすべてのリクエストをリプレイし、実際のレスポンスを仕様と比較します。言語に依存せず、セットアップとティアダウンのためのフックをサポートしています。

ライセンス： MIT。ソース： github.com/apiaryio/dredd。

npm install -g dredd

dredd apiary.apib http://127.0.0.1:3000

最適な用途：ドキュメントと実装が乖離していないことを証明する。正直な限界（これは実情です）：Dreddのリポジトリは2024年11月にアーカイブされ、読み取り専用となっています。まだ動作しますが、現在はメンテナンスされていないため、将来の修正がない安定したツールとして扱うべきです。活発にメンテナンスされているスキーマ駆動型のチェッカーが必要な場合は、Schemathesisの方が安全な選択肢です。

k6: JavaScriptでスクリプト化された負荷テスト

k6はGrafana製の負荷およびパフォーマンステストツールです。JavaScriptまたはTypeScriptでテストをスクリプト化し、高速なGoエンジンが大規模な負荷をかけます。単一のリクエストが成功するかどうかだけでなく、数百または数千の仮想ユーザーの下でAPIがどのように動作するかを知る必要がある場合に、頼りになるオープンソースの選択肢です。

ライセンス： AGPL-3.0。ソース： github.com/grafana/k6。

brew install k6

k6 new script.js   # スターターテストを生成
k6 run script.js

最適な用途：機能テストと同じリポジトリ内で管理する、パフォーマンスおよびソークテスト。正直な限界：AGPL-3.0は強いコピーレフトです。テストを実行する分には問題ありませんが、k6のコードを利用してサービスを構築・配布する場合は、ライセンスに実際の義務が発生しますので、まずご確認ください。k6は負荷に焦点を当てており、きめ細かな契約アサーションには対応していません。

Newman: GUIなしでPostmanコレクションを実行

NewmanはPostman公式のコマンドラインコレクションランナーです。チームが既にPostmanコレクションとしてAPIリクエストとテストを保存している場合、Newmanはデスクトップアプリなしで、ターミナルまたはCIでそのコレクションを正確に実行します。Postmanのワークフローをパイプラインに組み込むための標準的な方法です。

ライセンス： Apache-2.0。ソース： github.com/postmanlabs/newman。

npm install -g newman

newman run my-collection.json -e staging-environment.json

最適な用途：既存のPostmanコレクションを持つチームが、追加のPostmanシート費用なしでCI実行をしたい場合。正直な限界：Postmanコレクション形式に依存するため、テストの作成はPostmanのUI（またはそのJSON形式）で行い、プレーンな設定ファイルでは行いません。コレクションを実行するものであり、APIの設計やモック機能はありません。

Tavern: pytestプラグインとしてのAPIテスト

Tavernは、APIテストをYAMLで記述するPythonライブラリ、CLI、そしてpytestプラグインです。pytestにプラグインとして組み込まれるため、フィクスチャ、レポート、並列処理、そして既に利用しているCI連携など、pytestのエコシステム全体を無料で利用できます。REST、MQTT、gRPCに対応しています。

ライセンス： MIT。ソース： https://github.com/taverntesting/tavern。

pip install tavern

# test_login.tavern.yamlは他のテストの隣に置かれます
pytest test_login.tavern.yaml

最適な用途：既にpytestを利用しており、APIテストをユニットテストの隣に配置したいPython開発チーム。正直な限界：Pythonのテスト環境に慣れていることを前提としています。使用している技術スタックがPythonではない場合、pytestへの依存は機能というよりはむしろ障壁となります。

Venom: OVHcloudによるマルチエグゼキューター統合テスト

OVHcloudのVenomは、HTTPリクエスト、シェルスクリプト、IMAP、Web、データベースなど、多様なエグゼキュータタイプを横断して統合テストを実行します。Go言語で書かれており、YAMLテストスイートを使用し、CIシステムがネイティブに読み取れるxUnit結果ファイルを出力します。単一のテストがHTTPエンドポイントだけでなく、複数の要素にまたがる必要がある場合にその真価を発揮します。

ライセンス： BSD（修正版）。ソース： https://github.com/ovh/venom。

# GitHubリリースからバイナリをダウンロード後、以下を実行:
venom run testsuite.yml

最適な用途：API呼び出し、データベースチェック、スクリプトステップを1つのテストスイートに組み合わせるエンドツーエンドのフロー。正直な限界：非常に多くのエグゼキュータがあるため、YAMLが冗長になりがちで、ドキュメントはリポジトリの例を自分で組み合わせて使用することを前提としています。

Apidogの立ち位置（そして正直な見解）

ここが正直な話です。Apidogはオープンソースではありません。無料プランのある商用製品であるため、ソースコードが利用可能なツールのリストには該当しません。しかし、一つの理由から知っておく価値があります。それは、上記のツールはそれぞれが単一の機能に特化しており、Hurl、Schemathesis、Newman、さらにモックサーバーを組み合わせて一貫したワークフローを構築するには、自分でメンテナンスしなければならない手間がかかるからです。

Apidogは設計、テスト、モック、ドキュメントを一つのプラットフォームに統合し、apidog-cliによってターミナルからもテストを実行できます。テストシナリオを一度作成すれば、単一のコマンドでCIで実行できます。

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN>   # 全て成功で終了コード0、失敗で非0

出力は`agentHints.nextSteps`を含む構造化されたJSONであり、スクリプト作成やAIエージェントへの連携が容易です。完全な`apidog-cli`ガイドでは、全コマンドセットを詳しく解説しています。つまり、オープンソースではありませんが、無料プランとCLIを組み合わせることで、複数の単機能ツールを連携させる代わりに、統合された代替手段が得られます。監査可能なライセンスが必須要件である場合は、上記8つのツールから選択してください。統合されたワークフローがより重要であれば、これが選択肢となるでしょう。

選び方

ツール	最適な用途	インストール	オープンソース？	ライセンス
Hurl	GitでのプレーンテキストHTTPアサーション	`brew install hurl`	はい	Apache-2.0
Step CI	宣言型CIワークフロー	`npm i -g stepci`	はい	MPL-2.0
Schemathesis	スキーマからのプロパティベースのファジング	`pip install schemathesis`	はい	MIT
Dredd	ドキュメントと実装の契約テスト	`npm i -g dredd`	はい（アーカイブ済み）	MIT
k6	負荷およびパフォーマンステスト	`brew install k6`	はい	AGPL-3.0
Newman	CIでのPostmanコレクション実行	`npm i -g newman`	はい	Apache-2.0
Tavern	pytest内のAPIテスト	`pip install tavern`	はい	MIT
Venom	マルチエグゼキュータ統合スイート	GitHubリリース	はい	BSD
apidog-cli	統合された設計からテストまでのワークフロー	`npm i -g apidog-cli`	いいえ（無料プランあり）	商用

ツールをタスクに合わせて選択しましょう。高速で読みやすいリクエストチェックが必要な場合はHurlまたはNewman、スキーマがありバグを自動的に見つけてほしい場合はSchemathesis、規模が問われる場合はk6、テストをより大きなスイートに含める必要がある場合はTavernまたはVenomを選びましょう。これらのツールをより大規模なプロセスと比較検討している場合、APIテスト戦略ガイドは各タイプがどこに適合するかを解説し、ヘッドレスAPIテストツールに関する記事は、UIを一切使わずにテストを実行する方法を考察しています。

まとめ

オープンソースのCLIツールは、自分でソースコードを読み、フォークし、自身の条件で実行できるAPIテスト環境を提供します。HurlとNewmanは日常的なリクエストチェックをこなし、SchemathesisとDreddはAPIの契約を強制し、k6はパフォーマンスを検証し、TavernとVenomはAPIテストをより広範なテストスイートに統合します。ライセンスと必要なタスクに基づいて選択してください。複数のツールを併用しても問題ありません。

ツールチェーンのメンテナンスではなく、設計、テスト、モック、ドキュメント作成を一つの場所で行いたい場合は、Apidogがそのライフサイクル全体をカバーし、CI向けのapidog-cliも提供しています。Apidogをダウンロードして、上記のツールとCLIを試用し、どの組み合わせがあなたのパイプラインに最適かを確認してください。