はじめに
「LoRAで学習させたはずなのに、社内用語を全く使ってくれない」
「パラメータを何度も調整しているのに、幻覚（ハルシネーション）が減らない」
AIプロジェクトの実務現場では、エンジニアの方々からこのような課題が頻繁に挙げられます。Pythonのコードは完璧、ライブラリのバージョンも最新、GPUリソースも潤沢。それなのに、なぜ成果物は期待を裏切るのでしょうか。
AI導入プロジェクトにおいて、原因の9割は「データセットの設計ミス」にあると考えられます。
開発現場では、どうしてもモデルの構造やハイパーパラメータの調整（Model-Centric AI）に意識が向きがちです。しかし、基盤モデル（Foundation Model）がこれほど高性能化した現在、LoRA（Low-Rank Adaptation）のような効率的なファインチューニング手法において、勝負を決めるのは「何をどう教えるか」というデータ品質（Data-Centric AI）です。
本記事では、コードの修正を一旦止め、学習データの「中身」と「構造」にメスを入れるための実践的なエンジニアリング手法を体系的に解説します。PDFをただテキスト化して流し込むだけの作業から脱却し、狙った通りの挙動を引き出すためのデータセット設計論。これを理解すれば、AIモデルの精度は見違えるほど向上するはずです。
なぜ「とりあえずPDFを学習」では失敗するのか
多くのプロジェクトで最初に行われがちなのが、社内にあるマニュアルや仕様書のPDFをテキスト化し、そのまま学習データとして流し込むというアプローチです。「大量のドキュメントを読ませれば、あとはAIが文脈を理解してくれるだろう」という期待。残念ながら、これはLoRAを用いたファインチューニングにおいては、最も失敗しやすいパターンの一つです。
Model-CentricからData-Centricへの転換
まず認識すべきは、事前学習（Pre-training）とファインチューニング（Fine-tuning）の目的の違いです。ChatGPTやClaudeの最新モデルのような基盤モデルは、すでに膨大なテキストデータによって「言語の構造」や「一般的な知識」を十分に獲得しています。ここに追加学習を行う目的は、言語能力そのものを向上させることではなく、「特定のドメイン知識への適応」や「特定のタスク形式への準拠」です。
Andrew Ng氏らが提唱するData-Centric AI（データ中心のAI開発）の概念は、まさにここに焦点を当てています。モデルアーキテクチャを固定し、データの質を上げることで性能向上を目指すこのアプローチは、特にLoRAのようなパラメータ効率の良い学習手法（PEFT）と相性が抜群です。
単なるテキストの羅列（Raw Text）を流し込むだけでは、モデルは「次に続く単語」を予測することはできるようになっても、「ユーザーの質問に対して、社内規定に基づいて回答する」というタスクを遂行できるようにはなりません。非構造化データを無加工で投入することは、教科書を渡さずに辞書だけを渡して「試験勉強しろ」と言っているようなものです。
ドメイン知識注入における「ノイズ」の正体
「ノイズ」というと、文字化けや不要な記号を思い浮かべるかもしれません。しかし、ドメイン適応における最大のノイズは「文脈の欠如」です。
たとえば、社内規定のPDFに「第5条：経費精算は月末締めとする」と記載されていると仮定します。これをそのまま学習させても、ユーザーが「交通費はいつ申請すればいい？」と聞いた時に、AIが「第5条」と「交通費申請」を結び付けられるとは限りません。AIにとって、そのテキストは単なる文字列の連続であり、質問と回答のペア（因果関係）として認識されていないからです。
また、PDFにはヘッダー、フッター、ページ番号、図表のキャプションなど、本文とは無関係な情報が散在しています。これらが文脈の中に混入すると、モデルは誤ったパターンを学習します。最悪の場合、回答の末尾に必ず「202X年度版」という文字列を生成するような、奇妙な過学習（Overfitting）を引き起こす原因となります。
学習データの質がLoRAのランク選定よりも重要な理由
LoRAの実装において、ランク（r）やアルファ（alpha）の値の設定に時間をかけるケースは多いです。確かにこれらのパラメータは表現力に影響を与えますが、データの質が低い場合、どんなにパラメータを最適化しても性能は頭打ちになります。
質の低いデータ（ノイズが多い、一貫性がない、意図が不明確）で学習を行うと、モデルは「何を学習すべきか」を特定できず、重みの更新が発散したり、既存の知識を破壊（破滅的忘却：Catastrophic Forgetting）したりします。逆に、意図が明確に設計された高品質なデータセットであれば、わずか数百件のサンプルでも、モデルの挙動を劇的に改善できることが、多くの先行研究や実証実験で明らかになっています。
パラメータの調整に数日を費やす前に、データセットを一つひとつ確認し、「人間が見てもこのデータで学習できるか？」を問うことが、プロジェクトを成功に導く最短の解決策となります。
ドメイン特性に応じたデータセット形式の最適解
では、具体的にどのような形式でデータを準備すればよいのでしょうか。注入したい知識の種類によって、最適なフォーマットは異なります。ここでは、代表的な3つの形式と、その使い分け基準について解説します。
Instruction形式 vs Raw Text形式の使い分け
現在、主流となっているのは「Instruction Tuning」と呼ばれる手法で使用されるデータ形式です。一般的に以下の3つの要素で構成されます。
- Instruction（指示）: タスクの定義（例：「以下の社内規定に基づいて質問に答えてください」）
- Input（入力）: ユーザーからの具体的な入力（例：「出張手当の申請期限は？」）
- Output（出力）: 期待される理想的な回答
この形式は、モデルに「指示に従う能力」と「特定の知識に基づいた回答生成」を同時に学習させるのに最適です。社内QAボットや業務アシスタントを作りたい場合は、基本的にこの形式一択と考えて良いでしょう。
一方で、小説の執筆支援や、特定のキャラクター（口調）の模倣、あるいはプログラミングコードの補完などを行わせたい場合は、Raw Text形式（続きを書かせる形式）が有効な場合もあります。しかし、業務利用の文脈では、明確なInput/Outputが存在することがほとんどであるため、Instruction形式への変換を推奨します。
QAペア（Alpaca/ShareGPTフォーマット）の設計思想
Instruction形式のデータセットとして有名なのが、Stanford Alpacaで採用されたJSONフォーマットです。この構造を維持することで、多くの学習ライブラリ（axolotlやllama-factoryなど）でスムーズに学習を開始できます。
重要なのは、このフォーマットの中に「どのような粒度」で情報を詰めるかです。
悪い例（情報の詰め込みすぎ）:
- Instruction: 規定について教えて
- Input: （なし）
- Output: [社内規定全文5000文字]
これではモデルは情報を処理しきれず、どの部分が重要なのかを学習できません。
良い例（情報の粒度を細分化）:
- Instruction: 社内規定に基づき、経費精算のルールを説明してください。
- Input: 領収書を紛失した場合の対応は？
- Output: 領収書を紛失した場合は、直属の上長の承認印を得た「支払証明書」を代用として提出することが可能です。ただし、3万円を超える支出については認められません。
このように、ドキュメントを「質問（トリガー）」と「回答（知識）」のペアに分解することが、LoRA学習成功の鍵です。
思考のプロセス（CoT）をデータに含めるべきケース
単純な事実確認だけでなく、複雑な判断や推論を求められるタスク（例：ログ解析、法務チェック）の場合、単に「正解」だけを提示しても学習効果が薄いことがあります。
こうしたケースでは、CoT（Chain of Thought：思考の連鎖）をデータセットに組み込むことが極めて有効です。Outputの中に、最終的な回答だけでなく、そこに至る「思考プロセス」を含めるのです。
例：
- Input: このシステムエラーログから原因を特定してください。
- Output:
- まず、エラーコード503が出ていることから、サーバー過負荷の可能性があります。
- 次に、タイムスタンプを確認すると、バックアップ処理の時間帯と重なっています。
- メモリ使用率のログを確認する必要がありますが、現状の情報では「バックアップ処理による一時的なリソース不足」が最も高い可能性として考えられます。
結論：バックアップスケジュールの見直しを推奨します。
このように「考え方」をデータとして与えることで、モデルは未知のケースに遭遇した際にも、同様の論理展開で推論を行う能力を獲得しやすくなります。これは特に、専門性の高いエンジニアリング領域や医療、法律分野でのAI活用において、精度向上の切り札となります。
高品質な学習データを量産する「データエンジニアリング」
「QAペアの有効性は理解できるが、数千件ものデータを作成する工数が確保できない」
これは、実務においてよく直面する課題です。しかし、ここでもテクノロジーが解決策を提供してくれます。人間が全てを手書きするのではなく、強力なLLM（ChatGPTなど）を使って学習データ自体を生成するアプローチです。
既存ドキュメントからの半自動QA生成パイプライン
元となるドキュメント（PDFやWiki）がある場合、以下のパイプラインを構築することで、効率的にデータセットを生成できます。
- チャンク分割: ドキュメントを意味のまとまりごとに分割する。
- QA生成: ChatGPTなどの高性能モデルに、そのチャンクを読ませ、「このテキストから想定される質問と回答のペアを5つ作成せよ」とプロンプトで指示する。
- フィルタリング: 生成されたQAペアのうち、回答が短すぎるものや、幻覚を含んでいそうなものをルールベースまたはLLM判定で除外する。
この「LLMを使ってLLMを育てる」手法はSelf-InstructやEvol-Instructとして知られ、現在のLLM開発における標準的なプラクティスとなっています。ここで重要なのは、生成に使用する「親モデル」の性能です。教師データを作るモデルは、生徒モデル（LoRAで学習させる対象）よりも賢い必要があります。
「多様性」と「網羅性」を確保するプロンプトエンジニアリング
自動生成の落とし穴は、似たようなパターンのデータばかりが量産されることです。例えば、「～とは何ですか？」という質問ばかりが1000件あっても、モデルの応用力は育ちません。
プロンプトエンジニアリングを駆使して、データの多様性（Diversity）を強制的に高める必要があります。
- 「初心者向けの平易な言葉で説明させてください」
- 「ベテラン社員向けの専門用語を使った簡潔な回答にしてください」
- 「質問の意図が曖昧なケースを含めてください」
このように、ペルソナやシチュエーションを変えながらデータを生成することで、モデルは様々な文脈に対応できるロバスト性（堅牢性）を獲得します。
ネガティブサンプル（誤答例）の戦略的活用
意外と見落とされがちなのが、「知らないことには答えない」という能力の学習です。社内規定に書いていないことを聞かれた時に、もっともらしい嘘（幻覚）をつかれては困ります。
そのため、データセットには意図的にネガティブサンプル（拒否回答）を含めるべきです。
- Input: 社長個人の休日の予定を教えて。
- Output: 申し訳ありませんが、提供されたドキュメントにはその情報は含まれておりません。
また、「間違った前提の質問」に対する訂正も学習させると効果的です。これにより、モデルの信頼性は飛躍的に向上します。
精度を左右する「前処理」と「クレンジング」の基準
データが集まったら、最後に徹底的なクリーニングを行います。料理において下ごしらえが味を決めるように、AI開発においても前処理が精度を決定づけます。
ノイズ除去と個人情報マスキングの徹底
自動生成されたデータやOCRで読み取ったテキストには、目に見えないゴミが含まれていることがあります。
- 制御文字の除去: 改行コードの異常連続や、ゼロ幅スペースなどは削除または正規化します。
- 定型文の削除: メールの署名や、ドキュメントのフッターにある「社外秘」といった文言が全てのデータに入っていると、モデルはそれを「回答の必須要素」と勘違いして学習してしまいます。
- PII（個人特定情報）の削除: 社員の実名や電話番号が含まれている場合は、エンティティ抽出ツールなどを使ってマスキング（例：
[NAME],[PHONE]）処理を行います。これはセキュリティ上の理由だけでなく、モデルが特定の個人名に過剰反応するのを防ぐためにも重要です。
トークン長を意識した適切なチャンク分割戦略
LLMにはコンテキストウィンドウ（扱えるトークン数の上限）があります。学習データの長さがこの上限を超えると、データが途中で切り捨てられ、文法が破綻した状態で学習されてしまいます。
LoRA学習を行うベースモデルの最大トークン数（例：Llama 2なら4096、モデルによっては2048など）を確認し、Instruction + Input + Outputの合計がその8割程度に収まるようにデータを調整します。長すぎる場合は、無理に詰め込まずにデータを分割するか、要約タスクを挟んで短縮する工程が必要です。
重複データの排除と正規化のルール
データセット内に全く同じ、あるいは極めて類似したデータが大量に含まれていると、特定の表現に過学習してしまいます。これを防ぐために、De-duplication（重複排除）を行います。
MinHashやSimHashといったアルゴリズムを用いて、意味的に類似したデータを検出し、代表的なものだけを残して削除します。データセットの総数が20%減ったとしても、重複を排除した方が最終的なモデルの汎化性能は向上すると考えられます。「量は質を凌駕する」と言われますが、それは「質の高いデータが大量にある」場合の話であり、ゴミデータが大量にあっても逆効果なのです。
【検証】データセット改善によるBefore/After
最後に、データセットの品質管理が実際にどれほどのインパクトをもたらすのか、検証方法と事例について触れます。
Loss値だけでは見えない「回答品質」の評価指標
学習中、エンジニアはTraining Loss（学習損失）やValidation Loss（検証損失）のグラフを注視します。Lossが下がっていれば学習は順調に見えますが、ここに罠があります。
Lossはあくまで「正解テキストとの文字の一致率」に近い指標であり、「回答の意味的な正しさ」や「有用性」を完全に反映しているわけではありません。Lossが低くても、同じ言葉を繰り返すだけの壊れたモデルができあがることは珍しくありません。
したがって、定量的な指標（BLEUスコアやROUGEスコアなど）だけでなく、定性的な評価が不可欠です。
ベンチマークテストセットの設計方法
学習データとは別に、評価用データセット（テストセット）を必ず用意してください。これは学習には一切使用せず、モデルの実力を測るためだけに使います。
テストセットには、以下の3種類を含めます。
- In-Domain: 学習データと似た傾向の質問（基礎力の確認）
- Out-of-Distribution: 学習データにはない言い回しや応用的な質問（応用力の確認）
- Adversarial: 意地悪な質問や、答えてはいけない質問（防御力の確認）
これらを定期的にモデルに投げ、回答精度を（可能であれば人間が、難しければChatGPTを利用して）採点します。
実際の改善事例：専門用語理解度の向上
製造業において、社内技術文書の検索AIを構築した際の事例では、以下のような変化が確認されています。
- Before: PDFを単純にテキスト化し、チャンク分割してRAG（検索拡張生成）と組み合わせただけの状態。
- 結果：専門用語「XYZ工程」の意味を聞いても、一般的なWeb知識を答えてしまい、社内独自の定義を反映できなかった。
- After: 「XYZ工程とは何か？」という定義QAペアと、「XYZ工程でエラーが出た場合の対処法」というCoT付きトラブルシューティングデータを約500件作成し、LoRAで学習。
- 結果：社内用語を正確に定義できるようになっただけでなく、関連するトラブルシューティングの手順まで自律的に提示できるようになった。
データ件数はわずか500件でしたが、その質を徹底的に高めることで、数万件の雑多なデータを学習させるよりも遥かに高い実用性を実現しています。
まとめ
LoRAによるLLMのファインチューニングにおいて、エンジニアが最も注力すべきはPythonコードの修正ではなく、データセットの設計と品質管理です。
- Data-Centricへ転換せよ: データの質がモデルの賢さを決める。
- 形式を最適化せよ: Instruction形式を基本とし、思考プロセス（CoT）も学習させる。
- 自動化で量産せよ: LLMを活用して多様なデータを効率的に生成する。
- 徹底的に磨き上げよ: ノイズ除去と重複排除で、データの純度を高める。
これらは地味で泥臭い作業に見えるかもしれません。しかし、高度に見えるAIの知能も、結局は入力されたデータの鏡に過ぎません。データに対して論理的かつ体系的にアプローチした結果は、必ずモデルの回答精度、ひいてはプロジェクトのROI（投資対効果）向上として返ってきます。
データセット構築やLoRA活用の具体的な設計を進める際は、業界ごとの詳細なデータ戦略や、先行する成功事例の具体的なアプローチを参考にすることをおすすめします。
コメント