はじめに

現代の開発にAIは欠かせないものとなっており、それに応じて、私たちの開発スタイルにも変化が求められています。
そうした背景の中で、近年注目を浴びているのが仕様駆動開発(Spec-Driven Development) です。コードを書きはじめる前に「何を作るか」を仕様ドキュメントとして固め、そのドキュメントを人とAIの "共通の拠りどころ" にする——という考え方です。仕様ドキュメントという明確な拠りどころがあることで、指示する人ごとのプロンプトの差異によってAIの出力が揺らいでしまうことも抑えられます。
この記事では、その流れのなかでParasoft Virtualizeが担う役割、とりわけ新しく登場したVirtualize MCP 機能にフォーカスして解説します。

※本機能は、SOAtest/Virtualize 2026.1以降でご利用いただけます。

仕様を先に決める — 仕様駆動開発

仕様駆動開発では、どんな機能を・どんな画面で・どんなデータをやり取りするのかといった「作るものの中身」を、あらかじめ仕様ドキュメントにまとめておきます。そして、AIはこの仕様ドキュメントを見て、コードを実装していきます。

ポイントは、人もAIも同じ文書を見て動く点です。判断や意思決定は人が、調査や実装はAIが担いますが、両者が同じ仕様ドキュメントを参照するため「任せたら思っていたのと違うものが出てきた」という事故が起きにくくなります。

これは変更のときも同じです。プログラムを修正する際は、まず仕様の修正を必ず先に行い、その変更された仕様をもとにプログラムを直します。CLAUDE.md のようなAIのルール書に「仕様書を作成・修正してから実装に入る」と明記して、AIの振る舞いをそのルールで縛っておくのがコツです。

仕様駆動型開発の開発フロー

仕様駆動型開発の場合、開発サイクルはこのような流れになります。

実際に手を動かすのはAIです。人は最初の指示と反映前の承認という要所を担います。
起票から実装・検証までは一続きで進み、マージした後はCIが自動で再検証します。人が全工程に張り付くのではなく、要所だけを押さえて AI に走ってもらう——今後はこういったスタイルの開発が必要となってきます。

Virtualize MCP でできること

では、このフローのなかで Parasoft Virtualize は何をしてくれるのでしょうか。

答えはシンプルで、仕様ドキュメントからテスト資産(スタブ)を自動で生成してくれる、です。
たとえばバックエンドAPIがまだ実装されていなくても、仕様ドキュメントさえあれば、 AIがVirtualizeを使ってそのAPIを模したスタブ(サービス仮想化)を自動で作成します。フロントエンドの開発者は、そのスタブを相手に依存サービスの完成を待たずにテストを進められるというわけです。

そもそも MCP とは？

MCP(Model Context Protocol)は、生成AIとツールをつなぐための共通の"窓口"のようなものです。
生成AI(Claude など)が仕様ドキュメントを読み込み、MCPが定めた形式に変換してVirtualizeへ渡す——この受け渡しの取り決めがMCPです。そのため、生成AIが読める形式であれば、仕様ドキュメントはExcelでもWordでもMarkdownでも構いません。

実際にやってみる

ここからは、簡単なTODOアプリを題材に、実際のフローを少しのぞいてみましょう。

今回は、フロントエンドの開発だけを行い、バックエンドは別部隊が開発することを想定します。そのため、フロントエンドの開発には、バックエンドの代用となるスタブが必要になります。
システム構成図としては、以下を目指します。

1. 仕様ドキュメントを作らせる

まずはClaude Codeに、作りたい機能の仕様ドキュメントを書いてもらいます。

プロンプトで指定したフォーマットに沿って、AIが仕様ドキュメントをまとめてくれます。ここはまだVirtualizeには触れない、いわば "土台づくり" の工程です。

2. フロントエンドの先行開発

生成された仕様ドキュメントをもとに、AIがフロントエンドのコードを実装させます。それと同時に、Virtualize MCPがバックエンドAPIのスタブ(サービス仮想化)も生成させます。

フロントエンドの実装と同時に、仕様ドキュメントに対応したスタブが生成されます。

まとめ

AIを活用することで、フロントエンド開発と並行してスタブを作成できる点が、生成AI × Virtualize MCPの大きな特徴です。さらに、スタブは仕様ドキュメントに基づいて生成するため、仕様変更にも柔軟に追従できます。
このように、 Virtualize MCPを使うと、依存サービスの準備を待たずに早期からテストを始められ、テスト資産の作成・保守にかかる時間も大幅に短縮できます。

一方で、生成 AI の利用にはトークン消費(コスト)が伴い、生成物の妥当性は最終的に人の確認・検証が必要です。とはいえ、仕様ドキュメントを起点にAIとサービス仮想化を組み合わせるこのやり方は、これからの開発の心強い選択肢になるはずです。