【農家自作アプリ全解剖】営農のすべてをデータにしたくて、栽培管理アプリを自分で作った話｜CMS① 全体概要

農業DX挑戦シリーズ #09

この記事は、個人農家がIoT・クラウド・生成AIを活用して独自のスマート農業システムを構築する過程を発信する「農業DX挑戦シリーズ」の第9弾です。自作Webアプリ「Cultivation Manager System（CMS）」全解剖シリーズの第1回。今回から5回連続で全解剖します。

この記事は、僕が日々の栽培を回すために自作したWebアプリ「カルチベーションマネージャー」の、はじまりの章です。なぜ既製サービスでは足りなかったのか、生成AIの登場で何が変わったのか、そして「経営に関わるすべての判断材料をデータにする」という構想を、4つのタブにどう落とし込んだのか。これから始まる全5回シリーズの、いちばん最初の地図として書きました。

1. なぜ、自作することにしたのか

営農を始める前から、データで農業をやりたかった

「農業って一言で言うけど、結局何でもやるじゃんね」

ほんとその通りなんですよ。一人で営農してると、考えることが本当に多岐にわたります。

「勘と経験で技術を上げて、良い品質の農産物を安定して作るのが一人前！」——そう考えている人も多いし、実際そういう世界だなぁと、就農してから何度も感じてきました。

でも、僕はちょっとだけ違う入口から農業に入りたかったんです。

たぶん、理系のバックグラウンドが効いてるんですよね。大学でデータ触って、会社員時代も数字を触る仕事ばっかり。気づいたら「勘より数字で語りたい」っていうクセが、身体に染みついちゃってました。

だから農業を始めると決めたときも、最初から思ってました。

「どうせやるなら、勘と経験だけに頼るんじゃなくて、データでブラッシュアップを回していけるような、そういう営農にしたいなぁ」って。

調べてみると、やはり現代はなんでもある。
スマート農業とか、時代の流れにうまく乗らんとしたアプリが多数。

それで営農1年目から、記録できそうなものは片っ端から記録していきました。
温度、換気、農薬、肥料、作業時間——とにかく何でも。栽培まわりは農家向けクラウドサービスの Agrihub に、計画や経営に近いものは Excel・Notion・Dropbox に溜めていく。

「これでデータドリブンな営農にだいぶ近づけてるぞ」

当時の僕は、そう思ってたんですよね。

※なお新規就農するまでの奮闘記についても、シリーズとしてまとめておりますので良ければご覧ください。

「記録はあるのに、つながらない」という壁

始めてみるとすぐにわかったのが、記録運用の難しさでした。

道具を増やせば増やすほど、情報がバラバラの場所に散らかっていくんです。

栽培の作業履歴はアグリハブの中。計画のネタはNotion。経費はExcel。写真はDropbox。メモはスマホの標準アプリ。しかもそれぞれ、テキストが向いてるもの、表が向いてるもの、画像でしか残せないもの——扱い方も保管場所も、ぜんぶ違う。

記録は確かに溜まっていく。でも、それを 横につなげる手段 が、どこにもない。

「あの作付け、結局いくらかかったんだ？」
「この品種、3年間でどう動いてきたっけ？」

本当に知りたい問いほど、いつも複数のツールをまたいでしまう。答えを出すには、僕が手作業でデータを引っ張り出してくるしかありませんでした。

これが、じわじわキツかった。毎回「同じことを頭の中でやり直してる」感覚。

写真をとったらキャプションにメモ書いて、栽培記録はNotionにまとめて…
熱量があるときにはできるけど、なかなか続くかこんなもの…っ！って状態にも。

既存アプリ（Agrihubなど）についても、栽培管理や農薬の使用記録という点では、本当によくできてるなぁと思っています。でも、そこから枠を飛び越えて経営全体を分析するのは、そもそも想定されていない。BigQuery（データベース）みたいな分析基盤に流す道もないから、データはアプリの中に閉じ込められたまま。

「経営に関わるすべての判断材料をデータにする」というところまで踏み込んで設計されたツールが、農家向けには存在していない。これが、僕が抱えていた根本的な問題でした。

ただ、これは当たり前といえば当たり前な話で。農家の現場って、個別差がとんでもなく大きい。品目・地域・経営規模・作型・売り先——どれかひとつ違うだけで、必要な記録の粒度も画面の作りも、ぜんぶ変わっちゃう。そこに細かく合わせてカスタマイズしたら、大企業だって開発コストは膨大になる。だから「全部の農家に当たる最大公約数の機能」しか提供できない。ある意味で、当然の帰結です。

だからこそ、あとでまた書きますけど、現場の人間が、現場のために、自分でアプリを書ける時代になった ——これ自体がとんでもない変化だと思っています。

5年後、10年後にはきっと近未来的なスマート農業が来る。データを全部つないで、環境制御も自動化されて、農家は数字を見ながら次の一手を打てるようになる——そういう未来は、ぼんやりと思い描いていました。

ただ、それを 個人が実現できる手段 が、その時点ではなかった。

だから「いつか、ね」って、心の棚の上にそっと置いておいたんです。

生成AIが、棚の上から下ろしてくれた

棚の上にあった構想が下りてきたのは、生成AIの登場がきっかけでした。

具体的には、ふたつのことが同時に起きました。

ひとつは、テキストも画像もまとめて扱える時代になったこと。日報のような自由文、農薬ラベルの写真、市況メールの本文、CSVの数字——形式がバラバラの情報を、AIがひとつの文脈で理解してくれるようになりました。バラバラの記録たちを横につなぐ手段が、ようやく現実的になったんです。

もうひとつは、個人がプログラムを書けるようになったこと。これは僕個人にとって本当に大きい変化でした。以前は「アプリを自作する」というのは専業エンジニアの仕事で、プログラムなんか触ったことがない個人の片手間でやれることではなかった。それが、AIに相談しながら自分で書ける時代になった。「いつか誰かが作ってくれる」を待たなくてよくなったんです。

このふたつが揃ったとき、棚の上に置いていた構想——営農に関わるすべての判断材料をデータにして、PDCAサイクルとして回す——が、はじめて「個人でも実現できそうな具体的なゴール」に変わりました。

それで、エディタを開きました。

（余談ですが、実は大学の頃友達とゲーム製作にハマっていた時期がありました。工学部の友達がスクリプト作成、自分がドット絵のイラスト担当。今でもAppストアに公表中なはず。あの共同作業が楽しかったけど、今では自分一人でもゲームくらい簡単に作れちゃう時代。嬉しいような、さみしいような…）

2. どんなアプリを作ったのか

全部を1つのアプリに詰め込むのは、やめました

僕が作りたかったのは、こういうものでした。

「営農に関わるすべての判断材料を、ひとつの体系の中で扱えるようにすること」

日々の作業も、農薬や肥料の使用も、収穫も、販売も、作付け計画も、経費も——気づいたこと、判断したこと、起きたことの全部を、明文化してデータとして残していく。それが回り始めたら、はじめて「データドリブンな農業」って呼べるんだろうなぁと思うんですよね。

ただし、これを ぜんぶ1つのアプリに詰め込もうとはしませんでした。

というのも、経営判断の中身って、役割によって求められるUIがぜんぜん違うんです。

日々の実行（Do）の部分は、毎日触るから、片手でサクッと終わるUIじゃないとダメ。ハウスの中で、泥だらけの手で、3タップで終わってほしい。計画（Plan）のほうも、振り返りや確認のために現場でチェックする機会がけっこうあるので、やっぱりモバイル寄り。

一方、分析（Check）と次の手の決定（Act）は、座ってじっくり腰を据えてやる作業。求められるUIもぜんぜん違う。

この両方を1つのアプリに詰め込むと、どっちも中途半端になりそうだな——というのが、設計初期に出した判断でした。

そこで P と D の部分を切り出した専用アプリ として作り始めたのが、このCultivation-manager（カルチベーションマネージャー）。Check と Act にあたる分析機能は、別途 Streamlit で作っている統合分析ダッシュボードに任せる、という割り切りです。

だからこのアプリには、派手なグラフも複雑な分析機能もほとんど入っていません。代わりに、「判断材料となる事実を、過不足なく、楽に、正直な形で記録する」 ことに全振りしています。

そうして必要なものを並べていったら、自然と4つのタブに落ち着きました。

• 栽培管理タブ：日々の作業・農薬・肥料・潅水・在庫を記録する場所

• 収穫・出荷管理タブ：収穫本数と販売実績を作付けに紐づけて積み上げる場所

• 作付け計画タブ：何をいつ作付けするかを決め、経費と売上の見込みを置く場所

• タスク管理タブ：単発・繰り返し・長期の作業を一画面で管理する場所

データは、絶対に諦めたくなかった

このアプリを作るうえで、いちばん強く心に決めていたことがあります。

「データ構造が複雑になるからこのデータは諦めよう」を、絶対にやらない。

地味だけど、いちばん大事なポリシーです。

経営判断に必要なものは、複雑でも面倒でも、全部記録できる形にする。判断の精度って、結局 記録の細かさ で決まると思うんですよね。大雑把に丸めた瞬間に、後から振り返ったときに何も言えなくなっちゃう。

これ、大学の研究時代、会社員時代、農業の現場、どこにいても何度も経験してきました。「もっとちゃんと取っておけばよかった…」って気づいたときには、だいたい手遅れなんですよ。

具体的にどういう細かさが必要か、ちょっと例を出してみますね（細かい例になるので読み飛ばしていただいて大丈夫です）。

農薬と肥料は、ただ「この農薬を撒いた」じゃ足りないんです。何をいつ散布したか、その時の植物の状態は、病害虫の発生状況は。去年と比べてどう違うのか。農薬に関しては法律も厳しいので、希釈倍率、散布量、その作物に対して規定上あと何回使えるか、収穫前日数制限はクリアしてるか——そこまで持って初めて、来年の防除計画の材料になる。

潅水は、「水をやった」じゃ足りない。手潅水なのか、スプリンクラーなのか、チューブ潅水なのか、通路に流したのか。方法によって、与えられる水量も、作業時間も、根への効き方もまるで違うんですよね。後から「あの作付け、潅水が足りなかったかも…」って検証するには、その粒度が要る。

生育記録は、「育ってる」じゃ足りない。ハウスを歩いていて気づいたことって、その瞬間に残さないと、そのまま消えていっちゃうんですよ。草丈や節数のような数値、生育段階の節目、病害虫の発生具合、欠株の数、その日の作物の表情を写した写真、ちょっとした違和感のメモ——記録できることはたくさんある。しかもそれは、品種ごとの粒度で残せたほうがいい。「あのハウス全体としては良かったけど、この品種だけ伸びが遅かった」って、品種で分けて持っていないと見えてこない情報なんです。翌年の作付けを考えるとき、頭の中のぼんやりした印象じゃなくて、写真と数字で去年の経過を振り返れる——これだけで、判断の安心感がまるで変わります。

タスクは、「TODOリストに並べて消す」じゃ足りない。農業の作業には、1回やったら終わる単発のものと、灌水のように一定間隔で繰り返すもの、そして芽整理のように数十時間を数日〜数週間かけて少しずつ消化する長期のものが、ぜんぶ混在してるんです。これを同じ箱で扱おうとすると、絶対どこかで無理が出る。だからカルチベーションマネージャーでは、タスクを最初から3種類に分けて設計しました。

作付け計画も、品目と品種を決めるだけじゃ足りない。いつ植えるか、どう管理するか、いつ収穫するかによって、発生するタスクや経費の山がまるで変わる。作型によって管理方法も大きく違うし、労働時間が発生するタイミングや作業量もぜんぶ変わる。計画段階で、その整合性まで考えに入れたい。

こういう「細かさを諦めない」設計を、4つのタブそれぞれに通してます。

「うわ、めんどくさそう…」って思った方、その感覚は正解です。普通に作ったら絶対めんどくさい。

だからこそ、入力側はできる限り自動化し、過去の記録から複製したり、面積比で一括按分したりといった工夫を重ねて、ユーザー（＝僕）の手が止まらないUI にすることも同時に追求しました。

理想は、「ユーザーが意識しなくても、その日その日の判断と作業を通じて、自然に正しい形のデータが蓄積していく」 状態。ここを目指して毎日ブラッシュアップを続けています。

P と D の間に、隙間を作らない

設計のうえで、もうひとつ譲れなかった軸がありました。

計画（Plan）と実行（Do）のあいだに、隙間を作らない——という方針です。

ここでいう「隙間」って、こういう状態のことなんですよね。

• 計画したのに、実行に移せない

• 実行したのに、記録が残らない

• 記録したのに、次の計画に反映されない

こういう途切れが起きるたびに、データが死にます。で、死んだデータって、判断材料になってくれないんですよ。

だからカルチベーションマネージャーでは、4つのタブを別々のアプリにせず、1つのアプリの中で完結させること に強くこだわりました。

• 作付け計画タブで作付けを決めた瞬間に、タスク管理タブにその作付け固有の作業が並ぶ

• 栽培管理タブで作業を記録した瞬間に、その作付けの実コストに反映される

• 収穫・出荷管理タブで売上が立った瞬間に、その作付けの粗利が更新される

これを別々のサービスでやろうとすると、必ずどこかで途切れる。だから1つのアプリにまとめました。

これが、P と D の統合UIとしてのカルチベーションマネージャーの、いちばんの存在理由です。

4つのタブを、たった1本の背番号で結ぶ

そして、この4つのタブを実際に結んでる仕掛けが 「作付け番号（cultivationNo）」 です。

難しい話じゃなくて、たとえば `202603` みたいに、`年（YYYY）+ その年の連番（NN）` で作る6桁の番号。「2026年の3番目の作付け」ってだけの背番号なんですよ。

ただ、この番号の使われ方がミソなんです。

• 作付け計画を立てると、その作付けに `202603` という番号が振られる

• 日々の栽培管理の記録は `202603` に紐づいて蓄積される

• 発生するタスクも `202603` に紐づく

• 収穫した本数と売上も `202603` に紐づく

• 最終的に `202603` の経費合計と売上合計を引き算すれば、その作付けの粗利が出る

つまり、「ひとつの作付けの一生」を、たった1つの背番号で追えるようになってる わけです。

テーブル設計の教科書的にどうこう言うよりも、現場で僕が一番使い慣れている呼び方を、そのままシステムの中心に置いた ——というのが正直なところです。判断材料を全部つなげる、という構想を支えているのが、この地味な背番号なんですよね。

3. このシリーズについて

なぜ、ここから紹介するのか

データドリブンな農業っていう大きな構想のうち、Farm Eolica で実用レベルまで動いてるシステムって、実はもう複数あるんです。

ハード面では Eolica System が走ってます。ハウスの環境制御・潅水・センシングなど、Doの一部を担う自動化システム。これも自作です。分析側では Streamlit の統合分析ダッシュボード がすでに実用可能なところまで進んでいて、こちらは Check と Act の入口を支えてくれています。

この中で、全体構想の「軸」と呼べる形がいちばん固まっているのが、このカルチベーションマネージャー です。

栽培計画から日々の作業記録、収穫、販売、タスク管理まで、ぜんぶを4タブに整理して、`cultivationNo` という背番号で串刺しにする。この設計があることで、Eolica System が拾ってくる現場データも、Streamlit が読み出す分析データも、すべて同じ背番号の上で語れる ようになっています。

CMSは、いわば PDCA全体を組み立てるための "背骨" です。

Eolica System や Streamlit の話もいずれ別の記事でじっくり書くつもりですが、まずは背骨であるカルチベーションマネージャーから紹介したい——というのが、このシリーズをこの順番で出している理由なんです。

これからお話しすること

というわけで、このあと4つのタブそれぞれについて、1本ずつ記事を書きました。

• 第2回：栽培管理タブ ——「いつ・何を・どれだけ撒いたか」を、片手で全部済ませたかった

• 第3回：収穫・出荷管理タブ ——育てた花を、雰囲気ではなく数字で売れるようにしたかった

※現在執筆中（近日投稿）

• 第4回：作付け計画タブ ——感覚の作付け計画を、自動で粗利まで弾ける "設計図" に置き換える

※現在執筆中（近日投稿）

• 第5回：タスク管理タブ ——作型を選べば段取りが降り、タスクを消せば記録になる

※現在執筆中（近日投稿）

各記事は今回と同じ感じで、「なぜそれを作ったのか」「どう設計したのか」「使うとどう変わったのか」を順に書いていきます。

そして各記事の最後には、有料パートを用意しました。

「自分も似たようなアプリを作ってみたいなぁ」
「AIに相談しながら個人開発をしてみたい」

——そんな方に向けて、構成のおおまかな図、技術スタック、データの持ち方、AIへの相談のとっかかりになるプロンプトの例などを、しっかりめに書き下ろしています。読まなくても本編の理解にはまったく影響しないので、興味があればどうぞ、くらいの位置づけです。

5本まとめての一斉公開（かなりのボリュームなので数日に分けての投稿になりますが）です。どこか1本からでもお付き合いください。

技術が気になる方へ

カルチベーションマネージャーは、Astro + Preact で組んだモバイル中心のWebアプリです。ハウスの中でも片手で操作できることを最優先にしています。

データの正本は Firestore に置き、夜のうちに BigQuery へ自動で同期される二層構成にしています。「現場の入力に必要な速さは Firestore、振り返りや横断分析の重さは BigQuery」という棲み分けで、別途構築している Streamlit 統合分析ダッシュボードはこの BigQuery を読みに来ます。

そして本文で触れた `cultivationNo`（YYYYNN 形式の背番号） が、4タブのデータを横断的に結びつけるキーです。テーブルを綺麗に正規化することよりも、業務上いちばん強い呼び名をシステムの中心に据えることを優先しました。

各タブの実装については、第2〜5回の有料パートで、データモデル・主要画面コンポーネント・設計上のハマりどころ・AIに相談するときのプロンプト雛形まで、踏み込んで書いていきます。

筆者について
福島県浪江町在住、34歳。2024年より切り花栽培を開始。理系出身の知識を活かし、IoTシステムを自作してスマート農業を実践中。屋号「Farm Eolica」にて、データドリブンな花卉栽培に挑戦している。

Homepage: https://farmeolica.com
Instagram: @farm_eolica
X (Twitter): @FarmEolica
note: https://note.com/farm_eolica