第14章 トラブルシューティング

この章では、Difyでアプリを作る・試す・公開して使う、それぞれの段階で起きるつまずきの確認と対処をまとめます。ここまでの各章で「エラーの対処は第14章」と案内した症状の受け皿になる章です。各項は「症状 → 原因 → 確認手順 → 対処」の形で書きます。

この章の使い方は次のとおりです。

• まず14-1冒頭の「エラー調査の基本手順」で、どの段階のつまずきかを特定します。
• そのうえで、14-1の段階別の表から症状を探します。動くが遅い場合は14-2、公開後の運用の疑問は14-3を見ます。

この章で扱わない内容は、次の場所で説明しています。

• 答えの内容が資料と合わない・根拠を拾えないなど、ナレッジ（保管庫）の登録・検索の設定は、第5章で説明しています。
• どのノードで止まったかを特定する切り分けの手順そのものは、第7章7-5「うまく動かないときの確認の順番」で説明しています。
• 各ノードの設定項目の意味は第10章、外部サービスとの接続は第11章で説明しています。

エラーの文言・画面の名称・配置は、バージョンや環境により本書の記載と異なることがあります（序章「本書の確認環境」参照）。本章に書くエラーの文言は要旨であり、画面にこのとおり表示されるとは限りません。

14-1. よくあるエラーと対処

エラー調査の基本手順（どの段階で起きたか → どこを見るか）

エラーが出たら、やみくもに設定を変える前に、次の2つを特定します。

1. どの段階で起きたか：ノードを組んでいる最中（作成時）か、テスト実行・デバッグとプレビューで試したとき（テスト実行時）か、公開したあと（公開後）か。
2. どこを見るか：段階ごとに、確認する場所が決まっています。

あわせて、エラーの文言（またはその要旨）を控えておきます。文言はバージョンにより変わるため、本章の表では「〜という趣旨」で探してください。

テスト実行時に「どのノードで止まったか → 入ってきた値と出した値のどちらがおかしいか」をさかのぼる手順は、第7章7-5のとおりです。本章は、その先の「エラーの種類別に何を直すか」を扱います。

作成時のつまずき

ノードを組んでいる最中のつまずきです。多くは操作か設定の確認で解決します。

同じインポートエラーが繰り返し出るとき（第12章12-3からの続き）は、次の順で切り分けます（一般的な確認手順です）。

1. 第12章12-3の表の対処（ファイルの先頭・末尾の確認、生成AIへの修正依頼）を一巡します。
2. それでも取り込めない場合、第12章12-2の依頼文の例のような小さな構成のDSLファイルを別に作り、取り込めるかを試します。
3. 小さなファイルが取り込める場合は、元のファイル固有の問題です。修正依頼を繰り返すより、依頼文を見直してDSLファイルを作り直します（第12章12-4の目安のとおり）。
4. 小さなファイルも取り込めない場合は、環境・バージョン側の問題の可能性があります。情報担当部署に相談するか、公式ドキュメントの最新の記載を確認します。

テスト実行時のエラー

第7章7-5の手順でエラーになったノードを特定したら、エラーの原因を「設定の誤り（自分で直せる）」と「外部サービス・環境側（時間を置く、または確認先に連絡する）」に分けて確認します。公式ドキュメントには、ノードの種類ごとに起きるエラーの種類の一覧があり、本項の表はその代表例です。

設定の誤りが原因のエラー（自分で直せるもの）

外部サービス・環境側が原因のエラー

エラーで流れ全体を止めない設定（エラー処理）

LLM・HTTPリクエスト・コード・ツールの4種類のノードでは、失敗したときの動きを エラー処理（失敗時にどう続けるかをノードに決めておく設定）で選べます。第11章11-3で触れた「失敗したら別の流れに進める」設定がこれです。

• 失敗分岐の先では、エラーの種類と内容が入った変数（error_type・error_message）を使えます。通知文への差し込みや、記録に使えます。
• イテレーションの繰り返し中のエラーは、「終了」「エラー時継続」「失敗結果を除去」の3つから選びます（第10章10-3）。
• 失敗時の再試行を使う場合は、回数の上限と間隔を必ず設定します（第11章11-3のとおり）。

エラー処理は「止めない」ための設定であり、原因が直るわけではありません。失敗分岐に流れた記録をログ（第9章9-4）で確認し、原因側も直してください。

公開後のエラー

APIのエラーは、応答に「コード・メッセージ・状態」の3項目が含まれて返ります。ステータスコード別の意味と対処は次のとおりです。

設定の誤り（400・401・404）は、再試行しても直りません。呼び出し側の設定を直してから試します。

14-2. 動きが遅いときの見直しどころ

「遅い」もエラーと同じ進め方で、まず「どこで時間がかかっているか」を特定し、その場所だけを見直します。当てずっぽうに設定を変えないでください。なお、本書は「この設定にすれば速くなる」という一律の値は書きません。効果は処理の内容と環境によるため、変更は1つずつ行い、変更の前後で所要時間を比べて確かめます。

確認の順番

1. テスト実行のトレーシングで、ノードごとの所要時間を見ます（第7章7-5）。どのノードがどの順に動いて何秒かかったかが表示されるため、一番時間のかかっているノードを特定できます。
2. 公開後は、ログで応答時間と処理の過程を見ます（第9章9-4）。特定の使われ方だけ遅いのか、全体が遅いのかもここで分かります。
3. 特定したノードに応じて、次の表の順に見直します。

ノード別の見直しどころ

処理は同じでも、待たされ感を減らす

処理そのものの時間は変わりませんが、結果の見え方を変えることで、利用者が待たされていると感じる時間を減らせます。

• API連携では、応答の返り方をストリーミング（途中経過を少しずつ返す方式）にできます（第11章11-4）。
• チャットフローでは、回答ノードを流れの途中に複数置くと、できたものから順次表示されます（第10章10-2）。

14-3. 運用でつまずきやすい点のQ&A

公開したあと、日々使う中でよく出る疑問です。

Q1. 公開したあとに直したのに、利用者の画面が変わらない

14-1「公開後のエラー」の1つ目のとおりです。編集は、公開の操作をするまで公開中のアプリに反映されません。直したら「編集 → テスト実行で確認 → 公開」までを1セットで行う運用にしてください。

Q2. スケジュールトリガーを設定したのに、時刻になっても動かない

• 症状：時刻・間隔を設定したのに、ワークフローが自動で実行されない。
• 原因：設定の誤りのほか、「公開していない（編集内容は公開の操作をするまで反映されません。14-1）」「トリガーが無効になっている（無効のトリガーはワークフローを実行しません）」が典型です。
• 確認手順：
  1. アプリの種類がワークフローであること、スケジュールトリガーが1つだけで、時刻・間隔が正しいことを確認します（第2章2-8）。
  2. アプリを公開済みであることを確認します。
  3. トリガーが有効になっていることを確認します。
  4. 実際に実行されたかどうかを、ログの一覧（第9章9-4。「トリガー方法」の列でどこから実行されたかが分かります）で確認します。
  5. 置けるトリガーの数や月あたりの実行回数は契約プランにより異なるため、上限に達していないかを管理者に確認します。
• 対処：未公開なら公開し、無効なら有効にします。上限の問題なら、実行の頻度か契約を見直します。

Q3. どれくらい使われているかを知りたい

利用件数・利用者数・トークン使用量の集計はモニタリング、1件ずつの中身はログで確認します（第9章9-4・9-5）。

Q4. 複数人で同じアプリを編集してよいか

• 編集できるのは、役割がエディター以上のメンバーです。通常メンバーは公開済みアプリの利用のみできます。
• 公式ドキュメントでは、複数人での同時編集と、キャンバス上のコメント機能が説明されています。同じ箇所を同時に変えた場合は、最後の編集が反映されるとされています。使える機能の範囲は環境・バージョンにより異なります。
• 上書きし合う事故を防ぐため、同じアプリを同時に直さない（直す担当と時間を決めて声をかけ合う）運用をおすすめします（一般的な確認事項）。大きく変える前には、次のQ5の控えを取ってください。

Q5. 誤って壊した・消したとき、元に戻せるか

• 編集の直後なら、元に戻す（Ctrl＋Z）で戻せます（第7章7-4）。
• それ以外は、事前にエクスポートしたDSLファイルの控えがあれば、取り込んで変更前の構成に戻せます（第12章12-5）。公開は現在の設定での置き換えのため、公開の前と、大きく変える前にエクスポートしておく習慣が有効です。

Q6. 入力したデータや記録は、どこに残るか・いつまで残るか

• 利用者が入力した文とアプリの答えは、ログにそのまま残ります（第9章9-4）。閲覧・共有は所属の個人情報の取り扱いルールに従ってください。
• クラウド版では、アプリと記録はDifyの提供元が運用するサーバー（庁外）に保存されます。セルフホスト版では、自組織で用意したサーバーに保存されます。
• 保存される場所の地域や保存期間の定めは、本書の確認日時点の公式ドキュメントでは確認できませんでした。契約・利用規約の確認が必要な場合は、情報担当部署を通じて提供元に確認してください。
• どのデータを入れてよいかは、お使いの環境のルールに従ってください（序章0-5）。個人情報や外部に出せないデータを質問・入力に書かない運用が基本です。

まとめ：つまずいたときの見方

1. どの段階で起きたかを特定する（作成時／テスト実行時／公開後）。
2. 段階ごとの見る場所を開く（ノードの設定欄／「最後の実行」／ログ）。
3. 本章の表で症状を探し、対処する。設定の誤りは直し、外部・環境側は時間を置くか確認先に連絡する。
4. 遅いときは、トレーシングで場所を特定してから1つずつ見直す（14-2）。
5. 本章で直らない場合は、章末の出典にある公式ドキュメントの最新の記載を確認するか、情報担当部署に相談する。

出典一覧

本章の記述の根拠です（いずれも確認日：2026-08-14）。

前の章：第13章 チュートリアル