WRITING
建設データがAIに使えないのは、量ではなく「意味の断絶」のせいだ
生成AIを建設業に導入しようとすると、すぐに壁に当たる。施工計画書を横断検索したい、過去工事の原価と工程を比較したい、BIMから数量を拾いたい。いずれも魅力的なユースケースだが、実際に動かそうとすると「モデルの精度」より先に別の問題が姿を現す。同じ工事が社内で別々の名前で管理されている、工種の粒度がシステムごとに違う、施工計画書に識別子がない──これが「意味の断絶」という問題だ。
「同じ工事」がシステムごとに別名で動いている──AIは同一工事を特定できない
建設業の典型的な問題は、工事識別子の不統一だ。同じトンネル工事でも、営業段階の案件番号・受注後の工事番号・会計システムの工事コード・ファイルサーバーのフォルダ名がそれぞれ別の文字列になっている。JV内番号や発注者番号が加わると、「同じ現場」を機械が自動で特定することは困難になる。
人間は「これは○○トンネルの話だな」と文脈で補える。しかしAIが原価・工程・安全を横断分析するとき、識別子が揃っていなければ名称の類似で推測するしかない。推測に依存したまま複数データを結合すると、接続ミスが無音で発生する。
横断分析の精度が担保できず、AIの回答を業務で信頼できない。モデルを変えても解決しない構造問題だ。
見分け方 AIが「工事コードを入力してください」と毎回聞いてくる状態は、識別子が整っていないサインだ。AIは識別子を「使う」のではなく「聞き直す」ことで穴を埋めている。
分かれ目 既存コードをすべて統一しようとする必要はない。各システムのローカルコードを1つの企業共通IDに紐づける翻訳表を作るだけで、AIは同じ工事として追跡できるようになる。
データを「一か所に集める」だけでは、意味の断絶は解消されない
工事の識別子が揃っても、次の壁が工種の粒度だ。原価では「掘削工」、工程WBSでは「床掘り」、BIMのカテゴリでは「土工」、安全分類では「掘削作業」と表現される同じ作業が、システムごとに異なる語彙と粒度で存在している。
データをクラウドや一か所のレイクに集めても、この語彙の対応表がなければAIはシステムをまたいだ「同じ作業」を認識できない。従来のDXで言われた「サイロ問題」は、データの物理的な分散だった。AI活用では、物理統合が完了しても「意味の断絶」が残ることが本質的な障壁になる。
従来のサイロ問題
物理的な分散
- –データが複数システムに散在
- –一か所に集めれば使えると考える
- –データレイク・DWH構築が解決策
AI時代の本質課題
意味の断絶
- ✕集まっても工事コード・工種の語彙が揃わない
- ✕PDFに識別子がなくBIMと結合できない
- ✕翻訳表・共通ID・版管理が別途必要
よくある誤解 「クラウドに移したのになぜAIが使えないのか」という疑問はここから来る。物理統合と意味統合は別の作業だ。大きな箱にサイロごと移しただけでは、意味の断絶はそのまま残る。
目安 「工種」の名前が、会計・工程・安全・BIMの4システムで一致していれば基盤は整っている。一つでも揃っていなければ、コード間の翻訳表が必要だ。
施工計画書はPDF検索ができるだけでは半分しか使えていない
施工計画書は建設業の知識資産の核だ。鉄骨・コンクリート・土工など工種ごとに章立てが定型化された長大なPDFが、現場ごとに数百件単位で存在する。これをそのままベクトル化して全文検索できるようにするだけでは、AIの活用は途中段階にとどまる。
文書に工事コード・工種・版数・承認状態がメタデータとして付いていなければ、AIは検索結果を工程・原価・安全記録と確実に接続できない。「この施工条件に近い過去工事の計画書を出して」という問いに答えるには、識別子の紐づけと版管理が先に必要だ。
注意 PDFをまとめてベクトル化するだけでは、RAGの入口に過ぎない。版管理がなければ古い施工計画書や未承認の草稿をAIが正として引用するリスクがある。検索が成功していても業務として失敗するケースはここで起きる。
分かれ目 「施工計画書を検索できる状態」と「業務で使える状態」は別物だ。後者には識別子の紐づけ・版管理・横断接続の3点がそろっている必要がある。
データの地ならしなしにAIを入れると、4つの失敗を繰り返す
建設業でAI導入を急いだとき、共通して現れる失敗パターンが4つある。いずれも「AIモデルの問題」ではなく「データ基盤の問題」が起点になっている。
全データを先に集める
価値と品質を選ばずに大量移行すると、コストとゴミデータが増えるだけで使える状態にならない
RAGをデータ統合と混同する
似た文章を見つける技術と、工事・工種を確実に結合することは別問題。RAGだけでは意味の断絶は埋まらない
AIにクレンジングを丸投げする
AIは候補生成には強いが、企業の公式マスタを確定する責任主体にはできない。Human-in-the-loopが必要
現場に入力作業を増やす
AI基盤のために二重入力を強いると現場に定着しない。既存業務の入力から自然にメタデータが得られる設計が先
見分け方 「まず全データをレイクに入れましょう」という提案が出たら、「どのデータを、どの粒度で、誰のキーで使うか」を先に決める議論が抜けているサインだ。
注意 AIにすべてのクレンジングを任せる判断は危険だ。名称揺れの候補提示や分類支援はAIが得意だが、「この工事コードが正式なものだ」と企業として確定する判断は人が行う必要がある。
「意味の断絶」を解消する4段階の地ならし
問題が分かれば、解決策の順序は決まる。全システムを一夜で統一しようとする必要はない。既存の業務システムやファイル保管を活かしながら、それらを横につなぐ「データの背骨」を段階的に作ることが現実的な進め方だ。1段階ずつ積み上げれば、3か月後には最初のAIユースケースが動き始める。
配分 段階1・2に投資の7割を集中させるのが正しい。「先にAIアプリを作って、後でデータを整える」という順序は高確率で最初からやり直しになる。
目安 段階2まで完了すれば、1つのユースケース（例：過去工事の横断検索）は動き始める。段階4まで整うと、施工・安全・積算・設計の複数ユースケースが同じ基盤を再利用できるようになる。
建設業には、施工実績・施工計画書・BIM・安全記録という価値の高いデータが揃っている。問題はデータがないことではなく、工事コードが揃っていないこと、工種の語彙が統一されていないこと、文書に識別子がないことだ。この3点が「AIが使えるデータ」と「使えないデータ」の境界線になっている。AIモデルを選ぶ前に、この地ならしに着手することが、実務でAIを動かす最短経路だ。