オートメーション設定ガイド

オートメーション設定ガイド

対象画面：オートメーション設定（ルールとアクション一覧） ／ 目的：運用・設計・デバッグの観点で「自動化の実行構造」と「各ボタンの出力内容」を理解する

1. オートメーション設定について 概要

SWPF の自動化は、イベント（トリガー）を起点に、対象グループのテンプレートを順次実行し、テンプレート内からコマンド（プラグイン）を呼び出す形で構成されます。

Trigger (発火条件)
  ↓ resolve
Group ID (実行対象のまとまり)
  ↓ list / sort
Template Entities (順序付きの処理ひな型)
  ↓ execute
Commands (Plugin invocations)
  ↓ persist
Results / Trace (実行結果の保存・ログ)
設計上の要点
トリガーとグループは「ルーティング」、テンプレートが「制御（ルール/フロー）」、コマンド（プラグイン）が「副作用を持つ実処理」を担当します。

2. 名前の定義と説明 定義

Triggerトリガー
  • 自動化の入口。CRONや外部イベントなどの「起動条件」。
  • 「何を実行するか」は持たず、実行対象（グループ）への紐付けが主。
  • 運用では「発火しているか」「対象ユーザー/UIDが正しいか」が重要。
Groupグループ（GROUP_ID）
  • テンプレートを束ねる識別子。エンティティではなくGroup IDとして扱う。
  • 1つのトリガーが複数グループを持つ/呼ぶことも可能。
  • グループ内のテンプレートはweight順に並ぶ想定。
Templateテンプレート
  • ルール判定（rule_json）と処理フロー（template_json）を内包する「自動化の中枢」。
  • パラメータ（params_json）で外部接続・閾値・文言などを受け取る。
  • テンプレート単位で「何を実行し、何を出力し、どこに記録するか」が決まる。
Commandコマンド／Pluginプラグイン
  • 実処理（API呼び出し、通知、DB保存、AI実行など）を行う再利用部品。
  • テンプレートから呼び出される。
  • 同じプラグインを複数テンプレートで共用可能（標準化・保守性向上）。

3. 画面構成と処理の流れ 説明

この画面は「実行チェーン」をそのまま左から右へ並べたものです。

列 目的 運用で見るポイント
トリガー 起動条件の一覧 期待するトリガーが存在するか／有効か
グループ 実行対象のまとまり トリガーに紐づく GROUP_ID が正しいか
テンプレート ルールとフローの定義 weight順・ルール内容・必要パラメータの有無
コマンドとプラグイン 実処理の一覧 呼び出されるプラグインが想定通りか／副作用の把握
診断の基本手順
「トリガーが正しい」→「グループが正しい」→「テンプレート順と条件が正しい」→「プラグインが正しい」へ順に疑うと最短で原因に到達します。

4. 各ボタンの出力（グラフ/表）の説明 説明

4.1 フローチャート（図）

テンプレート内の処理をノードと矢印で可視化します。
典型的には「入力取得 → 正規化 → 判定 → プラグイン実行 → 結果保存」の並びになります。

  • 目的：処理順・分岐・依存関係の俯瞰
  • 見る点：分岐条件の位置、失敗時の迂回経路、実行ノードの順序
  • 活用：レビュー、事故防止、変更影響の確認

4.2 ルール表示（表）

rule_json（評価ロジック）を、IF/THEN/ELSE のような形で表形式に展開して表示します。

  • 目的：「どの条件で実行されるか／されないか」を確認
  • 見る点：比較対象のパラメータキー、比較演算子、優先順位
  • 活用：誤通知・過検知の原因調査、条件のレビュー
注意：ルールが意図せず常に真/常に偽になっていると、テンプレート全体の挙動が崩れます。まずルール表を確認してください。

4.3 パラメータ表示（表）

params_json（設定値）をキーと値で一覧表示します。
API接続情報・閾値・テンプレート文言・宛先など、挙動を左右する設定が集約されます。

  • 目的：「どんな設定で動いているか」を確認
  • 見る点：必須キーの欠落、環境差（本番/検証）、値の型（数値/文字列）
  • 活用：運用切替、ユーザー別設定の差異確認、事故防止
運用メモ：パラメータは「変更しただけで挙動が変わる」ため、変更履歴（誰が/いつ/何を）を残すと事故が減ります。

4.4 コマンド表示（一覧）

テンプレートが呼び出す「コマンド（プラグイン呼び出し）」を一覧で表示します。
例：fetch_weather_from_jma / chatgpt_chat / mail_send など。

  • 目的：副作用（外部送信、デバイス制御等）を把握
  • 見る点：呼び出し順、同じプラグインの多重実行、環境依存（キー/URL）
  • 活用：セキュリティレビュー（外部送信先）、コスト確認（AI/API）

5. 手動実行および自動実行における注意点注意点

5.1 手動実行（テンプレートを手動で実行する）

  • 運用確認・検証・障害復旧で使用します。
  • 「CRONを待たずにすぐ試す」用途に適しています。
  • 実行前に、副作用（メール送信、デバイス制御、外部API課金）を必ず意識してください。

5.2 権限・スコープ（ユーザー別）

  • ユーザー単位（UID）でテンプレート/トリガーが紐づく場合、表示・実行対象が一致しているか確認します。
  • 管理者は「全体」を見られる一方、一般ユーザーは「自分の分」だけ見えるのが安全です。

5.3 失敗時の観点

  1. 入力が来ているか（トリガー発火/スケジュール動作）
  2. グループが解決できているか（対象 GROUP_ID）
  3. テンプレートの順序が正しいか（weight）
  4. 必要パラメータが揃っているか（params_json）
  5. プラグイン実行が成功しているか（外部API、認証、タイムアウト）

6. 【プラグイン開発者向け】データ構造・拡張ポイント・テスト観点 プラグイン開発者向け

6.1 典型的なデータ責務

要素 責務 変更頻度 影響範囲
Trigger 起動点（スケジュール/イベント） 低 広（入口）
Group ID テンプレート束ね 中 中
Template ルール/フロー/パラメータ 高 広（挙動を決める）
Plugin 実処理（副作用） 中 広（外部接続）

6.2 拡張ポイント（よく追加される箇所）

  • 新規プラグイン追加：外部API連携、通知方式、デバイス制御を増やす
  • テンプレートJSON拡張：新しいノードタイプ（EXPRESSION/COMMAND/TRANSFORMなど）
  • params_map 拡張：コンテキスト（raw.*）の追加、テンプレート差し込みキーの追加
  • バリデーション：rule_json/params_json の整合性チェックを強化

6.3 テスト観点（最小セット）

機能テスト
  • トリガー発火 → グループ解決 → テンプレート順実行
  • ルールの真/偽で分岐が変わること
  • プラグイン呼び出し成功・失敗の挙動
安全性テスト
  • 副作用のあるプラグイン（メール/制御）は二重実行されない
  • 認証情報がログに出ない
  • 異常時にトレースが残る（原因追跡できる）
開発メモ：
画面の「表/図」は、運用者が内部構造を理解するための“デバッグUI”でもあります。
変更時は「表示の意味が変わっていないか」「誤解を生まないか」もテスト項目です。

7. 自動実行チェックリスト チェックリスト

  • ✅ 期待するトリガーが存在し、定期実行（CRON）が動いている
  • ✅ トリガーが参照する GROUP_ID が正しい
  • ✅ グループ内テンプレートが weight 昇順で並んでいる
  • ✅ パラメータ（APIキー・宛先・閾値）が欠落していない
  • ✅ コマンド一覧に想定外の外部送信先・副作用がない
  • ✅ 失敗時にログ/トレースが残り、原因追跡できる
SWPF / オートメーション設定 ガイド

 

当サイトまたはIoTカスタムモジュール、開発支援に関するお問い合わせはこちらのメールフォームからお気軽にお問い合わせください。