10月1日、Kiroが「Introducing Kiro workflows」と題した記事を公開した。AIコーディングIDE「Kiro」に搭載されたマルチエージェントワークフロー機能の概要と設計思想、具体的なレシピ構成が詳しく紹介されている。
「毎回プロンプトを打ち直す」問題を解消するワークフロー
AIコーディングアシスタントを使い続けているエンジニアなら、一度はこの状況に陥ったことがあるはずだ。エージェントに実装を依頼し、完了したらコードレビューを依頼し、さらに「レビューで指摘された箇所を修正して」と追加で依頼する。エージェントがステップを飛ばせば再度リマインドし、コンテキストウィンドウがツール出力やファイル内容で埋まってくれば、以前の決定事項を忘れ始める。
Kiroチームはこの問題を「エージェントの注意は有限だ」と端的に表現している。セッションをまたいで作業を分割し、計画をファイルに書き出して永続化するという回避策もあるが、その段取り自体が手間だ。
Kiro workflowsはこの手間を自動化する。 モデルがどのエージェントをどの順番で動かすかを定義し、Kiroランタイムがその計画を実行する。人間が10分ごとにプロンプトを打って「次に進め」と促さなくても、各ステップが時間通りに実行される。
なお、後述するように一部のレシピは設計変更やUXへの影響が生じた場合に人間への確認を求める設計になっており、「完全無人化」ではなく「必要な判断は人間が行う」という思想で設計されている点は押さえておきたい。
なぜ今このアプローチが注目されるのか
GitHub CopilotやCursor、Windsurf（旧Codeium）など、AIコーディングIDEの競合は多い。多くはチャット補完・インライン提案・単一エージェントによるファイル編集を中心に据えている。これに対してKiroがマルチエージェントのグラフ実行基盤をIDEに統合した点は、製品的な差別化軸として明確だ。単一モデルへの逐次依頼ではなく、複数エージェントが役割分担して並列・ループ実行するアーキテクチャを「レシピ」として記述・再利用できることが、今回の発表の核心にある。
AIエージェントのオーケストレーション自体はLangGraphやAutoGenといったフレームワークで以前から取り組まれてきたテーマだが、それをIDEのUIと開発フローに直接統合し、実際の自社開発で日常的に活用しているという実績を示した点がKiroの主張の強みだ。
アーキテクチャ：グラフ構造で表現されるワークフロー
ワークフローはグラフ構造で表現される。構成要素はエージェントステップ、シーケンス、ループ、並列ブランチだ。重要なのは、各ステップが独立したセッションで実行される点だ。たとえばコードレビューを担当するエージェントは、実装エージェントの推論経緯を引き継がない新鮮なコンテキストで評価を行う。実装者の「思い込み」がレビュアーに伝染しない設計だ。
ワークフローはYAMLまたはJSONで記述する「レシピ」として保存・再利用できる。以下は「変更の計画→実装と並列レビューのループ→ドラフトPRを開く」という一連の流れを表すレシピの概念的な構造例だ（元記事掲載のコード例を基に構造を示す）。
name: feature-pipeline
steps:
- id: plan
agent: wf-coder
thinking: low
- id: design
parallel:
- id: design-draft
agent: wf-design
thinking: extra-high
- id: design-review
agent: wf-design-reviewer
thinking: extra-high
repeat:
until: approved
max: 3
- id: implement
agent: wf-coder
input: "{{design.output}}"
- id: review
parallel:
- id: review-claude
model: claude-opus # 元記事記載のモデル名表記に準拠
thinking: extra-high
- id: review-gpt
model: gpt-sol # 元記事記載のモデル名表記に準拠
thinking: extra-high
repeat:
until: approved
max: 3
- id: open-pr
agent: wf-coder
各stepは独立したエージェントセッションとして動作する。{{...}}変数で前のステップの出力を参照し、parallelノードで独立したステップを並列実行、repeatノードでレビュー承認のような停止条件付きループを定義できる。グラフエッジを別途管理する必要はなく、ステップの記述順序が依存関係を表す。
Kiro固有の概念：エージェント識別子について
上記のコード例に登場するwf-coderやwf-design、wf-design-reviewerはKiro固有のエージェント識別子だ。汎用的なモデル名ではなく、Kiroランタイムが管理するロールベースのエージェント定義を指している。各識別子がどのモデルや設定にマッピングされるかはKiroの設定によって決まる。
レシピ内でモデルを直接指定するケース（コードレビューステップでの複数モデル並列実行）もあり、元記事ではその具体的なモデル名が記載されている。ただし、元記事に登場するモデル名は2026年10月時点での表記であり、実際の最新の対応モデルについてはKiroの公式ドキュメントで確認することを推奨する。
「feature-pipeline」レシピ：フルスタック開発の自動化
Kiroには組み込みレシピが付属している。その中でもfeature-pipelineは、要件収集→ソリューション設計・レビュー→実装計画→コーディング→並列コードレビューという一連のフルスタック開発フローをエージェントが自律実行する。
このレシピの構成を見ると、Kiroチームのこだわりが見えてくる。デザインループとコードループにはそれぞれ最大3回の反復制限と「承認されなければ実行を中断」という中止条件が設けられている。コードレビューは2モデルを並列で走らせ、それぞれの指摘を集約するアグリゲーターエージェントが処理する。
ステップごとのモデルと推論努力レベルの設定例は以下の通りだ：
setup：wf-coder、Thinking effort: Lowrequirements：wf-design、Thinking effort: Extra highdesign-draft/design-review：wf-design/wf-design-reviewer、Thinking effort: Extra high- コードレビュー（Claude系モデル）：Thinking effort: Extra high
- コードレビュー（GPT系モデル）：Thinking effort: Extra high
validate：wf-coder（セッションデフォルト）
ステップごとにモデルと推論努力を使い分けることで、コストと精度のバランスを取れる。
実際にKiro自身の開発に使われた
Kiroチームはワークフロー機能自体の開発に、このワークフローを活用した。フロントエンド、API・内部サービス、エージェントハーネスにまたがるフルスタック作業を、それぞれ独立したワークフローが並列処理した。実装には独立したGit worktreeを使って変更を隔離し、エージェントはPRを開いてレビュー指摘をループで処理し、関連する変更が入ればブランチをrebaseしてマージコンフリクトを解決した。
チーム全体で、ワークフローはほぼ24時間365日稼働しているという。1セッションで数十のワークフローを管理することもあり、典型的なワークフローは5〜10ステップで構成されるカスタムエージェントを使う。
日常的に使える2つの組み込みレシピ
Kiroチームが自分たちで毎日使っていると明言するレシピが2つある。
- **
investigate**：単一エージェントによる読み取り専用の調査をバックグラウンドで実行し、結果を報告する。メインセッションのコンテキスト消費を抑えるために使う。 publish-pr：PRを開き、マージまでフォローする。CIの失敗があればリトライし、安全に解決できるレビュー指摘には対処する。設計変更・PRスコープの拡大・UXへの影響がある場合は人間に確認を求める設計になっており、判断が必要な局面では人間の関与を前提としている。
利用方法と注意点
現在、ワークフローはオプトイン方式で提供されており、設定で有効化する必要がある。
- プロジェクトのWorkspace Configurationを開く
- Workflowsを選択
- Workflowsを有効化
- 新しいチャットセッションを開始する（既存セッションに適用するにはKiroの再起動が必要）
バッキング設定はkiroAgent.workflows.enabledだ。設定項目が表示されない場合は、まだアカウントへの展開が済んでいない。レシピはクラウド設定に保存することで、プロジェクトやデバイスをまたいで再利用できる。また、クラウドセッションでのワークフロー実行も対応している。
クレジット消費はエージェントが実行する作業量に依存し、複雑なワークフローほど多くのクレジットを消費する点は把握しておきたい。
詳細はIntroducing Kiro workflowsを参照していただきたい。
