安全書類作成システム開発の進め方/やり方/流れや方法/手法/工程/手順

安全書類作成システムの開発は、帳票を電子化するだけでなく、会社・作業員・資格・現場・施工体制の情報を一元管理し、提出から承認、更新までを継続できる業務基盤にする取り組みです。成功の要点は、要件整理から定着までを6つのフェーズに分け、法定項目と元請独自ルールを先に整理することです。

本記事では、安全書類作成システム開発の進め方を、要件整理、製品・開発会社の選定、設計・開発、テスト、稼働、定着の順に解説します。協力会社から書類を回収する方法、資格証の期限切れを見つける仕組み、CCUSや既存システムとの連携、2026年時点で確認したい費用相場と見積もりのチェックポイントまで、実務で判断できる形に整理します。

▼全体ガイドの記事
・安全書類作成システム開発の完全ガイド

安全書類作成システムとは何ですか?

安全書類作成システムの全体像

安全書類作成システムは、建設現場で使うグリーンファイルを、マスターデータから自動作成し、元請と協力会社の間で提出、確認、差し戻し、承認、保管するシステムです。施工体制台帳、施工体系図、再下請負通知書、作業員名簿、社会保険の加入状況、建設業許可証、資格証、健康診断や安全衛生教育の記録などを対象にします。国土交通省は、法令上必要な記載事項が含まれていれば作成例以外の様式も利用できると案内しています(出典: 国土交通省「施工体制台帳、施工体系図等」、2026年8月確認)。そのため、既存様式を画像やPDFで再現するだけではなく、法定項目と元請独自項目を分けて管理する設計が重要です。

帳票出力だけでなく情報基盤として考えます

Excelの帳票をシステムから出力できても、元となる作業員情報や資格情報が古ければ、現場で使える安全書類にはなりません。会社、協力会社、作業員、資格、保険、健康情報、工事、契約、施工体制をマスターとして持ち、1回更新した情報を複数の現場や帳票に反映できる状態を目指します。協力会社が別の現場でも同じ情報を再利用できれば、同じ資格証を何度も提出する負担を減らせます。元請側も、未提出、差し戻し、期限切れ、変更箇所を現場単位で確認しやすくなります。

最初に必要な機能と後回しにできる機能を分けます

最初に必要な機能は、会社・作業員・資格・保険・現場・施工体制の登録、帳票の自動生成、協力会社への招待と提出、差し戻し、承認、期限通知、Excel・PDF出力、権限管理、操作履歴です。添付ファイルの版管理や変更箇所の比較も、資格証や許可証を扱う現場では優先度が高くなります。一方、AIによる画像読み取り、高度な分析、入退場、作業日報、労務費、ERPとの連携は、MUST要件が安定した後に追加しても構いません。機能を増やすほど便利になるとは限らず、協力会社が迷わず入力できることを最初の品質基準にします。

安全書類作成システム開発の進め方

安全書類作成システム開発の6フェーズ

開発は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めます。各フェーズの完了条件を決めずに次へ進むと、後から帳票の差分、協力会社の権限、データ移行、CCUS連携が追加され、費用と期間が膨らみます。元請の現場担当だけでなく、一次・二次下請、現場事務、情報システム、法務・監査の代表者を初期から巻き込むことが大切です。

フェーズ1:要件整理で対象範囲と業務ルールを決めます

最初に、現在どの書類を、誰が、いつまでに、誰へ提出し、どの条件で差し戻しているかを一覧化します。施工体制台帳、施工体系図、再下請負通知書、作業員名簿、資格証、許可証、保険、健康診断、安全衛生教育、車両や持込機械に関する書類を、現場別に棚卸しします。現場ごとの締切、再提出の回数、紙・Excel・メール・共有フォルダの使い分けも記録します。ここで「提出されたら完了」ではなく、「内容を確認し、承認履歴を残し、期限切れを検知できたら完了」と定義することが重要です。

要件はMUST、SHOULD、WANTの3段階に分けます。MUSTには、マスター登録、書類生成、提出・差し戻し・承認、期限通知、権限、出力、ログ、バックアップを置きます。SHOULDには、CSV一括登録、スマートフォン対応、変更箇所の比較、CCUS連携を置き、WANTにはAIの入力補助や入退場との連携を置くと、初回導入の範囲を制御できます。完了条件は、対象帳票一覧、業務フロー、権限表、データ項目表、移行方針、パイロット現場が合意されている状態です。

フェーズ2:製品と開発会社を実データで選定します

選定では、SaaS、パッケージ、個別開発を同じ業務シナリオで比べます。代表的な現場の施工体制、一次・二次下請の会社情報、作業員名簿、期限切れの資格証、元請独自の追加書類を用意し、招待から提出、差し戻し、承認、帳票出力までをデモまたはPoCで確認します。機能一覧の「対応」だけでは、元請独自様式への対応方法や、協力会社が無料で使えるか、現場数・ID数・ファイル容量の制限までは分かりません。

評価表には、法定帳票、独自帳票、CCUS、データ移行、権限、スマートフォン、通知、API、サポート、契約終了時のデータ返却を入れます。「CCUS対応」も、ログイン連携、情報の取り込み、帳票出力、入退場データ連携のどこまでを意味するか確認します。国土交通省は施工体制台帳などをCCUSで作成でき、民間システムにもCCUS情報を利用できるものがあると案内しています。自社が必要とする連携範囲を言葉にしてから比較することが大切です。

フェーズ3:業務・データ・帳票を設計して開発します

設計では、画面より先にデータモデルを決めます。会社、現場、工事契約、施工体制、作業員、資格、保険、健康情報、教育履歴、添付ファイル、提出状態、承認履歴をどの単位で管理するかを定義します。作業員が複数の会社や現場に関係する場合の所属期間、退職・異動、資格の有効期限、同じ証明書の更新履歴も想定します。過去データをそのまま移すのか、現在有効なマスターだけを移すのかを決めないと、移行作業と運用開始後の検索が複雑になります。

帳票は、全建統一様式、元請独自様式、現場ごとの追加書類を分けて管理します。全建統一様式は令和6年10月の改訂6版が案内されているため、古いExcelの見た目を固定的に再現するのではなく、様式改訂時に項目と出力を更新できる仕組みにします(出典: 一般社団法人全国建設業協会「全建統一様式 改訂6版」、2024年10月)。アクセス権は、元請の全体管理者、現場担当、協力会社管理者、作業員本人などに分け、健康情報や資格証画像を必要以上に公開しない設計にします。多要素認証、通信・保存時の暗号化、操作・ダウンロードログ、バックアップ、保存期間、削除手順も設計書に含めます。

フェーズ4:書類・権限・連携を分けてテストします

テストは、単体テスト、連携テスト、業務シナリオテスト、受入テスト、障害復旧テストに分けます。作業員を追加して複数帳票に反映されるか、資格の期限が近づいたら通知されるか、差し戻し理由と再提出版が残るか、承認者以外が承認できないかを確認します。通常の提出だけでなく、二重登録、同じ証明書の差し替え、協力会社の退会、現場の終了、通信切断、ファイル容量超過、CCUS側の一時停止もシナリオに入れます。

受入テストの合格条件は、画面が表示されることではなく、現場業務の成果で決めます。たとえば、代表現場の書類を決めた締切までに回収できること、期限切れを一覧で見つけられること、元請独自様式に必要な項目が出力されること、操作履歴から承認経路を説明できることを条件にします。個人情報を含むテストでは、実データをそのまま使わず、氏名、住所、生年月日、資格番号、証明書画像などをマスキングします。

フェーズ5:1〜2現場から稼働して安全に切り替えます

本番稼働は、全社・全現場への一斉切り替えではなく、1〜2現場のパイロットから始めます。元請の規模だけでなく、一次・二次下請の数、書類の種類、現場事務の習熟度、電波状況、協力会社のPC・スマートフォン利用環境が異なる現場を選ぶと、実運用の課題が見えます。パイロットでは、書類1件あたりの作成時間、提出率、差し戻し件数、回収リードタイム、期限切れの発見数、問い合わせ件数を導入前と比較します。

切り替え前には、データ移行の基準日、旧Excelの参照期間、未提出書類の扱い、旧運用へ戻す条件、障害時の連絡先、手作業の代替帳票、稼働判定者を決めます。最初の一定期間は旧運用と新システムを並行させ、作業員数、施工体制、資格期限、出力帳票が一致するか確認します。現場の開始日に合わせて急いで稼働するのではなく、協力会社への説明会と問い合わせ窓口を準備してから切り替えます。

フェーズ6:KPIと教育で現場に定着させます

稼働後は、システムを導入したかではなく、業務が改善したかを月次で確認します。作成時間、協力会社の提出率、差し戻し率、承認までの時間、資格・許可証の期限切れ件数、問い合わせ件数、紙やメールの残存件数をKPIにします。Greenfile.workについて国土交通省が公表した取組概要では、従来の紙・Excel運用と比べて安全書類業務の時間を73.8%削減した事例が紹介されています(出典: 国土交通省「インフラDX大賞受賞取組概要」、2023年)。ただし、これは特定サービスと導入条件における事例であり、自社の効果としてそのまま約束する数字ではありません。

定着には、管理者向けの機能研修だけでなく、協力会社向けに「どの書類を、いつまでに、どの画面から提出するか」を現場の業務シナリオで伝えることが必要です。会社情報や資格情報の更新申請、権限の棚卸し、帳票テンプレートの変更、問い合わせの一次受付、月次KPIの確認を運用手順にします。現場から出た改善要望はすぐに追加開発せず、法令対応、提出率向上、作業時間削減、情報漏えい防止のどれに効くかを確認して優先順位を付けます。

安全書類作成システムの費用相場とコストの内訳

安全書類作成システムの費用相場

費用は、SaaSの利用料、初期設定、データ移行、帳票設定、連携開発、教育、保守に分けて考えます。安全書類に特化したスクラッチ開発の公的な価格統計は限られるため、以下の開発費は、NotebookLMリサーチで確認した業務システムの相場と機能範囲をもとにした検討用の推定レンジです。企業規模、現場数、協力会社数、データの状態、独自様式、CCUSや既存システムとの連携によって大きく変わるため、確定金額ではなく、RFPの予算枠を置くための目安として利用します。

SaaS導入では月額と初期設定を分けて確認します

公開料金の実例として、Buildee労務安全は、支店登録料が初回5万円、基本利用料が月額3万円、現場利用料が1現場あたり月額6,000円、協力会社利用料が無料と案内されています(出典: Buildee公式「労務安全 ご利用料金」、2026年8月確認)。この条件で1支店・5現場を1年間利用する単純計算は、5万円+3万円×12か月+6,000円×5現場×12か月で、税別77万円です。実際には現場説明会、他サービス、契約条件、導入支援などが加わるため、公開料金だけで総額を判断しないようにします。

一般的なSaaS導入・初期設定のみであれば、アカウント、現場、帳票セット、権限、操作説明を含めて10万〜100万円程度を検討するケースがあります。既存パッケージへの帳票設定、CSV連携、データ移行、CCUS連携の追加開発まで含める場合は、100万〜500万円程度の推定レンジになります。金額が低く見えても、協力会社への説明会、過去データの整理、追加現場、ファイル容量、サポートが別料金になっていないか確認します。

専用システムの開発費は機能範囲で段階的に見ます

小規模な専用システムは、会社・作業員・資格マスター、帳票自動生成、提出管理に絞る場合で300万〜800万円程度、開発期間は3〜6か月程度が一つの推定目安です。多現場、協力会社ポータル、承認、期限通知、権限、監査ログ、CCUSやAPI連携を含む中規模システムは、800万〜2,000万円程度、6〜12か月程度を見込みます。入退場、労務費、施工管理、ERP、複数企業・多テナント、高可用性まで統合する大規模な基盤は、1,500万〜4,000万円以上になる可能性があります。

これらは安全書類作成システムの公的統計ではなく、業務システムの一般的な費用情報を、安全書類の機能範囲に置き換えた推定です。特に費用を左右するのは画面数ではなく、協力会社の招待と利用方式、既存データの重複整理、元請ごとの帳票差分、添付ファイル容量、権限の細かさ、連携先、監査・セキュリティ要件です。見積もりでは、開発費だけでなく、保守、クラウド、追加現場、追加ユーザー、教育、帳票改訂、脆弱性診断、データ返却費まで含めた5年程度の総保有コストを比べます。

ランニングコストと費用負担者を設計段階で決めます

安全書類は元請だけでなく協力会社も利用するため、誰が費用を負担するかが導入の成否に影響します。元請が基本料金を支払い、協力会社の利用料を無料にする方式、現場数や会社数に応じて元請が支払う方式、会社ごとにIDや機能を課金する方式などがあります。協力会社に有料登録を求める場合は、同じ情報を別の元請現場へ再利用できるか、退会後にデータを取り出せるか、費用に見合うメリットを説明できるかを確認します。

契約では、月額の改定条件、最低利用期間、現場終了後の課金、ファイル容量、API利用料、サポート時間、障害時の補償、バックアップ、解約時のデータと帳票の返却形式を確認します。個人情報保護委員会は、クラウドなどの委託先について安全管理措置の確認、委託契約、取扱状況の把握を求めています。ISO認証の有無だけでなく、再委託、保管場所、事故時の通知、返却・消去の責任分界を契約書で確認します。

見積もりを取る際のポイント

安全書類作成システムの見積もり

「安全書類作成システムを作りたい」とだけ伝えると、開発会社ごとに想定する帳票、現場数、ユーザー数、連携、移行範囲が異なり、見積もりを比較できません。RFPでは、業務範囲、データ、機能、非機能、移行、教育、運用、責任分界を分けて記載します。提案書では、標準機能、設定で対応する部分、追加開発、対象外を分けてもらうと、後から追加費用になりやすい項目を把握できます。

RFPには何を記載すればよいですか?

RFPには、対象となる支店、現場、協力会社、作業員、月間の書類件数、帳票種類、同時利用者数、利用端末、現場の通信環境を記載します。会社・作業員・資格・保険・健康情報・施工体制の現行データ件数と、重複や期限切れの有無も伝えます。帳票については、全建統一様式、元請独自様式、現場固有の追加書類を分け、サンプルを渡します。CCUS、施工管理、入退場、会計、人事などの連携先は、連携方式と必要項目まで書きます。

非機能要件には、権限の単位、MFA・SSO、暗号化、ログの保存期間、バックアップ、復旧目標、稼働時間、障害時の連絡、個人情報の保管場所、再委託、データ返却を含めます。さらに、協力会社の招待方法、無料利用の範囲、スマートフォンでできる操作、通知方法、説明会の有無を明記します。要件が固まっていない場合は、要件定義とパイロットを先行発注し、本開発と契約を分ける方法もあります。

開発会社や製品は同じデータで比較します

候補を2〜3社に絞ったら、同じデータセットと同じ業務シナリオでデモまたはPoCを依頼します。確認するのは、登録のしやすさだけではありません。協力会社の招待、未提出一覧、差し戻し理由、期限切れ通知、資格証の更新、元請独自様式の出力、承認履歴、帳票の一括ダウンロード、退場した作業員の扱いまでを実際に操作します。現場担当が10分程度の説明で使えるか、協力会社がスマートフォンから迷わず提出できるかも評価します。

既製SaaSが向くのは、標準化できる帳票を早く使い始めたい企業です。パッケージへの追加設定は、施工体制や帳票が近く、既存の施工管理と統合したい企業に向きます。スクラッチ開発は、元請独自の承認、契約、入退場、労務管理まで一つの基盤にしたい場合に検討します。標準機能を活用し、独自性が必要な部分だけAPIや追加開発で補う段階的な構成は、費用と保守性のバランスを取りやすい選択です。

見積もりの抜け漏れと開発リスクを先に潰します

追加費用になりやすいのは、元請ごとの帳票差分、過去データの移行、重複した会社や作業員の整理、添付ファイルの大量移行、通知の細かな条件、APIの仕様変更、協力会社への説明会、帳票改訂への対応です。見積書に「帳票一式」「データ移行一式」「連携一式」とだけ書かれている場合は、対象数、作業内容、納品形式、検収条件を分解してもらいます。準委任か請負か、仕様変更の扱い、検収時の不具合修正、保守の開始時点も確認します。

契約には、データの所有権、API仕様書や帳票テンプレートの利用権、設計書の納品範囲、ベンダー変更時の移行支援、解約後のエクスポート形式を入れます。安全書類には作業員の個人情報や資格証画像が含まれるため、事故時の報告期限、再委託先、国外保管、アクセスログ、バックアップからの復元を質問します。要件変更をすべて拒むのではなく、法令・元請指定・セキュリティに関係する変更と、便利機能の追加を分けて管理することが重要です。

よくある質問(FAQ)

安全書類作成システムのよくある質問

安全書類作成システムは、法定様式、元請の運用、協力会社の使いやすさ、個人情報の保護を同時に考える必要があります。ここでは導入前に特に質問されやすい点を、判断に使える形で回答します。

CCUSを使っていても安全書類作成システムは必要ですか?

必要性は、元請の指定、対象現場、必要な帳票、協力会社との回収・承認運用によって決まります。CCUSは登録情報を使った施工体制台帳や作業員名簿などの作成支援ができますが、民間システムは元請独自の書類、差し戻し、期限管理、現場ごとの権限、周辺システム連携を補える場合があります。CCUSと民間システムのどちらか一方に決めるのではなく、データの重複入力と責任分界を確認して併用可否を判断します。

中小建設会社はスクラッチ開発とSaaSのどちらがよいですか?

標準的な安全書類を扱い、早く導入して協力会社の負担を抑えたい場合は、SaaSから比較するのが現実的です。独自様式や社内承認が多い場合でも、最初から全機能をスクラッチで作るのではなく、SaaSのパイロットで業務を標準化し、差別化が必要な部分だけ追加開発する方法があります。自社専用の開発を選ぶのは、複数現場で共通する独自ルールが明確で、保守・セキュリティ・データ管理を長期的に担える体制がある場合です。

過去のExcelや紙の安全書類はすべて移行すべきですか?

すべてを移行する必要はありません。現在進行中の現場と有効期限のある資格・許可・保険情報を優先し、終了済み現場の帳票は法令や社内規程に必要な期間だけ、検索可能なPDFなどで保管する方法があります。移行前に会社名の表記揺れ、退職者、重複作業員、期限切れ、画像の欠落を整理し、マスターとして移すデータとアーカイブとして保管するデータを分けます。

作業員名簿や資格証画像の個人情報はどう守りますか?

会社、現場、役割ごとに閲覧範囲を分け、必要な人だけが必要な情報を見られるようにします。多要素認証、通信・保存時の暗号化、操作・ダウンロードログ、バックアップ、期限を決めた削除、退職者や退場者の権限停止を実装し、委託先・再委託先の安全管理も契約で確認します。本人確認書類などを扱う場合は、マイナンバーが写り込まないようにするなど、目的に不要な情報を収集しない運用も重要です。

まとめ

安全書類作成システム開発のまとめ

安全書類作成システムの進め方は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分けると判断しやすくなります。最初に、書類の種類だけでなく、協力会社からの回収、差し戻し、承認、期限切れ、元請独自様式、CCUSとの役割分担を整理します。法定記載事項を満たすことと、現場・協力会社が使い続けられることは別の検証項目です。

導入前に6項目を確認します

導入前は、(1)対象現場と帳票の範囲、(2)会社・作業員・資格・施工体制データの状態、(3)協力会社の費用と入力方法、(4)CCUS・既存システムとの連携範囲、(5)権限・ログ・暗号化・データ返却、(6)パイロットのKPIを確認します。この6項目がRFPと見積書に反映されていれば、価格だけでなく、導入後に発生する追加作業や運用負担も比較しやすくなります。

まず1〜2現場で効果を測定してから広げます

最初から全社の書類を移すのではなく、代表的な1〜2現場で、作成時間、提出率、差し戻し率、回収リードタイム、期限切れの発見数を測定します。数値と現場の声をもとに、帳票や権限、教育を改善してから対象を広げると、協力会社の利用停止や想定外の追加開発を抑えられます。公開料金と推定相場は自社の条件に合わせて再計算し、複数社から同じ前提の見積もりを取得して、長く使える安全書類作成システムを選びます。

▼全体ガイドの記事
・安全書類作成システム開発の完全ガイド

会社紹介

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

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

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

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

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

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