Dify Agent で外部ツールを呼び出す：天気クエリを例にツール定義から呼び出しまでの完全なパイプラインを解説

多くの企業シナリオにおいて、ユーザーが本当に必要としているのは単に「AI と対話する」ことではなく、「AI が外部の能力を使ってアクションを完了する」ことです。

これこそが Agent の価値が発揮される場面です。

通常の Q&A アプリケーションとは異なり、Agent の重点は一つの回答を生成することだけでなく、タスク完了に向けた完全なパイプラインを展開することです。

ユーザーの意図を理解する
ツール呼び出しが必要かどうか判断する
正しいツールを選択する
呼び出しパラメータを組み立てる
ツールからの返却結果を受け取る
結果に基づいて最終的な返答を生成する

このパイプラインを説明しやすくするために、天気クエリは非常に典型的な例です。十分にシンプルでありながら、Agent が外部ツールを呼び出す際の最も核心的な能力構造を完全にカバーしています。

一、「ツール呼び出し」とは何か

ツール呼び出しとは、モデルが自身では信頼性のある回答ができないと判断した場合に、外部の能力を通じて情報を取得し、その結果を最終出力として組織することと理解できます。

天気クエリを例にすると、典型的なフローは以下の通りです。

ユーザー：今日の東京の天気はどうですか？
→ Agent の判断：リアルタイム情報が必要な質問である
→ 天気 API を呼び出す
→ 気温、天気状態、風力、降水確率を取得する
→ 最終回答を生成する

つまり、重要なのはモデルが「天気を知っているかどうか」ではなく、モデルが「いつ天気を確認しなければならないかを知っているかどうか」です。

二、Dify Agent でよく使われる二つの戦略

Dify の Agent シナリオにおいて、ツール呼び出しは通常二つの方式を中心に展開されます。

ReAct：モデルが「思考 → 行動 → 観察」のサイクルで段階的に次のステップを決定する
Function Calling：モデルがツール名とパラメータを直接出力し、構造化された形で呼び出しを発行する

ReAct がより適する状況

タスク目標が比較的オープン
マルチステップの推論が必要
思考プロセスと呼び出しパスを観察したい
複雑な行動チェーンのデバッグが必要

Function Calling がより適する状況

タスク構造が明確
ツール呼び出しパスが安定している
応答速度とパラメータ精度への要求がより高い
出力フォーマットに構造化が求められる

天気クエリのようなタスクでは、Function Calling がより直接的であることが多いです。一方、「天気、交通、スケジュールを組み合わせて外出の提案を行う」ようなよりオープンなタスクでは、ReAct の柔軟性がより高くなります。

三、なぜ天気クエリは典型的な Agent シナリオなのか

天気クエリは標準的な Agent シナリオのすべての特徴を備えています。

問題がリアルタイムデータに依存する
外部 API の呼び出しが必要
パラメータ構造が明確。例：都市と日付
返却結果が構造化されている。例：気温、天気状態、降水確率
最終結果に自然言語での表現が必要であり、生の JSON ではない

したがって、天気クエリは単なるシンプルな例ではなく、Agent のツール呼び出しの全パイプラインを理解するための最も適した入門ケースの一つです。

四、第一ステップ：ツール能力を定義する

Dify Agent において、ツールは本質的にモデルが呼び出せる外部能力です。

天気クエリを例にすると、ツールを定義する際には少なくとも以下の三項目を明確にする必要があります。

1. ツール名

例えば：

get_weather
query_weather

名称はできるだけ明確にし、モデルが用途を理解しやすいようにすべきです。

2. ツールの説明

例えば：

指定された都市の指定日の天気情報を照会するために使用する
天気状態、気温、湿度、風力、降水確率を返す

説明の品質はモデルが使用シナリオを正しく判断できるかどうかに直接影響するため、あまりに汎用的な記述は避けるべきです。

3. 入力パラメータ

天気クエリで最も一般的なパラメータは以下の通りです。

city：都市名
date：日付
unit：温度単位（任意）

企業シナリオでは、パラメータ定義が明確であるほど、呼び出しの安定性は通常より高くなります。

五、第二ステップ：外部天気 API に接続する

ツール定義が完了したら、次のステップは実際にデータを提供する外部サービスに接続することです。

一般的な接続方法は以下の通りです。

公開天気 API を使用する
企業内部の中間サービスを呼び出す
HTTP リクエストでサードパーティの天気インターフェースにアクセスする

このステップの重点は API 自体の複雑さではなく、入出力構造が十分に安定していることを保証することです。

理想的な返却構造は通常以下のようになります。

{
  "city": "東京",
  "date": "2026-04-12",
  "condition": "曇り",
  "temperature_min": 14,
  "temperature_max": 22,
  "rain_probability": "30%",
  "wind": "北東の風 3級"
}

Agent にとって、返却構造が明確であるほど、後続の生成結果はより安定します。

六、第三ステップ：Agent に「いつツールを呼び出すべきか」を学ばせる

実践では、このステップが過小評価されることがよくあります。

多くのチームは「ツールが接続できたかどうか」に重点を置きますが、体験を真に決定するのは、通常モデルが以下を理解しているかどうかです。

どの種類の質問で天気ツールを呼び出す必要があるか
どの種類の質問は既存のコンテキストで直接回答できるか
パラメータが不完全な場合、先に確認すべきか

基本的な制約の例

システムプロンプトに以下のようなルールを追加できます。

ユーザーが天気、気温、降雨、風力、服装の適切さ、外出の適否など天気に関連する質問をした場合、直接回答するのではなく、天気ツールを優先的に呼び出してください。
都市や日付が不足している場合は、先にユーザーに確認してください。

この目的は、リアルタイム情報シナリオにおけるモデルの主観的な推測を減らすことです。

七、第四ステップ：不完全な入力を処理する

実際のユーザーの入力は常に完全であるとは限りません。例えば：

「今日は外出に適していますか？」
「東京の天気は？」
「明日大阪は雨が降りますか？」

このような場合、Agent には二つの基本的な能力が必要です。

1. 推測可能な情報の自動補完

例えば「今日」は現在の日付として解析できます。

2. 欠落パラメータの能動的な確認

ユーザーが「天気はどうですか」とだけ言い、都市を指定しなかった場合、優先的に確認すべきです。

「どの都市の天気を照会しますか？」

この能力は非常に重要です。なぜなら、Agent が利用可能なシステムとして振る舞うか、たまにツール呼び出しが成功するデモプロトタイプに過ぎないかを直接決定するからです。

八、第五ステップ：構造化された結果を実用的な回答に変換する

ツールが返すのは構造化データですが、ユーザーが本当に必要としているのは実行可能で理解しやすい結論です。

例えば、ユーザーが以下のように質問した場合：

「明日東京で傘は必要ですか？」

Agent は生の JSON を機械的に復唱するのではなく、以下のような結果を出力するのがより適切です。

明日の東京は曇りのち小雨、最高気温 21℃、降水確率 60%、雨具の携帯をお勧めします。

さらに、よりシナリオに即した表現も生成できます。

明日屋外の予定がある場合は、短時間の降雨に備えて折りたたみ傘をご用意ください。

これが Agent と通常の API 呼び出しの核心的な違いでもあります。ツールがデータ取得を担当し、モデルが解釈と表現を担当する。

九、なぜ天気クエリは Function Calling により適しているのか

天気クエリが特に Function Calling に適している理由は、以下の特徴を満たしているからです。

呼び出し対象が明確
パラメータ構造が安定
返却値の構造が明確
長いチェーンの推論が不要

ReAct と比較して、通常三つの明確な利点があります。

応答が速い
不必要な思考テキストの生成を削減できる。
パラメータがより安定
要件を満たす構造化された呼び出しパラメータを出力しやすい。
コストがより低い
余分なトークン消費を削減できる。

したがって、Agent のタスクが主に「天気を調べる、在庫を調べる、注文を調べる、価格を調べる」といった標準的なアクションである場合、Function Calling が通常より適切な第一選択となります。

十、天気クエリから企業シナリオへの拡張

天気クエリは教育的なケースに過ぎませんが、その背後には実際には一連の企業シナリオが対応しています。

在庫照会
チケットステータス照会
注文進捗照会
顧客情報照会
会議室予約状況照会
経費承認ステータス照会

これらの問題と天気クエリには一つの共通点があります。

モデルに回答を憶測で生成させるのではなく、モデルにまずデータ取得能力を呼び出させ、その後結果を組織させること。

天気クエリのパイプラインが明確に構築されれば、企業は通常同じパターンをより多くの社内ビジネスシステムに移植できます。

十一、推奨する設計原則

Agent のツール呼び出し設計において、非常に実用的な原則は以下の通りです。

ツールはできるだけ構造化し、モデルの推測はできるだけ少なくする。

具体的には、以下を可能な限り実現すべきです。

ツールの説明が明確
パラメータ定義が明確
返却フィールドが明確
リアルタイム情報シナリオでは「ツール呼び出し必須」を明確に要求する
パラメータ欠落シナリオでは「先に確認してから呼び出す」を明確に要求する

このような基本設計は、単にモデルを入れ替えるよりもシステムの信頼性を向上させることが多いです。

まとめ

天気クエリを例にすると、Dify Agent による外部ツール呼び出しの完全なパイプラインは以下のように明確に分解できます。

ツールを定義する
API に接続する
呼び出しタイミングを制約する
パラメータ補完を処理する
結果をユーザーが理解できる回答に組織する

このパイプラインの本質は、モデルを何でも知っている万能な存在にすることではなく、適切なタイミングで外部の能力を呼び出せるようにすることです。

企業にとって、この能力は「より上手にチャットする」ことより重要であることが多いです。なぜなら、実際のビジネスにおいてより一般的なニーズは「より美しい文章を書くこと」ではなく、以下だからです。

調べて、取得して、判断して、そして結果を直接使える出力に整理してほしい。

これこそが Dify Agent とツール呼び出しの最も注目すべき価値です。

Keyboard shortcuts

MKC — Dify Japan コンテンツ体系