この記事は、自治体のDX担当・情報システム担当が「複数の既存システムを横断してAIを使わせる調達を設計する」段階で使えるRFP要件リファレンスです。RFPの基本条項は姉妹記事（RFP条項）で、データの削除・返却条項はデータ保存・削除ルールの記事で扱っています。

デジタル庁は「デジタル田園都市国家構想」の一環として、各地域でデータ連携基盤の整備を推進しています。自治体内でも、住民台帳・福祉・教育・農業など複数のシステムが持つデータをAIに横断参照させることで、業務効率化と住民サービス改善を図る動きが広がっています。このような「複数データソースをAIがまたいで参照する」構成を、本記事では「データメッシュ型」と呼びます。

データメッシュ型AIシステムをRFPで発注するとき、個別業務の単機能AIと同じ仕様書の書き方では要件が足りません。どのデータをどこから持ってきて、誰が参照できて、何が記録されるかを先に設計しないと、調達後に「このシステムでは庁内の〇〇データが読めない」「住民データが想定外の範囲に流れた」という問題が起きます。

データメッシュ型AIの典型構成

自治体内情報活用型のAIシステムは、主に次の構成をとります。

この構成で問題になるのは3点です。データの「結合」によって新たな個人特定が可能になるリスク、複数部署にまたがる権限制御の複雑化、どのデータが回答に使われたかのトレーサビリティです。

RFP要件の4観点

観点1：データ連携仕様

どのシステムのデータを取り込み、どのように正規化・更新するかを明記します。

要件項目記載すべき内容
データソース一覧対象システム名・保有データ項目・更新頻度
接続方式API連携・CSV定期取り込み・リアルタイム連携のいずれか
データ正規化方針複数システムにまたがる同一人物データの名寄せ方法
除外データの定義AIの参照対象から除外するデータ項目（医療情報、センシティブ情報等）
更新・廃棄サイクルAIシステム側のデータキャッシュの有効期限と削除タイミング

観点2：権限分離の設計

住民基本台帳を扱う部署が福祉ケース記録も参照できてしまうような「過剰アクセス」を防ぐため、権限制御を業務ドメイン単位で設計します。

権限レベル参照可能データ範囲設定例
全庁共通参照公開情報・施設情報のみ全職員
部署限定参照当該部署が担当する住民情報のみ福祉課→福祉データのみ
上位権限複数部署データの横断参照情報統括担当・首長指定者
委託先限定運用保守に必要な最小限のログのみ委託SIer

この権限設計の要件は、RFPの「機能要件」節ではなく「セキュリティ要件」節として独立させることを推奨します。

観点3：監査トレイルの設計

データメッシュ型AIが生成した回答について「どのデータを参照したか」「誰が照会したか」を後から追跡できる設計が必要です。個別業務AIと異なり、参照元が複数システムにまたがるため、単一のログでは不十分です。

ログ種別保存内容保存期間
照会ログ照会者ID・照会日時・入力クエリ・参照したデータソース名・参照件数3年
回答生成ログ生成した回答テキスト・参照ドキュメントID・信頼度スコア3年
データ取込ログ取り込んだシステム名・件数・日時・エラー件数1年
権限変更ログ変更対象・変更内容・変更者・承認者5年（監査対応）

観点4：データライフサイクル管理

キャッシュされたデータは、元システムで削除された情報を参照し続けるリスクがあります。次の仕組みをRFPに要件として含めます。

  • 削除連動：元システムで個人情報が削除・更新された場合、AIシステム側のキャッシュが○時間以内に同期されること。
  • 整合性チェック：月1回以上、元システムとAIシステムのデータ整合性を確認する手順が自動化されていること。
  • 廃棄フロー：AIシステム終了時に、各データソースから取り込んだデータをソース別に削除証跡付きで廃棄できること。

データ基盤の設計と運用では、データメッシュ型基盤のアーキテクチャ選定と運用フローを詳しく扱っています。

よくある調達失敗：データメッシュ特有のリスク

単機能AIと比べてデータメッシュ型のAIは、次の失敗が起きやすいです。

失敗パターン原因防止策
部署間で見せてはいけないデータが混在権限設計をベンダーに丸投げRFP段階でデータドメインと権限マップを定義する
元システムの廃棄データをAIが参照し続ける削除連動の要件がRFPにない削除同期の時間基準をRFPに明記する
誤回答の根拠調査ができない参照ドキュメントIDがログに含まれていない回答生成ログの必須項目をRFPで定義する
年度更新でシステムが止まるデータ取込スケジュールが業務カレンダーと連動していない年次更新・マスタ変更時の手順をRFP要件に含める

GXOはどう支援するか

GXOでは、自治体の複数システムにまたがるデータメッシュ型AI調達のRFP設計を支援しています。データソースの棚卸しから権限マップの作成、監査トレイル要件の文書化まで、「発注者として要件を定義できる状態」に整えます。調達後の構築フェーズで必要になるデータ基盤の導入と運用まで、連続して支援が可能です。

よくある質問

Q1. データメッシュ型AIシステムはオンプレで調達すべきですか、クラウドで調達すべきですか

住民データを扱う場合、自治体情報セキュリティポリシーと「三層の対策」（マイナンバー利用事務系・LGWAN接続系・インターネット接続系の分離。総務省ガイドラインでα・α'・β・β'などのモデルが定義されています）への準拠が前提になります。クラウド活用は可能ですが、どのデータをどのゾーンで扱うかをRFP段階で明確にし、CSP（クラウドサービス提供者）が自治体のセキュリティ要件を満たすことを確認します。

Q2. 一度にすべてのシステムを接続する必要がありますか

不要です。まず参照頻度が高く個人情報リスクが低い業務データ（施設情報、FAQ等）から始め、個人情報を含む住民データは権限設計と監査トレイルが整ってから接続する段階的アプローチが安全です。

Q3. 既存SaaSベンダーへのデータ連携APIが非公開の場合はどうすればよいですか

APIが非公開の場合、CSV定期エクスポート＋定期バッチ取り込みが現実的な代替手段です。ただし取込ラグが発生するため、リアルタイム性が必要な業務には向きません。接続方式の制約はRFP要件に書いておき、各ベンダーが制約内でどう実現するかを提案させる設計にします。

参考情報

  • デジタル庁「Area Data Coordination Platform（地域データ連携基盤）」：https://www.digital.go.jp/en/policies/digital_garden_city_nation/area-data-coordination-platform
  • デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（DS-920）」：https://www.digital.go.jp/en/news/3579c42d-b11c-4756-b66e-3d3e35175623
  • DS-920 ガイドライン本文（PDF）：https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/80419aea/20250527_resources_standard_guidelines_guideline_01.pdf
  • 総務省「自治体におけるAI活用・導入ガイドブック（導入手順編・第4版）」：https://www.soumu.go.jp/main_content/000820109.pdf

データメッシュ型AI調達のRFP設計を支援します

GXOでは、自治体内の複数システムにまたがるデータ連携型AIのRFP要件定義を、データソース棚卸し・権限マップ設計・監査トレイル要件の文書化まで一貫して支援します。

データメッシュAIのRFP設計を相談する