文章を作るのに 10 時間かかっていた人が、新しい道具を使って同じ文章を 5 時間で完成できるようになったとする。内容、正確性、確認手順が同じであれば、この作業の所要時間は半減し、時間当たりの処理能力は 2 倍になった。しかし、残された 5 時間を使って何が行われるかによって、仕事全体の成果は変わる。別の文章を作れば成果物の件数が増える。未着手の調査を始めれば仕事の種類が変わる。労働時間を短縮すれば、同じ成果を少ない時間で得られる。いずれも最初の作業では同じ効率改善が生じているが、その後に得られる便益は異なる。
技術の導入は、既存の仕事に必要な時間を変えるだけでなく、限られた時間の中で実行可能な仕事の範囲も変える。従来は時間が足りずに断念していた調査に着手できる一方、容易に作れるようになったという理由で、利用される見込みのない資料を増やすこともできる。この違いは、作業速度だけでは決まらない。仕事を選ぶ人の判断、成果物を必要とする相手の需要、完成後の確認や維持に必要な費用が関係する。処理能力が増えても、その能力を何に割り当てるかによって、得られる成果は変化する。
生産性を評価する際には、既存の仕事に必要な時間の変化、実際に選択された仕事の構成、選択の結果として得られた価値を区別する必要がある。第一の変化は同じ仕事を比較することで測定できる。第二の変化は技術導入前後の時間配分や実行件数に現れる。第三の変化には、成果物の利用状況、目的の達成度、追加費用、労働負担などの評価が必要になる。三つを分けることで、技術が直接改善した部分と、人間の仕事の選択を通じて生じた変化を識別できる。
1. 仕事が速くなったとき、何が増えるのか
一人の担当者が、毎月同じ形式の報告書を作成しているとする。必要な資料を収集し、数値を確認し、文章を作成して完成させるまで、従来は 10 時間かかっていた。新しい道具を導入した結果、同じ報告書を 5 時間で完成できるようになったと仮定する。比較の条件として、報告書の内容、正確性、確認範囲、完成の判定基準は変わらず、道具の準備や生成結果の確認に必要な時間も 5 時間に含まれているものとする。この条件では、報告書 1 件当たりの作業時間が 50％減少したという評価が成立する。
この改善は、報告書という一つの仕事に対する処理能力の変化である。従来は 10 時間で 1 件を完成させていたため、時間当たりの完成件数は 0.1 件だった。導入後は 5 時間で 1 件を完成させるため、同じ指標は 0.2 件になる。報告書の品質と作業条件が等しいなら、時間当たりの処理能力は 2 倍である。ただし、この数値が表しているのは、同じ報告書を繰り返し作成する場合の能力である。実際に 2 件目を作成するかどうかは、別の判断によって決まる。
例えば、報告書を必要とする部署が月に 1 件しか要求していなければ、作成能力が 2 倍になっても、その部署が利用する報告書の件数は変わらない。追加の報告書を作成しても、利用する相手が存在しなければ、作成件数の増加をそのまま便益の増加と評価することは難しい。一方、報告書の作成が遅いために別の部署への提供を断っていたなら、節約された時間を使って新しい依頼に対応できる。どちらも同じ処理能力の改善から始まっているが、追加の需要の有無によって実際の成果が変わる。
別の選択として、余った 5 時間を新しい調査に割り当てる場合を考える。従来は報告書の作成に時間を使い切っていたため、調査への着手を見送っていた。道具の導入によって時間の制約が緩和されると、調査を実行できる可能性が生まれる。ただし、調査の成果は報告書の作成件数には表れない。調査によって新しい顧客の需要が判明したり、従来の業務に問題が見つかったりすれば、将来の意思決定に役立つ可能性がある。反対に、目的が不明確な調査であれば、時間を投入しても利用可能な成果が得られない場合がある。
さらに、担当者が余った時間を使わず、労働時間を 5 時間短縮する選択もある。この場合、完成した報告書の件数は変わらない。しかし、同じ成果を得るための労働投入は半減している。担当者にとっては自由時間の増加や負担軽減につながり、組織にとっては必要な労働時間の削減につながり得る。追加の成果物を作らないことを理由に、この改善を生産性の向上から除外すると、労働投入を減らして同じ成果を維持するという効率改善を見落とす。
三つの選択を比較すると、作業時間の短縮という共通の変化から、異なる結果が生じることが分かる。
| 時間の使い道 | 直接観測できる変化 | 成果が改善する条件 | 作業時間だけでは分からないこと |
|---|---|---|---|
| 同種の仕事を追加 | 報告書など同じ種類の成果物の件数が増える。 | 追加の成果物に需要があり、確認や利用に必要な能力も確保されている。 | 増えた成果物が実際に利用され、追加費用を上回る便益を生んだかどうか。 |
| 別の仕事へ着手 | 実行される仕事の種類と時間配分が変わる。 | 新しい仕事が目的の達成に寄与し、必要な費用に見合う成果を生む。 | 新しい仕事の価値が、従来の仕事を増やす場合より高いかどうか。 |
| 労働時間を短縮 | 同じ成果を得るための労働投入が減る。 | 成果と品質を維持しながら、時間削減や負担軽減による便益が得られる。 | 削減した時間が、担当者や組織にとってどの程度の便益を持つか。 |
表の三つの選択には、評価上の違いがある。同種の仕事を追加する場合は、成果物の件数を比較しやすい。しかし、件数が増えたことと、利用者が受け取る価値が増えたことは異なる。別の仕事へ着手する場合は、成果物の種類が変わるため、件数の比較だけでは評価できない。労働時間を短縮する場合は、成果物が増えなくても、投入した時間に対する成果の比率が改善する。いずれの選択でも、何を成果として数え、何を費用として数えるかによって評価結果が変わる。
仕事の選択には、さらに優先順位という条件が加わる。担当者が自由に仕事を選べるなら、新しい道具によって容易になった仕事を増やす可能性がある。一方、組織が業務上の必要性に基づいて仕事を割り当てる場合は、節約された時間が、未処理の依頼や優先度の高い課題に再配分されることもある。技術が変えるのは各作業に必要な時間であり、その時間をどこへ配分するかは、仕事の目的、需要、権限、評価制度によって決まる。
この関係には、少なくとも二つの経路がある。第一に、技術によって既存作業の所要時間が減少すると、同じ労働時間の中で実行可能な仕事の範囲が広がる。第二に、その範囲からどの仕事を選ぶかによって、実際に完成する成果物と得られる便益が変化する。追加の仕事が選ばれた場合には、その仕事の確認や利用に必要な費用も発生するため、初期の作業時間だけでは最終的な改善幅を決定できない。
報告書を 10 時間から 5 時間で完成できるようになったという事実は、技術の直接的な効果を評価する出発点になる。しかし、追加の報告書、新しい調査、労働時間の短縮という選択によって、その後の成果は異なる。技術導入前後で実際に選ばれる仕事が変化する場合、生産性の評価には、個別作業の効率に加えて、仕事の構成と選択の結果を含める必要がある。
2. 同じ技術でも、仕事によって効果は異なる
生成 AI を導入したとき、すべての仕事が同じ割合で速くなるわけではない。文章の草案作成、顧客からの問い合わせへの回答、既存プログラムの修正では、必要な知識、確認手順、完成を判断する基準が異なる。生成 AI が直接処理できる部分が多い仕事では時間短縮が期待できる一方、既存の業務知識や複雑なシステムの状態を理解する必要がある仕事では、生成結果を確認する時間が増える場合もある。技術の効果を評価するには、仕事の種類と測定対象を対応させる必要がある。
Noy と Zhang は、高等教育を受けた 453 人の参加者を対象に、職業上の文章作成課題を与える実験を行った。参加者を生成 AI の利用可能な群と利用しない群に無作為に割り当てた結果、利用可能な群では平均所要時間が 40％短縮し、成果物の品質評価も 18％向上した[1]。この実験では、仕事の内容があらかじめ定められており、参加者が同じ種類の課題に取り組んでいる。作業時間と成果物の品質を比較できるため、生成 AI の利用が文章作成の効率に与えた効果を評価しやすい。ただし、実験で使用された文章が実際の業務でどの程度利用され、後からどれだけ修正されたかという長期的な成果まで測定したものではない。
Brynjolfsson、Li、Raymond は、顧客対応担当者 5,172 人の業務データを使い、生成 AI による会話支援の導入効果を調べた。AI 支援へのアクセスによって、時間当たりに解決した問い合わせ件数が平均 15％増加した。改善幅には担当者の経験や技能による差があり、経験の浅い担当者ほど大きな改善が観測された[2]。顧客対応では、過去の対応事例や熟練者の知識を利用することが回答の作成に役立つ。AI 支援によって、経験の浅い担当者が適切な対応方法を参照しやすくなれば、回答に必要な時間が短縮される可能性がある。研究でも、熟練者の対応方法が AI を通じて他の担当者へ伝わることを示唆する結果が報告されている。
この研究で測定されたのは、実際の業務における問い合わせ解決件数である。文章作成実験のように、指定された文章を完成させるまでの時間を比較したわけではない。問い合わせには内容や難易度の違いがあり、担当者の経験、顧客とのやり取り、組織の業務手順も処理件数に影響する。研究では段階的な導入を利用して効果を推定しているが、無作為割り当てによる文章作成実験とは研究方法が異なる。この違いを踏まえると、40％の時間短縮と 15％の処理件数増加を、同じ尺度の改善率として直接比較することは適切ではない。
ソフトウェア開発については、Cui らが Microsoft、Accenture、匿名の大企業で実施された三つの現場実験を分析している。合計 4,867 人の開発者を対象とした結果、AI 支援を利用できる群では完了タスク数が平均 26.08％増加した。ただし、推定値の標準誤差は 10.3 パーセントポイントであり、個別実験の結果にもばらつきがあった。経験の浅い開発者ほど AI の利用率が高く、生産性の改善幅も大きい傾向が報告されている[3]。この結果は、実際の開発環境で AI 支援が完了タスク数を増やした証拠である。一方、完了タスク数は、変更による事業上の便益や長期的な保守費用を直接表す指標ではない。
同じソフトウェア開発でも、反対方向の結果が確認されている。Becker らは、成熟したオープンソースプロジェクトに詳しい 16 人の開発者が、246 件の課題に取り組む無作為化比較試験を行った。参加者は対象プロジェクトについて平均約 5 年の経験を持ち、2025 年 2 月から 6 月に利用可能だった AI ツールを使用する条件と使用しない条件が、課題ごとに割り当てられた。その結果、AI を利用できる条件では作業時間が平均 19％増加した[4]。AI を使えることが、必ずしも熟練開発者の作業時間を短縮するとは限らないことを示している。
既存プロジェクトの修正では、変更対象のコードだけでなく、周辺機能との依存関係、過去の設計判断、テスト条件などを把握する必要がある。開発者がこうした情報をすでに理解している場合、AI に文脈を伝え、生成結果を確認し、必要な修正を加える作業が追加の負担になり得る。ただし、Becker らの実験から、作業時間増加の原因を特定の確認作業だけに確定することはできない。研究対象は特定の開発者集団、成熟したコードベース、2025 年前半のツールであり、異なる環境や新しい AI に同じ結果を適用するには追加の検証が必要である。
Dell’Acqua らは、技術の効果が仕事の難易度に沿って一様に変化するとは限らないことを、知識労働の実験で調べた。758 人の参加者を対象に、AI を利用しない条件、AI を利用する条件、AI の利用方法について説明を受けてから利用する条件を比較した。AI の能力範囲に含まれる 18 種類の業務課題では、AI を利用する群の作業速度や成果物の品質が改善した。一方、能力範囲の外側に設定された複雑な経営判断課題では、AI を利用した参加者が正しい解答に到達する割合が低下した[5]。
この研究が扱うのは、外見上は難易度が近い仕事でも、AI が適切に支援できる範囲には不均一な境界が存在するという現象である。文章の構成や情報の整理では有効な支援が得られても、必要な推論を正確に実行できない課題では、不正確な出力が人間の判断に影響する可能性がある。ただし、能力範囲の外側については特定の複雑な課題を用いた評価であり、すべての経営判断業務について同じ程度の成績低下が発生することを示したものではない。
五つの研究を比較すると、測定された成果と技術が作用した条件の違いが明確になる。
| 研究対象 | 研究方法と測定対象 | 主な観測結果 | 解釈上の制約 |
|---|---|---|---|
| 職業上の文章作成 | 453 人の無作為化実験で、完成までの時間と成果物の品質を測定した。 | AI 利用可能群の平均作業時間が 40％短縮し、品質評価が 18％向上した。 | 指定された文章作成課題の結果であり、完成後の利用価値や維持費用までは評価していない。 |
| 顧客対応業務 | 5,172 人の業務データを用い、段階的な AI 導入による時間当たりの問い合わせ解決件数を分析した。 | 平均処理件数が 15％増加し、経験の浅い担当者ほど改善幅が大きかった。 | 対象組織の業務内容、担当者の経験、導入条件に依存する。 |
| 企業内のソフトウェア開発 | 4,867 人を含む三つの現場実験で、完了タスク数を比較した。 | AI 利用可能群の完了タスク数が平均 26.08％増加した。 | 推定値に統計的不確実性があり、仕事の価値や長期的な保守性を直接測定していない。 |
| 熟練開発者による既存プロジェクトの修正 | 16 人による 246 件の課題を無作為に割り当て、完了までの所要時間を比較した。 | 2025 年前半の AI を利用できる条件で、平均作業時間が 19％増加した。 | 開発者の経験、対象コードベース、利用ツール、実験時期によって適用範囲が限定される。 |
| 経営コンサルティングの知識労働 | 758 人の実験で、AI の能力範囲内外に設定した課題の作業速度、品質、正答を比較した。 | 能力範囲内の課題では改善が見られ、範囲外の複雑な課題では正しい解答に到達する割合が低下した。 | 能力範囲外の評価は特定の課題に基づき、他の仕事への一般化には限界がある。 |
研究によって、作業時間、時間当たりの解決件数、完了タスク数、正答率という異なる指標が使用されている。作業時間の短縮は、同じ仕事を終えるために必要な投入の減少を表す。時間当たりの解決件数は、一定時間内に処理できる仕事の量を表す。正答率は、完成した成果が求められた条件を満たしているかを表す。これらの指標はそれぞれ異なる側面を測定しており、改善率の大小だけで技術の優劣を順位付けすることはできない。
仕事ごとの効果が異なる背景には、技術が処理できる部分と、人間が確認しなければならない部分の組み合わせがある。生成 AI が文章の草案を短時間で作成できても、草案の内容を判断するために専門知識が必要なら、その確認時間が残る。既存システムの修正では、生成されたコードが局所的に正しくても、周辺機能との整合性を確認する作業が発生する。技術によって削減される時間と、技術を利用することで追加される時間の差が、実際の所要時間に反映される。
例えば、ある担当者が報告書の草案作成と既存システムの障害調査を担当しているとする。草案作成が短時間で完了するようになり、障害調査では従来と同じ確認作業が必要なら、二つの仕事の相対的なコストは変わる。報告書への需要が十分にあれば作成件数を増やす選択が生まれ、障害調査の優先度が高ければ節約した時間を調査へ配分できる。実際の配分は、各業務の必要性、期限、期待される便益、担当者の権限によって決まる。
個別の仕事に対する技術の効果が不均一であることは、仕事の選択を考えるうえで重要な前提になる。同じ道具を導入しても、どの作業がどれだけ容易になるかによって、限られた時間の中で実行可能な仕事の組み合わせは変化する。各研究が直接測定したのは特定の仕事に対する効果であり、仕事の再配分による価値の変化は別途評価する必要がある。技術導入後の生産性を考えるには、作業効率の変化と、それを受けて選ばれる仕事の変化を結び付けて捉えることが求められる。
3. コストが変わると、選ばれる仕事も変わる
技術によって作業時間が短縮されると、人間が一日の中で実行できる仕事の組み合わせも変化する。例えば、文書作成とプログラム変更にそれぞれ 4 時間を使っていた担当者がいるとする。新しい道具によってプログラム変更に必要な時間が半減すれば、従来と同じ成果を 6 時間で完成できる。残る 2 時間を文書作成へ割り当てることも、プログラム変更の件数を増やすことも、別の仕事を始めることもできる。どの選択が合理的かは、各作業の所要時間に加えて、成果物の需要、期待される便益、期限、担当者の権限によって決まる。
この変化を考える際には、技術導入前に実行していた仕事と、導入後に実行する仕事を区別する必要がある。同じ仕事の集合を固定すれば、技術による時間短縮を測定できる。しかし、新しい道具を利用できる状況では、従来は時間がかかりすぎて選ばなかった仕事にも着手できるようになる。実際に選択された仕事の集合が変われば、従来の仕事に対する時間短縮率だけでは、仕事全体の成果を説明する範囲が不足する。
Cunningham と Whitfill は、技術導入による生産性の改善を三つの指標に分けている。第一は、導入前に実行していた仕事の集合を固定し、旧方式と新方式に必要な時間を比較する改善率である。第二は、導入後に選ばれた仕事の集合を固定し、それを旧方式と新方式で実行する場合の時間を比較する改善率である。第三は、仕事の組み合わせを変更できる状況で、実際に得られる価値がどれだけ改善するかを表す指標である[6]。この三つを区別することで、技術そのものによる作業効率の変化と、仕事の再配分による価値の変化を整理できる。
具体的な数値で考える。導入前は文書 1 件とプログラム変更 1 件に、それぞれ 1 時間かかるとする。担当者は 8 時間のうち 4 時間を文書作成、4 時間をプログラム変更に使い、それぞれ 4 件ずつ完成させていた。新しい道具によってプログラム変更の所要時間だけが 30 分に短縮され、文書作成の所要時間は変わらないとする。従来と同じ 4 件ずつを完成させるには、文書作成に 4 時間、プログラム変更に 2 時間、合計 6 時間が必要になる。
この場合、従来の仕事に対する作業効率の改善倍率は、旧方式の 8 時間を新方式の 6 時間で割った約 1.33 倍である。作業時間そのものは 8 時間から 6 時間へ 25％減少している。改善倍率が約 1.33 倍であることと、所要時間が 25％減少したことは、同じ変化を異なる基準で表した数値である。
担当者が残る 2 時間をプログラム変更に割り当てれば、追加で 4 件を完成できる。導入後の成果は、文書 4 件とプログラム変更 8 件になる。この仕事の集合を旧方式で完成させるには、文書作成に 4 時間、プログラム変更に 8 時間、合計 12 時間が必要だった。新方式では 8 時間で完成できるため、導入後の仕事を固定した改善倍率は 1.5 倍になる。従来の仕事を固定した場合の約 1.33 倍とは、異なる結果である。
| 比較対象 | 旧方式で必要な時間 | 新方式で必要な時間 | 改善倍率と意味 |
|---|---|---|---|
| 導入前の仕事を固定 | 文書 4 件とプログラム変更 4 件に、合計 8 時間を必要とする。 | 同じ 8 件の仕事を 6 時間で完了する。 | 約 1.33 倍。従来の仕事に対する作業効率の改善を表す。 |
| 導入後の仕事を固定 | 文書 4 件とプログラム変更 8 件に、合計 12 時間を必要とする。 | 同じ 12 件の仕事を 8 時間で完了する。 | 1.5 倍。導入後に選ばれた仕事に対する作業効率の改善を表す。 |
| 仕事の再配分を含む価値 | 旧方式の下で選択された仕事から得られる価値が基準になる。 | 新方式の下で選択された仕事から得られる価値を評価する。 | 仕事の種類ごとの便益と、その組み合わせを評価する基準が必要になる。 |
この表の最初の二行では、完成させる仕事の集合を固定している。違いは、固定する対象が導入前の仕事か、導入後の仕事かという点にある。導入後には相対的に短時間で実行できるようになったプログラム変更の件数が増えているため、その仕事の集合を旧方式で処理する場合には、より長い時間が必要になる。このように、技術の効果が大きい仕事へ配分が変化すると、どの仕事の集合を基準にするかによって改善倍率が変わる。
第三の価値の改善率を求めるには、文書とプログラム変更がそれぞれどれだけの便益を持つかを定義しなければならない。文書を追加することに大きな需要があれば、節約された時間を文書作成へ割り当てる方が合理的かもしれない。反対に、プログラム変更の遅延によって業務が停止しているなら、変更作業を優先する価値が高くなる。完成件数が増えたという事実だけでは、こうした仕事の組み合わせの優劣を決定できない。
Cunningham と Whitfill の分析では、意思決定者が与えられた時間の中で価値を最大化するよう仕事を配分し、各作業に対する技術の改善効果を正しく把握しているなどの仮定を置く。この条件の下では、価値の改善率は、導入前の仕事を固定した改善率以上、導入後の仕事を固定した改善率以下になる[6]。前者は仕事の再配分による便益を含まず、後者は新しい技術の下で選ばれた仕事を旧方式で実行するという仮想的な比較を行うためである。
ただし、この大小関係は、実際の職場で無条件に成立する法則ではない。担当者が仕事ごとの改善効果を誤って予測していたり、評価制度の都合で優先度の低い仕事を選んだりすれば、価値を最大化する配分から外れる。新しい道具に慣れるための学習を優先する場合も、短期的な成果を最大化する配分とは異なる選択が行われる。また、仕事をどの単位で区切るかによって、改善率の測定対象そのものが変わる。実際の価値を評価するには、選択された仕事の種類と、その選択が行われた条件を把握する必要がある。
仕事の選択が変化する現象は、生産性を測定する実験にも影響している。METR は、2025 年 8 月から開始した開発者向けの新しい実験について、2026 年 2 月に実験設計の見直しを報告した。実験では、開発者が取り組む課題を事前に提出し、その課題について AI の利用を許可する条件と禁止する条件を無作為に割り当てていた。しかし、AI を使えない条件で仕事をすることを避ける開発者が増え、研究への参加や提出する課題の選択に偏りが生じた[7]。
具体的には、調査に回答した開発者の約 30〜50％が、AI を使用できない条件で取り組むことを避けるため、一部の課題を実験に提出しなかったと回答している[7]。この場合、AI による改善効果が大きいと予想される仕事ほど、比較実験から除外される可能性がある。研究者が観測できるのは提出された課題だけなので、実際の業務で AI が利用される仕事の構成と、実験に含まれる仕事の構成に違いが生じる。METR は、報酬単価を時給 150 ドルから 50 ドルに変更したことによる参加者の選択や、複数の AI エージェントを並行利用する際の作業時間測定の難しさも報告している。
この報告には、生産性を測定するうえで二つの意味がある。第一に、AI を利用できるかどうかが、開発者の実験参加や課題提出の判断に影響している。第二に、実験へ提出される課題の構成が変わると、観測された平均作業時間の差を、実際の業務全体へ一般化しにくくなる。METR は、2026 年初頭の AI による高速化が以前より大きくなっている可能性を示しつつ、選択による偏りがあるため、その改善幅を信頼して推定することは難しいと説明している[7]。技術が普及すると、仕事の進め方だけでなく、その効果を観測するために集められるデータの構成まで変化し得る。
仕事の構成が技術によって変化するという考え方は、個人の時間配分だけでなく、経済活動全体にも存在する。Acemoglu と Restrepo は、技術による既存作業の自動化と、人間が担う新しい仕事の創出が、労働需要に異なる影響を与えることを理論的に整理した[8]。自動化によって、それまで労働者が担っていた仕事の一部を機械やソフトウェアが実行するようになると、生産における人間の担当範囲が変わる。一方、人間が比較優位を持つ新しい仕事が創出されれば、労働需要を増やす方向にも作用する。技術進歩が生産性を高めることと、既存の仕事に対する労働需要が増えることは、異なる経路によって決まる。
この経済学的な議論は、産業や労働市場における仕事の分担を扱っており、一人の担当者が一日の時間をどう配分するかを直接測定したものではない。ただし、技術によって各作業の相対的なコストが変化すると、誰がどの仕事を実行するかという構成も変わり得る点では、共通した構造を持っている。個人の時間配分でも、組織の業務分担でも、技術による処理能力の変化は、仕事の選択や割り当てを通じて最終的な成果へ影響する。
ここで、仕事の再配分と、仕事に対する要求そのものの変化を区別しておく必要がある。既稿「AI は要求を満たすだけでなく、要求そのものを作る」では、AI との対話を通じて選択肢が具体化され、利用者の選好や判断基準が形成される問題を論じた[9]。例えば、複数の提案を比較する過程で、それまで重視していなかった条件に気づき、何を実現したいかという要求自体が変化する場合である。
これに対して、仕事の相対コストによる再配分は、目的や評価基準が一定でも成立する。担当者が文書作成とプログラム変更の双方を必要としており、その優先順位を決める基準も変わっていない場合を考える。プログラム変更の所要時間が短縮されれば、同じ時間の中で実行可能な仕事の組み合わせが増える。担当者は既存の評価基準に従って、新しい組み合わせから仕事を選べる。要求の形成と仕事の再配分は相互に関係することもあるが、前者は何を望むかという判断基準の変化、後者は与えられた条件の下で何を実行するかという資源配分の変化として整理できる。
仕事を選べるようになっても、その仕事が実際に利用されるまでには別の条件がある。既稿「生成 AI の競争軸は、モデルから業務実装へ移る」では、技術の能力を業務上の価値へ変えるために、データ、権限、確認手順、既存システム、責任分担との接続が必要になることを論じた[10]。例えば、プログラム変更の作業時間が短縮されても、変更対象について利用部門の合意が必要なら、その判断を経て初めて実際の業務へ反映できる。作成された変更の件数が増えることと、利用者が便益を得ることの間には、採用や運用に関する条件が存在する。
以上の関係を整理すると、技術の導入によって生じる変化には、作業単位のコスト変化、実行する仕事の再配分、成果の利用という段階がある。作業コストが下がると実行可能な仕事の範囲が広がる。その範囲からどの仕事を選ぶかによって、実際に完成する成果物の種類と量が変わる。さらに、完成した成果物が必要とされ、利用されることで、仕事の価値が実現する。技術導入による生産性の改善を評価するには、個別作業の時間短縮と、再配分された仕事から得られる価値を、それぞれの条件に基づいて測定する必要がある。
4. 作られた量と、採用された成果は同じではない
技術によって仕事の選択が変わると、生産性を測定する際にもう一つの問題が生じる。作業によって生み出された数量と、その成果が実際に利用されて得られた価値は、異なる段階の指標である。文章なら作成した文字数や文書数、プログラムなら変更したコードの行数、組織なら完了した作業票の件数を数えられる。しかし、これらの数量には、成果物が必要とされていたか、利用可能な状態まで完成したか、利用者にどのような便益をもたらしたかという情報が十分に含まれていない。
例えば、従来は 1 日に 5 件の報告書を作成していた担当者が、新しい道具によって 10 件を作成できるようになったとする。報告書を必要とする部署が 10 件すべてを利用するなら、作成能力の向上は業務上の成果につながる可能性がある。一方、実際の需要が 5 件のままなら、追加された報告書は利用されないかもしれない。作成件数が 2 倍になったという事実はどちらの場合も同じだが、追加された 5 件から得られる便益は異なる。さらに、報告書の確認や保管にも時間がかかるなら、追加作成によって新たな費用が発生する。
この違いは、生成 AI を利用したソフトウェア開発の実証研究にも現れている。Gambacorta らは、中国の Ant Group で開発された AI コーディング支援ツール CodeFuse の導入を利用し、プログラマーの生産性への影響を準実験によって分析した。2023 年 9 月の導入初期には、CodeFuse を利用できる開発者と、導入を知らされていなかった開発者が存在した。研究者らは、経験や従来の生産性が近い開発者を比較することで、AI 支援の効果を推定している[11]。
分析では、コード出力量が平均約 55％増加した。一方、コードの行数が増えても、それが完了した仕事の増加を正確に表すとは限らないため、研究者らは完了タスク数やコードの取り込み状況を使って結果を検証した。完了タスク数の増加は、対数線形モデルによる推定では約 22％、ポアソンモデルによる推定では約 13％だった[11]。いずれの推定でも仕事の完了に改善が見られたものの、コード出力量の増加率とは一致していない。
この差を、増加したコードの残りが不要だった証拠と解釈することはできない。コード行数と完了タスク数は測定単位が異なり、必要な実装量も仕事ごとに変わる。例えば、既存機能の不具合を修正する仕事では、数行の変更で目的を達成できる場合がある。一方、新しい機能を追加する仕事では、多数のコード行が必要になることもある。どちらも完了タスクとしては 1 件に数えられるため、行数の増加率と完了件数の増加率を直接対応させることはできない。
Gambacorta らの研究では、コード出力量の増加のうち、AI が直接生成したコードに相当するのは約 3 分の 1 であり、残りは開発者自身の作業効率の改善によるものと推定されている。また、生産性の改善について統計的に有意な効果が確認されたのは、主として経験の浅い開発者だった[11]。AI 支援が生み出す効果は、生成されたコードそのものの量に限定されず、開発者が他の作業へ時間を割り当てられるようになることにも関係する。ただし、この分析は対象企業の導入条件に基づいており、他の開発組織でも同じ改善幅が得られることを保証するものではない。
仕事が作成された後には、採用するかどうかという判断がある。ソフトウェア開発では、変更内容を Pull Request として提出し、レビューや自動テストを経て、既存のコードベースへ統合する運用が広く使われている。提出された変更は、承認されて統合される場合もあれば、修正が必要になったり、採用されずに終了したりする場合もある。変更を作成する能力が向上すると提出件数を増やせるが、そのすべてが採用されるとは限らない。
Njoku らは、2,807 の GitHub リポジトリから収集した 40,214 件の Pull Request を分析し、人間が作成した変更と、自律的なコーディングエージェントが作成した変更を比較した。対象には、エージェントが作成した 33,596 件と、人間が作成した 6,618 件が含まれている。分析の結果、エージェントが作成した変更は、統合されたものに限れば統合までの時間が短い傾向を示す一方、全体のマージ率は人間による変更より低かった[12]。
ここで、統合までの時間とマージ率は異なる指標である。統合までの時間は、実際に統合された変更について、提出から統合までに経過した時間を測定する。マージ率は、提出された変更のうち、統合されたものが占める割合である。採用された変更が短時間で統合されても、採用されなかった変更が多ければ、提出された変更全体の成果は別の評価になる。統合までの時間が短いという結果だけから、提出されたすべての変更が効率的に処理されたとは判断できない。
さらに、この研究では変更の種類による違いも確認されている。エージェントが作成した変更は、文書を更新する仕事では人間による変更より良い結果を示す一方、プログラムの動作を変更する仕事では採用結果が劣る傾向があった[12]。文書の修正とプログラムの動作変更では、確認すべき内容や影響範囲が異なる。動作変更では、既存機能との整合性、テスト結果、利用者への影響なども判断材料になるため、生成された変更の妥当性を確認するための条件が増える。このような仕事の種類の違いは、変更の採用結果を比較する際に考慮する必要がある。
ただし、Njoku らの研究は、実際のリポジトリで観測された変更を比較したものである。人間とエージェントに同じ仕事を無作為に割り当てた実験ではない。担当した仕事の難易度、変更規模、リポジトリの運用方針、レビュー担当者の判断などが、統合結果に影響している可能性がある。したがって、マージ率の差を作成者の種類だけによる因果効果として解釈することはできない。観測されたのは、異なる作成主体と変更内容を含む実際の開発環境において、統合までの時間と採用率に異なる傾向が存在したという結果である。
ここまでの研究から、仕事の成果には少なくとも四つの評価段階がある。成果物が作成された段階、定められた完了条件を満たした段階、利用者や組織によって採用された段階、実際の利用によって便益が得られた段階である。例えば、プログラムの変更はコードを記述しただけでは完成せず、必要な検証を終えて変更として受け入れられることで、利用可能な成果へ近づく。さらに、変更が利用者の問題を解決したかどうかは、統合されたという事実とは別に評価する必要がある。
| 評価段階 | 観測できる指標 | 次の段階へ進む条件 | 指標だけでは判断できないこと |
|---|---|---|---|
| 作成 | 文書数、コード行数、生成された変更件数などを測定できる。 | 成果物が定められた仕様や完了条件を満たす必要がある。 | 作成した成果物が必要とされているか、完成しているかは分からない。 |
| 完了 | 完了した作業票の件数、所要時間、期限内完了率などを測定できる。 | 利用者や組織による確認を経て、実際の利用対象として受け入れられる必要がある。 | 完成した成果物が採用されたか、利用されたかは分からない。 |
| 採用 | 承認率、統合率、利用開始件数などを測定できる。 | 成果物が実際の業務や利用環境で使われ、目的に沿った効果を生む必要がある。 | 継続利用の状況、利用による便益、維持費用の大きさは分からない。 |
| 価値 | 利用者の時間節約、業務費用の削減、売上への寄与、目的の達成度などを評価できる。 | 得られた便益と必要な費用を、比較可能な基準で評価する必要がある。 | 観測された改善のすべてが技術導入によるものかどうかは、単純な前後比較だけでは確定できない。 |
表の四つの段階は、成果物が価値へ結び付く過程を整理したものである。ただし、すべての仕事が同じ手順を通過するとは限らない。例えば、個人が自分のために作成した文書には、組織による明示的な承認工程が存在しないこともある。また、作成された成果物が途中で不要と判断され、利用に至らない場合もある。評価する際には、実際の業務に存在する完了条件、採用条件、利用状況を特定する必要がある。
このような指標の違いを整理する枠組みとして、Forsgren らはソフトウェア開発者の生産性を多面的に捉える SPACE を提案した。SPACE は、満足度と心身の健康、成果、活動量、コミュニケーションと協業、効率と仕事の流れという五つの側面から、生産性を評価する枠組みである[13]。コード行数や変更件数は主として活動量を表し、作業の所要時間や待ち時間は効率と仕事の流れに関係する。成果物の品質や目的の達成度は成果の側面に位置付けられる。
五つの側面を区別する理由は、ある指標の改善が、別の指標の改善と一致するとは限らないためである。例えば、変更件数を増やすために多くの仕事を同時に進めれば、活動量は増加する一方、レビュー待ちの仕事が増えて完了までの時間が長くなる可能性がある。また、短期間に大量の成果物を完成させても、担当者の負担が増え、継続的な開発能力に影響する場合がある。SPACE は、このような異なる側面を併せて測定するための枠組みであり、特定の指標が改善すれば他の指標も必ず改善するという因果関係を証明するものではない。
既稿「AI を一つの物語に閉じ込めない」では、AI に関する異なる現象を単一の説明へ還元すると、対象ごとの条件や評価基準が見えにくくなることを論じた[14]。生産性の評価にも同様の問題がある。コード出力量が増えたこと、完了タスクが増えたこと、変更が採用されたこと、利用者の負担が減ったことは、それぞれ異なる事実である。これらを区別すれば、技術導入によってどの段階が改善し、どの段階に制約が残っているかを具体的に判断できる。
評価指標の選択は、仕事の選択にも影響する。例えば、組織がコード行数や作業票の完了件数だけを成果として評価すれば、担当者には件数を増やしやすい仕事を優先する誘因が生じる。技術によって成果物を容易に作成できるようになれば、その誘因に従って作成量が増える可能性がある。しかし、利用者が必要としているのが既存機能の不具合解消や業務時間の短縮なら、件数を増やす仕事よりも、件数としては少ない変更の方が高い価値を持つ場合がある。技術による相対コストの変化と組織の評価制度が組み合わさることで、実際に選ばれる仕事の構成が変化し得る。
そのため、技術導入の効果を測定する際には、成果物の数量だけでなく、どの仕事が増えたのか、その仕事がどの条件で完成したのか、実際に採用されたか、利用後にどのような便益が得られたかを追跡する必要がある。さらに、完成した成果物を維持するために費用が発生するなら、その費用も評価に含めることになる。作成能力の向上によって増えた仕事が価値を生んだかどうかは、完成した時点だけでなく、利用と維持を通じて確認される。
5. 早く完成した仕事にも、将来の費用がある
仕事を完成させるまでの時間が短縮されても、その成果物に関する費用がすべて減少するとは限らない。報告書には内容の訂正や定期的な更新があり、プログラムには不具合修正や仕様変更がある。分析結果も、基になるデータが変更されれば再計算や解釈の見直しを必要とする場合がある。こうした作業は成果物が完成した後に発生するため、最初の作成時間だけを測定していると、将来の労働投入や運用上の負担が評価から抜け落ちる。
例えば、あるプログラムの機能を追加する方法として、2 時間で完成する実装と、4 時間かけて変更箇所を整理する実装があるとする。どちらも現在の要求を満たし、必要なテストに合格している。完成時点の作業時間だけを比較すれば、前者が有利である。しかし、将来の仕様変更によって修正が必要になったとき、前者では複数箇所を変更し、後者では限定された箇所だけを変更できる可能性がある。最初の実装方法が後続の変更範囲に影響し、その変更範囲が将来の作業時間に影響するという関係である。
ソフトウェア開発における AI 支援の効果を調べた研究でも、初期の開発速度と、その後の品質や保守性を区別する必要性が示されている。ただし、何を品質と呼ぶか、どの期間まで観測したか、どのような仕事を対象にしたかによって、研究が測定できる範囲は異なる。
He らは、AI コーディング支援ツール Cursor を導入した GitHub のオープンソースプロジェクトと、導入していない類似プロジェクトを比較した。分析には差の差法を用いている。これは、導入前後の変化を単純に比較するのではなく、同じ期間における非導入プロジェクトの変化も考慮して、ツール導入と関連する効果を推定する方法である。研究では、Cursor の導入後にプロジェクト単位の開発速度が統計的に有意に増加した一方、その増加は一時的であり、静的解析上の警告とコード複雑性には継続的な増加が認められた[15]。
ここで、静的解析とは、プログラムを実行せずにコードを検査し、規則違反や潜在的な問題を検出する方法である。コード複雑性は、条件分岐や構造上の依存関係など、プログラムを理解して変更する際の負担に関係する性質を表す。これらの指標が増えると、後続の変更で確認すべき箇所が増えたり、不具合の原因を特定する作業が複雑になったりする可能性がある。ただし、静的解析上の警告がすべて実際の不具合になるわけではなく、複雑性の増加が必ず保守費用の増加につながるわけでもない。
He らは、導入後の時間的な変化をさらに分析し、静的解析上の警告とコード複雑性の増加が、長期的な開発速度の低下を説明する主要な要因であると報告している[15]。この分析は、初期に増加した開発活動が、その後も同じ水準で継続するとは限らないことを示す。ただし、実際の開発速度には仕事の難易度、開発者の構成、プロジェクトの成熟度なども関係する。統計モデルによる推定結果を、品質指標の悪化だけが速度低下を引き起こしたという完全な因果関係の証明として扱うことはできない。
別の観点から、Liu らは、実際の GitHub リポジトリに取り込まれた AI 関与コードについて、静的解析上の問題がどの程度発生し、その後どう変化したかを調査した。研究対象は 6,299 リポジトリの約 30 万 2,600 件のコミットであり、五つの AI コーディング支援ツールに由来する変更を含んでいる。研究者らは、コミットの前後で静的解析を実施し、新たに検出された問題を特定したうえで、導入時点から調査対象の最新リビジョンまで追跡した[16]。
分析では、合計 484,366 件の問題が検出され、その 89.3％をコードスメルが占めた。コードスメルとは、プログラムが直ちに誤動作することを意味するものではなく、コードの構造や記述方法について、理解や変更の負担につながる可能性がある特徴を指す。また、対象となったすべての AI ツールで、15％を超えるコミットから少なくとも一つの新規問題が検出された。さらに、追跡した問題の 22.7％は、調査対象の最新リビジョンにも残存していた[16]。
この 22.7％という数値は、AI が生成したコードの 22.7％に不具合があるという意味ではない。分母は、静的解析によって検出され、追跡対象となった問題である。また、最新リビジョンに問題が残っていることと、その問題が実際に障害を引き起こしたことも異なる。開発者が問題を修正する必要性を低いと判断した場合や、対象コードが現在の機能に影響していない場合も考えられる。この研究から直接確認できるのは、AI が関与したコードによって導入された静的解析上の問題の一部が、コミット時点を過ぎても残存していたという事実である。
問題の残存は、将来の費用を考えるうえで意味を持つ。例えば、現在の動作に影響していない複雑な条件分岐でも、その部分を変更する必要が生じれば、開発者は処理の意味を調べ、変更による影響を確認しなければならない。構造上の問題が残存することは、後続の変更時に追加の作業を必要とする可能性を残す。一方、そのコードを変更する機会がなければ、問題が存在していても追加の修正費用が発生しない場合がある。将来の負担は、問題の性質と、そのコードが実際にどの程度変更されるかによって決まる。
AI の関与が将来の保守性を一律に悪化させるという結論には、反対方向の研究結果も存在する。Borg らは、151 人の参加者を対象に、AI 支援によって作成されたコードを別の開発者が変更する際の保守性を調べた。参加者の約 95％は職業としてソフトウェア開発に従事していた。実験は二段階に分かれ、第一段階では Java の Web アプリケーションに新しい機能を追加し、第二段階では別の参加者が第一段階の成果物を引き継ぎ、AI 支援を利用せずに機能を変更した[17]。
第一段階の観察結果では、AI 支援を利用した参加者の完了時間の中央値が 30.7％短縮していた。一方、第二段階の無作為化比較試験では、後続の変更に要する時間とコード品質について、AI 支援の有無に由来する統計的に有意な差は検出されなかった。ベイズ統計による分析でも、AI 支援による後続作業への改善効果は、存在するとしても限定的であり、推定には大きな不確実性が残ると報告している[17]。
この結果は、最初の開発者が AI を利用していたとしても、別の開発者による変更作業が必ず困難になるわけではないことを示している。ただし、統計的に有意な差を検出しなかったことは、保守性への影響が完全に存在しないと証明したことを意味しない。実験対象は特定の Java アプリケーションと機能変更であり、大規模なシステムの長期運用や、複数年にわたる変更の蓄積を直接測定したものではない。研究の結論は、評価された仕事と指標の範囲で、保守性の一貫した悪化が確認されなかったというものである。
三つの研究を並べると、初期の作業時間と将来の費用について、それぞれ異なる対象を測定していることが明確になる。
| 研究 | 主な測定対象 | 確認された結果 | 直接は判断できないこと |
|---|---|---|---|
| He ら | AI 導入前後の開発速度、静的解析上の警告、コード複雑性をプロジェクト単位で追跡した。 | 導入初期の開発速度の増加と、その後の鈍化、静的解析上の警告と複雑性の持続的な増加が報告された。 | 個々の警告が実際の障害や保守費用にどれだけ影響したかは直接測定していない。 |
| Liu ら | AI 関与コミットによって導入された静的解析上の問題と、その残存状況を追跡した。 | 追跡対象の問題の 22.7％が、調査対象の最新リビジョンにも残っていた。 | 残存した問題のすべてが障害や追加の保守作業を生んだかどうかは分からない。 |
| Borg ら | AI 支援を受けて作成されたコードを、別の開発者が変更する際の所要時間と品質を測定した。 | 評価された後続作業では、所要時間と品質に統計的に有意な差を検出しなかった。 | 他の種類のシステムや、長期間にわたる変更の蓄積でも同じ結果になるかは分からない。 |
He らと Liu らは、静的解析やコード複雑性という指標から、将来の保守負担につながり得る状態を観測している。一方、Borg らは、後続の開発者が実際に機能を変更する際の時間と品質を測定している。静的解析上の問題が存在することと、後続の変更が困難になることは関連し得るが、同じ事象ではない。三つの結果を併せて読むと、AI の利用そのものを保守性の良否の代理指標とするよりも、実際のコードの性質と後続作業への影響を分けて評価する必要がある。
将来の費用が仕事の選択にどのように影響するかを、具体的な計算で考える。ある機能について、最初の実装を短時間で済ませる方法と、将来の変更箇所を整理してから実装する方法があるとする。前者は初期の作業に 2 時間を必要とし、その後の仕様変更には毎回 2 時間がかかる。後者は初期の作業に 4 時間を必要とするが、その後の仕様変更は毎回 30 分で完了すると仮定する。どちらも現在の仕様と品質要件を満たすものとし、数値は関係を説明するための仮定であって、実証研究の測定値ではない。
| 将来の変更回数 | 短時間で実装する方法 | 変更範囲を整理する方法 | 累積作業時間の比較 |
|---|---|---|---|
| 0 回 | 初期実装の 2 時間で完了する。 | 初期実装の 4 時間で完了する。 | 短時間で実装する方法が 2 時間少ない。 |
| 1 回 | 初期実装と変更を合わせて 4 時間になる。 | 初期実装と変更を合わせて 4.5 時間になる。 | 短時間で実装する方法が 0.5 時間少ない。 |
| 2 回 | 累積作業時間は 6 時間になる。 | 累積作業時間は 5 時間になる。 | 変更範囲を整理する方法が 1 時間少ない。 |
| 3 回 | 累積作業時間は 8 時間になる。 | 累積作業時間は 5.5 時間になる。 | 変更範囲を整理する方法が 2.5 時間少ない。 |
この条件では、将来の変更が発生しなければ、最初の作業時間が短い方法の方が有利である。変更が 2 回以上発生すると、初期の作業に時間をかけた方法の累積作業時間が少なくなる。つまり、最初の作業時間を削減することと、将来を含めた総作業時間を削減することは、仕様変更が発生する回数によって異なる判断になる。
実際の仕事では、将来の変更回数を正確に把握できるとは限らない。要求が安定している機能なら、将来の変更に備えて大きな追加費用をかけることが合理的とは限らない。一方、頻繁な仕様変更が予想される機能や、多数の機能から参照される共通部分では、初期の設計判断が後続の変更範囲に影響する可能性がある。変更が発生する見込み、変更時の作業時間、障害が発生した場合の影響を考慮することで、初期費用と将来費用の関係を具体的に評価できる。
この判断は、技術によって新しい仕事を実行できるようになった場合にも適用できる。例えば、従来は作成に時間がかかりすぎたため見送っていた管理用のプログラムを、AI によって短時間で開発できるようになったとする。作成時間が短縮されれば、着手のための制約は緩和される。しかし、そのプログラムを運用するなら、利用するデータの変更への対応、動作環境の更新、障害発生時の調査などが必要になる可能性がある。管理用プログラムの導入によって節約できる業務時間と、継続的に必要となる保守費用を比較して初めて、その仕事を追加する経済的な合理性を判断できる。
仕事の作成コストが下がるほど、従来は費用に見合わなかった仕事にも着手できる可能性が広がる。その一方で、作成された成果物を保有し続ける場合には、維持のための費用や責任が生じ得る。作成時点での効率改善と、成果物を利用し続けた結果としての便益は、異なる期間にわたって評価する必要がある。AI の導入によって増えた仕事が価値を生むかどうかは、完成までの時間に加えて、その成果物がどれだけ利用され、将来どのような費用を必要とするかによっても変わる。
6. 生産性を測るには、仕事の選択まで追跡する
技術導入による生産性の変化を評価するには、何を比較対象とし、どの期間に発生した成果と費用を測定するかを決める必要がある。従来から行っていた仕事を固定して所要時間を比較すれば、同じ仕事に対する作業効率の変化を測定できる。一方、技術導入後に実際に選ばれた仕事まで評価対象を広げると、仕事の種類、数量、必要性、利用後の便益も比較に含まれる。二つの方法は異なる問いに答えるものであり、測定する対象を明確にすることで、それぞれの結果を適切に解釈できる。
例えば、ある担当者が毎週 2 件の報告書を作成しており、従来は 1 件につき 3 時間、合計 6 時間を必要としていたとする。新しい道具を導入した結果、同じ報告書を 1 件につき 1.5 時間、合計 3 時間で完成できるようになった。報告書の内容、正確性、確認手順が同じであり、道具の操作や生成結果の確認に必要な時間も含まれているなら、報告書作成の所要時間は 50％減少したと評価できる。この数値は、仕事の種類と完成条件を固定した場合の作業効率を表している。
担当者が節約した 3 時間で、新しい顧客需要を調べる分析を実施したとする。導入前後の総作業時間は 6 時間で変わらないが、導入後には報告書 2 件に加えて分析結果が得られる。この場合、報告書作成の効率改善は明確である一方、新しく実施した分析の価値は別の情報によって評価する必要がある。分析によって未対応の需要が見つかり、事業上の判断に利用された場合と、既知の情報を整理しただけで利用されなかった場合では、同じ 3 時間の投入でも得られる便益が異なる。
さらに、分析を実施できた理由も確認する必要がある。報告書作成の時間短縮によって着手可能になった場合もあれば、顧客から新しい調査依頼が届いたために優先順位が変更された場合もある。担当者の経験が増えたこと、調査に使用するデータが整備されたこと、組織の方針が変更されたことなども、仕事の選択に影響する。技術導入と同じ時期に成果が増加したという観測結果だけでは、その増加のすべてを技術の効果として説明することはできない。
この違いを整理するには、まず同一作業の効率を測定し、そのうえで仕事の選択と成果を追跡する方法が考えられる。同一作業の測定では、作業内容、難易度、完了条件、品質基準、利用者の経験をできるだけそろえる。仕事の選択については、実際に着手した仕事に加え、候補に挙がりながら見送られた仕事も記録する。成果については、完成件数だけでなく、採用、利用、維持に必要な費用まで観測する。このように測定対象を分けることで、技術による直接的な効率改善と、仕事の構成変更を経由した成果の変化を区別できる。
| 測定対象 | 必要な記録 | 判定できる範囲 | 解釈上の制約 |
|---|---|---|---|
| 同一作業の効率 | 仕事の種類、難易度、完了条件、品質基準、所要時間、利用した道具とその条件を記録する。 | 比較可能な仕事について、完了までの時間や必要な労働投入がどの程度変化したかを評価できる。 | 仕事の難易度や担当者の経験が変化すると、観測された時間差に技術以外の影響が含まれる。 |
| 仕事の選択 | 着手した仕事と見送った仕事、優先順位、見積もり時間、実際の時間配分、選択理由を記録する。 | 技術導入の前後で、実行する仕事の種類と構成がどのように変化したかを追跡できる。 | 観測された構成変更が、技術によるコスト低下だけで生じたかどうかは別途検証する必要がある。 |
| 仕事の完了と採用 | 完了条件、承認、差し戻し、利用開始、採用見送り、利用中止などの状態を記録する。 | 作成された成果物のうち、完成し、実際の利用対象として受け入れられた部分を確認できる。 | 採用されたという事実だけでは、利用後に得られた便益の大きさを評価できない。 |
| 継続的な費用 | 修正、更新、追加検証、障害対応、運用、道具の利用料金などを、評価期間と対応させて記録する。 | 成果物の作成後に必要となった労働投入や費用を把握し、初期費用と合わせて比較できる。 | 評価期間が短い場合は、期間終了後に発生する費用が観測対象から外れる。 |
| 仕事の価値 | 利用目的、成果を受け取る人、便益の評価方法、必要な費用、評価期間を定義する。 | 仕事の構成変更によって、目的の達成度や利用者の便益がどの程度変化したかを評価できる。 | 価値の評価基準が不明確な場合や、導入前後で基準が変化した場合は、結果の比較可能性が制限される。 |
仕事の選択を記録する際には、実際に完成した仕事だけを対象にすることによる偏りにも注意が必要である。例えば、AI を利用すると容易に完成できる仕事を優先し、複雑な確認を必要とする仕事を見送るようになった場合を考える。完成した仕事だけを集めて平均所要時間を比較すると、技術による高速化に加えて、比較的容易な仕事が選ばれるようになった影響も含まれる。逆に、短時間で終わる仕事を AI に任せ、人間が難しい仕事を担当するようになれば、人間の平均作業時間は増加する可能性がある。この場合も、平均作業時間の増加を技術導入の失敗と直ちに判断することは適切ではない。
METR の開発者向け生産性実験で報告された参加者と課題の選択バイアスは、この問題を具体的に示している。AI を使えない条件で取り組むことを避けるため、一部の開発者が課題を実験に提出しなければ、実験に含まれる仕事の構成は実際の業務で選ばれる仕事の構成と異なる可能性がある[7]。観測できる仕事が変わることによって、測定結果の適用範囲も変化する。実際の職場で評価する場合も、完了した仕事だけでなく、候補となった仕事、着手しなかった仕事、途中で中止した仕事を把握することで、このような構成変更を確認しやすくなる。
仕事の件数を評価する際には、仕事の分割単位もそろえる必要がある。例えば、従来は一つの作業票として管理していた機能追加を、技術導入後には設計、実装、テストの三つの作業票に分割するようになったとする。機能追加という成果が同じでも、作業票の完了件数は 1 件から 3 件に増える。この増加は、仕事の処理能力が 3 倍になったことを意味しない。仕事の分割方法が異なる場合、件数の比較には、機能単位や要求単位など共通する評価単位が必要になる。
また、仕事の完了条件が変化すると、同じ名前の作業でも測定している内容が異なる場合がある。例えば、以前は実装とテストの完了をもって作業票を閉じていた組織が、新しい運用では実装の終了時点で完了とするようになった場合、作業票を閉じるまでの時間は短縮する。しかし、テストに必要な仕事が消えたわけではなく、別の工程へ移動している可能性がある。生産性を比較するには、仕事の開始点と完了点、成果物の品質基準、後続工程への引き渡し条件を明確にする必要がある。
技術による因果効果を推定する場合は、技術を利用した条件と利用しない条件を比較できるようにする。例えば、同じ種類の仕事について AI 支援の利用可否を無作為に割り当てれば、担当者の経験や仕事の難易度などが結果へ及ぼす影響を、平均的には均衡させやすくなる。ただし、仕事の選択まで含めた効果を測定するなら、利用条件を割り当てる前に仕事の集合を固定する方法だけでは不十分な場合がある。技術の利用によって新たに選ばれる仕事も評価対象に含めるためには、利用可能な条件を割り当てたうえで、どの仕事が選ばれたかを追跡する設計が必要になる。
実際の組織では、技術を利用できる部署と利用できない部署を同時に設けることが難しい場合もある。その場合、段階的な導入を利用し、導入時期が異なる部署の変化を比較する方法が考えられる。ただし、導入前の傾向が比較可能かどうか、部署間で仕事の難易度や需要が異ならないか、技術導入と同時に業務手順が変更されていないかを検討する必要がある。単純な導入前後の比較で確認できるのは観測された変化であり、因果効果を主張するには、その変化を技術以外の条件で説明できる可能性を評価しなければならない。
技術の効果を評価する期間についても、目的に応じた設定が必要になる。例えば、報告書作成の効率を調べるなら、同じ種類の報告書について複数回の所要時間を比較することで、短期的な作業効率を評価できる。しかし、新しい分析業務への着手が事業上の価値を生んだかどうかは、分析結果が意思決定に使われるまで確認する必要がある。プログラム変更の保守費用を評価するなら、変更後の運用や追加修正が発生する期間を観測対象に含める必要がある。評価期間が異なれば、観測できる成果と費用の範囲も異なる。
価値の評価基準は、仕事の目的によって変わる。問い合わせ対応では、時間当たりの解決件数に加えて、同じ問題による再問い合わせ、顧客が求めた問題の解消、対応品質などを確認する必要がある。ソフトウェア開発では、実装した変更件数だけでなく、その機能が実際に利用され、要求された問題を解決したかを確認する。報告書や分析業務では、成果物の数よりも、その内容が意思決定に利用され、判断の精度や業務上の成果にどのように寄与したかが評価対象になる。
このように、価値の評価基準を仕事ごとに設定することは、生産性の測定を恣意的にすることとは異なる。評価対象となる目的を事前に定義し、その達成度を観測可能な指標と結び付けることで、測定結果を検証できるようになる。例えば、問い合わせ業務で再問い合わせ率を用いるなら、同じ問題による再問い合わせをどの期間まで数えるか、顧客側の事情による問い合わせをどう扱うかを決める必要がある。開発業務で機能の利用率を測るなら、対象利用者、観測期間、利用の定義を統一する必要がある。指標の名前が同じでも、測定条件が異なれば結果の意味が変わる。
Forsgren らの SPACE は、ソフトウェア開発者の生産性について、成果、活動量、協業、効率、満足度と心身の健康を区別している[13]。この枠組みは、活動量の増加と成果の改善を同一視せず、仕事の進め方や開発者の状態も評価対象に含めるために役立つ。ただし、複数の指標を記録するだけで、どの仕事を選ぶことが最も価値を生むかが自動的に決まるわけではない。組織や利用者が何を達成したいのかを定義し、それぞれの指標がその目的とどのように関係するかを確認する必要がある。
例えば、導入後に報告書作成の時間が半減し、追加の分析業務を実施できるようになった場合、評価結果は少なくとも三つに分けられる。報告書作成については、同じ成果を得るための作業時間が減少した。仕事の構成については、従来の報告書に加えて分析が選択された。最終的な価値については、その分析が実際の判断や業務成果に寄与したかどうかが評価対象になる。三つの変化を別々に記録すれば、技術による直接的な時間短縮と、その時間をどこへ配分したかという選択、選択された仕事から得られた成果を対応付けられる。
技術によって生産性が向上したかという問いには、何の生産性を測るかという定義が必要である。同じ仕事を短時間で完成させる能力、一定時間に処理できる仕事の量、利用者に提供された成果、将来の費用を含めた経済的な価値は、それぞれ異なる評価対象になる。技術導入によって仕事の構成まで変化する場合には、従来の仕事に対する効率改善を測定したうえで、新しく選ばれた仕事と見送られた仕事、その選択によって生じた便益と費用を追跡することが、全体の成果を評価するための条件となる。
7. 技術が変えるのは仕事の速度だけではない
最初の報告書の例に戻る。従来は 10 時間かかっていた報告書を、新しい道具によって 5 時間で完成できるようになったとする。内容、正確性、確認条件が同じであれば、報告書 1 件当たりの作業時間は半減し、時間当たりの処理能力は 2 倍になっている。この改善は、同じ仕事を比較することで確認できる。しかし、一日の仕事全体で得られる成果は、節約された 5 時間をどのように使うかによって変わる。
例えば、追加の報告書を作成しても、それを必要とする利用者がいなければ、作成件数の増加に対応する便益は小さい可能性がある。一方、従来は時間不足のため見送っていた調査に着手し、その結果が重要な意思決定に利用されれば、報告書の件数が変わらなくても業務上の価値が増える場合がある。労働時間を短縮する選択なら、成果物の数量を維持したまま、必要な労働投入を削減できる。いずれも作業効率の改善から生じた選択肢だが、評価する成果と便益の種類が異なる。
ここには二つの変化が存在する。第一に、技術によって既存の仕事に必要な時間が減少し、同じ時間の中で実行可能な仕事の範囲が広がる。第二に、その範囲から実際にどの仕事を選ぶかによって、完成する成果物の種類、数量、将来の費用が決まる。新しく選ばれた仕事が利用されれば便益が生じる可能性があり、利用されなければ作成や維持に費やした時間だけが残る場合もある。技術による直接的な効率改善と、その能力をどこへ配分するかという判断は、異なる段階で成果に影響している。
研究結果も、この区別を支持する材料になる。文章作成や顧客対応、ソフトウェア開発の実験では、作業時間や完了件数の改善が報告される一方、仕事の種類や利用条件によって効果が異なることも確認されている。さらに、コード出力量と完了タスク数、変更の作成件数と採用率、初期の開発速度と後続の保守性は、それぞれ異なる測定対象である。ある指標の改善が確認されても、別の指標については追加の観測が必要になる。こうした研究の違いは、生産性を測る際に、どの仕事の、どの段階を評価しているのかを明示する必要があることを示している。
仕事の構成変更を含めた生産性評価では、比較対象を固定する方法にも限界が生じる。Cunningham と Whitfill が整理したように、導入前に選ばれていた仕事の効率と、導入後に選ばれた仕事の効率は、異なる改善率を示し得る[6]。技術によって相対的に容易になった仕事へ時間が再配分されれば、導入前の仕事だけを比較した結果には、新しく実行されるようになった仕事の便益が含まれない。一方、導入後の仕事を比較する場合には、以前は選ばれなかった仕事を旧方式で実行するという仮想的な条件を考える必要がある。
この問題は、研究の測定方法にも現れる。METR の開発者向け実験では、AI を利用できない条件を避けるため、参加者が提出する仕事を選別する現象が報告された[7]。技術の利用可能性が仕事の選択に影響すると、観測される仕事の集合も変化する。このため、同じ指標で作業時間を比較していても、比較対象の構成が変われば、結果の意味や一般化できる範囲も変わる。技術の普及によって測定対象自体が変化することは、生産性評価における独立した制約である。
技術導入の効果を整理するには、少なくとも次の三つの評価対象を区別する必要がある。
| 評価対象 | 確認する変化 | 判断できること | 追加で必要な条件 |
|---|---|---|---|
| 既存の仕事の効率 | 同じ仕事の所要時間、完了条件、品質を比較する。 | 一定の条件で、仕事に必要な時間や労働投入がどれだけ変化したかを評価できる。 | 仕事の難易度、担当者の経験、品質基準などの比較可能性を確保する。 |
| 実行する仕事の構成 | 導入前後で選ばれた仕事、見送られた仕事、時間配分の違いを確認する。 | 技術導入後に、どの仕事が増え、どの仕事が減ったかを把握できる。 | 需要、優先順位、権限、評価制度など、仕事の選択に影響する条件を確認する。 |
| 選択された仕事の価値 | 成果物の利用状況、得られた便益、初期費用と継続費用を確認する。 | 仕事の構成変更が、目的の達成や労働負担の軽減にどの程度寄与したかを評価できる。 | 価値の評価基準と観測期間を定義し、技術以外の要因による影響を検討する。 |
三つの評価対象は連続しているが、同じ数値に置き換えられるものではない。作業時間が半減したことは、既存の仕事の効率改善として評価できる。節約された時間で追加の調査を始めたことは、仕事の構成変更として記録できる。その調査が実際に有益だったかどうかは、得られた情報がどのような判断に利用され、どの程度の便益と費用を生んだかによって評価する。さらに、その変化を技術導入の因果効果として捉えるには、同じ期間に生じた需要や業務条件の変化も考慮する必要がある。
仕事の選択肢が広がることには、便益とともに判断上の負担も伴う。従来は作成に時間がかかりすぎたため見送っていた資料や機能が、短時間で作れるようになれば、新たな着手候補になる。しかし、作成が容易になったことだけでは、その仕事を優先する理由は決まらない。限られた時間の中でどの仕事を選ぶかは、利用者の需要、期待される便益、実施に必要な費用、将来の維持負担によって判断される。技術が作業の制約を緩和するほど、実行する仕事を選ぶための評価基準が成果に与える影響も大きくなり得る。
そのため、生産性の改善を判断する際には、作業速度が上がったという事実を正確に評価するとともに、その変化によって何が実行されるようになったかを確認する必要がある。新しい仕事が増えた場合には、その仕事が必要とされ、利用され、費用に見合う便益を生んだかを調べる。仕事を増やさず労働時間を短縮した場合には、同じ成果を維持しながら削減できた労働投入や負担を評価する。どちらも技術によって得られた能力を利用した結果であり、成果物の件数だけでは表せない改善を含んでいる。
技術の進歩によって、従来は実行できなかった仕事が選択肢に加わる。その結果、技術導入前後で比較すべき対象は、同じ仕事を完了するための時間から、実際に選ばれた仕事の組み合わせと、その成果にまで広がる。生産性を正しく評価するには、作業効率の変化、仕事の選択、選択によって得られた価値を対応付ける必要がある。技術によって何が速くなったかと、その能力を使って何を行うようになったかを区別することが、仕事全体の成果を評価するための基礎となる。
参考文献
- Shakked Noy and Whitney Zhang, “Experimental evidence on the productivity effects of generative artificial intelligence,” Science（2023-07-13）. https://doi.org/10.1126/science.adh2586
- Erik Brynjolfsson, Danielle Li, and Lindsey Raymond, “Generative AI at Work,” The Quarterly Journal of Economics（2025-02-04）. https://doi.org/10.1093/qje/qjae044
- Kevin Zheyuan Cui et al., “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers,” Management Science（2026-02-27）. https://doi.org/10.1287/mnsc.2025.00535
- Joel Becker et al., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” arXiv（2025-07-12）. https://arxiv.org/abs/2507.09089
- Fabrizio Dell’Acqua et al., “Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality,” Organization Science（2026-03-11）. https://doi.org/10.1287/orsc.2025.21838
- Tom Cunningham and Parker Whitfill, “Task Substitution and Uplift,” METR（2026-05-08）. https://metr.org/blog/2026-05-08-task-substitution-and-uplift/
- Joel Becker et al., “We are Changing our Developer Productivity Experiment Design,” METR（2026-02-24）. https://metr.org/blog/2026-02-24-uplift-update/
- Daron Acemoglu and Pascual Restrepo, “Automation and New Tasks: How Technology Displaces and Reinstates Labor,” Journal of Economic Perspectives（2019）. https://doi.org/10.1257/jep.33.2.3
- id774, AI は要求を満たすだけでなく、要求そのものを作る（2026-08-16）. https://blog.id774.net/entry/2026/08/16/5487/
- id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
- Leonardo Gambacorta, Han Qiu, Shuo Shan, and Daniel M. Rees, “Generative AI and labour productivity: A quasi experiment on coding,” Journal of Financial Stability（2026-06）. https://doi.org/10.1016/j.jfs.2026.101543
- Anthonia Oluchukwu Njoku, Zohreh Sharafi, and Foutse Khomh, “When Code Authors Are Agents: A Large-Scale Study of Human–Agent Collaboration in Pull Requests,” AIware 2026（2026-07-05）. https://doi.org/10.1145/3805760.3814909
- Nicole Forsgren et al., “The SPACE of Developer Productivity: There’s more to it than you think,” ACM Queue（2021-03-06）. https://doi.org/10.1145/3454122.3454124
- id774, AI を一つの物語に閉じ込めない（2026-08-09）. https://blog.id774.net/entry/2026/08/09/4974/
- Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner, and Bogdan Vasilescu, “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects,” MSR 2026（2026-04-13）. https://doi.org/10.1145/3793302.3793349
- Yue Liu et al., “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild,” arXiv（2026-03-30）. https://arxiv.org/abs/2603.28592
- Markus Borg et al., “Echoes of AI: Investigating the downstream effects of AI assistants on software maintainability,” Empirical Software Engineering（2026-06-09）. https://doi.org/10.1007/s10664-026-10889-1