[](https://devin.ai/ja)

[](https://devin.ai/ja/blog)

# AIコスト管理へのよりスマートなアプローチ：効率に基づいて利用枠を配分する

Cognition2026年10月19日15分で読めます

一律の利用上限は、AI時代における採用凍結のようなものです。

多くのエンタープライズがAIへの支出を抑えるために一律の上限を導入していますが、これは生産性を制限してしまう大雑把な手段です。AIを最も効率的に使いこなしているエンジニアの足を引っ張る一方で、AIをうまく活用できていないエンジニアには、何を改善すべきかというフィードバックが届きません。

より良いアプローチは、エンジニアリングの効率に基づいて支出を配分し、効率の低いエンジニアには改善のための具体的な提案を示すことです。

これを手作業で大規模に行うことは、これまで困難でした。そこで本日、その助けとなる3つのエンタープライズ向け機能を発表します。

- **Efficiency Scoreは、各エンジニアがどれだけ効率的にDevinを使っているかを評価します。** Devinはセッションごとに、PRを生まない調査や計画のセッションも含めて、そのセッションに相当する生産的なエンジニアリング時間、つまり人間のエンジニアが同じ作業に要したであろう時間を推定します。評価は、直近のセッション全体で支出1単位あたりにエンジニアが得た生産的な時間を反映し、作業量にも小さな比重で加点します。
- **Devin Coachは、プロンプトの実行前にエンジニアへフィードバックを返します。** 曖昧な依頼、単純なタスクへの高コストなモードの使用、ひとつのセッションへの無関係なタスクの詰め込みといった、よくあるミスを指摘し、修正案を提示します。
- **効率に基づく承認は、効率的なエンジニアの上限を自動的に引き上げます。** これにより、管理者のレビュー負担を膨らませることなく、よりきめ細かなコスト管理が可能になります。HealthyまたはSatisfactoryの評価を持つエンジニアが上限に近づくと、Devinは管理者が設定した上限値の範囲内で、その上限を自動的に引き上げます。それ以外のエンジニアのリクエストは、管理者のレビューに回されます。

> Devinのインテリジェントなコスト管理のおかげで、エージェントへの支出が際限なく膨らむのを抑えられています。効率に基づく自動承認によって、管理者の負担は大幅に軽くなりました。パワーユーザーは申請しなくてもより多く使えるようになり、利用が成果につながっていない人がいれば、それに気づいて本人と話し合うことができます。Devin Coachのおかげで、ユーザーがより効率的に使えるようにするためのトレーニングも、規模を拡大しやすくなりました。
>
> Will Laughlin, VP of EngineeringBilt

## エンジニアごとにEfficiency Scoreを付ける

きめ細かな上限を設定するには、各エンジニアが支出に対してDevinからどれだけの成果を得ているかを把握する必要があります。Efficiency Scoreは、各エンジニアの直近のDevin利用を0〜100で評価するものです。スコアは直近のDevinセッションから3つの段階で算出されます。Devinは有用な作業を生み出したセッションを特定し、その作業に相当するエンジニアリング時間を推定し、その時間を効率と作業量の評価に換算して、それらを組み合わせてスコアにします。

#### マージされたPRにつながらない作業も評価する

多くの組織は、AIの成果をマージされたPRで測定しています。このアプローチの限界は、計画、トリアージ、データ分析、調査など、有用な作業の多くがマージされるPRを生まないことです。そこでEfficiency Scoreは、Devinセッションの価値を推定するために私たちが[今年の初めに](https://cognition.com/blog/ai-productivity)導入した指標である「生産的なエンジニアリング時間」をベースにしています。

まず、Devinは各セッションが有用な作業を生み出したかどうかを確認します。PRのあるセッションであれば、そのPRがマージされたことを意味します。PRのないセッションについては、バグのトリアージや分析に関する質問への回答など、Devinがタスクを実際に前進させたかどうかを分類器が判定します。これにより、バグ調査はPRを生まなくても評価されます。

次に、この確認を通過したすべてのセッションについて、同じ作業に人間のエンジニアであれば何時間かかったかを推定します。

私たちはこれらの推定値を、エンジニア自身がDevinセッションに相当するエンジニアリング時間を評価したデータセットと照らし合わせて検証しました。

#### 効率と作業量を組み合わせてスコアにする

Cognitionでは、LLMとクラウドインフラのコストをひとつの単位にまとめたAgent Compute Unit（ACU）で支出を計算しています。スコアは、エンジニアの生産性を2つの観点から捉えます。

- **効率（E）** は、ACUあたりの生産的な時間です。支出が生産的な作業につながっているかどうかを示します。明確なプロンプトを書き、適切に範囲を絞ったタスクを選び、適切なモデルを使うエンジニアは、1 ACUあたりでより多くの生産的な時間を得られます。
- **作業量（V）** は、1日あたりの生産的な時間です。コストに関係なく、エンジニアが全体としてどれだけの生産的な作業を生み出しているかを示します。

目的は、1 ACUあたりで最も多くの成果を引き出すエンジニアにより多くのキャパシティを与えることなので、効率により大きな比重を置いています。エンジニアがどれだけの生産的な作業を生み出しているかも評価したいため、作業量にも点数を与えています。

それぞれの指標は、まず0から1の間の評価値に換算され、値が高くなるにつれて頭打ちになります。そのうえで、2つの評価値を組み合わせてスコアを算出します。

エンジニアの効率の評価値が、その人の基準スコアを決めます。評価値が0.50であれば、基準スコアは50です。作業量は、その基準スコアと100との差の最大5分の1までを上乗せできます。基準スコアが50のエンジニアは作業量によって最大10点、80のエンジニアは最大4点を上乗せできます。

例として、直近200 ACUに基づく4人のエンジニアのスコアを示します。

|              | E（効率）   | V（作業量）  | スコア                                   |
| ------------ | ------- | ------- | ------------------------------------- |
| 標準的なエンジニア    | 0.50（中） | 0.50（中） | 100 × (0.50 + 0.2 × 0.50 × 0.50) = 55 |
| パワーユーザー      | 0.50（中） | 0.95（高） | 100 × (0.50 + 0.2 × 0.95 × 0.50) = 60 |
| 利用量は多いが無駄も多い | 0.27（低） | 0.95（高） | 100 × (0.27 + 0.2 × 0.95 × 0.73) = 41 |
| 慎重で利用量は少ない   | 0.75（高） | 0.17（低） | 100 × (0.75 + 0.2 × 0.17 × 0.25) = 76 |

パワーユーザーと標準的なエンジニアの効率は同じですが、パワーユーザーは作業量が多い分、5点高くなっています。利用量は多いが無駄も多いエンジニアは、作業量ではパワーユーザーと並びますが、効率が低いため20点近く低くなっています。

#### エンジニアに改善の道筋を示す

スコアは全期間の平均ではなく直近の利用を反映するため、初期のセッションがいつまでもエンジニアの評価を下げ続けることはありません。タスクの選び方、計画、モデル選択を改善すれば、今後のスコアは向上します。

エンジニアは、My AnalyticsのSession efficiencyで自分のスコアを確認できます。スコアは4つの評価のいずれかで表示されます。Healthy、Satisfactory、Needs Improvement、そしてデータが不十分な場合のUnknownです。補助的な指標も、スコアの理由を理解するのに役立ちます。1日あたりのマージ済みPR数、マージ済みPR 1件あたりのACU、成果を出したセッション、セッション規模別の消費量です。

![DevinのMy Analytics。利用上限に対するACU消費量と、SatisfactoryのSession efficiency評価が表示されている](https://devin.ai/images/blog/efficiency-based-cost-controls/my-analytics.png)

## Devin Coachで、支出が発生する前にエンジニアを導く

新しいユーザーは、同じいくつかの問題につまずきがちであることがわかってきました。具体的なタスクを達成するには一般的すぎるプロンプト、最も高価なモデルを当然のように選んでしまうこと、ひとつのセッションに無関係な複数のタスクを詰め込むことなどです。こうしたパターンは非常に一貫しているため、トレーニングをプロダクトとして提供できる機会があると考えました。Devin Coachは、プロンプトの実行前にエンジニアへフィードバックを返すため、何度もトレーニングセッションを開かなくても、エンジニアは時間をかけてより良い習慣を身につけられます。

**例：実装前に計画を立てていない**

ユーザーが「従量課金に対応できるよう、課金システムを書き直して」と書いたとします。このようなプロンプトの主な問題は、設計上の大きな判断が未決のまま残されていることです。Devin Coachは、まず計画を立てることを提案します。これにより、実装に費用がかかる前に、エンジニアは誤った前提を修正できます。

**例：タスクに対して高性能すぎるモデルを使っている**

別の例として、ボタンのラベル変更のような単純なタスクでは、Devin Coachが「Switch mode」を提案し、最も高性能で最も高価な選択肢であるUltraを、デフォルトのモードに切り替えるよう促すことがあります。小規模なモデルが進化したことで、多くのタスクではそちらのほうが効率的な選択肢になっています。

| リクエストの例                                               | 提案の種類       | 提案の例                                          |
| ----------------------------------------------------- | ----------- | --------------------------------------------- |
| 課金データのエクスポートに関するセッションに、無関係なダークモード切り替えの依頼が届く。          | 無関係なフォローアップ | 無関係な履歴がセッションのコンテキストに入らないよう、新しいセッションを開始してください。 |
| ひとつのプロンプトに、料金ページのリンク修正とiOSの起動時クラッシュなど、無関係なタスクが混在している。 | 並列化できるタスク   | 完了までの時間を短縮するため、子セッションに分割してください。               |
| 休暇の計画など、明らかに私的な依頼である。                                 | 業務外の利用      | 業務に関係がないと思われるため、このプロンプトは送信しないでください。           |

ノイズの多い提案を避けるため、Coachは小規模なLLM分類器を使って決められた一連の振る舞いをチェックし、プロンプトに問題がなければ何も提案しません。私たちは数百件のラベル付き事例でこの分類器をチューニングしました。その際、良いプロンプトにはCoachが口を出さないケースに重みを置いています。

Devin Coachの分析画面では、ユーザーがどの提案を目にし、受け入れ、却下したかを、受け入れ率、日次の推移、種類別の内訳とともに管理者が確認できます。これはチームが繰り返し起きる問題を特定するのに役立ち、企業のDevExチームや、Cognitionのフォワードデプロイドエンジニアリングチームが、個別に最適化した活用支援セッションを行う際にも利用できます。

![管理者向けのDevin Coach分析画面。表示・受け入れ・却下された提案の数、日次の推移、提案の種類別の内訳が表示されている](https://devin.ai/images/blog/efficiency-based-cost-controls/coach-analytics.png)

Devin Coachが、プロンプトを黙って書き換えることはありません。どの程度介入するかは管理者が選択できます。エンジニアが無視することもできるインライン提案（デフォルト）、指摘を受けた新規セッションのプロンプトを送信する前に確認を必須にする設定、あるいはチェックを一切行わない設定です。

## 効率に基づく承認で上限を自動的に引き上げる

静的な上限を使っているエンタープライズには、通常2つの選択肢しかありません。誰がパワーユーザーなのかを手作業で見極めて多めの利用枠を与えるか、一律の上限を設けてパワーユーザーを制限してしまうかです。私たちは、第3の選択肢として、Devinに効率に基づく承認を組み込みました。Devinは各エンジニアのEfficiency Scoreを使って上限を自動的に引き上げるため、エンタープライズは、レビュー待ちの列を増やすことなく、数百人、場合によっては数千人のエンジニアに個別最適化したコスト管理を広げることができます。

管理者は、Usage policiesで「Approve based on efficiency」を選択し、Devinが自動的に承認できる最大量を設定するだけで、この機能を有効にできます。

![DevinのUsage policies。承認ポリシーがApprove based on efficiencyに設定されている](https://devin.ai/images/blog/efficiency-based-cost-controls/approval-policy.png)

HealthyまたはSatisfactoryの評価を持つエンジニアが上限に近づくと、Devinはリクエストなしで上限を引き上げるため、エンジニアは管理者を待つことなく作業を続けられます。引き上げは管理者が設定した上限値で止まり、組織全体の上限も引き続き適用されます。

エンジニアが上限値を超える量をリクエストした場合、Devinは上限値までを付与し、残りを管理者に回します。リクエストを自動的に却下することはありません。

Needs ImprovementまたはUnknownの評価を持つエンジニアも追加の利用をリクエストできますが、そのリクエストは管理者のレビューに回されます。リクエストをレビューする際、管理者はエンジニアが示した理由とあわせて、その人の効率、モデルの使用比率、消費量を確認できます。これらは、支出を配分するうえで最も重要だとエンタープライズの管理者が私たちに語ってくれた指標です。

![Request additional usageダイアログ。エンジニアがより高いACU上限を理由とともにリクエストしており、その隣に管理者から見たそのエンジニアの利用状況の分析が表示されている](https://devin.ai/images/blog/efficiency-based-cost-controls/request-usage-and-analytics.png)

下のグラフは、異なる企業に所属する実在の2人のエンジニアを追ったものです。2人とも、それぞれのアカウントで最も生産性の高いユーザーのひとりであり、2人とも月間の上限に達しました。手動承認を必須としていた1社目（左）では、管理者が上限を引き上げるまでエンジニアは4日間作業を止められ、その週のマージ済みPR数は通常の3分の1に落ち込んだあと、回復しました。自動承認を有効にしていた2社目（右）では、エンジニアは上限に22回達し、そのたびにDevinが自動的に上限を引き上げました。このエンジニアは開発を止めることなく、期間中に週あたりのマージ済みPR数を30件から80件近くまで伸ばしました。

![グラフ：自動承認により、最も成果を出しているユーザーが作業を止められずに済む。手動承認ではエンジニアが4日間作業を止められた一方、自動承認では上限が22回引き上げられ、マージ済みPR数は増え続けた。](https://devin.ai/images/blog/efficiency-based-cost-controls/auto-approvals-chart.png)

## 最も大きな効果が得られるところに支出を配分する

AIへの投資が拡大するなか、組織が数千人の開発者にわたって支出を効果的に管理するには、より高い精度と自動化が必要です。Efficiency Score、Devin Coach、効率に基づく承認は、組織が一律の上限に頼らずに済むよう支援するためのものです。

今後数か月のうちに、柔軟な予算管理機能を導入する予定です。エンタープライズの管理者は部門のリーダーに予算を割り当て、リーダーはそれをサブチームへの利用上限として配分し、リクエストの承認を担えるようになります。こうした管理機能とあわせて、効率のスコアリングとコーチングの機能も引き続き最適化し、エンタープライズが支出1ドルあたりに得られるエンジニアリングの成果を最大化できるよう支援していきます。

自動承認は、Devin Enterpriseプランをご利用のすべてのお客様に本日からご利用いただけます。お試しになりたい方は、[お問い合わせ](https://devin.ai/contact?utm_source=blog\&utm_medium=referral\&utm_campaign=efficiency-based-cost-controls\&utm_content=end-cta)ください。

目次

[エンジニアごとにEfficiency Scoreを付ける](#エンジニアごとにefficiency-scoreを付ける)[Devin Coachで、支出が発生する前にエンジニアを導く](#devin-coachで支出が発生する前にエンジニアを導く)[効率に基づく承認で上限を自動的に引き上げる](#効率に基づく承認で上限を自動的に引き上げる)[最も大きな効果が得られるところに支出を配分する](#最も大きな効果が得られるところに支出を配分する)