Saisit
848ページに及ぶサウジ建築基準のPDFと2D CAD図面を、自動化された信頼できる適合判定に変えます。
SAISIT
Building Code Compliance
- ルール抽出精度
- 98%
- DWG一致率
- 100%
- 適合チェックエージェント
- 6
- クライアント
- Saisit
- 業種
- 建設テック · サウジアラビア
- 依頼内容
- フルスタックのプラットフォーム + マルチエージェントの適合チェックパイプライン
- ステータス
- 進行中 · MVP統合
- 期間
- 2026年1月〜継続中
- 対応範囲
- 適合チェッカーは稼働中 · アドバイザーと申請図書ジェネレーターはロードマップ上
01 概要
クライアントは誰か
Saisitは、サウジアラビアの建設市場向けの適合チェックプラットフォームです。この国では、あらゆる建築許可で、サウジ建築基準（Saudi Building Code、SBC）への適合を示さなければなりません。SBCは、防火安全、構造に関する要件、避難、MEP（機械・電気・配管などの設備）を扱う法規文書群（SBC 201、301、401、501、601/602、701〜704）です。SBC 201だけで848ページあります。プロダクトの構想は3つのツールを1つにまとめたもので、適合チェッカー（Compliance Checker）、適合アドバイザー（Compliance Advisor）、申請図書ジェネレーター（Submission Generator）からなります。これまでの取り組みは最初の1つに集中しており、残る2つの技術的な土台にもなっています。
このプロジェクト全体を形づくったのは、市場の現実でした。サウジアラビアにはBIMを前提とする義務化の方針がありますが、設計者の大半はいまもAutoCADで作業しています。そのため、プラットフォームはIFC専用にはできません。2DのDWGファイルも受け付け、そこから実際の法規チェックを走らせるのに足りるだけの建物の情報を復元する必要がありました。
02 課題
どんな課題を抱えていたか
建築設計が法規に適合しているかの確認は、いまのところ専門家による手作業です。時間もコストもかかり、同じ図面でも担当者によって結論が分かれるほど、ばらつきがあります。
848ページの法規、構造はゼロ
SBCの文書は、表がぎっしり詰まった長大なPDFです。文書間の相互参照（「per SBC 701 Section 3.2...」）があり、適用条件は文書、節、ルールの3階層に散らばっています。プロジェクトは、建築許可の時点で有効だった版のSBCに照らしてチェックされるため、法規文書群は版管理しておく必要があります。
図面には、チェックに必要なデータがない
3DのIFCモデルには、壁・ドア・空間が明示的に含まれています。一方、2DのDWGにあるのは線と文字だけです。ドアの防火性能は図面のどこにも書かれておらず、建具表（別のPDFのこともあります）にあり、「DR-1000」のような符号でしか図面とつながっていません。
市場の大半は、いまもAutoCADで図面を描いている
サウジアラビアにはBIMを前提とする義務化の方針がありますが、それでもプラットフォームをIFCだけに対応させるわけにはいきません。設計者が実際に作成する2D CADファイルから、建物についての実用的な情報を読み取る必要があります。
ハルシネーションで出たPASSは、ツールがないより悪い
適合判定に大規模言語モデル（LLM）を使うシステムには、わかりやすい信頼性の問題があります。防火に関わるルールで誤った確信を示すのは、機能ではなく責任リスクです。
03 解決策
どう解決したか
いま動いているのは、法規のPDFからインタラクティブな適合レポートまでの一連のパイプラインです。Goのモジュラーモノリスが、gRPC経由で呼び出すPythonの計算ワーカーを統括し、すべてのワークフローはリクエストハンドラーではなくRedisキューで駆動しています。
法規がデータになる。 管理者がSBCのPDFをアップロードすると、Doclingがページと目次を解析します。続いて構造エージェントが文書の構成を把握し、チャンク単位の抽出タスクがレート制限付きのキューコンシューマーで並列に振り分けられます。抽出エージェントと検証エージェントのペアが、ルールごとに本文、適用条件、相互参照、原文上の位置を取り出します。ルールはPostgresに格納され、管理者のレビューと承認を待ちます。パイプラインは最初から最後まで通して動作しており、SBC 201に対する抽出精度は約98%です。
建物がデータになる。 IFCファイルはIfcOpenShellワーカーを通り、トポロジー全体が抽出されます。DWGの抽出はAspose.CADを基盤とし、室、住戸数、ドアと窓の位置と符号、壁厚、階高を取り出します。実際のプロジェクトファイルでAutodesk自身の出力と照合し、100%一致を確認しました。1枚の図面に8種類の建物タイプが含まれるファイルも対象です。
チェックは、1つのプロンプトではなく、エージェントのチームが行う。 適合チェックの実行は、6つの専門エージェントを通って進みます。分類エージェント、ルールローダー、決定的な計算チェッカー、LLMチェッカー、是正提案、集約です。ドラフト → レビュー → 再試行のループが、解釈を要する結果にハルシネーションによる判定が紛れ込むのを防ぎます。指摘事項は、レンダリングしたスクリーンショット付きのPDFレポート、RevitやNavisworksでそのまま開けるBCFファイル（BIMモデル上の指摘事項を共有する形式）、そしてThatOpen/Three.jsで作ったブラウザー上の3Dビューアーを動かすJSONとして返ります。
- GO Go Backend オーケストレーター + キュー chiルーターasynqキューSSEイベント
- PY Python Workers gRPCサテライト IfcOpenShellAspose.CADBlender
- LLM Agent Pipelines 法規 + 適合チェック Geminiドラフト → レビュー → 再試行
- Go
- chi
- Python
- gRPC
- PostgreSQL
- Redis + asynq
- MinIO
- IfcOpenShell
- Aspose.CAD
- Docling
- Gemini
- Next.js
- ThatOpen / Three.js
動作するページ — 再構築したUX、モックデータ駆動
04 プロジェクトの流れ
主なマイルストーンと期間
フェーズ1 2026年1月25日〜2月1日
検証スパイク
いちばんリスクの高い前提から先に検証しました。SBC 201からのルール抽出、実際のチェックに使えるIFCのトポロジー、そして抽出パイプラインの設計です。1月29〜30日のLLM品質スパイクによって、適合チェッカーは判定ゼロの状態から、実際のPASS/FAIL判定を出せるようになりました。
フェーズ2 2026年2月1日〜12日
コアパイプライン
7つのキュー駆動ワーカーを備えたGoのバックエンド、Python製のジオメトリ・レンダリングサービス、6エージェントの適合チェックフロー、PDF/BCFのレポート生成、そして法規の取り込みパイプラインが、最初から最後まで通して動作しています。2月12日までに揃ったものは、APIエンドポイント31個、本番向けのパイプライン2本、3Dビューアー1つです。
フェーズ3 2026年2月12日〜26日
DWG対応
2D CAD対応についての2週間の調査です。実際のサウジのプロジェクトファイルを使い、記録に残したスパイクセッションを9回行いました。最後にLibreDWGからAspose.CADへの切り替えを決め、DWGベースの適合チェックのアーキテクチャを設計しました。
フェーズ4 2026年3月1日〜継続中
UXファーストのMVP再構築
プロダクトの画面をゼロから再設計しました。11のフローグループ、107のユーザーフローを対象に、それぞれスパイク → モック実装 → コードレビュー → 実ブラウザーでの動作確認の順で進めています。3月10日までに11グループすべてを構築・検証済みです。残る作業は、デザインシステムとの整合と、新しいフロントエンドを実際のバックエンドにつなぎ込むことです。
05 直面した壁と対処
どんな壁にぶつかり、どう乗り越えたか
判定を出したがらないLLM
課題パイプラインは最初から最後まで動いていましたが、モデルは解釈ルール62件のすべてでSKIPPEDを返しました。技術的には機能しているのに、実用上は役に立たない状態でした。
解決策重なり合っていた5つの原因を突き止めました。temperatureの制御がない、具体例（Few-shotの例）がない、62件のルールを1回のリクエストに詰め込んでいる、SKIPPEDという簡単な逃げ道がある、要素データが乏しい、の5つです。5つすべてを直したことで、チェッカーは実際に判定を下せるようになりました。
LLMに適合判定を任せてよいか
課題もっともらしいのに間違っている判定だらけのレポートは、自動化がまったくないより悪い結果を招きます。防火や人命に関わるルールでは、なおさらです。
解決策表引きに還元できるルールは、LLMの出番がない決定的な計算チェッカーに通します。解釈を要するルールは、ドラフト、レビュー、再試行の各ステージを通ります。データが不足している場合、プラットフォームはチェックをロックし、強制実行はできません。
DWG対応は、最初のライブラリで頓挫しかけた
課題最初の抽出アプローチは、実際のファイルでは力不足でした。1つのファイルに8種類の建物タイプが入った図面もその一つです。
解決策その場しのぎで回避するのではなく、チームは実際のサウジのプロジェクト図面を使った2週間の構造化されたスパイクを重ねたうえで、Aspose.CADに切り替えました。その出力は、Autodeskの出力とエンティティ単位で照合して検証しています。
848ページのPDFは、LLMに一度では通せない
課題法規文書は1つだけでも分量が多く内容も詰まっているため、1回の処理では確実に抽出できません。さらに、SBC文書間の相互参照も正しく解決する必要があります。
解決策取り込みパイプラインは文書をチャンクに分け、レート制限付きのキューコンシューマーで各チャンクを並列に振り分け、チャンクごとに抽出エージェントと検証エージェントのペアを走らせます。ルールが保存される前に、あるモデルの出力を別のモデルが検証する仕組みです。
非同期システムにおける状態管理の規律
課題ここまで非同期のシステムでは、Goのオーケストレーション、ステートレスなPythonワーカー、UIのリアルタイム更新が入り組みます。どの層が何を持つのかを明確に決めておかないと、状態があちこちに散らばってしまいます。
解決策状態とオーケストレーションはすべてGoが持ち、PythonワーカーはgRPC経由で呼び出されるステートレスな計算処理に徹します。APIがワークフローを直接起動することはありません。リアルタイム更新は、処理ごとに接続を乱立させるのではなく、プロジェクトごとに型付きイベントを流すSSEストリーム1本で届けます。
06 Before / After
プロジェクト前後の状況の比較
| Before | After |
|---|---|
| 法規：848ページのPDF、人が探して参照 | 構造化され、版管理され、クエリできるルール（適用条件・相互参照付き、抽出精度は約98%） |
| ルールのレビュー：専用のワークフローなし | 管理者向けパイプライン：アップロード、抽出の進捗、ルール表、編集と承認 |
| IFCのチェック：専門家による手作業のレビュー | トポロジーの自動抽出 + 6エージェントによる適合チェック |
| DWG対応：実用上、機械で読み取れない | 室、面積、住戸、ドア、窓、壁、階を抽出して検証済み — テストファイルでAutodeskと100%一致 |
| 図面にないデータ：建具表のPDFを手作業で探し回る | 建具表の取り込み（符号の照合付き）、レビュー用ドロワー、質問票へのフォールバック |
| LLMの判定への信頼：未確立 | 可能な限り決定的なチェック、そうできない箇所はドラフト → レビュー → 再試行、データが足りなければ完全にロック |
| 成果物：書面のレビューメモ | レンダリング画像付きのPDFレポート、Revit/Navisworks向けのBCF、指摘箇所をハイライトするインタラクティブな3Dビューアー |
| プロダクトの画面：エンジン先行のプロトタイプUI | 11グループ・107フローを再設計（テナント管理、プロジェクト、不足データ、版管理、実行、ライブラリ、エクスポート、管理） |
07 クライアントにもたらした成果
クライアントはどんな価値を得たか
- 抽出精度
- 98%
- SBC 201に対する実測値、推定ではない
- DWG一致率
- 100%
- 実ファイルでのAutodeskとの一致率
- APIエンドポイント
- 31
- 2026年2月12日時点
- 再構築したUXフロー
- 107
- 11のフローグループ、すべて検証済み
本当に難しいプロダクトの、検証済みの技術的な核
最もリスクの高い2つの主張、つまり、法規のPDFを信頼できる構造化ルールにできること、そして市場が実際に出力する2D CADファイルから使える建物データを抽出できることは、どちらも実際の文書と実際のプロジェクト図面で実証されました。裏づけになっているのは、楽観ではなく、実測した精度です。
長く使える資産は、エージェントのアーキテクチャ
法規の取り込みも適合チェックも、検証ステージを備えた、組み合わせ可能なエージェントパイプラインとして作られています。ロードマップにある適合アドバイザーと申請図書ジェネレーターも、同じルール、同じ抽出済みジオメトリ、同じエージェントを、別の問いに向けて使います。
出力は、業界がいま使っているツールにそのままなじむ
BCFファイルは設計者が日頃使っているツールでそのまま開け、PDFレポートは建築許可の手続きに使えます。3Dビューアーがあれば、BIMを使わない関係者も、指摘事項をモデル上の該当箇所とあわせて確認できます。誰もツール環境を変える必要がないため、導入の壁が低くなります。
属人化しない体制（ナレッジが失われない）
作業セッションはすべて記録され、設計判断はすべて理由とともに残され、スパイクの結果もすべて文書にまとめられています。研究開発色の強い開発では、ここまで文書化を徹底することが、コードと同じくらいの価値を持ちます。
08 得られた学び
このプロジェクトから何を学んだか
不安な部分から先にスパイクする
プロダクト全体を支える2つの前提、つまりルールを抽出できること、図面から情報を抽出できることは、それぞれ1週目と4週目に、大きな投資をする前に検証しました。DWGのスパイクで採用するライブラリが変わりましたが、6か月目ではなく4週目に分かってよかったです。
LLMの出来が悪いときは、地味なところから点検する
すべてSKIPPEDになった失敗は、モデルの限界ではありませんでした。temperature、プロンプトの構造、バッチサイズ、SKIPPEDという簡単な逃げ道、乏しい入力データが重なっていたのです。一つひとつの修正は小さく、大変だったのは修正ではなく原因の特定でした。
表引きで済むことをLLMにやらせない
決定的なルールと解釈を要するルールを分けたことで、ハルシネーションが起こりうる範囲そのものが縮まり、残ったLLMの判定を守るためのコストも下がりました。
自信ありげなノイズより、正直な「判定不能」
十分なデータのない法規をロックし、上書きもできないようにすることは、技術上の判断ではなくプロダクトの判断です。それが、適合チェックツールと、責任リスクの塊とを分ける線になります。
「モックを仕様にする」は立派な方法論
モックデータでUXを作り直し、「すべてのモックはそのままAPI仕様になる」という取り決めを明示しました。これにより、バックエンドが止まっている間も設計を前に進められ、バックエンドの要件も推測ではなく実際の画面に基づいて固められました。
すべて書き残す
セッションログ、設計判断の記録、スパイクの結果が残っているので、数十回の作業セッションにまたがるプロジェクトでも、なぜその選択をしたのかを誰か一人の記憶に頼らずに済みました。
実際の動き方 · キューからキューへ
パイプライン
プラットフォームを動かす流れは2つあります。法規が構造化ルールになる流れと、建物がそのルールに照らしてチェックされる流れです。
- 01 PDFアップロード 管理者がSBCの法規文書をアップロード
- 02 Docling解析 ページと目次を抽出
- 03 構造エージェント 文書 → 節 → ルールの構造を把握
- 04 チャンク抽出 レート制限付きのキューで、チャンクごとに並列に振り分け
- 05 抽出・検証 エージェントのペアが各ルールを抽出し、相互に検証
- 06 管理者レビュー 承認または編集 — SBC 201に対して精度98%
- 01 分類エージェント この建物に適用されるルールを判定
- 02 ルールローダー 適用されるルールと条件を読み込む
- 03 計算チェッカー 決定的な表引き — LLMの出番はない
- 04 LLMチェッカー 解釈を要するルールはドラフト → レビュー → 再試行
- 05 是正提案 不適合を、優先順位つきの是正アクションに変える
- 06 集約 PDF、BCF、3Dビューアー用の出力をまとめる
実装済みの画面 · モックデータ駆動で動作する、再設計後のUX
製品
プロジェクトへのログインからプラットフォーム管理まで、ここに並ぶ画面はすべて、実際に動いているアプリの画面そのものです。クリックすると拡大します。
