タイトル: カテゴリ・タイプ・インスタンス
SEOタイトル: Revitのデータ構造 — カテゴリ→ファミリ→タイプ→インスタンスの4層とタイプ/インスタンスパラメータ
| この記事の要点 |
|
4 層構造の全体像
Revit のすべての要素は、上位から順に カテゴリ → ファミリ → タイプ → インスタンスの 4 層で整理されています。この階層は Revit のデータ構造そのものであり、API でのフィルタ・IFC への変換・Speckle へのマッピングのすべてがこの構造を土台にしています。
| 層 | 意味 | 具体例 |
|---|---|---|
| カテゴリ（Category） | 要素の用途・種類の大分類 | Doors（ドア） |
| ファミリ（Family） | 振る舞い・共通パラメータのまとまり | 片開きドア |
| タイプ（Type） | ファミリ内の規格バリエーション | 片開きドア 900×2100 |
| インスタンス（Instance） | モデルに配置された 1 個の要素 | 1F 会議室の入口に付いた、その特定のドア |
カテゴリ（Category）
カテゴリは要素の最上位の分類で、Walls（壁）、Floors（床）、Doors（ドア）、Windows（窓）、Structural Columns（構造柱）、Furniture（家具）といった、あらかじめ定義された用途の区分です。利用者が自由に増やせるものではなく、Revit が持つ固定のリストから選ばれます。
カテゴリは次のような場面で基準として使われます。
- 表示制御：ビューごとに「ドアを表示／非表示」のようにカテゴリ単位で制御する（後述のビュー設定 VG）。
- 集計（スケジュール）：集計表はカテゴリを指定して作成する（例：ドア集計表）。
- API のフィルタ：要素を取得するとき、組込み列挙
BuiltInCategory（例OST_Doors）でフィルタするのが基本。 - IFC マッピング：Revit カテゴリは IFC のエンティティ（IfcDoor 等）へ対応づけられる。
タイプとインスタンスの違い
4 層のうち、実務で最も誤解されやすいのがタイプとインスタンスの関係です。
- タイプは「規格・仕様の定義」です。たとえば「片開きドア 900×2100」というタイプは 1 つで、モデル内に同じ仕様のドアが何枚あっても、参照しているタイプは共通です。
- インスタンスは「配置された実体」です。1F 会議室の入口にあるドア、2F 廊下にあるドア…それぞれが別々のインスタンスで、位置や向きといった個別の情報を持ちます。
プログラム的に言えば、タイプはクラス（あるいはプロトタイプ）、インスタンスはそのクラスから生成された個々のオブジェクトに近い関係です。Revit API では、タイプは ElementType（およびその派生 FamilySymbol 等）、インスタンスは FamilyInstance など、別の要素として扱われます。あるインスタンスから、それが参照しているタイプをたどることもできます（タイプ ID を取得して解決する）。この「インスタンス → タイプ → ファミリ → カテゴリ」とたどれる関係が、要素の正体を特定する手がかりになります。
この区別を誤ると、たとえば「タイプの寸法を変えるつもりが、本当はインスタンス固有の値を変えていた（あるいはその逆）」といった事故につながります。連携で値を書き込むときは、書き込み先がタイプとインスタンスのどちらのスコープなのかを必ず確認することが重要です。
タイプパラメータとインスタンスパラメータ
4 層構造と表裏一体なのが、パラメータの 2 つのスコープです。これは連携実装で取り違えると数量や属性がずれる、極めて重要なポイントです。
| 種類 | スコープ | 変更の影響 | 例 |
|---|---|---|---|
| タイプパラメータ | タイプ単位（同タイプの全インスタンスで共有） | 変えるとそのタイプの全インスタンスに一斉反映 | ドアの幅・高さ、壁の構成・厚さ、材質 |
| インスタンスパラメータ | インスタンス単位（1 個ごと） | その 1 個だけに反映 | 配置レベル、敷居高さ、コメント、個別マーク番号 |
たとえば「片開きドア 900×2100」のタイプパラメータである幅を 900 → 1000 に変更すると、そのタイプを使うすべてのドアが一斉に 1000 幅になります。一方、特定のドアだけ取り付けレベルを変えたいときは、そのインスタンスのインスタンスパラメータを編集します。「全体で揃えたいものはタイプ、個別に持たせたいものはインスタンス」と覚えると間違えにくくなります。
API・IFC・Speckle との関係
この 4 層 + 2 スコープの構造は、外部連携でそのまま現れます。
- Revit API：要素取得はカテゴリ（
BuiltInCategory）でフィルタするのが定石。各要素からタイプ（GetTypeIdで取得）とインスタンスを区別し、パラメータはget_Parameter等で読む。 - IFC：Revit のカテゴリ／タイプ／インスタンスは、IfcDoor などのエンティティと、IfcTypeObject（型）／プロパティセットに対応づけられる。
- Speckle：Revit コネクタは要素をオブジェクトに変換し、カテゴリ・ファミリ・タイプ・各パラメータをプロパティとして保持する。受信側はこの構造を頼りに要素を再構成する。
つまり、ここで押さえた 4 層構造は連携実装の共通言語です。Revit・IFC・Speckle はいずれも「大分類（カテゴリ／エンティティ）」「型（タイプ）」「実体（インスタンス）」「属性（パラメータ／プロパティ）」という同じ発想で要素を表現します。表現の名前は違っても構造が共通しているからこそ、ツール間でデータを行き来させられるわけです。パラメータの詳しい種類（共有パラメータ・組込みパラメータなど）は次の パラメータ（プロジェクト/共有/グローバル/ファミリ） で扱います。
まとめ
カテゴリ・ファミリ・タイプ・インスタンスの 4 層と、タイプ／インスタンスの 2 種類のパラメータが、Revit データ構造の骨格です。これを正確に理解しておけば、API・IFC・Speckle のどれを扱うときも迷いません。逆に、この区別が曖昧だと、データの取り違いや書き込みミスの温床になります。Revit を SE として扱う出発点として、まずここを固めておきましょう。次は パラメータ を、全体は Revit を参照してください。