図面の空間構造を損なわずに道路設計図を読み解く：PlanSightRAGの試み

米国の州運輸局（DOT）による高速道路インターチェンジの設計図面を思い浮かべてみてほしい。ガードレールの支柱から舗装端まで寸法線が引かれ、「24'-0"」と記されている。そのすぐ近くでは、引き出し線のバルーンがカルバート（暗渠）を指し、管径に関する注記が添えられている。ここには自然な「読む順序」など存在しない。「24」という数字は付随する矢印がなければ意味をなさず、その矢印もまた、結びつけている2つの点が分からなければ何の意味も持たない。ここで、このページをOCRにかけてみよう。得られるのはテキストの寄せ集め（bag of text）だ。「24'-0"」、「CULVERT」、管径、測点番号など、抽出された文字列としてはすべて正しくても、まったく役に立たない。それらに意味を与えていた要素（どの線がどのオブジェクトに接しているかや、ページのどこに配置されているか）がすべて失われてしまっているからだ。

これこそが、新たな論文「PlanSightRAG」が解決しようとしている課題であり、「OCRはすでに解決済みの問題だ」と考えていると見落としがちな典型的な失敗例と言える。OCRは図面に対しては解決していない。大半が文章で構成された文書に対して解決しているにすぎないのだ。

なぜ土木図面では標準的なドキュメントAIの手法が通用しないのか

文書を対象とする検索拡張生成（RAG）システムの多くは、共通のレシピに従っている。ページをOCRでテキスト化し、テキストをチャンクに分割し、チャンクを埋め込みベクトルに変換し、言語モデルに検索と推論を行わせるというものだ。契約書や請求書、報告書などであれば、情報は言葉の中に宿り、言葉は順序立てて読まれるため、この手法でも十分に機能する。

しかし、土木工学の標準設計図（Standard Plans）はそうはいかない。州運輸局（DOT）の図面集に含まれるたった1枚のシートであっても、以下のような要素が混在している。

• 平面図（真上からの見下ろし）と縦断図（側面からの立面図）が、同一ページ内に異なる縮尺で共存している
• 寸法線や引き出し線が、純粋に幾何学的配置によって関係性をエンコードしている
• テキストラベルではなく、慣例的な記号やハッチングパターンによって特定の意味を表現している
• 他の図面シート、表、そして実際の数値基準を定めた別冊の仕様書（specification book）への相互参照が含まれている

OCRによってレイアウトを削ぎ落としてしまえば、図面を読み解くために必要な情報のほとんどを捨て去ることになる。著者陣もアブストラクトで率直に述べている通り、OCRベースの自動化は「これらの図面を解釈するために不可欠な幾何学的構造やレイアウトを削ぎ落としてしまう（strips away the geometry and layout essential for interpreting these plans）」のだ。エンジニアはいまだに、数百ページにも及ぶ仕様書と突き合わせながら、1枚1枚目視で適合性チェック（compliance checking）を行っている。これは時間がかかり、反復的でミスが起きやすいという、まさに自動化が得意とするはずのタスクである。しかし、標準的なドキュメントAIのツールキットでは歯が立たないのだ。

解決策：図面をテキストに変換すること自体をやめる

PlanSightRAGの中核となるアプローチは、インデックス作成と検索においてOCRによるテキスト抽出を完全に排したことだ。図面シートをテキストに変換してから検索するのではなく、各ページを画像として扱い、画像から画像を検索する。

その検索バックボーンを担うのが「ColNomic-3B」と呼ばれるモデルだ。これが何を意味するのかを理解するには、そのモデルが属する系譜を知るのがわかりやすい。従来の文書検索では、ページ全体を圧縮して1本のベクトル（数値のリスト）にまとめ、ページ上のすべてを要約しようとする。これは高速だが情報落ち（lossy）が大きい。12個の独立した引き出し注記があるページも、1つの段落しかないページも、同じサイズのベクトルに潰されてしまうからだ。それに対してColNomicは、「ColPali」と呼ばれる手法の系譜を引くマルチベクトル・アプローチを採用している。画像をグリッド状のパッチに分割し、パッチごとに個別のベクトルを生成するため、クエリはページ全体の平均値ではなく、該当する情報が実際に存在するページの特定の領域とマッチングできる。システムにクエリ（例えば「このガードレール形式の最小クリアランスはいくらか」など）を投げると、全ページの全パッチに対してクエリを照合し、最も関連性の高いマッチを見つけ出す。幾何情報が損なわれないのはこのためだ。モデルに対して、最初に図面を言葉で説明させるといった処理を挟む必要が一切ない。

この検索レイヤーの上層で稼働するのが、論文内で「エージェント型Planner-Retriever-Auditor-Synthesizerパイプライン」と呼ばれている仕組みだ。単一のモノリシックなプロンプトに頼るのではなく、パイプラインの各ステップで以下の4つの役割を分担して処理する。

• Planner：質問が実際に何を求めているのかを分解する（関連する図面種別や、チェックすべき要件の特定）
• Retriever：ColNomicのマルチベクトル検索を用いて、候補となる図面ページや参照仕様書のページを取得する
• Auditor：検索された結果を鵜呑みにせず、取得した証拠が実際に回答を裏付けているかを検証・監査する
• Synthesizer：検索されたページに基づいて根拠付けされた（grounded）、最終的な回答や適合性の判定結果を生成する

もう1点特筆すべきは、「MaxSimヒートマップ」と呼ばれる機能だ。検索モデルがパッチレベルの類似度スコアを計算するため、ページのどのパッチがマッチングに寄与したのかを可視化できる。これにより、元の図面上にヒートマップがオーバーレイされ、システムが該当する寸法線、記号、あるいは注記をどこであると認識しているかを正確に確認できる。これは一見する以上に重要な機能だ。単に「合格（PASS）」または「不合格（FAIL）」とだけ返す適合性チェックでは、エンジニアは承認のサインを出せない。「不合格。そして図面上で問題となった箇所はここだ」と示してくれる適合性チェックであれば、人間が実際にレビューして信頼したり、誤りを検知したりすることが可能になる。

数値データが実際に示しているもの

研究チームは実データに基づくベンチマークを構築した。5つの州DOTの標準設計図から収集した1,898ページを元に、4,056件の質問応答ペアを作成している。事前のファインチューニングを行わないゼロショット検索において、PlanSightRAGは91.47%のRecall@5を記録した。この指標は、ある質問に対してシステムが取得した上位5ページの中に正解となる情報源ページが含まれている割合を意味する。これほど情報密度が高く非構造的な図面において、91%以上の確率で正解を引き当てられるというのは極めて堅実な結果だ。

個人的にさらに説得力を感じた数字は、当初の5州には含まれていなかったミシガン州DOTのホールドアウト（検証用）コーパスで得られた結果だ。Recall@5は91.40%と、分布内（in-distribution）の結果とほぼ同等だった。標準設計図のフォーマットは州ごとに異なる。調整に用いた図面でしか機能しないシステムは、訓練データに含まれていなかったDOTにとってはあまり有用ではない。未知の州の図面フォーマットに対してここまで鮮やかに汎化できているという事実は、このアプローチが単に一握りのレイアウトを暗記しているのではなく、図面を読み解くための一般的な構造を捉えていることを強く示唆している。

論文がより誠実に、そして興味深くなるポイント

適合性チェックの結果については、少し立ち止まって精査したい。見出しに躍る数字には、論文自体が示している「注釈」が必要だからだ。

パラメータ制御によって合成生成された適合性判定用の図面（正解があいまいにならないよう、プログラムで制御された既知の値を用いて作成された図面）において、720億パラメータのVision-Language ModelであるQwen2.5-VL-72Bをベースにしたパイプラインは、100%の判定精度を達成した。しかし、これには明確な前提条件が1つある。照合すべきルールの閾値が、あらかじめ数値としてシステムに与えられている場合、という点だ。言い換えれば、「ここでの許容最大値は6インチである」とモデルに教えれば、図面上の寸法と6インチの比較を毎回正確に行うことができる、ということだ。

これは制御された環境における上限値（ceiling）であり、エンドツーエンドの適合性チェックの実証ではないことを論文も率直に認めている。この結果が示しているのは、モデルが「図面上の数値」と「別の数値」を正しく比較できるということであり、確認できて喜ばしいことではあるものの、タスクの本質的な難所ではない。真に有益な比較対象は、視覚モデルを用いない非VLMのOCRベースラインが、まったく同じセットアップで既に76.4%に達しているという点だ。つまり、このベンチマークのかなりの部分は、図面の幾何構造をまったく理解しなくても、数値を抽出して比較するだけで解けてしまう。76.4%と100%の差は確かに存在するが、「OCR対高度なビジョンシステム」という構図から直感的に想起されるほどの開きではない。論文が「100%」という数値を前面に押し出しているときには、この点を心に留めておく価値がある。

私がこの論文で最も重要だと考える貢献は、末尾に控えめに示されている地味な結果、すなわち自律的なルール根拠付け（autonomous rule-grounding）である。適合性の閾値があらかじめ与えられるのではなく、人間が事前にルールを指示することなく、システムが仕様書コーパスから直接数値基準を抽出する。これこそが、実際の現場における適合性チェックが求めているタスクの姿だ。誰も基準値を手渡してはくれない。仕様書の中から自分でその値を探し出し、図面に正しく適用しなければならないのだ。これは事前に確定した2つの数値を比較するよりもはるかに難易度が高く、実用導入に足るシステムであるためには、まさにこの部分で安定した性能を発揮する必要がある。論文ではこれが機能することを示しているものの、大々的な精度数値は公表していない。そのこと自体が、このコンポーネントがベンチマークとして確立されるまでにはまだ多くの課題が残されていることを雄弁に物語っている。

ドキュメントAIを開発・導入するあらゆる人にとってなぜ重要なのか

工学図面や建築設計図、電気回路図など、「言葉そのもの」ではなく「記号間の空間的関係」に意味が宿る文書を扱うパイプラインを構築しているなら、この論文は肝に銘じるべき鉄則を具体的に提示している。すなわち、「まずOCRにかけてから考えるな」ということだ。テキストへの変換は容易には再構築できない情報を削ぎ落としてしまい、OCR出力に対してどれほど工夫を凝らしたプロンプトを与えてもそれを取り戻すことはできない。

OCRやドキュメントAIのベンダーを評価しているプロダクトチームにとって、ここでの検索精度（Recall@5で91%以上、かつ未知の州の図面フォーマットに対しても維持）は、地図や技術図面、複雑な表を持つ帳票など、人間が「上から下へと読む」ことのないレイアウト主導の文書を扱う際の極めて有益な比較基準となる。ただし、本研究は英語図面のみを対象としており、多くのOCRやVLMにとって最難関となる縦書き配置や漢字・かな混じりの図面が検証対象外である点は、日本の読者や開発者にとって留意が必要なポイントだ。

そして、プレゼン資料で「適合性判定100%」という数値を引用したくなったら、まずは注記をよく読むべきだ。その数字は、あらかじめルールとなる数値を教えられたシステムが検証を行った際のものにすぎない。真の試練は、解答集が与えられないまま仕様書コーパスから自律的にルールを特定する点にあり、これこそが今後注視すべき領域であると同時に、まだ明確な精度数値が出ていない領域でもある。だが、それは論文の価値を損なうものではない。パイプラインのどの部分が実証済みで、どの部分が有望な初期デモ段階にすぎないのかを誠実に明示することは、単一の誇らしいパーセンテージを示すことよりも、実務者にとって遥かに有用なのだ。

まだ何が不足しているのか

いくつか念頭に置いておくべき点がある。このベンチマークの検索精度は5つの州の図面から作成された質問応答ペアのRecall@5に基づいており、幸先の良いスタートではあるものの、全米50州にわたるDOTフォーマットの多様性を網羅するには程遠く、DOTのテンプレートにまったく従わない郡や自治体の基準は言うに及ばない。また、適合性パイプラインは720億パラメータのモデルに依存しており、本番環境で運用するには決して軽量とは言えない。さらに論文には、実際のDOT審査部門が必要とする処理量を現実的にさばけるかどうかを判断するためのコストやレイテンシの数値が報告されていない。そして、合成生成された適合性検証用図面は、クリーンなグラウンドトゥルース（正解データ）を得る合理的な方法ではあるものの、現実のインフラ審査で今なお多く扱われている、手書きの注記が乱雑に入り混じった何十年も前の図面セットに比べれば格段にシンプルである。

だからといって、本手法の根本的なアイデアの価値が損なわれるわけではない。設計図のシートを「文字起こしすべきページ」ではなく「検索すべき画像」として扱うアプローチは、この種の文書に対する直感として極めて正しく、検索結果の数値もそれを裏付けている。適合性チェックに関する側面は、論文の打ち出し方が示唆するよりも初期段階にあるが、その境界線がどこにあるのかを論文自身が清々しいほど明確に示している点は、この分野の多くのベンチマークと比べても大いに評価できる。