• AI
  • Claude Code
  • Rust
  • 開発ツール

AI コーディングエージェントを何体も並列で走らせると何が起きるか — 管理ツール「すみつぼ」を作っている理由

Claude Code などを 2〜6 体並列で動かすと、承認待ちの取りこぼし・コストの見えなさ・コンフリクトで人間がボトルネックになる。Windows ネイティブで TUI と GUI を同じコアに載せる「すみつぼ」の設計思想と、なぜその構造にしたかを書きます。

公開: 約 7 分namespace

Claude Code のような AI コーディングエージェントを、1 体ではなく 2〜6 体、並列で走らせて開発するようになりました。速いです。ただ、速い代わりに人間のほうがボトルネックになる瞬間が増えました。この記事は、その問題を解くために作っている開発ツール「すみつぼ」の話です。

並列にすると何が起きるか

自分の体験と、同じことをしている人たちの記事を集めると、不満はだいたい次の 6 つに収束します。

#不満
1タブを 10 個開いて、どれが何をしているか分からなくなる
2承認待ちに気づかず、AI が止まったまま放置される
3トークン / コストが読めず、気づいたら週次の上限に当たっている
4タスクがセッションをまたいで壊れる。依存関係を毎回説明し直す
5並列にした結果コンフリクト地獄になり、人間がボトルネック化する
6既存のターミナル(iTerm2 / Warp / tmux)はエージェント時代に最適化されていない

特に 2 番が痛い。エージェントは「このコマンドを実行していいですか?」で止まります。止まっているのに気づくのが 10 分後なら、並列にした意味の大半が消えます。

既存ツールの空白

すでに Claude Squad、devteam、Conductor、vibe-kanban など、並列エージェントを管理するツールはあります。調べていくと、3 つの空白がありました。

  • Windows。 並列エージェント管理ツールはほぼ全て macOS + tmux 前提。日本の開発現場には Windows が多く、ここが最大の未開拓地
  • TUI と GUI の両立。 TUI 系は CLI 熟練者向け、GUI 系は macOS 専用。同じコアで両方を提供する製品がない
  • コストの「制御」。 ccusage は可視化の事実上の標準だが、管理・制御の機能は持たない

自分が Windows で困っていたので、まず 1 つ目を埋めることにしました。WSL も tmux も要らない、Windows ネイティブで動くものです。

すみつぼの一行定義

複数のコーディングエージェントを worktree で隔離し、依存関係グラフでタスクを配り、状態を一望し、承認待ちを取りこぼさず、コストを制御する統合開発ツール。

エディタではありません。人間がコードを書く機能は最小限しか持ちません。やるのは「配置・観測・検収」です。

  • どのエージェントが何をしているか
  • どれが承認待ちで止まっているか
  • いくら使っているか
  • 次に何をやらせるべきか

を一望し、差分を検収して PR に送り出すまでを担います。名前の由来は墨壺(すみつぼ)。大工が材木に基準線を弾く道具で、何人もの職人が同じ材に手を入れても、一本の線があれば仕上がりはずれない。エージェントが何体いても、基準線は人間が引く、という意味を込めています。

三層構造:TUI が基盤、GUI はその上に被せる

設計の背骨はここです。

sumitsubo-gui (Tauri + React)    sumitsubo-tui (ratatui)
              │                         │
              └──────────┬──────────────┘
                         ↓
               ViewModel (JSON)  ← 唯一の契約
                         ↓
               sumitsubo-core (Rust)
               PTY / worktree / 状態機械 / コスト集計

この構造から導かれる鉄則が 4 つあります。

  1. コアは UI を知らない。 色もレイアウトもコアには存在しない。コアが返すのは意味(state: "consult")だけで、それを赤く光らせるかは各クライアントの責務
  2. 機能は TUI で先に成立させる。 TUI で表現できない機能は、コアの設計が間違っている疑いを持つ
  3. ViewModel を変えるときは両クライアントを直す。 契約を壊す変更は人間が判断する。エージェントに勝手に変えさせない
  4. GUI は TUI の上位互換であって別物ではない。 同じ操作が同じ名前で存在する。TUI の n = GUI の「新規 Wave」ボタン

なぜこの構造にするか

理由説明
販売戦略TUI を OSS / 無料、GUI を有料にできる。コアは共通なので二重開発にならない
リモート開発SSH 越しの開発サーバーでは TUI しか動かない。ここを捨てると実務で使えない
設計の規律TUI という厳しい制約が、機能の肥大化を防ぐフィルタになる
CI / 自動化ヘッドレスでコアだけ叩ける(sumitsubo wave list --json

作業単位「Wave」

すみつぼでは、1 タスク = 1 Claude セッション = 1 PTY = 1 worktree = 1 PR を「Wave」と呼びます。エージェントごとに git worktree を切るので、並列に走らせても作業ツリーが混ざりません。コンフリクトは PR をマージするときに 1 回だけ向き合えばいい。

承認待ちの検出は、PTY の出力を状態機械で監視して行います。「Do you want to proceed?」のようなプロンプトが出た瞬間に consult 状態になり、一覧の中で目立つようにする。これで「10 分後に気づく」がなくなります。

いまどこまでできているか

Rust のワークスペース(core / rpc / daemon / cli / hook)と Tauri + React の GUI が動いていて、PTY 接続、契約層とデーモン、GUI での実データ表示、コスト集計、GUI からの Wave 作成、TUI のセッション画面まで来ています。開発中なので、公開はもう少し先です。

面白いのは、すみつぼ自体を、複数のエージェントを並列で走らせて作っていることです。5 枠並列で「波」を回し、各枠の担当ファイルを決めて、契約(ViewModel)を壊す変更だけ人間が判断する。ツールが解こうとしている問題を、ツールを作りながら毎日体験しています。

おわりに

AI エージェントを使った開発は、「1 体をうまく使う」段階から「何体かを配置して回す」段階に移りつつあります。そのとき必要なのは賢いエージェントではなく、人間が基準線を引き続けられる道具だと思っています。

AI を業務に組み込む設計や、エージェントを使った開発体制の相談は AI 開発 のページからどうぞ。

About the author

namespace

namespace(ネームスペース)

フリーランスの IT コンサルタント兼エンジニア。基幹システム刷新・データ基盤・FA から、Web / SaaS 開発、業務自動化、AI 開発まで一気通貫で支援しています。 相談する →

More posts