Revitファミリ管理の正しい進め方|共有パラメータとIFC連携まで整理

1. はじめに

建築プロジェクトの大型化に伴い、Revitを活用する現場は増えています。一方で、「ファミリ乱立」や「属性不統一」が原因で、IFC納品時に必要な情報が不足し、後工程で手戻りが発生するケースも少なくありません。
こうした問題の多くは、ファミリ数の多さではなく、共有パラメータ定義やIFC出力方針(IFCExportAs/マッピング)が統一されていないことに起因します。

本記事では、

  • ファミリ区分の整理
  • 共有パラメータの設計と一元管理
  • IFCExportAs/マッピングテーブルを含むIFC連携設計
    を軸に、実務で機能するファミリ管理の進め方を具体的に整理します。

【最初に押さえる前提】

  • 管理対象は主にロード可能ファミリ(RFA)と、例外的に残るインプレイス。
  • システムファミリはRFA配布ではなく、テンプレート/プロジェクト標準として統制する。
  • 着手順は「棚卸し→優先順位→パラメータ設計→IFC出力検証」。IFC納品に影響する主要ファミリから先に整える。

2. ファミリ管理の第一歩は“パラメータ設計”

ファミリ管理で最初に固めるべきは、形状ではなくパラメータの設計ルールです。
とくに共有パラメータは、複数ファミリ/複数プロジェクトで共通利用できる「パラメータ定義」であり、値が自動的に他ファミリへ伝播する仕組みではありません(同一項目として集計・タグ・IFC出力に使えることが目的)。

【定義(最小限)】

  • ファミリパラメータ:そのファミリ内だけで完結する項目
  • 共有パラメータ:タグ/スケジュール/IFC連携の“共通キー”になる項目

【設計時に必ず決める項目(ここが未決定だと不統一が再発)】

  • パラメータ種別:共有/ファミリ
  • データ型:文字・数値・Yes/No・長さ など
  • 適用:インスタンス/タイプ
  • 必須度:必須/任意(空欄許容の有無)
  • 入力責任:設計/施工/設備/メーカー など
  • 用途:タグ表示/集計表/IFC出力(どれに使うか)
  • 命名ルール:表記ゆれ禁止(例:DISC_属性名_用途 などの形式を固定)

上記を一覧で整理すると、次のようになります。

表1|共有パラメータ設計の決定チェック項目

決定項目選択肢決めないと起きる問題
種別共有 / ファミリ集計できない、IFC未出力
データ型文字 / 数値 / YesNo / 長さ型違いで統合不可
適用インスタンス / タイプ集計値が崩れる
必須度必須 / 任意IFCで空欄発生
入力責任設計 / 施工 / 設備責任不明で未入力
用途タグ / 集計 / IFC出力漏れ

3. 共有パラメータを正しく作成・管理する手順

ここでは、Revitで共有パラメータを作成する基本的な方法と、その後の運用管理の手順を解説します。誤った設定や場当たり的な変更は、後の更新管理を複雑にします。そのため、初期段階でルールを固めておくことが重要です。

共有パラメータファイルの作成から、管理者が見落としやすい運用ルールまで順を追って整理します。とくに命名ルールやグループ分けを事前に設計しておけば、属性不統一の予防につながります。

初心者や新規メンバーも含め、組織全体で同じ共有パラメータファイルを使う体制を整えることで、チーム内の認識のずれを減らせます。IFC連携を円滑に進めるためにも、ここで示す手順を実務に活かしてください。

公式ドキュメントでは共有パラメータの作成手順や考え方が説明されています。本記事ではそれを踏まえ、実務に落とし込みやすい形で整理します。

3.1. 共有パラメータファイルの作成方法

まず、Autodesk公式の「Revitで共有パラメータを作成する方法」を参照しながら、共有パラメータファイルを作成します。[管理]タブから共有パラメータを選択し、新しいファイルを作成する手順に従います。

保存先は、社内サーバやクラウドなど全メンバーがアクセスできる場所が望ましいです。このファイルが、全プロジェクトで共通となる共有パラメータの基盤になります。

ファイルを設定したら、チーム全体に周知し、どのタイミングで参照するかを明確にします。複数の共有パラメータファイルが並行して存在すると混乱の原因になるため注意が必要です。

初期段階では項目数が少なくても問題ありません。運用に合わせて追加していく形でも構築できます。重要なのは、一元管理とメンテナンスルールの明確化です。

3.2. グループ分けの考え方

共有パラメータファイルでは、任意にグループを作成できます。たとえば「寸法系」「メーカー情報系」「施工管理系」「IFCエクスポート関連」など、用途ごとに分類して整理する方法が一般的です。

グループ分けが曖昧だと、新しいパラメータを追加する際に分類で迷います。逆に細かく分けすぎると管理が煩雑になるため、適度なバランスが必要です。

実務では、建築・設備・電気など専門分野ごとに分けるケースがよく見られます。それに加え、「プロジェクト管理系」のような共通枠を設けておくと、重要項目を見失いにくくなります。

組織の規模やプロジェクト特性に応じて適切なグループ設計を行い、誰にとっても分かりやすいルールを共有することが重要です。

3.3. 命名ルールの決め方

共有パラメータの名称は、後から変更すると影響範囲が広いため、初期段階で十分に検討しましょう。一般的には「区分_属性名」のように、用途や範囲が分かる形式が推奨されます。

たとえば「ELEC_メーカー名」「ARCH_仕上材」のように分野を示す略称を付けるだけでも、重複や衝突を避けやすくなります。また、全角・半角の使い分けや記号の使用可否を決めておくことで、管理のしやすさが向上します。

さらに、「参照元」や「単位」が必要な場合は、パラメータとして明示する方法もあります。Revit標準化を進める際は、パラメータ名だけでなくラベルや説明欄の扱いも統一しておくと混乱を減らせます。

命名ルールが整っていれば、メンバー全員が同じ認識でファミリを扱えるようになり、トラブル対応も容易になります。

3.4. 管理者が決めるべき運用ルール

共有パラメータファイルの変更権限を誰が持つか、追加や改訂をどのような手順で行うかは、初期段階で決めておくべきです。とくに大規模プロジェクトでは複数部門が関わるため、統括する管理者を明確にします。

ファミリ属性を一括管理する作業が多い現場では、改廃の申請フローを整理しておくと効率的です。一方で、誰でも簡単に編集できる状態ではパラメータが乱立する恐れがあるため、適切な権限制御が必要です。

たとえば、QC(品質管理)チームやBIM管理者の承認後にファイルを更新する仕組みにすれば、誤修正を防ぎつつ必要な変更を反映できます。こうしたルールは更新管理やバージョン管理にも関わります。

また、どの段階でパラメータの整合性を確認するかを明確にしておけば、IFC連携も円滑になります。これらの運用ルールが、ファミリ管理全体を安定させる鍵となります。

運用責任を整理すると、次のようになります。

表2|共有パラメータ運用の責任分解表

管理項目決定者更新タイミング備考
共有パラメータ追加BIM管理者申請承認後変更履歴記録
命名ルール変更BIM責任者原則変更禁止全体通知必須
データ型変更原則不可特例のみ版上げ必須
マッピング更新IFC担当納品前検証時テスト必須

4. IFC連携を見据えたファミリ管理

引用:https://www.buildingsmart.org/standards/bsi-standards/industry-foundation-classes/

BIMモデルを外部へ渡すための標準フォーマットであるIFC(Industry Foundation Classes)は、異なるソフトウェア間でデータを受け渡す際に用いられます。RevitからIFCを書き出す場合、ファミリ設定やパラメータの内容が大きく影響します。

設定が不十分だと、意図した情報がIFCに含まれず、取引先や建築主との協業が円滑に進まない可能性があります。とくにIFC納品が契約要件となっている場合、プロジェクト全体の品質や評価にも直結します。

ここでは、IFCエクスポートの基本構造からパラメータマッピングの考え方まで、流れを整理します。詳細は「revit-ifc-handbook-ja.pdf」などの公式ドキュメントを参照してください。

共有パラメータを適切に設定し、IFCとの対応関係を整理しておけば、外部との連携が円滑になり、結果としてプロジェクト管理の効率化につながります。

4.1. IFCエクスポートの基本構造

IFCは、建築要素や属性情報を部材ごとに階層構造で表現します。Revitでファミリ設定が正しく行われていれば、エクスポート時に適切なカテゴリや属性がIFCファイルへ反映されます。

一方、カテゴリ設定やIFC出力指定が不十分だと、「柱」である要素が意図しない分類で出力されたり、必要なプロパティが欠落することがあります。IFC納品が要件の場合は、納品前の検証で早めに確認しておくことが重要です。

そのためには、ファミリの階層やパラメータをIFCの階層やプロパティセットに正しく対応付ける必要があります。事前に公式資料でIFC構造を理解しておけば、書き出し時のトラブルを減らせます。

また、設計や施工段階で調整が発生しても、共有パラメータを通じて情報が一貫していれば、IFCエクスポートにも反映しやすくなります。

4.2. IFCExportAs / IFCExportType

RevitのIFC書き出しでは、要素をIFC上でどのクラスやタイプとして扱うかを指定するパラメータ設定が関わります。注意点として、Revitのバージョンや使用するIFC Exporter(組み込み/アドオン)の構成によって、参照されるパラメータ名や推奨手順が異なる場合があります。そのため、自社環境でどのパラメータ体系を採用するかを決め、混在を避けることが重要です。

指定が未整備のままエクスポートすると、IFC上で意図しないクラスに割り当てられたり、相手先で正しく解釈されないことがあります。対象ファミリごとに「IFC上でどう扱うか」を早い段階で決め、必要に応じてマッピング設定と合わせて確認する運用が安全です。

こうした指定ルールを標準化しておけば、納品前の確認や修正の手戻りも減らせます。

4.3. パラメータマッピングテーブルの役割

IFC出力では、Revit側のパラメータとIFC側のプロパティセットを対応付ける「マッピング」の考え方が重要です。Autodeskの技術情報では、パラメータマッピングテーブルをテキストファイルとして定義し、書き出し時に適用する方法が案内されています。運用としては、このテキストをチーム標準として管理し、必要に応じて更新していく形が有効です。

このテーブルを活用しない場合、設定した共有パラメータがIFCに正しく反映されないことがあります。ファミリパラメータや共有パラメータをどのIFC属性に紐付けるかを話し合い、ルール化することが重要です。

パラメータマッピングは一度整備すれば複数プロジェクトで再利用できます。ただし、更新管理を怠ると図面とIFCが一致しなくなる恐れがあるため、定期的な検証やテストを行うことが必要です。

最終的には、外部ビューワーや他システムにIFCを取り込んで確認することで、マッピングが正しく機能しているかを確実に検証できます。

表3|RevitとIFCの対応関係整理表

Revit側IFC側管理ポイント
共有パラメータPsetプロパティマッピング必須
カテゴリIFCクラスIFCExportAsで制御
インスタンス値属性値必須項目空欄禁止
ファミリタイプIFCタイプExporter差異に注意

5. 実務で使えるファミリ管理フロー例

ここでは、実務で再現しやすい管理フローを簡潔に整理します。
目的は、共有パラメータ定義とIFC出力設定を組織的に統制することです。

5.1. フォルダ構成例

社内サーバやクラウドに「ファミリ・ライブラリ」を設け、以下を分離します。

  • ロード可能ファミリ(RFA)
  • 共有パラメータファイル
  • IFCマッピングテーブル

大型案件では分野別(建築/設備/電気)に分けます。
共有パラメータファイルとマッピングテーブルは常に最新版を1つに統一します。

5.2. バージョン管理方法

RFAにはリビジョン番号や日付を付与します。

例:

  • ファミリ名_V1_2023-01-01.rfa
  • ファミリ名_V2_2023-03-10.rfa

正式版とドラフト版を区別し、IFC出力に影響する変更は必ず検証後に更新します。

5.3. 承認フロー

共有パラメータの追加・変更は、以下の流れで統制します。

  1. 担当者が申請
  2. BIM管理者またはQCが確認
  3. 管理者が承認後に共有パラメータファイル更新

個人判断での追加・名称変更は禁止し、定義の重複を防ぎます。

5.4. 更新時の上書き注意点

RFA上書き時は以下を確認します。

  • パラメータ構成に変更がないか
  • IFCExportAs/IFCExportTypeに影響がないか
  • マッピングテーブルとの整合性

必ずテストモデルで確認し、問題がなければ本番へ反映します。
バックアップを保持し、ロールバック可能な状態で更新します。

表4|ファミリ管理フロー全体像

フェーズ管理対象チェック内容成果物
設計開始共有パラメータ決定項目確認標準ファイル
RFA更新ファミリ差分確認新版RFA
IFC出力前マッピングPset確認検証IFC
納品前IFC全体ビューア検証納品IFC

6. よくあるトラブルと回避策(原因→確認→対処)

運用で起きやすいトラブルは、原因パターンがほぼ固定です。「原因→確認→対処」の順で潰すと、手戻りを最短化できます。

6.1. 共有パラメータが一致しない

  • 原因:共有パラメータファイルが複数/同義項目の重複作成(例:MakerName と メーカー名)/型違い
  • 確認:参照している共有パラメータファイルの統一有無、対象項目のデータ型・運用ルール(必須/任意)
  • 対処:共有パラメータファイルを一本化し、追加は承認制にする。既存混在は「統合先(正)」を決め、変換表で置き換える

6.2. IFCに出力されない(属性が落ちる)

  • 原因:マッピング未設定/IFCExportAs・IFCExportTypeが未整備/Exporter構成差(組み込み・アドオン)
  • 確認:①対象パラメータが共有パラメータか ②マッピングテーブルに記述があるか ③IFCビューアでPsetに入っているか
  • 対処:マッピングテーブルを標準管理し、プロジェクト個別改変を禁止。IFC出力は検証モデルでテストしてから本番へ

6.3. 上書きロードで属性が変わる

  • 原因:新旧RFAでパラメータ構成が違う(追加/削除、インスタンス⇔タイプ変更、既定値変更)
  • 確認:上書き前後で「パラメータ一覧」と「タグ表示」「集計表」の差分をテストモデルで確認
  • 対処:IFC影響項目・必須項目は変更禁止(変更するなら版上げ+承認+検証を必須化)。ロールバック用バックアップを保持

6.4. 年度版混在問題

  • 原因:下位互換不可/IFC出力設定やExporter挙動の差で結果が揺れる
  • 確認:プロジェクト内のRevit年度版一覧、IFC出力担当環境、同条件で出したIFCの差分
  • 対処:可能なら年度版統一。難しい場合はIFC出力専用の環境・手順を固定し、納品IFCはそこでのみ生成する

7. まとめ

Revitのファミリ管理は、「ファミリの数を減らすこと」ではなく、パラメータ定義を統一し、IFC出力まで一貫させることに本質があります。

本記事で整理した重要点は次の通りです。

  • システム/ロード可能/インプレイスの区分を踏まえて棚卸しする
  • 共有パラメータは「値が自動伝播する仕組み」ではなく、共通の定義として管理する
  • 共有パラメータファイルを一元管理し、命名ルールと承認フローを明確にする
  • IFCExportAs/IFCExportTypeの扱いを標準化する
  • パラメータマッピングテーブルをチーム標準として管理し、外部ビューアで検証する

これらを実行できていれば、スケジュール・タグ・IFC出力は同じ設計思想のもとで整合します。
逆に、この基盤が曖昧なままでは、属性不統一やIFC未反映といった問題が繰り返されます。

ファミリ管理とは、個々のRFAを管理する作業ではなく、BIMモデル全体の情報構造を設計する行為です。
共有パラメータ設計とIFCマッピングを軸に運用を組み立てることが、実務で機能するファミリ管理の条件といえるでしょう。

建設・土木業界向け 5分でわかるCAD・BIM・CIMの ホワイトペーパー配布中!

CAD・BIM・CIMの
❶データ活用方法
❷主要ソフトウェア
❸カスタマイズ
❹プログラミング
についてまとめたホワイトペーパーを配布中

<参考文献>

ヘルプ | ファミリについて | Autodesk

https://help.autodesk.com/view/RVT/2026/JPN/?guid=GUID-6DDC1D52-E847-4835-8F9A-466531E5FD29

ヘルプ | 共有パラメータ | Autodesk

https://help.autodesk.com/view/RVT/2026/JPN/?guid=GUID-E7D12B71-C50D-46D8-886B-8E0C2B285988

Revit で共有パラメータを作成する方法

https://www.autodesk.com/jp/support/technical/article/caas/sfdcarticles/sfdcarticles/JPN/How-to-create-a-shared-parameter-in-Revit.html

Revit で IFC パラメーター マッピング テーブルを使用する方法

https://www.autodesk.com/jp/support/technical/article/caas/sfdcarticles/sfdcarticles/JPN/REVIT-How-to-use-the-IFC-parameter-mapping-table.html

Revit IFC Handbook(日本語版 PDF) | Autodesk

https://damassets.autodesk.net/content/dam/autodesk/draftr/2528/revit-ifc-handbook-ja.pdf