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]
現場の文脈の上で、より良い判断と即時の実行を支えます。
意思決定ツールの不在
[lack of decision making tool]
私たちの解き方
データ収集から問題解決まで
記録されていなかった現場データを取得し、稼働中のシステムのデータをひとつに集めます。
データに関係と意味を与え、現場がどう回っているかをAIが理解できるようにします。
産業の文脈を知るエージェントが、いま何をすべきかを判断します。
判断が実際の運営の行動につながるよう、人が確認するポイントを一緒に設計します。
データ収集
ひとつの汎用AIではなく、
機能ごとの専門家を送り込む。
データ収集・処理から、
AIエージェントの業務遂行まで。
AI HUBターゲットアーキテクチャ、12レイヤー
顧客体験、知能組織、共通記憶、実行・運用基盤を分離した拡張型構造です。
L1
チャネル・顧客体験
- Web/App
- Chat
- Dashboard
- Report
- Notification
各レイヤーは独立した責任を持ちます。
顧客体験
店主と本部が見るページと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
CC-MV1-2X4J
[決済] 承認、₩12,500
14:31:40
CC-MHYYSSPF
[注文 → 在庫] 豆の在庫引き落とし連動
14:31:55
CC-MV1-2X4J
[注文] アメリカーノ(HOT) 受付
14:32:07
CC-MV1-2X4J
[人員 → 注文] ピーク人員マッチング
14:20:05
CC-MRLNBYXL
[在庫] 豆の残量20%を検知
14:22:18
CC-MV1-2X4J
[注文] アメリカーノ(HOT) 受付
14:32:07
注文の急増は 前触れなしには来ない

デリバリーの核心は、急増前の備えです。
急増予測の不在
注文の急増は過ぎてから確認され、ライダー確保も調理準備もいつも遅れて始まります。
調理と配車のズレ
調理完了とライダー到着の時刻が噛み合わず、料理が冷めるか、ライダーが待たされます。
エリア別需要の偏り
エリアごとの需要変化をリアルタイムに読めず、ライダーが余る区域と足りない区域が同時に生まれます。
急増を先に読む配車
注文の流れとエリアのシグナルを重ね、急増を予測してライダー配置と調理開始のタイミングを先に提案する設計です。
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
DV-KT02-P7
[注文 → キッチン] 最適調理開始を連動、12分
18:40:30
DV-SG04-K1
[ライダー → ゾーン] 事前配置を提案、ゾーン4
18:41:52
DV-SG04-K1
[急増] 注文急増予測 92%、19:00
18:42:11
DV-SG04-K1
[ゾーン → ライダー] 再配置を確定
18:32:44
DV-KT02-P7
[配車] 本日3,924件を判断
18:35:02
DV-SG04-K1
[急増] 注文急増予測 92%、19:00
18:42:11
欠品は倉庫ではなく 構造から始まる

物流の核心は、欠品前に動くことです。
しきい値割れの検知遅れ
しきい値割れの在庫が出庫時に発覚し、緊急発注につながります。
配車とドックの非同期
車両の到着時刻とドックの荷役スロットが別々に管理され、ドライバーとドックの両側に待機が積み上がります。
手作業承認のボトルネック
補充発注の起案が何人もの手を経て遅れ、そのぶんリードタイムが伸びます。
欠品の前に動く補充と配車
在庫・車両・ドックの状態をまとめて読み、欠品の前に補充を起案。人が承認するポイントも一緒に設計します。
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
LG-FL08-T2
[ルート → ドック] 積み込みスロットをマッチング、ドック04
09:08:55
LG-WH01-D4
[補充] 自動発注を起案、承認待ち
09:12:12
LG-WH01-D4
[在庫] SKU-1042 しきい値割れ
09:12:40
LG-FL08-T2
[ドック → 人員] 荷役作業を割り当て
08:58:47
LG-WH01-D4
[入庫] パレットをスキャン、Cゾーン
09:01:03
LG-WH01-D4
[在庫] SKU-1042 しきい値割れ
09:12:40
空き棚は、売上が 消えていく瞬間

リテールの核心は、棚が空いている時間です。
欠品の発見遅れ
空き棚の確認はスタッフの巡回だけ。空いている間の販売機会をそのまま逃します。
発注と需要の分断
週末やプロモーションで変わる需要が発注に反映されるのが遅く、過剰と欠品が交互にやってきます。
陳列優先度の不在
どの棚から埋めるかの基準がなく勘で決まり、そのぶん動線と時間が無駄になります。
空き棚に最初に気づく運営
棚・需要・発注をひとつの構造でつなぎ、欠品を早期に検知して補充と発注が途切れない設計です。
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
RT-DM01-Q9
[需要] 週末の上振れ予測 +18%
11:20:15
RT-ST03-A3
[補充 → スタッフ] 作業を割り当て、到着まで3分
11:23:48
RT-ST03-A3
[棚] 空きスロットを検知、3番通路
11:24:09
RT-DM01-Q9
[価格 → 需要] プロモ影響を連動
11:10:22
RT-ST03-A3
[棚] 補充完了、B4スロット
11:15:36
RT-ST03-A3
[棚] 空きスロットを検知、3番通路
11:24:09
遅延は道路の上だけで 起きるのではない

ラストマイルの核心は、遅延後の対応スピードです。
ルート再設計の遅れ
渋滞にはまってから迂回路を探し始め、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
LM-IC08-Q2
[荷物] 引き継ぎスキャン、ハブ2
11:01:19
LM-IC03-V5
[遅延 → お客様] 先回りの案内を連動
11:04:40
LM-IC03-V5
[ルート] リアルタイム再設計を適用
11:05:12
LM-IC03-V5
[配送] 完了証明を取得、時間内
10:49:08
LM-IC08-Q2
[ドライバー → ルート] 動線最適化をマッチング
10:54:31
LM-IC03-V5
[ルート] リアルタイム再設計を適用
11:05:12
導入をご検討中なら、
AI HubはNEXTPAYの、オフライン産業向けAI実行プラットフォームです。現場で運営データを取得し、Ontologyでデータに関係と意味を与え、産業の文脈を知るエージェントを構成して、その判断が実際の運営の行動につながるよう設計されています。決められた機能一覧から選ぶ製品ではなく、各現場が自らの運営方式に合わせてAIを設計・運用できる構造を提供します。
多くのツールは記録と参照で止まります。何が起きたかは分かっても、次に何をすべきかは人に委ねられたまま。AI Hubは散在するデータをひとつに編み、AIが現場の文脈を理解したうえで、数字ではなく次の行動を示すよう設計されています。
はい。多くのAIは整理済みのデータを前提にしますが、オフラインの現場にはそれがないことがほとんどです。AI Hubは記録されていない箇所に収集デバイスを置き、稼働中のシステムからデータを引き込み、パートナーが持つデータをつなぎます。先にデータを整えていただく必要はありません。
AI Hubは特定業種向けのツールではなく、複数の産業で機能するよう設計された構造です。Ontologyはそのままに、産業別の判断基準とエージェントだけを差し替える方式のため、産業が変わってもゼロから作り直す必要はありません。
すべてを任せる設計にはしていません。どの決定を自動で実行し、どの決定を人の承認後に行うかは、現場の条件に合わせて一緒に設計します。自動化の範囲は現場が決める、それが原則です。
はい。置き換えではなく、いまお使いのシステムの上に運営レイヤーを重ねる方式です。一箇所から始めて検証し、全体へ広げられます。
まず運営環境の診断から始めます。どんなデータがすでに蓄積されているか、どのシステムをお使いか、どの判断が繰り返し人の手を経ているかを確認し、どのレイヤーから適用するかを一緒に決めます。現場を理解する専門家が、導入設計から伴走します。

私たちの仕事
複雑な運営を、
シンプルな実行へ。
現場で働くすべての人に、
より良い結果を生むAIの判断を。