LINEリッチメニューの一括変更は終わった？｜進行状況と再試行の確認
文・小川 靖人元LINE社員・LIFE合同会社 代表この記事の結論
Messaging APIでユーザーにリンクしたリッチメニューを一括変更するときは、受理と完了を分けます。requestIdとphase、部分失敗、resumeRequestKeyの期限、複数操作の順序を確認する方法を解説します。
最終更新：2026年10月17日
Messaging APIで、ユーザーにリンク済みのリッチメニューを一括で置き換えた場合、リクエストが受け付けられても、全員への処理が終わったとは限りません。一括操作は非同期です。受付時のリクエストIDを使って進行状況を確認します。
この記事で扱うのは、APIでユーザーとリンクしたメニューの一括操作です。LINE Official Account Managerのデフォルトメニューの公開設定や、利用者がタブを押して切り替える操作とは分けてください。
requestIdを残してphaseを読む
公式の進行状況APIは、GETで取得します。ホストはapi.line.me、パスは/v2/bot/richmenu/progress/batchです。クエリのrequestIdへ、一括操作のレスポンスヘッダーに含まれるリクエストIDを指定します。
結果のphaseは三つに分かれます。
- ongoing：処理中。これを見て同じ変更を新規に送り直さない。
- succeeded：一括操作が完了。代表のテスト対象で表示とリンク先も確認する。
- failed：1人以上に対する処理が失敗。一部は成功している可能性があるため、「誰も変更されなかった」と扱わない。
acceptedTimeは受付時刻、completedTimeは完了時刻です。後者はsucceededまたはfailedの場合にだけ返ります。いずれもUTCの時刻なので、日本時間の作業記録と並べるときは時差をそろえます。
部分失敗を、全員への新規変更で上書きしない
公式の一括操作仕様では、初回にresumeRequestKeyを指定しておけば、同じキーで再試行したとき、未完了のユーザーだけが再処理の対象になります。
キーの有効期間は14日間です。期限後は新しいリクエストとして扱われるため、古い作業記録から無条件に再実行しないでください。初回のキーが分からない場合も、別のキーを作れば同じ再試行になる、と考えてはいけません。現在のリンク状態と予定した変更を確認してから、対応を判断します。
進行状況を取得できる期間も、受付時刻から14日間です。404は、存在しないIDや取得可能期間の超過でも返ります。結果を取り直せないことを、変更なしや失敗の証明にはしません。
複数の置き換えは、順番に連鎖する処理ではない
一つのリクエストに複数の操作を入れる場合、それぞれは独立して処理されます。配列に並べた順に、同じユーザーが段階的に移動する指定ではありません。
たとえば、架空のメニューA・B・Cで「AをBへ」「BをCへ」を同じ一括操作に入れた場合、実行前にAだった人はBへ、実行前にBだった人はCへ移ります。Aだった人がそのままCまで進む、という意味ではありません。
担当者同士で「最終的にどの人が何を見るか」を確認し、メニューのIDと案内内容を照合します。全員のリンク解除など、対象範囲の大きい操作を障害調査の試し打ちに使わないでください。
完了記録には、表示と行き先の確認を加える
一括処理が完了したら、許可されたテスト対象で、表示されたメニュー、タップ領域、遷移先を確かめます。ユーザー別メニューとデフォルトの優先関係やタブ切替のエイリアスは別に確認が必要です。
引き継ぎメモには、対象条件、変更前後のメニュー、受付時刻、phase、再試行の履歴、画面で確認できた範囲を残します。顧客全員のIDや実リクエスト全文を、共有資料へ貼る必要はありません。作業を引き継いだ人が、同じ操作を最初から繰り返さず判断できる記録にします。
仕様確認日：2026年10月17日。メニューA・B・Cは架空の説明例です。実アカウントの一括変更や顧客への送信は行っていません。