LegalOn、開発スピードを保ったまま Codex のコストを半減

Published · AI Daily — AI-assisted deep research, methodology & disclosure

LegalOn Technologies は Codex を開発プロセスに組み込み、AID CoE がモデル選択のガイドラインを整備した。エンジニアはタスクの複雑さと開発段階に応じて GPT-6 の Astra と Luna、GPT-6.1 Sol から選び、予算は事業の成長段階に合わせた。見積もり日額コストは65%、成熟領域のコストは20%減り、開発速度は維持された。モデルの階層化と予算管理が重要だと示す事例である。

2026年10月8日、OpenAI は、世界中で「Professional AI」を提供する LegalOn Technologies の導入事例を公開した。同社は Codex を開発プロセスに組み込んだうえで、タスクごとにモデルを使い分け、事業の成長段階に合わせて予算を割り当てることで、見積もりベースの1日あたりコストを65%削減し、成熟した事業領域ではコストを20%削減した。しかも開発スピードは落ちていない。この事例の価値は数字そのものよりも、エージェント型コーディングが組織に浸透した後に必ず直面する問いへの答えを示している点にある。最も高性能なモデルを無制限に使わせれば支出は膨らみ、一律の利用制限をかければ、せっかく得た生産性を手放すことになる。

LegalOn の出発点は、多くの先行導入企業と同じだった。主力モデルである GPT-5.5 の Fast モードを開発者に無制限で提供し、設計、実装、日常業務へと利用範囲を広げていった。この段階で同社は、人と AI の役割分担をどう決めるべきかを、実験を通じて学んでいる。能力の限界を知らないまま制限を設けても適切な方針にはならないため、まず開放して観察するという順序は理にかなっている。しかし、高性能モデルを制限なく使い続ければ、年間予算を超えることは避けられない。コスト管理は経理上の問題から、開発組織自身が解くべき運営上の課題へと変わった。

同社の解決策の前半は、モデル選択の方法論である。社内の AI 駆動開発推進組織「AID CoE」が、モデル選択のガイドラインの整備に着手した。AID CoE はモデルをテストして継続的に監視し、その知見をマネージャーが各チームに共有する。この分担は注目に値する。テストと監視は集中させて根拠の一貫性を保ち、判断は分散させて、各エンジニアが自分で最適なモデルを選べるようにしている。ガイドラインはタスクの種類とモデルを機械的に対応づける規則集ではなく、個人が素早く適切に判断するための共通の根拠として機能している。 選択肢となったのは、GPT-6 の Astra と Luna、そして GPT-6.1 Sol である。LegalOn はタスクの複雑さと開発の段階に応じて、これらを選び分けた。ここで参照できる原文は、どのモデルをどのタスクに充てるかの対応までは述べておらず、それを推測で補うべきではない。事例が確かに示しているのは原則のほうである。モデルは全社共通の既定値ではなく、タスクごとに決めるパラメータになる。単純な作業に最も高価な能力を使う必要はなく、難しい作業から能力を奪って少額を節約するのも賢明ではない。 解決策の後半は、予算設計である。LegalOn は各事業の成長段階に合わせて予算を整えた。これは、報告されている二つの数字が異なる理由を説明する。成熟した事業領域でのコスト削減は20%であり、全体の見積もり日額コストの削減は65%に達している。成熟した事業は作業が安定していて予測しやすく、節約できる余地が比較的小さい。成長初期の事業は探索と試行が多く、予算の考え方も異なる。支出を成長段階に結びつけることは、AI の利用を全チームに一律に課す共通経費としてではなく、期待されるリターンを伴う投資として扱うことを意味する。ただし、65%は見積もりの日額コストの削減であり、完全な請求サイクルで監査された実績ではない点には注意が必要である。

業界にとっての示唆は三つある。第一に、エージェント型コーディングの競争は、最強のモデルを持つことから、モデルを最も効率よく使うことへ移りつつある。モデルの階層化とタスクのルーティングは、大規模に導入する組織の基本的な能力になる。第二に、有効なガバナンスは技術的なスイッチではなく組織の仕組みである。テスト、監視、ガイダンス、マネージャーによる伝達という循環が、多数の独立した判断を一貫させる。第三に、コストと速度は本質的に対立しない。選択基準が明確であれば、両立は可能である。他のチームが借りられるのは具体的なモデル名ではなく、まず観察し、次に階層化し、事業の段階に応じて予算を配分するという順序のほうだろう。

Sources

FAQ

LegalOn は開発速度を落とさずに Codex のコストをどう下げたのか。

二つを並行して進めた。AID CoE がモデルをテスト・監視してガイドラインを作り、エンジニアがタスクの複雑さと開発段階に応じて GPT-6 の Astra、Luna、GPT-6.1 Sol から選ぶ。加えて予算を事業の成長段階に合わせた。見積もり日額コストは65%、成熟領域は20%減った。

65%という数字は実際の削減額と見てよいか。

そのまま実績とは言えない。原文は見積もりベースの日額コストの削減としており、請求サイクル全体で監査された結果ではない。引用時は「見積もり」を付けるべきである。

他のチームはこの事例から何を学べるか。

学べるのはモデル名ではなく順序である。まず開放して観察し、専任の組織がテストを続け、結果をガイドラインにして各自の判断に委ね、最後に予算を事業の成熟度に連動させる。