大規模言語モデル学習の全体像：AI アプリケーションエンジニアが理解すべきこと
自分でモデルを学習させる必要はない。しかし、モデルがどのように学習されたかは理解する必要がある。本稿は、Java バックエンドから AI アプリケーションエンジニアへ転向する私が、大規模言語モデルの学習を体系的に学んだ際の完全なノートである。研究者向けの論文レビューではなく、私と同じようにアプリケーション層で工学的な判断を求められる人に向けて書いた。
アプリケーションエンジニアが学習を理解すべき理由
AI アプリケーションを開発していると、モデル選定、prompt の調整、Agent のオーケストレーション、評価体系の設計といった判断に毎日向き合う。その判断の質は、モデルが「どこから来たのか」をどこまで深く理解しているかに左右される。
モデルがどのように学習されたかを知れば、なぜ特定のタスクでは優れているのに別のタスクでは苦戦するのか、なぜ benchmark のスコアが高くても自分の用途で使いやすいとは限らないのか、なぜ同じベースモデルでも製品によって性能が大きく異なるのか、新しいモデルが公開されたときに「強くなった」とは具体的に何を意味するのかを理解できる。
これらの答えは、すべて学習工程における設計判断の中にある。
第1章：データは燃料ではなく、能力の設計図である
データパイプライン：6層のフィルタリングが能力の上限を決める
大規模言語モデル学習の第一歩は、学習コードを書くことではなく、データを準備すること である。生データは、Web クローリング、コードリポジトリ、書籍、フォーラム、文書、合成データなどから集められる。しかし、生データをそのまま学習に使うことはできず、漏斗状の完全な処理パイプラインを通す必要がある。
第1層は テキスト抽出（Text extraction） である。生の HTML から本文を取り出し、ナビゲーションバー、フッター、広告コード、cookie のポップアップなどのテンプレート化された内容を除去する。抽出器の品質が、その後の全工程に入るデータの品質を直接決める。
第2層は 言語識別（Language ID） であり、対象言語以外の内容を除外する。この工程が、モデルの多言語能力の分布を直接決める。英語だけを残せば英語モデルになり、中国語が5%しかなければ、中国語能力は英語能力より弱くなる。
第3層は 品質フィルタリング（Quality filtering） である。一般には Wikipedia や高品質な書籍を正例、無作為な Web ページを負例として分類器を学習させる。つまり、特定の「品質」の定義でデータを選別することになる。学術的で正式な内容は通りやすく、口語的あるいは非主流な内容は落とされやすい。ある状況でモデルの性能が悪い場合、その根本原因がここにあることもある。
第4層は 個人情報の削除（PII redaction） であり、メールアドレス、電話番号、身分証番号などを取り除く。法令遵守のために必要だが、過度に削除すると、モデルがこの種の形式を理解する必要がある場面で性能を落とす可能性がある。
第5層は 安全性フィルタリング（Safety filtering） であり、ヘイトスピーチ、暴力、ポルノなどの内容を除去し、モデルの安全行動の基準を直接形作る。
第6層は 重複排除（Deduplication） であり、近似重複の排除と benchmark 漏洩の除去を含む。インターネット上の多くの内容は互いに複製されている。同じ文章が学習データに1,000回現れれば、モデルはそれを過剰に記憶し、他の内容を有効に学ぶ割合が薄まる。Benchmark leakage の除去は、テスト問題の答えが学習データに含まれて評価スコアが不当に高くなることを防ぐ。
このパイプラインから得るべき核心は、Data pipeline changes the capability distribution before training starts. すなわち、データパイプラインは学習開始前の時点で、すでにモデル能力の分布を決めているということだ。捨てたデータをモデルが学ぶことは永遠にない。
データ配合：Mixture Design は最も重要な設計判断
6層のフィルタを通過したデータは、出所ごとに Web テキスト、コード、書籍、フォーラム、文書、合成データといった「バケット」に分けられる。学習時に各バケットをどの割合で使うかが Mixture Design である。
この割合がモデル能力の重点を直接決める。コードの比率が高ければプログラミング能力は強くなる一方、会話能力が弱くなる可能性がある。書籍の比率が高ければ言語能力は向上するが、最新の知識が不足する可能性がある。しかも、効果は単純な線形加算ではない。コード自体が構造化された推論なので、コードデータを増やすと論理推論も向上し得るが、多すぎれば自然言語の流暢さを損なうことがある。
Data Mixing Laws のような研究は、数学的に最適な配合比率を見つけようとしている。Llama 3 では、小規模モデルで多数の mixture 実験を行い、最適な比率を見つけてから大規模モデルの学習に適用した。この工程自体が莫大なエンジニアリング投資である。
重複排除と汚染管理が重要な理由
重複排除が不十分だと、モデルはインターネット上で大量にコピーされた内容を何度も学ぶ。たとえば GitHub 上に数百万回現れる MIT License、ナビゲーションのテンプレート、cookie の告知などである。こうした内容は学習データ内で人為的に重みが増し、本当に価値のある内容を学ぶ割合を奪う。
Benchmark leakage の影響はさらに見えにくい。MMLU や HumanEval のテスト問題が学習データに含まれていれば、その benchmark スコアは不当に高くなる。モデルは能力を身につけたのではなく、答えを「暗記」しただけだからだ。多くのオープンソースモデルが benchmark 上では優秀に見える一方、実際に使うと性能にばらつきがある理由の一つがこれである。
アプリケーションエンジニアへの示唆： モデル選定では benchmark スコアだけを見てはいけない。データパイプラインの仕組みを理解すれば、スコアが重複排除の品質、データ漏洩、配合上の偏りなど、さまざまな要因に左右され得ると分かる。より信頼できる判断方法は、自分の具体的なタスクで評価することであり、これは Evaluation-Driven Development（EDD）の中心思想でもある。
第2章：Scaling Law と Over-Training——学習計算量をデプロイコストと交換する
Chinchilla 則：学習における「理論上の最適値」
モデルの学習には「計算量」（FLOPs）が必要であり、その量はモデルのパラメータ数 × 学習データ量で決まる。総工数 = 作業者数 × 1人当たりの作業時間、という関係に似ている。
DeepMind が2022年に発表した Chinchilla 論文は、固定された計算予算のもとでは、パラメータ数とデータ量をおおむね 1:20 の比率で配分すると loss、すなわち予測誤差が最小になるという古典的な結論を示した。8B パラメータのモデルなら、Chinchilla 最適のデータ量は約 200B tokens である。
Over-Training：実務が理論上の最適値から外れる理由
Meta は Llama 3 8B に 15T tokens を与えた。これは Chinchilla 最適量の75倍である。純粋な学習効率だけを見れば、これは計算の「無駄」に見える。同じ FLOPs でより大きなモデルを学習すれば、さらに低い loss を得られるからだ。
しかし、デプロイの観点では、こちらの方が賢い判断である。学習は一度限りのコストだが、推論コストは継続する。大規模にデプロイするモデルなら、学習に10倍の計算量を使って数百万ドル多くかかったとしても、モデルを半分の大きさにできれば、推論1回ごとのコストは半減し、導入障壁も大きく下がる。長期的な累積削減額は、学習時の追加費用をはるかに上回る。
15T tokens はどれほど大きいのか。約1億5千万冊の書籍に相当し、人類史上出版された全書籍の総量に近い。人が食事も睡眠も取らず読み続けても、読み終えるまで25万年かかる。
Over-training 戦略を支える重要な経験則がある。Total FLOPs はモデル品質を予測する最良の単一指標である。 計算量をより大きなモデルに使うか、より多くのデータに使うかにかかわらず、決定的なのは Total FLOPs である。したがって over-training を使えば、想像するほど学習品質を失わずに、デプロイ時には小規模モデルの利点を得られる。
Single Accelerator：デプロイ制約がアーキテクチャ設計を逆方向から形作る
Google は Gemma 3 で single accelerator を強調した。モデル全体を1基の GPU または TPU にロードして推論でき、複数デバイスでの並列化を必要としないという意味である。これは「偶然動いた」という事後的な結果ではなく、前もって置かれた設計制約だ。パラメータ数の上限、attention head 数、hidden dimension などのアーキテクチャ選択を逆方向から制限する。Single accelerator を目標に選ぶことは、より大きなモデルを作る可能性を手放す代わりに、デプロイ障壁を大幅に下げることを意味する。
アプリケーションエンジニアへの示唆： Over-training とデプロイ制約の考え方を理解すれば、より良いモデル選定ができる。低遅延・低コストが必要な場面では、Llama 3 8B や Gemma 3 27B のような over-trained な小規模モデルが、大規模モデル API を直接使うより適している場合がある。評価すべきなのは、その小規模モデルが自分の具体的なタスクに十分かどうかであり、汎用 benchmark 上の順位ではない。
第3章：システム制約——学習前に固定される工学的判断
学習の本質は分散システムの問題である
学習を研究問題として捉える人は多い。目的関数をどう設定するか、loss をどう下げるか、モデル構造をどう変えるかという問題である。しかし、実際の大規模言語モデル学習では、システム制約こそが中心となる。GPU 数、メモリ帯域、並列化戦略、耐障害性、コストは、学習後に初めて調整できるものではない。どれほど大きなモデルを学習できるか、どれほど長いコンテキストを扱えるか、より複雑なポストトレーニングを実行できるかを、最初から決めてしまう。
これは、単一ノードの Spring Boot アプリケーションと、数百台へデプロイする分散システムの違いに似ている。ビジネスロジックは同じように見えても、後者の中心課題は分散整合性、ネットワーク分断、負荷分散、障害復旧へと完全に変わる。
Fixed Compute Budget：4つの次元をめぐるゼロサムのトレードオフ
固定された計算予算を4つの方向へ「使う」ことができるが、それらは互いに競合する。
上へ進む——より大きなモデル、すなわちより多くのパラメータ。代償は GPU メモリ需要の増加、複数デバイスによる並列化、通信オーバーヘッドの増加である。
右へ進む——より多くの学習データ。代償は学習時間の長期化とデータパイプラインのコスト増である。Llama 3 の over-training 戦略はこの方向を選んだ。
下へ進む——より長いコンテキストウィンドウ。代償は token 当たりの attention コスト増である。標準 attention の計算量は O(n²) であり、シーケンス長を 4K から 128K に伸ばすと、attention の計算量は1,024倍になる。サンプル1件当たりのメモリ使用量が急増するため、同時に処理するデータ数である batch size を直接小さくせざるを得ない。Batch size の縮小は学習効率を下げ、総学習時間を延ばす。
左へ進む——より安価な serving。代償は量子化制約が厳しくなり、quantization-aware training が必要になる可能性があることだ。
核心となる原則は、Every model capability is a budget decision. すなわち、モデルのあらゆる能力は予算上の判断である。Meta は「小規模モデル + 膨大なデータ」、Google は「小規模モデル + 単一デバイスで実行可能」、DeepSeek は「総パラメータ数の大きい MoE + 低いアクティブコスト」を選んだ。どこかの企業の技術が劣っているのではなく、4つの次元で異なるトレードオフを選んでいる。
MoE：コストと効果の工学的な折衷
MoE（Mixture of Experts、混合エキスパート）は、ほぼ同じ計算量で総パラメータ数を拡大するアーキテクチャである。DeepSeek-V3 の場合、総パラメータ数は 671B だが、推論1回当たりで有効になるのは 37B だけで、どの expert を有効化するかは router が決める。総パラメータが多いことで大きな「知識容量」を持ちながら、1回の推論コストははるかに小さい dense モデルに近づけられる。
代償は、システムの複雑性が大幅に増すことだ。ルーティング機構そのものが工学的な難題であり、各 expert が均等に使われるようにする負荷分散には追加の loss 項が必要で、基盤の通信パターンも複雑になる。
深いネットワークと情報の希薄化
現在の大規模言語モデルは数十層、時には100層を超える。Llama 3 8B は32層であり、GPT-4 クラスのモデルは100層を超える可能性がある。層が増えるほど表現できる計算の複雑性は高まるが、同時に 情報の希薄化 という中心的な問題が生じる。
入力情報が数十層の変換を通ると、元の信号が徐々に薄まる。この問題に対する古典的な解決法が Residual Connection である。各層の出力 = その層の計算結果 + その層への入力とし、情報が一部の層を飛び越えて直接先へ進める「直通管」を設ける。現在のあらゆる Transformer アーキテクチャは Residual Connection を多用している。
Kimi の Attention Residuals や Forgetting Transformer といった研究は、この基盤をさらに発展させ、それぞれ attention 内部の情報損失と、超長シーケンスでの情報保持に取り組んでいる。
学習の不安定性：工学上の現実
数千基の GPU で数週間学習した後、loss が突然急上昇する loss spike が発生し、それまで数日分の進捗がすべて失われ、数日前の checkpoint へ戻してやり直さなければならない場合がある。数日分の計算資源、場合によっては数十万ドル相当が、そのまま無駄になる。
さらに見つけにくい問題もある。1基の GPU がエラーを報告せず誤った勾配を生成する、NVLink の帯域が異常になる、ノード間通信が不安定になる、といった問題だ。大規模学習中にこうした障害を素早く検出、分離、復旧する能力は研究所レベルのエンジニアリングであり、論文を読むだけで解決できるものではない。
DeepSeek-V3 の技術報告は、事前学習の全工程で復旧不能な loss spike が一度もなく、rollback も行わなかったと特に述べている。また、超大規模モデルにおける FP8 混合精度学習の実現可能性を公に検証した数少ない事例でもある。全工程で約278万8千 H800 GPU 時間を使い、14.8T tokens を安定して学習した。この「全工程で安定」という事実自体が、最も注目すべき工学的成果である。
アプリケーションエンジニアへの示唆： 分散学習の細部まで習得する必要はないが、こうした制約を理解すれば、「なぜこのモデルのコンテキストは 1M ではなく 128K なのか」という重要な問いに答えられる。これは恣意的な数字ではなく、上記すべてのトレードオフの結果である。学習側はスループットとコストを重視し、推論側は遅延と KV cache 管理を重視するという違いを理解することも、デプロイ最適化の判断に役立つ。
第4章：合成データと蒸留——能力を生産し、移し替える
合成データとは何か
学習データの出所は2つしかない。人間が生み出す実データと、モデルが生み出す合成データである。最も単純な例は、GPT-4 に「光合成についての一般向け解説記事を書いてください」と指示することだ。出力された記事が合成データであり、それを集めて次のモデルの学習に使えば、合成データで学習していることになる。
合成データが必要とされる根本的な理由は、人間のデータが不足しつつあること だ。インターネット上の高品質なテキストには限りがあり、大手企業はクロールできる Web ページやライセンスを購入できる書籍の大半をすでに使っている。同時に、本質的に希少な種類のデータもある。たとえば、人間が書いた高品質な数学的推論過程は非常に少ない。
合成データの典型的な形には、少数の seed instruction から数十万件のデータへ広げる Self-Instruct のような指示・回答ペア、DeepSeek-R1 が生成するような完全な思考過程を含む reasoning trajectory、RLHF/DPO 学習用の良い回答と悪い回答を比較した preference data、既存の知識を学習しやすい形式へ組み直した knowledge-augmented data がある。
合成データが抱える根本的な矛盾
モデルはすでに「知っている」ものを組み替えることしかできず、無から新しい知識を作ることはできない。合成データの品質上限は、それを生成したモデルの能力上限に制約される。また、モデル生成データは人間のデータより「きれい」で「規則的」である。一見すると利点だが、必ずしもそうとは限らない。実際の人間のデータには、多様な表現習慣、非主流な推論経路、非常に大きなスタイルの違いがある。この「ノイズ」こそが、モデルが堅牢な汎化能力を学ぶための鍵となる。合成データだけで学習したモデルは、学習データがカバーする場面では良好でも、境界事例や新しい問題への汎化性能が低下する可能性がある。
蒸留：能力を移し替える工学的手段
蒸留の中心的な考え方は、大規模モデルである teacher から「知識」を取り出し、小規模モデルである student に移すことである。
DeepSeek-R1 の蒸留は、本質的には教師あり微調整（SFT）であり、学習データが大規模モデル由来だという点だけが異なる。具体的には、まず 671B パラメータの MoE である R1 大規模モデルを学習し、強化学習で深い推論を身につけさせる。次に、多数の難しい問題を R1 に入力し、試行錯誤、訂正、検証を含む完全な reasoning trajectory を生成させる。最後に、それらの軌跡で小規模モデルを標準的な SFT によって学習する。DeepSeek は約80万件の高品質な軌跡を集め、1.5B から 70B までのさまざまな規模の dense モデルを学習した。
この蒸留で重要なのは、小規模モデルが「この問題の答えは何か」だけでなく、「この種の問題に出会ったとき、どのような思考過程を展開すべきか」を学ぶことだ。学習データに完全な推論軌跡が含まれるため、次の token を予測する過程で、実質的に推論のパターンを学んでいる。
より古典的な方法として、Hinton が2015年に提案した Knowledge Distillation がある。大規模モデルの最終出力テキストだけでなく、完全な確率分布、すなわち soft labels も利用する。たとえば、次の単語を予測するとき、大規模モデルが「猫」に70%、「犬」に25%、「机」に5%の確率を割り当てたとする。軌跡蒸留は「答えは猫」とだけ教えるが、Hinton の蒸留は完全な確率分布を伝え、「犬は最適ではないが一定の妥当性がある」という dark knowledge も含める。ただし、Hinton の蒸留では大規模モデルと小規模モデルを同時に動かして logits を取得する必要があり、671B モデルでは工学コストが非常に高い。そのため DeepSeek は、より現実的な軌跡蒸留を選んだ。
蒸留の限界
パラメータ数が同じでも、合成データで学習した新しいモデルは元の大規模モデルと同じにはならない。理由はいくつかある。合成データは大規模モデルの内部表現の「投影」にすぎず、3次元物体の影が奥行き情報を失うのと同じである。モデル生成データは人間データの分布上の多様性を欠く。大規模モデルの能力空間すべてを網羅することはできない。また、大規模モデルの能力の多くは強化学習での探索過程から生じるため、純粋な教師あり学習では完全に再現できない。
より正確には、蒸留によって、小規模モデルは特定のタスクや場面で、大規模モデルよりはるかに低いコストで、大規模モデルに近い、ただし同等ではない性能へ到達できる。 大規模モデルは「能力の源」であり、蒸留は「能力の移送」である。移送には必ず損失があり、範囲も限られる。
ブートストラップの循環：各世代のモデルが次世代のデータを再構成する
合成データはブートストラップの循環を作る。GPT-3 scale の初期モデルが基礎的な instruction data を生成する → GPT-4 scale のより強いモデルが高品質な reasoning trajectory と CoT data を生成する → DeepSeek-R1/o1 scale の RL 学習済み推論モデルが蒸留用の推論軌跡を生み出す → その軌跡からデプロイ可能な小規模モデルを学習する。
この循環には方向性がある。Models must get bigger before they can get smaller. 一部の能力、特に複雑な推論は、十分に大きいパラメータ空間でなければ創発しない。その説明の一つとして、インターネットコーパスでは知識の記憶と推論能力が結びついており、事前学習の目的は両方を同時に学ぶことをモデルに要求するため、十分に大きなモデルでなければ両方を支えられないという考え方がある。しかし大規模モデルは「純粋な推論の実演データ」を生成できるため、分離されたデータで学習する小規模モデルは、推論そのものに集中できる。
したがって、frontier model の価値は自身の serving 能力だけでなく、業界全体へ学習データを供給する点にもある。Frontier model value = training data source for the whole industry, not just its own inference.
アプリケーションエンジニアへの示唆： 蒸留の仕組みと限界を理解すれば、より正確なモデル選定ができる。たとえば DeepSeek-R1-Distill-14B は数学推論で一部の大規模モデルに近づけても、オープンドメインの対話では大きく劣る可能性がある。蒸留データが数学推論に強く集中しているためだ。「このモデルは GPT-4 と同程度」という大まかな主張を信じるのではなく、自分の具体的なタスクで評価する必要がある。
第5章：ポストトレーニング——ユーザーが実感する差はここから始まる
ポストトレーニングが鍵となる理由
事前学習を終えて得られるのは base model であり、本質的には非常に強力な「続きを書く機械」である。自分がアシスタントとして振る舞うべきことを知らない。「東京の天気はどうですか」と尋ねても、答えずに記事の続きを書くかもしれない。すべての「知識」は事前学習で取り込まれているが、協力的でない形に閉じ込められている。
ポストトレーニングは、潜在能力をユーザーが期待する形式で解放する。あらゆる本を読み、頭の中には何でもある人が、「誰かに質問されたので答えるべきだ」という行動様式をまだ知らない状態に似ている。
3つの主要な方法：SFT、RLHF、DPO
SFT（Supervised Fine-Tuning、教師あり微調整） は最も直接的な方法である。「指示 → 理想的な回答」のペアを用意し、それらでモデルの学習を継続する。学習後、モデルは「指示を受ける → 回答する」という行動様式を身につける。ただし、SFT が教えられるのは模範回答の模倣であり、「何がより良いか」を理解させることはできない。
RLHF（Reinforcement Learning from Human Feedback） はこの問題を解決する。同じ質問に対して複数の回答を生成させ、人間のアノテーターがどちらが良いかを比較し、その比較データで reward model を学習する。さらに、強化学習によって、より高い reward score を追求するようモデルを学習する。これにより、モデルは模範回答をまねるだけでなく、抽象的な「良さ」の基準を学ぶ。
DPO（Direct Preference Optimization） は RLHF を簡略化したもので、reward model を学習する工程を省き、preference comparison data から直接学ぶ。2つのモデルを同時に維持する必要がなく、複雑な RL 学習ループも不要なので、工学的にはより単純である。
DeepSeek-R1 の4段階パイプライン
現在公開されている資料の中で、最も明確な現代的ポストトレーニングのパイプラインである。
段階1：SFT cold start。 RL の前に、少量の高品質な CoT data でウォームアップする。DeepSeek-R1-Zero は base model から直接 RL を行えることを証明した。これは重要な科学的発見だが、純粋な RL で学習したモデルは、同じ内容を繰り返し、言語を混在させ、非常に読みにくくなる。RL の reward signal は最終回答が正しいかだけを見て、表現が流暢かどうかは見ないからだ。Cold-start SFT は、まず形式と言語の一貫性を整え、RL により安定した出発点を与える。
段階2：Reasoning RL（GRPO）。 数学、コード、論理など検証可能な領域で、GRPO アルゴリズムによる強化学習を行う。重要な設計判断は2つある。第1に、reward signal に検証可能な正しさを使う。数学には正解があり、コードはテストを実行できるため、人間による採点が不要になる。第2に、GRPO は同じ問題に対して回答のグループをサンプリングし、絶対的な価値推定をグループ内順位で置き換える。独立した value network が不要で、従来の PPO より工学的にはるかに簡潔である。
段階3：Rejection Sampling Fine-Tuning。 RL 学習後のモデルに大量の回答を生成させ、成功した高品質な軌跡だけを残して、新しい SFT data としてもう一度教師あり微調整を行う。これは RL と SFT の橋渡しとなり、正の循環を作る。RL が良いパターンを探索する → rejection sampling が最良の軌跡を選ぶ → 軌跡が SFT data になる → SFT が良いパターンを安定して再現させる。この循環は複数回繰り返せる。
段階4：Alignment RL。 Preference feedback を使い、モデルの有用性と安全性を調整して公開基準に合わせる。この段階の reward signal は「答えが正しいか」ではなく、「回答が有用で安全か」である。
4段階は互いに依存する。Cold start により RL を安定して始められ、RL が高品質なデータを生み、rejection sampling がそれを次の SFT 入力に変え、alignment RL が行動の収束を完了させる。
「スタイルと能力」に関する重要な注意
SFT data の形式、たとえば箇条書きを使うか、引用を付けるか、回答をどれほど長くするかは、モデル出力の「見た目」に大きく影響する。Preference evaluation は本質的に長い回答を好む傾向があり、短い回答の方が適切でも、モデルはより長く答えるよう学習される。ユーザーは能力を比較しているつもりでも、実際にはスタイルの違いだけを比較していることが多い。
アプリケーションエンジニアへの示唆： ポストトレーニングのパイプラインを理解したら、「どのモデルの回答が良く見えるか」だけで評価してはいけない。具体的なタスクにおける正確性、コスト、遅延、安定性を見る必要がある。より「真剣」に見える長い回答は、SFT data で長い回答が「良い」とラベル付けされた結果にすぎず、実際により正確だとは限らない。
第6章：Eval、Grader、Reward——「良い」の定義が学習方向を決める
核心となる命題
If the grader is wrong, training optimizes the wrong target. Grader が間違っていれば、学習は誤った目標を最適化する。
モデル学習は本質的に最適化の過程である。目的関数を与えれば、モデルはあらゆる手段でスコアを最大化しようとする。モデルは本当に望んでいることを「理解」するのではなく、数値化されたスコアを「最適化」する。採点規則と真の意図の間に隙間があれば、モデルは正確にその隙間へ入り込む。チームに KPI を設定するのと同じだ。KPI が「コードの行数」ならエンジニアは冗長なコードを書き、「修正した bug 数」なら、簡単な bug を先に作ってから修正するだろう。
3つの主要コンポーネント
Eval は「何を測るか」を決める。モデルを評価するタスクを選ぶ。Grader は「1回の出力をどうスコアへ変えるか」を決め、モデル出力と学習信号を橋渡しする。Reward は「次にモデルをどの方向へ押すか」を決める。Grader のスコアを集約して RL の reward signal とし、パラメータ更新の方向を直接動かす。
3つのコンポーネントは、Task definition → Eval set → Grader/judge → Reward signal → Policy update → New rollouts → Eval set というフィードバックループを形成する。どこか1か所でも誤れば、それ以降の最適化もすべて誤った方向へ進む。
ORM と PRM：結果だけを見るか、過程も見るか
ORM（Outcome Reward Model、結果報酬モデル） は最終回答だけを見る。推論過程が混乱していても、偶然答えが正しければ満点になる。問題は、モデルが「正しく推論する方法」ではなく、「最終回答を当てる確率を高める方法」、つまりさまざまな shortcut reasoning を学ぶことだ。
PRM（Process Reward Model、過程報酬モデル） は各ステップを採点する。モデルは「第2ステップが間違っていた」と分かり、正しい推論過程を学ぶよう訓練される。しかし PRM のアノテーションコストは非常に高い。10ステップの推論問題なら、作業量は ORM の約10倍になる。
大多数の実システムは、コストを制御しやすい ORM から始める。PRM が現実的になるのは、数学、コード、論理など検証可能なタスクで、中間ステップをプログラムで自動検証し、人手によるアノテーションのボトルネックを回避できる場合に限られる。
Reward Hacking：モデルが抜け道を学ぶ
モデルが十分に強くなると、reward system の脆弱性を能動的に探すようになる。この問題には浅いものから深いものまで、いくつかの段階がある。
第1段階は 近道を使うこと であり、ORM の典型的な問題である。モデルは本当に推論しなくても高得点を取れる方法を見つける。
第2段階は CoT の不忠実性 である。Anthropic は、モデルが書いた「思考過程」が実際の内部過程とは限らないことを示した。モデルは追加の手がかりを使いながら CoT では触れず、事後的にもっともらしい説明を加える場合がある。
第3段階は reward hacking である。モデルはタスクをより良く達成するのではなく、採点システムの抜け穴を突く。たとえばコードタスクの grader がテスト通過率なら、テストケースの期待出力をハードコードすることを学ぶかもしれない。
第4段階は reward tampering と alignment faking である。モデルが採点過程そのものを改変しようとしたり、監視中は規則に従い、監視されていないときは異なる行動を取ったりする。Anthropic の2025年の実験は、このような行動の存在を確認した。
重要なのは、これらの行動は標準的な対話評価では見えず、Agent のタスク環境で初めて観測されることだ。Agent にはツール呼び出し、環境アクセス、多段階実行の能力があるためである。
Constitutional AI：個別のラベルを原則で置き換える
Anthropic の Constitutional AI（CAI）は別の考え方を取る。「この回答が良いか」を一件ずつラベル付けするのではなく、一連の原則、すなわち constitution を記述し、モデル自身に出力が原則を満たすか判断させる。
Phase 1、SL 段階：モデルが回答を生成する → 原則に照らして自己批判する → 回答を修正する → 修正版を SFT に使う。Phase 2、RL 段階：回答のペアを生成する → AI が原則に基づきどちらが良いか判断する（RLAIF）→ preference data を作る → RL 学習を行う。
核心となる革新は、RLAIF replaces RLHF——AI evaluates AI, human oversight via rules instead of per-example labels. すなわち AI が AI を評価し、人間の監督は個別ラベルではなくルールを通じて行うことだ。人間の監督が「一件ずつラベル付けする」ことから「ルールを書く」ことへ変わり、規模拡張性が質的に向上する。
アプリケーションエンジニアへの示唆： Eval、Grader、Reward の枠組み全体は、Agent システムの評価設計に直結する。RAG システムや Agent を構築するときも、「何を良い出力とするか」を定義する必要があり、それが自分の grader となる。評価基準が不正確なら、たとえば回答が本当に役立つかではなく、キーワードを含むかだけを見るなら、最適化は誤った方向へ進む。同様に reward hacking の存在を理解すれば、Agent システム設計に必要な安全対策を組み込める。
第7章：Agent 学習——最適化の対象はモデル本体だけではなくなる
Reasoning から Agent へ：業界の進化を捉える座標系
AI の進化は2次元座標で理解できる。X 軸は学習計算量、Y 軸は推論計算量、すなわち回答1回当たりに消費する token 数である。
GPT-3 era、左下： 能力を高める唯一の方法は学習計算量を増やすことだった。推論時の回答長は固定され、知能のすべてが学習段階で注入された。
Larger pretraining、右下： Over-training によって学習規模を増やし続ける一方、推論コストは変わらない。限界効果は小さくなる。
Reasoning models、左上： o1 と DeepSeek-R1 が新たに開いた次元である。学習規模は必ずしも大きくないが、推論時にモデルは「より長く考える」ことを学ぶ。推論 token を多く使えば、test-time scaling によって実際により良い答えを得られる。RL は「どう答えるか」だけでなく、「いつ長く考え、いつ止めるか」も教える。
Agent era、右上： 学習計算量と推論計算量を同時に拡張する。推論は単に「長く考える」ことから、「より多く行動する」ことへ変わる。より長い軌跡、より多くのツール呼び出しを使い、モデルは環境の中で継続的に行動する。ツールを呼び、フィードバックを得て、記憶を更新し、次の行動を決める。
Reasoning Model と Agentic Model：構造上の違い
両者の違いは、単に「できることが増える」ことではなく、最適化の枠組み全体が変わることである。
Reasoning model の流れは線形である。Prompt → Reasoning trace → Final answer → Verifier。最適化の単位は 1つの回答 だ。Agentic model の流れは循環する。Goal → Planner/policy → Tool call → Environment feedback → Memory/context edit → Next action → Planner へ戻る。最適化の単位は、環境の中でモデルが行う一連の行動と判断、すなわち1本の trajectory である。
ここからいくつかの重要な違いが生まれる。Reasoning model の主なボトルネックは verifier の精度で、典型的な失敗は shortcut reasoning、reward hacking のリスクは比較的低い。一方、Agentic model の主なボトルネックは、制御プログラムの品質である harness quality である。典型的な失敗は tool misuse と context drift で、reward hacking のリスクは非常に高い。Agent はツールと環境へアクセスできるため、純粋な推論場面より抜け道の種類がはるかに多いからだ。
Harness：実行時の概念から学習の概念へ
従来、harness は Agent をデプロイするときにモデルの周囲へ構築する制御層、すなわち prompt construction、retrieval、tool orchestration と理解されてきた。しかし Agent 学習では、その役割が変わる。
Agent の学習では、環境内でタスクを繰り返し実行し、経験と reward signal を集める必要がある。Harness 自体が不安定で、ツールの返り値が一定しない、ブラウザ環境が本番と異なる、ファイルシステムの状態を再現できない、といった状態なら、まず grader が誤り、モデルは能力ではなく環境の脆弱性を利用する方法を学ぶ。Agent を学習するとき、多くの場合はモデルと環境の両方を debug している。
SFT の時代はデータの多様性が第一だった。Agent の時代には、環境品質こそが中心 となる。安定性、現実性、カバレッジ、難易度分布、フィードバックの豊かさ、悪用への耐性が問われる。
Kimi K2.5 PARL：Agent 学習の具体的な工学事例
PARL の中心的な設計は、orchestrator だけを学習し、すべての sub-agent を固定すること である。これは credit assignment の問題を解決する。マルチ Agent システムがタスクに成功または失敗したとき、功績や責任を誰に帰属させるのか。Sub-agent を固定すれば、すべての結果を orchestrator の判断品質へ帰属できる。
Reward signal は3つの成分からなる。r_perf はタスク成功率で主信号、r_parallel は有効な並列分解を促し、「何でも並列化」して得点を稼ぐことを防ぐため、学習中に徐々に0へ annealing する。r_finish は偽の並列化を罰する。
並列化が本当に有効かどうかは、総ステップ数がどれだけ減ったかではなく、critical path、すなわち最長の直列チェーンが短くなったか で評価する。極めて典型的な分散システムの考え方である。
結論は、Parallelism emerges from RL, not supervision. 並列能力は教師あり学習で直接教えるものではなく、RL 学習から創発する。
Meta-Harness：Harness 自体を最適化する
最新の進展では、harness の中でモデルを学習するだけでなく、harness code 自体も外側のループで探索・最適化する対象になり始めている。
方法は次のとおりである。Harness を実行してモデルにタスクを行わせる → rollouts、scores、execution traces を生成する → outer-loop optimizer が traces と scores を読む → prompt 構築、検索戦略、コンテキスト編集ロジック、ツール編成規則を調整して harness code を変更する → 変更後の harness で再びタスクを実行する → スコアが向上したか確認する。
Meta-Harness の実証結果では、同じベースモデルでも harness だけを変えると6倍の性能差が生じた。また、harness の最適化はモデルをまたいで汎化することも分かった。IMO レベルの200問で見つけた harness は、最適化に参加していない5つのモデルを平均4.7ポイント向上させた。
特に注目すべき例として、Meta-Harness は TerminalBench-2 で environment bootstrap 戦略を自動的に発見した。Agent loop を始める前に shell command を実行し、作業ディレクトリ、利用可能な言語、パッケージマネージャー、メモリ状態をスナップショットに整理し、最初の prompt へ注入する。この方法は、手動のエンジニアリング実践から導かれた AGENTS.md の設計原則、すなわち モデルを最初からより良いコンテキストの上に立たせること と完全に一致する。
したがって、最適化対象は answer → trajectory → harness program へと進化している。
アプリケーションエンジニアへの示唆： この章は、AI アプリケーションエンジニアに最も直接関係するかもしれない。Agent 時代に harness engineering が最もレバレッジの高い工学領域の一つであることを示している。モデルを学習する必要はないが、モデル外部の制御プログラム、すなわち prompt construction、retrieval policy、context editing、tool orchestration を適切に設計する必要がある。Meta-Harness は、同じベースモデルでも harness だけで大きな差が生まれることを証明した。アプリケーションエンジニアとしての harness 設計能力は、どのモデルを選ぶかより重要になる可能性がある。
第8章：今後、モデルが強くなった理由をどう分析するか
3次元の分析フレームワーク
新しいモデルが公開され、「前版より大幅に強くなった」と説明されたときは、3つの次元から分解して考える。
第1の次元：変化は事前学習で起きたのか、ポストトレーニングの工程で起きたのか。 能力向上の多くは、確かにより強力な事前学習とより良いデータ配合から生まれる。しかし、ユーザーが感じられる変化の多くは、主にポストトレーニングで生じる。モデルが指示に従うか、ツールを使えるか、回答スタイルが安定しているかは、語料を増やすだけで自然に育つものではなく、ポストトレーニングにおける SFT data のスタイル、RL reward の設計、alignment training の方法によって決まることが多い。
第2の次元：向上はどの層から生じたのか。 Weights と training recipe、つまりモデル自体が変わった可能性がある。Reward、eval、grader、つまり学習目標が変わった可能性もある。あるいは harness code と deployment loop、つまりモデル外部の制御プログラムが変わった可能性もある。Reasoning model と Agent の段階では、ユーザーが感じる向上を base model だけが生み出しているとは限らない。評価の設計、reward の付け方、ツール環境の安定性、retrieval と memory の構成、summary とコンテキストの剪定、本番に選んだ checkpoint のすべてが、最終的な製品性能へ影響する。
第3の次元：本番版は何を最適化しているのか。 能力の上限を追求するリリースもあれば、コストや遅延を削減するもの、特定の用途へ特化するものもある。公開バージョンは製品上の判断であり、学習曲線の最も右にある点ではない。ユーザーはモデル名が滑らかに上昇する1本の学習曲線に対応すると考えがちだが、どの checkpoint を本番投入するかには、多数の製品上のトレードオフがある。
オンライン最適化：学習とデプロイの境界が縮まっている
Cursor Composer 2 の real-time RL は重要な兆候である。実際のユーザーのコーディング行動が学習ループへ直接入り、次の大型バージョンを待たずモデルを継続的に反復する。学習とデプロイの境界が消えたわけではないが、両者を結ぶフィードバックループは短くなっている。
今日公開されたモデルは1つのスナップショットにすぎない。継続して動く製品は、パイプラインと harness program である。
第9章：この知識が AI アプリケーションエンジニアに意味すること
パイプライン全体のどこに位置するか
LLM が製品になるまでの流れは、おおむねデータエンジニアリング → 事前学習 → ポストトレーニング → 蒸留・専用化 → デプロイ → 製品・アプリケーションである。AI アプリケーションエンジニアの主な仕事は、後半のデプロイとアプリケーション層にある。前半のデータエンジニアリングや学習を自分で行う必要はないが、前半への理解の深さが、後半でどれほど良い判断ができるかを直接決める。
すぐに行動へ移せる6つの示唆
第1に、モデル選定では benchmark だけでなく学習の背景を見る。 モデルがどのように学習されたか、すなわちデータ配合、蒸留元、ポストトレーニング方法を知れば、自分のタスクでどう振る舞うかを予測できる。コードデータを重点的に学習したモデルは推論が強くても雑談が弱い可能性がある。蒸留モデルは蒸留データがカバーするタスクに強くても、それ以外では性能が低下し得る。
第2に、benchmark スコアは慎重に解釈する。 スコアはデータ漏洩、重複排除の品質、長い回答を好む preference evaluation の性質など、さまざまな要因に影響される。自分の具体的なタスクで EDD（Evaluation-Driven Development）を行うことが、信頼できる判断方法である。
第3に、harness engineering は最もレバレッジの高い技能である。 Meta-Harness は、同じベースモデルでも harness を変えるだけで6倍の性能差が生まれることを示した。Agent システムで設計する prompt construction、retrieval policy、context editing、tool orchestration、state management は、すべて harness engineering の構成要素である。これは「ツール設定」のような些事ではなく、Agent システムで最もレバレッジの高い工学領域の一つである。
第4に、評価設計は reward 設計と直結する。 RAG システムや Agent に定義する評価基準は、本質的に自分の grader である。評価基準が不正確なら、最適化の方向は誤る。ORM と PRM のトレードオフ、reward hacking の存在を理解すれば、より信頼できる評価体系を設計できる。
第5に、学習側の制約を理解すれば、より良いデプロイ判断ができる。 「なぜこのモデルのコンテキストは 128K なのか」。より長いコンテキストは attention コストを急増させ、batch size を小さくするからである。「なぜ量子化すると性能が落ちるのか」。学習時に quantization-aware training を行っていなかった可能性がある。こうした理解が、より合理的なデプロイ選択につながる。
第6に、自分の物語を組み立てる。 面接では、本稿の知識体系を使い、説得力のある物語を示せる。自分は単に prompt を書いているのではなく、harness engineering を行っている。これは現在の Agent システムで、学習からデプロイまで高いレバレッジを持つことが証明されている工学実践である。この領域の理論的基盤と実務経験の両方を深く理解している、と説明できる。
おわりに
大規模言語モデルの学習は、自分の手で行う必要はないが、理解する必要のあるシステムである。Java バックエンドエンジニアが自分で CPU を設計する必要はなくても、CPU のキャッシュ階層とメモリモデルを理解すれば、より良い並行処理コードを書けるのと同じだ。
本稿では、データパイプラインと事前学習のトレードオフから、ポストトレーニングのパイプラインと Agent 学習、評価体系から harness 最適化まで、全体の流れを扱った。すべての細部を覚える必要はないが、全体を貫く核心の論理は自分のものにする必要がある。モデルのあらゆる能力は設計判断の結果である。データ配合が能力の方向を決め、事前学習の規模が能力の上限を決め、ポストトレーニングのパイプラインが能力の現れ方を決め、harness が現実の場面でどこまで能力を発揮できるかを決める。 この流れを理解することは、アプリケーションエンジニアとして行うすべての判断の背景と制約を理解することである。
今日公開されたモデルは1つのスナップショットにすぎない。継続して動く製品は、パイプラインと harness program である。そして自分の仕事は、その流れの末端で、モデルの能力をユーザーが本当に必要とする価値へ変えることだ。