--- title: "tsumiki（ツミキ）とは？クラスメソッドのAI駆動開発フレームワークをClaude Codeで使う方法【1.5.0対応】" url: "https://www.issoh.co.jp/tech/details/10833/" published: 2026-02-03 updated: 2026-09-29 categories: ["Claude"] publisher: "株式会社一創" --- # tsumiki（ツミキ）とは？クラスメソッドのAI駆動開発フレームワークをClaude Codeで使う方法【1.5.0対応】 tsumiki（ツミキ）は、クラスメソッドが2025年7月29日にオープンソースで公開した、Claude Code向けのAI駆動開発フレームワークです。GitHubの[classmethod/tsumiki](https://github.com/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日のプレスリリース](https://prtimes.jp/main/html/rd/p/000000420.000014901.html)は、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です。直下の主なディレクトリは次のとおりです。 | パス | 中身 | | ----------------- | ---------------------------------------------------- | | `skills/` | Dev Skills（dev-\*）、ipa-security-\*、task-breakdown など | | `commands/` | DCS、rev-\*、ユーティリティ（help・orchestrate など） | | `legacy/` | Kairo・TDD・DIRECT（tsumiki-legacy プラグイン） | | `.claude-plugin/` | plugin.json・marketplace.json（版番号） | | `book/` | AITDDの解説文書（8章） | 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日です。 | 版 | 日付 | 主な変更 | | ----------- | ---------------- | ---------------------------- | | 0.0.6 | 2025-10-09 | Claude Codeプラグイン形式へ移行 | | 0.0.7 | 2025-11-28 | DCS分析コマンドを追加 | | 1.1.1 | 2026-02-02 | DCSにedgecase-analysis等を追加 | | 1.2.0 | 2026-02-25 | kairo-loop、auto-debug等のデバッグ系 | | 1.3.0 | 2026-03-29 | Dev Skills（dev-\*）を導入 | | 1.4.0〜1.4.2 | 2026-05-18〜05-27 | ipa-security-check・guide を追加 | | 1.5.0 | 2026-08-03 | Kairo・TDD・DIRECTを legacy へ分離 | 影響が大きいのは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プラグインの作り方と社内配布](/tech/details/17849/)で詳しく扱っています。 ### Kairo・TDD向けのtsumiki-legacy追加手順 Kairo・TDD・DIRECTを使い続ける場合は、同じマーケットプレイスから2つ目のプラグインを入れます。 ``` /plugin install tsumiki-legacy@tsumiki ``` 呼び出しの接頭辞は `tsumiki-legacy:` です（例：`/tsumiki-legacy:kairo-requirements`）。既存のスクリプトや手順書に `/tsumiki:kairo-` と書いてある箇所は、書き換えが必要です。 ### 更新は自動では届かない：版の確認と手動更新 Claude Codeの[公式ドキュメント](https://code.claude.com/docs/en/discover-plugins)によると、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つのモードがあり、実行時に選びます。 | モード | 向く作業 | 出力 | | ----------- | ------------ | ------------------------------------ | | Lightweight | 小さな機能追加・バグ修正 | plan.md、tasks/ | | Full-spec | 新規システム・複雑な要件 | requirements.md ほか2文書、plan.md、tasks/ | Full-specでは、[EARS記法](/tech/details/11489/)の機能要件（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//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](https://github.com/dyoshikawa/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 rulesync@23.0.0 init npx -y rulesync@23.0.0 import --targets claudecode --features commands,skills # Cursor向けに書き出す（.cursor/commands と .cursor/skills が生成される） npx -y rulesync@23.0.0 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の仕様と移植性](/tech/details/17685/)の記事が詳しいです。なお、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](/tech/details/9805/)や[OpenSpec](/tech/details/11351/)が複数のAIツールに公式対応しています。対してtsumikiは、Claude Codeへの最適化とテストファーストの実装・検証まで含めている点が特徴です。複数ツールを混在させるチームは前者、Claude Codeで実装とテストまで一続きに回したいチームはtsumiki、と選び分けるのが実用的です。仕様駆動開発そのものの考え方は[仕様駆動開発（SDD）とは](/tech/details/8740/)で整理しています。 ## tsumikiに関するよくある質問 ### tsumikiのGitHubリポジトリはどこですか？ です。クラスメソッドの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設定まで実務手順](/tech/details/17375/) - [Claude Codeプラグインの作り方と社内配布｜marketplace.json・管理設定【2026年9月版】](/tech/details/17849/) - [EARS記法とは？5つの基本型と複合型の書き方・日本語例文・Kiroでの使い方](/tech/details/11489/) - [Spec Kit（GitHub）とは？仕様駆動開発の使い方・インストール・コマンドを徹底解説](/tech/details/9805/) - [OpenSpecとは？使い方・インストール・/opsxコマンドをv1.13で解説](/tech/details/11351/) --- 出典: [tsumiki（ツミキ）とは？クラスメソッドのAI駆動開発フレームワークをClaude Codeで使う方法【1.5.0対応】]()（株式会社一創）