「条件を説明するな、型を見せろ」は本当か？LLMの形式制約8種を実験検証した結果

生成AIを業務で使い込んでいる方なら、一度は経験があるはずです。「語尾を『です』で統一して」と指示したのに、なぜかLLMが意図しない出力を返してくる瞬間を。

もんてらさんが報告した「ですです。事件」は、まさにこの問題の象徴的なケースでした。qwen3:8bに「2文目は『です。』で終われ」と指示したところ、「役に立つことを心がけていますです。」という不自然な出力が続いたというもの。このとき効果を発揮したのが「条件を説明するな、型を見せろ」というアプローチでした。

しかし、1つの成功例だけでは法則とは言えません。今回の実験は、この原則が本当に普遍的なのかを8種類の形式制約で検証した貴重な取り組みです。

今回の実験では、以下の2つの指示スタイルを比較しています：

検証対象となった8種類の形式制約は、実務で頻繁に使われるものばかりです：

1. **語尾制約**（「です」「ます」の統一など）

2. **文の数**（3文で答える、など）

3. **文字数制限**（100文字以内、など）

4. **禁止語**（特定の単語を使わない）

5. **箇条書き形式**

6. **段落構成**

7. **見出しの有無**

8. **数値の表記形式**

実験の結論として報告されているのは、**単純な単独制約（語尾・文の数・文字数・禁止語）は、システムプロンプトを併用すれば条件説明で十分に機能する**という点です。つまり、「型を見せろ」は万能薬ではなく、制約の種類によって使い分けが必要だということです。

さらに興味深いのは、実験中に採点を任せていたLLM自体が「誤審」を起こしていた事実まで観測されたという点。これはLLMによる自動評価の限界を示す重要な発見です。

単純制約と複合制約で戦略を変えるべき理由

この実験結果は、プロンプトエンジニアリングの成熟を示しています。初期の「とにかく例を見せれば良い」という単純な方法論から、**制約の性質に応じた最適化**へとシフトしているのです。

単純な単独制約で条件説明が機能する理由は、LLMの訓練データに含まれる指示パターンとの親和性にあります。「です・ますで統一してください」という指示は、日本語の文章作成における一般的な要求として大量に存在するため、モデルが理解しやすいのです。

一方で、複合的な制約や複雑なフォーマット（JSONスキーマ、特殊な表形式など）では、型例示が圧倒的に効果を発揮します。これは人間の学習プロセスと同じです。複雑なルールは言葉で説明されるより、完成品を見た方が理解が早い。

ChatGPTやClaude との比較で見えてくること

qwen3:8bでの実験結果は、他の主要LLMにも適用できるのでしょうか？

ChatGPT（GPT-4系）やClaude 3は、より大規模なパラメータと洗練された指示追従能力を持つため、**条件説明での成功率がさらに高い**傾向にあります。特にClaude 3は、複雑な多段階の制約でも言語的な説明だけで正確に従える場面が多いです。

しかし、だからこそ**トークン効率**の観点が重要になります。型例示は一見冗長に見えますが、複数回の試行錯誤を防げるなら、結果的にトークン消費は少なくなります。8bクラスのモデルでは特に、初回から成功させる戦略が費用対効果で優位です。

LLM評価のLLMによる誤審問題

今回観測された「採点LLMの誤審」は、AI開発の現場で深刻な課題です。LLMを使った自動評価は効率的ですが、**評価者自身が評価対象と同じバイアスを持つ**というメタ問題を抱えています。

実務での対策としては：

このような多層的なアプローチが必要です。

1. 制約の複雑度マトリクスを作る

あなたがよく使う出力制約を「単純/複合」「頻出/特殊」の2軸で分類してください。単純×頻出なら条件説明、複合×特殊なら型例示、という判断基準を持つだけで、プロンプト作成の効率が劇的に上がります。

2. システムプロンプトを活用する

実験結果が示すように、システムプロンプトの併用は条件説明の成功率を大きく高めます。API利用時は必ず`system`ロールで基本方針を設定し、`user`ロールでは具体的なタスクに集中させる分離設計を採用してください。

3. 「型見せ→条件説明」の段階的移行

新しい制約を導入する際は、まず型例示で確実に動作させ、その後少しずつ条件説明に切り替えてトークン効率を改善する、という段階的アプローチが実践的です。本番環境では型例示、運用安定後に条件説明へ最適化、という流れが理想的です。

この情報は @もんてら | エージェント開発 さんの投稿を参考にしています。