Coding Agentを使う上でもっとも重要なことの一つ: コンテキストウインドウについて

Cursor/Clineを使う上で重要なこととして、LLMのコンテキストウインドウを意識しないと

1. 逐一指示をして対応するものの「Lost in Middle」現象でうまく指示が通らなくなる
2. 良いパフォーマンスが出せていないのでルールを無秩序に追加する
3. 「Lost in Middle」は解消されるがその結果早い段階でタスクのコンテキストウィンドウをはみ出す
4. Cursor/Clineがループしたり性能が落ちるのを確認する
6. 結果現状のAIの性能、判断に対して幻滅しAIを使うのをやめてしまう

というようなことが起こります。
そのためにもコンテキストウィンドウを意識することは非常に大事です。

以前のバイアスに関する記事を読んでいただいた人向け

前回は人間側の問題を提示しました
https://zenn.dev/tesla/articles/763568928c7175

今回は人間側の問題ではなく、LLM側の問題になるのと
ある程度実際に出ている結果からの判断になるので同じようなことを
別ベクトルで言っているつもりです。
また今回はPKMとかは出てこないので安心してください（？）

まず、コンテキストウインドウとは何か？から説明します。

コンテキストウィンドウとは

https://www.sbbit.jp/article/cont1/142381

コンテキストウィンドウとは、モデルが一度に処理できるトークン数のことを指す。トークンとは、単語、画像、動画の一部分など、モデルが扱う最小単位だ。テキストであれば、英語の場合、100トークン＝75ワードほど、日本語の場合、100トークン＝100文字ほどとなる。

コンテキストウィンドウの限界

LLMは「コンテキストウィンドウ」と呼ばれる一定量のトークンしか同時に処理できません。（Claude 3.7 Sonnetの場合200Kまで）
この限界付近になると一般的には以下のような問題が発生します：

1. 情報保持の非一貫性
   • 先行するコンテキストで確立された規則や修正が、後続の応答で維持されない
   • セッションが長くなるほど情報の断片化が進行

「Lost in the Middle」（中間部分での情報喪失）
https://arxiv.org/abs/2307.03172

これによる弊害として

反復的修正サイクル

• 同じ問題を何度も修正させる必要がある
• 例：エラーハンドリングを共通化するよう修正したのに、次の機能追加で元の実装パターンに戻る

---

2. 推論能力の低下
   • 複数ステップの推論タスクでの成功率が著しく低下
   • 論理的一貫性の欠如や循環論法などの症状

（追記3/24 16:30）主題として正しくないので取り消し
（論文はそれを避けるための方法ですが、論文内で数値的に言及されています）
~~https://arxiv.org/abs/2502.07365~~

これによる弊害として

循環論法と繰り返し

• 同じ思考パターンを繰り返す
• 思考の進展がなく同じところをぐるぐる回る

Xで「Cline ループ」や「Cursor ループ」など検索するとたくさん出てきます。

セマンティック干渉

• 類似する概念間での混同
• 新しい情報が入力されると、古い情報が歪曲または置換される

型情報が保持されていなかったり、あるいは似たような情報で混乱したりなどします。

この辺に関するDeepResearchのサーベイ
https://note.com/delta_ipsilon/n/nbcbe266da163

（追記3/24 16:30）これらのサーベイに対して不足があったので、OODに関してまとめた資料を追加
https://note.com/delta_ipsilon/n/n3e0ccf32ac77

Rulesの再定義

これらの技術的制約を理解した上で、Rulesの本質的な価値を再考する必要があります。

従来の誤解

Rulesに関して、以下のような誤解が広がっていました：

• 「業界標準のベストプラクティスを網羅すべき？」
• 「記述される問題をすべて解決できる？」
• 「詳細であればあるほど良い？」

しかし、LLMの技術的制約を考慮すると、これらのアプローチが必ずしも効果的ではないことが分かります。

コンテキスト圧縮としてのRules

LLMの限界を踏まえると、Rulesの価値ある役割の一つは「コンテキストの効率的な圧縮」だと言えます：

1. 情報密度の最適化

   • 周辺ファイルをすべて見せるより、本質的なパターンを抽象化して伝える方が効率的

2. 作業記憶の温存

   • LLMの限られた「思考能力」を保護するため、作業記憶を温存
   • 不必要な情報が占める領域を減らし、実際の課題に思考リソースを集中

3. プロジェクト固有の知識伝達

   • ディレクトリ構造、命名規則など、プロジェクト固有の最小限の情報を効率的に伝達

（もし）Rulesを逐次追加するとどうなってしまうのか？

Rulesの無秩序な追加がもたらす悪循環を以下に書きます。

フェーズ

フェーズ1: 初期の改善と誤った希望

最初の基本的なルール（ディレクトリ構造や命名規則など）は明確な改善をもたらす
この初期成功から「ルールを追加すれば改善する」という誤った信念が強化される
より多くのルールを追加すれば、さらに良くなるという期待が生まれる

フェーズ2: 期待と現実のギャップ

ルールを追加しても、期待した改善が見られなくなる
「ルールが不十分」または「ルールが不明確」と誤診断される
対応策として、さらに詳細なルールや例外ルールが追加される

フェーズ3: 逆効果のエスカレーション

ルール量とコードの読み込みによってコンテキストウィンドウを超過し、LLMのパフォーマンスが急激に低下し始める
中間に位置するルールが完全に無視され、同じミスが繰り返される
この問題を「さらなるルール」で修正しようとする悪循環

コンテキスト崩壊

パラドキシカルな性能低下：ルールが多すぎて基本的なタスクすら遂行できなくなる
一貫性のない適用：最初と最後のルールは遵守されるが、中間ルールは無視される
自己矛盾する実装：同じファイル内で矛盾するコーディングパターンが混在
思考能力の完全な低下：循環論法や思考の繰り返しが顕著になる

効果的な戦略：LLMの制約を踏まえたアプローチ

LLMの技術的制約を前提とした、より効果的な戦略を以下に提案します：

1. タスク設計の最適化

• セッションごとにタスクを完結させる

  • 各セッションは独立した作業単位として扱う
  • コンテキスト窓が飽和する前にタスクを完結させる

• タスクを細かく切る

  • 大きな開発作業を小さな独立したタスクに分割
  • 各タスクが単一のファイルや機能に集中するよう設計

• 計画を明確にする

  • 最初に明確な計画と期待成果を設定
  • 「何を作るか」の指示を具体的にし、検証基準を明示

Devinの開発チームはこれを把握していて、ルールにも書いています。
上記で述べてきた通りコンテキストウィンドウの問題から
DevinでそうなのであればClineもCursorも基本的にやるべきことは同じです。
https://docs.devin.ai/essential-guidelines/when-to-use-devin

2. 効率的なRulesの設計

• 最小限の必要情報に集中

  • プロジェクト固有の本質的な情報のみを含める
  • ディレクトリ構造、命名規則、主要なアーキテクチャパターン

• 抽象度と具体性のバランス

  • 過度に抽象的すぎず、細かすぎない適切な粒度
  • 具体例の効果的な活用

• 手続きとナレッジの区別

  • 「どのように考えるか」より「何を作るか」の情報を優先
  • LLMの限られた注意リソースを効率的に使用

Devinでは効率よくKnowledge（=Rules）を取得できるシステムがあるものの
"一般的なバグとその関連ソリューション、コード準拠のプラクティス、デプロイメント ワークフロー、テスト ワークフロー、独自のツールの操作方法"
などの具体的なものを推奨しています。
ここからもコンテキストウィンドウの圧縮に対する工夫として捉えられると思います。

https://docs.devin.ai/onboard-devin/knowledge#what-belongs-in-knowledge%3F

またCursorでもファイルパターンマッチングなどを駆使して効率よくルールを制御するシステムが設けられています
https://docs.cursor.com/context/rules-for-ai

3. 現実的な期待値設定

• LLMの限界を認識

  • 完璧な結果を期待せず、検証の重要性を理解
  • 特定の問題は技術的制約によるものであり、ルールだけでは完全に解決できない

• ツールとしての適切な使い方

  • 「万能の開発者」ではなく「制約のある強力なツール」として位置づけ
  • 人間による検証と組み合わせた効果的なワークフロー

まとめ

LLMコーディングエージェントのRulesは、単なる「良いプラクティス集」ではなく、LLMの技術的制約を踏まえた「コンテキスト圧縮のための効率的情報伝達ツール」として捉え直す必要があります。

最も効果的なアプローチの一つは、「セッションごとにタスクを行う」「タスクを細かく切る」「計画を明確にする」という基本戦略と、「最小限の必要情報に集中した」Rulesを組み合わせることです。

この技術はまだ黎明期にあり、何を目的とするかという根本的な部分さえ定まっていない状況です。しかし、LLMの根本的な制約を理解した上で現実的な期待値を設定し、適切な戦略を採用することで、その潜在能力を最大限に引き出すことができるでしょう。

おまけ

この記事をClaudeと書いている最中に図を生成してもらったのですが、悲惨な図が上がってきてしんどい気持ちになったのでセッションを切り替えて何度が図を生成してもらいました...
コンテキストが長くなった時のイメージがしやすいと思うので貼っておきます

悲惨な図

Cline使いの方はこちらも

https://zenn.dev/tesla/articles/33d196d17bf3bb