源内OSSで自前のセキュアな社内AI/RAG基盤を持つ｜企業・自治体の検討観点

デジタル庁のガバメントAI「源内（Gennai）」が、商用利用が可能なOSSとして公開された（2026-04-24・二次報道）。これにより、機密データを外部の生成AI SaaSに出しにくい企業や自治体でも、公的に検証された素材を土台に「自前のセキュアな社内AI/RAG基盤」を持つという選択肢が、これまでより現実的になった。重要なのは、ソフトウェアが手に入ること自体ではなく、データの境界・アクセス権限・運用体制・内製と外注の切り分けを最初に設計することだ。本記事では、源内OSSを起点に社内AI/RAG基盤を検討する際の判断軸を整理する。

この記事の要点

• デジタル庁のガバメントAI「源内」が、商用利用可のOSSとして公開されたと報じられている（2026-04-24・二次報道）。マルチクラウド（AWS/Azure/GCP）対応のテンプレートが提供されるとされる。

• 全府省庁向けの大規模実証が2026年度に予定されている（デジタル庁資料・2026年5月時点）。資料では全府省庁約18万人を対象とし、2026年5月末時点で約10万人が利用可能とされる。

• 源内OSSの登場で、外部SaaSに機密データを出しにくい組織が「自前のセキュアな社内AI/RAG基盤」を検討する敷居が下がった。

• 判断の鍵は、ソフトの入手ではなく「データ境界・権限・運用・内製/外注」の設計。ここを曖昧にしたまま着手すると情報漏えい・運用破綻のリスクが残る。

• まずは小さく要件定義し、PoCで効果と運用負荷を見極めてから本番展開するのが現実的だ。

何が起きたのか：政府のAIがOSSで公開された

複数の報道（二次報道）によれば、デジタル庁が府省庁向けに整備したガバメントAI「源内（Gennai）」が、2026年4月24日にOSSとして公開された。商用利用が可能なライセンスで提供され、AWS・Azure・GCPのマルチクラウドに対応したテンプレートが用意されると報じられている。

あわせて、デジタル庁の資料では、全府省庁向けの大規模実証が2026年度に予定されていることが示されている（資料は2026年5月時点）。同資料では、全府省庁約18万人を対象とし、2026年5月末時点で約10万人が利用可能とされる。

ここで企業・自治体にとって意味があるのは、利用人数の大小そのものではない。**「政府が、自らの庁内利用を前提に整備したAI基盤を、商用利用可の形で外部にも公開した」**という事実だ。これは、外部の生成AI SaaSに機密データを預けることに慎重な組織が、公開されたコードという具体的な素材を土台にして、自前のAI/RAG基盤を構想できることを意味する。

汎用的な「オンプレAIを作ろう」という議論は以前からあった。源内OSSが異なるのは、抽象論ではなく公的で具体的な出発点が手に入った点にある。だからこそ、「ソフトがあるから作れる」で止まらず、設計の論点を先に押さえることが重要になる。

なぜ「自前のセキュアな社内AI/RAG基盤」が選択肢に入るのか

外部の生成AI SaaSは導入が速く便利だが、機密性の高いデータを扱う組織には共通の懸念がある。契約書、顧客情報、設計図面、住民情報、医療・介護記録などを、社外のサービスへ送信してよいのか。利用規約上の学習利用やデータ保持の扱いをどこまで把握できているのか。監査や説明責任を果たせるのか。

こうした懸念があると、現場が便利な外部AIを勝手に使う「シャドーAI」が起きやすい。禁止だけでは抑えきれず、かといって全面解禁もできない、という板挟みに陥りがちだ。

自前のセキュアな社内AI/RAG基盤は、この板挟みに対する一つの答えになる。自社・自治体が管理するクラウド環境やネットワーク境界の内側にAIとデータを置き、誰がどのデータにアクセスできるかを自分たちで制御するという発想だ。源内OSSはその土台の候補になりうる。

ただし、自前で持つことは「丸ごと自社運用」を意味しない。マルチクラウド対応のテンプレートを使い、責任分界を明確にしたうえで、必要な部分だけを内製し、残りは外部の知見を借りる、という現実的な構成が取れる。社内AIの企画から要件定義の入口は、AI開発の相談窓口やAI導入の準備度を測るチェックから始めるとよい。

社内AI/RAG基盤の検討観点：4つの軸

源内OSSを土台にするかどうかにかかわらず、社内AI/RAG基盤を検討するときに最初に決めるべき論点は次の4つに集約される。

検討軸	主な問い	つまずきやすい点
データ境界	どのデータをAIに渡すか、どこまでが社内側か	機密データと公開可能データを分けずに一括投入してしまう
アクセス権限	誰がどの文書を参照・回答に使えるか	既存の権限設計を無視し、RAGが見えてはいけない情報を返す
運用体制	誰が更新・監視・障害対応・精度改善を担うか	構築で終わり、運用担当・更新フローが決まっていない
内製/外注	どこを自社でやり、どこを外部に任せるか	全部内製を狙って人員不足で頓挫、または丸投げで中身が分からなくなる

データ境界：何をAIに渡すかを先に決める

RAG（検索拡張生成）は、社内文書を検索してAIの回答根拠にする仕組みだ。ここで最初に決めるべきは「どの文書をAIに渡してよいか」である。機密度の高い情報と一般共有してよい情報を分類せずに一括で取り込むと、回答に出してはいけない情報が混ざるリスクが生まれる。

源内OSSのようにマルチクラウド対応の基盤を使う場合でも、データをどのクラウド・どのネットワーク境界に置くかは自分たちの判断だ。データ分類と配置設計は、データ基盤・データ活用基盤の構築の観点と一体で進めると整理しやすい。

アクセス権限：RAGは既存の権限設計を引き継ぐべき

社内AIでよくある事故が、「本来見られないはずの文書の内容を、AIが要約して答えてしまう」というものだ。RAGは便利な反面、文書の権限管理を素通りしてしまうと、情報漏えいの新しい経路になる。

回避するには、RAGの検索対象に既存のアクセス権限を反映させ、利用者の権限に応じて参照できる文書を絞り込む設計が必要になる。これは生成AIの精度の問題ではなく、設計とガバナンスの問題だ。AIエージェントや社内AIの運用ルールを整える際の論点は、AIエージェント導入の業務・法務・運用チェックリストも参考になる。

機密データを外に出さない社内AI、どこから手をつけるべきか

源内OSSを土台にするか、別の方式にするか。データ境界・権限・運用の設計を、自社の実情に合わせて一緒に整理します。構想段階の壁打ちからご相談いただけます。

社内AI/RAG基盤の構想を相談する → GXO お問い合わせ

※ 営業電話はしません ｜ オンライン対応可 ｜ 構想段階の相談だけでもOK

運用体制：構築より運用のほうが長く続く

社内AI/RAG基盤は、作って終わりではない。社内文書は日々更新され、組織や規程も変わる。古い情報をAIが根拠にすれば、もっともらしい誤回答が増える。だからこそ、誰が文書を更新し、回答品質を監視し、障害に対応し、精度を改善するのか、という運用の担い手とフローを最初に決めておく必要がある。

源内OSSのような基盤を導入しても、運用設計が無ければ「動くが使われない」「精度が落ちて信用されない」状態に陥りやすい。継続的な運用・保守・改善の体制づくりは、AI運用・保守の伴走支援のような枠組みで補完する選択肢がある。

内製/外注：全部抱え込まず、切り分ける

「自前で持つ」を「全部自社でやる」と捉えると、人材不足で止まりやすい。一方で丸ごと外注すると、中身がブラックボックスになり、後から変更や監査がしにくくなる。

現実的なのは、自社が握るべき部分（データ境界・権限・意思決定）は内製で押さえ、構築や難所の設計は外部の知見を借りる、という切り分けだ。源内OSSのコードを土台にする場合でも、自社の要件に合わせた接続・カスタマイズ・既存システム連携はDX・業務システム開発やAI開発・生成AI導入の支援と組み合わせると進めやすい。

進め方：小さく要件定義し、PoCで見極める

源内OSSが公開されたとはいえ、いきなり全社・全庁展開を狙うべきではない。鮮度の高い話題ほど「すぐ入れる」圧力がかかるが、本記事の情報源は2026年4〜5月の発表・実証段階のものであり、機能の細部や規模は出典によって表記が割れている。だからこそ、自組織での適用は次の順で慎重に進めたい。

• まず対象業務を1〜2件に絞り、扱うデータの機密度と利用者の権限を洗い出す。

• データ境界・権限・運用の設計をドキュメント化し、関係部署（情報システム・法務・現場）で合意する。

• 限定範囲でPoC（試行）を行い、回答品質・運用負荷・セキュリティ要件の充足を確認する。

• PoCの結果をもとに、内製/外注の切り分けと本番展開の判断を行う。

この入口で効果と実現性を見極めたい場合は、AI導入の準備度診断やAI開発・生成AI導入の無料相談を起点にすると、論点の抜けを減らせる。RAG導入で実際に問われる要件は、特集のRAG導入 実務チェックにも整理されている。

この記事を読むべき人

• 機密データを外部の生成AI SaaSに預けることに慎重で、自前の社内AI/RAG基盤を検討している企業の情報システム・DX責任者。

• 住民情報や個人情報を扱い、外部送信に制約がある自治体・公共系組織の担当者。

• 源内OSSの公開を受けて「自組織でも使えるのか」を判断したい経営・企画層。

• すでに現場でシャドーAIが起きており、安全な受け皿を用意したいセキュリティ・ガバナンス担当者。

よくある質問（FAQ）

Q1. 源内OSSを入れれば、すぐ社内AIが使えるようになりますか？

ソフトウェアが公開されたことと、自組織で安全に運用できることは別です。データ境界・アクセス権限・運用体制の設計を先に行わないと、情報漏えいや誤回答のリスクが残ります。まずは対象業務を絞ったPoCから始めることをおすすめします。

Q2. 外部の生成AI SaaSではなく、自前で持つ意味は何ですか？

機密性の高いデータを自組織が管理する環境の内側に置き、誰がどのデータにアクセスできるかを自分たちで制御できる点が主な意味です。監査や説明責任が求められる業務、外部送信に制約のあるデータを扱う場合に有効な選択肢になります。

Q3. 利用規模の「約18万人」と「約10万人」はどう違いますか？

デジタル庁資料では、全府省庁約18万人を大規模実証の対象とし、2026年5月末時点で約10万人が利用可能とされています。前者は対象規模、後者はその時点で利用可能な人数として読み分けるのが安全です。正確な数値は一次資料の最新版をご確認ください。

Q4. 全部を自社で開発しないといけませんか？

いいえ。自社が握るべき部分（データ境界・権限・意思決定）を内製で押さえ、構築や難所の設計は外部の知見を借りる、という切り分けが現実的です。源内OSSを土台にする場合も、既存システム連携やカスタマイズは外部支援と組み合わせて進められます。

まとめ

源内OSSの公開は、機密データを外部SaaSに出しにくい企業・自治体にとって、自前のセキュアな社内AI/RAG基盤を持つための現実的な出発点になりうる。ただし鍵を握るのは、ソフトウェアの入手ではなく、データ境界・アクセス権限・運用体制・内製/外注の切り分けという設計だ。ここを曖昧にしたまま着手すると、便利さよりリスクが先に立つ。

まずは対象業務を絞って要件を定義し、PoCで効果と運用負荷を見極めてから本番展開へ進むのが堅実だ。社内AI/RAG基盤の構想段階から相談したい場合はAI開発・生成AI導入の無料相談へ、データ活用の土台から整理したい場合はデータ基盤構築へ、運用まで見据えるならAI運用・保守の伴走支援へ、それぞれ入口を選んでほしい。

一次情報と社内実装に落とす確認表

源内OSSを検討するときは、「OSSがあるから安く早く作れる」と短絡しない方がよい。社内AI/RAG基盤は、データ境界、アクセス権限、モデル選定、ログ、監査、運用責任を含む業務システムである。稟議・RFP・ベンダー選定では、次の一次情報と自社データをセットで確認したい。

確認領域	参照先	稟議・RFPで確認すること
源内資料	デジタル庁 ガバメントAI関連資料	公開範囲、実証対象、利用条件、更新情報を確認する
報道確認	Internet Watch 源内OSS公開記事	二次報道として概要と日付を確認する
AIリスク管理	NIST AI Risk Management Framework	影響範囲、リスク分類、評価方法を確認する
LLMセキュリティ	OWASP Top 10 for LLM Applications	RAGのデータ汚染、権限越境、プロンプト攻撃を点検する
個人情報	個人情報保護委員会	個人情報・委託先管理・安全管理措置を確認する

構築判断は30日・60日・90日の3段階で進める。30日以内に対象業務と文書群を1〜3領域へ絞り、60日以内に権限・データ分類・検索品質の評価セットを作る。90日以内にPoCで回答品質、権限越境、ログ、費用、運用負荷を測る。OSSを入れるだけなら数日でも、業務で使える状態にするにはこの検証が必要だ。

指標	初期値の置き方	90日後に見る状態
対象業務	1〜3業務	本番化候補を1件に絞る
対象文書	100〜1,000件	更新頻度と責任者を確認
評価質問	30件以上	正答・引用・禁止回答を分類
権限ロール	3種類以上	役職・部署ごとの参照範囲を確認
ログ確認	月1回	監査・改善に使える状態にする

GXOに相談する場合は、対象文書、機密区分、既存の認証基盤、クラウド制約、利用者数、RAGで答えたい業務、答えてはいけない質問を共有してほしい。要件定義、RFP、ベンダー選定、AI開発、RAG基盤、基幹システム連携、セキュリティ、運用保守を一体で見ることで、OSS活用を「試しただけ」で終わらせず、社内AI基盤として育てられる。

参考情報

• インプレス Internet Watch「デジタル庁のガバメントAI『源内（Gennai）』をOSS公開」（2026-04-24・二次報道）: https://internet.watch.impress.co.jp/docs/news/2104549.html

• デジタル庁「ガバメントAI（源内）に関する資料・全府省庁向け実証の概要」（2026-05-28・一次情報）: https://www.digital.go.jp/assets/contents/node/information/field_ref_resources/fc155eba-e83d-4ecf-9c6a-a3c855e2e7b3/d0d53b25/20260528_news_genai_outline_01.pdf

実装後に追うKPIとベンダー比較軸

対策を始める前に、導入後の測定方法を決めておく。AI開発、業務システム、セキュリティ、補助金活用、レガシー刷新のいずれでも、成果が測れない投資は次の改善につながらない。特に経営説明では「導入したか」ではなく「どの数字がどう変わったか」が問われる。最低限、次の5項目を月次で追える状態にしたい。

KPI	測定単位	初期目標
処理時間	1件あたり分数	30日で現状把握
手戻り件数	月間件数	60日で原因分類
例外対応	月間件数	90日で削減策を決定
セキュリティ確認	月1回	権限・ログ・脆弱性を確認
費用対効果	月次	削減時間と運用費を比較

ベンダー比較では、金額だけでなく、要件定義、RFP回答、PoC、保守、セキュリティ、データ移行、教育、運用改善を同じ表で見る。見積りが安くても、要件定義が薄い、ログが残らない、引き継ぎ資料がない、保守範囲が曖昧であれば、90日後に追加費用が発生しやすい。

比較軸	確認する質問	赤信号
要件定義	現行業務をどこまで聞くか	ヒアリング1回だけで見積る
セキュリティ	権限・ログ・脆弱性をどう扱うか	管理者権限を広く要求する
PoC	成功条件を数字で置くか	「使いやすさ」だけで判断する
保守	障害時の初動とSLAは何か	連絡先と責任者が曖昧
改善	30日・60日・90日の見直しはあるか	納品後の改善が別料金で不明

問い合わせ前に整理する情報は7点でよい。対象業務、月間件数、担当人数、既存システム、希望時期、予算レンジ、制約条件。この7点があれば、GXO側で要件定義、RFP、ベンダー選定、AI開発、RAG、セキュリティ、補助金、レガシー刷新のどこから着手すべきかを切り分けられる。未整理のまま相談しても構わないが、1時間の初回相談でこの7点を埋めるだけでも、次のアクションはかなり明確になる。

失敗を早く見つけるレビュー運用

導入後のレビューは「最後に品質を見る場」ではなく、30日ごとに前提を直す運用にする。初月は対象を1業務に絞り、2ヶ月目に例外処理を増やし、3ヶ月目に本番運用の責任分界を確定する。AI開発やRAGであれば回答ログ、業務システムであれば操作ログ、セキュリティであれば検知ログ、補助金案件であれば効果測定の根拠を残す。ログがない案件は、効果も事故も説明できない。

レビュー項目	30日	60日	90日
対象範囲	1業務	2業務	本番候補を確定
評価件数	30件	60件	100件
例外分類	5分類	10分類	改善担当を決定
ログ確認	週1回	週1回	月次運用へ移行
経営報告	1回	1回	投資判断を更新

GXOでは、このレビュー表を起点に、要件定義、RFP、ベンダー選定、AI開発、RAG、セキュリティ、レガシー刷新、補助金活用の優先順位を整理する。初回相談では、現状の課題を完璧にまとめる必要はない。業務フロー、画面、帳票、Excel、ログ、既存見積りのうち1つでもあれば、そこから不足情報を洗い出せる。

相談前にそろえる7つの材料

最後に、社内相談・外部相談の前にそろえる材料を明確にしておく。完璧な資料は不要だが、次の7点があると、初回の1時間で論点をかなり絞れる。1. 対象業務、2. 月間件数、3. 現在の担当人数、4. 利用中システム、5. 既存の課題、6. 希望時期、7. 予算レンジ。この7点がないまま製品比較に入ると、要件定義もRFPも曖昧になり、ベンダー選定が価格比較に寄りやすい。

材料	例	使い道
対象業務	受注処理、問い合わせ、申請審査	スコープを1〜3件に絞る
月間件数	100件、1,000件、10,000件	効果測定と費用対効果を見る
担当人数	2人、5人、10人	削減時間と教育計画を見る
利用中システム	SaaS、Excel、基幹システム	連携・移行・権限を確認する
課題	手戻り、待ち時間、属人化	優先順位を決める
希望時期	30日、60日、90日	PoCと本番化の計画を分ける
予算レンジ	初期費用、月額費用	過剰投資を防ぐ

この材料は、AI開発、RAG、AIエージェント、セキュリティ、業務システム、レガシー刷新、補助金のどの相談でも共通して使える。GXOに相談する場合も、この7点から始めれば、要件定義、RFP、ベンダー選定、開発費用、運用体制、セキュリティ要件を同じ土俵で整理できる。

関連記事

• AIエージェント導入の業務・法務・運用チェックリスト

• RAG導入 実務チェック（特集）

• AIエージェント導入前チェックリスト（特集）

• AI導入の準備度診断

• AI開発・生成AI導入の無料相談