メインコンテンツへスキップ
構造化出力により、AIエージェントが応答時に従うべきJSONスキーマを定義できます。これにより、他のシステム、API、自動化ワークフローと容易に統合できる一貫性のある機械可読な応答が保証されます。

概要

構造化出力により以下が可能になります:
  • 応答フォーマットの定義 - エージェント応答のためのカスタムJSONスキーマを作成
  • 一貫性の確保 - エージェントが常に同じ構造でデータを返すことを保証
  • 統合の有効化 - 応答を他のシステムが容易に消費できるようにする
  • パースの改善 - 複雑なテキストパースの必要性を排除

仕組み

1. JSONスキーマの作成

エージェントに従わせたい構造を定義します:
  • フィールド - 必須およびオプションのフィールドを指定
  • データ型 - 型を定義(string、number、boolean、array、object)
  • ネストされた構造 - 複雑なネストされたJSONオブジェクトを作成
  • - 明確さのために例の値を提供

2. エージェントに割り当て

エージェントの構造化出力スキーマを選択します:
  • 一般タブ - 利用可能な構造化出力から選択
  • エージェント固有 - 各エージェントが異なるスキーマを使用可能
  • 動的選択 - 必要に応じてスキーマを変更

3. エージェントの応答

有効にすると、エージェントは以下を行います:
  • JSONとしてフォーマット - 指定されたJSON構造で応答を返す
  • スキーマに準拠 - すべての必須フィールドを含む
  • 構造を維持 - ネストされたオブジェクトと配列を保持
  • フォーマットを検証 - 応答がスキーマと一致することを確認

構造化出力の作成

ステップ1:出力タブにアクセス

  1. サイドバーのエージェントに移動します
  2. エージェントを選択または新しいものを作成します
  3. 編集をクリックしてエージェントビルダーを開きます
  4. 出力タブに移動します

ステップ2:新しいスキーマを作成

  1. 新規作成ボタンをクリックします
  2. 構造化出力に説明的なタイトルを入力します
  3. JSONビルダーを使用してスキーマを定義します

ステップ3:スキーマ構造を定義

ビジュアルJSONビルダーを使用してスキーマを作成します:

基本構造

{
  "status": "string",
  "message": "string",
  "data": {
    "result": "string"
  }
}

配列付き

{
  "items": [
    {
      "id": "string",
      "name": "string",
      "value": "number"
    }
  ],
  "total": "number"
}

複雑なネスト構造

{
  "response": {
    "summary": "string",
    "details": {
      "category": "string",
      "subcategory": "string",
      "metadata": {
        "created_at": "string",
        "updated_at": "string"
      }
    },
    "items": [
      {
        "id": "string",
        "properties": {
          "name": "string",
          "value": "number"
        }
      }
    ]
  }
}

ステップ4:スキーマを保存

  1. 保存をクリックして構造化出力を保存します
  2. スキーマがエージェントで使用可能になりました

エージェントへの割り当て

方法1:一般タブから

  1. 設定するエージェントを開きます
  2. 一般タブに移動します
  3. 応答フォーマットセクションを見つけます
  4. ドロップダウンから構造化出力を選択します
  5. エージェントを保存します

方法2:出力タブから

  1. 設定するエージェントを開きます
  2. 出力タブに移動します
  3. リストから構造化出力を選択します
  4. エージェントはすべての応答にこのスキーマを使用します

ユースケース

API統合

シナリオ: エージェントの応答をAPIが消費できるフォーマットで必要とする場合。 スキーマ例:
{
  "status": "success",
  "code": 200,
  "data": {
    "result": "string",
    "timestamp": "string"
  }
}
エージェントの応答:
{
  "status": "success",
  "code": 200,
  "data": {
    "result": "Task completed successfully",
    "timestamp": "2024-01-15T10:30:00Z"
  }
}

データ抽出

シナリオ: 非構造化テキストから構造化データを抽出する場合。 スキーマ例:
{
  "entities": [
    {
      "type": "string",
      "value": "string",
      "confidence": "number"
    }
  ],
  "summary": "string"
}
エージェントの応答:
{
  "entities": [
    {
      "type": "person",
      "value": "John Doe",
      "confidence": 0.95
    },
    {
      "type": "company",
      "value": "TechCorp",
      "confidence": 0.88
    }
  ],
  "summary": "Extracted 2 entities from the text"
}

フォーマット付きレポート

シナリオ: 一貫したレポート構造を生成する場合。 スキーマ例:
{
  "report": {
    "title": "string",
    "date": "string",
    "sections": [
      {
        "heading": "string",
        "content": "string",
        "metrics": {
          "value": "number",
          "unit": "string"
        }
      }
    ],
    "summary": "string"
  }
}

ワークフロー自動化

シナリオ: 自動ワークフロー処理のために応答を構造化する場合。 スキーマ例:
{
  "action": "string",
  "parameters": {
    "key": "value"
  },
  "next_step": "string",
  "metadata": {
    "workflow_id": "string",
    "step_number": "number"
  }
}

ベストプラクティス

スキーマ設計

  1. 具体的に - すべてのフィールドとその型を明確に定義
  2. 例を使用 - スキーマに例の値を含める
  3. シンプルに保つ - 可能な限り過度に複雑なネスト構造は避ける
  4. フィールドを文書化 - 説明的なフィールド名を使用
  5. オプションフィールドを考慮 - 適切な場合はフィールドをオプションとしてマーク

フィールド命名

  • 明確な名前を使用 - unの代わりにuser_name
  • 一貫性を保つ - 命名規則に従う(snake_case、camelCase)
  • 略語を避ける - 可能な限り完全な単語を使用
  • 関連フィールドをグループ化 - 関連データにネストされたオブジェクトを使用

スキーマ構造

  • 可能な限りフラットに - シンプルなデータにはフラット構造を優先
  • 整理のためにネスト - 複雑な関連データにはネストを使用
  • リストには配列 - 類似アイテムのコレクションには配列を使用
  • グループにはオブジェクト - 関連フィールドをグループ化するためにオブジェクトを使用

テスト

  1. 実際のクエリでテスト - スキーマが実際のユーザーケースで機能することを確認
  2. すべてのフィールドを確認 - すべての必須フィールドが入力されていることを確認
  3. 型を検証 - データ型がスキーマと一致することを確認
  4. エッジケースを処理 - 異常または欠落したデータでテスト

構造化出力の管理

すべてのスキーマの表示

出力タブで以下ができます:
  • 全スキーマを一覧 - プロジェクトのすべての構造化出力を表示
  • 検索 - 名前でスキーマを検索
  • ソート - 作成日またはタイトルでソート
  • 詳細を表示 - スキーマ構造とメタデータを表示

スキーマの編集

  1. リストでスキーマをクリック
  2. ビジュアルビルダーを使用してJSON構造を変更
  3. 保存をクリックしてスキーマを更新
  4. 変更はこのスキーマを使用しているすべてのエージェントに適用

スキーマの削除

  1. リストでスキーマを見つける
  2. 削除アイコンをクリック
  3. 削除を確認
  4. このスキーマを使用していたエージェントは通常のテキスト応答に戻ります
構造化出力を削除すると、現在それを使用しているすべてのエージェントに影響します。 削除する前にこれらのエージェントを更新してください。

応答フォーマット

通常の応答(デフォルト)

構造化出力が選択されていない場合、エージェントはフリーフォームテキストを返します:
The user requested information about project status.
The project is currently in progress with 75% completion.
All milestones are on track.

構造化応答

構造化出力が選択されている場合、エージェントはJSONを返します:
{
  "status": "in_progress",
  "completion_percentage": 75,
  "milestones": [
    {
      "name": "Phase 1",
      "status": "completed"
    },
    {
      "name": "Phase 2",
      "status": "in_progress"
    }
  ],
  "on_track": true
}

システムプロンプトとの統合

構造化出力がエージェントに割り当てられると:
  1. スキーマが含まれる - JSONスキーマがシステムプロンプトに追加
  2. フォーマット指示 - エージェントが明示的なフォーマット指示を受け取る
  3. 例が提供される - スキーマがフォーマットの例として機能
  4. 検証 - エージェントが正確な構造に一致しようとする

高度な機能

動的フィールド値

スキーマには応答に適応するフィールドを含めることができます:
{
  "response_type": "string",
  "content": {
    "text": "string",
    "metadata": {}
  }
}

条件付き構造

異なる応答タイプに異なるスキーマを使用します:
{
  "type": "success|error|warning",
  "message": "string",
  "data": {} // Structure varies by type
}

配列配列応答

応複数アイテムを処理します:
{
  "count": "number",
  "items": [
    {
      "id": "string",
      "data": {}
    }
  ]
}

トラブルシューティング

エージェントがスキーマに従わない

考えられる原因:
  • スキーマがエージェントに割り当てられていない
  • スキーマ構造が複雑すぎる
  • エージェントにより明確な指示が必要
解決策:
  • 一般タブで構造化出力が選択されていることを確認
  • スキーマ構造を簡素化
  • より明示的なフィールド説明を追加
  • まずシンプルなクエリでテスト

無無効なJSON応答

考えられる原因:
  • スキーマに構文エラーがある
  • エージェントが複雑な構造で苦戦している
  • 必須フィールドが不足
解決策:
  • JSONビルダーでスキーマ構文を検証
  • JSON検証エラーを確認
  • 複雑すぎる場合はスキーマを簡素化
  • エージェントの応答でパースエラーを確認

フィールドの不足

考えられる原因:
  • フィールドが明確に定義されていない
  • エージェントがフィールド要件を理解していない
  • スキーマが曖昧すぎる
解決策:
  • 明確なフィールド説明を追加
  • スキーマに例の値を提供
  • 常に利用可能でない場合はフィールドをオプションにする
  • 特定のクエリでテスト

例1:カスタマーサポート応答

スキーマ:
{
  "ticket_id": "string",
  "status": "open|resolved|pending",
  "response": "string",
  "next_actions": ["string"],
  "priority": "low|medium|high|urgent"
}
エージェントの応答:
{
  "ticket_id": "TKT-12345",
  "status": "resolved",
  "response": "Your issue has been resolved. The problem was related to account permissions.",
  "next_actions": ["Refresh your browser", "Log out and log back in"],
  "priority": "medium"
}

例2:データ分析応答

スキーマ:
{
  "analysis": {
    "summary": "string",
    "findings": [
      {
        "category": "string",
        "insight": "string",
        "confidence": "number"
      }
    ],
    "recommendations": ["string"]
  },
  "data_points": "number"
}
エージェントの応答:
{
  "analysis": {
    "summary": "Sales data shows 15% increase in Q4",
    "findings": [
      {
        "category": "revenue",
        "insight": "Revenue increased by 15% compared to Q3",
        "confidence": 0.95
      },
      {
        "category": "customers",
        "insight": "New customer acquisition up 20%",
        "confidence": 0.88
      }
    ],
    "recommendations": [
      "Continue current marketing strategy",
      "Focus on customer retention"
    ]
  },
  "data_points": 1250
}

例3:タスク管理応答

スキーマ:
{
  "task": {
    "id": "string",
    "title": "string",
    "status": "todo|in_progress|completed",
    "assignee": "string",
    "due_date": "string",
    "description": "string"
  },
  "related_tasks": [
    {
      "id": "string",
      "title": "string"
    }
  ]
}

権限

構造化出力の作成

  • プロジェクト管理者 - 構造化出力の作成、編集、削除が可能
  • プロジェクトメンバー - プロジェクト権限に依存(flows.edit)
  • 閲覧者 - 構造化出力の表示のみ可能(変更不可)

エージェントでの使用

  • エージェントオーナー - 自分のエージェントに構造化出力を割り当て可能
  • プロジェクト管理者 - プロジェクト内の任意のエージェントに割り当て可能
  • プロジェクトメンバー - アクセスできるエージェントに割り当て可能

関連機能

  • エージェント設定 - エージェントのパーソナリティと行動を設定
  • ツール - 構造化データを返すツールを使用
  • API統合 - 構造化応答を外部APIと統合
  • ワークフロー - 自動ワークフローで構造化出力を使用

エージェント設定

エージェントの設定方法を学ぶ

サポート

構造化出力についてサポートが必要ですか?support@automationanywhere.comにご連絡ください。