AIは本当に仕事を速くしてくれるのか：自分で測る2週間の実験

AIでコードを書く人、AIを日常の仕事に使う人なら誰でも、初心者の方でも読めます。統計の知識は不要です。用語にはどれも身近なたとえを添えています。計算の部分は印をつけてあるので、不要なら読み飛ばせます。

数字は公開情報から取っており、末尾に一覧があります。この記事で使うMETRの数字は、私が原典を開いて確認しました。「例」と書いたものは私が作った数字で、誰かの実測ではありません。AIの内部の仕組みはまだ誰にも完全には分かっておらず、この記事もそれには触れません。外から結果を測る方法だけを扱います。引用する2つの研究は他の人のもので、特定のツールと時期のものであり、あなたについての結論ではありません。

---

まず要点#

• 「AIで速くなった」という感覚と、実際に速くなることは違うことがあります。METRの2025年のランダム化試験では、経験豊富な開発者16人が実際の作業246件をこなしました。AIを使った作業は約19%長くかかりましたが、開発者は事前に24%速くなると予想し、終わった後も約20%速くなったと信じていました。
• METRの2026年初めの追跡調査（開発者57人、800件超の作業）はAIが役立つ方向に傾きましたが、METR自身が、AIなしでは働きたくないと参加を断る開発者が増えたため、増加幅については「非常に弱い証拠」だと述べています。
• 自分でも2週間で測れます。同じくらいの大きさの作業を約10件、AIを使うかどうかをランダムに割り当て、やり直しの時間も含めて測り、中央値を比べます。
• 測定を台無しにしやすいのは3つです。どの作業にAIを使うかを自分で選ぶこと、やり直しの時間を忘れること、途中で結果を見てやり方を変えることです。
• 10件では何も証明できません。感覚だけでなく、測ったヒントが手に入るということです。
• 記事にはCSVの雛形、動くPythonスクリプト、答え付きの計算例、チェックリストがあります。結果で同僚を評価しないでください。

---

むずかしい言葉をやさしく#

---

この記事を読むと説明できること#

1. 速くなった気がすることと測った速さが違うことがあるのはなぜか、そしてなぜストップウォッチが必要か。
2. 比較をおおむね公平にするために、なぜランダムに分け、やり直しの時間も足すのか。
3. なぜ10件はヒントにすぎないのか、そして自分をだまさずに結果を読む方法。

---

1. まずイメージ：新しいランニングシューズ#

新しいランニングシューズを買ったとします。走った後、足が軽く感じて速くなったと思います。ところが時計を見ると、今日は暑くて道も坂が多かったので、普段より2分遅かった。感覚は本物で、時計も本物ですが、測っているものが違います。

シューズが役立つかを知りたい慎重な人は、何回も走り、どの回に新しい靴を履くかをランダムに決め、毎回タイムを測って比べます。「走った時間」だけでなく「走った後に足がどれだけ痛かったか」も数えます。

AIも同じです。「タイプが減った、考えることが減った」という感覚は本物です。しかし、作業を受け取ってから本当に終わって差し戻されないまでの時間は、別の量です。この記事は、その2つ目のストップウォッチの押し方を伝えます。

ここから言えること： 何かが自分の役に立つかを知りたいなら、感覚に聞かず、小さくて公平な比較をしましょう。

---

2. 他の人はどう測ったか#

2.1 METRの2025年の試験#

METRは独立した研究組織です。ランダム化試験を行い、経験豊富なオープンソース開発者16人（自分のプロジェクトでの経験が平均約5年）が、大きなコードベース（平均で2万2,000スター超、100万行超）で、バグ修正、機能追加、リファクタリングなど実際の作業246件に取り組みました。各作業は「AIを使ってよい」か「使ってはいけない」にランダムに割り当てられました。AIツールは主にCursor ProとClaude 3.5・3.7 Sonnetです。期間は2025年2月から6月、1件あたり平均約2時間、開発者には1時間150ドルが支払われました。

結果：AIを使った作業は19%長くかかりました。作業の前に、開発者はAIで**24%速くなると予想していました。終わった後も、AIで約20%**速くなったと信じていました。質問された経済学と機械学習の専門家は、およそ39%と38%速くなると予想していました。

METR自身が限界も挙げています。16人だけなので一般化しにくいこと、標本の偏りがありうること（AIで大きく伸びると期待した人は応募しなかったかもしれない）、ツールを約50時間以上使った後の学習効果は排除できないこと、時間の一部は自己申告であること、慣れたコードベースの作業にしか当てはまらないことです。METRのページには現在、この結果が古くなったという注記もあります。

ここから言えること： 19%は「AIは遅くする」という意味ではありません。特定のグループ、ツール、時期の1つの実験です。学ぶ価値があるのは感覚と測定のずれです。

2.2 2026年初めの追跡調査#

2026年2月24日、METRは「We are Changing our Developer Productivity Experiment Design」を公開しました。開発者57人（前回からの10人と新規47人）、143のリポジトリ、800件超の作業でやり直したものです。記事によると、前回からの開発者は約18%速く（信頼区間は38%速いから9%遅いまで）、新規の開発者は約4%速く（15%速いから9%遅いまで）なりました。どちらの区間にも0が含まれます。

さらに重要なのは、METRがこのデータを増加幅について「非常に弱い証拠」と述べていることです。AIなしでは働きたくないと参加を断る開発者が増えたこと（速さの増加を低く見積もる方向に偏る可能性が高い）、報酬を1時間150ドルから50ドルに下げたことで選択の偏りが加わった可能性があること、開発者が複数のエージェントを同時に動かすと時間の計測が信頼できなくなったことが理由です。それでもMETRは、2025年初めに比べて開発者がAIでより速くなっている可能性が高いと考えており、実験を設計し直しています。

ここから言えること： 測ることが仕事の人たちでさえ、ツールや習慣が変われば測り方を変えます。他の人の数字は、あなた自身の数字の代わりにはなりません。

---

3. 2週間の実験を設計する#

台所での小さな実験を想像してください。同じ料理を2通りの方法で作り、目隠しで味見します。

3.1 8つのステップ#

1. 同じくらいの大きさの作業を約10件選ぶ。 たとえば1件30分から90分の見込み。10件は2週間の勤務に収まり、1日1件ほどです。
2. 先に予想を書く。 「AIで何%速くなると思うか」を記録します。METRも使った手順で、いちばん省かれやすい手順です。
3. 始める前に「終わり」を定義する。 たとえばテストが通る、コードを読み返した、動かしてみた。両グループで同じ定義にします。
4. ランダムに分ける。 コインを投げるか、下のスクリプトを使います。約半分の作業にAIを使い、半分は使いません。作業を見た後でグループを変えてはいけません。
5. 開始からステップ3の「終わり」まで測る。 見積もりではなく、実際の開始と終了の時刻を記録します。
6. やり直しも記録する。 差し戻されたり、抜けに気づいたりしたら、その修正時間を同じ作業に足します。
7. 途中で結果を見ない。 早く見ると、やり方を変えたり作業を選んだりしたくなります。
8. 10件そろってから分析する。 両グループの中央値を比べ、ステップ2の予想と照らし合わせます。

3.2 CSVの雛形#

1行が1作業です。minutesは自分の定義で終わるまでの時間、rework_minutesはその後の修正時間です。

task_id,arm,minutes,rework_minutes,done_checks
T1,no_ai,70,5,pass
T2,ai,35,20,pass

別の場所に、作業の説明、事前の予想、終わった後の印象（何%速い、または遅い）、気づいたことも残しましょう。印象は、数字の表を開く前に書きます。

3.3 割り当てと分析のスクリプト（Python 3、追加インストール不要）#

planコマンドが作業をランダムに分けます。analyzeコマンドは中央値、差、厳密な順列検定、95%のブートストラップ区間を計算します。

#!/usr/bin/env python3
"""Self-experiment helper: randomize which tasks use AI, then compare the times.

  python3 ai_experiment.py plan 10 [seed]    : prints a CSV with the arm of each task
  python3 ai_experiment.py analyze data.csv [--no-rework] : medians, difference, exact permutation test, bootstrap interval

Needs only the Python standard library.
"""
import csv, itertools, random, statistics, sys


def plan(n, seed=None):
    rng = random.Random(seed)
    arms = ["ai"] * (n // 2) + ["no_ai"] * (n - n // 2)
    rng.shuffle(arms)
    print("task_id,arm")
    for i, a in enumerate(arms, 1):
        print(f"T{i},{a}")


def load(path, rework=True):
    rows = list(csv.DictReader(open(path)))
    cost = lambda r: float(r["minutes"]) + (float(r["rework_minutes"]) if rework else 0)
    ai = [cost(r) for r in rows if r["arm"] == "ai"]
    no = [cost(r) for r in rows if r["arm"] == "no_ai"]
    return ai, no


def diff(a, b):
    return statistics.median(a) - statistics.median(b)


def analyze(path, rework=True, seed=1, boots=10000):
    ai, no = load(path, rework)
    obs = diff(ai, no)
    # exact permutation test: every way of choosing which tasks would have been "ai"
    pooled = ai + no
    n, k = len(pooled), len(ai)
    count = total = 0
    for idx in itertools.combinations(range(n), k):
        s = set(idx)
        a = [pooled[i] for i in s]
        b = [pooled[i] for i in range(n) if i not in s]
        total += 1
        if abs(diff(a, b)) >= abs(obs):
            count += 1
    # bootstrap interval for the difference of medians
    rng = random.Random(seed)
    ds = sorted(
        diff([rng.choice(ai) for _ in ai], [rng.choice(no) for _ in no]) for _ in range(boots)
    )
    lo, hi = ds[int(0.025 * boots)], ds[int(0.975 * boots) - 1]
    print(f"tasks with ai: {len(ai)}, without ai: {len(no)}")
    print(f"median minutes with ai:    {statistics.median(ai):.1f}")
    print(f"median minutes without ai: {statistics.median(no):.1f}")
    print(f"difference (ai - no_ai):   {obs:+.1f} min ({obs / statistics.median(no) * 100:+.0f}%)")
    print(f"exact permutation p-value: {count}/{total} = {count / total:.3f}")
    print(f"bootstrap 95% interval:    {lo:+.1f} to {hi:+.1f} min")


if __name__ == "__main__":
    cmd = sys.argv[1]
    if cmd == "plan":
        plan(int(sys.argv[2]), int(sys.argv[3]) if len(sys.argv) > 3 else None)
    elif cmd == "analyze":
        analyze(sys.argv[2], rework="--no-rework" not in sys.argv)

本番ではplanにシードを渡さないでください。そうすれば自分でも予測できません。実行した瞬間に出力を保存し、後から書き換えないでください。

---

4. 計算できる例（例であり、読み飛ばせます）#

これは私が作った数字による例で、誰かの実測ではありません。割り当てはシード7で実行し（例を再現できるようにするためだけです）、各作業の時間は作りました。

$ python3 ai_experiment.py plan 10 7
task_id,arm
T1,no_ai
T2,ai
T3,ai
T4,ai
T5,no_ai
T6,ai
T7,no_ai
T8,no_ai
T9,ai
T10,no_ai

2週間後のsample.csv（作った分数）は次のとおりです。

4.1 分析を2通りで実行する#

上の表でスクリプトを実際に動かした出力です。まずやり直しを含めた場合：

$ python3 ai_experiment.py analyze sample.csv
tasks with ai: 5, without ai: 5
median minutes with ai:    55.0
median minutes without ai: 60.0
difference (ai - no_ai):   -5.0 min (-8%)
exact permutation p-value: 252/252 = 1.000
bootstrap 95% interval:    -45.0 to +25.0 min

次にやり直しを忘れた場合（--no-reworkフラグ）：

$ python3 ai_experiment.py analyze sample.csv --no-rework
tasks with ai: 5, without ai: 5
median minutes with ai:    40.0
median minutes without ai: 60.0
difference (ai - no_ai):   -20.0 min (-33%)
exact permutation p-value: 48/252 = 0.190
bootstrap 95% interval:    -50.0 to +10.0 min

4.2 答えと読み方#

正直な読み方：この例では、AIがわずかに上に見えますが、10件では断言できず、最初の感覚は測定より大きい。さらに重要なのは、やり直しの時間を足し忘れると、見栄えのよい33%を信じてしまうことです。

注意：これらは作った数字です。実際の仕事では、逆の方向を含めて、まったく違う結果になることがあります。

---

5. 測定が崩れる場所#

時計で走りを測るのに、赤信号の後でもう一度押し忘れるようなものです。

5.1 例：ある開発者の1週間#

これは想定した場面で、実在の人物や製品には触れていません。

• 月曜 09:00。 開発者がplanを実行します。最初の作業はAIのグループに入りました。予想を書きます：30%速い。
• 09:05。 タイマーを始め、AIにデータ整形の関数を書かせます。
• 10:20。 AIが完了と言い、テストも通ります。開発者は時計を止めます：75分。
• 10:45。 読み返すと、日付が空のケースが抜けていました。修正にさらに25分。飛ばさず、やり直しの列に書きます。
• 金曜 17:30。 いくつかよい数字がすでに見えていても、来週の終わりまで合計を見ないと自分に約束します。
• 翌週の金曜 16:00。 10件がそろいました。分析を実行し、予想と照らし合わせ、結論を書きます：パターンがはっきりした作業ではAIがわずかに上、業務の理解が要る作業では上ではない。

やること：「ほぼ終わり」と感じても、やり直しの時間は同じ作業に足します。これは例なので何も証明しません。証拠は研究にあり、上のMETRの試験は、感覚と測定が違うことがある一例です。

---

6. 使った数字と資料#

正しく読むために： これらの資料は、感覚と測定がずれることがあること、AIの生産性を測るのは難しいことを示します。AIがあなたにとって遅いか速いかは示していません。

---

7. チェックリスト：自分の数字を信じる前の8つの質問#

1. 始める前に予想を書いた？
2. どの作業にAIを使うかはコインかスクリプトで決め、保存した？
3. 作業は同じくらいの大きさ？
4. 「終わり」は両グループで同じ定義？
5. すべてのやり直しの時間を正しい作業に足した？
6. 途中で結果を見て、やり方を変えていない？
7. 区間はどれくらい広く、それ以上の結論を出していない？
8. 結果は自分の習慣の調整だけに使い、誰かの評価には使わない？

---

8. バランスよく見る：測れること、測れないこと#

測れること： どの作業でAIが役立ちそうか、どれで役立たなさそうかのヒントと、感覚と測定のずれ。

測れないこと：

• 10件では何も証明できません。区間は広く、個々の作業の難しさが結果を歪めます。
• 時間がすべてではありません。AIは学びを助けたり、疲れを減らしたり、難しい仕事を引き受ける気にさせたりしますが、ストップウォッチには映りません。また、速いことは、提出したコードを理解していることを意味しません。知らないライブラリをAIと学んで腕を落とさないを参照してください。
• 今日の結果は、3か月後のツールには当てはまらないかもしれません。
• 結果で同僚を評価しないでください。標本は小さく、人によって仕事が違い、1つの数字は悪用されやすいからです。チームにどんな指標でも出す前に、生産性をコードの行数で測らないを読んでください。
• 新人エンジニアに関する数字を慎重に読みたい場合は、新人エンジニアの仕事、数字が食い違うとき、どれを信じるかを参照してください。

誇張しないこと： 個人の実験は厳密な科学ではありません。軽く見ないこと： それでも感覚を信じるだけよりよく、費用は2週間の時間記録だけです。AIが渡した結果の質を確かめたい場合は、AIの結果に自分で証明させるも読んでください。

---

9. 結論#

速くなった気がするのは感覚です。作業を受け取ってから本当に終わって差し戻されないまでの時間は、測定値です。この2つはずれることがあり、METRの試験は特定のグループでそれを示しました。小さな実験をしましょう。10件、ランダムに割り当て、やり直しも含めて時間を測り、中央値を比べ、結果はその確かさのとおりに読みます。

---

参考資料#

数字は2026年10月時点の公開情報です。METRのページとarXivの論文は私が開いて、METRの数字を照合しました。引用する前に、原典を開いて確認してください。

• METR、Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（arXiv 2507.09089）とMETRのブログ記事、2025年7月10日
• METR、We are Changing our Developer Productivity Experiment Design（2026年2月24日）
• Python Software Foundation、statisticsとitertoolsモジュールのドキュメント（中央値と組み合わせのため）