生成AIの業務効果をどう測るか｜「体感で速くなった」を信用せず、時間・品質・手戻り・定着の4軸で導入前後を比べる

生成AIを部署に入れて数か月たつと、推進担当のところに「で、どれくらい効果があったの」という質問が来ます。手元にあるのは、利用者アンケートの「業務が速くなったと感じる」という回答と、ツールの利用回数くらい。これをそのまま経営報告に載せてよいのか、迷う方は多いはずです。

結論から言うと、体感とアンケートだけでは足りません。ただし、統計の専門家がいなくても、対象業務を1つに絞って導入前の数字を先に取っておけば、判断に使える水準の比較はできます。この記事では、非エンジニアの推進担当が明日から回せる簡易な測り方を、時間・品質・手戻り・定着の4軸で整理します。

なぜ体感とアンケートだけでは足りないのか#

体感と実測がずれた実験#

米国の非営利研究機関METRは2025年7月、経験豊富なオープンソース開発者16人を対象にした無作為化比較試験の結果を公表しました。開発者が自分のリポジトリで抱えている実際の課題246件を、AIツールを使ってよい条件と使ってはいけない条件に無作為に割り当て、所要時間を比べたものです。使われたのは主にCursor ProとClaude 3.5/3.7 Sonnetでした。

結果は、AIを使ってよい条件のほうが所要時間が19%長くなった、というものでした。注目したいのは数字そのものよりも、本人の認識とのずれです。開発者は作業前に「AIで24%速くなる」と予想し、作業後も「20%速くなった」と見積もっていました。実測では遅くなっていたのに、本人は速くなったと感じていたことになります。

論文は、画面録画が有効だった一部の課題(74件)について、時間の使い方の内訳も分析しています。AIを使える条件では、自分でコードを書く時間や情報を探して読む時間の割合が減った一方で、AIへの指示、生成の待ち時間、AI出力の確認に時間が使われ、何も操作していない時間の割合もやや増えていました。開発者が採用したAIの生成結果は44%未満で、AIを使える条件の録画(44件)に限ると、AI出力の確認と手直しに時間の約9%を使っていたと報告されています。「書く時間が減った」という実感は本物でも、前後に増えた時間が見えにくい、というのがこの実験の示唆です。

その後の追試と、測ること自体の難しさ#

METRは2026年2月に続報を出しています。2025年後半のAIツールで同様の実験を行ったところ、所要時間の変化の推定値は、元の参加者で-18%(信頼区間は-38%から+9%)、新規参加者で-4%(同-15%から+9%)でした。METRは参加者との対話も踏まえ、2025年初頭の推定と比べて現在はAIで速くなっている可能性が高いと述べ、当初の結果は現在の影響を反映していないとしています。

同時に、この続報は「測ること自体が難しくなった」という報告でもあります。報酬が出るにもかかわらずAIなしで作業したくない開発者が増えて参加者が偏ったこと、調査に答えた開発者の30%から50%が「AIなしでやりたくない課題は提出しなかった」と答えたことなどを挙げ、得られたデータは効果の大きさについてごく弱い証拠にしかならないと結論づけています。研究機関が報酬を払って設計した実験でも、こうした偏りは入り込みます。

さらにMETRは2026年5月、技術職349人への調査で、AIによる仕事の価値の変化について自己申告の中央値が1.4倍から2倍だったと報告しました。ただし同じ記事の中で、調査結果は必ずしも現実に根ざしたものではないと断り、2025年の実験で参加者がAIの時間への効果を平均40ポイント過大に見積もっていたこと、一般にアンケートによる推定は現場実験や準実験による推定より大きくなる傾向があることを注意点として挙げています。

効果が出た研究もある#

一方で、はっきりした向上を報告した研究もあります。

3つを並べると、効果は業務の性質と担当者の習熟度で大きく割れることが分かります。経験の浅い人が定型的な業務をこなす場面では効きやすく、熟練者が文脈の深い仕事をする場面では効きにくい、という傾向は読み取れますが、これも限られた研究からの読み取りです。

もう1つ、見落とされがちな点があります。GitHub Copilotの実験では、参加者は事後アンケートで生産性の向上を平均35%と見積もっており、論文はこれを実測の55.8%に対する過小評価だと述べています。つまり自己申告は、過大にも過小にもずれます。「アンケートの数字を割り引いて使えばよい」という補正も当てになりません。

個人が速くなっても、組織の成果は別の話#

ソフトウェア開発組織を調査しているDORAの2025年版レポート(約5,000人が回答)は、回答者の90%が仕事でAIを使い、80%以上が生産性が上がったと考えている一方で、AIの導入はソフトウェアデリバリーのスループット向上と関連しつつ、デリバリーの不安定さの増加とも関連している、と報告しています。レポートは個人の有効性、チームのパフォーマンス、組織のパフォーマンスを別々の指標として扱い、土台となる仕組みがなければ、AIが生む局所的な生産性向上は下流の混乱で失われがちだと述べています。

開発組織の調査ではありますが、一般の業務にも通じる論点です。資料の下書きが速くなっても、レビューする上長の確認時間が増えたり、差し戻しが増えたりすれば、部署全体の処理時間は縮みません。担当者個人の作業時間だけでなく、その成果物を受け取る側の時間まで含めて測る必要があります。

国内では、そもそも指標を置いていない企業が多い#

IPAが2026年7月に公開した「DX動向2026」(調査期間は2026年4月中旬から6月中旬、国内1,799社が回答)によると、DXに取り組んでいる企業のうち、成果を把握するための指標を「設定している」と答えた割合は23.9%でした。報告書は、4社に1社にも満たない状況が続いていると述べています。設定していない理由は「評価指標の設定方法がわからない」が36.0%で最も多く、前回調査の28.7%から約7ポイント増えました。「評価指標はこれから定める」も33.4%あります。必要性は感じているが、測り方が分からない、という企業が多いことになります。

海外との比較は、1年前の「DX動向2025」(調査期間は2025年2月上旬から3月下旬)にあります。この回の調査では、指標を設定している割合は日本が27.4%、米国が89.8%、ドイツが82.7%でした。DX動向2026は海外企業への調査を実施していないため、3か国を並べた数字はこの2025年版が直近です。

いずれもDX全般についての調査で、生成AIに限った数字ではありませんが、「効果を聞かれて答えられない」状況が特別なものではないことは分かります。

この節の数値は、METRの公式ブログ3本と論文(arXiv:2507.09089)、NBER Working Paper 31161の要旨、arXiv:2302.06590の本文、DORAの2025年版レポートと発表記事、IPA「DX動向2026」本文と「DX動向2025」本文で確認した範囲のものです。各研究は対象者・業務・時期・使用ツールが異なるため、数値同士を直接比較したり、自社の見込み値として使ったりすることは避けてください。

測るのは4つの軸#

ここからが本題です。現場で回せる範囲に絞ると、測る対象は次の4つになります。

時間:作業単位の所要時間を、導入前に先に記録する#

時間を測るときの要点は2つです。

1つめは、単位を「1件」に落とすことです。「月の残業時間」や「部署の総労働時間」は、生成AI以外の要因で大きく動くため、比較に向きません。「議事録1本」「見積書1件」「問い合わせ回答1件」のように、始まりと終わりがはっきりした作業単位で、着手から提出可能な状態になるまでの時間を取ります。

2つめは、導入前に記録を始めることです。導入後に「以前は何分かかっていましたか」と聞いても、返ってくるのは記憶と印象です。先ほどの研究が示すとおり、この種の見積もりは当てになりません。すでに導入済みの場合は、後述するように、まだ使っていないチームや、使わずに処理した案件を比較対象にします。

記録の方法は、精密である必要はありません。共有のスプレッドシートに、案件ID、作業の種類、着手時刻、完了時刻、AIを使ったかどうか、を1行ずつ入れてもらう程度で足ります。チケット管理や申請システムに時刻が残る業務なら、それを使うほうが負担も偏りも小さくなります。

品質:レビュー指摘数・差し戻し率・サンプル採点#

時間だけを測ると、「速いが雑になった」を見逃します。品質は次の3つのうち、その業務で取りやすいものを選びます。

• レビュー指摘数。上長やチェック担当が1件あたり何か所を直したか
• 差し戻し率。提出した成果物のうち、やり直しになった割合
• サンプル採点。週に数件を抜き出し、事前に決めた観点(正確さ、漏れ、読みやすさなど)で採点する

サンプル採点をする場合は、採点者に「AIを使った成果物かどうか」を伏せるのが理想です。知っていると、期待や先入観が点数に混ざります。難しければ、少なくとも採点の観点と基準を導入前に決めておき、途中で変えないことが重要です。

なお、ここでいう品質は業務の成果物の品質です。LLMアプリの出力を評価データで機械的に測る評価(eval)とは目的が違います。

手戻り:修正と検証の時間を「削減時間」から差し引く#

4軸の中で最も抜けやすく、結果を最も左右するのがこの軸です。生成AIを使った作業は、おおよそ次の時間で構成されます。

• 指示を書く時間、やり直しの指示を出す時間
• 生成を待つ時間
• 出力を読んで確かめる時間(事実関係、数字、固有名詞の確認)
• 出力を直す時間
• 受け取った側(レビュー担当、後工程)が確認し、直す時間

報告に使うのは、次の考え方で出した正味の時間です。

正味の削減時間(1件あたり)
  = 導入前の所要時間(作成 + 本人の見直し + レビュー側の確認・修正)
  - 導入後の所要時間(指示・待ち + 出力の確認・修正 + レビュー側の確認・修正)

要するに、着手から「後工程が受け取って問題なく使える状態」になるまでを、前後で同じ範囲で比べるということです。作成部分だけを切り出して「60分が10分になった」と報告すると、確認と修正に移っただけの時間まで削減に数えてしまいます。METRの実験で、書く時間が減ったのに全体では長くなっていたのは、まさにこの構造でした。

記録シートでは、所要時間を「作成(指示と待ちを含む)」と「確認・修正」の2つに分けて書いてもらうだけでも、どこに時間が移ったかが見えるようになります。

定着:週次利用率と継続率#

効果が出ていても、使われなくなれば意味がありません。逆に、使われていても効果があるとは限りません。定着は効果そのものではなく、「効果が続く前提が保たれているか」を見る補助の軸として扱います。

• 週次利用率。対象者のうち、その週に対象業務で1回以上使った人の割合
• 継続率。使い始めた人のうち、4週後、8週後も使い続けている人の割合

見るべきは累計ではなく推移です。導入直後に上がって数週間で下がる形なら、物珍しさで触られただけの可能性があります。使うのをやめた人に理由を聞くと、「確認に時間がかかって結局自分で書いたほうが速い」といった、手戻りの軸と直結する情報が得られることが多いです。

測定の手順#

コストの側に入れるもの#

効果の側だけ丁寧に測って、コストの側がライセンス料だけ、というのもよくある偏りです。少なくとも次を並べます。

• ライセンス費用、またはAPIの利用料
• 出力の確認・修正にかかる工数(手戻りの軸で測ったもの)
• 研修、マニュアル整備、社内からの問い合わせ対応の工数
• 測定そのものにかかる工数(記録の手間、集計の時間)

もう1つ注意したいのは、削減時間に時給を掛けた数字を、そのまま金額効果として報告することです。浮いた時間が別の業務に充てられた、残業が減った、外注が減った、といった形で現れて初めて、金額として意味を持ちます。時間の効果と金額の効果は分けて書き、金額に換算する場合は「浮いた時間を何に充てたか」を添えてください。

よくある測り方の失敗#

成功事例だけを集める#

「うまくいった使い方を教えてください」と募ると、うまくいった話だけが集まります。事例集としては有用ですが、効果の測定にはなりません。使ってみたが時間がかかった、途中で使うのをやめた、という案件も同じシートに記録される形にしておく必要があります。METRの続報が報告していたのも、AIなしでやりたくない課題が実験から抜け落ちるという、同じ種類の偏りでした。

繁忙期と閑散期を比べる#

導入前の数字を決算期に、導入後の数字を閑散期に取ると、AIと関係なく数字は改善します。同じ曜日構成、同じ業務サイクルの期間どうしを比べるか、同じ時期に使うチームと使わないチームを並べてください。人員の増減、業務フローの変更、システムの入れ替えが同じ時期にあった場合も、記録に残しておきます。

利用回数をKPIにする#

利用回数やプロンプトの送信数は、取りやすいため目標にされがちです。しかし回数は、うまくいかずにやり直した場合にも増えます。目標にすると、必要のない場面で使う、回数を稼ぐ、といった行動も生まれます。利用の指標は定着を見る補助にとどめ、効果の指標(時間・品質・手戻り)とは別に扱います。

全社平均で薄める#

全社員の平均を取ると、よく効いている業務と、まったく効いていない業務が混ざって、「少し効果があった」というぼんやりした結論になります。カスタマーサポートを対象にした先ほどの研究(Generative AI at Work)でも、解決件数の平均は14%増でしたが、経験の浅い担当者は34%増、熟練者はほとんど変化なしと、中身は大きく割れていました。業務別、習熟度別に分けて見るほうが、どこに展開し、どこはやめるかの判断に使えます。

測らなくてよい場面・向かない場面#

測定にもコストがかかります。次のような場面では、この記事の方法をそのまま当てはめないほうがよいでしょう。

• 頻度の低い業務。年に数回の業務では、比較できるだけの件数が集まりません。担当者の所感と成果物の確認で判断し、測定の対象は頻度の高い業務に回します
• 品質基準が言語化されていない業務。企画のアイデア出しや文章の推敲など、良し悪しの基準が人によって違う業務は、時間だけ測ると「速いが良くなったかは分からない」で終わります。先に、何をもって良しとするかを関係者で決める必要があります
• 少額で、個人の補助的な利用にとどまる場合。数人が下書きの補助に使っている程度なら、厳密な測定より、困りごとを定期的に聞くほうが得るものが多いことがあります
• 投資額が大きい、または人員配置の判断に使う場合。この記事の簡易版では根拠として弱いため、対照群を置いた実験や因果推論の手法を検討してください

最後の点について、厳密な手法を学びたい場合は、次の書籍ガイドで段階順に整理しています。

経営報告用の1枚テンプレート#

測定結果は、次のような1枚にまとめると、判断に必要な情報が抜けにくくなります。数値はすべて記入例で、実在の測定結果ではありません。

「比較条件」と「限界」の行を省かないことが、この表の要点です。都合の悪い条件を書いておくほうが、後から数字の意味を問われたときに説明がつきます。

よくある質問#

まとめ#

生成AIの効果は、業務と使う人によって、大きくも小さくも、ときにはマイナスにもなります。だからこそ、他社の数字や体感ではなく、自社の業務で測った数字が必要です。まずは頻度の高い業務を1つ選び、今週から1件ごとの着手時刻と完了時刻を記録するところから始めてみてください。導入前の2週間分の数字があるだけで、半年後の「で、効果はあったの」への答え方が変わります。