---
title: ループエンジニアリングで再考する仕様書駆動開発
tags: 
author: [laiso 𝕏](https://www.docswell.com/user/laiso)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/KE4W33LZJ1.jpg?width=480
description: 仕様駆動開発を、AIエージェント時代の「文脈を設計する技術」として捉え直す。仕様、計画、検証、エビデンスを一度きりの成果物ではなく、次の実行へ戻るループとして扱い、ドキュメントが開発の判断と再現性をどう支えるかを整理、ソフトウェア開発の関心レイヤーがコードからドキュメントに移っていることをまとめます
published: June 14, 26
canonical: https://www.docswell.com/s/laiso/ZY8VG4-sdd-in-loop-engineering
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/KE4W33LZJ1.jpg)

ループエンジニアリングで
再考する仕様書駆動開発


# Page. 2

![Page Image](https://bcdn.docswell.com/page/L71Y11LDJG.jpg)

仕様書駆動開発とは実装前に
合意を作る型
要求、設計、タスク、完了条件を先に言葉にして、何を作るかを揃えてから
実装する。
先に書くのは、きれいな仕様書そのものではない。
実装前に、目的、制約、受入条件、作業単位を揃える。
その合意が、エージェントへ渡す最初のコンテキストになる。
仕様、計画、タスク、実装の順に進む
各段階でMarkdown成果物を作る
エージェントへ構造化した文脈を渡す
GitHub Spec Kit


# Page. 3

![Page Image](https://bcdn.docswell.com/page/G7WG88V8E2.jpg)

登場時の目的
仕様、設計、タスクで出力範囲を狭め、AIが逸れないようにする。最初は、
コード生成を制御する方法論として読めた。
仕様を先に書き、作るものを固定する
設計とタスクへ分け、出力のブレを減らす
人間が作ったレールの上でAIにコードを書かせる
要求、設計、タスクを3つのファイルに分ける
高レベルのアイデアを実装計画へ変える
タスク実行の進捗を追跡する
Kiro docs / Specs


# Page. 4

![Page Image](https://bcdn.docswell.com/page/4JZL8849E3.jpg)

ループエンジニアリングとは
Addy Osmaniの記事では、Peter SteinbergerとBoris Chernyの発言を並
べて、人間が毎回promptする段階から、loopがagentをpromptする段階
への変化として整理している。
Peter Steinberger: coding agentを毎回promptするのではなく、
agentをpromptするloopを設計する。
Boris Cherny: Claudeをpromptするloopが走り、人間の仕事は
loopを書くことになる。
仕様書駆動開発も、コード出力の制御からループの文脈設計へ読み替
えられる。
Peter Steinberger と Boris Cherny の発言を並
べて紹介
loop engineeringを、agentにpromptする
systemを設計することとして説明
recursive goalと完了までの反復として捉える
記事: Addy Osmani / Loop Engineering


# Page. 5

![Page Image](https://bcdn.docswell.com/page/YE6WPP3DEV.jpg)

ゴール単位の委任
Ralph Loopは、ゴールを置き、完了条件を確認し、未完了なら同じゴール
へ戻す発想を示した。そのコンセプトは、/goalのような標準機能に取り込
まれつつある。
Ralph Loop: ゴール、完了条件、未完了時の再実行をひとつのルー
プにする。
/goal: 達成したい状態を渡し、計画、実行、確認をエージェントに委
ねる。
仕様は、ゴール、制約、受入条件としてループに渡す文脈へ変わる。
Ralph Loop -> ゴール + 完了条件 -> /goal -> 計画 -> 実行 -> 確認
Stop hook が終了を止める
completion promise で完了条件を置く
未完了なら同じプロンプトを戻す
GitHub: Ralph Wiggum Plugin


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GE5MKKL8E4.jpg)

人間はループを設計する
Anthropicの文脈では、agentのループは実行のたびに履歴、ツール結果、
外部データを増やす。人間は、その中から次の推論へ何を戻すかを設計す
る。
ループが回るほど、次のターンに使えそうな情報は増える。
全部を入れると、文脈は重くなり、重要な情報が埋もれる。
だから、目的、観測結果、判断、未完了の理由を選び直して戻す。
実行 -> 観測 -> 選別 -> 次のコンテキスト -> 再実行
agent loop は次ターンに関係し得る情報を増や
す
context engineering は限られた文脈へ何を入れ
るかを選ぶこと
promptを書く一回の作業ではなく、毎ターンの
反復的な調整になる
Anthropic / Effective Context Engineering


# Page. 7

![Page Image](https://bcdn.docswell.com/page/9729WWLVJR.jpg)

ループを次回へつなぐには、コード差分だけでなく、何を目指し、何を確認
し、なぜ戻すのかが必要になる。それらはソースコードだけには残らない。
ゴール
制約
判断
検証
未完了理由
次の入力
何を達成しようとしているか
守る条件は何か
なぜその進め方にしたか
何で完了と見たか
なぜ戻す必要があるか
次回に何を渡すか
agent loop は情報を増やす
次の推論に必要な文脈を選ぶ
文脈は毎ターン更新される作業対象になる
Anthropic / Effective Context Engineering


# Page. 8

![Page Image](https://bcdn.docswell.com/page/DJY4LLQQ7M.jpg)

コードだけでは意図と理解が
残らない
エージェント時代は、コードを生んだ会話や途中の編集も開発履歴になる。
最終差分だけでは、なぜそう書かれたかを次の人間やエージェントが追いに
くい。
コードを生成する会話がソフトウェアの実質的な
これまで
これから
sourceになりつつある
コード差分 -> テスト -> あと
追いの説明
ゴール -> 判断 -> 検証 ->
コード + エビデンス -> 次の
入力
メッセージとその編集を並べて記録する
エージェントもコードの背後にある文脈を参照で
きる
Zed Blog / Software Is Made Between Commits


# Page. 9

![Page Image](https://bcdn.docswell.com/page/V7NY44K2E8.jpg)

エビデンスで意図を記録する
コードだけで失われやすい意図を、説明、実行コード、出力、検証条件とし
て残す。次のエージェントは、主張ではなく再現できる証拠から再開でき
る。
説明
実行
出力
検証
なぜ確認したか
どのコードを動かしたか
何が返ったか
完了条件と合っているか
説明、実行コード、出力をMarkdownにまとめる
verifyでコードブロックを再実行し、出力差分を
確認する
エージェントの作業を読める文書と再現可能な証
拠にする
GitHub: simonw/showboat


# Page. 10

![Page Image](https://bcdn.docswell.com/page/YJ9PQQVD73.jpg)

ストックとフロー
あらかじめ設置しておく文脈と、実行中に生まれる文脈を分ける。エビデン
スは基本的にフローで、次回も使うものだけ仕様、ルール、スキルへ戻す。
ストック
ストック
フロー
フロー
昇格
AGENTS.md / CLAUDE.md / rules
SKILL.md / hooks / settings
plan / tasks / tests
Artifacts / evidence / recordings
次回も使うものだけ戻す
Artifact はagentが作る構造化されたdeliverable
タスクを進めながら進捗と思考を人間へ伝える
plans、diffs、browser recordingsなどを検証
可能な形にする
Google Antigravity Docs / Artifacts


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GJ8DGGP5JD.jpg)

残した文脈が次の作業の
入力になる
仕様、判断、検証、エビデンスが次の実行で再利用されるなら、それは一度
きりのメモではなく保守すべき資産になる。
仕様
判断
検証
エビデンス
何を作るかを再利用する
同じ議論を繰り返さない
完了条件を引き継ぐ
次の実行を始める
毎ターン、必要な文脈を選ぶ
蓄積した情報を次の行動へ渡す
文脈の管理がエージェントの性能に直結する
Anthropic / Effective Context Engineering


# Page. 12

![Page Image](https://bcdn.docswell.com/page/LJLMGG13ER.jpg)

ドキュメントによる
ループエンジニアリング
仕様書駆動開発は、コード生成を制御するための仕様作成に限られない。仕
様、判断、検証、エビデンスを更新しながら次の実行へ戻すループとして捉
え直せる。
仕様
判断
検証
エビデンス
何を作るかを次の実行へ渡す
なぜそうしたかを残す
再確認できる形にする
次の実行へ戻す
保守は仕様を進化させることになる
チームの意図は自然言語、設計資産、原則で表さ
れる
仕様が中心のsource of truthになり、計画とコー
ドは出力側になる
GitHub Spec Kit / spec-driven.md


# Page. 13

![Page Image](https://bcdn.docswell.com/page/47MYQQWM7W.jpg)