自治体の生成AI調達は「ツール選定」から「要件定義」へ
自治体における生成AI活用は、単にチャットAIを導入する段階から、庁内業務・住民サービス・文書管理・セキュリティを含めた基盤整備の段階へ移りつつあります。
デジタル庁は、地方公共団体や政府機関が安全・安心に生成AIを活用できる環境整備を目的として、ガバメントAI「源内」と同様の生成AI利用環境を構築可能なソースコード等をOSSとして公開しています。OSS化により、類似AI基盤の重複開発を防ぎ、特定ベンダーへの依存を抑えながら、各機関が自らの要件に応じてAI基盤を運用・発展させやすくなるとされています。
つまり、自治体の生成AI調達で重要になるのは、「どのAIサービスを買うか」だけではありません。どの業務に使い、どのデータを参照させ、どの情報を入力禁止にし、どの範囲まで事業者に責任を求めるのかを、調達仕様書に具体的に落とし込むことです。
ガバメントAI「源内」OSSとは何か
ガバメントAI「源内」は、政府職員向けの生成AI利用環境として整備が進められている取り組みです。デジタル庁の公表資料では、2026年度に全府省庁の約18万人の政府職員を対象とした大規模実証を開始するとされています。
また、デジタル庁の「源内」ページでは、2026年4月24日にOSS公開が行われたこと、2026年5月28日に大規模実証が開始されたことなどが整理されています。
自治体にとって重要なのは、源内OSSをそのまま使うこと自体ではなく、源内の考え方を調達仕様書の基準にできる点です。元資料では、源内OSSを活用した調達仕様書の記載例として、Webインターフェース、バックエンドAPI、RAG、権限管理、監査ログ、契約上の権利帰属、運用保守までを一体で整理する必要性が示されています。
調達仕様書に書くべき基本要件
基本システム構成を明記する
生成AIシステムの仕様書では、まずシステム全体の構成を明確にする必要があります。特に、利用者が操作するWeb画面と、生成AIやRAGと連携するバックエンド処理を分離して記載することが重要です。
仕様書には、たとえば「本システムは、ガバメントAI『源内』OSSのWebインターフェースを参考に、フロントエンドとバックエンドを疎結合な構成とする」といった形で、将来の機能追加やAIアプリの差し替えに耐えられる構成を求めるべきです。
これにより、特定のAIベンダーや単一アプリに閉じた導入ではなく、議事録作成、文書要約、条例検索、福祉相談支援など、業務ごとのAIアプリを段階的に追加できる余地が生まれます。
LGWANや庁内ネットワークでの利用条件を定義する
自治体業務では、住民情報、行政内部資料、要機密情報を扱う場面があります。そのため、一般的なクラウドサービスをそのまま導入するだけでは不十分な場合があります。
仕様書では、LGWAN接続環境、庁内ネットワーク、認証方式、利用端末、対応ブラウザ、アクセス制御の範囲を明確にする必要があります。特に、職員の所属部署や役職に応じて利用できる機能や参照できるデータを分けるロールベースのアクセス制御は、RAG活用時の基本要件になります。
RAG要件は「検索精度」より先に「権限管理」を書く
自治体の生成AI活用では、庁内文書をAIに参照させるRAGが注目されます。しかし、RAGで最初に詰めるべきなのは検索精度だけではありません。
より重要なのは、誰が、どの文書群を、どの範囲で参照できるかです。人事情報、福祉情報、契約情報、防災情報、庁内規程などは、同じ庁内文書であっても機密度が異なります。
仕様書には、PDF、Word、Excelなどの庁内文書をデータ連携できることに加え、フォルダ単位・部署単位・利用者単位でアクセス権限を設定できることを記載する必要があります。また、RAGの回答には参照元文書を表示できること、誤回答や古い文書の参照を抑制するために文書更新管理ができることも重要です。
RAGは「便利な検索機能」ではなく、庁内ナレッジをAIで扱うための情報統制の仕組みとして設計すべきです。
セキュリティ要件は入力禁止情報まで具体化する
生成AI調達では、セキュリティ要件を抽象的に書くと、導入後の運用で必ず迷いが出ます。仕様書では、少なくとも次のような要件を具体化する必要があります。
入力されたプロンプト、アップロードされたファイル、RAG連携データ、生成された回答が、AI提供事業者のモデル学習に使われないこと。データの保管場所が国内であること。個人情報やマイナンバー、要機密情報、発注者が定める禁止ワードが入力された場合に、警告または送信制限ができること。利用ログ、アクセスログ、生成履歴を取得し、必要に応じて監査できること。
デジタル庁は2026年6月12日に「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（第2.0版）」を策定しており、生成AI関連技術の進展やユースケース拡大、国内外の制度的・政策的動向を踏まえた改定であると説明しています。
自治体が調達仕様書を作成する際は、このような国の最新ガイドラインを前提に、高リスク利用、要機密情報、契約チェック、監査対応を仕様に反映させることが欠かせません。
契約要件では「入力・出力・ノウハウ」の権利帰属を分けて書く
生成AIシステムの調達で曖昧にしやすいのが、契約上の権利帰属です。
仕様書や契約書では、少なくとも「インプット」「インプットの処理成果」「アウトプット」「ノウハウ」を分けて定義する必要があります。
インプットとは、自治体が提供するプロンプト、庁内文書、RAG参照データなどです。これは原則として自治体に帰属し、事業者が目的外利用やモデル学習に使わないことを明記すべきです。
アウトプットとは、AIが生成した要約、翻訳、回答、文案などです。第三者の権利を侵害しない範囲で、自治体が庁内外の業務に利用できるようにしておく必要があります。
ノウハウについてはさらに注意が必要です。自治体固有の業務知識やプロンプト設計の知見が、事業者側に流出するリスクがあります。一方で、事業者が持つ汎用的な技術ノウハウまで自治体が独占するのは現実的ではありません。両者を切り分け、自治体固有の知見は発注者に帰属する形で整理することが望まれます。
運用保守・研修・料金体系まで仕様に含める
生成AIは、導入して終わりのシステムではありません。庁内文書の更新、RAGデータの追加、プロンプトテンプレートの改善、利用ログの確認、職員研修、問い合わせ対応を継続することで、はじめて効果が出ます。
仕様書には、ヘルプデスク対応、障害時対応、RAGデータ登録支援、職員向け研修、プロンプトテンプレート提供、利用状況レポート、改善提案の頻度まで含めるべきです。
また、生成AIはトークン数や文字数によって費用が変動しやすいため、完全従量課金では予算超過のリスクがあります。自治体調達では、固定料金を基本とし、超過利用時の協議ルールや上限管理の仕組みを明記しておくことが現実的です。
自治体の生成AI調達で失敗しないための視点
自治体の生成AI導入で失敗しやすいのは、AIツールの機能比較だけで調達を進めてしまうことです。
本来見るべきなのは、自治体業務に合わせて安全に運用できるか、庁内データを適切に扱えるか、将来のAIアプリ追加に対応できるか、契約上の責任範囲が明確か、職員が継続的に使える支援体制があるかです。
源内OSSの価値は、単なる無償ソフトウェアではありません。自治体が生成AI基盤を調達する際に、共通のアーキテクチャ、API、セキュリティ、契約要件を参照できる「ものさし」になる点にあります。
まとめ：源内OSSは自治体AI調達の共通言語になる
地方自治体が生成AIを調達する際は、流行のAIサービスを導入するのではなく、庁内業務に耐えるAI基盤として要件定義する必要があります。
ガバメントAI「源内」OSSは、重複開発の抑制、ベンダーロックインの回避、調達仕様書の具体化、AIアプリの段階的追加という点で、自治体調達の重要な参考になります。
今後の自治体AI調達では、RAG、権限管理、監査ログ、入力禁止情報、契約上の権利帰属、運用研修、料金管理までを一体で設計できるかが問われます。生成AIを安全に使う自治体ほど、調達仕様書の解像度が高くなるはずです。
コメント