ガバメントAI「源内」とは？OSSと国産LLM

2026年4月24日、​デジタル庁が​政府向け生成AI環境​「源内」の​一部を​OSSと​して​公開した。​GitHubで​誰でも​読める。

報道の​見出しは​「ベンダーロックインを​断つ」​「官民連携の​促進」で​揃っている。​だが​実際に​リポジトリと​デジタル庁の​公開資料を​読むと、そのまとめでは落ちてしまう事実がいくつも出てくる。

• 源内Webの​うちAWS以外では​使えない​ファイルが​17個ある。​しかも​それは、​源内を​元の​OSSから​差別化している​中核機能​その​ものである
• Pull Requestは受け付けていない。 Issueも​「データ損失・サービス停止・法令違反・重大な​アクセシビリティ障壁」に​限定されている
• デジタル庁の​資料には​「永続的なメンテナンスを保証するものではなく、将来的にOSSの公開を終了する場合がある」と​明記されている
• 「国内開発の​LLMを​選定・活用する」と​いう​方​針は、​汎用チャット側と​国産モデルの​評価検証側で別のトラックで​進んでいる。​国産3モデルに​ついては、​2026年9月から​11月に​かけてA/Bテストで評価する計画が​公表されている

本記事は、​源内を​一次​資料​（GitHubリポジトリ、​デジタル庁の​公開資料、​開発担当者本人の​技術記事）から​読み解く。​運用体制の​数字だけは​講演報告と​いう​二次資料に​依拠しており、​その​箇所は​明記する。​批判が​目的ではない。約18万人を対象とする実証環境を1〜2人のインフラ担当で回している設計は、​企業が​AI基盤を​作る​ときに​そのまま​効く。​持ち帰れる​ものを​取りに​行く。

この​​記事の​​対象読者

• 自治体・​公共向けに​AIサービスを​提供しようと​しており、​源内OSSの​採用可否を​判断する​必要が​ある​事業者
• 社内に​複数の​AIアプリを​展開したいが、​認証・ログ・UIを​毎回​作り直していて​増やせない​情報システム部​門
• 国産LLMの​採用を​検討しており、​政府が​どの​モデルを​どう​選んだかを​知りたい​推進担当者
• AI基盤の​運用体制を​設計中で、​少人数で​回す前提の​設計例を​探している​アーキテクト

源内とは​何か

源内​（GenAI）は、​デジタル庁が​開発・運用する​行政職員向けの​生成AI利活用基盤である。​名前の​由来は、​生成AIの​英語略称GenAIと、さまざまな生成AIアプリケーションの発明が集まってほしいという願いの​2点だと​開発担当者が​書いている。

デジタル庁の​公開資料から、​規模と​現在地を​数字で​押さえる。

開発担当者は​源内の​位置づけを​こう​書いている。

「この​プロジェクト​「源内」は、​直近の​デジタル庁職員の​生産性改善だけでなく、​ガバメントAIの​推進に​対する​課題の​解決も​視野に​入れており、生成AIのサービス提供というよりも、技術検証の意味合いが大きいです。」

サービス提供その​ものより​技術検証に​重心が​ある、と​いう​自己規定である。​後述する​OSSの​扱いを​読むときの​前提に​なる。

公開されたのは​​何か​​ — 2つの​​リポジトリ

拡大 ⤢

公開は​2つの​GitHubリポジトリに​分かれている。

源内Webに​対して​デジタル庁が​加えた​変更は、​READMEに​列挙されている。​チーム管理機能、​AIアプリ管理機能、外部マイクロサービスとして構築した生成AIアプリの追加・実行機能、​デジタル庁デザインシステムの​適用、​庁内アクセシビリティチームに​よる​試験、​運用に​必要な​監視機能。​READMEは​「GenUとは​独立して​開発を​進めており、​GenUとは​異なる​機能構成と​なっています」と​明記している。

AIアプリ側の​リポジトリには、​ガバメントクラウドに​採択された​3つの​クラウドそれぞれの​テンプレートが​入っている。

• Amazon Web Services：行政実務用RAG​（検索拡張生成）の​開発テンプレート
• Microsoft Azure：LLMを​セルフデプロイして​利用する​開発テンプレート
• Google Cloud：最新の​法律条文データを​参照・回答する​法制度AIアプリの​再現可能な​実装

設計の​​核心 — インターフェースと​​AIアプリを​​切り離す

源内で​最も​真似する​価値が​あるのは、​この​一点である。

READMEは​こう​書く。​「源内で​利用できる​行政実務用AIアプリは、源内Webとの間のプロトコルに準拠すれば、源内Webと独立した環境で構築ができ、GUI等の操作で源内への追加登録ができます。」

開発担当者は​この​プロトコルを​「約束」と​呼び、​共通化すべき対象と​して​挙げている。​通信の​プロトコル、​入出力の​形式と​項目、​認証認可の​方法、​非同期処理の​実現方​法、​ログ取得要件、​主体認証を​どちらが​行うか、といった​責務分離である。

実装としては、AIアプリのAPIリクエストのデータ形式（JSON）の定義から、利用者向けの実行画面が自動生成される。​AIアプリを​作る​側は​画面を​作らない。

この​分離が​効いている​証拠が​ある。​デジタル庁自身、Google CloudのGeminiを使った行政実務用AIアプリを源内上で実行可能にしている。​源内Webは​AWS上に​あるのに、である。

企業に​​置き換えると​​何が​​変わるか

社内で​AIツールが​増えないのは、​たいてい能力の​問題ではない。1つ作るたびに、認証・権限・ログ・監査・UIをもう一度作っているからである。​共通の​土台が​ないまま​数を​増やすほど、​追加と​保守の​負担は​積み上がる。

源内の​構造は、​その​反復を​インターフェース側に​一度だけ寄せる。​業務側は​「約束」に​従う​APIを​1本立てるだけで​よくなる。AIアプリを作る速度ではなく、AIアプリを増やせる構造を先に作る、という順番の話である。

1〜2人で​​18万人を​​支える​​運用設計

拡大 ⤢

AWS Summit Japan 2026での​講演を​報じた​記事に​よれば、源内のインフラ専任エンジニアは1〜2人である。​この​体制で​40以上の​テナントを​運用し、​新機能の​開発も​並行している。​以下​この​節の​数字は、​この​講演報告​（二次資料）に​よる。

前提と​して、​源内はサイロモデルを​採っている。​省庁ごとに​DynamoDBや​S3を​個別に​構築して​リソースを​分離し、​その​境界を​IAMで​強制する。​万一バグで​他省庁の​データを​参照しようと​しても​IAMが​防ぐ。​セキュリティは​上がるが、環境が独立している分、更新や管理の手間はテナントの数だけ膨らむ。

この​二律背反を、​宣言的インフラ管理で​解いている。

1. 管理者は​設定変更の​要件をYAML形式の指示書に書く
2. GitHubにチェックインする
3. それを​トリガーに​Control Plane内の​Lambda関数群が​連動する
4. システム構成の​正本​（SSoT）である​DynamoDBの​テーブル​「Tenant Master」に​指示内容を​マージし、​現在の​インフラ状態と​比較する
5. 差分が見つかったときだけデプロイを​実行する

ユーザーが​触る​環境​（Application Plane）と、​それを​裏側から​自動構築・管理する​仕組み​（Control Plane）を​分けている。​効果は​具体的である。

講演者の​言葉は​「全部を宣言にする」である。

これはハーネスエンジニアリングとは？​エージェント品質の​決め手で​扱った​原則と​同じ​構造を​している。品質と運用を人間の注意力ではなく、決定論的な仕組みに預ける。 対象が​エージェントの​出力か​インフラの​状態かが​違うだけで、​設計の​考え方は​同じである。

国産LLMは​​どこに​​いるのか

デジタル庁の​資料は​方針を​明確に​書いている。

「AIに​関する​日本の​自律性確保を​実現する​ため、​源内では国内開発の大規模言語モデル（LLM）を選定・活用します。 政府に​よる​継続的な​調達を​通じ、​国産AIの​育成・強化を​推進します。」

ここで​大事なのは、汎用チャットで選べるモデルと、国産モデルの評価検証は別のトラックで進んでいると​いう​点である。​混ぜて​読むと​現在地を​見誤る。

汎用チャット側

2026年7月時点で​職員が​選択できるのは、​AWSの​Nova Lite、​Anthropicの​Claude Haiku 4.5 / Sonnet 4.6 / Opus 4.8 の​4モデルである​（2025年11月時点は​3モデルだった）。ここは海外モデルが担っている。

国産モデル側

一方で、​国産モデルは​既に​一部が​本番に​入っている。​2025年12月から​Preferred NetworksのPLaMo翻訳が​源内を​通じて​政府職員に​提供されている。​海外の​言語モデルを​ベースと​せず​設計から​学習までを​国内で​完結している​点が、​採用理由と​して​会見で​挙げられている。

そして​評価検証の​トラックが、​公募から​順に​進んでいる。

3月に​選定された​7件​（五十音順）と、​5月時点で​契約締結に​至った​5社は​次の​とおり。

デジタル庁の​別紙は​「その​後​2社から​辞退の​申し出が​あった​ため、​最終的に​5社と​契約を​締結しました」と​記している。

選定基準に​​「自前で​​動く​​こと」が​​入っている

ここが​本記事の​読者に​とって​最も​重要である。​公募の​選定基準には、​次の​条件が​含まれている。

「政府職員が​機密性2情報を​取り扱える​よう、​十分な​セキュリティを​確保できる​こと。​具体的には、ガバメントクラウド上の推論環境で動作すること。」

APIと​して​外から​呼ぶのではなく、政府が管理するクラウド上に推論環境を立てて動かせることが​要件に​なっている。​評価テストも、​試験当日に​初めて​開示される​50問で​実施された​と​公表されている。

そして​この​要件は、​具体的な​構成と​して​示されている。​2026年8月21日​最終更新の​デジタル庁資料に​よれば、​NTTデータの​tsuzumi 2、​富士通の​Takane 32B、​Preferred Networksの​PLaMo 2.0 Primeの​3モデルを、さくらのクラウド上で​稼働させる。​さくらの​クラウドは​ガバメントクラウドに​おける​唯一の​国産クラウドであり、​デジタル庁は​これを​「政府がガバメントクラウド上でさくらのクラウドを実利用する初めての事例（第一号案件）」と​説明している。

評価方​法も​公表されている。​源内の​チャット機能で​国産基盤モデルを​提供し、​既存の​基盤モデルとのA/Bテスト（利用者に​ランダムかつブラインドで​出力を​提示し、​どちらが​好みかを​選ばせる）で​比較する。​資料には​「本年8月までに​実験環境を​構築し、​本年9月～11月の​期間に​複数回の​実験を​実施する」と​ある。本記事の公開時点は、この予定期間に入ったところである。​この​資料だけでは​実験の​開始実績は​確認できない。​評価・検証結果の​一部は​2027年1月頃に​公表予定である。

「国産LLMを​​使う」を​​3つの​​軸で​​分解する

自治体や​企業が​同じ​ことを​しようと​する​とき、​次の​3つは​別の​軸である。​混同すると​調達が​止まる。

源内が​選定基準に​据えたのは​3つ目である。重みが公開されているかどうかではなく、自分たちが管理する環境で推論を動かせるかどうかが​条件に​なっている。​選定された​各モデルの​重みの​公開状況や​利用条件は、​公募結果の​資料には​書かれていない。​そこは​モデルごとに​別途確認する​項目である。

上の​5モデルに​ついて​自社で​同じ​構成を​組めるかは、​モデルごとに​提供事業者へ​確認するのが​確実である。​たとえば​tsuzumi 2は、​NTT西日本らが​オンプレミス環境で​利用できる形での​提供を​2026年9月から​開始すると​発表している。入口が「ダウンロード」か「商談」かは、モデルによって違う。

OSSの​​Azureテンプレートは​​セルフホストの​​実装例を​​含む

源内OSSに​含まれる​Azureの​テンプレートは、​Azure OpenAIの​APIを​使う​構成と、vLLMに対応したHugging FaceモデルをGPU上でセルフホストする構成の​両方を​扱っている。

後者の​構成は、​API Management → Application Gateway​（WAFで​ヘッダ検証）​→ GPUを​積んだ​VM Scale Setと​いう​閉域構成で、​GPUコスト対策と​して​Azure Automationで​VMを​定期的に​起動・停止する​仕組みまで​入っている。

そして​vLLM側の​実装例と​して​使われているのが、​Preferred Networksのplamo-2-translateである。​READMEは​利用に​あたって​plamo-community-licenseを​参照するよう​明記している。​この​ライセンスの​条件​（商用利用には​事前登録が​必要で、​年商10億円超は​別途商用ライセンスが​必要）はローカルLLM比較で扱っている。政府の参照実装だからライセンスを読まなくてよい、ということにはならない。

モデル選定​その​ものの​考え方はオープンウェイトモデルの​選び方、​必要な​GPUの​見積もりはローカルLLMに​必要な​GPU要件を​参照して​ほしい。

ライセンスを​​読む — MITだけではない

源内Webの​READMEは、​ライセンスを​こう​書いている。​ソフトウェアは​MIT、​ドキュメントは​CC BY 4.0。ただし、AWS Prototyping Programにより作成された一部のLambda・CDKファイルはAmazon Software License（ASL）の対象である。

対象は​17ファイル。​リポジトリのdocs/ASL対象ファイル.mdに​一覧が​ある。​中身を​見ると、​性格が​はっきりする。

packages/cdk/lambda/createExApp.ts        ← 外部AIアプリの登録
packages/cdk/lambda/listTeams.ts          ← チーム管理
packages/cdk/lambda/repository/teamRepository.ts
packages/cdk/lib/construct/team-access-control.ts  ← アクセス制御
（ほか13ファイル）

これは、源内を元のGenUから差別化している中核機能そのものである。 チーム管理、​AIアプリの​登録、​アクセス制御。​前述した​「インターフェースと​AIアプリを​切り離す」​設計を​支えている​部分が、​ここに​含まれている。

ドキュメントは​正直に​書いている。

「非AWS環境では、​上記の​ASL対象ファイルを​そのまま​実行する​ことは、ライセンス上だけでなく技術的にも不可能である​ため、​該当箇所を​ご自身の​環境に​合わせて​実装し直す必要が​あります。」

整理すると​こうなる。

アプリ層は改変も再配布も自由である。公開された源内Webの一部はAWSでの利用に限られる。 ​「ベンダーロックインを​断つ」と​いう​要約は、​アプリ層に​ついては​素直に​読めるが、​Web層に​ついては​条件が​付く。

な​お、​MITである​ことは​改変・再配布の​許諾であって、​移植が​技術的に​容易である​ことまでは​意味しない。​AWSの​マネージドサービスに​依存した​実装を​他クラウドへ​持っていく​改修量は、​ASL対象の​17ファイルとは​別に​見積もる​必要が​ある。

自治体​向けに​サービスを​組む事業者なら、​判断は​分かれる。​AWSで​組むなら​17ファイルごと​使える。​他クラウドで​組むなら、差別化機能の再実装と、AWS依存部分の移植の両方を最初に見積もる必要がある。

PRを​​受け付けない​​OSS

もう​1つ、​採用前に​読むべきものが​ある。​両リポジトリの​READMEに​同じ方​針が​書かれている。

「本リポジトリでは、​サービスの​安定運用に​影響する​致命的な​問題に​限り、​Issueでの​報告を​受け付けています。Pull Requestは受け付けておりません。」

Issueの​対象は​両リポジトリ共通で、​データの​損失・破損、​サービスが​利用​不能に​なる​障害、​法令・規則への​違反の​3つ。​源内Web側には​これに​加えて、​アクセシビリティ上の​重大な​障壁​（JIS X 8341-3:2016 適合レベルAA相当）が​挙げられている。対象外と​して​明記されているのは、​機能追加の​要望・提案、​軽微な​表示崩れ・誤字脱字、​パフォーマンス改善提案、​コーディングスタイルの​指摘、​質問・​使い方の​相談である。

さらに​デジタル庁の​資料には​こう​ある。

「脆弱性への​対応等、​必要な​メンテナンスを​実施する​ため、​当面の間は​公開OSSの​更改・修正作業を​継続する。​ただし、永続的なメンテナンスを保証するものではなく、将来的にOSSの公開を終了する場合がある。」

理由は​公式には​説明されていない。​ここからは​筆者の​解釈に​なるが、約18万人を対象とする実証環境の運用責任を負っている組織が、同じコードを公開するときの現実的な形だと​読める。​外部​PRを​取り込めば、​その​品質と​安全性の​責任は​公開元に​戻ってくる。

また、​GitHub上の​受付方​針と、​外部への​技術支援が​ない​ことは​別である。​デジタル庁の​資料には​「公開した​源内の​OSSを​活用し、​地方​公共団体等向けサービスと​して​展開する​ことを​検討している​企業からの​技術的な​お問い​合わせに​対応する」と​明記されており、別の窓口は用意されている。

ただし採用する​側の​帰結は​はっきりしている。フォークして自分で保守する前提で読む。 アップストリームが​直してくれる、​機能追加を​提案できる、​いつまでも​公開されている​——​その​どれも​前提に​できない。

横展開が​​止まる​​4段階

源内の​構想記事には、​行政に​限らず​そのまま​通じる​整理が​ある。​他組織の​成功事例を​自組織に​取り入れるまでに​4段階の​壁が​あると​いう​仮説である。

源内の​仮説は、​3つを​共通化すれば​この​4段階が​軽減されると​いう​ものである。

「記述」（ドキュメント）の共通化。 AIアプリの​概要と​機能、​業務での​具体的な​効果​（削減工数、​コスト削減率など）と​その​算出方​法、​必要な​データ・外部​システム、​権利・セキュリティ上の​懸念、​運用費用、​導入時の​留意点。​これが​揃えば​検索性と​一覧性が​上がり、段階1と2が軽減される。

「約束」（プロトコル）の共通化。 同じ​約束に​従う​インターフェースを​既に​導入していれば、​AIアプリ部分だけを​調達すれば​よくなる。​コピー構築や​マルチテナント化で​安価かつ迅速に​実現できる。​ここで段階3と4が大幅に軽減される。

「代表的な実装パターン」の共通化。 複数ファイルの​入出力、​非同期の​大量データ処理、​マニュアルなど​特定書類の​参照、​AIが​自律再実行して​外部リソースに​アクセスする​場合。

企業で​事業部​ごとに​AIツールが​乱立して​横展開しないのは、​まったく​同じ​構造である。足りないのはアイデアではなく、「記述」と「約束」の共通化である。

企業が​​源内から​​持ち帰れる​​もの

失敗パターン

OSSだから無料で使える、と読んで採用を決める。 ライセンスは​層ごとに​違い、​17ファイルは​AWS限定である。​さらに​保守の​継続が​保証されていない。採用判断に必要なのは「MITかどうか」ではなく、「自分で保守できるか」である。

PRを送って改善に参加するつもりで計画を立てる。 受け付けていない。​コミュニティ型OSSの​前提で​採用計画を​書くと、​初回の​フォークで​詰まる。

「国産LLMだから自由に使える」と読む。 重みの​公開状況・商用利用の​条件・実行場所は​別の​軸で、​モデルごとに​違う。​源内が​選定基準に​据えたのは​「ガバメントクラウド上の​推論環境で​動作する​こと」であって、​重みの​公開ではない。

「約束」を決めずにAIアプリを増やす。 数が​少ないうちは​動く。​増える​ほど、​認証と​ログの​実装が​アプリごとに​散らばって​保守が​効かなくなる。

サイロモデルだけ真似て、宣言的な管理を入れない。 環境を​分けた​分だけ運用負荷が​増える。​源内が​テナント分離を​成立させているのは、​Control Planeが​あるからである。

FAQ

Q1. 源内の​​OSSを​​そのまま​​使えば、​​自治体​向けの​​生成AI基盤が​​作れるのか？

A. AWS上で​構築するなら、​源内Webと​同等の​環境を​構築できる​ソースコードと​手順が​公開されている。​ただし他の​クラウドで​構築する​場合は、​Amazon Software Licenseの​対象と​なる​17ファイル​（チーム管理・AIアプリ登録・アクセス制御）を​自前で​実装し直す必要が​ある。​デジタル庁自身​「ライセンス上だけでなく​技術的にも​不可能」と​書いている​箇所である。​加えて、​MITの​部分も​AWSの​マネージドサービスに​依存しており、​移植の​改修量は​別途見積もる​必要が​ある。

Q2. なぜPull Requestを​​受け付けないのか？

A. 公式に​理由は​説明されていない。​以下は​筆者の​解釈である。​源内は​約18万人を​対象と​する​実証環境であり、​開発担当者自身が​「生成AIの​サービス提供と​いうよりも、​技術検証の​意味合いが​大きい」と​位置づけている。​外部​PRを​取り込めば​品質と​安全性の​責任は​公開元に​戻る​ため、​運用責任を​負う​組織と​しては​合理的な​線引きだと​読める。​なお、​自治体向けサービス展開を​検討する​企業からの​技術的な​問い合わせには​対応すると​資料に​明記されており、​窓口が​無いわけではない。

Q3. 源内で​​使われている​​LLMは​​国産なのか？

A. 2つの​トラックが​並行している。​汎用チャットで​職員が​選べるのは、​2026年7月時点で​Nova Liteと​Claude Haiku 4.5 / Sonnet 4.6 / Opus 4.8 の​4モデルで、​ここは​海外モデルである。​一方で​国産モデルも​既に​入っており、​2025年12月から​PLaMo翻訳が​提供されている。​さらに​2026年8月21日​最終更新の​資料では、​tsuzumi 2・Takane 32B・PLaMo 2.0 Primeの​3モデルを​さくらの​クラウド上で​稼働させ、2026年9月から11月にかけてA/Bテストで評価する計画が​示されている。

Q4. 契約締結した​​5社の​​国産LLMは、​​自社でも​​同じように​​使えるのか？

A. モデルごとに​違うので、​提供事業者に​確認するのが​確実である。​判断は​「重みが​公開されているか」​「商用利用の​許諾条件」​「APIか​自社環境への​デプロイか」の​3軸に​分けると​整理しやすい。​源内が​選定基準に​据えたのは​3つ目で、ガバメントクラウド上の推論環境で動作することが​条件だった。​自社環境で​動かせる​例と​しては、​tsuzumi 2に​ついて​NTT西日本らが​オンプレミス環境向けの​提供を​2026年9月から​開始すると​発表している。

Q5. 源内OSSの​​Azureテンプレートは​​何を​​する​​ものか？

A. vLLMに​対応した​Hugging Faceモデルと​Azure OpenAIの​モデルを​Azure上で​ホスティングし、​APIと​して​提供する​テンプレートである。​前者の​セルフホスト構成は、​API Management → Application Gateway → GPU搭載の​VM Scale Setと​いう​閉域構成で、​Azure Automationに​よる​VMの​定期起動・停止まで​含む。​vLLM側の​実装例と​して​Preferred Networksの​plamo-2-translateが​使われており、​利用には​plamo-community-licenseの​確認が​必要である。

Q6. ​「記述」と​​「約束」の​​共通化は、​​自社では​​どこから​​手を​​付ければ​​よいか？

A. ​「記述」からである。​既存の​AI施策に​ついて、​効果の​算出方​法・必要な​データ・運用費用・導入時の​留意点を​同じ​書式で​1枚に​揃える​ところまでは、​開発を​伴わない。​これだけで​横展開の​段階1と​2は​動く。​「約束」​（プロトコル）の​設計は、​AIアプリを​継続的に​増やす見込みが​立ってから​着手しても​遅くない。

Q7. 源内は​​今後も​​公開され続けるのか？

A. 保証されていない。​デジタル庁の​資料に​「当面の間は​公開OSSの​更改・修正作業を​継続する。​ただし、​永続的な​メンテナンスを​保証する​ものではなく、​将来的に​OSSの​公開を​終了する​場合が​ある」と​明記されている。​採用する​場合は、フォークして自分で保守する前提で​計画すべきである。

次に​​読むべき記事

• ハーネスエンジニアリングとは？​エージェント品質の​決め手 — 品質を​仕組みに​預ける​設計
• ローカルLLM比較｜日​本語性能と​ライセンス — モデルごとの​ライセンス条件
• オープンウェイトモデルの​選び方 — 重みが​公開された​モデルの​選定軸
• ローカルLLMに​必要な​GPU要件 — セルフデプロイの​計算基礎
• AIガバナンスと​実装セキュリティ｜6つの​制御点 — 機密情報を​扱う​環境の​設計

まとめ

• 源内は​デジタル庁の​行政職員向け生成AI基盤。​2026年5月から​全府​省庁 約18万人を対象とした大規模実証が​走っており、​5月末時点で​約10万人が​利用可能
• 開発担当者は「生成AIのサービス提供というよりも、技術検証の意味合いが大きい」と​位置づけている。​OSSの​扱いは、​この​前提を​踏まえて​読むと​理解しやすい​（筆者の​解釈）
• 設計の核心はインターフェースとAIアプリの分離。​「約束」​（プロトコル）に​準拠すれば​独立環境で​AIアプリを​作れ、​リクエスト形式の​定義から​利用者画面が​自動生成される
• 講演報告に​よれば、インフラ専任1〜2人で40以上のテナントを運用している。​YAML指示書を​GitHubに​チェックインすると​差分だけデプロイされる​宣言的インフラが​効いている
• ライセンスは​層で​違う。​AIアプリ側は​全て​MITで、​3クラウドそれぞれに​実装例が​ある。源内Webの17ファイルはAmazon Software Licenseで、非AWS環境では使えない。 しかも​それは​チーム管理・AIアプリ登録・アクセス制御と​いう、​源内を​元の​GenUから​差別化している​中核である。​な​おMITの​部分も、​移植には​AWS依存の​改修が​別途かかる
• Pull Requestは受け付けていない。 Issueも​致命的な​問題に​限定。​さらに​「永続的な​メンテナンスを​保証する​ものではなく、​将来的に​OSSの​公開を​終了する​場合が​ある」と​明記されている。フォークして自分で保守する前提で読む
• 国産LLMは​2トラックで​進んでいる。​汎用チャットは​2026年7月時点で​Nova Liteと​Claude 3種。​国産側は​2025年12月から​PLaMo翻訳が​提供され、​契約5社の​うち3モデル​（tsuzumi 2 / Takane 32B / PLaMo 2.0 Prime）をさくらのクラウド上で稼働させ、2026年9〜11月にA/Bテストで評価する計画である。​公募は​15件応募→7件選定→2社辞退→5社契約と​いう​経緯を​たどった
• 選定基準に「ガバメントクラウド上の推論環境で動作すること」が入っている。 重みが​公開されているかではなく、​自分た​ちが管理する​環境で​推論を​動かせるかが​条件に​なっている
• 横展開が​止まる​4段階​（知らない​／効果が​不明瞭／方​法が​わからない​／コストが​高い）は​企業でも​同じ。​効く​打ち手は​「記述」と​「約束」の​共通化である

FDXの​​支援範囲

FDXは​AX​（AI Transformation）の​実装パートナーと​して、​業務の​分解から​実装・現場定着・運用移管までを​対応領域と​する。

源内から​読み取れる​最大の​教訓は、AIアプリを1つ作ることと、AIアプリを増やせる構造を作ることは別の仕事だと​いう​点である。​後者を​飛ばしたまま​数を​増やすほど、​追加と​保守の​負担が​積み上がる。

自社で​AIアプリを​どう​増やせる​形に​するか、​どの​モデルを​どこで​動かすかを​業務要件から​整理したい​場合はお問い合わせから、​まず​現状を​把握したい​場合はAX診断からどうぞ。

出典・参考文献

• デジタル庁「genai-web​（源内Web）」​README・docs/ASL対象ファイル.md（ライセンス構成、​ASL対象17ファイル、​Issue/PR対応方針。​2026年9月16日確認）
• デジタル庁「genai-ai-api​（源内AIアプリ）」​README・azure/genai-azure/README.md（3クラウドの​テンプレート、​vLLM構成、​plamo-2-translateの​利用。​2026年9月16日確認）
• デジタル庁 戦略・組織グループ AI実装総括班​「（参考資料）​ガバメントAI源内の​展開状況」​（2026年5月。​約18万人を​対象と​する​実証、​展開スケジュール、​機密性2の​条件、​OSS公開範囲と​メンテナンス方​針、​自治体向けサービスを​検討する​企業からの​技術的問い​合わせへの​対応）
• デジタル庁「ガバメントAIで​試用する​国内大規模言語モデル​（LLM）の​公募結果」​（2026年3月6日。​応募15件・選定7件、​選定基準、​当日開示の​50問評価テスト、​今後の​スケジュール）
• デジタル庁「令和8年度​（2026年度）に​源内で​評価検証を​行う​企業一覧」​（2026年5月29日。​契約締結済​5社、​2社辞退の​経緯）
• デジタル庁「ガバメントAI 源内に​おける​国産クラウド上での​国産基盤モデルの​試用開始に​ついて」​（2026年8月21日​最終更新。​さくらの​クラウド上で​稼働させる​3モデル、​A/Bテストに​よる​評価方​法、​2026年9〜11月の​実験予定、​2026年7月時点の​選択可能モデル4種）
• 大杉直也​（デジタル庁）​「ガバメントAI、​プロジェクト​「源内」の​構想紹介」​（2025年11月11日。​名前の​由来、​3つの​最重要事項、​横展開の​4段階、​「記述」​「約束」​「代表的な​実装パターン」）
• 名須川竜太「行政機関18万人を​支える​「源内」​ わずか​1〜2人での​運用を​実現した​“一見​手の​込んだ​仕組み”」​ITmedia エンタープライズ​（2026年9月8日。​AWS Summit Japan 2026に​おける​大月氏の​講演報告。​サイロモデル、​Application/Control Plane、​SSoT、​40テナント×20アプリ。本記事で唯一の二次資料であり、​運用体制の​数値は​この​報告に​よる）
• Preferred Networks​「plamo-2-translate モデルカード」​（PLaMo Community License）

※ 引用中の​強調​（太字）は​編集部に​よる。​英数字前後の​空白や​算用数字の​表記は​読みやすさの​ため調整している。