— GUIDE
自治体のためのWeb3/AI実証の
進め方ガイド
構想 → 実証(PoC) → 評価 → 調達・本格導入の手順とチェック観点
自治体・公共セクターがWeb3・AIの実証を進める際に、各フェーズで整理すべき事項と確認観点を4ステップでまとめた実務ガイドです。構想段階の課題整理から、PoCの設計・実施、評価、そして調達・本格導入までを通して参照できるよう構成しています。
特定の技術や製品に依存した記述は避け、自治体の調達・法令対応・庁内合意形成の観点から、一般的に押さえておくべき論点を整理しています。
— 01
本資料の使い方
このガイドは4ステップ構成で、合計40のチェック観点を整理しています。
- 第2章: ステップ1 — 構想整理（10項目）
- 第3章: ステップ2 — 実証(PoC)の設計と実施（10項目）
- 第4章: ステップ3 — 評価（10項目）
- 第5章: ステップ4 — 調達・本格導入（10項目）
各項目はYes / No / 未確認 で評価し、フェーズ移行前に担当者間で状態を共有する使い方を想定しています。すべてYesである必要はありません。未確認項目をリストアップし、リスクとして認識した上で次フェーズに進むことも選択肢の一つです。
要点
- ・40項目を4ステップに分割
- ・Yes / No / 未確認 で評価
- ・未確認項目をリスクとして把握した上でフェーズを進める
— 02
ステップ1: 構想整理
実証の目的と対象課題を明確にし、庁内合意の土台をつくるフェーズです。
「どの業務課題に対して、なぜWeb3・AIが有効なのか」を言語化します。技術選定より先に、課題の輪郭を整えることが、その後の実証設計と調達の精度を左右します。
- 1
解決したい業務課題が1〜2文で説明できる
YesNo未確認 - 2
Web3・AIでなければ解けない理由が説明できる（既存システムとの差分）
YesNo未確認 - 3
対象業務の担当部署と関係者が把握されている
YesNo未確認 - 4
住民・企業など外部ステークホルダーへの影響範囲が整理されている
YesNo未確認 - 5
法令・条例・個人情報保護規制との整合確認の担当者が決まっている
YesNo未確認 - 6
首長・議会への報告フローと説明責任の範囲が確認されている
YesNo未確認 - 7
予算区分（補助金・一般財源・共同調達等）の候補が挙がっている
YesNo未確認 - 8
担当部署の主管者と技術窓口が1名ずつ決まっている
YesNo未確認 - 9
外部有識者・研究機関・他自治体との連携可能性を確認した
YesNo未確認 - 10
「実証しない」という選択肢も含め、判断基準を事前に共有している
YesNo未確認
要点
- ・課題の言語化が先。技術選定は後
- ・法令・規制の確認担当を早期に確保
- ・判断基準（やらない条件）を事前合意
— 03
ステップ2: 実証(PoC)の設計と実施
限定スコープで技術・運用の実現可能性を検証するフェーズです。
実証(PoC)は、技術の展示ではなく「業務上の仮説を検証する場」として設計します。スコープを絞り、検証期間・KPI・撤退条件を事前に定めることで、実証後の意思決定をスムーズにします。
- 1
検証する仮説が3項目以内に絞られている
YesNo未確認 - 2
実証のスコープ（対象業務・対象データ・参加者数）が文書化されている
YesNo未確認 - 3
KPIと計測方法が定義されている（例: 処理時間・担当者の手作業件数）
YesNo未確認 - 4
実証期間（開始日・終了日）と中間レビューの日程が決まっている
YesNo未確認 - 5
撤退・縮小判断の基準が事前に合意されている
YesNo未確認 - 6
データ取り扱い（個人情報の匿名化・保管場所・廃棄手順）が整理されている
YesNo未確認 - 7
システム提供側との役割分担・責任範囲が文書で確認されている
YesNo未確認 - 8
実証中のインシデント対応フロー（障害・情報漏洩）が用意されている
YesNo未確認 - 9
実証参加者（職員・住民等）への説明と同意取得が完了している
YesNo未確認 - 10
議会・上位機関への進捗共有の頻度とフォーマットが決まっている
YesNo未確認
要点
- ・仮説・KPI・撤退条件を事前に文書化
- ・データ取り扱いルールは実証開始前に確定
- ・中間レビューで軌道修正できる設計にする
— 04
ステップ3: 評価
実証結果を整理し、本格導入・見直し・中止のいずれかを判断するフェーズです。
PoCで得たデータと知見を、事前に定めたKPIと照合して評価します。「技術が動いた」ではなく「業務課題が改善できる見通しが立ったか」を判断軸に置きます。結果の記録は、今後の調達・議会説明・他自治体との情報共有にも活用できます。
- 1
実証開始前に定めたKPIとの比較が行われた
YesNo未確認 - 2
実証参加者（職員・住民等）からのフィードバックが収集された
YesNo未確認 - 3
セキュリティ・プライバシー面で問題がなかったことが確認されている
YesNo未確認 - 4
本格導入した場合の運用体制（人員・予算・保守）の見通しが立った
YesNo未確認 - 5
本格導入しない場合の理由・学びが文書化された
YesNo未確認 - 6
コスト試算（初期費用・ランニングコスト）が更新されている
YesNo未確認 - 7
類似自治体の先行事例と比較した検討が行われた
YesNo未確認 - 8
実証ベンダーとの守秘義務・知財の取り扱いが契約通り履行された
YesNo未確認 - 9
評価結果を首長・議会・市民向けにどの範囲で公開するかが決まっている
YesNo未確認 - 10
次フェーズ（調達・本格導入）への移行判断が担当者間で合意された
YesNo未確認
要点
- ・評価軸は「業務課題の改善見通し」
- ・中止判断も記録して次の調達資料に活用
- ・公開範囲を決めて透明性を確保
— 05
ステップ4: 調達・本格導入
PoCの知見をもとに、適切な調達手続きで本番システムを導入するフェーズです。
自治体の調達は、入札・プロポーザル・随意契約など複数の手続きが存在します。実証で得た仕様情報が特定ベンダーへの依存（ロックイン）につながらないよう、調達仕様の中立性に注意が必要です。
- 1
調達方式（一般競争入札・公募型プロポーザル・随意契約等）が確定している
YesNo未確認 - 2
調達仕様書がベンダー中立の記述になっている（特定製品名に依存しない）
YesNo未確認 - 3
評価基準（技術点・価格点の配点）が事前に公表されている
YesNo未確認 - 4
PoC実施ベンダーが本調達に参加する場合の公平性確保策が講じられている
YesNo未確認 - 5
システム移行・データ移行計画が仕様に含まれている
YesNo未確認 - 6
保守・運用フェーズのSLA（可用性・障害対応時間）が明記されている
YesNo未確認 - 7
契約終了・業者変更時のデータ返還・システム引継ぎ条件が明記されている
YesNo未確認 - 8
住民・企業向けの導入説明・広報計画が策定されている
YesNo未確認 - 9
本格導入後のKPI計測・定期評価の体制が用意されている
YesNo未確認 - 10
将来的な機能拡張・他システム連携の際の変更管理手続きが整理されている
YesNo未確認
要点
- ・仕様書のベンダー中立性を確認
- ・引継ぎ・データ返還条件を契約に明記
- ・導入後のKPI計測体制を事前に用意
— 06
集計シートの使い方
各ステップ10項目について、Yes / No / 未確認 を選択し、集計シートでフェーズごとの準備状態を把握します。
| 章 | フェーズ | 項目数 | Yes | No | 未確認 |
|---|---|---|---|---|---|
| 第2章 | 構想整理 | 10 | — | — | — |
| 第3章 | 実証(PoC)設計・実施 | 10 | — | — | — |
| 第4章 | 評価 | 10 | — | — | — |
| 第5章 | 調達・本格導入 | 10 | — | — | — |
| 合計 | 40 | — | — | — | |
各フェーズの移行判断の目安は次のとおりです。
各ステップ7項目以上確認済
次フェーズへ移行できる状態
未確認項目をリスクとして記録した上で、次のフェーズへ進める
各ステップ4〜6項目確認済
主要論点は押さえている
未確認項目を優先整理してから次フェーズへ移行することを推奨
各ステップ3項目以下
構想・体制の整理が不足
庁内の合意形成と担当者の確定を先に行うことを推奨
— 07
Netsujoへのご相談
このガイドの活用は、庁内だけで完結する場合も、外部支援を受ける場合も両方を想定しています。「どのステップから始めるべきか」「未確認項目が多く整理が進まない」という場合は、初回30分の無料相談でご一緒に論点を洗い出します。
支援の標準範囲は以下です。
- ・構想整理（課題の言語化・ステークホルダー整理）
- ・PoC設計（仮説・KPI・スコープ・撤退基準の文書化）
- ・調達仕様書のレビュー・ベンダー中立性の確認
- ・評価レポートの作成支援