Kimi K3の「Dynamic Tool Loading」──ツール定義を会話の途中で継ぎ足す設計

2026年8月27日、Kimi API Platformの公式ドキュメントを実際に開いて確認した内容です。 Moonshot AIのKimi API公式ドキュメント（platform.kimi.ai）に、「Dynamically Loaded Tools（動的にロードされるツール）」という機能の解説ページがあります。ツールを大量に持つエージェントが、リクエストのたびに全ツール定義を送り続けることで起きる問題──トークン消費の増大とツール選択精度の低下──に対して、会話の途中でツール定義を追加していく設計で応じるものです。当サイトはこれまでKimi K3の正式発表や重み公開を扱ってきましたが、今回はAPI機能そのものを一次ドキュメントベースで見ていきます。

3行まとめ

• Kimi API公式ドキュメントに「Dynamically Loaded Tools」という機能が解説されている。ツールを最初から全部toolsフィールドに入れず、会話が必要とした時点でmessagesに追記する仕組み
• 狙いは3つ：トークン消費の削減、ツール選択の誤り（違うツールを選ぶ・不正な引数を組み立てる）の抑制、そしてプロンプトキャッシュの維持（末尾への追記のみなので、既存のキャッシュ済みプレフィックスを壊さない）
• 公式ドキュメントは現時点でkimi-k3限定の機能と明記しており、kimi-k2.6など他モデルではtokenization failedエラーになるとしている

「Tool Definition Bloat」という前提の問題

公式ドキュメントはまず、この機能が解決しようとしている問題を「Tool Definition Bloat（ツール定義の肥大化）」と呼んでいます。エージェントが多数のツールを持つ場合、リクエストのトップレベルのtoolsフィールドに全ツールの説明とパラメータスキーマを毎回書き込むと、次の2つが起きるとされています。

• リクエストのたびに全ツールの説明・スキーマを運ぶことになり、トークン消費が増える
• 候補となるツールが増えるほど、モデルが誤ったツールを選んだり、不正な呼び出し引数を組み立てたりする可能性が上がる

この問題自体は目新しいものではなく、多くのエージェントフレームワークが「ツールが多すぎる」課題として認識しているものです。Kimiの場合、対応策として公式にドキュメント化された機能を持っている、という点が今回のポイントです。

仕組み：会話の途中でツールを「注入」する

Dynamically Loaded Toolsの使い方は、messages配列にroleがsystemのメッセージを挿入し、そのメッセージのtoolsフィールドにツール定義を書く、というものです。宣言フォーマット自体はトップレベルのtoolsフィールドと同じで、name・description・parametersを含む完全なツール定義である必要があります。

公式ドキュメントに掲載されているサンプルでは、次のような流れになります。

1. 通常のsystemメッセージ（役割説明）とuserメッセージ（「燃料消費量を計算して」）を送る
2. その直後に、toolsフィールドを持つsystemメッセージを追加し、Calculatorという関数ツールを1つだけ注入する
3. モデルはこの時点からCalculatorツールを認識し、呼び出せるようになる

ポイントは、動的に注入されたツール宣言は、トップレベルのtoolsフィールドで宣言されたグローバルツールと共存することです。モデルは両方を見ることができます。また、ツール名だけを渡して「既に宣言済みのツールを参照する」ことはできず、必ず完全な定義を渡す必要がある、と公式ドキュメントは明記しています。

プロンプトキャッシュとの関係──「末尾への追記のみ」が鍵

この機能がただの「ツールを後から足せる」以上の設計になっているのは、AnthropicがMid-conversation Tool Changesで扱っているのと似た課題──プロンプトキャッシュとの両立──に対する回答を持っているからです。

Kimiのコンテキストキャッシュは、リクエストの先頭からどこまでが以前のリクエストと同じかで判定するプレフィックス一致方式です。プレフィックスの途中を変更・挿入すると、その時点からキャッシュが無効になります。公式ドキュメントは、動的ツールローディングを使うときに守るべき原則を3つ挙げています。

• 末尾に追記するだけで、途中に挿入しない：既存のプレフィックスは変わらないので、確立済みのキャッシュに影響しない。会話の途中のメッセージ（既に注入したツール宣言を含む）を削除・変更すると、その時点からキャッシュが無効になる
• 注入した宣言は保持し続ける：動的なツール宣言はリクエストごとに適用され、サーバー側には保持されない。以降のリクエストでも同じ宣言を運び続けることで、ツールを使い続けられるだけでなく、安定したプレフィックスを保ってキャッシュヒット率を保てる
• コアツールはトップレベルに固定する：毎ターン必要なツールはグローバルツールとして宣言し、変更しない。グローバルツール宣言はキャッシュヒットに影響しないため、安定させておくとプレフィックスキャッシュの効果を保てる

公式ドキュメントの表現をそのまま訳すと、「新しいリクエストがプレフィックスキャッシュにヒットできるのは、直前のリクエストのプロンプトトークン数が256を超えている場合のみ。256トークン未満のリクエストはキャッシュされず、破棄される」ともあります。小さいリクエストではこの機能の恩恵自体が発生しない点は覚えておく必要があります。

この節の内容は、公式ドキュメント自身が次のような一覧表にまとめています。

ツール検索を自前実装する方法

公式ドキュメントは「専用のツール検索APIは無い」と明記した上で、大量のツールインベントリを持つ場合の設計パターンも示しています。

1. トップレベルのtoolsフィールドにはsearch_toolsという関数を1つだけ宣言する。これは自分のバックエンドが実装するもので、キーワードに対して該当するツール名と概要を返す
2. システムプロンプトで検索可能なキーワード（ツールカタログやドメインタグなど）を伝え、モデルが「ツールが必要になったらまずsearch_toolsを呼ぶ」ことを促す
3. search_toolsが返した結果に基づき、アプリケーション側が該当ツールの完全な定義をtoolsフィールドを持つsystemメッセージとして注入する
4. モデルは以降の生成で、注入されたツールを呼び出せる

ツールインベントリ全体がどれだけ大きくても、各リクエストが運ぶツール宣言はごく少数に保たれる、という設計です。

制約：現時点ではkimi-k3限定

公式ドキュメントの「Notes」セクションには、この機能の適用範囲について明記があります。

• 動的ツール宣言は、グローバルなtools宣言とまったく同じフォーマットを使うため、スキーマを一本化でき、移行コストが低い
• toolsを持つsystemメッセージ自体もコンテキスト長を消費するため、その会話が実際に必要とするツールだけを注入すべき
• 動的ロードされたツールは現時点でkimi-k3でのみサポートされている。他モデル（kimi-k2.6など）でリクエストするとtokenization failedエラーになる
• toolsを持つsystemメッセージは同時にcontentフィールドを持てない。持たせると400エラー（cannot be used with content）になる。OpenAI SDKを使う場合はtoolsフィールドをmessagesにそのまま渡せば良く、extra_bodyは不要

この「kimi-k3限定」という制約は、Dynamic Tool Loadingがモデルの学習段階から見込んで作られた機能である可能性を示唆していますが、公式ドキュメントはその設計背景までは説明していません。

サンプルコードを読み比べて気づいたこと

公式ドキュメントに載っているサンプルリクエスト（Calculatorツールを動的注入する例）をcurl版・python版の両方で読み比べると、role: "system"のメッセージにcontentを持たせずtoolsだけを持たせる、という構造になっている点が目に留まりました。筆者はKimi APIのキーを持っておらず、本記事執筆にあたって実際にこのリクエストを送信して動作を確認したわけではありませんが、多くのチャット系APIではsystemメッセージにcontentが必須という前提が一般的なため、この「contentなしのsystemメッセージ」という形は、コードをそのままコピーしただけでは見落としやすく、他社APIに慣れた実装者ほど引っかかりやすい部分だろうと感じます。

機能の初出日が特定できなかった点

この機能がいつから提供されているのか、公式ドキュメントの本文には明記がありませんでした。Kimi K3自体は2026年7月に正式発表されていますが、Dynamic Tool Loadingがそれと同時に追加されたのか、後から追加された機能なのかは判断できませんでした。実際に「Platform Changelog」ページ（platform.kimi.ai/docs/platform-changelog.md）を開いて確認したところ、掲載されている更新履歴の最新項目は「April 7, 2025」で、価格改定・組織メンバー管理機能の追加・UIバグ修正が記載されているだけで、Dynamic Tool LoadingやKimi K3自体への言及はありませんでした。つまりこの変更履歴ページ自体が2025年4月以降更新されておらず、少なくともこのページからはKimi K3期の機能追加の時期を特定できない、というのがこの記事で確認できた実際の状態です。また、この機能に類似する仕組みが他社API（Claude APIのMid-conversation Tool Changes、OpenAIのProgrammatic Tool Callingなど）にどこまで対応するのかについては、各社の実装が異なるため単純比較はできず、本記事では踏み込んでいません。

関連記事

• Kimi K3正式発表──2.8兆パラメータ・世界初のオープン3Tクラス
• Kimi K3の重みが公開された──1.56TBの中身を開けて検算
• Kimi（Moonshot AI）とは何か──全体像を整理