オントロジーをツール結果の検証ループに組み込む

This chapter examines a design in which an agent does not immediately accept a tool result. The speaker shows a flow that validates information returned by a tool with an ontology and decides whether the result is reasonable.

Where to place the ontology

The insertion point shown by the speaker is not a place where the LLM or the tool is replaced. After the tool runs and returns information, that information is put into a form that a validator can handle. The system then uses an ontology about the domain to check whether the LLM response or tool result is reasonable.

The flow, in order, is as follows.

1. The LLM proposes using a tool to solve the problem.
2. The surrounding program calls the tool using the parameters in that proposal.
3. The tool returns information.
4. The program puts the returned information into a form that the validator can read.
5. The validator checks the result against the ontology for the domain.
6. If it is reasonable, the loop continues; if it is not, the system returns to the LLM or asks a human to review it.

Here, “reasonable” does not mean only that the string has the correct shape. It means that the result fits the concepts, relationships, and constraints of the domain. Therefore, even a grammatically correct response is not accepted if it violates a domain rule. The speaker explains the idea of assigning this judgment to an ontology-based validator.

Figure 1. A Claude agent loop and two validation gates surrounding a tool call.

On this slide, input and output gates appear before and after run_tool(call). Pydantic is placed on the input side, and the ontology is placed on the output side. In other words, the system checks not only the proposal before running the tool but also the result returned by the tool. This describes the structure visible on the slide; it does not specify how a particular validation library is implemented.

Branches after validation fails

In an agent loop, receiving a tool result does not by itself complete the process. The program checks the stop reason and decides whether the response requests tool use. If it does, the program executes the call and puts the result back into the running context. It then passes the result through output validation based on the ontology.

There are at least two paths depending on the validation result.

• If the result is reasonable, the system accepts it and continues the loop. When needed, it uses the information as input for the LLM’s next decision.
• If the result is not reasonable, the system returns information that something is not working to the LLM and asks it to think again. If it is difficult to leave the process to automation, a human is brought into the loop to make the decision.

Figure 2. A loop that calls a tool, checks the stop reason, passes through input and output validation gates, and repeats.

On this code slide, the stop reason indicating tool use leads to a tool call, and the returned result is added to the running context before the process repeats. The two gates separate input validation from output validation. The slide shows the tool loop and the validation points; it does not show a handoff to a human.

Guardrails do not mean “zero bad proposals”

An LLM generates responses probabilistically. Therefore, even if the LLM proposes how to use a tool or which parameters to use, that alone does not guarantee correctness in the domain. Validation with an ontology does not replace the LLM with another system; it adds checks around the proposal and execution.

RDFS and OWL, discussed in the previous chapter, can provide material for these checks. For example, the domain and range of a relationship can be used to infer an entity’s type. Rules about property constraints and kinds that cannot hold together (disjointness) can also reveal that a result does not fit the domain’s assumptions. These inferences and constraints support the decision before a tool result is accepted.

As an additional example, consider a result returned by a tool. Even if the result is easy to read, the program does not adopt it as-is if the types or relationships in it do not match the ontology’s rules. It asks the LLM to revise the result or asks a human to review it. This example explains the validation idea; it does not mean that the speaker specified a particular business dataset or validation library.

Summary

The main point of this design is to put the LLM’s flexible proposal, tool execution, and ontology-based semantic validation into one loop. By validating after receiving a tool result, the program can check not only whether a response arrived but also whether it is reasonable in the domain. An unreasonable result can be sent back to the LLM for another attempt or sent to a human for review. This is a guardrail proposal, not a guarantee that the LLM will never make a mistake.