社内ツールやPoC（概念実証）にLLM（大規模言語モデル）を組み込む際、クラウドAPIではなくローカル推論を選ぶ構成が増えています。
Dev.to で公開された個人開発タスク管理アプリ「SlothMode」は、Gemma 3 1B というオープンウェイトモデル（重みが公開され自由に動かせるモデル）を Ollama（ローカルでLLMを動かすためのランタイム）経由で呼び出す構成を採用しています。
小規模な個人開発の事例ですが、ローカル推論基盤を業務システムに組み込む際の監視設計・障害対応を考えるうえで、題材として参考になる構成です。この記事では、クラウド運用の視点からこの構成を読み解きます。
SlothModeのアーキテクチャを分解する
SlothModeは、タスクを細かいステップに分解し、休憩時間も含めたスケジュールを提案するアプリです。
構成はシンプルです。フロントエンドはReact・TypeScript・Vite、バックエンドはExpress（Node.jsのWebフレームワーク）で、タスクの見積もり・分類・計画生成のAPIを公開しています。
注目すべきは、AI（Gemma 3 1B）が担う範囲を意図的に絞っている点です。モデルはタスクの所要時間推定・カテゴリ分類・緊急度判定・サブタスク提案だけを担当します。
実際にカレンダー上のどこに予定を入れるかは、決定的（同じ入力なら必ず同じ出力になる）なスケジューラが計算します。LLMに時刻の生成そのものを任せていません。
この役割分担には理由があります。LLMは自然言語の解釈は得意ですが、日時計算のような厳密なロジックでは誤りを起こしやすいという特性があります。AIの出力を「解釈」に限定し、確定処理は従来型コードに任せる設計は、業務システムへの組み込み方として理にかなっています。
クラウドAPI型とローカル推論型、何が違うか
OpenAIやAnthropicのAPIを使う場合、推論はベンダーのクラウド上で行われます。アプリ側が気にするのはネットワーク越しのレイテンシとレート制限、それにAPIの可用性です。
一方Ollamaのようなローカル推論基盤では、モデルの実行プロセス自体がアプリと同じホスト（またはプライベートネットワーク内のサーバー）で動きます。オンプレでGPUサーバーを運用する構成に近い形です。
この違いは、障害の発生箇所が変わることを意味します。クラウドAPI型では「外部サービスが落ちた」という単一の障害モードに対応すればよい一方、ローカル推論型では自分たちのインフラの問題（GPUメモリ不足、モデルロード失敗、プロセスクラッシュ、ディスク容量不足によるモデルファイル破損など）まで自前で切り分ける必要が出てきます。
SlothModeの実装では「Ollamaまたはモデルが利用できない場合、ルールベースの推定にフォールバックする」という設計が組み込まれています。AI依存部分が落ちてもアプリ全体が止まらないようにする、という考え方自体は、オンプレ・クラウド問わず可用性設計の基本です。
障害の根本原因をどう切り分けるか
ローカルLLM構成でインシデントが起きたとき、原因の層を分けて考える必要があります。
- インフラ層: GPU/CPUリソース枯渇、OOM（メモリ不足によるプロセス強制終了）、ディスクI/O遅延
- Ollamaプロセス層: モデルのロード失敗、バージョン不整合、APIタイムアウト
- モデル出力層: 想定外フォーマットの応答、幻覚（事実と異なる出力）による後続処理の失敗
- アプリケーション層: フォールバックロジックの不具合、バリデーション漏れ
切り分けの第一歩は、Ollamaのログとシステムリソースを分離して見ることです。ollama ps でロード中のモデルとメモリ使用量を確認し、journalctl -u ollama（systemdで動かしている場合）でプロセスレベルのエラーを確認します。
そのうえで、OS側の top や nvidia-smi（GPU使用のモデルの場合）でリソース枯渇の有無を見れば、インフラ起因かモデル起因かの一次切り分けができます。
SlothModeのように「AIが落ちてもルールベースで動く」実装であれば、監視上もう1つ重要な指標が増えます。フォールバックが発動した回数です。
フォールバック発動率が上がっているのに誰も気づかない状態は、見かけ上アプリが動き続けているため障害として検知されにくく、サイレント劣化（気づかれないまま品質が落ちる状態）につながります。
監視設計に落とし込むポイント
ローカルLLMを本番相当の用途で使うなら、最低限次の指標を監視対象に入れておくと安心です。
| 監視項目 | 確認方法の例 | 見るべき兆候 |
|---|---|---|
| 推論レイテンシ | APIレスポンスタイムのログ集計 | 急激な増加や張り付き |
| GPU/CPUメモリ使用率 | nvidia-smi, top, Prometheus Node Exporter | 常時90%超など余裕のない状態 |
| Ollamaプロセスの死活 | systemdのステータス, ヘルスチェックエンドポイント | 再起動の頻発 |
| フォールバック発動率 | アプリログのカウント集計 | 通常時との差分 |
クラウドAPI型であればベンダー側のステータスページやSLA（サービス品質保証）を参照すれば済む部分も、ローカル推論では自分たちで可用性の数字を作る必要があります。既存のPrometheus/Grafanaのようなオンプレ監視スタックに、推論レイテンシとGPUメトリクスを足すだけでも初期の可視化としては十分です。
コスト面で見落としがちな点
クラウドAPI課金はトークン数に応じた従量課金なので、コストの見通しが立てやすい一方、使用量が増えるほど線形に費用が膨らみます。
ローカル推論はGPUサーバーの固定費（電気代・ハードウェア減価償却・運用人件費）が主なコストです。Gemma 3 1Bのような小型モデル（パラメータ数10億程度）であれば、CPU推論や小型GPUでも動作するため、個人開発や小規模な社内ツールでは費用対効果が出やすくなります。
ただし運用担当者が増えるタスクも忘れてはいけません。モデルの更新、Ollamaのバージョンアップ、障害対応の一次切り分けといった作業は、クラウドAPI型であればベンダーに任せられていた部分です。小規模チームでこれを内製する場合、工数として見積もっておく必要があります。
今日確認できること
ローカルLLMをすでに使っている、あるいは検討している場合、次を確認してみてください。
- 使用しているOllamaのバージョンを
ollama --versionで確認し、公式リポジトリの変更履歴と照合する - 推論失敗時のフォールバック処理が実装されているか、コードレビューで確認する
- GPU/CPUメモリ使用率を監視ダッシュボードに追加しているか確認する
- フォールバック発動件数をログから集計できる状態になっているか確認する
これらが未整備であれば、まずはフォールバックの発動ログを残すところから始めるのが手堅い一歩です。
まとめ
SlothModeの構成は個人開発の規模ですが、AIの役割を「解釈」に限定し決定的な処理と分離する設計、そしてモデル不在時のフォールバックという考え方は、業務システムにローカルLLMを組み込む際にも通用する基本です。
- 障害切り分けはインフラ層・プロセス層・モデル出力層・アプリ層に分けて考える
- 監視対象にはレイテンシとリソース使用率に加え、フォールバック発動率も含める
- コストは固定費型になる分、運用工数の内製化も含めて見積もる
まずは手元のOllama環境で ollama ps を叩き、現在のリソース消費状況を確認するところから始めてみてください。