要点（最初に結論）

デジタル庁の共通生成AI基盤「源内（GENAI）」が、2026年5月から全府省庁39機関・職員約18万人を対象とした大規模実証フェーズに入っているとされています（時期・規模は公開資料・報道ベース）。
公募で選定された国産LLMは7モデル（tsuzumi 2 / Llama-3.1-ELYZA-JP-70B / Sarashina2 mini / cotomi v3 / Takane 32B / PLaMo 2.0 Prime / CC Gov-LLM）で、横並びで業務適合性が検証される予定です。
本稿で一番伝えたいのは「7モデルのスペック比較」そのものよりも、なぜ日本政府が、海外の高性能モデルを横目に、わざわざ国産LLMを7並列で試すのかという政策的・地政学的な背景です。データ主権・経済安全保障・ベンダーロックイン回避・日本語/制度文脈への適合という4つの動機から読み解いていきます。
公共・自治体向けにAIを提案する立場としては、「源内」の比較設計や調達ロードマップを把握しておくと、PoCや要件定義の議論がしやすくなります。
本稿は公開済みの一次情報を基にした整理であり、本採用や性能順位を断定する内容ではありません。政府の方針は今後変わり得るため、最終的には一次資料の参照をおすすめします。

はじめに：「源内」とは何か

本稿は、公共・自治体向けにAIの提案や要件定義に関わる方、そして国産LLMと行政の関係に関心のあるエンジニアを主な読者として想定しています。
読み進めるのに必要なのは、生成AIの基本用語（LLM、PoCなど）を知っている程度の前提だけです。
特定の実行環境やコードの知識は前提にしていません。

「源内（英語表記 GENAI）」は、デジタル庁が中心となって整備を進めている政府職員向けの共通生成AI基盤です。デジタル庁の公開資料によると、行政文書の作成、政策調査、国会答弁の作成支援など、政府業務に関わる幅広い場面でのAI活用を想定しているとされています。2026年4月にはOSSとしてGitHub上で公開されたと報じられており、自治体や民間企業でも参照・利用しやすい形になったとされています。

名称の「源内」は、江戸時代の発明家・平賀源内を連想させますが、本稿では公式に確認できる範囲を超えた命名意図の解釈は控えます。注目したいのは、その規模感です。

項目	内容
対象機関	全府省庁39機関
対象職員	約18万人
実証期間	2026年5月〜2027年3月（公開情報ベース、一部資料では開始時期に差異あり）
主な用途	行政文書作成、政策調査、国会答弁支援など
公開形態	OSS（GitHub上で公開）

18万人という規模は、単なる試験導入というより「行政組織全体でAIを使う前提の社会実装に近い検証」だと受け取れます。
これだけの規模で「複数の国産LLMを並べて試す」枠組みは、これまでに国内では例が少ないと思われます。
公共向けにAIを提案する事業者からすると、自社の提案内容と国の方向性を擦り合わせる良い参照点になりそうです。

本稿で扱う数字や用語は、デジタル庁の公開資料および各社の公式発表で確認できる範囲を中心にまとめています。記載のない仕様や採用条件については、推測ではなく「公開情報なし／要確認」と明記するようにしています。政府の調達方針は流動的なため、断定的な表現は避けています。

なぜ日本政府は「国産LLM」にこだわるのか

民間の高性能な生成AIを使えば早いはずなのに、なぜわざわざ国産モデルにこだわるのか。ここが本稿で一番深掘りしたい部分です。公開資料や各種報道を読む限り、背景には大きく4つの動機があるように見えます。順に整理していきます。

動機1：データ主権 — 行政データをどこに置くか

最も大きい論点が、いわゆる「データ主権（データソブリンティ）」だと考えられます。

行政が扱う情報には、未公表の政策素案、個人情報、安全保障に関わる情報など、国外に流出すると問題になり得るものが含まれます。海外事業者のクラウドや海外で学習・運用されるモデルにこうしたデータを通す場合、

データが物理的にどの国のデータセンターを経由するのか
相手国の法制度（例えば外国政府によるデータ開示要求が及び得るかどうか）の影響を受けないか
学習に使われない保証や、ログの保持・削除の権限が日本側にあるか

といった点を、行政としては説明責任を持って管理したい、という発想が出てきます。
海外大手の多くは「学習に使わない」「リージョン指定可能」といったオプションを提供しています。
それでも「国内事業者・国内インフラで完結させた方が、国民・国会に対して経路を説明しやすい」という判断が働きやすい領域です。

つまり、ここでの論点は「海外モデルが危ない」という単純な話ではなく、機微情報を扱うときに、データの所在とコントロール権を誰が握っているかを明確にできるかという統制（ガバナンス）の話だと理解するのが正確だと思います。

動機2：経済安全保障 — 基盤技術を他国に依存しない

二つ目は経済安全保障の観点です。生成AIは、今後の行政・産業・防衛の幅広い領域に関わる基盤技術になりつつあります。その中核を特定の海外プレイヤーだけに依存する状態は、

価格や提供条件を相手側に握られる
地政学的な緊張が高まったときに、供給が止まる/制限されるリスクがある
自国内に技術・人材・計算資源のノウハウが蓄積されない

といった懸念につながります。半導体やエネルギーと同じく、「自国で一定の選択肢を持っておく」ことが安全保障上の備えになる、という考え方です。源内の取り組みからは、行政DXを進めると同時に国産AI産業の裾野を育てる、という産業政策的な意図も読み取れます。複数の国内事業者に実証の機会を与えること自体が、国内エコシステムへの投資という側面を持っていると見ることもできます。

動機3：ベンダーロックインの回避 — 1社依存を避ける

三つ目は、特定ベンダーへの依存（ロックイン）を避けたいという調達上の動機です。

仮に1社のモデルに全面的に乗り換えてしまうと、

価格交渉力が下がる（他に移れないと足元を見られやすい）
そのベンダーの仕様変更・値上げ・サービス終了に振り回される
データ形式やプロンプト設計がそのモデルに最適化され、乗り換えコストが膨らむ

といった構造的な弱みを抱えることになります。公共調達では「健全な競争環境を保ち、特定事業者に過度に依存しない」ことが原則として重視される傾向があり、後述する「7モデル並列」という設計は、このロックイン回避の発想とも整合しているように見えます。

動機4：日本語と日本の制度文脈への適合

四つ目は、日本語の処理品質と、日本固有の制度・慣習への適合です。

行政文書には、独特の言い回し、法令用語、決裁文書の様式、国会答弁の作法など、日本の制度文脈に深く根ざした要素があります。汎用の海外モデルでも日本語は扱えますが、こうした「日本の行政文化に固有の文脈」への適合度は、日本語データで追加学習された国産モデルに分があり得る領域です。もっとも、これは「国産だから必ず優れている」という話ではなく、実証を通じて業務適合性を確かめるべき仮説の段階だと捉えるのが妥当だと思います。

ここで挙げた4つの動機は、公開資料や報道から読み取れる範囲での整理です。デジタル庁が公式にこの4分類を提示しているわけではない点はご留意ください。動機の比重は領域や時期によっても変わり得ます。

なぜ「7モデル並列」なのか — 公共調達の発想として読む

ここが本稿のもう一つの核心です。1社に絞らず、あえて7モデルを横並びで試す。この設計には、公共調達ならではの考え方が表れているように見えます。

競争原理を働かせる

複数モデルを同じ土俵に乗せること自体が、事業者間の健全な競争を促します。「選ばれるために性能・運用性・価格を磨く」インセンティブが働き、結果として行政側はより良い条件を引き出しやすくなります。1社を最初から本命に据えるより、横並びで評価する方が、調達の公正性・透明性の観点でも説明しやすいという面もあります。

用途別の適材適所

行政業務は一様ではありません。短い定型文書の作成、長文の政策調査、要約、検索支援、コーディング支援など、求められる特性はタスクごとに異なります。1つの万能モデルを探すより、用途ごとに向いたモデルを使い分ける前提で複数を評価する方が、現実の業務にフィットしやすい、という設計思想が読み取れます。
実際、選定7モデルには「フラッグシップ級の大型モデル」と「1GPUでも動くような中小型モデル」が混在しています。
これは「ベンチマークスコア一発勝負」ではない評価を意識した構成にも見えます。

リスク分散

特定モデルに障害・脆弱性・サービス終了が起きても、他の選択肢があればすぐに切り替えられます。複数を並行して評価しておくこと自体が、行政サービスの継続性を担保するリスク分散になります。

なぜ「いきなり本採用」ではなく「実証（PoC）」なのか

そしてもう一点、なぜPoC（実証）という慎重なステップを踏むのか、という論点があります。

公共調達は、税金を原資とする以上、失敗のコストが大きく、説明責任も重くなります。いきなり1社・1モデルを本採用すると、

後から「他より高かった/性能が劣っていた」と判明したときに是正が難しい
評価指標が曖昧なまま走ると、効果検証ができず説明できない

といった問題が起きやすくなります。そこで、まず横並びの実証で「どの業務に、どのモデルが、どれだけ適合するか」を測り、評価指標を設計したうえで、有償の本格調達に進む。この段階を踏むこと自体が、公共調達の慎重さの表れだと理解できます。源内のロードマップが「試用 → 評価・検証結果の公表 → 本格調達」という順序になっていると見られるのも、この発想と整合します。

採用7モデル一覧と特徴

公開情報を元に、7モデルを整理してみます。パラメータ数などの数値は、各社が公式に公開している範囲のみを記載し、未公開のものはそのまま「公開情報なし／要確認」と明記しています。

モデル名	開発企業	パラメータ数（公式）	公開状況	開発アプローチ	想定される強み
tsuzumi 2	NTTデータ／NTT	公式リリースで「軽量モデル」「1GPU環境で動作」と説明（公開情報では30B規模とされる）	商用提供	国産フルスクラッチ系	日本語処理性能、1GPUで動く運用効率、図表入り文書への対応強化
Llama-3.1-ELYZA-JP-70B	ELYZA（KDDIグループ）	70B	商用提供（デモ公開あり）	Llama 3.1ベースの継続学習	日本語追加学習による長文・指示追従性能、ベースモデルの資産活用
Sarashina2 mini	SB Intuitions（ソフトバンク系）	「mini」位置付け（具体数値の公式表記は要確認）／関連シリーズ Sarashina2.2 で 0.5B / 1B / 3B が公開	商用提供（Sarashina API）	国産フルスクラッチ系	日本語特化、日本の文化や慣習への適合、軽量運用
cotomi v3	NEC	v3のパラメータ数は非公開（v1は13B、v2以降の具体的なパラメータ数は未確認）	商用提供	国産系	エージェント用途を意識した強化、ベンチマーク重視の設計
Takane 32B	富士通	32B（「Takane」シリーズの小・中規模モデルとして7B / 32Bを提供）	商用提供（オンプレ含む）	Cohere Command R+ をベースに日本語で継続学習（富士通×Cohere）	エンタープライズ向け、軽量化・省電力技術と組み合わせた運用
PLaMo 2.0 Prime	Preferred Networks	「Prime」フラッグシップ（Prime自体のパラメータ数は非公開、シリーズ内に1B・8B・31Bが存在）	商用提供	国産フルスクラッチ系	フルスクラッチ開発、日経優秀製品・サービス賞最優秀賞受賞などの実績
CC Gov-LLM	カスタマークラウド	公開情報なし（公式に詳細スペック非公開）	政府実証向けに提供	行政特化チューニング	行政領域向けのチューニング、スタートアップとしての機動力

この表は、各社の公式リリースやニュースリリースで確認できる情報をベースにしています。一部のモデルはパラメータ数や学習データの詳細を公開していないので、比較表でも無理に推定値を入れず「公開情報なし／要確認」と書くようにしています。「開発アプローチ」の列も、フルスクラッチか継続学習かを公式情報の範囲で記載しており、明確に確認できないものは無理に分類していません。

個人的な観察になりますが、フルスクラッチ開発のモデルと、海外のオープンモデル（Llamaなど）を土台に日本語で継続学習したモデルが同じ枠組みに並んでいる点が興味深いところです。「ゼロから国産で作る」路線と「海外の優れた基盤を賢く活用する」路線の両方が並走しており、ここにも前述の「1社・1路線に賭けない」リスク分散の発想が表れているように感じます。

民間 LLM（GPT / Claude / Gemini）との立ち位置の違い

GPT・Claude・Gemini といった海外フロンティアモデルと比べたとき、「源内」採用モデル群はどう位置付けられるのか。ここで大事なのは、比較軸を「純粋な性能の優劣」に置かないことだと考えています。生のベンチマークだけで見れば、海外フロンティアモデルが上回る場面は少なくないと見るのが公平です。そのうえで、行政が重視する軸は別のところにあります。主権・コンプライアンス・コスト・説明責任の4軸で整理してみます。

主権（データ主権）

海外モデルをSaaSで使う場合、ログやプロンプトが国外データセンターを経由するケースがあります。多くのベンダーが「学習に使わない」「リージョン指定可能」といったオプションを提供していますが、行政の機微情報を扱う前提では「国内事業者・国内インフラで完結する」方が、経路と管理権限を国会・国民に説明しやすい場面があります。性能ではなく「コントロール権を誰が持つか」が判断軸になる、という点が海外モデルとの最大の違いだと思います。

コンプライアンス

ISMAP（政府情報システムのためのセキュリティ評価制度）や各種セキュリティ要件、契約面での責任分界などを考えると、国内事業者の方が調整がしやすい場面が多そうです。海外モデルが使えないという話ではなく、「行政固有要件への合わせ込みを誰が担い、誰が責任を負うか」が論点になります。

コスト

API単価だけを見ると海外大手のモデルが安いこともあります。
ただ、行政全体での総コストを考えると、ライセンス体系・運用支援・教育コスト・乗り換えリスク（ロックインによる将来の値上げ余地）まで含めた比較が必要になります。
「源内」でも、本格調達フェーズで初めて有償導入の本格的なコスト評価が表に出てくると考えられます。安いか高いかは、単価ではなくライフサイクル全体で見る必要があります。

説明責任

行政は、なぜそのモデルを選び、どんなデータをどう扱い、どんな出力が出たかを、後から説明できる状態にしておく必要があります。透明性の高い国産事業者・OSS基盤の方が、この説明責任を果たしやすい局面があり得ます。これも性能とは別の軸です。

つまり、海外フロンティアモデルと国産モデルは「どちらか一方を選ぶ」ものではなく、利用シナリオごとに使い分ける構図になりそうです。
あくまで筆者の見立てです。
機微情報を含む文書作成や政策調査は国産、機微情報を含まない汎用業務やコーディング支援などは海外モデルに寄せる。
そうした棲み分けが現実的な落とし所になるのではないかと感じています。

国産LLMが抱える現実的な課題 — フェアに見るために

国産LLMの意義を整理してきましたが、ここで一度立ち止まって、現実的な課題にも触れておきたいと思います。「国産だから良い」という前提で読むと判断を誤りかねないためです。

学習データ量：日本語のテキストデータは、英語圏と比べると総量で見劣りすると言われることがあります。良質な日本語コーパスの確保は、各社にとって継続的な課題だと考えられます。
計算資源（GPU）：大規模モデルの学習には膨大なGPU資源が必要です。世界的なGPU需給の逼迫もあり、海外フロンティア勢と同等の計算規模を国内で確保するのは容易ではない、という指摘があります。
性能ギャップ：汎用的なベンチマークでは、海外の最先端モデルとの差が指摘される場面もあります。ただし、行政業務に必要なのは「あらゆるタスクで世界最高」であることとは限らず、特定の日本語業務での実用十分性が問われる、という見方もできます。
エコシステムの厚み：ツール連携、ドキュメント、コミュニティの蓄積といった周辺エコシステムは、海外勢が先行している領域があります。

これらは「だから国産は不要」という結論を導くものではなく、むしろ実証を通じて、どの課題がどの業務でどれだけ効いてくるのかを見極めることの意義を裏付けるものだと捉えています。横並びの実証は、こうした課題を定量的に把握するための手段とも言えそうです。

公共・自治体向け事業者にとっての示唆

公共や自治体向けにAIソリューションを検討している事業会社の立場で考えると、「源内」の動きはいくつかの観点で参考になります。要件定義・調達・PoC設計のそれぞれに効いてくる話です。

1. 要件定義 — 「主権・コンプラ・コスト・説明責任」を比較項目に組み込む

提案時に「なぜそのモデルを使うのか」を説明する場面が増えています。前述の4軸（主権・コンプライアンス・コスト・説明責任）を要件定義の比較項目として明示的に組み込むと、性能だけに偏らない説明ができ、行政の意思決定者に伝わりやすくなります。源内で並列評価されている7モデルを「比較の物差し」として使うのも有効です。例えば、

「省内の文書作成支援なら tsuzumi 2 や cotomi v3 のような運用効率重視のモデルが向くかもしれません」
「専門的な調査支援なら ELYZA や PLaMo のように長文・指示追従性能を打ち出すモデルとの比較もご検討ください」

といった整理は、提案先の議論のたたき台になります。断定的に「これが最適」と言うのではなく、要件と特性のマッピングを丁寧に提示するスタンスのほうが、行政の意思決定では受け入れられやすい印象があります。

2. 調達 — ロードマップに合わせて逆算する

公開情報を見る限り、ガバメントAIの調達ロードマップはおおむね次のように整理されています（時期は資料ベースで、変更の可能性がある点には留意してください）。

2026年3月〜：試用に向けた契約締結・調整
2026年5月〜2027年3月：大規模実証フェーズ（18万人展開）の期間
2026年8月〜：国内LLM7モデルの試用開始（Release 2.1）
2027年1月頃：評価・検証結果の一部公表
2027年4月〜：優れたモデルを政府調達（有償）として導入予定（Release 3.0）

公共調達は「いきなり本採用ではなく実証から」という慎重なステップを踏むことを前提に設計されています。自治体向けに提案する事業者としても、この段階的なロードマップを意識し、PoC・評価・本番導入を逆算して計画しておくと、国の方針と歩調を合わせやすくなります。特に「評価指標を先に設計しておく」ことは、国の進め方からも学べるポイントです。

3. PoC設計 — 複数モデル横並びを最初から組み込む

源内の動きから学べるPoC設計のポイントとして、「複数モデルを横並びで試す枠組みを最初から組み込む」という考え方が挙げられます。1モデルだけで評価すると、結果が「モデルの良し悪し」なのか「業務との相性」なのか切り分けにくくなります。源内のように、同じ業務シナリオに対して複数モデルを試す設計にしておくと、結果の説明力が上がり、後の調達判断にも耐える評価データが残ります。評価指標（精度・運用コスト・セキュリティ適合・現場の使い勝手など）を事前に定義しておくことも、説明責任の観点で効いてきます。

ここで挙げているのはあくまで一般論で、個別案件の最適解はクライアントの業務内容や法令要件に大きく左右されます。提案先に応じて、要件・制約・予算・人員を踏まえた個別の検討が必要です。

注意点：実証はあくまで実証

ここまで前向きな観点を整理してきましたが、いくつか冷静に押さえておきたい点もあります。

本採用の確約ではない：今回の7モデル選定は、あくまで試用・実証の対象としての選定です。本格採用がどうなるかは、評価結果次第と公開資料に記されています。
性能順位の確定でもない：今回の枠組みは横並びの実証であり、2026年5月時点で「どのモデルが最も優れている」と公式に断定されたものではありません。各モデルが得意とする業務領域や用途が異なる前提で読む必要があります。
海外モデルの排除ではない：源内は国産LLMの活用を進める取り組みですが、政府全体として海外モデルの利用を一律に排除しているわけではありません。用途に応じて使い分けが続くと見ておくのが現実的だと思います。
公開情報の制約：本稿の表に含めた数値は、各社が公式に公開している範囲に限定しています。一部モデルはパラメータ数や学習データの詳細を公開していないため、「比較しきれない部分がある」という前提での理解が必要です。
方針は変わり得る：政府の調達方針やロードマップの時期は、予算・政治状況・技術動向によって変わり得ます。最新情報は必ず一次資料で確認することをおすすめします。

まとめ

「源内」での7モデル横並び実証は、行政DXと国産AI産業の動きを同時に観察できる貴重な題材だと感じています。重要なのは、これを単なる「国産LLMのスペック比べ」として見るのではなく、データ主権・経済安全保障・ロックイン回避・日本語適合という政策的な動機と、競争原理・適材適所・リスク分散という公共調達の発想から読み解くことだと考えています。

事業者の立場としては、

採用7モデルの特徴を、公式情報の範囲で押さえておくこと
海外フロンティアモデルと国産モデルの違いを、性能ではなく「主権・コンプライアンス・コスト・説明責任」の4軸で整理しておくこと
国産LLMの現実的な課題（データ量・計算資源・性能ギャップ）もフェアに踏まえること
本格調達フェーズに向けて、複数モデル横並びを前提としたPoC設計や提案ストーリーをアップデートしておくこと

あたりが、当面の現実的なアクションになりそうです。本記事は公開情報の範囲をベースにした整理ですので、実際の導入検討にあたっては、必ず一次資料と各社の最新リリースを参照していただくのが安全だと思います。

参考リンク

AdverTimes：デジタル庁、政府AI用の国産LLM7モデルを選定 18万人の政府職員で大規模実証
デジタル庁：Government AI “GENAI”
デジタル庁（参考資料）：今後のガバメントAI 源内の展開（2026年3月6日）
国立情報学研究所（NII）：LLM-jp-4 8B / 32B-A3B のオープンソース公開
IPA：政府情報システムのためのセキュリティ評価制度（ISMAP）
内閣府：経済安全保障に関する取り組み
NTT：NTT版LLM tsuzumi 2 アップデート
NTTデータ：tsuzumi 2 製品ページ
ELYZA：Llama-3.1-ELYZA-JP-70B の公開
ソフトバンク：国産LLM「Sarashina mini」のAPI接続サービス「Sarashina API」を法人向けに提供開始
NEC：NEC Generative AI「cotomi」
富士通：世界一の日本語性能を持つ企業向け大規模言語モデル「Takane」を提供開始
Preferred Networks：PLaMo 2.0 Prime リリース
カスタマークラウド：政府向けAI「CC Gov-LLM」が源内に選定
Ledge.ai：デジタル庁、政府AI基盤「源内」で国産LLMを試用へ
Impress Watch：デジタル庁、ガバメントAI用国産LLMを選定 tsuzumi 2やPLaMo 2.0など