仕様→計画→タスク→実装──6コマンドの「型」
今回のセッションでは、スイーツ店の商品管理API（商品約100件、一覧・検索・基本的なデータ操作）にカート機能を1つだけ追加する工程がデモとして披露された。既存プロジェクトへの機能追加という、現場でよくあるパターンだ。
技術には.NET（ASP.NET Core Minimal API／C#）を採用。鈴木氏によれば、型のあるコンパイル言語はAIの出力のブレが少なく、機械的な正誤信号が効きやすいためだ。constitutionにプロジェクトの原則や制約を渡し、specifyでは「既存のAPIにカート機能を追加してください」と依頼するだけで、ユーザーストーリーや禁止事項まで含むspec.mdが生成される。そこからplan、tasksを経て、任意コマンドであるanalyzeが検出した2件の不整合を修正し、implementではxUnitのテストを自動実行して検証をループしながら、手書きの実装をほぼ行うことなく、動くアプリが完成するまでの一連の流れを実演した。
この手法の価値は、（1）仕様駆動で成果物まで到達できること、（2）AIが実装し、人間は仕様とレビューに集中できること、（3）そして手順（仕様）が残るので誰でも再現可能であることだ。「速い」ことより「仕様から再現できる」ことが価値であり、既存プロジェクトでも改修箇所から段階的にSDD化できるため、保守案件が大半を占めるSIやエンタープライズ開発とも親和性が高いと、鈴木氏は強調した。
Spec Kit自体も進化している。当初は、constitutionに何でも入れる想定だったが、直近では原則だけをコアに残し、詳細は外出しする設計が明確になった。構造としては、常時参照されて挙動に影響を与える原則（Constitution.md、CLAUDE.md、AGENTS.md）、必要時に読み込む専門知識（Skills相当）、必ず通す強制ルール（Hooks）の3層構造を形成している。さらにコアは小さく保ち、機能を追加するextensions（現在100近い）と、要件・挙動を方向付けるpresetsなどで拡張していく（例えばPII禁止を強制するなど）。鈴木氏は「ツール選定ではなく『思想と仕組み』を設計する時代へ」と説明する。
適用範囲と運用の勘どころとして、鈴木氏は新規プロジェクト（greenfield）なら立ち上げ時から仕様駆動で始め、最初に原則を定義してきれいに積み上げていける。一方で既存プロジェクト（brownfield）でも全置換は不要で、改修が入る箇所からSDD化し、既存資産を活かしながら段階的に広げられる。保守や既存プロジェクトが7割ほどを占めるSIの現場では、こちらが現実的な入り方になるだろう。
そしてエンタープライズでの運用の鍵になるのが、長時間作業での文脈維持、すなわちコンテキスト管理だ。鈴木氏はコンテキストエンジニアリングの4要素として「WHAT／HOW／WHY／FEEDBACK」の4要素を挙げる。WHATは技術スタックやフォルダ構成、HOWは正例・反例つきで具体化した規約や命名、WHYは設計の理由、FEEDBACKはtest・build・lintといった検証コマンドと期待出力だ。中でも欠けやすく、欠けると高コストな誤りの元になるのがWHYだという。運用面では、暗黙知を規約化（Capture）し、バージョン管理して各ツール形式へ配布（Distribute）、違反はpre-commitで検知する（Govern）という「ContextOps」のサイクルを回していく。
過程を記録することも重要だ。小規模の開発ならすぐトレースできるが、長時間の自律的な作業では、AIが本当に仕様どおりに動いたのか、どのようなやりとりを経たのかを後から追えることが重要になる。具体的にはLLMの入出力を記録するProxy層と、ツール呼び出しや判断といったエージェントの過程を記録するOTel層を設け、Langfuseのようにセルフホストできる受け皿へ集約すれば、機密を社内に置いたまま保存・検索・監査ができる。過程の記録は監査証跡であり、完了の証となる。テストが受け入れ基準として残るのと同じ考え方だ。
