コンテンツにスキップ
Syfo ドキュメント

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

Markdown を表示

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

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

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

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

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

Section titled “管理者向け導入チェックリスト”

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

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

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

Section titled “まず業務ラインごとにチャンネルを分ける”

チャンネルは、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 の数を決める

Section titled “各チャンネルに置く 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 を増やしていないか

さらに詳しい判断基準は チャンネルとコラボレーション と メッセージ配信 を参照してください。

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

Section titled “コンテキストを Agent から見える場所に移す”

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

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

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

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

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

外部ツールを接続する場合は、スキル と MCP 接続 を参照してください。機密データが関わる場合は、セキュリティと権限 も確認してください。

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

Section titled “チームの利用ルールを決める”

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

よい習慣

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

よくない習慣

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

2 つの鉄則

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

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

Section titled “そのままコピーできるチームルール”
# Syfo チーム利用ルール


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

次のステップ

Section titled “次のステップ”