AWS IoT＋Amazon Bedrockの構築事例｜スマート菜園システムで検証した設計・実装のポイント

AWS IoTとは、IoTデバイスとAWSクラウドを安全に接続・管理するためのサービス群の総称です。デバイスの接続・認証から、データの収集・処理・分析、セキュリティ管理まで、IoTシステム構築に必要な機能が一通り揃っています。

AWS IoT Coreは、IoTデバイスとAWSクラウドを安全に双方向で接続するためのマネージドサービスです。MQTTやHTTPSプロトコルを介してデバイスからデータを受信し、AWSの各サービス（Lambda、DynamoDB、S3など）へルーティングするメッセージブローカーとして機能します。

本事例では、LoRaWAN対応のゲートウェイを接続するために「AWS IoT Core for LoRaWAN」を利用しました。LoRaWANゲートウェイをAWS IoT Coreに登録することで、センサーから送られたデータをクラウド側でデコード・処理できます。デバイス証明書による認証やIoTポリシーの設定により、セキュアな通信経路を確保できる点も重要なポイントです。

AWS IoT Device Managementは、大量のIoTデバイスを安全かつ効率的に管理するためのサービスです。デバイスの登録・整理・監視に加え、リモート操作やソフトウェアの更新（OTA：Over-the-Air）を一元的に実施できます。

具体的には、現地に訪問することなくデバイスの状態確認や設定変更が可能となり、運用コストの削減と管理負荷の軽減を実現します。

AWS IoT Device Defenderは、IoTデバイスおよびシステム全体のセキュリティを強化するためのサービスです。デバイスの設定や通信動作を監視・監査し、不正な挙動やセキュリティポリシー違反を検出できます。

機械学習を活用して通常時の振る舞いを学習し、異常検知を行うことで、サイバー攻撃や不正アクセスを早期発見できる点が強みです。

AWS IoT Greengrassは、クラウドの機能をエッジデバイス側に拡張するサービスです。この機能により、デバイスはクラウドに接続されていない状態でもローカルでデータ処理や分析、機械学習の推論を実行できます。

特にリアルタイム性が求められる処理や通信遅延を抑えたい場合に有効であり、ネットワーク負荷の軽減にも貢献します。

本事例は、プランター菜園の水やり・追肥タイミングをAIが自動判断するシステムのPoC（小規模検証）です。背景や課題の詳細については前章「AI×IoTの活用事例｜スマート菜園システムPoCから学ぶ設計・構想プロセス」をご参照ください。

システムの連携イメージは「センサーで土の状態を数値化→LoRaWAN経由でAWSへ送信→生成AIが水やり要否を判断→モバイルアプリとSlackへ通知」という流れです。人が介在することなく、センサーとAIが連携して最適な水やりタイミングを判断します。

本システムは大きく「自宅側（デバイス）」と「AWSクラウド側」「モバイルアプリ」の3層で構成されています。

自宅側（デバイス）
土壌センサー（SenseCAP S2105）がLoRaWAN経由でデータを送信し、LoRaWANゲートウェイ（SenseCAP SX1302）がAWS IoT Coreへデータを転送します。

AWSクラウド側

モバイルアプリ
React Native（Expo）で開発したクロスプラットフォームアプリをAndroid・iOSで動作確認しました。

以下が1か月のAWS費用です。サーバレス構成にしたことでほぼ無料に近い状態でシステムを稼働させることができました。
※前提：1日1回アプリ操作、AI相談。週に1回写真送信程度

センサーからクラウドまでのデータの流れは次の通りです。

1）土壌センサー（SenseCAP S2105）がLoRa無線で土壌水分・温度データを送信
2）LoRaWANゲートウェイ（SenseCAP SX1302）がそのデータを受け取り、AWS IoT Core for LoRaWANへ転送
3）AWS IoT Core側では、受信したデータをIoTルールに従ってLambdaへ転送
4）Lambdaがデコード処理を行った上でDynamoDBへ保存する

LoRaWAN機器から送られるデータはPayloadDataと呼ばれるバイナリ形式のため、そのままでは可読性がなく、Lambda上でデコード処理が必要です。Seeed社（SenseCAPの製造元）から公式のデコーダーサンプルコード（JavaScript）が公開されているため、それをベースにClaudeを活用してAWS Lambda用のデコーダーを実装しました。分かりにくいマニュアルの仕様解析にもAIを活用し、効率的に実装を進めることができました。

なお、LoRaWANデバイスの設定（デバイスEUI・AppKey等の登録やAWS IoT Coreへのゲートウェイ登録）は手順が複雑で、今回のPoC全体を通じて最も時間を要した箇所の一つです。IoT機器固有のネットワーク・認証知識が必要な点は留意が必要です。

センサーデータ・作業記録・天気情報をAIへ渡して判断させる処理は、AWS LambdaとAmazon Bedrockの組み合わせで実装しました。構成は以下のとおりです。

1）LambdaがDynamoDBからセンサーデータ（土壌水分・温度）と作業記録（前回の水やり日時・生育段階）を取得
2）センサーデータをプロンプトに組み込んでBedrockへリクエストを送る
3）Bedrockからの応答（水やり要否・アドバイス文）をそのままSlack通知やアプリ表示に利用する

また、作物の写真診断は別フローで実装しています。モバイルアプリからS3への写真アップロードにはAPI Gateway経由で署名付きURLを発行し、アプリがS3へ直接アップロードする設計としています。アップロードされた写真のURLをLambdaがBedrockへ渡し、画像診断結果を返す流れです。

AIへのプロンプト設計では、「経験と勘で判断する農家の代役として振る舞う」というコンテキストを設定しました。センサー数値・天気・作業履歴をまとめてインプットとして与えることで、複数の条件を総合した判断を実現しています。

モバイルアプリはReact Native（Expoフレームワーク）で開発しました。

クロスプラットフォーム開発でFlutterも検討しましたが、iOSビルドにMacが必須な点やGoogle独自言語のDartが採用障壁になるため、TypeScriptで開発できReact経験が活きるReact Nativeを選択しました。ExpoはMacなしでAndroid実機・ブラウザで動作確認できる点が決め手です。

一点注意が必要なのが、ExpoとReact Nativeの互換性問題です。React Nativeの一部モジュール（特にAmazon Cognitoを使ったamplify認証）はExpo Goで動作しないことが判明し、Android実機エミュレータでの動作確認に切り替える必要がありました。

iOS実機への対応にはApple Developerの手続きが必要なため、今回はiOSシミュレーターでの確認に留めています。

出社前（AM 7:00）と帰宅前（PM 18:00）の1日2回、センサー情報と作業記録をもとにAIがレポートを生成して通知するバッチ処理を実装しました。構成は以下のとおりです。

1）Amazon EventBridgeでスケジュールを設定
2）トリガーされたLambdaがDynamoDBからセンサーデータを取得してBedrockへ送信
3）Bedrockが生成したレポート文をAmazon SNS経由でAWS Chatbotへ転送
4）Slackチャンネルへプッシュ通知

当初はモバイルアプリへの直接プッシュ通知を想定していましたが、App Store・Google Playへの公開やFCM（Firebase Cloud Messaging）の設定が検証目的には過剰であったため、Slackへの通知に切り替えました。実用化の際はアプリへのプッシュ通知対応が次のステップになります。

今回の構築を通じて、AWS IoTを活用する技術的なメリットとして次の点が挙げられます。

フルマネージドで運用負荷が低い
メッセージブローカーの管理・スケーリング・可用性確保をAWSが担うため、エンジニアはビジネスロジックの実装に集中できます。接続デバイス数が増えても追加の基盤構築なしに対応できます。

他のAWSサービスとの高い親和性
IoT CoreでデータをDynamoDB・S3・Lambdaへ直接ルーティングできるため、既存のAWS構成への組み込みがスムーズです。今回のようにBedrockと組み合わせることで、センサーデータをAIで活用するシステムも容易に構築できます。

実際に構築してみて、技術的な制約やコスト面での課題も見えてきました。

IoT機器固有のトラブルシューティングコスト
LoRaWANデバイスの設定（デバイス登録・認証情報の設定・Join手順など）は、AWSのドキュメントだけでは解決しにくいケースが多くありました。機器メーカー固有の仕様（PayloadDataのデコード形式など）への対応も必要で、IoTネットワーク・認証の知識がないと想定以上に時間がかかります。

今回のPoC全体の作業時間のうち、IoT機器の設定におけるトラブルシューティングが大半を占めました。

デバイスのコスト
今回使用したSenseCAP S2105（土壌センサー）とLoRaWANゲートウェイは、一般的なWi-Fiセンサーと比べて高価です。大規模展開を想定した際のデバイスコストは事前に試算が必要です。

今回のPoC全体を通じて、AI活用の観点から感じたことを一章も含めてまとめます。

システムの中でAIが活動できる箇所を設計することが重要
センサーが集めたデータをAIに渡して判断させる——このフローの設計こそが、AI×IoTシステムの核心です。「どのデータを取得し、どこでAIに何を判断させるか」を業務の観点で整理することが、システム設計の出発点になります。人が介在することなく、システムとAIが自律的に動作する設計を目指すことが理想です。

野良AI→システム内AIへのシフトが重要
個人がバラバラに使う「野良AI」は属人性が高く成果のばらつきが生じるため、システム内AIへのシフトが重要です。AIをシステムに組み込み、業務プロセスの中で一貫した精度で自動的に活動させるという観点で導入を検討することが良いと考えます。

本記事で紹介したAWS IoTを活用したシステム構築、および生成AI（Amazon Bedrock）との連携設計は、株式会社第一コンピュータリソース（DCR）が支援しています。AWS環境の設計・構築から、既存業務システムへのAI組み込みまで、お客様の課題に合わせてご提案します。

AI活用に関するご相談やAWS構築支援の詳細については、下記よりお気軽にお問い合わせください。

本記事では、スマート菜園システム構築PoCを通じて、AWS IoTを使ったシステム構築の全体像を解説しました。

AWS IoT Core for LoRaWANによるデバイス接続から、Lambda・DynamoDB・Bedrockを組み合わせたデータ処理とAI連携、React Nativeによるモバイルアプリ開発まで、小規模であれば数日で動作するシステムを構築できることを確認しました。

IoT×AIシステムの設計で重要なのは、「どのデータを取得し、どこでAIに判断させるか」を業務の観点から設計することです。AWS IoTは他のAWSサービスとの親和性が高く、フルマネージドで運用負荷も低いため、PoC段階から本番環境まで一貫して活用できるプラットフォームだと感じました。

AWS IoT活用やAmazon Bedrockとの連携に関心がある方は、ぜひDCRまでご相談ください。