LINE WORKS API 2.0でできること。Bot・予定連携の条件と設計

LINE WORKS APIを使うと、社内の通知、予定、メンバー情報などを業務システムと連携できます。発注前に確認したいのは、どの操作を、誰の権限で、どのデータに対して行うかです。「API対応」と書かれていても、画面上の全機能を同じように操作できるわけではありません。

本記事は2026年9月8日に公式開発資料で確認した機能と、連携の設計例を整理します。実行可能な完成コードや負荷試験の結果ではありません。LINE公式アカウントのMessaging APIとは、認証情報・利用者ID・送信先が異なります。

業務から使うAPIと条件を選ぶ

実現したい業務	候補となる領域	最初に確認する条件
受注や入金を担当へ知らせる	Bot	社内のメンバー・ルーム、利用設定
日報を受け取る	BotのCallback	受信項目、本人と社員IDの対応
作業予定を連携する	Calendar	対象カレンダーの種類と更新権限
顧客連絡先を参照する	Contact	取得範囲、正本、閲覧者
入退社に伴いメンバーを管理する	User等	管理権限、利用プラン、削除承認
掲示板にお知らせを作る	Board	投稿先、更新・公開の運用

具体的な操作とプランの対応はScope一覧から確認します。参照だけのアプリに、メンバー削除等の書き込み権限をまとめて付けないようにします。

Botは外部トークでは使えない

LINE WORKSのBotは、社内メンバーとの1対1や複数人のトークで使えます。一方、LINEユーザーまたは外部LINE WORKSユーザーを含むトークルームでは利用できません。Botの公式仕様

たとえば協力会社がいるルームに、工事予定Botを入れて一括通知する計画は、この制約に合いません。社内ルームへ通知して担当者が外部へ案内するか、別の通知経路を作るかを選びます。顧客向けの自動通知が中心なら、LINE公式アカウントとMessaging APIを検討します。

Botの登録はDeveloper Consoleだけで完了するとは限りません。管理者画面での追加・公開と、対象メンバーが使える状態まで確認します。送信できないときは、トークンだけでなくBotの状態、対象ルーム、権限の順に切り分けます。

カレンダー連携は種類と正本を決める

Calendar APIは予定の作成・取得・編集・削除等に対応します。対象はマイカレンダーとトークルームカレンダーで、会社カレンダーにはAPIアクセスできないと案内されています。Calendar API

「全社員に見えるカレンダーだから自動登録できる」とは判断せず、実際のカレンダー種別を確認します。画面で見える名称とAPIで指定する識別子も別に記録します。

予定を双方向に同期する場合は、どちらを正しい情報とするかが必要です。たとえば予約DBが正本なら、予約DBで確定した予定をLINE WORKSへ反映し、手動編集をどう扱うかを決めます。変更を双方で繰り返す同期ループや、取り消した予定の復活を避けるため、元システムのIDと連携先のID、最終反映時刻を保存する設計にします。

ユーザー認証とService Account認証を使い分ける

利用者の操作に基づく連携と、夜間バッチのような自動処理では、認証の設計が変わります。Service Accountはアプリ用の仮想管理者アカウントで、JWTを使ってアクセストークンを取得します。利用できないAPIや、meを使えない等の条件があります。Service Account認証

仮想管理者で動くから、全業務へ広い権限を渡してよいということではありません。アプリごとのScopeと、実行側で操作できる対象を絞ります。秘密鍵やトークンはソースコードに直接置かず、保存場所と更新担当を決めます。

認証・管理項目	決めること
実行主体	利用者の操作か、定期処理か
Scope	必要な参照・書き込みの最小範囲
秘密情報	保存場所、閲覧者、更新・失効の手順
対象ID	利用者、ルーム、予定と業務IDの対応
終了条件	アプリ廃止、担当交代、権限剥奪時の停止

フリーで検証できる範囲を操作ごとに確かめる

フリープランで利用可能なAPIもありますが、利用できるサービス・プラン・オプションによってScopeの対応が異なります。現在のScope一覧では、Botだけでなくカレンダー等にも利用可能な項目があります。「無料は参照だけ」と一括して説明しないようにします。

また利用上限はAPI単位で適用され、プランによる差や個別APIの例外があります。一般枠ではフリー60回/分、有償240回/分ですが、全APIにこの値を当てはめることはできません。API使用の上限

社員一人の操作が通ることと、月末に全社員へ処理を行えることは別です。呼び出し回数、同時実行、ページング、取得する期間を見積もり、応答の上限情報を見て処理を抑制します。本番と異なるプランでの試験結果を、そのまま本番の性能保証にはしません。

受信を使うBotでは、検証してから保存・処理する

LINE WORKSのCallbackは署名を検証してからイベントを処理します。使用するヘッダーはX-WORKS-Signature、秘密情報はBot Secretです。LINE Messaging APIの設定やヘッダーを流用して混同しないようにします。Callbackの署名検証

日報受付なら、受信した内容の検証、報告IDの付与、保存、集計先への反映を分けます。通信切断や利用者の連打で同じ報告が増えないよう、業務上の依頼IDと状態を管理する設計が必要です。失敗した仕事を単に捨てず、保留一覧から担当が確認できるようにします。

架空例：受注通知を一つの社内ルームへ送る

受注システムで注文が確定したら、受注ID・担当部署・処理時刻を通知する構成を考えます。本文には顧客の詳細を全て複製せず、権限のある人が元システムを開くためのリンクを載せます。

受注確定を記録する処理と通知ジョブの保存を対応付け、未通知の受注を後から照合できるようにします。送信先ルームがなくなった場合やBotが使えない場合は、担当へ別経路で通知し、宛先を修正するまで保留します。通知が受理されたことを、担当者が処理を完了したことにはしません。

受入場面	確認する結果
同じ受注イベントを再処理	同じ受注通知を不要に増やさない
宛先や権限が無効	失敗が記録され、保留を確認できる
利用上限に達する	間隔を空けて定めた回数・期限で再試行
注文が取り消される	古い確定通知を無条件に再送しない
保守担当が交代	新担当が設定・未処理・復旧手順を確認できる

相談前には、連携したい操作、対象者、件数、既存システムのAPI有無、失敗時の担当をまとめます。古い連携の調査はAPI 1.0終了後の見直しを参照してください。

よくある質問

LINE WORKS Botから顧客のLINEへ直接返信できますか？

LINEユーザーや外部LINE WORKSユーザーを含むトークルームではBotを利用できません。顧客向け自動通知は、LINE公式アカウントとMessaging API等の別構成を検討します。

フリープランでは参照APIしか使えませんか？

一律に参照だけではありません。利用するScopeごとに対応プランが定められているため、必要な操作とサービス・オプションの条件を公式一覧で確認します。

会社カレンダーへAPIで予定を登録できますか？

公式のCalendar APIでは会社カレンダーへアクセスできないとされています。マイカレンダーやトークルームカレンダーを含め、目的に合う対象を確認します。

APIが成功したら業務も完了ですか？

通知の受理と担当者の業務完了は別です。未処理の仕事、通知失敗、担当者の確認や完了操作を分けて記録します。

この記事に関連するサービス

LINE WORKSとの連携は、通知する業務、対象のルーム、更新するデータから実現条件を確認します。LINE公式アカウントとの使い分けも含めて、システム連携をご相談いただけます。

LINEアプリ開発のサービス・相談窓口を見る