Vibe Kanban代替：コーディングエージェントを今すぐ実行するならどこ？

ボードを軸に仕事の習慣を組み立ててきたのではないでしょうか。タスクごとに1列、カードごとにコーディングエージェント1体、それぞれが自分の git worktree の中で動くので衝突は起きません。3〜4体のエージェントを同時に走らせながら、diff を1つずつレビューできる、実にクリーンなやり方でした。ところが、そのツールを保守していた企業がクラウド事業を終了し、こんな率直な疑問が浮かびます。これからコーディングエージェントはどこで動かせばいいのか、そしてその答えはノートPC1台と1人を超えてスケールするのか、と。

Vibe Kanban の代替を探しているとして、それは Claude Code や Codex の代替を探しているわけではありません。探しているのは、それらのランタイムを取り囲むレイヤーです。各エージェントにタスクを渡し、作業を分離された状態に保ち、マージ前に何が変わったかを示してくれる場所です。本記事ではそのレイヤーを順に解説します。Vibe Kanban が証明したパターンには十分な敬意を払いつつ、ローカルボードが通用しなくなる境界線をはっきり示し、その先の共有タスク、Crews、Sprints へとチーム全体で使い続けられる Sharkly がどう引き継ぐかを見ていきます。

TL;DR

Vibe Kanban は「エージェントごとに1枚のカード」というモデルを切り開きました。複数のコーディングエージェントを並列で走らせ、それぞれを専用の worktree に置き、その出力を手元のマシン上のカンバンボードでレビューする。Sharkly はこのモデルをそのまま保ち、その周りにチームのレイヤーを加えます。共有された Task レコード、接続された Computers、Crews、Sprints、そしてリクエストからリリースまでの人間によるレビューです。1台のマシンでソロで作業するなら、ローカルボードで十分です。チームが共有コンテキストとレビューのゲートを必要とするなら、そこから Sharkly の出番です。

Vibe Kanban の代替が本当に解決する課題

Vibe Kanban は、ほとんどのツールが見落としていた重要な点を正しく押さえていました。複数の AI コーディングエージェントを同時に走らせるとき、難しいのはモデルではありません。厄介なのは衝突です。2つのエージェントが同じファイルを編集し、出力はターミナルのタブに散らばり、どのタスクが完了し、どれがブロックされ、どれが静かに迷走しているのかを一覧で把握する術がない。

「エージェントごとにボード」という答えはエレガントでした。タスクごとにカードを1枚。カードごとに専用の git worktree を与え、エージェントは隔離されたディレクトリの隔離されたブランチで作業します。Claude Code、Gemini CLI、Codex などのランタイムにそのサンドボックス内で作業させ、diff を持ち帰ってレビューします。これにより「5体のエージェントが動いているが、何をしたのか皆目わからない」という状態が、実際に読めるボードへと変わりました。この並列パターンの仕組みそのものについては、複数の Claude Code エージェントを並列で実行する方法のガイドで worktree のセットアップを詳しく解説しています。

欠けていたのはパターンではありません。ローカルボードでは届かない部分です。手元のマシン上のボードは、あなただけのボードです。チームメイトはタスクを見られず、ブロックされたカードを拾うこともできず、マージ前に diff をレビューすることもできず、離れた場所からスプリントが順調かどうかを知ることもできません。作業がソロならそれで問題ありません。しかし作業がチームのものなら、足りないのは共有レコードであり、それは別の種類のツールです。

Vibe Kanban が証明したこと、率直に言えば

このツールには最大限の評価を与えましょう。そうされるだけの価値があります。Vibe Kanban は、エージェントの実行を使い捨てのターミナルセッションではなく、第一級の作業単位として扱いました。worktree による分離をデフォルトにしたので、並列エージェント同士がぶつからなくなりました。ランタイムの切り替えを安価にしたので、1つのモデルに縛られることもなくなりました。そして diff を目の前に出すことで、レビューを後回しではなく1つの工程にしました。カードを完了に移す前に、です。

この4つの考えはどれも正しく、本気の代替ツールならすべて維持しなければなりません。worktree の分離を捨てたり、diff を隠したり、単一のランタイムに縛ったりする Vibe Kanban の代替は、他に何を追加しようとダウングレードです。あのボードが設定した基準は下限であって、上限ではありません。

変わったのは保守体制です。プロジェクトはオープンソースで、今もローカルで動かせますが、企業が運営していたクラウド機能は削除され、今後の修正はコミュニティのコントリビューター頼みになりました。ソロの開発者なら、それはまったく問題ないかもしれません。しかし四半期のデリバリーをこのツールに賭けるチームにとって、「誰かが出てきてくれれば何とかなる」は無視できないリスクであり、今まさに移行が検討されている正直な理由でもあります。

ローカルボードが終わり、Sharkly が引き継ぐ地点

ここで、実際の判断がどう分かれるかに沿って選択肢を整理します。

ローカルボードを使うべきなのは、1人で1台のマシンを使い、タスクが自分だけのもので、プルリクエストを開くまで誰もその作業を見る必要がない場合です。「エージェントごとにカード1枚」の構成は軽量で、自分の環境で動き、調整相手がいないので調整コストはゼロです。このケースでチーム向けプラットフォームに手を伸ばすのは過剰です。

Sharkly を使うべきなのは、エージェントの実行がプライベートでなくなったときです。2人目がタスクを割り当てたり、ブロッカーを拾ったり、マージ前に diff をレビューしたりする必要が生じた瞬間、ノートPC上のボードはボトルネックになります。それが境界線です。Sharkly は、すでに使っているのと同じランタイムを取り囲むレイヤーであり、すべての実行を自分だけでなくチームが割り当て・閲覧・レビューできるものにします。

ここから先の話の前提になるので、用語集レベルの簡単な定義を。Task は Sharkly における作業の基本単位です。ゴール、割り当てられた Agent、ランタイム、進捗、ブロッカー、結果としての diff、人間によるレビューを、1つの共有レコードにまとめます。ローカルボードのカードが自分だけのものなのに対し、Task はチームのものです。

そして境界線の話も必要です。ローカルボードから移行する読者は、そう言われなければ誤解するからです。Sharkly は Claude Code、Codex、Gemini の代替ではありません。モデルを動かすこともコードを書くこともありません。チームがすでに使っている実行ツールの周りに、共有タスク、接続された Computer、コンテキスト、コントロール、レビューのレイヤーを加えるのです。Vibe Kanban がランタイムを自由に差し替えられた点が気に入っていたなら、Sharkly はその自由を保ったまま、そこにチームを加えます。

移行パス：ランタイムはそのまま、リポジトリもそのまま、レビューレイヤーだけ追加する

終了していくボードから離れる最大の利点は、手放すものがほとんどないことです。スタックを作り直すのではありません。うまくいっていた部分はそのまま残し、欠けていた部分を足すだけです。

ランタイムはそのまま。Claude Code、Codex、Gemini CLI、OpenCode、Cline などは、これまでとまったく同じように実行を担い続けます。モデルの利用は、これらのツールにすでに設定されているサブスクリプションや API キーを通じて続きます。サブスクリプションはご自身で用意するものであり、Sharkly がエージェントとモデルの間に立つことはありません。これらのランタイムが何をしているのかの概念的背景については、エージェント型コーディングが開発チームにとって何を意味するかの解説で用語を整理しています。

リポジトリと worktree の習慣もそのまま。Sharkly は接続された Computer 上の隔離された worktree でエージェントを実行します。あなたが頼りにしていたのと同じ分離を、ローカルのカードではなく共有の Task に結び付けた形です。フロントエンド、バックエンド、バグ修正、テストカバレッジを衝突させずに同時に進められます。これこそ「エージェントごとにボード」モデルが存在した理由そのものです。

欠けていたレビューレイヤーを追加する。ここが新しい部分です。実行、ブロッカー、結果、フォローアップの議論が Task のタイムラインに戻り、チームが見られるようになります。Agent は調査し、実行し、テストし、報告します。人は方向性を定め、権限を与え、結果を承認します。自動化はチームの判断が必要なところで止まり、完全なコンテキストと検証可能なエビデンスを備えたデリバリーとして戻ってきます。この最後の一文こそ、ローカルボードが果たせなかった契約です。その向こう側にチームがいなかったからです。

つまり移行は積み上げ式です。Computer を1台接続し、すでに持っているランタイムを Sharkly に指定し、チームがすでに理解しているプロセスを作り直すことなく作業を流し始めます。ボードはエージェントを並列で動かすことを教えてくれました。Sharkly はそこにチームの残り全員を招き入れます。

ソロのボードからチームのシステムへ：Crews、Sprints、Projects

実行が共有されると、単一ユーザーのボードにはなかった3つの機能が開けます。

Crews：1体以上のエージェントを必要とする作業のために。Crew は、1体のリーダー Agent が取りまとめる、People と Agents の再利用可能なグループです。小規模で明確な作業には不要です。Task を単一の Agent に割り当て、動く部品をゼロに保てばよいのです。Crew を使うのは、リーダー Agent がより広いゴールを解釈し、他の Agent メンバーを招き入れ、その結果を1つの Task にまとめる必要があるときです。これが率直なルールです。Crew は作業が本当に多面的なときにはてこの支点になり、そうでなければただの重荷です。

Sprints と Projects：1枚のカードを超えて生き残るトラッキングのために。ローカルボードは今日目の前にあるタスクを示します。Sprint は、一定期間にわたる作業群の完了状況、担当、依存関係、スコープ変更、ブロッカーを追跡します。People と Agents のハイブリッドチームにとって、これは「今週エージェントがいくつか作業をした」と、実際に報告できる計画との違いです。開発チームのための AI エージェントオーケストレーションの入門記事では、チームのスループットがモデルではなく調整レイヤーで決まる理由を解説しています。

チームの透明性：画面共有ではなくデフォルトとして。コンテキスト、進捗、ブロッカー、結果、人間によるレビューを、リクエストからリリースまで見える状態に保ちます。ローカルボードでは、可視性は自分のモニターまででした。共有システムでは、てこの効果は AI チャットを増やすことからは生まれません。役割、ルール、コンテキスト、ワークフローを共有し、1つの良いセットアップをチーム全体が再利用できる力に変えることから生まれます。

Vibe Kanban と Sharkly の公平な比較

この表はスコアボードではなく分業として読んでください。無料のローカルボードだけを求めているソロ開発者なら、コミュニティが保守するプロジェクトが今も正解かもしれませんし、そこにとどまることに何の恥じらいも要りません。実行を共有し、割り当て可能にし、レビュー可能にする必要があるチームにとって、ボードはいずれ手狭になる運命にあり、同じランタイムにチームを足して使い続けられるのが Sharkly です。Sharkly をダウンロードして Computer を1台接続すれば、実際の作業で違いを確かめられます。

ローカルボードから移行するときによくある失敗

• 単純な置き換えと考える。探しているのは別のボードではありません。ボードには決してなかったチームのレイヤーです。代替ツールが列とカードを再現するだけなら、何も解決していません。
• 速さを求めて worktree の分離を捨てる。分離があるからこそ並列エージェントは衝突しません。維持しましょう。エージェントに作業ディレクトリを共有させるツールは、解決済みの問題を再び呼び戻しているだけです。
• 単一エージェントの作業に Crew を追加する。Crew に手を伸ばすのは、ゴールが本当にリーダー Agent によるメンバーの調整を必要とするときだけです。スコープが明確なタスクなら、1体の Agent と動く部品ゼロが正解です。
• 生産性を感じたくてレビューのゲートを飛ばす。このレイヤーの要点は、人が結果を承認することです。速いからといってエージェントの diff を未レビューでマージすると、システムが存在する理由である安全性をそのまま手放すことになります。
• 初日にすべてを移行する。実際の要件1つと低リスクの Task 1つから始めましょう。ループが回ることを確かめてから広げてください。

まとめ

Vibe Kanban は、守る価値のあるパターンを証明しました。エージェントは並列で、それぞれの worktree に分離されて動くのが最もよく、レビューは正式な工程であるべきだということです。このパターンは今や下限であり、それを放棄する Vibe Kanban の代替は後退です。

• エージェントごとにカード1枚のモデルは正しかった。並列で worktree に分離されたエージェントと diff レビューが正しい形です。
• ローカルボードは1人・1台のマシンで終わります。共有される作業には共有されるレコードが必要です。
• Sharkly はランタイム、リポジトリ、worktree の習慣をそのままに、その周りにチームのレイヤーを加えます。
• Task はゴール、ランタイム、進捗、ブロッカー、diff、レビューを1か所にまとめます。
• Crews、Sprints、Projects は並列の実行を、チームが報告に使える計画へと変えます。
• Agent は調査・実行・テスト・報告を行い、人は方向性を定め、権限を与え、結果を承認します。

次にコーディングエージェントをどこで動かすかを選ぶなら、チームがすでに使っているツールはそのままに、実行を割り当て可能で追跡可能にするレイヤーを加えましょう。Computer を1台接続し、Agent を1体作成し、退屈な作業を1つ割り当ててみてください。あとはチームの他のメンバーに、作業が Task に戻ってくる様子を見せればいいのです。Sharkly から始められます。各概念の詳細はドキュメント docs.sharkly.ai で解説しています。

よくある質問

Bloop のサービス終了後も Vibe Kanban は使えますか？はい。プロジェクトはオープンソースで、今もローカルで実行できます。企業が運営していたクラウド機能は削除され、修正や更新はコミュニティのコントリビューターに依存するようになりました。ソロでの利用なら問題ないかもしれませんが、デリバリーをこれに頼るチームは保守リスクを天秤にかける価値があります。

Sharkly は Claude Code や Codex の代替ですか？いいえ。Sharkly は Claude Code、Codex、その他の実行ツールの代替ではありません。実行を担うのはそれらのランタイムです。Sharkly はその周りに、共有タスク、Computer、コンテキスト、コントロール、レビューのレイヤーを加えます。使うエージェントはこれまでと同じです。

エージェントを並列 worktree で動かすことを諦める必要はありますか？いいえ。Sharkly は接続された Computers 上の隔離された worktree でエージェントを実行します。「エージェントごとにボード」モデルが頼っていたのと同じ分離です。フロントエンド、バックエンド、テストを衝突させずに同時に進められます。基盤となるパターンについては複数の Claude Code エージェントを並列で実行する方法をご覧ください。

ローカルボードからの移行では実際に何をするのですか？ランタイムとリポジトリはそのままです。Computer を接続し、すでに使っている実行ツールを Sharkly に指定し、作業を共有 Task として流し始めます。モデルの利用は、各ツールに設定済みのサブスクリプションや API キーを通じて続くので、課金は変わりません。

Sharkly を使うべきでないのはどんなときですか？1人で1台のマシンを使い、他の誰も作業を見たりレビューしたりする必要がないなら、ローカルボードで十分です。Sharkly がその価値を発揮するのは、2人目がエージェントの実行を割り当てたり、拾ったり、レビューしたりする必要が出た瞬間です。

カードと Task の違いは何ですか？ローカルボードのカードはあなたのもので、あなたのマシン上にあります。Task はチームの共有レコードです。ゴール、割り当てられた Agent、ランタイム、進捗、ブロッカー、diff、人間によるレビューを保持し、実行結果がそこに戻ってきます。