デジタル庁は2026年4月24日、全府省庁向けの生成AI環境であるガバメントAI「源内（GENAI）」をGitHubでOSS公開しました。狙いは、自治体や各府省庁が似たAIシステムを重複開発することと、特定ベンダーへロックインされることを構造的に防ぐことです。
この動きは行政だけの話ではありません。社内AIをゼロから作ろうとしている民間企業にとっても、「作る前に、使える部品が公開されていないかを確認する」という発想を持つきっかけになります。本記事では、源内の公開構成を手がかりに、再利用の可否を判断するための具体的な確認項目を整理します。
源内OSS公開で実際に出たもの
源内のOSS公開では、紹介記事でよく語られる「18万人が使う」という規模よりも、何が再利用可能な形で出たかが実務上重要です。公開されたのは主に次の構成です。
| 公開物 | 内容 | 民間企業での再利用イメージ |
|---|---|---|
| Web UI のソースと構築手順 | 利用者向け画面と環境構築の手順 | 社内AIポータルの土台として参照 |
| 行政実務用RAG開発テンプレート | 文書を根拠に回答する仕組みの雛形 | 社内規程・マニュアル検索の出発点 |
| 自己ホスト型LLMのデプロイテンプレート | 自社環境でLLMを動かす構成 | 機密データを外に出さない構成の参考 |
| 法制度AIアプリの実装例 | 最新法令を参照する応用例 | 契約・規程チェックなど自社版への応用 |
ソフトウェア本体はMITライセンス、ドキュメントはCC BY 4.0で、いずれも商用利用・改変・再配布が可能です。つまり民間企業が自社の社内AIへ取り込むこと自体は、ライセンス上は許容されています。
ただし注意したいのは、テンプレートが前提とするクラウド構成です。源内の各テンプレートは、RAGはAWS、自己ホスト型LLMはAzure、法制度AIアプリはGoogle Cloudというように、特定のクラウドサービスを前提に書かれた部分があります。さらに、本体はMITでも、構成に含まれる一部の部品にはAmazon Software Licenseのように利用条件が異なるものが混ざる場合があります。「本体がMITだから全部自由」と早合点せず、再利用する部品ごとにライセンスと前提クラウドを確認する作業が欠かせません。
一次情報として、デジタル庁の公開ページとリリース告知でライセンスと公開範囲を必ず確認してください。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。ROI 試算シート・失敗要因チェックリストをその場で共有します。
「作る前に再利用する」かを決める4つの確認
再利用が許されていることと、自社で安全に運用できることは別です。発注や内製の判断に入る前に、次の4点を埋めてから進めます。
1. ライセンスと改変範囲
MITライセンスは商用利用できますが、改変したコードの保守責任は自社に移ります。「無償だから安い」ではなく、改変・追従・脆弱性対応を誰が続けるかを先に決めます。OSSを土台にする場合、本家の更新へどこまで追従するかも方針化が必要です。
2. 入れてよいデータと入れてはいけないデータ
RAGテンプレートを社内文書に向けると、参照範囲の設計がそのまま情報漏えいリスクになります。顧客情報、契約情報、人事情報のうち、どれをインデックス対象にするか、誰が参照できるかを先に分類します。ここはLLMセキュリティreadiness診断で、社内データを渡す前の前提を点検しておくと判断が早くなります。
3. 運用と保守の責任者
OSSは導入できても、問い合わせ対応、モデル更新、障害復旧、ログ確認は自社に残ります。業務部門、情報システム、外部委託先の役割を分け、最終判断者を文書化します。
4. 再利用と内製と外注の切り分け
源内を参考にすると、すべてを内製したくなりますが、自社のエンジニア体制次第では運用で詰まります。再利用する部品、自社で書く部分、外部に任せる部分を切り分け、システム見積の読み方で運用費まで含めて比較します。
自社流用 可否判定チェックリスト
4つの確認をそのまま稟議や社内検討に持ち込めるよう、観点ごとに「確認項目」と「OK・NGの目安」を一覧にしました。判定がNG側に寄る項目が多いほど、ゼロからの再利用ではなく外部支援や別の選択肢を検討するサインになります。
| 観点 | 確認項目 | OKの目安 | NG（要追加検討）の目安 |
|---|---|---|---|
| ライセンス | 本体MIT／ドキュメントCC BY 4.0の範囲と、一部部品（例：Amazon Software License）の条件を区別できているか | 再利用する部品ごとにライセンスを台帳化し、配布・改変条件を確認済み | 「本体MITだから全部自由」と一括りにしている |
| クラウド前提 | RAG＝AWS、自己ホスト型LLM＝Azure、法制度AI＝Google Cloudという構成前提を、自社の利用クラウドと突き合わせたか | 既存契約クラウドに合わせて移植・読み替えの方針が決まっている | テンプレートのクラウド前提を確認せず、そのまま動くと想定している |
| 自社データの取り扱い | RAGのインデックス対象（顧客・契約・人事など）と参照権限を分類したか | 入れてよいデータと禁止データを定義し、参照範囲を設計済み | どの文書を入れるか未定のまま検証を始めようとしている |
| セキュリティ要件 | 自己ホスト構成で機密データを外に出さない要件、認証・ログ・監査を満たせるか | 既存のセキュリティ基準に照らして必要対策を洗い出し済み | 「OSSだから安全」「自己ホストだから安全」で済ませている |
| 運用体制 | 問い合わせ対応・モデル更新・障害復旧・本家追従の担当を決めたか | 業務部門／情シス／委託先の役割と最終判断者を文書化済み | 導入後の保守担当が未定、または特定個人に依存 |
セキュリティ要件の行で判断に迷う場合は、社内データを渡す前提をLLMセキュリティreadiness診断で点検し、運用体制やコストの比較はシステム見積の読み方とAI開発のRFP・セキュリティ・費用チェックリストで具体化すると、稟議の精度が上がります。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
PoCから本番までの導入評価プロセス
チェックリストでNGが少なかったとしても、いきなり本番展開はおすすめしません。源内のようなテンプレートを再利用する場合でも、小さく検証してから広げる段階設計が安全です。次のステップで進めます。
- 対象業務の絞り込み：まずは情報漏えいリスクが低く、効果が見えやすい1業務（例：社内規程の検索）に絞ります。最初から全社展開を狙わないことが、撤退判断をしやすくする鍵です。
- 再利用範囲の切り分け：源内のどのテンプレートを土台にし、どこを自社で書き、どこを外注するかを決めます。可否判定チェックリストの結果をそのまま材料にします。
- 小規模PoC：限定したデータと少人数で、回答精度・参照範囲・権限制御を検証します。ここで「禁止データが回答に出ないか」を必ず確認します。
- 運用設計とコスト試算：PoCの結果をもとに、保守・モデル更新・障害対応の体制と、ライセンス費以外の総額（構築・データ整備・運用）を見積もります。
- 段階的な本番展開：対象業務を一つずつ増やし、各段階で権限とログを点検します。台帳と引き継ぎ資料を更新し続け、属人化を防ぎます。
AI活用全体の進め方を整理したい場合は、生成AI導入の完全ガイドもあわせて参照すると、再利用判断を全社方針の中に位置づけやすくなります。
向く企業と向かない企業
源内のOSSを社内AIへ再利用する取り組みは、すべての企業に等しく向いているわけではありません。自社がどちらに近いかを確認してから着手すると、無駄な検証を避けられます。
向く企業
- 自社に改変・運用を担えるエンジニアがいる、または信頼できる委託先を確保できる
- 機密データを外に出せず、自己ホスト型LLMの構成に明確なメリットがある
- 入れてよいデータと禁止データを整理する体制があり、権限設計を運用し続けられる
- ベンダーロックインを避けたい明確な理由（調達方針・継続性）がある
向かない（慎重に検討すべき）企業
- エンジニアがほぼおらず、改変・追従・障害対応を担う体制が作れない
- 対象業務やデータがまだ定義できておらず、まず要件整理から必要
- 短期で確実に成果が必要で、テンプレートの自社適合に時間をかけられない
- SaaSで十分に要件を満たせ、自己ホストの必然性がない
向かない側に当てはまる場合でも、考え方を参考にしつつ構築・運用を外部に任せる、SaaSと組み合わせるなど現実的な選択肢があります。
再利用で失敗しやすい3つのパターン
- OSSを「完成品」と誤解する：源内はあくまで開発テンプレートと実装例です。自社のデータ、権限、業務に合わせる工数が必ず発生します。
- ベンダーロックイン回避のつもりで属人化する：特定ベンダーに依存しない代わりに、社内の特定担当者に依存すると、退職時に運用が止まります。台帳と引き継ぎ資料を最初から残します。
- 法制度AIの実装例をそのまま自社規程に流用する：参照する法令や社内規程は組織ごとに異なります。実装例は構造の参考にとどめ、根拠データは自社のものへ差し替えます。
GXOはどう支援するか
GXOでは、源内のようなOSSを「再利用すべきか、内製すべきか、外注すべきか」の切り分けから支援します。初回相談では、対象業務、扱うデータ、社内のエンジニア体制、既存の委託先、予算感を確認し、ゼロから作らずに済む範囲と、自社が責任を持つ範囲を整理します。RAG構成のデータ設計や、自己ホスト型LLMの運用設計まで、稟議資料と見積に落とせる形でお手伝いします。
よくある質問
Q1. 源内のOSSは中小企業でも使えますか
ライセンス上は使えます。ただし自社で改変・運用する体制が必要です。エンジニアが少ない場合は、テンプレートの考え方を参考にしつつ、構築と運用は外部に任せる選択も現実的です。
Q2. RAGテンプレートを使えば社内検索はすぐ作れますか
仕組みの雛形は得られますが、社内文書の整理、権限設計、入力禁止データの定義が前提です。ここを飛ばすと、参照してはいけない文書まで回答に出る事故につながります。
Q3. 無償OSSなら見積は不要ですか
ライセンス費はゼロでも、構築、データ整備、権限設計、運用、保守の費用は発生します。総額で比較するために、運用費まで含めた見積を取ることをおすすめします。
Q4. テンプレートのクラウド前提が自社と違っても使えますか？
考え方は使えますが、そのまま動くとは限りません。源内はRAGがAWS、自己ホスト型LLMがAzure、法制度AIアプリがGoogle Cloudを前提に書かれた部分があります。自社が別のクラウドを使っている場合は、構成の読み替えや移植の工数を見込んでおく必要があります。
Q5. 再利用を進めるとき、ガバナンス面で気をつけることは？
入力禁止データの定義、参照権限、ログと監査、本家更新への追従方針を、運用ルールとして残すことです。OSSを土台にすると改変の自由度が上がる分、誰が何をどこまで変更したかを管理する仕組みが重要になります。全社的な指針づくりは生成AIガバナンスの進め方も参考になります。
参考情報
- デジタル庁「ガバメントAI（源内 / GENAI）」：https://www.digital.go.jp/policies/genai
- デジタル庁「Government AI "GENAI" のOSS公開」：https://www.digital.go.jp/en/news/907c8e5d-2f4f-4bd7-9400-37c9f4221d7d
社内AIは「作る前に再利用」で費用と期間を圧縮しませんか
GXOでは、OSSやSaaSの再利用・内製・外注の切り分け、RAGのデータ設計、自己ホスト型LLMの運用設計を、見積と稟議資料に落とせる形で支援します。