日本における干渉チェックの（誤）認識（Part1）

それって干渉チェックですか？

ときたまクライアントとの会話で違和感を覚えることがあります。この1,2年で複数の設計事務所の方と会話していて、何回か干渉チェックに関して同じような反応をもらい困惑したことがありました。それは、

施主から干渉チェックを要望されているが、何か所かピックアップして断面を切り出し、目視確認をするという方針で対応したい

というものです。

干渉チェックに関する私の認識からすると「えええ？」という驚きがあったのですが、どうもいろいろと調べてみると、干渉チェック＝断面目視確認派は実はそれなりの勢力なのでは？という予感がしてきたので、今回から数回に分けてブログで話を整理してみようと思います。

まずは派閥の整理から

今回取り上げている干渉チェックですが、実際に干渉チェックなるものを実践したことがない立場での先入観も含めると、これまで3種類の意見を耳にしたことがあります。曰く、干渉チェックとは

3Dモデル上の要素が互いに邪魔になっていないかを断面図などで目視チェックすることである
3Dモデル上のすべての要素に重なりが皆無になるまで機械的にチェックを繰り返し、最後に干渉検出数を0にすることである
何らかの図形で組み合わせを定義し、機械的に干渉抽出を行った後、設計上の課題と3D表現の問題を仕分け、プロジェクト進捗を把握することである

という3種類です。皆さんのイメージに近いのはどれでしょうか？ちなみに国土交通省のサイトにPDFでアップロードされている干渉チェックの資料があるのですが、1のスタンスです。

~~https://www.mlit.go.jp/gobuild/content/001768901.pdf~~

この記事を書いてからしばらく寝かせていたらアクセスできなくなっていました。
内容としては干渉チェックの手引きで、断面図を表示して目視でチェックすることを基本として、ソフトウェアを使った干渉検出もある（詳細は触れない）というような方向性でした。

どれにも当てはまらない定義があればぜひコメントを寄せてください。

なぜ干渉チェックをやるのか

さて、認識のずれ方が激しいですね。こういう時は根源的な問いに立ち返るのが良いでしょう。

まず、干渉とは何であるのか、干渉をどうしたいのでしょうか？

干渉（Clash=クラッシュ）には大きく分けて二つあります。

ハードクラッシュ（物理的な接触や貫入）
ソフトクラッシュ（メンテナンススペースやアクセスゾーンへの侵入）

ハードクラッシュが発生している場合、モデルは現実世界にはありえない状況を示していることになります。立て入れや据え付けができないので修正が必要そうですね。

ソフトクラッシュは建設俗語でいう地獄（取り外し不可）になっているようなものや点検口を開けようとすると梁にぶつかって開かないというようなものです。これもない方がよいですね。

さて、このような干渉ですが、多くの場合、発覚して問題となるのは設計段階ではありません。

施工現場に行ったら納まっておらず設計のやり直しになったという経験
竣工後のメンテナンスや日常の利用で「何でこんな所に柱があるんだ！（三谷幸喜『みんなのいえ』）」という不快感

など、事後的に設計がちゃんと納まっていないことが判明します。

これに対して原因と対策として

原因：設計者がうっかりしていた
対策：設計者がしっかりする

というやり取りが歴史的に繰り返されてきました。

俯瞰して見ると、（納まっていないこと以上に）着工してみるまで評価ができず、設計者の専門性によって状況が隠蔽されていることが不満の根本原因ではないでしょうか。

建物のどこかに干渉があるかもしれないというブラックボックスに対する疑念を晴らしてほしいのに、「経験と勘に基づいて適切に判断しています。細かいことはプロにしかわかりませんから」と言われてもモヤモヤしてしまいます。

これに業を煮やした発注者から、業務プロセスへのアカウンタビリティ（説明能力）の向上として要望されているのが干渉チェックだと言えるかもしれません（まぁ実際にはそこまで深い考えはなく、「なんかBIMを使うとチェックできるらしいよ」くらいの感覚かも）。

この前提に立つと、説明能力の向上になっているか？という観点で3派閥を評価することができそうです。

アカウンタビリティの観点で

さて、説明能力の観点でもう一度3つの干渉チェック観を見てみましょう。

3Dモデル上の要素が互いに邪魔になっていないかを断面図などでチェックすることである
3Dモデル上のすべての要素に重なりが皆無になるまで機械的にチェックを繰り返し、最後に干渉検出数を0にすることである
何らかの図形で組み合わせを定義し、機械的に干渉抽出を行った後、設計上の課題と3D表現の問題を仕分け、プロジェクト進捗を把握することである

1 に関しては、これはどこかに干渉が隠れているか？という問いに対して、答えられません。断面を切った場所は確認できますが、他の場所はどうなっているのか？という追及が無限に発生し、無数に断面を切ろうというような非現実的な方向に行ってしまいます。定量性の観点でも評価が難しく、結局技術者の専門性に依存しており、客観的説明とはいいがたいものがあります。

2に関しては、説明は明快にはなるかもしれませんが、現実的な問題としてそんな3Dモデルの作り方は不可能です。例えば、構造部材+ボルトだとか壁+ドアのような組み合わせは、モデル上接しているわけですが、これにクリアランスをつけるようなことをやり始めると現実とは乖離しますし、手間数が激増します。

3は2と比べると網羅性の点で疑問は残るものの、定義されている組み合わせに関しては定量的に評価ができます。また、干渉の検出が機械的に（計算幾何学的処理によって）行われることで、属人的な技量の差が出にくく、人為的なミスをある程度軽減できます。モデルの重なりを判断する程度あれば、多くの手間がかかるものの実現可能な作業でもあります。

しばしば干渉無し、干渉ゼロ（No Clash, Zero Clash）というような表現を見ますが、その意味するところが2のような考え方であれば非現実的です。求められていることの要諦が、専門性に隠されている設計を建築主に理解しやすい形で説明するという点にあるのだとすれば、3のように検討すべき場所を計算幾何によって特定して、各所への判断を示せば事足ります。

以上のような考え方で、干渉チェックとして穏当なのは「何らかの図形で組み合わせを定義し、機械的に干渉抽出を行った後、設計上の課題と3D表現の問題を仕分け、プロジェクト進捗を把握することである」ではないかと思います。

実務上はEIRとBEPによって期待値のすり合わせを行うので、具体的な実行方法はプロジェクトに応じて定義されますが、実務者の常識的感覚としては目視チェックよりも妥当ではないかと思っています。

経験則ではありますが、今回書いたような議論は日本国内ではよく経験する一方、弊社の関わる中東諸国や欧州の案件ではBEPで論点になったことがありません。次回以降このあたりの背景も触れようと思います。長くなっちゃったのでこの辺で（Part1）を〆ます。