Amazon Web Services ブログ

Kiro workflows のご紹介

本日、Kiro workflows を発表します。複数のエージェントを使い、少ない監督で複雑なタスクを最初から最後までやり遂げられる機能です。私たちは Kiro 自体の開発にも workflows を使ってきました。新しいクラウド構成、クラウドセッション、そして workflows 体験の大部分がその成果です。

workflows 以前は、エージェントに変更の実装を頼み、戻ってきてから「この変更をコードレビューして」と伝え、さらに後で「レビューの指摘に対応して」と頼んでいました。セッションの大半を監督に費やし、ステップを飛ばせば再度プロンプトを送り、以前の決定事項をエージェントに思い出させていました。セッション内では順序の制御はモデルが担いますが、モデルの注意力には限りがあります。合意した内容はすべて、ツール出力やファイル内容で埋まっていく同じコンテキストウィンドウに置かれているため、まだ残っている作業をエージェントが忘れたときにも私たちが介入していました。この問題を回避するために、作業を別々のセッションに分け、セッションをまたいで残るファイルに計画を書いていましたが、それでも各セッションが何をしているかを覚えておき、セッション間で結果を受け渡す必要がありました。こうした手動のワークフローは良い結果を生むこともありますが、準備に時間がかかります。うまくいくプロセスができたら、手で組み直すことなく、その実行を指して「もう一度やって」と言いたいものです。

Kiro workflows はこれを解決します。workflows では、どのエージェントがどの順序で作業するかをモデルが定義し、Kiro ランタイムがその計画を実行するので、各ステップがリマインドなしで予定どおりに実行されます。workflows は、エージェントステップ、シーケンス、ループ、並列ブランチで構成されるグラフで、人間とエージェントの両方が読み書きできる形式で表現されます。各ステップは新しいコンテキストを持つ独立したセッションで実行されるため、たとえばレビュアーはコーダーの推論を引き継がずに作業を評価できます。Kiro は目の前のタスクに合わせて workflow を生成します。生成された workflow はレシピとして保存して再利用でき、自分で書くこともできます。

workflows はバックグラウンドで実行されるため、委任した作業が進む間もメインの会話で Kiro との作業を続けられます。workflow の各ステップのセッションは実行中も参照でき、一時停止、再開、方向修正ができます。実行後もフォローアップの質問のために戻れます。小さな調査を委任するだけでも、そのツール出力や詳細な推論がメインの会話に入らないため、作業を続けるためのコンテキストを温存できます。

workflows で Kiro を開発する

左側にワークフロー実行と保存済みレシピを一覧表示する Workflows パネル、中央に pr ステップのワークフローステップセッション、右側に各ステップのエージェント・モデル・effort・所要時間を含む subscription-tier-discounts のステップツリーを表示するメインの会話がある Kiro IDE
Kiro IDE
実行中の release-readiness-audit ワークフローを表示する Kiro CLI のターミナル画面。sequence、parallel、repeat ノードからなるステップツリーに、各ステップのエージェント、モデル、effort、ステータスが並び、下部にキーボードショートカットが表示されている
Kiro CLI
左側のメインの会話で完了した認証とセッションのリファクタリングワークフローを要約し、右側の Workflows タブに auth-session-refactor のステップツリーと validate ステップの結果を表示する Kiro Web
Kiro Web

ランタイムが動くようになってすぐ、私たちは workflows を使って、workflow ランタイム自体の大部分と Kiro Web との統合全体を開発しました。フロントエンド、API と社内サービス、Kiro のエージェントハーネスにまたがるフルスタックの作業で、それぞれの部分を別々の workflow が並列に担当しました。

実装を担う workflow は、変更を分離するためにそれぞれ別の Git worktree を使いました。エージェントがコンポーネント間の問題を見つけると、メインセッションが影響を受ける workflow のエージェントにそれを伝え、軌道修正できるようにしました。私たちのステアリングファイルでは、agent-browser CLI を使った自動テストで Web UI を操作し、検証用のスクリーンショットを撮ることを必須にしています。

エージェントは変更をプッシュし、私たちが好む記述スタイルでプルリクエストを作成しました。その後、レビューの指摘にループで対応しながら PR を更新しました。関連する変更がマージされるとブランチをリベースしてマージコンフリクトを解消し、設計に影響する変更、スコープを広げる変更、ユーザー体験を変える変更については私たちに確認しました。

私たちのエージェントは、Kiro の 1 セッションで数十個の workflow を管理することがよくあります。典型的な workflow はカスタムエージェントを使った 5〜10 ステップで構成され、マルチモデルのコードレビューと、ループでの自動修正が含まれます。数週間続くセッションもあり、機能や改善を重ねるにつれて、私たちの決定事項に関するコンテキストが蓄積されていきます。チーム全体では、workflows はほぼ 24 時間 365 日稼働しています。

workflows は私たちの働き方を変えました。各セッション内で並列に実行される作業が増え、エージェントがバックグラウンドで調査を進め、複数の PR にわたって機能を構築します。タスクはより非同期になり、10 分ごとに私たちがプロンプトを送って先へ進めなくても、エージェントが長時間作業を続けます。Kiro は私たちの判断が必要な依頼だけを持ってくるので、私たちは設計上の判断や次に何を作るかにより多くの時間を使えるようになりました。

workflow の中身

次に示すのは、変更を計画し、実装と並列レビューを承認されるまで繰り返し、最後にドラフトのプルリクエストを作成する workflow の短い例です。これはグラフとして表現できます。

ワークフローのグラフ。最初に plan で planner が実装計画を書く。次に code-loop という repeat ループ(最大 3 回、verdict.json が APPROVED になるまで)の中で、implement(coder が計画を実装し、指摘を修正してコミット)から独立したレビュアー review-a と review-b に並列に分岐し、aggregate(両方のレビューをまとめて verdict.json を書く)で合流する。aggregate から implement へ戻る破線が次の反復を表す。ループの後、draft-pr がドラフトのプルリクエストを作成する。

同じ workflow を次のレシピで記述できます。

{
"name": "deliver-change",
"inputs": { "task": "prompt", "workdir": "string" },
"steps": [
  {
    "type": "step",
    "id": "plan",
    "agent": "wf-planner",
    "prompt": "Read the code relevant to {{task}} in {{workdir}} and write an ordered implementation plan to {{workdir}}/plan.md.",
    "artifacts": { "plan": "{{workdir}}/plan.md" }
  },
  {
    "type": "repeat",
    "id": "code-loop",
    "maxIterations": 3,
    "onMaxIterations": "abort",
    "stopCondition": {
      "fileCheck": { "path": "{{workdir}}/review/verdict.json", "jsonPath": "verdict", "value": "APPROVED" }
    },
    "steps": [
      {
        "type": "step",
        "id": "implement",
        "agent": "wf-coder",
        "prompt": "Implement {{task}} in {{workdir}} following {{artifacts.plan}}. If {{workdir}}/review/verdict.json says CHANGES_REQUESTED, fix every finding in it first. Run the tests and commit."
      },
      {
        "type": "parallel",
        "id": "reviews",
        "joinPolicy": "all",
        "branches": [
          {
            "type": "step",
            "id": "review-a",
            "agent": "semantic_reviewer",
            "prompt": "Review the change in {{workdir}}. Write your review to {{workdir}}/review/a.md. Do not read the other reviewer's file.",
            "artifacts": { "review_a": "{{workdir}}/review/a.md" }
          },
          {
            "type": "step",
            "id": "review-b",
            "agent": "semantic_reviewer",
            "prompt": "Review the change in {{workdir}}. Write your review to {{workdir}}/review/b.md. Do not read the other reviewer's file.",
            "artifacts": { "review_b": "{{workdir}}/review/b.md" }
          }
        ]
      },
      {
        "type": "step",
        "id": "aggregate",
        "agent": "wf-review-aggregator",
        "prompt": "Read {{artifacts.review_a}} and {{artifacts.review_b}}. Dedupe the findings, then write the verdict to {{workdir}}/review/verdict.json as {\"verdict\": \"APPROVED\" | \"CHANGES_REQUESTED\"}."
      }
    ]
  },
  {
    "type": "step",
    "id": "draft-pr",
    "agent": "wf-pr-submitter",
    "prompt": "Open a draft pull request for the change in {{workdir}}. Base the description on {{artifacts.plan}}."
  }
]
}

各step は独立したエージェントセッションとして実行されます。依存関係は、必要とする作業の後にステップを置き、その出力を {{...}} 変数で参照することで定義します。グラフのエッジを別途管理する必要はありません。parallel ノードは独立したステップを同時に実行し、repeat はレビューの承認などの停止条件を満たすまでステップをループします。workflow を作る最も簡単な方法は、Kiro に頼むことです。

Kiro はレシピを JSON で生成しますが、YAML にも対応しています。

モデル駆動の workflows

セッションで説明したタスクは Kiro が分解するので、レシピを書く必要はありません。カスタムエージェント、使いたいモデル、思考の effort レベルなど、作業の組み立て方を指定することもできます。

Kiro は、エージェントが見つけた内容に応じて実行中の workflow を調整できます。たとえば、プランナーが実装を独立したタスクに分割し、並列で動くコーディングエージェントにそれぞれを委任できます。変更はステップの合間に反映されるため、完了した作業はそのまま残り、実行中のステップも変わりません。

同梱の workflow の例

より複雑な例として、同梱の feature-pipeline レシピは、要件の収集、ソリューションの設計とレビュー、実装計画の作成、コードの記述をエージェントに分担させます。その後、独立したコードレビュアーが並列に実行されます。

次のツリーでは、設計ループとコードループがそれぞれ承認を得るまで最大 3 回試行し、それでも承認されなければ実行を停止します。最後の検証では、結果を元の要件と照らし合わせます。

この例は Claude Opus 5 を High effort で使うセッションから起動しています。設計とレビューのエージェントは Extra high を使うようにカスタマイズしています。以下ではモデルと effort の上書き設定のみを示し、省略した設定はセッションのデフォルトを使います。

repeat の下にネストされた行はそのループ本体を構成し、parallel の下にネストされた行は同時に実行されます。トップレベルの行は順番に実行されます。

私たちは Kiro の開発で数千回の workflow を実行してきました。Kiro には組み込みのレシピが同梱されており、その中でも investigate と publish-pr は私たち自身が毎日使っているものです。investigate は単一エージェントによる読み取り専用の調査をバックグラウンドで実行して結果を報告するので、セッションのコンテキスト使用量を抑えられます。publish-pr レシピはプルリクエストを作成し、マージまで追跡します。失敗した CI チェックを再試行し、安全に解決できるレビューのフィードバックには対応します。設計を変える、PR のスコープを広げる、ユーザー体験を変えるといった場合は、事前に確認を求めます。これらのレシピは出発点です。そのまま実行することも、タスクを説明して Kiro に workflow を組み立てさせることも、自分で書くこともできます。

セッション間のメッセージング

workflow のステップは、進捗の報告、完了や失敗の通知、自分では判断できない決定の依頼のために、メインセッションへメッセージを送ります。こうしたメッセージは Kiro とすでに進めている会話に届くので、各ステップのセッションを開いて確認しなくても、1 か所で作業を追えます。

メッセージングは逆方向にも機能します。メインセッションは、チャットで下した決定をステップを実行中のエージェントにメッセージで伝えられます。ステップの質問への答えがすでに会話の中にある場合は、メインセッションがあなたの代わりに返信するので、ステップは作業を続け、あなたは本当に自分の判断が必要な質問だけを受け取ります。これにより、メインの会話から作業を進めながら、workflows をより自律的に実行できます。

はじめ方

workflows は Kiro IDE、CLI、Web で利用可能になりました。3 つすべての下で1 つのランタイムが動いているので、どこから起動してもレシピは同じように動作します。

workflows はオプトインで提供を開始しているため、まず設定で有効にする必要があります。

IDE

  1. プロジェクトの Workspace Configuration を開きます。
  2. Workflows を選択します。
  3. Workflows を有効にします。
  4. 新しいチャットセッションを開始します。すでに開いているセッションに変更を反映するには、Kiro を再起動してください。

対応する設定は kiroAgent.workflows.enabled です。Workflows が表示されない場合は、まだお使いのアカウントでは利用できません。

CLI

  1. /settings を実行します。
  2. Features を選択します。
  3. Workflows を有効にします。
  4. Kiro CLI を再起動すると、workflow のコマンドが使えるようになります。

この設定は chat.enableWorkflows として保存されます。Workflows が表示されない場合は、まだお使いのアカウントでは利用できません。

Web

  1. Kiro Web で Settings を開きます。
  2. Workflows を選択します。
  3. Enable workflows をオンにします。オフにすると Workflow 関連の画面が非表示になり、新しい起動ができなくなります。
  4. 任意: Upload workflow を選択して、レシピを 1 つアップロードします。.kiro/workflows/ フォルダ全体をインポートするには、Configuration Sync を使います。

Web では .workflow.json、.workflow.yaml、.workflow.yml のレシピファイルを受け付けます。

よく使うレシピを Kiro Web のクラウド構成に保存しておけば、プロジェクトやデバイスをまたいで再利用できます。workflows は Kiro CLI と IDE からのクラウドセッションでも実行できます。クラウドセッションで workflows を有効にし、保存した workflow を管理するには、workflows の設定ページを使います。

workflows には、他のエージェント作業と同じ Kiro のクレジットモデルが適用されます。クレジットの使用量は実行するエージェント作業によって決まるため、複雑な workflow ほど多くのクレジットを使う場合があります。特に指示がなければ、Kiro はタスクに必要と判断した内容に基づいて workflow を作成します。プロンプトやステアリングファイルで、Kiro が作業をどう分割し、どの程度レビューを行うかを指示できます。

詳しくは Workflows のドキュメントをご覧ください。

workflows で作ったものをぜひ教えてください。

本記事は 2026 年 9 月 30 日に公開された Introducing Kiro workflows を翻訳したものです。