自治体向けシステム提案書の書き方・作り方

行政AIヤマトにおいては「DX・情報」の「自治体システム書類作成」のボタンで、この仕様の通り、AI出力できます。

要約・結論

自治体向けシステム提案書は、製品の魅力を並べる営業資料ではありません。住民サービスまたは庁内業務の課題を明確にし、限られた予算・人員・期間の中で、公共性、公平性、安全性、継続性を満たす実現方法を、審査者が比較できる形で示す文書です。良いシステム提案書は「課題」「解決策」「効果」「実現性」「費用」「リスク」のつながりが明快で、仕様書や評価基準の全項目に漏れなく答え、導入後の運用まで説明しています。

結論を先に書くと、自治体向けシステム提案書の作り方で最も重要なのは、発注者の言葉で課題を定義し、要求事項ごとに根拠のある回答を置き、実現できないことや前提条件も透明に示すことです。機能数の多さではなく、行政目的への適合度、住民・職員双方の使いやすさ、個人情報保護、セキュリティ、アクセシビリティ、移行と運用引継ぎを一体として提案してください。法令、条例、国のガイドライン、クラウド利用方針、情報セキュリティポリシーは改定されるため、案件時点の最新版を必ず発注者と確認します。

想定読者

• 自治体のDX、情報政策、原課、契約・調達部門の担当者
• 自治体向けシステムの提案責任者、営業、SE、プロジェクトマネージャー
• 提案書を初めて作る地域事業者、スタートアップ、共同企業体の担当者
• 技術提案を行政目的や評価基準に翻訳したい設計・運用担当者
• 審査委員として提案内容を比較し、実現性を確認する職員や外部有識者

自治体向けシステム提案書の基本構成

推奨する章立ては次のとおりです。募集要領や様式が指定されている場合は、その順序、ページ数、文字サイズ、提出形式を最優先します。

1. 表紙、提出者情報、版数、秘密情報の扱い
2. エグゼクティブサマリー
3. 自治体の現状認識と解決すべき課題
4. 提案方針と全体コンセプト
5. 業務・サービスの将来像
6. 機能、非機能、データ、連携の提案
7. システム構成、セキュリティ、個人情報保護
8. 導入計画、データ移行、教育、テスト
9. 運用保守、障害対応、SLA、運用引継ぎ
10. 実施体制、役割分担、品質管理
11. スケジュールと成果物
12. 費用、効果、KPI
13. リスク、前提条件、制約、将来拡張
14. 実績、参考情報、要求事項対応表

1. 提案前の読み込みと情報整理

自治体向けシステム提案書を書く前に、公告、実施要領、仕様書、機能要件一覧、非機能要件、評価基準、質問回答、契約書案、様式集を一式として管理します。文書ごとに担当者を分けるだけでは、条件の見落としが起きます。「原文」「解釈」「提案書で答える場所」「確認要否」「担当」「根拠」の列を持つ要求事項対応表を作り、一つの要求に一つ以上の回答箇所を紐づけます。

質問期間が設定されている場合、曖昧な要件を独自解釈で埋めず、期限内に公平な手続で質問します。特定の職員から非公式に得た情報だけを提案の前提にしてはいけません。公開された質問回答は全提案者に共通する正式情報として再読し、見積条件やスケジュールも更新します。

現状分析では、単に「紙が多い」「効率が悪い」と書かず、対象業務、件数、繁忙期、処理時間、差戻し率、問い合わせ件数、利用者属性、既存システム、ネットワーク制約、関連部署を整理します。数値が提供されていない場合は推測を事実のように書かず、「ヒアリング後に基準値を確定する」「試算上の仮定」と明示します。

2. エグゼクティブサマリーの書き方

最初の1〜2ページで、審査者が提案全体を説明できる状態を目指します。次の順で簡潔にまとめます。

• 何が住民・職員の課題なのか
• どの考え方で解決するのか
• 何が変わり、どの指標で確かめるのか
• なぜ実現可能なのか
• 主要な費用、期間、体制、リスクは何か

例：「本提案は、申請者が同じ情報を繰り返し入力し、職員が複数台帳へ転記している状態を解消する。入力支援、本人確認、審査ワークフロー、通知、データ連携を段階導入し、窓口とオンラインを選べる状態を維持する。稼働後3か月で処理時間、差戻し率、電話問い合わせ、オンライン完了率を測定し、目標値は現状調査後に双方で確定する。」

「最新AIで全業務を自動化」「必ずコストを半減」といった根拠のない表現は避けます。AEOを意識するなら、「自治体向けシステム提案書とは何か」「何を最初に書くか」という質問に、冒頭だけで直接回答できる文章にします。

3. 課題と提案方針をつなぐ方法

課題は原因と症状を分けます。たとえば「問い合わせが多い」は症状であり、原因候補は案内の難しさ、処理状況が見えないこと、入力エラー、通知の遅れなどです。原因を確認せずチャットボットを置いても、問い合わせは減りません。課題ごとに「対象者」「発生場面」「影響」「原因仮説」「確認方法」を書きます。

提案方針は、各課題に対して一対一または一対多で対応させます。表にすると評価しやすくなります。

4. 機能提案の書き方

機能名だけでなく、利用者、開始条件、通常の流れ、例外、権限、入力、出力、保存、監査ログを説明します。画面イメージを使う場合は「提案時点の参考」であること、契約後の要件定義で確定することを記載します。標準機能、設定変更、追加開発、外部サービスを色や記号で区別し、費用と納期への影響を追えるようにします。

住民向け機能では、スマートフォン、低速回線、途中保存、多言語、やさしい日本語、読み上げ、キーボード操作、色以外の識別、エラー説明を検討します。デジタル利用が困難な人を排除しないよう、窓口、電話、代理申請など代替手段との関係も示します。

職員向け機能では、所属・職位・担当による権限、異動時の変更、兼務、代理承認、差戻し、取消し、一括処理、検索、帳票、統計、ログ確認を具体化します。「柔軟に対応」では評価できないため、設定可能な範囲と開発が必要な範囲を分けます。

5. 非機能・システム構成のポイント

非機能要件は「高性能」「安全」といった形容詞ではなく、対象、測定条件、目標、除外条件、測定方法で示します。可用性、性能、拡張性、バックアップ、復旧、監視、保守時間、脆弱性対応、ログ保存、時刻同期、データ暗号化、通信暗号化などを扱います。

構成図には利用者、端末、ネットワーク境界、認証、アプリケーション、データベース、外部連携、監視、バックアップ、管理者経路を記載します。インターネット系、LGWAN接続系、マイナンバー利用事務系などの扱いは自治体の構成・方針により異なるため、決めつけず確認事項として示します。クラウドサービスを使う場合は、責任共有、データ保管、再委託、障害通知、終了時のデータ返却・消去、監査資料の提供範囲も説明します。

性能目標の例は「通常時の主要画面について、想定同時利用者数とデータ量を前提に、応答時間を測定する」のように条件を伴わせます。根拠なく全操作の秒数を保証したり、外部サービスの応答まで自社保証に含めたりしないでください。

6. 個人情報保護とセキュリティ

自治体向けシステム提案書では、保有する情報の種類、利用目的、収集範囲、保存期間、アクセス権、第三者提供・委託・再委託、廃棄をデータライフサイクルとして示します。機微性の高い情報は、必要最小限性を説明します。本番データを安易に開発・テストへ複製せず、マスキングや合成データの利用方針を記載します。

セキュリティは、多要素認証、最小権限、職務分離、操作ログ、暗号化、脆弱性管理、マルウェア対策、インシデント対応、委託先管理、教育を多層で設計します。ゼロリスクを約束するのではなく、予防、検知、封じ込め、復旧、報告の流れを明らかにします。生成AIを利用する場合は、入力してよい情報、学習利用の有無、保存、リージョン、誤回答、人による確認、ログ、著作権等の論点を案件ごとに整理します。

準拠すべき条例、規程、ガイドラインの名称や版は、調達時点の発注資料を優先し、契約前に最新版と適用範囲を確認します。一般論だけで「法令に完全準拠」と断定しないことが重要です。

7. 公平性・調達への配慮

自治体調達では、審査の公平性と説明可能性が欠かせません。競合を不当におとしめる表現、実証できないNo.1表示、審査員への非公開の働きかけ、仕様にない無償提供による囲い込みは避けます。自社固有名称だけで説明せず、発注者が比較できる一般的な分類、提供範囲、条件を併記します。

オープンなデータ形式、API、データ辞書、移行ツール、契約終了時の返却条件を提示し、ベンダーロックインの懸念に答えます。ただし「完全にロックインなし」という抽象表現ではなく、標準形式で出力できるデータ、出力できない情報、作業費、期間、支援内容を記載します。

提案価格と提案内容を一致させます。提案書に書いた教育、移行、会議、ドキュメント、試験が見積に含まれるか、オプションかを明示します。評価対象の機能を「将来対応予定」とする場合、現時点の提供可否、時期の確度、追加費用を区別します。

8. 導入計画、移行、教育、試験

導入計画は、契約、キックオフ、要件定義、設計、構築、移行リハーサル、試験、研修、受入、稼働判定、稼働、安定化の依存関係を示します。自治体側の作業、承認期限、データ提供、関係者調整も書き、事業者だけで完了するように見せないでください。議会、予算、繁忙期、制度改正、人事異動、庁内審査などの制約を確認します。

データ移行は、対象、件数、品質、文字コード、重複、欠損、変換ルール、照合、リハーサル回数、切替、戻し方、旧環境の扱いを説明します。移行成功の判定基準を件数一致だけにせず、項目値、関連性、添付、権限、検索性をサンプリングまたは全件で確認します。

教育は、管理者、一般職員、ヘルプデスク、異動者など対象別に設計します。集合研修だけでなく、動画、操作ガイド、FAQ、演習環境、録画、更新方法を示します。試験は単体、結合、総合、性能、セキュリティ、移行、運用、受入の責任分担と証跡を明確にします。

9. 運用保守と引継ぎ

運用保守では、受付時間、連絡手段、優先度、一次回答、復旧目標、計画保守、監視、月次報告、問題管理、変更管理を示します。SLAはサービスレベルと測定方法、除外条件、未達時の扱いをセットで記載します。問い合わせ窓口の営業時間だけを「24時間365日監視」と混同しないようにします。

運用引継ぎは納品時だけでなく契約終了時も設計します。運用手順、構成、アカウント、証明書、ライセンス、未解決課題、障害履歴、変更履歴、データ、ソースコード等の扱いを整理し、後継事業者への説明会や並行期間の条件を示します。自治体が必要な情報へ継続してアクセスできることが重要です。

10. 効果、KPI、費用対効果

KPIは行政目的、利用、業務、品質の階層で考えます。オンライン申請数だけが増えても、完了できず窓口が増えるなら成功とはいえません。オンライン完了率、入力時間、差戻し率、審査時間、問い合わせ、満足度、アクセシビリティ上の問題、重大障害など複数指標で確認します。

効果試算は式を開示します。例として「年間削減時間＝対象件数×1件当たり削減時間」とし、対象件数と削減時間が仮定か実測かを示します。職員時間の削減を直ちに現金支出の削減とみなさず、政策立案や相談支援へ再配分できる時間として表現します。初期費用、経常費用、更新、通信、端末、外部サービス、職員作業を含む総保有コストの視点を持ちます。

11. 文章・図表・根拠の作り方

一文を短くし、主語と責任主体を明確にします。「対応する」「可能」と書く場合は、誰が、いつ、何を、どの条件で行うかを補います。略語は初出で正式名称を記載し、用語集で統一します。同じ機能を複数章で違う名称にしないでください。

図表には番号、タイトル、注記、出典、基準日を付けます。公開実績を引用するときは、対象規模、導入範囲、時期が今回と比較可能かを確認します。顧客名や画面を許可なく掲載してはいけません。生成AIを下書きに使う場合は、機密情報を入力せず、仕様との一致、数値、固有名詞、著作権、誤情報を人が検証します。

重要事項

1. 評価基準への対応箇所を明示し、審査者に探させない。
2. 必須要件、提案要件、参考情報を混同しない。
3. 標準、設定、追加開発、対象外を明示する。
4. 数値には算定根拠と測定条件を付ける。
5. 自治体側の役割と意思決定期限も計画に含める。
6. 個人情報の収集から消去までを説明する。
7. 障害時、災害時、契約終了時の対応を書く。
8. アクセシビリティを画面制作の最後ではなく要件から扱う。
9. 住民の選択肢を確保し、デジタルだけを強制しない。
10. 最新の法令、条例、ガイドライン、庁内規程を案件ごとに確認する。

禁止事項

• 仕様書の文章を理解せずコピーし、回答したように見せる。
• 実装未定の機能を標準機能として記載する。
• 条件や除外事項を小さな注記に隠す。
• 根拠なしに「100％安全」「障害ゼロ」「必ず削減」と断定する。
• 他自治体の個人情報、秘密情報、非公開画面を流用する。
• 価格に含まれない作業を本文で無条件に約束する。
• 職員・住民の操作負担を無視して技術の新しさだけを訴求する。
• 認証情報や本番データを提案書、デモ、生成AIへ入力する。
• 競争上の公平性を損なう非公式情報や接触に依存する。
• 様式、ページ数、提出期限、ファイル容量、署名等の指定を軽視する。

実務テンプレート

審査者別レビュー観点

提案書の完成前に、読む立場を変えてレビューします。業務原課は、現場の例外や繁忙期に耐え、住民対応が改善するかを確認します。情報政策部門は、既存基盤、ネットワーク、認証、データ連携、将来更新との整合を見ます。契約・財政部門は、提案範囲と価格、年度別負担、契約変更条件を確認します。個人情報・セキュリティ担当は、収集目的、権限、ログ、委託・再委託、事故時連絡を確認します。運用担当は、問い合わせ、障害、アカウント、定期作業、終了時引継ぎが実行可能かを見ます。

模擬審査では、実際の評価基準と配点を用い、回答箇所の頁を記録します。点数だけでなく「根拠がない」「条件が分からない」「見積と不一致」といった理由を残します。専門外の職員が短時間で読んでも、結論、責任主体、追加費用の有無を把握できるか確認してください。プレゼンテーションやデモがある場合も、提案書と異なる機能や未見積のサービスを即興で約束せず、回答不能な質問は確認事項として正式に持ち帰ります。

最終校正では、目次、頁番号、図表番号、参照先、用語、金額、日付を横断確認します。PDF化後にも文字化け、リンク、折返し、代替テキスト、検索可能性を確かめ、提出版のハッシュ値や版番号を記録すると誤提出防止に役立ちます。

提案概要テンプレート

行政目的：［実現したい住民価値・政策目的］
現状課題：［対象者／場面／事実／影響］
提案方針：［課題を解決する基本方針］
提供範囲：［標準機能／設定／追加開発／連携／対象外］
期待効果：［指標、基準値、目標、測定時期］
実施期間：［開始、主要マイルストーン、稼働予定］
体制：［責任者、主要担当、自治体との役割分担］
主要リスク：［リスク、予防策、発生時対応］
費用：［初期、経常、オプション、前提条件］

要求事項対応表テンプレート

リスク記載テンプレート

リスク：既存データの欠損により移行確認が遅れる。
兆候：必須項目の空欄、コード体系の不一致が基準を超える。
予防：初期段階でデータ診断を行い、補正責任を合意する。
対応：対象を分類し、補正、保留、個別移行を選択する。
責任者：事業者移行責任者／自治体データ責任者
期限・判定：移行リハーサル前に未確定件数を合意する。

実務チェックリスト

提出条件

• [ ] 公告、要領、仕様書、質問回答、様式の最新版を確認した
• [ ] ページ数、用紙、文字、ファイル形式、容量、提出方法を満たした
• [ ] 提出期限とアップロード・持参等の所要時間を確認した
• [ ] 会社名を伏せる指定、押印、電子署名等の条件を確認した

内容と整合

• [ ] 全要求に回答し、要求事項対応表と本文頁が一致する
• [ ] 標準、設定、追加開発、外部サービス、対象外を区別した
• [ ] 提案、見積、スケジュール、体制、成果物の内容が一致する
• [ ] 数値、実績、製品仕様に根拠と基準日がある
• [ ] 自治体作業、承認、データ提供の期限を記載した

公共性と品質

• [ ] デジタル利用が困難な人への代替手段を考慮した
• [ ] アクセシビリティと多様な利用環境を要件化した
• [ ] 個人情報の最小化、権限、ログ、保存、消去を示した
• [ ] 災害、障害、サイバーインシデントの対応を示した
• [ ] 移行、教育、運用、契約終了時の引継ぎを示した
• [ ] 最新の条例、国のガイドライン、自治体規程を確認する工程がある

FAQ：自治体向けシステム提案書のよくある質問

Q1. 自治体向けシステム提案書で最初に書くべきことは何ですか。

行政目的と住民・職員の課題、その課題をどう解決し、何を指標に成果を確認するかです。製品紹介から始めるより、発注者の目的への回答を先に示すと理解されやすくなります。

Q2. システム提案書の適切なページ数はありますか。

指定があれば厳守します。指定がなければ、評価項目へ過不足なく回答できる量にします。付録へ詳細を分けても、本文だけで結論が分かる構成が必要です。

Q3. 仕様が曖昧な場合はどう書けばよいですか。

質問期間中に正式に確認します。解消しない場合は、採用した前提、代替案、費用・納期への影響、要件定義での確定方法を明記し、独自解釈を隠さないでください。

Q4. 他自治体の導入実績はどのように示しますか。

許可された範囲で、自治体規模、対象業務、導入時期、提供範囲、得られた効果を示します。今回との違いも書き、名称や数だけで同等性を主張しないことが大切です。

Q5. AIを含む提案のポイントは何ですか。

利用目的、入力可能な情報、人の確認、誤回答対策、ログ、学習利用、保存、権限、停止方法、効果測定を示します。AIが最終判断を行う範囲は慎重に検討し、説明責任と救済手段を設計します。

Q6. セキュリティはどこまで詳しく書きますか。

公開して差し支えない範囲で、要求への対応、責任分担、運用、証跡を具体化します。攻撃に悪用され得る詳細や認証情報は提案書へ載せず、必要に応じ秘密保持下の別資料とします。

Q7. アクセシビリティは何を提案すればよいですか。

対象とする基準、設計・実装・試験の方法、試験範囲、不適合時の修正、公開後の維持を示します。読み上げやキーボード操作だけでなく、理解しやすい文章、エラー回復、代替手段も扱います。

Q8. 費用対効果はどう算定しますか。

件数、時間、単価など計算式と根拠を開示し、仮定と実測を区別します。金銭効果だけでなく、待ち時間、正確性、災害対応、職員の政策業務への再配分など公共価値も示します。

Q9. ベンダーロックインへの回答はどう書きますか。

データ出力形式、API、ドキュメント、移行支援、知的財産、契約終了時の費用と期間を具体的に書きます。自治体が後継事業者へ引き継げる成果物と、提供できない範囲を明確にします。

Q10. 提案書完成後のレビューは誰が行いますか。

営業だけでなく、業務、技術、セキュリティ、運用、法務・契約、見積の各担当が確認します。最後に初見の読者が評価基準に沿って模擬採点し、矛盾と探しにくさを修正します。

まとめ

自治体向けシステム提案書の書き方は、派手な表現よりも、要求への忠実な回答と根拠の透明性が中心です。行政目的から課題、機能、非機能、導入、運用、費用、効果までを一本の線でつなぎます。公平な調達、個人情報保護、セキュリティ、アクセシビリティ、運用引継ぎを後付けにせず、提案の中心に置いてください。案件ごとに最新の法令、条例、国のガイドライン、自治体の情報セキュリティポリシー等を確認し、実現可能で比較可能な自治体向けシステム提案書に仕上げることが、採択後の信頼と成功につながります。