> ## Documentation Index
> Fetch the complete documentation index at: https://dify-6c0370d8-add-new-agent.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# LLM
> 大規模言語モデルを呼び出し、テキスト生成・分析、ツールによる複雑なタスクの実行を行う
⚠️ このドキュメントはAIによって自動翻訳されています。不正確な部分がある場合は、[英語版](/en/use-dify/nodes/llm)を参照してください。
LLM ノードは大規模言語モデルを呼び出し、指示と上流ノードからの入力に基づいてレスポンスを生成します。
## モデルの選択
設定済みのプロバイダーからタスクに最適なモデルを選択します。
選択後、モデルパラメータを調整してレスポンスの生成方法を制御できます。利用可能なパラメータとプリセットはモデルによって異なります。
## プロンプトの作成
モデルに入力の処理方法とレスポンスの生成方法を指示します。`/` または `{` を入力して変数を参照できます。
どこから始めればよいかわからない場合や、既存のプロンプトを改善したい場合は、AI アシスト付きプロンプトジェネレーターをお試しください。
### 指示とメッセージの指定
システム指示を定義し、**メッセージを追加**をクリックしてユーザー/アシスタントメッセージを追加します。すべて順番にプロンプトとしてモデルに送信されます。
モデルと直接会話するイメージです：
* **システム指示**はモデルのレスポンスルールを設定します——役割、トーン、行動ガイドライン。
* **ユーザーメッセージ**はモデルに送信する内容——質問、リクエスト、タスク。
* **アシスタントメッセージ**はモデルのレスポンスです。
### 入力とルールの分離
システム指示で役割とルールを定義し、ユーザーメッセージで実際のタスク入力を渡します。例：
```bash wrap theme={null}
# システム指示
あなたは子ども向けの物語作家です。ユーザーの入力に基づいて物語を書いてください。簡単な言葉と温かいトーンを使ってください。
# ユーザーメッセージ
ウサギと恥ずかしがり屋のハリネズミが友達になる、おやすみ前のお話を書いてください。
```
すべてをシステム指示にまとめる方が簡単に見えるかもしれませんが、役割定義とタスク入力を分離することで、モデルにとってより明確な構造になります。
### 対話履歴のシミュレーション
アシスタントメッセージがモデルのレスポンスなら、なぜ手動で追加するのか疑問に思うかもしれません。
ユーザーメッセージとアシスタントメッセージを交互に追加することで、プロンプト内に対話履歴をシミュレーションできます。モデルはこれらを過去のやり取りとして扱い、動作の誘導に役立ちます。
### 上流 LLM からの対話履歴のインポート
**対話履歴の追加**をクリックして、上流の Agent または LLM ノードから対話履歴をインポートします。これによりモデルは上流で何が起こったかを把握し、そのノードが中断したところから続けることができます。
対話履歴には**ユーザー**メッセージ、**アシスタント**メッセージ、**ツール**メッセージが含まれます。Agent または LLM ノードの `context` 出力変数で確認できます。
システム指示はノード固有のため含まれません。
複数の Agent または LLM ノードを連結する場合に有用です：
* 対話履歴をインポートしない場合、下流ノードは上流ノードの最終出力のみを受け取り、それがどのように導き出されたかはわかりません。
* 対話履歴をインポートすると、プロセス全体が見えます：ユーザーが何を質問したか、どのツールが呼び出されたか、どのような結果が返されたか、モデルがどのように推論したか。
**自動追加されるユーザーメッセージで新しいタスクを指定してください。** インポートされた履歴は現在のノードのメッセージの前に追加されるため、モデルはこれを1つの連続した会話として認識します。インポートされた履歴は通常アシスタントメッセージで終わるため、モデルは次に何をすべきかを知るためのフォローアップユーザーメッセージが必要です。
2つの LLM ノードが順番に実行されるとします：LLM A は検索ツールを呼び出してトピックを調査し、LLM B は調査結果に基づいてレポートを作成します。
LLM B が LLM A の最終テキスト出力のみを受け取る場合、結論を要約できますが、検証や具体的なソースの引用はできません。LLM A の対話履歴をインポートすることで、LLM B は各ツール呼び出しの生データを確認し、レポートで直接参照できます。
LLM A の対話履歴インポート後に LLM B が受け取る完全なメッセージシーケンス：
```bash wrap theme={null}
# LLM B のシステム指示
1. System: "あなたはプロフェッショナルなレポートライターです..."
# LLM A から
2. User: "EV 市場の新しいトレンドは何ですか？"
# LLM A から
3. Tool: [URL と生データを含む検索結果]
# LLM A から
4. Assistant: "検索結果に基づくと、主なトレンドは..."
# LLM B のユーザーメッセージ
5. User: "500語の市場分析レポートを作成してください。"
```
LLM B は次のことを理解します：調査プロセス（質問、検索、要約）を見た上で、テキスト出力だけでは得られない生データを含め、その情報に基づいてレポートを作成する必要があるということです。
### Jinja2 を使った動的プロンプトの作成
[Jinja2](https://jinja.palletsprojects.com/en/stable/) 構文で動的プロンプトを作成できます。例えば、条件分岐を使って変数の値に応じた指示をカスタマイズできます。
```jinja2 wrap theme={null}
あなたは
{% if user_level == "beginner" %}忍耐強く親切な
{% elif user_level == "intermediate" %}プロフェッショナルで効率的な
{% else %}シニアエキスパートレベルの
{% endif %} アシスタントです。
{% if user_level == "beginner" %}
わかりやすい言葉で説明してください。必要に応じて例を示してください。専門用語は避けてください。
{% elif user_level == "intermediate" %} 一部の専門用語を使用できますが、適切な説明を付けてください。実践的なアドバイスとベストプラクティスを提供してください。
{% else %} 技術的な詳細に踏み込み、専門用語を使用してください。高度なユースケースと最適化ソリューションに焦点を当ててください。
{% endif %}
```
デフォルトでは、すべての可能な指示をモデルに送信し、条件を説明し、どれに従うかをモデルに判断させる必要がありますが、この方法は必ずしも信頼できるとは限りません。
Jinja2 テンプレートを使えば、定義された条件に合致する指示のみが送信されるため、動作が予測可能になり、トークンの使用量も削減されます。
## コンテキストの追加
**高度な設定** > **コンテキスト**で、LLM に追加の参照情報を提供し、ハルシネーションを減らしてレスポンスの精度を向上させます。
一般的なパターン：ナレッジ検索ノードから[検索結果を渡す](/ja/use-dify/nodes/knowledge-retrieval#llm-ノードとの連携)ことで、検索拡張生成（RAG）を実現します。
## 対話メモリの有効化（チャットフローのみ）
メモリはこのノード内でのみ有効です。異なる会話間では保持されません。
**メモリ**を有効にすると最近の対話が保持され、LLM がフォローアップの質問に一貫して回答できるようになります。
現在のユーザークエリとアップロードされたファイルを渡すためのユーザーメッセージが自動的に追加されます。これはメモリが最近のユーザー-アシスタント間のやり取りを保存することで機能するためです。ユーザークエリがユーザーメッセージを通じて渡されないと、ユーザー側で記録するものがなくなります。
**ウィンドウサイズ**は保持する最近のやり取り数を制御します。例えば `5` は、直近の5組のユーザークエリと LLM レスポンスを保持します。
## Dify ツールの利用
Tool Call タグが付いたモデルのみが Dify ツールを利用できます。
[Dify ツール](/ja/use-dify/workspace/tools)を追加して、モデルが外部サービスや API と連携できるようにします。ウェブ検索やデータベースクエリなど、リアルタイムデータやテキスト生成を超えるアクションが必要なタスクに有用です。
追加したツールは無効化・削除でき、設定も変更できます。より明確なツール説明により、モデルがツールの使用タイミングを適切に判断できます。
**最大イテレーション回数の調整**
**高度な設定**の**最大イテレーション回数**は、モデルが1つのリクエストに対して推論-行動サイクル（思考、ツール呼び出し、結果処理）を繰り返す回数を制限します。
複数のツール呼び出しを必要とする複雑なマルチステップタスクでは、この値を増やしてください。値が大きいほどレイテンシとトークンコストが増加します。
## マルチモーダル入力の処理
*マルチモーダル対応*モデルに画像、音声、動画、ドキュメントを処理させるには、以下のいずれかの方法を選択します：
* プロンプトでファイル変数を直接参照する。
* **高度な設定**で **Vision** を有効にし、ファイル変数を選択する。
**解像度**は画像処理の詳細レベルのみを制御します：
* **高**：複雑な画像でより高精度だが、より多くのトークンを使用
* **低**：シンプルな画像でより高速、より少ないトークンで処理
## 思考プロセスとツール呼び出しをレスポンスから分離
モデルの思考プロセスやツール呼び出し（もしあれば）を含まないクリーンなレスポンスを取得するには、`text` 出力変数（**推論タグ分離を有効化**をオンにした状態）または `generation.content` を参照します。
`generations` 変数自体にはすべての中間ステップと最終レスポンスが含まれます。
## 構造化出力の強制
指示で出力形式を記述しても、一貫性のない結果が生じることがあります。より信頼性の高いフォーマットを実現するには、構造化出力を有効にして定義済みの JSON スキーマを強制します。
ネイティブ JSON をサポートしないモデルの場合、Dify はスキーマをプロンプトに含めますが、厳密な遵守は保証されません。
1. **出力変数**の横で**構造化**をオンにします。出力変数リストの末尾に `structured_output` 変数が表示されます。
2. **設定**をクリックし、以下のいずれかの方法で出力スキーマを定義します。
* **ビジュアルエディター**：ノーコードインターフェースでシンプルな構造を定義。対応する JSON スキーマが自動生成されます。
* **JSON Schema**：ネストされたオブジェクト、配列、バリデーションルールを含む複雑な構造のスキーマを直接記述。
* **AI 生成**：自然言語でニーズを記述し、AI にスキーマを生成させる。
* **JSON インポート**：既存の JSON オブジェクトを貼り付けて、対応するスキーマを自動生成。
## エラー処理
一時的な問題（ネットワークの不具合など）に対する自動リトライ、またはエラーが続く場合にワークフローの実行を継続するための代替エラー処理戦略を設定します。
