データ連携プラットフォームの自治体事例6選｜基盤構築の手順

自治体のデータ連携は、庁内の基幹業務システムをつなぐ話と、官民のデータを地域で流通させる話が同じ言葉で語られがちです。情報政策課が検討する「連携基盤」と、スマートシティ部門が検討する「連携基盤」は、目的も設計の勘所も異なります。この2つを分けずに検討を始めると、要件定義の段階で論点が混ざり、ベンダー提案の比較もできなくなります。

庁内連携では標準準拠システムへの移行に伴う過渡期の対応が、地域連携ではデータ提供元の確保と同意の設計が、それぞれ最初のつまずきどころです。どちらも技術より先に、対象業務の棚卸しと運用ルールの設計で成否の大半が決まるのが実情です。

本記事では、自治体のデータ連携基盤を庁内連携と地域連携の2層で整理し、構築の5つのSTEPと失敗パターン、6つの事例を解説します。ガバメントクラウド移行やスマートシティの検討を進める際の判断材料として、ご活用ください。

自治体のデータ連携プラットフォームとは：庁内連携基盤と地域データ連携基盤の2層で捉える

自治体で「データ連携プラットフォーム」と呼ばれる仕組みは、大きく2つの層に分かれます。1つは住民記録や税、福祉などの基幹業務システムと電子申請、職員のExcel業務をつなぐ庁内の層です。もう1つは、庁内で整理したデータを交通事業者や医療機関などの民間データと組み合わせ、地域で流通させる層です。ここでは2つの層それぞれの役割と、両者をどうつなぐかを順に整理します。

庁内データ連携基盤：基幹業務システム・電子申請・Excel業務をつなぐ仕組み

庁内データ連携基盤の役割は、業務システム間のデータ受け渡しを人手に頼らず自動化することです。たとえば電子申請で受け付けた転入届の内容を住民記録システムへ取り込み、異動結果を国保や介護のシステムへ反映させる、といった流れを担います。対象となるシステムは、県庁規模で150〜250、中核市規模でも50〜100程度に達することが多く、連携の組み合わせは数百単位に膨らむのが実情です。この量を個別のインターフェース開発でさばくと、改修のたびに費用と期間が積み上がります。

構成要素は、連携の指示を受け取る受付機能、データ形式を変換する変換機能、宛先へ配信する配信機能、そして実行履歴を残すログ機能の4つが基本です。実務で見落とされやすいのがログ機能で、どの職員がいつどのデータを流したかを追跡できないと、監査対応や障害時の原因特定に時間がかかります。既存の連携ツールを選ぶ際は、画面上で実行履歴を検索し、失敗したジョブを再実行できるかを必ず確認してください。この確認を怠ると、夜間バッチの失敗を翌朝の電話で知る運用が続きます。

データ統合とは？統合の目的や初心者向けの進め方を解説

地域データ連携基盤：都市OSとして官民・分野横断でデータを流通させる仕組み

地域データ連携基盤は、内閣府のスマートシティリファレンスアーキテクチャで都市OSと位置づけられる仕組みです。交通、防災、観光、医療といった分野ごとに分かれていたデータを共通のAPIで取り出せるようにし、民間事業者や大学がサービスを作れる状態を目指します。庁内連携基盤との最大の違いは、データの提供元と利用者が自治体の外にも広がる点です。このため、技術仕様よりも先に「誰がどのデータを、どの条件で提供するか」の合意形成に時間を割く必要があります。

実装面では、FIWAREをはじめとするオープンソースの基盤や、国内ベンダーが提供する都市OS製品が選択肢になります。判断基準は明確で、自前で技術者を確保できる、または地域の大学や企業と開発を分担できる体制があればオープンソース、運用を外部に任せる前提なら製品型が向いている構成です。費用感は、初期構築で数千万円から、年間運用で数百万〜1,000万円超の幅があり、データの種類と接続先の数で大きく変わるのが実態です。先行自治体の公開資料を確認すると、接続先が10を超えたあたりから運用費が急増する傾向が読み取れます。

パーソナルデータの連携基盤とは？セキュリティ対策と導入ポイント

2層の関係：庁内で整理したデータを地域基盤へ安全に流す構造

2つの層は独立した仕組みではなく、庁内連携基盤で整えたデータが地域データ連携基盤へ流れる構造として設計すると無理がありません。住民情報を扱う基幹系ネットワークから直接外部へデータを出すことはできないため、間に加工・匿名化を行う中間領域を置き、統計化や仮名化を済ませたデータだけを地域基盤へ渡します。この中間領域が「どこに置かれ、誰が管理するか」が設計上の分岐点です。多くの自治体ではLGWAN接続系に中間領域を設け、情報政策課が管理する形を採っています。

図で整理する場合は、左に基幹系、中央にLGWAN接続系の中間領域、右に地域基盤を並べる形です。データが左から右へ一方向に流れる矢印を描くと、関係者の理解が早まります。現場でよくあるつまずきは、地域基盤の構築を先に決め、後から「基幹系のデータが出せない」と判明するケースです。回避策として、企画段階で情報セキュリティ担当を同席させ、対象データごとに流せる経路を確認する会議を1回設けてください。この1回の確認で、要件定義の手戻りを数か月単位で防げます。

自治体でデータ連携基盤が求められる背景と導入効果

データ連携基盤の検討が加速している背景には、国の制度変更と自治体内部の人員事情という2つの要因があります。制度面では基幹業務システムの標準化とガバメントクラウド移行、デジタル田園都市国家構想が同時に進み、内部要因では職員減少と手作業の限界が重なっているのが現状です。それぞれの要因が現場にどのような課題を生み、基盤導入でどこまで解消できるのかを見ていきます。

基幹業務システムの標準化とガバメントクラウド移行で生じる「過渡期連携」の課題

基幹業務システムの標準化では、住民記録や税など20業務のシステムを標準仕様に準拠した製品へ移行します。ただし全業務が同時に切り替わるわけではなく、移行時期がずれた業務同士をつなぐ過渡期連携が発生するのが実態です。移行済みの標準準拠システムと、未移行の現行システムの間でデータ形式が異なるため、変換を挟まないと連携が成立しません。移行期間が1〜3年にわたる自治体も多く、この間の連携をどう維持するかが情報政策課の実務課題になっています。

対応の選択肢は、現行ベンダーに個別改修を依頼する方法と、変換機能を持つ連携基盤を間に置く方法の2つです。判断基準として、未移行業務が3つ以下で移行完了まで1年以内なら個別改修、それ以上の規模や期間なら連携基盤を置く方が総費用を抑えられます。現場でよくあるつまずきは、個別改修で始めたものの移行スケジュールが延び、改修費が当初見積もりの2倍以上に膨らむケースです。移行計画を立てる段階で、遅延した場合の追加費用を試算し、連携基盤方式との比較表を作っておいてください。

データ要件・連携要件標準仕様書が前提とする連携方式

デジタル庁が公開するデータ要件・連携要件標準仕様書は、標準準拠システム同士が連携する際のデータ項目と連携方式を定めています。前提となる方式はファイル連携で、業務ごとに定義された機能別連携仕様に沿ったCSV形式のファイルをやり取りする方式です。この仕様はガバメントクラウド上の共通機能として整備されるため、自治体が独自にAPIを設計する必要はありません。重要なのは、仕様書で定義されたファイルレイアウトを前提に、庁内の独自システムや外部連携側の設計を合わせることです。

仕様書は定期的に改定され、文字コードや項目の追加が行われます。実務では、改定のたびに影響範囲を確認する作業が発生するため、連携基盤側で「仕様書バージョンごとの変換定義」を管理できるかを選定時に確認してください。確認方法は簡単で、ベンダーに「仕様書の改定時に変換定義の差分をどの画面で確認できるか」を質問し、デモで見せてもらえば判断できます。この質問に即答できないベンダーの製品は、改定対応が手作業になり、年1〜2回の改定ごとに数十万円規模の追加費用が発生しやすくなります。

デジタル田園都市国家構想とスマートシティリファレンスアーキテクチャの要請

デジタル田園都市国家構想では、地域課題をデジタルで解決する取り組みに交付金が充てられ、その多くでデータ連携基盤の整備が採択要件に含まれています。内閣府のスマートシティリファレンスアーキテクチャは、都市OSが備えるべき機能として、データ仲介、認証・認可、サービス連携などを定めています。交付金の申請時には、この構造への準拠を説明することが条件です。要するに、補助制度を使って地域基盤を整えるなら、アーキテクチャの用語と機能区分を押さえた計画書が求められます。

申請実務でよくあるつまずきは、基盤の機能一覧だけを並べ、どの地域課題をどのデータで解くかが書かれていないケースです。審査では「データ連携によって何が変わるか」が問われるため、対象サービスを2〜3個に絞り、使うデータと提供元を具体名で書く方が採択率が上がります。計画書を書く前に、リファレンスアーキテクチャの図を印刷し、自分たちの基盤がどの箱に該当するかを色分けしてみてください。空白の箱が多ければ、それは申請前に埋めるべき検討事項です。

職員減少とIT人材不足：手作業の転記・二重入力が限界を迎えている

自治体職員の総数は長期的に減少しており、業務量は増える一方で、システム間の転記や二重入力を人手でこなす余力が失われています。たとえば電子申請の内容を職員が画面を見ながら基幹システムへ打ち直す運用では、1件あたり3〜5分、月1,000件なら50〜80時間が転記だけに消える計算です。転記ミスによる差し戻しや再確認の時間を含めると、実際の負荷はさらに大きくなります。この作業を連携基盤で自動化すると、職員の時間を相談対応や審査に振り向けられます。

IT人材の不足も深刻で、情報政策課の職員が2〜3名、しかも数年で異動する自治体は珍しくない状況です。この体制で個別のインターフェースを保守し続けるのは現実的ではなく、設定を画面上で管理できる連携基盤へ集約する方が、引き継ぎの負担も減ります。現場でよくあるつまずきは、自動化の効果を測らずに導入し、議会や財政課への説明で成果を示せないケースです。導入前に対象業務の処理件数と1件あたりの作業時間を記録しておき、導入後に同じ指標で比較できるようにしてください。

自治体DXとは？推進ステップと、デジタル化を成功させる7つのポイント

導入効果：ワンストップ化・業務効率化・EBPM・ベンダーロックイン解消

連携基盤の導入効果は、住民側と庁内側の両方に表れます。住民側では、1つの申請で複数の手続きが完了するワンストップ化が進み、窓口での待ち時間や再来庁が減少するのが利点です。庁内側では転記作業の削減に加え、複数システムのデータを組み合わせた分析が可能になり、根拠に基づく政策立案を意味するEBPMの土台が整います。ベンダー面では、連携の仕様が基盤側に集約されるため、特定ベンダーの製品を外しにくい状態、いわゆるベンダーロックインの解消にもつながります。効果は次の4つです。

• ワンストップ化：転入・転出や出生に伴う複数手続きを1回の申請で処理し、来庁回数を削減する
• 業務効率化：転記・二重入力を自動化し、月数十〜数百時間の職員工数を他業務へ振り向ける
• EBPM：福祉・教育・税のデータを横断集計し、施策の対象者数や効果を数値で把握する
• ベンダーロックイン解消：連携仕様を基盤側に集約し、システム更新時の乗り換え障壁を下げる

効果を数値で示す際は、導入前後で同じ指標を使うことが原則です。たとえば「転記時間を月80時間から10時間に削減」「転入手続きの平均滞在時間を40分から20分に短縮」のように、計測方法を決めてから導入すると説明に困りません。EBPMの効果は短期では測りにくいため、まずは横断集計に要する日数を「依頼から2週間」から「即日」へ短縮する、といった業務指標に置き換えて示してください。議会説明では、削減した時間を人件費に換算した金額も併記すると説得力が増します。

自治体のデータ連携基盤を構築する5つのSTEP

連携基盤の構築は、製品選定から入ると失敗しやすく、対象業務とデータの棚卸しから始めるのが定石です。ネットワーク配置、データ標準化、連携方式の選定、運用設計という順序で進めると、要件の手戻りを最小限に抑えられます。各STEPで実際に使う様式や判断基準、目安となる期間を示しながら解説します。

STEP1：対象業務とデータの棚卸し：連携頻度・方向・機密区分を整理する

最初に行うのは、連携候補となる業務とデータを一覧にする棚卸しです。様式はExcelで十分で、列には「業務名」「送り元システム」「送り先システム」「データ項目」「連携頻度」「連携方向」「機密区分」「現在の受け渡し方法」を設けます。連携頻度は即時・日次・月次の3区分、機密区分は個人情報・要配慮個人情報・非個人情報の3区分で記入すると、後の設計で使いやすくなります。この一覧を各課へ配布し、2〜3週間で回収するのが現実的なスケジュールです。

現場でよくあるつまずきは、各課が「現在手作業で行っている受け渡し」を連携対象と認識せず、記入漏れが多発することです。回避策として、記入依頼の際に「USBメモリや紙で他課へ渡しているもの」「月末にExcelで集計して送っているもの」と具体例を挙げてください。回収後は、連携頻度が日次以上で件数が月100件を超えるものから優先順位を付けると、効果の大きい業務から着手できます。棚卸しの段階で優先候補を5〜10業務に絞っておくと、後続のSTEPが進めやすくなります。

STEP2：ネットワーク配置の設計：三層分離とガバメントクラウド接続を前提にする

自治体のネットワークは、個人番号利用事務系、LGWAN接続系、インターネット接続系に分ける三層分離が前提です。連携基盤をどの層に置くかで、扱えるデータと接続できるシステムが決まります。基本配置は、住民記録や税を扱うなら個人番号利用事務系、電子申請や業務支援システムとつなぐならLGWAN接続系、民間データと組み合わせるならインターネット接続系です。複数の層にまたがる場合は、層ごとに基盤の機能を分け、間に無害化や承認の仕組みを挟みます。

ガバメントクラウドへ移行した標準準拠システムとの接続では、ガバメントクラウド接続回線を経由するため、既存の庁内ネットワークとは別に接続経路の設計が必要です。実務では、クラウドサービス事業者の提供する接続サービスの帯域と、連携するファイルの容量・頻度を突き合わせ、夜間バッチが時間内に収まるかを確認します。現場でよくあるつまずきは、帯域の試算をせずに日次連携を設計し、ファイル転送が朝の業務開始に間に合わないケースです。移行前に、最大容量のファイルを実際に転送して所要時間を計測しておいてください。

STEP3：データ標準化とコード統一：文字コード・住所表記・コード体系をそろえてから突合する

複数システムのデータを突き合わせる前に、形式をそろえる標準化が必要です。自治体で特に問題になるのが外字で、戸籍や住民記録で使われる独自の文字は、システムごとに異なるコードが割り当てられています。文字情報基盤（MJ文字）への対応状況をシステムごとに確認し、外字の変換表を先に作るのが実務の第一歩です。住所表記も「1丁目2番3号」「1-2-3」「１－２－３」が混在するため、全角半角の統一と番地の分割ルールを決めてから突合に進みます。

コード体系では、同じ「性別」や「世帯主区分」でもシステムごとに1・2や01・02、M・Fといった値が使われています。標準化の作業は、対象項目ごとに変換表をExcelで作り、連携基盤の変換定義へ登録する流れです。項目数が50を超える場合は、変換表の管理を連携基盤の画面で行える製品を選ぶと保守が楽になります。標準化を終えてから氏名・生年月日・住所で同一人物を特定する名寄せに進むのが正しい順序で、逆にすると突合漏れが数％単位で発生します。

名寄せとは？正確な顧客データ管理の方法と活用ポイントを徹底解説

STEP4：連携方式の選定：ファイル連携・API連携・連携ツールの使い分け

連携方式は、ファイルを決まった場所に置いて受け渡すファイル連携、システム同士がリアルタイムに通信するAPI連携、そして変換や配信を画面で設定できる連携ツールの3つに大別されます。標準準拠システム同士はファイル連携が前提ですが、電子申請からの即時反映や外部サービスとの接続ではAPI連携が求められます。実務では1つの方式に統一するのではなく、業務ごとに使い分けるのが現実的です。判断基準を表で整理します。

選定の目安として、連携先が5システム以下で全てバッチ処理ならファイル連携のみで十分です。即時性が求められる業務が1つでもあればAPI連携を組み合わせ、連携先が10を超えて方式が混在するなら連携ツールの導入を検討してください。現場でよくあるつまずきは、API連携を選んだものの、相手システムのAPI仕様が非公開で追加費用を請求されるケースです。選定前に相手システムのベンダーへ「API仕様書の開示可否と利用料」を文書で確認しておくと、見積もりの段階で判断できます。

STEP5：スモールスタートと横展開：運用ルール・エラー通知・変更管理を整える

構築は全業務を一度に対象とせず、効果が見えやすい1〜2業務から始めるスモールスタートが基本です。最初の対象は、STEP1で優先度を付けた業務のうち、関係課が協力的で、月の処理件数が多いものを選びます。立ち上げ期間は、対象業務が2つなら要件定義から本番稼働まで3〜6か月が目安です。この期間で運用ルールを固めてから、残りの業務へ横展開すると、2巡目以降は1業務あたり1〜2か月で追加できるようになります。

運用ルールで最低限決めるのは、エラー発生時の通知先と対応手順、連携定義を変更する際の承認フロー、月次での実行結果の確認方法の3点です。エラー通知は担当者個人のメールではなく、課の共有アドレスへ送る設定にしないと、異動のたびに通知が止まります。変更管理では、変更内容・理由・承認者・実施日を記録する台帳をExcelか連携基盤の機能で用意してください。現場でよくあるつまずきは、本番稼働後に通知設定を見直さず、エラーが数週間気付かれないケースです。稼働後1か月の時点で、通知が実際に届いているかを確認する日程をあらかじめ入れておきましょう。

データ分析基盤とは？基盤を構築するための5つのステップ

自治体のデータ連携でよくある失敗パターン

連携基盤の失敗は、技術的な不具合よりも、検討順序や体制の設計に起因するものが大半です。先行自治体の報告や支援現場で繰り返し見られる失敗は、おおむね5つの型に分類できます。それぞれどの段階で起き、どうすれば避けられるかを具体的に示します。

標準準拠システムの連携仕様を確認せず独自連携を作り込む

ガバメントクラウド移行前に庁内連携を整備した自治体で起きやすいのが、独自のデータ項目や形式で連携を作り込み、標準準拠システムへ移行した途端に動かなくなる失敗です。標準仕様書で定義された項目名や桁数と異なる前提で変換定義を作っていると、移行後に全ての定義を作り直す必要が生じます。件数が多い自治体では、作り直しに数か月と数百万円規模の費用がかかった例もあります。移行前に整備した連携ほど、この見直しが丸ごと発生する点に注意してください。

回避策は、連携設計の初期段階で標準仕様書の機能別連携仕様を参照し、項目名と形式を仕様書に合わせておくことです。具体的には、デジタル庁のサイトから最新版の仕様書をダウンロードし、対象業務の連携ファイルのレイアウトを変換定義のひな形として使います。現行システムが仕様書と異なる項目を持つ場合は、現行側を変換して仕様書形式に寄せる方向で設計すると、移行後の修正が最小限で済みます。仕様書は改定されるため、設計時に参照したバージョンを設計書の表紙に明記しておいてください。

都市OSを先に構築してデータ提供元が集まらない

スマートシティ系の失敗で最も多いのが、交付金を使って都市OSを先に構築したものの、載せるデータが集まらず、利用されないまま運用費だけが発生する状態です。民間事業者にとってデータ提供は、提供コストと情報漏えいのリスクを負う行為であり、自治体側が明確な利用目的と提供条件を示さなければ協力は得られません。基盤が完成してから提供元を探し始めると、交渉に1年以上かかり、その間に基盤の更新時期が来てしまいます。

回避策は、構築の前に「このサービスのために、このデータを、この事業者から」という組み合わせを最低3つ確定させることです。確定の基準は、提供元の担当者と提供条件を書面で合意できた状態とし、口頭の前向きな返事は数に入れません。実務では、地域の交通事業者や商工会議所、大学など、すでに自治体と協定を結んでいる組織から当たると合意が早く進みます。提供元が確定してから、そのデータ形式に合わせて基盤の要件を書く順序を守ってください。

外字・コード体系の不一致で名寄せが破綻する

庁内で複数システムのデータを突き合わせる際、外字やコード体系の不一致を放置したまま名寄せを行うと、同一人物が別人として扱われたり、別人が同一人物と判定されたりします。たとえば「髙」と「高」、「﨑」と「崎」が別コードで登録されていると、氏名による突合が成立しません。住所でも、旧住所のまま更新されていない台帳と、最新の住所を持つ台帳を突き合わせると、世帯単位の集計がずれるのが典型例です。こうした不一致は件数全体の2〜5％程度に及ぶことが多く、放置すると給付対象の漏れや重複につながります。

対策は、名寄せの前に外字変換表とコード変換表を作成し、突合キーを氏名だけでなく生年月日と住所コードの組み合わせにすることです。突合結果は「完全一致」「候補一致」「不一致」の3区分に分け、候補一致は職員が目視で確認する運用にします。候補一致の件数が全体の1％を超える場合は、変換表の不備が疑われるため、名寄せを止めて変換表を見直してください。マスタデータの管理ルールを整備しておくと、こうした不一致の再発を防げます。

マスタデータ管理（MDM）とは？適切に運用する重要性とその手法を解説

担当者の異動で連携フローが属人化し保守できなくなる

自治体では2〜4年で担当者が異動するため、連携の設定や運用手順が個人の記憶に依存していると、引き継ぎの時点で保守が止まります。特にスクリプトで連携処理を組んでいる場合、作成者が異動した後に誰も修正できず、仕様変更のたびにベンダーへ依頼して費用がかさむ状態に陥ります。連携定義がどこにあり、何をしているのかを新任者が1週間以内に把握できなければ、属人化していると判断してください。判断の目安として、設定変更の依頼が特定の職員にしか来ない状態も属人化のサインです。

対策として、連携定義ごとに「目的」「送り元と送り先」「実行タイミング」「エラー時の対応」「最終変更日と変更者」を記載した一覧を作り、連携基盤の画面か共有フォルダで管理します。一覧の更新を変更管理の承認条件に組み込むと、記載漏れを防げる仕組みです。引き継ぎ時には、新任者が実際に1つの連携定義を変更し、テスト環境で動かす演習を行うと定着が早まります。この演習に半日を充てるだけで、異動後の問い合わせが大幅に減ります。

パーソナルデータの同意設計を後回しにして公開が止まる

地域データ連携基盤で住民の行動データや健康データを扱う場合、本人の同意をどう取得し、どう管理するかを決めずに構築を進めると、公開直前で法務確認に引っかかって停止します。個人情報保護法では、利用目的の特定と本人への通知が求められ、要配慮個人情報は原則として本人の同意なしに取得できない決まりです。自治体には個人情報保護条例もあり、条例で定めた審議会への諮問が必要なケースでは、諮問から答申まで2〜3か月を要します。

対策は、要件定義の段階で扱うデータを個人情報・仮名加工情報・匿名加工情報・統計情報に分類し、それぞれの取得根拠と同意の取り方を一覧にすることです。同意が必要なデータは、同意の取得画面と撤回の手続きまで設計に含めます。実務では、法務担当と個人情報保護担当を要件定義の会議に最初から参加させ、分類の妥当性を毎回確認する運用が確実です。公開の2か月前に法務確認を始める計画では間に合わないため、分類一覧の作成を構築開始前に終えておいてください。

パーソナルデータと個人情報の違いとは？取り扱いの注意点をわかりやすく解説

自治体のデータ連携基盤を成功させるポイント

失敗パターンの裏返しとして、成功している自治体には共通する4つの要素があります。推進組織と費用負担の仕組み、民間が使えるAPIとカタログの整備、法令対応を含むガバナンス、そして国が用意した調達支援ツールの活用です。順に、実務でどう整えるかを説明します。

推進組織と費用負担ルール：県・市町の共同利用や負担金方式を設計する

単独の市町村で連携基盤を構築・運用すると、初期費用と年間運用費の両方が重くのしかかります。この負担を軽くする手段が、県が基盤を整備して市町が共同利用する方式です。県が構築費を負担し、市町は利用するデータ量や人口規模に応じた負担金を払う形が一般的で、1市町あたりの年間負担を単独構築の数分の1に抑えられます。推進組織としては、県の情報政策部門が事務局となり、市町の担当者が参加する協議会を設け、年2〜4回の会合で利用ルールを決める体制が機能しやすい構成です。

負担金の算定方式は、均等割と人口割を組み合わせるのが実務上の落としどころです。均等割のみだと小規模町村の負担感が強く、人口割のみだと大規模市が参加をためらいます。協議会の立ち上げ時には、参加を見送る市町が出ても運営できる最低参加数を決めておき、途中参加の条件も文書化してください。現場でよくあるつまずきは、県が構築を先行させ、市町の参加表明が集まらず利用率が低迷するケースです。構築前に市町への意向調査を行い、参加意思のある市町と共同で要件を書く順序を守ると、利用率の問題を避けられます。

API公開ルールとデータカタログの整備：民間事業者が使える状態にする

地域データ連携基盤に載せたデータを民間事業者に使ってもらうには、API仕様の公開と利用申請の手順が整っていることが前提です。利用申請から承認までの日数、利用料の有無、利用規約の内容を公開サイトに明記し、申請書は電子フォームで受け付ける形が望ましい運用です。APIの仕様書はOpenAPI形式で公開すると、事業者側の開発者がツールで読み込めるため、問い合わせの数が減ります。承認までの標準日数は5〜10営業日を目安にし、それを超える場合は理由を通知するルールにしてください。

データカタログは、基盤にどのデータがあり、更新頻度や形式、利用条件が何かを一覧で示す仕組みです。カタログがないと、事業者は問い合わせなしにデータの有無を判断できず、利用が広がりません。項目は「データ名」「提供元」「更新頻度」「形式」「利用条件」「サンプルの有無」の6つを最低限とし、新しいデータを追加する際にカタログ更新を必須にする運用です。先行自治体のカタログを参考にし、自治体向けのオープンデータカタログサイトと項目をそろえておくと、横展開の際の手戻りを減らせます。

データカタログとは？必要な理由、作成手順、管理方法までを解説！

データガバナンス：改正個人情報保護法と条例への対応

自治体の個人情報の取り扱いは、改正個人情報保護法によって国の法律に一本化され、条例はその範囲内で定める形になりました。連携基盤の運用では、法で定める利用目的の特定、第三者提供の制限、安全管理措置を、基盤の機能と運用ルールの両面で満たす必要があります。たとえば第三者提供の記録は法で義務付けられているため、基盤のログ機能で提供先・提供日・提供したデータ項目を自動記録できるかを設計時に確認してください。手作業で記録する運用では、記録漏れが必ず発生します。

ガバナンス体制としては、データの所管課がデータごとの責任者となり、情報政策課が基盤全体の管理者、個人情報保護担当が法令適合の確認者を務める3者の役割分担が基本です。データを新たに連携対象に加える際は、この3者が承認する手続きを設け、承認記録を残します。チェックリストとして、利用目的の明記、提供先の範囲、保存期間、削除手順、問い合わせ窓口の5項目を承認時に確認する運用にすると、審査の抜けを防げます。年1回は連携対象データの一覧を棚卸しし、利用実績のないデータは連携を停止する判断も行ってください。

国のカタログ・ガイドブックの活用：デジタル庁のサービスカタログと内閣府ガイドブック

連携基盤の調達では、国が整備した資料を使うと、要件定義と製品比較の工数を大幅に減らせます。デジタル庁のデータ連携基盤のサービスカタログには、都市OSとして利用できる製品やサービスが機能ごとに整理されており、調達仕様書の機能要件を書く際のひな形として使える資料です。内閣府が公開するスマートシティのガイドブックには、推進体制の作り方や地域の合意形成の進め方が事例付きで記載されており、計画書の構成を検討する際の参考になります。

使い方の手順は、デジタル庁のサイトでサービスカタログの最新版を確認し、自分たちの対象サービスに必要な機能を一覧から選んで要件候補を作るところからです。候補となる製品を3〜5つに絞り、各ベンダーへ情報提供依頼を出す際に、カタログの機能区分を共通の様式として使うと、回答の比較が容易になります。現場でよくあるつまずきは、ベンダーの提案書をそのまま仕様書に転記し、特定製品にしか対応できない要件になるケースです。カタログの機能区分で要件を書き、製品固有の用語を仕様書に入れないよう確認してください。

自治体のデータ連携プラットフォーム事例6選：ガバメントクラウド・スマートシティ

ここからは、公開資料で確認できる取り組みをもとに、庁内連携の軸で3つ、地域連携の軸で3つの事例を紹介します。各事例は「抱えていた課題」「連携したデータ」「得られた成果」の順で整理し、自分たちの自治体に当てはめやすいよう、規模や方式の特徴を添えた形です。自治体名は公開資料に基づく概要として、規模区分で記載します。

事例1：ガバメントクラウド移行の過渡期連携：データ連携共通基盤でマルチベンダー対応を実現

首都圏の人口15万人規模の市では、基幹業務システムの標準化に伴い、複数ベンダーの標準準拠システムへ業務ごとに段階移行する方針を採りました。課題は、移行時期の異なるシステム間でデータ形式が食い違い、住民異動の情報が税や福祉のシステムへ正しく届かなくなる懸念でした。対応として、変換機能とログ機能を備えたデータ連携共通基盤をLGWAN接続系に配置し、移行済みと未移行のシステムの間に挟む構成です。基盤はベンダーに依存しない製品を選び、どのベンダーの標準準拠システムとも接続できる前提で調達しています。

連携したデータは住民異動、税の課税情報、各種給付の受給者情報で、日次のファイル連携を基本とした構成です。成果として、ベンダーごとに個別の連携改修を依頼する必要がなくなり、移行スケジュールが変更されても基盤側の変換定義を修正するだけで対応できる体制が整っています。この方式を参考にする際の判断基準は、移行対象が3ベンダー以上にまたがるかどうかです。単一ベンダーで一括移行する場合は、基盤を置かずにベンダー内の連携機能で足りるため、過剰投資になります。

事例2：電子申請と約200の庁内システムを接続：県庁規模の連携基盤

関東の県庁では、電子申請で受け付けた手続きの内容を各部局のシステムへ手作業で転記しており、年間で数万件規模の申請に対して職員の転記作業が常態化していました。課題は転記の工数と入力ミスで、申請の種類が増えるたびに作業が膨らむ状況が続いていたのが実態です。対応として、電子申請システムと庁内の約200のシステムを連携基盤で接続し、申請データを各システムの取り込み形式へ自動変換する仕組みを整えています。接続は一度に行わず、申請件数の多い手続きから数年かけて段階的に広げる計画で進められました。

成果は、申請種別ごとに数日かかっていた取り込みが即日で完了するようになり、転記ミスによる差し戻しが減少した点です。県庁規模で200近いシステムを接続する場合、1システムあたりの接続設定に1〜2週間を要するため、全体で2〜3年の段階的な展開計画が前提になります。参考にする際は、申請件数が年間1,000件を超える手続きから接続し、少量の手続きは後回しにする優先順位付けが現実的です。接続順を決める判断材料として、STEP1の棚卸し一覧に申請件数の列を加えておくと、そのまま計画に使えます。

事例3：県・市町の共同利用モデル：防災・空き家対策を対象にしたデータ流通

北関東の県では、市町ごとに連携基盤を構築する財政的な余裕がなく、県が基盤を整備して市町が共同利用する方式を採用しました。対象として選ばれたのは防災と空き家対策で、どちらも県と市町の双方がデータを持ち、単独では全体像を把握できない分野です。防災では避難所の開設状況と河川の水位情報、空き家対策では市町の空き家台帳と県の建築確認情報を連携対象にしています。どちらも県と市町が同じ画面を見る必要がある分野で、共同利用の効果が説明しやすいのが選定理由です。

成果として、災害時に県と市町が同じ画面で避難所の状況を確認できるようになり、電話やFAXによる報告のやり取りが減少したのが第一の成果です。空き家対策では、所有者情報の突合に要していた期間が短縮され、対策の優先順位を数値で説明できる状態になっています。共同利用方式を参考にする際の判断基準は、県内の市町のうち半数以上が参加意思を示しているかどうかです。参加が3割に満たない段階で構築を始めると、負担金の収入が計画を下回り、県の持ち出しが増えます。意向調査で参加率を確認してから予算化する手順を守ってください。

事例4：防災データ連携基盤による広域自治体連携：水位・潮位・道路情報の一元化

四国の中核市では、台風や高潮の際に河川の水位、海岸の潮位、道路の冠水状況が別々のシステムで管理され、災害対策本部で情報を突き合わせるのに時間がかかっていました。対応として、オープンソースの都市OSを基盤に、水位計や潮位計のセンサーデータと道路カメラの情報を集約し、地図上で一元表示する防災データ連携基盤を構築した取り組みです。周辺の自治体にも同じ基盤を開放し、広域で情報を共有する体制に発展させました。河川は市域をまたいで流れるため、広域化は防災分野では必然の展開です。

連携したデータはセンサーの観測値、カメラ画像、避難所の開設情報で、センサーは数分間隔の自動収集です。成果は、災害対策本部での状況把握が複数画面の切り替えから1画面で済むようになり、避難情報の発令判断が早まった点にあります。参考にする際は、センサーの設置と通信費が運用費の大半を占めることを前提に、設置箇所を優先度の高い10〜20か所から始める計画が現実的です。センサーを一度に数百か所へ設置すると、通信費と保守費が年間数千万円規模に達し、継続が困難になります。

事例5：都市OSによる分野横断活用：除雪・観光・見守りデータの連携

東北の中核市では、都市OSを早期に導入し、除雪車の位置情報、観光客の周遊データ、高齢者の見守りセンサーの情報といった分野の異なるデータを1つの基盤に集約しました。課題は分野ごとに事業者が異なり、データ形式も利用条件もばらばらで、横断的なサービスが作れなかったことです。対応として、住民が自らの意思でデータ提供に同意するオプトイン方式を採用し、同意した住民のデータだけを連携対象にする設計を選んでいます。

成果の例として、除雪車の位置を住民がスマートフォンで確認できるサービスや、観光データを使った混雑情報の提供が実現しています。見守りでは、センサーの異常を家族や地域の協力者へ通知する仕組みが運用中です。参考にする際の判断基準は、同意率の目標を事前に決められるかどうかです。オプトイン方式では同意した住民の割合がサービスの価値を左右するため、人口の5〜10％程度の同意を初期目標とし、達成できる広報計画を立ててから着手してください。広報計画なしに始めると、同意率が1％台で止まり、データが集まらない状態が続きます。

事例6：小規模自治体の共同導入：子育て支援を起点にした地域データ連携

人口1万〜8万人規模の2つの自治体では、単独で都市OSを導入する予算も人員もなく、子育て支援という共通テーマで基盤を共同導入する道を選びました。課題は、妊娠届から出産、健診、保育所の申請まで手続きが分かれ、保護者が同じ情報を何度も記入していたことです。対応として、母子保健のデータと保育所の申請情報を連携し、保護者向けのアプリから一度の入力で複数の手続きが進む仕組みを整えています。基盤の設定は共通とし、団体ごとに異なる部分は様式の差分だけに限定した点が特徴です。

成果は、保護者の手続き負担の軽減に加え、健診の未受診者を早期に把握し、保健師が優先的に連絡できるようになった点です。小規模自治体が共同導入する際の判断基準は、業務フローの違いをどこまで共通化できるかにあります。2団体で手続きの様式や申請の流れが大きく異なる場合、基盤の設定を団体ごとに分ける必要があり、共同のメリットが薄れます。着手前に両団体の担当者が互いの業務フローを図にして突き合わせ、共通化できる割合が7割以上であることを確認してから進めてください。

まとめ：自治体のデータ連携は「庁内の整流化」から始めて地域基盤へ広げる

自治体のデータ連携は、庁内の基幹業務システムや電子申請をつなぐ層と、官民のデータを地域で流通させる層の2つに分けて考えると、検討の順序が定まります。庁内では標準化とガバメントクラウド移行に伴う過渡期の連携を基盤で吸収し、外字やコード体系をそろえてから名寄せに進む手順が成果を左右します。地域基盤は、データ提供元と同意の設計を構築前に固め、県と市町の共同利用など費用負担の仕組みを先に決めることが成功の条件です。

着手の目安は、STEP1の棚卸し一覧を2〜3週間で作り、優先業務を5〜10に絞るところからです。効果の大きい1〜2業務でスモールスタートし、運用ルールを固めてから横展開に進めば、担当者の異動があっても保守が止まりません。国のサービスカタログやガイドブックを調達の共通様式として使えば、要件定義の工数も抑えられます。庁内の流れを整えてから地域へ広げる順序を守り、自分たちの自治体に合った基盤の形を具体化してください。

「これからデータ連携基盤の整備を始めたいけれど、何から手をつけたらいいかわからない」「データ連携やデータガバナンスの専門家の知見を取り入れたい」という方は、データ連携の実績豊富な弊社、データビズラボにお気軽にご相談ください。

貴社の課題や状況に合わせて、データ連携基盤の取り組みをご提案させていただきます。

データビズラボの実績無料相談・お見積り