AI CLI を 7 本並べたら、次に要るのは「契約」と「引き継ぎ」と「委譲」だった。many-ai-cli v0.8.0

複数の AI コーディング CLI を 1 タブに集約するダッシュボード many-ai-cli の v0.8.0 を出しました。CHANGELOG の項目は 78 個で、前回の 27 個から 3 倍近くになっています。増えたのは機能を足したからというより、同時に回す CLI が 6 本から 7 本になった結果、足りないものが 3 か所同時に見えたからでした。契約を積む層、セッションを引き継ぐ層、作業を委譲する層の 3 つに並べ直した記録です。

記事全体の要約。3 つの層と、それぞれで何を決めたか。

1 本目の層: 同じ CLI に契約を 2 本ぶら下げる

AI のコーディング CLI は月額プランで動き、枠を使い切ると一定時間止まります。契約を 2 本持っていても、公式 CLI は「いつものログイン」を 1 つしか覚えないので、2 つ立ち上げると両方が同じアカウントを見にいきます。

v0.8.0 でやったのは、公式 CLI が持っている「設定をどのディレクトリから読むか」の切り替えを、起動時に環境変数で差し替えることだけです。ログインは公式 CLI にそのまま任せるので、こちらは token を読まないし保存もしません。残量を見て勝手に別契約へ乗り換える機能は、意図的に作っていません。

やっているのは設定ディレクトリの差し替えだけ。認証情報の置き場所は動かしていません。

2 本目の層: 詰まったセッションを次へ渡す

長く動かしていると、契約の枠切れ、文脈の劣化、単純な停止でセッションが使えなくなります。困るのは、そこまでの経緯がその会話の中にしか無いことでした。

そこで「引き継ぎ看板」を足しました。設計で決めたのは、入れてよいものを型で先に固定したことです。完了サマリー、次にやること、未検証の前提、変更ファイル。この 4 種類しか入る場所がなく、PTY の出力やファイルの中身を入れるフィールドは作っていません。伏字化は最後の網であって、最初の守りにはならないという判断です。

左が入るもの、右が入る場所そのものが無いもの。allowlist はテストで固定してあります。

3 本目の層: 指揮者に判断させず、Hub が回す

1 つのセッションが指揮者になって子セッションを起こす仕組みは前からありました。そこに「実装 → レビュー → 修正」を回すループを足すとき、最初は指揮者の AI に進行管理を任せようとしてやめています。どこまで進んだかの記録が会話の中にしか無いと、同じ段を 2 回踏んだり、終わった段へ戻ったりするからです。

進行は Hub の状態機械が持ち、AI がやるのは実装とレビューと修正だけにしました。作業は専用の worktree の中だけで行い、利用者のブランチには触りません。

判断は Hub、作業は子。どちらが何を決めるかを固定しました。

記事に書いたこと

Qiita 版には、3 層それぞれの設計判断と、それを守るために書いたテストの話を入れました。停滞の判定を画面の見た目ではなく CLI が書くトランスクリプトの増減で行う理由、7 本目に足した Command Code を「対応済み」と書かなかった理由、そしてリリース後に自分で踏んだ 4 件の後始末も入っています。