Every offline workspace already knows things. Work, time, people, movement. We call that memory layer StoreGraph our ontology of how a workspace runs. AI Hub reads it, and turns it into decisions you approve, actions it runs, and results that come back.

AI Hubはオントロジー上で動作します。

オフライン空間の運営を 判断に変える技術です。

現場の文脈の上で、より良い判断と即時の実行を支えます。

意思決定ツールの不在

[lack of decision making tool]

私たちの解き方

データ収集から問題解決まで

DATAPOSERPLOGSENSORCSVAPIAPIONTOLOGYperformstakesdrivesupdatesWORKPEOPLETIMEMOVEMENTAPPLICATIONRUN 24/7ANALYTICSWORKFLOWSINTEGRATIONS
DATAPOSERPLOGSENSORCSVAPIAPIONTOLOGYperformstakesdrivesupdatesWORKPEOPLETIMEMOVEMENTNODE · PEOPLELINKED SIGNALS12LAST UPDATE00:12CONFIDENCE97%APPLICATIONRUN 24/7ANALYTICSWORKFLOWSINTEGRATIONS
DATAPOSERPLOGSENSORCSVAPIAPIONTOLOGYperformstakesdrivesupdatesWORKPEOPLETIMEMOVEMENTAPPLICATIONRUN 24/7ANALYTICSWORKFLOWSINTEGRATIONS
OPERATIONSDECISIONAPPROVEACTIONFEEDBACK

データ収集

IngestSTREAMNormalizeDedupeSchema Mapv3Validate

ひとつの汎用AIではなく、

機能ごとの専門家を送り込む。

データ収集・処理から、

AIエージェントの業務遂行まで。

ONTOLOGYAI HUBF&BDELIVERYRETAILLAST MILELOGISTICS

AI HUBターゲットアーキテクチャ、12レイヤー

顧客体験、知能組織、共通記憶、実行・運用基盤を分離した拡張型構造です。

L1

チャネル・顧客体験

  • Web/App
  • Chat
  • Dashboard
  • Report
  • Notification

各レイヤーは独立した責任を持ちます。

L1-L2

顧客体験

店主と本部が見るページとDecision Cardを構成します。質問、レポート、承認、通知がこのレイヤーで統合されます。

ドメインを理解し、

人と協働し、

決定を支えるAI Agent。

注文のピークは 予定どおりには来ない

F&Bの核心は、ピークタイムの判断スピードです。

需要予測の不在

天候・曜日・イベントで注文量は毎日変わるのに、予測の根拠がなく、準備量は担当者の経験頼みになります。

在庫と注文の分断

販売はPOSに、在庫の引き落としは別システムに記録され、実際の残量をリアルタイムに把握できません。

勘頼みの人員配置

ピークがいつ来るかデータで見えず、シフトは担当者の勘に依存します。

ピーク前に準備を終わらせる判断

注文・在庫・天候・人員をひとつの文脈で読み、ピーク対策と在庫切れ予測を先に示すよう設計されています。

Ontology

ORDER

84%

relation coverage

Data schema

Data schema

Data schema

INVENTORY

consumes

STAFF

handles

WEATHER

affects

イベントストリーム

Stream

relations mapped in realtime

DEVICE

LOG

TIME

STATUS

CC-MHYYSSPF

[天候 → 注文] 降雨シグナル、デリバリー加重

14:30:12

LINK

CC-MV1-2X4J

[決済] 承認、₩12,500

14:31:40

INFO

CC-MHYYSSPF

[注文 → 在庫] 豆の在庫引き落とし連動

14:31:55

LINK

CC-MV1-2X4J

[注文] アメリカーノ(HOT) 受付

14:32:07

INFO

CC-MV1-2X4J

[人員 → 注文] ピーク人員マッチング

14:20:05

LINK

CC-MRLNBYXL

[在庫] 豆の残量20%を検知

14:22:18

WARN

CC-MV1-2X4J

[注文] アメリカーノ(HOT) 受付

14:32:07

INFO

注文の急増は 前触れなしには来ない

デリバリーの核心は、急増前の備えです。

急増予測の不在

注文の急増は過ぎてから確認され、ライダー確保も調理準備もいつも遅れて始まります。

調理と配車のズレ

調理完了とライダー到着の時刻が噛み合わず、料理が冷めるか、ライダーが待たされます。

エリア別需要の偏り

エリアごとの需要変化をリアルタイムに読めず、ライダーが余る区域と足りない区域が同時に生まれます。

急増を先に読む配車

注文の流れとエリアのシグナルを重ね、急増を予測してライダー配置と調理開始のタイミングを先に提案する設計です。

Ontology

ORDER

91%

relation coverage

Data schema

Data schema

Data schema

RIDER

pre-positions

ZONE

rebalances

KITCHEN

preps

配車ストリーム

Stream

relations mapped in realtime

DEVICE

LOG

TIME

STATUS

DV-SG04-K1

[ETA] 遅延リスクを検知、区間3

18:38:19

WARN

DV-KT02-P7

[注文 → キッチン] 最適調理開始を連動、12分

18:40:30

LINK

DV-SG04-K1

[ライダー → ゾーン] 事前配置を提案、ゾーン4

18:41:52

LINK

DV-SG04-K1

[急増] 注文急増予測 92%、19:00

18:42:11

WARN

DV-SG04-K1

[ゾーン → ライダー] 再配置を確定

18:32:44

LINK

DV-KT02-P7

[配車] 本日3,924件を判断

18:35:02

INFO

DV-SG04-K1

[急増] 注文急増予測 92%、19:00

18:42:11

WARN

欠品は倉庫ではなく 構造から始まる

物流の核心は、欠品前に動くことです。

しきい値割れの検知遅れ

しきい値割れの在庫が出庫時に発覚し、緊急発注につながります。

配車とドックの非同期

車両の到着時刻とドックの荷役スロットが別々に管理され、ドライバーとドックの両側に待機が積み上がります。

手作業承認のボトルネック

補充発注の起案が何人もの手を経て遅れ、そのぶんリードタイムが伸びます。

欠品の前に動く補充と配車

在庫・車両・ドックの状態をまとめて読み、欠品の前に補充を起案。人が承認するポイントも一緒に設計します。

Ontology

STOCK

87%

relation coverage

Data schema

Data schema

Data schema

ROUTE

matches

DOCK

loads

STAFF

handles

オペレーションストリーム

Stream

relations mapped in realtime

DEVICE

LOG

TIME

STATUS

LG-FL08-T2

[車両] 稼働率87%

09:05:21

INFO

LG-FL08-T2

[ルート → ドック] 積み込みスロットをマッチング、ドック04

09:08:55

LINK

LG-WH01-D4

[補充] 自動発注を起案、承認待ち

09:12:12

LINK

LG-WH01-D4

[在庫] SKU-1042 しきい値割れ

09:12:40

WARN

LG-FL08-T2

[ドック → 人員] 荷役作業を割り当て

08:58:47

LINK

LG-WH01-D4

[入庫] パレットをスキャン、Cゾーン

09:01:03

INFO

LG-WH01-D4

[在庫] SKU-1042 しきい値割れ

09:12:40

WARN

空き棚は、売上が 消えていく瞬間

リテールの核心は、棚が空いている時間です。

欠品の発見遅れ

空き棚の確認はスタッフの巡回だけ。空いている間の販売機会をそのまま逃します。

発注と需要の分断

週末やプロモーションで変わる需要が発注に反映されるのが遅く、過剰と欠品が交互にやってきます。

陳列優先度の不在

どの棚から埋めるかの基準がなく勘で決まり、そのぶん動線と時間が無駄になります。

空き棚に最初に気づく運営

棚・需要・発注をひとつの構造でつなぎ、欠品を早期に検知して補充と発注が途切れない設計です。

Ontology

SHELF

89%

relation coverage

Data schema

Data schema

Data schema

DEMAND

forecasts

STAFF

restocks

PRICE

drives

ストアストリーム

Stream

relations mapped in realtime

DEVICE

LOG

TIME

STATUS

RT-DM01-Q9

[予測 → 発注] 自動起案を作成

11:19:52

LINK

RT-DM01-Q9

[需要] 週末の上振れ予測 +18%

11:20:15

INFO

RT-ST03-A3

[補充 → スタッフ] 作業を割り当て、到着まで3分

11:23:48

LINK

RT-ST03-A3

[棚] 空きスロットを検知、3番通路

11:24:09

WARN

RT-DM01-Q9

[価格 → 需要] プロモ影響を連動

11:10:22

LINK

RT-ST03-A3

[棚] 補充完了、B4スロット

11:15:36

INFO

RT-ST03-A3

[棚] 空きスロットを検知、3番通路

11:24:09

WARN

遅延は道路の上だけで 起きるのではない

ラストマイルの核心は、遅延後の対応スピードです。

ルート再設計の遅れ

渋滞にはまってから迂回路を探し始め、1件の遅延が後続の配送全体に広がります。

お客様への案内の空白

遅延の連絡がお客様に届くのが遅く、問い合わせとクレーム対応に時間が奪われます。

引き継ぎ追跡の分断

ハブを移るたびに記録が途切れ、紛失や誤配送が起きても原因を遡れません。

遅延のシグナルで引き直されるルート

交通と配送状況をリアルタイムに読み、ルートを引き直し、お客様への案内までひとつの流れでつなぐ設計です。

Ontology

ROUTE

86%

relation coverage

Data schema

Data schema

Data schema

DRIVER

follows

TRAFFIC

affects

CUSTOMER

notified

配送ストリーム

Stream

relations mapped in realtime

DEVICE

LOG

TIME

STATUS

LM-IC03-V5

[交通] 前方渋滞、区間7

10:58:56

WARN

LM-IC08-Q2

[荷物] 引き継ぎスキャン、ハブ2

11:01:19

INFO

LM-IC03-V5

[遅延 → お客様] 先回りの案内を連動

11:04:40

LINK

LM-IC03-V5

[ルート] リアルタイム再設計を適用

11:05:12

INFO

LM-IC03-V5

[配送] 完了証明を取得、時間内

10:49:08

INFO

LM-IC08-Q2

[ドライバー → ルート] 動線最適化をマッチング

10:54:31

LINK

LM-IC03-V5

[ルート] リアルタイム再設計を適用

11:05:12

INFO

導入をご検討中なら、

AI HubはNEXTPAYの、オフライン産業向けAI実行プラットフォームです。現場で運営データを取得し、Ontologyでデータに関係と意味を与え、産業の文脈を知るエージェントを構成して、その判断が実際の運営の行動につながるよう設計されています。決められた機能一覧から選ぶ製品ではなく、各現場が自らの運営方式に合わせてAIを設計・運用できる構造を提供します。

多くのツールは記録と参照で止まります。何が起きたかは分かっても、次に何をすべきかは人に委ねられたまま。AI Hubは散在するデータをひとつに編み、AIが現場の文脈を理解したうえで、数字ではなく次の行動を示すよう設計されています。

はい。多くのAIは整理済みのデータを前提にしますが、オフラインの現場にはそれがないことがほとんどです。AI Hubは記録されていない箇所に収集デバイスを置き、稼働中のシステムからデータを引き込み、パートナーが持つデータをつなぎます。先にデータを整えていただく必要はありません。

AI Hubは特定業種向けのツールではなく、複数の産業で機能するよう設計された構造です。Ontologyはそのままに、産業別の判断基準とエージェントだけを差し替える方式のため、産業が変わってもゼロから作り直す必要はありません。

すべてを任せる設計にはしていません。どの決定を自動で実行し、どの決定を人の承認後に行うかは、現場の条件に合わせて一緒に設計します。自動化の範囲は現場が決める、それが原則です。

はい。置き換えではなく、いまお使いのシステムの上に運営レイヤーを重ねる方式です。一箇所から始めて検証し、全体へ広げられます。

まず運営環境の診断から始めます。どんなデータがすでに蓄積されているか、どのシステムをお使いか、どの判断が繰り返し人の手を経ているかを確認し、どのレイヤーから適用するかを一緒に決めます。現場を理解する専門家が、導入設計から伴走します。

私たちの仕事

複雑な運営を、

シンプルな実行へ。

現場で働くすべての人に、

より良い結果を生むAIの判断を。