保守開発で試作を行うのは、稼働中のシステムに変更を入れる前に、技術面や既存機能への影響、使いやすさを小さく確かめるためです。PoC・プロトタイプ・モックアップは検証する対象が異なるため、確かめたい不確実性に合わせて選びます。
▼全体ガイドの記事
・保守開発の完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
保守開発でPoC・プロトタイプ・モックアップが必要になる理由
新規開発の試作は、これから作るものが本当に機能するかを確かめるために行います。一方で保守開発では、稼働中のシステムを壊さずに変更できるかも確かめる必要があります。稼働中のシステムは日々の業務を支えているため、新機能の追加や旧技術の置き換えで本番に問題が起きると、業務停止や顧客への影響につながります。
本格実装の前に、小さな検証用のコードや画面を作り、実現性、既存システムとの衝突、使いやすさを確かめます。
稼働中システムへの変更は「試してから入れる」が原則
試作では、本格実装の前に検証環境で次の三点を確かめます。
- 技術面：変更が技術的に実現できるかどうか。
- 既存機能への影響：システム内の既存機能と衝突しないかどうか。
- 利用者の視点：変更後も利用者が使いやすいか。
長年のシステムでは、独立して見える機能も裏で複雑につながっています。そのため、実際に試すまで影響が分からないことがあります。
外部連携を本番で試し、セキュリティ要件を満たせないと分かれば、それまでの工数が無駄になります。事前にPoCで接続の可否を確かめておけば、手戻りを防げます。
保守開発では、「動いているものを止めない」ことが大切です。失敗時の損失は新規開発より大きいため、先に試す進め方が原則です。
試作にかける時間と費用は、本番トラブルによる損失を避けるための合理的な備えと考えられます。
PoC・プロトタイプ・モックアップの違いと使い分け
三つの試作手法は混同されがちですが、検証する対象がそれぞれ異なります。見た目、操作感、技術的な実現性のどれを確かめたいかで選びます。
- モックアップ：画面の見た目やレイアウトを関係者間で共有し、画面構成をすり合わせるための試作です。
- プロトタイプ：操作できる試作品で、画面遷移などの使い勝手や操作感を確かめるものです。
- PoC：Proof of Concept（概念実証）で、API連携や処理性能など技術的な実現性を検証する手法です。
既存画面に項目を追加して利用者の反応を見たい場合は、モックアップかプロトタイプから始めるのが適しています。新しいAIモデルや外部SaaSを組み込む場合は、連携できるかどうか不安な点をPoCで確かめます。
確かめたい不確実性に合わせて必要な手法を選べば、無駄のない計画になります。三つすべてを順番に行うことは、必須ではありません。
保守フェーズでPoCを行う典型ケース
PoCが特に役立つのは、既存システムに技術的な不確実性の高い変更を加える場面です。安定して稼働している最中でも、環境の変化に応じて新技術の導入や刷新が必要になることがあります。既存の前提が変わるため、いきなり本格実装すると危険です。
代表的な例は、老朽化システムのモダナイゼーション、新技術や外部サービスとの連携、既存データを使った精度・負荷の検証です。自社で同様の検討を始める場合は、本格的に着手する前にPoCを挟むのが有効です。
老朽化システムのモダナイゼーション実現性検証
PoCの大きな意義の一つは、保守が困難であったり、仕様書がなくブラックボックス化したりしているシステムについて、刷新の可能性を確かめられることです。
長年稼働してきた基幹システムを一括で刷新するとリスクが高く、巨額の投資が無駄になるおそれもあります。そこで、全面刷新に踏み切る前に、段階的な改修や新しい技術スタックへの移行が可能かを小さく試します。
生成AIのコード書き換え支援ツールを使い、古いコードの解析や新しい言語・基盤への書き換えを、どこまで自動化できるか検証する手法もあります。
移行の判断に使う次の二点を、PoCで数値により把握します。
- 実現性：新しい技術スタックへ移行できるか。
- 工数とリスク：移行にどの程度の作業量と危険が伴うか。
結果を基にすれば、全面刷新・段階移行・現状維持といった大きな判断を、勘ではなく根拠に沿って下せます。特に、投資規模が大きいモダナイゼーションほど、事前検証の価値は高まります。
外部API・新技術連携、既存データでの精度・負荷検証
既存システムに機能を追加するときにPoCが必要になるのは、主に次の三つのパターンです。
- API連携：AIモデルや外部クラウドサービス（SaaS）が、既存仕様やセキュリティ要件のもとで接続できるか。
- 精度：問い合わせデータをAIで分類する場合、データの量と質を踏まえ、本番に近い条件で一致率80%以上などを確かめます。
- 負荷：リアルタイム処理や大量データ処理が、既存システムの性能に悪影響を与えないか。
ある食品卸会社は、受発注のAI自動処理PoCで、既存システムとのAPI連携を2か月以内に実現できるかを検証しました。結果は目標に届かず、約70万円で撤退しました。ただし、本格投資の前に見送る判断ができた点で、成功といえる結果です。
技術的な不確実性の高い機能は、小さなPoCで先に見極めると、大きな投資判断の精度を高められます。
進め方と期間・費用の目安
試作では、まず目的を定め、必要最小限の範囲だけを作ります。範囲を欲張って広げると、小さな本開発になってしまい、「小さく早く確かめる」という目的を失います。
試作は、本開発へ進むか見送るかを判断するための投資です。そのため、試作を本開発へ進めるかどうかを判断するGo/No-Go基準も、事前に決めておきます。基準を先に決めておくと、検証の結果を判断に生かせます。
モックアップ/プロトタイプ/PoCの期間・費用相場
モックアップ、プロトタイプ、PoCの期間と費用は、検証対象や作り込みの深さで変わります。
- モックアップ：画面の見た目を共有する範囲なら、約1〜2週間、30万〜40万円程度。
- プロトタイプ：実際に操作できる試作品は、1〜3週間、70万〜90万円程度。
- PoC：数日〜2週間が目安で、長くても3か月以内に区切ります。
- 小規模PoC：50万〜100万円程度。既存システムと連携する中・大規模検証は100万〜300万円以上の場合があります。
既存システムとの接続を検証する場合は、調査や準備に想定以上の手間がかかることがあります。本番に近い検証環境を用意することや、既存データへのアクセス権限を調整することも必要になります。そのため、検証本体だけでなく、周辺の準備にかかる工数も見込んでおきます。
予算は、「いつまでに、何を判断するのか」を起点に組むことが大切です。
Go/No-Go基準と早期撤退の判断
PoCは、本番実装・見送り・設計見直し後の再検証のどれに進むかを判断するために行います。動いたという結果だけで、本番へ進めることは避けます。
検証の前に、定量的な合否基準を決めておきます。たとえば、次のような数値目標を置きます。
- 業務時間：既存業務の作業時間を30%以上削減できるか。
- 分類精度：精度が80%以上に達するか。
- 連携期間：既存システムとのAPI連携を2か月以内に確立できるか。
目標に届かなければ撤退するというルールも、事前に合意しておきます。食品卸会社の事例では、明確な基準があったため、約70万円で撤退を決められました。
追加開発の費用がかさみやすい保守フェーズでは、見込みの薄い投資を早く止める価値があります。試作の費用は、本番での大きな失敗を防ぐための判断材料を得る投資です。
基準を厳格に運用することで、保守開発を賢く進められます。
既存システムを壊さないための注意点と契約
検証環境では動いても、本番に接続する段階で権限が下りない、審査に通らないといったことがあります。また、想定外の負荷で既存機能が不安定になることも珍しくありません。
試作が動いたことを確認するだけで終わると、本番適用の段階で行き詰まり、PoCの価値が半減してしまいます。検証の段階から本番適用を見据えて設計すると、試作を本当に役立てられます。そのためには、注意点と契約の形態も決めておく必要があります。
接続条件・非機能要件・失敗系設計の事前合意
試作の前に、関係部門と次の三点を合意しておきます。
- 接続条件と非機能要件：データ取得方法、利用権限、監査ログ、セキュリティ要件の確認。
- 失敗時の設計：API停止でも既存のコア機能を止めないための、縮退運転・タイムアウト・リトライの設計。
- Go/No-Go基準：本番へ進める条件と見送る条件を、検証の前に定めた基準。
接続条件を事前に確認しないと、技術的には動くPoCでも本番で使えず、検証が無駄になります。
接続条件は、情報システム部門やガバナンス部門と事前にすり合わせておきます。従量課金のサービスでは、費用が膨らまないよう上限も設けておきます。
三点を前提として固めておけば、「試作では動いたのに本番で使えない」という落とし穴を避けられます。
準委任での検証→ハイブリッド本開発への移行
試作と本開発では、適した契約の形態が異なります。検証の途中では要件を固めきれず、試行錯誤しながら進めるためです。
- 検証段階：成果物の完成を約束する請負より、作業時間や体制に対価を払う準委任契約が適します。
- 本開発段階：検証完了後に要件が固まったら、実装は請負、改善・運用は準委任とするハイブリッド型が標準です。
- 移行準備：PoC契約時に、本開発の見積もり優先交渉権を盛り込む方法があります。
優先交渉権があれば、検証で得た知見を持つ同じパートナーと本開発へ進めます。
保守開発は継続的な取り組みです。そのため、試作から本開発、その後の運用改善まで任せられる体制を、契約の面から設計しておく必要があります。
検証の段階では柔軟性を保ち、本開発で成果と予算の見通しを立てるという使い分けが、試作を実りあるものにします。
まとめ
保守開発の試作は、稼働中のシステムを壊さずに変更できるかを確かめるものです。不確実な変更は、本番の前に試すのが原則です。
見た目はモックアップ、操作感はプロトタイプ、技術的な実現性はPoCで検証します。確かめたい内容に応じて、必要な手法だけを選びます。
PoCは、モダナイゼーションや外部API連携、既存データを使った精度・負荷検証に役立ちます。
期間と費用の目安は、モックアップが1〜2週間・30万〜40万円、プロトタイプが1〜3週間・70万〜90万円です。PoCは数日〜3か月以内で区切り、小規模なら50万〜100万円、連携を含む中・大規模なら100万〜300万円以上の場合があります。
Go/No-Go基準は数値で定め、接続条件や失敗時の設計は事前に合意しておきます。そのうえで、準委任での検証からハイブリッド型の本開発へつなげます。
機能追加や刷新を検討する場合は、本格着手の前に小さな試作で不確実性を減らしましょう。
▼全体ガイドの記事
・保守開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。