Optimization Night第10回をブレインパッド会場で開催～数理最適化とUI/UX～

はじめに～開催の背景～

今回は、「数理最適化とUI/UX」というテーマで開催しました。数理最適化はアルゴリズムが中心ではありますが、実務で担当者の方々に結果を使っていただくためには、「結果をどう見せるか、どう使ってもらうか」といった視点が重要と日々感じています。このテーマは、弊社内で常に議論していたのですが、これといった答えはありませんでした。そこで、様々な方とディスカッションすることが業界全体にとって有益なテーマだと考え、Casual Optimizationに打診しました。

最適化の学会や研究会等は「こういうことをしました、達成できました」という成果を発表し合うことが多いです。それはそれで良いことですが、「こういったこと悩んでいるのですが、皆さんどう思いますか？」という趣旨の発表ができる場があまりないと感じていました。特に、数理最適化の実務の現場は、あまり教科書的でない実態も多いです。Casual Optimizationはそのような内容でも快く受け入れてくださり、大変助かりました。後の質疑応答セッションでは、座席から自由に意見が飛び交い、運営を担当した私たちにとっても大変勉強になりました。

メインセッション

メインセッションとして、魚井が30分ほど発表しました。発表資料は、Speaker Deckに公開しているのでご覧ください。

【発表資料】
【OptimizationNight】数理最適化のラストワンマイルとしてのUIUX

数理最適化と聞くと、どのような問題をどのようなアルゴリズムで何分で解けたか、という話が中心にされがちです。それは重要なテーマではありますが、それだけがビジネス課題ではないと思います。私の経験上、数理最適化で出てきた解を、何も修正せずに実行できることは意外と多くありません。それは、数理最適化の解に対して、人間の担当者が違和感を持つケースが多いためです。担当者は普段から数理最適化を意識せず意思決定しているわけですから、当然のことです。

こういった事象に対して、技術者はどう向き合うべきなのでしょうか？これこそ、教科書に載っていない数理最適化の一例ではないでしょうか。数理最適化で解を出すところまででエネルギーを使い果たしてしまい、違和感を解消するところまで手が回らない気持ちも理解できますが、この点を突破することに、数理最適化の新しい発見があるような気もしています。

「ラストワンマイル」と題したのは、数理最適化の結果に生じる”違和感”をUIの工夫によって解消できないかと考えたためです。数理最適化は実務の意思決定のための「たたき台」にすぎず、最終的には人が最後の一手を加える必要があるという意味で「ラストワンマイル」という言葉を選びました。

ただし、UIだけが答えとは限りません。「違和感を解消するような制約条件の追加」というアプローチも考えられます。しかし、複雑な制約条件の導入によってかえって良い解が失われる可能性もあるため、慎重な設計が必要になります。

そこで発表では、必須の制約と違和感を解消する制約に分けて用意し、画面からON/OFFできるようにするという案を提唱しました。

とはいえ、制約条件と一言で言っても、商品単位、日付単位とモデルの添え字によって多様なため、どの粒度でON/OFFを実現可能にするのかは非常に悩ましい問題です。粒度を細かくしすぎると、ユーザーにとっては設定する煩わしさが勝るというおそれもあります。

次の話題では、数理最適化の解を可視化し、それを画面上で修正できるようにするという案を提示しました。

ただ、この案の問題点として、オープンソースにはデータの可視化ツールと呼ばれるものは多くあるのですが修正ツールがあまりないということがあります。修正とは「可視化されたデータを改ざん」することを指すため、ニーズがないのかもしれません。しかし、このケースではデータの微妙な改ざんにこそ、意味があると考えます。修正ツールがあまりない以上、自作するしかありません。さらに辛いのは解の可視化といっても問題ごとに可視化方法が異なるため、それぞれに修正ツールを開発する必要がある点です。

本発表では「生産スケジューリング」と「投資計画」という2テーマを上げて、それに対するUIについて議論しました。生産スケジューリングに対しては「順序を入れ替える」「生産を引き延ばす」といった操作が可能なコンポーネントをReactで開発し、それを紹介しました。ただ、これを凝って作ってしまうと人が決めているのと変わらず、数理最適化の良さを失ってしまうため、「少し」修正できるくらいが良い塩梅だとと考えています。この「少し」というニュアンスも問いによって温度感が異なるため厄介な問題ではあるのですが、これはポジティブにとらえることも可能です。人の修正によって、最適化で出した答えよりも良い解が見つかる可能性もあるかもしれないからです。

そこで問題となってくるのが、制約条件と目的関数のリアルタイム更新です。

解を画面上で修正できたとしても、リアルタイムに制約条件と目的関数を更新するのは難しい問題です。というのも、後の議論でも出ましたが、制約条件や目的関数の値は数理最適化モデルを一度解くことで初めて得られるものだからです。このため、リアルタイム更新を実現しようとするとリロードが長いアプリケーションになる可能性が高く、ユーザー体験にも大きく影響してしまいます。解決のためには「目的関数だけ更新する」「ハードな制約条件だけチェックする」といった様々な方策が考えられます。

最後に数理最適化の修正コンポーネントのオープンソース化についての話題を出しました。

修正コンポーネントをpip installできるような形にして公開すると、様々な方がこれを改良して、数理最適化の実用適用が加速することは起きないでしょうか。せっかく良いアルゴリズムができたにも関わらず、実務適用されずPOCで終わってしまったということを防ぐためにも、この辺りのUIコンポーネントの充実さが意外とキーになるのではないかと感じています。

Lightning Talk

Optimization Nightではメインセッションの発表に加えてLightning Talkの発表もしていただくのが恒例となっており、今回も2名の方々が発表されました。

ひとつ目はryuhmdさんから。「書を捨てず、勉強会へ出よう」というタイトルで、勉強会への参加、特に社外に出て勉強会へ参加することの意義について熱く語っていただきました。

社外勉強会を開催することで会社どうしであったり、会社と学術界とのつながりを作ることでコミュニティへの貢献ができるとおっしゃっていた点が印象的でした。

筆者自身、学生時代にCasual Optimizationで「Pythonではじめる数理最適化」の勉強会に参加して学生ながらにして実務家の方の話を聞く機会を得たという経験があります。

ryuhmdさんの発表を聞いて私も何かしら勉強会の形でコミュニティに貢献したいと思いました。

現在、ryuhmdさんの主催するConvex Optimizationの輪読会が開催中です。興味のある方はCasual OptimizationのサイトからDiscordに参加していただき勉強会スペースを覗いていただければと思います。（※記事公開時点の情報です）

ふたつ目はtakasuka_mさんから「現場目線のUIを意識した数理最適化」というタイトルで、インフラ補修工事の立会者の割当を決める問題に対してStreamlitを活用して現場の方と対話しながらPoCを行った事例をご紹介していただきました。

発表資料とデモアプリも公開されているので是非ご覧ください。

【発表資料】
20250806_OptimizationNight_現場目線のUIを意識した数理最適化_投影用 | ドクセル

今回の発表では割愛されていましたが、スライドでは列生成法を用いた解法なども紹介していただいております。

発表の中で、Streamlitを使って現場の人が普段見慣れた形で可視化を行うことで解の違和感についてなどのフィードバックをもらい、モデル改善を行っていったとお話しされていたのが印象的でした。

まさに実務において、現場の人に使ってもらうにはそういった視点が重要であると感じました。

改めて発表していただいたお二方、素敵な発表をありがとうございました。

質疑応答とディスカッション

数理最適化のモデル内で記述されている制約条件を画面側で記述するにはどうすれば良いか

冒頭に記述した制約条件のリアルタイム更新の問題について様々な意見が飛び交いました。

• 数理最適化モデルはpythonなど専用の言語で書かれているが、画面側はJavaScriptといった別言語で記述されているため、その言語の壁が高い
• 特に企業のプロジェクトでは画面開発とモデル開発で人が分かれていることも多いが、モデル側が更新されればそれに伴って画面の更新も必要になる。そのような状況下でコミュニケーションの壁が発生してしまう

表示する期間の問題

計画期間の長さがモデリングにおいても重要な要素となりますが、以下のような議論がありました。

• 計画表が画面に収まるような１週間程度であれば修正可能だが、1か月の計画のような長期の場合は、もはや人間の目で可視化を把握することすら難しくなる。そもそも修正できるのか、長期の計画の場合はそもそも現場レベルではなく、経営層のニーズなので重要なのは目的関数の値だけではないか
• そもそも数理最適化プロジェクトにおいて、計画表の期間の最大値を決めるべきかどうか

アラート表示の問題

• ハードではない制約条件は目的関数にしてしまって違反量のアラート表示するのが良いのでは
• 現実問題ではどの制約条件がハードかは依頼者にとっても曖昧な場合も多いため、事前にわかっていれば良いが、後から修正するのは大変

運営として

Optimization Night運営かつブレインパッド社員としてイベント全体を振り返ります。

会場は、今回も前回同様にオフライン(ブレインパッドオフィス)、オンライン(YouTube Live)のハイブリッド開催で行いました。

オフラインで30人程度、オンラインで40人程度の方に参加していただきました。
たくさんのご参加ありがとうございました。

今回は飲食も弊社でスポンサーし、ビール、お茶などの飲料や発表を聞いている間でもつまめるようなサンドイッチ・おにぎりなどを用意しました。

最初からアルコールや軽食を片手に発表を聞いてもらう形にした結果、質疑応答の際は様々な方から質問が飛び交い、賑やかな雰囲気で進行することができました。

次回以降の会場・飲食スポンサーも絶賛募集しております！

スポンサーいただいた際はイベント冒頭で会社紹介の時間を設けさせていただいておりますので何卒よろしくお願いいたします。

さいごに

発表やディスカッションの様々な意見を通じて、改めて実務における数理最適化は、教科書にはない難しさを秘めており、それと向き合っていくことが新たな発見を生むように感じました。

特に、DXブームは終わり、POCで構築したアルゴリズムが現場利用されなかったという事態は今後、より厳しく見なされる時代になります。より確実に現場利用されるには、アルゴリズムの周辺領域（UI/UX、現場装着）に、技術者自ら踏み込んでいく必要があるでしょう。ただ、それに対して、高性能な汎用ソルバーや、可視化＋修正コンポーネント、生成AIによるモデリング等、ツールは充実してきたため、アルゴリズムが得意な技術者が、カバー領域を拡大しやすい時代と感じますし、拡大した方が、技術者自身も価値を発揮しやすくなると期待しています。

弊社では数理最適化プロジェクトを重点領域として捉えており、今後も記事の発信やイベントの開催を積極的にしていきたいと思います。またイベントを開催した際には、ぜひお気軽に弊社にお越しください。