TAKT は、計画・実装・レビュー・修正というソフトウェア開発のループを YAML で定義し、AI コーディングエージェントにその工程どおり動いてもらうための CLI ツールだ。他のワークフローツールと分かれるのはレビューの扱いで、レビューで指摘が出たタスクは自動的に修正ステップへ差し戻され、エージェントの判断でスキップすることができない。「エージェントが自分のコードを自分で承認して先へ進む」という長時間タスクでよく起きる失敗を、プロンプトの工夫ではなく工程の構造で潰しにいく設計になっている。
主な特徴
- YAML によるワークフロー定義: 計画から修正までの流れを状態機械として明示的に記述する。出力そのものは毎回変わるが、工程の順序と各ステップの通過条件は実行ごとにぶれない
- レビュー差し戻しの強制: レビューステップの結果は自動的に修正ステップへ戻る。エージェントが自分のコードを自分で承認して先に進む、という品質劣化のパターンを構造的に防ぐ
- ステップごとのファセット注入: ペルソナ・権限・知識・指示・出力契約をステップ単位で分けて持ち、各ステップには必要なものだけを渡す。長時間タスクでのコンテキスト汚染や、実装とレビューの責務が混ざる問題を抑える設計
- 隔離ワークツリーとトレーサビリティ: タスクごとに git worktree を切って実行し、自動コミット・PR 作成・NDJSON 形式のログを残す。複数タスクを並行させても、後から経緯を追える
- マルチプロバイダーと外部連携: Claude Code / Claude SDK / Codex / OpenCode / Cursor / GitHub Copilot CLI / Kiro などを横断して使える。stdio ベースの MCP サーバー（
takt-mcp）として起動すれば、MCP クライアントからタスクを登録できる
料金
無料。MIT ライセンスのオープンソースで、npm からグローバルインストールして使う。ただし実行にはバックエンドとなる AI コーディングツール（Claude Code、Codex など）が別途必要で、そちらの契約・API 利用料は各自で負担する。
メリット・デメリット
✅ メリット
- 「なぜこの実装になったか」を後から追える。どのステップで何が指摘され、どう直したかが NDJSON のログに残るため、手戻りの原因を人間が記憶で再現しなくてよくなる
- 工程ごとにプロバイダーを割り当てられるので、実装は高性能なモデル、レビューは安価なモデル、といったコストの配分ができる
- worktree で隔離されている分、複数タスクを走らせたまま別の作業を続けられる。実行中のタスクが手元の作業ツリーを触らない
⚠️ デメリット
- レビューの差し戻しを強制する分、1 タスクあたりのステップ数が増える。そのぶん実行時間とバックエンドの API 利用料はかさむ
- ワークフローを YAML で設計する初期コストがかかるうえ、プロバイダーごとに挙動が完全には揃わないため、組んだワークフローの移植性には限界がある
類似サービスとの比較
| 比較項目 | TAKT | BMAD-METHOD |
|---|---|---|
| アプローチ | YAML で工程を定義する実行制御エンジン。レビュー差し戻しを強制する | 役割とプロセスの設計を体系化したフレームワーク |
| 対応エージェント | Claude Code / Codex / OpenCode / Cursor / GitHub Copilot CLI など横断 | 特定のツールに依存しない設計 |
| ライセンス | MIT | MIT |
同じ「AI エージェントのワークフロー統制」領域でも、TAKT は実行エンジン側、BMAD-METHOD は方法論側に軸足がある。
こんな人におすすめ
- Claude Code や Codex に長時間のタスクを任せると、途中で文脈が崩れたりレビューが素通りしたりして品質が落ちると感じている開発者
- 複数の AI コーディングツールを役割で使い分け、工程とログを外部から統制したいチーム
- GitHub / GitLab の Issue 駆動開発に AI エージェントを組み込みたい人
まとめ
AI コーディングエージェントの出力品質を「プロンプトの上手さ」ではなく「工程の設計」で担保しにいくツール。レビューをスキップさせない構造が中心にある。初期コストを回収できるかは頻度で決まり、同じ手順を週に何度も回すなら合う一方、月に数回の単発作業なら YAML を組む手間のほうが上回る。