Skip to main content
構造化された出力を使用すると、エージェントから返してほしいデータの正確な形状を定義できます。エージェントはタスクを完了するために必要なツールを使用でき、最後にスキーマに一致する検証済み JSON を取得できます。必要な構造の JSON Schema を定義すると、SDK は出力をそれに対して検証し、不一致の場合は再プロンプトします。検証が再試行制限内に成功しない場合、結果は構造化データではなくエラーになります。エラーハンドリング を参照してください。 完全な型安全性のために、Zod(TypeScript)または Pydantic(Python)を使用してスキーマを定義し、強く型付けされたオブジェクトを取得します。

構造化された出力が必要な理由

エージェントはデフォルトでは自由形式のテキストを返します。これはチャットには機能しますが、出力をプログラムで使用する必要がある場合には機能しません。構造化された出力は、アプリケーションロジック、データベース、または UI コンポーネントに直接渡すことができる型付きデータを提供します。 エージェントがウェブを検索してレシピを取得するレシピアプリを考えてみてください。構造化された出力がない場合、自分で解析する必要がある自由形式のテキストが得られます。構造化された出力を使用すると、必要な形状を定義し、アプリで直接使用できる型付きデータを取得できます。
これをアプリで使用するには、タイトルを解析し、‘15 分’を数値に変換し、材料と手順を分離し、応答全体で一貫性のない形式を処理する必要があります。
UI で直接使用できる型付きデータ。

クイックスタート

構造化された出力を使用するには、必要なデータの形状を説明する JSON Schema を定義し、outputFormat オプション(TypeScript)または output_format オプション(Python)を使用して query() に渡します。エージェントが完了すると、結果メッセージにはスキーマに一致する検証済みデータを含む structured_output フィールドが含まれます。 このページの例を実行する前に、クイックスタートに従って Claude Agent SDK をインストールしてください。以下の例は、エージェントに Anthropic を調査し、会社名、設立年、本社を構造化された出力として返すよう求めています。

Zod と Pydantic を使用した型安全なスキーマ

JSON Schema を手書きする代わりに、Zod(TypeScript)または Pydantic(Python)を使用してスキーマを定義できます。これらのライブラリは JSON Schema を生成し、応答を完全に型付けされたオブジェクトに解析できるため、オートコンプリートと型チェックを使用してコードベース全体で使用できます。 以下の例は、概要、ステップのリスト(各ステップに複雑さレベルを含む)、および潜在的なリスクを含む機能実装計画のスキーマを定義しています。エージェントは機能を計画し、型付けされた FeaturePlan オブジェクトを返します。その後、plan.summary などのプロパティにアクセスし、完全な型安全性を備えて plan.steps を反復処理できます。 SDK は JSON Schema draft-07 でスキーマを検証するため、より新しいバージョンを宣言するスキーマは拒否されます。Zod はデフォルトで draft 2020-12 をターゲットとするため、スキーマを変換する際に target: "draft-7" を渡してください。

出力形式の設定

outputFormat(TypeScript)または output_format(Python)オプションは、以下を含むオブジェクトを受け入れます:
  • type:構造化された出力の場合は "json_schema" に設定
  • schema:出力構造を定義する JSON Schema オブジェクト。Zod スキーマから z.toJSONSchema(schema, { target: "draft-7" }) で、または Pydantic モデルから .model_json_schema() で生成できます。
SDK は、すべての基本型(object、array、string、number、boolean、null)、enum、const、required、ネストされたオブジェクト、および $ref 定義を含む標準 JSON Schema 機能をサポートしています。サポートされている機能と制限の完全なリストについては、JSON Schema の制限 を参照してください。 有効な JSON Schema ではないスキーマは、問題を示すエラーで起動時に実行に失敗します。v2.1.205 より前は、無効なスキーマは暗黙的に無視され、エージェントは非構造化テキストを返していました。 "format": "email" などの format キーワードは、注釈として受け入れられ、SDK のバリデーターによって強制されません。v2.1.205 より前は、format を含むスキーマは無効として扱われていました。

例:TODO トラッキングエージェント

この例は、マルチステップツール使用で構造化された出力がどのように機能するかを示しています。エージェントはコードベース内の TODO コメントを見つけ、各コメントの git blame 情報を調べる必要があります。実行中に使用するツール(検索用の Grep、git コマンド実行用の Bash)を自律的に決定し、結果を単一の構造化応答に組み合わせます。 スキーマには、すべてのファイルで git blame 情報が利用できない可能性があるため、オプションフィールド(author と date)が含まれています。エージェントは見つけられるものを埋め、残りは省略します。

エラーハンドリング

構造化された出力の生成は、エージェントがスキーマに一致する有効な JSON を生成できない場合に失敗する可能性があります。これは通常、スキーマがタスクに対して複雑すぎる場合、タスク自体が曖昧な場合、またはエージェントが検証エラーを修正しようとして再試行制限に達した場合に発生します。また、検証の失敗がなくても発生する可能性があります。モデルフォールバックは既に完了した出力をストリーム中に取り消すことができ、再試行がそれを置き換えない場合、実行は同じエラーで終了します。スキーマをデバッグする前に、エラー結果メッセージの errors リストを確認して、2 つの原因を区別してください。 エラーが発生すると、結果メッセージには何が問題かを示す subtype があります: 結果は subtype が success でも structured_output 値がない場合に終了することもあります。例えば、実行がエージェントによる構造化出力の生成なしに完了した場合です。その場合も失敗として扱ってください。トラブルシューティングエントリ structured_output is None but the result says success がこのケースをカバーしています。以下の例は、subtype が success で structured_output が存在する場合にのみ結果を成功として扱い、他のすべての結果を失敗として処理します:
エラーを回避するためのヒント:
  • スキーマを焦点を絞ったものにしてください。 多くの必須フィールドを持つ深くネストされたスキーマは満たすのが難しいです。シンプルに始めて、必要に応じて複雑さを追加してください。
  • スキーマをタスクに合わせてください。 タスクがスキーマが必要とするすべての情報を持たない可能性がある場合、それらのフィールドをオプションにしてください。
  • 明確なプロンプトを使用してください。 曖昧なプロンプトは、エージェントが何を出力するかを知るのを難しくします。
  • JSON Schema ドキュメント:ネストされたオブジェクト、配列、列挙型、検証制約を含む複雑なスキーマを定義するための JSON Schema 構文を学習します
  • API 構造化出力:ツール使用なしの単一ターンリクエストの場合、Claude API で直接構造化された出力を使用します
  • カスタムツール:構造化された出力を返す前に実行中にエージェントが呼び出すカスタムツールを提供します