ボタンの「送信」を「検索」に変える仕事と、検索フォームに失敗表示・再試行・テストを足す仕事。同じリポジトリでも、エージェントへの渡し方は分けたい。
以下は、この2件を題材にした比較手順です。Kiroを実機で比較した結果ではありません。時間やトークンの実測値もありません。
有効化と、仕事の振り分けを分ける
Kiro CLI 2.33.1では、V3 Workflowsを有効にしただけではWorkflowが始まらず、依頼したときに起動する動作へ変わりました。11月3日のCLI更新では、対応ホストの対話セッションでV3が既定になり、Workflowsの開始前に計画を表示することも案内されています。有効化は/settings → Featuresから行います。
既存V2ユーザーには切り替え前の確認があり、headlessや既存ACPクライアントには別の移行条件があります。「どの環境でも同じ」とは扱わず、まず利用中のCLIバージョンと実行形態を確認します。
Workflowsでは、各stepが新しいコンテキストを持つ別セッションで動きます。後続stepへ前段の結果を渡すには、出力や成果物を明示的に引き継ぎます。実装担当の思考をそのまま引き継がず、別の観点でレビューさせたい仕事には使いどころがある。
ただし、複数エージェントやレビューの反復は単一セッションよりトークンを使います。すべての変更を同じ工程に載せる必要はありません。
行数より、分ける理由で選ぶ
最初の振り分け案は、これくらいで十分です。
| 依頼例 | 第一候補 | 判断の理由 |
|---|---|---|
| A：既存ボタンの文言を1か所変更 | 通常チャット | 変更範囲も確認点も狭い |
| エラーの原因を読取だけで調査 | 背景Workflowも候補 | 小さくても、詳細な調査出力を主会話から分離したい場合がある |
| B：検索フォームに失敗表示・再試行・テストを追加 | Workflowを検討 | 調査から実装への引き継ぎと、別コンテキストでのレビューが欲しい |
小さな調査でも、長いログを主会話へ持ち込まずに済むなら委譲したい。一方、Bが既存実装の小さな変更で済むなら、チャットで進めてもよいはずです。レビューを分けて何を確かめたいのか決まっていないなら、私はチャットから始めます。
変更を頼む前に、計画だけを確認する
Bなら、最初の依頼をここで区切ります。
検索フォームの失敗表示・再試行・テスト追加について、計画だけを作って。
ファイル編集やコマンド実行はまだしないで。
変更候補と、各工程から次へ渡す成果物を示して。
レビュー観点と、失敗時に止まる条件も挙げて。
このフォームなら、失敗を画面上で伝えられるか、再試行で同じ検索条件を使うかを計画に入れます。既存の成功ケースを壊さないことも受入条件にしておく。実際のアプリに違う要件があるなら、そちらに合わせます。
人が計画を確認したあと、調査→設計→実装→独立レビュー→既存テストでの検証を依頼します。レビュー担当に渡すのは変更差分と受入条件。実装担当の「これで正しいはず」という説明だけでは、判定材料が足りません。
この依頼文や計画表示は、ファイル書込みやコマンド実行を強制的に遮断する仕組みではありません。権限設定は別に確認し、最初の比較では本番APIや機密情報を使わない。セッションを分けることも、OSの隔離とは別です。
比較は同じ開始点から、未実施欄を埋める
Aは通常チャット、BはWorkflowで一度ずつ進めれば、操作の違いを確かめる入口になります。ただ、それだけで「Workflowの方が速い」とは判断できません。作業自体が違うからです。
方式を比べるなら、A・Bそれぞれを両方式で試します。同じ基準commitから別branchやworktreeを用意し、利用形態・CLIバージョン・モデル・権限を記録する。テストはpackage.jsonなどで実在するscriptを確認し、リポジトリに合ったコマンドを使います。worktreeを分けても、権限を隔離したことにはなりません。
次は記入用の表です。まだ実行していないので、結果は入れていません。
| 記録する項目 | 現時点 |
|---|---|
| 依頼／起動方法 | A・Bそれぞれで通常チャットとWorkflowを比較予定。未実施 |
| 計画の過不足／人の確認回数 | 未実施 |
| 修正回数 | 未実施 |
| 実行したテストコマンドと終了コード | 未実施 |
| 表示された使用量 | 未取得 |
| 未確認の挙動 | アプリの受入条件を含め、すべて未確認 |
結果を見返すときは、人が何回修正を求め、レビューでどの不具合を拾えたかを比べます。使用量や所要時間が取れなければ、未取得のまま残す。parallelを使っても、実行時間が短くなったかは計測しないと分かりません。
止める条件も、実行前に決める
必須テストの失敗、レビュー指摘の未解決、事前に決めた修正回数の上限。このどれかに当たれば、未完了として人へ返す運用にします。
Workflowのstepが終わっていても、フォームが受入条件を満たしたかは別に確認します。Bで試すなら、再試行の仕様について実装担当が見落とした点をレビューで拾えたかまで残したい。工程を分けても確認の質が変わらなければ、次はチャットへ戻してよいと思います。