JAPAN BUILD OSAKA 2026で見えた建設DXの現在地

建設DX

2026年8月27日、インテックス大阪で開催された「JAPAN BUILD OSAKA 2026」を訪問しました。

今回の目的は、個別製品を比較して導入先を決めることではありません。

建設DXの現場で、

  • 建設実務の知識がどのようにシステム開発へ取り込まれているのか
  • 建設実務とITの両方を理解する人材は実際に必要とされているのか
  • 建設コンサルやインフラ維持管理の実務と、現在の建設DX市場にどの程度接点があるのか

を、出展企業との会話から確認することが主な目的でした。

実際に複数のブースを回ってみると、「建設DX」という言葉の広さと、その中で現在製品化が進んでいる領域の偏りが見えてきました。

会場で目立ったのは施工現場向けDX

今回、私が接触した範囲で特に多かったのは、ゼネコンや施工会社の現場を対象にしたサービスです。

施工管理、安全管理、KY、作業間調整、現場帳票、写真管理、図面管理、BIM/CIM、タブレットやスマートフォンからの入力、クラウド共有、AIを利用した書類作成などが多く見られました。

建設RXコンソーシアム関連のセミナーでも、施工現場で利用する安全支援アプリの実証が紹介されており、展示会全体としても「現場監督や施工現場の生産性向上」が大きなテーマの一つだったように感じます。

一方で、私が普段携わっている橋梁点検、維持管理、設計成果、発注者との協議、自治体独自様式、成果品照査といった建設コンサル側の業務を、そのまま主対象にした展示は多くありませんでした。

ただし、これは「建設DX市場には施工会社向けしか存在しない」という意味ではありません。

今回はあくまで一つの展示会で、私が実際に話を聞けた企業という限られたサンプルです。

インフラ点検を扱う企業もあり、建設コンサルや設計会社を顧客に持つDX企業も存在します。

今回の訪問で分かったのは、「建設DX」という言葉だけでは対象業務を判断できない、ということでした。

「建設が分かる人」がシステム開発に必要になる

複数の企業で特に興味深かったのが、建設実務の知識をシステム開発へどう取り込んでいるかという点です。

話を聞くと、その方法は企業によって異なっていました。

現場経験者自身が開発へ参加する企業もあれば、エンジニアが顧客へ直接ヒアリングする企業、建設実務経験者を採用する企業、元ゼネコン社員などの外部専門家を活用する企業もありました。

方法は違いますが、共通しているのは、

建設業務の内容を理解しないまま、ITだけでシステムを作るのは難しい

ということです。

建設会社の担当者が話す業務上の要求を、そのままプログラムへ変換できるわけではありません。

その要求が、

「なぜ必要なのか」

「どの工程で使われるのか」

「変更すると他の帳票やデータへ何が波及するのか」

「どこまでをシステムで決めてよく、どこから人間の技術判断として残すべきなのか」

まで整理されて初めて、実装可能な仕様になります。

この間をつなぐ工程は、建設DXではかなり重要なのだと感じました。

建設×IT人材といっても中身は一つではない

一方で、今回もう一つ感じたのが、「建設が分かるIT人材」という言葉そのものの曖昧さです。

建設業には、建築、土木、ゼネコン、地方建設会社、施工管理、設計、建設コンサル、維持管理、点検など、かなり異なる業務があります。

施工現場の安全管理を理解するために必要な知識と、橋梁点検調書の意味を理解するために必要な知識は同じではありません。

今回話を聞いた範囲では、「建設業」「建設DX」という大きな括りで説明されることも多く、具体的にどの建設実務を理解する人材が必要なのかまでは、企業によってかなり差があるように見えました。

これは建設DX市場が広がるにつれて、今後より細分化されていく部分なのかもしれません。

建設コンサル側にもDXとの接点はある

今回の展示会では施工会社向けサービスが目立ちましたが、建設コンサルの実務とDXに接点がないわけではありません。

むしろ、維持管理や点検の世界には、IT側から見ると説明しにくい独特の業務構造が数多くあります。

例えば、同じ橋梁点検でも、現場で取得した情報だけで業務が終了するわけではありません。

過年度成果との比較、写真番号、損傷番号、評価、コメント、一覧表、損傷図、自治体ごとの様式など、最終成果まで複数の情報が関連します。

さらに発注者協議などで一つの評価が変更されれば、関連する成果を複数箇所修正しなければならないこともあります。

こうした「実務上は当たり前だが、外から見ると分かりにくいルール」をシステム仕様へ翻訳する部分は、建設コンサル経験者がDXへ関与できる領域の一つだと考えています。

DXでは技術だけでなく「業務の翻訳」が必要になる

今回のJAPAN BUILD OSAKAを回って、改めて感じたのは、建設DXは単純な「建設+プログラミング」ではないということです。

現場や設計側の人間には、長年の業務経験から当たり前になっていることがあります。

一方、システム開発側には、データ構造、Webアプリ、クラウド、データベースなどの別の専門知識があります。

問題は、この二つの専門領域の間です。

建設実務者の言葉をそのままIT用語へ置き換えるだけではなく、業務の意味を整理し、システムとして扱える条件へ変換する必要があります。

維持DXでもこれまで、Excel帳票や橋梁点検成果を題材に、帳票構造の整理、セルマッピング、統合マスタ化などを試してきました。

今回の展示会は、こうした「実務を構造化してIT側へ渡す」という考え方が、建設DXのより広い領域でも重要になる可能性を確認する機会になりました。

展示会は製品を見るだけでは分からないことが多い

なお、今回の内容は各社の公式見解や詳細な技術調査ではありません。

ブースで対応いただいた方の多くは営業担当者であり、短時間の会話をもとにした観測です。

そのため、個別企業の開発体制や技術力を評価するものではありません。

それでも、Webサイトや製品資料を読むだけでは分からないことを、直接質問できたのは大きな収穫でした。

「誰が現場の業務を理解しているのか」

「顧客の要求を誰が整理するのか」

「建設知識が足りない場合、どのように補っているのか」

こうした問いは、完成した製品画面だけを見ていてもなかなか分かりません。

建設DXを考えるうえでは、製品そのものだけでなく、その裏側で建設実務とITをどう接続しているのかを見ることも重要だと思います。

維持DXでも、今後は橋梁・インフラ維持管理を中心とした実務知識とITの接点について、実際の事例や試作を通じて検証を続けていきます。

ダウンロード

維持DXでは、国交省様式を対象とした橋梁点検支援ツールを無料・機能制限版として公開しています。

実際の処理イメージを確認したい方は、以下のフォームからお申し込みください。

フォーム送信後に、ダウンロード案内をお送りします。

    お名前(任意)

    メールアドレス(必須)

    会社名・所属(任意)

    ご関心のある内容(任意)

    ご相談内容(任意)

    ご注意

    ダウンロードしたExcelでマクロが実行できない場合は、
    右クリック → プロパティ →「許可する」 をチェック後、再度開いてください。

    Windowsのセキュリティ機能により、初回実行時にマクロがブロックされる場合があります。