title: "LLM の出力の縛り方を6段階に並べたら、強い順になっていなかった"
emoji: "🗺️"
type: "tech"
topics: ["ai", "llm", "設計", "オントロジー", "jsonschema"]
published: true
前回まででオントロジーという言葉の意味は整理できたのですが、いざ自分のボットに入れようとしたところで手が止まってしまいました。「入れる」と決めたところで、結局のところ何をどこまで作ればいいのかが、まったく分からなくなってしまったからです。
そこで選択肢を並べて地図にしてみたら、作った直後に自分の想定が崩れました。
結論
- LLM の出力を制約する手段は6段階に分けられる。段階2〜6 にはそれぞれ参照できる公式ドキュメントや標準がある（段階1は「何もしない」なので該当なし）
- ただし段階は「弱い→強い」の一本道ではありません。段階3（enum）と段階4（統制語彙）は、効く場所が生成時と受領後で違う
- 結果として、この環境で現実的な打ち手は 1 → 2 → 4、つまり3を飛ばす順序になった
「オントロジーを入れる / 入れない」の2択で考えていたら、この選択肢は絶対に見えませんでした。
なぜ2択ではなく段階で考えるのか
前回までで分かっていることが2つあります。第1回では、分類の揺れは下流がその値を使うときだけ問題になること、そして enum で縛ってあってなお実害が出たことを実測しました。第2回では、「オントロジー」が4つの違うものを指していて、実行を含むのは1つだけだと確認しています。
さてここで「では構造を入れよう」となったとき、2択で考えると安い手段を飛ばして高い手段を選ぶことになってしまいます。
実際、最初は「統制語彙を入れるべきか」というところから考え始めていたのですが、第1回の実測をやってみて、もっと安い手段であるプロンプトの例示をまだ一度も試していなかったことに気づかされました。
段階に分ける目的は、安い順に試して、足りたところで止めることにあります。
6段階
| 段階 | 内容 | 実装コスト | 保守する対象 |
|---|---|---|---|
| 1 | 制約なし（自由記述） | ゼロ | なし |
| 2 | 例示を増やしたプロンプト | 極小 | プロンプト |
| 3 | enum による出力制約 | 小 | 許可値のリスト |
| 4 | フラットな統制語彙（定義つき） | 中 | 語彙＋定義＋別名 |
| 5 | 階層タクソノミー（上位下位） | 中〜大 | 階層構造 |
| 6 | 関係を持つ軽量オントロジー | 大 | スキーマ＋整合性 |
以下、各段階について参照できる一次資料を並べていきますが、いずれも 2026-08-27 に原典を開いて確認したもので、解説記事は経由していません。
先に断っておくと、この6段階という区分そのものを規定した公式仕様は存在しません。 段階1に対応する仕様はありませんし、段階2で引くのは各社のプロンプト作成ガイドにすぎず、SKOS も OWL 2 もそれぞれ独立した標準であって段階4〜6を定義したものではありません。区分そのものはこちらで作ったもので、各段階に紐づけられる資料があるというだけです。
図にするとこうなりますが、横軸を「いつ効くか」にしてあるところが、後半の話につながってきます。
段階3を2つの箱にまたがせているのは、置き場所で効果が変わるからです（後述）。
段階4〜6 を「受領後」に置いたのはこの環境での使い方であって、SKOS や OWL 2 が
受領後専用という意味ではありません。生成前の参照にも使えます。
段階1 — 制約なし
何も課さない状態で LLM に自由にラベルを書かせるやり方で、第1回で観測したのがまさにこれ、実データ5件が5通りに散らばりました。ただし下流が使っていなければ実害はゼロなので、それ自体を問題と呼ぶべきではありません。
段階2 — 例示を増やす
プロンプトに入出力の例を入れる、いわゆる few-shot と呼ばれるやり方で、実装コストはほぼゼロに近いのが特徴です。
【一次情報】Anthropic — Prompting best practices（2026-08-27 取得）
"Examples are one of the most reliable ways to steer Claude's output format, tone, and structure.
A few well-crafted examples (known as few-shot or multishot prompting) improve accuracy and consistency."
"Include 3–5 examples for best results."
"Diverse: Cover edge cases and vary enough that Claude doesn't pick up unintended patterns."
【一次情報】OpenAI — Prompt engineering（2026-08-27 取得）
"When providing examples, try to show a diverse range of possible inputs with the desired outputs."
| 多様性の推奨 | 件数の明示 | |
|---|---|---|
| Anthropic | ✅ | ✅ 3〜5件 |
| OpenAI | ✅ | 記載なし |
両社に共通しているのは多様性のほうで、具体的な件数まで挙げているのは Anthropic だけでした。
第1回の観測が、ここで説明できます
第1回で「例示を2件だけ置くと、LLM は自分で階層を作る」と観測しました。プロンプトの例示は 価格改定 / 仕様 という1階層なのに、出力は 新製品/推論チップ という2階層になっていた、というものです。
手元の実装は例示が2件しかなく、Anthropic のガイドが挙げる3〜5件を下回っていました（OpenAI 側は件数を書いていないので、LLM 一般の推奨というわけではありません）。しかも Anthropic が言う「意図しないパターンを拾わない程度に多様に」とは逆をいっていて、2件とも同じ形だったんですね。
手元で観測した現象は、公式ガイドの記述と方向が一致しています。もっともこれは相関の観察であって、「例示が2件だったから階層が生まれた」という因果を確かめたわけではありません。 件数を変えて出力を比べる実験まではやっていないので。段階2は「なんとなく例を足す」作業に見えて、実は件数と多様性という2つの設計変数を持っているわけです。
段階3 — enum で出力を縛る
許可する値の集合をあらかじめ決めておいて、それ以外を認めないという、いちばん素直な縛り方です。
ここで注意したいのは、この段階に効く場所の違う2つの使い方があることです。 生成時にスキーマの enum として課すか、出てきた値を集合と照合して弾くかで、前者なら集合外の値がそもそも生成されず、後者なら集合外の値は拒否されて落ちます。同じ「enum」と呼んでいても結果はまったく違うので、以下では区別して書きます。
【一次情報】JSON Schema Validation, Draft 2020-12 §6.1.2（2026-08-27 取得）
"An instance validates successfully against this keyword if its value is equal to one of the
elements in this keyword's array value."
enum が検証してくれるのは「値が配列の要素と等しいか」だけで、意味として妥当かどうかは仕様の対象外になっています。
【一次情報】OpenAI — Structured model outputs（2026-08-27 取得）
"Structured Outputs is a feature that ensures the model will always generate responses that adhere
to your supplied JSON Schema, so you don't need to worry about the model omitting a required key,
or hallucinating an invalid enum value."
"Structured Outputs can still contain mistakes. If you see mistakes, try adjusting your
instructions, providing examples in the system instructions, or splitting tasks into simpler subtasks."
公式が「enum で足りないときの対処」の筆頭に挙げているのが例示、すなわち段階2だという点は見逃せません。ということは段階3は、段階2を置き換えるものというより、その上に重ねるものだったことになります。
段階4 — フラットな統制語彙
許可値のリストに、それぞれの定義と別名を付け足したものが段階4です。標準としては W3C の SKOS があり、この記事でもそれを参照しますが、採用率を調べたわけではないので「業界標準」とまでは言いません。
【一次情報】W3C SKOS Reference（W3C Recommendation 18 August 2009 / 2026-08-27 取得）
"a common data model for sharing and linking knowledge organization systems via the Web"
"The SKOS data model provides a standard, low-cost migration path for porting existing
knowledge organization systems to the Semantic Web"
「low-cost migration path」という自己規定が、この段階の性格をとてもよく表していると思います。厳密な論理体系を作るためのものというより、既にある分類をそのまま機械可読にするための軽い道具、という位置づけになるでしょうか。
ラベルをどう持つかについては、整合条件がきちんと決まっています。
"A resource has no more than one value of
skos:prefLabelper language tag"
【一次情報】W3C SKOS Primer（2026-08-27 取得）
"The
skos:prefLabelproperty makes it possible to assign a preferred lexical label to a resource."
"The
skos:altLabelproperty makes it possible to assign an alternative lexical label to a concept."
altLabel の用途として同義語・類義語・略語が挙げられています。
これを分類ラベルに当てはめるなら、新機能 を prefLabel にして、新機能追加 や 機能追加 を altLabel に置くことになります。こうしておけば別名として登録済みの表記であれば代表ラベルに正規化できますが、逆に言うと登録していない表記や複合ラベル、誤記は素通りするので、そこは別の手当てが要ります。
段階5 — 階層タクソノミー
段階4に上位下位の関係を入れたものですが、SKOS の場合は同じモデルの中でプロパティを足すだけで済みます。
"A triple
<A> skos:broader <B>asserts that<B>, the object of the triple, is a broader concept than<A>"
"By convention,
skos:broaderandskos:narrowerare only used to assert a direct
(i.e., immediate) hierarchical link"
ex:animals rdf:type skos:Concept;
skos:prefLabel "animals"@en;
skos:narrower ex:mammals.
ex:mammals rdf:type skos:Concept;
skos:prefLabel "mammals"@en;
skos:broader ex:animals.
原文が "By convention" と書いているとおり、これは整合性違反として機械が弾く制約ではなく慣習です。とはいえ慣習に従うなら、中間の概念を飛ばして上位と下位を直接つなぐことはしないわけで、階層を作るときの自由度はここで一段下がることになります。
段階4と5は同じ仕様で扱えます
SKOS 自身は、対象範囲についてこう書いています。
"SKOS … provides a model for expressing the basic structure and content of concept schemes such as
thesauri, classification schemes, subject heading lists, taxonomies, folksonomies, and other
similar types of controlled vocabulary."
「統制語彙」と「タクソノミー」を別のものとして区別せず、同じモデルの中に包含しているわけです。ということは段階4から5への移行に別技術への乗り換えは要らず、データモデルとしては broader / narrower を足すだけで済みます。とはいえ作業まで軽いという意味ではありません。 どの概念を上位に置くか、粒度をどう揃えるか、循環をどう防ぐかは人が決める必要があり、そこは別のコストとして残ります。それでも技術スタックを変えずに済むのは、見積もりに効いてきます。
段階6 — 関係を持つ軽量オントロジー
クラス間の関係と制約まで定義して、推論までできるようにするのがこの段階になります。W3C の OWL 2 には「プロファイル」と呼ばれる軽量版がいくつか用意されていて、実務上はそこが入口になることが多いようです。
【一次情報】W3C OWL 2 Profiles（W3C Recommendation 11 December 2012 / 2026-08-27 取得）
"An OWL 2 profile … is a trimmed down version of OWL 2 that trades some expressive power
for the efficiency of reasoning."
この一文、このシリーズの主題そのものじゃないでしょうか！ 標準仕様自身が「表現力を減らして、推論の効率を得る」というトレードオフを明示的に設計しているわけです。ここから「全部盛りが正解ではない」と読み取るのは私の解釈で、W3C がそう表明しているわけではありません（書いてあるのは、各プロファイルが何と何を交換したかという事実です）。
3つのプロファイルは、それぞれ何のために削ったのかが違っていて、そこを読み比べると設計思想が見えてきます。
EL: "designed as a subset of OWL 2 that is particularly suitable for applications employing
ontologies that define very large numbers of classes and/or properties … can be decided in
polynomial time."
QL: "designed so that sound and complete query answering is in LOGSPACE … while providing
many of the main features necessary to express conceptual models such as UML class diagrams and
ER diagrams."
RL: "aimed at applications that require scalable reasoning without sacrificing too much
expressive power … accommodate both OWL 2 applications that can trade the full expressivity of
the language for efficiency, and RDF(S) applications that need some added expressivity from OWL 2."
| 何のために削ったか | |
|---|---|
| EL | クラス・プロパティが非常に多い場合に推論を polynomial time にするため |
| QL | データ量に対して LOGSPACE で問い合わせるため（UML/ER のような概念モデル向け） |
| RL | ルールエンジンで実装できるスケーラブルな推論のため |
地図を作ってすぐ、想定が崩れました
段階を並べ終えたので、段階3と段階4を最小実装して、手元の実データに当ててみました。
- 対象: 収集ボットが実際に出力した分類ラベル5件
- 段階3（enum）は、許可値集合
["新製品","新機能","価格改定","仕様変更","提供終了","セーフティ"]に含まれるかを判定するだけのもの - 段階4（統制語彙）:
prefLabel/altLabelの発想で代表ラベルに正規化
先に、この比較の欠陥を書いておきます。
段階4の別名表は、この5件を見てから私が手で作ったものです。新製品/オープン仕様 を見て
「新製品 に寄せよう」と決めているので、5/5 通るのは当たり前です。段階4が優れていることの
証拠にはなりません。
しかも2つの処理は目的が違います。段階3は「集合の外なら拒否する」、段階4は「別名を代表ラベルへ
書き換える」。拒否率と正規化成功率を同じ「通過率」の列に並べたこと自体が、比較として誤りでした。
それでも表を残すのは、この対比が「段階3と4は強さの違いではない」ことに気づいた実際のきっかけ
だからです。数字は効果の測定ではなく、気づいた経緯として読んでください。効果の測定は第5回・第6回で、
ゴールドラベルを先に作ってから行います。
【実測】2026-08-27・n=5
| 入力（実データ） | 段階3（enum） | 段階4（統制語彙） |
|---|---|---|
新製品/オープン仕様 |
❌ 弾かれる | ✅ → 新製品
|
新機能/提供開始 |
❌ 弾かれる | ✅ → 新機能
|
新機能/仕様変更 |
❌ 弾かれる | ✅ → 新機能
|
新製品/推論チップ |
❌ 弾かれる | ✅ → 新製品
|
AIセーフティ |
❌ 弾かれる | ✅ → セーフティ
|
| 処理を通った件数 | 0/5（集合外なので拒否） | 5/5（別名を登録済みなので当然） |
段階3と4は「強さ」の違いではない
「段階を上げると制約が単調に強くなる」という直感は、見事に外れていました。
| 何をするか | いつ効くか | |
|---|---|---|
| 段階3（enum） | 出力を集合に閉じ込める / 集合外を拒否する | 置き場所しだい（生成時にも受領後にも置ける） |
| 段階4（統制語彙） | 出力を代表ラベルに正規化する | 受け取ってから（この環境での使い方） |
そもそも種類が違うので、「段階3で足りなければ段階4へ」という順序は、強度の話というより、対処する問題の種類の話だったことになります。出力が集合の外に出るのが問題なら段階3、表記がゆれるのが問題なら段階4です。
enum は「どこに入れるか」で効果が正反対になる
上の実験で段階3が 0/5 なのは、enum を事後検証として使ったからです。
| 使い方 | 実装 | 結果 |
|---|---|---|
| 生成時制約 | Structured Outputs / tool schema の enum に入れる |
集合外の値が出ない |
| 事後検証 | 出てきた値を集合と照合して弾く | 集合外なら拒否。実データでは全部拒否になった |
ところが手元の環境では、その前者が使えませんでした。判定を行っている仕組みが JSON を書き戻す形になっていて、スキーマで生成を縛る経路がなく、プロンプトで指示するしかないためです。
同じ「段階3」と呼んでいても、API のスキーマ機能が使えるかどうかで、まったく別物になってしまうわけです。ここは実装に入る前、設計を選ぶ段階で真っ先に確認しておくべき点だったと反省しています。
この環境では、段階3を飛ばすのが合理的
第1回の観測、例示が2件しかなく Anthropic のガイドが挙げる件数を下回っていたという話と合わせると、現実的な順序はこうなります。
段階1（現状）
↓
段階2（例示を3〜5件に増やす）← Anthropic のガイドが挙げる件数。実行可能。コスト極小
↓
段階4（統制語彙で正規化） ← 表記ゆれという実際の課題に直接効く
↓
（足りなければ段階5・6へ）
では段階3はどうするか？ ここは飛ばすという判断になりました。生成時に制約として課せない以上、事後検証として実データを全部弾くだけの装置に成り下がってしまうので、入れる意味がありません。
この判断にたどり着けたことこそ、6段階という地図を作った価値でした。2値で考えていたら「安い段階2を先に、そして段階3を飛ばして4へ」という選択肢は、どうやっても出てこなかったはずです。
どこまでが「オントロジー」なのか
前回整理した4つの定義に照らすと、この6段階のうち「オントロジー」と呼べるのは段階6だけです。
| 段階 | 前回の定義に照らすと |
|---|---|
| 2・3 | プロンプト技法・スキーマ検証。オントロジーではない |
| 4・5 | SKOS の領域。SKOS 自身は「knowledge organization system」と呼び、オントロジーとは名乗っていない |
| 6 | OWL の領域。ここで初めて Gruber / W3C の定義に当たる |
だから段階4に留まる場合に「オントロジーを導入した」とは書かないことにしています。 用語を実態より大きく見せてしまうのを避けたいので。
この段階の切り方を採った理由（と、却下した切り方）
6段階という切り方に唯一の正解があるわけではないので、こう切った理由と、途中で却下した案を並べて書いておきます。
採用した理由は各段階がそのまま実装の単位になっていることで、段階を1つ上げるときに「何を書き足すか」が具体的に決まるからです。例示を足す、許可値リストを作る、別名表を作る、階層を定義する、という具合に。
却下1: 3段階（なし / 語彙 / オントロジー）。 これは試してみたのですが、あまりに粗すぎました。この環境で採るという判断に至った「例示を増やす」と「表記を正規化する」が同じ箱に入ってしまうので、今回見つけた「3を飛ばす」という判断がそもそもできなくなります（有効だったかどうかは、まだ測っていません）。
却下2: 連続量として扱う（制約の強さを 0〜1 で表す）。 段階3と4が強さの違いではなく種類の違いだった、という今回の発見が、そのままこの案の反例になっています。制約の強さという一次元に並べてしまうと、種類の違いがきれいに消えてしまうので。
却下3: 実装技術で切る（プロンプト / JSON Schema / RDF / OWL）。 技術はあくまで選択肢であって段階そのものではありませんし、同じ JSON Schema が生成時制約にも事後検証にもなってしまうように、技術名からは「どこに効くか」が決まらないからです。
各段階に紐づけた資料が実在することは確認済みですが、冒頭に書いたとおりこの区分自体を規定した仕様はありません。切り方は設計判断なので、他の切り方のほうが優れている可能性は残ると思います。
第5回・第6回で使う測定の基準
実際に測るのは第5回・第6回になりますが、基準そのものはこの段階で決めて公開しておくことにします。測った後になってから、自分に都合の良い基準をあとづけで選べる状態にはしておきたくないので。
| # | 決めること | 内容 |
|---|---|---|
| 1 | 試行回数 | 各段階 n ≧ 10。1回の値は分布からの1標本にすぎません |
| 2 | 報告の形 | n・中央値・範囲・ばらつきを併記。平均値だけは書きません |
| 3 | 同一条件内のばらつきと、条件間の差を分ける | 条件間の差がばらつきの範囲内なら、差は主張しません（それも結果として書きます） |
| 4 | 正しさは一貫性と別に測る | 同じ誤分類を返し続けるシステムも「一貫して」います。ゴールドラベルが要ります |
| 5 | ゴールドラベルは実装前に作る | 実装を見てから作ると、実装に有利なラベルになります |
| 6 | Before は実装前に取る | 段階を上げた後では、上げる前の値は二度と取れません |
この地図をそのまま持ち帰れない条件
| # | 条件 |
|---|---|
| 1 | どの段階で足りるかは、ここでは決まりません。 公式仕様はどこまでできるかを規定しますが、あなたの環境でどこまで必要かは測らないと分かりません |
| 2 | 各段階の効果は未測定です（第5回・第6回で測ります） |
| 3 | 保守コスト（語彙の追加頻度・定義の改訂・分類不能率）も未測定です |
| 4 | 段階5・6 がこの環境で必要かどうかは分かりません。段階4 で足りる可能性もあります |
| 5 | n=5 の実験は、手元の実データを1回当てただけです。統計的な主張はできません |
| 6 | 「enum が使えない」のはこの実装の制約です。スキーマで生成を縛れる環境なら、段階3の評価は変わると思います |
地図はできたので、次はいったん外の証拠を見にいきます。
「知識グラフを入れたら LLM の正答率が 16% → 54% になった」という数字を、あちこちで見かけると思います。あの論文を実際に読んで、何が測られていて何が測られていないのかを切り分けてみるつもりです。先に方向だけ言っておくと、あの論文が比較しているのは段階1と段階6の2点だけで、ここで刻んだ段階2〜5はどこでも測られていません。