行政の補助金公募資料やベンダーからの提案書で『基盤モデル』という言葉を見かけて、これがLLMと同じものなのか判断がつかず、上司への説明に困っていませんか。
生成AIの実用化が進んだこの数年で、テキストだけでなく画像や音声まで扱うモデルが増え、『言語モデル』という呼び方だけでは説明しきれない技術が『基盤モデル』という言葉でまとめて語られるようになりました。
この記事では、業務自動化の構築設計で使っている確認の観点をもとに、基盤モデルという言葉が生まれた経緯とLLM・生成AIとの関係、そして提案書でこの語に出会ったときに確認すべき3つの基準を整理しています。
基盤モデルとは何か
基盤モデルとは、大量かつ多様なデータで事前学習され、特定の一つの用途に絞らずに幅広いタスクへ応用できるAIモデルを指します。
この呼び方は単体の製品名ではなく、GPT-4oやGeminiのようなモデルを『事前学習された汎用的な土台』として扱うときに使う分類名です。
この語はもともと存在せず、2021年にスタンフォード大学の研究機関が新しく提唱した学術用語という出自を持ちます。
というのも、従来の『言語モデル』『事前学習モデル』という呼び方では説明しきれなくなった変化があったためです。
まず定義の中身を分解し、そのうえでなぜこの語が必要になったかの経緯を確認します。
定義：大量データで事前学習した汎用AIモデル
基盤モデルの定義は、大量かつ多様なデータで事前学習されていること、特定のタスクに限定せず汎用的に使えること、追加の学習によって個別の用途に転用できること、の3点に整理できます。
たとえばOpenAIのGPT-4oは、文章生成だけでなく画像や音声の理解にも対応しており、単一のモデルが複数の入力形式を扱う点が基盤モデルの典型例です。
一方で、特定の業務のためだけに設計された小規模な分類モデル、たとえば迷惑メール判定に特化したモデルは、汎用性を前提としていないため基盤モデルには含まれません。
なぜこの言葉が生まれたか（2021年・スタンフォード大学HAI）
基盤モデルという用語は、2021年にスタンフォード大学の人間中心AI研究所（HAI：Human-Centered AI Institute、人間中心の人工知能研究を行う機関）が発表した論文で初めて定義されました。
それ以前は同種のモデルを『事前学習モデル』や『言語モデル』と呼ぶ例が目立ちました。
ただ、テキストだけでなく画像・音声・コードまで扱うモデルが増え、『言語』という語では実態を表せなくなったことが背景にあります。
実際にこの時期の後、画像生成のStable Diffusionのように言語以外のデータを扱うモデルが相次いで登場しており、テキスト・画像・音声といったデータの種類（モダリティ）をまたぐ総称が必要になった流れと重なります。
この経緯を知っておくと、行政資料やベンダー提案で『基盤モデル』と書かれていた場合に、テキスト生成に限らない技術を指している可能性があると読み取れます。
出典： Stanford HAI「On the Opportunities and Risks of Foundation Models」
基盤モデル・LLM・生成AIはどう関係しているか
3語の関係は、生成AIが最も広い概念で、その内側に基盤モデルが位置し、さらにその内側にLLMが含まれる、という包含関係で整理できます。
生成AI（Generative AI：新しいコンテンツを生成するAI技術の総称）は、文章・画像・音声など出力形式を問わず新しいものを作り出すAI全般を指す、最も広いカテゴリです。
基盤モデルは、その生成AIを実現するための土台となる技術で、汎用性の高い事前学習済みモデルという位置づけです。
そしてLLM（Large Language Model：大規模言語モデル）は、基盤モデルのうちテキストの理解と生成に特化したものを指すため、3語は入れ子構造の関係にあります。
この関係を表で確認したうえで、実際のサービス名がどこに位置づけられるかを見ます。
3語の包含関係
3語の関係を整理すると、次の表のとおりです。
| 用語 | 扱う範囲 | 代表例 |
|---|---|---|
| 生成AI | テキスト・画像・音声・動画など新しいコンテンツを生成するAI技術全般 | ChatGPT、Midjourney |
| 基盤モデル | 生成AIを実現する、大量データで事前学習された汎用モデル | GPT-4o、Gemini、Stable Diffusion |
| LLM | 基盤モデルのうちテキストの理解・生成に特化したもの | GPT-4、Claude、Llama |
表からわかる通り、生成AIという広い分類の中に基盤モデルがあり、そのうちテキストに特化したものだけがLLMと呼ばれます。
逆にいえば、画像を生成するStable DiffusionはLLMではありませんが、大量データで事前学習された汎用モデルという意味では基盤モデルに含まれます。
この整理を知らないと、提案書で『基盤モデル』と『LLM』が混在して出てきたときに、同じものを指しているのか範囲が違うのかを判断できません。
具体例で見る位置づけ
位置づけを具体的なサービス名で確認します。
文章生成に使われるGPT-4やClaude、Geminiは、テキストに特化した基盤モデルであるため『LLM』にも『基盤モデル』にも該当します。
一方、画像生成のStable DiffusionやMidjourneyは、テキストではなく画像を扱うため『基盤モデル』ではあっても『LLM』には該当しません。
行政資料や提案書で『生成AI』とだけ書かれている場合は、テキスト生成に限らず画像・音声を含む可能性があるため、具体的にどのモダリティを指しているかを別途確認する必要があります。
LLMと生成AIの包含関係は、次の記事でさらに詳しく整理しています。
行政資料やベンダー提案で基盤モデルと書かれていたら何を確認するか
提案書や行政資料で『基盤モデル』という語を見たときは、扱うモダリティ、汎用のまま使うか追加学習前提か、運用と責任の所在、の3点を確認すれば実務上の判断ができます。
この3つの基準は、提案の中身をそのまま鵜呑みにせず自社の用途に当てはまるかを判断するための最低限のチェックポイントです。
基盤モデルという言葉自体は技術の分類名であり、それだけでは自社の業務にどう役立つかは何もわかりません。
提案書に『基盤モデルを活用した～』とだけ書かれている場合、範囲が曖昧なまま話が進むことがあるため、この3点で具体化を求めるのが実務上の対処になります。
それぞれの基準を1つずつ確認します。
確認基準1：どのモダリティを扱うモデルか
1つ目の基準は、提案されている基盤モデルがテキストだけを扱うのか、画像・音声・動画も含むのかを確認することです。
議事録の要約や問い合わせ対応の自動化であればテキスト特化のLLMで足りますが、図面の検査や音声の文字起こしを含む提案であれば、画像認識・音声認識に対応した基盤モデルが必要になります。
モダリティの確認を怠ると、テキスト特化のLLMを想定して契約したのに画像処理が別料金・別契約だったというすれ違いが起きやすく、この確認を提案段階で済ませておくと後工程での契約変更を避けられます。
画像や音声を扱うマルチモーダルAIの仕組みは、次の記事で整理しています。
確認基準2：汎用のまま使うのか、追加学習前提か
2つ目の基準は、提案されているモデルを汎用のまま使うのか、自社データで追加学習した上で使うのかを確認することです。
汎用のまま使う場合は導入までの期間が短く費用も抑えやすい一方、社内特有の用語や過去の判断基準を反映させるには限界があります。
追加学習を前提にした提案であれば、学習に使うデータの準備・精度検証にかかる期間と費用が別途発生するため、提案書の見積もりにこの工程が含まれているかを確認する必要があります。
社内文書の分類のように業界特有の言い回しが多い業務ほど、汎用のままでは精度が不足しやすい場面です。
確認基準3：運用と責任の所在はどこにあるか
3つ目の基準は、導入後にモデルの出力が誤っていた場合の確認・修正を誰が担うのかを確認することです。
基盤モデルは汎用的であるがゆえに特定の業務向けに完全調整されているわけではなく、誤った出力が発生する前提で運用設計を組む必要があります。
提案書に運用体制の記載がない場合、出力チェックの工程が社内の担当者に丸投げされる形になりやすく、稼働後の負担を事前に見積もっておくことが実務上の判断材料になります。
特に人事評価や与信判断など誤りが業務上の損失に直結する用途では、人による最終確認の工程を提案に含めるよう求めるのが妥当です。
自社の提案書をこの3つの基準で整理してみて判断に迷う場合は、 個別相談 で一緒に確認することもできます。
基盤モデルの適用範囲はどこまで広がっているか
基盤モデルの適用範囲は、当初のテキスト生成から画像・音声・コード・行動計画まで広がっており、企業活用の場面も日常業務からシステム開発まで拡大しています。
登場当初の基盤モデルはテキスト生成が中心でしたが、現在は画像・音声・動画・プログラムコードを扱うモデルまで含む総称として使われています。
適用範囲が広がった背景には、同じ事前学習の手法を画像や音声のデータにも応用できることが実証されてきた経緯があります。
ただし適用範囲が広いことは、あらゆる業務に向くことを意味せず、向かない場面も存在します。
広がりの実態と向かない場面の両方を確認します。
テキスト以外への広がり
テキスト以外への広がりの代表例が、画像生成のStable Diffusionや、音声認識・音声合成に使われるモデルです。
企業活用の場面では、コールセンターの音声を自動でテキスト化して要約する、設計図面の画像から不具合箇所を検出する、といった用途に基盤モデルが使われ始めています。
こうした用途ではテキストに特化したLLM単体では対応できないため、画像・音声を扱う基盤モデルを組み合わせるか、複数モデルを連携させる構成が必要になります。
基盤モデルが向かない場面
基盤モデルが向かない場面としては、判断基準が法令や社内規定で厳密に固定されている業務が挙げられます。
たとえば税額の計算や資格要件の判定のように答えが一意に決まる処理は、確率的に出力を生成する基盤モデルより、従来型のルールベースの計算処理の方が適しています。
また学習データに含まれない社内固有の最新情報、たとえば当日の在庫数や当日の人事異動をそのまま正確に答えることも基盤モデルの得意分野ではありません。
社内システムとの連携なしに使うと、誤った回答をそのまま提示してしまう場合があります。
基盤モデルという言葉の整理はついても、自社の提案書がどこに当てはまるのか判断に迷っていませんか。
「提案書のどの部分が基盤モデルの話で、どこからが自社向けの追加開発なのか切り分けられない」「汎用モデルのままで自社の業務精度が足りるのか判断できない」「社内に提案内容の妥当性を判断できる人材がいない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、AI業務自動化に関するお悩みをお伺いする 無料の個別相談 を実施しています。
よくある質問
Q. 基盤モデルとLLMは同じ意味で使っても問題ありませんか？
テキストの話に限定するなら混同しても実務上の支障は小さいですが、画像や音声を含む提案の場合は区別が必要です。
提案書が『基盤モデル』という語を使っている場合、テキスト以外のモダリティを含んでいる可能性があるため、契約範囲を確認する材料として区別しておくと後工程での認識違いを防げます。
Q. 提案書に「生成AI」とだけ書かれていて「基盤モデル」という語が出てこない場合はどうすればいいですか？
生成AIは基盤モデルより広い概念のため、具体的にどの基盤モデルを使っているかを別途確認する必要があります。
ベンダーに『使用しているモデル名』を尋ねれば、テキスト特化なのか画像・音声も含むのかが明確になり、料金体系や運用範囲の確認にもつながります。
Q. 基盤モデルを使うには必ず追加学習が必要ですか？
必須ではありません。
汎用のまま使える業務も多く、たとえば一般的な問い合わせ対応や文書要約であれば、追加学習なしのモデルで十分対応できる場合があります。
社内固有の用語や過去の判断基準を反映させたい場合に限り、追加学習の必要性を検討する流れになります。
Q. 中小企業でも基盤モデルを使ったシステムを導入できますか？
可能です。
多くのベンダーが基盤モデルをAPI経由で提供しており、自社でモデルを一から開発する必要はなく、既存のクラウドサービスに組み込む形で導入するケースが一般的です。
導入規模に応じて、汎用モデルをそのまま使う小規模な構成から始めれば、初期費用を抑えて始められます。
Q. 基盤モデルの安全性やセキュリティはどう確認すればいいですか？
提案書の運用体制の項目で、入力データの保存先と、学習データへの再利用の有無を確認するのが実務上の第一歩です。
入力した社内文書がモデルの再学習に使われる契約になっていないか、データの保存場所が国内か海外かといった点は、契約前にベンダーへ直接確認しておく必要があります。
クラウドに出せないデータを扱う場合の選択肢は、次の記事で整理しています。
