メタディスクリプション：Ollama + Gemma + AnythingLLMで請求書OCR・RAG検索を試した実装記録。48GBメモリMacで動くモデルの選定理由と、中小企業の経理・営業業務に落とし込める5つのユースケース。
キーワード：ローカルAI / Ollama / Gemma / AnythingLLM / 中小企業DX / 請求書OCR / RAG
この記事で得られること
- 48GBメモリのMacで実用になるローカルLLMの選定基準
- OllamaとAnythingLLM・Open WebUIの役割分担
- 中小企業の事務業務で実装可能なAI活用5パターン
- クラウドAI（ChatGPT/Claude）ではなくローカルを選ぶ判断基準
なぜローカルAIなのか
中小企業の現場では、ChatGPTやClaudeに顧客データ・請求書・人事情報を入力することが事実上できない。情報システム部門がない会社ほど「外に出したくない」という判断は強い。
一方で、ここ半年で状況が大きく変わった。個人が触れる範囲のハードウェア（メモリ32〜64GB程度のMac/Windows）で、実用レベルのLLMがローカルで動くようになった。
- 2024年：70Bクラスのモデルを動かすには100万円超のGPUが必要だった
- 2026年現在：32Bクラスの日本語対応モデルが48GBメモリで動く
「データを外に出さない」と「そこそこ賢い」が両立できる地点に、個人・中小企業が立てるようになった。これが今、検証する価値のあるテーマだ。
検証環境
| 項目 | 内容 |
| ハード | MacBook Pro4 メモリ48GB |
| ランタイム | Ollama（ローカルLLM実行） |
| UI | Open WebUI（ブラウザからチャット） |
| RAG | AnythingLLM（ナレッジ検索） |
| 連携 | n8n（ワークフロー自動化・検証中） |
Ollama1本ではなく、UI・RAG・ワークフローを別ツールで分担する構成にした。各ツールがOllamaをAPIで叩く形。1つのUIに全部集約するより、後から差し替えやすい。
試したモデルと選定理由
Gemma 4（31B）
現在のメイン。Googleのオープンウェイトモデル。
採用理由：
- 48GBメモリで余裕を持って動く（実効メモリ消費 約25GB）
- 日本語の応答品質が安定（1年前のLlama 2系とは別次元）
- 請求書のような半構造化PDFからの情報抽出が実用レベル
- Googleが継続開発している安心感（業務提案で説明しやすい）
Gemma 4（e4b 軽量版）
OCRデモ用に採用。
採用理由：
- スマホで撮影した請求書画像からテキスト化までが数秒
- デモの「見せる」用途では速度優先
- 精度は31Bに譲るが、文字認識タスクなら十分
LLM-JP-4（32B）
日本語特化モデル。国立情報学研究所系。
検証目的：
- 日本企業向けに提案する際の「国産AIです」という訴求
- 請求書・帳簿・社内マニュアルなど日本語純度の高いタスクでの比較
現時点の評価： 汎用タスクではGemma 4が安定しているが、純日本語文書の要約・言い換えではLLM-JPが自然な出力を返す場面がある。タスクで使い分ける方針。
DeepSeek-R1（32B）
推論特化モデル。
検証目的：
- 「この取引先の過去3ヶ月の請求傾向を分析して」のような複雑な集計・推論タスク向け
- 単純なOCR・転記タスクにはオーバースペックなので使い分け前提
中小企業の事務業務に落とせそうな5つのユースケース
実装の難易度と、手作業削減インパクトで整理した。
1. 請求書PDF → Excel自動転記
現状の手作業： 紙またはPDFで届く請求書を、担当者が目視で金額・取引先・日付を読み取り、Excelや会計ソフトに入力。
AI実装： 特定フォルダにPDFを入れる → Ollama + Gemmaが読み取り → Excelシートに追記。
削減効果： 月100件処理している会社なら、10〜15時間の手入力がほぼゼロに。
難易度： 中。OCR精度は実用レベルだが、会社ごとの請求書フォーマットに合わせた抽出ルールのチューニングが必要。
2. 全銀フォーマット生成 → 振込作業1クリック化
現状： 請求書を見ながら銀行のEB（電子バンキング）に1件ずつ振込情報を入力。
AI実装： 1の結果から全銀フォーマット（銀行の一括振込用CSV）を自動生成 → 担当者が目視確認 → EBに取り込み → 承認。
削減効果： 振込作業が9割削減。最後の承認ボタンは必ず人間が押す設計にすることで、誤振込リスクを統制。
難易度： 中。全銀フォーマットの仕様はオープンなので、生成自体は容易。
3. 価格表・社内マニュアルのRAG検索
現状： Excelの価格表が複数ファイルに分散。「この商品の卸値いくらだっけ」で毎回ファイルを開いて探す。
AI実装： AnythingLLMに全ファイルを読み込ませ、チャットで「○○の卸値は？」と聞くと即答。
削減効果： 「どこに書いてあったっけ」のロス時間がゼロ。新人教育コストも下がる。
難易度： 易。ファイルを入れるだけで動く。このユースケースが一番ROIが高い。
4. ECサイト注文 → 会計ソフト自動転記
現状： Yahooショッピング・楽天・Amazonの注文CSVを、弥生会計などに手入力。
AI実装： ECの注文CSV取得 → 仕訳ルールに沿ってAIが会計ソフト形式に変換 → インポート用ファイル出力。
削減効果： 月200件の注文で月8〜10時間削減。
難易度： 中。仕訳ルールの初期設計に時間がかかるが、一度決めれば安定。
5. 業務マニュアルのAI検索化
現状： 業務マニュアルがWord・PDFで分散。誰も全部は読んでいない。
AI実装： AnythingLLMに全マニュアルを投入 → 「〇〇の手続きはどうやる？」でAIが該当箇所を引用付きで回答。
削減効果： 新人教育の「先輩に聞く回数」が激減。定型質問への回答コストをゼロに。
難易度： 易。
ローカルAIの限界と、クラウドとの使い分け
ローカルAIは万能ではない。以下のタスクはクラウド（Claude/ChatGPT）のほうが向いている。
- 最先端の推論が必要なリサーチ業務
- 大量の外部Web情報を参照する必要があるタスク
- 画像生成・動画生成
判断基準はシンプルだ。社内データを含むかどうか。含むならローカル、含まないならクラウド。
中小企業の日常業務の7〜8割は社内データを含む。だから、ローカル側に寄せる設計価値がある。
次の検証
現在、以下を並行で検証中。
- n8nでのワークフロー組み上げ（フォルダ監視 → OCR → Excel書き込みの全自動化）
- AnythingLLMのワークスペース分離（部門ごとに参照範囲を分ける設計）
- 実運用を想定した、非エンジニアでも触れるUI構成
個別の検証結果は、別記事で順次公開する。