LLMによるビジネスルールとワークフロー推論の扱い方

ビジネスルール推論はコード生成以上のもの

「LLMはビジネスルールについて“推論”できるか？」と聞かれたとき、人々はたいてい「if/else文を書けるか」よりも厳しい期待を持っています。ビジネスルール推論とは、方針を一貫して適用し、決定を説明し、例外を扱い、現在のワークフローステップに沿っていることを保つ能力です。特に入力が不完全で雑多、または変化している場合に重要です。

推論とコードの出力は違う

コード生成は主にターゲット言語で有効な構文を出力することに関する作業です。ルール推論は意図を保持することに関する作業です。

モデルは有効なコードを生成できても、ビジネス上の誤った結果を生むことがあります。その理由は:

• 方針文が曖昧（「最近の顧客」「高リスク」「承認済みの書類」など）。

• ルールが競合しており、優先順位が不明確。

• エッジケースが明示されていない（部分返金、重複、週末・祝日）。

• ワークフローの状態が次に何をすべきかを変える（受付 vs. 審査 vs. 最終承認）。

つまり、正しさは「コンパイルするか？」ではなく「ビジネスが毎回下すであろう判断と一致しているか、かつそれを証明できるか？」です。

LLMに何を期待すべきか

LLMは方針を構造化されたルールに翻訳したり、意思決定の経路を提案したり、人間向けの説明を下書きしたりできます。しかし、どのルールが優先されるか、どのデータソースが信頼できるか、あるいはケースがどのステップにあるかを自動的に知っているわけではありません。制約がなければ、ありそうな解答を自信満々に選んでしまい、統制されたものを選ばないことがあります。

したがって、目標は「モデルに決定させる」ことではなく、モデルが信頼できる支援をできるように構造とチェックを与えることです。

この記事の残りで扱うこと

実用的なアプローチはパイプラインのように見えます:

1. 方針文を利用可能なルール表現に変換する。
2. ワークフローの状態を追跡し、ステップ間で決定が一貫するようにする。
3. 優先事項、例外、説明を強制するプロンプトパターンを使う。
4. ツールと検索で決定を根拠づける（承認されたデータのみ使用）。
5. 出力をスキーマで制約して曖昧さを減らす。
6. 検証、テスト、モニタリングを行い、リリース前にミスを捕らえる。

それが、巧みなコードスニペットと、実際のビジネス判断を支えられるシステムの違いです。

ビジネスルールとワークフロー：簡単な英語での整理

「推論」について話す前に、チームがしばしば一緒に扱ってしまう二つのものを区別すると役に立ちます：ビジネスルールとワークフローです。

ビジネスルールとは？

ビジネスルールは組織が一貫して適用したい意思決定の記述です。方針やロジックとして現れます：

• 適格性： どの人が給付・プラン・機能の対象になるか？
• 価格設定： いつどの割引が適用されるか？
• 承認： いつマネージャーのレビューが必要か？
• コンプライアンス： 何を記録・編集・ブロックすべきか？

ルールは通常「IF X, THEN Y」の形で表現され（時に例外付き）、明確な結果を生むべきです：承認/拒否、価格A/価格B、追加情報を要求、など。

ワークフローとは？

ワークフローは作業を始めから完了まで移動させるプロセスです。何が許可されるかというよりも、次に何が起きるかに関するものです。ワークフローはしばしば以下を含みます：

• 状態： submitted → under review → approved/denied → completed
• ステップと引き継ぎ： カスタマーサポート → 財務 → 顧客
• 時間ベースのイベント： リマインダー、SLA、自動キャンセル（14日後）
• 成果物： フォーム、添付、理由コード、監査ノート

小さな例：返金リクエスト

返金リクエストを想像してください。

ルールの断片：「購入から30日以内は返金可。例外：デジタルダウンロードはアクセス後は返金不可。例外：チャージバックはエスカレーション。」

ワークフローの断片：

1. 顧客がリクエストを送信（状態：submitted）。
2. システムが購入日と商品タイプをチェック（状態：under review）。
3. 適格なら返金を発行し顧客に通知（状態：completed）。
4. チャージバックなら財務に調査で回す（状態：escalated）。

ルールが見た目より難しい理由

ルールは競合すると厄介になります（「VIPは常に返金される」対「デジタルはアクセス後は不可」）、文脈が欠けていると（ダウンロードはアクセスされたか？）、またエッジケース（バンドル、部分返金、地域法）が隠れていると厄介です。ワークフローは別の層を加えます：決定は現在の状態、以前のアクション、締め切りに一致している必要があります。

LLMが「推論する」方法：構造化されたパターンマッチング

LLMは人間のようにビジネスルールを「理解」しているわけではありません。大量のテキストから学んだパターンに基づいて次に最もありそうな単語を生成します。だから、入力が欠けているときや推測しているときでも説得力があるように聞こえるのです。

この制約はワークフローや意思決定ロジックにとって重要です。モデルは実際の方針に例外があるのに、聞こえは正しいルールを適用してしまうことがあります（「従業員は常にマネージャーの承認が必要」など）。これはよくある失敗モードです：自信はあるが間違っている。

それでもLLMがビジネスルールに有用な理由

真の「理解」がなくても、LLMは構造化されたアシスタントとして扱うと役立ちます：

• 長い方針文を要約してレビュー用に分かりやすくする。
• 雑多な文書を一貫したフィールド（who, what, threshold, exception, effective date）にマッピングする。
• 提案された決定を明示的にチェックして「どの条項がこれを支持するか？」を指摘する。

鍵はモデルが逸脱しにくい立場に置くことです。

モデルの迷走を防ぐ（制約を加える）

曖昧さを減らす実用的な方法は出力の制約です：LLMに固定のスキーマやテンプレート（例：特定フィールドを持つJSON、必須列を持つ表）で応答させます。モデルが rule_id, conditions, exceptions, decision を埋める必要がある場合、ギャップを見つけて自動で検証しやすくなります。

制約された形式はモデルが知らないことを示すのも簡単にします。必須フィールドが欠けていれば、あいまいな答えを受け入れるのではなくフォローアップを強制できます。

まとめ：LLMの「推論」は構造に導かれたパターンベースの生成だと見なすのがよく、ルールの整理と相互検証には有用ですが、誤りを起こしやすいことを忘れてはいけません。

雑多な方針文を使えるルール表現に変える

方針文書は人間向けに書かれており、目標・例外・常識が同じ段落に混ざっています。LLMはそれを要約できますが、方針を明示的でテスト可能な入力に変えるとより確実にルールに従えます。

「使える」ルールとは

良いルール表現は二つの特性を持ちます：曖昧でないこと、そして検査可能であること。

テストできる文としてルールを書く：

• 意思決定には IF/THEN（適格性、ルーティング、承認）
• ハード制約には MUST / MUST NOT
• 許容動作には MAY（ただしタイブレーカーが必要なことが多い）

モデルにルールを与える方法はいくつかあります：

• プレーンランゲージの箇条書き（最速、構造はある程度保たれる）
• 表（閾値ベースの方針に最適）
• YAML/JSON（出力制約や自動検証も行いたい場合に最適）

競合と優先順位の扱い

実際の方針は競合します。二つのルールが矛盾する場合、モデルには明確な優先順位が必要です。一般的なアプローチ：

• 特異は一般に勝つ（例外がデフォルトを上書きする）
• 上位権限が勝つ（法務/コンプライアンスはチーム方針より優先）
• 新しい方が勝つ（新しい方針バージョンが古いものを上書き）
• 明示的な優先度番号（最も確実）

競合解決ルールを明示するか、priority: 100 のようにエンコードしてください。そうしないとLLMはルールを「平均化」してしまうかもしれません。

例：段落をルールリストに変える

元の方針文：

“Refunds are available within 30 days for annual plans. Monthly plans are non-refundable after 7 days. If the account shows fraud or excessive chargebacks, do not issue a refund. Enterprise customers need Finance approval for refunds over $5,000.”

構造化ルール（YAML）：

rules:
  - id: R1
    statement: "IF plan_type = annual AND days_since_purchase <= 30 THEN refund MAY be issued"
    priority: 10
  - id: R2
    statement: "IF plan_type = monthly AND days_since_purchase > 7 THEN refund MUST NOT be issued"
    priority: 20
  - id: R3
    statement: "IF fraud_flag = true OR chargeback_rate = excessive THEN refund MUST NOT be issued"
    priority: 100
  - id: R4
    statement: "IF customer_tier = enterprise AND refund_amount > 5000 THEN finance_approval MUST be obtained"
    priority: 50
conflict_resolution: "Higher priority wins; MUST NOT overrides MAY"

これによりモデルは何が重要かを推測するのではなく、レビュー・テスト・バージョン管理できるルールセットに基づいて適用します。

ワークフロー状態を追跡してモデルの一貫性を保つ

ワークフローは単なるルール集合ではなく、前のステップが次に何が起きるかを変える一連のイベントです。その“記憶”が**状態（state）**です：ケースに関する現在の事実（誰が何を提出したか、何が既に承認されているか、何が保留中か、どの締め切りが適用されるか）。状態を明示的に追跡しないと、ワークフローは重複承認、必要なチェックのスキップ、決定の逆転、あるいはモデルが既に起きたことを信頼できず誤った方針を適用するなど、予測可能な失敗を起こします。

平易な言葉での「状態」の意味

状態はワークフローのスコアボードのようなものです。今どこにいるか、何が済んでいるか、次に何が許可されているかを答えます。LLMにとって明確な状態サマリがあれば、過去のステップを再審議したり推測したりするのを防げます。

モデルに状態を渡す方法

モデルを呼ぶときは、ユーザーの要求と一緒に簡潔な状態ペイロードを含めてください。有用なフィールド：

• ステップ名とステータス（例：manager_review: approved, finance_review: pending）
• 安定したID（request ID, employee ID）——モデルがケースを混同しないように
• タイムスタンプ（submitted at, last updated）——「最新が勝つ」状況を解決するため
• フラグ（方針例外、書類不足、エスカレーション要）

すべての履歴メッセージを渡すのは避け、現在の状態と主要な遷移の短い監査トレイルを提供してください。

単一の真実の情報源を保つ

ワークフローエンジン（データベース、チケットシステム、オーケストレータ）を単一の真実の情報源として扱ってください。LLMはそのシステムから状態を読み、次のアクションを提案するべきですが、遷移を記録するのはシステムが権威であるべきです。これによりモデルの語る内容と現実が乖離する「状態ドリフト」を減らせます。

例：承認フローの状態スナップショット

{
  "request_id": "TRV-10482",
  "workflow": "travel_reimbursement_v3",
  "current_step": "finance_review",
  "step_status": {
    "submission": "complete",
    "manager_review": "approved",
    "finance_review": "pending",
    "payment": "not_started"
  },
  "actors": {
    "employee_id": "E-2291",
    "manager_id": "M-104",
    "finance_queue": "FIN-AP"
  },
  "amount": 842.15,
  "currency": "USD",
  "submitted_at": "2025-12-12T14:03:22Z",
  "last_state_update": "2025-12-13T09:18:05Z",
  "flags": {
    "receipt_missing": false,
    "policy_exception_requested": true,
    "needs_escalation": false
  }
}

このようなスナップショットがあれば、モデルは一貫性を保てます：再度マネージャー承認を尋ねることはなく、財務チェックに集中し、現在のフラグとステップに基づいて決定を説明できます。

ルール遵守と決定を改善するプロンプトパターン

良いプロンプトは単に答えを求めるのではなく、モデルがどのようにルールを適用し、どのように結果を報告するかの期待を設定します。目標は再現可能な決定であり、見事な文章ではありません。

1) 役割プロンプティング：感覚ではなく役割を与える

プロセスに結びついた具体的な役割をモデルに与えます。よく使われる三つの役割：

• ポリシーアナリスト：方針文を解釈し、現在のケースにマッピングする。
• バリデータ：決定を要件に照らしてチェックし、入力欠落をフラグする。
• エージェント：次のワークフローアクションを実行する（チケット作成、メール下書き、ステータス設定）。

これらを連続実行（「アナリスト → バリデータ → エージェント」）するか、単一の構造化応答で三つの出力を求めてもよいです。

2) ステップごとの指示（隠れた思考を求めない）

「チェインオブソート」を要求する代わりに、可視的なステップと成果物を指定してください：

1. 関連するルールを特定する。
2. ケースから必要な入力を抽出する。
3. 優先順位順にルールを適用する。
4. 決定と次のステップを出す。

これによりモデルは整理され、どのルールが使われたか、どの結果が導かれたかに集中できます。

3) 構造化された根拠を求める：ルールID + 証拠

自由形式の説明は逸脱しがちです。使った根拠を簡潔に求めてください：

• 使用したルールID（例：R-12, R-18）
• 証拠（方針文からの引用スニペットと特定のケースフィールド）
• 仮定（入力が欠けている場合のみ）

これによりレビューが速くなり、意見の不一致のデバッグが容易になります。

4) チェックリストプロンプトパターン：入力、決定、例外、次のステップ

毎回固定テンプレートを使用します：

• 受け取った入力： …
• 不足している入力： …
• 決定： approve/deny/needs-review
• ルール参照： [R-…]
• 考慮した例外： …
• 次のワークフローステップ： ステータス更新 / 情報要求 / エスカレーション

テンプレートは曖昧さを減らし、モデルに不確かな点を表明させてから決定するよう促します。

ツールと検索を使って決定を現実データに基づける

LLMは重要な事実が欠けていると説得力のある答えを書くことができます。それは下書きには有用でも、ビジネスルールの決定にはリスクがあります。モデルがアカウントのステータスや顧客のティア、地域税率、既に達した上限を推測しなければならないと、自信ありげな誤りが出ます。

ツールは「まず証拠を取得し、次に決定する」という二段構えにして、推論を正す役割を果たします。

モデルを正確に保つ一般的なツール

ルールとワークフローが重要なシステムでは、いくつかのシンプルなツールが大部分の仕事をこなします：

• データベース参照（顧客プロファイル、アカウントステータス、権利、使用量合計）
• 方針/ルールストア（承認済みルール文、バージョン管理された手順、例外リスト）
• 計算機（手数料、按分、税、時間窓、閾値）
• チケッティング/ワークフローAPI（オープンケース、SLAタイマー、承認、ステップ完了）

重要なのは、モデルが運用上の事実を「作り上げる」のではなく、それらを要求することです。

検索：関係するルールだけを持ってくる

方針を中央に置いていても、現在のケースに全てをプロンプトに貼り付けるべきではありません。検索は現在のケースに最も関連する断片だけを選択します：

• 顧客のプランに対するキャンセルポリシー
• 顧客の国/州に基づく地域の順守条項
• チャージバックが保留中の場合に適用される例外ルール

これにより矛盾が減り、モデルが古いルールのせいで誤った行動をとるのを防げます。

ツール出力を決定の証拠に変える

信頼できるパターンはツール結果をモデルが引用すべき証拠として扱うことです。例：

1. ツール: get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000
2. ツール: retrieve_policies(query="overage fee Business plan") → returns rule: “Overage fee applies above 10,000 units at $0.02/unit.”
3. ツール: calculate_overage(usage=12000, threshold=10000, rate=0.02) → $40.00

これで決定は推測ではなく、特定の入力に基づく結論になります（“past_due”、“12,000units”、“$0.02/unit”）。後で監査するとき、どの事実とどのルールバージョンが使われたかを正確に辿れ、問題があれば該当箇所を直せます。

曖昧さを減らす制約付き出力：スキーマ

自由形式テキストは柔軟ですが、ワークフローが壊れる最も簡単な方法でもあります。モデルは「問題なさそう」といった自動化不可能な答えや、ステップ間で一貫しない表現（“approve”と“approved”など）を出しがちです。制約付き出力は、すべての決定を予測可能な形に強制します。

決定をJSONで返す

実用的なパターンは、モデルに単一のJSONオブジェクトで応答させ、それをシステムがパースしてルーティングすることです：

{
  "decision": "needs_review",
  "reasons": [
    "Applicant provided proof of income, but the document is expired"
  ],
  "next_action": "request_updated_document",
  "missing_info": [
    "Income statement dated within the last 90 days"
  ],
  "assumptions": [
    "Applicant name matches across documents"
  ]
}

この構造は、モデルが完全には決定できないときでも出力を有用にします。missing_info と assumptions は不確実性を隠れた推測にするのではなく、行動可能なフォローアップに変えます。

列挙型（enum）を使って結果を限定する

変動を減らすために主要フィールドに許容値を定義してください。例：

• decision: approved | denied | needs_review
• next_action: approve_case | deny_case | request_more_info | escalate_to_human

enumがあれば、下流システムは同義語や句読点、トーンを解釈する必要がなく、既知の値で単純に分岐できます。

スキーマがワークフローを安全にする理由

スキーマはガードレールの役割を果たします：

• 必須フィールドを要求して「不完全な回答」を防ぐ。
• reasons を通じて決定の理由を監査しやすくする。
• decision と next_action から直接キュー、通知、タスク作成がトリガーできるため自動化に適する。
• バリデーションをサポート：スキーマと合わない出力は拒否してモデルに再試行させる。

結果として曖昧さが減り、エッジケースの失敗が減り、ワークフローを通じた決定の一貫性が高まります。

本番投入前にエラーを捕らえるための検証戦略

適切にプロンプトされたモデルでも、ルール違反や必要なステップのスキップ、値の捏造を静かに起こすことがあります。検証は、そのような“もっともらしい”答えを信頼できる決定に変える安全網です。

事前チェック：推論前に入力を検証する

まず、ルールを適用するのに最低限必要な情報がそろっているかを検証します。事前チェックはモデルが決定する前に実行されるべきです。

典型的な事前チェック：必須フィールド（顧客タイプ、注文合計、地域）、基本フォーマット（日付、ID、通貨）、許容範囲（非負の金額、割合は100%まで）など。何かが失敗したら、モデルに推測させるのではなく明確で実行可能なエラーを返します（例：「'region' が欠落しているため税ルールを選べません」）。

事後チェック：決定がルールと整合するかを検証

モデルが結果を出した後、その結果がルールセットと矛盾しないか検証します。

注目点：

• ルール適用の網羅：決定は該当ルールを引用またはマッピングしているか？必須ポリシーをスキップしていないか？
• 矛盾チェック：出力が入力と矛盾していないか（例：「approved」でありながらハードブロック条件が真である）
• 境界値ケース：閾値（ちょうど$10,000）、空状態（“違反なし”）、わずかに超えたシナリオなどをテスト

二段階検証：意図的なレビューステップ

最初の回答を再評価する「セカンドパス」を追加します。これは別のモデル呼び出しか、同じモデルを使ったバリデータ風のプロンプトで、創造性ではなく準拠性だけをチェックします。

単純なパターン：第一パスは決定＋根拠を出し、第二パスは valid か失敗項目の構造化リスト（不足フィールド、違反制約、あいまいなルール解釈）を返す。

ログ：決定を監査可能にする

すべての決定について、使用した入力、ルール/ポリシーバージョン、検証結果（セカンドパスを含む）をログに残します。問題が起きたときはこれにより正確な条件を再現でき、ルールマッピングを直し、修正を確認できます——モデルが「どう言いたかったか」を推測する必要はありません。

ルールとワークフローの信頼性を保つためのテストとモニタリング

LLMを使ったルール／ワークフロー機能のテストは「何か生成したか？」よりも「注意深い人間が同じ状況で下す決定を、正しい理由で毎回下したか？」を重視します。良いニュースは：従来の決定ロジックと同じ規律でテストできることです。

ビジネスルールのユニットテスト（小さく予測可能なチェック）

各ルールを関数として扱い、入力に対して期待する結果をアサートします。

例：返金ルール「未開封アイテムは30日以内なら返金可」があるなら、集中したケースを用意：

• 注文日 = 10日、未開封 = true → approve
• 注文日 = 10日、未開封 = false → deny
• 注文日 = 45日、未開封 = true → deny
• 境界：ちょうど30日、unopened が欠落、矛盾信号

これらのユニットテストはオフバイワンのミス、フィールド欠落、「親切」なモデルが未知を埋めようとする挙動を捕らえます。

ワークフローのシナリオテスト（マルチステップ、時間を意識した経路）

ワークフローはステップ間で状態が不整合になると失敗します。シナリオテストは実際の経路をシミュレートします：

• パステスト：請求を送信 → 書類要求 → 書類受領 → 決定
• 時間ベースのエッジ：7日応答無しならリマインダー、30日でクローズ
• 分岐：顧客がエスカレート、方針例外が要求される、重複ケース検出

目的はモデルが現在の状態を尊重し、許可された遷移のみを取ることを検証することです。

「ゴールドセット」：既知の良いケースの構築

実例の匿名化されたケース集（期待結果と簡潔な根拠付き）を用意し、バージョン管理してください。100～500件の小さなゴールドセットでも、欠落データや異常な文言、境界判断といった現実の雑多さを反映して強力です。

本番モニタリング（顧客に問題が伝わる前にドリフトを検出）

時間とともに決定分布と品質信号を追跡：

• ドリフト：ポリシー更新なしに承認/拒否率が変化
• needs_review や人手への引き渡しが急増（多くはプロンプト、検索、上流データの問題）
• 製品、地域、ポリシーカテゴリ別のエラークラスター

モニタリングは安全なロールバックと合わせます：以前のプロンプト／ルールパックを保持し、新バージョンはフィーチャーフラグで出し、メトリクスが悪化したら迅速に戻せるようにします。運用プレイブックとリリースゲーティングの例は /blog/validation-strategies を参照してください。

Koder.ai がこのパイプラインで果たす役割

上記のパターンを実装すると、通常はモデルの周りに小さなシステムを構築することになります：状態ストレージ、ツール呼び出し、検索、スキーマ検証、ワークフローオーケストレータ。Koder.ai はその種のワークフロー対応アシスタントをより早くプロトタイプし本番化するための実用的な方法です：チャットでワークフローを記述すると、動作するWebアプリ（React）とバックエンドサービス（Go + PostgreSQL）を生成し、スナップショットとロールバックを使って安全に反復できます。

これはビジネスルール推論にとって重要です。なぜなら「ガードレール」はしばしばプロンプトではなくアプリケーションに置かれるからです：

• Planning mode は実行前にフロー（状態、許可遷移、エスカレーション経路）を設計するのに役立ちます。
• スキーマ制約された応答 はAPI境界で強制できるため、解析可能な決定だけを受け入れます。
• ツールフック（DB読み取り、方針検索、計算機、チケット更新）は明示的なエンドポイントとして実装でき、「まず証拠を取得し、次に決定する」ことをデフォルトにします。
• ソースコードのエクスポート によりプロトタイプが本番クリティカルになってもロックインを避けられます。

限界、安全な利用、そしていつ人間を介入させるべきか

LLMは日常的な方針適用でかなり有用になり得ますが、決定論的なルールエンジンと同等ではありません。LLMはガードレールを必要とする決定アシスタントとして扱い、最終決定権を与えないでください。

LLMが苦手な領域

ルール重視のワークフローで繰り返し現れる失敗モードは三つです：

• 稀な例外とエッジケース：年に一度しか起きない例外は学習データにほとんど現れず、プロンプトや方針から明示的に与えられないと見落とされがち。
• 長いコンテキストと“埋もれた”制約：重要な詳細が多数のページやメッセージに散らばっていると、モデルは最新や印象に残った文を過大評価し、初期の制約を過小適用する。
• 数値の精度と厳密な計算：合計、按分、閾値、丸め規則はズレることがある。計算はツールに任せ、モデルに使用した正確な数値を引用させる。

人間のレビューを必須にすべきとき

以下の場合は必ずレビューを入れてください：

• 結果が高リスク（金銭移動、コンプライアンス、安全、法的約束、顧客の信用/適格性）。
• モデルが自信低めを示すとき（入力を推測する、方針根拠が見つからない、矛盾する推論を出す）。
• ケースが初めて（新製品、新地域、方針が最近変更）か敏感な場合。

エスカレーション経路で作業を止めない設計

モデルに「何かを作り上げさせる」代わりに、明確な次のステップを定義します：

1. 確認質問をする（欠落日付、顧客ティア、管轄、承認状況）。
2. 抽出された事実、提案決定、引用を付けて担当者に回す。
3. 方針があいまい・矛盾する場合はチケットを作る。これにより根本的な方針が修正されれば将来は自動的に参照できる。

簡単な導入フレームワーク

次の問いに大部分で「はい」と答えられるとき、ルール重視ワークフローでLLMを導入してください：

• 決定を承認された方針文やシステムデータで**根拠付け（ground）**できるか？
• 出力を**制約（スキーマ、許可されたアクション、必須引用）**できるか？
• 実行前に検証（チェック、閾値、ユニットテスト、サンプリング）できるか？
• 危険・不確実なケースのための人間によるエスカレーション経路があるか？

もし答えが「いいえ」なら、これらのコントロールが整うまでLLMはドラフト/アシスタント役に留めておいてください。