生産スケジューラーFLEXSCHEは工場の計画を立てるツールなのですが、以前、席替えアプリを作ったように工場以外の計画もモデリングさえできてしまえば立案することができます。今回は私の趣味であるトレイルランニングのレースのプランをFLEXSCHEを使って立ててみることにします。

ただ、自分で一から全部のデータを入力するのもなかなか大変です。そこで、FLEXSCHE MCP Serverを通してAI（Codex GPT-6.1 Sol）に手伝ってもらいます。私は口を出すだけでデータやスケジューリングルールを作成するのはAI。果たして工場とは畑違いのトレランの計画をAIが作成することができるのでしょうか。

題材は、私が2026年6月に走ったKagaSpa Trail 100K。加賀、山中温泉がスタート・ゴールで山を登ったり下りたりしながら約100km進むトレランレースです。

実際に走ったレースを題材に良いプランが立てられるのかを検証します。

ちなみにレース当日は雨で山道はドロドロ、ツルツルで、レースは大変なものになりましたが、そんな事情は当然プランには考慮されていません。

まずは山をモデリング

プロジェクトを作成してそのフォルダでAIを起動します。そこからレース用のデータやルールを一から組み立てていきます。AIに伝えるのは、例えばこんな内容です。

私「公式GPXを使って、エイドで区間を分けてください。休憩時間も入れて。」

AI「区間ごとの距離と標高差を整理して、移動と休憩の工程を作ります。」

私「県民の森にはデポバッグがあります。そこは20分休みます。」

AI「では、その休憩と補給食の受け取りを計画に入れます。」

※やり取りは一部要約・再構成しています。

GPXはコースの位置や標高が入ったファイルです。デポバッグはあらかじめ預けておける荷物でそれに着替えや追加の補給食を入れておくことができます。これをもとに、AIと相談しながらエイド（飲食物が提供される場所）までの区間を「資源」、移動や休憩を「工程」、レース全体を「オーダー」としてモデリングしてFLEXSCHEに登録してもらいました。こんな風にAIと私の共同作業で進めていきます。工場でないので見慣れないワードが多いですが、意外とあっさりモデリングできちゃってます。

移動時間は距離、上り下り、路面の係数から計算します。GPXには路面の種類までは入っていないので、そこはひとまず仮の係数です。これに個人の能力を加味することでレースタイムが推測できるわけですが、過去のレースの情報を与えることでAIが割り出してくれました。

係数や計算方法はFLEXSCHE側に持たせているので「休憩を5分増やしたら？」とか「能力をあげたら？」といった変更もFLEXSCHE上で入力して再計算できます。

いつものガントチャートですが、並んでいるのは機械ではなく山の区間とエイドです。

補給は在庫問題？

長いレースでは、時間だけでなく補給も重要です。走って消費したカロリーをエイドや走行中の補給でカバーするのですが、その補給の計画まで作ってしまおう、ということでAIに注文を追加します。

私「消費したカロリーはエイドで100〜200kcalくらい補給して、残りは持っている補給食を食べます。」

AI「持っている食料と、摂取したエネルギーは分けて扱いましょう。」

私「食べる時刻は固定せず、安全在庫を切るタイミングで補充してください。」

補給食を持っているだけではエネルギーになりません。食べて初めて補給になります。

そこで、未摂取の「補給食」と、計算用の「体内エネルギー」を別の品目にしました。走るとエネルギーを消費し、一定の下限に達する前に100kcal分を補充する。そのタイミングを、FLEXSCHEの補充オーダー生成メソッドで求めます。材料の補充に使う仕組みで、自分の補給を計画してしまおうというわけです。

エイドでの摂取を150kcalとした今回の条件では、補給食を食べる作業が26回生成されました。持ち物は、エイドの補給が少なかった場合と予備も見込み、スタートで21個、県民の森のデポバッグに12個。食べる数と準備する数も、ちゃんと別です。

実際には上りと下りではカロリー消費が違ったり個人差もあるのでこのまま実際のレースでは使えませんが、目安にはなりそうです。

いいプランを作るには？

ここまで読むと、AIにお願いすれば全部すんなり完成するように見えるかもしれません。実際には、途中で相談してデータを整理したり、モデルを変えたり、エラーを調べたりもしています。

私「リスケしたところエラーが出るのですが、原因わかりますか？」

AI「時間の実績はありますが、補給の実績数量はありません。計画の補給計算に、その状態が混ざっています。」

私「では、計画用のルールと実績反映用のルールを分けましょう。」

レース結果のGPSログから分かるのは時間や位置で、食べた補給食の数ではありません。計画の仮定と実測した情報を混ぜないよう、「計画作成」と「実績反映」のルールを分けました。計画時にはFLEXSCHE上の対象実績をクリアして計算し、実績反映時には保存してある解析データから時間実績を取り込みます。

こんなふうに、作って、見て、注文を追加して、また試す。AIが用意したものを私が確認して、「そこは違う」「こうしたい」を伝えていきます。最初から完璧な仕様書を書かなくても、会話しながら形にできるのが面白いところですね。

ルールも対話しながら作成。計画と実績を切り替えて確認できるようにしました。

プランとレース結果を比較してみる

実際のウェーブスタートに合わせて、開始は18時35分。時計のGPSログを解析し、エイド付近の低速・停止から滞在時間を推定して、移動11区間と休憩10区間の時間実績を取り込みました。結果を並べると、こんな感じです。

上のバーが計画で、下のバーが実績です。

計画より1時間5分52秒早くゴールした計算です。過去のレースの実績からの予想なので私が成長した、ということにしておきたいところですが、区間ごとに見ると、計画より時間がかかっている区間もあります。全体のタイムだけを見るより、「どこで差がついたのか」が分かるほうが、次の計画に役立ちそうです。ということでAIにレポートを作成してもらいます。

計画と実績を区間ごとに比較。合計だけでは見えない差も確認できます。こういう分析をサクッと行ってくれるのもAIのいいところですね。

分析の結果、1時間5分52秒のうち39分7秒、約6割がエイドでの滞在時間で短縮したものでした。食べ物に後ろ髪をひかれながらもそれを断ち切って出発する、これこそがタイム短縮のカギだったわけですね。本人としては走力アップの努力の結果であってほしかったですが。

今回は工場ではなく山を舞台に、AIとの会話からデータとルールを作り、FLEXSCHEで計画し、実績と比べるところまで試してみました。生産スケジューラも、何を資源や工程として扱うか考えると、案外いろいろな計画に使えますね。