はじめに：その請求書を見たとき、我々は「自社モデル」への転換を決意した
生成AIを自社サービスに組み込んだ多くのプロジェクトが、ある日突然、目を疑うようなAPI利用料の予測に直面します。OpenAI APIを中心とした機能の評判が上々でも、ユーザー数の増加に伴い、APIコストが指数関数的に跳ね上がるケースは珍しくありません。損益分岐点を超え、サービスを提供すればするほど利益を圧迫する構造に陥るという課題は、業界全体で頻繁に報告されています。
特に昨今では、GPT-4o等のレガシーモデルが廃止され、より高度な推論能力を持つGPT-5.2（InstantおよびThinking）が新たな標準モデルへ移行する動きが見られます。このようなモデルの世代交代は、長い文脈理解やツール実行能力の向上をもたらす一方で、APIコストの構造変化や利用プランの再評価を開発チームに突きつけます。旧モデルに依存していたシステムは、最新モデルへの移行計画とそれに伴うコストシミュレーションのやり直しが急務となります。
スタートアップでも、大手企業でも、この「APIコストの壁」は必ず立ちはだかります。そして多くの技術リーダーや経営層が次に検討するのが、オープンモデルの自社運用です。現在では、128kの長文脈に対応するLlama 3.3や、MoEアーキテクチャを採用して効率的な推論を実現したLlama 4、さらにはMistral Small 3.2など、強力なオープンモデルが次々と登場し、有力な移行先としての選択肢が広がっています。
しかし、ここで大きな問題に直面します。世界最高峰のオープンモデルの多くは、英語能力は卓越していても、日本語能力は「そこそこ」か、あるいはビジネスユースには耐えないレベルであることが多いのです。Llama Swallowなどの日本語強化モデルも登場していますが、自社の専門領域に特化した高い精度を求める場合、依然として課題が残ります。
「英語モデルをベースに、自社のドメイン知識と日本語を教え込めばいいのではないか？」
この仮説から導き出されるのが「継続事前学習（Continual Pre-training）」というアプローチです。しかし、それは単にデータを流し込めば賢くなるという単純なものではなく、モデルが元々持っていた知性を破壊してしまう「破滅的忘却（Catastrophic Forgetting）」との過酷な戦いでもあります。
本記事では、なぜRAG（検索拡張生成）やSFT（指示チューニング）だけではなく継続事前学習が有力な選択肢となるのか、そして最大の敵である忘却をどう乗り越え、実用的な日本語モデルを構築するのか、その実践的なアプローチを解説します。長年の開発現場で培った知見をベースに、コストと納期、そして精度の狭間で格闘する技術リーダーや経営者が直面する課題を解決するための、実践的かつ先見的なガイドとして紐解いていきましょう。
なぜAPI利用ではなく、英語モデルの「日本語化」を選んだのか
意思決定の背景には、コスト、セキュリティ、そしてドメイン適応という3つの避けられない現実があります。経営者視点とエンジニア視点の双方から、この選択の必然性を探ります。
月額コストの試算と損益分岐点
冒頭でも触れた通り、外部APIの従量課金モデルは、スケーラビリティの足かせになり得ます。特にコンテキスト長が長いB2B SaaSのようなユースケースでは、数千トークンのプロンプトと生成が頻繁に発生するため、コストが指数関数的に増加するリスクがあります。
一般的な試算を行うと、月間のトークン処理量が一定の閾値（例：10億トークン）を超えた時点で、自社でGPUインスタンスを確保し、オープンモデルをホスティングする方が安価になるケースは珍しくありません。初期投資や運用人件費を含めても、適切な設計を行えば短期間で投資回収できる計算になります。しかし、これはあくまで「モデルが実用レベルの性能を発揮できれば」という前提の話です。
機密保持とレイテンシの要件
金融や医療、あるいは企業の極秘R&Dデータを扱うプロジェクトにとって、外部APIへのデータ送信は依然として高いハードルです。「データは学習に使われない」という規約があったとしても、コンプライアンス部門の承認が下りないケースは多々あります。
自社管理のVPC（仮想プライベートクラウド）内、あるいはオンプレミスで完結するLLM環境は、それ自体が強力な競争優位性となります。また、ネットワークレイテンシを最小化し、推論速度をコントロールできる点も、UX（ユーザー体験）に直結する重要な要素です。
既存の日本語モデルでは満たせなかったニッチな専門性
開発プロジェクトにおいて、既存の日本語特化モデルだけでは要件を満たせないことがあります。一般的な日本語能力は高くても、高度なプログラミング能力や特定の業界ドメイン知識においては、ベースとなる英語モデル（Llamaシリーズの最新モデルなど）の推論能力に及ばないケースがあるためです。
特にLlamaのような最新の英語モデルは、パラメータ数に対する性能効率が飛躍的に向上しており、論理的思考力において圧倒的な強みを持っています。「英語モデルが持つ高度な論理的思考力を維持したまま、日本語で流暢にやり取りさせたい」。この課題を解決するためには、既存モデルの単純な流用ではなく、英語の強豪モデルをベースにした独自の日本語化アプローチ、すなわち継続事前学習が有効な選択肢となるのです。
RAGやファインチューニング(SFT)では不十分だった理由
プロジェクトの初期段階で必ず議論になるのが、「RAG（検索拡張生成）で知識を補えばいいのでは？」「SFT（Supervised Fine-tuning）で日本語を教えればいいのでは？」という問いです。なぜ、あえてコストとリスクの大きい継続事前学習（Continual Pre-training）を選定するのか。その技術的な必然性を解説します。皆さんはどう思われますか？少し考えてみてください。
知識の「参照」と「理解」の違い
RAGは、試験中に教科書（外部知識）を参照することを許可するようなアプローチです。近年では、単純なキーワード検索を超え、知識グラフを用いて複雑な関係性をたどる「GraphRAG」や、画像や図表も統合して検索する「マルチモーダルRAG」といった高度な手法も登場しています。
しかし、どれほど高度な教科書や検索システムを与えられても、回答する本人（モデル）の「基礎的な読解力」や「日本語での論理思考力」が低ければ、正解を導くことはできません。
英語主体のモデルに日本語のドキュメントをRAGで与えた場合、以下のような問題が頻発します。
- 文脈の読み違え: 日本語特有の「行間を読む」処理ができず、検索結果を誤って解釈する。
- 出力の不安定さ: 知識は合っていても、生成される日本語が不自然であったり、英語の文法構造に引きずられたりする。
つまり、RAGは「知識の不足」は補えますが、「言語能力の不足」は補えません。モデル自体の「日本語の基礎体力」を底上げするには、学習フェーズでの介入が必要です。
SFTと事前学習の役割の違い
SFTは、モデルの振る舞いや口調を整えるプロセスです。「ユーザーの指示に従う」「丁寧語で話す」「JSON形式で出力する」といった出力形式の調整には極めて有効です。
しかし、SFTはあくまで「表面的な矯正」に過ぎません。新しい言語の語彙、文法構造、そしてその言語特有の論理展開（商習慣や文化的背景を含む）をゼロから教え込むには、SFTのデータ量では圧倒的に不足します。モデルの深層にある知識表現や推論能力自体を書き換えるには、大量のテキストデータを読み込ませる事前学習（Pre-training）のフェーズが不可欠です。
トークン効率と推論速度の課題：これが決定打
技術的に最もクリティカルな理由は「トークナイザー」と「推論コスト」の関係です。
Llamaシリーズをはじめとする英語圏発の最新モデルは、非常に高性能ですが、そのトークナイザーは日本語を効率的に扱えるようには設計されていません。例えば、「東京都」という単語を処理する場合を考えてみましょう。
- 日本語特化モデル: 「東京都」＝ 1トークン
- 英語主体モデル: 「東」「京」「都」＝ 3トークン（あるいはバイト列としてさらに多く）
このように、英語主体のモデルをそのまま日本語で使用すると、同じ意味を伝えるために数倍のトークン数を消費します。これは実運用において2つの致命的なデメリットをもたらします。
- 推論速度の低下とコスト増: 生成すべきトークン数が増えるため、レスポンスが遅くなり、API利用料やGPU稼働コストが跳ね上がります。
- コンテキストウィンドウの浪費: 入力できる情報量が実質的に減少し、RAGで参照させたいドキュメント量が制限されます。
継続事前学習のプロセスで、日本語の語彙を追加（Vocabulary Expansion）し、トークナイザーを最適化することで、この非効率性を根本から解決できます。これはSFTやRAGでは決して解決できない、モデル構造レベルの最適化です。
最大の壁「破滅的忘却」との戦いとデータ戦略
プロジェクト開始当初、多くの開発現場では「高品質な日本語データを大量に集めて、Llamaに読ませればいい」と楽観視しがちです。しかし、最初の実験モデルが出来上がったとき、予期せぬ結果に直面することが少なくありません。
日本語を覚えると英語と論理的思考力が低下する現象
学習後のモデルに英語で簡単な論理パズルを出題したとします。「リンゴが3つあり、2つ食べた。残りは？」
このとき、モデルの回答が支離滅裂になることがあります。日本語は流暢になっても、ベースモデルが持っていた高度な推論能力、英語の理解力、さらにはPythonコードを書く能力までもが、著しく劣化してしまうのです。
これが「破滅的忘却（Catastrophic Forgetting）」です。ニューラルネットワークの容量は有限であり、新しい知識（日本語）を強引に詰め込むことで、既存の重要な結合重みが上書きされてしまいます。結果として「日本語が話せるが論理的思考ができないモデル」が生まれてしまうのです。
日本語データと英語データの「黄金比率」探索
この問題を解決するために導入されるのが「Replay Buffer（リプレイバッファ）」という概念です。日本語データだけで学習させるのではなく、元々の学習に使われていたような高品質な英語データやコードデータを一定割合で混ぜて学習させます。
実務の現場では、日本語データと英語/コードデータの混合比率を変えながら、小規模なモデル（8Bクラス）で何度も実験を繰り返すアプローチが取られます。プロトタイプ思考で「まず動くものを作る」ことが、ここでも活きてきます。
- 実験1（日本語100%）: 英語能力崩壊。論理的推論能力低下。
- 実験2（日本語50% : 英語50%）: 英語能力は維持されるが、日本語の習得が遅い。
- 実験3（日本語70% : 英語30%）: バランスは良いが、コード生成能力が微減。
多くの検証から導き出される「黄金比率」の目安は、ターゲットとするタスクによって異なりますが、概ね日本語:英語:コード = 5:4:1 程度の割合です。特に、高品質な数学やプログラミングのデータセット（英語）を混ぜることは、言語能力とは独立した「論理的思考力」を維持するために極めて重要です。
高品質な日本語コーパスの確保とクリーニングの苦労
データの「量」より「質」が重要であることは、AI開発の鉄則です。Common CrawlなどのWebデータから日本語を抽出する際、そこにはノイズが溢れています。SEO目的のワードサラダ、アダルトコンテンツ、機械翻訳された不自然な日本語などです。
これらをフィルタリングするために、専用のデータパイプラインを構築することが求められます。
- MinHashによる重複排除: 似通った記事を削除。
- 品質フィルタリング: KenLMなどの言語モデルを用いて、テキストの「日本語らしさ」をスコアリングし、低品質なものをカット。
- 個人情報削除: PII（個人識別情報）のマスキング処理。
「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」。この格言は、継続事前学習において痛いほど真実です。データクリーニングには、学習そのものと同じくらいのリソースと情熱を注ぐ必要があります。
計算リソースと学習スケジュールの現実
「で、結局いくらかかるの？」
経営層が最も気にするポイントです。継続事前学習は、フルスクラッチほどではないにせよ、相当なGPUリソースを消費します。
GPUクラスターの確保とコスト管理
例えば、NVIDIA H100 GPUを搭載したクラスターを利用する場合、70Bクラスのモデルを学習させるには、数週間単位での占有が必要になります。
クラウドベンダーのスポットインスタンス（安価だが中断リスクがある）を活用し、チェックポイントを頻繁に保存することでコストを抑制する工夫が求められます。それでも、一度の学習ジョブで数百万円〜数千万円規模のコストが発生するため、失敗は許されません。
学習率スケジューリングの最適解
学習率（Learning Rate）の設定は、モデルの運命を左右します。高すぎれば学習が発散し、低すぎればいつまで経っても収束しません。
継続事前学習の場合、ゼロからの学習とは異なり、既に学習済みの重みを持っています。そのため、学習率は通常よりも低めに設定し、かつ「ウォームアップ」期間を設けて徐々に上げていく手法が有効です。また、コサイン減衰（Cosine Decay）を用いて、学習の終盤に向けて学習率を下げていくことで、安定した収束を図ります。
チェックポイントごとの評価体制
学習を流しっぱなしにして、最後に蓋を開けて結果を見るのはギャンブルです。数億トークン学習するごとにチェックポイントを保存し、自動評価パイプライン（LLM-as-a-Judge）を走らせる運用が推奨されます。
評価指標には、日本語のJGLUEだけでなく、英語のMMLU（知識・推論能力）、HumanEval（コード生成能力）を含めます。もし英語のスコアが急激に下がっていれば、それは「忘却」のサインです。即座に学習を止め、データ比率やハイパーパラメータを見直すアジャイルな運用を徹底することが重要です。
導入後の成果：日本語処理能力の向上とコスト削減効果
数ヶ月にわたる試行錯誤の末に独自の日本語化モデルを完成させたプロジェクトでは、当初の期待を上回る成果が報告されています。
JGLUE等のベンチマークスコアの変化
定量的な評価として、JGLUE（Japanese General Language Understanding Evaluation）のスコアが、ベースモデルと比較して大幅に向上するケースが見られます。特に、JSQuAD（読解）やJCommonsenseQA（常識推論）において、国内トップクラスの日本語特化モデルと同等以上の性能を記録することもあります。
さらに重要なのは、英語のベンチマーク（MMLUなど）のスコア低下を数ポイント以内に抑えられる点です。これにより、「英語の頭脳を持ちながら、日本語を流暢に操る」という目標を達成できるのです。
トークン削減による推論コストの60%圧縮
ビジネスインパクトとして最も大きいのは、トークナイザーの最適化による効果です。日本語の語彙を追加することで、同じ日本語テキストを表すのに必要なトークン数が平均で約45%減少した事例があります。
これは、推論速度が約1.8倍になることを意味します。さらに、入力プロンプトのトークン数も減るため、同じGPUリソースでより多くのリクエストを捌けるようになります。結果として、API利用時と比較して、運用コストを約60%削減することに成功したケースも存在します。
実務における要約・生成精度の定性評価
現場のエンジニアやプロダクトマネージャーからは、次のようなポジティブなフィードバックが寄せられることが多いです。
「以前はRAGの回答が翻訳調で不自然だったが、今はネイティブが書いたような文章で返ってくる」
「複雑なJSONデータの解析指示を日本語で出しても、正確に意図を汲み取ってくれる」
これらは、単なるSFTでは到達できなかった「文脈理解の深化」による成果と言えます。
これから継続事前学習に挑むチームへのアドバイス
自社での継続事前学習を検討している開発チームへ、実践的なアドバイスをいくつか紹介します。
「小さく始めて評価する」ためのパイプライン構築
いきなり70Bやそれ以上の巨大モデルで学習を始めないでください。まずは7Bや8Bクラスのモデルで、データセットの配合比率やハイパーパラメータの検証を行ってください。小さいモデルで起きた問題（忘却など）は、大きいモデルでも必ず起きます。ReplitやGitHub Copilot等のツールも駆使し、PoC（概念実証）のサイクルを高速に回すことが、成功への近道です。
オープンデータセット活用の落とし穴
「Hugging Faceにあるデータセットを使えばいい」と安易に考えないでください。ライセンスの問題や、品質のバラつきがあります。特に商用利用を前提とする場合、データの権利関係（著作権や利用規約）はクリアにしておく必要があります。また、自社独自のドメインデータ（社内文書やログなど）こそが、競合他社との差別化要因になります。ここへの投資を惜しまないでください。
経営層への説明ロジック
継続事前学習はコストがかかります。GPU代だけでなく、エンジニアの人件費も莫大です。経営層を説得するには、「日本語が上手くなります」では弱すぎます。
「トークン削減によるインフラコストの圧縮」「機密データのセキュリティ担保」「自社特化型AIによる業務効率化の具体的数値」など、ROI（投資対効果）を明確に示す必要があります。そして、リスク（破滅的忘却の可能性）も正直に伝え、それを回避するための技術的戦略があることを説明し、信頼（Assurance）を勝ち取ってください。技術の本質を見抜き、ビジネスへの最短距離を描く視点が不可欠です。
まとめ：自社モデル構築は「総合格闘技」である
継続事前学習は、データエンジニアリング、インフラ構築、モデル評価、そしてビジネス戦略が複雑に絡み合う「総合格闘技」のようなプロジェクトです。決して楽な道のりではありませんが、それを乗り越えた先には、外部ベンダーに依存しない、自社だけの強力な資産が待っています。
継続事前学習のプロジェクトを通じて得られる知見は膨大です。細かいパラメータ設定や、データクリーニングのスクリプト、失敗した実験のログなど、現場には多くのノウハウが蓄積されます。
これからこの険しい山に登ろうとしているなら、まずは小規模なプロトタイプで仮説を即座に形にして検証し、技術の本質を見極めることが重要です。無用な失敗を避け、ビジネスへの最短距離を描くために、本記事で解説したアプローチをぜひ参考にしてみてください。
コメント