こんにちは。株式会社kikitoriの大木です。
kikitori では JA や卸売市場向けの SaaS 「nimaru」を開発しています。
農業現場には、そのままだとシステムで扱いにくい情報が多く、どう取り込めばよいか悩むことが多々あります。
今回は、生産者の方が栽培記録をつける際に使用する「農薬登録情報」を取り上げます。
ドメインとしては少し特殊ですが、同じような構造化しづらいデータに向き合っている方の参考になれば嬉しいです。
農薬登録情報とは
農薬のボトルなどに記載されている、適正な使用に関する基準のことです。
この使用基準は、農林水産省所管の独立行政法人である 独立行政法人農林水産消費安全技術センター（FAMIC） が公開している登録情報に基づいています。
使用基準には、こういった情報が含まれています。
- 使用量（例：10kg/10a）
- 希釈倍数（例：1000倍）
- 使用時期（例：収穫前7日まで）
- 本剤の使用回数（例：本剤3回以内）
- 使用方法
- 有効成分ごとの回数制限
nimaruでは、生産者やJA職員の方が基準に沿って農薬情報を扱えるように、この登録情報を取り込んで適正使用の判定に活用しています。
一見シンプル、でも扱いが難しい
使用基準は、一見するとシンプルに見えます。
- 使用量は
8〜10kg/10aの範囲に従って使用する - 使用時期は
収穫前7日まで - 栽培期間における使用回数は
3回以内 - 原液の希釈倍数は
1000倍
数値もあり、条件もはっきり書かれているため、最初は「パターンを抽出してパースすればよいのでは」と考えていました。
しかし調べていくうちに、難しさが見えてきました。
- 単位が揺れている（kg, g, mL, ppm など）
- 希釈倍数と使用量が、1つの項目にまとめて書かれている
- 但し書きや例外が途中に入っている（「ただし施設栽培の場合を除く」など）
- 基準は不定期に改訂される
農薬登録情報は法令に基づく情報なので、誤った取り扱いは重大な問題につながります。
パターン抽出だけでは安全に扱えないことが分かってきて、どう構造化するかを本格的に考え始めました。
ユーザーに基準を設定してもらう方式
最初に考えたのは、登録情報の解析は入力補助にとどめて、最終的な判定基準はユーザーに設定してもらう方式です。
農薬登録情報 ↓（簡易パース） 入力補助 ↓ ユーザーが基準を設定 ↓ システム判定
この方式なら、判定ロジックはシンプルになります。
基準をユーザーが設定するので、どの条件で判定しているかも分かりやすくなります。
ただし、実際の運用を考えると課題がありました。
現場では数十から数百種類の農薬を扱うこともあるので、それぞれに基準を手で設定するのは手間がかかります。
また、登録情報は不定期に更新されるので、そのたびに設定を見直す必要も出てきます。
安心感はありますが、本番運用をするには難しい構成でした。
どこまで構造化できるか
次に考えたのは、ラベルの文言を機械的にパースして、判定に使える形にする方法です。
- 数値を抽出して
min / maxにする - 「◯回以内」を整数にする
- 「収穫前◯日」を基準イベントからの相対日数にする
機械的に読み取れる部分は、このように構造化できます。
ただし、全部を同じように扱えるわけではありませんでした。
- 表記揺れ（「10aあたり」「10a 当たり」など）
- 条件付きの例外
- 1つの基準の中に含まれる複数の条件
- 曖昧な但し書き
機械的に扱える部分と、人が読まないと分からない部分が混ざっていました。
この状況をCTOに相談して、パースできる範囲とできない範囲を分ける方針になりました。構成の大枠や詳細はCTOに、自分からは現場のデータの実態を共有する形で詰めていきました。
Raw と Parsed を分けて持つ
採用したのは、Raw（原文）と Parsed（解析済みデータ）を分けて持つ構成です。
同じ項目でも、Raw は原文をそのまま文字列で持ち、Parsed は機械的に扱える形に変換しています。
構造化できる例
| 項目 | Raw（原文） | Parsed（解析後） |
|---|---|---|
| 使用量 | 8〜10kg/10a |
min: 8, max: 10（数値の範囲） |
| 希釈倍数 | 1000倍 |
min: 1000, max: 1000 |
| 使用時期 | 収穫前7日まで |
基準: 収穫日, 日数: -7 |
| 使用回数 | 3回以内 |
3 |
構造化できない例
| 項目 | Raw（原文） | Parsed |
|---|---|---|
| 使用量 | <床土･堆肥>1穴当り3mL<圃場>1穴当り2～3mL |
解析しない |
| 使用時期 | 3～5月株養成期 |
解析しない |
画面表示には Raw、判定には Parsed を使うことで、ユーザーが見る情報とシステムが使う情報を分けています。
構造化できない基準には「要確認」のフラグを立てて、自動判定ではなく意思表示で確認する形式にしました。
曖昧なまま自動判定を行わない、というのがこの設計の意図です。
どこまで自動で判定するか
この構成により、「自動で判定するもの」と「人が確認するもの」を分けられるようになりました。
自動で判定するのは、数値や日付のように機械的に扱えるものです。
- 数値の範囲チェック
- 使用回数の累積チェック
- 使用時期の相対日数の計算
一方で、基準のなかには機械的に扱いづらいものもあります。
そういったものは無理に自動判定を通さず、適正使用の意思表示で確認できるようにしています。
- 曖昧な但し書き
- 想定していない単位
- 条件付きの例外
この線引きがあることで、生産者の方やJA職員の方にも「ここはシステムが見ています」「ここはご自身で確認してください」と伝えやすくなりました。
おわりに
今回のケースでは、全部を自動化しようとせず、機械的に構造化できる範囲と人が判断する範囲を分けることが重要なポイントでした。
非構造な情報をシステムで扱う場面で、何かの参考になれば嬉しいです。
We're hiring!
kikitoriでは事業拡大に伴い、一緒に働く仲間を募集しています！
ご興味ありましたら、ぜひお気軽にエントリー・面談をお申し込みください。 お待ちしております！
