n8n＋Dify＋SQLiteで模擬ジョブを接続する——結果を後から受け取るAPIと、二重受付を防ぐ仕組みの概念実証

工程図の矢印だけでは判断できない

新しい動画制作の仕組みを検討する担当者が、依頼の受付から企画、制作までをつなぐ工程図を見せられたとします。画面にはサービス名と矢印がありますが、何を入力し、どの結果を取り出せたかは書かれていません。「接続できた」という報告を、本番の制作を任せられる根拠にしてよいのでしょうか。この疑問には、実際に通った処理の範囲を分けて答える必要があります。

この概念実証では、工程を視覚的に組むn8nと、処理を組み立てるDifyを実際に動かして接続しました。依頼を保存し、あとで状態を取り出す処理も含みます。ただし、生成AIのモデルを呼び出した回数も、本番の制作を実行した回数も、いずれもゼロです。確認できたのは模擬連携の経路で、企画や動画そのものの生成品質は別の検証になります。

説明には「製品紹介の動画を企画したい」という一件を使います。題名と骨子を渡し、整えられた模擬企画を受け取り、受付と状態の照会へ進む流れです。実サービスを通るという事実は、依頼が届く経路の検査に役立ちます。一方、題名を整えた結果を見ても、説明が正しい映像になるかは分かりません。この例を通して、接続の成功から読み取れることを具体化します。

二つのサービスと保存する処理の役割

n8nは、依頼を受け取ってDifyへ企画を求め、その結果を検査して次の受付へ渡します。Dify側では、入力を受け取り、通常のプログラム処理で模擬企画を用意し、結果を返します。企画を考えるAIが裏で動いている構成ではありません。AIを扱えるサービスを使ったことと、その工程でAIが動いたことを分けると、今回何の品質を検査しているかが明確になります。

受付の後で状態を答えるために、仕事を保存する専用の接続処理を置いています。保存はSQLiteというデータベースで行い、受け付けた内容と仕事の状態を結び付けます。n8nの実行履歴だけへ頼る方法では、利用者が同じ依頼を送り直した時の受付を統一して扱いにくくなります。工程を動かす役割と、仕事を継続して照会できるよう残す役割を分けた構成です。

仕様を書き起こして管理する仕組み（OpenSpec）と、検証・差し戻し・受入の流れを組む仕組み（LangGraph）も使っています。これらは企画内容を生成する担当ではなく、何を実装し何を確認したかを管理する側です。既存の動画制作基盤をこの試験のために作り直してはいません。模擬連携を新しい部分に限定したことで、接続の検査が本番のモデルや制作環境を勝手に動かさない境界を保っています。

企画が返った後に、内容を受け入れる

確認したn8nの流れは、受付、企画の要求、企画結果の確認、模擬仕事の受付、待機、状態の観測、結果の返却という七つの工程です。説明用の依頼は題名と骨子を含み、Difyから対象と題名、骨子、模擬処理である指定を受け取ります。n8nはその返答をそのまま受付へ流さず、期待する企画として扱えるかを一度確認します。

この関門が必要なのは、通信が成功しても仕事として成功しているとは限らないからです。相手が応答を返し、その中身に「企画を用意できなかった」と記されている場合があります。通信の成功だけを見れば、その失敗を後段へ通してしまいます。固定試験では、Difyが成功の通信応答で意味上の失敗を返した場合にも止める条件を扱っています。応答があることと、必要な企画があることは別です。

代案として、後段で不足を補って進む方法も考えられますが、それでは企画の失敗がどこで起きたか見えにくくなります。この試験では扱う入力を限定し、企画を受け入れてから模擬仕事へ進む方針です。本番で企画の質を評価するなら、必要な場面や根拠など別の受入条件が要ります。模擬企画の形式を確認した結果を、そのまま創作物の良さの評価へ広げることはできません。

受付の入口と状態照会の入口を使い分ける

製品紹介の企画を提出するのは受付用の入口です。ここでは認証、送られた内容の大きさ、対象、入力の項目を確認します。受理した時に返すのは仕事を受け付けたという応答で、完成した動画ではありません。返答にある仕事の番号を残しておけば、状態照会の入口からその仕事を探せます。受付と完成を同じ返答として扱わないため、時間のかかる処理へ拡張する余地があります。

入力は対象と題名、骨子、模擬処理の指定、説明用の失敗指定などに限定されています。例えば題名は一文字以上二千文字以下、骨子は八千文字以下という範囲を見ます。扱わない項目が混ざったら、黙って捨てて受け付けるのではなく拒否します。依頼者が「この指定も使われた」と思う食い違いを避ける判断です。この入口には、自由に本番制作を始める役割は実装されていません。

状態照会も認証で保護され、保存済みの仕事があるかを確認して答えます。稼働状況を確認する入口が公開されていても、仕事の内容を誰でも取り出せるという意味ではありません。また、仕事が見つからない応答は制作失敗とは違います。番号を取り違えた可能性もあるため、依頼者は受付時に返った情報と照らし合わせます。接続を実装する際は、入口ごとの認証と入力条件、受付番号、エラー応答を通信仕様で確認します。日本語の状態名だけから通信の契約を決めないことが必要です。

受付と状態照会はHTTP APIとして分けています。新しい依頼を受理すると202を返し、同じ依頼の目印（冪等キー）で内容の異なる依頼が来た場合は、409（競合）を返します。SQLiteでは対象と冪等キーの組を一意にし、入力を並び順のそろったJSONへ正規化して比較します。同じ依頼を既存ジョブへ戻す契約と、完成結果を後から照会する契約を別に定める構成です。

同じ依頼の再送と、内容を変えた依頼

受付の返答を取り損ねた時、同じ依頼を送り直して別の仕事を作ると、本番なら生成が重なる恐れがあります。そのため対象ごとに重複防止の目印を持たせ、同じ目印を受け取った時は保存済みの入力を比較します。対象も内容も同じなら、既存の仕事へ戻します。入力の項目の並び順をそろえて比較するので、順番だけを変えた同じ内容を別の依頼と扱わない構成です。

例えば、担当者が最初に「基本操作の製品紹介」を受け付け、返事がないため同じ題名と骨子を再送したとします。この場合は新しい仕事を作らず前の受付を返します。次に担当者が骨子へ「初回の同期操作」を追加し、同じ目印で提出すると、内容が異なる競合として拒否します。後から来た文章で前の受付を上書きすると、何を受け付けたかの意味が変わるためです。競合を受け取った担当者は、同じ内容を連打するより、前の受付内容を見直します。誤って新しい骨子を混ぜたなら元の依頼で回復し、本当に改訂したいなら別の依頼として提出する判断になります。拒否を分かりやすく返すことには、未対応の内容を黙って受け付けないという価値もあります。

変更版を別の依頼として作りたいなら、その意図を区別した受付にします。元の依頼を回復したいのか、内容を更新して新しい仕事にしたいのかを、送る側が決めます。異なる対象では同じ目印でも別の仕事として扱いますが、対象を変えて拒否を回避する使い方は適切ではありません。今回確かめたのは保存先の重複受付防止であり、将来接続する課金や投稿の相手でも一回しか実行されないという保証ではありません。

進捗が百でも、成功とは限らない

動作確認用の仮の依頼は、受付からの経過時間に応じて待機、処理中、完了または失敗へ変わります。この処理では、短い時間の境界で進捗を零、五十、百と返します。これは接続先が途中状態と終端状態を扱えるかを見るための仕組みです。映像の半分ができたから五十になるわけではなく、背後で画像や音声を作る担当が動いているわけでもありません。

説明用の失敗を指定した依頼も、終端へ達すると進捗は百になります。画面が数値だけを読んで「完成」と表示すれば、失敗を成功へ読み替えてしまいます。状態が完了なら結果を、失敗ならエラーを読む必要があります。また、照会の通信に失敗したことと、照会できた仕事が失敗状態であることも分けます。前者では結果がまだ分からず、後者では処理が終わって失敗したと分かっています。

n8nが挟む短い待機は、この模擬処理の観測に合うものです。本番の制作で数分かかる場合に、同じ待機後の一回の照会だけで結果を確定できるとは限りません。照会する間隔、待つ期限、取消し、通信が途切れた時の回復を別に設計します。期限を超えたからといって、元の制作が止まったとは判断できません。副作用を伴う処理を再送する前に、既存の仕事の結果を確かめる経路が必要です。

実サービス記録と固定試験が示す範囲

2026年10月5日の確認では、模擬の依頼が完了し、同じ依頼の重複受付が抑えられ、n8nとDifyの実行履歴も成功しています。これは、サービス名を記した工程図だけでなく、登録した工程を依頼が通った記録です。対象は当時の入力と登録済み工程です。現時点の稼働を判断するには、同じ経路を改めて取得・実行して確認する必要があります。

固定試験は、正常な一件だけでは見えない分岐を検査します。認証がない場合、許されない入力、同じ目印で異なる入力、対象間の分離、保存する処理を再起動した後の結果保持などが含まれます。Difyの意味上の失敗を後段へ通さない条件も対象です。実サービス記録と固定試験は役割が違い、一回の実行成功から全失敗条件の確認を推定したり、試験結果だけでサービス登録を済ませたと判断したりしません。再起動後の保持を確かめる時も、稼働確認だけでは足りません。前に受け付けた仕事を照会し、完了した結果だけでなく失敗した理由も取り出せるかを見ます。状態が消えて新しい受付として作り直されるなら、利用者は復旧のつもりで別の仕事を始めてしまいます。保存の継続性は、接続の途中で途切れた一件を扱うための検査です。

残っているのは、生成AIの企画品質、画像や音声や動画の品質、費用、本番負荷、長時間の運用、既存制作機能との接続です。動画を実際に作る処理は今回の模擬仕事の中にありません。本番へ進むなら、使うモデルと入力、企画を受け入れる条件を定め、その後に制作結果を評価します。接続の検査で確かめた土台を使いながら、検査対象を段階ごとに増やすのが次の判断になります。

見学できる工程図と実行の入口を分ける

外部から工程を見られるページでは、登録された工程の担当と接続を閲覧用に示します。この工程図は閲覧用で、編集や実行の操作は含みません。設定、認証情報、実行の入出力なども閲覧ページへ持ち出しません。ログイン不要の見学ページを用意することと、管理画面の保護を外すことは異なります。どの工程を通した検証かを共有するには、秘密を出さずに接続の対応を示せます。

自分の導入で同じ考え方を試すなら、本番で使う費用を伴う操作を外し、受付と照会だけを先に通せるかを調べます。正常な依頼、同じ内容の再送、内容を変えた再送を一組にし、何件の受付が残るべきかを先に決めます。完了と失敗をそれぞれ返す例で、画面が数値だけから成功を判断しないかも見ます。試す内容が限定されていれば、合格と残る課題の境界を説明しやすくなります。

採用を決める時は、模擬処理の結果と本番で求める成果を隣に置き、まだ接続していない担当を洗い出します。企画が届くことを確認できたなら、その次は根拠を持つ企画ができるか、動画が出るなら仕様と一致するかを確かめます。この確認では、品質や削減時間は測っていません。接続試験を過小評価する必要もありませんが、結果が証明する範囲を明示して次の検証へ使うことが大切です。