こんにちは。tuyomoriです。
農家とエンジニアの二足のわらじで活動しています。
今は「農薬×農業日誌アプリ NOULOG」を開発していて、
農薬選定で毎回オーバークロックする脳内NPUを、アプリ側に肩代わりさせる のが目的です。
この記事では、NOULOG の農薬データ構造を
「設計 → JSON化 → 実装 → 利用」 の流れで整理していく様子を紹介します。
農薬データは、一般的なマスターデータとは違い、
構造が複雑で、表記揺れが多く、現場で扱いにくい という特徴があります。
この連載では、NOULOG で実際に採用する
“現場で使える農薬データ構造” を中心に、
設計思想から実装までを順番に解説していきます。
この連載で扱う内容の大まかなロードマップを第１回の内容とします。
第2回:現場の課題（農薬データの難しさ）
農薬データは
- 項目が多い
- 表記がバラバラ
- 情報量が多い
- 検索軸が多次元
- ラベルが読みづらい
- 農家は脳内で多次元検索している
という理由で、普通のデータベース設計では扱いづらい領域です。
現場の農家がどのように農薬を選んでいるのか、
その“脳内フロー”を具体的に紹介しながら、
農薬データの構造化がなぜ難しいのかを解説します。
第３回:NOULOG でどう整理するか（データ構造の思想）
- NOULOG は農薬データベースではない
- NOULOG の目的は農薬選定の意思決定支援である
- 農薬データはそのままでは複雑すぎて使えない
- 生データには多重ネスト構造の問題がある
- NOULOG はネストを避けてデータを分解する方針を採用する
- NOULOG のテーブル構造（6テーブル）を定義する
- この構造により軽量・高速・更新容易なデータ運用が可能になる
第3回では、NOULOG が「単なる農薬データベース」ではなく、
農薬データ × 現場文脈 を組み合わせた 意思決定支援システム を目指していることを説明します。
そのために、生データの多重ネスト問題を避け、
6つのテーブルに分解した フラットなデータ構造 を採用します。
これにより、アプリ側でも扱いやすく、更新しやすい軽量なデータ運用が可能になります。
第４回:生データからCSVへの加工とJSON変換
- 生データを4つのテーブルへ機械的に分離するロジックを作る
- CSV を“編集・更新のための中間フォーマット”として扱う
- CSV から JSON へ変換する実装を行う
- データ更新の仕組みとして source_version と change_log を導入する
第4回では、生データを NOULOG のデータ構造に合わせて
CSV → JSON → DB へ変換する実装手順を解説します。
テーブル分割、CSV の役割、更新管理（source_version / change_log）など、
実際にアプリで扱える形に落とし込むための処理フローを整理します。
第５回:データ利用の検討（アプリ側の実装）
- JSON データを Android アプリに読み込む仕組みを作る
- データ更新を効率化するためのキャッシュ戦略を設計する
- 作物・病害虫・成分・RAC を横断する検索・フィルタリングを実装する
- UI とデータ構造を接続し、現場で使いやすい画面を設計する
- 運用時の注意点（データ更新・バージョン管理・不整合対策）を整理する
- データ拡張（作物・成分・使用回数など）に対応できる構造を検討する
次回 予告
次回は 第２回で「現場の課題（農薬データの難しさ）」 を掘り下げます。
なぜ農薬データが扱いにくいのか、現場で何が起きているのかを整理します。
第2回現場の課題（農薬データの難しさ）
https://qiita.com/tuyomori/items/28230af0b8b4adcf7f19