01
手作業の計画がすぐ崩れる
シフト、訪問、配送、注文が変わるたびに、誰かが予定を組み直している。
数理システム開発
人が毎日考えている計画を、システムに考えさせる
シフト、訪問予定、配車、工程、担当者割り当て。Excel と熟練者に依存している複雑な判断を、数理モデルに変え、現場で使える Web・アプリとして実装します。
最短2週間で試作
Web・iOS・Android
現場独自ルールに対応
制約ソルバー
最適化済み · 0.38秒
訪問スケジュール / 6月20日
最短2週間で試作
青木
伊藤
佐藤
林
09:00
V-012北 / 介護
V-008東 / リハビリ
11:00
V-003中央 / メンタル
V-021西 / 児童対応
13:00
V-017北 / リハビリ
V-026南 / メンタル
制約違反
0件
総移動時間
84分
割り当て率
100%
min Σ cᵢxᵢ + λΣ vⱼ
s.t. Ax ≤ b
解く課題
業務が制約だらけになると、普通のシステム開発では核心を外します。
Finite Field が扱うのは、単純なフォーム型システムでは足りず、汎用 SaaS にも乗りにくい制約の多い業務です。
02
ルールが見えにくい
スキル、容量、場所、納期、優先順位のルールが、表計算と人の記憶に分散している。
03
複雑さを熟練者が吸収している
同じデータが Excel、チャット、システムを行き来し、最後は同じ熟練者が修正している。
04
システムが判断していない
システムはあるが結果を記録するだけで、難しい判断はシステムの外で起きている。
答えは、見た目のよい画面だけではありません。判断し、説明できるモデルです。
私たちはこれを数理システムとして扱います。判断をモデル化し、制約を検証し、結果を説明し、そのロジックを中心に業務 UI を作ります。
業務ルールからシステムモデルへ
同じ判断が繰り返される業務には、数理の層が必要です。
Finite Field は、画面を先に並べるのではなく、現場の判断を変数、制約、目的、説明要件へ分解してからシステムを設計します。
変数
担当者、訪問、設備、注文、車両、時間帯、スキル、容量、日付を明示的なデータにします。
制約
スキル、納期、場所、負荷上限、優先順位、対応不可時間、業務例外をルールとして書き出します。
目的
移動を減らす、負荷をならす、希望一致を高める、納期を守る、判断のトレードオフを見える化します。
画面一覧からではなく、判断変数、制約条件、目的、説明要件を先に定義します。その上で、現場が運用できるプロダクトへ落とし込みます。
割り当てデモ
制約の多い予定が、数理モデルになるとどう変わるかを試せます。
このブラウザデモは説明用です。このページ外へデータを送信しません。
訪問スケジュールプランナー
目的を変えてプランナーを実行できます。
手作業プラン: 2件の制約に調整が必要
サンプル: 9訪問 / 5担当者
対応領域
汎用的な画面分類ではなく、判断そのものを中心に作ります。
シフト、訪問、配車、工程、担当者割り当てなど、毎日やり直しが起きる計画業務を中心に扱います。
勤務計画
シフト・人員配置最適化
スキル、時間帯、休憩ルール、公平性を、確認できる勤務計画へ落とし込みます。
現場業務
訪問・巡回スケジュール
移動、スキル適合、希望担当者、時間枠を見ながら訪問や現場作業を割り当てます。
ルート
配車・配送ルート計画
容量、順序、サービス条件の制約下で、車両、配送、立ち寄り先を計画します。
マッチング
割り当て・マッチングシステム
人、案件、注文、資源を、説明できる優先順位と例外でマッチングします。
進め方
まずモデル、次にプロトタイプ。適合が見えてから本番へ進みます。
本番システムに進む前に、モデルを検証できるだけの小さな範囲に絞って始めます。
01
ルールとデータを棚卸しする
現在の表計算、ルール、実例、例外を集め、実際に判断が起きている場所を特定します。
02
モデルを作る
業務を変数、制約、目的、説明要件に分解し、レビューできる形にします。
03
運用をプロトタイプ化する
モデルの周りに小さな画面を作り、担当者が触りながら不足ルールを見つけられるようにします。
04
本番開発を計画する
データ、モデル、使い勝手、リスク前提が見えてから、本番開発の範囲を決めます。
最初の一歩
小さく始めて、本番システムに進むか判断します。
不確実な業務は、小さなプロトタイプから始めます。ルールをモデル化し、小さな UI を作り、本番開発する価値があるロジックかを確認します。
プロトタイプ 29.8万円から
プロトタイプは実現可能性と範囲を明らかにするものです。業務効果を保証するものではありません。
ルールとデータの棚卸し
小さな最適化・マッチングモデル
触れる業務プロトタイプ
リスクと前提を含む次工程提案
研究からプロダクトへ
モデル化、検証、運用
NPA
検証
プロダクト
Math Lab
研究を実装の近くに置きます。
Math Lab は、数理モデル、証明志向の考え方、ソフトウェア提供をつなぐ場所です。トップでは方向性を示し、技術的に深く読みたい人を NPA などへ送ります。
研究コンテンツは設計判断を支えるものであり、本番検証や形式証明ツールの代替として位置づけるものではありません。
NPA を読むFAQ
初回相談前によくある質問
業務判断をシステム化すべきか検討しているチーム向けに、初回相談前の疑問を整理します。
どのような業務を数理システムにできますか。
スケジューリング、割り当て、配送ルート、マッチング、生産計画など、多くの制約を扱う業務が対象です。何を作るかを決める前に、まず業務ルールを小さなモデルにします。
業務効果は保証されますか。
いいえ。プロトタイプやデモは、実現可能なロジック、必要なデータ、使い勝手を確認するためのものです。コスト削減、売上向上、その他の業務効果を保証するものではありません。
要件が固まる前でも始められますか。
はい。最初は、データ確認、ルール整理、触れるプロトタイプまでの小さな範囲で始めることが多いです。モデルと運用適合が見えてから本番開発に進みます。