企業のコードベースのためのファインチューニング基盤：2026年に自社のコードでモデルを学習させる方法

企業のコードベースのためのファインチューニング基盤：データ、学習、提供のパイプライン

汎用のコーディングモデルは、オープンなインターネットで書かれているようにReactやPythonを書く方法を知っています。しかし、あなたのモノレポのモジュール境界も、社内のRPCフレームワークも、すべてのサービスが使うことになっている認証のラッパーも知りません。3年前の障害のあと、チームがあるパターンを禁止したことも知りません。世の中のコードの書き方と、あなたの会社のコードの書き方との差。それこそが、ファインチューニングしたモデルが埋めるものです。そして2026年、それを実現する基盤を作ることは、多くのエンジニアリングリーダーが思っているよりはるかに手の届くものになっています。

本記事では、特定の企業のコードベースでモデルをファインチューニングするのに必要な基盤を、層ごとに実践的に見ていきます。データパイプライン、ベースモデルの選定、学習の層、評価、サービング、そしてコードの変化に合わせてモデルを最新に保つ再学習のループです。最初に来る判断、つまりそもそもファインチューニングすべきか、それとも検索だけで十分かについても取り上げます。

まず：ファインチューニングか、RAGか、長いコンテキストか

GPUを1台でも用意する前に、自分が解こうとしている問題について正直になりましょう。ここでは3つのツールが競合しますが、互いに置き換えられるものではありません。

検索(RAG)は事実を教える。 「この関数は何をする?決済クライアントはどこで定義されている?」。現在のコードとドキュメントに基づいて答えることが目的なら、リポジトリのベクトルインデックスに対するRAGのほうが安く、早く出荷でき、コードが変わった瞬間に更新されます。ここから始めてください。
ファインチューニングは振る舞いとスタイルを教える。 「私たちが書くようにコードを書いて」。命名規則、エラー処理の定石、好んで使うライブラリ、サービスの社内標準の構成。プロンプトに詰め込むには散らばりすぎていて、汎用モデルに任せるには一貫しすぎているパターンです。ここはファインチューニングにしかできない領域です。
長いコンテキストは単発の作業に向く。 1つの大きなタスクなら、関係するファイルをフロンティアモデルのコンテキストウィンドウに貼り付ければ足りることがよくあります。しかし、すべての開発者が毎日、予測可能なコストで使うようにはスケールしません。だからこそ、チームはやがてファインチューニングへと進むのです。

成熟した答えは、たいていファインチューニングとRAGの組み合わせです。自社のスタイルと規約を身につけたモデルが、推論時に現在のコードを検索するので、事実が古くなることがありません。本記事の残りは、この組み合わせに向けて組み立てていきます。

第1層：データパイプライン(作業の80%)

正直な実務家なら誰もが同じことを言います。モデルは簡単で、データこそがプロジェクトだ、と。ファインチューニングの出来は、学習する例の質で決まります。そして企業のコードベースは雑多な情報源です。パイプラインは4つの段階からなります。

集める。 チームが実際にどう作っているかが表れている情報源から集めます。ソースリポジトリ、マージされたプルリクエストとそのレビューコメント、社内の設計文書とADR、解決済みのチケット、そしてランブックです。PRとレビューのスレッドは宝の山です。コードだけでなく、その背後にある考え方と修正の過程まで記録されています。
整理して絞り込む。 シークレットと認証情報を取り除きます(これは譲れません。何かが学習用サーバーに触れる前に行ってください)。生成されたコード、同梱された依存関係、ロックファイルを除き、使われていない古いモジュールを外し、ほぼ同一のファイルを重複排除して、よくある定型コードがシグナルを支配しないようにします。
例の形に整える。 タスクの形式を決めます。補完モデルなら、実際のファイルから取ったfill-in-the-middle(FIM)の例を使います。指示に従うアシスタントなら、指示と応答のペアを作ります。「このサービスにページネーション付きのエンドポイントを追加して」と、それを実際に実装した差分の組み合わせです。PRのタイトルと説明を指示に、マージされた差分を応答にすれば、強力でほぼ無料の指示データになります。
分割して保留する。 学習の前にテスト用のデータを取り分けます。理想は最新のコミットで、そうすれば評価が実際の利用、つまりモデルが見たことのないコードを予測する状況を再現できます。テスト用のファイルが学習に紛れ込むことは、決してあってはいけません。

ライセンスとプライバシーの関門

学習データは、最も機密性の高い知的財産です。基盤全体を自社が管理するインフラ、つまりプライベートなVPC、予約したGPU、あるいはオンプレミスで動かすべき最大の理由はここにあります。すべての情報源について学習させる権利があることを確認し(モノレポの中にあるサードパーティのコードやコピーレフトのコードに注意してください)、個人情報とシークレットを取り除き、各学習実行に何が入ったかを正確に記録します。基盤を自社で持てば、これはベンダーの約束ではなく、アーキテクチャそのものの性質になります。

第2層：ベースモデルを選ぶ

モデルをゼロから学習させるのではありません。すでにプログラミングを理解している、強力なオープンウェイトのベースを適応させるのです。現世代のオープンなコードモデル(Qwen-Coder、Code Llama、DeepSeek-Coder、StarCoderの各ファミリー、さらにPhiやGemmaのような小型の汎用モデル)から選びます。選択を左右する要因は3つです。

仕事に対するサイズ。 インライン補完や範囲の限られたアシスタントのタスクなら、自社のコードでファインチューニングした3B〜8Bのモデルは高速で、サービングも安く、自社固有のパターンではずっと大きな汎用モデルに勝つことがよくあります。14B〜34Bは、本当に複数ファイルにまたがる推論のために取っておきましょう。目標は大きさではなく、適合です。
ライセンス。 重みが商用利用と社内利用を認めているかを確認します。これは細部ではなく、法務上のチェック項目です。ベースの上に構築する前に片付けてください。
コンテキスト長とFIMへの対応。 コードのタスクは複数のファイルにまたがります。補完が用途なら、長いコンテキストを持ち、fill-in-the-middleでネイティブに学習されたベースを優先してください。

第3層：学習の層(LoRA / QLoRA)

フルファインチューニングが必要になることは、まずありません。パラメーター効率の高い手法、つまりLoRAとその量子化版であるQLoRAは、凍結したベースの上で小さなアダプターの重みだけを学習させます。そのため、7Bのモデルを最新のGPU1台で数時間のうちに、ちょっとしたディナー程度の費用で適応させられます。ツールも成熟しています。Hugging Face PEFT、Axolotl、Unslothといったライブラリが、ループ全体を包んでくれます。

この層で本当に重要なこと:

アダプターでモジュール性を保つ。 LoRAアダプターはベースの重みとは別の小さなファイルなので、チームごと、言語ごと、サービスごとにアダプターを学習させ、サービング時に差し替えられます。再学習は安く、失敗したときの影響範囲も小さくなります。
破滅的忘却を防ぐ。 範囲の狭いコードベースで学習させすぎると、汎用的なプログラミングの能力が落ちることがあります。汎用のコードデータを一部混ぜ、学習率を控えめにし、決まったエポック数ではなく評価曲線を見て早めに止めてください。
すべての実行を記録する。 データセット、ベースモデル、ハイパーパラメーター、そしてできあがったアダプターを、まとめてバージョン管理します。モデルの性能が後退したとき、何が変わったのかを正確に知る必要があります。

計算資源については、買う前に借りましょう。予約したクラウドのGPU(CoreWeave、Lambda、あるいはハイパースケーラーの予約枠のA100やH100)が正しい入口です。自社でハードウェアを持つのは、学習と推論の量がそれを正当化できるほど安定してからにしてください。

第4層：評価(チームが飛ばして後悔する層)

デモで「良くなった気がする」ファインチューニングは、成果ではありません。本番で運用するモデルの取り組みと研究の実験を分けるのは、再学習のたびに実行される本物の評価の仕組みです。コードについては、珍しく良い選択肢があります。

実行に基づくテスト。 コードは確かめられます。保留したタスクに対して補完を生成し、実際のユニットテストに対して実行し、いくつ通るかを測ります。自社で解決したイシューとそのテストから、SWE-bench形式の社内セットを作りましょう。これが得られる中で最も正直なシグナルです。
スタイルと規約のチェック。 生成されたコードを、リンター、フォーマッター、型チェッカーに通します。自社の規約を身につけたモデルは、CIの関門をすんなり通るコードを出します。
ベースラインとの直接比較。 ファインチューニングしたモデルは、必ず素のベースモデルと強力なフロンティアのAPIの両方と、同じタスクで比べてください。自社の指標で両方に勝てないなら、出荷する前に価値ある学びを得たことになります。

第5層：サービングとアプリケーションの層

オブジェクトストレージに置かれたままの学習済みアダプターは、誰の役にも立ちません。サービングの層は、モデルが開発者と出会う場所です。

推論サーバー。 vLLM、TGI、Ollamaで提供し、高スループットで低レイテンシーの推論を実現します。補完ではこれが決定的で、数百ミリ秒を超えると壊れているように感じられます。量子化(GPTQ/AWQ)して、各GPUでより多くの同時リクエストをさばけるようにします。
推論時の検索。 ファインチューニングしたモデルを、現在のリポジトリに対するRAGと組み合わせます。そうすれば、スタイルは身についたまま、しかも最新の事実がコンテキストに入ります。これがファインチューニングとRAGを組み合わせる見返りです。
届ける場所。 開発者がすでに作業している場所で使えるようにします。補完のためのIDE拡張、質問のためのチャットのエンドポイント、レビューのためのCIボット、あるいはエージェント型ワークフローの中のツールとしてです。
ルーティング。 すべてのリクエストを自社のモデルで処理する必要はありません。量が多く、ドメイン内のリクエストはファインチューニングしたモデルに送り、まれで本当に難しく、答えの定まらないものはフロンティアのAPIに回します。各リクエストを、それをうまく処理できる最も安い層に置いてください。

第6層：再学習のループ

コードベースは動く標的です。第1四半期に学習させたモデルは、第3四半期には少しずつずれています。規約も、依存関係も、アーキテクチャも先に進んでいるからです。基盤の最後のピースは、マイルストーンではなくループです。月ごとか四半期ごとに、新しくマージされたPRをパイプラインに取り込み、アダプターを再学習させ、評価の仕組みを実行し、自社の指標で現行のアダプターに勝ったときだけ新しいアダプターに切り替えます。サイクルを回すたびに、自社のモデルと、競合が汎用モデルにプロンプトを与えて得られるものとの差は広がっていきます。その差こそが、積み上げてきたエンジニアリングの知識だからです。

基盤の全体像

データ： リポジトリ、PR、文書を集める → 整理、重複排除、シークレットの除去 → FIMまたは指示のペアの形に整える → 最近のコミットを保留する。
ベースモデル： タスクに合ったサイズのオープンウェイトのコードモデルで、ライセンスが明確で、長いコンテキストを持つもの。
学習： 予約したGPU上で、PEFT、Axolotl、UnslothによるLoRA/QLoRA。実行はバージョン管理し、忘却を防ぐ対策を入れる。
評価： 保留したセットでの、実行テスト、リントと型のチェック、ベースラインとの直接比較。
サービング： vLLM/TGIとRAG。IDE、CI、エージェントに届け、難しいごく一部はフロンティアのAPIにルーティングする。
再学習： コードの変化に合わせてアダプターを最新に保つ、定期的なループ。

結論

企業のコードベースでモデルをファインチューニングすることは、もはやAIの研究所だけに許された研究ではありません。使い込まれた基盤を持つエンジニアリングのプロジェクトです。規律あるデータパイプライン、オープンウェイトのベース、借りたGPUでの数時間のLoRA学習、本物の評価の仕組み、高速なサービングの層、そして再学習のループ。データさえ正しく整えれば、残りは配管工事です。最後に手にするのは、どの競合も買うことも、プロンプトで再現することもできない知能です。あなたの組織が書くようにコードを書くモデルです。

どこから始めるべきか、つまりファインチューニングするか検索に頼るか、最初にどのタスクを適応させるか、自社のインフラ上でパイプラインを安全に立ち上げるにはどうするかを検討しているなら、無料のディスカバリーコールを予約してください。一緒に基盤の全体像を描きます。