そろそろ実務で使えるローカルLLM

こんにちは。Algomaticの組織変革本部でAIエンジニアをしている伊藤です。

本記事は 『Algomaticアドベントカレンダー 第2弾 - Algomaticの現在地をみんなで紹介しよう！』 の5日目です。

メンバーそれぞれが自分の仕事や関心領域を語るリレー企画です。Algomaticがいま何をやっているのか、どんなメンバーがいるのかを知っていただけたら幸いです。

昨日の記事はこちらです。

tech.algomatic.jp

本日はエンジニアからの発信として、最近注目度が上がり始めているローカルLLMについて、検証してみた内容をお届けします。

背景

企業の業務環境では、情報漏えい対策やコンプライアンスの観点から、インターネット接続がプロキシ経由に限定されていたり、外部サイト・外部APIがホワイトリスト制になっていたりするケースが多くあります。

その結果、クラウドLLMやSaaSに自由に通信できず、オフライン／閉域網でも動くローカルLLMがAIを利用するための現実的な選択肢になります。

ただ、これまでは「LLMがローカルで動く」ことと「LLMが仕事で使える」ことの間に距離がありました。ローカルで利用可能な計算リソースで動くLLMは、OpenAIやAnthropicのような最先端LLMと比べると、複数ファイルにまたがる作業、ツールの利用、失敗からのリカバリーといった実作業での性能差が目立っていたためです。

ところがこの数ヶ月で、比較的小規模な計算リソースでも、コーディングエージェントとしてこれまでより高い性能を発揮できるモデルが相次いで登場しました。

そのひとつがDeepSeek V4 Flash 0731です。

DeepSeek V4 Flash 0731は、ソフトウェア開発エージェントの実力を測るベンチマークなどで、最先端LLMに肉薄する水準の結果を示しています。

ただし、比較的小型のこのモデルでも、限られた計算リソース下では量子化などの軽量化が必要です。軽量化による性能トレードオフが、実務でどの程度効いてくるかがポイントになります。

そこで本記事では、DeepSeek V4 FlashをDGX Spark 1台で動かせるように量子化して、実案件に近い業務アプリをどこまで作れるかを検証します。

検証環境

DeepSeek V4 Flash 0731の総パラメータ数は、公式モデルカードの記載で304BのMoEモデルです。公式モデルカードの実行例は複数GPUが前提のため、128GBの統合メモリを持つDGX Spark 1台に収めるには量子化が必要です。したがって今回の評価対象は、フル精度のモデル単体ではなく「量子化GGUF＋DwarfStar＋DeepSeek Harness＋DGX Spark 1台」の構成全体です。

課題：請求・入金消込ダッシュボード開発

今回与えた課題は、請求書CSVと入金CSVを読み込み、請求ごとの入金状況を集計するWebアプリです。

仕様として次を指示しました。

• 入力データの検証：引用符で囲まれたカンマ・エスケープされた引用符・改行を含むCSVを読めること。必須項目の欠落・不正な日付・不正な金額は集計から除外すること。完全な重複行は1件として扱い、同じIDで内容が異なる行はそのIDごとすべて除外すること。除外理由は警告として画面に表示すること

• 状態判定：請求ごとに入金を合算し、過入金 → 入金済み → 期限超過 → 一部入金 → 未入金の優先順位で状態を1つに決めること。基準日当日は期限超過にしないこと

• 集計：有効な請求の総額、請求に紐づく入金総額、請求額を上限として充当した金額、未収残高、期限超過請求の残額、過入金額、請求に紐づかない未消込入金額の7種類を別々に集計すること

画面にはCSV選択、サンプル読込、リセット、基準日の変更、顧客名・請求ID検索、状態フィルター、請求明細、警告一覧、JSON出力を求めました。

業務ロジックの流れ

内部では、2つのCSVをいきなり合計するのではなく、まず各CSVを検証して有効な行だけを残し、その後に請求IDで照合します。

充当額は請求額を上限とします。たとえば請求額40,000円に45,000円が入金された場合、入金額45,000円・充当額40,000円・過入金額5,000円と3つの値を区別します。残額と過入金額はそれぞれ0円を下限とし、存在しない請求IDへの入金は未消込入金として別枠で合計します。

状態は、入金額と請求額、期日と基準日を次の順に比較して1つに決めます。

この順序により、一部入金済みでも期日を過ぎた請求は「一部入金」ではなく「期限超過」になります。期日が基準日と同じ請求は期限超過にしません。

評価

上記のように、実務に近いそれなりに複雑な業務ロジックを入れたアプリケーションを開発させ、要件を満たしているかを確認しました。

完成したアプリ

今回の検証で完成したアプリは下記の画像のようになりました。上から「入力と操作」「7種類の集計カード」「請求ごとの明細」「取り込まなかったデータの警告」という構成です。

警告欄には、集計から除外した行の元CSVでの行番号と除外理由（不正行・完全重複・ID競合・未消込入金）が表示されます。

初回実行

空のディレクトリから開始し、開発指示は一度だけ送りました。24分46秒で正常終了し、Vite＋React＋TypeScriptによる日本語のWebアプリが生成されました。

実行中、モデルはnpmキャッシュの問題、4件のテスト失敗、TypeScriptのビルドエラーに遭遇し、いずれも自分で出力を読んで修正しました。

最終的に、クリーンな状態からのnpm ci、26件の自動テスト、npm run build、開発サーバーがHTTP 200応答可能な状態の成果物が作成されました。

評価用CSVを読み込ませての検証でも、想定どおりの出力が出ており、ほとんどの要件を満たしていました。

初回としてはかなり良い結果だったと思います。

一方で、ブラウザでの動作確認で次の2件の問題が見つかりました。

• 基準日の変更が反映されない：日付入力欄を2026-08-31から2026-07-01に変えても、Reactの内部状態に反映されず、期限超過の集計と画面下部の基準日表示が古い日付のままだった

• リセット後に集計カードが消える：仕様ではカードを残して全項目0円と表示すべきところ、カード自体が非表示になった

修正指示による再実行

これらのUIの不具合を修正できるか確認するため、再現手順と期待する結果のみを伝えて修正させました。

所要時間は1時間2分36秒で、途中でjsdomを使った一時テストを複数作成してReactの日付入力イベントを調査していました。

最終的な修正内容は、基準日入力にDOMのinput/changeイベントを監視して内部状態へ同期する処理を追加、リセットにはゼロ値の集計を定義してデータがない場合も集計カード・明細表・警告欄を表示する変更、の2点です。

修正後の確認結果は次の通りです。

• 基準日を2026-07-01に変更すると、期限超過が0件・0円になり、画面下部の基準日表示も追従する

• リセット後も7枚の集計カードが表示され、すべて0円になる。明細0件、警告0件

• 既存の自動テスト26件、ビルド、評価用CSVによる検査が引き続き成功する

一度ですべての不具合をなくすことはできませんでしたが、追加指示でバグを修正することができました。

まとめ

今回の記事では、量子化したDeepSeek V4 Flash 0731をDwarfStarとDeepSeek HarnessでDGX Spark 1台上で動かし、請求・入金消込のWebアプリを空のディレクトリから開発させました。

結果としては、初回実行の時点でかなりの品質のアプリができ、追加指示でバグ修正もできました。実用に足る手応えはあったと思います。

インターネットが制限された環境でも、汎用的なコーディングエージェントを使うことが現実的になってきたのではないかと思います。

これまでセキュリティの問題などで諦めていた方も、ローカルLLMを試してみるのはいかがでしょうか。

一緒に働く仲間を募集しています！

ここまで読んでいただきありがとうございました！

Algomaticでは、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも学びや試行錯誤を続けられる仲間を募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！