ツールスキーマ検証

ツール定義を貼り付けて、拒否される理由や誤って呼ばれる理由を突き止めます。

ツール定義は社内のシステムやエンドポイントを説明します。すべてブラウザー内で点検され、送信されません。

定義を一から作る

ツールスキーマ検証 について

ツール定義には二種類の問題が住んでいます。一つは構造上のもの。JSON Schema の型でない型、プロパティに無い required 名、items のない配列、strict モードが課す規則を欠いた strict。これらは拒否されますが、返るメッセージはたいてい項目名を告げても理由は告げません。もう一つの種類は完全に妥当なまま別の問題を起こします。ツールが誤ったタイミングで、あるいはもっともらしい出鱈目を引数に入れて呼ばれる。スキーマのどこにも意味が書かれていないからです。ここでは両方を点検し、各指摘をその出どころのパスとともに報告し、貼り付けられた形は何であれ受け付けます。単体のツール、配列、リクエストの断片、あるいはスキーマだけでも。

機能

• 単体・配列・tools 断片・スキーマ単体のいずれも受け付け
• 各指摘にその出どころのパスを付与
• 個々のプロパティも含めて不正な型を検出
• プロパティにない required 名を検出
• strict モードの規則を適用し、違反しているプロパティを名指し
• 誤ったキーの下にあるスキーマを指摘
• 配列内でのツール名の重複を検出
• 説明のないパラメーターと空の列挙に警告

ツールスキーマ検証 の使い方

1. 手元にある形のまま定義を貼り付けます
2. パス付きの指摘を読みます
3. まずエラーを、次に説明文を直します
4. 何も残らなくなるまで点検を繰り返します

例

入力

"required": ["email", "customer_id"]

出力

Error: “customer_id” is required but is not among the properties

対応するプロパティのない required 名は、そのまま拒否されます。

よくあるエラーとトラブルシューティング

• API がツールを拒否するのに項目名を教えてくれない。 — ここに貼ってください。指摘にはパスが付くので、問題のノードが名指しされ、探し回らずに済みます。
• スキーマのキーが違うと言われる。 — Messages API が読むのは input_schema です。他の流儀で書かれた定義は parameters を使いがちで、JSON として妥当なまま単に読まれません。
• 正しく見えるスキーマで strict が失敗する。 — strict には additionalProperties: false と、すべてのプロパティの required が要ります。両方を点検し、違反しているプロパティを名指しします。
• エラーではなく説明文の警告ばかり出る。 — それが二つ目の種類の問題です。ツールが受理されることは妨げませんが、誤った引数で呼ばれる原因になります。

よくある質問

どんな形を貼れますか。

ツールのオブジェクト、その配列、{"tools": [...]} の断片、あるいは入力スキーマ単体です。スキーマ単体は認識されて注記されます。ツールには名前と説明も要るからです。

なぜ説明の欠落を警告するのですか。

ツールが誤って呼ばれる最大の原因でありながら、決してエラーにならないからです。名前だけで説明のないパラメーターは、意味を名前から推測させることになります。

実際の引数と突き合わせて検証しますか。

いいえ、定義そのものを点検します。特定の引数が検証を通るかは別の問いで、呼び出したときに API が答えます。

$ref には対応していますか。

指摘の対象です。ツールスキーマでは参照が確実に解決されるとは限らず、それに頼った定義は書いた人が読んだのと違う挙動をしがちです。定義を展開して書けばこの問いは消えます。

複数のツールをまとめて点検できますか。

はい、配列ごと貼ってください。集合内の名前の重複を検出します。ツールをまとめて見たときにしか現れない問題です。

関連ツール

• MCP ツールスキーマ — ツールを定義し、strict モードを検証した JSON Schema を得ます。
• MCP サーバー設定 — stdio、HTTP、SSE 向けの MCP サーバー設定を生成します。
• SSE ストリームビューア — 生のストリーミング応答から本文、ツール呼び出し、使用量を取り出します。
• システムプロンプトリンター — 矛盾、効かない指示、未置換のプレースホルダーを見つけます。
• JSONL ビューア・検証 — JSONL ファイルを行単位で読み、絞り込み、検証します。
• サブエージェントビルダー — ツールとモデルを指定してサブエージェント定義ファイルを作ります。

AI・エージェントの他のツール

• スキルビルダー — SKILL.md を作成し、frontmatter を入力しながら検証します。
• スキルリンター — SKILL.md を貼り付け、タスクに一致しない理由を確かめます。
• サブエージェントビルダー — ツールとモデルを指定してサブエージェント定義ファイルを作ります。
• スラッシュコマンドビルダー — 引数とツール許可リストを備えた独自コマンドを作ります。
• プロジェクト指示ビルダー — 毎リクエストの費用に見合う CLAUDE.md を書きます。
• プラグインマニフェスト — plugin.json を生成し、前提となるフォルダ構成を確認します。
• フックビルダー — settings.json のフックを作り、発火しないマッチャーを見つけます。
• 権限ルールテスター — 許可・確認・拒否のルールを実際のコマンドで試します。
• MCP サーバー設定 — stdio、HTTP、SSE 向けの MCP サーバー設定を生成します。
• MCP ツールスキーマ — ツールを定義し、strict モードを検証した JSON Schema を得ます。
• プロンプトテンプレート展開 — 一つのプロンプトを行の表に展開し、欠けている値を確認します。
• システムプロンプトリンター — 矛盾、効かない指示、未置換のプレースホルダーを見つけます。
• プロンプト差分 — 二つの版を単語単位で比較し、トークン差も表示します。
• Few-shot 例ビルダー — 入出力の組をタグ付き、JSON、会話形式の例に変換します。
• XML プロンプト構成 — 内容が外に漏れないタグでプロンプトの各節を囲みます。
• JSONL ビューア・検証 — JSONL ファイルを行単位で読み、絞り込み、検証します。
• 会話ログ変換 — メッセージ配列を読みやすい記録に変換し、元にも戻します。
• 学習データ検証 — 学習を途中で止めるエラーがないか chat 形式の JSONL を調べます。
• SSE ストリームビューア — 生のストリーミング応答から本文、ツール呼び出し、使用量を取り出します。
• コンテキストウィンドウ設計 — ウィンドウをプロンプト、ツール、履歴、応答に配分します。
• プロンプトキャッシュ設計 — キャッシュできる接頭辞が最長になるようブロックを並べ替えます。
• テキスト分割 — 実際の切れ目で分かれる重なり付きのチャンクに文書を分けます。
• エージェントループ費用 — 再送される履歴とキャッシュを含めてターンごとに費用を見積もります。
• バッチリクエストビルダー — 行の表をバッチ処理に変換し、各リクエストに一意の ID を付けます。

AI・エージェントのツールをすべて見る · すべてのツール