Kavor で CodingAgents を選び、役割を定義する方法

CodingAgent を選ぶとき、provider から始めるべきではありません。最初に決めるのは、その Agent が 担う責任です。

一つのセッションで問題を分析し、Specification を書き、実装し、レビューし、リリースを準備すること はできます。参加者が少ないため単純に見えますが、異なる目的が同じコンテキストウィンドウに集中します。 実装はそれ以前の調査をすべて抱え、レビューはコードを書いた人と同じ前提を引き継ぎ、リリース準備は、 本来セッションの外に保存されているべき意思決定と注意を奪い合います。

Kavor では、仕事を孤立したチャットに分断せず、責任を複数の CodingAgents に分けられます。参加者は Specifications、Files、Sticky Notes などの永続的なリソースを中心にグラフを作ります。Connections はコンテキストと能力を見える状態にし、メッセージは handoff と議論を支え、最終判断はあなたに残ります。

四つの役割が仕事のグラフを作る様子を見る →

Agent ではなく、仕事から始める

Canvas に CodingAgent を追加する前に、その Agent がなぜ必要なのかを一文で書きます。良い定義には 次の要素があります。

• 主な責任が一つあること
• 責任を果たすために必要なコンテキスト
• 生成すべき結果
• 停止すべき条件

「コードをレビューする」だけでは範囲が広すぎます。「実装を Specification の基準と比較し、 findings を記録し、コードを変更する前に停止する」なら、検証可能な役割になります。

同じ provider が別々のセッションで異なる役割を担うことも、異なる providers が同じ役割を担うことも できます。役割は仕事に属し、provider、モデル、effort はその仕事を実行するための設定です。

役に立つ四つの役割

すべてのタスクに以下の四役が必要なわけではありません。これは仕事を考えるための境界であり、 Agent のノルマではありません。

役割	主な問い	必要なコンテキスト	期待する結果
Analyst または Spec Writer	何を変え、どの境界を維持する必要があるか	問題、制約、意思決定、既存の動作	スコープと検証可能な基準を持つ明確な Specification
Implementer	契約の範囲内でどう変更を作るか	Specification、関連 Files、Terminal、Workspace の規約	検証と証拠を伴う実装
Reviewer	何が誤り、不完全、または危険か	Specification、変更、検証結果	具体的な findings、またはブロッカーなしというレビュー
Shipper	安全に届けられる状態か	Specification、レビュー、Git の状態、release 要件	リリース準備、残るリスク、人が判断するための証拠

小さな修正なら、一つの Implementer と人によるレビューで十分な場合があります。リスクが高い変更では、 Specification、実装、レビュー、リリースを分けることで、一つの思考経路がサイクル全体を支配する 可能性を下げられます。

役割を分けるために provider を分ける必要はありません。同じ provider の二つのセッションでも、目的と コンテキストは分離できます。異なる providers を組み合わせると別の視点や相関した盲点の軽減が期待 できますが、受け入れ基準の代わりにはならず、より良いレビューを保証もしません。

グラフが共有メモリになる

仕事を分けるために、同じ prompt を複数セッションへコピーする必要はありません。Kavor では共通の コンテキストが永続的な Nodes に置かれます。

• Specification は意図、スコープ、基準を保存します。
• Files は関連する情報源をフロー内に保ちます。
• Sticky Note は作業中の観察と意思決定を記録します。
• Terminal はコマンドと検証を実行する環境を提供します。
• CodingAgents はそれらのリソースを中心に異なる責任を担います。

共有メモリは、際限なく伸びる一つの会話履歴ではありません。Connections と Guardrails が許可する 範囲で参加者が参照・更新できる、明示的なリソースの集合です。セッションが終わっても、 Specification、Files、ノート、証拠は Workspace に残ります。

実装、レビュー、リリースのグラフは次のように表せます。

Specification
    ├── Spec Writer
    ├── Implementer ↔ Reviewer
    └── Shipper

永続コンテキスト: Files · Sticky Note · Terminal · Specification outputs

この図が表すのは責任の分割であり、Connections の向きではありません。Connections が自動で手順を 実行するわけではなく、関係、コンテキスト、能力を Canvas 上で確認可能にします。

コンテキストウィンドウも分ける

役割ごとに必要な問題の部分は異なります。Spec Writer は代替案や制約を調べる必要があり、 Implementer は合意済みの契約、関連ファイル、コード規約を必要とします。Reviewer に必要なのは基準、 diff、証拠であり、Implementer が解決策に至るまでの全会話ではありません。

この分割により、全コンテキストに対する有用なコンテキストの割合が高まります。

• 各 CodingAgent は、より狭く明確な目的を受け取ります。
• 共通リソースは prompts で繰り返さず、Workspace に置かれます。
• 詳細は必要なときに参照します。
• レビューは作者の積み上げた説明ではなく、契約と結果から始まります。
• 長いセッションが、完了した段階を抱え続けなくなります。

token 使用量の削減は利点になり得ますが、約束ではありません。適切に分けたグラフは重複または無関係な コンテキストを避けます。一方、Agent が多すぎ、メッセージが重複し、役割が曖昧なグラフは消費量を 増やします。目的は CodingAgents の数を最大化することではなく、各 token の責任を明確にすることです。

役割を決めてから provider、モデル、effort を選ぶ

責任を定義した後、タスクに合わせてセッションを設定します。利用できる場合は provider のネイティブな 制御を使ってモデルと effort を選びます。

四つの要因を考えます。

1. 曖昧さ: 問題自体を発見する必要があるか、明確な契約を実行するだけか。
2. リスク: 失敗は局所的で元に戻せるか、安全性、データ、アーキテクチャ、release に影響するか。
3. ツール利用: コードを調べてコマンドを実行する必要があるか、主に証拠を分析するか。
4. 調整コスト: より強いセッションなら handoff を減らせるか、それとも第二の視点が必要か。

高い effort は、曖昧な Specifications、アーキテクチャ判断、高リスクのレビューで意味を持つことが 多いです。機械的で範囲が明確なタスクは、速いモデルや低い effort で対応できます。実装は変更規模と、 コードを調べてテストする必要性によって変わります。

これらの指針を固定の担当表にしないでください。「Provider A は常に実装」「Provider B は常にレビュー」 という決め方は、エンジニアリング判断を習慣に置き換えます。役割ごとに設定を見直し、得られた証拠の 品質から学んでください。

会話を handoff と並行作業に使う

同じフローの CodingAgents が黙って作業する必要はありません。次の場合は Kavor のメッセージを使います。

• 実装をレビューへ渡す
• Specification の作者に説明を求める
• finding をブロッカーとして記録する前に議論する
• 修正を再検証へ戻す
• 並行して進められる独立した調査を調整する

良いメッセージには次を含めます。

• handoff の目的
• コンテキストを持つグラフ上のリソース
• 完了・検証済みの内容
• 受信者に求める行動
• 結果を保存する場所

会話は非同期で確認可能ですが、永続メモリの代わりではありません。handoff 後も残すべき意思決定は Specification、Sticky Note、または適切な output に戻し、メッセージの中だけに隠さないでください。

同じ決定を奪い合わず、同じ領域を変更しない作業だけを並行化します。二つの Agent が別の仮説を調査 したり、独立した観点をレビューしたりすることはできます。明示的な分担なしに二人の Implementers が 同じファイルを変更すると、通常は速度より調整コストが増えます。

避けるべきこと

サイクル全体を一つのセッションに集中させる

分析、Specification、実装、レビュー、release はそれぞれ問いと基準が異なります。一つのセッションを 使い続けると、その前提、ノイズ、盲点も保持されます。

サブタスクごとに Agent を作る

独立した責任のない分割は、メッセージ、重複コンテキスト、調整コストを増やします。異なる結果と停止条件 を説明できないなら、別の CodingAgent は必要ない可能性が高いです。

便利だから同じ設定を使い続ける

モデルや effort が不足すると曖昧または重要なタスクの質が落ちます。過剰な設定は機械的な仕事で時間と tokens を浪費します。役割のリスクと性質に合わせて選びます。

Implementer に自分の思考をレビューさせる

自己レビューで単純なミスは見つかりますが、独立性は生まれません。別の視点が重要なら、明確な基準と 検証可能な結果へのアクセスを持つ別セッションを使います。

Agents を孤立させる

セッション間で手動コピーすると、出所が断片化し handoff が隠れます。レビュー、確認、並行作業の調整には Kavor の会話を使います。

意思決定をメッセージだけに残す

メッセージは参加者を調整します。Specifications、Sticky Notes、outputs は Workspace が覚えるべき内容を 保存します。

最初に使える三つの構成

小さな変更

Specification、一つの Implementer、一つの Reviewer を使います。両方の Agent を必要なコンテキストに 接続し、実装とレビューを Sticky Note または Specification outputs に残します。これは最小限の有用な 構成です。本ページの動画では、同じ考え方がコンテキストを失わず Shipper まで広がる様子を示します。

高リスクの変更

Spec Writer、Implementer、Reviewer、Shipper を分けます。Reviewer に明確な基準と、実装を疑う独立性を 与えます。Shipper はリリースの証拠を準備しますが、公開するかどうかの判断はあなたが行います。

並行調査

二つの CodingAgents で異なる仮説や領域を調べ、三つ目の役割が結果を統合します。開始前に各発見の保存先 を決め、質問と handoff にはメッセージを使います。

開始前のチェックリスト

各 CodingAgent について確認します。

• 役割を一文で説明できるか。
• 観測可能な結果と停止条件があるか。
• グラフは必要なコンテキストと能力だけを提供しているか。
• provider、モデル、effort は曖昧さとリスクに合っているか。
• 誰と何のために話すべきかが明確か。
• 意思決定と証拠は会話の外に保存されるか。
• この CodingAgent の追加による独立性、並行性、品質の向上は、調整コストに見合うか。

良い Canvas は Agent が最も多い Canvas ではありません。責任、コンテキスト、handoff、証拠、意思決定が、 あなたを含むすべての参加者に明確な Canvas です。

最初のループを Kavor で完結させるでこの構成を作るか、 Kavor とは？で概念を確認してください。