ツールとFunction Calling

ツールは、モデルの外で行う処理を接続する部品

モデルは、与えられた情報から文章や要求を生成できます。一方、最新の残日数を勤怠システムから取得することや、申請データを保存することには、外部の処理が必要です。その処理をモデルが利用できる機能として表したものがツールです。

第3節で、関数は名前を付けた処理、引数は渡す条件、戻り値は受け取る結果と説明しました。LangChainでは、関数に@toolという目印を付けて、ツールとして定義する方法などがあります。名前や説明、引数の形を、モデルが利用方法を判断するための情報にできます。

モデルへ機能の使い方を伝えることと、関数を実際に動かすことは別です。たとえば規程検索なら、「何を渡せば何が返るか」をモデルへ伝え、実際の検索はアプリケーションの処理が行います。この区別が、Function Callingとツールの説明をつなぎます。

関数の中身より先に、使い方の説明が必要になる

たとえばsearch_policyというツールなら、説明に「社内規程から、問い合わせに関連する条項を検索する」と書けます。入力は検索する質問、出力は本文と出典の一覧です。この説明が「情報を探す」だけでは、何を探せて何を探せないのか、モデルに伝わりにくくなります。

同じ検索でも、規程検索と、利用者本人の申請状況の照会は別の仕事です。ツールを分け、説明を具体的にすることで、モデルが目的に合う機能を選びやすくなります。処理が正しく実装されていても、その使い道の説明が曖昧なら、適切に選ばれるとは限りません。

ツール呼び出しは、要求・実行・結果の往復

モデルにツールの定義を渡すと、応答にツール名と引数を含む要求が返ることがあります。たとえば「規程検索へ『交通費の精算期限』を渡す」という要求です。LangChainでは、モデルへ利用可能なツールを結び付けるbind_toolsなどの仕組みがありますが、定義を渡すこと自体は、外部システムの処理を実行することではありません。

アプリケーションが要求を受け取り、許可された処理か、引数が妥当かを確認した上で、実際のツールを実行します。その返り値をToolMessageなどでモデルへ戻すと、モデルは検索結果に基づいた回答を生成できます。tool_call_idは、どの要求に対する結果かを対応づけるために使います。

複数の要求がある場合、結果の順番だけでは取り違えることがあります。要求AのIDを付けて結果Aを返す、と対応を保つのが呼出IDの役割です。ToolMessageは、第4節で学んだ役割付きメッセージのうち、ツールから返った情報を表すものです。

結果が空だった場合も、その事実を返す必要があります。「該当なし」を「一般的な規程ではこうだろう」という推測で置き換えると、実データの取得とモデルの推測の境目が失われます。

この例では、モデルの要求の時点では、期限について何も確定していません。実行結果を受け取って初めて、その情報を使った説明へ進めます。ツール名が応答に含まれたことを、検索が成功した証拠として扱わない理由がここにあります。

読み取りと書き込みでは、扱う責任が変わる

規程を検索するツールは主に情報を読み取ります。一方、申請を登録する、メールを送る、予約を確定するといったツールは外部の状態を変えます。どちらもツールですが、間違った要求を実行したときの影響が異なります。

モデルが「申請を登録したい」と要求しても、本人がその申請を登録できる権限を持つか、必要な確認が済んでいるかは、アプリケーションが判断します。本人のIDをモデルの生成した文字列だけから決めるような設計では、別の人の情報を扱う危険があります。信頼できる本人情報は、アプリケーション側の実行情報として渡します。

このように、ツールはモデルの能力を現実の処理へつなぐ一方、実行してよい範囲を明確にする境界でもあります。利用できる機能を必要なものへ絞ることは、選択の分かりやすさと権限管理の両方に役立ちます。

ツールを一度使うことと、エージェントは別の概念

一つの決まった検索をアプリケーションが必ず呼び出し、結果をモデルへ渡すだけなら、固定した処理として構成できます。モデルに次のツールの選択を任せる必要はありません。一方、何を調べるか、追加の照会が必要かを、モデルの応答に応じて繰り返し判断させる場合は、エージェントの構成が関わります。

ツールは利用できる機能、エージェントはその機能を選びながら仕事を進める流れです。次の節では、LangChainのcreate_agentを通して、この流れを説明します。