先說清楚這篇不是給誰看的：如果你要的是自己做一支 LINE Bot 來玩，這篇不適合你，LINE Bot 開發實戰：GAS + Gemini 那篇才是。
這篇是給正在評估要不要把 LINE 官方帳號接進公司系統的人——重點在動工前該確認什麼，而不是怎麼寫。
LINE 官方帳號串接看起來只是「接一個 Messaging API」，但有幾件事如果一開始沒想清楚，之後要改的成本會高很多，有些甚至改不回來。
以下五件，前兩件決定你每個月付多少錢，後三件決定程式怎麼寫。
一、訊息則數按「人數」算，不是按「幾則」算
這是 LINE 官方帳號串接最多人算錯的地方，而且多數人算反了。官方寫得很直接：
The number of messages is counted by the number of people you send a message to. —— Messaging API 計費說明
官方的例子：一次 push 帶四個訊息物件送給五個人，計為 5 則（不是 20 則），而單次請求最多可放五個訊息物件。
| 做法 | 送給 100 人的消耗 |
|---|---|
| 標題、明細、按鈕分三次請求 | 300 則 |
| 三者包成一次請求 | 100 則 |
同樣的內容、同樣的收件人，差三倍——最容易被忽略，也最容易補救。
哪些不計入免費訊息則數
| 計入 | 不計入 |
|---|---|
| Push、Multicast、Broadcast、Narrowcast | Reply |
但台灣官方列出的免付費訊息不只 Reply，還包括加入好友的歡迎訊息、一對一聊天訊息、自動回應訊息、AI 自動回應訊息。
很多老闆想做的「關鍵字自動回覆」本來就不用錢。先確認想做的事是不是已經在免費範圍內，再談要不要串接。
Reply 訊息的邊界
「能做成 Reply 就做成 Reply」是對的，但回覆權杖只能用一次而且有時效，官方也註明該時限可能變更、不建議依賴。分界是：
- 收到訊息後能立刻回答的 → Reply，不計費
- 要等外部系統、等人工審核、或之後才主動通知的 → 只能 Push，計費
「訂單狀態一變就通知」屬於後者，「使用者輸入編號查狀態」屬於前者——同一個需求，帳單差很多。
怎麼估一個月要用多少
LINE 官方帳號串接動工前用三個數字就能估：每月主動通知幾次 × 每次通知幾人 = Push 則數。
第三個變數不是「一次分幾則」——包成一次請求就好。真正的變數是人數：超量的話先看能不能少通知幾個人，通常比升級方案便宜。
中用量方案不能加購訊息，超過 3,000 則只能升級；額度用完 API 會回 429、訊息不送出——估算時沒算到，就會在尖峰期斷掉。
要降的是人數，不是一次分幾則（AI 生成示意圖）
二、2026-11-01 的方案調整（有期限）
以下為時效資訊，2026-11-01 之後請以 LINE 官方公告 最新內容為準。
月費調整（未稅）：中用量 800 → 1,000 元、高用量 1,200 → 1,400 元，輕用量維持免費。每月免費訊息則數不變（輕 200／中 3,000／高 6,000）。高用量加購改為兩段式：前 50,000 則每則 0.2 元、超過的部分每則 0.15 元。
想降級要在 10 月 27 日前處理。 官方明訂：10 月 27 日後仍繼續使用中／高用量方案，即視為同意本次調整。而 10 月 28 日至 11 月 2 日是系統維護期間，期間無法升降方案，11 月 24 至 25 日還有一次——也就是說錯過 10/27，實務上也沒有補救的窗口。
三、userId 綁的是 Provider，不是 Channel
這件事決定你的會員綁定資料能不能重複使用。官方說明是：
If the provider is the same, the user ID is the same regardless of the channel type. —— LINE Developers：取得使用者 ID
同一個 Provider 底下的 Messaging API channel 與 LINE Login channel，同一位使用者拿到的 userId 是同一個；不同 Provider 則不同。
所以日後可能再開第二個 Channel（先做客服、之後做會員）的話，一開始就放同一個 Provider，綁定資料才接得起來；放在不同 Provider，使用者得重走一次綁定。這是少數「一開始決定、之後很難改」的設定。
另外：使用者未同意提供個人資料時，webhook 不會帶 userId，綁定流程要能處理。
同一 Provider 底下不分 Channel 類型都是同一個 userId（AI 生成示意圖）
四、Webhook 簽章一定要驗
Webhook 的網址是公開的。任何人只要知道它，就能送一個看起來像 LINE 發來的請求。
只回覆固定文字的話影響有限；會查詢訂單、變更資料或觸發通知的話，等於把那些功能開放給不特定人。
做法：用 Channel secret 對請求內容做 HMAC-SHA256，與 x-line-signature 標頭比對，不相符就不要處理該事件（官方說明）。要回什麼狀態碼官方沒有規定，回 400 是常見的實作選擇。
最常見的實作錯誤：HMAC 必須對原始的 request body 計算。先做過 JSON 解析、再序列化回去算，會得到不同的值——看起來程式沒錯，但永遠驗不過。
不相符就不要處理，HMAC 要對原始 request body 算（AI 生成示意圖）
五、權限分層要在一開始就想
初期只有一種使用者時權限問題不會浮現，它會在這三個時機出現：
- 內部與外部混用——員工要查的跟客戶要查的不一樣
- 跨部門——業務只該看自己的客戶，主管要看全部
- 要留稽核紀錄——誰在什麼時候查了什麼
等到需要時才加，通常要回頭改資料結構——因為一開始的資料表沒有「這筆屬於誰」。
最省的做法是第一版就把 userId 與內部身分綁起來，即使目前所有人權限都一樣。最小組合三欄：userId、內部身分、綁定時間——有這三欄，日後要做部門權限、稽核或解綁都接得上。
聊天室做不完的，放 LIFF
很多需求談到後來會變成「能不能在 LINE 裡做一整套系統」。可以，但不是做在訊息泡泡裡。
LINE 有 LIFF 可以在 LINE 內開網頁並取得 userId，官方也在推 MINI App。所以問題不是「能不能做在 LINE 裡」，而是用哪一種容器：
| 用訊息泡泡 | 用 LIFF／網頁 |
|---|---|
| 查詢、選單、確認、通知 | 大量輸入、複雜表單、要並排比對的資料 |
判準是：一個動作如果需要使用者看超過一個畫面才能完成，就不要塞進訊息泡泡。 那不代表要離開 LINE，是要換一個容器。
要不要用 LIFF 也是早期決定——牽涉前端怎麼做、資料從哪來，跟「先接個 Bot 試試」不是同一個工程量。
不是「不要做在 LINE 裡」，是換一個容器（AI 生成示意圖）
五件事的檢查順序
| 確認什麼 | 沒做的後果 | |
|---|---|---|
| 1 | 通知要送給幾個人、能不能包成一次請求 | 訊息則數消耗數倍於必要 |
| 2 | 方案要不要在 10/27 前調整 | 11/1 起視為同意新價 |
| 3 | Channel 是否放在同一個 Provider | 日後綁定資料接不起來 |
| 4 | Webhook 簽章有沒有驗 | 功能對不特定人開放 |
| 5 | 資料表有沒有「屬於誰」 | 要分層時得改結構 |
LINE 官方帳號串接的成本多半不在寫程式，在這些一開始沒想清楚、之後要回頭改的地方——在寫第一行之前確認，比寫完再改便宜得多。
給我們三個數字
不確定自己會落在哪個方案、哪些該做成 Reply 的話，給我們三個數字就好：
- 每月要主動通知幾次
- 每次通知幾個人
- 現在是怎麼做的（人工傳、系統寄信、還是還沒做）
我們會回你月消耗估算、該選哪個方案，以及哪幾段可以改成 Reply 訊息、不用付那筆錢。這一步不收費，也不用先整理規格。
實際的 LINE 官方帳號串接做法寫在 LINE 企業應用開發。如果你連要接進去的那套系統都還沒有，先確認的是資料現在放在哪裡——連一份共用的試算表都沒有的話，LINE 接上去也沒東西可回，那要看的是 企業系統客製開發。
常見問題
LINE 的訊息則數到底怎麼算？
按收訊人數算，不是按送出幾則訊息物件算。官方舉例：一次 push 帶四個訊息物件送給五個人，計為 5 則。單次請求最多可放五個訊息物件，所以把標題、明細、按鈕拆成三次請求是三倍消耗，包成一次只算一次。
哪些訊息不計入免費則數？
Push、Multicast、Broadcast、Narrowcast 計入，Reply 不計入。台灣官方另列的免付費訊息還有加入好友的歡迎訊息、一對一聊天、自動回應與 AI 自動回應——很多老闆想做的關鍵字自動回覆本來就不用錢。
既然 Reply 不計費，是不是全部做成 Reply 就好？
盡量做，但有邊界：回覆權杖只能用一次且有時效，官方也註明該時限可能變更、不建議依賴。分界是——收到 webhook 後能立刻回答的（查詢、選單、確認）做成 Reply；要等外部系統或之後才主動通知的（出貨、異常、提醒）只能用 Push，那就計費。
同一個使用者在我不同的 LINE 服務裡，是同一個 userId 嗎？
同一個 Provider 底下就是同一個。官方說明是「If the provider is the same, the user ID is the same regardless of the channel type」——同一 Provider 下的 Messaging API 與 LINE Login channel 共用同一個 user ID，不同 Provider 則不同。這直接決定會員綁定怎麼設計，而且之後很難改。
Webhook 沒有驗簽章會怎樣？
Webhook 網址是公開的，任何人知道就能送出看起來像 LINE 發來的請求；如果 Bot 會查訂單、改資料或觸發通知，等於開放給不特定人。做法是用 Channel secret 對原始請求內容做 HMAC-SHA256 並與 x-line-signature 比對，不符就不處理。注意必須對原始 request body 算——先 JSON 解析再序列化會算出不同的值，這是最常見的實作錯誤。
本文引用的官方文件
- Messaging API 計費說明 — 訊息則數按收訊人數計算、哪些發送方式計入
- Messaging API 發送訊息 — 單次請求最多五個訊息物件
- LINE Developers：取得使用者 ID — userId 以 Provider 為界
- LINE Developers：驗證 Webhook 簽章 — 簽章比對方式
- LINE 官方帳號 2026 年收費方案調整 — 月費、免費則數與維護期間