LINE 是台灣最主流的通訊軟體之一，不只用在私人聯絡，也有不少公司直接把 LINE 當作內部溝通工具。「重要事情直接丟群組確認」幾乎已經成為很多人的工作習慣。

kintone 本身其實就有相當完整的通知機制，但在實務上，仍常聽到使用者提出類似需求：

• 希望重要異動能同步出現在 LINE 群組
• 不想只依賴 kintone 內建通知或 Email
• 希望非 kintone 使用者也能即時看到資訊

本篇文章將介紹一個不需撰寫程式碼的作法：
透過自動化工具 Make，串接 kintone 與 LINE 官方帳號，在 kintone 應用程式新增記錄時，將重點資訊即時推送到指定的 LINE 群組。

本範例所需環境

• kintone 環境
• LINE 官方帳號（LINE Official Account）
• Make 帳號

※ 注意
LINE 官方帳號與 Make 皆為付費服務，雖然各自都有免費方案，但仍有訊息則數、執行次數等限制。實際費用與方案內容請以官方說明為準。

實作原理說明

一般的 LINE 個人帳號無法進行 API 操作，因此必須使用 LINE 官方帳號 作為發信端。

整體流程如下：

1. kintone 新增記錄
2. kintone 透過 Webhook 將資料送出
3. Make 接收 Webhook 資料
4. Make 呼叫 LINE Messaging API
5. 將整理後的訊息推送到指定的 LINE 群組

其中，推播訊息使用的是 LINE Messaging API 的 Send a Push Message，因此需要事先取得目標群組的 groupId。

實作步驟概覽

1. 申請 LINE 官方帳號並啟用 Messaging API
2. 使用 Make 建立 LINE Webhook，取得群組 groupId
3. 在 Make 建立 custom webhook，並設置到 kintone
4. 將 kintone 記錄資訊整理後推送到 LINE 群組

Step 1. 申請 LINE 官方帳號與啟用開發者後台

首先前往 LINE Biz-Solutions ，點擊「免費開設帳號」，填寫必要資訊完成申請。

▼ 申請完成後可直接進入管理畫面（不需先做帳號認證）

▼ 點擊右上角「設定」

▼ 在「設定＞帳號設定＞功能切換」中，啟用「接受邀請加入群組或多人聊天室」

這個設定非常重要，否則官方帳號無法被加入 LINE 群組。

接著，請將官方帳號加入為好友，並建立一個用來接收通知的 LINE 群組，再邀請官方帳號加入該群組。

※ 注意事項
一個 LINE 群組中只能存在一個官方帳號。
若加入第二個官方帳號，原本的官方帳號會被自動退出。

▼ 接著在「設定＞Messaging API」，啟用 Messaging API

▼ 建立新的「服務提供者（Provider）」

▼ 完成後，前往 LINE Developers Console 進行其他設定。

▼ 在 Providers 中找到剛建立的 Channel

▼ 於 Messaging API 頁面底部建立 Channel access token

此 token 將用於 Make 串接 LINE API，請妥善保存，避免外洩。

Step 2. 使用 Make 建立 LINE Webhook，取得群組 groupId

使用 Push Message 推播時，必須指定收件者（userId 或 groupId），
因此第一步需要先取得目標 LINE 群組的 groupId。

Make 提供的 LINE Watch Events 模組，可以在官方帳號收到訊息時，取得完整的事件物件（Event Object）。

▼ 在 Make 建立新的 Scenario，並加入 LINE Watch Events

▼ 使用 Channel access token 建立 webhook

▼ 再加入 LINE Send a Reply Message 模組，用來回傳事件內容

Make 提供的 LINE API 模組中，已經預先定義好對應的資料結構與欄位型別。
在設定訊息內容時，只要點擊欄位項目，即可直接帶入 webhook 事件中可用的各項資料，不需要自己手動組 JSON 或記欄位名稱。

※ 需留意：Connection 通常會自動帶入先前建立的設定，不過如果帳號中同時存在多個 LINE 官方帳號的 Connection，建議在這裡稍微確認一下，確保是使用正確的 Channel 進行發送。

Source 物件中會包含：

• type：對話來源類型（使用者 / 群組）
• userId
• 若來自群組，則會包含 groupId

本範例需要的是 groupId。

本範例後續要將通知內容推送到群組中，故要取得 groupId。

▼ 設定完成後，請先儲存 Scenario 並啟動

▼ 回到 LINE Developers Console，在對應的 Channel 設定中填入 Make 所產生的 webhook URL

▼ 回到加入官方帳號的 LINE 群組中，隨意傳送一則訊息。
若前述設定皆正確，群組中會收到由 Make 回傳的事件內容（Source 物件）。

請將其中的 groupId 值複製並妥善保存。
此 ID 為該 LINE 群組的識別碼，後續呼叫 Push Message API 時，必須指定此 groupId，訊息才會被正確推送到對應的群組對話中。

完成 groupId 取得後，這個 Scenario 即可關閉，避免持續監聽事件而產生不必要的執行次數與額度消耗。

Step 3. 在 Make 建立 custom webhook 並設置到 kintone

接下來要建立一個專門接收 kintone 新增記錄事件 的 webhook。

▼ 建立新 Scenario，加入 Custom webhook

▼ 建立 custom webhook 並取得 webhook URL

建立完成後，custom webhook 會先進入「等待接收資料結構」的狀態。
此時請先將 webhook URL 複製下來，接著前往 kintone 應用程式設定進行 webhook 設置。

▼ 進入 kintone 應用程式設定：「設定＞自訂/服務整合＞Webhook」
點擊「新增」，貼上剛才取得的 webhook URL，並勾選啟用後儲存，最後記得更新應用程式設定。

更新應用程式後，實際新增一筆記錄進行測試。
完成後回到 Make 的 Scenario 畫面查看執行結果。

▼ 若 Make 成功接收到資料，並能正確解析 kintone 傳送的內容，畫面會顯示「Successfully determined」，請點擊「Save」保存此資料結構設定。

kintone 透過 webhook 傳送的通知內容，包含應用程式資訊、記錄內容與欄位值等資料。
完整資料格式與說明可參考官方文件：
https://jp.kintone.help/k/zh-tw/id/040602

Step 4. 將 kintone 記錄資訊推送到 LINE 群組

最後一步，將 Make 接收到的 kintone 記錄資料整理後，透過 LINE Messaging API 的 Push Message 功能，將通知內容推送到指定的 LINE 群組中。

▼ 在 Scenario 中加入 LINE Push Message 模組

▼ 設定推播訊息的必要參數

設定說明：

• Connection：
  選擇在 Step 1 中建立的 LINE 官方帳號連線設定。
• To：
  推播訊息的收件對象，請填入在 Step 2 取得的 groupId，以確保訊息會被送至正確的 LINE 群組。
• Messages：
  編輯欲傳送的訊息內容。
  Make 會列出先前解析完成的 kintone webhook 資料結構，可直接點選欄位帶入應用程式名稱、記錄內容或欄位值等資訊。

💡補充說明
Make 內建多種資料處理函式可供使用。
例如，直接取得 kintone 的日期時間欄位（record.日期時間欄位.value）時，資料會以 ISO string 的形式傳入，可透過 formatDate() 函式轉換成較易閱讀的日期時間格式。

儲存設定並啟用 Scenario 後，回到 kintone 應用程式新增一筆記錄進行測試。
若設定皆正確，就能在指定的 LINE 群組中收到推播通知訊息囉！

注意事項

Make 與 LINE 官方帳號皆屬於付費服務，但兩者皆提供一定的免費額度可供試用。
實際使用時，建議依照通知頻率與使用情境，評估是否需要升級方案。

LINE 的主動推播訊息（Push Message）會依推送則數計算用量。
以目前的輕用量（免費方案）為例，每月可免費推送 200 則訊息，另有中用量與高用量方案可供選擇。實際方案內容與收費方式，請以 LINE Official Account 當下提供的資訊為準。

Make 則會依 Scenario 的執行次數與步驟數消耗 credits。
免費方案在 credits 數量、可啟用的 Scenario 數量等方面皆有一定限制，若使用情境較為頻繁，可再視需求選擇合適的方案，實際規則以 Make 官方說明為主。

結語

本範例示範了在不撰寫程式碼的情況下，如何透過自動化工具完成 kintone 與 LINE 的簡單通知串接。
藉由 Make 提供的模組化功能，即使不自行架設後端伺服器、也不需要深入研究 LINE Messaging API 的使用方式，仍能快速實現基礎的通知需求。

在需求不複雜、且缺乏開發或後續維護資源的情境下，這樣的作法是一個相對容易嘗試、成本也較低的選擇。