# SpecScore vs Tessl

Canonical: https://specscore.md/ja/vs/tessl/

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

## 共通点。

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

## Tessl が得意なこと。

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

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

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

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

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

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

[tessl-labs/spec-driven-development](https://tessl.io/registry/tessl-labs/spec-driven-development) タイルは、[公開タイルリポジトリ](https://github.com/tesslio/spec-driven-development-tile) で 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](https://specscore.md/acceptance-criteria-specification) |
| 仕様の検査 | そのタイルのフロントマターとリンクのための、タイルに同梱されたシェルスクリプト | このリポジトリの CI で、SpecScore フォーマットに対する **specscore spec lint**。`/score` は手動の AI 採点です。 |
| ライセンス | タイルは [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) です。プラットフォームは製品です。ドキュメントは、プラットフォームのソースコードを公開していません。 | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) のフォーマット · [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) の CLI |
| 価格 | 2026年10月30日に読んだ [Tessl のホームページ](https://tessl.io/) は、無料枠（1 つのワークスペースで月 1,000 クレジット）と、有料のエンタープライズプランを説明しています。 | フォーマットにも CLI にも **料金はありません** |

## SpecScore が加えるもの。

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

タイルのシェルスクリプトが検査するのは、そのタイルがエージェントに書かせた `.spec.md` です。SpecScore が検査するのは、このサイトに文書化されたフォーマットです。[dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) はピン留めした [specscore](https://github.com/specscore/specscore-cli) のリリースを導入し、`specscore spec lint` を実行します。[/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) はそのジョブではありません。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 と、モデルを呼ばないリンターが欲しいとき。
- スキルのプラットフォームとは別に、クリエイティブ・コモンズのライセンスでフォーマットを [オープンソース](https://github.com/specscore/specscore) にしたいとき。

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

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

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

## 出典。

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

- [Tessl ドキュメント — Tessl とは](https://docs.tessl.io/)
- [Tessl のホームページ](https://tessl.io/)
- [Tessl ブログ — コードだけでは足りない理由（2025年6月27日）](https://tessl.io/blog/from-code-centric-to-spec-centric)
- [Tessl レジストリ — tessl-labs/spec-driven-development](https://tessl.io/registry/tessl-labs/spec-driven-development)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [specscore/specscore — dogfood の CI ワークフロー](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills — /score スキル](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md)
- [specscore/specscore — CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli — Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)