壊れたツール呼び出しを自動修復する──Unsloth Desktopの「Self-healing tool calling」を公式の実測データで読む

3行まとめ

• Unsloth Desktop（2026年8月11日公開）の「Self-healing tool calling」は、壊れたツール呼び出しを破棄せず修復する機能。公式ドキュメントはQwen3.5-4B-GGUFでのテストで、XMLの漏出が10件中10件→0件に減ったと実測データを公開している。
• 公式ドキュメントは「Unslothの全モデルでツール呼び出しが30〜80%正確になる」「ツール呼び出しの上限は25回超」ともうたっており、リリースノートの「最大50%」という見出し数値より幅のある表現をしている。
• Claude CodeやCodexからUnslothのAPIエンドポイント（/v1/messagesでAnthropic Messages API互換）に接続し、ローカルモデルをこれらのエージェントのバックエンドとして差し替えられる。

ローカルLLMにツール呼び出し（外部関数の実行指示）をさせると、モデルが出力するJSONやXMLの構文が微妙に崩れて、呼び出し自体が失敗する——という経験をしたことがある人は多いはずだ。2026年8月11日にリリースされたUnsloth Desktopは、この問題を自動修復する機能を持つ。GitHubのリリースノートでは「Self-healing tool calling」という1語で紹介されているが、公式ドキュメントには具体的な実測データまで公開されている。

リリースノートでの紹介は1文だけ

Unsloth Desktopの発表リリース（v0.1.701-beta、2026年8月11日公開）では、この機能はこう紹介されている。

"Get up to 50% more accurate tool calling with self-healing calls and sandboxed code execution."

（自己修復するツール呼び出しとサンドボックス化されたコード実行によって、ツール呼び出しの精度を最大50%向上させる）

本文中の別の箇所には、もう少し踏み込んだ説明がある。

"Self-healing tool calling repairs malformed calls instead of dropping them. Models can run Python and Bash inside sandboxed environments, so they can test code, create files and verify their work."

（Self-healing tool callingは、不正な形式の呼び出しを破棄するのではなく修復する。モデルはサンドボックス化された環境内でPythonとBashを実行できるため、コードをテストし、ファイルを作成し、自分の作業を検証できる）

公式ドキュメントにある実測ベンチマーク

リリースノートのリンク先である公式ドキュメント（unsloth.ai/docs/new/studio/chat）を実際に開くと、unsloth/Qwen3.5-4B-GGUF（UD-Q4_K_XL量子化）でWeb検索・コード実行・thinkingを有効にした状態のテスト結果が、通常のツール呼び出しとUnslothのツール呼び出しを比較する表として公開されている。

最も分かりやすい差は「XMLの漏出」だ。通常のツール呼び出しでは10回中10回すべてでXMLタグがそのまま応答に漏れ出していたのに対し、Unsloth側では0回だった。ツール呼び出しに失敗すると、モデルは呼び出し用の構文（XMLタグなど）をそのままユーザー向けの回答に混ぜて出力してしまうことがある。これが起きなくなった、という数字だ。

一方で「曲名が正しく取得できた回数」は、Unsloth側でも2/10にとどまっている。修復機能があっても万能ではなく、タスクの成功率自体は限定的だったことも、この表からは読み取れる。

同じドキュメントの別の節「+50% Tool Calling Accuracy」には、この表の周辺にある補足情報として次の記述もあった。

• Unsloth上の全モデルで、ツール呼び出しは「30%から80%正確になる」（"Tool calls across all models in Unsloth are 30% to 80% more accurate"）
• 許可されるツール呼び出しの上限回数は25回超
• ツール呼び出しの終了判定が改善し、ループや呼び出しの繰り返しが減る

リリースノートの見出しは「最大50%」という単一の数字だったが、ドキュメント本文はこれを「30〜80%」という幅のある数字で説明しており、単一の改善率ではなくモデルやタスクによって差があることを示唆している。

サンドボックスでの実コード実行

公式ドキュメントは、コード実行機能についてもこう説明している。

"Unsloth Studio lets LLMs run Bash and Python, not just JavaScript. It also sandboxes programs like Claude Artifacts so models can test code, generate files, and verify answers with real computation." "This makes answers from models more reliable and accurate."

（Unsloth Studioは、LLMにJavaScriptだけでなくBashとPythonの実行も許可する。Claude Artifactsのようにプログラムをサンドボックス化するため、モデルはコードをテストし、ファイルを生成し、実際の計算で回答を検証できる。これにより、モデルからの回答の信頼性と正確性が高まる）

Anthropicが提供するClaude Artifactsの名前を引き合いに出しながら、「モデルに実際にコードを実行させて答え合わせをさせる」という設計思想を説明している点は、ローカルモデルの弱点（幻覚・計算ミス）を、外部の実行環境で機械的に検証させることでカバーしようという方向性だと読める。

Claude CodeやCodexからも呼び出せるAPIエンドポイント

もう1つ確認できたのは、UnslothのローカルモデルをClaude CodeやCodexといった既存のコーディングエージェントから呼び出せる、という統合だ。

"You can now use local LLMs via tools like Claude Code and Codex by connecting it to Unsloth's API endpoint. This means you'll be able to directly run Qwen and Gemma models in those tools with Unsloth's inference which includes features like self-healing tool-calling, websearch etc."

（Unsloth APIエンドポイントに接続することで、Claude CodeやCodexといったツールからローカルLLMを使えるようになった。これにより、QwenやGemmaのモデルを、Self-healing tool callingやWeb検索を含むUnslothの推論機能付きで、これらのツール内から直接動かせるようになる）

つまり、Unsloth上で動くローカルモデルを、Claude Codeのバックエンドとして差し替えて使えるという構成だ。Claude Code自体のエージェントループはそのまま使いながら、推論だけをローカルGPU上のモデルに向ける、という選択肢になる。API公式ドキュメント（unsloth.ai/docs/basics/api）を直接確認すると、エンドポイントは/v1/messages（Anthropic Messages API互換、Claude Code・OpenClaw・Anthropic SDK向け）と/v1/chat/completions・/v1/responses（OpenAI互換、OpenCode・Cursor・Continue・Cline向け）の2系統が用意されており、Self-healing tool callingはどちらの系統からアクセスしても同じUnslothバックエンドの機能として働く、という構成であることが分かる。専用ガイド（unsloth.ai/docs/basics/claude-code）はGemma 4・Qwen3.5をClaude Codeで動かす手順をスクリーンショット付きで示している。

ベンチマーク表の実在はドキュメントで確かめた

筆者は今回、リリースノートに貼られたリンク先の公式ドキュメント（studio/chatページ）に加えて、APIエンドポイントの説明ページとClaude Code連携ガイドも実際に開き、上記のベンチマーク表と「30〜80%」という補足数値がドキュメント本文に実在することを確認した。ただし、手元の環境でUnsloth Desktopをインストールし、自分の用途でこの自己修復機能を動かして検証するところまでは行っていない。「50%改善」という見出しの数字と、ドキュメントに載っているQwen3.5-4Bの実測表は、評価の切り口が異なる（前者は改善率のサマリー、後者は個別指標の内訳）ため、両者がどう対応しているのかは今回の情報源だけでは一対一に対応づけられなかった。

「30〜80%」の内訳は特定できなかった

「30%から80%正確になる」という幅のある改善率が、どのモデル・どのタスクセットで測定されたものかという条件は、リリースノート本文にも公式ドキュメントにも明記されていなかった。表に示された実測値も、Qwen3.5-4B-GGUFという1モデル・1量子化設定での結果であり、他のモデル（Muse Glimmer 30BやKimi K3など、同じUnsloth Desktopが動かせるとされているモデル）でも同様の改善が出るかどうかは、今回確認した情報源からは分からない。Claude Code経由で実際にSelf-healing tool callingが働いているところを筆者自身が動かして確認したわけでもない。

関連記事

• ローカルLLMとは何か──自分のPCでAIを動かす仕組み・利点・始め方を解説
• AIコーディングアシスタント比較──Copilot/Cursor/Claude Code【2026年】
• ローカルLLMおすすめモデル10選──無料で動かせるAI【2026年版】