Cursor,Claude Codeなどが一回で読み込める行数について調べる
きっかけ
CursorやRoo Codeなどで関数が再生成されたりなどの問題が発生する原因を特定したかった
各プロパイダごとの情報
※ 2025年4月26日現在の情報です
各プロパイダごとにファイルごとに何行ごとずつ読んでいるかが違います
- Cline: ファイルサイズで規定（300KB）
- Roo Code: Cline+ デフォルトが500行、行数は可変
-
（非公式）Claude Code: 2000行
公式ソースはないですが有志によりいくつか調査が行われているようです
都合によりソース元は省略します。 -
Cursor: 500行 => 250行
- Codex: 最大行数は未定義、ただし実際はcontext長を超えるとエラーが出て分割依頼が出る
- （非公式）Windsurf: 200行（ただしシンボルで概要を把握している）
- Github Copilot Agent: 500行以上で要約が走る
- Devin: 分割している行数はわからないが、RAG形式で把握している
これは何を意味するか？
Gemini 2.5 Proを用いてもClaude 3.7 Sonnetを用いても
上記の行数でぶつ切りにされてしまうので
長い行数のファイルはあんまりコンテキストが活かせてないということになります。
ただこれは開発側としては妥当で
モデルによって可変させるようにするには多少面倒ですし、費用面が上がったというネガティブな判断にもつながりかねません。
またCursorのようなVector Indexingを採用している場合、chunkが小さいことで検索の正しさが上がります。
またこれによって全体を把握している可能性がありますが型情報とかは抜け落ちている可能性があります。
この場合は一長一短ですね。
そもそも長いコードを取得することをデフォとしない方がLLMからのリターンが早くてユーザー体験が良い可能性もあります。
ぶつ切りになっているとコンテキストが活かせない根拠
By only keeping the last 512 tokens as code context (w/o out-of-window context), we can see that the performance is nearly the same as UniXcoder … which shows the importance of modeling long code context.
最後の512トークンのみをコードコンテキストとして保持することで（ウィンドウ外のコンテキストなしで）、性能はUniXcoderとほぼ同じであることがわかります。これは、長いコードコンテキストをモデル化することの重要性を示しています。
Our experimental results demonstrate that code completion can benefit from taking longer context into consideration, and our LongCoder achieves superior performance
私たちの実験結果は、コード補完がより長いコンテキストを考慮に入れることで恩恵を受けられることを示しており、私たちのLongCoderは優れた性能を達成しています。
長い文脈を確保できると固定長より良い性能を示す、的な話です。
なぜClaude Codeが高いのか
上記からClaude Codeだけ圧倒的に読み込み行数が多いです。
これによりtoken消費数がえげつないことになっていると思われます
そもそものPromptもかなり分厚く作られているのでは...?という話もあります。
結論
ここから以下のような結論になります
エディタの選び方
行数の長いコードを書きたい、もしくは細かいことをあんまり気にせずVibe codingしたい場合
=> Cline、Codex、Roo Code（制限変更済み）、Claude Code
（OpenAIとかClaudeが自前でCLIのエディタを出してきたのはこういう理由も一つありそうですね）
こちらでもvibe codingで推奨されています
フォルダ全体を走査しつつ、細かい不整合性は自分で修正してなんとかする場合
=> Cursor、Windsurfなど
おまけ
興味を持ってもらえたらフォローいただけると嬉しいです🙇
過去の記事
現状ローカルLLMでできることについて
各エディタを使う上で必要なことなど
Discussion