コーディングエージェント向けMCPモデルカタログ：モデル選択をマシンリーダブルにする

コーディングエージェント向けのMCP（Model Context Protocol）モデルカタログとは、ソースコードにハードコードされたモデル名に頼るのではなく、エージェントがModel Context Protocolを通じて読み取ることができる、構造化されたクエリ可能な利用可能モデルリストのことです。これにより、エージェント、IDEプラグイン、またはオーケストレーション層は、開発者が半年前にタイプして忘れてしまった文字列ではなく、タスクの種類、コンテキストウィンドウ、コスト上限に基づいて実行時にモデルを選択できるようになります。

これは、聞こえる以上に重要なことです。コーディングエージェントは、オートコンプリート、複数ファイルのリファクタリング、テスト生成、コミットメッセージの作成など、常にモデルを呼び出しています。これらの各タスクには、それぞれ最適なモデルが存在します。エージェントがどのモデルが存在し、何に適しているかを発見できなければ、プロバイダーが新しいリリースを出すたびに誰かが設定ファイルを編集し続けなければなりません。この記事では、モデルカタログのエントリに何を含めるべきか、そのようなカタログに対するMCP形式のリクエストがどのように構成されるか、そしてどのタスクにどのモデルをルーティングするかを決定する方法について解説します。

重要なポイント

• モデルカタログは、モデル選択をハードコードされた文字列から実行時のルックアップへと変えるため、プロバイダーが新しいモデルをリリースした際のメンテナンス負荷が軽減されます。
• コーディングエージェントは、すべてに1つのモデルを使用するのではなく、タスクの種類（オートコンプリート、リファクタリング、テスト生成、レビュー）ごとに異なるモデルにルーティングすることでメリットを得られます。
• モデルカタログデータに対するMCPリクエストは、通常resource-listまたはtool-callの形式に従います。正確なスキーマは、実装前にプロバイダー自身のドキュメントで確認する必要があります。
• TokenLabは /models/data にModel Data Centerを、/models にモデルディレクトリを公開しています。モデルのラインナップは頻繁に変更されるため、この記事ではなく、これらを現在のモデル名を確認する場所として利用してください。

なぜコーディングエージェントに機械可読なモデルデータが必要なのか

ほとんどのコーディングエージェントの統合は、10年前のAPI統合と同じ方法で機能しています。開発者がモデル名を選び、設定や環境変数に貼り付けてリリースするというものです。これは、プロバイダーがそのモデルを非推奨にするか、価格を変更するか、あるいはチームが採用するプロセスを持たないより優れたオプションをリリースするまでは機能します。

機械可読なカタログは、この障害モードを変えます。モデルが廃止されたときにエージェントが黙って壊れるのではなく、カタログにクエリを投げてモデルがなくなったか、非推奨とマークされていることを確認し、文書化された代替案にフォールバックすることができます。開発者が新しいリリースごとに手動でベンチマークを行う代わりに、エージェント（または開発者のツール）が、切り替える前にリストされたコンテキストウィンドウ、モダリティサポート、コストフィールドを比較できます。

これは、本格的なモデルルーティング戦略の前提条件でもあります。安価で大量の補完を DeepSeek V4 Flash や Gemini 3.5 Flash のような低コストモデルに送信し、複数ファイルのリファクタリングには Claude Sonnet 5 のような強力なモデルを確保したい場合、ルーティングロジックには、どのモデルが最新で、いくらかかり、何をサポートしているかについての信頼できる情報源が必要です。それがなければ、ハードコードされたモデル名と同じように、ルーティングルールも陳腐化してしまいます。

TokenLabは、モデル情報を人間が手作業で再確認するものではなく、エージェントが信頼できるものにするという文脈で、この問題について直接言及しています。エージェントが読み取れるモデルの真実に関するより広範な議論については agent-readable model truth を、主な呼び出し元が人間の開発者ではなくエージェントである場合にAPI設計がどのように変化するかについては agent-first API を参照してください。

MCPモデルカタログのエントリに含めるべきもの

コーディングエージェントにとって有用なカタログエントリには、モデル名以上の情報が必要です。構築または利用する開発者は、少なくとも以下の項目を期待すべきです：

• モデル識別子：APIが期待する正確な文字列。プロバイダーは名前を厳密にバージョン管理することが多いため（ここでの不一致は最も一般的な統合バグの1つです）。
• プロバイダー：どの企業やプラットフォームがモデルを提供しているか。カタログが複数のプロバイダーを集約する場合に関連します。
• モダリティサポート：テキスト、コード、画像、動画。Kimi K2.7 Code のようなコーディングモデルと Nano Banana Pro のような画像モデルを混在させるカタログには、エージェントが必要なものに基づいてフィルタリングできるフィールドが必要です。
• コンテキストウィンドウ：大規模なリポジトリで作業するコーディングエージェントにとって、トークン制限は非常に重要です。
• コストフィールド：入力トークンと出力トークンの価格。コーディングエージェントは入力負荷の高いワークロード（大きなファイルのコンテキスト、小さなdiff出力）になることが多いため、理想的にはこれらを分離します。
• ステータス：現在、非推奨、または廃止予定。これは、サイレントな故障を防ぐためのフィールドです。
• タスク適合性タグ：エージェントがすべてのモデルの特性を事前に知らなくてもフィルタリングできるように、「coding」、「low-cost routing」、「open-weight」などのオプションですが有用なメタデータ。

これらのフィールドのすべてが、すべてのプロバイダーのカタログ形式で存在するとは限りません。統合を構築する前に、使用しているプロバイダーで文書化されている実際のスキーマを確認してください。特にTokenLabが提供するモデルについては、カタログスキーマは新しいモデルやモダリティが追加されるにつれて変更されるため、この記事から推測するのではなく、/models/data で現在のフィールドセットと更新頻度を確認してください。

例：MCP経由でのモデルカタログのリクエスト

MCPは通常、JSON-RPC 2.0経由で通信します。クライアントがサーバーに利用可能なモデルリソースのリストを要求する場合、以下のようなリクエストを送る可能性があります。この例は一般的なMCPリソースリストパターンの説明であり、特定のプロバイダーのライブスキーマに関する主張ではありません。本番環境のコードを書く前に、https://docs.tokenlab.sh または使用しているMCPサーバー自身のドキュメントで、正確なメソッド名とレスポンスフィールドを確認してください。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {
    "filter": {
      "modality": "text",
      "tag": "coding"
    }
  }
}

考えられるレスポンスの形式（これも検証済みのスキーマではなく、例示です）：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "id": "claude-sonnet-5",
        "provider": "Anthropic",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["coding", "review"]
      },
      {
        "id": "deepseek-v4-flash",
        "provider": "DeepSeek",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["low-cost", "coding"]
      }
    ]
  }
}

コンテキストウィンドウの値、正確なフィールド名、または上記にリストされた特定のモデルを、ライブAPIに関する確定した事実として扱わないでください。これらはリクエストとレスポンスの形式を示すために存在しており、価格や能力の数値を述べるものではありません。それらの数値は、構築時にプロバイダー自身の最新のドキュメントまたは /models/data から常に取得してください。

タスク別のモデル選択：決定チェックリスト

モデルカタログは、エージェント（またはエージェントを設定する開発者）がタスクの種類とモデルを一致させるルールを持っている場合にのみ有用です。以下の表はフレームワークの出発点であり、ベンチマーク結果ではありません。本番環境でルーティングルールを確定させる前に、プロバイダーのドキュメントと /models で現在の価格と能力の主張を確認してください。

コーディングエージェントのタスク	最も重要なこと	評価すべきモデル例
オートコンプリート / インライン提案	低レイテンシ、呼び出しごとの低コスト	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
複数ファイルのリファクタリング	より大きなコンテキストウィンドウ、強力なコード推論	Claude Sonnet 5, DeepSeek V4 Pro
テスト生成	一貫したフォーマット、中程度の推論能力	Kimi K2.7 Code, Claude Sonnet 5
コードレビュー / PR要約	強力な推論能力、diffを正確に参照する能力	Claude Sonnet 5, Gemini 3.5 Flash
大量のバッチタスク（Linting、ドキュメントコメント）	生の能力よりもトークンあたりのコスト	GLM-5.2, Qwen3.7 Plus, MiniMax M3
オープンウェイト要件（セルフホストまたはライセンス制約）	オープンウェイト、マネージドAPI外でのデプロイ可能性	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

ルーティングロジック自体を構築するための実用的なチェックリスト：

1. 呼び出しが失敗する前に非推奨を検出できるように、カタログエントリにステータスフィールドが含まれているか？
2. フィルタリングにハードコードされたリストを必要としないように、カタログはコーディング可能なモデルを一般的なテキストや画像モデルと分離しているか？
3. タスクタイプごとにコスト上限を設定し、常に最も有能（かつ最も高価）なオプションをデフォルトにするのではなく、それを満たす最も安価なモデルをエージェントに選択させることができるか？
4. 選択肢が利用できない、またはレート制限がかかっている場合に備えて、すべてのタスクカテゴリに対してフォールバックモデルが定義されているか？
5. モデルのラインナップは時間とともに変化するため、最初の統合時だけでなく、定期的にカタログを再確認しているか？

このワークフローにおけるTokenLabの役割

TokenLabは、2026年7月14日時点で観測された /models/data のModel Data Centerと /models のモデルディレクトリを維持しています。モデルカタログは本質的に時間に敏感であるため、静的な記事に頼るのではなく、これらが現在のモデルリストを確認する場所となります。https://docs.tokenlab.sh にあるTokenLabのAPIドキュメントは、統合前に正確なリクエストおよびレスポンススキーマを確認する場所です。

レビュータスクには Claude Sonnet 5、安価で大量の補完には DeepSeek V4 Flash、テスト生成には Kimi K2.7 Code といったモデル間でルーティングを行うコーディングエージェントを構築している場合、実用的なパターンは、モデル識別子をエージェントのソースコードにコンパイルされた定数ではなく、リクエスト時にカタログに対して解決される変数として扱うことです。/models/data の現在のリストを確認し、ルーティングロジックを本番環境に組み込む前に、TokenLab APIドキュメントに対してMCPクライアントが必要とするリクエスト形式を確認することから始めてください。

制限事項

この記事では、MCPモデルカタログとコーディングエージェントのルーティングに関する一般的なパターンを説明しています。TokenLabを含む特定のプロバイダーが、上記で説明したすべてのフィールド（コンテキストウィンドウ、コストフィールド、ステータス、タスクタグ）を正確にこの形式で公開していることを保証するものではありません。スキーマ、フィールド名、利用可能なモデルは頻繁に変更されます。この記事のJSON例は、ライブエンドポイントの検証済みスキーマとしてではなく、MCPの一般的なリクエストおよびレスポンスパターンの例示として扱ってください。リリース前に、プロバイダーの最新のドキュメントおよび /models/data に対して、正確なモデル識別子、価格、コンテキストウィンドウを確認してください。

FAQ

MCP自体は標準的なモデルカタログスキーマを定義していますか？ MCPはJSON-RPC経由のリソースとツールに関する一般的なパターンを定義していますが、モデルカタログ内の正確なフィールド（価格、コンテキストウィンドウ、ステータス）は、MCPを実装するサーバーがそのデータをどのように公開するかによって異なります。統合先のサーバーまたはプロバイダーで特定のスキーマを確認してください。

コーディングエージェントは常に利用可能な最も有能なモデルを使用すべきですか？ 必ずしもそうではありません。オートコンプリートのようなタスクはレイテンシとコストに敏感ですが、複数ファイルのリファクタリングはより強力な推論とより大きなコンテキストの恩恵を受けます。タスクタグとコストフィールドを持つカタログを使用すれば、すべてに1つのモデルをデフォルトにするのではなく、タスクごとにルーティングできます。

エージェントが依存するモデルカタログをどのくらいの頻度で再確認すべきですか？ モデルのラインナップは頻繁に変更されるため、一度限りの統合では不十分です。モデル識別子を永続的にキャッシュするのではなく、カタログにクエリを投げるようにルーティングロジックを構築し、定期的なスケジュールで /models/data またはプロバイダーのドキュメントを確認してください。