LINE Messaging APIの始め方予約受付と詰まる所

この記事の内容のご相談は株式会社bundlyzeへbundlyzeのシステム開発について見てみる

この記事は、小さなジム、整体院、結婚式場、リフォーム会社で、自社の公式LINEに予約受付などを足したい担当者と、その開発を担当する人に向けて書きました。「LINE公式アカウントのAPI」を探している場合、メッセージの送受信に使うのがMessaging APIです。扱うのは、最初の1通を返すまでの流れと、そこで詰まる所です。そもそも作るか、拡張ツールで足りるかを迷っている段階なら、会社のコラム拡張ツールで足りるか、自社で作るかが先です。

載せたコードは、2026年11月1日に手元のNode.jsで動かしたものです。LINEのAPIの代わりに、応答を真似る小さなサーバーを立てました。本物のLINEのチャネルは作っておらず、本物のLINEには一度も送っていません。 スマホの画面でも見ていません。コンソールの操作と仕様は、LINE Developersのドキュメントで確かめた内容です。確かめたことと確かめていないことは、後半の「動かして確かめた範囲」に分けて書きます。

Messaging APIは、Webhookで受けてAPIで返す仕組み

Messaging APIの動きは、受ける向きと送る向きの2本でできています。相手がトークで何かすると、LINEのプラットフォームが自社のサーバーへWebhookを送ります。自社のサーバーは、そのイベントを読んでAPIを呼び、返事を送ります。

予約受付に当てはめると、1回のやり取りは次のようになります。

決まった言葉に決まった答えを返すだけなら、Messaging APIは要りません。線の引き方はLINE自動返信の記事に書きました。相手や予約の状態で返事が変わるなら、この記事の範囲です。

手順1. チャネルは公式アカウント側から作り、プロバイダーを先に決める

Messaging APIのチャネルは、LINE公式アカウントでMessaging APIを有効にすると作られます。LINE Developersのドキュメントには、コンソールから直接作ることは2024年9月4日で廃止されたと書かれています。作業の順番はLINE予約システムの記事の手順1にまとめたので、ここでは先に決めることだけを書きます。

いちばん大事なのはプロバイダーです。一度選ぶと、別のプロバイダーへ変えることも、Messaging APIとの連携を解除することもできません。ドキュメントは、次の場合は後で問題が起きる可能性があるとして、慎重に選ぶよう求めています。

• チャネルとプロバイダーを、別々の個人や企業が管理している
• 関係のないサービスのチャネルを、同じプロバイダーの下に作る
• 運用ツールを提供する企業のプロバイダーの下にチャネルを作る

ユーザーIDはプロバイダーごとに違う値になるので、あとでLINEログインを足す予定があるなら、同じプロバイダーを選びます。既存のプロバイダーを選ぶにはAdmin権限が要り、権限のないプロバイダーは選択の画面に出ません。

もう1つ、Webhook URLに設定できる送り先は、1つのチャネルに1つだけです。公式アカウントで別のツールをすでに使っている場合は、Webhook URLが何に使われているかを先に確かめます。

手順2. チャネルアクセストークンは、4種類から選ぶ

サーバーからAPIを呼ぶときに必要なのがチャネルアクセストークンです。Webhookの署名の検証に使うチャネルシークレットとは別の値で、シークレットは「チャネル基本設定」タブで確認できます。

トークンは4種類あります。

LINE Developersのドキュメントが勧めているのはv2.1です。始める順番としては、手元の確認は長期のトークンで進め、運用に入る前にv2.1へ移す形が手軽です。これは経験則で、公式の手順ではありません。

長期のトークンは、再発行すると今のトークンが無効になります。動いているサーバーで再発行するときは、今のトークンの有効期間を最大24時間延ばす選択があるので、その間に入れ替えます。長期のトークンを使う場合は、APIを呼べるサーバーをIPアドレスで絞る設定（任意）もあります。

v2.1の発行には、RSAの鍵の組を作って公開鍵をコンソールに登録し、秘密鍵で署名したJWTを送る手順が要ります。ドキュメントは、v2.1と短期のトークンを使うたびに発行し直さず、有効期間の中では同じものを使うよう求めています。この記事のコードでは、v2.1の発行は試していません。

値はコードに書かず、gitに入れないファイルか、本番の環境変数に置きます。

LINE_CHANNEL_SECRET=
LINE_CHANNEL_ACCESS_TOKEN=

手順3. Webhookは、署名を確かめてから先に200を返す

受け口のコードは次の1ファイルです。Node.jsの標準機能だけで書いたので、追加のパッケージは要りません。予約の枠は説明のためにメモリに置いています。

// server.mjs：Webhook を受けて、ボタンで予約を受ける最小のサーバー
import { createHmac, timingSafeEqual } from "node:crypto";
import { createServer } from "node:http";

const API = process.env.LINE_API_BASE ?? "https://api.line.me";
const SECRET = process.env.LINE_CHANNEL_SECRET;
const TOKEN = process.env.LINE_CHANNEL_ACCESS_TOKEN;
if (!SECRET || !TOKEN) throw new Error("LINE_CHANNEL_SECRET と LINE_CHANNEL_ACCESS_TOKEN を入れてください");

// 題材の枠と処理済みのID。動きを見るだけなのでメモリに置く
const slots = [
  { id: "1", label: "11/05 10:00", left: 1 },
  { id: "2", label: "11/05 11:00", left: 3 },
];
const seen = new Set();

// 受け取ったバイト列のまま、署名を確かめる
function verify(rawBody, signature) {
  const expected = createHmac("sha256", SECRET).update(rawBody).digest();
  const given = Buffer.from(signature ?? "", "base64");
  return given.length === expected.length && timingSafeEqual(given, expected);
}

async function reply(event, messages) {
  const res = await fetch(`${API}/v2/bot/message/reply`, {
    method: "POST",
    headers: { "Content-Type": "application/json", Authorization: `Bearer ${TOKEN}` },
    body: JSON.stringify({ replyToken: event.replyToken, messages }),
    signal: AbortSignal.timeout(10_000),
  });
  if (res.ok) return;
  // 問い合わせに使うので、ステータス、リクエストID、本文を残す
  throw new Error(`reply ${res.status} ${res.headers.get("x-line-request-id")} ${await res.text()}`);
}

const slotButtons = () =>
  slots
    .filter((s) => s.left > 0)
    .slice(0, 13) // クイックリプライは13個まで
    .map((s) => ({
      type: "action",
      action: { type: "postback", label: s.label, data: `action=book&slot=${s.id}`, displayText: s.label },
    }));

function chooseSlot(event) {
  const items = slotButtons();
  if (items.length === 0) return reply(event, [{ type: "text", text: "いま予約できる枠がありません。" }]);
  return reply(event, [{ type: "text", text: "時間を選んでください。", quickReply: { items } }]);
}

async function handleEvent(event) {
  if (seen.has(event.webhookEventId)) return; // 同じイベントは1回だけ処理する
  seen.add(event.webhookEventId);
  if (!event.replyToken) return; // 友だち解除や standby には応答トークンがない

  if (event.type === "follow") return chooseSlot(event);
  if (event.type === "message" && event.message.type === "text" && event.message.text.includes("予約")) {
    return chooseSlot(event);
  }
  if (event.type !== "postback") return;

  const p = new URLSearchParams(event.postback.data);
  if (p.get("action") === "dates") return chooseSlot(event);
  if (p.get("action") === "book") {
    const slot = slots.find((s) => s.id === p.get("slot"));
    if (!slot || slot.left <= 0) return chooseSlot(event); // 見せた後に埋まった枠
    slot.left -= 1;
    return reply(event, [{ type: "text", text: `${slot.label} のご予約を受け付けました。` }]);
  }
}

createServer(async (req, res) => {
  if (req.method !== "POST" || req.url !== "/webhook") return res.writeHead(404).end();

  const chunks = [];
  try {
    for await (const chunk of req) chunks.push(chunk);
  } catch {
    return res.destroy(); // 本文の途中で切れた接続。拾わないとサーバーごと落ちる
  }
  const rawBody = Buffer.concat(chunks);

  if (!verify(rawBody, req.headers["x-line-signature"])) return res.writeHead(401).end();
  res.writeHead(200).end(); // 署名が合ったら先に200を返し、処理はその後

  const { events = [] } = JSON.parse(rawBody); // 空の配列なら何もしない
  for (const event of events) {
    await handleEvent(event).catch((err) => console.error(event.webhookEventId, err.message));
  }
}).listen(process.env.PORT ?? 3000);

動かすコマンドは次のとおりです。--env-fileはNode.jsの機能で、.envの値を環境変数として読み込みます。

node --env-file=.env server.mjs

コードの要点は4つです。詳しい理由はWebhookの記事に書いたので、ここではNode.jsで書くときの差を中心に挙げます。

• 本文はバイト列のまま検証する。 署名はチャネルシークレットを鍵にしたHMAC-SHA256です。LINEのドキュメントは、検証の前のJSONの読み込み、整形、エスケープの解釈、UTF-8以外での処理を禁じています。Expressなどの本文を自動で読み込む道具を使う場合は、読み込む前の本文を取っておきます
• 2秒より前に返す。 ドキュメントの「エラーの統計情報」の説明では、2秒以内にレスポンスが返らないとrequest_timeoutになるとされています。予約の処理を終えてから返すのではなく、署名が合ったら先に200を返します
• 空のeventsにも200を返す。 疎通の確認のために、イベントのないリクエストが届くことがあります
• ヘッダー名の大文字と小文字に頼らない。 ヘッダー名の表記は予告なく変わることがあるとされています。Node.jsのreq.headersは小文字にそろえてくれるので、x-line-signatureで読めます

Workersでは先に200を返すのにctx.waitUntil()が要りましたが、ずっと動いているNode.jsのサーバーでは、返した後の処理をそのまま続けられます。その代わり、処理の途中でサーバーが止まると、そのイベントは失われます。LINEには成功と伝わっているので、再送もされません。

サーバーを公開したら、コンソールの設定に進みます。

1. 「Messaging API設定」タブの「Webhook URL」に、https://（公開したドメイン）/webhookを入れる
2. 「検証」を押して「成功」と出ることを確かめる
3. 「Webhookの利用」を有効にする
4. 同じタブのQRコードで、公式アカウントを友だち追加する
5. LINE Official Account Managerで、あいさつメッセージと応答メッセージの扱いを決める

Webhook URLはHTTPSが必須で、自己署名の証明書は使えません。手元のサーバーをそのまま登録することはできないので、公開の環境に置くか、HTTPSのURLを手元へ転送する道具を使います。

チャネルを作った直後は、あいさつメッセージと応答メッセージが有効です。Webhookと一緒に有効のままにすると、管理画面の返事とサーバーの返事が重なることがあります。ドキュメントは、初めてボットを作るときはオフにするよう勧めています。

会社サイトの関連ページ公式LINEの運用と構築

手順4. 応答とプッシュは、きっかけで使い分ける

Messaging APIの送り方を分ける基準は、相手の操作に返すのか、こちらの都合で送るのかです。

1回で送れる吹き出しは、どちらも5つまでです。

応答トークンには細かい決まりがあります。リファレンスでは、1回しか使えず、Webhookの受信から1分以内に使う必要があり、再送されたWebhookの応答トークンは、元のトークンを使っていたり、イベントの発生から20分を過ぎていたりすると使えないとされています。時間の制限は予告なく変わることがあるので、制限に頼らず、できるだけ早く使います。

返事に時間がかかる処理なら、トーク画面にローディングのアニメーションを出すAPIがあります。表示は5〜60秒で指定し、1対1のトークだけで使えて、相手がそのトーク画面を見ているときにだけ出ます。

プッシュは、次の短いスクリプトで試せます。送り先には、「チャネル基本設定」タブに出る開発者本人のユーザーIDを使います。LINEアカウントと連携していないビジネスIDでは表示されません。

なお、相手にブロックされている場合、プッシュは 200 が返っても届きません。送信の成功と到着は別のものとして扱います。

// push.mjs：自分のユーザーIDに1通送る。node --env-file=.env push.mjs <ユーザーID> <文>
import { randomUUID } from "node:crypto";

const API = process.env.LINE_API_BASE ?? "https://api.line.me";
const [to, text] = process.argv.slice(2);

const res = await fetch(`${API}/v2/bot/message/push`, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.LINE_CHANNEL_ACCESS_TOKEN}`,
    "X-Line-Retry-Key": process.env.RETRY_KEY ?? randomUUID(), // 送り直すときは同じ値を使う
  },
  body: JSON.stringify({ to, messages: [{ type: "text", text }] }),
});
console.log(res.status, res.headers.get("x-line-request-id"), await res.text());

X-Line-Retry-Keyには、送るたびに新しいUUIDを付けます。タイムアウトなどで届いたか分からないときは、同じ値で送り直します。すでに受理されていれば409が返り、二重には届きません。リトライキーは最初のリクエストから24時間有効です。自社の連絡の形にするときの作りは、前日リマインドの記事に書きました。

メッセージ通数は、送った相手の人数で数える

メッセージ通数は、吹き出しの数でもリクエストの回数でもなく、送信の対象になった人数で数えます。LINE Developersのドキュメントの例では、メッセージを4件入れたプッシュを5人のトークルームに1回送ると、5通です。

ブロックされている相手や存在しないユーザーIDのように、実際には届かない宛先は数えられません。

見積もるときは、相手の操作への返事を除いて、こちらから送る分だけを足します。

月の通数 ＝ 月の予約の件数 × 予約1件あたりのプッシュの回数 ＋ 友だちの数 × 月の配信の回数

たとえば前日のリマインドだけなら、予約1件につき1通です。すべての連絡をプッシュで作ると、同じやり取りでも通数が増えます。相手の操作をきっかけにできる連絡は、応答で返す形に寄せます。

上限を超えて送ろうとすると、エラーが返り、メッセージは送られません。当月の状況はAPIで確かめられます。

// quota.mjs：今月の上限の目安と、使った通数を見る
const API = process.env.LINE_API_BASE ?? "https://api.line.me";
const get = async (path) => {
  const res = await fetch(`${API}${path}`, {
    headers: { Authorization: `Bearer ${process.env.LINE_CHANNEL_ACCESS_TOKEN}` },
  });
  return [res.status, await res.json()];
};
console.log("上限の目安", ...(await get("/v2/bot/message/quota")));
console.log("使った通数", ...(await get("/v2/bot/message/quota/consumption")));

上限の目安は、typeがlimitedのときだけvalueが返り、noneなら目安が設定されていません。どちらの数字にも、LINE Official Account Managerから送った分が含まれます。管理画面の配信とAPIの連絡は、同じ枠を使う前提で考えます。使った通数の値は概算とされているので、正確な数はLINE Official Account Managerで見ます。プランごとの通数と金額は変わることがあるので、LINE公式アカウントの料金プランで確かめます。

リッチメニューは、ポストバックが要るならAPIで作る

リッチメニューは、LINE Official Account ManagerとMessaging APIのどちらでも作れます。予約受付で分かれ目になるのは、ボタンを押したときにサーバーへ知らせたいかどうかです。LINE Developersのドキュメントでは、ポストバックアクションや日時選択アクションを使えることが、Messaging APIで作る利点に挙げられています。

予約ページが別にあり、リンクを開くだけなら、管理画面で足ります。トークの中で枠を選んでもらうなら、APIで作ります。上のserver.mjsのaction=datesは、リッチメニューのボタンにdataとして入れる値です。作るスクリプトはLINE予約システムの記事の手順3に載せたので、ここでは繰り返しません。

作る前に知っておきたいのは次の4つです。

• 1つのメニューには1つの道具だけ。 管理画面で作ったメニューはAPIで扱えず、APIで作ったメニューは管理画面で扱えません
• パソコン版のLINEには出ない。 リッチメニューはデスクトップ版（macOS、Windows）では表示されません。文字で「予約」と届いた場合にも同じ案内を返しておくと、メニューが見えない人の受け口になります
• APIのメニューが優先される。 表示の順は、ユーザー単位、APIの既定、管理画面の既定です。管理画面で直したのに変わらないときは、APIの既定が残っていないかを見ます
• 既定のメニューはすぐには変わらない。 既定のメニューは、トーク画面に入り直したときに反映されます。APIの既定は、反映まで1分ほどかかることがあります

予約の前と後でメニューを変える設計は、段階で切り替える記事で扱っています。

よくあるエラーは、ステータスとmessageで切り分ける

Messaging APIのエラーは、ステータスコードとJSONのmessageで原因を絞れます。上のserver.mjsは、失敗したときにステータス、X-Line-Request-Id、本文をログに残します。

自社のサーバーの側で起きる失敗は、次のとおりです。

シークレットを新しく発行すると、古い値は無効になります。ある日から突然署名が合わなくなったら、まず再発行の有無を確かめます。

could_not_connectなどの原因は、コンソールの「エラーの統計情報」で見られます。この機能は初期設定で無効で、オフの間の分はさかのぼれません。「検証」のリクエストは統計に入らないので、検証の失敗はサーバーのログで見ます。LINEのガイドラインは、送ったリクエストと受けたWebhookのログを一定期間残すよう勧めています。

最小のコードの次に足すもの

ここまでのコードは、動きを見るためのものです。枠と処理済みのIDがメモリにあるので、再起動すると消えます。実際の予約に使うときは、次の順で足します。

業種で変わるのは、主に枠の持ち方です。ジムや整体院は時間と担当者、結婚式場は見学の時間帯やフェアの回、リフォーム会社は現地を見に行ける希望日になります。違いはLINE予約システムの記事の業種の節にまとめました。

名前や電話番号をトークの中で聞き始めると、やり取りが長くなります。入力が要るなら、予約の画面だけをLINEミニアプリで作る形も検討します。

会社サイトの関連ページbundlyzeのシステム開発

やってはいけないこと

• トークンやシークレットをコードやgitに入れる。 例の値でも、本物と同じ形の文字列を書かないようにします。漏れた疑いがあれば、LINEのドキュメントのとおり取り消して発行し直します
• 検証の前に本文をJSONにする。 中身が同じでも署名が合わなくなります
• WebhookをIPアドレスで絞る。 LINEのガイドラインで禁じられています。LINEのプラットフォームのIPアドレスは開示されておらず、守りは署名の検証で行います
• 本物のLINEで負荷試験をする。 ガイドラインは、大量のリクエスト、プラットフォームを経由した負荷テスト、同じユーザーへの大量送信を禁じています。手元の試験は、この記事のように真似るサーバーで行います
• 応答トークンを取っておいて後で使う。 後から送る連絡はプッシュにします
• ボタンのdataをそのまま信じる。 見せた後に枠が埋まることがあり、トークに残るボタンなら古いものも押せます。枠の空きと本人を、押された時点で確かめ直します

公開前に確かめること

• プロバイダーが、今後LINEログインを足すものと同じになっている
• 本物のチャネルで、コンソールの「検証」が成功する
• 運用で使うトークンの種類を決め、発行し直す手順を書いた
• シークレットとトークンがgitの履歴に残っていない
• 管理画面のあいさつメッセージと応答メッセージの扱いを決めた
• 「エラーの統計情報」をオンにした
• 友だち追加から予約の受け付けまでを、iPhoneとAndroidの実機で通した
• リッチメニューのボタンが、意図したdataで届く
• パソコン版のLINEから「予約」と送っても案内が返る
• 月の通数を見積もり、当月の状況を見る人を決めた
• 失敗のログに、リクエストIDが残っている
• サーバーが止まったときの連絡先を決めた

動かして確かめた範囲

2026年11月1日に、手元のMacで確かめました。

server.mjsは90行、push.mjsは16行、quota.mjsは10行です。試験の結果は次のとおりで、24項目を3回流し、3回とも全項目が通りました。

エスケープの書き換えは、本文の\nを\u000aに変えたものです。JSONとしての中身は同じでも、署名が合わなくなることを確かめました。

確かめていないこと：

• 本物のLINEとのやり取りのすべて。チャネルの作成、トークンの発行、コンソールの「検証」、実際のWebhookの形、応答とプッシュの到着、ボタンの見え方は見ていません。真似るサーバーはドキュメントを読んで書いたもので、本物と同じ動きとは限りません
• 上のエラーの表は、ドキュメントのステータスコードとエラーメッセージから書いたものです。動かして試したのは、真似るサーバーが返す400と401と409だけです
• 公開の環境へのデプロイと、HTTPSの設定。2秒の制限を実際のネットワークで測っていません
• v2.1のトークンの発行と、リッチメニューの作成。リッチメニューのスクリプトは予約システムの記事のもので、この記事では動かしていません
• ローディングのアニメーションのAPI
• 月の通数の上限を超えたときの実際の動き。上限を超えた後に応答メッセージが送れるかは、確かめたドキュメントの範囲では読み取れませんでした
• 大きな本文を送りつけられたときの備え。server.mjsは本文の大きさを制限していないので、本番では上限を付けます

自社でやる場合と、任せる場合

最初の1通を返すところまでは、Node.jsを読める人が1人いれば進められます。詰まるのはその後で、トークンの発行し直し、失敗の見張り、仕様の変更への追従、通数の管理が続きます。予約の決まりと、自動で答えないことを決める仕事は、どの進め方でも店でしかできません。Node.jsで書かない場合も、Python、Javaなどの公式のSDKがあります。

任せる場合、株式会社bundlyzeでは、Web・システムのご相談は内容を問わずお受けしていて、公式LINEと予約・顧客管理をつなぐ仕組みも開発しています。配信や設定の運用からの入口はLINE運用のページ、開発からの入口はシステム開発のページです。

出典（一次情報）

確認日はどれも2026年11月1日です。LINEの仕様は変わることがあるので、作り始める時点で確かめてください。

• LINE Developers「Messaging APIの概要」：ボットサーバーとLINEプラットフォームのやり取り
• LINE Developers「Messaging APIを始めよう」：2024年9月4日の直接作成の廃止、プロバイダーを変更できないこと、Admin権限、注意が要る場合
• LINE Developers「ボットを作成する」：トークンの勧め、Webhook URLが1つなこと、HTTPSと証明書、検証、IPアドレスでの呼び出し元の制限、あいさつメッセージと応答メッセージ
• LINE Developers「チャネルアクセストークン」：4種類の有効期間と発行数、再発行、取り消し
• LINE Developers「チャネルアクセストークンv2.1を発行する」：アサーション署名キーとJWT
• LINE Developers「Webhookの署名を検証する」：HMAC-SHA256、検証の前に本文を変えないこと、シークレットの再発行
• LINE Developers「メッセージ（Webhook）を受信する」：非同期の処理、再送、webhookEventId、イベントの種類
• LINE Developers「Webhookのエラーの原因と統計情報を確認する」：2秒のrequest_timeout、原因の種類、統計に検証が入らないこと
• LINE Developers「ユーザーIDを取得する」：開発者本人のユーザーID、プロバイダーごとに違う値になること
• LINE Developers「メッセージを送信する」：送信の種類、1回に5つまでの吹き出し
• LINE Developers「クイックリプライを使う」：ボタンは13個まで
• LINE Developers「失敗したAPIリクエストを再試行する」：X-Line-Retry-Key、409、24時間の有効期間
• LINE Developers「ローディングのアニメーションを表示する」：表示の秒数と条件
• LINE Developers「Messaging APIの料金」：通数の数え方、数えられる送り方、上限を超えたとき
• LINE Developers「リッチメニューの概要」：道具ごとの利点、1つのメニューに1つの道具、デスクトップ版、優先順位、反映のタイミング
• LINE Developers「Messaging API開発ガイドライン」：禁止事項、ログの保存
• LINE Developers「FAQ」：応答メッセージが通数に数えられないこと、残りがあるのに429が返る理由
• LINE Developers「LINE Messaging API SDK」：公式のSDK
• LINE Developers「Messaging APIリファレンス」：ステータスコード、エラーメッセージ、応答トークンの制限、空のevents、ヘッダー名の扱い、上限の目安と利用状況のAPI
• LINEヤフー for Business「料金プラン」：プランごとの内容