1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

コンテキスト管理とエージェント開発を支える、次世代の開発パラダイム

AIを活用したコーディングが一般化するにつれ、エージェントの能力と限界を理解し、これを最大限活かすための新しい開発手法が必要となっている。その有力候補が Spec-Driven Development(SDD) である。

本稿では、OpenAI の Sean Grove が強調する SDD の思想を整理しつつ、実際に SD Dを AI コーディングに適用した際の有効性、そして Claude Code における実践方法を示す。

1. Sean Grove が語る、SDD の必然性

参考: https://www.youtube.com/watch?v=8rABwKRsec4

Sean は、コードの実装力を重視しつつも、それ以上に “仕様を書く能力” がエンジニアに求められる資質である と強調する。

Sean のプロセス整理

Sean が述べる「仕様から実装までの流れ」は次のとおりである。

  • ユーザーと対話し課題を理解する
  • 議論を抽出(distill)し、解決すべき具体的目標へ落とし込む
  • その目標をどのように実現するか計画する
  • 計画をチームと共有する
  • 計画をコードへ翻訳(translate)する
  • 結果が計画と一致しているか検証する

一般的なコードベースには、これらの意図・背景・判断理由は書かれていない。
そのため、

  • なぜこの構造なのか
  • 何を実現しようとしたのか
  • この仕様は本来どう定義されていたのか
    といった問いに、コードだけで回答することは難しい。

だからこそ Sean は 「コードは仕様に従属すべきであり、仕様こそが源泉であるべきだ」 と主張する。

2. AI コーディングにおける SDD の価値

SDD は単に「先に仕様を作る」という古典的な要求仕様書作成の話ではない。
AI エージェントと協働する時代においては、コンテキスト管理とエージェント制御の要となる基盤である。

事前定義した仕様がエージェントを効率化する

AIに「〇〇を実装して」と伝えるだけでは、エージェントは:

  • ファイル構造の探索
  • 過去会話ログの分析
  • 不足情報の補完
  • 意図の推測
    など、多くの無駄なコンテキスト処理を強いられる。

しかし仕様書を事前に与えておけば、エージェントは 推測ではなく “仕様書を根拠” に作業できる

これはプロンプトエンジニアリングの拡張であり、コンテキストの浪費を抑え、生成の正確性と効率性を高める。

コンテキストをクリアしても作業を再開できる

エージェントはループを回すたびに大量のコンテキストを蓄積するため、どこかで Clear または Compact が必要となる。

しかしその際、仕様が外部ファイルとして保存されていなければ、再度同じ指示や背景をすべて与え直す必要があり、再現性の低下につながる。

仕様書があれば、

  • コンテキストを一度リセット
  • 仕様書を再読み込み
  • 途中のタスクから再開
    という流れが可能となる。

これは実質的に コンテキストのガーベジコレクション に相当し、長期的なエージェント開発で極めて重要となる。

3. SDD の実践例:JetBrains Junie における手法

参考: https://blog.jetbrains.com/junie/2025/10/how-to-use-a-spec-driven-approach-for-coding-with-ai/

JetBrains の Junie では、SDD を次の 3 文書で構成することを推奨している。

  • Requirements.md
  • Plan.md
  • Task.md

これらはユーザーが手書きする必要はなく、エージェントに生成させればよい。

Junie の出力例では、要求 → 仕様 → 実装計画 → タスクへと段階的にブレイクダウンされ、
明確な TODO リストが生成される。
これにより、エージェントは迷うことなく計画通りにコードを作れる。

4. Claude Code における SDD:Spec Kit の活用

Claude Code でも SDD をサポートする方法が多数提案されており、有名なのはGitHub が公開した Spec Kit である。

Spec Kit の思想

Spec Kit では次のように述べられている

コードは仕様に仕える。仕様が先にあり、コードは仕様から生成されるべきである。
PRDは実装のガイドではなく、実装を生み出す“源泉”である。

これは SDD を最も簡潔に表現したものと言える。

導入方法

導入はわずか 2 コマンドで完了する。

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init . --ai claude

Claude Code のスラッシュコマンドに SpecKit 拡張が追加される。

/speckit.constitution – プロジェクト原則の設定
/speckit.specify – 仕様の作成
/speckit.plan – 実装計画の作成
/speckit.tasks – タスク分解
/speckit.implement – 実装実行

ユーザーはこれらを順に実行するだけで SDD に沿った開発フローに乗れる。

実際に使ってみた所感

実際にプロジェクトへ導入すると、specs/ フォルダ配下に

  • 要件定義(requirements.md)
  • 仕様書
  • 実装計画
  • タスクリスト

が生成され、ステップごとに更新されていく。
image.png

これにより、

  • 仕様の一貫性
  • 作業再現性
  • 進捗管理
  • エージェントへのタスク伝達効率
    が大きく向上する。

5. まとめ:SDD が AI コーディングにもたらすメリット

  • 明確な仕様によるコンテキスト節約
    エージェントは無駄な探索をせず、仕様を根拠に作業を進められる。
  • コンテキストクリア後の作業再開
    仕様を外部ファイルとして保持することで、コンテキストを一度リセットしても再開可能となる。
  • ワークフロー全体の再現性向上
    タスクブレイクダウン → 実装 → 検証のループが整い、AI コーディングが一定の品質と安定性を持つようになる。
  • エンジニアリング資産としての仕様書
    コードだけでは表現できない背景・意図・判断基準を仕様として残すことで、将来の保守性も大幅に向上する。
1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?