CASE STUDY ・ WEBサービス ・ ChatworkとTeamsの連携を設計する｜MentionRelay事例（仮称）
- Chatwork
- Microsoft Teams
- 業務連携
- 通知管理
- 運用設計
- NestJS
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
チャット連携で先に決める四つの境界。
- どの通知をどの担当チャネルへ渡すかを一覧化する転送対象
メンションの条件、転送先、除外ルーム
- 状態変更と引き継ぎの責任者を決める未返信の確認
未返信とみなす状態、確認者、再通知条件
- 担当変更と例外処理を記録する担当の可視化
部署・PM・ルームの責任者、交代手順
- 判定結果と設定変更を監査できるようにする内容の統制
NGワード、警告・停止の条件、承認者
WebhookとGraphを使い、受信から記録までを一つの流れにする。
MentionRelayは、Chatwork Webhookでメンションを受け、Microsoft Graphを介して担当Teamsチャネルへ渡す構成です。未返信の状態は定期チェックと再通知の業務フローで扱い、部署・PM・ルームの対応関係をダッシュボードで確認します。
技術要素はVue.js、Ant Design Vue、Chart.js、NestJS、Chatwork API、Microsoft Graph、MySQL、スケジュール実行、NATS、Socket.IOです。利用企業側では、API権限、チャットデータの保存期間、ログへのアクセス権、送信停止を含むNGワード運用を自社規程に合わせて定義する必要があります。
- 領域 01受信課題
Chatwork側で対象メンションを受け取る
解決策WebhookとAPI権限の境界を確認
- 領域 02振り分け課題
ルームと担当部署の対応付けを参照
解決策Teamsの宛先と除外条件を定義
- 領域 03確認課題
未返信の状態、経過時間、再通知の有無を記録
解決策確認者と引き継ぎ条件を定義
- 領域 04管理課題
担当設定とNGワードの扱いを変更
解決策変更履歴、権限、停止条件を定義
「通知」から「責任の記録」までを導入判断にする。
MentionRelayの公開範囲から読み取れるのは、二つのチャットを接続し、通知・未返信・担当・内容設定を一つの運用導線に置く設計です。転送機能の有無だけで比較せず、どの状態を誰が確認し、どの証跡を残すかを導入条件に含めます。
この事例の根拠と読み方
根拠は、AMELAの移行記録、匿名化したMentionRelayの開発ストーリー、公開用にモック化されたデモ画面です。対象期間は開発範囲であり、稼働後の返信率、転送速度、監視ルーム数、対応時間、見逃し削減、コンプライアンス効果、セキュリティ、SLA、売上や顧客満足度を示す期間ではありません。プロジェクト名、顧客名、画面上の人物・件数・日時は機密保持のため匿名化またはモック化しています。
本文は設計範囲と確認項目を示すもので、特定企業の運用成果や法的適合性を保証するものではありません。
読者が使える実践ツール
RFPやデモ確認では、次の表を自社のチャット連携に合わせて埋めてください。記入例はMentionRelayで確認できる設計範囲をもとにした一般例であり、特定企業の設定値ではありません。
| 確認領域 | 先に決めること | 運用時に残す証跡 | 未確認の成果 |
|---|---|---|---|
| 転送対象 | メンションの条件、転送先、除外ルーム | 受信時刻、ルーム、担当チャネル、転送結果 | 見逃し削減率は未測定 |
| 未返信確認 | 未返信とみなす状態、確認者、再通知条件 | 状態変更、確認者、再通知履歴 | 返信率と対応時間は未測定 |
| 担当管理 | 部署・PM・ルームの責任者、交代手順 | 担当変更、引き継ぎ、例外処理 | 属人化解消の効果は未測定 |
| 内容の統制 | NGワード、警告・停止の条件、承認者 | 判定結果、対応、設定変更履歴 | 違反抑止効果は未測定 |
表の各欄が埋まらない場合は、連携の実装より先に運用責任を決める必要があります。特に、転送の失敗、API権限の変更、担当者不在、誤検知を誰が処理するかを受入条件に含めてください。
