Palantir Workshopとは？機能とFDE実務での使い方を解説

Palantir Workshopとは何か？

Palantir Workshopは、Palantir Foundryのオントロジーを土台にして、業務アプリをローコードで組み立てるためのツールです。データ分析用のダッシュボードというより、現場の担当者が日々の判断と操作を行う「業務画面」を作るためのものです。

Palantirの公式ドキュメントでも、Workshopはオペレーション向けアプリを作るときの中心的なツールとして紹介されています。FDE（Forward Deployed Engineer）が顧客の現場に入り、短い期間で動くものを見せるときにも、Workshopが最初の選択肢になることが多いと考えられます。

オントロジーを起点にしたアプリ構築ツール

Workshopは、テーブルではなくオントロジー上の「オブジェクト」を扱う点が特徴です。画面はこのオブジェクトの単位で設計します。

Foundryのオントロジーは、データセットを「工場」「設備」「受注」「顧客」といった業務上の概念（オブジェクト型）と、その間のリンクに置き換えたものです。Workshopのウィジェットはこのオブジェクトを直接読み書きします。そのため、アプリの開発者がSQLやAPIの接続を毎回書く必要がありません。

逆に言うと、オントロジーの設計が粗いままでは、Workshopアプリの使い勝手もそれ以上には良くなりません。Workshopの品質を決めるのは、半分以上がオントロジー側の設計です。

誰がどんな場面で使うのか

Workshopで作られるのは、現場の担当者が「見て、判断して、操作する」ための業務アプリです。作り手は、FDE、顧客側のデータ担当者、業務部門の上級ユーザーです。

代表的な用途は次のとおりです。

どの用途にも共通するのは、「見る」だけでなく「書き込む（意思決定を記録する）」操作まで1つの画面で完結することです。BIツールとの最も大きな違いはここにあります。

Workshopの主要機能と仕組みは？

Workshopは、ウィジェット・変数・イベントで画面を組み、Actionsで書き込み、Functionsで計算するという役割分担でできています。

この5つの要素の関係をつかめば、Workshopのアプリはほぼ読み解けます。

ウィジェット・変数・イベントの3要素

Workshopの画面は、ウィジェットが変数を読み書きし、イベントが変数と画面の状態を切り替えることで動きます。

たとえば、フィルターウィジェットで絞り込んだ結果をオブジェクトセット変数に入れ、その変数を表と地図の両方に渡すと、2つのウィジェットが連動します。表で1行選ぶと「選択中オブジェクト」変数が更新され、右側の詳細パネルがその内容に切り替わります。この「変数の流れ」を設計できるかどうかが、Workshop開発の基本的なスキルです。

レイアウトは、セクション、タブ、ページ、ドロワーやモーダルといったオーバーレイを組み合わせて作ります。ロジックの大部分はコードを書かずに設定画面で組めるため、業務担当者と画面を一緒に見ながら、その場で修正していくことができます。

ActionsとFunctionsで書き込みと計算を担う

業務アプリとして成り立つかどうかは、Actionsによる書き込みと、Functionsによるロジックの組み込みにかかっています。

ActionsはオントロジーのAction型として定義します。Workshopのボタンやフォームからこれを呼び出し、オブジェクトを更新します。Action型には、実行できる条件（提出条件）やパラメータの検証を設定できます。そのため、「権限のある担当者しか承認できない」「必須項目が空なら送信できない」といった業務ルールを、画面ではなくオントロジー側で一元的に守れます。

Functionsは、標準のウィジェット設定だけでは表現しにくい集計や派生指標を作るときに使います。現場での経験から言うと、最初からFunctionsに頼りすぎると保守の担い手が限られてしまいます。まず標準機能で組めるところまで組み、どうしても必要な部分だけコードにするのが安全です。

AIPとの連携

近年のWorkshopは、Palantir AIPの機能を業務画面に組み込む場所としても使われています。

AIP Logicで作ったLLMベースのロジックをFunctionsやActions経由で呼び出したり、エージェント的なアシスタントを画面に配置したりする構成が、公式ドキュメントやデモで紹介されています。ここで大事なのは、生成AIの出力をそのまま確定させず、人がActionで承認する流れにすることです。「AIが提案し、人が決める」業務設計がFDEに求められます。なお、AIP関連の機能は更新の頻度が高いため、使える範囲は導入時点の公式ドキュメントで確認してください。

WorkshopとSlate・Quiverとの違いは？

Workshopはオントロジーを使った業務アプリ、Slateは自由度の高い独自アプリ、Quiverは分析とダッシュボードに向いています。

どれもFoundryの中で「画面」を作れるツールなので、初めて触る人は混乱しがちです。設計思想の違いを表にまとめます。

3ツールの比較表

違いは「誰が、何のために使う画面か」と「どこまで作り込むか」の2つで整理できます。

使い分けの判断基準

迷ったときはWorkshopを第一候補にし、Workshopでは要件を満たせない理由がはっきりしたときだけSlateを選ぶのが一般的です。

実務での判断の順序は次のようになります。

1. 現場の担当者が日常的に操作し、判断を記録する画面か → そうであればWorkshop
2. 時系列の深掘りや、指標間の関係を探る分析が主目的か → そうであればQuiver（Workshopへの埋め込みも検討する）
3. 対外向けのポータルのように、独自のデザインや特殊な操作がどうしても必要か → Slateを検討する
4. Slateを選ぶ場合は、引き継ぎ先にフロントエンドを保守できる人がいるかを確認する

FDEの視点で特に重視したいのは4番目です。FDEはいずれ現場を離れます。顧客が自分たちで改修し続けられるかどうかは、ツール選定の段階でほぼ決まります。

FDEはWorkshopを実務でどう使うのか？

FDEはWorkshopを、業務ヒアリングの結果を数日で動く画面にし、現場と一緒に作り直すための道具として使います。

Palantir型のFDEの価値は、要件定義書を積み上げることではなく、顧客の現場で「動くもの」を使ってもらいながら課題を絞り込むことにあります。Workshopのローコード性は、この進め方とよく合っています。

ヒアリングから本番運用までの流れ

典型的な進め方は、オントロジーの最小構成を作り、画面を作って現場で試し、Actionsで業務を組み込むという順番です。

ステップ3と4を短い間隔で何度も回すことが重要です。最初から書き込み機能まで作り込むと、業務フローが変わったときに作り直す範囲が大きくなります。

現場で気をつけたいポイント

Workshopは早く作れるぶん、設計の負債もたまりやすいです。変数の命名、モジュールの分割、権限の設計は最初に決めておくのが安全です。

現場の実務者の感覚として、次のような点が後から問題になりやすいと感じます。

• 変数が増えすぎる：画面を足すたびに変数を作ると、どの変数が何に連動しているか追えなくなります。役割がわかる命名規則を最初に決めておきます。
• 1つのモジュールに詰め込みすぎる：利用者の役割ごとにモジュールを分け、共通部分は埋め込みで使い回すと保守しやすくなります。
• 権限をアプリ側で制御しようとする：見せてよいデータ、書き込んでよい操作は、オントロジーとAction型の権限で制御するのが基本です。
• パフォーマンスを後回しにする：大量のオブジェクトをそのまま表に流すと表示が遅くなります。フィルターの初期値や集計の持ち方は試用の段階で確認します。

どれもWorkshop特有の高度な話ではありません。ただ、FDEが顧客の前で「早く作れる」ことを見せたあとにつまずきやすいポイントです。

Workshopのスキルはキャリアにどう活きるのか？

Workshopのスキルで評価されるのは操作の速さではありません。業務をオブジェクトと操作に分解する設計力が、FDEとしての評価につながります。

評価されるのはツール操作より設計力

Workshopの操作は数週間あれば覚えられます。差がつくのは、どの判断を画面に載せ、どの操作をActionにするかという設計です。

FDEの採用や評価で問われるのは、たとえば次のような力です。

Palantir製品を使わない環境に移っても、「業務オブジェクトを定義し、それに対する操作と権限を設計する」という考え方はそのまま使えます。Workshopは、この考え方を短時間で身につけられる教材としても価値があります。

学び方と経験の示し方

公式のトレーニング教材で基本を押さえ、そのうえで「どんな業務判断を画面にしたか」を説明できるようにしておくのが近道です。

学習の手順の例は次のとおりです。

1. Palantirの公式学習サイト（Palantir Learn）と公式ドキュメントで、オントロジー・Workshop・Actionsの基本を順に学ぶ
2. 個人や開発者向けに提供されている環境が使える場合は、身近な業務（例：問い合わせ管理）を題材に、一覧・詳細・ステータス更新の3画面を作ってみる
3. 作ったアプリについて「どの判断を支援し、どの操作を減らしたか」を文章にまとめる
4. 公式の認定資格を受ける場合は、その時点の対象範囲と試験要項を公式サイトで確認する

開発者向け環境や認定資格の内容は変わることがあるため、取り組む時点の公式情報を必ず確認してください。

職務経歴書や面接では、「Workshopが使える」と書くだけでは伝わりません。「現場担当者の例外対応を、一覧から担当割り当てまで1画面で完結させた」のように、業務の変化と結びつけて説明できると、FDEとしての実務経験が伝わります。FDEの導入を検討している企業の意思決定者にとっても、ツールの習熟度よりこの「業務を画面に翻訳する力」が、人材を見極めるポイントになります。

参考資料

• Palantir公式ドキュメント「Workshop」「Slate」「Quiver」「Ontology」「Actions」「Functions」各概要ページ（palantir.com/docs/foundry）
• Palantir Learn（learn.palantir.com）公式トレーニング教材

※本記事の実務上のコメントは一般的な現場経験に基づく見解です。機能の仕様や提供状況は更新されるため、最新の公式ドキュメントで確認してください。

姉妹メディアの関連記事