Azure Data Manager for Agriculture
Azure Data Manager for Agriculture は2025年9月1日に廃止された農業データ基盤。現在は新規導入できないため、旧構成の理解とエクスポート済みデータの移行設計を目的に確認する。
- Azure Data Manager for Agriculture は2025年9月1日に廃止済み。
- 旧サービスは農業データを共通モデルへ正規化し、APIで提供した。
- 新規設計では保有データを汎用のレイク、ETL、APIへ移行する。
解決していた課題
Azure Data Manager for Agriculture は、衛星画像、気象、土壌センサー、農機など形式の異なる農業データを、圃場や作付けを中心とした共通モデルへ集約するプレビューサービスでした。Microsoft はこのサービスを 2025年9月1日に廃止しており、現在は新規システムの構成要素として採用できません。
- 圃場・季節・作物を同じ識別子で関連付ける
- 外部プロバイダーのデータをコネクターで取り込む
- 正規化済みデータをアプリや分析処理へ API で渡す
本記事はサービスの旧構造を理解し、エクスポート済みデータや周辺アプリを別基盤へ移すための資料です。
Microsoft は新規開発と機能・セキュリティ更新を停止し、廃止前のデータ抽出を案内しました。公式案内では廃止後30日でサービス内データを削除するとされているため、2026年時点で旧インスタンスからデータを回収できる前提にはできません。
主要概念と用語
- パーティ: 農家や組織など、データを所有する主体
- ファーム / フィールド: 農場と圃場区画。位置と形状のジオメトリを持つ
- 季節 / シーズンフィールド: 作付けサイクルと、特定期間の圃場状態
- 作物 / 作付け: 作物の種類や品種を表すマスター情報
- コネクター: 衛星画像や気象などの外部データを取得する旧連携機能
- 農業データモデル: ソースごとの差異を吸収した旧サービスの共通スキーマ
仕様・制限・クォータ
- サービスはプレビューのまま廃止され、インスタンスの新規作成や継続利用はできない
- 廃止前は REST API を中心にデータの登録・検索・取得を行った
- 旧コネクター、レート制限、対応リージョンは移行先で継承されない
- 旧リソース ID や API 仕様に依存するアプリは、移行先の契約へ置き換える必要がある
内部の仕組み
横にスクロール
旧サービスは、外部ソースをつなぐコネクター、農業ドメインの共通モデル、アプリ向け API の三層で動作していました。
- コネクターが衛星・気象・センサーなどを取得し、圃場識別子と時刻を対応付けた
- 共通モデルがパーティ、ファーム、フィールド、季節、作物の関係を保持した
- API が登録・検索・取得を受け付け、分析パイプラインや業務アプリへ渡した
- 現在はこの経路が停止しているため、旧 API を再試行する実装では復旧できない
移行設計 / ベストプラクティス
- 保有データを棚卸しする: 廃止前に出力したファイル、下流レイク、元プロバイダーの原本を確認する
- 契約を先に作る: パーティ、圃場、季節、作付け、観測値の ID と関係を明文化する
- 生データを保持する: 元形式を ADLS Gen2 などへ保存し、再変換できるようにする
- 取り込みを疎結合にする: Data Factory、Functions、Logic Apps などを使い、外部プロバイダーごとの失敗を隔離する
- API を自社境界に置く: Azure API Management とアプリ用 API で、認証・版管理・レート制御を行う
- ジオメトリ品質を検証する: 座標系、境界の自己交差、重複圃場を検査してから時系列データを結合する
運用・監視
- 旧サービスの稼働監視ではなく、移行先の取り込み成功率、遅延、重複、欠損を監視する
- 外部プロバイダーの認証期限と API 変更を個別に追跡する
- データ契約の版を記録し、変換不能なレコードを隔離して再処理する
- 旧エンドポイントへの呼び出しが残っていないか、コード、シークレット、監視設定を検索する
コスト
移行後の費用は、外部データの購入、取り込み実行、保存容量、変換計算、API 配信に分解します。旧サービスの料金モデルをそのまま当てはめず、各構成要素の利用量から見積もります。
- 衛星画像や気象データは取得範囲・頻度を用途に合わせる
- 生データと正規化済みデータの保持期間を分ける
- 増分取り込みと列指向形式で転送量・計算量を抑える
セキュリティ
- 圃場の位置、収量、作業履歴を機微な事業データとして分類する
- マネージド ID と Microsoft Entra ID を使い、共有キーをコードへ埋め込まない
- ADLS Gen2 の RBAC と ACL、プライベートエンドポイントで保存境界を守る
- 外部プロバイダーの資格情報を Key Vault に保管し、期限と利用主体を監査する
- 旧サービス用のアプリ登録、シークレット、ロール割り当ては依存関係を確認して廃止する
関連サービス・比較
単一の直接後継ではなく、必要な責務を複数の Azure サービスへ分割します。
| 責務 | 移行先の例 | 設計上の注意 |
|---|---|---|
| 原本保存 | Azure Data Lake Storage Gen2 | 階層、保持、RBACとACLを設計 |
| 取り込み | Azure Data Factory / Functions | 再試行、重複排除、資格情報を設計 |
| 正規化 | Databricks / Fabric | 農業データ契約を自社で維持 |
| API公開 | API Management + App Service | 認証、版管理、レート制御を実装 |
| 可視化 | Power BI | 圃場・期間単位の権限を適用 |
移行確認例
# 旧リソースを新規作成するコマンドではありません。
# 手元へエクスポート済みのファイルを新しいレイクへ配置します。
az storage fs file upload \
--account-name <storage-account> \
--file-system agriculture \
--path raw/export/fields.json \
--source ./fields.json \
--auth-mode login
# 移行コードに旧リソースプロバイダーへの参照が残っていないか確認します。
rg "Microsoft.AgFoodPlatform|agfood|farmbeats" .
Azure Service
Azure Data Manager for Agricultureを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
分析
比較で見る軸
クラウド: Azure / カテゴリ: 分析 / 難易度: intermediate
導入後に効く点
旧サービスは農業データを共通モデルへ正規化し、APIで提供した。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Azure
- カテゴリ
- 分析
- 難易度
- intermediate
- 関連資格
- —
- 設計柱
- operational / security / cost
判断チェックリスト
- 自社の用途が「分析 / operational」に近いか確認する。
- 強みである「Azure Data Manager for Agriculture は2025年9月1日に廃止済み。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。