MiniMax M3 ツール呼び出しガイド

はい、 MiniMax M3はツール呼び出しをサポートしています。

MiniMaxはM3を、自律的なタスク分解、ツール呼び出し、マルチステップ推論を含むコーディングおよびエージェントワークロード向けに特化して位置づけています。このモデルはまた、最大1Mトークンのコンテキストウィンドウをサポートしており、長時間実行されるエージェントおよびコーディングワークフローを支援するように設計されています。

ただし、ツール呼び出しはMiniMax M3があなたのAPIや関数を直接実行することを意味しません。

実際のフローは次のとおりです：

ツールを定義する
    ↓
MiniMax M3にツールを送信する
    ↓
M3がtool_callsを返す
    ↓
アプリケーションが関数を実行する
    ↓
結果をM3に送り返す
    ↓
M3が続行するか、最終回答を返す

そのループを理解することが、エージェントでMiniMax M3を正しく使用するための鍵です。

MiniMax M3のツール呼び出しとは？

通常のLLMリクエストは次のようになります：

ユーザー → モデル → 回答

モデルはテキストを受け取り、テキストを返します。

それは、モデルがすでに持っているコンテキストから答えられる質問に有効です。

しかし、ユーザーがこう尋ねたとしましょう。

今の東京の天気は？

モデルは現在の天気データを捏造すべきではありません。

ツール呼び出しを使うと、M3に次のような関数を使わせることができます。

get_weather(city)

ワークフローは次のようになります。

ユーザー
  ↓
MiniMax M3
  ↓
get_weather(city="Tokyo")
  ↓
あなたの天気API
  ↓
現在の天気結果
  ↓
MiniMax M3
  ↓
最終回答

M3は、どのツールを使用すべきか、どの引数が必要かを決定します。

アプリケーションは、ツールが実際に何を行うかを決定します。

MiniMax M3 Tool Calling API

MiniMaxの現在のテキスト生成APIドキュメントには、MiniMax-M3がサポートされているモデルとして含まれており、以下を公開しています：

tools
tool_choice
tool_calls

ドキュメントに記載されているエンドポイントは次のとおりです:

POST /v1/text/chatcompletion_v2

また、現在のM3モデル識別子は次のとおりです:

MiniMax-M3

MiniMaxは2つのtool_choiceモードを文書化しています:

auto
none

また、自動、M3はツールを呼び出す必要があるかどうかを判断します。

「なし」の場合、ツールの使用は無効になります。

ステップ1: ツールを定義する

M3に天気情報を確認させたいとします。

まず、モデルに関数を説明します。

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Get the current weather for a city",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "The city to get weather for"
        }
      },
      "required": ["city"]
    }
  }
}

MiniMaxは現在、次のものをサポートしています。function ツールタイプとして。そのAPIスキーマには、関数名、説明、パラメータ定義が必要です。

このスキーマの品質が重要です。

ツールの説明が曖昧な場合、モデルはいつ呼び出すべきかについての情報が少なくなります。

比較：

悪い例：
データを取得する。

一方：

良い例：
指定した都市の現在の天気、気温、状況を取得する。
ユーザーが現在または将来の天気について尋ねたときにこのツールを使用する。

2つ目の説明は、モデルにはるかに明確なツール選択の指針を与えます。

ステップ2：ツールをMiniMax M3に送信する

簡略化されたPythonリクエストは次のようになります。

import requests

url = "https://api.minimax.io/v1/text/chatcompletion_v2"

headers = {
    "Authorization": "Bearer YOUR_MINIMAX_API_KEY",
    "Content-Type": "application/json"
}

payload = {
    "model": "MiniMax-M3",
    "messages": [
        {
            "role": "user",
            "content": "What's the weather in Tokyo?"
        }
    ],
    "tools": [
        {
            "type": "function",
            "function": {
                "name": "get_weather",
                "description": "Get the current weather for a city",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "city": {
                            "type": "string"
                        }
                    },
                    "required": ["city"]
                }
            }
        }
    ],
    "tool_choice": "auto"
}

response = requests.post(
    url,
    headers=headers,
    json=payload
)

data = response.json()
print(data)

現在のMiniMax APIドキュメントには、MiniMax-M3と、このエンドポイントのtoolsおよびtool_choiceリクエストフィールドが明示的にリストされています。

ステップ3: M3のツール呼び出しを読み取る

M3がツールが必要と判断した場合、アシスタントの応答には tool_calls 配列を含めることができます。

MiniMaxは各呼び出しを次のように文書化しています：

id
type
function.name
function.arguments

概念的には、結果は次のようになります：

{
  "tool_calls": [
    {
      "id": "call_123",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\":\"Tokyo\"}"
      }
    }
  ]
}

重要な点は次のとおりです：

M3はまだ何も実行していません。

次の内容の構造化されたリクエストを生成しました：

実行してください：get_weather の引数に city="Tokyo"。

ここで、アプリケーションは引数を解析し、実際の関数を実行する必要があります。

ステップ 4: アプリケーションでツールを実行

例：

import json

tool_call = data["choices"][0]["message"]["tool_calls"][0]

function_name = tool_call["function"]["name"]
arguments = json.loads(
    tool_call["function"]["arguments"]
)

if function_name == "get_weather":
    result = get_weather(**arguments)

独自の関数は、実際の天気サービスを呼び出して、次のような結果を返すこともあります：

{
  "city": "Tokyo",
  "temperature": 29,
  "condition": "Rain"
}

この結果は、あなたのツールによるものであり、MiniMax によるものではありません。

その区別は、本番エージェントを構築する際に不可欠です。

ステップ 5: ツール結果を M3 に返す

ここで、会話を続ける必要があります。

あなたのアプリケーションは、ツール呼び出しを含む M3 のアシスタントメッセージを保持し、あなたの関数からの結果を会話に追加する必要があります。

モデルはその後、実際の結果を使用して最終回答を生成できます。

MiniMax は、マルチターンの関数呼び出し会話では、推論の連続性を保つために、ツール呼び出し情報を含むアシスタントの完全な応答を保持すべきだと明確に文書化しています。

概念的には、履歴は次のようになります。

ユーザー：
東京の天気は？

アシスタント：

[tool call: get_weather(city=”Tokyo”)]

ツール：東京：29°C、雨 アシスタント：現在東京は29°Cで雨が降っています。

これが基本的なエージェントループです。

ツール呼び出し履歴を保持すべき理由

これは、MiniMaxのドキュメントで最も重要な実装詳細の1つです。

ツール呼び出しが発生した場合、表示されているテキストだけを保持しないでください。

保持してください： 完全なアシスタントメッセージ。

なぜ？

なぜなら、次のモデルリクエストは以下を理解する必要があるからです：

• どのツールをリクエストしたか
• どのような引数を生成したか
• どの結果がどの呼び出しに対応するか
• 現在、タスクのどのステップにいるか

その状態を破棄すると、マルチステップのツールワークフローが一貫性を失う可能性があります。

エージェントがより多くの呼び出しを実行するにつれて、この点はますます重要になります。

複数のツールを使用する

実際のエージェントは通常、複数の関数を公開します。

コーディングエージェントが提供する可能性があるもの：

read_file
search_code
write_file
run_command
run_tests
git_diff

ビジネスアシスタントが提供する可能性があるもの：

search_customer
get_order
issue_refund
create_ticket
send_email

ユーザーは呼び出す関数を指定する必要はありません。

を使用するとtool_choice="auto"、モデルはリクエストに基づいて利用可能なツールから選択できます。

例えば：

ユーザー：
ログインテストが失敗する理由を調べて、問題を修正してください。

コーディングエージェントは、次の操作を実行できます：

search_code
    ↓
read_file
    ↓
run_tests
    ↓
read_file
    ↓
write_file
    ↓
run_tests
    ↓
git_diff

ここで、ツール呼び出しはエージェントワークフローになります。

MiniMax M3がこれに適している理由

ツール呼び出し自体はM3独自のものではありません。

GPT、Claude、Gemini、Qwen、GLMなど、多くのモデルもツールをサポートしています。

M3が興味深い理由は、MiniMaxがモデルを長時間のツール実行にどれほど強く集中させているかということです。.

MiniMaxはM3が自律的なタスク分解、ツール呼び出し、マルチステップ推論の能力を備えていると述べている。

同社はまた、M3が以下の項目を完了した長時間実行のCUDA最適化実験を公開した：

147件のベンチマーク提出
1,959件のツール呼び出し

約24時間の自律最適化ワークフロー中に。

だからといって、すべてのアプリケーションが何千ものツール呼び出しを実行すべきというわけではない。

これは、MiniMaxが目指す長期的な行動の一種を示している。

MiniMax M3のコンテキストウィンドウ

M3は最大100万トークンのコンテキストをサポートしています。.

MiniMaxは、M3 APIが最大1Mのコンテキストをサポートし、インフラストラクチャコンテキストとして最低512Kトークンが保証されていると述べています。

ツール呼び出しにはなぜそれが重要なのでしょうか？

長いエージェントはコンテキストを蓄積するからです。

多くのステップを経た後、モデルは以下を覚えておく必要があるかもしれません：

• 元のユーザー指示
• システム指示
• 以前のツール呼び出し
• ツール結果
• ソースコード
• ファイル
• エラー
• プラン
• 中間的な決定

例：

初期プロンプト
+ リポジトリのコンテキスト
+ 20回のツール呼び出し
+ 20件のツール結果
+ テスト出力
+ 変更後のコード
+ 追加のユーザー指示

これらはすべてコンテキストを消費します。

大きなコンテキストウィンドウは、以前の状態をすぐに破棄することなく、長時間実行されるワークフロー向けの容量をM3に提供します。

コーディングエージェント向けMiniMax M3

コーディングは、M3のツール呼び出しの最も明確なユースケースの1つです。

モデル自体がリポジトリを直接編集することはありません。

その代わりに、エージェントフレームワークは以下のようなツールを提供します。

read_file(path)
write_file(path, content)
search_code(query)
run_command(command)
run_tests()

M3 はそれらのツールを使ってタスクを進めることができます。

例えば：

このプロジェクトの認証バグを修正してください。

ワークフローは次のようになります：

1. 認証コードを検索
2. 関連ファイルを確認
3. 失敗したテストを実行
4. 原因を特定
5. 実装を修正
6. テストを再実行
7. エラーを確認
8. 別の変更を加える
9. 最終結果を検証

これは、次のような一回限りのプロンプトよりも、実際のソフトウェアエンジニアリングにずっと近いものです：

ログイン関数を書いてください。

MiniMaxは、M3を単純なコード補完だけではなく、コーディングエージェントや自動化ワークフローを中心に明確に位置づけています。

MiniMax M3はマルチモーダルにも対応

M3はネイティブにマルチモーダル対応です。

MiniMaxによると、マルチモーダルトレーニングは当初から含まれており、後から別のアダプターとして追加されたわけではありません。また、モデルはエージェント機能の一部として視覚理解をサポートしています。

これにより、ツールベースのエージェントをテキスト以外の領域にも拡張できます。

例：

スクリーンショットを確認
      ↓
UIの状態を把握
      ↓
次のアクションを決定
      ↓
コンピューター/ツール操作を実行
      ↓
結果を確認
      ↓
続行

これは、ブラウザエージェント、コンピューター操作タスク、ビジュアルQA、マルチモーダル開発ワークフローに役立ちます。

MiniMax M3のツール呼び出し vs 単純な関数呼び出し

2つの概念を区別しておくと便利です。

シンプルな関数呼び出し

ユーザーが質問する
→ モデルが1つのツールを選択する
→ ツールがデータを返す
→ モデルが回答する

例：

東京の天気は？

エージェンティックなツール呼び出し

ユーザーが目標を設定する
→ モデルが計画を立てる
→ ツールを呼び出す
→ 結果を評価する
→ 別のツールを呼び出す
→ 計画を変更する
→ さらにツールを呼び出す
→ 結果を検証する
→ 目標を達成する

例：

このリポジトリのバグを見つけて修正し、テストが通ることを確認してください。

M3は2番目のカテゴリではるかに興味深い。

MiniMax M3のツール呼び出しでよくある間違い

1. M3が関数を実行してくれると期待する

実行しません。

M3はツールリクエストを生成します。それを実行するのはあなたのアプリケーションです。

2. アシスタントのツール呼び出しメッセージを保持しないこと

マルチターンのワークフローでは、ツール呼び出しに関連するアシスタントの応答全体を保持してください。MiniMaxは互換性ドキュメントでこの点を特に強調しています。

3. あいまいなツールの説明を使用する

定義しないでください：

do_task

代わりに次のように定義できます：

search_customer_by_email

明確なツールは、モデルが正しく選択できる可能性を高めます。

4. ツールに過剰な権限を与える

公開する場合：

run_command

アプリケーションは引き続き、権限、検証、サンドボックス化、安全性のルールを適用する必要があります。

モデルは、インフラストラクチャで何を実行できるかについての最終決定権を持つべきではありません。

5. 長いコンテキストを無制限のメモリとして扱う

1Mのコンテキストウィンドウは大きいですが、それでも有限です。

長時間のエージェント実行では、すべてを永遠に追加し続けるのではなく、コンテキストを意図的に管理する必要があります。

MiniMax M3はOpenAI互換のワークフローで動作しますか？

MiniMaxはテキストモデルエコシステム向けにOpenAI互換のAPIサポートを提供しており、そのツール呼び出しスキーマは、次のようなおなじみの概念に従います：tools、assistantのtool_calls、およびツール結果メッセージ。

MiniMaxのAPIドキュメントはM3を中心に活発に更新されているため、本番環境への統合では、正確なエンドポイントとサポート対象フィールドについては、常に最新のM3 APIドキュメントを正規の情報源として使用してください。

マルチモデルエージェントスタックにおけるMiniMaxモデルの利用

エージェント全体をMiniMaxで構築している場合、MiniMaxを直接統合するのが理にかなっています。

しかし、エージェント開発者の多くは複数のモデルを試します。

比較したい場合もあるでしょう：

• MiniMax
• GLM
• Qwen
• DeepSeek
• Claude
• GPT
• Gemini

ツール呼び出しの品質は、実際のスキーマやワークフローによって異なることがあります。

あるモデルはツールの選択に優れている場合があります。

別のモデルはコーディングに優れている場合があります。

長いエージェントループでは、別のモデルの方が安価な場合があります。

こうした場合に、統合モデルゲートウェイが役立ちます。

エージェント開発におけるTokenHubの利用

TokenHubは、対応モデル向けのOpenAI互換APIゲートウェイを提供し、Claude Code、Codex、Cursor、Cline、Aider、OpenCodeなどのツールや他の開発エージェントとの統合も文書化しています。

TokenHubのOpenAI互換ベースURLは次のとおりです。

https://us-api.tokenhub.com/v1

モデルプロバイダーごとにエージェントアーキテクチャ全体を書き直す代わりに、共通APIレイヤーを維持したまま、TokenHubの現在のカタログからモデルを選択できます。

これは、ツール呼び出しモデルの評価に特に役立ちます。同じエージェント、同じツール定義、同じタスクを異なる対応モデルに対して実行できるからです。

必ずTokenHubのライブモデルリストに表示されている正確なモデルIDを使用してください。

MiniMax M3はツール呼び出しに優れていますか？

MiniMax M3は、ツールを多用するエージェントワークフロー向けに明確に設計されています。

評価すべき最大の理由は次のとおりです。

• ネイティブツール呼び出し
• マルチステップ推論
• コーディング重視
• 最大1Mコンテキスト
• 長期実行エージェント設計
• ネイティブマルチモーダル機能

それがあなたの製品にとって最適なツール呼び出しモデルであるかどうかは、あなた自身のエージェント次第です。

カスタマーサービスのエージェントとコーディングのエージェントでは、好ましいモデルが異なる場合があります。

正しい評価は次のようなものではありません：

M3はツールをサポートしていますか？

はい、サポートしています。

より適切な質問は：

M3は確実に完了できますか 自分の実際のワークフロー を使用して 自分の実際のツール 許容可能なコストとレイテンシーで？

よくある質問

MiniMax M3はツール呼び出しをサポートしていますか？

はい。MiniMaxの現在のAPIドキュメントはツールとtool_choiceをMiniMax-M3に対してサポートしています。

MiniMax M3のモデルIDは何ですか？

現在のダイレクトAPIのモデル名は次のとおりです：

MiniMax-M3

MiniMax M3はtool_choiceでどのような値をサポートしていますか？

現在のテキストAPIのドキュメントには次のように記載されています：

auto
none

MiniMax M3はツールを自身で実行しますか？

いいえ。モデルはツール呼び出しと引数を生成します。外部関数を実行するのはお使いのアプリケーションです。

MiniMax M3がツールを呼び出したい場合、何を返しますか？

アシスタントのレスポンスには、 tool_calls ツール呼び出しID、関数名、JSON形式の引数を含む配列。

MiniMax M3は1Mコンテキストウィンドウに対応していますか？

はい。MiniMaxによると、M3は最大1Mトークンのコンテキストに対応しています。

MiniMax M3はコーディングエージェントに適していますか？

はい。コーディングとエージェント型タスクは、M3の主要なターゲットワークロードの2つです。

ワークフローを中心にエージェントを構築：単一プロバイダーに依存しない

MiniMax M3のツール呼び出しが有用なのは、これがより広範なエージェント設計の一部だからです。モデルはタスクを分解し、ツールを呼び出し、結果を処理し、長いワークフローを継続できます。

ただし、本番環境のエージェントでは、複数のモデルをテストする価値が依然としてあります。

TokenHubは、サポート対象モデル向けの統一APIレイヤーを提供し、プロバイダーごとにインテグレーションを再構築することなく、エージェント対応のさまざまなLLMを比較できます。

推奨内部リンク

• リンク：TokenHub → ホームページまたはモデルカタログ。
• リンク：OpenAI互換API → TokenHub API Docs。
• その後リンク：エージェントとツール呼び出しに最適な中国のLLM → 対応するブログ。
• 関連するGLM、Qwen、DeepSeek、Kimiの名称は、利用可能な場合に対応するTokenHubモデルページへリンクしてください。