Keployを使う価値は明確です。アプリを起動し、いくつかのエンドポイントを叩くだけで、実トラフィックからテストが生成されます。アサーションを手書きしたり、依存関係を手動でスタブしたりする必要はありません。Keployはネットワーク層でAPI呼び出しをキャプチャし、それを再生します。
では、なぜKeployから移行を検討するのでしょうか。多くの場合、理由は「テストをチームで読み、レビューし、意図的に変更したい」からです。キャプチャされたテストは、すでに発生した挙動の回帰検出には強力です。一方で、テストの意図、入力データ、環境差分、モックの設計を明示的に管理したい場合は、Apidogのような仕様ベースのAPIテスト基盤が向いています。
KeployとApidogは何が違うのか
KeployとApidogはどちらもAPIテストに関係しますが、前提となるパラダイムが異なります。
Keployは、実行中のアプリケーションからトラフィックを記録し、テストと依存関係モックを生成するオープンソースプラットフォームです。ネットワーク層でeBPFを使うため、SDKの追加やコード変更なしで、API呼び出し、DBクエリ、ダウンストリームサービス、ストリーミングイベントなどをキャプチャできます。ソースコードはGitHubで確認できます。
Apidogは、APIの設計、デバッグ、モック、ドキュメント、テストを1つのワークスペースで扱うAPIプラットフォームです。Apidog CLIのapidog runを使うと、作成したテストシナリオやコレクションをローカルやCI/CDで実行できます。データ駆動型テスト、環境切り替え、複数形式のレポート、クラウドレポートにも対応しています。
重要な違いはここです。ApidogはKeployのようにeBPFでライブトラフィックをキャプチャし、プロダクション実行から依存関係モックを自動生成するツールではありません。そこはKeployの強みです。Apidogへ移行して得られるのは、仕様ベースで設計され、レビューしやすく、チームで保守しやすいAPIテストです。
| Keployのアプローチ | Apidogのアプローチ |
|---|---|
keploy recordでeBPF経由の実トラフィックをキャプチャ |
OpenAPI、Postman、cURLからAPIサーフェスをインポート |
| キャプチャされた呼び出しからテストを自動生成 | 仕様からAIテストケースを生成し、シナリオを作成 |
keploy test --delay 10で記録を再生 |
apidog runでCI上のシナリオを実行 |
| 実際のDB/ネットワークトラフィックから依存関係モックを生成 | スキーマに基づき、制御可能なモックサーバーを設計 |
| テストデータは記録に埋め込まれる |
-dでCSV/JSONを渡すデータ駆動型テスト |
| 環境は記録時の実行に依存 |
-eで明示的に環境を切り替え |
| Linux/eBPFと昇格権限が前提 | CLIが動作する環境なら標準CIランナーでも実行可能 |
この表は優劣ではなく、移行時の変換表として読むと実務に落とし込みやすくなります。Keployでは「ツールが実トラフィックから理解したこと」を使います。Apidogでは「チームが正しい挙動として定義したこと」をテストにします。
ステップ1：APIサーフェスを仕様として用意する
Keployは実行中のアプリから始めます。ApidogはAPI仕様から始めます。まず、APIをインポート可能な形にします。
選択肢は次のとおりです。
- 既存のOpenAPI仕様を使う
- フレームワークからOpenAPIを生成する
- チームが管理しているPostmanコレクションをエクスポートする
- エンドポイント検証に使っているcURLコマンドを整理する
すでにKeployの記録がある場合は、それをインポートするのではなく、チェックリストとして使います。どのエンドポイントが、どのメソッド、パス、ヘッダー、ペイロードで呼ばれているかを確認し、OpenAPIやPostmanコレクション側で同じサーフェスをカバーします。
ステップ2：Apidogにインポートする
Apidogをダウンロードし、プロジェクトを作成します。その後、OpenAPIファイル、Postmanコレクション、またはcURLコマンドをインポートします。
インポート後、Apidog上には次の情報が構造化されます。
- エンドポイント
- HTTPメソッド
- パスパラメーター、クエリ、ヘッダー
- リクエストボディ
- レスポンスモデル
- スキーマ定義
ここで作成されるエンドポイント定義は、単なるテストフィクスチャではありません。ドキュメント、デバッグ用リクエスト、モックサーバー、テストシナリオの土台になります。CLIの全体像はApidog CLI完全ガイドで確認できます。
ステップ3：初期テストを生成し、重要シナリオを手で整える
次に、仕様から初期テストケースを作ります。
ApidogのAIテストケース生成は、インポートしたAPIスキーマとエンドポイントをもとに、正常系、境界値、一般的なエラーケースなどをドラフトします。ゼロから書き始めるより早く、最初のテストスイートを用意できます。
ただし、AI生成されたテストはそのまま本番用にしないでください。実装時は次の作業を行います。
- 不要なケースを削除する
- ステータスコードの期待値を確認する
- レスポンスボディのアサーションを厳密にする
- 認証、権限、エラー条件を追加する
- 実際の業務フローに沿ったシナリオへ組み直す
たとえば、ユーザーAPIなら次のようなシナリオを作成します。
- ユーザーを作成する
- 作成結果から
userIdを取得する - ログインしてトークンを取得する
- トークン付きでプロフィールを取得する
- プロフィールを更新する
- ユーザーを削除する
Keployでは、この流れが記録の中に暗黙的に含まれていました。Apidogでは、これを明示的なテストシナリオとして作ります。初期作業は増えますが、プルリクエストで読みやすく、変更理由も追いやすくなります。
AI生成と手動作成の使い分けは、AIアシスタンスでテストケースを記述する方法も参考になります。また、他の生成ツールとの比較は最高のAIテストケースジェネレーターの概要で確認できます。
ステップ4：環境とテストデータを分離する
Keployの記録には、1回の実行時点の値が含まれます。Apidogでは、環境とテストデータを分離して管理します。
まず、Apidogで環境を作成します。
- local
- staging
- production
- preview
- sandbox
それぞれに、ベースURL、認証トークン、共通変数を設定します。CLI実行時は-eで環境を指定します。
次に、CSVまたはJSONでテストデータを用意します。たとえばログインケースなら、次のようなCSVを作れます。
email,password,expectedStatus
user1@example.com,correct-password,200
user2@example.com,wrong-password,401
locked@example.com,password,403
CLIでは-dでデータファイルを渡します。
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
これにより、同じシナリオを複数データで繰り返し実行できます。固定された記録に依存せず、テストデータをGitで管理し、レビューし、新しいエッジケースを追加できます。詳細はデータ駆動型テストガイドを参照してください。
ステップ5：apidog runをCIに組み込む
Keployのkeploy testに相当するCI実行ステップは、Apidogではapidog runです。
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
このコマンドで行うことは次のとおりです。
- 指定したテストシナリオまたはコレクションを実行
-
-eで環境を切り替え - 必要に応じて
-dでテストデータを適用 - CLI、HTML、JSONなどのレポートを出力
-
--upload-reportでクラウドレポートを生成
CIでは、基本的に次の流れになります。
- Apidog CLIをインストールする
-
APIDOG_ACCESS_TOKENをCIのシークレットに登録する - シナリオIDまたはコレクションIDを指定する
-
apidog runを実行する - 失敗時の非ゼロ終了コードでビルドを落とす
GitHub Actionsなどの具体的なYAMLは、CI/CDパイプラインガイドとGitHub Actionsウォークスルーが参考になります。レポートの見方はテストレポートガイドで確認できます。
ステップ6：制御可能なモックサーバーを作る
Keployは、記録時に依存関係トラフィックをキャプチャすることでモックを生成します。Apidogでは、インポートしたスキーマをもとにモックサーバーを設計します。
Apidogのモックでは、たとえば次のような要素を制御できます。
- レスポンスボディ
- フィールド値
- ステータスコード
- エラーケース
- レイテンシ
- 特定条件ごとのレスポンス
これはKeployの「実際に依存先が返したもの」とは異なります。Apidogのモックは「依存先がこう振る舞うべき」という契約を明示するためのものです。
安定したCIや契約テストでは、制御可能なモックのほうが扱いやすい場面があります。背景は契約テストとモックツールとOpenAPIスキーマからのモックデータ生成で詳しく説明されています。
移行で得るものと失うもの
移行前に、チームでトレードオフを明確にしておきましょう。
失うものは、Keployの自動キャプチャです。keploy recordで実トラフィックを記録し、依存関係モックを自動生成する仕組みはApidogにはありません。ランタイムキャプチャが中核要件なら、その用途ではKeployを使い続けるべきです。
得られるものは、次のような運用しやすさです。
- 読めるテストシナリオ
- レビュー可能なアサーション
- 明示的に切り替えられる環境
- Gitで管理できるテストデータ
- 設計されたモックサーバー
- API設計、デバッグ、ドキュメント、テストをまとめたワークスペース
作成コストは記録ベースより高くなります。ただし、チーム全体で保守するテストとしては、意図が明確なぶん長期運用しやすくなります。
APIテスト自動化全体の選択肢はAPIテスト自動化ツールで整理されています。Apidogでの実践手順はApidogでAPIをテストする方法も参考になります。
KeployとApidogを並べて比較したい場合は、Apidog vs Keployの比較を確認してください。Keploy以外の選択肢も含めて検討するなら、最高のKeploy代替案も役立ちます。
よくある質問
Apidogは既存のKeployレコーディングをインポートできますか？
直接はできません。Keployのレコーディングはランタイムキャプチャであり、ApidogはAPI仕様から動作します。現実的には、OpenAPI、Postman、cURLのいずれかでAPIサーフェスを表現し、それをApidogにインポートします。Keployのレコーディングは、カバーすべきエンドポイントのチェックリストとして使います。
ApidogはKeployのようにライブトラフィックを記録してDBを自動モックしますか？
いいえ。ApidogはeBPFでトラフィックをキャプチャせず、実行時の依存関係モックを自動生成しません。それはKeployの明確な強みです。Apidogでは、スキーマからテストやモックを生成し、その上にチームがシナリオを作成します。
keploy recordとkeploy testの代わりは何ですか？
keploy recordに直接相当する機能はありません。代わりに、OpenAPI、Postman、cURLをインポートし、AIで初期テストを生成し、重要シナリオを作成します。実行はkeploy testではなくapidog runで行います。
追加のオーサリング作業をする価値はありますか？
プルリクエストで読みやすく、レビュー可能で、チーム全体で所有できるテストが必要なら価値があります。一方で、依存関係モックを含む実際のランタイム挙動をゼロに近い労力でキャプチャしたいなら、Keployを使い続けるほうが適しています。
KeployとApidogを併用できますか？
できます。キャプチャベースの回帰チェックにはKeployを使い、設計されたE2Eシナリオ、APIドキュメント、モック、CI実行にはApidogを使う構成も現実的です。両者は解決する問題が異なります。
まず何から始めるか
最初から全サービスを移行しないでください。まず1つのサービスを選び、次の順序で進めます。
- OpenAPI仕様をエクスポートする
- Apidogにインポートする
- AIで初期テストケースを生成する
- 重要な業務フローを1つシナリオ化する
- staging環境を設定する
- 小さなCSV/JSONデータを用意する
-
apidog runでローカル実行する - CIに組み込む
このサイクルが機能すれば、対象エンドポイントやサービスを段階的に広げます。記録の手軽さは減りますが、チームが読み、変更し、信頼できるテストを構築できます。
CLIから始める場合は、インストールガイドとコマンドラインREST APIテストのウォークスルーを読むと、実装に入りやすくなります。
Top comments (0)