官公庁のシステム開発のPoC・プロトタイプ・モックアップ開発について

官公庁のシステム開発において、いきなり本番システムを構築するのではなく、まずは小規模に「試してみる」ためのPoC（概念実証）やプロトタイプ、モックアップの開発が近年ますます重要になっています。生成AIやAI-OCR、RPAといった新しい技術が次々と登場する一方で、行政の現場には「本当に自分たちの業務で効果が出るのか」「住民に受け入れられるのか」といった不確実性がつきまといます。こうした不確実性を、限られた予算とリスクの範囲で見極めるための手法がPoC・プロトタイプ・モックアップ開発です。実際、総務省は平成30年度から毎年度、地方自治体におけるAI・RPAの実証実験・導入状況を調査しており、令和5年度からは生成AIの実証状況も調査対象に加えるなど、実証事業は行政DXの標準的な入り口として定着しつつあります。

ただし、官公庁のPoC・プロトタイプ開発には、民間企業とは異なる独特の難しさがあります。最大の特徴は、予算が原則として単年度で区切られる「会計年度独立の原則」の下で運用される点です。実証事業として組まれた予算はその年度内に使い切ることが前提であり、翌年度の本格導入には改めて予算要求と稟議、調達手続きを経なければなりません。この構造が、実証で良い結果が出ても本格導入に至らない、いわゆる「PoC疲れ」を生みやすい土壌になっています。本記事では、「PoCにはどれくらいの期間・費用がかかるのか」「PoCで終わらせず本格導入につなげるにはどうすればよいか」という担当者の疑問に答えながら、官公庁ならではの実証事業の進め方と注意点を、具体的な数字や事例を交えて解説していきます。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド

官公庁におけるPoC・プロトタイプ・モックアップ開発の位置づけと種類

まずは、官公庁におけるPoC・プロトタイプ・モックアップがそれぞれどのような役割を担い、どのような予算の仕組みの下で実施されるのかを整理します。三つの手法は言葉が似ているため混同されがちですが、検証する対象が異なります。ここを正しく理解することが、実証事業の企画段階でつまずかないための第一歩となります。あわせて、行政特有の単年度予算という制約が、実証事業の設計にどのように影響するのかも押さえておきましょう。

官公庁のPoCを理解するうえで最も重要なのが、予算の仕組みです。国や自治体の予算は会計年度独立の原則に基づき、4月から翌年3月までの単年度で区切られ、その年度に計上された予算は原則としてその年度内に執行しなければなりません。実証事業もこの原則の中で組まれるため、多くの場合「令和◯年度実証事業」として単年度で予算化され、年度内に検証を終えて成果を取りまとめる流れになります。これが民間企業のPoCと大きく異なる点で、民間であれば経営判断次第で検証期間を柔軟に延長できますが、行政では年度末という明確な区切りが常に存在します。

実証事業の予算は、大きく分けて自治体・省庁が自らの予算で実施するケースと、上位機関からの補助金・交付金を活用するケースがあります。例えば国の実証事業では、先進無線システムの活用タイプなどにおいて補助金の下限が原則1千万円と設定されている枠組みもあり、一定規模以上の実証が求められることもあります。また、ガバメントクラウドの利用については、令和6年度までは国の実証事業として国が費用を負担していましたが、令和7年度以降は利用に応じて各利用者が負担する仕組みへと転換されました。このように、実証段階では国の負担で始まったものが、本格運用段階では自治体の自己負担に切り替わるという構造も、予算計画上あらかじめ見込んでおく必要があります。

単年度実証には、短期間で成果を出さなければならないというプレッシャーがある一方で、メリットもあります。年度ごとに区切ることで、無限にコストが膨らむことを防ぎ、その都度成果を検証して次年度に継続するかどうかを判断できる点です。裏を返せば、年度をまたいで検証を続けたい場合には、翌年度予算に改めて実証費用や本格導入費用を計上する必要があり、この予算要求のタイミングを逃すと1年以上プロジェクトが空白になってしまうリスクがあります。実証事業を企画する段階から、翌年度以降の予算スケジュールを逆算して動くことが、行政のPoCでは欠かせません。

官公庁で行われる実証は、検証したい対象によって性質が異なります。第一に、住民向けサービスの使いやすさを確かめるUI/UXプロトタイプ検証があります。これは、市民ポータルやマイページ、申請フォームなどの画面を試作し、実際の住民に操作してもらって課題を洗い出すものです。モックアップが主に画面の見た目やレイアウトを確認するための静的な試作物であるのに対し、プロトタイプは画面遷移や操作の流れまで作り込み、利用者が本当に目的を達成できるかを検証します。つまりモックアップは「どう見えるか」、プロトタイプは「どう使えるか」を確かめるものだと整理すると分かりやすいでしょう。

第二に、新技術の実現可能性を確かめる技術検証PoCがあります。AI-OCRで手書き帳票をどこまで正確に読み取れるか、RPAで定型業務をどの程度自動化できるか、生成AIが問い合わせ対応や文書作成に耐えうるかといった、技術そのものの精度や適用可能性を見極めるタイプです。例えば東京都三鷹市ではNTT東日本と共同で、AI-OCRで実際の帳票をデジタル化し、その後の業務プロセスをRPAで自動化する一連の流れを検証する実証を行いました。福島県郡山市でもOCR-RPAツールとAIツールを組み合わせ、入所事務の効率化・迅速化を目指す実証が実施されています。

第三に、住民向けモックアップを用いたサービス設計の検証があります。東京都では2021年9月に都庁職員向けの「ユーザーテストガイドライン」を公開し、「テストしないものはリリースしない」を合言葉に、2023年1月にはバージョン2.0へと改訂しました。この改訂では、従来のユーザビリティテストに加えて、開発の上流工程で行うリサーチとプロトタイピングを、都が実施するユーザーテストとして新たに位置づけています。生成AIについては、令和6年度調査（12月31日現在）で都道府県の87.2%、指定都市の90.0%が導入済みと回答しており、多くの団体が実証を経て本格活用へと進んでいる状況がうかがえます。このように、目的に応じてどの種類の検証を行うのかを明確にすることが、実証事業設計の出発点となります。

PoC・プロトタイプ開発の期間・費用の目安

実証事業の予算を組む際に最も気になるのが、PoCやプロトタイプの開発にどれくらいの期間と費用がかかるのかという点です。ここでは、UI検証を目的としたプロトタイプ・モックアップ開発と、新技術の技術検証PoCに分けて、一般的な相場観を示します。もちろん官公庁案件は要件定義や個人情報の取り扱い、調達手続きなどで民間より工数がかさむ傾向がありますが、まずは基準となる目安を持っておくことで、予算要求時の説得力が増します。

画面の見た目を確認するモックアップであれば、比較的短期間で作成できます。デザインツールを使った静的なモックアップであれば、対象画面が数枚から十数枚程度であれば数週間で用意できることも珍しくありません。一方、操作や画面遷移まで作り込むプロトタイプになると、対象範囲にもよりますが1〜3か月程度をみておくのが現実的です。エンジニアの単価は一般に1人月あたり80万円から120万円が相場とされており、少人数で短期間のプロトタイプ開発であれば、おおむね100万円から400万円程度の範囲に収まるケースが多く見られます。

ただし、官公庁の住民向けサービスの場合、単に画面を作るだけでなく、実際の住民を対象としたユーザーテストの設計・実施までを含めると、その分の期間と費用が上乗せされます。プロトタイプ開発では、機能を盛り込みすぎると開発期間もコストも一気に膨らむため、検証したい仮説に直結する画面や機能に絞り込むことが費用を抑えるうえで重要です。アジャイル的にスモールスタートし、最小限の画面で住民の反応を確かめてから作り込みを進める進め方が、無駄な作り込みを避けるうえで有効です。実際に操作した住民のフィードバックを反映してUIを改善できる点が、プロトタイプ検証の最大の価値であり、この工程を丁寧に行うことでリリース後の大規模な改修リスクを減らせます。

費用を計画する際には、開発費そのものだけでなく、要件整理のための打ち合わせ工数や、テスト参加者への謝礼、検証環境の構築費用なども忘れずに見込む必要があります。特に行政案件では、個人情報を扱う場合の環境分離やセキュリティ要件が費用に影響します。実証段階では本番データではなくダミーデータで検証する、あるいは限られた範囲の実データに絞ることで、コストとリスクの両方を抑える工夫がよく採られています。

AI-OCRやRPA、生成AIといった新技術の検証PoCは、既存のクラウドサービスやパッケージ製品を活用できるかどうかで、期間と費用が大きく変わります。既存のSaaS型サービスを試用ライセンスで導入して検証する場合、実証期間は2〜3か月程度、費用も月額利用料を中心に比較的抑えた形で始められることが多くあります。実際、総務省の調査でも、導入団体の大部分が実証実験段階では無償の試用や低コストで導入を行い、本格的な実装段階になって初めて予算額の確保が課題となる、という傾向が示されています。つまり、実証の入り口は思いのほか低コストで始められる反面、本格導入時にコストが跳ね上がる構造には注意が必要です。

一方、独自のデータで精度を検証したり、複数のシステムと連携させたりする本格的な技術検証PoCになると、要件整理から検証環境の構築、結果分析までで3〜6か月、費用も数百万円規模に及ぶことがあります。特に生成AIの検証では、プロンプトの設計や出力の妥当性評価、機密情報を含まないための工夫など、技術面以外の検討事項も多く、その分の工数が必要になります。AI関連の開発費用が一般的に高めになる傾向があるのも、こうしたデータ準備やチューニングの手間が背景にあります。

技術検証PoCで費用対効果を見誤らないためには、実証時のコストだけでなく、本格導入した場合の年間ランニングコストまで見据えて試算することが大切です。実証で良好な結果が出ても、全庁展開した際のライセンス費用や保守費用が想定を超えていれば、本予算化のハードルは一気に高くなります。実証の段階から、対象業務の件数や職員数を基に「本格導入時にはこの規模の予算が必要になる」という見通しをベンダーと共有しておくことで、本格導入の予算要求がスムーズになります。

「PoC疲れ」を防ぎ本格導入につなげるためのポイント

官公庁のPoCで最も避けたいのが、いわゆる「PoC疲れ」です。これは、実証を繰り返すばかりで本格導入に進まず、検証コストだけを消費してしまう状態を指します。良い結果が出ているのに次のステップに進めない、あるいは毎年似たような実証を別の部署が繰り返す、といった事態は行政の現場で少なくありません。ここでは、実証を本格導入へと確実につなげるための移行プロセスと、その鍵を握る評価基準・KPI設計について解説します。

実証事業から本格導入への移行は、行政特有の予算サイクルを理解して逆算することが不可欠です。多くの自治体では、翌年度予算の要求は前年の夏から秋にかけて始まり、査定を経て年明けに議会での審議、3月頃に予算成立という流れをたどります。つまり、翌年度に本格導入したいのであれば、その前年度の夏までには実証の中間成果を示し、予算要求資料に落とし込める状態にしておく必要があります。単年度で3月まで実証を続けてしまうと、成果が出る頃には翌年度予算の要求時期を過ぎており、本格導入がさらに1年先送りになる、という事態が起こりがちです。この予算スケジュールとの整合こそが、PoC疲れを防ぐ最大のポイントです。

本格導入の際には、実証で得られた知見を調達仕様書に反映させることが重要になります。行政のシステム調達では、仕様書の記載が曖昧だと発注者と受注者の間で認識のずれが生じ、後々のトラブルにつながります。実証段階で「どの機能が本当に必要か」「どの程度の精度・性能が求められるか」を具体的に確かめておけば、その結果を根拠として明確な仕様書を作成できます。例えばAI-OCRであれば、実証で得られた読み取り精度の実測値を基に、本格導入時の要求水準を数値で明記できます。実証は、単に技術を試す場であるだけでなく、本調達の仕様を固めるための情報収集の場でもあるという意識を持つことが大切です。

また、本格導入に向けた稟議や予算要求では、財政部門や上層部を説得する材料が求められます。実証で得られた定量的な効果、例えば「この業務にかかっていた時間が何割削減できた」「年間でこれだけの人件費相当の効果が見込める」といった数字を、実証段階から意識して収集しておくことが、移行の成否を分けます。実証の目的を「技術が動くことの確認」で終わらせず、「本格導入の意思決定に必要な材料を集めること」と位置づけることで、実証と本格導入がひと続きのプロセスになります。

PoCが実験だけで終わってしまう大きな原因の一つが、評価基準の欠如です。成功を測る指標をあらかじめ設定していないと、実証の結果をどう解釈すればよいかが曖昧になり、本格導入の判断ができなくなります。そこで欠かせないのが、KPIの設計です。KPIは、最終的に達成したい目標であるKGIから逆算し、途中経過を定量的に観測できる中間指標を定めるものです。官公庁の実証であれば、業務効率化であれば処理時間の削減率、住民向けサービスであれば手続き完了率や住民満足度といった指標を、実証開始前に設定しておく必要があります。

KPIを設計する際には、漠然とした目標ではなく具体的な数値目標に落とし込むことがポイントです。単に「業務を効率化する」ではなく、「この申請業務の1件あたりの処理時間を3割削減する」「窓口の待ち時間を平均で何分短縮する」といった形で、達成できたかどうかを明確に判定できる基準を定めます。費用対効果を示す場合も、削減される時間を人件費相当額に換算し、導入コストやランニングコストと比較して、何年で投資を回収できるのかを試算しておくと、財政部門への説明が格段にしやすくなります。

効果を測定する際には、いくつかの落とし穴に注意が必要です。机上で算出した理論値と、実際に測定した実績値を混同すると、効果を過大に見積もってしまいます。また、複数の施策が同じ業務に影響している場合、効果を重複してカウントしないよう切り分けることも大切です。住民満足度のような定性的な要素も、アンケートで5段階評価を取るなどして、できるだけ定量化して記録しておくと、本格導入の根拠として説得力を持ちます。実証の結果を踏まえてKPI自体を柔軟に見直す姿勢も、より実態に即した評価につながります。

PoC実施時に注意すべきリスクと対策

実証事業は本番導入に比べてリスクが小さいと思われがちですが、官公庁ならではの注意点がいくつも存在します。特に、検証範囲が知らないうちに広がってしまう「スコープの肥大化」と、本格導入を見据えないまま実証を進めてしまう「出口の欠如」は、多くの実証がつまずくポイントです。ここでは、これらのリスクとその対策を具体的に見ていきます。

実証を進めるうちに「せっかくだからこの機能も試したい」「別の部署のこの業務も対象にできないか」といった要望が加わり、当初の検証範囲が膨らんでいくことがあります。スコープが肥大化すると、限られた期間と予算の中で検証しきれなくなり、結局どの仮説についても明確な結論が出ないまま実証が終わってしまいます。これを防ぐには、実証の開始時に「今回の実証で検証する仮説は何か」を一つか二つに絞り込み、それ以外は次フェーズの課題として明確に切り分けておくことが有効です。関係者が増えやすい行政の実証では、検証対象を文書で合意しておくことが、後からの追加要望を適切にコントロールする助けになります。

目的の曖昧化も、PoC疲れを招く典型的な要因です。現場、管理職、開発ベンダーの三者で、実証のゴールに対する理解がずれていると、プロジェクトが明確な目標を失い、本格開発へ進めないまま漂流してしまいます。特にAIのような新技術を扱う場合、期待だけが先行し「何をもって成功とするか」が定まらないまま実証が始まってしまうケースが目立ちます。対策としては、実証計画書に目的・検証項目・成功基準・実施体制を明記し、キックオフの段階で関係者全員が同じ認識を持てるよう合意形成を図ることが基本です。こうした共通認識があることで、実証の途中で判断に迷ったときの拠り所ができます。

また、実証の期間設定にも注意が必要です。長すぎる実証はコストを浪費し、モチベーションの低下を招く一方、短すぎると十分なデータが集まりません。検証したい仮説に対して必要な期間を逆算し、途中に中間レビューのタイミングを設けて、進捗と方向性を確認しながら進める運営が望まれます。中間レビューで芳しくない結果が出た場合には、実証を早めに切り上げる判断も、限られた予算を有効に使ううえで重要な選択肢となります。

実証段階で協力してもらうベンダーの選定も、本格導入を見据えて慎重に行う必要があります。実証で使った技術や仕組みが特定のベンダー独自のものである場合、本格導入時にそのベンダーへ発注が固定化されてしまう、いわゆるベンダーロックインのリスクが生じます。行政の調達では公平性・競争性が強く求められるため、実証を担当したベンダーがそのまま本格導入を受注できるとは限りません。この点を踏まえ、実証段階から特定製品に過度に依存しない設計を意識し、本格導入時には他社製品への切り替えも可能な形で仕様を整理しておくことが望まれます。

本格導入の調達仕様書には、実証で得られた知見を具体的に落とし込みます。求める機能や性能、セキュリティ要件、他システムとの連携要件などを、実証の結果を根拠として明確に記載することで、認識のずれによるトラブルを未然に防げます。標準的な住民記録システムなどの調達仕様書のひな形でも、契約期間や導入スケジュール、データ移行、並行稼働の期間などが具体的に定められており、こうした項目についても実証段階で検証・確認しておくと、本調達の精度が高まります。実証は、こうした本格導入の要求水準を現実的に見極めるための貴重な機会だと捉えるべきです。

加えて、実証を委託する際には、実証で得られたデータや成果物の権利関係についても、あらかじめ契約で明確にしておくことが大切です。実証で構築したプロトタイプやモックアップ、収集したデータが本格導入時にも活用できるようにしておかないと、本格導入で一から作り直すことになり、実証の投資が無駄になってしまいます。実証と本格導入を分断させず、成果を確実に引き継げる形で契約や体制を設計することが、投資対効果を最大化する鍵となります。

官公庁向けPoC・プロトタイプ開発の進め方と体制づくり

ここまで見てきたポイントを踏まえ、実際に官公庁でPoC・プロトタイプ開発を進める際の流れと、必要な体制づくりについて整理します。実証を成功させるには、技術面の準備だけでなく、企画段階での関係者調整や、内製と外部委託の適切な使い分けが欠かせません。組織としてどう推進体制を組むかが、実証の質と本格導入への移行のしやすさを大きく左右します。

実証を始める前の企画段階では、まず解決したい業務課題を明確にすることが出発点になります。技術ありきで「生成AIを使いたい」と考えるのではなく、「この業務のどこに、どのような課題があり、それをどう解決したいのか」を言語化することで、本当に実証すべきテーマが見えてきます。企画段階でユーザーである職員や住民の課題やニーズを丁寧に把握しておくと、後の実証で検証すべき仮説が具体的になり、満足度の高いサービスの企画につながります。この上流工程のリサーチを軽視すると、動くものはできても現場で使われないという結果に陥りがちです。

官公庁の実証では、関係者調整も大きな比重を占めます。業務を所管する原課、情報システム部門、財政部門、そして場合によっては住民や外部の有識者まで、多様な関係者が関わります。実証の目的や進め方について、これらの関係者と早い段階で認識を合わせておかないと、途中で反対意見が出て実証が止まってしまうこともあります。特に、実証の結果を本格導入につなげたいのであれば、予算を握る財政部門に対して、実証の狙いと期待される効果を企画段階から共有しておくことが、後の予算要求を円滑に進めるうえで効果的です。

また、個人情報の取り扱いやセキュリティに関する庁内手続きも、企画段階から見込んでおく必要があります。行政の実証では、住民の個人情報を扱う場合に個人情報保護に関する審査や手続きが求められることが多く、これらに時間を要するケースがあります。単年度で成果を出す必要がある実証において、こうした手続きに想定以上の時間がかかると、肝心の検証期間が圧迫されてしまいます。スケジュールを引く際には、こうした行政特有の手続き期間もあらかじめ織り込んでおくことが、無理のない実証運営につながります。

実証を内製で進めるか、外部のベンダーに委託するかは、対象の技術難易度と庁内のリソースを踏まえて判断します。既存のノーコード・ローコードツールや汎用のSaaSを使った小規模な実証であれば、職員が主体となって内製で進めることも十分可能です。内製には、業務を熟知した職員が自ら手を動かすことで課題への理解が深まり、ノウハウが庁内に蓄積されるという大きな利点があります。一方で、専門的な技術検証や、本格導入を見据えた作り込みが必要な場合は、外部の専門ベンダーの知見を活用する方が、限られた期間で確実に成果を出せます。

総務省の調査でも、ICTの専門人材が不足していることや、特にAIについては単独の自治体だけでは対応が難しいことが課題として挙げられています。こうした状況では、複数の自治体が共同で実証を行ったり、外部ベンダーと連携したりすることで、リソースやコストの負担を分担する進め方が現実的です。外部委託する場合でも、丸投げにするのではなく、職員が実証のプロセスに主体的に関わり、検証結果の解釈や本格導入の判断を自ら行える体制を保つことが、実証を組織の力に変えるうえで大切です。

ベンダーを活用する際には、行政のPoCや実証事業の経験が豊富なパートナーを選ぶことも重要な観点です。単年度予算や調達手続き、個人情報の取り扱いといった行政特有の制約を理解しているベンダーであれば、実証から本格導入までを見据えた現実的な提案が期待できます。技術力だけでなく、行政の予算サイクルや意思決定プロセスに寄り添った伴走ができるかどうかが、実証を本格導入へと着実につなげるパートナー選びの鍵になります。

まとめ

官公庁のシステム開発におけるPoC・プロトタイプ・モックアップ開発は、新技術の不確実性を限られたリスクの中で見極め、本格導入への確かな判断材料を得るための重要な手法です。モックアップで見た目を、プロトタイプで使い勝手を、技術検証PoCで実現可能性を確かめるというように、目的に応じて手法を使い分けることが出発点となります。費用は、小規模なプロトタイプやSaaS活用の実証であれば数百万円程度から始められますが、本格導入時のランニングコストまで見据えて試算しておくことが欠かせません。

そして、官公庁のPoCで最大の課題となる「PoC疲れ」を防ぐには、単年度予算という制約を理解し、翌年度の予算要求スケジュールから逆算して実証を進めること、そして実証開始前に明確なKPIと評価基準を設定し、費用対効果や住民満足度を定量的に示せるようにしておくことが決定的に重要です。実証を「技術が動くことの確認」で終わらせず、本格導入の意思決定に必要な材料を集め、調達仕様書に反映させるための情報収集の場と位置づけることで、実証と本格導入はひと続きのプロセスになります。スコープの肥大化や目的の曖昧化を防ぎ、本格導入を見据えたベンダー選定と体制づくりを行うことで、実証への投資を確実に成果へとつなげていきましょう。

▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。