データセンターから産業プラントなど、特注建設部材を担うBALLAS

株式会社BALLASはデータセンター・産業プラント・製造工場・商業ビルなどの社会インフラを支える施設向けに、配管サポート・下地材・ガード・架台・点検台・手すりなどの特注建設部材を提供しています。現場ごとに異なる寸法や施工条件にあわせて、一つひとつ設計・製造する「特注領域」を専門としています。

24兆円の建設業の調達市場が抱える分断の課題

75兆円の建設業で3分の1を占める調達市場は、約24兆円と言われています。需要側の建設工事会社と、供給側の製作工場の間に存在する、巨大サプライチェーンです。

これほど大きな市場でありながら、いまなおファックスや紙、メール・電話を中心としたアナログな業務が数多く残っています。

その背景には、設計・積算・製造・施工という工程ごとの「分断」があります。設計は設計会社、製造は製造工場、施工は施工会社と、それぞれ異なる企業が担うため、情報が工程をまたぐたびに分断され、手戻りやコミュニケーションが発生しています。

BALLASは、各工程を個別に最適化するのではなく、サプライチェーン全体をデータでシームレスにつなぐことを目指しています。その中核となるのが、「モジュール」という概念です。

モジュール化で作図・購買プロセスを連動させる

サプライチェーン全体を連動させるために、2つのプロダクトを開発しています。需要側（建設工事会社様）向けの案件マネジメントツール「LINKS」と、供給側（パートナー工場様）向けのモジュール駆動業務ツール「SCM」です。

ビジネスモデルとしては、建設工事会社とパートナー工場をデータでつなぎ、作図・購買プロセスを標準化することで、発注側のQCD向上と供給側の稼働率向上を実現し、サプライチェーン全体の供給力向上につなげています 。 単に仲介するのではなく、データを介して三者が価値を高め合えるプラットフォームを構築していることが特徴です。 その基盤となる考え方が「モジュール」です 。ソフトウェア開発で共通処理を関数として切り出すように、作図業務を「変数」「定数」「ロジック」に分解し、再利用できる形へ構造化します。

ロジックと定数は共通化し、案件ごとに異なる変数だけを入れ替えることで、毎回ゼロから設計・作図する必要がなくなります。BALLASでは、この再利用可能な単位を「モジュール」と呼んでいます。このモジュールを実現するためには、設計や作図に関する知識・判断を、人ではなく「コードで扱える形」へ変換する必要があります。それが本日のタイトルで「AI Nativeな建設業」 につながっています。

図面の暗黙知をAIに渡す：5ステップパイプラインの設計

AI活用の1つ目のテーマは、図面解析による積算・見積もりの半自動化です。図面をアップロードすると構造化データへ変換され、積算パラメーターを適用した見積もりの叩き台が2分程度で生成されます。

従来は、担当者が図面を読み取り、必要な材料や寸法、加工内容を整理したうえでExcelにまとめ、積算・見積もりを行っていました。 現在は、この一連のプロセスを半自動でできるようになっています。

一方で、 実現するまでには多くの試行錯誤がありました。 最大の課題は、「図面には書かれない暗黙知」をAIにどう扱わせるか、という点です。

私たちが、直面したのは4種類のバイアスでした。
1つ目が「見たままバイアス問題」です。図面に「155」と書かれていても、熟練者は規格を踏まえて「H-148」と補正できます。 しかしAIは、素直に「155」と認識してしまいます。
2つ目が「近傍バイアス問題」です。近くにある無関係な数値を、対象の値として誤認してしまいます。
3つ目が「整合性欠如問題」です。外々550・幅100・内々85」のように、物理的に成立しない数値の組み合わせでも矛盾を検知できないのです。
そして、4つ目が「シンボルグラウンディング問題」です。破線を実在する線として認識し、誤って寸法を取得してしまうのです。

当初は、生画像をそのままLLMに渡し、「図面を理解してほしい」というアプローチを採っていました。 しかし期待した精度は得られず、設計思想そのものを見直すことになりました。

そして、辿り着いたのが、「LLMの性能で解くのではなく、 構造とドメイン知識を渡す」という考え方です。精度向上の要因を振り返ると、約8割はドメイン知識の設計、残りの約2割が画像処理の改善でした。つまり、精度を決めるのはLLMそのものではなく、AIが理解できる形でドメイン知識を設計できるかどうかだったのです。

この考え方をもとに、現在は以下の5ステップのパイプラインを構築しています。

STEP1の画像変換では、PDFを高解像度画像へ変換する。
STEP2のOCRでは、HSV判定で手書き文字を識別しながら文字を抽出し、各テキストへ4桁のハッシュIDを付与する。
STEP3の線分検出では、LSDで寸法線や引き出し線を抽出し、OCR領域をマスクして線のみを抽出。さらに、Union-Findで1本の線として統合する。
STEP4の中間生成では、SoM画像とトポロジー情報を生成する。
そして、STEP5でLLMに画像・構造データ・ドメイン知識を入力し、スキーマ化された結果に加えて、根拠・確信度・疑義をセット出力する。

さらに、ドメイン知識そのものもAIとともに進化させています。

・Plan：JIS規格、読図ルール、検算式をプロンプトとして整理する
・Do：5ステップパイプラインで推論する
・Check：低スコア項目をLLMになぜ間違えたか分析させる
・Action：LLMが発掘した暗黙のドメイン知識をプロンプトへ反映する
このPDCAサイクルを繰り返すことで、人間も明文化できていなかった暗黙知が徐々に言語化・蓄積され、AIだけでなく組織全体の知識試算として活用できるようになっています。

開発プロセス自体もEnd to Endでつなぐ

2つ目のテーマは、プロダクト開発プロセスそのもののモジュール化です。

設計・積算・製造・施工という建設業のサプライチェーンを抽象化すると、要件定義・見積・開発・テストというソフトウェア開発と、驚くほどよく似た構造を持っていることに気づきました。どちらも工程ごとに担当者が分かれ、その境界で情報が分断されるという共通の課題を抱えています。

ソフトウェア開発でも、要件定義はPdM、見積もりはテックリード、開発はエンジニア、テストはQAがと役割が分かれている。その結果、前工程で生まれた情報や意図が十分に引き継がれず、手戻りやコミュニケーションコストが発生します。

BALLASは、この課題を各工程ごとのツール導入で解決するのではなく、開発プロセス全体をEnd to Endで接続・自動化するアプローチを採っています。すべてのドキュメントをNotion上に集約し、それらをAIが横断的に活用できるよう設計しています。要件定義から単体テストまで、前工程の成果物が次工程にシームレスに受け渡される仕組みを構築しています。

この取り組みは、2025年から開始し、現在では約1.5倍の生産性向上を確認しています。今後は、各工程をAIエージェントが自律的に連携し、人が介在しなくても開発プロセス全体が繋がる世界を目指しています。

仕組みは作れた、文化はこれから

ここまで紹介してきたように、AIを活用するための仕組みは、少しずつ形になってきました。しかし実感しているのは、仕組みを作ること以上に、それを組織へ根付かせることの方がはるかに難しいということです。

せっかく仕組みを整えても、それを十分に活用できるメンバーはまだ限られています。AIは一度作れば終わりではなく、チーム全員がフィードバックサイクルに参加して初めて精度が向上し、よりよい仕組みへと進化していきます。

目標を立て、仕組みを活用し、より良い方法を考え、フィードバックを通じて改善を続ける。このサイクル自体を組織の日常にしていくことが重要です。しかし、エンジニアにはこれまで培ってきた仕事の進め方があり、その習慣を組織の文化としてアップデートしていくことこそが、AI活用における最も難しい課題だと感じています。

私たちは、図面や設計に潜む暗黙知を構造化し、AIが扱える形へ変換することに取り組んでいます。そして、これからは、ドメインの暗黙知だけでなく、組織の暗黙知や仕事の進め方そのものも構造化し、AIと人がともに学び続けられる組織を作っていきたいと考えています。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
AI Engineering Summit Tokyo 2026
※動画の視聴にはFindyへのログインが必要です。