関数補完からタスク一括委任への進化とPR大型化が示す変化
まず、明確な傾向としてコード量が増加しています。主な数値データは以下の通りです。
| 見ている指標 | 変化 | データの捉え方 |
|---|---|---|
| 開発者あたり週次追加行数 | 3.6K → 8.6K | コード量が増加 |
| PRあたり追加行数（p75） | 125.86 → 345.02 | PR単位が大型化 |
| 1,000行以上のマージ済みPR | 8.0% → 13.8% | レビュー対象が拡大 |
| agent sessionあたりtool call数 | 113.63 → 145.08 | agent作業が深くなる |
| 受け入れられたAI生成行の60分後残存率 | 76.6% → 80.6% | 短期的に残りやすい |
これらの数値を見ると、一見「AIによって生産性が2倍以上に伸びた」と結論づけたくなるかもしれません。
しかし、生成された行数そのものが価値を直接表すわけではありません。肥大化したPRは実装が進んだ証拠である一方で、人間がレビューすべき対象が増加したことも意味します。1000行を超えるPRが増えれば変更意図を追う負荷が高まり、コードの増加に伴って人間が読み込む面積も広がります。
そのため私は、この数値を単に生産性が上がったと捉えるのではなく、「AIに委ねる仕事の単位（タスク粒度）が大きくなっている」と読み解きたいと考えます。
コード生成量を比べるなら、行数は一つの目安になります。ただ、AIへの仕事の任せ方がどう変わったかを見るには、作業単位にも注目する必要があります。
従来、AIへの依頼は「この関数を修正してほしい」「この型エラーの原因を見てほしい」といった局所的な内容にとどまっていました。
しかし現在は、「このissueを調査し、実装した上で動作確認まで行ってほしい」といった大きな単位で渡すケースが増加しています。行数の増加は、その副産物として表れているのではないでしょうか。
現在のAIは、単一ファイルを補完して終わる存在ではありません。検索し、編集し、シェルを実行しながら、複数ステップの作業を自律的に進めます。
ただし、60分後にコードが残っているからといって、それが長期的に優れた設計や保守性の高いコードであるとまでは断言できません。この数値は、あくまで短期的な残存率として捉えておくのが適切でしょう。
「何を読ませるか」という問いと、Context設計の重要性
このレポートの中で最も関心を引くのは、contextに関するデータです。数値の推移から、明確な方向性が読み取れます。
| 見ている指標 | 値 | データの捉え方 |
|---|---|---|
| 入力tokenと出力tokenの比 | 4.52倍 → 11.41倍 | 読ませる量が増加 |
| non-cache tokenに占める入力割合 | 81.9% → 91.9% | token量はinput中心 |
| AI Lines Gini | 0.77 | 利用はpower usersに集中 |
| p99とp50のAI lines/day比 | 46倍 | 使い方の差が大きい |
AI codingにおいては、「何を書かせるか」よりも「何を読ませるか」というインプットの重要性が増しています。
これは開発現場の実感とも非常に合致するポイントです。AIに質の高いコードを生成させるには、巧みなプロンプトを執筆するよりも、適切な材料を渡すほうが効果的な場面が増加しています。どのファイルを読ませるのか、どの仕様書を提示するのか、どのログやエラー情報を共有するのか、あるいは過去の会話履歴をどこまで保持するか、といった判断が鍵を握ります。
ただし、contextは単に大量の情報を渡せばよいというものではありません。過剰に渡せばAPIコストや待ち時間が増大し、無関係な情報に処理が引っ張られるリスクも生じます。今後重要になるのは、大量に読ませる力ではなく、「読むべき情報を適切に厳選する力」です。これこそが、「AIが円滑に働ける環境を作る」ということの具体像といえます。
Cursorレポートにおけるcontextの増大傾向は、この感覚を裏付けています。AI codingは、単に出力を求める技術から、入力環境を最適に整える技術へとシフトしているのです。
また、power user gapも同様の文脈で捉えられます。この差は個人のスキルの差というよりも「AIに作業をどう任せるか」という習慣の差に起因していると考えられます。組織としては、パワーユーザーの存在を一部の特筆すべき例で終わらせるのではなく、そのノウハウをチーム共通の作法として標準化していくアプローチが効果的です。
