AIを導入した。でも、本当に成果は出ているか?OpenAI「AI時代のスコアカード」から考える、AI投資を測る6つの指標
企業で生成AIの導入が進むと、さまざまな数字が報告されるようになります。
「何人にアカウントを配布したか」
「週に何人が利用したか」
「何回プロンプトを送ったか」
「どれだけトークンを消費したか」
これらは、導入や利用の状況を知るうえでは必要です。
ただし、利用量が増えたことと、会社の仕事が速く、正確に、低コストで進んだことは同じではありません。AIの出力が増えた一方で、人間による確認、修正、手戻りも増えている可能性があります。
2026年7月17日、OpenAIは「A scorecard for the AI age」を公開しました。著者は同社CFOのSarah Friar氏です。記事が提示した中心的な考え方が、Useful Intelligence per Dollar――1ドル当たりに得られる有用な知能・成果です。案を一文で表すと、次のようになります。
AI投資は、どれだけAIを使ったかではなく、どれだけ重要な仕事を完了し、その成果を得るために総額いくらかかったかで測るべきである。
私は、この方向性には強く賛成します。
一方、企業が実際に使う評価制度へ落とし込むなら、OpenAIのスコアカードをもう一段拡張する必要があります。
AIが成果物を生成した時点ではなく、その成果が品質基準を満たし、人間に受け入れられ、後工程でも問題なく使われ、事業成果へつながったところまで確認しなければ、見かけ上の生産性向上に惑わされるからです。
この記事では、OpenAIが示した4つの評価軸を整理し、関連研究による支持と反証を確認します。そのうえで、企業が1つの業務から使い始められる6つの評価指標へ再構成します。
OpenAIは、AIの評価単位を「利用」から「完了した仕事」へ変えた
これまで企業向けソフトウェアは、主に購入ライセンス数、アクティブユーザー数、契約更新率などで評価されてきました。
しかしOpenAIは、AIの価値を理解するには、導入や利用ではなく、AIによって完了した仕事を見る必要があると述べています。な成果です。
AIが解決を支援した顧客問い合わせ
AIが支援し、テストを通過したコード変更
正確かつ期限内にレビューされた契約書
AIによって人間へ戻された時間
適切な情報が与えられたことで改善した意思決定
トークンや回答は、それ自体では業務成果ではありません。
顧客の問題が解決された。コードがテストを通過した。契約上の論点が担当者へ渡った。判断に必要な情報がそろった。
そこまで進んで初めて、AIの出力が仕事へ変換されます。
OpenAIが提示した評価軸は、次の4つです。
AIは重要な仕事をどれだけ完了したか
成功した仕事1件には、実際いくらかかったか
AIの結果をどの程度信頼して利用できるか
利用が拡大するほど、1ドル当たりに得られる価値は増えているか
OpenAIは、最初から全社共通の巨大なKPIを作るのではなく、まず1つのワークフローを選び、「完了とは何か」を定義し、実際に仕事が行われるシステムで測ることを勧めています。Iの変更ではありません。
AIそのものを評価するのではなく、AIを含む業務システム全体を評価するという転換です。

安いモデルが、安い成果を作るとは限らない
AIサービスを比較するとき、入力・出力トークンの単価や月額料金は分かりやすい指標です。
ただし、モデル単価が低いことと、仕事を完了するコストが低いことは同じではありません。
安価なモデルを使っても、要求水準へ到達するまでに、
指示を何度も修正する
複数回生成する
人間が長時間レビューする
誤りを修正する
別のAIで再確認する
最初から作り直す
必要があれば、最終的な総コストは高くなります。
反対に、1回当たりの利用料が高いモデルでも、少ない試行で品質基準を満たし、人間のレビューや手戻りが減れば、合格成果1件当たりでは安くなる可能性があります。
OpenAIが提案する「成功タスク当たりコスト」は、概念的には次のように表せます。
成功タスク当たりコスト
= AI利用料+人間の操作時間+レビュー時間+再試行費+修正費
÷ 品質基準を満たしたタスク数
重要なのは、分母を「生成した件数」ではなく、品質基準を満たした件数にすることです。
提案書を100本生成しても、社内基準を満たしたものが20本しかなければ、100本で割ってはいけません。残り80本の確認や廃棄に使った時間も、AI投資のコストです。
OpenAIはGPT-5.6のSol、Terra、Lunaという3階層についても、固定的な性能ランクではなく、業務全体の経済性に基づいて選択すべきだと説明しています。
同社はGPT-5.6 Solについて、特定のコーディング評価で、比較対象モデルより少ない出力トークンで高いスコアを得たと報告しています。ただし、これはOpenAI自身が選択したベンチマーク、設定、価格条件に基づく製品比較です。自社業務で同じ優位性が再現するとは限りません。適モデルは、公開ランキングだけでは決められません。
同じ業務、同じ入力、同じ品質基準で実行し、AI料金だけでなく、人間の確認時間と修正時間まで含めて比較する必要があります。
AIによる生産性向上は実在する。ただし、効果は業務ごとに不均一である
生成AIによる生産性向上を示す研究は複数あります。
顧客サポート担当者5,179人を対象にした研究では、生成AI支援を利用できた担当者は、1時間当たりの問題解決数が平均14%向上しました。特に、経験や技能が低い担当者では34%の改善が確認される一方、熟練者への効果は限定的でした。
タント758人を対象にした実験では、AIの能力範囲内にある18のタスクについて、AI利用者は平均12.2%多くのタスクを完了し、25.1%速く、品質も有意に高い成果を出しました。、「AIを導入すれば生産性は上がる」と結論づけたくなります。
しかし、同じBCG研究では、AIの能力範囲外にある複雑な経営タスクについて、AI利用者はAIを使わなかった人より、正解を出す確率が19パーセンテージポイント低くなりました。概念が、Jagged Technological Frontier――ギザギザした技術的境界です。
AIが得意な仕事と不得意な仕事は、難易度順にきれいには並びません。一見似た2つの仕事でも、一方では人間を大きく助け、もう一方では説得力のある誤答によって人間を間違った方向へ導く場合があります。
したがって、
営業業務ならAIが有効
コーディングならAIが有効
若手ならAIが有効
高性能モデルならAIが有効
といった職種やモデル単位の判断は粗すぎます。
評価するときは、少なくとも次の単位まで分解する必要があります。
誰が、どの業務の、どの工程で、どの情報を渡し、どの品質基準と確認方法でAIを使うのか。
AIの生産性は、モデル単独の属性ではありません。
業務、利用者、入力情報、ツール、工程、評価方法を組み合わせた結果です。

「速くなった気がする」と「実際に速くなった」は違う
AI導入の評価で特に注意したいのが、利用者の自己申告です。
METRは2025年、経験豊富なオープンソース開発者16人を対象に、本人たちが長期間関与している大規模リポジトリの実務タスク246件を、AI利用可・不可へ無作為に割り付けました。
その結果、当時のAIツールを利用できた条件では、タスクの完了に平均19%長い時間がかかりました。
参加者は実験前には、AIによって24%速くなると予測していました。実験後にも、実際には遅くなっていたにもかかわらず、20%速くなったと自己評価していました。を「AIは熟練開発者を遅くする」と一般化してはいけません。
対象者は16人で、本人が熟知する成熟したコードベースを扱っていました。利用されたAIツールも2025年前半時点のものです。METR自身も、この研究がソフトウェア開発全般や将来のAIツールを代表するとは主張していません。
2026年2月、2025年後半のツールを使った追試について、生産性向上を示唆する生データはあるものの、AIを使わない条件を嫌う開発者や、AIが有効そうなタスクが実験から抜ける選択バイアスが大きく、現在の効果量を信頼できる形では推定できないと報告しました。結論は、「AIは速くない」ではありません。
AIの効果は急速に変化し、業務条件によって異なる。だからこそ、利用者の体感だけでなく、自社業務で実測する必要がある。
AIは、ゼロから考える負担を減らし、作業を心理的に楽にすることがあります。それ自体にも価値はあります。
ただし、
AIを使うと楽になった
AIが便利だと感じた
今後も使いたい
数時間削減できたと思う
という回答を、そのまま処理速度や投資対効果へ置き換えてはいけません。
満足度、心理的負担、利用継続意向と、実測した所要時間、品質、コストは別の指標として管理する必要があります。
成果物が完成しても、後工程で負債を生むことがある
OpenAIの「成功タスク当たりコスト」は、レビュー、再試行、手戻りを含めている点で優れています。ストは、タスクが一度完了した後に現れることがあります。
例えば、若手担当者がAIを使い、以前の3倍の速度で営業提案書を作れるようになったとします。
しかし、その結果として、
上司のレビュー時間が増える
数字や顧客情報の確認が増える
顧客ごとの理解が浅くなる
類似した提案が量産される
修正指示や差し戻しが増える
誤った提案による信用リスクが高まる
のであれば、個人の生成速度は上がっても、組織全体の価値は下がる可能性があります。
同じ問題はコード、契約書、調査レポート、会議記録などでも起こります。
したがって、実務では「成功タスク当たりコスト」を、次のような総ライフサイクルコストへ広げるべきです。
総ライフサイクルコスト
= 生成・実行コスト
+ 検証コスト
+ 修正・承認コスト
+ 下流工程の手戻り
+ 保守コスト
+ 失敗時の期待損失
分母も「一度合格した成果」ではなく、受け入れられ、後工程でも維持された成果に近づける必要があります。
例えばコードなら、生成直後にテストを通っただけでなく、レビュー、統合、本番運用、後日の保守まで含めて評価します。
ただし、すべての業務で長期間追跡する必要はありません。
誤りの影響が小さく、出力が使い捨てに近い業務では、短い評価期間で十分です。影響が大きく、後工程や保守が続く業務ほど、評価範囲を長くします。
信頼性とは、正解することだけでなく、危険なときに止まれること
OpenAIは、AIの成果を次の3つに分けて記録することを提案しています。
Ready to use:そのまま品質基準を満たした
Needs correction:再試行または人間の修正が必要だった
Needs escalation:人間が引き取って完了する必要があった
これは、単純なモデル正解率より実務的です。
AIが一部を正しく答えたかではなく、人間の仕事をどの程度本当に減らしたかが分かるからです。務システムとして利用する場合、もう1つ区別すべき状態があります。
Undetected unsafe failure:問題があるのに、AIも人間も異常へ気づかず、そのまま後工程へ進んだ
最も危険なのは、システムが明確に停止する失敗ではありません。
取得したデータの一部だけが古い
必要な添付資料が1件欠けている
表の途中だけが読み取れていない
APIは成功を返したが、内容に欠損がある
引用先は存在するが、主張を支えていない
数字の単位や桁だけが違う
といった、一見正常に見える失敗です。
したがって、企業が見るべきなのは単なる正解率やエラー率ではありません。
危険な失敗を検知し、処理を止め、必要な情報とともに人間へ戻せたか。
を測る必要があります。
なお、検知できなかった失敗の総数は直接観測できません。
そのため、抜き取り監査、既知の異常を混ぜたテスト、後工程の差し戻し、インシデント調査などを組み合わせて推定します。

Human in the Loopだけでは足りない。Evidence in the Loopが必要になる
AIによる操作や判断が増えると、「最後に人間が承認すれば安全」と考えたくなります。
しかし、人間の承認が形式的なチェックになれば、品質保証としては機能しません。
人間へ単に「承認しますか」と尋ねるのではなく、判断に必要な証拠を提示する必要があります。
例えば、次のようなものです。
参照した一次資料と該当箇所
入力データの件数、欠損、更新日時
実行した処理と変更差分
テスト結果
計算過程
例外ケース一覧
未確認事項
AIが処理を止めた理由
人間へ戻した条件
ロールバック方法
人間はAIを漠然と信用するのではなく、証拠を見て採否を判断します。
私は、これをEvidence in the Loopと捉えています。
もちろん、AIの全処理を大量に表示すればよいわけではありません。監視情報が多すぎれば、確認者は読み切れず、承認が形骸化します。
各承認者が何を判断するのかを定め、その判断に必要な証拠だけを、適切な粒度で提示する設計が必要です。
自律性が高いほど価値が高い、とは限らない
モデルが長い仕事を扱えるようになると、企業は1つのAIエージェントへ多くの工程をまとめて任せたくなります。
しかし、長い仕事には、小さな失敗が蓄積し、途中経過を追跡しにくくなる問題があります。
ここで必要なのは、一括委任か人間による全面作業か、という二択ではありません。
短く検証可能な工程へ分割し、各工程で状態と証拠を確定し、失敗した場所だけ局所的に戻せる構造にする。
例えば、調査から記事公開までを1つの指示で任せるのではなく、
調査対象と判断基準を確定する
一次資料を収集する
主張と出典を結び付ける
反証と適用限界を確認する
原稿を作る
数字と引用を再検証する
人間が公開を承認する
と分けます。
すべての仕事を細かく分割すればよいわけでもありません。
単純で可逆な業務に大量のゲートを設ければ、AIによる速度向上を相殺します。
工程の長さ、確認の強さ、人間承認の有無は、次の条件に応じて変えるべきです。
誤りの発見しやすさ
失敗時の損失
操作の可逆性
外部への影響
機密性
必要な説明責任
AIの実測成功率

OpenAIの4つの問いを、実務では6つの指標で測る
ここまでを踏まえると、OpenAIの4つの評価軸は、企業のAI投資評価にとって有力な出発点です。
実務では、次の6指標へ落とし込むことを勧めます。
1.品質基準を満たした業務完了数
AIが何件出力したかではなく、定義された完了条件と品質基準を満たした件数です。
例えば、
顧客の問い合わせが解決された
コードがテストとレビューを通過した
契約書の論点が期限内に抽出された
会議の決定事項、担当者、期限が台帳へ登録された
という状態です。
2.受け入れ成果当たりの総ライフサイクルコスト
AI利用料だけでなく、人間の準備、操作、確認、修正、承認、下流手戻り、保守、失敗対応まで含めます。
すべてを厳密な金額へ変換できない場合は、少なくともAI料金と人間時間を別々に記録します。
3.そのまま利用・要修正・要エスカレーションの割合
AIが人間の仕事をどの程度減らしたかを測ります。
最終的に完成したかだけではなく、どの程度の人間介入が必要だったかを区別します。
4.危険な失敗を検知して止められた割合
根拠不足、入力欠損、権限外操作、異常値、処理不能を検知し、自動処理を止められたかを確認します。
観測できない失敗があるため、抜き取り監査や既知異常を使ったテストと組み合わせます。
5.下流工程への影響
AIを導入した工程だけでなく、その後の担当者や部署への負担を確認します。
上司や専門家のレビュー時間
差し戻し・再作業率
保守工数
顧客からの問い合わせ
熟練者への負担集中
後工程の待ち時間
局所的な速度向上を、組織全体の生産性向上と混同しないための指標です。
6.最終的な事業・顧客成果
業務完了は、事業成果の代理指標にすぎません。
提案書が完成しても、商談化率、受注率、粗利、顧客満足が悪化すれば、事業価値は増えていません。
すべてのAI活用を売上へ直接結び付ける必要はありません。対象業務に応じて、次のような成果を選びます。
売上・粗利
リードタイム
顧客満足
ミス・事故
解約・再問い合わせ
従業員負担
意思決定の速度と質
リスク回避
AI導入の初期段階では、業務完了と品質までを中心に測っても構いません。
ただし、継続・拡大・高額投資の判断では、最終成果との接続を確認する必要があります。

6指標は、必ずAIなしのベースラインと比較する
AIを使って100件の仕事を完了したという数字だけでは、AIの価値は分かりません。
比較すべきなのは、
AIを使わなかった場合、同じ人員、時間、品質条件で、どれだけの成果が出ていたか。
です。
これは反実仮想の問題です。
AI導入後に成果が増えても、原因は別にあるかもしれません。
人員が増えた
業務量や難易度が変わった
担当者が習熟した
テンプレートを改善した
繁忙期が終わった
市場環境が変わった
可能であれば、次のいずれかを使います。
導入前後を同じ条件で比較する
AI利用あり・なしのタスクを比較する
同じ担当者が条件を交互に変える
複数チームを比較する
タスクを無作為に割り付ける
品質評価者へAI利用条件を知らせない
大規模な実験が難しくても、一定数の類似タスクをAIあり・なしへ分けるだけで、自己申告より信頼性の高い判断材料を得られます。
ただし、AIによって従来は不可能だった仕事が可能になる場合、従来方式との時間比較だけでは価値を捉えられません。
その場合は、
新たに実行可能になった業務
意思決定へ追加された情報
従来は見逃していたリスク
新しく対応できた顧客
作成できるようになった製品やサービス
も別枠で記録します。
最初から全社ROIを求めず、1つの業務から始める
この評価体系を見て、「測定項目が多すぎる」と感じるかもしれません。
その懸念は妥当です。
全業務、全社員、全モデルについて、最初から精密な投資対効果を計算しようとすると、測定そのものが新しい負担になります。
OpenAIが述べるように、最初は1つのワークフローから始めるのが現実的です。らタスク台帳を作る業務なら、次のように設計できます。
完了条件
決定事項、担当者、期限、未決事項が所定の台帳へ登録された。
品質基準
元の会議内容と一致し、担当者・期限の誤りがなく、未確定事項を確定情報として扱っていない。
ベースライン
AIを使わない場合の所要時間、誤り件数、上司の確認時間。
AI利用後
AI利用料、担当者の操作時間、修正時間、上司の確認時間、完了件数。
信頼性
そのまま利用できた割合、修正が必要だった割合、人間が引き取った割合。
下流影響
登録漏れ、担当者からの問い合わせ、期限超過、再確認の発生。
この測定を一定期間行い、
品質を維持しながら時間とコストが下がった
修正率が高く、上司の負担が増えた
定型的な会議には有効だが、複雑な会議では失敗した
高性能モデルの方がAI料金は高いが、総コストは低かった
といった結果を確認します。
そこで初めて、対象を拡大するか、工程を修正するか、利用を限定するか、停止するかを判断できます。
AI研修も「受講」ではなく「業務完了」で評価する
この考え方は、AIシステムだけでなく研修にも当てはまります。
研修の効果を、
受講者数
修了率
満足度
プロンプト作成数
ChatGPTの利用回数
だけで評価すると、企業側は最終的な投資効果を判断できません。
研修前に、対象業務の完了条件を定義する必要があります。
例えば、
会議録:決定事項、担当者、期限が台帳へ登録された
営業提案:社内品質基準を満たす提案書が完成した
調査:重要主張と一次資料が結び付いたレポートが完成した
看護記録:音声から所定形式の下書きが作られ、人間が確認した
開発:テストとレビューを通過した変更が完成した
という状態です。
そのうえで、研修前、研修直後、一定期間後に、所要時間、品質、修正率、利用定着を測ります。
これにより研修を、「AIの使い方を教えた活動」ではなく、仕事の完了能力と業務システムを改善する投資として評価できます。
私が考える、AI時代の本当のスコアカード
OpenAIは、AI時代の評価単位を「利用」から「完了した仕事」へ変えました。
これは非常に重要な前進です。
ただし、企業が最終的に測るべき対象は、AIが単独で完了した仕事ではありません。
人間とAIで構成された業務システムが、従来より良い成果を、低い総コストと許容可能なリスクで、継続的に生み出したか。
これが本当の評価対象です。
概念的には、AI投資による純増価値を次のように考えられます。
AI純増価値
= AI導入によって改善した成果
- AI利用、人間作業、修正、保守、失敗リスクの総コスト
ただし、意思決定の質、従業員の学習、顧客信頼、組織の独自性、将来の業務能力など、短期的な金額へ変換しにくい価値もあります。
すべてを1つの金額や総合スコアへ無理に統合する必要はありません。
経済性、品質、信頼性、下流負担、リスク、事業成果を分けて確認し、どの指標を優先するかを業務ごとに決める方が実用的です。
最もAIを多く使う企業が、最も強い企業になるとは限りません。
強くなるのは、
AIに任せる仕事
人間が保持する判断
合格とする品質基準
確認すべき証拠
自動実行を止める条件
失敗時に戻る方法
人間の学習として残す領域
を正確に設計し、実測結果をもとに更新できる企業です。
まず、自社で頻繁に行われている1つの業務を選んでください。
そして、「AIを何回使ったか」ではなく、次の問いから始めることを勧めます。
この仕事は、何をもって完了とするのか。
品質基準を満たした成果1件を作るために、本当はいくらかかっているのか。
AIを使わなかった場合と比べて、何が実際に良くなったのか。
その改善は、後工程や顧客にとっても価値になっているのか。
そこから初めて、AI投資を評価できるようになります。
関連記事
「AIシステムは、公開してから何を評価すべきか?品質・費用・事故・変更を管理する継続運用の11要素」
公開後の品質、費用、例外、事故、変更、停止・廃止までを継続的に評価する方法を詳しく整理しています。
「AIを導入した先で、経営は何を変えるべきか?事業・組織・人材を再設計するAIネイティブ経営の10領域」
AI投資の評価を、業務単位から事業・組織・人材・経営全体の再設計へ広げたい場合に参考になります。
企業で実行する場合
この記事で扱った評価方法を、自社のAI研修、業務設計、AIエージェント開発、導入後の改善運用へ落とし込みたい場合は、支援内容を「生成AIを導入した。でも、業務は変わらなかった。そんな企業へ研修から業務設計・開発・改善運用まで支援します」にまとめています。
出典・参考資料
OpenAI, “A scorecard for the AI age,” 2026年7月17日
Erik Brynjolfsson, Danielle Li, Lindsey R. Raymond, “Generative AI at Work”
Fabrizio Dell’Acqua et al., “Navigating the Jagged Technological Frontier”
Joel Becker et al., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”
METR, “We are Changing our Developer Productivity Experiment Design,” 2026年2月24日
いいなと思ったら応援しよう!
社会問題×マーケティングが好き / ㍿小さな一歩(前澤ファンド出資先)で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。