Industry Foundation Classes - Release 1.5

IFC End User Guide

1998 年 7 月 1 日

International Alliance for Interoperability

建設業界の相互運用を目指してCopyright  1997 - International Alliance of Interoperability (IAI)
Mailing address:

4200 Wisconsin Avenue NW
Suite 106 - Box 263
Washington, DC 20016-2157

Email address:

IAI@Interoperability.com

Web Address:

www.Interoperability.com

All rights reserved. No part of the contents of this document may be reproduced or transmitted in any
form or by any means without the written permission of the copyright holder (IAI)IFC End User Guide

もくじ
今日の建設業界の状況
IAI（International Alliance for Interoperability
IAI のビジョン、ミッションおよびバリュー
IFC（Industry Foundation Classes）
国際組織
支部
会員資格
会費
分科会
国際組織
IFC 仕様書リリース・ドキュメント

1
2
2
3
5
5
6
6
7
8
9

IFC エンドユーザ・ガイド
IFC 仕様開発ガイド
IFC オブジェクト・モデル構築ガイド
Volume1:IFC がサポートする AEC プロセスについて
Volume2:IFC オブジェクト・モデル・ガイド
Volume3:IFC オブジェクト・モデル・リファレンス
Volume4:ソフトウェア実現ガイド

9
9
9
9
9
10
10

情報モデル化プロセス
リリース1.0 の適応範囲
リリース1.5 の適応範囲
リリース2.0 の適応範囲
リリース3.0 の適応範囲
現サポート・プロセス
意匠設計

11
13
13
14
14
15
15

空間設計
壁配置
ドア配置
窓配置
建具表

15
15
16
16
16

空調設備設計17

空調設備負荷計算用の面積拾い出し
機器の選択と機器表の自動作成

17
17

工事管理

18

数量の拾い出しと見積もり
工事計画

18
18

FM（施設管理）18

設備・家具などに関する施設管理

18

付録 A−建設業界における相互運用

付録

Page i1

IFC End User Guide

Page ii

IFC End User Guide

今日の建設業界の状況
今日の建設業界は、多くの業種によって構成されています。それぞれの業種は、独自の専門用語，技術そして情報の表現と伝達方法によって独立して発達してきました。こうした結果、各業種間で情報を共有する場合に多くの問題を引き起こしてきました。同じ業種の中でさえ、プロジェクト情報の損失やコミュニ
ケーションの困難さが存在します。共同で作業するような場合、プロジェクト費用の追加が莫大になっています。この問題を早急に解決するために IAI(International Alliance for Interoperability）が発足しました。
現在、建設業界の CAD アプリケーションは、これらの業種の情報の共有化ということに対して、ほとんど機能を持ちあわせていません。例えば、最近完成したデンバー国際空港において、プロジェクト実施中に発生した問題点が新聞紙面で大きく取り上げられ、この点が指摘されました。それは、設計者が作業を開始した時点で、２０以上の異なる業種が、さまざまなプラットフォームの CAD とサードパーティーのアプ
リケーションを使用していました。このことによって、各業種間でのデータ交換ができないことから、つぎの２つの解決策が考え出されました。

1． ソフトウェアのプラットフォーム統一による方法
この方法は、いくつかの設計会社にとっては、新
しいソフトウェア、さらにはハードウェアの購入にかなりの出費が必要となり、しかも、スタッフ
は、新しいツールを熟練する必要が出て来ます。
2． アプリケーション間共通部での情報交換による方法
この方法は、会社にとっては最も慣れた方法で作業をすることができるが、一部データ欠落などの問題があります。(例えば、DXF ファイルによる変換)

結局、経済的な理由で後者の解決策が選ばれました。
上記のデンバー国際空港プロジェクトは、今日の建設業界の代表的な状況を示しています。

建 築

構 造

土 木

施 主

設 備

制 御

FM

施 工

図１ 建築分野の複雑なコミュニケーション

データ共有化による相互運用（Interoperability）をソフトウェア上で解決できてないということは、いろい
ろな面で生産性の効率化において問題となっています。このことは、建築ライフサイクル、すなわち、設計，施工，および保守管理において、非効率的な作業過程をもたらしています。多くの担当者はライフサ
イクルの中で同じような作業状況に遭遇し、何度も情報の追加や検索を行わなければなりません。しかしながら、高度情報化時代にありながら、ほとんどの作業で多くの無駄が発生しています。
以上のことから IAI では、データを共有化し、相互運用するための活動を行います。具体的には、コンピ
ュータを利用した高度情報化に対し、標準化を図り、異なるソフトウェア・アプリケーションでも利用できるデータの共有化とその活用の実現化を目的としています。

Page 1IFC End User Guide

IAI (International Alliance for Interoperability)
IAI は、建物のライフサイクルを通して、利用するソフトウェア間で、有効な相互運用を可能にするための標準化の作成を目的としています。
当初 IAI は、建設業界に携わる北米１２の会社によって設立されました。
これらの会社は、相互運用の問題点の解決策を示すために、１９９５年６月のジョージア州アトランタで開催された A/E/C システムショーで、一連のプロトタイ
プ・アプリケーションを展示しました。
これらのプロトタイプは、理想とする相互運用が実現できることを立証しました。
この公開デモンストレーションの成功により、当初の１２社は１９９５年９月世界中の建設業界に対して、この活動への参加を募りました。こうして、国際的なIAI が誕生しました。

建 築

土 木

構 造

共 有
プロジェクト
モデル

施 主

FM

設 備

制 御

施 工

１９９８年５月現在、９つの国際支部､約６００社が参加し、日々その数は増加しています。

図２ IFC が唱える相互運用性の概念図

IAI のビジョン，ミッションおよびバリュー
ビジョン
建設業界の相互運用を可能にすること。
ミッション
プロジェクトのライフサイクルを通して、各業種とソフトウェア・アプリケーションで使用する共有データの仕様の定義，利用の推進、そして広報活動すること。
バリュー● 非営利団体● オープンな会員資格● 協調組織● コンセンサスによる意志決定● 研究成果を適宜公表● 国際的なソリューション
● ソフトウェア専門家と建設業界専門家の共同作業による標準仕様の定義● 仕様公開● 拡張性のある仕様● 最新技術対応

Page 2

IFC End User Guide

IFC (Industry Foundation Classes）
IAI は、建物を構成する全てのオブジェクト (例えば ドア， 窓，壁などのような要素)のシステム的な表現方法の仕様を定義します。これらの仕様を IFC( Industry Foundation Classes）と呼びます。アプリケーション
で用いるプロジェクト・モデルのデータ構造も合わせて提示します。
定義されるそれぞれの仕様は「クラス」と呼ばれます。「クラス」は共通の特性をもつものとして扱われます。例えば、「ドア」は部屋（空間）に出入りする開口、そして「窓」はそこを通して外を見ることができる透明さをもつ開口として、それぞれの特性が定義されています。この「ドア」や「窓」はともに「クラス」となります。
IAI で定義されるこれらの「クラス」を IFC として表記します。
IFC は以下の略語の意味となります。
Ｉ ( Industry ） ：建設業界（ Industry ）Ｆ ( Foundation ） ：共有のプロジェクト・モデルの基礎（ Foundation ）Ｃ ( Classes )：合意のもとに構築するための共通な言語としてのクラス（ Classes ）IFC で定義される「ドア」は、「ドア」を表現するだけの単純な線分の集合ではありません。「ドア」として認識できる特性を持ちます。
プロジェクトでは、様々なタイプの「ドア」が使用されます。ある「ドア」は幅９００ｍｍ、またある「ドア」は幅１２００ｍｍというような場合、どちらの「ドア」も認識することができ、IFC 仕様で定義されている「ドア」の共通の特性も持っています。「クラス」は、この共通の特性を定義したもので、それに対してそれぞれの実体にあたるものを「オブジェクト」と呼びます。
IFC 上の「オブジェクト」は、建設業界の各業種でプロジェクト・モデルを共有することができます。
建築家が設計した「ドア」は、他の業種の担当者も同じ「ドア」として扱うことができます。こうした共有化によって、積算、設備設計、施工、施設管理で効率を計ることができます。
IFC は、建設業界のソフトウェア・アプリケーション間のデータ共有化とその相互運用を可能にします。
ここでの IFC 仕様書は、このソフトウェア・アプリケーション開発者向けに、オブジェクト指向プログラ
ミングに基づくクラス・ライブラリを定義します。ある 1 つのアプリケーションで作成される「ドア」オ
ブジェクトは、他の IFC 準拠のアプリケーションと情報を交換することができます。他のアプリケーショ
ンは、暗黙的に「ドア」オブジェクトを自動的に認識します。
つまりここでの「ドア」オブジェクトの特徴は、オブジェクト指向で表現すれば、つぎのようになります。
「自分はドアで、どのようなタイプのドアで、どのような材質で作られ、どのように仕上げられ、どのような操作で、どのような幾何形状で、どこがドアの上枠、縦枠、丁番そして敷居かということを認識します。」
他のアプリケーションは、これらの特徴を理解し、IAI で定義された IFC 仕様を使用して、オブジェクトに情報を付加することも可能です。
さらに、IFC 準拠のアプリケーションにより、電子情報によるデータ(図面，レポートおよび仕様書などのような)を共有することを可能にします。これは、データの一貫性と整合性の保証を意味します。さらに、
この共有データは、設計終了後の施工においても発展し続けます。設計者によって作成された情報は、知的で電子的なフォーマットにより、IFC 準拠のソフトウェアを通して、施工や保守管理に利用されます。

Page 3

IFC End User Guide
現在、IAI の加盟会社は、多くの業種にまたがって協同で IFC の仕様書をまとめています。IAI は、ソフト
ウェアの作成ではなく、ソフトウェア会社と共に建設業界に IFC 標準を促進することを目的とし、そして建設業界でコンピューターの新しい可能性をもつソフトウェア・アプリケーションを作り出すことをサポートします。（図３参照）

IMPLEMENTATION‘A'
Flavor APIs

VENDOR “A“

AEC PROCESSES

“A“
IFC
STORE

‘B'

OWNED BY IMPLEMENTERS

Technology

OPEN FOR IAI MEMBERS

"B"
IFC
STORE

‘N'

IFC IMPLEMENTATION

Technology

IFC DEFINITION

“N"
IFC

IFC PROJECT MODEL
MODEL EXCHANGE

IFC
MODEL
EXCHANGE

VENDOR "B“
IMPLEMENTATION(FILES = STATIC)MODEL INTERFACES
VENDOR “N“(RUNTIME = DYNAMIC)

IMPLEMENTATION

STORE

図3 IFC 建築モデルに対するIAI とソフトウェアベンダーの関係
IAI が作成した仕様に基づき、ソフトウェア・ベンダーはそれぞれのアプリケーション開発を行います。IAI
は、IFC 建築モデル（ IFC building model）を含む IFC 仕様を作成します。

Page 4

IFC End User Guide

国際組織
IAI は、国際間協力によって展開されることから、国際支部を組織しています。
現在下図で示される、９支部２１ヶ国で組織されています。

North America

United Kingdom

NordicJapan

FranceKorea

German Speaking

Singapore

Australasia

図4 現在のIAI 国際支部

支部
各支部は、IFC の統合を運営する国際評議会とともに、各支部独自の組織構造を持ちます。各支部の組織は、事務局、幹事会、技術統合委員会、および各分科会で構成されています。各支部は、支部で行われるそれぞれの組織の運営を行います。

Page 5IFC End User Guide

会員資格
IAI 参加資格制度は、オープンになっています。このことは、建築家，エンジニア，施工業者，建物の所有者および管理者，建築製品製造者，ソフトウェア・ベンダー，情報プロバイダー，政府機関，研究室そして大学を含めた、建設業界の様々な組織が自由に参加できるようになっています。IAI 加盟会社の会社代表
者は、大きくは２つの業種に携わる専門家です。１つは、建設業界の専門家で、建築家，エンジニア，施工業者および設備管理者といった建築業界で日常の専門業務に携わる人で、エンドユーザの立場となります。 もう１つは、技術専門家で、ソフトウェア開発を行うデベロッパーの立場となります。
建設業界専門家は、IAI と IFC の仕様に準拠したアプリケーションを利用することによって、莫大な利益を享受することができる代表的なエンドユーザです。
ソフトウェア技術専門家は、研究，ソフトウェア設計および工学にバックグラウンドをもつ個人で、一般的に建設業界で経験を持っています。
これらの２つの専門家グループは、共有プロジェクト･モデルを定義するという共通のゴールに向かって協力していきます。

会費
IAI は、会員の会費により運営される非営利団体組織です。
この会費は、以下のような目的に使用しています。
● 支部の各分科会と技術統合委員会の開催費用● 国際会議への参加費用● ドキュメントの翻訳費用● 広告宣伝● IFC 仕様書の配布● Web 維持管理
● 国際資金各支部は必要に応じた会費で運営されます。また、各支部の会費の一部を国際組織に支援するようにしています。

Page 6

IFC End User Guide

分科会
各分科会は、業種別のそれぞれの専門領域で経験を持つメンバーによって構成されます。
技術統合委員会は、選ばれた業種の専門家により統括され，技術専門家により協同で運営されます。
各分科会ごとに、全体の共有プロジェクト・モデルに適用する特定の業種別のモデルの仕様作成を行います。
建材メーカーやソフトウェア・ベンダーも分科会のメンバーとなり、各業種の専門家との調整を行っていきます。分科会間の会議や調整は、技術統合委員会で運営しています。

意

匠

構

造

施

工

研究機関

会

技術統合委員会
事

設備・ＦＭ

幹

クロスドメイン
事務局
機械翻訳

土

木

インプリメンテーション

図5 現在のIAI 日本支部組織

Page 7

IFC End User Guide

国際組織
各支部は、IAI の年２回の国際評議会に代表を送り、さらに年４回の国際技術会議に参加します。
国際組織は、統合的な企画や実証の戦略に関する以下の４つの技術委員会を併設します。
・ITM（International Technical Management）
国際的な技術活動を統合し、全 IFC プロジェクトの整合性をとり、各支部で使用可能な世界標準を作成します。
・ STF（Specification Task Force）
ITM を代表し IFC オブジェクトモデルと仕様書を作成する技術者の専門グループ
・ Software Implementation
ソフトウェア会社が IFC インプリメンテーション（ 実証・実現 ）を行うための委員会
・ Research／Advisory
今後のIFC 戦略の指針を定めるための委員会内顧問グループ

国際評議会
運営委員会

事
International Business Management

務局

International Technical Management
Research / Advisory
Specification Task Force

各支部組織

図6 IAI の国際組織

Page 8Australasia

FrenchSpeaking

GermanSpeaking

Korea

Japan

NordicNorth
America

Singapore

UnitedKingdom

Software Implementation

IFC End User Guide

IFC 仕様書リリース・ドキュメント
IFC 仕様書の対象とする読者は、建設業界専門家とソフトウェア技術専門家を対象にしています。
以下に、リリース1.5 で提供されるドキュメント内容を紹介します。

IFC エンドユーザ・ガイド
この IFC エンドユーザ・ガイドは、 建設業界専門家向けに、IFC 準拠の共有プロジェクト･モデルの概念を含む IFC 仕様書の紹介用として記述されています。このガイドは、IFC に準拠したアプリケーションのエンドユーザに対するメリットの概説、IFC、IAI の概要、それに IFC 仕様の構造化プロセス・モデルについて要約しています。

IFC 仕様開発ガイド「IFC 仕様開発ガイド」は、IAI で使用される
IFC の開発プロセスを定義しています。また、プロセス・ダイアグラム作成例、詳細要求定義の作成例、
EXPRESS（データモデル）定義やEXPRESS-G ダイアグラムの内容についても説明しています。

IFC オブジェクト・モデル構築ガイド「IFC オブジェクト・モデル構築ガイド」は、IFC オブジェクト・モデルの構成を定義しています。このオ
ブジェクト・モデルの構成ではいくつかのモジュールとその階層からなり、独自の開発やサブ・スキーマの改良を可能にします。
このガイドは、IFC 準拠のアプリケーションを開発するソフトウェア・ディベロッパ用に作成された仕様書です。

Volume１：IFC がサポートするAEC プロセスについて
IFC でサポートされる AEC プロセスでは、IFC プロジェクト・モデルがサポートする建設業界の各業種の作業プロセスの説明を行っています。この仕様書では、AEC プロジェクトで定義する範囲に限定しています。さらに Volume２では、この範囲でのアプリケーションで展開する具体的な IFC に関する情報を構造化して表現してします。

Volume２：IFC オブジェクト・モデル・ガイド
IFC プロジェクト・モデル・ガイドでは、IFC で扱うプロジェクト・モデルの定義について説明しています。
Volume１の AEC プロセスで必要とされる IFC オブジェクト・クラス、標準インターフェース、それにデータ型についての情報を構造化して明確にしています。また、IFC モデルを構築するにあたってのコンセプ
ト・モデルの構造、設計意図、共有関係、アプリケーション開発者によるモデル拡張、それに IFC プロジ
ェクト・モデルが意図しているモデル交換とインターフェース部分に関しても説明しています。

Page 9

IFC End User Guide

Volume３：IFC オブジェクト・モデル・リファレンス「IFC オブジェクト・モデル・リファレンス」は「クラス」と IFC のオブジェクト・モデルで定義されている「データのタイプ」を詳細に説明したものです。Volume１で定義される建設プロセスの要求定義、詳細なオブジェクト・クラス・データ、関連、標準インターフェース、タイプの定義そして形状を定義する
幾何スキーマの情報モデルの構築についても説明しています。
さらに、EXPRESS で定義されているデータ・モデルのビューとIDL で定義されている標準インターフェースについて説明をしています。それぞれのコード方式は、IFC 準拠のアプリケーション開発を部分的に自動化するための CASE（Computer Aided Software Engineering）ツールのインターフェースとしてアプリケーシ
ョン開発に使用されます。最終的には、この情報のオンライン・バージョンは HTML で提供され、関連情報または特定の「クラス」と「データ」に対して簡単にアクセスできるようになります。

Volume４：ソフトウェア実現ガイド「IFC ソフトウェア実現ガイド」は、IFC 準拠のアプリケーションを実証する方法論を詳細に説明しています。この中では、準拠評価の概要、IFC モデルのサブセット・データ変換の定義、準拠実証テストで使用されるテスト一式などを説明しています。

Page 10

IFC End User Guide

情報モデル化プロセス
IFC 仕様書は、建設業界の各業種専門家とソフトウェア開発技術専門家で共有される建物データを、トップ
ダウン・アプローチによって情報モデルとして定義します。建設業界の一般的な見解のもとにコア（核）となる全体的な建物モデルが定義され、各業種にまたがる詳細な部分についてはソフトウェア・アプリケーションに合わせて組み込まれます。下記の内容は、IFC 仕様書で使用される重要項目を説明しています。
● 使用方法： 例えば建築家が壁をレイアウトする手順、およびプロセスの各ステップ間で必要となる情報を記述しています。
● プロセス・ダイアグラム：プロセス定義は、以下のような TQM 図式例を使って説明しています。

Fire Rating
Egress Needs

Determine
Constraints

Size

Place Door

Location
Swing

Define
Door
Attributes

Type

図7 プロセス･ダイアグラムの例● クラス：オブジェクト指向定義で使用される構成要素です。クラスは、建物データの定義となり、

例えば、ドアなどのような物理的なオブジェクト、もしくは施工プロセスでの追加作業や積算プロ
セスでのリソース（資源）などを表現します。
● インターフェース：インターフェースは、ソフトウェア開発者向けに、IFC 準拠のオブジェクトとのアクセスを可能にするものです。例えば、壁オブジェクトでは、各業種における防火や、構成する空間（部屋）、遮音などに関するインタフェースがあります。
● 属性：クラスまたはインターフェースに取り付く情報で、オブジェクトに付加定義されます。例えば、ドアには、高さ，幅，材質などの属性が付加定義されます。
● 関連：クラス間に定義され、クラス・インターフェースに組み込まれます。例えば、ドアは、壁と関係があり、壁にドアが取り付けられます。このとき壁の一部としてドアが関連付けられます。関連は、実際のオブジェクトとして動作を定義する上で重要であり、例えば、壁を動かすと同時にドアを動かすときに必要となります。
● 情報モデル：クラス，インターフェース，属性，関連を表現するために使用されます。IFC のモデ

ル図化表記法としてEXPRESS-G を使用し、図８のように図示することができます。IFC 情報モデルの詳細については、IFC 仕様書 Volume２をご参照ください。
Page 11

IFC End User Guide

GenericType
IfcProductExtension.IfcBuildingElement

IfcRoofSlab

IfcRoofSlabTypeEnum

GenericType
IfcFloorTypeEnum

IfcFloor

LayerInformation
GenericType

IfcWall

LayerInformation

IfcWallTypeEnum

LayerInformation

IfcPropertyResource.IfcMaterialLayerSetUsage
LayerInformation
GenericType

IfcCovering

SELF¥IfcRelationship1toN.RelatingObject

IfcKernel.IfcRelationship1toN

IfcCoveringTypeEnum

SELF¥IfcRelationship1toN.RelatedObjects
L[1:?](INV) Covers

IfcRelCoversBldgElements

図8 Express-G ダイアグラムの例● テストケース：具体的な建物を使って定義されたデ要素/属性ータとなります。このテストケースにより、ソフト表示
ウェア・ベンダーが開発したIFC 準拠のアプリケー
ションの性能をテストすることができます。テスト 部屋１
面積
ケースは、オブジェクト，インタフェース，属性，
関連を含むデータを提供します。図９は、サンプル・
部屋番号
テスト・ケースデータの内容です。
壁１

材質
方向
壁面積

入力値

単位

26.6261
室１

平方メータ
文字

レンガ
180
12.36

文字
度
平方メータ

窓１
材質

厚さ3mm
文字
透明ガラス
開口面積
7.2
平方メータ
ブラインド
なし
文字
図９ サンプル・テスト・ケースデータ

Page 12IFC End User Guide

リリース1.0 の適応範囲
IFC リリース 1.0 は、建物のライフサイクルを通して使用される共有プロジェクト・モデルを定義することを目的としています。初期のリリースとして、意匠設計、空調設備、工事管理、およびFM(ファシリティ・
マネージメント:施設管理）をサポートしていますが、共有プロジェクト・モデルの一部の定義しかされていません。今後のリリースによって、サポート範囲は拡張されていく予定です。
IFC 仕様書のリリースは、達成可能な範囲に限定しています：● ｢コア｣モデルとプラグイン拡張機能のサポート

この機能でIFC モデルの拡張を保証します。
● ４つの業種（設計，空調設備，工事管理，FM）のみを記述します。
● ４つの業種で使用されるプロセスの一部がサポートされます。

リリース1.5 の適応範囲
IFC 仕様書のリリース1.5 は、リリース1.0 で開発された業種範囲の拡張はありません。
ただし、リリース 1.0 の実証実験の建物や IFC モデル構成は改良されました。また、IFC のオブジェクト・
モデルの「コア」は範囲が拡張され、ソフトウェア開発のプラットフォームとして提供できるようになりました。

Resource

KERNELCore
Interop
DomainAPPLICATIONB1

APPLICATIONAB1APPLICATION
A1

図１０ IFC モデル構成

Page 13APPLICATION
A2

IFC End User Guide

リリース2.0 の適応範囲
IFC 仕様書のリリース 2.0 は、IFC オブジェクト・モデルの適応範囲が拡張され、図１１に示される各業種分野が含まれます。

Core Extensions

Architecture

Tables,Network

Core, Shell, Roof,
Restroom,
Space Planning,Fire Compartmentation

IFC 2.0

Building Services
Duct design, Pipe
design, Coordination,
Thermal load calcs

Estimating

Codes

FM

Energy,Disabled access,Escape routes

Move planning,
Workstation design,
Workstation layout

Cost item id,
Task modelling

Photometrically
Accurate
Visualisation
図１１ IFC リリース2.0 適応範囲

リリース3.0 の適応範囲
現時点では、リリース3.0 の作業として図１２に示す業種分野が提案されています。リリース 3.0 では、IFC
オブジェクト・モデルの適応範囲の拡張を計っています。

X-Domain

Architecture

Libraries,
Documents,
Legal issues,
Materials performance

Site design, Ceiling,
Design intent,
Escape routes

IFC 3.0

Estimating

Building Services

Cost Planning,
Scheduling

Articial Lighting,Protectice Devices,
Enclosures, Conductors,
Ducts *, Pipes *,Control Systems

FM

Codes

Assets, Work Order,
Maintenance History,
Area Measurement,
BAS Configuration

Performance based
code checking

ClientGeneric Process Model

Civil/Structural
Steel frame, RC frame,
RC Foundation, Roads,
Railways, Bridges,
Load definition

Construction
Scaffolding,Lifting Device

図１２ IFC リリース3.0 適応範囲

Page 14

IFC End User Guide

現サポート・プロセス
以下では、
IFC でリリースされている建設業界での具体的なプロセスを簡略したものとして紹介しています。
詳しくは IFC 仕様書をご覧ください。また、この情報は、エンドユーザがこのリリース範囲を明確に知ることができるようにまとめています。

意匠設計
IFC リリース1.0 の建築意匠設計プロセスでは、つぎの IFC プロジェクト・モデルがサポートされます。
● 空間設計● 壁配置● ドア配置
● 窓配置
● 建具表

空間設計
意匠設計における初期段階のプロセスのひとつに、エスキースなどを使って建物の空間表現を行なうことがあります。IFC モデルは、面積，用途，
部屋と部屋の隣接関係，建築設備などの情報を含んでおり、効果的に空間を表現することができます。
IFC 準拠のアプリケーションは、計画の与条件をわかりやすく表示し、操作が容易な空間レイアウト機能を持ち、設計者を支援するソフトウェアでなくてはなりません。また、延床面積や容積率などの関連する計画の必要条件を満足しているかどうか、設計者にフィードバックしなければなりません。さらには、この簡単なエスキースから建築図面への変換も必要となります。

壁配置
建物の構造的な変更や、設計プロセスにおけるデザインの試行錯誤の繰り返しによって、図面上で表現する壁の作成や編集に多くの時間と費用がかかります。設計プロセスの簡素化とコスト削減のために、IFC モデルは単に壁を線分で表現するだけではなく、様々な情報を持つ必要があります。つまり、IFC における壁は、例えば壁と他の部分との納まり、材料、仕上げ、および空間との関係などについての情報も含む必要があります。
IFC 準拠のアプリケーションは、設計者が壁の種類や配置、納まりなどを試行錯誤する事に対して、柔軟な壁の作成や編集機能を提供しなければなりません。これらの機能を実現することによって、設計者は様々な角度からの検討を行うことができるようになります。設計の初期段階では、設計者は一本線のスケッチだけで十分です。プロセスが進んでくると、壁の位置や厚さなどが決まり、エスキースやスケッチよりも具体的な図面の方が分かりやすくなります。

Page 15

IFC End User Guide

ドア配置
現在の CAD では、設計している壁にドアを挿入・移動するといった変更作業に手間がかかるものがあります。また建具表などを自動作成するといった設計者を支援するような機能も十分に提供されていません。これらの問題を解決するために、例えば、IFC モデルのドアに対して、様々な情報を持たせています。IFC のドアは、サイズ、形状、
開き勝手、材料、建具枠、納まり、取り付け金具や仕上げなどの情報を含んでいます。さらに、挿入された壁についての情報も関係として持ちます。
IFC 準拠アプリケーションで壁にドアを挿入するなどの機能は、設計作業プロセスを簡単に、しかも柔軟な
ものにします。この機能を持ったアプリケーションを使えば、ドアをいつでも何度でも変更することができます。設計者は、材料，開き勝手，納まり，および仕上げなどを後で決定したりします。この性能的な情報は建具表などの作成、空調性能評価や動線計画時の開口部評価の様な検討に利用するアプリケーションで有効になります。

窓配置
ドアと同様に、設計中の壁に窓を挿入したり、その窓を移動したりする作業
は、現在の CAD では手間がかかり、非効率的なものがあります。IFC 準拠ア
プリケーションでは、窓を配置したり移動したりする作業を簡素化し、自動化したコマンドとして作成することによって効率的になります。IFC の窓は
開口幅や高さ、形状、開き勝手、材料、窓枠、額縁、納まり、取り付け金具、仕上げ、およびグレージングのタイプについての情報を持っていなければなりません。そして、その窓のある壁の接続情報も含まなければなりません。
IFC 準拠アプリケーションは、壁に窓を挿入する機能などを持つことで、以上の設計作業プロセスを簡単に、しかも柔軟なものとします。これらのアプリケーションはいつでも、何度でも窓の詳細情報を変更することができます。設計者は、窓の配置に当たって、開口幅と形状を先に定義し、開き勝手、窓枠の材料、仕上げおよびグレージングのタイプなどの定義を後回しにしたりします。
この窓の性能的な情報は、建具表などの作成、断熱性能の評価、および採光計画などを検討するアプリケーションで有効になります。

建具表
現在、標準的な建具表の作成は、図面上の建具とは連動せず、手作業で拾っているのが一般的です。CAD
システムの中にも、図面上から図形を選択し、半自動的に建具表を作成することができるものもあります。
しかし、これらは正確に建具を拾ってくれず、常に図面と建具表の整合性をとりながら作業を進めなければなりません。
IFC のドアと窓の表現は、設計していく上で必要な情報を明確で無駄のないモデルとして提供しなければなりません。建具表作成の機能を持つアプリケーションは、拾い出しプロセス（数量把握）の単調な作業を自動化したり、見たい建具だけを図面上（一層分の平面図、部分的な平面図、平面図全体など）で表示したりする機能が必要となります。さらに、建具表のフォーマットにあわせて出力する作業において、例え

Page 16

IFC End User Guide
ば窓やドアの追加・削除に柔軟に対応できるような機能も必要となります。

空調設備設計IFC リリース1.0 の空調設備の記述の中で、以下の２つのプロセスを定義しています。
● 空調負荷計算用の面積拾い出し● 機器の選択と機器表の自動作成

空調設備負荷計算用の面積拾い出し
建物の冷暖房負荷最大値に対して、建物形状以外の多くの要因が影響します。このひとつとして、外壁ガ
ラス開口のサイズと向きがあります。これは、日射が熱負荷の重要な要因となるからです。
最近では、最大冷暖房負荷計算用のツールが多数あります。これらのほとんどは、建物の幾何形状の正確な情報を必要とします。外壁部分の情報を定量化するプロセスは、現在、意匠図面をもとに手間のかかる
手作業となっています。この作業には費用が掛かり、さらには誤計測のような人為的エラーにもつながります。このプロセスを自動化することは、設計者にとって効果的な機能となります。
IFC 空調設備モデルを使ったアプリケーションは、事前に定義されたプロジェクト・モデルから、建築幾何
情報を自動的に抽出し、建物の暖房や冷房負荷計算を容易にします。

機器の選択と機器表の自動作成
空調設備設計プロセスの主な作業に、空調設備システムの構成要素として建物中に設置される機器の選定・確認があります。この作業では、設計図面上に個々の設備機器を作図し、機器表による設備機器仕様の表記を行い、相互関係を維持することが必要となります。空調設備設計では、設備機器が設計図面に追加・削除されますが、人為的エラーが原因で、対応する機器表の情報まで適切に変更されないことがあります。
この作業の自動化は、設計者にとって効果的な機能となります。IFC 空調設備モデルを使ったアプリケーシ
ョンは、機器表に設備機器情報を自動表示し、機器選択のプロセスを容易にします。

Page 17

IFC End User Guide

工事管理
IFC リリース1.0 の工事管理において、以下のプロセスを定義しています。
● 数量の拾い出しと見積もり● 工事計画

数量の拾い出しと見積もり
数量拾い出しおよび見積もりのプロセスは、IFC モデルを使うことで容易となります。このプロセスで使う
IFC モデルには、ドア，窓，面積，およびゾーンなどがあります。

工事計画
工事計画プロセスでは、工事工程表を作成します。ここでは、作業情報と数量拾い出しの過程で作成される資源情報、さらには作業規模と構成要素などの計画用に必要な情報を集めることが必要となります。

FM（施設管理）
IFC リリース1.0 では、以下のプロセスをFM 分野で定義します。

設備・家具などに関する施設管理
施設管理者の作業には、設備や家具などの把握、およびその空間占有に関する管理があります。これらのプロセスを簡素化するために、IFC モデルでは、これらに関する情報を含まなければなりません。IFC 準拠のアプリケーションは、このプロセスにおける単調な作業を自動化しなければなりません。
例えば、設備・家具などに関する選択規準や設置位置、および空間占有との関係についての検索条件を持つ必要があります。さらには、検索一覧表が容易に作成することが必要です。

Page 18

IFC End User Guide（付録）

付録Ａ−建設業界における相互運用
著者 Ken Herold，IAI 北米支部 Executive Director， 1995 年 6 月

1 つ屋根の下に住む他人
今日の建設業界は、さまざまな業種で構成されています。各業種は、独自のプロセスと技術を駆使して、物理的な実体である「建物」という共通の目標を目指します。 AEC（建設）プロセスの関係者の多くの場合、気持ちの通じ合った
１チームというよりはむしろ、ひとつ屋根の下に住む別々のファミリーのようなものです。それぞれのファミリーは、ファミリーごとの目標，
必要性そして文化を持ちます。ここでの大なる挑戦は、異なるグループの中での要求を総合化
し、ひとつのファミリーのように振舞うことです。AEC 市場の法的な問題のほとんどは、純粋な建築の失敗を除いて、最後には設計者と施工管理者とが相対することになり、施主が巻き込まれるという事で起こります。AEC プロセスを再設計するためには、２つの重要な点を変更しなければなりません。第 1 は、後述の自動車業界の例のような AEC 関係者のパラダイム・シフ
トです。第２は、協調し合うプロセスを支える技術に対する強い要望です。チームとサービスをモットーとする業界にとって、情報を共有するための明確な方法論や技術が、各関係者とさ
まざまな技術的ニーズの間に必要です。
現在、協調的にデータを共有する（相互運用）
方法論や共通の建築モデルを実現する(オブジェ
クト指向データ)技術論があります。

共有されない情報
これまで、AEC の専門家は、２次元の図面上で実質的に情報交換を行ってきました。レイヤーを使用したり、物理的にアイテムを示す記号を
各業種用のレイヤーに配置して実現しました。
例えば、室内展開図の照明スイッチと電気設備
計画の照明スイッチは、同じものですが、２つの別々な図形と属性に分かれています。どちらか一方を変更しても、もう一方は変更されません。その他の例としては、平面，立面そして３次元モデル用に、３つの別々な要素で表示される窓の図形があります。別々の図形によって、情報を伝える建物の各アイテムの同じ性質は、
建築専門家の設計プロセスの一貫性を妨害するようなエラーを起こします。
共通の建築モデルを使用することで、専門家の情報を保存する方法や再表示する方法が変わります。シンボルの表示方法や、他の業種から表示に必要なシンボルの継承方法を、建築オブジ
ェクトとともに保存または参照することができれば、システム上で異なるレイヤーに別々な表現を保存する必要がなくなります。トレースしたり、情報をどのレイヤーに表示するかということは、現在では建築の専門家が行います。共通の建築モデルは、建築専門家の間でのやりとりが必要とされる場合に、作図または計算機能が実行されます。
共通の建築モデルを使用すれば、AEC 業界は、レイヤーを意識した作図から離れることができるでしょう。パラダイムは、物理的オブジェク
ト、すなわち、建物空間に配置される壁，窓，
ドア，そしてダクトなどを表示するでしょう。
オブジェクトは、必要な場合、それ自身を表示／非表示することができます。オブジェクトの全情報は、オブジェクトと共に保存されますので、仕様書と費用が自動的に連動することになります。整合性は、作図される個々のオブジェ
クトとオブジェクト間に関連がはられてますので、この問題は、やがて軽減されることになるでしょう。

ＣＡＤの発達最近１５年以上にわたり、AEC での科学技術の利用は、段階を経て発達してきました。線分による描画，円などを線分で作成，繰り返しの多い図面用テンプレートとして要素をグループ化，

付録 1

IFC End User Guide（付録）テンプレートにテキスト属性を付加，そして非図形情報検索用にリレーショナル・データベー
スとテンプレートを接続するというような段階です。すべての場合、CAD は、プログラムと非図形データ(リレーショナル・データベース)とに独立していました。このような方法では、物理的な世界は、接続されない非自動的な状態でしか機能しないことを示しています。リレーショ
ナル・モデルの中で、複数のテーブルにまたがった正確なデータの作成，関連付け，それに管理に関しては、十分に注意を払う必要があります。リレーショナル・モデルは、表形式の情報がうまく生かせる金融業界などでは機能的と言えます。問題は、建築が、自然の法則に逆行す
る物理的な独立オブジェクトを基礎としていることです。
将来の方向性の最も良い手本は、自然を観察することです。自然界では、建物は、空間に位置しています。環境に影響され、その相互作用が起因となって反応します。新しいオブジェクト指向の技術は、自然の機能性をよく反映しています。鉄骨の梁のようなオブジェクトは、表示
用の情報，断面のサイズ，長さ，そして他の接続フレーム・オブジェクトに対する振る舞いに関係する非幾何学情報を含んでいます。要素はそれ自身で機能することから、例えば、接合オ
ブジェクトの反力計算や風力シミュレーションの場合において、それ自身の曲げや反りを計算する機能を持っています。この技術は、自然界でオブジェクトが機能する方法とよく似ています。

プロジェクト情報の解釈
業界におけるその他の問題は、現在、異なるリソース（資源）が持つ情報によって、さまざまに解釈されることです。AEC 業界では、建築企
画，図面，仕様書，積算，スケジュール，およびプロジェクト記録などの情報のタイプを考慮
して、すべて異なる形式で独立して保存されます。建築プロセスを通して、一般的に、情報は変換され，解釈されて、意図と解釈の間でギャップを埋める新しい情報が取り込まれます。別の問題点は、決定プロセスの間で作成される情報が、つねにプロセスの後半になって、意図を解釈するために取り込まれないで、保存されな
いということです。
例えば、同じプロジェクト・データベースで失われるか、含まれていないいくつかの情報には、
計算書，空間計画書，そして図形とテキスト両方の決定文書などがあります。プロジェクトに関係する情報が失われるということは、設計の意図が失われ、プロセスを通して同時に作業するすべてのグループの解釈に任されます。共通の建築モデルは、潜在的に履歴情報オブジェク
トのレベルで更新され運用されます。

異なる考え方ビジネス界のある人たちは、１０年前の自動車業界を思い出します。この業界は、現在の AEC
業界と同じ方法で機能していました。工場内の各担当グループと納入業者は、独立した機能グ
ループに編成されていました。それは、設計，製造，販売，マーケティング，管理の各グループでした。それぞれの機能グループは、独立して機能し、次の担当グループに対しては、最終の成果を渡しました。日本の品質プロセスのために、アメリカの業界は、やむを得ず競争をしながらパラダイム・シフトをしなければなりませんでした。変化は、機能的な範囲ばかりではなく、車の製造プロセスに集中する競争を操作することでした。まず始めに、大きく公表された変化は、 LH ラインの最終成果に焦点を合わせたクライスラー社とその関連会社チームでした。慣習を変えるために、プロジェクトの開始時点で、クライスラー社は、すべての機能の範
囲、すなわち設計，製造，販売などを１つのチームとして組織しました。変更点は、全プロセ
スを通して、関係する業種の考え方や問題、そして障害に対してスムーズに対応できるように、プロセスの開始から終了までを共同で作業するチームとして各業種を統合することでした。この結果、エラー，コストそして LH シリーズの自動車の出荷時間がかなり減少しました。
AEC 市場でも、慣習的な面で、同じような変化が期待できるでしょう。

付録 2

IFC End User Guide（付録）Linear Interoperability
Horizontal Information Sharing

Vertical Information Sharing

Concurrent Interoperability

Strategic
Planning

Programming

DesignProduction

Bidding

Construction

Facility
Management

Facility
Programming
Architecture\Interiors\Landscaping
Engineering
Construction Management
Building Owner
NOTE: Any of the participants may be oversea’s
Global Interoperability

プロジェクトの開始時点から共同で作業することになる施主，建築家，エンジニアそして工事管理者は、設計の構築の可能性やコスト管理を
プロセス間を通して行うことができます。結局は、思いがけない建築上の問題をカバーし、あるいは変更を減少することができれば、工事費用の追加を減少することになります。現在、プロセスの中で軽減することが可能なその他の事例としては、建築専門家のプロセスとその後で工事管理者が見積もりを作成するという、別々に行なわれるプロセスが原因で起こる施主の予算に合わせた再設計があります。
AEC 業界でも、自動車業界がどんな協調プロセスにも対応してきたような同様の技術的変化が必要でしょう。自動車業界は、CAD／CAM とその他の科学技術を駆使して、機能の統合や強化をしてきました。AEC 業界は、もう 1 ステップ
先に進まなければならないでしょう。次のステップが必要になる理由は、チームでの協調作業
を同じ組織内で行うことができる自動車業界と異なり、AEC の建築サイクルは、独立した担当者で構成されるということからです。
建築のライフサイクルを通して、担当者が同じ組織の一員ではないという理由から、各メンバ
ーがプラグ・アンド・プレー形式で行うことができ、組織に合った技術で使用できるような相互運用が可能な情報とシステムの統合化が必要でしょう。オブジェクト指向は、基本の技術を提供します。その基本技術は、相互運用が可能な建築要素と材料レベル、すなわち壁，ドア，
ダクト，梁などのレベルで情報を作成、纏め上げられます。それは、各業種が、オブジェクトと共に保存され、そして建物ライフサイクルの中で、他の関係者が共有できるような独自の情報を、セットで提供するオブジェクト・モデルの機能で継承されます。

時間と距離に沿った情報
AEC 業界の共通な建築モデルには、並行に働くチーム（コンカレント作業）と、時間に沿って働くチーム（リニアー作業）のための配慮が必要です。プロセスにおいて同時に発生する事柄
は、社内と関連業種のチームの双方に影響があります。
一般に、社内や関連業種内のプロセスは、プロセスの部分を展開する同じ専門用語と技術を使用する建築チームや構造チームのようなメンバーで構成されます。相互運用のための共通な建築モデルは、将来、プロジェクト間の各業種内のチームの調整のキーとなり、プロジェクトのためにオブジェクトが蓄積され、再利用できるようになります。プロジェクト実施中に、問題が発生したときや、機会あるごとに、新しい解決策が出てきます。しかし、現時点では、このようなプロジェクトで学んだり経験したりした
一部の解決策は、脇に置いている間に、蓄積できず、失われてしまいます。
一貫した相互運用を行うには、様々な業種で、１つの建築モデルを作成するための情報の伝達，統合，そして情報の明確化が重要です。関連する業種で一貫した統合の必要性の例として、ひとつの図面類を仕上げるために、意匠，構造，

付録 3

IFC End User Guide（付録）設備，それにインテリアなどの各種業種間の関係において、並行して展開し、設計の協調と統一が必要となります。建築モデルは、各フェー
ズを通していつでもプロジェクトに合致する必要があります。
プロジェクトの部分役割を担って展開し、そして次のグループに渡していくというプロセスは、
AEC 産業ではごく一般的なプロセスです。これは、施主が、プロジェクトの開始時点、つまり現在の戦略に沿ったプランで建物を建築するかどうかの決定時から発生し、建築の計画を展開
していきます。設計／エンジニアリングの業種
では、まずプランが作成され、施主との非公式の契約の後に、入札用に建設管理者にプランを公開して、その後、契約者に渡ります。多くの場合、サイクルの最終段階で、施主は実際の設
備の保守管理用の情報を受け取ります。プロセ
スを通して、実際の情報は、 契約者用の紙図面
セット用の形式に変更されるでしょう。どのような場合でも、建築モデルを使用する多くのユーザにとって、独自の技術を必要とします。技術は、複数の建築製図システム，構造解析モジ
ュール，積算，スケジューリング・パッケージ、または保守管理システムであるかもしれません。
真に柔軟でそして全てのプロセスで利用できる
ためには、業種で作業を行うための情報の追加や変更において、相互運用的で最適な手法で行えることが必要となります。全てのシステムは、共通の建築モデルである情報を共有するための共通の記憶方法を合わせて持たなけれなければなりません。

世界的プロジェクト
建築業界が、企業から国家的に、そして最終的には国際的なプロジェクト・チームに移行する
につれて、情報を共有しなければならないという必要性は、世界的規模で重要となります。協
調や情報を交換するために、相互運用の共通な建築モデルを使用すれば、世界的プロジェクトでの高いコストを大幅に削減できるでしょう。
現在、国際的に渡航をするメンバーの航空運賃と物理面で、多くの費用が発生します。異なる
時間帯のチームで、情報を共有することができるような機能を持つことは、終日そして世界中で働き続けるようなプロジェクトを可能にします。グループ間でのコミュニケーションとして、共通の建築モデルと相互運用ができるソフトウ
ェアを使用すれば、人間の交渉やコミュニケー
ションのレベルではなく、情報のレベルで行うことができます。さらに共有の建築モデルを使った進んだ使い方を行えば、例えば文書やアプ
リケーションの使い方をサポートするためにテレ・ビデオを使用することで、ビジュアル化された会議が行うことができ、この共通な建築モ
デルの使用が拡大していくでしょう。共通の建築モデルを共有すること、そしてテレ・ビデオの使用は、移動に掛かる出張コストを削減し、アド・ホックな会議の自由度と効果を増大するでしょう。さらに将来において行動決定や決定
意図を保存することが可能になれば、情報は連
続的な時間帯で選択・使用することができ、電子的な形式でプロジェクト調整が可能となります。

情報と企業内チーム
前述したように、オブジェクト指向技術と相互運用は、社内の単一業種のチーム内と同様に、複数の業種と他の会社の間でも大きな利益をもたらします。このことは、２つの機会、第一に情報の整合化が可能な点と、第二に経験とガイ
ドラインを蓄積できる点で感じ取ることができます。
第一の整合化とは、情報自身や情報を操作してできる全情報を含む共通の建築モデルの機能によって制御できることになります。例えば、ドアを削除する場合、ドア内部の振る舞いによって削除され、さらに共通な建築モデルでの壁なども関連を取ることになります。建具表は、現在の建築モデルのリストであることから、図面上に作図されたドアの正確な数と情報を継承する機能があります。今日まで、振る舞い，テキスト，および図形情報は、リレーショナル・デ
ータベースと製図システムの別々のシステムとして扱われてきました。このことは、両者が別々の技術に分かれていたために、データベースのフィールドが無いために図形処理が難しくなる
か、その逆などがあったことによります。図形
上のドア情報と関連する建具表の情報の間で、1

付録 4

IFC End User Guide（付録）対 1 の関係になる共通の建築モデルのような情報が整合化されたものにとっては、厄介でコストの掛かるのを軽減するでしょう。
第二の新しい技術に取り組む機会は、チーム・メンバーの経験レベルと知識の間に矛盾が生じるときです。共通の建築モデルが、振る舞いと他のオブジェクトとの関連を持つことで、将来的にモデルの中にプロジェクトの経験を移行し保持するするための強力なツールになっていきます。例として、平面図と関連する詳細図において、壁や間仕切りが関係する図面の保守管理に最も手間がかかります。将来、共通の建築モ
デルは、部分詳細図のような図面を構成するオ
ブジェクトの集合を持つでしょう。鉛直スタッドなどに振る舞いを付加するれば、メッセージやリアクションは、耐火壁であることを示すことを図面に伝えることができます。システムは、間仕切りが構造の上に明確に位置することで、詳細図に変更が必要である反応や建築家への示
唆ができます。間仕切りに関係する他のオブジ
ェクトは、建築家にドアも耐火用でなければならないことを示唆することができます。決定の可能性ある経験的なものは、例えばシステムが
床から床高さまでを知っていて、詳細図で間仕切りの構造が鉛直方向の距離間で配置決定されます。将来の構造的な支援を行ってくれるシス
テム例で、相互にメンバーが接続しているスパンを検討する場合、処理スピードを上げ、ミスを削減するような決定プロセスに変わるでしょう。このようなタイプの問題では、現時点のユーザにとって、一般的に時間の制約やプロジェクトの経験不足が原因となって見逃されるかもしれません。
早い時点での指摘として、将来、システムを使用するユーザは、法規やその他の規則によって建築モデルに統合さるなければならない山のような情報の回答支援を受けることができます。
規則や法規の ADA や BOCA などは、機能として組込み、対話形式で使用することができます。
例えば、平面図上にトイレの仕切りのドアを配置する場合、システムは、ユーザに対して ADA
コードに従っていないことを気付かせなければなりません。また、ドアと照明スイッチの関係のように、関連するアイテムの配置の規則も管理されます。ドアを壁に沿って移動する場合は、ドアの開き（幅）とスイッチの位置は、お互いに関係しながら移動することができます。ドアが今までと異なる向きの壁に配置される場合、オブジェクトは、新しい位置に合わせて変更しなければなりません。オブジェクトとその振る舞いによる機能の全ては、時間的または法的のいずれかの人為的なエラーによって発生するコストを削減できるでしょう。

タイミングと情報のアクセス
オブジェクト・モデルを使用するサイクルの中で、建築プロセスを通して、早めに情報が提供されることで決定機能をアップするような状況がよくあります。しかし現状で、早めの情報の提供に対して、障害となることの１つに、その業種に有効な基本の情報の再構築や再変更に費やされる大変な作業量があります。良い例としては、プロジェクト・コストの見積もりがあります。現在、図面からプロジェクトの見積り用の数量の拾い出しには、多くの時間がかかります。問題点は、図面とコストとの間に強い繋がりがないだけではなく、他の業種による変更の追跡や決定がないことにあります。プロセスに関係するコストやスケジュール・テンプレート
を持つオブジェクトを使用することで、コスト計算は、プロセスの中で速く、そしてより早い時期に作成することができます。また、建築モデルが拡大された場合、その拡大部分のみがコストとして更新されます。その他の利点としては、このテンプレートを使用したシミュレーシ
ョンのツールと時間を持てるということです。
工事管理者は、標準のスケジュール・テンプレートを使用したり、または建物用にコンクリー
ト構造物のような建物を建てる施工プロセスに適用される新しいテンプレートを作成することができます。テンプレートを変更すれば、オブジェクト・モデルは、最も適したコストを決定するための類似のものを作成することができます。このオブジェクト・モデルは、情報をより早く入手することができるばかりか、正確な情報が必要な詳細図と任意のビューにも対応することができます。

付録 5

IFC End User Guide（付録）

ベンダーの新しい役割
将来、共通の建築モデルと相互運用は、製造業
者と建築業界との関係を変えるでしょう。物理的なアイテムを提供したり、振る舞いとルールを包含する共通の建築モデルを表現することによって、ベンダーは、実際の設計と施工システ
ムのやりとりの部分を提供することができるでしょう。可能性は、オブジェクトが設計意図を反映し、プロジェクトの環境能力に対して柔軟に合わせて考慮することです。このような理由により、建築業界は、設計の中で、プロジェク
トのゴールに最も効果的に決定できる製品を、ベンダーによって切り替えていくことができます。
共通の建築モデルを使用することで、よりオープンで適用性が高く，拡張性のある建築モデルを提供する機会が出てきます。AEC 業界にとっての意義は、専門家が、製品ベンダーやソフト
ウェア・ベンダーが作成するどんなソフトウェ
アでも使用でき、しかも同じ建築オブジェクト・
モデルで終了することができることです。これが、相互運用の定義です。

フォーマットと将来の情報
CAD の使用と情報の共有の歴史の上で、エレメントをどう作成・保存し、その後どう使用するかで、常に不具合が生じました。図形の作成は、その時の担当者に任されることで、基本情報が、その後の段階になって不適当となる場合もあります。例えば、ブロックなどのエンティティを使用するところを線分や多角形，円，その他などの基本的なエンティティを使って建物情報を作成してしまうことです。もし、トレーニング
や時間が原因で、接続情報をエンティティに組み込むのを、線分に設定するならば、その他の業種の作業効率を下げることになり、そのプロ
セスや同じチーム内ではさらに効率を下げるでしょう。

とから、オブジェクトが、どう作成，操作されるかを制御することで、知的な機能を持ちます。
共通の建築モデルでは、全てをオブジェクトとして保存します。

結論
業界に対する今後の可能性は、製造者サイドば
かりではなく、ビジネスの専門家サイドに焦点を合わせることです。ここ１０年以上、我々専
門家は、作図作業で CAD を使用することに力を入れてきました。相互運用と共通の建築モデル
により、最終的にはエラーの減少，時間の短縮，
およびコストの削減を促進し、プロセスの決定と整合で支援するシステムを持つことができます。
相互運用をサポートし、共通の建築モデルを作り管理するという新しい技術により、ソフトウ
ェア開発方法のパラダイムが変わりました。このプロセス間の変化は、機能的チームのアプローチの議論で早くから述べられていたことと一致しています。プロセスは、共通の建築モデルを設計するソフトウェア・ディベロッパー，工事管理者，建築家，エンジニア，建築製品業者，
および研究といった建築サイクルに従事する多くの関係者とともに、プロジェクトの始めからありました。それぞれの関係者は、設計と、多くの場合にはその相互運用という観点での実施を行ってきました。最終的な成果は、まもなく IAI
によりリリースされる IFC(Industry Foundation
Classes)です。このプロジェクト発端からのコン
セプトは、業界のだれでもが開発し、促進していく、オープンな標準でした。促進することに関心を持つ多くの業界の加盟により、全く非営
利的な立場の IAI が創設されました。上述したよ
うに、企業内だけの経験の推移ではなく、業界を通しての推移であることを期待しています。

共通の建築モデル情報を使用すれば、オブジェ
クトが全ての情報を持っていますので、情報の操作方法が変わってきます。図形は、属性と振る舞いを備えたオブジェクトの一部分となるこ

付録 6

IFC End User Guide− メモ −

付録 7

IFC End User Guide（付録）− メモ −

付録 8

IFC End User Guide

IAI 日本支部事務局〒134‑0088
東京都江戸川区西葛西 6‑16‑4 エスペランス 6F
TEL 03‑5676‑8471
FAX 03‑5696‑2862

E-mail office@ml.interoperability.gr.jp
ホームページ日本支部
http://www.interoperability.gr.jp

International

http://www.interoperability.com

付録 9