KanBots: Kanban を介した並列 AI エージェントのオーケストレーション

AI チャットインターフェースから自律型エージェントへの移行は、根本的にワークフローの管理方法の変化を意味します。単純なクエリには単一のチャットウィンドウで十分ですが、複雑なソフトウェアエンジニアリングのタスクには、進捗を追跡し、依存関係を管理し、タスクを並列に実行するための「記録のシステム（system of record）」が必要です。

KanBots は、Kanban ボードを単なるプロジェクト管理ツールとしてではなく、AI エージェントの能動的なランタイムとして再定義するオープンソースのデスクトップアプリケーションです。Claude Code や Codex のような CLI ベースのエージェントと統合することで、開発者は異なるカードに対して複数のエージェントを割り当てることができ、各エージェントは独自の分離された git worktree 内で動作します。このアプローチにより、ボードは静的なタスクリストから、並列な機能開発のためのダイナミックなエンジンへと変貌します。

並列エージェンシーのアーキテクチャ

KanBots の核となるのは「エージェント・ランタイム」という概念です。AI を対話パートナーとして扱うのではなく、KanBots は、特定のタスクに割り当て可能な「ワーカー」として扱います。

分離された Worktrees

KanBots における最も重要な技術的決定の一つは、git worktrees の使用です。エージェントがカードに割り当てられると、単に現在のディレクトリを修正するのではなく、専用の kanbots/issue-N ブランチとそれに対応する worktree を作成します。これにより、以下が保証されます：

並列性が安全であること: 複数のエージェントが、ローカルの作業ディレクトリでマージコンフリクトを引き起こすことなく、異なる機能を同時に開発できます。
コンテキストが保持されること: 各エージェントは独自のクリーンな状態を持っており、変更内容のレビューや差し戻しが容易になります。
デプロイが効率化されること: GitHub 統合により、worktree はワンクリックでコミットへ昇格させたり、ドラフト PR を作成したりできます。

エージェント CLI アダプター

KanBots は、独自の LLM オーケストレーション層をゼロから構築しようとはしません。代わりに、AgentCliAdapter を使用して、Claude Code や Codex のような既存の強力な CLI とインターフェースを提供します。これにより、ユーザーはアプリ内で別途アカウントシステムを管理することなく、既存の認証（例：claude /login）や API キーを活用できます。

高度なオーケストレーション：Autopilot と Persona

手動での割り当てを超えた活用を目指すユーザーのために、KanBots は、自己進化する機能開発システムである「Autopilot」を導入しています。

ペルソナベースの実行

KanBots における「ペルソナ」とは、名前付きのシステムプロンプトのスニペットです。ユーザーは Product Manager、Engineer、Reviewer、または Tester といった役割を定義できます。Autopilot モードでは、オーケストレーターが最大 4 つの並列スロットを通じて、これらのペルソナをラウンドロビン方式で実行します。

自己進化するバックログ

従来の自動化とは異なり、Autopilot はエージェントがボード自体を修正することを許可します。エージェントが実装中に新しい要件やバグを発去見した場合、ボード上に新しいカードを作成できます。これらの新しいタスクは、サイクル内の次の利用可能なペルソナによって処理され、タスクが完了に向かって収束していくループが形成されます。

ローカルファーストの哲学

クラウド中心の AI ツールが普及する時代において、KanBots はプライバシーとローカル制御に対して明確な姿勢を示しています。このアプリケーションは、SQLite データベース、設定、および worktrees がすべてリポジトリの隣にある .kanbots/ フォルダ内に存在する、ローカルファーストのツールとして設計されています。

この「ゼロサーバー」アプローチにより、コードがマシンから離れることは決してありません。これは、多くのプロフェッショナルな開発者が採用において譲れない条件とする要件です。さらに、MCP (Model Context Protocol) サーバーの搭載により、Cursor や Claude Desktop といった他の MCP 対応ツールが KanBots ボードと対話できるようになり、ボードが他のエージェントのための第一級のツールとなります。

コミュニティの視点と課題

技術的なアーキテクチャは印象的ですが、Hacker News でのコミュニティの議論は、現在のエージェント型ワークフローにおけるいくつかの重要な緊張関係を明き示しています。

監視のギャップ

多くの開発者が、これらのツールの「オートパイロット」的な性質に対して懐疑的な見見解を示しています。あるユーザーが指摘したように、エージェントが短期間に生成する膨大な量の変更は、レビューが追いつかないほど圧倒的になる可能性があります：

"I keep wondering how people accept a nights worth of agent activity... At minute 5, I may ask the AI to redo stuff even as its spitting out code."

これは根本的な課題を浮き彫りにしています。エージェントのコードを実際に書く能力が増すにつれ、人間がそのコードを レビュー する能力がボトルネックになります。

IDE 統合の問題

もう一つの論争点はインターフェースです。Kanban ボードはハイレベルなオーケストレーションには優れていますが、一部の開発者は、エージェントントが「小さなチャットインターフェース」に閉じ込められるのではなく、すべてのタスクに対して完全な IDE 環境を持つべきだと主張しています。求められているのは、「1 タスク = 1 worktree = 1 フル IDE」モデルであり、人間がフル機能のエディタに飛び込み、エージェントのエージェントの作業をリアルタイムでレビューし、洗練させるモデルです。

コストと予測可能性

一部の CLI ツールが API ベースの価格体系に移行しているため、、高レベルなオーケストレーターを動かすコストが急騰する可能性があります。KanBots は、ライブ・コスト・アナリティクスと、実行ごと/セッションごとの予算上限の設定を実装することで、この問題に対価処しています。これにより、オートノマス・エージェント・ループに伴う「予期せぬ請求」シナリオを防ぐことができます。

結論

KanBots は、AI エージェントをチャットインターフェースではなく、拡張可能なワークフォースとして扱うための重要な一歩を表しています。Kanban の構造的な規律と git worktrees の技術的な分離を組み合わせることで、、オートノマス・ソフトウェアエンジニアリングの複雑さを管理するためのフレームワークを提供します。「監視のギャップ」は依然として課題ですが、ローカルファースト、オープンソースのアプローチにより、開発者はコードとプロセスを自ックック管理し続けることができます。