はじめに：AIの提案を、仕事で使える判断にするには
「AIが経費申請を読んで、必要な確認まで進めてくれたら便利だな」
そう思ったとき、気になるのは読み取りの速さだけではありません。金額を間違えていないか。社内の規程を守っているか。わからないことを、わからないまま止められるか。仕事で使うには、こうした確認も必要です。
以前、「自然言語からSQL」、精度100%の魔法はない。だから「運用」の話をしようという記事を書きました。自然言語からSQLを作る技術でも、業務用語の定義や権限、評価の仕組みを整える必要がある、という話です。
今回はその続きです。整えた業務ルールを、AIを使う仕事の流れにどう組み込めるのか。そこで知っておきたいのが、ニューロシンボリックAIと自動推論です。
名前は少し難しそうですが、今から理解を始めても全然間に合います。まずは、身近な業務のどこをAIに任せ、何をルールで確かめるかを考えてみましょう。
経費申請や営業業務のルールは、説明用の架空の例です。研究・製品情報の確認日は2026年11月5日です。
1. 有望なのは、条件をはっきり書ける仕事
最初に、使いどころを見ておきます。この技術が有望なのは、言葉を読み取る必要があり、その後の判断には明確な条件がある仕事です。
| 仕事の例 | AIに手伝ってもらうこと | ルールで確かめること | 人が確認すること |
|---|---|---|---|
| 経費申請 | 申請文から金額や領収書番号を読み取る | 上限金額、必須項目、登録データとの一致 | 支出の必要性や例外の扱い |
| 見積もり・値引き申請 | 顧客からの依頼を整理する | 値引き幅、承認者、適用期間 | 個別交渉や特別対応の妥当性 |
| 保守サービスの案内 | 問い合わせの内容を整理する | 契約期間、対象製品、利用条件 | 契約の解釈が難しい案件 |
| 社内制度の案内 | 社員の質問を読み取る | 雇用区分、勤続期間、対象地域 | 情報不足や規程にないケース |
例えば「この顧客に値引きすると喜ばれそうか」と、「この値引き率には部長承認が必要か」は、性質の違う問いです。前者には顧客理解や営業判断が要ります。後者は、条件が決まっていれば機械で確認できます。
万能ではありませんが、この違いを整理できる領域には使い道があります。営業担当者が持つ「普段、どこで確認が必要になるか」という知識も、設計の材料になります。
2. 二つの名前を、経費申請で理解する
LLMは言葉を読み取り、答えを作る
ChatGPTなどで使われるLLMは、大量のデータから学び、文章を理解・生成するモデルです。
例えば「昨日の訪問で立て替えた交通費12,000円です。領収書はR-001です」という申請文から、金額と領収書番号を取り出す役割を任せられます。ただし、読み取りを誤ることもあるため、その値を確かめる工程が必要です。
ニューロシンボリックAIは、学習と明示した知識・ルールを組み合わせる
「ニューロ」はLLMなどを支えるニューラルネットワークを指します。「シンボリック」は知識や条件、関係を、機械が扱えるよう明示する考え方です。
二つを統合するのが、ニューロシンボリックAIです。今回の例では、LLMに申請文を読んでもらい、抽出した内容を別のプログラムが業務データやルールと照合します。
この名前が指す研究は幅広く、ルールを学習に取り込む方法などもあります。ここで扱う「LLMと外部のルールを組み合わせる構成」は、その一つです。2025年のサーベイでは、こうした統合の方法が整理されています。
自動推論は、前提とルールから結論を導く
例えば、次の条件が決まっているとします。
「申請者が在籍中で、領収書の照合が済んでいれば、申請資格がある」
そのうえで「申請資格があり、金額が3万円以下なら、自動処理の候補にする」と決めます。確認した事実にルールを順に適用すれば、結論を導けます。前提とルールから結論を導くことを、演繹と呼びます。
自動推論はこの結論の導出や、条件の矛盾・反例を探す処理などを機械化する技術です。LLMが登場する前から研究・利用されており、LLMを使わない構成でも動きます。
| 用語 | まず押さえたいこと | 経費申請での役割 |
|---|---|---|
| LLM | 言葉を理解し、文章などを作るモデル | 金額や領収書番号を読み取る |
| ニューロシンボリックAI | ニューラルネットワークと明示的な知識・ルールを統合する考え方 | 読み取りとルールによる判定を組み合わせる |
| 自動推論 | 前提と規則を使い、結論の導出などを機械化する技術 | 確認した事実から、処理の候補になるかを導く |
ニューロシンボリックAIは「組み合わせ方」、自動推論はそこで使える「技術」と考えると、二つの関係をつかみやすくなります。
3. LLMにルールを伝えるだけでは、何が足りないのか
LLMに「社内規程を守ってください」と指示できます。ただ、守るように頼むことと、実際の処理をルールに従わせることには違いがあります。
例えば、LLMが「この申請は問題ありません」と答えても、何を照合したのかがわからなければ、業務では判断に困ります。必要な金額や番号を取り出し、確認済みのデータと照合し、決めた条件で判定する。こうした処理をシステムに組み込みます。
engchinaさんの「AI Agent の幻覚、人間じゃなくて『プログラム』に見張らせるのはアリじゃないか、という話」でも、AIの出力をプログラムで確認するProgram-in-the-Loopという発想が紹介されています。企業でAIを使う方法を考えるうえで、参考になる視点です。
ただし、確認できるのはプログラムに書いた条件です。合計金額が合っていても、別の人の領収書だったら困ります。何を確認するかを決める仕事は残ります。
4. 経費申請は、どこまで任せられるか
架空の会社で、次のようなルールを作ったとします。
| 確認すること | 結果・扱い |
|---|---|
| 金額や領収書番号が読み取れない | 申請者に確認する |
| 在籍状態を確認できない | 保留して確認する |
| 在籍していない | この制度の対象外にする |
| 領収書番号や金額が、確認済みの登録データと一致しない | 人が確認する |
| 在籍中で照合も済み、金額が3万円以下 | 自動処理の候補にする |
| 在籍中で照合も済み、金額が3万円を超える | 人が確認する |
申請額が12,000円で、在籍状態と領収書の照合が確認できたなら、自動処理の候補にできます。30,000円も候補、30,001円なら人に確認する、という境界も明確です。
3万円の壁、1円違うだけでもシステムは律儀に確認をお願いしてきます。
ここで注意したいのは、「自動処理の候補」と「支払いの承認」は別だということです。この例では、支出の目的や二重申請までは確かめていません。実際の承認・支払いには、そうした条件や権限管理も必要になります。
また、LLMが読み取った値を、別の欄にコピーして「確認済み」と呼んでも照合にはなりません。従業員マスターや、申請者との対応を確認した領収書データなど、照合に使える業務データを用意します。
なお、経費申請の弱点にリアルに挑戦しようとするのはやめましょう。ここでは仕組みの弱点を見つけて、直すために考えています。
5. 今すぐ始めるなら、ルールを表にするところから
最初はシンプルな推論システムから。まず、業務担当者とエンジニアで「何を確かめるか」「どのデータを見るか」「わからなければ誰に戻すか」を表にします。
先ほどの経費申請では、次のようにルールをつなげられます。
在籍中 ＋ 領収書の照合済み → 申請資格あり
申請資格あり ＋ 3万円以下 → 自動処理の候補
「申請資格あり」という途中の結論を、次の判断に使っています。これが、ルールに基づく演繹の小さな例です。
実装には、条件が少なければ既存アプリの条件分岐やSQLを使えます。SQLはデータベースの検索や処理に使う言語です。ルール同士の関係や例外が増えれば、複数のルールを適用するための専用ソフトウェアも選択肢になります。
ところで、普通の条件チェック以外に、数学的な方法で性質を確かめる「形式検証」があります。例えば「金額が上限を超えているか」を今回の申請について確認するのが条件チェックです。一方、形式検証では、明示した前提のもとで「上限を超えるのに自動処理されるケースがあるか」といった性質を調べます。
どちらも役立ちますが、条件チェックを追加しただけで、あらゆる入力に対する正しさを証明したことにはなりません。
営業担当者なら、顧客との会話から「何の確認に時間がかかるのか」「どの例外で担当者が困るのか」を聞けます。それを具体的な条件とデータに整理できれば、エンジニアと実装の相談がしやすくなります。
6. なぜ有望なのか。何に気をつけるのか
期待できるのは、決めた条件を繰り返し適用できることです。さらに、どのルールで結論を出したかを記録すれば、人が確認するときの手がかりになります。規程が変わったときも、変更する条件を明示できます。
一方で、ルールや元データが間違っていれば、その間違いに沿って判断してしまいます。
| 気になる点 | 業務で考えておくこと |
|---|---|
| AIが金額や契約条件を読み違える | 元の文書や業務データとの照合を用意する |
| ルールの抜けや古い規程がある | ルールの担当者、適用日、更新手順を決める |
| 判断に必要な情報がない | 推測で埋めず、保留や確認へ進める |
| 正しい判定でも、データ自体が現実と違う | 元データの確認や訂正の手順を持つ |
| 確認が増えて、かえって手間になる | 誤った許可・差し戻し、処理時間、維持費も評価する |
ルールを細かくすればするほど、保守する仕事も増えます。まず対象を絞り、実際の申請を使って効果と手間を確かめる方が取り組みやすいでしょう。
社内の「場合によります」を一つずつ確認していくと、AIの話をしていたはずが、いつの間にか業務改善の打ち合わせになっているかもしれません。それも、この取り組みの使い道だと思います。
7. 研究でも、AIの生成と機械による検証の組み合わせが進んでいる
2025〜2026年の研究には、LLMが作った文章やコードを、そのまま結論にせず、明示した知識や検証の仕組みと組み合わせる取り組みがあります。
| 研究 | 取り組んでいることを短くいうと | 企業で考えるときのヒント |
|---|---|---|
| ATA、2025年10月、プレプリント | 知識を事前に整理して人が確認し、実行時の判断と分ける | 業務知識の整備と日々の処理を分けて考える |
| SymCode、EACL 2026 Findings、2026年3月 | 数学問題を、実行できるコードと記号計算を使って解く | 文章の説明に加え、計算を実行して確かめる |
| FormalJudge、ICML 2026、2026年7月 | 要求を検証できる条件に変換し、AIエージェントの振る舞いを確認する | 「守ってほしい」を、確認できる条件にする |
| Neuro-Symbolic Proof Generation for Scaling Systems Software Verification、OSDI 2026、2026年7月 | LLMが証明の候補を提案し、証明を検査するソフトウェアと組み合わせる | 候補を作る役割と、正しさを検査する役割を分ける |
数学やソフトウェアの研究成果が、そのまま経費や契約業務全体の正しさを保証するわけではありません。ただ、生成したものを別の仕組みで確かめる方法が、複数の分野で研究されていることはわかります。
AIが回答だけでなく業務の処理にも関わるようになるにつれ、こうした技術への注目はこれから高まるでしょう。「何ができるか」に加え、「何を根拠に実行するか」が企業での検討課題になるためです。
8. OracleやAWSにも、関連する機能がある
Oracle：データの意味や関係を、ルールで扱う基盤
Oracle Databaseには、データ同士の関係を表すRDFや、用語・関係を定義するオントロジーを扱い、ルールから新たな関係を導く機能があります。詳しくはOracleの公式ドキュメントに説明されています。
また、前の記事で扱ったSelect AIには、自然言語からSQLを作り、データに問い合わせる用途があります。言葉による依頼と企業データを接続する機能です。
これらは業務データと知識・ルールを組み合わせる構成を考える材料になります。Select AIが作ったSQLや回答の正しさに加えて、どのデータを使い、どの条件を確認するかという設計と合わせて、有用性を考えたいところです。
AWS：生成した回答を、定義した規則に照らして確かめる
Amazon Bedrock Guardrailsには、Automated Reasoning checksという機能があります。利用者が定義したポリシー、つまり守るべきルールに対して、自然言語の回答が整合しているかを検証します。
確認日時点では英語（米国）のみ対応し、検証できる範囲もポリシーで表現した内容に限られます。検知結果を受けて回答を出すか、修正するか、人に確認するかはアプリケーション側で扱います。自然言語を論理的な表現に変換する精度にも依存します。
こうした製品への実装はルールによる確認を実務へ組み込む選択肢になります。私は、推論の機能だけでなく、業務ルールを作り、試し、更新する作業への支援にも期待しています。
おわりに：仕事のルールを知る人にも、出番がある
ニューロシンボリックAIや自動推論を使うには、業務のどこに明確な条件があり、どこに人の判断が必要かを見つけることが大切です。その整理には日々の仕事や顧客の困りごとを知る人に参加していただくのがよいでしょう。
最初の一歩は、一つの業務について「AIに何を読ませるか」「何を確かめるか」「迷ったら誰に戻すか」を書きおこしてみること。経費申請でも、値引きの相談でも、具体的な仕事から始められます。
参考資料
関連記事
- Dash3：「自然言語からSQL」、精度100%の魔法はない。だから「運用」の話をしよう
- engchina：AI Agent の幻覚、人間じゃなくて「プログラム」に見張らせるのはアリじゃないか、という話
論文・公式ドキュメント
- Neuro-Symbolic Artificial Intelligence: Towards Improving the Reasoning Abilities of Large Language Models — 2025年のサーベイ。
- ATA: A Neuro-Symbolic Approach to Implement Autonomous and Trustworthy Agents — 2025年のプレプリント。
- SymCode: A Neurosymbolic Approach to Mathematical Reasoning via Verifiable Code Generation — Findings of EACL 2026。
- FormalJudge: A Neuro-Symbolic Paradigm for Agentic Oversight — ICML 2026。
- Neuro-Symbolic Proof Generation for Scaling Systems Software Verification — OSDI 2026。
- Oracle：Introduction to Oracle Semantic Technologies Support
- Oracle：Select AI Use Cases
- AWS：What are Automated Reasoning checks in Amazon Bedrock Guardrails?