要約
SoapUIの動作が遅い原因は、JVMの起動オーバーヘッド、大規模プロジェクトには低すぎるデフォルトのメモリ設定、そしてWSDLの解析遅延にあります。具体的な修正（ヒープサイズ調整、WSDLキャッシュ、プロジェクトの分割）によって、速度を大幅に改善できます。これらのボトルネックを完全に回避できる、より高速なツールが必要なチームには、Javaランタイムなしで動作するApidogがおすすめです。
はじめに
SoapUIは動作が遅いです。数週間以上使用した経験があれば、30秒かかる起動時間、大規模なWSDLを解析中の応答しないUI、または数百のテストステップがある場合のテスト実行の遅延を経験したことがあるでしょう。これらはバグではありません。SoapUIがどのように構築されているかの必然的な結果です。
このガイドでは、SoapUIが遅い特定の技術的理由を説明し、それぞれに対する具体的な修正方法と限界を示します。遅延の一部は修正できますが、ツールを切り替えないと修正できないものもあります。
根本原因1：JVM起動のオーバーヘッド
SoapUIはJava Swingアプリケーションです。起動するたびに、Java仮想マシン（JVM）が起動し、数百のクラスファイルがロードされ、Springフレームワークが初期化され、プロジェクトがロードされ、Swingインターフェースがレンダリングされます。最新のSSDを搭載したマシンでは20〜60秒かかりますが、古いハードウェアでは90秒を超えることもあります。
これが起こる理由：Javaアプリケーションは、ネイティブアプリケーションにはない起動コストを支払います。JVMは、実行が開始される前にバイトコードを解釈またはJITコンパイルする必要があります。Swing UIの初期化もこれに加わります。
修正方法：
SoapUIを開いたままにする。最も簡単な解決策は、テスト実行の間に閉じないことです。JVMが一度実行されると、そのまま温かく保たれます。
高速なディスクを使用する。Spinning Hard DiskからSoapUIを実行している場合は、SSDに移動してください。クラスロードフェーズでは多くの小さなファイルが読み取られますが、これはSSDがHDDよりも優れている正確な点です。
Java 8ではなくJava 11または17を使用する。新しいJVMバージョンでは起動時間が改善されています。soapui.bat（Windows）またはsoapui.sh（Linux/Mac）でSoapUIが使用するように設定されているJDKを確認してください。最初の行でJavaホームパスを設定します。新しいJDKに切り替えることで起動時間を短縮できます。
AppCDS（Application Class Data Sharing）を有効にする。このJVM機能は、クラスロードデータを事前にキャッシュします。一度設定が必要ですが、その後の起動時間を短縮します。JVM引数に-XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsaを追加します。
根本原因2：デフォルトのメモリ設定が低すぎる
SoapUIは、デフォルトのヒープサイズ設定が低く出荷されています。大規模なプロジェクトを開いたり、長いテストスイートを実行したりすると、JVMはガベージコレクションに時間を費やし、アプリケーションが一時停止して動作が重く感じられます。
デフォルト設定（soapui.vmoptionsまたはsoapui.batから）：
-Xms128m
-Xmx768m
これは、SoapUIが128MBのヒープで起動し、最大768MBを使用できることを意味します。最新のマシンには8〜32GBのRAMが搭載されています。SoapUIを768MBのままにすると、大規模なプロジェクトでは常にガベージコレクションの負荷がかかります。
修正：ヒープサイズを増やす
Windowsの場合、<SoapUI_Install>/bin/SoapUI.vmoptionsを編集します。
-Xms512m
-Xmx2048m
macOSの場合、SoapUI.app/Contents/vmoptions.txtを編集するか、soapui.shを探します。
JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"
Linuxの場合、<SoapUI_Install>/bin/soapui.shを編集します。
JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"
推奨事項：
- RAMに余裕がある場合は、
-Xms（初期ヒープ）を512MB以上設定します。これにより、段階的なヒープ拡張を回避できます。 -Xmx（最大ヒープ）は、中規模プロジェクトで2GB、大規模プロジェクトで4GBに設定します。利用可能なRAMの半分以上に設定しないでください。- Java 9以降を使用している場合は、
-XX:+UseG1GCを追加します。G1GCは、デフォルトのガベージコレクタと比較して一時停止時間を短縮します。 - メタスペース（クラスメタデータ）が無制限に増大するのを防ぐために、
-XX:MaxMetaspaceSize=512mを追加します。
修正の確認：SoapUIを再起動した後、Help > System Propertiesダイアログを開きます。更新されたヒープ値が表示されるはずです。タスクマネージャーを監視して、SoapUIが新しい割り当てを使用していることを確認してください。
根本原因3：大規模なプロジェクトファイル
SoapUIはすべてを単一のXMLファイルに保存します。多くのテストスイート、大きなリクエストボディ、またはインラインバイナリデータを持つプロジェクトは、このファイルを肥大化させます。10MBのプロジェクトファイルを開いたり保存したりする作業は、500KBのものよりも著しく遅くなります。
この問題の兆候：
- 保存時（Ctrl+S）にSoapUIが数秒間一時停止する
- ディスク上のプロジェクトファイルが数MBある
- SoapUIが既に起動している状態でプロジェクトを開くのに10秒以上かかる
修正方法：
大規模なプロジェクトを分割する。SoapUIは、テストスイートをディレクトリ内の別個のXMLファイルとして保存する複合プロジェクトをサポートしています。これは、Project > Settings > Composite Projectで有効にします。これにより、部分的なロードと高速な保存が可能になります。
不要なテストケースを削除する。もはや関連性のないテストケースはアーカイブまたは削除します。スクリプトとリクエストデータを持つ各テストケースは、XMLサイズを増加させます。
大きなリクエストボディを外部化する。テストステップが大きなXMLまたはJSONボディをインラインで使用している場合、それらをパラメータ化し、SoapUIのファイルベースのDataSourceを使用して外部ファイルからロードすることを検討してください。
「終了時に保存」の自動バックアップを無効にする。SoapUIは終了時にバックアップコピーを作成します。Preferences > UI Settingsでこれを無効にすることで、終了時の余分なディスク書き込みを回避できます。
根本原因4：WSDL解析の遅延
SoapUIがWSDLファイルを参照するプロジェクトを開くとき、起動時やインターフェースツリーを展開するときに、これらのWSDLを再解析することがあります。WSDLがリモートサーバーでホストされている場合や、大きい場合（多くの操作、複雑な型）、この解析によってかなりの遅延が生じます。
この問題の兆候：
- インターフェースを展開するときにSoapUIがハングするか、回転するインジケーターが表示される
- テストが開始される前に接続タイムアウトエラーで失敗する
- 異なるマシンでプロジェクトのロード速度が異なる（ネットワーク依存）
修正方法：
WSDLをローカルにキャッシュする。SoapUIで、インターフェースを右クリックし、「Update Definition」を選択します。定義URLを、リモートURLではなく、WSDLのローカルファイルコピーを指すように変更します。これにより、ロードごとのネットワーク遅延が解消されます。
定義URLをfile://パスに設定する。WSDLのローカルコピーがある場合は、インターフェースの定義URLをfile:///path/to/your/service.wsdlに更新します。SoapUIはこれをディスクから瞬時にロードします。
定義の自動更新を無効にする。Preferences > WS-Security Settingsで、起動時にWSDLの再検証を強制するオプションのチェックを外します。
HTTPタイムアウト設定を増やす。ネットワークWSDLの応答が遅い場合は、Preferences > HTTP Settingsに移動し、接続タイムアウトを増やします。これにより、SoapUIが遅いWSDLサーバーで無期限にハングするのを防ぎます。
根本原因5：大規模スイートでのテスト実行パフォーマンス
数百のテストケースを含むテストスイートを実行するのは遅くなることがあります。特に、各テストステップに複雑なGroovyスクリプト、アサーション、またはネットワーク呼び出しがある場合に顕著です。
修正方法：
スイートを並行して実行する。SoapUIは並行テストスイート実行をサポートしています。TestSuiteランナーで、「Run test cases concurrently」オプションを有効にします。SOAPサービスが同時接続を処理できることを確認してください。
不要なアサーションを無効にする。SoapUIが評価する各アサーションは処理時間を追加します。テストステップを監査し、意味のあるものをチェックしていないアサーションを削除します。
Groovyスクリプトを最適化する。GroovyスクリプトはSoapUIで解釈実行されます。すべてのテストステップで実行されるスクリプト（文字列解析、正規表現、大規模なオブジェクト作成）で高コストな操作を避けてください。共通ロジックはプロジェクトレベルのスクリプトライブラリに移動します。
応答時間アサーションを慎重に使用する。応答SLAアサーションは、失敗する前に完全なタイムアウトを待ちます。信頼性の低いエンドポイントで長いタイムアウトを持つ厳密なSLAアサーションを使用すると、スイート全体がブロックされる可能性があります。
ログの冗長性を減らす。SoapUIはデフォルトで各リクエストとレスポンスをログに記録します。大規模なスイートの場合、このI/Oは増加します。Preferences > HTTP Settingsに移動し、テスト実行中にログに記録される内容を減らしてください。
修正できないこと
SoapUIのパフォーマンス問題の中には構造的なものもあります。どんなチューニングをしても変わらない点があります。
- Swing UIのレンダリング。インターフェースは、常にネイティブアプリやWebアプリよりも遅く感じられます。Swingは2000年代には最先端でしたが、今はそうではありません。
- JVMの起動。軽減はできますが、なくすことはできません。
- シングルスレッドのWSDL解析。SoapUIはWSDLを順次解析します。多くのインポートされたスキーマを持つ大規模で複雑なWSDLは時間がかかり、並行処理を設定する方法はありません。
- メモリのオーバーヘッド。JVM、Swing、Springフレームワークは、プロジェクトのサイズに関係なくメモリを消費します。アイドル状態での300〜400MBは一般的です。
移行を検討する時期
上記の修正を適用してもSoapUIがワークフローの妨げになる場合、ボトルネックは設定では修正できない可能性があります。
Apidogは、JVMではなくNode.jsクライアントにバックアップされたWebアプリケーションとして動作します。数秒で起動し、テスト実行にマシン上のJavaランタイムは必要ありません。SoapUIの起動時間とUIの応答性が主なボトルネックであるチームにとって、ツールの切り替えはJVMの継続的なチューニングよりも生産的です。
トレードオフ：ApidogはWSDLを解析しません。新しいサービスのオンボーディングでSoapUIのWSDLインポートに依存している場合、その特定のタスクのためにSoapUIを保持しつつ、日常のテストはApidogで実行することをお勧めします。
よくある質問
大規模プロジェクト（50以上のテストスイート）の場合、SoapUIに推奨されるヒープサイズはどのくらいですか？マシンのRAMが16GB以上ある場合、-Xmxは少なくとも2GB、理想的には4GBに設定します。段階的なヒープ拡張を避けるために、-Xmsは512MBから1GBに設定します。より良いガベージコレクション動作のために-XX:+UseG1GCを使用します。
SoapUIの現在のヒープ使用量を確認できますか？はい、できます。Help > System Propertiesに進みます。これにより、ヒープ設定を含むJVM引数が表示されます。また、一時的にJVMオプションに-verbose:gcを追加して、SoapUIログでガベージコレクションの活動を確認することもできます。
新しいJDKに切り替えるとSoapUIのパフォーマンスは向上しますか？ほとんどの場合、はい。Java 8と比較して、Java 11および17ではJVMの起動時間とガベージコレクションが改善されています。一部の新しいJDKバージョンは古いSoapUIリリースとの互換性の問題があるため、推奨されるJDKバージョンについてはSoapUIのリリースノートを確認してください。
SoapUIは数時間テストを実行すると、なぜ遅くなるのですか？メモリの断片化とガベージコレクションのオーバーヘッドは時間とともに増加します。SoapUIを閉じて再度開くと、JVMの状態がリセットされます。-Xmxを増やし、G1GCを使用するとこの劣化を遅らせることはできますが、完全に解消することはできません。
サーバー（ヘッドレス）でSoapUIを実行するとパフォーマンスは向上しますか？はい、ある程度は。ヘッドレスモード（-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=falseおよび同様のフラグ）は、Swingのレンダリングオーバーヘッドを削減します。最適なパフォーマンスを得るには、GUIではなくCI/CDにはコマンドラインのテストランナーを使用してください。
ApidogはSoapUIと比較して、大規模なコレクションをどのように処理しますか？Apidogはコレクションをクラウドに保存し、必要に応じてロードします。解析するローカルXMLファイルはありません。テスト実行には、JVMの初期化を必要としないローカルのCLIランナーを使用します。
ほとんどのSoapUIのパフォーマンス問題には解決策があります。ヒープサイズの変更だけでも、即座に目に見える効果があることが多いです。より複雑な解決策を試す前に、そこから始めてください。