こんにちは、ohyaです。
今回は、Microsoft Dynamics 365（Dataverse）でちょっとした落とし穴にハマった話を共有します。
「列を追加しただけなのに、なんでやり直しになるの？」と思った方、きっと共感してもらえるはずです。

あるある？列追加でスキーマ名が違う問題

ある日、Dataverseのテーブルに新しい列を追加しようとしたときのこと。
いつも通りテーブル画面からポチポチと列を追加していたのですが、ふと気づくと…

あれ？スキーマ名が arcs_ じゃない…？

そう、ソリューションから追加したときと、テーブルから直接追加したときで、スキーマ名が変わってしまっていたんです。

• ソリューションから追加 → arcs_
• テーブルから直接追加 → cr065_

この違い、見た目は些細ですが、運用や保守に大きな影響を与えることになります。

同じ画面なのにスキーマ名が違う！！

スキーマ名って何？なぜ気にするの？

スキーマ名とは、Dataverseで列やテーブルを一意に識別するための「内部名」です。
表示名は後から変えられますが、スキーマ名は一度作ったら変更できません。

スキーマ名を分ける理由は主にこの3つ：

1. ソリューションの出自を明確にする
   → どの列がどの開発元か一目でわかる。
2. メンテナンス性の向上
   → 不要な列の削除や影響調査がしやすくなる。
3. 名前の衝突を防ぐ
   → 複数のソリューションが共存する環境では特に重要。

やり直しの悲劇とその教訓

今回のケースでは、テーブルから直接列を追加してしまったため、スキーマ名が arcs_ ではなく cr065_ に。
その結果、ソリューションの一貫性が崩れ、再作成を余儀なくされました。

列を削除して再作成、関連ビューやフォームの修正、ソリューションの再エクスポート…。
たった一つの列追加が、思わぬ手間を生むことに。

対策：スキーマ名で迷わないために

列の追加は必ず「ソリューション」から行う

→ スキーマ名が自動でソリューションのプレフィックスに。

命名規則をチームで統一する

→ 例：arcs_ は社内開発、ext_ は外部連携用など。

設計段階でスキーマ名を意識する

→ 後から変えられないからこそ、最初が肝心！

まとめ：小さな設計が、大きな安心に

Dynamics 365のカスタマイズは、ちょっとした操作ミスが後々の運用に響くことがあります。
今回のスキーマ名問題もその一つ。「どこから列を追加するか」だけで、未来が変わるんです。

これからD365に触れる方、同じような壁にぶつかった方の参考になれば嬉しいです。

最後まで読んでくださり、ありがとうございました。
次回の投稿もお楽しみに！