これまで幾つかの記事で広大なコンテキストが必ずしも正しいとは限らないと主張してきました。広大なコンテキストウィンドウは、出力の一貫性と再現性を損なう要因となることがあります。たとえば、厳格な規約を持つReactプロジェクトで「コンポーネント一式を生成してほしい」と依頼した際、Atomic Designの異なるレイヤーの規約が混在し、期待と異なるコード構造が生成されるケースが頻発します。
これは、広すぎるコンテキストがノイズや不要な情報を含むことで、LLMの出力が予測不能になるためです。
本記事では、LLMが回答をするという発想を逆転して、LLMをテストを作成する教師、そしてユーザをテストを受ける学生であるという視点でコンテキストウインドウはテストの出題範囲と位置付けて考察していきます。
1. コンテキストウィンドウの二面性：利便性と一貫性のトレードオフ
コンテキストウィンドウとは、LLMが参照可能な情報（プロンプト、過去の対話、外部データのRAG結果）の範囲であり、教師がテスト問題を作成する際の「教科書やノート」に相当します。
広大なコンテキストウィンドウは以下の利便性を提供しますが、一貫性・再現性の低下を招きます。
- 利便性：プロジェクトの全設定ファイルや広範なコードベースを一度に渡せるため、複雑な要件を包括的に伝えることが可能です。
-
一貫性・再現性の低下：情報量が増えると、LLMがどの情報に優先順位をつけるかが不透明になります。これは 「Lost in the Middle」 現象として知られるものです。LLMは、コンテキストの最初や最後に置かれた情報に比べ、中央部に置かれた情報へのアテンション（注意）が相対的に低下することが確認されています。
- この現象を教師の比喩で表現するなら、教師が「ここをテストに出すぞ」と発言した（重要な指示を与えた）にもかかわらず、その発言を膨大な資料（コンテキスト全体）の中に埋もれさせてしまい、出題の際にその重要度を相対的に低く評価してしまう状況に酷似しています。その結果、教師が出題比率を誤り、生徒が期待と異なる回答を受け取る原因となります。
エンジニアの役割は、教師（LLM）に適切な「テスト範囲」を指定し、一貫性と再現性のある「テスト問題」（出力）を引き出すことにあります。
2. 実例：Reactプロジェクトにおける規約混在のリスク
Reactプロジェクトを例に、広大なコンテキストウィンドウが一貫性・再現性に与える影響を検証します。プロジェクトはTypeScriptを使用し、ESLint（Airbnbルール）でコードスタイルを統一、Atomic Designを採用していると仮定します。
2.1 広すぎるコンテキストのリスク：規約混在と一貫性低下
広大なコンテキスト（全コードベースなど）を提供すると、LLMは異なるレイヤーの規約を混在させるリスクが高まります。
生成結果（不適切な例）:
プロジェクトがtypeとhandleClickを正としているにもかかわらず、コンテキスト内の古いMolecules層のコードに引っ張られた結果です。
interface ButtonProps = { // 規約のtypeと異なる
text: string
onClick: () => void; // 規約の「handleClick」と異なる
};
const Button: React.FC<ButtonProps> = ({ text, onClick }) => (
<div className="molecule-container"> {/* Molecules層の構造が混入 */}
<button onClick={onClick}>{text}</button>
</div>
);
問題点：
意図しない規約が混入し、コードレビューで修正が必要となり、一貫性と再現性が損なわれます。これはLost in the Middle現象により、LLMが最新かつ重要な指示（「このプロジェクトではtypeとhandleClickを使う」という教師の発言）を、古いコード例（コンテキストの中間にあるノイズ）に埋もれさせてしまった結果です。
2.2 小さなコンテキストの効果：一貫性と再現性の向上
一貫性と再現性を確保するには、コンテキストを意図したレイヤーに絞り、必要最小限の情報のみを提供します。
適切なプロンプト例（Few-shot Learning適用）:
以下の規約に基づき、React/TypeScriptのボタンコンポーネントを生成してください：
- Atomic DesignのAtoms層（単一のボタン要素、コンテナなし）。
- TypeScriptを使用、typeで型定義。
- プロパティはlabelとhandleClickを使用。
例：
type ExampleProps = {
label: string;
handleClick: () => void;
};
const ExampleButton: React.FC<ExampleProps> = ({ label, handleClick }) => (
<button onClick={handleClick} type="button">{label}</button>
);
生成結果（適切な例）:
type ButtonProps = {
label: string;
handleClick: () => void;
};
const Button: React.FC<ButtonProps> = ({ label, handleClick }) => (
<button onClick={handleClick} type="button">
{label}
</button>
);
小さなコンテキストと明確な 「過去問」（Few-shot）により、LLMはAtoms層の規約に準拠した一貫性のある出力を生成し、再現性が確保されています。
3. 解決策：小さなコンテキストと狭いウィンドウのモデル
広大なコンテキストウィンドウの利便性を追求するよりも、一貫性と再現性を優先する場合は、以下の戦略が有効です。
3.1 Few-shot Learning：規約の厳選例示
Few-shot Learningは、プロンプト内に意図した規約のコード例を少数含める手法です。この 「過去問」 は、LLMに 出題傾向（必要な一貫性） をピンポイントで教え、ノイズや規約混在を防ぐための最も信頼性の高い戦略（精度の高い情報のキュレーション）です。
3.2 RAGの限界：チャンク欠落による一貫性低下
Retrieval-Augmented Generation（RAG）は、外部の規約ファイルを動的に参照させる手法ですが、一貫性と再現性を損なうリスクがあります。RAGでは、情報がチャンク単位で分割されるため、重要な規約が欠落する可能性があり、予測可能性の低下を招きます。
RAGを活用する場合、参照する情報を厳選し、最新かつ重要な規約のみを確実に含める必要がありますが、Lost in the Middle現象やチャンク欠落のリスクを考慮すると、Few-shot Learningや小さなコンテキストの優先がより信頼性が高いと言えます。
3.3 狭いコンテキストウィンドウのモデルの検討
広大なコンテキストウィンドウを持つモデルは柔軟性が高いものの、その広大なコンテキストウインドウに甘えてしまうと「Lost in the Middle」現象や規約混在により一貫性と再現性が低下しやすい側面があります。一貫性を最重視する場合、コンテキストウィンドウが狭いモデル（例：軽量なLLMやプロジェクト固有の専用モデル）を検討するのも有効です。これらのモデルは、限られた情報に集中するため、ノイズの影響を受けにくいというメリットがあります。
結論：小さなコンテキストで一貫性と再現性を確保
広大なコンテキストウィンドウは利便性を提供しますが、「Lost in the Middle」現象や規約混在により、エンジニアが求める一貫性と再現性が損なわれやすいという落とし穴があります。
エンジニアは、教師（LLM）に 小さな「テスト範囲」（コンテキスト） を指定し、厳選された「過去問」（Few-shotの例）を適用し、必要に応じて狭いコンテキストウィンドウのモデルを活用することで、一貫性と再現性を確保すべきです。
もちろん、コンテキストウインドウの広いモデルを使うべきではないという話ではありません。LLMに与えるコンテキストを可能な限り分割しても1Mや2Mといった広大なコンテキストウインドウが必要になるケースなどでは積極的に使っていくべきです。要は適材適所ですね。