Agent を本当のチームメンバーにする

計画づくり、トリアージ Agent、コンテキスト管理からタスクボードの運用まで、実践から得たノウハウです。

ここで紹介するプラクティスは、すでに Syfo を試し始めていて、Agent をチームの日常業務に取り入れようとしている方に向けたものです。チャンネルの分け方や Agent の数については、まずチームへの導入とチャンネルとコラボレーションを参照してください。このページでは、日常のコラボレーションで特につまずきやすく、効率化の効果も大きい習慣を取り上げます。

ひとことで言うと、人は目的と原則を示し、やり方は Agent に任せる、です。あなたはツールを操作しているのではなく、自ら成長するチームを率いています。要件、判断、受け入れ確認に力を注ぎましょう。

Agent に計画づくりを手伝ってもらう

設定方法を自分で無理に考える必要はありません。計画づくりそのものを Agent に任せましょう。

業務、フロー、組織構成を Agent に説明し、チャンネルの分け方、各チャンネルに置く Agent、1 つのタスクにおおよそ何体の Agent を割り当てるかを提案してもらいます。
目的と制約（たとえば「N 個のシステムをリファクタリングする、期間は何日、人数は何人、使えるリソースは何か」）を伝えると、Agent は計画を作り、各 Agent の役割とプロンプトまで提示してくれます。新しく作成して貼り付ければ、すぐに動かせます。
ずれがあればいつでも修正してください。Agent はそれを長期記憶に書き込み、使うほどチームに合っていきます。

これは「自分でツールを操作する」から「Agent のチームを率いる」へ移るための重要な一歩です。

トリアージ Agent・常駐 Agent をうまく設計する

複数のチャンネルで協働する場合、情報の振り分けと調整を担う「常駐」Agent が 1 体必要になることが多くあります（病院の受付案内のような存在です）。うまく活用するための原則がいくつかあります。

職責を 1 つに絞る：常駐 Agent は振り分けと調整だけを行い、具体的な開発はしません。開発の細部に入り込むと、タイミングよくトリアージできなくなり、メッセージが順番待ちになります。
作成者が管理する：Agent の作業原則は owner がチューニングし、制約を設けます。ほかの人が勝手に変更しないようにします。直属の manager がいる同僚と同じで、フィードバックは manager に集約します。
ルールを積み上げず、枠組みを与える：ルールを何百個も積み上げないでください。Agent と一緒に「判断の枠組み + ルーティングルール」を抽象化し、その枠組みに沿って動かします。ずれたらその都度修正します。
部門横断の意思決定は 1 つのグループで行う：複数の部門にまたがる意思決定は、各部門のトリアージ Agent と人間の意思決定者が同じチャンネルで議論し、合意したら各自が自部門に持ち帰ってタスクに分解します。1 体の Agent に 2 つの大きなシステムをまたいでトリアージさせないでください。

コンテキストを管理して、コストも抑える

Agent は常駐セッションなので、長く動かすとコンテキストが蓄積し、動作が遅くなります。

手が空いているときにリセットする：アイドル状態のときに、手動または一括でセッションをリセットします。長期記憶は失われず、Agent は再起動後に前回の作業地点まで復帰できます。リセットすると進行中のタスクが中断されるため、手が空いているときに行ってください。一括操作は、コンピューター詳細ページの「エージェントを再起動します」または「リセットと再起動」から行えます。
コンテキストの長さを抑える：多くのタスクでは、非常に長いコンテキストは必要ありません。コンテキストが長いほど、1 回のリクエストのコストと遅延が大きくなります。Agent 詳細ページの「使用法」タブで現在のセッションのコンテキスト使用量を確認し、リセットするかどうかを判断できます。
用途に応じてモデルを選ぶ：モデルにはそれぞれ、コーディング、文章作成、デザインセンスなどの得意分野があり、価格や速度も異なります。まず同じタスクを 2〜3 個のモデルで試し、結果と使用量を比べてから、デフォルトを決めましょう。

役割分担ができていれば、Agent にリセットできる「空き時間」が生まれます。そうでなければ Agent は常に忙しく、深夜まで手が空きません。

Agent と一緒にコードを書く

diff より結果を見る：モデルの能力が十分であれば、コードを 1 行ずつ読むより、最終的な動作結果を見て受け入れ確認するほうが効率的です。変更内容を見たいときは 2 画面を使いましょう。1 つの画面で Agent と会話し、もう 1 つの画面で VS Code を使って git diff とコミット履歴を確認します。Agent 詳細ページの「アクティビティ」タブで、ツール呼び出しや推論を確認することもできます。
コード品質は別のタスクにする：機能開発とは別に、長いファイルの分割や保守性向上のための整理を定期的に Agent に任せます（1 ファイルを数百行以内に抑え、複数の Agent が同じファイルを変更して衝突するのを防ぎます）。普段からコーディング規約も決めておきましょう。
バージョン管理は git、並行作業は worktree で：git はバージョン管理とロールバックの土台です。複数の Agent が同じリポジトリで並行して開発する場合は、git worktree を使います（Agent にひとこと伝えるだけで十分です）。worktree はディスク容量を多く使うため、ルートディレクトリにインストール済みの依存関係をシンボリックリンクで共有するか、使い終わったら削除しましょう。

自律的に進める範囲と再確認のルールを決める

Agent は自分でトラブルシューティングできます（たとえばデプロイに失敗したら、自分でログを取得して修正します）。Agent が何度も止まって確認を待つ場合、たいていは境界がはっきり決まっていないか、コンテキストが長すぎることが原因です。

作業のルールをはっきり伝える：リスクの低い操作は自律的に進めさせ（自分でログを見て解決できることは聞かなくてよい）、リスクの高い操作だけ確認させます。
リスクの高い操作は再確認する：本番環境の変更、データの削除、リリース、外部への約束、権限の変更など、取り消せない、または影響の大きい操作については、誰が何を確認するかを決めておきます。確認ルールの書き方や、どの操作で承認カードが自動生成されるかは承認を参照してください。
信頼に応じて調整する：長く一緒に作業して信頼関係ができたら、通常の場面では確認を減らし、リスクの高い場面でだけ確認を残します。

タスクボードの運用を Agent に任せる

タスクボードの運用は Agent に任せ、人は要件を出すことと受け入れ確認だけを行います。
すき間時間には、Agent にタスクボードを棚卸しさせたり（進んでいないもの、ステータスを更新すべきもの）、git を棚卸しさせたり（自分の名前でまだマージされていない変更）できます。
あるタスクを「保留にして今は進めない」ようにしたい場合は、タスク間の依存関係で順序を表します。依存先で止まっているタスクは「ブロック中」と表示されます。タスクのステータスを変更すると対応する Agent に通知されますが、これは正常なコラボレーションの仕組みです。