株式会社DYNA ／ 2026年9月28日 公表
建設業は、担い手の減少と技能者の高齢化という構造的な変化の只中にあります。就業者数は平成9年のピーク685万人から令和7年には478万人へ、約3割減少しました。※5 年齢構成（令和6年）では55歳以上が36.6%、29歳以下が11.9%（全産業はそれぞれ32.8%、17.0%）であり、国土交通省は「高齢化が進行し、次世代への技術承継が大きな課題」と明記しています。※1
仮設工事の分野では、足場の割付、資材の積算、仮設構造物の強度計算といった業務が、長年にわたり一部の熟練者の経験と勘に依存してきました。図面を読み、必要な部材を数え、安全性を確かめる——この一連の判断は、文書になっていない知識の塊です。それを担ってきた世代が現場を離れるとき、会社に残るのは図面と資材だけで、判断の根拠は残りません。
生産性の水準も課題です。建設業の労働生産性は全産業の約7割、製造業の約6割に留まっています。※2 国土交通省は i-Construction 2.0 において、2040年度までに建設現場で3割の省人化（生産性1.5倍以上）を目指すことを掲げています。※3
この状況にありながら、建設業のデジタル化の取組は他業種に比べて進んでいません。中小企業庁の調査では、建設業は約5割の企業がデジタル化の初期段階（段階1〜2）に留まり、他業種に比べて取組が進展していないことが確認されています。※4 国土交通省も令和8年7月に「特に完成工事高の小さい中小事業者におけるICT化、業務効率化については取組が遅れている」と指摘しています。※5
なぜ進まないのか。当社の見方は明確です。
この3つ目が、最も根が深いと当社は考えています。中小企業庁の調査で、AIを活用していない理由の第1位が「活用する業務がイメージできていない」63.4%、第2位が「活用を推進する人材が不足している」40.0% であることは、この構造と一致します。※6 道具がないのではありません。何を仕組みにすべきかを、言葉にできていないことが障壁なのです。
当社はここに焦点を当てています。設計の軸は2つです。直感的であること。そして、今までのやり方を極力崩さないこと。そのうえで、時間がかかりすぎている業務を洗い出し、そこだけを置き換えます。全体を作り変えようとすれば、上の3つの壁に正面から当たって止まります。
外国人材の受け入れも急速に進んでいます。建設業の外国人労働者は206,468人（令和7年10月末時点）で、前年比+16.1%、全産業に占める構成比は8.0%です。※7 安全教育を日本語だけで完結させることが難しくなっています。
そして実際に取り組んでみてわかったことがあります。「わかっていないことが、わかっていない」状態は、国籍に関係なく起こるということです。安全の判断ができないのは日本語が読めないからだけではなく、経験がないからです。外国人技能者も日本人の新人も、同じ手当てを必要としています。
これは軽視できない問題です。令和7年の労働災害では、全産業の死亡者700人のうち建設業が214人——約3割を占めています。一方で休業4日以上の死傷者では建設業の比率は約1割です。※8 つまり建設業は、休業4日以上の死傷者に占める割合と比較して、死亡者に占める割合が高く、死亡災害の防止が特に重要な業種です。「伝えたつもり」で済ませられる領域ではありません。
当社は、「現場の判断をデータとして残し、次の世代が同じ水準の判断を再現できる会社」を目指します。熟練者の経験を代替するのではなく、その判断の過程をデータと計算根拠の形で見えるようにし、経験の浅い担当者が自ら考える手がかりを得られる状態をつくります。
その実現手段として、当社は汎用の業務パッケージを導入するのではなく、自社の業務に即したシステムを自社で設計・開発するという方法を選びました。仮設工事の判断は業界共通の規格と個別現場の条件が絡み合っており、外部の標準機能では割り切れません。現場特有の判断条件を仕様に反映しやすく、自社業務との適合性を高められると判断しています。
当社が扱う業務のデータをすべてつなぐという構想——現場が毎日書いている日報を台帳の中心に据え、そこから必要なものを取り出せば話が早い、という考え方——は、10年以上前から社内にありました。着想が足りなかったわけではありません。実現できなかった理由は2つあります。
ひとつは、日報を人の手で管理し続けることが単純に重かったことです。集約すれば強いとわかっていても、集めて整えて突き合わせる作業が人の作業量として成立しませんでした。
もうひとつは、より根本的な問題でした。外部の専門家に開発を依頼したこともありましたが、思うようなものにはなりませんでした。理由は専門家の技量ではありません。当社の側が、自分たちの業務の判断を言語化して渡すことができなかったからです。何をどう集計すべきか、どの数字が経営の判断に効くかは、請求書を作り現場を回してきた者の頭の中にはあります。しかしそれは文章になっていない知識でした。仕様書に書けないものは、他人には作れません。構想は構想のまま、10年以上置かれていました。
この状況を変えたのが、生成AIの登場と精度の向上です。効いたのは実装の速さだけではありませんでした。対話を重ねる中で、言葉になっていなかった自社の判断が言語化されていったことです。長年渡せなかったものを渡せるようになり、そこから実装までが一気につながりました。
当社にとってデジタル技術の進化とは、新しい道具が増えたという話ではありません。現場にあった構想を、現場を知る者自身の手で形にできるようになったという、担い手の変化です。
そして当社は、この経験をそのまま製品の思想にしています。自分が何をわかっていて何をわかっていないのかを、自分では言葉にできない——これは当社の経営者が実際に10年以上つまずいてきたことであり、同時に、経験の浅い現場監督が日々直面していることでもあります。当社のシステムが答えだけを出さず、計算の根拠を追える形で示し、問いかけとヒントを返す設計になっているのは、ここに理由があります。AIが当社に対してしてくれたことを、当社が現場に対してする——それが当社のDXの中身です。
当社は以下の3つの方向で情報処理技術を活用します。
当社は、鳶工事一式（足場・鉄骨・重量・鍛治）の請負を主たる事業としてきました。今後は、これに自社開発システムの外部提供を加えた二本柱へ転換します。
| 従来 | 今後 | |
|---|---|---|
| 事業の柱 | 鳶工事一式の請負 | ① 鳶工事一式の請負 ② 自社開発システムの外部提供 |
| 収益の源 | 施工の対価 | 施工の対価 ＋ ソフトウェア利用料 |
| 顧客 | 元請ゼネコン・専門工事業者 | 左記 ＋ 同業の仮設工事業者・仮設リース事業者 |
| 競争力の源泉 | 施工力・人員 | 施工力 ＋ 現場を知る者が設計した計算・積算の仕組み |
自社の業務で実際に使い、精度と使い勝手を確かめたシステムを外部に提供します。自社で使っていないものを売ることはしません。
当社は、業務ごとに個別のツールを導入するのではなく、同一の現場を軸にデータをつなぐことを設計の起点としています。現在、以下の6つのシステムを自社で開発しています。稼働状況は 稼働中 開発中 で示します。両方が付いているものは、実務で稼働しながら機能を拡張している状態です。実務検証中は、完成前の一部機能を社内の実務検討に使用している段階であり、製品としての供用完了とは区別していることを示します。
第一に、既存の業務様式を作り変えさせないことです。この業界向けの業務システムは、多くの場合「システムの仕様に合わせて仕事の手順を変える」ことを求めます。請求書の様式を変え、集計表を作り直し、現場に新しい入力を覚えさせる——当社はこれを採りませんでした。当社を含む多くの建設会社・現場では、様式は違っても日報が日常的に使われています。ならば新しい入力を覚えさせるのではなく、すでに書かれている日報をそのままデータとして扱えばよいと考えました。
第二に、わからないことを、わかったことにしないことです。データを扱う仕組みは、不明な値を便宜的に埋めたくなります。名前が一致しなければ似たものに寄せ、金額が不明なら0として扱う——そのほうが処理は通ります。しかし当社はこれを設計上禁止しています。不明は不明、ゼロはゼロとして区別する。推測で埋めた値は、本当に間違えたときに誰も気づけなくしてしまうからです。請求漏れや未入金を見つけることが目的の仕組みで、不明をゼロに潰してしまえば、見つけたいものが消えます。
第三に、使う人の理解を飛び越えて自動化しないことです。技術的には、もっと自動化できる部分が各システムに残っています。それでも当社は、使う人がその処理の意味を理解していない段階で自動化を進めません。理解されないまま動く仕組みは、結果が間違っていても誰も気づけず、何かあったときに誰も直せません。自動化の範囲は、使う人の理解が追いついた分だけ広げます。
この3つは、以下のすべてのシステムに共通する設計原則です。
扱うデータ：仮設構造物の寸法・荷重条件、鋼材の断面性能データベース、資材の規格データ、適用する労働安全衛生規則および業界基準。
活用方法：寸法と荷重の条件から部材ごとの安全性を検証し、不足があれば補強の取り方まで含めた計画案を提示します。計算結果は、適用した数式と数値を追跡できる計算書として出力します。
従来の計算書との違い：これまでの計算書が示していたのは、「計画した寸法・角度であれば成立する」ということだけでした。しかし現場では、納まりの都合で部材の取付角度や寸法が計画どおりにならないことがあります。そのとき、その状態が安全かどうかは確かめられていませんでした。PROTBは、計画値で成立するかだけでなく、現場で寸法や角度が変わった場合にも安全を確認できる形で計画を示します。
実現すること：従来は熟練者が個別に判断していた仮設構造物の安全性検証を、根拠が追跡できる形で標準化します。現場の実情に合わせて実現できる計画を、速く、根拠をもって指示し、施工時にも確認できるようにします。計算書が残ることで、なぜその構成にしたのかが後から検証可能になります。
現状：実務検証中・改良開発中。完成前の一部機能を社内の仮設計画の検討に使用しており、片持ち梁および単純梁の計画検討で活用実績があります。一方、製品としての供用完了とは区別しており、操作性・計算書出力・利用者拡大に向けた改良を継続しています。
この片持ち梁の事例には、当社が重視している効果がはっきり表れています。発注者から追加の要件が出てきたのは、当社が先に提案を示したからです。何もない状態では、発注者の側も何を要求すべきかを言葉にできません。具体的な案が目の前にあって初めて「ここはこうしたい」が出てきます。提案が、相手の言語化を助けた——これは当社が第1章に記した、当社自身が経験したことと同じ構造です。
改良中の点：現在は画面の見せ方と操作の流れが直感的でないため、事実上代表取締役しか使えません。第2章冒頭に掲げた「直感的であること」に達していないため、そこを改良しています。使える人が1人しかいない状態を、当社は稼働完了とは呼びません。
扱うデータ：建築図面から取得した建物の形状と寸法、足場部材の規格別データベース。
活用方法：建築図面から建物の躯体をデジタル化し、3Dで立ち上げたうえで足場の割付を計算し、資材の拾い出し表、平面図・立面図、3Dモデルを出力します。図面の種類に応じて読み取り方を使い分けており、電子データとして作成された図面はデータから直接寸法を読み取ります。
機械に読めないものを、読めたことにしない：手書きの図面や、何度も複写を重ねた図面は、現在の画像解析では正確に読み取ることができません。こうした図面は、縮尺を合わせたうえで人が図面から躯体をなぞってデジタルにつなぎ、3D化しています。読み取れない部分を推測で埋めて自動化したように見せるより、人が確かめた形でデータにするほうが、その後の割付と積算を信頼できるからです。第2章冒頭の第二の方針を、図面の読み取りに適用したものです。
実現すること：図面から積算までの工程を連続処理にします。人が数える工程を減らすことで、所要時間の短縮と数え落としの防止を同時に実現します。
拡張中の点：汎用性の高い範囲から先に実務の運用に回しています。出現頻度の低い複雑な形状の躯体に対する割付の対応は、順次拡張しています。
扱うデータ：施工中や日々の気づき・改善点の投稿と、それに対するAIのフィードバック、現場ごとのトークルームのやり取り、終了した現場の記録。
活用方法：広く使われているSNSの機能のうち、社内に必要なものを実装した総合的な社内SNSです。社員は施工中や日々の気づき、改善点を自分の言葉で投稿し、それに対してAIがフィードバックを返します。
実現すること：現場で得た気づきを、その人の中だけで終わらせず、言葉にして残し、次にその経験を必要とする人へ渡します。
次の段階（日報報告機能：実装済み・運用開始前）：日報報告の機能を実装しており、今後はこれを日報のデータベースへ直結させます。報告の誤りを防ぐため、日報を他の記録と突き合わせて食い違いを検知し、差し戻す仕組みとし、判断のつかない部分はシステムの側から人に確認を求めます。この機能はまだ運用していません。運用前の確認が済んだ範囲から、順次運用を開始します。
扱うデータ：ヒヤリハット、進捗状況、改善提案、災害・事故の報告とその防止策。報告の紐づけ先となる顧客・現場・業態（統合管理の台帳と総日報から作成）。社内の作業マニュアル。
解決する課題：ヒヤリハットや改善提案は、これまでも現場で報告されてきました。しかし報告書がデータになっていなかったため、書かれた経験を会社として活用できていませんでした。一人が危ない目に遭って得た教訓が、その人の中で止まっていたのです。
活用方法：報告はチャット形式で行います。報告者はシステムからの短い質問に答えるだけで、その内容をAIが報告として言葉にまとめます。さらに、その報告がどのような効果を持つかをフィードバックとして返し、社内で共有します。
改善提案やヒヤリハット、災害・事故報告から出た防止策は、3名の責任者が合議のうえで社内ルールとして採用し、採用されたものは作業マニュアルに反映して全員に共有します。ルール化するのは、汎用性があるもの、効果がすぐに出るもの、緊急性の高いものに限ります。一過性のものや特殊な条件でしか起きないものまでルールにすると、ルールそのものが複雑になりすぎて守られなくなるからです。採否の判断は機械に任せず、人が行います。
報告の紐づけ先となる顧客・現場・業態は、統合管理の台帳と総日報を読み取り専用で解析して作った正式な一覧から選びます。元のファイルは一切書き換えません。照合は完全一致のみとし、名前が一致しない場合に推測で補正することを設計上禁止しています。一致しなかったものは黙って直すのではなく「一致しなかった」として記録し、人が判断します。報告の版も、確定したものを上書きせず、訂正は新しい版として残します。既存の日報の保存・承認処理には手を入れず、別の領域に分離しています。
実現すること：一人の経験を、全員の経験にします。10人が報告すれば、10人分の経験と知恵が社員一人ひとりに積み上がります。報告が作業マニュアルの更新につながることで、書いた人にとっても報告が「出して終わり」ではなくなります。
現状：開発中。報告画面の基本部分（正式な一覧に基づく顧客・現場・業態の選択と、下書きの保存）まで実装しており、本番環境には未反映です。AIとの対話による報告、フィードバック、社内共有、作業マニュアルへの反映は次の段階で実装します。
扱うデータ：現場語彙・専門用語の辞書（日本語表記・ふりがな・カテゴリー・建設タグ）、日々の出題と回答、受講記録、連続学習日数、未提出状況、紙ベース確認テストの合否記録。
本システムは「日本語学習」と「安全トレーニング（安全作業教育）」の2つで構成されます。対象は技能実習生・外国人作業員（ネパール・モンゴル）11名と、日本人の新人作業員4名の計15名です。従業員33名の当社において、新しく現場に入る層のほぼ全員が本システムで学んでいます。
外国人向けの仕組みとして作り始めましたが、運用してみると日本人の新人にも同じ必要があることがわかりました。安全の判断ができないのは日本語が読めないからだけではなく、経験がないからです。「何をわかっていないのかがわからない」状態は、国籍に関係なく起こります。そのため現在は新人全体の教育基盤として運用しています。
日本語学習：対象者がスマートフォン（PWA）から毎日10分・25問のテストを受けます。出題構成は、語彙・漢字7問、文法・表現5問、現場指示理解6問、安全判断4問、当社の考え方2問、実技振り返り1問（自由記述）です。
安全トレーニング：安全作業に関する教育を、技能実習生でも読めるよう全体にかな振り（ふりがな）を付けて提供します。ここに当社の考え方があります。安全は、日本語が読めるようになるまで待てません。本人に「日本語を習得してから安全を学べ」と求めるのではなく、教材の側を読める形にする——これが当社の採った方法です。
出題は、管理画面に登録した当社の現場語彙・専門用語の辞書を根拠に生成します。根拠となる資料のない自由生成は禁止しています。自由記述への助言は、間違いを責めない前提（No-Blame）で行い、元の内容を尊重したやさしい日本語の例文を返します。日本語入力を推奨しつつ、ネパール語・モンゴル語での入力も認めています。
習熟度の段階（N5→N4→N3）は、日々の蓄積点が目安に達した時点で紙ベースの確認テストを実施し、責任者が合否を記録します。合格しても自動では昇格しません——管理者が確認したうえで段階を変更します。機械の採点だけで「わかった」と判定しないためです。
安全施工に関する理解度テストも別途運用しています。ただしこれは社内教育・理解度確認のためのものであり、法定の特別教育・技能講習・免許・作業主任者教育の代替ではありません。現場では職長・元請・法令・メーカー取扱説明書に従うことを前提としています。
実現すること：「伝えたつもり」で終わらせず、理解されたことを記録として確認できる安全教育に変えます。未提出者を日次で把握できるため、教育が行き届いていない人を放置しません。
扱うデータ：総日報から抽出した日々の施工実績、見積書・契約書、契約台帳、請求台帳、銀行取引明細、カード明細。
目的：工事ごとの施工と日々原価を起点として、見積漏れ・請求漏れ・未入金・未払を見つけ、原価と売上を一貫して管理することです。人が行っていた転記・検索・採番・集計を減らし、人は発生した事実の入力、資料の保存、業務判断、承認、確認に集中できる状態を目指します。
この仕組みが生まれた経緯：事務担当者に「いま何が一番大変か」を尋ねたことが発端でした。答えは、統合管理システムへ請求と入出金を入力する作業そのもの、そして請求書の作成と管理でした。
そこで判断したことがあります。定型ルールに基づく転記・照合・差異検知は、システム化することでヒューマンエラーを抑えられるということです。人が途中に入るほど転記の誤りと見落としが生まれます。ならば機械的な作業は中途半端に分担せず全部システムに任せ、人は判断と承認だけを担うべきだと考えました。この構想をAIと対話しながら設計し、実装もAIとの協働で行いました。開発期間は1週間です。
現在稼働している部分（2026年7月から運用中）：
結果として、経理業務のうち最も時間のかかる請求書の作成が、日報を書くことの延長線上で片付く状態になっています。請求のために現場名や工事内容を改めて調べ直し、転記する作業がなくなりました。
拡張として開発している部分：
次の段階：現在は総日報を人が入力していますが、これをやめ、各自が書く自社日報を入口にして、そこから総日報を機械が組み立てる形に変えます。人が同じ内容を二度書く工程を無くすためです。
最終段階：共有スプレッドシート上の行動予定と、DynaSocialに投稿される自社日報を連携させ、予定から実績、原価、売上、請求、入出金までをデータだけで流す状態を目指します。
この拡張では、設計上の禁止事項を先に明確にしています。金額が不明なときに推測で按分しない。原資料との集計差を端数の配分で隠さない。支払先の請求書を受け取っただけで支払済みとしない。同じ日・同じ金額でも別の取引を潰さない。元のPDFは改名・上書き・削除せず、同一であることを照合したうえで管理用の控えを作る。銀行への実際の送金機能は持ちません。
また「リアルタイム」という言葉を、取り込まれた最新の資料までの状態という意味に限定しています。まだ保存・取込されていない活動を把握済みとして扱わず、最終取込時点と未処理の件数を必ず表示します。
完成の目標時期と、その考え方：拡張部分の完成目標は2027年3月頃（本稿から約半年後）です。技術的にはもっと早く自動化できますが、意図してこの期間を置いています。ほぼ完全な自動化に進む前に、実際に使う担当者が使い込み、処理の意味を理解し、使いにくい点を指摘する期間が必要だと考えているからです。
開発した本人は使い方がわかります。しかし当社が目指すのは、この仕組みを何も知らない人が、説明を読まずに直感的に使える状態です。そこへ到達するには、開発者の想定ではなく実際の使用者の手触りを反映させる工程が要ります。半年という期間はそのために確保したものです。
その検証を、いま実地で行っています。入社直後で、当社システムに関する事前知識を持たない事務担当者に、実際の業務で使用してもらい、説明書に依存せず扱えるかを検証しています。現在は自社日報を総日報へ手で入力してもらい、その作業を通じて両者の関係を理解してもらう段階です。開発者ではなく、初めて使う利用者を基準に画面設計を評価する——これが当社の方針です。
当社のDXには、はっきりした出発点があります。決算期をまたぐ現場です。そして、それを解ける状態になったきっかけは生成AIの登場でした。
工事は決算期の区切りに合わせて終わってくれません。期をまたぐ現場があると、その工事の原価と売上を一貫して追うことができず、どの現場で利益が出ていて、どこに請求の漏れがあるのかが見えなくなります。表計算ソフトで個別に管理していては追いつかない——この問題に直面したことが、すべての起点でした。
解き方の構想は、以前から社内にありました。総日報——現場が毎日書いている日報を台帳の中心に据えるという考え方です。しかしそれを形にするには、表計算ソフトを高度に扱えて、なおかつ自社の業務で何を集計すべきかを理解している人間が必要でした。当社にその両方を兼ねた人材はおらず、構想は構想のまま置かれていました。
この状況を変えたのが生成AIです。業務を理解している者が仕様を語り、AIが実装する——この分業が成立したことで、2024年11月、当社は自社で統合管理システム（顧客マスタ・契約・正式現場の台帳）稼働中と集計システム（顧客別の管理表と全社集計）稼働中を構築し、運用を開始しました。以来、現在まで実務の正本として使い続けています。
| システム | 担っているもの |
|---|---|
| 統合管理システム （DYNA統合管理システム） | 顧客マスタ、契約入力、正式現場の台帳を一元管理する当社の基幹台帳。現在は第5版、VBAモジュール74本の規模。銀行明細CSV・カード明細CSV／PDFの取込と金融マスタの管理も担う。パスをコードに書かず設定ファイルで一元管理し、検証環境と本番環境を切り替えられる構成としている |
| 集計システム （顧客及び現場管理表／全社集計管理表） | 顧客ごとに管理表を持ち（約50社分）、それを全社集計管理表へ集約する仕組み。集計対象は顧客別売上に加えて現場別原価と出面であり、当社にとってはこの2つが核心である。どの現場で利益が出ているか、労務がどこに投入されているかは、この2つを現場単位で押さえないと見えない |
この2つで固めた業務の型とデータ構造が、そのまま経理自動管理および報告書DXの土台になっています。報告書DXがいま読み取っている統合管理の台帳は、2024年11月から使い続けているものです。経理自動管理が扱う銀行明細・カード明細の取込も、統合管理システムで先に仕組みを作り上げたものを引き継いでいます。
そして2024年11月から約2年で、統合管理システムは第5版・VBAモジュール74本、顧客管理表は約50社分に達し、その上に本章の6つのシステムを重ねてきました。速く進めた理由は2つあると考えています。
ひとつは、作り変えなかったことです。既存の様式を残したまま、その裏側にデータの流れを通していく方法を採ったため、現場に新しい入力を覚えさせる工程が要らず、そのぶんを開発に回せました。
もうひとつは、構想が現場の側にあったことです。何を集計すべきか、どの数字が経営の判断に効くかは、請求書を作り、現場を回してきた者にしかわかりません。その理解が先にあったため、実装に迷いがありませんでした。
つまり当社のDXは、新しい仕組みに乗り換えた話ではありません。長年かけて自社で作り上げた業務の型を、そのままデータベースに載せ替えてきた積み上げの結果です。作り変えなかったからこそ、現場に新しい負担を課さずに移行できました。
これら6つは独立したツールの集まりではありません。現場を共通の軸として、次のようにつながることを目標としています。
以下は当社が目標としているデータ連携の全体像です。2026年9月時点では、総日報から月次請求書を作成し統合管理へ集計する連携など一部が稼働しており、その他は手作業による受け渡しまたは開発中です。各機能の現在の稼働状態は、前項の各システム説明に記載しています。
DXの推進は代表取締役の直轄としています。当社は専任の情報システム部門を持たず、システムの要件定義・設計・開発判断を代表取締役自身が担っています。経営判断とシステム設計が同一人の手にあることを、意思決定の速さという長所として活かす体制です。
実装工程には複数のAIエージェントを常時参加させる協働体制を採っています。実装を担当するエージェント、レビューを担当するエージェント、方針整理を担当するエージェントの役割を分け、以下の3つの文書によって変更管理を行っています。
| 文書 | 役割 |
|---|---|
ROADMAP.md | 到達すべき状態と達成条件を定義する。変更は代表取締役の決裁を要する |
STATUS.md | 進行中の作業、担当、状態、レビュー結果、完了ログを記録する |
DECISIONS.md | 設計上の意思決定とその理由を、識別番号を付して記録する |
この体制の効果は開発期間に現れています。経理自動管理の中核（総日報から月次請求書を作成し統合管理へ集計させる機能）は、構想から実装完了までおよそ1週間でした。業務を理解している者が仕様を語り、AIが実装を担い、レビューを別のエージェントが行う——この分担が成立したことによるものです。
実装の着手前に作業計画を提示し、代表取締役の承認を得てから着手する手順を定めています。レビューで重大な指摘が出た場合は実装者に差し戻し、修正後に再レビューを行います。自動テストを整備し、変更のたびに全件を実行して既存機能への影響を検証しています。
この項目について、当社の方針は一般的なDX人材育成とは前提が違います。最初に明記します。
当社は「使いこなせる人を増やす」ことを目指していません。「使いこなす必要のない仕組みにする」ことを目指しています。
習得を前提にした仕組みは、習得した人がいなくなれば止まります。操作を覚えた人に依存する状態は、熟練者に依存していた従来と構造が同じです。だから当社は、教育で埋めるべき差を、まず設計で消しに行きます。第2章に掲げた設計方針——直感的であること、既存のやり方を崩さないこと、使う人の理解を飛び越えないこと——はこのための原則です。実際に、経理自動管理は入社直後で当社システムに関する事前知識を持たない事務担当者に実際の業務で使用してもらい、説明書に依存せず扱えるかを検証しています（第2章(6)参照）。初めて使う利用者を基準に設計を評価することで、教育で埋める必要のある差そのものを減らします。
ただし、操作教育を減らす設計と、人材育成を不要にすることは同義ではありません。次項のとおり、仕組みを理解し説明できる人材の育成は別に進めます。
一方で、専門的な判断の担い手——つまり教える側——は必要です。ここについて当社は2つの手を打ちます。
これは代表取締役自身が経験した順序でもあります。当社の6つのシステムは、外部から専門人材を採用して作ったものではなく、業務を理解している者がAIとの対話を通じて仕様を言語化し、実装を進めて作りました（第1章参照）。同じ方法を、代表取締役1人から社内へ広げていく——それが当社のデジタル人材確保の中身です。
現在の最大のリスクは明確です。この取り組みが代表取締役に集中していることです。上記2つは、その集中を解くための手当てです。
前章のDX戦略を動かすための技術基盤として、以下を整備しています。
当社の基幹台帳（統合管理システム・集計システム）は、表計算ソフトのマクロとして社内のファイルサーバー上で本番運用しています。長年の実務に耐えてきた資産であり、これを一斉に置き換えることはしません。設定ファイルによってパスを一元管理し、検証環境と本番環境を切り替えられる構成にしてあるため、段階的な移行が可能な状態を保っています。
新しく開発するシステムは、クラウド基盤の上に構築しています。この2つを併存させ、業務を止めずに順次移していくのが当社の整備方針です。
新規開発分については自社でサーバーを保有せず、クラウドサービス上にシステムを構築しています。データベース、認証、サーバーレス実行環境、ファイル保管をクラウドのマネージドサービスで構成し、保守負担と障害リスクを抑えています。現場からの利用を前提に、スマートフォンのブラウザで動作する形式を採用しています。
全システムのソースコードをバージョン管理システムで管理し、変更の履歴、レビューの記録、課題の管理を一元化しています。誰がいつ何を変えたかを遡れる状態を保っています。
仮設構造物の強度計算と足場の割付は、誤りが現場の安全に直結します。そのため計算ロジックには自動テストを整備し、変更のたびに全件を実行して、既存の挙動が壊れていないことを確認したうえでなければ本番環境へ反映しない運用としています。
たとえばASHIBA-AIでは、2026年9月時点で自動テスト2,968件を整備し、変更のたびに全件を実行しています。
システムごとにデータを閉じ込めず、現場を共通の識別子として相互に参照できる構造を採っています。将来的には、BIM／CADデータとの連携、および取引先システムとのデータ授受にも対応できる設計方針としています。
当社のDX戦略は「熟練者に依存していた判断をデータと計算に置き換え、少ない人数でより大きな付加価値を生む」ことを目的としています。したがって主指標には、その結果が集約して現れる従業員一人当たりの付加価値額を置きます。
付加価値額は「営業利益＋人件費＋減価償却費」で算出します。
| 付加価値額 | 従業員数 | 一人当たり付加価値額 | |
|---|---|---|---|
| 令和6年7月期（実績） | 167,776,304円 | 30名 | 5,592,543円 |
| 令和7年7月期（実績） | 191,462,010円 | 33名 | 5,801,879円（前期比 +3.7%） |
| 令和10年7月期（最低到達水準） | — | — | 6,325,000円以上（令和7年7月期比 +9%以上） |
| 令和10年7月期（目標水準） | — | — | 7,543,000円以上（令和7年7月期比 +30%以上） |
当社はこの指標に最低到達水準と目標水準を分けて置いています。当社はDX戦略上の最低到達水準として、一人当たり付加価値額を令和7年7月期比で9%以上向上させる水準を設定しています。+30%は当社が実際に狙っている水準です。なお、経営革新計画における基準年度および目標値については、申請時の直近期末に基づき別途確定します。
+30%の目標は、次の3つの経路で達成度を管理します。
各経路を補助指標に分解し、決算期ごとに実績を検証します。単一の施策に依存した目標ではありません。
主指標を動かす直接の手段がこれです。仮設工事の請負では、一人が一日現場に出て生む施工高が収益構造の基礎になります。当社は現在、材料費と経費を含めて一人一日あたり5万円を見積の基準としており、これを6.7万円（+34%）まで引き上げることを目標とします。
ここで誤解のないように申し上げます。単価を上げることは、発注者に高く売ることではありません。
仮設計画と強度計算に時間がかかるほど、現場では待機や手戻りが生じ、その工事に必要な人工は増えがちです。計画が早く正確に固まれば、同じ工事をより少ない人工で仕上げられる余地が生まれます。当社は、同一仕様・同一施工範囲の工事について必要人工を30%削減することを目標としています（例：10人工を要していた工事を7人工で）。
両方を達成した場合、単価が34%上がり、人工が30%減るため、発注者の工事総額は現状比で約6%低減します（1.34 × 0.70 ＝ 0.938）。単価だけを見れば高く、総額で見れば安い——これが当社の狙う構造です。
なお、人工30%削減は現時点では目標値です。施工条件を揃えた現場ごとの実績値を継続して測定し、検証します。目標は目標として示し、実績が出た時点で実績に置き換えます。
そしてもう一つ、金額に表れない効果があります。発注者側の監督者の負担です。計画の往復が減れば、発注者の監督者が確認・調整に費やす時間も減ります。仮に人工が同じ10人工だったとしても、この監督者の負担軽減そのものが当社の提供価値です。
| 指標 | 現状 | 目標 |
|---|---|---|
| 一人一日当たり施工高 （材料費・経費を含む見積単価） | 5万円 （現在の見積基準。実際の金額は現場により幅があります） | 6.7万円 （+34%） |
| 仮設計画の確定までに要する期間 | 社外との複数回の往復で数日以上 | 1〜2日 |
| 同一仕様・同一施工範囲の工事に要する人工 | 現場ごとに測定を開始 | 3割削減（目標値） （例：10人工 → 7人工） |
| 発注者の工事総額 | — | 約6%低減（上記2つを達成した場合） （単価+34% × 人工▲30%） |
計画期間の短縮と、現場人工の削減は別の指標として測ります。前者は計画・調整の工程、後者は現場施工の工程です。前者が後者を生むという因果は、現場ごとの実績で確かめていきます。
なぜ計画期間を短縮できるのか。仮設計画と強度計算は、従来は社外の専門家に依頼し、条件のやり取りを何度も重ねて仕上げるものでした。複数回の往復に日数を要し、そのあいだ現場は動けません。
PROTBとASHIBA-AIが稼働すれば、この工程が変わります。条件入力と一次案の作成を標準化することで、専門的な計算操作そのものに習熟していない担当者でも、計画検討の入口まで進められる状態を目指します。従来は複数回の往復で日数を要していたものが、1〜2日で一次案と計算根拠が揃う見込みです。
ただし、システムは専門的判断そのものを代替するものではありません。生成された案は計算根拠を確認し、最終的な採用判断は社内責任者および必要に応じ外部専門家が行います。
これは当社の工数削減にとどまりません。お客様の待ち時間も同じだけ短くなり、プロジェクトに関わる時間と人員を双方で削減できます。
当社は前章のとおり、名前の照合において推測による補正を行わないという設計方針を採っています。この設計方針のもとでも、実際の業務データを正しく照合できることを確認するため、以下を指標とします。報告書DXで報告の紐づけ先となる顧客・現場・業態の一覧を作る処理について、2026年5月分の総日報を用いた受入検証において、総日報と正式マスターの組合せ43組中43組が完全一致し、未登録候補は0組でした。
| 指標 | 対象システム | 実測値（2026年5月分の総日報による受入検証） | 目標 |
|---|---|---|---|
| 総日報と正式マスターの完全一致率 | 報告書DX | 43組／43組（100%） | 100%を維持 |
| 未登録候補（マスターに一致しなかった組）の件数 | 報告書DX | 0組 | 0組を維持 |
推測で名前を直せば一致率は容易に上がりますが、本当に間違えたときに誰も気づけなくなります。当社は補正を行わないまま、この水準を維持することを目標とします。
参考として、上記の判定が対象としている台帳とデータの規模を示します。
| 項目 | 実測値 | 対象期間 |
|---|---|---|
| 登録顧客数 | 115件 | 台帳の累計（2026年8月10日時点） |
| 登録契約数 | 196件 | 台帳の累計（同上） |
| 登録正式現場数 | 168件 | 台帳の累計（同上） |
| 総日報の作業員入力行数 | 740行 | 1か月分（2026年5月） |
主指標に至る過程を測るため、以下の業務時間を測定します。いずれも令和8年度中に測定基盤を整備し、基準値を確定させます。
| 指標 | 対象システム | 基準値 | 目標 |
|---|---|---|---|
| 足場積算の1現場あたり所要時間 | ASHIBA-AI | 測定準備中 | 基準値の50%以下 |
| 仮設構造物 強度計算書の1件あたり作成時間 | PROTB | 測定準備中 | 基準値の50%以下 |
| 日報の集計・転記に要する月間工数 | DynaSocial（日報報告機能の運用開始後） | 測定準備中 | 実質ゼロ |
| 構想から実装完了までの期間（新機能あたり） | 全システム共通 | 実績例：1週間（経理自動管理の中核機能） 基準値：今後3件以上の新機能開発実績の中央値で算定 | 管理上限：2週間以内 |
| 月次請求書の作成に要する工数 | 経理自動管理 | 測定準備中 （機能は稼働済み。人は請求額の指示と承認のみ） | 基準値の50%以下 |
| 月次収支を把握できるまでの日数 | 経理自動管理 | 測定準備中 | 翌月10営業日以内 |
| 安全教育の受講完了率（日次） | DYNA日本語安全トレーニング | 測定可能 （未提出者の日次把握とCSV出力が稼働中） | 対象者の100% |
各指標は年1回、決算期（7月期）にあわせて実績を確認し、目標との差を検証したうえでDX戦略および指標そのものを見直します。
足場の現場から仕事を始めました。図面を読み、部材を数え、組んで、それで合っているかを確かめる——その判断のほとんどを、誰にも教わらないまま身体で覚えました。覚えたことは自分の力になりましたが、会社の力にはなっていませんでした。私が現場を離れれば、その判断はどこにも残らないからです。
答えは、ずっと前から見えていました。日報です。現場の人間は毎日日報を書いています。誰が、どの現場で、何をしたか。会社が知りたいことは全部そこに書かれている。これを台帳の中心に据えて、必要なものをそこから取り出せば話が早い。私はそれを「総日報」と呼んで、構想として持っていました。
10年以上、作れませんでした。
理由は2つあります。ひとつは、日報を人の手で集めて整えて突き合わせる作業が、単純に重すぎたことです。集約すれば強いとわかっていても、その管理が人の作業量として成立しませんでした。
もうひとつは、いま振り返ればこちらが本質でした。外部の専門家に開発を依頼したこともあります。しかし、思うようなものにはなりませんでした。相手の技量の問題ではありません。私の側が、自分の頭の中にあるものを言葉にして渡せなかったのです。何をどう集計すべきか、どの数字が判断に効くのか——それは請求書を作り、現場を回してきた自分の中には確かにありました。けれどもそれは文章になっていない知識でした。仕様書に書けないものは、他人には作れません。私は自分が何をわかっているのかを、自分で説明できなかったのです。
状況が変わったのは、生成AIが実用に届いたときです。速く書けるようになったから、という話ではありません。AIと対話を重ねるうちに、言葉になっていなかった自分の判断が、言葉になっていったのです。10年渡せなかったものが渡せるようになり、そこから実装までが一気につながりました。
そこからは速かった。2024年11月、決算期をまたぐ現場の原価が追えないという目の前の困りごとを入口に、顧客と契約と現場の台帳、そして顧客別・現場別の原価と出面の集計を作りました。そこから約2年で、仮設構造物の強度計算、図面からの足場割付と積算、日報と社内共有、作業報告、経理、新人への日本語と安全の教育——6つのシステムが積み上がりました。
作るときに決めたことが3つあります。
ひとつ。相手のやり方を変えさせない。業務システムはたいてい「このシステムの通りに仕事を変えてください」と言ってきます。請求書の様式を変え、集計表を作り直し、現場に新しい入力を覚えさせる。うちではそれが通りませんでした。だから逆にしました。日報の様式は会社ごとに違いますが、日報を書く習慣は、ほとんどの会社にあります。すでに書かれているものをそのままデータにすれば、請求書のテンプレートを一枚も作り直さなくていい。作り変えなかったから速かったのだと思っています。
ふたつ。わからないことを、わかったことにしない。作っている途中、表計算ソフトから現場名を読み出したら「現場A」が「現場Aゲンバエー」になっていました。ふりがなの注釈まで一緒に読んでいたのです。このとき手っ取り早い直し方が2つありました。カタカナを機械的に削る。似た名前に寄せて勝手に直す。私はどちらも採らず、読み取り方そのものを直しました。推測で埋め始めた瞬間に、本当に間違えたときに誰も気づけなくなるからです。金額も同じで、不明は不明、ゼロはゼロとして分けています。請求漏れを見つけるための仕組みで不明をゼロに潰したら、見つけたいものが消えます。
みっつ。使う人の理解を飛び越えて自動化しない。経理の仕組みを作ったきっかけは、事務の担当者に「いま何が一番大変か」と聞いたことでした。答えは、請求と入出金の入力そのものと、請求書の作成でした。決まった手順の転記や照合、差異の検知は、人より機械のほうがミスを抑えられます。だから機械的な作業は中途半端に分担せず全部任せ、人は判断と承認だけを担う形にしました。開発は1週間でした。ただし完全な自動化には、あと半年かけます。いま、入社したばかりで、パソコンを使う業務に長く携わってきたわけではない事務の担当者に、これを扱えるか確かめてもらっているところです。その人が説明書なしで使える設計でなければ、私の目標には届いていません。
そして、いちばん大事なことを最後に書きます。
私が10年つまずいたのは、自分が何をわかっているのかを自分で言葉にできなかったことでした。同じことが、いまの現場で起きています。経験の浅い監督は、自分が何をわかっていないのかがわかりません。だから質問もできません。
だから当社のシステムは、答えだけを出しません。計算結果をぽんと画面に出すのではなく、どの数式に、どの数値を入れて、なぜその結論になったのかを全部追えるようにしています。答えだけを見せれば、現場の人間は考えるのをやめます。それでは技術は次に渡りません。作りたいのは熟練者の代わりではなく、その人が自分で気づくための手がかりです。
AIが私にしてくれたことを、当社が現場に対してする。それが私たちのDXの中身です。
まだ足りていないことがあります。この取り組みが私一人に集中していること——これが当社の最大の弱点です。ここから先は、社内に担い手を育てることが私の仕事になります。
自社で使い、精度を確かめたものしか外には出しません。自分たちが使っていないものを売ることはしない。それが、現場から始めた会社としての最低限の筋だと考えています。
現場の判断を、次の世代が再現できる形で残す。そのために、DXを経営の中心に置いて進めてまいります。
2026年9月28日
株式会社DYNA
代表取締役 佐藤 陽童
株式会社DYNA（以下「当社」）は、お客様および取引先からお預かりした情報、ならびに当社が保有する情報を重要な資産と認識し、これを適切に保護することが社会的責務であると考えます。当社は、自社開発システムを外部に提供する事業者としての責任も踏まえ、以下の方針に基づき情報セキュリティに取り組みます。
制定日：2026年9月28日
株式会社DYNA 代表取締役 佐藤 陽童
株式会社DYNA ホームページへ戻る