LLMの使用領域におけるバッドプラクティスと対応策

共通の根本原理

LLMは確率的なモデルであり、同じ入力でも出力が揺れることがあるため、決定論的に処理できる領域では使うべきではない。
この原理を無視すると、さまざまな場面で「LLMを使う必要がないのに使ってしまう」失敗が起きる。

失敗の種類と事例

技術的ミスマッチ：決定論的処理にLLMを使う

• 事例
  • JSON構造の正当性をLLMで判定 → 誤って「OK」と返す。
  • 数値計算をLLMに任せる → 桁ズレや誤差。
• なぜ問題か
  • LLMは揺れるので「常に正しい」が求められる処理に不適。
• 代替案
  • JSON Schemaや正規表現で検証。
  • 計算は組み込み演算やライブラリを利用。

リスク耐性：ゼロエラー要求の領域に使う

• 事例
  • 金融システムで送金額をLLMが解釈 → 1円の誤りでも致命的。
  • 医療システムで薬剤量をLLMに算出させる。
• なぜ問題か
  • 一度の誤りが重大事故につながる領域では誤答許容できない。
• 代替案
  • LLMは入力補助や説明生成に限定。
  • 最終判断はルールベースか人間。

説明可能性：監査が必要な領域に使う

• 事例
  • 契約書のリスクを「OK/NG」で返すだけ → 根拠不明で監査不可。
  • 個人情報保護チェックをLLMに丸投げ。
• なぜ問題か
  • 出力に根拠がなく、後から説明・検証できない。
• 代替案
  • 条文や規約ベースで一次判定。
  • LLMは要注意箇所のハイライトと補足説明。

効率性：ルールで十分な領域をLLMに丸投げ

• 事例
  • スペルチェックをLLMに依頼 → 高コスト＋誤検知。
  • コードフォーマットをLLMで処理 → 本来はリンタやフォーマッタで済む。
• なぜ問題か
  • コストが高く、再現性や効率性も低下する。
• 代替案
  • 専用ツール（リンタ、辞書、スタイルガイド）を利用。
  • LLMは「改善提案」や「読みやすさ評価」に限定。

運用設計：LLMを必須チェックに組み込む

• 事例
  • CI/CDで「LLMレビューに合格しないとPRをマージできない」。
  • QAで「LLMスコアが一定値未満ならリリース不可」。
• なぜ問題か
  • LLMの揺れや誤検知で開発・リリースが止まってしまう。
• 代替案
  • LLMはアドバイザリー（提案）扱い。
  • 必須チェックは決定論的処理で担保。
  • フォールバックを用意（LLMが失敗してもパイプラインは止めない）。

まとめ

• すべての失敗事例は「決定論で解ける領域にLLMを当ててしまう」という根本原理から生じる。
• ただし、現れ方は「技術的ミスマッチ」「リスク耐性」「説明可能性」「効率性」「運用設計」といった複数の観点に分けられる。
• ベストプラクティスは、ルールベース・人間判断・LLM補助を適材適所で組み合わせること。