指示チューニング（Instruction Tuning）とは、要約、分類、質問応答、変換など多様なタスクを「自然言語の指示と望ましい応答」の形へそろえ、事前学習済みLLMへ追加学習する方法です。狙いは一つの業務だけを覚えさせることではなく、指示を読んでタスクを判断し、学習時に見ていない種類や言い回しにも対応しやすくすることです。
多くの指示チューニングはSFT（Supervised Fine-Tuning、正解例を使う教師あり追加学習）として実装されます。ただし、SFTは「どう学習するか」、指示チューニングは「どのようなデータを集め、何へ一般化させるか」に重心があります。この違いを押さえると、Fine-tuning、Instruction Tuning、RLHFを同じ軸で比べる混乱を避けられます。
- 3文要約
- この記事で分かること
- 指示チューニングを一言で定義する
- SFT、Instruction Tuning、RLHFは何が違うのか
- なぜ「次のtoken予測」から指示追従を学べるのか
- instruction、input、responseはどうモデルへ入るのか
- なぜ多様なタスクを混ぜるのか
- 「データ件数」よりタスク構成を見る
- データセットをどう混ぜるか
- instruction templateの多様性
- 未見タスクを評価するには分割単位を変える
- 人手データの設計で決めること
- 合成データは量を増やすが、正解を保証しない
- 指示チューニングで起きやすい失敗
- 何を評価すればよいか
- 指示追従、事実性、安全性は別の目標
- 実務での進め方
- 学習前のチェックリスト
- まとめ
- 次に読むべき記事
- 参考資料
3文要約
- 指示チューニングは、複数のタスク群をinstruction、任意のinput、望ましいresponseへ変換し、指示追従と未見タスクへの転用を狙う多タスクSFTです。
- 成否を左右するのは総件数だけではなく、タスクの多様性、指示の言い換え、データセット間の混合比、応答部分へ正しく損失を掛ける実装、評価データとの分離です。
- 指示を守りやすくなっても、最新知識、事実性、安全性、価値判断まで自動的に保証されるわけではなく、別のデータ・評価・仕組みが必要です。
この記事で分かること
この記事では、指示チューニングを「会話口調を付ける処理」としてではなく、データ、学習目的、一般化評価を含む一つの設計問題として整理します。
- SFT、単一タスクFine-tuning、Instruction Tuning、RLHFの関係
- instruction、input、responseをchat templateへ直列化する流れ
- response-only loss mask（応答部分だけを学習対象にするマスク）
- 多数のデータセットを混ぜるときのサンプリング設計
- FLAN、T0、Super-NaturalInstructionsが検証した一般化
- Self-Instruct型の合成データを使う場合の品質管理
- 漏洩、過学習、過剰拒否、一般能力低下を見つける評価
指示チューニングを一言で定義する
指示チューニングは、自然言語で記述したタスクとその実行例を複数集め、指示から望ましい出力へ写像する能力を追加学習する方法です。典型的な1件は次の要素を持ちます。
| 要素 | 役割 | 例 |
|---|---|---|
| instruction | 何をしてほしいかを定義する | 「次の問い合わせを3分類してください」 |
| input | 処理対象。不要なタスクでは省略できる | 「請求書を再発行したい」 |
| response | 望ましい出力 | 「請求・支払い」 |
| metadata | タスク名、出典、言語、品質、権利など | task_id、source、license |
単一の問い合わせ分類器を作るだけなら、同じ形式の例を増やす単一タスクFine-tuningでも目的を達成できます。指示チューニングでは、分類だけでなく、要約、抽出、言い換え、質問応答、推論、形式変換などを同じ学習へ混ぜます。モデルが「特定ラベルを返す装置」ではなく、「自然言語で与えられた課題を解く装置」へ近づくことを狙うためです。
SFT、Instruction Tuning、RLHFは何が違うのか
これらは完全に排他的な手法ではありません。比較する軸が違います。
| 用語 | 主に答える問い | 典型的なデータ | 学習信号 | 主な狙い |
|---|---|---|---|---|
| Fine-tuning | 事前学習後に追加学習するか | 任意 | 任意 | 用途への適応全般 |
| SFT | 正解例を教師として学ぶか | 入力と望ましい出力 | token単位の交差エントロピー | 応答例の模倣 |
| Instruction Tuning | 多様な指示へ一般化させるか | 複数タスクの指示と応答 | 多くはSFT | 指示追従、未見タスクへの転用 |
| Preference Tuning / RLHF | 複数の候補のどれが望ましいか | 比較、順位、報酬 | 選好または報酬 | 応答の優劣を反映 |
| LoRA / Full tuning | どのパラメータを更新するか | 上記のどれでもよい | 上記の目的関数 | 計算・保存方法の選択 |
したがって「SFTとInstruction Tuningのどちらを選ぶか」という質問は、そのままでは粒度が合いません。Instruction TuningをSFTで実行し、その更新方法としてLoRAを使う構成は普通に成立します。
前回のFine-tuningとは？LLMを用途に合わせて調整する方法では、追加学習全体とLoRAなどの更新方式を扱いました。本記事では、その中でも多様な指示データを使って一般化を狙う設計へ絞ります。
なぜ「次のtoken予測」から指示追従を学べるのか
事前学習と同じ自己回帰型LLMなら、指示チューニングでも基本は次tokenの確率を高めます。違うのは、学習させる系列の中身と、どのtokenへ損失を掛けるかです。
instructionを \(x\)、望ましいresponseを \(y=(y_1,ldots,y_T)\) とすると、応答部分だけを対象にした損失は概念的に次のように書けます。
実装ではinstruction、input、区切り記号、responseを一つのtoken列へ連結することがあります。その場合は、各位置が学習対象かを示すmask \(m_t\) を使います。
prompt部分を \(m_t=0\)、assistant responseを \(m_t=1\) とすれば、モデルへ「質問文そのものを再生成する」よりも「条件を読んで回答する」勾配を集中させられます。ただし、prompt側も学習対象にする設計や、encoder-decoder型のように入力と出力を分ける構成もあります。論文や実装を比べるときは、単に「SFTをした」ではなく、直列化とmaskを確認する必要があります。
instruction、input、responseはどうモデルへ入るのか
人が見るJSONと、モデルが読むtoken列は同じではありません。たとえば元データが次の形だとします。
{
"instruction": "問い合わせを分類してください",
"input": "パスワードを忘れました",
"response": "アカウント・ログイン"
}chat modelでは、tokenizerに対応したchat template（system、user、assistantなどの役割と区切りを一つの文字列へ変換する規則）で直列化します。
<system> あなたはサポート分類器です。
<user> 問い合わせを分類してください
パスワードを忘れました
<assistant> アカウント・ログインここで重要なのは、学習時と推論時に同じ規則を使うことです。区切りtoken、BOS/EOS、assistant開始記号がずれると、本文の質とは別の理由で出力が不安定になります。また、長いinstructionやfew-shot例を入れすぎてresponseが最大系列長から切り落とされると、教師信号がほとんど残りません。
データ検査では少なくとも次を可視化します。
- 直列化後のtoken列
- roleごとのtoken数
- loss maskが1になった位置
- truncation後にresponseが残る割合
- EOSが意図した位置へ入っているか
- 推論時promptと学習時promptの差
なぜ多様なタスクを混ぜるのか
一つの感情分類だけを学習したモデルは、その入力分布やラベル形式には適応できても、未知の要約指示を解けるとは限りません。指示チューニングは、異なるタスクに共通する「指示を読み、入出力関係を推定し、指定形式で返す」という上位のパターンを学ばせようとします。
Finetuned Language Models Are Zero-Shot Learnersで提案されたFLANは、60を超えるNLPタスクを自然言語のinstruction templateへ変換し、学習から外したtask cluster（近い種類のタスク群）でzero-shot性能を測りました。論文のablation（要素を外して影響を見る比較）では、学習データセット数、モデル規模、自然言語instructionが重要な要素として報告されています。
T0の論文も、多数の教師ありデータセットを複数の自然言語promptへ変換して学習し、完全にhold-outしたタスクで評価しました。両研究が示すのは、「答えの例を大量に暗記すれば何にでも答えられる」ということではありません。多タスク学習と自然言語の課題記述を組み合わせることで、少なくとも各論文のモデル・データ・評価条件では、未見タスクへのzero-shot一般化が改善したという結果です。
「データ件数」よりタスク構成を見る
同じ100万件でも、一つの巨大データセットから集めた100万件と、異なる能力を要求する多数タスクからバランスよく集めた100万件では意味が違います。Scaling Instruction-Finetuned Language Modelsは、タスク数、モデル規模、chain-of-thoughtデータなどを拡張し、複数のモデル系列と評価設定でinstruction finetuningを検証しました。
さらにThe Flan Collectionは、task balancing（タスク間の学習量を調整すること）とデータ拡張が重要であり、zero-shot、few-shot、chain-of-thoughtのprompt設定を混ぜる設計を分析しています。
ここから得られる実務上の教訓は、総行数だけをKPIにしないことです。データ台帳には、次の分布を持たせます。
| 観点 | 確認すること | 偏ると起きやすいこと |
|---|---|---|
| タスク | 分類、抽出、生成、推論、変換 | 多いタスクだけ得意になる |
| 指示表現 | 命令形、質問形、制約の置き方 | 特定の言い回しへ依存する |
| 出力形式 | 自由文、ラベル、JSON、表 | 形式変更に弱くなる |
| 応答長 | 短文、長文、手順 | 常に短い／冗長になる |
| 言語 | 日本語、英語、その他 | 少数言語の性能が落ちる |
| 難易度 | 単純、複合、曖昧、解けない | 境界条件で破綻する |
| 出典 | 人手、業務ログ、合成 | 一つの文体や誤りを複製する |
データセットをどう混ぜるか
タスク \(k\) のデータ分布を \(D_k\)、混合重みを \(w_k\) とすると、多タスクの目的関数は次のように表せます。
全レコードをそのまま連結すると、最大のデータセットが勾配の大半を占めます。一方、すべてのタスクを完全に均等にすると、数十件しかない低品質タスクを何度も反復する可能性があります。代表的な選択肢は次の通りです。
| 混合方法 | 長所 | 弱点 | 向く状況 |
|---|---|---|---|
| 件数比例 | 元のデータ量を反映しやすい | 大規模タスクが支配する | 分布が目的に近い |
| タスク均等 | 少数タスクも学べる | 小規模データを過剰反復しやすい | タスク横断一般化を重視 |
| 上限付き | 巨大データセットの支配を抑える | 上限の根拠が必要 | 規模差が大きい |
| 温度付き | 比例と均等の中間を調整できる | 温度もhyperparameterになる | 多数データセットを混ぜる |
| 手動重み | 製品要件を反映できる | 継続監視と説明責任が必要 | 重要タスクが明確 |
重みは一度決めて終わりではありません。validationをタスク別、言語別、出力形式別に追い、改善が止まったタスクと悪化したタスクを見ながら更新します。全体平均だけを見ると、主要タスクの改善が少数タスクの崩壊を隠します。
instruction templateの多様性
同じデータを違う文言へ包むだけでも、学習信号は変わります。
- 「感情を答えてください」
- 「このレビューは肯定的ですか、否定的ですか」
- 「positive / negativeのどちらか一語で返してください」
- 「根拠を一文、その後にラベルを返してください」
これらは似た分類でも、要求する出力形式や推論過程が異なります。templateを増やす目的は語尾をランダムに変えることではなく、実運用で変化する指示の表現と制約を覆うことです。
ただし、templateだけをtrainとtestで分け、元の入力・正解が重複していれば、未知の言い回しへ強いように見えて実際は例を記憶している可能性があります。template robustness（言い換え耐性）とtask generalization（未知タスクへの転用）は別々に測ります。
未見タスクを評価するには分割単位を変える
通常のrandom splitは、同じタスクの異なる例をtrainとtestへ分けます。これは「見たタスクの新しい入力」を測るには適切ですが、「学習していない種類の指示へ一般化したか」は測れません。
| 分割方法 | testに残すもの | 測れる能力 | 主な漏洩リスク |
|---|---|---|---|
| 例単位 | 同じタスクの別例 | task内一般化 | 近重複、同一文書 |
| template単位 | 同じタスクの別表現 | 言い換え耐性 | 入出力自体の重複 |
| source単位 | 別文書・別提供元 | source変化への耐性 | 派生版の混入 |
| task単位 | 学習していないタスク | cross-task一般化 | 類似タスクの別名 |
| task cluster単位 | 学習していない種類のタスク群 | より厳しい未知タスク一般化 | cluster定義の恣意性 |
| 時点単位 | 将来時点のデータ | 時系列変化への耐性 | 更新版の先行混入 |
Super-NaturalInstructionsは1,616のタスクと専門家が書いたinstructionを整備し、タスクの一部で学習して残りの未見タスクで評価する枠組みを提供しました。この種のベンチマークは、通常のvalidation lossだけでは見えないcross-task generalizationを測るために使えます。
製品データでも、同じFAQ記事から作った質問の言い換えをtrainとtestへばらまかないよう、元文書IDやtask familyでgroup splitします。公開ベンチマークが学習データへ含まれていないかも、データ名だけでなく本文の近重複まで検査します。
人手データの設計で決めること
指示データには、唯一の正解がない課題が多くあります。「分かりやすく説明する」「丁寧に断る」「必要十分に要約する」といった目標は、annotator（教師データ作成者）ごとに解釈が変わります。
annotation guidelineには、最低限次を明文化します。
- 誰を想定した応答か
- 正確さ、簡潔さ、網羅性の優先順位
- 不足情報があるときに質問するか
- 解けない／確認できない場合の表現
- 出力形式と許容される揺れ
- 安全上回答しない範囲
- 根拠や引用を要求する条件
- 複数の正解がある場合の扱い
一致率が低い例は、多数決で無理に正解へ固定するより、指示が曖昧なのか、評価基準が衝突しているのかを調べます。曖昧な教師はモデルへ曖昧な振る舞いを教えます。
また、業務ログを利用する場合は、品質だけでなく同意、個人情報、機密情報、利用規約、保持期間を確認します。公開データセットも、公開されていることと商用学習へ使えることは同義ではありません。データセット本体、配布元、元コンテンツの権利を分けて記録します。
合成データは量を増やすが、正解を保証しない
Self-Instructは、seed taskから言語モデル自身に新しいinstruction、input、outputを生成させ、無効または類似した例をfilterしてFine-tuningへ使う流れを提案しました。人手で全件を書く場合より規模と多様性を増やせる可能性があります。
しかし、生成器が作ったresponseは自動的にground truth（正しい教師）にはなりません。次の誤りが連鎖します。
- もっともらしい事実誤認
- 指示と回答の不一致
- 同じタスクの言い換えばかり増える重複
- 生成モデル固有の文体や冗長さ
- 安全境界の過不足
- seedに含まれる偏りの増幅
- 評価データや公開ベンチマークの再生成
実運用では「生成できた件数」ではなく、filter後の採用率、task familyの増加、近重複率、人手監査の正答率を追います。検証可能な問題ではルール、計算器、テストコードでresponseを確認し、自由記述では複数評価者や別モデルの判定だけに依存しない抽出監査を組み合わせます。
合成データの作成条件も版管理します。generator model、system prompt、sampling parameter、seed集合、filter規則のどれかが変われば、同名データセットでも性質が変わるためです。
指示チューニングで起きやすい失敗
指示の意味ではなく表面記号を覚える
instruction末尾の定型句や特定の区切りtokenだけを手掛かりにすると、意味が同じ別表現で性能が落ちます。言い換えだけでなく、制約の順序、不要情報、複数条件を変えた評価が必要です。
出力形式は守るが内容が間違う
JSONを正しく閉じることと、中身が正しいことは別です。schema validation、field単位の正解、事実性を分けて測ります。
多数派タスクに引っ張られる
短い分類例が大半なら、説明を求めても一語だけ返す傾向が強まります。応答長、言語、タスク別にsamplingと評価を分けます。
拒否例を増やしすぎて過剰拒否する
安全な依頼まで断るover-refusal（過剰拒否）が起こることがあります。拒否すべき例だけでなく、似ているが回答可能な境界例も入れ、両方を評価します。
一般能力が低下する
狭いデータを繰り返すと、指示追従が改善しても、読解、推論、多言語などbase modelの能力が落ちる場合があります。目的タスクだけでなく、一般能力の回帰テストを残します。
ベンチマーク汚染で性能を過大評価する
問いと答えの完全一致だけでなく、翻訳版、言い換え、元文書、同じgeneratorからの派生を調べます。公開ベンチマークの名称がデータ台帳にないから安全とは限りません。
何を評価すればよいか
一つの総合scoreでは、何が改善し何が壊れたか分かりません。少なくとも次の軸を分けます。
| 評価軸 | 例 | 自動評価 | 人手評価 |
|---|---|---|---|
| 見たタスクの新規例 | 問い合わせ分類 | accuracy、F1 | 境界例の妥当性 |
| 未見タスク | hold-out task family | task別metric | 指示理解、部分点 |
| 指示の言い換え | 語順・制約順の変更 | performance差 | 意味保持の確認 |
| 出力形式 | JSON、ラベル、表 | parse率、schema一致 | 読みやすさ |
| 内容の正しさ | QA、要約、抽出 | exact match、faithfulness検査 | 根拠との一致 |
| 一般能力回帰 | 読解、推論、多言語 | 固定benchmark | 実利用scenario |
| 安全性 | 拒否対象、境界例 | policy test | 過剰拒否と説明 |
| 応答品質 | 簡潔さ、丁寧さ | proxyに限定 | pairwise比較 |
生成タスクでは、referenceと一語一句一致しなくても正しい回答があります。単一のBLEUやROUGEだけで合否を決めず、要求充足、根拠への忠実性、形式、致命的誤りをrubric（評価基準）へ分けます。
モデル同士を比較するときは、temperature、最大出力長、system prompt、few-shot例、停止条件を固定します。学習checkpointだけ変えたつもりでも、推論templateが違えば比較になりません。
指示追従、事実性、安全性は別の目標
「指示どおり答えるモデル」は、誤った前提にも流暢に従う可能性があります。古い知識が更新されるとも限りません。また、ユーザーの指示へ無条件に従うことが安全とは限りません。
| 目標 | 指示チューニングで改善を狙えるか | 追加で必要になりやすいもの |
|---|---|---|
| タスク理解 | 狙える | 多様なinstructionと未見タスク評価 |
| 形式遵守 | 狙える | schema検証、再試行 |
| 最新情報 | 主目的ではない | 検索、RAG、知識更新 |
| 事実性 | 一部はデータ次第 | 根拠付け、検証、評価 |
| 安全性 | 例から学べるが保証しない | 方針、境界例、選好学習、監視 |
| 個人・組織の価値判断 | 一意に定まらない | 明示基準、選好、ガバナンス |
InstructGPT論文では、人が作成したdemonstrationでSFTした後、モデル出力の順位データから報酬モデルを作り、RLHFへ進みました。これは、正解例の模倣と、複数のもっともらしい応答の優劣を学ぶ工程が異なることを示す代表例です。
ただし、すべての製品が同じ工程を必要とするわけではありません。正解が明確な抽出や変換ならSFTと検証器で十分な場合があります。自由記述のhelpfulness（有用性）や複数価値の調整では、選好データが役立つ可能性があります。次回の記事でRLHFの仕組みと限界を詳しく扱います。
実務での進め方
1. 改善したい行動を観測可能にする
「賢くする」ではなく、「未知の問い合わせでもカテゴリをJSONで返す」「不足情報があれば質問を一つ返す」のように成功条件を定義します。
2. task taxonomyを作る
実運用の依頼をtask family、言語、出力形式、難易度、安全境界へ分類します。件数の多さだけでなく、重要度と失敗時の影響も記録します。
3. trainより先に評価集合を隔離する
task cluster、source、時点でhold-outを作り、作成者と保管場所を分けます。合成データ生成promptにも評価例を入れません。
4. 最小構成でbaselineを測る
base model、prompting、RAG、単一タスクSFTなど、学習しない／狭い選択肢も比較します。指示チューニングが本当に必要かを確認します。
5. 直列化とmaskをunit testする
数件をtoken単位で表示し、assistant responseだけにlabelが残るか、truncationで回答が消えていないかを確認します。
6. 混合比を記録して学習する
データセット名、版、task数、例数、sampling weight、重複除去規則、license判断をmanifestへ保存します。
7. slice別に評価する
全体平均、task family、言語、形式、応答長、安全境界、出典別に比較し、改善と回帰を同時に確認します。
8. 一組としてreleaseする
base model、tokenizer、chat template、dataset manifest、training config、checkpoint、inference config、evaluation reportを同じrelease IDへ結び付けます。rollback（以前の安定版へ戻すこと）可能な状態にしてから段階的に配備します。
学習前のチェックリスト
- [ ] 目的を「指示追従」のどの行動へ落としたか
- [ ] 単一タスクSFT、prompting、RAGとの比較をしたか
- [ ] task familyと重要度を定義したか
- [ ] source、license、個人情報、機密情報を確認したか
- [ ] train/testを例だけでなくtask・source単位で分離したか
- [ ] chat templateとloss maskをtoken単位で確認したか
- [ ] truncation後のresponse残存率を測ったか
- [ ] データセット間のsampling weightを記録したか
- [ ] 合成データを正解として無条件採用していないか
- [ ] 形式、内容、一般能力、安全性を別々に評価するか
- [ ] inference条件とrelease構成を再現できるか
- [ ] rollback先を残したか
まとめ
指示チューニングは、多様な自然言語instructionと望ましいresponseを使い、LLMへ指示追従とtask横断の一般化を学ばせる追加学習です。実装はSFTであることが多いものの、価値は学習アルゴリズムの名前より、どのtaskをどう表現し、どう混ぜ、何を未見として評価したかにあります。
FLANやT0の結果は、自然言語instructionを使った多タスク学習が各研究条件でzero-shot一般化を改善できることを示しました。一方、その結果を自社データへそのまま保証するものではありません。task clusterを隔離し、表面のtemplateではなく未知の課題へ転用できたかを測る必要があります。
指示追従の改善と、事実性、安全性、最新知識は別の目標です。データ台帳、損失mask、混合比、slice評価、版管理まで含めて初めて、再現可能な指示チューニングになります。
次に読むべき記事
次回は、正解例を模倣するSFTだけでは表現しにくい「二つの回答ならどちらが望ましいか」を学ぶRLHF（人間のフィードバックによる強化学習）を扱います。
参考資料
- Finetuned Language Models Are Zero-Shot Learners
- Multitask Prompted Training Enables Zero-Shot Task Generalization
- Scaling Instruction-Finetuned Language Models
- The Flan Collection: Designing Data and Methods for Effective Instruction Tuning
- Super-NaturalInstructions: Generalization via Declarative Instructions on 1600+ NLP Tasks
- Self-Instruct: Aligning Language Models with Self-Generated Instructions
- Training language models to follow instructions with human feedback
コメント