エンジニアでもないのにJulian Encisoはなぜ建設入札AIを4週間で形にできたのか

概要

Julian Encisoは、建設入札の比較・評価業務をAIで効率化するKlava AIのソロ創業者だ。Product Hunt上では、自身をベルリン拠点の創業者として紹介し、建設プロジェクト管理の現場で繰り返し聞いた課題を起点にプロダクトを組み立てたと説明している。Klava AIは、契約前文や入札書類を読み込み、見落とされやすい条件差や価格の外れ値を見つけ、発注判断の文書化まで支援する構成を打ち出している。

Julianの経歴が面白いのは、典型的なソフトウェアエンジニア出身ではない点だ。Product Huntの本人プロフィールでは、EYでのファイナンス経験、Enpalでのデータエンジニアリングと自動化の実務、さらにESCP Business SchoolでのBig Data分野の修士課程修了が並ぶ。加えて、同プロフィールでは修士課程でvaledictorianだったこと、2026年5月のDeel Global Startup Pitch Competitionのドバイ地域大会で4万件超の応募から40社のファイナリストに選ばれたことも触れられている。

プロダクトの立ち上がりも速い。Product Huntの投稿では、Julian自身がKlava AIを4週間で構築したと記しており、しかもデモ環境には実案件を模した3つのドイツ建設プロジェクトをあらかじめ載せ、ログイン不要で試せる状態にしていた。単なる構想段階ではなく、触れる形の業務ソフトとして見せにいったことがわかる。

ビジネスモデル

Klava AIの狙いは、ドイツ建設業界のAVAプロセス、つまり設計数量書の作成、入札、比較、発注、さらに後続の変更管理までをAIで再設計することにある。プロダクトページでは、PDF・GAEB・Excelの各形式を取り込み、入札比較や契約リスクの洗い出しを短時間で行う流れを提示している。

顧客像はかなり明確だ。Starterは、設計者が作成した数量書を受け取り、妥当性確認や比較表作成、発注判断を担うプロジェクトマネージャーや発注者側チーム向け。Professionalは、数量書作成から入札・発注まで自前で回す中堅デベロッパーや住宅会社向け。Enterpriseでは、複数案件を並行管理する大手事業者向けに、権限管理や複数案件ダッシュボードまで広げている。

この設計から見ると、Klava AIの収益化はSaaSの階層課金モデルが中心だと考えられる。ただし、現時点でサイト上に価格表は見当たらず、Starterはデモ予約、Professionalはウェイトリスト、Enterpriseは個別導入を想定した導線になっている。つまり、完全セルフサーブ課金というより、初期はデザインパートナーや個別商談を通じて要件を深掘りしながら拡張していくB2B型の立ち上げに近い。

さらに特徴的なのは、「入札比較」だけに閉じないことだ。Klava AIは、契約前文の読み込み、各ポジションとの照合、外れ値検知、欠落項目の指摘、発注メモ生成、さらに後続の変更追跡まで射程に入れている。1機能SaaSよりも、発注者側の調達判断を支える業務基盤として入り込もうとしている点に勝ち筋がある。

収益規模

公開されている収益データは確認できなかった。

確認できたのは、2026年にローンチしたばかりの比較的新しいプロダクトであること、Product Hunt上で57フォロワー、70ポイント、デイリー順位34位を獲得したこと、そしてDeelのThe Pitchではドバイ地域大会の参加対象として掲載されていたことだ。これらは初期の認知指標としては参考になるが、MRRや契約社数、有料導入件数までは読み取れない。

そのため、事業の現段階は「売上規模を語るフェーズ」より、「ニッチだが強い業務課題に対してPoCと初期導入を積み上げるフェーズ」と捉えるのが自然だろう。

学べるポイント

1つ目は、業界知識とデータ処理能力の掛け合わせだ。Julianは建設業界の生え抜きでも純粋なエンジニアでもないが、ファイナンス、業務自動化、データ分析の経験を持っていた。そこに「入札比較はExcelで何日もかかる」「契約前文の読み落としが後の追加請求につながる」という具体的な現場課題を結びつけた。AIプロダクトでは、モデル性能そのものより、どの文書のどの判断を置き換えるかの設計が重要だと示している。

2つ目は、狭いが深い業務に絞ったことだ。Klava AIは一般的な文書AIではなく、ドイツの建設調達で使われるGAEBファイルやAVAフローに寄せている。市場を狭めるように見えて、実際には既存ソフトが古く、しかも判断ミスのコストが高い領域を狙っているため、導入価値を説明しやすい。

3つ目は、ソロ創業でも「完成品らしく見せる」ことを優先した点だ。4週間で作ったMVPでも、実際のユースケースに沿ったサンプル案件、入力形式への対応、比較から文書化までの流れを一続きで見せれば、単機能ツールより説得力が増す。特にB2Bでは、機能数より業務フローの一貫性が評価されやすい。

4つ目は、信頼性の設計を前面に出したこと。Klava AIのサイトでは、EU域内ホスティング、GDPR準拠を意識した構成、監査可能性、顧客データを学習に使わない方針などを明示している。建設や調達のように機密文書を扱う領域では、AIの便利さだけでは導入が進まない。ここを早い段階からパッケージ化しているのは示唆が大きい。

日本での再現可能性

一定の再現余地はある。ただし、そのまま横展開するのは難しく、日本版に作り替える必要がある。

再現しやすいのは課題構造だ。日本でも建設・設備・不動産開発の入札比較、見積精査、仕様差分の確認、契約条件の読み合わせは依然として人手依存が強い。複数社見積の比較表づくりや、条件漏れの洗い出しに時間がかかる点は、Klava AIが攻める論点とかなり近い。

一方で、そのまま移植しにくいのは業務規格と商習慣である。Klava AIはGAEBやドイツのAVA実務に強く寄せているが、日本では見積書の様式、発注方式、原価内訳の粒度、公共調達と民間調達のルールが異なる。したがって、日本で再現するなら「建設AI」よりも、まずは電気設備、空調、内装、修繕工事など、書類形式が比較的そろっている縦市場から入るほうが現実的だ。

また、日本では生成AIの提案精度より、責任所在と説明可能性がより厳しく問われる場面が多い。だから再現モデルの鍵は、全文要約AIではなく、差分検知、根拠箇所の引用、見積比較の半自動化、稟議用メモ生成のような「人が最終判断する前提の補助線」をどう設計するかにある。

要するに、Julian Encisoのモデルは日本でも参考になる。ただし再現すべき本質は、建設向けAIという表層ではない。古い業務ソフトが残り、1件の見落としコストが大きく、文書読解が重い産業を見つけ、そこにAIを業務フローごと差し込む発想こそが移植可能な部分だ。

出典

• https://www.producthunt.com/products/klava-ai
• https://www.producthunt.com/%40julian_enciso
• https://www.producthunt.com/p/klava-ai/solo-founder-built-in-4-weeks-ai-in-construction
• https://www.producthunt.com/contests/the-pitch-dubai
• https://www.deel.com/the-pitch-by-deel/
• https://www.klavaai.com/
• https://de.linkedin.com/in/julianencisoizquierdo