Claude Architect · レッスン

モデル駆動の判断とハードコードされた判断

判断はモデルに任せ、保証が必要な部分にはコードを使います

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

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

Two Ways to Decide

Every agent you build has to make decisions. Who makes them is the design choice.

There are two options:

Model-driven: Claude looks at the situation and chooses the next step.
Hard-coded: your code forces the step, no matter what.

The rule for the exam: let the model decide, and reserve hard code for guarantees you cannot afford to get wrong.

Why the Model Should Drive

Real tasks are open-ended. The order of steps is not known in advance.

A customer message might need one lookup, or three. A research task might branch in ways you cannot predict. Claude reads the live context every turn and adapts.

If you hard-code the path, you freeze the agent into one rigid script. It breaks the moment reality differs from your plan. So the default is: give Claude tools and let it choose.

The Agentic Loop

Here is the model-driven loop. You send the full message history every turn (the model keeps no state). Then you inspect stop_reason:

tool_use → run the tool, append the result, loop again.
end_turn → the model is done. Stop.

The model decides what to do; your code just executes and loops.

while True:
    resp = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=16000,
        tools=tools,
        messages=messages,  # FULL history every turn
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason == "end_turn":
        break
    if resp.stop_reason == "tool_use":
        results = run_tools(resp.content)
        messages.append({"role": "user", "content": results})

Stop on the Signal, Not the Words

How do you know the agent is finished? Terminate on stop_reason — never by scanning the text for words like "done" or "finished".

Parsing text for completion signals is a classic anti-pattern. The model might say "I'm done thinking" mid-task, or never say "done" at all. The structured stop_reason is the real, reliable signal.

# WRONG — parsing text for a completion word
if "done" in resp.content[0].text.lower():
    break

# RIGHT — terminate on the structured stop signal
if resp.stop_reason == "end_turn":
    break

Iteration Caps Are a Safety Net

You may add a maximum number of loop iterations. That is fine — but understand its role.

An iteration cap is a safety net that stops a runaway loop. It is never the primary stop mechanism. The primary stop is always stop_reason == "end_turn".

If your agent normally finishes only by hitting the cap, the decision logic is broken — you are hard-coding what should be model-driven.

MAX_TURNS = 20  # safety net only

for turn in range(MAX_TURNS):
    resp = client.messages.create(
        model="claude-opus-4-8", max_tokens=16000,
        tools=tools, messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})
    if resp.stop_reason == "end_turn":
        break  # the REAL exit
    messages.append({"role": "user", "content": run_tools(resp.content)})

When Code Must Guarantee

Now the other half of the rule. Some outcomes are too important to leave to a probabilistic model.

A prompt is roughly 90% reliable — it usually follows instructions, but not always. For rules with financial, legal, or safety consequences, "usually" is not good enough.

For those, you reserve hard code, which is 100% deterministic. This is the one place where you take the decision away from the model.

Hooks Enforce the Hard Limits

The deterministic tool for this is a hook. A hook intercepts an action and can block it before it ever happens — with 100% certainty.

Classic example: "never refund more than $500." You do not write that as a prompt instruction. You write it as an outgoing-call hook that blocks any refund over the limit, every single time.

Hooks for guarantees, prompts for judgment.

# Deterministic policy hook — runs before the refund tool executes
def before_process_refund(tool_input):
    if tool_input["amount"] > 500:
        return {
            "block": True,
            "reason": "Refunds over $500 require human approval.",
        }
    return {"block": False}

Programmatic Preconditions

The same idea applies to preconditions — things that must be true before an action runs.

Example: never process a refund until the customer's identity is verified. Prompt guidance ("please verify identity first") is only ~90% reliable. A programmatic precondition — block process_refund until get_customer returns a verified ID — is a deterministic guarantee.

Code enforces the precondition; the model still decides everything else.

def before_process_refund(tool_input, state):
    # Deterministic precondition: identity must be verified first
    if not state.get("customer_verified"):
        return {"block": True,
                "reason": "Call get_customer and verify identity before refunding."}
    return {"block": False}

Don't Over-Hard-Code

The mistake in the other direction is just as costly: hard-coding decisions that the model should make.

If you wrap every step in branching if/else logic, you have rebuilt a rigid pipeline and thrown away Claude's adaptability. The agent can no longer handle the unexpected case.

Reserve hard code for the narrow set of guarantees — money, law, safety, required preconditions. Everything else stays model-driven.

A Clean Division of Labor

Put it together as a division of labor:

Model decides: which tool to call, in what order, when the task is complete, how to recover from an unexpected result.
Code guarantees: policy ceilings (refund ≤ $500), required preconditions (verified ID), and the loop terminating on stop_reason.

The model drives the trajectory. Code draws the hard boundaries it can never cross.

Fixed Pipelines vs Adaptive

One nuance: not every task is open-ended.

For a known, sequential process, a fixed pipeline (prompt chaining) is fine — the steps really are fixed.
For an open-ended investigation, use adaptive decomposition and let the model choose its path.

So "let the model decide" applies where the path is genuinely uncertain. Where the sequence is truly known, structure is appropriate — just don't force structure onto problems that need adaptability.

Quick Check

A support agent must never issue a refund above $500. Refunds at or below $500 should be handled smoothly within the conversation. What is the architect-grade design?

Key Takeaways

Remember the rule: let the model decide; reserve code for guarantees.

Default to model-driven decisions — Claude adapts to live context.
Drive the agentic loop and terminate on stop_reason, never by parsing text.
Iteration caps are a safety net, not the primary stop.
Use hooks and programmatic preconditions for financial, legal, or safety rules — 100% deterministic vs a prompt's ~90%.
Don't over-hard-code: guarantees are a narrow boundary, not the whole agent.

よくある質問

「モデル駆動の判断とハードコードされた判断」レッスンは無料ですか？

はい。「モデル駆動の判断とハードコードされた判断」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと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に戻る