Claude Architect · レッスン

形式とエッジケースの例

出力形式を固定し、難しい境界条件を明確にします

レッスン 2/413 ステップ

「形式とエッジケースの例」はCoddyKit上の無料Claude Architectレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはClaude Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Claude Architectコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Format Examples Exist

Instructions tell Claude what to do. Examples show it exactly what the output should look like.

Few-shot prompting means dropping 2-4 targeted examples into your prompt. The model generalizes from them - it doesn't just copy them back. In this lesson we use examples for two jobs: pinning the output shape and clarifying tricky edge cases.

These two jobs are where few-shot earns its keep: consistency, output format, and reducing hallucination on the weird inputs.

The Problem: Drifting Shape

Imagine you ask Claude to extract a date. Sometimes you get 2026-06-10, sometimes June 10, 2026, sometimes 10/06/2026. Every variation breaks the code that consumes the output.

A prose instruction like "return the date" is ambiguous. Vague guidance produces vague consistency. The fix is to show the exact shape you want instead of describing it.

Pinning Shape with Examples

Put a couple of input/output pairs in the system prompt. The model locks onto the format of the outputs and reproduces it for new inputs.

Notice each example pins the same structure: ISO date, uppercase status, no extra commentary.

system = (
    "Extract the event into JSON. Match this shape exactly.\n\n"
    "Input: Launch is on June 10th, all systems go.\n"
    'Output: {"date": "2026-06-10", "status": "GO"}\n\n'
    "Input: Demo slipped to the 3rd of July, still pending.\n"
    'Output: {"date": "2026-07-03", "status": "PENDING"}'
)

resp = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=256,
    system=system,
    messages=[{"role": "user", "content": "Input: Kickoff is set for May 1st and confirmed."}],
)

Examples Beat Adjectives

Explicit criteria beat vague pleas. "Be more consistent" or "format it nicely" gives the model nothing to anchor on.

Compare two ways to ask for the same thing:

Vague: "Return the status in a clean format."
Concrete: show two outputs that are both {"status": "GO"} / {"status": "PENDING"}.

The concrete version removes the guesswork. The model sees the target and hits it.

Format-Critical? Combine with Structured Output

Examples make the shape likely. A JSON Schema via tool_use makes it guaranteed - it eliminates syntax errors and enforces required fields.

Setting tool_choice to "any" forces the model to call some tool, which guarantees you get structured output instead of free text. Use few-shot examples to clarify the content, and the schema to lock the structure.

tools = [{
    "name": "record_event",
    "description": "Save the parsed event.",
    "input_schema": {
        "type": "object",
        "properties": {
            "date": {"type": "string", "description": "ISO 8601, e.g. 2026-06-10"},
            "status": {"type": "string", "enum": ["GO", "PENDING", "OTHER"]},
            "status_detail": {"type": "string"}
        },
        "required": ["date", "status"]
    }
}]

resp = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=256,
    tools=tools,
    tool_choice={"type": "any"},  # must call a tool -> structured output
    messages=msgs,
)

The Required-Field Trap

A schema is only safe if you mark fields correctly. The rule: mark a field required ONLY if it is always present.

If you require a field that may be absent from the source, the model will fabricate a value to satisfy the schema. That is a silent data-quality bug.

In the example above, date and status are always derivable, so they are required. status_detail may be missing, so it stays optional.

Designing for Edge Cases

Now the second job: tricky boundaries. The default output covers the happy path. Edge-case examples teach the model what to do when the input is weird, incomplete, or doesn't fit.

Pick 2-4 examples that target the specific ambiguities you actually hit - not random samples. Each example should resolve one boundary the model would otherwise guess at.

Show the Empty / Absent Case

The most common edge case: the answer simply isn't in the input. Distinguish a valid empty result (no data present) from an access failure (couldn't read the source).

Show an example where the field is absent and the model returns a sentinel like "OTHER" plus a detail - never an invented value.

system = (
    "Extract status. If the text states no status, use OTHER and explain.\n\n"
    "Input: Meeting moved to Friday.\n"
    'Output: {"status": "OTHER", "status_detail": "no status stated"}\n\n'
    "Input: Release approved by the board.\n"
    'Output: {"status": "GO", "status_detail": "approved"}'
)

Enums with an 'Other' Escape Hatch

Edge cases break rigid enums. An input that fits none of your categories forces the model to either fabricate a fit or crash the schema.

The extensible pattern: an enum plus an "other" value and a free-text detail field. This lets the model classify cleanly when it can, and gracefully overflow when the input is unexpected - without you re-deploying the schema.

"properties": {
    "category": {
        "type": "string",
        "enum": ["GO", "PENDING", "BLOCKED", "OTHER"]
    },
    "category_detail": {
        "type": "string",
        "description": "Required when category is OTHER; free text"
    }
}

Examples Generalize - Don't Over-Enumerate

A common mistake is treating few-shot like a lookup table - stuffing in 30 examples hoping to cover every input. The model generalizes from a few well-chosen pairs; it doesn't need an exhaustive list.

More examples also cost context, and long prompts suffer from lost-in-the-middle: the model attends most to the start and end, least to the middle. A bloated example block buries the very patterns you care about.

Keep it to 2-4 sharp, boundary-targeting examples.

When the Output Is Still Wrong

Even with good examples, you may get a malformed result. Retry-with-feedback fixes format, structural, and arithmetic errors: resend the original input, the wrong output, and the exact validation error.

But know the limit: retry does not help when the information is simply absent from the source. No amount of re-prompting invents data that isn't there - that's an edge case your examples and schema should handle up front with an "OTHER"/empty path.

try:
    event = validate(tool_input)  # Pydantic-style schema check
except ValidationError as err:
    retry = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=256,
        tools=tools,
        tool_choice={"type": "any"},
        messages=msgs + [
            {"role": "assistant", "content": [tool_use_block]},
            {"role": "user", "content": f"Validation failed: {err}. Fix and resubmit."},
        ],
    )

Quick Check: Optional Field

You are extracting invoices into JSON. Most invoices have a purchase_order number, but about 30% omit it. You add two few-shot examples to pin the output shape.

How should you handle the purchase_order field in your JSON Schema?

対話的なレッスンで答える

Recap: Pin the Shape, Tame the Edges

Key takeaways:

Show, don't describe: 2-4 input/output pairs pin format far better than adjectives like "clean" or "consistent".
Examples + schema: few-shot makes the shape likely; JSON Schema via tool_use (with tool_choice: "any") makes it guaranteed.
Required only if always present: requiring a possibly-absent field forces fabrication.
Use enum + "other" + detail for extensibility, and show an absent/empty example so the model never invents data.
The model generalizes: a few sharp, boundary-targeting examples beat a bloated list that buries the pattern in the middle.
Retry-with-feedback fixes malformed output, but not information that simply isn't in the source.

無料で開始

AI チューターと学ぶ Python — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース: 26
レッスン: 104

無料で学習を始めるコース全体を表示

よくある質問

「形式とエッジケースの例」レッスンは無料ですか？

はい。「形式とエッジケースの例」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Claude Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Claude Architectコースには全4レッスンが含まれています。

「形式とエッジケースの例」で何を学びますか？

出力形式を固定し、難しい境界条件を明確にしますブラウザで直接実行するハンズオンコードでClaude Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Claude Architectを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのClaude Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン2/4です。

「形式とエッジケースの例」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このClaude Architectレッスンでコードを書いて実行できますか？

はい。すべてのClaude Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Claude Architectに戻る