Specmatic 創設者 Naresh Jain 氏インタビュー — 実行可能な仕様、MCP、そして AI エージェントのための harness

どのような課題意識から、Specmaticを作られたのですか？

Naresh Jain

7 年ほど前、私はインドのある大企業グループのアドバイザーを務めていました。比較的若い会社でしたが、驚異的な速度で成長しており、通信・小売・金融・教育・メディア・ヘルスケアにまたがって 4 万を超えるマイクロサービスを運用していました。初期の頃、彼らのチームは 1 日に何度も本番リリースできていました。ところが組織とアーキテクチャが大きくなるにつれ、そのリリース能力が劇的に落ちていったのです。経営陣から、その原因を一緒に突き止めてほしいと声がかかりました。

私は SDLC プロセスを分析する、Engioscope という小さなユーティリティを作りました。すると、エンジニアリングのメトリクスの中でひとつだけ突出しているものがありました。変更のリードタイムが、全体のサイクルタイムのおよそ 3 分の 2 を占めていたのです。言い換えれば、要件定義・設計・開発に費やされていたのは全体の 3 分の 1 程度で、残りの 3 分の 2 は、テストとパッケージングと、その変更を安全に本番へ届けることに消えていました。さらに掘り下げてみると、その遅延の大きな部分が結合テストでした。各チームは独立に自分のサービスを作り、開発ライフサイクルのかなり後半になってからそれらを持ち寄る。そこで初めて、API についての互いの前提が食い違っていたことに気づくわけです。設計上の問題、互換性の問題、Consumer と Provider の間の認識のズレが、いずれもかなり手遅れな段階で見つかっていて、これが非常に高くついていました。

これはモノリスとマイクロサービスの構造的な違いに起因します。モノリスであればコンパイラが関数呼び出しの不整合を即座に検知してくれますが、マイクロサービスでは呼び出しがプロセス境界をまたぐため、API 呼び出しの不整合は結合時にしか判明しません。

そこで問いはこうなりました。どうすればこのフィードバックをもっと早く得られるように shift-left できるか。

契約テスト (contract testing) は明らかに有力な方向でした。Provider と Consumer を分離し、それぞれ独立に開発・テストできるようにするからです。ところが既存のアプローチを評価してみると、別の問題にぶつかりました。エンジニアが相当量の追加のテストコードを書き、保守しなければならない、という点です。このスケールでは、それは小さな問題ではありません。契約テストの導入が「数千人のエンジニアを説得して独自 DSL を学ばせ、もう一層のテストコードを書かせて保守させる」ことを意味するなら、導入そのものがボトルネックになってしまいます。だから私たちは、作るものは何であれ no-code でなければならないと考えました。エンジニアが契約テストを書く必要などない。すでに API を仕様として記述しているのなら、それで十分なはずだ、と。

もうひとつ、より根本的な問いもありました。source of truth は何なのか。 API 仕様なのか、それとも契約テストのコードなのか。私たちの立場は、API 仕様こそが契約であるべきだ、というものでした。そこから Specmatic の中心的なアイデアが生まれます。仕様が Provider と Consumer の間の契約なのであれば、それを実行できる契約に変えてしまえばいいのではないか、と。

Specmatic は API 仕様を受け取り、Provider が本当にその仕様に適合しているかを検証するテストを自動生成できます。そしてまったく同じ仕様から、Consumer が開発・テストの相手にできる、ワイヤ互換のモックを立ち上げられます。追加で書いたり保守したりする契約テストのコードはありません。チームはすでに手元にある成果物、つまり API 仕様を使って導入できる。これは非常に重要でした。私たちが解こうとしていたのは技術的な問題だけではなく、巨大なエンジニアリング組織に短期間で行き渡る解が必要だったからです。こうして Provider と Consumer は独立に作業しながら、それでも「後で持ち寄ったときに互換である」ことを決定論的に知る手段を持てるようになりました。

それが Specmatic の出発点です。API 仕様をドキュメントから no-code な実行可能契約へと変え、結合のフィードバックをデリバリーの後半から可能な限り手前へ動かすこと。

Specmaticの特徴はどこにあると考えられますか？

Naresh Jain

Specmatic を際立たせているのは、突き詰めると出発点にあった哲学です。仕様が source of truth であるべきで、その仕様は実行可能であるべきだ。API 仕様が「ドキュメントのために書くもの」であって、システムの本当の意図や振る舞いのほうは設計書・受入基準・実装コード・テスト・モックに散らばっている——そういう状態にはしたくありませんでした。そうした瞬間に source of truth が複数生まれ、時間とともに必ず乖離していきます。

Specmatic では、可能な限り多くのものを仕様から直接導き出そうとしています。契約テストの生成、ワイヤ互換モックの生成、後方互換性のチェック、境界条件のテスト生成、そして実装が契約で約束したとおりに振る舞っているかの検証です。そして重要なのは、これらすべてを no-code かつ決定論的 (deterministic) にしたかった、という点です。これらを正しく行うには、かなり泥臭いエンジニアリングが要ります。私たちの哲学は、個々の開発チームが同じ問題を何度も解き直したり、追加のテストコードを保守したりするべきではない、というものです。その重い部分は Specmatic が引き受ける。エンジニアは契約を一度記述すればよく、Specmatic がそれを、開発ライフサイクル全体を通じて使える実行可能なエンジニアリング成果物に変える、という考え方です。

もうひとつ大事にしたのは、現代のエンタープライズに存在するさまざまな API・通信スタイルにまたがって、一貫した体験を提供することでした。大きな組織には REST API しかない、ということはありません。ある箇所では REST と OpenAPI、別の箇所では非同期メッセージングとイベント駆動、内部の高性能通信には gRPC、複数サービスの集約には GraphQL、そしてそれらをまたぐワークフローがある。下位のプロトコルが変わるたびに、まったく別のアプローチを覚えなければならないというのはおかしい、と考えました。ですから Specmatic は、特定のプロトコルではなく仕様を中心に設計されています。OpenAPI であれ AsyncAPI であれ GraphQL であれ gRPC であれ、根本のアイデアは変わりません。契約を受け取り、実行可能にし、それを使ってシステムを決定論的に検証する。これはエンタープライズ規模でとくに効いてきます。バラバラなツールと慣行の寄せ集めではなく、異種混在の技術ランドスケープに対して一貫したエンジニアリングのやり方が手に入るからです。

そして今日とりわけ興味深いのは、この哲学が AI と spec-driven development によっていっそう重要になってきていることです。AI が実装のより多くを生成するようになるにつれ、人々はこう問うようになっています。AI に与える source of truth は何なのか。 そして AI が何かを生成したあと、それが本当に正しいことをどうやって決定論的に確かめるのか。業界は、その source of truth として仕様に回帰しつつあります。ですからある意味で、Specmatic の根本のアイデアは変わっていません。変わったのは周囲の環境です。実装のますます多くが確率的に生成されるようになるほど、決定論的で実行可能な仕様の価値は上がるのです。

これまでのところ、ユーザーからはどのようなフィードバックが共有されていますか？

Naresh Jain

エンタープライズと仕事をしてきて最も興味深かった学びのひとつは、この問題領域が実際どれほど広いかということです。

私たちは「API の Consumer と Provider をどう分離し、結合の問題をどれだけ早く見つけるか」というかなり具体的な問題から Specmatic を始めました。ところが利用組織が増えるにつれ、「明確に定義された実行可能な契約を持つ」という同じ原理が、まったく別のエンジニアリング課題を解いているのを見るようになりました。

たとえばある顧客は、一連の Lambda 関数が段階的にデータを変換していく複雑なデータパイプラインを構築していました。個々のコンポーネントは動くのに、パイプライン全体を端から端まで整合させるのが難しい。よく見ると、各変換ステップは次のステップとの間に事実上の契約を持っていたのです。それを AsyncAPI で明示的に表現し、独立に検証できるようにすれば、全部つないだ段階で非互換に気づくのではなく、パイプラインをずっと決定論的に扱えるようになります。

別の顧客は、ほとんど逆の問題を抱えていました。統一 API を定義したうえで、それを地域別・国別のチームが独立に実装する。彼らの課題は、それらすべての実装が同じインターフェースと互換であり続けること、そして組織横断で「どの実装が準拠していて、どこにギャップがあるか」を可視化することでした。

さらに別のエンタープライズでは、課題はそもそも結合ではありませんでした。彼らが求めたのは API そのものの品質向上で、仕様が組織の標準に従い、その API が組織中に広まる前に十分な完全性と精度を備えていることを保証したい、というものでした。こうした経験は、Specmatic が何になり得るかについての私たちの視野を大きく広げてくれました。私たちは当初、実行可能な仕様を主に結合問題を解く手段として考えていました。ユーザーが示してくれたのは、いったん仕様を source of truth に据えると、その同じ原理を、分散システム・イベント駆動アーキテクチャ・API 品質・互換性・ガバナンス・全社的な可視化へとずっと広く適用できる、ということでした。

ここが Specmatic を作っていて最もわくわくする部分のひとつです。根底の原理は驚くほど一貫したままなのに、その原理が解ける問題の範囲は、当初想像していたよりはるかに広かったのです。

いま MCP が大きな注目を集めています。API と MCP の関係はどう進化していくとお考えですか。MCP は本質的には API のラッパーなのか、それともそれ以上のものなのでしょうか？

Naresh Jain

歴史的に、私たちが API を設計するとき、その相手はもう一人の人間——開発者——でした。開発者は API のドキュメントや仕様を読み、その能力を理解し、それを消費するコードを自分で書く。実際のクライアントは比較的単純で、開発者がプログラムした振る舞いを実行するだけでした。

AI エージェントによって、これは根本的に変わります。史上はじめて、あなたの API の消費者そのものが知的でありうる。エージェントは能力を発見し、どれを使うか推論し、組み合わせ、場合によっては API の設計者が明示的に想定していなかった使い方さえします。ここで面白い問いが立ちます。この新しい種類の消費者のために、既存の API をすべて設計し直すのか。それとも、既存の能力をエージェントにとって適切な形で提示する抽象レイヤーを導入するのか。私は、MCP がその役割を果たせると考えています。

MCP が API を置き換えるとは必ずしも思っていません。多くの場合、根底のビジネス能力はこれからも API として公開され続けるでしょう。MCP はその上にエージェント向けのレイヤーを提供し、複数の API を集約して、エージェントが発見・理解・利用しやすい少数のまとまったツールとして見せることができます。もうひとつ重要な側面があります。API の中身がすべて LLM やエージェントに公開されるべきとは限らない、ということです。既存の API は、信頼できるアプリケーションや内部システム向けに設計されてきたために、非常に広い表面積を露出しているかもしれません。エージェント相手には、もっと意図的な境界を引きたくなるはずです。MCP はその抽象レイヤーになり得ます。エージェントが実際に必要とする能力と情報だけを露出し、根底の複雑さや、機微あるいは不適切な操作は境界の裏に隠す。

ですから私は、API と MCP は共存すると見ています。API はビジネス能力を公開する基盤であり続ける。MCP は、その能力を新しい種類の消費者、すなわち知的なエージェントに向けて、選び・束ね・公開する手段を与えてくれる。そしてこの区別は重要だと思います。MCP が興味深いのは、単に新しいプロトコルが増えたからではありません。クライアントの性質そのものが変わったからです。

AI によるコード生成・仕様生成が広がる中で、契約（Contract）の役割はどう変わるでしょうか。また、AI が書いたコードを仕様に対して誠実に保つには何が必要でしょうか？

Naresh Jain

他産業の工業化で起きたことと、実に興味深い相似があると思っています。繊維産業を例に取りましょう。

もともとは、熟練の織り手が手織機に向かって布を織っていました。美しいものができますが、当然ながらスケールしません。そこへ力織機が現れます。突如として、はるかに速く布を生産できる機械が手に入った。ところが問題がありました。人は機械を完全には信用していなかったのです。だから結局、誰かが織機を見張り、糸切れや不良を探し、何かおかしければ機械を止める必要がありました。機械の生産能力は劇的に高まったのに、人間は依然としてクリティカルなループの内側に座っていた。そのぶん、得られたはずの生産性向上を実際には取り切れなかったわけです。

いまのソフトウェア開発は、これと非常によく似た地点にあると思います。私たちはいま、途方もない速度で大量のコードを生成できる、極めて強力な AI コーディングエージェントを手にしています。しかし、その成果物をまだ完全には信用していない。そして実際、限界もある。

ではどうしたか。すべての AI コーディングエージェントの隣にエンジニアを 1 人座らせ、生成されたコードをレビューして、正しいことをしたかどうかを判断させているのです。コードを生成する速度は劇的に上がったのに、人間によるレビューが新しいボトルネックになった。これはスケールしないと思います。

ここでトヨタの歴史がとりわけ興味深くなります。豊田佐吉の自動織機における重要な発明のひとつは、糸が切れたなどの異常を機械自身が検知し、不良品を織り続けるのではなく自ら止まる能力でした。この考えがやがて、私たちが自働化 (Jidoka) として知るものの中核になります。機械に異常を検知して止まる能力を与え、人間の判断が本当に必要なときにだけ人間を呼ぶ、という考え方です。アンドンやポカヨケといった考え方と合わせて、これにより人間は「機械を常時監督する」ことから「自らを監督できるようになっていくシステムを監督する」ことへ移ることができました。

ソフトウェアエンジニアリングにも、AI 時代における同等の発明がいま必要だと思います。AI コーディングエージェントはすでに並外れて有能です。足りていないのは、その周りの harness (ハーネス) ——全速力で安全に自律動作させるためのガイドとセンサーです。

API 仕様、ドメイン固有の例、API カタログ、その他の文脈情報がガイドになり得ます。これらは、私たちがエージェントに作らせたいシステムの意図・制約・境界を明示的に記述します。実行可能な仕様（テストとモック）、lint、カバレッジ、後方互換性チェックがセンサーになります。これらは、生成されたものが本当にその意図に適合しているかを、決定論的なフィードバックとして継続的に返します。両方が揃うと、開発ループそのものが変わり始めます。

これまでの:

AI がコードを生成する → 人間がすべてをレビューする

から、次の形へ動けます:

仕様がエージェントを導く → エージェントが生成する → 実行可能な仕様が検証する → エージェントが自ら修正する → 判断が本当に必要なときに人間が呼ばれる。

この違いは私にとって非常に重要です。

私たちは AI の周りに柵を増やそうとしているのではありません。AI がより大きな自律性をもって動けるようにする harness を作ろうとしているのです。そして、そこが AI ネイティブな開発ライフサイクルにおける Specmatic の居場所だと考えています。

Specmatic は仕様を実行可能な契約に変え、コーディングエージェントに決定論的なセンサーを提供できます。生成された実装を契約に照らして検証し、互換性を確認し、境界条件を突き、食い違いがあれば正確で決定論的なフィードバックを返す。AI は本質的に確率的であり、それは大きな強みでもあります。従来のソフトウェアにはできない仕方で、探索し、推論し、解を生成できる。しかしその確率的なエンジンを自律的に動かすには、その周りに決定論的なフィードバックが必要です。

だからこそ、次の重要な一歩は「コーディングエージェントをもっと賢くすること」ではなく、その周りにより良い harness を作ることだと思うのです。自働化が、機械を「常時人間の監督が要る」状態から autonomation へ動かしたのとちょうど同じように、実行可能な仕様は AI コーディングエージェントを、人間監督下の生成から、真に自律的なソフトウェアエンジニアリングへ動かし、人間の判断が本当に必要なときにだけ人間をループに引き込めるようにすると信じています。

Specmatic をはじめて導入するチームに向けて、着手時のコツや注意点はありますか？

Naresh Jain

いちばんの助言は、小さく始める、ただし本物から始める、です。重要なビジネスフローをひとつ選ぶ。そのフローの中で、複数の Consumer が依存している中核サービスをひとつ特定する。そのサービスの API 仕様を定義し、Specmatic で Provider を契約テストする。そして同じ仕様からモックを作り、少なくとも 1 つの Consumer がそれを相手に開発・テストできるようにする。このループ全体を、開発者のマシン上でも CI 上でも動かしきる。それが最初の PoC です。

Provider と Consumer が独立に開発でき、その間に実行可能な契約としての仕様が座っている——チームが一度それを体験すると、価値はすぐに理解されます。そこから先の展開はずっと楽になります。強くお勧めしたいのは、完璧な API や完璧な仕様を待たないことです。何百・何千という API を見渡して「どれが理想的な出発点か」を決めようとして、分析麻痺に陥るチームをよく見かけます。私の経験では、それはさほど重要ではありません。大事なのは、最初のループを端から端まで動かすことです。

今日 API 仕様を持っていないとしても、それで構いません。Specmatic には仕様を作る手助けをする方法がいくつもあります。たとえば Specmatic をプロキシとして動かし、実際の API トラフィックを観測して、そこから適切な example 付きの仕様を生成できます。既存の Postman collection をインポートすることもできます。あるいは私たちの AI skills を使って、既存の実装から仕様を導き出すこともできます。同様に、仕様はあるけれど品質が望むレベルにない、という場合も、それは着手を止める理由になりません。観測したトラフィックや AI を使って仕様を充実させられますし、コーディングエージェントと Specmatic の MCP サーバーを組み合わせて検証ループを作ることもできます。仕様を改善し、実行し、不完全なところや矛盾を特定し、直し、それを高品質な実行可能契約になるまで繰り返す。つまり、spec-first をすでに実践していなければ始められない、ということはありません。むしろ Specmatic が spec-first への移行を助けてくれます。

もうひとつの助言は、一度にすべてを片付けようとしないこと（英語では "Don't boil the ocean" という言い回しで表現されていました）。API は 1 本ずつでいい。ただしエンタープライズのレベルでは、全体像の可視性は持っておきたい。そこで私たちは Specmatic Insights で組織全体の仕様を捕捉することをお勧めしています。API landscape の全体像がつかめますし、何より、実行可能契約でカバーされた API が増えていく進捗を測れるようになります。

ですから私の勧めるパターンは非常に単純です。全社の可視性は持つ。ただし導入は漸進的に。意味のある API を 1 本選ぶ。その仕様を実行可能にする。Provider を契約テストする。Consumer のためにモックする。その全体を CI に載せる。チームがそれが端から端まで動くのを一度見たら、そこから先の会話は「アイデアを説明する」ものではなく「体験されたもの」に変わります。

Specmatic がいま最も注力しているのはどこで、この先どこへ向かっていくのでしょうか？

Naresh Jain

Specmatic を始めたとき、私たちの焦点は比較的具体的でした。API 仕様を実行可能にして、開発ライフサイクルのずっと早い段階で決定論的なフィードバックを得られるようにし、後半での結合の不意打ちを避けること。いま私たちが向かっているのは、はるかに広い射程です。ビジネスの意図から、アーキテクチャ、実装を経て、継続的なガバナンスに至るまでの旅路全体に、この「実行可能性」という考えを持ち込みたいと考えています。それをいくつかのレイヤーで捉えています。

第 1 は Executable Intent（実行可能な意図） と呼んでいるものです。今日、ビジネスが望むものとエンジニアリングが最終的に作るものの間には、しばしば巨大な翻訳のギャップがあります。要件が文書に書かれ、アーキテクトが解釈し、API 設計に翻訳され、開発者が実装し、そしてずっと後になって検証される。

私たちはこのループを劇的に短くしようとする Specmatic Genie というものに取り組んでいます。ビジネス要件を平易な英語で記述すると、そのままプロトタイピング環境に入れて、API 設計を探索し、仕様を生成し、API をシミュレートし、実装する前に提案中のシステムと実際に対話できる——そんな姿を想像してみてください。私はときどきこれを 「API 設計における Figma」 と表現します。Figma がプロダクトデザインを変えたのは、アプリケーションを作らなくても人々がインターフェースを体験して検証できるようにしたからです。私たちは同じことを API にもたらしたい。意図を、作り込む投資をする前に、ビジネス・プロダクト・アーキテクチャ・エンジニアリングが「作るべきものかどうか」を検証できるくらい早く、手触りのある実行可能なものにする、ということです。

ただし、仕様が source of truth になるのなら——とりわけ人間と AI エージェントの双方がそれに依存するのなら——仕様そのものの品質にも確信が持てなければなりません。そこも私たちが大きく投資している領域です。新しい世代の API linting に取り組んでいます。従来の API linter はおおむね静的なルールに基づいています。命名規約、構造パターン、必須フィールド、組織のスタイルガイド。それらは有用ですが、その仕様が「現実世界で正しく振る舞う API」を記述しているかどうかまでは教えてくれません。

私たちはもっと先へ行きたい。Specmatic は仕様を実際に実行できるので、私たちの linter は静的解析に動的・振る舞い・実行時の検証を組み合わせられます。境界条件、制約、example、HTTP のセマンティクス、互換性——仕様を実行可能なものとして扱ってはじめて見えてくる特性について推論できるのです。目的は「あなたの仕様は見た目が良い」と伝えることではありません。その仕様が意味的に妥当で実行に耐えると確信できるようにし、API が現実世界に出会う前に潜在的な問題を洗い出すことです。

次のレイヤーは Executable Architecture（実行可能なアーキテクチャ） です。API が単独で存在することは稀です。ひとつのビジネス能力は、複数の API・サービス・イベント・相互作用がワークフローとして噛み合って初めて成立します。Arazzo Specification のような標準を使えば、それらのワークフローを明示的に記述できます。そして Specmatic は、そのアーキテクチャを実行可能なものに変えられます。参加するシステムのモックを作り、それらに対してワークフローを走らせるテストを生成する。

個々のサービスが存在するより前に、結合アーキテクチャを動かせるわけです。これはアーキテクトにとって非常に強力です。アーキテクチャを主に図と文書としてレビューするのではなく、実際に実行して、部品同士がどう相互作用するかについての前提を検証できる。その後、実際の API とサービスが実装されるにつれて、モックは段階的に置き換わっていきます。同じ harness がその旅路を通じて回り続け、実装がいまも合意したアーキテクチャに適合しているかを継続的に教えてくれます。これは大きな組織における重大な問題、すなわちアーキテクチャのドリフトに効きます。

次に実装そのものが来ますが、ここは AI について話したことに直結します。仕様とその周辺の文脈がガイドになり、実行可能な仕様と決定論的な検証がセンサーになる。この 2 つが合わさって、AI コーディングエージェントの周りにソフトウェアとして実装された harness を作ります。仕様がエージェントを「何を作るべきか」へ導き、Specmatic がその仕様を実行可能にして、「生成したものが本当に正しいか」を告げる決定論的なセンサーを提供する。エージェントは、生成し、実行し、フィードバックを受け取り、自ら修正し、そのループを繰り返す。そして人間の判断が本当に必要なときに人間を引き込む。

ここが、私たちにとって MCP が非常に面白くなる場所でもあります。エージェントが必要とするのは API へのアクセスだけではなく、その API を理解し、作り、検証するためのエンジニアリング能力へのアクセスです。Specmatic の能力を MCP 経由でコーディングエージェントに開放すれば、エージェント自身がこの決定論的なフィードバックループに直接参加できるようになります。そして現代のエンタープライズは単一の API プロトコルでは動いていないので、この体験を OpenAPI・AsyncAPI・GraphQL・gRPC などの標準にまたがって一貫させたいと考えています。

最後に、これらすべてを取り巻くのが Continuous Governance（継続的ガバナンス） です。組織が実行可能な意図から、実行可能なアーキテクチャ、実行可能な契約、そしてますます自律的な実装へと進んでいくと、そこで起きていることすべての可視性が必要になります。それが Specmatic Insights の役割です。Insights はこのエンジニアリングライフサイクルから継続的に情報を集め、API landscape 全体の可視性を組織に与えます。仕様の品質と完全性、API の依存関係、カバレッジ、互換性、非推奨化、spec-first の実践の浸透度、組織ポリシーへの適合。

ガバナンスが「最後に行われるレビュー会議やゲート」ではなく、継続的で証拠に基づいたものになるわけです。組織横断で API 品質を俯瞰し、リスクの所在を特定し、アーキテクチャや契約のドリフトがどこで起きているかを把握し、定期監査ではなく継続的に検証されるポリシーを確立できるようになります。

ですから Specmatic の行き先を考えるとき、私はそれを「API テスト機能を増やすこと」としては捉えていません。より大きなビジョンは、ソフトウェア開発ライフサイクルそのものを、ますます実行可能にしていくことです。

Executable Intent: 作る前に、提案しているものを体験し検証できるか。

Executable Specifications: 契約そのものが高品質で、意味的に妥当で、実行に耐えると確立できるか。

Executable Architecture: すべての部品が存在する前に、システムがどう協働するかを走らせて検証できるか。

Executable Contracts: すべての実装が約束を守っていることを継続的に証明できるか。

AI Engineering Harness: 自律的なコーディングエージェントに、決定論的フィードバックのもとで作り・直すためのガイドとセンサーを与えられるか。

Continuous Governance: 組織は自らの API エコシステムの品質・互換性・進化を継続的に理解できるか。

私はますます、Specmatic を AI 駆動の API エンジニアリングにおける trust layer（信頼の層） として捉えるようになっています。AI は、私たちがソフトウェアを設計・生成する速度を劇的に上げるでしょう。しかし、最終的に解くべき問題は生成の速度ではありません。生成が安く速くなるほど、重要になってくるのは確信 (confidence) のほうです。意図が正しく仕様へ翻訳されたという確信。仕様そのものが健全だという確信。アーキテクチャが機能するという確信。生成された実装が契約に適合しているという確信。そして、システムが継続的に進化してもそれらが真であり続けるという確信。

顧客の中には、この考えを confidence engineering と呼び始めた人たちもいて、私はこれは有用な捉え方だと思っています。私たちは、人間が手作業でソフトウェアを検分して確信を得ていた時代から、確信そのものを開発システムに作り込む必要がある時代へ移りつつあります。そこが Specmatic の向かう先です。複雑なソフトウェアシステムを人間と AI エージェントが確信をもって作り、進化させるために必要な、実行可能な仕様・決定論的フィードバック・継続的な可視性を提供する trust layer である、ということです。