CIでInsomniaを実行している方なら「inso」をご存知でしょう。これはKongのオープンソースAPIクライアントであるInsomniaのコマンドラインツールであり、ターミナルから3つの便利な機能を提供します。テストスイートの実行、リクエストコレクションの実行、そしてSpectralを使ったOpenAPI仕様のリントです。多くのチームにとってこれで十分ですが、他のチームにとってはすぐに問題が浮上します。
このガイドでは、「inso」とは何か、なぜチームが**insoの代替ツール**を探し始めるのか、そして必要な作業に応じてどのツールがそれに取って代わるのかを説明します。中には完全なAPIプラットフォームであるものもあれば、ごく小さな単一目的のランナーもあります。完璧に置き換えられるものは一つもないため、「最適な**Insomnia CLIの代替ツール**は何か」という問いに対する正直な答えは、「今日、insoを何のために使っているかによる」ということになります。
ボタン
insoの機能と問題点
「inso」は、作業ディレクトリ内の.insomniaディレクトリ（InsomniaのGit同期によって作成されたもの）、またはデスクトップアプリがインストールされている場合はInsomniaアプリのデータディレクトリから読み込みます。仕様やスイートは、ファイルパスではなく名前で参照します。
inso run test "My API Test Suite" --env "Staging"
inso run collection "Smoke Tests" --env "Staging"
inso lint spec "Petstore Design Doc"
inso export spec "Petstore Design Doc" --output openapi.yaml
インストールは簡単です。Homebrew（brew install inso）、Dockerイメージ（docker pull kong/inso:latest）、またはWindows、Linux、macOS用の直接ダウンロード可能なzipファイルがあります。Stoplight OpenAPIリンターであるSpectralがinso lint specの機能を支えています。このリンティング機能は真の強みであり、切り替える前に覚えておく価値があります。
では、なぜ**insoの代替ツール**を探すのでしょうか？いくつか繰り返し挙げられる理由があります。
- Insomniaアプリのデータベースとの結合。テストの信頼できる情報源が
.insomniaディレクトリ内またはアプリのデータフォルダ内に存在します。デスクトップアプリを使用しない場合、このモデルは逆行しているように感じられます。 - 名前ベースの参照。スイートや仕様は表示名で参照されます。GUIでスイートの名前を変更すると、CIコマンドがサイレントに失敗します。名前は安定した識別子ではありません。
- クラウドアカウントの問題。Insomnia 8（2023年）では必須のクラウドログインアカウントが導入され、大きな反発を招きました。その時期にはデータ損失や移行のインシデントも発生しました。これによって痛手を負ったチームは、リクエストデータをベンダーアカウントに縛られないツールを探し始めました。
- リンティングとテストの分離。
insoは仕様のリンティングとリクエストのテストをバンドルしています。どちらか一方しか必要ない場合、他方を含まないツールを望むかもしれません。
OpenAPIのリンティングがinsoを実行する主な理由である場合、ツールを切り替えることで得られるものよりも失うものの方が大きいかもしれません。以下のほとんどのランナーは、リクエストの実行とアサーションに焦点を当てており、Spectralスタイルのスタイルガイドチェックは行いません。この違いを念頭に置いて読み進めてください。
代替ツール一覧
| ツール | 種類 | ソース形式 | データ駆動型 | レポーター | オープンソース | 最適な用途 |
|---|---|---|---|---|---|---|
| Apidog CLI | フルプラットフォームランナー | Apidogプロジェクト / OpenAPIインポート | はい（-d CSV/JSON） |
CLI, HTML, JSON | いいえ（無料プランあり） | 単一プラットフォーム：設計、モック、ドキュメント、テスト |
| Newman | Postmanコレクションランナー | PostmanコレクションJSON | はい（-d CSV/JSON） |
CLI, HTML, JSON | はい | 既存のPostmanコレクション |
| Hoppscotch CLI | OSSコレクションランナー | HoppscotchコレクションJSON / クラウドID | はい（イテレーションデータCSV） | CLI, JUnit XML | はい | 無料、セルフホスト可能なOSSパイプライン |
| Step CI | 宣言型APIテスター | YAML / JSONワークフローファイル | 制限あり | CLI, JUnit | はい | 仕様駆動型、コードとしての設定テスト |
| Hurl | プレーンテキストHTTPランナー | .hurl テキストファイル |
変数経由 | CLI, JUnit, HTML | はい | 軽量HTTPアサーション |
1. Apidog CLI（オールインワンの選択肢）
Apidogは、設計、デバッグ、テスト、モック、ドキュメンテーションをカバーするオールインワンのAPIプラットフォームです。Apidog CLIは、そのテスト機能をターミナルとCI/CDに持ち込み、insoと直接競合します。
apidog runは、テストシナリオとコレクションをコマンドラインから実行します。-d（CSVまたはJSONデータセット）によるデータ駆動型テスト、-eによる環境、そしてCLI、HTML、JSON形式のレポーターをサポートしています。また、--upload-reportでクラウドテストレポートをアップロードできるため、結果が単にCIログの中に消えてしまうこともありません。
apidog run --access-token <token> -t <scenario-id> -e <env-id>
apidog run -t <scenario-id> -d ./users.csv -r html,cli
apidog run -t <scenario-id> --upload-report
テスト実行以外にも、Apidog CLIはAPIリソースをコードとして管理します。OpenAPIのインポート、エンドポイント、スキーマ、環境、ブランチ、マージリクエストをターミナルから操作できます。このブランチとリソースをコードとして扱うモデルは、.insomniaディレクトリのパターンよりもGitネイティブなワークフローに近く、複数のツールをつなぎ合わせたスタックではなく、単一のツールを望むチームがApidogを選ぶ理由となっています。
補足： Apidog CLIには、スタンドアロンのOpenAPIリンター、スタイルガイド、分割、結合、またはバンドルコマンドはありません。インポート時に仕様を検証しますが、insoがSpectralで行うようなリンティングは行いません。ターミナルでのリンティングが中核的なニーズである場合、これは実際のギャップであり、inso（またはRedocly CLI）がその点で優位性を保ちます。Apidogが優れているのは統合性であり、設計、モック、ドキュメント、テストがすべて一箇所に集約され、データ駆動型の実行と複数形式のレポーターが組み込まれています。
利点
- 設計、モック、ドキュメント、テストのための単一プラットフォームであり、ばらばらのツールをつなぎ合わせたものではない
- データ駆動型の実行（
-d）、3種類のレポーター形式、環境、クラウドレポート - CLIからコードとして管理されるリソースとブランチ
欠点
- スタンドアロンの仕様リンターがない（インポート時に検証するが、Spectralのようにリンティングはしない）
- 完全なオープンソースではなく、無料プランがある
ターミナルランナーを直接比較する場合、Apidog CLIの完全ガイドではセットアップについて説明されており、Apidog CLIとNewmanの比較、Apidog CLIとPostman CLIの比較のような直接的な比較分析も提供されています。自動化に組み込む場合は、GitHub Actionsガイドを参照してください。
2. Newman（Postman CLIランナー）
Newmanは、Postmanのオープンソースのコマンドラインコレクションランナーです。チームがすでにPostmanを使用している場合、既存のコレクションをそのまま実行できるため、これは明らかな**inso CLIの代替ツール**となります。
newman run collection.json -e staging.json -d data.csv -r cli,html,json
Newmanは、-dによるデータ駆動型イテレーション、-eによる環境ファイル、そしてCLI、HTML、JSON形式のレポーターをサポートしています。これは成熟しており、ドキュメントも豊富で、CIの例で広く使われています。
利点
- 既存のPostmanコレクションを手直しなしに実行できる
- オープンソース、巨大なコミュニティ、豊富なCIのレシピ
- 堅牢なレポーターエコシステム
欠点
- Postmanコレクション形式とその同期モデルに縛られる
- OpenAPIリンティング機能が全くない
- コレクションはPostmanアプリで管理され、プレーンな仕様ファイルとしては扱われない
Newmanの限界とプラットフォームランナーの始まりについて並べて比較するには、Apidog CLIとNewmanの比較がレポーター、データ駆動型実行、クラウドレポートをカバーしています。
3. Hoppscotch CLI（オープンソースランナー）
Hoppscotchは、PostmanやInsomniaの代替として位置付けられているオープンソースのAPIエコシステム（ウェブ、デスクトップ、CLI、セルフホスト可能）です。そのCLIである@hoppscotch/cliは、CIでコレクションを実行します。
インストールにはNode.js v22以降が必要です（Node 20ユーザーはCLI v0.26.0を使用してください）。
npm i -g @hoppscotch/cli
hopp test ./collection.json -e ./env.json -d 100
hopp test <collection-id> --token <pat> --server https://hoppscotch.example.com
hopp test ./collection.json --reporter-junit ./report.xml
hopp testはコレクション内のすべてのリクエストを再帰的に実行し、プリリクエストスクリプトとテストスクリプト（pw.test()スイート、pw.expect()ケース）を実行し、レスポンスを検証します。アサーションが失敗した場合、ゼロ以外のコードで終了します。フラグは、環境（-e）、遅延（-d）、パーソナルアクセストークン（--token）、セルフホスト型サーバー（--server）、JUnit XML出力（--reporter-junit）、およびデータ駆動型イテレーション（--iteration-count、--iteration-data）に対応しています。
利点
- 完全にオープンソースでセルフホスト可能、必須のベンダーアカウント不要
- JUnitレポートとデータ駆動型イテレーションを備えた純粋な無料OSSランナー
- クラウドまたはセルフホストのコレクション参照
欠点
- Node v22+の要件は、古いCIイメージにとって問題となる可能性がある
- Newmanよりもエコシステムが小さい
- OpenAPIリンティング機能がない
オープンソースの道を選ぶ場合、Hoppscotchの代替ツールやPostmanとHoppscotchの比較が役立つ情報を提供しており、Apidog CLIとHoppscotch CLIの直接比較もあります。
4. Step CI（宣言型オプション）
Step CIは異なる形をとります。GUIで作成されたコレクションを指すのではなく、APIテストをリポジトリに存在する宣言型YAMLまたはJSONワークフローファイルとして記述します。テストは設定として扱われ、他のコードと同様にプルリクエストでレビューされます。
version: "1.1"
name: Status check
tests:
health:
steps:
- name: GET health
http:
url: https://api.example.com/health
method: GET
check:
status: 200
insoの名前ベースの参照が脆いと感じた場合、これは魅力的です。ここでは、テスト定義がファイルそのものであり、ファイルパスが識別子となります。Step CIはローカルおよびCIで実行され、JUnit出力を生成します。
利点
- テストはリポジトリ内の宣言型ファイルであり、PRでレビュー可能
- アプリデータベースもGUIへの依存もなし
- 仕様駆動型のチームに適している
欠点
- アドホックなデバッグにおいては、GUIベースのランナーよりもインタラクティブ性が低い
- コミュニティが小さく、手作業で書くことが多い
- データ駆動型サポートはNewmanやApidogよりも制限されている
Step CIは、テスト定義をツールのデータベース内ではなく、アプリケーションコードの隣に置きたいチームにとって、クリーンな**Insomnia CLI代替**となります。
5. Hurl（プレーンテキストオプション）
Hurlは、ここでのエントリの中で最もミニマルなものです。HTTPリクエストとアサーションをプレーンな.hurlテキストファイルに記述し、Hurlがそれらを実行します。GUIなし、データベースなし、アカウントなし、ただのテキストです。
GET https://api.example.com/users/1
HTTP 200
[Asserts]
jsonpath "$.id" == 1
jsonpath "$.name" exists
hurl --test users.hurlで実行します。リクエストを連結し、リクエスト間で変数をキャプチャし、JUnitおよびHTMLレポートをサポートします。スモークテストや契約テストの場合、高速でほぼ設定不要です。
利点
- 非常にシンプルなプレーンテキスト形式で、バージョン管理がしやすい
- アプリなし、アカウントなし、CIにおけるフットプリントが非常に小さい
- 変数をキャプチャした連結リクエスト
欠点
- 完全なテストフレームワークではなく、複雑なシナリオでは冗長になる
- コレクションGUIがないため、CLIユーザー以外にはとっつきにくい
- OpenAPIリンティング機能がない
選び方
ブランドではなく、用途で選びましょう。
- 設計、モック、ドキュメント、テストを1つのツールで完結したい場合。Apidog CLIを使用してください。最も広範な代替ツールであり、リソースとブランチをコードとして扱う唯一のツールです。
- 既にPostmanコレクションがある場合。Newmanを使用してください。既存のものを再構築する必要はありません。
- 完全にオープンソースでセルフホスト可能なものを望む場合。Hoppscotch CLIを使用してください。さらに軽量なものを望むならHurlも良いでしょう。
- テストをリポジトリ内の宣言型ファイルとして管理したい場合。Step CIを使用してください。
- 主に
inso lint specを実行している場合。切り替える前によく考えてください。Spectralによるリンティングはinsoの真の強みであり、ここにあるほとんどのランナーはそれを置き換えません。ランナーとSpectralを直接組み合わせるか、専用のリンティングCLIを検討してください。
insoだけでなく、より広範なInsomniaエコシステムからの移行を検討している場合は、以下の記事を読む価値があります。ApidogとInsomniaの比較、最適なInsomniaアプリ代替ツール、そしてInsomniaのデータ損失と移行に関する回復ガイドです。特にCLIからCLIへの移行については、insoからApidog CLIへの移行を参照してください。