Azure Data Manager for Agriculture

解決する課題

農業の現場では、衛星画像、気象、土壌センサー、トラクターなどの農機、灌漑装置といった多様なソースからデータが生まれますが、それぞれが別のフォーマットとサイロに閉じています。これらを横断して分析や AI に使おうとすると、取り込み・正規化・保存の仕組みを一から作る必要があります。Azure Data Manager for Agriculture は、こうした農業データの集約と標準化をマネージドな業種向け基盤として提供します。

• 衛星・気象・センサー・農機など 異なるソースのデータを1か所に集約 したい
• ソースごとにバラバラな形式を 共通の農業データモデルへ正規化 したい
• アグリテックアプリや AI モデルの開発で データ取り込み基盤を毎回作り直したくない
• 圃場（フィールド）や作付けといった 農業ドメインの概念をそのまま扱える データ基盤がほしい
• 外部のデータプロバイダーや衛星画像サービスと コネクターで接続 して取り込みを自動化したい

主要概念と用語

• パーティ（Party）: データを所有・管理する主体。農家や組織などを表す、データを束ねる最上位の単位
• ファーム / フィールド（圃場）: 農場と、その中で作付けや管理の対象となる区画。ジオメトリ（位置・形状）を持つ
• 季節（Season）/ シーズンフィールド: 作付けのサイクルを表す概念と、特定の季節における圃場の状態
• 作物・作付け（Crop / Crop Product）: 栽培する作物の種類や品種を表すマスター情報
• 衛星画像（Satellite Imagery）: コネクター経由で取得する圃場の画像データ。植生指標などの分析に用いる
• 気象（Weather）: 過去・予報の気象データ。外部プロバイダーから取り込む
• センサー / IoT: 土壌水分や温度などを計測するデバイスのデータ
• コネクター（Connector / Solution）: 外部データプロバイダーやサービスと接続し、データを取り込む仕組み
• 農業データモデル: 上記の概念を共通スキーマで表現する、サービスの中核となるデータ表現

仕様・制限・クォータ

• 業種特化のマネージドサービス: 汎用ストレージや汎用 DB ではなく、農業ドメイン専用のデータモデルと API を備えた基盤として提供される
• API 駆動: 圃場やシーズン、衛星画像、気象などのデータは REST API を通じて登録・取得する。アプリやパイプラインからプログラム的に扱う設計
• コネクターによる取り込み: 衛星画像や気象などは、対応する外部プロバイダーのコネクターを構成して取り込む。利用できるプロバイダーやデータ種別は構成によって異なる
• データ保持とジオメトリ: 圃場はジオメトリ情報を保持し、衛星画像はその範囲に対して取得される
• インスタンス単位のデプロイ: サービスのインスタンスをサブスクリプション内にデプロイして利用する
• 対応プロバイダー、レート制限、取り込み頻度などの具体値は変動しうるため、利用前に公式ドキュメントで確認する

内部の仕組み

Azure Data Manager for Agriculture は、農業ドメインの概念を共通スキーマで表現するデータレイヤーと、外部ソースをつなぐコネクター群、そしてそれらを操作する API から構成されます。利用者はインスタンスをデプロイし、API とコネクターを通じてデータを流し込みます。

• 共通データモデル が中核にあり、パーティ・ファーム・フィールド・季節・作物といった概念を正規化して保持する。ソースごとの差異はこのモデルへ吸収される
• コネクター が衛星画像や気象などの外部プロバイダーと接続し、取得したデータをモデルへマッピングして取り込む
• API レイヤー がデータの登録・検索・取得の入り口になり、アプリや分析パイプライン、AI モデルがここを通じてアクセスする
• 圃場のジオメトリ を基準に、衛星画像や気象などの空間・時系列データが関連付けられ、圃場単位での分析が可能になる

設計パターン / ベストプラクティス

• ドメインモデルに合わせて設計: パーティ・ファーム・フィールド・季節という階層を、自社の業務概念とどう対応づけるかを最初に決める
• 取り込みはコネクター優先: 衛星や気象など対応するソースは、独自実装より用意されたコネクターを使い、運用負荷とマッピングのばらつきを抑える
• 圃場の境界を正確に: 圃場のジオメトリ精度が衛星画像や気象の関連付けの品質を左右するため、境界データの整備を重視する
• AI の前段として活用: 正規化されたデータを特徴量の供給源とし、収量予測や病害検知などのモデル開発を上に積む
• 下流分析への連携: 集約したデータを必要に応じて分析基盤やデータレイクへ連携し、横断分析やレポートに使う

運用・監視

• API 利用状況の把握: アプリやパイプラインからの API 呼び出しの成否やレートを監視し、取り込みの詰まりを早期に検知する
• コネクターの健全性: 衛星画像や気象などの取り込みジョブが期待どおり動いているか、欠損や遅延がないかを定期的に確認する
• Azure Monitor 連携: 診断ログやメトリクスを Log Analytics へ送り、取り込みや API の状況を可視化・アラート化する
• データ品質の点検: 圃場ジオメトリや作付け情報の欠落・重複を運用の中でチェックし、下流の分析品質を保つ

コスト

課金は、デプロイしたインスタンスや取り込み・保存するデータ量、衛星画像など外部プロバイダー由来のデータ取得、関連する Azure リソースの利用に応じて発生します。外部の衛星・気象プロバイダー側に別途の費用が発生する場合もあります。

• 取り込み範囲を絞る: 必要な圃場・期間・データ種別に取得を限定し、不要な衛星画像や高頻度取得を避ける
• 保持方針を設計: 古い季節のデータの保持要否を決め、保存コストを抑える
• 下流連携の重複を避ける: 同じデータを複数基盤へ二重に持たない構成を意識する
• 具体的な単価は変動するため、断定せず公式の料金情報で確認する

セキュリティ

• Microsoft Entra ID による認証: API へのアクセスは Entra ID のトークンで認証し、匿名アクセスを許さない
• RBAC: データの読み取り・書き込み・管理を行える主体を Azure のロールベースアクセス制御で限定する
• データの所有境界: パーティ単位でデータが束ねられるため、誰のデータかを明確に保ったままアクセス範囲を設計できる
• 保管・転送時の暗号化: Azure 標準の暗号化により、保存データと通信を保護する
• 外部コネクターの資格情報管理: 衛星や気象プロバイダーへの接続情報は安全に管理し、直書きを避ける

関連サービス・比較

汎用のデータ取り込み基盤である Azure Data Factory と役割を比べると、本サービスの位置づけが分かりやすくなります。Data Factory は業種を問わない ETL/ELT のオーケストレーターで、Data Manager for Agriculture は農業ドメインのモデルとコネクターをあらかじめ備えた業種特化の基盤です。

ハンズオン / CLI例

Azure Data Manager for Agriculture のインスタンス管理は、専用のリソースプロバイダーを使って Azure CLI から操作します。インスタンス作成後の圃場や衛星画像などの登録は、サービスの REST API を通じて行います。

# 拡張機能とリソースプロバイダーを準備
az extension add --name agrifood
az provider register --namespace Microsoft.AgFoodPlatform

# リソースグループを作成
az group create --name demo-rg --location eastus

# Data Manager for Agriculture のインスタンスを作成
az agfood farmbeats create \
  --resource-group demo-rg \
  --name demo-agri-instance \
  --location eastus

# 作成したインスタンスの一覧を確認
az agfood farmbeats list \
  --resource-group demo-rg \
  --output table