Claude Agent Teams は、うまく回り始める瞬間と混乱し始める瞬間が同じです。

チームメイトをいくつか起動し、作業が並列に進み始めて…そして、次の問いに簡単に答えられないことに気づきます。

• 誰が何をしている？
• 誰が自分を待っている？
• 次のメッセージはどこに送るべき？

これを解決しないと、チームは力になるどころか、スクロールの連続に感じられます。

このガイドでは、Claude Agent Teams をわかりやすく予測しやすくするワークフローを紹介します。明確なルーティング、決まった確認、そして無駄のない「対応ループ」です。

要点

1. Claude Agent Teams は、トランスクリプトの問題ではなくメッセージのルーティングの問題として扱います。
2. 3つの「宛先」を意識します:
   • リード（既定。アプリの表示は メイン（Lead））
   • 特定のチームメイト
   • Broadcast（チーム全体に1つのメッセージ）
3. メッセージがどこに行ったか推測しないこと。ルーティングした送信を明示的にします。
4. スマホでチームメイトを監視し、ルーティングしたメッセージを送りたいなら、Happier が選択肢の1つです。「送信先」（Send to）の宛先チップ（メイン / Broadcast / チームメイト）と、専用のエージェント一覧があります。

課題

Claude Teams が難しいのは、Claude が作業をこなせないからではありません。

人間が見失うからです。

チームメイトが複数になると:

• リードのトランスクリプトだけでは全体がわからない
• 止まっている1人のチームメイトを見逃しうる
• 「ちょっと訂正を送る」が曖昧になる（誰に？）

だから本当に解決すべきは、注意とルーティングです。

よくある方法とトレードオフ

• リードとだけ話す: 安全ですが、チームメイトの利点の大半を失います。
• スクロールして目的のチームメイトの出力を探す: 使えますが、規模が大きくなると無理です。
• チームメイトごとにウィンドウ/タブを分ける: ましですが、それでも次の指示を違う場所に送りがちです。

Happier を初めて使う場合

Happier を初めて見る方へ。Happier はコーディングセッション向けのオープンソースのコンパニオンアプリ（モバイル/Web/デスクトップ）です。

このガイドで関係するのはシンプルな点です。Claude Agent Teams 用の UI があり:

• チームメイトが一覧（「エージェント」（Agents））として見える
• コンポーザーに「送信先」（Send to）の宛先チップ（メイン / Broadcast / チームメイト）がある
• ルーティングした送信がカードとして表示される（どこに送ったかわかる）

セットアップ:

• スマホから Happier を使う方法
• GitHub: https://github.com/happier-dev/happier
• インストール/ダウンロード: https://github.com/happier-dev/happier#how-it-works
• Discord（コミュニティとサポート）: https://discord.gg/W6Pb8KuHfg

わかりやすさを保つ Claude Teams の考え方

リード

リードは既定の会話です。

ルーティングなしでメッセージを送ると、リードに届きます。

チームメイト

チームメイトは、Claude チームの特定のメンバーです。チームメイトに送るメッセージは明示的にします。

Broadcast

Broadcast は「チーム全体に伝える」チャンネルです。

Happier の実装では、Broadcast は Claude のチーム ID から作られ、チームがあるときにルーティング先として表示されます。

動くワークフロー

1) 毎回使い回すチームメイトの「役割」を 2〜3 個決める

チームメイトが毎回一点ものだと、チームは散らかります。

再利用できる役割を少しだけ用意し、毎回同じプロンプトを使いましょう。

妥当な既定:

• レビュアー（差分重視、慎重）
• テスター（テストを実行し、前提を崩そうとする）
• リファクタラー（機械的なコードの移動を担当）

役割は増やせます（ドキュメント、トリアージ、リリースノート）が、小さく始めるとチームを管理しやすくなります。

2) コピー&ペーストできるプロンプトでチームメイトを作る（振る舞いを予測しやすくする）

チームメイトを起動するときは、次を与えます。

• 役割
• 範囲
• 止まるルール
• チェックポイントの形式

使い回しても崩れにくいプロンプトです。

チームメイトのプロンプト: レビュアー

あなたは私のレビュアーです。リスクと矛盾を見つけるのが仕事です。

ルール:

• 変更はしないでください。レビューだけです。
• まず、目標が何だと考えているか要約してください。
• 次に、(1) リスク、(2) 足りないテスト、(3) 差分の改善案を挙げてください。
• 不明な点があれば、確認の質問を1つしてください。

チームメイトのプロンプト: テスター

あなたは私のテスターです。

ルール:

• リファクタリングはしないでください。失敗のパターンに集中してください。
• まず最小限のテスト計画を提案してください。
• それから計画を実行してください（または実行する内容を正確に説明してください）。
• 何かが失敗したら、失敗したコマンドとエラーをそのまま貼り付けてください。

チームメイトのプロンプト: リファクタラー

あなたは私のリファクタラーです。

ルール:

• 何かを変える前に、3ステップの計画を提案してください。
• 各ステップのあとに、変更内容を要約してください。
• 明示的に指示しない限り、マイグレーションや認証には触れないでください。
• リスクのある変更が必要なら、止まって確認してください。

3) 全体の制約には Broadcast を使う（1つのメッセージを全員が受け取る）

Broadcast は、チーム全体に適用すべき制約に向いています。

• 「マイグレーションには触れないで。」
• 「次のステップのあとで止まって要約して。」
• 「インストールを実行する前に確認して。」

Broadcast は詳細なタスク（「ファイル X を変えて、次に Y」）には向きません。責任の所在が混ざるからです。

4) 詳細なタスクは一度に1人のチームメイトに送る

チームメイトに特定のことをしてほしいときは、そのチームメイトに直接送ります。

役立つ小さな習慣: メッセージの最後に、必ず返事をもらう一文を付けます。

例:

返事は「今やっていること」と「次にやること」で。

メッセージが違う宛先に届いたら、すぐにわかります。

5) エージェントのサイドバーを一覧として使う（これが肝心）

ここが、Claude Teams を管理しやすくする Happier 固有の部分です。

Claude チームのセッションでは、Happier がセッション UI に エージェント（Agents）一覧を表示します。

そこには:

• 起動（Launch）: 新しいチームメイトを起動
• 稼働中（Active）: 現在動いているもの
• 最近（Recent）: 終了/アイドル

そして各エージェントの項目は、トランスクリプトの1行ではなく、実際に「開けるもの」です。

つまり、ワークフローはスクロールからではなく、一覧から始まります。

習慣: セッションを開いたら、まずエージェントのサイドバー/ペインを開きます。

6) チームメイトを開いて、何をしているか見る（コンテキストを失わずに）

エージェント一覧から:

• チームメイトをタップ/クリック

Happier がそのチームメイトの画面を開き、次を確認できます。

• トランスクリプト
• ツールのアクティビティ
• 自分を待っているかどうか

これで Claude Teams が「長いスクロールバックから正しいメッセージを探す」作業にならずに済みます。

7) 特定のチームメイトにメッセージを送る（リードではなく）

メッセージのコンポーザーには 送信先（Send to）の宛先チップがあります。

次のメッセージの送り先を選べます。

• メイン（Lead、既定）
• 特定のチームメイト
• Broadcast（チーム全体へ）

チームメイトを選ぶと、メッセージはそのチームメイトに届きます。

これが Happier のチーム UX の大きな利点です。ルーティングが明示的になります。

8) 「2分チェックイン」ループを使う（特にスマホで）

スマホで動くワークフローは、意図的にシンプルです。

1. セッションを開く。
2. エージェント 一覧を開く。
3. 対応が必要なものを見つける。
4. メッセージを1つルーティングする（または制約を1つ Broadcast する）。
5. アプリを閉じる。

スマホでそれ以上やろうとすると、判断の質が下がります。

9) 送信後にルーティングを確認する方法を知る

メッセージがどこに行ったか証明できるようにしたいものです。

Happier では、ルーティングした送信は、宛先のラベルがはっきりしたメッセージカードとして表示されます（例:「宛先: メイン」、「宛先: Broadcast …」、「宛先: reviewer」）。

この小さな UI の工夫が、「レビュアーに言ったはず…」という混乱を防ぎます。

トラブルシューティング

チームメイトが黙っている

よくある原因:

• まだ作業中（チェックポイントを求める）
• 権限や入力を待って止まっている
• 深みにはまった（停止と要約を送る）

良い救出メッセージ:

止まってください。やったこと、次にやろうとしていたこと、私に必要なことを要約してください。

2人のチームメイトが同じ作業をしている

たいてい次のときに起きます。

• タスクを、宛先指定ではなく Broadcast で送った
• リードがタスクを曖昧に転送した

対処:

• 担当を1人に決める（「レビューはレビュアー、編集はリファクタラー」）
• その担当ルールを一度 Broadcast する

Broadcast がうるさく感じる

Broadcast は制約と調整のためのもので、タスクの割り当てには使いません。

「X をやって」を Broadcast に入れていると気づいたら、宛先指定のチームメイトへのメッセージに戻しましょう。

よくある質問

いつもチームメイトを3人使うべきですか？

いいえ。1人から始めましょう。

価値の多くは次から生まれます。

• リスクを拾うレビュアーのチームメイト1人、または
• 壊れやすい変更を防ぐテスターのチームメイト1人

リードは何をすべきですか？

リードが向いているのは:

• 調整
• チームメイトの出力どうしの食い違いの解決
• メインの実装スレッドへの最終的な「これをやって」という指示を書くこと

よくある間違い

• 宛先を決めたタスクを Broadcast で送る
• 全体の制約を1人のチームメイトにだけ送る
• チェックポイントの要約を一度も求めない

関連ガイド

• Claude Code、Codex、OpenCode のどのセッションが止まっているかを見分ける方法（ターミナルを 10 個確認せずに）