この記事は「RTSPカメラとWireGuardでトマト栽培のAI監視をしてみた話」シリーズの第1回目です

はじめに

ベランダでトマトを育て始めたのは、本当に些細なきっかけでした。「自分で育てた野菜を食べてみたい」。それだけです。ホームセンターで苗を買い、プランターに植え、水をやる。最初はそれで十分楽しく、日々の成長を見るだけでも満足していました。

しかし数日経つと、ある違和感に気づきます。朝は元気だったトマトが、昼にはしおれている。夜にはまた少し回復している。この変化を見て、「昼間に何が起きているのか？」という疑問が生まれます。

外出している時間帯、トマトの状態は完全にブラックボックスです。直射日光、気温、湿度、風。これらの要因が複雑に絡み合い、植物に影響を与えているはずですが、人間が見ていない間の変化は分かりません。

最初は単純にスマートカメラで確認するだけのつもりでした。しかし次第に欲求はエスカレートします。こうして暇な時間を家庭菜園でトマトを観察や世話をするはずが、それとは逆にIoTやAIと格闘する忙しい日々が始まることになりました。

技術的に必要な要素は明確でした。映像取得、ネットワーク接続、データ保存、そしてAI解析。この4つをどう組み合わせるか。そして条件は「市販機器＋OSS」「低コスト」です。

これから連載するのは、トマトの苗を育て始めてからの半年間、トマトと一緒に作っていた見える化システムの記録です。

第1回では、これから連載を始める予定の第2回から第8回までをざっくりをまとめて記事にしました。

技術にあまり詳しくない方でも読んでいただけるようにできるだけ分かりやすく執筆しました。最後まで気軽に読み進めていただければ嬉しいです。

---

① RTSPカメラの罠｜なぜ安定しないのか

まず取り組んだのがカメラです。選んだのはRTSP対応の市販カメラ。RTSPとは、カメラの映像を直接取得できるプロトコルで、クラウドに依存せず自分のサーバーで扱えるのが最大の魅力です。

実際のURLは以下のようになります。

rtsp://user:pass@192.168.1.10:554/stream1

この仕組みを使えば、サーバー側で自由に映像を処理できます。OpenCVやffmpegと相性が良く、AI処理にも最適です。

しかし、ここで最初の壁にぶつかります。

RTSPは「ローカル専用」なのです。

市販カメラの多くはLAN内でしか使えません。外出先からアクセスするにはポート開放が必要になりますが、これは非常に危険です。RTSPは認証が弱く、簡単に突破されるケースもあります。

さらに、メーカーごとにURL仕様が違うという問題もあります。

■ RTSP対応カメラ例
・SwitchBot（RTSP対応モデル）
・TP-Link Tapoシリーズ
・Reolink
・ONVIF対応カメラ（おすすめ）

また接続の不安定さも大きな問題でした。UDP接続ではパケットロスが発生し、フレームが欠落します。OpenCVでは「取得失敗」、ffmpegでは「timeout」が頻発しました。

■ RTSP運用のポイント
・必ずTCP接続にする
・固定IPを設定
・ONVIF対応を選ぶ

これらの問題から、RTSP単体では「使えるが運用できない」という結論に至りました。ここで必要になったのが、安全に外部接続する仕組みです。

RTSPの通信構造

RTSPは単なるURLではなく、制御とストリームが分かれたプロトコルです。実際にはSETUP→PLAY→RTPという流れで通信が行われています。

この構造を理解していないと、「繋がるけど映らない」という状態に陥ります。実際にUDPが遮断されている環境では、SETUPは成功してもRTPが届かず黒画面になります。そこでTCP指定が重要になります。

メーカーごとに異なる仕様

実際にSwitchBotとTapoの両方を試した際、同じRTSPでも挙動が大きく異なりました。特に顕著だったのが「一定時間後に接続が切れる問題」です。これはカメラ側のセッション管理によるもので、クライアントが長時間接続し続けると切断されるケースがあります。そのため、mediamtxのような中継を入れることで再接続制御を任せるのが重要になります。

また、RTSPのURLはドキュメントに記載されていない場合も多く、実際にはONVIFツールで探すこともありました。ONVIF Device Managerなどを使うと、ストリームURLを自動検出できるため非常に便利です。

---

② WireGuardで安全に繋ぐ方法｜外から安全にアクセス

RTSPの問題を解決するために導入したのがWireGuardです。これは軽量で高速なVPNで、設定も非常にシンプルです。

構成はこうなります。

・VPS（サーバー）
・GL.iNetルーター（Mango / Opal）
・カメラ（LAN内）

ルーターをVPNクライアントにすることで、カメラがサーバーと同じネットワークにいるように見えます。

■ WireGuardの特徴
・高速（UDPベース）
・シンプルな設定
・鍵認証

■ サーバー設定例

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820

■ クライアント（Mango / Opal）

GL.iNetのGUIから簡単に設定可能です。

しかしここで最大の罠が待っています。

DNSです。

WireGuardを入れると名前解決が壊れます。実際に「app.swpf.jp」が解決できず、API通信がすべて失敗しました。

■ 解決方法

/etc/resolv.conf を固定

nameserver 8.8.8.8
nameserver 1.1.1.1

chattr +i /etc/resolv.conf

さらにIPv6問題も発生します。IPv6で名前解決されるが通信できない、という現象です。

これらを乗り越えて、ようやく「安全で安定したネットワーク」が完成しました。

WireGuardのネットワーク設計

WireGuardは単なるVPNではなく、「仮想L3ネットワーク」を作ります。今回の構成では10.0.0.0/24を内部ネットワークとして扱いました。

ここで重要なのは「ルーティング」です。カメラのIPとVPNのIPは別物であり、ルーターが橋渡しをしています。この理解がないと、pingは通るがRTSPが通らない、といった現象に悩まされます。

WireGuardの落とし穴

WireGuardはシンプルですが、「シンプルすぎるがゆえにハマる」ポイントがあります。今回最大の問題はDNSでしたが、実はもう一つ重要なのが「AllowedIPs」です。これを0.0.0.0/0にするとすべての通信がVPNに流れます。

一見便利ですが、これにより外部通信もすべてVPN経由になり、結果として通信不安定や速度低下の原因になります。用途に応じて「10.0.0.0/24」のみに制限するなど、設計が重要です。

---

③ mediamtxによる安定運用｜接続を安定させる仕組み

次に導入したのがmediamtxです。これはRTSPの中継サーバーで、カメラ映像を安定して扱うための重要なコンポーネントです。

■ なぜ必要か？

RTSPは直接扱うと不安定です。mediamtxを挟むことで

・接続の安定化
・複数クライアント対応
・負荷分散

が可能になります。

■ 設定例

paths:
cam1:
source: rtsp://10.0.0.2:554/live
sourceOnDemand: yes
sourceProtocol: tcp

これにより、サーバー側では

rtsp://localhost:8554/cam1

でアクセスできます。

■ よくあるトラブル

・400 Bad Request → パス未定義
・bind error → ポート競合
・接続不可 → VPN未接続

ログを見ながら一つずつ解決する必要があります。

mediamtxの役割再整理

mediamtxは単なる中継ではなく、「接続管理レイヤー」です。

直接カメラに複数接続すると負荷が上がりますが、mediamtxを挟むことで負荷分散と再接続制御が可能になります。実際の運用では「カメラ1台に対してクライアント複数」が普通なので、ここは重要な設計ポイントです。

mediamtx運用のコツ

mediamtxは軽量ですが、運用ではログ確認が重要です。特に「no one is publishing to path」というログは、カメラに接続できていないことを意味します。

また、sourceOnDemandを使うと、初回アクセス時に数秒遅延が発生します。リアルタイム性を重視する場合は常時接続も検討する必要があります。

---

④ Python + YOLOによる画像解析｜AIで状態を理解する

ここからが本番です。

RTSPで取得した映像をPythonで処理し、YOLOで解析します。

■ 構成

RTSP → OpenCV → YOLO → 保存 → POST

■ サンプルコード

import cv2
from ultralytics import YOLO

cap = cv2.VideoCapture("rtsp://localhost:8554/cam1")
model = YOLO("yolov8n.pt")

ret, frame = cap.read()

if ret:
results = model(frame)
cv2.imwrite("output.jpg", frame)

■ ポイント

・TCP接続必須
・フレーム取得チェック
・例外処理

この処理により、単なる映像は「AIで解析されたデータ」に変わります。

OpenCVの現実

OpenCVでRTSPを扱うとき、最初に直面するのは「ret=False問題」です。これは接続できていないか、フレームが取得できていない状態です。

この原因の多くはネットワークかプロトコルです。TCP指定だけで解決するケースが多く、逆にUDPのままだと不安定になります。

AI処理パイプライン

AI処理は単発ではなく「パイプライン」です。

この流れを分離して考えることで、後からMQTTや別AIに差し替えることが可能になります。最初から密結合にしないことが重要です。

---

⑤ Drupalによるデータ管理｜記録と可視化

解析結果はDrupalで管理します。

DrupalはCMSですが、データ構造の柔軟性が非常に高いのが特徴です。

■ なぜDrupalか？

・エンティティ管理
・REST API
・ユーザー管理

Drupalの強み

Drupalは単なるCMSではなく「データ基盤」として使える点が強みです。今回のように画像＋メタデータを管理する場合、エンティティ設計が非常に役立ちます。

WordPressでも可能ですが、データ構造を厳密に扱うならDrupalの方が適しています。

■ 使い方

・画像保存
・履歴管理
・ユーザー単位管理

■ POST例

curl -X POST -H "Content-Type: image/jpeg" --data-binary @image.jpg

■ よくあるエラー

・415 → Content-Type
・DNS → VPN

Drupalのデータモデル

Drupalの強みは「エンティティ設計」です。

単なるファイルではなく、「誰の」「いつの」データかを紐づけることで、後の分析に使えるデータになります。

---

⑥ AIによるブログ自動生成｜観察を自動化

ここまで来ると、自動化が可能になります。

■ 処理

画像 → AI → テキスト → 投稿

AIは以下が可能です。

・状況説明
・異常検知
・日次レポート

人間よりも安定して記録できるのが最大のメリットです。

AIの価値

AIは万能ではありませんが、「継続すること」に関しては人間より優れています。人間はどうしても記録をサボりますが、AIは必ず記録を残します。

この「継続性」が最終的に大きな価値になります。

AIの役割の変化

AIは最初「解析ツール」ですが、徐々に「判断エンジン」になります。

ここまで来ると、AIは単なる補助ではなくシステムの中核になります。

---

⑦ MQTTによるリアルタイム化｜即時に反応する仕組み

ここまでの構成では、RTSPで映像を取得し、Pythonで処理し、DrupalにHTTPでPOSTするという流れでした。この構成でも十分に実用的ですが、運用しているとある課題に気づきます。

それは「リアルタイム性」と「処理のシンプルさ」です。

HTTPによる通信は非常に便利ですが、どうしてもリクエスト・レスポンス型になります。つまり「送る側」が主導で動く必要があり、イベント駆動の処理にはあまり向いていません。また、画像をPOSTする際のヘッダー設定や認証、エラー処理など、実装が煩雑になりがちです。

そこで次に考えているのがMQTTです。

MQTTはIoT向けに設計された軽量なメッセージングプロトコルで、「Publish / Subscribe」という仕組みを持っています。これは「誰かがデータを送る（Publish）」と、それを待っている側が自動的に受け取る（Subscribe）という非常にシンプルな構造です。

この構成にすると、カメラやセンサーは「データを送るだけ」でよくなります。サーバー側は「受け取ったら処理する」だけです。

■ MQTTのメリット

・リアルタイム処理が可能
・通信が非常に軽い
・HTTPのような複雑な処理が不要
・複数システムとの連携が容易

例えば、カメラが画像を取得した瞬間にMQTTで送信すれば、サーバーは即座にそれを受信し、YOLOで解析できます。さらにその結果をトピックとして配信すれば、別のシステム（通知や制御）にも即時連携できます。

この仕組みを使えば、

・異常検知 → 即通知
・温度上昇 → 扇風機ON
・乾燥 → 自動水やり

といった「リアルタイム制御」が可能になります。

また、MQTTはESP32などのマイコンとも相性が良く、将来的にセンサーやデバイスを追加する際にも非常に拡張しやすい構造になります。

ここまで来ると、最初は「トマトを見守る」だけだったシステムが、

👉 「環境を理解し、自動で制御するシステム」

へと進化します。

最終的な理想構成は以下です。

この形になると「人間が見るシステム」から「自律するシステム」に変わります。

そしてこの仕組みは、トマトだけに限りません。

・農業
・見守り
・工場監視
・スマートホーム

さまざまな分野に応用可能です。

半年間の試行錯誤の中で分かったのは、

👉 OSSと市販機器だけでもここまでできる

ということでした。

そして今、

👉 カメラ映像は「データ」になり
👉 データは「AIで意味を持ち」
👉 MQTTによって「リアルタイムに動き出す」

ここから先は、さらに面白い世界が広がっています。

---