Site icon image blog.kamisamakourin.com

一個人の考えブログ

2026/02/26 18:22

最近は相変わらずspeckitを使った、spec drivenでツール開発をしている。

ソフトウェアエンジニアリングの経験はやはり少ないので、勘所がわからない部分も多く、そういった部分を完璧ではないにせよ強力に支援してくれる素晴らしい仕組みだと思います。

完全にフリーハンドで構築するより、議論を経たうえでタスクを明確化されて成果物が一定程度、安定していると感じるようになりました。

しかし、それでも微妙な部分もあり、もう少し精度を上げられないかなと感じていた。

そこでtaktというツールを見つけた。

sddとtaktを統合できないかtと思い、少しClaude Codeに壁打ちしたので、メモを残しておく。

実行したら、感想を書く(忘れてなければ)。

SpecKit + TAKT 統合アイディア

SpecKit(Spec-Driven Development)の実装フェーズをTAKTで置き換えるアイディア。

背景
  • SpecKit: 「何を・なぜ作るか」を仕様として段階的に精緻化するフレームワーク(GitHub公式OSS)
  • TAKT: AIエージェントのマルチエージェントオーケストレーションツール(OSS)。ピースで定義したワークフローにAIを強制的に従わせる

両者はSDLCの異なるレイヤーを担当しており、組み合わせで互いの弱点を補完できる。

分担イメージ
1. specify init          ← 人間 + SpecKit
2. /speckit.constitution ← 人間 + SpecKit(プロジェクト原則策定)
3. /speckit.specify      ← 人間 + SpecKit(機能仕様作成)
4. /speckit.clarify      ← 人間 + SpecKit(仕様明確化)
5. /speckit.plan         ← 人間 + SpecKit(技術計画作成)
6. /speckit.analyze      ← 人間 + SpecKit(整合性チェック)
7. /speckit.tasks        ← 人間 + SpecKit(タスク分解)
8. /speckit.implement    ← ★ TAKTのピースに置き換え

上流工程(1〜7)はSpecKitで仕様を精緻化し、実装フェーズだけTAKTに委ねる。

なぜ実装フェーズをTAKTに置き換えるか

SpecKit単体の /speckit.implement の課題:

  • 単一エージェントが一気通貫で実装するだけ
  • コードレビューが入らない
  • 仕様準拠の検証が弱い
  • AIが自分で「完了」と言えてしまう

TAKTに置き換えることで:

  • implement → review → fix のレビューループが強制的に回る
  • SpecKitの成果物(spec.md / plan.md / tasks.md)をKnowledgeファセットとして注入し、仕様への準拠を常時参照
  • constitution.md をPolicyファセットとしてマッピングし、品質基準を自動注入
  • 並列レビュー(アーキテクチャ + 仕様準拠 + QA)で多角的チェック
成果物とTAKTファセットの対応
SpecKit成果物 TAKTファセット
constitution.md Policy(品質基準・禁止事項)
spec.md Knowledge(機能仕様)
plan.md Knowledge(技術計画)
tasks.md Knowledge(タスク一覧)