Naosyファインチューニング vs プロンプト設計 ― 審査 AI の最適カスタマイズ戦略
審査 AI を自社業務に最適化する際、ファインチューニングとプロンプト設計のどちらを選ぶべきか。判断基準・コスト・運用性を比較解説します。
「カスタマイズ」の選択肢を整理する
審査AIを自社業務に最適化するとき、多くのチームが「ファインチューニングすべきか、プロンプトで十分か」という二択に陥ります。しかし実際には、カスタマイズの選択肢はプロンプト設計・RAG・ファインチューニング・それらの組み合わせ（ハイブリッド）の4系統に分かれ、「どれが最強」ではなく「どの失敗モードを解決したいか」で選ぶのが正しいアプローチです。
OpenAIの精度最適化ガイドは、これを単純な線形フロー（プロンプト→RAG→FT）ではなく、**「課題に応じたレバー選択（行列）」**として捉えるべきだと明示しています。
審査タスクが要求する品質
審査業務は「誤判定が直接的に損失・差別・法令違反につながる」ため、一般的な生成タスクよりも厳しい品質が求められます。
| 比較軸 | 審査での意味 | 重視すべき理由 |
|---|---|---|
| 再現性 | 同種の入力に同種の判定が返る | 担当者間・時期間の判定ブレを排除する |
| 説明可能性 | 判定の根拠・理由コードを出せる | 監査対応と顧客への説明責任 |
| 監査可能性 | いつ・誰が・何で判定したかを追跡可能 | EU AI法・金融庁ガイドラインへの準拠 |
| 更新容易性 | 規程変更に迅速に追随できる | 法令改正・社内ルール変更への対応 |
| コスト構造 | 初期費用と1リクエスト単価のバランス | 大量の審査案件を処理する経済性 |
特に金融領域では、金融庁が与信審査・AML/CFT・コンプライアンス違反抽出をAI活用ユースケースとして明示しており、EU AI法でも信用力評価は「高リスク用途」に分類されます。技術選定が精度だけでなくリスク管理プロセスとセットで問われる領域です。
プロンプト設計のメリット・限界
メリット：最速でスタートでき、更新が容易
プロンプト設計の最大の強みは即座に試行錯誤でき、規程変更にもその場で対応できる点です。学習データの整備もGPU環境も不要で、APIキーがあればすぐに検証を始められます。
Anthropicが提唱する「Context Engineering」の考え方では、プロンプト単体ではなく、履歴・外部情報・ツール定義を含む"コンテキスト全体"を最適化することが重要とされています。審査業務では、審査基準（rubric）・過去の判定例・関連規程をコンテキストに含めることで、ファインチューニングなしでも高い精度を実現できるケースがあります。
NAACL 2025の長文ICL（In-Context Learning）研究では、デモ例を数千件まで増やすと性能が上がり続けることが示されています。これは**「少量データしかない初期段階はプロンプト（例示）で戦える」**ことを意味します。
限界：構造化分類では負ける実証がある
一方で、「プロンプトだけで十分」という一般化は危険です。
SemEval 2025 Task 10（プロパガンダ検出の分類）では、LLMは一定の汎化能力を示しつつも、ファインチューニング済みモデルが精度・信頼性で有意に上回ると報告されています。コード領域の比較研究でも、GPT-4を複数のプロンプト戦略で評価しても、ファインチューニング済みモデルに一貫して勝てるわけではなく、データセットによっては28.3ポイント差で負ける例が示されています。
さらに、運用面での限界も無視できません。
- 非決定性 — 同じプロンプトでもモデルの出力が揺れる
- スナップショット差分 — モデル更新で挙動が変わる
- テストの必須化 — OpenAIは「プロンプト性能を測るevalsの構築」と「モデルスナップショットの固定」を強く推奨
ファインチューニング（SFT / DPO）のメリット・限界
ファインチューニングの手法は一枚岩ではない
近年のファインチューニングは用途に応じて複数の手法が区別されます。
| 手法 | 学習データの形式 | 向いているタスク | 審査での位置づけ |
|---|---|---|---|
| SFT | 入力→正解出力のペア | 分類・抽出・定型出力など正解が明確なタスク | 分類ラベルと理由コードの固定化 |
| DPO | 好ましい/好ましくない出力のペア比較 | 振る舞い・トーン・適切性の調整 | 境界事例の判定、説明の保守性の調整 |
| RFT | 報酬関数による反復改善 | 複雑な推論・意思決定 | 設計と運用が重く、慎重な検討が必要 |
OpenAIが推奨するワークフローは**「まずSFTで決め方とフォーマットを固定し、次にDPOで境界事例やトーンを詰める」**という二段構えです。
LoRA / QLoRA：単一GPUで現実的な学習
オンプレミスや閉域環境での運用が求められる審査AIでは、**PEFT（Parameter-Efficient Fine-Tuning）**が事実上の前提になります。
| 手法 | 特徴 | 実績データ |
|---|---|---|
| LoRA | 事前学習済み重みを凍結し、低ランクアダプタだけ学習 | 学習パラメータ数を大幅に削減、GPU メモリ要求も削減 |
| QLoRA | ベースモデルを4-bit量子化してLoRA学習 | 48GB GPUでLLaMA 65B相当の学習を実現。VicunaベンチでChatGPT比99.3%（1GPU・24時間） |
PLOS One 2024の分類タスク研究では、PEFT（LoRA/Adapter）が学習パラメータ数を140〜280倍削減し、学習時間を32〜44%短縮しつつ、分類性能の差が平均1%未満に収まることが報告されています。審査AIのように更新頻度が高い用途では、この反復コスト削減が運用性に直結します。
限界：データ合意率が精度の天井を決める
ファインチューニングの精度上限は「モデル性能」ではなく、「教師データの合意率（Inter-Annotator Agreement）」に強く制約されます。OpenAIのベストプラクティスは、作成者間の一致が70%程度なら、モデルもそれ以上に伸びにくいことを明記しています。
また、DPOはデータ品質の揺らぎに特に敏感です。EMNLP 2024の研究では、RLHFよりDPOの方が品質変動の影響を受けやすいことが示されています。審査用途のように「人手による理由の品質がぶれやすい」ドメインでは、好ましい応答例そのものの品質保証が不可欠です。
ハイブリッドアプローチ — プロンプト + RAG + LoRA
実務で最も効果を発揮するのは、単一手法ではなく目的に応じた組み合わせです。
RAG：知識の鮮度を確保する
RAGは、生成前に社内規程や法令を検索・取得してプロンプトに注入する手法です。Microsoftのガイダンスでは、**「最新情報や変化する情報が必要」「学習用データや計算資源が限定的」**な場合にRAGが選びやすいと整理されています。
ただし、RAGは万能ではありません。Google DeepMindの研究では、単一ベクトル埋め込みには理論的な限界があり、「表現できないtop-kの組み合わせ」が必ず存在することが示されています。RAGを導入する際は以下を測定可能にする必要があります。
- 取得された根拠が判定に必要十分か（再現率/適合率）
- 参照文書が最新の規程か（改訂履歴との同期）
- 取得根拠と出力（判定・理由コード）が整合するか
Doc-to-LoRA：RAGの次の選択肢
RAGの弱点は「毎回同じ文書を読ませるコスト」です。Sakana AIが提案するDoc-to-LoRAは、文書をLoRAアダプタに変換して"長期記憶"として内在化し、以後は文書をコンテキストに入れずに回答できるアプローチです。
SQuAD等の読解タスクで**フルコンテキスト投入の上限性能に対して83.5%**を、更新時間1秒未満で達成しています。「RAGとファインチューニングの中間」に位置し、規程の更新頻度が高い審査業務で検討に値する選択肢です。
判断ディシジョンツリー — あなたの審査業務に最適な手法は？
「プロンプトかファインチューニングか」という二択に落とすと判断を誤ります。失敗モードを分類し、それに対応するレバーを選ぶ方が再現性の高い意思決定ができます。
失敗モード別の対処法
| 失敗モード | 症状 | 第一候補 | 理由 |
|---|---|---|---|
| 知識の不足・古さ | 最新の規程を参照できない、社内商品ルールが出力されない | RAG | 最新の外部情報を検索・注入する |
| 出力形式・分類境界の不統一 | 判定ラベルがブレる、理由コードが統一されない | SFT → DPO | SFTで形式を固定し、DPOで境界を詰める |
| 検索の取りこぼし・ノイズ混入 | 正しい根拠を取得できない | RAG自体の改善 | 検索評価・再ランキング・チャンキング改善が必要 |
| 推論の一貫性不足 | 同種の入力で判定が揺れる | SFT + 評価セット | モデル挙動を固定化し、回帰テストで監視 |
FTを足しても治らない失敗がある
「検索の取りこぼし」が原因の場合、ファインチューニングを追加しても問題は解決しません。RAGは検索とLLMの両方を調整する必要があるため、まず検索品質を評価・改善することが先決です。
段階的アプローチ：評価駆動のフェーズ移行
OpenAIの最適化ガイドが提案する**「evals → prompt → 必要ならFT → eval → 反復」**というフライホイールを、審査AIではさらに明確に定義します。
Phase A（プロンプト設計） — モデルスナップショットを固定し、代表・境界・禁止例を含む評価セットを構築。プロンプトの最適化で目標精度に近づける。
Phase B（RAG導入） — 根拠文書の取得品質を評価に組み込む。「根拠が取れているのに誤判定」なのか「根拠が取れていない」なのかを分離することが鍵。
Phase C（SFT） — 分類ラベルと理由コードを確定し、まず50件の高品質例から着手する。OpenAIのベストプラクティスでは、実務上は数百〜数千件を推奨。QLoRAなら単一GPUで24時間規模の学習が可能。
Phase D（DPO） — 出力の「好ましさ」（過剰承認を避ける、違反疑いは人手へ寄せる等）を対比較データで詰める。DPOはデータ品質の揺らぎに敏感なため、データ品質ゲート（フィルタリング等）を必ず設計する。
コスト・運用性の現実的比較
審査AIのTCOは**「初期費用 + 月額運用費 + 更新費用」**に分解して比較すると、意思決定が明確になります。
API型の実データ（2026年2月時点）
| コスト項目 | 具体的な金額 |
|---|---|
| GPT-4.1 ファインチューニング（学習） | $25 / 100万トークン |
| GPT-4.1 mini ファインチューニング（学習） | $5 / 100万トークン |
| RFT（o4-mini 学習） | $100 / 学習時間（hour） |
| File Search Storage（RAG） | $0.10 / GB-day（最初の1GBは無料） |
| File Search tool call（RAG） | $2.50 / 1,000 calls |
手法別コスト構造の比較
| 手法 | 初期費用 | 月額運用費 | 更新時の負荷 |
|---|---|---|---|
| プロンプト中心 | 低（設計＋評価整備の人件費のみ） | 高め（Few-Shotや長文規程でトークン増） | 低（プロンプト修正のみ） |
| RAG中心 | 中（データ整備＋検索評価） | 高め（トークン＋検索コール＋ストレージ） | 中（文書更新＋検索品質の再評価） |
| SFT中心 | 高（教師データ作成＋学習） | 低め（短いプロンプトで済む場合あり） | 高（再学習＋回帰テスト） |
| ハイブリッド | 中〜高 | 中 | 中（変更箇所に応じたレバーを選択） |
見落としがちなコスト：モデル廃止への追随
長期運用で最も見落とされやすいのがモデルの更新・廃止（deprecation）への追随コストです。OpenAIはAPIモデルの廃止スケジュールと移行先を公開していますが、移行時の挙動変化は審査AIにとって重大事故につながり得ます。**変更管理と回帰評価（evals）は"任意のコスト"ではなく"必須コスト"**として計上すべきです。
日本市場での選定ポイント
日本語審査タスクでは、規程文の微妙な表現・敬体/常体の文体差・漢字/数字/単位の正規化・出力フォーマット遵守が精度を左右します。
国内モデルの活用
| プロジェクト / 企業 | 特徴 | 審査AIでの活用ポイント |
|---|---|---|
| Swallow | 継続更新されるリーダーボード、評価再現性が高い | 日本語モデルの「比較可能性」のベースラインとして有用 |
| PLaMo 2（Preferred Networks） | SFT→DPOの事後学習パイプラインが技術報告として公開 | 「どこを学習で固定し、どこを推論時に制御するか」の設計参照 |
| ELYZA | 日本語評価データセット（ELYZA-tasks-100）と評価手法を公開 | 評価コスト（100問×3名採点）の定量化参考 |
PLaMo 2のブログでは、「複数制約を同時に満たす指示追従」と「出力フォーマット制約」を評価するJFBench/JFTrainの構築が紹介されています。審査AIの現場では「判定は合っているが出力が壊れる」事故が致命傷になりやすく、フォーマット遵守を測定する設計は極めて重要です。
金融・与信審査のガバナンス
金融庁のディスカッションペーパー（2025年3月公表）では、金融分野のAI活用として与信審査等が明示され、生成AIの利用範囲について「一般社員向けに広く認める先が約7割」という調査結果も掲載されています。審査AIの導入では、技術選定より先に**「誰がどこまで使えるか」の利用統制**を決める必要があります。
まとめ：失敗モードから逆算して手法を選ぶ
審査AIのカスタマイズは「プロンプトかファインチューニングか」の二択ではなく、失敗モードを特定し、それに対応するレバーを段階的に適用するプロセスです。
| ケース | 推奨手法 | 理由 |
|---|---|---|
| データ少・規程変更が頻繁 | プロンプト設計 + RAG | 初期コスト最小、更新が即座に反映される |
| 分類精度を追求・判定ブレを排除 | SFT（LoRA/QLoRA） | 出力形式と分類境界を学習で固定化できる |
| 境界事例の判定品質を上げたい | SFT → DPO | SFTで基本を固め、DPOで微妙な判定を詰める |
| 毎回同じ規程文書を参照するコストが高い | Doc-to-LoRA | 文書をアダプタに内在化し、推論コストを削減 |
| すべての軸でバランスを取りたい | ハイブリッド（プロンプト + RAG + SFT） | 各手法の強みを組み合わせる |
導入を検討される際のポイントは以下の3つです。
- 「まずプロンプト + 評価セット」から始める — ファインチューニングの前に、評価データセットを構築し、プロンプト最適化で到達できる精度を確認する
- 失敗モードを分類して対処する — 精度不足の原因が「知識不足」「形式不統一」「検索品質」のどれかを切り分け、適切なレバーを選ぶ
- TCOを全コスト構成要素で比較する — 学習コストだけでなく、検索コール課金・ストレージ・モデル廃止時の移行コストを含めて試算する
Naosyでは、審査AIのカスタマイズ戦略の設計から、評価セット構築、ファインチューニング実装、運用パイプラインの構築まで一貫して支援しています。まずは現状の審査精度の課題をお聞かせください。
この記事の著者
Naosy 編集部
レビュー・校正・審査プロセスの最適化に関する実践的なナレッジを発信しています。
