Frugonで自社のLLM費用を診断する——どの呼び出しを安いモデルに回せるか可視化するOSS

経営の意思決定にAIを使い倒している、ひでです。

AimanaVo: https://aimanavo.com/c/hide_ceo

同じ流れの前編で「AIの推論コストが5分の1になった」話をしました。

業界全体の原価は確かに下がっています。

ではその追い風は、自社のAPI請求書にちゃんと反映されているでしょうか。

この記事では、自社のLLM呼び出しを診断して「どの呼び出しを安いモデルに回せるか」を数値で出すOSS、Frugonの位置づけを整理します。

「APIコストが増えている気がする」を数字にできない問題

経営者の視点で見えるのは、月末に届くLLMプロバイダの請求書の合計額だけです。

用途別にいくら、どの呼び出しがどれだけ効いているかは、大抵の場合ブラックボックスになっています。

「増えている気がする」という感覚を持ちながら、その根拠を説明できない。

これが一番まずい状態です。

エンジニアに「安いモデルにしろ」と口頭で指示しても、品質担保の議論に落ちず、結局現状維持で終わる。

指示を出した側も、受けた側も、誰も正解を持っていない。

業界全体の原価は下がっているのに、自社のAPI費用はむしろ増えているという矛盾を解くには、「どこに何を投げているのか」を可視化する道具が先に要ります。

ここを突破する枠組みが今まで欠けていました。

Frugonはその穴を埋めるために作られたOSSです。

Frugonが何をするツールか

Frugonは、自社のLLM呼び出しを記録し、削減シナリオを提示するOSSです。

作者はRodiunさん、ライセンスはMIT、2026年7月時点でv0.2.4、GitHubスターは151ほど。

派手なプロダクトではありませんが、経営判断に使える出力を出してくれます。

GitHub - Rodiun/frugon: Free, local, open-source LLM cost analyzer - see where your LLM bill leaks, on your machine.

Free, local, open-source LLM cost analyzer - see where your LLM bill leaks, on your machine. - Rodiun/frugon

github.com

「呼び出しを記録して、削減シナリオを提示する」2ステップ

動作は2つのコマンドに集約されています。

1つ目がfrugon capture。

ローカルHTTPプロキシとして立ち上がり、アプリからLLMプロバイダへの呼び出しをJSONLに記録します。

呼び出し自体はそのまま転送されるので、既存のアプリ動作には影響しません。

2つ目がfrugon analyze。

溜まったログを読み込んで、月次推定コストとルーティング推奨を出力します。

データは外に出ない設計

READMEには「Your data never leaves your machine」と明記されています。

APIキーは各プロバイダに直接送られ、Frugon側は何も収集しません。

すべてローカル完結です。

社内エンジニアに導入を許可するとき、外部SaaSに通信ログを渡す構成だと稟議が長引きます。

ローカルOSSで完結する設計は、経営者が導入判断をするうえで大きな安心材料です。

対応プロバイダとインストール

OpenAI・Anthropic・Gemini・DeepSeekなど主要プロバイダに対応しています。

インストールはuv tool install frugon、pipxやpipでも入ります。

品質を実測する--measureオプションを使う場合のみ、追加でpip install 'frugon[measure]'が必要になります。

ここは後述します。

次のセクションで、このツールが返してくる出力の「どこを見るか」を整理します。

出力の読み方——経営者が見るべき3つの数字

Frugonのanalyzeが返してくるレポートには複数の指標が並びますが、経営者が最初に押さえるべきは次の3つです。

現在の月次推定コスト

記録された呼び出しから、トークン数×プロバイダ価格表で「実測に近い月次額」を算出してくれます。

請求書には出てこない「どのリクエストが高い」までブレイクダウンされるのが、この数字の意義です。

合計額しか見えない状態から、内訳が見える状態へ。

ここが最初の変化点です。

ルーティング推奨(何%を安いモデルに回せるか)

「現行モデルのまま残すのは何%、安いモデルに移せるのは何%」という配分案が出ます。

READMEに掲載されているデモでは、現行モデル維持が17.8%、安いモデルへの移行推奨が64.4%という比率になっていました。

感覚ではなく数字で配分が出るのは、経営会議に持ち込みやすい形式です。

品質は--measureで実測する

デフォルトの分析では、品質はオフライン推定に留まります。

実際に安いモデルへ切り替える前に品質を確かめたいなら、frugon[measure]を入れて--measureを付けます。

すると自分のAPIキーで候補モデルにサンプリング呼び出しを行い、品質スコアを返してくれます。

診断だけで即切替ではなく、「診断→サンプル検証→切替」の3段構えが安全です。

数字の読み方がわかったところで、実際にどれくらいの差が出るのかを見ていきます。

HNで報告された実例:月$549 → $343(37.4%削減)

READMEとShow HNスレッドで紹介されているデモ数値を引用します。

月$549.46(約8万8千円)のLLM費用が、Frugonの推奨に沿ってルーティングし直すと月$343.91(約5万5千円)まで落ちる、という結果が示されています。

削減額は月$205.55、日本円で約3万3千円、年換算で約40万円弱です(1ドル≒160円換算、2026年7月時点の参考値)。

40万円弱、という数字を一度止まって考えてほしいのです。

エンジニアへの一声と1〜2週間のプロキシ計測だけで可視化できる話が、診断すらせずに放置されている。

原価が下がる業界の流れに乗れているかを確かめないまま、毎年その差額が積み上がっていきます。

この削減額は作者が示したデモであって、自社の結果を保証するものではありません。

同じ37.4%が出るかはFrugonを回してみないとわかりません。

ただし前編で扱った「業界原価が5分の1になった」流れと合わせて読むと、使う側の運用でさらに引き剥がせる余地がここに残っている、という構図は見えてきます。

経営者が明日エンジニアに投げる指示

3ステップで整理します。

指示の1つ目。

開発環境でuv tool install frugonを入れ、既存のLLM呼び出しをfrugon captureのプロキシ経由で1〜2週間流してもらう。

呼び出しは転送されるだけなので、既存アプリの挙動は変わりません。

2つ目。

溜まったJSONLにfrugon analyzeをかけ、月次推定コスト・ルーティング推奨・現行モデル維持率のレポートを経営会議に持ってきてもらう。

数字が出た時点で、「増えている気がする」から「どこを削れるか」に議論の質が変わります。

3つ目。

削減候補が具体的に出てきたら、--measureで品質サンプリングを実施し、既存機能への品質影響を確認してから本番切替を判断する。

コマンドを打つのはエンジニア、ラインを引くのは経営者です。

「このユーザー接点の品質はモデルを落としても許容できるか、できないか」——この問いに答えられるのは経営者しかいません。

ここを棚上げにしたまま指示を出すと、エンジニアは安全側に留まり続けます。

まとめ

Frugonは請求書合計しか見えない状態を抜けるための、最小構成のOSSです。

ローカル完結でリスクは小さく、uvで入れて2コマンドで動きます。

前編で書いた「原価が下がる時代」の追い風を、自社のAPI費で実測する第一歩として、社内エンジニアに導入検討を依頼するタイミングとしては悪くない道具だと思います。