LegalOn、タスク振り分けでCodexの推定コストを65％削減

OpenAIの顧客事例によると、LegalOnはGPT-5.5を使う場合と比べ、Codexの推定日次コストを約65％削減した。開発速度と品質も維持したとしている。モデル選択、機能制限、事業ごとに異なる予算配分を組み合わせた結果だ。

3つのモデルが難易度に応じて仕事を分担した

LegalOnは、すべてのタスクを最上位の構成に送る運用をやめた。GPT-6 Lunaは明確な要件に沿った実装、日常的な自動化、簡単な分析を担う。GPT-6.1 Solは標準的な設計、分析、文書作成を扱う。GPT-6 Astraはアーキテクチャ、高度な判断、ほかのエージェントの統括を担当する。

Fast modeも標準では無効にし、申請があった場合だけ提供する。月間上限は部門と個人に設定した。既存事業には最大20％のコスト効率改善を求める一方、新規事業には実験を促すため余裕のある予算を与えた。

Coding agentの支出は運用設計の問題になった

重要なのはAstra、Sol、Lunaという名称ではない。安価な定型変更と、失敗すればreview、テスト、本番運用の負担が増える仕事を分ける必要がある。安い実行でも修正が一巡増えれば、結局は高くつく。

LegalOnが示したのは、万人向けの割引ではなく社内の運用モデルだ。誰かが継続的にモデルを試し、振り分けルールを書き、上限を調整しなければならない。token数だけを測り、採用された変更を見なければ、APIの節約分は人間の作業に消える。

65％という数字はベンダー側の測定に依存する

OpenAIは、絶対額、開発者数、タスク量、観測期間を公表していない。速度と品質を維持したことを示す指標もない。比較対象はGPT-5.5利用時の推定日次コストであり、同等期間の監査済み請求額ではない。

review時間、差し戻された不具合、テスト成功率、採用された変更のデータがなければ、コストの一部がモデルから開発者へ移っただけか判断できない。この事例の手法は有用だが、65％をそのまま他社のbenchmarkにはできない。

採用された変更の単価が本当の節約を決める

次に見るべき指標は、採用された変更やリリースした機能1件あたりのコストだ。LegalOnはこの測定をまだ構築中としている。日次支出だけでなく、cycle time、review負荷、手戻り、リリース後の障害も並べる必要がある。

軽量モデルでもこれらの指標が維持され、最上位モデルが必要な場面だけで使われるなら、routingは再現可能な運用手段になる。手作業の確認が増えるなら、残るのは整然と並んだtokenの請求書だけだ。

Lilithの判定

LegalOnは最上位モデルを司令室に置き、軽量モデルを日常業務へ回した。終業時に開発者の机へ修正の山が残らないなら、その節約は本物だ。