なぜLLMのファインチューニングは失敗するのか？巨大テックの数千億モデル開発に消耗戦を挑むな

対象読者: 自前モデル開発や無理なファインチューニングに予算と時間を溶かし、ハイパースケーラーのアップデート一撃で陳腐化することに危機感を抱いているエンジニア・CTO・研究者 難易度: 初級〜中級 テーマ: 特化AIのための代替アーキテクチャ（ドメイン特化データ × ハーネス）

:::message この記事の要点 (TL;DR)

課題: 「自前でファインチューニングして特化モデルを作ろう」とすると、精度が出ない・コストが見合わない・次のモデル更新で陳腐化する、という3重苦に陥る。
原因: LLMの知能はすでにPCのOS並みの設備投資ゲームであり、中途半端な規模のコストで挑んでも「知能の差」で負ける構造になっている。
解決策: モデルを弄るのをやめる。ドメイン特化データ（高品質データ）をDuckDB/Parquetに蓄積し、汎用LLMを制御するハーネスを外側に組む。この2つは時代が変わっても価値が目減りしない。 :::

1. はじめに：多くの人が「モデルのファインチューニング」に手を出して失敗する

「LLMで〇〇を実現しよう」と考えたとき、多くの人が最初に取る選択肢は2つです。

自前データで ファインチューニング（FT） しよう
とりあえず RAG を繋いでみよう

どちらも正しい方向性の「断片」ではありますが、そのまま実行すると高い確率で失敗します。そして失敗の理由を「プロンプトの工夫が足りない」「データが少ない」と誤診し、さらに多くの時間を溶かしていく。

この記事では、実際に長編小説生成と専門文書解析のためにプレトレーニングとFTに挑み、 VRAMとコンテキスト長の物理限界を肌で痛感し、最終的に**「モデルを弄るのを完全にやめる」**という結論に至った経緯を共有します。

そして、その先に何があるのか——AIモデルではなく、特化データ（高品質データ）とハーネスが優先という選択肢を、具体的なアーキテクチャと一緒に提示します。

2. 実体験に基づく壁の解剖：なぜFTは失敗するのか

2.1 物理的限界——VRAMとコンテキスト長

特化モデルを作ろうとすると、まず壁になるのは物理リソースです。

VRAMの壁: 意味のあるFTをしようとすると、コンシューマGPUでは即座に限界に達する。マルチGPU構成にすると、今度は投資対効果が成立しなくなる。
コンテキスト長の壁: 長文（長編小説、契約書、論文）を扱うほど、モデルが「文脈の外」を推定する必要が出る。FTで「知識」を盛れても、文脈的一貫性は別問題である。

私自身、長編小論生成においてこの2つの壁に正面から衝突しました。設定の整合性を保とうとしてFTを試みましたが、VRAM内で収まるサイズに縮めた瞬間に「知能の質」が落ち、かといって大きくすると投資対効果が崩壊する——堂々巡りです。

2.2 もっと深刻な問題——モデル更新による陳腐化

しかし物理的限界は、まだマシな方です。

本当に致命的なのは、ハイパースケーラーが次世代フロンティアモデルを出した瞬間に、あなたの特化モデルが「知能の差」で一撃で陳腐化するという構造です。

数ヶ月かけて中途半端なコストでFTした特化モデルは、巨大テックが数千億円を投じて出してくるモデルと比較すると、知能そのものが劣る。汎用モデルの方が賢くなった時点で、あなたの「特化モデル」は意味を失います。

これは技術力の問題ではなく、資本力の絶対差です。弱小な部隊が、巨大な火力の前に同じ土俵で消耗戦を挑むようなものですか？

2.3 なぜこの構造に気づかないのか

多くの人がこの構造に気づかないのは、「自前モデルを作る」こと自体が、エンジニアとしての威信や、技術的な所有感と結びついているからです。

「うちだけの特化モデル」という言葉の響きは魅力的です。しかし、その所有感は、あなたの会社のビジネス価値を高めているでしょうか？ それとも、単に陳腐化していく負債を積み上げているだけでしょうか。

3. 解決策① —— ドメイン特化データの構築

モデルを弄るのをやめた私が最初に取り組んだのは、**ドメイン特化データ（高品質データ）**の蓄積です。

3.1 なぜ「データ」が本体なのか

LLMの知能は交換可能な部品です。しかし、あなたの事業領域に最適化された、クリーンな一次情報は、どこかのベンダーが提供してくれるものではありません。

論文のLaTeXと数式（strata）
法定開示に基づく財務数値（finance）
小説の設定図と世界観辞書（Story_creator）

これらはあなたにしか作れない資産です。そして、このクリーンなデータがあれば、汎用モデルをRAGによって即座に特化させられます。さらに、将来もしFTが必要になったとしても、きれいな種データがあればいつでも実行できます。

3.2 データパイプラインの現実的な設計

ここで重要なのは、スケールを夢見ないことです。

❌ 世間がやりがちな失敗: PostgreSQLクラスタ + FastAPI中継サーバー8個 + 外販SaaS機能
✅ 現実的な解:          DuckDB / Parquet に「正しい特化データを冪等に積む」

私は strata（arXiv 15.7万本のLaTeX・数式抽出）と finance（SEC EDGAR / EDINET 正規化財務データ）で、 **「正しい特化データを単一ファイルのデータレイクに冪当に積む」**という単一責務に絞りました。 Web外販をしないフェーズにおいて、PostgreSQLサーバーやAPI層を排することで、「データを正しく積む」という本質的な作業に集中できました。

4. 解決策② —— ハーネス設計（責務分離と監査ゲート）

データだけでは不十分です。汎用LLMは暴走します。ハルシネーションを吐き、文脈を破綻させます。

そこで必要なのが、ハーネス（制御・実行システム）——巨人の暴れ馬を手綱で縛る外側の設計です。

4.1 生成と監査の責務を分離する

私のアプローチは、「生成プロセス」と「監査ゲート」を明確に分離することです。

[生成層] 汎用LLM  ── 自由に生成させる（創造性を殺さない）
    │
    ▼
[監査層] 決定論的ゲート ── 設定図・辞書と照合し、矛盾を遮断
    │
    ▼
[トリアージ] 多層的最適化 ── 許容範囲か、修正要求か、再生成かを決定

Story_creator では、この監査を決定論的に行っています。 Python標準ライブラリ（difflib, re, dataclasses, frozenset）とIPA辞書データを使い、文脈や設定との照合を多層的に検証します。確率的な生成物を、決定論的なルールで遮断する——この責務分離こそが、破綻しない長編生成を可能にしています。

4.2 通信もハーネスで守る

生成とは別に、通信のレイヤーもハーネス化が必要です。

resilient-llm では、外部Redisやプロキシを排し、単一プロセス内で 429レート制限・複数キースロット・TTFTを監視する薄いインメモリ層を提供しています。 LiteLLMとInstructorの肩に乗り、**「429レスポンスからの自己学習型台帳（RateLimitLedger）」**と「複数キースロット回転・5xx隔離」のみを自作しました。

ポイントは、**「どのモデル（Claude, Gemini, OpenAI）に知能を差し替えても、夜間バッチを絶対に途中で落とさない」**ということです。知能は交換可能なOSとして扱い、通信防壁だけは自分で持ち、かつ薄く保つ。

4.3 開発すらハーネス化する

CLI_Subagents は、Claude CodeからKiroやOpenCodeを安全に従属・並行実行させるハーネスです。重いコンテナやtmux（Linux依存）を排し、標準 git worktree とファイルベース状態管理で完結させ、 **「OpenCode非対話ハング回避」「Kiro予算残量遮断」「.git 指紋照合」**というコアロジックに集中しました。

5. 結論：AIを作るな。ハーネスとドメイン特化データを作れ

ここまで読んでいただければ、結論は明確です。

巨大テックが数千億円を投じるAIモデル開発に、中途半端な規模のコストで消耗戦を挑むのは愚策である。

LLMの知能は、PCのOS並みに設備投資の参入障壁が高い巨大資本のゲームです。数ヶ月かけて中途半端なコストでFTした特化モデルは、次世代フロンティアモデルが出た瞬間に、知能の差で一撃で陳腐化します。

だからこそ、LLMの知能は「いつでも交換可能なOS（コモディティ）」として割り切り、巨人の肩に乗るのが合理的な戦略です。

そして、時代が変わっても絶対に価値が目減りしない、私たちが手元に積み上げるべき永続資産は2つしかありません。

ドメイン特化データ（高品質データ） RAGの燃料となり、必要に応じてファインチューニングの種となる、自前のクリーンな一次情報資産。
ハーネス（制御・実行システム） 巨人の暴れ馬（汎用LLM）を手綱で縛り、ハルシネーションや429エラーを防いで目的を完走させる外側の設計。

AIモデルを追うな。自前で無理にモデルを作るな。 ハイパースケーラーの知能を最大限に活かし、知能はいつでも交換可能にしておけ。 そして、自分だけの「ドメイン特化データ」と「ハーネス」を構築せよ。

6. 次に読むべきもの

Manifesto — 旗印の全文と2つの永続資産
Architecture Showcase — 各プロジェクトがどうデータを蓄積し、どうハーネスを組んだか
小説特化LLMのプリトレを断念した話 — 整合性監査ゲートの実装
「とりあえずRAG」が失敗する本当の理由 — 特化データパイプライン設計

なぜLLMのファインチューニングは失敗するのか？巨大テックの数千億モデル開発に消耗戦を挑むな — AIを作るな。ハーネスとドメイン特化データを作れ