パイプライン用のCLIテストランナーを選ぶときは、まず「開発中にAPIをどのツールで扱っているか」「CIで何を自動化したいか」を決めます。Insomnia中心ならinsoが自然です。一方、設計、モック、ドキュメント、テストまで同じワークスペースで管理したいなら、Apidog CLIが選択肢になります。
各ツールの概要
insoは、KongのオープンソースAPIクライアントであるInsomniaのCLIです。主な用途は次の3つです。
- リクエストコレクションの実行
- ユニットテストスイートの実行
- OpenAPI仕様のリンティング
Insomniaデスクトップアプリと同じデータを読み取るため、GUIで作成したリクエストをCI上でヘッドレス実行できます。
Apidog CLIは、設計、デバッグ、モック、ドキュメント作成、テストを単一ワークスペースで扱うApidogのCLIランナーです。プロジェクト内のテストシナリオやコレクションを実行し、データ駆動型テストや複数形式のレポート出力に対応します。また、OpenAPIのインポートや、エンドポイント、スキーマ、ブランチなどのAPIリソース管理にも使えます。
要点は次のとおりです。
-
inso: Insomniaエコシステムに特化したランナー兼リンター - Apidog CLI: Apidogプラットフォーム上のテスト・自動化インターフェース
Apidog CLI vs inso: 比較表
| 機能 | inso (Insomnia CLI) | Apidog CLI |
|---|---|---|
| インストール |
brew install inso、Docker (kong/inso)、または直接ダウンロード |
インストーラーをダウンロード。Apidogプロジェクトからシナリオを実行 |
| 実行対象 | テストスイートとリクエストコレクション(名前で参照) | プロジェクト内のテストシナリオとコレクション |
| データソース |
.insomniaディレクトリ (Git Sync) またはInsomniaアプリDB。--workingDir/--srcで上書き可能 |
Apidogワークスペースに同期されたプロジェクトテストシナリオ |
| データ駆動型テスト | 組み込みフラグなし | CSV/JSONデータセットを-dで指定可能 |
| レポーター | コンソール/CI出力 | CLI、HTML、JSON。--upload-reportでクラウドレポート |
| スペックリンティング |
inso lint specでSpectralベースのリンティング |
スタンドアロンのリンターなし。インポート時にスペックを検証 |
| リソース/ブランチ・アズ・コード | なし | CLIからエンドポイント、スキーマ、ブランチを管理 |
| プラットフォーム統合 | Insomniaクライアントと連携 | 設計、モック、ドキュメント、テストを一つのプラットフォームで管理 |
| オープンソース | はい(Insomniaはオープンソース) | 商用プラットフォーム |
| 価格設定 | 無料 | 無料枠あり |
以降では、CIに組み込むときに実装上重要になる違いを見ていきます。
インストール: brewとDocker vs Apidogインストーラー
insoは複数の方法で導入できます。
# Homebrew
brew install inso
# Docker
docker pull kong/inso:latest
Windows、Linux、macOS向けの直接ダウンロードも利用できます。CIランナーでNode.jsツールチェインを管理したくない場合は、Dockerイメージが扱いやすいです。
Apidog CLIはApidogダウンロードページからインストールします。Apidogプロジェクト内にあるシナリオを実行するため、ローカルフォルダを手動で同期し続ける必要はありません。
導入手順は次の記事も参考になります。
各ツールの実行内容と読み込み元
apidog cli vs insomnia cliを比較するとき、最も実装に影響するのがデータの参照方法です。
insoの場合
insoはスイートやスペックを名前で参照します。作業ディレクトリ内の.insomniaディレクトリ、またはInsomniaアプリのデータディレクトリから定義を読み込みます。
inso run test "Smoke Suite" --env "CI"
inso run collection "User API" --env "Staging"
inso script seed-data --env env_staging
必要に応じて--workingDirや--srcで参照先を変更できます。
inso run test "Smoke Suite" \
--env "CI" \
--workingDir ./api-tests
このモデルは、.insomniaフォルダをGitにコミットして真実の源として扱うチームに向いています。CI上では次の点を確認してください。
-
.insomniaフォルダがチェックアウトされている - テストスイート名やコレクション名が変更されていない
- CI用の環境名がInsomnia側に存在する
Apidog CLIの場合
Apidog CLIはApidogプロジェクト内のテストシナリオやコレクションを実行します。認証後、対象の環境を指定して実行します。
apidog run -t <scenario-or-collection> -e <environment>
例:
apidog run -t "Smoke Suite" -e "CI"
Apidog側で管理している定義を実行するため、GUIで作成・更新したシナリオをCIからそのまま使えます。
選択の目安はシンプルです。
- Git管理された
.insomniaフォルダを中心にしたい:inso - Apidogプロジェクト上のシナリオをそのままCIで実行したい: Apidog CLI
データ駆動型テスト
同じテストシナリオを複数の入力データで回す場合、Apidog CLIの-dが便利です。
apidog run -t "Checkout Flow" -e "Staging" -d ./datasets/orders.csv
CSVやJSONの各行を1回の反復として扱い、変数にマッピングできます。たとえば注文APIのテストなら、次のようなCSVを用意します。
orderId,userId,amount
1001,u001,1200
1002,u002,3400
1003,u003,5600
CIでは次のように実行できます。
apidog run \
-t "Checkout Flow" \
-e "Staging" \
-d ./datasets/orders.csv
詳しいパターンはApidog CLIでのデータ駆動型テストで説明されています。
insoには、CSV/JSONを直接指定して行ごとに反復する組み込みフラグはありません。環境変数やCIスクリプトでループさせることはできますが、Apidog CLIのようなファーストクラス機能ではありません。
データセットを使った反復実行が重要なら、Apidog CLIの方が実装しやすいです。
レポーター: CIで何を成果物にするか
CIでは、失敗したかどうかだけでなく、結果をどう確認・共有するかも重要です。
Apidog CLIは次の形式でレポートを出力できます。
- CLI
- HTML
- JSON
-
--upload-reportによるクラウドレポート
例:
apidog run \
-t "Smoke Suite" \
-e "CI" \
-r html,json
HTMLはCIの成果物として保存し、JSONはダッシュボードや後続処理に渡せます。
# 例: GitHub ActionsでHTML/JSONを成果物として保存するイメージ
- run: apidog run -t "Smoke Suite" -e "CI" -r html,json
- uses: actions/upload-artifact@v4
with:
name: apidog-test-report
path: ./reports
レポート形式の詳細はApidog CLIテストレポートガイドを参照してください。
insoはテスト結果をコンソールに出力し、終了コードで合否を通知します。多くのCIではこれで十分です。ただし、追加ツールなしでHTML成果物やホストされたレポートを使いたい場合は、Apidog CLIの方が機能が多いです。
リンティング: 正直な比較
OpenAPIのリンティングではinsoに明確な強みがあります。
inso lint specは、Spectralを使ってOpenAPIスペックをリンティングします。スタイルガイドを適用し、契約上の問題をCIで検出できます。
inso lint spec "Payments API"
inso export spec "Payments API" --output openapi.yaml
スペックファースト開発で、テスト実行と同じCLIからOpenAPIの品質チェックまで行いたい場合、insoは有力です。
一方で、Apidog CLIにはスタンドアロンのOpenAPIリンター、スタイルガイド、分割、結合、バンドル用のCLIコマンドはありません。Apidogはスペックのインポート時に構造的な問題を検証しますが、CIで任意のルールセットを適用するlintコマンドではありません。
つまり、次のように考えると整理しやすいです。
- CIでSpectralベースのOpenAPIリンティングをCLIから直接実行したい:
inso - Apidog上で設計・テスト・ドキュメントを統合し、必要なら別途Spectralステップを追加する: Apidog CLI
リソースとブランチ・アズ・コード
Apidog CLIは、テスト実行だけでなくAPIリソースの管理にも使えます。ターミナルからOpenAPIをインポートし、エンドポイント、スキーマ、環境、ブランチ、マージリクエストなどを扱えます。
これにより、たとえば次のような流れを自動化できます。
- OpenAPI定義をインポート
- Apidogプロジェクト上のリソースを更新
- 対象ブランチでテストシナリオを実行
- レポートをCI成果物として保存
insoはランナーとリンターとしての役割が中心です。スペックのエクスポートはできますが、エンドポイント編集やブランチ管理を行うリソース管理CLIではありません。
API定義とテスト実行を同じCLIベースのワークフローにまとめたい場合、Apidog CLIのリソース・アズ・コード機能が有利です。
プラットフォーム統合、オープンソース、価格設定
insoはオープンソースエコシステムの一部です。Insomnia自体もオープンソースであり、ツールの透明性や自己管理を重視するチームに向いています。
一方、Insomnia 8では必須のクラウド/ログインアカウント導入により反発があり、その時期には移行やデータ損失に関する問題も報告されました。背景を確認したい場合は、次の記事が参考になります。
ただし、insoがSpectralリンティングを内蔵した無料のCLIランナーであることは変わりません。
Apidogは無料枠のある商用プラットフォームです。設計、モック、ドキュメント作成、デバッグ、テストを1か所で扱い、CLIを自動化インターフェースとして使えます。
より広い製品比較は次の記事を参照してください。
実際にAPIテストを試す場合は、次のガイドから始められます。
CIへの接続
どちらのツールも、CIでは同じ考え方で組み込みます。
- CLIをインストールする
- 認証またはテストデータに接続する
- テストを実行する
- 終了コードでビルドを失敗させる
- 必要に応じてレポートを保存する
insoの例
- run: brew install inso
- run: inso run test "Smoke Suite" --env "CI"
Dockerを使う場合は、.insomniaディレクトリをコンテナから参照できるようにします。
docker run --rm \
-v "$PWD:/workspace" \
-w /workspace \
kong/inso:latest \
run test "Smoke Suite" --env "CI"
Apidog CLIの例
- run: apidog run -t "Smoke Suite" -e "CI" -r html,json
認証、キャッシュ、レポートアップロードを含めた構成は次の記事で確認できます。
評決
唯一の正解はありません。チームのAPI開発フローに合わせて選びます。
insoを選ぶべきケース:
- すでにInsomniaを中心に使っている
-
.insomniaフォルダをGit管理している - CIでSpectralベースのOpenAPIリンティングを実行したい
- 無料のオープンソース系CLIランナーを使いたい
Apidog CLIを選ぶべきケース:
- 設計、モック、ドキュメント、テストを一つのワークスペースにまとめたい
-
-dでCSV/JSONを使ったデータ駆動型テストを実行したい - CLI、HTML、JSON、クラウドレポートを使いたい
- APIリソースやブランチもCLIから管理したい
insoからApidog CLIへ移行する場合は、inso (Insomnia CLI) からApidog CLIへの移行を参照してください。
実際に比較するには、Apidogをダウンロードして、自分のAPIに対してシナリオを実行してみてください。
Top comments (0)