セルマッピングだけでは帳票対応にならない
自治体独自の橋梁点検調書に対応しようとすると、最初に目に入るのはセル番地である。
どのシートのどのセルに橋梁名があるか、写真番号はどこか、評価欄はどの範囲か。Excel VBAやPythonで処理するなら、まずセル位置を特定する必要がある。
しかし、福島県版の橋梁点検調書を対象に内部PoCを行って分かったのは、セル番地を拾うだけでは帳票対応にならないということだった。
橋梁点検調書は、単なる入力フォームではない。基本情報、径間、部材、損傷、写真、評価、コメントが、Excelの表示上の都合に合わせて配置されている。その見た目を、業務上のデータ構造へ翻訳する工程が必要になる。
ここでいう実務翻訳とは、日本語を英語に訳すことではない。
Excel上のセル、結合セル、反復ブロック、オートシェイプ、写真欄、コメント欄が、橋梁点検実務上のどの意味を持つのかを確定し、実装可能な仕様へ落とす作業である。
表示名が同じでも意味が同じとは限らない
Excel帳票では、似たような見出しが複数箇所に出てくることがある。
たとえば「評価」「判定」「損傷」「写真番号」「部材」といった言葉は、橋梁点検調書の中で何度も登場する。しかし、それぞれが同じ粒度の情報を指しているとは限らない。
同じ評価に見えても、径間全体に関する評価なのか、部材単位の評価なのか、損傷種類ごとの評価なのか、写真に紐づく記録なのかで、データ上の扱いは変わる。
この違いを無視して、見出し文字だけをキーに自動抽出すると、値は取れても意味が崩れる。
実務上は、次のような判断が必要になる。
- この評価は橋梁全体か、径間か、部材か
- この写真番号はどの損傷情報に紐づくのか
- このコメントは写真説明なのか、損傷説明なのか
- 空欄は未入力なのか、対象外なのか、評価不要なのか
- 同じ記号が別の表で使われている場合、意味は同じか
これらは、セル値だけを見ても確定しにくい。帳票の配置、周辺見出し、橋梁点検の実務知識、成果品としての使われ方を合わせて判断する必要がある。
Excel上の位置関係とデータ上の親子関係は別である
Excel帳票では、見た目の近さがそのままデータ上の親子関係を表すとは限らない。
隣り合うセルに置かれていても、業務上は別の単位に属する情報である場合がある。逆に、離れた位置にある情報が同じ写真、同じ部材、同じ径間に紐づくこともある。
福島BISTの内部PoCでは、この点が特に重要だった。
固定セルとして読める基本情報は比較的扱いやすい。一方で、写真メタ情報、部材・損傷情報、評価情報は、帳票上の配置と業務上の関係を読み替える必要があった。
たとえば、写真欄に記載される情報は、単に写真台帳として独立しているわけではない。写真番号、撮影位置、部材、損傷、コメント、評価結果のいずれかと関係している可能性がある。
また、径間単位で繰り返される情報は、Excel上では横方向・縦方向に広がる反復ブロックとして表現される。この反復構造をそのまま読まずに、径間、部材、損傷種類といった単位へ分解しないと、統合マスタの列設計ができない。
つまり、Excel上で近いかどうかではなく、実務上どの単位に属するかを軸に再構成する必要がある。
オートシェイプは見た目ではなく意味を持っていた
福島県版の調書で特徴的だったのは、セル値ではなくオートシェイプの配置によって評価情報が表現されていた点である。
IT実装側から見ると、Shapeは図形オブジェクトであり、セル値とは別物である。通常のセル読取では取得できない。
しかし、橋梁点検の帳票として見ると、その図形は単なる装飾ではない。評価欄のどこに置かれているかによって、損傷程度や評価区分を示している。
ここで必要になるのは、図形を取得する処理だけではない。
- どのShapeを対象にするか
- Shapeの中心座標をどの基準で読むか
- 評価表上のどの領域に入っているか
- 行方向が何を表しているか
- 列方向が何を表しているか
- 判定不能なShapeをどう扱うか
これらを決めるには、Excelオブジェクトモデルだけでなく、評価表の実務上の意味を理解する必要がある。
Shapeの座標を統合マスタに格納するだけなら、技術的には難しくない。難しいのは、その座標がどの評価項目に対応するのかを確定することである。
AI候補と正式マッピングは別物である
帳票解析では、AIにセルや見出しの候補を出させることは有効である。
空様式やサンプル帳票をもとに、入力項目らしきセル、周辺ラベル、見出し、反復パターンの候補を抽出することで、初期調査の速度は上がる。
しかし、AIが出した候補をそのまま正式マッピングとして扱うことはできない。
AIは、文字列や配置から「それらしい候補」を出せる。一方で、橋梁点検調書では、同じ見た目でも実務上の意味が異なる場合がある。空欄、対象外、未評価、判定不能の違いも、帳票だけでは確定しづらいことがある。
そのため、AIの役割は候補抽出までに留める必要がある。
正式マッピングでは、次のような人間の確認が必要になる。
- 項目名候補が実務上正しいか
- セル位置が対象情報の本体か、単なる見出しか
- 反復ブロックの単位が径間、部材、損傷のどれか
- 統合マスタ上の列名として再利用可能か
- 後段の一覧生成や整合確認に使える粒度か
- 自動抽出対象にしてよいか、人間確認を残すべきか
AIで下書きを作り、人間が意味を確定し、確定した仕様を実装へ渡す。この分離がないと、処理は速くなっても成果品としては危うくなる。
実務翻訳は土木知識とIT実装の中間にある
橋梁点検に詳しいだけでは、Excel帳票を機械処理可能なスキーマへ落とすことは難しい。逆に、ExcelやVBAに詳しいだけでも、帳票の業務上の意味までは確定しづらい。
必要なのは、土木実務とIT実装の間にある仕様翻訳の工程である。
この工程では、次のような作業を行う。
- 帳票上のセルや図形を意味単位へ分解する
- 橋梁、径間、部材、損傷、写真の関係を整理する
- 固定情報と反復情報を分ける
- 統合マスタの列命名規則を設計する
- 自動化できる処理と人間判断を残す処理を分ける
- 実装結果が実務上の意味を保っているか確認する
この部分は、単なる要件定義とも違う。要件定義書に「福島県様式に対応」と書くだけでは足りない。実際のExcel帳票を開き、セル、図形、反復構造、評価表現を読み、機械処理可能な仕様へ変換する必要がある。
ベンダー実装で問題になりやすい箇所
建設DXやインフラ点検DXの製品では、現場入力、写真管理、AI判定、クラウド連携といった機能が注目されやすい。
一方で、自治体ごとの提出様式に合わせる段階では、泥臭い帳票対応が残る。
ここで問題になるのは、プログラムが動くかどうかだけではない。
- その列は本当にその評価を表しているか
- その出力は発注者様式の読み方と合っているか
- その空欄処理は実務上許容されるか
- 写真番号と損傷情報の関係が崩れていないか
- 後で修正が入ったときに整合確認できる構造か
これらは、エンジニアだけで調べると時間がかかる。土木技術者だけでも、実装可能な仕様に落とすところで詰まりやすい。
福島BISTの内部PoCで確認したのは、この中間工程を具体的な形にできるかどうかだった。
実装済みと未実装の境界
今回のPoCで実装済みなのは、単一橋・3径間サンプルにおける、既存成果から統合マスタへの構造化取込である。
固定セル、写真メタ情報、オートシェイプ座標による評価情報、約1,900列規模の統合マスタヘッダー生成は確認済みである。
ただし、評価結果一覧生成、差分抽出、整合確認、帳票再出力、複数橋対応、一般ユーザー向けUIは未実装である。
この区別は重要である。未実装の機能を完成済みのように見せる必要はない。むしろ、どこまで実装し、どこから先は設計上の拡張かを分ける方が、技術者向けの記事としては評価しやすい。
仕様翻訳の成果物はコードだけではない
仕様翻訳の結果として残るものは、VBAコードだけではない。むしろ、コードより前に残すべきものが多い。
たとえば、固定セルの対応表、写真欄の意味付け、Shape座標と評価欄の対応、反復ブロックの単位、統合マスタの列名規則、警告に回す条件、確認すべきテストケースなどである。
これらが整理されていない状態でコードを書くと、実装者は帳票を見るたびに判断をやり直すことになる。処理は動いても、なぜそのセルを読んでいるのか、なぜそのShapeを評価として扱うのか、なぜその列名になるのかを説明しにくい。
反対に、仕様翻訳が済んでいれば、実装は差分修正しやすくなる。別の自治体様式へ横展開する場合も、流用できる部分と再確認が必要な部分を分けやすい。
福島BISTの内部PoCで確認した価値は、完成した配布製品ではなく、この仕様翻訳の工程を具体的な形で残せることにある。
実務翻訳がないと何が起きるか
実務翻訳を省略すると、実装は一見進む。セルを読み、図形を読み、一覧のようなものを作ることはできる。
しかし、後から確認すると、写真と損傷の対応が曖昧だったり、評価の粒度が違っていたり、帳票上の空欄を未入力として扱うべきか対象外として扱うべきか分からなくなったりする。
これはプログラムの文法エラーではなく、仕様の意味エラーである。実行時に止まらないため、むしろ気づきにくい。橋梁点検調書対応で怖いのは、この種の意味エラーが成果品整理や後段の整合確認で表面化することである。
まとめ
自治体独自の橋梁点検調書対応では、セル番地を拾うだけでは不十分である。
帳票上の表示構造、橋梁点検実務上の意味、Excelオブジェクト、反復ブロック、写真情報、評価情報を読み解き、統合マスタとして再構成する必要がある。
AIは候補抽出には使えるが、正式マッピングの確定には実務上の意味判断が必要になる。そこに、IT実装と橋梁点検実務の間をつなぐ仕様翻訳の工程がある。
福島BISTの内部PoCは、完成製品ではない。だが、自治体独自帳票を実装可能な仕様へ翻訳する工程を具体的に確認した実例としては、十分に意味があると考えている。
