土木工事業向け出来形管理システム開発の発注/外注/依頼/委託方法について

土木工事業向け出来形管理システムの発注・外注は、写真を保存するアプリを選ぶだけではなく、設計値・実測値・規格値・判定・帳票・電子納品を一つの業務データとしてつなぐことが成功の条件です。

紙の野帳やExcelからの転記、写真フォルダの整理、発注者ごとに異なる帳票への入力に負担を感じている会社では、既製クラウド、土木専用パッケージ、部分開発、スクラッチ開発のどれを選ぶかで、費用も定着しやすさも変わります。この記事では、発注形態の選び方からRFP・要件整理、契約形態、費用相場、委託先の比較方法まで、実際に外注を進めるための判断軸を解説します。

▼全体ガイドの記事
・土木工事業向け出来形管理システム開発の完全ガイド

土木工事業向け出来形管理システムの発注・外注とは何ですか？

発注・外注とは、自社でシステムを作るのではなく、製品ベンダーや受託開発会社に、出来形管理業務を効率化する仕組みの選定・導入・開発・保守を委託することです。重要なのは、製品名や機能数から探し始めず、どの作業を標準化し、どこに自社独自のルールを残すかを先に決めることです。

出来形管理では、工事名、発注者、工種、測点、設計値、許容差、実測値、測定日、担当者、写真、判定結果を記録します。システムの発注範囲は、現場での測定値入力だけで終わらせず、「設計値の登録→実測→写真撮影→差の計算→規格値判定→承認→出来形管理図表や総括表の出力→検査・電子納品」という流れで整理します。

発注者の基準や工事の特記仕様書によって、必要な測定項目、撮影頻度、帳票の様式、電子納品の形式が変わります。国土交通省の関東地方整備局は、令和7年3月改定の土木工事施工管理基準及び規格値、出来形管理基準、土木工事写真管理基準を公開しています。したがって、RFPには「国交省対応」とだけ書かず、対象工種と実際に提出する帳票のサンプルを添付することが大切です。出典として、国土交通省関東地方整備局「土木工事共通仕様書」掲載資料（2026年8月確認）を参照しています。

出来形管理システムは、現場監督や測量担当者が毎日使わなければ効果が出ません。評価指標は、入力画面の見た目だけでなく、1測点の入力にかかる時間、写真と測定値の紐付け漏れ、事務所に戻ってからの転記件数、帳票の作成時間、未検査箇所の把握時間で決めます。

たとえば、現場ではスマートフォンで測定値と写真を登録し、事務所では品質担当が異常値を確認し、本社では進捗と未承認データを確認する役割分担が考えられます。誰がどの画面を使うかを決めずに高機能なシステムを導入すると、紙やExcelを併用する二重運用になりやすいため、発注時点から利用者ごとの業務を明記します。

発注形態は既製品・部分開発・スクラッチから選びます

発注形態は、標準業務への適合度、独自帳票の多さ、現場数、協力会社とのデータ連携、測量機器や基幹システムとの接続範囲で決めます。最初からスクラッチ開発に限定せず、既製品で満たせる範囲と、開発しなければ解決できない範囲を分けることが費用を抑えながら失敗を減らす方法です。

既製クラウドやSaaSは、写真、図面、電子小黒板、検査、書類共有、電子納品など、建設現場で共通する機能を短期間で利用し始められます。複数現場を本社から確認したい会社や、サーバー保守・バックアップを自社で抱えたくない会社に適しています。

一方で、独自の規格値計算、特殊工種の帳票、社内の原価・積算システムとの連携が標準機能にない場合は、オプションやAPI開発が必要です。Photoructionの公式料金ページでは、初期費用0円を掲げつつ、カスタマイズ・オプションを除き、利用者数に応じた月額料金とオプション料金で見積もる体系が示されています。容量による金額変動がない点も含め、現場数、利用者数、追加機能を分けて確認します。出典として、Photoruction「料金プラン」（2026年8月確認）を参照しています。

既製品だけでは入力や帳票が合わず、全社向けのスクラッチ開発には不確実性が大きい場合は、部分開発が現実的です。たとえば、1工種の設計値・実測値入力、写真の自動紐付け、規格値判定、帳票出力だけを対象にして、1現場で2〜3か月程度の試行を行います。

PoCでは、機能が動くかだけでなく、通信が途切れたときに保存できるか、同期の競合をどう知らせるか、現場で何回タップすれば登録できるかを測ります。成功条件を「担当者が使える」ではなく、入力時間、未入力件数、写真整理時間などの数字に置き換えると、本番化の判断がしやすくなります。

スクラッチ開発は、特殊な工種や独自帳票が多い会社、積算・原価・会計・測量・ICT建機・BIM/CIMのデータを一つの基盤で扱いたい会社に向いています。自社の業務に合わせて画面やワークフローを設計できる反面、要件定義、基準改定への追随、障害対応、端末更新、保守体制まで自社と開発会社が長く負担します。

AIによる写真分類や帳票の下書きは、入力補助としては有効ですが、規格値を満たすかどうかの最終判定や検査の承認を自動化する前提にしないことが安全です。最終的な施工判断は技術者が行い、AIの提案内容、採否、修正履歴が残る設計にします。

発注・外注はどの順番で進めますか？

発注を急いで製品デモから始めると、デモで見た機能に業務を合わせることになりがちです。まず現状の流れと提出物を棚卸し、次に選択肢を比較し、RFPで同じ条件を提示してから、PoCまたは本番導入へ進めます。発注から稼働までを、企画、要件、選定、契約、試験、教育の段階に分けると、判断の抜け漏れを防げます。

現場代理人、測量担当、品質担当、本社の工事部、協力会社から、実際に使っている野帳、Excel、写真フォルダ、提出帳票を集めます。そして、設計値を誰が登録するか、実測値をどこで入力するか、写真の撮影者と整理者は誰か、承認と差戻しをどの手段で行うかを確認します。

特に確認したいのは、同じ情報を何度入力しているかです。工事名や測点名を紙、写真名、Excel、帳票へ繰り返し入力しているなら、マスタと自動連携の効果が出やすい箇所です。反対に、発注者の判断や現場の例外処理まで一律に自動化しようとすると、要件が複雑になり費用が増えやすくなります。

要件は「出来形を管理できる」ではなく、「道路土工の盛土について、指定した測点の設計高と実測高を入力し、許容差を計算して、指定の出来形管理図表と写真帳を出力できる」のように書きます。対象工種、測定項目、単位、小数桁、規格値、測定頻度、写真の撮影タイミング、帳票の提出形式を一つずつ記載します。

山間部、河川、トンネルなどでは、通信断を前提にします。オフラインで入力した値と写真を端末に一時保存し、復旧時に同期する機能だけでなく、同じ測点を別端末で編集した場合の競合表示、同期失敗の再送、端末紛失時のデータ保護を確認します。外部測量機器を使う場合は、Bluetooth、CSV、LandXML、点群など、実際の入出力形式をRFPに書き、サンプルデータで連携テストを行います。

受入試験では、画面が表示されるかではなく、工事資料を使って一連の成果物が完成するかを確認します。設計値を登録し、現場で実測値と写真を入力し、異常値を確認し、承認し、帳票を出力し、電子納品用のデータとして取り出すまでを試します。正常値だけでなく、規格値外、未入力、重複測点、通信断、同期競合、担当者変更も試験ケースに含めます。

教育は一度の説明会で終えず、現場用の短い操作手順、よくあるエラーへの対応、問い合わせ窓口、初回現場への伴走支援を用意します。KENTEMの公式導入事例では、SiteBoxと写真管理ソフトの連携によって写真整理が半分以下になったという利用者の声が紹介されていますが、これは個別事例であり、自社でも同じ効果が出るとは限りません。自社の現場で導入前後を測定し、全社展開の根拠にします。出典として、株式会社建設システム「SiteBox導入事例」（2026年8月確認）に記載されています。

RFP・要件整理では何を明記しますか？

RFPは、開発会社に価格だけを出してもらう文書ではありません。対象業務、解決したい課題、対象工事、利用者、データ、連携、非機能要件、導入スケジュール、保守範囲を同じ前提で比較するための文書です。候補会社ごとに説明の仕方が違っても、同じ回答欄で比べられる粒度に揃えます。

機能要件には、工事・工種・測点マスタ、設計値と規格値の登録、実測値の入力、写真と電子小黒板、撮影漏れの警告、自動計算、承認・差戻し、帳票出力、電子納品、検索、履歴、CSVや画像のエクスポートを含めます。3次元を扱う場合は、TS、GNSS、レーザースキャナー、ドローン、ICT建機、LandXML、点群、BIM/CIMのどこまでを対象にするかを分けます。

異常値を見つけたときに上書きするのか、修正前の値を残して再入力するのか、承認後の訂正に誰の承認が必要かも明記します。自動判定は技術者の確認を助けるために使い、判定ロジックの変更履歴と最終承認者を残します。国土交通省の情報共有システム機能要件Rev.5.6でも、工事基本情報、書類管理、オンライン電子納品、遠隔臨場、3次元データ、データ連携、権限管理などが機能の対象に整理されています。出典として、国土交通省「工事施工中における受発注者間の情報共有システム機能要件 Rev.5.6」（2026年8月確認）に示されています。

非機能要件には、対応端末とOS、通信断時の動作、同時利用者数、画像や動画の容量、表示速度、バックアップ頻度、復旧目標、稼働時間、障害時の連絡体制、脆弱性対応、暗号化、認証、権限、監査ログを含めます。現場で使う端末が古い場合は、推奨機種だけでなく、会社が実際に配布できる機種でテストします。

協力会社や発注者が閲覧する場合は、会社・工事・役割単位の権限を切り分けます。退職者や工事終了後の利用者を停止できること、ダウンロードや共有リンクを制御できること、操作ログを出力できることも確認します。Rev.5.6では、利用者単位のID・パスワード、権限設定、バックアップと復元、マスタ管理が要件として示されているため、単なる写真共有サービスと施工管理基盤を区別して選定します。

提案書には、システム構成図、画面一覧、データ項目一覧、帳票サンプル、連携方式、移行計画、テスト計画、教育計画、運用開始後のサポート体制を含めてもらいます。「標準」「設定」「追加開発」「対応不可」を機能ごとに分けて回答してもらうと、見積の前提が明確になります。

基準や帳票が改定されたときの対応も重要です。軽微な改定は保守費に含むのか、個別改修として見積もるのか、改定情報を誰が収集し、いつまでに反映するのかを契約前に決めます。解約時には、工事情報、測定値、写真、帳票、XML、操作履歴をどの形式で返却できるか、返却費用や期限があるかまで確認します。

契約形態は準委任・請負・SaaS利用を使い分けます

同じ「外注」でも、何を成果物とするか、仕様変更を誰が負担するか、作業時間に対して支払うか、完成した機能に対して支払うかで契約の考え方が変わります。法務や顧問弁護士の確認を前提に、開発フェーズと運用フェーズを分けて契約条件を整理します。

現場ヒアリング、業務棚卸し、RFP作成支援、PoCのように、調査しながら最適解を探す段階では準委任が使われることがあります。作業内容、担当者、稼働時間の管理方法、成果の確認方法を定め、毎月の成果報告と次月の判断を行います。要件が固まっていない段階で完成責任だけを求めると、双方が想定しない追加費用や納期延長につながりやすくなります。

画面、帳票、連携、性能、対応端末が決まった本番開発では、請負契約と納品・検収の条件を検討します。ただし「動けば検収」では不十分です。対象工種のサンプルデータで規格値計算が一致すること、写真と測定値が正しく紐付くこと、通信断から同期できること、帳票が指定様式で出力されることを受入基準にします。

仕様変更の扱いも重要です。変更依頼の受付、影響調査、追加費用、納期変更、承認者を定め、口頭依頼だけで開発を進めない運用にします。ソースコードや設計書の帰属、第三者ソフトウェアのライセンス、脆弱性が発見されたときの修正責任、開発会社が事業を継続できなくなった場合の引継ぎ条件も、スクラッチ開発では確認します。

SaaSは初期開発を抑えやすい一方、月額料金、利用者数、現場数、端末数、容量、オプション、教育費、API利用料、データ移行費が別々に設定されることがあります。契約期間、自動更新、最低利用期間、解約予告、障害時の返金やサービス品質保証、バックアップと復旧の範囲を確認します。

写真や測定値は工事完成後も保存が必要になる場合があるため、契約終了後に読み取り専用で保管できるか、エクスポートできるかを確認します。ベンダーの標準約款だけで判断せず、自社の電子納品・監査・発注者への提出義務と照らし合わせて、保存期間とデータ返却を合意します。

費用相場はどのくらいですか？

土木工事業向け出来形管理システムだけを対象にした公的な費用統計は確認できないため、以下は建設業務システムの一般的な目安と、出来形管理の要件をもとにした概算レンジです。公開価格と個別開発の推定費用を混同せず、要件、現場数、利用者数、端末、帳票、データ連携、移行、教育、保守を含むかを確認して使います。

機能を限定した既製クラウドやSaaSは、月額3万〜50万円程度、複数現場や業務システム全般を含む場合は月額10万〜100万円程度が検討時の目安になります。初期設定、アカウント発行、帳票設定、教育、オプションは別途になることがあります。土木専用パッケージは、本体・保守・追加モジュールを含めた初年度で50万〜300万円程度が一つの推定レンジですが、端末ライセンスや現場数で変動します。

1現場のPoCや部分開発は50万〜300万円程度、数現場へのパイロット本番化は300万〜1,500万円程度、独自帳票や複雑な規格値計算、API連携を含むスクラッチ開発は300万〜2,000万円程度が概算の検討レンジです。支店・協力会社・会計・積算・ICT建機・BIM/CIMまで横断する全社展開は、1,500万〜5,000万円程度になる可能性があります。これらは公的統計ではなく、要件を読み替えた予算検討上の目安であり、見積書の特定金額を保証するものではありません。

開発費には、要件定義、現場ヒアリング、画面設計、アプリやWeb開発、帳票、連携、テスト、プロジェクト管理が含まれます。導入費には、工事・工種・規格値マスタの整備、既存Excelや写真の移行、端末設定、利用者登録、教育、初期現場への支援が含まれることがあります。見積書にこれらが一式で書かれている場合は、作業項目と数量を分解してもらいます。

運用費には、クラウド利用料、保守、監視、バックアップ、問い合わせ、基準改定、セキュリティ対応、追加帳票、端末交換、現場教育が含まれます。保守費を初期開発費の年15〜25％程度と仮置きする考え方もありますが、これは予算検討の仮定に過ぎず、契約するサービスレベルや対応範囲によって変わります。最低3年の総保有コストで比較すると、初期費用が安い方式の運用負担も見えます。

初期見積より費用が増えやすいのは、対象工種の追加、発注者ごとの帳票差分、規格値マスタの整備、協力会社のアカウント、オフライン同期、過去データ移行、測量機器との連携、発注者が求める電子納品形式への対応です。RFPの時点で優先度を必須・重要・将来対応に分け、将来対応を本契約に含めるのか、別フェーズにするのかを決めます。

見積比較では、合計額だけでなく、同じ業務を完了するまでの費用を比較します。たとえば、A社は月額が安くても帳票設定と現場支援が別料金、B社は月額が高くても教育とAPIが含まれることがあります。項目ごとの「含む・含まない・上限・追加単価」を揃え、同じ3年利用シナリオで再計算します。

委託先選定と見積比較のポイントは何ですか？

委託先は、受託開発会社だけでなく、土木専用ソフトのベンダー、建設クラウド、測量・3次元連携に強い会社を含めて比較します。選定の中心は会社の知名度ではなく、対象工種と帳票への適合性、現場での使いやすさ、データの持ち出し、保守の継続性、提案の透明性です。

実績確認では、「建設会社への導入実績があります」だけでなく、出来形のどの工種で使ったのか、写真・測定値・帳票・電子納品をどこまでつないだのか、何人・何現場で運用したのかを尋ねます。可能であれば、同規模の会社、同じ発注者、通信条件が似た現場の担当者から、導入後の定着状況と困った点を聞きます。

製品ベンダーの場合は、標準機能でどこまで対応できるかを確認します。KENTEMの出来形管理クラウドは、出来形管理工種を写真管理側へ反映し、SiteBoxで入力した実測値や立会値を同期する機能を案内しています。こうした連携は転記削減に有効ですが、自社の工種・帳票・発注者基準でも同じように動くかを、デモではなくサンプルデータで確かめます。出典として、株式会社建設システム「出来形管理クラウド」（2026年8月確認）に掲載されています。

候補会社には、同じ工事資料、同じ帳票、同じ利用者数、同じ現場数、同じ保存期間を渡します。比較表の評価項目は、機能適合性、現場入力の手数、オフライン、写真・測定値の紐付け、帳票・電子納品、測量・3次元連携、権限と監査ログ、データ返却、導入支援、サポート、費用、納期とします。

価格だけでなく、必須機能の未対応数、追加開発の単価、保守範囲、基準改定時の対応、障害復旧の目標、問い合わせへの回答時間も点数化します。提案会社の説明が抽象的な場合は、要件ごとに「標準・設定・追加開発・不可」を記した回答を求めます。見積の安さより、後から発生する追加費用と社内の運用負担を含めて判断することが大切です。

選定の最終段階では、開発会社の担当者が発注後も参加するか、導入支援の担当と保守担当が分かれるか、現場からの問い合わせを誰が受けるかを確認します。担当者の交代時に、要件書、決定事項、テスト結果、マスタ、操作手順、障害履歴が引き継がれる仕組みも必要です。

本番稼働後は、入力率、写真の整理時間、帳票作成時間、差戻し件数、未検査箇所、問い合わせ件数を月次で確認します。KPIが改善しない場合に、操作教育を追加するのか、画面を直すのか、業務ルールを見直すのかを決められるよう、契約に定例レビューと改善提案の場を含めると定着しやすくなります。

よくある質問

ここでは、発注前に多く寄せられる疑問へ直接回答します。費用や適合性は工種、発注者、現場数、利用者数、既存データ、連携範囲で変わるため、回答の数字は予算検討の目安として扱います。

対象工種と帳票が標準機能に近く、早期導入と法令・基準への追随を優先するなら、既製の土木専用パッケージやクラウドが向いています。独自帳票、社内基幹連携、特殊な規格値計算、複数システムをまたぐ業務を優先するなら、既製品を基盤にした部分開発やスクラッチ開発を検討します。

機能を限定したクラウドは月額3万〜50万円程度、土木専用パッケージは初年度50万〜300万円程度、1現場のPoCは50万〜300万円程度、スクラッチ開発は300万〜2,000万円程度が概算レンジです。ただし、いずれも公的な費用統計ではなく、業務システムの一般目安を出来形管理の要件に読み替えたものです。対象工種、帳票、利用者数、端末、データ移行、教育、保守を含めた見積を複数社から取ります。

発注できますが、オフライン入力と後同期を必須要件にして、実際の現場で通信断試験を行う必要があります。端末内への一時保存、同期失敗の通知、重複や競合の解決、端末紛失時の遠隔ロックやデータ消去、復旧後の再送まで確認し、オンライン時だけのデモで判断しないことが大切です。

発注者、地方整備局、自治体の最新基準と、対象工事の特記仕様書を用意し、実際に提出する帳票と電子納品データで確認します。候補会社には、対応する基準名と改定時点、標準対応か追加設定か、出力できるファイル形式、写真の信憑性確認や改ざん検知の方式を回答してもらいます。「電子納品対応」という一言だけでは、必要な様式まで対応できるとは限りません。

まとめ

土木工事業向け出来形管理システムを発注・外注するときは、まず紙、Excel、写真、帳票、承認の流れを現場資料で棚卸しします。そのうえで、既製クラウド、土木専用パッケージ、部分開発、スクラッチ開発のどこまでが必要かを切り分けます。

RFPには、対象工種、設計値・実測値・規格値、写真、電子納品、オフライン、測量・3次元連携、権限、監査ログ、データ返却、基準改定、保守を明記します。費用は、月額や初期開発費だけでなく、マスタ整備、移行、教育、追加帳票、連携、3年間の運用費まで含めて同じ条件で比較します。

最後に、1現場・1工種のPoCで、入力時間、転記件数、写真整理時間、帳票作成時間、未入力率を測定します。現場で使われる仕組みを小さく検証し、発注者の基準と自社の運用に適合すると確認できてから、数現場、支店、全社へ段階的に展開することが、費用と定着リスクを抑える進め方です。

▼全体ガイドの記事
・土木工事業向け出来形管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。