KiroとClaude Codeの連携｜仕様駆動で実装を爆速にする手順
「Claude Code は速いけれど、曖昧な指示だと手戻りが多い」「Kiro は設計が丁寧だが実装に時間がかかる」――どちらか一方では物足りなさを感じている方は多いはずです。そこで注目されているのが、両者を組み合わせて弱点を打ち消し合う使い方です。この記事では、Kiro で要件・設計・タスクを固め、Claude Code で一気に実装する連携ワークフローを、具体的な手順と渡し方の注意点まで整理します。
Kiro で requirements・design・tasks の仕様書を作り、その tasks.md を Claude Code に渡して実装させると、曖昧な指示による手戻りを抑えつつ高速に開発できるとわかる。設計はKiro、実装はClaude Codeと役割を分けることで、品質と速度を両取りできる。
目次 (11)
KiroとClaude Codeを「組み合わせる」とは
KiroとClaude Codeは、どちらかを選ぶ「比較対象」として語られがちですが、実務では両方を順番に使う組み合わせが効果を発揮します。Kiroは2026年にAWSが公開したエージェント型の開発環境で、Kiro公式サイトが掲げるとおり、いきなりコードを書くのではなく要件・設計・タスクを先に文書化する「仕様駆動（spec-driven）開発」を得意とします。
一方のClaude CodeはAnthropic公式のターミナル向けツールで、コードベース全体を読み込んで複数ファイルを横断しながら編集・テスト・コミットまで自律的にこなす実装力が強みです。つまり「設計の質はKiro、実装の速さはClaude Code」という補完関係が成り立ちます。この役割分担を前提に、Kiroが出力した仕様書をClaude Codeへ橋渡しするのが連携ワークフローの核です。
なぜ連携が効くのか：弱点を打ち消し合う
単体で使うと、それぞれに弱点があります。Claude Codeは「指示→即実装」が速い反面、要件が曖昧なまま走らせると期待と違う実装になり、手戻りが発生しがちです。逆にKiroは要件定義・設計の質が高い一方、実装フェーズに時間がかかる段階だと指摘されています（Zenn・Ubie Dev）。
この2つを組み合わせると、Kiroが作った詳細な設計書がそのままClaude Codeへの「明確な指示」になります。AIに曖昧さの少ない要件を渡せるため、高速かつ期待値どおりの実装が実現します。初期の要件をAIが途中で忘れてしまう問題も、文書化された仕様を参照させることで起きにくくなります。
連携ワークフローの全体像
実際の流れは大きく4ステップです。合同会社iroriの例では、小さめの機能なら合計40分程度の流れとして紹介されています（合同会社irori）。
- Kiroで仕様書（requirements / design / tasks）を作成する。
- プロジェクトルートに
CLAUDE.mdを置き、Claude Codeの役割を定義する。 - tasks.md を Claude Code に渡し、仕様に沿って実装させる。
- 動作確認とフィードバックを行い、必要に応じて追加指示する。
ポイントは「設計フェーズと実装フェーズをツールごとに分ける」ことです。設計の往復はKiroの対話で済ませ、固まった仕様だけをClaude Codeに渡すことで、実装中の迷走を防ぎます。
Step 1：Kiroで仕様書を作る
最初にKiroのチャットで「何を作りたいか」を伝え、対話形式で要件を詰めます。Kiroは .kiro/specs/<機能名>/ 配下に3つのMarkdownファイルを生成します。
- requirements.md：機能要件とユースケースを記述する。
- design.md：アーキテクチャとUX設計を記述する。
- tasks.md：実装すべきタスクを順序立てて並べる。
ここで重要なのは、生成された3ファイルを鵜呑みにせず、要件の抜け漏れや方針のズレをこの段階で直しておくことです。設計の修正コストは実装後より圧倒的に低く、ここで品質を作り込むほど後工程の手戻りが減ります。
Step 2：CLAUDE.mdで橋渡しする
次に、プロジェクトルートに CLAUDE.md を作成します。これはClaude Codeが起動時に自動で読み込む指示ファイルで、「Kiroが生成した仕様書を正確に読み取り、コード・テスト・ドキュメントを出力する」という役割を明文化しておきます。
CLAUDE.mdに「実装前に該当する design.md / requirements.md を必ず参照する」「タスクは tasks.md の順序に従う」といったルールを書いておくと、Claude Codeが仕様から外れにくくなります。プロジェクト固有のコーディング規約やテスト方針もここにまとめておくと、連携の精度が上がります。
Step 3：tasks.mdをClaude Codeに渡して実装
仕様が固まったら、Claude Codeに実装を任せます。渡し方はシンプルで、tasks.md のパスを指定し、「このタスクに従って実装して。必要なら design.md や requirements.md も参照して」と指示するだけです。ターミナルにファイルをドラッグ&ドロップしてパスをコピーする方法もよく使われます（Zenn・Ubie Dev）。
あとはClaude Codeがタスクを順に実装していきます。仕様という「地図」があるため、複数ファイルにまたがる変更でも方針がぶれにくく、レビュー前に仕様との突き合わせがしやすいのも利点です。
Step 4：動作確認とフィードバック
実装が終わったら、テストを実行して動作を確認します。期待と違う挙動があれば、その差分をClaude Codeに伝えて修正させます。ここで仕様そのものに不足が見つかった場合は、Kiro側のrequirements.mdやdesign.mdに戻って更新し、ドキュメントとコードの同期を保つのが望ましい運用です。
この「仕様→実装→確認→仕様へ反映」の循環を回すことで、ドキュメントが陳腐化せず、次の機能追加でも同じワークフローを再利用できます。
連携時のつまずきポイント
組み合わせ運用で実際に報告されている注意点もあります。
- ドット始まりパスの扱い：Kiroの仕様は
.kiroという隠しフォルダ配下に出力されます。Claude Codeの@メンション機能は、当初こうしたドット始まりパスに非対応でしたが、その後改善されています（Zenn・Ubie Dev）。うまく参照できない場合はフルパス指定で渡すと確実です。 - 仕様の粒度：tasks.mdが大雑把すぎると実装がぶれます。1タスク＝1まとまりの変更になるよう、Kiro側で粒度を整えておくと安定します。
- 二重管理の回避：実装中に仕様を変えたら、必ずKiro側のドキュメントへ反映します。コードだけ直して仕様を放置すると、次の連携で古い指示を渡してしまいます。
どんなチーム・規模に向くか
この連携は万能ではなく、向き不向きがあります。要件が固まりにくい探索的なプロトタイピングでは、仕様書作成の手間が重く感じられることもあります。逆に、仕様レビューが必要な中〜大規模開発や、複数人で認識を揃えたいチームでは、Kiroの仕様書が共通言語として機能し、Claude Codeの実装速度を最大限に引き出せます（CayTech Lab）。
「設計の往復が多い」「曖昧な指示でAIが暴走しがち」という課題を抱えるチームほど、Kiroで仕様を固めてからClaude Codeに渡す型がはまります。まずは小さな機能で40分ワークフローを一度試し、自分たちの開発スタイルに合うか確かめるのがおすすめです。
まとめ
KiroとClaude Codeは、比較して片方を選ぶよりも、組み合わせて役割分担させることで真価を発揮します。Kiroで要件・設計・タスクを文書化し、CLAUDE.mdで役割を定義し、tasks.mdをClaude Codeに渡して実装する――この流れにより、曖昧な指示による手戻りを抑えつつ高速な開発が可能になります。設計はKiro、実装はClaude Codeという分担を軸に、自分のチームの規模と開発スタイルに合わせて連携ワークフローを組み立ててみてください。
