自由記述をAIで読めば帳票DXは完成する？｜非構造化データと技術判断の責任境界

建設DXで既存のExcel帳票を自動化すると、あるところで必ず気になる問題があります。

自由記述です。

前回までの記事では、自治体独自の橋梁点検Excelを題材に、

• セル配置の複雑さ
• 欄外注記
• 所見
• 備考
• 表記揺れ
• 担当者独自の記述

などが、自動化を難しくすることを書きました。

ここで今なら、かなり自然な疑問が出てきます。

「それ、AIに読ませればいいのでは？」

実際、生成AIやLLMは文章を読むのが得意です。

たとえば自由記述に、

「支承部に著しい錆が確認された」

と書いてあれば、

「部材は支承」

「変状は腐食」

と整理することは、技術的には十分考えられます。

では、

自由記述をAIで読めるようになれば、帳票DXは完成するのでしょうか。

私は、そう単純ではないと考えています。

なぜなら、

文章を読むこと

と、

技術判断をすること

は別だからです。

そして、この境界を越えた瞬間、

システムの性質そのものが変わります。

AIは「非構造化データを読む」ことはできる

まず、AIを使う価値がないという話ではありません。

むしろ逆です。

従来のプログラムでは扱いにくかった自由記述も、生成AIならかなり柔軟に読めます。

たとえば、

「主桁下フランジに腐食あり」

「排水装置付近に漏水跡」

「支承周辺に錆が進行」

といった記述から、

• 対象部材
• 変状の種類
• 場所
• 程度
• 関連するキーワード

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

従来なら、

「腐食」

「錆」

「発錆」

「サビ」

などの表記揺れを辞書で一つずつ管理していた部分も、

AIなら文脈から近い意味として扱える可能性があります。

これは大きな利点です。

建設実務では、

文章。

備考。

写真コメント。

所見。

申送り。

など、構造化されていない情報が大量にあります。

AIは、これらを扱う入口としてかなり強い技術です。

ただし、

ここで一つ線を引く必要があります。

「抽出」と「判定」は同じではない

たとえば自由記述に、

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

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

ここから、

「支承」

「腐食」

という情報を抽出する。

これは比較的、

情報抽出

に近い処理です。

一方、

「この記述なら評価Cにすべき」

と出力する。

これは性質が違います。

なぜなら、

評価を決めるには、

• どの判定基準を使うか
• 損傷の程度はどのレベルか
• 他の所見と矛盾しないか
• 写真と整合しているか
• 過年度評価とどう比較するか
• 例外条件がないか

などを考える必要があるからです。

ここまで行くと、

単なる文章整理ではありません。

技術判断

です。

つまり、

自由記述
↓
部材名・変状名を抽出

と、

自由記述
↓
評価値を決定

の間には大きな差があります。

見た目には、どちらも「AIが文章を読んで答える」だけです。

しかし実務上の責任はまったく違います。

転記システムから「判断システム」へ変わる瞬間

既存Excelから値を読み、

別の一覧表へ転記するシステムであれば、

基本的な責任は、

元データを正しく移せているか

です。

たとえば、

元帳票でC評価なら、一覧表でもC。

橋梁名がA橋なら、統合マスタでもA橋。

このような処理です。

ところがAIに自由記述を読ませ、

そこから新しい評価を生成する場合、

システムは元データを移しているだけではありません。

元帳票に存在しない新しい意味を作っています。

ここが重要です。

たとえば元帳票に、

「著しい錆あり」

とだけ書かれていて、

評価値は入力されていない。

AIがこれを読んで、

「C評価」

と出したとします。

そのCは、

どこから来たのでしょうか。

元帳票にはありません。

つまり、

AIが推論によって新しい技術情報を作ったことになります。

この瞬間、

帳票自動化ツールは、

データ変換ツールから技術判断支援システムへ変わります。

「読める」と「正式データにしてよい」は別問題

生成AIの性能が上がると、

文章をかなり自然に分類できます。

すると、

「ここまで読めるなら、そのままデータ化してしまえばいい」

と思いやすくなります。

しかし、

AIがそれらしく分類できることと、

その結果を正式データとして採用してよいことは別です。

たとえば、

「支承周辺に錆あり」

という文章から、

変状を「腐食」とするのは比較的分かりやすいかもしれません。

では、

「やや錆が見られる」

「局部的に劣化」

「進行していると思われる」

のような表現はどうでしょうか。

どの程度を意味するかは文脈に依存します。

さらに、

写真。

現地状況。

過年度成果。

他部材との関係。

点検者の意図。

まで含めないと判断できない場合があります。

つまり、

文章だけを読めても、判断に必要な情報が全部揃っているとは限らない

のです。

AIに自由記述を任せると、新しい確認項目が増える

AIで非構造化データを扱う場合、

従来の自動化にはなかった確認項目が増えます。

何をAIへ送るのか

自由記述だけか。

橋梁名も含めるのか。

写真コメントも送るのか。

過年度記録も含めるのか。

入力情報の範囲で、AIの判断も変わります。

AIの出力をどこまで採用するのか

候補表示だけにする。

人間確認後に確定する。

自動確定する。

ここで責任の重さが大きく変わります。

誤読した場合にどう戻すのか

AIが「腐食」と分類したが、

実際には別の変状だった。

その場合、

誰が修正するのか。

修正履歴を残すのか。

元文章も保存するのか。

といった運用が必要になります。

同じ結果を再現できるか

同じような文章でも、

入力文脈やモデル条件によって結果が変わる可能性があります。

正式成果へ使うなら、

「なぜこの分類になったか」

を後から追える設計も重要です。

こうして見ると、

AIを入れることで単純に人手が減るわけではありません。

別の種類の確認作業が発生する

ことがあります。

BISTでは、ここをあえて越えなかった

今回の橋梁点検ExcelのPoCでは、

自由記述をAIで技術判断へ変換するところまでは対象にしていません。

扱うのは、

元帳票ですでに構造化された評価

です。

つまり、

点検者や技術者がすでに入力した評価値を取得し、

橋梁単位のデータへ整理し、

一覧表へ集約する。

ここを自動化対象にしています。

一方、

自由記述。

所見。

欄外注記。

他様式のコメント。

だけを根拠として、

システム側が新しい評価を創作することはしません。

これは、

AIを使えないからではありません。

責任境界を明確にするためです。

自動化できることと、

自動化すべきことは同じではありません。

AIは「判断の前処理」にはかなり使える

では、自由記述にAIを使う余地はないのでしょうか。

そんなことはありません。

むしろ、

正式な技術判断の一歩手前

にはかなり使える可能性があります。

たとえば、

自由記述から、

「支承に関する記述がある」

「腐食に関連する表現がある」

「前年度比較について言及している」

といった候補を抽出する。

そして人間へ、

「この文章は支承・腐食に関する記述として抽出しました。確認してください」

と提示する。

これなら、

AIが最終判断を確定するのではなく、

人間が確認すべき情報を探す補助

として使えます。

ほかにも、

• 自由記述の分類候補を出す
• 表記揺れをまとめる
• 重複記述を探す
• 要確認箇所を抽出する
• 長い所見を要約する
• 既存の構造化項目との矛盾候補を探す

といった使い方があります。

この場合、

AIの役割は、

判断者ではなく検索・整理・候補提示

です。

帳票DXでは、この差がかなり重要だと思います。

人間確認を残すなら、どこに残すのか

「AIは補助にして、人間が最後に確認する」

という言い方は簡単です。

しかし実装では、

どこで確認するか

まで決める必要があります。

たとえば、

AIが抽出した候補を一覧表示し、

技術者が、

• 採用
• 修正
• 対象外

を選ぶ。

採用されたものだけを統合マスタへ登録する。

元の自由記述も残す。

AIが出した候補も履歴として保持する。

こうすれば、

原文
↓
AIによる候補抽出
↓
人間確認
↓
確定データ

という流れになります。

この設計なら、

どこまでがAIで、

どこからが人間なのか

が明確です。

逆に、

AI出力をそのまま確定値へ書き込むと、

責任境界が見えにくくなります。

「AIを使うか」より「AIに何を決めさせるか」

AI導入の議論では、

「AIを使うか、使わないか」

という二択になりがちです。

しかし実務では、

もっと細かく考えた方がいいと思います。

たとえば、

文章を読む。

分類候補を出す。

検索対象を絞る。

要約する。

矛盾候補を出す。

ここまではAI。

最終評価を決める。

成果品へ確定値として反映する。

技術的な意味を確定する。

ここは人間。

というように、

役割を分解できます。

重要なのは、

AIの有無ではなく、どの判断権限をAIへ渡しているか

です。

建設DXでは「正解率」だけ見ても足りない

AIの性能を評価するとき、

「何％当たったか」

だけを見たくなります。

もちろん精度は重要です。

しかし建設実務では、それだけでは足りません。

たとえば99％正しくても、

残り1％が、

重要構造物の評価。

緊急性の高い変状。

補修判断に影響する箇所。

だったらどうでしょうか。

件数ベースの正解率が高くても、

業務リスクが低いとは限りません。

そのため、

どこまで自動確定を許すかは、

精度だけでなく、

誤ったときの影響

も含めて考える必要があります。

これはAIに限らず、自動化全般で同じです。

情報管理の問題も出てくる

自由記述には、

案件固有の情報が含まれることがあります。

橋梁名。

位置情報。

現場状況。

担当者コメント。

場合によっては、外部へそのまま送ることを想定していない情報もあります。

そのためAIを使うなら、

何を入力するのか。

どの環境で処理するのか。

保存されるのか。

学習利用されるのか。

組織の情報管理ルールと整合するのか。

といった確認も必要です。

「AIなら文章を読める」

だけでは導入判断はできません。

技術的な可能性とは別に、

運用可能性

を見なければなりません。

本当に必要なのは「AIで全部読むこと」ではない

帳票DXを考えると、

最終形として、

「どんなExcelでもAIが全部読んで、自動で理解してくれる」

という姿は魅力的です。

しかし実務では、

そこを最初の目標にしなくてもよいと思います。

まず、

構造化できるものを構造化する。

評価値は評価欄へ入れる。

部材名は統一する。

検索したい情報は項目化する。

その上で、

どうしても残る自由記述だけAIで補助する。

この順番の方が安定します。

AIは、

正規化をしなくてよくなる魔法

ではありません。

むしろ、

正規化しても残る曖昧な領域を扱うための追加手段

と考えた方が、実務では使いやすいと思います。

まとめ

生成AIを使えば、これまで機械処理しにくかった自由記述を読むことは可能になってきました。

これは帳票DXにとって大きな変化です。

しかし、

文章を読める。

分類できる。

情報を抽出できる。

ことと、

正式な技術判断を確定できる。

ことは別です。

AIが、

「この文章は腐食について書いている」

と候補を出すのと、

「この橋梁の評価はCである」

と確定するのでは、

システムの責任が違います。

だから帳票DXでは、

どこまでがデータ抽出で、どこからが技術判断なのか

を先に決める必要があります。

AIを入れるかどうかより、

AIに何を決めさせるのか。

どこで人間が確認するのか。

誤った場合にどう戻せるのか。

ここを設計する。

自由記述をAIで読めるようになっても、

帳票DXはそれだけでは完成しません。

むしろAIによって、

これまで曖昧だった「人間が判断していた領域」が、よりはっきり見えるようになる。

そこに、次の建設DXの設計課題があると思います。

ダウンロード

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

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

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

ご注意

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

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