Difyのイテレーション出力を整える｜空配列・失敗・件数の確認

Difyのイテレーションを使ったら、結果が配列のままになった。表示文へ整えたら読みやすくなったけれど、入力した3件のうち何件が成功したのか分からない。このようなときは、入力配列、内部ノードの一件の結果、外側へ集まる結果配列を別に確認します。

対象読者は、Difyで開始・テンプレート・条件分岐などの小さいフローを作り、複数の入力を扱いたい初学者です。本稿は「配列を文章へ変える」だけで終わらず、欠けたIDや本文空欄を残して確認する練習です。架空のタスクを使い、外部APIやLLMは呼び出していません。

仕様確認日：2026年10月12日。Dify公式Iterationを参照し、最終更新表示は2026年5月14日でした。公式仕様の説明と、Python 3.12.14で実行したローカル照合教材を分けています。Dify管理画面でこの3タスクを実行した体験談ではありません。

配列の入力と、一件の結果と、集約された出力を分ける

画面に角括弧が見えても、配列型とは限らない

イテレーションは、上流の配列を受け取り、要素ごとに内部の処理を適用します。公式は入力と収集された出力を配列として案内しています。最初の確認は、見た目がリストかではなく、前のノードがどの型の変数を出しているかです。

例えば、文字列の中に「角括弧、三つのタスク、閉じ括弧」が書かれていても、それは配列を表したテキストである可能性があります。Stringを作ったノードと、Arrayを作ったノードでは、後続で選べる変数や扱う処理が違います。表示された文字を眺めるだけで型を確定しないようにします。

本稿の教材は、各要素にIDと作業名を持つ配列です。文字列の配列を使う仕事もありますが、ここでは三つのタスクを追跡するために、要素ごとのIDを用意します。Objectを使うことが、すべてのイテレーションで必要という意味ではありません。

前のノードからJSON文字列を受け取る場合、配列の形として読み取れるかを確認する段階と、Difyの出力変数として配列型を設定する段階を分けます。ローカルPythonでJSONを読めたことだけでは、Difyの変数接続も正しいとは言えません。

逆に、すでに配列として受け取っているデータを、見た目のために一度文字列へ変えてしまうと、後続で扱いにくくなることがあります。文字列へするのは、文章として表示する目的がある段階です。処理途中の型を変える前に、次のノードが何を必要としているかを確認します。

配列の型を確かめたいときは、前ノードの出力定義と、実行詳細に表示される結果を見ます。値の長さや角括弧の有無だけで判断せず、「三つの要素なのか、一つの長い文字列なのか」を小さい入力で説明できるようにしてください。

内部の出力変数と、イテレーション全体の出力を混同しない

イテレーションの内部には、一件の入力に対して実行する処理を置きます。外側では、その処理から集めた結果を受け取ります。内部で生成した一つの本文と、外側で集まった三つの本文の配列は、同じ変数ではありません。

設定を調べるときは、現在処理中の要素を参照している変数、内部で最終的に返す値、外側で選ぶ出力の三点を確認します。似た名前のノードがあると、別の値を接続してしまうことがあります。変数名だけでなく、その値の型と具体的な小さい入力を見比べます。

本稿なら、T01を処理するときの入力は会議準備です。その一件から返す照合用の結果には、T01というIDと、確認した本文を残します。外側へ集まった後もIDを残せば、「最初の文章だからT01だろう」と位置だけから推定する必要がありません。

位置の番号とIDは目的が違います。公式は、現在の要素と0から始まるindexを内部から参照できると案内しています。indexはどの位置を処理しているかの確認に使えますが、仕事のタスクそのものを識別するIDを置き換えるものではありません。

特に、途中の結果を除く設計では、外側の0番目、1番目という位置が、元の入力のどのIDに対応するかを見直す必要があります。失敗した一件が配列から取り除かれた後に、残った二件を三件の入力へ位置で対応させると、後ろのタスクを別のタスクとして読むおそれがあります。

出力を受け取った段階でIDを付け直すより、処理中の元IDを結果へ含める設計を検討します。内部の処理で返せる形式は、使用するノードと画面の定義へ合わせてください。本稿のPythonのdictをそのままDifyの設定としてコピーした結果まで確認したものではありません。

架空3タスクで、成功・失敗・本文空欄を別の状態にする

入力は、会議準備、来客受付、備品補充の三つです。T01には本文があり、T02は処理失敗として扱い、T03は処理結果のレコードがあるものの本文が空欄という教材を用意します。これらは編集部が手で定義した値で、LLMが生成した結果ではありません。

tasks = [
    {"id": "T01", "title": "会議準備"},
    {"id": "T02", "title": "来客受付"},
    {"id": "T03", "title": "備品補充"},
]
success1 = {"id": "T01", "text": "机の配置を確認"}
success3 = {"id": "T03", "text": ""}

# 公式の失敗方針を理解するための、手で作った照合入力。
continued = [success1, None, success3]
removed = [success1, success3]

T03の本文空欄は、T02の失敗と同じ状態ではありません。教材ではT03の結果レコードが存在し、IDも返っています。ただし、作業メモが必要な仕事なら、空欄のまま完了としてよいかを別に判断します。ノードが成功扱いでも、読者が必要な内容を得られたとは限りません。

T02は、受け取ったIDの集合から抜けています。継続時の教材にはその位置へNoneを残し、失敗除去時の教材には要素自体を残しません。PythonのNoneは、このローカル例でJSONのnullに相当する状態を表すために使っています。Difyの実際の出力を取得して代入したものではありません。

この三状態を分けると、配列の長さ、IDの数、本文がある件数という三つの数字を確認できます。配列の長さが3でも、本文のあるタスクが3件とは言えません。また、配列が2件でも、入力自体が2件だったのか、一件失敗して減ったのかは、出力だけから決められません。

教材の値を変更するときは、T03へ本文を入れる、T02の成功レコードを加える、といった一つの変更から試します。それぞれ、本文空欄の一覧と欠けたIDの一覧のどちらが変わるかを先に予想します。表示が変わるだけでなく、確認する状態が変わることを意識してください。

空配列、null、本文の空文字を分けて調べる

空配列は、要素が一つもない状態です。nullは、何らかの要素を受け取る箇所に値がない状態を表す場合があります。空文字は、文字列の値は存在するものの中身がない状態です。これらを全部「空」と呼ぶと、止まっている段階を見失いやすくなります。

入力が空配列なら、まず前段の抽出や絞り込みが、期待する三つのタスクを作れていたかを確認します。条件に合うタスクが本当にゼロなら、ゼロ件という結果を返す経路が必要です。三件あるはずなのにゼロだった場合は、イテレーションの表示整形へ進む前に、入力生成を調べます。

本稿の照合関数では、入力も出力も空配列なら件数0を返します。ただし、Difyの各版や設定で空配列を実行した挙動まで確認したわけではありません。実機では、空入力を別の分岐へ回す必要があるか、使っている画面と小さい試験入力で確認してください。

出力のnullは、今回の教材ではT02の処理失敗を残す表現です。何の情報が欠けたかを調べるために、入力IDの控えが必要になります。nullを文字列の「null」として表示しただけでは、どのタスクの処理をやり直すかは決まりません。

本文が空文字のT03は、IDの照合では存在を確認できます。したがって、欠けたIDの一覧には入りませんが、本文空欄の一覧へ残します。作業によっては空の結果が正常な場合もあるため、「空欄を見つけたら無条件で失敗」と決めるのではなく、必要な内容の条件を先に書きます。

空白だけの本文も、表示上は空欄に見えることがあります。本稿の教材は文字列の両端の空白を調べ、本文空欄の候補へ残します。元の本文を書き換えているわけではありません。空白を意味のある文字として扱う仕事では、別の判定条件へ変更する必要があります。

失敗時の3方針を、仕事の完了条件から選ぶ

現行公式は、エラーで停止する方針、失敗した要素をnullとして残して続ける方針、失敗結果を除いて成功分だけ返す方針を案内しています。使いやすそうな設定を先に選ぶのではなく、全件が必要か、部分的な結果を使えるかを確認して決めます。

例えば、三つの作業すべてに担当者向けのメモが必要なら、T02を落とした二件の本文だけを配布しても完了ではありません。部分的な結果を使う場合も、確認が残るIDを明示します。配布物の読みやすさと、仕事を全部処理できたことは別の条件です。

一方、成功分だけを先に確認する作業なら、失敗除去の結果が候補になります。その場合も、失敗した入力がなかったことにしないようにします。次の作業でT02を拾うための一覧や、失敗内容を調べる記録を別に残してください。

継続時の配列が3要素あったというだけでは、成功が3件とは言えません。本稿の例では、nullを一つ含む三要素です。結果の数を数える式へ何を含めたかを、報告へ書きます。本文が空のT03も、ノードの成功扱いと内容の確認を分けて数えています。

設定の変更前後を比較するときは、同じ入力IDを使います。入力自体が変わっていると、出力件数の差が設定によるものか判断しにくくなります。三件という小さい入力で、nullが残る、要素がなくなる、処理が止まるという違いを確かめてから、実務の入力へ移します。

件数とIDを照合してから、目的に合わせて出力を整える

表示用の文章とは別に、件数と欠けたIDを返す

次のコードは、三タスクの照合方法を練習するための通常のPython関数です。DifyのCodeノード用のmain関数や出力変数の宣言は含みません。実際のノードへ移す場合は、入力・出力の設定を対応する画面へ合わせる必要があります。

この教材では、一つの入力IDに対して一つの結果レコードを期待しています。出力が複数の明細になる仕事は、後の節で扱うように照合単位を見直します。すべてのDifyワークフローでこの形式を使う必要がある、という意味ではありません。

def audit_outputs(inputs, outputs):
    if not isinstance(inputs, list) or not isinstance(outputs, list):
        raise TypeError("配列を確認")
    if any(
        not isinstance(x, dict)
        or not isinstance(x.get("id"), str)
        or not x["id"] for x in inputs
    ):
        raise ValueError("入力IDを確認")
    expected = [x["id"] for x in inputs]
    if len(expected) != len(set(expected)):
        raise ValueError("入力ID重複")

    kept = []
    nulls = 0
    for x in outputs:
        if x is None:
            nulls += 1
            continue
        if (
            not isinstance(x, dict)
            or not isinstance(x.get("id"), str)
            or not isinstance(x.get("text"), str)
        ):
            raise ValueError("出力の型を確認")
        kept.append(x)

    received = [x["id"] for x in kept]
    if len(received) != len(set(received)):
        raise ValueError("出力ID重複")
    if set(received) - set(expected):
        raise ValueError("入力外のID")

    return {
        "inputs": len(inputs),
        "outputs": len(outputs),
        "nonnull": len(kept),
        "nulls": nulls,
        "missing": sorted(set(expected) - set(received)),
        "blank": [x["id"] for x in kept if not x["text"].strip()],
        "text": "\n".join(
            f'{x["id"]}: {x["text"] if x["text"].strip() else "<本文空欄>"}'
            for x in kept
        ),
    }

c = audit_outputs(tasks, continued)
f = audit_outputs(tasks, removed)
assert c["outputs"] == 3 and c["nulls"] == 1
assert f["outputs"] == 2 and f["nulls"] == 0
assert c["missing"] == f["missing"] == ["T02"]
assert c["blank"] == f["blank"] == ["T03"]
assert c["text"] == f["text"]

受け取ったIDの集合と、入力したIDの集合を比べます。これでT02が確認対象へ残ります。出力の順が変わった場合も、IDが保たれていれば、どの入力に結果がないかを照合できます。Difyの並列出力の順序を、このローカル関数で実測したという意味ではありません。

関数は、出力のID重複と入力外のIDを見つけたら止めます。T01が二回返っているのに、配列が三件だから全部成功したと数えることを避けるためです。また、T09という入力していないIDが混じっていた場合も、そのまま配布せず入力と接続を調べます。

戻り値のtextは表示用です。missingやblankを含む照合結果を、表示文だけへ置き換えないでください。何が確認済みで、何が残っているかを機械的に見る情報と、人が読む文章を一組にして保存します。本文だけをコピーすると、失敗したIDの情報は失われます。

実務へ持ち込む前に、どの項目を完了条件にするかを書きます。「出力IDが揃う」「必要な本文がある」「本文の内容を人が確認する」などです。件数を数えるコードは、最後の内容確認までは代わりに行いません。

同じ文章になっても、3要素と2要素の違いを隠さない

教材の継続配列と失敗除去配列は、照合後の表示文が同じになります。T01の本文と、T03の本文空欄という表示だけが残り、T02の失敗は表示文へ入れないためです。「読みやすい文章ができた」という見た目だけでは、選択した失敗方針を確かめられません。

表示する文章の例は、T01に「机の配置を確認」、T03に「本文空欄」と付けた二行です。ただし、この二行を「二件の成功」とだけ報告すると、T03の内容確認が落ちます。成功扱いのレコードが二つあり、そのうち本文を確認できるのは一つ、と分けて書くと状況を伝えやすくなります。

nullを取り除く処理を追加すると、出力の長さがさらに変わることがあります。除去する前の配列と、表示のために除去した後の配列を区別します。後の長さだけを使って、元から二件の入力だったかのように集計しないでください。

入力側にIDがない場合は、何を元のタスクとして識別するかを先に決めます。文章が同じ二タスクを、本文をキーにして区別できるとは限りません。入力ファイルの管理番号や、教材用に定義したIDなど、同じ作業を追える情報を用意します。

なお、本稿の「欠けたID」は失敗原因を示す情報ではありません。T02が戻っていないことは分かっても、設定の違い、前ノードの型、外部サービスの応答などのどれが原因かは、この集合だけでは決められません。実行詳細を調べる対象を絞るために使います。

最終表示では、確認が残る項目も一緒に書きます。例えば「入力3件、結果ID2件、来客受付T02は確認待ち、備品補充T03は本文空欄」といったメモです。これなら、読みやすさのために失敗情報を消してしまうことを防げます。

文字列へ変えるか、配列のまま渡すかを用途で選ぶ

イテレーションの結果を人が読む一つの文章へまとめたいなら、配列の各結果から必要な文字列を取り出し、区切りを付けて整形します。後続が配列を必要とする場合は、その型を保つ設計が候補です。「イテレーションの出力は常に文字列へ変換しなければ使えない」と一律に決めません。

現行公式は、最終用途に向けて変換が必要になることがあると説明し、CodeやTemplateによる配列からテキストへの変換例を示しています。実際に使う出力ノードがどの型を受け付けるかは、使用している画面と出力定義で確認してください。

Objectの配列をそのまま文字列化すると、ID、本文、記号が一つの表示へ混ざることがあります。見た目を直すために全体へstrをかける前に、どの項目をどの順で見せるかを決めます。本稿は、IDと本文を一行にし、本文空欄には表示語を付けました。

Templateで整える場合も、文字列だけを受け取るのか、ID付きの結果を受け取るのかで書き方が変わります。変数を設定する欄と、その変数を本文で参照する欄を分けて確認します。別の例に出てきた変数名をそのまま貼っても、自分の接続先の出力とは限りません。

IDを文章へ入れない表示が必要な場合も、照合用の情報は別に残せます。利用者へ見せる短い本文と、担当者が点検するID・件数の控えを分ければ、表記を簡潔にしながら確認を続けられます。何の情報を残すかは、使う人の目的から決めます。

出力形式の選択は、型のエラーを隠すための手段ではありません。前段が想定した結果を作れているかを確認した後に、表示へ進めます。単一のHTTPリクエストのJSON型を調べる場合は、DifyのJSONエラーと本文タイプの確認へ戻って切り分けられます。

一件から複数の結果が出る場合は、数える単位を見直す

本稿の照合関数は、一タスクにつき一つの結果レコードを期待する教材です。実務では、一つの資料から二つの見出しが出るなど、入力一件に対して結果が複数になることもあります。その場合、出力の要素数が入力数より多いという理由だけで異常と決めないようにします。

例えば、三つのタスクそれぞれに「準備」と「完了確認」の二項目を付ける教材なら、三タスクと六項目という二つの数があります。一件分をまとめたリストが三つある状態と、六項目へ展開した状態では、配列の数え方が変わります。

このような入力を単純に一列へ平らにすると、どの項目がT01から出たかを見失う場合があります。元のIDと項目名を結果へ残すか、タスクごとのまとまりを維持します。見た目の階層を減らせたかではなく、元タスクへ戻れるかを確認するのが判断の軸です。

六項目を一件ずつ追いたいなら、「タスクID＋項目名」などの照合単位を検討します。ただし、項目名が同じでも内容が複数ある場合には別の識別方法が必要です。本稿のID重複チェックを外すだけで、複数結果への対応が完成するわけではありません。

また、改行を含む一つの本文を二行と数えることと、二つの結果レコードを数えることも違います。本文の長さや改行数を、処理したタスク数へ置き換えないでください。出力形式を変える前後で、数える対象を同じ名前の指標にしていないか見直します。

Difyの出力形式や配列の接続方法は、ノードの種類や版で確認する必要があります。本稿の三タスクのPython例は、任意の入れ子配列を処理するDify実機の検証ではありません。形が違う入力へ使う場合は、元ID、結果の単位、期待する件数を書き直して、小さい教材から確かめます。

小さい入力で検収してから、学習や実務へ進む

最初の確認票には、入力したID、期待する件数、選んだ失敗方針、受け取ったID、nullの数、本文空欄、残る確認を記入します。「成功した」とだけ書かず、どの条件を確かめられたかを残すためです。

本稿のローカル参照では、三タスクの継続と失敗除去、空の入力、出力の並び替えを確かめています。また、配列を記述した文字列、重複ID、入力外のID、本文がNoneの入力は保留しました。これは照合関数の確認であり、Difyの実行やLLMの回答品質の評価ではありません。

Difyで自分のフローを試すときも、まず少数の架空入力で期待値を書きます。外部サービスへつなぐ場合は、呼び出しの有無や利用枠を確認したうえで試す範囲を決めます。並列化や再試行を増やす前に、一件の入力と一件の結果を説明できる状態にしてください。

停止したタスクを再処理する必要があるときは、すでに結果があるタスクまで重複して実行していないかを確認します。どのIDを処理済みとするかは、ノードの成功だけでなく仕事の完了条件で決めます。本稿のT03のような本文空欄が、再確認の対象になる仕事もあります。

独学を進める目安は、入力3件、出力3要素、結果ID2件、本文空欄1件という数字を自分で説明できることです。表示された二行だけを見る段階から、何が欠けたかを追える段階へ進む練習になります。

2026年10月12日に確認したバイテックのDifyマスターコースは、Difyのワークフローを学ぶ候補です。ただし、この三タスクのレビューや特定の外部APIとの接続支援が含まれるとは確認していません。申込前には、質問・添削の範囲、支援期間、受講総額とツール利用料を分けて確認します。

配列の型だけを調べたい人は、公式文書と小さい参照入力から独学を続ける方法も比較できます。フローの接続や複数段階の切り分けで止まっている人は、どの工程を質問したいかを整理してから支援を選びます。学習方法の違いは、Difyの独学ロードマップでも確認できます。

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

無料説明会の予約・参加と、有料講座の契約は別です。自分が止まっている工程を整理し、どの演習や質問支援が含まれるかを確認してから判断します。

よくある質問

Q. イテレーションの入力は、配列を書いた文字列でもよいですか？

A.

配列の見た目をしたStringと、Arrayとしての変数を区別します。前ノードの出力型と接続を確認し、文字列を読めたことだけでDifyの配列設定も確認済みとは扱いません。

Q. 出力配列の長さが3なら、3タスクとも成功ですか？

A.

今回の継続教材は三要素のうち一つがnullです。出力長、受け取ったID、null、本文空欄を別に数え、入力のIDと照合します。

Q. 失敗結果を除いたら、何を確認すればよいですか？

A.

成功分だけの配列には失敗したIDが残らない場合があります。入力IDの控えと結果IDを比べ、欠けたタスクを別の確認対象へ残します。

Q. 出力はいつも文字列に変換する必要がありますか？

A.

人が読む文章へまとめる用途なら整形を検討します。配列を必要とする後続では型を保つ設計が候補です。使うノードが受け付ける型を現行の画面で確認します。

Q. 本稿のコードをDifyのCodeノードへそのまま貼れますか？

A.

通常のPython用の照合関数です。Dify用のmain関数や出力変数宣言を含まないため、ノードへ移す際は入力・出力設定を合わせて実機で検証してください。

• テンプレートの空欄・0・falseを調べる：文字列へ整える段階の条件確認。
• IF/ELSEの型と境界値：空入力などを別の経路へ分ける場合。
• ナレッジの検索結果を切り分ける：検索結果を入力配列へ使う前の確認。