LLM による意味論検証を支える規律 〜参照整合性への応用例を添えて〜Semantic validation has long relied on costly and inconsistent human review,…

Program correctness rests on two distinct foundations, syntax and semantics, and the tools available to check each have historically been very different. A recent post on the Japanese developer platform Zenn argues that large language models are narrowing that gap, and it grounds the argument in a concrete referential integrity example. The topic matters because semantic review is one of the most labor-intensive parts of building software, and any credible path to automating it could reshape how teams enforce quality.

Syntax — whether code is well-formed according to a language's grammar — has been the machine's domain for decades. Compilers and linters enforce it silently, and they do so deterministically: run them twice on the same input and the result is identical. Semantic validation is harder to pin down. Questions such as whether a specification contradicts the intent of a design, or whether a code change deserves a reviewer's comment, have traditionally required a human reader. As the article puts it, human review is expensive, non-reproducible, and person-dependent; the verdict shifts depending on who performs it and when.

LLMs alter this division of labor because a machine-side evaluator can now read meaning across both natural language and code. A model can hold a written requirement and an implementation side by side and reason about whether they agree, a comparison that static analyzers cannot make because it depends on understanding intent rather than form. The post presents this as a way to strip person-dependency out of semantic checking while making it automatable, so that the same question yields a consistent answer.

The catch, and the reason the original title emphasizes discipline, is that LLMs are not deterministic in the way a linter is. The same prompt can produce different judgments across runs, and a model can be confidently wrong. Turning an LLM into a dependable validator therefore appears to require deliberate constraints: narrowing the question to something checkable, fixing decoding settings to reduce variance, demanding structured output that can be verified, and pinning the exact model version so results stay comparable over time. Without that scaffolding, an LLM reviewer risks reintroducing the very inconsistency it was meant to remove.

Referential integrity is a useful demonstration case precisely because it sits between the two worlds. In its strict database sense, it means every foreign key points to a record that exists; in a broader software sense, it means that identifiers, links, and cross-references resolve to something real and consistent. Checking it requires semantic understanding — knowing what refers to what and whether those references still hold — yet the underlying truth is comparatively objective. That combination makes it easier to judge whether the model's answer is right, which is valuable when you are trying to establish trust in an automated approach.

This work sits