【Dify】Lesson4-3:JSON入門|構造化出力の仕組みを理解しよう

ここまでの学習記事で、実務っぽいアプリの形が見えてきたかと思います。
ここまで来ると次にぶつかりやすいのが、AIの出力が “その時々で言い回しが変わってしまう問題” です。
たとえば、ミスチェック結果を後段で整理して表示したいのに、AIが毎回違う順番で書いたり、余計な前置きを入れたりすると、ワークフローの後半で扱いづらくなります。
ここで役に立つのが、JSON(ジェイソン)という「決まった形で出力させるためのルール」です。
この記事では、プログラミングとしてのJSONではなく、Difyでアプリを安定させるための「構造化出力」としてのJSONに絞って学びます。
最終的には、AIの回答を “決まった項目に分けて” 受け取り、変数として次のノードに渡せる状態を目指します。
Lesson1:Dify入門|環境構築と最初の生成AIアプリ開発
Lesson2:まずは体験|基本的なアプリを作ろう
Lesson3:文章業務を自動化するアプリを開発しよう
Lesson4:ファイル処理で広がるDifyアプリ開発
・Lesson4-1:PDF資料要約アプリ|ワークフローツール入門
・Lesson4-2:資料のミスチェックアプリを作ろう|会話変数と変数代入ノード
・Lesson4-3:JSON入門|構造化出力の仕組みを理解しよう ◁今回はここ
・Lesson4-4:JSON体験|文章作成アシストアプリを作ろう
Lesson5:RAG実践|ナレッジ検索アプリを作ろう
Lesson6:機能拡張と外部システム連携|ツールを使いこなそう
Lesson7:総仕上げ|実践投入への準備
JSONとは?Difyで構造化出力が必要な理由
JSONは一言でいうと、「情報を項目ごとに整理して渡すための書き方」です。
Difyのワークフローでは、LLMノードの出力を次のノードで利用する場面が増えていくので、出力が整理されているほど後工程がラクになります。

テンプレートノードでもある程度の整形はできるけど、やっぱり限界があるよね。。。
JSONも活用してさらに綺麗な出力を作ろう!
人間向けの文章と、機械が扱いやすいデータの違い
ここまでのレッスンでも、LLMが返す文章は読みやすい一方で、毎回同じ形になるとは限らない…という感覚があったと思います。
人間は多少の揺れ(言い回し・順番・改行)があっても読めますが、ワークフローは「ここにあるはずの情報」を前提に処理します。
JSONにすると、たとえば「指摘内容」「理由」「修正案」といった “箱” が先に決まり、その箱に沿って中身を入れる形になります。
結果として、後段のノードで「この項目だけ取り出して使う」がやりやすくなります。
後工程がラクになる:JSONで“渡しやすい出力”を作るメリット
Difyでアプリを作っていると、ワークフローが進むほど「出力を材料にして次の処理をする」割合が増えます。
Lesson4-2で会話変数や変数代入ノードを触ったことで、「必要な情報だけを変数として扱う」重要性が見えてきたはずです。
JSONは、その “必要な情報だけを抜き出す” ことに相性がいい形式です。
文章から必要箇所を探して切り取るより、最初から「summary」「risks」「fixes」のように項目が分かれていれば、ワークフローが安定します。
特に、ミスチェックや評価結果のように「複数の指摘を並べたい」ケースでは、JSONの形にしておくと後で整形しやすくなります。
今回のゴール:Difyで困らないJSON最小セット
JSONは深く学び始めるといろいろありますが、この記事ではDify初心者が “必ず使う部分” だけに絞ります。
具体的には、次の2点ができればOKです。
- LLMに「この項目で返してね」とお願いして、出力の形をそろえる
- そろえた出力をワークフロー内で使いやすくする
JSONの基本:オブジェクト({})の意味と使い方
ここからは、Difyで構造化出力を使うために「これだけ分かれば困らない」という最小セットだけを押さえます。
目的はプログラミングの勉強ではなく、LLMの出力を“崩れにくい形”に整えることです。
まずは、JSONの オブジェクト の意味と使い方を理解しましょう。
オブジェクトとは、{} で囲んだ「項目名(キー)と中身(値)」のセットをまとめたものです。
情報を項目ごとに整理して持てる箱だと思えばOKです。
{
"項目1": "中身",
"項目2": "中身",
"項目3": "中身"
}たとえば、「要約結果」を1つにまとめるオブジェクトは以下のように書けます。
{
"title": "要約タイトル",
"summary": "短い要約本文"
}
このオブジェクトには、「title」という箱に「要約タイトル」という文字列が、「summary」という箱に「短い要約本文」という文字列が保存されているね。
オブジェクトは変数の集まりと言ってもいいかもね。
Lesson4-1で作った「要約アプリ」のように、決まった項目を1つずつ用意したいときに向いているよ。
オブジェクトのキーと値(key: value)の感覚だけ押さえる
オブジェクト {} の中は、「キー」と「値」のペアでできています。
Dify視点で言うと、キーは“項目名”、値は“中身”です。たとえば summary というキー(項目名)に、値(要約文)を入れるイメージですね。
{
"summary": "この資料は◯◯について説明しています。"
}ここで大事なのは、キーは必ずダブルクォートで囲むことです。
summary を 'summary' にしたり、クォート無しにしたりするとJSONとしてはNGになります(このミスはかなり多いです)。
{"キー1": "値1" , "キー2": "値2" , "キー3": "値3" , ... }
改行はあってもなくても意味は同じ。
「{」「”」「:」「,」「}」の5種類の記号と、それぞれの情報で構成されるのがオブジェクトだよ。
JSONの値の型:文字列・数値・真偽値・null
値(value)として使われるのは、文字列(文章)だけではありません。
Difyの構造化出力でよく使われる例を4つ紹介します。
まず、文字列はダブルクォート「”」で囲みます。
{"result": "OK"}キーは必ず文字列なので、常に「”」が必要ですが、値も文字列のときは必要となるので忘れないようにしましょう。
文字列ではなく数値の場合は、クォート不要です。
{"score": 85}真偽(はい/いいえ)を表したいときは、専用の言葉「true / false」を使います。
ここは小文字固定なので注意です。
{"has_issue": true}そして「該当なし」「まだ埋めない」を表したいときには、これも専用の言葉「null」が使えます。
{"note": null}たとえばミスチェックで「指摘があるか?」を has_issue に入れておくと、後段のノードで分岐しやすくなります。
値はチェック前なら「null」、チェック後なら「true」か「false」が入るでしょう。
よくあるJSONエラー:クォート/末尾カンマ/全角記号
JSONはルールがシンプルなぶん、ちょっとした記号ミスで崩れます。Difyで「構造化出力がうまく読めない」ときは、だいたい次のどれかです。
まず、よくあるミスをざっと見てから、何に気をつければいいか掴みましょう。
- キーや文字列がダブルクォートではない(
'を使う、またはクォート無し) - 最後の要素の後ろにカンマが付いている
- 全角の記号が混ざる(全角カンマ
,、全角コロン:など) - JSONの外に余計な文章が混ざる(例:「以下が結果です:」のような前置き)
たとえばこのJSONは、最後にカンマがあるのでアウトです。
{
"title": "要約",
"summary": "本文の要点です",
}直すとこうなります。
{
"title": "要約",
"summary": "本文の要点です"
}また、JSONの“見た目”は合っていそうでも、全角記号が混ざっていると別物になります。
LLMがたまに全角を混ぜることがあるので、崩れたときは「記号が半角か?」をチェックすると直せることが多いです。
JSONの基本:配列([])の意味と使い方
JSONにおける配列とは、[] で囲んだ「データを順番に並べたもの」です。
以下のように、複数の項目をリストとしてまとめる箱だと思えばOKです。
["要点1","要点2","要点3"]
[ "要約タイトル", "この資料は◯◯について説明しています。" ]

単にデータを並べただけだから、オブジェクトよりも単純で簡単だね。
ただ、Difyで配列を扱うときに難しいのは、この各データの部分に “オブジェクトが入る” パターンが多いということ。
ここで一気に分からなくなってしまう人も多いよ。。。
配列の中にオブジェクトを格納する例は以下の通りです。
[
{ "キー1": "値1" , "キー2": "値2" , "キー3": "値3" },
{ "キー1": "値1" , "キー2": "値2" , "キー3": "値3" },
{ "キー1": "値1" , "キー2": "値2" , "キー3": "値3" }
]例えば「複数のミスを探すアプリ」なら、ミスごとにオブジェクト作成し、それらを1つの配列の中に入れてしまうことができます。
[
{"issue": "誤字", "fix": "修正案"},
{"issue": "脱字", "fix": "修正案"},
{"issue": "表現が曖昧", "fix": "修正案"}
]
この配列には、オブジェクトが3つ入っている。
Lesson4-2で作ったミスチェックアプリのように、決まった項目が2つ以上出てくるときに使いやすいね。
さらに、「オブジェクトを含んだ配列」をオブジェクトの中に入れた例も見てみましょう。
{
"issues": [
{ "issue": "指摘1", "fix": "修正案1" },
{ "issue": "指摘2", "fix": "修正案2" }
]
}この例は、大きく見ると
{"issues": [ 配列 ]}というシンプルなオブジェクトで、配列の部分が
[
{ "issue": "指摘1", "fix": "修正案1" },
{ "issue": "指摘2", "fix": "修正案2" }
]となっていることが分かります。
慣れないと読み取るだけでも大変ですが、このような書き方ができるとDifyの応用範囲が格段に広がります。

初めの内は簡単なオブジェクトだけを使うのでもいいと思うよ。
慣れてきて、より高度なアプリをより美しく作ろうと思った際に配列との組み合わせを思い出そう!
DifyでJSONを使う3つの定番パターン
JSONのルールが分かったら、次は「Difyのワークフローの中で、どこにどう差し込むと効果が出るか」を押さえましょう。
ここでは、初心者がまず使いこなしたい定番パターンを3つに絞って紹介します。
パターン1:LLMの出力をJSON形式で固定(プロンプトで縛る)
一番大事なのはこれです。
LLMの出力がブレると、後段のノードが扱いにくくなります。なので最初から「決まった項目で返してね」をプロンプトに入れて、出力の型を固定します。
たとえば「ミスチェック結果」を返す場合、文章で返させるのではなく、最初から次のような“箱”を決めておきます。
{
"has_issues": true,
"issue": "指摘内容",
"reason": "理由",
"fix": "修正案"
}このときのコツは、最初から欲張らないことです。
項目が多いほど崩れやすいので、まずは「後工程で本当に使うもの」だけに絞ります。
Lesson4-2の流れで言うなら、いきなり完璧な診断レポートを目指すより、「指摘・理由・修正案」くらいに絞ったほうが安定します。
パターン2:会話変数・変数代入で“必要な項目だけ”取り出す
JSONで返してもらったら、次は「必要なところだけ使う」に進みます。
ここで効いてくるのが、前のレッスンで触れた会話変数や変数代入の考え方です。
たとえば、ユーザーに見せたいのは「issuesだけ」、さらに別のノードでは「has_issuesだけ使って分岐したい」みたいなケースがよくあります。
文章のままだと毎回探して切り取る必要がありますが、JSONなら「このキーの中身」という形で扱えるので、ワークフローが読みやすくなります。
実務寄りのアプリだと、次のような整理がしやすくなります。
- 画面に表示する:
issuesを整形して見せる - 分岐に使う:
has_issuesが false なら「問題なし」で終了、true なら「修正提案へ」 - ログとして保存する:
titleやkey_pointsだけ別枠で残す
「全部を一気に使おう」とすると複雑になります。
まずは、“1つのJSONから1〜2項目だけ取り出して次に渡す”くらいの運用にすると、失敗しにくいです。
パターン3:コードノードで整形・検証・集計する
コードノード を使うと、LLMが返したJSONを材料にして、次のような “細かい仕上げ” ができるようになります。
たとえば、指摘の件数を数えて表示したり、必要な項目だけを抜き出して並べ直したり、入力漏れがないかをチェックしたり、といった処理です。
JSONで出力が揃っているほど、こうした加工がやりやすくなります。
コードノードの使い方は、次のLesson4-4で詳しく解説しますので、ここでは「そういう選択肢がある」と知っておけばOKです。
まとめ:JSON構造化出力でDifyワークフローを安定化
今回は、JSONを「プログラミングの知識」ではなく、Difyアプリを安定させるための“出力の型”として扱いました。
ポイントは、最初から完璧を目指さず、崩れにくい最小形から育てることです。
ここまでできれば、要約・ミスチェックのような文章系アプリが一段と実務向けになります。
次のレッスンでは、このJSON実際に使ったアプリを開発します。
ぜひこのまま次の記事へ進んでください。


