タイトル: Speckle Automate
SEOタイトル: Speckle Automateとは｜Version公開トリガーで自動QA・命名規約チェックを走らせる仕組み
Speckle Automate
新しい Version の公開をきっかけに、登録した処理を自動で走らせる仕組みです。CI（継続的インテグレーション）の発想を BIM データに持ち込み、命名規約や必須属性などの品質チェックを機械的に繰り返します。
この記事の要点
- Speckle Automate は新しい Version の公開をトリガーに自動処理を走らせる仕組み
- 処理本体は「Function」として記述し、受け取ったデータを検査・加工・レポートする
- 命名規約チェック・必須属性の有無・干渉や数量の検証など QA 用途に向く
- 人手のレビューを自動チェックで補い、品質を継続的に担保するのが狙い
本記事は Speckle カテゴリの一部として、Speckle Automate を整理します。モデルが更新されるたびに自動でチェックを走らせたい、という典型的なニーズに応える機能です。実務での組み込み方は データ連携実務 もあわせて参照してください。
1Speckle Automate とは
Speckle Automate は、Speckle サーバー上で 新しい Version（旧世代の Commit）が公開されたことなどをきっかけに、あらかじめ登録した処理を自動実行する仕組みです。CI（継続的インテグレーション）の発想を BIM データに持ち込んだもの、と捉えると理解しやすいでしょう。
ソースコードに対してテストが自動で走るように、モデルデータに対して「ルールどおりか」を自動でチェックできます。Version 公開のたびに人手で目視確認する代わりに、決まった検証を機械的に繰り返せるのが価値です。
ソフトウェアの CI とのアナロジー
「変更が入ったら自動で確かめる」という発想は同じで、対象がソースコードからモデルデータに置き換わったものと考えると理解が早まります。
2仕組み（トリガーと Function）
| 要素 | 役割 |
|---|---|
| トリガー | 新しい Version の公開などのイベント。これを起点に処理が始まる |
| Function | 実際の処理本体。受け取ったモデルを検査・加工し、結果を返す |
| Automation | 「どの Model に対してどの Function を走らせるか」の設定・紐づけ |
| Run（実行） | トリガーごとに1回走る実行単位。ログや成否が残る |
Function は SDK（Python の specklepy や .NET）を使って書くのが基本で、対象 Version のデータを受け取り、検査結果を Automate に返します。返した結果は実行の合否やモデルへのコメントとして反映されます。トリガーから Function、Run、結果の反映までが一本の流れになっているため、モデルを更新するたびに同じ検査が抜けなく繰り返される点が、人手の確認とは異なる安心材料になります。
同じ Model に複数の Automation を設定することもでき、たとえば「命名規約のチェック」と「必須属性のチェック」を別々の Function として用意し、それぞれ独立した Run として走らせる構成も取れます。どの Run がいつ・どの Version に対して走ったかはログに残るため、後から「この版はどの検査を通過したか」を追跡できます。
3Function でできること
Function は受け取った Speckle のオブジェクトツリーを走査し、任意のロジックを適用できます。代表的には次のような処理です。
処理は specklepy などでオブジェクトを取得して進めます。データ取得の基本は specklepy を参照してください。
4ユースケース：命名規約チェック
分かりやすい例が「命名規約チェック」です。たとえば「壁の名前は WL- で始まること」というルールがあるとき、Function でモデル内の壁要素を走査し、規約に反する要素を検出してマークします。概念的には次のような判定です。
# 概念例：壁の命名規約チェック（specklepy 風の擬似コード）
for el in walls:
name = el["name"]
if not name.startswith("WL-"):
# 不合格として要素をマークし、理由を付ける
attach_error(el, "命名規約違反: WL- で始めてください")記号を含む条件式やパスを扱う場合、<（小なり）や >（大なり）、&（アンパサンド）などはコードとして崩れないよう注意します。チェック結果は Run の合否として残り、レビュー前に機械的に弾けます。
5その他の典型ユースケース
| 用途 | チェック内容の例 |
|---|---|
| 必須属性の検査 | 防火区画・用途・型番など必須プロパティの欠落を検出 |
| 数量・面積の検証 | 計算した数量が想定範囲に収まるか |
| 分類・コードの妥当性 | 分類コードが許可リストに含まれるか |
| レポート生成 | 集計表や差分サマリを自動作成し関係者へ通知 |
6導入時の考え方
Automate は「人手のレビューを置き換える」というより「機械的に判定できる部分を自動化し、人は判断が要る部分に集中する」ための道具です。最初は1つの明確なルール（命名規約や必須属性の有無など）から始め、Run のログで誤検出を調整しながら段階的にルールを増やすのが現実的です。
命名規約・必須属性・数量の範囲など、明確に判定できる検査
意匠の良し悪し・優先順位など、判断が要る部分に集中する
機能の提供形態・実行環境・料金体系は時期によって変わり得るため、本番運用の前提にする場合は最新の公式情報を確認してください。実務パイプラインへの組み込み例は データ連携実務 で扱います。