DifyのCodeノードで出力エラーが出たら、入力変数名とmainの引数、returnの項目名と設定した型、下流の参照先を順番に比べてください。すべての値を文字列に変える前に、どの段階で期待した値と違ったかを確認します。
対象は、Difyで簡単な集計やデータ整形を組み込みたい人です。架空の受付3件を使い、採用2件・保留1件を数える小さなコードを作ります。その後、12種類の戻り値をローカルで検算し、出力の形と、元の受付に合う内容を分けて確認します。
一次資料確認日：2026年10月15日。現行のCodeノード資料、Outputノード資料、変数の検査、単一ノードの実行を確認しました。コードはPython 3.12.14でローカル実行しています。Difyクラウドや有料モデルを使った実機テストではありません。画面や型の名称は導入版により違う場合があるため、使っている環境と照合します。
コードとノード設定の間で、名前・型・参照を揃える
入力名とmainの引数を、一対一で照合する
Codeノードへ値を渡す際は、前のノードで値があることと、その値を正しく入力へ結び付けたことを別に確認します。画面に表示されている文字列をコードが自動的にすべて受け取るわけではありません。今回使う入力を一つに絞り、名前と参照元を控えます。
教材の入力名はraw_jsonです。Startなどで用意したテキストをCodeノードの入力raw_jsonへ指定し、Pythonの関数はmain(raw_json: str)にします。入力名をarg1へ変えたのに関数の引数をraw_jsonのままにすると、名前の約束が揃っているかを調べる必要があります。
引数の型注釈がstrであることと、実際に届く値が文字列であることも分けます。上流がObjectを返しているのに、JSON文字列を受け取るコードへ接続すると、処理の入口が合いません。今回のコードは文字列からJSONを解析する設計なので、Objectを受け取る設計とは異なります。
まず、架空の文字列を固定してCodeノード単体で確認するのが一つの方法です。上流のLLMを同時に動かすと、出力が毎回変わる問題と、入力の結び付けの問題が混ざります。固定した三件を使えば、受け取った値の違いを追いやすくなります。
入力欄の名前だけでなく、右側に指定した参照元も確認します。別のノードが同じような名前を持つ場合、古いノードの出力を選んでいるかもしれません。ノード名、変数名、実際のテスト入力を揃えて記録すると、何を渡したか説明できます。
LLMが返したJSONの形そのものを整える段階で止まる場合は、Difyの構造化出力とJSON Schemaを確認する方法が関連します。本稿は、その前処理を通った値をCodeノードへ渡すときに、名前と型の約束を検算する課題です。
returnのキーと出力変数名を、三項目に限定する
現行の公式Code資料では、mainが辞書を返し、その項目を設定した出力変数と対応させる構成を説明しています。教材ではaccepted_count、hold_count、summaryの三つを返します。画面の出力変数にも同じ名前を使い、必要以上に項目を増やしません。
accepted_countは採用件数、hold_countは保留件数、summaryは人が読む短い説明です。例えばacceptedCountとaccepted_countは、読者には似た名前でも同じ文字列ではありません。大文字小文字、下線、末尾のスペースを含めて、コードと設定を比較します。
Pythonのローカル変数名がcountであっても、辞書のキーがaccepted_countなら、返す項目の名前はaccepted_countです。関数内で計算に使う名前と、外へ渡す項目名を区別してください。画面の出力変数へ、計算途中の変数名をそのまま書く必要があるとは限りません。
また、print()で表示したこととreturnで返したことは別です。画面に件数らしい文字が見えても、関数が必要な辞書を返しているかを確認します。ログを見るための出力と、次のノードで選ぶ変数を混同しないことが、空出力を調べる手掛かりになります。
今回の教材は三項目すべてが必要という約束です。採用件数だけを返して保留件数を省くと、総件数が合うか確認できません。逆に不要な個人名や連絡先を出力へ追加する理由もありません。次の処理に必要な範囲を決めてから項目を揃えます。
見直す際は、コードの戻り値と設定の一覧を並べます。「どちらかに合わせる」だけで終えず、後続の処理が必要とする三項目に合っているかまで確認します。設定を場当たり的に変更すると、エラーが消えても次のノードで使いたい値を失う可能性があります。
数値・文字列・Booleanを、用途から使い分ける
教材ではaccepted_countとhold_countを数値、summaryを文字列として扱います。件数を数値にしておくと、後で足し算や条件分岐に使う意図が伝わります。表示のための説明文はsummaryへ分け、すべての値を文章へまとめてしまわない設計です。
数値の2と文字列の“2”は、同じ数字に見えても型が違います。戻り値が文字列なのに出力変数を数値へ設定していたら、コードが返す型と画面の型を比較します。どちらを使うかは、後続で計算するのか、人へ表示するのかを基準に決めます。
Booleanのtrueも、件数の1と同じものとして受け取りません。PythonではBooleanと整数の関係から、単純な型判定が意図した条件より広くなることがあります。本稿のローカル検算ではtype(value) is intを使い、件数は整数だけという教材の約束に合わせます。Difyが同じエラー文を出すという意味ではありません。
不明な件数を0にすることにも注意してください。0は対象がゼロ件だと数えた結果で、不明は確認できない状態です。今回のコードは不明なstateを受け取ったときに止めます。未知の分類を保留件数へ黙って加算する仕様にはしていません。
空文字のsummaryは、型として文字列でも、人が判断する説明として不足しています。型の検査を通ることと、使える説明があることは別です。この違いを、後半の12例で確認します。型だけ直して「全部解決した」と判断しない理由になります。
| 項目 | 教材の型 | 使い道と検算 |
|---|---|---|
| accepted_count | 整数を数値として返す | 採用件数。元のstateがacceptedの件数と一致 |
| hold_count | 整数を数値として返す | 保留件数。元のstateがholdの件数と一致 |
| summary | 文字列 | 二つの件数を人が読める説明へまとめる |
Codeの出力と、利用者へ返すOutputを分ける
Codeノードで三項目を作った後は、次のノードがその出力を参照しているか確認します。変数名が同じでも、別ノードの古い出力を指定していたら、期待した件数は届きません。ノード名と項目名を組にして照合する必要があります。
現行のWorkflow用Outputノードは、上流のどの変数を利用者やAPIへ返すか設定するものです。公式は、OutputがないWorkflowでも実行は成功し得る一方、その経路から利用者へ返すデータはないと説明しています。Codeの計算成功と、結果を返す設定を別の確認項目にします。
例えばOutput側の公開名をacceptedとするなら、その参照元としてCodeノードのaccepted_countを選ぶ設計になります。公開名とCodeの項目名を同じにすることもできますが、名前を変えた場合は対応表を残すと、APIを使う側がどの値を読むか分かります。
Chatflowでは、WorkflowのOutputと同じ扱いを前提にせず、Answerノードの構成を確認します。古い説明でEndと書かれている場合もあるため、使うフローの種類と現在の画面を照合してください。本稿はWorkflowの結果を返す構成を中心に説明しています。
分岐を挟む場合は、通った経路で必要な値が作られるかを確認します。別の経路で作られた変数を選んでいても、今回の経路から値が出るとは限りません。Difyの変数集約器で分岐の型を揃える方法も、経路が複数あるときの参考になります。
検査では、ノード単体の出力、フロー全体の返却結果、利用者が見た表示を分けて記録します。一か所で三項目が見えたことを、すべての段階で値が渡った証拠にはしません。どこまで届いたかを確認すると、追加する設定が明確になります。
サンドボックスの制限と、型の問題を混ぜない
現在の公式Code資料は、コード実行の環境に制限があることを説明しています。ファイル操作、外部へのネットワーク通信、システムコマンドなどは、このノードで自由に使える前提にしません。今回のコードは、標準のjsonと文字列・リスト・辞書だけを使います。
パソコンで動いたコードを、そのままDifyへ貼ると、利用できるライブラリや実行環境が違う可能性があります。importで止まっているなら、returnの型を直す前に、その環境で依存するライブラリが使えるかを確認します。エラーが出た行を読むことが切り分けの出発点です。
外部の情報を取得したい場合も、Codeノードへ通信処理を足す前に、目的に合う専用ノードと環境の許可を確認します。入力データの加工と外部通信を別の段階に分ければ、通信の失敗と辞書の形の問題を比較しやすくなります。
件数が大きい処理や長い文字列では、導入版ごとの制限も確認してください。本稿の小さな例が通ることから、どの大きさでも同じコードが動くとは推定しません。最小の固定入力で名前と型を揃えた後、対象量を増やして確認範囲を広げます。
本稿は実機の制限を変更する手順ではありません。設定を緩めたり、勤務先のデータを別の環境へ移したりしなくても、今回の三件の教材で変数の約束を練習できます。問題を再現できる範囲を小さくすることが、相談しやすい記録にもなります。
受付3件のコードと12出力で、形と内容を検算する
採用2件・保留1件という期待値を先に作る
教材は、idがR01、R02、R03の三件です。stateは順にaccepted、hold、acceptedとします。人が読んだ期待値は採用2件・保留1件、合計3件です。コードの出力を見てから期待値を決めず、元の三行から先に数えておきます。
idとstate以外の項目は使いません。教材の受付IDは実在の顧客識別子ではなく、説明のために編集部が作ったものです。同じIDが二回あれば、今回は重複として止めます。再受付を別件として扱う業務なら、識別の仕様から見直す必要があります。
acceptedとhold以外の状態も、今回は止める理由になります。approvedやpendingを自動的に読み替える仕様にはしていません。分類の言い換えを受け入れたいなら、入力の仕様に含め、対応表と期待値を追加してから検算します。
空配列は、受付がゼロ件という有効な入力として扱います。解析できない文字列、配列ではないObject、項目の欠落は、ゼロ件と同じではありません。件数を0で返して処理を続けると、入力が壊れたことを確認する機会がなくなります。
この区別は、条件分岐にも影響します。採用が0件なら処理をしない、という分岐と、集計できないので人が確認する、という分岐は違います。DifyのIF/ELSEで空欄と数値を確認する方法を合わせると、値と停止理由を分けて考えられます。
入力の説明は短くても、件数の根拠を残してください。「R01とR03がaccepted、R02がholdなので2と1」と書ければ、後で出力が逆になったときにも、どちらが正しいか元の行へ戻って判断できます。
mainが辞書を返す小さなPythonコードを作る
次のmainを、教材の処理として用意します。raw_jsonはJSON文字列です。コードをDifyへ移すときは、入力にraw_json、出力にaccepted_countとhold_countを数値、summaryを文字列として設定する構成を照合します。ローカルでは下のsampleとassertを付けて確認できます。
import json
def main(raw_json: str) -> dict:
if not isinstance(raw_json, str):
raise ValueError("教材の入力はJSON文字列に限定")
rows = json.loads(raw_json)
if not isinstance(rows, list):
raise ValueError("教材の入力は配列に限定")
seen = set()
accepted = 0
hold = 0
for row in rows:
if not isinstance(row, dict) or set(row) != {"id", "state"}:
raise ValueError("各行にはidとstateが必要")
if not isinstance(row["id"], str) or not row["id"].strip():
raise ValueError("idは空でない文字列")
if row["id"] in seen:
raise ValueError("idが重複")
seen.add(row["id"])
if row["state"] == "accepted":
accepted += 1
elif row["state"] == "hold":
hold += 1
else:
raise ValueError("stateが教材の選択肢にない")
return {
"accepted_count": accepted,
"hold_count": hold,
"summary": f"採用{accepted}件、保留{hold}件",
}
sample = '[{"id":"R01","state":"accepted"},' \
'{"id":"R02","state":"hold"},' \
'{"id":"R03","state":"accepted"}]'
expected = {"accepted_count": 2, "hold_count": 1,
"summary": "採用2件、保留1件"}
assert main(sample) == expected
assert main("[]") == {"accepted_count": 0, "hold_count": 0,
"summary": "採用0件、保留0件"}ここで使うValueErrorの文章は、教材が自分で定義した停止理由です。Dify標準のエラー文を引用しているわけではありません。実機で別の表示が出る場合は、ノードの入力と停止した行を確認し、同じ原因かを調べます。
mainの外のsampleとassertはローカル検算用です。Difyへ貼る処理と、手元で結果を比べるコードを分けて保管すると分かりやすくなります。コード生成機能などで関数を書き換えた際にも、三件の期待値を残しておけば、変更後の件数を比べられます。
12種類の戻り値で、形の7例と内容の4例を分ける
次はmainの後に続けて実行するローカルの検算です。正しい出力を一つ作り、項目の欠落、名前違い、型違い、入れ子の違いを順に混ぜます。さらに、型が正しくても件数や説明が違う四例を用意します。
def inspect_output(value):
keys = {"accepted_count", "hold_count", "summary"}
if not isinstance(value, dict) or set(value) != keys:
return "保留:形"
if type(value["accepted_count"]) is not int:
return "保留:形"
if type(value["hold_count"]) is not int:
return "保留:形"
if not isinstance(value["summary"], str):
return "保留:形"
if value != expected:
return "保留:内容"
return "採用"
cases = [
("A 正しい出力", expected.copy()),
("B 項目がない", {"accepted_count": 2, "summary": "採用2件、保留1件"}),
("C 名前が違う", {"acceptedCount": 2, "hold_count": 1, "summary": "採用2件、保留1件"}),
("D 数値が文字列", dict(expected, accepted_count="2")),
("E 件数がBoolean", dict(expected, accepted_count=True)),
("F 件数がNone", dict(expected, hold_count=None)),
("G 戻り値が配列", [expected.copy()]),
("H 外側へ入れ子", {"result": expected.copy()}),
("I 件数が負", dict(expected, hold_count=-1)),
("J 説明が空", dict(expected, summary="")),
("K 合計が違う", dict(expected, accepted_count=3)),
("L 内訳が逆", {"accepted_count": 1, "hold_count": 2,
"summary": "採用1件、保留2件"}),
]
results = [inspect_output(value) for _, value in cases]
assert results == ["採用"] + ["保留:形"] * 7 + ["保留:内容"] * 4
for (name, _), result in zip(cases, results):
print(name, result)この検算は、教材の三項目と期待値に厳密に合わせています。Difyが追加項目をどのように処理するか、どの表示で停止するかを、このコードだけで実測したとは考えません。実機の設定確認に進む前に、自分が渡したい形を説明できるようにする練習です。
| 例 | 検算結果 | 見直す対象 |
|---|---|---|
| A 正しい出力 | 採用 | 三項目・型・2件と1件の内容が一致 |
| B／C 項目欠落・名前違い | 保留：形 | returnのキーと出力変数名 |
| D／E／F 型違い | 保留：形 | 文字列・Boolean・Noneを件数に混ぜていないか |
| G／H 配列・入れ子 | 保留：形 | 辞書のどの階層に三項目を返したか |
| I／J 負の件数・空説明 | 保留：内容 | 件数の意味と人が読む説明 |
| K／L 合計・内訳の違い | 保留：内容 | 元の三行から数えた期待値 |
Lは、採用1件・保留2件で合計3件です。合計だけを比べる検算なら通ってしまいます。元のstateごとの件数と照合することで、内訳の逆転を見つけられます。出力の型を直すことだけでは、この間違いを防ぐ確認にはなりません。
Jはsummaryが文字列なので、形の検算は通ります。しかし説明が空では、受取人が結果の意味を読めません。本稿では期待した説明まで照合して止めます。実務で表現を自由にしたい場合も、必要な件数が説明へ含まれるかなど、目的に合う内容確認を残します。
検算の採用1例という数字は、生成AIの成功率ではありません。十二の戻り値は意図的に編集部が作りました。学習者が、項目や型を直す作業と、集計内容を直す作業を混ぜずに説明するためのケース集です。
ノード単体、下流の参照、フロー全体の順で確認する
ローカルで期待値が一致したら、Dify側の確認を始めます。まず固定した三件の入力でCodeノードを単体実行し、実際に届いた入力と三項目の出力を見ます。画面の設定がコードの引数・キー・型に合っているかを、同じ教材で比較します。
次に、下流のノードでaccepted_countを選び、実行結果へ2が届くか確認します。summaryだけを選ぶと、採用件数の参照を確認したことにはなりません。用途に必要な項目ごとに、ノード名と変数名の対応を控えてください。
分岐やイテレーションを入れる前の短い経路で確認すると、原因を調べやすくなります。三件の処理が通ってから、空配列や不正なstateなどの境界例へ進みます。途中の一か所だけを直して、フロー全体の確認を省かないことが大切です。
配列の各件を繰り返す構成なら、Difyのイテレーションで入力と出力の件数を確認する方法も関連します。繰り返し後の件数が減った場合と、Codeの戻り値に項目がない場合は、確認する段階を分けられます。
今回のように人へ短い説明を返す場合は、数値を保ったままテンプレートで表示文を作る設計も選べます。DifyのJinja2で空欄・0・falseを扱う方法を使うと、ゼロ件の表示を空欄と混ぜずに確認できます。
最終記録には、クラウドか自分で導入した環境か、確認した日、ノード設定、固定入力、単体の結果、全体の結果を残します。本稿で済ませたのはローカルのmainと12出力の検算までです。実機で同じ確認をしたら、その範囲を別に追記して学習記録を更新できます。
質問支援を選ぶ前に、再現例と相談したい範囲を整理する
独学の課題としては、Aの出力を作るだけでなく、BからLのどれかを自分で修正して、なぜ直ったか説明するところまで進めます。名前違いならキーを揃え、文字列の件数なら必要な型を見直し、内訳違いなら元の分類の数え方へ戻ります。
相談するときは「動きません」だけでなく、「raw_jsonへ三件を渡し、accepted_countは数値2を期待したが文字列になった」のように具体化します。入力と期待値が少量なら、コードの修正と画面の設定確認を同じ例で話せます。実際の顧客情報を相談先へ送らない形でも再現できます。
Difyの学習ロードマップと講座の選び方では、作りたい課題と支援の必要な範囲を整理できます。操作を覚えたいのか、Pythonの辞書や型を理解したいのか、業務での検収を相談したいのかを分けると、質問できる講座を選びやすくなります。
バイテックの公式Dify講座案内では、Difyの基礎やワークフローを学ぶ内容が紹介されています。確認日は2026年10月15日です。バイテックAIスクールの教材と支援の確認点も参照し、Codeノードの課題や自作Pythonコードをどこまで質問できるかを、受講前に個別に確認してください。
本稿の12出力が講座に含まれると断定したり、受講すれば業務自動化や副業の成果が得られると約束したりはしません。学びたい範囲、質問方法、支援期間、総額、必要なツール費用が合うかを判断材料にします。小さな課題を先に作ると、相談したい内容が具体的になります。
よくある質問
Q. Codeノードの出力は全部文字列にすればよいですか？
用途に合わせて型を決めます。本稿の件数は数値、説明は文字列です。すべて文字列へ変えると、後続の計算や分岐で期待する型と合わなくなる場合があります。
Q. printで値が見えたのに、次のノードへ渡せません。
表示用のprintと、mainが返す辞書は別です。returnのキー、出力変数の名前と型、次のノードが参照するノード名と項目名を順に確認してください。
Q. 実行成功なのにWorkflowの結果が空なのはなぜですか？
Codeの出力と、利用者へ返すOutputの設定を分けて確認します。現行の公式資料では、OutputのないWorkflowや経路は成功しても利用者へ返すデータがないと説明されています。ChatflowではAnswerの構成も確認します。
Q. 合計件数が合えば、集計は正しいと判断できますか？
内訳も元の入力と比べます。教材のLは合計3件でも採用と保留が逆です。型と合計だけでは、分類ごとの間違いを検出できません。
Q. このコードはDify上で動作確認済みですか？
確認したのはPython 3.12.14でのローカル実行です。mainの通常入力と空配列、入力を止める例、12種類の出力を検算しました。実機では導入版・入力設定・出力変数・下流参照を別に確認する必要があります。