この記事は、自治体のDX担当・情報システム担当が「複数の既存システムを横断してAIを使わせる調達を設計する」段階で使えるRFP要件リファレンスです。RFPの基本条項は姉妹記事（RFP条項）で、データの削除・返却条項はデータ保存・削除ルールの記事で扱っています。
デジタル庁は「デジタル田園都市国家構想」の一環として、各地域でデータ連携基盤の整備を推進しています。自治体内でも、住民台帳・福祉・教育・農業など複数のシステムが持つデータをAIに横断参照させることで、業務効率化と住民サービス改善を図る動きが広がっています。このような「複数データソースをAIがまたいで参照する」構成を、本記事では「データメッシュ型」と呼びます。
データメッシュ型AIシステムをRFPで発注するとき、個別業務の単機能AIと同じ仕様書の書き方では要件が足りません。どのデータをどこから持ってきて、誰が参照できて、何が記録されるかを先に設計しないと、調達後に「このシステムでは庁内の〇〇データが読めない」「住民データが想定外の範囲に流れた」という問題が起きます。
データメッシュ型AIの典型構成
自治体内情報活用型のAIシステムは、主に次の構成をとります。
[データソース群]
住民基本台帳DB ─────┐
福祉・介護システム ────│──→ [データ連携ハブ/ETL] ──→ [AI検索・生成エンジン]
教育・子育て支援DB ───│ ↓
公共施設予約システム ──┘ [職員向け照会UI]
この構成で問題になるのは3点です。データの「結合」によって新たな個人特定が可能になるリスク、複数部署にまたがる権限制御の複雑化、どのデータが回答に使われたかのトレーサビリティです。
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
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要件に含める |
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
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要件定義を、データソース棚卸し・権限マップ設計・監査トレイル要件の文書化まで一貫して支援します。
