Fine-tuning実践ガイド

どの課題でファインチューニングを選ぶべきか

まずは意思決定です。プロンプト最適化やRAGで十分なときに無理に学習する必要はありません。ファインチューニングが効くのは、(1)表現の一貫性（社内用語・敬語・文体）、(2)手順の厳密化（社内フローや禁止事項の徹底）、(3)タスク固有の出力形式（タグ付け、JSON構造、テンプレ回答）、(4)特定ドメインの長期記憶（FAQパターンの反射速度）です。一方、最新情報や大量の社内文書検索はRAGが基本線、論理推論や汎用知識はChatGPTやClaude、Geminiといった強力なベースモデルのプロンプトで十分なことが多いです。

判断の目安として、プロンプト+RAGで再現率/適合率が頭打ち、かつ出力のバラツキがボトルネックになっているなら学習候補です。さらに、出力コストを下げたい（小型モデルで運用したい）、オフラインで品質を安定化したい、という要件も後押しになります。逆に、データが少ない、方針が変わりやすい、法務・安全要件が未整理の段階では見送りが賢明です。

データ作りが9割：収集・整形・分割の実務

ソースとラベル設計

学習データは「入出力の対」が基本です。高評価のオペレーター返信、過去の承認テンプレ、コードレビュー例、製品Q&Aなどから集めます。1プロジェクトあたり300〜3,000対の高品質例をまず目標にし、長文ばかりに偏らないよう長さ分布を整えます。出力の「良さ」を定義し、必須要素（例：謝罪→原因→代替案→クロージング）をチェックリスト化すると、アノテーションの一貫性が上がります。

クリーニングとフォーマット

個人情報・機密語は正規表現と辞書でマスクし、禁則語を除去します。重複やほぼ同一の例はクラスタリングで間引き、矛盾する教示は統一ルールに合わせて修正します。形式はJSONLでsystem/user/assistantの3役に分け、プロンプトテンプレートも固定しておきます。タスクが複数ある場合はタグを付与（例：style=敬体、format=JSON、policy=返品）し、後段の多タスク学習や重み付けに使います。

分割とリーク対策

学習/検証/テストは7:2:1を目安に、同一案件・同一顧客に紐づく例は必ず同じ集合へ固めてリークを防ぎます。RAG併用時は、参照ドキュメントが訓練とテストで重複しないようハッシュ管理します。評価用には「落としてはいけない必須ケース」（監査・リスク場面）を別途ゴールドセットとして管理し、モデル更新ごとに必ず通します。

学習レシピとコスト見積もり

実務では軽量なパラメータ効率学習（LoRA/QLoRA）が第一選択です。ベースは7B〜8B級で十分なことが多く、日本語ドメインなら語彙とトークナイザの適合度も確認します。初期設定の目安は、学習率5e-5〜1e-4、LoRA rank 8〜16、バッチサイズはGPUメモリに合わせて勾配累積で調整、エポック1〜3、早期打ち切りあり。出力の形式を守らせたい場合は、フォーマット違反にペナルティを与えるスコアベースの選択（best-of）や、JSONスキーマ検証で弾くと安定します。

コストは「総トークン数×単価」だけでなく、事前前処理と評価の人件費を含めて見積もります。例として、平均800トークン×10万例=8,000万トークン規模は過剰で、まずは1万例（800万トークン）から反復し、差分学習で伸ばす方が費用対効果が高いです。運用コストは、学習後に小型モデルへ切替できるかが鍵。応答速度や単価を実測し、ChatGPTやClaude、GeminiのAPI運用と比較してTCOで判断します。社内開発者向けならCopilot的な補完体験を小型モデルで局所最適化する手もあります。

品質評価・安全性・運用のツボ

評価は三層で回します。

(1)自動評価：正規表現/スキーマ/キーワード必須

(2)モデル採点：LLM-as-judgeで観点別スコア（礼儀・事実・手順準拠）を付与

(3)人手：ゴールドセットの二重査読。

オフラインで合格したら、オンラインA/Bで解決率、再問い合わせ率、工数削減を計測します。安全性は、PIIマスク、毒性/差別表現フィルタ、ポリシー違反のデコーダールール、脱漏監査ログをセットに。継続学習では「変更履歴」「データ版」「モデル版」を紐づけ、逆回転できるようにします。忘却（catastrophic forgetting）が出たら、原型タスクの再サンプリングや正則化で緩和します。

身近な企業活用例：地域ECのカスタマーサポート改善

問い合わせメールの文体がばらつき、一次解決率が62%で停滞。最初はRAG+プロンプトでChatGPTを使いましたが、社内用語と返金規定の表現が揺れ、監査で差戻しが多発。次に手元の返信ログ2万件をそのまま学習して失敗。クレームの極端な事例に引っ張られ、謝罪過多・値引き提案が増える副作用が発生しました。

改善では、

(1)高評価返信1,200例に絞り、必須構成（謝意→事実確認→選択肢→次アクション）でラベル付け

(2)返品・配送・支払の3カテゴリで均衡化

(3)JSONテンプレ出力を厳守、の方針でLoRA学習。評価は監査必須30ケースのゴールドでチェック。

結果、一次解決率は62%→81%、再問い合わせ率は-28%、平均応答時間は-35%。運用はFAQ更新をRAGで補い、月次で新規データ300例を追加学習。副作用の「過度な値引き」は、割引提案トークンに重みペナルティを設けて抑制しました。総コストはAPI運用のままより若干増でしたが、工数削減とCSスコア改善で回収できる計算となりました。

ファインチューニングは魔法ではなく、データ作り・評価・運用という地味な基盤の上で成果が出ます。プラットフォーム視点で見ると、データパイプライン、評価ハーネス、モデル/プロンプトの版管理、権限と監査ログを共通化するほど、各チームの横展開が速くなります。生成AIプラットフォーム事業としての価値は、まさにこの共通土台を安定稼働させ、組織内で「学習して良くなる経験」を反復可能にすることにあります。