すべてのカードで並列エージェントを実行するオープンソースのKanbanデスクトップアプリ
(kanbots.dev)- KanBotsは、各カンバンカードごとにClaude CodeとCodexを並列実行し、進捗・意思決定・コストをボード上にリアルタイム表示するデスクトップアプリ
- 各実行は
kanbots/issue-Nブランチの個別のgit worktreeで分離され、フォルダを投入してボードを作成し、カードごとにエージェントを割り当てられる - Autopilotは、プロダクト・エンジニア・レビュアー・テスターのようなペルソナを最大並列度4で巡回しながら作業を分担し、バックログを更新する
- エージェントは判断が必要な地点で停止して選択肢を提示し、ユーザーは番号選択・修正して再送・
/spec・/review・/splitで続行できる - デスクトップアプリは無料のMITライセンスとローカルファースト方式を採用し、Cloudは1席あたり月額$19でチーム同期・通知・ダッシュボードを提供する
KanBotsの基本概念
- KanBotsは、Claude CodeとCodexエージェントをカンバンボードのカード単位で並列実行するデスクトップアプリ
- 各エージェントは
kanbots/issue-Nブランチの個別のgit worktreeで実行され、ボードは進捗・意思決定リクエスト・コストをリアルタイムで更新する - フォルダを投入するとボードが生成され、複数のカードにClaude CodeまたはCodexエージェントを割り当てられる
- 自動実行モードでは、ペルソナが作業を分担して並列実行し、結果を点検する
- デスクトップアプリは無料、MITライセンス、寄付ベースで、ローカルファースト方式で動作する
製品構成と課金
-
デスクトップOSS
- Desktopはローカルファースト、アカウント不要、テレメトリなし、永続的に無料、MITライセンス方式
- macOS、Linux、Windowsをサポートし、すべての機能を含む
- 主な機能には、並列エージェント実行、自動実行、意思決定プロンプト、組み込み・ユーザー定義ペルソナ、リアルタイムのコスト分析、レシピライブラリ、
kanbots-mcp-server、Sentry取り込み、GitHub Issuesモード、ブランチプレビュー、PRドラフト作成、Claude Code・Codex対応、pre-push hookが含まれる
-
チーム向けCloud
- Cloudはホスト型のマルチユーザー製品で、エージェントはユーザーのハードウェア上でローカル実行される
- 価格は1席あたり月額$19、年額請求では$190
- OSS機能に加えて、ボード上のリアルタイムプレゼンス表示、チームメンバー割り当て通知、デバイス間同期、Slack通知、組織全体のコスト集計、リアルタイム共同カード編集、組織別エージェント活動ダッシュボード、Managed GitHub Appを提供する
- Enterprise機能には、監査ログ、SSO / SCIM、REST APIとPAT、アウトバウンドWebhookが含まれる
- Cloud専用機能は、他の人や他のデバイスが存在して初めて意味を持つ機能に限定され、1人が1台のマシンで使う機能はOSSに含まれる
対応ツールと連携
- Claude CodeとCodex CLIに対応
- GitHub IssuesとPR作業に対応
- Sentryエラー取り込みに対応
- CursorとClaude DesktopはMCPクライアントとして連携可能
- ローカルストレージはSQLiteを使用
- デスクトップシェルはElectronベースで提供される
主要機能
-
並列カード実行
- 複数のカードでエージェントを同時実行でき、各実行は独自のgit worktreeと
kanbots/issue-Nブランチで進行する - ボードは実行の進捗、エージェントの意思決定リクエスト、累積コストをリアルタイムで更新する
- 複数のカードでエージェントを同時実行でき、各実行は独自のgit worktreeと
-
自動実行とペルソナ
- プロダクト、エンジニア、レビュアー、テスターのようなペルソナを接続し、並列度は最大4まで設定できる
- オーケストレーターがペルソナをラウンドロビンで巡回し、上位課題を下位タスクに分割し、エージェントが発見した作業でバックログを更新する
- ペルソナが別のペルソナを生成できる
-
意思決定中心の実行
- エージェントは必要な判断に出会うと停止し、選択肢を表示する
- ユーザーは番号選択、修正後の再送、
/spec、/review、/splitのようなスラッシュコマンドで実行を続けられる - 作業ツリーを静かに変更する代わりに、レビュー可能な意思決定フローを残す
-
Claude CodeとCodex統合
- Claude CodeまたはCodexを、同じボード、同じworktree、同じ意思決定UIで利用できる
- KanBotsは単一のAgentCliAdapterの背後で2つのストリーム形式を処理する
- 既存の
claude /loginまたはOPENAI_API_KEYを利用できる
-
ローカルファースト保存
- すべてのデータはリポジトリ横の
.kanbots/内に配置される - SQLiteデータベース、設定、worktreeがローカルに保存される
- クラウドアカウント、テレメトリ、HTTPサーバーはなく、コードがマシンを離れない
- すべてのデータはリポジトリ横の
-
コスト分析と予算制限
- 実行ごと、カードごと、プロジェクトごとのコスト集計を提供する
- エージェント作業中にコストメーターが累積する
- 実行ごと・セッションごとの上限を設定でき、予算に達すると実行が停止する
-
GitHubワークフロー
- 個人PATで実際のGitHub Issueを扱える
- worktreeをコミットに昇格させたり、ワンクリックでドラフトPRを開ける
- pre-push hookによってエージェントが自力で公開できないようにする
-
MCPサーバー
kanbots-mcp-serverがModel Context Protocolを通じてボードを公開する- Cursor、Claude Desktop、またはMCPを理解するツールがボードを扱える
- ボード自体が、他のエージェントが利用できるツールになる
アプリ内部のワークフロー
-
Autopilot
- 1つ以上のペルソナを選択し、並列度を設定してから自動実行を開始する
- 最大4つの並列スロットがペルソナ一覧をラウンドロビンで巡回する
- 各スロットは次のペルソナをアトミックに取得し、エージェントは進行中に上位課題を下位タスクへ分割する
- 完了またはセッション予算到達時に停止する
- 例示画面には、Claude Opus 4.7、
mediumeffort、並列度2、Product ManagerとSenior Engineerペルソナが選択された状態が表示される
-
Decisions
- 実行スレッドはすべての
tool_useとtool_resultをリアルタイムでストリーミングする - エージェントが判断が必要な地点で実行を止め、番号付きの選択肢を提示する
- 返信入力欄は
/spec、/review、/splitのようなコマンドを受け付ける - パスワードリセットトークン実装の例では、単回使用JWT、DB保存のopaque token、マジックリンク、まずトレードオフを説明するといった選択肢が表示される
- 実行画面には、モデル、経過時間、トークン数、コスト、状態、優先度、フォルダ、worktree、ブランチ、ベースブランチ、作成者が表示される
- 実行スレッドはすべての
-
Personas
- ペルソナは名前付きのシステムプロンプト断片
- 既定のペルソナはアプリに含まれ、ユーザーは新しいペルソナを作成して保存し、再利用できる
- ユーザー定義ペルソナはそのマシンにローカル保存される
- 既定の例として、Product Manager、Senior Engineer、UX Designer、Growth Lead、Reliability Engineerが提供される
-
Providers
- Claude CodeとCodexを1つの
AgentCliAdapterの背後で利用できる - 既存の
claude /loginまたはcodex loginを再利用でき、追加アカウントや追加のキー管理は不要 - 実行ごとにプロバイダーを切り替えられる
- Codex CLIは
codexがPATH上に存在する必要があり、Issueドラフト作成とSentry分析は引き続きClaudeで実行される - Codexログインではブラウザで
auth.openai.comを開くか、環境変数OPENAI_API_KEYを利用できる
- Claude CodeとCodexを1つの
-
Tasks
- 新規タスクでは、バグ修正、機能追加、リファクタリング、レビュー、スパイクのテンプレートを提供する
- 開始方法はspec-first、作成後すぐに実行、後でキューに入れる、から選択する
- タイトルはブランチ名とPRタイトルに使用される
spec-firstは/specを実行して受け入れ条件を磨き込み、承認待ち状態に置く- 新規タスクはfresh worktreeを作成し、
mainを基準に.kanbots/worktrees/issue-N配下へブランチを生成する
-
Chat
- ワークスペースについて質問できる汎用エージェントが提供される
- エージェントはリポジトリ、テスト、git状態を把握し、質問に答える
- rate limitingのないAPIルートを見つけ、
/api/loginと/api/signupにrateLimit({ windowMs: 60_000, max: 10 })を追加し、その後テストを書いて通過させる例が示される
Autopilotの動作方式
- Autopilotは、Issueと予算を受け取り、バックログを自律的に更新するモード
- オーケストレーターがペルソナ一覧をラウンドロビンで巡回し、最大4スロットを並列実行する
- 上位課題を下位タスクへ分割し、作業が収束するかコスト上限に達するまで循環する
- 例では、並列度4、モデル
opus 4.7、セッション予算$25.00のうち$4.27を使用、14回目のサイクル状態が表示される -
ペルソナ一覧の選択
- 既定のペルソナを使うか、独自のシステムプロンプトを定義して保存し、再利用できる
- ユーザー定義ペルソナはマシンを離れない
-
並列度設定
- 並列度は1から4まで設定可能
- 各スロットはラウンドロビンカウンターを通じて次のペルソナをアトミックに取得する
- 4つのエージェントが4つの視点と4つのworktreeで同時に実行できる
-
作業分割
- エージェントが作業を発見すると、新しいカードをボードに作成する
- その後のサイクルが新しいカードを取得し、バックログはオーケストレーター配下で増減する
-
予算または完了時に停止
- セッションごとのコスト予算が総支出を制限する
- 停止ボタンは親実行とすべての子実行を終了する
- 実行中の処理は現在の反復をクリーンに終える
QAモード
- QAモードはworktree内でtypecheck、tests、lint、build、e2eを実行する
- 必要に応じて開発サーバーを起動し、監視できる
- 失敗した各チェックに対して、派生した子Issueで修正実行を割り当てる
- チェックが通るまで繰り返す
提供形態とまとめ
- OSSデスクトップアプリは、無料、MITライセンス、アカウント不要で提供される
- すべてのエージェント実行をカンバン上に載せて可視化し、意思決定可能にし、分離する流れを強調する
- チームでボードを共有する必要がある場合はCloudへ移行できる
- ダウンロード形式はmacOS
.dmg、Windows.exe、Linux.AppImage/.tar.xz
1件のコメント
Hacker Newsのコメント
エージェントが一晩中作業した結果を、人がどう受け止めているのかずっと疑問に思っている
個人のサイドプロジェクトのリポジトリですら、30分計画して30分実装した結果はレビューするには大きすぎると感じる。5分ほど経つと、コードがどんどん出てくる最中でもAIにやり直させることがある
個人的には強いファイル構造も役に立つ。たった今生成された3,000行のファイルをレビューするのは最悪で、人間にも機械にもそんな成果物は受け取りたくない。適切な場所に複数ファイルへ分かれていれば、認知負荷は下がる
ときにはエージェントと対話しながら一緒にレビューすることもある。まず最初にレビューすべき最重要ファイルはどれか、と聞くような感じだ
変更を「LGTM」の山にステージしておくのが好きだ。後で修正が必要なら、エージェントに「ステージされていない変更をレビューして。ここは別のやり方にしてほしい」と指示する
何か問題が起きたら、つまりバグが出たら、その場その場で直す。ソフトウェアエンジニアリングにとってとても悲しい時代だ。この業界にエンジニアリングというものがあったなら、今ではその大半が消え、「バグを入れないで」や「君は借り手ではなくオーナーだ」といったskillsファイルを書いて、だいたいの当たりをつけている
努力レベルも低く、決定性もとても低い。GitHubのような大きなアプリですらAIのゴミのせいで劣化し続けていて、知名度の低いシステムではさらに頻繁に見かける。自社や、私たちが使っている他のSaaSでも同じだ
プロダクトマネージャーはもともとコードに関心がなく、エンジニアリングマネージャーも、エンジニアだった頃ほどコードに関心がない。ディレクターはコードをまったく気にせず、CTOは今やコードがどんな見た目かすら知らない
私たちは鎖の末端にいて、良いシステムは良いコードの上に築かれることを深く知っていたからこそ、使いやすく保守しやすいコードに誇りを持ってきた。なのに今は自分たち自身を危険にさらしていて、コードをもう気にしなくなっているのは当のエンジニアであり、AIがその問題を増幅している
ほとんどの時間は、複数のアプローチを試して要約し、そのうえで自分がレビューして修正できる比較的小さな差分を出させることに使っている
個人的には、エージェントが作った成果物にはいつも何かしら手を入れることになる。そのコントロールを手放すべきなのか悩んでいる
これは、たいていのプロジェクトでコーディングエージェントを管理するときに使っているVibe Kanban(https://vibekanban.com/)を思い出させる
残念ながら、Vibe Kanbanの開発者たちは収益化の道筋が見えないと判断して、プロジェクトへの投資を止めてしまった。オープンソースなのでローカルで動かしたりフォークしたりはできるが、改善は止まっており、まだ直すべき厄介なバグが残っている。個人的にはメンテナンスする時間がない
喜んでVibe Kanbanにお金を払うつもりはあったので残念だ。ただし有料プランの機能は必要なかった。今思えば、ただ払っておくべきだったのかもしれない
Kanbotsも試してみるつもりだ。Vibe Kanbanの機能は積極的に真似してもいいと思う。特にリモート対応と「Open in VS Code」ボタンは自分にとって重要だ。自分の場合、このボタンはリモートVSCodeサーバーを指すローカルのVSCodeクライアントを開いてくれる
この1〜2週間、新しいツールをVKと機能同等レベルまで引き上げ、さらに改善も加える作業をしている。Vibe KanbanのDiscordにもスクリーンショットを何枚か投稿した。リリース準備が整ったら、あなたのユースケースにもよく合うことを願っている
私のツールは、Kanbanボードとエージェントのワークスペースの両方でVKより良い機能を目指しており、デスクトップのウィンドウ管理、プラグイン、ブラウザ内VSCode統合、htmx風のサーバーレンダリングUIといった追加システムも入れている
リモートアクセスの方式も異なる。ノートPCでWebサーバーを立ててリモートのコーディングエージェントにアクセスする代わりに、OpenClawのように全体をホストし、ブラウザからリモートデスクトップUIにアクセスする
「ローカルファースト、サーバーなし。すべてがリポジトリ横の .kanbots/ にある。SQLiteデータベース、設定、ワークツリー。クラウドアカウントなし、テレメトリなし、HTTPサーバーなし。これがオープンソースのデスクトップエディションだ」という点は、こうしたツールの導入を検討するための前提条件だ
AIがエージェント型なら、どんなプロダクトマネージャーでも1時間ほど会話すれば、Jiraと何らかのエージェントループを統合できるはずだと期待する
Jira、Trello、Linear、BasecampにはどれもAPIがあり、エージェントが使えるCLIもあるはずだ。作業を始めたらチケットがチェックアウトされ、指示を持ち、終わったらDONEに移る、ということを理解させるのに、開発者やSaaSが必要であってはならない
正直、見た目はかなり良さそうだ。でも、見た目が良さそうなツールはすでにかなり多い
そもそも「Kanban」という言葉は、Toyotaがカードシステムを説明するのに使ったもので、そのシステムは同時に抱える仕事を増やしすぎないことや、作業を可視化することなど、いくつかの重要な目的を果たしていた
全体として、Kanbanは欠陥を通過させないために作業フローを管理するために使われていた
ところがこのツールは、「思いつく仕事をできるだけ並列で生成されるよう押し込む」というものに近い。品質あるアウトプットの流れを管理しているわけでもなく、作業を制限しているわけでもない。ひたすら何でもエージェントに放り込み、トークンを狂ったように燃やしているだけだ
こんなものを「Kanban」と呼ぶのは本当に気に入らない。冒涜に近い感じがする
エージェントを監督なしで回してみたが、成功よりもフラストレーションの方が多かった
技術はいずれそこまで行くと信じているが、今はエージェントごとにIDEが1つ必要で、作業のマージも面倒だ
最新のオープンソースプロジェクトを共有する。並列エージェントを備えたKanbanボードだ
さらに多くの機能で改善しようとしているところで、コード貢献でもアイデアでも、リポジトリに貢献してくれるとうれしい
作業の進み方を追っていくのが楽しそうだ
これは基本的にWindsurfがやっていることではないのか？ 結局、こうしたUIはどれもエージェントの上に載った見た目の層にすぎない
[0] https://windsurf.com/blog/windsurf-2-0
自分には、もっと人が介在するフローが必要だった。変更セットを十分に見られず、方向転換の機会もないままエージェントに渡すやり方は合わない
https://www.agentkanban.io は、拡張機能を通じてタスクボードとVS CodeのGitHub Copilot Chatを接続し、タスク管理と、チャットからタスクへつながるコンテキストの取得を両立している。だから、VS Codeという上位の実行環境の利点と、タスク／プロジェクト管理機能の両方を使える
Linearもまさにこの方向で取り組んでいる
こうしたツールでよくわからないのは、異なるワークツリーごとのインフラ起動をどう扱うのかという点だ
たとえばWebアプリがあるなら、各ワークツリーがそれぞれ自分のインフラを立ち上げ、固有のローカルURLでアクセスできる必要がある。そうでないと、各ワークツリーの変更をローカルで確認したり、agent-browserのようなものでエージェントが視覚確認を自動化したりできない
いまはインフラにDockerを使っていて、各サービスはそれぞれのコンテナで動かしている。
./app worktree create worktreenameというスクリプトがあり、このスクリプトは「worktreename」というワークツリーを作ったあと、「WORKTREENAME」のようなプレフィックスを付けてDockerインフラを全部立ち上げる。だから、すべてのURLに worktreename.myapp.test でアクセスでき、メインのワークツリーは単に myapp.test を使う今のところうまく動いているが、こうしたアプリのどれかがこの概念と互換性を持ってくれれば、そちらへ移行できてありがたい
そのCLIは
.envファイルにそのワークツリー用のURLとデータベースを埋め込み、Vercelのオープンソースパッケージ portless で固有ポートの開発サーバーを立ち上げる。だからワークツリーごとにURLが得られるこれには、10個分のポート範囲に対する固有ポートである
EMDASH_PORTが含まれる。単一モノレポで複数サービスを動かすときにとても便利だそのシェルスクリプトは、既存のすべてのワークツリーの中で使われていない固有ポートを見つけ、ワークツリー作成時にローカルの
.envに割り当てる。ワークツリーがマージされて削除されると、ポートも解放されるワークツリーごとではないシークレット値はローカルの
.envには置かず、シェルから注入している正直、開発作業の自動化のためにこういうローカルスクリプトを書くのはとても簡単で、他のあらゆるCLIツールともよく組み合わせられる。だからまだGUIアプリは使っていない。自分が望む通りに動くカスタムのローカル設定と競争できるのかはわからない
N=mod(...)を取り、port=default_port+NにすればいいClaudeに設定させればいい。1つのプロンプトでやってくれるはずだ
「‘kanbots’は破損しているため開けません。ゴミ箱に移動する必要があります」だって
vibe codingソフトウェアで最初に出会うエラーとしてはあまりにもふさわしい
これって単なる vibe-kanban じゃないのか？
https://github.com/BloopAI/vibe-kanban