AI駆動開発におけるLLMへのコンテキスト渡し方の方法論

はじめに

昨今、開発現場においてGitHub CopilotやCursor、Claude Codeといった生成AIツールを用いた「AI駆動開発」が標準化しつつあります。しかし、現場からは「期待したほどコードの精度が出ない」「複雑な仕様を理解してくれない」という声が依然として多く聞かれます。

実務レベルのコーディングにおいて生成精度を左右する要因は、実はプロンプトそのものではなく、「AIにいかに適切な前提知識（コンテキスト）を渡すか」にあります。

本レポートでは、生成AIにおけるコンテキストの重要性を技術的に紐解き、主要なサービスなどで活用されている5つのコンテキスト提示手法（フルコンテキスト、サマリー、RAG、Grep、LSP）を比較分析します。

生成AIのコード理解精度を左右するコンテキスト重要性

なぜAIによるコーディングにおいてコンテキストがこれほどまでに重要なのでしょうか。 その理由は、LLM（大規模言語モデル）の根本的な仕組みと、ソフトウェア開発特有の「依存関係」にあります。

まず、LLMは確率的に次に来る単語（トークン）を予測しているに過ぎません。 人間がコードを書く際は、無意識のうちに「別ファイルで定義された関数の引数」や「プロジェクト全体のディレクトリ構造」、「共通定数の定義値」を参照しています。 しかし、AIに渡されるプロンプトにこれらの情報が含まれていなければ、AIはそれらを幻覚（ハルシネーション）で補完するしかありません。 これが、存在しないメソッドを呼び出したり、引数の型を間違えたりするバグの主因です。

また、近年のモデルは100万トークン単位の巨大なコンテキストウィンドウを持てるようになりましたが、これには2つの課題があります。

1. コストと速度: 毎回リポジトリ全体を読み込ませれば、APIコストは膨大になります。

2. Lost in the Middle現象: コンテキストが長大になると、AIは入力の中間部分にある情報を忘れたり、無視したりする傾向があることが研究で示されています。

つまり何でもかんでも情報を詰め込んでしまうと、コストがかかる割に精度が上がらないという状況に陥ります。 そもそも、いくらLLMが処理できるトークン長が増大したとはいえ、大規模な開発現場では全ての情報を依然としてプロンプトに乗せきれない事象はまだまだ起こりえます。

したがって、「必要な情報だけを、過不足なく、構造化して渡す」技術こそが、AI駆動開発の生産性を決定づける鍵となります。

主要なコンテキスト提示手法のメリット・デメリット分析

現在、AIにコードの情報を伝えるための手法は大きく5つに分類されます。 それぞれの技術的な仕組みと、実務における長所・短所を解説します。

フルコンテキスト(全文)

最も単純かつ強力なアプローチです。 編集対象のファイルだけでなく、関連しそうなソースコード、Excelの仕様書、Markdownの設計ドキュメントなどを、そのまま生のテキストとしてプロンプトに含める手法です。

• メリット: 情報の欠落が最も少なく、AIが詳細なロジックまで完全に把握できるため、局所的な修正においては最高の精度を発揮します。また、ロジックも単純なので実装も比較的容易です。

• デメリット: 前述の通り、トークン消費が激しくコストがかさみます。また、数十ファイルを超える規模になると、AIの注意機構（Attention Mechanism）が分散し、重要な指示を見落とすリスクが高まります。小規模なスクリプト開発以外では限界があります。

サマリーコンテキスト

コードや仕様書の「要約」を作成し、それをAIに渡す手法です。 例えば、各関数のシグネチャ（関数名、引数、戻り値）とDocstring（説明文）だけを抽出し、実装の中身（Body）を省略した「スケルトンコード」を生成してコンテキストに含めます。 また、仕様書などをコンテキストに乗せたい場合は、文章全体を要約した情報を使ったり、一定範囲（一定文字数やページごと）ごとに分割した仕様書をそれぞれ要約し、それらを統合したものを使用するといった選択肢があります。

• メリット: トークン数を劇的に（数分の一から十分の一程度に）節約しつつ、プロジェクト全体のクラス図や依存関係の概観をAIに伝えることができます。

• デメリット: 「実装の詳細」が伝わらないため、既存のロジックに深く依存する修正（例：ある関数の内部処理の副作用を考慮する必要がある場合）では精度が落ちます。また、サマリーを生成・維持するための仕組み（CTagsなどのツール連携）が別途必要になります。

ベクトル検索（RAG）

コードの断片（チャンク）をベクトル化してデータベース（Vector DB）に保存し、ユーザーの質問と意味的に近いコードを検索（Semantic Search）してプロンプトに注入する手法です。 GitHub Copilotなどがこの仕組みを採用していることが知られています。

• メリット: 数百万行のコードベースであっても、関連しそうな箇所を瞬時に抽出できるスケーラビリティがあります。「認証周りのロジック」のような、キーワードが不明確でも概念的な関連性で検索できる点が強みです。

• デメリット: コード特有の厳密な構造を見落とす弱点があります。例えば、「Userクラスを継承している全てのクラス」を探す場合、ベクトル検索では「継承」という論理的な関係性を保証できず、単に「User」という単語が含まれる無関係なファイルを拾ってくる可能性があります。

検索対象のコードベースやユーザーからのクエリをベクトル化する必要がある都合上、有料ツールでしか利用できない場合が多かったり、次に触れるGrep検索よりやや時間がかかることがあります。

Grep検索

従来のテキスト検索（grepコマンドやripgrepなど）を用いて、特定のキーワードを含む箇所を抽出し、コンテキストとする手法です。Cursorなどのエディタ統合型AIでは、@Codebase機能の一部としてこの手法がバックグラウンドで動いています。

• メリット: 処理が非常に高速で、APIコストもかかりません。特定のエラーコードやユニークな変数名など、検索対象が明確な場合に無類の強さを発揮します。

• デメリット: 「文脈」を理解しません。例えば「saveメソッド」を検索すると、全く関係ないクラスのsaveメソッドまで大量にヒットし、コンテキストにノイズが混入します（同音異義語の問題）。

LSP（Language Server Protocol）活用

現在のAI駆動開発において注目されている、高精度なアプローチです。 VS Codeなどのエディタがコード補完や「定義へ移動」機能のために使用している LSP（Language Server Protocol） の情報をAIに利用させます。

具体的には、AIがコードを修正しようとした際、LSPを通じて「この関数の定義元はどこか？」「この変数はどこで参照されているか？」という情報を問い合わせ、その回答（依存関係グラフやAST：抽象構文木）に基づいて正確な関連ファイルだけをコンテキストに追加します。

この領域では、Serena のようなMCP（Model Context Protocol）を活用した最新ツールが登場しています。Serenaは、AIエージェントがLSPサーバーと直接対話し、シンボル（クラス、関数、変数）単位でコードベースをナビゲートすることを可能にします。

• メリット: 開発者と同じ「認知モデル」でコードを理解できます。テキストの一致ではなく、プログラムの構造（継承関係、呼び出し階層）に基づいて情報を収集するため、ハルシネーションが極めて起きにくく、リファクタリングなどの高難易度タスクに強いです。

• デメリット: 言語ごとにLSPの設定が必要であり、導入のハードルがやや高いです。また、LSPが解析できない動的な依存関係（リフレクションなど）は追跡できません。

手法別比較：精度・コスト・速度から見るAI活用戦略

各手法の特徴を整理した比較表を以下に示します。

まとめ

AI駆動開発におけるコンテキスト渡し方に、万能な「銀の弾丸」は存在しません。 しかし、技術の進化により、複数の手法を組み合わせるハイブリッドなアプローチがスタンダードになりつつあります。

具体的には、以下のような使い分けを推奨します。

1. 「やりたいこと」の探索（RAG）:

「このプロジェクトでログ出力はどうやるの？」といった概念的な質問には、ベクトル検索（RAG）を用いてプロジェクト内の類似コードやドキュメントを探させます。 2. 正確な実装・修正（LSP/Serena）: 「この関数の引数を変更し、影響箇所を修正して」といった具体的なコーディングタスクには、LSPベースのツール（SerenaやCursorのシンボル検索）を用い、依存関係を正確に特定させます。

今後のAI開発ツールは、MCP（Model Context Protocol）のような標準規格により、これらの手法を裏側で自動的に切り替え、開発者が意識せずとも「最適なコンテキスト」がAIに渡される世界へと進化していくでしょう。開発現場としては、LSP対応のツールチェーンを整備し、AIがコードの構造を理解できる環境（型定義の整備など）を整えておくことが、AIの能力を最大限に引き出すための重要な投資となります。