はじめに
経費精算のチェック作業、件数が増えると地味にしんどい。
上限超えてないか、承認は取れてるか、領収書の但し書きは合ってるか。1件ずつ規程と照らし合わせて確認する。ルールは明確なのに、量が多いと時間がかかる。
AIに投げたら一瞬で終わりそう。でも経費データには社員名、取引先、金額も入っている。社内ルール上、クラウドのAIサービスにこういったデータを送ることは難しい。現時点だとこういう企業は少なくないと思う。
ということで、Qwen3.5をOllamaでローカル実行して、経費チェックをやってもらった。推論データは手元のGPUで完結するので、経費データがクラウドAPIに送信されない構成が取れる。
さらにQwen3.5はテキストと画像を1つのモデルで扱える（Vision統合）。実際の郵便局の領収書を読み取ってもらう検証もやった。
結論から言うと、Qwen3.5の真価はVision（画像読み取り）にあって、テキスト判定だけなら旧モデルのQwen3で十分だった。
この記事でわかること
- Qwen3.5（35B-A3B）× RTX 4090 での経費チェック判定の実力
- 思考モードON/OFFで精度が大きく変わった話（OFFは非推奨）
- 実物の領収書をローカルLLMでOCRした結果（成功と失敗の両方）
- Qwen3.5 vs Qwen3 の比較で見えた使い分け
環境
| 項目 | 内容 |
|---|---|
| GPU | NVIDIA RTX 4090（VRAM 24GB） |
| モデル | qwen3.5:35b |
| Ollama | ローカルサーバー |
| OS | Windows 11 Pro |
RTX 4090は別のPCに載っていて、ローカルLLM専用機として使っている。
補足: Qwen3.5-35B-A3BはMoE（Mixture of Experts）アーキテクチャで、35Bパラメータのうち推論時に動くのは3B分。VRAM 24GBに収まるサイズ。Q4_K_M量子化は、モデル重みの精度を下げてサイズを小さくする方式で、精度劣化の可能性はあるが実用性が高い。Ollamaでも推奨量子化の一つ。これによりVRAMに載るようになる。
セットアップ
Ollamaが入っていれば、モデルの取得と起動はコマンド2つ。Ollamaのインストール手順は以前の記事を参照。
ollama pull qwen3.5:35b
ollama serve
あとはアプリ側からlocalhostにリクエストを投げるだけ。うちの環境ではこれだけで動いた。
検証1: 単一ケースでの経費チェック判定
まずはシンプルなテキスト入力での判定から。
シナリオ: 居酒屋○○ 7,800円。交際費の上限は5,000円。
thinking ON（思考過程あり）
補足: Qwen3.5では、Qwen3の
/think/nothinkのようなソフトスイッチではなく、APIパラメータで思考モードを制御する。この記事では便宜上「thinking ON/OFF」と表記する。
応答時間: 約80秒（うち思考過程に70.9秒）
判定は正確。金額超過→条件不備→結論の順で論理的に思考していた。指摘は3件:
- 第5条(1) — 交際費上限5,000円を超過、部長の事前承認なし
- 第6条(2) — 領収書の但し書き「飲食代」が不十分
- 第8条(1) — 相手先の会社名・氏名・参加人数の記載不足
条文番号付きで差戻しコメントまで生成してくれた。
thinking OFF（思考過程なし）
応答時間: 約30秒。判定は同じく正確。2.7倍速い。
単一ケースではthinking OFFでも精度に差がなかった。ただし、この判断は後で覆ることになる。
検証2: 20件の交通費データで精度を測る
単一ケースで「thinking OFFでも大丈夫そう」と思ったので、本格的に検証した。電車・タクシー・新幹線・自家用車・飛行機・グリーン車など20件の交通費データを、以前のQiita記事（Qwen3 14B / 30B-A3B / 32B を Ollama で比較：交通費の課税判定タスクで見えた差）と同じデータ・同じプロンプトで投入し、Qwen3.5と比較。
結果: thinking ONは合格、OFFは精度が大きく落ちた
| モデル | 精度 | 応答時間 |
|---|---|---|
| Qwen3-14B | 17/20 (85%) | 40秒 |
| Qwen3-30B-A3B (MoE) | 18/20 (90%) | 36秒 |
| Qwen3.5-35B-A3B (think ON) | 18/20 (90%) | 415秒 |
| Qwen3.5-35B-A3B (think OFF) | 14/20 (70%) | 97秒 |
| Qwen3-32B Dense | 20/20 (100%) | 760秒 |
なお、20件での検証なので統計的に厳密な精度とは言えない。傾向を掴むための参考値として見てほしい。
thinking ONなら90%で、Qwen3-30B-A3Bと同等の精度が出た。
問題はthinking OFF。精度が70%まで落ちた。しかも単純に間違えるだけでなく、ある行の根拠欄で自問自答が止まらなくなり、出力上限に達して3行まるごと欠落するという、今回の検証ではさすがにまずい問題が起きた。
単一ケースでは見えなかった弱点が、20件の定量評価で一気に見えてきた。「1件やって大丈夫だったからOK」は危ない、という教訓になった。
もう一つの発見: テキスト判定にQwen3.5を使うメリットがない
表をもう一度見てほしい。Qwen3.5（thinking ON）は精度90%・415秒。Qwen3-30B-A3Bは同じ精度90%で36秒。同じ精度で約11.5倍遅い。
これはMoEアーキテクチャの特性で、ルーティング機構が各トークンに対して一部のエキスパートだけを選択して計算するため、実際に動くのは3B分のパラメータのみ。この構造はQwen3-30B-A3Bと同じ。テキストの判定だけなら、Qwen3.5に乗り換える理由がなかった。
検証3: Qwen3.5のVision OCRで実物の領収書を読む
ここからがQwen3.5の出番。テキストと画像を1つのモデルでネイティブに処理できるのが特徴。Qwen3世代ではテキスト用（Qwen3-30B-A3B）とVision用（Qwen3-VL-30B-A3B）が別モデルだったのが、Qwen3.5では統合された。
郵便局の領収書（実物を撮影した写真）を読み取ってもらった。証紙切手引受（第一種定形110円）+ 簡易書留350円 = 合計460円の感熱紙レシート。
応答時間: 約127秒
結果: 核心情報は正確、細部に誤読あり
| 項目 | 読み取り結果 | 正解 | 一致 |
|---|---|---|---|
| 発行者名 | 日本郵便株式会社 | 日本郵便株式会社 | ✓ |
| 日付 | 2026/01/28 | 2026/01/28 | ✓ |
| 合計金額 | ¥460 | ¥460 | ✓ |
| 税区分 | 課税計¥460, 消費税¥41 | 同左 | ✓ |
| 支払方法 | QUI Pay | QUICPay | ✗ |
| 品名 | 第二種定形 | 第一種定形 | ✗ |
| 加盟店名 | こづかピコッ | （印字が薄く判読困難） | ✗ |
経費判定に必要な情報（金額・日付・発行者・税区分）は全て正確だった。
一方で誤読も3箇所。「第一種」→「第二種」は漢数字の誤認識、「QUICPay」は「C」が脱落、加盟店名はレシート下部の印字が薄くて完全に読めなかった。
テスト画像（くっきりした文字をプログラムで生成したもの）では全項目100%正確だったので、実物の感熱紙レシート特有の課題がはっきり出た:
- 感熱紙は濃淡にムラがある → 薄い部分の認識精度が落ちる
- 小さい文字（加盟店名、端末情報）は不安定
- ブランド名のカタカナが崩れやすい
とはいえ、金額と日付と発行者が取れていれば経費チェックの入口としては使える。品名や細かい情報は人間が確認すればいい。「全自動」ではなく「下読みをAIに任せて、人間は確認に集中する」使い方が現実的。
結論: Qwen3.5の価値はVisionにある
今回の検証で見えた使い分けはこうなった。
| 用途 | おすすめモデル | 理由 |
|---|---|---|
| テキストの経費チェック（通常） | Qwen3-14B / 30B-A3B | 高速（36〜40秒）で精度も十分 |
| テキストの経費チェック（高精度） | Qwen3-32B Dense | 正答率100%。ただし760秒かかる |
| 領収書画像の読み取り | Qwen3.5-35B-A3B | 今回比較したQwen3群で唯一のVision統合型 |
今回の検証条件（20件のテキスト判定）では、Qwen3.5に乗り換える利点は見つからなかった。 同精度で11倍遅い。
Qwen3.5の真価はVision統合。 領収書を画像で読み取って、金額・日付・発行者を自動抽出できる。テスト画像なら100%正確、実物の感熱紙でも核心情報は正確に取れた。
実運用のイメージとしては:
- 領収書の画像 → Qwen3.5 でOCR（金額・日付・発行者を抽出）
- 抽出したテキスト → Qwen3 で規程と照合（高速チェック）
- 要確認ケースのみ → Qwen3-32B に再投入、または人間が判断
推論処理はローカルで完結する。経費データをクラウドAPIに送らない構成が取れる。
注意点・制限事項
とはいえ、正直なところ。
- 応答速度: Qwen3.5 thinking ONで415秒（20件）。平均1件あたり約20秒。Claude Codeなら数秒で返ってくるタスク
- thinking OFFは今回の検証では非推奨: 単一ケースでは問題なく見えたが、20件で検証したら精度が90%→70%に低下。出力欠落も発生した。Qwen3.5ではthinking ONを推奨
- GPU要件: 今回はRTX 4090（VRAM 24GB）で検証。35Bモデルを量子化して載せるにはこの程度のVRAMがいる。他のGPUでの動作は未確認
- OCRの限界: 実物の感熱紙レシートでは、印字が薄い部分や小さい文字で誤読が発生した。品名や加盟店名は人間の確認が必要
- LLMの非決定性: 同じ入力でも毎回微妙に異なる結果が出る可能性がある。最終判断は必ず人間が行う前提
- 推論はローカル完結だが: モデルのダウンロードにはネット接続が必要。周辺ツール（Ollamaのアップデート確認等）が外部通信する可能性もある。「一切の外部通信ゼロ」ではなく「推論データがクラウドAPIに送信されない構成」が正確な表現
まとめ
- Qwen3.5（35B-A3B）× RTX 4090 で、経費チェック判定と領収書OCRをローカルで検証した
- テキスト判定の精度は90%（thinking ON）。ただしQwen3と同精度で約11.5倍遅く、テキスト判定だけなら乗り換えるメリットなし
- Qwen3.5の真価はVision統合。実物の領収書でも金額・日付・発行者は正確に読み取れた
- thinking OFFは単一ケースでは問題なかったが、20件で検証したら崩壊した。「1件で大丈夫」を信じすぎない方がいい
- 推論データはローカル完結。経費データをクラウドに送らない構成が取れる
「AIで経費チェックを効率化したいけど、データを外部に送れない」。その壁に対して、ローカルLLMは現実的な選択肢になりつつある。ただし万能ではない。テキストはQwen3、画像はQwen3.5、最終判断は人間。適材適所で組み合わせるのが、今のところ一番現実的な使い方だった。
ただ、最近はクラウドAIサービスのセキュリティ基準も整ってきており大企業でも導入が進んでいる。自社のセキュリティポリシーに合わせて、ローカルとクラウドを使い分けるのが現実的な選択肢になってきていると思う。