Claude Architect · レッスン

システムをエージェント型にする要素

自律性、ツールの利用、反復的な意思決定について学びます

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

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

What Is an Agentic System?

A normal program follows a fixed script. An agentic system is different: you give it a goal, and the model decides the steps to reach it.

Three properties make a system agentic:

Autonomy — the model chooses what to do next, not your code.
Tool use — it can act on the world (search, read files, call APIs).
Iteration — it loops: act, observe the result, decide again.

In the Claude Certified Architect track, these three ideas sit at the center of Agent Architecture & Orchestration, the largest exam domain (27%).

The Model Keeps No State

Each call to the Claude API is stateless. The model remembers nothing between turns. You must send the full message history every turn.

A request carries these fields:

model — which Claude model to use.
max_tokens — the output cap.
system — instructions and role.
messages — the entire conversation so far.
tools — what the model is allowed to call.

Because there is no hidden memory, you own the loop that grows messages over time. That loop is what turns a single answer into agentic behavior.

import anthropic

client = anthropic.Anthropic()

messages = [{"role": "user", "content": "Check today's open orders."}]

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system="You are an operations assistant.",
    messages=messages,  # the FULL history, every single turn
    tools=TOOLS,
)

Autonomy: Decisions Are Model-Driven

The heart of autonomy is simple: the model decides, your code executes.

You do not hard-code 'first search, then summarize, then reply.' You describe the goal and the available tools, and Claude works out the path — including when it has gathered enough to answer.

Reserve hard-coded logic for things you must guarantee (a refund limit, an identity check). Everything else is a model decision. Over-scripting the path defeats the purpose of building an agent at all.

Tool Use: Acting on the World

Autonomy is useless if the model can only talk. Tools let Claude take real actions: look up a customer, read a file, run a query.

You declare each tool with a name, a description, and an input_schema. The description is the primary selection mechanism — Claude reads it to decide when the tool applies. Names matter far less.

A good description states purpose, return values, input formats, and edge cases. Keep each agent focused: 4-5 tools per agent is optimal; past about 18 tools, selection reliability degrades.

TOOLS = [{
    "name": "lookup_order",
    "description": (
        "Fetch an order by its ID. Use when the user references a "
        "specific order. Returns status, items, and total. "
        "order_id format: 'ORD-' followed by 6 digits, e.g. ORD-001234. "
        "Returns an empty result if the order does not exist."
    ),
    "input_schema": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
    },
}]

The stop_reason Signal

After every request, Claude returns a stop_reason. This is how the model tells you what it wants to happen next:

end_turn — Claude is finished. The task is complete.
tool_use — Claude wants to run one or more tools, then continue.
max_tokens — the output was truncated by your cap.
stop_sequence — a custom stop string was hit.

The agentic loop is built entirely around inspecting this field. You never guess what the model meant — it tells you directly.

The Agentic Loop

Put the pieces together and you get the agentic loop:

Send the request.
Inspect stop_reason.
If it is tool_use: run the tools, append the results to messages, and loop again.
If it is end_turn: stop — the task is done.

This is iterative decision-making in action. Each pass, the model sees the new tool results and chooses its next move. The conversation history grows until Claude decides it is finished.

while True:
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=1024,
        messages=messages,
        tools=TOOLS,
    )
    messages.append({"role": "assistant", "content": response.content})

    if response.stop_reason == "end_turn":
        break  # the model says it is done

    if response.stop_reason == "tool_use":
        results = run_requested_tools(response.content)
        messages.append({"role": "user", "content": results})

Terminate on stop_reason, Not on Text

This is one of the most tested decisions on the exam. You terminate the loop on stop_reason — never by scanning the model's text for words like 'done', 'complete', or 'finished'.

Why? Text parsing is fragile: the model might say 'I'm not done yet' or 'almost finished', and a naive keyword match would stop early or loop forever. The stop_reason field is the model's explicit, structured signal — it is unambiguous.

Parsing text for completion signals is a classic anti-pattern. If you see it in an answer choice, it is almost always wrong.

Iteration Caps Are a Safety Net

It is wise to cap the number of loop iterations — but understand its role. An iteration cap is a safety net that catches runaway loops. It is not the primary way the loop ends.

The primary stop mechanism is always stop_reason == "end_turn". The cap only fires if something goes wrong and the model never converges.

Treating an arbitrary cap (say, 'always stop after 3 turns') as your main control flow is an anti-pattern. Let the model drive; keep the cap as a backstop.

MAX_TURNS = 10  # safety net, not the primary exit

for turn in range(MAX_TURNS):
    response = client.messages.create(
        model="claude-opus-4-8", max_tokens=1024,
        messages=messages, tools=TOOLS,
    )
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason == "end_turn":
        break  # PRIMARY exit — the model decided
    handle_tool_use(response)
else:
    escalate("Loop hit the safety cap without converging.")

Guarantees Belong in Code

Model decisions are powerful but probabilistic — roughly 90% reliable when steered by a prompt. For anything with financial, legal, or safety consequences, that is not enough.

When you need a 100% guarantee, use deterministic code, not prompt instructions:

A hook can block a policy-violating action before it runs (e.g. a refund over $500).
A programmatic precondition can require that a customer's identity is verified before any refund tool runs.

Prompts guide; code guarantees. Knowing which to reach for is core architect judgment.

def process_refund(order_id, amount, verified_customer_id):
    # Deterministic precondition — a prompt cannot guarantee this
    if verified_customer_id is None:
        raise PermissionError("Identity must be verified before refunds.")
    if amount > 500:
        return escalate_to_human(order_id, amount)  # hook-style hard rule
    return issue_refund(order_id, amount)

Tool Choice Shapes Autonomy

You can tune how much freedom the model has on any given request with tool_choice:

"auto" — Claude decides whether to answer in text or call a tool. This is the default and the most agentic.
"any" — Claude must call some tool. Useful when you want guaranteed structured output.
{"type": "tool", "name": "X"} — force one specific tool.

An agentic system normally runs on "auto": the model needs the freedom to decide when to act and when it is done. Forcing tools every turn would break the natural end_turn signal.

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=messages,
    tools=TOOLS,
    tool_choice={"type": "auto"},  # let the model choose to act or finish
)

From One Agent to Many

Once a single agentic loop works, the same ideas scale up. A multi-agent system uses a hub-and-spoke shape: a coordinator decomposes the task, delegates to subagents, and aggregates their results.

One rule is critical for the exam: subagents do not inherit the coordinator's conversation history. Each subagent's context must be passed explicitly in its prompt. There is no shared memory between them.

Each subagent still runs its own autonomous, tool-using, iterative loop — the building block you just learned, composed at a larger scale.

Quick Check: Ending the Loop

An architect is building a Claude agent that calls tools to resolve support tickets. How should the loop decide when the agent is finished with a request?

Recap: The Agentic Building Blocks

You now have the foundation of every Claude agent:

Autonomy — the model decides the path; your code executes. Reserve hard code for guarantees.
Tool use — descriptions drive selection; keep 4-5 focused tools per agent.
Iteration — the loop runs request → inspect stop_reason → run tools → repeat.
Terminate on stop_reason (end_turn), never by parsing text. Iteration caps are a safety net only.
State is yours — the model keeps none; send the full history every turn.

Master these and you can reason about any agent on the exam — single-agent or hub-and-spoke multi-agent.

よくある質問

「システムをエージェント型にする要素」レッスンは無料ですか？

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

「システムをエージェント型にする要素」で何を学びますか？

自律性、ツールの利用、反復的な意思決定について学びますブラウザで直接実行するハンズオンコードでClaude Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

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

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

「システムをエージェント型にする要素」レッスンにはどのくらい時間がかかりますか？

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

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

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

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

← Claude Architectに戻る