DataverseのAuto-number列は、数値に見えてテキスト型です。この一点を知っているかどうかで、Power Automateフローを組むときの詰まり方がまったく変わります。
SharePointリストのID列（1, 2, 3と増える連番）を使い慣れていると、Dataverseにも同じような採番列があると期待するのは自然なことです。Auto-number列がまさにそれだと思って使い始め、フローの条件式で比較しようとしたら型エラー、という経験は、SharePointからDataverseに移行する人なら一度はぶつかります。自分もそうでした。
Auto-number列とはどんな機能か
設定できるフォーマット
Auto-number列は、レコードが新規作成されるたびに自動で値が採番される列です。採番のルールをフォーマット文字列で設定できるのが特徴で、以下の3種類の要素を組み合わせられます。
- SEQNUM(桁数)：連番。例：{SEQNUM:4} なら 0001, 0002…
- DATETIME(フォーマット)：日付。例：{DATETIME:yyyyMMdd} なら 20260322
- RANDSTRING(桁数)：ランダム文字列
これらを自由に組み合わせることができます。たとえば REQ-{DATETIME:yyyyMM}-{SEQNUM:4} と設定すれば、REQ-202603-0001 のような番号が自動生成されます。SharePointの連番IDにはできない、業務要件に合わせた採番が可能なのはたしかに便利です。
ただし型はテキスト型。これが全ての起点
便利なフォーマット設定ができる一方、Auto-number列の型はテキスト（文字列）です。見た目が 0001 や 123 であっても、Dataverseの内部では文字列として保存されています。つまり数値計算も大小比較もできません。
なぜテキスト型なのかというと、REQ-202603-0001 のように日付や固定文字列を含めた複合フォーマットを実現するには、型を文字列にするしかないからです。純粋な数値型では、アルファベットや記号を含める採番ルールを表現できません。機能の柔軟性とのトレードオフとして、型はテキストに固定されています。
SharePointのID列との違い
改めて2つを比較してみます。
| 比較項目 | SharePoint ID列 | Dataverse Auto-number列 |
|---|---|---|
| データ型 | 数値（整数） | テキスト（文字列） |
| 自動採番 | 1, 2, 3…（固定） | フォーマット自由（REQ-0001 など） |
| 数値比較 | できる（gt, lt, eq） | できない（テキスト比較になる） |
| 計算 | できる（+1など） | できない |
| Patchでの書き込み | 不可（自動） | 不可（自動） |
| 採番リセット | できない | できない（連番は減らせない） |
SharePointのIDは純粋な数値型なので、フローの条件式で ID gt 100（100より大きい）のような比較がそのまま動きます。Auto-numberは見た目が同じ数字でも、中身は文字列なのでこれができません。
Power Automateフローで起きるエラーの実例
条件ステップでの型エラー
フローの条件ステップで Auto-number列の値が 100 より大きければ〜という分岐を作ろうとすると、思い通りに動きません。数値の 100 とテキストの 0100 を比較しているため、フローが正しく評価できないのです。エラーにならず無言でfalseを返し続けるケースもあり、原因に気づきにくいことがあります。
個人的に一番やっかいだと感じるのはこのパターンです。エラーメッセージが出ないまま動作がおかしいだけなので、フローのどこに問題があるのか特定しづらいです。
int()で数値に変換してから比較する
純粋な連番形式（0001, 0002…）のAuto-numberであれば、int()関数でテキストを整数に変換してから比較できます。式エディタ（fx）で以下のように書きます。
// Auto-number列の値を整数に変換してから比較する
int(triggerOutputs()?['body/cr52a_managementnumber'])ただしこれが使えるのは、採番値が純粋な数字のみの場合に限ります。REQ-202603-0001 のようなプレフィックス付きフォーマットでは、数字部分だけを substring() や split() で切り出してからint()変換する必要があります。だんだん複雑になってきますね。
値の型を確認するには Composeアクションが便利です。Composeアクションの使い方の記事でも触れていますが、フローの途中でComposeにAuto-number列の値を渡して実行してみると、どんな形式で保存されているかを目で確認できます。
フィルタークエリでの注意
Dataverseの行を取得するアクションで、フィルター行に Auto-number列を使って絞り込もうとするときも注意が必要です。
// 数値として比較しようとするとうまく動かない
cr52a_managementnumber gt 100
// テキストとして一致比較なら動く
cr52a_managementnumber eq '0100'大小比較はテキスト型では期待通りに動作しません。一致比較（eq）であればテキストとしての比較になるので動きます。どうしても大小比較が必要な場合は、数値型の別列を用意してそちらで管理するほうが現実的です。
Patch関数でAuto-number列への書き込みはできません
Power AppsのPatch関数でレコードを新規作成するとき、Auto-number列を指定しようとするとエラーになります。Auto-numberは読み取り専用の自動採番列なので、アプリ側から値を指定できない仕様です。
解決策はシンプルで、Patchのレコード定義からAuto-number列を省略するだけです。
// ❌ Auto-number列に値を入れようとするとエラー
Patch(
案件テーブル,
Defaults(案件テーブル),
{
管理番号: "0001", // ← これがNGの原因
件名: TextInput1.Text,
担当者: Dropdown1.Selected.Value
}
)
// ✅ 省略するだけでOK。採番はDataverseが自動でやってくれる
Patch(
案件テーブル,
Defaults(案件テーブル),
{
件名: TextInput1.Text,
担当者: Dropdown1.Selected.Value
}
)Patchの書き方全般についてはPatch関数の使い方の記事をあわせて参照してください。
どうしても数値として使える連番が欲しい場合
SharePointのIDのように数値として扱える連番が業務上どうしても必要な場合、Auto-numberではなく数値型の列を別途用意するのが現実的です。いくつかの設計パターンを紹介します。
パターン1：Power Automateフローで採番する
レコード作成時にPower Automateをトリガーとして起動し、フロー内で現在の最大値を取得して+1した値を数値型列に書き込む方法です。処理の流れとしては次のようになります。
- Dataverseの行が作成されたときにフローを起動
- テーブル全体の行を取得し、採番列の最大値を取得
- 最大値+1を計算して、対象レコードの採番列に書き込む
同時に複数のレコードが作成される環境では採番の重複が起きるリスクがあります。同時アクセスが少ない業務アプリであれば現実的に問題になることは少ないですが、設計の前提として把握しておく必要があります。
パターン2：表示用と管理用を分けて持つ
Auto-number列はあくまで表示・印刷用の採番として使い、内部の管理キーはGUIDのままにする設計です。フローの条件分岐や検索キーにはGUIDを使い、Auto-numberは帳票に印刷する申請番号としてだけ機能させます。DataverseはGUIDで完結できる設計なので、この割り切りが一番シンプルです。
Power AppsからPower Automateを連携させる基本的な設計についてはPower AppsとPower Automateの連携記事も参考にしてください。
まとめ
- DataverseのAuto-number列は見た目が数字でも型はテキスト（文字列）です
- フロー条件での数値比較には使えません。int()変換が必要で、プレフィックス付きフォーマットではさらに複雑になります
- Patch関数での書き込みは不要で、省略するのが正解です
- 数値として使える連番が必要な場合は、数値型の別列を用意してフローで採番するか、GUIDで割り切る設計を選びましょう
仕様を知った上で使うぶんには、表示用の採番列として十分活躍してくれます。SharePointのIDとは別物だと割り切って、Dataverse本来の設計に慣れていきましょう。
Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。
