LLM の出力の縛り方を6段階に並べたら、強い順になっていなかった

LLMの出力を制約する方法には正解の順序がないという話だ。一般的には「制約が強いほど良い」と思いこまれているが、実測は違う。プロンプトに例を増やす（段階2）だけで足りることが多く、JSONスキーマのenum（段階3）や統制語彙（段階4）に投資する前に、やるべきことが残っていることがほとんどだ。

これは工学的な直感の罠だ。より強力な制約ツール、より形式的な標準、より複雑な仕様ほど「正解」だと思いやすい。だが実際にはコストと効果が比例していない。AnthropicやOpenAIの公式ガイドも、「enumで足りなければ例示を増やせ」と逆方向で推奨している。つまり強力さの順序と、実装コストの順序は反対なのだ。段階2で試してみて足りなければ段階4に跳ぶという、3を飛ばすやり方が実務的だという発見は、予算の限られた企業にとって特に重要だ。

自社のルール・分類をLLMに覚え込ませたいなら、まず「プロンプトの例を3～5件、多様に置く」で試すこと。それで揺れが減らなければ、次のステップを検討する。形式的な統制語彙を作るのはそれからでいい。安い手段から順に試す、足りたところで止める、という段階的なアプローチが失敗を減らす。