はじめに

生成 AI を金融業務に使ううえで重要なのは、単に高性能なモデルを選ぶことではなく、データの扱い方や評価基準を含めて「自社で説明できる形」に落とし込むことです。本記事では、ローカル環境で扱える日本語モデルを金融タスクに合わせて fine-tuning し、固定ベンチマークで継続的に評価する実装ループを紹介します。

具体的には、 NVIDIA によってスクラッチから学習された大規模言語モデル（LLM）であり、推論タスクと非推論タスクの両方に対応する統合モデルとして設計され、日本語に特化して最適化された”NVIDIA Nemotron-Nano-9B-v2-Japanese” をベースに、JaFIn (Japanese Financial Instruction Dataset)を用いた LoRAでのファインチューニングを行い、 japanese-lm-fin-harness による評価を通じて、小型モデルでもどこまで実務性能を引き上げられるかを検証します。結果として、 JaFIn でGPT-5と同水準に到達しました。これは、評価設計とデータを適切に絞れば、ドメイン特化 SLM が実務で十分戦えることを示しています。
本記事では、この結果に至るまでの設計・実装・評価のポイントを整理し、金融向け日本語 LLM を「小さく作り、測り、改善する」ための具体的なアプローチを解説します。

1. なぜ日本語LLM を金融向けファインチューニングするのか

金融領域で日本語 LLM を使う目的は、一般的な会話能力を業務で求められる語彙や制度知識、回答形式、評価基準に適応させることです。

社内 FAQ、監査・会計、税務、IR、与信、証券販売、コンプライアンスでは、自然な日本語に加えて、制度名、勘定科目、選択肢形式、根拠提示、曖昧さの扱いが品質を左右します。金融向けのモデルでは、流暢に答える力だけでなく、業務上使える形式で、安定して、検証可能な回答を返せることが重要になります。

ここで重視すべき点は、モデルの精度向上に加えて、AI の改善サイクルを自社でコントロールできることです。金融機関では、顧客情報、社内規程、監査資料、営業履歴、リスク判断のログが、競争力と説明責任の両方に直結します。外部 API の高い性能を活用する選択肢は有効ですが、すべての金融データを外部に出せるわけではありません。自社環境で学習し、評価し、checkpoint を選び、ログを残せるモデルを持つことで、精度とデータ主権を同じ設計の中で扱いやすくなります。

ファインチューニングの価値は、業務に必要な精度を、管理可能な形で積み上げられる点にあります。どのデータで改善したのか、どの評価タスクで伸びたのか、どの checkpoint を採用すべきかを追跡できれば、モデル選定は感覚的な比較から、再現可能な改善プロセスに変わります。金融AI では、この再現性がそのまま監査可能性、運用品質、社内説明のしやすさにつながります。

本記事の実装方針は、9Bクラスの日本語モデルをベースに、JaFIn で supervised fine-tuning を行い、japanese-lm-fin-harness の固定タスクで評価する最小ループです。LoRA を採用することで、GPUメモリー、学習時間、checkpoint 管理の負荷を抑えながら、target_modules、rank、learning rate、checkpoint の探索に集中できます。

2. 技術構成：model / dataset / benchmark / adapter

最小構成は、ベースモデル、SFT データ、金融ベンチマーク、LoRA アダプターの四層です。推論基盤は vLLM、NVIDIA TensorRT-LLM、Transformersなどが候補になりますが、学習の初期実装は Hugging Face Transformers + PEFT + datasetsの組み合わせが適しています。これにより、adapter の差し替え、merged export、token length auditといった作業を比較的容易に管理できます。

3. NVIDIA Nemotron-Nano-9B-v2-Japanese について

NVIDIA Nemotron-Nano-9B-v2-Japanese は、 NVIDIA によってスクラッチから学習し、日本語に特化して最適化された 9Bクラスの reasoning model です。最大 128K トークンのcontext長をサポートしています。ローカル検証では、単一 GPU でも実験設計を始めやすく、GPU メモリーに余裕がある環境では長文処理やバッチ推論、マージ済みチェックポイントの比較検証まで広げられます。

アーキテクチャーは Mamba-2、MLP、少数の Attention 層を組み合わせた hybrid 構成です。この点は LoRA の target_modulesを選定する際にも重要になります。標準的な Transformer なら q_proj、k_proj、v_proj、o_proj が初期候補になりますが、Nemotron-Hybrid では Mamba 系の in_proj / out_proj、MLP 系の up_proj / down_proj も検討対象になります。

また、reasoning trace の扱いも注意が必要です。enable_thinking を使う場合は、学習、評価、推論で chat template と生成設定を揃えます。学習時だけ thinking を含め、評価時に外す構成にすると、出力形式と解答抽出がずれやすくなります。金融ベンチマークでは、正答選択や短い説明を要求するタスクが多いため、推論能力と回答フォーマットの両方をログで確認します。

4. JaFIn を supervised fine-tuning データとして使う

JaFIn は、日本語金融 QA を instruction / input / output 形式で扱える SFT データです。財政、国債、地方債、税務、金融制度など、金融業務で頻出する説明型の質問と回答が含まれます。データ量は1500QAペアと小規模なので、巨大な知識注入の用途よりも、金融語彙の表現、回答の構造化、制度説明の言い回しをモデルへ寄せる用途に向いています。

SFT では、instruction と input を user content にまとめ、output を assistant response として教師信号にします。label は assistant 側 token のみに付け、prompt 側は -100 でマスクします。これにより、モデルは金融回答を生成する方向に勾配を使います。

小規模金融データで学習するには token length audit が有効です。長すぎる output が一部に含まれていると、loss と GPU メモリーが不安定になり、短い選択式 benchmark の改善に直結しにくくなります。そのため、max_length、max_assistant_tokens、truncation ルール、空 input の扱いを統一し、各 run に dataset fingerprint と token statistics を残し、再現性を確保します。

def build_messages(example):
    user_text = example["instruction"]
    if example.get("input"):
        user_text += " " + example["input"]
    return [
        {"role": "user", "content": user_text},
        {"role": "assistant", "content": example["output"]},
    ]

5. japanese-lm-fin-harness による金融ベンチマーク

japanese-lm-fin-harness は、日本語金融ドメインで LLM を比較するための評価ハーネスです。本検証では、chabsa、cma_basics、cpa_audit、fp2、security_sales_1 の5つをベンチマークとして使います。base model と LoRA model を同じ task list、harness revision、 prompt convention で測ることで、改善の有無を実験ごとに比較できます。金融特化 LLM の評価では、単一の QA タスクだけを見ると、モデルが「金融らしい文章」を生成できるのか、実務上の判断に必要な知識を持っているのか、分類・読解・選択式問題に安定して対応できるのかを判断しにくくなります。そのため、金融テキスト理解、管理会計、監査、ファイナンシャルプランニング、証券販売にまたがる複数タスクで評価します。

MODEL_PATH=$ROOT_DIR/outputs/iter16_attn_mamba_safe_ep2_lr5e-5_enable_thinking_ckpt100/merged
TASKS='chabsa-1.0-0.2,cma_basics-1.0-0.2.1,cpa_audit-1.0-0.2.1,fp2-1.0-0.2.1,security_sales_1-1.0-0.2.1'
RUN_NAME=iter16_attn_mamba_safe_ep2_lr5e-5_enable_thinking_ckpt100 BENCH_MODE=merged MODEL_PATH=$MODEL_PATH TASKS=$TASKS bash scripts/run_fin_benchmark.sh

6. LoRA fine-tuning の実装ポイント

LoRA は、事前学習済みモデルの重みを固定したまま、線形層に低ランク行列の更新を追加する parameter-efficient fine-tuning です。主な設計変数は rank、alpha、dropout、target_modules、bias、量子化、merge 方針などがあります。金融 QA のような小規模 SFT では、学習可能パラメータを絞り、checkpoint を細かく比較する方が安定した評価が得やすくなります。

RUN_NAME=scan01_attn_mamba_safe_ep2_lr5e-5_enable_thinking_steps20 
TARGET_PRESET=attn_mamba_safe FORCE_TORCH_MAMBA=0 NUM_EPOCHS=2 LEARNING_RATE=5e-5 
bash scripts/run_train_jafin.sh   --enable_thinking   --save_strategy steps   --eval_strategy steps   --save_steps 20   --eval_steps 20

7. 実験結果の読み方

今回の5 では、base model の score_primary 0.5747 に対し、LoRA best checkpoint は 0.6718 まで改善しました。gain は +0.0971 です。同じ benchmark contract に GPT-5 Chat API を並べると score_primary は 0.6683 であり、今回の LoRA best は GPT-5 Chat に非常に近い水準、かつ primary score ではわずかに上回る結果です。採用 checkpoint は iter16_attn_mamba_safe_ep2_lr5e-5_enable_thinking_ckpt100 で、設定は attn_mamba_safe、2 epochs、learning rate 5e-5、enable_thinking です。

スコア改善の主な要因は、CMA Basics、FP2、Security Sales の伸びです。CHABSA はベースの時点ですでに高く、追加で改善できる余地が小さい状態でした。CPA Audit は横ばいで、監査系の選択式問題については、説明型 QA を中心とした SFT だけでは伸びが限られる可能性があります。

GPT-5 Chat などの API モデルは response text matching の経路で評価され、ローカルの HF モデルは likelihood scoring の経路で評価されます。そのため、0.6718 > 0.6683 という結果は、この固定されたベンチマーク条件における技術的なシグナルとして捉える必要があります。

汎用的なチャット能力を含めた広い意味での順位づけについては、今後の追加評価で検証する予定です。今回の金融タスクに限定した条件では、local 9B + LoRA が最先端の LLM に匹敵する評価点に到達しました。

8. 実運用に向けた注意点

・ データ混入：JaFIn、追加 SFT データ、few-shot 例、評価データの重複経路を確認する。金融タスクほど contamination check を厳密に残す。
・ 評価ベンチマーク：task list、harness revision、prompt template、few-shot 数、answer extraction、seed、checkpoint path を run manifest に固定する。
・ 出力制御：金融 QA は「短い結論、根拠、注意点」の形式に寄せる。RAG/Agent 前処理では JSON や箇条書きなど downstream が読める形式を優先する。
・ checkpoint 選択：小規模 SFT では途中 checkpoint が最良になりやすい。best checkpoint、best eval loss、best benchmark を分けて保存する。
・ Mamba fast path：LoRA を当てた module が実際の forward path で使われ、勾配を受けているかをログ化する。
・ デプロイ：adapter 運用は差し替えやすく、merged model 運用は serving がやりやすい。社内本番ではライセンス、監査ログ、RAG 参照元表示、出力検証を加える。

オプション：AutoResearch を使う

AutoResearch は、 AI agent に小さな学習実験を自律的に回させる、元TeslaのAIディレクターでありOpenAIの共同創業者でもある研究者Andrej Karpathyが提案したワークフローです。 本記事の中心は model / dataset / benchmark / adapter の4点構成でしたが、 これまでしたことを、 fine-tuning と benchmark を短い反復ループに整理して、 AI Agentの力を借りて、パラメーター を自律的に探索し続けることもできます。

実験管理を始めるには、まずprogram.md に mission、benchmark contract、acceptance rule、run manifest の保存フォーマットを定義します。各 run では metrics、token_length_stats、sampling_stats、benchmark result、生成 sanity check を残し、次の探索候補を keep / discard で管理します。評価では最終スコアに加えて、どの task が伸び、どの失敗型が残ったかを確認することが重要です。

まとめ

今回は、金融向けに絞った小型ローカルモデルで、精度、データ管理、監査可能性を同時に高めるアプローチを試してみました。今回の best checkpoint は score_primary 0.6718 を記録し、GPT-5 Chat API（0.6683）と同水準で、わずかに上回りました。金融 QA、監査・会計、証券販売のように業務範囲を明確にできる領域では、ドメイン特化 SLM が frontier LLM に匹敵する性能を発揮できます。

実務で重要なのは、モデルの出力品質に加えて、改善プロセスを管理できることです。どのデータを使い、どの評価で判断し、どの checkpoint を採用し、どのログを残すのか。この一連の流れをローカル環境で扱えると、機密データを社内に置いたまま、評価結果を蓄積し、コストとレイテンシを予測しながら、業務に合わせてモデルを更新できます。金融機関にとって、この管理可能性は精度そのものと同じくらい重要です。

LoRA による日本語金融 SLM の fine-tuning は、この考え方を小さく始めるための現実的な手段です。大規模な基盤モデルを最初から作る必要はありません。まずは 9B クラスのモデルに対して、金融データ、固定 benchmark、adapter 探索、評価ログを揃えることで、実務に近い改善サイクルを構築できます。

次の一歩は、対象業務を一つに絞り、評価セットを固定し、base model と LoRA model の差分を継続的に測ることです。監査 FAQ、証券販売 QA、金融文書分類のような具体的な業務から始めると、精度、コスト、データ主権のバランスを検証しやすくなります。将来的には、このようなローカルモデルを RAG や Agent の一部に組み込み、社内ナレッジ検索、問い合わせ分類、回答生成の品質を高める展開も考えられます。

参考資料

• NVIDIA Nemotron-Nano-9B-v2-Japanese
• Sakaji-Lab/JaFIn
• pfnet-research/japanese-lm-fin-harness
• LoRA: Low-Rank Adaptation of Large Language Models
• Hugging Face PEFT LoRA documentation
• karpathy/autoresearch
• guchengwei / autoresearch-nemotron-jp-finance-lora

関連ページ