パランティアが米軍の司令部に提供するものを、一言で言えば「作戦室（Operations Room）」だ。
全ての情報が一画面に集約される。衛星データ・地上センサー・人的情報・過去の作戦記録
これらがリアルタイムで統合され、「今、戦場で何が起きているか」が可視化される。司令官は画面を見て、即座に判断を下す。判断はシステムを通じて現場に届き、数分以内に行動が始まる。
「情報収集から行動まで」のサイクルタイムを極限まで短縮する。
これがパランティアの最大の価値だ。
通販企業版の「作戦室」は何か。
「顧客・在庫・施策・売上のリアルタイム状況が一画面で見え、次に何をすべきかが自動的に提示され、承認ボタン一つで施策が動き出す」そういう環境だ。
「作戦室」の設計原則—パランティアから学ぶ5つのルール
パランティアの作戦室には、設計上の原則がある。
原則①：「現在」が最優先で表示される
過去のトレンドより「今、何が起きているか」が画面の中心にある。
原則②：「異常」が自動的に浮かび上がる
正常な状態は静かに流れ、異常な状態だけがハイライトされる。
「全てを見る」ではなく「見るべきものだけが見える」。
原則③：「次の行動」が提示される
情報を見た人間が自分で「だから何をすべきか」を考えるのではなく、システムが「推奨アクション」を自動的に提示する。
原則④：「承認」だけが人間の仕事
複雑な分析・判断・推奨はシステムが行う。
人間の役割は「承認するか拒否するか」という最終判断だけだ。
原則⑤：「全てのデータが一つの地図に統合されている」
チャンネルAの画面、システムBの画面、レポートCのExcel
これらを切り替えながら状況を把握する必要がない。全てが一つの「地図」として統合されている。
「今、何が起きているか」を示す日次モニタリングSQL
作戦室の中核は「毎朝の現状確認SQL」だ。
-- 通販企業版「作戦室」——今日の状況を一発で把握する日次モニタリングSQL
WITH
-- 昨日の売上
yesterday_sales AS (
SELECT
SUM(amount) AS total_revenue,
COUNT(DISTINCT order_id) AS total_orders,
COUNT(DISTINCT customer_id) AS unique_buyers,
SUM(amount) / COUNT(DISTINCT order_id) AS avg_order_value
FROM orders
WHERE
order_date = DATE_ADD('day', -1, CURRENT_DATE)
AND status = 'completed'
),
-- 前日比・前週比
comparison AS (
SELECT
-- 前日（2日前）の売上
SUM(CASE WHEN order_date = DATE_ADD('day', -2, CURRENT_DATE)
THEN amount ELSE 0 END) AS day_before_revenue,
-- 先週同曜日の売上
SUM(CASE WHEN order_date = DATE_ADD('day', -8, CURRENT_DATE)
THEN amount ELSE 0 END) AS last_week_same_day
FROM orders
WHERE
order_date IN (
DATE_ADD('day', -2, CURRENT_DATE),
DATE_ADD('day', -8, CURRENT_DATE)
)
AND status = 'completed'
),
-- 今日の在庫アラート（発注点を下回っている商品数）
inventory_alert AS (
SELECT
COUNT(CASE WHEN current_stock <= reorder_point THEN 1 END) AS items_need_reorder,
COUNT(CASE WHEN current_stock = 0 THEN 1 END) AS items_out_of_stock
FROM (
SELECT
im.product_id,
im.current_stock,
ROUND(sv.daily_avg_units * (im.reorder_lead_days + im.safety_stock_days), 0)
AS reorder_point
FROM inventory_master im
JOIN (
SELECT product_id, SUM(quantity_sold) / 30.0 AS daily_avg_units
FROM order_items oi JOIN orders o ON oi.order_id = o.order_id
WHERE o.status = 'completed'
AND o.order_date >= DATE_ADD('day', -30, CURRENT_DATE)
GROUP BY product_id
) sv USING (product_id)
) t
),
-- CJOの今日のアクティベーション件数（CJOテーブルから）
cjo_today AS (
SELECT
COUNT(DISTINCT cdp_customer_id) AS profiles_activated_today
FROM journey_13 -- journey_${journey_id}
WHERE intime_stage_0_24d42ab6_activation = -- Activation Stepのカラム
TD_DATE_TRUNC('day', TD_SCHEDULED_TIME(), 'JST')
),
-- 休眠顧客の新規発生数（昨日初めて30日間購買がなくなった顧客）
new_dormant AS (
SELECT COUNT(DISTINCT customer_id) AS new_dormant_today
FROM (
SELECT customer_id, MAX(order_date) AS last_order_date
FROM orders WHERE status = 'completed'
GROUP BY customer_id
) t
WHERE last_order_date = DATE_ADD('day', -30, CURRENT_DATE) -- ちょうど30日前が最終購買
)
SELECT
-- 【売上サマリー】
ys.total_revenue AS "昨日の売上",
ys.total_orders AS "昨日の注文数",
ys.unique_buyers AS "昨日のユニーク購買者数",
ROUND(ys.avg_order_value, 0) AS "昨日の平均客単価",
-- 【前日比・前週比】
ROUND((ys.total_revenue - c.day_before_revenue)
/ NULLIF(c.day_before_revenue, 0) * 100, 1) AS "前日比(%)",
ROUND((ys.total_revenue - c.last_week_same_day)
/ NULLIF(c.last_week_same_day, 0) * 100, 1) AS "前週同曜日比(%)",
-- 【在庫アラート】
ia.items_need_reorder AS "発注点以下の商品数",
ia.items_out_of_stock AS "在庫切れ商品数",
-- 【CJOアクティベーション】
cj.profiles_activated_today AS "今日のCJOアクティベーション数",
-- 【顧客状態変化】
nd.new_dormant_today AS "本日新規休眠化顧客数"
FROM
yesterday_sales ys,
comparison c,
inventory_alert ia,
cjo_today cj,
new_dormant ndこのSQLを毎朝digdagで実行し、Slackに投稿する。これが通販企業版「朝の作戦会議」の自動化だ。
「異常検知」の自動化—正常からの逸脱を検出する
作戦室の真価は「異常が自動的に浮かび上がる」設計にある。
-- 売上の異常検知：過去30日の平均と標準偏差から逸脱を検出する
WITH daily_sales AS (
SELECT
order_date,
SUM(amount) AS daily_revenue
FROM orders
WHERE
status = 'completed'
AND order_date >= DATE_ADD('day', -31, CURRENT_DATE)
AND order_date < CURRENT_DATE -- 昨日まで
GROUP BY order_date
),
stats AS (
SELECT
AVG(daily_revenue) AS avg_revenue,
STDDEV(daily_revenue) AS stddev_revenue,
MAX(daily_revenue) AS max_revenue,
MIN(daily_revenue) AS min_revenue
FROM daily_sales
WHERE order_date < DATE_ADD('day', -1, CURRENT_DATE) -- 昨日を除く直近30日
),
yesterday AS (
SELECT daily_revenue AS yesterday_revenue
FROM daily_sales
WHERE order_date = DATE_ADD('day', -1, CURRENT_DATE)
)
SELECT
y.yesterday_revenue,
s.avg_revenue,
s.stddev_revenue,
-- Z スコア（平均から何標準偏差離れているか）
ROUND((y.yesterday_revenue - s.avg_revenue) / NULLIF(s.stddev_revenue, 0), 2)
AS z_score,
-- アラート判定
CASE
WHEN ABS((y.yesterday_revenue - s.avg_revenue) / NULLIF(s.stddev_revenue, 0)) >= 2.0
THEN '🚨 異常値（±2σ逸脱）——原因調査が必要'
WHEN ABS((y.yesterday_revenue - s.avg_revenue) / NULLIF(s.stddev_revenue, 0)) >= 1.5
THEN '⚠️ 注意（±1.5σ逸脱）——要モニタリング'
ELSE '✅ 正常範囲'
END AS anomaly_status
FROM yesterday y, stats s「推奨アクション」の自動生成—判断をシステムに委ねる
パランティアの最も先進的な機能は「推奨アクション（Recommended Actions）」だ。
データを分析した結果として「だからこうせよ」という提案を自動生成する。
-- 今日の推奨アクション一覧を自動生成する
SELECT
priority,
action_type,
description,
estimated_impact,
recommended_channel,
target_count
FROM (
-- アクション①：ウィンバック対象の緊急顧客
SELECT
1 AS priority,
'WINBACK_URGENT' AS action_type,
'購買間隔が通常の2倍以上経過した優良顧客へのウィンバック' AS description,
'推定CVR 12%・推定売上回復 XXX万円' AS estimated_impact,
'メール + SMS（クーポン付き）' AS recommended_channel,
COUNT(DISTINCT customer_id) AS target_count
FROM customer_ontology
WHERE
churn_status IN ('要注意休眠', '深刻休眠')
AND ltv_tier IN ('VIP', '優良')
AND recency_days BETWEEN 60 AND 180
UNION ALL
-- アクション②：在庫切れ予測商品の発注
SELECT
2 AS priority,
'REORDER_ALERT' AS action_type,
'発注点を下回った商品の緊急発注' AS description,
'欠品防止・機会損失回避' AS estimated_impact,
'購買部門への発注指示' AS recommended_channel,
COUNT(product_id) AS target_count
FROM inventory_master im
JOIN (
SELECT product_id, SUM(quantity_sold)/30.0 AS daily_avg
FROM order_items oi JOIN orders o ON oi.order_id = o.order_id
WHERE o.status = 'completed'
AND o.order_date >= DATE_ADD('day', -30, CURRENT_DATE)
GROUP BY product_id
) sv USING (product_id)
WHERE im.current_stock <= sv.daily_avg * (im.reorder_lead_days + im.safety_stock_days)
UNION ALL
-- アクション③：CJOで今日アクティベーションされた顧客の確認
SELECT
3 AS priority,
'CJO_ACTIVATION_CHECK' AS action_type,
'本日のCJOアクティベーション実行確認' AS description,
'ジャーニーが正常に動作しているかの確認' AS estimated_impact,
'Treasure Data コンソール確認' AS recommended_channel,
COUNT(DISTINCT cdp_customer_id) AS target_count
FROM journey_13
WHERE intime_stage_0_24d42ab6_activation =
TD_DATE_TRUNC('day', TD_SCHEDULED_TIME(), 'JST')
) actions
ORDER BY priority通販企業版パランティアの本質
このシリーズを通じて伝えたかったことを最後に整理する。
#10：思想の翻訳
パランティアが軍に提供しているもの（バラバラなデータの統合→リアルタイムの意思決定支援）は、通販企業が顧客データでやるべきことと同じ構造だ。
#11：インテリジェンス思考
「何が起きたか（過去）」ではなく「次に何が起きるか（未来）」を予測する思考法。
HUMINT・SIGINT・OSINTという情報源の分類は、顧客データの分類にそのまま使える。
#12：予測的補充
「弾薬が切れてから補充する」ではなく「切れる前に補充する」設計。
在庫管理もSQLで予測可能だ。
#13：オントロジー
バラバラなデータに「意味」を与え、「顧客ID」を「行動可能なインテリジェンス」に変換する設計思想。
これはTreasure DataとSQLで実装できる。
#14：作戦室（本記事）
全ての情報が統合され、異常が自動検知され、推奨アクションが提示される環境。これが「データで経営する」という状態の最終形だ。
「全てを見通す水晶」は自分で作れる
パランティアに億単位のシステム投資をしなくても、「通販企業版パランティア」は作れる。
必要なものは三つだ。
Treasure Data（データプラットフォーム）、SQL（データの言語）、そして「今、何が起きているか」を問い続ける意志。
技術は道具だ。道具は使う人間の意志によって、はじめて「全てを見通す水晶」になる。
戦場でも通販でも、データが「見えている組織」と「見えていない組織」の差は、時間とともに埋めようのないものになっていく。
あなたの通販企業は、今日の「戦場」を見えているか。
