DWHの予算がなくても、TableauのREST APIコネクタで業務データにつなぐ

日本企業のデータ活用を、筆者の実務上の感覚からピラミッドで捉えてみます。上段には、DWH（データウェアハウス）を整え、複数のシステムからデータを集めている企業。その下には、HubSpotやkintone、freeeなどのSaaSを使い、日々の業務データはたまっているものの、DWHまでは整備していない企業があります。さらに、SaaSの利用がまだ少ない企業もあります。

今回の記事を届けたいのは、「SaaSは使っている。でも、そのデータを分析するところで止まっている」という方です。Tableauで見たいのに、使っているサービスの専用コネクタが見当たらない。「いったんDWHへ転送すればいい」と言われても、追加の予算がない、稟議が通らない、構築を頼める担当者がいない。データはあるのに、分析まで届かないことがあります。

DWHや追加のデータ転送サービスを用意できなくても、APIの仕様が合えば、Tableau純正の「REST APIコネクタ」で業務データを直接取り込めます。使うのは、HTTP GETでJSONやCSVを取得し、Tableauの抽出として分析する技術です。

今回はこの方法でHubSpotのコンタクトを対象全件取得し、Tableau Cloudに保存した後、手動で完全な抽出更新を実行しても、元データと全IDが一致することを確認できました。Bridgeや他社製コネクタ、外部のデータ転送処理は使っていません。

例えば、取得したコンタクトの作成日時を日別に集計すれば、新規登録件数がいつ増えたかを追えます。担当者やステータスへ分析を広げる場合は、必要な項目も追加取得できるかを確かめます。追加のデータ基盤を整える前にも、いまのTableauから分析を始められる可能性が見えてきました。

図：筆者の実務上の感覚に基づき、DWHを整備した層、SaaSを利用しDWHは未整備の層、SaaSの利用がまだ少ない層を、面積の違いで模式化しました。統計調査による日本企業の導入率を示すものではありません。図はタップすると原寸で開けます。

検証環境について：Cloudでの実測は、2026年10月18日時点のTableau Cloud 2026.3 Pre-ReleaseのDeveloper Sandboxで行いました。すべてのTableau Cloudサイトで現在利用できることを示すものではありません。お使いの環境の接続メニューと提供状況を確認してください。REST APIコネクタの公開仕様はこちらです。

ただし、少数件を取得できることと、全件を揃えて更新できることは別でした。ここからは、どんな設定を使い、どこで躓き、どう確かめたのかを紹介します。

使う技術は、Tableau純正のREST APIコネクタ

REST APIコネクタは、サービス側のAPIへHTTP GETを送り、返ってきたJSONやCSVをテーブルとして取り込むためのコネクタです。Tableauのコンテンツを管理する「Tableau REST API」とは用途が異なります。

設定は、新しいデータソースで「REST API」を選び、①接続先URL、②認証、③レコード配列のJSONPath、④ページ送りを指定して、抽出を作成・保存する流れです。JSONPathは、返ってきたJSONのどの配列をレコードとして読むかを指定するものです。Tableau公式の機能説明を確認すると、接続先APIとの相性を判断しやすくなります。

図：純正REST APIコネクタで抽出へ取り込む流れ。今回はHubSpotのコンタクトで、Cloudからの手動更新と全IDの一致まで確認しました。図はタップすると原寸で開けます。

短い仕様：取得はHTTP GET、形式はJSON・CSV、接続は抽出です。今回のページ送り設定はOffset/Limit方式でした。APIの認証・ページ送りがこの機能に合うかを先に確かめます。

今回の実証は、純正コネクタの接続設定によるものです。Tableauのライセンス、APIの利用条件、設定と運用の工数は必要です。そのうえで、追加のDWHや転送サービスを挟まずに取得する道を探しました。

5件は取れた。でも、そのまま全件には広がらなかった

最初はHubSpotのコンタクトを5件だけ取得しました。読み取りに絞った認証情報を設定し、接続、抽出の作成、Cloudへの保存、Cloud側からの再取得まで成功しました。

ところが、全件取得へ進むと、APIの「ページ送り」の違いに躓きました。

「100件まで」は、全件取得できないという意味ではない

HubSpotのコンタクト一覧API v3は、1回のリクエストで最大100件を返します。続きを取得するときは、前のレスポンスに含まれるpaging.next.afterの値を、次のリクエストへ渡します。HubSpotの公式仕様にある、この値の引き継ぎが必要です。

一方、今回のTableau側で設定できたのは、0、100、200……と取得開始位置を増やすoffset/limit方式でした。afterは単純な行数ではないため、パラメーター名をoffsetからafterへ変えるだけでは対応できません。1回の取得件数を大きく指定しても、API側の100件という上限に止められました。

行数が合っていても、全件取得の証明にはならない

次に、countとoffsetを使えるHubSpotの旧GET検索APIを試しました。Tableauのページ送り方式と組み合わせると、取得した総行数は元データと一致しました。

しかし、IDまで照合すると、同じコンタクトの重複と、取得できていないコンタクトが見つかりました。「元と同じ行数がある」と「同じレコードがすべて揃っている」は、別の確認です。

この時点では、重複が生じた内部的な原因までは特定できていません。取得順を明示する設定を加えた後に、欠落と重複が解消したことを実測で確認しました。

図：ページ送りの方式と、件数だけでは見抜けない重複・欠落。A・B・Cは説明用の架空IDです。図はタップすると原寸で開けます。

APIがあることや、最初の数件が取れることだけでは、全件取得できるとは判断できません。必要なのは、TableauとAPIのページ送りを合わせ、同じレコードが過不足なく揃うかまで確かめることでした。

突破口は、ID順を固定してからページを送ること

HubSpotの旧検索APIには、並び順を指定するsortとorderがありました。HubSpotの公式告知では、内部プロパティ名と昇順・降順を指定できると説明されています。

そこで、レコードIDを表すhs_object_idの昇順に固定し、100件ずつ取得するようにしました。今回動作を確認した接続先は次の形です。

https://api.hubapi.com/contacts/v1/search/query?q=&sort=hs_object_id&order=ASC&property=createdate&property=lastmodifieddate

countとoffsetはページ送りの設定側で指定し、基本URLには重ねて入れていません。認証情報には、今回の取得に必要なコンタクト読み取り権限だけを付与しました。トークンをURLや記事、画像に含めないことも大切です。

この設定で、対象コンタクトの全件取得、重複のない全IDの一致、Cloudで保存した接続からの再取得後の一致まで確認できました。このHubSpotのケースでは、APIの選び方と取得順を整えることで、純正コネクタの設定だけでCloudへの全件取り込みに進めたのです。今回の「全件」はコンタクトの全レコードです。会社・取引・活動などHubSpotの全オブジェクトや、全プロパティを取得した実験ではありません。

全件確認は、次の順で件数とIDを照合します。今回も、取得元とTableauのID一覧を別の経路で用意し、集合として一致するかを確かめました。

① 取得元から、同じ対象条件のレコードID一覧を用意します。実務ではエクスポートなども候補です。比較する範囲と確認時点を揃えます。

② Tableau側でIDのNullがないことを確認し、COUNT([ID])とCOUNTD([ID])を比較します。両者が異なれば、同じIDを複数行取り込んでいます。[ID]は実際のIDフィールド名に置き換えます。

③ 両方のID一覧を照合し、「取得元にだけあるID」「TableauにだけあるID」がそれぞれ0件かを確認します。同じ件数・重複なしでも、別のIDに入れ替わっている可能性があるためです。保存した接続から更新した後にも、この照合を繰り返します。

ID順を固定しても、取得の途中でレコードが追加・削除されると、offsetの指す位置が変わる場合があります。並び順の指定だけで将来の完全性を保証せず、更新後も件数とIDの照合を行うことが大切です。

また、確認したのは手動で開始したCloud側の完全な抽出更新です。定期スケジュールの実行まで検証したものではありません。旧検索APIを使う構成なので、今後のAPI仕様変更への追従も運用に含めて考えます。

標準コネクタで、先に確認しておきたいこと

「追加の転送基盤を用意せずに、分析へ進めるか」という最初の問いには、HubSpotのコンタクトで一歩進めました。ここからは、皆さんの使うサービスで同じ道を探すための確認点です。「APIが公開されているか」の次に、取得方法がTableauのコネクタと合うかを確かめます。

「JDBCドライバーが必要」という説明も、実行する場所と一緒に読みます。公開されているDesktop向け手順ではドライバーを配置します。一方、今回のCloud検証ではブラウザ上の接続メニューから設定し、手元のPCへのドライバー導入やBridgeの稼働を使わずに取得できました。DesktopとCloudの利用条件は、それぞれ確認してください。

なお、以前のWeb Data Connectorの開発記事を参考にする場合は、世代と対応環境も確認が必要です。WDC 3.0は非推奨となり、Tableauは純正REST APIコネクタへの移行を案内しています。

kintone、freee、Asana……普段使うサービスのAPIから可能性を探す

ここまでで分かったのは、サービス名の付いた専用コネクタがなくても、APIの仕様が合えば接続の可能性があるということです。専用コネクタやデータ転送サービスを使っている方にも、純正REST APIコネクタから直接取得を試す選択肢が見えてきました。次は自分の使っているサービスで考えられるよう、日本製サービスや海外SaaSの公開APIを一覧にしました。

下表は接続先を検討するための一覧です。実機で接続・全件取得・保存後の更新を確認したのは、HubSpotのコンタクトだけです。各行の取得例はサービス側のAPIの機能であり、すべてがTableauの標準設定だけで取得できるという意味ではありません。専用コネクタの有無を網羅した一覧でもありません。

日本製サービスのAPI（Tableau接続は未検証）

海外サービス・オープンソースのAPI（HubSpot以外は未検証）

特に、APIが返すカーソル、次ページURL、Linkヘッダーを追う方式は、今回のOffset/Limit設定へ名前を合わせるだけでは全件取得できません。ページ番号方式も、取得開始行を増やす方式とは異なります。認証、GETの対象、ページ送り、データの形を照らし合わせることが出発点です。

標準設定で合うAPIから試し、違いが大きい場合は、取得処理や変換を実装するカスタムコネクタ開発の余地もあります。その際は、開発方式の現行サポートとTableau Cloudへの配置条件を別途確認します。今回の実証を入口に、これまで取り込めなかったサービスのデータへつながる可能性を探していきたいと思います。

すでにDWHがあるなら、Tableau Prepから書き出す道も

図：Tableauに取り込んだデータをPrepからDWHへ出力する候補経路。破線の部分は今回は未検証です。図はタップすると原寸で開けます。

冒頭では、DWHをまだ整備できていない方へ、直接分析する道を紹介しました。すでにDWHがある方にとっても、Tableauへデータを持ってこられると、その先の使い道が生まれます。Tableau Prepには、フローの結果を対応する外部データベースへ出力する機能があります。いわゆるライトバック（データベースへの書き込み）で、Snowflake、Google BigQuery、Amazon Redshiftなども出力先に含まれます。Tableau公式の出力仕様で対応先を確認できます。

公開済みのデータソースもPrepの入力にできるため、SaaSのAPI → Tableauの公開抽出 → Tableau Prep → DWHという経路も検討できます。取り込んだデータを整え、DWHへ書き出して、ほかのデータと一緒に使う発想です。入力時の制約は公開データソースへの接続仕様を確認してください。

DWH側の連携機能や既存の転送手段で取り込めるSaaSもあります。その対象に必要なサービスがない場合は、Tableauを経由する選択肢も覚えておいてください。

今回、DWHへの書き込みまでは実機検証していません。出力先の対応状況、書き込み権限、Cloudからの到達性を確認し、定期実行にはPrep Conductorなどの契約・実行条件も確認します。公開抽出の更新とPrepの実行は別の処理なので、その順序も設計します。フローのスケジュール実行の条件はこちらです。

DWHの導入を待つ間にも、試せることがある

まずは、分析したい項目だけを少数件取得する。次に全件でIDを照合し、保存した接続から更新できるかを試す。この順で確認すると、「接続できた」と「業務で使える」の間にある問題を見つけやすくなります。

DWHは、履歴の蓄積や複数システムのデータ管理に役立つ基盤です。一方、SaaSにはデータがあるのに、追加予算や稟議で分析が止まっているなら、APIの仕様が合う範囲で、Tableau純正のREST APIコネクタから直接取り込む道を試せます。今回のHubSpot検証では、その道で全件取得とCloudからの更新まで進めました。

まず、お使いのTableau環境にREST APIの接続メニューがあるかを確認します。表示されない場合は、サイト管理者と提供状況を確認してください。利用できる場合は、上の一覧から普段使うサービスのAPIを調べ、分析したい項目を少数件だけ取得してみてください。そこが、次の分析へ進む最初の一歩です。

ロゴ出典：各社の公式配布素材。Backlog：Copyright: Nulab, Inc.（公式素材）。Redmine：Copyright (C) 2009 Martin Herr／CC BY-SA 2.5（公式素材）。

マエス（吉田 裕宣）

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

X

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