生成AIって、なんで「ロジカルな話」で間違えるんだろう？〜誤答をちょっと分解して、AIとの付き合い方を考えてみる

📚 論理ソルバーMCP 連載（全3回） ① 全体像：会計チェックを「毎回ブレない仕組み」に　／　② なぜ論理ソルバーか：生成AIはなぜ「ロジカルな話」で間違えるのか　／　③ 品質を守る：「暴走するAI」をどう手なずけるか （この記事は ②）

きっかけ

生成AIに業務のことを聞いて、もっともらしい嘘を返されたこと、ありませんか？ 僕はあります。しかも、けっこう頻繁に。

不思議なのは、ふわっとした相談（「この企画、どう思う？」みたいなやつ）だと割と満足できるのに、「誰がやっても同じ答えになるはずの作業」を頼むと、平気で外してくる、という点です。

雑談で答えがブレるのは別にいいんです。人間だってブレますし。 でも「順を追って考えれば必ず同じ結論にたどり着く話」── つまりロジカルな推論でブレられると、ちょっと信用しづらくなる。

「これって、なんでだろう？」というのを、今日は一緒に考えてみたいなと思います。 会計士・税理士・経理担当・エンジニア・AIに関心のある方、いずれにも届く内容を目指して、技術用語はできるだけかみ砕いて書いてみました。 後半では、freee と連携した具体的な動作例（論理ソルバーMCP）も登場します。

「ロジカルな推論」って、そんなに使ってます？

「ロジカルな推論」と言うと、なんだか数学の証明みたいな話を想像してしまって、「いやいや、私の仕事って、そんなお堅い話と関係なくない？」って思いますよね。僕も最初そう思いました。 でも、ちょっと棚卸ししてみると、業務の中の「ロジカルな推論」って、けっこう多いんです。

たとえば、

• 経費精算、これ通していいやつ？って判断する
• 契約条件を見て、適用される値引きを計算する
• 在庫と発注リードタイムから、欠品しそうかどうか見極める
• 法令の要件を、自社のケースに当てはめてみる

このあたり、ざっくり言うと「ルールを当てはめて結論を出す」作業ですよね。 言い換えると、人によって答えが変わったら困るタイプの仕事です。

もちろん、すべてのケースがきれいにルールで決まるわけではありません。 判例の解釈が割れる契約条項とか、規定の趣旨にまで踏み込まないと判断できない経費とか、最後は人の判断が要る場面は残ります。 ただ、実務の感覚としては 大部分のケースは形式的に決まる。残った少数の例外をどう扱うか、というのが本当の論点で、まずは「形式的に決まる側」をちゃんと処理できることが前提になります。

例えるなら、受験数学の「計算問題」

ちょっと話が飛ぶんですが、受験数学に「計算問題」っていうジャンル、ありますよね。 あれって、本当は存在しないんじゃないか、と僕は思っているんです。

「2x + 3 = 7 を解け」って、要するに「x = 2 が成り立つことを証明せよ」と同じ意味じゃないですか。 つまり計算問題も、本質的には証明問題なんです。

ただ、毎回ちゃんと証明過程を書かせると、受験で測りたい能力（速く、正確に処理する力）と難易度がズレちゃう。 だから「途中の証明は省略していいよ。結果だけ合ってればOK」というルールにしている。

これ、実は今の生成AIのライトな使い方とそっくりなんですよね。 結果が合えばOK、過程は問わない。 ところが業務だと「結果が合ってるかどうか」を確かめる手段がないことも多くて……だから、誤答が混ざる。

ロジカル推論を「5つのステップ」に分けてみる

ここからが本題です。 ロジカルな仕事を、数学で「定理を証明していく手順」の考え方を借りて、ちょっと分解してみます。

[▲ ロジカル推論の5ステップ]

業務シーンに置き換えると、こんな感じです。

ステップ	業務でいうと
① 自然文の依頼	「この経費、通る？」って聞かれる
② 命題を作る	「Aさんの3月分の交際費5万円は経費規定に適合する」を示せばいいんだな、と整理する
③ 証明を作る	規定の条文を引いて、当てはめの道筋を組み立てる
④ 証明を検証	道筋に飛躍や見落としがないかチェック
⑤ 計算（簡約）	判定の計算として、承認処理／否認通知を出す

こうやって分けると、何がうれしいか。 AIがどこでつまずいているのか、ピンポイントで見えるようになるんです。

それともう一つ、地味だけど大事なポイントが。 一回検証が通った証明は「定理」としてライブラリに保存しておけて、次からはそれを呼び出すだけで済む。 人間でいうと、「業務マニュアル」とか「過去の判断事例集」を作っていくのに近いです。

昔の大工でも、まったく同じことをやっていた ── ピタゴラスの例

経費精算だけだと「業務の話だよね」で終わってしまいそうなので、もう一例。 まったく違う分野でも、この5ステップがそのまま動いている、というのを見せたいんです。 題材はピタゴラスの定理── 昔の大工さんが、家の屋根に届く梯子を作る場面で並べてみます。 梯子は切ってから長くできないので、切る前に正確な長さを知っておく必要がある ── これが具体的な実務動機です。

（……いや、現場の大工さんなら定理なんて持ち出さず、巻尺（メジャー）でサッと測るやろ、というツッコミはごもっともです。ここはあくまで「同じ5ステップが、分野をまたいでそのまま動く」を見せるための例え話、ということでひとつ。）

状況はこんな感じ。先祖代々の古い家、屋根の瓦が一枚はがれてしまった。雨漏りする前になんとか直したい。 ところが、家の周りには昔からの堀があって、壁にぴったり梯子をつけられない。堀のへりから立てると、どうしても壁から 3 m 離れたところに梯子の足元が来てしまう。修理したい瓦は、地面から 4 m の高さ。

求めたいのは、梯子そのものの長さ（＝壁と地面が作る直角三角形の斜辺）。

ステップ	昔の大工さん
① 自然文の依頼	「先祖代々の家の屋根、瓦が一枚はがれちまってな。直したいんだが、堀があるから壁から 3 m 離してしか梯子を立てられねえ。瓦は地面から 4 m の高さだ。梯子は何 m で切ればいい？」
② 命題を作る	「足元 a・高さ b の直角三角形で、斜辺 c は c² = a² + b² を満たす」と整理する
③ 証明を作る	ピタゴラスの定理を、いくつかの補題（正方形の分割、相似三角形の性質 …）を組み合わせて導く
④ 証明を検証	その式が同義反復じゃないか？「直角」という条件は本当に必要か？ 別経路の証明（ユークリッド流、相似流 …）と突き合わせて穴がないか確認
⑤ 計算（簡約）	a=3, b=4 を代入。c² = 9 + 16 = 25、よって c = 5 m。「梯子を 5 m で切れ」と職人に伝える

そして類題が来たとき ── たとえば次の現場で、もっと高い家（a=5, b=12）の梯子を頼まれたら？

• ピタゴラスの定理は証明済みの定理として、もう呼び出すだけで OK。c = 13 m がすぐ出る
• さらに、ピタゴラスの定理を導くために使った補題（正方形の分割、相似三角形 …）も、別の定理（余弦定理、三角形の面積公式 …）の証明にそのまま再利用できる

昔の大工や数学者の頭の中にあった「定理ライブラリ」は、こうやって少しずつ太っていきました。 経費精算で起きていることと、構造はまったく同じなんですよね。やっている人間と分野が違うだけ。

生成AIだけに任せると、どこで転ぶ？

純粋な LLM（生成AI）って、この5ステップをぜんぶ「文章生成」だけで済ませているんですよね。 それっぽい命題を書いて、それっぽい証明を書いて、それっぽい結論を書く。

検証は特に、構造的に苦手なんです。 だって検証って「ルールに照らして1ステップずつ確認する」作業じゃないですか。 LLM の得意な「もっともらしい次の単語を予測する」とは、ちょっと毛色が違う。

[▲ 純LLM：検証（赤）が実質スキップされる]

赤くしたところが、実質スキップされている検証です。 ここを通っていないので、誤答がそのまま外に出ちゃう、というわけですね。

3つのやり方を並べてみる

じゃあ、どう直したらいいのか。 ここでは**代表的な2つの手法（LLM単独、素朴なRAG+LLM）**と、**僕からの提案（論理ソルバー+LLM）**を、3つ横並びで見てみます。

[▲ 3手法の役割分担（推論ステップ × 手法）]

① LLM単独

• 得意：ふわっとした質問にも、それっぽく答えてくれる
• 苦手：検証ができないので、誤答が混ざりがち
• 使いどころ：雑談、アイデア出し、下書き

② RAG（過去事例検索）＋ LLM

過去の似た判断とか文書を検索して、それを LLM の参考資料にする方式です。ここで比べるのは、いちばん素朴な形 ── 「似た文書」をベクトル検索で上位いくつか引いて、そのまま渡すだけのRAGを想定します。

• 得意：前例が多い領域での精度アップ
• 苦手：検索でヒットした「定理もどき」って、けっこう曖昧で。結局 LLM の判断に委ねるところが残る
• 位置づけ：計算ステップでの入力の補強にとどまる感じ

⚠️ 念のため。RAG にも、再ランキング・クエリ分解・反復検索・GraphRAG・エージェント的な検索…と、精度を大きく引き上げる高度な手法がいろいろあります。このあと「RAG はここが弱い」という話をしますが、それは**“素朴な形に限った”話**で、RAG という枠組み全体を否定するものではありません。

③ 論理ソルバー ＋ LLM ── ここからは僕の提案です

まず、用語をひとつだけ。「論理ソルバー」っていうのは、ルールに照らして合うかどうかを機械的に判定するエンジンのことです。エンジニア向けに言うと、いわゆる FOL（一階述語論理）ソルバーのことなんですが、本記事では「論理ソルバー」で統一します。

• LLM にはざっくりした証明の骨格だけ作ってもらう
• ソルバーが、詳細を詰める・検証する・実務に落とす・定理を再利用する、を全部担当
• 得意：網羅性、繰り返しの精度、トークン節約
• 苦手：論理ソルバーで扱えない種類の問い（程度・確率・時間順序・あいまい述語など）

LLM単独 と RAG+LLM、何が不安定なんだろう？

このあと出てくる比較表で、LLM単独 と RAG+LLM は「網羅性」「繰り返しの精度」のところが △ や × になります。 なんでそうなるのか、ちょっとだけ深掘りさせてください。 ここがピンとくると、論理ソルバー方式の良さも腹落ちしやすくなるはずです。

理由は、ざっくり二つあります。

検証ステップ自体が「文章生成」になっちゃう問題

LLM単独 も RAG+LLM も、「証明っぽい文」を作っているのは LLM です。 LLM の生成って、本質は「次の単語の確率分布から、それっぽいやつを引く」作業なので、同じ問いを2回投げると、微妙に違う筋書きの答えが返ってくることがあります。

検証ステップがあれば「あ、この道筋は穴があるな」と弾けるんですけど、その検証ステップ自体もまた文章生成。 結局、入口から出口まで、ぜんぶ確率の上に乗っかっているわけです。 だから繰り返しの精度って、原理的にどうしてもブレちゃう。

「だったら別の AI エージェントに検証させればいいじゃん」── そう思いますよね。 僕もそう思っていた時期がありました。コードレビューを別の AI に任せる、みたいな分業は実際よく試されています。

ただ、別の AI を立てたところで、結局それも確率の上での検算なんですよね。 実際に運用してみると、こんな癖がポロポロ出てきます。

• 毎回、指摘内容が変わる。しかも、それぞれは「言われてみればそうかも」と思える絶妙な線で返ってくるので、無視しづらい
• 網羅性の保証がない。今回拾われた論点が次回も拾われるとは限らないし、本当に大事な見落としが拾われている保証もない
• なぜその指摘なのか、説明可能性がない。「気になりました」「念のため」レベルの根拠しか返ってこないので、棄却すべきかどうかの判断材料が残らない
• 無限に湧いてくる。どこまで直したら終わりなのか、誰にも判断がつかない

プログラミング領域の AI コードレビューでは、この「無限に出る、もっともらしい指摘」問題が、もう実際に顕在化しはじめています。 確率的な検算をいくら重ねても、それは確率の足し算にすぎなくて、「ルールに照らして真／偽」の機械的判定にはどうしても届かない ── これが、AIで検証を補おうとしたときの構造的な天井です。

入力サイドも「偶然のつまみ食い」になっちゃう

不安定さの原因は、もう一つあります。 こっちは検証じゃなく入力サイドの話です。

さっきの素朴なRAG（似た文書を上位だけ引いて渡す形）を思い出してください。 「ちゃんと根拠を引いてる感」があって、僕も最初は「これで安心」って思ってました。 でも、ちょっと立ち止まって考えると、落とし穴があるんです。

検索でヒットしたものを全部渡せるかというと、そうじゃない。 LLM が一度に読める文字量（トークンウィンドウ）に収まる範囲でしか入れられないので、スコアの高い上位だけをつまみ食いするしかない。

本来なら「このルール群を全部当てはめないと結論が出ない」ような問いでも、入りきらなかったルールは、なかったことにされる。 つまり計算ステップに渡す材料の時点で、もう網羅できていない。

（くり返しですが、これは素朴なRAGの弱点です。高度なRAGなら、反復検索や絞り込みで網羅性を上げる工夫はできます。ただ「ルールを漏れなく全部当てる」を保証したいなら、確率的な検索を磨くより、次に話す“機械的にルールを辿る”やり方のほうが素直、というのがこの記事の立場です。）

出口（検証）も入口（材料）も、どちらも確率任せ

ここまでをまとめると、

• 出口の検証は、別 AI を立てても確率の足し算にしかならない
• 入口の材料は、文字量制限のせいで「上位だけのつまみ食い」になって漏れが出る

両端が確率任せなので、網羅性も繰り返しの精度も、安定しようがないんですよね。 このあと出てくる論理ソルバー方式は、この両端を機械的なルール照合と、必要な定理の自動呼び出しに置き換えることで、「偶然」に左右されずに済む構造になっています。

役割分担で誤答を減らす

ここから、僕の提案する論理ソルバー方式がなぜ効くのか、二つの角度から見ていきます。 最初の角度は役割分担── 苦手な仕事を、得意なほうに預ける、という話です。

LLM って、「直感」は得意なんですけど「検算」がちょっと苦手。 ソルバーは逆で、「検算」は得意だけど「直感」はあんまりない。 なので、お互いの苦手を引き受け合うっていう設計になっています。

🔰 用語メモ：ハーネス／足場（harness / scaffolding） … 生のAIモデルそのままでは頼りないので、その周りに「道具・手順・検証・ガードレール」を組み付けて、ちゃんと働く装置に仕立てます。この外側の足場一式を、最近この界隈では ハーネス（harness） とか 足場（scaffolding） と呼びます。ここで紹介している論理ソルバー方式は、“検証”を確率任せのLLMから機械（ソルバー）に移したハーネス、と言い換えられます。

[▲ LLM（直感）×ソルバー（検算）の役割分担]

LLM は翻訳者として光る ── これは GPT の DNA そのもの

論理ソルバーって、便利な反面、ルールの書き方（クエリ言語）が独特っていう昔ながらの弱点があります。 書ける人が書ければ強力なんですけど、業務担当者に「自分でルール書いてください」って渡すと、まあ厳しい。これが「理屈はわかるけど、使う人を選ぶよね」と言われてきた理由でもあります。

ただ、ひとくちに論理ソルバーのクエリ言語と言っても、流派はいくつかあります（Prolog、ASP、SMT、Datalog ……）。 そのなかで、業務用語との距離がいちばん近いのが Datalog だと、僕は思っています。

Datalog って、ざっくり言うと

「主語 ─ 動詞 ─ 目的語（SVO）」 を素直に書ける、論理ソルバー向けのルール言語

なんですよね。さらに、述語を組み合わせれば SVOC（補語あり） みたいな、もう少し情報量の多い文型もカバーできます。 たとえば、

• 「Aさんは経費規定に適合する」（SVO）
• 「上司はAさんの経費を妥当と判定した」（SVOC 寄り）

みたいな、業務担当者の自然な言い回しと、ルールの構造がほぼ一対一で対応する。 SQL みたいに「テーブル結合して、条件で絞って、集計して……」と手続き脳に切り替える必要がない。 業務用語で考えた指示と Datalog の文法の、距離がすごく近いんです。

とはいえ、業務担当者に Datalog を直接書いてもらうのは、それでもまだしんどい。 そこに、プログラマーの知識と業務ドメインの知識を両方もっている LLM が、翻訳者として入ると、空気が変わります。

ちなみにこの「翻訳者」って言い方、ただの比喩じゃないんですよね。 GPT は Generative Pre-trained Transformer の頭文字で、最後の "Transformer" は中身を支える神経網モデルの名前。 このモデル、もともと機械翻訳のために考案されたものなんです（2017年の "Attention Is All You Need" という論文で提案されました）。 つまり「LLM は翻訳が得意」って、後付けの例え話じゃなくて、素性（DNA）そのものの話だったりします。 苦手な検証はソルバーに、得意な翻訳は LLM に── ここが論理ソルバー方式の役割分担の肝です。

LLM にとっても Datalog は かなり生成しやすい（＝LLMに優しい） 言語なので、ユーザーは自然文でしゃべるだけで、裏でちゃんとしたクエリが組み上がる。

ユーザー目線では、こう動きます ── freee × Datalog の具体例

ここまで抽象的な話が続いたので、ぐっと具体に降ります。 僕らが今手元で動かしている 論理ソルバーMCP（remote-logic-solver-mcp）という MCP サーバー（簡単に言うと、AIから呼べるツール群）を例にとります。 中身は、freee の会計データに対して Datalog の述語を当てて検証するエンジンだと思ってもらえれば OK です。

たとえば、月末の経理担当者がチャットでこう聞いたとします。

「先月の交際費で、一人当たり 5,000 円ルールに引っかかってる伝票だけ拾って」

ユーザーから見ると、普通にチャットに日本語を打ってるだけ。 でも、裏ではこんなレールが敷かれています。

[▲ freee × Datalog の処理の流れ]

順を追うと、

1. MCP が freee からデータを取りに行く：該当月の伝票・参加人数・金額を一気に引っ張ってくる
2. ソルバーが述語を当てて検証：合致する伝票を機械的に抽出する。ここは確率の上に乗っかっていないので、誰がいつ何回投げても同じ答えになります
3. LLM が結果を翻訳して返す：「5件あります。伝票 #123 は一人当たり 8,000 円で、上限の 5,000 円を超えています ……」

LLM が両端の**「翻訳」だけ**やって、判定の本体はソルバーに任せる ── まさに役割分担そのものです。

ちょっと中身を覗いてみる ── Datalog って、思ったより素朴

「述語」「Datalog」と言われると身構えますが、中身はかなり素朴です。少しだけ覗いてみましょう（コードは読めなくて大丈夫。雰囲気だけ眺めてください）。

まず、会計データを 「主語・関係・目的語」の3つ組にバラします。この一粒を 事実（datom） と呼びます。

[ある取引   "is_a"          "取引"]       ; これは「取引」である
[ある明細   "is_belong_to"  ある取引]     ; 明細は、その取引にぶら下がる
[ある明細   "is_a"          "課税仕入"]    ; その明細は「課税仕入」である
[ある取引   "attr/amount"   33000]        ; 取引の金額は 33,000 円

freee から同期した取引・明細・取引先・税区分などが、ぜんぶこの「3つ組の事実」に展開されます。1事実につき1行。込み入った構造はありません。

その上に、「こういう事実が揃うものを探せ」とルール（クエリ）を書きます。

[:find ?取引
 :where
 [?明細 "is_belong_to" ?取引]              ; 明細が、ある取引にぶら下がっていて
 [?明細 "is_a" "課税仕入"]]                 ; その明細が「課税仕入」である

?取引 や ?明細 は「まだ中身の決まっていない箱（変数）」。しくみが、手元の全事実を当てはめて、条件をぜんぶ満たすものだけを漏れなく・重複なく返します。「どう探すか（手順）」は書きません。「何が成り立てば対象か」を並べるだけ。これが論理ソルバーの素直さです。

この書き方が、会計監査でとくに効く理由を3つだけ。

「○○が無い」を素直に書ける

会計監査の本丸は、じつは否定・欠落だったりします。「取引先が紐づいていない」「証憑がない」。さっきのクエリに「その取引に "取引先" の事実が無いこと」を一句足すだけで、「課税仕入なのに取引先が未登録の取引」が書けます。表計算ソフトの検索言語だと回りくどい言い換えに悩むところが、論理ルールならそのまま書けるんです。

「なぜ拾われたか」を最後まで辿れる

答えが事実の連鎖からできているので、結論から根拠の事実まで遡れます。本ツールには可視化機能があって、「この取引が指摘された」の背後にある取引・明細・取引先を、点と線の関係図で表示できます。AIがもっともらしい嘘をついても、原票まで遡って即座に見破れる。

[▲ 可視化（関係グラフ）]

[▲ 該当を色づけ（ノードから freee 原票へ）]

法令改正に「バージョン併走」で追える

税制は変わります。論理ルールはバージョン管理できて、旧版を残したまま新版を併走できる。「過去期は旧法令、当期は新法令」という監査が、同じしくみの上で成立します。

検証ずみの述語が「資産」として残る

二つ目の角度は資産化の話。 論理ソルバー方式の効きどころは、誤答が減ることだけじゃありません。 役割分担の副産物として生まれた検証ずみの述語が、組織の知的資産として積み上がっていく ── ここが中長期で一番効いてきます。

この述語、来月もそのまま使えます

さっきの 違反伝票 という述語、来月もそのまま使い回せます。 データの中身（誰がどこで何を飲み食いしたか）は毎月変わりますが、判定ロジックの構造は変わらないからです。

さらに、

• 「上限が 5,000 円 から 5,500 円 に変わった」みたいな改正 → 一行直すだけ
• 「子会社では 3,000 円」みたいなバリエーション → 同じ述語に引数を渡すだけ
• 「交際費じゃなくて会議費も同じチェックを」みたいな横展開 → 入口の述語だけ差し替え

会計士・税理士の方なら、たとえばこんなチェックも同じ仕組みで書けます。

• 「インボイス番号が抜けてる仕入伝票だけ拾って」
• 「税区分が消費税率と整合していない仕訳ない？」
• 「期末残高で、勘定科目と税区分の組み合わせが規定外のもの」

毎月 Excel で目視フィルタしていた頃と決定的に違うのは、判定ロジックそのものが組織の資産として残ること。 一度述語にしてしまえば、来期も、別のクライアントでも、そのまま使い回せます。

密度が高くて、雑味が乗らない ── だから何度でも参照される

なぜ、ここまで使い回せるのか。 LLM のアウトプットには色々ありますが、構造化された述語論理クエリ（Datalog の述語）って、生成物としての"濃さ"が他とはだいぶ別格なんですよね。

ポイントは二つ。

• 情報密度が高い：「貸借が一致する」「税区分に該当する」って一行に、判定ロジックの本体がぎゅっと詰まっている。雑談1往復の長文と比べると、1文字あたりの仕事量がぜんぜん違う
• 個別事情の雑味が乗らない：取引の中身や登場人物が変わっても、本質だけを切り出した形で書かれているので、データの中身（誰が・何を・どこで……）がいくら変わっても、そのまま呼び出せる。雑味を削いで骨だけ残しているからこそ、別のケースにも当たる

結果として、述語は何度でも参照される。 LLM に同じ問いを毎回投げて似たような長文を返してもらう（＝参照回数 1）のと、一度きちんと翻訳して述語ライブラリに刺しておく（＝参照回数 N）のとでは、累積で稼げる仕事量が桁で違ってきます。 生成AIの出力を「使い捨て」で終わらせず、参照回数 × 情報密度が両方稼げる構造にしています。

段重ねで積み上がる ── 原始述語 → ドメイン述語 → 業界特化

ここまで「述語1個の強さ」を見てきましたが、もうひとつ。Datalog だと、述語を段重ねにして積み上げられます。

• 原始述語（一番下の段）：もっとも基本的なつながりを定義する。たとえば「取引概念 is_a 取引実態」（「取引概念」は「取引実態」の一種）、「取引実態 has_many 取引詳細」（一つの取引実態は複数の取引詳細を持つ）
• 会計ドメイン述語（中段）：原始述語を組み合わせて、会計の業務用語に当たる述語を組み立てる。例：仕訳が成立する / 貸借が一致する / 税区分に該当する …
• 医療会計ドメイン述語（さらに上）：会計ドメイン述語の上に、医療会計の特殊ルールを積む。例：保険点数の計算、自費と保険の按分、医療法人特有の会計処理 …

下の段で一度検証された述語は、上の段からは「もう確かなもの」として呼び出すだけで済む。 新しい業界に展開するときも、原始述語まで作り直す必要はなくて、上の段だけ差し替えればいい。

これ、人間の業務に習熟していくプロセスと、ほぼそっくりだと思いませんか。 新人のうちは、「仕訳ってなに？」「この取引はどの勘定科目？」みたいな、原始述語レベルの話を覚える。 ベテランになると上司から「この患者さんの月次レセプト、まとめといて」みたいに、高度なドメイン述語そのもので指示が飛んでくる。 中身には、診療行為の分類、保険点数の計算、自費と保険の按分、請求形式への整形 ── 大量の低レベル処理が入っているわけですが、ベテランは頭の中でそれを自動展開できる。 「急性期入院なら…／在院日数が○日超なら…／減算は△で…」みたいな、複雑な場合分けの木が、頭の中でほぼ反射で走っている、という感じです。

Datalog の述語ライブラリで起きていることも、まったく同じ構図です。

ここでひとつ嬉しいポイントが。 Datalog は、事実と述語の関係を「ネットワーク（向きのある矢印でつながった図、有向グラフ）」として扱う言語なんですよね。 ベテランの頭の中の「場合分けの木」── 厳密には同じ判断を共有するので、木というより枝が合流したり分かれたりするネットワーク ── を、そのまま述語のつながりとして表現できる。 SQL みたいに「テーブルを結合で無理やり平らにつなぐ」ノリだとどうしても歪んでしまう判断の流れが、Datalog のネットワーク上には素直に載ってくれます。

具体的には、ベテランの「複雑な場合分け」は、Datalog でいうと クエリ × IDB（ルールで導かれる述語の集まり） に、きれいに対応します。 業務担当者が投げる「月次レセプト まとめて」というひとつの大きな問いが、IDB に積まれたたくさんの場合分けルールを辿って、最下層の原始事実までドミノ式に展開されていく。 ベテランの頭の中にあった「もし○○なら、…」の判断ネットワークが、そのまま述語ライブラリのネットワークに写し取られている、と言ってもよさそうです。

つまり、ベテランの暗黙知をマニュアル化して、誰でも同じ品質を出せるようにする── そういうイメージですね。

もちろん、万能ではないです

正直なところ、論理ソルバー方式にも制約はあります。

• 抽象化のひと手間がかかる：自然文を述語に落とすところで、ちょっと整備が要る

「あいまい寄りの問い」も、ソルバーを完全に諦めなくていい

ひとつ実務寄りの裏ワザを。 「白黒つかない問い」でも、ソルバーをまるごと捨てる必要はないんです。 コツは、ソルバーを "取りこぼさない粗いフィルタ" として使うこと。

たとえば、

1. ソルバーで粗く絞る：取引データ 1万件のなかから、「規定違反の疑いがあるもの」を疑わしきは拾う方針で Datalog に書く（取りこぼしゼロ、空振りはあってよしの精神でOK）。1万件 が 10件 の "要チェック" まで一発で機械的に削れる
2. LLM で深掘り：残った 10件 に LLM が個別に当たって、趣旨や文脈まで踏み込んで判定。最終的に「本当に対応が要る 2件」を出す

ここがポイントなんですが、「白黒ハッキリの絞り込み」と「グレーの取り扱い」を別の役者にやらせることで、お互いの苦手を補い合えるんですよね。

• ソルバー側は「疑わしきは入れる」で書けるので、見逃しが出ない
• LLM 側は 10件 という人間スケールの量だけ深く見ればよく、ブレもトークン代も収まる

1万件をいきなり LLM に投げるとトークン代もブレも事故りますが、10件まで落ちれば LLM が安定して仕事できるレンジです。 白黒ハッキリ（ソルバー）→ グレーの取り扱い（LLM） を直列に並べると、相性がよくなる、というイメージ。

それでも扱えない問いは、素直に LLM単独 / RAG+LLM に逃がす

そして、上の「粗いフィルタ → LLM 深掘り」でもまだ届かない、本当にフワッとした問い ── そういうものは、無理せず LLM単独 や RAG+LLM にそのまま流せばいいだけです。 ハマる範囲では論理ソルバー方式が他の二つを上回り、ハマらない範囲では LLM単独 / RAG+LLM と同じ土俵に降りるだけ。 つまり論理ソルバー方式を採用しても劣後する場面が出ない（最悪でも引き分け）、というのがポイントです。

その上で、対象を「ロジカルな推論」に絞ったときの効果は、けっこう大きいです。

観点	① LLM単独	② 素朴なRAG+LLM	③ 論理ソルバー+LLM
網羅性	△	△	◎
繰り返しの精度	×	△	◎
トークン節約	×	△	◎
表現の柔軟性	◎	◎	△（論理で書ける範囲）
曖昧質問への対応	◎	◎	△

なので現実的には、ロジックで書ける問いはソルバー方式、はみ出る話は従来のやり方って棲み分けるのがよさそうかな、と思っています。

[▲ 問いの棲み分け（ルールで書けるか？）]

おわりに

ざっくりまとめると、こんな話でした。

• 生成AIの誤答って、「ロジカル推論」で目立ちやすい
• ロジカル推論は 依頼 → 命題 → 証明 → 検証 → 計算（簡約） に分けられる
• LLM単独はこれを全部「文章生成」でやっちゃうので、検証が抜けちゃう
• RAG は入力の補強にはなるけど、根っこの検証までは届かない
• 論理ソルバーと組ませると、LLMの直感 × ソルバーの厳密さで、誤答がグッと減る
• 検証ずみの述語（定理）が貯まっていくので、使うほど賢くなる
• ただしロジックで書けない問いは従来方式に任せる、っていうのが現実的な落としどころ

「AIを使うか／使わないか」って議論から、「どこに、どんなAIを、どう組み合わせて使うか」って話に、少しずつ変わってきている気がします。 このあたり、まだ正解がない領域なので、僕も日々試行錯誤しています。 読んでくださった方の業務でも、何かヒントになれば嬉しいです。

---

関連記事

• 🚀 freeeの会計データを「論理」で監査する（リリース・全体像） … この記事の論理ソルバーMCPで、実際に何ができるか。
• ✅ 「暴走するAI」をどう手なずけるか？——検証六角ボルトの打ち方 … 述語（ルール）の品質を、テストでどう担保するか。