生成AIを支える基盤モデルとは？｜上に載るAIが受け継ぐもの

「社内のチャットAIと資料検索のAIが、同じ時期から同じように古い情報を答えるようになった」「『自社専用AI』と言われて導入したが、中身が何なのか社内で説明できない」。AI導入の担当者や情報システム部門から、こうした声を聞く機会が増えています。手がかりになるのが、総務省と経済産業省が出している「AI事業者ガイドライン」です。2026年3月31日の第1.2版は、基盤モデルを「様々なサービスを支える個別モデルを生み出すコアの技術基盤」と位置づけています。基盤モデルは、数あるAI製品のうちの1つではありません。本当は、社内で別々に見えるAIの多くが、共通して載っている土台です。この記事では、基盤モデルとは何か、上に載るAIがそこから何を受け継ぐのか、不具合をどの層から来たかで切り分ける方法と、層ごとに誰が何を決めるかを整理します。

基盤モデルとは、上に多くのAIを載せる土台のこと

AI事業者ガイドライン第1.2版は、第1部「AIとは」の脚注で基盤モデルをこう説明しています。「大規模言語モデルに代表される基盤モデルは、様々なサービスを支える個別モデルを生み出すコアの技術基盤である」。続けて、「基盤モデルから派生する下流の幅広いタスクに適応させたモデルの開発、開発過程そのものから得られる知見等の観点から、従来のAIとは異なる性質を持つ」とも書いています。本稿の定義は、この文言だけに拠ります。

この説明の要点は2つあります。1つは、基盤モデルそのものは最終の製品ではなく、個別のモデルやサービスを生み出す元だという点です。もう1つは、そこから「下流」の幅広い仕事に合わせたモデルが派生する、という上下の関係です。チャットで質問に答える、資料を探して要約する、メールの下書きを作る、といった私たちが日々触れる機能は、この下流の側にあたります。

ガイドラインは本文でも、2021年以降に基盤モデルが台頭したことで、特定の分野だけに特化したAIではない汎用的なAIの開発が進み、文章や画像などを生成する生成AIが普及しつつあると述べています。ふだん「生成AI」と呼んでいるものの多くは、この基盤モデルの上に組まれたものだと言えます。なお、汎用か特化かという線引きは別の記事「バーティカルAIか汎用AIか」で扱っており、本稿では立ち入りません。

「基盤」の意味は、1つのモデルから多くの用途が派生すること

ガイドラインは、学習を「事前学習」と「事後学習」の2つの工程に分けて説明しています。事前学習はモデルの汎化性能を形づくる段階です。事後学習は、事前学習を済ませたモデルを特定の用途に合わせるための追加の学習で、専門知識の補い、人の意図や価値観に沿った応答に整えることを含み、主な手法として追加の学習やデータを足した再学習が挙げられています。基盤モデルは、この事前学習を大きな規模で済ませた側にあたります。

そのうえで、実際に使う場面には推論の工程があります。ガイドラインによれば、推論では利用者が入力する指示に加えて、RAGなどを介して外部の知識を補った情報も使われ、それらをまとめてモデルが処理することで、状況や用途に即した回答が導かれます。つまり、同じ基盤モデルでも、渡す指示と資料が違えば、まったく別の道具のように振る舞います。製品ごとの違いの多くは、この渡し方の違いから生まれています。

ここに「基盤」と呼ぶ理由があります。土台は1つでも、上に載る建物はいくつも建てられます。社内のチャット、営業資料の検索、議事録の要約、問い合わせの一次回答が、それぞれ別の製品名で入っていても、下をたどると同じ提供元の基盤モデルに行き着くことは珍しくありません。どの土台の上に何が載っているかを知らないままでは、次の章以降で述べる「同時に起きる不具合」に説明がつかなくなります。

語の出どころは2021年の論文と「均質化」という警告

基盤モデルという呼び名は、2021年8月に米スタンフォード大学の基盤モデル研究センターの研究者らが公表した論文で広まりました。論文は、幅広いデータで大規模に学習し、下流の幅広い仕事に合わせて使えるモデルの台頭を、AIの転換点として描いています。「基盤」という語には、中心にありながら、それだけでは完成しないという性格を込めたと説明されています。

同じ論文が強調しているのが「均質化」です。多くの用途が少数の基盤モデルに集まると、改善が一気に行き渡るという強い利点がある一方で、基盤モデルの欠陥は、下流で合わせ込んだすべてのモデルに受け継がれると注意を促しています。本稿のサブタイトルにある「受け継ぐ」という言葉は、この指摘から取っています。

これは研究の世界だけの話ではありません。企業の中でも、部署ごとに別々のAI製品を入れた結果、気づけば同じ基盤モデルに集まっていた、ということが起こります。そのとき均質化は、利点と弱点の両方の形で社内に現れます。土台が良くなれば上に載るAIがまとめて良くなり、土台に癖があれば上に載るAIのすべてに同じ癖が出ます。

社内の別々のAIで、同じ不具合が同じ時期に出る

典型的なのは次のような場面です。社内チャットで最近の制度の改正について聞くと、改正前の内容で答える。同じ週に、資料検索のAIに要約を頼むと、元の資料にない数字を補って書く。さらに問い合わせの一次回答のAIが、特定の言い回しの質問にだけ的外れな答えを返す。担当部署も導入した時期も違うので、これらはそれぞれの窓口に別々の不具合として届きます。

窓口ごとに調べると、指示文を直す、資料を入れ替える、設定を見直す、と個別の手当てが始まります。ところが、一方を直してもしばらくすると似た症状が戻ってくる、あるいは手を入れていない別のAIで同じ症状が見つかる、ということが起こります。個別に直しても消えない不具合は、個別のAIの外から来ている疑いがあります。

こうした症状が重なると、「AIはやはり仕事には使えない」という空気が社内に広がりがちです。しかし原因の多くは、個々の製品の出来の悪さではなく、共通の土台が持つ性質にあります。その性質を知らないまま手当てを重ねると、上の側では消せないものを消そうとして、確かめ直しと設定変更の手間ばかりが積み上がっていきます。

原因は、見た目が違っても同じ基盤モデルに乗っていること

前の章の3つの症状は、それぞれ基盤モデルの性質として説明がつきます。古い内容で答えるのは、学習に使った資料に時期の切れ目があるからです。資料にない数字を補うのは、もっともらしい続きを作るという生成の仕組みそのものから来ています。特定の言い回しにだけ弱いのは、学習の段階でついた得意と不得意の偏りです。

どれも、上に載るAIの側で作り込んだものではありません。だから同じ基盤モデルに乗るAIには、同じ性質が同じ形で現れます。製品名も画面も違うので、利用者からは別々の不具合に見えますが、根は1つです。前の章で触れた論文が警告した「受け継ぎ」は、社内ではこのような形で表に出てきます。

逆に言えば、どのAIがどの基盤モデルに乗っているかが分かっていれば、ある窓口に届いた症状を見て、同じ土台に乗る他のAIにも出ていないかを先回りで確かめられます。窓口ごとに受け付けていた不具合を、土台ごとに束ねて見られるようになる。これが、基盤モデルという考え方を実務に持ち込むいちばんの効用です。

上に載るAIが受け継ぐ5つの性質

受け継ぐ性質を、本稿の整理として5つに分けます。ガイドラインは、AIを製品として提供する事業者に対し、学習などによる出力の変化の可能性や、更新を行った場合の更新内容とその理由を利用者に伝えるよう求めています。土台の性質とその変化が、上に載る利用の側に響くことは、公的な指針でも前提になっていると読めます。

受け継ぐ性質	上に載るAIでの現れ方	上の層で薄められるか（本稿の整理）
知識の切れ目	一定の時期より後の出来事を知らず、古い内容で答える	新しい資料を渡せば薄まるが、渡していない話題では残る
作り話の起き方	資料にない数字や固有名詞を補って書く	根拠の箇所を示させ、人が確かめる工程を置けば減るが、なくならない
偏り	特定の見方や言い回しに寄った答えになる	指示で抑えられる範囲は限られ、人の確認が要る
得意と不得意	長い表、計算、特定の言語や形式で崩れやすい	仕事の渡し方で避けられるが、土台の限界は越えられない
提供元による更新と廃止	ある日から出力の調子が変わる、使っていた版が使えなくなる	上の層では止められず、知らせを受けて備えるしかない

知識の切れ目と作り話の仕組みは、それぞれ別の記事「AIの知識のカットオフとは？」「AIのハルシネーションとは？」で詳しく扱っています。自律して動くエージェントも多くはこの土台の上に組まれており、その型は「自律して動くAI知的エージェントとは？」の記事にあります。本稿で押さえたいのは中身ではなく、これらが個々の製品の欠点ではなく、土台から一斉に受け継がれる性質だという点です。

表の右の列が示すとおり、上の層で手当てできるのは「薄める」ところまでです。新しい資料を渡す、根拠を示させる、人が確かめる、といった工夫で影響は小さくできますが、性質そのものは消えません。だから自社のAIの使い方を決めるときは、どの性質を上の層で薄め、どこから先を人の確認で受け止めるかを先に決めておく必要があります。

受け継がないもの：上の層で決まること

反対に、基盤モデルからは受け継がず、上に載る側で決まるものもあります。どの社内資料を検索の対象にするか、誰がどの資料を見てよいかという権限、画面の作り、会話の記録をどこに残すか、社内の他の仕組みとどうつなぐか。これらは基盤モデルが同じでも、製品の作りや自社の設定によってまったく違ってきます。

この区別が大事なのは、不具合の多くが実はこちら側で起きているからです。検索の対象から古い資料を外し忘れていた、権限の設定で必要な資料が見えていなかった、といった原因は、土台をいくら疑っても見つかりません。土台のせいにしてよいのは、上の層の原因を外したあとと考えるほうが、切り分けは早く進みます。

また、AIを動かす周りの仕組みの作り込みによって、同じ基盤モデルでも成果が大きく変わることが知られています。繰り返し方、渡す道具、止める仕組みといった部品の話は、別の記事「エージェントハーネスとは？」で扱っています。本稿ではそれらを細かく分けず、「載せる仕組み」というひとまとまりの層として扱います。

自社のAIを3つの層で見る

ここまでを踏まえ、本稿では自社のAIを3つの層で見ることを勧めます。これはガイドラインの区分ではなく、不具合の切り分けと役割分担のための本稿の整理です。下から順に、基盤モデル、合わせ方、載せる仕組みの3つになります。

合わせ方の層の中で、資料を渡すか追加で学習させるかの選び方は、別の記事「社内データはAIに覚えさせるか渡すか」に譲ります。この層で覚えておきたいのは、追加の学習で口調や形式、分類の傾向を用途に寄せることはできても、受け継いだ性質がすべて書き換わるとは限らないことです。用途に寄せた分だけ見えにくくなるだけで、下には残っていると考えておくほうが安全です。

3つの層で見ると、同じ「AIが間違えた」でも、層によって直す人も直し方も違うことが見えてきます。載せる仕組みの不具合は、導入した部署か製品の提供者が直せます。合わせ方の不具合は、指示文や資料を見直せば直る見込みがあります。一方で、基盤モデルから来る性質は自社では直せず、薄めるか避けるかしかないという点が、ほかの2つの層との決定的な違いです。

まず、社内のAIがどの基盤モデルに乗っているかを数える

切り分けの前提になるのが棚卸しです。社内で使っているAIを、チャット、検索、要約、文書作成、問い合わせ対応、業務の自動化といった用途ごとに書き出し、それぞれがどの提供元の基盤モデルに乗っているかを確かめます。部署が独自に入れた製品や、既存の業務システムに後から加わったAIの機能も漏らさずに数えます。

1つのAIごとに、表に書いておく欄は次のとおりです。欄の立て方は本稿の整理で、自社の台帳の形に合わせて足し引きしてかまいません。

• 用途、使っている部署、社内の持ち主
• 乗っている基盤モデルの提供元と、版の呼び名（分かる範囲で）
• 合わせ方（指示文、渡している資料、追加の学習の有無）
• 載せる仕組み（画面、権限、記録の残し先、つないでいる社内の仕組み）
• 提供元からの更新や提供終了の知らせを、社内の誰が受け取るか

製品によっては、どの基盤モデルに乗っているかを画面や資料で明かしていないこともあります。その場合は欄を空けたままにせず、「不明」と書いて提供者に問い合わせる対象に回します。不明の欄が残っていること自体が、更新の知らせを受け取れない場所の目印になります。表をAIに読み込ませ、同じ提供元に集まっている用途を要約させるのは手間の削減になりますが、表の中身が正しいかどうかは人が確かめます。

不具合をどの層から来たかで切り分ける

棚卸しができていれば、不具合の届け出を受けたときに層をたどる手順が組めます。本稿で勧める順番は、上の層から疑っていくことです。上の層ほど自社で直せる見込みが高く、確かめる手間も小さいからです。土台を疑うのは最後に回します。

この手順で注意したいのは、同じ症状が複数のAIに出ても、それだけで土台が原因と決めつけないことです。同じ社内資料を複数のAIに渡しているなら、資料が古いだけでも同じ症状が並びます。土台を共有しているのか、渡している資料を共有しているのかを、棚卸しの表で両方見てから判断します。

気づいたあとの原因の外し方や、精度の落ち方を日頃から見張る仕組みは、別の記事「AIの精度が落ちる原因と気づく仕組み」で詳しく扱っています。本稿の手順は、そこに「同じ土台の他のAIと比べる」という一手を足すためのものです。比べる相手を表からすぐ選べることが、棚卸しをしておく見返りになります。

層ごとに誰が何を決めるか

ガイドラインは、AIに関わる事業者を「AI開発者」「AI提供者」「AI利用者」の3つに分けています。開発者はモデルの学習や検証を通じてAIシステムを作り、運用後も事後学習で性能の維持と改善を担います。提供者はAIシステムを製品や業務の流れに組み込んで提供し、運用を支えます。利用者は提供者が意図した範囲で適正に使い、環境の変化などの情報を提供者と共有します。同じ事業者が複数の役割を兼ねる場合もあると明記されています。

層（本稿の整理）	主に作り、直す側	自社が決めること
基盤モデル	基盤モデルの開発者	どの用途をこの土台に載せるか、版の更新を受け入れるか
合わせ方	提供者、または自社	指示文と渡す資料の中身、追加の学習をするか
載せる仕組み	提供者、または自社の情報システム部門	権限、記録の範囲、社内の仕組みとつなぐかどうか

表の右の列は、どの層にも、自社が決めることが残るという点を示しています。土台を自社で作っていなくても、その土台に何を載せるかは自社の判断です。製品の規約で責任の分かれ目をどう読むかは、別の記事「AIで事故が起きたら誰の責任？」で扱っています。

実務では、層ごとに社内の持ち主を決めておくと動きやすくなります。たとえば基盤モデルの層は全社のAIの方針を持つ部署、合わせ方の層は各用途の業務の責任者、載せる仕組みの層は情報システム部門、という分け方です。持ち主のいない層の不具合は、窓口の間を行き来したまま放置されがちです。

AIに任せてよいこと、人が決めること

棚卸しや切り分けの作業には、AIに任せてよい部分があります。棚卸しの表を読み込ませて同じ提供元に集まる用途を一覧にさせる、届いた不具合の記述を症状ごとに束ねさせる、提供元の更新のお知らせを要約させる、といった下ごしらえです。その際は根拠になった行や原文の箇所を必ず示させ、人が元をたどれる形で受け取ります。

一方で、次の判断はAIに任せません。どの層の不具合かの切り分けの確定、提供元の版の更新を受け入れるかの承認、全社を同じ基盤モデルに寄せるか分けるかの決定の3つです。どれも、AI自身が受け継いでいる性質の影響を受けうる判断であり、結果に責任を持つ人が要るからです。

• AIの要約だけで「土台が原因」と結論づける：同じ資料を渡しているだけ、という可能性を見落とす
• 更新の知らせをAIに読ませ、影響なしの判定まで任せる：自社の使い方に照らした確かめが抜ける
• 棚卸しの表の空欄をAIに推測で埋めさせる：もっともらしい提供元の名前が入り、確かめた欄と区別がつかなくなる

ガイドラインも利用者に対し、AIの出力の精度とリスクの程度を理解し、様々なリスクの要因を確かめたうえで使うことを求めています。共通の指針でも、AIに過度に依存する自動化バイアスへの注意が挙げられています。切り分けや承認までAIに預けると、その確かめの主体が組織から消えてしまいます。

提供元の版の更新は、上に載るAIすべてに同時に届く

受け継ぐ性質の中で、上の層ではまったく止められないのが、提供元による更新と提供終了です。基盤モデルの版が改められると、その上に載るすべてのAIで、同じ時期に出力の調子が変わりえます。ガイドラインが提供者に対し、AIシステムの更新を行った場合の更新内容とその理由、学習などによる出力の変化の可能性を伝えるよう求めているのも、この影響を見込んでのことと読めます。

ここで効いてくるのが棚卸しの表です。更新の知らせが届いたとき、どの用途がその土台に乗っているかがすぐに引ければ、確かめる範囲が決まります。逆に表がなければ、知らせを受け取った担当者は自分の使っているAIだけを見て終わり、同じ土台の上にある別部署のAIは誰も確かめないまま、という事態が起きます。

更新のときに回す短い検査、版を固定するかどうか、乗り換えで壊れる箇所の点検は、別の記事「モデルが更新されても業務を止めない方法」「AIのモデル乗り換えで点検する項目一覧」で扱っています。製品そのものの提供が終わる場合の備えは「使っているAIが終わるとき」の記事にあります。本稿で決めておきたいのは、更新の知らせを受け取る人と、受け入れを承認する人を、層ごとに名前で決めておくことです。

全社を同じ基盤モデルに寄せるかは、受け継ぎの集中で考える

社内のAIを同じ基盤モデルに寄せると、指示文の書き方や確かめ方の手順を共通にでき、利用者への教育の手間も減ります。土台の改善が一斉に行き渡るのも利点です。前に触れた論文が均質化の強い利点と呼んだのは、まさにこの点です。

一方で、寄せれば寄せるほど、同じ弱点と同じ更新の影響が全社に集中します。ある時期から土台の調子が変わったとき、すべての用途で同時に確かめ直しが必要になります。分ければ影響は散らせますが、確かめる手順と知らせの受け手が土台の数だけ増えます。どちらが正しいかは一概に言えず、用途ごとの誤りの重さと、確かめる体制の厚さで決まります。

寄せるか使い分けるかの運用の組み方は、別の記事「AIは1つに絞るか使い分けるか」で扱っています。本稿の視点から言えるのは、この決定はAIに任せず、受け継ぎの集中を引き受けるかどうかという問いとして人が決める、ということです。決めた理由を棚卸しの表の横に書き残しておくと、次に見直すときの出発点になります。

「自社専用AI」の中身を確かめる質問

「自社専用」「独自開発」をうたうAI製品でも、既存の基盤モデルの上に合わせ方と載せる仕組みを足したものは少なくありません。それ自体は悪いことではありませんが、土台が何かを知らないままでは、受け継ぐ性質も更新の影響も見積もれません。導入の前や契約更新の前に、提供者へ次のような質問をしておくと、3つの層のどこに何があるかが見えてきます。

• どの提供元の基盤モデルに乗っているか。複数を切り替えているなら、どの用途でどれを使うか
• 自社向けに足しているのは、指示文か、渡す資料か、追加の学習か
• 基盤モデルの版が改められたとき、いつ、どの手段で知らせてもらえるか
• 版を固定して使い続けられるか、その場合はどれくらいの期間か
• 更新による出力の変化を、提供者の側でどう確かめているか
• 不具合が出たとき、原因が基盤モデルか自社向けの部分かを、どこまで切り分けて説明できるか

これらの質問は、ガイドラインが提供者に求める項目とも重なっています。提供者には、システムの構成やデータの処理の過程を文書にしておくこと、更新の内容と理由、出力の変化の可能性、不具合の原因と対応の状況を利用者に伝えることが挙げられています。利用者の側にも、提供者から受け取った文書を適切に保管し活用することが求められています。

答えが曖昧な場合は、契約の前に書面で確かめておきます。特に版の更新の知らせ方と、版を固定できるかどうかは、導入したあとに交渉しても変えにくい項目です。受け取った答えは棚卸しの表の該当欄に書き写し、次の契約更新のときに変わっていないかを見直します。

よくある質問

基盤モデルと大規模言語モデルは同じものですか

ガイドラインは「大規模言語モデルに代表される基盤モデル」と書いており、大規模言語モデルは基盤モデルの代表例という位置づけです。前述の論文も、文章だけでなく画像を生み出すモデルを例に挙げています。社内の話し合いでは、上に多くの用途を載せる土台という役割に目を向けるときは基盤モデル、文章を扱う仕組みに目を向けるときは大規模言語モデル、と使い分けると混乱が減ります。

自社で基盤モデルを作る必要はありますか

基盤モデルを一から作るには、幅広いデータと大きな計算の資源が要ります。そのため多くの企業では、既存の基盤モデルの上に合わせ方と載せる仕組みを足す使い方が中心です。計算の環境を借りるか自前で持つかの判断は、別の記事「AI基盤は借りるか自前で持つか」で扱っています。作らない場合でも、土台に何を載せるかの判断は自社に残ります。

追加の学習をすれば、受け継いだ性質は消えますか

追加の学習で口調や形式、分類の傾向を寄せることはできますが、受け継いだ性質がすべて消えるとは限りません。また、土台の版が改められると、追加の学習をやり直す必要が出ることもあります。性質を消そうとするより、どの性質を人の確認で受け止めるかを先に決めるほうが確実です。

どの基盤モデルを選べばよいですか

本稿では、特定のモデルの良し悪しは扱いません。選び方と比べ方は「【2026年】小規模言語モデルの使い分け」「AIモデルを選ぶ前に見る項目一覧」、仕事ごとの割り振りは「生成AIは仕事ごとに向きが違う」の記事をご覧ください。選ぶ前に、今の社内のAIがどの土台に乗っているかを数えておくと、比べるための材料がそろいます。

• 基盤モデルの定義、学習と事後学習と推論の説明、AI開発者・AI提供者・AI利用者の役割、提供者の情報提供と利用者の留意点は、総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日）に基づきます
• 均質化と欠陥の受け継ぎの指摘は、2021年8月に公表された米スタンフォード大学の研究者らによる基盤モデルについての論文に基づきます
• 3つの層の分け方、受け継ぐ5つの性質と表の右の列、棚卸しの表の欄、切り分けの順番、提供者への質問は本稿の整理で、ガイドラインの区分ではありません

まとめ

AI事業者ガイドライン第1.2版は、基盤モデルを、様々なサービスを支える個別モデルを生み出すコアの技術基盤と位置づけています。社内のチャット、検索、要約、問い合わせ対応といったAIは、製品名が違っても同じ基盤モデルに乗っていることがあり、知識の切れ目、作り話の起き方、偏り、得意不得意、提供元の更新を土台から一斉に受け継ぎます。別々の窓口に届く不具合の根が1つ、ということが起こるのはこのためです。

実務では、社内のAIがどの基盤モデルに乗っているかを数え、基盤モデル、合わせ方、載せる仕組みの3つの層で不具合を上から切り分けます。層ごとに社内の持ち主を決め、更新の知らせの受け手と承認する人を名前で決めておきます。棚卸しの要約や不具合の束ねはAIに任せてかまいませんが、層の切り分けの確定、更新の受け入れ、全社を同じ土台に寄せるかの決定は人が持ち続けてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。