この記事の要点: Revitの自動化には Dynamo とアドイン開発という2つの道があります。「まずDynamoで試す」は定番ですが、無条件に正解ではありません。 Dynamoで作ったものはアドインに変換できず、移行は実質的に作り直しになるためです。この記事では両者の違い、切り替えるべきサイン、そしてDynamoを経由すべきケースと飛ばすべきケースを整理します。
Revitの作業を自動化したいとき、最初に出てくる選択肢が Dynamo です。ただ、社内で使い始めると「Dynamoでどこまでやれるのか」「これはもうアドインにすべきなのか」という判断に迷う場面が出てきます。
この記事では、その判断基準を整理します。どちらが優れているという話ではなく、向いている領域が違うというのが実際のところです。そして、両者を順番に通る（まずDynamo→あとでアドイン）ことが常に得とは限りません。
Revitアドインでできることの全体像は建設業のBIM・Revit API活用ガイド、外注の進め方はRevitアドイン開発の外注ガイドをご覧ください。
そもそも何が違うのか
Revitに同梱されているビジュアルプログラミング機能。処理を表す「ノード」を線でつないで組み立てます。文字でコードを書かずに作れるのが最大の特徴です。
C#（.NET）でプログラムを書き、Revitに組み込む方式。リボン（画面上部のメニュー）にボタンを置き、独自の画面も作れます。
主な違いを表にすると次のようになります。
| Dynamo | アドイン開発 | |
|---|---|---|
| 作る人 | 設計者本人でも始めやすい | プログラミングの知識が必要 |
| 立ち上がり | すぐ試せる | 環境構築と開発期間が必要 |
| 配布 | ファイルを配る（管理が煩雑になりやすい） | インストールしてリボンに常駐 |
| 使う側の操作 | Dynamo を開く、または Dynamo Player から実行 | ボタンを押すだけ |
| 画面（UI） | 作り込みには限界がある | 自由に作れる |
| 処理速度 | 要素数が増えると遅くなりやすい | 最適化しやすい |
| エラー処理 | 苦手。途中で止まりやすい | きちんと作り込める |
| 外部連携 | 限定的（Pythonノードで拡張は可能） | 社内システム・DB・API（外部サービスとの接続口）と連携できる |
| 保守 | 作った人以外が読み解きにくくなりがち | コードとして管理・引き継ぎできる |
補足: Dynamo には Python を書けるノードもあり、標準ノードだけでは足りない処理を補えます。また、Python でツールを作ってリボンに載せられる pyRevit というオープンソースの仕組みもあり、DynamoとC#アドインの中間的な選択肢として使われています。
Dynamo で十分なケース
「そもそも自動化する価値があるのか」を確認したい段階。作って捨てられるのがDynamoの強みです。
個人の作業効率化なら、配布や操作性の問題が起きません。Dynamoの弱点がそのまま無視できます。
パラメータの一括変更、条件に合う要素の抽出など、分岐の少ない処理はノードでも十分読めます。
プロジェクトごとにルールが変わる処理は、その都度いじれるDynamoのほうが小回りが利きます。
Dynamoは「捨てやすい」ことが価値です。 効果が読めない段階で作り込まないための道具として使うと、投資の失敗を減らせます。
アドインに切り替えるべきサイン
次のいずれかに当てはまり始めたら、アドイン化を検討する時期です。
- 使う人が3人を超えた — ファイルを配る運用は、人数が増えると必ず破綻します。「どれが最新か分からない」「AさんとBさんで結果が違う」が起き始めます
- 処理が遅くて待たされる — 対象の要素数が増えると、Dynamoは目に見えて遅くなりがちです。待ち時間が長いと、結局手作業に戻ります
- ノードが読めなくなった — 分岐や例外処理が増えると、線が絡み合って作った本人でも追えなくなります。読めないものは直せません
- エラーで止まると困る — 想定外のデータが来たときに、途中で止まって中途半端に反映される——という事故が許されない処理は、エラー処理を作り込める側に移すべきです
- Excelや社内システムとつなぎたい — 外部との連携が絡むと、Dynamoでは無理をすることになります
- 作った人しか触れない — 属人化のサインです。異動や退職で使えなくなる前に、引き継げる形に移す判断が要ります
- 操作を人に説明するのが大変 — 「Dynamoを開いて、このファイルを読み込んで…」という手順そのものが、利用の障壁になっています
特に効くのは①と⑦です。 技術的な限界より先に、運用の限界が来ます。「機能としては動くのに、社内に広がらない」という状態は、たいていここが原因です。
判断の目安
| 状況 | 向いている方 | 理由 |
|---|---|---|
| 効果を検証したい | Dynamo | 作って捨てられる |
| 使うのは自分だけ | Dynamo | 配布・操作性の問題が出ない |
| 案件ごとにルールが変わる | Dynamo | その都度いじれる |
| 部署・全社で使う | アドイン | 配布とバージョン管理が現実的になる |
| 毎日使う | アドイン | ボタン1つで済む操作性が効いてくる |
| 大量の要素を扱う | アドイン | 速度を作り込める |
| 止まると業務に影響する | アドイン | エラー処理を設計できる |
| 外部システムと連携する | アドイン | 制約が少ない |
| 長く使う前提 | アドイン | コードとして引き継げる |
迷ったときの原則: 使う人数と使用頻度で決めるのが実務的です。「1人が月1回」ならDynamo、「10人が毎日」ならアドイン。その中間で、かつ効果がまだ読めないなら、Dynamoで作って様子を見る価値があります。逆に効果も要件も見えているなら、試作を挟まないほうが早いこともあります（後述）。
Dynamoの試作は、どこまで無駄にならないか
「結局アドインにするなら、Dynamoで作った時間が無駄では」という疑問はもっともです。結論としては、残るものと残らないものがはっきり分かれます。 まず残るものから見ます。
Dynamoで動くものがあれば、それがそのまま仕様書になります。「こう動くものを、速く・使いやすくしてほしい」と伝えられるのは大きな違いです。
実際に使うと必ず例外が出ます。それを先に潰しておくと、開発の見積もり精度が上がり、手戻りも減ります。
「何分が何分になったか」が分かった状態で投資判断ができます。想像で決めるより確実です。
実際に使った人がいれば、アドイン化したときの利用も見込めます。誰も使わないものを作るリスクが減ります。
開発を外注する場合、Dynamoで作った試作があると見積もりが安くなることがあります。 仕様のヒアリングと例外の洗い出しにかかる工数が減るためです。
ただし、移行そのものにはコストがかかる
ここは正直に書きます。Dynamoで作ったものを、そのままアドインに変換することはできません。 ノードのつながりをC#のコードに自動変換する手段はなく、移行は実質的に作り直しです。
移行にあたって発生するコストは次のとおりです。
| コスト | 内容 |
|---|---|
| 実装のやり直し | ロジックは流用できても、コードは書き直しになる |
| Dynamoを作った時間 | 試作にかけた社内工数。効果が出なければ回収されない |
| 学習コスト | 社内でDynamoを覚える時間。担当者が異動すると失われる |
| 利用者の再教育 | 操作方法が変わるため、使っていた人への説明が必要 |
| 二重管理の期間 | 移行中はDynamo版とアドイン版が並存し、どちらが正か曖昧になりやすい |
見落とされがちな失敗: 試作が「そこそこ使えてしまう」ケースです。遅い・たまに止まる・作った人しか直せない、という状態のまま定着し、誰も困っていないので改善もされない——という形で数年経つことがあります。試作は試作として期限を切るのが安全です。
費用と期間の違い
| Dynamo | アドイン開発 | |
|---|---|---|
| 初期費用 | 社内工数のみ（Revitに同梱） | 開発費が発生 |
| 立ち上がり | 数時間〜数日 | 数週間〜数ヶ月 |
| 継続コスト | 作った人の時間（属人化しやすい） | 保守費（バージョン対応を含む） |
| 人数が増えたとき | 管理コストが増える | 1本で全員が使える |
アドイン開発の費用の目安は、小規模で20〜50万円、中規模で50〜120万円ほどです（2026年7月時点／中小の開発会社・フリーランスを含む一般的な水準）。詳しくは外注ガイドにまとめています。
見落としやすい点: Dynamoは「無料」に見えますが、作る人の時間と、属人化のリスクは費用です。 特に、その人しか直せない状態が長く続くと、あとで作り直す羽目になります。
よくある誤解
単純な処理は確かに簡単です。ただし複雑になるほどノードが増え、線が絡み、読めなくなります。簡単なのは最初だけという性質があります。
使う人数で割ると見え方が変わります。10人が毎日使うツールなら、1人あたりの負担は小さくなります。人数と頻度で判断してください。
実際には併用が普通です。試作や案件個別の処理はDynamo、全社で使う定番処理はアドイン、という住み分けが機能します。
Dynamoを飛ばして、最初からアドインにすべきケース
「まずDynamoで試す」は、効果や要件が読めていないときに有効な手であって、常に得なわけではありません。次の条件が揃っているなら、試作を挟まず最初からアドインにするほうが早く安く済みます。
既存の手順書があり、例外パターンも把握できている場合。試作で確かめることが少なく、通る意味が薄くなります。
全社展開が決まっている、毎日多人数が使うと分かっている場合。結論が見えている道を回り道する形になります。
Excelや社内システムとの連携が必須なら、Dynamoでは早い段階で行き詰まります。
Dynamoを一から覚える時間のほうが高くつくことがあります。覚えた人が異動すれば、その投資も残りません。
逆に、Dynamoを経由する価値が高いのは次の場合です。
- 効果が読めない — 本当に時間が減るのか、使われるのかが未知
- 要件が固まっていない — 何を自動化すべきかがまだ言語化できていない
- 例外が見えていない — 実際に流してみないと分からない部分が多い
- すでに社内にDynamoを使える人がいる — 学習コストが発生しない
- 今期は予算が取れない — 効果を実測してから予算化したい
判断のしかた: 「まずDynamo」を手順ではなく道具として捉えてください。確かめたいことがあるときだけ使う。確かめることが無いなら、通る必要はありません。
実務での進め方
前提として、これは「効果や要件が読めていない場合」の進め方です。 上の条件に当てはまるなら、この手順は飛ばして構いません。
- Dynamoで試作する — 完成度は求めず、動くところまで。この段階では作った人だけが使えれば十分です。あらかじめ期限を決めておくと、中途半端な状態で定着するのを防げます
- 実際に使って測る — 何分が何分になったか、どんな例外が出たかを記録します。ここを飛ばすと、次の投資判断が勘になります
- 広げるか決める — 効果が小さければそこで終わり。それも正しい結論です。無理にアドイン化しません
- 広げるならアドイン化する — 試作と実測データを持って相談すると、見積もりの精度が上がります
- 保守の枠を確保する — Revitのバージョンアップ対応を含めて、継続的に使える体制にします
まとめ
- Dynamoとアドインは優劣ではなく、向いている領域が違う
- Dynamoの価値は「捨てやすい」こと。効果が読めない段階の検証に向く
- アドインに切り替えるサインは、技術的な限界より先に運用の限界として現れる。特に「使う人が3人を超えた」「操作の説明が大変」
- 判断は使う人数と使用頻度で。「1人が月1回」ならDynamo、「10人が毎日」ならアドイン
- Dynamoの試作は仕様書・例外リスト・効果の実測値として役立つ。ただしコードは変換できないため、移行は実質的に作り直し。学習コスト・利用者の再教育・二重管理の期間も発生する
- 「まずDynamo」は無条件の正解ではない。要件が明確・規模が大きい・外部連携が前提・社内に触れる人がいない、のいずれかなら最初からアドインのほうが早く安い
- Dynamoは無料に見えるが、作る人の時間と属人化のリスクは費用
- 実務では併用が普通。案件個別の処理はDynamo、全社の定番処理はアドイン
JIT株式会社は、Revitの業務アドインを3年以上にわたって約50本開発し、リリース後の機能追加やRevit本体のバージョン更新に伴う改修も継続して引き受けてきました。
「Dynamoで作ったものが重い・管理しきれない」「アドインにすべきか判断したい」といったご相談を承っています。まだ試作しかない段階でも構いません。お気軽にご相談ください。