近年、LLM（大規模言語モデル）を活用したコーディング支援が急速に普及している。
しかし、LLMにはいくつかの技術的な制約が存在し、それに伴い様々な課題が生じている。
本稿では、まずLLM活用時に直面しやすい課題を整理し、
その背景にある技術的制約を解説した上で、
どのようにプロジェクト構成や設計を工夫すれば、LLMにも人間にも優しい開発環境を作れるかを考察する。
コンテキスト長の制限により、巨大なコードベース全体を一度に理解させることが困難となる。
依存関係が複雑な箇所では、必要な情報がコンテキスト外に追いやられ、断片的な理解に留まる。
もっともらしいが誤ったコードや説明を生成することがある。
特に、
- 存在しないAPIや関数を提案する
- セキュリティ上問題のあるコードを生成する
- 文脈に合わない処理を挿入する
新しいフレームワークやAPIの仕様変更、
セキュリティパッチやベストプラクティスの更新に追随できず、
古い知識に基づく提案をすることがある。
プロンプトが曖昧だったり、前提条件が明示されていない場合、
意図しないコードを生成したり、仕様と異なる実装を提案することがある。
長い対話や複数回のコード生成を行うと、
命名規則や設計方針がぶれたり、以前の回答と矛盾する提案をすることがある。
- 脆弱性を含むコードを生成する可能性
- 著作権侵害の恐れがあるコード断片の生成
- 差別的・不適切な表現の混入
LLMエージェントとコードのやり取りが増えるほど、通信や処理にかかる時間が長くなり、応答までの待ち時間が増大する。
特に、
- 複数ファイルの送受信
- 長大なコード断片のやり取り
- 複雑な指示や対話の繰り返し
が重なると、開発体験の快適さを損ねる要因となる。
これらの課題の背景には、次に述べるようなLLMの技術的な制約が存在する。
LLMは数千〜数万トークン程度の「コンテキストウィンドウ」内の情報しか保持できない。
Transformerベースのモデルは、入力長に比例して計算コストとメモリ消費が増大するため、現実的な計算資源の範囲で扱えるコンテキスト長には限界がある。
なお、
クラウド上のLLMサービスは豊富な計算資源を活かして比較的長いコンテキストを扱えることが多く、制約はある程度緩和される。
一方で、
ローカル環境で動作するLLMは計算資源が限られるため、より厳しい制約を受け入れざるを得ない。
LLMは一度学習されると、その知識は固定される。
継続的なアップデートがなければ、最新の技術や仕様に追随できない。
LLMは次の単語を確率的に予測する仕組みであり、
学習データに存在しない情報や曖昧な指示に対しては、もっともらしいが誤った内容（幻覚）を生成しやすい。
曖昧な表現や省略された前提を完全に理解することは困難であり、
指示が不明瞭だと誤解や誤った生成が生じやすい。
LLMはトークンを逐次生成するため、長い出力や複数回の対話で一貫性を保つのが難しい。
公開コードやWeb上の情報には、脆弱性を含むコードや不適切な表現も含まれている。
これがセキュリティ・倫理的問題の温床となる。
LLMのこれらの技術的制約は、特に以下のようなアーキテクチャや設計において、
課題を顕在化させ、LLMの活用を難しくする要因となる。
すなわち、技術的制約が設計上の問題を引き起こす構造になっている。
1ファイルが数千行に及ぶ、あるいは密結合な巨大システム。
コンテキスト長の制限により、全体像の理解が困難となる。
グローバル変数やシングルトン、密結合なサービス群。
依存関係が複雑で、必要な情報がコンテキスト外に追いやられる。
設定ファイルや仕様書が複数箇所に散在し、全体像を掴みにくい。
重要な情報が分散しているため、断片的な理解に留まる。
このような構成では、LLMが必要な情報をコンテキストに収めきれず、誤解や誤った提案をしやすくなる。
理由
- 技術的な素養が十分でない利用者は、曖昧な指示や不完全な要望しか伝えられないことが多い
- そのままコーディングを開始すると、誤解や誤提案の原因となる
- 仕様や設計意図のズレを事前に解消することが極めて重要である
具体策
- LLMに仕様案や設計方針のドラフトを作成させる
- それを人間がレビュー・修正・承認する
- LLM側が人間にとって理解しやすく、曖昧さのない仕様案を積極的に提案し、それを人間が確認・受け入れる形で仕様を確定させる
- このような対話的な壁打ちを繰り返し、認識のズレを解消する
効果
- 曖昧さや誤解を事前に排除できる
- 仕様の抜け漏れや矛盾も早期に発見できる
- 合意形成された仕様をもとにコーディングを開始でき、LLMの誤解や幻覚を大幅に減らすことができる
理由
LLMは曖昧な指示や省略された前提を完全に理解できず、意図しないコードや誤解を生みやすい。
仕様や設計意図を明示すれば、LLMはそれをコンテキストとして参照し、より正確な提案が可能となる。
具体策
- 重要な仕様や設計意図は関数・クラスのコメントやJSDoc、docstringに明示的に記述
- 仕様変更や設計判断の背景もMarkdownドキュメントや設計書に記録し、LLMが参照できるようにする
- 前提条件、制約事項、想定ユースケースなども明文化し、曖昧さを排除する
- プロンプトや指示文も具体的かつ明確に記述し、LLMの誤解を防ぐ
効果
- LLMが仕様や意図を理解した上でコード生成・修正を行えるため、誤解や意図しない提案を大幅に減らせる
- 人間の開発者にとっても設計意図や仕様が明確になることで、保守性や引き継ぎが容易となる
理由
コードの意図や仕様が近くにあれば、LLMはそれらを同時に読み込み、より適切な提案ができる。
ドキュメントが別ファイルや別システムに散在していると、コンテキストに含めにくい。
具体策
- 関数やクラスにJSDocやdocstringで説明を付与
- 重要な設計意図や仕様は、同一ディレクトリ内のMarkdownに記述
- 設定ファイルや仕様書も、なるべくコードと同じリポジトリに置く
効果
LLMがコードと仕様を同時に理解しやすくなり、意図に沿ったコード生成やレビューが可能となる。
理由
- 技術的な素養が十分でない利用者は、曖昧な指示や不完全な要望しか伝えられないことが多い。
- そのままコーディングを開始すると、誤解や誤提案の原因となる。
- 仕様や設計意図のズレを事前に解消することが極めて重要である。
具体策
- LLMに仕様案や設計方針のドラフトを作成させる。
- それを人間がレビュー・修正・承認する。
- LLM側が人間にとって理解しやすく、曖昧さのない仕様案を積極的に提案し、 それを人間が確認・受け入れる形で仕様を確定させる。
- このような対話的な壁打ちを繰り返し、認識のズレを解消する。
効果
- 曖昧さや誤解を事前に排除できる。
- 仕様の抜け漏れや矛盾も早期に発見できる。
- 合意形成された仕様をもとにコーディングを開始でき、 LLMの誤解や幻覚を大幅に減らすことができる。
理由
LLMは「局所的な情報の塊」を得意とするため、重要な情報を1箇所に集約すれば、理解の精度が上がる。
情報が分散していると、必要な部分がコンテキスト外に追いやられる。
具体策
- 設定や仕様はなるべく集約し、分散を避ける
- 重要なドメイン知識は専用のドキュメントやコメントにまとめる
- 変更が多い箇所は、変更履歴や意図を明示的に記述
効果
LLMが「この部分の全体像」を把握しやすくなり、断片的な理解による誤りを防げる。
LLMに最適化した構成は、
- 新規参加者が局所的な理解から始めやすい
- レビューや保守がしやすい
- バグの局所化が容易
といった、人間にとってもメリットが大きい。
LLMの制約を逆手に取ることで、結果的に健全な設計・構成を促進できる可能性がある。
こうしたLLMに最適化した構成は、既存の大規模・複雑なプロジェクトに後から適用するのは困難な場合が多い。
一方で、新規プロジェクトの立ち上げ時に意識的に設計・構成することで、より効果的にLLM活用に適した環境を構築できる。
- LLMには技術的制約があり、それに伴い理解困難、幻覚、依存関係の把握困難、応答遅延の増大など様々な課題が生じる
- 広範囲の依存や分散した情報は、LLMの理解を阻害し、やり取りの増大・遅延も招く
- 小さく責務明確なモジュール化、依存の明示、ドキュメントの近接配置、コンテキストを意識した設計が有効
- これらの工夫は、人間の理解や保守性向上にも寄与する
今後は、
- LLMのコンテキスト拡張技術の進歩
- 自動で関連コードやドキュメントを抽出・要約するツールの発展
- LLMに最適化された新しい設計パターンの確立
が期待される。
LLMの特性を理解し、それに合わせた設計・構成を模索することが、これからの開発現場に求められるであろう。
LLMは万能ではないが、その制約を理解し工夫することで、
人間とAIが協調しやすい開発環境を築くことは十分に可能である。
LLM時代の新しい設計論を、今後も模索し続けたい。