最適化の計画を作って終わりではない「付加価値」
梅田：これがこの話の最後ですが、実は最適化モデルには、ある程度出来上がった段階で、シミュレーターとして利用するという付加価値があります。その話をして締めたいなと思っています。
基本的には、プロジェクトをやっていて最適化モデルを作るというのは、何かのインプットを入れて、最適化の計画を出すところで終わりがちです。でも、やはりさっきのGurobiさまの発表にもありましたが、意思決定に役立ってなんぼなので、もっともっと経営レベルの意思決定に役立てていきたいよねというお話です。
例えばさっきの電力会社で言うと、発電所が10個あります。その10個の発電所を効率的に運転するという最適化モデルを作るプロジェクトだったとします。
それはできましたとなるのですが、やはり、さらにそこから上で、例えばこの最適化モデルを使って、「新しい発電所を1個作ったらどうなるの？」「発電所を1個潰したらどうなるの？」というシミュレーションができたらもっとうれしいなと思うわけですよね。ちょっと拡張性にも通じるところではあるんですけど。
「経営の意思決定」に役立つシミュレーターとしての用途
梅田：例えば私たちのモデルの中で、新規の発電所を1つ作る想定で、何か箱みたいなものを用意しておく。そこに自分たちが今作ろうと思っている新規発電所のスペックデータを入れてもらったら、擬似的に11発電所で計算を回すことができて。
そこで、この発電所を作ったほうがコストが全体として下がるのかとか、投資回収を5年でできるのかというシミュレーションができるようになると思うんですよね。
なので、モデルというのは作って最適化で終わりではなくて、使いようはいっぱいあるなと思っています。柔軟的な使い方ができるようなかたちで、モデルを作っていくことがすごく大事だと思っています。
例えばガチガチに発電所を10個だけで作って、それをデータの中に取り込んでやりますだと、1台増やす時に「改修が必要です」「プログラムを書き換えないと」となると思うんですよね。
でもたぶん、「こういう使い方をしたほうがいいよね」ということがわかっていれば、例えば最初のインプットのExcelシートに1つ箱を用意しておいて、「ここに入れておいてください」ということができると思うんですよね。
それで使い道が広がっていって、みんなにとってうれしいことがあるかなと思います。実際に我々も「拡張性がありそうだな」と思って提案することで、もともとのお客さまの部署だけじゃなくて、他部署の経営企画部門からも「使わせてほしい」ということで、ユーザーがガーッと増えていき、用途もすごく広がっていったことがありました。
なので、最適化モデルは本当に、使い方によってはシミュレーターとして使うなどのいろいろな用途があり、いろいろな可能性を秘めていることをわかっていただけたらなと思います。
ソルバーは開発が速く、柔軟性が高いのがメリット
梅田：最後に話が少し変わりますが、数理最適化ソルバーの説明をします。最適化ソルバーはいいよねという話をちょっとしていきたいと思います。さっきの開発サイクルの話の時もあったのですが、やはりソルバーを使うと開発が早い、そして柔軟性が高い。
そして、これは触れなかったですけど、「解の精度」がわかる。「どのくらい良い解なのか」がわかるメリットがあります。もちろんプロジェクトの問題によっては、ソルバーで解けるんだけど、とんでもない時間がかかってしまうというシチュエーションもけっこうあるので、最終的な製品にどういったアルゴリズムを載せるのか。
ソルバーを使うのか、自分たちで開発するのかはプロジェクトに依るのですが、どんなプロジェクトであっても、最初の要件定義の段階で、開発のサイクルを高速で回していくシチュエーションは存在しているので、その時はソルバーを使うのがすごく大事だなと思っています。
それをもうちょっと図で表したのがこんな感じです。最終的なアルゴリズムを作る前に、ソルバーを使って何回も何回もリピートしていって、モデルを修正していき、要件を詰めていく。
「ほぼほぼ9割はこの要件でいく」となったら、要件に則った専用のアルゴリズムを作るか、そのままソルバーで突破するか。そんな感じで、私たちはプロジェクトの解法を選択しています。
ソルバーにも、いろいろな種類があります。最適化ソルバーの中には、お金を払って買う商用のソルバーと無償でやるソルバーがあります。私たちも当然、商用も無償もいろいろ試してきています。
私たちは基本的に「Gurobi」を使うようにはしています。なぜかと言うと、やはり計算速度が速いというのがあります。あとは使いやすさも大事だなと思っていて、すごく使いやすいAPIでけっこう直観的に書けるところも重宝しています。
あとはサポート体制ですね。「なんかわからないんだけど」とテクニカルサポートに聞くことがあるのですが、すごくわかりやすく瞬時に対応してくれたことがあるので、そういった意味でGurobiを選択しております。
いろいろなフェーズごとの「落とし穴」に注意
梅田：最後にまとめに入りたいと思います。プロジェクトのライフサイクルに沿って、ちょっとハマりそうな場所や、「こういうふうにしたほうがいいかもね」といいう話をさせてきていただいたんですが。
SIerによるガチッと決まっている要件で、ウォーターフォールで、システムを1回上から順に作っていったらできます、というものとは性質が違う点が多々あるかなと思っています。
なので、「最適化プロジェクトをやりたい。でも、ちょっと難しそうだな」という時はご相談をお待ちしています。
下に書いたように、いろいろなフェーズでいろいろな落とし穴があるので、そういったところで何かお力添えができたらなと思っている次第です。では、以上で私の発表を終えたいと思います。ありがとうございました。
（会場拍手）
簡易的な画面のイメージを伝えるのに便利なフレームワーク
司会者：梅田さま、ありがとうございました。少しお時間がありますので、質疑応答を実施させていただきます。ご質問のある方は挙手にてお知らせください。
それでは、まだお時間がありますので、Q&Aシステムにいただいているご質問をいくつかさせていただければと思います。
「GRID 梅田さま、AIで生成するアプリによく採用するフロントエンドフレームワークは何でしょうか？ また、そのアプリは使い捨てされるイメージでしょうか？」ということですが、いかがでしょうか。
梅田：これはいろいろなフェーズがあるのですが、私たちがさっき言った「高速で回す」という、プレゼンの中で使っているものは、PythonでStreamlitで書くことが一番多いです。1週間で画面がガラリと変わったりする時に、いろいろ何かやっている場合ではないので、そこで簡易的な画面のイメージを作っちゃって出すことが多いですね。
プロンプトの管理・共有やセキュリティ対策は？
司会者：ありがとうございます。それではまだお時間がありますので、次の質問に移りたいと思います。「生成AIをご活用されているということですけれども、プロンプトの管理はどうされておりますか？ また、RAGやMCPを構築されておりますでしょうか？ 外部のLLM利用時は、機密漏えいリスクはどのように管理されているのでしょうか？」。
梅田：プロンプトの管理というのは、プロンプトを社内で共有しているかみたいな感じですかね？
司会者：「テンプレート的なものを持たれているか」というご質問なのかなと推測しました。
梅田：会社の中で決まったテンプレートは別にないですが、共有し合っている感じですね。「こういうプロンプトを与えたらうまくいきましたよ」という報告や共有ができるプラットフォームがあって、お互いに報告し合う会もあるので、「そうなんだ」という感じで持ってきたりすることはけっこうあります。
あとはGeminiをけっこう使うのですが、GeminiのGemを使ったり、ChatGPTのGPTを使って、定型の業務があったら、そこに仕事を持たせて会話したり、みんなで共有したりはしますね。MCPの話なども構築していますが、これはけっこう人によるというか、いい事例の共有会の中のプロンプト以上に、人に依るところだと思うのですが。
「このMCPを使ってうまくいきましたよ」という話があったら、「そうなんだ。じゃあちょっと使ってみようか」みたいな理由くらいで、会社として正式に、「開発の中に取り込んでください」とちゃんと打ち出しているわけではないです。
というか、それをキャッチアップしてルールにして共有するという時間の中で、状況が変わっていることがけっこうあって、「こっちは新しいのが出てきました」となったりするので、今は個々人がキャッチアップしていき、「いいな」と思ったものをどんどん共有してもらう感じになってしまっていますね。
外部のLLM利用時の機密漏えいリスクは、深いところはやはりわからないんですけど、一応ガイドラインというか、「こういうプランに入ったら大丈夫です」というものには入っています。「大丈夫」と言われつつも、本当のところはちょっとわかりませんという感じですね。
計画に現場の工夫を取り込むと、いざという時の余地がなくなる
司会者：ありがとうございます。では、あと1問だけ質問させていただければと思います。「計画と運用の混在に関連するのですが、モデルをシミュレーターとして使う場合に、モデルの結果が足元の実運用と合っていないと、未来のシミュレーションに対して顧客の信頼を得られないケースがあります」。
「計画と運用を切り離して考えてもらうために、よく使うキーワードですとか、決まり文句等があれば教えてください」ということです。どちらかというと、お客さま向けにどうアプローチをするのかみたいな話ですかね。
梅田：いやぁ、これは私もけっこうしんどいので、キラーフレーズがあるかというとないですし、すごくよく言われるのですが、さっきの「どっちも違う論理で動いていますよね」という話を話は繰り返し言いますね。
運用の細かな部分、例えば現場の工夫を計画の段階で取り込んで運用に寄せることはできます。でも、そうすると最終的な現場の工夫の余地を計画の段階で奪っていることになるんですよね。
例えばさっきのトラックの例だと、「若干社内基準を上回ってもいいや」という例があった時に、それを計画の中に取り込んでいくと、常に破っているような感じになるわけですよね。
そうすると現場としては、何かあった時に、さっきの20パーセントは余白だから、「ここに詰めればいいや」と思ったところが、どうしようもなくてにっちもさっちもいかない感じになってしまう。「そういう状況って嫌ですよね」という話をしていて。
「計画は計画で理想的な段階で残しておき、現場の工夫の余地を計画に取り込まずに、最後に現場に任せられるようなかたちで残しておいたほうがいいんじゃないですか？」と言うと、わりと「確かに。最後に現場の工夫で何もできないのは怖いよね」という感じで落ち着いていってくれることはあるかなと思いますね。
司会者：ありがとうございます。「現場で運用する余白というか、柔軟性を保っておきましょう」というメッセージかなと思いました。
それではお時間も近づいてまいりましたので、質疑応答は終了とさせていただければと思います。引き続き、もしご質問がある方がいらっしゃれば、Q&Aシステムに質問内容を投稿してください。ありがとうございました。
梅田：ありがとうございました。
（会場拍手）
PR
PR
PR
PR
PR
PR
PR
PR
PR
PR
