📕

なぜ、ここ2年でChatGPTのプログラミング能力がめっちゃ上がったのか？

に公開
AI
プログラミング
ChatGPT
LLM
idea

はじめに

この二年間で、ChatGPTを含む大規模言語モデル（LLM）のコード生成は、短いスニペットの提案段階から、中規模アプリケーションや複数ファイルにまたがる実装のドラフト作成・修正まで現実に使えるレベルへと跳ね上がりました。しばしば“モデルが賢くなったから”と語られますが、実態はもっと無骨です。決定打は、**LLM本体の改良そのものではなく、外側に築かれた外骨格（検証・検索・実行・探索管理の統合構造）**と、十万〜百万トークン級へ拡張したコンテキスト（入力＋出力の合計）です。つまり、メインエンジンは全体の一部分にすぎず、主戦場はモデルの外。以下ではその構図を順に解きほぐし、最後に未解決の弱点（いわゆる鳥頭問題）を整理します。

LLM単体ではコード生成は難しい

LLMは確率的に次トークンを選ぶ生成器で、曖昧さを許容できる言語タスクに強みがあります。ただ、コーディングは曖昧さを嫌うゲームです。ここでの失敗コストは、文章の“違和感”ではなくビルドエラーや実行時例外、仕様逸脱として露出します。だからこそ、以下の厳密さが効いてきます。

  • 構文の厳密さ：一文字でビルドが止まる
  • 意味の厳密さ：形式的に正でも仕様どおりに動くとは限らない
  • 外部仕様への適合：API／ライブラリ制約の順守
  • モジュール整合性：複数ファイル・層間の一貫性

GPT-3.5世代で露呈していたのは、これらをモデル内部だけで同時に満たすことの難しさでした。未定義シンボル、テスト未考慮、依存の破綻——いずれも「言語モデル的に尤もらしい」ことと「機械的に正しい」ことのギャップが原因です。このギャップを埋めたのは、モデルの賢さの増量ではなく、外側の工学的仕掛けでした。

主戦場はLLMの外にある（外骨格が主役）

現在の“AIコーディング”は、LLMが案出し（ドラフト生成）を担い、その外側で決定的（デターミニスティック）なエンジンが検証・修正・統合を担当する、役割分担のアーキテクチャです。具体的には、構文・型チェックや静的解析、データフロー解析、シンボリック実行／SMTソルバによる制約充足、サンドボックス実行とログ回収、RAG（検索拡張生成）で仕様や既存コードを前段に供給——これらが外側のループを形成し、ドラフトを機械的にふるい続けます。
ポイントは、ここで得られる改善は一回の“正答”ではなく、収束するプロセスそのものだということです。モデルが出す“もっともらしさ”に依存せず、外骨格が失敗を検出してはリジェネレートを指示し、段階的に品質を上げる。伸びたのは“知能”よりもプロセス設計と統合工学です。

メモリ資源の拡張がプロセスを変えた

外骨格が効く条件として、長大な文脈と十分な出力長が必要です。ここ2年で、コンテキスト長（入力＋出力の合計）は実運用に耐えるレベルへ拡張されました。これにより、プロジェクト全体のコードベース、依存関係、API仕様、設計資料、テスト方針を一度に抱えたまま生成・修正できるようになり、途中で忘れる／切れるが激減しました。結果、上流（仕様・設計）から下流（実装・テスト）までの一貫性が、初めて“現実的な前提”になったのです。
さらに、長出力が許すのは“長い回答”ではなく**“まとまった変更”です。パッチやマイグレーションを最初から最後までひと括り**で提案できると、外骨格側の適用・検証が一気に簡単になります。長文脈×長出力×外骨格の三位一体で、初めて“運用で使える”水準に到達しました。

参考：主要モデルのコンテキスト長の推移（代表例・入力＋出力の合計）

  • GPT-3.5：おおむね 4K → 16K
  • GPT-4 無印 → GPT-4 Turbo／4o：8K／32K → 128K
  • Claude 3.5 Sonnet：200K
  • Gemini 1.5：128K → 1M級
  • GPT-4.1系：1M級
    ※ベンダやエディションで差異はありますが、「数千 → 数十万 → 百万トークン級」の段階的拡張が大勢です。同じ総枠内で入力を増やせば出力は減るため、実務では要約・分割・再配置などのプロンプト設計とチャンク戦略が依然として効きます。

外骨格側の要素技術が一気に制度化

外骨格の内訳は、この二年で“研究プロト”から“運用設計”へと昇格しました。まず、出力のスキーマ化と差分化。JSON Schemaや強制スキーマ出力、diff／patchで変更を機械可読に固定し、そのまま適用→静的解析→テストのパイプラインへ流します。次に、探索制御と評価ループの標準化。Chain-of-ThoughtやSelf-Consistencyで複数案を出し、静的解析・テスト・LSP（Language Server）連携の結果をスコアにして再生成を指示する。“一発勝負”をやめ、スコア駆動の収束に切り替えたわけです。
さらに、RAG×長文脈の相乗で**“正しい呼び方”と依存関係を常時参照可能にしました。APIリファレンスや既存コードを埋め込み検索→前段統合し、プロンプト内で具体的シンボルへアンカーします。加えて、OCR／UI画像解析→テキスト・構造化によって、画面や図面の情報を検索・検証パスに投入可能に。見かけは“視覚を得たAI”でも、実体は前処理と統合の勝利**です。

製品間の差は「LLM以外」で決まる

同じ世代の基盤モデルでも、IDE統合の深さ、型エンジンの賢さ、差分適用の保守性、社内APIメタデータとの照合、サンドボックス実行の粒度、自己修正ループの設計で体験は激変します。ユーザーの目には「自然文→数秒→コード」とシンプルに映りますが、裏側では多段の検証・検索・実行がオーケストレーションされている。今の優劣は、LLM本体ではなく外骨格の編成力で決まる局面に入っています。だからこそ、企業導入ではモデル選定＝外骨格選定であり、既存リポジトリ／CI／セキュリティ方針との“結線容易性”がROIを左右します。

なお、残る弱点（鳥頭問題）

長文脈で“忘れにくく”なっても、同じ不適解を蒸し返す堂々巡りは残ります。原因は主に三つです。

  • 排他的制約の弱さ：不適解を恒久除外し続けるメモリ／ルールが弱い
  • 分布の偏り：頻出解が確率的にいつまでも候補に残る
  • 探索縮約の不足：棄却・封印の管理が甘く、探索空間が収束しない

解はやはり外側にあります。探索ログの外部管理で不適解を強制的に除外し、SMTソルバ等で「AもBも不可」を明文化、さらに計画的多様化で下位候補を意図的に試す。ここを制度化できるかが、**「覚えていて、同じ過ちを繰り返さないAI」**への分岐点です。

まとめ

この二年の飛躍は、LLM本体が万能化したからではありません。実際に効いたのは、

  1. 外骨格（検証・検索・実行・探索管理）の制度化、
  2. コンテキスト長の段階的拡張（数千→十万→百万トークン級）と長出力、
    という**“構造とメモリ”の進化**です。メインエンジンは必要条件ですが、全体の一部分にすぎない。次の一歩も外側にある。すなわち、除外推論と探索管理の標準装備化で、失敗の再発をシステム的に断つこと——ここまで来て、ようやく“AIがチームに常在する”開発様式が完成形に近づきます。

Discussion