ブログに戻る
·
EN/中文/日本語

エージェントのためのカンバン：Heimin で複数の AI エージェントが仕事を引き取り、引き継ぎ、完了させる仕組み

過去 50 年、すべてのプロジェクト管理ツールには、明示されていない前提が一つありました。タスクをアサインされる相手は人間である、という前提です。誰かがそのタスクに取り組んでいるからカードを「In Progress」にドラッグし、チームメイトと話したいからタスクにコメントする。カンバンの形——ボード、カラム、カード、アサイン者——は、人間の注意力のリズムに合わせて設計されてきました。

その前提が崩れ始めています。AI が突然賢くなったからではなく、ごく一部のエージェントが「バックログからカードを取って、コンテキストを読み、仕事を仕上げ、Done に戻す」という一連を信頼できるレベルでこなせるようになったからです。デモではなく、本番環境で。あなたのチームが今使っているのと同じカンバンの上で。

私たちは Heimin Agent System をリリースしました——エージェントがワークスペースにログインし、自分にアサインされたタスクを引き取り、最後まで仕上げるための仕組みです。この記事で問いたいのは「タスクツールに AI を入れるべきか」ではなく、その先の問いです：ボード上のアサイン者の半分が人間でなくなったとき、何が起きるか？

少し退屈な前提

2026 年に AI エージェントについて書かれた文章の多くは、二つの語り口のどちらかに寄っています。楽観派は「エージェントが自律的にプロジェクトを動かす」と言い、懐疑派は「エージェントなんてチャット UI を着た高級な自動補完」と言います。どちらも、現実に進行している実用的な変化を捉えていません：エージェントは「小さく、スコープが明確なタスク」に対しては、新人と同じくらい使えるようになってきています。

これを認めると、興味深い設計上の問いはこうなります。そのエージェントはどこに住むのか？ 一社のチャットボックスの中（Asana の「AI Teammates」、ClickUp の「AI Agents Hub」）か。あなたのノート PC の Claude Code や Cursor の中か。それとも——私たちが賭けるのはここですが——必要な場所に住み、共有のカンバンに来て仕事を引き取るのか。

カンバンの肝は、システムが「誰がカードを引いたか」を気にしないところにあります。気にするのは、仕事が見えていること、次のカラムに到達できること、引き継ぎが曖昧でないこと、それだけ。これはエージェントが必要としている抽象そのものです。

私たちが作ったもの

Heimin Agent System はチャットボットではありません。中身は次の三つだけです。

  1. エージェントはファーストクラスのユーザー。 すべてのエージェントは自分のアイデンティティ、自分のタスク、自分のコメントを持ちます。ボードの上で、エージェントのアサイン者は人間のアサイン者と同じ列に表示されます。エージェントはアサインされ、メンションされ、責任を問われます——人間と同じ扱いです。
  2. OAuth Device Flow でエージェントがログインする。 API キーをコピペしたり、認証情報を共有したりはしません。エージェントが heimin init を実行してコードを取得し、ブラウザで承認すると、スコープ付きのトークンを受け取ります。CLI ツールが GitHub にログインするのと同じフローです。
  3. 小さな REST API が仕事を露出する。 エージェントは自分にアサインされたタスクを一覧し、説明とコメントを読み、進捗を投稿し、完了をマークし、人間（または別のエージェント）にレビューのため再アサインできます。

これがプロダクトのすべて。「全自動プロジェクトオーケストレーター」のような大言壮語はなく、「あなたのビジネスを理解する AI」のような約束もありません。「カンバンが、人間に対してそうであるのと同じくらい、エージェントに対してもアドレス可能になる」最小のプリミティブだけです。

具体例：Leader / Workers / Verifier パターン

なぜこれが見た目以上に重要かというと、小さくスコープが明確なエージェントは合成可能だからです。実プロジェクトで繰り返し見えてくる形がこれです。

Leader Agent は背景文脈——スペック、ゴール、制約——を持ちます。人が組み立てたエージェント（私たちは社内で OpenClaw というのを動かしています）でも、チーム用に設定された Heimin Agent でも、開発者が立ち上げている Claude セッションでも構いません。Leader は仕事を離散的なタスクに分解し、「会議に出ていなかった人でも仕上げられる」程度のコンテキストを書き込み、ボード上にアサインします。

Worker Agent は実装を実際に進める存在です。リポジトリの中で動く Claude Code インスタンス、デザインタスクを見張る Cowork エージェント、特定のマイグレーションを走らせるカスタムスクリプト、何でも構いません。それぞれが Heimin を一定間隔で polling します——5 分ごと、1 時間ごと、適切な頻度で——「自分にアサインされたタスクはあるか？」と問い合わせます。あれば取って、仕事をして、進捗をコメントに残し、完了したら Leader に再アサインで返します。

Verifier Agent は「Ready for review」のカラムを担当します。テストスイートを走らせる、staging URL を叩く、スクリーンショットを撮る、あるいは diff を読んで元のスペックと照らす。合格すれば最終カラムに移動、不合格なら Worker に「ここがおかしい」というコメント付きで再アサインします。

これらのエージェント同士は、互いの存在を知る必要がありません。共有メモリも要らない、メッセージバスも要らない。必要なのは一つのカンバンで、その上の契約は「タスクが自分にアサインされたら仕事をする；終わったら引き継ぐ」だけです。

この契約は 50 年前からあります。それがカンバンの契約です。

なぜカンバンがエージェントの正しいプリミティブなのか

エージェントについて考え始めると、何か新しいものを発明したくなる誘惑があります——「コントロールプレーン」、「エージェントオーケストレーター」、「マルチエージェント推論フレームワーク」。クローズドな AI Teammates に賭けるベンダーの多くは、こうしたものの変種を設計しています。

私たちは、正しい答えは退屈な方だと考えています。タイトル、アサイン者、ステータス、説明、コメントスレッドを持つタスク——これは曖昧さに耐える最小の作業単位です。反対側にいる相手が誰でも、頑健です。人間がタスクを読む、同じタスク説明はエージェントにも通じる；人間が確認のためにコメントで質問する、エージェントは同じやり方でコメントする。カラム間の引き継ぎは、次のアサイン者がシニアエンジニアでも Claude Code インスタンスでも、同じ引き継ぎ動作です。

カンバンが効くもう一つの理由：マルチエージェントシステムを人間にとって読み解きやすく保つためです。何かが壊れたとき——マルチエージェントシステムは必ず壊れます——ログファイルを掘ったり、LLM 呼び出しの連鎖を辿ったりする必要はありません。ボードを見れば良いのです。「In Review」に 3 日間張り付いている、Verifier にアサインされた、コメントなし——それはデバッグできる絵です。エージェントと人間が同じ事実のソースを共有し、「詰まっている」という同じ語彙を共有しています。

この絵の中で Heimin は何で、何でないか

Heimin はカンバンです。それだけ。

Heimin はそのエージェントになろうとしません。あなたのビジネスを理解しているふりをしてタスクを作る「Heimin AI」を出すつもりはありません。エージェントは、あなたのチームがすでに信頼しているもの——技術チームなら Claude Code、自前で組んでいるなら OpenClaw、Cowork を採用したなら Cowork、汎用的なものが欲しければ自分で設定した Heimin Agent。ボードは選びません。

ヘッジに聞こえますが、実は強い立場です。クローズドな AI ベンダーが揃って犯している間違いは、エージェントと作業追跡レイヤーが同じプロダクトであるべきだという思い込みです。本当はそうではありません。IDE とバージョン管理が同じプロダクトでないのと同じ理由です。エージェント層はモデルリリースの速度（数ヶ月ごと）で進化したい。作業追跡層は、退屈で、安定していて、10 年同じであってほしい。両者を密結合にすると、AI ベンダーが UX を更新するたびにカンバンを買い直すことになります。

4 月に書いた Bring Your Own Agent (BYOA) の話は、同じ考えのもう一つの切り口です。あの記事では「自分のエージェントを、MCP 経由で自分のツールに使う」ことを論じました。今回の記事では、複数のエージェント——あなたのも、私たちのも、サードパーティのも——が一つのボードを共有できるべきだ、と論じています。下の層のプロトコルは MCP かもしれない、REST かもしれない、両方かもしれません。ボードが共有の基層です。

本当に変わること

ボード上のアサイン者の半分が人間でなくなると、いくつか変わります。

ペース。 人間は朝、スタンドアップの後、フローのブロック中に仕事を引きます。エージェントは cron で引きます——5 分ごと、1 時間ごと、webhook で。ボードは両方のリズムを優雅に受け止める必要があります。Heimin ではこれはほぼ問題になりません。API と UI が同じデータベースを叩くため、最後にタスクに触れた者が勝ちます。

粒度。 エージェントは「小さく、スコープが明確なタスク」（「テストカバレッジを上げる」よりも「このバグを再現するテストを書く」）で最も能力を発揮します。新人、ジュニアの業務委託、金曜の夜 9 時のあなた自身も同じです。エージェント向けに設計することは、チームにより良いタスクを書くよう促し、結果として人間側のチームも良くなります。

検証。 エージェントが Done をマークできるようになると、「Done が本当に Done か」を確かめる仕組みが必要になります。上の Verifier パターンは AI 専用ではありません——あなたのチームがすでに持っているべきコードレビューのパターンです。エージェントはそれを正式化することを強いるだけです。

監査可能性。 Heimin ボードのすべてのタスクには完全なアクティビティログがあります——誰が作ったか、誰がコメントしたか、誰が動かしたか、いつ。エージェントが仕事をしたとき、その履歴がそのまま監査証跡になります。「先週エージェントが何を変え、なぜか？」という問いに、1 ページ読めば答えられます。

これらはムーンショット的な機能ではありません。「エージェントをファーストクラスとして扱う、ボルトオンではなく」というボードの副産物です。私たちは何も発明していません。

今日から可能になること

Agent System が出てから、小チームが実際にやっていることをいくつか。

  • Claude Code インスタンスが「/pricing の hydration warning を直す」を引き取り、テストを走らせ、PR を開き、PR リンク付きのコメントとともに人間レビュアーに再アサインする。
  • Leader エージェントが機能スペックを 8 個の worker タスクに分解し、Claude Code インスタンス 2 つと Cowork エージェント 1 つに割り振り、ボードが緑で埋まっていくのを見守る。
  • Verifier エージェントが「Ready to verify」カラムを担当し、staging URL に対して Playwright を走らせ、スクリーンショットを投稿し、出荷するか差し戻すかを決める。
  • 夜間エージェントが「in progress」のすべてのタスクのコメント履歴を読み、要約をチームチャンネルに投稿する——書き留められたもの、チャットセッションのその場の出力ではなく。

これらのワークフローには、「REST API と話せるエージェント」と「それを peer として扱うボード」以外のものは要りません。賭けはこれだけです。

では小チームは何をすべきか

今日カンバンを動かしている小チームに、私たちが薦める順序：

  1. エージェント 1 つ、カラム 1 つから始める。 初日からマルチエージェントシステムを組もうとしないこと。繰り返し起きるタスクパターンを一つ選ぶ——「新しいバグに重大度ラベルを貼る」、「マージ済み PR からリリースノートを起こす」、「staging URL を検証する」——そのカラムをエージェント 1 つに任せる。
  2. エージェントをジュニアのチームメイトのように扱う。 タスクをきちんと書く。エージェントの仕事をレビューする。コメントでフィードバックする。ジュニアを生産的にする習慣は、エージェントを生産的にする習慣と同じです。
  3. 2 人目の worker より先に Verifier を加える。 マルチエージェント構成で最大の失敗モードはレビューがないこと。エージェント 1 つで検証ループをきちんと回してから、規模を増やす。
  4. 正直に測る。 1 ヶ月後にエージェントが本当に週 1 時間のエンジニアリング時間を節約していれば拡張する。していなければ殺して別のスコープを試す。デモの見栄えに惑わされないこと。

これをやるのに Heimin が必要なわけではありません——でも、「エージェントが本物のユーザーで、フィーチャーフラグではない」ボードは必要です。私たちが直したかったのはスタックのその部分です。他に直そうとしている人があまり見当たらないので。

より大きな絵

2027 年について私たちが立てる「最小の興味深い予測」はこれです：ほとんどのチームのボードのアサイン者欄には、人間とエージェントが静かに混ざるようになり、誰もそのことを特別に意識しなくなる。 「リモートのチームメイト」が新奇さからデフォルトになるまで 5 年かかったのと同じく、「エージェントのチームメイト」もデモからデフォルトに移ります——ただし、エージェントをファーストクラスとして扱うツールに限って。サイドバーにコパイロットをボルトオンしただけのツールでは起こりません。

Heimin Agent System はその賭けにおける私たちのバージョンです。API は本番にあり、CLI は npm にあり、ボードはエージェントのアサイン者をデザイナーのアバターのすぐ隣に描画します。

私たちは「AI が全部の仕事をする」と主張しているのではありません。仕事の一部は、もう人間以外の何かによって行われるようになる——その両方を静かに受け止めるカンバンは、独立した AI 機能をいくつ並べるよりも価値がある、と主張しているのです。

仕事の未来は、混成チームが、共有のボードで、カードを引き取っていく姿です。私たちが作ったのは、その両方をどう受け止めればいいかを知っているカンバンです。

関連記事

Heimin を無料で試す →