Datadog のマルチテナントとCross Organization Visibility
マルチテナントと聞くと、テナントの分割や、RBAC みたいなアクセス制限を想像する方もいるかもしれません。もちろん、Datadog においてもテナント分割やRBAC の仕組みはありますが、他の製品と比べるとやや特殊な印象を受けます。そもそもが単一プラットフォームで様々なシステムやユーザーを繋げるという設計思想なためか、マルチテナンシーを強化するための組織分割ですら2026年4月現在は利用申請が必要で（とはいえ申請すれば普通に使えます）、後述するCross Organization Visibility の機能がリリースされたのも2025 年と最近なので、設計に注意することがあります。ありがたいことに、Datadog のマルチテナント設計と、Cross Organization Visibility について検証する機会に恵まれたので、せっかくなので共有します。
Datadog の組織
Datadog は契約すると組織（Organization）がユーザーに払い出されます。この組織の中に、ユーザーやAPI キー、ダッシュボードといった機能やリソースが属する形になります。
重要なこととして、組織は原則1 契約につき1 つです。ただし、申請ベースで複数の組織を子組織として払い出すことができます。
It is possible to manage multiple child-organizations from one parent-organization account. This is typically used by managed service providers that have customers which should not have access to each others’ data. The multi-organization account feature is not enabled by default. Contact Datadog support to have it enabled. Managing Multiple-Organization AccountsManage multiple child organizations from a parent account with separate billing, usage tracking, and access control for managed service providers.Datadog Infrastructure and Application Monitoring
さらに重要なこととして、組織間では、たとえ親子の関係であっても、請求に関連する利用状況以外のデータはアクセスができません。つまり、例えば親組織のLog Explorer で、子組織のログを検索することはできません。もちろん、子組織同士でもアクセスできません。つまり、組織ごとに完全に分離された環境が提供される形になり、後述するCross Organization Visibility の機能を使わない場合には、組織分割をする理由は「組織ごとに分離した環境が必要だが請求は一本化したい」というユースケースに限られます。
補足として、孫組織も作れます。組織名の変更は可能ですが、一度組織を作ってしまうと、親子の入れ替えや、組織の統合削除はユーザー側ではできないため、サポートへ連絡して対応してもらう形になります。なので、子組織を作る前には入念に設計する必要があります。
ちなみに、子組織作成を有効化するとUI としてはこんな感じになり、New Organization ボタンが出現します。
Datadog のRBAC
次に、組織を作らないマルチテナントの仕組みについて紹介します。Datadog にはRBAC の仕組みがあり、ユーザーごとにロールを割り当てることで、アクセスできる機能を制限することができます。
例えば、API キーの作成や削除を許可しない、Read Only にしてもろもろの機能の設定変更を許可しない、などです。特にMCP やAPI を使ったエージェントによる操作をする場合は、基本的にはRead Only ロールを割り当てることになると思います（MCP の場合はこれに加えMCP Write Access というMCP 自体のパーミッションがあります）。
ロールによって権限がブロックされると、例えば以下のような感じでページ上にエラーが表示されます。サイドペインのメニュー自体は見えたままです。
ただし、ロールはあくまで機能へのアクセスを制限するものであって、データへのアクセスを制限するものではありません。たとえば、ダッシュボートの閲覧制限はできますが、ダッシュボードの中の特定のシステムに対して閲覧制限はかけられません。このような機能の中でのアクセス制御の方法として2 つあり、1. 機能単位でのアクセス制御 2. DAC （Data Access Control）があります。1 に関しては、ダッシュボード/モニター/ノートブック/ワークフローなどがあり、それぞれの機能ごとにアクセス制御ができます。例えば、ダッシュボードに閲覧制限をすると、対象のユーザーには以下のような感じで鍵付きで表示されます。
ただし、これもダッシュボードの存在自体は見えることに注意してください。
なお、朗報ですが、1週間前に検証したときはダッシュボードの閲覧制限自体も申請が必要だったのですが（ドキュメントにもそう書いています）、4/12 現在は申請なしで利用できるようになっています。以前までは組織全体としてViewer （閲覧のみ）+ 個別に編集権限を渡すしかできなかったのですが、No Access という閲覧禁止の設定が申請なしでできるようになっています。
Learning Center のsandbox 環境も有効化されていることを確認したので、おそらく段階リリースの最中です。個人的にはとてもうれしいアップデートです。一応、後で確認できるように現時点でのドキュメントのスクショも添えておきます。
DAC に関しては、データごとにアクセスを制限する、より高度なアクセス制御の仕組みです。これについては後述します。
最後に、Team の仕組みも触れておきます。ユーザーをグルーピングする機能ですが、注意点としてロールはユーザーに割り当てるのであって、Team には割り当てません（2026年4月時点では）。ほかのSaaS だと大体ユーザー直接ではなくグループを作ってからグループに対してロールを割り当てると思いますが、Datadog ではユーザーに直接ロールを割り当てる形になります（個人的にはいまだにここはしっくり来ていません）。
Team を作ると、先ほどのダッシュボード閲覧制限などの設定の時にTeam 単位で制御できたりするので、管理自体は楽になります。ただ、今時点ではロールとは関係がない点に注意してください。
Datadog のDAC（Data Access Control）
DAC は、組織の中でアクセスできるデータを制限するための仕組みです。ロールとは異なり、機能へのアクセスを制限するわけではありません。
特定のチームやロールに対して、タグと属性ベースでフィルタリングをかけたデータにのみアクセス可能にします。例えば、service:a のタグのついたログにしかアクセスさせないといった感じです。DAC を適用したユーザーは、根っこのクエリの部分でブロックされるようで、例えば、service:a のタグがついたログのみアクセス可能にした場合、それをベースにしたログベースのダッシュボードにもアクセスできなくなります。
このDAC の機能にも注意点があります。リリースしてからまだ日が浅いこともあり、ドキュメント記載の通り結構制限があります。例えばDAC が適用できるテレメトリが限られていたり、テレメトリごとに1 つのフィルターしか設定できません。このような制限から、DAC だけでマルチテナントを実現することは難しく、ロールベースのアクセス制御と組み合わせて使っていきます。
Datadog のCross Organization Visibility
最後に、Cross Organization Visibility について紹介します。これは、複数の組織のデータを横断的に可視化するための機能です。例えば、親組織が複数の子組織を持っている場合に、親組織のダッシュボードで子組織のデータをまとめて見ることができるようになります。
Datadog において厳密なマルチテナント設計をするとなると、後述のように組織を切らざるを得ないのですが、そのときにCross Organization Visibility は「最低限の」運用性を確保するための機能になります。最低限、と強調したのは、Cross Organization Visibility ではダッシュボードとノートブックの2 つにおいて、メトリクスやログなどを組織間で横断的に見ることができます。APM やRUM といったドキュメントに記載のないものは2026年4月現在対応しておらず、Log Explorer などの機能を使った組織間のログの横断検索も対応していません。また、子組織で作ったダッシュボードを親組織から見ることができるわけではなく、共有したテレメトリベースで専用でダッシュボード（やノートブック）を作る必要があります。
Cross Organization Visibility の設定は、共有したい組織（関連のある組織に限る）を共有先として選択し、共有するデータを選択します。
なお、子から親だけではなく親から子にデータを共有することもできますし、子同士でも可能です。親と孫でも可能です。あまり複雑な共有設定にすると管理できなくなるので、実際には一方向に共有したほうがいいです。
また、Cross Organization Visibility で共有されたデータをダッシュボードで可視化する際には、Logs (Cross Org) といったように、ウィジェットの中のクエリの部分でCross Organization 専用のクエリを選択し、さらに組織名を指定します。この組織名ですが、ワイルドカードやテンプレート変数は使えません。「ウィジェットには組織ごとに1 クエリ」という制限が地味に重要で、実は可視化の際に若干の制限が出てきます。
例えば、ダッシュボードを1 つ作成し、テンプレート変数で組織名を切り替えることはできません。つまり、子会社A とB の直近のログを親会社X がダッシュボードでリストウィジェットで見る場合、1 つのクエリしか含められないので、1ウィジェットには子会社A のログしか表示できず、A とB の2つの組織で特定のエラーログのみ表示、みたいなことができません。この場合はウィジェットを分けるか、ダッシュボードを分けるか、カスタムメトリクスにして1つのウィジェットにテーブルウィジェットなどでまとめるか、といった選択になります。
Datadog で実現できるマルチテナント設計
ここまで、色々なマルチテナントに使える機能を紹介してきましたが、マルチテナントを考える際はマルチテナンシー、つまりどのレベルで組織を分割するかを併せて考える必要があります。要求されるマルチテナンシーに応じて、組織分割のレベルを決める必要があります。ということで、いくつかユースケースごとに設計を考えてみましょう。
複数のテナントにダッシュボードだけを共有したい
この場合は、まず最初にダッシュボードの共有機能で要件を満たせないか検討します。Datdog のアカウントがなくても、URL だけで共有できます。その場合、公開範囲には気を付ける必要があります。よほどのことがない限り、Invitation Only で指定したユーザーのみ共有することをお勧めします。
ただし、共有したダッシュボードにも制限があります。具体的にはリストウィジェットなどの一部のウィジェットが使えず、App Builder で作ったアプリケーションも共有できません。
このような要件がある場合は、Datadog アカウントが必要になります。その場合、ロールによりダッシュボードだけを許可し、さらにダッシュボード自体の権限を設定することで、不要なダッシュボードへのアクセスを制御します。ただし、先述しましたがアクセスを禁止したとしてもそのダッシュボードの存在自体は確認できてしまうことに注意してください。
もし、例えば1つのダッシュボードにservice タグなどのテンプレート変数を使い、ダッシュボード表示を動的に切り替える場合は、DAC を使うとある程度は制御できますが、この場合の挙動は、テンプレート変数の変更自体はできてしまい、変更するとDAC により制限のかかったクエリを叩こうとするウィジェットは空データが表示される、といった流れになります。
また、通常のメトリクスについても、現時点ではDAC の制御の範囲外なので、DAC を1 つのダッシュボードの中のマルチテナントに使うのはなかなか難しいです。なので、ダッシュボードの共有にマルチテナンシーを求められる場合は、1 つのダッシュボードをテナントごとに切り替えるのではなく、テナントごとにダッシュボードを分けることをお勧めします。
ただ、繰り返しですが、ユーザーをDatadog にログインさせる時点で、ダッシュボードの閲覧制限をかけたとしても、他のダッシュボードの存在はバレます。テンプレート変数で1つのダッシュボードを切り替える場合でも、どんなフィルタがあるかは見えてしまいます（ある程度の制御はできますが）。つまり、割といろいろなものが見えるので、ダッシュボードの共有機能が使えず、マルチテナンシーのレベルがさらに必要な場合は、組織分割を検討することになります。
テナントごとに完全に分割された環境が必要
この場合はテナントごとに組織を作成します。Cross Organization Visibility を使わない限り、組織間で利用状況以外のデータは共有されないので、完全に分割された環境が提供されます。ただ、当然運用管理のコストが上がるので、組織作成の必要性があるかどうかは慎重に検討する必要がありますし、数が増える場合はAPI やTerraform を使った構成管理をお勧めします。ちなみに、もし請求すらも別に分けていいのであれば、そもそも契約を分けてしまって完全に別組織として作ることも検討します。
テナントごとに完全に分割された環境が必要だが、親組織で一括で管理したい
テナントごとに組織を作成したうえで、Cross Organization Visibility を使います。ただし、Cross Organization Visibility は、先述の通りダッシュボードまたはノートブックで子組織を横断的に見ることができる機能ですので、それで十分かどうかは要件を確認する必要があります。例えば、APM やRUM といった機能は現時点ではCross Organization Visibility の対象外なので、これらの機能も横断的に見たい場合は、Cross Organization Visibility ではなく、API を使って必要な情報を取得する方が楽です。一応Dual Shipping という複数組織にエージェントからテレメトリを送る方法もありますが、それなりにコストがかかりますし、マルチテナントと言えるのかは微妙なところです。
まとめ
Datadog でマルチテナントを実現する方法は、大きく分けて「組織分割」と「組織内でのロール/機能単位/DAC による制御」があります。どちらを選ぶかは、求められるマルチテナンシーのレベル次第です。
- ダッシュボードを共有したいだけなら、まずはダッシュボード自体の共有機能で要件を満たせないか検討する。Datadog アカウントが不要で一番手軽。
- 次に、ロール + ダッシュボードなどの機能単位のアクセス制御 + DAC を組み合わせる。ただしDAC は対応テレメトリなどに制限がある。
- 上記よりもさらにマルチテナンシーを引き上げたい場合は子組織の作成をするが、親組織で横断的に見たい場合はCross Organization Visibility を利用する。ただしCross Organization Visibility は2026年4月現在はダッシュボードとノートブックベースでの共有となるため、要件次第ではAPI ベースでの取得も検討。
Datadog のマルチテナント関連機能は比較的新しいものが多く、アップデートも多いので、おそらく本記事で記載の制限もすぐに変わってくると思います。最新の情報はドキュメントをご参照くださいませ。