> ## 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. # Agent > LLM に複雑なタスクを自律的に完了させる ⚠️ このドキュメントはAIによって自動翻訳されています。不正確な部分がある場合は、[英語版](/en/use-dify/nodes/agent)を参照してください。 [サンドボックスランタイム](/ja/use-dify/build/runtime#サンドボックスランタイム)では、Agent ノードは LLM に自律的なコマンドライン実行能力を与えます。ツールの呼び出し、スクリプトの実行、内部[ファイルシステム](/ja/use-dify/build/file-system)や外部リソースへのアクセス、マルチモーダル出力の生成が可能です。 これにはトレードオフがあります：レスポンス時間が長くなり、トークン消費も増えます。シンプルなタスクをより速く効率的に処理するには、**[Agent モード](#コマンド実行の有効化（agent-モード）)** をオフにしてこれらの機能を無効にできます。 ## モデルの選択 設定済みのプロバイダーからタスクに最適なモデルを選択します。 選択後、モデルパラメータを調整してレスポンスの生成方法を制御できます。利用可能なパラメータとプリセットはモデルによって異なります。 ## プロンプトの作成 モデルに入力の処理方法とレスポンスの生成方法を指示します。`/` を入力して変数やファイルシステム内のリソースを挿入したり、`@` を入力して [Dify ツール](/ja/use-dify/workspace/tools)を参照したりできます。 必要なリソースがファイルシステムにまだ存在しない場合、**Add files** をクリックしてファイルを直接作成またはアップロードできます。デフォルトの *work* はルートディレクトリです。 新しいファイルを作成する際、拡張子付きのファイル名を入力できます（例：`report.md`）。ファイルは空の状態で作成されます——先にプロンプトで参照し、後からファイルシステムで内容を追加できます。 プロンプトでファイルを追加 どこから始めればよいかわからない場合や、既存のプロンプトを改善したい場合は、AI アシスト付きプロンプトジェネレーターをお試しください。 プロンプトジェネレーターアイコン プロンプトジェネレーターインターフェース ### 指示とメッセージの指定 システム指示を定義し、**メッセージを追加**をクリックしてユーザー/アシスタントメッセージを追加します。すべて順番にプロンプトとしてモデルに送信されます。 モデルと直接会話するイメージです： * **システム指示**はモデルのレスポンスルールを設定します——役割、トーン、行動ガイドライン。 * **ユーザーメッセージ**はモデルに送信する内容——質問、リクエスト、タスク。 * **アシスタントメッセージ**はモデルのレスポンスです。 ### 入力とルールの分離 システム指示で役割とルールを定義し、ユーザーメッセージで実際のタスク入力を渡します。例： ```bash wrap theme={null} # システム指示 あなたは子ども向けの物語作家です。ユーザーの入力に基づいて物語を書いてください。簡単な言葉と温かいトーンを使ってください。 # ユーザーメッセージ ウサギと恥ずかしがり屋のハリネズミが友達になる、おやすみ前のお話を書いてください。 ``` すべてをシステム指示にまとめる方が簡単に見えるかもしれませんが、役割定義とタスク入力を分離することで、モデルにとってより明確な構造になります。 ### 対話履歴のシミュレーション アシスタントメッセージがモデルのレスポンスなら、なぜ手動で追加するのか疑問に思うかもしれません。 ユーザーメッセージとアシスタントメッセージを交互に追加することで、プロンプト内に対話履歴をシミュレーションできます。モデルはこれらを過去のやり取りとして扱い、動作の誘導に役立ちます。 ### 上流 LLM からの対話履歴のインポート **対話履歴の追加**をクリックして、上流の Agent ノードから対話履歴をインポートします。これによりモデルは上流で何が起こったかを把握し、そのノードが中断したところから続けることができます。 対話履歴には**ユーザー**メッセージ、**アシスタント**メッセージ、**ツール**メッセージが含まれます。Agent ノードの `context` 出力変数で確認できます。 システム指示はノード固有のため含まれません。 複数の Agent ノードを連結する場合に有用です： * 対話履歴をインポートしない場合、下流ノードは上流ノードの最終出力のみを受け取り、それがどのように導き出されたかはわかりません。 * 対話履歴をインポートすると、プロセス全体が見えます：ユーザーが何を質問したか、どのツールが呼び出されたか、どのような結果が返されたか、モデルがどのように推論したか。 **自動追加されるユーザーメッセージで新しいタスクを指定してください。** インポートされた履歴は現在のノードのメッセージの前に追加されるため、モデルはこれを1つの連続した会話として認識します。インポートされた履歴は通常アシスタントメッセージで終わるため、モデルは次に何をすべきかを知るためのフォローアップユーザーメッセージが必要です。 2つの Agent ノードが順番に実行されるとします：Agent A はデータを分析してチャート画像を生成し、サンドボックスの出力フォルダーに保存します。Agent B はこれらのチャートを含む最終レポートを作成します。 Agent B が Agent A の最終テキスト出力のみを受け取る場合、分析結論はわかりますが、どのファイルが生成されどこに保存されているかはわかりません。 Agent A の対話履歴をインポートすることで、Agent B はツールメッセージから正確なファイルパスを確認でき、チャートをレポートに埋め込むことができます。 Agent A の対話履歴インポート後に Agent B が受け取る完全なメッセージシーケンス： ```bash wrap theme={null} # Agent B のシステム指示 1. System: "あなたはレポートデザイナーです。ビジュアルを埋め込んだプロフェッショナルなレポートを作成してください。" # Agent A から 2. User: "Q3 の売上データを分析し、可視化を作成してください。" # Agent A から 3. Tool: [bash] 棒グラフを作成：/output/q3_sales_by_region.png 4. Tool: [bash] トレンドラインを作成：/output/q3_monthly_trend.png # Agent A から 5. Assistant: "Q3 の売上データを分析し、2つのチャートを作成しました..." # Agent B のユーザーメッセージ 6. User: "生成されたチャートを含む PDF レポートを作成してください。" ``` Agent A の対話履歴をインポートすることで、Agent 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 テンプレートを使えば、定義された条件に合致する指示のみが送信されるため、動作が予測可能になり、トークンの使用量も削減されます。 ## コマンド実行の有効化（Agent モード） **Agent モード**をオンにすると、モデルが組み込みの bash ツールを使ってサンドボックスランタイムでコマンドラインを実行できるようになります。 これはすべての高度な機能の基盤です：モデルが他のツールを呼び出す、ファイル操作を行う、スクリプトを実行する、外部リソースにアクセスする——これらすべては bash ツールを呼び出して基盤となるコマンドラインを実行することで行われます。 これらの機能が不要なシンプルなタスクでは、**Agent モード**をオフにすることで、より高速なレスポンスと低いトークンコストを実現できます。 **最大イテレーション回数の調整** **高度な設定**の**最大イテレーション回数**は、モデルが1つのリクエストに対して推論-行動サイクル（思考、ツール呼び出し、結果処理）を繰り返す回数を制限します。 複数のツール呼び出しを必要とする複雑なマルチステップタスクでは、この値を増やしてください。値が大きいほどレイテンシとトークンコストが増加します。 ## 対話メモリの有効化（チャットフローのみ） メモリはこのノード内でのみ有効です。異なる会話間では保持されません。 **メモリ**を有効にすると最近の対話が保持され、LLM がフォローアップの質問に一貫して回答できるようになります。 現在のユーザークエリとアップロードされたファイルを渡すためのユーザーメッセージが自動的に追加されます。これはメモリが最近のユーザー-アシスタント間のやり取りを保存することで機能するためです。ユーザークエリがユーザーメッセージを通じて渡されないと、ユーザー側で記録するものがなくなります。 **ウィンドウサイズ**は保持する最近のやり取り数を制御します。例えば `5` は、直近の5組のユーザークエリと LLM レスポンスを保持します。 ## コンテキストの追加 **高度な設定** > **コンテキスト**で、LLM に追加の参照情報を提供し、ハルシネーションを減らしてレスポンスの精度を向上させます。 一般的なパターン：ナレッジ検索ノードから[検索結果を渡す](/ja/use-dify/nodes/knowledge-retrieval#llm-ノードとの連携)ことで、検索拡張生成（RAG）を実現します。 ## マルチモーダル入力の処理 マルチモーダル対応モデルに画像、音声、動画、ドキュメントを処理させるには、以下のいずれかの方法を選択します： * プロンプトでファイル変数を直接参照する。 * **高度な設定**で **Vision** を有効にし、ファイル変数を選択する。 **解像度**は画像処理の詳細レベルのみを制御します： * **高**：複雑な画像でより高精度だが、より多くのトークンを使用 * **低**：シンプルな画像でより高速、より少ないトークンで処理 マルチモーダル機能を持たないモデルの場合は、[サンドボックスへのファイルアップロード](/ja/use-dify/nodes/upload-file-to-sandbox)ノードでファイルをサンドボックスにアップロードします。Agent ノードがコマンドラインを実行してツールのインストールやスクリプトの実行を行い、モデルがネイティブに処理できないファイル形式も処理できます。 ## 思考プロセスとツール呼び出しをレスポンスから分離 モデルの思考プロセスやツール呼び出しを含まないクリーンなレスポンスを取得するには、`generations.content` 出力変数を使用します。 `generations` 変数自体にはすべての中間ステップと最終レスポンスが含まれます。 ## 下流ノードに適した出力変数の選択 * **`generations`** — すべてが必要な場合：最終レスポンス、思考プロセス、ツール呼び出し、生成されたアーティファクト。 * **`generations.content`** — クリーンなレスポンスのみが必要な場合。 * **`files`** — 生成されたアーティファクトのみが必要な場合。 ## 構造化出力の強制 指示で出力形式を記述しても、一貫性のない結果が生じることがあります。より信頼性の高いフォーマットを実現するには、構造化出力を有効にして定義済みの JSON スキーマを強制します。 ネイティブ JSON をサポートしないモデルの場合、Dify はスキーマをプロンプトに含めますが、厳密な遵守は保証されません。 構造化出力 1. **出力変数**の横で**構造化**をオンにします。出力変数リストの末尾に `structured_output` 変数が表示されます。 2. **設定**をクリックし、以下のいずれかの方法で出力スキーマを定義します。 * **ビジュアルエディター**：ノーコードインターフェースでシンプルな構造を定義。対応する JSON スキーマが自動生成されます。 * **JSON Schema**：ネストされたオブジェクト、配列、バリデーションルールを含む複雑な構造のスキーマを直接記述。 * **AI 生成**：自然言語でニーズを記述し、AI にスキーマを生成させる。 * **JSON インポート**：既存の JSON オブジェクトを貼り付けて、対応するスキーマを自動生成。 ## エラー処理 一時的な問題（ネットワークの不具合など）に対する自動リトライ、またはエラーが続く場合にワークフローの実行を継続するための代替エラー処理戦略を設定します。 エラー処理 クラシックランタイムでは、Agent ノードは LLM にツールの自律的な制御権を与え、どのツールをいつ使用するかを反復的に判断できるようにします。Agent はすべてのステップを事前に計画するのではなく、問題を動的に推論し、必要に応じてツールを呼び出して複雑なタスクを完了します。 Agent node interface ## Agent 戦略 Agent 戦略は Agent の思考と行動の方法を定義します。モデルの能力とタスクの要件に最も適したアプローチを選択してください。 Agent strategies selection LLM のネイティブな Function Calling 機能を使用し、tools パラメータを通じてツール定義を直接渡します。LLM は組み込みメカニズムを使って、いつどのようにツールを呼び出すかを判断します。 GPT-4、Claude 3.5 など、強力な Function Calling サポートを持つモデルに最適です。 構造化されたプロンプトを使い、LLM を明示的な推論ステップに導きます。**思考 → 行動 → 観察**のサイクルに従い、透明な意思決定を行います。 ネイティブな Function Calling 機能を持たないモデルや、明示的な推論トレースが必要な場合に適しています。 **マーケットプレイス → Agent 戦略**から追加の戦略をインストールするか、[コミュニティリポジトリ](https://github.com/langgenius/dify-plugins)にカスタム戦略を提供してください。 Function calling setup ## 設定 ### モデル選択 選択した Agent 戦略をサポートする LLM を選択します。より高性能なモデルは複雑な推論をより良く処理しますが、イテレーションあたりのコストが高くなります。Function Calling 戦略を使用する場合は、モデルが Function Calling をサポートしていることを確認してください。 ### ツール設定 Agent がアクセスできるツールを設定します。各ツールには以下が必要です： **認証** - ワークスペースで設定された外部サービスの API キーと認証情報 **説明** - ツールの機能と使用タイミングの明確な説明（これが Agent の意思決定を導きます） **パラメータ** - 適切なバリデーションを伴う必須およびオプションの入力 ### 指示とコンテキスト 自然言語の指示で Agent の役割、目標、コンテキストを定義します。上流のワークフローノードから変数を参照するには Jinja2 構文を使用します。 **クエリ**は Agent が処理すべきユーザー入力またはタスクを指定します。以前のワークフローノードからの動的コンテンツを使用できます。 Agent configuration interface ### 実行制御 **最大イテレーション回数**は無限ループを防ぐための安全上限を設定します。タスクの複雑さに応じて設定してください——シンプルなタスクは3〜5回、複雑な調査は10〜15回が目安です。 **メモリ**は TokenBufferMemory を使って Agent が記憶する過去のメッセージ数を制御します。メモリウィンドウを大きくするとコンテキストが増えますが、トークンコストも増加します。これにより、ユーザーが以前のアクションを参照できる会話の連続性が実現します。 ### ツールパラメータの自動生成 ツールには**自動生成**または**手動入力**として設定されたパラメータがあります。自動生成パラメータ（`auto: false`）は Agent が自動的に設定し、手動入力パラメータはツールの永続設定の一部となる明示的な値が必要です。