数理最適化の新時代到来 ～最適化→予測でDXは加速する～

数理最適化とは？

数理最適化は、最適なアクションを決定するための方法論です。

近年、注目を集めてきた機械学習とは大きく異なります。機械学習は主に未来の予測値を算出するのに使われる方法ですが、数理最適化はその予測値を使って、シミュレーションを行い、意思決定を自動化します。すごくざっくり言うと、明日の降水確率を算出するのが機械学習で、傘を持って行くかどうかを決めるのが数理最適化です。

「明日、60%の確率で雨が降ります」だけでは、その後どうすれば良いかはまだ人の判断が残りますが、数理最適化は「傘を持って歩いた場合」「車で移動した場合」のそれぞれの場合で例えば1日の満足度を計算したうえで、「車で移動すべき」という判断をします。

このように、数理最適化は機械学習プロジェクト、およびビジネスの意思決定を加速させる非常に強力なツールです。

※数理最適化の意味やビジネス活用事例については、以下の記事で紹介しているのであわせてご覧ください。

【関連記事】数理最適化とは？機械学習・AIとの違いやビジネス活用事例をわかりやすく解説

■「数理最適化」に関する記事

• データをアクションにつなげる技術「数理最適化」とは？
• 「逆問題解析」～人間が受け入れやすい 、自然な解釈を生む数理最適化の新たな活用法～
• 意思決定を支援する技術「数理最適化」の最前線～BrainPad DX Conference 2022～実践セミナー
• 配送ルート最適化プロジェクトの現場実装

ビジネスにおける応用例としては、例えば下記が挙げられます。

• 倉庫から顧客に荷物を届けるための、トラックの配送計画
• Web、ポータルサイトを統合した年間の広告予算の配分計画
• アミューズメント施設におけるチケットの発券計画
• 顧客の注文を満たすための、工場ラインの生産と輸送計画
• 必要な製品の性能を満たすために、無駄な実験を省く、効率的な実験計画
• 需要予測を元に、人員の配置を組むシフト計画
• 需要予測を元に、発注をかけた場合の、在庫数の削減計画
• 需要予測を元に、売上を最大化するための、商品の価格計画
• 優良顧客数を最大化するための、新規顧客の獲得計画

上記でもまだまだ抽象度高く、トラックの配送計画1つをとっても、バリエーションは多くあります。顧客に時間指定がある場合や、途中で荷物を積み込む場合、臨時で配車する車両の考慮など、顧客の業務は様々です。配送ソリューションパッケージのようなパッケージ化されたサービスは昔からありましたが、そういったパッケージで世の中の全ての業務課題を解決することは私の経験上、不可能だと思います。

 こういった点がデータサイエンティストの腕の見せ所で、顧客の業務課題をオーダーメイドで数理最適化問題に落とし込み、実装する必要があります。

上に挙げた例は全て最後に「計画」という文言がついていることに注目してほしいと思います。数理最適化は「計画作成業務の自動化」といって差し支えありません。未来の意思決定をするということは、計画を立てるということです。そこで、ただ闇雲に計画を立てるのではなく、「目的」と「制約」を考慮した計画を立てます。「目的」とは、配送の例で言えば、「ドライバーの総稼働時間を減らしたい」、予算配分の例で言えば、「コンバージョン数を増やしたい」等です。複数の目的を設定することもできます。

　次に制約とは、「顧客の時間指定範囲に訪問する」「使える予算は最大で1000万円まで」といった業務上の条件です。こういった制約条件を満たした中で、目的が最も良くなるように計画を立てます。目的とはまさに企業のKPIに該当します、KPIを改善したいという課題は世にあふれているため、数理最適化の適用範囲は世にあふれていると言えます。

　これまでは、配送計画、在庫計画、実験計画といったどちらかというと現場のオペレーションの業務改善に使われて来ましたが、これからは経営における四半期や年間の予算計画、各部署の妥当な売上目標値の算出計画など、より上位層の経営計画にも使われていくと思われます。

　ここで少し、技術的な視点で数理最適化を説明させてください。

　よく数理最適化と機械学習は混同して理解されており、「説明変数と目的変数は何か？」と聞かれることがあります。数理最適化においては、説明変数、目的変数といったものはありません。その代わりとして、上で述べた「目的（関数）」と「制約（条件）」があります。これらを数式で表現し、それらをコンピューター上で数値的に解くことで、計画表が自動で作成されます。

　目的関数と制約条件の数に限りはありませんが、優先度の高いものから入れていくことが良いです。配送の例ではドライバーの配送時間の他に、トラックの総台数も考えられ、それらに優先順位をつけて目的関数として入力します。

　また、制約条件にはある店舗には、10時~12時の間にしか訪問できないというようなものは、不等式を用いて「10<x<12」のように入力します。

　その他にも、トラックの積載量や店舗の訪問順序等、様々な条件が考えられ、それらを全て数式で表現します。こうした数多くの制約条件を満たしつつ、目的関数を最小化するという複雑な方程式を解いた結果、あるトラックは店舗Aに9時30分、店舗Bに9時45分、店舗Cに10時05分…という計画ができあがることになります。

「2024年問題」で日本の物流になにが起きるのか、より深く知りたい方はこちらもご覧ください。

「アルゴリズム職人」に頼る必要がない、数理最適化の新時代の到来。

数理最適化というのは、実は機械学習が流行するはるか前から存在し、業務適用された事例もありました。しかし、機械学習ほど注目されなかった理由には、数理最適化の「高いハードル」がありました。

　1つ目は、従来のSIにおけるウォーターフォール開発といった「要件定義フェーズで要件を洗い出し、その後実装フェーズに移る」といった推進方法と非常に相性が悪かったことです。まず制約条件を、❝事前❞に❝全て❞洗い出すということが、なかなか難しいのです。システム企画の担当の方は現場のオペレーションにそこまで詳しくはないといった事情もあり得ます。次章でも述べますが、数理最適化は計画を出力するため、現場の方の感覚と合致するかというフィードバックが非常に重要です。そのフィードバックの過程で、抜け落ちていた制約条件や目的を、お客様自身が発見することがあります。そういった、はじめから完成品を定義するのではなく、インタラクティブに開発し、完成系をお客様と議論していく必要があるのです。

　2つ目は、ここが最も大きいとは思いますが、目的関数と制約式を方程式として表現できたとしてもその「方程式を解く」ことがいわゆる「アルゴリズム職人」にしかできませんでした。このアルゴリズム職人になるためのハードルが非常に高かったのです。

　加えてその職人が作成するプログラムコードは膨大で、それを周囲の人はなかなか理解できませんでした。また、アルゴリズムにバグがあるかどうかも、誰も判別できません。さらにアルゴリズム職人も「配送計画」の方程式には強いが、「予算計画」の方程式には弱いといった、課題毎にアルゴリズム職人が必要でした。

そういった汎用的なアルゴリズム職人がいないこと、いたとしても周囲が理解できないという理由から、数理最適化を実務で適用し運用していくことは非常に難しいものがありました。

　ところがここ数年で状況は大きく変わりました。「汎用ソルバー」の劇的な進化です。

　汎用ソルバーとは配送や予算といった、どんな問題にでも対応できるソフトウェア（ライブラリ）です。汎用ソルバー自体は以前から存在していましたが、現実のデータ量に対応できるものになかなか至っていませんでした。

　それが昨今、改善が進み、大規模な配送計画や予算計画でも、アルゴリズム部分は、わずか数百行程度のプログラムコードで完成し、かつ短い時間で解けるようになりました。

　汎用ソルバーを用いると、上に述べた顧客のフィードバックで新しい制約条件が見つかった際の対応も非常に柔軟に対応できます。これにより、インタラクティブに開発し、完成に近づけていく、いわゆるアジャイル開発法と非常に相性の良いものになりました。

　汎用ソルバーによって（アルゴリズム職人に、必ずしも頼る必要ではなくなりましたが）データサイエンティストの仕事がなくなったわけではありません。むしろデータサイエンティストの職務の幅が劇的に広がった（広げることができた）と感じています。

　データサイエンティストは汎用ソルバーの使い方を習得するだけで良いのです。わずか1,2ヶ月程度の学習期間があれば、アルゴリズム職人が出していた精度と同等の解の精度を汎用ソルバーで出すことができます。

　これにより、データサイエンティストは、よりお客様と会話して、新しい最適化問題を創り出すといった、よりビジネス寄りの視点や、使いやすいUIを開発して、お客様にいかに使ってもらうかを考えるといったシステム開発の視点も持てるようになり、よりクリエイティブな職務にシフトすることが可能になりました。

　「データサイエンティストは、1日中パソコンに向かって難しいアルゴリズムを書いている人」というイメージを持たれることは以前はありましたが、弊社で汎用ソルバーでプロジェクトを推進しているデータサイエンティストに関しましては、上で述べたような広範囲な視点で仕事ができており、職務の壁を取り払い、活躍している者が多い印象を受けます。

　これは私が大規模な配送計画作成のプロジェクトを担当していたときの話です。

　以前はアルゴリズム作成に数か月かかっていたものが、汎用ソルバーによりわずか数日で完成し、アルゴリズム部分のコードはわずか200行程度で完結しました。（汎用ソルバーがなければ、数千行の規模になると思われます。さらにチェックの工数も考えると、想像するだけで苦しさを感じます。）

　汎用ソルバーによって、データベースの設計や、アルゴリズムへのデータの受け渡し、お客様が見やすい帳票の出力、外部の地図APIとの連携、現場への適用、UIの設計といった、より広範囲な仕事に、データサイエンティスト自身が主軸となって、コンサルタントやエンジニアを巻き込み、進めることができました。開発スピードが一気に加速し、お客様の満足度も高まったと感じます。

　「数理最適化の新時代」が到来したといっても過言ではありません。もちろん全ての問題が簡単に解けるようになったとは言えませんが、ハードルは劇的に下がったことは間違いありません。

　今後もビジネス適用の範囲は広がっていくと感じます。

　ではここからは、汎用ソルバーを利用することを前提に、ビジネスで数理最適化を実施するための手順や、成功のためのポイントについて説明します。

ビジネスで実施するにあたって：フィードバックを元に改善していく大切さ

以下では汎用ソルバー（詳細は前編参照）を利用することを前提に、ビジネスで数理最適化を実施する際の手順や、成功のポイントについて説明します。

1.KPI（目的）と制約条件をできる限り洗い出す

　ここで言うKPIとは前編で述べたように、トラックの総稼働時間やコンバージョン数等、ビジネス的に最大化/最小化したい対象を意味します。　

　また、制約条件を洗い出している際には、この数値は予測しないといけないという状況に直面します。ここから「機械学習で予測する」という必要性が生じる場合があります。機械学習プロジェクトは、こういった最適化プロジェクトの副次的な要素としてはじめた方が上手くビジネスと直結します。そこから必要なデータを洗い出す、といった具体的なタスクも始まるのです。

2. 過去データでバックテストし、コストインパクトを算出する

　1で、KPIと制約条件を洗い出した後は、それを汎用ソルバーでモデリングします。ポイントは、過去データを用いることです。過去データでトライする理由は、「もし、意思決定が○○だったら、××円のコストインパクトがありました」を提示するためです。

　過去データでROIを算出し、アルゴリズムの良さを評価します。メッセージとしては上記の一文さえあれば十分で、込み入った資料を作成する必要もありません。KPIを過去値と汎用ソルバーの出力値で差を出して、その差を見れば良いのです。できれば、単価を掛けて金額に換算して出すと、企業の上位層の方にも響きやすいので良いと思います。

3. 現場のフィードバックをもらい、再実行する

　2で算出したインパクトは、1回目だと制約条件を全て洗い出せていないケースがほとんどです。例えば、インパクト値があまりにも現実とかけ離れている場合には、足りない制約条件がある場合が多いです。そこで、現場のオペレーション視点で計画が実行可能かどうかを判断する必要があります。そういった現場のオペレーションのフィードバックを元に、新しく制約条件を追加すると、当然インパクト値は下がってしまいますが、現場の方には響きます。

　こういった実装する制約条件のセンスも、データサイエンティストに問われる点で、「実装した制約をあえて抜く」こともあります。例えば、現場のオペレーション上の制約が業務改善側からすると必ずしも満たす必要がないルールとなっている場合があり、そのルールによってインパクトが抑えられているような状況では有効な対処法になります。こういった上位層と現場層の両者の満足度を高めていくことがモデリングの腕の見せ所で、仕事の面白い点でもあります。

4. 継続して使っていただけるようなダッシュボードを開発する

　数理最適化は2で述べたような経営層にビジネスインパクトを算出するだけに留まらず、現場のオペレーションをも支援するボトムアップツールです。

出した計画は、現場の方々に実行してもらわないと効果はありません。そこで、どういったデータを準備していただき、どういった形式で結果を表示するかといった設計が必要になります。

　例えば、顧客の時間指定や、予算制約の上限はユーザーが変更して何パターンかの計画を試したいという場合が多いです。そういった条件をいくつか変更して試したい場合には、無理にデータベースで数値を管理せず、お客様にエクセルファイルで条件の数値を入力していただき、それをアップロードしてもらう方が、使っていただきやすいというのが私の経験です。

　また、計算された計画表も画面で綺麗に表示するのも見栄えは良いのですが、エクセルファイルで帳票形式でダウンロードできる方が、クライアント企業様の社内でも展開されやすく、広まりやすいと感じます。

　こういった開発は、アプリケーション開発というと少し開発の規模が大きくなりがちなため、私は「ダッシュボード開発」と呼んだ方が良いと考えております。アプリケーション開発のような、機能要件を洗い出し外堀りを決めるのも大事ですが、よりプロジェクトの後半で良く、まずは制約条件の値を変更し、結果がどう変わるかをインタラクティブに体感できる仕組みを作ることを優先すべきと考えます。

よく基幹システムと接続しなければ使ってもらえないのではないかという話が出ますが、まずは基幹システムとは切り離して開発した方が良いと思いますし、そこで簡単なダッシュボードを作り関係者の理解を深めてから、基幹システムとどう繋げるべきかは別途議論して決めた方がリスクをコントロールしやすいです。まずはアルゴリズムをお客様自身に体感してもらうことを優先すべきと考えます。

はじめから、話をむやみやたらに大きくしないことがプロジェクトが成功する秘訣と言えるでしょう。

「機械学習プロジェクト」は、「数理最適化プロジェクト」のサブタスク

　機械学習プロジェクトの失敗例として、予測精度を追求し、精度が95%を超えるまでやり続けるという場合が多いように感じます。

　むしろ、「予測精度が上がった後の仕組み」について考えることの方が重要だと思います。

　例えば、配送計画では顧客の注文量を、予算を投じた際のコンバージョン数を予測する場合があります。予測値は、あくまでその後計画を立てる場合のインプットとして使うだけです。すなわち、機械学習の出力は数理最適化の材料に当たります。材料だけ合っても料理は完成しません。さらに言うと、材料が多少悪くても、それを考慮して、料理を実行することはできます。

　数理最適化の強力な手法として、予測のブレを取り込んで、計画を立てることができます。例えば、配送計画の注文量の例で言えば、予測が外れて注文が多い場合に備えて、多く台数を用意すれば良いことになります。しかし、それでは保守的すぎてインパクトが弱まります。

こういった場合には、技術的に高度な内容にはなりますが、多い場合と少ない場合のあらゆるパターンを試行（モンテカルロシミュレーション）し、いかなるパターンでも配車を（そこそこ）組めるようにするといった手段を取ることができます。私はそれを「ロバスト最適計画」と呼んでいます。配送計画だけでなく、他の計画作成にも有効な手法であり、「機械学習を数理最適化で、補完する技術」であるとも言えます。

　こういった複雑な最適化技法も以前は職人技でしたが、汎用ソルバーには、こういった高度な最適化機能（ブラックボックス最適化機能）を取り備えたソルバーもあります。

　機械学習プロジェクトで予測精度を100%にするのではなく、現状の精度に対して、数理最適化でどう補うか、または補う必要がどの程度あるのかを議論することが非常に大切だと感じます。2つのプロジェクトで補完し合いながら1つのプロジェクトを完成させていくのが良いと思います。

まとめ

　私が数理最適化に初めて出会ったのは8年前でしたが、そのときには、考えられなかった時代が来たと感じています。昨今は新型コロナの暗いニュースが多いですが、数理最適化は明るい未来があるような気がします。先人の方々の汎用ソルバーの開発に対する努力には、感謝するばかりです。ぜひとも、先人の方々の知恵の結晶で、データというボトムからビジネスを変革できるような方々が増えてほしいと思います。

　それは特にブレインパッドに限った話ではないと思います。汎用ソルバーで解決したビジネス課題をオープンに共有される時代も近いうちに来るでしょう。

　私もまだまだ修行中ですので、皆さんと一緒に頑張りたいと思います。