ローカルLLMのツール呼び出しに実行前検証を入れる方法

ツール呼び出しへ対応したモデルがツール名と引数を返しても、その内容をそのままシェルや外部APIへ渡すべきではない。

モデルは実行候補を作り、アプリ側が実際に実行してよいかを決める構成にする。

最初のツールは副作用のないものにする

初回は、現在時刻を返す、固定データを検索する、といった読み取りだけのツールを一つ用意する。

ファイル削除、設定変更、外部送信のような操作を最初から入れない。引数の定義も小さくする。

{
  "name": "lookup_fixture",
  "arguments": {
    "key": "string"
  }
}

引数を解析して形式を検証する

モデルの出力は、信頼済みの入力として扱わない。

JSONとして解析できるか、必須項目があるか、型や許容値が正しいかをアプリ側で確認する。解析に失敗したり、未知の項目が含まれていたりしたら、ツールを実行せずエラーとして記録する。

ツール名と実行権限を別に確認する

引数の形式が正しくても、そのツールを現在の利用者や作業が呼んでよいとは限らない。

許可するツール一覧や権限を別に確認する。

1. そのツールは存在するか
2. 引数は正しいか
3. 現在の利用者・作業に実行権限があるか
4. 実行する
5. 結果をモデルへ返す

この順番なら、モデルが許可していないツール名を生成しても実行へ進まない。

実行結果もモデル出力と分けて残す

ツールの結果はモデルの推測ではなく、外部処理が返した情報だ。

記録では、

• モデルが作ったツール名と引数
• アプリ側の検証結果
• 実際のツール実行結果

を別々に残す。

正常系だけでなく拒否できるかも試す

最初の確認では、正常な呼び出しに加えて次も試す。

• 必須引数が足りない
• 引数の型が違う
• 許可一覧にないツール名
• 許容範囲を外れた値

これらが実行前に止まれば、次に複数ツールや複数段階の処理へ進める。

Ollama側で最小のツール呼び出しを確認したい場合は、Ollamaのツール呼び出し入門を先に使える。モデル同士のツール選択能力を比べたい場合は、ツール呼び出し対応のローカルLLMを評価する方法へ進む。