kiro-cliのPR動作確認結果

[okajun35]

#773 のPRの動作確認した結果です。

kiro-cli 2.5.1 で TAKT の Kiro provider を動かして確認しました。
結論として、この PR は方向性としては良いのですが、現状のままだと TAKT のマルチターン実行では文脈が継続されないため、少なくとも以下の2点は入れたほうがよいと思います。

1. 重要: 初回ターンで実際の Kiro session ID を確定して返す

現状の src/infra/kiro/client.ts の KiroClient.call() は sessionId: options.sessionId を返しています。

そのため、初回ターンでは options.sessionId が存在せず、response.sessionId が undefined になります。

一方で、TAKT 側の aiCaller.ts / conversationLoop.ts は、次ターンに response.sessionId を渡し直す設計です。
つまり、初回レスポンスで実 session ID が返らないと、2ターン目以降が同じ会話に接続されず、毎回新規会話になって文脈が失われます。

kiro-cli 2.5.1 で確認した挙動は以下です。

• 実在する session ID を --resume-id <ID> に渡すと、cwd に依存せず正しく再開できる
• --list-sessions は最新セッションが先頭に出る
• 2.5.1 では --list-sessions への反映はほぼ即時
• ただし --list-sessions の出力は stdout ではなく stderr に出る

そのため、provider 側では以下の流れが現実的だと思います。

1. 初回ターンでは、--resume も --resume-id も付けずに通常実行する
2. 実行成功後に kiro-cli chat --list-sessions を実行する
3. stdout / stderr の両方を見て、ANSI エスケープを除去した上で、先頭の UUID を取得する
4. その UUID を response.sessionId として返す
5. 2ターン目以降は --resume-id <取得した実ID> で再開する

この方式で、逐次マルチターンは動作確認できています。

例:

Turn1 sessionId: 8df26159-87b5-495d-be71-806e71c7ea67
Turn1 content:   OK
Turn2 sessionId: 8df26159-87b5-495d-be71-806e71c7ea67
Turn2 content:   モンブラン

また、同一 cwd で2つの会話を逐次に開始した場合も、実 session ID により正しく分離されました。

例:

A.sid: e7493b0a-...
B.sid: 2033a622-...
separated: true

A recalls: 42
B recalls: 青

実装上の注意点は以下です。

• --list-sessions の出力は stderr に出るため、stdout だけでは取得できない
• ANSI エスケープを除去してから UUID を抽出する必要がある

2. 重要: 応答本文から ANSI エスケープと先頭プロンプト記号を除去する

kiro-cli chat --no-interactive は、非TTYのパイプ出力でも ANSI カラーエスケープと先頭のプロンプト記号 > を stdout に出します。

確認例:

$ kiro-cli chat --no-interactive "OKと答えて" | cat -v
^[[38;5;141m> ^[[0mOK

現状の provider はこの stdout をそのまま AgentResponse.content に入れているため、成果物やメタデータにエスケープ列が混入します。

実際に観測した例:

"task": "\u001b[38;5;141m> \u001b[0m\u001b[38;5;252m\u001b[1m## タスク指示書..."
runSlug: "20260602-053649-38-5-141m-0m-38-5-252m-1m-0m-0"

この状態だと、色コードがスラッグ化されたり、成果物に制御文字が混入したりします。

そのため、AgentResponse.content に入れる前に、少なくとも以下を除去したほうがよいです。

• ANSI カラーエスケープ
• 先頭の > プロンプト記号

parseLatestSessionId 側でも同様のクリーンアップが必要ですが、本文側にも同じ処理が必要です。

provider 側だけでは完全解決できない制約

上記の --list-sessions 方式は、逐次マルチターンでは有効です。
ただし、同一 cwd で複数の新規 Kiro 会話を同時に開始するケースでは完全には安全ではありません。

理由は、複数プロセスが同時に --list-sessions の「最新セッション」を取りに行くと、同じ session ID を掴む可能性があるためです。

実際に Promise.all で2つの新規会話を同時開始すると、以下のように混線しました。

A.sid: ff25be52-...
B.sid: ff25be52-...
separated: false

A recalls: 888
B recalls: 888

また、frontend / backend を同時に実装するような parallel workflow 相当でも再現しました。

FE.sid: 87c3433c-...
BE.sid: 87c3433c-...
separated: false

FE recalls: バック
BE recalls: バック

つまり、provider 側の --list-sessions 方式で逐次ワークフローは改善できますが、同一 cwd での新規会話の同時並行については、kiro-cli 本体側の対応が必要です。

根本的には、kiro-cli 側で以下のどちらかが必要だと思います。

• headless mode で session ID を stdout / JSON に出す
• --resume-id <caller-supplied-id> で新規セッション作成を許可する

この点は Kiro CLI 本体側の Feature Request として別途起票しています。

follow-up でよさそうなもの

以下も有用ですが、上記2点とは分けてもよいと思います。

• TAKT persona 名を .kiro/agents/<name>.json が存在する場合に kiro-cli --agent <name> へ配線する
• stderr から Credits: X.XX / Time: Ns を拾って usage 情報として surface する　※こちらは消費量は調べる方法はほかにあるのでそこまで重要
  ではないです。