Claude Code に「この機能を追加して」と伝えた瞬間、設計も仕様も固まっていないまま実装が始まる——この問題に悩んだことはないでしょうか。AI は実行力が高い反面、「まず要件を整理する」「設計を先に固める」という段取りを省きがちです。
この問題を解決するのが tsumiki(積み木)です。Classmethod が 2025年7月に MIT ライセンスで公開したオープンソースの Claude Code スキル集で、要件定義→設計→タスク分割→TDD実装という開発プロセスを Claude Code に踏ませるためのフレームワークです。Claude Code の基本やスキル機能を知っている方を対象に、本記事では tsumiki の設計思想・全コマンドの詳細・実際の使い方・gstackとの比較まで体系的に解説します。
- なぜ tsumiki が必要か:AI が「段取りを省く」問題
- 設計思想の3本柱:Specification First / Test First / Quality First
- 4つのコマンドグループの全体像
- インストール方法
- Kairo フロー:新規開発の一気通貫ワークフロー
- TDD フロー:Red-Green-Refactor を Claude Code に徹底させる
- Rev フロー:既存コードからドキュメントを逆生成する
- DCS フロー:アイデア整理と開発相談
- 出力ファイルの全体構成
- gstack との比較:どちらを使うべきか
- 実際のユースケース:どんなプロジェクトで使われているか
- 既存の開発ワークフローへの組み込み方
- コスト管理:Kairo フローを使う前に知っておくべきこと
- よくある質問
- まとめ
なぜ tsumiki が必要か:AI が「段取りを省く」問題
Claude Code の実行力は高く、指示した内容を素早くコードに落とし込めます。しかしこの高い実行力が逆効果になるケースがあります。
| 問題 | 何が起きるか | 根本原因 |
|---|---|---|
| 仕様が曖昧なまま実装が進む | 後から「そういう意味じゃなかった」と大規模修正が必要になる | AI は「実行できること」を優先し、曖昧な仕様を自分で補完して進む |
| 設計なしに複雑な機能が増える | コードが絡み合って後から変更できない構造になる | 設計フェーズを明示的に要求しないと実装に直行する |
| テストが後回しになる | バグが後から見つかり修正コストが跳ね上がる | 「テストを書いてから実装する」という逆順を指示しないと実装→テストの順になる |
| 長時間タスクで脱線する | 途中で別の問題に気づいて元の要件から逸れていく | タスクが細かく分割されていないと優先度の判断ができない |
tsumiki はこれらの問題を「コマンドで強制的に段階を踏ませる」ことで解決します。実装を始める前に必ず仕様と設計が存在するよう、ワークフローを構造化します。
設計思想の3本柱:Specification First / Test First / Quality First
tsumiki のすべてのコマンドは3つの原則に従って設計されています。この原則を理解すると、各コマンドがなぜその順番・そのルールで動くかが分かります。
Specification First(仕様先行)
コードを書く前に必ず仕様書を作ります。「とりあえず動くものを作って後から仕様を整理する」というアプローチを tsumiki は取りません。仕様書が存在しない状態で実装フェーズに進むことができない設計になっています。
この原則が重要な理由は、AI の実装速度が速いほど「仕様の誤解を素早く具現化してしまう」リスクが高まるからです。後から修正する手間は、最初から仕様を固める手間より大きくなります。
Test First(テスト先行)
TDD(テスト駆動開発)の原則に従い、実装コードより先にテストを書きます。Red(失敗)→ Green(合格)→ Refactor(改善)というサイクルを Claude Code に厳密に実行させます。
AI にとって TDD は自然な作業ではありません。「全部一気に実装してからテストを書く」方が短時間で完了するように見えるため、指示しなければそちらに向かいます。tsumiki の TDD コマンドはこの傾向を構造的に防ぎます。
Quality First(品質先行)
実装の速度よりも品質を優先します。具体的には、各フェーズの完了条件が明示されており、条件を満たさないまま次のフェーズに進むことができません。
- 要件定義フェーズ:すべての機能要件・非機能要件が文書化されていること
- 設計フェーズ:アーキテクチャとデータフローが図式化されていること
- タスクフェーズ:依存関係とクリティカルパスが特定されていること
- 実装フェーズ:テストカバレッジが基準値以上であること
4つのコマンドグループの全体像
tsumiki のコマンドは用途別に4グループに分かれています。
| グループ | 略称の意味 | 用途 | 代表コマンド |
|---|---|---|---|
| Kairo(回路) | 開発の回路=全体の流れ | 新規開発:要件定義から実装まで一気通貫 | /tsumiki:kairo-requirements〜implement |
| TDD | Test Driven Development | 個別機能をRed-Green-Refactorで精密に実装 | /tsumiki:tdd-red/green/refactor |
| Rev(逆流) | Reverse Engineering | 既存コードから設計書・仕様書を逆生成 | /tsumiki:rev-design/specs/requirements |
| DCS | Developer Consulting Skills | アイデア整理・デバッグ・影響分析の相談支援 | /tsumiki:dcs:feature-rubber-duck |
新規開発では Kairo → TDD の流れが中心になります。Rev はレガシーコードのドキュメント整備に、DCS は「何を作るか」が固まっていない最初期のアイデア整理に使います。
インストール方法
GitHub から .claude/commands/ に配置する(標準方法)
tsumiki のコマンドファイルは Claude Code の .claude/commands/ ディレクトリに配置するMarkdownファイルです。GitHub リポジトリからコマンドファイルを取得してプロジェクトに追加します。
# プロジェクトルートで実行 git clone https://github.com/classmethod/tsumiki.git /tmp/tsumiki # .claude/commands/ ディレクトリにコマンドファイルをコピー mkdir -p .claude/commands cp /tmp/tsumiki/.claude/commands/*.md .claude/commands/
コピー後、Claude Code を再起動するとコマンドが認識されます。/tsumiki: と入力すればコマンド一覧が表示されます。
.claude/commands/ ディレクトリに置いたMarkdownファイルは自動的にスラッシュコマンドとして登録されます。ファイル名がコマンド名になり(例:kairo-requirements.md → /tsumiki:kairo-requirements)、ファイルの内容がコマンド実行時に Claude Code への指示として送信されます。Claude Code Skills の仕組みと同じ仕組みです。rulesync 経由で複数ツールに対応させる(上級者向け)
rulesync は AI ツール間でルールファイルを共有するためのツールです。tsumiki を Claude Code だけでなく Gemini CLI や Cursor でも使いたい場合に活用します。rulesync を使うと一つのソースから複数ツール向けのコマンドファイルを自動生成できます。
# rulesync のセットアップ(Node.js 18+ 必要) npx -y rulesync init npx -y rulesync config --init # Claude Code 向けにインポート(.claude/commands/ に配置) npx -y rulesync import --targets claudecode --features commands,subagents # Gemini CLI 向けにも生成する場合(.gemini/commands/ に配置) npx -y rulesync generate --targets geminicli --features commands # Cursor 向けにも生成する場合(.cursor/rules/ に配置) npx -y rulesync generate --targets cursor --features commands
インストール後のファイル構成
.claude/
commands/
init-tech-stack.md # 技術スタック選定
kairo-requirements.md # 要件定義
kairo-design.md # 設計書作成
kairo-tasks.md # タスク分割
kairo-implement.md # TDD実装
kairo-task-verify.md # タスク確認
kairo-loop.md # 長時間実装ループ
tdd-requirements.md # TDD用要件定義
tdd-testcases.md # テストケース生成
tdd-red.md # Red フェーズ
tdd-green.md # Green フェーズ
tdd-refactor.md # Refactor フェーズ
tdd-verify-complete.md # TDD完了検証
direct-setup.md # テスト不要タスク設定
direct-verify.md # 直接実装確認
rev-tasks.md # タスク構造抽出
rev-design.md # 設計書逆生成
rev-specs.md # テスト仕様書逆生成
rev-requirements.md # 要件定義書逆生成
dcs-feature-rubber-duck.md # アイデア整理
Kairo フロー:新規開発の一気通貫ワークフロー
Kairo は tsumiki の中核となるフローです。要件定義から実装まで、開発の全フェーズを順番に実行します。各コマンドは前のコマンドが生成したドキュメントを入力として使うため、必ず順番通りに実行する必要があります。
| ステップ | コマンド | 入力 | 出力 | 役割 |
|---|---|---|---|---|
| ① | /tsumiki:init-tech-stack |
プロジェクトの概要説明 | docs/tech-stack.md |
使用技術・フレームワーク・インフラを確定 |
| ② | /tsumiki:kairo-requirements |
tech-stack.md + PRD |
docs/spec/requirements.md |
機能要件・非機能要件を EARS 記法で文書化 |
| ③ | /tsumiki:kairo-design |
requirements.md |
docs/design/design.md |
アーキテクチャ・データフロー図・コンポーネント設計 |
| ④ | /tsumiki:kairo-tasks |
design.md |
docs/tasks.md |
タスク分割・依存関係・クリティカルパスの特定 |
| ⑤ | /tsumiki:kairo-implement |
tasks.md |
ソースコード + テスト | TDD ベースで実装(Red→Green→Refactor) |
① /tsumiki:init-tech-stack
プロジェクトで使用する技術スタックを確定するコマンドです。ここで選択した技術が後続のすべてのコマンドに影響します。Claude Code が技術の選択肢を提案し、ユーザーとの対話で確定します。
# Technology Stack ## Frontend - Framework: React 18 - State Management: Zustand - Styling: Tailwind CSS - Package Manager: pnpm ## Backend - Runtime: Node.js 20 - Framework: Hono - Database: PostgreSQL 16 - ORM: Drizzle ORM ## Infrastructure - Deployment: AWS ECS(Fargate) - CDN: CloudFront - CI/CD: GitHub Actions - IaC: Terraform ## Testing - Unit: Vitest - E2E: Playwright - Coverage Target: 80%+
② /tsumiki:kairo-requirements
要件定義書を生成するコマンドです。EARS(Easy Approach to Requirements Syntax)記法を使って機能要件・非機能要件を文書化します。EARS は自然言語で要件を記述しながらも曖昧さを排除するための構文ルールで、alistair.cockburn.usが提唱した手法です。
EARS には主に4つの構文パターンがあります。
| パターン | 構文 | 使いどころ |
|---|---|---|
| ユビキタス要件 | 「システムは〔動作〕しなければならない」 | 常に満たすべき要件(例:パスワードはハッシュ化して保存する) |
| イベント駆動要件 | 「〔トリガー〕が発生したとき、システムは〔動作〕しなければならない」 | ユーザー操作・外部イベントに応じる要件 |
| 状態駆動要件 | 「〔状態〕である間、システムは〔動作〕しなければならない」 | 特定の状態中にのみ適用される要件 |
| オプション要件 | 「〔機能〕が有効な場合、〔トリガー〕が発生したとき、システムは〔動作〕しなければならない」 | 設定・フィーチャーフラグで制御される要件 |
このコマンドの前に PRD(製品要件ドキュメント)を用意しておくと精度が上がります。PRD は箇条書きの簡単な要求で構いません。/tsumiki:dcs:feature-rubber-duck を先に実行すると自動生成されます。
# PRD: 商品レビューシステム ## 概要 ECサイトのユーザーが購入した商品にレビューを投稿できる機能。 ## ターゲットユーザー - 購入済みの商品を評価したい顧客 - 購入前に商品の評判を知りたい顧客 ## 解決したい課題 現在、購入後のフィードバックを受け取る手段がなく、商品の改善に繋がる情報が得られていない。 ## 主要機能(MVP) - 1〜5の星評価とコメントのテキスト投稿 - 1ユーザー×1商品に1件のみ - 投稿後24時間以内は編集・削除可能 ## 除外(v1では実装しない) - 画像添付 - いいね機能 - 返信スレッド ## 成功指標 - レビュー投稿率:購入ユーザーの20%以上 - API 応答時間:95パーセンタイルで500ms以下
# Requirements ## Functional Requirements ### Authentication - ユーザーは有効なメールアドレスとパスワードで登録できる - システムはパスワードを bcrypt でハッシュ化して保存しなければならない - ユーザーはログイン時に JWT を受け取り、以降のリクエストに使用できる - JWT の有効期限は24時間とし、リフレッシュトークンで更新できる ### Review Feature - 認証済みユーザーは商品に対して1〜5の評価とコメントを投稿できる - 1人のユーザーは1商品に対して1件のレビューのみ投稿できる - レビューは投稿から24時間以内であれば編集・削除できる ## Non-Functional Requirements - API レスポンスタイム: 95パーセンタイルで500ms以下 - 同時接続: 1,000ユーザーの同時リクエストを処理できること - 可用性: 月次 SLA 99.9%(ダウンタイム43分/月以内)
③ /tsumiki:kairo-design
要件定義書をもとにアーキテクチャ設計書を生成するコマンドです。コンポーネント間の関係、データフロー図、API設計、データベーススキーマを文書化します。
データフロー図は Mermaid 記法で生成されるため、そのまま GitHub や Notion で可視化できます。
# Design Specification
## Architecture Overview
```mermaid
graph TD
Client[Browser/Mobile Client]
CDN[CloudFront CDN]
API[Hono API Server]
DB[(PostgreSQL)]
Cache[Redis Cache]
Client --> CDN
CDN --> API
API --> DB
API --> Cache
```
## API Design
### POST /api/reviews
- **認証**: JWT Bearer トークン必須
- **Request Body**: `{ productId: string, rating: 1-5, comment: string }`
- **Response**: `{ id: string, createdAt: string }`
- **エラー**: 401(未認証)、409(重複投稿)、422(バリデーション失敗)
## Database Schema
```sql
CREATE TABLE reviews (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL REFERENCES users(id),
product_id UUID NOT NULL REFERENCES products(id),
rating SMALLINT NOT NULL CHECK (rating BETWEEN 1 AND 5),
comment TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
UNIQUE (user_id, product_id)
);
```
④ /tsumiki:kairo-tasks
設計書をもとにタスクを分割するコマンドです。各タスクに依存関係を明示し、並列実行できるタスクとシーケンシャルに進める必要があるタスクを区別します。クリティカルパス(最も時間がかかる依存チェーン)も特定します。
# Implementation Tasks ## Critical Path: 認証 → 商品 → レビュー ## Phase 1: インフラ・環境構築(並列実行可) - [ ] TASK-001: PostgreSQL スキーマ作成(migrations/001_initial.sql) - [ ] TASK-002: Hono プロジェクト初期化(src/index.ts) - [ ] TASK-003: Drizzle ORM 設定(drizzle.config.ts) ## Phase 2: 認証機能(TASK-001, TASK-002 完了後) - [ ] TASK-004: ユーザーモデル実装(src/models/user.ts) - [ ] TASK-005: 登録エンドポイント(POST /api/auth/register) - [ ] TASK-006: ログインエンドポイント(POST /api/auth/login) - [ ] TASK-007: JWT ミドルウェア(src/middleware/auth.ts) ## Phase 3: レビュー機能(TASK-004〜007 完了後) - [ ] TASK-008: レビューモデル実装(src/models/review.ts) - [ ] TASK-009: レビュー投稿エンドポイント(POST /api/reviews) - [ ] TASK-010: レビュー一覧エンドポイント(GET /api/reviews/:productId)
⑤ /tsumiki:kairo-implement
タスクリストをもとに TDD ベースで実装を実行するコマンドです。内部的に TDD のサイクル(後述)を自動的に回しながら進みます。タスクの完了チェックを更新しながら進捗を管理します。
長時間の実装が必要な場合は /tsumiki:kairo-loop コマンドと組み合わせます。kairo-loop はセッション切れや想定外の中断に対処するためのループ実行機構です。
# 現在のタスク進捗を確認する /tsumiki:kairo-task-verify # 長時間実装(中断リカバリー機能付き) /tsumiki:kairo-loop
TDD フロー:Red-Green-Refactor を Claude Code に徹底させる
TDD コマンドは Kairo の kairo-implement が内部で使う仕組みですが、個別のタスクに対して手動で実行することもできます。より細かく制御したい場合や、Kairo 外の既存プロジェクトに TDD を導入する場合に使います。
実行時には kairo-tasks が生成した要件名と TASK 番号を引数として渡します。
| フェーズ | コマンド | 何をするか | 完了条件 |
|---|---|---|---|
| 要件定義 | /tsumiki:tdd-requirements [TASK-NNN] |
対象タスクの実装範囲を限定・詳細化 | 実装すべき動作が箇条書きで明示されている |
| テストケース生成 | /tsumiki:tdd-testcases |
テストファイルの骨格を生成(中身は未実装) | テストケースの名前と期待動作が定義されている |
| Red フェーズ | /tsumiki:tdd-red |
失敗するテストを実装 | 全テストが実行されて失敗することを確認 |
| Green フェーズ | /tsumiki:tdd-green |
テストを通過する最小実装を書く | 全テストが合格(品質は問わない) |
| Refactor フェーズ | /tsumiki:tdd-refactor |
テストを維持しながらコードを改善 | 全テスト合格かつコード品質基準クリア |
| 完了検証 | /tsumiki:tdd-verify-complete |
実装の完了を検証しレポートを生成 | 要件達成率100%・カバレッジ基準達成 |
Red フェーズの意味
TDD の「まず失敗するテストを書く」というフェーズは、AI にとって最も反直感的なフェーズです。実装がないのにテストを書き、わざと失敗させます。
このフェーズの目的は「テストが実際に何かを検証していることを確認する」ことです。常に合格するテスト(何も検証していないテスト)を書いてしまうことを防ぐため、まず「実装がなければ失敗する」ことを確認します。
import { describe, it, expect } from "vitest";
import { submitReview } from "../src/services/review";
describe("submitReview", () => {
it("評価が1〜5の範囲内なら投稿できる", async () => {
const result = await submitReview({
userId: "user-1",
productId: "product-1",
rating: 5,
comment: "良い商品でした",
});
expect(result.id).toBeDefined();
expect(result.rating).toBe(5);
});
it("評価が0の場合はバリデーションエラー", async () => {
await expect(submitReview({
userId: "user-1",
productId: "product-1",
rating: 0, // 無効な値
comment: "",
})).rejects.toThrow("Rating must be between 1 and 5");
});
it("同一ユーザーが同一商品に2件目を投稿しようとするとエラー", async () => {
await expect(submitReview({
userId: "user-1",
productId: "product-1", // 1件目と同じ
rating: 3,
comment: "やっぱり普通でした",
})).rejects.toThrow("Review already exists");
});
});
// → この時点で submitReview が実装されていないため全テストが失敗(Red)
Green フェーズ:最小実装
Green フェーズでは「テストを通過する最小限のコードだけを書く」というルールが重要です。エレガントな実装・エラーハンドリングの充実・パフォーマンス最適化はすべてRefactorフェーズに後回しにします。
import { db } from "../db";
import { reviews } from "../db/schema";
import { eq, and } from "drizzle-orm";
// Green フェーズ: テストが通る最小実装。エラーハンドリングは後回し。
export async function submitReview(input: {
userId: string;
productId: string;
rating: number;
comment: string;
}) {
if (input.rating < 1 || input.rating > 5) {
throw new Error("Rating must be between 1 and 5");
}
const existing = await db.select().from(reviews).where(
and(eq(reviews.userId, input.userId), eq(reviews.productId, input.productId))
);
if (existing.length > 0) {
throw new Error("Review already exists");
}
const [result] = await db.insert(reviews).values({
userId: input.userId,
productId: input.productId,
rating: input.rating,
comment: input.comment,
}).returning();
return result;
}
// → テスト全件 Green。次は Refactor で品質を上げる。
この実装にはトランザクション管理・適切なエラーコード・ログ出力がありません。Green フェーズではそれで構いません。Refactor フェーズでこれらを追加します。テストが壊れないことを確認しながら改善するので、安全に品質を上げられます。
この制約が意味するのは、「まず動く」を確認してから「良く動く」に移行するということです。AI は実装を一度に完成させようとする傾向があるため、この段階分けを強制するのが tsumiki の価値の一つです。
DIRECT コマンド:テスト不要なタスク向け
設定ファイルの作成・フォルダ構造の初期化・サードパーティサービスの設定など、TDD が適さないタスクもあります。こうしたタスクには DIRECT コマンドを使います。
| コマンド | 用途 |
|---|---|
/tsumiki:direct-setup |
テスト不要のタスクを設定・実装する(環境構築・設定ファイル作成など) |
/tsumiki:direct-verify |
direct-setup の結果を検証する(期待した状態になっているか確認) |
# Terraform の初期化(テストが書けない設定作業) /tsumiki:direct-setup TASK-001 # 設定が意図通りになっているか確認 /tsumiki:direct-verify TASK-001
Rev フロー:既存コードからドキュメントを逆生成する
Rev(Reverse Engineering)コマンドは、ドキュメントが存在しないレガシーコードや引き継いだシステムに対して使います。コードを読んで設計書・仕様書・要件定義書を自動生成します。
| コマンド | 入力 | 出力 | 用途 |
|---|---|---|---|
/tsumiki:rev-tasks |
既存コードベース | docs/tasks.md(現在の実装タスク構造) |
「このコードは何を実現しているか」をタスク粒度で把握 |
/tsumiki:rev-design |
既存コードベース | docs/design/design.md |
設計書がない既存システムのアーキテクチャを可視化 |
/tsumiki:rev-specs |
既存コードベース | docs/spec/specs.md |
既存コードからテスト仕様書を逆生成(テスト追加の足がかりに) |
/tsumiki:rev-requirements |
既存コードベース | docs/spec/requirements.md |
「このシステムは何をするシステムか」を要件定義書として文書化 |
Rev の典型的なユースケースは3つです。
- レガシーシステムのドキュメント整備:長年メンテナンスされてきたが設計書がないコードに対して、現状の設計を文書化する
- 引き継ぎ作業の加速:前任者が作成したシステムを引き継ぐとき、コードを読む前に全体像を把握する
- リファクタリング前の現状把握:大規模リファクタリングの前に、現在の設計と要件を明文化しておく
# まず設計を把握する /tsumiki:rev-design # 要件定義書を逆生成 /tsumiki:rev-requirements # 既存テストがない場合、仕様書をもとに TDD フローに入る /tsumiki:tdd-testcases /tsumiki:tdd-red ...
DCS フロー:アイデア整理と開発相談
DCS(Developer Consulting Skills)は「作りたいものはあるが、まだ形になっていない」段階から使えるコマンド群です。
/tsumiki:dcs:feature-rubber-duck
「Rubber Duck Debugging」の AI 版です。AI がユーザーに質問を投げかけることで、漠然としたアイデアを構造化された PRD に変換します。ユーザーが全部考えて書く必要はなく、AI の質問に答えていく形式で PRD が完成します。
質問の例:
- 「このシステムの主なユーザーは誰で、どんな課題を持っていますか?」
- 「既存の解決策と比べて、何が違いますか?」
- 「成功の定義は何ですか?どのメトリクスで測りますか?」
- 「どんな制約がありますか(技術・予算・期限)?」
- 「最初のバージョンに含めないものは何ですか?」
すべての質問に答えると、PRD.md が自動生成されます。このファイルを /tsumiki:kairo-requirements に渡すことで、Kairo フローに入れます。
その他の DCS コマンド(バグ調査・影響範囲分析・パフォーマンス分析)は、対話形式で開発上の問題を相談できるコンサルティング機能として機能します。
出力ファイルの全体構成
tsumiki が各コマンドで生成するファイルの全体像です。
project-root/
docs/
tech-stack.md # init-tech-stack が生成
spec/
requirements.md # kairo-requirements が生成(EARS記法)
prd.md # dcs:feature-rubber-duck が生成(任意)
design/
design.md # kairo-design が生成
dataflow-diagram.md # kairo-design が生成(Mermaid)
tasks.md # kairo-tasks が生成(チェックリスト形式)
src/
(実装コード) # kairo-implement / tdd-green が生成
tests/
(テストファイル) # tdd-testcases / tdd-red が生成
これらのドキュメントは Git で管理することで、「なぜこの実装にしたか」という設計判断の経緯をコードと一緒に保管できます。後からコードを読む人(未来の自分も含む)が設計の意図を理解するための重要な資産になります。
gstack との比較:どちらを使うべきか
gstack(Garry Tan / YC CEO が公開)と tsumiki(Classmethod が公開)はどちらも Claude Code のスキル集ですが、設計思想が根本的に異なります。
| 比較軸 | tsumiki | gstack |
|---|---|---|
| コアコンセプト | 仕様駆動開発フレームワーク | AI エンジニアリングチームシミュレータ |
| 最適な場面 | 新規開発・ゼロから始める | 既存プロジェクトの品質管理・リリース管理 |
| 主なワークフロー | 要件定義→設計→TDD実装の線形フロー | Think→Plan→Build→Review→Test→Ship→Reflect の反復サイクル |
| TDD 対応 | ネイティブ(Red/Green/Refactor を専用コマンドで管理) | テスト機能あり(/qa系)だが TDD の手順管理ではない |
| セキュリティ | 実装フェーズに組み込まれた品質チェック | 専用 /cso コマンド(14フェーズ監査) |
| デザイン監査 | 設計書レベルの確認 | /design-review(AIスラップ検出・80項目チェック) |
| ブラウザ自動化 | なし | /browse(永続Chromiumデーモン) |
| ドキュメント管理 | 設計書・要件定義書を自動生成 | /document-release(README・CHANGELOG 自動更新) |
| 作者 | Classmethod, Inc.(企業) | Garry Tan(個人) |
tsumiki と gstack は使い分けるべきもので、競合するものではありません。
| 状況 | 推奨 |
|---|---|
| 新しいプロダクトをゼロから作る | tsumiki(要件定義から設計まで構造化) |
| 既存プロダクトのバグ修正・機能追加 | gstack(/review・/investigate・/canary) |
| コードの品質監査をしたい | gstack(/cso・/design-review) |
| TDD で特定機能を実装したい | tsumiki(tdd-red/green/refactor) |
| レガシーコードのドキュメントが欲しい | tsumiki(rev コマンド群) |
| リリース管理を自動化したい | gstack(/ship・/land-and-deploy・/canary) |
新規プロジェクトは tsumiki で仕様・設計・実装を固め、リリース後の継続的な開発と品質管理は gstack を使う、という組み合わせが現時点での最も強力な構成です。
実際のユースケース:どんなプロジェクトで使われているか
ユースケース1:AWS インフラ構築
Terraform を使った AWS インフラ構築に tsumiki を適用した事例です。
/tsumiki:init-tech-stackでインフラ要件(セキュアな開発環境・VPC・NAT Gateway)を確定/tsumiki:kairo-requirementsでセキュリティ要件(踏み台不要・プライベートサブネット必須)を文書化/tsumiki:kairo-designでVPC設計・サブネット構成・ルーティングを図式化/tsumiki:kairo-tasksで「Terraform 初期化」「VPC 作成」「サブネット設定」「IGW/NGW 設定」に分割/tsumiki:direct-setupで各タスクを実装(インフラ設定はテストが書けないため DIRECT コマンドを使用)
この事例での発見は、インフラ構築でも要件定義→設計のフェーズを踏むことで、設定ミスの手戻りが減ったという点です。Terraform を直接書き始めると、後から「このリソースが必要だった」という追加が生まれやすくなります。
ユースケース2:BigQuery データツール開発
Google BigQuery のテーブル説明を自動生成するツールを開発した事例です。Gemini API・Google Sheets・GitHub PR 作成が絡む複雑な実装でした。
Kairo フローで要件定義から始めたことで、「認証設定」「API 統合」「エラーハンドリング」「パフォーマンス最適化」が実装中に自動的に追加されました。この事例では kairo-implement が自律的に品質を上げる判断をしたという点が注目されています。
既存の開発ワークフローへの組み込み方
tsumiki はゼロからの新規開発だけでなく、既存ワークフローへの段階的な導入もできます。
最初に試すべきコマンド3本
すべてのコマンドを一度に使おうとせず、まず以下の3本から始めるのが現実的です。
| コマンド | 推奨理由 | 期待できる効果 |
|---|---|---|
| /tsumiki:dcs:feature-rubber-duck | 既存のコードに影響しない・アイデア整理だけに使える | 「とりあえず実装」を防ぐ習慣がつく。PRD を書く負担が減る |
| /tsumiki:rev-design | 既存コードを変えず設計書だけ生成できる | 引き継ぎドキュメントや設計レビューの準備が10分で完成 |
| /tsumiki:kairo-tasks | 設計が完成しているプロジェクトで使える | タスク分割の精度が上がり「次に何をするか」が明確になる |
Hooks との組み合わせ
Claude Code の Hooks 機能を使うと、特定のコマンド実行前に必ず tsumiki の特定フェーズを踏ませることができます。たとえば「実装系のコマンドを実行する前に kairo-tasks が存在しない場合は警告を出す」という制御が可能です。
またサブエージェントと組み合わせることで、kairo-implement の各タスクを並列で実行させることも可能です。ただしこれは上級の使い方であり、最初は順次実行から始めることを推奨します。
コスト管理:Kairo フローを使う前に知っておくべきこと
tsumiki の Kairo フローは強力ですが、コンテキストの長さが増加するためコストも増加します。
| フェーズ | コンテキスト量 | コストの目安 |
|---|---|---|
| init-tech-stack | 低 | 数セントレベル |
| kairo-requirements | 中 | 数十セント〜数ドル(要件の複雑さによる) |
| kairo-design | 高(requirements.md を全参照) | 数ドル〜十数ドル |
| kairo-tasks | 高(requirements.md + design.md を参照) | 数ドル |
| kairo-implement | 非常に高(全ドキュメントを参照しながら実装) | タスク数×数ドル〜数十ドル |
コスト削減の実践的なアドバイスをまとめます。
- 小規模から始める:最初は1〜2機能の小さなスコープで試して、1機能あたりのコストを把握する
- kairo-implement を個別タスクで実行:全タスクを一度に渡すのではなく、TASK-001 から順に個別実行するとコンテキストが短くなる
- TDD コマンドを直接使う:Kairo フローを使わずに TDD コマンドだけを使う方がコストを抑えられる
- 設計書を事前に手書きする:
kairo-requirementsとkairo-designを手書きで準備して、kairo-tasksから tsumiki に入ると要件定義・設計フェーズのコストを削減できる
よくある質問
まとめ
tsumiki が解決する問題と、各コマンドグループの役割を整理します。
| 問題 | tsumiki の解決策 | 使うコマンド |
|---|---|---|
| 仕様が曖昧なまま実装が進む | 要件定義書の生成を実装の前提条件にする | kairo-requirements / dcs:feature-rubber-duck |
| 設計なしにコードが増える | 設計書の生成を実装の前提条件にする | kairo-design |
| テストが後回しになる | Red→Green→Refactor のサイクルを強制 | tdd-red / tdd-green / tdd-refactor |
| 長時間タスクで脱線する | タスクを依存関係付きで分割し順番を管理 | kairo-tasks / kairo-loop |
| レガシーコードのドキュメントがない | コードから設計書・要件定義書を逆生成 | rev-design / rev-requirements |
| アイデアが形にならない | AI の質問に答えるだけで PRD が完成 | dcs:feature-rubber-duck |
tsumiki の設計思想「Specification First / Test First / Quality First」は、AI の実行力を最大限活かしながらも品質を担保するための構造的な解決策です。gstack と組み合わせれば、要件定義から本番デプロイまでのすべてのフェーズを AI 支援で進められます。まず /tsumiki:dcs:feature-rubber-duck か /tsumiki:rev-design から試してみてください。
Claude Code Skills の基本・Skills の設計ガイド・gstack 完全ガイドも合わせて参照してください。
