売上って、どの売上？ Tableauの項目説明をデータ辞書とそろえる設計

マエスです。たとえば、Tableauに「売上」という項目があるとします。さて、この売上、税込ですか。返品前ですか。値引きは引いていますか。

数字を眺める前に、まずそこが知りたい。項目の説明を開いても、書いてあるのは「売上」。うーん、もう一声ほしい。

今回は、そんな場面を架空の例にして、Tableau Data Source Edit APIによる説明文のそろえ方を考えます。辞書に決めた意味を、分析する場所へしゅっと届けたい。Tableauの新機能紹介でも、外部データ辞書との同期が活用例に挙げられています。

この記事は公式仕様と、架空データのローカル差分検証に基づく設計例です。Edit APIでの実機編集・公開は未検証です。

辞書は詳しい。Tableauは「売上」のまま

ここからは、ある会社のデータ辞書で、Salesを「返品・値引き後の税抜売上額。」と定義し、承認したと仮定します。ところが、Tableauの項目説明は「売上」の二文字。正しい定義はあるのに、使う人の目に入る場所まで届いていません。

説明をそろえる前に、元データや計算式が承認済みの定義と合うことを確認します。税込と税抜など、実際には別の指標なら、同じ説明にそろえてはいけません。

値と計算式が定義に合っているなら、項目の説明に辞書の定義を載せたい。表示名も「税抜売上額」にすれば、最初の手がかりになります。そろえるのは説明文と表示名。売上の値や計算式を変える話ではありません。表示名のcaptionと、内部の項目名nameも分けて扱います。

Data Source Edit APIは、公開データソースの項目やテーブルの説明をプログラムから編集するための機能です。ただし、「辞書を渡せば、いい感じに全部同期してくれる」わけではありません。何を正本にして、どの違いを直すか。そこは利用側で決めます。

全件送る前に、違うところだけ並べる

今回の架空サンプルでは、承認済みのJSON辞書を正本にしました。現在の説明と比べると、変更候補は次の3件です。売上に加えて、販売地域にも説明がありませんでした。

「ある説明を変える」と「まだない説明を足す」は、送る処理も分かれます。今回のローカルサンプルでは、更新用PUTが2要素、追加用POSTが1要素になりました。説明はFieldDescription／TableDescription、表示名はColumnのcaptionとして扱います。

この段階で、対応する項目が見つからない、同名が重複する、といった曖昧さがあれば停止。辞書が空欄でも、Tableauの説明は消さない。型やroleも変更しない。これらは今回のサンプルで設けた規則です。

Tableau側だけに大事な補足があるなら、辞書へ戻すか、その項目を同期対象から外すかを決めておきます。きれいにそろったけれど、必要な説明まで消えた。そんな結果にはしたくないですよね。

変更後の状態をローカルで模擬し、同じ辞書でもう一度比べると、差分は0件になりました。これは「同じ内容を何度も変更候補にしない」差分ロジックの確認です。

直す場所は、まずWork Copy

変更候補が決まったら、次は編集先を決めます。公式仕様の流れは、公開データソースを読む → Work Copyを作る → コピーを編集する → 公開する。Work Copyは編集用のコピーで、元のデータソースとはIDを分けて扱います。

図：公式仕様をもとにした概念図です。タップすると原寸で開けます。差分の照合や承認、定期実行は利用側で設計します。

今回の3件なら、同じWork Copyへ更新と追加を送る設計です。編集と公開は別の操作で、公開はPOST workcopy/{workcopyLuid}/publish。要求・応答の詳細は公式RESTリファレンスで確認できます。

ここで押さえたいのが、公開の応答は新しいdatasourceLuidを返すこと。既存データソースへの上書きや、既存Workbookの参照切り替えまで自動で済むとは断言できません。公開後のIDと、どのWorkbookでその説明が使われるかまで、試験環境で確かめます。

「200だから全部OK」で帰らない

Salesの表示名だけ変わって、説明は「売上」のまま。もしそうなったら、最初の問いが残ります。

そのため、HTTPステータスだけでは完了にしません。公式仕様では、HTTP 200の応答内に要素ごとのerrorが入る場合や、一部だけ失敗する場合があります。今回なら、3件のうちどれが成功し、どれが失敗したのかを照合する必要があります。

運用にするなら、次の順で確かめる設計を考えます。

1. 要求した変更と要素ごとの結果を照合する。失敗があれば公開へ進めない。
2. 編集後のWork Copyを読み戻し、3件とも期待する内容か確認する。
3. 公開後のデータソースを読み戻し、公開先とIDを記録する。
4. 利用先のWorkbookでも、期待する説明が見えるか確認する。

差分が0件になったことと、使う人に正しい説明が届いたこと。この二つを分けて見ておくと、どこで止まったのかも追いやすくなります。

今回の確認範囲と、試す前の条件

ここまでの例で、確認したことと、これから試すことをまとめます。

許可済みの試験データソースを特定できていないため、今回は実機編集・試験公開に進んでいません。ローカルの差分0件は、Tableauで更新できたことを示す結果ではありません。認証情報や非公開環境の画面も掲載していません。

REST APIの更新情報では、API 3.30はTableau Cloudの2026年10月／Tableau Server 2026.3に対応します。一方、利用Editionの表記には差があり、新機能紹介はEnterprise／Tableau+、RESTのエラー表はCloudのTableau+／ServerのData Management Bundleです。自分の環境で使えるかは、管理者と契約・提供状況を確認してください。

非管理者には元データソースのConnect、Write（save）、VizqlDataApiAccessが要求され、読み取りにも条件があります。composable／SDMデータソースはWork Copy作成の対象外です。また、独立したTDS検証用のvalidate／dry-runエンドポイントは未確認。先ほどの差分確認・読み戻しは、利用側で行う設計として紹介しています。

まず一つ、「どの売上？」に答える

手元の項目を一つ選んで、「現在の説明」「承認済みの定義」「変更してよい理由」を並べてみてください。対応付けが曖昧なら、送る前にそこで止めます。

先ほどの架空例なら、「現在：売上／承認済み定義：返品・値引き後の税抜売上額／理由：値・計算式は定義と一致し、説明だけが不足」と一行にできます。

次に、管理者と利用条件・権限、送信する説明文や表示名の範囲と送信先を確認。承認済みの非公開試験データソースで、Work Copyの作成から公開後の読み戻し、Workbookでの表示までを試します。その結果を見てから、対象を増やしたり、承認や定期実行を組み込んだりする順です。

辞書には、ちゃんと決めた意味がある。それが、分析する人の目に入る場所にもある。「売上って、どの売上？」に説明を開いて答えられるように、まずは一つから。Tableauへ定義を届ける方法を考えてみてください。

マエス（吉田 裕宣）

法人番号株式会社 代表取締役

X

法人番号株式会社 代表取締役／一般社団法人学生データ分析AWARD 代表理事。りょうさんより、マエスさんのTableau発信しちゃいましょうよ。 という機会を頂き思わず投稿。せっかくならばまだ日本では紹介事例が少ないもののみ取り上げていきます。