SLM実装設計 ── 事前定義推論で法律・金融・医療の信頼性を担保

2026年2月時点で、生成AIを高信頼領域に適用する実装は「自由生成を後で検査する」方式から、「生成前に推論経路を制約する」方式へ移行しつつある。本稿ではこの設計思想を Structured Language Models（SLM）と定義し、法律・金融・医療で使える実装パターンとして整理する。なおSLMは単一ベンダー製品名ではなく、2026年に普及した実装アーキテクチャ上の呼称として扱う。

背景にあるのは、LLMのハルシネーション問題が「精度向上」だけでは解決しないという業界共通の認識である。GPT-5.3 Instantでもハルシネーション率は26.8%の削減にとどまったように、自由生成モデルの出力品質には原理的な限界がある。医療診断支援や金融審査補助のように「1件の誤答が訴訟・行政処分に直結する」領域では、精度向上のアプローチだけでは不十分であり、推論プロセスそのものを構造的に制約する設計思想が求められている。

SLMの作業定義: 事前定義推論を中核に置く

SLMの要点は、モデル出力を「自然言語全文」ではなく「制約付きの状態遷移」として扱う点にある。2024年8月6日に公開されたOpenAIのStructured Outputsは、スキーマに一致する出力を生成時点で担保する constrained decoding を説明している。これは事後パーサではなく、探索空間そのものを狭める設計である。

実装上は、以下の4要素を固定する。

許可された推論ステップ集合 ── モデルが取れる推論パスを事前に列挙し、未定義の推論ステップへの遷移を構文レベルで禁止する。たとえば金融審査では「信用スコア算出→返済能力評価→総合判定」の3段階を固定し、モデルが独自の判断基準を生成することを防ぐ。
スキーマ付き中間表現 ── 各推論ステップの出力をJSON Schemaで型定義する。自由記述ではなく、列挙型（enum）・数値範囲（minimum/maximum）・必須フィールドで出力空間を制限する。
証拠参照必須ルール ── 各推論ノードに evidence_id フィールドを必須化し、根拠文書への参照がないノードをバリデーション時点で失敗させる。これにより「もっともらしいが根拠のない結論」がシステム的に通過できなくなる。
不確実時の保留・エスカレーション ── 確信度が閾値を下回る場合、回答を「保留」ステータスで出力し、人間レビュアーへのエスカレーションを強制する。高信頼領域では、誤答して即答するモデルより、判断を保留して人に渡すモデルの方が業務価値が高い。

ここで重要なのは「正解を当てる確率」を直接上げることではなく、「不正な推論をシステム的に通さない」ことである。従来のGuardrails（出力フィルタリング）は生成後に検査を行うため、モデルが一度生成した不正確な推論チェーンが検査をすり抜けるリスクが残る。SLMは生成プロセス自体を構造化することで、この根本問題を解決する。

参照実装: Policy Engine + Typed Reasoning Graph

実運用では、LLM本体の前後に制御層を置く三層構成が安定する。

層	名称	責務	実装例
第1層	入力正規化・リスク分類	ユーザー入力をパースし、リスクレベルを判定	FastAPIエンドポイント + Pydanticバリデーション
第2層	型付き推論グラフ（Typed Reasoning Graph）	制約付きの推論ステップを順次実行	LangGraph / DSPy パイプライン + JSON Schema
第3層	Policy Engine	ドメイン規則に基づく最終検証・承認/拒否	OPA (Open Policy Agent) / カスタムルールエンジン

生成は常に「ノード評価→制約検証→次ノード確定」の反復で進む。各ノードの出力は型付きスキーマで定義されているため、フリーテキスト生成とは異なり、中間結果の妥当性を自動検証できる。

ハルシネーション抑制の3経路

この三層設計により、ハルシネーションは主に3つの経路で抑制される。

経路1: 語彙・形式制約による無効トークン除外 ── Constrained Decodingにより、スキーマに一致しないトークン列を探索対象から除外する。たとえば「判定結果」フィールドが enum: ["承認", "保留", "拒否"] と定義されていれば、モデルは3択以外の値を出力できない。OpenAI Structured Outputsの技術は、この層の実装を大幅に簡素化した。

経路2: 根拠欠落の構文レベル検出 ── 各推論ノードに evidence_id を必須化し、根拠欠落を構文レベルで失敗させる。従来の「RAGで根拠文書を取得→LLMが自由に参照」というパイプラインでは、モデルが取得した根拠を無視して独自の推論を行うリスクがあった。SLMでは、根拠参照がスキーマの必須フィールドとして定義されるため、参照なし推論は構文エラーとして検出される。

経路3: Policy Checkによる規制違反・根拠不足のreject ── 最終回答の前に policy_check ノードを必須通過にし、ドメイン固有の規制ルールとの整合性を検証する。Open Policy Agent（OPA）のようなルールエンジンと組み合わせることで、「金融商品取引法に抵触する表現がないか」「医薬品医療機器法の広告規制に違反しないか」といったドメイン固有の検証を自動化できる。

実装コード例: 型付き推論ノードの定義

{
  "reasoning_step": "credit_score_evaluation",
  "input_schema": {
    "type": "object",
    "properties": {
      "applicant_data": { "$ref": "#/definitions/ApplicantProfile" },
      "credit_history": { "$ref": "#/definitions/CreditHistory" }
    },
    "required": ["applicant_data", "credit_history"]
  },
  "output_schema": {
    "type": "object",
    "properties": {
      "score": { "type": "integer", "minimum": 0, "maximum": 1000 },
      "risk_level": { "enum": ["low", "medium", "high", "very_high"] },
      "evidence_ids": { "type": "array", "items": { "type": "string" }, "minItems": 1 },
      "confidence": { "type": "number", "minimum": 0, "maximum": 1 }
    },
    "required": ["score", "risk_level", "evidence_ids", "confidence"]
  },
  "escalation_threshold": { "confidence_below": 0.7 }
}

このスキーマ定義により、信用スコアは0〜1000の整数範囲に制約され、リスクレベルは4択の列挙型に固定される。根拠IDは最低1件必須であり、確信度が0.7未満の場合は自動的にエスカレーションが発火する。

法律・金融・医療での信頼性要件マッピング

法律領域: 推論グラフによる監査証跡

EU AI Actが2024年8月1日に発効し、用途に応じたリスク管理・透明性・記録保持を要求する枠組みが明確化された。2026年8月にはAnnex III高リスクAIシステムの適合性評価が完全施行される。法律AI（契約レビュー、判例検索、規制適合チェック等）は高リスクカテゴリに分類される可能性が高く、「どの規則に基づいてどの結論に到達したか」を再現可能な形で記録する必要がある。

SLMでは、推論グラフの各ノードにタイムスタンプ・入力データ・適用ルール・出力結果・根拠文書IDを記録する。この構造化されたログは、従来の「LLMの出力テキストをそのまま保存」する方式と比較して、監査時に格段に追跡しやすい。特に、推論の途中でどのルールが適用され、どの時点で判断が分岐したかを、グラフ構造として可視化できる点が大きな利点である。

金融領域: SR 11-7モデルリスク管理との整合

金融領域では、米連邦準備制度理事会のSR 11-7（2011年4月4日）が示すモデルリスク管理原則が依然として基盤である。特に conceptual soundness（概念的健全性）、継続的監視、独立検証の3要件は、SLMのノード単位評価・ドリフト検知・再現可能ログと直接整合する。

筆者自身、暗号通貨自動取引システムの開発経験から、金融系システムではミリ秒単位のレイテンシが直接損益に影響する現実を体感している。SLMの推論グラフは、自由生成と比較して推論ステップ数を事前に固定できるため、レイテンシの予測可能性が大幅に向上する。金融審査のSLA要件（例: 応答時間3秒以内）を設計段階で担保できる点は、実運用では精度と同等に重要な要素である。

自由生成モデル単体では、同じ入力に対して異なる推論経路を取る非決定性が問題になる。SLMでは推論経路を固定するため、「同一入力に対して同一経路で推論する」再現性を確保でき、独立検証の要件を満たしやすい。

医療領域: FDAライフサイクル管理との適合

FDAが2024年9月28日に公開したドラフトガイダンス（AI-enabled device software functions）では、ライフサイクル全体の透明性と変更管理が重視されている。SLMでは、推論手順を事前定義し、更新時に「どのノード規則が変わったか」を差分管理できるため、変更審査に必要な説明可能性を担保しやすい。

具体的には、SLMの推論グラフはバージョン管理システム（Git等）と親和性が高い。各推論ノードのスキーマ定義をJSON/YAMLファイルとして管理すれば、変更差分をプルリクエストとしてレビューし、承認フローに載せることができる。これは「モデルの重みを更新する」という不透明な変更と比較して、規制当局への説明コストを大幅に削減する。

また、医療分野特有の要件として「なぜその判断に至ったか」を患者や医療従事者に説明する責任がある。SLMの推論グラフは、自然言語による説明文を各ノードに付加できるため、専門家以外にも判断プロセスを示すことが可能になる。

SLMとRAGの統合設計

SLMはRAG（Retrieval-Augmented Generation）を代替するものではなく、むしろRAGを推論パイプラインの一部として組み込む上位アーキテクチャである。従来のRAGパイプラインでは「検索→取得→生成」の3ステップが暗黙的に実行されるが、SLMではこれを明示的な推論ノードとして定義する。

比較項目	従来RAG	SLM + RAG統合
検索クエリ生成	LLMの自由生成	スキーマ定義されたクエリオブジェクト
根拠文書の利用	コンテキストに追加（利用は任意）	`evidence_id`必須、未参照は構文エラー
回答の根拠追跡	事後的にAttribution	推論グラフで構造的に追跡可能
矛盾する根拠への対応	モデル判断（不透明）	Policy Engineで判定ルール明示
根拠不足時の挙動	推測で回答する傾向	エスカレーション強制

この統合設計により、RAGの「正しい文書を取得したのにモデルが無視する」問題と、「取得した文書が矛盾する場合にモデルが恣意的に選択する」問題の両方を構造的に解決できる。

運用設計: ハルシネーションを「検出」から「予防」へ

本番運用のKPIは、正答率だけでなく以下の4指標を同時に設定すべきである。

KPI	定義	推奨閾値	測定方法
未根拠回答率	`evidence_id`が不足した回答の比率	0%（スキーマ制約で強制）	推論ログの構文検証
Policy Reject率	Policy Engineで拒否された回答の比率	5〜15%（適正範囲）	Policy Engine ログ
エスカレーション率	人手レビューに回された回答の比率	10〜25%（初期運用時）	エスカレーションキュー
SLA遵守率	応答時間がSLA内に収まった比率	99.5%以上	APMツール

Policy Reject率が5%を下回る場合、ルールが緩すぎる可能性がある。逆に30%を超える場合、モデルの基礎性能が用途に合っていないか、推論グラフの設計が過度に制約的である可能性を検討すべきである。

AI ROI測定の2026年転換点でも指摘されているように、生成AIの投資対効果は「正答率」だけでは測定できない。SLMでは「エスカレーション率の低下」「監査コストの削減」「コンプライアンス違反の未然防止件数」といった運用指標でROIを測定する設計が推奨される。

導入ロードマップ: 3四半期段階導入

推奨する導入順序は以下の3段階である。

第1四半期（PoC）: 単一ユースケースをSLM化する。最も効果が見えやすいのは、規則が明確で評価基準を定義しやすい業務（金融の審査補助、医療の文書要約、法務の条項チェック等）である。この段階では、既存のLLMパイプラインとSLMパイプラインを並行運用し、出力品質を比較評価する。

第2四半期（監査基盤構築）: 推論ログの永続化と再評価パイプラインを構築する。各推論ノードのログをデータレイクに蓄積し、定期的に「過去の判断が現在のルールでも妥当か」を再評価する仕組みを追加する。ドリフト検知（推論パターンの変化検出）もこの段階で導入する。

第3四半期（水平展開）: 複数ドメインへSLMを展開する。共通の推論グラフ基盤（Typed Reasoning Graph Engine）を構築し、ドメイン固有のルールセットを差し替えるだけで新しいユースケースに対応できるアーキテクチャを目指す。

SLM導入時の技術的課題と対策

SLMは万能ではない。導入時に頻出する技術的課題と、その対策を整理する。

課題1: 推論ステップの事前定義が困難なケース

法律相談や医療診断のように、状況に応じて推論パスが大きく分岐するケースでは、全パスを事前列挙することが現実的でない場合がある。対策としては、推論グラフを「固定ノード」と「動的ノード」のハイブリッドで設計する。固定ノードで大枠の推論フレームを制約し、動的ノードで分岐先を限定的に許容する。動的ノードにも出力スキーマは必須とすることで、完全な自由生成への退行を防ぐ。

課題2: レイテンシの増加

三層構成は自由生成と比較してオーバーヘッドが発生する。特にPolicy EngineでのルールチェックとJSON Schemaバリデーションがボトルネックになりやすい。対策としては、(a) スキーマバリデーションの並列実行、(b) Policy Engineのルールキャッシュ、(c) 推論ノード数の最小化（不要な中間ステップの排除）がある。実測では、5ノード構成のSLMパイプラインで、自由生成比+300〜500msのオーバーヘッドに収まるケースが多い。

課題3: ルールの陳腐化

法規制やガイドラインの改訂に応じて、Policy Engineのルールセットを更新し続ける必要がある。EU AI Actの段階的施行スケジュールのように、規制環境は常に変化する。対策としては、ルールセットをIaC（Infrastructure as Code）と同様にバージョン管理し、変更時にはCIパイプラインで回帰テストを自動実行する仕組みを構築する。

実務者の視点: LLMの「構造化」は現場でどう機能するか

筆者はタオリス（人機和総研）の運営において、LLMをメディアコンテンツ生産に活用する中で、ハルシネーション対策と格闘してきた。この経験から断言できるのは、LLMを高信頼用途に使う上で最も難しいのは「精度向上」ではなく「誤りの検出可能性」の担保である。自由生成モデルが出力した文章は、一見もっともらしく見えるため、人間レビュアーが誤りを見落とすリスクが高い。SLMの推論グラフは、各ステップの根拠と判断基準を明示するため、レビュアーの検証負荷を構造的に下げる。

SLMの本質は「賢い1モデル」を作ることではなく、「誤ると危険な推論を設計で無効化するシステム」を作ることにある。AI導入のROIが問われる2026年において、この「予防設計」の思想は、技術的な正確性と事業リスク管理の両面で、今後の標準アーキテクチャになると考える。

FAQ

SLMは小型モデル（Small Language Model）の略か？

本稿のSLMはSmall Language ModelではなくStructured Language Modelsの略である。モデルサイズではなく、事前定義推論と制約付き生成を中心に据えた実装思想を指す。Microsoft等が使う「SLM = Small Language Model」とは別概念である。

RAGを導入していればSLMは不要か？

不要ではない。RAGは根拠候補の取得に強いが、推論手順そのものを制約しない。SLMはRAGを取り込んだ上で、推論ノード・出力スキーマ・ポリシー判定を固定し、誤推論の通過確率を下げる設計である。RAGとSLMは競合ではなく、相補的な関係にある。

ハルシネーションはゼロにできるか？

ゼロ化は現実的ではない。実務上は、未根拠回答を自動拒否し、閾値未満の確信度を保留に回すことで、重大誤答の発生率を許容水準まで下げる設計が現実解となる。SLMは「ゼロを目指す」のではなく「検出不能な誤りをシステム的にゼロに近づける」ことを目的とする。

どの業界から導入すべきか？

まずは規則と監査指標が明確な業務から始めるべきである。金融の審査補助、医療の文書要約、法務の条項チェックなど、評価基準を定義しやすい領域が初期導入に適している。自由度が高いクリエイティブ業務には過剰設計になる可能性がある。

SLMの導入コストはどの程度か？

PoC段階では、既存のLLMパイプラインに推論グラフとPolicy Engineを追加する形で、エンジニア2〜3名・2〜3ヶ月程度が目安となる。ただし、ドメイン固有のルールセット策定にはドメインエキスパートの関与が必須であり、この人件費が全体コストの40〜60%を占めるケースが多い。

既存のGuardrailsフレームワークとどう違うのか？

Guardrails（NVIDIA NeMo Guardrails等）は主に出力フィルタリングに焦点を当てており、生成後に不適切な出力を検知・ブロックする。SLMは生成プロセス自体を構造化し、不適切な推論経路を事前に排除する点が本質的に異なる。両者は排他ではなく、SLMの最終出力にGuardrailsを追加する多層防御も有効である。

オープンソースで実装できるか？

可能である。推論グラフの構築にはLangGraph（LangChain）やDSPy、Policy EngineにはOpen Policy Agent（OPA）、スキーマバリデーションにはPydantic + JSON Schemaの組み合わせが実績ある構成である。LLM本体はOpenAI GPT-4o（Structured Outputs対応）やAnthropic Claude（Tool Use対応）を利用し、制御層をオープンソースで構築するハイブリッド構成が現時点での最適解といえる。

参考文献

Introducing Structured Outputs in the API — OpenAI, 2024-08-06
Supervisory Guidance on Model Risk Management (SR 11-7) — Board of Governors of the Federal Reserve System, 2011-04-04
AI Act enters into force — European Commission, 2024-08-01
Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft Guidance) — U.S. FDA, 2024-09-28
Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST, 2023-01-26

Structured Language Models（SLM）の実装設計 ── 事前定義推論で法律・金融・医療の信頼性要件に応える新アーキテクチャ