freeeは「AIコスト問題」をどう乗り越えた？ 月100万件規模の処理で、汎用LLM比50分の1に：AWS Summit Japan 2026

freeeは月100万枚の帳票を処理するAI OCRに、独自のSLMを採用した。汎用LLMのAPIと比べ、項目抽出の精度は最大10ポイント向上し、速度は5倍、コストは50分の1になったという。当初は外部API並みだった速度をどのように向上させたのか。同社の取り組みに迫る。

[元廣妙子，ITmedia]

　AIを適用する業務が増え、活用レベルも上がる中で、AIにかかるコストが当初の想定を上回るケースが出てきた。

　クラウド会計ソフト「freee会計」などの使い勝手は、紙やPDFの帳票を自動で読み取るAI OCRの性能に左右される。freeeは、月間100万枚に上る帳票をAI OCRで処理している。汎用LLM（Large Language Model：大規模言語モデル）の精度は上がり続けているが、この規模のトラフィックにそのまま適用すれば、コスト面で見合わなくなる。

　そこで同社が選んだのは、巨大モデルに頼らない道だった。帳票から日付や金額、取引先などを抜き出す工程に絞り、自社で運用する独自の言語モデルを開発した。

　ただし、開発は最初から順調に進んだわけではない。SLMを自社環境でホストしただけでは、処理速度は外部API並みにとどまり、月100万枚をさばくには足りなかった。壁を破った鍵の一つは、仕組みをあえて「簡略化」することだった。学習データはどの程度必要だったのか。コストを50分の1まで下げられた理由とは。

freeeは「AIコスト膨張問題」をどう乗り越えた？

　freeeの木佐森慶一氏（AIプロダクトマネージャー）は、最新の高性能LLMの精度の高さを評価しつつも、月100万枚規模のトラフィックにそのまま適用すれば、膨大なコストの壁に直面すると指摘する。

　「向き合うべきは、現実的なコストで月100万枚をさばくというビジネス上の課題です。そこで巨大モデルに頼らず、コストとパフォーマンスを最適化できる独自のSLM（Small Language Model：小規模言語モデル）が必要だと確信しました」（木佐森氏）

図1　汎用LLMと独自SLMのメリット、デメリット（出典：木佐森氏の講演資料）

　木佐森氏によると、API経由で利用する汎用LLMと独自のSLMは、メリットとデメリットが正反対の関係にある。汎用LLMは手軽に高い性能を得られる反面、コストやレイテンシのコントロールが困難だ。一方で独自SLMの自社運用は、学習や評価、運用に投資が必要だが、特定のタスクに絞り込むことで、コストやレイテンシ、セキュリティを自社で制御できるようになる。

　「コスト・レイテンシ・精度は常にトレードオフの関係にありますが、コアタスクに最適化したSLMこそが、このトレードオフを突破して持続可能なビジネス価値を生み出す最適解だったのです」（木佐森氏）

SLMと学習データの概要

　木佐森氏は、今回のプロジェクトで使ったモデルと学習データについて解説した。

　freeeのAI OCRによるデータ処理は、以下の2つのステップで構成されている。

1. 画像からテキストを抽出：　アップロードされた画像やPDFから文字列を書き起こすプロセス
2. テキストから項目を抽出：　日付、合計金額、税率、取引先などの意味を特定し、構造化するプロセス

　独自SLMが担うのは後者の「テキストから項目を抽出」で、ベースとしたのは、80億パラメーター（8Bクラス）のオープンウェイトの基盤モデルだ。このモデルに対して、LoRA（Low-Rank Adaptation）を使った軽量なファインチューニングを施し、抽出したいタスクごとに最適化された重みを学習させるアプローチをとった。

　ここで問題になるのが、「学習データをどのように、どれだけの規模で用意すべきか」という点だ。木佐森氏は「『10万枚や100万枚といった膨大な正解データがなければ使い物にならないのではないか』とよく聞かれます。しかし、今回の取り組みでは検証やテスト用のデータは数万枚、実際の学習に投入した正解データは約1万枚でした」と強調する。

　なお、学習にはAWSの「Amazon SageMaker HyperPod」を活用した。ホスト環境は、Kubernetes基盤の「Amazon EKS」で高速な推論エンジン「vLLM」を稼働させる構成だ。

図2　SLMの推論基盤のアーキテクチャ（出典：木佐森氏の講演資料）

精度、速度、コスト　高性能モデルとの差はどこで生まれたか

　独自のSLMを導入した結果、高性能モデルと比べて精度は最大10ポイント向上し、速度は5倍、コストは50分の1になった。

精度面：テキスト項目で最大10ポイント向上

　日付や金額といった「数字」の項目は、初期の精度も高かったため改善の余地は限られていた。大きな効果が見られたのは「摘要」や「取引先」「発行元」といった、多様な文字列が含まれる「テキスト項目」だ。この部分の抽出精度が、クラウドAPI経由で利用する「Claude Sonnet 4.6」相当のモデルと比較して最大10ポイント向上した。

速度面：投機的デコーディングの最適化で速度5倍

　当初、単純に自社環境でSLMをホストした段階では、外部の高性能APIを呼び出すのと同程度の速度しか出ず、月100万枚のトラフィックをさばくための並列処理性能が不足していた。

　この課題を打破したのが、AWSのチームとの協業だった。両社のチームは1日がかりで推論のボトルネックを解消した。vLLMの機能である「Speculative Decoding」（投機的デコーディング）の仕組みを、今回はあえて「n-gram」を使った軽量な方式に簡略化し、パラメーターを徹底的にチューニングした。投機的デコーディングは、後に続く複数のトークンを先回りして予測し、本体のモデルでまとめて検証することで生成を速める手法だ。予測には通常、小型の補助モデルを使うが、n-gram方式では入力テキストや生成済みのテキストに現れた文字列の並びを手掛かりに予測する。これにより、サーバ（GPUインスタンス「Amazon EC2 G6e」）の性能を最大限に引き出し、クラウドAPI経由で利用する「Claude Sonnet 4.6」相当のモデルと比較して5倍の高速化を実現した。

コスト面：外部API利用から自社ホストへの転換で50分の1に圧縮

　木佐森氏によると、「50分の1」というコスト削減は課金体系の違いによるものだ。外部APIがリクエスト数に応じた「従量課金」でトラフィックに比例して費用が増えるのに対し、自社ホストはサーバの起動時間に応じた「時間課金」だ。月100万枚ほどの膨大かつ安定したトラフィックがある環境では、インフラを自社運用し、処理能力の限界までリクエストを詰め込む方が大幅に低コストになるという。

　木佐森氏は、多くの企業が自社運用に踏み切れない背景には、コスト見積もりの「不確実性」があると指摘する。

　「サーバ代金は事前に計算できますが、処理速度である『スループット（1秒当たりの処理トークン数）』は動かすまで分かりません。そのため、試作段階でスループットの実測値をいち早く計測することが重要です。これが分かれば必要なサーバ台数や時間を逆算でき、正確な運用コストを弾き出せます。結果として、外部APIの利用を続けるか自社運用へ投資するかを、数式に当てはめるだけでロジカルに判断できるようになります」（木佐森氏）

モデルはすぐ古くなる　本番で問われる「評価」の仕組み

　freeeでは、SLMの挙動を管理・分析するためのツールとして、オープンソースのLLMエンジニアリングプラットフォーム「Langfuse」を導入している。本番環境で何らかのエラーが発生した際、Langfuseを活用することで、どのようなプロンプトが投入され、AIがどう出力したのかを1件ずつ詳細に追跡・分析できる。

　「オフラインのテストで問題なくても、実際のリアルな帳票データに直面すると、想定外の挙動を示すことは珍しくありません。Langfuseでエラーの原因を即座に特定し、効率的にフィードバックできる仕組みが運用の成否を分けます」（木佐森氏）

　さらに同氏は、急激な技術進化を踏まえ、これからSLMに取り組む企業にとって最も重要になるのは「評価改善ループ」の仕組み化だと付け加えた。

　「昨日開発したモデルやプロンプトが、一瞬でデッドコードになるようなスピード感の中に私たちはいます。モデルが進化し続ける中、自社に『このタスクにおける正解はこれだ』という厳密な評価基準がなければ、新しいモデルへの乗り換えや追従は難しいでしょう。リリースして終わりではなく、常に評価し、改善し続けるループを組織で回すことが重要です」（木佐森氏）

置き換えの目安は「Claude Haiku 4.5で解けるか」

　木佐森氏は、freeeが見据えるバックオフィス領域におけるAI活用の未来像を語った。

　キーワードとして掲げたのは、「Done by you」から「Done for you」へのシフトだ。利用者が自ら作業する形から、AIが利用者に代わって作業を完了させる形へ変えていくことを指す。精度と体験の改善を積み重ねることにより、将来的には「領収書・決済明細・経費規定、税法などを基に自動で申請する」「証憑（しょうひょう）を集めたら試算表を提供する」「情報が簡単に集まり、給与計算とそのチェックまで自動で完結する」という世界の実現を目指しているという。

　最後に木佐森氏は、同プロジェクトから得られた学びを、タスクとコスト、運用の面から紹介した。

　「SLMの導入は、汎用的なLLMをそのまま置き換えるものではありません。特定の出力を得るためにタスクを絞り込み、そこに最適化していくことが成功の鍵です。一つの目安として、現時点（編注：2026年6月時点）で軽量モデルである『Claude Haiku 4.5』クラスでコンスタントに精度よく解けるレベルのタスクであれば、現在の8BクラスのSLMに置き換えて十分に勝負できると考えています。また、運用コストの見積もりにおいて最も重要なのは『スループット』であり、これさえ実測できればコストは自ずと決まります。さらに運用面においては、SLMはモデル開発ではなく、評価や監視、改善を含む『本番システム開発』そのものです。リリースして終わりにせず、その後の評価や改善のループを回し続ける体制を整えることが大前提となります」（木佐森氏）

　自社のタスクは、軽量モデルで安定して解けるところまで絞り込めているかどうか。「Claude Haiku 4.5」クラスで安定して解けるタスクなら8BクラスのSLMに置き換えられるという木佐森氏の目安は、外部APIを使い続けるか自社運用へ投資するかを判断する最初の物差しになるだろう。

本稿は、Amazon Web Services（AWS）が主催したイベント「AWS Summit Japan 2026」（開催日：2026年6月25〜26日）でfreeeの木佐森慶一氏（AIプロダクトマネージャー）が「freee の月 100 万件 AI-OCR ：汎用 LLM の壁を越える独自 SLM の開発と運用」をテーマに講演した内容を編集部で再構成したものだ。