複数プラットフォーム メッセージ通知
WeChat、Dingtalk、Telegram、Slack——どこにでも送信できます
通知のこと、思ったより面倒
大事メッセージ見落とし、各プラットフォーム単独操作、手動で人に@するのが疲れる
真夜中3時にサーバーダウン。アラートメール送られたけど見てない。スマートフォンは钉钉の通知だけON。朝9時に会社到着して気づいた。顧客が6時間のクレーム
チーム日報を3回催促してるやつも。钉钉で@かけて、WeChatで@かけた。誰かがTelegramだけ見る。同じメッセージを3回配信。
もっと困るのがクロスチーム協力。国内チームは钉钉、海外チームはSlack、顧客グループはWeChat。通知は3つのプラットフォームで、形式がバラバラ。毎日メッセージ送信で30分。忘れるプラットフォームもある
OpenClawがすべての通知チャネルを管理
OpenClawに誰に、何を、どのプラットフォーム。それで、WeChat、钉钉、Telegram、Slack、メール、SMS。
ワンコマンドで、全チャネルカバー5つのAppを行ったり来たり不要
さらにすごいのは条件トリガー——「CPU が 90% を超えたら Dingtalk でアラートを送る」「毎日午後 5 時に日報を催促する」「GitHub に新しい Release が出たら WeChat で通知する」といった設定ができます。あなたが見張っている必要はなく、OpenClaw が見張っていて、送る時が来たら自動で送ります。
通知内容もインテリジェントに生成されます——固い雛形ではありません。たとえばアラート メッセージには主要な指標と推奨操作が自動で付きますし、日報の催促メッセージには誰がまだ提出していないかのリストが自動で付きます。
3 つの通知 Prompt——最も一般的なシナリオをカバー
アラート、リマインダー、コンテンツ配信——3 つの方向をそのまま使える
サーバーの CPU が 90% を超えた時、同時に Dingtalk と Telegram にアラートを送信
ゴールデン指示
サーバー監視アラート ワークフローを設定してください：
監視対象：
- CPU 使用率 > 90%（3 分以上続く）
- メモリ使用率 > 85%
- ディスク使用率 > 90%
- サービス応答時間 > 5 秒
アラートルール：
- トリガー後、同時に送信：Dingtalk 運用グループ + Telegram 個人
- アラート メッセージ フォーマット：
🚨 サーバーアラート
サーバー：[ホスト名/IP]
指標：[CPU/メモリ/ディスク/応答時間]
現在値：[数値]
トリガー時刻：[時刻]
推奨操作：[指標タイプに基づく提案]
- 同一指標は 30 分以内に重複アラートなし（スパム防止）
- 回復後は回復通知を送信運用必須。深夜に問題が発生しても「メールを見つけるまで」待たなくてはいけません。Dingtalk と Telegram は同時に通知が来るので、スマホでどちらか一つは見られます。30 分の重複排除により、深夜に 20 回もアラートで叩き起こされることを避けられます。
毎日午後 5 時、チームに日報の提出を催促し、未提出の人に再度催促
初心者向け
毎日午後 5:00 に以下のプロセスを実行：
1. 日報システム（または共有ドキュメント）をチェック、本日提出済みの人員を取得
2. チームの花名簿と比較、未提出者を特定
3. Dingtalk/Feishu グループで送信：
"📝 日報リマインダー
以下の同僚は本日の日報をまだ提出していません、急いでください：
@Taro @Hanako @Jiro
提出先：[リンク]"
4. 午後 6:30 になってもまだ提出していない場合、再度催促：
"⏰ 2 次催促
@Taro @Jiro 日報をまだ提出していません～今日のことは今日のうちに 🙏"
5. 毎週金曜日に週間の報告率を集計：
"本週日報報告率：92%
皆勤：[名単]
漏れあり：[名単と漏れ日数]"管理者が最も嫌なことの一つ：日報の催促。この Prompt は催促の作業を完全に自動化し、さらに集計機能も付いています。もう群れの中で一人一人 @ する必要はなく、見た目も良いです。
GitHub Release Notes を自動翻訳して WeChat 公式アカウントに送信
応用技法
GitHub リポジトリ [owner/repo] の Release を監視：
新しい Release が公開された時：
1. Release 情報を取得：バージョン番号、発布日時、Release Notes 全文
2. 英語 Release Notes を中国語に翻訳、要件：
- 技術用語は英語で保持（API、SDK、Bug Fix など）
- わかりやすい言葉で、翻訳っぽくない
- 重大な変更（Breaking Changes）を特別に標注
3. WeChat 公式アカウントのフォーマットでレイアウト：
- タイトル：[プロジェクト名] v[バージョン] がリリースされました！
- 本文：新機能概要 + 完全な更新ログ
- 下部：GitHub リンク + ダウンロード URL
4. 公式アカウント API 経由でドラフトとして公開（または直接公開）
5. WeChat 技術交流グループに同時にメッセージを送信オープンソースプロジェクトまたは技術チームの必須ツール。毎回のリリースで公式アカウント記事を手動で書く必要がなく、Release Notes は自動翻訳 + レイアウト + 公開され、リリースからユーザーが知るまで数分しかかかりません。
複数プラットフォーム通知設定
一度にすべてのチャネルを設定すれば、その後のすべての通知は自動配信されます。
通知チャネル設定テンプレート
# 複数プラットフォーム通知チャネル設定
# ================================
チャネル 1：Dingtalk グループボット
- タイプ：Webhook
- URL：https://oapi.dingtalk.com/robot/send?access_token=xxx
- 署名キー：SEC...
- 用途：内部チーム通知、アラート
チャネル 2：WeChat Enterprise
- タイプ：Webhook
- URL：https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx
- 用途：日報催促、データレポート
チャネル 3：Telegram Bot
- タイプ：Bot API
- Token：bot_token_here
- Chat ID：-100xxxxxxxxx（グループ）/ 個人 ID
- 用途：個人アラート、重要リマインダー
チャネル 4：Slack
- タイプ：Incoming Webhook
- URL：https://hooks.slack.com/services/xxx
- チャネル：#deployments / #general
- 用途：海外チーム通知、デプロイ状態
チャネル 5：メール
- タイプ：SMTP
- 用途：公式通知、記録が必要な場合
通知ルール：
- アラート → Dingtalk + Telegram（確実に見える）
- 日常リマインダー → Dingtalk/WeChat Enterprise（仕事シナリオ）
- クロスチーム → Slack + Dingtalk（国内外カバー）
- 公式通知 → メール（記録）OpenClaw vs 単一通知ツール
OpenClaw 統合通知
- 一つの指示ですべてのプラットフォームに送信、一つずつ操作する必要がありません
- 通知内容はインテリジェントに生成、固い雛形ではありません
- 条件トリガーをサポート——条件を満たしたら自動送信、見張る必要がありません
- 上流と下流を連鎖させることができます：先に監視 → 次に分析 → 最後に通知
- 新しいチャネルを追加するには Webhook を設定するだけ、5 分で完成
VS
Server 酱 / Bark / PushDeer など
- 通常は 1～2 個のチャネルのみをサポート、複数プラットフォームには複数のツールが必要
- 固定テンプレート メッセージのみ送信可能、コンテンツに基づいて知的に調整することはできません
- トリガー ロジックは自分でスクリプトを書くか cron を設定する必要があります
- 純粋な通知ツール、上流データを処理できません
- 軽量で使いやすく、個人の単純なシナリオに適しています
実践シナリオ：国際チームのメッセージ同期
国内は Dingtalk、海外は Slack、顧客は WeChat グループ——一つのメッセージを 3 回送る必要があります
国内運用は Dingtalk、海外倉庫は Slack、大手顧客は WeChat グループにいる越境 e コマース企業。重要な通知（在庫警告、物流異常、大型プロモーション）があるたびに、営業マネージャーは 3 つのプラットフォームで別々に編集・送信する必要があり、フォーマットも異なります。
OpenClaw 方案
通知内容を一度書けば、OpenClaw が 3 つのプラットフォームのフォーマットに自動適応して一斉に送信します。Dingtalk に中国語版、Slack に英語版、WeChat グループに顧客向けバージョンを送信します。在庫が安全ラインを下回ったら自動トリガーされ、バックエンドのデータを見張る必要がありません。営業マネージャーはもう「人肉メッセージリレーステーション」ではありません。
人手による通知
重要なメッセージごとに、営業マネージャーは Dingtalk で入力し、Slack に切り替えて英語でもう一度入力し、WeChat に切り替えて別のトーンで入力します。緊急時には、通知を送るだけで 15 分かかり、海外チームが見るころには既に 30 分以上経っています。前回は Slack への送信を忘れ、海外倉庫は大型プロモーション備蓄通知を受け取らず、品切れかけました。
通知管理の小技巧
アラート通知は必ず重複排除と沈黙期間を設定してください。サーバーの CPU が飛び上がれば、1 分間に 60 件のアラートが送信され、誰も耐えられません。「同一指標は 30 分以内に重複アラートなし」を設定すれば、漏れもなくスパムもありません。
異なる緊急度の通知は異なるチャネルを使用してください。一般的なリマインダーはグループに送ればいいのですが、緊急アラートは同時にグループ + 個人 + スマホ通知で送る必要があります。段階的に処理し、すべてのメッセージに最高優先度を使わないでください。そうしないと、本当に緊急の時にみんなが麻痺しています。
Webhook アドレスと Bot Token は機密情報です。コードに直接書いたり平文で保存したりしないでください。環境変数またはキー管理サービスで保管し、漏洩したら直ちに変更してください。