ユーザーが方向を決め、Claude が細部を実行する

研究はセッション内の各意思決定を2種類に分けた。プランニングの意思決定は「何をするか、どの道筋を取るか、何をもって完了とするか」を、実行の意思決定は「どのファイルを直すか、何のコードを書くか、どの言語を使うか、どのコマンドを走らせるか」を管轄する。それぞれの決定を「人間が下したか、Claude が下したか」を分類器に判定させ、各セッションについて二つの数値を算出した。

ひと言でまとめれば——人間が方向を決め、AIが細部をこなす。この役割分担は、セッション全体を通じて安定的に現れる。

視点を変えて、「意思決定」を「アクション」に置き換えてみる。Claude Code のセッションは、人間と Claude のやり取りの往復だ——ユーザーが1つの指示を出すと、Claude はひとまとまりの作業をこなし、その後ユーザーが次の指示を出す。典型的なセッションは約4往復。過去データでは、ユーザーの1指示あたり Claude は平均約10個のアクションを引き起こし、時には100を超えることもある。Claude は毎ラウンド、ファイルを読み、コードを書き換え、コマンドを実行し、平均約2400字の出力を書き記す。

どれだけ権限を委ねるかは、基本的に「誰が意思決定するか」次第だ。

注：ユーザー自身が実行の意思決定の80%以上を担う場合、Claude は1ラウンドあたり約8個のアクションしか行わない。逆に Claude がプランニング権限の80%以上を握る場合、アクション数は最多の約16個に達する。

原文 Figure 2：セッション内のプランニング決定と実行決定のうち、どれだけが Claude に帰属するか。典型的なセッションではユーザーが約70%のプランニング決定を、Claude が約80%の実行決定を行う。出典：Anthropic

「専門家」かどうかをどう判定するか

ここで言う「専門家」が測っているのは、目の前の具体的なタスクへの理解度であり、職業の肩書きともコーディング能力とも無関係だ。これはタスク固有のものだ——ベテランのエンジニアでも Rust の質問に初めて向き合えばその件では初心者であり、Python を一度も使ったことがない経理担当者でも、照合ルールを正確に語れて、Claude が月末決算で見落とした例外を指摘できるなら、その件では専門家ということになる。

分類器は「初心者から専門家まで」の5段階スケールで各セッションを採点する。見るのは3つのシグナルのみ——指示がどれだけ正確か、Claude に何を検証させたか、そして人間が Claude を訂正しているのか Claude が人間を訂正しているのか。

上記2段は分類器が見る3つのシグナルを説明するための例示であり、原文そのままの文章ではない。原レポートの等級づけの例は、公開されているエージェント型コーディング会話データセット SWE-chat から取り、改変・匿名化・要約した上で使用している。

専門ユーザーほど、Claude により多くの作業をさせられる

専門度が高いほど、同じ一つの指示から引き出せる Claude の産出量も多くなる。典型的な初心者セッションでは、指示1つあたり Claude のアクションは約5個、出力は約600字。専門家セッションでは、アクションの連鎖は倍の12個に、文字産出量は5倍の約3200字に達する。

指示1つあたりの Claude のアクション数

指示1つあたりの文字産出量

原文 Figure 3：ユーザーの専門度が高いほど、Claude が1指示あたりに産出するアクション数（左）と文字数（右）が増える。白丸は幾何平均で、両方の上昇傾向は統計的に有意（p<0.001）。出典：Anthropic

成否を決めるのはコーディング経験より専門度

まず成功の測り方を明確にしておく。研究はユーザーの実世界での成果を直接見ることも、本人に直接尋ねることもできないため、セッション記録を読み解く2つの物差しに頼っている。

この2つの物差しで測ると、傾向は明確だ——セッションで示されるユーザーの専門度が高いほど、セッションが成功する可能性は高い。しかも大部分の伸びはスケールの下端に集中している。初心者から中級への差は、中級から専門家への差より大きい。

では職業的背景はどうか。研究はセッション記録から推測したユーザーの職業を、米国労働統計局（BLS）の23の大分類にマッピングした。結果は、コードを生成したセッションにおいて、職業的背景の影響は想像よりずっと小さいというものだった。

（コードを生成したセッションにおける検証成功率の）差はわずか5ポイントで、7カ月間で拡大も縮小もしていない。「少なくとも部分的成功」まで基準を緩めると、両グループはそれぞれ89%と88%になる。

さらに踏み込むと、コードを生成したセッションでは、データセット中の上位10職種すべてがソフトウェアエンジニアの7ポイント以内に収まる。マネジメント系職種の検証成功率はソフトウェアエンジニアをわずかに上回ることさえある——これはマネジメントスキルが本来的にエージェント指揮に向いているからかもしれないし、単にマネージャーが対話の中で「達成した」とはっきり述べる傾向が強く、検証成功の判定がこうした明確な確認に一部依存しているためかもしれない。

原文 Figure 6：推測された職種別の検証成功率と判定成功率（コードを生成したセッションのみ、上位10職種グループ）。いずれのグループもソフトウェア・数学系職種の7ポイント以内に収まる。出典：Anthropic

つまずいた後、専門ユーザーの方が立ち直りやすい

専門度は順調な場面だけでなく、セッションが「つまずいた」時にこそ、より大きな差を生む。

下の図は、「検証成功率」を専門度5段階で並べたもの。全セッションと、困難に遭遇したセッションのみを切り替えて見ることができ、困難なセッションでは初心者はほぼ崩壊する一方、専門家はまだ持ちこたえていることがわかる。

もう一方の極端な例が「即座に諦める」ケース、すなわちセッションが失敗と判定され、かつコードが1行も書かれなかった場合だ。ここで初心者とその他の差が最も激しく開く。

最も経験の浅いユーザーは、行き詰まった時に諦める割合が他の人の3〜4倍に達する。専門度の価値の一部は、エージェントを正しい方向に引き戻す能力にあるようだ。

一点、条件の細部を補足しておく。「困難に遭遇」という条件が絞り出すセッションは、人によって異なる。専門家は全体として困難に遭遇する頻度が低いため、彼らが本当に行き詰まったセッションは、往々にしてより難しい問題であることが多い。タスク評価額を複雑さの代理指標として見ると、つまずいたセッションの平均評価額は、専門度が最も低い層から最も高い層でおよそ倍になる。したがって回復率の差の一部は、初心者が定型的な問題でつまずき、専門家が手強い問題でつまずいているという違いによるものかもしれず、必ずしも挫折への耐性の差だけではない。

原文 Figure 5：タスクにおけるユーザーの専門度別に見たセッションの結末。左：全セッション、中央・右：困難に遭遇したセッションのみ（失敗シグナル>3）。各点は作業タイプ、タスク価値、月、テーマ、職種について整合性を取る制御を行っている。出典：Anthropic

7カ月間で、Claude Code の使われ方は変わった

研究は各セッションを9種類の作業パターンのうち最も当てはまるものに分類した。うち4種は直接コードを書く・保守する作業（構築、修正、テスト、他エージェントのオーケストレーション)。残りはソフトウェアの運用、システムの仕組みの解明、着手前の計画立案、そしてコードとは無関係なデータ分析やドキュメント作成だ。7カ月の間に、この構成は変化した。

最も顕著なのは、壊れたコードの修正に費やしたセッションの割合が33%から19%へと、ほぼ半減したことだ。空いた分は、コード周辺の作業へと流れた。

ソフトウェアの運用（デプロイ、設定、パイプライン実行、システム監視）は14%から21%へ上昇。ドキュメント作成とデータ分析は合わせて約10%から20%へと倍増した。人々は Claude Code を、コードを書く工程だけでなく、一連の作業の最初から最後まで、より広い場面で使うようになっている。

タスクそのものの価値も上がっている。研究は各セッションをフリーランス市場の相場に照らして評価額を算出し、典型的なセッションの評価額は7カ月間で約25%〜27%上昇、ほぼすべての作業カテゴリーで値上がりが見られた。

これらの価格はあくまで概算であり、タスク間および時系列での相対的な変化を比較するためのものにすぎず、実際のドル建て金額としてそのまま受け取るべきではない。

原文 Figure 4：2025年10月から2026年4月にかけての、各作業パターンのセッション割合の変化。バグ修正は33%から19%に低下し、運用・データ分析・ドキュメント作成は同時に上昇した。出典：Anthropic

これらの数字が現時点で言えること

このデータが裏付けられる結論を並べておく。物差しが測ったことだけを述べ、それ以上は外挿しない。

第一に、コードを生成したセッションにおいて、あらゆる業界の成功率がソフトウェア従事者に近づいており、コーディング経験がコード作成の成否に与える影響は小さくなりつつある。第二に、うまく使えるかどうかは、その人がどの分野にいるかにかかわらず、問題そのものへの理解度により多く左右される。第三に、これはこのレポートが繰り返し強調する点でもあるが——恩恵の大部分は「使いこなせる水準の習熟」に由来する。初心者から中級へ登るときの成功率の跳躍は、中級から専門家への小さな一段よりもはるかに大きい。

下の階段図は、「専門度の上昇とともに検証成功率が上がる」様子を描いたものだ。前半は急、後半は緩やか——それがこのデータが示す収穫逓減の形そのものだ。

留めておくべき境界がいくつかある。研究は実世界での成果、たとえばあるセッションで書かれたコードがその後実際に使われたのか捨てられたのかは見ていない。本記事が除外している非対話型利用（headless と API バッチ）はかなり大きな部分を占めており、それをどう測るかは次の重点課題だ。すべての分類は AI モデルによるセッション記録の読み取りに依存しており、大規模な検証自体が難しい上、Claude Code のセッションは長く複雑で、人手によるラベリングを正解として扱うのは難しい。

モデル、ユーザー、そして両者の分担が今後も変化し続けるにつれ、この全体像は継続的に更新されていくだろう。研究者によれば、今後注視すべきシグナルには、専門度がもたらす見返りが逓減し始めるかどうか、そしてソフトウェア以外の職種における成功セッションの割合がさらに伸び続けるかどうかが含まれるという。

この発見を、明日からの使い方に落とし込む

原レポートはここで終わっている。これは純粋なデータ分析であり、操作方法の提案は行っていない。しかし「専門度」を測るために使われた3つのシグナルを裏返せば、それがそのまま「Claude Code をより快適に使うための」チェックリストになる。以下の数項目は、研究の特徴から逆算した使い方であり、参考として提示するものだ。

研究はセッション内の各意思決定を2種類に分けた——「何をするか」（方向を決める、道筋を選ぶ、何をもって完了とするか）と「どうやるか」（どのファイルを直すか、何のコードを書くか、どのコマンドを走らせるか)。誰が決めているかは、計算すればすぐわかる。

1セッションでの往復は約4回。ユーザーが指示を1つ出すたび、Claude は平均約10個のアクション（ファイルを読む、コードを直す、コマンドを走らせる)を自ら実行し、時には100を超えることもある。役割分担は安定しているが、本当の問いは——どんな人がこの分担のもとで良い結果を出せるのか、ということだ。

この研究における「専門家」は、職業でもコーディング能力でもなく、目の前のタスクへの理解度だけを見る。ベテランエンジニアも Rust に初めて触れれば初心者になるし、コードを一度も書いたことのない経理担当者でも、照合ルールを説明でき、Claude が見落とした月末の例外を指摘できれば、その件については専門家だ。

この基準で測ると——理解度が高いほど、セッションは成功しやすく、しかも専門家は指示1つあたり Claude により多くの作業をさせられる（初心者は約5アクション・600字、専門家は約12アクション・3200字)。ただし成功率の伸び方には形がある。前半は急、後半は緩やかだ。

「検証成功率」を専門度5段階で階段状に積む——小互が初心者から専門家へ登るにつれ、足元の段は高くなっていく（達成率が上がる）。だが上に行くほど一段あたりの積み増しは小さくなり、見返りの大部分は「初心者から使いこなせる水準」の段にあり、「使いこなせる水準から頂点」の段にはない。（中間3段は説明のための補間で、実測値は初心者15%と中級以上28〜33%のみ）

「成功率15%対33%」だけでは抽象的すぎる。同じく100回セッションを走らせたら実際に何回成功するかに換算すれば、はっきりする。ここでの「成功」は最も厳しい物差し、検証成功——判定が「成功」であるだけでなく、確たる証拠が必要だ。コードが実際にコミットされた、テストが実際に通った、あるいはユーザーが明確に「完了した」と述べたこと。

さらに意外なのは、職業がほとんど関係ないという点だ。コードを生成したセッションに限れば、データセット中の上位10職種の成功率はいずれもソフトウェアエンジニアの7ポイント以内に収まり、マネジメント系職種はむしろわずかに上回ることさえある。7カ月の間に、バグ修正に費やしたセッションの割合は33%から19%に落ち、浮いた力は運用・ドキュメント作成・データ分析といった一連の作業へ流れ、タスク評価額も約25〜27%上昇した（フリーランス市場の相場と照合した相対的な変化のみで、実額として受け取らないこと)。