INSIGHT
AIで仕事はどれだけ楽になった？——時短・品質・費用を同じ条件で比べる
生成が速くなった分を、確認や手直しまで含めてどう測るか。
AIに回答案を作ってもらうと、白紙から書く時間は短くなった。でも、出典を開き、言い回しを直し、相手に合わせて整えると、思ったより時間がかかる。確認を頼んだ同僚から、修正が戻ってくることもある。
速くなった感触を否定する必要はありません。ただ、その感触が仕事のどこまでを指すのかは、確かめられます。「AIは役に立ったか」という大きな問いを、一件の時間、仕上がり、費用へ分けてみます。
生成時間だけでなく、一件の仕事が終わるまでを測る
最初に、比べる仕事の始まりと終わりを決めます。問い合わせへの回答なら、依頼を読むところから、資料を調べ、回答案を作り、確認を経て送信するまでです。
AIへ依頼して出力が返るまでだけを測ると、確認・修正・差戻しが外へ落ちます。逆に、送信後の別業務まで一緒にすれば、何が変わったか分からなくなります。同じ区切りで、AIを使う場合と従来の方法を比べます。
以前の記録がなければ、記憶で正確な数字を埋める必要はありません。比較できる仕事を、許可された範囲でこれから記録する方法もあります。測っていない部分は、測っていないと残すところから始めます。
確認と手直しは、自分以外に増えた作業も確かめる
自分の作成時間が短くなっても、受け取る人の照合や修正が増えているかもしれません。反対に、整理された案のおかげで確認が楽になっていることもあります。見ていない作業を、増えたとも減ったとも決めつけないことが大切です。
確認を頼む人には、「AIを使った案と従来の案で、どの手直しに時間がかかりましたか」と聞けます。記録をお願いする場合は、目的と負担を相談します。自分の効果を示すために、他の人へ無断で測定作業を増やす話ではありません。
資料の更新や設定の修正も、使い続けるための仕事です。自分には費用や時間が分からないなら、その部分を未測定として担当へ確認します。自分の時間が減ったことと、仕事全体の負担が減ったことを、同じ数字にしないようにします。
同じ仕事・同じ条件で、時間・品質・費用を並べる
記録は、まず案件ごとに分けます。次の表は測定項目の例です。
| 見るもの | 一件ごとに残すこと | 別に確かめること |
|---|---|---|
| 時間 | 作成、確認、修正、待ち時間 | 他の人の作業、資料更新 |
| 品質 | そのまま使えた、直した、使わなかった | 修正理由、誤りが次の工程へ届いたか |
| 費用 | 一件の利用に伴う料金など | 月額利用料、初期設定、保守、教育 |
待ち時間と、人が手を動かした時間は分けます。AIの処理中に別の仕事ができたなら、経過時間の全てを人の作業時間に足すわけにはいきません。一方、急ぎの返答が処理待ちで遅れたなら、その影響は別に残します。
月額料金などの共通費用を各案件へ全額載せると、合計で二重計上します。期間全体の費用として分け、一件あたりへ配分する場合は件数や期間を明記します。契約の費用が分からなければ、推定で埋めず担当へ確認します。
品質も、一つの点数に押し込めなくて構いません。「古い資料を参照した」「書式を直した」「対象外なので使わなかった」。理由を分けると、AIの使い方を変えるのか、資料を直すのかが見えてきます。
通常例と例外例を分け、平均だけで良し悪しを決めない
定型の問い合わせでは速くても、資料が足りない案件では照合と差戻しが増えるかもしれません。通常例と例外例を分けて記録すると、どんな使い方で助かり、どこに手間が残るかが分かります。
例外で見るのは、正答したかだけではありません。誰が不足に気づいたか、どこで保留したか、従来の手順へどう戻したかも材料です。安全のための確認時間を、単純な無駄として削らないようにします。
また、担当者が慣れた、資料を更新した、モデルを変えたときには印を付けます。条件の違う記録を混ぜて、変化の全てをAIの効果と説明しないためです。件数が少なければ、大きな削減率にまとめず、確認した一件ずつを示しても構いません。
他社の成果は参考にし、自分たちの結果を別に残す
外部研究は、何を測るかの参考になります。ただし、その数字を自分の仕事の削減率へ置き換えることはできません。
METRの2025年の実験 では、経験豊富なオープンソース開発者16人、246タスクという条件で、AI利用を許可した場合の完了時間が19％長くなったと報告されています。参加者の速くなったという感触と、測定結果にも差がありました。当時の対象者・仕事・ツールでの結果であり、現在のAIや事務作業全体についての結論ではありません。
METRの2026年2月の研究設計更新 では、AIなしで作業する実験への参加を避ける傾向や、複数エージェントを並行利用する際の時間測定などが課題とされています。この更新からも、現在の効果量を確かな一つの率として取り出すことはできません。
一方、Microsoft Researchが紹介する三社での実験 は、4,867人の開発者を含む統合分析で、完了タスク数の増加を報告しています。こちらも、仕事全体の工数削減や品質の保証を測った数字ではありません。
誰が、何を、どの条件で行い、何を結果として測ったか。この違いを読んでから、自分たちの測り方へ戻ります。
測った結果から、続ける使い方と次に直す一件を選ぶ
たとえば「定型の回答案は作成が短くなったが、資料不足の案件は照合が増えた」と分かったら、次はその違いを使い方へ戻します。資料がそろう範囲で使う、必要な資料を先に確かめる、対象外の案件は従来の手順へ渡す、といった改善案が考えられます。これは説明用の例で、実測した成果ではありません。
本人の権限で変えられる使い方と、利用範囲・契約・体制の変更は分けます。後者が必要なら、測った範囲と未測定を添えて担当へ渡します。時短だけで、人員や予算を減らせると結論づけません。
まず、よく行う仕事を一つ選び、生成後に何を直したかまで記録してみてください。「楽になった」を打ち消すのではなく、どこで役立ち、次に何を変えればもっと使いやすいかを確かめるための記録です。