> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dify.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# LLM
> テキスト生成と分析のための言語モデルを起動
> このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、[英語版](/en/cloud/use-dify/nodes/llm) を参照してください。
LLM ノードは大規模言語モデルを呼び出してテキスト、画像、ドキュメントを処理します。設定されたモデルにプロンプトを送信し、その応答を取得します。構造化出力、コンテキスト管理、マルチモーダル入力をサポートしています。
LLM ノードを使用する前に、**統合** > **モデルプロバイダー** で少なくとも 1 つのモデルプロバイダーを設定してください。
## モデル選択とパラメータ
設定したモデルプロバイダーから任意のモデルを選択できます。異なるモデルはそれぞれ異なるタスクに適しています。GPT-4 と Claude 3.5 は複雑な推論を得意としますがコストが高く、GPT-3.5 Turbo は機能と価格のバランスが取れています。
モデルパラメータは応答生成を制御します。**温度** は 0（決定的）から 1（創造的）の範囲です。**Top P** は確率によって単語選択を制限します。**頻度ペナルティ** は繰り返しを減らします。**存在ペナルティ** は新しいトピックを促進します。プリセットも使用できます：**精密**、**バランス**、**創造的**。
## プロンプト設定
インターフェースはモデルタイプに基づいて適応します。チャットモデルではメッセージロール（**システム** は動作用、**ユーザー** は入力用、**アシスタント** は例用）を使用し、補完モデルでは単純なテキスト継続を使用します。
プロンプト内でワークフロー変数を二重中括弧で参照します：`{{variable_name}}`。変数はモデルに到達する前に実際の値で置き換えられます。
```text theme={null}
System: あなたは技術文書の専門家です。
User: {{user_input}}
```
## コンテキスト変数
コンテキスト変数はソース帰属を保持しながら外部知識を注入します。これにより、大規模言語モデルがあなたの特定のドキュメントを使用して質問に答える RAG アプリケーションが可能になります。
知識検索ノードの出力を LLM ノードのコンテキスト入力に接続し、次のように参照します：
```text theme={null}
このコンテキストのみを使用して回答してください：
{{knowledge_retrieval.result}}
質問：{{user_question}}
```
知識検索からのコンテキスト変数を使用する場合、Dify は自動的に引用を追跡するため、ユーザーは情報源を確認できます。
## 構造化出力
プログラムで使用するために、JSON などの特定のデータ形式での応答をモデルに強制します。3 つの方法で設定できます：
シンプルな構造のためのユーザーフレンドリーなインターフェース。名前とタイプでフィールドを追加し、必須フィールドをマークし、説明を設定します。エディターは自動的に JSON スキーマを生成します。
ネストされたオブジェクト、配列、検証ルールを含む複雑な構造のためにスキーマを直接記述します。
```json theme={null}
{
"type": "object",
"properties": {
"sentiment": {
"type": "string",
"enum": ["positive", "negative", "neutral"]
}
},
"required": ["sentiment"]
}
```
平易な言語でニーズを説明し、AI にスキーマを生成させます。
ネイティブ JSON 対応のモデルは構造化出力を確実に処理します。その他のモデルについては、Dify がプロンプトにスキーマを含めますが、結果は異なる場合があります。
## メモリとファイル処理
メモリを有効にすると、チャットフロー会話内の複数の LLM 呼び出しでコンテキストを維持できます。有効にすると、以前のインタラクションがフォーマットされたユーザー - アシスタント出力として後続のプロンプトに含まれます。`USER`テンプレートを編集することで、ユーザープロンプトに入力される内容をカスタマイズできます。メモリはノード固有であり、異なる会話間では持続しません。
**ファイル処理** では、マルチモーダルモデル用にプロンプトにファイル変数を追加します。GPT-4V は画像を、Claude は PDF を直接処理しますが、他のモデルでは前処理が必要な場合があります。
### ビジョン機能設定
画像を処理する際、詳細レベルを制御できます：
* **高詳細** - 複雑な画像でより良い精度を提供しますが、より多くのトークンを使用します
* **低詳細** - シンプルな画像でより少ないトークンでより高速な処理
ビジョン機能のデフォルト変数セレクターは`userinput.files`で、ユーザー入力ノードからファイルを自動的に取得します。
## Jinja2 テンプレートサポート
LLM プロンプトは高度な変数処理のために Jinja2 テンプレートをサポートしています。Jinja2 モード（`edition_type: "jinja2"`）を使用すると、次のことができます：
```jinja theme={null}
{% for item in search_results %}
{{ loop.index }}. {{ item.title }}: {{ item.content }}
{% endfor %}
```
Jinja2 変数は通常の変数置換とは別に処理され、プロンプト内でループ、条件文、複雑なデータ変換が可能になります。
## ストリーミング出力
LLM ノードはデフォルトでストリーミング出力をサポートしています。各テキストチャンクは`RunStreamChunkEvent`として生成され、リアルタイムの応答表示が可能になります。ファイル出力（画像、ドキュメント）はストリーミング中に自動的に処理され保存されます。
## 回答からの推論の分離
一部の推論モデルは、思考を `...` タグで囲みます。デフォルトでは、これらのタグは `text` 出力に含まれるため、推論は回答とともに下流のノードへ流れます。
**推論タグの分離を有効にする** トグルをオンにすると、`text` 出力には回答のみが残り、思考は独立した `reasoning_content` 出力変数に格納されます。トグルがオフの場合、`reasoning_content` は空のままです。
API 呼び出しでは、このトグルは `reasoning_format` パラメータとして現れます。トグルがオンのとき、`reasoning_format` は `separated` になります。すると、ストリーミング API クライアントは推論を回答ストリームとは別の `reasoning_chunk` イベントとして受け取ります。イベントの詳細は [チャットメッセージを送信](/api-reference/チャットフロー/チャットメッセージを送信) と [ワークフローを実行](/api-reference/ワークフロー/ワークフローを実行) を参照してください。
この設定は、推論を `` タグで囲むモデルにのみ影響します。
## エラーハンドリング
失敗した LLM 呼び出しのリトライ動作を設定します。最大リトライ回数、リトライ間隔、バックオフ乗数を設定します。リトライが十分でない場合のデフォルト値、エラールーティング、代替モデルなどのフォールバック戦略を定義します。