TAKTでAI駆動開発の品質を設計する

AIエージェントに開発を任せると速い。しかし1回の実行結果をそのまま採用する「バイブコーディング」だけでは、受入条件の未達やレビュー漏れが素通りし、品質保証になりません。必要なのは、検出 → 修正 → 再検証を必要な回数だけ回す、閉じた品質ループです。

本セッションでは、ワークフローエンジン TAKT がこのループをどう実現するかを、仕様書駆動開発ツール cc-sdd を TAKT ワークフロー化した実例「takt-sdd」を題材に解説します。TAKTが決定論化するのはAIの出力ではなく、実行経路・分岐・証跡・完了判定。プロンプトではなく「ワークフローと契約」でAI駆動開発の品質を設計するアプローチを、実際に動いているワークフローの設計を図解しながら紹介します。

トピック:

なぜ仕様書駆動開発か — バイブコーディングだけでは品質保証にならない
TAKTの構成要素 — step / rules / facets / output contract による決定論化
生成ステップと read-only 判定ステップの権限分離
実例: kiro-impl と AI品質ゲート — 並列レビュー・ループ監視・完了判定の合成
AI駆動開発を設計する4つのパターン
対象: AIエージェントによる開発の品質に課題を感じている方、TAKT / cc-sdd / 仕様書駆動開発に興味のある方

Transcript

1. TAKTでAI駆動開発の品質を設計する 実例 takt-sdd で学ぶ、AI駆動開発の品質ゲート設計 かとじゅん(@j5ik2o) Findy / TAKTで実践するマルチエージェントのオーケストレーション / 2026-06-10 v1.1
2. 自己紹介 加藤潤一 かとじゅん / @j5ik2o IDEO PLUS合同会社 代表 2014–2024年: kubell（旧Chatwork）テックリード 2025年1月: 独立。技術顧問として SaaS 企業を支援 関心領域: DDD / 関数型 / 分散システム設計 / AI-DLC takt コントリビューター（40 PR）— オブザーバビリティ基盤・セキュリ ティ強化・cursor provider 対応など。takt-sdd 作者 2
3. 今日話すこと TAKTが決定論化するのは AI の出力ではなく、実行経路・分岐・証跡・完了判定 なぜ仕様書駆動開発か — 1回実行（バイブコーディング）だけでは品質保証にならない cc-sdd v3 と takt-sdd — 仕様書駆動開発を TAKT workflow として実行する TAKTの構成要素 — step / rules / facets / output contract と決定論化 生成ステップと read-only 判定ゲートの分離 kiro-impl — 品質制御を 1 つのワークフローに合成 kiro-ai-quality-gate — 検出・修正・再計画の閉ループ AI駆動開発を設計する 4 つのパターン 3
4. なぜ仕様書駆動開発か — バイブコーディングだけでは品質保証にならない バイブコーディング ＝ 1 回の実行をそのまま採用 指示 AI 実行 回答を採用 受入未達・レビュー漏れも素通り 実行経路は毎回同じとは限らない 検出 → 修正 → 再検証 が設計されていない 検出 → 修正 → 再検証 ＝ 閉ループ ゲート通過時のみ 実行 検証ゲート 完了 修正 問題あり 再検証へ 必要な回数だけ回る — 完了はゲート通過時のみ 同じ指示でも実行経路は毎回ブレる。必要なのは、必要な回数だけ回る検出 → 修正 → 再検証の閉じたループ。TAKTはこれをステートマシン とゲートとして設計可能にする。 4
5. FYI: 普段の開発フロー — アイデアを煮詰めてから spec に乗せる 1. アイデアを相談 新機能・改修どちらでも。 タスクではなく相談として AI に話す 2. grill-me スキル 質問攻めでデシジョンツリーの分岐を 漏れなく・ダブりなく解消 3. grill-with-docs スキル 計画をドメイン用語・既存決定と照合 決定が固まるたび文書をその場で更新 → plan.md → CONTEXT.md / adr/ 4. cc-sdd に接続 /kiro-discovery → /kiro-spec-init に plan.md を渡す 5. cc-sdd フローで開発 要件 → 設計 → タスク → 実装 → 検証 は spec 駆動に任せる ポイント タスクの丸投げではなく、 相談 → 煮詰める → spec 化の順 今日はこのあたりの話です アイデアの解像度を grill 系スキルで上げ、 plan.md と CONTEXT.md / adr/ が整ってから spec 駆動のフローに乗せる。grill 系スキルの出典: mattpocock/skills 5
6. cc-sdd: 承認済み spec を長時間の自律実装に変えるSDDハーネス 何をするものか npx cc-sdd@latest の一発で、エージェント 型の SDLC ワークフロー（discovery → 要件 → 設計 → タスク → 自律実装）を Agent Skills と して導入する。 Kiro-inspired — 既存の Kiro spec （ .kiro/specs/ ）と互換でポータブル。 思想 — spec は「契約」 spec はエージェントへの命令書ではなく、シ ステムの部分間の契約。コードが SSoT。 エージェントが spec を書き、人間は フェーズ ゲート（各フェーズ完了時の関門）で契約を承 認し、出荷されるのはコード。明示された境界 （boundary）が、人間とエージェントの並行 作業を可能にする。 プロジェクト v3.0.2 — 2026/04 MIT ★ 3.4k gotalab/cc-sdd — 13 言語対応（ --lang ja ） 。 takt-sdd はこの cc-sdd を pinned cc- sdd@3.0.2 で初期化し、TAKT workflow とし て包む。 次: v3 の全体像 — discovery から spec 生成・自律実装までの 3 フェーズを 1 枚で。 cc-sdd 6
7. cc-sdd: AIエージェントによる自律的な仕様書駆動開発 1. 探索・振り分け /kiro-discovery を起点に、既存 spec の拡張 / 新規 spec 作成 / spec なし直接実装 / 複数 spec への分解 を判断。 要求の大きさに応じて出力が分かれる — 単一 機能なら brief.md 1 つ、複数 spec への分解 なら roadmap.md + 複数の brief.md 。 2. 仕様策定 要件定義（EARS 形式） → 設計（Mermaid 図 + File Structure Plan） → タスク分割の 3 段階を 経て、実装の「契約」を固める。 EARS ＝ 要件を定型構文で書く WHEN 〈トリガー〉 システム SHALL 〈応答〉 英: WHEN balance is low, THE system SHALL reject payment 日: 残高不足のとき、システムは決済を拒否すること 変種: WHILE（状態）/ IF…THEN（異常）/ WHERE（範囲） 3. 自律実装 /kiro-impl を実行。タスクごとに独立した implementer が担当し、TDD サイクル（RED → GREEN）でコードを書き上げる。 生成される主要ドキュメント requirements.md — EARS 要件と明確な受 入基準 design.md — アーキテクチャ図解と File Structure Plan tasks.md — Boundary / Depends が明記さ れた実行用タスクリスト /kiro-impl の自律的な仕組み TDD — テスト失敗（RED） → 成功 （GREEN）を自動で反復 独立レビューと自動デバッグ — 実装とは別 のレビュアーが検証。blocked / 2 回否決で auto-debug が根本原因を調査 境界重視（Boundary-first） — File Structure Plan に基づき境界違反をチェック 対応エージェントとステータス 8 エージェント × 共通 17 スキル。プラットフ ォームを問わず同じワークフロー。 Claude Code — Stable Codex — Stable Cursor Copilot Windsurf OpenCode Gemini CLI Antigravity — Beta cc-sdd 7
8. cc-sdd / Kiro-style SDDは仕様生成から実装・検証へ進む kiro-discovery アイデア分類 / roadmap kiro-spec-init spec の初期化 kiro-spec-requirements EARS 形式の要件 kiro-spec-design 技術設計 + 発見ログ requirements.md design.md / research.md kiro-validate-gap 既存実装とのギャップ分析 research.md 更新 kiro-validate-design read-only / GO・NO-GO kiro-spec-tasks 実装タスク生成 kiro-impl ゲート付き実装 kiro-validate-impl read-only / 最終検証 design-review.md tasks.md tasks.md 進捗更新 成果物はすべて .kiro/specs/{feature}/ に蓄積 Kiro の仕様フォーマットと互換 — gap 分析の発見は research.md に追記される discovery から spec 生成・design validation・tasks・実装・final validation へ。成果物は .kiro/specs/{feature}/ に蓄積され、Kiro と 互換。 cc-sdd 8
9. takt-sdd: taktの上でcc-sdd / OpenSpecを動かすワークフロー資産 何をするものか SDD の全フロー（要件 → 設計 → タスク → 実 装 → 検証）を takt の workflow（YAML）+ facets で自動化する定義集。 成果物は .kiro/specs/{feature}/ に出力さ れ、Kiro 互換で併用できる。 提供するワークフロー kiro:* — cc-sdd 互換の spec 駆動フロー一 式（生成 step + 検証ゲート群） opsx:* — OpenSpec の change 管理 （propose → apply → archive） steering — .kiro/steering/ をプロジェク トメモリとして生成・同期 導入とステータス npx create-takt-sdd の一発で .takt/ と npm scripts を導入（ --lang ja 対応） 。 cc-sdd v3 対応完了 リリース準備中 MIT / Apache-2.0 github.com/j5ik2o/takt-sdd AI エージェント Claude Code / Codex など — コード・成果物を実際に書く 実作業 cc-sdd SDD の手法定義 — スキル・プロセスの定義情報のみで、それ自体は動かない 定義 takt-sdd workflow + facets の定義資産 — cc-sdd のプロセスを TAKT で実行できる形に定義 定義 TAKT プロセスマネージャー — 定義を読んで step 実行・分岐・完了判定を管理する実行体 実行・管理 以降は takt-sdd を実例に、TAKT でAI駆動開発のワークフローを設計するノウハウを見ていく。 takt-sdd 9
10. takt-sddではどのstepを・どの条件で・どの証跡で次へ進めるかを固定する 入口 kiro:* scripts 安定した surface workflow（YAML）— 実行制御を宣言 step step step rules: condition → next（分岐・差し戻し） facets — プロンプトを 5 つの関心事に分離 Persona Policy Instruction Knowledge Output Contract output contracts STATUS / VERDICT / 証跡 → rules が機械的に評価 loop_monitors 反復を監視し 閾値で介入 workflow _call 合成 spec artifacts .kiro/specs/ requirements / design / tasks 証跡（evidence） validation / review の 判定根拠・証跡 workflow（YAML）が steps・rules・facets・output contracts・loop_monitors・workflow_call を束ね、spec artifacts と証跡へ落とす。 TAKT takt-sdd 10
11. TAKTはAI出力ではなく、実行制御面を決定論化する AIの非決定性は消せない。消すのではなく、制御面で囲い込む。 AI に残すもの（非決定的なまま） 成果物の中身 — 要件文・設計・コード 調査・発見・設計判断の根拠づくり レビューでの指摘内容 YAML で固定するもの（決定論的） 実行順序と遷移条件 — steps + rules 分岐先 — fix / need_replan / ABORT 証跡の形式 — output contract 完了判定 — 検証ゲートを通過したときだけ 重要 TAKT 11
12. facets で部品化し、output contract で出力を定型化する steps: - name: review persona: ai-antipattern-reviewer # facet参照 instruction: ai-review output_contracts: report: - name: ai-review.md format: ai-review # STATUS / findings / evidence rules: - condition: AI固有の問題なし next: COMPLETE - condition: AI固有の問題あり next: fix facets — プロンプトをモノリスにせず、5 つの関 心事 Persona / Policy / Instruction / Knowledge / Output Contract に部品化 同じ facet を複数 step・workflow に差し込んで 再利用できる。ビルトイン facet に自作を足して 差分カスタムも簡単 output contract — AI の非定型な出力を STATUS ・ VERDICT ・証跡の定型出力に変換さ せ、rules が自由文の印象ではなく contract のフ ィールドで機械的に次の step を決められるよう にする TAKT 12
13. 同じワークフロー内でも、生成ステップと判定ステップの権限を分離する 生成と検証を同じ step に混ぜると「作った本人が通した」になる。分けるのは呼び出しではなく権限と役 割。 生成 step（ edit: true ） kiro-spec-requirements / kiro-spec- design / kiro-spec-tasks の生成 step kiro-impl の execute-task / update- progress spec・コードなどの artifact を作成・更新する 判定 step（read-only） kiro-validate-gap / kiro-validate- design （GO / NO-GO）/ kiro-validate- impl kiro-impl の reviewers / verify-task- completion edit: false + readonly 権限 — artifact を直 さず、不足証跡・manual check を返す 判定スキルは生成ワークフローの step として起動される — 例: kiro-spec-design 内で validate-design が、 kiro-impl 内で validate- impl-final が動く。同じワークフローに同居しても、判定 step は read-only に固定される。 takt-sdd 13
14. kiro-impl は実装から最終検証までを1つのワークフローで制御する plan-one-task persona: planner 着手可能な task を選ぶ execute-task persona: coder 選んだ task を実装 workflow_call kiro-ai-quality-gate subworkflow として合成 reviewers — parallel 4 観点 coding architecture QA testing debug-task persona: supervisor 分岐を判定 verify-task-completion persona: supervisor 証跡を確認して完了判定 need_replan any(needs_fix) all("approved") RETRY_TASK NOT_ VERIFIED update-progress persona: coder tasks.md の進捗を更新 validate-impl-final persona: supervisor read-only / GO → COMPLETE block / stop VERIFIED 全 task 完了 残 task あり → 次の task loop_monitors execute ⇄ debug / review の循環を監視 threshold 2 で supervisor が健全性を判定 非生産的なら update-progress へ kiro-impl は 1 task ずつ、AI 品質ゲート（subworkflow） ・4 観点並列 review・supervisor による debug 分岐・completion verification・ 進捗更新を全 task 完了まで反復し、最後に read-only の final validation を通る。 重要 takt-sdd 14
15. kiro-ai-quality-gate は検出・修正・再計画の分岐でループを閉じる review persona: ai-antipattern-reviewer AI 固有の問題を検出 AI 固有の問題なし COMPLETE 問題あり fix persona: coder 指摘を修正 FIXED → 再 review NO_FIX_NEEDED（証跡必須） NEED_REPLAN / BLOCKED ambiguous / blocked / 内部矛盾 need_replan persona: supervisor caller に返して計画へ戻す loop_monitors judge persona: supervisor review ⇄ fix の反復を監視 threshold 3 で判定 検出例: hallucinated path / API、scope mismatch、unsupported claim、unused artifact。ゲートの本質は検出項目数ではなく fix / need_replan への分岐にある。COMPLETE には証跡が必須。 takt-sdd 15
16. まとめ TAKTから学ぶ、AI駆動開発をワークフローとして設計する4つのパターン 1. 作業を分解する AI作業を step + rule + contract に分解する。プロン プトへの依存を減らす。 2. 関心事を分離する 状態変更 workflow と read- only validation を厳格に分け る。自己承認を防ぐ。 3. 分岐を設計する AI 品質ゲートは検出だけでな く、 fix と replan の分岐を 持つ。閉じたループを作る。 4. 上限を強制する parallel review と loop monitor で、レビュー漏れや 未収束（無限ループ）を強制 遮断する。 cc-sdd v3 をこの形で包むことで、工数削減と品質向上を同時に実現する。 AI駆動開発をプロンプトではなく「ワークフローと契約」として設計する。 TAKT 16
17. ご清聴ありがとうございました TAKTでAI駆動開発の品質を設計する かとじゅん（@j5ik2o） — github.com/j5ik2o/takt-sdd