メインコンテンツへスキップ
見出し画像

PDCAを全部AIで回したい。農家が作った5つのシステムの全体像


    農業DX挑戦シリーズ #08

    この記事は、個人農家がIoT・クラウド・生成AIを活用して独自のスマート農業システムを構築する過程を発信する「農業DX挑戦シリーズ」の第8弾です。

    1. ずっと見せられていなかった「全体像」

    これまでの記事で、僕はいくつかのシステムの話をしてきました。

    AIエージェントの安全設計の話、ローカルGPUの話、音声入力の自動化、そしてAIとの協働開発の話——でも振り返ってみると、実は肝心の「農業システムそのもの」の全体像を、まだちゃんとお見せできていなかったんです。

    「こんなシステムを作っています」とざっくり触れたことはあります。でも、実際のアプリの画面を見せたり、具体的にどう動いているかを示したりする機会がなかった。読者の方からすれば、「この人、結局何を作ってるの?」という状態だったかもしれません。

    本当は、それぞれのアプリについて1本ずつ丁寧に解説記事を書いてから、最後に全体像をまとめるつもりでした。でも、開発のスピードが自分の想定を超えてしまって。1つのアプリについて記事を書いている間に、次のアプリがもう動き出している。気がつけば、やりたかった全体像——PDCAサイクルを回す5つのシステム——が、ほぼ形になっていました。

    だったら、順番にこだわるのはやめよう。今のこのタイミングで、全体像をドンと見せてしまおう。各アプリの細かい話はまた別の記事で深掘りするとして、まずは「僕が何を作って、どう使っているか」の全体図を1本にまとめたいと思います。

    個人農家が、生成AIを使ってここまでの規模でシステム化している事例は、おそらくまだ多くはないと思います。栽培管理や販売管理をアプリ化している方はいらっしゃいますが、Plan・Do・Check・Actの全フェーズにわたって、事業のほぼ全てをシステムでカバーしようとしている試みは、少なくとも僕が知る限りではあまり見かけません。

    だからこそ、今の段階で出す意味があると思いました。PDCAサイクルを、AIとシステムで全自動に回す。 就農2年目、34歳。浪江町の切り花農家として、僕はそれを本気で目指しています。


    2. 4フェーズの全体設計図

    まず全体像を俯瞰してみます。

    システムはPDCAの4フェーズに対応する形で設計しています。

    • Plan(計画):何を、いつ、どれだけ作るか。作付け計画と多品目管理。

    • Do(実行):現場で何が起きているか。IoT制御とデータ収集。

    • Check(分析):経営全体の数字はどうなっているか。データ統合と横断分析。

    • Act(改善):次に何をすべきか。AI解析と意思決定支援。

    それぞれのフェーズに対応するシステムがあります。

    • Plan → Cultivation Manager App、Polyculture Board

    • Do → Eolica System(IoT環境制御)、ハイブリッド記録システム

    • Check → Streamlit統合分析ダッシュボード

    • Act → OpenClaw(AI秘書、開発中)

    そして、この全レイヤーを貫通する共通キーが存在します。cultivation_id(作付け番号) です。「この作付けは何番か」という情報が、Plan段階で生成され、Doの現場記録に紐づき、Checkの分析でも、ActのAI判断でも一貫して使われます。異なるシステムをまたいでデータを追跡できるのは、このIDのおかげです。

    画像

    4レイヤーで整理するとこうなります。

    • Control Layer:Eolica System(メイン制御・ヒーター・灌水・独立制御・写真アップロード・収穫入力UI)

    • Operation Layer:栽培管理・収穫出荷管理・業務自動化(音声入力・Slack日報)

    • Management Layer:予算管理・販売管理・公式Webサイト

    • Data Layer:BigQuery Data Lake・栽培環境分析・FAJ市況データ・Streamlit統合分析

    • AI Orchestrator:OpenClaw(WSL2/Docker、Slack連携)

    5つのシステム、4つのレイヤー、1つのID。これが今のFarm Eolicaの骨格です。


    3. Plan — 作付け計画と多品目管理

    「何を植えるか」を決める作業は、農業経営で最も戦略的な判断のひとつです。品目によって単価は違う。作期によって労働量は変わる。市場のトレンドも読まなければならない。感覚で決めていた時代を、そろそろ終わりにしたかったんです。

    Cultivation Manager App

    作付け管理に特化した3タブ構成のWebアプリです。

    • 栽培管理タブ:作付けごとの生育状況、管理作業の記録

    • 収穫・出荷管理タブ:収穫本数・出荷記録・市場速報値との照合

    • 作付け管理タブ:何をいつ作付けするか、作業予測・経費予測を含めた計画立案

    画像
    Cultivation-managerアプリのデフォルト画面。作業記録・収穫記錄・作付計画の3タブ構成
    画像
    作業記録タブでは、日々の作業ほか生育記錄も可能です
    画像
    アプリでは簡易分析もできるので、おおよそのコスト感や労働イメージも付きやすいです(詳細分析は後述)
    画像
    もちろん栽培に係る資材の詳細情報や、在庫管理、散布管理(使用した回数や農薬コスト算出)などもできます
    画像
    収穫管理タブでは、収穫品質の記錄および出荷記錄を行います
    画像
    どんな品質で何本収穫できたか記録したり、どこに出荷したか記録します。私の経営数値出てしまうのであまりサンプル画像出せませんが…気になる方は後述のデモ御覧ください。
    画像
    作付計画画面。その名の通り作付スケジュールを考えます
    画像
    品目品種と植え付け圃場を設定すれば、出荷時期の平均単価や過去経費を参照して収益予想をしながら計画立てが可能です
    画像
    作付単位で細かく分析も可能

    一言で言えば、「何を、いつ作って、どう栽培して、どう売るか」を記録するためのアプリです。特に作付け管理タブでは、「計画」そのものをデータで扱えるようにしました。何本植えて、何日後に収穫できて、そのための経費はいくらか——これを数字で見ながら計画を立てられます。直感から、データに基づく意思決定へのシフトです。

    簡易的な分析機能もありますが、本格的な分析はStreamlitダッシュボード(Checkフェーズ)に任せています。このアプリの役割は、あくまで「Planを立てて、Doを記録する」こと。そこに注力しています。

    データベースはFirebase/Firestoreを使っています。UIから入力したデータはリアルタイムでFirestoreに保存され、BigQueryに同期されて分析に使われます。FirebaseをUI用、BigQueryを分析用に分けて使うスタイルに落ち着くまでには、紆余曲折がありました——それは後で触れます。

    Polyculture Board

    メイン品目の切り花だけでなく、Farm Eolicaでは花・野菜・ハーブなど多品目を栽培しています。Cultivation Manager Appはメイン品目のPlan〜Doに特化させたい。そこで、サブ品目の管理は別アプリに切り出しました。それがPolyculture Boardです。


    画像
    栽培中の品目の生育段階や作業ログを記錄確認できます
    画像
    育てている花の開花時期のカレンダーなどの表示
    画像
    品種ごとの特性などのライブラリ情報
    画像
    計画をチェックしながら、管理ログやマイルストーンの記錄も可能

    品種ごとの特性情報(栽培適温・収穫サイクル・相性の良い隣接作物など)をライブラリとして持ち、「何を植えて、いつ何をしたか」を細かく記録できます。多品目栽培は管理が煩雑になりがちですが、記録の仕組みさえあれば振り返れます。

    こちらもFirestoreを正本データとして使い、専用CLIツールを経由して読み書きする設計にしています。

    両アプリとも、自分で設計・実装したものです。完成度は100%ではありません。でも、「自分の農業のために自分が作った」というのは、既製品には絶対に出せない強みだと思っています。

    使っていて、少しでも気に食わないところがあれば、即日修正、ブラッシュアップできます。

    業者や企業に頼んだら、設計レベルの手戻りは嫌がられると思いますが、自分で作ってしまえば、インフラ設計から顧客まで全てのフローが一人で完結。運用しながら設計するという、通常のIT業界では考えたくもないような強硬手段が簡単に実現できるというのは、現場=開発者の最大のメリットですね。(その御蔭で、制限無く延々と開発にのめり込めてしまうのがデメリット)


    4. Do — 現場のIoTとデータ収集

    計画が決まったら、あとは実行するだけ——と言えれば楽ですが、農業はそうはいきません。現場で何が起きているかをリアルタイムで把握しなければ、計画通りに動けない。「ハウス5棟の環境を、自宅から制御したい。」そのために作ったのが、Eolica Systemです。

    Eolica System(IoT環境制御)

    ラズパイ(Raspberry Pi)上で動くローカル環境制御システムで、Control Layerの中核をなしています。世間一般の「スマート農業」のイメージに最も近いのが、このシステムかもしれません。制御対象は以下の通りです。

    • 換気(サイドカーテン・天窓)

    • 遮光・保温カーテン

    • ヒーター・クーラー

    • 灌水システム

    • カメラによる圃場写真のアップロード

    自宅のPCやスマホから操作できます。就農した当初は「現場に行かないと何もできない」が当たり前でしたが、今は自宅の画面を見ながらハウスの温度を確認し、ボタン一つで換気を調整できます。農作業の効率化、精度向上、時間短縮——このシステムが実現してくれたことは本当に大きいです。初めて動いた時は、正直、胃が痛くなるほど緊張しました(笑)。

    センサーデータ(温湿度・照度など)は自動収集され、Data Layerに蓄積されます。

    画像
    Eolicasystemの操作画面のサンプル

    ハイブリッド記録システム

    データの収集には、大きく分けて2種類あると考えています。

    1つは一次情報——自分の手で記録しなければならないデータです。作業内容、農薬散布の記録、栽培の手応えといった、現場にいる人間にしか分からない情報。これはUIで素早く入力できるようにしてあります。

    もう1つは二次情報——自分のところではなく、外部から取得してくる情報です。市場の卸価格データ、直売所の販売実績、メールで配信される市況速報、天気予報、ハウス内の環境センシング——これらは人間が手を下さなくても、基本的には全部自動化できると思っています。

    実際に、市況データはメールから自動取得していますし、直売所の販売データもBigQueryの外部テーブル経由で自動集計しています。現場の環境情報もセンサーが24時間収集し続けています。また、MFクラウドなどの帳簿データも自動化スクリプトでCSVを毎日取り込んで、ほぼリアルタイムに経理状況も把握できます。

    まだ全てが自動化されたわけではありません。灌水の自動化は今年中に完成させるつもりで、現在進めているところです。センシングもまだ最低限にしか設置できていないので、パーツを購入しての取り付けも急ぎ進めていきます。でも、「人間がやらなくていいデータ収集は全部機械に任せる。人間は、人間にしか記録できないことに集中する。」この考え方をベースに、少しずつ自動化の範囲を広げています。


    5. Check — データ統合分析基盤

    計画して、実行して、記録した。次はそれを「意味のある情報」に変える番です。ここが、今の僕が最も力を入れているレイヤーです。

    Streamlit統合分析ダッシュボード

    ローカルサーバー上で動くWebアプリで、経営判断に必要な全ての情報を一箇所に集約することを目指しています。

    画像
    環境モニタリングタブの一例。圃場や野外環境のデータ解析が可能
    画像
    作付ごとに詳細の分析ができるページ
    画像
    収穫量や品質の推移などもグラフで確認
    画像
    市場ビックデータを使用してマーケット分析など

    UXとしてイメージしているのは、「このダッシュボードを開けば、経営の全体像が分かる」という状態です。扱う情報は多岐にわたります。

    • 栽培データ(作付けごとの生育・収穫・品質の振り返り)

    • 作付けシミュレーション(何を・いつ作付けすると、売上と経費がどう変わるか)

    • 経理状態(売上・経費・利益の推移、融資の返済計画、キャッシュフロー、確定申告書の作成など)

    • 予算管理(計画比との乖離)

    • 環境情報(天気・天候・気温の履歴)

    • 市場卸価格の分析

    • 勤怠管理

    個人事業主の農家は、事業の支出とプライベートの支出がごっちゃになりがちです。だからこそ、そこをしっかり分けながら、ライフマネジメントも含めた統合的な分析ができることを意識しています。

    もちろん、作物の状態や栽培環境に特化した分析もできます。「この日の収穫量が多いけど例年と比較するとどうかな?」「市場価格が高い時期に出荷を集中させるには、いつ作付けすればいいか?」——点と点を線で繋げる分析が、ここで初めてできるようになりました。

    要するに、一人の個人農家が生きていくために必要な情報のおおよそ全てを、分析・集約できるものを目指しています。細かい分析項目は多岐にわたりますし、今もどんどんブラッシュアップしている最中ですが、大枠としてはこういう方向です。

    エクセルとLooker Studioから始まった旅

    なお最初からStreamlitを使っていたわけではありません。

    最初はそれこそエクセルの関数でデータの集計をしていましたし、マクロを覚えて半自動化を頑張って作ったりもしていました。

    就農初年度にChatGPTを使い始めたころ、分析ツールとしてまず使い始めたのはLooker Studio(Googleのダッシュボードツール)でした。BigQueryと繋いで、売上グラフや収穫推移を可視化できます。ノーコードで使えて、見た目も綺麗。エクセルベースのグラフであくせくしていた自分は、初めてこのツールに出会ったときは衝撃を受け、「これでなんでもいけるんじゃないか」と思っていました。

    でも、ブラッシュアップを続けるうちに気づきました。Looker Studioでは「点」の分析しかできない。特定の期間の売上を見ることはできます。でも、「その売上が生まれた背景にある栽培環境」と「市場価格の動向」と「その週の天気」を組み合わせて分析しようとすると、途端に限界が来ます。複数のデータソースをまたいだ動的な分析が苦手なんです。

    Streamlitに移行したのは、「線で繋げたかった」ことと、AI駆動ベースでの分析実装によりフィットしていたからです。Pythonで書けるので、データを自由に組み合わせて計算し、好きな形で可視化できます。「自分が本当に見たいものを見せてくれる」ツールに辿り着いた時の解放感は、言葉にならないものがありました。

    データ基盤の変遷

    データ基盤も、進化の歴史があります。

    最初は全部ローカルや既存サービス内でのデータ集計でした。スプレッドシート、CSVファイル、ローカルDB、Raspberry Pi上のストレージ——手元にあるものを組み合わせていました。シンプルですが、スケールしない。データが増えるほど管理が煩雑になり、システム間でのデータ共有も難しくなりました。

    今の構成は、Firebase/FirestoreとBigQueryの併用です。

    FirestoreはUI用のリアルタイムデータベースとして使います。アプリ画面に即座に表示する必要があるデータはここに置く。BigQueryは分析用のData Lakeとして使います。大量のデータを高速にクエリできる。Firestoreのデータは定期的にBigQueryに同期され、Streamlitがそこからデータを引っ張って分析します。

    速さが必要なものはFirestore。大量データの分析はBigQuery。それぞれの強みを活かす設計です。


    6. Act — AI解析による次のアクション(開発中)

    PDCAの最後、「A」のフェーズ。Check(分析)の結果を受けて、「では次にどうするか」を決める部分です。

    実はまだこのフェーズは実装中です。
    でもいちばん大切なフェーズだと考えています。

    現状の流れはこうです。Streamlitで分析結果を見る。「先月の単価が低かった品種は何か」「天候の影響で収穫遅れが出たのはどのハウスか」——これらを僕が自分の目で判断して、次の作付け計画に反映させています。

    もちろん自分がどうしたいのか(Plan)というのは自身が得られる最大の権利でもあるので、手放すつもりはないのですが、それでもデータアナリシスな考えに基づいてAIが解析アドバイスしてくれるというのはとても強い武器になると思っています。

    Planへのフィードバックも、可能にする。人間の直感力や経験・勘に加えて、AIの分析力も足せれば…成長のスピードはグッと上がると信じています。

    このAct(分析・アクション)部分を担うために開発中なのが、OpenClawです。

    OpenClawはSlackを通じて動くAI秘書で、WSL2/Docker環境上で稼働しています。今できることは多いです。市況メールの自動解析・Slack通知、タスク管理、会話からの情報整理、GitHubリポジトリの監視と仕様書同期——日常業務の「雑務」を肩代わりしてくれるようになってきました。

    でも、最終的に目指しているのはもっと先です。分析ダッシュボードのデータを読み込んで、「今季の切り花はこの品種の作付けを20%増やすべきだ」という提案をAIが自律的に行う。人間がいちいちダッシュボードを開かなくても、朝のSlackに「今週の判断事項」が届く。そういう未来です。

    P→D→Cまでは、おおよそ形になりました。 Aの自動化が完成すれば、PDCAサイクルが全自動で回り始めます。まだ道半ばですが、そこに向かっていることは確かです。


    7. 今後の展望——PDCAの先にあるもの

    「A」の完成に向けて

    ロードマップの核はシンプルです。PDCAの「A」を完成させること。

    OpenClawが分析データを受け取り、次の作付け計画の原案を提示する。人間はそれを確認して承認するだけ——そういうサイクルを目指しています。技術的には実現できるので、あとは時間の問題と思っています。LLMの能力は十分ですし、データ基盤も整ってきました。あとは、「農業ドメインの知識をどうシステムに組み込むか」という設計の問題です。

    デモプラットフォームと学習基盤

    もう一つ進めているのが、作ったアプリを「見せる場」と、Aiにより集約された知識やスキルを「学ぶ場」の構築です。

    Farm EolicaのHPでは、自分が作ったアプリのデモを公開する準備を進めています。完成度が低くても、バグがあっても、実際に触れる状態で公開することに意味があると思っています。

    うまくいけばプラットフォーム化でもしてみようかと…現在友人に相談しながら計画中。これについては別事業になりそうなので割愛します。

    ※試験的に下記FarmEolicaHPにて、この記事で紹介した各種アプリのデモを触れるようにしてみました。お時間あればぜひ

    そして、学習のための基盤も作りたい。今、自身のための「学習図書館システム」を構築中で、AIが集めてきた信頼できるソースを、自分が体系的に学ぶためのツールにしようとしています。これについても形ができてきたら発信していくつもりです。

    人間中心のAI活用——大切にしたいこと

    最後に、PDCAを回す中で僕が一番大切にしたいことを書かせてください。

    今、AIを使えば仕事の判断が効率よくできるようになってきています。相談相手としても優秀ですし、仕組みを作る上でも欠かせない存在になりました。でもその一方で、正直に言えば怖さも感じています。

    AIに頼りすぎると、自分自身の栽培技術や知見が育たなくなるんじゃないか。「技術不足」「知識不足」と言われるような、人間だけでは仕事ができない人材になってしまうんじゃないか——その危惧は常にあります。(というかおそらく、批判を恐れず言えばAIを使うほど人は馬鹿になると思う。でもいくら賢い人がいても、AIを使わなきゃ勝てなくなる。そんな時代になりそうな予感)

    だからこそ、僕はAIをあくまで「共同パートナー」として位置づけたいと思っています。自分を支えてくれるメンターであり、フォロワーであり、時には先生にもなる。でも、判断の中心は常に自分。人間中心で動かしていく。

    自動化できることは機械に任せて、人間にしかできない判断や、作物と向き合う時間に集中する。そして、学習プラットフォームを使って自分自身のスキルも磨き続ける。AIの力を借りながらも、農家としての自分自身が成長していくこと——それが、このシステム群を作っている本当の目的かもしれません。


    同じように農業DXに挑戦している農家さん、個人でシステムを作っているエンジニアさん——この記事が、何かの参考になれば嬉しいです。まだ全部できていないけれど、できていない過程こそ、いちばん面白い。

    一緒に、前に進みましょう。


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

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

     
     
    「人生は一度きり、主体性をもって楽しんで生きていこう」がモットーの34歳農家。福島県浪江町で切り花栽培中。2歳児のパパ。前職は出版社営業→人生リスタートで新規就農。理系知識×ITスキルで農業をアップデート。失敗も成功もリアルに発信|Farm Eolica|

    あなたへのおすすめ