Hoppscotch CLIは、APIコレクションをターミナルから実行するための、無料のオープンソースツールです。Hoppscotchをウェブ版やデスクトップ版で既にお使いの場合、hopp testを使えば、それらのリクエストをCIパイプラインに無料で組み込むことができます。これは大きな強みであり、この記事ではその点を否定しません。
しかし、Hoppscotch CLIは意図的にその範囲を限定しています。コレクションを実行し、結果を報告するだけです。APIを設計したり、モックしたり、文書化したり、コードとして管理したりすることはできません。そのため、多くのチームがJSONファイルの実行以上の機能を持つ単一のツールを求めるようになったり、Node v22の要件などの問題に直面して、別のツールを探し始めたりします。
Hoppscotch CLIが実際にできること
Hoppscotch CLIは、npmパッケージ@hoppscotch/cliとして提供されています。グローバルにインストールします。
npm i -g @hoppscotch/cli
まず知っておくべきこととして、Node.js v22以降が必要です。Node 20に固定されている場合は、CLI v0.26.0を使用することになりますが、他のジョブが古いNodeに固定されている共有CIイメージでは複雑になる可能性があります。
コアコマンドはhopp testです。コレクションファイル（またはクラウドコレクションID）を指定すると、その中のすべてのリクエストを順番に実行します。
hopp test ./collection.json -e ./environment.json -d 500
クラウドまたはセルフホストインスタンスの場合、IDと認証情報を渡します。
hopp test <collection-id> -e <environment-id> --token <access_token> --server <server-url>
プリリクエストスクリプトとテストスクリプト（pw.test()スイート、pw.expect()ケース）を実行し、応答を検証し、いずれかのアサーションが失敗すると非ゼロで終了します。また、JUnit XML用の--reporter-junit <path>、データ駆動型実行用の--iteration-countおよび--iteration-data <csv>もサポートしています。これは非常に高性能な無料ランナーです。
チームがHopp testの代替を探す理由
人々がHoppscotch CLIの代替を探す理由は、通常、思想的なものではなく実用的なものです。
- 単なるコレクションランナーであること。 設計、モック、ドキュメントは別の場所で行われます。結果として複数のツールを組み合わせることになります。
- 最初にJSONをエクスポートする必要があること。 スペックと環境は、エクスポートされたコレクション/環境ファイル（またはクラウドID）として入力されます。CLI自体にはスペックリンティングやデザインレイヤーがありません。
- Node v22の要件。 多くのビルドイメージのデフォルトよりも新しいため、追加のバージョン管理が必要です。
- コードとしてのスペックのワークフローがないこと。 CLIからエンドポイント、スキーマ、ブランチを管理することはできません。CLIは、APIを定義した場所の下流に位置します。
これらのどれもがHoppscotchを悪いものにするわけではありません。単に焦点を絞ったツールであるということです。より幅広いカバレッジを求めるなら、次に挙げる代替案が検討する価値があります。
1. Apidog CLI（最高のオールインワン代替）
Apidogは、設計、デバッグ、モック、ドキュメント、テストをカバーするオールインワンのAPIプラットフォームです。Apidog CLIは、テストとリソース管理の側面をターミナルとCI/CDにもたらし、これがスタンドアロンのコレクションランナーに対する強力な代替となる理由です。
apidog runを使用すると、コマンドラインからテストシナリオとコレクションを実行できます。データ駆動型テスト（-dでCSVまたはJSONデータセット）、環境（-e）、CLI、HTML、JSON形式のレポーター、そして--upload-reportによるクラウドテストレポートをサポートしています。テスト実行に加えて、CLIはOpenAPIのインポート、APIリソース、エンドポイント、スキーマ、環境、ブランチ、マージリクエストをコードとして管理できます。これにより、API定義とテストは、行き来するエクスポートではなく、同じシステム内に存在します。
スコープについて正確に言うと、Apidogはインポート時にスペックを検証しますが、スタンドアロンのOpenAPIリンターやsplit/join/bundleコマンドは提供していません。CIでの純粋なスペックリンティングが目標であれば、inso（下記）の方が適しています。Apidogの売りは統合であり、設計、モック、ドキュメント、テストを1か所で行い、CLIからテストとリソース層を駆動します。
長所：
- ツールチェーンではなく、設計、モック、ドキュメント、テストのための単一プラットフォーム
- CSV/JSONデータセットによるデータ駆動型実行
- CLI、HTML、JSONレポーター、およびアップロード可能なクラウドレポート
- リソース・アズ・コード：CLIからエンドポイント、スキーマ、ブランチ、マージリクエストを管理
- OpenAPIを直接インポート
短所：
- スタンドアロンのスペックリンターコマンドがない（SpectralスタイルのリンティングにはinsoまたはRedoclyを使用）
- 1つのコレクションしか実行しない場合、フルプラットフォームは必要以上に高機能
両者を比較検討する際は、Apidog CLI vs Hoppscotch CLIと、実用的なHoppscotch CLIからApidog CLIへの移行のチュートリアルをご覧ください。より広範なApidog CLIの完全ガイドでは、インストール、認証、全コマンドセットをカバーしています。試すには、Apidogをダウンロードしてください。
2. Newman (Postmanランナー)
Newmanは、Postmanの公式コマンドラインコレクションランナーです。チームがすでにPostmanを使用している場合、Newmanは最も抵抗の少ない道です。コレクションと環境をエクスポートし、CIで実行するだけです。
newman run collection.json -e env.json -r cli,json
複数のレポーター（CLI、JSON、JUnit、プラグイン経由のHTML）、イテレーション用のデータファイル、パイプライン用の安定した終了コード契約をサポートしています。
長所：
- 成熟しており、広く文書化され、巨大なエコシステム
- ファーストクラスのPostman互換性
- 柔軟なレポーターとデータ駆動型イテレーション
短所：
- Hoppscotch CLIと同様に、ランナーのみで、デザインやドキュメント層はない
- Postmanコレクション形式とそのスクリプトモデルに縛られる
- 使用するにはJSONをエクスポートする必要がある
Apidogのアプローチとの直接比較については、Apidog CLI vs Newmanをご覧ください。
3. inso (KongによるInsomnia CLI)
insoは、KongのオープンソースクライアントInsomniaのコマンドラインコンパニオンです。Hoppscotch CLIにはない機能、OpenAPIスペックのリンティングを行います。リンティングはSpectral（Stoplight OpenAPIリンター）上で実行されるため、CIにおけるスペックの品質ゲートが重要であれば、insoは有力な候補です。
inso run test "My Test Suite" --env "Staging"
inso lint spec "My API Design"
inso export spec "My API Design" --output output.yaml
insoは、.insomniaディレクトリ（InsomniaのGit同期によって作成）またはアプリデータディレクトリから読み込み、スイートとスペックを名前で参照します。brew install insoまたはdocker pull kong/inso:latestでインストールできます。
長所：
- Spectralによる本格的なOpenAPIリンティング
- テストとコレクションの実行、スペックのエクスポートをすべてターミナルから
- BrewおよびDockerによるインストールパス
短所：
- リソースを名前で参照するため、スクリプトで脆くなる可能性がある
- Insomnia 8は2023年に必須のクラウド/ログインアカウントを導入し、反発を招き、その変更に伴う移行やデータ損失の問題が発生しました。エコシステムを新たに導入するなら、知っておくべき点です。
Insomniaをより広範に評価する場合、Apidog vs Insomniaと最適なInsomniaアプリの代替は、次に読むべき良い記事です。また、焦点を絞ったApidog CLI vs inso (Insomnia CLI)の比較もあります。
4. Step CI (YAMLでAPIをテストするオープンソース)
Step CIは、スクリプト化されたJSではなく宣言的なYAMLでテストを定義するオープンソースのAPI品質ツールです。リクエストと期待されるレスポンスを記述し、それがチェックされます。REST、GraphQL、gRPCをサポートしており、ほとんどのコレクションランナーよりも幅広いプロトコルをカバーしています。
npx stepci run workflow.yml
長所：
- 宣言的なYAMLで、バージョン管理で読みやすい
- マルチプロトコル (REST, GraphQL, gRPC)
- GUIへの依存がなく、設定は完全にリポジトリ内で完結
短所：
- コミュニティとエコシステムが小さい
- デザイン、モック、ドキュメント層がない
- 記録ではなく、YAMLで手動でテストを作成する必要がある
Step CIは、gitネイティブで人間が読めるテストを望み、UIが全く不要な場合に最適です。
5. Hurl (プレーンテキストHTTPテスト)
Hurlは、シンプルなプレーンテキスト形式で記述されたHTTPリクエストを実行し、レスポンスをアサートします。libcurlをベースにしており、高速でクリーンな出力が得られます。スクリプトやJSONコレクションはなく、プルリクエストで差分を確認できる.hurlファイルのみです。
GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "up"
以下で実行します。
hurl --test health.hurl
長所：
- 非常に軽量で、単一バイナリ、高速
- ドキュメントのように読めるプレーンテキストファイル
- CIでのスモークテストやヘルスチェックに最適
短所：
- 本格的なテストフレームワークよりも低レベル
- デザイン、モック、ドキュメント機能がない
- 複雑なチェーンされたデータ駆動型シナリオには不便
Hurlは、迅速で読みやすいコントラクトチェックやスモークチェックに優れています。プラットフォームを目指しているわけではありません。
比較表
| ツール | ライセンス | 主要な焦点 | データ駆動型 | スペックリンティング | 設計/モック/ドキュメント | レポート形式 |
|---|---|---|---|---|---|---|
| Apidog CLI | 商用（無料枠あり） | フルプラットフォーム + CLIテスト | あり (CSV/JSON) | なし（インポート時に検証） | あり | CLI, HTML, JSON, クラウド |
| Hoppscotch CLI | オープンソース | コレクションランナー | あり (CSVイテレーション) | なし | なし | CLI, JUnit |
| Newman | オープンソース | Postmanランナー | あり (データファイル) | なし | なし | CLI, JSON, JUnit, HTML |
| inso | オープンソース | Insomniaランナー + リンター | 限定的 | あり (Spectral) | 部分的（デザインドキュメント） | CLI, JUnit |
| Step CI | オープンソース | YAML APIテスト | あり | なし | なし | CLI, JUnit |
| Hurl | オープンソース | プレーンテキストHTTPテスト | テンプレート経由 | なし | なし | CLI, JUnit, HTML |
選び方
- 設計からテストまで1つのツールで完結させたい場合： Apidog CLI。JSONをエクスポートして実行する手間を省き、APIリソースとテストを同じシステムに保持します。
- チームがすでにPostmanを使用している場合： Newman。最も移行コストが低いでしょう。
- CIでOpenAPIリンティングが必要な場合： Spectralを利用できるinso。
- Gitネイティブで宣言的なテストが必要な場合： Step CI（YAML）またはHurl（プレーンテキスト）。
- 無料のOSSランナーで満足しており、Node 22を避けたいだけの場合： 上記のいずれか。Newman、Step CI、Hurlにはその要件はありません。
Hoppscotch CLIを離れる主な理由が、特定の不便さではなく、コレクションランナーの限界である場合、まず検討すべきは統合されたアプローチです。Apidog CLI vs Postman CLIやApidog CLI CI/CDパイプラインで、テストの側面が実際のパイプラインにどのように適合するかを、またApidog CLIテストレポートでレポーターのオプションを確認してください。
よくある質問
Hoppscotch CLIは無料ですか？ はい。@hoppscotch/cliはオープンソースで無料で使用できます。コレクションを実行し、テストスクリプトを実行し、JUnitレポートを出力します。ここで挙げられている代替案は、Hoppscotchが高価だからではなく、ランナー以上の機能を求めるためです。
Node v22を避けたい場合、Hoppscotch CLIの最もシンプルな代替はどれですか？ HurlはNodeの依存関係が全くない単一バイナリです。insoはHomebrewまたはDocker経由でインストールできます。Step CIはnpx経由で実行されますが、現在のHoppscotch CLIのようにNode 22に固定されているわけではありません。
既存のHoppscotchコレクションを別のツールに移行できますか？ はい。ほとんどのツールはエクスポートされたコレクションまたはOpenAPIを受け入れます。統合されたアプローチの場合、Hoppscotch CLIからApidog CLIへの移行ガイドは、スイートのインポートと再実行を案内しています。
Apidog CLIはinsoのようにOpenAPIスペックをリンティングしますか？ いいえ。Apidogはインポート時にスペックを検証しますが、スタンドアロンのリンターコマンドはありません。CIでSpectralスタイルのスタイルガイド強制が厳密な要件である場合は、Apidogとinsoを組み合わせるか、リンティングに焦点を当てたオプションを比較するためにApidog CLI vs Redocly CLIを参照してください。
CIパイプラインに最適な代替はどれですか？ すべてのツールは失敗時に非ゼロの終了コードを返すため、CIで機能します。決定要因は、他に何が必要かです。純粋な実行であればNewmanやHurlが有利。設計とテストの両方で単一の信頼できる情報源が必要な場合はApidog CLIが有利。スペックゲートが必要な場合はinsoが有利です。
Hoppscotch CLIは、その唯一の仕事をうまくこなします。その仕事だけで十分なら、そのまま使い続けてください。設計、モック、ドキュメント、テストをランナーをつなぎ合わせるのではなく、単一のワークフローに統合したい場合は、統合プラットフォームが最善の選択です。Apidog CLIの完全ガイドから始め、Apidogをダウンロードして最初のシナリオを実行してみてください。