はじめに
AI駆動開発が当たり前になりつつある2026年、ツールの選択肢は急増しています。「仕様駆動開発」を標榜するツール、マルチエージェントオーケストレーション、自動コードレビュー……。名前は聞くけれど、それぞれが開発ライフサイクルのどこを担当し、どう組み合わせるべきなのか、見通しが悪い状況です。
本記事では、cc-sdd、takt、Claude Code Agent Teams、Code Reviewという4つのツール/機能を取り上げ、それぞれの守備範囲と位置づけを整理します。「結局どれを使えばいいの？」という問いに対する、2026年3月時点での回答を示します。
本シリーズは全3回です。
- 第1回（本記事）: ツールの違いと選び方
- 第2回: 企画書から実装までのワークフロー設計
- 第3回: GitHub Issue起点のアジャイルSDDパイプライン構築
AI駆動開発のライフサイクルを俯瞰する
まず、AI駆動開発の典型的なライフサイクルを整理します。
企画書 → 要件定義 → 設計 → タスク分解 → 実装 → レビュー → 統合テスト
この流れ自体は、人間主体の開発と変わりません。違うのは「誰がやるか」です。AI駆動開発では、このライフサイクルの各フェーズをAIエージェントが担当します。ただし、すべてを1つのツールでカバーできるわけではありません。ツールごとに守備範囲が異なります。
cc-sdd — 仕様書を生成するツール（上流担当）
cc-sddは、Kiro IDE の仕様駆動開発プロセスをClaude CodeやCursor、Gemini CLIなど8種のAIエージェントで再現するオープンソースツールです。
cc-sddの守備範囲
ライフサイクルの中で、cc-sddがカバーするのは要件定義→設計→タスク分解の部分です。
企画書 → [要件定義 → 設計 → タスク分解] → 実装 → レビュー
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cc-sddの守備範囲
具体的に何をするか
npx cc-sdd@latest --claude --lang ja でプロジェクトにインストールすると、スラッシュコマンド群が追加されます。
/kiro:spec-init— 機能の概要を伝えると、仕様書のひな型を生成/kiro:spec-requirements— EARS形式の要件定義書を生成/kiro:spec-design— Mermaid図付きの設計書を生成/kiro:spec-tasks— 依存関係付きのタスクリストを生成/kiro:spec-impl— タスクに沿ってTDD形式で実装
各フェーズの間には人間の承認ゲートがあり、AIが生成した仕様書を確認・修正してから次のフェーズに進みます。
cc-sddの強み
- 構造化された仕様書: 曖昧な指示によるバイブコーディングの失敗を防ぐ
- Steeringドキュメント: プロジェクト固有の規約や技術スタックをAIに記憶させ、セッション間で一貫性を保つ
- 成熟度: スター2.6k、v2.1.1、16人のコントリビューター。日本語完全対応
cc-sddの制約
- 1機能の仕様書がrequirements.md、design.md、tasks.mdそれぞれ単一ファイルのため、大きな機能では肥大化しやすい
- タスクの依存関係の順序が正しくないケースが報告されている
- 「機能内」の整合性は保てるが、「機能間」の整合性を自動保証する仕組みは持っていない
takt — マルチエージェントオーケストレーション（下流担当）
takt（Task Agent Koordination Tool）は、Claude Codeの複数エージェントを協調動作させるオーケストレーションツールです。
taktの守備範囲
企画書 → 要件定義 → 設計 → [タスク分解 → 実装 → レビュー]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
taktの守備範囲
cc-sddが上流を担当するのに対し、taktは下流のタスク実行・レビュー・承認ループを担当します。
具体的に何をするか
YAMLでワークフローを定義し、エージェント間の連携ループを自動で回します。
steps:
- name: implement
agent: coder
transitions:
- condition: done
next_step: review
- name: review
agent: architect
transitions:
- condition: approved
next_step: COMPLETE
- condition: rejected
next_step: implement
coderが実装→architectがレビュー→却下されたらcoderに戻る、というループが自動的に回ります。
taktの独自機能
- YAMLベースの宣言的ワークフロー定義: ワークフローをバージョン管理可能
- カスタムエージェント: プロンプトをMarkdownファイルで管理し、allowed_toolsやstatus_patternsを制御
- MAGIシステム: エヴァンゲリオンにインスパイアされた3人格による合議判定
taktの現状
まだ初回コミットのみ（0 stars）で、作者自身も「vibe codingで作った個人プロジェクト」と明記しています。本番運用にはまだ早い段階です。
Agent Teams — Anthropic公式のマルチエージェント機能
2026年2月6日、Opus 4.6と同時にリリースされたClaude Code Agent Teamsは、taktの守備範囲を大部分吸収するAnthropic公式のマルチエージェント機能です。
Agent Teamsの仕組み
環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化すると、複数のClaude Codeインスタンスがチームとして協調動作します。
4つのコンポーネント:
- Lead（リーダー）: 全体を指揮するメインセッション
- Teammates（チームメイト）: 独立したClaude Codeインスタンス
- Task List（共有タスクリスト）: タスクの割り当てと状態管理
- Mailbox（メッセージング）: エージェント間の直接通信
taktとの違い
| takt | Agent Teams | |
|---|---|---|
| ワークフロー定義 | YAML（宣言的） | 自然言語（動的） |
| エージェント対応 | Claude Code | Claude Code |
| コミュニケーション | リーダー経由のみ | メンバー間直接通信可 |
| 状態管理 | ファイルベース | 共有タスクリスト + メールボックス |
| 成熟度 | 初期段階 | 実験的だが公式サポート |
Agent Teamsがtaktを代替する部分
taktのコア機能である「coder → architect → supervisor」のループは、Agent Teamsのリード/チームメイト構造でネイティブに実現できます。
taktに残る独自価値
- YAMLによる再現可能なワークフロー定義
- バッチ処理（
/run-tasks） - Claude Code以外のエージェントへの将来的な拡張
ただし実際には、Agent Teamsの進化速度を考えると、現時点でtaktに投資する理由は薄いというのが率直な評価です。
Code Review — PR自動レビュー
2026年3月9日にリリースされたCode Reviewは、PRに対して複数の専門エージェントを並列で走らせ、検出結果を検証・ランク付けしてコメントを投稿するマルチエージェントレビューシステムです。
Code Reviewの特徴
- 複数エージェントが並列でバグを探索し、交差検証でfalse positiveを排除
- REVIEW.mdとCLAUDE.mdでカスタマイズ可能
- Anthropic社内では、PRの54%に実質的なコメントがつくようになった（従来は16%）
Code Reviewの制約
- Team/Enterpriseプラン限定（Research Preview）
- 1回あたり15〜25ドルのコスト
- 約20分の処理時間
個人開発者（Maxプラン）では利用できません。ただし、GitHub Actionsベースのオープンソース版Claude Code Reviewは引き続き利用可能です。
個人開発者（Maxプラン）の現実的な選択肢
ここまでの整理を踏まえると、個人開発者の選択はシンプルです。
使うべきもの:
- cc-sdd: 仕様生成の構造化ツールとして
- Agent Teams: Phase 1（企画書分解）、Phase 2b（実装）、Phase 3（統合検証）で活用。Code Reviewが使えない環境ではReviewer役のエージェントが代替として機能する
現時点では見送り:
- takt: Agent Teamsが守備範囲を吸収している
- Code Review: Maxプランでは利用不可
まとめ
4つのツール/機能の位置づけを一言で表すと、こうなります。
| ツール | 一言 | 守備範囲 |
|---|---|---|
| cc-sdd | 仕様書を作る | 要件定義→設計→タスク分解 |
| takt | タスクを実行する | タスク実行→レビューループ |
| Agent Teams | チームで働く | タスク実行→レビュー（taktを吸収） |
| Code Review | PRをレビューする | コードレビュー特化 |
cc-sddとAgent Teamsの組み合わせが、2026年3月時点での有力解です。ただし、この2つを「どう組み合わせるか」が次の問題になります。素朴に組み合わせるとウォーターフォールの罠にはまります。
次回の第2回では、企画書から実装までのワークフローをどう設計するか、アジャイルSDDの考え方を解説します。
シリーズ記事:
- 第1回（本記事）: ツール編 — cc-sdd、takt、Agent Teams、Code Reviewは何が違うのか
- 第2回: 設計編 — 企画書から実装までのワークフローをどう設計するか
- 第3回: 実践編 — GitHub Issue起点のアジャイルSDDパイプラインを構築する