CIでInsomniaを実行しているなら、insoを使ったことがあるはずです。insoは、KongのオープンソースAPIクライアントであるInsomniaのCLIで、ターミナルからテストスイートの実行、リクエストコレクションの実行、Spectralを使ったOpenAPI仕様のリントを行えます。ただし、CI/CDで長期運用すると、データ管理、参照方法、クラウドアカウント依存などの課題が見えてきます。
このガイドでは、insoで何ができるのか、なぜチームがinsoの代替ツールを検討するのか、そして用途別にどのツールを選べばよいのかを実装視点で整理します。結論から言うと、最適なInsomnia CLIの代替ツールは「現在insoを何に使っているか」によって変わります。
insoの機能と問題点
insoは、作業ディレクトリ内の.insomniaディレクトリ、またはデスクトップアプリがインストールされている場合は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
インストール方法はシンプルです。
# macOS
brew install inso
# Docker
docker pull kong/inso:latest
inso lint specはStoplightのOpenAPIリンターであるSpectralを利用します。OpenAPIのスタイルガイドチェックが主目的なら、これは大きな強みです。
一方で、CI運用では次の課題が出やすくなります。
Insomniaアプリのデータベースと結合している
テストの信頼できる情報源が.insomniaディレクトリまたはアプリのデータフォルダにあります。デスクトップアプリを使わないチームには扱いづらい構成です。名前ベースの参照が壊れやすい
スイートや仕様を表示名で参照するため、GUIで名前を変更するとCIコマンドが失敗します。名前は安定した識別子ではありません。クラウドアカウント依存が気になる
Insomnia 8では必須クラウドログインが導入され、反発がありました。その時期にはデータ損失や移行の問題も報告されました。これをきっかけに、リクエストデータをベンダーアカウントに縛られない形で管理したいチームが増えました。リンティングとテストを分離したい
insoは仕様リンティングとリクエストテストを1つのCLIにまとめています。どちらか一方だけ必要な場合、より小さな専用ツールの方が扱いやすいことがあります。
注意点として、OpenAPIリンティングが主目的なら、単純に別のAPIテストランナーへ移行すると機能を失う可能性があります。以下の多くのツールはリクエスト実行とアサーションに強く、Spectralのような仕様リンティングは提供しません。
代替ツール一覧
| ツール | 種類 | ソース形式 | データ駆動型 | レポーター | オープンソース | 最適な用途 |
|---|---|---|---|---|---|---|
| Apidog CLI | フルプラットフォームランナー | Apidogプロジェクト / OpenAPIインポート | はい(-d CSV/JSON) |
CLI, HTML, JSON | いいえ(無料プランあり) | 設計、モック、ドキュメント、テストを1つに統合 |
| 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 | はい | 設定ファイルとしてAPIテストを管理 |
| Hurl | プレーンテキストHTTPランナー |
.hurl テキストファイル |
変数経由 | CLI, JUnit, HTML | はい | 軽量なHTTPアサーション |
1. Apidog CLI:オールインワンで置き換える
Apidogは、API設計、デバッグ、テスト、モック、ドキュメントを1つにまとめたAPIプラットフォームです。Apidog CLIは、そのテスト機能をターミナルとCI/CDに持ち込みます。
基本的な実行例は次の通りです。
apidog run --access-token <token> -t <scenario-id> -e <env-id>
CSVまたはJSONを使ったデータ駆動型テストも可能です。
apidog run -t <scenario-id> -d ./users.csv -r html,cli
CIでレポートを残したい場合は、HTML/JSONレポートやクラウドレポートを使います。
apidog run -t <scenario-id> -r html,json,cli
apidog run -t <scenario-id> --upload-report
Apidog CLIはテスト実行だけでなく、APIリソースをコードとして管理する用途にも使えます。OpenAPIのインポート、エンドポイント、スキーマ、環境、ブランチ、マージリクエストをCLIから操作できます。
.insomniaディレクトリに依存するよりも、GitとCIを中心にした運用へ寄せたい場合に向いています。
向いているケース
- API設計、モック、ドキュメント、テストを1つのプラットフォームに集約したい
- データ駆動型テストをCIで回したい
- HTML/JSON/CLIレポートを生成したい
- テスト結果をクラウドレポートとして共有したい
- リソースやブランチをCLIで管理したい
注意点
- スタンドアロンのOpenAPIリンターではありません
- インポート時に仕様を検証しますが、Spectralのようなスタイルガイドリンティングは行いません
- 完全なオープンソースではありませんが、無料プランがあります
Apidog CLIの導入手順は、Apidog CLIの完全ガイドで確認できます。比較検討する場合は、Apidog CLIとNewmanの比較、Apidog CLIとPostman CLIの比較、CIに組み込む場合はGitHub Actionsガイドが参考になります。
2. Newman:PostmanコレクションをそのままCIで実行する
Newmanは、PostmanのオープンソースCLIコレクションランナーです。すでにPostmanコレクションを持っているチームなら、最も導入しやすいinso CLIの代替ツールです。
newman run collection.json -e staging.json -d data.csv -r cli,html,json
主な使い方は次の通りです。
# コレクションを実行
newman run collection.json
# 環境ファイルを指定
newman run collection.json -e staging.json
# CSVでデータ駆動型テスト
newman run collection.json -d users.csv
# 複数形式でレポート出力
newman run collection.json -r cli,json,html
向いているケース
- 既存のPostmanコレクションをそのまま使いたい
- CIでPostmanテストを自動実行したい
- OSSかつ実績のあるランナーを使いたい
- レポーターエコシステムを重視したい
注意点
- Postmanコレクション形式に依存します
- OpenAPIリンティング機能はありません
- コレクション管理は基本的にPostmanアプリ中心です
Newmanとプラットフォーム型ランナーの違いを比較するなら、Apidog CLIとNewmanの比較が参考になります。
3. Hoppscotch CLI:OSSでセルフホスト可能なランナーを使う
Hoppscotchは、PostmanやInsomniaの代替として使えるオープンソースのAPIエコシステムです。Web、デスクトップ、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
遅延を指定して実行します。
hopp test ./collection.json -e ./env.json -d 100
クラウドまたはセルフホスト環境のコレクションを参照することもできます。
hopp test <collection-id> --token <pat> --server https://hoppscotch.example.com
JUnit XMLを出力する場合は次のようにします。
hopp test ./collection.json --reporter-junit ./report.xml
hopp testは、コレクション内のリクエストを再帰的に実行し、プリリクエストスクリプトとテストスクリプトを処理します。アサーションが失敗すると、ゼロ以外の終了コードで失敗します。
向いているケース
- 完全にオープンソースのAPIテストランナーを使いたい
- セルフホスト可能な選択肢が必要
- JUnitレポートをCIに取り込みたい
- ベンダーアカウントに依存したくない
注意点
- Node v22+要件が古いCIイメージでは問題になる可能性があります
- Newmanよりエコシステムは小さめです
- OpenAPIリンティング機能はありません
Hoppscotchを検討するなら、Hoppscotchの代替ツール、PostmanとHoppscotchの比較、Apidog CLIとHoppscotch CLIの直接比較も参考になります。
4. Step CI:APIテストをYAMLで管理する
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
実行イメージは次のようになります。
stepci run workflow.yml
JUnit出力をCIに取り込む構成にもできます。
stepci run workflow.yml --reporter junit
insoの名前ベース参照が壊れやすいと感じる場合、Step CIは分かりやすい代替になります。テスト定義そのものがファイルであり、ファイルパスを識別子として扱えるためです。
向いているケース
- APIテストをリポジトリで管理したい
- GUIやアプリ内データベースに依存したくない
- PRレビューでテスト変更を確認したい
- 宣言型のテスト定義を好む
注意点
- GUIベースのランナーよりインタラクティブなデバッグは弱めです
- 手でYAMLを書く場面が多くなります
- データ駆動型テストはNewmanやApidogほど強くありません
Step CIは、テスト定義をツール内データベースではなくアプリケーションコードの隣に置きたいチームにとって、クリーンなInsomnia CLI代替です。
5. Hurl:プレーンテキストでHTTPテストを書く
Hurlは、HTTPリクエストとアサーションを.hurlファイルに書いて実行するミニマルなツールです。GUI、データベース、アカウントは不要です。
GET https://api.example.com/users/1
HTTP 200
[Asserts]
jsonpath "$.id" == 1
jsonpath "$.name" exists
実行はシンプルです。
hurl --test users.hurl
JUnitやHTMLレポートを出力することもできます。
hurl --test users.hurl --report-junit report.xml
hurl --test users.hurl --report-html report.html
リクエストを連結し、レスポンスから値をキャプチャして次のリクエストに渡すこともできます。スモークテストや軽量な契約テストには十分です。
向いているケース
- とにかく軽いHTTPテストをCIに入れたい
- プレーンテキストでレビューしやすい形式にしたい
- GUIやアカウントに依存したくない
- 小さなスモークテストを高速に実行したい
注意点
- 複雑なシナリオでは冗長になりやすいです
- GUIコレクション管理はありません
- OpenAPIリンティング機能はありません
選び方
用途別に選ぶと、判断しやすくなります。
設計、モック、ドキュメント、テストを1つのツールで完結したい
Apidog CLIを使います。最も広範な代替ツールで、リソースとブランチをコードとして扱える点が特徴です。既にPostmanコレクションがある
Newmanを使います。既存資産を再構築せずにCIへ載せられます。完全にオープンソースでセルフホスト可能なものが必要
Hoppscotch CLIを使います。さらに軽量なテキストベースにしたいならHurlも候補です。テストをリポジトリ内の宣言型ファイルとして管理したい
Step CIを使います。PRレビューとの相性が良いです。主に
inso lint specを使っている
すぐに移行しない方が安全です。SpectralによるOpenAPIリンティングはinsoの強みです。テストランナーは別ツールに移しつつ、リンティングはSpectralや専用CLIを直接使う構成を検討してください。
insoだけでなくInsomnia全体からの移行を検討している場合は、ApidogとInsomniaの比較、最適なInsomniaアプリ代替ツール、Insomniaのデータ損失と移行に関する回復ガイドも参考になります。CLIからCLIへの移行については、insoからApidog CLIへの移行を確認してください。
Top comments (0)