GLMなどのオープンモデルを自社コードで学習させる：実際に何が得られるのか（2026年）
By Surya Pratap
2026年7月29日
11 min read
AI & Technology
2026年7月29日
11 min read
数週間おきに、創業者から同じような質問を受けます。GLMのようなオープンモデルを自社のコードベースで学習させれば、うちのチームと同じ書き方でコードを書くエージェントが手に入るのではないか、と。いい直感ですし、2026年になってようやく現実的な発想にもなりました。オープンウェイトのモデル群はその上にプロダクトを築けるほど強くなり、かつては数万ドルかかったファインチューニングが、今ではランチ代より安く済みます。ただし、この要望には落とし穴があります。「自社のコードで学習させたい」は、実は1着のコートに3つの別々の要望が入っているようなもので、そのうち学習ジョブなのは1つだけなのです。これを切り分ける前にファインチューニングを始めたチームは、1か月かけて、社内の書き方を真似るのに請求のリトライをどのサービスが担当しているかは答えられないモデルを作ることになります。
この記事は、それを正しい順序で進めるための実践ガイドです。オープンウェイトの現状、3つの要望の切り分け方、LoRAアダプターが測定可能な形で何を直すのか、全体でいくらかかるのか、そして他人のリーダーボードではなく自社のリポジトリでベースモデルを選ぶ方法を扱います。
まず、そもそもなぜやる価値があるのかから始めましょう。Z.aiが2026年6月に公開したGLM-5.2は、7,440億パラメーターのmixture-of-expertsモデルで、100万トークンのコンテキストウィンドウを持ち、完全なウェイトがHugging Faceで公開され、ライセンスはMITです。コーディング、推論、ツールを使うエージェント的な作業のために明確に設計されており、主要なエージェント系ベンチマークでAnthropicのOpus 4.8に約1ポイント差まで迫りながら、コストはおよそ5分の1です。ベンチマークより重要なのはMITという点です。誰の許可も得ずに学習させ、出荷し、ホストできます。
選択肢はこれだけではなく、適切なベースはワークロードの形によって変わります。Qwen3-Coder-480BはApache-2.0で、SWE-bench Verifiedでは約69.6%。より小さなバリアントはセルフホストがずっと簡単です。DeepSeek-V3.2はMITライセンスで、約70%に達します。マルチモーダルやマルチエージェントの作業ならKimi K2.6、低コストで高スループットのジョブならMiniMax M3です。実際には、長いコンテキストと長期にわたるエージェント作業ではGLM-5.2が最も強力なデフォルトで、自分で管理するハードウェアで動かしたいときにはQwen3-Coderに落ち着くチームが大半です。
数字については注意が1つあります。GLM-5.2は公開時点で独立したベンチマーク結果がなく、開発元が長期的なコーディングで旧バージョンより優れていると位置づけていただけでした。このセクションの数字はすべて、決定ではなくふるい分けとして扱ってください。ここから、本当に重要な話に入ります。
ベンチマークはふるい、決めるのはリポジトリ
最終判断は、自社のタスクから作った非公開の評価セットで下してください。実際にデプロイする量子化済みのチェックポイントそのものを使い、本番で使うのと同じエージェントフレームワークの中で実行します。フル精度でリーダーボードの首位にいるモデルが、4ビットで自社のハーネスに入れると、まったく違う振る舞いをすることがあります。
自社のコードで学習させたモデルが欲しいと言うとき、たいていは3つの異なるものを同時に求めています。それぞれを別々に名指しすることが、作業の大半を占めます。
1つ目の要望は事実です。 コードベースに何があり、どこにあり、どのサービスがどのテーブルを持ち、あのヘルパー関数が実際に何を返すのか。これは知識であり、知識は変わります。リポジトリは毎日変わりますが、ウェイトは変わりません。事実をチェックポイントに焼き込めば、誰かがマージするたびに再学習が必要になります。この要望は検索の担当であり、ずっと検索の担当のままです。2026年のコンセンサスははっきりしています。答えが変化するデータに依存するなら検索を使い、ファインチューニングは変わるべきでない振る舞いにだけ使う、ということです。
2つ目の要望は慣習です。 チームの仕事の進め方、つまりレビューのチェックリスト、マイグレーションの手順、エラーのラップの仕方、リポジトリクラス以外からデータベースに触れてはいけないというルールなどです。学習の問題に見えますが、ほとんどの場合そうではありません。厳選したスキルファイル、つまり何をいつどうやるかを書いた平易な指示があれば、同じ振る舞いがすぐに得られ、どのモデルプロバイダーでも動き、チェックポイントに触れずに編集、バージョン管理、テスト、ロールバックができます。ファインチューニングは振る舞いを恒久的に変え、元に戻すのは遅くて面倒です。スキルファイルなら、プルリクエスト1つで済みます。
ここには重要な但し書きがあり、それは今年の研究の中でも特に役立つ知見です。スキルがあるだけでは何も保証されません。自動生成されたスキルは平均すると効果がなく、人が書いて厳選したスキルはスキルなしのベースラインを一貫して上回り、質の低いスキルはエージェントの性能を測定可能なほど悪化させます。ですから、モデルにリポジトリを読ませて自分で慣習を書かせるのはやめましょう。いちばん優秀なエンジニアに、レビューで実際に問題になることをもとに、本物を10個、手で書いてもらってください。
3つ目の要望は形式とツールスキーマです。 そして、これこそ本物の学習ジョブです。モデルに自社の内部API呼び出しを自社のパラメーター名で出力させ、出力構造を正確に守らせ、自社のツール群から正しいツールを確実に選ばせる。これはまさにファインチューニングが得意とすることです。これは事実ではなく形式であり、ファイルの場所とは違って安定しています。
3つ目の要望について公開されている最も分かりやすい例は、自社固有のツールスキーマとパラメーターの命名をモデルに理解させる必要があったチームです。彼らのエージェントのツール呼び出し成功率は40%でした。エージェントを出荷したことがある人なら、何も動かず誰もがモデルのせいにする数字だと分かるでしょう。QLoRAでファインチューニングした後、成功率は90%になりました。費用は1台のRTX 4090で総額約1,500ドル、測定したすべてのベンチマークでフルファインチューニングとの差は1%以内でした。
何が動いたのかに注目してください。自社システムについてのモデルの知識でも、一般的なコーディング能力でもなく、自社インターフェースへの準拠です。自社のコードで学習させることの正直な約束は、ツールの扱いでつまずかないエージェント、ということです。いまエージェントが失敗する理由が、パラメーター名をでっち上げる、壊れた構造を返す、間違ったツールを選ぶ、といったものなら、アダプターで直ります。アーキテクチャを知らないことが原因なら、アダプターでは直らず、どれだけ学習させても直りません。
計算資源そのものは、もはやほぼ無料です。7〜8BモデルのLoRAやQLoRAによるファインチューニングはGPU時間で3〜10ドル。レンタルのA100で2〜4時間、手元にある4090なら3ドル未満です。70BのQLoRAなら15〜30ドル前後です。マネージドサービスは100万トークンあたり約0.48〜0.50ドルなので、8Bモデルでの典型的な5,000万トークンのジョブは、ホスト型で約25ドル、自前なら3〜10ドルです。大多数のケースではLoRAが正しい選択で、アダプター同士の組み合わせも驚くほどうまくいきます。コードスタイルのアダプターとセキュリティ推論のアダプターは、互いにほとんど干渉しません。
GPUの請求額はコストではない
学習にかかるのは10ドルです。本当の予算は、チームが実際にどう働いているかを表す例を厳選することと、アダプターが役に立ったかどうかを教えてくれる評価セットを作ることに使われます。この2つを飛ばしたチームが手にするのは、測定可能なほど良くなったモデルではなく、自信満々に違うだけのモデルで、しかもどちらなのかを見分ける手段がありません。
2026年に実務家たちが行き着いた順序は、プロンプト、検索、ファインチューニング、蒸留です。そして最もリターンが大きいファインチューニングは、強力なベースモデルの上に薄いLoRAアダプターを載せ、検索を置き換えるのではなく検索と組み合わせる形です。どのステップも次のステップより安く、元に戻しやすいので、順番に進めれば早い段階で止められると分かることがよくあります。
この順序は、ここで最も高くつく失敗、つまり早すぎる段階で特定のチェックポイントに縛られることからも守ってくれます。検索ならベースモデルを自由に入れ替えられますが、ファインチューニングではそうはいきません。GLM-5.1から5.2まで数か月というこの分野の速さを考えれば、ビジネスを表現しているシステムの部分は、より良いベースモデルへ午後のうちに持っていける部分であってほしいはずです。
この話題がクローズドなAPIではなくGLMやQwenを中心に語られるのには理由があります。自社のコードで学習させるということは、自社のコードが学習データになるということです。MITやApache-2.0のウェイトなら、その工程全体を自分で管理するインフラの中で実行できます。それは、自社のセキュリティチームとの話し合いで済むか、顧客のセキュリティチームとの話し合いになるかの違いです。データ所在地に関する約束やエンタープライズのデータ処理条件のもとで事業をしているなら、オープンなベースをセルフホストすることが、このプロジェクトが審査を通る唯一の形であることも少なくありません。
2つ目の理由は可搬性です。オープンウェイトとモデル非依存のエージェントハーネスを組み合わせれば、今四半期に学習させたアダプターを、来四半期に首位に立つモデルへ移せます。1社のベンダーのホスト型ファインチューニング製品の上にワークフローを築き、価格が据え置かれることを祈るのとは、まったく違う立ち位置です。
これが時間をかける価値のあることかを知りたいなら、学習から始めてはいけません。3つの要望のうち、どれが実際にコストを生んでいるのかを突き止めるところから始めてください。
この順序で進めれば、2つのうちどちらかが起きます。痛みの大半が事実と慣習だったと分かれば、検索とスキルファイルで1週間のうちに無料で解決でき、学習プロジェクトそのものを丸ごと省けます。あるいは、どんなプロンプトでも直らないインターフェースの失敗という硬い核が見つかれば、10ドルを使って40%のツール呼び出し成功率を出荷できる水準に変えられます。どちらも良い結果です。悪い結果は、いちばん面白い部分だからという理由でファインチューニングから始め、社内の書き方をうまく覚えすぎて、その書き方のまま説得力たっぷりに間違えるモデルを手にすることです。
オープンウェイトの世界は今年、本当の意味で一線を越えました。創業者が初めて、MITライセンスのフロンティア級コーディングモデルを手に入れ、コーヒー1杯分の値段で自社のインターフェースに適応させ、すべてを自分で管理するハードウェアで動かせるようになったのです。これは小さなチームが所有できるものの範囲を変える、本物の変化です。ただ、てこになるのは学習の実行そのものではなく、3つの要望のどれに答えているのかを知っていることだ、という点は覚えておく価値があります。
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
