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

モデル名をハードコードしたコーディングエージェントは、いずれ午前2時に誰かを呼び出す（障害対応させる）ことになります。コーディングエージェント向けのMCPモデルカタログは、その障害モードを変えるものです。ソースコードに埋め込まれた文字列の代わりに、エージェントはリクエスト時に現在のモデル、コスト、モダリティ、ステータスフィールドの構造化リストを読み取ります。私たちはTokenLabで同様のカタログを維持しており、このカタログをルーティングの信頼できる唯一の情報源（Source of Truth）として扱っています。私たちのパイプラインでは、モデルの選択は定数ではなく、ルックアップ（検索）です。

なぜコーディングエージェントにマシンリーダブルなモデルデータが必要なのか

ほとんどのコーディングエージェントの統合は、10年前のAPI統合のような仕組みで動作しています。開発者がモデル名を選び、設定や環境変数に貼り付けてリリースします。これは、プロバイダーがそのモデルを非推奨にしたり、価格を変更したり、より優れた選択肢をリリースしたりするまでは機能します。しかし、そうなった場合、チームにはそれを採用するためのプロセスが存在しません。

マシンリーダブルなカタログは、この障害モードを変えます。モデルが引退したとき、エージェントはカタログにクエリを投げ、モデルが消滅したか、非推奨とマークされていることを確認し、ドキュメント化された代替案にフォールバックできます。開発者が新しいリリースごとに手動でベンチマークを行う代わりに、ツールがリスト化されたコンテキストウィンドウ、モダリティサポート、コストフィールドを比較してから切り替えることができます。

これは、本格的なモデルルーティングの前提条件でもあります。DeepSeek V4 FlashやGemini 3.5 Flashで安価かつ大量の補完を行いたい場合や、複数ファイルのリファクタリングにはClaude Sonnet 5を予約しておきたい場合などがあるでしょう。ルーティングロジックには依然として信頼できる情報源が必要です。その情報源には、どのモデルが現在有効か、コストはいくらか、何に対応しているかが記載されていなければなりません。それがなければ、ハードコードされたモデル名と同じように、ルーティングルールも陳腐化してしまいます。

TokenLabはこの問題について直接言及しています。より広範な議論についてはagent-readable model truthを、人間ではなくエージェントが主要な呼び出し元となる場合のAPI設計の変化についてはagent-first APIを参照してください。

重要なポイント

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

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

コーディングエージェントにとって有用なカタログエントリには、モデル名以上の情報が必要です。最低限、構築者と利用者は以下を確認できるべきです：

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

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

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

MCPは通常、JSON-RPC 2.0を介して通信します。クライアントがサーバーに対して利用可能なモデルリソースのリストを要求する場合、以下のような形式のリクエストを送信する可能性があります。この例は一般的なMCPのresource-listパターンに従っています。これは特定のプロバイダーのライブスキーマに関する主張ではありません。本番環境のコードを書く前に、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要約	強力な推論能力、差分を正確に参照する能力	Claude Sonnet 5, Gemini 3.5 Flash
大量のバッチタスク（リンティング、ドキュメントコメント）	純粋な性能よりもトークンあたりのコスト	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日時点で確認されたModel Data Centerを/models/dataで、モデルディレクトリを/modelsで維持しています。静的な記事に頼るのではなく、これらのインターフェースで現在のモデルリストを確認してください。モデルカタログは本質的に時間に敏感なものです。https://docs.tokenlab.shにあるTokenLabのAPIドキュメントは、統合前に正確なリクエストおよびレスポンススキーマを確認する場所です。

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

制限事項

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

FAQ

MCP自体は標準のモデルカタログスキーマを定義していますか？

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

コーディングエージェントは常に利用可能な最も高性能なモデルを使用すべきですか？

必ずしもそうではありません。オートコンプリートのようなタスクはレイテンシとコストに敏感ですが、複数ファイルのリファクタリングはより強力な推論と大きなコンテキストの恩恵を受けます。タスクタグとコストフィールドを備えたカタログがあれば、すべてを1つのモデルにデフォルト設定するのではなく、タスクごとにルーティングすることができます。

エージェントが依存するモデルカタログをどのくらいの頻度で再確認すべきですか？

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

まずは/models/dataの現在のリストを確認し、TokenLab APIドキュメントと照らし合わせてMCPクライアントが必要とするリクエスト形式を確認してから、ルーティングロジックを本番環境に組み込んでください。