✍️ 【学び】AI駆動開発 (も) フレームワークから学ぼう
🚀 はじめに
こんにちは！parasanです。
今回は、AI駆動開発（Spec-Driven Development）のフレームワークである**「tsumiki」**を実際に触ってみた話を書いてみます。
最近、AIを開発に組み込もうとして、みんな試行錯誤しているかと思います。
昔、オブジェクト指向、MVCフレームワークやDIコンテナ、TDD、etc・・・を学んだときって、オープンソースのコードから「設計の構造、思想」とか「規律や規約」を学んできた経緯が個人的にはあります。
今回AIコーディングでもその学び方を活かせるんじゃないかと思いフレームワークを触り始めてみたわけです。
今回は国産のフレームワークのtsumikiを触ってみました。
🛠️ 本題：技術的な解説と実装
1. AI駆動開発とフレームワークってなんだろう？
まずは、AI駆動開発とフレームワークの基本から確認してみましょう。
最近、AIに自然言語で指示するだけでコードを生成できる「Vibe Coding」で、誰でも簡単にシステムを作れるようになりましたよね。でも、実際の開発現場ではこんな課題が出てきています：
- 「思った通りに実装されていない...」（仕様が曖昧で手戻り多発）
- 「動くけど、保守が難しい」（テスト不足で技術的負債が溜まる）
- 「本番は怖くて出せない」（品質保証プロセスがない）
クラスメソッドが公開している「tsumiki」は、こういう課題に対して「AIの賢さ」だけでなく、**「開発プロセスの規律」**を持ち込むアプローチを取っています。これは「仕様駆動開発（Spec-Driven Development）」と呼ばれていて、コードではなく「仕様」を唯一の真実（Single Source of Truth）にして、仕様からテスト・実装へ落とし込んでいくスタイルです。
2. 課題と解決策：なぜtsumikiが必要だったのか
今回、私が直面していたのは「コードが王様」への逆襲という課題でした。
Vibe Codingが普及して、誰でも簡単にシステムを作れるようになったのですが、その一方で仕様が曖昧だったり、テストが足りなかったり、品質保証プロセスがなかったりという問題が出てきていました。
この課題を解決するために、tsumikiの**「仕様駆動開発」**というアプローチを試してみることにしました！tsumikiは、仕様を唯一の真実にして、仕様からテスト・実装へ落とし込むことで、開発プロセスに規律を持ち込むことができます。
3. tsumikiの概要と主要機能
tsumikiは大きく分けて2つのアプローチで開発をサポートしてくれます。
3-1. Kairo（回路）コマンド
Kairoコマンドは、要件定義から設計、タスク分割、TDD実装まで、開発の全体的なフローを対話形式で実行してくれます。
AIと対話しながら、ステップバイステップで開発を進めることができます：
-
要件定義 (
kairo-requirements) -
設計 (
kairo-design) -
タスク分割 (
kairo-task) -
TDD実装 (
kairo-implements)
3-2. TDDコマンド
TDDコマンドは、Red/Green/Refactor/Verifyのサイクルを個別に実行できて、ピンポイントでAIの支援を受けることができます。
-
Red（テスト作成） (
tdd-red)：AIが要件に基づいてテストケースを生成します -
Green（実装） (
tdd-green)：AIがテストをパスする最小限のコードを生成します -
Refactor（改善） (
tdd-refactor)：AIが生成したコードを、より保守しやすいコードに最適化します -
Verify（検証） (
tdd-verify)：実装が元の要件を正しく満たしているかAIが最終確認します
4. 実際にやってみた（開発フロー体験）
実際に tsumiki を使って、要件定義から実装までを流してみました。
4-1. 要件定義（kairo-requirements）
まず驚いたのが、AI側から**「非機能要件」**について確認を求められたことです。
「セキュリティ要件（PCI DSS等）はどうする？」「性能要件は？」といった質問に、選択肢形式で答えることで仕様を固めていきます。
また、収集した情報の信頼性を「信号機（青・黄・赤）」で色分けして可視化してくれる機能があって、推測ベースの情報（赤）と確定情報（青）がパッと見てわかるのは、認知負荷を下げる良いプラクティスだと感じました。
4-2. 設計（kairo-design）
要件定義が終わると、それに基づいて設計フェーズに入ります。
ここでは、受け入れ基準の作成や、システムアーキテクチャ図（PlantUML/Mermaid等）の生成が行われます。成果物が標準化されるため、誰がやっても一定の一貫性が保たれるのがメリットですね。
4-3. 実装（kairo-implements / tdd-*）
設計が終わると、実装タスクが分割されて、TDD（テスト駆動開発）のサイクルに入ります。
AIがタスク分割をサジェストしてくれるため、開発者は小さい単位で「テスト作成(Red) -> 実装(Green) -> リファクタリング」のサイクルを回すことができます。各フェーズでAIによるセルフレビューが走り、前後フェーズとの整合性もチェックされます。
4-4. おまけ：リバースエンジニアリング
既存プロジェクトのドキュメント生成もコマンド一発で可能でした。
データフロー図などがコードから逆生成されるため、ドキュメントがない既存システムの解析にも使えそうです。
💡 感想と学び：巨人の肩に乗る
今回、AI駆動開発フレームワークを触ってみて感じたのは、**「過去からある構造化の手法は、AI時代でも有効である」**ということです。
今の状況は、昔Web開発でStruts、Spring、Rails、Djangoなどが次々と生まれて、オレオレフレームワークが乱立していた2000年代中盤の「フレームワーク黎明期」に似ている気がします。当時はMVCモデルによる標準化が進みましたが、今は「AIエージェントをどうワークフローに組み込むか」という標準化の過渡期（夜明け前）にあると感じます。
まとめ
- 構造化の再評価: 品質の色分けや、仕様からコードへの落とし込みなど、既存のプラクティスはAI開発でも強力な武器になります
- 一貫性と規律: 個人のプロンプトスキルに依存せず、チーム全体でワークフローを標準化するために、フレームワークの活用は有効です
- 今後の動向: まだ「これ」という決定的な巨人はいませんが、各支援基盤の動向を追いながら、良い構造を取り入れていく（巨人の肩に乗る）姿勢が大切です
「我流上等」の精神も大切ですが、主流のフレームワークから構造を学んで、自分たちの開発プロセスをアップデートしていく良い機会だと感じました。
📚 参考資料
- tsumiki: https://github.com/classmethod/tsumiki
- Kiro (IDE): https://kiro.dev/
Discussion