LINE WORKS API 1.0終了後の見直し。旧連携の調査と2.0への移行

LINE WORKS API 1.0は2023年4月30日に提供終了済みです。 2026年の新しい終了予定ではありません。公式は、終了した機能には完全停止していないものが含まれる可能性があっても、動作は保証しないと説明しています。提供終了機能の一覧

今から旧連携を調べる場合は、将来の期限に備える通常移行というより、残っている旧コード・止まった処理・現行APIへ移った部分を棚卸しする作業になります。この記事では、2026年9月8日に確認した公式情報をもとに、調査・再構築・受入の進め方を整理します。

最初に「古いコードがある」と「今それが動いている」を分ける

リポジトリにAPI 1.0のURLが残っていても、現行の処理がそのコードを使っているとは限りません。実行中のバッチ、サーバー、設定、呼び出し先、最近の成功・失敗記録を対応付けます。

調査では、動作を確かめるために顧客や全社員へメッセージを送る必要はありません。まず設定・ログ・依存関係を読み取り、現在稼働しているものを特定します。実際の送信やデータ更新の試験は、対象を定めた検証環境で行います。

発見した状態	次に確認すること	作業の候補
旧コードがあるが呼ばれていない	廃止理由、代替処理、残る認証情報	記録を残して不要資産を整理
旧連携が失敗し続けている	未処理の業務と代替対応	停止・照合・現行方式で再構築
外部製品の連携だけ使っている	提供元の現行API対応と設定	契約先での更新・再設定
現行APIと旧処理が混在	処理ごとの更新元と送信担当	重複と取りこぼしを整理
認証情報・担当が不明	資産所有者と権限管理者	調査と権限回復から始める

停止した通知が何かを知るには、アプリのエラーだけでなく、受注・勤怠・予定など元の業務データと照合します。数か月分の古い通知を復旧時にまとめて送ることが適切とは限りません。

移行範囲は機能対応表から見積もる

APIの更新では、URLだけでなく認証、Scope、ID、ページング、更新方法、レスポンスの形を確認します。ただし全てを必ず全面書き換えすると決めず、再利用できる業務処理と変更する接続処理を調べます。

現在の機能	現行で確認する箇所	受入時の観点
Bot通知	Bot ID、公開状態、対象ルーム	期待する社員・ルームだけに届く
日報受付	Callback、署名、業務ID	不正な受信を処理せず重複を抑える
予定同期	カレンダー種別と予定ID	時刻・変更・削除・繰り返しを照合
メンバー参照	Scope、取得範囲、ページング	全件取得と所属変更を確認
メンバー更新	書き込み権限、更新・削除の承認	不要な属性を消さない

現在のCalendar APIは会社カレンダーへアクセスできません。昔の画面や企画書にある機能を、現行APIにも存在するものとして見積もらず、一つずつ対応を確認します。

認証と秘密情報の管理を作り直す

現行の利用方法では、アプリのScopeと認証方式を決めます。定期処理に使うService Account認証では、Client ID等のアプリ情報、Service Account、秘密鍵を使ってトークンを取得します。Service Accountで利用できないAPIもあるため、権限があることだけで全操作ができるとは判断しません。Service Account認証

調査資料には実際の秘密鍵やトークンを書かず、保存場所、管理者、切り替え手順を残します。旧認証情報を廃止するタイミングは、どの処理が参照しているかを確認して決めます。更新後のアプリには、必要なScopeだけを付けます。Scopeの定義

切り替えは送信・更新を一つに絞る

検証環境で新しい処理を動かし、元データから作る結果を照合する方法があります。本番への通知や更新は、旧処理と新処理が同時に実行しないよう管理します。二つの実装が同じ予定を別IDで作ると、見かけ上の成功が重複データになります。

現在の未処理・処理済みの範囲を確定する。
新処理が読み取る開始点とIDの対応を決める。
検証先で結果を照合し、対象者・時刻・内容を確認する。
本番の書き込み・送信担当を新処理へ切り替える。
切り替え前後の業務件数と結果を照合する。

旧APIが終了済みなので、失敗時の戻し先を「旧APIへ戻す」だけにしてはいけません。手動運用、送信の保留、現在稼働している別の経路など、実際に使える代替策を決めます。

架空例：止まっていたシフト通知を復旧する

シフトDBには予定がある一方、LINE WORKSへの通知が2週間停止していたとします。まずは対象期間のシフト変更を照合し、社員が別の方法で把握しているかを確認します。過去の変更通知を全て再送すると、現在の予定を誤解させるおそれがあります。

復旧案としては、最新の確定シフトを一度案内し、以降の変更だけを現行Botで通知する方法があります。旧ジョブの送信待ちは、廃棄・確認済み・要個別対応のどれにしたかを記録します。新しいBotの動作に加えて、業務担当が欠けた連絡を回収できたことまで確認します。

発注と納品で揃える成果物

成果物	内容	確認する担当
連携の棚卸し	処理、実行場所、呼び出し先、稼働状態	管理者・開発担当
機能対応表	再利用、改修、廃止、代替案	業務責任者
設定・権限表	アプリ、Scope、秘密情報の管理場所	権限管理者
切替手順	対象期間、重複防止、停止と再開	保守担当
試験結果	正常、失敗、再実行、欠損照合	受入担当
運用資料	更新情報の確認、担当交代、未解決事項	次の保守担当

見積もりは「API移行一式」ではなく、調査、接続修正、データ照合、試験、切り替え、保守を分けます。古いコードを読み解く時間や、失われた処理結果を確認する作業も含めます。現行APIでできることは機能と設計の一覧を参照してください。

よくある質問

API 1.0の提供終了はこれからですか？

いいえ。公式の提供終了一覧では2023年4月30日に終了済みです。2026年の将来予定として扱わず、旧コードや停止した連携の利用状況を確認します。

移行はURLを書き換えるだけですか？

認証、Scope、ID、リクエストや結果の形式、ページング、更新操作を確認します。全面改修の必要性は機能対応表で判断し、再利用できる部分と分けます。

新旧のBotを両方本番で動かして確認できますか？

同じ送信や更新が重複する可能性があります。検証先で結果を照合し、本番へ書き込む担当を一つにして切り替える計画を立てます。

新しい処理に問題があったらAPI 1.0へ戻せますか？

終了済みAPIを戻し先として当てにしません。手動対応、送信保留、現に利用できる別経路など、業務を継続できる代替策を先に決めます。

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

古いLINE WORKS連携は、現在の稼働状況と未処理の業務を調べるところから始めます。構成や担当が不明な場合も、確認できる資料をもとに連携の見直しをご相談いただけます。

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