LINE Bot 開發費用怎麼算？拆開四層帳單，教你判讀報價單

「做一個 LINE Bot 大概要多少錢？」

這個問題很難用一個數字回答，但原因不是廠商想藏價格，而是 LINE Bot 開發費用從頭到尾就不是一筆錢——它至少是四筆，付給三個不同的對象，其中只有建置開發費是一次性的，另外三筆每個月都在跑，而且開發商報的那張單子通常一毛都不含要付給 LINE 的訊息費。

先給一個能對號入座的答案，但請連條件一起讀：需求只到關鍵字自動回覆與客製對話流程，公開可查的級距落在數萬元；加上 LIFF 前端（表單、線上預約、會員中心）或主動推播排程，普遍跳到十幾萬至五十萬；再加上金流與 ERP 整合，落在五十萬以上。但同時必須說明：就本文 2026 年 7 月的公開檢索範圍所及，找不到任何公協會或第三方單位發布過 LINE Bot 開發費用的統計，上述級距全部來自個別開發商或單一接案平台的自述，中階區間幾乎不重疊、下限差距達五倍——它能拿來自我定位，不能拿來議價。

（本文所引 LINE 官方資費與規則為 2026 年 7 月查證，實際以 LINE 官方後台與最新公告為準；法規段落為一般性說明，非法律意見。）

LINE Bot 開發費用分成四層，付給三個不同的對象

一個上線運作的 LINE Bot，帳單至少四層，合約對象與計價週期都不同；搞混哪一層，後面的比價都是無效的。

層級	這是什麼錢	付給誰	一次性還是持續
第一層｜官方帳號方案費	LINE 官方帳號月費（含固定的免費訊息則數）	LINE	每月固定
第二層｜訊息超額費	超出免費則數後的加購訊息費	LINE	每月變動
第三層｜建置開發費	對話流程設計、Webhook 端點與驗簽、選單與 Flex 實作、跨機型測試、會員綁定、額度監控	開發商	一次性
第四層｜主機與第三方服務費	雲端執行環境、資料庫、網域、簡訊、LLM API 等	雲端與服務商	每月變動

這張表最重要的一句話是：第三層跟第一、二層是分開的合約，開發商報的價通常不含任何 LINE 官方訊息費。 換個角度問「上線之後每個月固定要付什麼」，一定會有的是三筆：官方帳號月費、超額訊息費、雲端與第三方服務費；簽了維護合約是第四筆，串大型語言模型還會多一筆 token 費用——只有建置費是一次性的。這不是廠商偷藏：官方帳號是用你公司的名義申請與扣款，開發商也不可能替你決定每個月要推播幾次。

第四層也常被略過：LINE 平台明訂 Webhook 接收端必須走 HTTPS、憑證必須由公開的憑證機構簽發、不接受自簽憑證，且僅支援 TLS 1.3 與 1.2。所以只要你的 Bot 不是純用官方後台的自動回覆，就必須有一個能用 HTTPS 接收 webhook 的執行環境（自架主機、雲端虛擬機或無伺服器服務都可以）。憑證可用免費的公開 CA，執行環境低流量時也可能落在免費額度內，但它是一筆會隨流量成長、且必須有人負責的持續性成本。

LINE 官方那一層是唯一能寫死的數字，重點在「只有高用量可以加購」

方案	月費（未稅）	每月免費訊息則數	可否加購
輕用量	0 元	200 則	不可加購
中用量	800 元	3,000 則	不可加購
高用量	1,200 元	6,000 則	可加購，每則 0.2 元起降（量越大單價越低），階梯式累進

（依 LINE Biz-Solutions 台灣官方公告，自 2023 年 9 月 1 日起適用，金額均為未稅。）

多數文章寫到這裡就結束，但會讓你營運出事的是最後一欄：輕用量與中用量超出免費則數之後不能加購，該月就再也推不出去。 假設你是中用量方案、有 4,000 位好友，這次群發根本發不出去——當月額度只有 3,000 則、系統要扣 4,000 則，官方的處理方式不是先送 3,000 人，而是整則訊息直接失敗，一個人都收不到；接下來整個月也不能再主動推播，除非升級方案。

LINE 的技術文件寫得很直白：超過當月上限時，API 會回傳錯誤、訊息不會送出，不是自動扣款寄出去。好處是帳單不會爆掉，代價是失敗得安靜——行銷同事按下發送，可能隔天才發現訊息沒出去。所以額度監控必須是開發時就做進去的功能；官方有提供查詢當月已發送則數與上限的 API。

加購訊息的完整階梯級距，官方主要以圖片或文宣呈現，文字版本無法取得；可確定的只有「每則 0.2 元起降、量越大單價越低」這個方向，其他流通的單價彼此矛盾且回溯不到官方頁面，所以本文除此之外不列單價。另提醒一個常見誤植：日本的方案結構與幣別完全不同，把日圓換算成台幣寫成「台灣行情」是錯的。

訊息費是變動成本，好友數長它就跟著長

LINE 的訊息費依「發送對象的人數」計算，不是依你發了幾次；一則群發給 1,000 位好友就是扣 1,000 則。你的推播成本會跟著好友數放大，而開發費不會。 準確地說它是分段的：免費則數之內不額外收費，超出之後才依人數計費——分水嶺不是好友數本身，是「好友數 × 每月推播次數」有沒有越過額度線。

好友數	每月群發 2 次	每月群發 4 次	對照 6,000 則免費額度
3,000	6,000 則	12,000 則	2 次剛好用完；4 次超出額度 6,000 則
5,000	10,000 則	20,000 則	2 次超出 4,000 則；4 次超出 14,000 則
10,000	20,000 則	40,000 則	群發 1 次即超出額度 4,000 則

（本表依 LINE 官方「依發送對象人數計算」的規則推算，假設每次皆為全體群發、每次僅發 1 則；實際消耗會因分眾推播與封鎖名單而不同。表中不推算金額——加購的完整階梯級距官方未公開文字版本，任何金額推算都會是猜的。）

好友數過了 3,000、一個月推超過兩次，高用量的額度就不夠；還在中用量方案，撞到牆就是當月停播。所以編年度預算時，訊息費要用「明年的好友數」估。另一頭，輕用量的 200 則也有一個很少被翻譯出來的意思：200 則等於 200 位好友只夠推一次。

一個會影響推播設計的細節：單次 API request 最多可放 5 個 message object，對同一個人仍只算 1 則，所以一次把三段話講完跟分三次發，計費差三倍。至於「一週發幾則比較安全」，LINE 官方並未公開發送頻率上限或停權閾值，屬於資料不足。

LINE Bot 開發要多少錢？報價差在功能落在哪一層

同樣叫「LINE Bot」，技術含量的落差比多數人想的大。下面這張階梯是從 LINE 官方技術文件的能力邊界推導出來，可以拿來自我定位（L6 是唯一一定計費的一層，L4、L5、L7 依發送方式而定）。

層級	功能	核心技術元件	主要工時來源
L1	關鍵字自動回覆	官方後台設定，或 Reply API（不計費）	幾乎沒有開發，成本在流程與話術
L2	客製對話流程	Messaging API＋自建 Webhook 端點	後端開發、執行環境、憑證與驗簽
L3	進階圖文選單	Rich Menu API、依使用者切換選單、分頁	選單設計＋使用者狀態管理
L4	卡片式版面	Flex Message（跨機型渲染差異）	UI 設計＋跨裝置跨版本測試
L5	表單／線上預約／會員中心	LIFF（Endpoint 須 https）＋LINE Login	等於多做一套前端 Web App
L6	主動推播與排程提醒	Push／Multicast／Broadcast／Narrowcast（計費，依人數）	排程、佇列、失敗重試、額度控管
L7	金流	LINE Pay Online API（需特約商店資格）	金流流程＋對帳補償＋雙環境測試
L8	以電話號碼發送通知	Notification Messages（限法人、須申請）	資格申請與審查是主要瓶頸

L1 到 L3 還算「同一個等級的專案再加點東西」，L4 之後每往上一層都是換一個量級。報價會在三個地方跳級：需求裡出現表單或選時段（等於在 LINE 裡多蓋一個網站，還得掛 LINE Login channel）；需求從被動回覆變成系統主動發訊（要做排程、佇列、失敗重試與額度監控，訊息也從不計費變計費）；需求包含金流（LINE Pay 是獨立體系，要做 HMAC 簽章、兩段式流程、雙環境測試，還要處理「付了款但回呼沒回來」的補償）。

同樣說「有圖文選單」報價卻差好幾倍，理由也在技術邊界：官方文件明寫，後台建立的圖文選單只能用後台讀取與編輯，要做「不同會員等級看到不同選單」就得走 API 開發並自行管理使用者狀態——前者是設計師在後台點幾分鐘的事，後者是後端工程。

還有三類需求加預算也不會變快，卡的是資格而非工時：用電話號碼直接發通知（Notification Messages，截至 2026 年 7 月查證僅開放日本、泰國、台灣，限法人、須申請、號碼須經 E.164 正規化後雜湊、不得作商業廣告，計費官方未公開）、取得使用者 Email（email scope 須事前送審並附用途截圖）、LINE Pay 收款（須先完成特約商店註冊，費率公開查不到）。有硬性上線日的專案，這三項要在啟動當天送件。

這張表也可以當減法工具：官方後台就能做關鍵字自動回覆、歡迎訊息、靜態圖文選單與基本分眾標籤，不需要開發費——把需求逐條丟到後台試，試不出來的才進報價單。

設計成 Reply 還是 Push，決定了你每月要不要付訊息費

LINE 只對主動發送的訊息計費：官方明列計費的是 push、multicast、broadcast、narrowcast 四種，依人數計算，而 Reply API（使用者先傳訊息、系統回覆他）不計費。翻成商業語言：使用者先開口，你回話，不用錢；你主動找使用者，每個人每一次都要錢。

台灣官方頁另列為不計費的還有加好友的歡迎訊息、自動回應訊息與 AI 自動回應訊息。至於「一對一手動聊天訊息」有一個要提醒的分歧：LINE 台灣官方頁列為不計費，但有第三方服務商的技術文件把客服端的一對一聊天標示為走 Push API 並計費。如果你的一對一回覆是透過第三方客服台在發，建議以官方後台的實際帳務對一次。

同一個需求試試看：牙醫診所要「讓病人知道下次回診是什麼時候」。設計成「病人在選單點『我的預約』、系統用 Reply 回覆」，訊息成本趨近於零；設計成「系統排程在回診前一天 Push 提醒每位病人」，1,000 位病人每月各一次就是 1,000 則。兩個都對，但長期帳單完全不同，而前者省下的訊息費有一部分是用「沒被提醒到的病人」換來的，所以合理的做法通常是混合。重點是這個決定要在畫流程圖的時候做，不是在收到第一張帳單的時候做。

一個跟 AI 有關的延伸情況：LINE 的 replyToken 是一次性的，且必須在收到 webhook 後一分鐘內使用，所以串大型語言模型時如果推理較慢，常見做法是先回應 200、非同步處理、再用 Push 把答案補送回去。這一改，訊息就從不計費變成計費了。 這是「串 AI 的 LINE Bot 為什麼比較貴」最具體的理由——它的每月成本同時受 LLM token 用量與 LINE 訊息量夾擊，所以單則回應的 token 上限、同一使用者的冷卻時間、知識庫檢索範圍限制這些成本煞車，本身就是開發工項。

該租還是該做？用 LINE 的結構決策點比，不要只比月費

需求落在自動回覆、圖文選單、優惠券、分眾推播這類標準功能時，SaaS 平台的第一年支出通常明顯低於客製開發——多數平台有 0 元起的免費級距（例如 CHATISFY 與 OakMega 的免費方案皆為 0 元，但都設有約 1,000 名訂閱戶／會員的上限，2026 年 7 月查證）。但只比「月費 vs 建置費」，會漏掉幾個由 LINE 平台結構決定、不可逆的決策點。

決策點	用現成 SaaS 平台	委外客製化開發
Provider 掛在誰名下	多掛在平台方或代開的 Provider 下	可指定以你公司名義建立，寫進合約
userId 這份資產跟著誰走	綁在平台的 Provider，離開等於重建綁定	綁在你自己的 Provider，換開發商不影響
好友數成長時漲的是哪一筆	平台月費＋訊息費，兩邊一起漲	只有訊息費漲，建置費不隨規模變動
Reply／Push 的比例誰決定	由平台模組決定	需求階段可逐條決定，直接影響訊息費
資料在自家有沒有第二份	多數平台未載明終止服務後的資料處理	資料庫自有，帳號出狀況營運不會斷

這五列決定的不是第一年花多少，是第三年還能不能換人。

官方帳號用誰的名義開，決定三年後你手上還剩什麼

這一節不會改變你拿到的報價數字，但它決定你第二年、第三年的選擇權，而目前搜尋得到的繁中費用文章幾乎沒人把它寫進成本評估。LINE for Business 台灣的官方操作手冊寫得很明白：透過 Channel 蒐集到的資料，所有權屬於對應的 Provider，同一份文件也要求第三方系統整合商或經銷商以客戶的名義建立專屬 Provider。（Provider 是「這些 Channel 是誰家的」這個上層身分，Channel 是跑 Messaging API 的通道，Channel Secret 與 Access Token 是鑰匙。）如果開發商圖方便把你的 Bot 建在他自己公司的 Provider 底下，這些資料在名義上屬於誰就不是你以為的答案——合約約束雙方的權利義務，平台規則決定帳號掛在誰名下，這是兩件事。

還有一個最容易被低估的技術細節：業界普遍理解 userId 是在 Provider 範圍內產生的識別碼，同一位使用者在不同 Provider 底下取得的 userId 並不相同，而 userId 是你的系統辨識「這位好友是誰」的唯一依據，會員綁定、消費紀錄、分眾標籤全掛在這串 ID 上。至於 Channel 能否跨 Provider 轉移，LINE 官方文件並未載明明確規則，屬於資料不足；業界普遍認為不容易變更，但既然官方沒寫死就不該寫成絕對，合理的做法是簽約前確認並留下書面紀錄。

把時間快轉到「你決定不跟這家廠商合作了」的那一天，差別會很清楚。Provider 用你公司的名義建立、Token 你也有一份，換廠商是有限的麻煩：交出原始碼、資料庫、環境設定與部署文件就能接手，Bot 不用重建、userId 不變。Provider 建在開發商名下、Token 你從沒拿過，資料歸屬在名義上就不在你這裡；若必須在自己的 Provider 底下重建 Channel，userId 會是新的一組，你可能得請所有會員重新綁定一次。兩種情境的開發報價可能完全一樣，但總成本差多少，取決於你有沒有第二年要換人。

多數合作不會走到最壞的情況；要指出的只是——當你必須依賴對方的善意才能拿回自己的東西時，你就沒有議價能力了。做法不複雜：簽約當下把 Provider 名義、Token 保管、交接清單寫進合約，成本是零。

報價單上看不到、但很可能會出現在你帳上的三筆錢

一、把 LINE 使用者接到你自家會員身上，本身就是一個專案

「串接公司現有的 CRM」在報價單上常常只是一行字。一般系統串接的老問題（舊 ERP 沒有 API、欄位要清洗）這裡不重複，值得單獨講的是 LINE 特有的那一段：LINE 的 userId 和你系統裡的會員 ID 是兩套完全不相干的識別碼，中間必須設計一段綁定流程，而這段流程的成敗會決定整個專案的實際效益。 吃工時的是綁定要用什麼當鑰匙（手機號碼 OTP、訂單編號還是會員卡號，驗證成本與失敗率都不同，而每一次 OTP 簡訊都是第四層的錢），以及綁定率永遠不會是 100%——只有六成好友完成綁定，「依會員資料分眾」的功能實際覆蓋就只有六成，報價單上寫的卻是 100%。所以該問的不是「串接多少錢」，是「綁定流程怎麼設計、預期綁定率多少」。

二、法遵是真實的開發工項，不只是一份隱私權政策

一個常被忽略的前提是：使用者加你好友，通常不會被直接當成他同意你蒐集、處理他的個人資料——這是實務上律師專文普遍持的看法。只要 Bot 開始跟使用者要手機、Email、生日，就進入個人資料保護法的蒐集行為。

法規依據	對應的開發工項	不做的後果
個資法第 8 條	蒐集前的告知頁：機構名稱、蒐集目的、個資類別、利用的期間地區對象方式、當事人權利、不提供的影響	告知不完備，蒐集行為即有瑕疵
個資法第 20 條第 2、3 項	退訂機制、推播前的名單過濾	首次行銷未提供拒絕方式、拒絕後未停止
個資法施行細則第 8 條	委外合約須約定範圍、受託者安全措施、能否複委託、違法通知、終止時載體返還或刪除	委外不免責，責任不隨外包移轉
個資法第 48 條	安全維護事項的落實與限期改正	屆期未改正可按次處 15 萬元以上、1,500 萬元以下罰鍰

（醫療、健檢、長照等涉及第 6 條特種個資的產業門檻更高。「未使用個資、單純對全體好友群發」是否涵蓋在第 20 條內，公開檢索沒有找到明確函釋，屬於資料不足；流傳的「最高 15 億」則是單位換算錯誤。個資法已於 2025 年 11 月 11 日修正公布，新增事故通知與通報義務等規定，但施行日期由行政院另定，截至查證時尚未確定。本段為一般性說明，非法律意見，個案請諮詢律師。）

如果 Bot 會承載交易，依消費者保護法第 19 條，七日解除權的告知與退款流程通常要做進系統（依「通訊交易解除權合理例外情事適用準則」第 2 條，客製化給付、非以有形媒介提供的數位內容等情形經告知後可排除）。在 LINE 上它多了一個實作問題：告知放在哪一則訊息裡、按了什麼算已閱讀、退貨要不要做成一個流程分支——網頁上這是結帳頁的一個區塊，在 LINE 上是好幾個對話節點。

三、維護費裡真正屬於 LINE Bot 的那一項

維護費的通用組成（主機維運、功能更新、故障排除）不在這裡重複，那三項在任何委外系統都一樣。LINE Bot 的維護費裡有一項是網站與 APP 沒有的：平台變動的跟進。 憑證到期、TLS 版本被停用、Messaging API 改版、webhook 事件格式調整——任何一項發生，症狀都是已經上線的 Bot 突然收不到任何訊息，使用者只覺得「你們的 LINE 壞了」，而且它是靜默的。所以維護費該問的不是「一年幾趴」（國際上這個比例的說法從 15% 到 100% 都有，差距大到代表沒有參考價值），而是三個是非題：平台改版跟進在不在維護費裡？有沒有做 webhook 健康監測？憑證到期前多久會有人動作？ 至於台灣本地的維運與主機成本區間，流傳的數字逐頁查證後都無法回溯到可指認的來源，屬於資料不足，本文不列。

簽約前先問完這十題，報價才有比較的基礎

比價常常無效，是因為兩張報價單根本在講不同的東西。一般軟體外包的共通問題（智財權歸屬、套件授權、驗收標準、變更計價、保固期）這裡不重複，本表只列 LINE Bot 專屬、問錯了會反映在每月帳單或三年後選擇權上的十題。

#	該問的問題	為什麼要問
1	LINE 官方帳號的 Provider 用誰的名義建立？	決定資料歸屬與移轉可能性
2	Channel Secret 與 Access Token 由誰保管？你能否取得一份？	決定你能不能自己接手或換人
3	哪些訊息走 Reply、哪些走 Push？預估每月幾則？	決定你每月付給 LINE 多少錢
4	額度監控做不做？閾值多少、通知誰、怎麼降級？	超額時 API 只回錯誤，失敗得安靜
5	圖文選單走官方後台還是 Rich Menu API？以後誰能改？	後台建的選單只能後台改
6	Flex Message 要測到哪些機型與 LINE 版本？寫在哪裡？	跨機型差異是工時，也是驗收爭議來源
7	需審核的項目（email scope／LINE Pay／Notification Messages）誰送件、何時送？	卡審核不是加錢能解決，送晚就過檔期
8	會員綁定用什麼當鑰匙？預期綁定率多少？	綁定率決定分眾功能的實際覆蓋範圍
9	個資告知同意、退訂機制、資料刪除與返還怎麼做？	委外不免責，這是法規要求
10	終止合作的交接清單有哪些？（Provider 權限、Token、原始碼、資料庫、部署文件）	第一天就該想好最後一天

付款節奏也一起看：比例應該對應交付物而不是時間——「簽約付一半、上線付一半」代表整個開發期間都沒有檢查點。這張表也不只是拿答案，還是拿反應：該警覺的是十題全部秒答「都可以」的那種。

如果你正在整理需求、還沒決定要租現成的還是自己做一套，可以帶著這張表，找像瞻新資訊這樣習慣先把流程盤清楚再動手的團隊聊聊——先確認要解決哪一個流程、誰來維運、三年後要帶走什麼，報價才會是一個有意義的數字。

LINE Bot 開發費用常見問題

把四個問題分開問，報價單就看得懂了

「LINE Bot 開發費用多少」之所以難回答，是因為它問的其實是四個問題疊在一起：付給 LINE 多少、付給開發商多少、每個月還要付多少，以及三年後我還剩下什麼。

在拿到任何一個數字之前，還有一件比預算更早該回答的事：這個 Bot 上線之後，公司裡誰負責它？ 不是誰負責付錢，是誰改話術、誰每月看訊息用量、誰在額度快滿時決定要不要升級。這幾件事指不出人，Bot 退化的方式會很特別：不是壞掉，是話術過期、選單指向已下架的活動、推播照排程發但沒人看數據，看起來還活著，實際上在燒訊息費。

以台灣中小企業的規模來看，務實的期待通常落在「少回一百次一樣的問題」「預約不用再靠人工排班表」這個尺度，不是取代整個客服中心。把目標訂在這裡，報價單自然就看得懂了。