クラウドサービス

Azure Data Manager for Agriculture

Azure Data Manager for Agriculture は2025年9月1日に廃止された農業データ基盤。現在は新規導入できないため、旧構成の理解とエクスポート済みデータの移行設計を目的に確認する。

中級運用上の優秀性セキュリティコスト最適化
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. Azure Data Manager for Agriculture は2025年9月1日に廃止済み。
  2. 旧サービスは農業データを共通モデルへ正規化し、APIで提供した。
  3. 新規設計では保有データを汎用のレイク、ETL、APIへ移行する。

解決していた課題

Azure Data Manager for Agriculture は、衛星画像、気象、土壌センサー、農機など形式の異なる農業データを、圃場や作付けを中心とした共通モデルへ集約するプレビューサービスでした。Microsoft はこのサービスを 2025年9月1日に廃止しており、現在は新規システムの構成要素として採用できません。

  • 圃場・季節・作物を同じ識別子で関連付ける
  • 外部プロバイダーのデータをコネクターで取り込む
  • 正規化済みデータをアプリや分析処理へ API で渡す

本記事はサービスの旧構造を理解し、エクスポート済みデータや周辺アプリを別基盤へ移すための資料です。

2025年9月1日に廃止済み

Microsoft は新規開発と機能・セキュリティ更新を停止し、廃止前のデータ抽出を案内しました。公式案内では廃止後30日でサービス内データを削除するとされているため、2026年時点で旧インスタンスからデータを回収できる前提にはできません。

主要概念と用語

  • パーティ: 農家や組織など、データを所有する主体
  • ファーム / フィールド: 農場と圃場区画。位置と形状のジオメトリを持つ
  • 季節 / シーズンフィールド: 作付けサイクルと、特定期間の圃場状態
  • 作物 / 作付け: 作物の種類や品種を表すマスター情報
  • コネクター: 衛星画像や気象などの外部データを取得する旧連携機能
  • 農業データモデル: ソースごとの差異を吸収した旧サービスの共通スキーマ

仕様・制限・クォータ

  • サービスはプレビューのまま廃止され、インスタンスの新規作成や継続利用はできない
  • 廃止前は REST API を中心にデータの登録・検索・取得を行った
  • 旧コネクター、レート制限、対応リージョンは移行先で継承されない
  • 旧リソース ID や API 仕様に依存するアプリは、移行先の契約へ置き換える必要がある

内部の仕組み

横にスクロール

廃止されたAzure Data Manager for Agricultureの旧処理経路と、エクスポート済みデータを新基盤へ移す責任境界
旧サービスは外部データを農業モデルへ正規化して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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

分析operationalsecuritycost