ThoughtSpotウェビナー「SpotMap」（2026年5月）についてご紹介いたします

AkimasaKajitaniです。本ブログ記事は、2026年にSpotMapという新たに始まったウェビナーシリーズの内容についてブログに書いているシリーズです。

 

SpotMapウェビナーって何？

SpotMapウェビナーは、ロードマップをご紹介するウェビナーシリーズとなっており、毎月第一木曜日に開催されます。ThoughtSpotの製品分野として６つあり、年２回ずつ行われる、とのことです。

SpotMapへの登録はこちらのリンク からできます。

今回のアジェンダ

今回はコアアプリと呼ばれる部分についてのウェビナーとなります。コアアプリというのは馴染みがありませんでしたが、いわゆる基盤と呼ばれるものです。これには、クラスタ管理、オブジェクトライフサイクル管理、スケーラビリティ、インデックス作成などが含まれるとのことです。

特にその中でも、コレクション、公開管理ポータル、オブジェクトIDとゴミ箱に焦点があたります。つまり、今回は管理者向けのウェビナーでしょうか・・・。

 

コレクション

 

まず、スライドを翻訳してみましょう。

 

主なポイント

1. コレクションは、TS のツールとして、異種オブジェクトを階層的に整理し、複数の (異種) オブジェクトへのアクセスを一度に管理します。
2. 顧客のニーズに応じて、回答、ライブボード、モデル、テーブルの論理的な構成を提供します。
3. コレクションとその中のオブジェクトに対する共有権限を分離します。
4. UI、API、TML の 3 つすべてがサポートされています。
5. 26.5 で一般提供開始。

第 4 四半期の予定（5、6、7月）

1. TS MCP サーバーのスキルとして、コレクションの CRUD 操作が利用可能になります。

実際に語られていることでは、コレクションの中に、ライブボード、Answers（回答）、モデル、テーブルを格納でき、コレクションは階層構造にできる。ということで、例えばモデルだけのコレクションを作ったり、という形で整理できます。権限も、コレクションに対する権限と、中に格納されたライブボードなどの表示・編集権限は異なる、ということがポイントです。つまり、ある人が編集権限を持つオブジェクトばかりのコレクションを作り、そこに他の人が閲覧権限で共有ができる、ということができます（異なる権限のオブジェクトを混ぜて配置できる）。

特に、第四四半期のアップデートでは、MCPサーバー上でコレクションのCRUD操作ができる、というのが強調されています。

コレクションのデモもウェビナーでは行われています（共有されたスライドにもデモビデオのURL貼ってるんですが、どうも誰でも見える権限が付与されていないようです）。

 

デモで解説されている内容で興味深いもの：

• コレクションはエクスポートもでき、中に入っているオブジェクトごとエクスポートが可能です。
• APIも利用可能ですが、共有はできません

QAでは、コレクションを消す時に中のオブジェクトの元となるものを消すのを防ぐことができるかどうか、というものがありましたが、消す時に「削除」と入れないと消せないようになっているとのことです。基本的に、コレクションは誰かが作ったものを共有するものなので（もちろん自分自身で作ることもできます）、管理は気をつける必要があるように思いました（組織内の公式的なコレクションを作りたい、ということであれば、管理者側で作って共有してその組織内の公式のコレクションとすれば良いかとは思います）。このあたりについても言及があり、コレクションの管理についてはまだ現状の機能では限界もある、とのことです。

その他、コレクションにSpotter会話の追加というアイデアも出てきます（現時点ではそのような機能はありません）。

 

パブリッシング

パブリッシングは、「Publishing」なので、そのまま翻訳すると「出版」となるのですが、日本語の場合普通の単語すぎてわかりにくいので私は「パブリッシング」と翻訳しています（「公開機能」とかが直感的で良いのでしょうか？）

 

 

まず、スライドを翻訳してみましょう。パブリッシングのまとまった説明を聞くことは少ないのでこの機会を活用しましょう。

 

パブリッシングとは何？

• プライマリ組織からターゲット組織へオブジェクトを読み取り専用で共有します。
• ライブボード、回答、モデルは、TMLのエクスポート/インポートに依存せずに公開できます。
• 接続とテーブルのパラメータ化がサポートされており、実行時にデータを変更できます。

どのように役立つか？

• オブジェクトのLCMが非常に簡素化されます。
• 同じオブジェクトの複数のTMLコピーが作成されないため、オブジェクトの肥大化がありません。

 

パブリッシングは、概念として少し説明がないとわかりにくいかと思います。これは、基本的に、オブジェクト、ライブボード、回答、モデルをプライマリ組織からターゲット組織へ読み取り専用で共有できるようにする機能です。現在、これはインスタンス管理者のみが実行できる機能です。

この基盤となっているのは、接続、テーブルに「変数」を使用してパラメータ化をサポートし、実行時にデータを変更できるようにする、というものです。つまり、プライマリの組織（Org）から他の組織（組織１、組織２、組織３）へ、あるライブボードをパブリッシングすると、組織１のライブボードにアクセスすると組織１のデータが反映され、組織２のライブボードにアクセスすると、組織２のデータが反映される、といったものです。つまり、同じライブボードなのに組織（Org）によって中身のデータが変わって見える、ということになります。

これにより、各組織で同じライブボードを見たい場合、通常はTMLのエクスポート・インポートで対応していたものが、プライマリ組織からパブリッシングしたもので代替できるため、手間がかかる作業が必要ない、というのがポイントです。

 

 

次にロードマップです。

現在の機能

• 接続とテーブルのパラメータ化
• API サポート
• UI サポート
• パブリッシングオブジェクトのスポッター
• パブリッシングオブジェクトと連携するカスタムカレンダーのサポート

2026 年度第 4 四半期以降の目標（5月～7月）

• 導入をさらに促進するオブジェクト移行ツール
• 直感的に操作できるようにパブリッシング UI を強化 (パラメータ化解除)
• プライマリ以外の組織での UI の変数ビュー
• モデル/回答/LB (タグ、セット) に関連付けられたオブジェクトのパブリッシング
• TS MCP サーバーへのパブリッシングワークフローの公開 (第 4 四半期以降)
• プライマリ以外の組織からのパブリッシング (第 4 四半期以降)
• 変数の使用例を翻訳、動的クエリ生成などに拡張 (第 4 四半期以降)
• パブリッシングへのアクセスを拡張 (第 4 四半期以降)

 

5月～7月の予定として、パブリッシングを使いたいお客様が多く、オブジェクト移行ツールを作成し、導入しやすくするそうです。その他新機能は上の通りです。

 

顧客事例についても紹介されました。

ある顧客は、ユースケースの約50%をパブリッシングに移行しました。パブリッシングでは、322の組織にわたって約10～13個のオブジェクトが公開されます。メタデータノートの数は大幅に減少し、約45%削減されました。クラスタのメモリ使用量も減少しました。以前は77%使用されていましたが、現在は55%にまで低下し、実質的にメモリ使用量を4分の1以上削減しました。

実際のお客様の声も紹介されています。

それは彼らにとって非常に役立ち、まさにゲームチェンジャーと言えるものでした。そして、彼らのSDLC開発およびデリバリープロセスを非常に迅速にし、以前よりもはるかに拡張性の高いものにしました。

別のお客様の事例です。

「顧客2」は公開機能に大変満足しており、早期導入企業の1社です。旧CSツールと比較して、これは非常に大きな改善点であり、以前は数時間かかっていたコンテンツの組織全体への展開が、わずか1～2分で完了するようになったと評価しています。旧方式は再現性がなく、「一貫性がなく」「標準化されていない」応答が特徴の「見苦しい解決策」であり、自動化ソフトウェアの開発を困難にしていたと述べています。一方、公開機能は、自動化と継続的デプロイメントに必要な標準化を提供します。

実際にパブリッシングのデモを行っていますが、これは実際に見ていただいた方が良いかもしれません。ベータの頃はAPIでしかできなかったのですが、現在は驚くほど簡単にGUIからパブリッシングすることができます。

単にパブリッシングするだけだと、そのままライブボードが読み取り専用のオブジェクトとして各Orgで見えるようになるだけです。パブリッシングの際に、以下のようにパブリッシング先を選択すればオッケーです。

 

 

ただ、各組織（Org）で見えるものを変えたい、といった場合は変数を使います。

 

 

以下のようにマッピングすることができます。

 

 

そして、パラメータ化を行います（これは、テーブルを選択し、メニューから「Parameterise」を選択しています。これで、スキーマが変数にひも付きます。

 

 

これにより、以下のようにライブボードをパブリッシングする際に、パラメータ化されたことがわかると思います。

 

 

つまり、スキーマがパラメータ化されているので、GeorgiaOrgでは、テーブルのスキーマが「ORG1」としてデータ接続を行う、ということになります。

管理者ポータル

管理者ポータルは、あまりこれまで開発に注力されていない領域とのことですが、重要性は認識されているとのことです。今後は積極的に力を入れていきたい、とのことです。

 

 

26.6

• 組織レベルでEA機能とGA機能の両方にフラグを設定できる機能

2026年度第4四半期

• 情報アーキテクチャの再考
• UIの刷新
  • ユーザー管理
  • 組織管理
  • アプリケーション設定
  • 機能管理
• 管理ポータル内の統合検索ボックス
• ユーザーなりすまし（スキルとして）

2027年度第1四半期以降

• 管理ポータルをTS MCPサーバーに公開
  • 監査ログ
  • 所有権の一括転送
  • ユーザーなりすまし
  • ガバナンスとセキュリティセンター

 

26.6では、アーリーアクセスとGA（商用化）の両方の機能に対して、組織レベル（Org）でフラグを設定できるようにするとのことです。これは、組織ごとに設定を上書きする、といった機能になるようです。画面は以下のようになるとのこと。

 

 

各機能を選ぶと、以下のようにOrgごとに設定できるようになるとのこと。

 

 

実際にそのOrgに入ると、OrgのAdminの方で設定が可能になります。

次に、UIの刷新です。以下は、クラスタ管理者のアプリケーション設定の画面です。

 

 

以下は、クラスタ管理者のユーザー管理の画面です。ユーザー管理ページには、ユーザー、グループ、ロール、認証などが表示されます。新しいユーザーの追加、ユーザーに対する現在の操作の実行、ユーザーをグループに割り当て、ロールを管理できます。

 

 

いろいろな機能がMCPサーバーに公開されるようですが、これを使うと、AIから利用できるようになるので、管理が省力化される、ということになるかと思います。

デモでは、セキュリティログを取得し、結果を表示しています。これはMCPサーバーを使っています。

 

 

オブジェクトID＆ゴミ箱

 

今回のウェビナーのラストです。まずスライドの翻訳から。

 

要点

1. 問題点：GUIDは機械可読ですが、意味的に不透明であるため、シームレスなCI/CDワークフローには適していません。また、TML操作を行うたびに新しいGUIDが生成されます。
   1. これは、環境間でのオブジェクトの移植に影響を与えます。
   2. GUIDのライフサイクルは、クラスタ外で手動で行う必要があります。

解決策

1. 機械可読なGUIDと人間可読なオブジェクトIDを組み合わせた二層構造のIDシステム
2. 環境間で完全に移植可能なオブジェクト用TML
3. IDを標準化し、デプロイメントの俊敏性を向上させ、OLM（ごみ箱、GIT CICD）の基盤を提供します。
4. オブジェクトIDとごみ箱は、2026年度第4四半期に提供開始予定です。

 

記載の通り、基本的にすべてのオブジェクトはGUIDで管理されていますが、環境間（クラスタ間）での移植性が考慮されていないものになってしまっています。そのため、ThoughtSpot外で手動で管理する必要があります。これに対して、ObjectIDというものを導入し、これを使って環境間の移行をうまくできるように開発を行っているとのことです。この四半期では、最も重要な9つのオブジェクトのObjectIDについて作業を行うとのこと。

 

ゴミ箱は、論理削除的なイメージのもののようです。オブジェクトを削除しても、ゴミ箱コンテナに移動し、実際にクラスターから消えるには一定時間かかるとのこと。これで誤って削除しても大丈夫、ということになります。

 

スライドにはない内容で、インデックスクエリの削減にも取り組んでいます。

• インデックス作成頻度の細かい制御
• 特定のテーブルに対して、異なる頻度の割り当て
• 大きなテーブルを除外