業務システムに「判定」のロジックを組み込むとき、LLM（大規模言語モデル）にそのまま判断させるか、従来通り決定的なコード（入力が同じなら必ず同じ結果を返す処理）で判定するか、迷う場面があります。審査・適格性チェック・与信判断・資格確認など、間違えると利用者が実害を被る処理ほど、この選択は重くなります。
ナイジェリアの大学入試を題材にした「Clearance Desk」という事例があります。これは、JAMB（統一大学入学試験機構）のUTME（統一大学入学試験）のスコアや科目、O'levelという中等教育修了試験の結果が、志望大学・学部の出願要件を満たしているかを出願前にチェックするエージェントです。Physics（物理）の単位が2回目の受験（セカンドシッティング）で取得されたものだと一部大学では無効になる、Further Maths（上級数学）の単位がないとUNILAGの情報科学には出願できない、といった細かいルールを、出願後の「クリアランス」段階まで気づかずに合格取り消しになるケースが実際にあるそうです。この設計が採用した役割分担は、業務システムでAIをどこまで信用するかを考える上で参考になります。
どんな場面でこの判断が必要になるか
審査・判定系の機能にLLMを組み込もうとする場面は、社内ツールでもプロダクトでも増えています。
- 規約・資格要件への適合判定（出願要件、契約条件、与信スコアリングなど）
- 問い合わせ内容から対応可否を判断するサポートボット
- コンプライアンスチェックやポリシー違反の自動検知
- 複雑な分岐ルールを持つワークフローの自動化
これらに共通するのは、「判定結果が間違っていたときのコストが高い」という点です。チャットの雑談なら多少の誤答は許容されますが、合否判定や与信判断の誤りは、利用者の人生や金銭に直結します。
判断軸
ルールの構造化可能性
まず確認すべきは、判定ルールが「構造化されたデータ」として表現できるかどうかです。
Clearance Deskの実装では、出願要件をSanity（ヘッドレスCMSの一種で、コンテンツやデータをAPI経由で管理する基盤）上に、requirement・programme・institution・subjectといったドキュメント型で保存しています。「英語・数学必須、物理か化学のどちらか1科目」というルールは、自然言語の一文ではなく、utmeCompulsory（必須科目の配列）やutmeChoices（pick: 1, from: [科目参照]）という集合演算の問題として表現されています。
同様に「5科目1回受験、または6科目2回受験まで許容」(UIの要件)のようなルールも、olevelMinCredits・olevelMaxSittingsといったフィールドに落とし込まれています。
自分のプロジェクトでも、判定ルールを「もし〜なら〜」という条件分岐の集合として書き出せるかを試してみる価値があります。書き出せるなら、それはLLMの柔軟な解釈ではなく、決定的なコードが向いているサインです。
誤判定の非対称コスト
次に見るべきは、誤判定のコストが「過大評価」と「過小評価」で非対称かどうかです。
Clearance Deskの文脈では、本当は出願資格がないのに「Eligible（適格）」と誤って表示することは、1年を棒に振る出願ミスに直結します。逆に資格があるのに厳しめに「At risk（リスクあり）」と出すことは、再確認の手間が増えるだけで致命傷にはなりません。
このような非対称性がある業務では、曖昧さを残すLLM単体の判定よりも、決定的ロジックで安全側に倒す設計が理にかなっています。
説明責任と追跡可能性
3つ目の軸は、「なぜその判定になったか」を利用者に説明できる必要があるかどうかです。
Clearance Deskは、判定そのものはTypeScriptの評価器（決定的コード）が行い、Claude（Anthropic社の対話型AIモデル）はその結果を根拠付きの平易な文章で説明する役割に限定しています。設計方針として明記されているのが「the model finds and explains; deterministic code judges（モデルは探して説明する、判定するのは決定的コード）」という原則です。回答はJAMBと大学の公式通知のみを根拠にし、すべての情報源にリンクを張る仕組みになっています。
監査・規制対応が必要な業務では、この「判定と説明を分離する」構造が効いてきます。LLMにすべて任せると、同じ入力でも説明の仕方や細部の表現が揺れ、再現性のある監査証跡を残しにくくなるためです。
開発・運用コストの見合い
最後の軸は、決定的ロジックを書くコストが見合うかどうかです。
Clearance Deskのリポジトリには、評価器に対する49件のユニットテストが含まれています。ルールをコード化し、テストで固めるには初期コストがかかります。ただし一度固めてしまえば、対象大学やルールが増えても、データを追加するだけで判定ロジックは再利用できます。
小規模な一回限りの判定であれば、LLMに任せたほうが開発コストは低く済む場合もあります。継続的に使われる・ルールが頻繁に参照される機能かどうかで、投資対効果は変わってきます。
選択肢の比較
| 方式 | 得意なこと | 弱点 |
|---|---|---|
| LLM単体で判定 | 曖昧な自然文の解釈、未知パターンへの対応 | 再現性がない、説明が毎回変わる、誤判定の追跡が困難 |
| 決定的コードのみ | 再現性、テストによる保証、監査証跡 | ルールの構造化に初期コストがかかる、例外対応が硬直的 |
| LLM+決定的コードの併用 | 判定の正確さと説明の自然さを両立 | 設計・実装の手間が増える、役割分担の設計ミスが起きやすい |
ケース別の推奨
- 要件が頻繁に変わらず、条件分岐として書き出せる業務（資格審査・料金プラン適合・与件要件チェックなど）は、決定的コードで判定し、LLMには結果の説明・質疑応答だけを任せる構成が向いています
- 利用者からの自由記述の質問に答える必要がある場合（「このケースだとどうなりますか」のような問い合わせ）は、Knowledge Base的な仕組みを別途用意し、LLMが公式情報源だけを参照して回答する設計が参考になります
- ルールがまだ流動的で頻繁に変わるプロトタイプ段階では、まずLLM単体で判定ロジックの叩き台を作り、安定してきた部分から決定的コードへ移行する進め方も現実的です
- 誤判定のコストが低く、やり直しが容易な社内ツール（下書きのトリアージ、FAQの一次回答など）は、LLM単体でも十分機能します
あえて見送るべき条件
決定的コードへの分離を急ぐべきでないケースもあります。
判定ルールがそもそも人間の専門家の間でも意見が割れる・頻繁に改訂される性質のものであれば、無理に構造化データへ落とし込むコストが開発速度を損ないます。また、判定対象が少数・一度きりで再利用の見込みがない場合も、評価器やテストを整備する投資は回収しにくくなります。
さらに、組織内にTypeScriptやPythonでロジックとテストを書ける担当者がいない状態で、見た目だけLLMと決定的コードを分離しようとすると、結局「決定的コード」の部分がブラックボックスのプロンプトに戻ってしまうことがあります。分離の恩恵を得るには、ルールをコードとテストとして維持できる体制が前提になります。
まとめ
判定ロジックをAIに任せるかどうかは、「ルールが構造化できるか」「誤判定のコストが非対称か」「説明責任が必要か」「構造化コストに見合う継続利用があるか」の4つの軸で整理すると判断しやすくなります。
まず手を動かすなら、自分のプロジェクトの判定ルールを条件分岐の形で紙に書き出してみることです。きれいに書き出せるなら、それは決定的コードに切り出す候補であり、LLMには説明・要約・質疑応答の役割を残す設計を検討してみてください。