デジタル庁がガバメントAI「源内」をオープンソース化、RAG・LLMセルフデプロイ・法制度AIのテンプレートを商用利用可で公開
目次
2026年4月24日、デジタル庁が中央省庁で展開中の生成AI利用環境「源内(げんない)」の一部をオープンソースとして公開した。
Webインターフェースのコードに加えて、AWS・Azure・Google Cloudそれぞれを前提にしたAI開発テンプレートも同梱されていて、しかも商用利用可能なライセンスになっている。
「国が作ったAIシステムがまさかGitHubに出てくるとは」という温度感だが、再利用を前提にした作りで、地方自治体や民間事業者が自分の環境で「源内」を再構築できる。
「源内」とは
源内は、政府職員向けの生成AI利用環境。
デジタル庁が主導して整備しているもので、中央省庁の業務で使える前提の共通基盤として設計されている。
2026年度中には約18万人の政府職員が生成AIを利用できるようにする計画になっている。
目的は単なるチャットUIの提供ではなく、「業務特化の生成AIアプリケーションを、早く・安全に・簡単に実際の業務で使えるようにする」こと。
単一のLLMラッパーではなく、業務別AIアプリをチームごとに管理・登録・運用できる基盤寄りの作りになっている。
背景にあるのは、2025年5月に成立したAI法(通称)と、同年12月に閣議決定された「人工知能(AI)基本計画」。
「隗より始めよ」で政府自身がまずAIを使いこなす側に回る、という文脈で源内が整備されている。
公開されたもの
GitHubのdigital-go-jp組織配下で、2つのリポジトリが公開されている。
| リポジトリ | 内容 |
|---|---|
digital-go-jp/genai-web | 源内本体のWebアプリケーション |
digital-go-jp/genai-ai-api | AI側のマイクロサービス(クラウド別テンプレート) |
genai-web(Webアプリ本体)
職員がアクセスする画面側。
AWSが公開している生成AIユースケース向けのOSSプロジェクトをベースに、デジタル庁が独自機能を足して作っている。
技術スタックはそこまで奇をてらった構成ではない。
- 言語: TypeScript(リポジトリの99%)
- フロントエンド: React
- スタイリング: Tailwind CSS
- インフラ: AWS + AWS CDK
主な機能は以下。
- チーム管理: 組織単位でAIアプリをまとめる
- AIアプリの管理・登録: 業務特化AIをアプリとして登録
- 外部マイクロサービスの追加・実行:
genai-ai-api側のテンプレートと組み合わせる - デジタル庁デザインシステムの適用
- SAML認証対応: 職員認証に乗せやすい
- ログ・CI/CD・カスタムドメイン設定
「業務別AIアプリのアプリストア兼ランチャー」のような立ち位置に近い。
genai-ai-api(AI側マイクロサービス)
Webアプリから呼び出すAI処理の実体がこちら。
モノレポで、3つのクラウドそれぞれを前提にしたテンプレートが分かれて入っている。
| フォルダ | クラウド | 内容 |
|---|---|---|
aws/ | AWS | 行政実務用RAG開発テンプレート |
azure/ | Azure | LLMセルフデプロイ開発テンプレート |
google-cloud/ | Google Cloud | 法制度AI開発テンプレート |
全部入れる必要はなく、自分のクラウド環境に合わせて欲しいテンプレートだけ使える。
言語構成はPythonが4割強、Bicep(Azure用IaC)とTypeScript、HCL(Terraform用)、Shell、PowerShellが混ざっている。
AWS・Azure・Google Cloudで何が違うのか
3つのテンプレートは担当領域が明確に分かれている。
graph TD
A[源内 genai-web<br/>職員が触る画面] --> B{業務用途}
B -->|ナレッジ検索・文書QA| C[AWSテンプレート<br/>行政実務RAG]
B -->|独自LLMを動かす| D[Azureテンプレート<br/>LLMセルフデプロイ]
B -->|法令・法制度に強いAI| E[Google Cloudテンプレート<br/>法制度AI]
C --> F[S3 / OpenSearch等で<br/>省内文書をRAG]
D --> G[Azure上に<br/>自前LLMをデプロイ]
E --> H[法令API・現行法情報と<br/>連携したAIアプリ]
- AWS: 省内文書やマニュアルをRAGで引ける前提のテンプレート。行政実務寄り。
- Azure: 自前のLLMをクラウドに立てて動かす想定。モデル選定の自由度が高い。
- Google Cloud: 法制度・法令を扱うAIアプリ専用。現行法情報との連携を前提にしている。
面白いのは、特定クラウドに寄せずマルチクラウドで書いていること。
省庁横断で使う前提だと、すでに導入済みのクラウドは省庁ごとに違うので、全部揃える作りになるのは自然ではある。
ライセンスと商用利用の扱い
licenseは2系統。
- ソースコード: MIT License(一部Amazon Software Licenseが混ざる)
- ドキュメント: Creative Commons Attribution 4.0 International(CC BY 4.0)
MITなので商用利用・改変・再配布が可能。
「源内を丸ごと社内向けに立てる」「テンプレートの一部を既存のAI基盤に組み込む」といった使い方が問題なくできる。
一方で、デジタル庁側は運用方針として以下も明記している。
- 機能要望・Pull Requestは受け付けない
- 脆弱性報告だけは指定ページ経由で受ける
- 公的リソースとしてOSSコミュニティに提供する、という位置付け
OSSとして「配布はするが共同開発プロジェクトではない」というスタンス。
フォークして各自で育てる前提になっている。
逆に「公開しないもの」
オープンソース化されていない部分も明記されている。
- 内部マニュアル類
- 大規模言語モデル(LLMそのもの)
- 本番環境のログ
LLMは切り離されているので、源内を自分の環境に立てる場合はAPIキーなり自前ホストのモデルなりを別途用意する必要がある。
AzureテンプレートはLLMセルフデプロイに踏み込んでいるので、そこから自前運用につなげるルートはある。
なぜ公開したのか
デジタル庁は公開理由を3つ挙げている。
- 参照実装としての役割: 中央省庁で業務特化AIを安全に動かすための共通ルール整備に寄与する
- 重複開発の防止: 地方自治体や他の政府機関が似たような基盤をゼロから作らずに済む
- 特定事業者への依存の軽減: 改変・再利用できる形で配ることで、一社依存を抑える
特に2番目は現場の事情としては切実で、自治体ごとに生成AI基盤をSIerに発注すると、似た要件のシステムが全国で何十個も並列開発されることになる。
源内を下敷きにできるなら、調達コストも運用リスクもまとめて下げられる。
3番目の「特定事業者依存の回避」は、AWSベースのOSSに乗りながらも、マルチクラウドのテンプレートを揃えている点に現れている。
クラウドベンダーロックインを外せる余地が残されている。
今後の予定
利用実績や、技術的な知見を順次公開していく予定とされている。
特に「ガバメントクラウドでモダンなWebアプリケーションを作った話」系の技術記事が予告されていて、政府クラウド上で現実的にAIアプリを運用するレシピが外に出てくる可能性がある。
政府が公開するAI基盤は、機能単体よりも「どう運用しているか」の情報のほうが価値が高いことが多い。
このあたりの続報は追っておきたい。
関連する動き
国産AI・政府AI周りは2026年に入ってから動きが速い。
少し前には、ソフトバンクやNEC・ホンダ・ソニーが国産AI新会社「日本AI基盤モデル開発」を設立して、1兆パラメーター級のフィジカルAIを目指すという話が出ている。
こちらは「国が使うモデルそのもの」寄り、源内は「国が使う利用環境」寄り、という役割分担になる。
モデル側については、NIIがLLM-jp-4-32B-A3B-thinkingを公開していたり、日本語LLMの選択肢自体が急速に増えている(日本語LLMの整理)。
源内のAzureテンプレートと組み合わせれば、日本語特化モデルを自前ホストして政府系ユースケースに当てる、という構成も現実的に組める。
自分の環境に落として何に使えるのか
公開されたリポジトリを手元に落としてきたとして、実際何ができるのか。
READMEを斜め読みしたうえでの読み筋を整理しておく。
前提として必要なもの
genai-webだけなら React + TypeScript + Tailwind で動かせそうに見えるが、実運用には以下が前提になる。
| 前提 | 内容 |
|---|---|
| SAML認証基盤 | 職員認証に乗せる前提なので、社内IdPなり代替のダミー認証なりが要る |
| クラウドアカウント | AWS / Azure / Google Cloud のどれかひとつは最低限必要 |
| LLMの口 | Bedrock、Azure OpenAI Service、Vertex AI、または自前ホストLLMのいずれか |
| AWS CDK | genai-webのデプロイはAWSベース |
フロントだけ起動するなら npm install && npm run dev で触れるが、AIアプリとしての価値を出すなら結局クラウド側のリソースが必須になる。
NotebookLM的な使い方はできるか
できるが、スコープは少し違う。
NotebookLMはPDFやGoogle Docsをアップロードして要約・Q&A・音声ポッドキャスト生成までやるツール。
一方で源内は「業務別AIアプリを組織単位で管理・運用する基盤」なので、NotebookLMの機能そのものをすぐ提供するわけではない。
ただしAWSテンプレートが「行政実務用RAG」なので、以下のようなユースケースは自然に組める。
- 省内マニュアルを取り込み、職員が自然言語で問い合わせる
- 過去の通達や議事録を検索可能にして、担当者がQ&A形式で引く
- 複数文書にまたがる情報を横断的に要約する
音声ポッドキャスト生成のような派手な部分はテンプレートの範囲外。
ただし外部APIを呼ぶマイクロサービスを追加する設計になっているので、別途TTSを噛ませる拡張はやりやすい。
どんなLLMが必要か
LLMはリポジトリに含まれていない、というのが一番大事なポイント。
公開されているのは「AIアプリの器」と「クラウド別のテンプレート」だけで、モデルは自分で持ち込む前提になっている。
選択肢は大きく分けて3つ。
| ルート | 使えるモデル | 向いているテンプレート |
|---|---|---|
| マネージドLLM | Claude (Bedrock) / GPT-4o (Azure OpenAI) / Gemini (Vertex AI) | 各クラウドの標準テンプレート |
| 自前ホスト | Llama / Qwen / LLM-jp / PLaMo など | Azureテンプレート(セルフデプロイ想定) |
| ハイブリッド | 機密データは自前、一般タスクはマネージド | 全テンプレート |
行政用途だとデータをクラウドベンダーのAPIに出せないケースがある。
Azureテンプレートが「LLMセルフデプロイ」を前提にしているのはこのため。
日本語特化ならLLM-jp-4-32B-A3B-thinkingのようなオープンモデルを自前ホストして繋ぐのが現実的。
資料のエンベッディング検索は組めるか
組める。というかAWSテンプレート側の主要機能がこれ。
「行政実務用RAG」と銘打っている時点で、以下の構成が内包されていると見てよい。
- 文書アップロード → 埋め込みモデルでベクトル化
- ベクトルDB(OpenSearch / Bedrock Knowledge Base / pgvector 等)に格納
- 質問が来たら類似文書を検索 → LLMに文脈として渡す
埋め込みモデルそのものは各クラウドのマネージドを想定している。
- AWS: Titan Embeddings, Cohere Embed
- Azure: text-embedding-3-small/large, ada-002
- Google Cloud: text-embedding-004, gecko
ハイブリッド検索(ベクトル + BM25)やリランキングを入れるかは実装次第。
テンプレートをそのまま使うだけでもエンベディング検索は成立するが、実務レベルで精度を出すにはドメイン特化のチャンク設計・メタデータ設計が必要になる。
政府のシステム一式をGitHubで配る、というのは日本ではまだ珍しい。
digital-go-jp/genai-web をクローンすれば一旦手元で動かせるので、源内の中身を知りたいなら読むより git clone のほうが早い。