このガイドでは、@Waker をチーム作業の共有 IM エントリーポイントとして使用する方法を示します。接続すると、グループメンバーは常に同じボットまたはアカウントをメンションします。そのアイデンティティの裏側で、QoderWake がタスクを認識し、適切な Waker を選択し、同じ IM アイデンティティを通じて進捗と結果を返します。
コード変更、計画、データ分析、ドキュメントなどの作業を実行・フォローアップ・成果物提供するには @Waker を使用します。知識から回答する繰り返し質問には Group Chat Q&A Specialist を使用します。どちらも同じチームに提供できますが、解決する問題は異なります。
コラボレーションパターンの選択
| パターン | 作業の開始方法 | 最適な用途 |
|---|
| グループボットまたは接続済みアカウント | 共有アイデンティティをメンションしてタスクを説明する | チームで追跡するプロジェクト納品、インシデント対応、運用作業 |
| IM ダイレクトチャット | 通常のメッセージを送信する。メンションは不要 | 個人のリサーチ、計画作成、反復的な編集、プライベートな確認 |
1 つのボットが複数の Waker を接続する方法
共有エントリーポイントとして、グループには 1 つのボットまたはアカウントのみを接続します。メンバーは、その裏側でいくつの Waker が設定されているかを知る必要も、各ロールの個別のアドレスを記憶する必要もありません。すべてのメンションの後、QoderWake は以下を判断します。
- メッセージが新しいタスクを開始するのか、既存の作業を継続・確認・変更・キャンセルするのか。
- 依頼者が新しいタスクについて Waker または責任範囲を明示的に選択したかどうか。
- 選択されていない場合、ルーティングルールが一致するかどうか。ルールが一致しない場合、デフォルトの Waker が応答するか、確認を求めます。
- どの Waker がタスクを実行するか。タスクステータスがその Waker を識別し、同じボットまたはアカウントがすべてのメッセージをグループに返します。
グループで議論 → 同じボットをメンション → タスクの関係を特定 → Waker にルーティング
→ 同じボットが進捗と結果を返す → 人間が承認 → タスクを継続
ロールアウト基準の設定
IM 接続、チャットペアリング、Waker 割り当て、Wake-up Mode の完全な設定については、@Waker を参照してください。このプラクティスでは、シナリオのロールアウト前に一致させるべき基準のみを保持します。
チャットに 2〜4 つの補完的な Waker を割り当てます。
- 各 Waker が何を担当し、何が明確に範囲外かを定義します。「General Assistant」などの広範なロールは避けてください。
- 一般的なリクエストを処理し、意図を判断し、確認質問を行えるデフォルトの Waker を選択します。
- 作業の各カテゴリに対してルーティングルールを追加し、コードマージ、本番変更、外部公開に対して人間の承認境界を設定します。
- 各 Waker の応答モデル、ワークスペース、ファイル権限を設定します。その責任範囲が必要とするディレクトリのみを含めます。
- チャットを保存し、
Active であることを確認して、@Waker をオンにします。テストグループで、同じボットを使用して 2 つのカテゴリの作業を開始します。タスクステータスに異なる Waker が表示され、表示上の送信者が変わらないことを確認します。
@Waker を有効にするときは、チャットと応答する Waker を選択し、デフォルトの Waker、モデル、関連する権限を設定します。
ページに Check Responsibility Conflicts が提供されている場合は、ロールアウト前に実行してください。まず重複する責任範囲を絞り込み、意図的な重複がある箇所にルーティング優先度を追加します。
Scenario 1: プロジェクトグループからエンジニアリング成果物を目指す
このパターンは、要件、実装、テスト、リリース準備を 1 つのグループで連携させる場合に使用します。ボットは確定した議論を作業に変えて進行させ、一方でスコープ、マージ、リリースの判断はプロジェクトの責任者が保持します。
責任範囲を構成する
| Waker | 担当するもの | 担当しないもの |
|---|
| Project Coordinator (default) | 要件の分解、スケジュール、進捗、リスク | アプリケーションコードの編集は行わない |
| Engineering Executor | コード調査、実装、テスト | スコープや本番リリースの決定は行わない |
| QA Reviewer | テスト設計、リグレッション、受け入れサマリー | 本番リリースの承認は行わない |
要件の分解、スケジュール、進捗サマリーは Project Coordinator にルーティングします。コード、ビルド、トラブルシューティングは Engineering Executor にルーティングします。テストケース、リグレッション、受け入れ結果は QA Reviewer にルーティングします。コードのマージと本番リリースには、必ず人間の承認が必要です。
ワークフローに従う
1. 確定した議論を作業に変える
チームは通常どおり議論します。スコープが確定したら、責任者が共有ボットにメンションします。
プロダクトオーナー（通常のメッセージ）: 今回のリリースで変更するのはクーポン併用の検証だけです。クーポン取得フローは変更しません。
エンジニアリング責任者: @ProjectBot 新規タスク: 上記の議論をもとに、デリバリー作業を分解してください。
成果物: 担当者、依存関係、受け入れ基準、リスクを含む、エンジニアリング、QA、リリース準備のチェックリスト。
制約: 金曜日までに完了してください。まだコードは編集しないでください。
2. 承認済みの作業を並行して実行する
責任者が分解内容を確認した後も、チームは同じボットを使い続けます。
エンジニアリング責任者: @ProjectBot 新規タスク: クーポン併用の検証を調査し、承認済みの変更を実装して、単体テストを実行してください。コードはマージしないでください。
QA 責任者: @ProjectBot 新規タスク: 承認済みの受け入れ基準からエッジケースを追加してください。実装と並行して実行してください。
3. 元のグループでフォローアップする
エンジニアリング責任者: @ProjectBot 実装タスクの状況を報告してください。新しいタスクは作成しないでください。
エンジニアリング責任者: @ProjectBot 実装タスクを継続し、既存のクーポンとの互換性を確認してください。
4. 重要な操作の前に人間のゲートを設ける
コードマージ、リリース、本番変更を分析と 1 つの依頼にまとめないでください。まず Waker に準備状況、リスク、ロールバック手順を返させ、責任者が操作を承認した後に限り同じタスクを継続します。
グループでの承認メッセージでも、同じボットにメンションし、それが継続するタスクを特定する必要があります。
エンジニアリング責任者: @ProjectBot ビルド調査を継続してください。
変更を確認してテストを実行しますが、コードはマージしないでください。
DingTalk グループでは、同じ Project Bot が計画準備とビルド調査を異なる Waker にルーティングします。タスクステータスが実行中の Waker を示し、すべてのメッセージは同じボットを通じて返されます。
Scenario 2: IM ダイレクトチャットで個人の作業を完了する
ダイレクトチャットは、資料の整理、提案の準備、データ分析、チームに持ち帰る前のドラフトの反復作業に適しています。1 つの役割がほとんどの作業をカバーする場合はデフォルトの Waker を 1 つ割り当て、責任範囲が明確に異なる場合に限り専門の Waker を追加します。
責任範囲を構成する
Personal Work Assistant (default): 資料の整理、計画の準備、成果物の修正。Data Analyst (optional): テーブル、指標、知見の処理。指定されたデータディレクトリのみアクセス可能。
ワークフローに従う
ダイレクトチャットではメンションは不要です。最初のメッセージがタスクを作成し、明示的な「Continue」がそれをフォローアップします。
新規タスク: 添付された顧客インタビューのメモを要件サマリーにまとめてください。
成果物: 「問題」「根拠」「推奨事項」「未解決の質問」に整理し、Markdown ファイルを作成してください。
制約: 氏名と連絡先を削除してください。インタビューにない結論を作らないでください。
インタビューサマリーのタスクを継続し、影響度と実装コストに基づいて推奨事項を順位付けしてください。
新規タスク: Data Analyst に添付のフィードバック統計を処理させてください。インタビューサマリーのタスクとは分けてください。
DingTalk のダイレクトチャットでは、生成されたドキュメントがクリック可能なリンクとして返され、フォローアップがタスクを継続して同じ成果物を更新します。
@Waker は、タスクが生成したドキュメント、画像、スプレッドシートを納品できます。DingTalk では、QoderWake は現在成果物を DingTalk ファイルストレージにアップロードし、受信者にダウンロード権限を付与し、同じ返信内でクリック可能なリンクを返します。ネイティブのファイルバブルとしては表示されません。Feishu やその他のチャネルでの表示、および Automatically Send Artifact Files を有効にする必要があるかどうかは、接続設定に依存します。コード変更は添付ファイルとして送信されません。
シナリオ3：インシデントグループでの調査と復旧の支援
インシデントグループでは、共有された事実をすばやく確立し、原因を並行して調査し、レビュー可能な復旧計画を準備する必要があります。1つのボットがすべてのリクエストを受け付け、バックエンドのWakerが作業を分担します。本番環境へのすべての操作は、人間の承認の対象のままです。
責任範囲を設定する
| Waker | 担当する範囲 | 担当しない範囲 |
|---|
| Incident Coordinator（デフォルト） | タイムライン、影響範囲、進捗、アクションの追跡 | システム変更は実行しない |
| Engineering Investigator | コード、スタックトレース、最近の変更 | 本番環境を直接操作しない |
| Operations Analyst | モニタリング、ログ、キャパシティ、復旧手順 | 承認なしでの再起動、スケール、デプロイは行わない |
影響範囲、タイムライン、進捗サマリーは Incident Coordinator にルーティングします。コード、スタックトレース、バージョン変更は Engineering Investigator にルーティングします。モニタリング、ログ、キャパシティ、復旧計画は Operations Analyst にルーティングします。本番環境を変更する場合は、必ず手順、リスク、ロールバック計画を提示し、人間の承認を待ちます。
ワークフローに従う
1. インシデントの概要を確立する
インシデント責任者: @IncidentBot 新規タスク: インシデントサマリーを作成してください。
症状: 午後 2 時 5 分から注文送信の失敗が増加しています。影響範囲はまだ確認できていません。
入力: マスキング済みのログとモニタリングのスクリーンショットを添付しています。
成果物: タイムライン、影響範囲、既知の事実、検証すべき仮説、次のステップの担当者。
制約: 再起動、スケール、ロールバック、デプロイは行わないでください。
2. 技術的な調査を並行して開始する
エンジニアリング責任者: @IncidentBot 新規タスク: 最新リリースとスタックトレースを比較してください。根拠と修正案だけを返してください。
インシデント責任者: @IncidentBot 新規タスク: モニタリングとログを調査してください。復旧計画、リスク、監視シグナルを返してください。実行はしないでください。
3. 発見事項を統合し、承認を依頼する
インシデント責任者: @IncidentBot インシデントサマリーのタスクを継続してください。エンジニアリングと運用の調査結果を追加し、承認が必要な復旧操作とそのロールバック方法をすべて列挙してください。
DingTalk のグループでは、同じ Incident Bot がインシデントの統合とログ分析を異なる Waker にルーティングし、すべての結果を返すと同時に、人間の承認ゲートを維持します。
編集処理っていないログを添付しないでください。また、「できるだけ速やかにサービスを復旧する」を、明示的に禁止する操作や承認境界の代わりに使うことは避けてください。
シナリオ4：運用グループでのコンテンツ作成とレビュー
このパターンは、テーマ計画、ドラフト作成、データ検証、公開レビューに使用します。メンバーは常に同じOperations Botを使い、最終的な外部公開は人間の判断に委ねられます。
責任範囲を設定する
Content Planner（デフォルト）：読者の理解、テーマ計画、ドラフト作成、コンテンツの修正。Data Analyst：出典、計算、グラフ定義の検証。Publishing Reviewer：事実、機密情報、リンク、アセットの権利、公開準備状況の確認。自動では公開しない。
ワークフローに従う
運用責任者: @OperationsBot 新規タスク:
添付された公開済みの製品資料をもとに、ローンチ記事の下書きを作成してください。
対象読者: 製品を初めて使用するエンジニアリングチーム。
成果物: タイトル案 3 件、初稿、画像リスト。
未解決事項: まだ確認が必要な事実。
制約: 社内リンクや未公開データを使用しないでください。
公開しないでください。
運用責任者: @OperationsBot 新規タスク:
完成したローンチ記事の指標と出典を検証してください。
成果物: 修正または確認が必要な項目の一覧。
制約: 下書きは書き換えないでください。
運用責任者: @OperationsBot 新規タスク:
完成したローンチ記事の公開前レビューを行ってください。
確認項目: 事実の正確性、機密情報、リンク、アセットの権利。
制約: 未解決の項目はすべて、人間による確認が必要であることを明記してください。
公開しないでください。
再利用可能なリクエスト構造を使用する
通常、実行者を名指しする必要はありません。作業内容を記述し、ルーティングに選択させます。
@Bot [新規タスク / タスクを継続 / 状況を報告 / タスクを変更 / タスクをキャンセル]
目的: 解決する問題
入力: ファイル、リンク、ディレクトリ、または確認済みの結論
成果物: 必要な応答、ファイル、完了基準
制約: 禁止事項、権限の境界、期限、承認ゲート
担当: 自動ルーティングを上書きする場合のみ、Waker 名または責任範囲を指定（任意）
| 意図 | 推奨される表現 |
|---|
| タスクを続行する | 「ビルド調査を続行し、依存関係のバージョンも確認してください。」 |
| 別のタスクを開始する | 「新規タスク: リリースノートを作成してください。これは調査とは関係ありません。」 |
| 進捗を確認する | 「ビルド調査のステータスを報告してください。新しいタスクは作成しないでください。」 |
| タスクを変更する | 「成果物を修復計画のみに変更してください。まだコードは編集しないでください。」 |
| タスクをキャンセルする | 「リリースノートのタスクをキャンセルしてください。」 |
ワークフローを検証し維持する
より広い展開を行う前に、テストグループでこれらのチェックを完了します。
- グループに表示されるボットまたはアカウントは 1 つだけです。異なる作業は異なる Waker にルーティングされ、タスクステータスが実行者を示します。
- 通常のグループメッセージはタスクを作成しませんが、正しいメンションにより直近の議論をコンテキストとして使うことができます。
- 続行、新規タスク、ステータス、変更、キャンセルのすべてが意図したタスクを対象とします。
- Waker は許可されたワークスペースにのみアクセスでき、コードのマージ、本番環境への変更、外部公開は人間の承認を維持します。
- グループに返されるテキスト、画像、ファイルに、認証情報、個人情報、別のチャットからのデータが含まれていません。
ワークフローがデータを生成した後、Task Records を使用して、依頼者、ステータス、要約、納品されたファイルを確認します。関連するデータが存在する場合、Topic Records と Group Memory も表示されることがあります。メモリには、安定したチームの慣習、プロジェクトの境界、納品フォーマットのみを保持します。一時的な進捗、アクセストークン、個人情報、未検証の結論は保持しないでください。
Waker、デフォルトの Waker、モデル、ワークスペース、権限、ルーティングルールが変化するたびに、同じボットを使用して 1 つのデフォルトルートと 1 つの専門ルートを再テストします。 
ダイレクトチャットは資格情報のチャネルではありません。パスワード、トークン、顧客の機微データ、その他の機密情報は、保護された資格情報やデータ接続を通じて提供してください。
