SDDツール群の全体像 ― AgentOS・Speckit・Backstage整理

SDD（仕様駆動開発）の話題になると、最近は必ず「ツール」の名前が出てきます。
AgentOS、Speckit、Backstageなどです。しかし多くの議論が混乱する理由は、これらが同じ種類のツールとして語られてしまうことです。

先に整理してしまうと、これらは競合していません。
それぞれ解決している問題の層が違います。

SDDは単なるドキュメント手法ではありません。仕様を中心に開発を回すということは、仕様を「どこに置き」「誰が使い」「どう更新するか」という運用問題になります。
ツールはこの運用の異なる部分を担当しています。本記事では、SDDツール群の全体像を分解して説明します。

SDDツールを分類する3つの層

まずSDDのツールは大きく3層に分かれます。

層	役割	扱うもの
実行層	仕様を動かす	振る舞い
管理層	仕様を維持する	知識
基盤層	仕様を共有する	組織

この分類を知らないと、「どのツールを導入すべきか」が永遠に決まりません。

実行層 ― AgentOS系ツール

AgentOS系のツールは、仕様を“実行可能なもの”として扱います。
ここでいう実行とは、プログラムとして動かすことだけではありません。仕様を入力として振る舞いを生成・検証する仕組みを指します。

この層が解決する問題は、次のものです。

• 仕様から挙動を確認する
• 仕様からテストを生成する
• 仕様と実装の差分を検出する

つまり、仕様を静的な文書ではなく振る舞いの定義として扱います。
SDDの中でも最も「開発」に近い領域です。

ただし注意点があります。
AgentOS系ツールは仕様の正しさを保証しません。保証するのは「仕様と実装の一致」です。仕様自体の誤りは検出できません。

管理層 ― Speckit系ツール

Speckit系ツールは、仕様の管理に焦点があります。
実行ではなく、更新・履歴・関係性を扱います。

解決している問題は、意外と地味です。

• 仕様の変更履歴を追跡する
• 関連仕様の影響範囲を知る
• 用語の定義を統一する

これは開発者が軽視しがちな領域ですが、SDDでは最も重要な部分です。
なぜなら、仕様が壊れる原因の多くは「間違い」ではなく古さだからです。

Speckit系は、仕様をコードのように扱います。
レビュー・差分・履歴が存在し、仕様の更新が開発プロセスに組み込まれます。

ただし、これ単体では挙動確認はできません。
管理はできますが、実行はしません。

基盤層 ― Backstage系ツール

Backstageのような開発ポータルは、さらに別の問題を解決します。
それは「誰が仕様を使うのか」です。

組織が大きくなると、仕様は存在しても発見されません。
存在するが参照されない、という状態になります。

この層が扱うのは次の問題です。

• どこに仕様があるか分からない
• サービスの責任者が不明
• 依存関係が見えない

Backstage系ツールは、仕様そのものを改善するわけではありません。
仕様を見つけられる状態を作るのが役割です。

SDDにおいて仕様は共有資産です。
共有できなければ、どれだけ良い仕様でも機能しません。

なぜ混乱が起きるのか

これらのツールが同時に語られる理由は、すべてが「仕様」に関係しているからです。
しかし対象が違います。

ツール層	対象
AgentOS	挙動
Speckit	知識
Backstage	組織

同じ仕様でも見ている面が違います。
そのため、1つ導入してもSDDが完成するわけではありません。

よくある失敗パターン

SDDツール導入でよく起きる問題があります。
「1つのツールで解決しようとする」ことです。

例えばAgentOS系だけ導入した場合：

• 実行できる仕様は増える
• しかし古い仕様が残る
• 結果として信頼が落ちる

Speckit系だけの場合：

• 整理された仕様は増える
• しかし開発と結びつかない
• 参照されなくなる

Backstage系だけの場合：

• 情報は見つかる
• しかし正しいか分からない

どれも部分的には成功しています。
しかしSDDとしては成立しません。

リスクと注意点

重要な注意点があります。
ツールを入れてもSDDは始まりません。

SDDの本質は「仕様が意思決定に使われること」です。
ツールは保存・実行・共有を助けますが、判断はしません。

ツール導入が目的になると、仕様の運用設計が行われません。
結果として、ツールは増えますが仕様は使われません。

どう考えるべきか

SDDツールは選択するものではなく、役割で考えるべきです。

• 仕様を動かす仕組みはあるか
• 仕様を更新する仕組みはあるか
• 仕様を見つける仕組みはあるか

この3つが揃ったとき、初めて仕様が組織で機能します。

SDDにおけるツールは、設計を自動化するものではありません。
仕様が流れる経路を作るものです。

仕様は書くだけでは資産になりません。
参照され、更新され、検証されたときに初めて機能します。ツールの位置づけを理解すると、どこが欠けているのかが見えるようになります。