tsumiki（ツミキ）とは？クラスメソッドのAI駆動開発フレームワークをClaude Codeで使う方法【1.5.0対応】

tsumiki（ツミキ）は、クラスメソッドが2025年7月29日にオープンソースで公開した、Claude Code向けのAI駆動開発フレームワークです。GitHubのclassmethod/tsumikiで配布され、ライセンスはMITです。中身は、要件整理・計画・テストファーストの実装・検証をClaude Codeに段階的に進めさせるスラッシュコマンドとスキルの集まりです。

2026年8月3日の1.5.0で構成が変わりました。公開当初の看板だった「Kairo」「TDD」コマンドは、別プラグインのtsumiki-legacyに移っています。現在の本体は「Dev Skills」と呼ばれるスキル群が中心です。本記事は、リポジトリの README・各スキル定義・コミット履歴（いずれも2026年9月29日に確認）をもとに、現行版の構成、インストールと更新の手順、旧コマンドの扱い、Claude Code以外で使うときの手順を整理します。

まとめ：tsumikiの要点

• tsumikiはクラスメソッド製のOSS（MIT）で、Claude Codeのプラグインとして入れます。読み方は「ツミキ」、由来は「積み木」です。
• インストールは /plugin marketplace add https://github.com/classmethod/tsumiki.git と /plugin install tsumiki@tsumiki の2行です。コマンドは /tsumiki: を付けて呼びます。
• 1.5.0以降、Kairo・TDD・DIRECTの旧コマンドは /plugin install tsumiki-legacy@tsumiki を追加しないと使えません。呼び出しも /tsumiki-legacy:kairo-requirements のように変わります。
• 現行の推奨フローは Dev Skills の dev-context（または dev-init）→ dev-plan → dev-run → dev-verify です。
• GitHubにReleasesやタグはありません。版は .claude-plugin/plugin.json の version で確認します。サードパーティのマーケットプレイスは自動更新が既定でオフです。自動更新を有効にせず、手動更新もしていない環境では、導入時の版が残ります。
• Claude Code以外（Cursor・Gemini CLI・Codex CLIなど）では rulesync で変換します。ただし README の手順のうち2か所は、rulesync 23.0.0 では通りません。

tsumikiの正体：クラスメソッドが公開したClaude Codeプラグイン

クラスメソッドの2025年7月29日のプレスリリースは、tsumikiを「Claude Code」の活用を体系化・効率化するフレームワークと紹介しています。ライセンスは「MIT License（商用利用可能）」です。利用料はかかりませんが、実際に動かすのはClaude Codeなので、Claude Code側の利用料金（Anthropicのサブスクリプションか API 従量課金）は別途必要です。

読み方と「AITDD」の意味

正式表記は「Tsumiki（積み木）」で、読みは「ツミキ」です。検索では「tumiki」「tsumiki ai」と綴られることもありますが、同じリポジトリを指します。公開時に掲げた考え方が AITDD（AI-assisted Test-Driven Development、AI支援型テスト駆動開発）です。プレスリリースは「従来のテスト駆動開発（TDD）にAI技術を組み合わせ、開発効率を向上させる手法」と定義しています。AIに実装を任せる前に、要件とテストを先に固めて品質の基準にする、という順序が要点です。リポジトリの book/ ディレクトリには、AITDDの定義から失敗事例までを8章にまとめた解説文書も入っています。

GitHubリポジトリの構成と版の見方

リポジトリは2025年7月24日に作成されました。2026年9月29日時点のスター数は973、フォーク数は63です。直下の主なディレクトリは次のとおりです。

GitHubの Releases とタグは1件も作られていません。「最新版はいくつか」を確かめるときは、.claude-plugin/plugin.json の "version" を見ます。2026年9月29日時点では 1.5.0 です。

1.1.1から1.5.0までの変更点：Dev Skillsへの移行

plugin.json のコミット履歴から、版ごとの主な変更を抜き出しました。日付は版番号を変更したコミットの日付（UTC）で、mainへの取り込み日とは異なります。たとえば1.5.0の変更コミットは2026年8月3日、mainへの取り込みは8月7日です。

影響が大きいのは1.5.0です。このコミットで、Kairo・TDD・DIRECTのコマンド16本と kairo-implement スキルが legacy/ へ移動しました。本体の tsumiki プラグインを1.5.0に更新すると、/tsumiki:kairo-requirements などは見つからなくなります。2025年に書かれた導入記事の多くはKairoを入口にしているので、その手順をそのまま実行すると最初のコマンドで止まります。

tsumikiのインストールと更新の手順

Claude Codeへのプラグイン追加

Claude Codeのセッション内で、マーケットプレイスの登録とプラグインのインストールを続けて実行します。

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

インストール後のコマンドは /tsumiki:dev-plan のように tsumiki: 付きで呼びます。一覧を見たいときや、困りごとから使うコマンドを探したいときは /tsumiki:help を使います。引数なしなら一覧、コマンド名なら詳細、それ以外の文章なら困りごと検索として動きます。プラグインの仕組みやマーケットプレイスの登録方法はClaude Codeプラグインの作り方と社内配布で詳しく扱っています。

Kairo・TDD向けのtsumiki-legacy追加手順

Kairo・TDD・DIRECTを使い続ける場合は、同じマーケットプレイスから2つ目のプラグインを入れます。

/plugin install tsumiki-legacy@tsumiki

呼び出しの接頭辞は tsumiki-legacy: です（例：/tsumiki-legacy:kairo-requirements）。既存のスクリプトや手順書に /tsumiki:kairo- と書いてある箇所は、書き換えが必要です。

更新は自動では届かない：版の確認と手動更新

Claude Codeの公式ドキュメントによると、Anthropic公式以外のマーケットプレイスは自動更新が既定でオフです。tsumikiもこれに当たるため、自動更新を有効にせず、手動更新もしていない環境では、導入時の版が残ります。更新するときは、シェルで次を実行するか、/plugin の Installed タブで Update now を選びます。

claude plugin marketplace update tsumiki
claude plugin update tsumiki@tsumiki

シェルから更新した場合は、Claude Codeのセッション内で /reload-plugins を実行するか、セッションを再起動して反映します。1.5.0への更新でKairoのコマンドが消えた場合は、レガシープラグインへの分離を確認してください。tsumiki-legacy を追加すれば戻ります。

npx tsumiki installの配布版とプラグイン方式への移行

公開直後のREADMEは npx tsumiki install で .claude/commands/ にコマンドを配置する方式でした。npmの tsumiki パッケージは0.0.6（最終更新2025年7月30日）から更新されておらず、この方法で入るのはDev SkillsもDCSも含まない初期版です。古いブログ記事の手順で入れた場合は、プラグイン方式に入れ直してください。

Dev Skillsの使い方：コンテキスト作成から検証までの実行手順

1.3.0で入ったDev Skillsは、1.5.0での本体の中心です。コンテキスト・計画・検証レポートなどの文書は、主に docs/dev/ の下に書き出されます。実装コードや、dev-initが生成するプロジェクトファイルは、それぞれの配置先に作成されます。

# 既存プロジェクトの分析（新規なら /tsumiki:dev-init）
/tsumiki:dev-context

# 実装計画の作成（plan名 auth・要件は文章かPRDファイルのパス）
/tsumiki:dev-plan auth "ユーザー認証機能を実装"

# タスク001〜005を自動で連続実装
/tsumiki:dev-run auth 001 005

# plan単位でテスト・ビルド・Lintを検証
/tsumiki:dev-verify auth

前提になる docs/dev/context.md

dev-context は既存プロジェクトの技術スタック、テスト環境、ディレクトリ構造、コーディング規約の4領域を並行して調べ、500行以内の docs/dev/context.md にまとめます。新規プロジェクトでは dev-init が対話で技術スタックを決め、同じ形式のファイルを作ります。dev-plan・dev-impl・dev-verify・dev-debug はこのファイルを前提にしているので、最初に必ず作ります。何から始めればよいか分からないときは、目的を聞いて起点のスキルを提案する dev-navigate があります。

dev-planのLightweightとFull-spec

dev-plan には2つのモードがあり、実行時に選びます。

Full-specでは、EARS記法の機能要件（requirements.md）、As a／I want／So that 形式のユーザーストーリー（user-stories.md）、Given／When／Then 形式の受入基準（acceptance-criteria.md）を作ってから設計とタスク分解に進みます。旧Kairoの要件定義に相当する工程は、現行版ではここにあります。

dev-impl・dev-run・dev-verify・dev-debugの役割

dev-impl はタスクを1つずつ、テストを先に書いてから実装します。dev-impl auth 001 のようにplanのタスクを指定する通常モードと、dev-impl "バリデーションメッセージを日本語に変更" のようにplanなしで小さく直すクイックモードがあります。dev-run は指定範囲のタスクをサブエージェントに渡し、impl→verify→debug を自動で繰り返します。dev-verify はタスクの完了状態、全テスト、ビルド、Lintを確かめ、レポートを docs/dev/plans/<plan名>/reports/ に出します。失敗したときの dev-debug は、コンパイル・型エラー、テスト失敗、ランタイムエラー、環境・設定、Lint、依存関係、Webテストの7種類に分けて原因を探ります。

画面仕様とPlaywrightのWebテスト

Webアプリ向けには、ソースコードから画面仕様を起こす dev-screen-spec、その仕様からPlaywright用のテスト計画を作る dev-webtest-plan、実際に画面を操作して確かめる dev-webtest がつながっています。見た目の崩れ、アクセシビリティ違反、レスポンシブ不備が見つかった場合は、dev-debug webtest が修正を引き受けます。

Kairo・TDDコマンド（レガシー）の流れと出力先

tsumiki-legacy に移った旧コマンドも、機能は残っています。既存のKairo成果物がある案件は、こちらを使い続けるのが無難です。

Kairoの要件定義・設計・タスク分割の手順

/tsumiki-legacy:init-tech-stack
/tsumiki-legacy:kairo-requirements ユーザー認証システム
/tsumiki-legacy:kairo-design ユーザー認証システム
/tsumiki-legacy:kairo-tasks ユーザー認証システム
/tsumiki-legacy:kairo-loop ユーザー認証システム TASK-0001 TASK-0005

kairo-requirements はEARS記法の要件定義書を docs/spec/{要件名}/requirements.md に、ヒアリング記録を同じ場所の interview-record.md に書き出します。以降、設計は docs/design/、タスクは docs/tasks/ に出力されます。kairo-tasks は1日単位でタスクを切り、kairo-loop（1.2.0で追加）が指定したTASK-IDの範囲を順に実装します。TASK-IDは kairo-tasks が「TASK-0001」の4桁形式で採番するので、docs/tasks/ に生成された番号をそのまま渡します。Dev Skillsの出力先は docs/dev/ なので、同じリポジトリで新旧を混ぜると文書が2系統に分かれます。

TDDコマンド：Red・Green・Refactorを1段ずつ実行

TDDコマンドは、テスト駆動開発の各段階を人が区切って進めたいときに使います。tdd-requirements→tdd-testcases→tdd-red（失敗するテストを書く）→tdd-green（通す最小実装）→tdd-refactor→tdd-verify-complete の順です。作業記録は docs/implements/ に残ります。設定ファイルの変更のようにテストを書きにくい作業は、DIRECT（direct-setup・direct-verify）で扱います。

既存コードへの適用：リバースエンジニアリングとDCS

rev系4コマンドの実行順

文書がない既存システムに入るときは、コードから文書を逆に起こす4本を /tsumiki:rev-tasks→rev-design→rev-specs→rev-requirements の順に実行します。タスク構造、設計文書、テスト仕様書、要件定義書の順で、READMEもこの順を推奨しています。

DCSの分析コマンド

DCSはコードを変更せず、調べて文書にするためのコマンド群で、/tsumiki:dcs:bug-analysis のように呼びます。READMEの表には9本が載っています（アイデアをPRDにまとめる feature-rubber-duck、シーケンス図、状態遷移、影響範囲、増分開発計画、バグ原因、性能、コードへの質問、エッジケース）。commands/dcs/ にはこれに test-performance-analysis を加えた10本が入っています。旧版の解説で見かける「DCS＝自動品質スコアリング」という説明は、リポジトリのどこにも根拠がありません。

1.4.0以降の追加：IPA準拠のセキュリティ検査とタスク分割

1.4.0で入った ipa-security-check は、IPAの「安全なウェブサイトの作り方 改訂第7版」「安全なSQLの呼び出し方」「ウェブ健康診断仕様」「安全なウェブサイトの運用管理に向けての20ヶ条」「セキュリティ実装チェックリスト」の5資料を基準に、リポジトリのコードと設定ファイルを静的に検査します。SQLインジェクションやXSSなど11種類の脆弱性を対象にし、検出結果には原典の資料名・節・ページを添えます。続く ipa-security-guide は、その報告を読んで対応不要の候補を分け、dev-debug に渡せる優先順位付きの修正依頼リストに変換します。

1.5.0では、依頼を実行可能なタスクへ分ける task-breakdown（dev-planのFull-specが内部で使う）と、業務受入・システム受入・非機能受入の試験項目をL1〜L3の3階層で作る uat-test-design が加わりました。

Claude Code以外で使う：rulesync 23.0.0での手順

READMEは、Claude Code以外のツールで使う方法として rulesync を案内しています。.claude/ 配下のコマンドを一度rulesync形式に取り込み、Cursor、Gemini CLI、Codex CLIなどの形式で書き出す仕組みです。2026年9月29日に、リポジトリの commands/ と skills/ をプロジェクトの .claude/ に置き、rulesync 23.0.0 で実行しました。README の手順のうち、次の2か所はそのままでは通りませんでした。

• npx -y rulesync config --init は error: unknown command 'config' で止まる（init だけで設定ファイルまで作られる）
• --experimental-simulate-commands は error: unknown option になる（現行名は --simulate-commands）

また README の例は --features commands,subagents だけを取り込むため、1.3.0以降の中心であるDev Skills（skills/）が変換対象から漏れます。skills を加えると、27本のコマンドと14本のスキルが取り込まれました。uat-test-design だけは、SKILL.md の先頭に name がないため rulesync がスキップします。動作を確認した手順は次のとおりです。コピー先の .claude/commands と .claude/skills、取得先の /tmp/tsumiki がまだ存在しない環境で実行してください。既存ディレクトリがある場合は、そのまま再実行せず、作業用ディレクトリで変換してから必要なファイルを統合します。

# tsumikiのコマンドとスキルをプロジェクトの .claude/ に置く
git clone --depth 1 https://github.com/classmethod/tsumiki.git /tmp/tsumiki
mkdir -p .claude
cp -r /tmp/tsumiki/commands .claude/commands
cp -r /tmp/tsumiki/skills .claude/skills

# rulesync形式へ取り込む
npx -y [email protected] init
npx -y [email protected] import --targets claudecode --features commands,skills

# Cursor向けに書き出す（.cursor/commands と .cursor/skills が生成される）
npx -y [email protected] generate --targets cursor --features commands,skills \
  --simulate-commands --simulate-skills

rulesyncのヘルプによると、--simulate-commands と --simulate-skills が使えるのは copilot・cursor・codexcli の3つです。Claude Codeのプラグインとして入れたtsumikiはプロジェクトの .claude/ には展開されないため、上のようにリポジトリから直接コピーします。スキルを複数ツールで共有する仕組みそのものはAgent Skillsの仕様と移植性の記事が詳しいです。なお、Dev Skillsの dev-run はClaude CodeのTaskCreate・TaskUpdateやサブエージェントを前提に書かれています。変換先のツールにこれらがなければ、自動連続実装はそのままの手順では動きません。

tsumikiが向く案件・向かない案件と、Spec Kit・OpenSpecとの違い

tsumikiは、Claude Codeを主に使うチームが、要件・テスト・検証の手順までAIに任せたいときに向いています。とくに、テストファーストを徹底したい、plan単位で検証レポートを残したい、IPA基準のセキュリティ検査まで一続きで回したい、という案件です。

一方で、次の場合は採用を見送るか、範囲を絞るべきです。

• Claude Code以外が主なツールの場合：rulesyncで変換はできますが、dev-runの自動連続実装はClaude Codeの機能に依存します。
• 1行の修正が中心の場合：dev-planからdev-verifyまでの文書作成が負担になります。dev-implのクイックモードか、tsumikiを使わない修正で足ります。
• 版を固定したい場合：Releasesもタグもないため、固定するならコミットSHAを記録するしかありません。1.5.0のように、版上げでコマンドの置き場所が変わることもあります。

同じ仕様駆動系のツールでは、GitHubのSpec KitやOpenSpecが複数のAIツールに公式対応しています。対してtsumikiは、Claude Codeへの最適化とテストファーストの実装・検証まで含めている点が特徴です。複数ツールを混在させるチームは前者、Claude Codeで実装とテストまで一続きに回したいチームはtsumiki、と選び分けるのが実用的です。仕様駆動開発そのものの考え方は仕様駆動開発（SDD）とはで整理しています。

tsumikiに関するよくある質問

tsumikiのGitHubリポジトリはどこですか？

https://github.com/classmethod/tsumiki です。クラスメソッドのGitHub組織（classmethod）が管理しています。Releasesはないため、版は .claude-plugin/plugin.json で確認します。

tsumikiは無料で使えますか？

tsumiki自体はMITライセンスのOSSで、商用利用も無料です。ただし実行するのはClaude Codeなので、Claude Codeの利用料金は別にかかります。

tsumikiを使うにはClaude Codeが必須ですか？

公式にサポートしているのはClaude Codeです。rulesyncを使えばCursor、Gemini CLI、Codex CLIなどへ変換できますが、サブエージェントを使う自動連続実装（dev-run）は変換先で同じようには動きません。

Kairoのコマンドが見つからないのはなぜですか？

1.5.0（2026年8月3日）で、Kairo・TDD・DIRECTのコマンドが別プラグインの tsumiki-legacy に移ったためです。/plugin install tsumiki-legacy@tsumiki を実行し、/tsumiki-legacy:kairo-requirements のように呼び出します。

AITDDとは何ですか？

AI-assisted Test-Driven Development（AI支援型テスト駆動開発）の略で、クラスメソッドがtsumikiとともに提唱した開発手法です。テスト駆動開発の手順にAIを組み合わせ、要件とテストを先に固めたうえでAIに実装させます。

関連記事

• Claude Codeの使い方｜導入から権限とCLAUDE.md設定まで実務手順
• Claude Codeプラグインの作り方と社内配布｜marketplace.json・管理設定【2026年9月版】
• EARS記法とは？5つの基本型と複合型の書き方・日本語例文・Kiroでの使い方
• Spec Kit（GitHub）とは？仕様駆動開発の使い方・インストール・コマンドを徹底解説
• OpenSpecとは？使い方・インストール・/opsxコマンドをv1.13で解説