AIの「最適解」が現場で使えない

配送、生産、要員配置などで、AIに「最適な計画を作って」と依頼する場面が増えています。条件の整理や選択肢の比較には、有用な支援になります。

ただし、すべての情報がそろった後に作るよい計画と、情報が不完全な時点で実行できる計画は違います。

以下は、計画業務の設計上の注意を説明する架空の例です。実際のAIが不適切な計画を出して損失を生んだという報告ではありません。

1．推進の現場で起きていること

過去データではよい結果。でも、翌週の計画には使えない

ある会社で、過去の配送実績を使って配車計画を試したとします。最終的な荷量、納品先、時間指定がそろったデータから、効率のよい計画ができました。

しかし、実際に車両を確保する時点では、一部の出荷がまだ確定していません。判断を待てば車両が足りず、早く決めれば後から変更が入ります。

さらに、費用を下げる案でも、現場では守るべき納品条件や作業上の制約がありました。

過去の確定情報を使ってよい結果が出ても、当時の判断時点で同じ案を作れたとは限りません。

2．壁が生まれる理由

「最適」の意味が一つだと思っている

費用を最小にしたいのか、納期を守りたいのか、急な変更に対応する余裕を持ちたいのか。目的が違えば、望ましい案も変わります。

安全や契約上の条件は、単純に点数へ換算して費用と交換してよいものではありません。必須条件と、調整可能な希望を分けます。

情報が確定する時刻を見ていない

データに値があることと、意思決定時点でその値を知ることができたことは別です。後から判明した情報を混ぜると、実運用より有利な条件で評価してしまいます。

一度で完成する出力を求める

実際の計画業務は、暫定配置、確定、変更、再調整の連続です。最終計画だけを出させると、途中で何を判断し、何を待つかが抜けます。

3．どう進めるか――目的・制約・時点を一組にする

「未確定」「未入手」「入力漏れ」も区別します。未来のためまだ決まらない情報と、取得手順の不備で欠けている情報では、対処が違います。

未確定の値をAIに埋めさせても、確定した情報にはなりません。 仮定を置く場合は、元の情報と分け、変わった場合の影響を示します。

4．検証では「当時分かっていた情報」を使う

過去の案件で試す際は、最終結果だけでなく、判断時点の情報を再現します。再現できない場合は、その限界を明記します。

1. 判断を行う時点を決める
2. その時点で入手していた情報だけを入力にする
3. 暫定の計画と、未確定部分への対応を作る
4. 後から情報が追加・変更された状況を順に試す
5. 最終結果だけでなく、変更回数、調整負担、制約違反を確認する

比較する人の計画とAIを使った計画にも、同じ情報と条件を与えます。AI側だけに後日の確定情報を渡してはいけません。

見たいのは「すべて分かっていれば何ができたか」だけでなく、「分からない中でどう判断できるか」です。

5．暫定判断と、再判断の条件を設ける

例えば、確定分は先に配置し、未確定分には余裕や候補を残す方法があります。どの方法が適切かは、変更費用、必要な準備時間、業務の制約によって変わります。

一つの案に固執せず、複数の状況でどこまで成立するかを確かめます。頻繁な再計算が現場の変更負担を増やさないかも見ます。

6．生成AIの役割と、厳密な検証を分ける

生成AIは、業務条件の言語化、制約の抜けの洗い出し、計画案の説明、確認質問の整理に使えます。

一方、複雑な組合せや厳密な制約を満たす必要がある場合、文章として自然な計画が出たことを、計算上の最適性や実行可能性の証明にしてはいけません。適切な計算・最適化手法と、業務側の検証を組み合わせます。

人間は目的と制約を決め、入力を確認し、例外を判断します。AIの説明だけでなく、制約を満たしているかを別途点検できるようにします。

「AIの最適解」ではなく、「どの条件で検証した計画か」を説明できることが重要です。

7．現場ですぐ使える「虎の巻」

• 最適化したい目的と評価方法を明示した
• 必須制約と調整可能な条件を分けた
• いつ何を決めるかを整理した
• 判断時点で利用できる情報を確認した
• 未確定・未入手・入力漏れを区別した
• 後日分かった情報を検証の入力へ混ぜていない
• 情報追加・予定変更・実行不能のケースを試した
• 再判断、承認、例外対応の担当がいる
• 生成AIの説明と、計算・現場の検証を分けた

8．すぐ試せるプロンプト

計画の前提を整理する

以下の計画業務について、すぐに最適案を出さず、判断条件を整理してください。
【改善したい成果】
【判断時点と実行までの時間】
【必須制約・調整可能な条件】
【その時点で利用できる情報】
【未確定・未入手の情報】

目的、制約、仮定、不足情報を分け、確認質問を出してください。
暫定判断、更新、実行不能時の対応の設計案も示してください。
後日判明した情報を、当時知っていたと扱わないでください。
計算や実行可能性を検証していない案を「最適」と断定しないでください。

検証計画を点検する

以下の検証方法について、当時の判断時点では使えなかった情報が
混ざっていないかを点検してください。
比較条件、制約の確認方法、情報追加時の再判断、変更負担、
例外時の人の対応を整理してください。
再現できない条件と、結果を一般化できない範囲を示してください。

9．実践してみる

架空の配置計画を用意し、最初は確定分だけ、次に追加情報、最後に予定変更を渡します。

1. 各時点で何を決め、何を保留するかを書く
2. 仮定と必須制約を分ける
3. 情報が変わった際に見直す範囲を決める
4. 最終確定情報を最初から使った結果と比較する
5. 実際の判断時点で使える計画だったかを説明する

成功の基準は、後知恵で一番効率のよい案を出すことではありません。情報が不完全でも、条件を守りながら判断と更新ができることです。

まとめ｜壁を越えて、AI活用を業務改革へ

現場の計画は、確定情報だけでできていません。不確実性を隠さず、扱える形にすることが、AIを実務へつなげる人間の仕事です。