まず最初に、自分が３年前にどのような内容を寄稿したか振り返ってみる。^※１
 
2022年当時、BIMは単なる設計・施工の３次元ツールではなく、発注者が「何のために・どの情報を・どの水準」で要求するべきかを明確にし、「不動産情報」（AIM）の集積体を運用するためのツールたるべきと結論付けた。
ISO19650の規定でAIMが“起点番号の１”と示されていたのは（図-1）、運用情報が“結果”ではなく“出発点”で規定されるべきことを示している。
つまり、私たちが本当に欲しいのは「整った３次元モデル」それ自体ではなく、竣工引き渡し後に運用を開始してから“使える”情報を集積して、運用できるツールであること―これが当時の寄稿の骨子であった。

 
本稿はその続きである。
建物の運用を開始してのち、今日までを運営側の当事者として３年間の足取りを、前に進めたところも立ち止まったところもありのままに書き留めたい。
先に結論を置くなら、私は今、呼び名（BIMでもAIMでもPIMでも）にこだわりはない。
肝心なのは“更新が止まらないツール”を用意すること、そして“指定したい場所を迷わず特定“できることである。
３次元か２次元かは、その次の問題にすぎない（図-2）。

 

BIMの“Ｍ”はしばしば「３次元モデリング」を連想させる。
だが、運営で必要な“モデリング”とは形の作図ではなく情報の構造化だ。
すなわち、どの区画（部屋）に、どの設備（型式や性能）があり、どのような状況（点検・障害・工事）で、誰が、いつ、どのように対応するか―この関係と対応の作法まで含めて考慮されていなければ、どんな精緻な３次元モデルであっても日常的に運用しきれない。
この事実を見ると、運営に必要な“ビル情報のモデル”は２次元でも十分に目的を果たすことができる。
区画・設備などに共通のIDを割り振り、台帳・履歴・写真・契約・日報などの各種情報と相互にリアルタイムで連携できるなら、それは立派なBuilding Informationであり、日常的な意思決定に十分活用できる。
もちろん３次元モデルを否定するものではなく、むしろ節目の検討（大規模改修、耐震・避難、安全検証、新たな投資の意思決定）では、決断を促すツールになると感じている。
しかしながら、日常業務で必要なのは“場所×台帳×出来事”である。
 

竣工引き渡し直後、私たちは建設会社が提供する維持管理パッケージ^※２を導入した。
対象は新築のテナントビルである。
BIMモデルはビューアで参照でき、管理会社にも協力をいただき、日報を直接データ入力してもらう運用を実現した。
これはこれで有効であり、新たな取り組みとして得るものは多かった。
報告が雑多のメールに埋もれず、所定の箱に落ちてくるような安心感があった。
一方で、日々BIMモデルを開いて確認する機会はほとんどなかったのが現実であった。
一刻を争う現場判断は、ときに一本の電話と数枚の写真で進んでしまう。
結果として画面を定常的に見ているのは主にビル担当者で、他の関係者には期待したほど波及しなかった。
 
さらに、私たちは複数の不動産を所有しており、一棟だけ“特別扱い”でパッケージに載せ、他はアナログ手法での従来運用―この二重管理は労多くして実りが少ないことを痛感した。
一方で全物件を一斉に統一しようとすれば、ライセンス、教育、権限設計、サポートなどのコストが実際得られる業務効率の改善や、建物管理品質の向上とバランスするかを考えると、どうひいき目に見ても合理的投資にはなりえないことは明白であった。
この板挟みの中で、前稿の考え方を、日々の運用の言葉に置き換えて捉え直した。
「正確さ」を目指して更新が止まるくらいなら、多少「妥協」しても業務が回り続けることを優先すべきだ。
しかも、全物件に横展開できるツールでなければ意味がない、と。
 
 

私たちは、kintone^※３を土台に運営情報の受け口を一本化する方向で動くことを決め、プロジェクトを立ち上げた。
狙いは機能の多彩さではない。
誰でも書ける／今日から止まらない／全物件に広がる、の三点を他の全てに優先させる。
点検、障害、修繕、契約、請求、テナント、問い合わせ、図面・写真―日常の入り口を一カ所にまとめて、権限と履歴でしっかりと管理する。
 
管理会社や協力会社には自社アカウントがなくても直接入力できる導線を設け、合意形成より前に“事実の記録”が先に落ちる流れをつくる。
そして、われわれは維持管理の専用ソフトから自作のKintoneで管理する体制へ乗り換えにかじを切った（図-3）。

 
システムは切り替えたが対象のビルでは当初から委託先は変わっていない。
簡単に入力できることを重視して設計したため、移行初日から何のトラブルもなく委託会社も問題なく日常業務が移行できた。
運営において大事なことは担当も体制も“時間とともに変わり得る”ものとして設計しておくこと、そのためには簡単に使えるものであること―これが長期運用のための要諦だと実感している。
属人的なPCフォルダーやメールに情報を閉じ込めさせないように“、箱は一つ、入り口は複数”。
この備えが、長期にわたる運用で効果を発揮し、果実を得られると感じている。
 
 

空間の見せ方は背伸びをせず、３次元を常時保守する道は現状の技術レベルでは選択が難しいと考えている。
運営で本当に効くのは、「どこで何が起きているか」を迷わず示せることだ。
現在はSVG（Scalable Vector Graphics： ブラウザーで扱えるベクター形式の２次元図面）による平面図を実験的に用い、区画にIDを付し、台帳・履歴と双方向に行き来させる試みを進めている（図-4）。
生成AIを活用してSVGとkintoneを連携させるプログラムを開発し、テスト実装にも成功した（図-5）。
すでに日常業務での運用を通して、手応えを得つつある。
完成形と呼べる段階ではないが、“場所×台帳×出来事”が一直線につながるだけで、現場の判断は即時性を確保し、無駄な業務を減らし、業務によるストレス軽減を実現し始めている。

 
 

避けて通れなかったのが、設備分類マスタだ。
現場の言葉と分類の言葉は、想像以上にズレがあることを再認識することとなった。
精度のレベル感、呼び名の違い、タグの扱い。
例えば、「防災」「警備」といった目的語が分類名の中に混ざる、といったちぐはぐさはまだまだ残っているが、ここは拙速にルールを決めることは各階層の常識を否定することになりかねず、丁寧に進めていきたい。
COBie／OmniClass／Uniclass^※４といった枠組みが存在することはこの３年でようやく把握したが、私たちは今、これから理解を深め、外部とつなげる受け口（外部コード列）を用意しながら、社内用語を含めた着地点を探っている最中だ。
動かしながら整える以外に近道はない。
分類は“構造を堅く”、目的は“軽く”―原則はそう掲げつつ、今使える姿に少しずつ寄せていく。
正直に言えば、国レベルでの基準が策定されることで本質的に問題は解決されるとも思う。
 
 

この３年で確かになったことがある。
同じ“BIM”でも、立場によって期待する成果は異なる。
設計・施工が求めるのは形の整合であり、上流から下流まで整備された３次元モデルが一気通貫に流れていくことを理想としている。
一方、運営が日々課題としているのは更新の整合である（図-6）。
台帳、履歴、契約、点検結果等々、そして“場所”。
Building Informationは３次元に限られず、むしろ３次元は重要であるが、その一部に過ぎない。
呼称は運営BIMでも経営BIMでも、ISOの語彙でいえばAIMでもよい。
重要なのは、「誰のための、何のための、どこまでの情報か」を上流で合意し、それが日常で迷いなく更新できる形で下流まで流れていくかどうかである。

 
 

ここで本音を述べると、Revit^※５のような専用ソフトを“日常的に”使いこなせる人材が前提になる運用は、運営者にとって現実的ではない。
これは技術への軽視ではなく、プロセスの中でそのツールとそのスキルが必要な業務があることは承知している。
しかしながら、生産年齢人口が先細る社会で、“完璧な記録”“完璧なモデル”のために常に労力を投じ続けるやり方は経済合理性に合致することは難しい。
経営、不動産運営に重要なのは閉ざされた正確性より、開かれた更新性にある。
間違わないことよりすぐに直せること、全部持つより使う分だけ持ち、足りないときに足す。
この地味な選択の積み重ねが、結果的にミスを減らし、長期の運用、人の入れ替わりによる引き継ぎの永続性を担保すると信じている。
 
 

本稿の読者の多くは、設計・施工のプロフェッショナルだと思う。
運営側から、あえて三点を申し上げるとすると、第一に、場所IDの指定を設計の進捗とともに共有したい。
部屋・ゾーン・設備位置―運用で“知るべき”要素の設計時点での共有は、後々の管理運用時に効果的である。
第二に、情報の受け口の定義を引き渡し図書に含めたい。
COBieであれ独自CSVであれ、“どの列に何を落とすか”の約束があるだけで、運営の立ち上がりが格段に早い。
第三に、更新におけるトリガーの合意だ。
入退去、法定点検、故障、更新工事―どの出来事で、誰が、何を更新するか。
この三点が、“節目は濃く、平時は軽く”という運営設計と自然につながる。
BIM/AIMという呼び名の議論より先に、この三点の合意こそが「設計」「施工」そして「運用（建物管理）」に情報の橋を架ける可能性がある。
 
 

kintoneへ集約を進めている日常の運用情報は、長期の情報集積により“時間と事象の地図”を示してくれると期待している。
どの設備がどの季節に弱いか、どのテナントでどの相談が繰り返されるか、入退去と修繕の波がどこで重なるか、等々。
そこに見えてくるのが、データの美しさではなくスムーズな運営に向けての指標であれば、今後の業務や運営に資する大きな成果となる。
SVGはその地図に向けた仮設の足場に過ぎないが、足場があれば人は動ける。
場所をまっすぐ示せるだけで、日常は前へ進むだろう。
 
さいごにもう一度だけ、言い換えて締めくくりたい。
私たちが形にしたいのは“今日、適切に更新できる運営情報のツール”である。
３次元モデルも、平面の地図も、台帳も、IoTも、契約も―運営に必要な情報は全てBuilding Informationだ。
それをAIMと呼ぼうがBIMと呼ぼうが、どちらでもよい。
大切なのは、更新が止まらないこと。
節目は濃く、平時は軽く。
合意より先に事実を落とし、足りないものは後から足す。
学ぶべき標準があるなら学び、迷ったら戻し、動かしながら整える。
未完成でも動き続ける仕組みが、明日の現場を守る。
私たちはその歩みを、これからも静かに続けていく。
 
協力：企画室 課長 永井 秀之
 
 

---

※1.建設ITガイド2022「発注者目線のBIM－ BIMとはナンナノカ－」
https://it.kensetsu-plaza.com/cad/kiji/post/40467
※2.前田建設工業株式会社「ichroa（アイクロア）」
https://www.maeda.co.jp/tpms/tpmsichroa/
※ 3.サイボウズ株式会社「kintone（キントーン）」
https://kintone.cybozu.co.jp/
※4.
・COBie：建物の引き渡し情報を表形式で標準化した国際仕様。
・OmniClass：建築要素・作業・資材を体系化した北米系分類体系。
・Uniclass：建築・土木を統合的に分類する英国の標準体系。
※5.オートデスク株式会社のBIM統合ソフト。
 
 
 

 
 
【出典】

---

建設ITガイド2026