変更要約: GH-300 第3章を新規作成（データの取り扱いと流れ＝文脈収集/プロンプト構築・プロキシフィルタリング/後処理・プラン別のデータ利用/共有/保持、提案のライフサイクルと LLM の限界＝文脈変化→生成→提示→受入/却下の循環・インライン候補の未確定・確率的生成/知識カットオフ/コンテキスト依存/正しさ非保証）
3.2提案のライフサイクルと LLM の限界
コード提案が生成されて受け入れ/却下されるまでのライフサイクルを可視化し、大規模言語モデル（LLM）と Copilot の限界（コンテキスト依存・知識のカットオフ・確率的生成・正しさの非保証）を理解します。
提案がどのように生まれ、消えていくかという ライフサイクル を理解すると、Copilot の挙動を予測しやすくなります。大まかには「文脈の変化を検知 → プロンプト生成 → モデル生成 → 候補を提示 → 利用者が受け入れ/却下 → 新しい文脈で次の提案」という循環です。受け入れた/却下した結果は次の文脈に影響します。
3.2.1コード提案のライフサイクル
入力やカーソル移動で 文脈が変わる たびに、Copilot は新たにプロンプトを組み立ててモデルに渡し、候補を 提示 します。利用者が Tab などで 受け入れる と、その内容が以後の文脈の一部になります。却下 すれば破棄され、次の入力で別の候補が提示されます。インライン補完では「グレー表示の候補」がこの提示段階で、確定するまでコードには反映されません。この循環を理解すると、「なぜこの提案が出たか/出ないか」を文脈から推測できます。
3.2.2LLM と Copilot の限界
Copilot の中核は LLM であり、その性質に由来する限界があります。
①確率的生成：同じ文脈でも出力は揺れ、常に最適とは限らない。
②知識のカットオフ：学習時点以降の情報を知らない。
③コンテキスト依存：与えた文脈の質と量に強く左右され、無関係/不足だと精度が落ちる。
④正しさの非保証：もっともらしくても誤り得る（ハルシネーション, 第1章）。これらは「設定で消せるバグ」ではなく モデルの本質的な特性 なので、運用（検証・プロンプト改善）で補います。
頻出：
①提案のライフサイクル＝文脈変化→プロンプト→生成→提示→受入/却下→次の文脈（受入が次の文脈に影響）。
②インライン候補は確定まで未反映。
③LLM の限界＝確率的生成/知識カットオフ/コンテキスト依存/正しさ非保証。
④限界は設定で消せない本質的特性＝運用（検証・プロンプト改善）で補う。
混同・注意：
①同じ文脈でも出力が変わるのは不具合ではなく確率的生成の性質。
②提案が出る/出ないは文脈に強く依存——「機能の故障」と決めつけない。
③限界は「設定で無効化」できるものではない＝検証とプロンプト改善で補う。
④インラインのグレー候補は受け入れるまでコードに入っていない。
3.2.3この節のまとめ
- 提案のライフサイクル：文脈変化→プロンプト→生成→提示→受入/却下→次の文脈
- インラインのグレー候補は確定まで未反映
- LLM の限界：確率的生成・知識カットオフ・コンテキスト依存・正しさ非保証
- 限界は本質的特性＝検証とプロンプト改善で運用的に補う
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. インライン補完で表示される「グレー表示の候補」について正しいものはどれですか？
Q2. 同じコード文脈でも Copilot の提案内容が毎回少し異なることがあります。これは何によるものですか？
Q3. Copilot が最新のライブラリ仕様を反映できないことがある根本原因はどれですか？
Q4. 提案の精度が低いとき、ライフサイクルの理解から導ける改善アプローチはどれですか？
Q5. LLM/Copilot の限界に対する正しい向き合い方はどれですか？
Q6. 受け入れた提案が以後の挙動に与える影響として正しいものはどれですか？