NCDC テックブログ
🍊

Claude CodeにKiro CLIを使わせてみた

いばらき
に公開
Claude Code
Kiro
Agent Skills
tech

Kiroといえば仕様駆動開発が有名だと思いますが、この記事ではそのような話はしません。ご了承ください。

では、なんの記事か？

単純にClaude Codeでアプリ開発をするときに実装部分をKiroに任せてみたよ。そのためのSkillを作ったよ。という話になります。(任せたのは設計ではなく実装です。)


Geminiに書かせた扉絵

実装をKiroに実装を任せるために作ったスキルはこちらのリポジトリに置きました。
https://github.com/k-ibaraki/kiro-delegate-skill

なんでKiroにコーディングをさせてみたか？

主な理由は、以下です。

  1. 最近Claude Codeの質が低く感じるので、1つの製品にすべて任せるのは怖いと思った。
  2. 最近Claude Codeのコスパが怪しかったので、他製品との併用を検討したくなった。
  3. 一般的にAIエージェントは「自分に甘い」性質が有るので、複数のエージェントを使ったほうが品質が上がるのでは？と思った。
  4. 社内で「AWSパートナーなのだしもう少しKiroを積極的に使ってみては？」という声があった。

正直なところKiroである技術的な意味はほぼ無くGitHub Copilot CLIでもよいしCodexでもよい、何ならClaude Code内のサブエージェントでもよい、というのが本音ではあります。[1]
ただ、4の理由により社内都合でKiroに課金しやすかったというのはあります。

Kiro CLI v2.0について

さて、作ったスキルはKiro CLI の v2.0以降を前提にしています。v2.0は2026年4月にリリースされました。はい、つい最近です。
実はこのスキルを作り始めたのは、Kiro CLI v2.0 リリースの数日後だったりします。

v2.0の目玉はヘッドレスモードの追加です。--no-interactiveオプションで非インタラクティブに実行できるようになり、--trust-all-toolsでツール権限を事前に付与できるようになりました。
v1系では実行中にツールの許可を対話的に求めてくるため、Claude Codeのサブプロセスとして呼び出す使い方が出来なかったみたいです。
このスキルの核となる--no-interactive --trust-all-toolsの組み合わせはv2.0以降でしか使えないようです。つまりこの記事は、Kiro CLI v2.0の機能をフル活用した最新の取り組みと言えるでしょう。

スキルの仕組み

役割分担

Claude CodeとKiroの役割はとてもシンプルに分けました。

  • Claude Code
    • 設計・タスク整理・検証
  • Kiro CLI
    • 実装（コードの変更・テスト実行）

例えるならClaude Codeがシステムエンジニアで、Kiroがプログラマーといったところでしょうか。

トリガー

毎回勝手にKiroを使って実装されても邪魔になりそうだと思ったので、このスキルは明示的な指示があった場合にのみ動作するようにしました。

kiroに投げて
kiroで実装して
use kiro to fix this bug

一般的なコーディングタスクで自動発動することはないので安心して使えますが、指示を忘れて発動しないこともあるのが悩ましいところでもあります。

実行フロー

スキルは5つのステップで動きます。

0. 事前チェック

タスク実行中にバージョン不足やログイン要求で中断されないよう、開始前にまとめて解決します。

  • kiro-cli --versionでv2.0以上かチェック
  • kiro-cli whoamiでログイン済みかチェック（未ログインならkiro-cli loginを実行）

1. タスクを自己完結した形に整理する

Kiro CLIを外部から使う場合、インタラクティブに質問はできません。曖昧な指示では誤った判断をしたり途中で止まったりするため、Claude Codeがタスク説明を整理します。

整理する内容は以下です。

  • 対象ファイルと場所: src/foo.pyの42行目など、迷わず作業できる粒度
  • 期待する変更の詳細: 変更前後の意図を明示する
  • 完了条件: テスト通過など、Kiroが自己検証できる基準

この過程を踏むことで「Kiroに正確に伝えるために設計をしっかり考える」という副作用が生まれました。これは後述します。

2. kiro-cliを実行する

タスクの内容を一時ファイルに書き出してから、Claude CodeのMonitorツール経由でkiro-cliを起動します。

kiro-cli chat --no-interactive --trust-all-tools < "$KIRO_TASK_FILE" 2>&1

Monitorツールはバックグラウンドでコマンドを実行しながら、条件にマッチした出力だけをClaude Codeに通知する仕組みです。Kiroを通常のBash実行で同期で呼び出すとKiroが完了するまでClaude Codeがロックされ、途中経過も見えません。それに対して、Monitorの利用には以下のメリットがあります。(ちなみにClaude CodeのMonitorツールも2026年4月リリースの新しい機能です。)

  • 途中経過の把握
    • エラーや品質チェック結果が出たタイミングでリアルタイムに通知される
  • 並行作業が可能
    • Kiroが実装している間、Claude Codeは別のタスク（ドキュメント整理や次のタスクの設計など）を並行してこなせる

出力フィルターはエラーや品質チェック結果（FAILED・passed in・✅・❌など）に絞っているので、ルーチンのファイル読み書きログに埋もれることなく重要な情報だけを把握できます。

タイムアウトはタスク規模に応じて設定します。Kiroはコード変更後にテスト・型チェック・lintを実行するため、変更が小さくても完了まで数分かかることが多いです。

規模 目安 timeout_ms
小（1〜2ファイル） 6〜10分 600000
中（3〜5ファイル） 15〜20分 1200000
大（6ファイル以上） 25〜30分 1800000

また、タスク前後の使用量（/usage）を記録してユーザーに報告します。
usageの見える化はユーザーにとって重要な機能だと思っています。

3・4. 出力確認と変更内容の検証

Monitorが status: completed を返したら、品質チェック結果とKiroのサマリーを確認します。

ただし「Kiroのサマリー＝実際に変わったもの」ではないため、git statusとgit diffで実際の差分を必ず確認します。

5. ユーザーへの報告

変更内容・品質チェック結果・使用量をまとめて報告します。コミット・プッシュなどの後続作業はClaude Code自身が行います（Kiroに--trust-all-toolsを渡している関係上、意図せずpushされるリスクを避けるため）。

スキル自体もClaude Codeが作った

このスキルはClaude Codeに作らせました。

  1. Claude Codeに初期スキルを生成させる
  2. そのスキルを使って実際にいくつかの開発タスクをこなさせる
  3. 問題点をClaude Codeに考えさせる
  4. Claude Codeにスキルを修正させる

2〜4を繰り返した結果、現在のSKILL.mdになっています。

つまり「AIがAIに向けた指示書を自己改善していく」という構図です。SKILL.mdに書かれているBefore/Afterの正規表現エスケープへの注意やブランチのベース指定の話なども、実際にKiroがハマったことをClaude Codeが学習して追記した内容です。
ぶっちゃけた話、私はそれらが追加された細かい経緯を把握していません。

使ってみた結果

コスト

Claude Code側のusage消費は減りました。
また、Kiro側のusage消費もかなり少な目です。直接kiroを使ったことのあるメンバーから「少し使っただけで月の使用量の10%以上持っていかれる」といったことも聞いたことがありますが、このスキル経由でKiroを使うと半日使い続けて3%程度でした。
設計はClaude Code、実装だけKiroという役割分担が効いているのだと思われます。

品質

品質はClaude Codeに全て任せたときと比べて悪くなったということはありませんが、良くなったかというと結構怪しいです。それなりの頻度で普通に不具合が発生してしまっています。

ただ Kiroに投げるためにClaude Codeが以前よりもしっかり設計を考えるようになった と思います。曖昧な指示では途中で止まるKiroのために、必然的にClaude Codeが仕様を整理してからタスクを明文化する必要がある為です。

一方で明確なマイナスの作用として、不具合発生時に、Claudeが「kiroが勝手にやったので、私は関係ない」と言い訳をしてまともに対応しようとしないことが何度かありました。
スキルの「4. 変更内容を検証する」ステップを改善し続けることで緩和を試みていますが、完全には防げていません。責任の所在が曖昧になるのは複数エージェント構成の弊害ですね。
結局最後は「人間が確認する」という面白味のないプラクティスから完全に逃げることは難しそうです。

まとめ

Claude CodeにKiro CLIを使わせる構成は、以下のよう場合にはアリだと思います。

  • Claude Codeのusage消費を抑えたい
  • 実装を別エージェントに分散させたい
  • Kiroを使える環境があるけど、仕様駆動開発には馴染めない

スキルは公開しているので、興味があればどうぞ。
https://github.com/k-ibaraki/kiro-delegate-skill

脚注

  1. 本当に何でもいいかというと実はそうでもなく、最初はGeminiも試したのですが、Claudeとの相性が悪いらしく(オブラートに包んだ言い回し)、Claudeが「あいつには任せられん俺が全部見る」と言い出して、時間もコストも品質もむしろ非効率だったので封印しました。 ↩︎

NCDC テックブログ
NCDC テックブログ

NCDC株式会社( ncdc.co.jp/ )のテックブログです。 主にエンジニアチームのメンバーが投稿します。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください！

Discussion