Claude Codeの登場でAI駆動開発はどう変わったのか。世界の調査データと現場の実例から読み解く

半年で倍以上。数字が語る、静かな地殻変動

まず、驚きの数字から見てみましょう。開発ツールを手がけるJetBrainsが世界中のプロの開発者に対して行った2026年の調査によると、2026年5月から7月の時点で、世界のプロの開発者のおよそ39パーセントが仕事でClaude Codeを使っています。2026年1月時点では18パーセントでしたので、わずか半年で倍以上に増えた計算になります。アメリカに限れば47パーセントで、ほぼ2人に1人という水準です。

同じ調査では、プロの開発者の90パーセントが週に1回以上、68パーセントが毎日、なんらかのAIエージェントを使って仕事をしていることもわかっています。これはもう「一部の先進的な人が試している」という段階ではありません。開発の現場では、AIと一緒に働くことがすでに当たり前になっているのです。

そもそもAI駆動開発とは。補完型とエージェント型の決定的な違い

AI駆動開発とは、ひとことで言えばAIを開発の中心に置いて、設計から実装、テスト、運用までを進めていく仕事の進め方のことです。ここで大事なのが、これまでのAIコーディングツールとの違いです。

従来のツールは「補完型」と呼ばれます。人が書きかけたコードを見て、次の1行を提案してくれるタイプです。便利ではありますが、どのファイルを直すか、全体をどう組み立てるかを考えるのはあくまで人でした。

一方でClaude Codeのようなエージェント型は、プロジェクト全体を自分で読み込み、どこをどう直せばよいか計画を立て、複数のファイルを同時に書き換え、テストを実行し、失敗すれば原因を調べて直し、そのうえで結果をまとめて報告します。人が「何をしてほしいか」を伝えれば、「どうやるか」はAIが決めて実行する。この差はとても大きなものです。

変化その1。人は「何を作るか」、AIは「どう作るか」

ここからは、実際の利用データを見ていきましょう。Anthropicは2026年6月、2025年10月から2026年4月にかけての約40万件のClaude Codeの利用記録（約23万5千人分）を、個人が特定されない形で分析した調査結果を公開しました。ここには、現場のリアルな姿が数字として現れています。

計画は人が7割、実行はAIが8割

この調査で最も象徴的なのが、意思決定の分担です。「何をするか、どんな方針でいくか、どこまでできたら完成とするか」といった計画の判断は、およそ70パーセントを人が行っています。一方で「どのファイルを変えるか、どんなコードを書くか、どのコマンドを実行するか」といった実行の判断は、およそ80パーセントをAIが行っています。

つまり、はっきりとした役割分担が生まれているということです。人は「何を作るか」を決め、AIは「どう作るか」を決める。この形が、いまの標準になりつつあります。

もう1つ驚くのが、指示1回あたりの仕事量です。人が1回指示を出すと、AIは平均しておよそ10個の操作を続けて実行します。ときには100を超えることもあります。そして1回のやりとりで、平均2,400語もの出力を返してきます。使っている人はClaude Codeを週平均20時間ほど動かしているという数字もあり、「指示を出して、待って、確認する」というリズムが新しい働き方になっていることがうかがえます。

仕事の中身そのものが入れ替わった

さらに興味深いのは、この7か月間で「AIに頼む仕事の種類」が大きく入れ替わったことです。

デバッグ、つまり不具合探しに費やされる時間はこの期間でほぼ半分に減りました。その分、AIが担う仕事はより上流へ、そしてコードの外側へと広がっています。同じ調査では、1回あたりの仕事の価値（フリーランス市場の相場に照らした推計）が、7か月で平均25パーセントほど上がったとも報告されています。同じツールで、より難しく、より価値の高い仕事ができるようになっているということです。

変化その2。強いのは「書ける人」ではなく「わかっている人」

ここが、AI初心者の方にとって一番の朗報かもしれません。同じAnthropicの調査は、こんな結果も示しています。

この5ポイントほどの差は、7か月間で広がりもしなければ縮まりもしませんでした。つまり「プログラマーかどうか」は、もはや成功を左右する決定的な要素ではなくなりつつあるということです。実際にこの調査では、法務や営業、経営管理といった職種の利用が急速に伸びていることも報告されています。

では、何が差を生むのか

成功率を大きく左右していたのは、その人が「取り組んでいる仕事そのものをどれだけ理解しているか」でした。調査ではこれを熟練度と呼び、5段階で評価しています。

• 1初心者と判定されたセッションで、明確な証拠を伴って成功した割合は15パーセント。
• 2中級以上と判定されたセッションでは、28から33パーセントに跳ね上がります。
• 3途中でつまずいたとき、何も残さず作業を投げ出した割合は初心者が19パーセント。それ以外の人は5から7パーセントにとどまりました。

ここで重要なのは、この熟練度が肩書きではなくタスク単位で測られていることです。調査の説明はとてもわかりやすいものでした。ある言語をはじめて触るベテランエンジニアは、その言語については初心者です。逆に、プログラムを一度も書いたことがない経理担当者でも、月次の締め作業でどんなルールを守らなければならないかを正確に伝えられ、AIが取りこぼした例外にすぐ気づけるなら、その仕事の専門家なのです。

しかも伸びしろの大半は、初心者から中級に上がるところに集中していました。深い熟練を極めなくても、対象をきちんと理解しているだけで、恩恵のほとんどを受け取れるということです。「コードが書けないから無理」ではなく、「自分の仕事をよく知っているから使いこなせる」。これがいまのAI駆動開発の実像です。

変化その3。速くなるのは前半だけ。詰まりは後ろへ移動する

ここまで明るい話が続きましたので、現場で本当に起きている難しさにも触れておきます。ここを理解しているかどうかで、AI導入の成否は大きく変わります。

検証にかかるコストという新しい負担

Googleの研究チームDORAが2026年に公開したレポートは、AI導入によって一時的に成果が落ち込む時期があることを指摘しています。グラフの形からJカーブと呼ばれる現象で、いったん下がってから上がるという意味です。

落ち込みの主な原因が「検証にかかる負担」です。AIが作ったコードが本当に正しいのか、安全なのか、全体の設計と噛み合っているのかを確かめる作業には手間がかかります。AIが書くスピードは速くなっても、レビューやテストの体制が追いつかなければ、確認待ちの列が伸びるだけです。実際、DORAの試算例では、AI導入によって変更の失敗率が5パーセントから6パーセントに上がると仮定すると、システム停止による損失が約34万4千ドル発生するという計算が示されています。

「速くなった気がする」という落とし穴

もう1つ有名なのが、非営利の研究機関METRが2025年に行った実験です。経験豊富なオープンソース開発者16名が、自分がよく知るプロジェクトで246件の実作業に取り組み、それぞれAIを使う場合と使わない場合にくじ引きで振り分けられました。

結果は予想外のものでした。AIを使ったときのほうが、作業完了までに19パーセント長い時間がかかったのです。しかも参加者は事前に24パーセント速くなると予想し、終了後も20パーセント速くなったと感じていました。実感と実測が正反対を向いていたわけです。

ただし、この話には続きがあります。METRは2026年2月、後続の実験がうまく測定できなくなったと公表しました。理由が象徴的です。「AIなしで作業したくない」という理由で参加を断る開発者が増えてしまい、公平な比較ができなくなったのです。ある参加者は、AIなしで進めるのは車に慣れた後で街を歩いて横断するようなものだ、という趣旨の言葉を残しています。METR自身も、2026年初頭の開発者は2025年初頭よりも確実に加速している可能性が高い、と述べています。

ここから学べるのは、感覚だけで判断してはいけないということと、状況が驚くほど速く変わっているということの2点です。

海外の実例。数字で見るAI駆動開発の現在地

実例1。数万人規模の導入で、成果は24パーセント増えた

Microsoftの研究チームが2026年7月に公開した論文は、この分野で初めての大規模な実地調査として注目されました。同社が2026年初めに数万人のエンジニアへClaude CodeとGitHub Copilot CLIを展開した際の、実際の記録を追ったものです。

結果として、ツールを使い始めたエンジニアは、使わなかった場合と比べておよそ24パーセント多くのプルリクエストを完了させていました。プルリクエストとは、修正した内容をチームに提出して本体に取り込んでもらう手続きのことで、開発の成果を測る目安としてよく使われます。この効果は観察期間の4か月を通じて持続しました。

もう1つ面白いのが、広まり方です。最初にツールを使い始めるきっかけは、社内の人間関係、つまり隣の同僚が使っているのを見たことでした。研修やお知らせよりも、身近な人の使っている姿のほうが強い。これは、これから社内導入を考える人にとって実用的なヒントです。

実例2。100万行の書き換えを2週間弱で完了

2026年7月にAnthropicが公開した事例は、規模の面でとくに驚きがあります。JavaScriptの実行環境として世界中で使われているBunというソフトを、Zigという言語からRustという別の言語へ全面的に書き換えるプロジェクトです。

従来であれば数年がかりの大仕事でした。それが今回は、100万行のコードが2週間足らずで書き上がり、本体に取り込む前の自動テストは100パーセント通過しました。取り込み後に見つかった不具合は19件で、いずれも修正済みです。

成果も具体的です。2,000回のビルドを繰り返す試験でのメモリ使用量は6,745メガバイトから609メガバイトに減り、配布ファイルの大きさはLinuxとWindowsで19パーセント小さくなり、実際の処理速度も2から5パーセント向上しました。かかった費用はAPI料金換算でおよそ16万5千ドルです。数年分の人件費と比べれば桁違いに安い一方、決してタダではないという現実も見えてきます。

同じ記事では、Anthropic Labsの責任者がPythonで書かれた社内ツールを16万5千行のTypeScriptへ、週末のあいだに移し替えた例も紹介されています。移行後は、配布ファイルを作る時間が1環境あたり約8分から約2秒に短縮され、起動も6倍速くなりました。

初心者が今日から試せる3つのステップ

ここまでの内容を、明日から使える形にまとめてみます。プログラミングの経験がなくても始められる順番です。

1. 1
   自分がよく知っている小さな作業から任せる。いきなり大きなシステムを作ろうとせず、毎月手作業でやっている集計や、散らかったファイルの整理といった、自分が正解を判断できる仕事から始めます。前述の調査が示すとおり、成功を決めるのは対象への理解度です。自分が正解を知らない仕事から始めると、AIの答えが合っているかどうかも判断できません。
2. 2
   「これができたら合格」という基準を先に決める。Bunの事例でも、まず判定役を用意することが前提条件とされていました。専門的な仕組みでなくてかまいません。前と後で結果が一致するか比べる、想定される代表的な場面を3つ書き出しておく、その程度で十分に効果があります。基準がないと、AIは終わりのない作業を続けてしまいます。
3. 3
   うまくいった指示の出し方を、文章にして残す。同じ指示を毎回考え直すのは非効率です。守ってほしいルール、使ってほしい書き方、避けてほしいやり方をメモにまとめ、次回はそれを最初に渡します。個人の工夫がチームの資産に変わるのは、この一手間からです。

まとめ。変わったのはツールではなく、仕事の形

Claude Codeの登場でAI駆動開発がどう変わったのか。最後に整理します。

いま起きているのは、道具が新しくなったという話にとどまりません。「作れる人」の定義そのものが広がっているのです。これまで技術者に依頼するしかなかったことを、業務をよく知っている人が自分の手で形にできるようになりました。営業の人が営業の仕組みを、経理の人が経理の仕組みを、自分でつくれる時代がすでに始まっています。

難しい専門知識を先に身につける必要はありません。必要なのは、自分の仕事を丁寧に言葉にする力と、出てきた結果をきちんと確かめる姿勢です。その2つさえあれば、あなたはもうAI駆動開発の当事者になれます。まずは今日、いつも手作業でやっているあの面倒な作業を1つ思い浮かべることから始めてみてください。

参考にした主な情報源

• ・Anthropic「Agentic coding and persistent returns to expertise」2026年6月16日（リンク）
• ・JetBrains「AI Coding Agents: Adoption Trends」2026年8月（リンク）
• ・Murphy-Hillほか「Adoption and Impact of Command-Line AI Coding Agents」2026年7月1日（リンク）
• ・Anthropic「How Anthropic runs large-scale code migrations with Claude Code」2026年7月16日（リンク）
• ・METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」および2026年2月24日の続報（リンク）
• ・InfoQ「New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment」2026年5月（リンク）