標準が止まるところ、プラットフォームが止まるところ

1ST-Bridge — 日本の構造データ標準が担うもの

日本にはST-Bridgeという構造データ交換標準があります。buildingSMART Japanが管理するXML形式で、通り芯・部材配置・断面符号とともに配筋情報を持ちます。IFCだけでは一貫構造計算ソフトとの連携が難しいという判断から出発した、日本独自の標準です。

重要なのはどのような方式で持つのかです。仕様書は配筋表現の原則をこう定義しています — 「建築構造設計図の断面表と同じ、種別・径・本数またはピッチによる配筋表現」。つまり表であって、鉄筋1本の3次元形状ではありません。

スキーマを実際に開いて確認すると、次の情報が存在しません。

そしてこれは欠落ではなく、仕様書自身が認めている空白です。当該要素について仕様書は「鉄筋の加工・組立、定着長さなどを与えることを想定」すると記し、「次期バージョン以降に実情を反映して詳細な定義を行う」と明示しています。

2標準があっても、実際に渡る量は異なる

二つめの事実は標準そのものではなく実装に関するものです。「ST-Bridge対応」と書かれていても、すべてのソフトウェアが同じ情報をやり取りするわけではありません。

そしてこれを標準をつくった側が自ら測定し、公表しています。buildingSMART Japanが発行する「情報連携マップ」は、掲載アプリのImport・Export対応を属性項目単位で◯△×により評価し、組み合わせごとの相互連携度を百分率で示します。RC造の評価項目数だけで1,201項目あります。

その値は組み合わせによって大きく分かれます。同じ標準に対応と書かれていても、どのソフトからどのソフトへ送るかによって、実際に渡る情報の量が変わります。標準が存在することと、実装が均質であることは別の問題である — それを標準の作り手自身が定量的に示しているわけです。

ただしこの二つは、いずれも「どれだけうまく運ぶか」の問題です。

運ぶ対象そのものに鉄筋1本の形状が入っていないという前節の事実は、実装がいくら良くなっても残ります。

3Revit — なぜ鉄筋が入ると重くなるのか

鉄筋は、部材あたりの要素数が爆発的に増える対象です。柱一本に主筋・フープ・補強筋が数十本、建物全体では数十万本になります。ですからBIMプラットフォームで鉄筋を扱うと重くなるというのは、実務者であればほとんどが経験していることです。

これが使い方の問題なのか構造の問題なのかは、Autodesk自身の公式文書で確認できます。

• 公式HelpのCPU推奨事項は、マルチコアによる性能向上を「最大20%」と記しています
• 同じ文書はL3キャッシュの大きいCPUを推奨しています — モデルの再生成がシングルスレッドで動く構造だからです
• 鉄筋要素のコピー・移動・編集が遅い現象については専用のサポート文書が別途あり、最初に推奨される対処はビューの詳細レベルを下げることです — 鉄筋をソリッドではなく線で描け、という意味です

回避策は世界中どこでも同じです。モデルを分割し、リンクで参照することです。鉄筋を別ファイルに切り出してリンクで読み込み、必要なビューだけで表示させ、詳細レベルを下げます。Autodeskの大規模プロジェクト向けガイドもまた、分割・リンク・モデル状態の管理を推奨しています。

「まるごと開いてまるごと扱う」解法は、公式文書にもありません。

これは特定の製品を貶める話ではありません。20年以上積み上がったコードベースが担える範囲の問題であり、ベンダー自身が文書で明らかにしている事実です。

ここから重要な含意が一つ出てきます。Revitの中で計算するアドインは、この天井をともに引き継ぎます。アドインがどれほど最適化されていても、モデルの再生成と要素の生成はプラットフォームのルールの中で起こるからです。

4そこで残る結論

整理すると、2026年の状況はこうです。一貫構造計算は標準化され（データ交換標準があり、ただし実装の差は残り）、BIMオーサリングも標準化され（プラットフォームとテンプレートの生態系が成熟し）、法的な成果物も標準化されています（2D図面）。

その間の層 — 1本単位の鉄筋の実体と、接合部での整合 — だけが標準もなく、プラットフォームも直接は埋めていません。