官公庁のPoC・プロトタイプ・モックアップは、確かめたい対象で使い分けます。単年度予算を踏まえて計画し、KPIを決めておけば、本格導入の判断材料を得られます。
期間と費用は、試作の範囲や住民テストの有無、既存サービスの活用で変わります。全体像は官公庁のシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
官公庁におけるPoC・プロトタイプ・モックアップ開発の位置づけと種類
官公庁のPoC・プロトタイプ・モックアップは、役割も予算の仕組みも異なります。それぞれの違いと単年度予算の影響を押さえておくと、企画の段階でつまずきにくくなります。
総務省は平成30年度から毎年度、地方自治体のAI・RPAの実証実験と導入状況を調査しています。令和5年度からは生成AIの実証状況も対象に加わり、実証事業は行政DXの標準的な入り口として定着しつつあります。
実証事業（PoC）予算の仕組みと単年度実証の特徴
官公庁のPoCは、会計年度独立の原則と予算の出どころを踏まえて組み立てる必要があります。
- 単年度予算：原則として年度内に執行し、成果もその年度中にまとめます。
- 予算の出どころ：自治体や省庁の予算か、上位機関の補助金・交付金のどちらかです。
- 翌年度の予算：継続や本格導入には、改めて予算計上が必要です。
会計年度は4月から翌年3月までです。
実証は多くの場合、「令和◯年度実証事業」として単年度で予算化され、年度内に検証と成果のとりまとめまで行います。民間企業は経営判断で検証期間を柔軟に延ばせますが、行政には年度末という区切りがあります。
国の先進無線システム活用タイプなどでは、補助金の下限が原則1千万円の枠組みもあり、一定規模以上の実証が求められる場合があります。
ガバメントクラウドは令和6年度まで国が実証費用を負担し、令和7年度以降は利用に応じて各利用者が負担する仕組みに変わりました。この負担の切り替わりは、予算計画に織り込んでおく必要があります。
単年度実証は短期間で成果を出す必要があります。一方で、年度ごとに区切れるため、コストの膨張を防ぎ、継続の可否を判断できます。
年度をまたぐ場合は、翌年度の予算に実証費用や導入費用を計上します。予算要求の時期を逃すと、プロジェクトが1年以上空白になるおそれがあります。そのため、企画の段階から翌年度以降の予算スケジュールを逆算しておきます。
PoCの種類（UI/UXプロトタイプ・技術検証PoC・住民向けモックアップ）
実証の種類は、確かめたい対象に合わせて選びます。画面、技術、サービス設計では、検証する内容がそれぞれ異なります。
- UI/UXプロトタイプ：住民向け画面の使いやすさを確かめる試作。
- 技術検証PoC：新技術の精度や適用可能性を調べる実証。
- 住民向けモックアップ：画面を使ったサービス設計の検証。
市民ポータル、マイページ、申請フォームなどを住民に操作してもらい、課題を洗い出します。モックアップは、見た目やレイアウトを確かめる静的な試作物です。
これに対して、プロトタイプは画面遷移や操作の流れまで作り込み、利用者が目的を達成できるかを検証します。
技術検証では、AI-OCRの手書き帳票の読み取り精度や、RPAによる定型業務の自動化の度合いを確かめます。さらに、生成AIでは、問い合わせ対応や文書作成に適用できるかも検証します。
東京都三鷹市は、NTT東日本と組み、AI-OCRによる帳票のデジタル化とRPAによる業務自動化を検証しました。また、福島県郡山市でも、OCR-RPAとAIを組み合わせ、入所事務の効率化と迅速化を目指す実証が行われました。
東京都は2021年9月に都庁職員向けの「ユーザーテストガイドライン」を公開しました。「テストしないものはリリースしない」を掲げ、2023年1月にバージョン2.0へ改訂しています。この改訂では、従来のユーザビリティテストに加え、上流工程のリサーチとプロトタイピングも都のユーザーテストに位置づけました。
令和6年度調査（12月31日現在）では、生成AIを導入済みとの回答が、都道府県で87.2%、指定都市で90.0%でした。目的に応じて検証の種類を明確にすることが、実証設計の出発点です。
PoC・プロトタイプ開発の期間・費用の目安
実証予算では、PoCやプロトタイプの期間と費用を事前に見ておくことが欠かせません。UI検証の試作と新技術PoCに分けると、一般的な目安が見えてきます。
官公庁案件は、要件定義や個人情報の扱い、調達手続きで民間より工数が増える傾向があります。基準となる目安は、予算要求の説明にも役立ちます。
プロトタイプ／モックアップ開発の期間・費用感
試作範囲と住民テストの有無が、プロトタイプやモックアップの費用と期間を左右します。
- 静的モックアップ：数枚から十数枚の画面なら、数週間で用意できる場合があります。
- 操作可能な試作：画面遷移まで作る場合の目安は、1〜3か月程度です。
- 開発費：少人数・短期間なら、100万〜400万円程度が多く見られます。
エンジニア単価は、一般に1人月あたり80万〜120万円が相場とされています。また、住民向けサービスでユーザーテストの設計と実施まで含めると、期間と費用が上乗せされます。
費用を抑えるには、仮説の検証に必要な画面や機能に絞り込みます。最小限の画面で住民の反応を確かめてから作り込む進め方は、無駄な開発を避けるうえで有効です。さらに、フィードバックをもとにUIを改善しておくと、リリース後の大規模改修リスクを減らせます。
開発費に加えて、要件整理の打ち合わせ、テスト参加者への謝礼、検証環境の構築費用も見込んでおく必要があります。特に、個人情報を扱う場合は、環境の分離やセキュリティ要件も費用に影響します。
実証では、本番データの代わりにダミーデータを使う方法があります。ただし、実データを使う場合も、範囲を限定してコストとリスクを抑える工夫が採られます。
新技術（AI-OCR・RPA・生成AI等）検証PoCの期間・費用感
AI-OCR、RPA、生成AIの検証PoCは、既存のクラウドサービスやパッケージ製品を活用できるかどうかで、期間と費用が変わります。
- SaaSの試用：2〜3か月程度で、月額利用料を中心に始められることがあります。
- 本格的な技術検証：3〜6か月、数百万円規模に及ぶことがあります。
- 導入判断：実証費用だけでなく、年間の運用費も試算の対象にします。
総務省の調査では、実証段階は無償試用や低コストが多い一方、本格実装時には予算確保が課題になる傾向があります。実証の入り口が低コストでも、導入時の費用増には注意が必要です。
独自データの精度検証や複数システムとの連携では、要件整理、環境構築、結果分析が必要になります。さらに、生成AIでは、プロンプト設計や出力の評価、機密情報を含めない工夫にも工数がかかります。
AI関連の開発費が高めになる背景には、データ準備やチューニングの手間があります。全庁展開でライセンス費や保守費が想定を超えると、本予算化の壁になります。
対象業務の件数や職員数をもとに、導入時の年間ランニングコストを試算します。その規模をベンダーと共有しておくと、本格導入の予算要求を進めやすくなります。
「PoC疲れ」を防ぎ本格導入につなげるためのポイント
PoC疲れは、実証を繰り返して本格導入に進めず、検証コストだけがかかる状態です。また、良い結果が出ても先に進まず、別の部署が似た実証を繰り返すことがあります。この問題を防ぐには、導入への移行プロセスと、その鍵となる評価基準・KPI設計を押さえることが欠かせません。
実証事業から本予算化・調達仕様書反映への移行プロセス
行政特有の予算サイクルを理解し、そこから逆算して、成果を予算要求に間に合わせます。
- 予算日程を逆算：翌年度に導入するなら、前年度夏までに中間成果をまとめます。
- 仕様を具体化：実証結果を機能・性能・連携要件に反映します。
- 効果を記録：本格導入を判断する定量的な材料を集めます。
自治体の翌年度予算は、前年の夏から秋に要求が始まり、査定を経て年明けに議会審議、3月頃に成立する流れが多く見られます。
PoC疲れを防ぐうえで最も大切なのは、予算日程と合わせることです。年度末まで実証を続けてしまうと、要求の時期を逃して導入が1年先送りになることがあります。
実証で得た知見は、本格導入の調達仕様書に反映します。仕様書の記載が曖昧だと、発注者と受注者の認識にずれが生じます。
実証では、必要な機能や精度・性能の水準を確かめます。例として、AI-OCRなら、読み取り精度の実測値を要求水準に反映できます。
本格導入の稟議や予算要求では、財政部門や上層部を説得する材料が欠かせません。そのため、業務時間の削減割合や年間の人件費相当の効果を、実証の段階から集めておきます。実証は、導入判断と本調達の仕様づくりに向けた情報収集の場と位置づけます。
評価基準・KPI設計（費用対効果・住民満足度）の重要性
評価基準がないと、実証結果を解釈できず、本格導入を判断しにくくなります。このため、KGIから逆算して、途中経過を測るKPIを設定します。
- 業務効率化：処理時間の削減率を測ります。
- 住民サービス：手続き完了率や住民満足度を指標にします。
- 費用対効果：導入・運用コストと投資回収年数を比べます。
目標は、達成を判定できる数値にします。例として、申請1件あたりの処理時間を3割削減する目標があります。
窓口の待ち時間を平均何分短縮するかも、目標の一例になります。削減時間を人件費相当額に換算し、導入費・運用費と比べると、財政部門への説明がしやすくなります。
机上の理論値と実測値を混同すると、効果を過大に見積もってしまいます。さらに、複数の施策が同じ業務に影響する場合は、効果を重複して計上しないよう切り分けます。
定性的な住民満足度も、アンケートの5段階評価などで定量化して記録すると、導入判断の根拠になります。加えて、実証結果に応じてKPIを見直すことも、実態に即した評価につながります。
PoC実施時に注意すべきリスクと対策
実証は本番導入よりリスクが小さいと思われがちですが、官公庁特有の注意点もあります。特に、範囲の肥大化や出口の欠如は、実証がつまずく要因です。こうしたリスクには、それぞれ対策があります。
スコープの肥大化・目的の曖昧化を防ぐ方法
実証の範囲、成功条件、期間を関係者と共有しておくと、途中で判断できる状態になります。
- 仮説を絞る：検証対象を一つか二つに限定し、他は次の課題にします。
- 目的をそろえる：計画書に目的・項目・成功基準・体制を記し、開始時に全員で合意します。
- 中間レビュー：進捗を確かめ、必要なら実証を早めに終えます。
実証の途中では、「この機能も」「別部署の業務も」といった要望が加わり、範囲が膨らむことがあります。
範囲が広がると、限られた予算と期間では検証しきれず、仮説に結論が出ないこともあります。そこで、対象を文書で合意しておけば、追加の要望を管理しやすくなります。
目的の曖昧化も、PoC疲れの典型的な要因です。現場、管理職、ベンダーの認識がずれると、本格開発へ進めないこともあります。また、AIでは、期待が先行して成功条件が定まらないまま、実証が始まるケースもあります。
長すぎる実証はコストと意欲を損ない、短すぎる実証はデータ不足を招きます。そのため、仮説に必要な期間を逆算し、中間レビューで方向性を確かめます。
中間レビューの結果が芳しくなければ、早期終了も選択肢です。これにより、限られた予算を有効に使えます。
本格導入を見据えたベンダー選定・調達仕様への反映
実証に協力するベンダーは、本格導入も見据えて選びます。競争性や成果の引き継ぎを考えながら、仕様と権利関係も整えておきます。
- ロックインを避ける：他社製品へ切り替えられる仕様にします。
- 調達仕様に反映：実証結果を機能・性能・要件に落とし込みます。
- 成果を引き継ぐ：データや成果物の権利を契約で定めます。
行政調達では、公平性と競争性が求められます。そのため、実証を担当したベンダーが、本格導入も受注できるとは限りません。
仕様書では、機能と性能を明確にするとともに、セキュリティとシステム連携の要件も定めます。実証の段階で、契約期間や導入日程を確かめ、データ移行と並行稼働期間の見込みも立てておくと、本調達の精度が上がります。
成果物やデータを導入時に使えないと、一から作り直すことになり、実証への投資が無駄になります。こうした無駄を避けるには、契約や体制を整えて、導入後も成果物やデータを使えるようにします。
官公庁向けPoC・プロトタイプ開発の進め方と体制づくり
技術の準備に加えて、企画段階の関係者調整と、内製・外部委託の使い分けが必要です。推進体制は、実証の質と導入への移りやすさを左右します。
PoC実施までの企画・要求整理と関係者調整
企画では、業務課題と利用者ニーズを整理し、そのうえで関係者と庁内手続きを押さえながら、要求をまとめます。
- 課題を特定：技術ありきにせず、解決する業務課題を言語化します。
- 関係者と合意：原課・情報システム・財政部門などと早期に共有します。
- 手続きを見込む：個人情報やセキュリティ審査の期間を予定に含めます。
職員や住民の課題を調べると、検証すべき仮説が具体化します。逆に、上流のリサーチを軽視すると、動くものができても現場で使われないことがあります。
関係者には、業務を所管する原課、情報システム部門、財政部門が含まれます。場合によっては、住民や外部有識者も加わります。
目的や進め方を共有しないと、途中で反対が起きて実証が止まることがあります。導入につなげる場合は、狙いと効果を企画段階から財政部門へ伝えておきます。
個人情報を扱う実証では、保護に関する審査や手続きに時間がかかる場合があります。こうした審査が想定以上に長引けば、検証期間が圧迫されます。そのため、単年度で成果を出せるよう、庁内手続きに必要な期間もスケジュールに織り込んでおきます。
内製・外部委託（ベンダー活用）の使い分け
技術の難易度と庁内のリソースをもとに、内製と外部委託を選び分けます。ただし、どちらを選ぶ場合でも、職員が主体性を保つことが大切です。
- 内製：小規模な実証では、職員にノウハウが蓄積します。
- 外部委託：専門的な検証や作り込みで、外部の知見を生かします。
- 共同実証：自治体間やベンダーとの連携で、負担を分け合う形です。
ノーコード・ローコードや汎用SaaSを使う小規模な実証は、職員主体で進められる場合があります。業務を知る職員が手を動かすと、課題への理解と庁内のノウハウが深まります。
専門的な技術検証や、導入を見据えた作り込みでは、専門ベンダーの知見が限られた期間での成果につながります。
総務省の調査では、ICT人材の不足や、単独の自治体でのAI対応の難しさが課題とされています。そこで、複数の自治体や外部ベンダーと連携すれば、リソースやコストを分担できます。
委託しても、職員がプロセスに関わり、結果の解釈と導入判断を担います。あわせて、行政の予算・調達・個人情報の制約を理解しているベンダーかどうかも、選定時に確かめます。
まとめ
官公庁のPoCは、新技術の不確実性を限られたリスクで確かめ、本格導入の判断材料を得る手法です。モックアップは見た目、プロトタイプは使い勝手、技術検証PoCは実現可能性を、それぞれ確かめます。
小規模な試作やSaaS実証は数百万円程度から始められますが、導入後のランニングコストも試算します。そのうえで、単年度予算から逆算し、明確なKPIで効果を記録します。
実証結果を調達仕様書と導入判断に活用し、スコープや目的を管理します。そして、ベンダー選定と体制づくりを通じて、実証の成果を本格導入へ引き継ぎます。
▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。