# Syfo をチームの日常業務に取り入れる

> 個人での試用からチームでのコラボレーションへ広げるための、チャンネル、Agent、コンテキストの設計方法です。

Source: https://docs.syfo.ai/ja/docs/team-playbook

チームで Syfo を本格的に導入するとき、最初にやるべきことは Agent の作成ではありません。チャンネルをどう分けるか、Agent にどう役割を分担させるか、コンテキストをどこに置くかを考えることです。このガイドでは、その計画づくりを手伝います。

本当に最初に考えるべきなのは「Agent を何体作るか」ではなく、次のことです。

1.  どの業務ラインを Syfo に載せるか
2.  各業務ラインをどのチャンネルに分けるか
3.  各チャンネルに Agent を何体置き、それぞれどんな役割を担わせるか
4.  Agent が実際に仕事をするには、どんなコンテキストが見える必要があるか
5.  チームメンバーがどんなコラボレーションのルールを守るか

## 管理者向け導入チェックリスト

本格展開の前に、組織の Owner または Admin が次の準備をしておきます。

1.  **メンバーを招待し、役割を割り当てる。** 「メンバー」から同僚を招待し、必要に応じて Owner、Admin、メンバーなどの役割を割り当てます。組織、請求、Syfo Cloud Agent を管理する人は、少数かつ明確にしておきましょう。各役割の違いは [権限](https://docs.syfo.ai/ja/docs/permissions)、招待の手順は [組織](https://docs.syfo.ai/ja/docs/organization) を参照してください。
2.  **クレジットを用意する。** 「設定 → サブスクリプションとクレジット」でプランを契約するか Credit を購入し、「請求先情報」（請求先メールアドレス、請求書の宛名）を入力します。残高アラートを誰が確認するかも決めておきます。詳しくは [使用量と請求](https://docs.syfo.ai/ja/docs/usage-billing) を参照してください。
3.  **コンピューターを接続する。** ローカルのリポジトリや手元のツールが必要なメンバーは、「コンピューター」で「コンピューターを追加する」をクリックし、自分のコンピューターを接続します。詳しくは [コンピューターと実行場所](https://docs.syfo.ai/ja/docs/computers#コンピューターを接続する) を参照してください。
4.  **Cloud とローカルの使い分けを決める。** 常にオンラインである必要がある Agent（スケジュール済みタスク、運用、カスタマーサポート）は Syfo Cloud に置き、Owner または Admin が作成または承認します。開発やデバッグ用の Agent はメンバー自身のコンピューターで動かします。ローカルの Agent にメンバー自身のモデルアカウントを使わせるか、組織クレジットで支払うかも決めておきます。
5.  **認証情報をパスワード保管庫に入れる。** チームで共有する外部システムの認証情報は、管理者が「設定 → Vault」の「組織」タブに保存し、必要な Agent に個別に権限を付与します。詳しくは [パスワード保管庫](https://docs.syfo.ai/ja/docs/vault) を参照してください。
6.  **通知とミュートのルールを決める。** 次のようにメンバーに伝えます。流量の多いチャンネルは通知を「@メンションとフォロー中のスレッド」または「ミュート」にしてよいこと、業務時間外は「設定 → 通知」で「この組織をミュートする」を使えること、緊急の用件は @メンションで名指しし、相手がチャンネルを見てくれることを当てにしないこと。詳しくは [通知](https://docs.syfo.ai/ja/docs/notifications) を参照してください。
7.  **必要に応じて拡張機能を有効にする。** データリサーチや画像・動画生成が必要なチームは、該当するコンピューターに [Powerpack](https://docs.syfo.ai/ja/docs/powerpack) をインストールします。ウェブサイトを公開する必要があるチームは、[ウェブサイト](https://docs.syfo.ai/ja/docs/hosted-websites) の承認フローを確認しておきます。

## まず業務ラインごとにチャンネルを分ける

チャンネルは、Syfo における仕事の現場です。1 つのチャンネルは、同じ種類のコンテキスト、同じ参加者、同じ一連のタスクを中心に成り立つべきです。

組織図をそのまま写したり、すべてを 1 つのチャンネルに詰め込んだりしないでください。まずチームが現在進めている業務ラインを洗い出し、どれに専用のチャンネルが必要かを判断します。

| ユースケース | おすすめのチャンネル | このように分ける理由 |
| --- | --- | --- |
| 顧客への導入支援 | `#顧客A-導入`、`#顧客A-納品実行` | 顧客情報、納品の進捗、課題の追跡を 1 か所に集める必要があります。実行の細部は、議論用のチャンネルから専用チャンネルに切り出せます。 |
| 社内の研究開発 | `#product-planning`、`#dev-runtime`、`#release-review` | プロダクトの議論、コードの実装、リリース前チェックでは、参加者も Agent の権限も異なります。 |
| 営業のフォローアップ | `#sales-leads`、`#enterprise-demo` | 営業リード、顧客の背景、デモ資料は継続的に蓄積する必要があり、ダイレクトメッセージに散らばらないようにします。 |
| 顧客フィードバック | `#customer-feedback`、`#faq-improvements` | 生のフィードバックとドキュメント・プロダクトの改善は関連付けられますが、同じメインの流れに混ぜる必要はありません。 |

チャンネルを分けるときは、次の 4 つの観点を優先します。

-   **プロジェクトまたは顧客**：長期的に進めるプロジェクト、顧客、納品ラインは、専用チャンネルに向いています。
-   **機密性**：契約、見積もり、本番環境、顧客のプライバシー、社内の人事などの情報は、公開チャンネルに置かないでください。
-   **実行フェーズ**：要件の議論、設計レビュー、実行と納品、リリース後の振り返りは分けることができます。1 つのチャンネルが長くなりすぎたり、騒がしくなりすぎたりするのを防げます。
-   **参加する役割**：ある仕事に長期的に関わるのが少数の人と少数の Agent だけなら、全員参加のチャンネルには置かないでください。

1 つのプロジェクトに対応するチャンネルは 1 つでも、複数でもかまいません。判断基準はシンプルです。同じ人、同じ Agent、同じ権限で対応できるなら、まず 1 つのチャンネルにまとめます。コンテキスト、権限、実行のリズムが明らかに異なるなら、分けます。

## 各チャンネルに置く Agent の数を決める

Agent は多ければよいというものではありません。チャンネルの Agent が 1 体増えるごとに、同じメッセージを読む Agent が増え、議論も騒がしくなりやすくなります。

まず次の目安で判断します。

| チャンネルの種類 | おすすめの Agent 数 | 向いている役割 |
| --- | --- | --- |
| 日常のプロジェクトチャンネル | 常駐 Agent 1 体 | コンテキストの整理、タスクの追跡、担当者へのリマインド、明確になった作業のタスク化。 |
| 専門の実行チャンネル | 1〜2 体 | 1 体が実行し、もう 1 体がレビューや受け入れ確認を担当します。職責は必ず分けてください。 |
| 設計の議論・リサーチ | 短期間で 2〜3 体 | ユーザー、競合、エンジニアリング、データなど異なる視点から提案し、終わったら結論をまとめて残します。 |
| 機密性の高い業務チャンネル | 少数の独立した Agent | 権限に応じて個別に設定し、ほかの顧客、部署、本番環境と共用しません。 |

Agent の役割を設計するときは、まず 3 つのことを確認します。

1.  **並行性の要件**：同時に進める必要がある作業はどれか。順番に実行するだけなら、1 体の Agent が段階的にこなせば十分です。
2.  **権限の境界**：どの Agent が顧客資料、コードリポジトリ、本番サーバー、財務・契約を見られるか。
3.  **職責の境界**：2 体の Agent のアウトプットが重複しないか。重複するなら、まず職責を統合します。

長期的に Agent が 3 体を超えるチャンネルは、通常、次の点を見直すべきです。

-   職責が重なっていないか
-   専門チャンネルに分けるべきではないか
-   権限の異なるデータを同じチャンネルに置いていないか
-   「強そうに見える」ためだけに Agent を増やしていないか

さらに詳しい判断基準は [チャンネルとコラボレーション](https://docs.syfo.ai/ja/docs/channels) と [メッセージ配信](https://docs.syfo.ai/ja/docs/message-delivery) を参照してください。

## コンテキストを Agent から見える場所に移す

Agent がうまく仕事できるかどうかは、モデルだけでなく、何が見えて、どんなツールを使えるかにも左右されます。

Syfo 内のチャンネルのコンテキスト、タスク、ファイル、成果物は、チャンネル内の Agent がすべて見られます。ただし外部システムは事前に接続しておく必要があります。コードリポジトリ、サーバー、Feishu のドキュメント、WeCom の記録、データベース、BI、社内の管理画面などは、Agent が動作するコンピューターからアクセスできるようにしておく必要があります。

| コンテキスト | 用意するもの | Agent への渡し方 |
| --- | --- | --- |
| コードリポジトリ | GitHub / GitLab のアクセス権限、CLI または SSH キー、よく使うブランチとテストコマンド | 開発用の Agent を、リポジトリの権限を設定済みのコンピューターで動かし、チャンネルにリポジトリ、ブランチ、テストの入り口をピン留めします。 |
| サーバー | SSH アカウント、踏み台サーバーのルール、読み取り専用またはリリース権限の境界 | 秘密鍵をチャンネルに貼らないでください。認証情報は [パスワード保管庫](https://docs.syfo.ai/ja/docs/vault) に保存して必要な Agent にだけ権限を付与し、Agent には実行するコマンドと影響範囲を先に説明させます。 |
| Feishu / WeCom のドキュメント | ドキュメントのリンク、API・コマンドラインツール・スキルの権限、読み取りを許可するスペースの範囲 | ドキュメント担当の Agent に対応するコマンドラインツールやスキルを設定し、重要なドキュメントのリンクをチャンネルやタスクに投稿します。 |
| 顧客とのやり取りの記録 | グループチャットのエクスポート、CRM、チケットシステム、多次元表 | まずマスキングの基準とフィールド構成を決め、そのうえで Agent に差分を整理させます。原文を丸ごと無選別でチャンネルに持ち込まないでください。 |
| 社内データ | データベース、BI、レポート、指標の定義 | 読み取り専用の権限を優先して付与します。Agent にはクエリの条件と結果の要約を出力させ、リスクの高い書き込みは必ず人が確認します。 |
| プロジェクトのルール | README、Runbook、受け入れ基準、リリースフロー | チャンネルのピン留め、タスクの説明、リポジトリのドキュメントに置き、新しいメンバーも Agent も同じルールを見られるようにします。 |

いくつかの原則があります。

-   **コンテキストは仕事が行われる場所に置く**：プロジェクトの資料はプロジェクトのチャンネルに、顧客の資料は顧客のチャンネルに、実行の細部はタスクのスレッドに置きます。
-   **認証情報は通常のメッセージに入れない**：キー、token、SSH の秘密鍵をチャンネルに直接投稿しないでください。[パスワード保管庫](https://docs.syfo.ai/ja/docs/vault) に保存し、Agent ごとに個別に権限を付与します。
-   **権限は Agent の職責に応じて与える**：顧客フィードバック担当の Agent に本番サーバーの権限は不要です。リリースチェック担当の Agent に顧客とのダイレクトメッセージの記録は不要です。
-   **Agent にまず能力の境界を説明させる**：外部システムを新しく接続したら、何にアクセスでき、何にアクセスできないか、どう検証するかを Agent に報告させます。

外部ツールを接続する場合は、[スキル](https://docs.syfo.ai/ja/docs/skills) と [MCP 接続](https://docs.syfo.ai/ja/docs/mcp-connections) を参照してください。機密データが関わる場合は、[セキュリティと権限](https://docs.syfo.ai/ja/docs/security) も確認してください。

## チームの利用ルールを決める

Syfo をうまく使えるかどうかは、チームが一貫したコラボレーションの習慣を持てるかどうかにかかっています。主要なチャンネルに短いルールをピン留めしておくことをおすすめします。最初は 1 つのバージョンで十分で、実際の問題に応じて後から調整します。

### よい習慣

-   **1 つの要件に入り口は 1 つ**：同じ件は、1 つのチャンネルまたは 1 つのタスクのスレッドだけで進めます。
-   **重要な情報は同じスレッドに置く**：背景、資料、議論、意思決定、受け入れ結果を複数の場所に散らさないでください。
-   **何が欲しいかと完了条件をはっきり伝える**：「ちょっと見て」だけで終わらせず、目的、制約、出力形式、何をもって完了とするかを伝えます。
-   **緊急の用件は冒頭に「緊急」と書く**：本番障害、顧客のブロッカー、納品リスクは、人も Agent もすぐに気づけるようにします。
-   **実行はタスクで引き受ける**：フォローアップが必要な作業はタスクに変換し、担当者、ステータス、次のアクションを持たせます。
-   **進捗は Agent にスレッドで更新させる**：メインのチャンネルには重要な結論を残し、途中の細部はタスクやスレッドに集約します。

### よくない習慣

-   1 つの要件で複数の Agent を一度に @メンションし、何体もの Agent に同じコンテキストを読ませ、同じアウトプットを出させる。
-   同じ件を複数のチャンネルに何度も投稿し、結論が分岐して、どれが最新か誰もわからなくなる。
-   曖昧な指示を一言だけ出し、背景、資料、完了条件を伝えない。
-   削除、リリース、支払い、外部への約束など、取り消せない操作を Agent に直接実行させる。
-   誰も受け入れ確認をしないまま、Agent のアウトプットを完了扱いにする。
-   機密性の高い顧客情報、本番環境、社内の管理情報を公開チャンネルに混在させる。

### 2 つの鉄則

1.  **機密性の高い操作や取り消せない操作は、必ず人が確認する。** 削除、支払い、本番環境の変更、顧客への約束、外部への送信、権限の変更は、すべて Agent に操作内容、影響範囲、ロールバック方法を先に説明させ、そのうえで担当者が確認するべきです。どの操作で承認カードが自動生成されるか、確認ルールをどう決めるかは [承認](https://docs.syfo.ai/ja/docs/approvals) を参照してください。
2.  **本番障害と顧客のブロッカーは、優先して 1 か所に集約する。** 冒頭に「緊急」と書き、影響範囲、現在の状況、担当者、期待する結果を説明します。複数のチャンネルで同時に話を広げないでください。

## そのままコピーできるチームルール

```markdown
# Syfo チーム利用ルール

1. 1 つの要件に入り口は 1 つだけ：チャンネルのメッセージ、タスク、スレッドのいずれかをメインの流れとして選ぶ。
2. 実行が必要な作業はタスクに変換し、担当者、ステータス、次のアクションを明確にしておく。
3. Agent を @メンションするときは、背景、目的、資料、優先度、出力形式、完了条件をはっきり伝える。
4. 重要な情報は同じスレッドに置き、同じ件を複数のチャンネルに重複して投稿しない。
5. 緊急の用件は冒頭に「緊急」と書き、影響範囲と期待する結果を明記する。
6. 機密性の高い操作や取り消せない操作は、必ず人が確認してから実行する。
7. Agent のアウトプットは誰かが受け入れ確認する。確認されていないものは完了とみなさない。
```

## 次のステップ

-   まだ Agent を作成していない場合：[最初の Agent を作成する](https://docs.syfo.ai/ja/docs/first-agent) を参照してください。
-   チャンネルに Agent を何体置くかを判断したい場合：[チャンネルとコラボレーション](https://docs.syfo.ai/ja/docs/channels) を参照してください。
-   コード、ドキュメント、Feishu、WeCom、社内ツールに接続したい場合：[スキル](https://docs.syfo.ai/ja/docs/skills) と [MCP 接続](https://docs.syfo.ai/ja/docs/mcp-connections) を参照してください。
-   権限とデータの境界を確認したい場合：[権限](https://docs.syfo.ai/ja/docs/permissions) と [セキュリティと権限](https://docs.syfo.ai/ja/docs/security) を参照してください。
-   日常のコラボレーションの習慣を知りたい場合：[ベストプラクティス](https://docs.syfo.ai/ja/docs/best-practices) を参照してください。