チームに1体目のエージェントを入れるのは、個人の生産性の話だ。5体目になると、それは組織の話になる。その間のどこかで、あるグループは「AIを使うチーム」であることをやめ、「エージェントチーム」になる。人間とエージェントが同じボードで、同じタスクに取り組み、誰かが書き残さなければならなかったルールの下で働くチームだ。
この移行こそ、興味深い問いのほとんどが潜んでいるところだ。エージェントが実行した仕事のオーナーは誰か？ ボードが自ら更新されるようになると、スタンドアップでは何を話すのか？ 1人のレビュアーは何体のエージェントをさばけるのか？ 本ガイドでは、エージェントチームの構成、実際の仕事に触れても生き残る分業、そして真似する価値のあるワーキングアグリーメントを扱う。Sharklyは、こうした形のチームのために私たちが作っているプラットフォームであり、以下に挙げる失敗パターンは、その形が崩れていくのを目の当たりにしてきた中から生まれている。
TL;DR
エージェントチームとは、人間とAIエージェントが1つの共有システム上でそれぞれ割り当てられた作業を持ち、人間が方向性・権限・受け入れを担うグループだ。エージェントは調査・実行・テスト・報告を行う。人間は方向性を示し、権限を与え、結果を受け入れる。実務上の要件は、双方が読めるタスク記録、責任者とは別の実行担当者、誰かに届くレビューステータス、そしてエージェントが推測しなくて済む程度に書き出されたスコープだ。
エージェントチームは何でできているか
参加者は3種類あり、それぞれを正確に呼び分けると役に立つ。
人間はタスクを作成・更新し、コメントし、キュー項目を受け取り、作業を割り当てられ、エージェントの結果をレビューし、自分の役割が許す範囲で設定を管理する。説明責任を負える唯一の参加者だ。
エージェントは単発のプロンプトではなく、保存された作業構成だ。指示、Claude CodeやCodexといったランタイム、リポジトリ、環境、実行設定、紐づけられたスキルなどが含まれる。エージェントは人間というより、文書化された役割に近い。何が含まれるかはSharkly Agentsの解説記事で扱っている。
クルーは、調整が必要な作業のために複数のエージェントを1体のリーダーエージェントの下にまとめる。実行はリーダー優先で進む。リーダーがタスクとクルーの指示を読み、自分で処理するか、特定のメンバーを呼び入れる。この順序は、全メンバーがいっせいに動き出すのを防ぐためにある。詳しくはSharkly Crewsのガイドで説明している。
アクセス制御はその上に重なる。組織ロールが大まかな管理権限を決め、スペースのメンバーシップがどの作業領域に到達できるかを決める。エージェントも同じように、特定のリポジトリと特定のマシンにスコープが限定される。
機能する分業のかたち
Sharkly自身の契約は、強制できるほど狭く定義されているので良いデフォルトだ。エージェントは調査・実行・テスト・報告を行い、人間は方向性を示し、権限を与え、結果を受け入れる。
エージェントがどれほど有能になっても、4つの責任は人間に残る。
- 方向性。何に取り組む価値があり、どの順序で進めるかを決めること。
- コンテキスト。エージェントが行動できるスコープを書くこと。なぜその仕事が重要か、何がスコープ外か、関連するファイルと制約、そして完了をどうレビューするか。
- 受け入れ。証拠を読み、その作業が完了したと判断すること。実行が終わったことは、受け入れられた成果ではない。
- エスカレーション。エージェントが行き詰まった、間違えた、あるいは判断を要する疑問に突き当たったときに何をするかを決めること。
それ以外はすべて交渉の余地があり、特定の種類の作業に対する特定のエージェントの実績を、チームがどれだけ信頼するかによって決まる。
チームの中で仕事はどう流れるか
このループは短く、明示する価値がある。1つでも手順を飛ばしたチームは、1週間以内にそれを実感するからだ。
- 担当者が、明確な成果と受け入れ基準を伴うタスクを書く。
- タスクには、責任を負う人間の担当者と、実行担当としてエージェントまたはクルーが割り当てられる。これらは別々のフィールドであり、片方を変えてももう片方は変わらない。
- タスクを保留中のバックログ状態から動かすと、割り当てられたエージェントの準備ができ次第、実行が始まる。
- 実行は接続されたマシン上で、隔離されたディレクトリ内で行われ、進捗とブロッカーはタスクに返される。
- エージェントは作業を「人間の返信待ち」または「人間のレビュー待ち」の状態にし、それが責任者のエージェント受信箱に入る。
- 人間がトレースとdiffを読み、受け入れるか、コメントして続行するか、再割り当てする。
コメントは持続する会話だ。エージェントの準備ができたタスクへのコメントは次の実行をキューに入れられる。これにより、レビューフィードバックと実行が2つのシステムに分かれず、同じ動作になる。
うまく機能する3つの形
ペアを組む開発者。各開発者が、自分の反復作業用に1〜2体のエージェントを持つ。テストカバレッジ、依存関係の更新、20回はやったことのあるリファクタリングなどだ。チームにとっての利点は、そうしたエージェント定義が共有されることにある。新入社員は自分で一から作る代わりに、初日から5つの動くセットアップを引き継げる。
共有クルーを持つスクワッド。1つのクルーが、リリース準備やインシデントのトリアージなど、スクワッド全体が依存するあるカテゴリの作業を担う。リーダーエージェントがどのメンバーが貢献するかを決め、1人の人間がそのカテゴリをオーナーする。これは、レビュー能力が制約になるまで最も遠くまでスケールする形だ。
標準化するプラットフォームチーム。プラットフォームまたは開発者体験のグループが、複数のプロダクトチームのエージェント定義、スキル、マシン構成をオーナーする。プロダクトチームは作業を割り当て、プラットフォームチームはランタイム、権限、指示を最新に保つ。この形は自律性の一部を一貫性と引き換えにするが、エンジニアがおよそ30人を超えたら、たいていは正しい取引だ。
3つのどれも、組織を再編する必要はない。これらはエージェント構成を誰がオーナーするかというパターンであり、まさにその問いが、エージェントの能力がチーム全体で複利的に積み上がるか、個人のものにとどまるかを決める。
採用する価値のあるワーキングアグリーメント
タスクごとに、説明責任を負う人間を1人。4体のエージェントからなるクルーが作業する場合でも。いや、そういう場合こそ。
スコープはアサインの前に書く。結果をどう確認するかを誰も言えないなら、そのタスクはエージェントに任せられる状態ではない。このルール1つで、悪い実行のほとんどがなくなる。
レビューは余暇ではなく、予定されたキャパシティ。各レビュアーが1日にどれだけのエージェント作業を吸収できるかを決め、その数を守る。レビューされていないエージェントの結果が積み上がっていくのは、マージされていないプルリクエストと同じ負債であり、しかもより速く増える。
失敗した実行は診断する。再試行しない。実行ログを開き、まずタイトルと技術的な詳細を読む。似て見えるベンダーエラーでも、正反対の対処が必要なことがよくある。反射的な再試行は本当の原因を隠してしまう。
エージェント定義にはオーナーとレビュー日を決める。指示は陳腐化する。マイグレーションエージェントを書いた開発者が退職し、規約が変わり、それでもエージェントは前四半期のルールを自信満々に適用し続ける。
チームが成長するにつれて最初に壊れるもの
毎回、まずレビュー能力が限界を迎える。2つ目の制約はマシンのキャパシティだ。並列実行数や空き作業ディレクトリを待つ間、実行はキューに並ぶ。コンピュータを増やさずにエージェントだけを増やしたチームは、ボードからは見えないキューに気づくことになる。
3つ目はオーナーシップの漂流だ。複数のエージェントが関連するタスクに貢献し、引き継ぎ後に誰もオーナーを書き換えないと、名目上はアサインされているものの実質的にオーナー不在の作業が生まれる。エージェントが担当者になっているタスクと、人間のオーナーが古いままのタスクを週に一度見直すのに10分かければ、この厄介な版を防げる。こうしたフィールドがすでに分かれているシステムから始めたいなら、Sharklyをダウンロードして、1種類の繰り返し作業を1週間通してみてほしい。
FAQ
開発者1人あたり何体のエージェントが妥当ですか？まず1〜2体から始め、レビューのスループットで上限を決めましょう。適切な数は、結果が人間の判断を待つ時間が1営業日を超えない数です。
エージェントはスタンドアップに参加するのですか？彼らの作業は参加します。ステータスはボードが担うので、スタンドアップは例外リストになります。失敗、ブロックされた実行、人間待ちの結果です。
エージェントを唯一の担当者にすべきことはありますか？ありません。成果に対する責任者として人間を残し、エージェントは実行枠に入れます。量が増えるほどこの分離が重要になる理由は、AIエージェントのプロジェクトマネジメントのガイドで説明しています。
新しいエージェントをチームにオンボーディングするには？人間をオンボーディングするのと同じです。まず狭い範囲の仕事を任せ、密にレビューし、それからスコープを広げます。うまくいったやり方はエージェントの指示とスキルとして保存し、次のチームが一から発見し直さなくて済むようにしましょう。
