ループエンジニアリングで再考する仕様書駆動開発
-- Views
June 14, 26
スライド概要
仕様駆動開発を、AIエージェント時代の「文脈を設計する技術」として捉え直す。仕様、計画、検証、エビデンスを一度きりの成果物ではなく、次の実行へ戻るループとして扱い、ドキュメントが開発の判断と再現性をどう支えるかを整理、ソフトウェア開発の関心レイヤーがコードからドキュメントに移っていることをまとめます
関連スライド
各ページのテキスト
ループエンジニアリングで 再考する仕様書駆動開発
仕様書駆動開発とは実装前に 合意を作る型 要求、設計、タスク、完了条件を先に言葉にして、何を作るかを揃えてから 実装する。 先に書くのは、きれいな仕様書そのものではない。 実装前に、目的、制約、受入条件、作業単位を揃える。 その合意が、エージェントへ渡す最初のコンテキストになる。 仕様、計画、タスク、実装の順に進む 各段階でMarkdown成果物を作る エージェントへ構造化した文脈を渡す GitHub Spec Kit
登場時の目的 仕様、設計、タスクで出力範囲を狭め、AIが逸れないようにする。最初は、 コード生成を制御する方法論として読めた。 仕様を先に書き、作るものを固定する 設計とタスクへ分け、出力のブレを減らす 人間が作ったレールの上でAIにコードを書かせる 要求、設計、タスクを3つのファイルに分ける 高レベルのアイデアを実装計画へ変える タスク実行の進捗を追跡する Kiro docs / Specs
ループエンジニアリングとは 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
ゴール単位の委任 Ralph Loopは、ゴールを置き、完了条件を確認し、未完了なら同じゴール へ戻す発想を示した。そのコンセプトは、/goalのような標準機能に取り込 まれつつある。 Ralph Loop: ゴール、完了条件、未完了時の再実行をひとつのルー プにする。 /goal: 達成したい状態を渡し、計画、実行、確認をエージェントに委 ねる。 仕様は、ゴール、制約、受入条件としてループに渡す文脈へ変わる。 Ralph Loop -> ゴール + 完了条件 -> /goal -> 計画 -> 実行 -> 確認 Stop hook が終了を止める completion promise で完了条件を置く 未完了なら同じプロンプトを戻す GitHub: Ralph Wiggum Plugin
人間はループを設計する Anthropicの文脈では、agentのループは実行のたびに履歴、ツール結果、 外部データを増やす。人間は、その中から次の推論へ何を戻すかを設計す る。 ループが回るほど、次のターンに使えそうな情報は増える。 全部を入れると、文脈は重くなり、重要な情報が埋もれる。 だから、目的、観測結果、判断、未完了の理由を選び直して戻す。 実行 -> 観測 -> 選別 -> 次のコンテキスト -> 再実行 agent loop は次ターンに関係し得る情報を増や す context engineering は限られた文脈へ何を入れ るかを選ぶこと promptを書く一回の作業ではなく、毎ターンの 反復的な調整になる Anthropic / Effective Context Engineering
ループを次回へつなぐには、コード差分だけでなく、何を目指し、何を確認 し、なぜ戻すのかが必要になる。それらはソースコードだけには残らない。 ゴール 制約 判断 検証 未完了理由 次の入力 何を達成しようとしているか 守る条件は何か なぜその進め方にしたか 何で完了と見たか なぜ戻す必要があるか 次回に何を渡すか agent loop は情報を増やす 次の推論に必要な文脈を選ぶ 文脈は毎ターン更新される作業対象になる Anthropic / Effective Context Engineering
コードだけでは意図と理解が 残らない エージェント時代は、コードを生んだ会話や途中の編集も開発履歴になる。 最終差分だけでは、なぜそう書かれたかを次の人間やエージェントが追いに くい。 コードを生成する会話がソフトウェアの実質的な これまで これから sourceになりつつある コード差分 -> テスト -> あと 追いの説明 ゴール -> 判断 -> 検証 -> コード + エビデンス -> 次の 入力 メッセージとその編集を並べて記録する エージェントもコードの背後にある文脈を参照で きる Zed Blog / Software Is Made Between Commits
エビデンスで意図を記録する コードだけで失われやすい意図を、説明、実行コード、出力、検証条件とし て残す。次のエージェントは、主張ではなく再現できる証拠から再開でき る。 説明 実行 出力 検証 なぜ確認したか どのコードを動かしたか 何が返ったか 完了条件と合っているか 説明、実行コード、出力をMarkdownにまとめる verifyでコードブロックを再実行し、出力差分を 確認する エージェントの作業を読める文書と再現可能な証 拠にする GitHub: simonw/showboat
ストックとフロー あらかじめ設置しておく文脈と、実行中に生まれる文脈を分ける。エビデン スは基本的にフローで、次回も使うものだけ仕様、ルール、スキルへ戻す。 ストック ストック フロー フロー 昇格 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
残した文脈が次の作業の 入力になる 仕様、判断、検証、エビデンスが次の実行で再利用されるなら、それは一度 きりのメモではなく保守すべき資産になる。 仕様 判断 検証 エビデンス 何を作るかを再利用する 同じ議論を繰り返さない 完了条件を引き継ぐ 次の実行を始める 毎ターン、必要な文脈を選ぶ 蓄積した情報を次の行動へ渡す 文脈の管理がエージェントの性能に直結する Anthropic / Effective Context Engineering
ドキュメントによる ループエンジニアリング 仕様書駆動開発は、コード生成を制御するための仕様作成に限られない。仕 様、判断、検証、エビデンスを更新しながら次の実行へ戻すループとして捉 え直せる。 仕様 判断 検証 エビデンス 何を作るかを次の実行へ渡す なぜそうしたかを残す 再確認できる形にする 次の実行へ戻す 保守は仕様を進化させることになる チームの意図は自然言語、設計資産、原則で表さ れる 仕様が中心のsource of truthになり、計画とコー ドは出力側になる GitHub Spec Kit / spec-driven.md