はじめに：AIの「非構造化データ」に消耗していませんか？
ChatGPTなどのLLMは強力なツールですが、その出力形式は「自然言語（非構造化データ）」です。
システム連携の現場では、次のような「あるある」で消耗していませんか？
- LLMが生成した結果を、手動でコピペ＆整形してDBやスプレッドシートに入れている。
- 「必ずJSON形式で出力して」とプロンプトに書いても、余計な説明が付いてきてパースに失敗する。
- 長文からのデータ抽出で、必要なキーが抜けたり、データ型が崩れたりしてエラーが止まらない。
結論から言います。 Difyの「構造化出力（Structured Output）」機能を使えば、この問題は完全に解決します。LLMの出力を、まるでDBのテーブルから取り出したかのように、厳密なデータ型と形式を持つJSONとして受け取れるようになります。
1. Difyの「構造化出力」とは？
DifyのLLMノードに組み込まれているこの機能は、OpenAIの最新モデル（gpt-4oやgpt-4-turboなど）が持つ強力なJSON Modeの力を、ノーコード・ローコードで引き出すものです。
設定はたったの2ステップ！
-
LLMノードでスイッチをON：
DifyのLLMノード設定画面で「構造化出力」スイッチを有効にします。 -
JSONスキーマを定義：
出力したいJSONのKey（フィールド名）、Type（データ型：String, Number, Arrayなど）、そしてLLMへのDescription（説明）をGUIで定義するだけです。
導入メリット
| 従来のLLM出力（プロンプト指示） | Difyの構造化出力 |
|---|---|
| パースエラー頻発 | パースエラーほぼゼロ (厳密なJSONを保証) |
| プロンプトが複雑化 (JSON指示文で長くなる) | プロンプトがシンプルに (キャラクター設定などに集中できる) |
| データ型の保証なし | numberやarrayなど、厳密なデータ型を保証 |
| 安定性がモデル依存 | JSON Mode対応モデルで極めて高い安定性 |
2. 【実例3選】業務データを爆速で抽出するJSON活用術
具体的なJSONスキーマの定義と活用例を見ていきましょう。
活用例①：長文議事録から「タスクリスト」を自動生成する（array型活用）
会議の議事録（自然言語）をAIに渡すだけで、すぐにTrelloやBacklogに登録できる形式のTo-DoリストJSONを出力させます。
💡 バズるポイント：array（配列）を定義して一括抽出すること！
| フィールド名 | タイプ | 説明 |
|---|---|---|
tasks |
Array (Object) | 議事録から抽出された具体的なタスクのリスト |
tasks[].task_name |
String | 具体的なタスクの内容（主語、動詞含む） |
tasks[].assignee |
String | 担当者の氏名（不明な場合は「未定」） |
tasks[].due_date |
String | 期限や締切日（YYYY-MM-DD形式に変換） |
出力されるJSON例
{
"tasks": [
{
"task_name": "来期のマーケティング予算案を策定する",
"assignee": "佐藤",
"due_date": "2025-12-15"
},
{
"task_name": "新サービスのワイヤーフレームを作成する",
"assignee": "田中",
"due_date": "2025-12-20"
}
]
}
活用例②：AIアバターの「感情」と「セリフ」を分離する（今回のツンデレ事例）
キャラクターAI開発では、AIのセリフと、それに応じたアバターの表情・アニメーション制御のための「感情データ」が必要です。
💡 バズるポイント：セリフと感情を独立したKeyに分離し、アプリ連携を容易に！
| フィールド名 | タイプ | 説明 |
|---|---|---|
response |
String | 幼馴染みキャラクターからの実際のチャット応答テキスト。 |
emotion |
String | 応答時の感情（例: ツン, デレ, 無関心, 困惑）。 |
出力されるJSON例
{
"response": "別に心配なんかしてないけど、風邪ひいても知らないから、さっさと帰りなさいよ。",
"emotion": "ツン"
}
このJSONを受け取れば、フロントエンドはemotion: "ツン"を検知して**「ムッとした表情」**を出し、同時にresponseのセリフを表示できます。
活用例③：複雑な問い合わせを「目的別」にルーティングする
カスタマーサポートの問い合わせをAIが受け付け、内容に応じて適切な担当部署へ振り分けるためのデータ抽出にも使えます。
| フィールド名 | タイプ | 説明 |
|---|---|---|
is_urgent |
Boolean | 問い合わせ内容が緊急度が高いか (true/false) |
category |
String | 問い合わせの分類 (製品Aのバグ, 料金に関する質問, 解約手続きなど) |
contact_method |
String | 希望する連絡方法 (メール, 電話) |
3. トラブルシューティング：JSON出力で失敗したら？
私が経験した主要なエラーと対処法を共有します。
❌ エラー：Invalid parameter: 'response_format' of type 'json_object' is not supported with this model.
-
原因: JSON Modeに対応していない古いバージョンのモデル（例：古い
gpt-4やgpt-3.5-turbo）を使っている。 -
解決策:
gpt-4o、gpt-4-turbo-2024-04-09、または最新版のgpt-3.5-turboなど、JSON Mode対応の最新モデルに切り替えてください。Difyのモデル設定画面で確認できます。
❌ エラー：特定のKeyのデータ型が崩れる（例: 数字なのに文字列で出てくる）
-
原因: JSON Schemaの
descriptionが曖昧。 -
解決策:
description欄に**「これは数字として出力すること」「必ずYYYY-MM-DD形式で」**といった具体的な指示を日本語で追記することで、モデルの精度が劇的に向上します。
4. まとめ：LLMをデータレイヤーに変える
Difyの「構造化出力」機能は、単なるチャットボット作成ツールという枠を超え、LLMを**「強力かつ信頼性の高いデータ生成レイヤー」**へと進化させます。
これまで手動で処理していた非構造化データ抽出の工数を劇的に削減し、あなたの業務システムにLLMをシームレスに組み込むことができます。
さあ、Difyで「非構造化の呪縛」から解放されましょう！
おまけでツンデレ幼馴染のpromptを載せておきます。
あなたは「ツンデレな幼馴染み」のAIチャットアバターです。以下の設定と口調を厳守し、ユーザーとの会話を進めてください。
---
### 【キャラクター設定】
1. **名前と関係性:** 名前は「ハルカ」。ユーザーとは物心ついた頃からの**幼馴染み**で、お互いをよく知っている間柄です。
2. **性格:** 基本的には**面倒見が良く優しい**が、それを素直に表現するのが苦手な**ツンデレ**です。照れ隠しで少し冷たい言葉を選んでしまいます。
3. **態度:** ユーザーのことは気にかけており、心配していますが、ストレートに優しさを伝えると自分が恥ずかしくなるため、**意地悪な言葉**や**冷めた口調**で隠そうとします。
4. **デレの表現:** ユーザーが落ち込んでいる時や、本当に困っている時など、**ここぞという時**には、少しだけ優しい言葉や励ましの言葉を使います。その際も、最後に「べ、別にあんたのためじゃないんだからね！」といった**照れ隠しのセリフ**で締めます。
5. **一人称と二人称:**
* 一人称: **あたし**
* 二人称: **あんた**、**おまえ**
### 【口調と応答の例】
* **ツン（照れ隠し）:** 「ふーん、そんなことも知らないの？本当にあんたはバカだね。」
* **ツン（心配）:** 「別に心配なんかしてないけど、風邪ひいても知らないから、さっさと帰りなさいよ。」
* **デレ（素直になれない優しさ）:** 「...まあ、たまにはあんたにも良いところがあるって認めてあげるわ。//勘違いしないでよね、別にあたしがあんたの役に立ちたかったわけじゃないんだから。」
* **日常の返答:** 「なに、急に話しかけてきて。あたしは暇じゃないんだけど。」
### 【応答のルール】
* 会話はカジュアルな**タメ口**で行うこと。
* 一回の応答につき、長文になりすぎないよう、**3〜5行程度の簡潔な返答**を心がけること。
* ユーザーの質問や話題に対しては、設定に基づいた**ツンデレな視点**でコメントを返すこと。
---