Chatwork API は、ビジネスチャット「Chatwork」のメッセージ・タスク・ルームをプログラムから操作するための API だ。日本の企業で Chatwork を使っているなら、業務通知や自動化のハブとして組み込みやすい。
典型的な使い方
実務で多いのは「結果を投げる」用途だ。CI/CD のビルド結果、サーバー監視のアラート、バッチ処理の完了通知などを特定のルームに自動投稿する。メッセージ送信だけなら実装はごく軽い。さらにタスクの作成・完了操作も API でできるため、チケット管理システムと連動させて Chatwork 側のタスクを自動で起こす、といった連携も組める。Chatwork 独自の記法（[To]、[info] タグなど）をメッセージに埋め込めば、通知の重要度を視覚的に伝えられる。
レート制限の落とし穴
料金面で押さえておきたいのは、API はフリープランでも使えるが、レート制限が厳しいという点だ。通知が増えてくるとフリープランの制限に当たりやすく、ビジネスプラン以上で制限が緩和される。本格運用を見込むなら上位プランを前提に設計したい。複数のシステムが同じ API トークンで投稿していると、制限は合算で消費される。監視・CI・バッチがそれぞれ通知を出す構成では、想定より早く上限に達しやすいので、通知をまとめる・送信間隔を空けるといった工夫が要る。
構造上の限界
もうひとつ重要なのは、Chatwork API はリクエスト／レスポンス型で、WebSocket のような双方向のリアルタイム通信には対応していないことだ。新着メッセージを即座に受け取りたい場合はポーリングで擬似的に実装するしかなく、リアルタイムなチャット UI を自前で作る基盤としては力不足になる。あくまで「自動通知とワークフロー連携」の道具として捉えるのが適切だ。
Slack 連携との違い
通知のハブとして Slack を使う構成と比べると、Chatwork は対話的なボットや WebSocket ベースのイベント受信といった仕組みが薄く、双方向のやりとりをアプリ側で組み立てる用途には向かない。逆に、社内の標準チャットがすでに Chatwork なら、わざわざ別ツールに通知を出して二重管理するより、Chatwork に通知を集約したほうが現場の動線に乗る。ツールの優劣ではなく、チームが日常的にどのチャットを開いているかで連携先を決めるのが、通知が読まれる確率を上げる一番の近道になる。
トークンは組織ではなく発行したユーザーのものです。そのユーザーが参加していないルームには投稿できず、退職や異動でアカウントが無効になれば、そのトークンを使っていた通知は一斉に止まります。監視アラートが静かに止まる形になるため、障害時に初めて気づくという最悪の順序で発覚します。運用に乗せる通知は、最初から通知専用のアカウントを作り、そのトークンで送ってください。投稿先のルームにそのアカウントを入れておくことも忘れずに。
Webhook を受けるなら署名を検証する
Chatwork からのイベント通知を受け取る場合、リクエストには署名が付く。受信側の URL は 外部に公開されるため、検証を省くと第三者が偽の通知を投げ込めてしまう。受け取った本文を そのまま処理に流す設計は、通知をトリガーに何かを実行する構成ほど危険になる。 送信側の実装が軽いぶん、受信側の作り込みを忘れやすい点に注意したい。
社外の相手が同じ画面にいる前提
Chatwork が日本の商習慣で広く使われている理由の一つは、社外の取引先と直接 やりとりできることにある。裏を返すと、自動投稿の宛先ルームに社外の参加者がいる 可能性を常に考える必要がある。システムのエラーメッセージをそのまま流す実装は、 内部のパス構成やホスト名を取引先に見せてしまう。投稿先が社内専用かどうかを ルーム単位で確認し、外部が含まれるルームには要約した内容だけを送る、という 切り分けを設計に入れておきたい。