チームに最初のAIエージェントを導入するとスループットは上がります。しかし2体目になると、調整の問題が生まれます。API変更をどのエージェントが担当するのか、テストはどれが書くのか、リファクタリングはスキーママイグレーションを待つべきか、そして人が受け入れる前に統合結果を誰が確認するのか——誰かが決めなければなりません。ほとんどのチームでは、その「誰か」は両手にターミナルを抱えたシニアエンジニアであり、この役割はスケールしません。
SharklyのCrew（クルー）は、まさにこの瞬間のために存在します。Crewとは、1体のリーダーAgentによって調整される、再利用可能なPeopleとAgentsのグループであり、エージェントの作業を共有タスクシステム内に保つプラットフォームであるSharklyの中に存在します。人がすべてのサブタスクを手作業で振り分ける代わりに、あなたはTaskをCrewに割り当てます。リーダーAgentがゴールを読み取り、どのメンバーが貢献すべきかを判断し、その結果をチームがレビューできる1か所にまとめます。
このガイドでは、Crewとは何か、単一のAgentのほうが適しているのはどんな場合か、リーダーファーストの実行が実行ごとにどう振る舞うか、そして3か月後もチームが使い続けているようなCrewのセットアップ方法を扱います。
TL;DR
SharklyにおけるCrewとは、1体のリーダーAgentによって調整される、再利用可能なPeopleとAgentsのグループです。あなたがTaskをCrewに割り当てると、リーダーが最初に起動し、ゴールを解釈し、Agentメンバーにメンションして作業の一部を委任し、その結果をTask上で統合します。Agentsは調査・実行・テスト・報告を行います。Peopleは方向性を定め、権限を与え、結果を受け入れます。
SharklyにおけるCrewとは？
Crewとは、名前を持つ再利用可能なチームです。安定した種類の作業を中心にPeopleとAgentsがグループ化され、実行を調整する1体のリーダーAgentを伴います。単一のAgentが1つの役割のための保存された作業構成であるのに対し、Crewは複数の役割がどのように協働するかを捉えるため、複雑なTaskを1体の実行者ではなくチームに割り当てられます。
すべてのCrewには以下が含まれます：
- 名前、説明、および任意のCrew instructions
- 1人のOwner（組織内でCrewを管理する人物）
- 1体のリーダー（CrewのSpace内のAgentでなければならない）
- そのSpaceに参加できるAgentメンバーとPeopleメンバー
- 1つの所有Space
- PersonalまたはSpaceの可視性
- 任意の共有Taskディレクトリ設定
何よりも先に押さえるべき2つの境界があります。
Ownerはリーダーではありません。OwnerはCrewを管理する人物であり、メンバーシップ、設定、可視性を担います。リーダーはAgentであり、実行の調整を続けます。OwnerをリーダーAgentの代替と見なすのは、どちらの役割も誤解しています。
メンバーシップは実行ではありません。Peopleのメンバーシップは誰がCrewに参加しているかを記録しますが、Agentの実行を開始できるのはAgentメンバーだけです。Crewに参加した人物は、これまでどおりTaskのコメント、レビュー、チャットを通じて協働を続けます。Crewに加わることが、人間を実行ターゲットに変えることは一切ありません。
リーダーは自動的にメンバーとして追加され、リーダー役割を持ち、そのCrewを率いている間は削除できません。他のメンバーは、backend、tests、docsといった、貢献内容を表す役割ラベルを付けられます。これにより、リーダーが委任する際に具体的に判断できる材料が得られます。
単一のAgentではなくCrewを使うべきなのはどんなとき？
この判断のペアはSharkly docsからそのまま来ており、文字どおり受け取る価値があります。小さく明確に定義された作業には、Taskを直接1体のAgentに割り当ててください。リーダーがゴールを解釈し、他のAgentメンバーを巻き込み、その結果を1つのTaskまたは会話に戻す必要がある場合は、Crewを使います。
単一のAgentが正しい選択となるのは：
- 作業が1つの役割に収まる場合（例：1つのサービスにおけるバグ修正）。
- スコープがすでに明確で、分解が不要な場合。
- 割り当てからレビューまでの間に動く部品を最小限にしたい場合。
- 個々のAgentのinstructionsをまだ調整中で、クリーンなシグナルを得たい場合。
Crewがその価値を発揮するのは：
- ゴールが役割をまたぐ場合（例：backend、frontend、テストの変更を必要とする機能）。
- 誰かが貢献の順序を決めなければならず、その「誰か」を、2つのターミナルを開いた人間ではなくAgentにしたい場合。
- 同じ専門家の組み合わせが、新しいリクエストごとに繰り返し形成される場合。
- 複数のAgentからの結果が、プライベートセッションに散らばるのではなく1つのTaskに集まる必要がある場合。
マルチエージェントの作業を構造化する価値があるかどうかをチームがまだ判断している段階なら、AIエージェントオーケストレーションの入門記事が、そのトレードオフを原理から解説しています。要点はこうです：2体目のエージェントは安価ですが、エージェント間の管理されない調整は安価ではありません。
リーダーファースト実行の仕組み
TaskをCrewに割り当てると、実行はリーダーファーストの順序に従います：
- Taskは、他のAssigneeと同じように、Assigneeコントロールを通じてCrewに割り当てられます。
- Taskが実行可能なステータスにあり、リーダーの準備ができている場合、リーダーAgentが最初に起動します。
- リーダーはTaskのコンテキストとCrew instructionsを読み取ります。
- リーダーは、作業を自身で処理するか、特定の貢献のために対象となるAgentメンバーにメンションします。
- メンションされたAgentメンバーは同じTaskに対して実行し、その結果をTaskのチャットに追加します。
- リーダーは調整を続け、結果を統合します。
この順序の背後にある設計目標は「自制」です。リーダーファーストの実行は、すべてのAgentメンバーが一斉に起動するのを防ぎます。また、リーダーが不足しているコンテキストを特定し、適切な参加者を選び、作業の順序を制御する機会も与えます。リーダーのいないCrewはファンアウトボタンにすぎませんが、リーダーがいれば、作業を分割する前に考えるチームになります。
Backlogは個々のAgentと同じように振る舞います：Backlog内でTaskを割り当てても、リーダーは起動しません。Backlogは作業が準備される待機エリアであり、Taskを実行可能なステータスに移動させることがCrewを起動する行為です。割り当てが不意に作業を発火させることはありません。
メンバーが生み出すものはすべてTaskに戻ります：実行状態、結果、そしてそれらをめぐる議論です。これが、5つのターミナルにまたがるのではなく、Sharklyの中でチームを動かす意味です。コンテキスト、進捗、ブロッカー、結果、そして人のレビューが、1体のAgentが作業したか4体が作業したかに関わらず、リクエストからリリースまで見える状態に保たれます。
メンバーを並列で動かすチームへの実務的な注意点が1つあります：各Agentの実行はデフォルトで依然として独自の分離された作業ディレクトリを持つため、メンバーが互いのファイルでつまずくことはありません。この分離モデルについては、SharklyがマージコンフリクトなしでAgentsを並列実行する仕組みで扱っています。
所有権、可視性、そして誰がCrewを使えるか
Space内で共有リソースを作成する権限を持つ人は、そこでCrewを作成できます。すべてのCrewは1つのSpaceに属し、その可視性が誰がそれを見つけて使えるかを制御します：
| 可視性 | アクセスしてチャットできる人 | 管理または割り当てできる人 |
|---|---|---|
| Personal | Owner、人間のCrewメンバー、およびAgentメンバーのオーナー | OwnerのみがCrewを管理し、TaskのAssigneeとして選択できる |
| Space | CrewのSpaceのメンバー、およびOrganizationのOwnersとAdmins | Spaceと組織の権限に準じる |
可視性は、Crew自体、Crewチャット、およびTaskのAssigneeとしての選択に適用されます。Personal CrewはそのOwnerによって管理され、プライベートCrewのOwnerが変更された後、以前のOwnerは管理アクセスを失います。この引き継ぎルールは、Crewを構築した人物がチームを移る際に重要です：後でギャップに気づくのではなく、意図的に所有権を移してください。
Crewが役目を終えたら、履歴を削除するのではなくアーカイブしてください。アーカイブされたCrewは新しい割り当てを受け付けなくなりますが、既存の履歴は利用可能なままです。アーカイブする前に、現在のTaskやAutomationsがまだそのCrewを使用していないか確認し、その作業を先に別のAssigneeへ移してください。同じ依存関係のチェックは、Crewに属するAgentをアーカイブする前にも当てはまります。
Crewチャット：Taskが存在する前の調整
すべての議論が初日からTaskに値するわけではありません。Crewチャットは、作業項目より前に来る会話、つまり問題を探り、適切な参加者を特定し、計画を形作るための場として存在します。
各人はCrewとの永続的なチャットセッションを持ち、リーダーAgentが最初のチャット相手です。リーダーはAgentメンバーにメンションできるため、その返信が同じチャットに表示されます。つまり、何かにコミットする前に、チームが一緒に考える様子を眺められます。
境界は明確で、覚えておく価値があります：CrewチャットはTaskを作成しません。議論が具体的な作業になったら、Taskを作成してCrewを割り当ててください。そうすれば、ステータス、コメント、実行、受け入れが作業項目に紐づいたままになります。チャットセッションだけに存在する結論は、チームが失う結論です。共有される記録はTaskであり、結果はそこに戻る必要があります。
Taskの詳細画面には、ヘッダーツールバーにクイックチャットもあります。クイックチャットは、現在のタスクをコンテキストとして、選択したAgentまたはCrewをTaskの横の分割ビューで実行します。Crewを正式に割り当てる前に「これについてどうする？」と尋ねるのに便利な方法です。
応用的なCrewテクニック
Crew専用Agent：他のどこでも働かないスペシャリスト
チームの中でしか意味をなさないAgentもあります。他の3人のメンバーが存在することを前提とするマージコーディネーターや、あるCrewの慣習に合わせて調整されたレビュアーは、組織の一般のAgentピッカーに現れて、本来設計されていなかった単独作業を誰かに割り当てられるべきではありません。
AgentをCrew専用としてマークすると、そのAgentはそのCrewにスコープが限定されます。この設定をオンにすると：
- そのAgentは現在のCrew内でのみ呼び出せる
- プライベートチャットに使ったり、単独でTaskを割り当てたりできない
- My Agents、ディレクトリ、組織のAgentリスト、およびAssigneeピッカーから消える
専用化はAgentに対するスコープ制限であり、Crewの役割ではありません。役割ラベルはメンバーが何をするかを表し、専用化はそのAgentをどこで呼び出せるかを表します。Crew専用Agentは同時に最大1つのCrewに属するため、すでに別のCrewにある場合は先にそこから削除してください。専用化を解除すると通常の可視性と割り当て可能性が復元され、履歴のTaskとチャットはどちらの場合も残ります。ブロックされるのは、新しいプライベートチャットと新しい単独割り当てです。
共有Taskディレクトリ：メンバーが同じファイルの上に積み上げる必要があるとき
デフォルトでは分離が原則です：別々の実行は別々のディレクトリを持ちます。Crewはこれを意図的に緩められます。共有Taskディレクトリ設定を有効にすると、同じTaskに対する後続のCrew Agent実行が、そのComputer上の最新の対象ディレクトリを再利用し、以前のメンバーが残したローカル変更を保持できます。
これを安全に保つ2つの制約があります。共有されるのはファイルシステムの状態だけで、以前のAgentのプロバイダーセッションは共有されないため、各メンバーは依然としてTaskレコードから独自の推論を開始します。そして、それが適用されるのは、実行が同じCrew割り当てのTaskに属し、同じComputer上で実行される場合のみです。
判断ルール：実装Agentの後に新しいコードを検証するテストAgentが続く場合など、連続するメンバーが同じローカル変更の上に積み上げる必要があるときは、共有ディレクトリの再利用を有効にしてください。分離のほうが安全な場合や、同時編集が競合する可能性がある場合は無効のままにします。有効にするなら、意図する実行順序をCrew instructionsで明示してください。順序が曖昧な共有ディレクトリは、チームのジャージを着たマージコンフリクトです。
長持ちするCrew instructionsの書き方
Crew instructionsは、調整のためのリーダーの操作マニュアルです。docsには、そこに何を書くべきかが具体的に示されています：リーダーが別のAgentを巻き込むかどうかをどう判断するか、どの役割が利用可能か、結果をどう統合すべきか、そして人がいつ判断を下す必要があるか。
レイヤーは分けておいてください。タスク固有の要件はTaskの説明とコメントに残します。複数のAgentが共有する再利用可能な手順はSkillに属します。各メンバーAgent自身のinstructionsがその個別の役割を担います。Crew instructionsは協働ルールだけを扱うため、リーダーが毎回の実行で従える程度に短く保てます。すべてのメンバーのinstructionsをCrewに複製するのは、委任を予測不能にする最も一般的な原因です。
実用的な骨組み：
# Crew: Checkout Feature Crew
## When to delegate
- API or database changes: mention @backend-agent
- UI changes in web/: mention @frontend-agent
- After any code change lands: mention @test-agent
## Order
Backend before frontend when a contract changes.
Tests run last, against the combined changes.
## Combining results
Summarize each member's outcome on the Task,
list open risks, then set the Task to waiting
for human review.
## Escalation
Any schema migration or public API change stops
here: ask the responsible person on the Task
before proceeding.
このエスカレーションブロックは、チーム自体に書き込まれた人間とエージェントの契約です。Agentsは調査・実行・テスト・報告を行います。Peopleは方向性を定め、権限を与え、結果を受け入れます。Crewは契約を変えません。契約のエージェント側に、より多くの手を与えるだけです。
最初のCrewをセットアップする
docsには典型的なセットアップ手順が記載されており、Agentsがすでに存在していれば約15分の作業に相当します：
- Crewが扱う安定した種類の作業を定義します。「すべて」は作業の種類ではありません。「チェックアウトフローの変更」はそうです。
- 可視性とOwnerを選びます。調整中はPersonalで始め、その構成が再利用に値するようになったらSpace可視性へ移行します。
- リーダーとなるAgentを選びます。必ずしも最も多くコードを書くものではなく、作業を振り分ける判断力を信頼できるものを選んでください。
- その作業に必要なPeopleメンバーとAgentメンバーを追加し、リーダーが判断できる役割ラベルをメンバーに付けます。Membersページでは複数を一度に追加でき、行メニューから後で新しいリーダーを設定したり、メンバーを削除したりできます。
- 上記のレイヤー化ルールに従って、調整と出力のためのCrew instructionsを書きます。
- 共有Taskディレクトリは、その再利用動作がまさに望むものである場合にのみ有効にします。迷ったらオフのままにしてください。
次に、実際のTaskを1つ割り当てます。たとえばSH-312：「サブスクリプションのキャンセルフローにキャンセル理由フィールドをAPIとUIで追加し、テストを付ける」。リーダーが起動するのを眺め、どう委任するかを読み、Taskに何が戻ってくるかをレビューしてください。最初のCrew実行は、事前にどれだけinstructionsを編集するよりも、あなたのinstructionsについて多くを教えてくれます。各Agentメンバーは、チームがすでに費用を払っているClaude Code、Codex、その他のCLIツールであれ、それぞれが設定したRuntime上で実行されます。Sharklyはこれらのツールの調整レイヤーであり続け、それらを置き換えるものではないからです。
真似する価値のあるCrewパターン
これらはケーススタディではなく構成パターンであり、それぞれが文書化された動作を組み合わせたものです。
機能開発Crew。 計画を立てるリーダーAgentと、対応する役割ラベルを持つbackend、frontend、テストのメンバー。リーダーは要件を分解し、契約が変わる場合はbackendをfrontendより先に進め、テストメンバーに最後にメンションします。これは上記のセットアップ骨組みが説明するパターンであり、要件が日常的に役割の境界をまたぐチームに適しています。
トリアージCrew。 入ってくるバグレポートを読むリーダー、失敗を確認して証拠を収集する再現メンバー、確認された再現がTaskに戻ってきた後にのみ行動する修正メンバー。人はメンバーとしてループに関与し続けます。バグの優先度を決めるのは方向性の設定であり、契約のその側面は人に属するからです。
レビューCrew。 レビューの観点を割り当てるリーダー：1人のメンバーは正確性のために読み、別のメンバーはセキュリティ上重要なパスを、3人目はテストカバレッジを読みます。彼らの発見はリーダーが要約する個別の結果としてTaskに集まります。レビューメンバーは機能作業を単独で割り当てられるべきではないため、ここはCrew専用Agentの自然な居場所です。
スプリント支援Crew。 Sprint中に、Crewが繰り返し発生する範囲の明確な作業を引き受けます：依存関係の更新、フレーキーテストの隔離、ドキュメントの乖離。リーダーの主な仕事はスコープ外の作業を断ることであり、これによりCrewのスループットが計画を立てられるほど予測可能に保たれます。
どのパターンから始めるにしても、まず1つから始めてください。1つのCrewをうまく運用するチームは、2つ目を安価にする調整の習慣を身につけます。
Crewが答えではないとき
正直な境界のリストです。マルチエージェント作業に対してチームを最も早く幻滅させる方法は、それが価値を差し引く場所で使うことだからです。
1つの明確な役割、1つのAgent。 Taskが単一の役割に収まるなら、Crewは委任のホップを1つ追加するだけで、それ以外は何もしません。docs自身のガイダンスも、単純な作業には1つのAgentを、本当に調整を必要とする作業にはCrewを優先するよう勧めています。
定期的なトリガーにはAutomations。 作業が判断ではなくスケジュールやイベントで発火するなら、Automationのほうが鋭いツールです。Crewsは決定し、Automationsは繰り返します。両者はうまく組み合わせられますが、互換ではありません。
実行内の分解には、ランタイムのサブエージェント。 Claude Codeのようなツールは、1回の実行内でサブエージェントを生成できます。それは競合ではなく補完です：ランタイムのサブエージェントは1体のAgentの作業をそのセッション内で分割し、Crewは別々のAgents、Runtimes、結果をチームが見えるTaskレベルで調整します。現在、スクリプトとtmuxで複数のClaude Codeエージェントを動かしているなら、Crewはその構成の調整側面にとっての卒業パスです。
余計な手間が加わったグループチャット。 求めているのが議論なら、Crewチャットを使ってそこで止めてください。単一のAgentが答えられる質問に答えることだけを仕事とするCrewを作らないでください。
ここまでの話は、何かを再構築することを求めていません。メンバーはそれぞれのRuntimes、リポジトリ、サブスクリプションをそのまま保ちます。Crewはすでに設定したAgentsの上に乗る調整レイヤーであり、モデルの利用はそれらのツールで設定されたサブスクリプションとAPIキーを通じて続きます。
結論
Crewは、最初のAgentが成功した後にすべてのチームが突き当たる問いへのSharklyの答えです：人間の交通整理役を任命せずに、どうやってこれらのエージェントを複数動かすか？ その仕組みは、書かれた調整ルールを持つ1体のリーダーAgent、読み取れる役割を持つメンバー、そしてすべての結果が戻る1つのTaskです。自制は組み込まれています：リーダーファーストの実行、決して自動起動しないBacklog、デフォルトの分離、そして最後に受け入れを担う人。
具体的な次の一歩は小さく始められます。1つのComputerを接続し、すでに個別に信頼している2体のAgentを設定し、3行のinstructionsブロックを持つCrewでそれらを包みます。本当に両方の役割を必要とするTaskを1つ割り当て、何が返ってくるかを読んでください。Sharkly docsでは各概念をより深く扱っており、Sharkly入門では基盤となるセットアップを最初から最後まで順を追って説明しています。
よくある質問
SharklyにおけるCrewとは？
Crewは、1体のリーダーAgentによって調整される、再利用可能なPeopleとAgentsのグループです。それを管理するOwner、1つの所有Space、PersonalまたはSpaceの可視性、および任意のCrew instructionsを持ちます。TaskをCrewに割り当てると、リーダーがどのメンバーが貢献するか、結果がどう統合されるかを調整します。
単一のAgentではなくCrewをいつ使うべき？
小さく明確に定義された作業は、直接1体のAgentに割り当ててください。ゴールの解釈が必要な場合、複数の役割にまたがる場合、または複数のAgentからの結果を1つのTaskに戻す必要がある場合はCrewを使います。同じ専門家のグループがリクエストごとに繰り返し形成されるなら、その繰り返しこそチームを再利用可能にすべきシグナルです。
TaskをCrewに割り当てると、すべてのメンバーが一斉に起動しますか？
いいえ。実行はリーダーファーストです：リーダーAgentが起動し、TaskのコンテキストとCrew instructionsを読み、特定の貢献のために対象となるAgentメンバーにメンションします。メンションされたメンバーはその後、同じTaskに対して実行します。これにより、いわゆる「thundering herd」を防ぎ、リーダーが順序と参加を制御できます。
PeopleはCrewのメンバーになれますか？
はい。Peopleのメンバーシップは誰が参加するかを記録し、Personal Crewの人間メンバーはそれにアクセスしてチャットできます。ただし、Agentの実行を開始できるのはAgentメンバーだけです。PeopleはTaskのコメント、決定、レビューを通じて貢献します。これが契約の人間側です。
Crew専用Agentとは？
Crew専用Agentは1つのCrewにスコープが限定されます：そのCrew内でのみ呼び出せ、プライベートチャットや単独のTask割り当てを持てず、組織全体のAgentリストにも現れません。これは役割ではなくスコープ制限であり、解除するとそのAgentの通常の可視性が復元されます。
CrewメンバーはTask中にファイルを共有できますか？
はい、Crewが共有Taskディレクトリ設定を有効にしている場合に可能です。同じTaskに対する後続メンバーの実行は、同じComputer上の最新の対象ディレクトリを再利用し、以前のローカル変更を保持できます。共有されるのはファイルシステムの状態だけで、以前のAgentのセッションは決して共有されず、同時編集には分離のほうが安全なためデフォルトではオフです。
CrewチャットはTaskを自動で作成しますか？
いいえ。Crewチャットは、リーダーを最初のチャット相手として、問題を探ったり計画を形作ったりするための場です。議論が具体的な作業になったら、Taskを作成してCrewを割り当て、ステータス、実行、受け入れが作業項目に紐づいたままになるようにします。
