公共システムとは？官庁系・自治体系の違いと開発会社の選び方

公共システムは、国の府省庁や地方公共団体が行政サービスを提供するために使う情報システムの総称です。民間の基幹システムとの違いは、機能要件の検討と並行して、法令に沿った契約方式と、発注団体のセキュリティポリシーに適合するネットワーク構成を確認する必要がある点です。定義と官庁系・自治体系の区分、契約方式、WTO政府調達協定の基準額、三層対策のネットワークモデル、開発会社を選ぶときに公開情報で確認できる指標までを、条文と告示に当たって整理します。

まとめ｜公共システムの発注と受注で先に確定させる4点

発注側は要件定義より先に基準額と契約方式を確定させてください。ここが決まらないと公告期間もスケジュールも引けません。受注側は、資格が無ければ入口で参加できないため、資格の種類・等級・有効年度の確認が最初の作業になります。

公共システムの定義と、官庁系・自治体系という2つの区分

公共システムという語は法令用語ではなく、実務上の呼び分けです。発注元がどこかで、適用される制度がまるごと入れ替わります。

官庁系システムと自治体系システムの分かれ目

官庁系には国の府省庁や独立行政法人が発注する案件があります。国の契約には会計法と予算決算及び会計令が適用され、独立行政法人の契約には各法人の会計規程等が適用されます。税務、社会保険、統計、許認可、防災などを扱います。対象人数や可用性の要求は業務ごとに異なるため、利用者数、処理件数、稼働時間を個別に確認します。

自治体系は都道府県・市区町村が発注するもので、地方自治法と同法施行令に従います。住民基本台帳、税、国民健康保険、介護保険、生活保護といった基幹業務のほか、公共施設予約、電子申請、図書館、学校の校務支援まで幅が広い。同じ「住民税の計算」でも団体ごとに条例で減免規定が違うため、全国共通の仕様に落とし込みにくいという構造的な難しさがあります。

発注機関の数と業務範囲も違います。ただし国にも小規模案件があり自治体にも大規模案件があるため、発注主体だけで案件規模を判断しないでください。

民間の基幹システムとの比較｜調達・予算・仕様・利用者

公共システムは利用主体や公共性による分類、基幹システムは業務上の役割による分類で、両者は重なります。機能面では会計や人事のように似た業務も多く、差は制度側に出ます。

とくに重いのが3つめです。税制改正や制度改正が決まれば、施行日までに必ず動く状態にしなければならず、しかも改正内容が確定するのは施行の直前ということが珍しくない。要件が外部から降ってくるうえに納期が動かせないため、改修余力をあらかじめ契約に織り込んでおく設計が要ります。

SI業界における公共系の対象業務と設計上の制約

SI業界では、金融系・産業系と並べて「公共系」という分野呼称が使われます。指しているのは発注元が官公庁・自治体である案件群で、技術スタックの分類ではありません。長期運用が前提で、制度改正対応が定期的に発生します。法定要件は条文で確認できる一方、その要件自体は発注側の判断でも変えられません。画面設計や実装方式には選択の余地が残ります。業界別の要件の違いは金融・公共・流通系のシステム開発とは？業界特化の要件と外注先の選び方で横断的に整理しています。

公共システム調達の契約方式・基準額・予算制度

公共システムでは、技術的な要件に加えて、契約方式や予算制度への対応が開発計画を左右します。

会計法・地方自治法による契約方式の原則と例外

国の契約は会計法29条の3第1項が「契約担当官及び支出負担行為担当官（以下「契約担当官等」という。）は、売買、貸借、請負その他の契約を締結する場合においては、第三項及び第四項に規定する場合を除き、公告して申込みをさせることにより競争に付さなければならない」と定めています。つまり一般競争入札が原則です。指名競争は同条3項の「契約の性質又は目的により競争に加わるべき者が少数で第一項の競争に付する必要がない場合」など、随意契約は同条4項の「契約の性質又は目的が競争を許さない場合、緊急の必要により競争に付することができない場合及び競争に付することが不利と認められる場合」に認められます。このほか同条5項に基づく少額契約等の例外もあります。

自治体は地方自治法234条1項が「売買、貸借、請負その他の契約は、一般競争入札、指名競争入札、随意契約又はせり売りの方法により締結するものとする」とし、2項で「前項の指名競争入札、随意契約又はせり売りは、政令で定める場合に該当するときに限り、これによることができる」と絞っています。ここでも一般競争入札が原則です。

見落とされやすいのが234条3項のただし書で、「予定価格の制限の範囲内の価格をもつて申込みをした者のうち最低の価格をもつて申込みをした者以外の者を契約の相手方とすることができる」と定めています。総合評価落札方式、つまり価格だけでなく技術点で選ぶ入札の根拠がここにあります。品質も評価したい発注側は、評価項目と配点を落札者決定基準として定め、仕様書の要求事項と対応付けてください。価格点と技術点の配分や評価値の計算式は、総合評価落札方式の解説で試算つきで整理しています。

国の少額随意契約の基準額は令和7年4月1日に改正されています。予算決算及び会計令99条の基準額を超える契約は、予定価格が工事・製造契約で400万円超、財産購入で300万円超、物件借入れの予定賃借料の年額または総額で150万円超、役務等で200万円超となる契約です。情報システム開発を役務として調達する場合、200万円以下なら少額随意契約が可能ですが、200万円超でも別の随意契約事由に該当する場合があります。

誤解されやすいのがプロポーザル方式の位置づけです。デジタル庁の調達手続マニュアルは、プロポーザル型企画競争を「競争性のある随意契約」と区分しています。入札の一種ではなく随意契約の一形態なので、採用には会計法29条の3第4項の要件を満たす理由づけが要ります。総合評価落札方式を使う場合も、同庁は「特別な理由がない限り、情報システム等の調達では、過剰な低入札価格の影響を受けにくい加算方式を採用することが多くなっています」としており、同庁の情報システム等の調達では加算方式が基本ですが、得点配分は適用する基準と案件の評価項目に応じて設定します。

WTO政府調達協定の基準額と、適用される団体の範囲

予定価格が一定額以上になると、WTO政府調達協定に基づく特例手続が上乗せされます。基準額は2年度ごとに改定され、令和8年度・令和9年度分は令和8年1月30日付の告示で次のとおり定まりました。

国の基準額は財務省告示第28号、自治体の基準額は総務省告示第35号（いずれも令和8年1月30日）によります。自治体側の前回値は物品等・その他のサービスがともに3,600万円だったので、4,000万円へ引き上げられた計算です。基準額をまたぐかどうかで手続が変わります。デジタル庁の場合、WTO対象の入札公告期間は原則50日以上で、条件を満たせば短縮できます。自治体は公告媒体も期間も団体ごとに違うため、日程は個別に確認してください。

適用団体の範囲にも注意が要ります。地方公共団体の物品等又は特定役務の調達手続の特例を定める政令（平成7年政令第372号）は、適用対象を特定地方公共団体（都道府県・指定都市）と中核市に限り、13条でこれらが加入する一部事務組合・広域連合には準用しないと定めています。一般の市町村が発注する数千万円のシステム案件は、この特例政令の対象にはなりません。

実務で効くのが同政令5条1項です。特定地方公共団体の長は所在地に関する資格を「定めることができない」とされ、地元業者に限る運用が使えません。中核市は同条2項の別扱いで、所在地要件を定めた場合に欧州連合等の供給者を資格保有者として扱う義務を負います。所在地以外の参加条件は案件ごとに違うので、公告での確認は必要です。同政令はほかに、最低制限価格制度の不適用（9条）、随意契約事由の制限（11条）も定めています。

複数年契約の予算措置と長期継続契約の適用条件

自治体の予算は単年度主義です。地方自治法214条は「歳出予算の金額、継続費の総額又は繰越明許費の金額の範囲内におけるものを除くほか、普通地方公共団体が債務を負担する行為をするには、予算で債務負担行為として定めておかなければならない」と定めています。開発が2か年にまたがる、あるいは5年の運用保守を一括で契約する、といった場合は債務負担行為を予算に計上しておく必要があり、これは議会の議決事項です。

例外として234条の3の長期継続契約があり、「電気、ガス若しくは水の供給若しくは電気通信役務の提供を受ける契約又は不動産を借りる契約その他政令で定める契約」は翌年度以降にわたって締結できます。地方自治法施行令167条の17が定める物品借入れ・役務提供の条件の範囲内で各団体が条例を定めるため、機器の賃貸借や役務提供型の保守を長期継続契約で処理できるかは団体ごとに違う。ここを確認せずに5年契約を前提に見積もると、契約段階で単年度契約へ組み替えることになり、価格の前提が崩れます。

発注時期にも癖があります。当初予算で措置された案件を年度開始後に公告し、年度内の稼働を求められて実装期間が圧縮されやすい。この構造は発注側の努力だけでは解けないので、要件定義を前年度に別契約で切り出し、開発は翌年度に発注する二段階の組み方が現実的な回避策になります。

公共システムのネットワークとセキュリティ要件

自治体系のシステムでは、機能要件よりネットワーク区分のほうが設計への影響が大きくなります。総務省の地方公共団体における情報セキュリティポリシーに関するガイドライン（令和8年度版）が示す三層対策が前提だからです。

三層対策とαモデル

三層対策は2015年の日本年金機構の情報流出事案を受けて総務省が要請したもので、平成30年9月改定でガイドラインに反映されました。中身は次の3つです。

• マイナンバー利用事務系では、端末からの情報の持ち出し不可設定等を講じ、住民情報の流出を徹底して防止する
• LGWAN接続系とインターネット接続系を分割し、LGWAN環境のセキュリティを確保する
• 都道府県と市区町村が協力して自治体情報セキュリティクラウドを構築し、高度なセキュリティ対策を実施する

この3層を維持し、主たる業務端末をLGWAN接続系に置いてインターネットとは接続しない構成がαモデルです。市町村の大多数はいまもこの状態にあります。開発する側から見ると、αモデルの環境に納めるシステムは外部SaaSとの直接連携ができず、ファイルの受け渡しも無害化処理を挟むことになるため、一般的なウェブアプリの前提がそのまま通りません。

β・β’モデルの配置と技術的・組織的な採用条件

令和2年度のガイドライン改定で、利便性を高めるために業務端末をインターネット接続系へ配置するβモデルとβ’モデルが示されました。ただし、どちらも無条件ではありません。

提案時に誤解が起きやすい箇所です。β’モデルは技術的対策だけでなく、発注側の組織的・人的対策が揃っていることを条件にしています。監視を誰がどの時間帯で回すか決まっていない団体にβ’前提の構成を出しても、調達の段階で成立しません。提案前に対象団体のモデルを確認し、移行を伴うなら体制整備まで射程に入れてください。文書管理システムのようにモデル選択が要件に直結する領域は、自治体向け文書管理システムの選び方｜公文書管理条例と電子決裁・LGWAN要件で個別に扱っています。

α’モデルとクラウドサービスの利用

αモデルのままウェブ会議などの特定クラウドサービスを使いたい、という需要に応えて、令和6年10月の改定でα’モデルが追加されました。LGWAN接続系から特定のクラウドサービスに直接接続する、いわゆるローカルブレイクアウトの構成です。総務省の資料は接続先として「ISMAPクラウドサービスに登録されているサービス」を挙げており、実際に接続できる範囲は団体のセキュリティポリシーで決まります。

公共向けにSaaSを提供する側にとって、ISMAP登録の有無は機能比較以前の足切り条件になり得ます。自社サービスを自治体へ提案するなら、対象団体の接続方式を確認し、ISMAP登録が要る場合の期間と費用を事業計画に織り込んでください。標準準拠システムをガバメントクラウド上で動かす場合の接続要件はガバメントクラウドとは？自治体が使う仕組み・対象サービス・費用負担を解説【2026年版】にまとめています。

公共システム開発会社の選定基準

「公共システム 開発会社」で情報を探す人の多くは比較記事にたどり着きますが、掲載されている実績の裏取りまではできません。公共調達は結果が公開される制度なので、公開情報だけで確かめられる項目があります。

入札参加資格の種類・等級・地域・有効年度

国の物品・役務の競争入札では、原則として全省庁統一資格が必要です。「物品の製造・販売等」に係る一般競争（指名競争）入札の参加資格を統一の基準で審査するもので、申請は調達ポータルから行い、いずれかの申請受付窓口で資格を得れば、希望した地域の各府省庁の調達機関で有効になります。現在有効なのは競争参加者の資格に関する公示（令和07・08・09年度）に基づく資格で、等級の算出方法は同公示の別記4・別記5に定められています。

物品の製造・販売と役務の提供等はA・B・C・D、物品の買受けはA・B・Cに分かれ、案件ごとに参加できる等級が指定されます。実績が多い会社でも、申請している資格の種類が案件と合っていなければ参加できません。システム開発は「役務の提供等」のうちソフトウェア開発・情報処理の区分にあたります。発注側が特定の会社に声をかけたい場合も、その会社が該当年度・該当地域・該当種類の資格を持っているかが先決です。

自治体側は団体ごとに入札参加資格審査を実施し、名簿に登載された事業者が参加できます。所在地要件が外れるのは前述の特定調達だけなので、参加条件は案件ごとに公告で確認してください。

落札結果による受注分野・規模・契約範囲の確認

各府省庁の調達情報は調達ポータルから検索できます。特例政令12条による落札者等の公示義務は、都道府県・指定都市の特定調達が対象です。それ以外は各団体の公表制度を確認します。提案書に書かれた「自治体での豊富な実績」を鵜呑みにせず、団体名と年度で落札実績を引いて、次の3点を見てください。

• 類似の業務分野で、実際に元請として落札しているか（再委託先としての参画は公示に出ません）
• 落札した案件の規模が、今回の案件と同程度か。小規模案件の積み上げと大規模案件の経験は別物です
• 同じ団体での継続受注に加え、契約件名・仕様書から運用保守の担当範囲を確認できるか

確認にかかる時間は、候補社数や各団体の公開状況で変わります。比較サイトの掲載順だけでなく、落札結果と契約範囲を判断材料にしてください。

保守・運用契約の改修範囲・障害対応・引継ぎ条件

公共システムの選定では、稼働後の運用期間と更改時期まで確認します。制度改正が繰り返される業務では、開発力に加えて制度改正への追随体制を選定基準に入れてください。

• 法改正に伴う改修の扱い。定額の保守料に含むのか、その都度見積もるのかを契約書で切り分けておく
• 障害時の連絡経路と復旧目標。住民向けサービスは受付時間外の障害も発生するため、平日日中のみのサポートで足りるかを業務時間から逆算する
• 担当者交代時の引き継ぎ。長期運用では開発時の要員が交代する可能性があるため、体制図上の役割と引き継ぎ手順を契約に書いておく

自治体のDX支援業務そのものを委託する場合は、事業者の類型と委託範囲の線引きが選定の前提になります。判断の順番は自治体DX支援企業の選び方と委託範囲の線引きにまとめました。

公共システム開発の失敗を防ぐ要件確認・資料確保・体制整備

ここでは、要件の根拠確認、移行に必要な資料の確保、発注側の判断体制という、契約前から対処できる論点を扱います。

条例・規則に基づく要件の確認と仕様書への記録

ヒアリングで得た業務フローだけを要件にすると、後から「規則にこう書いてある」と差し戻されます。自治体の業務は根拠が条例・規則・要綱にあり、担当者の説明はその運用解釈にすぎません。減免、還付、時効、端数処理については、例規集と関係法令を確認し、仕様書に法令・条例名、条番号、施行日、対応する処理とテストケースを記録してください。根拠を明示しておけば、担当者が異動しても仕様の意図が引き継がれます。

遅延のもう一つの主因が関係機関との調整です。国のシステムとの連携、指定金融機関との調整、他部署とのデータ受け渡しは相手側の年間スケジュールに縛られるため、要件定義の初日に洗い出し、相手の締め切りから逆算してマイルストーンを引きます。

ベンダーロックインの要因とデータ・仕様書の確保

ベンダーロックインは、独自技術への依存、知的財産権の制約、データ構造や仕様書の不足などによって起きます。ここでは、発注側が仕様書を確保できていない場合を取り上げます。次期更改のRFPを書こうにも現行のテーブル定義が分からず、現行事業者にしか移行費用を見積もれない、という状態です。

契約時にデータ定義書とインターフェース仕様書を成果物として明記し、著作権の帰属と第三者への開示可否を条項で決めておく。稼働中もデータ構造の変更時にエクスポート手順を実行し、出力項目・所要時間・欠損の有無を次期移行の見積もり資料に残してください。基幹業務については国が標準仕様を定める形で構造的な対策が進んでおり、その到達点と残された論点は自治体システムの標準化とは？20業務の移行と期限経過後の実務を解説で扱っています。

発注側の要件判断担当者と業務・技術の責任分担

丸投げに近い形になると、提案の妥当性を評価できず、価格の根拠も検証できません。すべてを内製する必要はありませんが、業務の例外パターンを説明し見積もりの前提を確認する担当者は発注側に置いてください。実装方式の評価は技術担当者が支援し、要件変更の承認者も明確にします。

体制づくりは1つの案件では完結しません。人材・予算・調達制度の制約を先行団体がどう組み替えたかは自治体DXの課題と事例｜人材・予算・レガシー・調達制度を先行団体の打ち手で解くにまとめています。

費用の考え方と、見積もりで確認する項目

費用を比較する際は、対象人口・業務範囲・移行データ量を揃える必要があります。条件が異なる案件の総額だけでは、自団体の予算を判断できません。見積もりを読むときの分解のしかたを示します。

予算超過の典型はデータ移行とテストです。どちらも既存データの品質に左右され、着手して初めて分量が分かる。契約前に現行データのサンプルを提示し、移行対象件数と例外データの割合、見積もりを変更する条件を双方で合意してください。

よくある質問

公共システムとは何を指しますか？

国の府省庁や地方公共団体が行政サービスの提供に使う情報システムの総称です。法令用語ではなく実務上の呼び方で、発注元が国なら官庁系、地方公共団体なら自治体系と区分されます。住民基本台帳や税のような基幹業務のほか、公共施設予約システムとは？自治体の抽選・減免・公金収納から選ぶ判断基準で扱う施設予約や、電子申請、校務支援なども含みます。

公共システムと基幹システムはどう違いますか？

公共システムは利用主体と公共性による分類、基幹システムは業務上の役割による分類なので、両者は重なります。違いは制度側で、契約方式が会計法29条の3や地方自治法234条で定められ、予算は単年度主義に縛られ、仕様の変更が法令・条例の改正で外から決まります。法定の処理や施行期限は動かせませんが、画面設計や実装方式には選択の余地があります。

公共システムのネットワークはどうなっていますか？

自治体系では、マイナンバー利用事務系・LGWAN接続系・インターネット接続系に分ける三層対策が前提です。業務端末をインターネットから切り離すαモデルのほか、条件を満たせば業務端末をインターネット接続系に置くβモデル、業務システムまで置くβ’モデル、LGWAN接続系から特定クラウドへ直接接続するα’モデルがあります。どのモデルを採用しているかで、システムの構成も外部連携の可否も変わります。

官公庁のシステム開発に参入するには何が必要ですか？

国の物品・役務の競争入札では、原則として全省庁統一資格が必要で、調達ポータルから申請できます。現在有効なのは令和07・08・09年度の公示に基づく資格で、種類（システム開発なら役務の提供等）と等級、希望地域の指定が案件と合っている必要があります。工事は統一資格の対象外です。自治体の案件は団体ごとの入札参加資格審査を受けます。電子申請システムとは？自治体・官公庁の導入判断と構築方式の選び方のような個別分野から入るのも現実的な進め方です。

公共系のシステム開発はどのような仕事ですか？

発注元が官公庁・自治体である案件群を指す業界内の呼び方です。開発に加え、稼働後の運用保守と法改正に伴う改修を担当します。要件の根拠が法令・条例として公開されているため適合を条文で確認でき、法令が定めていない画面や実装方式は発注側と受注側で判断します。制度を読む力が実装力と同じくらい効く領域です。

関連記事

• 自治体システムの標準化とは？20業務の移行と期限経過後の実務を解説
• ガバメントクラウドとは？自治体が使う仕組み・対象サービス・費用負担を解説【2026年版】
• 自治体DXの課題と事例｜人材・予算・レガシー・調達制度を先行団体の打ち手で解く
• 金融・公共・流通系のシステム開発とは？業界特化の要件と外注先の選び方
• 自治体向け文書管理システムの選び方｜公文書管理条例と電子決裁・LGWAN要件