Apidog CLI vs Keploy: レコード&リプレイ vs APIテスト設計

Apidog CLIとKeployを比較するときは、まず「同じAPIテストツール」ではなく、解決する課題が違うツールだと整理すると判断しやすくなります。KeployはeBPFで実行中アプリのトラフィックを記録し、テストケースと依存関係モックを自動生成します。一方、Apidog CLIは、Apidog上で作成またはAPI仕様から生成したテストシナリオをCLIで実行します。

今すぐApidogを試す

この違いは、導入手順、CI/CDへの組み込み方、モックの作り方にそのまま影響します。既存サービスの実際の挙動をすばやく固定したいのか、それともチームでレビュー・保守できるAPIテストスイートを設計したいのかを先に決めると、選択を間違えにくくなります。

コアな違い

Keployは、実行中のアプリケーションを観察します。keploy recordでアプリを起動し、実際のリクエストを送ると、API呼び出し、DBクエリ、ネットワークイベント、ストリーミングイベントなどをeBPF層でキャプチャします。その後、キャプチャ内容をテストケースと依存関係モックに変換し、keploy testで再生します。

Apidogは逆に、テストしたい意図を先に定義します。エンドポイント、スキーマ、テストステップ、アサーション、環境変数、リクエスト間のデータ受け渡しをApidog上で作成し、apidog runで実行します。

要約すると、次の違いです。

• Keploy: 実際に起きた挙動を記録して再生する
• Apidog CLI: 設計されたテストシナリオを実行する

どちらが正しいかではなく、答えたい質問が違います。

テストを作成する手順

Keployで記録ベースのテストを作る

Keployでは、テストは観察された実行結果から生成されます。まずインストールします。

curl --silent -O -L https://keploy.io/install.sh && source install.sh

次に、アプリをKeploy経由で起動してトラフィックを記録します。

keploy record -c "CMD_TO_RUN_APP"

記録中に実際のAPIリクエストを送ると、そのリクエストと依存関係の呼び出しがテストケースとして保存されます。

再生は次のように実行します。

keploy test -c "CMD_TO_RUN_APP" --delay 10

この方法は、すでに動いているサービスに対して「今の挙動をテスト化したい」場合に向いています。コード変更やSDK追加は不要で、Go、Java、Node.js、Python、Rust、C#、C/C++、TypeScriptなどのスタックで利用できます。HTTP/REST、gRPC、GraphQL、Kafka、RabbitMQのような通信も対象になります。

Keployには、OpenAPI、Postman、cURL、ライブエンドポイントから検証済みスイートを生成するパスもあります。

Apidog CLIで設計ベースのテストを実行する

Apidogでは、テストはAPI設計や仕様から作ります。一般的な流れは次のとおりです。

1. ApidogでAPIエンドポイントとスキーマを定義する
2. テストシナリオを作成する
3. リクエストステップ、アサーション、変数、データ受け渡しを設定する
4. 環境を選択する
5. CLIで実行する

CLI実行例は次のとおりです。

apidog run --access-token <TOKEN> -t <SCENARIO_ID> -e <ENV_ID>

Apidogでも、アプリ内で定義したAPIスキーマやエンドポイントからAIテストケースを生成できます。作成したシナリオは、単発の記録結果ではなく、チームでレビュー・保守するテスト資産として扱えます。

Apidog CLIのシナリオ、トークン、終了コードについては、Apidog CLI完全ガイドで確認できます。

Apidog CLI vs Keploy: 機能比較

側面	Keploy	Apidog CLI
コアアプローチ	実際のトラフィックを記録し、決定論的に再生	作成済み / AI仕様生成済みテストシナリオを実行
テストの作成方法	ライブAPIコールと依存関係からキャプチャ	プラットフォーム内で設計、または仕様から生成
必要なコード変更	なし。eBPFキャプチャ、SDKなし	アプリへの変更なし。シナリオを作成
言語非依存	はい。eBPFネットワーク層でキャプチャ	はい。スタックに関係なく任意のHTTP APIに対して実行
依存関係モック	キャプチャされたトラフィックから自動生成。DB、ネットワーク、ストリームを含む	設計して設定するモックサーバー
データ駆動型テスト	記録されたバリエーションから導出	CSVまたはJSONを-dで指定
レポート	再生実行からのテスト結果	CLI、HTML、JSON、--upload-reportによるクラウドレポート
OS制約	eBPFのためLinuxと昇格された権限が必要	CLIが動作する環境で実行可能。macOS、Linux、Windows、CI
プラットフォームの広さ	テストとテスト生成に特化	設計、デバッグ、モック、ドキュメント、テストを含むAPIライフサイクル
オープンソース	はい。Apache-2.0	無料枠あり。商用プラットフォーム

依存関係モックの違い

最も大きな分岐点は、依存関係モックです。

Keployの強みは、依存関係を自動的にモックできることです。APIコールと一緒にDBクエリやネットワークイベントをキャプチャするため、再生時にライブDBや外部サービスを用意する必要がありません。

たとえば、次のようなサービスではKeployが有効です。

• APIが複数のDBテーブルに依存している
• 外部サービス呼び出しが多い
• KafkaやRabbitMQなどのイベント処理がある
• 既存サービスにテストがほとんどない
• まず現在の実挙動を固定したい

一方、Apidogは設計ベースでモックを作ります。モックサーバーを設定し、どのリクエストにどのレスポンスを返すかを明示的に制御します。これは次のケースに向いています。

• まだ実装されていないAPIをフロントエンドや他チームに提供したい
• API仕様に沿った意図的なレスポンスを返したい
• 正常系、異常系、境界値を明示的に設計したい
• 本番DBの挙動ではなく、契約としてのAPI挙動を検証したい

ライブサービスの実際のDB通信を固定したいならKeployが適しています。仕様に基づいて意図したAPI挙動をモデリングしたいならApidogが適しています。

この領域は、より広く見ると契約テストとモッキングの一部です。重要なのは、キャプチャしたいのか、設計したいのかです。

なお、ApidogはeBPFでライブトラフィックをキャプチャしたり、本番環境の呼び出しから依存関係モックを自動生成したりしません。この記録・再生モデルはKeployの明確な強みです。

データ駆動型テストを実行する

Apidog CLIでは、CSVまたはJSONを使って同じシナリオを複数データで実行できます。

apidog run \
  --access-token <TOKEN> \
  -t <SCENARIO_ID> \
  -e <ENV_ID> \
  -d ./users.csv \
  -r html,cli

各オプションの役割は次のとおりです。

• -t: 実行するテストシナリオID
• -e: 使用する環境ID
• -d: CSVまたはJSONのデータファイル
• -r: レポーター。cli、html、jsonなど

CIで使う場合は、次のようにレポート形式を分けると扱いやすくなります。

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t $SCENARIO_ID \
  -e $ENV_ID \
  -d ./test-data/users.csv \
  -r cli,json,html

用途別には次のように考えます。

• cli: CIログで即時確認
• html: 成果物として共有
• json: 後続ジョブや独自集計で利用
• --upload-report: 結果をクラウドにアップロード

詳しくは、データ駆動型テストガイドとテストレポートの内訳で確認できます。CI/CDへの組み込みは、CI/CDセットアップのウォークスルーが参考になります。

Keployのレポートは、記録されたスイートを現在のコードに対して再生し、以前の挙動が維持されているかを確認するものです。これは回帰検出に強い一方で、「200行の入力データに対して設計したアサーションがすべて通るか」を確認するApidogのデータ駆動型実行とは目的が異なります。

OSと実行環境の制約

KeployはeBPFを使ってネットワーク層を計測するため、Linuxと昇格された権限が必要です。LinuxベースのCIや開発環境では問題になりにくいですが、macOSやWindows中心のチームでは導入前に確認が必要です。

一方、Apidog CLIはカーネルを計測せず、通常のHTTPリクエストを送信します。そのため、macOS、Linux、Windows、標準的なCIランナーで実行できます。

実行環境で見ると、判断軸は次のようになります。

• Linux環境で既存サービスの挙動を記録したい: Keploy
• OSを問わずCIでAPIテストを実行したい: Apidog CLI
• 特権実行を避けたい: Apidog CLI
• SDKやコード変更なしでランタイム依存関係をキャプチャしたい: Keploy

また、記録ベースのテストにはキュレーションが必要です。実トラフィックには、一時的な状態、ノイズの多い値、不要なケースが含まれる可能性があります。生成されたスイートをそのまま信頼するのではなく、ベースラインとして採用する前にレビューする必要があります。

設計ベースのテストは最初から意図を反映しやすい一方で、テストを書く手間は発生します。

プラットフォームとしての違い

Keployは、テスト生成と記録・再生に特化したツールです。API設計、ドキュメントホスティング、モック設計まで含めた総合APIプラットフォームではありません。

Apidogは、APIライフサイクル全体を扱うプラットフォームです。CLIはその一部であり、同じ環境で次の作業を行えます。

• API設計
• OpenAPIのインポート
• エンドポイントとスキーマの管理
• APIデバッグ
• モックサーバー
• ドキュメント生成
• テストシナリオ作成
• CLIによる自動実行

設計、モック、ドキュメント、テストが別々のツールに分かれていて運用が複雑になっている場合、Apidogの統合型アプローチは有効です。

APIテスト自動化ツール全体の中での位置づけは、APIテスト自動化ツールの比較でも確認できます。

どちらを選ぶべきか

Keployを選ぶべきケース

次の条件に当てはまるなら、Keployから始めるのが自然です。

• すでに動いているサービスがある
• テストスイートがほとんどない
• DBや外部サービスへの依存が多い
• 依存関係モックを手で作りたくない
• 実際のランタイム挙動をすばやく固定したい
• Linuxベースの環境を使える
• 生成されたテストを後から整理する前提がある

KeployはApache-2.0のオープンソースで、言語に依存しない記録・再生を目的に作られています。レガシーサービスのカバレッジを素早く立ち上げる用途に向いています。

Apidog CLIを選ぶべきケース

次の条件に当てはまるなら、Apidog CLIが適しています。

• API仕様を中心にテストを設計したい
• チームでレビュー・保守できるテスト資産を作りたい
• CSV/JSONでデータ駆動型テストを実行したい
• HTML/JSONレポートをCI成果物として扱いたい
• macOS、Linux、Windows、CIで同じように実行したい
• API設計、モック、ドキュメント、テストを1つのツールにまとめたい
• 実装前のAPIもモックして検証したい

Apidog CLIは、設計済みのAPIテストを安定して実行するための選択肢です。テストをAPI開発プロセスの一部として扱いたいチームに向いています。

実務での使い分け

実際には、KeployとApidog CLIは排他的ではありません。

たとえば、次のような分担ができます。

1. 既存のレガシーサービスにKeployを使い、現在の実挙動を記録する
2. 生成されたテストをレビューして、重要な回帰検出に使う
3. 新規開発や仕様変更があるAPIはApidogで設計する
4. Apidog CLIで設計済みシナリオをCIに組み込む
5. モックとドキュメントもApidogで管理する

この分担にすると、Keployは「現実のキャプチャ」、Apidogは「意図の設計と継続的な検証」を担当できます。

設計アプローチを試したい場合は、Apidogには無料枠があります。Apidogをダウンロードして、既存APIに対してシナリオを作成し、CLI実行まで試せます。

関連情報として、Keployとは何か、最高のKeploy代替案、Apidog CLI vs Keploy、KeployからApidog CLIへの移行ガイドも参考になります。

Keploy側の一次情報は、Keployドキュメント、GitHubリポジトリ、eBPFプロジェクトサイトで確認できます。

FAQ

ApidogはKeployのようにライブトラフィックを記録しますか？

いいえ。ApidogはeBPFを使ってライブトラフィックをキャプチャしたり、本番環境の呼び出しからテストを自動生成したりしません。Apidogでは、テストシナリオを作成するか、API仕様から生成し、CLIで実行します。ランタイム挙動と依存関係モックを記録するのはKeployの機能です。

データベース依存関係が多いサービスにはどちらが適していますか？

依存関係を自動的にキャプチャして再生したいならKeployです。KeployはDBクエリを記録し、モックとして再生できるため、ライブDBなしでテストを実行できます。

意図したレスポンスや契約としてのAPI挙動を設計したいならApidogが適しています。

どちらもコード変更が必要ですか？

どちらもアプリケーションコードの変更は不要です。KeployはeBPFネットワーク層で計測するためSDKなしで動作します。Apidog CLIはAPIにHTTPリクエストを送るだけなので、アプリケーションコードには触れません。

どちらもOpenAPI仕様からテストを生成できますか？

はい。KeployはOpenAPI、Postman、cURL、ライブエンドポイントから検証済みスイートを生成できます。Apidogも、プラットフォーム内のスキーマとエンドポイントからAIテストケースを生成できます。

違いは、Keployだけが記録されたランタイム挙動からもテストを生成できる点です。

より多くのOSで使いやすいのはどちらですか？

Apidog CLIです。macOS、Linux、Windows、標準的なCIランナーで実行できます。

KeployのeBPFキャプチャはLinuxと昇格された権限に依存します。LinuxベースのCIでは使いやすい一方、それ以外の環境では事前確認が必要です。

まとめ

KeployとApidog CLIの選択は、「どちらが優れているか」ではなく「何をテスト資産にしたいか」で決まります。

• 既存サービスの実挙動を、依存関係ごとすばやく記録したい: Keploy
• API仕様に基づいて、保守可能なテストを設計・実行したい: Apidog CLI
• DBや外部依存を自動モックしたい: Keploy
• CIでデータ駆動型テストとHTML/JSONレポートを使いたい: Apidog CLI
• API設計、モック、ドキュメント、テストを統合したい: Apidog

現実をキャプチャするならKeploy。意図を設計して継続的に検証するならApidog CLI。用途をこの2つに分けると、導入判断はシンプルになります。