自治体におけるガバメントAI「源内」OSS活用の意味

デジタル庁がガバメントAI「源内」の一部をOSSとして公開したことで、自治体の生成AI導入は新しい段階に入りつつあります。これまで自治体が生成AIを導入する際には、個別にツールを選定し、セキュリティや運用ルールを一から検討する必要がありました。しかし、政府が実装を進めてきた行政向け生成AI基盤の一部が参照可能になったことで、自治体は「どのような構成で安全にAIを使うか」を具体的に検討しやすくなっています。

デジタル庁は、2026年度に全府省庁の約18万人の政府職員を対象とした大規模実証を予定しており、その一環として源内の一部を商用利用可能なライセンスのもとで無償公開しました。(デジタル庁) また、源内は行政職員が業務特化の生成AIアプリケーションを迅速かつ安全に利用できる環境として説明されています。(GitHub)

ただし、OSSが公開されたからといって、自治体がそのまま導入すればよいわけではありません。むしろ重要なのは、源内を「完成品」として見るのではなく、自治体が自らのネットワーク環境、情報管理規程、業務フローに合わせて検討するための参照実装として捉えることです。本記事では、提供資料をもとに、自治体が源内OSSを活用する際の技術要件、運用課題、予算配分、ガバナンス設計を整理します。

ガバメントAI「源内」とは何か

ガバメントAI「源内」は、デジタル庁が開発・運用する生成AI利活用基盤です。一般的なチャットAIのように単発の質問回答を行うだけでなく、行政実務に合わせたAIアプリケーションを利用できる点に特徴があります。デジタル庁のGitHubでは、源内WebがAWSのOSS「Generative AI Use Cases（GenU）」をベースに、チーム管理、AIアプリ管理、外部マイクロサービス連携、デジタル庁デザインシステムの適用、監視・モニタリング機能などを加えたものとして説明されています。(GitHub)

自治体にとって重要なのは、源内が単なるAIチャット画面ではなく、組織内で生成AIを使うための「基盤」として設計されている点です。職員ごとの権限管理、業務別AIアプリの提供、ログ管理、セキュリティ対策、マルチクラウド対応など、実務導入に必要な論点が含まれています。

一方で、OSS公開の範囲は源内のすべてではありません。公開されたコードやテンプレートを利用する場合でも、自治体側でクラウド環境、認証基盤、ネットワーク、運用ルールを整える必要があります。ここを見落とすと、「無料で使えるはずだったのに、実際には運用できない」という状態になりかねません。

自治体が確認すべき源内OSSの技術要件

フロントエンドは最新技術への対応が前提になる

提供資料では、源内Webのフロントエンド技術として、React 19、Vite 8、Tailwind CSS 4、Zustand 5、React Router 7、Biome、Vitest、TypeScript 6.xなどが挙げられています。これは、従来の行政システムで多く見られる保守中心の構成とは異なり、比較的新しいWeb技術スタックを前提にしていることを意味します。

この点は、自治体にとって大きな確認ポイントです。OSSを導入するには、単にソースコードを入手するだけでなく、その技術を理解し、改修・保守できる人材または外部パートナーが必要です。特に、アクセシビリティ、UI改善、権限管理、業務画面の追加などを行う場合、フロントエンド技術への理解が欠かせません。

自治体が導入を検討する際には、「この技術スタックを自庁で扱えるか」「委託先が継続的に保守できるか」「将来のバージョンアップに追随できるか」を確認する必要があります。

バックエンドはサーバーレス構成が中心になる

源内のインフラ構築には、AWS Cloud Development Kit（CDK）を用いたInfrastructure as Codeの考え方が取り入れられています。構成要素としては、CloudFront、API Gateway、Cognito、DynamoDB、Lambda、Amazon Bedrockなどが挙げられています。

この構成の利点は、利用量に応じた柔軟な拡張がしやすいことです。職員数が少ない自治体でも小さく始めやすく、利用が広がれば段階的にスケールさせることができます。一方で、クラウド設計、権限設定、ログ管理、障害対応、コスト管理の知識が求められます。

特に自治体では、導入時の構築費だけでなく、月額利用料、監視費用、保守費用、セキュリティレビュー費用を見込むことが重要です。OSSであることは「ソフトウェアライセンス費が不要になる可能性がある」という意味であり、運用コストがゼロになるわけではありません。

マルチクラウド対応と自治体ごとの選択肢

源内は、AWSだけでなく、AzureやGoogle Cloudを含むマルチクラウド対応の考え方を持っています。提供資料では、AWS向けには行政実務用RAG、Azure向けにはLLMセルフデプロイ、Google Cloud向けには法制度AIのような構成例が整理されています。

自治体にとって、これは大きな意味があります。すでに契約しているクラウド基盤、既存の認証基盤、セキュリティポリシー、庁内の技術人材によって、最適な構成は変わるからです。たとえば、Microsoft Entra IDを中心に庁内認証を整備している自治体であれば、Azure系の設計が検討しやすい場合があります。一方、既にAWS上でシステムを運用している自治体であれば、AWS構成のほうが導入しやすい可能性があります。

ただし、マルチクラウド対応は「どのクラウドでも同じように簡単に使える」という意味ではありません。クラウドごとにネットワーク、認証、ログ、暗号化、AIモデル利用条件、費用体系が異なります。そのため、自治体はクラウド選定を機能比較だけで決めるのではなく、既存環境との親和性、調達のしやすさ、長期運用の体制まで含めて判断する必要があります。

LGWAN環境での利用は最大の実務課題になる

自治体が源内OSSを検討するうえで、最も大きな壁になりやすいのがLGWAN環境との接続です。提供資料では、源内は基本的にインターネット接続を前提としたアーキテクチャであり、LGWAN内端末から直接アクセスすることは困難であると整理されています。

これは非常に重要です。自治体の業務端末は、マイナンバー利用事務系、LGWAN接続系、インターネット接続系などに分離されていることが多く、AI基盤をどの領域で利用するかによって設計が大きく変わります。インターネット接続系で使うのか、LGWAN環境から安全に接続するのか、あるいは閉域網や専用線を組み合わせるのかを明確にしなければなりません。

LGWAN環境から源内を利用する場合、専用線やVPNによる接続、CloudFrontを介さない通信経路の設計、ファイアウォール設定、API GatewayやLambdaの構成変更などが必要になる可能性があります。つまり、OSSをそのまま導入するのではなく、自治体のネットワーク分離方針に合わせたカスタマイズが前提になります。

この点を曖昧にしたまま調達を進めると、導入後に「庁内端末から使えない」「セキュリティ審査を通らない」「追加改修が必要になる」といった問題が生じます。調達仕様書の段階で、LGWAN対応の範囲を明確に書くことが欠かせません。

セキュリティとデータ保護で確認すべき項目

多層防御と通信の安全性

行政機関が生成AIを利用するうえで、セキュリティは最重要項目です。提供資料では、WAF、CloudFront、API Gateway、GuardDuty、暗号化、KMS、CMEKなどの対策が整理されています。これらは、外部からの不正アクセスやサイバー攻撃、データ漏えいリスクを低減するための基本的な仕組みです。

自治体が確認すべきなのは、これらの機能が「存在するか」だけではありません。実際にどの通信経路で使われるのか、ログはどこに保存されるのか、誰が監視するのか、障害発生時に誰が対応するのかまで決める必要があります。

特に生成AIでは、入力データに機密情報や個人情報が含まれるリスクがあります。住民情報、相談記録、契約情報、未公開資料などをAIに入力してよいのかどうかを、事前に分類しておかなければなりません。

認証基盤との統合

源内OSSの導入では、職員が安全にログインし、適切な権限でAIアプリを利用できる仕組みが必要です。提供資料では、SAML 2.0やOpenID Connectへの対応、Microsoft Entra IDなどとの連携が論点として挙げられています。

これは、自治体の実務では非常に重要です。職員の異動、退職、兼務、外部委託先の利用などが発生するため、アカウント管理が曖昧だと情報漏えいにつながる可能性があります。AI基盤だけを個別のIDで運用すると、退職者アカウントの残存や権限過多が起きやすくなります。

そのため、既存の認証基盤と統合し、職員属性や所属部署に応じて利用できるAIアプリを制御する設計が望まれます。生成AIの導入は、単なるツール導入ではなく、ID管理の見直しとセットで考えるべきです。

OSS利用で見落とされやすい責任分界

源内OSSは、自治体にとって有用な参照実装です。しかし、OSSである以上、利用者側に一定の責任が生じます。提供資料では、MITライセンスや無保証の原則、脆弱性対応、継続的なメンテナンスの責任が論点として整理されています。

ここで重要なのは、「国が公開したものだから安全に使える」と短絡しないことです。OSSは自由に利用・改変できる一方で、導入後の設定ミス、脆弱性対応、アップデート、障害対応は利用者側で管理する必要があります。

自治体は、導入前に責任分界を明確にする必要があります。たとえば、次のような項目です。

• ソースコードの改修責任は誰が持つのか
• セキュリティパッチの適用は誰が行うのか
• AIモデルの選定責任は誰が負うのか
• ログの監査はどの部署が担当するのか
• 誤回答が発生した場合、業務上どのように確認するのか

この整理がないまま導入すると、問題が起きたときに「システム部門の責任なのか」「利用部署の責任なのか」「委託先の責任なのか」が曖昧になります。生成AI活用では、技術導入と同じくらい責任設計が重要です。

自治体に必要な生成AI運用ルール

機密情報と個人情報の入力ルール

自治体がまず定めるべきなのは、AIに入力してよい情報と入力してはいけない情報の区分です。住民の個人情報、税情報、福祉相談、入札情報、人事情報などは、慎重な取り扱いが必要です。

「個人情報は入力しない」という一般論だけでは、現場では判断できません。たとえば、氏名を削除した相談記録は入力してよいのか、庁内資料の要約は可能なのか、未公開の条例案は対象にできるのかといった具体例が必要です。

運用ルールは、禁止事項だけでなく、使ってよい業務例も示すべきです。文書のたたき台作成、公開資料の要約、議事録の整理、FAQ案の作成、研修資料の構成案など、比較的リスクの低い用途から始めることで、現場に定着しやすくなります。

ハルシネーション対策と人による確認

生成AIは、もっともらしい誤回答を出す可能性があります。そのため、行政判断に直結する業務では、AIの出力をそのまま採用してはいけません。特に、法令解釈、補助金要件、住民への回答、契約文書、議会答弁などでは、人による確認が不可欠です。

自治体の運用ルールでは、「AIは補助者であり、最終判断者ではない」という位置づけを明確にする必要があります。AIの回答を使う場合は、根拠資料を確認する、担当者がレビューする、必要に応じて専門部署に照会する、といった手順を定めるべきです。

予算配分は「システム導入費」だけで考えない

生成AI導入で失敗しやすいのは、予算の大半をシステム構築費に使い、職員研修や運用改善に十分な費用を残さないケースです。提供資料では、成果を出すための費用配分モデルとして、システム・ツール導入費40％、人材育成・研修費30％、業務改善・運用費30％という考え方が示されています。

この配分は、自治体DXにおいて現実的な視点です。生成AIは、導入しただけでは成果が出ません。職員がどの業務で使うのか、どうプロンプトを作るのか、誤回答をどう見抜くのか、業務フローにどう組み込むのかを学ぶ必要があります。

また、AI活用によって業務改善を進めるには、現場ヒアリング、業務棚卸し、利用ログ分析、改善サイクルの設計が欠かせません。AI導入を「情報システム部門の案件」として閉じるのではなく、総務、企画、政策、福祉、建設、教育などの利用部署を巻き込むことが重要です。

調達仕様書に源内OSSをどう位置づけるか

自治体が源内OSSを活用する場合、調達仕様書での書き方が重要になります。単に「源内を導入すること」と書くのではなく、「源内OSSを参照し、自治体のネットワーク環境、認証基盤、セキュリティ要件に適合する形で構築すること」といった表現が望まれます。

また、LGWAN対応、クラウドリージョン、ログ保存、バックアップ、脆弱性対応、問い合わせ対応、職員研修、運用マニュアル、プロンプト利用ルールなども仕様に含める必要があります。

特に、OSSを利用する場合は、どの部分をそのまま使い、どの部分を改修するのかを明確にしなければなりません。改修部分が増えれば、将来のOSS更新に追随しにくくなる可能性があります。自治体は、短期的な導入のしやすさだけでなく、長期的な保守性も考える必要があります。

自治体が取るべき導入ステップ

自治体が源内OSSを参考に生成AI基盤を導入するなら、いきなり全庁展開を目指すべきではありません。まずは小さく始め、検証しながら広げることが現実的です。

第一に、利用対象業務を限定したPoCから始めることです。たとえば、公開資料の要約、庁内FAQ作成、議事録整理、研修資料作成など、リスクが比較的低く効果を確認しやすい業務が適しています。

第二に、ネットワークと認証の設計を先に固めることです。LGWANから使うのか、インターネット接続系で使うのか、どの職員が利用できるのかを決めずに導入を進めると、後から大きな手戻りが発生します。

第三に、運用ルールと研修を同時に整備することです。AIの使い方だけでなく、入力禁止情報、出力確認、著作権、個人情報保護、ログ管理まで含めて、職員が判断できる状態を作る必要があります。

第四に、自治体間で知見を共有することです。源内OSSの価値は、一つの自治体だけで閉じるよりも、複数自治体が導入課題や改善例を共有することで高まります。共通する課題を横展開できれば、重複開発や重複調達を減らせる可能性があります。

まとめ：源内OSSは自治体DXの近道だが、運用設計なしでは機能しない

ガバメントAI「源内」のOSS公開は、自治体にとって大きな機会です。政府が実装を進める生成AI基盤の一部を参照できることで、自治体はゼロから設計する負担を減らし、行政実務に即したAI活用を検討しやすくなります。

しかし、源内OSSはそのまま導入すれば成果が出る魔法のツールではありません。技術スタック、クラウド構成、LGWAN対応、認証基盤、セキュリティ、責任分界、運用ルール、職員研修を総合的に設計する必要があります。

自治体が目指すべきなのは、「AIを導入した」という状態ではなく、「職員が安全に使いこなし、住民サービスや業務改善につなげる」状態です。そのためには、小さく始め、検証し、ルールを整え、自治体間で知見を共有する姿勢が欠かせません。

源内OSSは、自治体が生成AIを自分たちの業務に合わせて育てていくための重要な参照点です。今後は、技術導入だけでなく、調達仕様書、職員研修、利用ログ分析、AIガバナンスまで含めた実践的な導入モデルの検討が求められます。