Dataverseを初めて開いたとき、テーブル一覧に見覚えのないテーブルが30〜40個並んでいて戸惑う方は多いと思います。これらは「標準テーブル（Standard Tables）」と呼ばれるシステムテーブルで、Dataverseが最初から用意しているものです。自分で作ったわけでも、誰かが追加したわけでもありません。
私も最初に見たとき、「Account」「Contact」「Activity」といった見慣れない英語のテーブルが大量に並んでいて、何が何だかわかりませんでした。誤って標準テーブルに列を追加しようとしたこともあります。この記事では、標準テーブルとは何か、どれが触っていいもので、どれを避けるべきかを整理します。
標準テーブルとは何か
Dataverseの環境を作成すると、最初から大量のテーブルが存在しています。これが標準テーブルです。SharePointでサイトを作ったとき、「サイトページ」「ドキュメント」「カレンダー」などが最初から存在しているのと似た感覚ですが、Dataverseの場合はその数がはるかに多く、またシステムとしての役割も複雑です。
標準テーブルは主に、Microsoft Dynamics 365やModel-driven appsが使うために用意されています。これらのアプリが顧客情報・連絡先・活動履歴などを管理するためのデータ構造として、あらかじめ定義されているのが標準テーブルです。
代表的な標準テーブルとその用途は以下の通りです。
| テーブル名（英語） | 表示名 | 主な用途 |
|---|---|---|
| Account | 取引先企業 | 顧客・取引先の企業情報を管理するためのテーブル |
| Contact | 取引先担当者 | 個人の連絡先情報を管理するテーブル |
| User | ユーザー | Dataverse環境にアクセスするユーザーの情報 |
| Activity | 活動 | メール・電話・タスクなどの活動履歴の親テーブル |
| Team | チーム | ユーザーをグループ化して権限管理するテーブル |
| Business Unit | 部署 | 組織の部門・部署構造を表すテーブル |
| Role | セキュリティロール | アクセス権限の役割定義テーブル |
Canvas appを独自に作るだけが目的であれば、これらの標準テーブルはほとんど使いません。Dynamics 365との連携や、Model-driven appsの構築を前提とした場合に意識する必要が出てきます。
カスタムテーブルとの見分け方
テーブル一覧でカスタムテーブル（自分で作ったテーブル）だけを表示したい場合は、一覧上部のフィルターで「カスタム」を選択すると絞り込めます。普段の作業はこのビューを使えば、標準テーブルに混乱させられることなく作業できます。
フィルターを使わずに見分ける場合は、以下の3点を確認するのが目安になります。
- スキーマ名のプレフィックス：カスタムテーブルのスキーマ名には「cr52a_」「abc_」のようなパブリッシャープレフィックスが付きます。標準テーブルにはプレフィックスがなく、「account」「contact」のようにシンプルな名前です
- Managed（マネージド）の表示：テーブルの詳細を開いて「Managed solution」と表示されているものは、Microsoftが管理しているシステムテーブルです
- テーブルプロパティの制限：標準テーブルの一部は、削除や特定のプロパティ変更が制限されています。カスタムテーブルは自由に変更できます
Dataverseの環境の概念や、環境によって標準テーブルのセットがどう変わるかについては、Dataverseの「環境」とは何かで詳しく解説しています。合わせて確認してみてください。
標準テーブルは触っていいのか
結論からいうと、「基本的には自分でカスタムテーブルを作れば十分」です。ただし「触ってはいけない」という意味ではありません。標準テーブルは用途に応じて3種類に分けて考えると整理しやすいです。
積極的に活用できる標準テーブル
「Account（取引先企業）」と「Contact（取引先担当者）」は、カスタマイズが許可されており、列を追加することもできます。顧客管理や案件管理をDataverseで行う場合は、これらの標準テーブルをベースにカスタマイズするのが推奨アプローチです。
特にDynamics 365との連携を前提にする場合は、AccountやContactに独自列を追加してデータを管理するのが一般的です。一から作ったカスタムテーブルでは連携がうまくいかないケースもあるため、将来的にDynamics 365の導入が視野にある場合は標準テーブルの活用を検討する価値があります。
参照には使えるが変更は慎重に
「User（ユーザー）」「Team（チーム）」「Business Unit（部署）」などは、Power Appsで「ログインユーザーの情報を引き出す」「担当者を選択肢に表示する」といった用途でよく参照します。ただし構造を変更すると、既存のアプリやフロー、セキュリティ設定に影響が出る可能性があるため、列の追加などは慎重に行いましょう。
触らなくていいシステムテーブル
Managedと表示されているテーブルや、名前から明らかにシステム内部で使われているとわかるテーブル（例：「Suggestion」「Audit」「Role」など）は基本的に変更しないほうが安全です。誤って構造を変えると、Dataverse内部の処理やModel-driven appsの動作に影響する可能性があります。
SharePointに例えるなら、サイトページライブラリやワークフロー履歴リストを直接触らないのと同じ感覚です。業務データは自分のカスタムリスト（カスタムテーブル）で管理するのが基本です。
カスタムテーブルを作成したときに知っておくこと
自分でテーブルを作成すると、スキーマ名にパブリッシャープレフィックス（例：cr52a_）が自動的に付きます。これは環境を作成したときに設定されたプレフィックスで、標準テーブルと自分のテーブルを区別するためのものです。
このプレフィックスは、Power AutomateでDataverseのテーブルを操作するときや、APIでアクセスするときに使います。画面上の「表示名（Display Name）」はプレフィックスなしで見られるため、日常の操作では気にする必要はありませんが、数式やフローを書くときに意識しておくと混乱しません。
たとえば「案件テーブル」という表示名のテーブルのスキーマ名が「cr52a_案件テーブル」になっているという具合です。make.powerapps.comのテーブル設定画面でスキーマ名を確認できます。
カスタムテーブルの作成フローについてはSharePointと違うDataverseのテーブル作成フローで詳しく解説しています。SharePointリストとの設計の違いも含めて確認してみてください。また、テーブルを作成した後はすぐに自動生成アプリで動作確認するのがおすすめです。手順はDataverseのテーブルから30秒でアプリを自動生成する方法をご覧ください。
まとめ
Dataverseを開いて大量のテーブルに驚いたとしても、それらのほとんどは標準テーブルであり、Canvas appを作るだけであれば直接関わる必要はありません。テーブル一覧は「カスタム」フィルターで絞り込んで使うのが日常の操作として正解です。
標準テーブルを知っておくことには、将来の設計上の意味があります。「Account」「Contact」は業務要件によっては積極的に活用できます。また、Dynamics 365との連携を前提にするなら、最初から標準テーブルを使う設計が重要になります。
「触ってはいけないテーブル」を見極める目安は、Managedかどうかとパブリッシャープレフィックスの有無を確認するだけで十分です。これを知っておけば、大量のテーブルに惑わされることなく、自分が必要なカスタムテーブルだけに集中して作業を進めることができます。
Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。環境・テーブル設計・列型まで、SharePoint経験者の視点で整理しています。
