Difyの変数集約器で型エラー｜分岐と出力項目の確認

Difyの変数集約器で型が合わないときは、一回の実行で選ばれる経路が一つか、同じ集約グループの型が揃っているか、下流で使う項目が両方の経路にあるかを分けて調べます。エラーを消すためにすべて文字列へ変えると、その後の判定に使いたい真偽値や項目を扱いにくくなることがあります。

本稿は、If/Elseで分岐する小さいワークフローを作り、分岐後を一つの回答や確認処理へつなぎたい人向けです。編集部作成の架空の受付データを使います。Dify実機でこのフローを実行した結果ではなく、現行公式の説明とローカルPythonでの出力検収を組み合わせた教材です。

確認日：2026年10月13日。Variable Aggregatorの公式資料は2026年6月6日更新、Codeノードの資料は7月2日更新の表示を確認しました。ローカル教材はPython 3.12.14で参照実行し、Difyの公開APIや外部サービスへデータは送っていません。

型エラーの前に、分岐の実行と共通の出力を整理する

変数集約器は、一度に一つだけ動く分岐の合流に使う

本稿の受付例には、autoとmanualという二つの経路があります。一回の受付でどちらか一方を選び、その出力を共通の確認処理へ渡す設計です。autoは受付を確認する本文、manualは人の確認を待つ本文を返します。二つの本文を一回の受付で両方生成して結合する設計ではありません。

現行の公式資料は、変数集約器をIf/ElseやQuestion Classifierなどの排他的な分岐に使うと説明しています。同じ集約グループの変数は同じデータ型を持つ必要があり、実行された分岐の出力を下流の共通処理へ渡します。設定画面の項目や変数名は、利用環境で確認してください。

最初に書くメモは、「一回の処理で何経路を動かすか」です。図に矢印が二本あることと、両方が実行されることは同じではありません。条件でどちらかを選ぶのか、二つを並列に実行するのかを説明できると、合流に必要な処理を選びやすくなります。

受付IDを一つ決めて、選ぶ条件、選ばれる経路、経路が返す項目、最後の確認処理を並べます。本稿ならQ01はauto、Q02はmanualという別々の試験です。Q01とQ02が同時に一つの出力になったわけではありません。この単位を曖昧にすると、ログと期待値の対応が崩れます。

エラーの原因を調べるときも、最初から全体を作り替える必要はありません。現在の図へ、どの経路を選んだかを書き足し、その一回の実行に必要な入力と出力だけを取り出します。利用者の実データを含まない小さい例にすれば、型と項目を分けて説明しやすくなります。

条件そのものが間違っていると感じる場合は、DifyのIf/Elseと条件境界の確認から選択経路を確かめます。本稿は、選んだ後の出力を合流させる段階を扱います。分岐が正しく選べたことと、下流が必要なデータを受け取れたことを別々に確認してください。

並列の結果をまとめたい場合は、入力を明示した別処理を考える

現行公式は、変数集約器が並列の分岐出力を結合するものではないと明記しています。複数の経路を動かし、それぞれの結果を一つの配列や文章へまとめたい場合は、CodeやTemplateなどを使う設計として区別します。古い解説や別の構成例を読むときも、現在の仕様と実行経路を照合します。

例えば、二つの資料を別々の処理で調べ、両方の結果を比較する仕事では、一回の実行で二つの結果を必要とします。本稿の「どちらか一方の受付経路」とは必要な出力数が違います。同じ合流の見た目だから同じノードでよい、とは判断しません。

並列結果の結合では、順序も確認点になります。結果Aと結果Bを単に並べるだけで、元の入力へ戻れるのか、片方が欠けたときにどうするのかを決めます。本稿のローカル検収は二経路が有効なら止めるため、並列処理の結合器として流用できません。

Templateで文章を作る場合も、入力が存在することと、表示したい内容が入っていることを分けます。空の本文を黙って表示しない、文字列のfalseを「確認不要」と見なさないなど、元の意味が失われない条件を置きます。表示上の空欄は、Jinja2テンプレートの空値確認で整理できます。

反復処理の配列をまとめる話も別です。同じ入力リストを何件処理したかを知りたい人は、DifyのIterationと出力配列の件数確認を参照してください。一方だけを選ぶ分岐、両方を使う並列、入力件数に応じて動く反復を分けて考えると、期待する結果を数えられます。

同じ型とは、同じ項目が入っていることではない

autoもmanualもObjectを返していても、片方にreplyがなく、もう片方にあるなら、下流がreplyを使うときに困ります。型を揃えた段階は確認の一部です。項目名、項目の中の型、意味、未記録を認める条件まで揃える必要があります。

この教材の共通項目は、ticket_id、route、reply、review_requiredの四つです。受付ID、選ばれた経路、返信本文、人の確認が必要かという真偽値をそれぞれ持ちます。Difyがこの四項目を標準で用意するわけではありません。本稿の編集部が、確認のために決めた出力の約束です。

どちらの経路にも同じ項目を持たせる理由は、合流後の処理を一回で説明するためです。下流では「replyを表示し、review_requiredがtrueなら人の確認へ戻す」と考えられます。ただし、本稿は実際の送信や業務システムへの登録を実行しません。教材のreplyも架空の短い本文です。

項目の一覧を紙や表へ書くだけでも、エラーを切り分けられます。片方がmessage、もう片方がreplyという名前なら、下流の参照先を同じにする設計が必要です。意味の異なる項目まで同じ名前へ変えればよい、ということではありません。返信本文と内部メモは別の情報です。

一つの項目の中に複数の意味を混ぜないことも大切です。review_requiredに「確認待ち」という文字列を入れる経路と、trueを入れる経路を用意すると、判定処理が複雑になります。確認理由の文字列が必要なら、真偽値と別の項目として設計する方が判断しやすくなります。

JSONの文字列とObject、falseと文字列のfalseを分ける

見た目が波括弧で囲まれていても、値が文字列ならObjectとは別です。例えばJSON形式を文字列として出力した経路と、項目を持つObjectを出力した経路を、同じ型だと考えないでください。画面で本文を見たときの形と、変数の型を分けて調べます。

JSON文字列をObjectへ変える設計が必要なら、その処理をどこで行うかを明示します。読み取り可能なJSONか、必要な項目があるか、値の型が期待どおりかを順に確認します。文字列を解析できることだけで、受付IDや返信内容が適切だと確認できたわけではありません。

HTTPから返った内容を使う人は、DifyのHTTP RequestとJSONの型確認で本文と型の違いを先に点検できます。本稿のコードでは、JSON文字列を入力した例を自動変換せず保留します。型の境界を見えるようにするための教材上の選択です。

Booleanのfalseも、文字列のfalseとは異なります。本稿のauto経路には、確認不要を示すBooleanのfalseを入れます。falseだから値がないとみなすと、正常な出力を落としかねません。そのためローカル検収では、経路が未実行である印のNoneと、Objectの中のfalseを別に扱います。

このNoneの扱いは、ローカル教材で決めた表現です。Difyが未実行の経路を画面や実行結果にどのように表示するかまで、教材のPython辞書から断定しません。実機では、選択した経路と出力を確認し、その記録を元に教材へ写すことが必要です。

空のObjectも、値がない経路と同じではありません。辞書が空でも経路の出力として与えた以上、本稿では有効な経路の数に含め、その後の項目検査で保留します。存在の確認、型の確認、内容の確認を順に行うことが、原因を分かりやすくする狙いです。

複数グループを使うなら、出力先もグループごとに点検する

公式のAggregation Groupは、変数の組を複数に分け、それぞれ独立した出力を用意する設定です。一つのグループの中は同じ型へ揃えます。型の違う値を一つのグループへ混ぜて、その設定だけで共通の項目へ作り直すものではありません。

例えば、返信本文のグループと、確認結果のObjectのグループを分ける設計が考えられます。ただし、本稿の受付例は四項目を一つのObjectに入れる方式です。二つの方式を途中で混ぜると、本文はあるが受付IDが別経路のもの、といった組み合わせを見落としやすくなります。

グループを増やす前に、合流後で何を使うかを書きます。本文だけでよいのか、受付IDと真偽値も必要なのかが決まると、別グループを作る理由を説明できます。単にエラーの出る値を別へ追い出すためにグループを増やすと、出力の対応が不明確になります。

出力変数名は、実際に表示される選択肢を使って確認します。資料や他人のコードにあるgroup1などの名前を、利用中の環境の出力名と確認せずに入力しないでください。この教材は、特定の画面名や参照構文を全環境で再現した設定手順ではありません。

項目が欠ける原因が、入力資料の検索結果にあることも考えられます。ただし、合流したことから資料の取得や回答の根拠まで確認済みとは言えません。検索の空結果は、Difyの知識検索と空の結果の確認へ戻って調べます。各工程が返した事実を、下流へまとめた事実と分けてください。

架空の二経路を検収し、合流後の見落としを確認する

受付ID・選択経路・共通項目をローカルで照合する

次のコードは、autoとmanualの出力をPythonの辞書で表した教材です。未実行側はNoneとします。Difyの集約ノードを再実装したコードではなく、出力を受け入れてよいかを確認する独自の検収処理です。実際のノードの優先順位や選択動作を模擬した結果とは扱いません。

検収の順序は、選択経路の名前、有効な経路数、Objectか、共通四項目か、IDと経路の一致、本文の有無、真偽値の型と意味です。エラーの文章も、この教材でどの確認が必要かを示すために決めています。Difyに表示されたエラーメッセージの引用ではありません。

import json

required={'ticket_id','route','reply','review_required'}
fixtures={'auto':{'ticket_id':'Q01','route':'auto','reply':'受付を確認しました','review_required':False},'manual':{'ticket_id':'Q02','route':'manual','reply':'確認待ちです','review_required':True}}
def validate_outputs(expected_id,selected_route,outputs):
    active=[(route,value) for route,value in outputs.items() if value is not None]
    if selected_route not in ('auto','manual') or len(active)!=1:
        raise ValueError('選択経路と実行数を確認')
    route,value=active[0]
    if route!=selected_route or not isinstance(value,dict):
        raise ValueError('経路またはObjectを確認')
    if set(value)!=required:
        raise ValueError('共通項目を確認')
    if value['ticket_id']!=expected_id or value['route']!=route:
        raise ValueError('受付IDと経路を確認')
    if not isinstance(value['reply'],str) or not value['reply'].strip():
        raise ValueError('返信本文を確認')
    if type(value['review_required']) is not bool:
        raise ValueError('要確認フラグはBoolean')
    if value['review_required']!=(route=='manual'):
        raise ValueError('フラグの意味を確認')
    return value.copy()

requiredとの完全一致は、この小さい教材の条件です。実際のフローで追加項目を許可するなら、必要な項目の不足と、認めてよい追加項目を別に点検する設計へ変えます。すべてのObjectが四項目だけでなければならない、というDifyの制限ではありません。

review_requiredの型はBooleanかを確認します。Pythonではboolが数値の性質も持つため、この教材ではtypeがboolかを明示しています。本文へfalseという文字を表示するだけの確認では、真偽値として使えるかが分からないためです。

受付IDとrouteを照合するのは、別の入力の出力を混ぜないためです。Objectも四項目も揃っているのにQ01の受付へQ02の本文を渡していたら、型検査だけでは見つけられません。下流で使う業務上の対応条件を、型の確認の後へ置きます。

正常な二例は、別々の受付として期待値を決める

正常例の一つ目は、Q01がautoを選び、manualはNoneの状態です。replyは「受付を確認しました」、review_requiredはfalseです。二つ目はQ02がmanualを選び、autoはNoneで、replyは「確認待ちです」、review_requiredはtrueになります。

この二例は、選択経路を変えた別の実行として確認します。両経路の結果を一つにまとめた成功例ではありません。出力の件数を説明するときも、「二例をそれぞれ検収した」と書き、「一回で二経路を集約できた」と表現しないようにします。

期待値には、受付ID、route、本文、フラグをすべて含めます。エラーが出なかったかだけでなく、manualの確認待ちがautoの確認不要へ変わっていないかを確かめます。型がBooleanでも、意味が逆なら仕事の判定は変わるためです。

実機で同じ考え方を使う場合は、外部送信を伴わない小さいフローで、autoとmanualを個別に試します。実行された経路、出力の型、項目名、下流が参照した変数を記録します。本稿ではこの実機操作を行っていないため、実際のDifyの成功件数や料金の実績として報告しません。

次に正常例の一項目だけを変えた保留例を用意すると、どの条件が効いているかを確かめられます。複数箇所を同時に変えると、最初のエラーだけを見て別の不一致を見落とすことがあります。教材では、本文の欠落、フラグの型、IDの違いなどを分けて試します。

八つの保留例で、型だけでは見つからない違いを調べる

次のコードは、正常二例と保留八例を検査します。数は編集部が用意した教材の件数です。Difyで起きるエラーの頻度や、業務での防止率を示すものではありません。保留とは、検収関数がValueErrorを返し、後続の利用へ進めないという意味です。

valid=[validate_outputs('Q01','auto',{'auto':fixtures['auto'],'manual':None}),validate_outputs('Q02','manual',{'auto':None,'manual':fixtures['manual']})]
invalid=[
 ('ゼロ経路','Q01','auto',{'auto':None,'manual':None}),
 ('二経路','Q01','auto',fixtures),
 ('JSON文字列','Q01','auto',{'auto':json.dumps(fixtures['auto']),'manual':None}),
 ('項目欠落','Q01','auto',{'auto':{k:v for k,v in fixtures['auto'].items() if k!='reply'},'manual':None}),
 ('文字列false','Q01','auto',{'auto':{**fixtures['auto'],'review_required':'false'},'manual':None}),
 ('ID違い','Q99','auto',{'auto':fixtures['auto'],'manual':None}),
 ('空Object','Q01','auto',{'auto':{},'manual':None}),
 ('意味違い','Q01','auto',{'auto':{**fixtures['auto'],'review_required':True},'manual':None}),
]
blocked=[]
for name,ident,route,outputs in invalid:
    try:validate_outputs(ident,route,outputs)
    except ValueError as e:blocked.append({'case':name,'reason':str(e)})
    else:raise AssertionError(name)
assert len(valid)==2 and len(blocked)==8

空Objectは存在する経路として数えられた後、項目がないため保留になります。文字列のfalseは項目の一覧を満たしていても、Booleanではないため保留です。autoのtrueは型も項目も正しいのに、この教材で決めた確認不要という意味に合わず保留になります。

この違いが分かると、Objectに変更しただけで解決したと判断しにくくなります。型の不一致が直った後にも、項目の不足や意味の違いが残る場合があります。原因が一つとは限らないので、直した条件と、まだ確認していない条件を分けて残してください。

Codeノードへ移す前に、入力・出力と実行範囲を合わせる

本稿のPythonコードを、そのままDifyのCodeノードへ貼れば同じ確認になるとはしていません。公式資料では、入力変数を定義し、main関数の返す辞書を宣言した出力変数へ対応させます。今回のローカル関数は、その入口と出口をCodeノード用に組み立てたものではありません。

移す場合は、expected_id、selected_route、検査するObjectをどの入力変数から受け取るかを決めます。成功時に返す型と項目、保留時にどう止めるかも、実際のフローで確認します。エラーを文字列として返す方式と、実行を止める方式では、その後の処理が異なります。

DifyのCode環境は、ローカルPCと同じ権限や依存ライブラリを持つものではありません。公式資料はサンドボックスの制限を説明しています。教材のためにシステム設定やアクセス権を変える必要はなく、入力と出力の検収に必要な範囲で設計します。

LLMから出た値をObjectへ渡す構成では、内容の事実確認も別に必要です。本稿の検収で分かるのは、受付ID、route、本文の存在、フラグの型と教材上の意味までです。replyが人の依頼に正しく答えているか、規約や元資料に合っているかを検証する関数ではありません。

外部APIへの送信や本番の返信へつなぐ前に、架空の入力で保留例を試す段階を設けます。分岐と検収が通ったことを理由に、実在の受付へ自動送信する範囲まで広げないでください。学習用の動作確認と、業務への導入判断は別の作業です。

質問や学習先には、経路と期待する出力を一緒に伝える

型エラーを質問するときは、「変数集約器が動かない」だけでなく、選択経路、各経路の出力型、共通項目、下流の参照先、期待する結果を一緒に伝えます。実在の顧客情報や外部サービスの認証情報は入れず、架空の受付IDと短い本文へ置き換えてください。

必要な知識は、変数の参照、条件分岐、StringとObjectの違い、項目ごとの型、実行結果の読み取りです。先に複雑なエージェントを作るより、二経路を別々に試せる小さいフローで、出力の約束を説明する練習が役立ちます。本稿の四項目は、その練習の一例です。

Codeを使うなら、Pythonで辞書の項目を読むことと、例外を扱うことも学習範囲になります。コードを書かずに進めたい場合でも、どの項目が必要かを表で示せれば、フローの確認や相談に使えます。コードの量を増やすことが、出力の意味を揃える代わりになるわけではありません。

講座や質問サポートを比較する際は、Difyを扱うという名称だけでなく、ワークフロー、型の不一致、実行経路の読み取り、自分の例への質問対応が範囲に含まれるかを確認します。料金や提供範囲を本稿から推定せず、利用時の公式説明と申込条件を見て判断してください。

学習の順序と独学で進める範囲は、Difyの独学ロードマップと講座の選び方で整理できます。今回の教材なら、正常二例、保留八例、共通四項目を説明できる状態を一区切りにします。Dify実機での試験結果を足す場合も、ローカル検収の結果とは別に記録します。

2026年10月13日に確認したバイテックのDifyマスターコースには、Dify入門やワークフローの学習案内があります。変数や分岐を含むフロー作成を順に学びたい人の比較候補です。この受付教材のレビューや変数集約器に限定した質問対応が含まれるとは確認していません。講座範囲、質問・添削、支援期間、受講総額とツール利用料を分けて確認してください。

合流の一箇所だけを直したい場合は、公式資料と正常・保留の小さい例から進める方法もあります。講座を検討するときも、Codeでの検収まで学びたいのか、コードを使わずフローを作りたいのかを先に伝えると、必要な学習範囲を比べやすくなります。

PR：バイテックAIスクールの無料説明会を確認する

無料説明会の予約・参加と、有料講座の契約は別です。今回のローカル教材と実際のDifyフローを分け、質問したい経路や出力の例を準備してから判断します。

変数集約器と型エラーのよくある質問

Q. 並列に動いた二つのLLMの結果を変数集約器でまとめられますか？

A.

現行公式は並列分岐の結合用途ではないと説明しています。複数結果を同時に使う場合は、CodeやTemplateなどで入力、順序、欠落時の扱いを決める設計と区別します。

Q. 両方をObjectにすれば項目の不足も直りますか？

A.

型を揃える確認と、必要な項目がある確認は別です。本稿は受付ID・経路・本文・確認フラグの四項目を独自に決め、型の後に項目と意味を検収しています。Difyがこの四項目を自動で補うわけではありません。

Q. JSON形式の文字列はObjectと同じですか？

A.

見た目が同じでも型は別です。解析処理を置くなら、その場所と解析後の項目検査を明示します。本稿のローカル教材は、JSON文字列を自動でObjectへ変えず保留します。

Q. falseは値がない経路として扱いますか？

A.

本稿のfalseはObject内の正常なBooleanです。未実行側のNoneとは分けます。文字列のfalseも別です。ローカル教材のNone表現から、Dify画面の未実行経路の表示まで断定しません。

Q. 掲載コードはDifyで実行済みですか？

A.

ローカルPythonで正常二例と保留八例を検収したコードです。Dify実機での実行やAPI利用はしていません。Codeノードへ移す場合は、main、入力変数、宣言した出力型、保留時の処理を利用環境で合わせる必要があります。