この内容は古いバージョンです。最新バージョンを表示するには、戻るボタンを押してください。
バージョン:2
ページ更新者:atom
更新日時:2026-06-29 13:35:40

タイトル: send/receive の基本ワークフロー
SEOタイトル: Speckleのsend/receive|Version生成・選択フィルタ・差分とバージョン履歴

Tool A Server Tool B send receive v1 › v2 › v3 …(バージョン履歴)
Speckle · 05

send/receive の基本ワークフロー

send はモデルを Speckle へ送って新しい Version を生成し、receive はそれを別ツールに読み込む操作。選択フィルタで範囲を絞り、送るたびに履歴が積み上がります。基本の往復を整理します。

この記事の要点

  • send はモデルを Speckle へ送り、対象 Model に新しい Version を生成する操作
  • receive は Version を取得して別ツールにネイティブ要素として読み込む操作
  • 送る範囲は選択フィルタ(選択要素・カテゴリ・ビューなど)で絞り込める
  • send のたびに Version が積み上がり、バージョン履歴として時系列にたどれる
  • 差分は Version 間の比較として確認でき、何が変わったかを把握できる

この記事は Speckle の最も基本的な操作、send と receive のワークフローを整理します。前提として コネクタアーキテクチャ(Project/Model/Version) を理解しておくとスムーズです。具体的な Revit での往復は Revit ⇄ Speckle を参照してください。

1send(送信)の流れ

send は、あるツールのモデルを Speckle に送る操作です。おおまかな流れは次のとおりです。

1Project/Model 指定
2範囲を選択
3Base に変換・転送
4新 Version 作成
  • 送りたい Project と Model を指定する(なければ作成する)。
  • 送る要素の範囲を選択フィルタで決める(後述)。
  • send を実行すると、選んだ要素が Base オブジェクトへ変換され、サーバに転送される。
  • 転送されたオブジェクトツリーを指す新しい Version(旧 Commit に相当)が、その Model に作成される。

送信後は、Web の Viewer でその Version の内容をブラウザから確認できます。

2選択フィルタ

毎回モデル全体を送る必要はありません。コネクタは送る範囲を絞る選択フィルタを備えています。代表的な絞り方は次のようなものです。

フィルタ内容
選択要素その場で選んだ要素だけを送る
カテゴリ壁・柱など、種類(カテゴリ)単位で送る
ビュー/その他特定のビューに含まれる要素など、ツールに応じた条件で送る

フィルタを使うと、必要な分野・範囲だけを Model ごとに送り分けられます。たとえば構造部材だけを構造用 Model に送る、設備要素だけを設備用 Model に送る、といった運用が可能です。分野ごとに Model を分けておくと、受け取る側も必要な Model だけを receive すればよく、無関係な大量データを読み込まずに済みます。どの単位で Model を切るかは、プロジェクトの体制や分担に合わせてあらかじめ設計しておくとよいでしょう。

3receive(受信)の流れ

receive は、サーバ上の Version を別のツールで読み込む操作です。

  • 対象の Project / Model を選び、読み込みたい Version(通常は最新、または特定の過去版)を指定する。
  • receive を実行すると、その Version が指すオブジェクトツリーが取得される。
  • 受け取ったオブジェクトは、そのツールのネイティブ要素へ変換される。変換できない要素は形状+属性で近似される(コネクタ 参照)。

これにより、Revit で作ったモデルを Rhino や Blender、あるいは Web 上で確認・活用する、といった連携が実現します。receive で読み込んだデータをそのツールで編集して再び send すれば、別の Model(または別バージョン)として履歴に積むこともできます。ただし、どちらのツールの状態を「正本」とみなすかを決めておかないと、双方が独立に更新して内容が食い違うことがあるため、運用ルールはあらかじめ取り決めておきます。

4差分とバージョン履歴

send を繰り返すと、Model には Version が時系列に積み上がっていきます。これがバージョン履歴です。履歴により、いつ・誰が・どんな状態を送ったかをたどれます。

メッセージ各 Version にコミットメッセージ的な説明を付け、変更の意図を残せる
差分Version 間を比較し、追加・変更・削除された要素を確認できる
巻き戻し過去の Version を receive すれば、その時点の状態を取り戻せる

この仕組みは、効率の面では オブジェクトモデル のハッシュと重複排除に支えられています。変わっていない部分は再送されないため、こまめに send してもストレージや転送は無駄になりません。

5ワークフローの全体像

まとめると、典型的な流れは「あるツールで send → サーバに Version 生成 → 別ツールや Web で receive/確認 → 更新したら再び send」という往復です。複数の関係者やツールが、それぞれ得意な環境で作業しつつ、同じ Project のデータを共有・更新していけます。

このとき重要なのは、send と receive はあくまでデータの「橋渡し」であり、各ツールでの編集そのものはそれぞれのネイティブ環境で行うという点です。たとえば構造担当が Revit で構造モデルを更新したら構造用 Model に send し、意匠担当はそれを receive または Viewer で確認して整合をとる、といった協働が成り立ちます。誰がどの Model を正本として更新するかをあらかじめ決めておくと、上書きや競合のトラブルを避けられます。

また、send は「いつでも・何度でも」行ってよい操作です。オブジェクトモデル のハッシュと重複排除により、変わっていないオブジェクトは再送・再保存されないため、こまめに send して履歴を細かく残しても無駄が生じにくい設計になっています。区切りのよいタイミングで Version にメッセージを添えて send しておくと、後から「いつ・なぜこの状態になったか」を追いやすくなります。

この往復を実際の Revit を主役に具体化したのが次の記事です。要素のマッピングや座標・単位の注意点も含め、Revit ⇄ Speckle の往復ワークフロー へ進んでください。

次に読む