tsumiki claude codeの使い方｜導入からTDD実装までのコツ

tsumiki claude codeとは？Claude Codeに開発手順を加える拡張

Tsumiki（つみき）は、クラスメソッドが公開しているAI開発支援フレームワークです。Claude Codeのモデルや料金プランを置き換えるサービスではなく、要件定義、設計、タスク分割、テスト、実装、検証といった工程をコマンドとして呼び出せるようにするClaude Codeプラグインと考えると分かりやすいでしょう。

素のClaude Codeでは、利用者が「まず仕様を整理する」「テストを先に書く」と指示しなければ、いきなり実装へ進むことがあります。Tsumikiは工程ごとのコマンドと保存先を用意し、会話だけで流れが消えないようにドキュメントとして残します。そのため、速くコードを生成するだけでなく、後から設計や判断の経緯を確認したい開発に向いています。

公式リポジトリでは、Claude Codeを基本の利用先としつつ、rulesyncを組み合わせてほかのAIコーディングツールへコマンドを出力する方法も案内されています。ただし、検索キーワードの中心である「tsumiki claude code」で試すなら、まずClaude Codeプラグインとして使うのが最も分かりやすい入口です。

出典: https://github.com/classmethod/tsumiki

Tsumikiでできること｜5つの機能群を整理

Tsumikiの機能は、ひとつの巨大なコマンドではなく、目的別のコマンド群に分かれています。公式READMEの分類を、使う場面に置き換えると次のようになります。

新しい機能を作るならKairo、テストを細かく管理したいならTDD、既存コードを読み解きたいならDev Skillsや逆解析、という選び方が基本です。迷ったときは/tsumiki:helpでコマンド一覧を表示し、困りごとを自然文で渡して候補を確認できます。

出典: https://github.com/classmethod/tsumiki/blob/main/README.md

Claude Codeへの導入方法｜プラグインを2コマンドで追加

Tsumikiはnpmパッケージを個別に入れるのではなく、Claude Codeのプラグイン機能からGitHubマーケットプレイスを追加して導入します。Claude Codeをインストールし、ログイン済みの状態でプロジェクトのルートディレクトリから実行してください。

1. Claude Codeが起動できることを確認し、claude --versionでバージョンを確認します。/pluginが見つからない場合は、Claude Codeを更新してから再起動します。

2. Tsumikiのマーケットプレイスを追加します。

   /plugin marketplace add https://github.com/classmethod/tsumiki.git
   

3. Tsumikiプラグインをインストールします。

   /plugin install tsumiki@tsumiki
   

4. 反映されない場合は/reload-pluginsを実行し、/tsumiki:helpでコマンド一覧が表示されることを確認します。

インストール後の呼び出しには、プラグイン名の名前空間であるtsumiki:を付けます。たとえば要件定義は/tsumiki:kairo-requirementsです。プラグインを追加しただけでは機能が有効にならない場合があるため、再読み込みとヘルプ表示までを導入手順に含めると切り分けが容易です。

Claude Code公式ドキュメントによると、マーケットプレイスの追加はカタログを登録する操作で、実際の利用には個別プラグインのインストールが必要です。また、プラグインはローカル環境で実行されるため、追加前に配布元と内容を確認してください。

出典: https://code.claude.com/docs/ja/discover-plugins 出典: https://code.claude.com/docs/ja/plugins

Kairoの使い方｜要件定義から実装までの5段階

Kairoは、機能開発の前半で仕様を固め、後半でタスクを順に実装するための中心的な流れです。すべてを一度に承認するのではなく、生成された文書を読んでから次の工程へ進むことが重要です。

1. 技術スタックを初期化する：/tsumiki:init-tech-stackを実行し、フレームワークやライブラリを/docs/tech-stack.mdに整理します。既存プロジェクトでは内容が実態と合っているか確認します。
2. 要件を定義する：/tsumiki:kairo-requirements 商品レビュー機能を追加のように目的を渡します。ユーザーストーリー、EARS記法の要件、エッジケース、受け入れ基準が/docs/spec/{要件名}-requirements.mdに出力されます。
3. 設計を作る：要件を確認してから/tsumiki:kairo-designを実行します。アーキテクチャ、データフロー、型定義、データベース、APIの設計が生成されるため、既存の方針と矛盾しないかを見ます。
4. タスクに分解する：/tsumiki:kairo-tasksで依存関係を含む作業一覧を作ります。/docs/tasks/{要件名}/overview.mdと個別のTASK-XXXX.mdを見て、粒度や実行順を調整します。
5. 実装と検証を進める：全タスクなら/tsumiki:kairo-implement、連続した範囲なら/tsumiki:kairo-loopを使います。Kairoは内部でTDDの工程を呼び出すため、実装後はテスト、ビルド、差分を人が確認します。

この流れのポイントは、コードより先に「何を満たせば完成か」をファイルにすることです。要件が変わったときも、会話履歴を探すのではなく、要件書・設計書・タスクのどこを更新すべきか追跡できます。

出典: https://github.com/classmethod/tsumiki/blob/main/MANUAL.md

TDDコマンドの使い方｜RedからVerifyまでを分けて実行

Kairoに任せず、テスト駆動開発の各段階を自分で進めたい場合は、TDDコマンドを順番に呼び出します。タスク名とタスク番号を受け取る構成なので、先に対象タスクを用意しておくとスムーズです。

1. tdd-requirementsで、そのタスクが満たすべき条件とテストの観点を整理します。
2. tdd-testcasesで正常系、入力不足、権限、境界値などのテストケースを作ります。
3. tdd-redで、まず失敗するテストを実装します。失敗が仕様の不足を示しているか確認します。
4. tdd-greenで、テストを通す最小限の実装を追加します。不要な先回り実装は避けます。
5. tdd-refactorで、テストを壊さない範囲で重複、命名、責務分割を改善します。
6. tdd-verify-completeで、タスクの要件、テスト、実装がそろっているか確認します。

実行例は次の形です。

/tsumiki:tdd-requirements タスクファイル名 TASK番号
/tsumiki:tdd-testcases タスクファイル名 TASK番号
/tsumiki:tdd-red タスクファイル名 TASK番号
/tsumiki:tdd-green タスクファイル名 TASK番号
/tsumiki:tdd-refactor タスクファイル名 TASK番号
/tsumiki:tdd-verify-complete タスクファイル名 TASK番号

Red、Green、Refactorは単なる自動修正の合図ではありません。最初にテストで期待する振る舞いを固定し、最小実装を通し、最後に読みやすさを整えるという順序に意味があります。Tsumikiの出力が正しくても、プロジェクト固有のテストコマンドや実データまでは完全に保証されないため、最終確認は必ずリポジトリ側の検証で行います。

既存コードの解析と日常の修正に使うコマンド

新規開発以外でもTsumikiは役立ちます。Dev Skillsを使う場合は、まず/tsumiki:dev-contextで技術スタック、ルール、設計書、履歴などを読み取り、次に/tsumiki:dev-plan 機能名 実装内容で計画を作ります。計画に沿って/tsumiki:dev-run 機能名 001 005を実行し、最後に/tsumiki:dev-verify 機能名でテスト、ビルド、Lintをまとめて確認する流れです。

既存システムの資料が不足しているときは、次の順で逆解析します。

1. rev-tasksでコードベースを機能単位のタスクへ整理する。
2. rev-designでアーキテクチャ、データフロー、API、データベースの設計書を生成する。
3. rev-specsで既存テストと不足するテストケースを整理する。
4. rev-requirementsで実装から推定した要件と受け入れ基準を文書化する。

バグ対応にはauto-debug、ビルドエラーにはbuild-fix、環境設定にはenv-fix、不安定なテストにはflaky-fix、タイムアウトにはtimeout-fixを使い分けられます。小さな変更ならrefine-planで影響範囲を調べてからrefine-executeへ進む方が、いきなり広範囲を編集するより安全です。

失敗しにくい運用のコツ｜レビューと権限を先に決める

Tsumikiは開発工程を整えてくれますが、生成された仕様やコードの正しさを自動で保証するものではありません。導入直後は次のルールを決めておくと、便利さと安全性を両立しやすくなります。

1. 生成物を承認してから次へ進む：要件書の前提、設計のデータ境界、タスクの完了条件を確認します。曖昧な文書をそのまま実装へ渡さないことが大切です。
2. 変更範囲を小さくする：大きな機能を一度に依頼せず、タスクごとに差分、テスト結果、ログを確認します。失敗しても原因を追いやすくなります。
3. プラグインの権限を意識する：Claude Code公式は、プラグインやマーケットプレイスがユーザー権限でコードを実行できる可能性を説明しています。公式リポジトリのURLを確認し、不要なマーケットプレイスを追加しないでください。
4. チーム共有の範囲を選ぶ：個人の試用はUserまたはLocal、リポジトリの全員に同じ拡張を使わせる場合はProjectのスコープが候補です。設定ファイルをコミットする前に、導入意図をチームで合意します。
5. 更新時にREADMEと差分を見る：TsumikiはGitHubで更新されるため、コマンド名や出力先が変わる可能性があります。実行前に公式READMEとMANUAL.mdを確認し、重要な変更はブランチで試します。

特に、長時間の連続実装を意味するkairo-loopやdev-runは、最初から本番リポジトリで試さない方がよいでしょう。小さなサンプル機能で出力形式とレビュー手順を確かめてから、実プロジェクトへ広げるのが現実的です。

出典: https://code.claude.com/docs/ja/discover-plugins 出典: https://github.com/classmethod/tsumiki/blob/main/MANUAL.md

tsumiki claude codeはどんな人向け？

Tsumikiは、Claude Codeで素早くコードを書きたいだけでなく、仕様・設計・テストをチームの共有資産として残したい人に向いています。新規機能ではKairo、テストを先に細かく書く場面ではTDD、既存システムの引き継ぎではDev Skillsと逆解析、日常の不具合では専用の修正コマンドというように、目的に合わせて入口を変えられる点が特徴です。

一方、1行の修正や短いスクリプトの試作では、工程を増やすTsumikiが重く感じられることもあります。まずは/tsumiki:helpで一覧を確認し、既存の小さな課題をひとつ選んで、要件書がどの程度役立つか、テストが実装を守れるかを試してください。

Tsumikiの価値は、Claude Codeにすべてを任せることではなく、開発の判断を確認可能な手順とファイルに変えることです。公式ドキュメントを参照しながら小さく導入すれば、AIを使った開発でも仕様と品質を追跡しやすくできます。

出典: https://it.impress.co.jp/articles/-/28192