環境制御自動化~

AoTのenv_coordinator(画面上は統合環境制御)は、1つの施設のすべてのアクチュエーター — 換気窓、排気・吸気ファン、ヒーター、冷房機、噴霧器、遮光スクリーン、保温カーテン、 補光照明、CO₂インジェクター — を1つにまとめて協調させる3層制御システムです。

異なる2つの場所で決まる、2つのことがあります。この2つを混同するのが、もっとも よくある混乱の原因です。

• 何を目指すか — VPD・CO₂・DLIなど — は、その施設で育っている区画の ものです。区画に付いた栽培プログラムを通じて決まります。
• どう到達するか — どんな設備があるか、越えてはいけない線はどこか、 目標をどれだけ強く追うか — はこの関数のものです。

目標はどこで決まるか~

区画は選んだプログラムを内在化します。区画画面でステージの目標値を編集すると、 その区画のその項目だけが上書きされ、プログラム本体や同じプログラムを使う他の区画には 影響しません。欄を空にすると、その項目はプログラムの値に戻ります — そのため 「元に戻す」ボタンを別に用意していません。

意図した制約が2つあります。

• 区画は新しい目標項目を作れません。語彙はプログラムのもの(target_defs) なので、未知のキーは黙って無視されるのではなく拒否されます。
• カーブが設定されている項目は、数値で上書きできません。カーブが優先され、 区画画面ではその項目が読み取り専用として表示されます。

コーディネーターが毎サイクル読み込むもの~

目標項目と制御軸は、項目のキー名ではなく測定値の種類と形で結び付きます — 利用者が「室内CO₂」と名付けた項目でも、測定値がCO₂であればCO₂制御に届きます。 測定値を選んでいない項目はどの軸にも届かず、画面には参考のみと表示されます。

区画がないとき~

コーディネーターは止まりません。 区画がない、プログラムがない、まだ確認されて いないAI下書きしかない、あるいは今日に該当するステージがない場合は、単に目標が ないだけです — 制御は自分自身の推奨範囲の中で動き続けます。これはすでに定義された 挙動であり、栽培中の作物がない温室でも暖房は必要だからです。

2026-09-01以降、コーディネーターには自分自身の終了日オプションはありません。 栽培を続けるかどうかは区画が決めます。以前はFunctionに一度設定した日付のせいで、 新しい作物を植えたあとも施設が止まったままになることがありました。

スコープ内に区画が2つ以上あるとき~

間作・混作は普通に起こることなので、コーディネーターは推測しません。施設・ベイの スコープ内に区画が2つ以上あるときは、そのことを伝えてこれに従うボタンを 出します。同じ選択は、詳細設定の基準区画にも保存されます。指定した区画が 終了したりスコープの外に出たりしても、値は消えません — 画面が「指定した区画は もうここにありません」と伝え、選択ルールをあらためて適用します。

区画に記録されるプログラムのバージョンは、バージョン番号を固定するだけで 内容までは固定しません。プログラムを編集すると、進行中の区画の解釈も 変わります。

VPD(飽差)~

VPDは、植物の蒸散と吸水を左右するもっとも重要な指標です。

VPD = SVP × (1 - RH/100)
SVP = 0.6108 × exp(17.27T / (T + 237.3))  [kPa]

env_coordinatorの制御レイヤー~

L1 — EnvTarget(設定値)~

上で説明した目標を、このサイクルの設定値へと解決します。Methodに従う目標項目は、 区画の経過週数と施設のローカルタイムゾーンで評価されます。

L2 — SituationReport(評価)~

現在の偏差、制限要因、傾向を評価します。

VPDが使えるとき、温度と湿度は制約に格下げされます — VPDを分解して得られる 範囲であり、越えてはいけない線です。この関数はサーモスタットではありません。

L3 — Coordinator(アクチュエーター指令)~

PI制御 + スルーレート制限 + アンチワインドアップを適用し、アクチュエーターへの 指令を算出します。

e(t) = setpoint - measurement
u(t) = Kp × e(t) + Ki × ∫e dt
slew: |Δu| ≤ slew_rate_per_cycle
output → heater / vent / fan / mister / CO₂ supply

アクチュエーターのドメイン~

負荷の分担はドメインの中で起こり、ドメインの区切りは装置の見た目が似ているか ではなく、エネルギーの行き先が同じかで決まります。設定画面も同じ区切りに 従っています。

ドメーム同士は互いの仕事を見ないため、ドメーム間の調整は効果の暗黙の積み上げでは なく、明示的なインターロック(換気参照)で行います。

屋根換気口と側面換気口は挙動が違う~

どちらもopeningアクチュエーターですが、施設図面は棟(屋根)窓と側窓を区別し、 効果モデルもそれを使います。

図面に形状の指定がない場合は、これまでどおりの挙動になります(補正なし)。

Function設定~

AoT UIでFunction → 統合環境制御に移動します。アクチュエーター自体は別途 登録するか(アクチュエーターの登録参照)、連携施設から自動的に 検出されます。

設定画面の読み方~

この画面は2026-08に全面的に作り直されました。以下の表を読む前に知っておくと よいことが5つあります。

画面の最上部にステータスヘッダーがあります。 施設選択欄の下に、制御が今 何をしているかが表示されます — 現在のVPDとその目標、デバイスの種類ごとの状態 (開口部、冷暖房、加湿、遮光…)、最後に判断してからどれくらい経ったか。その下の 2行の要約は、追従している区画・ステージと、現在適用中の目標を伝えます。動かせない 状態はそれぞれ別の文で示されます — 施設が未連携、制御がオフ、最近の判断なし。 区画が2週間以内に終了する場合は、その旨の1行が追加されます。

設定はオプションの種類ではなく、4つの層に並んでいます。

中心となる設定は、その詳細を引き連れて動きます。 誰も答えられない数値 (「緊急判定の倍率は3.0にすべきか4.0にすべきか?」)を尋ねる代わりに、答えられる 質問をして複数の値を一度に動かします — ロボット掃除機の静音/標準/強のような やり方です。そうした操作は3つあります: 制御の性格、換気・冷暖房の連携、噴霧の 頻度です。段階の名前そのものは保存されません — 保存されるのは実際の値だけで、 今どの段階かはその値から逆算されます。どの段階とも一致しない場合はカスタムと 表示されます。

範囲はハンドルが2つの帯として尋ねられます。 温度と湿度には質問が1つだけ あります — どの範囲で育てるか — で、越えてはいけない上下限はそこから固定の 余裕(±5°C、±5%RH)で導かれます。ここには意図した結果が1つあります — ハード上下限が推奨範囲より狭くなることは絶対にないため、「12~32°Cで育てるが 30°Cは絶対に超えない」という表現はできません。この組み合わせこそが、かつて ヒーターと冷房機を互いに逆らって同時に100%まで動かしていた原因でした。

[詳細]スイッチ1つで、すべての数値欄が開きます。 段階スケールごとにその 数値入力欄が併記され、詳細専用の行がすべて現れ、折りたたまれたグループも一度に 展開されます。このスイッチはブラウザ内だけのもので、保存される設定の一部ではない ため、同じFunctionを2人が別の見え方で見ることはありません。親トグルがオフの 設定は無効化されるのではなく非表示になります。 そのため保存済みの値は そのまま送信され続け、トグルをオフ/オンしても消えません。

一部の設定は特定の条件下でのみ読まれます — カスタム駆動周期はプロファイルが カスタムのときだけ、夜間の時刻欄は夜間を固定時刻で判定しているときだけ 使われます。入力されているのに使われていない値がある場合、画面はそれを 知らせます。そうしないと、黙って何も起きないだけになってしまうからです。

コマンド~

施設設定~

稼働時間~

トグルをオンにするまでは、それ以外の項目は表示されません。これは時間帯別の 制御ではなくスイッチです。時間帯の外では、暖房・冷房を含めてコーディネーターが 完全に停止します。安全の上下限はそれでも働きます。

目標と応答性~

[詳細]を開くと、各範囲帯の裏にある4つの数値(推奨最小/最大温度、 最小/最大温度、および湿度の対応する値)が表示され、制御の性格はそのメンバーを 表示します。

同じ場所にさらに2つのメンバーがありますが、これらは段階では設定されません — 同じ軸の上での微調整だからです。カスタム駆動周期(秒) — プロファイルが カスタムのときだけ使われます — と、緊急時の最小間隔(秒)(既定60)で、 緊急時であっても2回の換気窓指令の間に空ける最小の間隔です。

駆動プロファイルが左右するのは、側面/屋根の換気窓が動くことを許す頻度だけです。 センシングと計算は毎サイクル周期で常に実行され、カーテンや遮光スクリーンは 影響を受けず(一動作で開閉するため)、急な天候変化や安全ゲートは、この設定に 関係なく換気窓を即座に動かします。

換気~

換気と冷暖房の連携は、3つのトグルを一度に動かします。

• 換気で目標に届かないときは開口部を閉じる — 換気は室内を室外の方向にしか 引っ張れません。目標が外気の反対側にあるとき、開口部を開けば開くほど目標から 遠ざかります。典型例は夜間の除湿で、外気が室内より湿っている場合です。これを オンにすると、開口部と排気・吸気ファンは、一晩中中途半端に開けておくのでは なく、閉じたままパーキングされます。
• 換気で目標に届くときは冷暖房を休ませる — 外気がすでに目標を超えている とき、換気だけで到達でき、そこで冷暖房を一緒に動かすのは外気がタダでやって くれることに料金を払うようなものです。3つの条件がすべて成り立つ必要があります — 外気の値が許容誤差を超えて目標を上回っている、制御対象の変数のすべてが そうなっている、そして開口部にまだ余裕がある(直近サイクルの最大開度が90% 未満)。15分経っても目標に届かない場合は、すべてが暖房・冷房へ戻されます — 予測が外れたということです。
• 冷暖房が動いている間は開口部を閉じたままにする — 稼働中の機器に逆らって 換気すると、その熱や冷気をそのまま外へ捨てることになります。外気が目標に 近づくのを助けてくれる季節であっても、この設定はその助けも一緒に捨てて しまいます。

稼働中の機器を検知するには根拠が必要で、その情報源は2つしかありません — このコーディネーター自身がその機器に指令を出しているか、稼働すると値が上がる 測定値を信号として指定しているかです。室内温度は意図的に使いません。 冷房機の ない温室の実データ30日分で検証したところ、日射300 W/m²以上の条件下で室内外の 温度差の中央値は+0.03°C、最小値は−4.22°Cで、「室内が室外より涼しければ冷房が 動いている」という判定は、1.5°Cの余裕を持たせても昼間サンプルの13%で誤判定 しました。

信号自身に鮮度の上限がない場合、その信号自身の測定周期(×2、下限300秒)で 判定されます。期限切れの信号は稼働していないとみなされ、その旨が記録されます。

夜間閉鎖があるのは、夜になると湿度が上がり結露するためです — 夕方には 役に立っていた開口部が、朝には作物を濡らしたままにしてしまうことがあります。 そのサブ設定は、トグルがオンのときだけ現れます。

3つの保証が成り立ちます — 安全ゲートが優先します(真夏の夜の熱でも換気窓は 開きます)、ハードな温度/湿度の上下限がパーキングを解除します、そして太陽時刻を 計算できる座標がない場合は何もパーキングされません。時刻は施設のローカル タイムゾーンで読み取られ、サーバーのものではありません。施設のポップアップでは、 このオプションでパーキングされたデバイスは夜間のため閉じ、冷暖房で管理して いますと表示され、このデバイスが今できることは何もありませんとは区別されます。

冷暖房・加湿~

噴霧バルブはほとんどの場合オン/オフしかできないため、流量を絞る手段はありません — 調整できるのは、1回の作動がどれだけ続くかと、次までどれだけ待つかだけです。 この段階スケールが設定するのはそれです。

日焼け保護は頻度とは別の判断です — この2つは一時期まとめられていて、 「頻繁に噴霧しつつ強い日差しでは遮断する」という組み合わせが表現できません でした。

保護がオフでも、湿式噴霧器は連続変調ではなくパルス投与されます — 既定では 最大30秒オン、最小180秒オフです。連続的な変調では葉が乾く暇がないためです。

光と遮光~

どちらの端もオフにでき、オフの意味は両端で異なります — 下側のハンドルを0にすると 補光しない、上側のハンドルをオフにすると遮光しないです。施設に遮光スクリーンや 補光照明が登録されていない場合、画面は何もしないハンドルを出す代わりにその旨を 伝えます。

裏にある実際の値は最小光量しきい値(補光)(既定0)と最大光量しきい値 (既定800)で、どちらも[詳細]の下に表示されます。

関連する2つの設定はこの画面にはありません。

• 遮光生地の透過率は施設側の設定で、施設エディターの遮光カーテンの下に あります。室内の光センサーがないときにのみ使われ、そのときは屋外日射と 開度から室内の光量を推定します。未設定または範囲外の値は0.50にフォール バックし、施設が遮光カーテンを持たないと宣言している場合は1.0が使われます。 1画面だけ生地が異なる場合は、そのActionで個別に上書きできます。
• 光飽和点は遮光しきい値ではなく、プログラムにある作物のK_Lから導かれます。 この2つが同じ欄だったとき、遮光しきい値を下げると光合成モデルは「もう十分な 光がある」と判断してしまい、250に設定された2つのコーディネーターが、実測日射が 542と650 W/m²の間ずっと光制限を一度も検出しませんでした。K_Lがない場合は、 システムの既定値600 W/m²が使われます。

詳細設定~

このグループは既定で折りたたまれており、Functionを試験するエンジニア向けで、 生産者向けではありません。

効果キャリブレーション~

予報フィードフォワード~

デバッグログはもう独立したオプションではありません。 これはフレームワーク 自身のデバッグスイッチと重複しており、それが守っていたもののほとんどはDEBUG レベルで書き出されていたため、単独では何も出力していませんでした。Functionの 詳細設定にある1つのスイッチが、今では両方を兼ねています。重大なイベント — 安全ゲート、送信失敗、実行状態のエラー — は、この設定に関係なく常に記録 されます。

アクチュエーターの登録~

連携施設の図面に描かれたアクチュエーターは自動的に検出されます。それ以外は このFunctionに環境制御アクションを登録します — デバイス1台につき1回、この アクションを追加してください。手動登録は、施設から検出されたリストとマージ されます。

デバイス種類ごとの自動変換~

指令は常に0~100%として算出されます。アダプターはOutputモジュール自身の メタデータから選ばれ、追加設定は不要です。

湿式噴霧器は、さらにパルス投与でラップされます — 1回の噴霧は最大作動時間で 打ち切られ、乾燥間隔が経過するまでは一切噴霧しません。

かんがいの流量は施設図面から集計されます — あるレイヤー下のすべてのエミッターが そのアクチュエーターのflow_lpmに合算され、容積式アダプターと噴霧器の効果 モデルがそれをそのまま使います。フォールバックの順序は、アクチュエーター ごとの流量、次に施設全体の合計、それもなければ1.0 L/minです。

安全時デフォルト位置~

各アクチュエーターには、安全ゲートが作動したとき、緊急停止時、または外部からの force_safe_state()呼び出し時に移動する安全な位置があります。施設から検出 されたアクチュエーターについては、デバイスの種類に従います — 保温カーテンと 遮光スクリーンは100%でパーキングし、それ以外は0(オフ)です。

Method(設定値カーブ)~

Methodは、設定値が時間とともにどう変わるかを定義します。Methodはこの Functionではなく、プログラム側の目標項目に付けられます — カーブが設定された 項目は区画画面でカーブに従うと表示され、数値で上書きできません。

• Daily — 時刻(HH:MM)ごとの設定値
• Duration — 開始からの経過時間ごとの設定値
• Daily Bezier — なめらかな日周カーブ
• Repeating — 繰り返しパターン

生育週で進行するカーブは、区画の開始日から評価され、施設のローカルタイム ゾーンの深夜0時に読み取られ、区画画面や区画の日誌が使うのと同じ経過週数から 計算されます。

作物ステージスケジュールの例(トマト):

SEED:から始まるMethodはシードプリセットで、読み取り専用です。編集する前に プリセットを複製してください。

安全ゲート~

安全機構はL1~L3の協調アルゴリズムの外側で動きます — 毎サイクルL1~L3の前に 確認するPre-Gateと、L3の結果を送信前にサニティチェックするPost-Gateです。 一度作動すると、Pre-Gateは最後に作動してから最低300秒はアクティブなままです (急速なオン/オフの繰り返しを防ぐため)。

Pre-Gate(L1~L3の前に確認)~

降雨・高温・低温のしきい値はコードに固定されています — 強風だけが Functionのオプションとして公開されています。複数のゲートが同時に作動する こともあり(例: 降雨+強風)、その場合は方向にかかわらず開口部は無条件に 閉じます。

ゲートが作動したサイクルも、サイクルであることに変わりありません。 ゲートが サイクルを早期に終わらせると、簡略化されたサマリーが書き込まれ、サイクルには タイムスタンプが付きます — そのため施設ウィジェットは、コーディネーターが 応答不能になったと報告するのではなく、実際に何が起きたかを表示し続けます。この 簡略化されたサマリーは、そのサイクルで計算されなかった環境値をあえて省略し、 ゲートが実際に強制したデバイスだけを一覧にします — 触れていないデバイスには 0%ではなく、指令自体が記録されません。

Post-Gate(L3の後、送信前に確認)~

緊急停止と安全状態~

緊急停止のあと、次のサイクルは60秒遅延します。直後にアクチュエーターが 動かないのはこの遅延であり、故障ではありません。

トラブルシューティング~

AI連携~

AIエージェントはanalyze_control_performanceを使って制御品質を診断します。

vpd_rmse         → VPD追従誤差(低いほど良い)
oscillation_index → 制御の振動指数(低いほど安定)
assessment       → "good" / "moderate" / "poor"

診断結果をもとに、suggest_setpoint_adjustmentが目標値の調整を提案します。 提案はあくまでアドバイスであり、目標そのものは区画のステージ計画にあるため、 それを適用するには区画画面でそのステージの目標値を編集する必要があります。

関連ページ~

• AIの機能概要
• Functionガイド
• Methodガイド