---
title: "AWS IoT TwinMakerとは？料金モード3種と東京リージョン実額・採用判断"
url: "https://www.issoh.co.jp/tech/details/4537/"
published: 2024-12-17
updated: 2026-08-24
categories: ["AWS"]
publisher: "株式会社一創"
---

# AWS IoT TwinMakerとは？料金モード3種と東京リージョン実額・採用判断

AWS IoT TwinMakerは、工場やビル、産業プラントの設備・センサー・カメラ映像を1つの3D空間に重ねて監視する、AWSのデジタルツイン構築サービスです。公式ドキュメントはデジタルツインを「システムとその物理的・デジタル的な構成要素すべての、生きたデジタル表現」と定義し、データで動的に更新して実物の構造・状態・挙動を模倣するものだとしています。データを1か所へ集約せず既存の保管場所に置いたまま参照する点が、3Dビューアとの違いです。

導入検討で最初につまずくのは、機能の多さではなく料金モードです。AWS IoT TwinMakerには basic・standard・tiered bundle の3モードがあり、**basicモードではナレッジグラフも動的シーンも使えません**。この制約を知らずにPoCを始めると、設計の途中でモード変更が必要になり、しかも変更には請求サイクルをまたぐ縛りが付いてきます。本記事ではAWS公式ドキュメントとAWS Price List APIから取得した一次情報をもとに、構成要素・料金モードと機能の対応・東京リージョンの実額・クォータから導く採用判断までを整理します。

## まとめ

- AWS IoT TwinMakerはワークスペースを最上位コンテナとし、エンティティにコンポーネントを付けて設備をモデル化します。時系列データ本体は保持せず、参照だけを持ちます。
- 料金モードは basic・standard・tiered bundle の3種で、既定は standard です。ナレッジグラフと動的シーンは standard 以上でしか使えません。
- 東京リージョンの単価は、統合データアクセスAPIが100万コールあたり1.65USD、エンティティが1個あたり月0.0525USD、クエリ実行が1万件あたり0.525USDです（AWS Price List API version 20231018161701）。
- 従量制から定額バンドルへの切替は次の請求サイクルから有効になり、戻す場合は3利用サイクル待つ必要があります。basicからstandardへの変更だけは即時反映です。
- モデル・シーンAPIは10 TPS、データ読み書きAPIは100 TPSで、この2つは全リージョン共通かつ調整不可です。高頻度のポーリング設計は成立しません。
- 東京リージョン（ap-northeast-1）は対応済みですが、大阪リージョンには対応していません。国内2リージョン構成の可用性設計は組めません。

## AWS IoT TwinMakerの構成要素とデータの持ち方

### ワークスペース・エンティティ・コンポーネントの3階層

AWS IoT TwinMakerの最上位コンテナはワークスペースです。各ワークスペースはワークスペースデータの保存先となるAmazon S3バケットに紐づき、同時にIAMロールによるアクセス制御の境界も兼ねます。コンポーネントタイプ・エンティティ・シーン・リソースは、いずれか1つのワークスペース内にのみ存在します。

ワークスペースの中で設備や工程を表すのがエンティティです。エンティティ自体はデータを持たず、付与されたコンポーネントがデータと文脈を供給します。コンポーネントのライフタイムはエンティティに紐づくため、エンティティを削除するとコンポーネントも消えます。コンソールから追加できる組み込みコンポーネントは、ドキュメント（マニュアルや画像のURL）、時系列（AWS IoT SiteWiseのセンサーデータ）、アラーム（外部データソースの時系列アラーム）、動画（Kinesis Video Streamsに接続したIPカメラ）、カスタムコンポーネントの5種類です。

コンポーネントが持つプロパティは、エンティティのメタデータとともに直接保存される単一値の非時系列プロパティ、時系列ストアへの参照だけを保存する時系列プロパティ、別のエンティティへの参照を保持するリレーションシッププロパティの3種類です。公式ドキュメントはカメラと被写体を結ぶ `seen_by` を後者の例に挙げています。

### データを移さずに参照する統合データアクセス

AWS IoT TwinMakerの課金単位に「統合データアクセスAPIコール」が出てくるのは、このサービスがデータを集約しないからです。ナレッジグラフとコネクタが組み合わさることで、別々の場所にあるデータへ単一のインターフェースからクエリを投げられます。AWS IoT SiteWiseとKinesis Video Streams向けには組み込みコネクタがあり、それ以外の保管場所にはカスタムコネクタを作ります。

コンポーネントはデータソースとの接続方法を記述したJSONドキュメントで定義され、外部データソースへのアクセスはそこで指定したLambda関数を経由します。時系列データベースを差し替えても、エンティティ側のモデルは変えずにLambdaの実装だけを付け替えられる構造です。保存先に[Amazon Timestream for InfluxDB](/tech/details/15453/)のようなマネージドな時系列データベースを選んだ場合も、TwinMakerは参照を持つだけで実データを二重に抱え込みません。なおAmazon Timestream for LiveAnalyticsは2025年6月20日に新規顧客の受付を終了しており、これから選ぶならInfluxDB版が対象になります。

## 料金モード3種と機能制限の対応関係

### 東京リージョンの実額と米国比の単価差

次の表はAWS Price List API（IoTTwinMaker, version 20231018161701）から取得した、東京リージョンと米国東部（バージニア北部）の単価です。

| 課金対象                  | 東京 ap-northeast-1 | バージニア北部 us-east-1 |
| --------------------- | ----------------- | ----------------- |
| 統合データアクセスAPI（100万コール） | 1.65 USD          | 1.50 USD          |
| エンティティ（1個・1か月）        | 0.0525 USD        | 0.05 USD          |
| クエリ実行（1万件）            | 0.525 USD         | 0.50 USD          |
| Tier 1 バンドル（月額）       | 231 USD           | 220 USD           |
| Tier 2 バンドル（月額）       | 682.50 USD        | 650 USD           |
| Tier 3 バンドル（月額）       | 1,155 USD         | 1,100 USD         |
| Tier 4 バンドル（月額）       | 2,047.50 USD      | 1,950 USD         |

東京の割増率は一律ではありません。統合データアクセスAPIだけが米国比プラス10%で、エンティティ・クエリ・バンドルはいずれもプラス5%です。API呼び出しが支配的なワークロードほど、リージョン差が効いてきます。

basicで課金されるのは統合データアクセスAPIコールだけで、standardはこれにエンティティ数の月額とクエリ実行数が加わります。tiered bundleはエンティティ数で段階が決まり、Tier 1が1〜1,000、Tier 2が1,001〜5,000、Tier 3が5,001〜10,000、Tier 4が10,001〜20,000エンティティです。各バンドルにはAPIコールとクエリの枠が含まれ、東京のTier 1なら2,500万APIコールと380万クエリまでが月額231USDに収まります。

無料利用枠は、最初の12か月間、月あたり最大5,000万データアクセスAPIコールです。PoC規模なら統合データアクセスの費用はここに収まる可能性が高く、実質の負担はエンティティ数の月額になります。単価は改定されるため、見積り前に公式の料金ページで最新値を確認してください。

### basicで使えない機能と切替の3つの制約

料金モードは価格だけの問題ではありません。ナレッジグラフを使うには standard または tiered bundle モードである必要があり、公式ドキュメントにNoteとして明記されています。制限の対象はコンソールのクエリエディタだけでなくナレッジグラフ全体で、CLIの `execute-query` も同じ扱いです。動的シーンも同様で、basicでは静的シーンしか選べません。basicは3Dモデルを置いてS3上のシーンJSONを手で編集する使い方に限定されるため、設備台帳をグラフで問い合わせたい、シーンをクエリ結果から動的に描画したいという要件があるなら最初からstandard以上を選ぶべきです。

モード変更の制約は3つです。従量制から定額バンドルへはいつでも切替できますが、有効になるのは次の請求サイクルの開始時点です。いったん定額バンドルへ移ると、その後3利用サイクルは従量制へ戻せません。basicからstandardへの変更だけは即時反映されます。現在のモードはCLIでも確認・変更できます。

```
aws iottwinmaker get-pricing-plan --region ap-northeast-1

aws iottwinmaker update-pricing-plan \
  --pricing-mode STANDARD \
  --region ap-northeast-1
```

`--pricing-mode` に指定できる値は `BASIC`、`STANDARD`、`TIERED_BUNDLE` の3つです。`TIERED_BUNDLE` を選ぶ場合は `--bundle-names` でバンドル名を渡します。

## デジタルツインを立ち上げる最小手順

### ワークスペースとエンティティの作成

最小構成は、S3バケットと実行ロールを紐づけたワークスペースを作り、その中にエンティティを1つ置くところから始まります。`create-workspace` で必須なのは `--workspace-id` だけですが、リソースの保存先とロールを省くと後から設定し直すことになるため、最初から指定します。エンティティとコンポーネントをどの単位で切るか、時系列をどこに置くかという設計そのものは、[デジタルツインの設計｜収集層・データモデル・同期頻度の決め方を実装目線で解説](https://www.issoh.co.jp/tech/details/16872/)で扱っています。

```
aws iottwinmaker create-workspace \
  --workspace-id CookieFactory \
  --s3-location arn:aws:s3:::twinmaker-cookiefactory-123456789012 \
  --role arn:aws:iam::123456789012:role/TwinMakerWorkspaceRole \
  --region ap-northeast-1

aws iottwinmaker create-entity \
  --workspace-id CookieFactory \
  --entity-id Mixer_0 \
  --entity-name CookieMixer \
  --description "ライン1のミキサー" \
  --region ap-northeast-1
```

ワークスペースIDのパターンは `[a-zA-Z_0-9][a-zA-Z_\-0-9]*[a-zA-Z0-9]+` で、最大128文字です。ハイフン始まりや記号終わりは弾かれるので、設備コードをそのまま流用する場合は事前に整形しておきます。`create-entity` で必須なのは `--entity-name` のほうで、`--entity-id` は任意です。省略するとUUIDが自動採番されるため、設備コードで引きたいなら明示してください。

### ナレッジグラフを問い合わせるPartiQLクエリ

エンティティ同士の関係は、ナレッジグラフに対するクエリで辿ります。構文にはPartiQLが採用されており、リレーションシップをグラフパターンで書けます。公式ドキュメントに載っている例は、名前が `vav_` で始まるエンティティを探し、それらを `feed` リレーションシップで整理するものです。

```
SELECT ahu, vav, r FROM EntityGraph
MATCH (vav)<-[r:feed]-(ahu)
WHERE vav.entityName LIKE 'vav_%'
```

同じクエリはコンソールのクエリエディタからも、CLIの `execute-query` からも実行できます。`--query-statement` の上限は1,000文字、`--max-results` の既定値は50で最大100です。結果が多い場合は `--next-token` でページングします。

## 3Dシーンの可視化とGrafana連携

### 静的シーンと動的シーンの違いと選択基準

静的シーンは、すべてのシーンノードと設定を1つのJSONファイルとしてS3に保存するため、変更のたびにJSONを編集して保存し直します。動的シーンではグローバル設定だけがJSONに残り、個々のノードと設定はナレッジグラフ上のエンティティコンポーネントになります。読み取り専用のScene ViewerをGrafanaやカスタムアプリで使っている場合、動的シーンなら30秒間隔で更新が反映されます。

動的シーンのエンティティは `$SCENES` というグローバルエンティティの配下に格納され、シーンノードの階層とエンティティの親子関係が一致します。ノードの種類ごとに `com.amazon.iottwinmaker.3d.component.tag`（タグウィジェット）など9種類のコンポーネントタイプが用意されています。

選択基準ははっきりしています。複数人が見るダッシュボードとして運用し、シーンの更新を自動で反映させたいなら動的シーンです。シーン定義をJSONファイルとしてGitで版管理したいなら静的シーンが向きます。既存の静的シーンはコンソールのSettingsタブから変換できますが、**この変換は取り消せません**。またシーンエンティティを手動で削除するとシーンが壊れるため、削除はシーンコンポーザーとシーン一覧の画面から行います。

### 100MB超モデルの3D Tiles変換とトレードオフ

公式ドキュメントは、ファイルサイズが100MBを超える、数百から数千の個別メッシュで構成されている、メッシュジオメトリが数百万の三角形を持つ、のいずれかに当てはまるモデルを、読み込みの遅さや操作のもたつきを起こしうるケースとして挙げています。

対処は3D Tiles形式への変換です。3D TilesはCesiumが策定した形式で、カメラ視野に入っている部分だけをチャンク単位で読み込みます。変換ツールとして公式が推奨しているのはCesium Ionです。生成された `tileset.json` と依存ファイル（.gltf、.b3dm、.i3dm、.cmpt、.pnts）をワークスペースのS3バケットの同一ディレクトリへアップロードすると、リソースライブラリに `Tiles3D` タイプとして現れます。リソースライブラリからの直接アップロードには対応していません。

ただし3D Tilesは現時点で幾何・セマンティックメタデータに対応しておらず、元モデルのメッシュ階層をサブモデル選択機能から参照できません。サブモデル単位のモデルシェーダー、個別の3D変換、サブモデルメッシュへのエンティティバインドが使えなくなります。閾値を超えたら機械的に変換する、という判断は誤りです。**背景として置く大きな構造物だけを3D Tilesにし、しきい値で色を変えたい配管や制御盤はBlenderなどで切り出してglTF／glbのまま追加する**、という分割が公式に推奨されているやり方です。

### Grafanaプラグインの要件とCORS設定

ダッシュボードはGrafanaのアプリケーションプラグイン `grafana-iot-twinmaker-app` で構築します。対応バージョンはGrafana 10.4.0以降で、プラグインはカスタムパネル、ダッシュボードテンプレート、データソースを提供し、Scene ViewerパネルとVideo Playerパネルが含まれます。実行環境は[Amazon Managed Grafana](/tech/details/4540/)とセルフマネージドGrafanaのどちらでも構いません。

どちらを選ぶ場合も、GrafanaのUIがS3バケットからリソースを読み込めるようにS3バケットのCORS設定を変更する必要があります。シーンが描画されないときは、まずここを確認してください。

Grafanaを使わず自社のWebアプリケーションへ組み込む道もあります。AWS IoT Application Kit（`iot-app-kit`）が提供するUIコンポーネントを使えば、Scene Viewerなどを独自画面へ埋め込めます。

## SiteWise・Kinesis Video Streams・Matterportとの接続

### SiteWise既定ワークスペースによる自動同期

すでにAWS IoT SiteWiseでデバイスや設備の資産モデルを組んでいる場合、AWS IoT SiteWiseとAWS IoT TwinMakerの統合にオプトインすると `IoTSiteWiseDefaultWorkspace` という名前の既定ワークスペースが作成され、SiteWiseと自動的に同期されます。同じ名前のワークスペースを `CreateWorkspace` APIで作ることもできます。

前提条件は2つです。1つはサービスリンクロール `AWSServiceRoleForIoTTwinMaker` の作成、もう1つは実行するロールまたはユーザーに `iotsitewise:EnableSiteWiseIntegration` の権限があることです。権限が無ければ次のポリシーを追加します。

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iotsitewise:EnableSiteWiseIntegration",
            "Resource": "*"
        }
    ]
}
```

デバイスからのテレメトリ収集そのものはAWS IoT TwinMakerの担当ではありません。MQTTでの接続やデバイス認証は[AWS IoT Core](/tech/details/2991/)とSiteWiseの層で組み、TwinMakerはその出力を参照する立ち位置になります。カメラ映像についてはKinesis Video Streams向けの組み込みコネクタがあり、AWS IoT Greengrassで動くEdge Connector for Kinesis Video Streams経由で動画データを取り込み、GrafanaのVideo Playerパネルで再生できます。

### MatterportはEnterprise契約とPME有効化が前提

Matterportでスキャンした空間（Matterportスペース）をAWS IoT TwinMakerのシーンへ取り込む統合も用意されています。ただし前提条件のハードルは高く、Enterpriseレベルのアカウントと統合に必要な製品の購入に加え、Matterport側にPrivate Model Embed（PME）を有効化してもらう必要があります。公式ドキュメントにも新規の製品購入やサービス費用が発生する可能性があるとNoteが付いています。**すでにMatterport資産を持っている現場でなければ、最初の選択肢にはなりません。**

接続は、MatterportのSDKキーとPMEのClient ID・Client Secretを発行し、AWS Secrets Managerに `application_key`、`client_id`、`client_secret` として保存する流れです。Client Secretは一度しか表示されないため発行時に控えます。シークレットのタグはコンソール上「任意」と表示されますが、サードパーティのシークレットでは必須で、キーに `AWSIoTTwinMaker_Matterport` を指定します。ワークスペースロールには当該シークレットARNへの `secretsmanager:GetSecretValue` を追加します。

## 採用を見送るべき条件

### TPS上限が決める監視設計の限界

高頻度ポーリング前提の監視画面には使えません。モデル・シーンAPIは10 TPS、データ読み書きAPIは100 TPSで、これはAWSアカウント単位の上限であり、全リージョン共通かつ調整不可と明記されています。他のクォータの多くはService Quotasから引き上げ申請できますが、このTPSは動かせません。秒単位で全設備の値を舐めるような設計は成立しないため、しきい値超過をイベントで拾う設計に寄せる必要があります。

### 規模クォータと調整可否

1ワークスペースあたりのエンティティは50,000、シーンは100、1エンティティに付けられるコンポーネントは30、1コンポーネントタイプまたはコンポーネントのプロパティは800、1アカウント1リージョンのワークスペースは15が既定値です。これらは調整可能ですが、タグは1リソースあたり50、コンポーネントタイプの多重継承の親は10で、この2つはTPSと同じく調整できません。

### リージョンとユースケースの制約

対応リージョンは東京、ソウル、シンガポール、シドニー、ムンバイ、バージニア北部、オレゴン、フランクフルト、アイルランドの9商用リージョンとAWS GovCloud（US-West）です。大阪リージョンは含まれないため、国内2リージョンでの冗長構成は組めません。

用途上の制約として、AWS IoT TwinMakerは重大な人身傷害や死亡、環境・財産への損害につながる危険な環境や重要システムの運用での使用を意図していない、と公式ドキュメントに明記されています。安全性の判断を伴う物理システムの人的監視の代替としては使えません。プラント側の異常検知や連動停止は、[SCADA](/tech/details/16159/)やPLCといった制御層に残し、TwinMakerは可視化と横断的な状況把握に限定するのが妥当な役割分担です。

投資判断の材料として、ドキュメントの更新状況も挙げておきます。AWS IoT TwinMakerユーザーガイドのドキュメント履歴は、2021年11月30日の初版と2023年11月17日のサービスリンクロール追加の2件しかありません。サービス自体は現役で提供が続いていますが、AWS IoTファミリでは[AWS IoT Device Defender](/tech/details/5662/)のDetect機能が2026年8月31日以降は新規顧客に提供されなくなる（既存顧客の利用とAudit機能の提供は継続）といった、個別機能の受付終了が告知されています。長期運用を前提にするなら、TwinMakerに寄せる範囲を可視化層に留め、モデル定義とデータ接続の実装は移植できる形で持っておくと安全です。

## よくある質問

### PoCはbasicとstandardのどちらで始めるべきですか？

ナレッジグラフや動的シーンを試す予定があるならstandardです。basicからstandardへの変更は即時反映なので後戻りのコストは小さいものの、basicで組んだ静的シーンを動的シーンへ変換する操作は取り消せません。3Dモデルを置いて表示を確認するだけの段階ならbasicで十分です。

### AWS IoT TwinMakerの料金はどのくらいかかりますか？

従量制なら課金対象は統合データアクセスAPIコール、エンティティ数、クエリ実行数の3つで、東京リージョンの単価は本文の表のとおりです。定額バンドルは1〜1,000エンティティのTier 1で月231USDから始まります。無料利用枠として最初の12か月間、月あたり最大5,000万データアクセスAPIコールが無料です。

### AWS IoT SiteWiseとの違いは何ですか？

AWS IoT SiteWiseは産業機器の時系列データを収集・保存・計算するサービスで、AWS IoT TwinMakerはそのデータを含む複数のソースを3D空間とナレッジグラフの上で横断的に扱うサービスです。役割は競合せず、TwinMakerにはSiteWise向けの組み込みコネクタと資産の自動同期機能があります。すでにSiteWiseで資産モデルを組んでいるなら、`IoTSiteWiseDefaultWorkspace` から始めるのが最短です。

### Grafana以外の画面にデジタルツインを組み込めますか？

組み込めます。AWS IoT Application Kit（`iot-app-kit`）が提供するUIコンポーネントを使えば、Scene Viewerなどを自社のWebアプリケーションへ埋め込めます。Matterportスペースを取り込んだシーンも同じ方法で表示できます。既存の業務画面に3Dビューを足したい場合はこちらを選びます。

### 3Dモデルはどの形式で用意すればよいですか？

Web表示向けに最適化した .gltf または .glb です。重いモデルはCesium Ionで3D Tiles形式へ変換するとレンダリング性能が改善しますが、サブモデル単位のモデルシェーダーやエンティティバインドが使えなくなるため、色を変えたい部品だけはglTFのまま分離して追加してください。

## 関連記事

- [Amazon Managed Grafanaとは？機能・料金・データソースと始め方](/tech/details/4540/)
- [AWS IoT Coreとは？機能・料金・MQTT接続方法をまとめて解説](/tech/details/2991/)
- [Amazon Timestreamとは？仕組み・2つのエンジンと料金モデル・採用判断を実装者目線で解説](/tech/details/15453/)
- [SCADAとは？スキャダの仕組みとPLC・DCS・MESとの役割分担を実装目線で解説](/tech/details/16159/)
- [OTとは？ITとの違い・Purdueモデル・OTセキュリティ実装まで解説](/tech/details/15278/)

---

出典: [AWS IoT TwinMakerとは？料金モード3種と東京リージョン実額・採用判断](<https://www.issoh.co.jp/tech/details/4537/>)（株式会社一創）