ClaudeによるTool出力メタ認知
This commit is contained in:
parent
c331936455
commit
6e9ef385c8
|
|
@ -53,6 +53,22 @@ CronCreate
|
|||
|
||||
が返ってくる。「上のツール定義と同じエンコーディング」と明示されており、以降そのツールは通常通り呼べるようになる。
|
||||
|
||||
### 1.5 パラメータ値のエンコーディング規約
|
||||
|
||||
ツール呼び出しの `<parameter>` タグの中身は、値の型に応じて異なるエンコーディングを使う:
|
||||
|
||||
- プリミティブ (string / number / boolean): そのままテキスト
|
||||
- 配列・オブジェクト: JSON 文字列としてシリアライズしてテキストに
|
||||
|
||||
system prompt 末尾にも以下のように明記されている:
|
||||
|
||||
```
|
||||
When making function calls using tools that accept array or object parameters
|
||||
ensure those are structured using JSON.
|
||||
```
|
||||
|
||||
つまり「XML が外側の骨格、中身は型に応じてテキスト/JSON」という二層構造。
|
||||
|
||||
---
|
||||
|
||||
## 2. パラダイムの推測: prompted tool use
|
||||
|
|
@ -180,3 +196,115 @@ deferred tools 方式は **prompted tool use を前提とする限り**、これ
|
|||
> Claude Code の観察上は、ツール定義や呼び出しが prompt 内テキストとして見えている。ただし、公開されている Anthropic API の tool search は `tools` 配列、`defer_loading`、`tool_reference`、`tool_use` を使う structured tool use として説明されている。したがって、Claude Code 内部が完全な prompted tool use なのか、API の structured tool use を CLI / ハーネス側で別表現にレンダリングしているのか、あるいはそのハイブリッドなのかは未確認。
|
||||
|
||||
Pod / insomnia への示唆としては、deferred tools の設計目的である context 圧縮、tool selection accuracy の維持、prefix cache の安定化は公式情報でも裏付けられる。一方で、Anthropic API の現在の公開設計を参考にするなら、`tool_search` 相当の実装は「単なる schema text の注入」だけでなく、内部 registry 上の tool reference、ロード済み tool の状態管理、検証レイヤを明確に分けて設計する方がよい。
|
||||
|
||||
---
|
||||
|
||||
## 9. ツール I/O の実際のフォーマット
|
||||
|
||||
(2026-05-01 追記)
|
||||
|
||||
deferred tools の本論からはやや脇道だが、ToolSearch がスキーマテキストを context に注入することで「ツールが使える状態」になる仕組みを理解するためには、ツール定義・呼び出しの実フォーマットと、Anthropic API の公開 surface との対応関係を押さえておく必要がある。
|
||||
|
||||
### 9.1 ツール定義の入力フォーマット
|
||||
|
||||
system prompt 冒頭に置かれる:
|
||||
|
||||
```
|
||||
<functions>
|
||||
<function>{"description": "...", "name": "Read", "parameters": {...JSONSchema...}}</function>
|
||||
</functions>
|
||||
```
|
||||
|
||||
外側は XML、`<function>` の中身は単行 JSON。JSON 部分は `name`, `description`, `parameters` の 3 フィールドで、`parameters` は標準的な JSONSchema (`type: "object"`, `properties`, `required`, `additionalProperties` 等)。
|
||||
|
||||
### 9.2 ツール呼び出しの出力フォーマット
|
||||
|
||||
モデル側の生成は完全に XML タグ列:
|
||||
|
||||
```
|
||||
<function_calls>
|
||||
<invoke name="Read">
|
||||
<parameter name="file_path">/foo/bar</parameter>
|
||||
</invoke>
|
||||
</function_calls>
|
||||
```
|
||||
|
||||
`<parameter>` の中身は §1.5 のエンコード規則に従う。
|
||||
|
||||
### 9.3 標準 Anthropic API との関係
|
||||
|
||||
開発者から見える API surface は完全に JSON ベース:
|
||||
|
||||
- リクエスト: `tools: [{name, description, input_schema}]`
|
||||
- レスポンス: `tool_use` content block (JSON)
|
||||
|
||||
ところが Claude Code 上の観察では XML+JSON のハイブリッド表現が実際に流れている。両者の整合は次のように理解できる:
|
||||
|
||||
| | 標準 API (structured tool use) | Claude Code (prompted tool use) |
|
||||
|---|---|---|
|
||||
| 開発者が渡す形式 | JSON (`tools` 配列) | — (ハーネス内製) |
|
||||
| モデルが受け取る prompt | 非公開 (推測: XML+JSON) | XML+JSON (観察可) |
|
||||
| モデルが返す表現 | 非公開 (推測: XML タグ) → API が parse | XML タグ (観察可) |
|
||||
| 開発者が受け取る形式 | `tool_use` block (JSON) | — |
|
||||
|
||||
標準 API では JSON ↔ モデル内部表現の変換が API サーバ側で隠蔽されている。Claude Code が観察できるのはその「裸の」表現で、Anthropic がモデル訓練に用いているフォーマットそのものと推測される (同じモデルなので)。
|
||||
|
||||
### 9.4 バリデーションとリトライの内製化
|
||||
|
||||
この構造を見ると、Tool Call API は実質「フォーマット規約 + schema validation + retry」をプロバイダー側に押し込めた仕様と読める:
|
||||
|
||||
1. **フォーマット規約**: XML 骨格と parameter エンコード規則
|
||||
2. **バリデーション**: schema 違反の検出
|
||||
3. **リトライ**: malformed なら API 内部で再生成し、開発者には完成品だけ返す
|
||||
4. **訓練投資**: そのフォーマットで RLHF / SFT 済み
|
||||
|
||||
開発者が `tool_use` block を常に正しい JSON として受け取れるのは、(4) のおかげで失敗率が低く、(1)-(3) のおかげで失敗時も隠蔽されているから。Cline 等の prompted tool use 実装が同じことをやろうとしても、(4) が効かないため精度・安定性で見劣りしていたのは、この訓練投資の差で説明できる。
|
||||
|
||||
ただし Claude Code のハーネスは **token-level 制約 (grammar-based sampling) を入れていない**ことが、§10 の実演から推測できる。「自由に生成 → パース失敗なら error を tool_result で返して retry」という設計で、token 制約は使っていない。これは inference サーバ側の実装コストを避けつつ、(4) の訓練品質に依存する方針。
|
||||
|
||||
### 9.5 ローカル LLM への含意
|
||||
|
||||
Pod / insomnia でローカル LLM を使う場合、(4) が効かない。最近のローカル向けエージェントモデルは tool use 用に訓練されているので XML パースのような原始的処理は不要だが、各モデルが訓練された自前のフォーマット (Hermes / Llama / Qwen / Mistral 等で異なる) があり、それに合わせてレンダリングする必要がある。
|
||||
|
||||
具体的な責務分担は以下:
|
||||
|
||||
- ツール定義のレンダリング: モデル固有のテンプレート (chat template の `tools` 拡張等) に合わせる
|
||||
- 出力パース: モデルが生成した形式 (タグ / JSON / 独自トークン) をハーネスでパース
|
||||
- バリデーション: 自前で schema 照合
|
||||
- リトライ: パース失敗・schema 違反時に error を返してモデル側に修正させる
|
||||
|
||||
これは Claude Code が内製化しているもののローカル版そのもの。
|
||||
|
||||
---
|
||||
|
||||
## 10. 実演: schema 未ロードでの呼び出し
|
||||
|
||||
(2026-05-01 実演)
|
||||
|
||||
§3 の推測「検証の真実はレジストリであり、context にスキーマテキストが現れたかどうかではない」を確認するため、deferred tool である `TaskList` を ToolSearch せずに直接呼び出した。
|
||||
|
||||
### 10.1 結果
|
||||
|
||||
受理された (`No tasks found` が返ってきた)。InputValidationError は発生しなかった。
|
||||
|
||||
### 10.2 含意
|
||||
|
||||
1. **schema 未ロード = 呼び出せない、ではない**。少なくとも引数なしで呼べるツールでは、schema text が context に無くても通る
|
||||
2. ハーネスのバリデーションは「schema text が context にあるか」ではなく、**実引数が registry の schema に合致するか**で判定している
|
||||
3. system-reminder の "calling them directly will fail with InputValidationError" は厳密には常に真ではない。引数が schema と矛盾しないケース (特に必須引数のないツールに引数なしで呼ぶ場合) では素通りする
|
||||
4. context に積まれる schema text は、モデルが正しい引数を生成するための **誘導 / プロンプト材料** であって、validation の入力ではない
|
||||
|
||||
§3 の推測がそのまま裏付けられた形になる。
|
||||
|
||||
### 10.3 system-reminder の役割の再解釈
|
||||
|
||||
警告が「常に fail する」と読めるのは過剰表現で、実際には「**引数 schema が必要なツールは引数指定が必須なので、schema を知らずに呼べば事実上 fail する**」というモデルへの誘導と理解するのが正確。registry 側のバリデーションは引数の中身を見ているだけで、context に schema text があるかは見ていない。
|
||||
|
||||
### 10.4 設計上の含意
|
||||
|
||||
Pod / insomnia 側で同様の機構を作る場合:
|
||||
|
||||
- 「schema text が context にあるか」を validation 条件にする必要はない (むしろしない方が単純)
|
||||
- registry に常時全 tool を登録しておき、context へのレンダリングだけ deferred にする
|
||||
- モデルが (誘導を無視して) schema 未ロードのツールを呼んでも、引数が合っていれば実行してよい
|
||||
- この方が registry の真実性が一本化されて実装が単純になる
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user