LLM構造化出力：JSON Schema強制とツール呼び出しの信頼性保証

深夜3時、スマホが震えた——本番環境からのアラートだ。ログを開くと、エージェントのツール呼び出しが失敗し、5回連続でリトライしている。すべてパラメータの形式エラーだ。cityフィールドは"北京"であるべきなのに、LLMが返したのは{"name": "北京", "id": null}だった。パーサーがクラッシュし、データ処理パイプライン全体が停止した。

これは昨年私が踏んだ大きな穴だった。

その後、私はLLMの構造化出力問題を体系的に研究し始めた。OpenAIのStructured OutputsからAnthropicのTool Use、Instructorの自動リトライからOutlinesの制約付きデコードまで。正直、最初は「プロンプトをちゃんと書けば解決できる」問題だと思っていた。しかし、これはプロンプトの問題ではなく、信頼性アーキテクチャの問題だと気づいた。

この記事で共有したいのは、「三層信頼性保証アーキテクチャ」だ。パラメータ検証層、失敗リトライ層、制約付きデコード層。記事の最後では、OpenAI、Claude、Gemini三家の実装を横比較し、どう選ぶべきか、いつ何を使うべきかを説明する。ついでに本番級のコードテンプレートもいくつか提供するので、そのまま使ってほしい。

一、なぜ構造化出力はエージェントの基石なのか

まず、私が遭遇した「形式ドリフト」問題について話そう。これは特殊なケースではなく、エージェント開発に携わるすべての人が直面する悪夢だ。

形式ドリフトの3つのパターン

第一：フィールド欠損。 LLMにname、age、emailを含むユーザー情報オブジェクトを返すよう要求したが、返ってきたのは{"name": "张三"}——後ろの2つのフィールドが消えている。毎回欠けるわけではない、時々欠けるだけだ。本番環境では、「時々」は「必ず」を意味する。

第二：型エラー。 ドキュメントにはuser_idは整数と明記されている。しかしLLMが返したのは"user_id": "12345"、文字列だ。PythonのPydantic検証が即座にエラーを吐き、呼び出しチェーン全体が断裂する。

第三：余分な内容。 最も隠れたパターンだ。JSONを返すよう指示したのに、前に”Here is the response:“を付け、後ろに”I hope this helps!”を付けてくる。JSONパーサーはこれを見て混乱する。

vs

OpenAIの公式データは問題をよく示している。JSON Mode（有効なJSONを返すことだけを保証）の失敗率は5〜10%、一方Structured Outputs（Schemaへの準拠を強制）の失敗率は0.1%未満だ。2桁の差がある。

なぜこれが重要なのか

「解析失敗したら、リトライを何回か追加すればいいじゃないか」と思うかもしれない。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

問題は、リトライにはコストがかかることだ。

API呼び出しコスト。 GPT-4の1回の呼び出しは数角銭かかるかもしれないが、5回リトライすれば数元になる。エージェントが毎日10万リクエストを処理し、各リクエストが平均2回リトライするとしたら——この計算は自分でやってほしい。

遅延の蓄積。 1回の呼び出しに2秒、3回リトライすれば、ユーザーは6秒以上待つことになる。リアルタイム対話シナリオでは、これは許容できない。

ユーザー体験の崩壊。 ユーザーが天気を聞き、エージェントが止まり、10秒間スピナーが回り続け、最後に「システムエラー」を返す。次は来なくなる。

したがって、構造化出力は「锦上添花」ではなく、エージェントが安定して動作できるかどうかの基石だ。次に、この問題をどう解決するか話そう——「プロンプトをちゃんと書く」ではなく、信頼できるアーキテクチャによって。

二、三層信頼性保証アーキテクチャ

このアーキテクチャは、多くの穴を踏んだ後に私がまとめたものだ。銀の弾丸ではないが、形式エラーに遭遇する確率を5〜10%から限りなくゼロに近づけることができる。

L1：パラメータ検証層——第一の防衛線

この層が行うことはシンプルだ。Pydanticで期待するデータ構造を定義し、型強制変換とホワイトリストフィルタリングを行う。

from pydantic import BaseModel, Field, field_validator
from typing import Optional, List
from datetime import datetime

class ToolCallParams(BaseModel):
    """ツール呼び出しパラメータモデル"""
    city: str = Field(..., min_length=1, max_length=50, description="都市名")
    date: Optional[datetime] = Field(None, description="照会日")
    units: str = Field("metric", pattern="^(metric|imperial)$")

    @field_validator("city")
    @classmethod
    def validate_city(cls, v: str) -> str:
        # ホワイトリスト検証
        allowed_cities = {"北京", "上海", "広州", "深圳", "杭州"}
        if v not in allowed_cities:
            raise ValueError(f"サポートしていない都市: {v}。現在サポート: {allowed_cities}")
        return v

Pydanticは3つのことを行う。型強制変換（文字列”123”を整数123に変換）、フィールド欠損検出、カスタム検証。これが最も基礎的で最も重要な層だ。

L2：失敗リトライ層——フィードバック付き自己修正

LLMが返したデータの検証に失敗した時、単純にリトライするのではなく、エラー情報をフィードバックとして戻し、自分で修正させる。Instructorというライブラリはこれをうまくカプセル化している。

import instructor
from openai import OpenAI
from pydantic import ValidationError

client = instructor.patch(OpenAI())

def get_weather_with_retry(user_query: str, max_retries: int = 3):
    """エラーフィードバック付きリトライメカニズム"""
    messages = [{"role": "user", "content": user_query}]

    for attempt in range(max_retries):
        try:
            response = client.chat.completions.create(
                model="gpt-4o",
                response_model=ToolCallParams,  # Pydanticモデル
                messages=messages,
                temperature=0.1  # 構造化出力では低温を使用
            )
            return response  # 自動検証通過

        except ValidationError as e:
            # エラーをLLMにフィードバックして修正させる
            error_msg = f"パラメータ検証失敗: {str(e)}\n修正して正しいJSON形式で再送してください。"
            messages.append({"role": "assistant", "content": "パラメータ生成中..."})
            messages.append({"role": "user", "content": error_msg})

            if attempt == max_retries - 1:
                raise Exception(f"{max_retries}回リトライしても失敗: {e}")

# 使用例
result = get_weather_with_retry("北京の明日の天気を調べて")

核となる考え方は、LLMは闇雲に推測しているのではなく、どこが間違っているか、なぜ間違っているかを知っているということだ。フィードバックを与えれば、修正できる。実測では、このフィードバックメカニズムを追加することで、リトライ成功率が60%から95%以上に向上した。

L3：制約付きデコード層——源頭でエラーを杜絶

最初の2層は「事後救済」だが、L3は「事前予防」だ。

制約付きデコードの原理はこうだ。LLMが各トークンを生成する際、有限オートマトン（FSM）を通じて選択範囲を制限し、Schemaに準拠したトークンシーケンスだけを生成できるようにする。これはLLMに「ブレーキ」を取り付け、出力を乱したくてもできないようにするようなものだ。

実装方法には2つの主流の選択肢がある。

Outlines（オープンソース方式、ローカルモデル向け）：

from outlines import models, generate
import json

# ローカルモデルをロード
model = models.transformers("Qwen/Qwen2.5-7B-Instruct")

# Schemaを定義
schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "age": {"type": "integer"}
    },
    "required": ["name", "age"]
}

# 制約付きジェネレーターを作成
generator = generate.json(model, schema)
result = generator("ユーザー情報を抽出: 张三は今年28歳")
# 100% Schemaに準拠、リトライ不要

vLLMのguided_json（大規模モデルのデプロイ向け）：

from vllm import LLM, SamplingParams

llm = LLM(model="Qwen/Qwen2.5-72B-Instruct")
sampling_params = SamplingParams(
    temperature=0.0,
    guided_decoding_backend="outlines",
    guided_json={  # JSON Schemaを直接渡す
        "type": "object",
        "properties": {
            "tool_name": {"type": "string"},
            "arguments": {"type": "object"}
        }
    }
)

L3の代償は、追加のコンパイルオーバーヘッドがあることだ。FSMはSchemaに基づいて事前に構築する必要がある。Schemaが頻繁に変更される場合、FSMを毎回再構築する遅延が発生する。しかし、ほとんどのエージェントアプリケーションでは、Schemaは比較的安定しており、このオーバーヘッドは許容範囲内だ。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

三層の使い分け

三、プロバイダー横比較：OpenAI、Claude、Geminiの選び方

この章では、各プロバイダーの実装の違いについて話そう。正直、横比較をしないと、簡単に穴に落ちる——各プロバイダーの「構造化出力」の概念と実装方式は大きく異なるからだ。

OpenAI：Strict Mode、強制準拠

OpenAIは2024年8月にStructured Outputs機能をリリースした。これは現在、商用APIの中で最も信頼性の高い方式だ。

核となるメカニズムはstrict: trueパラメータだ。これを有効にすると、LLMの出力は定義したJSON Schemaに強制的に制約され、100%準拠が保証される。その裏側では制約付きデコード技術（Grammar-based Constrained Decodingベース）が使われており、原理はOutlinesと似ている。

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "ユーザー情報を抽出"}],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "user_info",
            "strict": True,  # 重要なパラメータ
            "schema": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "age": {"type": "integer"}
                },
                "required": ["name", "age"]
            }
        }
    }
)
# 出力は100% Schemaに準拠

OpenAIの公式データによると、Strict Modeの失敗率は0.1%未満だ。実際に使ってみても、形式エラーに遭遇したことはない。ただし制限もある。再帰Schemaはサポートされておらず、一部の複雑なネスト構造は回避策が必要だ。

Anthropic Claude：Tool Use、準拠保証なし

Claudeの構造化出力は別の道を歩んでいる——Tool Use（ツール呼び出し）だ。

ツールを定義すると、Claudeはそれを呼び出してパラメータを渡す。しかし、ここに落とし穴がある。Claudeのstrictパラメータは設定できるが、公式ドキュメントで明確に述べられている——これは無視される。Claudeはパラメータが必ず定義したSchemaに準拠することを保証しない。

これはAnthropic公式ドキュメントの原文だ（2026年4月更新）：

“The strict parameter is currently ignored for tool definitions. Claude will make a best effort to provide valid arguments, but does not guarantee schema compliance.”

要するに、ベストを尽くすが保証はしない。したがって、Claudeでツール呼び出しを行う場合、必ずL1（パラメータ検証）とL2（失敗リトライ）を追加する必要がある。

import anthropic

client = anthropic.Anthropic()

# Claudeのツール定義
tools = [{
    "name": "get_weather",
    "input_schema": {
        "type": "object",
        "properties": {
            "city": {"type": "string"}
        },
        "required": ["city"]
    }
}]

response = client.messages.create(
    model="claude-3.5-sonnet",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "北京の天気"}]
)

# 重要：tool_useのパラメータを手動で検証する必要がある
for block in response.content:
    if block.type == "tool_use":
        # ここでPydantic検証を行う
        validated_params = ToolCallParams.model_validate(block.input)

Google Gemini：Controlled Generation

Geminiの方式はControlled Generationと呼ばれ、response_schemaパラメータで出力構造を指定する。

import google.generativeai as genai

model = genai.GenerativeModel('gemini-1.5-pro')

response = model.generate_content(
    "ユーザー情報を抽出",
    generation_config={
        "response_mime_type": "application/json",
        "response_schema": {
            "type": "object",
            "properties": {
                "name": {"type": "string"},
                "age": {"type": "integer"}
            },
            "required": ["name", "age"]
        }
    }
)

Geminiの信頼性はOpenAIとClaudeの中間にある。制約はあるが、OpenAIのような「強制準拠」の力強さはない。実測では失敗率は約1〜2%で、JSON Modeよりは良いが、Strict Modeのレベルには達していない。

オープンソースモデル：Outlines/vLLMに依存

オープンソースモデル（Qwen、Llama、Mistralなど）自体は構造化出力をサポートしておらず、外部ツールが必要だ。主流の方式は、先に述べたOutlinesとvLLMのguided_jsonだ。

興味深い点がある。オープンソースモデルとOutlinesを組み合わせると、構造化出力の信頼性は逆に一部の商用APIより高くなる。FSMはハード制約であり、「ベストを尽くすが保証しない」状況が存在しないからだ。

選択ガイド

四、実践的コードテンプレート

この章では、いくつかの本番級のコードテンプレートを紹介する。これらのコードはすべて本番環境で検証済みだ。そのまま使ってほしい。

テンプレート一：OpenAI Structured Outputs完全例

"""
OpenAI Structured Outputs完全例
適用シナリオ：ツール呼び出し、データ抽出、レポート生成など
"""
from openai import OpenAI
from pydantic import BaseModel, Field
from typing import List, Optional
import json

# 1. Pydanticモデルを定義
class SearchQuery(BaseModel):
    """検索クエリパラメータ"""
    keywords: List[str] = Field(
        ...,
        min_length=1,
        max_length=5,
        description="検索キーワードリスト"
    )
    filters: Optional[dict] = Field(
        default=None,
        description="オプションのフィルタ条件"
    )
    limit: int = Field(
        default=10,
        ge=1,
        le=100,
        description="返却結果数"
    )

# 2. PydanticモデルをJSON Schemaに変換
def model_to_schema(model: type[BaseModel]) -> dict:
    """PydanticモデルをJSON Schemaに変換"""
    schema = model.model_json_schema()
    # Pydanticが追加したメタデータをクリーンアップ
    schema.pop("title", None)
    for prop in schema.get("properties", {}).values():
        prop.pop("title", None)
    return schema

# 3. 構造化出力呼び出し
client = OpenAI()

def extract_search_params(user_input: str) -> SearchQuery:
    """ユーザー入力から検索パラメータを抽出"""
    schema = model_to_schema(SearchQuery)

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {
                "role": "system",
                "content": "あなたは検索アシスタントです。ユーザーが検索パラメータを抽出するのを助けます。"
            },
            {"role": "user", "content": user_input}
        ],
        response_format={
            "type": "json_schema",
            "json_schema": {
                "name": "search_query",
                "strict": True,
                "schema": schema
            }
        },
        temperature=0.1  # 構造化出力では低温を使用
    )

    # 4. 解析して二次検証
    raw_content = response.choices[0].message.content
    data = json.loads(raw_content)
    return SearchQuery.model_validate(data)

# 使用例
if __name__ == "__main__":
    query = extract_search_params(
        "Pythonの非同期プログラミングに関する記事を探しています。直近1ヶ月のものだけで、最大20件"
    )
    print(query)
    # SearchQuery(keywords=['Python', '非同期プログラミング'], filters={'date_range': 'last_month'}, limit=20)

テンプレート二：Instructor自動リトライ例

"""
Instructor自動リトライ例
適用シナリオ：Claude API、OpenAI JSON Mode（非Strict）、フォールトトレランス必要なシナリオ
"""
import instructor
from openai import OpenAI
from pydantic import BaseModel, Field, ValidationError

class AgentAction(BaseModel):
    """エージェント行動決定"""
    action_type: str = Field(
        ...,
        pattern="^(search|execute|respond|clarify)$"
    )
    parameters: dict = Field(default_factory=dict)
    reasoning: str = Field(..., min_length=10)

# OpenAIクライアントにパッチを当てる
client = instructor.patch(OpenAI())

def get_agent_decision(
    context: str,
    user_request: str,
    max_retries: int = 3
) -> AgentAction:
    """
    エージェントの行動決定を取得（自動リトライ付き）

    Args:
        context: 現在の会話コンテキスト
        user_request: ユーザーリクエスト
        max_retries: 最大リトライ回数

    Returns:
        AgentAction: 検証済みの行動決定
    """
    messages = [
        {"role": "system", "content": "あなたはインテリジェントアシスタントです。ユーザーのニーズを分析し、次のアクションを決定します。"},
        {"role": "user", "content": f"コンテキスト: {context}\n\nユーザーリクエスト: {user_request}"}
    ]

    try:
        response = client.chat.completions.create(
            model="gpt-4o",
            response_model=AgentAction,  # Instructorが自動検証
            messages=messages,
            max_retries=max_retries,  # 組み込みリトライ
            temperature=0.1
        )
        return response

    except ValidationError as e:
        # Instructorはすでにmax_retries回リトライしている
        raise Exception(f"形式エラーを修復できません。モデル定義を確認してください: {e}")

# 使用例
decision = get_agent_decision(
    context="ユーザーは天気情報を照会中",
    user_request="北京の明日の天気を調べて、晴れならアウトドア活動を提案して"
)
print(f"アクションタイプ: {decision.action_type}")
print(f"パラメータ: {decision.parameters}")
print(f"推論過程: {decision.reasoning}")

テンプレート三：Outlinesローカルモデル構造化出力

"""
Outlinesローカルモデル構造化出力例
適用シナリオ：プライベートデプロイ、コスト重視、プライバシー要求が高いシナリオ
"""
from outlines import models, generate
from pydantic import BaseModel
from typing import List
import json

# データ構造を定義
class ProductInfo(BaseModel):
    """商品情報"""
    name: str
    price: float
    category: str
    tags: List[str]

# モデルをロード（初回ロードは数秒の遅延がある）
model = models.transformers("Qwen/Qwen2.5-7B-Instruct")

# 構造化ジェネレーターを作成
# 注意：schemaは初回呼び出し時にFSMにコンパイルされ、約1〜2秒のオーバーヘッドがある
schema_str = json.dumps(ProductInfo.model_json_schema())
generator = generate.json(model, schema_str)

def extract_product_info(description: str) -> ProductInfo:
    """
    商品記述から構造化情報を抽出

    Args:
        description: 商品説明テキスト

    Returns:
        ProductInfo: 構造化された商品情報
    """
    prompt = f"以下の商品記述から重要な情報を抽出し、JSON形式で返してください:\n{description}"

    # 生成結果は100% Schemaに準拠
    result = generator(prompt)

    # Pydanticモデルに変換（二次検証、万全を期す）
    return ProductInfo.model_validate(result)

# 使用例
description = """
このBluetoothイヤホンは最新のノイズキャンセリング技術を採用、価格は299元、
デジタルアクセサリカテゴリに属し、スポーツ、通勤などのシーンに適しています。
"""
product = extract_product_info(description)
print(product)
# ProductInfo(name='Bluetoothイヤホン', price=299.0, category='デジタルアクセサリ', tags=['スポーツ', '通勤'])

テンプレート四：完全なツール呼び出しフロー

"""
完全なツール呼び出しパラメータ検証フロー
含む：Schema定義 → LLM呼び出し → パラメータ検証 → 失敗リトライ → ツール実行
"""
from openai import OpenAI
from pydantic import BaseModel, Field, field_validator, ValidationError
from typing import Callable, Dict, Any
import json

# 1. ツールパラメータモデルを定義
class WeatherQueryParams(BaseModel):
    """天気照会ツールパラメータ"""
    city: str = Field(..., min_length=1, max_length=50)
    date_offset: int = Field(default=0, ge=-7, le=7, description="日付オフセット、0は今日")

    @field_validator("city")
    @classmethod
    def validate_city(cls, v: str) -> str:
        allowed = {"北京", "上海", "広州", "深圳", "杭州", "成都", "武漢"}
        if v not in allowed:
            raise ValueError(f"サポートしていない都市。選択可能: {allowed}")
        return v

# 2. ツール呼び出しマネージャー
class ToolCallManager:
    """ツール呼び出しの完全なフローを管理"""

    def __init__(self):
        self.client = OpenAI()
        self.tools: Dict[str, Callable] = {}

    def register_tool(self, name: str, func: Callable, param_model: type[BaseModel]):
        """ツールを登録"""
        self.tools[name] = {
            "function": func,
            "param_model": param_model
        }

    def execute_with_retry(
        self,
        tool_name: str,
        user_request: str,
        max_retries: int = 3
    ) -> Any:
        """ツール呼び出しを実行（リトライ付き）"""

        tool_config = self.tools[tool_name]
        param_model = tool_config["param_model"]
        schema = param_model.model_json_schema()

        messages = [
            {"role": "system", "content": f"ツール '{tool_name}' の呼び出しパラメータを抽出"},
            {"role": "user", "content": user_request}
        ]

        for attempt in range(max_retries):
            try:
                # LLMを呼び出してパラメータを取得
                response = self.client.chat.completions.create(
                    model="gpt-4o",
                    messages=messages,
                    response_format={
                        "type": "json_schema",
                        "json_schema": {
                            "name": tool_name,
                            "strict": True,
                            "schema": schema
                        }
                    },
                    temperature=0.1
                )

                # パラメータを検証
                params = param_model.model_validate_json(
                    response.choices[0].message.content
                )

                # ツールを実行
                return tool_config["function"](params)

            except ValidationError as e:
                # エラーをフィードバックしてLLMに修正させる
                messages.append({
                    "role": "user",
                    "content": f"パラメータ検証失敗: {e}\nパラメータ形式を修正してください。"
                })
                continue

        raise Exception(f"ツール呼び出し失敗、{max_retries}回リトライしても検証を通過できません")

# 3. 使用例
def get_weather(params: WeatherQueryParams) -> str:
    """天気照会をシミュレート"""
    # ここに実際のAPI呼び出しロジックが入る
    return f"{params.city}の今後{params.date_offset}日間は晴れ"

manager = ToolCallManager()
manager.register_tool("get_weather", get_weather, WeatherQueryParams)

result = manager.execute_with_retry(
    "get_weather",
    "北京の明日の天気を調べて"
)
print(result)  # 北京の今後1日間は晴れ

これらのテンプレートは、最も一般的なシナリオをカバーしている。実際に使用する際は、ニーズに合わせて組み合わせや修正ができる。

五、本番環境のベストプラクティス

コードは書けたが、本番環境にはまだ細かい注意点がたくさんある。ここでは、私が踏んだ穴とその対策をいくつか共有する。

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

Temperature設定：高くしないで

構造化出力シナリオでは、Temperatureを0.0〜0.2の間に設定することをお勧めする。この範囲はOpenAI公式ドキュメントが推奨しているもので、実測でも最も安定している。

温度が高いとどうなるか？LLMはより「発散的」になり、出力がよりランダムになる。ランダム性は構造化出力の敵だ。求めているのは確実性であって、創造性ではない。以前、Temperatureを0.7に設定したところ、形式エラー率が15%に急上昇した。その後0.1に変更したところ、基本的に問題は発生しなくなった。

リトライ戦略：すべてのエラーをリトライすべきではない

リトライする前に、まずエラーの種類を判断する：

すべてのエラーを無限にリトライする人を見たことがある。結果として、ある都市名がホワイトリストになく、LLMが10回推測しても当たらず、最終的にタイムアウトでクラッシュした。エラーの種類を区別してこそ、効率的に処理できる。

パフォーマンスオーバーヘッド比較

選択時はトレードオフを考慮する必要がある。極限の安定性を追求するなら、Structured OutputsまたはOutlinesを選ぶ。迅速なプロトタイピングなら、Instructorの自動リトライを使う。予算が限られているなら、JSON Mode + 手動検証でもなんとかなる。

監視指標：必見の3つ

リリース後、これらの指標は必ず監視する：

1. 形式失敗率：検証失敗したリクエストの割合。1%を超えたら調査が必要。
2. 平均リトライ回数：正常値は0.5〜1.5の間。2回を超えたら、モデルまたはSchemaに問題がある。
3. 平均遅延：構造化出力は通常の出力より50〜200ms遅くなるが、許容範囲内に抑える必要がある。

私はPrometheus + Grafanaで監視している。毎週レポートを確認している。ある時、リトライ回数が突然0.8から2.5に跳ね上がったのに気づいた。調査したところ、Schemaを変更したがコードに同期していなかったことがわかった——幸い、監視が早めに問題を発見してくれた。

まとめ

長々と書いたが、核心は一つ。構造化出力は2026年にはもう難しい問題ではない——正しい方法を使えばいい。

三層アーキテクチャ（パラメータ検証 + 失敗リトライ + 制約付きデコード）は、「動く」から「安定して動く」までの全シナリオをカバーしている。プロバイダーを選ぶ際は覚えておこう。OpenAI Strict Modeが最も安定しており、Claudeは自己検証が必要で、オープンソースモデルとOutlinesの組み合わせは逆に信頼性が高い。

コードテンプレートは第四章に全部置いてある。適宜修正して使ってほしい。エージェント開発を始めたばかりなら、まずInstructorから始めることをお勧めする。カプセル化が良く、自動リトライやエラーフィードバックが組み込まれている。慣れてから、100%強制準拠が必要かどうか検討してOutlinesを導入すればいい。

質問があれば、コメントを残すか直接連絡してほしい。この内容は少し硬派だが、皆さんがいくつかの穴を踏まないように役立てば幸いだ。

8 min read · 公開日: 2026年5月6日 · 更新日: 2026年5月6日

default

AI・インテリジェンス