この記事は連載「農家エンジニアの現場データ構造」の第2回です。
前回：第1回 「全体のロードマップ」
https://qiita.com/tuyomori/items/95ce38547491c5547586
次回：第３回 「NOULOG でどう整理するか（データ構造の思想）」
https://qiita.com/tuyomori/items/6b1e8583aa9d801d32d7
■ 農薬ラベルには“守らないといけない情報”がびっしり書いてある
農薬を使うときに必ず確認しないといけない項目は、ラベルに全部書いてあります。
- 商品名
- 適用作物
- 希釈倍率
- 使用量
- 使用方法
- 使用回数制限
- 成分
どの農薬も基本的には同じ構成で書いてあるのですが、
とにかく字が細かくて情報量が多い。
「必要な情報は全部ある。でも、探しにくい。」
これが現場の実感です。
■ 実際の農家はどうやって農薬を選んでいるのか（リアルな思考フロー）
ここが一番伝えたいところです。
農薬選びは、実はこんな “圃場ごとに別々の脳内コンピュータ” で行われています。
→ 茄子を作っている（A圃場・B圃場・C圃場…）
→ A圃場でオオタバコガが発生
→ 「A圃場は前回何を使ったっけ？」
→ A圃場の散布履歴を思い出す（or メモを見る）
→ 手持ちの農薬を見る → A圃場では RAC が被るな…
→ 「じゃあ A圃場に合う農薬を検索しよう」
→ 候補を見つけて散布する
→ 終わったら A圃場の記録を書く（忘れることもある）
→ 数日後、B圃場でもオオタバコガが発生
→ 「B圃場は前回何を使ったっけ？」
→ A圃場とは別の履歴を思い出す
→ B圃場では使用回数が残っていない農薬もある
→ 在庫も A圃場とは違う
→ 「じゃあ B圃場用に検索しよう」
→ 散布 → 記録（忘れることもある）
→ 圃場ごとに判断がバラバラ
→ 記録を忘れると、どの圃場で何を使ったか分からなくなる
→ 日誌がどんどん曖昧になっていく
正直、文字にすると一連の流れに見えますが、
実際は スマホがCPUで、自分がNPUみたいな状態 です。
スマホ（CPU）は
「検索」「表示」「計算」みたいな直列処理が得意だけど、
農家（NPU）は
圃場 × 病害虫 × 履歴 × 在庫 × 成分 × RAC × 使用回数
を全部まとめて“同時に”処理しないといけない。
A圃場は前回アファーム
B圃場は前回プレオ
C圃場は使用回数がもう残っていない
在庫はA圃場にしかない
RACはB圃場だけ被っている
……こんな条件を、
毎回判断しないといけない。
これが現場のリアルです。
■ 検索軸が多すぎて、調べ方が分かりにくい
例えば「茄子 農薬」で検索すると、
それっぽい情報は出てきます。
でも、そこからさらに
- 何の病害虫に効くのか
- 希釈倍率はいくつか
- 使用回数は何回までか
- 成分は何か
- その成分の RAC コードは何か(RACコード輪番を意識しない人もいる)
…と、検索軸が複数に分岐していく。
そして、それらを 自分で掛け合わせて判断 しないといけない。
■ 成分と RAC コードの問題（耐性回避）
農薬にはいろんな成分があり、
それぞれに RAC コード（作用機構分類） が付いています。
同じ 成分を連続で使うと耐性がつく
同じ RAC を連続で使うと耐性がつく
違う 成分をローテーションする必要がある
違う RAC をローテーションする必要がある
つまり、農薬を選ぶときは
「作物 × 病害虫 × 成分 × RAC × 使用回数」
という 多次元の条件 を同時に考えないといけない。
■ 農薬検索サイトはある。でも「数が多すぎる」
農薬一覧を検索できるサイトはあります。
病害虫から絞り込めるサイトもあります。
でも、実際に使うとこうなる。
- ヒット数が多すぎる
- 似た商品名が多い
- 成分が違うのか同じなのか分かりにくい
- 希釈倍率や使用回数がバラバラ
「結局、どれを選べばいいのか分からない」
これが農家の本音です。
■ 日誌データと掛け合わせたい。でも構造化が難しい
本当は、
-
自分の畑の作物
-
これまで使った農薬
-
成分のローテーション
-
使用回数の累積
-
在庫情報
こういう 日誌データと農薬データを掛け合わせて、
“今使える農薬” を自動で絞り込みたい。
でも、そのためには農薬データを
機械が扱いやすい形に構造化する必要がある。
ここで問題が起きる。
■ 普通に構造化すると「ネスト地獄」になる
農薬データを素直に JSON にすると、
農薬
作物
病害虫
希釈倍率
使用量
使用回数
成分
みたいに ネストが深くなりすぎる。
スマホアプリで扱うには重いし、
更新も難しい。
■ だから NOULOG では「ネストを避ける」設計が必要になる
この問題を解決するために、
NOULOG では “ネストしないデータ構造” を採用する。
（→ 第3回で詳しく説明）