Pactは、コンシューマー主導のコントラクトテスト（CDC）で広く使われるツールです。コンシューマーがテストからpactファイルを生成し、プロバイダーが実装に対してそれを検証します。Pact Brokerは検証結果を管理し、can-i-deployでデプロイ可否を判定します。この仕組みは統合時の不整合を検出する一方で、言語ごとのDSL、プロバイダー状態、Broker運用、再現しにくい検証失敗といった運用コストも増やします。スキーマのずれを防ぐことが主目的なら、単一のOpenAPI仕様を中心に検証・モック・CIを構成する方が実装と保守を単純化できます。
実際の課題がプロデューサーとコンシューマー間のスキーマのずれである場合、ApidogはPactの実用的な代替候補になります。Pactのようなコンシューマー主導のBrokerワークフロー、pactファイル、検証マトリックス、can-i-deployは提供しません。代わりに、OpenAPI仕様を単一のコントラクトとして扱い、モック、レスポンス検証、テストシナリオ、CI実行をその仕様に集約します。
Pactが実際にしていること
PactはHTTPおよびメッセージ統合を対象とするコードファーストのコントラクトテストツールです。
基本フローは次のとおりです。
- コンシューマーがPactモックプロバイダーに対するテストを書く
- テスト実行時にリクエスト・レスポンスのインタラクションをpactファイルへ記録する
- プロバイダーがpactファイルを取得する
- プロバイダーの実装に対してインタラクションをリプレイする
- 検証結果をBrokerへ公開する
-
can-i-deployで対象バージョンのデプロイ可否を確認する
コンシューマーが実際に利用するフィールドだけをpactに記録できる点は、Pactの重要な強みです。プロバイダーは未使用フィールドを変更でき、コンシューマーが依存する振る舞いだけを守れます。
Pact Brokerは、コンシューマーとプロバイダーの検証済みバージョンの組み合わせを管理します。can-i-deployの終了コードは通常、次の意味で利用されます。
can-i-deploy \
--pacticipant provider-service \
--version "$GIT_SHA" \
--to-environment production
- 終了コード
0: デプロイ可能 - 終了コード
1: デプロイ不可
PactはJVM、JavaScript、Go、.NET、Python、Ruby、Rust、PHP、Swiftなど、多数の言語に対応しています。Brokerを自前運用する代わりに、PactFlowのようなマネージドBrokerを利用する選択肢もあります。
Pact運用で負担になりやすいポイント
Pactの問題はテストそのものではなく、継続的にループを運用するための負荷です。
各コンシューマーがDSLコードを保守する
Pactはテストコードからコントラクトを生成します。そのため、各コンシューマーチームは利用言語に対応するPact DSLを習得し、モック設定・マッチングルール・アサーションを保守する必要があります。
多言語の組織では、同じコントラクトルールを複数のDSLで実装することになります。
プロバイダー状態が増え続ける
Pactの検証では、各インタラクションに必要なデータを用意するため、プロバイダー状態を実装する場合があります。
たとえば、次のような状態です。
ユーザー42が未払い請求書を持つ
コンシューマーやインタラクションが増えるほど、プロバイダー側では状態ハンドラー、テストデータ、認証スタブ、初期化ロジックの管理コストが増加します。
Brokerが追加インフラになる
Brokerをセルフホストする場合は、少なくとも以下の運用が必要です。
- データベース管理
- 認証・認可
- バージョンアップ
- CIとの連携
- Webhook設定
- ブランチ・環境・保留中pactの運用ルール
PactFlowを使えばサーバー運用は減らせますが、Brokerという独立した仕組みとワークフロー自体は残ります。
プロバイダー検証の失敗が調査しにくい
プロバイダー検証では、コンシューマーが記録したリクエストを実装へリプレイします。そのため、検証環境には以下のような依存が入りやすくなります。
- データベースシード
- 外部認証のスタブ
- バックグラウンドジョブ
- キャッシュ
- 非同期処理
- 環境固有の設定
失敗したpactが別チームによって作成されている場合、プロバイダーチームが原因を追跡しにくくなります。検証失敗が増えると、CIチェックをスキップする運用につながるリスクもあります。
PactFlowの双方向コントラクトテストは、この負担を軽減するアプローチです。プロバイダーのOpenAPIドキュメントとコンシューマー側のコントラクトを静的比較し、リプレイを省略します。
これは、多くのAPI統合では実行時リプレイよりスキーマ比較が重要であることを示しています。詳しくは双方向コントラクトテストも参照してください。
Apidogで置き換えられる部分
Apidogは、OpenAPI仕様を中心にAPI設計、ドキュメント、モック、テスト、検証を管理するAPI開発プラットフォームです。
Pactの代替として考える場合、基本方針は次のとおりです。
仕様をコントラクトとし、開発・テスト・CIで機械的に強制する。
APIコントラクトテストの観点では、実装すべきポイントは4つです。
- OpenAPI仕様を単一のコントラクトにする
- 実行ごとにレスポンスを仕様へ照合する
- 仕様からモックを提供する
- CIでテストシナリオを実行する
1. 1つのコントラクト、DSLは不要
Pactではコンシューマーごとにpactファイルが生成されます。
Apidogでは、OpenAPI仕様を共有コントラクトとして管理します。
openapi: 3.0.3
info:
title: Billing API
version: 1.0.0
paths:
/invoices/{id}:
get:
responses:
"200":
description: Invoice found
content:
application/json:
schema:
type: object
required:
- id
- status
- amount
properties:
id:
type: string
status:
type: string
enum: [paid, unpaid]
amount:
type: number
この仕様をレビュー対象にすれば、フィールド名、型、必須項目、列挙値、エラー形式の変更をコードレビュー段階で確認できます。
2. スキーマ検証をすべての実行で有効にする
仕様に対するレスポンス検証を有効にすると、以下のような変更を検出できます。
-
amountがnumberからstringに変わった - 必須フィールドが削除された
-
statusに未定義の値が返る - エラー応答のJSON構造が変わった
重要なのは、個別のアサーションを書かなくても、仕様に反するレスポンスを失敗として扱えることです。
これは、多くのチームがPactに期待している「ずれ検出」を、仕様ベースで実装する方法です。
3. コンシューマーを仕様ベースのモックへ接続する
Apidogのスマートモックを使うと、エンドポイント定義後に仕様に沿ったモックレスポンスを提供できます。
コンシューマー側では、Pact DSLでモックプロバイダーを作る代わりに、モックURLを環境変数として設定します。
API_BASE_URL=https://mock.example.com
フロントエンドやダウンストリームサービスは、プロバイダーの実装完了を待たずに開発を開始できます。
特定のケースが必要なら、カスタム期待値を使ってレスポンスを調整できます。仕様駆動モックと手作業モックの違いは、コントラクトテストとモックサーバーで確認できます。
4. CIでコントラクト検証を実行する
Apidog CLIでは、テストシナリオをCIから実行できます。
apidog run --config apidog.config.json
GitHub Actionsでは、たとえば次のように組み込みます。
name: API contract test
on:
pull_request:
push:
branches: [main]
jobs:
contract-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run API scenarios
run: apidog run --config apidog.config.json
実際の設定値や認証情報は、利用するApidogプロジェクトとCI環境に合わせて管理してください。
この構成では、仕様を破るプロバイダー実装を、そのサービス自身のCIで止められます。Pactのマトリックス判定とは異なりますが、「破壊的変更をデプロイ前に検出する」という目的には対応できます。
PactからApidogへ移行する実装手順
pactファイルを単純変換するのではなく、OpenAPI仕様を正式なコントラクトへ昇格させます。
1. OpenAPI仕様を用意する
既にOpenAPI仕様がある場合は、Apidogへインポートします。
仕様がない場合は、以下を材料にして作成します。
- 実装コードのアノテーション
- 既存のAPIドキュメント
- Postmanコレクション
- 現在のpactファイル
- 実際の通信ログ
pactファイルは「コンシューマーが何を利用しているか」のチェックリストとして役立ちます。ただし、移行後の中心成果物はpactではなくOpenAPI仕様です。
2. 破壊的変更を仕様差分としてレビューする
仕様はGitで管理し、変更をPull Requestでレビューします。
特に次の変更は破壊的変更候補として確認します。
- 必須フィールドの追加
- 必須フィールドの削除
- フィールド型の変更
- enum値の削除
- エンドポイント削除
- ステータスコード変更
- エラー形式変更
# 変更前
status:
type: string
enum: [paid, unpaid, overdue]
# 変更後: overdue を削除
status:
type: string
enum: [paid, unpaid]
overdueを利用しているコンシューマーが存在する可能性があるため、このような変更は明示的にレビューすべきです。
3. プロバイダーのテストシナリオを作成する
主要エンドポイントについて、成功ケースと代表的な失敗ケースをテストシナリオとして定義します。
最低限、次のケースをカバーします。
| 種別 | 例 |
|---|---|
| 正常系 |
200 OKで仕様どおりのレスポンスを返す |
| 入力エラー |
400 Bad Requestのエラー形式が仕様どおり |
| 認証エラー |
401 Unauthorizedまたは403 Forbidden
|
| 未存在リソース | 404 Not Found |
| 境界値 | 空文字、最大長、未定義enumなど |
各シナリオでレスポンススキーマ検証を有効にし、CIで継続的に実行します。
4. コンシューマーをモックURLへ切り替える
コンシューマーごとのPactモック設定を、共有されたモックURLへ段階的に置き換えます。
const apiBaseUrl =
process.env.API_BASE_URL ?? "https://api.example.com";
const response = await fetch(`${apiBaseUrl}/invoices/42`);
ローカル開発、PRレビュー環境、統合テスト環境で接続先を切り替えられるようにしておくと移行しやすくなります。
5. Brokerは最後に廃止する
すべての統合を一度に切り替える必要はありません。
以下のように段階的に進めます。
- OpenAPI仕様とCI検証を導入する
- 低リスクなコンシューマーをスマートモックへ移行する
- Pact検証とApidog検証を並行運用する
-
can-i-deployが実際に必要な統合だけを残す - 不要になったpact・状態ハンドラー・Broker依存を削除する
Pact + PactFlow と Apidog の比較
| 項目 | Pact + PactFlow | Apidog |
|---|---|---|
| コントラクト成果物 | コンシューマーごとのpactファイル | 単一のOpenAPI仕様 |
| コントラクトコード | 各コンシューマーが言語別DSLで作成 | 仕様をビジュアルまたはコードで編集 |
| プロバイダー検証 | インタラクションのリプレイとプロバイダー状態 | テストシナリオと自動スキーマ検証 |
| コンシューマーモック | テスト内モックプロバイダー | 仕様から生成するホスト型スマートモック |
| ずれ検出 | プロバイダー検証時 | リクエスト実行・テスト・CI実行時 |
| デプロイゲート | Brokerマトリックスとcan-i-deploy
|
サービスごとのコントラクト検証CI |
| 追加インフラ | BrokerまたはPactFlow | 追加Brokerなし |
| ドキュメント・設計 | 主な対象外 | 対話型ドキュメント、仕様エディター |
| 料金 | PactはOSS、PactFlowはプランによる | 4ユーザーまで無料、有料プランは月額9ドル/ユーザーから |
コストを比較するときのポイント
Pactライブラリ自体はオープンソースで無料です。ただし、実際のコストには以下が含まれます。
- BrokerのホスティングまたはPactFlow利用料
- コンシューマーごとのDSLテスト実装
- プロバイダー状態ハンドラーの保守
- 検証失敗時のチーム間調査
- バージョン・環境・ブランチ運用の教育
Apidogでは、仕様編集、モック、テストシナリオ、スキーマ検証、CLI実行を同じプラットフォームで扱えます。無料プランは4ユーザーまで利用でき、有料プランは月額9ドル/ユーザーからです。
比較すべきなのはライセンス費用だけではありません。
- コントラクトテスト専用の運用基盤を維持したいか
- API設計、ドキュメント、モック、検証を統合したいか
- コンシューマー単位のデプロイ判定が必要か
- スキーマの破壊的変更をCIで防げれば十分か
Postmanを含めたAPIツールの統合を検討している場合は、最高のPostman代替品も参考になります。仕様ファーストの構成は、コントラクトファースト開発ツールスタックで確認できます。
Pactを維持すべきケース
ApidogはPactのすべてを置き換えるものではありません。特に次の条件では、PactのBrokerマトリックスとcan-i-deployが有効です。
- 多数のチームがサービスを独立してデプロイする
- デプロイ頻度やリリースタイミングがチームごとに異なる
- 特定バージョンが本番の他サービスと互換かを機械的に判定したい
- コンシューマーごとの利用フィールドを厳密に把握したい
- メッセージキューのコントラクトテストを中心に運用している
一方で、課題が主に以下であるなら、OpenAPIベースのワークフローが適しています。
- レスポンススキーマのずれ
- フロントエンド開発用モック
- APIドキュメントの同期
- CIでの破壊的変更検出
- テストDSLやプロバイダー状態の保守削減
よくある質問
ApidogはPactのようなコントラクトテストツールですか？
コントラクトを強制する方法が異なります。
Pactはコンシューマーのテストコードからコントラクトを生成し、プロバイダー実装にリプレイします。ApidogはOpenAPI仕様をコントラクトとして扱い、リクエストやCIテストを仕様に対して検証します。
Brokerマトリックスを使わずにスキーマのずれを防ぎたい場合に適しています。詳細はAPIコントラクトテストを参照してください。
Apidogはcan-i-deployやPact Brokerをサポートしていますか？
いいえ。ApidogにはPact Brokerのような検証マトリックスやサービス間デプロイゲートはありません。
Apidogでは、仕様に違反する実装を各サービスのCIで失敗させます。マトリックスレベルのデプロイ判定が必須の統合については、Pactを維持する判断が適切です。
ApidogはPactのコンシューマーモックを置き換えられますか？
多くのケースで置き換えられます。
Apidogのスマートモックは、仕様に基づいたレスポンスを生成します。コンシューマーはテスト専用のモックプロバイダーDSLを書く代わりに、共有モックURLへ接続して開発できます。
より広い選択肢は、コントラクトテストとモックツールを参照してください。
仕様に対するプロバイダーのファジングはできますか？
Apidogのシナリオテストと、仕様ベースのプロパティテストツールを組み合わせる方法があります。
たとえば、通常のシナリオテストでは代表的なリクエストを確認し、ファジングでは境界値や不正値を広く生成して検証します。Schemathesisとはでは主要な選択肢を比較しています。
PactFlowの費用はApidogと比較してどれくらいですか？
PactFlowのStarterティアは2つの統合まで無料です。チームプランは50統合で月額127ドル、年間請求では約1,385ドルで、Enterpriseはカスタム価格です。
Apidogは4ユーザーまで無料で、有料プランは月額9ドル/ユーザーからです。キャプチャ・リプレイ型ツールとの比較が必要な場合は、最高のKeploy代替品も参照してください。
儀式を減らし、コントラクトを維持する
Pactの目的がスキーマのずれの検出であるなら、単一のOpenAPI仕様をコントラクトとして運用することで、その目的をより少ない運用負荷で達成できる場合があります。
実装は次の3ステップから始められます。
- OpenAPIファイルをApidogへインポートする
-
apidog runをCIパイプラインへ組み込む - コンシューマーへモックURLを配布する
Apidogをダウンロードするか、ブラウザから開始してください。Brokerマトリックスが本当に必要な統合はPactを維持し、それ以外は仕様ベースの検証へ段階的に移行するのが現実的です。
Top comments (0)