本文へ移動
← 記事一覧へ

AIを使うと,なぜ「速くなった気がする」のか

更新日 公開中#生成AI#インタラクティブ
目次

METRのランダム化比較試験は,熟練開発者の作業時間が19%長くなったと報告しました.
ところが同じ人たちは 「20%速くなった」と感じていた.39ポイントのズレです.

このズレは,どこから生まれるのか.時計を3つ並べて見てください.

METRのRCTを再現するモデル実測 +19% / 自己評価 -20% = 39ポイントのギャップ

AIを使うと,なぜ「速くなった気がする」のか

同じ12個のタスクを2人が並走。右の人だけAIを使う。時計を3つ見てください。

AIなし・実測
0:00
累計の作業時間(時:分)完了 0/12
AIあり・実測
0:00
ストップウォッチで測った時間完了 0/12
AIあり・体感
0:00
本人が感じている時間完了 0/12
条件プリセット:
0.78 倍
30%
0%
理論値:実測の所要時間比
1.16倍
理論値:体感の所要時間比
0.80倍
損益分岐のρ(今のqで)
0.65倍
体感-20%に必要な思い込み
1.00倍

いちばん右:いまの δ のままで「AIなしより20%速かった」と感じるには,「自分で書いたら 1.00倍 かかったはずだ」と見積もっている必要がある,という意味.δ を上げるほどこの数字は大きくなる=待ち時間をきちんと数える人ほど,反実仮想を盛らないと『速くなった』とは感じられない

何が起きているのか

体感時計は「待ち時間」を数えない

AIが生成している2分間,人は別のことを見ています. Slackを見たり,次の設計を考えたり.
その時間は「自分がタスクに費やした時間」として記憶に残りにくい.だから体感時計は止まったまま進みます.

δ(デルタ)のスライダーがこれです.0%にすると,待ち時間をまったく数えていない状態になります.

体感時計は「やり直した分」も数えない

AIの出力が使い物にならず捨てたサイクルは,「なかったこと」になりやすい.
完成したコードだけを見て「これをAIが書いてくれた」と評価するので,そこに至る失敗は勘定から落ちます.

q(やり直し率)を上げてみてください.実測時計だけが伸びて,体感時計はあまり伸びません.

そしてレビュー係数 ρ が,速いか遅いかを決めている

AIは「書く」時間をほぼ0にします.代わりに「読んで直す」時間が増える.それが ρ です.

自分が熟知したコードベースほど ρ は上がります. 自分の基準に合わせるコストが高いからです.
METRの被験者が熟練開発者・自分のOSSリポジトリという条件だったことは,偶然ではありません.

結論:「速くなった気がする」は錯覚ではなく,別の時計を見ている

体感時計が嘘をついているわけではありません.測っている対象が違うだけです.

  • 実測時計:待ち時間もやり直しも全部数える
  • 体感時計:自分が能動的に手を動かした時間だけ数える

AIは「手を動かす時間」を減らし,「待つ時間」と「直す時間」を増やします.
だから体感は速くなり,実測は遅くなる.

そしてここが実務上の含意です.ρ が低い領域──自分が詳しくないコード,書き捨てのスクリプト,定型作業──ではAIは実際に速い.
逆に自分が一番詳しいコードで使うと,一番遅くなる. スライダーを動かすと,その境目が見えます.


ファクトと出典

元になった研究
このモデルが置いた仮定(ファクトではありません)
  • プロンプトを書く時間:4分/AIの生成を待つ時間:2分
  • タスクの所要時間は対数正規分布(中央値120分)
  • ρ(レビュー係数)・q(やり直し率)・δ(待ち時間の体感率)はスライダーで可変

METRが報告しているのは「19%遅くなった」「20%速いと感じた」という結果だけです. 上の3つのパラメータはこのモデルが導入したもので,論文に出てくる数値ではありません.

  1. シミュレーション

    エスカレーターの片側空けは,本当に損なのか

  2. シミュレーション / 生成AI

    LLMがハノイの塔で「崩壊」する本当の理由