この記事の要点: Revitアドインは「作って終わり」になりません。Revit本体はほぼ毎年メジャーバージョンが出て、そのたびにアドインは作り直しに近い対応が必要になります。なぜそうなるのか、どのくらいの手間がかかるのか、保守契約で何を決めておくべきかを整理します。
社内でRevitアドインを導入したものの、数年後にはほとんど使われていない——というのは珍しい話ではありません。多くの場合、機能が悪かったのではなく、Revitのバージョンが上がったときに動かなくなり、そのまま放置されたことが原因です。
この記事では、その仕組みと、防ぐために契約・運用の段階で決めておくことをまとめます。
アドインの発注そのものについてはRevitアドイン開発の外注ガイドを、できることの全体像は建設業のBIM・Revit API活用ガイドを、Dynamoとの使い分けはこちらをご覧ください。
なぜバージョンが上がると動かなくなるのか
Revitアドインは、Revit本体が提供するAPI（プログラムから機能を呼び出すための窓口）を使って作られています。このAPIは、Revitのバージョンごとに別物として扱われます。
アドインは、対象バージョンのRevitに付属する部品を参照してビルドします。参照先が変われば、ビルドし直しが必要です。
バージョンによっては、使っていた機能が廃止されたり、呼び出し方が変わったりします。この場合はコードの修正が必要になります。
Revitが動作するために必要な実行環境（.NET）のバージョンが上がることがあります。そのタイミングでは修正量が増えがちです。
リボン（画面上部のメニュー）の構成や既定の動作が変わると、アドインの配置や前提が合わなくなることがあります。
つまり、「今年のRevitで動くアドイン」は、来年のRevitでそのまま動く保証がありません。 これは作り方が悪いのではなく、Revitというソフトの構造上そうなっています。
対応にかかる手間は「毎回同じ」ではない
バージョンアップ対応の手間は、年によって大きく変わります。
| ケース | 必要な作業 | 手間の目安 |
|---|---|---|
| APIに変更がない年 | 参照先を差し替えてビルドし直し、動作確認 | 小さい |
| 使っている機能の仕様が変わった年 | 該当箇所を書き換えて再検証 | 中程度 |
| 実行環境（.NET）が変わった年 | 全体の再構成と、広範囲の動作確認 | 大きい |
| 複数バージョンを同時にサポートする場合 | バージョンごとにビルドと検証を実施 | 本数に比例して増える |
ポイント: 費用が読みにくいのはこのためです。「毎年いくら」と固定しにくいので、保守契約では「軽微な対応は月額に含む／大きな変更は都度見積もり」のように、線引きを決めておくのが現実的です。
保有するアドインの本数で考える
アドインが1本なら年1回の対応で済みますが、社内に10本、20本と増えていくと話が変わります。バージョンアップのたびに全本数の確認が必要になるためです。
- 本数を把握する — 誰がいつ作ったか分からないツールが混ざっていることがあります。まず棚卸しをします
- 使われているものを選別する — 実際に使われていないものは、対応せずに廃止する判断も必要です
- 優先順位をつける — 業務が止まるものから先に対応します。全部を同時に上げる必要はありません
- 共通部分をまとめる — 複数ツールで同じ処理をしているなら、共通の部品に切り出しておくと、次回以降の修正が1箇所で済みます
保守契約で決めておくべき項目
トラブルになりやすい順に挙げます。
| 項目 | 決めておくこと |
|---|---|
| バージョンアップ対応の扱い | 月額に含むのか、都度見積もりか。含む場合はどこまでを「軽微」とするか |
| 対応するバージョンの範囲 | 常に最新1つか、複数世代を維持するか |
| 対応の期限 | Revitの新版が出てから何ヶ月以内に対応するか |
| 不具合対応 | 連絡方法、一次回答までの目安時間 |
| 軽微な改修 | 月あたり何時間まで含むか |
| ソースコードと資料 | 納品されるか。他社に引き継げる状態か |
| 契約終了時 | 引き継ぎに何を渡してもらえるか |
「他社に引き継げるか」を必ず確認してください。 ソースコードとビルド手順が手元にないと、開発会社を変えたくなったときに作り直しになります。これはRevitアドインに限らず、受託開発全般で起きる問題です。
「使われなくなる」を防ぐ運用
技術面だけ整えても、運用が抜けていると使われなくなります。
「動かないときにどこへ言えばいいか」が不明だと、誰も報告せずに放置されます。窓口を1つに決めて周知します。
Revitを更新する時期は、情報システム部門が握っていることが多いものです。開発側が事前に把握できていれば、間に合わせられます。
どのツールが何回使われているかを記録しておくと、保守の優先順位も廃止の判断もつけやすくなります。
新しく入った人に誰も使い方を教えないと、数年で存在自体が忘れられます。短い操作動画を1本残しておくだけでも違います。
新規に作るときに、あとで楽になる作り方
これから発注する場合は、次の点を最初に伝えておくと、将来のバージョンアップ費用を抑えやすくなります。
- バージョン依存部分を分けてもらう — Revit固有の処理と、業務ロジックを分けて作っておくと、バージョンアップ時に直す範囲が小さくなります
- 設定を外に出してもらう — しきい値や命名規則をコードに埋め込まず設定ファイルにしておくと、ルール変更のたびに開発を依頼せずに済みます
- 動作確認の手順を残してもらう — 何をどう確認すれば「動いている」と言えるかが決まっていると、次回の検証が速く安く済みます
- ログを残す作りにしてもらう — 不具合の連絡を受けたとき、原因の切り分けにかかる時間が大きく変わります
注意: これらは「あとで効いてくる」対策です。初期の開発費はやや上がることがあります。1〜2年で使い終わる想定のツールなら、そこまで作り込まない判断も妥当です。 長く使うかどうかで決めてください。
まとめ
- Revitアドインは、Revit本体のバージョンが上がるとそのままでは動かないことがある。作り方の問題ではなく、構造上そうなっている
- 対応の手間は年によって変わる。実行環境が変わる年は大きくなりやすい
- 保守契約では、バージョンアップ対応を「月額に含む／都度見積もり」のどちらにするかを必ず決めておく
- ソースコードと資料が手元にあるか（他社に引き継げるか）は、契約時点で確認する
- ツールが増えたら棚卸しをして、使われていないものは対応せずに廃止する判断も必要
- 連絡先・更新予定の共有・使い方の説明といった運用面が抜けると、技術的に問題がなくても使われなくなる
JIT株式会社は、Revitの業務アドインを3年以上にわたって約50本開発し、リリース後の機能追加や、Revit本体のバージョン更新に合わせた改修も継続して担当してきました。
「以前作ったアドインが動かなくなった」「作った会社と連絡が取れない」といった引き継ぎのご相談も承っています。まずは現状を教えていただければ、対応できる範囲と進め方をご提案します。お気軽にご相談ください。