執筆：Swooo編集部／監修：北浦 聡大（Bubble公式認定デベロッパー・国内初合格／Swooo共同創業者・元CTO）
工事台帳や原価管理のシステム化は、「どのツールを入れるか」より先に「どの業務をSaaSに任せ、どの業務を自社に合わせて開発するか」を切り分けるところから始めると失敗しにくくなります。勤怠管理や工程表の共有のように既製の建設SaaSで十分に効率化できる業務がある一方で、協力会社ごとに書式が異なる請求書の処理や自社独自の粗利計算のように、既製ツールでは手が届きにくく、自社に合わせた開発が効く業務もあるからです。
この記事では、中堅の建設会社・工務店・専門工事会社の経営層や管理部門に向けて、建設業の人手不足の現在地、工事台帳・原価管理がExcelで行き詰まる理由、SaaSと自社開発の切り分け、そしてSwoooが実際に開発した建設業向け原価管理AIツール「工事台帳アシストAI」の事例までを一通り解説します。
実際に建設業向けのシステムを設計・開発した経験にもとづく内容です。
目次
建設業務別の早見表：SaaSで済むか、開発が効くか
最初に結論の早見表を示します。建設業の管理業務ごとに、既製の建設SaaSで十分か、自社に合わせた開発が効くかを整理したものです。詳しい理由は後の章で解説します。
| 業務 | 向いている手段 | 理由 |
|---|---|---|
| 勤怠管理・労務管理 | SaaSで十分 | 建設業向けの勤怠SaaSが成熟しており、開発する理由がほぼない |
| 工程表の作成・共有 | SaaSで十分 | 汎用の工程管理SaaSで大半をカバーできる |
| 現場写真・図面の管理 | SaaSで十分 | 専用SaaSが充実。撮影から整理・共有まで標準機能で足りる |
| 見積書・請求書の発行（標準帳票） | SaaSで十分 | 自社が発行する側の帳票は書式を統一できるため、既製ツールと相性がよい |
| 協力会社から届く請求書・納品書のデータ化 | 開発が効く | 書式が会社ごとにバラバラで、定型フォーマット前提のツールでは吸収しきれない |
| 自社独自の原価・粗利計算 | 開発が効く | 費目の分類や経費の配分ルールは会社ごとに異なり、既製の計算ロジックに載せにくい |
| 既存の基幹・会計システムとの連携 | 開発が効く | 自社固有のシステム構成に汎用の連携機能が合わないことが多い |
| 工事台帳の作成・更新 | 場合による | 標準的な台帳ならSaaSで足りる。独自の項目や集計軸が多いなら開発が効く |
大づかみに言えば、「どの会社でも同じ形の業務」はSaaS、「自社にしかない形の業務」は開発という切り分けです。この視点を持たずに進めると、SaaSで済む領域に開発費を投じたり、逆にツールを何本も契約したのに肝心の原価集計が手作業のまま残ったりします。どちらの失敗も、手段から入って業務の切り分けを後回しにしたときに起こります。
前提：建設業の人手不足は構造的で、効率化は選択肢ではなく前提
切り分けの話に入る前に、なぜ今このテーマなのかを数字で押さえておきます。
2024年4月から、建設業にも時間外労働の上限規制が適用されました。原則として月45時間・年360時間が上限です。それまで猶予されていた長時間労働による吸収が制度上できなくなり、同じ工事量を回すには業務そのものを軽くするしかなくなりました。いわゆる建設業の2024年問題です。
担い手の減少はさらに深刻です。厚生労働省の資料によると、建設技能者はピークだった1990年代後半から大きく減り、2024年には約300万人となっています（厚生労働省資料）。しかも年齢構成が偏っており、60歳以上が約25.8%を占める一方、29歳以下は約12%にとどまります。
つまり、今後10年で相当数のベテランが現場を離れる一方、それを補う若手の入職が細いという構造です。
この2つの数字が重なると、管理業務への影響は現場以上に大きくなります。時間外労働を減らすには、現場監督が夕方以降にこなしてきた書類作成や原価の整理を、誰かが肩代わりするか、業務自体を軽くするしかありません。かといって管理部門の増員も、採用市場を考えれば容易ではないからです。
採用だけで解決するのは難しくなっており、「今いる人数で回る業務の形に変える」ことが、規模を問わずすべての建設会社の前提条件になっています。そして現場の施工と違い、工事台帳の作成や原価集計のような事務作業は、システム化で工数を大きく減らせる余地が残っている領域です。効率化はやるかやらないかの選択肢ではなく、事業を続けるための前提と捉えるべき局面に来ています。
工事台帳・原価管理がExcelで行き詰まる3つの理由
多くの建設会社では、工事台帳と原価管理をExcelで運用しています。工事件数が少ないうちはこれで十分に回りますが、規模が大きくなるにつれて、ほぼ決まったパターンで行き詰まります。
理由1：協力会社ごとに帳票の書式がバラバラで、手入力が消えない
最大の理由がこれです。協力会社から届く請求書や納品書は、会社ごとに書式がまったく違います。品目の書き方も、単価と数量の並びも、消費税の扱いもそろっていません。紙で届くものもあれば、PDFやFAXで届くものもあります。
この「入口のバラバラさ」がある限り、誰かが1枚ずつ内容を読み取り、工事ごとに振り分けてExcelに転記する作業がなくなりません。工事件数と協力会社の数が増えるほど、この転記工数は掛け算で膨らみます。
理由2：台帳が属人化し、担当者が抜けると止まる
長年運用されたExcel台帳は、特定の担当者だけが構造を理解している状態になりがちです。シートをまたぐ参照や独自の関数が積み重なり、「触っていいセル」と「触ると壊れるセル」の区別がその人の頭の中にしかありません。
担当者の退職や長期離脱で台帳の更新が止まるリスクは、前章で見た年齢構成を考えると、多くの会社にとって時間の問題です。
理由3：粗利が月次でしか見えず、赤字に気づくのが遅れる
転記が手作業である以上、台帳への反映はどうしても「月末にまとめて」になります。すると現場ごとの原価と粗利は月次でしか見えず、資材費の想定超過や追加工事の原価膨らみに気づくのは締め処理の後です。手を打てるタイミングを毎回1ヶ月分逃していることになります。
工事が終わってから赤字だったと判明する、いわゆる「どんぶり勘定」の正体は、担当者の怠慢ではなく、手入力を前提にした業務構造そのものにあります。
整理すると、Excelが悪いわけではありません。書式のそろわない帳票という「非定型な入口」を人力で吸収し続ける構造が、工事件数の増加と人手の減少に耐えられなくなるのです。だからこそ、次に考えるべきは「Excelを何に置き換えるか」であり、その選択肢がSaaSと自社開発の2つになります。
どこまでSaaSで済むか：正直な切り分け
Excelの限界が見えたとき、選択肢は大きく2つです。既製の建設SaaSを導入するか、自社に合わせてシステムを開発するか。ここは開発会社の記事だからといって開発に誘導せず、正直に切り分けます。
SaaSで十分な領域：標準化された業務
勤怠管理、工程表の作成・共有、現場写真や図面の管理、自社が発行する見積書・請求書。この領域は建設業向けSaaSがすでに充実しています。どの会社でもやることがほぼ同じ業務だからこそ、多くの利用企業の声を反映して既製品が磨かれているのです。
この領域をわざわざ開発するのは費用対効果に合いません。まずSaaSの導入を検討すべきですし、すでに導入済みならそのまま使い続けるのが合理的です。
見分け方の目安は、「その業務のやり方を同業他社に説明したとき、ほぼ同じですねと言われるかどうか」です。勤怠の集計方法や工程表の書き方は、会社が違っても大枠は変わりません。こうした業務は既製品の設計思想とぶつからないため、SaaSの導入がそのまま効率化につながります。
SaaSで吸収しきれない3つの領域
一方で、SaaSを入れても手作業が残り続ける領域が3つあります。
- 非定型帳票のデータ化：協力会社ごとに書式が異なる請求書・納品書は、定型フォーマットを前提にした読み取り機能では精度が出にくい領域です。結局、システムの手前で人がデータを整える作業が残ります
- 自社独自の原価・粗利ロジック：重機や共通経費を各現場にどう配分するか、外注費と材料費をどの粒度で分類するかは会社ごとの経営判断そのものです。既製の計算ロジックに自社のルールを合わせると、これまでの数字と比較できなくなります
- 既存の基幹・会計システムとの連携：長年使ってきた販売管理や会計のシステムと新しいツールの間を、汎用の連携機能だけでつなぎ切れないケースは珍しくありません。つながらない部分は、CSVの出力と取り込みという名の手作業になります
典型的なのは、原価管理SaaSを導入したものの、協力会社の請求書を読み取ってシステムに入力する作業だけが残ってしまうケースです。システムの中の集計や帳票出力は速くなっても、入口のデータ化が手作業のままでは、担当者の体感としての負荷はあまり変わりません。SaaS自体の問題ではなく、非定型な入口が自社固有の事情である以上、既製品の守備範囲の外にあるというだけの話です。
共通するのは、いずれも「自社にしかない形」を持つ業務だという点です。既製品は多数の会社に共通する形に合わせて作られるため、ここを無理にSaaSへ寄せるとツール側にも業務側にも歪みが出ます。この3領域こそ、自社に合わせた開発が効く場所です。
開発事例：工事台帳アシストAI（工数最大80%削減）
切り分けの話を具体的にするために、Swoooが実際に開発した建設業向け原価管理AIツール「工事台帳アシストAI」を紹介します。前章で挙げた「非定型帳票」と「原価・粗利の可視化」に正面から取り組んだ開発です。
課題：帳票の読み取りと転記に工数が集中していた
出発点は、建設業の煩雑な原価管理業務でした。協力会社から届く請求書・納品書は書式がそろっておらず、内容を読み取って工事ごとに振り分け、台帳に転記する作業が管理部門の工数を圧迫します。まさに前章までに見てきた「Excelで行き詰まる構造」であり、これは本事例に限らない話ですが、書式の統一を協力会社にお願いして回る解決策は、多くの建設会社にとって現実的ではありません。
解決：フォーマットが異なる帳票を、AIがそのまま読み取る
工事台帳アシストAIの中核は、請求書や納品書をアップロードするだけで、フォーマットが異なる帳票でもAIが自動で読み取る仕組みです。従来のOCRのように「この位置に金額がある」という帳票ごとの事前設定を前提とせず、AIとOCRを組み合わせることで書式の違いを吸収します。
読み取ったデータは現場ごとに集計され、工事別の原価と粗利率が可視化されます。月末の締めを待たずに現場の採算が見える状態です。
技術的な背景を補足すると、従来型のOCRは「文字を座標で拾う」仕組みなので、帳票のレイアウトが変わるたびに読み取り位置の定義が必要でした。協力会社が数十社あれば、その数だけ定義とメンテナンスが要る計算になり、現実的ではありません。
一方、LLM（大規模言語モデル）を組み合わせた読み取りでは、文字を拾ったうえで「これは品目名、これは単価、これは税額」という意味の解釈をAIが行います。位置ではなく意味で読むため、初めて見る書式にも対応しやすいのです。書式がそろわない建設業の帳票と、この技術の相性が良い理由がここにあります。
結果として、工事台帳作成の工数を最大80%削減しています。10あった転記・集計の作業が2になる計算で、人手不足の管理部門にとっては小さくないインパクトです。
削減された工数そのものに加えて、現場ごとの粗利率が締めを待たずに見えるようになる点も見逃せません。原価の実績が早く集まれば、進行中の工事への手当てだけでなく、次の見積もりの精度や受注可否の判断材料にもつながっていきます。原価管理のシステム化は事務作業の削減であると同時に、経営判断のスピードを上げる投資でもあるわけです。
開発：期間4ヶ月、Bubble＋Python＋LLM＋OCRの構成
開発期間は4ヶ月です。技術構成はBubbleとPython、ChatGPTなどのLLM、OCRを組み合わせたハイブリッド型です。一般に、画面や業務フローはノーコードで素早く作り、AIによる読み取りのような重い処理はPython側に切り出す構成が採られます。デザイン、要件定義、開発、テストまでSwoooが一貫して担当しています。
使う場面が「非エンジニアの管理部門」である以上、画面側は素早く作って利用者の声で直せるBubbleが向き、AIによる読み取りという重い処理はPython側に切り出す。この役割分担が、4ヶ月という期間と読み取り精度の両立につながっています。
この「ノーコード＋コード」のハイブリッド構成は、建設業に限らず業務システム全般で有効な型です。画面や帳票一覧のような変更要望の多い部分はノーコードで柔軟に、AI処理やデータ変換のような専門性の高い部分はコードで堅牢に。それぞれの得意分野に寄せることで、スクラッチで全部作るより短期間・低コストに収まります。
もう一つ重要なのがアクセス権限の設計です。原価や粗利率は経営情報そのものなので、誰がどの工事のどのデータを見られるかを細かく制御する必要があります。ここはBubbleのPrivacy Rulesという仕組みを使い、データベースのレベルで細かいアクセス権限制御を実装しました。画面上で見せない・見せるを切り替えるだけの見かけの制御ではなく、データの取得自体を権限で絞る設計です。
費用感と進め方：小さく検証してから広げる
自社に合わせた開発と聞くと数千万円規模を想像されがちですが、手法によって費用の幅は大きく変わります。目安は次のとおりです。
| 開発の内容 | 費用の目安 |
|---|---|
| 業務管理システム（ノーコード開発） | 50万〜200万円 |
| 業務管理システム（スクラッチ開発） | 500万〜1,000万円 |
| AI連携を含むアプリ（ノーコード開発） | 200万〜600万円 |
| AI連携を含むアプリ（スクラッチ開発） | 1,000万〜4,000万円 |
なお、本事例の開発金額は非公開のため、以下は同カテゴリの一般的な費用感です。工事台帳アシストAIのような「帳票のAI読み取り＋原価の可視化」は、AI連携を含むアプリに該当します。ノーコードとAI処理を組み合わせる構成なら、スクラッチで全部作る場合に比べて費用を大きく抑えられます。またAI部分だけを切り出せば、既存システムにLLMのAPI活用を足す小規模な構成で50万〜300万円程度、自社データを参照する本格的な業務組み込みで100万〜1,000万円程度が相場です。
このほか要件定義の工程は全体の10〜15%程度、稼働後の保守はノーコードの場合で月3万〜20万円程度が目安です。相場の詳しい内訳はWebアプリ開発の費用相場で解説しています。
進め方でお勧めしたいのは、最初から全業務を対象にせず、小さく検証してから広げることです。具体的には次の3段階です。
- ①検証：一番工数を食っている1業務（たとえば協力会社の請求書の読み取り）だけを対象に、実際の帳票で読み取り精度と削減効果を確かめる
- ②本番化：検証で効果が数字で見えた範囲を、日常業務で使える形に仕上げる。権限設計や例外時の運用ルールもこの段階で固める
- ③拡張：台帳の自動作成、原価・粗利のダッシュボード、会計システムとの連携へと範囲を広げる
この順序なら初期投資を抑えられるうえ、途中で「思っていたものと違う」となるリスクも小さくなります。特に帳票のAI読み取りは、自社の帳票で精度を確かめる工程を飛ばさないことが重要です。
開発会社の選び方：建設業の帳票を扱えるかを見る
開発を検討する場合、依頼先の見極めが結果を大きく左右します。建設業の原価管理という題材に対しては、次の観点を確認してください。
- 非定型データの処理・AI-OCRの実装経験があるか：書式がバラバラな帳票の読み取りは、AIを呼び出せば終わりではなく、読み取り結果の検証や例外処理の設計で精度が決まります。同種の実装経験の有無を、具体的な事例で確認しましょう
- 要件定義から一貫して対応できるか：原価管理は会社ごとのルールの塊です。出来上がった仕様書を実装するだけの体制ではなく、業務の聞き取りと整理から入れる会社のほうが、実態に合ったシステムになります
- 権限設計・セキュリティを具体的に語れるか：原価と粗利は社外にも社内にも見せる範囲を選ぶ情報です。どの仕組みでアクセス制御を実装するのか、設計レベルの説明を求めてみてください
- 小さく始める提案が出てくるか：最初から大規模な一括開発を勧めてくる場合は慎重に。検証から段階的に広げる進め方を提案できるかは、経験値の分かりやすい指標です
商談の場では、「うちの実際の請求書サンプルを見て、読み取れそうか判断してもらえますか」と聞いてみるのが手軽で確実です。実装経験のある会社なら、精度が出やすい帳票と苦手な帳票の傾向、検証の進め方まで、その場で具体的に答えられるはずです。逆に一般論しか返ってこない場合は、この分野の経験が浅い可能性があります。
Swoooは東証グロース上場の株式会社アイビスが運営する開発サービスで、Bubble公式のGoldパートナー（日本1位）です。工事台帳アシストAIのように、ノーコードとAI・Pythonを組み合わせた非定型帳票の処理を、要件定義から開発・テストまで一貫して手がけています。AIを開発工程にも取り入れた進め方はAI駆動開発の解説記事にまとめています。
よくある質問
Q. 紙やFAXの請求書が多くても、AIで読み取れますか？
スキャンや撮影で画像にできれば、AI-OCRの読み取り対象にできます。紙・FAX・PDFが混在している状態は建設業ではむしろ普通で、それを前提にした設計は可能です。
ただし精度は帳票の状態や書式の揺れに左右されるため、導入前に実際の帳票サンプルで読み取り精度を検証するのが確実です。検証を経ずに全面導入へ進まないことが、この分野では特に重要です。また、協力会社側に書式変更やデジタル化をお願いする必要がない点も、AI読み取り方式の利点です。取引先との関係を変えずに、自社側だけで完結できます。
Q. 既存の会計システムや販売管理システムは入れ替えが必要ですか？
入れ替えは必須ではありません。むしろ既存システムはそのまま残し、足りない部分（帳票のデータ化や原価の可視化）だけを開発して連携させる構成のほうが、移行リスクも費用も抑えられます。長年の運用で蓄積されたデータや、社内に定着した操作の習熟は、それ自体が資産だからです。既存資産を生かす前提で設計するのが基本であり、全面刷新は連携で解決できないことが明確になってから検討すれば十分です。
Q. どのくらいの規模の会社なら開発を検討する価値がありますか？
従業員数よりも、工事件数と協力会社の数で考えるのが実態に合います。並行する工事が多く、書式の異なる帳票が毎月大量に届く会社ほど、転記工数の削減効果が大きくなるからです。逆に工事件数が少なく帳票の種類も限られるなら、まずExcelの整理やSaaSで十分な場合もあります。
判断に迷う場合は、「帳票の処理と台帳の更新に月何時間かかっているか」を一度計ってみてください。その時間が担当者の業務のかなりの割合を占めているなら、検討の入口に立っていると言えます。
Q. SaaSと自社開発は併用できますか？
併用が現実的な標準形です。勤怠・工程・写真管理は既製SaaSに任せ、非定型帳票の処理や自社独自の原価計算だけを開発で埋める構成が、費用対効果の面で最も合理的です。すでに使っているSaaSを置き換える開発は、基本的に避けるべきです。
開発するシステムの側からSaaSや会計システムのデータを参照する連携も設計できるため、「SaaSか開発か」の二者択一で考える必要はありません。それぞれの得意領域に役割を割り振るのが、結局いちばん安く、いちばん長持ちします。
Q. 開発期間はどのくらいかかりますか？
範囲によります。工事台帳アシストAIは、デザイン・要件定義から開発・テストまで含めて4ヶ月でした。帳票読み取りの検証だけを先に行うような小さな始め方なら、より短い期間で効果の有無を確かめられます。対象業務と連携するシステムの数を伝えたうえで、概算の期間と費用を確認するのが早道です。
まとめ：標準化できない業務ほど、開発の価値が上がる
建設業の原価管理・工事台帳のシステム化のポイントを整理します。
- 時間外労働の上限規制（2024年4月適用）と技能者の減少（2024年に約300万人・29歳以下は約12%）により、管理業務の効率化は選択肢ではなく前提になっている
- Excel台帳が行き詰まる根本原因は、協力会社ごとにバラバラな帳票書式と、それを前提にした手入力の構造にある
- 勤怠・工程・写真管理・標準帳票はSaaSで十分。非定型帳票のデータ化、自社独自の原価ロジック、基幹システム連携は自社に合わせた開発が効く
- Swoooが開発した工事台帳アシストAIでは、書式の異なる請求書・納品書をAIで自動読み取りし、工事台帳作成の工数を最大80%削減した
- 進め方は、一番工数を食っている1業務から小さく検証し、効果を確かめてから広げるのが基本
国土交通省はi-Construction 2.0で、2040年度までに建設現場の省人化3割（生産性1.5倍）という目標を掲げています。国を挙げた省人化の流れの中で、標準化できる業務は、今後も施策とSaaSの進化が効率化を進めていくでしょう。裏を返せば、協力会社ごとの帳票や自社の原価ルールのような「標準化できない業務」ほど、効率化の手段が自社に合わせた開発しかなく、その価値が相対的に上がっていくということです。
自社の業務がSaaSで済むのか、開発が効くのか。その切り分けの段階からで構いませんので、実際の帳票を前にした検証も含めて、お気軽にご相談ください。検討した結果「SaaSで十分」という結論になるなら、それも正しい切り分けです。
