連載もここで最終回だ。第1回で「海外3強の代替か」という問いを壊し、二本の軸（汎用性能と、主権・特化）で地図を描いた。第2回で政府の「源内」がその地図に荷重をかける構造を見た。第3回〜第5回で、国産勢の3つの戦略——フルスクラッチ主権型・派生特化型・束ねる型——を一つずつ歩いた。
ここまでで、国産LLMは「使えるのか」という段階を抜けた。2026年6月、問いはもう「どの国産モデルが一番賢いか」ではない。自社のAIスタックの、どの層に、どの戦略の国産を、どう差し込むかだ。今日はその実装の話をする。
まず、問いを「モデル選び」から「層の設計」へ
多くの企業は「どのLLMを使うか」から考え始める。だが、これは実装としては筋が悪い。モデルは、AIスタックの中で最も速く陳腐化する層だからだ。半年で新版が出て、価格は下がり、順位は入れ替わる。そこに自社の競争優位を埋め込むと、土台が動くたびに作り直しになる。
実装の出発点は、モデル選びではなく「層の設計」だ。企業のAIスタックは、おおよそ次の層に分かれる。
ここで連載の3軸——主権・特化・フォールバック——が、実装の場所を持つ。主権は「どのモデルをどこで動かすか」（モデル層とインフラ層）、特化は「自社の知識をどう載せるか」（データ・知識層）、フォールバックは「使えなくなったらどう切り替えるか」（オーケストレーション層）。 国産LLMは、このうちモデル層に差し込む「部品」 だ。賢さで選ぶのではなく、主権・特化・フォールバックという要件を満たす部品として選ぶ。第1回で「軸は数字より長持ちする」と書いたのは、最終的にこの実装判断のためだった。
3つの層に、3つの戦略を割り当てる
では、どの業務に、どの戦略の国産を差すのか。連載で歩いた3分類が、ここで実装の選択肢になる。判断軸はシンプルで、「データを外に出せるか」と「汎用で足りるか特化が要るか」の2つだ。
データを外に出せない業務——機密性の高い情報、データ越境を避けたい要件、業界ガイドラインの対象——は、フルスクラッチ主権型のオンプレに寄せる。tsuzumi 2は1GPUで動く設計で、NTTは小規模なハードウェア構成でも稼働しうるとしており、オンプレ導入のハードルが低い。PLaMoはオンプレ提供があり料金も公開、SarashinaはOracle Alloyを使った国内ソブリンクラウド「Cloud PF Type A」で2026年6月から順次提供が始まった。第3回で見た「主権の床」が、ここで実装の選択肢になる。
データは出せるが、特化が要る業務——業種固有の知識、エージェントとしての作業遂行——は、派生・特化型だ。cotomi v3はMCP準拠でエージェント基盤として、Takaneは監査つきRAGで来歴の説明責任が重い業務に、ELYZAは法人向けの業務AIアプリ作成に向く。第4回で見た「エージェント適性」の土俵がここだ。
汎用で足りる業務——議事録要約、メール下書き、文書検索——は、API調達で最適なものを使えばいい。PLaMoのStandardプラン（入力60円／出力250円・100万トークンあたり）は国産で導入しやすい価格帯の一つだ。ここは賢さとコストで割り切る。
そしてどの経路を選んでも、最後に「束ねる層」で可用性を確保する 。これが第5回の主題だった。
束ねる層をどう作るか——自社構築・源内型・Fugu型
第5回で、束ねる型には「自前で束ねる源内型」と「束ねる仕組みを買うFugu型」の2形態がある、と書いた。実装の現場では、さらにもう一つ「自社で軽く束ねる」選択肢が加わる。3つを並べると、判断しやすい。
多くの中小企業にとって、堅い出発点は ①の「自社で軽く束ねる」 だ。OpenAI互換APIが事実上の標準になった今、モデルを設定値として扱い、プロンプトと予算だけ渡す抽象化レイヤーを置けば、ルーティング（業務ごとにモデルを振り分け）とフォールバック（落ちたら次へ切り替え）は自前で組める。別連載『AIエージェント構築、その前に』で扱った技術的フォールバックが、ここで効く。これだけで、第1回・第5回で繰り返した可用性リスク——2026年6月のClaude Fable 5・Mythos 5停止のような突然のアクセス停止——に耐える設計になる。
ここで一つ踏み込んでおきたい。「Fugu型を使う意味は、管理の手間を省くことだけなのか」。答えは半分そうで、半分は違う。①②は「使えるモデルの中から最良の1つを選ぶ」仕組みで、可用性は確保できるが、性能そのものは上がらない。一方③のFugu型が狙うのは、複数モデルを協調させて「どの単体よりも良い出力」を作ること——第5回で見たAB-MCTS的な集合知だ。これは単なる振り分けとは質的に違う。
ただし、その協調による性能向上が本物かどうかは、まだ独立検証が出ていない。Fuguのベンチマークはすべて提供元の自己申告で、第三者ラボの再現はこれからだ。第5回で触れたAI CUDA Engineerの撤回もある。だから現時点の実装判断としては、可用性は①②で確実に取り、③の性能向上は「第三者検証が出てから」採用を検討するのが妥当だ。手間の解消だけが目的なら①で足りる。性能向上に投資する価値があると判断でき、かつ検証が揃ったときに、はじめて③が選択肢に上がる。
国産を「いつ」入れるか——build / buy / wait
層と戦略が決まったら、次は時間軸だ。すべてを今すぐ自前で組む必要はない。判断は「自社構築（build）／調達（buy）／待機（wait）」の3択で、業務ごとに分ける。
汎用業務（要約・下書き・検索）は迷わずbuy——APIで今すぐ始める。自社固有のデータや業務文脈が競争優位になる業務（与信、顧客対応、専門文書の処理）は、データ・知識層に投資する価値があるのでbuild寄り。そして、まだ要件が固まっていない・市場が動いている領域は、無理に決め打ちせずwait——抽象化レイヤーだけ先に置いて、モデルは後から差し替える。
このwaitを賢くするのが、第2回で見た政府の「源内」だ。中小企業は自前で大規模なモデル評価を回せない。だが源内は、その評価インフラを実質的に肩代わりしてくれる。
源内の評価結果は2027年1月頃に一部が公表される予定で、これがwaitの「答え合わせ」になる。さらに2027年度向けの調達に向けては再公募が予定されており（2026年5月予告）、評価テストは初回の「当日開示・50問」から「事前公表・300問（1問3分・上限15時間）」へと拡充される。評価そのものの厳密さが一段上がることは、源内を「答え合わせ」に使う側にとって追い風になる。源内OSSはGitHubで商用利用可能な形で公開されており、社内RAGの土台にforkできる。そして「政府が採用したモデル」という事実は、保守的な社内稟議を通すうえでの公的なシグナルになる。第2回で「政府のお墨付きが民需に効く」と書いた構造が、ここで実装コストの削減として返ってくる。
オンプレに倒すのは、いつか——TCOと規制の二択
最後に、最も投資判断が重い「オンプレに倒すか」を整理する。これは2つの条件のどちらかで決まる。コストか、規制か。
コストの観点では、第3回で見たTCO逆転の話だ。APIは使った分だけ課金されるので、利用量が増えると累積で膨らむ。一方オンプレは初期投資が重いが、その後はゆるやかだ。どこかで逆転する。2026年の各種試算では、自己ホスティングがAPIを下回る分岐点は、おおむね月あたり1億〜2.5億トークン規模——大量利用の本番システムでないと届かない水準とされる。つまり多くの中小企業にとって、コストだけを理由にオンプレへ倒すのは時期尚早で、「APIで始めてスケール時にハイブリッド」が定石だ。
だが、規制の観点は別の論理で動く。金融・医療・行政のように、データの行き先と来歴を説明する責任が重い領域では、経済性に関係なくオンプレ／プライベートが事実上の要件になる。金融庁は2026年3月にAIディスカッションペーパーの第1.1版を公表し、医療では厚労省のガイドラインが生成AIへの医療情報入力の条件を整理している。ただし、ここは誤解されやすいので正確に言う。たとえば医療のガイドラインは「国内サーバ必須」を一律に義務づけているわけではなく、学習に使われないことが契約等で担保されれば国外サーバも排除されない。「オンプレが要件」かどうかは、業務・契約・社内ポリシー次第で、一律ではない。自社の要件を一次情報で確認することが要る。
実装ロードマップ——3つのステージ
ここまでを、時間軸の行動に落とす。中小企業がいまから動くなら、3ステージが現実的だ。
ステージ1（〜2026年8月／いますぐ）：層を分けて、計測する。 まず抽象化レイヤー（OpenAI互換ゲートウェイ）を置き、モデルを設定値にする。フォールバックチェーンを設定で持つ。これだけで可用性リスクに耐える。同時に60〜90日のトークン利用量を計測する。投資判断は計測の後だ。コモディティ業務はAPIで即開始する。
ステージ2（2026年後半）：主権要件のある業務をオンプレ国産へ。 機密性・越境制約・業界ガイドライン該当の業務を、tsuzumi 2やPLaMoオンプレ、Sarashinaに寄せる。医療なら医学書院・NTT・NTTドコモビジネスが進める純国産の医療AI情報プラットフォーム（2026年度内の商用展開開始を予定）、金融なら監査技術を持つTakaneが軸になる。
ステージ3（2027年1月以降）：政府評価を取り込んで再選定。 源内の評価結果公表（2027年1月頃）を待って、政府採用モデルを再評価する。源内OSSをforkして行政RAGのパターンを社内に転用する。ステージ1で置いた抽象化レイヤーがあるから、ここでモデルを差し替えても上のアプリは作り直さずに済む。
順番が大事だ。先に抽象化レイヤーを置くから、後の差し替えが安くなる。先に計測するから、オンプレ投資を間違えない。先に政府評価を待つから、自前で評価インフラを抱えずに済む。
まだ言えないこと
実装の前提には、まだ動いている数字が多い。
第一に、非開示が多い。tsuzumi 2やSarashina、そして2026年4月に動き出した1兆パラメータ級の「日本AI基盤モデル開発」は、公開価格やパラメータ構成が非開示の部分が大きい。正確なTCO比較は、各社への問い合わせが前提になる。
第二に、ベンチマークは自己申告が多い。PLaMo 3.0 PrimeやFugu Ultraの性能主張は、第三者ラボの独立検証がまだ揃っていない。「主張」として読み、自社の業務で小さく試してから判断するのが筋だ。
第三に、源内の実利用はこれからだ。2026年6月時点で公表されているのは「利用可能な人数」であって、実際の利用実績ではない。評価の質が見えてくるのは、試用と結果公表が進む2026年後半以降になる。
それでも、骨格は動かない。モデルは部品、競争優位は上の層、主権・特化・フォールバックは要件として実装に翻訳できる——この設計の順番は、個々の数字が動いても長持ちする。第1回で「軸は数字より長持ちする」と書いた約束を、最終回はこの形で果たす。
まとめ
- 問いは「どの国産モデルが賢いか」ではなく「自社スタックのどの層に、どの戦略の国産を、どう差すか」。モデル層は最速で陳腐化する「部品」であり、競争優位はオーケストレーション層とデータ・知識層に宿る
- 業務の割り当ては2問で決まる。データを外に出せないならフルスクラッチ主権型（オンプレ）、出せて特化が要るなら派生・特化型、汎用で足りるならAPI調達。どの経路でも束ねる層で可用性を確保する
- 束ねる層は3択：①自社で軽く束ねる（OpenAI互換ゲートウェイ＝多くのSMEの出発点）、②源内型（自前PF・統制重視）、③Fugu型（協調で性能向上を狙う既製品・ただし第三者検証待ち）
- 「いつ入れるか」はbuild/buy/wait。汎用はbuy、自社固有はbuild、未確定はwait。waitは源内（評価結果・OSS・採用実績）を無料の検証インフラとして使うと賢くなる
- オンプレに倒すのはコストか規制のどちらかが効いたとき。コスト分岐は多くのSMEに遠く、規制要件は一律でない（自社要件の一次確認が必須）
- ロードマップは3ステージ。①層を分けて計測（いますぐ）→②主権要件をオンプレ国産へ（2026後半）→③政府評価で再選定（2027年1月〜）。先に抽象化レイヤーを置くから、後の差し替えが安くなる
全6回を通じて見てきたのは、ひとつのことだ。国産LLMは「海外3強の劣化版」ではなく、主権・特化・フォールバックという別の物差しで測るべき選択肢であり、そしていま、それを自社のスタックに具体的に組み込める段階に入った。空白地帯の地図は、もう手元にある。あとは、自社の業務という土地に、どの部品をどの順で置いていくか——それを決めるのは、各社自身だ。この連載が、その判断の軸になれば嬉しい。
参考情報
この記事をシェアする
