海のない土地のシーバス：海から遠く離れた海水魚のための自動給餌システムを作る

チャンタブリーには海岸線がある。ナコンラチャシマにはない — 一番近い海水でも車で5時間はかかる。それでもやろうと思えば、コラート郊外の陸上施設でアジアシーバス（Lates calcarifer、バラマンディ）を育て、正真正銘の海産魚として売ることができる。障害になったことは一度もない、それは生物学的な話ではないからだ。シーバスは広塩性魚（euryhaline）で、全濃度の海水から淡水まで動じずに適応する。だからこそタイの河口部の生簀ですでに養殖されている。本当の障害は、水槽には失敗をそっと薄めてくれる海の水量がないということだ。

外海であれば、給餌ミス、アンモニアの急上昇、溶存酸素の低下は、生簀の脇を流れる何百万リットルもの水によって緩衝される。しかし120平方メートルの循環式水槽システムでは、そうはいかない。誰かが「気づく」まで、静かに悪化し続ける — そしてその「気づく」は、多くの場合ダッシュボードのアラートではなく、大量へい死という形で現れる。

これは養殖の問題ではなく、制御システムの問題である

タイの国家科学技術開発庁（NSTDA）傘下MTECはすでに生物学的側面と経済性を実証済みだ。40kg/立方メートルの密度で6水槽を運用する自動RASでシーバスを養殖すると、月あたり約340kgの生産量となり、流水式に比べて水使用量を94%削減できる。東南アジアのRAS市場規模は2026年の約17億米ドルから2035年には26億米ドルへ成長すると見込まれている。需要と生物学的な実現可能性は、すでに解決済みの問いだ。

まだ確立されていないもの — 内陸RASの大半で静かに失敗する部分 — は制御レイヤーだ。海が失敗を許してくれない環境で、4つのパラメータを継続的に狭い範囲内に保つ必要がある。

• 溶存酸素（DO）：高密度養殖では急速に低下し、水槽全体を巻き込む
• アンモニア・亜硝酸：給餌の合間に目に見えず蓄積し、手動検査で気づいた時にはすでに魚がストレスを受けている
• 塩分濃度：補給水や蒸発によって変動し、シーバスはある程度まで耐えられるが、それを超えると容赦がない
• 給餌のタイミングと量：過剰給餌は上記3項目が依存する水質を汚し、過少給餌は単に利益を目減りさせる

これは工場フロアと同じ形をした問題だ。分散したセンサー、誰かが見ているかどうかに関わらずスケジュール通りに動き続ける制御ループ、そして高くつくまで見えてこない障害モード。私たちが以前、工場フロアのOTプロトコル分断や真空炉の熱監視について書いたのと同じ理由がここにもある — 容器の中身が溶融金属であろうと海水であろうと、センサー・制御ロジック・アラートは同じ規律の話なのだ。

システムが実際にやるべきこと

flowchart TD
    SENS["センサー  
DO・pH・アンモニア・塩分・水温"] --> CTRL["制御ループ  
しきい値ロジック・給餌スケジューラ"]
    CTRL --> FEED["自動給餌機  
時刻指定 / 需要ベース"]
    CTRL --> AER["エアレーター・ポンプ  
DO補正"]
    CTRL --> ALERT["アラート  
SMS / LINEで運用者へ"]
    SENS --> LOG[("時系列ログ  
読み取り専用")]
    CTRL --> LOG
    FEED --> LOG

    classDef sense fill:#0f172a,stroke:#eab308,stroke-width:1px,color:#fde68a;
    classDef core fill:#082f49,stroke:#38bdf8,stroke-width:1px,color:#bae6fd;
    classDef act fill:#052e16,stroke:#22c55e,stroke-width:1px,color:#bbf7d0;
    classDef data fill:#134e4a,stroke:#14b8a6,stroke-width:1px,color:#99f6e4;
    class SENS sense;
    class CTRL core;
    class FEED,AER,ALERT act;
    class LOG data;

ここに突飛なものは何もない。センサー群（DO、pH、アンモニア、塩分、水温 — 水処理や産業プロセス監視で使われるのと同じクラスのプローブ）、給餌と補正のタイミングを判断する制御ループ、実行系（給餌モーター、エアレーター、ポンプ）、そしてへい死が起きる前に運用者のスマートフォンへ届くアラート経路。よくある失敗は、給餌機を単体のタイマーとして扱ってしまうことだ。水質を継続的に読み取る制御ループの一つの出力として扱わなければならない — それが単なる自動給餌機と、自動化された「養殖システム」との違いだ。

ソフトウェアスタックの中身

上の図の各レイヤーは、あえて「地味で枯れた」Pythonツールチェーンにマッピングされている。目新しさは、制御ループのバグを大量へい死という形で発見する原因になるからだ。

エッジ層（水槽ごと、現場デバイス上で稼働） 産業用グレードのDO・pH・塩分プローブは、きれいなデジタルバスよりもアナログ（4〜20mA）またはModbus RTUで出力することがほとんどだ。そのためエッジコントローラーは、プローブのグレードに応じて標準Pythonを動かすRaspberry Pi、あるいはMicroPythonを動かすESP32のいずれかになる。

• pymodbus — Modbus RTU/TCPプローブ（産業用DO/pHトランスミッターの一般的な出力形式）をポーリング
• smbus2 / adafruit-circuitpython-* ドライバ — Modbusがない安価なI²Cセンサーボード向け
• gpiozero または RPi.GPIO — 給餌モーター、エアレーターのリレー、投薬ポンプの出力を駆動
• asyncio — センサーポーリング、制御ループ、アクチュエーター書き込みを1台のデバイス上でブロッキングなく並行実行

トランスポート センサー値とアクチュエーターイベントは1対1ポーリングではなくMQTT経由で発行される — 工場フロアと同じパターンであり、「五つの方言」で書いたプロトコル分断問題への対処法と同じだ。エッジ側ですべてを一つのバスに正規化し、バックエンド側にModbusを喋らせない。

• paho-mqtt — 各水槽コントローラーの読み取り値をローカルのMosquittoブローカーへパブリッシュ
• orjson — センサーペイロードを高速にシリアライズ

制御ループ ここはローカルで動く必要があり、ネットワークの往復を待てない部分だ。

# 各水槽のエッジコントローラー上で30秒ごとに実行
async def control_tick(tank: TankState) -> None:
    reading = await read_sensors(tank)          # pymodbus / smbus2
    if reading.do_mg_l < tank.thresholds.do_min:
        await actuate("aerator", tank.id, on=True)
    if reading.salinity_ppt < tank.thresholds.sal_min:
        await actuate("brine_dose", tank.id, ml=tank.dose_step)
    if feed_scheduler.due(tank):                 # APSchedulerで駆動
        await actuate("feeder", tank.id, grams=tank.feed_ration)
    await publish(reading, tank)                 # paho-mqtt → broker
    if reading.breaches_critical(tank.thresholds):
        await alert(tank, reading)                # LINE Notify / Twilio

• APScheduler — 水槽ごとの給餌タイミングを制御（固定間隔だけでなく、時刻指定・需要ベースのスケジュールにも対応）
• pydantic — アクチュエーターを動かす前に、すべてのセンサーペイロードとしきい値設定を検証

バックエンドとダッシュボード simpliDepotがすでに使っているのと同じDjango 5スタックを使い、時系列データはトランザクションデータとは分離して扱う。

• Django + djangorestframework — 水槽設定、しきい値、給餌スケジュール、農場・サイト管理
• Django Channels — WebSocket経由で運用者ダッシュボードへリアルタイムに水槽データをプッシュ
• influxdb-client（またはpsycopg2/asyncpg経由のTimescaleDB）— リレーショナルOLTPスキーマに乗せるべきでない高頻度センサー時系列データを保存
• celery — スケジュールレポート、日次の飼料転換率（FCR）集計、30秒サイクルで動かす必要のない処理

アラート LINE NotifyまたはTwilio APIに対してrequestsを使用 — simpliDepotがすでに農家・買い手への通知に使っているのと同じチャネルであり、運用者は普段開いているアプリで水槽のアラートを受け取れる。

実際の魚に触れる前に、制御ループはシミュレーション水槽に対して検証される — 給餌・DO・アンモニアの動態を離散事象シミュレーションするsimpy、あるいはnumpyによるセンサー値の簡易モックを使い、1シーズン分の変動データに対してしきい値ロジックを検証してから、無人で夜間稼働させる。

なぜこれが日本企業にとって意味を持つのか — 調達リスクの分散という文脈

日本は水産物の多くを輸入に依存しており、天然漁獲は気候変動や地政学リスクの影響を受けやすい。経済安全保障推進法が重要物資のサプライチェーン強靭化を求める文脈の中で、内陸養殖はその論点に直接関わる — トレーサビリティが確保され、天候や漁場の情勢に左右されない、計画可能な供給源になり得るからだ。制御システムが30秒ごとに自動保存するDO・水温・塩分の時系列ログは、輸入先評価やHACCP・JFS相当の品質保証プロセスで求められる裏付け記録そのものであり、朝一回だけ手書きされる記録簿とは根本的に異なる。

商社や食品加工企業がタイ内陸部のRAS運用に技術投資や調達提携を検討する際、問われるべきは「養殖プラットフォームを買うかどうか」ではない。生物学はすでに機能しており、市場は沿岸の生簀養殖より低コストな内陸産シーバスを求めている。あとに残るのは、問題を朝の死魚のカウントで知るのではなく、リアルタイムで検知できる制御システムがあるかどうかだけだ。

FAQ

シーバス以外でも使えますか
使えます。シーバスは、タイですでに商業的に実証済みで、水槽システムが現実的に維持できる塩分範囲に耐えられるという理由から、最初の対象種として最も自然な選択です。同じセンサー・制御・給餌アーキテクチャは、他の広塩性・汽水耐性種で地元市場のあるものにも応用できます。

人工海水塩が必要ですか、それともタンクローリーで海水を運んでも構いませんか
実務上どちらも使われています。それはサイトごとのコストと物流の判断であり、制御システムの技術的な制約ではありません。塩分をどの供給源であっても範囲内に保つ必要がある、という点では同じセンサー・投薬の問題です。

地方サイトでインターネットが落ちたらどうなりますか
制御ループ（センサー→しきい値→アクチュエーター）は接続状況に関わらずローカルで動作しなければなりません。エアレーターを動かすかどうかの判断をクラウドとの往復通信に依存させることはできません。接続はログ記録・アラート・遠隔監視のためのものであり、安全に直結するループそのもののためではありません。これは、通信が不安定な地方のデポサイトに対して私たちが前提としているオフラインファーストの制約と同じです。

これはすでに実在する製品ですか
これは、実証済みのRAS経済性と、当社が既に持つIMCS/OT監視の実績をもとにスコープを検討中のコンセプトであり、まだ出荷可能なプラットフォームではありません。内陸RAS事業の運用や検討をされていて、御社のサイトに必要な制御システムの中身について話し合いたい場合は、お問い合わせください。

出典: NSTDA/MTEC 集約養殖向け自動RASシステム、東南アジアRAS市場, GM Insights、アジアシーバス／バラマンディの養殖, Global Seafood Alliance