自治体のOSS調達では「公開後」まで仕様化する必要がある
自治体の情報システム調達では、特定の製品や事業者に依存せず、他の自治体でも再利用できるソフトウェア資産を整備する考え方が重要になっています。
本記事では、自治体が開発委託や内部開発によって生み出し、庁内や他自治体で共有・再利用するOSSを、資料に合わせて「源内OSS」と呼びます。一般的な制度用語として定着している表現ではないため、実際の調達仕様書では「庁内・自治体発祥OSS」などの定義を明記しておくことが必要です。
OSSを活用する目的は、ライセンス費用を抑えることだけではありません。
ソースコードや技術情報を自治体側で管理し、保守事業者の変更や他自治体への横展開を可能にすることで、ベンダーロックインを抑えられる点に大きな意義があります。
一方、ソースコードを公開するだけでは、再利用可能な行政デジタル資産にはなりません。仕様書には、システム構造、著作権、OSSライセンス、セキュリティ、SBOM、保守体制、公開後の変更管理まで落とし込む必要があります。
デジタル庁でも、官公庁の情報システム調達におけるオープンソース化とOSS利活用について、公開範囲、調達要件、資産管理、組織体制などの検討が進められています。デジタル庁「オープンソース化・OSS利活用に関する有識者検討会」
最初に「何をどこまで公開するか」を決める
源内OSSの調達では、仕様書を書き始める前に、対象範囲と公開範囲を整理します。
公開範囲は、おおむね次の三段階に分けて検討できます。
庁内だけで共有する
複数部署でソースコードや共通部品を共有する形です。外部公開はしなくても、組織内で再利用できる状態にすることで、似たシステムの重複開発を抑えられます。
ただし、職員と受託事業者のアクセス権限、リポジトリの管理責任者、退職・異動時の権限削除などを定める必要があります。
他の自治体や行政機関と共有する
共同利用や横展開を目的として、限定された行政機関にソースコードを提供する形です。
この場合は、自治体固有の業務ルールや設定値をコードから切り離し、別の自治体でも変更しやすい構造にする必要があります。利用条件、問い合わせ窓口、改修成果の還元方法も決めておきます。
一般公開する
GitHubなどの公開リポジトリを通じて、民間企業や開発者も利用・改修できる状態にします。
一般公開には再利用や外部改善を促す効果がありますが、個人情報、認証情報、内部ネットワーク情報、脆弱性につながる設定などが混入していないか、公開前の検査が不可欠です。
公開範囲は一律に決めるのではなく、システムの目的、保有情報、セキュリティリスク、知的財産権などを踏まえて判断します。
調達前の要件アセスメントを実施する
仕様書策定の前に、業務、技術、運用、権利、セキュリティの各観点から現状を確認します。
再利用性を評価する
対象システムが、一つの自治体に固有の制度や業務フローへ過度に依存していないかを確認します。
自治体名、組織名、帳票様式、承認経路、コード体系などをソースコードに直接埋め込むと、他自治体での再利用が難しくなります。固有情報は設定ファイルやマスターデータとして分離できる設計が望まれます。
ソースコードそのものを公開しにくい場合でも、API仕様、データモデル、業務フロー、設定テンプレートなどを共通資産として公開できないか検討します。
TCOを算定する
OSSは無償で入手できても、運用コストがゼロになるわけではありません。
次の費用を含め、システムのライフサイクル全体で評価します。
- 導入・環境構築
- 既存システムからのデータ移行
- 職員研修
- OSSの更新と脆弱性対応
- 障害調査と復旧
- ドキュメントの整備
- 公開リポジトリの維持
- 保守事業者を変更する際の引継ぎ
初期価格だけで比較すると、公開後の維持管理費や技術者確保の負担を見落とす可能性があります。
サプライチェーンリスクを確認する
現代のシステムは、受託事業者が作成したコードだけでなく、多数のOSSパッケージや外部ライブラリで構成されています。
調達前に、使用予定のOSSについて、ライセンス、更新状況、メンテナー体制、既知の脆弱性、代替手段、サポートの有無を確認します。
IPAも、外部開発では納品物に含まれるOSSをSBOMなどで可視化し、ブラックボックス化を防ぐことが重要だと説明しています。IPA「OSS活用はコスト削減以上の戦略的選択」
要件管理表を作成して仕様書へ反映する
調達仕様書では、要求事項を文章として並べるだけでなく、要件管理表を作成します。
各要件には、少なくとも次の項目を設定します。
- 要件ID
- 要件の目的
- 必須要件・希望要件・評価要件の区分
- 受注者が提出する証拠
- 検査方法
- 合格基準
- 担当部署
- 変更履歴
- 関連するリスク
例えば「SBOMを提出すること」だけでは、納品形式や検査基準が分かりません。
「SPDXまたはCycloneDXなどの機械可読形式で、コンポーネント名、バージョン、ライセンス、依存関係、識別情報を含むSBOMを提出する」と具体化します。
さらに、設計、開発、試験、納品、運用の各工程で要件がどの成果物に反映されたかを追跡できるようにします。
調達仕様書に盛り込む主要要件
オープンなシステム構造
特定事業者だけが扱える独自仕様への依存を抑え、公開された標準仕様、API、データ形式を採用します。
仕様書には、次の要件を盛り込みます。
- システムを交換可能なモジュールに分割する
- 外部連携インターフェースの仕様を開示する
- 特定事業者の独自技術が必要な部分を明示する
- 設定情報とプログラムを分離する
- データを標準的な形式で出力できるようにする
- 別事業者が構築・保守できるドキュメントを納品する
ただし、公平な競争を妨げないよう、合理的な理由なく特定の製品名や特定のリポジトリサービスを必須指定することは避けます。
SBOMと脆弱性管理
SBOMは、システムに含まれるソフトウェア部品を把握するための基礎資料です。SBOMを納品させるだけで、安全性が保証されるわけではありません。
仕様書では、次の内容まで定めます。
- SBOMの対象範囲
- 提出形式と必須項目
- 作成・更新のタイミング
- 実際の納品物との照合方法
- 脆弱性情報の監視方法
- 影響調査の報告期限
- 修正、回避策、リスク受容の判断手順
- 保守終了時の最終SBOM引渡し
経済産業省とIPAは、SBOMについて、作成だけでなく共有、運用、管理を含む継続的な体制整備を示しています。経済産業省「SBOM導入に関する手引」、IPA「SBOM導入・運用の手引き」
SLAと保守体制
OSSは原則として無保証で提供されます。自治体システムとして安定運用するためには、受注者または保守事業者の責任範囲を契約で定める必要があります。
一律に「すべての脆弱性を直ちに解消する」と定めるのではなく、重要度、悪用可能性、システムへの影響、代替策の有無に応じて対応期限を設定します。
仕様書には、次の事項を記載します。
- 受付時間と連絡方法
- 障害の重要度分類
- 一次回答と暫定対応の期限
- 復旧目標
- 脆弱性発見時の報告期限
- 修正版または回避策の提供条件
- OSSのサポート終了時の対応
- 保守事業者変更時の引継ぎ義務
- 定期的な障害対応訓練
著作権とOSSライセンス
「成果物の著作権はすべて自治体に帰属する」とだけ記載しても、既存OSSや第三者のライブラリまで自治体に移転させることはできません。
仕様書と契約書では、少なくとも次の三つを区別します。
- 受注者が契約前から保有する既存資産
- 委託業務で新たに開発する成果物
- OSSを含む第三者の著作物
新規成果物の権利を自治体に移転する場合は、著作権法第27条・第28条に関する権利の取扱いも含め、契約部門や法務担当者と確認します。
OSSライセンスについては、MIT、Apache License 2.0、GPLなどの特徴を踏まえ、利用目的に合うものを選定します。コピーレフト型ライセンスを一律に排除するのではなく、既存ライセンスとの互換性や、改変物をどこまで共有したいかによって判断します。
また、ライセンス名、著作権表示、NOTICEファイル、変更履歴などを納品物として確認します。
公開リポジトリの管理
一般公開する場合は、ソースコードだけでなく、利用者が安全に理解・再利用できる情報を整備します。
- README
- LICENSE
- 利用・構築手順
- システム構成図
- API仕様
- CONTRIBUTING
- セキュリティ上の問題の報告方法
- サポート対象範囲
- 変更履歴
- 廃止方針
公開前には、認証情報、秘密鍵、個人情報、内部URL、テストデータなどが含まれていないかを確認します。シークレットスキャン、依存関係検査、コードレビューを公開前の必須工程にすることが重要です。
納品検査は「ファイルの有無」だけで終わらせない
納品検査では、成果物が提出されたかだけでなく、内容が仕様書の要件を満たしているかを確認します。
特に次の検査が重要です。
- SBOMと実際のソフトウェア構成の照合
- OSSライセンスと著作権表示の確認
- SCAによる既知脆弱性の検査
- 不要な外部通信やアクセス経路の検査
- 別環境での再構築試験
- データ出力・移行試験
- 運用手順書に基づく復旧試験
- 別の担当者がドキュメントだけで構築できるかの確認
- 公開前の機密情報・認証情報検査
検査結果は、要件IDと対応付けて記録します。不適合が見つかった場合は、修正期限、再検査方法、例外として受け入れる場合の承認者を明確にします。
公開後の維持管理まで調達範囲に含める
OSSは、公開した時点で完成するものではありません。
外部利用者からのIssueやPull Requestを誰が確認するのか、どのような基準で変更を取り込むのか、脆弱性をどのように通知するのかを決めておく必要があります。
公開後の管理項目には、次のものがあります。
- リポジトリ管理責任者
- Issueの受付・回答基準
- コード変更の承認者
- ブランチ保護と多要素認証
- リリース手順
- SBOMの更新
- 脆弱性情報の非公開受付
- バックアップまたはミラーの保管
- 長期間更新されない場合の廃止表示
- 他自治体が改修した成果の還元方法
他自治体で再利用された数だけでなく、更新継続率、脆弱性対応時間、重複開発の削減状況、保守事業者の選択肢などを評価指標にすると、OSS化の効果を検証しやすくなります。
源内OSSを持続させる組織体制
源内OSSの管理を個別の担当者だけに任せると、人事異動によって運用が止まる可能性があります。
情報政策部門、原課、契約部門、情報セキュリティ担当、法務・知財担当を含む横断的な管理体制が必要です。大規模な自治体では、OSSの選定、ライセンス確認、公開審査、コミュニティ対応を担うOSPO相当の機能も検討できます。
IPAの2025年度オープンソース推進レポートでも、OSSを単なるコスト削減手段ではなく、デジタル主権や持続可能なソフトウェア資産の基盤として捉える必要性が示されています。IPA「2025年度オープンソース推進レポート」
小規模自治体が単独で専門体制を整えることが難しい場合は、都道府県、近隣自治体、共同利用組織、外部専門家と連携し、ライセンス審査や脆弱性監視を共通化する方法があります。
まとめ
自治体の源内OSS調達では、「OSSを使用すること」や「ソースコードを納品すること」だけでは、再利用性と継続性を確保できません。
調達前に公開範囲とリスクを整理し、仕様書へ次の要件を具体的に落とし込む必要があります。
- オープン標準とモジュール化
- データとAPIの可搬性
- SBOMと脆弱性管理
- SLAと保守事業者の引継ぎ
- 著作権とOSSライセンス
- 公開前検査
- 公開後のリポジトリ運営
- 要件から検査結果までの追跡管理
重要なのは、OSS化そのものを目的にしないことです。住民サービスの改善、重複開発の抑制、事業者間の競争性、システムの継続性という行政上の目的から逆算して仕様を設計します。
JAICでは、自治体DXの構想整理、AI・情報システムの要件定義、セキュリティを含む運用体制の設計、人材育成まで、実務に即した支援を行っています。
※実際の調達仕様書および契約条項は、対象システムの性質や自治体の規程に合わせ、契約・法務・情報セキュリティの担当者や専門家による確認が必要です。
コメント