サーバー不要でLINE×AIチャットボットを作る｜Difyの4ノード構成と5秒ルール対策【AI活用検証vol.84】

LINE上でAIチャットボットを動かすには、通常Node.jsやPythonのサーバーが必要です。PoC段階でそこまで用意するのは、コストに見合いません。

この検証では、Difyのワークフロー機能だけでサーバーレスにLINE × AIの双方向連携を実現しました。構成は4ノード、初期設定は約30〜60分です。

この検証の概要

結論：async_mode: true が必須設定

この検証で最も重要な発見です。

LINEやSlackなど「5秒ルール」を持つWebhook統合では、async_mode: true が必須設定です。これを外すとLINEが再送を繰り返します。

LINEのWebhookは、5秒以内にレスポンスを返さないと再送が発生します。しかしLLMの処理は数秒かかります。デフォルト設定（async_mode: false）で試したところ、タイムアウトエラーが連続発生しました。

「受け付けたことをすぐ返し、処理は後で行う」——非同期化がこの構成の前提条件になります。

アーキテクチャ：4ノードで完結する

LINE ユーザー
    ↓（テキストメッセージ送信）
LINE サーバー
    ↓（Webhook POST: events[].message.text + replyToken）
Dify: Webhook トリガーノード（async_mode: true）
    ↓
Dify: コード実行ノード（Python3 でペイロードを解析）
    ↓（text, replyToken, messageType を出力）
Dify: LLM ノード（回答生成）
    ↓（回答テキスト）
Dify: HTTP リクエストノード（LINE Reply API へ POST）
    ↓
LINE ユーザーへ返信

サーバーのホスティング・管理が一切不要である点が最大のメリットです。

ペイロード解析のガード処理

コード実行ノードのPythonは短いものですが、1点だけ実務的な工夫があります。

def main(arg1: dict) -> dict:
    body = arg1.get("body") or {}
    events = body.get("events") or []
    event = events[0] if events else {}

    message = event.get("message") or {}
    message_type = message.get("type") or ""

    return {
        "text": message.get("text", "") if message_type == "text" else "",
        "replyToken": event.get("replyToken", ""),
        "messageType": message_type,
    }

events[0] if events else {} というガード処理が効きました。LINEの検証用Webhookは events 配列が空の状態で飛んでくるため、これがないとエラーになります。

あわせて、テキスト以外（スタンプ・画像等）が来た場合のハンドリングもコードノードに入れておくと安定します。

つまずいた点

Difyの変数参照は {{#ノードID.変数名#}} 形式で、ノードIDはYAML上の id フィールドの値です。慣れるまでは分かりにくい部分です。

もう1点、地味に引っかかるのがAuthorizationヘッダーです。YAMLのコメントにプレースホルダーとして波括弧が書かれていることがありますが、実際の記述に波括弧は不要です。

replyTokenの30秒制限

本番運用を考えるうえで押さえるべき制約です。

LINEのreplyTokenは発行から30秒で失効します。LLMの処理が長引く場合、返信できなくなります。

対策はPush API（/v2/bot/message/push）への切り替えです。事前にユーザーIDを取得・保存しておく必要がありますが、replyTokenの制限から解放されます。

短い応答ならReply API、長文生成や重い処理を挟むならPush API——という使い分けになります。

RAGへの拡張パスが明確

この構成の将来性として評価している点です。

コード実行ノード
    ↓
知識検索ブロック  ← Dify ナレッジ（PDF・テキスト等を事前登録）
    ↓
LLM ノード（ナレッジを context として参照して回答）
    ↓
HTTP リクエストノード（LINE 返信）

コード実行ノードとLLMノードの間に知識検索ブロックを1つ挟むだけで、FAQ Bot・社内規定参照Botに変わります。

汎用的なQ&Aから、自社のドキュメントを参照するボットへ——この移行コストが低いことが、PoCから先へ進める条件になります。

コスト

PoC段階なら実質0円で試せます。本番運用ではDifyのプラン上限とLINEの通数課金が効いてきます。

セキュリティ上の課題

この構成のまま本番に出すべきではない点も記録しています。

• チャネルアクセストークンをHTTPノードのヘッダーにベタ書きしている → 環境変数化が必要
• 署名検証（x-line-signature）が未実装 → Webhook URLを知られると偽リクエストを受け付ける
• Dify Cloudにメッセージが通過するため、機密情報を送らせない設計が必要
• Dify Cloudのデータ保管地域を確認すること

PoCで動かすことと、本番で運用することの間には、この差があります。署名検証は特に、外部から叩かれる前提のエンドポイントでは必須です。

他の構成との比較

よくある質問

サーバーは必要ですか？

不要です。DifyのWebhookトリガーがエンドポイントになるため、ホスティングも管理も発生しません。

LINEからの返信が来ません

Webhookノードの async_mode が true になっているか確認してください。デフォルトの false のままだと、LINEの5秒ルールに引っかかってタイムアウトが連続します。

本番運用できますか？

この構成のままでは推奨できません。チャネルアクセストークンの環境変数化と、署名検証（x-line-signature）の実装が必要です。またDify Freeプランのメッセージ数上限にも注意が必要です。

社内FAQ Botに拡張できますか？

できます。コード実行ノードとLLMノードの間に知識検索ブロックを1つ追加するだけです。ファイルをアップロードして登録すれば対応できます。

まとめ

• 4ノード構成でLINE × AIチャットボットがサーバーレスに動作（手動テスト10回中10回成功）
• async_mode: true が必須設定。LINE / Slackの「5秒ルール」を持つ統合では外せない
• ペイロード解析にはevents配列が空の場合のガード処理を入れる
• replyTokenは30秒で失効。処理が長い場合はPush APIへ切り替える
• 知識検索ブロックを1つ挟むだけでRAG対応。PoCから先への移行コストが低い
• 本番運用にはトークンの環境変数化と署名検証の実装が必要
• PoC段階なら実質0円で試せる

AIチャットボットは、動かすところまでは短時間で到達できます。差が出るのは、そこから本番運用の要件を満たすまでの部分です。何が足りないかを最初に把握しておくと、判断が早くなります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAIチャットボット導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。