SpecScore vs Tessl

仕様駆動開発（SDD）とは、意図した振る舞いの仕様を、コードより先に書くことです。Tessl（Tessl AI Ltd）は、2026年10月30日時点で、エージェント活用のプラットフォームです。コーディングエージェントが読み込むスキル、ルール、プラグインのためのレジストリとコントロールプレーンです。「仕様をソースとする」は、Tessl の 2025年6月のエッセイにおける、より強い主張です。長く残る成果物は仕様であり、コードはそこから導き出されます。SpecScore はその仕様のためのオープンソースのファイルフォーマットであり、コマンドラインインターフェース（CLI）が検査します。継続的インテグレーション（CI）、つまり提案された変更のたびに走る自動検査が、このリポジトリではその検査を実行します。

最終更新：2026年10月30日

共通点。

どちらも、意図を残す場所としてプロンプトは弱い、と言います。書かれた仕様はチャットより長く残るべきです。
どちらも、AI のコーディングエージェントがコードを編集する前に仕様を読むことを期待します。
どちらも、要件にテストを付けられるので、「完了」は指させるものになります。

Tessl が得意なこと。

Tessl には混同しやすい二つの面があります。以下は、2026年10月30日に読んだページに基づき、それらを分けて記します。

仕様をソースとする、はっきりした論

Simon Maple の 2025年6月27日のエッセイは、プロダクト要求文書（PRD）、つまり何を作るかを人に向けて書いた散文は、たいてい古くなり、コードだけが唯一の正しい情報源になる、と述べます。エッセイの対案は、変える対象は仕様であり、LLM がそこからコード、テスト、文書を生成する、というものです。これはスローガンではなく、一つの立場です。

エージェントの文脈のためのプラットフォーム

Tessl のドキュメントは、レジストリ、スキルを走査して採点するガバナンス、評価（evals）、エージェントを横断する可観測性を説明しています。ドキュメントは、スキルはリポジトリ内の平易な成果物であり、プラットフォームは Claude Code、Cursor、Copilot、Gemini などと動く、と述べます。そこでの採点はスキルの採点であり、製品仕様の採点ではありません。

シェル検査付きの公式な仕様駆動タイル

tessl-labs/spec-driven-development タイルは、公開タイルリポジトリで MIT ライセンスです。エージェントに、ヒアリングし、.spec.md を書き、承認を待ってから実装するよう教えます。レジストリのページは scripts/validate-specs.sh と scripts/check-spec-links.sh を、フロントマター、targets、[@test] のリンクのために挙げています。同じページは、このタイルが指針となる文脈であり、特別なコマンドもフレームワークもない、と述べています。

機能比較。

「仕様をソースとする」は Tessl のエッセイです。タイルは、今日のプラットフォームの上に載るスキルパックです。SpecScore は、版のあるリンターを持つフォーマットです。

機能	Tessl	SpecScore
主な役割	エージェントスキルのプラットフォームに加え、仕様駆動のタイルと、仕様をソースとする 2025 年のエッセイ	オープンな仕様フォーマット + CLI
仕様とは何か	エッセイ: 長く残り、コードがそこから生成されるソース。タイル: エージェントが実装の対象とし、コードは手元に残す .spec.md。	コードのそばにある契約。Lint はコードを再生成しません。
仕様の形	タイル: YAML フロントマター、targets のグロブ、テストファイルへの [@test] リンク	Markdown + YAML、`REQ: slug`、Given/When/Then
仕様の検査	そのタイルのフロントマターとリンクのための、タイルに同梱されたシェルスクリプト	このリポジトリの CI で、SpecScore フォーマットに対する specscore spec lint。`/score` は手動の AI 採点です。
ライセンス	タイルは MIT です。プラットフォームは製品です。ドキュメントは、プラットフォームのソースコードを公開していません。	CC BY 4.0 のフォーマット · Apache-2.0 の CLI
価格	2026年10月30日に読んだ Tessl のホームページは、無料枠（1 つのワークスペースで月 1,000 クレジット）と、有料のエンタープライズプランを説明しています。	フォーマットにも CLI にも料金はありません

SpecScore が加えるもの。

公開されたフォーマットであり、タイルのスクリプトではない

タイルのシェルスクリプトが検査するのは、そのタイルがエージェントに書かせた .spec.md です。SpecScore が検査するのは、このサイトに文書化されたフォーマットです。dogfood.yml はピン留めした specscore のリリースを導入し、specscore spec lint を実行します。/score はそのジョブではありません。AI のレビュアーが問題を報告したときにゼロ以外で終了する、手動のスキルです。

$ specscore spec lint

features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found
features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds
features/apply-discount/refunds:0 [error] readme-exists: README.md not found

3 violations found (3 errors)

どちらの場合もコードは手元に残る。エッセイはさらに先へ進む

2025 年のエッセイは、コードを仕様から再生成すべきだ、と述べます。2026年10月30日に読んだページのタイルは、承認された仕様に対してエージェントが実装する、としており、ソースツリーを置き換えるコンパイラは説明していません。SpecScore がコードを取り上げることはありません。仕様はレビューされる契約であり、コードは手元に残ります。

要件の同一性

タイルは要件を、targets と [@test] でファイルに向けます。SpecScore は要件を REQ: slug と名付けるので、ファイルが動いたあとも、計画、タスク、コミットトレーラーがそれを引用できます。

使い分けの指針。

Tessl を選ぶのは…

多くのエージェントとリポジトリで共有するスキルのために、レジストリ、評価、ガバナンスが必要なとき。
仕様をソースとするエッセイの流れを、指針となるタイルとして欲しいとき。ヒアリングし、.spec.md を承認し、それから実装します。
すでに Tessl のプラットフォームを契約している、または試していて、そのレジストリの仕様タイルが欲しいとき。

SpecScore を使うべきなのは…

Tessl を導入しないリポジトリを含め、仕様フォーマットそのものが CI で妥当でなければならないとき。
要件 ID と、モデルを呼ばないリンターが欲しいとき。
スキルのプラットフォームとは別に、クリエイティブ・コモンズのライセンスでフォーマットをオープンソースにしたいとき。

仕様をソースとし、検査できる仕様を。

古くなった PRD はコードに負ける、という Tessl のエッセイは正しいです。仕様が信頼する対象であり続ける方法が、フォーマットの検査です。SpecScore は仕様からアプリケーションを生成しません。構造、リンク、状態が誤っているときに、仕様を CI で失敗させます。

プラットフォームとタイルが欲しいなら Tessl を。プルリクエストが証明しなければならないのが git の中の成果物なら SpecScore を。

出典。

下の公開ページは 2026年10月30日に読みました。価格、プラン名、リリースの線は変わります。

他の比較。

同じフォーマットを、他の仕様駆動のツールと並べます。

まとめて一ページに: 2026年の仕様駆動開発ツール。

この比較は公開されているドキュメントとソースコードに基づいています。誤りや古い情報がありますか？修正issueを作成. 他のツールとの比較をご希望ですか？リクエスト.