🪴

【朗報】ずんだもん、野菜になる。小学生のやさしい植物教育を目指して。

に公開

https://youtu.be/CrfLAZ1BOYg

1. 背景・課題

きっかけとなった光景

夏に帰省した際、旧友の家を訪れました。
友人の子は小学1年生になったとのことで、夏休みの宿題としてアサガオの観察をしていました。
彼がアサガオに水をやっている姿を見て、「俺もやったな~懐かしい。」と思っていました。

ふと気づいたのですが、
その子は空いた片手で、スマホの縦長動画を見ていました。

私が「アサガオ、育てるの楽しい?」と聞くと、その子は
「楽しくない。けど宿題だから。」
と答えました。

この一言が、本プロジェクトの出発点になりました。

理想: 子どもが植物に優しい心で接する経験の重要性

小学校1・2年生においては、身近な自然に親しみ、動植物に優しい心で接する教育が求められています。 以下は、文部科学省が定める道徳における指導要領を引用したものです。植物を育てることは、単なる理科の実験というよりも、「植物も生きている」ということを実感する活動です。

(中略)
指導に当たっては,児童のこうした活動や体験を通して,自然に親しみ動植物に優しく接しようとする心情を育てることが求められる。自然や動植物のもつ不思議さ,生命の力,そして,共に生きていることのいとおしさなどを自然や動植物と触れ合うことを通して実際に感じることによって,自然や動植物を大事に守り育てようとする気持ちが強く育まれる。

引用元: 文部科学省「小学校学習指導要領(平成29年告示)特別の教科 道徳編 pp.66-67

また、植物を育てる活動は感情知性、レジリエンス、自己効力感を向上させることが報告されています[1][2]

しかし、この理想と現実の間にはいくつかのギャップが存在しています。

課題①: 子どもが植物に接する機会は、減少している。

子どもが日常的に植物に触れる機会は減少傾向です。以下は、小学生の体験活動に対するアンケートです。半数以上の小学生は植物に接していないことが分かります。


引用元: 国立青少年教育振興機構「青少年の体験活動等に関する意識調査(令和元年度調査)令和3年3月 pp.35

アサガオやミニトマトの栽培を行う学校もあるかと思われますが、学期中の限られた授業時間と、夏休みの宿題として家庭任せになる状況だけでは、植物との関わりが不十分であることが実情です。

課題②: 植物を育てることは難しい。

「それなら家庭菜園をやればいい」と思われるかもしれません。しかし、植物の栽培は意外と難しいものです。経験がある方ならばご存知かと思われます。

  • 水やりの頻度・量がわからない: 多すぎれば根腐れ、少なすぎれば枯れる。
  • 環境の管理が難しい: 日当たり、温度、湿度のバランスが難しい。
  • 異変に気づけない: 病気や害虫の初期症状を見逃す。
  • フィードバックがない: 正しく世話ができているのか判断できない。

大人でさえ失敗しがちな家庭菜園を子どもが行うのは困難です。最終的には「枯らしてしまった」、「綺麗に咲かなかった」という失敗体験だけが残り、植物への関心がさらに薄れる可能性もあります。

課題③: 子どもにとって、成長途中の植物は面白さを感じにくい。

一因として考えられるのは、今時の子どもにとって成長途中の植物は興味を感じにくいと考えます。以下では小学校1年生〜3年生の半数以上が毎日1時間以上YouTubeを閲覧していることが報告されています。

引用元: NTTドコモモバイル白書2025 第7章 子どものICT利用 [資料7-13] YouTubeの利用頻度[学年別](単一回答)

スマートフォンの縦長動画やゲームは、リアルタイムのフィードバックがあり、常に新鮮な刺激を与えてくれます。一方で、植物の成長を感じ取るのには何週間も要します。発達心理学・教育心理の観点でいうと、前者のデジタルメディアは「即時報酬」、後者の自然体験は「遅延報酬」とならざるを得ません。「あっもうすぐ花が咲きそう!」、「花が咲いた!キレイ!」という達成感や感動を得るのには時間を要します。

また、植物に水をあげても「ありがとう」と言ってくれませんし、表情も変わりません。子どもにとって、植物が生きていることを実感するのは、難しいことです。


2. ソリューション: 植物に転生したずんだもんと会話する。

コンセプト: 植物が会話できるなら、関わり方が心から変わる。


本プロジェクトは、植物に生まれ変わったずんだもんが、自分の気持ちを言葉や表情で示して会話するシステムです。センサーを使用することにより土壌湿度(水分)・温度・湿度・照度をリアルタイムで取得して、それをもとに会話を行います。

  • 水が足りなければ「喉がカラカラなのだ・・・。」
  • 水を与えたならば「ぷはー!生き返ったのだ!」
  • 寒ければ「ちょっと寒いのだ・・・。」

植物は人や環境と調和しながら生きていること、水や光を必要としていること、世話をすれば喜ぶことをずんだもんを介して伝えます。

ユーザ像

  • 小学校低学年(6〜8歳)の子ども、およびその保護者や教師。 学校の授業や夏休みの宿題で植物の栽培・観察に取り組むが、十分な関心を持てず、「やらされている」感覚で世話をしている家庭。
  • 家庭菜園に興味はあるが、うまく育てられない人。 水やりのタイミングや環境管理に自信がなく、植物を枯らしてしまった経験がある方。

アプリケーション概要

本システムは、Raspberry Pi 5を中心としたエッジデバイスと、Google Cloudの各種サービスを組み合わせて構成されています。

主な機能

機能 説明
センサー監視 土壌湿度・温湿度・照度を常時モニタリングし、植物の状態を数値化
AI対話 Gemini 2.5 Flashがセンサーデータをもとに、ずんだもん口調で植物の状態を伝える
音声対話 人感センサーで人を検知→マイクで音声認識→AIが応答→ずんだもんの声で返答
表情変化 植物の状態に応じて、画面上のずんだもんの表情が変化(嬉しい・普通・悲しい・喉が渇いた等)
口パクアニメーション 音声出力に合わせて口が動き、キャラクターの存在感を高める

対話の流れ

https://youtu.be/CrfLAZ1BOYg?t=57

ユーザーが「お水足りている?」と聞けば、土壌湿度センサーの値をもとに「ちょっと喉が渇いてきたのだ・・・。お水をくれると嬉しいのだ!」と答えます。

システムアーキテクチャ

ハードウェア構成

名称 役割 備考
Raspberry Pi 5(8GiB) アプリケーション実行基盤 メモリ使用量0.4 GiB
10.1インチHDMIモニター ずんだもんの表示 解像度1280×800
DHT22 温湿度センサー GPIO接続
YL-69 + ADS1115 土壌湿度センサー ADS1115でアナログ→デジタル変換(要はんだ付け)
GY-30(BH1750) 照度センサー I2C接続(要はんだ付け)
HC-SR501 人感センサー(赤外線) 対話モードのトリガー
USBスピーカー 音声出力 VOICEVOX合成音声の再生
USBマイク 音声入力 Speech-to-Text

Google Cloudサービス構成

サービス 用途 レイテンシ
Cloud Speech-to-Text ユーザー音声の文字起こし ユーザが話し終えてから(無音状態が)1.0秒
Gemini 2.5 Flash 対話応答・植物状態の言語化 0.4秒〜0.9秒
Compute Engine(T4 GPU + VOICEVOX Engine) ずんだもん音声の合成 RTF: 0.1(例えば、3秒の音声ならば0.3秒で生成)

ソリューションコスト

現状のソリューションコストを以下のように見積もります。

  • 初期投資: 約4万円(Raspberry Pi、モニター、マイク・スピーカーで3万5千円超。各センサーは500円程度)
  • 月額コスト: 約4万円(24時間31日間と常時稼働を仮定したGPUインスタンス(n1-standard-4)の場合)

PoC(概念実証)として試行錯誤の段階で、GPU常時稼働構成ですが、GPU稼働時間のスポット化、モデルの量子化・エッジ推論により月額数千円レベルまで削減可能であると見込んでいます。

デモ動画(コミカル版)と視聴者様のご意見

本プロジェクトの実演動画をニコニコ動画やYouTubeに投稿しました。
本動画ではベビーリーフを題材としています。ベビーリーフは冬季でも栽培しやすく、収穫は2~3週間程度と比較的早く、トライアンドエラーを行いやすい植物です。

ニコニコ動画
https://www.nicovideo.jp/watch/sm45892270

YouTube
https://youtu.be/KSuKB_3lroY

視聴者様からは以下のようなコメントをいただきました。

「えーーかわいい!!」
「普通に便利かも」
「えー便利」
「野菜もコミュニケーションが取れて満足なのでしょう」

「かわいい」という反応は、ずんだもんというキャラクターを介することで植物への親しみが生まれることを示唆しています。また「便利」という反応は、センサーデータに基づく栽培アドバイスが実用面でも価値を持つことを示しています。

ソリューションの達成度

課題 アプローチ 達成度
植物に接する機会の減少 センサー+AIによる表情と声で、世話をするきっかけを作る ◎ 表情と声を通じて毎日の関わりが発生する。
家庭菜園のハードルが高い センサーデータに基づく論理的なアドバイス ○ 水やりタイミングや環境の過不足を音声で通知
植物は見ていても面白くない ずんだもんによる表情と音声対話による即時報酬・フィードバックを与える。 ◎ キャラクターの表情変化・音声で感情移入を促進

動画中の以下のパートの例でいいますと、水が足りないずんだもんが苦しそうな顔をしています。そこで水を与えたけれども足りなかったので、もっと水を与えました。結果、ずんだもんが元気になっています。

https://youtu.be/KSuKB_3lroY?t=112

ソリューションの応用性

このアプローチは植物に限らず、センサーを持つあらゆる動物やモノに対して応用可能です。

学校で金魚やメダカを育てる場合を例として挙げますと、センサーによって①水温、②塩素濃度、③(溶存)酸素量、④pH(酸性・アルカリ性)を検知することで、「水が冷たい・・・」といった表現が可能となり、コミュニケーションが生まれます。

他にも以下のようなアプローチも面白いと思います。

  • ペットの見守り: 活動量・室温・餌の残量 → 「お腹すいたワン!」
  • スマートホーム: 電力消費・室温・CO2濃度 → 「窓を開けてほしいのだ!」
  • 工場設備: 振動・温度・稼働時間 → 「そろそろメンテナンスしてほしいのだ……」

センサーデータという数値を、キャラクターの感情や言葉に変換するアプローチは、子どもだけでなく、専門知識を持たないあらゆる人にとってIoTデバイスとの新しいコミュニケーションの形になり得ます。


3. 実装のポイント

ポイント①: センサーデータを、植物が持つ感覚として組み込む。

目標: 子どもに「この植物は生きているんだ」と心で感じてもらう。

「私たちの自然を大切にしましょう!」と説教しても、都会に住んでいる子どもの心には全く響かないと思っています。 教科書で学ぶことと、目の前の植物が「生きている」「美しい」と心や肌で感じることには、埋められない差があると思っています。

本プロジェクトが目指したのは、後者の体験です。植物が感じる喉の渇き、日差しの心地よさ、寒さを、子どもが直感的にわかる形で伝えます。ずんだもんが「お水が飲みたいのだ・・・。」と言えば、子どもは「この子、喉が渇いているんだ。水をあげなきゃ。」と感じます。目の前のキャラクターが困っていて、自分が水をあげれば喜んでくれる。そういった繰り返しの中で、この子も生きているんだという感覚が「自然」と育まれていきます。

アプローチ: マルチモーダルの切り口として、センサーデータを追加する。

このビジョンを技術的に実現するために、マルチモーダルの概念を拡張しました。

従来のマルチモーダルAIは、テキスト・音声・画像・動画といった「人が知覚するメディア」を複合的に扱うアプローチが一般的です。本プロジェクトでは、センサーデータという「植物の身体感覚」を新たに加えました。

従来のマルチモーダル:
  入力値: テキスト、音声、画像、動画
  出力値: テキスト / 音声

本プロジェクトのマルチモーダル:
  入力値: 土壌湿度💧、照度☀️、温湿度🌡️ 、音声
  出力値: 音声 + 表情(キャラクター)

植物に転生したずんだもんにとって、土壌湿度は「喉の渇き」、照度は「日差しの心地よさ」、温湿度は「暑さ・寒さ」です。Geminiへのプロンプトには、ユーザーの発話だけでなく、その瞬間のセンサー値と植物の健康スコアが含まれます。AIは「言葉」と「身体感覚」の両方を踏まえて、感情を伴った応答を生成します。

この仕組みにより、センサーの数値変化が「ずんだもんの気持ちの変化」としてリアルタイムに表出されます。水をあげれば喜び、日当たりが悪ければ元気がなくなる。子どもは数値を読む必要がありません。キャラクターの声と表情だけで、植物の状態を直感的に理解できます。

具体的な実装例

センサーデータの更新箇所を一部(土壌湿度)抜粋したものを以下に示します。

メインクラス(システムアーキテクチャ図における、メインループ)
class ZundamonGarden:
    async def _update_sensors(self):
        logger.info("Updating sensors...")
    
        # NOTE: 2025/12/27 センサーおよび健康データ読取
        self.sensor_data = self.sensor_manager.get_all_data()
    
        # 感情判定(画面表示用)
        self.current_emotion = self.emotion_manager.determine_emotion(
            self.sensor_data
        )
        
    async def run(self):
        logger.info("Main loop started")
    
        try:
            while self.is_running:
                current_time_MILI = pygame.time.get_ticks()
                should_update = (
                    current_time_MILI - self.last_sensor_updated_time_MILI > config.SENSOR_UPDATE_INTERVAL * 1000
                )
                if should_update:
                    await self._update_sensors()
マネージャクラス(システムアーキテクチャ図における、センサー制御)
class SensorManager:
    def _get_real_sensor_data(self):
            """
            実際のセンサーからデータを読み取る
    
            Returns:
                dict: センサーデータ
    
            Raises:
                RuntimeError: センサー読み取りに失敗した場合
            """
        # YL-69から土壌湿度を取得
        if self.moisture_sensor:
            try:
                moisture = self.moisture_sensor.read_moisture()
                data[SensorKey.MOISTURE] = moisture
                logger.debug("YL-69 土壌湿度=%.1f%%なのだ!", moisture)
            except Exception as e:
                logger.warning("YL-69 read failed: %s", e)
                # 前回のデータがあればそれを使う
                if self.last_data:
                    data[SensorKey.MOISTURE] = self.last_data.moisture
                else:
                    data[SensorKey.MOISTURE] = self.base_moisture
各センサークラス(システムアーキテクチャ図における、土壌湿度センサーを例に。)
class YL69Sensor:
    def __init__(self, channel=0, i2c_address=0x48):
        self.channel = channel

        # I2Cバスの初期化
        i2c = busio.I2C(board.SCL, board.SDA)

        # ADS1115の初期化
        self.ads = ADS1115(i2c, address=i2c_address)

        # チャンネルの設定
        channels = [Pin.A0, Pin.A1, Pin.A2, Pin.A3]
        self.chan = AnalogIn(self.ads, channels[channel])

    def read_moisture(self):
        """
        土壌水分を読み取る

        Returns:
            float: 土壌湿度パーセンテージ (0-100)
                - 0%: 完全に乾燥
                - 100%: 完全に湿潤

        Note:
            センサーの特性上、実際の値は環境によって異なる。
            キャリブレーションが必要な場合がある。
        """
        raw_value = self.chan.value

        # ADS1115の最大値は約26400(16bit)
        # 値を反転(低い値=湿っている、高い値=乾いている)
        # パーセンテージに変換(0%=完全に乾燥、100%=完全に湿潤)
        max_value = 26400
        percentage = 100 - (raw_value / max_value * 100)

        # 負の値にならないように制限
        percentage = max(0, min(100, percentage))

        return round(percentage, 1)

ポイント②: TTS(Text-to-Speech)のレイテンシ低下とコストカット

目標: 音声合成のレイテンシとしてRTF:0.2以内に抑え、自然な対話テンポを実現する。

本システムでは、ずんだもんの声を再現するためにVOICEVOX Engineを採用しています。Google Cloud TTSなど他のTTSサービスでは、ずんだもん固有の声質を再現できません。子どもとの対話を想定しており、応答の待たされ感がUXを大きく左右します。

以上のことから、VOICEVOX Engineを用いたリアルタイム応答について、キャッシュに依存せずにRTF:0.2以内に音声合成を実施することを目標としました。

なお、RTFという単位とは音声合成速度の1つであり、RTF(Real-Time Factor)= TTS処理時間 / 音声の長さより計算されます。リアルタイムの対話システムの場合、RTFは0.2以下であることが望ましいです。

アプローチ: Compute Engine T4 GPU(東京リージョン)でVOICEVOX Engineのコンテナを運用する。

当初、Raspberry Pi上でVOICEVOXをDockerコンテナとして実行しましたが、CPU推論では1回の音声合成でRTF: 1を遥かに超えてしまいました。音声長にもよりますが約5秒以上を要し、対話のテンポを著しく損なっていました。また、Cloud Run(CPU対応)も用いましたが、それでもテンポに課題がありました。

VOICEVOX EngineのTTSレイテンシ低下にあたり、GPUインスタンスの導入が最も効果があると判断しました。なお、開発期間の制約からモデルの量子化のアプローチは実施しておりません。

GPUインスタンスの選択肢として、Cloud Run(GPU対応)とCompute Engineの両方を検討しました。検討の結果、Compute Engineを採用しました。

Cloud Runを採用しなかった理由:

  1. リージョン制約によるレイテンシ増加: Cloud RunのGPU対応リージョンにasia-northeast1(東京)が含まれていません(2026年2月11日時点)。最寄りはasia-southeast1(シンガポール)となり、ネットワークの往復で50〜100ミリ秒の遅延が追加されます。音声合成で50〜100ミリ秒の遅延は許容できないと判断しました。

  2. コスト効率: Cloud RunのL4 GPUは$0.67/時間に対し、Compute EngineのT4 Spotは$0.11/時間と約6倍のコスト差があります。VOICEVOX EngineはT4の16GiB VRAMで十分動作するため、L4の24GiB VRAMはオーバースペックであると判断しました。

観点 Cloud Run(GPU) Compute Engine(T4 GPU)
利用可能リージョン us-central1, europe-west1, asia-southeast1など(東京未対応 asia-northeast1(東京)対応
ネットワーク遅延 シンガポール経由で +50〜100ミリ秒 最小(同一リージョン)
GPU種別 NVIDIA L4(24GiB VRAM) NVIDIA T4(16GiB VRAM)
コールドスタート 約5秒(GPU付きコンテナ起動) Spot再起動時: 約60秒
スケーリング 自動スケール、ゼロスケール可能 手動(スクリプトで起動・停止)
コスト(GPU) L4: 約$0.67/時間 T4 Spot: 約$0.11/時間
最小構成 4 CPU, 16 GiB RAM(L4使用時) 柔軟に選択可能

以上のことから、VOICEVOX EngineをCompute Engine(T4 GPU)にデプロイし、GPU推論による高速化を図りました。結果を以下に示します。

構成 合成レイテンシ メモリ消費 コスト目安
Raspberry Pi上Docker(CPU) 5〜10秒 +0.5GiB~ 無料
Compute Engine T4 GPU(東京・採用) 0.1秒~0.3秒(RTF: 0.1) 0GiB(ローカル不要) 〜$0.11/時間(Spot)
Cloud Run L4 GPU(シンガポール) 0.1秒~0.3秒+ 50〜100ミリ秒 0GiB 〜$0.67/時間
  • T4 GPUによりCPU比10倍の高速化を実現
  • 東京リージョンでの低レイテンシを確保
  • Raspberry Piのメモリ消費を削減
  • Spot インスタンス利用でコストを抑制(使用時のみ起動・停止が可能)

ポイント③: LLM推論: エッジAI vs クラウドAPI

目標

子どもの言葉に対して、1秒以内に自然な日本語で応答を生成する。

アプローチ

Raspberry Pi上でローカルLLM(軽いGemma 2B)を動作させることを検討しました。オフラインでも動作する利点がありますので、検証しました。結果、テンプレートに対してセンサー値をプレイスホルダーで当てはめるような、簡易な推論に対しても4〜10秒を要し、メモリも4〜6GiB消費しました。また、生成されるテキストも不自然であることから、リアルタイム対話には不向きでした。

Gemini 2.5 Flash APIに切り替えたところ、応答時間は0.4〜0.9秒に短縮され、ずんだもん口調の日本語生成品質も大幅に向上しました。

成果

構成 応答時間 日本語品質 メモリ
ローカルLLM(Gemma 2B) 4〜10秒 不自然な表現が多い +4〜6GiB
Gemini 2.5 Flash(採用) 0.4〜0.9秒 自然なずんだもん口調 API呼び出しのみ

ポイント④: 対話の合計レイテンシ

上記の最適化の結果、対話全体のレイテンシは以下のように改善されました。

フェーズ 最適化前 最適化後
音声認識(Speech-to-Text) 1秒 1秒
AI応答生成(Gemini) 4〜10秒 0.4〜0.9秒
音声合成(VOICEVOX) 5秒〜10秒 0.1秒~0.3秒
合計 7〜12秒 約2秒

7〜12秒では「待たされている」感覚がありましたが、2~3秒まで短縮されたことで、子どもが飽きずに対話を楽しめるテンポを実現できました。

ポイント⑤: フロントエンドにPythonを採用した理由

目標: センサーデータの取得から表示までを、低レイテンシで実現する

本システムは、センサーデータをリアルタイムに取得し、ずんだもんの表情や音声に反映させる必要があります。このため、センサー読取からUI更新までの遅延を最小化することが重要です。

アプローチ: Pythonによる統合的な実装

フロントエンド(Raspberry Pi上のアプリケーション)にPythonを採用した理由は、以下の3点です。

1. センサーライブラリが充実しているため。

Raspberry Piで使用する各種センサーは、Pythonライブラリが最も充実しています。

センサー Python JavaScript C/C++ Rust
土壌湿度 ○Adafruit_ADS1x15 △ 限定的 要自作 ほぼなし
温湿度 ○Adafruit_DHT △ 限定的 要自作 ほぼなし
照度 ○smbus2 △ 限定的 要自作 ほぼなし
人感 ○RPi.GPIO ○ onoff WiringPi △ rppal

他言語では、多くのセンサーで自前でドライバを実装する必要があり、開発コストが大幅に増加します。

2. クライアント-サーバ分離によるレイテンシの増加を回避するため。

当初、以下のようなアーキテクチャも検討しました。こちらはHTTP通信のオーバーヘッドが発生してUI表示に遅延が生じますし、分離することでデバッグが困難になることから、採用しませんでした。

案1: クライアント-サーバ分離
Node.js(フロント) ←HTTP→ Python(センサーサーバ)

              表示更新

これに対し、Pythonで統合実装することで、分離した分のレイテンシを損なわず、シンプルなアーキテクチャとして実現しました。センサー値が変化してから、ずんだもんの表情が更新されるまでの時間を最小化できます。

採用案: Python統合実装
センサー読取 → データ処理 → 表情更新
(全て同一プロセス内)

3. 開発効率とエコシステム

Pythonは、Raspberry Piの公式推奨言語であり、以下の利点があります。

  • 豊富なドキュメント: Raspberry Pi公式ドキュメントがPython中心
  • 活発なコミュニティ: センサー関連の情報が豊富
  • AI/MLライブラリとの親和性: 将来的なローカルLLM実装にも対応可能
  • UI描画(Pygame): シンプルで高速な描画が可能

4. 今後の展望

本プロジェクトは、PoC(概念実証)として基本機能を実装しましたが、より多くの子どもたちに植物との対話を楽しんでもらうため、以下の展開を計画しています。

展望①: ニコニコ超会議2026への出展とユーザフィードバックの収集

2026年4月開催予定のニコニコ超会議2026に本システムを出展し、実際のユーザ体験を通じたUI/UXの改善を目指します。

現在のシステムは、開発者視点での設計が中心となっています。実際に小学生や大人の方々に触れていただき、以下の点について具体的なフィードバックを収集します。

  • 子どもの反応: どのセリフに笑うか、どの表情に興味を示すか
  • 操作性: 音声認識の精度、表示の見やすさ、反応速度の体感
  • 保護者の評価: 教育効果への期待、自宅での利用意向、価格感

これらのフィードバックをもとに、より子どもに寄り添ったUI/UX設計へとブラッシュアップします。

展望②: データ可視化とGrafanaダッシュボードの実装

保護者や教師が植物の成長を記録・確認できるよう、Grafanaによるダッシュボードを構築します。

センサーデータは現在、ローカルのSQLiteに記録されていますが、これをFirestoreやBigQueryと連携させ、以下の機能を実現します。

  • 成長の可視化: 土壌湿度・温度・照度の時系列グラフ
  • 健康スコアの推移: 植物の状態を0-100点でスコア化し、変化を追跡
  • 水やり記録: いつ、どれだけ水をあげたかの履歴
  • 比較分析: 複数の植物を育てている場合の成長比較
  • 異常検知: 極端な乾燥や低温などをアラート通知

これにより、子どもの「世話をした実感」と、保護者の「成長を見守る楽しさ」の両方をサポートします。

展望③: 植物ごとの専門知識の統合とRAG実装

育てる植物の種類に応じた、より専門的なアドバイスを提供するため、RAG(Retrieval-Augmented Generation)を導入します。

現在のシステムは汎用的な植物の世話を想定していますが、実際にはアサガオ、ヒマワリ、ミニトマト、ヘチマなど、植物ごとに最適な育て方が異なります。

実装アプローチ

  1. 植物データベースの構築

    • Wikipedia、園芸サイト、教育機関の栽培マニュアルから情報を収集
    • 植物ごとの最適温度、水やり頻度、日照時間、成長ステージなどを構造化
  2. RAGによる文脈に応じた応答生成

   ユーザ: 「つぼみができたよ!」

   RAG: アサガオの「つぼみ期」の情報を取得

   ずんだもん: 「つぼみなのだ! あと2〜3日で花が咲くのだ!
                朝の6時ごろに咲くから、早起きして見てほしいのだ!」
  1. 季節・成長段階に応じたプロンプト切り替え
    • 種まき期: 「土をかけすぎないでほしいのだ」
    • 発芽期: 「芽が出てきたのだ! 嬉しいのだ!」
    • 成長期: 「ぐんぐん大きくなるのだ!」
    • 開花期: 「もうすぐ花が咲くのだ!」

これにより、植物ごとの特性を踏まえた、より実践的なアドバイスが可能になります。

展望④: 画像解析による成長記録と対話機能

背景

「子どもが自分で撮った写真について、ずんだもんと一緒に見て、喜びを分かち合う」 体験を目指しています。
Raspberry Pi Camera Module 3の解像度は十分ですが、カメラの定点撮影による画角の制限や、照明条件の変動により、詳細な診断は困難でした。
Raspberry Pi搭載カメラの画質制限を克服するため、ユーザがスマートフォンでアップロードした高画質写真を解析し、対話に活用します。

実装アプローチ

  1. スマートフォンからの写真アップロード

    • Webインターフェース経由で写真を受信。
    • Firestore Storageに保存し、画像URLをRaspberry Piに通知

  2. Gemini 2.5の画像解析

   ユーザ: 「成長したね。」(写真アップロード)

   Gemini: 画像解析
   - 葉の色: 緑色
   - 葉の形: 健全

   ずんだもん: 「見たのだ! 元気に成長できて嬉しいのだ!」
  1. 病害虫の早期検知
    • 葉の斑点、虫食い、カビなどを画像認識
    • 早期段階での対処方法をアドバイス

5. おわりに

本プロジェクトは、アサガオの宿題に対する「楽しくない。けど宿題だから。」という一言から始まりました。

スマートフォンの縦長動画を見ながら、義務的に水をあげていた小学1年生の姿。植物が「生きている」ことを実感できず、ただタスクをこなす時間。そんな光景を変えたいという想いが、このシステムの出発点でした。

目指すのは、単なる便利なIoTシステムではありません。植物栽培を「義務的な観察」から「対話的な体験」へ転換する試みです。IoTと生成AIを組み合わせることで、自然との関わり方を再設計し、教育・家庭・趣味領域に新しいインタラクションを提案します。

子どもたちが「この子、喉が渇いているんだ。水をあげなきゃ。」と自然に感じ、「大きくなったね!」と一緒に喜び、「今日も元気かな?」と気にかけるようになる。そんな、植物との心の通った関わりを生み出すことです。

文部科学省が掲げる「自然や動植物のもつ不思議さ、生命の力、そして、共に生きていることのいとおしさ」を言葉ではなく、体験を通じて伝える。

本システムが、小学生や保護者、先生にとって、より良い植物教育のきっかけとなり、植物にも優しい心を持った人へと成長する一助となることを願っています。

ニコニコ超会議2026での出展を皮切りに、実際のユーザの声に耳を傾け、今後もブラッシュアップを続けてまいります。将来的には学校教育での導入やSTEAM教育教材としての活用の夢も見ています。

いつか、「アサガオの世話、楽しい!」と笑顔で答える子どもたちの姿を見られる日が来たら幸いです。

脚注
  1. Yun-Ah Oh et al, "Horticultural therapy program for improving emotional well-being of elementary school students: an observational study", Integrative Medicine Research
    Volume 9, Issue 1, Pages 37-41, 2020.
    ↩︎

  2. Yuhan Shao et al, "Horticultural Activity: Its Contribution to Stress Recovery and Wellbeing for Children", IJERPH, Volume 17, Issue 4, 2020. ↩︎

Discussion