SDD（Spec-Driven Development）とLoop Engineeringの関係 ― superpowersは両者を統合したハーネスだった

はじめに

AIコーディングの界隈で、2025年後半から2つの言葉がよく聞かれるようになりました。
ひとつが Spec-Driven Development（SDD / スペックドリブン開発） です。
もうひとつが Loop Engineering（ループエンジニアリング） です。

どちらも「エージェントにコードを書かせるときの作法」を指しますが、両者の関係を整理した日本語の記事はあまり見かけません。
そこで本記事では、この2つがどう違い、どう補い合うのかを、一次情報（公式リポジトリ・ツール本体）に当たって整理します。

そして後半では、両者を1本のパイプラインに統合した実装例として superpowers（Jesse Vincent / Prime Radiant 製。Claude Code を含む複数のコーディングエージェントに対応するプラグイン）を取り上げます。
superpowers は「SDD」とも「Loop Engineering」とも自称していません。
にもかかわらず、その動作構造は両概念をきれいに実装しています。
この「名乗っていないのに両方やっている」という発見が、本記事を書いた一番の動機です。

対象読者

• Claude Code / Codex などのコーディングエージェントを日常的に使う方
• 「エージェントに長く自走させたいが、品質が安定しない」と感じている方
• SDD や Loop Engineering という言葉は聞くが、関係を整理できていない方

前提・実行環境

• 調査時点: 2026年6月
• superpowers: v6.0.3（プラグイン本体のスキル定義を直接読解）
• 参照したツール: GitHub Spec Kit / Tessl / AWS Kiro / superpowers

おことわり

本記事は解説と私見の混在した記事です。
事実（各ツールの仕様・公開時期）は一次情報で裏取りした範囲で言い切ります。
一方、「superpowers が SDD と Loop Engineering の統合実装である」という位置づけは筆者の分析です。
superpowers の作者がそう名乗っているわけではない点は、先にお断りしておきます。
異論は歓迎します。

一言でいうと

長くなるので、先に要点をまとめます。

• SDD は「何を作るか」を仕様で先に固める上流の規律です。
• Loop Engineering は「どう安全に回すか」を有界ループで制御する実行の規律です。
• 両者は競合しません。SDD の受け入れ基準が、そのまま Loop Engineering の停止条件になるという形で噛み合います。
• そして superpowers は、この2つを設計段階から一体で実装したハーネスでした。

「ハーネス」という言葉は本記事で何度も出てきます。
ここでは「エージェントが規律から逸脱しないように縛る仕組み（馬具・安全帯）」くらいの意味で使います。

Loop Engineeringとは（プロンプトの次の一手）

まず Loop Engineering から見ていきます。
発端は、Peter Steinberger 氏（X: @steipete）の2026年6月の投稿でした。

もうコーディングエージェントにプロンプトを書くべきではない。エージェントにプロンプトを与えるループを設計すべきだ。

Claude Code の開発に携わった Boris Cherny 氏（X: @bcherny）も、別の角度から同じことを述べています。

私はもう Claude にプロンプトを書かない。走り続けているループがある。Claude にプロンプトを与え、何をすべきか考えているのはそのループだ。私の仕事はループを書くことだ。

要するに「プロンプトを書く人」から「プロンプトを書くシステムを書く人」へ、仕事のレイヤーが一段上がるという主張です。

ループの基本形

ループとは、次の4つを行う小さなプログラムです。

1. あなたの代わりにエージェントへプロンプトを与える
2. エージェントが生み出したものを読む
3. 完了したかどうかを判断する
4. 完了していなければ、エラーや次の手とともに再度プロンプトを与える

図にすると、いつも同じ形になります。

ゴールを定め、実行し、チェックし、エラーを差し戻し、チェックが通るかループ自身が止まるまで繰り返します。

良いループの4つの問い

Forward Future（Matthew Berman 氏ら）が公開している「Loop Library」では、良いループは次の4つの問いに答えるとされています。

1. エージェントは何を達成しようとしているか
2. 直近の試行が効いたかをどう判断するか
3. 学んだことをどう扱うか
4. いつ終える、あるいは人に助けを求めるか

ここで大事なのは、ループは「永遠に走る許可」ではないという点です。
良いループは意図的に**有界（bounded）**で、本物のチェック・明確な停止点・人間に制御を返す瞬間を持ちます。
コストの焦点も、トークン数から「反復回数」へ移ります。

SDD（Spec-Driven Development）とは

次に SDD です。
こちらは Loop Engineering よりやや早く、2025年9月前後に主要ツールが相次いで登場しました。

定義と3つのレベル

SDD は「仕様（spec）を第一義的な成果物とし、コードを派生的な成果物として扱う開発アプローチ」です（arXiv:2602.00180v1, 2026年1月）。
仕様が「意図の source of truth」として機能し、エージェントはその仕様に基づいてコードを生成・検証します。

Birgitta Böckeler 氏（Thoughtworks）は SDD を3つのレベルに分類しています（MartinFowler.com, 2025年10月）。

登場背景（vibe codingへの反省）

SDD は、構造なしのアドホックなプロンプティング（いわゆる vibe coding）への反省として生まれました。
エージェントが意図を推測して実装すると、実装と意図の乖離が積み上がります。
API のハルシネーションや、スケール時の仕様ドリフトも起きます。
仕様を先に成文化することで、この「意図とコードの間隙」を埋めるのが狙いです。

代表的なツール

主要な実装は3つです。
中核ワークフローは三者でほぼ共通しています。

AWS Kiro が採用する EARS（Easy Approach to Requirements Syntax）は、WHEN [trigger] the system shall [response] のような構造化された要件構文です。
あいまいさを減らし、テスト可能性を高めることを狙っています。

中核ワークフロー

GitHub Spec Kit を代表例に取ると、フローは4段階です。

/specify → /plan → /tasks → /implement
 ↓ ↓ ↓ ↓
 spec.md plan.md tasks.md コード生成
 (受入基準) (技術設計) (実行単位) (テスト先行)

• specify: ユーザーストーリーと受け入れ基準を spec.md として生成します。技術より「意図」を先に言語化します。
• plan: spec を読み、アーキテクチャ・データモデル・API 契約を生成します。簡潔性ゲートなどで品質をチェックします。
• tasks: plan を読み、独立して実装・テスト可能な小タスクに分解します。
• implement: テスト先行で実装します。

各フェーズが Markdown を生成し、次フェーズへ引き渡します。
フェーズはゲートを通過するまで次に進めません。

両者の関係：競合ではなく補完

ここからが本題です。
SDD と Loop Engineering は、よく似た言葉に見えて主眼が違います。
そして、その違いゆえに補い合えます。

共通点

両者は驚くほど多くの設計原則を共有しています。

相違点

一方で、力点は明確に異なります。

ひとことで言えば、SDD は「上流」、Loop Engineering は「実行時」を見ています。
時間軸が違うので、ぶつかりません。

SDDの各フェーズをループとして表現する

面白いのは、SDD の各フェーズが、そのまま Loop Engineering の「ループ」として書けることです。

[Specify ループ]
 ゴール: spec に受け入れ基準が揃うこと
 実行: エージェントがヒアリング・要件整理
 チェック: 人間が spec をレビューし承認
 終端: 承認（成功） / 未整理（再ループ）

[Implement ループ]
 ゴール: テスト全通過 かつ spec の受け入れ基準を満たす
 実行: エージェントがテスト先行で実装
 チェック: CI テスト + spec 照合
 終端: 全通過（成功） / テスト失敗（再ループ）

この見方をすると、SDD の spec に書かれた受け入れ基準は、Loop Engineering の「検証可能な停止条件」に直接対応します。
別々に語られてきた2つが、ここで1つの絵につながります。

互いの弱点を補う

補完関係は双方向です。

SDD が Loop Engineering を補う方向。
Loop Engineering はゴールの記述形式までは規定しません。
あいまいなゴールは、検証できない停止条件につながります。
SDD の specify フェーズが、EARS 構文や受け入れ基準としてゴールを精密化します。

Loop Engineering が SDD を補う方向。
SDD 単体では、逐次フェーズの待機時間が長くなりがちです。
ある検証記事（Scott Logic, 2025年11月）では、初回の機能実装でレビューに3.5時間以上を要したと報告されています。
「SDD はウォーターフォールの再来ではないか」という批判の本質はここにあります。
各フェーズの中に Loop Engineering の有界ループを埋め込めば、フェーズ内のフィードバックを速くできます。

実装例1：spec-kit-loop拡張（ビルド区間だけを包む）

ここまでは概念の話でした。
では、実際に両者を組み合わせた実装はあるのでしょうか。
あります。

GitHub Spec Kit の拡張カタログに、コミュニティ開発者 formin 氏が spec-kit-loop という拡張を申請しています（Issue #2977、2026年6月起票、現在クローズ済み）。
GitHub 公式ではなく第三者製で、MIT ライセンスです。
Addy Osmani 氏の Loop Engineering 論を、SDD に適用したものと明記されています。

特徴は、SDD のうち tasks → implement の区間だけを、有界・採点・署名つきのループで包む点です。
spec や plan は編集しません。
コマンドは5つです。

• /speckit.loop.define — ループを契約化します。目的・チェック可能な完了基準・反復予算・maker/checker の役割を定めます。停止条件のない無限ループは拒否します。
• /speckit.loop.run — Maker 役です。レビュー可能な増分を1つ生成し、ディスクへ書き出します。自己採点はしません。
• /speckit.loop.check — 独立した Checker 役です。別セッションで各完了基準を一次ソースに当て、pass / fail / uncertain を判定します。
• /speckit.loop.guard — 「技術者であり続ける」ためのチェックポイントです。理解度の負債を洗い出し、人間の署名ゲートを設けます。ループを閉じられる唯一のコマンドです。
• /speckit.loop.status — 予算を考慮した状態表示と、次の一手の推奨を返します。

設計思想は拡張本文に簡潔に書かれています。
「ループとは再帰的なゴールである。目的を定義し、完了するまでエージェントに反復させる。ただし『自分が技術者であり続けるつもりの人間』のように作る」。
SDD の spec が定義した受け入れ基準を、ループの checker が判定する停止条件として使う構造です。

ただし、この拡張がカバーするのは build 区間だけです。
仕様生成そのものは Spec Kit 側に任せます。
「もっと広く、上流から包んだものはないのか」と探して見つけたのが、次の superpowers でした。

実装例2：superpowers（全工程を1本に統合したハーネス）

superpowers は、Jesse Vincent 氏（GitHub: @obra / Prime Radiant）が公開しているコーディングエージェント向けのプラグインです。
MIT ライセンスで、初公開は2025年10月です。
Claude Code・Codex・Cursor・Gemini CLI・Copilot CLI など、複数のハーネスに対応しています。

superpowersとは

README は superpowers を「コーディングエージェントのための完結したソフトウェア開発方法論」と表現しています。
動作の流れはこうです。
エージェントは、何かを作れと言われても、いきなりコードに飛びつきません。
まず一歩下がって「本当に作りたいものは何か」を訊きます。
会話から仕様を引き出し、読める長さに分割して承認を取ります。
承認後に実装計画を組み、go と言われたらサブエージェント駆動で各タスクを実装・レビューしながら前進します。

注目したいのは、superpowers が 「SDD」とも「Loop Engineering」とも名乗っていない点です。
本体のスキル定義にも README にも、その用語は出てきません。
それなのに、動作構造は両概念をきれいに実装しています。

基本ワークフロー（7段階）

各スキルは条件が揃うと自動で発火します。
「提案」ではなく「必須」として扱われます。

1. brainstorming — 着手前に発火します。1問ずつ質問し、2〜3案を比較し、設計をセクション単位で承認させます。最終的に仕様を docs/superpowers/specs/ 配下に保存してコミットします。
2. using-git-worktrees — 設計承認後に発火します。隔離ワークスペースを作り、クリーンなテストベースラインを確認します。
3. writing-plans — 仕様から、2〜5分粒度のタスクへ分解した実装計画を作成します。各タスクは正確なファイルパス・完全なコード・検証手順を持ちます。
4. subagent-driven-development（または executing-plans）— 計画を実行します。タスクごとに新しいサブエージェントを起動し、仕様準拠とコード品質の2観点でレビューを挟みます。
5. test-driven-development — 実装中に発火します。RED-GREEN-REFACTOR を強制します。テストより先に書いたコードは削除します。
6. requesting-code-review — タスク間で発火します。計画に照らしてレビューし、重大度別に報告します。
7. finishing-a-development-branch — 全タスク完了時に発火します。テストを検証し、マージ / PR / 保持 / 破棄を選ばせ、ワークスペースを片付けます。

SDDとしての側面（上流の仕様規律）

前半の brainstorming と writing-plans が、SDD の specify / plan / tasks に対応します。

brainstorming には次のような「ハードゲート」が明記されています。

設計を提示しユーザーが承認するまで、いかなる実装スキルも呼ばず、コードも書かず、いかなる実装行動も取らない。これはどんなに単純に見えるプロジェクトでも適用される。

「単純すぎて設計不要」という言い訳を、仕組みとして封じています。

Loop Engineeringとしての側面（実行時の有界ループ）

中核は subagent-driven-development のタスク単位ループです。
これが Loop Engineering の「ゴール→実行→チェック→差し戻し→停止」を、maker / checker 分離つきで実装しています。

[タスクごとの有界ループ]
 ① implementer サブエージェントを起動（新コンテキスト = 文脈の隔離）
 └ TDD で実装・テスト・コミット・自己レビュー
 ② diff をファイル化 → task-reviewer を起動
 └ 2つの判定: 仕様準拠（過不足なし） + コード品質
 ③ Critical / Important があれば fix サブエージェントへ → ②へ再レビュー
 ④ 進捗台帳にタスク完了を追記
 → 残タスクがあれば①へ。なければ最終レビュー → finishing

Loop Engineering の各原則との対応は次の通りです。

特に印象的なのが、verification-before-completion というスキルの「鉄則」です。

検証なき完了の主張は、効率ではなく不誠実である。このメッセージで検証コマンドを実行していないなら、合格とは主張できない。

「should」「probably」「seems to」といった、検証を伴わない完了表現を明確に禁止しています。
これは Loop Engineering の「観測可能・再現可能な成功ゲート」と、思想がそのまま一致します。

spec-kit-loopとの違い

実装例1の spec-kit-loop と比べると、カバー範囲の差がはっきりします。

spec-kit-loop が「ビルド区間だけを有界ループ化」するのに対し、superpowers は上流の仕様規律と全工程の有界ループを最初から一体で設計しています。
ここがハーネスとしての完成度の差だと感じました。

なぜ規律が守られるのか（強制機構）

Loop Engineering も SDD も、守らなければ意味がありません。
superpowers の本質は、逸脱を構造的に難しくする強制機構にあります。

• セッション開始フックが、起動時とコンテキスト圧縮の後に「該当しそうならスキルを必ず使う」という指示を毎回注入します。
• ハードゲート（承認前の実装禁止）、必須サブスキル（次工程スキルの強制呼び出し）、鉄則（検証なき完了主張の禁止）で、各ゲートをスキップ不能にします。
• README は「Mandatory workflows, not suggestions（提案ではなく必須）」と明言しています。

「正しいやり方を知っている」ことと「毎回それを守れる」ことは別物です。
superpowers は後者を仕組みで担保しようとしています。

自作のエージェント運用で見えたこと

ここからは私見と体験です。

私は自作のAIエージェント運用環境を持っており、そこに以前から似たハーネスを組んでいました。
具体的には、次のような仕掛けです。

• 完了を「全チェック通過」と定義し、検証ログを示さずに「完了」と報告させない
• 出力前に、読み取り専用のレビュー役へ必ず通す（作成者と承認者を分ける）
• 重要な委譲はファイル出力で二重化し、返り値が空でもファイルから結果を回収する
• 同種の失敗を3回繰り返したら自動継続をやめ、別視点で立て直す

superpowers のスキル定義を読んで驚いたのは、これらがほぼ同じ発想で先に体系化されていたことです。
対応関係を並べると、こうなります。

• brainstorming のハードゲート ＝ 「3ステップ以上は計画から始める」
• verification-before-completion の鉄則 ＝ 「実物で確認するまで完了と言わない」（誤った成功報告の防止）
• 進捗台帳のディスク外部化 ＝ 「委譲結果はファイルを正として回収する」
• maker / checker 分離 ＝ 「レビュー役は読み取り専用で、自分では直さない」

逆に、superpowers から取り入れたいと思った差分も3つありました。

1. 仕様をコミットして living artifact にする点。私の環境は成果物を保存はしますが、仕様の版管理は弱めでした。
2. タスクを2〜5分・テスト付き・プレースホルダ禁止まで分解するwriting-plans の厳密さ。
3. 役割ごとのモデル選択（turn count beats token price）。安いモデルが2〜3倍のターンを食えば、結局は高くつくという指摘です。

「自分で組んでみて初めて、既存の体系の良さが分かる」という体験でした。
車輪の再発明ではありましたが、再発明したからこそ部品の意味が腹落ちした、とも思います。

まとめ

本記事の要点を再掲します。

• SDD は「何を作るか」を仕様で固める上流の規律です。
• Loop Engineering は「どう安全に回すか」を有界ループで制御する実行の規律です。
• 両者は競合せず、SDD の受け入れ基準が Loop Engineering の停止条件になる形で補完します。
• spec-kit-loop はビルド区間だけを、superpowers は全工程を、それぞれ両者の統合として実装しています。
• superpowers は両用語を名乗らないまま、設計段階から両方を一体で実装したハーネスでした。

エージェントを長く自走させたいなら、プロンプトの巧拙よりも「仕様＋ループ＋検証ゲート」という器の設計が効いてきます。
まずは小さく、ひとつのタスクに「明確な停止条件」と「独立した検証」を足すところから試してみてはいかがでしょうか。

参考文献

• GitHub Spec Kit 公式ブログ（Den Delimarsky, 2025-09-02） https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
• GitHub spec-kit リポジトリ https://github.com/github/spec-kit
• Kiro and the future of software development（AWS, Marc Brooker, 2025-07） https://kiro.dev/blog/kiro-and-the-future-of-software-development/
• Tessl SDD ブログ（Guy Podjarny, 2025-09-16） https://tessl.io/blog/how-tessls-products-pioneer-spec-driven-development/
• Exploring SDD with 3 tools（Birgitta Böckeler, MartinFowler.com, 2025-10-15） https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
• Loop Engineering（Addy Osmani, O'Reilly Radar, 2026-06-22） https://www.oreilly.com/radar/loop-engineering/
• Forward Future Loop Library（Matthew Berman） https://signals.forwardfuture.com/loop-library/
• spec-kit-loop（Issue #2977 / formin） https://github.com/github/spec-kit/issues/2977
• superpowers（Jesse Vincent / obra） https://github.com/obra/superpowers
• Scott Logic: Spec Kit 批判的検証（2025-11-26） https://blog.scottlogic.com/2025/11/26/putting-spec-kit-through-its-paces-radical-idea-or-reinvented-waterfall.html

本記事の調査・草稿作成には生成AIを用い、各ツールの仕様は一次情報（公式リポジトリ・プラグイン本体）で筆者が確認しました。