建設DXで神Excelを自動化して分かった本当の壁｜自由記述と欄外注記が生む非構造化

建設DXの現場では、今もExcel帳票が大量に使われています。

点検調書、台帳、検査記録、積算資料、写真帳、集計表。

しかも単なる一覧表ではありません。

印刷したときの見た目を優先してセルが細かく分割され、結合セルがあり、図形や写真が配置され、複数シートが連動し、担当者が自由記述を書き足せる。

いわゆる「神Excel」と呼ばれるような帳票です。

ここでいう神Excelとは、Excelそのものを揶揄する言葉としてではなく、

人間が見る・印刷する・その場で判断を書き足すことに最適化され、その結果として機械処理しにくくなった帳票

くらいの意味で使います。

こうしたExcelをDXしようとすると、最初に目につくのはセル配置の複雑さです。

私自身、ある自治体独自の橋梁点検Excelを対象に、複数の点検調書を取り込み、橋梁単位の統合データへ変換し、最終的に一覧表へ再出力するPoCを作りました。

開始時点では、

「一番大変なのは、この複雑なExcel構造をどう読むかだろう」

と考えていました。

ところが、実際に自動化してみると、本当に厄介だったのは別の場所にありました。

セルを読めないことではありません。

評価や判断の意味が、そもそも一か所に構造化されていなかったのです。

最初はExcelの構造差が問題だと思っていた

自治体独自の点検Excelをプログラムから読むのは、確かに簡単ではありません。

一般的なデータベースのように、

• 1行が1レコード
• 1列が1項目
• 同じ列には同じ意味の値が入る

という構造になっているとは限らないからです。

基本情報は固定セル。

点検結果は別シート。

写真情報はさらに別の領域。

評価値がセルではなくShapeなどのオブジェクトとして配置されている場合もあります。

橋梁によって径間数が違えば、繰り返されるデータ量も変わります。

写真枚数も一定ではありません。

人間なら画面を見れば、

「ここが橋梁名」

「ここがこの径間の評価」

「この写真はこの部材」

と理解できます。

しかしプログラム側から見れば、すべて位置とルールを定義する必要があります。

これは面倒です。

ただし、面倒ではあっても、

ルールとして定義できるものは自動化できます。

固定セルならセル位置を定義する。

ShapeならShapeを読む。

複数径間なら繰り返し構造として扱う。

写真なら写真番号や位置関係を仕様化する。

帳票ごとの差分も、仕様として切り出せば処理できます。

実際、この部分はPoCを進める中でかなり機械化できました。

そこで次の問題が出てきます。

同じ「評価」が、いろいろな場所に書かれている

橋梁点検のExcelには、構造化されたチェック欄があります。

たとえば、

「ひびわれがあるか」

「漏水・遊離石灰があるか」

「変形があるか」

といった設問があり、それに対応する評価が入力されます。

ここだけ見れば、自動集計は比較的やりやすい。

ところが実際の帳票を見ていくと、それだけではありません。

構造化されたチェック欄とは別に、

• その他自由記入欄
• 所見
• 備考
• 他の様式に書かれたコメント
• 欄外への注記
• 担当者独自の表現

などにも重要な情報が存在します。

つまり、

評価の意味が一つのデータ項目として完結していない

のです。

たとえば構造化されたチェックではある評価になっていても、別の自由記述欄に追加の説明が書かれていることがあります。

また、正式な変状名称ではなく、現場で通じる俗称や略称で記録されることもあります。

人間の担当者は、それらを総合して意味を理解できます。

しかし機械処理では、

「この文章はどの部材の、どの変状を意味するのか」

「このコメントは既存の評価を補足しているだけなのか、それとも評価そのものを変更する情報なのか」

を判断しなければなりません。

ここで問題の性質が変わります。

神Excelの本当の問題は、セル結合だけではない

神Excelというと、

• セル結合が多い
• 印刷レイアウト優先
• 見た目が複雑
• VBAが大量に入っている

といった話がよく出ます。

もちろん、それらも自動化では障害になります。

しかし今回、実際に処理を作ってみて感じたのは、

より根深い問題は「情報の意味が非構造化領域へ漏れ出していること」

でした。

セル位置が複雑でも、そのセルが何を意味するか分かっていれば処理できます。

逆に、非常にシンプルな自由記述欄でも、

そこに何が書かれるか分からないのであれば、自動処理は急に難しくなります。

つまり、

見た目の複雑さと、データとしての扱いにくさは別問題

です。

Excelは自由度が高いからこそ、

「このケースだけ一言書いておこう」

「ここは欄外に補足しておこう」

「正式項目はないけれど、担当者には伝わるから備考へ書こう」

という運用が成立します。

短期的には非常に便利です。

しかし長期間その運用を続けると、

人間の解釈を前提とした情報が帳票全体へ分散する

ことになります。

そして後からDXしようとした時に、そのツケが一気に出ます。

人間は非構造化データを無意識に補完している

人間がExcel帳票を扱う時は、かなり多くの補完を無意識に行っています。

たとえば、

「この記述は支承のことだな」

「この略称はこの変状を意味している」

「この所見は評価そのものではなく補足説明だ」

「ここに書いてあるから、一覧表にも反映した方がいい」

といった判断です。

長くその業務を担当している人ほど、こうした判断を自然に行えます。

しかしこれは裏を返すと、

帳票の仕様だけでは業務を完全に再現できない

ということでもあります。

データに書かれていない意味を、人間が経験や文脈から補っているからです。

この状態で、

「Excelを全部自動化しよう」

とすると、

単なる転記処理では済まなくなります。

人間が暗黙に行っていた解釈までシステムへ実装する必要が出てきます。

そこで「全部自動化しない」と決めた

今回のPoCでは、ここで責任境界を明確にしました。

基本方針は、

構造化された評価だけを機械的に処理する

です。

自由記述、所見、欄外注記、他様式のコメントにだけ存在する判断については、自動評価へ反映しない。

これは技術的に読めないから単純に諦めた、という意味ではありません。

理由は、

そこまで処理すると、システム自身が技術判断を行うことになるから

です。

たとえば、

自由記述に、

「支承部に著しい錆あり」

と書かれていたとします。

文字列として取得すること自体はできます。

しかし、それをどの評価項目へ対応させるのか。

既存のチェック結果より優先するのか。

判定値を変更するのか。

別の変状として扱うのか。

ここまで進むと、

「Excelから値を取り出して一覧化するシステム」

ではなく、

文章を読んで点検結果を解釈するシステム

になります。

同じ自動化でも、責任の重さがまったく違います。

そのため現行のPoCでは、

• 元帳票ですでに構造化された評価
• 明確に定義できる基本情報
• ルールで集約できる部材別評価

を自動処理の対象とし、

それ以外の自由記述領域は責任境界の外へ置きました。

表示上の正規化と、技術判断は分ける

一方で、一覧表へ出力するときには別の問題があります。

元帳票の設問文が、そのままでは一覧表示に長すぎる場合です。

たとえば、

「床版下面に漏水、遊離石灰があるか」

という点検設問を、そのまま一覧表の変状名として毎回表示する必要はありません。

一覧では、

「漏水・遊離石灰」

のように、意味を変えない範囲で短い名称へ整理できます。

これは今回のPoCでも行っています。

ただし重要なのは、

これは技術判定の変換ではなく、表示の正規化である

という点です。

元の設問が持つ意味を別の基準へ勝手に変換するわけではありません。

どこまでが表示整理で、

どこからが新しい技術判断なのか。

この境界を明確にすることも、帳票DXでは重要になります。

「自由記述もAIで読めばいい」は次の問題を生む

ここまで読むと、

「今ならAIやLLMで自由記述も解析できるのでは？」

と思うかもしれません。

実際、技術的にはかなり可能性があります。

自由記述から、

• 部材名
• 変状名
• 程度
• 関連する評価項目

などを抽出することは考えられます。

ただし、それを実務へ入れる場合は別の論点が出てきます。

入力した情報を外部APIへ送ってよいのか。

同じ文章に対して毎回同じ解釈になるのか。

AIが誤解した場合、誰が確認するのか。

元データとAI解釈のどちらを正式記録とするのか。

なぜその評価になったのか説明できるのか。

つまり、

非構造化データをAIで読めることと、安全に業務判断へ使えることは別問題

です。

この話は次の段階として重要ですが、まず既存帳票を自動化する段階では、

「AIなら何でも読める」

と一気に飛ばず、

どこまでが単純なデータ処理で、

どこからが人間の判断なのか

を分ける必要があります。

本質的な解決策は、入力段階で構造化すること

自由記述を後から解析する方法はいくつも考えられます。

辞書を大量に作る。

条件分岐を増やす。

AIに文章を読ませる。

いずれも技術的には可能です。

しかし、根本的には、

最初から必要な情報を構造化して入力できるようにする

方が強い。

変状名を選択式にする。

対象部材を明確にする。

評価値と補足コメントを分離する。

例外処理にも専用項目を用意する。

こうしておけば、後工程の集計や比較は圧倒的に簡単になります。

ただし現実には、既存の自治体様式や長年の業務運用をすぐに変更できるとは限りません。

そのため建設DXでは、

理想的なデータ構造を一から作るだけでなく、

すでに存在する非構造化Excelと、どこまで付き合うのか

という設計も必要になります。

建設DXでは「既存帳票をそのまま自動化」が最適とは限らない

既存業務をDXするとき、

「現在人間がやっていることを全部そのまま自動化する」

ことが目標になりがちです。

しかし今回のような帳票では、その考え方が危険な場合があります。

人間が行っている作業の中には、

単純転記だけでなく、

暗黙の補完。

経験による解釈。

例外判断。

現場固有の慣行。

が混ざっています。

それを区別せず全部自動化しようとすると、

システムの責任範囲が際限なく広がります。

そこで重要なのは、

既存業務をそのまま機械へ移すのではなく、一度分解すること

です。

これはデータなのか。

これは表示なのか。

これは転記なのか。

これは集約ルールなのか。

これは技術判断なのか。

ここまで分けると、

「自動化できる部分」

と、

「人間が残るべき部分」

が見えやすくなります。

まとめ

自治体独自の橋梁点検Excelを実際に自動化してみると、確かにセル配置やShape、複数シート、繰り返し構造などの技術的な難しさはありました。

しかし、それらは仕様を定義できれば処理できます。

より大きな壁だったのは、

評価や判断の意味が、構造化された入力欄だけでなく、自由記述・所見・欄外注記などへ分散していたこと

でした。

Excelは自由度が高い。

だからこそ、人間がその場で例外を書き足せます。

そして、その便利さが長年積み重なると、

人間だけが意味を理解できる非構造化データが増えていきます。

建設DXで重要なのは、

Excelを読めるプログラムを作ることだけではありません。

その前に、

どこまでがデータで、どこからが人間の解釈なのかを切り分けること

です。

神Excelの本当の壁は、セル結合だけではありません。

人間が無意識に補っていた意味まで、Excelの中へ埋め込まれている。

既存帳票をDXすると、その事実が初めて見えてきます。

ダウンロード

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

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

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

ご注意

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

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