源内 / GenAI
生成AI 利活用基盤 (源内Web × 行政実務用AIアプリ) · 2026-04-24 公開
バラバラなAI利用を、
安全に管理し、
業務に広げる基盤へ。
デジタル庁が開発・運用する生成AI 利活用基盤。
一部が商用利用可能なライセンスのもと、無償の OSS として公開された。
源内 (GenAI) は、利用者が直接触る 源内Web と、業務向けの 行政実務用AIアプリ という2 種類のシステムで構成される。源内Web には、チーム管理 / AIアプリ管理 / 外部マイクロサービスとして構築した生成AIアプリの追加・実行機能が組み込まれている。デジタル庁デザインシステムの適用、アクセシビリティ試験、監視・モニタリング等の運用機能も整備されている点が、汎用 OSS との違いだ。
- 源内とは：デジタル庁が開発・運用する生成AI 利活用基盤の OSS。
- 仕組み：源内Web と業務別 AI アプリを分離し、チーム管理・AI アプリ管理・外部 AI アプリ連携を備える。
- 企業にとって：社内の AI 利用を安全に管理し、業務別 AI アプリを広げるための検証基盤になり得る。
事実 2026年度に全府省庁の約 18 万人の政府職員を対象とした大規模実証を実施予定（デジタル庁公式発表）。これは政府の実証スケールであり、企業導入の実績値ではない点に注意。
情シス・管理部門が抱える「3 つのジレンマ」
生成 AI への需要はあるが、現場任せにも自前構築にも踏み切りにくい——「禁止」「許可」「自社開発」のどれを選んでも別のリスクが残るというトレードオフが、多くの組織で観測されている。
3 つのジレンマ
- 禁止しても個人判断で管理されていない AI 利用が広がりやすい
- 許可しても汎用 SaaS は社内文脈に弱く、用途を絞りづらい
- 自社開発は毎回ゼロから作る形になりやすく、長期・高コストになりやすい
- 結果として、各社が共通化されていない開発を重複しがち
- 解釈 「全社共通の AI 利用基盤」が標準化されていれば、各社の重複投資は減らせる可能性がある
共通土台で何が変わるか
- 事実 源内Web に SSO・監査ログ・チーム管理・AI アプリ管理を内蔵
- 事実 業務別 AI アプリを REST 連携で追加・差し替え可能
- 解釈 自社AIポータルの実装コストを下げる選択肢になりうる
- 期待効果 管理されていない AI 利用を抑制しやすくなる運用設計が組める
- 期待効果 業務別 AI アプリを差し替え・拡張しやすい構成にできる
源内Web は「利用者の窓口」、業務別 AI アプリは「中身」
源内は 源内Web（Web アプリケーション）と 行政実務用 AI アプリ（マイクロサービス）の 2 種類で構成される。窓口側は組織共通の機能、中身側は業務単位で増やしたり差し替えたりする想定だ。
源内Web — 利用者向けの Web アプリ
事実 チーム管理、AI アプリ管理、外部マイクロサービスとして構築した生成 AI アプリの追加・実行機能を備える。事実 デジタル庁デザインシステム適用 + アクセシビリティ試験 + 運用監視を整備。
行政実務用 AI アプリ — 業務別マイクロサービス
事実 生成 AI を活用したマイクロサービス群。事実 源内Web から外部 REST API として呼び出せる構成。
JSON 定義 × REST API 連携
事実 AI アプリ登録時にリクエスト形式を JSON で定義する。解釈 プロトコルと JSON 定義に準拠していれば外部の業務 AI アプリも追加しやすい構成と読める。
運用 — 監視・モニタリング
事実 監視・モニタリング等の運用機能追加が説明されている。解釈 商用導入を想定した運用設計の足場が用意されていると読める。
期待効果 業務シナリオの一例：契約・規程レビュー補助、議事録作成、社内 FAQ など、用途別の AI アプリを並べる構成が考えられる。具体的な工数削減効果は対象業務・運用設計・評価基準に依存するため、PoC で検証することが前提となる。
利用者 → 源内Web → 業務別 AI アプリ → クラウド/AIモデル/データ
3 階層で考えると分かりやすい。利用者の窓口は源内Web に統一され、その奥で業務別の AI アプリがそれぞれのクラウド・AI モデル・自社データに接続される。
- チーム管理（組織 / 部署）
- AI アプリ管理（公開 / 権限）
- 外部 AI アプリの追加・実行
- 監視・モニタリング
- 業務単位のマイクロサービス
- JSON でリクエスト形式を定義
- 源内Web に動的に追加可能
- 同じ REST API 仕様で接続
- 差し替え・拡張しやすい
- 自社業務向けの AI アプリも追加可
- Azure OpenAI 等
- Vertex AI / Gemini 等
- Bedrock / 自社モデル等
解釈 構造上、窓口（Web）と中身（業務別 AI アプリ）を分離しているため、AI アプリ単位で AI モデル・クラウド・データ連携の選択ができる。「特定のクラウドや AI モデルへの依存を下げやすい」構成、と表現するのが正確。
何が公式事実で、どこからが企業側の期待か
情報を読み解くときに混ざりがちな 3 種類の言明（公式に確認できる事実 / 技術的に妥当な解釈 / ビジネス上の期待効果）を、はっきり分けて並べる。意思決定にあたっては「事実」だけが土台で、それ以外は仮説として扱う。
- デジタル庁が開発・運用する生成 AI 利活用基盤
- 源内Web と行政実務用 AI アプリで構成される
- 源内Web にチーム管理 / AI アプリ管理 / 外部 AI アプリの追加・実行機能
- Software は MIT License、Documentation は CC BY 4.0
- 2026 年度に全府省庁約 18 万人を対象とした大規模実証を実施予定
- Web 画面と業務別 AI アプリを分けることで、AI アプリを追加・差し替えしやすい
- チーム管理や AI アプリ管理により、社内 AI 利用の統制を設計しやすい
- 外部 REST API 連携により、自社業務向け AI アプリを接続する入口になり得る
- バラバラな AI 利用の抑制
- AI 利用基盤の共通化
- 業務別 AI アプリの内製検証
- 特定ベンダーや特定クラウドへの依存低減
期待効果は「実現する」ではなく「期待できる」「可能性がある」「設計しやすい」という形で扱う。導入判断は、自社の検証結果と運用設計に基づくべき。
同じ「源内」でも、立場ごとに見える価値が違う
経営 / 情シス・CISO / 開発 / 現場の 4 つのレイヤーそれぞれの視点で、源内が何の選択肢になり得るかを整理する。期待効果 の表現に留め、実績や保証ではない。
- AI 投資の重複削減を検討しやすい
- 全社の AI 利用を標準化する選択肢になる
- 特定サービスへの依存低減を図りやすい
- チーム管理・AI アプリ管理で公開範囲を制御
- 利用状況の可視化と監査しやすい運用
- 管理されていない AI 利用を抑制しやすい運用設計
- Web 画面と業務別 AI アプリを分離して開発
- 外部 REST API 連携で機能追加
- JSON 定義に基づく接続設計
- 共通ポータル経由で AI を利用
- 業務別の専用 AI アプリを選んで使える
- 個人の汎用ツール利用に頼らずに済む
源内は「土台」。運用・設計・コストは各社側にも残る
「OSS で公開されている」ことと「すぐに使える」ことは別だ。源内をベースに据える場合に、社内検討の前段で確認しておくとよい項目を 6 つに整理する。
SSO・SAML 設定は自社の認証基盤に合わせた個別作業が必要。「設定するだけ」ではない。
権限設計、チーム設計、監査ログの保持・出力先を、自社のセキュリティ方針に合わせて決める必要がある。
API 利用料、クラウド費用、ホスティング・運用監視費用は別途発生する。ライセンス料の有無と総コストは別の話。
共通実装を参照しつつ、脆弱性対応・アップデート追随・運用責任は利用者側にも残る。SBOM やパッチ運用設計が前提。
AI 出力の正確性は別問題。評価設計と人間のレビュー設計（精度 / 回答根拠 / 例外フロー / 利用ガイドライン）を業務単位で組む必要がある。
自社データを使う場合、データの権限・整備状況・更新頻度・品質管理の設計が必要。データ品質を整えないまま接続しても効果は得にくい。
情報収集から、検証の段階へ
「源内すごい」で止めず、自社で評価するために置きにいくべき4 つの作業に落とし込む。OSS であるからこそ、検証は短いサイクルで回せる。
共通の土台が公開されたことで、議論は「作るかどうか」から、「どこから検証し、何を自社で管理するか」に移る。— 源内 (GenAI) OSS 公開、2026-04-24 デジタル庁