LINEを承認窓口にしてAI自動化の確認作業をなくした仕組み

LINE Messaging APIとは何か、承認窓口として使う発想

LINE Messaging APIは、LINEの公式アカウントを介してメッセージの送受信をプログラムから操作できる仕組みです。結論から言うと、私はこれを「承認待ちの作業を代わりに監視してくれる窓口」として使っています。

LINE Messaging API自体は、ユーザーからのメッセージを受け取るWebhook機能と、こちらからメッセージを送るプッシュ送信機能の2つが基本です。チャットボットとしての活用例はすでに多く紹介されていて、LINE公式アカウントのAI活用方法を解説やLINEにおけるAIエージェント活用事例では、問い合わせ対応や接客の自動化事例が中心に取り上げられています。

ただ、個人で自動化スクリプトを回している立場から見ると、LINEのもう一つの価値は「毎日開くアプリに、承認か否かの判断だけを届けられる」点にあります。管理画面を別に作ってログインする手間をなくし、通知が来たらその場で「承認」と打つだけで次の処理が走る。この発想が、今回紹介する仕組みの出発点です。

n8n→LINE→Supabaseで動く承認フローの全体像

結論として、承認フローは「スクリプトが依頼を作る」「n8nがLINEに通知する」「返信でSupabaseが更新される」という3段階だけで成立しています。いまはn8nの部分をCloudflare Workerと手元の実行機に置き換えていますが、流れは同じです。

私のサイトでは、記事生成や案件への応募文作成を担うPythonスクリプトが、投稿前の内容を承認待ちとしてSupabaseのapprovalsテーブルにINSERTします。そこからの流れを手順にすると次のとおりです。

1. スクリプトが承認依頼のレコードをSupabaseに作成する。このときstatusは「未承認」で保存する。
2. 同じスクリプトがn8nのWebhook URLにPOSTリクエストを送り、承認待ちの内容(タイトルや本文の要約)を渡す。ここでWebhookのURLを間違えるとn8n側が何も反応せず、原因がスクリプト側にあるのかn8n側にあるのか切り分けに時間がかかるので、まずn8nのテスト実行モードで受信確認をしてから本番に切り替えるようにしています。
3. n8nのワークフローがLINE Messaging APIのプッシュ送信ノードを呼び出し、スマートフォンのLINEに通知を送る。
4. 通知を確認し、内容に問題がなければ「承認」とだけ返信する。問題があれば返信せず、翌日以降に手元で修正してから再実行する。
5. LINEからの返信はn8nのWebhookで受信し、本文が「承認」と一致した場合のみSupabaseのapprovalsテーブルのstatusを更新する。
6. ステータス更新をトリガーに、別のスクリプトまたはn8nのワークフローが自動投稿を実行する。

この一連の仕組みは、定時タスクの運用の中の一部として動いています。案件収集・応募文作成・記事生成・計測といった処理をWindowsのタスクスケジューラとPythonで定時実行し、AIによる分類や下書き作成のあとにLINE webhookを経由した人の確認を挟み、Cloudflare WorkerとSupabaseでデータを受け渡す構成です。公開や送信は必ず人が確認してから行う設計にしていて、LINEはその確認作業の入口にあたります。

実際にやってみて詰まった場所と対処

結論として、返信テキストだけで制御する仕組みはシンプルな分、表記ゆれと二重承認への対策を先に決めておく必要があります。

実際に運用して詰まった場所と、それぞれどう対処したかを整理します。

1. 表記ゆれで承認が通らない。「承認」ではなく「承認します」「OK」と返信してしまい、ステータスが更新されないことがありました。対処として、n8nの条件分岐で完全一致ではなく「承認」という文字列を含むかどうかの判定に変更しています。
2. 二重返信で処理が重複しそうになる。一度「承認」と送ったあと、通知を忘れて再度「承認」と送ってしまうケースです。Supabase側でstatusがすでに「承認済」の場合は更新クエリを実行しない、という条件をn8nのワークフローに入れることで、同じ投稿が二重に実行されるのを防いでいます。
3. 承認待ちのまま放置してしまう。通知が来てもすぐに確認できず、数日経ってから「承認」と返したところ、投稿対象の情報が古くなっていたことがありました。これについては仕組みで防ぐより、承認依頼の本文に対象の日付を必ず入れておき、自分で古さに気づける状態にする運用でカバーしています。
4. エラー通知が増えすぎて埋もれる。スクリプトのtry-exceptでエラーを検知するたびにLINEへ飛ばす設計にしたところ、一時的なネットワークエラーのようなものまで通知が来て、本当に見るべき通知が埋もれました。対処として、同じ種類のエラーが短時間に繰り返し出た場合はまとめて1通にする、軽微なエラーは翌朝のログ確認に回すという優先度分けを入れています。

LINE Messaging API側にプッシュ送信を試すときの基本形だけ共有しておきます。n8nを使わず直接Pythonから送信する場合はこのような形になります。

import requests

url = "https://api.line.me/v2/bot/message/push"
headers = {
    "Content-Type": "application/json",
    "Authorization": f"Bearer {CHANNEL_ACCESS_TOKEN}"
}
payload = {
    "to": USER_ID,
    "messages": [
        {"type": "text", "text": "承認待ち: 記事Aを投稿してよいか確認してください"}
    ]
}
response = requests.post(url, headers=headers, json=payload)
print(response.status_code, response.text)

このコードで詰まりやすいのは、CHANNEL_ACCESS_TOKENの期限切れとUSER_IDの取り違えです。チャネルアクセストークンは発行方法によって有効期限が異なるため、長期運用する場合は長期トークンを選ぶか、定期的に再発行するスケジュールを決めておく必要があります。

いま動いている実績と費用感

結論として、この規模の個人運用であれば、LINE連携のAPI実費はごくわずかで、無料枠を大きく超えることはありません。

LINE公式アカウントの無料プランは月200通までですが、数えられるのはこちらから送るプッシュ通知だけで、相手のメッセージに返す返信は数に入りません。承認依頼を1日に数通送る程度なら枠を使い切らず、Webhook側にも費用はかかりません。

承認フロー以外のLINE活用：問い合わせ対応や他ツールとの連携

結論として、LINE Messaging APIは承認窓口だけでなく、問い合わせ対応の窓口としても同じ仕組みで動かせます。

私はサイトのLINE公式アカウントで、生成AIが自動で返答するチャットボットを動かしています。友だち追加したユーザーからのメッセージをWebhookで受け取り、登録した内容をもとにAIが返答する構成で、承認フローとWebhookの受け口を共有しています。

同じ考え方で、問い合わせの自動返答も作っています。登録した内容の範囲でだけ回答し、答えられない質問は担当者に回す管理画面つきの受付で、サンプルを 問い合わせ自動返答のデモ として公開しています。承認フローで使っているWebhookの受け口と仕組みを流用できるため、ゼロから別物を作るより着手しやすいと感じています。

通知と問い合わせ対応を同じLINE公式アカウントでやると、どちらの用途のメッセージか判別しにくくなる場面も出てきます。この点については、チャンネルを分けながらユーザーIDを共有する設計を扱った別記事でも触れているので、複数の用途でLINEを使う場合は参考にしてみてください。

まとめ：自分のフローにLINEを組み込む最初の一歩

ここまでの仕組みが目指しているのは、確認のためにパソコンを開く回数を減らすことです。承認フロー全体を一度に作る必要はありません。

最初の一歩としておすすめなのは、既存のスクリプトのうち1つだけを選び、そのエラー通知だけをLINEに飛ばす設定から始めることです。承認フローよりも実装が単純で、try-exceptでエラーを検知した箇所にLINE Messaging APIへのプッシュ送信を1行足すだけで動きます。まずそこで通知が届く感覚をつかんでから、承認待ちのステータス管理をSupabaseに持たせる設計に進む順番が、詰まりにくいと感じています。