詳細設計が噛み合わない？整合の取れた有料道路DEDをつくる方法

インドネシアの有料道路工事を請け負う施工会社のチームで、次のような場面は十分に起こり得ます。橋脚の基礎工事に着手する準備が整いました。ところが現場チームが構造図と最新の排水図を突き合わせると、ボックスカルバートがパイルキャップの範囲をそのまま横切っています。別のチームが使っている埋設物図には、同じ場所にまだ移設されていないケーブルルートが描かれています。図面は一枚ずつ見れば正しく見えます。重ね合わせたときに初めて問題が表面化するのです。

注：上記は仮想の例であり、特定のプロジェクトやクライアントで実際に起きた出来事ではありません。

本記事では、有料道路の詳細設計（Detail Engineering Design、以下DED）で図面の詳細がなぜ噛み合わなくなるのか、その根本原因は何か、そして最初から整合の取れたDEDをつくるにはどうすればよいかを整理します。設計コンサルタントからDEDを受け取る場合も、設計施工（Design and Build）方式で自らDEDを作成・精緻化する場合も、考え方は共通です。

要約

問題。 有料道路のDEDでは、線形、舗装、排水、構造、埋設物、用地境界などを異なる分野が異なる改訂サイクルで作成します。その結果、幾何学的な干渉、高さの不一致、図面と数量の食い違いが生じます。

主な原因。 データの一元的な情報源がない、座標系や基準面が統一されていない、ファイル命名や文書ステータスのルールがない、分野間の調整が遅い、図面発行前の明確な品質確認の関門がない、といった点です。

中核となる解決策。 早い段階で情報要件と実行計画（BEP）を定めます。共通データ環境（CDE）で文書をステータス付きで管理します。座標系と命名を統一します。各分野のモデルを統合して定期的に干渉チェックを行います。インターフェース台帳と記録付きの調整会議で境界部を管理します。発行前にQAの関門を設けます。

重要な限界。 BIMやソフトウェアを導入するだけで、調整不足の設計が自動的に解決するわけではありません。成果は、プロセスの規律、責任範囲の明確さ、入力データの品質に左右されます。

有料道路のDEDとは

DED（詳細設計） とは、入札と施工にそのまま使える技術文書を作成する詳細な設計段階を指します。一般的には、施工図、技術仕様書、設計計算書、数量内訳などが含まれます。用語や成果物の範囲は発注者によって異なるため、最終的な拠り所は業務仕様書（インドネシアでは「KAK」と呼ばれます）と契約書です。

有料道路のDEDは、多くの分野を同時に扱います。幾何構造（平面線形・縦断線形）、舗装、排水、構造物（橋梁、アンダーパス、カルバート、擁壁）、地盤、埋設物、道路付属施設、用地（ROW）などです。これらは同じ物理的空間を共有するため、ある分野の変更はほぼ必ず他の分野に影響します。

問題の特定：詳細設計の不整合とはどのような状態か

不整合は、大きな一つのミスとして現れることはまれです。多くの場合、小さな指摘事項の連続として、施工段階になって初めて見つかります。よくある兆候は次のとおりです。

• 排水路の底高が、他の図面の放流先高さや地盤高と合わない。
• 構造物の基礎が、水路、管、地下埋設物と干渉する。
• 平面図か断面図のどちらかを改訂した後、両者が一致しなくなる。
• 数量内訳書の数量が、最新図面から再計算した数量と異なる。
• 複数の図面バージョンが各チームに出回り、どれが有効か分からない。
• 根本原因が解消されないため、同じ場所について同じ質問（RFI）が繰り返される。

影響を受けるのは多くの関係者です。改訂を迫られる設計者、確認待ちの施工技術者、作業を止める現場、数量を再計算する積算担当、遅延を説明するプロジェクトマネージャーなどです。伴うリスクは、工程（作業の遅れ）、コスト（手戻りとクレーム）、品質（現場での場当たり的な対応）、調整（責任範囲をめぐる対立）に及びます。

根本原因の分析

問題を解決するには、症状と原因を切り分ける必要があります。情報の流れに沿って整理すると、可能性の高い根本原因は次のとおりです。

1. データの情報源が一つではない。 分野ごとに独自のファイルとバージョンで作業することが少なくありません。唯一の正式な保管場所がなければ、全員が同じデータを使っている保証はありません。

2. 座標系と基準面が統一されていない。 あるチームが現地座標を使い、別のチームが異なる座標系を使えば、モデルや図面は正しく重なりません。インドネシア公共事業・国民住宅省の道路総局（Bina Marga）のBIM通達に従うプロジェクトでは、モデリング座標はSRGI2013を参照することとされています。

3. 命名と文書ステータスのルールがない。 命名規則やステータス（例：作業中、共有、発行）がなければ、草案と承認済み図面の区別が難しくなります。

4. 調整が遅い。 分野間の確認が図面発行の直前にしか行われないと、多くの図面が互いに依存している段階になっているため、指摘事項の修正コストが高くなります。

5. 分野の境界で責任が曖昧。 構造物の下を通る排水や、用地を横切る埋設物といった境界部の要素は、どの分野の担当かが明確でないことがよくあります。

6. 2D図面と数量が別々に動く。 数量を図面から手作業で算出すると、図面を改訂するたびに再計算されるとは限りません。

7. QAの関門がない。 分野間の整合を確認するチェックリストなしに、図面が発行されます。

Key Takeaway： 不整合の症状のほとんどは、単なる作図ミスではなく、プロセスとデータの問題に由来します。したがって解決策も、ソフトウェアだけでなく、プロセスとデータに踏み込む必要があります。

解決策と実施戦略

段階的に導入できる七つのステップを紹介します。各ステップについて、何をするか、なぜ必要か、どう進めるか、誰が関与するか、期待される成果、限界を示します。

解決策1：情報要件と実行計画を早期に定める

内容と理由。 各分野から、どの情報を、どの形式で、いつ必要とするのかを決めます。これがないと、各チームが納品物を独自に解釈してしまいます。

進め方。 BIM実行計画（BIM Execution Plan、BEP）を作成します。役割、ソフトウェアとバージョン、交換形式、命名規則、詳細度、情報交換のスケジュールを盛り込みます。Bina Marga通達第11/SE/Db/2021号の対象プロジェクトでは、受注者に入札時BEPとプロジェクトBEPの作成が求められています。

関与者。 プロジェクトマネージャー、BIMマネージャー（コーディネーター）、各分野の代表者です。

期待される成果。 全員が同じ期待値から出発できます。

限界。 長すぎて誰も読まないBEPは役に立ちません。簡潔にまとめ、範囲が変わったら更新します。

解決策2：共通データ環境（CDE）で文書を管理する

内容と理由。 CDEとは、プロジェクト情報の唯一の情報源となる共有デジタル作業空間です。重複バージョンを減らし、各ファイルのステータスを明確にすることが目的です。

進め方。 一貫したステータスのワークフローを使います。上記のBina Marga通達には、たとえば「作業中」「共有」「発行」「保管」というフォルダ区分と、情報を共有する前の確認・レビュー・承認（Check、Review、Approve）機能が記載されています。この考え方は、ISO 19650の情報マネジメントの枠組みとも整合します。

関与者。 情報コーディネーター、各分野のリーダー、発注者側の承認者です。

期待される成果。 バージョンと承認の履歴が明確になり、古い図面が現場に出回ることが減ります。

限界。 CDEはチーム全員が実際に使って初めて機能します。ファイルが別の経路で流れ続ければ、効果は失われます。

解決策3：座標系、基準面、命名を統一する

内容と理由。 モデルと図面は、同じ基準を共有していて初めて重ね合わせられます。

進め方。 すべての分野で単一の座標系と基準面を定め、測量の基準点も共有します。たとえば、プロジェクトコード、分野、ゾーン、階層または位置、ファイル種別を含む命名規則を決めます。Bina Margaのガイダンスにも、この種の命名パターンが示されています。

関与者。 測量担当、BIMコーディネーター、すべてのモデル作成者です。

期待される成果。 異なる分野のモデルがずれなく統合でき、ファイルも探しやすくなります。

限界。 新しい規則は最初は負担に感じられます。導入しやすいようテンプレートを用意します。

解決策4：統合モデルと定期的な干渉チェックを活用する

内容と理由。 すべての分野のモデルを一つの統合モデルにまとめれば、干渉を現場ではなく画面上で見つけられます。

進め方。 主要な情報交換のたびなど、定期的にモデルを統合します。どの分野をどの分野と照合するかを定めた干渉マトリクスを作ります。干渉の重要度はすべて同じではないため、許容値と優先度を設定します。指摘事項は、ハードクラッシュ（二つの要素が同じ空間を占める）、ソフトクラッシュ（離隔が不足している）、ワークフロー上の干渉（施工手順が矛盾する）に分類します。

関与者。 BIMコーディネーターが推進役となり、各分野のモデル担当者が指摘事項を解決します。

期待される成果。 担当者と対応状況が付いた、追跡可能な指摘事項の一覧が得られます。

Important Alert： 干渉チェックの結果は、必ず人が確認する必要があります。ソフトウェアは数百件の干渉を報告することがあり、その中には技術的に無関係なもの（たとえば鉄筋とそれを包むコンクリートの重なり）も含まれます。絞り込みと優先順位付けをしなければ、チームは対応しきれなくなります。

限界。 干渉チェックは、モデル化された形状しか調べられません。モデル化されていない要素は検出されず、設計の技術的な妥当性は設計者が確認する必要があります。

解決策5：インターフェース台帳と調整会議で境界部を管理する

内容と理由。 多くの問題は分野の境界で起こります。インターフェース台帳を作れば、すべての接点に担当者が付きます。

進め方。 場所（たとえば排水と構造物が交わる地点）、関係する分野、必要な決定事項、担当者、期限を記載したインターフェース台帳を作成します。一般的なプレゼンではなく、指摘事項に焦点を当てた調整会議を定期的に開きます。課題は追跡可能な形式で記録します。ソフトウェアが対応していればBCF（BIM Collaboration Format）、そうでなければ簡易的なチケット管理で構いません。

関与者。 コーディネーター、各分野のリーダー、現場の代表者、必要に応じて埋設物の管理者や地権者です。

期待される成果。 会議の参加者の記憶に頼らない、記録された意思決定が残ります。

限界。 フォローアップのない会議は負担を増やすだけです。すべての課題を明確なステータスで完了させます。

解決策6：モデルを図面と数量に連携させる

内容と理由。 図面と数量が同じモデルから導かれていれば、一箇所の変更が他の箇所にも反映されやすくなります。

進め方。 オブジェクトに必要な属性（材料種別や寸法など）を定め、モデルからの数量算出を手計算の照合に使います。Bina Marga通達は、対象プロジェクトでは概算費用の数量をBIMオブジェクトの数量拾い出しから取得すると述べています。

関与者。 設計者、積算チーム、BIMコーディネーターです。

期待される成果。 数量の食い違いを早く発見できます。

限界。 成果は属性の網羅性とモデリングの規律に左右されます。見た目の確認のためだけに作ったモデルは、数量の根拠にはなりません。日本の国土交通省のBIM/CIM取扱要領（案）も、モデルを細かく作り込みすぎて、モデル作成自体が目的化しないよう注意を促しています。

解決策7：情報を発行する前にQAの関門を設ける

内容と理由。 QAの関門は、すべての図面リリースが標準的な確認を通過していることを保証します。

進め方。 次の項目を含むチェックリストを用意します。座標系と基準面が正しい。優先度の高い干渉が解消済みである。図面がモデルと一致している。命名とステータスが適切である。数量を照合した。改訂履歴が揃っている。このチェックを通過して初めて、パッケージを「発行」ステータスに移します。

関与者。 作成者とは独立した確認者と、正式な承認者です。

期待される成果。 発行される図面に、一貫した確認水準が保たれます。

限界。 QAは各リリースに時間を加えます。確認の深さは、各図面パッケージのリスクに応じて調整します。

Practical Tip： 橋梁周辺、インターチェンジ、埋設物の交差部など、分野が最も密集している場所から始めましょう。すべてを一度に導入するより、小さな範囲で効果を示す方が容易です。

比較：従来のワークフローと調整されたワークフロー

適用例（仮想シナリオ）

以下のシナリオは、進め方を説明するための例示にすぎません。Fujiconのクライアント事例ではありません。

ある有料道路区間に、河川橋、橋台付近の排水用ボックスカルバート、そして移設が必要な電力ケーブルルートがあるとします。構造、排水、埋設物の三つのチームがそれぞれ別々に作業しています。

ステップ1。 コーディネーターが単一の座標系を定め、基準点をCDEにアップロードします。各チームは合意した命名規則に従い、モデルを「作業中」フォルダにアップロードします。

ステップ2。 最初の情報交換でモデルを統合し、マトリクスに従って干渉チェックを実行します。ソフトウェアは、たとえば橋台のパイルキャップとボックスカルバートの干渉、ケーブルルートと基礎の離隔不足などを報告します。

ステップ3。 指摘事項を絞り込みます。無関係な干渉は除外します。優先度の高い二件はインターフェース台帳に登録し、それぞれに担当者を付けます。

ステップ4。 調整会議で、排水チームがカルバートの高さと線形を変更し、埋設物チームがケーブルルートを調整することが決まります。決定事項は記録され、構造チームは影響を受ける図面を更新します。

ステップ5。 発行前に、QAがモデル、図面、数量の整合を確認します。通過して初めて、承認ワークフローに従い、パッケージが「共有」または「発行」に移されます。

このようなシナリオで期待されるのは、現場で見つかる干渉の指摘が減ることです。ただし効果の大きさはプロジェクトの条件に大きく左右され、一般論として約束できるものではありません。

実施に向けた提言

現実的な導入の順序を示します。各段階にかかる期間はプロジェクトの規模によって異なるため、具体的な数字は示しません。

1. 現状を把握する。 関与する分野、ファイルの流れ、問題が繰り返される場所を洗い出し、試行する範囲を一つ選びます。
2. 基本ルールを決める。 座標系、命名、文書ステータス、交換形式（たとえば、要求される場合はネイティブファイルとIFC）を定めます。
3. CDEと役割を整える。 情報コーディネーターと、各分野のモデル担当者を任命します。
4. 試行範囲で調整サイクルを回す。 統合、干渉チェック、レビュー、決定、指摘事項の完了までを一巡させます。
5. QAの関門を設ける。 簡易なチェックリストから始め、指摘事項をもとに改善します。
6. 評価して拡大する。 自分たちで選んだ指標、たとえば繰り返されるRFIの件数、リリース前に解決された干渉の件数、数量の食い違いなどを確認します。成果が十分であれば、他の範囲に広げます。

データ交換に関する補足です。IFC（Industry Foundation Classes）は、モデル情報を交換するためのオープンなデータスキーマです。ISO 16739-1の第2版（2024年）では、橋梁、道路、鉄道、水路、港湾施設を含むインフラ施設に必要な情報の範囲が追加されました。ただし、道路オブジェクトへの実際の対応状況は、ソフトウェアとプロジェクトで合意した交換要件に左右されます。まず小規模なサンプルで、ツールの連携を検証してください。

Expert Insight（Fujiconの編集上の見解であり、特定の人物の発言ではありません）： 設計調整はソフトウェアの機能ではなく、仕事の習慣です。ツールは干渉の発見を助けますが、誰が何を変更するかという判断は、人が行い、記録しなければなりません。

まとめ

有料道路のDEDの不整合は、たいてい一つのミスではなく、分散したデータ、不統一なルール、遅い調整が積み重なって生じます。BEP、CDE、座標系と命名の統一、干渉チェック付きの統合モデル、インターフェース管理、QAの関門といった構造化されたアプローチは、問題解決の場を現場から設計段階へ引き戻すのに役立ちます。

今週できる実践的な第一歩は、プロジェクト内で分野が最も密集している場所を一つ選び、座標系と命名に合意し、モデル統合と指摘事項のレビューを一巡させてみることです。その結果から、この方法を広げる価値があるかどうかを判断できます。

プロジェクトのご相談

DEDの調整ワークフローを見直したい、BIMモデリングを準備したい、干渉チェックや多分野の調整を実施したいといったご要望があれば、Fujiconが相談相手になれます。サービス情報は Fujicon と BIM Solusiでご覧いただけます。 WhatsAppから直接ご相談いただくことも可能です。プロジェクトに対するサービスの範囲と適合性は、相談の段階で検討します。

FAQ

有料道路のDEDとは何ですか。
DED（詳細設計）とは、入札と施工の基礎となる施工図、仕様書、計算書、数量内訳を作成する詳細な設計段階です。正確な範囲は、プロジェクトの業務仕様書と契約書に従います。

なぜDEDで詳細設計が噛み合わなくなるのですか。
よくある原因は、データの情報源の分散、座標系や命名の不統一、分野間の調整の遅れ、図面発行前の品質確認の欠如です。

BIMを使えばDEDの調整問題は自動的に解決しますか。
いいえ。BIMはモデルの統合と干渉の検出を容易にしますが、成果は作業プロセス、データの品質、チームの判断に左右されます。

干渉チェック（クラッシュ検出）とは何ですか。
統合モデルの上で、衝突している要素や近すぎる要素を自動的に見つける確認作業です。結果は技術チームが確認し、優先順位を付ける必要があります。

有料道路プロジェクトでCDEは何の役に立ちますか。
CDE（共通データ環境）は、情報の唯一の情報源となる共有デジタル作業空間で、作業中、共有、発行、保管といったファイルのステータスを管理します。

インドネシアの有料道路でBIMは義務ですか。
Bina Marga通達第11/SE/Db/2021号は、一定の範囲で高規格道路や有料道路にBIMを適用すると述べています。個別のプロジェクトでの要否は契約と発注者によるため、確認が必要です。

すでに進行中のプロジェクトでは、どこから始めればよいですか。
分野が密集している範囲を一つ選び、座標系と命名を統一し、拡大する前にモデル調整のサイクルを一巡させてください。