0Pricing
Claude Architect · レッスン

決定論的な強制とプロンプト

フックの確実性は100%ですが、プロンプトの確率は約90%です

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

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

Two Ways to Enforce a Rule

When you need an agent to always follow a rule, you have two fundamentally different tools.

  • Prompts ask the model to behave a certain way. The model usually complies — but it's still a probabilistic system making a judgment call.
  • Hooks are deterministic code that runs around tool calls. They don't ask — they enforce.

This lesson teaches the single most important number in workflow enforcement: a well-written prompt gives you roughly ~90% compliance; a hook gives you 100%.

Prompts Are Probabilistic

A system prompt is guidance. Even an excellent one — explicit criteria, few-shot examples — steers the model toward the right behavior but never guarantees it.

Across thousands of requests, that residual ~10% surfaces: an edge case, an unusual phrasing, a long context where the rule sits in the lost-in-the-middle zone. The model generalizes from your instructions, which is exactly why it can also generalize wrong.

For most behaviors that's fine. For rules where a single violation is unacceptable, ~90% is a liability.

system = (
    "You are a refund agent. "
    "NEVER issue a refund above $500 without manager approval."
)
# This is guidance. The model will *usually* obey —
# but 'usually' is not 'always'. There is no code path
# that physically blocks a $501 refund.

Hooks Are Deterministic

A hook is ordinary code wired into the agent lifecycle. It runs every time, evaluates a condition the same way every time, and its decision does not depend on model reasoning.

  • PostToolUse hooks intercept a tool's result before the model ever sees it.
  • Outgoing-call hooks block policy-violating actions before they execute.

Because the logic is hard-coded, the guarantee is absolute: 100% deterministic enforcement. A blocked action is blocked — no matter what the model decides.

def block_large_refund(tool_name, tool_input):
    if tool_name == "process_refund" and tool_input["amount"] > 500:
        return {"allow": False,
                "reason": "Refunds over $500 require manager approval"}
    return {"allow": True}
# Runs on EVERY process_refund call. $501 is blocked, every time.

The Decision Rule

Here is the rule to memorize for the exam and for real architecture:

Use hooks when failure has financial, legal, or safety consequences.

If a single violation costs money, breaks the law, or endangers someone, ~90% is not acceptable — you need 100%. That is a hook's job. Prompts are for guidance, tone, preference, and the countless soft behaviors where an occasional miss is recoverable.

Don't enforce a critical business rule with prompts alone. That is one of the most common wrong answers on scenario questions.

Programmatic Preconditions

The same deterministic principle applies to preconditions — rules about what must happen before an action is allowed.

Example from the Customer Support scenario: never run process_refund until get_customer has returned a verified customer ID. You could write that as a prompt instruction... or you could enforce it in code so it physically cannot be skipped.

A programmatic precondition gives a deterministic guarantee that prompt guidance cannot. The identity check happens 100% of the time, not 90%.

def require_verified_identity(tool_name, tool_input, state):
    if tool_name == "process_refund" and not state.get("verified_customer_id"):
        return {"allow": False,
                "reason": "Block refund until get_customer returns a verified ID"}
    return {"allow": True}

Why Not Just Prompt Harder?

A tempting trap: "I'll write a really strong prompt — all caps, repeated three times, with examples." This improves compliance, but it does not change the category. You are still on the probabilistic side of the line.

Few-shot examples and explicit criteria are powerful — they raise quality, reduce hallucination, and lock in output format. But they raise the ceiling of ~90%; they never reach the deterministic 100% that financial, legal, and safety rules demand.

If the requirement is a guarantee, no amount of prompt engineering substitutes for code.

Hooks Don't Replace Model Decisions

Important balance: hooks are not a license to hard-code everything. The agentic loop is model-driven — the model decides which tools to call and when, based on stop reasons.

You reserve hard code for guarantees, not for routine decision-making. Think of it as a thin, deterministic safety boundary around an intelligent, flexible core.

The same wisdom appears with iteration caps: a cap is a safety net, never the primary stop mechanism. Terminate on stop_reason, and use deterministic code only where a hard guarantee is genuinely required.

PostToolUse: Guarding Inputs to the Model

A PostToolUse hook intercepts a tool result before the model sees it. This is more than blocking — it's a deterministic checkpoint on data flowing back into the conversation.

Use it to enforce things like: redact secrets from output, validate that a required field is present, or refuse to surface a result that violates policy. Because it runs deterministically on every result, the model never even gets a chance to mishandle data you've decided it must not see raw.

def post_tool_use(tool_name, result):
    if tool_name == "lookup_order":
        # Deterministically strip PII before the model sees it
        result.pop("raw_credit_card", None)
    return result

Outgoing-Call Hooks: Guarding Actions

The mirror image of PostToolUse is the outgoing-call hook: it sits between the model's decision to act and the action actually firing.

This is where you block policy-violating actions — the refund over $500, the email to an unapproved domain, the deletion of a protected resource. The model may request the action; the hook decides whether it executes.

This separation is the architecture: the model proposes, deterministic code disposes — but only for the small set of rules that truly require a guarantee.

def on_outgoing_call(action):
    if action.type == "refund" and action.amount > 500:
        raise PolicyViolation("Refund exceeds $500 ceiling")
    if action.type == "refund" and not action.customer_verified:
        raise PolicyViolation("Customer identity not verified")

Reading the Signal in a Scenario

Exam scenarios telegraph the answer with their wording. Train yourself to spot it:

  • Words like "must never," "financial," "compliance," "safety," "regulatory," or a hard dollar threshold → the answer involves a hook / deterministic enforcement.
  • Words like "prefer," "tone," "style," "usually," "when appropriate" → a prompt is fine.

If an option proposes enforcing a hard, costly rule with "a stronger system prompt," it is almost certainly a distractor.

Combine Both Layers

The strongest designs use both. The prompt makes the model want to do the right thing 90% of the time — fewer blocked attempts, smoother conversations, better UX. The hook catches the remaining 10% with a hard guarantee.

Prompt for good default behavior; hook for the non-negotiable boundary. You get a system that is both intelligent and provably safe — guidance for the common case, deterministic enforcement for the catastrophic one.

# Layer 1 (prompt, ~90%): set the right default behavior
system = "Confirm customer identity before any refund, and keep refunds under $500."

# Layer 2 (hook, 100%): the guarantee the prompt can't make
hooks = [require_verified_identity, block_large_refund]

Quick Check: Refund Policy Enforcement

Apply the decision rule to a real scenario.

Recap: 100% vs ~90%

Key takeaways:

  • Prompts are ~90% probabilistic guidance; hooks are 100% deterministic enforcement.
  • Use hooks when failure has financial, legal, or safety consequences; use prompts for tone, preference, and soft behavior.
  • PostToolUse hooks guard results before the model sees them; outgoing-call hooks block policy-violating actions before they fire.
  • Programmatic preconditions (block a refund until identity is verified) give guarantees prompts cannot.
  • Reserve hard code for guarantees — keep the loop model-driven, and combine a good prompt (default behavior) with a hook (hard boundary).
  • Distrust any answer that enforces a critical, costly rule with "a stronger prompt" alone.

よくある質問

「決定論的な強制とプロンプト」レッスンは無料ですか？

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

「決定論的な強制とプロンプト」で何を学びますか？

フックの確実性は100%ですが、プロンプトの確率は約90%です ブラウザで直接実行するハンズオンコードでClaude Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

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

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

「決定論的な強制とプロンプト」レッスンにはどのくらい時間がかかりますか？

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

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

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

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

  1. PostToolUseと送信呼び出しフック
  2. 決定論的な強制とプロンプト
  3. プログラムによる事前条件
  4. 構造化された引き継ぎプロトコル
← Claude Architectに戻る