DEV Community

Cover image for Apidog CLI vs Specmatic 比較
Akira
Akira

Posted on • Originally published at apidog.com

Apidog CLI vs Specmatic 比較

仕様ファーストでAPIを構築する場合、最初に決めるべきことは「OpenAPIなどの仕様を実行可能な契約チェックとして使いたいのか」、それとも「設計、モック、機能テスト、CI実行まで一つの流れで扱いたいのか」です。SpecmaticとApidog CLIはどちらも仕様ファーストですが、得意領域が異なります。この記事では、実装時に判断しやすいように、API契約テストの観点と、公式のOpenAPI Specificationを前提に比較します。

今すぐApidogを試す

要約

Specmaticは、API仕様を「実行可能な契約」として扱うツールです。仕様からテストを生成し、実行中のプロバイダーAPIがその契約を満たしているかを検証します。同じ仕様をスタブとして使い、コンシューマー側の開発を先行させることもできます。特に、複数チームがマイクロサービスを独立して開発・デプロイしている環境で有効です。

Apidogは、仕様ファーストのAPIプラットフォームです。OpenAPIに基づいてAPIを設計し、モックを作成し、機能テストシナリオを構築し、apidog runでCI内から実行できます。REST、GraphQL、gRPC、WebSocketなど、複数プロトコルを同じワークフローで扱える点が特徴です。

実務上の判断はシンプルです。

  • サービス間の契約破壊を検出したい: Specmatic
  • APIの設計、モック、機能テスト、CI実行をまとめたい: Apidog CLI
  • 両方の課題がある: OpenAPIを共通ソースとして両方を併用

Specmaticの得意なこと

Specmaticの中心は、仕様を契約として実行することです。OpenAPI、AsyncAPI、GraphQL、gRPC、WSDLなどの仕様ファイルを入力にし、ポジティブケースとネガティブケースを含む契約テストを生成します。

主な用途は次の2つです。

1. プロバイダー検証

プロバイダーAPIを起動し、仕様に対して検証します。

たとえば、OpenAPI上では以下のように定義されているとします。

paths:
  /users/{id}:
    get:
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                type: object
                required:
                  - id
                  - name
                properties:
                  id:
                    type: string
                  name:
                    type: string
Enter fullscreen mode Exit fullscreen mode

実装が誤って name を返さなくなった場合、契約テストで検出できます。

{
  "id": "u_123"
}
Enter fullscreen mode Exit fullscreen mode

このような「仕様では約束しているが、実装が返していない」差分をCIで早期に検出するのがSpecmaticの強みです。

2. サービス仮想化

同じ仕様をスタブとして動かすことで、コンシューマーチームは実際のプロバイダー完成を待たずに開発できます。

典型的な流れは次のとおりです。

  1. OpenAPIなどの契約ファイルをリポジトリに置く
  2. Specmaticでスタブを起動する
  3. フロントエンドや別サービスがそのスタブを呼び出す
  4. プロバイダー実装時には同じ仕様に対して契約テストを実行する

これにより、コンシューマーとプロバイダーが同じ契約を参照し続けられます。

SpecmaticはGitHubでオープンソースとして公開されているコアを持ち、CI/CD向けのCLIとして利用できます。また、StudioやInsightsのような商用レイヤーも提供されています。RESTだけでなく、AsyncAPI、GraphQL、gRPC、WSDL、Kafka、JMS、RabbitMQなどのイベント駆動バックエンドにも対応しています。

ただし、SpecmaticはAPI設計ツールや汎用的なE2E機能テストスイートではありません。仕様を作成・管理する場所は別途必要です。価値を発揮するのは、すでに仕様があり、それを契約として強制したい場合です。

Apidog CLIの得意なこと

Apidog CLIは、Apidogで作成したAPIテストシナリオをコマンドラインから実行するためのランナーです。Apidog上でAPIを設計し、モックやテストを作成し、CIでは apidog run を実行します。セットアップや終了コード、レポートについては、apidog runコマンドリファレンスで確認できます。

Apidogの使い方は、契約検証だけに閉じません。APIライフサイクル全体を扱います。

1. OpenAPIを起点に設計する

まずAPI仕様を作成します。OpenAPIを直接扱う場合、次のような定義が起点になります。

openapi: 3.0.3
info:
  title: User API
  version: 1.0.0
paths:
  /users/{id}:
    get:
      summary: Get user by ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: User found
          content:
            application/json:
              schema:
                type: object
                required:
                  - id
                  - name
                properties:
                  id:
                    type: string
                  name:
                    type: string
Enter fullscreen mode Exit fullscreen mode

Apidogでは、この仕様を視覚的に編集し、同じ定義からモックとテストを作成できます。

2. スキーマ駆動のモックを作る

バックエンドが未完成でも、OpenAPIスキーマからモックサーバーを立ち上げられます。フロントエンドや別サービスは、先にモックに対して実装を進められます。

詳しい考え方は、スキーマファーストのモックワークフローで説明されています。

3. 機能テストシナリオを作る

Apidogでは、単に「レスポンスがスキーマに一致するか」を見るだけでなく、複数ステップのシナリオを作れます。

例:

  1. POST /auth/login でトークンを取得
  2. レスポンスから access_token を変数に保存
  3. GET /users/me に Authorization ヘッダーを付けて実行
  4. ステータスコード、レスポンス値、スキーマを検証

このような連鎖したAPIテストは、純粋な契約チェックよりもE2E寄りの機能テストに近いものです。

4. CIで apidog run を実行する

Apidog CLIは、CIパイプラインからヘッドレス実行できます。

apidog run
Enter fullscreen mode Exit fullscreen mode

GitHub ActionsやGitLab CI、Jenkinsなどでは、テスト実行ステップとして組み込みます。

name: API tests

on:
  push:
    branches:
      - main

jobs:
  api-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Apidog tests
        run: apidog run
Enter fullscreen mode Exit fullscreen mode

実際の認証情報、環境、レポート出力などはプロジェクト設定に合わせて調整します。パイプライン全体の例は、完全なApidog CLIガイドで確認できます。

Apidogは、REST、GraphQL、gRPC、SOAP、WebSocketを同じワークフローで扱えるため、REST以外のAPIも含むチームに向いています。

一方で、ApidogはPactスタイルのコンシューマー駆動契約ブローカーではありません。独立したコンシューマー/プロバイダーリポジトリ間で正式な契約ハンドシェイクを管理したい場合は、Specmaticのほうが適しています。

比較表

項目 Specmatic Apidog CLI
主な重点 コードとしての契約。仕様に対するプロバイダー検証、契約ベースのスタブ 仕様ファースト設計、モック、機能テスト、CI実行
テスト生成 仕様からポジティブ/ネガティブテストを自動生成 シナリオを視覚的に構築。スキーマ検証も利用可能
プロバイダー/コンシューマー契約検証 中核機能 スキーマ検証が中心。契約ブローカーではない
モック 契約からのサービス仮想化 OpenAPI設計からのスキーマ駆動モックサーバー
プロトコル OpenAPI, AsyncAPI, GraphQL, gRPC, WSDL, メッセージング（Kafka, JMSなど） REST, GraphQL, gRPC, SOAP, WebSocket
インターフェース CLI、商用版Studio/Insights ビジュアルアプリ、apidog run CLI
機能/E2Eフロー 契約シナリオ中心 連鎖ステップ、データ駆動実行、アサーションに対応
オープンソース はい（コア部分） 無料枠あり。プラットフォームは商用
最適な用途 独立したサービス間で共有契約との整合性を保つ APIライフサイクル全体で設計、モック、テストを行う

実装時の選び方

Specmaticを選ぶケース

次の課題があるならSpecmaticが向いています。

  • 複数チームが別々のサービスを所有している
  • サービスを独立してデプロイしている
  • API仕様と実装のズレが頻繁に起きる
  • コンシューマーが実プロバイダーを待たずに開発したい
  • 契約違反をCIでブロックしたい

実装パターンは次のようになります。

OpenAPI / AsyncAPI / GraphQL schema
        ↓
Specmaticでスタブ起動
        ↓
コンシューマー開発
        ↓
プロバイダー実装
        ↓
CIで契約検証
Enter fullscreen mode Exit fullscreen mode

Specmaticは、仕様を中心にしてコンシューマーとプロバイダーの整合性を保つためのフィードバックループを作ります。

Apidog CLIを選ぶケース

次の課題があるならApidog CLIが向いています。

  • OpenAPIベースでAPIを設計したい
  • バックエンド完成前にモックを提供したい
  • 複数リクエストを連鎖させた機能テストを作りたい
  • テストをCIで自動実行したい
  • REST以外にGraphQL、gRPC、WebSocketなども扱いたい
  • 設計、モック、テストを別々のツールに分散させたくない

実装パターンは次のようになります。

ApidogでAPI設計
        ↓
OpenAPIベースのモック生成
        ↓
機能テストシナリオ作成
        ↓
apidog runでCI実行
Enter fullscreen mode Exit fullscreen mode

設計、モック、検証の連携については、契約テストとモックサーバーのガイドも参考になります。

両方を一緒に使うことはできますか？

はい。むしろ、仕様ファーストを徹底するチームでは自然な構成です。

共通のOpenAPIファイルを信頼できる情報源として扱います。

OpenAPI
  ├─ Apidog: 設計、モック、機能テスト、CI実行
  └─ Specmatic: プロバイダー契約検証、サービス仮想化
Enter fullscreen mode Exit fullscreen mode

具体的には、次のように分担できます。

  1. ApidogでOpenAPIを設計する
  2. Apidogのモックでフロントエンドやコンシューマー開発を進める
  3. Apidogで機能テストシナリオを作る
  4. CIで apidog run を実行する
  5. サービス間契約が重要な箇所ではSpecmaticを追加する
  6. 契約違反があればマージやデプロイを止める

Apidogはライフサイクル全体を広くカバーし、Specmaticはチーム間契約の検証に集中します。両方を使うことで、API開発の速度と契約の厳密性を両立できます。

よくある質問

ApidogはSpecmaticの代替品ですか？

一部の用途では代替になりますが、完全な1対1の置き換えではありません。

APIを設計し、モックを作り、機能テストをCIで実行したいなら、Apidogで広くカバーできます。一方、コンシューマー/プロバイダー間の契約を正式に検証し、契約ベースのサービス仮想化を重視するならSpecmaticが向いています。

Apidog CLIは契約テストを行いますか？

Apidogは、テスト実行時にOpenAPIスキーマに対してレスポンスを検証し、仕様と実装の構造的なズレを検出できます。これは単一APIにおける一般的な契約テストのニーズに対応します。

ただし、Pactスタイルの契約ブローカーとして、独立したコンシューマー/プロバイダーリポジトリ間のハンドシェイクを管理するものではありません。詳しくは、API契約テストとは何かの記事で整理されています。

CI/CDにはどちらが適していますか？

どちらもCIでヘッドレス実行できます。

  • Specmatic: 仕様から契約テストを生成し、プロバイダー検証をCIで実行する
  • Apidog CLI: Apidogで作成した機能テストシナリオを apidog run で実行する

判断基準はCIゲートの目的です。

サービス間契約を壊していないか確認したい → Specmatic
APIの機能テスト全体を実行したい → Apidog CLI
両方必要 → 両方をCIに組み込む
Enter fullscreen mode Exit fullscreen mode

どちらのツールでもテストコードを書く必要がありますか？

多くの場合、手書きのテストコードは減らせます。

Specmaticは仕様から契約テストを生成します。Apidogはビジュアルなシナリオビルダーでリクエスト、アサーション、データ駆動実行を設定できます。コードファーストのテストフレームワークと比べると、どちらも手動実装の量を抑えられます。

結論

SpecmaticとApidog CLIは、どちらも仕様ファーストのAPI開発に役立ちます。ただし、解決する問題が異なります。

Specmaticは、仕様を契約として扱い、プロバイダー検証や契約ベースのスタブを実行するためのツールです。サービス間の契約破壊を防ぐ用途に向いています。

Apidog CLIは、APIの設計、モック、機能テスト、CI実行を一つのワークフローにまとめるためのツールです。apidog run を使えば、Apidogで作成したテストシナリオをパイプラインに組み込めます。

仕様ファースト、モック、CI対応のテストワークフローを一つのプラットフォームで始めたい場合は、Apidogをダウンロードして、OpenAPIベースのテストスイートを実行してみてください。APIライフサイクル全体で何ができるかは、Apidogでも確認できます。

Top comments (0)