冷凍庫、冷蔵室、温室、温度センサー付きのサーバークローゼットを持っているなら、この記事はコールドチェーン監視 SaaS への年額 $2,400 のサブスクリプションを節約します。
MQTT ブローカーを Tablize にサブスクライブし、エージェントにセンサートピックを識別させ、温度閾値のウォッチをセットアップし、アラートを Slack にルーティングします。合計時間：約 10 分。Python なし、Node-RED なし、Grafana セットアップなし。
必要なもの
- センサーがパブリッシュしている MQTT ブローカー。 Mosquitto、HiveMQ、EMQX — いずれでも。まだなければ、EMQX に 2 分で立ち上がる無料クラウドブローカーがあります。
- 温度データをパブリッシュしている少なくとも 1 つのセンサー（JSON または単純数値）。ほとんどのコンシューマグレード ESP32 ベースセンサーはこれを箱出しで行います。
- Pro プラン以上の Tablize ワークスペース（月額 $60）。MQTT は Pro 機能 — 常時オンの計算ポッドが必要なため、センサーデータが到着したときエージェントが起きている必要があります。
- 配信用の Slack ワークスペース。（メールも機能 — 最後に触れます。）
ステップ 1：Tablize を MQTT ブローカーに接続
Tablize サイドバーで Spaces（IoT セクション）をクリック。Tablize で IoT を使ったことがなければ、これがエントリーポイント。
Add MQTT broker をクリック。必要なもの：
- ブローカーホスト（例：
broker.hivemq.comや EMQX クラウド URL） - ポート（プレーン MQTT は 1883、TLS は 8883 — TLS を使用）
- ユーザー名 + パスワード（ブローカーが認証を要求する場合）
- サブスクリプショントピック（
#で開始してすべて受信、またはsensors/+/temperatureなどにスコープ）
「Test connection」を押す。Tablize がサブスクライブし、メッセージを待ち、受信した最初の 10 件を表示。センサーデータが流れ込むのが見えれば、接続完了。
これは Tablize にどのセンサーがどれかのヒントを与える瞬間でもあります。センサーが sensors/freezer-east/temperature や sensors/walkin-cooler-1/temperature のようなトピックにパブリッシュしていれば、エージェントは「freezer-east」と「walkin-cooler-1」が 2 つの別個のデバイスだと推論します。トピックが不透明（devices/0a3f1b2c/temp）なら、出現後に Spaces UI で名前変更したくなるでしょう — 各々に人間が読める名前を与える。
ステップ 2：エージェントにデータを学習させる
新しいチャットを開く。入力：
"現在ワークスペースに流れ込んでいる MQTT データは何ですか？
各トピック、それがパブリッシュする頻度、数値フィールドの典型的な値範囲を
見せてください。"エージェントが過去 24 時間の MQTT データ（Tablize が自動的に TimescaleDB に保存するもの — パイプラインをセットアップする必要なし）をクエリし、表を返します：
- トピック名
- 分あたりメッセージ数
- JSON ペイロードから抽出されたフィールド名
- 各数値フィールドの最小 / 最大 / 中央値
これがセンサー在庫。問題も浮上 — センサーが 1 回パブリッシュして停止していたら、「過去 24h で 1 メッセージ」としてここに表示され、確認しに行くべきだとわかります。
ステップ 3：ウォッチをセットアップ
月額 $200 SaaS を置き換える部分。入力：
"すべての freezer センサー（トピック名に 'freezer' を含むもの）を監視。
午後 10 時から午前 6 時の間に温度読み取りが -15°C を 5 分連続で超えたら、
センサー名、現在温度、閾値超過時間、Tablize でライブデータを表示する
リンク付きで Slack DM を送ってください。"エージェントは：
- ルールを基礎ウォッチプリミティブに解析 — フィルター（topic LIKE ‘%freezer%’）、トリガー（temperature > -15）、期間（5 分）、スケジュール（午後 10 時 - 午前 6 時）、アクション（Slack DM）。
- 使う Slack ワークスペース + チャンネル / DM を尋ねる。Slack を接続していなければ、OAuth をガイドします。
- 確認のためルールを自然な言葉で表示。
- ウォッチを有効化。
ウォッチは今からウォッチサイドバーに存在します。編集、停止、複製できます。エージェントは見えないコードを書いていません — すべてのウォッチはトリガー、条件、アクションがすべて見えて編集可能な構造化オブジェクトです。
ステップ 4：動作を検証
これがほとんどのコールドチェーンロールアウトがスキップして後悔するステップ。Tablize はそれを簡単にします：
"freezer-east が午後 11 時から 11:30 まで -15°C を超える 30 分窓を
シミュレーション。私のウォッチがどんな通知を送ったかを教えてください。"エージェントが履歴データに対してドライランシミュレーションを実行し、ルールを適用し、どの Slack メッセージが発火したかを正確に表示。ウォッチが間違っている（間違った時間窓、間違ったセンサーパターン、閾値が逆）なら、今見えます。
一時的に閾値を下げる（例：-100°C — それ以上のすべてが即座に発火）ことで実トリガーを強制し、Slack DM の到着を確認してから実閾値に戻す方法もあります。30 秒で完了。
コスト比較
典型的なコールドチェーン SaaS と比較：
| Tablize Pro | コールドチェーン SaaS A | コールドチェーン SaaS B | |
|---|---|---|---|
| 月額コスト | $60（Tablize の全機能込み） | ロケーションあたり $200 | ロケーションあたり $150、アラート別課金 |
| カバーするセンサー数 | ワークスペースあたり無制限 | プラン層あたり通常 10〜50 | プラン層あたり通常 5〜20 |
| 他のユースケース込み | Tablize の全機能 | なし | なし |
| ベンダーセンサーへのロックイン | なし | しばしばあり | しばしばあり |
専用 SaaS が存在する理由は、一部の 顧客（病院、FDA 規制食品保管、ワクチンコールドチェーン）が認定ハードウェア、監査証跡コンプライアンス、24/7 SLA サポートを必要とするから。それらには月額 $200 を支払うべき。それ以外のすべて — 冷凍庫 3 台のレストラン、温室のある農場、去年壊れたワインフリッジのあるアパート — には Tablize が正しい形。
ウォッチを拡張
基本ウォッチが動作したら、自然な次の動き：
マルチチャネルアラートを追加。 「午後 11 時から午前 5 時の間にアラートが発火し、10 分以内に承認されなかったら SMS でも通知して。」 Tablize はメール、Slack、ウェブフックを箱出しでサポート；SMS は Twilio ウェブフック経由。
集約イベントレポート。 「毎週日曜朝、過去 1 週間のすべての freezer イベントのダイジェストを送って — センサー名、時刻、ピーク温度、閾値超過期間。」 これはウォッチのイベント履歴の上の別レポート。
ダッシュボードを生成。 「すべての freezer のライブ温度、センサーごとの 24 時間ライングラフ、最後の 10 アラートのリストを表示するダッシュボードを構築。」 これは生成アプリ、キッチンマネージャーが電話から見る必要があれば公開リンクで共有可能。
派生条件を監視。 「営業時間中にセンサーが 15 分以上パブリッシュを停止したら通知して」 — 温度ドリフトだけでなくセンサー障害を捕捉。しばしば温度アラートより有用。
Slack の代わりにメールはどうか？
同じフロー、アクションをスワップ：「Slack の代わりにメールを送って。」 エージェントがウォッチアクションをメールに再接続（デフォルトではアカウントの確認済みアドレスを使用）。
ウェブフックにルーティングもできる — PagerDuty、Opsgenie、カスタム通知スタックにパイプする一般的なパターン。
よくある落とし穴
TLS vs プレーン MQTT。 本番では TLS（ポート 8883）を使用。プレーン MQTT（ポート 1883）は認証情報を平文で送ります。Tablize は両方サポートしますがデフォルトは TLS。
トピックワイルドカード。 MQTT は +（単一レベル）と #（複数レベル）を使用。sensors/+/temperature は sensors/freezer-1/temperature にマッチしますが sensors/freezer-1/room-a/temperature にはマッチしません。後者には sensors/# を使用。
重複メッセージ。 一部の QoS-0 パブリッシャーは不安定なネットワークで再試行し、重複イベントを引き起こす可能性。Tablize はデフォルトで同じ (topic, timestamp, payload) トリプルで重複排除 — センサーが積極的な再試行動作を持ち Tablize が正しく重複排除していなければ、ペイロードに一意の event_id を追加。
センサーオフライン。 センサーがオフラインになると、温度ウォッチは決して発火しません（閾値を超える読み取りがないから）。常に温度ウォッチを「センサーがパブリッシュを停止」ウォッチとペアに — それが死んだセンサーを捕捉。
次は何か
これが Tablize での最初の IoT 連携なら、自然な拡張：2 つ目のセンサータイプ（湿度、ドア開イベント、消費電力）を接続、すべての物理資産を表示する Spaces マップ UI を生成、センサーイベントの上にメンテナンスチケットアプリを構築。すべて 1 文プロンプト離れています。
関連記事：