メインコンテンツへスキップ

7.2.4 大規模モデル産業の構造

LLM 産業構造のレイヤーマップ

図の読み方

1つの建物として見てください。モデル層は「エンジン」を提供し、プラットフォーム層はそのエンジンを呼び出しやすく、監視しやすく、運用しやすくします。アプリ層は、その能力をユーザー向けのワークフローに変えます。オープンソースとクローズド API は「どちらが絶対に良いか」ではなく、制御性、コスト、遅延、プライバシー、運用負荷のトレードオフです。

学習目標​

この節を終えると、あなたは次のことができるようになります。

  • 産業チェーンの視点から大規模モデルのエコシステムを理解する
  • モデル層、プラットフォーム層、アプリケーション層がそれぞれ何をしているかを区別する
  • オープンソースとクローズドソースの違う強みを理解する
  • 小さな例でモデル選定の考え方を練習する

一、まず産業チェーンを分けて見てみよう​

モデル層：誰が「エンジン」を作っているのか？​

モデル層は、主に基盤モデルと汎用モデルの学習を担当します。
これは「エンジンを作る人」と考えるとわかりやすいです。

この層で主に重視されるのは次のような点です。

  • モデルアーキテクチャ
  • 学習データ
  • 学習計算資源
  • モデル性能

一般的な形としては、次のようなものがあります。

  • クローズドソースの API モデル
  • オープンソースでダウンロード可能なモデル
  • 業界特化モデル

プラットフォーム層：誰がモデルを使いやすくしているのか？​

プラットフォーム層は、「道を整備し、電気を供給する人」のような役割です。

ここでよく行われることには次のようなものがあります。

  • モデルホスティング
  • 推論サービス
  • ベクトルデータベース
  • 監視と評価
  • 微調整プラットフォーム
  • Agent / workflow 開発フレームワーク

プラットフォーム層がなければ、多くのチームはモデルを手に入れても、安定して実運用に乗せるのが難しくなります。

初学者向け用語メモ：プラットフォーム層でよく出る言葉​

用語意味なぜ重要か
APIモデルやサービスを呼び出すための標準インターフェースアプリがモデル内部を管理せずに結果を取得できる
推論モデルを実行して出力を得ることユーザーが質問するたびに、裏側でよく行われる処理
ベクトルデータベースembedding を保存し、近いものを検索しやすくしたデータベースRAG システムの検索層としてよく使われる
監視遅延、エラー、コスト、出力品質を継続的に見ること本番環境で問題を早く見つけるために必要
評価出力がタスク要件を満たしているか測ること感覚だけでモデルの良し悪しを判断しないために必要

二、アプリケーション層：本当にユーザーの近くにある​

アプリケーション層が売っているのはモデルではなく、結果​

アプリケーション層は「レストランを開く人」に近いです。

ユーザーは、どの注意機構を使っているかはあまり気にしません。気にするのは次のような点です。

  • 仕事をちゃんと手伝ってくれるか
  • 回答が信頼できるか
  • 十分に速いか
  • コストを受け入れられるか

代表的なアプリケーションには次のようなものがあります。

  • AI 検索
  • AI カスタマーサポート
  • AI プログラミングアシスタント
  • AI オフィスツール
  • AI 学習支援アシスタント

同じモデルでも、いろいろな製品に変わる​

同じ基盤モデルでも、チームが違えばまったく別の製品になることがあります。

  • 法務アシスタント
  • 営業アシスタント
  • 教育支援アシスタント
  • コードレビューツール

これは、産業競争が「モデルがどれだけ大きいか」だけで起きているわけではなく、次のような点でも起きていることを示しています。

  • ワークフロー設計
  • データ蓄積
  • 製品体験
  • 業界知識

三、オープンソース路線とクローズドソース路線、どう選ぶ？​

クローズドソースモデルは「すぐ使える成熟したエンジン」に近い​

メリットは一般的に次の通りです。

  • すぐに使ってよい効果が出やすい
  • モデルの保守作業が少ない
  • リリースまでが速い

代わりに、デメリットとしては次のような点があります。

  • 利用ごとに課金される
  • 制御しにくい
  • プライベート環境への導入が制限される

オープンソースモデルは「自分で改造できるエンジン」に近い​

メリットは一般的に次の通りです。

  • 自分でデプロイできる
  • 微調整できる
  • データと推論の流れをより細かく管理できる

代わりに、デメリットとしては次のような点があります。

  • デプロイと保守がより複雑
  • そのままで必ずしも最強の性能ではない
  • より高いエンジニアリング力が必要

一言で覚えるなら、

クローズドソースは手軽さ重視、オープンソースは制御性重視。

四、多くのチームが本当に競っているのは「システム能力」​

モデルはシステムの中の一部にすぎない​

実際の大規模モデル製品は、多くの場合「モデルだけが頑張る」のではなく、システム全体で協力しています。

  • Prompt
  • RAG
  • ツール呼び出し
  • 評価体系
  • 安全対策
  • コスト管理

つまり、次のように考えられます。

ユーザー体験 = モデル性能 × システム設計 × データ品質

なぜ同じモデルでも、製品によって体験が大きく違うのか？​

体験を左右するのは、モデル性能だけではないからです。たとえば次のような要素も重要です。

  • ナレッジベースが良いか
  • ツールが正確に動くか
  • 失敗時のフォールバックがあるか
  • レイテンシーがうまく抑えられているか

これが、「API を使える」ことと「AI 製品を作れる」ことは同じではない理由です。

五、実践的なモデル選定フレームワーク​

まず「誰が最強か」ではなく、「何が必要か」を考える​

よく使う選定の観点には次のようなものがあります。

観点確認したいこと
品質タスクの結果は十分に良いか？
コスト1回あたりの呼び出し料金は高くないか？
レイテンシーユーザーは応答速度を受け入れられるか？
制御性プライベート導入、微調整、監査はできるか？
マルチモーダル画像や音声を見る必要があるか？
ツール能力function calling / agent が必要か？

小さなスコアリングスクリプト​

次の例は、実在する最新モデルを選ぶためのものではなく、「要件に合わせてどう評価するか」を練習するためのものです。

models = {
    "cloud_api_model": {
        "quality": 9,
        "cost": 4,
        "latency": 8,
        "control": 4
    },
    "open_source_8b": {
        "quality": 6,
        "cost": 9,
        "latency": 7,
        "control": 9
    },
    "open_source_70b": {
        "quality": 8,
        "cost": 5,
        "latency": 5,
        "control": 9
    }
}

weights = {
    "quality": 0.4,
    "cost": 0.2,
    "latency": 0.2,
    "control": 0.2
}

def score_model(info, weights):
    return sum(info[k] * weights[k] for k in weights)

scores = []
for name, info in models.items():
    scores.append((score_model(info, weights), name))

for score, name in sorted(scores, reverse=True):
    print(name, "->", round(score, 2))

期待される出力：

open_source_8b -> 7.4
open_source_70b -> 7.0
cloud_api_model -> 6.8

モデル選定スコアの実行結果図

weights を変えることで、会社ごとの重視点の違いを再現できます。

六、なぜ「産業構造」がエンジニアにも重要なのか？​

毎日、技術選定をしているから​

あなたは次のような問題に何度も出会うことになります。

  • API を使うか、自前でデプロイするか？
  • まず RAG を作るか、先に微調整するか？
  • 汎用モデルを使うか、垂直特化モデルを使うか？
  • 単一モデルにするか、複数モデルのルーティングにするか？

これらの問題は、根本的にはすべて産業構造と関係しています。

技術路線はキャリアパスにも影響するから​

職種によって、重視する能力は少しずつ違います。

  • 基盤モデル：学習とアルゴリズム寄り
  • プラットフォームエンジニアリング：推論、デプロイ、最適化寄り
  • アプリケーションエンジニアリング：プロダクト、ワークフロー、評価寄り

産業構造を知ることで、自分がどの分野に進みたいかをよりはっきり考えられます。

七、初学者がよくする誤解​

ランキングだけを見る​

ランキングには価値がありますが、それだけがすべてではありません。
実際のプロジェクトでは、コスト、レイテンシー、安定性も同じくらい重要です。

「オープンソースなら必ず安い」と思う​

モデル自体がオープンソースでも、学習、デプロイ、保守まで安いとは限りません。

「最良のモデル」が常にあると思う​

多くの場合、「絶対に最良のモデル」はありません。あるのは「今の場面に最も合うモデル」だけです。

まとめ​

この節で最も大切な理解は次の通りです。

大規模モデル産業は、モデルのパラメータ数だけで競っているのではなく、モデル、プラットフォーム、データ、製品、エンジニアリング能力の組み合わせで競っている。

アプリケーションを作る人が産業構造を理解するのは、流行を追うためではなく、より安定した技術的・製品的判断をするためです。

練習​

  1. スコアリングスクリプトの重みを変更して、「スタートアップチーム」と「金融企業」の選定傾向をそれぞれ再現してみましょう。
  2. 考えてみましょう：もしあなたのプロジェクトがプライベートデプロイを必要とするなら、オープンソース路線とクローズドソース路線の優先順位はどう変わるでしょうか？
  3. 自分の言葉で説明してみましょう：なぜ多くの場合、真の競争優位はモデル本体だけではないのでしょうか？