Cursor / Clineを使う上でもっとも重要なことの一つ: コンテキストウインドウについて
Cursor/Clineを使う上で重要なこととして、LLMのコンテキストウインドウを意識しないと
1. 逐一指示をして対応するものの「Lost in Middle」現象でうまく指示が通らなくなる
2. 良いパフォーマンスが出せていないのでルールを無秩序に追加する
3. 「Lost in Middle」は解消されるがその結果早い段階でタスクのコンテキストウィンドウをはみ出す
4. Cursor/Clineがループしたり性能が落ちるのを確認する
6. 結果現状のAIの性能、判断に対して幻滅しAIを使うのをやめてしまう
というようなことが起こります。
そのためにもコンテキストウィンドウを意識することは非常に大事です。
以前のバイアスに関する記事を読んでいただいた人向け
前回は人間側の問題を提示しました
今回は人間側の問題ではなく、LLM側の問題になるのと
ある程度実際に出ている結果からの判断になるので同じようなことを
別ベクトルで言っているつもりです。
また今回はPKMとかは出てこないので安心してください（？）
まず、コンテキストウインドウとは何か？から説明します。
コンテキストウィンドウとは
コンテキストウィンドウとは、モデルが一度に処理できるトークン数のことを指す。トークンとは、単語、画像、動画の一部分など、モデルが扱う最小単位だ。テキストであれば、英語の場合、100トークン＝75ワードほど、日本語の場合、100トークン＝100文字ほどとなる。
コンテキストウィンドウの限界
LLMは「コンテキストウィンドウ」と呼ばれる一定量のトークンしか同時に処理できません。（Claude 3.7 Sonnetの場合200Kまで）
この限界付近になると一般的には以下のような問題が発生します：
-
情報保持の非一貫性
- 先行するコンテキストで確立された規則や修正が、後続の応答で維持されない
- セッションが長くなるほど情報の断片化が進行
「Lost in the Middle」（中間部分での情報喪失）
これによる弊害として
反復的修正サイクル
- 同じ問題を何度も修正させる必要がある
- 例：エラーハンドリングを共通化するよう修正したのに、次の機能追加で元の実装パターンに戻る
-
推論能力の低下
- 複数ステップの推論タスクでの成功率が著しく低下
- 論理的一貫性の欠如や循環論法などの症状
（追記3/24 16:30）主題として正しくないので取り消し
（論文はそれを避けるための方法ですが、論文内で数値的に言及されています）
https://arxiv.org/abs/2502.07365
これによる弊害として
循環論法と繰り返し
- 同じ思考パターンを繰り返す
- 思考の進展がなく同じところをぐるぐる回る
Xで「Cline ループ」や「Cursor ループ」など検索するとたくさん出てきます。
セマンティック干渉
- 類似する概念間での混同
- 新しい情報が入力されると、古い情報が歪曲または置換される
型情報が保持されていなかったり、あるいは似たような情報で混乱したりなどします。
この辺に関するDeepResearchのサーベイ
（追記3/24 16:30）これらのサーベイに対して不足があったので、OODに関してまとめた資料を追加
Rulesの再定義
これらの技術的制約を理解した上で、Rulesの本質的な価値を再考する必要があります。
従来の誤解
Rulesに関して、以下のような誤解が広がっていました：
- 「業界標準のベストプラクティスを網羅すべき？」
- 「記述される問題をすべて解決できる？」
- 「詳細であればあるほど良い？」
しかし、LLMの技術的制約を考慮すると、これらのアプローチが必ずしも効果的ではないことが分かります。
コンテキスト圧縮としてのRules
LLMの限界を踏まえると、Rulesの価値ある役割の一つは「コンテキストの効率的な圧縮」だと言えます：
-
情報密度の最適化
- 周辺ファイルをすべて見せるより、本質的なパターンを抽象化して伝える方が効率的
-
作業記憶の温存
- LLMの限られた「思考能力」を保護するため、作業記憶を温存
- 不必要な情報が占める領域を減らし、実際の課題に思考リソースを集中
-
プロジェクト固有の知識伝達
- ディレクトリ構造、命名規則など、プロジェクト固有の最小限の情報を効率的に伝達
（もし）Rulesを逐次追加するとどうなってしまうのか？
Rulesの無秩序な追加がもたらす悪循環を以下に書きます。
フェーズ
フェーズ1: 初期の改善と誤った希望
最初の基本的なルール（ディレクトリ構造や命名規則など）は明確な改善をもたらす
この初期成功から「ルールを追加すれば改善する」という誤った信念が強化される
より多くのルールを追加すれば、さらに良くなるという期待が生まれる
フェーズ2: 期待と現実のギャップ
ルールを追加しても、期待した改善が見られなくなる
「ルールが不十分」または「ルールが不明確」と誤診断される
対応策として、さらに詳細なルールや例外ルールが追加される
フェーズ3: 逆効果のエスカレーション
ルール量とコードの読み込みによってコンテキストウィンドウを超過し、LLMのパフォーマンスが急激に低下し始める
中間に位置するルールが完全に無視され、同じミスが繰り返される
この問題を「さらなるルール」で修正しようとする悪循環
コンテキスト崩壊
パラドキシカルな性能低下：ルールが多すぎて基本的なタスクすら遂行できなくなる
一貫性のない適用：最初と最後のルールは遵守されるが、中間ルールは無視される
自己矛盾する実装：同じファイル内で矛盾するコーディングパターンが混在
思考能力の完全な低下：循環論法や思考の繰り返しが顕著になる
効果的な戦略：LLMの制約を踏まえたアプローチ
LLMの技術的制約を前提とした、より効果的な戦略を以下に提案します：
1. タスク設計の最適化
-
セッションごとにタスクを完結させる
- 各セッションは独立した作業単位として扱う
- コンテキスト窓が飽和する前にタスクを完結させる
-
タスクを細かく切る
- 大きな開発作業を小さな独立したタスクに分割
- 各タスクが単一のファイルや機能に集中するよう設計
-
計画を明確にする
- 最初に明確な計画と期待成果を設定
- 「何を作るか」の指示を具体的にし、検証基準を明示
Devinの開発チームはこれを把握していて、ルールにも書いています。
上記で述べてきた通りコンテキストウィンドウの問題から
DevinでそうなのであればClineもCursorも基本的にやるべきことは同じです。
2. 効率的なRulesの設計
-
最小限の必要情報に集中
- プロジェクト固有の本質的な情報のみを含める
- ディレクトリ構造、命名規則、主要なアーキテクチャパターン
-
抽象度と具体性のバランス
- 過度に抽象的すぎず、細かすぎない適切な粒度
- 具体例の効果的な活用
-
手続きとナレッジの区別
- 「どのように考えるか」より「何を作るか」の情報を優先
- LLMの限られた注意リソースを効率的に使用
Devinでは効率よくKnowledge（=Rules）を取得できるシステムがあるものの
"一般的なバグとその関連ソリューション、コード準拠のプラクティス、デプロイメント ワークフロー、テスト ワークフロー、独自のツールの操作方法"
などの具体的なものを推奨しています。
ここからもコンテキストウィンドウの圧縮に対する工夫として捉えられると思います。
またCursorでもファイルパターンマッチングなどを駆使して効率よくルールを制御するシステムが設けられています
3. 現実的な期待値設定
-
LLMの限界を認識
- 完璧な結果を期待せず、検証の重要性を理解
- 特定の問題は技術的制約によるものであり、ルールだけでは完全に解決できない
-
ツールとしての適切な使い方
- 「万能の開発者」ではなく「制約のある強力なツール」として位置づけ
- 人間による検証と組み合わせた効果的なワークフロー
まとめ
LLMコーディングエージェントのRulesは、単なる「良いプラクティス集」ではなく、LLMの技術的制約を踏まえた「コンテキスト圧縮のための効率的情報伝達ツール」として捉え直す必要があります。
最も効果的なアプローチの一つは、「セッションごとにタスクを行う」「タスクを細かく切る」「計画を明確にする」という基本戦略と、「最小限の必要情報に集中した」Rulesを組み合わせることです。
この技術はまだ黎明期にあり、何を目的とするかという根本的な部分さえ定まっていない状況です。しかし、LLMの根本的な制約を理解した上で現実的な期待値を設定し、適切な戦略を採用することで、その潜在能力を最大限に引き出すことができるでしょう。
おまけ
この記事をClaudeと書いている最中に図を生成してもらったのですが、悲惨な図が上がってきてしんどい気持ちになったのでセッションを切り替えて何度が図を生成してもらいました...
コンテキストが長くなった時のイメージがしやすいと思うので貼っておきます
悲惨な図
Discussion
コンテキストウィンドウの限界を超えた場合の問題について2つの論文が参照されていますが、"Lost in the Middle"論文の方はコンテキストウィンドウに収まる入力において中間の情報が軽視される問題、"LongReD"論文はコンテキストウィンドウに対して短い入力のとき性能が落ちる問題についての話で、コンテキストウィンドウの限界を超えた際の挙動とは関係ないのではないでしょうか？
コメントありがとうございます！
そちら二点明確に引用箇所を用意しますね！
ご確認ありがとうございました🙇
こちらいくつか自分の主観が入っていたため直接的ではない引用になっていたと思います🙇
主題としてはおっしゃる通り「コンテキストウィンドウに収まる入力において中間の情報が軽視される問題」なのですが
長いコンテキストが必ずしも有益ではなく、推論の複雑さを増し、精度を低下させる可能性について述べているので同様にコンテキストウィンドウに収まらない入力もLost in Middle論文の内容の影響を受けると考えています。
こちらも
と書いているので持ってきてしまいましたが、本来はこの引用元であるout-of-distribution （OOD）に関する論文を引いてくるのが正しいと思います。
Lost in Middleに関しては現実のケース（つまり中央の指示が通らない）を主題としているので引き続きこちらは続けて
LongReD論文の方は主張として乏しいのでOODに関する論文を追加する対応をします。
ご指摘ありがとうございます。