「RAG（検索拡張生成）システムを構築したが、専門用語が飛び交う会議の議事録を読み込ませても、文脈を汲み取ってくれない」
「LoRAでチューニングを繰り返しても、根本的な知識不足によるハルシネーション（幻覚）が消えない」
多くのAIプロジェクトにおいて、現場がこの「壁」に直面することがあります。外部データベースを参照させるRAGは強力ですが、例えるなら試験会場に「カンニングペーパー」を持ち込んでいる状態に過ぎません。膨大なマニュアルや複雑な因果関係を持つ技術文書を扱う場合、AI自身にその知識を「記憶」として定着させる必要があります。
そのための解が、継続事前学習（Continual Pre-training: CPT）です。
今回は、高い日本語性能を持つ国産LLM「PLaMo（Preferred Networks製）」をベースに、自社データを学習させるための実践的なロードマップを描きます。単なるコードの解説ではなく、技術の本質を見抜き、ビジネスへの最短距離を描くための「段取り」と「意思決定ポイント」に焦点を当てていきましょう。まずは動くプロトタイプを素早く作り、仮説を検証していくアジャイルな視点が重要です。
なぜ「継続事前学習」なのか：RAG・SFTとの決定的な違いとROI
プロジェクトのGOサインを得るためには、経営層やステークホルダーに対して技術選定の確固たる根拠を示す必要があります。特に、コストと時間がかかるイメージのある「事前学習」をなぜあえて選択するのか、RAGやSFT/RFT（Supervised/Reinforcement Fine-Tuning）との違い、そしてROI（投資対効果）を明確に解説します。
知識の「参照」か「獲得」か：技術選定の分岐点
RAG（検索拡張生成）と継続事前学習（CPT）は、対立する技術ではなく、補完関係にあります。しかし、その役割は決定的に異なります。
RAGは、クエリに関連するドキュメントを外部から検索し、プロンプトに挿入する技術です。GraphRAGやエージェント型RAGといった最新の手法では、情報の関連付けや推論精度が飛躍的に向上していますが、本質的には「外部知識の参照」であることに変わりありません。モデル自体の推論能力や思考回路はそのままだからです。
一方、継続事前学習は、モデルのニューラルネットワーク（重みパラメータ）自体を更新し、対象ドメインの知識を脳内に「獲得」させます。また、SFTや最新のRFT（強化学習を用いたファインチューニング）が「回答のスタイルや手順」といった振る舞いを最適化するものであるのに対し、継続事前学習は「言葉の意味や論理そのもの」を教え込むプロセスと言えます。
技術選定の判断基準として、以下の分岐点が有効です。
- RAG推奨: データが頻繁に更新される（日次ニュース、在庫情報）、または回答の根拠となるドキュメントを明示し、ハルシネーション（嘘）を厳密に抑制したい場合。
- SFT/RFT推奨: 「専門用語を使って回答してほしい」「特定のフォーマットで出力してほしい」といった、出力形式や推論プロセスの調整が主目的の場合。
- CPT推奨: 業界特有の言語ロジック、専門用語の背景にある暗黙知、あるいは独自のプログラミング言語などを「直感的に」理解させたい場合。
継続事前学習を選択する大きなメリットの一つに、推論レイテンシとランニングコストの削減があります。RAGのように毎回数千〜数万トークンの参考資料をプロンプトに含める必要がないため、トークン課金や処理時間を大幅に圧縮でき、長期的な運用コスト（TCO）を低減できる可能性があります。経営者視点で見れば、このランニングコストの圧縮は非常に魅力的なポイントではないでしょうか。
PLaMoを選ぶ理由：日本語性能とライセンスの優位性
2026年現在、Llamaシリーズの最新モデルをはじめとする海外製モデルの性能は著しく向上しており、旧来のモデルはサポート終了（EOL）となるサイクルも早まっています。それでもなお、ベースモデルとしてPLaMo（特にPLaMo-13B）を推奨するのには、明確な戦略的理由があります。
- 商用利用に最適なライセンス: Llamaの最新モデルなどは独自のコミュニティライセンスを採用しており、大規模サービスでの利用には制約がある場合があります。一方、PLaMo-13BはApache License 2.0で公開されており、商用利用、改変、再配布の自由度が極めて高く、企業ユースにおける法的なリスク（コンプライアンス懸念）を最小限に抑えられます。
- Llamaアーキテクチャ互換によるエコシステム活用: PLaMoは、広く普及したLlama 2アーキテクチャを採用しています。Llama 2モデル自体の開発は終了し、主流はLlamaモデル系などの次世代モデルへ移行していますが、このアーキテクチャ構造自体は依然としてエコシステムの基盤です。そのため、
vLLMやllama.cppといった、グローバルで活発に開発されている高速推論・量子化ツールチェーンとの互換性が維持されており、最新の環境でもスムーズに動作します。独自アーキテクチャのモデルを採用する場合と比較して、エンジニアリング工数を大幅に削減できます。 - 日本語処理の効率性: 国産モデルとして日本語データで重点的に学習されているため、トークン効率や文脈理解において、同サイズ帯の海外モデルと比較しても安定した性能を発揮します。
投資対効果の試算：GPUコスト対精度向上のバランス
「事前学習には数億円規模の投資が必要」という懸念は、ゼロからモデルを作るフルスクラッチ学習の場合の話です。既存モデルへの継続事前学習であれば、計算リソースは数十分の1から数百分の1で済みます。
例えば、AWSの最新ハイエンドGPUインスタンスを利用する場合を想定してください。
数十億〜100億トークン程度のドメインデータを学習させるプロジェクトであれば、適切な分散学習設定を行うことで、期間は数日〜1週間程度、クラウド利用料も数百万円のレンジに収まるケースが多く見られます（※正確な価格はAWS公式サイトの最新料金表をご確認ください）。
この初期投資により、RAGシステムの複雑なインデックス管理や検索レイテンシの問題を解消し、業務特化AIの基盤モデルとしての精度を恒久的に底上げできると考えれば、そのROIは十分に正当化できるはずです。まずは小規模なデータセットでプロトタイプを回し、効果を検証してからスケールさせるアプローチが確実です。
フェーズ1：学習データの品質が成否を決める「コーパス構築ワークフロー」
モデルの性能は、アルゴリズムではなく「データの質」で9割決まると言われています。特に継続事前学習では、質の低いデータを入れると、元々賢かったモデルが急速に劣化する「破滅的忘却（Catastrophic Forgetting）」を引き起こします。
ドメインデータの収集と選別基準
まず、社内のあらゆるテキストデータを集めることから始めますが、「量より質」を徹底してください。
- 採用すべきデータ: 技術仕様書、運用マニュアル、高品質な報告書、社内Wiki、教科書的な知識ベース。
- 除外すべきデータ: 雑談の多いチャットログ、自動生成されたログファイル、重複の多いテンプレート文書、スキャン精度の低いOCRデータ。
データの「密度」を意識してください。人間が読んで「学びがある」と感じるテキストこそが、LLMにとっても良質な学習データとなります。
前処理パイプラインの設計：重複排除と個人情報マスキング
収集したデータに対して、以下の処理パイプラインを構築します。
- クリーニング: HTMLタグ、特殊文字、意味のない記号列（
========など）の削除。 - 重複排除（Deduplication）: MinHash LSHなどのアルゴリズムを用いて、類似文書を徹底的に排除します。重複データは学習効率を下げるだけでなく、過学習の原因となり、モデルが特定のフレーズしか喋らなくなるリスクを高めます。
- PII（個人情報）削除: 電話番号、メールアドレス、マイナンバーなどを正規表現や専用ライブラリ（Microsoft Presidioなど）でマスキングします。モデルが個人情報を記憶してしまうと、生成時に漏洩するリスクがあるため、これはコンプライアンス上の必須要件です。
破滅的忘却を防ぐ「Replay Buffer」戦略
ここが最大の失敗ポイントです。ドメインデータだけを学習させると、モデルは日本語の一般的な文法や一般常識を忘れてしまう可能性があります。
これを防ぐために、学習データには必ず一般データ（General Domain Data）を混ぜてください。これを「Replay Buffer」と呼びます。
- 推奨混合比率: 一般的な傾向として、ドメインデータに対して 10%〜20% 程度の一般データを混合することが推奨されます。
- データソース: Wikipedia（日本語）、CC-100、mC4の一部など、品質が保証された公開データセットを使用します。
- 構成例:
- 社内ドキュメント（ドメイン知識）: 80%
- Wikipedia日本語版（一般知識維持）: 10%
- 高品質なWebテキスト（文法維持）: 10%
この「混ぜ物」が、モデルの汎用性を維持するアンカー（錨）の役割を果たします。
フェーズ2：学習環境の設計とリソース最適化
データセットの準備が整ったら、次は学習を回すためのインフラと環境設定です。PLaMo-13Bのようなモデルを効率的かつ安定して学習させるには、単一のGPUではメモリも計算力も不足します。ここでは、エンタープライズ環境で現実的な分散学習の設計について掘り下げます。
分散学習ライブラリの選定とアーキテクチャの互換性
マルチGPU環境での学習には、以下のライブラリ選定がプロジェクトの速度を左右します。
- Megatron-LM: NVIDIAが開発。大規模クラスター向けで最速のパフォーマンスを誇りますが、設定の複雑さは高めです。
- DeepSpeed: Microsoftが開発。
ZeRO (Zero Redundancy Optimizer)技術により、GPUメモリ効率を劇的に向上させます。 - FSDP (Fully Sharded Data Parallel): PyTorch標準機能。最近のバージョンではDeepSpeedに迫る性能を出しており、外部ライブラリへの依存を減らせるため導入のハードルが低いです。
PLaMoはLlama 2アーキテクチャをベースにしています。ここで重要なのは、2026年現在、Llama 2自体は主要なクラウドプラットフォーム（Amazon Bedrock等）でのサポート終了（EOL）が進み、Meta社の主力開発はLlamaモデル系（Llamaモデル/3.2など）へ完全に移行しているという事実です。
しかし、Llama 2が確立したアーキテクチャ（RoPE, SwiGLUなど）は、Llamaモデル系を含む現在のLLM開発における事実上の標準として継承されています。そのため、最新のLlamaモデル向けに最適化された学習スクリプトや、Hugging FaceのTrainer + DeepSpeedプラグインといった豊富なエコシステムを、PLaMoの学習にもそのまま活用できるのが大きな強みです。
カスタマイズ性とパフォーマンスのバランスを重視するなら、多くの現場で実績のあるDeepSpeed ZeRO-2 または ZeRO-3の利用を推奨します。
GPUメモリ見積もりとバッチサイズ設定
必要なGPUメモリ $M$ は、ZeRO-3使用時、概算で以下の式で考えます。
$ M \approx \frac{\text{パラメータ数} \times 16\text{bytes}}{\text{GPU数}} + \text{Activation Memory} $
13Bモデル（130億パラメータ）をFP16（半精度浮動小数点数）でロードするだけで約26GBのメモリを消費します。ここに勾配（Gradients）やオプティマイザの状態（AdamWならパラメータあたり8バイト追加）を含めると、A100 (40GB) 1枚ではOOM（Out Of Memory）になる可能性が高いです。
- 推奨構成: 最低でも A100 (40GB/80GB) x 4枚〜8枚、あるいは最新の H100 を用いた構成。H100などの最新GPUではFP8学習も視野に入りますが、安定性を重視するならBF16（BFloat16）での学習が一般的です。
- バッチサイズ: 学習の安定性に直結します。物理的なGPUメモリに収まるバッチサイズ（Micro Batch Size）が小さくても、Gradient Accumulation（勾配蓄積）を活用して、実質的なバッチサイズ（Global Batch Size）を数百万トークン（例：2M〜4M tokens）程度に保つよう調整してください。
学習率スケジューラの設定（WarmupとDecay）
継続事前学習（Continual Pre-training）では、ゼロからの学習（Scratch）とは異なるパラメータ設定が求められます。既にモデルは「完成」に近い状態にあるため、急激な重みの変更はこれまで獲得した知識を破壊（Catastrophic Forgetting）するリスクがあるからです。
- Max Learning Rate: 事前学習時の 1/10 程度（例: 2e-5 〜 1e-4）に抑えます。
- Warmup: 学習開始直後は学習率を徐々に上げる期間を設けます（全ステップの1〜5%）。これにより、オプティマイザの状態が安定するまでの急激な勾配変動を防ぎます。
- Decay: その後、Cosine Decayなどで徐々に学習率を下げていきます。最新の知見では、学習終盤まで学習率を下げすぎないスケジュールも提案されていますが、まずは標準的な減衰設定から始めるのが無難です。
フェーズ3：学習プロセスの実行とモニタリング指標
いよいよ学習開始です。しかし、コマンドを叩いて放置、というわけにはいきません。LLMの学習は不安定になりがちです。
Lossスパイクへの対応フロー
学習曲線（Loss Curve）を見ていて、突然Loss（損失）が急上昇する「スパイク」が発生することがあります。これはデータの不良（異常値）や学習率が高すぎることが原因として考えられます。
- 対策: チェックポイントから少し前の状態に戻し、学習データから該当バッチ付近のデータ（異常に長いトークン列など）を除外するか、学習率を下げて再開します。自動で直前のチェックポイントに戻るスクリプトを組んでおくと、深夜の学習停止を防げる可能性があります。
途中経過の評価：Perplexityとダウンストリームタスク
Lossが下がっていても、モデルが賢くなっているとは限りません。定期的に（例：500ステップごと）以下の指標を確認します。
- Perplexity (PPL): 次の単語を予測する能力。ドメインデータに対するPPLが下がっていることを確認します。
- ダウンストリームタスク: 知識を問う簡単なQAタスクなどを定期的に解かせ、正答率を監視します。
破滅的忘却の早期検知
ここで重要なのが、一般常識タスクでの評価も同時に行うことです。ドメイン知識のスコアが上がっていても、一般的な日本語能力のスコアが急落していたら、それは「過学習」または「破滅的忘却」のサインです。その場合は、Replay Buffer（一般データの混合比率）を増やす調整が必要と考えられます。
フェーズ4：モデル評価とインストラクションチューニングへの接続
継続事前学習が終わった段階のモデルは、「知識は持っているが、対話は苦手」な状態である可能性があります。あくまで「文章の続きを書く」能力が高まっただけだからです。
ドメイン特化性能の定量的評価（JGLUE + 独自セット）
モデルの完成度を測るために、以下の2軸で評価を行います。
- 汎用性能: JGLUEなどの標準ベンチマークを使い、日本語能力が維持されているか確認。
- ドメイン性能: 社内の専門家が作成した独自のクイズセット（50〜100問程度）で評価。ここでのスコア向上が、今回のプロジェクトの成果指標となります。
対話能力を付与する事後学習（SFT）への移行
ユーザーがチャットボットとして利用するためには、この後にInstruction Tuning（指示チューニング/SFT）を行う必要があります。ここで初めて、「質問に答える」「要約する」といった対話形式のデータを学習させます。
継続事前学習で「知識（教科書）」を与え、SFTで「振る舞い（マナー）」を教えるイメージです。この2段階を経ることで、専門知識を持ちつつ、ユーザーフレンドリーなAIが完成します。
まとめ：自社AI開発は「設計」が9割
継続事前学習は、RAGのような「後付けの知識」ではなく、AIの脳そのものを自社仕様に作り変える強力な手法です。PLaMoという優れたベースモデルと、適切なデータエンジニアリングを組み合わせることで、競合他社には模倣できない「自社だけの頭脳」を手に入れることができる可能性があります。
しかし、その成功はGPUの数ではなく、データの質、混合比率の設計、そして慎重なモニタリングにかかっています。今回紹介したロードマップは標準的なガイドラインですが、実際のプロジェクトでは、扱うデータの特性や企業のセキュリティ要件に応じた、より詳細なチューニングが必要になることがあります。まずは小規模なプロトタイプから始め、仮説検証を繰り返しながら、自社にとって最適なAIエージェントの形を模索していくことをお勧めします。
コメント