DynamoDBでRDBのように連番のIDを採番したい！ホットパーティションを回避して実装する設計パターン

DynamoDBを採用する際、多くの開発者が一度は直面する課題が「RDBのような連番IDをどう扱うか」という問題です。
特に業務システムや帳票処理などでは、単純なUUIDではなく、人間が読みやすい連番を要求されるケースも少なくありません。
しかし、その実現方法を誤ると、DynamoDBの設計思想に反し、パフォーマンス劣化やスケーラビリティの低下を招く原因になります。

一見すると「カウンタテーブルを用意してインクリメントすれば良い」と考えがちですが、この方法は高頻度アクセス時にホットパーティションを引き起こす典型例です。
DynamoDBはパーティションキーにアクセスが集中するとスループットが偏り、レイテンシの悪化やスロットリングが発生します。
そのため、単純なシーケンス生成は本番環境では危険な設計となり得ます。

本記事では、DynamoDBの特性を踏まえた上で、ホットパーティションを回避しながら連番IDを疑似的に実現する設計パターンについて整理します。
シャーディングを用いた分散カウンタ、事前予約方式、あるいはアプリケーションレイヤでの工夫など、実務で検討される複数のアプローチを比較し、それぞれのトレードオフを明らかにしていきます。

単に「実現できるかどうか」ではなく、「なぜその設計がスケールするのか」を理解することが重要です。DynamoDBの内部動作とアクセスパターンの関係を正しく捉えることで、連番IDという一見単純な要件にも、クラウドネイティブな設計判断が求められることが見えてきます。“`

DynamoDBで連番IDが難しい理由と設計上の課題

DynamoDBで連番IDを実現しようとすると、多くの開発者が最初に直面するのが「RDBと同じ感覚では設計できない」という現実です。
特にオートインクリメントIDのような仕組みは、リレーショナルデータベースでは極めて自然に扱えますが、DynamoDBではそのまま再現しようとするとアーキテクチャ上の制約に抵触します。

ここでは、その本質的な理由を「設計思想の違い」と「連番IDが抱える問題」の2つの観点から整理します。

RDBとDynamoDBの設計思想の違い

RDBは基本的に単一の整合性モデルを前提としています。
トランザクションによって整合性が保証され、テーブル全体に対して一貫した状態を維持することが可能です。
そのため、AUTO_INCREMENTのような仕組みも、内部的にロックやシーケンス管理を用いることで成立しています。

一方でDynamoDBは、分散システムとしてのスケーラビリティを最優先に設計されています。
データはパーティションキーによって分散され、各ノードが独立してスケールする前提です。
このため、全体で一意かつ順序保証されたIDを生成するような仕組みは、設計思想と相性が良くありません。

簡単に比較すると以下のようになります。

観点	RDB	DynamoDB
一貫性	強い整合性	最終的整合性中心
スケーリング	垂直・限定的水平	水平スケーリング前提
ID生成	中央集権的	分散設計が必要

この違いを理解せずに連番IDを持ち込むと、設計全体が歪む原因になります。

なぜ連番IDが問題になるのか

連番IDは一見シンプルですが、分散環境では非常に扱いづらい性質を持っています。
その理由は「単一の状態に依存する」という点にあります。

例えば、単純にカウンタテーブルを用意し、そこに対してインクリメント処理を行う設計を考えるとします。
この場合、全リクエストが同一のアイテムに集中することになり、結果として以下の問題が発生します。

• パーティションキーが単一となり、ホットパーティション化
• 同時更新による競合とリトライ増加
• スループット制限によるレイテンシ悪化

特にDynamoDBではパーティション単位でスループットが管理されるため、1点集中型のアクセスは致命的です。
これはRDBにおけるロック競合とは異なり、スケーラビリティそのものを損なう点が重要です。

さらに、連番という性質上「次の値を知るためには必ず直前の状態が必要」という依存関係が発生します。
これは並列性と相性が悪く、分散環境ではボトルネックになります。

このように、連番IDは単なる実装問題ではなく、分散システムにおける状態管理の難しさを象徴する設計課題と言えます。

RDBのオートインクリメントIDとDynamoDBの違い

RDBにおけるオートインクリメントIDは非常に直感的で扱いやすい仕組みですが、その背後には強い整合性と集中管理されたトランザクション制御が存在しています。
一方でDynamoDBでは、同じような振る舞いを期待すると設計上の前提が崩れます。
この違いを正しく理解することは、分散システムにおけるID設計の第一歩です。

トランザクションと一貫性の違い

RDBではトランザクションが中心的な役割を担っており、BEGINからCOMMITまでの間で一貫した状態を保証できます。
このため、オートインクリメントIDの生成も「排他制御された単一のシーケンス」として成立します。
内部的にはロックやシーケンスオブジェクトが用いられ、同時実行でも重複が発生しないよう制御されます。

これに対してDynamoDBは、分散ストレージとして設計されており、全体での強い一貫性よりもスケーラビリティと可用性を優先しています。
トランザクション機能は存在するものの、それは局所的な整合性を担保するためのものであり、RDBのような全体ロック型の設計とは異なります。

例えばRDBとDynamoDBの違いを整理すると以下のようになります。

観点	RDB	DynamoDB
トランザクション範囲	テーブル全体	アイテム単位中心
一貫性モデル	強い一貫性	最終的整合性が基本
排他制御	ロックベース	楽観的制御中心

この違いにより、RDBで自然に成立していた「順序性の保証」はDynamoDBでは前提として存在しません。

分散環境でのID生成の考え方

分散環境におけるID生成では、「単一の正しい順序」を維持するという発想自体を見直す必要があります。
なぜなら、複数のノードが独立して処理を行うため、全体での厳密な順序付けは性能とトレードオフになるからです。

DynamoDBでは特に以下のような設計思想が重要になります。

• IDはグローバルに一意であればよく、連続性は必須ではない
• 生成処理は複数ノードに分散可能であるべき
• 単一障害点を作らない構造が優先される

このため、UUIDのような分散生成可能なIDや、タイムスタンプ＋乱数を組み合わせた設計がよく採用されます。
重要なのは「後から並び替え可能な情報を持たせるかどうか」であり、必ずしも生成時点での順序保証は必要ありません。

また、分散環境ではID生成そのものがボトルネックにならないように設計することが重要です。
もし中央集権的なカウンタを用いると、それだけでシステム全体のスループットが制限されてしまいます。

結果として、DynamoDBにおけるID設計は「順序性の保証」から「衝突しない分散生成」へと発想を転換することが本質となります。

ホットパーティションが発生する仕組みとリスク

DynamoDBを設計する上で避けて通れない重要な概念がホットパーティションです。
特に連番IDのような集中アクセス型の設計を持ち込んだ場合、この問題は顕著に現れます。
ホットパーティションは単なる性能問題ではなく、システム全体のスケーラビリティを制約する構造的なボトルネックです。

ここでは、その発生メカニズムを「パーティションキーの集中」と「スループット制限」という2つの観点から整理します。

パーティションキーの集中問題

DynamoDBではデータがパーティションキーに基づいて分散配置されます。
この設計により水平スケーリングが可能になる一方で、特定のキーにアクセスが集中すると、そのパーティションだけが極端に負荷を受けるという問題が発生します。

例えば連番IDを生成するために、単一のカウンタアイテムをパーティションキーとして使用した場合を考えます。
この場合、すべての書き込みリクエストが同じキーに集中するため、実質的に以下の状態になります。

• すべてのリクエストが1つのパーティションに集中
• 他のパーティションが空いていても負荷分散されない
• 結果として単一ノード依存の構造になる

この状態はDynamoDBの分散設計思想と完全に逆行しており、スケーラビリティの恩恵を一切受けられない構造になります。

また、アクセス集中は単純な書き込みだけでなく読み取りにも影響します。
特定キーへの読み書きが増えることで、そのパーティションのキャパシティが継続的に消費され、システム全体のレスポンスが不安定になります。

スループット制限とスロットリング

DynamoDBでは各パーティションに対して、一定のスループット制限が設けられています。
この制限を超えるアクセスが発生すると、リクエストはスロットリングされ、エラーまたは遅延としてアプリケーションに返されます。

ホットパーティションが発生した場合、このスロットリングは局所的に集中し、以下のような問題を引き起こします。

• レイテンシの急激な悪化
• リトライによるさらなる負荷増大
• スパイラル的な性能劣化

特に厄介なのは、リトライ処理が逆効果になるケースです。
スロットリングを検知して再試行すると、その瞬間にさらに同じパーティションへ負荷が集中し、状況が悪化することがあります。

この問題を整理すると、以下のような関係が成立します。

要因	影響	結果
パーティション集中	単一ノード負荷増加	ホットパーティション化
スループット超過	リクエスト拒否	スロットリング発生
リトライ増加	負荷再集中	性能劣化加速

このようにホットパーティションは単なる設計ミスではなく、分散システムにおける負荷分散原理の破綻状態とも言えます。
そのため、連番IDのような集中型アクセスパターンを避ける設計が極めて重要になります。

単純なカウンタテーブル設計の問題点

DynamoDBで連番IDを実現しようとする際、最も直感的に思いつくのが「カウンタテーブル」を用意して、そこに対してインクリメント処理を行う設計です。
しかし、この方法は一見シンプルであるにもかかわらず、分散システムの特性を無視した場合に深刻な性能問題を引き起こします。
特に高トラフィック環境では、想定以上に早い段階でボトルネックが顕在化します。

ここではその問題を「インクリメント処理の競合」と「高負荷時のボトルネック」という観点から整理します。

インクリメント処理の競合

カウンタテーブル方式では、単一のアイテムに対してADD操作などを用いて値を増加させます。
この設計は理論上は単純ですが、実際には同一キーへの同時更新が必ず発生するため、競合が避けられません。

DynamoDBはアトミックな更新をサポートしていますが、それは「正しさ」を保証するものであり、「並列性能」を保証するものではありません。
そのため、リクエストが増加すると以下のような現象が発生します。

• 同一アイテムへの書き込み待ちが発生
• リトライによる追加負荷の発生
• レイテンシのばらつき増加

特に問題となるのは、更新が逐次的に処理される点です。
つまり、どれだけスケールアウトしても、カウンタの更新部分だけは本質的に直列処理から逃れられないという構造的制約があります。

この性質は、分散システムの並列性を活かすDynamoDBの設計思想と相反します。

高負荷時のボトルネック

アクセス数が少ない段階ではカウンタテーブル方式は問題なく動作しますが、トラフィックが増加すると状況は一変します。
特定のキーに対する書き込み集中が発生し、システム全体のスループットが頭打ちになります。

このとき発生する主な問題は以下の通りです。

• 単一パーティションへのアクセス集中
• スループット上限によるスロットリング
• リトライループによる負荷増幅

これらが連鎖的に発生することで、負荷が増えるほど性能が悪化するという逆転現象が起こります。
特に注意すべきは、リトライ制御が適切でない場合、負荷が指数的に増加する点です。

また、カウンタテーブルはスケールアウトによる恩恵を受けられないため、以下のような構造的問題を抱えます。

要素	影響	結果
単一キー依存	負荷集中	スケーラビリティ喪失
逐次更新	並列化不可	レイテンシ増加
上限到達	スロットリング	システム不安定化

このように、単純なカウンタ設計は実装コストこそ低いものの、本番環境の負荷特性に対して極めて脆弱な構造を持っています。
そのため、実務ではより分散性を考慮した代替設計が必須となります。

シャーディングを使った分散カウンタ設計パターン

DynamoDBで連番IDを安全に近い形で実現しようとする場合、単一のカウンタに依存する設計から脱却し、シャーディングを用いた分散カウンタ設計が有力な選択肢となります。
このアプローチは、ホットパーティション問題を回避しつつ、ある程度の順序性や一意性を担保するための現実的な妥協点として機能します。

重要なのは、ID生成を「単一の状態管理」から「複数ノードへの分散処理」へと再定義することです。

シャードキーによる分散方法

シャーディングの基本的な考え方は、カウンタを複数の論理的な単位に分割することです。
例えば、カウンタを1つではなく複数のシャードに分け、それぞれが独立してインクリメントを行う設計を採用します。

具体的には以下のような構造になります。

• shard-1: カウンタA
• shard-2: カウンタB
• shard-3: カウンタC

アプリケーション側では、IDを取得する際にランダムまたはハッシュベースでシャードを選択し、分散的にカウントアップを行います。
この方法により、特定のキーへのアクセス集中を回避できます。

この設計のポイントは次の通りです。

• 書き込みを複数パーティションに分散できる
• 単一ホットパーティションを回避できる
• スループットをシャード数に応じて拡張可能

結果として、従来の単一カウンタ設計に比べて、水平スケーリングの恩恵を受けやすい構造になります。

ただし、この時点では各シャードの値は独立しているため、全体としての厳密な連番は保証されません。
この点は後段の設計で補う必要があります。

衝突回避と整合性の設計

シャーディングを導入した場合、新たに問題となるのが「IDの衝突」と「順序性の崩壊」です。
複数のシャードが独立してカウンタを持つため、そのままでは同じ数値が生成される可能性があります。

この問題を解決するために、一般的には以下のような設計が採用されます。

手法	特徴	メリット	デメリット
シャードID + カウンタ	複合ID化	衝突回避可能	可読性低下
時間情報付加	時系列補助	並び替え可能	厳密連番不可
集約バッチ処理	後段統合	一貫性向上	遅延発生

例えば、シャードIDとカウンタ値を組み合わせることで一意性を担保する設計は一般的です。

また、整合性の観点では「リアルタイムでの厳密な順序保証」を諦める代わりに、「後から再構築可能な順序情報」を持たせる設計が現実的です。
これは分散システムにおける重要な設計判断であり、即時整合性よりもスケーラビリティを優先するトレードオフと言えます。

さらに、シャード数の設計も重要です。
少なすぎるとホットパーティションの再発リスクがあり、多すぎると管理コストが増加します。
そのため、想定トラフィックに応じた適切な分割設計が求められます。

このようにシャーディングによる分散カウンタは、単純な連番生成の代替というよりも、分散環境に適応したID生成モデルへの再設計として捉える必要があります。

事前採番・バッチ生成によるスケーラブルなID設計

DynamoDBにおける連番ID問題を解決するアプローチの一つとして、事前採番・バッチ生成方式があります。
この設計は、リアルタイムでのインクリメント処理を避け、あらかじめIDの塊を生成しておくことで、書き込み時のボトルネックを回避するものです。
分散環境においては、処理の「即時性」を犠牲にして「スループットと安定性」を確保する代表的な手法と言えます。

この方式の本質は、ID生成処理をオンライン処理からオフライン処理へと分離する点にあります。

予約済みIDの管理方法

事前採番方式では、一定数のIDをまとめて生成し、それをアプリケーション側で消費していきます。
これにより、リクエストごとにDynamoDBへアクセスする必要がなくなり、負荷を大幅に削減できます。

典型的な構成としては以下のようになります。

• バッチジョブが定期的にIDブロックを生成
• 生成されたIDレンジをストレージに保存
• アプリケーションが必要に応じてIDを取得

このとき重要なのは、IDを単なる数値として扱うのではなく「レンジ単位で管理する」という考え方です。
例えば、以下のような管理方式が一般的です。

管理単位	内容	特徴
レンジ方式	1000単位でIDを予約	管理が容易
プール方式	事前生成IDをキュー管理	消費効率が高い
分散割当	ノードごとに範囲固定	衝突回避が容易

この設計の利点は、リアルタイム更新を伴わないため、DynamoDBのホットパーティション問題を根本的に回避できる点にあります。
一方で、IDの消費状況と生成タイミングを適切に管理しないと、ID枯渇や無駄なバッファリングが発生する可能性があります。

レイテンシ削減のメリット

事前採番方式のもう一つの重要な利点は、書き込みレイテンシの大幅な削減です。
通常のカウンタ方式では、ID生成のたびにDynamoDBへの更新処理が発生し、それがレイテンシの下限を決定してしまいます。

しかし、事前採番方式ではID取得がメモリまたは軽量ストレージから行われるため、以下のような改善が期待できます。

• ネットワーク往復の削減
• DynamoDB依存の排除
• 高トラフィック時の安定したレスポンス

特に高負荷環境では、この違いは顕著に現れます。
ID生成がボトルネックにならないことで、システム全体のスループットはアプリケーションロジックや外部I/Oに近いレベルまで引き上げられます。

ただし、この方式にもトレードオフは存在します。

• IDの連続性は保証されるがリアルタイム性は低下
• バッチ生成失敗時のリカバリ設計が必要
• 複数インスタンス間での同期管理が必要

このように、事前採番・バッチ生成方式は「即時性」を犠牲にする代わりに「スケーラビリティと安定性」を獲得する設計です。
そのため、システム要件に応じて適用可否を慎重に判断する必要があります。

UUIDと連番風IDを組み合わせるアプローチ

DynamoDBにおけるID設計の現実解として、UUIDと連番風IDを併用するハイブリッドアプローチがあります。
この方法は、分散システムにおける一意性の確保と、業務要件として求められる可読性や順序性のバランスを取るための設計です。
単一のIDスキームに依存するのではなく、役割ごとにIDを分離することで、システム全体の柔軟性を高めることができます。

このアプローチの核心は「IDに複数の意味を持たせない」という設計原則にあります。

ユーザー向けIDと内部IDの分離

まず重要なのは、IDを「内部処理用」と「外部公開用」に明確に分離することです。
内部IDにはUUIDを採用し、分散環境でも衝突しない一意性を担保します。
一方で、ユーザー向けには連番風のIDを別途付与することで、可読性や運用性を確保します。

この分離により、以下のようなメリットが得られます。

• 内部処理ではUUIDによる安全な分散生成が可能
• 外部APIでは連番風IDによるユーザビリティ向上
• システム変更時も影響範囲を限定できる

例えば以下のような構造になります。

種別	ID形式	用途
内部ID	UUID	データ整合性・参照キー
外部ID	連番風ID	ユーザー表示・検索キー

このように役割を分離することで、DynamoDBの分散特性と業務要件の両立が可能になります。

また、外部IDを完全な連番にする必要は必ずしもありません。
例えばタイムスタンプやシャード情報を組み合わせることで、「見かけ上の連番性」を持たせることができます。
重要なのは、ユーザー体験としての連続性であり、内部的な厳密順序ではありません。

実務での採用パターン

実務においては、UUIDと連番風IDの併用はさまざまな形で採用されています。
特にマイクロサービス構成やサーバーレス環境では、この設計が標準的な選択肢になることも少なくありません。

代表的なパターンとしては以下のようなものがあります。

• APIレスポンスでは外部IDのみ返却
• データベース内部ではUUIDを主キーとして使用
• 検索やソート用途で連番風IDを補助的に利用

この設計のポイントは、IDの責務を明確に分離することです。
UUIDは一意性と分散性を保証する役割を持ち、連番風IDはUXや業務要件を満たす役割を担います。

さらに、実務では以下のような工夫が行われることもあります。

• 連番風IDにプレフィックスを付与し、ドメインを識別可能にする
• 日付ベースのソートキーと組み合わせて時系列順を担保する
• キャッシュ層で外部IDと内部IDのマッピングを保持する

このように、UUIDと連番風IDの併用は単なる妥協案ではなく、分散システムにおける現実的な設計最適化として機能します。
DynamoDBの制約を前提としつつ、業務要件を満たすためのバランス設計として非常に有効なアプローチです。

設計パターンの比較とユースケース別の選び方

DynamoDBにおける連番ID問題に対しては、単一の正解が存在するわけではなく、複数の設計パターンを要件に応じて使い分けることが重要です。
これまで見てきたように、カウンタ方式、シャーディング方式、事前採番方式、そしてUUID併用方式にはそれぞれ明確なトレードオフが存在します。
そのため、設計判断は「何を優先するか」に強く依存します。

ここでは、それらの違いを整理しながら、実務での選択指針を論理的に整理します。

性能・整合性・複雑性のトレードオフ

各設計パターンは、性能・整合性・実装複雑性のバランスにおいて異なる特性を持っています。
これを俯瞰すると、以下のような構造になります。

パターン	性能	整合性	複雑性
単一カウンタ	低	高	低
シャーディング	中〜高	中	中
事前採番	高	中	高
UUID併用	高	低〜中	中

単一カウンタ方式は整合性こそ高いものの、ホットパーティション問題により性能面で限界があります。
一方、シャーディング方式は性能を改善できますが、順序性や厳密な連番性は犠牲になります。

事前採番方式は高いスループットを実現できますが、バッチ管理やID枯渇対策といった追加の設計が必要になります。
UUID併用方式は最もスケーラブルですが、連番性は基本的に放棄されるため、業務要件との調整が不可欠です。

このように、どの方式も万能ではなく、必ず何らかの制約とのトレードオフが発生する構造になっています。

システム要件別の最適解

実務では、システムの性質に応じて最適なID設計を選択する必要があります。
単純に技術的に優れている方式を選ぶのではなく、要件駆動で判断することが重要です。

典型的なユースケースと推奨設計は以下の通りです。

• 小規模システム・低負荷
• 単一カウンタでも許容可能
• 中規模・スケーラビリティ重視
• シャーディング方式が現実的
• 高トラフィック・ミッションクリティカル
• 事前採番またはUUID併用
• 分散マイクロサービス環境
• UUID + 外部ID分離設計

特に重要なのは、「連番IDが本当に必要か」という再評価です。
多くのケースでは、連番性は本質的な要件ではなく、ユーザー体験や運用上の便宜として求められているに過ぎません。
そのため、内部IDはUUIDで十分であり、外部向けに別の識別子を持たせる設計が合理的な場合も多くあります。

また、将来的なスケールを考慮すると、初期段階から分散前提の設計を採用する方が結果的にコストを抑えられるケースが多いです。
後から単一カウンタ構造を分散化するのは難易度が高く、リファクタリングコストも大きくなります。

このようにID設計は単なる実装詳細ではなく、システム全体のスケーラビリティ戦略を左右する設計判断であると言えます。

まとめ：DynamoDBで安全に連番IDを扱うための設計指針

DynamoDBにおいて連番IDを扱う設計は、一見すると単純な要件に見えますが、実際には分散システムの本質的な制約と強く衝突する領域です。
本記事で整理してきた通り、RDBのようなオートインクリメントをそのまま再現しようとすると、ホットパーティション、スループット制限、競合処理といった問題が連鎖的に発生します。
そのため、設計の出発点として「連番をそのまま実現する」という発想自体を一度分解して考える必要があります。

まず重要なのは、DynamoDBが前提とする設計思想を正しく理解することです。
DynamoDBは単一の整合性モデルではなく、水平スケーリングを前提とした分散データストアです。
このため、特定キーへの集中アクセスや、全体での厳密な順序保証といった要件とは本質的に相性が良くありません。
連番IDはまさにこの「集中性」と「順序性」を強く要求するため、設計上の工夫が不可欠になります。

ここまでで扱ってきた代表的なアプローチを整理すると、以下のような位置づけになります。

• 単一カウンタ方式：シンプルだがホットパーティション問題が顕在化
• シャーディング方式：負荷分散は可能だが厳密な連番性は失われる
• 事前採番方式：高スループットだがバッチ管理の複雑性が増加
• UUID併用方式：スケーラブルだが連番要件は外部設計に分離

これらはいずれも「正解・不正解」という関係ではなく、システム要件に応じた選択肢の集合です。

特に重要なのは、IDに対する要求を分解することです。
多くのシステムでは、連番IDが求められている理由は以下のようなものに分解できます。

• ユーザーが扱いやすい識別子であること
• ソート可能であること
• 業務上の参照性が高いこと

しかしこれらは必ずしも「厳密な連番」である必要はありません。
例えば、タイムスタンプを含んだIDや、シャード付きの疑似連番でも、多くのユースケースは十分に満たされます。
この発想の転換が、DynamoDB設計における重要なポイントです。

また、実務的な観点では次のような指針が有効です。

• 高スループット要件がある場合は単一カウンタ設計を避ける
• 順序性よりも一意性を優先する設計に切り替える
• 外部IDと内部IDを分離し、責務を明確化する
• 将来的なスケールを前提に初期設計を行う

特に最後の点は重要で、初期段階で単純なカウンタ設計を採用すると、後から分散化する際に大きなリファクタリングコストが発生します。
そのため、最初から「分散前提のID設計」を選択することが長期的には合理的です。

さらに、DynamoDBの設計ではID生成をアプリケーションロジックから分離することも有効です。
例えば、ID生成専用のサービスを用意することで、責務を明確化しつつスケーラビリティを確保できます。
このような設計はマイクロサービスアーキテクチャとも親和性が高く、将来的な拡張性にも寄与します。

最終的に重要なのは、「連番IDをどう実現するか」ではなく、「なぜ連番IDが必要なのか」を再定義することです。
その上で、DynamoDBの特性に適合した代替手段を選択することが、最も安定した設計につながります。
分散システムにおけるID設計は単なる実装詳細ではなく、アーキテクチャ全体のスケーラビリティを左右する重要な意思決定領域であると言えます。