建設キャリア管理システム開発の発注/外注/依頼/委託方法について

建設キャリア管理システムの発注は、現場業務を整理し、1〜3現場で検証し、連携範囲を固めてから段階的に委託すると、手戻りを抑えられます。

発注形態、RFPと要件整理、契約と費用、委託先の選び方の順に、各段階で決めることを見ていきます。全体像は次のガイドもご覧ください。

▼全体ガイドの記事
・建設キャリア管理システム開発の完全ガイド

建設キャリア管理システムの概要

CCUSを中心に、入退場、施工体制、安全書類、勤怠の周辺機能を結んだ図です。
現場業務の機能をCCUS本体の外側に整理しています。

建設キャリア管理システムは、建設技能者の資格、所属、就業履歴、現場配置、能力評価などをまとめて管理し、日々の現場運用と人材育成に使う仕組みです。

その中心にあるのが、公的基盤の建設キャリアアップシステム(CCUS)です。発注の対象には、入退場、施工体制、安全書類などの周辺システムも含まれます。勤怠、給与、建退共も対象に入ります。

CCUS本体と民間システムの役割分担

CCUS本体と民間システムでは担う役割が違うため、RFPで連携範囲を整理しておく必要があります。

  • CCUS本体:技能者の資格と就業履歴を蓄積し、経験や技能に応じた評価と処遇改善につなげる役割を担います。
  • 民間システム:カード、QRコード、顔認証、電話発信による入退場登録を支え、施工体制や作業員名簿の作成も支援します。
  • RFPで決めること:「CCUS対応」だけで済ませず、各データをどちらのシステムが正として持つか、連携するタイミングを明記します。

発注前に整理する主要機能

発注前に整理する機能は、基本管理、現場登録、例外対応の3つに分けると、要件を確かめやすくなります。

  • 技能者・事業者管理:マスター、資格、健康診断、権限を扱う機能です。
  • 現場と帳票:現場ごとの施工体制や就業履歴を整理し、帳票を出力します。
  • 例外時の処理:登録の代替手段、通信障害時の再送、修正、データ保持を決めます。

現場にカードリーダーを置けない場合の登録方法や、タッチ漏れ、現場変更時の修正も、要件に含めておきます。また、退職者や契約が終わった協力会社のデータは、保持期間を決めておきます。

CCUSの現場運用では、元請が現場と契約の情報を登録し、下請が施工体制と所属技能者を登録します。このように業務の境界が、単一会社で完結する人事システムとは異なります(出典:一般財団法人建設業振興基金「CCUSを使う」、2026年確認)。

建設キャリア管理システムの発注形態

認定API連携システムの導入、個別開発、両者の組み合わせを並べた図です。
標準機能を使う方法と独自機能を加える方法を選べます。

発注形態は、認定API連携システムの導入、個別開発、両者の組み合わせの3つから選びます。判断材料になるのは、現場数と協力会社数です。既存システムや独自業務の強さも、判断に加えます。

初期段階では、標準機能やSaaSで運用を始めるのが現実的です。そのうえで、差別化に必要なデータ連携や評価機能だけを追加します。

SaaS・パッケージ導入が向く企業

短期間で現場へ展開したい場合や、業務を標準化できる場合は、SaaS・パッケージを中心に検討します。入退場方式や運用支援を選べる点が、この方式の利点です。

  • 入退場方式:カードリーダー、QRコード、顔認証、電話発信のなかから選べます。
  • 継続支援:導入後もアップデートや運用サポートを受けられます。
  • 追加費用:端末、通信、初期設定、データ移行、協力会社向け説明会が、別に発生する場合があります。

国土交通省の資料でも、認定API連携システムは利用可否が元請ごと、現場ごとに異なるとされています。そのため、候補製品の認定だけで契約を決めず、実際の利用条件を確認します。

スクラッチ開発・ハイブリッド発注が向くケース

個別開発の価値が高まるのは、独自業務が競争力につながる場合です。次のような要件が判断材料になります。

  • 独自の技能評価:自社の評価業務を、システムに反映させたい場合です。
  • 複数会社の権限:会社をまたぐ権限モデルを、システムで扱う必要があります。
  • 基幹データ連携:採用・人事、給与、ERPとの深い統合が求められる場面です。

CCUSの登録や就業履歴は自社で再現せず、標準APIや認定サービスを使うほうが安全です。独自業務は、上位のレイヤーで開発します。

ハイブリッド発注では、SaaS会社と開発会社のどちらがどこまでを受け持つかを決めておきます。障害時の窓口や、API仕様変更への対応者も、契約前に定めます。

ポイント

迷ったら、標準機能やSaaSで運用を始め、差別化に必要なデータ連携や評価機能だけを後から追加する方法を検討します。認定サービスの利用条件は、元請や現場ごとに確認が必要です。

RFP・要件整理で決めること

RFPで整理するアクセス管理、安全管理、委託先管理の3項目を示した図です。
情報へのアクセス、保護措置、委託先を分けて整理できます。

RFPは、機能一覧だけでなく、誰がどの現場で、どのデータを、いつ登録するかを伝える文書です。現場の一日の流れを起点に、業務とデータの流れを書き、例外処理や運用体制も加えます。

「CCUSと連携できるシステム」とだけ依頼すると、各社が異なる前提で見積を作ります。前提がそろわないため、金額と納期を比べられません。

現場の業務フロー

元請による現場の開設から、下請の登録、技能者の入場、月末の履歴確認と修正までを順に書き出します。通常の運用から外れる場面も、同じ流れに含めます。

  • 入場時:カードを忘れた人、スマートフォンを持たない人、雨天や通信不良の場面を想定します。
  • 現場変更:現場の追加、所属の変更、重複登録を扱います。
  • 退職後:退職した人の就業履歴を、どう照会するかを決めます。

各工程に「現場監督の作業を何分減らしたいか」「協力会社は何回の入力で完了するか」といったKPIを置いておくと、開発後の評価に使えます。

データ項目とAPI連携の境界

RFPには、まず技能者IDや氏名、所属、職種を書きます。資格、健康診断、社会保険も記載します。さらに、現場IDや契約、施工体制のほか、就業日、立場、修正履歴も含めます。

CCUSから取得するデータ、自社システムから送るデータ、画面で人が確認するデータを、分けて書きます。接続先の仕様と連携頻度を確かめ、エラー時の再送や名寄せキーも見ておきます。

  • 連携先:勤怠、給与、会計、建退共、安全書類、施工管理のなかから、対象を決めます。
  • 連携方式:既存システムとのAPIまたはCSV連携の方式。
  • 品質条件:登録情報の正確さとエラー時の再送を要件に含めます。

2026年にはCCUSと建退共の自動連携が拡充されています。ただし、施工体制技能者情報などが正しく登録されていないと連携エラーになります。そのため、データ品質も要件に含めます(出典:建設業振興基金「2026年6月11日 CCUS運営状況」、2026年)。

権限・個人情報・運用条件

システムでは、本人確認書類や資格、健康診断、社会保険、就業履歴を扱う可能性があります。そのため、役割ごとの閲覧と修正の範囲や、データの保持、退職・契約終了時の扱いを明記します。

  • アクセス管理:元請、下請、現場管理者、本人、人事部門の権限を分けて設定します。
  • 安全管理:二要素認証、暗号化、バックアップ、操作ログの扱いを定めます。
  • 委託先管理:再委託先、保管場所、事故報告、監査協力の条件。

個人情報保護委員会は、人事労務管理サービスをクラウドで提供・利用する場合について注意喚起しており、その内容は安全管理措置と委託先の監督です(出典:個人情報保護委員会「人事労務管理のためのサービスをクラウド環境で提供・利用する場合の注意喚起」、2024年12月)。

ポイント

RFPには、通常の業務と例外時の流れを同じ文書に書き、CCUSと自社システムのどちらが正として持つデータかを項目ごとに決めておきます。

契約形態と開発スケジュールの設計

要件が変わりやすい上流工程と、仕様を固定する下流工程を同じ契約で扱うと、追加費用や責任の範囲があいまいになりやすいです。

要件定義、PoC、開発、運用保守に分け、各段階で納めるものと、次へ進む条件を決めておきます。契約書では、納品物と検収条件、知的財産権、データ返却を具体的に定めます。さらに、障害対応、API変更、再委託、秘密保持も、同じ契約書で具体化します。

準委任と請負の使い分け

協議しながら成果を作る要件定義や業務整理では、準委任契約が検討しやすいです。一方で、完成機能、検収条件、納期が明確な実装工程は、請負契約の対象にしやすくなります。

責任は、契約名よりも実態と契約条項で決まります。「CCUS連携一式」や「データ移行一式」のような包括的な記載は、対象件数、成功条件、エラー時の扱いを別紙で定めておきます。

1〜3現場のPoCと本番展開

最初から全社や全現場へ広げず、条件の異なる1〜3現場でPoCを行います。現場条件の違いを含めておくと、本番で起こる課題を早く見つけられます。

  • 端末条件:カードリーダーを置ける現場と、置けない現場の両方。
  • 現場環境:協力会社の多い現場や、通信が不安定な現場。
  • 測定項目:履歴登録率、漏れの修正時間、登録完了日数、管理者の月間作業時間を測ります。

目標値を達成した機能だけを標準化します。未達の機能は、原因を整理してから追加開発します。

検収と保守の条件

検収では、実際の現場シナリオが完了することを基準にします。協力会社による技能者登録から、入退場記録、エラー修正、帳票反映までをテストします。

保守契約では、問い合わせの時間帯と、重要度別の初動・復旧目標を定めます。CCUSや外部APIの仕様変更、端末故障、バックアップからの復旧も、対象に含めます。

解約時に、CSVなどで全データを返却できるかも確認します。この返却条件は、長期の外注リスクを左右します。

ポイント

工程ごとに契約を分け、要件定義や業務整理は準委任、完成機能の実装は請負で検討します。次へ進む条件を段階ごとに決めておくと、追加費用の範囲を見極めやすくなります。

建設キャリア管理システムの費用相場

費用は、CCUS公式料金と民間SaaSの利用料、端末・通信費を含めて合算します。導入支援費、個別開発費、保守費も加えます。

CCUS公式料金だけを見ると安く見えます。ただし、協力会社の登録支援や既存システム連携まで含めると、発注金額は大きく変わります。

ここで示す開発費は、建設業向けの業務システムや、2026年時点の一般的な業務系Webシステムの公開相場をもとにした推定です。CCUS専用開発の公定価格ではありません。

CCUS公式料金(開発費とは別計算)

CCUS公式料金は、登録区分や利用量によって異なります。見積もりでは、次の料金を民間費用と分けて扱います。

  • 技能者登録:簡略型2,500円、詳細型4,900円です。詳細型は資格や健康診断を登録し、能力評価の申請情報を扱います。
  • 事業者登録:資本金に応じ、一人親方は0円、個人事業主を含む資本金500万円未満は6,000円から、500億円以上は2,400,000円までです。
  • 管理者ID:1IDあたり年11,400円、一人親方は2,400円です。
  • 現場利用:就業履歴1人日・1現場あたり10円です(出典:建設業振興基金「ご利用方法・料金」、2026年確認)。

20人が50日就業する現場の利用料は、20人×50日×10円で10,000円です。

この金額には、民間システムの月額や端末、通信、初期設定、データ移行、問い合わせ対応の費用が含まれません。公式料金は利用量に応じて見積もりに入れ、民間ベンダーの費用とは分けてください。

個別開発費は300万〜5,000万円超の幅

規模ごとの開発費を比べると、必要な機能と連携範囲に応じた概算をつかめます。

  • 小規模PoC・MVP:300万〜800万円程度です。
  • 中規模システム:800万〜2,000万円程度です。
  • 大規模システム:2,000万〜5,000万円超の可能性があります。

小規模では、マスター、現場登録、QRまたはカードによる入退場、基本一覧、CSV出力に機能を絞る想定です。既存サービスでCCUS連携を補い、独自画面を限定すると、費用は下限に近づけます。

中規模では、標準APIと施工体制を含む想定です。資格・社会保険や権限も含め、さらに帳票とスマートフォン画面も対象に入ります。勤怠や建退共などとの連携も、範囲に入ります。

大規模では、多現場や多層下請、SSOを含む想定です。給与・会計・ERP連携も範囲に加わり、データ移行も対象です。さらに、監査ログと独自評価を含み、複数会社対応と冗長化も必要になります。この範囲は、公開相場を連携・セキュリティ・現場運用の難易度で補正した推定です。

2026年6月の開発費解説では、業務系Webシステムの相場を小規模100万〜300万円、中規模300万〜800万円、大規模800万円〜数千万円としています。なお、金額は工数と付帯費用によって変動します(出典:イー・ジーシステム「システム開発の費用相場と見積書の読み方」、2026年6月)。

保守・端末・運用支援の費用

初期開発費以外の費用も内訳に分けると、運用時の総額を比べられます。

  • 利用・設備費:月額・年額のクラウド利用料、CCUS料金、端末の購入やレンタル、通信、顔認証ライセンスが対象です。
  • 運用費:監視、バックアップ、問い合わせ窓口、アップデート、データ修正代行を、契約の範囲に含めて確認します。
  • 従量・追加費:現場数や技能者数の増加に伴う課金、協力会社アカウント、データ出力の有償化。

現場数や技能者数に応じた課金と、出力の有償化は、3年総額に影響します。そのため、初年度だけでなく、3年または5年のTCO(総所有コスト)で比べると、初期費用だけに左右されにくくなります。

ポイント

見積は、CCUS公式料金と民間の費用を別欄に分けて依頼し、3年または5年の総額で比べると判断しやすくなります。開発費は、規模ごとの概算レンジとして受け取ります。

委託先選定と見積比較のポイント

委託先は、建設業向けかどうかに加えて、CCUS連携、現場運用、データ移行、協力会社の定着、個人情報管理を扱えるかで評価します。

候補は3社前後に絞り、同じRFP、データ件数、現場条件をそろえて、提案と見積を依頼します。価格、機能、納期に加え、運用開始後に問題を解決する担当者も比べます。

認定・実績・現場適合性

候補会社には、CCUS標準APIの対象かどうか、施工体制や技能者情報の連携範囲、元請・現場ごとの利用条件を確認します。

国土交通省の公開資料には、Buildee、グリーンサイト、キャリアリンクなどの認定API連携システムが掲載されています。掲載された製品が対応する入退場方式には、カードリーダー、QRコード、顔認証、電話発信があります。

掲載されていても、すべての現場で使えるとは限りません。そのため、予定する元請、現場、デバイス、施工体制の条件で、利用できるかを確認します。

  • 導入実績:同規模の現場で扱った技能者数と協力会社数を尋ねます。
  • 修正対応:登録漏れや修正を、どのように処理したかを確認します。
  • 操作デモ:可能であれば依頼し、現場監督、協力会社の事務担当、技能者本人が操作します。

デモが成功するかどうかだけでなく、カード忘れや所属変更、現場追加、通信断、CCUS側のエラー時の手順も確認します。具体的に説明できる会社は、現場運用を理解している可能性があります。

見積の内訳と前提

見積書の工程と前提をそろえると、会社ごとの差を比べられます。「開発一式」とだけ書かれていると、対象範囲は判断できません。

  • 工程:要件定義、設計、実装、API連携、移行、テスト、教育、リリース、保守を確認します。
  • 数量・単価:人月、単価、画面数、端末台数、移行件数、保守時間をそろえます。
  • 付帯条件:外部サービス、テスト環境、出張費の扱い。

安い見積では、その理由を確かめます。例として、仕様の解釈が狭い、テストが少ない、保守が別料金、移行対象外、API調査なしなどがあります。

高い見積には、現場展開や説明会、移行リハーサル、障害訓練、セキュリティ診断が含まれる場合もあります。そのうえで、見積の差分に対する回答の速さと具体性も、選定の評価に加えます。

価格以外の評価軸

選定表では、次の評価軸を自社の失敗リスクに応じて点数化します。

  • 評価軸:要件適合、使いやすさ、連携実績、データ移行を点数にします。
  • 運用・費用:セキュリティ、支援、納期、3年総額、保守、データ返却を比べます。
  • 評価者:情報システム、現場監督、人事・労務、協力会社窓口の四者が採点します。
  • 最終候補:PoCの条件、終了時の出力、障害時の代替登録、制度やAPI変更への対応を確かめます。
  • 個人情報管理:再委託、権限、ログ、監査、事故報告、削除・返却の扱いを、契約と規程に定めます。

重みの付け方は一つではありません。要件適合や現場定着に、価格より高い重みを置く方法もあります。

人による最終確認を残しておくと、誤登録や誤評価の防止に役立ちます。

ポイント

委託先は、CCUS連携と現場運用、個人情報管理を扱えるかで評価します。見積は工程と前提をそろえて比べ、デモでは例外時の手順まで見ておく必要があります。

建設キャリア管理システムのよくある質問

発注前の疑問に、CCUS公式の料金・運用情報と、開発見積の考え方をもとに回答します。

具体的な費用や連携可否は、現場数、技能者数、協力会社数、既存システム、入退場方式によって変わります。自社の条件を添えたうえで確認する必要があります。

CCUSの利用料金だけでシステムを導入できますか?

CCUSの利用料金だけでは導入できません。CCUS公式料金は、技能者・事業者登録、管理者ID、現場利用の料金です。民間システムの月額や端末、通信、導入支援、個別開発、保守は、別に発生します。

公式料金と民間費用を別欄に分けた総額見積を依頼してください。

CCUS認定API連携システムならどの現場でも使えますか?

どの現場でも使えるとは限りません。国土交通省の資料でも、利用可否は元請ごと、現場ごとに異なるとされています。

対象現場の元請、施工体制、入退場デバイス、登録権限を伝えたうえで、実際の利用条件と代替運用を確認します。

最初からスクラッチ開発を発注するべきですか?

必ずしも必要ではありません。標準機能で解決できる現場運用は、SaaSや認定サービスで対応します。

独自の評価や基幹連携、データ統合など、差別化に直結する部分だけを個別開発します。そうすると、短期間で検証しやすくなります。

全社展開前に1〜3現場でPoCを行い、現場で本当に残る要件を確定してから開発範囲を広げると、手戻りを抑えられます。

委託先を変更するときデータは持ち出せますか?

契約とサービス仕様によります。形式、項目、費用、期限を契約時に定めておくと、持ち出せる可能性を高められます。

返却対象は、技能者、事業者、現場、施工体制の情報を明記します。さらに、就業履歴、修正履歴、添付書類、操作ログも含めるかを決めます。サンプル出力で中身も確かめます。

データ返却、削除証明、移行支援の範囲まで決めると、ベンダーロックインのリスクを下げられます。

まとめ

発注時はCCUS本体と民間の周辺システムを分け、現場の業務フローからRFPを作ります。発注形態は、SaaS・パッケージ、既存サービスと個別開発のハイブリッド、スクラッチ開発から選びます。選ぶときは、現場数、協力会社数、既存システム、独自業務の強さを基準にします。

費用は、CCUS公式料金と民間利用料を分けて把握します。端末・通信と導入支援も含めます。そのうえで、開発と保守を加え、3年総額で比較します。個別開発費の検討レンジは、小規模PoC・MVPで300万〜800万円、中規模で800万〜2,000万円です。

さらに、大規模・基幹連携型は2,000万〜5,000万円超です。これらは、公開されている業務系システムの相場を基礎にした推定です。

実額は要件定義後に再計算します。そのうえで、CCUS・API利用条件、個人情報の委託先監督、障害時の運用、データ返却を確認できる委託先を選ぶと、手戻りを抑えられます。

▼全体ガイドの記事
・建設キャリア管理システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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