「ChatGPTを導入したけれど、結局社内の独自フレームワークを使ったコードは書いてくれないし、古いCOBOLシステムの改修には役に立たない」
最近、SIerの現場や事業会社の開発リーダーの間で、こうした課題が頻繁に議論されるようになっています。汎用的なAIツールは、PythonやJavaScriptのようなメジャーな言語、そして一般的なアルゴリズムに関しては驚異的な能力を発揮します。しかし、企業の中に眠る「秘伝のタレ」のような独自ライブラリや、特定の業界でしか使われないドメイン固有言語（DSL）に対しては、途端に「幻覚（ハルシネーション）」を起こし始めます。
それもそのはずです。汎用モデルは、インターネット上に公開されている「一般的な知識」の平均点を取るように訓練されているからです。社内のクローズドなリポジトリにある知識は、モデルにとっては未知の世界なのです。
そこで注目されているのが、「特定ドメイン・特定言語に特化した小規模LLMの構築」です。
「自前でモデルを作るなんて、コストと手間がかかりすぎるのでは？」
そう思われるかもしれません。確かに、数年前まではそうでした。しかし、LlamaモデルやStarCoder2といった高性能なオープンソースモデルの登場と、LoRA（Low-Rank Adaptation）などの効率的なファインチューニング技術の普及により、現実的なコストで「自社専用のAIエンジニア」を作ることが可能になっています。
今回は、単なるプロンプトエンジニアリングでは超えられない壁を突破し、ROI（投資対効果）を最大化するための、「コード生成に特化したモデル構築の技術的ベストプラクティス」について、実践的なデータ前処理の手法も含めて論理的かつ体系的に掘り下げていきます。
なぜ「特定言語特化」が必要なのか：汎用モデルの死角とROI
まず、技術的な投資判断を行うための前提として、なぜ汎用モデルでは不十分なのか、その構造的な限界を整理しておきましょう。AIはあくまで手段ですが、目的とするビジネス課題の解決には、適切な技術選定が不可欠です。
汎用LLMが苦手とする「社内DSL」と「レガシー言語」の壁
ChatGPTやClaudeの最新モデルといった最先端のフロンティアモデルは、GitHub上の公開コードを大量に学習しています。そのため、ReactやDjangoといったオープンかつ標準的な技術スタックであれば、シニアエンジニア顔負けのコードを書くことができます。
しかし、エンタープライズ開発の現場はもっと複雑です。
- 社内製ラッパーライブラリ: 標準ライブラリをラップした独自のセキュリティ機構やログ出力機構。
- ドメイン固有言語（DSL）: 金融商品の記述や、製造装置の制御に使われる独自のスクリプト。
- レガシー言語の方言: メインフレーム上で動作する特定のベンダー仕様のCOBOLやPL/I。
これらは学習データに含まれていないため、汎用モデルにとっては「存在しない言語」です。無理に書かせようとすると、メソッド名を捏造したり、引数の順序を間違えたりといったハルシネーション（もっともらしい嘘）が発生します。エンジニアは生成されたコードの修正に追われ、結果として「自分で書いた方が早い」という結論に至ってしまいます。
RAG（検索拡張生成）とファインチューニングの使い分け基準
「それなら、RAGを使って社内ドキュメントを参照させればいいのでは？」という意見もあります。確かにRAGは、GraphRAGやマルチモーダル対応など進化を続けており、知識検索としては非常に強力です。しかし、IDEでのコーディング支援においては、いくつかの限界が存在します。
- 推論速度とレイテンシ: IDEのコード補完に求められるのは「数ミリ秒〜数百ミリ秒」のレスポンスです。毎回大量のドキュメントを検索・参照して生成するRAGのプロセスは、リアルタイムな入力支援には重すぎる場合があります。
- 「書き方」の習得: RAGは「知識（何を書くか）」を参照するのは得意ですが、その言語特有の「イディオム」や「コーディングスタイル（どう書くか）」を模倣するのは苦手です。
- コンテキストの複雑性: 最新のモデルはコンテキストウィンドウが拡大していますが、依存関係が複雑な大規模コードベース全体を毎回プロンプトに含めることは、コストと精度のバランスにおいて依然として課題があります。
ファインチューニング（特化型モデル構築）は、モデルのパラメータそのものを更新し、社内言語の文法やライブラリの使い方を「身体で覚えさせる」アプローチです。これにより、プロンプトに詳細な指示を書かなくても、文脈に沿った適切なコードを高速に生成できるようになります。
特化型モデル導入による開発速度向上とエラー削減の期待効果
実際に、社内独自のフレームワークや言語仕様に特化した小規模言語モデル（SLM）を構築・導入する組織が増えています。一般的に、こうした取り組みによって以下のような効果が期待できます。
- ボイラープレートコードの記述時間短縮: 定型的な記述を自動化することで、エンジニアは本質的なロジックに集中できます。目安として50〜60%程度の削減効果が報告されるケースもあります。
- API利用時のパラメータ設定ミスの減少: 社内ライブラリの正しい引数や型をモデルが学習しているため、初歩的な実装ミスを未然に防げます。
- オンボーディング期間の短縮: 新人エンジニアが社内独自の作法を学ぶ際、AIによる補完が「生きた手本」となり、学習曲線を緩やかにします。
特化型モデルは、単なる自動化ツールではなく、社内の技術標準を強制し、品質を底上げするための「生きたナレッジベース」として機能するのです。
【データ戦略】Garbage In, Garbage Outを防ぐコードデータセット構築の鉄則
AIモデル構築において、最も重要かつ工数がかかるのがデータセットの作成です。特にコード生成モデルの場合、自然言語とは異なる特有の前処理が必要です。ここを適当に済ませると、どんなに高性能なGPUを使っても実用的なモデルはできません。
リポジトリからの収集：ライセンス汚染と重複コードの排除
まず、学習データとなるソースコードを収集します。社内のGitリポジトリ（GitLab, GitHub Enterprise, Bitbucket等）が主な情報源となりますが、ここで注意すべきは「重複（Duplication）」の問題です。
コードベースには、コピー＆ペーストされたコードや、自動生成されたファイル、フォークされたプロジェクトなどが大量に含まれています。研究（例えば、BigCodeプロジェクトのStarCoder論文など）によると、重複データが含まれたまま学習すると、モデルはコードのパターンを抽象化して学習するのではなく、特定のコード片をそのまま「暗記」してしまう傾向が強まります。これは汎化性能を著しく低下させます。
対策：Near-deduplication（近傍重複排除）
単にファイルハッシュ（MD5等）で完全一致を除くのではなく、MinHash LSH（Locality Sensitive Hashing）などのアルゴリズムを用いて、「中身がほとんど同じファイル」を検出して削除します。Jaccard類似度を用いて、例えば類似度が0.85以上のペアを見つけ、片方を削除するといった処理を行います。Hugging Faceのdatatroveライブラリなどがこの処理に役立ちます。
品質フィルタリング：静的解析ツールを活用した「動くコード」の選別
「社内のコードだから全て高品質」とは限りません。バグを含んだコードや、書きかけのコードを学習させると、モデルはバグまで学習してしまいます。
フィルタリングの基準例
- 行の長さとファイルサイズ: 極端に長い行（例: 1000文字以上）や巨大なファイルは、自動生成されたminified JSやデータファイルである可能性が高いため除外します。
- コメント比率: コメントが全くないコードや、逆にコメントだらけのコードを除外する場合もありますが、コード生成においては「ドキュメントとコードのペア」が重要なので、Docstringがしっかり書かれているコードを優先的に抽出します。
- パース可能性: その言語のパーサー（AST解析器）に通し、構文エラーが出るファイルは即座に捨てます。「コンパイルできないコード」を学習させる価値はありません。
PII（個人情報）とシークレット情報の確実な除去プロセス
企業内モデル構築で最も恐ろしいのが、学習データに含まれる機密情報の漏洩です。APIキー、パスワード、AWSのクレデンシャル、顧客のメールアドレスなどがハードコードされている場合、モデルがそれを生成してしまうリスクがあります。
スクラブ処理（Scrubbing）の実装
- 正規表現によるスキャン: AWSキーやIPアドレス、メールアドレスのパターンマッチングで検出します。
- エントロピー解析: ランダムな文字列（パスワードやトークン）は文字の並びの不規則性（エントロピー）が高い傾向があります。
TruffleHogやGitleaksといったセキュリティツールを前処理パイプラインに組み込み、発見されたシークレットを含むファイルを除外、あるいは<PASSWORD>のようなプレースホルダーに置換します。 - PII検出モデル: MicrosoftのPresidioなどのライブラリを使い、名前や住所などの個人情報を特定してマスキングします。
このプロセスは、セキュリティ監査の観点からも必須であり、ここを自動化・厳格化することがプロジェクト成功の前提条件となります。
【学習手法】計算リソースを最小化しつつ精度を最大化するチューニング戦略
データが整ったら、次は学習です。しかし、ゼロからモデルを学習（フルスクラッチ）するには、数千万円〜数億円規模のGPUリソースが必要です。多くの企業にとっては現実的ではありません。
そこで、既存の高性能なコード生成モデル（CodeLlama, StarCoder2, DeepSeek-Coder等）をベースモデルとして採用し、社内データに適応させるアプローチをとります。
継続的事前学習（Continuous Pre-training）とSFTの違い
ここでのポイントは、いきなり「質問と回答」のペアで学習させるSFT（Supervised Fine-Tuning）を行うのではなく、その前に継続的事前学習（Continuous Pre-training: CPT）を挟むことです。
- 継続的事前学習 (CPT): ラベルのない生のコードデータを大量に読ませ、次のトークンを予測させるタスク。これにより、モデルは新しい言語の文法、クラス構造、命名規則を理解します。社内フレームワークを理解させるには、このフェーズが不可欠です。
- SFT (Instruction Tuning): 「この関数を使って〇〇するコードを書いて」という指示に対して、適切なコードを返す訓練。モデルを「チャットボット」として振る舞わせるために行います。
多くの場合、CPTでドメイン知識を注入し、その後に少量の高品質なInstructionデータでSFTを行う2段階構成が最も高い精度を出せます。
LoRA/QLoRAを活用した効率的なパラメータ更新
全パラメータを更新するフルファインチューニングはVRAM（GPUメモリ）を大量に消費します。そこで、LoRA（Low-Rank Adaptation）や、それを量子化技術と組み合わせたQLoRAを使用します。
LoRAは、モデルの重み行列のごく一部（低ランク行列）のみを追加学習させる手法です。これにより、7Bや13Bといったサイズのモデルでも、A100やH100といった最高級GPUを何枚も並べる必要なく、コンシューマー向けのGPUや小規模なクラウドインスタンスで学習が可能になります。
実践的な設定のヒント
- Target Modules:
q_proj,v_projだけでなく、全てのLinear層（all-linear）を対象にすると精度が向上する傾向があります。 - Rank (r): 一般的なNLPタスクでは8や16で十分ですが、コード生成のような複雑なタスクでは、64や128といった高めのランクを設定した方が、新しい構文規則を捉えやすくなります。
コード構造を理解させるための「FIM（Fill-In-the-Middle）」学習
通常の言語モデルは「左から右へ」文章を生成します。しかし、プログラミングの実務では、既存のコードの途中に新しい行を挿入したり、関数の引数を修正したりする作業が頻発します。
これに対応するために、FIM（Fill-In-the-Middle）という学習目的関数を採用します。これは、コードを「プレフィックス（前）」「サフィックス（後）」「ミドル（中身）」の3つに分割し、「前と後ろを渡すから、真ん中を埋めてね」という形式で学習させる手法です。
CodeLlamaやStarCoderなどのモデルは、すでにこのFIM形式で事前学習されています。ファインチューニング時にも、データをこの形式に加工（Special Tokenの挿入など）して学習させることで、IDE上での「コード補完」能力を維持・向上させることができます。これを行わないと、単純な続き書きしかできないモデルになってしまいます。
【評価指標】BLEUスコアの罠と「実行可能性」を重視した評価体系
モデルができたら評価を行いますが、ここにも大きな落とし穴があります。自然言語処理でよく使われるBLEUやROUGEといった「文字列の一致度」を見る指標は、コード生成においてはほとんど意味をなしません。
例えば、変数の名前を result から output に変えただけで、コードの意味は同じなのにBLEUスコアは大幅に下がってしまいます。逆に、構文エラーがあっても単語が合っていればスコアが高くなることもあります。
静的評価（N-gramベース）の限界と誤解
N-gramベースの指標（BLEUなど）は、あくまで「正解テキストとどれくらい似ているか」を測るものです。しかし、プログラミングにおいて重要なのは「似ているか」ではなく、「動くか」「要件を満たすか」です。
したがって、コード生成モデルの評価においては、これらの静的指標は参考程度にとどめ、動的な実行評価を主軸にする必要があります。
pass@k指標と単体テストによる動的評価の実装
業界標準となっているのがpass@kという指標です。これは、「1つの問題に対してk個のコード候補を生成し、その中に正解（テストケースを全てパスするコード）が少なくとも1つ含まれている確率」を指します。
- pass@1: 1発で正解する確率。チャットボットなど、ユーザーに対話的に答えを返す場合に重要。
- pass@10: 10個生成して、その中に正解がある確率。IDEの補完候補リストのように、ユーザーが選択できる場合に重要。
評価セットの自作
OpenAIが公開している「HumanEval」や「MBPP」はPythonの一般的な問題集です。社内特化モデルを評価するには、これらを参考に「社内版HumanEval」を作成することを強くお勧めします。
- 社内の実際の業務コードから、代表的な関数やメソッドを100個程度抽出する。
- それぞれの関数のDocstring（入力）と、Unit Test（検証コード）を用意する。
- モデルにDocstringを入力し、生成されたコードがUnit Testを通るかを確認する。
このパイプラインを構築することで、「自社の業務コードをどれくらい正確に書けるようになったか」を定量的に測定できます。
開発者による定性評価とフィードバックループの構築
自動評価（定量評価）だけでは測れない部分もあります。「コードの可読性」「社内規約（命名規則など）の遵守」「セキュリティリスク」などです。
これらを評価するために、実際の開発者にモデルを使ってもらい、生成されたコードに対して「Good/Bad」のフィードバックを収集する仕組みを作ります。VS CodeなどのIDEプラグインにフィードバックボタンを設置し、開発者が直感的に評価できるようにするのが効果的です。このデータを集めることで、次の再学習（RLHFなど）に活かすことができます。
アンチパターンから学ぶ：失敗しないためのプロジェクト設計
最後に、多くのプロジェクトで陥りがちな失敗パターン（アンチパターン）を紹介します。これらを避けるだけで、成功確率はぐっと上がります。
データ量不足をモデルサイズでカバーしようとする過ち
「データがあまり集まらなかったので、代わりにパラメータ数の大きいモデル（70Bなど）を使えば賢くなるだろう」という考えは危険です。
コード生成、特に特定の構文を覚えさせるタスクにおいては、モデルのサイズよりも「ドメインデータの質と量」の方が支配的です。スカスカの内容を巨大な脳で学習させても、過学習（Overfitting）を起こしやすくなるだけです。まずは7Bや13B程度の扱いやすいサイズで、データの質を高めることに注力してください。
学習データの「時系列リーク」による過学習
時系列データの扱いにも注意が必要です。例えば、2024年のコードをテストデータにし、2023年のコードを学習データにするのは正しい分割ですが、ランダムにシャッフルして分割すると、未来のコード（のリファクタリング後など）を見て過去のコードを予測することになり、不当に高い評価値が出てしまいます。
コードには進化の歴史があります。学習データとテストデータは、必ず「コミット日時」などで時系列に沿って分割し、未来の情報をカンニングさせないようにしてください。
開発者体験（DX）を無視したツール統合の失敗
どれほど優れたモデルができても、エンジニアが普段使っているIDE（VS Code, IntelliJなど）からシームレスに使えなければ、誰も使ってくれません。「Webブラウザを開いて、専用のチャット画面にコードをコピペして...」というフローでは、開発効率は逆に下がります。
モデル構築と同じくらい、IDE拡張機能の開発や、Continueなどの既存のOSSプラグインとの連携設定にリソースを割いてください。エンジニアにとっての「使いやすさ」こそが、導入成功のラストワンマイルです。
まとめ：自社専用AIエンジニアを育てる旅へ
特定のプログラミング言語やフレームワークに特化したAIモデルの構築は、決して魔法ではありません。それは、泥臭いデータの前処理、適切なベースモデルの選定、そして厳密な評価プロセスの積み重ねによって実現されるエンジニアリングそのものです。AIはあくまでビジネス課題を解決するための手段であり、実用的な導入こそが重要です。
しかし、適切に導入された場合の対価は計り知れません。社内の知見を凝縮したAIが、24時間365日、開発チームの隣でコードを書き、レビューし、バグを防いでくれる未来。それは開発スピードを劇的に向上させるだけでなく、エンジニアを単純作業から解放し、より創造的な設計業務に集中させるための強力な武器となります。
汎用AIの限界を感じているなら、次は「自社専用AI」を育てるステップへ進んでみてはいかがでしょうか。
コメント