CI/CD向けAPIテスト自動化ツール10選

APIは手元のマシンでは動作します。しかし、チームメイトが変更をマージし、レスポンスフィールドの名前が変更され、深夜2時に3つのダウンストリームサービスが本番環境で停止しました。誰かがGUIで「送信」をクリックするのを忘れたときにだけテストが実行されたため、誰もそれに気づきませんでした。リクエストを作成してから、すべてのコミットで実際に実行するまでのそのギャップを埋めるために、APIテスト自動化ツールが存在します。

大変なのは1つのテストを書くことではありません。大変なのは、プルリクエストごとに実行され、契約が破られたときにビルドを失敗させ、人間が10秒で読めるレポートを提供するように、スイート全体をパイプラインに組み込むことです。選択するツールによって、その組み込み作業のどれだけを手作業で記述し、どれだけをツールに任せるかが決まります。コードですべてをスクリプト化させるものもあれば、ビジュアルエディターを提供するものの、CI/CDの境界で立ち往生してしまうものもあります。

button

CI/CDに適したAPIテスト自動化ツールとは

リストの前に、基準を説明します。ツールは、これらのことをうまく実行できる場合に、パイプラインでの位置を確立します。

ヘッドレス実行。 コマンドラインまたはDockerイメージから、GUIなし、手動クリックなしで実行され、パイプラインが読み取れる実際の終了コードを返します。
機械可読なレポート。 CIダッシュボードがテストごとの合否を表示できるようにJUnit XMLを、人間やダッシュボード用にHTMLまたはJSONを生成します。
環境処理。 テストを編集することなく、開発、ステージング、本番環境間でベースURL、トークン、変数を切り替えることができます。
データ駆動型実行。 CSVまたはJSONファイルを供給し、多くの入力に対して同じシナリオを実行します。
実際の問題を検出するアサーション。 単に「200を返したか」だけでなく、ステータスコード、レスポンスボディ、JSONスキーマ、レスポンスタイムを検証します。
低いメンテナンスコスト。 APIが変更されたときでも、テストの更新が大量のコードを書き直すことを意味しないようにします。

このチェックリストを手元に置いておきましょう。以下のすべてのツールは、これに基づいて評価されます。

1. Apidog

ApidogはオールインワンのAPIプラットフォームで、設計、デバッグ、モック、ドキュメント化、テストを1つのワークスペースで行えます。テスト自動化に関して重要なのは、ビジュアル側とコマンドライン側がどのように連携するかです。定型コードを書くことなく、ビジュアルでテストシナリオを構築し、リクエストを連結し、ステップ間でデータを渡し、アサーションを追加します。次に、npmパッケージであるApidog CLIが、その正確なシナリオをパイプラインでヘッドレスに実行します。

この継続性がセールスポイントです。ほとんどのツールでは、ある場所で設計し、CI/CD用にテストをコードで再表現します。Apidogでは、手動でデバッグしたシナリオが、パイプラインで実行される成果物となります。変換ステップも、「ローカルでテストしたもの」と「コミット時に実行されるもの」との間にずれもありません。

パイプラインへの組み込みは数分で完了します。CLIをインストールし、IDでシナリオを実行します。

npm install -g apidog-cli
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r html,cli

これらのIDを覚える必要はありません。アプリでテストシナリオを開き、CI/CDタブに切り替え、コマンドラインオプションを選択し、アクセストークンを生成すると、ApidogがシナリオIDと環境IDを既に入力した完全なコマンドを構築します。これをパイプラインステップにコピーすれば完了です。

これらのフラグは、上記のCI/CDチェックリストに直接対応しています。単一のシナリオには-t、フォルダーには-f、厳選されたテストスイートには--test-suiteでスコープを選択します。-eでターゲット環境を選択します。-dでデータファイルからイテレーションを実行します。-rでレポーターを選択し、junitはCIダッシュボードにフィードし、htmlは閲覧可能なレポートを提供します。--on-errorで失敗時の動作を制御し、endは最初の失敗ステップで即座に中断します。実際のパイプラインステップは次のようになります。

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -r html,junit --out-dir ./test-reports \
  --on-error end

GitHub Actionsのワークフローでは、それは単一のジョブステップになります。CLIのキャッシュとレポートの成果物としてのアップロードを含む完全なセットアップは、Apidog CLIとGitHub Actionsのガイドで説明されています。

Apidogが適しているケース: 設計から自動テストまで一元的な情報源を求めるチーム、スクリプトよりもビジュアルエディターでテストを管理したい人々。QAエンジニア全員がJavaScriptに精通しているわけではない場合、これは多くのハードルを下げます。APIテストにおけるApidogとPostmanの比較で並べて見てください。

あまり適していないケース: チームがすべてのテストをリポジトリ内のコードとして保持し、他のソースファイルと同様にプルリクエストでレビューすることにコミットしている場合、コードファーストのフレームワークの方がワークフローに合うかもしれません。Apidogはシナリオをプラットフォーム内に保存しますが、Gitブランチとの同期は可能です。

2. Postman + Newman

Postmanは、多くの開発者が最初に手にするツールであり、それには十分な理由があります。リクエストビルダーは非常に優れており、コレクション形式は業界標準であり、ドキュメントとモック機能は成熟しています。自動化のためには、PostmanをそのコマンドラインコレクションランナーであるNewmanと組み合わせます。

NewmanはPostmanコレクションをヘッドレスで実行し、レポーターパッケージを介してJUnit XMLを含むレポートを出力します。ワークフローは、Postman GUIで構築・デバッグし、コレクションをエクスポートまたは同期し、CIでNewmanを使用して実行するというものです。

npm install -g newman
newman run my-collection.json -e staging.postman_environment.json \
  -r cli,junit --reporter-junit-export results.xml

Postmanが優れている点: 巨大なエコシステム、豊富なチュートリアル、ほとんどすべてのAPIチームが既にコレクションを持っていること。Newmanは安定しており、よく理解されています。

ぎこちない点: アサーションは各リクエストの「テスト」タブ内のJavaScriptに記述されるため、簡単な検証以上のことを行うにはスクリプトの記述とメンテナンスが必要です。チーム全体でGUIコレクションとエクスポートされたJSONを同期させるには規律が必要です。コレクションが大きくなるにつれて多くのチームが壁にぶつかります。もしそうなら、Postmanの代替ツールまとめとPostmanを使わないAPIテストでオプションを検討してください。

3. REST Assured

REST Assuredは、RESTサービスをテストするためのJava DSLです。バックエンドが既にJavaで、チームがJUnitとMavenまたはGradleを使用している場合、これは自然な選択肢です。テストは流れるように記述できます。

given()
    .header("Authorization", "Bearer " + token)
.when()
    .get("/v1/orders/42")
.then()
    .statusCode(200)
    .body("status", equalTo("shipped"));

優れている点: JVMテストライフサイクルに直接組み込まれるため、既に利用しているビルドツールでCIで実行でき、レポートはSurefireと既存のダッシュボードを通じて流れます。流れるような構文は読みやすく、表現力豊かです。

ぎこちない点: Java専用であり、実際のコードを記述・保守する必要があります。ビジュアルエディターがないため、Javaを書かないQA担当者は参加できません。ファイルを単に実行するCLIよりもセットアップが煩雑です。

4. Playwright

Playwrightはブラウザのエンドツーエンドテストで最もよく知られていますが、そのAPIRequestContextにより、APIテストランナーとしても信頼性が高く、特に1つのスイートでUIとAPIのチェックを組み合わせる必要がある場合に役立ちます。多言語（TypeScript、Python、Java、.NET）に対応し、ツールは洗練されています。

import { test, expect } from '@playwright/test';

test('order is created', async ({ request }) => {
  const res = await request.post('/v1/orders', {
    data: { sku: 'A-100', qty: 2 },
  });
  expect(res.status()).toBe(201);
});

優れている点: APIとUIテストの両方を1つのフレームワークで、並行実行可能、ファーストパーティのGitHub Actionsサポートによる強力なCI機能。トレースビューアはデバッグに非常に役立ちます。

ぎこちない点: コードファーストであり、ブラウザテスト用に構築されているため、純粋なAPIスイートには不要なフレームワークの重みがかかります。他のコードランナーとの比較については、CI/CDでAPIテストを自動化する方法を参照してください。

5. Karate

Karateは、独自のGherkinスタイルの構文を持つ専用のAPIテストフレームワークです。そのため、テストはほとんど平易な英語のように読め、プログラミングの知識がなくても作成できます。

Scenario: fetch a user
  Given url 'https://api.example.com'
  And path 'users', 7
  When method get
  Then status 200
  And match response.name == 'Ada Lovelace'

優れている点: JSONとXMLの組み込みアサーション、データ駆動型テスト、並列実行、組み込みレポート機能。JVM上で動作しますが、Javaを書く必要はありません。契約テストとモックが1つのツールでサポートされています。

ぎこちない点: GherkinとJavaScriptを組み合わせた構文は、習得に独自の学習曲線があり、複雑なフローのデバッグは煩雑になる可能性があります。MavenまたはGradleを通じて実行されるため、JVMツールが前提条件となります。

6. SoapUI / ReadyAPI

SoapUIは、SOAPおよびRESTテストのための長年のツールであり、テストケースを構築するためのGUIを備えています。ReadyAPIは、大規模なチーム向けの追加機能を備えた有料の商用版です。オープンソースのSoapUIは、testrunnerコマンドラインユーティリティを介してCIで実行されます。

優れている点: SOAPおよびWSDLの強力なサポート。これは、他のツールが弱いエンタープライズおよびレガシー環境で依然として重要です。有料版では、データ駆動型テストとセキュリティスキャンが成熟しています。

ぎこちない点: インターフェースが古く感じられ、無料版はReadyAPIよりも著しく機能が制限されています。Javaベースのランナーは重い場合があります。これを検討するチームは、しばしばReadyAPIとJenkinsの代替を評価します。

7. k6

k6はロードテストとパフォーマンスを目的として構築されており、JavaScriptでスクリプト化され、Goベースのエンジンから実行されます。第一に機能テストツールではありませんが、パフォーマンス実行に機能チェックを追加することは可能であり、推奨されます。多くのチームがパイプラインで両方にこれを使用しています。

import http from 'k6/http';
import { check } from 'k6';

export default function () {
  const res = http.get('https://api.example.com/health');
  check(res, { 'status is 200': (r) => r.status === 200 });
}

優れている点: 優れたパフォーマンスとロードテスト、クリーンなスクリプトモデル、CI向けに作られた強力なCLI。スレッショルドにより、リクエストエラーだけでなく、レイテンシが悪化したときにビルドを失敗させることができます。

ぎこちない点: 機能アサーションは専用のテストツールと比較して基本的であるため、代替というよりも補完的なものです。ロードテストが焦点である場合、他のAPIロードテストツールと比較してください。

8. Schemathesis

Schemathesisは異なるアプローチを取ります。OpenAPIまたはGraphQLスキーマを指すと、人間が考えることのないエッジケースを含め、テストケースを自動的に生成します。これはコマンドラインから実行されるPythonツールです。

pip install schemathesis
schemathesis run https://api.example.com/openapi.json --checks all

優れている点: プロパティベースのテストは、予期しない入力をエンドポイントに投げかけることで実際的なバグを発見し、スキーマがすべてを駆動するため、テスト作成はほとんど必要ありません。CIでクリーンに実行され、契約違反を検出する能力が非常に高いです。

ぎこちない点: スキーマが記述する内容のみをテストするため、テストの品質は仕様の品質に依存します。手動で作成されたビジネスフローシナリオ向けには設計されておらず、出力の解釈には学習が必要です。

9. Hoppscotch

Hoppscotchは軽量でオープンソースのAPIクライアントであり、しばしば重いデスクトップツールに代わる高速なブラウザベースの代替として説明されます。CLI (hopp) を持ち、CIでコレクションを実行できます。

npm install -g @hoppscotch/cli
hopp test my-collection.json

優れている点: 無料、オープンソース、高速ロード、セルフホスト可能で、すべてを社内で管理したいチームに適しています。CLIによりコレクションの実行をパイプラインに組み込むことができます。

ぎこちない点: 既存のツールに比べて新しく、機能の深さが劣ります。CLIと自動化の機能はまだ成熟途上にあり、目的別に構築されたテストプラットフォームよりも複雑なデータ駆動型シナリオの表現が困難です。

10. Bruno

BrunoはオープンソースのAPIクライアントで、特徴的な設計思想を持っています。コレクションはプレーンテキストファイル（Bruというマークアップ形式）としてGitリポジトリに直接保存されるため、テストは他のソースファイルと同様にバージョン管理されます。そのCLIはCIでコレクションをヘッドレスに実行します。

npm install -g @usebruno/cli
bru run --env staging

優れている点: Gitネイティブで、ファイルがリポジトリにあるモデルは、クラウド同期なしでプルリクエストですべてのテストをレビューしたいチームにクリーンに適合します。オフラインファーストでプライバシーに配慮しており、CLIはパイプラインに簡単に統合できます。

ぎこちない点: アサーションはスクリプトに依存しており、Bruフォーマットはもう一つ学習すべきものであり、周辺エコシステム（モック、ドキュメント、大規模チームコラボレーション）はオールインワンプラットフォームよりも劣ります。これは普遍的な選択肢というよりも、特定の哲学に強く合致するツールです。

クイック比較

ツール	アプローチ	最適なケース	CI/CDランナー
Apidog	ビジュアルデザイン + CLI	設計からテスト済みまで一貫した情報源	`apidog run`
Postman + Newman	GUI + JSスクリプト	既にPostmanを利用しているチーム	`newman run`
REST Assured	Java DSL	JVMバックエンド、コードファースト	Maven/Gradle
Playwright	多言語コード	API + UIテストの混合スイート	`playwright test`
Karate	Gherkin DSL	JVM上の読みやすいテスト	Maven/Gradle
SoapUI / ReadyAPI	GUI	SOAPとレガシーエンタープライズ	`testrunner`
k6	JSスクリプト	ロード + パフォーマンス	`k6 run`
Schemathesis	スキーマ駆動型	自動生成される契約テスト	`schemathesis run`
Hoppscotch	軽量クライアント	セルフホスト型、オープンソース	`hopp test`
Bruno	Gitネイティブファイル	コードとしてレビューされるテスト	`bru run`

選び方

唯一の勝者というものはありません。適切なツールは、あなたのスタックと誰がテストを作成するかによって異なります。

チームが言語に精通しており、すべてのテストをリポジトリに保存し、プルリクエストでテストをレビューしたい場合は、**コードファーストのフレームワーク**（REST Assured、Playwright、Karate）を選択してください。コストはメンテナンスです。APIが変更されるたびに、誰かがコードを更新します。

**スキーマまたはロードの専門ツール**（Schemathesis、k6）は、戦略全体ではなく、補完的なものとして選択してください。彼らはその特定の仕事においては優れていますが、それ以外の点では弱いです。

QAと開発者が同じ場所でテストを構築し、手動でデバッグしたテストがパイプラインで実行されるものと全く同じであることを望む場合は、Apidogのような**ビジュアル+CLIプラットフォーム**を選択してください。これにより、他のほとんどのツールが残している設計からCIまでのギャップが解消され、設計、モック、ドキュメントを同じワークスペースでカバーできます。自動化の側面を詳しく見るには、Apidogテストスイートガイドをお読みください。組み込む準備ができたら、Apidogをダウンロードし、GitHub ActionsのチュートリアルまたはJenkins統合ガイドに従ってください。

何を選択するにしても、目標は同じです。すべてのコミットで実行され、契約違反があった場合にビルドを失敗させ、何が問題だったかを数秒で人間に伝えるテストです。

button

よくある質問

APIテストとAPIテスト自動化の違いは何ですか？

APIテストとは、エンドポイントが正しく動作するか（正しいステータスコード、正しいボディ、正しいエラー処理など）を確認することです。APIテスト自動化とは、これらのチェックを、誰かが「送信」をクリックすることなく、スケジュールに基づいて、またはすべてのコミットで自動的に実行することです。自動化は、一度きりのチェックをセーフティネットに変えるものです。適切なAPIテスト自動化のセットアップは、すべてのプルリクエストで同じテストを実行します。

APIテストを自動化するためにコードを書く必要がありますか？

いいえ、常に必要ではありません。REST AssuredやPlaywrightのようなコードファーストのフレームワークでは必要ですが、Apidogのようなビジュアル+CLIツールでは、エディタでテストシナリオを構築し、CIでヘッドレスに実行できます。一般的なアサーションのためにスクリプトを記述する必要はなく、シナリオでカスタムロジックが必要な場合にのみコードを使用します。

これらのツールはGitHub ActionsやJenkinsで実行できますか？

はい。このリストのすべてのツールは、コマンドラインランナーまたはビルドツールプラグインを提供しており、これはCIシステムが必要とするすべてです。ランナーをインストールしてテストを実行するステップを追加し、JUnitレポートを公開することで、ダッシュボードがテストごとの合否を表示するようにします。GitHub Actionsガイドで完全な例をご覧ください。

専任のQAエンジニアがいないチームに最適なツールはどれですか？

ビジュアルツールは、開発者が別のテストフレームワークを学ぶことなくテストを構築および維持できるため、最も敷居が低くなります。ApidogやGUIベースのクライアントがこれに該当します。コードファーストのフレームワークは、チームの誰かがテストコードの記述とレビューに慣れていることを前提としています。

APIテスト自動化の無料オプションはありますか？

はい。Newman、REST Assured、Playwright、Karate、k6、Schemathesis、Hoppscotch、Brunoはオープンソースであり、Apidogには無料プランがあります。無料APIテストツールのまとめでは、それぞれの無料プランに実際に何が含まれているかについて詳しく説明しています。

APIが変更されるたびに自動テストが壊れるのを防ぐにはどうすればよいですか？

重複を減らし、アサーションを絞り込んでください。すべてのレスポンスのすべてのバイトではなく、コンシューマーにとって重要なフィールドをテストします。スキーマ駆動のツールは、仕様が変更されると自動的に更新され、ビジュアルツールはコードを書き直すよりも迅速に小さな編集を可能にします。APIテストのベストプラクティスに従って、メンテナンスを低く抑えてください。