LINE WORKS の Bot で業務通知を飛ばす

集計が終わった、バッチが落ちた、承認依頼が来た。こうした業務通知をメールで流すと埋もれる。普段使っているチャットに出したほうが見てもらえる。

LINE WORKS を社内チャットとして使っているなら、Bot を1つ作れば通知の出口になる。ここでは Bot の作成からメッセージ送信までを整理する。認証部分は別記事で扱っているため、アクセストークンは取得済みの前提で進める。

Bot を作る

Developer Console の「Bot」メニューから登録する。設定する項目は次のとおり。

通知を送るだけなら Callback URL は不要。Bot からの一方通行で完結する。

登録すると Bot ID が発行される。この後のAPI呼び出しで使う。

管理者画面で Bot を有効にする

Developer Console で作っただけでは使えない。管理者画面の「サービス」→「Bot」から、作成した Bot を追加して有効化する。ここを飛ばして「Bot が見つからない」と詰まることが多い。

有効化したら、通知を出したいトークルームに Bot を招待する。

メッセージを送る

トークルーム宛に送る場合のエンドポイントは次の形式。

POST https://www.worksapis.com/v1.0/bots/{BOT_ID}/channels/{CHANNEL_ID}/messages

ヘッダーとボディは次のとおり。

import requests

requests.post(
    f"https://www.worksapis.com/v1.0/bots/{BOT_ID}/channels/{CHANNEL_ID}/messages",
    headers={
        "Authorization": f"Bearer {ACCESS_TOKEN}",
        "Content-Type": "application/json",
    },
    json={
        "content": {
            "type": "text",
            "text": "日次集計が完了しました。",
        }
    },
)

成功すると HTTP 201 が返る。

CHANNEL_ID はトークルームの識別子。Bot を招待したトークルームで Bot 宛に発言し、Callback で受け取って確認するのが確実。単発の通知先であれば、一度取得して設定値として持っておけばよい。

運用に載せるときの設計方針

動かすこと自体は難しくない。むしろ、運用に載せた後に問題になるのは通知の量と質。

1. 通知は「行動が必要なもの」に絞る

正常終了の通知を全部流すと、数日で誰も読まなくなる。異常時のみ、あるいは日次サマリ1本に集約する。

2. 本文に次の行動を書く

「バッチが失敗しました」だけでは動けない。失敗した処理名、影響範囲、確認先のリンクまで入れる。

3. 送信失敗時の扱いを決める

API 側の障害やトークン期限切れで送信に失敗することがある。通知の送信失敗で本処理を止めない設計にし、失敗はログに残す。

4. 宛先を設定値として外に出す

Bot ID と Channel ID をコードに直書きすると、通知先の変更でデプロイが必要になる。環境変数や設定ファイルに出しておく。

まとめ

• Developer Console で Bot を作り、管理者画面での有効化を忘れない
• 送信は POST /bots/{BOT_ID}/channels/{CHANNEL_ID}/messages、成功は 201
• 動かすより、通知を絞り込む設計のほうが難しい
• 通知の失敗で本処理を止めない