Azure Digital Twins

解決する課題

工場・ビル・都市・エネルギー網のような現実環境は、多数の機器・場所・人が相互に関係し合う複雑なシステムです。個々のセンサー値だけを集めても「どの設備が、どのフロアの、どの系統に属しているか」という関係性は見えません。Azure Digital Twins は、こうした現実環境を モデル（型）とインスタンス（実体）の関係グラフ として表現し、IoT データで継続的に状態を更新できる基盤を提供します。

• 設備やフロアの 階層・関係性 を含めて環境全体を表現したい
• IoT センサーの生データを、意味のある ビジネスエンティティの状態 に結び付けたい
• 環境の現在状態を クエリ で問い合わせ、変化を イベント として下流に流したい
• AWS の IoT TwinMaker のように、空間や設備の デジタル表現 を中心にソリューションを組み立てたい

主要概念と用語

• デジタルツイン: 現実の人・場所・設備・センサーなどに対応する、グラフ上のインスタンス（実体）
• モデル（Model）: ツインの型定義。プロパティ・テレメトリ・コンポーネント・リレーションシップを記述する
• DTDL（Digital Twins Definition Language）: モデルを定義する JSON ベースの言語。継承や再利用ができる
• ツイングラフ（Twin Graph）: ツイン同士を リレーションシップ でつないだ関係グラフ。環境全体を表す
• リレーションシップ: 「含む」「給電する」「接続する」などツイン間の関係。グラフ走査の基盤になる
• プロパティ / テレメトリ: プロパティは状態を保持する値、テレメトリは一過性のイベント的データ
• イベントルート（Event Route）: ツインの変化を Event Hubs / Event Grid / Service Bus へ流す経路
• クエリ言語: ツイングラフを問い合わせる SQL ライクな言語。関係をたどって条件に合うツインを抽出する

仕様・制限・クォータ

• モデルは DTDL で記述し、いったん公開したモデルは原則 不変（変更は新バージョンとして扱うのが基本）
• ツインの状態更新は JSON Patch 形式で行い、プロパティ単位で部分更新できる
• ツインの数・リレーションシップの数・モデル数などには サブスクリプション／インスタンス単位の上限 がある（規模が大きい場合は事前に上限を確認する）
• クエリには結果件数やページングなどの制約があり、巨大グラフでは 絞り込みと分割 が前提となる
• リージョン可用性や具体的な上限値は変動しうるため、設計時に最新の公式ドキュメントで確認すること

内部の仕組み

Azure Digital Twins の中心は モデル → ツイン → リレーションシップ の三層構造です。まず DTDL でモデル（例: フロア、ルーム、温度センサー）を定義して公開し、そのモデルを型とする ツイン（実体）を作成します。ツイン同士を リレーションシップ でつなぐことで、現実環境の階層や接続を表す ツイングラフ ができあがります。

• 外部からのデータ（多くは IoT Hub 経由のテレメトリ）を Azure Functions などで受け、ツインのプロパティを更新する
• ツインのプロパティが変化すると、その変化イベントを イベントルート で下流（Event Hubs / Event Grid / Service Bus）へ配信できる
• 下流の Functions が、別のツイン（例: 親フロアの集計値）を連鎖的に更新することで、グラフ全体の状態を整合させる
• 現在状態は クエリ言語 で問い合わせ、リレーションシップをたどって「特定フロア配下の全センサー」のような抽出ができる

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

• 入力＝ IoT Hub、変換・更新＝ Azure Functions、表現＝ Digital Twins、下流連携＝ Event Hubs / Event Grid という流れを基本形にする
• モデルは 小さく再利用可能な単位 で設計し、共通要素はコンポーネントや継承でまとめる
• リレーションシップは クエリで実際にたどる関係だけ を定義し、グラフを過度に複雑化させない
• プロパティ更新は JSON Patch によるべき等な部分更新にし、テレメトリとプロパティを混同しない
• 大規模環境では 命名規約と ID 設計 を先に固め、後からの一括変更コストを下げる

運用・監視

• Azure Monitor のメトリクスで API 要求数・レイテンシ・スロットリングなどを監視する
• 診断設定で API ログやイベントルートのログ を Log Analytics へ送り、更新失敗や配信遅延を追跡する
• イベントルートの 配信失敗 はデッドレターやリトライ設計とあわせて監視し、ツイン状態の不整合を早期検知する
• モデルの公開・更新は デプロイのライフサイクル に組み込み、変更履歴を管理する

コスト

Azure Digital Twins の課金は主に 操作（API 呼び出し）数・クエリ実行・メッセージ／イベントの処理数 といった使用量ベースで構成されます。常時起動のクラスター料金ではなく、ツインの更新やクエリの頻度がコストを左右します。

• 更新やクエリの 頻度・件数 が増えるほど操作数が増えコストに直結する
• イベントルートで連鎖更新を多用すると、操作数が 掛け算的に増える 点に注意する
• 具体的な単価や無料枠は変動しうるため、コスト見積もりは最新の料金ページと実際のトラフィック見込みで行う

セキュリティ

• 制御は Microsoft Entra ID + RBAC が基本。データプレーン用ロール（Azure Digital Twins Data Owner など）で読み書き権限を最小権限で付与する
• アプリやサービスからの接続は マネージド ID を用い、キーや接続文字列の直書きを避ける
• ネットワークは プライベートエンドポイント で公開アクセスを制限し、転送は TLS で保護する
• 保存データはサービス側で暗号化される

Well-Architected の観点

• オペレーショナルエクセレンス: モデルとツインを コードとして管理（IaC・DTDL のバージョン管理） し、デプロイと監視を自動化する。イベントルートの失敗監視を運用の中心に据える
• 信頼性: イベントルートのリトライ・デッドレターを設計し、ツイン状態の不整合を検知・修復できるようにする
• セキュリティ: Entra ID + RBAC とマネージド ID、プライベートエンドポイントで最小権限と閉域アクセスを徹底する
• コスト最適化: 不要な連鎖更新や高頻度クエリを抑え、操作数ベースの課金を意識した設計にする

試験で問われるポイント

関連サービス・比較

Digital Twins は単体ではなく、デバイス入口の IoT Hub やイベント配信基盤と組み合わせて使います。ここでは AWS の相当サービスである IoT TwinMaker との対応を押さえます。

ハンズオン / CLI例

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

# Azure Digital Twins インスタンスを作成
az dt create \
  --resource-group demo-rg \
  --dt-name demo-adt-0614 \
  --location japaneast

# 自分（実行ユーザー）にデータプレーンのオーナー権限を付与
az dt role-assignment create \
  --dt-name demo-adt-0614 \
  --assignee takashi.matsuda.0627@gmail.com \
  --role "Azure Digital Twins Data Owner"

# DTDL モデルをアップロード（事前に floor.json などを用意）
az dt model create \
  --dt-name demo-adt-0614 \
  --models ./floor.json

# モデルを型とするツイン（実体）を作成
az dt twin create \
  --dt-name demo-adt-0614 \
  --dtmi "dtmi:example:Floor;1" \
  --twin-id floor-01

# ツイングラフをクエリして状態を確認
az dt twin query \
  --dt-name demo-adt-0614 \
  --query-command "SELECT * FROM digitaltwins"