SoapUIは2005年からWebサービスのテストで使われ、WSDL駆動のSOAP開発では今も代表的なツールです。ただし2026年に代替を検討するチームの多くは、SOAPだけでなくREST、GraphQL、gRPCも扱っています。XMLコントラクト中心、巨大なXMLプロジェクトファイル、動的な処理をGroovyに集約する構成は、現代のAPI開発フローでは運用負荷になりがちです。
直接的な選択肢としては、Apidogが、RESTや最新プロトコルを扱うAPIチーム向けのSoapUI代替ツールです。Groovyベースの処理を視覚的なテストオーケストレーションに置き換え、スキーマ認識モック、公開ドキュメント、CI実行を1つのワークスペースで扱えます。無料プランは最大4ユーザーまで利用できます。
SoapUIが時代遅れになりやすい理由
SoapUI Open SourceはSmartBearによって現在も保守されており、バージョン5.9は2025年半ばにリリースされました。課題は保守停止ではなく、ツールの設計がSOAP中心であることです。
SOAP/WSDL中心のUI
SoapUIの基本概念は、WSDL、SOAPエンベロープ、XPathアサーションです。RESTは後から追加された機能のため、JSONリクエストやJSONアサーションを扱う際にXML向けの設計が見えます。詳細はSoapUI ProとSoapUI Open Sourceの違いも参照してください。動的なテストロジックがGroovyに集中する
レスポンス値の抽出、次のリクエストへの受け渡し、条件分岐、独自アサーションはGroovyで実装することになります。JVMに慣れたQAエンジニアには強力でも、他のメンバーが読み書きしにくいテストスイートになりやすい構成です。プロジェクトが巨大なXMLファイルになる
SoapUIプロジェクトは1つのXMLドキュメントとして保存されます。同じファイルを複数人で編集するとマージ競合が起きやすく、Gitベースの共同作業にも不向きです。高度な機能は商用製品へ移行している
データ駆動テスト、詳細レポート、CI向け機能はReadyAPI側にあります。SoapUI ProはReadyAPIへ統合され、第三者の価格トラッカーでは年間ライセンスあたり約829ドルからと記載されています。SoapUIの代替品を比較するチームが多い理由の1つです。大規模プロジェクトでは動作が重くなりやすい
Java Swingのデスクトップアプリであり、プロジェクト全体をメモリに読み込みます。大きなテストスイートでは起動時間やUI応答が課題になる場合があります。
毎日WSDLコントラクトを扱うなら、これらは大きな問題ではないかもしれません。一方、テスト対象の大半がRESTやGraphQL、gRPCであるなら、ツールの設計差が日常的なコストになります。
答え: Apidog
Apidogは、50万人以上の開発者に利用されているAPI開発プラットフォームです。API設計、デバッグ、自動テスト、モック、ドキュメント作成を、OpenAPI仕様を中心とした1つのワークスペースで扱えます。
SoapUIから移行する場合は、次の点を確認してください。
テストフローを視覚的に構築できる
エンドポイントを連携し、前のレスポンスから値を取り出し、次のリクエストに渡し、アサーションを設定できます。SoapUIでGroovyに書くことが多い処理を、ドラッグ＆コンフィグで構成できます。スクリプトが必要な場合も、JVM専用ではなくPostman互換の構文を利用できます。無料プランは最大4ユーザーに対応する
API、リクエスト、テスト実行は無制限です。データ駆動テスト、CI統合、共有可能なレポートなどもコア機能として利用できます。最新プロトコルをネイティブに扱える
REST、GraphQL、gRPC、WebSocket、SSEをサポートします。JSONをXML向けUIに合わせるのではなく、JSONとして設計・検証できます。有料プランは月額9ドル/ユーザーから
無料利用からの移行時に、シートごとの大きな年間ライセンス費用を前提にする必要がありません。
実践で変わるポイント
Groovyを書かずにテストロジックを作る
SoapUIでGroovyを書いていた次のような処理を、Apidogではシナリオとして構成できます。
- レスポンスAからIDやトークンを抽出する
- 抽出した値をリクエストBへ渡す
- CSVまたはJSONのデータセットを使って繰り返し実行する
- 条件ごとに分岐する
- ステータス、スキーマ、特定フィールドを検証する
チームで共有・保守するテストでは、コード量を減らすことよりも「誰でも読んで修正できる」ことが重要です。データ駆動テストも、CSVまたはJSONをシナリオに指定して実行できます。
スキーマからモックを生成する
SoapUIのモックサービスは利用できますが、REST APIではレスポンス設定を手作業で用意する必要があり、さらにGroovyが必要になることもあります。SoapUIモックサービス：設定ガイドと最新の代替も参考にしてください。
ApidogのスマートモックはOpenAPIスキーマを読み取り、定義に応じたデータを返します。たとえば、emailフィールドにはメールアドレス形式の値、priceフィールドには数値を生成します。
実装の流れは次のとおりです。
- OpenAPI仕様をインポートする
- 対象エンドポイントのモックを有効化する
- フロントエンドからモックURLへリクエストする
- 必要に応じて固定レスポンスやルールを追加する
仕様ができた時点で、フロントエンドはAPIの実装完了を待たずに作業できます。セルフホスト型モックの選択肢もあり、トラフィックをネットワーク内に保持できます。
同じワークスペースでパフォーマンステストを実行する
SoapUI Open Sourceには基本的な負荷テストがありますが、本格的な機能はReadyAPIで提供されています。Apidogでは機能テストと同じワークスペースでパフォーマンステストを扱えます。
基本的な手順は次のとおりです。
- 既存のAPIテストシナリオを選択する
- 同時実行数などの負荷条件を設定する
- テストを実行する
- レイテンシとスループットを確認する
機能テスト用のシナリオを再利用できるため、別ツールへエクスポートする手順を減らせます。
CIでヘッドレス実行する
Apidog CLIを使うと、シナリオをヘッドレスで実行し、HTMLレポートを出力できます。
npm install -g apidog-cli
apidog run scenario --scenario-id 12345 --env staging
このコマンドは、testrunner.shを使っていたJenkins、GitLab CI、GitHub Actionsのジョブへ組み込めます。コマンドの詳細はApidog CLIでAPIを管理する方法で確認できます。
GitHub Actionsでの最小構成例です。
name: API Test
on:
pull_request:
jobs:
api-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run API scenario
run: apidog run scenario --scenario-id 12345 --env staging
仕様からドキュメントを公開する
SoapUIはテスト成果物を中心に扱います。Apidogでは、API仕様からインタラクティブなドキュメントも生成できます。
- OpenAPI仕様をベースに公開する
- カスタムドメインでホストする
- 「試してみる」コンソールを提供する
- API変更時に仕様とドキュメントを同期する
ドキュメントを別ツールで管理している場合、運用対象を減らせます。
SoapUIとApidogの比較
| 項目 | SoapUI Open Source | Apidog |
|---|---|---|
| 価格 | 無料。Pro機能はReadyAPIへ移行、年間約829ドル以上/ライセンス | 4ユーザーまで無料、それ以降は月額9ドル/ユーザー |
| 主な用途 | SOAP/WSDLコントラクト | REST、GraphQL、gRPC、WebSocket |
| テストロジック | Groovyスクリプト | ビジュアルオーケストレーション + オプションのスクリプト |
| データ駆動テスト | 有料のReadyAPI | 全プランに付属 |
| モック | SOAP中心のモックサービス | スキーマ認識スマートモック、セルフホスト可能 |
| ロードテスト | 基本機能は無料、フル機能は有料 | 付属 |
| CI統合 | testrunnerスクリプト | CLIとHTMLレポート |
| ドキュメント生成 | なし | あり。カスタムドメインでホスト可能 |
| コラボレーション | 共有XMLプロジェクトファイル | リアルタイムのチームワークスペース |
| プラットフォーム | Javaデスクトップ | デスクトップ（Windows/macOS/Linux）+ Webアプリ |
注意点として、SOAP/WSDLが主要ワークロードなら、Apidog側の多くの利点は優先度が下がります。その場合はSoapUIまたはReadyAPIが適しています。
SoapUIワークフローを移行する手順
SoapUIプロジェクトをワンクリックで完全移行するインポーターはありません。現実的には、次の手順で進めます。
プロジェクトXMLではなくAPIコントラクトから開始する
OpenAPI定義があれば、Apidogへ直接インポートします。エンドポイント、スキーマ、サンプルを構造化した状態で取り込めます。OpenAPIがない場合は、PostmanコレクションまたはcURLコマンドからリクエストを再構築します。SoapUIテストケースをシナリオとして再作成する
単純なテストから始めてください。リクエスト送信、値の抽出、次リクエストへの受け渡し、アサーションという流れを1つずつ移します。Groovy内に埋もれていた処理を視覚的なステップへ分解できます。CIジョブの実行コマンドを置き換える
以前testrunner.shを呼び出していたジョブに、Apidog CLIを追加します。ビルドエージェント上のJava依存を減らせます。
中規模のテストスイートでは、移行用に1スプリント程度の時間を確保してください。書き換えはコストですが、長期間見直されていないテストや不要なGroovyロジックを整理する機会にもなります。
切り替え後の最初の1時間
0〜15分: APIをインポートする
現在SoapUIでテストしているサービスのOpenAPI仕様をインポートします。仕様がない場合は、Postmanコレクションをインポートします。
確認する項目:
- エンドポイントが正しくグループ化されているか
- スキーマとサンプルが表示されるか
- 認証情報を環境変数として設定できるか
15〜30分: テストケースを1つ再構築する
プロパティ転送を含むSoapUIテストケースを1つ選びます。
- リクエストAを追加する
- レスポンスからIDなどの値を抽出する
- 抽出値をリクエストBに設定する
- ステータスコードとレスポンスフィールドを検証する
まずは1ケースをチーム全員が読める状態にすることが重要です。
30〜45分: データ駆動テストにする
CSVまたはJSONの入力データをシナリオに関連付け、各行を使って実行します。
email,password,expectedStatus
user1@example.com,password1,200
user2@example.com,password2,401
リクエスト内では、各列を変数として利用します。複数の入力パターンを個別のGroovyスクリプトで管理する必要がありません。
45〜60分: CIへ組み込む
CLIをインストールし、シナリオIDと環境を指定して実行します。生成されたHTMLレポートをCIのビルド成果物として保存します。
この1時間で確認すべき点は、単に機能があるかではありません。特定の担当者だけが理解している既存スイートを、チーム全体で運用できる形に変えられるかを確認してください。
SoapUIがまだ適しているケース
次の条件に当てはまる場合、SoapUIは依然として有力な選択肢です。
- WSDL駆動のSOAPサービスがシステムの大半を占める
- 銀行ミドルウェア、政府機関との統合、エンタープライズサービスバスを扱う
- JMSまたはJDBC仮想化を深く利用している
- 成熟したGroovyテストスイートを1人のQAエンジニアが保守しており、書き換えコストが高い
ApidogはWSDLをインポートしたり、コントラクトからSOAPエンベロープを生成したりしません。JMSやJDBC仮想化もReadyAPIの領域です。このスタックについてはSmartBearの価格設定と2025年の主要な代替品も確認してください。
一方、RESTや最新プロトコルがテストの大部分を占め、GroovyとXMLの運用負荷がチーム全体に及んでいるなら、移行を検討する価値があります。
よくある質問
ApidogはSoapUI Open Sourceのように無料ですか？
Apidogの無料プランは、最大4ユーザー、無制限のAPI・リクエスト・テスト実行に対応します。データ駆動テスト、CI統合、共有可能なテストレポートも利用できます。
SoapUI Open Sourceはコア機能を無料で利用できますが、高度な機能はReadyAPI側にあります。
ApidogはSOAPサービスをテストできますか？
HTTP経由でXMLリクエストボディを送信できるため、単純なSOAP呼び出しは可能です。ただし、WSDLのインポートやコントラクトからのSOAPエンベロープ生成は行いません。WSDL駆動テストが日常業務なら、その用途ではSoapUIを使い続けるのが適切です。
Apidogを使うためにGroovyを知る必要がありますか？
いいえ。リクエスト連携、値の抽出、データ駆動ループ、アサーションは視覚的に設定できます。スクリプトが必要な場合も、GroovyではなくPostman互換の構文を利用できます。
SoapUIのtestrunnerに代わるCIツールは何ですか？
Apidog CLIです。次のコマンドでインストールし、任意の環境に対してシナリオを実行できます。
npm install -g apidog-cli
apidog run scenario --scenario-id 12345 --env staging
HTMLレポートをビルド成果物として公開でき、Jenkins、GitLab CI、GitHub ActionsでJavaベースのtestrunnerスクリプトを置き換えられます。
SoapUI Proはどうなりましたか？
SmartBearはSoapUI Proを商用APIテストプラットフォームのReadyAPIに統合しました。SoapUI Open Sourceは継続されていますが、高度な機能はReadyAPIで提供されています。第三者の価格トラッカーでは、年間ライセンスあたり約829ドルからと記載されています。
まずは1つのRESTサービスで試す
現在SoapUIでテストしているRESTサービスを1つ選び、OpenAPI仕様をインポートして、テストスイートをApidogシナリオとして再構築してください。
- 代表的なテストケースを1つ選ぶ
- OpenAPI仕様またはPostmanコレクションをインポートする
- 値の受け渡しとアサーションをシナリオ化する
- CSVまたはJSONでデータ駆動実行する
- CLIからステージング環境に対して実行する
- HTMLレポートをCI成果物として保存する
Apidogをダウンロードし、実際に作業時間を計測してみてください。最大4人のチームは無料で利用でき、試用時に営業担当者との通話は不要です。
Top comments (0)