「先月と比べて今週の新規登録数はどう動いたか」。この程度の問いに答えるために、データ担当へ依頼を出し、数日待つ。そんな経験が経営層や事業部門にはあるはずです。

Claude Dashboardsは、その待ち時間を削るための機能です。Claudeに知りたいことを伝えると、接続した社内データから数字を引き、グラフ付きのダッシュボードにして返します。2026年10月8日（米国時間）にベータとして公開されました。

ただし、便利さだけで導入を決めると危うい機能でもあります。管理者がどこまで制御でき、どこから先はデータ側の権限設計に頼るしかないのか。公式がまだ書いていない点は何か。2026年10月時点で確認できた情報をもとに、導入判断に必要な材料を順に整理します。

この記事でわかること

  • Claude Dashboardsの正体と、既存のBIツールとの本質的な違い
  • 対象プランと、Enterpriseで管理者が必ず通る設定手順
  • 依頼から数字の検証、共有までの使い方
  • ウェアハウス側の権限とClaude側の管理者設定を一体で設計する考え方
  • 導入判断の枠組みと、公式に書かれていない未確認事項の一覧

Claude Dashboardsは「質問から作る」社内データの画面

Claude Dashboardsは、チャットで質問すると、接続した社内データをもとにダッシュボードを組み立ててくれる機能です。BIツールが「先に画面を設計してからデータを流し込む」のに対し、こちらは「知りたいことを先に言い、画面は後からできる」順序になります。

既存BIツールと何が本質的に違うのか

従来のBIツールでは、人が指標を決め、集計の定義を作り、画面を設計します。完成した画面は誰が見ても同じ数字を示すので、会議の共通言語になります。

Claude Dashboardsでは、チャートごとにClaudeがSQLを書き、接続先のデータソースで実行します。人が最初に作るのは画面の設計図ではなく、質問文です。たとえば次のような依頼で足ります。

今週の新規登録数を先月と比較したい。Snowflakeの会員テーブルを使って、日別の推移と、流入元ごとの内訳を見せてください。

公式は、グラフの種類を指定するより「何を知りたいか」を伝えるよう案内しています。テーブル名やアプリ名が分かっているなら、それも添えると精度が上がります。

BIが「決まった問いに毎回同じ答えを出す装置」なら、Dashboardsは「その場で生まれた問いに答える道具」です。この違いが、後半で扱う使い分けの土台になります。

なぜ今、経営層や事業部門が気にすべきなのか

理由は単純で、データを見るまでの距離が縮むからです。SQLを書けない人が、データ担当を介さずに自分の問いを数字にできます。

この機能は、機能そのものより運用の変化として捉えるべきです。「依頼して待つ」から「その場で聞く」に変わると、会議の中で仮説を試せるようになります。一方で、誰がどのデータに触れて、出てきた数字を誰が検証するのかという統制の問題が、一気に前面に出ます。

導入するかどうかより、導入するなら何を決めておくか。その設計が差になる機能です。

対象プランと提供状況

公式ヘルプでは、DashboardsはPro・Max・Team・Enterpriseのベータとされ、Freeプランは対象外です。Claude Dashboardsの始め方に記載があります。

国内報道では「有償プラン」とだけ書かれている場合があり、媒体によって表記が揺れています。記事や社内資料に書くときは、公式の表記に合わせるのが安全です。

項目内容
提供形態ベータ（仕様が変わる可能性あり）
対象プランPro / Max / Team / Enterprise
対象外Free
Enterpriseの初期状態既定でオフ。Ownerが有効化する
利用量プランの利用上限を消費する

使用量について、Dashboards専用の追加料金は公式ヘルプに見当たりません。ダッシュボードの作成や操作は、通常のチャットと同じくプランの利用上限を使います。Enterpriseで従量課金を使っている場合の扱いは、公式発表では確認できていません。

同時に発表されたMotionとDocs/Slides/Designの位置づけ

同じ日に、動画を作る「Claude Motion」も発表されました。Dashboardsが数字を見せる機能なら、Motionは数字や図を動かして見せる機能です。

Motionは動画生成モデルではなく、コードでテキスト・チャート・図形・画像を動かす仕組みです。生成された映像やAIの人物が出てくるわけではありません。語や数値、タイミングは後から編集でき、MP4で書き出せます。Team / Enterpriseでベータ提供され、Teamは既定オン、Enterpriseは既定オフです。

使いどころは、四半期報告を30秒の社内動画にしたり、役員会スライドのグラフに動きを付けたりする場面です。ダッシュボードで見つけた数字を、そのまま共有用の素材にできます。

Docs / Slides / Designはベータが終わり、Freeを含む全プランに広がりました。Enterpriseは2026年10月15日に既定オンへ切り替わっています。不要なら事前にオフにしておく設定でした。単体の claude.ai/design は2026年12月14日に終了し、会話内に統合されると管理者ガイドにあります。

Enterpriseの管理者にとって、Dashboards・Motion（既定オフ）とDocs/Slides/Design（既定オン）で初期状態が逆だという点が、地味ですが見落としやすいところです。

使い方は依頼、検証、共有の三段階

作成は数分で終わりますが、価値が決まるのは作った後の検証と共有です。ここでは作成の入り口から、数字を会議に出すまでの手順を扱います。

ダッシュボードを作る三つの入り口

作り方は三通りあります。

  1. チャットで直接依頼する
  2. Output メニューから Dashboards を選ぶ
  3. Artifacts タブでテンプレートを選ぶ

最初はチャットでの依頼が一番早いです。接続済みのデータソースが分かっているなら、依頼文の中で指定します。

データソースとして公式に明記されているのは、Amazon Redshift、BigQuery、ClickHouse、Databricks、Snowflakeの5つのデータウェアハウスです。加えて、Claudeに接続済みの他のアプリ（例としてSalesforce）も使えます。

依頼文のコツは、集計の結論だけでなく「何のために見るか」を書くことです。

来月の営業会議で、商談化率が落ちている原因を探りたい。Salesforceの商談データから、担当者別・業種別の商談化率の推移を出してください。

目的が書いてあると、Claudeは比較の軸を自分で補えます。逆に「売上のグラフを作って」だけだと、期間も粒度もClaudeの推測になります。

数字を会議に出す前に必ずクエリを開く

ダッシュボードには、チャートごとに実行されたクエリと最終更新時刻が表示されます。クエリを開けば、どのテーブルのどの列を、どんな条件で集計したかが読めます。計算が意図と違っていれば、チャットで修正を依頼できます。

これが公式の想定する検証手順です。最終更新時刻が示すのはデータの鮮度であって、集計の正しさの保証ではありません。ここは取り違えないでください。

SQLが読める人が一人もいない組織では、この検証が成立しません。導入前に最も確認すべき条件は、これです。クエリを読める担当者が最低一人いるか。いなければ、会議に出す数字の最終確認はデータ担当に残す運用にします。

共有は自分専用から始まる

作成直後のダッシュボードは自分専用です。共有するには Share を使います。Team / Enterpriseでは、閲覧範囲を次の三段階から選べます。

閲覧範囲内容
招待した人のみ指定した人だけが見られる
組織内の全員同じ組織のメンバー全員
リンクを知る全員組織外も含め、リンクがあれば見られる

コネクタを使っているか、Claudeへの質問を伴うArtifactは、「リンクを知る全員」を選べません。社内データを引いたダッシュボードが、URLの流出だけで外に出る事態は設計上起きにくくなっています。

組織外のメールアドレスへの招待は、Artifacts設定で有効化する別項目です。外部共有（External sharing）も別のトグルで、オフにすると既存の公開リンクも止まります。個別に許可したものは例外です。

この三つが独立している点は、あとで管理者設定の設計に効いてきます。

日本語での利用と更新の挙動

日本は対応国に含まれます。ただし、日本語ラベルや長い表がきれいに描画されるかは、公式の記載を確認できていません。実際の業務データで一度試してください。

データ更新についても、報道は「データ更新に合わせて最新状態になる」と伝えていますが、更新頻度、手動の更新ボタン、行数やチャート数の上限は、公式ヘルプに記載がありません。この点は後述の未確認事項に入れています。

Enterpriseでは管理者設定とウェアハウスの権限を一体で設計する

Enterpriseの入口管理は「組織設定」と「カスタムロール」の二段で、データ側の絞り込みはClaudeの管理画面では完結しません。ウェアハウス側の権限設計が、実質的な安全装置になります。

管理者が有効化する手順と二段構えの制御

Enterpriseでは、DashboardsもMotionも初期状態がオフです。有効化は次の順序で進めます。

  1. Organization settings > Capabilities で、コード実行（code execution）とファイル作成（file creation）を有効にする
  2. Organization settings > Artifacts で、Artifactsを有効にする
  3. 必要に応じて、カスタムロールで利用できるグループを限定する

手順の詳細はArtifactsの管理者ガイドにあります。設定を変更できるのはOwner、Primary Owner、または適切な管理権限を持つカスタムロールです。

この順序には意味があります。組織設定が主スイッチで、ロールはその配下の個別制御です。組織設定で機能がオフなら、どのカスタムロールでも付与できません。「営業部だけに先行導入したい」場合、組織設定をオンにしてから、営業部のグループにだけロールで許可する、という二段になります。

Claude側で制御できることと、できないこと

ここが法人導入の核心です。管理者がClaude側でできることと、できないことを分けて整理します。

項目管理者がClaude側でできるか
機能そのもののオン/オフできる（組織設定）
利用グループの限定できる（Enterpriseのカスタムロール）
共有範囲の上限できる（組織外招待・External sharingのトグル）
コネクタ全体の利用可否できる
到達できるアプリの限定できない
閲覧者のクエリが誰の権限で走るか公式の管理者ガイドに記載なし

コネクタは、ユーザーが各自で自分のアプリを接続します。共有されたArtifactでも同じです。管理者は組織全体でコネクタを使えるかどうかは決められますが、どのアプリに到達できるかを絞り込むことはできません。

そして、ダッシュボードを開いた閲覧者のクエリが誰の権限で実行されるのか。作成者の接続情報なのか、閲覧者自身の接続なのか。管理者ガイドからは読み取れません。公式発表では確認できていない以上、断定はできません。

ウェアハウス側に読取専用アカウントを用意する

Claude側で到達先を絞れないなら、絞る場所はデータ側です。当協会の見解として、次の設計を勧めます。

  • Claudeに渡す接続は、読取専用のアカウントにする
  • そのアカウントが見られるデータセット（テーブル）を、分析に使ってよい範囲だけに限る
  • 個人情報や機密を含む列は、ビューで除外したうえで公開する
  • 部門ごとに接続アカウントを分け、Claude側のカスタムロールと対応づける

BigQueryを例にした実務の設定記事では、サービスアカウントのJSONキーを使い、データセット単位でデータ閲覧権限、プロジェクト単位でジョブ実行権限を与える構成が紹介されています。Claude側の画面パスは公式で確認できていないため、ここでは触れません。権限を「必要最小限のデータセット」と「ジョブ実行」に分けて付与する考え方だけ、他のウェアハウスにも通用します。

設計は二枚で一組です。Claude側は「誰が使えるか」を決め、ウェアハウス側は「何に触れるか」を決めます。片方だけだと、もう片方の穴がそのまま事故になります。

機密データの扱いと共有統制

HIPAA対応の組織は、Dashboardsなどを有効化はできますが、BAA（事業提携契約）の対象外です。個人の医療情報（PHI）は入れてはいけません。日本企業に直接関係する場面は多くありませんが、医療・ヘルスケア領域のデータを扱う会社は明示的に禁止しておくべきです。

データの学習への利用、保存期間、監査ログについて、Dashboards固有の公式記載は今回の確認範囲では見つかっていません。契約と社内規程に関わる事項なので、導入前にAnthropicの営業窓口か契約書面で確認する項目として残してください。

既存BIとの使い分けと、導入判断の枠組み

結論から言うと、Dashboardsは既存BIの置き換えではなく、BIの手前にある「探索の場」として置くのが現実的です。公式ヘルプも用途を、手軽な探索的な問いと位置づけています。

探索はDashboards、定型指標はBIという役割分担

TableauやLookerなどの既存BIを置き換える、とは公式のどこにも書かれていません。以下は当協会の見解です。

比較軸Claude Dashboards既存BI
向く問い突発的・探索的な問い毎週・毎月の定型指標
作る人質問できる人なら誰でも設計できるデータ担当
数字の定義依頼のたびにClaudeがSQLを書く事前に定義され固定される
再現性同じ質問でも書かれるSQLが変わりうる毎回同じ定義で集計される
統制ウェアハウス側の権限に依存BI側のロール・行レベル制御

とくに再現性の行が大事です。経営会議で「先月の解約率」が人によって違う数字で出てきたら、議論が止まります。定義が固定されるべき指標は、BIに残すべきです。

運用の流れとして、Dashboardsで見つけた「毎週見たくなる数字」をデータ担当が定義化し、BIへ移す。この往復にすると、探索の速さと指標の統一が両立します。

外部ツールとの連携も進んでいます。作成物を引き継げる分析ツールとして、Amplitude、Grafana、Hex、Mixpanel、Omni、Perplexity、PostHog、Sigmaが対応済みと報じられています。Looker、monday.com、Tableauは近日対応です。報道ベースの情報なので、利用前に最新の対応状況を確認してください。

誰に、どのデータから、どの順で入れるか

導入判断の枠組みは、三つの問いで足ります。

  1. 誰に：SQLを読めるか、読める人に確認を頼める環境にいる人から始める。経営層への一斉配布は後回しにする
  2. どのデータから：個人情報を含まず、間違えても被害が小さい社内集計から始める。売上や利用状況の集計テーブルが適しています
  3. どの順で：小さな部門で試験運用し、検証ルールと共有ルールを固めてから広げる

最初の対象には「事業企画やマーケティングの分析担当」が向いています。クエリを読める人が数字を検証し、結果を経営層に渡せるからです。

一方で、選ばない方がよい状況もあります。クエリを検証できる人が一人もいない、ウェアハウス側の権限整理が終わっていない、機密列がテーブルに混在している。この三つのうち一つでも当てはまるなら、導入を急がず、データ側の整備を先に済ませてください。

ここまでの設計や検証ルールを自社で作り切るのは骨が折れます。組織への展開を段階的に進めたい場合は、AI駆動開発研修で、AIを業務に組み込む際の権限設計や検証の進め方をチームで身につけられます。

社内ルールに落とす三つの約束

導入後に効くのは機能の知識より、運用ルールです。最低限、次の三つを文書にしてください。

ルール内容
数字の検証会議や報告に使う数字は、クエリを開いて確認した人が責任を持つ
共有範囲既定は「招待した人のみ」。組織外への共有はデータ責任者の承認制
データの境界接続してよいデータセットを一覧化し、個人情報・機密列は含めない

ルールの運用で迷う場面は、必ず出ます。経営判断にAIをどう組み込むかの設計から相談したい場合は、AI顧問の活用が手になります。経営視点の整理は、AI駆動経営の記事も参考になります。

公式に書かれていない点の確認リスト

最後に、2026年10月時点で公式の記載を確認できていない点を一覧にします。導入前に、営業窓口への問い合わせや検証で埋めてください。

未確認事項なぜ確認が要るか
閲覧者のクエリが誰の権限で実行されるかデータ側の権限設計の前提が変わる
データの更新頻度、手動更新の可否経営数値の鮮度を保証できるか判断できない
行数・チャート数の上限大きなテーブルで使い物になるか分からない
データの学習利用、保存期間契約・社内規程に直結する
監査ログでの追跡可否誰がどのデータを引いたか追えるかが決まる
Enterprise従量課金時の扱い費用の見積もりに影響する
日本語の描画精度日本語ラベルや長い表で崩れないか不明
セマンティックレイヤーへの対応「コネクタ経由で公開されていれば対応予定」との報道があるが、原典は確認できていない

この表の項目は、検証すれば埋まるものと、問い合わせでしか埋まらないものが混ざっています。更新頻度や上限は小規模な検証で分かりますが、学習利用や監査ログは契約の話です。分けて進めてください。

よくある質問

Freeプランでも使えますか？

使えません。Dashboardsはベータとして、Pro・Max・Team・Enterpriseが対象です。Freeは対象外とされています。

SQLが書けなくても使えますか？

作成は可能です。チャートごとにClaudeがSQLを書くためです。ただし、数字を業務に使う前にクエリを確認できる人が必要です。

Enterpriseで使うには何を設定しますか？

Ownerが、CapabilitiesでコードとファイルのCapabilityを有効にしたうえで、ArtifactsをOrganization settingsから有効化します。部門限定はカスタムロールで行います。

既存のBIツールは不要になりますか？

不要にはなりません。公式の位置づけは探索的な問いです。定義を固定したい定型指標は、BIに残すのが安全です。

Claude Motionとは何ですか？

数字や図、テキストを動かして、MP4の動画に書き出す機能です。生成映像ではなく、コードで動きを作ります。Team / Enterpriseでベータ提供されています。

まとめ

Claude Dashboardsの導入で決めるべきことは三つです。ウェアハウス側に読取専用のアカウントを用意すること、クエリを読める検証担当を置くこと、共有範囲の既定を絞ること。機能を有効にするのは、この三つが終わってからで遅くありません。

最初の一歩は、事業企画やマーケティングの分析担当一人に、個人情報を含まない集計テーブルだけを渡して試すことです。そこで更新頻度や上限といった未確認事項が埋まり、社内ルールの原案も作れます。ベータ機能なので仕様は変わりますが、検証の型と権限の設計は仕様が変わっても使い回せます。

AIを使った業務の進め方を、チームで体系的に学びたい企業はAI駆動開発研修をご検討ください。

次に読みたい関連記事