Kiro Workflows を使ってみたら体験がすごく良かった話

はじめに

Kiro に最近追加された Kiro Workflows という機能を最近よく使っています。

Workflows は計画→実装→レビュー→PR のような一連のタスクを、複数のエージェントで最初から最後まで、人間の監督を最小限にして走らせる機能です。

これまで Kiro にコードを書かせると、「次はレビューして」「じゃあ指摘に対応して」と、次の指示を毎回こちらが打っていました。また、精度を上げるためにセッションを意図的に分けるなどしていました。

ここらの作業を遅くする原因が Kiro Workflows で解決し、とても便利なので紹介したいと思います！

この記事では前半で Kiro Workflows を紹介し、後半で実際に使ってみて感じたことを書いていきます。

公式の情報は以下が参考になると思います。

この記事で学べること

• Kiro Workflows が何を解決する機能なのか
• ワークフローの仕組み（ステップ・ループ・並列ブランチ・レシピ）の基本
• 最初から付いてくる bundled レシピ
• 実際に使ってみて感じたメリットと考慮点

前提知識・条件

• 検証時点: 2026 年 10 月。Kiro IDE / CLI / Web すべてで Workflows が利用可能な状態です
• Workflows は opt-in 機能です
• 基本的な Kiro のエージェント操作・スキル（skills）・ステアリング（steering）の知識があると読みやすいです

Kiro Workflows とは？

複数のエージェントを使って、計画→実装→レビュー→PR のような一連のタスクを、最初から最後まで人の介入が少なく走らせる機能です。

2026 年 10 月時点で Kiro IDE / CLI / Web すべてで利用可能です。今回は Kiro IDE でのお話です。

何が課題だったか（なぜ生まれたか）

公式ブログで挙げられている、これまでのつらみは以下の通りです。

• エージェントに実装させたあと、「次はコードレビューして」「レビュー指摘に対応して」と毎回人間が次の手を打っていた
• セッションの大半が監督作業。ステップを飛ばしたら再プロンプト、前に決めたことを忘れたら思い出させる
• 1 つのコンテキストウィンドウに、合意事項もツール出力もファイル内容も全部載るので、やることを見失いやすい
• 回避策としてセッションを分割し、計画をファイルに持たせて引き継ぐ運用をしていたが、各セッションが何をしているかを人間が覚えて、結果を手で受け渡す必要があった
• 一度うまくいった手順を「同じやつをもう 1 回」と再利用する仕組みがなかった

仕組み（コアコンセプト）

次に Workflows のコアコンセプトです。

• ワークフローは、エージェントステップ・シーケンス・ループ・並列ブランチからなるグラフです。人間もエージェントも読める宣言的な形式（JSON / YAML）で書きます
• このグラフは自分で書くこともできますが、Kiro がタスクに合わせて自動生成してくれるので、多くの場合は書かずに済みます（詳しくは後述のレシピの節で）
• 各ステップは独立したセッションで、まっさらなコンテキストで動きます。たとえばレビュアーは、実装者の思考を引き継がずに成果物を評価できます（＝レビューの独立性が保てる）
• どのエージェントがどの順で動くかはモデルが定義し、Kiro ランタイムがその計画を実行します。リマインドなしで各ステップが順番どおり走ります
• バックグラウンドで動くので、委譲した作業が進む間もメインの会話で Kiro と作業を続けられます
• 小さな調査を委譲するだけでも、そのツール出力や細かい推論をメインの会話から追い出せる＝メインのコンテキストを温存できます

「各ステップが独立したまっさらなコンテキストで動く」というのが、目立たないながらも後から役立ってくるポイントで、後半の感想でも触れます。

ワークフローの書き方（ステップ・依存・データ受け渡し）

ここで、ワークフローが実際どんな形で書かれているのかを見ておきます。

ステップ同士のつなぎ方も、構えずに書けるようになっています。まず雰囲気をつかむために、最小の例を見てみます。

name: implement-and-review
inputs:
  task: タスクの説明（例: "ユーザー一覧APIにページネーションを追加する"）
steps:
  - type: step
    id: implement
    agent: wf-coder
    prompt: "{{task}} を実装してコミットする"
  - type: repeat
    stopCondition: "{{review.output}} が APPROVED"
    maxIterations: 2
    steps:
      - type: step
        id: review
        agent: semantic_reviewer
        prompt: "{{implement.output}} の差分をレビューし、verdict を返す"

• グラフのエッジを別途管理するのではなく、必要な作業の後ろにステップを置くことで依存を表現します（上の例では implement → review の順）
• 前のステップの出力は {{...}} 変数で参照します（{{task}} は入力、{{implement.output}} は前ステップの出力）
• parallel ノードで独立ステップを同時実行、repeat でストップ条件（上の例ではレビューが APPROVED になるまで）付きのループを回します

なお、ワークフローは自分で書かなくても Kiro が生成してくれるので、実際にはあまり意識することはないです。

レシピ（recipe）

ワークフローの定義そのものを「レシピ」と呼びます。

• レシピ = inputs とノードのツリーを宣言した JSON / YAML ファイル
• Kiro がタスクに合わせてワークフローを自動生成してくれるので、自分でレシピを書かなくても大丈夫です
• 一度決めた手順はレシピとして保存して再利用できます。もちろん自分で書くこともできます
• カスタムエージェント・使用モデル・thinking effort（思考の深さ）レベルを指定できます
• 実行中に、エージェントが発見した内容に応じてワークフロー自身を適応・変更できます（例: planner が実装を独立タスクに分割して複数の coding agent に並列で振る）。
  • 変更はステップ境界で反映され、完了済みの作業や実行中のステップはそのままです

「実行中にワークフロー自身が形を変える」というのは最初ピンと来なかったのですが、要するに走らせてみて初めてわかる分割を、その場で反映できるということみたいです。

bundled レシピ（最初から付いてくる雛形）

公式が「毎日使っている」と挙げている bundled レシピは次の 3 つです。

レシピ	用途
investigate	read-only の調査。コードを変更せず、下調べ・原因調査だけをバックグラウンドで実行
publish-pr	PR を開いてマージまで追う。CI 再試行とレビュー対応つき
feature-pipeline	要件→設計→実装→レビューの一気通貫。重めのパイプライン

investigate は、単一エージェントの read-only 調査をバックグラウンドで走らせて報告してくれるもので、セッションのコンテキスト消費を抑えられます。

publish-pr は、PR を開いてマージまで追ってくれます。失敗した CI を再試行し、安全に解決できるレビュー指摘には自分で対応し、設計変更・スコープ拡大・UX 変更が必要なときは人間に確認してから進めます。

feature-pipeline は、要件収集→設計 & 設計レビュー→実装計画→実装→並列のコードレビュー、までを一気通貫でやる重めのパイプラインです。
design ループと code ループはそれぞれ最大 3 回まで承認を試み、ダメなら止まります。最後に元の要件に照らして検証します。

メッセージング（ステップ ⇔ メイン会話）

これも大きなメリットですが、ワークフローのステップとメイン会話は、メッセージをやり取りできます。

• ワークフローのステップは、メインセッションにメッセージを送って進捗・完了・失敗を報告したり、自分で判断できないことを質問したりします
• 逆方向もできます。メインセッションが、チャットで決めた判断をステップのエージェントに伝えられます
• ステップの質問の答えが既に会話にあれば、メインセッションが代わりに答えてステップを進めます。人間は本当に必要な質問だけ聞かれます
• 各ステップは独立したセッションなので、そのセッションを開いて人間が直接チャットで介入することもできます。

有効化手順（opt-in）

冒頭でも触れましたが、Workflows は opt-in です。設定でオンにしないと使えません。

設定画面で kiroAgent.workflows.enabled を検索すると、このトグルが出てくるので、ここをオンにする必要があります。

有効化したうえで、どのくらい積極的にワークフローを使うかはチャット上部の「Use workflows」から選べます。3 段階あります。

• Only when asked: アクティブなセッションでタスクを処理し、明示的に頼んだときだけワークフローを開始します
• Only for large tasks: マルチステップのタスクや、より多くのコンテキストが要るタスクで、Kiro が自分の判断でワークフロー化します
• As much as possible: コード読み・実装・テスト・レビューなど、大半のタスクをワークフローにルーティングしようとします

使ってみた感想

ここからは、実際しばらく使ってみた感想です。

感想 1: 人間の介入が減って、他の作業と並列で進めやすくなった

一番の体感は、人間の介入が大幅に減って、他の作業と並列化が容易になったことです。
最初にやることを壁打ちしておけば、残りはワークフローに投げておけばモクモクと作業をしてくれます。

やることが決まっていれば投げっぱなしで裏を回せるので、自分はその間に別の設計や調査を進められます。複数作業を並行で実施しやすくなりました。

感想 2: ワークフローを自動で組んでくれて、しかも手直しできる

もう一つ良かったのが、ワークフローを自分で一から設計しなくていいことです。

「こういうことをやりたい」と伝えれば、Kiro がステップ分割・エージェントやモデルの割り当て・依存のつなぎまで考えて組んでくれます。
ワークフローの作法を覚えていなくても気軽に投げられるのが助かりました。

そのうえ、組まれたワークフローはレシピとして手で直せます。さらに「レビューは複数モデルで実施する」といった方針をステアリングに書いておけば、毎回それを守ってワークフローを組んでくれるので、気づいたことを足すほど自分のタスク向けにどんどん育てられます。

感想 3（コツ）: 何でもワークフローにしがち

ワークフローを有効にしておくと、割と小さな作業までワークフローにしがちです。初動が少し重く、クレジットも食う（別セッションでコンテキストを読み直す）ので、軽い作業をいちいちワークフロー化すると割に合いません。

そこで、どこからワークフローに載せ、どこから自前でやるかの線引きをステアリング（.kiro/steering）に書いて対処していました。

さらに、上で書いたとおりこの「どれだけワークフローにするか」は、IDE 1.4.26（2026/10/22）でチャットに追加された「Use workflows」コントロールでも選べるようになりました。ステアリングに細かく書き込まなくても UI でざっくり頻度を切り替えられるので、使いがちを抑える手段が増えて扱いやすくなっています。

今は、規模に応じてこう使い分けています。

• 大規模な作業: ワークフロー
• 中規模な作業: 単体のサブエージェント（agent://wf-coder のように agent を直接指定して起動）
• 小規模な作業: そのままセッションで実施

これで 1 つのセッションで設計からテストまで完結できるようになりました。Kiro はコンテキストが増えるほど挙動が怪しくなるので、規模で切り分けて 1 セッションを太らせないのが効いています。

感想 4: invoke_sub_agent が使えなくなり、run_workflow へ書き換えた

これは Workflows 導入初日にあったことですが、自作のレビュースキルを呼んだら「そのツールはもう使えません」と言われました。

自作のレビュースキルはもともと invoke_sub_agent というツールでサブエージェントを起動し、複数観点（バグ・セキュリティ・型安全性・アーキテクチャ・i18n・整合性……）を並列レビューさせていました。

Workflows 導入後、invoke_sub_agent 経由が使えなくなっていて、スキルの実装を run_workflow（ワークフロー起動）経由に書き換える必要がありました。

まとめ

Kiro Workflows を実際に使ってみて感じたことをまとめます。

• Workflows は、計画→実装→レビュー→PR のような一連のタスクを、複数エージェントで少ない監督のまま走らせる機能。ステップ・ループ・並列ブランチをレシピ（JSON / YAML）で宣言する
• 人間の介入が大きく減り、投げっぱなしで裏を回せるので他の作業と並列で進めやすい。ただし時間とクレジットはかかる
• ワークフローは Kiro が自動で組んでくれて、レシピとして手直しもできる。方針をステアリングに書けば毎回守らせられ、使うほど自分のタスク向けに育つ
• 何でもワークフロー化すると割に合わないので、規模で線引きする（大=ワークフロー／中=単体サブエージェント／小=そのままセッション）。IDE 1.4.26 で追加された「Use workflows」コントロールでも頻度を切り替えられる
• 自作スキルで invoke_sub_agent を使っている場合、クライアントや設定の組み合わせ（CLI V3 の「Workflows: sub-agent tool」が既定オンなら利用可、オフや別クライアントだと run_workflow 一本化）によっては書き換えが必要になることがある。やりたいこと（並列処理）は同じでも実現手段が変わる

作業の並列化がとても楽になり、生産性爆上がりです！
ただ、クレジットの消費も爆上がりなので、KIRO POWERプランが欲しいところです・・・！