30年の内装業を、AI建設商社に変える挑戦 | 開発ジャーナル

なぜ30年のベテランがコードを書き始めたのか

内装業を営んでいる。しかし、この業界には根深い非効率が蔓延している。

建設業界の「理不尽な構造」

1. 多重請負の闇

元請→一次下請→二次下請→職人
各階層で20-30%のマージンが抜かれる
末端の職人は利益が出ない、元請は現場を知らない

2. 情報の非対称性

見積もりは「経験と勘」
材料単価は業者ごとにバラバラ
顧客は適正価格が分からない

3. アナログ地獄

図面はPDF、やり取りはFAX
積算はExcel手作業
進捗管理はホワイトボード

そして気づいた。

「これ、全部AIで解決できるのでは？」

作ろうとしているシステム

「AI建設商社」構想

目標： 一人で大手ゼネコン並みの処理能力を実現する

実現したい機能

案件受信 → 30分で設計提案+見積書
図面解析 → 自動積算
協力業者マッチング
進捗管理の自動化

現在の技術スタック

n8n（Railwayでセルフホスト）
Claude API (Sonnet 4.5)
データベース（検討中：Airtable? Supabase?）
PDF生成（未実装）

つまづいている壁

1. データ構造の設計

建設業特有の複雑さをどうモデル化するか。

「案件」「見積もり」「材料」「業者」の関係性
多重請負構造をどう表現するか
法規制（建築基準法、消防法）のチェック

2. n8nワークフローの最適化

Claude APIを何回呼ぶべきか
メモリ機能をどう実装するか
コスト効率と精度のバランス

3. 過去データの活かし方

過去の見積もりデータ（Excel）
これをどうDB化してAIに学習させるか
類似案件の検索と参照

今週の試行錯誤

実装したこと

最小構成ワークフロー：

[Webhook受信]
  ↓
[Claude API] 案件解析
  ↓
[Claude API] 見積書生成
  ↓
[Email送信]

テストケース：

エリア：東京都千代田区丸の内
施工面積：54.93坪（181.5㎡）
内容：オフィス拡張、間仕切り撤去、レイアウト変更

結果：

処理時間：30分
粗見積もり：1,200-1,850万円
提案書：A4で20ページ

うまくいったこと

案件情報の自動抽出（エリア、面積、工事種別）
設計コンセプト案の自動生成（3パターン）
工事項目の分類と単価計算

課題

精度が甘い：材料単価DBがないため、AIが推測で積算
類似案件参照ができない：過去案件との比較機能未実装
法規制チェックなし：建築基準法、消防法の自動確認が必要

なぜ諦めないのか

1. 業界を変えたい

下請け構造で苦しむ職人を見てきた。情報格差で損をする顧客を見てきた。

「技術があれば、この理不尽は解消できる」

2. 「一人で大手並み」の可能性

AIとn8nがあれば、組織の規模ではなく、 **「仕組みの精度」**で勝負できる時代が来た。

3. 失敗してもいい

本業は残る。でも、挑戦しないまま終わるのは嫌だ。

次のステップ

短期（今月中）

材料単価マスタの構築（Airtableで）
過去案件DB化（Excel → 構造化データ）
類似案件検索機能

中期（3ヶ月）

3Dパース自動生成（Stable Diffusion連携）
協力業者マッチング
工程表自動作成

長期（1年）

完全自動化（案件受信→提案→契約→施工管理）
他社への展開（SaaS化）

コミュニティの力を借りたい

技術的なアドバイスや、「うちでも似たようなことやってるよ」という方がいれば、ぜひお話ししたいです。

特に：

n8nの複雑なワークフロー設計の経験
建設業界のデータ構造に詳しい方
AI活用で業界を変えようとしている仲間

本質的な課題に向き合う人と、熱い議論がしたい。

技術スタック詳細

自動化プラットフォーム:
  - n8n (Railway)
  - Webhook受信

AI/LLM:
  - Claude API (Sonnet 4.5)
  - GPT-4 (比較検証用)

データベース:
  - 検討中: Airtable, Supabase, PostgreSQL

ドキュメント生成:
  - 検討中: PDF生成API

画像生成:
  - 検討中: Stable Diffusion, DALL-E

開発環境:
  - Claude Code
  - Git/GitHub

コスト試算

従来の手作業

所要時間：8-16時間/件
人件費換算：4-8万円/件

AI自動化後

Claude API利用料：約350円/件
処理時間：30分
人的作業：最終チェックのみ（10分）

コスト削減：約1/100

学びと気づき

AIを使ってわかったこと

プロンプトの重要性：指示の精度が結果を左右する
データ構造が全て：良い設計なくして良いシステムなし
完璧を目指さない：まず動くものを作る

建設業界の特殊性

暗黙知の多さ：「普通」「いい感じ」が通じる世界
標準化の難しさ：案件ごとに条件が異なる
人間関係重視：技術だけでは解決できない部分

最後に

この記事を書いたのは、同じ熱量で「本質的な課題」に向き合っている人と出会いたいから。

AIの可能性を信じて、業界の非効率と戦っている人。技術で社会を変えたいと本気で思っている人。

そんな方々と、一緒に未来を作りたい。

「一人ゼネコン」の実現まで、あと何マイル。