この記事は連載「農家エンジニアの現場データ構造」の第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回で詳しく説明）