AIエージェントを使ったコーディング術(スペック駆動開発)

概要

AIコーディングエージェントに機能をそのまま丸投げすると、仕様があいまいなまま実装が進み、意図しない設計になりがちである。この動画では「スペック駆動開発」という手法を使い、実装前にAIと一緒に仕様書(スペック)を作成・レビューし、タスクに分解してから段階的に実装させるワークフローを解説している。

主なポイント

• スペック駆動開発とは、いきなりプロンプトで実装させるのではなく、事前に「何を作るか・制約・重要な決定事項」を記した仕様書を作成してから実装させる手法
• PRD(人間向け・ビジネス価値の合意)、技術設計書(エンジニア向け・アーキテクチャ)、AIスペック(エージェント向け・実行計画)は目的が異なる別物として使い分けるべき
• スペックには「Why(なぜ作るか)」「What(何を作るか)」「制約(使う/使わないライブラリ、やらないこと)」「タスク分解(触るファイル・検証方法)」を含める
• Claude Codeなどではスラッシュコマンド(例: /spec)でAIと対話しながら仕様書を対話的に生成・修正できる
• 生成された仕様の中でAIが選んだ実装方針(例: 特定ライブラリの選定)に納得できない場合、実装前にスペックのテキストを直接編集して修正するのが効果的
• タスクは1つずつ「実装→テスト→コードレビュー→コミット」のサイクルで進め、セッションをまたいで途中から再開できる
• 実装後のコードは鵜呑みにせず、正規表現の多用など疑わしい箇所は人間がレビューして改善を指示する
• OpenSpec、GitHub Spec Kit、Kiroなどのフレームワークは便利だが、著者はオーバーヘッドが大きいと感じており、シンプルな自前運用を推奨
• 大きな機能を一気にAIに実装させて後からレビューするより、小さいタスク単位で段階的に進める方が結果的にコード品質が上がる

実践に使えること

• 新機能を実装する前に、AIエージェントと一緒に「Why/What/制約/タスク分解」を含む仕様書(Markdown)をまず作成し、コードを書かせる前に必ずレビュー・修正する
• 仕様書内でAIが提案したライブラリや実装方針が気に入らない場合は、実装前にスペックのテキストを直接書き換えて指示を明確化する
• 大きな機能は複数タスクに分解し、1タスクずつ「実装→テスト→レビュー→コミット」のサイクルで進め、必要なら新しいセッションで続きから再開する