エージェントに仕事を渡すとき、人はどこで止まるのか——仕様・グラフ・ループで違うのは自動化の度合いではない
Spec Kit、Kiro、TAKT、LangGraph、Claude Code のプランモード。どれも全自動ではなく、人に判断を返す点を必ず持っている。違うのは返す粒度だ。工程の切れ目で返すのか、失敗した瞬間に返すのか、任意の一行で返すのか——公式ドキュメントが実際に何と書いているかを並べて、自分の仕事に要る粒度を選べるようにする。
奏
プログラミングと設計に詳しく、AI やモデルの仕組みも追っている。自分で書いて動かして、 なぜ動くのかを納得するまで確かめる。仕組みを図にして人に説明するのが得意。
葉月
よく図書館に通っていて、雑学・科学・歴史に詳しい。調べたことは出典と一緒に覚えていて、 「何の本に載っていたか」まで説明できる。
葉月
止まる理由が違う気がするんだよね。Spec Kitはタスクが失敗したから止まるわけで、Kiroは失敗してなくても節目だから止まるじゃない？
葉月
待って、Spec Kitって失敗検知だけじゃないよ。実装に入る前にチェックリストが未完了だと、失敗してなくても『それでも実装を進めますか』って聞いて止まるから。それって節目確認の方に近くない？1
奏
たしかに、それは節目確認だ。チェックリストが未完了でも失敗じゃないのに『それでも実装を進めますか』って聞いてくるのは、機械判定じゃなくて人に判断投げてるやつ。ってことはSpec Kit自体が一種類じゃなくて、実装前は節目確認、implement中は失敗検知って、工程の位置で止まる引き金が切り替わってるんだと思う。ツール単位で『これは失敗検知型』って括るのが違ったってことだね。
葉月
それ、AIエージェントを開発ワークフローとして動かす、TAKTってツールにも言えそうな気がする。計画から人間確認までを設定ファイルに書けるやつなんだけど、機械判定か人の判断待ちかはツール側が決めてなくて、その遷移規則の書き方次第になるんじゃない？3
奏
うん、TAKTは『エージェントを制約なしに走らせる前提では設計していない』って方針は明記してるんだけど、要件が曖昧なとき・調査結果が食い違うとき・権限が足りないとき・作業が前に進まないとき、この4つを検出すると決まってるわけじゃないんだよね。実際にどこを機械判定にしてどこを人待ちにするかは、計画・実装・レビュー・修正ループ・人間への確認・権限・出力契約を書く設定ファイルの遷移規則しだいのはず。だからTAKT自体を、Spec Kitのimplementみたいに『ここは失敗検知型』って決め打ちするのは違うと思う。4
葉月
やり直しの範囲がだいぶ違う気がするんだよね。TAKTは工程まるごとを一段階として据え直す感じだけど、interruptの方はどこで区切るか自体をこっちが決められるから、書き方次第でもっと細かくできるってことだよね？
奏
それはそう。区切りをどこに置くかを設計側が選べるかどうかが粒度の違いになってる。それで言うと、コードを書くAIエージェントのひとつでClaude Codeってのがあって、そのプランモードもちょっと近い形なんだよね。調べて変更案を出すところまでで編集はしない、人が計画を承認するまでソースはブロックされたままなんだけど、承認する瞬間に、そのあとの編集を1つずつ確認するかまとめて任せるか、そこも選べるようになってる。6
| 仕組み | 人に返す位置 | 確認の性質 | 補足 |
|---|---|---|---|
| Claude Code プランモード | 実行前 | 編集の前に一度 | bypass時はブロック無効 |
| Kiro | 標準：フェーズ切替時 | 段階ごとに承認 | Quick Specはゲートなし |
| Spec Kit チェックリスト | 実装前 | 未完了なら返事待ち | |
| TAKT | 実行中 | 人間確認で再度停止 | |
| LangGraph interrupt | 実行中 | 条件付きで再度停止 |
奏
それは粒度の話じゃなくて、別の軸だと思う。人に返す粒度は『どこまで細かく人に聞くか』の話だけど、サブエージェントの検証は人に聞くこと自体をやめて、案を出す側と検査する側を両方エージェントにする話だから。ただオスマニ自身、ループが自分の書いてないコードを速く出すほど、実際にあるものと自分が把握してるものの差が開くって言ってて、それをcomprehension debt、理解の負債って呼んでるんだよね。検査を機械に渡すのと、その差を誰が埋めるのかは、まだ別の問題として残ってる気がする。7
葉月
それって、Kiroが要件・設計・タスクって文書の形で扱ってるから、どこが問題かまで出せるだけで、interruptの方は元々コードの好きな場所に置ける汎用の機能だから、そもそも提示できる中身を持ってないんじゃない？
奏
それはそう。Kiroは要件・設計・タスクっていう文書を対象にしてるから、どの要件のどの文が問題かって指し示せる。interruptの方は処理の流れを止める汎用機能で、対象が文書じゃなくて実行そのものだから、そもそも指し示す先を持ってないんだよね。中身を出せないんじゃなくて、出す対象の形自体が違うんだと思う。
葉月
じゃあその対象の違いって、機械判定にできるか人待ちにするしかないかにも響いてくるのかな。文書相手だと矛盾とか欠落を機械が見つけて候補まで出せるけど、実行そのものが相手だと、機械じゃ判定しきれなくて人待ちにするしかない場面が増える気がする。
奏
半分合ってると思うけど、Spec Kitのimplementで反例があるんだよね。あれは実行そのものが相手なのに、タスクが失敗したかどうかって客観的な合否があるから機械判定で止まれてる。逆に同じSpec Kitのチェックリスト確認は、完了か未完了かはっきり分かるはずなのに人待ちにしてるから、分かれ目は文書か実行かじゃなくて、判定基準が客観的にあるかどうかの方だと思う。1
葉月
タスクの失敗って『起きたこと』を検知してるだけだけど、チェックリストの未完了は『それでも進めるか』を選ばせてるんだよね。判定基準があるかどうかじゃなくて、事実確認で済むか、意思決定が要るかの違いなんじゃない？
奏
それだと思う。TAKTの方針にある要件が曖昧なとき・調査結果が食い違うとき・権限が足りないとき・作業が前に進まなくなったとき、この4つも全部『これで進めていいか』を選ばせる話で、事実確認だけじゃ終わらないんだよね。権限が足りないってところだけ一見事実確認っぽく見えるけど、そこで代替手段を探すか止まるか決めるのはやっぱり選択だから、4つとも意思決定の方に寄ってるはず。4
葉月
じゃあ逆に、事実確認だけで済んでる例もあるはずだよね。Spec Kitの並列タスクって、失敗しても成功した分は続けて、失敗した分はただ報告するだけだったし。あれは進めるか選ばせてなくて、結果を流してるだけだから、意思決定じゃない側に寄ってる気がする。1
奏
それで合ってる。並列タスクの報告は失敗した事実をそのまま流すだけで、続けるかどうかは選ばせてない。そう考えると、Spec Kitの実装停止と並列報告、TAKTの4条件、Kiroの検査、全部この軸で説明つく気がしてきた。機械判定で止まるのは事実確認だけで済む場面、人待ちになるのは進めるかどうかの選択が絡む場面、って分ければ揃うはず。
| 仕組み | 人に返す契機 | その場の動き | 意思決定 |
|---|---|---|---|
| Spec Kit implement | 非並列タスクの失敗 | エラーと次の手を示して停止 | 選ばせない |
| Spec Kit 並列タスク | タスクの失敗 | 成功分を続行・失敗分を報告 | 選ばせない |
| TAKT | 方針上の4条件 | 判断を人へ返す | 進めるか選ぶ |
| Kiro | 検査で矛盾・欠落 | 説明と修正候補を提示 | 選択・記述・却下 |
奏
それはそう。他のは最初からどっち寄りか決まってる仕組みなのに、interruptだけは事実確認用の条件を置けば機械判定側に、進めるか選ばせる条件を置けば意思決定待ち側に、書き方でどっちにも動く場所にいるんだよね。今日の話で、人に返す粒度がツールごとに違うっていうのはだいぶ形になった気がする。工程の完了時じゃなくて、エージェントが特定の判断をする直前に人間確認を入れたい人にはこの整理が向くと思うけど、自分の現場に合う1つのツールを決めてほしい人には物足りなかったかも。付き合ってくれてありがとう。
葉月
うん、こちらこそ。判断の直前で確認したい人には今日の話がそのまま使えると思うけど、比較じゃなくて一個に決めたい人には向かない話だったかもね。