BIM運用ではファミリが増え続けるため、標準仕様と命名ルールを先に整える必要があります。ルールが曖昧なまま追加を続けると、検索性が落ち、重複作成や誤用が増え、集計やタグ、凡例などテンプレート側の自動化も破綻しやすくなります。BooT.oneが提供するテンプレート「BooT.one Standards」は、社内外でRevitの運用ルールを簡単に統一できる一方、業務にあわせて調整することも可能です。
本節では、BooT.oneで提供しているファミリを起点に「利用→編集→自社作成」へ段階的に移行する考え方を示し、命名の基本形と、更新・周知の仕組みを整理します。
3.1-1ファミリ標準を「共通認識」として位置付ける
標準の目的と適用範囲を先に決める
ファミリ標準は、ライブラリの整理に留まらず、図面表現、タグ、集計表、凡例、フィルタなどテンプレート全体の整合に直結します。まず「何を標準化の対象にするか」を決め、運用上の迷いを減らすことが重要です。
対象は、ファミリ名・タイプ名・パラメータ名のほか、カテゴリの使い分け、配置基準(基準面・原点)、表現の前提(サムネイル・向き・表記)まで含めます。ここを曖昧にすると、同じ用途のファミリが増殖し、担当者ごとに表現がぶれ、後工程で修正コストが発生します。
重要なのは、標準を「禁止事項」として扱うのではなく、誰が使っても同じ判断に到達できる起点として設計することです。標準が機能すると、選定・配置・集計・修正が繰り返し可能になり、個人の経験に依存しない運用に近づきます。
ファミリ標準が影響する範囲
.jpg)
命名・分類が崩れると、テンプレート側の自動化が破綻する
3.1-2BIMを手軽にはじめるなら、BooT.one Standards を起点にする
1000を超える設定を標準化の基盤に活用
BooT.one Standardsは、テンプレートやファミリの運用ルールを整理した資料です。社内標準を一から設計すると、整備負荷が導入初期に集中します。BooT.one Standardsを起点として位置付け、社内で追加・変更が必要な点を明確にすることで、初期設定の組み立てが容易になり業務をはじめやすくなります。
設定内容の詳細を確認したい場合は、文書を参照します。文書はテンプレートに含まれる設定の考え方や内容を明文化したものです。まずテンプレートで操作と運用の全体像をつかんでもらい、設定変更や内容確認が必要になった段階で、該当箇所を参照できるようにしておくとよいでしょう。
BooT.one Standards 設定イメージ
| No. | 参照章/項目 | 参照ページ |
|---|---|---|
| 1 | テンプレート(プロジェクトテンプレート/ビューシート) | p.11–16 |
| 2 | ブラウザ構成 | — |
| 3 | ビュー/シート命名 | p.11–16 |
| 4 | ファミリ | — |
| 4-1 | タイプ命名 | p.106–107 |
| 4-2 | パラメータ命名 | p.104–105 |
BooT.one Standards の参照範囲
テンプレート(プロジェクトテンプレート、ブラウザ構成、ビュー/シート命名)と、ファミリ(タイプ命名、パラメータ命名)の章を優先参照とする。
詳細はBooT.one_Standards_ver2.0.1.pdfの該当ページを参照する。
3.1-3ファミリ命名ルールを定義する
接頭辞とカテゴリで検索性を確保する
命名は「検索・判別・再利用」を成立させるための設計です。BooT.oneでは、ファミリ名の接頭辞(例:B_)やカテゴリ名を手掛かりに、用途を早期に特定できるよう整理されています。社内標準でも、ファミリ名は「カテゴリ」「用途」「サイズ」などの判断材料が読み取れる構造にします。短さよりも、誤用を防ぐ情報量を優先することが重要です。
自社独自ファミリを作成する場合は、BooT.one由来と自社由来を区別できる接頭辞を用意し、命名規則を統一します。たとえば「<会社略称>カテゴリ用途_寸法」のように、最初の要素で出自を判別できるようにします。タイプ名も同様に、寸法や仕様が判断できる命名(WDH、L、φなど)を基本とし、図面上の注釈に依存しない運用を行います。
命名の良い例/悪い例(例示)
| 観点 | 良い例 | 悪い例 |
|---|---|---|
| 出自が分かる | B_Door_片開き | Door01 |
| 用途が分かる | JS_Sanitary_手洗器 | 器具A |
| 寸法が分かる | B_Window_W900_H1100 | 窓_大 |
| 仕様が分かる | JS_Door_W900_H2100_枠なし | 扉_標準 |
短さより、誤用を防ぐ情報量(出自/カテゴリ/用途/主要寸法)を優先する。
3.1-4パラメータ命名規則を整備する
パラメータの役割を見分けられる名前にする
パラメータはファミリの挙動と情報を支える基盤で、タグ、集計表、凡例、アドインの処理など複数の要素が参照します。パラメータ名が曖昧だと、運用者が意図せず削除・改名し、図面や集計が壊れる原因になります。パラメータ命名は何に関する情報かを名前から読み取れる構造にする必要があります。
命名の基本は「部位名分類位置」のように、影響範囲を段階的に特定できる形とします。さらに、ユーザーが操作しない制御用パラメータは「制御」などの識別子を付け、保守時の誤削除を防ぎます。マテリアル系は社内で追加ルールが必要な場合のみ「マテリアル部位」のように種類を追記します。
命名で「役割」を識別する
例:
・部位_分類_位置
・マテリアル_部位
・設備_仕様_区分
運用者が入力・変更する前提で意味が読める名前にする
例:
・制御表示分類
・制御集計対象
・制御タグ出力
ユーザーが触らない前提を接頭辞で明示する
誤削除・誤改名の事故を減らす
タグ・集計・凡例・アドインが参照するパラメータは「改名=仕様変更」である
運用前に役割を明示して保守負荷を抑える
3.1-5業務にあわせて標準化のルールを調整して推進
追加・改修を申請フローに載せて標準を更新する
運用が始まると、案件ごとに必要なファミリや表現が増えます。ここで「標準があるから追加できない」とすると、標準が形骸化し、逆に無秩序に追加すると、資産が膨らみ運用が破綻します。標準化の推進のためには、追加・改修を管理フローに載せ、誰が、いつ、どの版に反映するかを決めます。
実務上はBooT.oneファミリを起点に「そのまま利用する」「編集して拡張する」「自社ファミリとして新規作成する」を段階的に使い分けます。判断基準(頻度、再利用性、影響範囲、保守負荷)を明文化し、レビュー担当(BIMリーダー/マネージャー)が承認したものだけを標準ライブラリへ取り込みます。更新後は、テンプレート側のタグ・集計への影響確認と周知を必ず行います。
追加・改修の管理フロー

BooT.oneファミリを起点に段階移行する
-コピー.jpg)
更新後は、タグ・集計の動作確認と変更点の周知を必ずセットにする
3.1-6この節の要点
ここまでのまとめ
- ファミリ標準はライブラリ管理だけでなく、タグ・集計・凡例を含むテンプレート整合の基盤となります
- BooT.one Standards を起点とし、社内で追加・変更する点だけを明確にします
- ファミリ名は接頭辞とカテゴリを起点に、用途と主要寸法が判別できる構造にします
- パラメータ名は影響範囲が読める命名とし、制御用パラメータを識別して誤削除を防ぎます
- 標準化を固定せずに推進するため、追加・改修を申請フローと版管理に組み込み、周知までを運用に含めます




