はじめに
この記事は、DifyとGoogle Calendarを連携させたLINE秘書アプリを構築しようとして、最終的に動かなかった試行錯誤の記録です。読み終わるころには、以下のことがお分かりいただけます。
- Dify単体でのLINE連携が、なぜ構築は簡単なのに本番稼働に至らないのか
- マーケットプレイスの「公式プラグイン」と「コミュニティ製プラグイン」の見分け方
- LINEやMicrosoft Teamsのような外部サービス連携では、n8nの方が安定する理由
- この構成で実装を始める前に知っておくべき判断基準
結論から申し上げます。秘書アプリは最後まで動きませんでした。Dify単体で完結させようとしたのが原因でした。同じことを検討している方は、この記事を読んでから構成を決めていただくと、時間を節約できるかと思います。
何を作ろうとしたのか
当社が提供するAIエージェント導入サービスのデモとして、以下のようなアプリを構築したいと考えていました。
- LINEで「明日15時から打ち合わせ」と送ると、Googleカレンダーに予定が登録される
- 「今週の予定は?」で予定一覧を返す
- 「来週で1時間空いてる時間ある?」で空き時間の候補を提示する
- 削除・変更は対応しない(後述します)
要は、LINEで話しかけるだけで予定管理ができる「秘書くん」です。想定ユーザーは中小企業の経営者や個人事業主。スマホでLINEを開くだけで、外出先でも予定が入れられる世界観を目指しました。
構成案: Dify単体で完結させる
最初に考えた構成は以下のとおりです。
LINE Messaging API
↓ Webhook
Dify (Line Bot プラグイン + Google Calendar プラグイン)
↓
Claude Sonnet 4.6 (Function Calling)
↓
Google Calendar API
↓
返信 → LINEn8nもRailwayも使わず、Dify Cloudだけで完結させる構成です。既にn8nベースの別サービスを動かしていたのですが、Difyの可能性を検証したかったので、あえてn8nを外しました。
Difyマーケットプレイスを見ると、LINE連携もGoogle Calendar連携もプラグインとして存在します。一見、パーツは全部揃っているように見えました。
設計判断: 削除機能は絶対に入れない
実装に入る前に、秘書機能の範囲を決めました。CRUD(作成・読取・更新・削除)のうち、採用したのは作成と読取だけです。
「削除」と「更新」は意図的に外しました。理由はシンプルで、Googleカレンダーはただのコンテナであって、予約の実体ではないからです。
たとえばGoogleマップでレストランを予約すると、Gmail経由でカレンダーにイベントが自動登録されます。このとき、カレンダーのイベントを削除しても、レストラン側の予約台帳は微動だにしません。お店は普通にテーブルを用意して客を待ちます。結果として、無断キャンセル扱いになってしまいます。
会議も同じです。Zoomで作成した会議をカレンダーから消しても、Zoomのミーティング自体は残ります。参加者にキャンセル通知も飛ばないことが多いです(設定次第ですが)。
AI秘書がこれをやると何が起きるでしょうか。「明日の歯医者キャンセルして」と言われて、カレンダーから消して「削除しました」と返信する。ユーザーは処理が完了したと信じ込む。結果、すっぽかし、ペナルティ、謝罪電話という連鎖が生まれます。AIに「取り消せない副作用を持つ操作」を任せるのは設計として危険です。
そこで秘書くんは、削除リクエストには以下の定型文で答える設計にしました。
予定の削除・変更は、カレンダーアプリから直接操作をお願いします。理由は、レストランや病院などの予約は、カレンダーを消しても予約元には取り消しが伝わらないためです。
この設計思想自体は、結果的に動かなかった秘書くんでも筋は通っていたので、記録として残しておきます。同じ構成のAI秘書を作る方は、ぜひ削除機能は見送っていただきたいです。
実装開始: OAuth認証までは順調
実装は以下の順で進めました。
- Google Cloud Console でプロジェクト作成、Calendar API有効化、OAuth同意画面設定、Client ID/Secret発行
- Dify Cloud で Google Calendar プラグインをインストール、OAuth認証
- Line Bot プラグインをインストール、エンドポイント作成
- Agent アプリ「秘書くん」を作成、Claude Sonnet 4.6 を選択
- システムプロンプトを入力、Google Calendarツールを紐付け
ここまでは大きな問題なく進みました。Debug & Preview のテストチャットでは、秘書くんが完璧に動作します。「明日15時から打ち合わせ」でカレンダーに予定が入ります。「今日の予定は?」で一覧が返ります。削除要求には定型文で丁寧に断ってくれます。
OAuth設定でハマった点(解決済み)
Google OAuth の設定で1つだけ罠がありました。リダイレクトURIの登録が二往復必要になります。
Google Cloud Console でOAuthクライアントを作成するとき、「承認済みリダイレクトURI」の登録が必須ですが、この値はDifyのプラグイン認証画面に実際にアクセスするまで確定しません。プラグイン毎に動的に発行される仕組みだからです。
実際に発行されるURIは以下のような形式になります。
https://cloud.dify.ai/console/api/oauth/plugin/langgenius/google_calendar/google_calendar/tool/callback手順としては次のようになります。
- Google側で仮のURI(例:
https://cloud.dify.ai/)を登録してOAuthクライアントを作成 - Dify側でGoogle Calendarプラグインの認証画面を開き、表示されるRedirect URIをコピー
- Google側に戻ってリダイレクトURIを上書き更新
- Dify側に戻って認証を実行
公式ドキュメントにこの手順が明記されていないため、最初は redirect_uri_mismatch エラーで悩むことになります。Dify側に表示された値をそのまま使う、というのが正解です。
最大の罠: 日付がズレる
秘書くんが「明日15時から打ち合わせ」を登録した後、実際のGoogleカレンダーを見に行くと、予定が追加されていないという現象に遭遇しました。
ツール実行ログを確認すると、ステータスはSUCCESSです。しかし登録された日付が 2025-07-11 でした。現在は2026年4月です。10ヶ月前に登録されていました。
原因はClaudeを含むLLMの基本仕様です。LLMは現在日時を知りません。「明日」と言われても、今日が何月何日かを知らないので、訓練データに基づいた古い日付で推定してしまいます。
Dify には標準で「現在時刻を返すシステム変数」がありません。GitHub Issueでも機能要望として挙がっていますが、正式には実装されていない状態です。公式の Time プラグインを追加すれば解決できますが、マーケットプレイスで time で検索しても目的のものに辿り着きにくいケースもあります(提供元の見分けが必要です)。
応急処置として、システムプロンプトの冒頭に現在日時を固定で記述することで、日付ズレは解消しました。ただし、これは毎日プロンプトを更新しないと古くなる、ワークアラウンドに過ぎません。
## 現在日時(固定・毎日更新が必要)
今日は 2026年4月20日(月曜日) です。
### 日付の基準
- 「今日」= 2026-04-20
- 「明日」= 2026-04-21(火)
- 「来週月曜」= 2026-04-27
### 絶対に守るべきルール
- カレンダーAPIに渡す日付は、必ず 2026年 として扱ってください
- 2025年以前の年を使うことは絶対に禁止ですこの対策で、Debug & Preview では完璧に動作するようになりました。秘書くんの中核機能は全て検証済み、という状態になりました。
ここで本当の壁にぶつかる: LINEからは応答が来ない
Dify内でのテストが完璧だったので、意気揚々とLINEから話しかけました。
今日の予定は?返事が来ません。10分待っても来ません。
設定は全部確認しました。Webhook URL、Channel Secret、Channel Access Token、Webhookの利用をオン、LINE Official Account Managerの応答設定を「Bot」モードに変更、Webhook検証も成功しています。全部緑のチェックがついています。
それでもLINEは沈黙していました。
切り分けの過程
ログを見ると、異常な状況が見えてきました。
- LINE側のWebhook配信エラー: ゼロ件(LINEは送信成功と認識)
- Dify側の秘書くんアプリのログ: 空(メッセージが届いていない)
- LINE DevelopersのWebhook検証: Success
- Line BotプラグインのService Status: SERVICE OK
LINEとDifyの間の通信は成立しているのに、秘書くんアプリにメッセージが渡っていない。この状況がしばらく理解できませんでした。
原因判明: Line BotプラグインがAgentタイプと非互換
切り分けのため、Chatbotタイプの最小構成アプリを作って、Line Bot プラグインのエンドポイントをそれに紐付け直しました。
「こんにちは」
→ 「こんにちは!お手伝いできることはありますか?」動きました。LINEからChatbotには応答が返ってきます。
つまり、Line Bot プラグインは Chatbot タイプには対応しますが、Agent タイプには対応していないのです。これが根本原因でした。
エラーも警告も出ません。Line Botプラグインは LINE からのリクエストに対して一応 HTTP 200 を返します(そのため LINE 側は成功扱いになります)。しかし、バックエンドで Agent アプリに接続する部分で失敗し、メッセージは闇へ消えていきます。沈黙する故障で、これが一番たちが悪いパターンです。
Line Bot プラグインは誰が作ったのか
ここで初めて、使っているプラグインの提供元を確認しました。
- Google Calendar:
langgenius(Dify公式) - Anthropic Claude:
langgenius(Dify公式) - Line Bot:
kevintsai(コミュニティ)
Line Botプラグインはコミュニティ製のサードパーティプラグインでした。これが最初から分かっていれば、構成を変えていたと思います。
Difyマーケットプレイスの構造
Dify v1.0.0(2025年2月)で、モデルとツールが全てプラグイン化されました。これはAI開発プラットフォームとしては進んだ設計ですが、副作用としてDifyの機能はプラグインの品質に依存するようになりました。
マーケットプレイスは3層構造になっています。
第1層: Dify公式プラグイン(提供元: langgenius)
langgeniusが提供する公式プラグインのリポジトリで、Dify公式チームが維持管理と更新を行います。Dify本体のバージョンアップと同期して更新されるので、比較的安定しています。Google Calendar、Anthropic Claude、OpenAI、主要なLLMプロバイダー、ナレッジベース連携などが該当します。
第2層: パートナー企業製プラグイン
Microsoft、Google、Slack といった大手パートナーが提供するプラグインです。数はまだ少ないですが、品質は高い傾向にあります。
第3層: コミュニティ製プラグイン
個人開発者や小規模チームが作成したプラグインです。品質にバラつきがあり、Dify本体のアップデートに追従していないケースがあります。Line Bot、Teams、WhatsApp、特定業務向けの連携プラグインなどは、この層に該当することが多いです。
Marketplaceのプラグインは全てコードレビューを経て、隔離環境で実行されるとはいえ、レビューはセキュリティ中心で、全アプリタイプとの互換性や機能の完全性まで保証されているわけではありません。今回のLine BotプラグインのAgent非互換はレビューで拾われなかったものと思われます。
どのプラグインに不具合が多いか
GitHub Issuesを追うと、以下のカテゴリーで問題報告が多く見られます。
IMサービス連携プラグイン(LINE、Slack、Discord、WhatsApp、Teams等): 大半がコミュニティ製です。Dify本体のアップデート追従が遅れやすく、アプリタイプ非互換や認証周りの問題が頻発しています。
マイナーLLMモデル(Tongyi、各種中国系モデル等): バージョン不一致問題が多く見られます。
Agent Strategy系プラグイン: v1.0.0の大改修で仕様が変わった過渡期で、古い資産との非互換が残っています。
Dify単体でプロダクションアプリを作る場合、第1層(公式プラグイン)だけで構成できるユースケースに絞るのが安全策です。LLM呼び出し、RAG、基本的なAPI連携などは公式で揃っています。
n8n と Dify、どちらが向いているか
外部サービス連携の観点で比較すると、以下の表のようになります。
| 観点 | n8n | Dify |
|---|---|---|
| 歴史 | 2019年〜(約7年) | 2023年〜(約3年) |
| LINE Bot | 公式ノード | サードパーティ製のみ |
| Microsoft Teams | 公式ノード | サードパーティ製 |
| Slack | 公式ノード | 一部公式+コミュニティ |
| Google Calendar | 公式ノード | 公式プラグイン |
| AIエージェント管理UI | 基本機能のみ | 高度なUI |
| RAG | 外部連携が必要 | ビルトイン |
| Function Calling可視化 | 限定的 | 強力 |
LINEやTeamsのようなIMサービスとの連携では、n8nの公式ノードを使うのが圧倒的に安定します。n8nは7年の実績があり、LINE公式もMicrosoft公式もノードを提供しています。枯れた技術で、接続エラーの原因も調査しやすいです。
一方、AIエージェントのプロンプト管理、テストプレイグラウンド、RAG構築、Function Callingの可視化はDifyが得意です。Chatflowのビジュアルエディターや、Agent ノードの実行ログはn8nより見やすいと感じます。
結論として、両者は競合というより補完関係にあります。以下のような構成が現実解になるかと思います。
LINE / Teams / Slack などのIM
↓
n8n (公式ノードでIMと接続)
↓ HTTP Request
Dify Service API (秘書くんAgent)
↓ Function Calling
各種外部サービス(Difyプラグイン or n8n側で処理)
↓
n8n → IM へ返信DifyはAIの中核、n8nは外部接続のハブ、という責務分離です。今回のAgent非互換のような罠も、この構成なら回避できます。n8nから叩くのはDifyのService APIで、これは常に公式APIなのでアプリタイプに関係なく動きます。
Dify単体で完結させたかった場合の代替案
どうしてもDifyだけで構築したい場合、以下の選択肢があります。ただし、どれも弱点があるので現状ではおすすめしづらいです。
案1: Chatbotタイプ + Tools で運用 Line Bot プラグインは Chatbot タイプには対応します。ただし Chatbot Basic は Tools を持たないので、Claude の Function Calling で外部サービスを呼ぶような使い方はできません。単純な対話型ボットなら可能です。
案2: Chatflow + Agent ノード構成 Chatflow タイプなら Agent ノードを配置できて、Tools も使えます。ただし自分の環境では、Chatflow 経由でも Line Bot プラグインが応答しない現象が再現しました。もう少し検証が必要です。
案3: uezo/linedify ライブラリを使う uezo/linedify は FastAPI ベースのLINE ↔ Dify 統合ライブラリです。自前でFastAPIサーバーを立てて、そこからDify Service APIを叩く構成になります。Dify単体ではなくなるので、コンセプト上のメリットが薄れてしまいます。
案4: Dify公式のLINE対応を待つ Difyは急速に進化しているので、将来的に公式のLINEプラグインがリリースされる可能性はあります。その時まで待つという選択肢もあります。
いずれにしても、2026年4月現在、本番品質のLINE連携をDify単体で実現するのは難易度が高いというのが結論です。
今回得られた知見のまとめ
プロダクト開発の教訓として残しておきます。
プラグインの提供元は最初に確認する マーケットプレイスのプラグインを使う前に、必ず author をチェックしましょう。langgenius なら公式、それ以外はコミュニティ製です。コミュニティ製を使う場合は、GitHubのIssuesを見て最近のメンテナンス状況を確認するのがおすすめです。
Dify単体で完結できる範囲は限定的 LLMの呼び出し、Function Calling、RAG、基本的なツール呼び出しまでは Dify 単体で完結します。しかし、IMサービス連携や特殊な外部連携は n8n や専用ライブラリを挟むのが現実解です。
「沈黙する故障」を想定してテストする 今回のLine BotプラグインのAgent非互換は、エラーもログも出さずに沈黙します。Chatbot タイプで動作確認 → Agent タイプに切り替えて動作確認のように、アプリタイプを変えて検証するのが確実です。
日付は動的に渡す LLMは現在日時を知りません。システムプロンプトに固定で書くのは応急処置で、本番では Time プラグインを追加するか、Dify外で日時を解決してからプロンプトに埋め込む構成にしたいところです。
削除機能は慎重に カレンダー、予約システム、CRMなど、外部サービスと連動するデータを削除する機能は、AIに持たせるとユーザーに誤った安心感を与えてしまいます。読み取りと追加だけに絞る設計判断は、結果的に正しかったと思います。
次回: n8n経由での再実装
この失敗を踏まえて、次は n8n を LINE と Dify の間に挟む構成で秘書くんを再実装する予定です。既に動作実績のある n8n のLINE連携資産と、Dify の Agent 機能を組み合わせれば、今度こそ本番稼働まで持っていけるはずです。
同じ轍を踏む方が一人でも減ることを願って、この失敗記録を公開しておきます。
コメント