建設コンサル向けに「ローカルAIナレッジ検索・報告書支援」の構想を練ってみた - その１-

はじめに

建設コンサルタント業務では、過去報告書、仕様書、技術基準、ガイドライン、Excelの条件表、GIS関連資料、その他参考資料など、参照すべき資料が非常に多くあります。

一方で、これらの資料には案件情報や発注者資料など、外部の生成AIサービスにそのまま入力しにくい情報も含まれます。

そこで、第1段階として、ローカル環境で動作するRAGと報告書作成支援のデモを検討しています。

この記事では、実装の細部ではなく、

何を作るのか
なぜローカルで動かすのか
どのような構成にするのか
どの順番でデモ化するのか

を中心に整理します。

今更、遅いかもしれませんが、今後のために整理してみました。
また、構想をもとに、ちゃっちゃっとデモ作成してみようと考えています。

作りたいもの

構想しているものは、次のようなパッケージです。

建設コンサル向けローカルAIナレッジ検索・報告書支援パック

主な目的は、社内やローカルサーバー上にある技術資料を検索し、根拠付きで回答し、その結果をもとに報告書本文のたたき台を作ることです。

対象資料としては、将来的に以下を想定しています。

過去報告書
業務仕様書
特記仕様書
設計書
技術基準
ガイドライン
Excelの計算条件表
GIS関連資料
打合せ記録
解析条件資料
参考資料
貸与資料

最初から社内の機密資料を使うのではなく、まずはネット上で公開されている技術基準PDFやガイドラインPDFを使ってデモを作成します。

なぜローカル実装にするのか

建設コンサル業務では、資料の性質上、クラウド型AIにすべてを投げるのは難しいケースがあります。

ローカル実装にすることで、以下のようなメリットがあります。

資料を外部サービスに送信しない
社内LAN内で完結できる
顧客ごとにサーバーを分離できる
発注者資料や過去成果品を扱いやすい
将来的にGISや解析プログラムとも連携しやすい

そのため、今回は**Ubuntu 24.04で動作するLinux Server込み（ハードウェア）**の構成を前提にしています。

全体構成イメージ

構成は、できるだけシンプルに考えます。

利用者はブラウザからアクセスします。
サーバー側では、ローカルLLM、RAG検索、ベクトルDB、PDF解析処理などを動かします。

利用技術の候補としては、以下のような構成を想定しています。

区分	候補
OS	Ubuntu Server 24.04
LLM実行	Ollama など
チャットUI	Open WebUI など
ベクトルDB	Qdrant など
API	Python / FastAPI など
文書処理	Python系ライブラリ
対象文書	PDF、Excel、GISメタデータ等

ここでは詳細な設定手順までは書きませんが、まずはOSSを組み合わせて小さく動かし、その後に業務向けの機能を追加していく方針です。

第1段階のデモ範囲

第1段階では、社内文書ではなく、公開されているPDFを使います。

例えば、以下のような資料です。

国や自治体が公開している技術基準
防災・砂防・河川分野のガイドライン
治山・森林土木関連の技術資料
公開されている調査・設計の手引き

この段階で確認したいことは、次の5つです。

PDFをローカルサーバーに登録できること
PDFの内容を検索できること
回答に根拠資料を付けられること
検索結果をもとに報告書風の文章を作れること
外部APIを使わずに処理できること

ここまで確認できれば、次の段階として社内文書や案件資料を使ったPoCに進めます。

デモで見せたい操作

デモでは、複雑な機能を詰め込みすぎず、以下のような流れにします。

1. 技術基準を検索する

質問例です。

河川・砂防分野の技術基準における維持管理の考え方を整理してください。
根拠資料も示してください。

AIは、登録済みPDFから関連箇所を検索し、資料名やページ番号を添えて回答します。

2. 複数資料を横断して整理する

土砂災害に関する基礎調査の目的と、調査で確認すべき事項を整理してください。

単一のPDFだけでなく、複数の公開資料から関連箇所を拾い、整理できることを見せます。

3. 報告書ドラフトを作成する

上記の内容をもとに、報告書の「関連基準の整理」節のたたき台を作成してください。

最終的な文章は人が確認・修正する前提ですが、報告書作成の初動を短縮できることを示します。

段階的なシステム構築の進め方

Phase 0：デモ設計

まず、何を見せるデモにするかを決めていきます。

対象分野を決める
使う公開PDFを選ぶ
デモ用の質問を作る
成功条件を決める

最初は「河川・砂防・土砂災害」など、対象を絞った方が分かりやすいです。

Phase 1：ローカルAIサーバーを準備する

Ubuntu 24.04のLinux Serverを用意し、ローカルLLMや検索基盤を動かす環境を作ります。

この段階では、過度に作り込まず、まずは以下が動けば十分だと考えます。

ブラウザからチャットできる
ローカルLLMが応答する
PDF検索用のDBが起動する
外部APIを使わずに動作する

Phase 2：公開PDFを登録する

公開されている技術基準PDFやガイドラインPDFをローカルに保存し、検索できる形に変換します。

ここで重要なのは、単に文章を取り込むだけでなく、以下のような情報を持たせることです。

PDF名
ページ番号
章や節の情報
文書分類
出典情報

建設コンサル業務では、回答そのものよりも、根拠資料に戻れることが重要になります。

Phase 3：根拠付き回答を作る

RAGの回答では、AIに自由に答えさせるのではなく、検索された資料をもとに回答させます。

回答では、次のようなルールを重視します。

根拠資料にないことは断定しない
資料名とページ番号を示す
推測が必要な場合は明記する
技術報告書で使える落ち着いた文体にする

この段階で、単なるチャットAIではなく、技術資料検索AIとしての見せ方になります。

Phase 4：報告書ドラフトを作る

検索結果をもとに、報告書の一節を作成します。

最初に対象とする章は、以下のようなものが向いています。

関連基準の整理
既存資料の整理
使用資料の整理
検討条件の整理

いきなり結論や考察を自動生成するのではなく、まずは根拠資料に基づいて比較的安全に書ける部分から始めます。

Phase 5：デモとして整える

最後に、営業や説明で見せられるように、操作シナリオを整えます。

例えば、以下のような流れです。

公開PDFが登録されていることを説明する
技術基準について質問する
根拠付き回答を表示する
複数資料を横断して整理する
報告書の一節をドラフト生成する
将来的に社内文書・Excel・GISへ拡張できることを説明する

デモで見せるポイントは、派手な自動化よりも、ローカルで安全に技術資料を活用できることです。

最初からやりすぎないこと

第1段階では、あえて対象を絞ります。

最初から以下まで入れると、デモが重くなりすぎます。

全社NASの一括クロール
複雑な権限管理
OCR付き大量PDF処理
Wordの完全自動整形
GISデータの本格解析
QGISの自動操作
解析プログラムの実行管理

これらは重要な機能ですが、第2段階以降で追加する方がよいと考えています。

将来的な拡張

第1段階のデモができたら、次は以下のような拡張が考えられます。

特に建設コンサル業務では、Excel条件表や関連資料の扱いが重要になってきます。どこまで関係資料として取り込むのかも検討する必要があります。
将来的には、GISアプリや解析プログラムとの連携も視野に入れるように考えておきます。

まとめ

今回は、建設コンサル向けに、ローカル環境で動作するAIナレッジ検索・報告書支援の構想を整理しました。
単純に検索してその関連箇所を表示するのではなく、質問に的確に回答できるAIとしての位置づけと考えています。

第1段階では、まず公開PDFを使って、以下を確認します。

ローカルサーバー上でPDFを検索できる
根拠付きで回答できる
報告書本文のたたき台を作成できる
外部APIを使わずに動作できる

この仕組みができると、次の段階では社内の過去報告書、仕様書、Excel、GIS関連資料を対象にしたPoCへ進められます。

最終的には、Linux Server込みのオンプレミス型パッケージとして、建設コンサル、測量会社、地質調査会社、自治体向けに展開できる可能性があります。
この資料が、どなたかの参考にでもなれば。。。

補足

この記事では、あえて詳細な実装手順やプロンプト、スクリプト構成までは書いていません。
まずは構想と段階的な進め方を整理し、今後の検証結果に応じて、実装面の記事も分けて書いていく予定です。