Redditの r/ClaudeAI で、興味深い投稿が話題になっていました。
Claude Codeのスキル機能を使い、AIエージェント専用のカンバンボードを構築したという内容です。
一見すると「またJiraクローンか」と思うかもしれません。
でも実際はそうじゃないんですよね。
このツールは人間のためではなく、AIエージェントのために設計されたもの。
そこが決定的に違います。
本記事では、この投稿とコミュニティの議論を参考にしています。
そして、AIエージェントの文脈管理という課題と、その解決策について考えてみます。
バイブコーディングのボトルネックは「自分自身」
バイブコーディングという言葉が定着してきました。
AIにコードを書かせながら、感覚的に開発を進めるスタイルのことです。
この投稿者も数ヶ月間、Claudeで集中的にバイブコーディングを行っていたそうです。
そこで、ある問題に気づきました。
開発を遅くしているのはAIではなかったのです。
セッションをまたいだときに「何がどうなっているのか」を見失う、自分自身がボトルネックでした。
マークダウンファイルでメモを取っていたものの、すぐに管理不能になったとのこと。
この経験、AIを使った開発に取り組んでいる方なら共感できるのではないでしょうか。
4つのエージェントが回すパイプライン
投稿者が構築したシステムは、4つのAIエージェントによる自動パイプラインです。
まず、カードを作成して要件を書きます。
スクリーンショットを添付してもいい。
そしてコマンドを1つ打つ。
あとは自動で進んでいきます。
最初に、Planner（Opus）が要件を読み込みます。
そして実装計画を作成し、レビューへ回す。
次にCritic（Sonnet）がその計画を読んで、
承認するか差し戻すかを判断します。
差し戻された場合、Plannerが修正して再提出。
承認されると実装フェーズへ移ります。
Builder（Opus）が計画に沿ってコードを実装し、コードレビューに送る。
最後にRangerがリント、ビルド、E2Eテストを実行。
すべてパスすればコミットし、カードを完了にします。
このループが自動で走るわけです。
並列で3枚のカードを同時処理した実績もあるとのこと。
ただし投稿者自身は「正直、追いかけるのが大変なので1〜2枚にしている」と語っていました。
本質は「自動化」ではなく「文脈の蓄積」
ここが肝心なポイントです。
投稿者が本当に重視しているのは自動化そのものではありません。
文脈管理です。
各カードには完全な記録が残ります。
要件、計画、レビューコメント、実装メモ、テスト結果、コミットハッシュ。
1週間後にコードベースに戻ってきても、git履歴を掘り返す必要がない。
カードを見れば、すべてわかる。
投稿者のメンタルモデルはこうです。
Claudeは次のトークンを予測している。
だから、与えるコンテキストの質が高いほど、出力も良くなる。
特にエージェント間のハンドオフを含むマルチステップパイプラインでは、文脈を丁寧に管理することこそが勝負どころだと。
この視点は、バイブコーディングの本質を突いています。
自由に、感覚的にコードを書くのは楽しい。
しかし、何を頼むのかを事前にしっかり考えないと成果は出ません。
カンバンの構造が、その思考を強制してくれるのです。
コミュニティが指摘した「批評家」の弱点
Reddit上では活発な議論が展開されていました。
特に興味深かったのは、Criticエージェントの「ゴム印問題」です。
あるユーザーが指摘していたのは、Criticの判断が二値的すぎるという問題でした。
承認か却下か。
中間の段階がありません。
そこで提案されたのが、構造化された評価ルーブリックの導入です。
「明確性」「テスト可能性」「可逆性」といった項目を1〜5で採点させる。
こうすれば、Plannerへのフィードバックがより具体的になるという発想でした。
さらに面白い指摘もありました。
ルーブリックの項目にうまく点数をつけられないこと自体が、シグナルになるという話です。
つまり、要件の定義が不十分だということ。
評価の失敗が、Plannerにコミットする前の問題検出として機能するわけです。
「意思決定ログ」の追加も提案されていました。
Plannerがなぜその設計判断を下したのかを、1文で記録するフィールドです。
今の実装では「何をしたか」は残る。
しかし「なぜそうしたか」が残りません。
この情報があれば、途中で戻ってきたときの再理解コストは大幅に下がるでしょう。
大規模プロジェクトへの適用限界
一方で、懐疑的な意見も出ていました。
ある開発者は、大規模プロジェクトには不十分だと指摘しています。
高レベルの計画を低レベルに分解する多層的な能力が必要になる。
加えて、アーキテクチャ全体のメンタルマップも不可欠です。
そうした場面では、AIは迷子になりがちだと。
この指摘には説得力があります。
自分自身がアーキテクチャの全体像を持っていなければ、AIに適切な指示は出せない。
漠然とした方向性でも構わないが、生産的な方向を指し示す必要はある。
それがなければ、Claudeは自分自身の計画にゴム印を押すだけになってしまう。
そういう趣旨の意見でした。
既存ツールとの比較：何が違うのか
コミュニティでは「既存ツールでいいのでは？」という声も多く上がっていました。
たとえば、Jira MCPでClaude Codeと連携させている人がいます。
Linearでマイルストーンやissueを自動管理している人もいる。
さらには、Gitea上にボードとissueを直接作るエージェントが誕生したという報告もありました。
Backlog.mdでタスク管理しているという声も。
投稿者の回答はシンプルです。
これらのツールはチーム管理向けである。
一方、このカンバンはAIエージェントの管理に特化している。
そしてローカルのSQLiteデータベースで動くため、SaaSへの依存がない。
プロジェクトごとに1ファイルで完結します。
OSSとしてMITライセンスで公開されています。
スキルファイルはマークダウンで書かれているため、自分のスタックに合わせたカスタマイズも容易です。
実際に「コーディングではなくリサーチ用にチューニングしたい」というコメントも寄せられていました。
AIエージェント時代のプロジェクト管理とは
この投稿が示唆しているのは、プロジェクト管理の対象が変わりつつあるという事実です。
従来のプロジェクト管理ツールは、人間の作業を追跡するものでした。
しかし、AIエージェントが計画から実装、テスト、コミットまでを自律的に行う世界では、状況が異なります。
管理すべき対象は、エージェントの行動と文脈になる。
そこに最適化されたツールが必要になるのは自然な流れでしょう。
もちろん、このアプローチが万能ではありません。
大規模プロジェクトでの限界や、Criticの評価精度など、改善の余地は多く残っています。
プロンプトの微調整でCriticの挙動が大きく変わるという報告もあり、まだ試行錯誤のフェーズです。
まとめ
バイブコーディングの真のボトルネックは、AIの能力ではなく文脈管理にある。
この投稿が伝えているのは、その一点です。
AIエージェントに良い仕事をさせたければ、良いコンテキストを与える。
そのコンテキストを構造的に蓄積し、セッション間で引き継ぐ仕組みを作る。
カンバンボードは、そのための一つの解答でした。
既存のプロジェクト管理ツールで十分だという人もいるでしょう。
それも正しい判断です。
大切なのはツールの選択ではありません。
AIに渡す文脈を意識的に管理するという考え方そのものにあります。
AIとの協業において、あなたはどのように文脈を管理していますか？
この問いへの答えが、開発の生産性を大きく左右する時代に入っています。
