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
• 動かすより、通知を絞り込む設計のほうが難しいです
• 通知の失敗で本処理を止めません