Claude Media
MCPのツール定義がJSON Schema 2020-12の全機能に対応

MCPのツール定義がJSON Schema 2020-12の全機能に対応

MCPの2026-07-28仕様改訂で、ツール定義のJSON Schemaが2020-12の全キーワードに対応しました。structuredContentの型拡大と$ref解決の安全要件も解説します。

MCPの2026-07-28仕様改訂で、ツール定義のinputSchemaoutputSchemaが受け付けるJSON Schemaのキーワード範囲が広がりました。$refanyOfoneOfallOfといった合成キーワードを使ったスキーマも、仕様の想定内として明記されています。同時にstructuredContentはJSONオブジェクト限定から任意のJSON値を返せるようになり、$refの解決と合成キーワードの計算量には新しく上限を課す要件が加わりました。SEP-2106として提案されたこの変更は、MCPサーバーを実装・保守する開発者と、そのサーバーをClaude Codeで動かす利用者の両方に関わります。

MCPツール定義のJSON Schemaで何が変わったか

MCPのツール定義とは、サーバーがtools/listで返すinputSchema(入力パラメータ)とoutputSchema(出力構造)という2つのJSON Schemaのことです。2026-07-28版の変更点(SEP-2106)は3つに整理できます。inputSchemaoutputSchemaが使えるJSON Schema 2020-12のキーワード範囲を広げたこと、structuredContentが返せる型を広げたこと、そして$refの解決と合成キーワードの計算量に新しい安全要件を課したことです。

デフォルトのスキーマ方言がJSON Schema 2020-12であること自体は、1つ前の2025-11-25版から変わっていません。変わったのは、ツール定義がそのキーワードをどこまで受け入れるかという範囲です。以前の仕様は受け入れ範囲がより限定的で、$refや合成キーワードを使った複雑なスキーマは想定外になりやすい状態でした。2026-07-28版はこの制限を外し、$refanyOfoneOfallOfを含む2020-12の任意のキーワードを使えるようにしています。

スキーマの許容範囲とstructuredContentの変化

3つの変更点は次の表のとおりです。

変更点2025-11-25版まで2026-07-28版以降
inputSchema / outputSchemaのキーワード範囲2025-11-25版まで受け入れ範囲が限定的2026-07-28版以降2020-12の任意のキーワードを許容($ref・anyOf・oneOf・allOf等)
structuredContentの型2025-11-25版までJSONオブジェクトのみ2026-07-28版以降任意のJSON値(配列・文字列・数値・真偽値・nullも可)
$refのネットワーク解決2025-11-25版まで明文の規定なし2026-07-28版以降既定で自動解決を禁止。許可制ならホスト許可リストと内部アドレス拒否が必須
合成キーワードの計算量2025-11-25版まで明文の規定なし2026-07-28版以降深さ・サブスキーマ数・検証時間に妥当な上限を課すことをSHOULD

structuredContentの変化は仕様書の一文そのものが書き換わっています。2025-11-25版は「structuredContentはJSONオブジェクトとして返される」と明記していました。2026-07-28版はこの一文を「任意のJSON値」に置き換えています。ユーザー一覧を返すツールの結果例で見ると次のようになります。

{
  "content": [{ "type": "text", "text": "Found 2 users: Alice and Bob." }],
  "structuredContent": [
    { "id": "1", "name": "Alice", "email": "alice@example.com" },
    { "id": "2", "name": "Bob", "email": "bob@example.com" }
  ]
}

配列そのものをstructuredContentに入れたこの結果は、2025-11-25版の文面どおりに読めば範囲外でした。2026-07-28版では正規の書き方です。

outputSchemaを宣言したツールには、型の許容範囲が広がった後も義務が変わらない部分があります。サーバーはoutputSchemaに適合する構造化結果を返さなければならず、クライアントはその結果をoutputSchemaと照合して検証すべきだという原則です。型が「オブジェクトのみ」から「任意のJSON値」に広がっても、宣言したスキーマとの整合性を取る責任そのものは両者に残ります。

既存のツール定義を書き直す必要があるかというと、方言を明示しているスキーマに限れば答えは「いいえ」です。$schemaフィールドでdraft-07など2020-12以外の方言を明示したスキーマは、2026-07-28版でも変わらず有効です。今回広がったのは、方言を省略したとき暗黙に前提とする2020-12スキーマが使えるキーワードの範囲であって、既存の明示的な方言指定を無効にする変更ではありません。

$refキーワードの解決に上限が必要になった理由

$refはJSON Schema 2020-12で絶対URIを指せます。仕様はここに新しい制約を課しました。実装は既定でネットワーク越しの$refを自動解決してはいけません。オプトインで解決する場合も、ホストの許可リストを用意するか、少なくともループバック・リンクローカル・プライベートアドレスへの参照を拒否し、タイムアウトとサイズ上限を設け、解決したURIをログに残す必要があります。

この要件が想定しているのは、悪意あるスキーマが検証器を通じて内部ネットワークへリクエストを送らせる攻撃です。ツール定義は外部のMCPサーバーから届く、信頼度の低い入力です。そこに含まれる$refをそのまま追いかけると、検証器自身がSSRF(サーバー側リクエスト偽造)の踏み台になります。

合成キーワード(anyOfoneOfallOfif/then/else)と$defsにも、同じ理由で上限が課されました。これらは表現力の高いスキーマを書けますが、検証コストも跳ね上がります。仕様はスキーマの深さ・サブスキーマの総数・検証1回あたりの時間予算のいずれかに、妥当な上限を設けることを勧めています。上限がないと、悪意あるスキーマが検証器へのサービス拒否(DoS)攻撃として働く恐れがあるからです。

この2つの要件に共通するのは、仕様が具体的な数値でなく原則だけを定めている点です。深さの上限を「5」や「10」と指定するのではなく、「妥当な上限を設けよ」という判断を各実装に委ねています。MCPサーバーやクライアントを実装する側は、自分のスキーマ検証ライブラリがこの2つの要件をどう満たしているかを個別に確認する必要があります。

Claude CodeはMCPツールをどう検証しているか

Claude Codeは、MCPサーバーから受け取ったツール定義をClaude APIへ送る前に、独自の検証を挟んでいます。ここでの挙動は、SEP-2106が緩めた合成キーワードの扱いと直接つながっています。

まず合成キーワードです。Claude APIはスキーマのルート直下にあるanyOfoneOfallOfを受け付けません。ネストしたpropertiesの中にある合成キーワードはそのまま送信されます。ルート直下に合成キーワードを持つツールも、それだけで使えなくなるわけではありません。Claude Codeは送信前にスキーマを1つのオブジェクトへ平坦化し、パラメータの組み合わせをツールの説明文に追記します。allOfは各分岐のpropertiesrequiredをすべて反映し、anyOfoneOfpropertiesをマージしたうえでrequiredの制約を説明文側に回す扱いです。

次にスキーマ全体の妥当性です。Claude Codeはv2.1.216以降、Claude APIが個別に課している2つのチェックを、ツール一覧を読み込んだ時点で自前でも実行します。1つはプロパティ名の文字種と長さで、トップレベルのプロパティ名はASCII文字・数字・_.-のみで1〜64文字という制約です。もう1つが、$schemaを省略したスキーマと2020-12を明示したスキーマを対象にした、2020-12メタスキーマへの適合チェックです。ここで失敗したツールは、そのサーバーの他のツールを道連れにせず、そのツール単体だけが除外されます。除外の理由はサーバーのログに記録され、Claudeにも「どのツールがなぜ除外されたか」が伝わる設計です。v2.1.195より前のバージョンは、ルート直下にanyOfoneOfallOfを持つツールを丸ごとスキップしていました。平坦化による救済が入ったのはそれ以降です。

MCPサーバー開発者が確認しておきたい3点

自分のMCPサーバーを2026-07-28版の仕様に合わせるなら、優先すべき確認は3つです。

  • 合成キーワードの配置: ルート直下のanyOf/oneOf/allOfは、Claude Code経由だと平坦化されて説明文頼みの緩い制約になります。厳密さが要るならpropertiesの中に置く設計のほうが確実です
  • structuredContentの型: クライアント側で常にオブジェクトとして扱うパーサーは、配列や文字列を返す新しいツールで壊れます。型を決め打ちしない実装にしておくと安全です
  • $refの解決ポリシー: 仕様は既定で自動解決を禁止する立場です。外部URLへの$refを動的に解決する設計にしているなら、許可リストと拒否条件を自分のサーバー側で明文化しておきます

構造化出力コマンドとの違い(--json-schema)

ここまでのJSON Schema 2020-12は、MCPのツール定義の話です。Claude Codeのclaude -p --json-schemaが検証するJSON Schemaとは別物です。

--json-schemaはClaudeの応答そのものを指定した構造に固定する、Agent SDKの構造化出力機能です。この検証はdraft-07を対象にしており、Zodなど2020-12を既定出力するライブラリからスキーマを生成する場合はtarget: "draft-7"の明示が必要になります。エラーメッセージや挙動の詳細はClaude Code --json-schemaエラーの直し方にまとめてあります。MCPのツール定義側とAgent SDKの構造化出力側で、2つの別々のJSON Schema検証が同じCLIの中に存在しています。

まとめ

2026-07-28版のMCP仕様は、ツール定義のJSON Schemaが使えるキーワードを広げ、structuredContentをオブジェクト限定から解放しました。一方で$ref解決と合成キーワードの計算量には、新しい安全要件が課されています。仕様書はこの安全要件を具体的な数値でなく原則で定めており、実装側の裁量に委ねられた範囲が広い変更です。

MCPサーバーを自作している場合は、ルート直下の合成キーワード・structuredContentの型・$refの解決ポリシーの3点を確認すると、この改定への追随が完了します。サーバーを自作する手順はMCPサーバー自作ガイド、同じ2026-07-28版で変わったOAuth認可の側面はリモートMCPのOAuth認証で扱っています。

この記事を共有:XはてブLinkedIn
MCP をもっと見る →