スペック駆動開発（SDD）を理解する: Kiro、Spec-Kit、Tessl

 (martinfowler.com)
27 ポイント 投稿者 GN⁺ 2025-10-20 | 3件のコメント | WhatsAppで共有
  • Spec-Driven-Development（SDD） は、AIベースのコーディングにおいてコードを書く前に 仕様書（spec）を先に作成 するアプローチであり、仕様書が開発者とAIの真実の源泉（source of truth）として機能する
  • SDDは 3つの実装レベル に分けられ、spec-first（仕様先行作成）、spec-anchored（保守のために仕様を保持）、spec-as-source（仕様を主要なソースファイルとして使い、開発者はコードを直接編集しない）へと段階的に発展する
  • Kiroは要件→設計→タスクの シンプルな3段階ワークフロー を提供し、spec-kitは憲法（constitution）という強力なルールベースのワークフローを使い、Tesslは仕様とコードを1:1でマッピングする spec-as-sourceアプローチ を試している
  • 3つのツールはいずれも 小さなバグ修正には過剰なプロセス を要求し、Markdownファイルのレビューがコードレビューより煩雑であり、大きなコンテキストウィンドウがあってもAIがすべての指示に正しく従えない限界がある
  • SDDは過去の モデル駆動開発（MDD）の失敗例 を想起させ、非決定性と非柔軟性という両方の欠点を抱えるリスクがあり、実プロジェクトでの有用性について検証が必要である

スペック駆動開発（SDD）の定義

  • SDDはコードを書く前に仕様書を先に作成 する「documentation first」アプローチで、仕様書が開発者とAIの双方にとって単一の真実の源泉（single source of truth）として機能する
  • GitHubは「ソフトウェア保守とは 仕様書の進化 を意味し、開発の共通言語がより高いレベルへ移動し、コードは最終段階のアプローチになる」と定義している
  • Tesslは「仕様書がコードではなく 主要な成果物 となる開発アプローチであり、仕様書は構造化されテスト可能な言語で意図を記述し、エージェントがそれに合わせてコードを生成する」と説明している
  • SDDは 3つの実装レベル に分かれる
    • Spec-first: よく構成された仕様書を先に作成し、AI支援開発ワークフローで使う
    • Spec-anchored: 作業完了後も仕様書を維持し、その機能の進化と保守に継続して活用する
    • Spec-as-source: 仕様書が時間が経っても主要なソースファイルとして維持され、開発者は仕様書だけを編集し、コードには直接触れない
  • すべてのSDDアプローチはspec-firstだが、すべてがspec-anchoredやspec-as-sourceを志向しているわけではなく、時間経過に伴う仕様書維持戦略 が曖昧だったり、完全に開かれていたりする場合が多い

仕様書（spec）とは何か

  • 仕様書は 自然言語で書かれた、構造化された行動指向の成果物 であり、ソフトウェア機能を表現し、AIコーディングエージェントに対するガイドとして機能する
  • 最も一貫した定義は、仕様書を 製品要件文書（PRD） にたとえるものだ
  • 仕様書はコードベース向けの 一般的なコンテキスト文書と区別 されるべきである
    • 一般的なコンテキストには、ルールファイル、製品およびコードベースの高レベルな説明が含まれ、一部のツールはこれを メモリバンク（memory bank） と呼ぶ
    • メモリバンクファイルはコードベースに関するすべてのAIコーディングセッションで関係するが、仕様書は特定の機能を生成または変更する作業にのみ関係する
  • 各SDDのバリエーションは、仕様書の構造、詳細レベル、プロジェクト内での整理方法について独自のアプローチを定義している

SDDツール評価の難しさ

  • SDDツールやアプローチを 実運用に近い形で評価 するのは非常に時間がかかる
    • さまざまな規模の問題やグリーンフィールド／ブラウンフィールドのプロジェクトで試す必要があり、中間成果物を表面的ではなく徹底的にレビューし修正する時間も必要となる
  • GitHubのspec-kitブログ記事は「重要なのは、あなたの役割が単に方向付けすることではなく 検証すること であり、各段階で振り返り改善しなければならない」と強調している
  • 3つのツールのうち2つは 既存コードベースへ導入するのにより多くの作業 が必要に見え、ブラウンフィールドのコードベースに対する有用性評価をさらに難しくしている
  • 実際のコードベースで一定期間使った人たちの報告を聞くまでは、実際にどう機能するのかについて未解決の疑問 が多く残る

Kiro

  • Kiroは3つのツールの中で 最もシンプルで軽量 なツールで、主にspec-firstアプローチに当たる
    • タスクやユーザーストーリーに使う例しか見当たらず、時間の経過とともに複数タスクにまたがって spec-anchored方式で要件文書を使う方法 への言及はない
  • ワークフロー: 要件 → 設計 → タスク
    • 各ワークフロー段階は1つのMarkdown文書で表現され、KiroはVS Codeベースのディストリビューション内でこの3段階を案内する

  • Kiroの主要コンポーネント

    • 要件（Requirements）
      • 各要件が「ユーザーストーリー」（As a...形式）を表す 要件リスト として構造化される
      • 受け入れ基準は GIVEN... WHEN... THEN... 形式を使う
    • 設計（Design）
      • コンポーネントアーキテクチャ図、データフロー、データモデル、エラー処理、テスト戦略、実装アプローチ、マイグレーション戦略などのセクションを含む
      • タスクによって 一貫した構造なのか、それとも変化するのかは不明
    • タスク（Tasks）
      • 要件番号で追跡されるタスクリスト
      • タスクを1つずつ実行し、タスクごとの変更をレビューできる 追加のUI要素 を提供する

  • Kiroのメモリバンク

    • Kiroはメモリバンクの概念を「steering」と呼ぶ
      • 内容は柔軟で、ワークフローが特定ファイルの存在に依存していないように見える
    • Kiroがステアリング文書の作成を求められた際に生成する 基本構造 は product.md、structure.md、tech.md である

Spec-kit

  • spec-kitは GitHub版のSDD で、さまざまな一般的コーディングアシスタント向けのワークスペース設定を生成できるCLIとして配布されている
  • 構造設定後は、コーディングアシスタントの スラッシュコマンドを通じて spec-kitとやり取りする
  • すべての成果物がワークスペースに直接配置されるため、取り上げた3つのツールの中で 最もカスタマイズしやすい

  • Spec-kitのワークフロー

    • ワークフロー: 憲法（Constitution） → 𝄆 仕様化（Specify） → 計画（Plan） → タスク（Tasks） 𝄇
    • spec-kitにおけるメモリバンクの概念は spec-drivenアプローチの前提条件 である
      • これを 憲法（constitution） と呼び、あらゆる変更に常に適用されるべき「不変」の高レベル原則を含む
      • ワークフローで多用される非常に強力なルールファイルである

  • Spec-kitの動作方式

    • 各ワークフロー段階（specify、plan、tasks）で bashスクリプトとテンプレートを使って ファイルおよびプロンプトのセットをインスタンス化する
    • ワークフローはファイル内のチェックリストを多用し、必要なユーザーへの確認、憲法違反、調査タスクなどを追跡する
      • 各ワークフロー段階における 「完了の定義（definition of done）」 のような役割を果たす（AIが解釈するため100%保証はない）
    • 1つの仕様書は 複数ファイルで構成 される
      • 例: data-model、plan、tasks、spec、research、api、component など8つのファイル

  • Spec-kitのアプローチ

    • GitHubは当初 spec-anchoredアプローチを志向 しているように見える
      • 「仕様書を静的な文書ではなく、プロジェクトとともに進化する生きた実行可能な成果物として再考しており、仕様書は共有された真実の源泉となる」
    • しかしspec-kitは生成されるすべての仕様書に対して ブランチを作成 するため、仕様書を機能の寿命ではなく 変更要求の寿命のあいだ生きる成果物 と見ているようにも解釈できる
    • コミュニティの議論でもこの混乱が語られており、spec-kitは依然としてspec-firstにとどまり、時間が経ってもspec-anchoredではないように見える

Tessl Framework

  • Tessl Frameworkは クローズドベータ段階 にあり、spec-kitのようにさまざまなコーディングアシスタント向けのワークスペースおよび構成構造を生成できるCLIとして配布されている
  • CLIコマンドは MCPサーバーとしても動作 する

  • Tesslの特徴

    • 3つのツールの中で 唯一spec-anchoredアプローチを明示的に志向 しており、spec-as-sourceレベルのSDDも探求している
    • Tesslの仕様書は保守・編集される主要成果物として機能でき、コードの先頭には // GENERATED FROM SPEC - DO NOT EDIT というコメントが付く
      • 現時点では仕様書とコードファイルの 1:1マッピング、すなわち1つの仕様書がコードベース内の1ファイルへ変換される
      • まだベータ段階でさまざまなバージョンを試しているため、1つの仕様書が複数ファイルを持つコードコンポーネントへマッピングされるレベルへ発展する可能性もある

  • Tessl仕様書の構造

    • @generate や @test のようなタグは、Tesslに 何を生成するかを指示 する
    • APIセクションは、コードベースの他の部分に公開される最小限のインターフェースを仕様書内で定義するという考え方を示しており、生成されたコンポーネントの重要部分が 保守担当者の完全な管理下 にあることを保証する
    • tessl build を実行すると、そのJavaScriptコードファイルが生成される

  • Tesslの抽象化レベル

    • spec-as-sourceのための仕様書を コードファイルごとにかなり低い抽象化レベル に置くことで、LLMが実行すべきステップや解釈の量、したがって誤りの可能性を減らせる
    • こうした低い抽象化レベルであっても、同じ仕様書から何度もコードを生成 するときに非決定性が観察される
      • 仕様書を繰り返し書き直し、コード生成の再現性を高めるためにますます具体化していく過程は、曖昧さがなく完全な仕様を書くことの落とし穴と課題 を思い起こさせる

観察事項と疑問

  • 1つのワークフローですべての規模を扱えるか?

    • Kiroとspec-kitはそれぞれ1つの 教条的なワークフロー を提供しているが、どちらも大半の実際のコーディング問題には適していない可能性がある
    • 問題の大きさに見合う十分な多様性 を提供しているのかは不明である
      • 小さなバグをKiroで修正しようとしたとき、ワークフローは ハンマーでクルミを割る ように感じられた
      • 要件文書が小さなバグを、合計16個の受け入れ基準を持つ4つの「ユーザーストーリー」へ変換してしまった
    • spec-kitを使う場合も、どの規模の問題に使うべきか不明確 だった
      • 以前のチームで3〜5ポイントのストーリーになりそうな機能を試したところ、spec-kitが踏んだ手順数と生成したMarkdownファイル量は問題規模に対して過剰に感じられた
      • 同じ時間があれば「通常の」AI支援コーディングで機能を実装できただろうし、そのほうがはるかに制御しやすく感じただろう
    • 効果的なSDDツールは、さまざまな規模と種類の変更 に対して、少なくともいくつか異なる中核ワークフローへの柔軟性を提供する必要がある

  • コードレビューよりMarkdownレビュー?

    • spec-kitはレビューすべき 大量のMarkdownファイルを生成 する
      • 互いに重複しており、既存コードとも重複している
      • 一部はすでにコードを含んでおり、全体として非常に冗長で、レビューが退屈になる
    • Kiroでは3ファイルしか得られず、「要件 > 設計 > タスク」という メンタルモデルを理解しやすい ので少し楽だった
      • それでもKiroは、修正を依頼した小さなバグに対しては冗長すぎる
    • 正直なところ、この大量のMarkdownファイルよりコードをレビューしたほうがよい と感じる
    • 効果的なSDDツールは、非常に優れた仕様書レビュー体験 を提供する必要がある

  • 誤ったコントロール感?

    • こうした多くのファイル、テンプレート、プロンプト、ワークフロー、チェックリストがあっても、エージェントが最終的にすべての指示に従わないケース を頻繁に目にする
    • コンテキストウィンドウの拡大はSDDを可能にした要因の1つとして挙げられるが、ウィンドウが大きいからといってAIがその中身をすべて適切に把握するとは限らない
    • 例
      • spec-kitには計画中に調査段階があり、既存コードについて多くの調査を行ったが、最終的にエージェントはそれが既存クラスの説明である点を無視し、新しい仕様として受け取ってすべて再生成し、重複を生んだ
      • 指示を無視する例だけでなく、指示（例: 憲法条項の1つ）に従おうとしすぎて 過剰に実行するエージェント も見られた
    • 過去の経験から、私たちが作るものを制御する 最善の方法は小さく反復的なステップ だったため、多くの事前仕様設計が本当に良い考えなのか非常に懐疑的である
    • 効果的なSDDツールは 反復的アプローチ を受け入れる必要があるが、小さな作業パッケージはSDDの考え方とほとんど相反しているようにも見える

  • 機能仕様と技術仕様をどう効果的に分離するか?

    • SDDでは 機能仕様と技術実装の分離 を意図的に行うのが一般的な考え方である
      • 根本的な願いは、最終的にはAIがすべての解決策と詳細を埋め、同じ仕様で別の技術スタックへ切り替えられるようにすることだ
    • 実際にspec-kitを試すと、いつ機能レベルにとどまるべきか、いつ技術的詳細を加えるべきか でしばしば混乱した
      • チュートリアルやドキュメントもこれについて一貫しておらず、「純粋に機能的」が実際に何を意味するかについて異なる解釈が存在した
    • 要件と実装をうまく分離できていない 多くのユーザーストーリー を思い返すと、業界全体としてこれをうまくやれてきたとは言いがたい

  • 対象ユーザーは誰か?

    • 多くのspec-driven開発ツールのデモやチュートリアルには、製品や機能目標の定義のようなものが含まれており、「ユーザーストーリー」のような用語も使われる
    • ここでの発想は、AIをクロススキリングの促進要因として使い、開発者が 要件分析により積極的に関与 するようにすることなのかもしれない
      • あるいは、開発者がこのワークフローで作業する際にプロダクト担当者とペアを組むのか?
    • こうした点はどれも明示的に説明されておらず、開発者がこのすべての分析を行うのが当然であるかのように提示されている
    • では SDDはどの規模と種類の問題のためのものなのか?
      • おそらく、まだ非常に不明確な大規模機能には向かず、その場合はより専門的なプロダクト／要件スキルや、調査、ステークホルダー関与など多くの別工程が必要になるだろう

  • Spec-anchoredとspec-as-source: 過去から学んでいるのか?

    • 多くの人がSDDとTDDまたはBDDの類似性を指摘するが、特にspec-as-sourceの場合、見るべきもう1つの重要な類似対象は MDD（モデル駆動開発） である
    • キャリア初期にMDDを多用したいくつかのプロジェクトに関わっており、Tessl Frameworkを試しているときにそれを何度も思い出した
      • MDDのモデルは本質的に仕様書だったが、自然言語ではなくカスタムUMLやテキストDSL で表現されていた
      • こうした仕様書をコードへ変換するために、カスタムのコード生成器が構築された

  • MDDとSDDの比較

    • 最終的にMDDは 業務アプリケーションでは成功しなかった。抽象化レベルがぎこちなく、オーバーヘッドと制約が多すぎたためである
    • しかしLLMはMDDのオーバーヘッドや制約の一部を取り除くので、いまや 仕様を書くことに集中し、コードを生成する という新しい希望がある
    • LLMを使えば、事前定義されパース可能な仕様言語に縛られず、洗練されたコード生成器を構築する必要もない
      • その代償はもちろん LLMの非決定性 である
    • パース可能な構造には、有効で完全かつ一貫した仕様を書くための多くのツール支援を仕様作成者に提供できるという利点もあったが、いまはそれを失いつつある
    • spec-as-source、さらにはspec-anchoringでさえ、MDDとLLMの両方の欠点 に終わる可能性がある: 非柔軟性 そして 非決定性
    • 過去のspec-from-codeの試みを振り返り、今日spec-drivenを探る際にはそこから学ぶべきである

結論

  • 個人的には、AI支援コーディングを使う際、コーディングエージェントに与える 仕様の形を慎重に作ることに時間をかける ことが多い
    • したがってspec-firstの一般原則は、多くの状況で確かに価値がある
  • 仕様をどう構造化するかに関する多様なアプローチは非常に必要であり、現在実務家から最もよく受ける質問の1つでもある
    • 「メモリバンクをどう構造化しますか?」「AI向けの良い仕様書や設計文書をどう書きますか?」
  • しかし 「spec-driven development」という用語自体はまだ十分に定義されておらず、すでに意味が拡散している
    • 最近では「spec」をほぼ 「詳細なプロンプト」の同義語 として使う例も耳にする

  • ツールに対する評価

    • 既存ワークフローをAIエージェントへあまりに文字通りに与えようとするものもあり、最終的に レビュー過負荷やハルシネーションといった既存の課題を増幅 しかねない
    • とりわけ多くのファイルを生成するより精巧なアプローチでは、ドイツ語の複合語 「Verschlimmbesserung」（良くしようとしてかえって悪くしてしまうこと）を思い出す
      • 良くしようとする試みの中で、むしろ物事を悪化させているのではないかと疑問に思う

関連記事

3件のコメント

 
aer0700 2025-10-20

以前の document driven develope や readme driven develope といった話と似ているように見えますね。
https://ja.news.hada.io/topic?id=15502
 
GN⁺ 2025-10-20
Hacker Newsの意見

  • 最近のSDD（仕様駆動開発）トレンドを追っているが、この流れは理にかなっている一方で、まるでpre-agile時代の機能仕様書と設計文書の時代に戻っているようにも感じる。完全なBig Design Up Frontではないにせよ、次第に「動くソフトウェア == 完璧なドキュメント化」に向かっているように見える
    Big Design Up Front参考, Agile Manifesto参考

    • 機能仕様書と設計文書は、結局のところ自然言語でコーディングするのと同じ。以前は人間がこれをプログラミング言語に書き直す必要があったが、今ではLLM（大規模言語モデル）のような自動化コンパイラがこの作業を代行し始めている。この過程で1段階を飛ばせるようになったわけだ（成功率はさまざま）。<br /> 一方でアジャイルは、ソフトウェアをどの言語で作るかは気にしない。本質は「管理者を排除」し、開発者が管理業務まで直接担うことにある。12の原則では、管理者がいないときに開発者が何をすべきかをより詳しく扱っている

    • Behaviour Driven DesignはTest Driven Designのように「生きた仕様書」を生み出せる。ドメイン探索の基準からテスト合格可否まで、人が読める文書の形で残し、テストハーネスと直接つないで現行機能を検証できる。こうすればBDDレポートを通じて明確に検証され、協業・反復可能な仕様文書を持てるようになり、初期の不要な作業なしにアジャイル・JIT・YAGNIまで全部押さえられる。わざわざウォーターフォールに戻る必要はない

    • 小さな設計から始めることもできる。1〜2ページの仕様を書き、LLMでコードとテストを生成したあと、反復的に補完していく形だ。もしLLMコーディングを100%信頼するなら、仕様入力（英語プロンプト）を体系的に管理するのが論理的だ。プロンプトを捨てずに整理しておけば、将来再利用したり追加制約を明確に与えたりできる。<br /> ただし、LLMを重要なプロダクションコードに使うのは不安なので、サンドボックス／テスト／デモ目的でのみ実験している。コード品質がそこまで重要でない場所にだけ活用している

    • Spec driven development自体は良いアイデアだ。しかし現在の実装は、構造化されていないmarkdownファイルをagentに渡しているだけで、まともな結果が出ず、実際には再現性がまったくない。エージェントが仕様作成まで担うなら、stubコードやテストコードまで自動変換できる構造化仕様であるべきだ。markdownを捨てる必要はないが、コード生成器と連携すればはるかに再現性が高まるだろう。実際そうすれば、反復用のコード生成にかかる時間を大幅に短縮できる

  • SpecKitを使ってみて本当に興味深く満足もしたが、現実の複雑な例や活用法を探すのに苦労した。チュートリアルの多くは、単純にインストールして「ToDoリストアプリを作る」程度にとどまっている。既存のレガシーコードベースを段階的に改善したりリファクタリングしたりする実例や、spec driven developmentが最初から適用されていない大規模プロジェクトでどうアプローチすべきかを共有してほしい

    • 私自身もBDD方式とCLIベースのコーディングを並行しながら、本物のコードで直接機能を記録するほうが、長く冗長なmarkdownよりはるかに効果的だと実感した。AIに従わせるチェックリストが必要なら、agents.mdのようなファイルがあれば十分だ。一度そのcodingパターンと非機能要件（NFR）だけ記録しておけば、エージェントに明確に従わせられる

    • 本当に活用するには、templateやsource codeを直接読んでこそ、実際に何が動いているのか把握できる。こうしたプロジェクトでは、むしろ当然のプロセスだと思う

  • Thoughtworks出身のAIベースのデリバリー専門家の紹介に続いてmemory banksの話が出てきて、すぐに共感した。こちらも「AIが大勢」の現場で働いてみると、メモリバンクが大きくなるほど、かえってAIが方向を見失い、成果物もぐちゃぐちゃになる。結局、製品を完全に理解している人が直接AIをリードしてこそ、現場に実際適用できる。AIにどれだけだまされたか数え切れないほど経験したし、人間が直接もう一度導いてやると、いつも謝って理解はするが、それで何かが変わるわけでもない。AIが自分たち向けに書かれた大量の文書を全部読んで検証するのも現実的ではない。むしろその時間で自分で作業したほうがよほどましだと思う

    • memory bankとは何を意味していて、その役割について具体的に何を言いたいのか気になる

    • 現時点ではmemory機能はむしろ悪影響だ。きちんとした「検索／参照」戦略なしに使うと、悪い結果ばかりを増幅してしまう。ほとんどのmemoryシステムは単一チャットのパラダイムに合わせて設計されているため、多様な環境では問題しか起きない。本当の「記憶」とは、メインエージェントと分離された「メタ認知／デフォルトモードネットワーク」を通じて非同期にタスク構造と文脈を設計し、そのうえで各プロンプトごとにこのメタモデルが方向を与える方式、つまり「エージェントベースのメモリ」であるべきだ

    • LinkedInのようなところで「thought leader」という肩書きを付けているのも理解できない。最近ああいうタイトルにどんな意味があるのか本当に分かりづらいと思う

  • ここ2週間、SpecKitとClaude Codeで2つの新規プロジェクトを実験した経験を共有したい。どちらも自分1人で開発していたので、実験しても負担がなかった。最初のプロジェクトはSpecKitにそのまま任せて進めたが、10日かけて全タスクを終えたものの、成果物のテストの大半が失敗し、ビルドも壊れていた。問題修正に同じだけ時間を費やす必要があり、Claudeは1つ直すと別の部分を壊すので、信頼性が大きく下がった。<br /> 2つ目のプロジェクトでは、小さな単位で反復したいと考え、SpecKitのプランニング後にslashコマンドを追加してbacklog.mdを作り、plan-sprintでスプリント目標と作業詳細を含むファイルを生成し、implement-sprintで一括処理した。しかしこのプロセスでも、実装命令に従わず、何度プロセスを修正してもテストを作らなかったり、タスクを漏らしたりした。<br /> そこで設定をまた変えて、特定タスクだけを扱うsubagentを置き、implement-sprintはオーケストレーターとしてのみ使う形に切り替えた。こうすると各スプリントごとにコード状態を確認できるので、信頼性はずっと高かった。今でもテストが失敗していても終わったと言うことはあるが、自分で全部通して見るよりは楽だ。<br /> 現在の仮説は、ClaudeがTDDに弱いという点だ。テストを先に書く段階で常に問題を起こす。次はテストを実装後に書く方式への切り替えを試す予定だ。理想的ではないが、それでも生産性を上げて手書きコーディングより良くしなければならない

  • 多くのツールがたいてい「仕様先行」戦略に合わせて作られていて、仕様の保守方法は曖昧なのが興味深かった。個人的にはcofounderと一緒に「spec as source」に全振りしている。仕様を本当のソースにすることこそ最も面白い活用法だと思って挑戦しているが、実際に定着させるのはかなり難しい。関連する経験やフィードバックがあればぜひ聞きたい。<br /> 実験対象のspecific.devにも、もし興味があれば使ってみて知らせてほしい

    • 仕様が本当にソースなら、それはすなわちその仕様自体が実行可能な形式言語（プログラミング言語）でなければならない。そうでなければ仕様は仕様でしかなく、ソースコードはソースコードのままだ。結局「良いコード」とは何かを学ばなければならないのは皆同じだ

  • Kiroのspec-driven workflowを使ってみたところ、作業リストがものすごい量で出てくる（各作業に4つ以上のサブタスク、全体で12作業以上）。ワークフロー自体は悪くなかったが、予測不能にコードを削除し、ロールバックもしてくれない。IDEとして作っているせいでUIの例外処理にリソースを取られているようだ。複雑に細分化するより、シンプルに反復して改善するほうが楽だ。「クルミを割るのに大型ハンマーを使うようなもの」だ

  • カスタムslashコマンドで入力値をよく構造化されたプロンプトに包む方式は気に入った。agents.mdなどで分解して出てきた部分をコンテキストとして一緒に注入する点も良い。<br /> ただ、あらゆる結び目を全部ほどこうとする試みが、かえってハンマーでクルミを割るような感じになっていて（複雑さを生んでいて）好きではない。とはいえ、必要なときだけ追加のslashコマンド（/experiment, /stubなど）でコンテキスト管理を選択的に行えるなら、もっと軽くできると思う。最後に/wrap-upのような締め専用コマンドで、すべての結び目を一度にまとめるような形だ。手術が終わったあとに医師が全体を点検する感じに近い

  • SpecKitを使っていて常に「いつこのすべてのspecを単一の本当の基準（ground truth）に統合するのだろう？」という疑問があった。その段階自体が存在しないようで残念だった。<br /> 今では、人間とエージェントの間のコミュニケーション仕様（spec）がどのような姿であるべきかを定義・設計する課題が残っている。Birgittaの言う「spec anchored」という概念を実現するために考えている

    • AIが登場したことで、こうした標準を今こそ本当に定義すべき時期だと感じる。人間が読み管理できる程度に（完全でなくても部分的にLLMコンテキストへ入れられる程度に）仕様を定型化し、一部の情報だけをingestしても中核の意図と設計を保ったまま実務を進められる形であるべきだ。<br /> UMLやRational Rose系の試みが失敗したのは、意図が具体的に入らず図としてしか残らず、文書化・保守・リファクタリングの段階でしか使われなかったからだと思う。結果として、すでにリリースしたあとでしか役に立たず、無意味になってしまった。<br /> 今はC4モデルのような新しい方法に注目するようになった

  • SDDが突然大勢になった理由は分からないが、個人的には単に仕様ファイルを作って「最終成果物をあらかじめ把握」し、プロジェクトを細かく分割するときに進捗を追跡する実用性を感じている。特別なツールやフレームワークは使わず、markdownファイルだけを使っている。それ以上に複雑な仕組みには特に価値を感じなかった

  • spec-kitを最初に使ったときは本当に期待が大きかったが、実際には「洞窟でロボットを作る」段階に至るまで必要な作業を無理に作り出し、ただネジを締めれば済むようなことまで過剰に膨らませるので、修正しているうちに疲れ果ててやめてしまった。過度に複雑なワークフローは、補正する価値も感じられないと思う
 
jjw9512151 2025-10-20

実際、ソフトウェア工学で学んだことをMarkdownでやると考えれば、シンプルで実用的です。要件定義書さえうまく書ければいいのです。