---
title: "サーバー不要でLINE×AIチャットボットを作る｜Difyの4ノード構成と5秒ルール対策"
excerpt: "Difyのワークフロー機能だけで、サーバーレスにLINE × LLMの双方向連携を実現しました。最重要はasync_mode: trueの設定で、これがないとLINEの5秒ルールに引っかかり再送が続きます。replyTokenの30秒制限、RAGへの拡張パス、本番運用に足りないセキュリティ要件までまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-05-03T00:00:00+00:00
verified_at: 2026-05-03T00:00:00+00:00
models: ["Claude"]
tools: ["Dify", "LINE"]
tasks: ["ナレッジ活用・RAG", "ツール検証"]
canonical_url: https://ai-katsu.jp/articles/line-dify-chatbot
---
# サーバー不要でLINE×AIチャットボットを作る｜Difyの4ノード構成と5秒ルール対策

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

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

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証日 | 2026年5月3日 |
| 構成 | Dify 0.6.0（ワークフロー）× LINE Messaging API／LLM: claude-haiku-4-5-20251001 |
| やりたかったこと | コード最小限でLINE ↔ LLMの双方向連携を実現し、最小構成での動作を確認する |
| 結果 | **4ノード構成で完全動作。手動テスト10回中10回成功** |
| 応答速度 | LINE送信〜返信受信まで**3〜6秒** |
| 初期設定時間 | 約30〜60分 |
| 判定 | **条件付きで導入可**（PoC・プロトタイプ用途） |

## 結論：`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` 配列が空の状態で飛んでくるため、これがないとエラーになります。

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

## つまずいた点

| エラー・症状 | 原因 | 対処法 |
| --- | --- | --- |
| **LINEから返信が来ない（タイムアウト）** | `async_mode` が false | Webhookノードの `async_mode: true` を設定 |
| replyTokenが空で返信失敗 | events配列が空、またはノードID間違い | ガード処理と変数参照のノードIDを確認 |
| 401 Unauthorized | Authorizationヘッダーの書き方誤り | **`Bearer チャネルアクセストークン`（波括弧なし）**で記述 |
| 変数が `undefined` になる | 変数参照構文のノードIDが間違い | YAMLの `id` フィールドを確認 |

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から先へ進める条件になります。**

## コスト

| 項目 | 内容 | 金額 |
| --- | --- | --- |
| Dify Cloud | Freeプランで月200メッセージ | 0円（有料プラン $59/月〜） |
| LINE Messaging API | 月200通まで無料 | 0円（超過分 ¥3/通〜） |
| LLM（Haiku） | トークン従量課金 | 入力 $0.80 / 出力 $4.00 per MTok |

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

## セキュリティ上の課題

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

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

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

## 他の構成との比較

| 項目 | Dify + LINE | n8n + LINE | 自前Pythonサーバー |
| --- | --- | --- | --- |
| 構築コスト | **低（ノーコード）** | 低〜中 | 高 |
| **ホスティング** | **不要** | 自前またはクラウド | 自前必須 |
| LLM切り替え | 容易（ノード変更） | 容易 | コード変更必要 |
| RAG拡張 | **簡単（ブロック追加）** | プラグイン依存 | 自前実装 |
| カスタマイズ性 | 中 | 高 | 最高 |

## よくある質問

### サーバーは必要ですか？

**不要です。**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チャットボット導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。