決定論 vs 確率論：Gemini 3 FlashとTF-IDFを組み合わせた「法規判定エンジン」の構築

https://genai-users.connpass.com/event/391381/

複雑な例外規定や、政令・省令への外部参照（ポインタ）が張り巡らされた法規の解析は、確率論で動くLLM単体では「最も失敗しやすい」領域の一つです。
本セッションでは、「古典NLP（決定論）」と「生成AI（確率論）」を垂直統合したハイブリッド判定エンジンの設計思想とソースコードを徹底解説します。
【こんな方におすすめ】

生成AI（LLM）のハルシネーション対策に苦労しているエンジニア
RAG（検索拡張生成）の精度が上がらず、構造的な解決策を探している方
法律や規約など「1文字の揺らぎも許されない」ドメインでのAI活用に興味がある方
「最新のAIさえあれば古い技術は不要」という風潮に一石を投じたい方
【学べること】

法的効力の5層スタック： 憲法から条例までをITインフラとして解釈する視点
決定論的ガードレール： TF-IDFとコサイン類似度を用いた、揺るがない根拠の引き当て方
リーガル・コンパイラ： 法令XMLから論理フラグ（例外・準用）を抽出する前処理技術
プロンプト注入の極意： LLMの推論空間を物理的に制限し、論理推論マシンとしてのみ機能させる方法

Transcript

1. 決定論 vs 確率論： LLMと古典自然言語処理を組み合わせた「法規判定エンジン」 生成AIをそのまま使うと失敗する場合を解説 2026年4月30日 日本生成AIユーザ会 勉強会 株式会社スリーシェイク 小渕 周 Shu Kobuchi
2. • 生成AIが法律を間違える問題を、古典NLPの前処理で解いたプロトタイプを 読む • NLPの基礎を押さえる ◦ トークナイズ → BoW → TF-IDF → コサイン類似度 ◦ O'Reilly『実践 自然言語処理』に沿って整理 • 5機種ベンチで見えた「失敗の質の差」と、設計指針を共有 ◦ 技術スタック解説 + NLPミニ入門 + 5機種比較の3本立て ◦ 本質は「LLMをどこで縛り、どこで自由にさせるか」のアーキテクチャ論 本日のゴール 2 / 42 Copyright © 3-shake, Inc. All Rights Reserved.
3. • 自己紹介 ◦ 小渕 周（Shu Kobuchi） ◦ 学生時代:神戸大学海事科学部 → 卒論でVSM × コサイン類似度を使ったレポート盗作検出 (2008年度) ◦ 大学院:奈良先端(NAIST) 情報科学研究科、 P2P と強化学習を研究、松本研の授業を受講 ◦ 現在、株式会社スリーシェイク Sreake事業部 アプリケーション開発 マネージャー • 古典NLPには学生時代に触れていた ◦ 卒論で書いたVSM × cos類似度のコードが、18年経って生成AIの尻拭いに使えるとは思わな かった • 今日のテーマは「2008年式の決定論」と「2026年式の確率論」のハイブリッド 自己紹介と本プロジェクトの背景 3 / 42 Copyright © 3-shake, Inc. All Rights Reserved.
4. • 「自転車の青切符を生成AIに聞いたら間違っていた」というX投稿 ◦ 直接のトリガーは X（旧 Twitter）の投稿 • 自転車交通反則通告制度（青切符） ◦ 2026年4月1日施行 / 道路交通法（令和6年法律第34号） ◦ 16歳以上の自転車運転者、違反113種類、反則金 3,000〜12,000 円 • 制度自体が新しいので、LLMの学習データ反映が薄い ◦ ただし「学習データを増やせば直る」話ではない、というのが今日の主張 きっかけ — Xで見た投稿 4 / 42 Copyright © 3-shake, Inc. All Rights Reserved.
5. • 仮説：確率論的な処理にすべてを任せてい るから • 「絶対に揺らいではいけない情報」は決定 論的に引き当てて根拠として渡す ◦ 条文番号、反則金額など正解が1つしかな い情報 • 用語整理 ◦ 確率論（probabilistic）= LLM。同じ入力で も出力が揺らぐ ◦ 決定論（deterministic）= TF-IDF などの古 典NLP。同じ入力には必ず同じ出力 • 法律以外でも、薬の用量、契約金額、製品 仕様書などに転用可能 仮説 — なぜ生成AIは法規を間違えるのか 5 / 42 Copyright © 3-shake, Inc. All Rights Reserved. 正解の性質で扱いを分ける 古典NLP (TF-IDF など) 同じ入力 → 必ず同じ出力 ここで扱う情報 • 条文番号 • 反則金額 • 製品仕様 生成AI (LLM) 同じ入力でも出力が揺らぐ ここで扱う情報 • 文脈解釈 • 自然な表現 • 推論の合成 決定論 / Deterministic 確率論 / Probabilistic 法律以外も応用可：薬の用量・契約金額・製品仕様書
6. • ① 階層無視：原則→例外→例外の例外を平坦化 ◦ 例：歩道通行の例外規定を見落とす • ② 数値捏造：条文にない反則金額を補完 ◦ 例：存在しない「3,000円」を回答／条文番号の細部を作話 • ③ 参照欠落：「政令で定める者」を解決できない ◦ 例：70歳以上の歩道通行許可を無視 ◦ Flash / Pro / Sonnet / Opus / Gemma3:4b でも同じ系統で出る 生成AIが陥りがちな3つの失敗パターン 6 / 42 Copyright © 3-shake, Inc. All Rights Reserved.
7. • O'Reilly『実践自然言語処理』(Vajjala 他、邦訳 2022) 第2〜3章準拠 • LLM時代でも古典NLPは「前処理／検索／特徴抽出」で現役 ◦ RAGの前処理でトークナイズ／BoW／TF-IDF／cos類似度は今でも必須 • 本プロジェクトのLayer 1がまさにその位置づけ ◦ 知っている人は復習として、初耳の人はインデックスとして使ってほしい NLPミニ入門 — なぜここから話すか Copyright © 3-shake, Inc. All Rights Reserved. 7 / 42
8. • NLPは単一の手法ではなく、一連の処理の流れ（書籍 第2章） • 標準的なNLPパイプライン ◦ データ収集 → テキスト抽出／クリーニング ◦ 前処理（トークン化・正規化・ストップワード除去） ◦ 特徴エンジニアリング（BoW / TF-IDF / 埋め込み） ◦ モデリング → 評価 → デプロイ • 本プロジェクトの位置づけ ◦ Layer 1 = 前処理〜特徴エンジニアリング、Layer 2（LLM）= モデリング ◦ LLMが最初に来るのではなく、特徴抽出を済ませた状態で来る NLPパイプラインの全体像 Copyright © 3-shake, Inc. All Rights Reserved. 8 / 42 標準的な NLP パイプライン データ収集 テキスト抽出 クリーニング 前処理 トークン化 正規化 特徴量化 BoW / TF-IDF 埋め込み モデリング 推論・分類 評価 / デプロイ 精度検証 リリース Layer 1（古典NLP・決定論） Layer 2（生成AI・確率論）
9. • One-hot：語彙|V|次元、該当語だけ1 ◦ 欠点：類似度がとれない／次元爆発 • Bag of Words / Bag of N-grams：単語の出現回数 ◦ 欠点：語順を捨てる／次元増 • TF-IDF：一般的でない語に重み（本プロジェクト採用） ◦ 法令ドメインは語彙が限定的、決定論で十分、デバッグもしやすい • 分散表現（Word2vec、Sentence-BERT 等）：文脈で意味を捉える ◦ RAGで広く使われるのはこの系統。学習データ要 テキスト表現の系譜 Copyright © 3-shake, Inc. All Rights Reserved. 9 / 42 テキスト表現の進化と本プロジェクトでの選択 One-hot 次元爆発 Bag of Words 語順喪失 TF-IDF 本採用 分散表現 Word2vec Sentence-BERT RAGで主流
10. TF(t, d) = (単語tの出現回数) ÷ (文書dの総単語数) IDF(t) = log( 総文書数 ÷ 単語tを含む文書数 ) TFIDF(t, d) = TF(t, d) × IDF(t) • TF = 文書内での頻度／IDF = コーパス全体でのレア度 • 両方を掛けることで「よく出るが、コーパスではめずらしい」語にスコアが 集中 ◦ 「は」「を」のような一般語は IDF が小さくなり自動的に薄まる ◦ ストップワード除去を別途しなくてもいい、というのが TF-IDF の良いところ TF-IDFの定義（書籍 3.2 の公式） Copyright © 3-shake, Inc. All Rights Reserved. 10 / 42 数式
11. cos(a, b) = (a · b) ÷ ( ||a|| × ||b|| ) 値域：-1〜1（TF-IDFは非負なので 0〜1） • ベクトル間の角度で類似度を測る ◦ ベクトルの長さではなく向きで比較するので、文書の長さが違ってもOK • 本プロジェクトでは「クエリ」と「各条文」をTF-IDF化し、最も角度が近い 条文を正解候補とする ◦ 卒論ではレポート盗作検出に使用。今回は条文検索に流用 コサイン類似度 Copyright © 3-shake, Inc. All Rights Reserved. 11 / 42 数式
12. • ユーザクエリ → Layer 1（決定論）→ Layer 2（確率論）の二層構成 • Layer 1：古典NLP（決定論） ◦ Legal Compiler：e-Gov XML → 条文 AST + 論理フラグ抽出 ◦ VSM Engine：TF-IDF + cos 類似度で条文 アドレス特定 • Layer 2：生成AI（確率論） ◦ 条文 AST + 反則金 + 解決済み委任規定を 「絶対的根拠」として注入 ◦ 推論の脱走を物理的に封じて判定 • 重要：Layer 1 が天井になる。穴を開ける とLayer 2のモデル力では埋め切れない システム全体アーキテクチャ Copyright © 3-shake, Inc. All Rights Reserved. 12 / 42 ユーザクエリ Legal Compiler XML→AST +論理フラグ抽出 VSM Engine TF-IDF + cos 条文アドレス特定 条文AST + 反則金 + 委任規定 を「絶対的根拠」として注入 生成AI（LLM） 推論の脱走を物理的に封じて判定 Layer 1 · 決定論 Layer 2 · 確率論
13. gemini-law-compiler/ ├── data/ road_traffic_act_full.xml, bicycle_fine_table.json ├── src/ │ ├── parser/legal_compiler.py Layer 1-a: XML → 条文AST │ ├── matcher/vsm_engine.py Layer 1-b: TF-IDF + cos類似度 │ ├── llm/{ollama,anthropic}_client.py LLMアダプタ │ ├── benchmark/flash_only_judge.py LLM単体テスト │ └── judgement/hybrid_judge.py Layer 2: ハイブリッド判定 └── results/ 実行ログ（5機種ぶん） • コード本体は約 600 行。標準ライブラリ（xml.etree, re, math, collections）のみでLayer 1 を構成 • モデル切替は --model フラグだけ ディレクトリ構成 Copyright © 3-shake, Inc. All Rights Reserved. 13 / 42 Directory
14. • ファイル：src/parser/legal_compiler.py • 役割：e-Gov 法令 XML を AST（抽象構文木）に変換 ◦ 全 575 条 → 自転車関連 76 条にフィルタ ◦ 各 <Sentence> から「論理フラグ」を正規表現で抽出 • ポイント：論理フラグ ◦ e-Gov のXMLをそのまま LLM に投げると冗長すぎるので、必要な情報だけを構造化 ◦ 次のスライドで詳しく Layer 1-a：Legal Compiler — 何をするか Copyright © 3-shake, Inc. All Rights Reserved. 14 / 42
15. LOGIC_PATTERNS = { "exception": re.compile(r"を除[くき]"), "proviso": re.compile(r"ただし[、,]"), "delegation": re.compile(r"政令で定める"), "notwithstanding":re.compile(r"にかかわらず"), "obligation": re.compile(r"しなければならない"), "prohibition": re.compile(r"してはならない"), "permission": re.compile(r"することができる"), ... } • delegation が立てば → 後段で解決済み情報を注入する必要があるとわかる • exception / proviso が立てば → LLMが階層を潰しやすいケースなのでプロンプトで強調 • 機械学習でなく正規表現で十分。語彙が限定されたドメインの恩恵 論理フラグの抽出 — ここが本プロジェクトの肝 Copyright © 3-shake, Inc. All Rights Reserved. 15 / 42 Python
16. @dataclass class SentenceNode: text: str function: str # "main" or "proviso" logic_flags: list[str] # 「ただし」「を除く」検出結果 @dataclass class ArticleNode: num: str caption: str # （普通自転車の歩道通行） title: str # 第六十三条の四 paragraphs: list[ParagraphNode] • 型付き dataclass で AST を構築。後段は AST だけ参照すれば済む • 「XMLを直接いじらない」のは、デバッグ性とテスト容易性のため 生成されたASTの例 Copyright © 3-shake, Inc. All Rights Reserved. 16 / 42 Python
17. def tokenize(text: str) -> list[str]: tokens = [] for chunk in _SPLIT_RE.split(text): # 句読点・括弧で分割 for i in range(len(chunk) - 1): # 文字 bi-gram bigram = chunk[i:i+2] if not _PARTICLE_RE.fullmatch(bigram): tokens.append(bigram) for kw in ["自転車", "歩道", "車道", "通行", ...]: if kw in text: tokens.append(kw) # 法規キーワードをブースト return tokens • 今回はあえて 形態素解析エンジン MeCab を使わず文字 bi-gram に切り替えている • MeCab をあえて外した理由 (4 つ) – 依存を最小化 — Python 標準ライブラリだけで Layer 1 を完結 – Apple Silicon の MeCab/IPADIC ビルドハマりを回避 – デバッグ容易性 — 形態素解析器のブラックボックス (辞書・未知語・コスト) を挟まずトークン列が追跡可能 – 法令ドメインは語彙が限定的 — 辞書注入＋文字 bi-gram で十分、形態素解析を入れる ROI が薄い Layer 1-b：VSM Engine — トークナイザ Copyright © 3-shake, Inc. All Rights Reserved. 17 / 42 Python
18. self._doc_tokens = [tokenize(flatten_article_text(a)) for a in self._articles] df = Counter() for tokens in self._doc_tokens: for t in set(tokens): df[t] += 1 n = len(self._articles) self._idf = {t: math.log(n / freq) + 1.0 # smoothed IDF for t, freq in df.items()} # 各文書の TF-IDF を dict (sparse) で保持 • scikit-learn を使わず math と Counter だけで実装 • ベクトルは dict で持つ（スパース表現）。語彙数が増えても問題ない • 「全部追跡可能」「全部読める」のが古典 NLP の良さ TF-IDFインデックス構築（素朴な実装） Copyright © 3-shake, Inc. All Rights Reserved. 18 / 42 Python
19. def search(self, query: str, top_k: int = 5): q_tokens = tokenize(query) q_tf = Counter(q_tokens) q_tfidf = {t: (c/len(q_tokens)) * self._idf.get(t, 1.0) for t, c in q_tf.items()} scores = [(i, self._cosine_similarity(q_tfidf, doc_vec)) for i, doc_vec in enumerate(self._doc_tfidf)] scores.sort(key=lambda x: x[1], reverse=True) return scores[:top_k] # → Layer 2 へ渡す • 共通キーだけで内積を計算する最適化（スパースベクトル） • クエリ側も同じトークナイザ・同じ IDF を使う対称性が重要 コサイン類似度の検索 Copyright © 3-shake, Inc. All Rights Reserved. 19 / 42 Python
20. クエリ「75歳の高齢者が歩道を自転車で走行した」 #1 cos=0.3022 → 第六十三条の四（普通自転車の歩道通行） ← 正解 #2 cos=0.2739 → 第十七条の二 #3 cos=0.1958 → 第六十三条の三 クエリ「自転車で赤信号を無視して交差点に進入しました」 #1 cos=0.2801 → 第七条（信号機の信号等に従う義務） ← 正解 #2 cos=0.2269 → 第六十三条の七 • 成功例では1位に正解条文が来る • 決定論なので毎回同じ結果。Layer 2のプロンプトに「絶対的根拠」として注入される 実際の検索結果 — 成功例 Copyright © 3-shake, Inc. All Rights Reserved. 20 / 42 Output
21. def judge(self, query: str) -> HybridResult: # Layer 1 vsm_matches = self._vsm.search(query, top_k=3) combined_text = 上位3条文を連結 unique_flags = 検出された論理フラグ fine_info = self._lookup_fine(query, primary.article) # Layer 2 prompt = self._build_prompt(query, combined_text, fine_info, unique_flags) response = self._client.models.generate_content( model=self._model, contents=prompt, config={"system_instruction": HYBRID_SYSTEM_PROMPT, "temperature": 0.0}) • Layer 1 の結果を「条文 + 反則金 + 論理フラグ」としてプロンプトに詰めて投げる • LLM は判定（合法／違反）と理由文だけを生成すればよい • Gemini／Gemma／Claude で同一インタフェース Layer 2 — ハイブリッド判定エンジン Copyright © 3-shake, Inc. All Rights Reserved. 21 / 42 Python
22. 【重要】以下に提示する「条文データ」と「反則金データ」は、e-Gov 法令API から取得した公式の法令データを決定論的にパースした結果です。 この情報を絶対的な根拠として使用し、あなた自身の学習データからの補完は 一切行わないでください。 条文データに記載されていない金額や条文を回答に含めてはいけません。 • LLMの学習データを使わせない、というのが効く • 委任規定（delegationフラグ）は施行令第26条の中身を別ブロックで注入 • 反則金テーブル（手製JSON）も同様に注入 ハイブリッド用 System Prompt の核 Copyright © 3-shake, Inc. All Rights Reserved. 22 / 42 Prompt
23. • TC-001：75歳が普通自転車で歩道走行 → 合法（施行令で70歳以上OK） • TC-002：30歳が標識のない歩道走行 → 違反（やむを得ない例外あり） • TC-003：自転車でスマホを手に持って運転 → 違反、12,000円 • TC-004：10歳児童が歩道走行 → 合法（政令で児童OK） • TC-005：自転車で酒気帯び運転 → 反則金対象外（刑事罰） • TC-006：歩道徐行違反 → 違反、3,000円 • TC-007：信号無視 → 違反、6,000円 • 5機種 ×（単体／ハイブリッド）= 10通りで実行 ◦ 階層判断・委任規定・数値・対象外まで含めた構成 ベンチマーク 7ケース Copyright © 3-shake, Inc. All Rights Reserved. 23 / 42
24. • Gemini 3 Flash：5/7（71%）／ 7〜9秒／階層平坦化、条 番号細部捏造 • Gemini 3.1 Pro：5/7（71%）／ 13〜22秒／Flashと同じ穴 • Claude Sonnet 4.6：5/7（71%）／ 30〜65秒／TC-006で 「5,000円」捏造 • Claude Opus 4.7：5/7（71%）／ 5〜10秒／TC-006で 「6,000円」捏造 • Gemma3:4b（ローカル）：0/7（0%）／ 13〜33秒／条文 ネットワーク自体を作話 • フロンティア4機種は同点 5/7。Gemma3:4b だけ 別格 ◦ 失敗の質は割れる：Geminiは条文細部、Claudeは 金額そのもの ◦ ハルシネーション自動検知は 0/7。「LLMはわから ないとは言わない」 5機種ベンチマーク LLM単体結果 Copyright © 3-shake, Inc. All Rights Reserved. 24 / 42 単体結果（LLM のみ） 正解率（%） Gemini 3 Flash 7-9s 71% Gemini 3.1 Pro 13-22s 71% Claude Sonnet 4.6 30-65s 71% Claude Opus 4.7 5-10s 71% Gemma3:4b (Local) — 0%
25. • フロンティア4機種：単体でも5/7。モデルを上げても直らない2ケースがあ る ◦ 直らないケース：TC-002（階層）／TC-005 or TC-006（数値捏造） • 失敗ケースが完全に同じ場所に集中している ◦ = モデルクラスを変えても同じ穴 • 自動チェッカーは「条文番号一致」しか見ない ◦ 金額捏造は ✓判定で見逃される • 「モデル力ではなく、アーキテクチャで詰めるべき」が今日の主張の根拠 単体結果の重要メッセージ Copyright © 3-shake, Inc. All Rights Reserved. 25 / 42
26. • Gemini 3 Flash：完全✓ 5/7、本質的✗ 1（TC-003 合 法と誤判定）／合計 629秒 • Gemini 3.1 Pro：完全✓ 5/7、本質的✗ 1（TC-003 合 法と誤判定）／合計 147秒 • Claude Sonnet 4.6：完全✓ 5/7、本質的✗ 0（TC-003 「判定不能」）／合計 226秒 • Claude Opus 4.7：完全✓ 5/7、本質的✗ 0（TC-003 「該当条文なし」）／合計 54秒 • Gemma3:4b：完全✓ 3/7、本質的✗ 4／合計 249秒 • フロンティア4機種は同点 5/7。Layer 1 が天 井になっているのが見える ◦ TC-003で何が起きたかが割れる。これが今日 のクライマックス ◦ Opus 4.7 は54秒で完走、Sonnetの4倍速。 adaptive thinking が効いている 5機種ベンチマーク ハイブリッド結果 Copyright © 3-shake, Inc. All Rights Reserved. 26 / 42 ハイブリッド結果（Layer 1 + LLM） 正解率（%）と「失敗の質」 Gemini 3 Flash 629s 71% Gemini 3.1 Pro 147s 71% Claude Sonnet 4.6 226s 71% Claude Opus 4.7 54s 71% Gemma3:4b (Local) — 43% honest gap（許容） False Negative（致命）
27. クエリ「自転車でスマホを手に持って運転」 期待：第71条第5号の5、反則金 12,000円 Layer 1 出力（TF-IDF）： #1 cos=0.1421 → 第六十三条の九（自転車の制動装置等） #2 cos=0.1135 → 第六十三条の十（自転車の検査等） #3 cos=0.1126 → 第六十三条の三（自転車道の通行区分） → 第71条第5号の5は引けず、Layer 2 へ • Layer 1 が口語「スマホ」と条文文体「無線通信のために用いられる装置」の語彙ギャップ に敗北 • TF-IDFは単語一致の世界。意味的類似性は捉えられない（書籍3.2の弱点） • 「該当する反則金情報なし」の状態で Layer 2 に渡る → 4機種で挙動が割れる TC-003「ながらスマホ」をどう外したか Copyright © 3-shake, Inc. All Rights Reserved. 27 / 42 Output
28. { "judgement": "合法", "article": "該当なし", "fine": "対象外（提供された条文データに禁止規定がないため）", "reasoning": "提供された条文データには自転車運転中にスマホを 手に持つ行為を禁止する規定が含まれていません。…提示された条文の 範囲内では違反とは判定されません。" } • 論理は一貫：「禁止規定がない → 違反ではない → 合法」 • しかし法規制用途では最悪のFalse Negative ◦ 実際は違反である行為について「合法ですよ」と返している ◦ ユーザは「合法だ」と信じて違反行為に進む可能性がある Gemini Flash の TC-003 回答 Copyright © 3-shake, Inc. All Rights Reserved. 28 / 42 JSON
29. { "judgement": "合法", "article": "該当条文なし", "fine": "該当する反則金情報なし", "reasoning": "提供された情報の範囲内では違反を問う根拠がなく、 反則金についても該当する情報がありません。" } • Proでも結論は「合法」 ◦ 言い回しは慎重「提供された情報の範囲内では」と限定するが、最終判定は同じ • 「Proに上げれば判定が変わる」は成立しなかった Gemini Pro の TC-003 回答 Copyright © 3-shake, Inc. All Rights Reserved. 29 / 42 JSON
30. { "judgement": "判定不能", "article": "該当条文が提供データに含まれていない", "reasoning": "…スマートフォンを手に持ちながら運転する行為を直接 規制する条文は提供データに含まれていません。…提供データ外の条文・ 金額を補完することは指示により禁止されているため、本質問に対して 根拠ある判定を行うことができません。正確な回答のためには、携帯電話 使用等に関する条文（一般的には道路交通法第71条等）のデータを含めた 再照会が必要です。" } • スキーマには 合法 | 違反 しか書いていないのに「判定不能」と返してきた • 「一般的には道路交通法第71条等のデータを含めた再照会が必要」とLayer 1の取り逃しを 名指し • Anthropic系の傾向：スキーマに合わせるよりも、回答できないことを正直に報告する方を 優先 Claude Sonnet 4.6 の TC-003 回答 Copyright © 3-shake, Inc. All Rights Reserved. 30 / 42 JSON
31. { "judgement": "違反", "article": "提供された条文データには、自転車運転中の携帯電話 使用を直接規律する条文は含まれていません。", "fine": "提供された反則金データに該当情報なし" } • Opusはスキーマを保ちつつ「違反」と判定 ◦ articleフィールドで「条文が提供されていない」と説明 • 判定方向は正しい（実際違反）+ 根拠の不足は正直に書く、というハイブリ ッド対応 ◦ Sonnetと挙動が微妙に違うが、どちらも「沈黙する Claude」のカテゴリ Claude Opus 4.7 の TC-003 回答 Copyright © 3-shake, Inc. All Rights Reserved. 31 / 42 JSON
32. • Gemini 3 Flash → 合法（False Negative：実は違反なのに「合法」） • Gemini 3.1 Pro → 合法（同上） • Claude Sonnet 4.6 → 判定不能（スキーマ破棄して降参、Layer 1の穴を指摘） • Claude Opus 4.7 → 違反（根拠不足を併記。判定方向は正しい） • 数字（5/7）は同じだが、ユーザへの影響は決定的に違う ◦ Gemini：「合法」と返すのでユーザは違反行為に進みかねない ◦ Claude：「データに無い、判定不能」とユーザが別の言い方で聞き直せる • 法務・コンプライアンス用途では、安全側に倒れるClaudeのほうが望ましい ◦ ベンチマークの数字には出ない、質的な差 4機種の「失敗の質」を並べる Copyright © 3-shake, Inc. All Rights Reserved. 32 / 42
33. • ハイブリッド合計時間：Sonnet 226秒 vs Opus 54秒 ◦ TC-001単独時間：Sonnet 61秒 vs Opus 9秒 ◦ 単体ベンチ合計：Sonnet 230〜260秒 vs Opus 50〜60秒 • ハイブリッド構成下では判定そのものは Sonnet と Opus で完全に同一 ◦ 差はレイテンシのみ。Opus 4.7 は4倍速で完走 • 理由：adaptive thinking が「資料は揃っているので考える余地は少ない、整 形だけする」と判断 ◦ 「より高性能なモデルのほうが速く終わる」直感に反する結果 ◦ ただしLayer 1を外した複雑推論なら Sonnet と Opus の差は逆転しうる Sonnet vs Opus の差はどこに出たか Copyright © 3-shake, Inc. All Rights Reserved. 33 / 42
34. • TC-004「10歳児童が歩道走行」（期待：合法） • Layer 1注入：施行令第26条 → 「児童（6〜13歳）は歩道通行 OK」 Gemma3:4b 回答： { "judgement": "違反", "reasoning": "歩道を通行できると規定しており、政令で定める者 （この場合は10歳の児童）であるため、歩道を走行していることは違反 となります。" } • 注入された情報の要約は正しい（歩道通行できる） • ところが結論を逆向きに倒す（だから違反） ◦ 命題論理レベルで「である場合 ⇒ 違反」と接続してしまう • モデル容量がしきい値を切ると、ハイブリッド構成の前提が崩れる ローカルLLM（Gemma3:4b）の壁 Copyright © 3-shake, Inc. All Rights Reserved. 34 / 42 JSON
35. def get_llm_client(model: str): if is_ollama_model(model): from src.llm.ollama_client import OllamaClient return OllamaClient(OLLAMA_HOST) if is_anthropic_model(model): from src.llm.anthropic_client import AnthropicClient return AnthropicClient( project_id=VERTEX_PROJECT, region=VERTEX_LOCATION) return get_genai_client() # Gemini (Vertex AI) • 3つのLLMクライアントを client.models.generate_content() という同一インタフェースに統 一 • Anthropic は Vertex AI 経由（既存のADCをそのまま流用、課金もGCPに集約） • ベンチマークコードはLLMクライアントの違いを意識しない • モデル切替は --model claude のフラグだけ モデル切替の実装 — get_llm_client() Copyright © 3-shake, Inc. All Rights Reserved. 35 / 42 Python
36. • Flash：5/7 → 5/7（細部捏造は消えるが、TC-002階層 / TC-003 False Negativeが残る） • Pro：5/7 → 5/7（同上） • Sonnet：5/7 → 5/7（金額捏造は消える、TC-003 は honest gap） • Opus：5/7 → 5/7（金額捏造・別表参照は消える、TC-003 は honest gap） • Gemma3:4b：0/7 → 3/7（注入を逆向きに解釈する致命的な誤りが残る） • 決定論的NLPで根拠を限定して注入すると、フロンティア4機種では数値捏 造が物理的に封じられる ◦ ただしTF-IDFが穴を開けた瞬間（TC-003）、ベンダーで挙動が割れる ◦ Gemma3:4bは別の設計が必要（Layer 1で判定まで決定論化、説明文だけLLM） 各モデルを通じて見えた「Layer 1 が天井」 Copyright © 3-shake, Inc. All Rights Reserved. 36 / 42
37. • 1. 確定情報は決定論で固定。LLMに確率 分布から拾わせない • 2. 入力ごとに delegation / exception など の論理フラグを立て、プロンプトで強調 • 3. 自動評価は judgement + article + fine の三軸で ◦ 条文番号一致だけだと金額捏造を見逃 す • 4. 「降参できるLLM」を Layer 2 に置く ◦ Layer 1 が穴を開けたとき、False Negative より honest gap のほうが安 全 • 5. ローカル小型モデルでは Layer 1 にも っと仕事を持たせる ◦ 判定まで決定論化、説明文だけLLM 設計指針 5つ Copyright © 3-shake, Inc. All Rights Reserved. 37 / 42 1 決定論で確定情報を固定 LLMに確率分布から拾わせない 2 論理フラグを抽出 delegation / exception を入力ごとに 3 三軸で自動評価 judgement + article + fine。番号一致だけだと金額捏造を見逃す 4 降参できるLLMを選ぶ Layer 1 が穴を開けたら判定不能と言える 5 穴は埋めずに塞ぐ Layer 1 を改善する。モデル力で埋めない
38. • 7ケースで「同じ 5/7」は統計的に誤差範囲 • 機種差が消失したわけではなく、現テストセットでは見えていないだけ • 本来見えるはずなのに今回見えていない差： ◦ 条文ネットワークが多段に絡む特別法（破産法・会社法等） ◦ 但書のネスト3段以上 ◦ 数値計算（期日計算、過失割合） ◦ 制度変更時期と knowledge cutoff の干渉 ◦ 多言語・固有名詞混在クエリ • 次の宿題：ケース数を数十〜100に増やしてカテゴリ別に集計 重要な留保 — 7ケースでは差を出し切れない Copyright © 3-shake, Inc. All Rights Reserved. 38 / 42
39. • どのフロンティアLLMを選んでも、単体での法規判定は 5/7（71%）で並ぶ • どのフロンティアLLMでも、決定論的NLPを前段に挟めば数値捏造は消える • Layer 1 が穴を開けたときの挙動はベンダーで割れる： ◦ Gemini = False Negative ◦ Claude = honest gap acknowledgment • Layer 1 を改善するインセンティブは、ベンダー選択を超えて支配的 • Layer 1 が完璧でない以上、Layer 2 は「降参できるモデル」のほうが安全。 シリーズを通じての結論 Copyright © 3-shake, Inc. All Rights Reserved. 39 / 42
40. • 次の課題1：テストケース拡張 ◦ 数十〜100ケースに、条文リンク段数 / 但書ネスト深度 / 数値計算 / 制度変更時期で 散らす • 次の課題2：Layer 1 の TF-IDF を意味埋め込み化 ◦ Sentence-BERT / multilingual-e5 等で TC-003 の語彙ギャップを救う • リポジトリ：gemini-law-compiler ◦ https://github.com/shu-kob/gemini-law-compiler • 参考：O'Reilly『実践 自然言語処理』(Vajjala 他、邦訳 2022) • ご清聴ありがとうございました。 次の課題 Copyright © 3-shake, Inc. All Rights Reserved. 40 / 42