自治体のデータガバナンス：個人情報保護とオープンデータ活用を両立させる実践戦略

自治体のデジタルトランスフォーメーション（DX）推進において、最大の障壁となるのは「法規制の遵守」と「技術的サイロの解消」の両立です。令和4年4月に全面施行された改正個人情報保護法により、地方公共団体は国の機関と共通のルールが適用されることとなり、従来の自治体独自の個人情報保護条例に基づく運用からの脱却が求められています。

本稿では、住民のプライバシーを厳格に保護する「守りのガバナンス」を基盤としつつ、行政運営の効率化とオープンデータ活用による地域課題解決を目指す「攻めの利活用」を両立させるための、具体的かつ実務的なデータガバナンス構築手法を詳説します。行政DXの担当者が直面する技術的な選定基準、運用設計、および予期せぬシステムトラブルへの対応策まで、網羅的な知見を提供します。

1. 自治体データガバナンスの定義と法的背景

データガバナンスとは、組織が保有するデータの品質、可用性、整合性、およびセキュリティを維持・向上させるための包括的な管理体制を指します。自治体においては、住民の生活に直結する極めて機密性の高い情報を扱うため、民間企業以上に厳格な規律が必要とされます。特に、情報のライフサイクル（収集、加工、保存、利用、廃棄）全体を通じた統制が不可欠です。

1-1. 令和4年改正個人情報保護法によるパラダイムシフト

2022年（令和4年）4月の法改正は、自治体にとって「2000個問題」と呼ばれた自治体ごとのルールのバラつきを解消する大きな転換点となりました。これにより、広域連携や官民連携におけるデータ授受の法的根拠が明確化されました。以前は隣接する市町村であっても、条例の解釈が異なるために防災データの共有すら困難なケースがありましたが、現在は共通の「法」の下で標準化が進んでいます。

出典：個人情報保護委員会「令和3年改正個人情報保護法について（地方公共団体向け）」^[1]

1-2. データ活用の鍵となる「加工情報」の定義

データ利活用を推進する上で、実務担当者が最も正確に理解すべきは「匿名加工情報」と「仮名加工情報」の違いです。これらを適切に使い分けることで、プライバシー保護と分析精度のバランスを最適化できます。特にEBPM（証拠に基づく政策立案）においては、どの程度の加工が許容されるかの判断がプロジェクトの成否を分けます。

• 匿名加工情報：特定の個人を識別することができないように個人情報を加工し、当該個人情報を復元できないようにしたもの。オープンデータとして民間提供する場合や、学術機関への提供に必須です。
• 仮名加工情報：他の情報と照合しない限り、特定の個人を識別することができないように個人情報を加工したもの。行政内部での分析（例：福祉と教育のデータを突き合わせた予兆検知）や、部署を跨いだ相関分析に適しています。削除される項目が少ないため、分析精度を高く保てます。

例えば、健康診査データと介護認定データを突き合わせて「将来の要介護リスク」を予測するような内部分析では、仮名加工情報を用いることで、解析の精度を落とさずに安全な運用が可能です。一方で、地域の交通量や人口流動を民間に開放する際は、k-匿名性等の技術を用いて匿名加工を行う必要があります。

2. 自治体向けデータ基盤アーキテクチャの選定基準

データが各課の個別システムに閉鎖されている「サイロ化」の状態では、全庁的なガバナンスを効かせることは不可能です。論理的にデータを集約し、適切な権限管理を行うためのモダンデータスタック（MDS）の導入が急務となっています。ここでは、自治体が選定すべき主要な技術スタックを比較・検討します。

2-1. 主要ツール・プラットフォームの徹底比較

自治体の要件（ガバナンス、セキュリティ、コスト、拡張性）に基づき、現在主流となっている4つのプラットフォームを比較します。特に「データの所在」と「アクセス制御の細かさ」が選定の要となります。

Snowflakeによる「データシェアリング」の革新性

東京都の「デジタルセカンド（データ利活用基盤）」でも活用されているSnowflakeの最大の特徴は、コンピューティングとストレージの分離、そして「ライブ・データ共有」です。従来のデータウェアハウス（DWH）では、データを他部署に渡す際に「CSV出力→メール送付→相手先でインポート」というプロセスが発生し、その過程でガバナンスが喪失（コピーされたデータの管理が不能）していました。また、送付した瞬間にデータが古くなる「鮮度の問題」も抱えていました。

Snowflakeでは、元データに対して「参照権限」のみを他部署に付与することで、同一のデータソースをリアルタイムに共有できます。これにより、データの鮮度を保ちつつ、漏洩リスクを劇的に低減させることが可能です。また、クエリを実行した分だけの従量課金であるため、予算確保が年度単位の自治体にとっても、リソースの最適化が図りやすいという側面があります。

出典：Snowflake公式「東京都デジタル局の導入事例」^[2]

2-2. 自治体特有のセキュリティ要件「三層の対策」

総務省が提唱する「自治体情報セキュリティ対策の三層の対策」に基づき、データ基盤は以下のいずれかの配置、あるいはα/β/β’モデルへの適合が求められます。特にパブリッククラウドを利用する場合、インターネット接続系だけでなく、LGWAN接続系からの安全なアクセス確保が鍵となります。

1. マイナンバー利用事務系：インターネットから完全に隔離。住民基本台帳や地方税など、極めて高い機密性が求められる。
2. LGWAN接続系：地方公共団体専用の閉域網内で運用。福祉、保健、学務などの業務システムが配置される。
3. インターネット接続系：オープンデータや住民向けサービス、広報など。

現在のトレンドは、クラウドバイデフォルト原則に基づき、LGWANとパブリッククラウド（AWS/Azure/GCP等）をセキュアに接続する「統合基盤」の構築です。ここで重要なのは、Identity and Access Management (IAM) による厳格なID管理です。多要素認証（MFA）はもちろん、アクセス元のIP制限や端末制御を組み合わせることで、「どこからでもアクセスできる」クラウドの利便性と、「許可された者しか入れない」ガバナンスを両立させます。

関連記事：SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

3. 【実践】データガバナンス体制構築の10ステップ

データガバナンスは、ツールを導入すれば完成するものではありません。以下の10ステップを通じて、組織的な運用体制を確立する必要があります。特に、技術部門（情報システム課）と業務部門（各原課）の責任分解点を明確にすることが成功の要諦です。

ステップ1：データ活用ビジョンとガイドラインの策定

まずは「何のためにデータを使うのか」を明確にします。例えば、「EBPM（証拠に基づく政策立案）の推進」や「住民の利便性向上」、「災害時の迅速な意思決定」といった上位概念を定め、それに沿ったデータ取り扱いガイドラインを策定します。このガイドラインには、個人情報保護審査会への諮問基準なども含める必要があります。

ステップ2：データカタログ（メタデータ）の整備

各課が保有するデータの内容（カラム定義）、更新頻度、主管部署、機密レベルを一覧化します。これが無いと、エンジニアがデータを探すだけで数週間を要することになります。「どのテーブルに何が入っているか」を辞書化する作業は地味ですが、全庁基盤の心臓部となります。

ステップ3：データオーナーシップと権限の定義

各データの「責任者（オーナー）」を各課の課長級に設定し、情報システム部門は「技術的な管理（カストディアン）」に徹する責務分担を行います。データの利活用可否の最終判断はオーナーが行い、システム部門は設定の実行を担うという分離が、内部統制上重要です。

ステップ4：ETL/ELTパイプラインの設計

基幹業務システム（住民基本台帳、税務、福祉等）からデータを抽出する際のパスを設計します。手作業によるCSV出力を廃止し、API連携やデータベースのレプリケーション機能を活用して、人的ミスと改ざんのリスクを排除します。TroccoなどのETLツールを用いて、ワークフローを可視化することが推奨されます。

ステップ5：データクレンジングと名寄せルールの確立

自治体データで最も課題となるのが「住所表記」や「外字」の不一致です。「1丁目2番3号」と「1-2-3」を同一地点として認識させるための正規化エンジンをパイプラインに組み込みます。また、法人マイナンバーや枝番を用いた名寄せルールの統一もこの段階で行います。

ステップ6：匿名化・仮名加工処理の実装

DWH内に「生データ層（Bronze）」「加工データ層（Silver）」「公開データ層（Gold）」の3層構造（メダリオンアーキテクチャ）を構築します。生データ層には情報システム部門の一部のみがアクセスし、分析官は加工データ層のみを参照する、といった物理的な隔離をクエリレベルで制御します。

ステップ7：セキュリティ監査・ログ管理体制の構築

「誰が、いつ、どのデータにアクセスしたか」を完全に記録し、定期的に監査を行います。特権IDの利用は申請ベースとし、多要素認証（MFA）を必須とします。ログは不変性を保つために、読み取り専用のストレージにリアルタイム転送される構成が望ましいです。

ステップ8：データ利活用推進チーム（CoE）の組成

技術に強い職員と、行政実務に明るい職員を混合させたCenter of Excellence（CoE）を設置します。各課からのデータ活用相談（例：このアンケート結果と統計データを掛け合わせたい）を一括で受け付ける窓口を作り、技術的な壁を組織として解消します。

ステップ9：オープンデータ公開プロセスの自動化

DWHから特定の条件で抽出・匿名化されたデータを、CKAN等のオープンデータプラットフォームへ自動連携させる仕組みを構築します。手作業でのアップロードを廃止することで、更新の遅延を防ぎ、常に最新のデータを民間に提供できる環境を整えます。

ステップ10：継続的なモニタリングと改善（PDCA）

データの利用状況をBIツールで可視化します。どのデータが頻繁に使われ、どのデータが活用されていないかを把握し、利用頻度の低いデータの品質改善や、不要なデータ保持の停止を定期的（四半期ごと等）に実施し、ストレージコストとリスクを最小化します。

4. 匿名加工・データ連携における高度な技術的要件

データ利活用を安全に行うためには、単なる黒塗りではない統計学的なアプローチが不可欠です。自治体で求められる主要な手法を詳述します。

4-1. k-匿名性 (k-anonymity) の確保

k-匿名性とは、特定の属性（性別、生年月日、郵便番号等）を持つ個人のレコードが、データセットの中に少なくともk件以上存在することを保証する指標です。例えば、k=3の場合、同じ属性を持つ人が必ず3人以上いる状態を作ります。

• 一般化：年齢を「31歳」から「30代」へ、住所を「○丁目△番」から「○丁目」へ粒度を落とす手法。
• サプレッション（削除）：特定の極めて珍しい属性を持つレコード（例：100歳以上の住民が1人しかいない地域）をデータセットから除外する手法。

4-2. 差分プライバシー (Differential Privacy)

データセットに対して意図的な「ノイズ（誤差）」を加えることで、特定の個人がそのデータセットに含まれているかどうかさえ分からなくする技術です。AppleやGoogleも採用している手法であり、デジタル庁のデータ戦略においても検討されています。集計値の正確性を一定程度保ちつつ、個人の特定を数学的に不可能にします。

出典：デジタル庁「データ活用におけるプライバシー保護技術」^[3]

4-3. API連携におけるセキュリティプロトコル

自治体システム間、あるいはSaaSとの連携において、認証情報の管理は最重要課題です。以下のプロトコルを標準として採用すべきです。

5. 異常系の時系列シナリオとリカバリ計画

データガバナンス運用中には、必ず予期せぬトラブルが発生します。これらを想定内に収めるためのシナリオと対応策を事前に定義しておく必要があります。

5-1. シナリオA：APIリミット到達によるデータ遅延

• 発生事象：SaaS（Salesforce Data Cloud等）からDWHへの夜間同期中、APIの実行回数が上限（24時間リミット）に到達し、転送が50%で停止。
• 影響：翌朝のダッシュボードに前日のデータが反映されず、災害対策本部などの迅速な意思決定が阻害される。
• 対処策：
  1. ETLツール側で「Exponential Backoff（指数関数的リトライ）」を有効化し、数時間後に自動再開。
  2. 取得対象を「全件」から「差分（UpdatedDate）」のみに限定するフィルタリングの実装。
  3. 重要度の高いデータ（避難所状況など）を優先し、統計データなどは実行時間をズラすスケジューリングの最適化。

5-2. シナリオB：マスタデータの「重複・名寄せ失敗」

• 発生事象：住民向けアプリと内部の健康管理システムで、同一人物が別ID（名寄せ不一致）として登録される。特に結婚による氏名変更や、引越しによる住所変更のタイミングで発生しやすい。
• 影響：同一住民に重複した通知が届く、あるいは必要な行政サービス（給付金等）が提供されない。
• 対処策：
  1. 「氏名（カナ）＋生年月日＋住所（正規化後）」をキーとしたマッチングアルゴリズムの多層化。
  2. 名寄せ不一致レコードを隔離（Quarantine）し、人間が目視確認するワークフローの実装。
  3. dbt (data build tool) を用いた変換レイヤーでのデータ整合性テストの自動実行。

5-3. シナリオC：匿名加工情報の「再識別」リスクの露呈

• 発生事象：公開したオープンデータに対し、外部の攻撃者や研究者が別の公開データセット（不動産登記情報等）と照合し、個人を特定できたと指摘される。
• 影響：プライバシー侵害による損害賠償、住民の信頼喪失。
• 対処策：
  1. 直ちに該当データの公開を停止。
  2. 「再識別リスク評価ツール」を導入し、公開前の自動評価プロセス（k-値のチェック）を構築。
  3. 利用規約において「再識別を目的とした利用」を明示的に禁止する法的措置の徹底。

関連記事：WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ

6. 自治体における先進的なデータ活用事例の深掘り

単なる「管理」を超え、データガバナンスを基盤に成果を上げている自治体の事例を、共通の成功要因とともに分析します。これらの事例には、技術選定の妥当性と組織体制の強固さが共通しています。

6-1. 事例1：東京都「デジタルセカンド（全庁データ連携基盤）」

東京都は、Snowflakeを基盤とした全庁的なデータ連携基盤を構築しました。従来、各局（福祉保健局、建設局等）がバラバラに管理していたデータを、クラウド上で論理的に集約しています。

• 課題：局を跨いだデータ共有に数週間の調整と物理的なコピー作成が必要だった。データの鮮度が低く、緊急時の意思決定に使えなかった。
• 施策：Snowflakeのデータシェアリング機能を採用。データの実体を動かさず、必要な部分だけを他局に「見せる」運用へ転換。また、データの機密性に応じたアクセス権限をロール単位で厳格に管理。
• 結果：データ準備期間が数日から数分に短縮。局間を跨いだ複雑な相関分析が可能になり、EBPMの精度が向上。

6-2. 事例2：兵庫県神戸市「ダッシュボードによる政策可視化」

神戸市は、Tableauを活用して市民向けのオープンデータサイト「KOBE Data Sheet」を展開しています。

• 課題：オープンデータが単なるCSVファイルの羅列になっており、市民や企業が活用しにくかった。市職員もデータの傾向を直感的に把握できていなかった。
• 施策：人口、財政、観光客数などの重要指標をTableauでグラフ化し、自動更新される仕組みを構築。スマホからも閲覧可能なインターフェースを採用。
• 結果：サイトのPV数が大幅に向上。民間企業からのデータ活用に関する問い合わせが増加し、地域のスタートアップ支援にも寄与。市内部でも、視覚的に傾向を把握できるため、政策立案のスピードが向上した。

出典：神戸市「KOBE Data Sheet」^[4]

6-3. 事例3：千葉県市川市「住民一人ひとりに寄り添うプッシュ型行政」

市川市はSalesforceを活用し、LINE公式アカウントと連携したパーソナライズサービスを提供しています。

• 課題：住民が必要な情報を市のHPから探す手間がかかり、給付金などの申請漏れが発生していた。行政側も一律の広報しかできず、情報の到達率が低かった。
• 施策：住民の年齢、居住地、家族構成（任意回答）に基づき、最適な情報をLINEでプッシュ通知する基盤を構築。Salesforce Data Cloudでセグメント管理を行い、ガバナンスを保ちつつ配信を自動化。
• 結果：申請手続きのデジタル化と相まって、窓口の混雑緩和と住民満足度の向上を同時に達成。特に子育て世代からの評価が極めて高い。

出典：Salesforce「市川市導入事例」^[5]

成功自治体の共通項と「成功の型」

複数の成功事例を分析すると、以下の3つの共通項が浮かび上がります。これらは「失敗を避ける条件」でもあります。

1. スモールスタートとクイックウィン：全庁一斉ではなく、特定の局やニーズの高いデータ（例：防災、観光、子育て）から開始し、成功実績を作ってから拡大している。
2. トップのコミットメント：知事や市長がデータ活用の重要性を明言し、組織文化の変革（データを見て話す文化）を強力に後押ししている。技術的な議論の前に「やる」という決断がある。
3. 技術的負債の排除：レガシーなオンプレミスサーバーやCSV運用に固執せず、APIやクラウドネイティブな基盤への投資を優先している。保守コストを削減し、それをデータ分析のリソースへ転換している。

7. 運用コストとリソース配分の現実解

データガバナンス構築には相応の投資が必要です。人口30万人規模の中規模自治体を想定した概算コストと、費用対効果の考え方を示します。なお、具体的な見積りは各ベンダーの窓口や公式ドキュメント（ライセンス体系ページ等）で最新情報を確認してください。

7-1. 構築・運用コストの見積り（参考例）

※上記は一例であり、既存システムとの連携難易度やセキュリティ要件（閉域網接続の有無など）により大きく変動します。詳細は各ベンダーの公式窓口へお問い合わせください。

7-2. 費用対効果（ROI）の考え方

自治体におけるROIは、直接的な収益ではなく「コスト削減」と「付加価値向上」で評価します。

• 窓口業務の削減：プッシュ型通知と電子申請の連携により、窓口対応時間を年間数千時間削減。
• 政策の最適化：EBPMにより、効果の低い事業を廃止・縮小し、財源を重要施策へシフト。
• リスク回避：情報漏洩が発生した際の想定損害額（1件数万円×全住民分）を、強固なガバナンスによって最小化。

8. 自治体データガバナンスに関するFAQ

実務担当者からよく寄せられる質問を整理しました。

Q1: 改正個人情報保護法で、条例はすべて廃止すべきですか？

A1: 条例自体を廃止する必要はありませんが、法に抵触する部分は無効となります。多くの自治体では、法の施行に伴い条例を全面的に改正、あるいは法に従う旨を明記した「施行条例」へと移行しています。詳細は総務省の「地方公共団体等向けガイドライン」をご確認ください。

Q2: マイナンバーはDWHに入れても良いですか？

A2: マイナンバー（個人番号）そのものをDWHに入れることは、番号法上の強い制限があるため推奨されません。代わりに、内部的に利用する「独自ID（名寄せ用ID）」に変換（ハッシュ化等）した上で格納し、分析に用いるのが一般的です。個人番号そのものを扱う場合は、専用の隔離された環境が必要です。

Q3: クラウド導入に対する住民の不安にはどう答えるべきですか？

A3: ISMAP（政府情報システムのためのセキュリティ評価制度）に登録されたサービスを選定していること、データは日本国内のリージョンに保管されていること、アクセスログが完全に記録されていることなど、客観的な基準を公表することが有効です。また、データの「所有権」は自治体にあり、ベンダーが利用できない契約であることを明示してください。

Q4: 技術的なスキルを持つ職員がいません。どうすれば良いですか？

A4: 外部の専門人材（DX補佐官等）の採用、あるいは「マネージドサービス（運用保守込み）」のツール選定が現実解です。また、ノーコードツールを採用することで、現場の職員が自分でデータを扱える環境（セルフサービスBI）を整えることが、長期的な属人化排除に繋がります。

Q5: 匿名加工情報の作成に特別なソフトは必要ですか？

A5: SnowflakeなどのモダンDWHには、動的データマスキング機能や、匿名化のための関数が標準搭載されています。また、ARXなどの専門的な匿名化オープンソースツールをパイプラインに組み込むことも可能です。ツールの選定よりも、「どの項目をどう消すか」という定義（ルール）の策定が重要です。

Q6: データの「品質」が悪すぎて分析できません。どこから手をつけるべきですか？

A6: まずは「入力段階」の制御です。全角・半角の混在や、住所の揺らぎを許さないバリデーション（入力チェック）をシステム側に実装します。次に、既存データの「正規化」をETLプロセスで自動化します。全てのデータを一気に綺麗にするのは不可能であるため、分析に必要な重要項目（生年月日、性別、郵便番号）から順次着手してください。

9. まとめ：データが支える「持続可能な自治体運営」

データガバナンスの構築は、一朝一夕に成し遂げられるものではありません。しかし、少子高齢化に伴う職員不足と財政逼迫が深刻化する中、データに基づいた効率的な行政運営（スマート自治体）への転換は避けて通れない課題です。本稿で紹介したSnowflakeやSalesforceといったテクノロジーを、強固な法的知識と運用設計で包み込むことによって、初めて「安全かつ自由な」データ利活用が可能になります。

まずは自庁のデータカタログの整備という小さな一歩から始め、成功事例を積み重ねていくことで、住民に真に寄り添うデジタル行政を実現してください。