![]()
LLMによる現場のモデル化
![]()
事業所や学校などの現場に最適化技術を使って機械スケジュール、配送、勤務表などを最適化するシステムを作ろうとすると、その現場に固有の様々なルールや状況への対応に大変なコストがかかる。これを簡単にできるように、LLM(大規模言語モデル)を使って現場の状況や固有の条件を上手に聞き取ってシステムを自動構築する技術について考えたい。
オペレーションズ・リサーチとは数理的な技術を経営や産業に応用し、精度や処理速度を上げ、コストを下げるような方法論を研究する学問分野である。その中心的な技術の一つが最適化である。ここでいう最適化とは、コストや精度などを評価基準を定め、その評価がなるべくよくなる計画を立てるものである。計画の例としては、ナビゲーションシステムにおける最短経路の探索、宅急便の効率的な配送ルートの作成、製造業における機械のスケジューリングなどがある。ただし、どのようなルート、どのような計画でもよいわけではなく、通常はいくつもの制約条件が存在する。たとえば配送では、トラックに積める荷物の量や、1台が1日に稼働する時間に制限がある。スケジューリングでも、同時に使えない機械や、使い始めるための準備に時間がかかる機械など様々な条件がある。こうした制約条件を守りながら、最も評価が良い計画を作るのが最適化である。
このような最適化は、人間が行うと意外とうまくいかない。配送先が数百件を超えると人間が良い解見つけるのは難しくなるし、機械のスケジューリングでも同様である。評価値を良くしようと考えれば時間が長くかかり、精神的な負担も大きい。病院の看護師の勤務表や、訪問介護所でのヘルパーさんの割り当て表でも、1ヶ月の予定表のマスは1000を超えることも多く、現場での大きな負担となっている。
こうした現場に最適化を導入すれば、負担は大きく改善される。技術的にもそれほど難しいことではないのだが、現実にはなかなか導入が進んでいない。多くの現場で業務が電子化されていないことなのだが、それ以上に大きな理由は、現場ごとに制約条件が大きく異なることにある。配送では、トラックの種類、荷物の性質(危険物や冷蔵品など)、従業員のシフト条件、配送拠点の地理的な条件などが現場ごとに異なる。勤務表でも、「
必ずベテランを配置す」「こういう作業ができる人を配置する」「特別な仕事がある日は人を増やす」「この利用者にこのヘルパーは割り当てない」といった多様な制約がある。これらを考慮して現場に合った形に最適化技術をカスタマイズし、場合によっては新しい技術を開発する必要がある。この作業は現場の人には難しく、研究者やエンジニアの専門性が必要であるところが、普及の障害になっている。
エンジニアが現場に対して技術のカスタマイズを行う際、まず行うのが現場の人たちへの聞き取りである。どのような条件があり、何を重視しているのかを聞き出し、制約条件と評価基準を設計する。この作業は、システムの仕様書を作ることに近い。一見簡単そうに見えるが、実際には非常に難しく、ここが最も大変な工程である。例えば勤務表の作成ソフトをカスタマイズするとき、現場の人に条件を聞くことになる。しかし現場の人は、多くの場合、それらの条件を言葉にすることができない、単に聞かれただけでは、思いつくことができないのだ。仮に勤務表を作ってみると、「ここが悪い」「ここがダメだ」と指摘され、そこで初めて条件が表面化する。しかしその条件も明確に説明されるわけではない。「ここはこうでなければダメだ」と言われても、「こう」とは何かを尋ねると、はっきりした答えが返ってこないことが多い。「この日にこの人とこの人が配置されているからダメ」と言われた場合でも、日付が問題なのか、人の組み合わせが問題なのか、2人同時であることが問題なのかがわからない。そこから少しずつ、「この人とこの人は一緒に配置してはいけない」といった制約を引き出していく必要がある。さらに、それを個別の話で終わらせず、「一緒に配置できない人の組がある」と抽象化し、まとめて扱えるようにしなければならない。そうしなければ、人の入れ替わりのたびにシステムを作り直すことになる。このような聞き取りは、専門知識のない人には非常に難しい。条件を適切に抽象化し、最適化技術に組み込むことが求められるからである。初心者向けに簡単にカスタマイズできるシステムも存在するが、扱える制約が一般的で単純なものに限られ、実際の現場では役に立たない勤務表しか作れないことが多い。
この聞き取りの問題は、産業やビジネス、学術分野全般に共通して存在する。企業のDXにおいて業務フローや業務ルールを聞き出す場合も同様である。情報学の技術を使って他分野のデータ分析を行う際にも、研究者が何をしたいのか、何が問題で、何が見えるとよいのかを聞き取る必要がある。この聞き取りの質によって、研究の成果は大きく左右される。しかし、この重要なプロセスは、工学や情報学の分野では長らく職人芸やアートとして扱われてきた。学問的に体系化された方法論や知見はほとんど存在しない。そこで、このプロセスを「仕様書策定のためのインタビューイング問題」とよびたい。
この仕様書策定のためのインタビューイング問題に取り組むためのタスクは2つ考えられる。1つは、この聞き取りを工学的に技術として体系化することである。もう一つは、これを研究者やエンジニアなどの専門家の手を借りずに、企業や学術の現場の人間が自律的に仕様書を作れるようにする技術を開発することである。
前者に対しては、人文学などで発展してきたインタビュー技術を参考にできる。人類学や社会学では研究活動にインタビューイングが含まれ、構造化インタビュー、半構造化インタビューといった手法が使われている。しかし、これらの分野でのインタビューは、語り手の話をじっと聞きことを目的とし、インタビューワーはほとんど介入を行わないタイプと、定型の質問で構成される調査のためのインタビューの2つのタイプに分かれ、ここで考えているような、相手が自覚できていないこと、言語化できていないことを、インタビューワーが手助けしながら言語化していくようなインタビューとは性質がことなる。
むしろ近いのはカウンセリングかもしれないが、カウンセリングでは言語化そのものを目標に積極的に誘導するわけではない。患者が傷つかないよう、ゆっくり話を聞いている中で自然に患者がそこにたどり着くような形を目指しており、言語化の際にも、患者に最も納得がいく形を目指し、高額のような多くの人に価値をもたらすようにするようなことはしない。一方で、こうした聞き取りは、研究者や技術者によって実践的に長年行われてきており、暗黙的なノウハウは蓄積されているはずである。それらを収集し、体系化することで、ボトムアップ的に技術としてまとめることができるだろう。その際、人文学で培われたインタビュー技術は重要な基盤となる。
次に、現場の人が自律的に仕様書を作れるようにする課題について考える。これまでの研究では、モデリング言語やプラットフォームの開発によって対応されてきた。抽象的で多様な制約条件を扱える汎用的な最適化ツールを用意するとともに、各個別の現場における具体的な制約条件や評価基準をテキストで記述できるようにするモデリング言語とよばれるプログラミング言語のような仕組みを作り、その使い勝手を上げることで、現場の人間が簡単に使えるようにするものである。最適化のプログラムだけがある状態よりは遙かに容易にはなるが、それでもモデリング言語の学習は依然として負担が大きく、言語化そのものへの支援も不足している。いくつかのテキストがあるので、自身が持つ問題と同様のケースを参照できるが、それも同様のケースの発見とその理解に大きなコストがかかる。データ解析分野では、Jupyter Notebook や R などのプラットフォームが普及し、試行錯誤しながら分析できる環境が整っている。多くのデータ解析ツール、データ可視化ツールが利用でき、それぞれをインタラクティブに使っていくことで、試行錯誤を伴うデータ解析が簡単に行えるようになっている。試行錯誤の支援が間接的に言語化の支援になっていると考えることもできるが、こういったプラットフォームの使い方に習熟することは大変なコストがかかり、やはり現場の人間には依然としてハードルが高い。
そこで考えられるのがLLMの活用である。LLMを使えば、現場の人の言葉から基本的なモデルを簡単に作ることができる。勤務表作成であれば、必要人数、夜勤の有無、繁忙時間帯、役割を持つスタッフの有無、曜日による違いなど、基本的な質問をLLMが行い、回答をもとにモデルを構築することはそれほど難しくないだろう。次に、それぞれの現場に固有の制約や評価基準を調べるための聞き取りを行う。土日は営業時間が変わる、月末や年末はお客が増えるので人数を増やす、週に一度の仕込みの日は料理できる人を配置する、といった条件を聞き取るのだが、これらの条件は非常に多様であり、構造化・パターン化して質問することが難しい。現場の言葉を、最適化で扱える制約条件に記述しなおすには専門知識が必要である。たとえば「パートの勤務時間をなるべく公平になるようにしているんです」という言葉を、勤務時間のばらつきを抑える制約や評価基準として数理的にとらえてモデリング言語で表現する必要がある。また、それが月の勤務時間なのか週なのか、厳守すべき条件なのか、努力目標なのかも聞き出し、それよって制約とするか条件とするかを変える必要もある。こうした「モデリング言語として表現するときの考え方」をLLMに教え込むことにより、現場に即した仕様書が作れるようになるだろう。しかし、研究者の界隈でも、こうした考え方の技術は暗黙知であり、ほとんど言語化されていない。この暗黙知を最適化研究者へのインタビューを通じて体系化する必要があるだろう。これ自体、かなり興味深く、重要な研究と思われる。
このように大変なくろうをして最適化モデルを作るのだが、それでも多くの場合、現場には出てくる解に対する不満が残る。そこで再び聞き取りが必要になる。「この日の組み合わせがよくない」「パートにきつい働き方をさせたくない」といった曖昧な不満を、具体的な条件に落とし込まなければならない。「きつい」とは何なのか、労働時間なのか、勤務頻度なのか、勤務が忙しいのか、ストレスの多い作業のことなのか、を丁寧に聞く必要がある。また、「AさんとBさんは同時に配置しない」といった条件が出てきたら、それを抽象化し、「同時に配置できない人の組がある」と捉え、「他にも同様の人はいるか」と確認する必要がある。こうした聞き取りをLLMが担えるようにするには、研究者の暗黙知の整理とLLMの高度化が必要である。一回これができてしまえば、現場の人は研究者のインタビューイングなしで、自律的に最適化技術のカスタマイズを試行錯誤することができるようになる。これはとても大きな前進であり、企業のDX、学術でのデータ解析など、非常に多くの応用が期待できる。
さらに、聞き取ることが尽きたように見えても、現場の人が満足しないことがある。その場合、「こういうことはありますか」「こういうのは大丈夫ですか」と、他の事例を提示しながら追加の条件を探る必要がある。そして、その返事を手掛かりに、さらなる制約条件を掘り出していき明確化していくことになる。この深掘りは非常に難しく、専門知ではなく話術の問題のように思えるが、他の事例を知っているなど知識も必要であり、さらにあいまいとした返事の中から「ここかな」という点にあたりをつけ、そこを深く聞いていくという専門知と専門性に基づく思考力が必要となる。こうなると、もはやこれは職人芸やアートの領域となるのだが、人類学や社会学は、このアートがしっかりと研究活動に入っているわけで、そこには暗黙的な分野で共有された知見なり技術があるはずである。現在、それらは言語化されておらず、参照できる文献もないようだが、きちんと言語化して記述すれば、必ずや最適化技術の応用場面で有効に使える知見となるはずである。そして、いったん記述されてしまえば、LLMで扱える可能性も出てくる。暗黙知の体系的な記述が、大きな鍵になるはずである。
このようにすれば完成度の高いシステムができるようになるだろう。しかし現場では、ここからさらに別の大きな問題が出てくることがある。現場の人から「実は」という隠れた要求が出てくることがある。「実は、業務上大変だったのは、スタッフの勤務可能日などのデータを手入力でやらないといけないところなんです。うちはデータは紙で管理しているので、なるべく入力の手間が省けないとそこに時間がかかってしまって意味がないんです」、「これはこれでいいのですが、実際のところは常に人員不足で、穴の開かないスケジュールが作れないんですよね。だから、いつも、パートの方に出勤を多くしてもらうように交渉しているんです。穴の開いているスケジュールでいいので、パートの人が出勤しやすい時間帯が開いているようなスケジュールが出るようにできないですかね」「実は、こういう条件付けでスケジュールを作るようにしろ、と社長から言われているんですが、実際現場としてはそれが無理なんです。社長は、現場の厳しさがわかってない。今までは人手でスケジュール作ることでなんとか妥協できるようなものを作ってたんですが、こうやって最適化技術で自動的に作られてしまうと、我々どうしようもなくなるんです」といったものである。どれも自分の仕事の範囲外ではあるので、はいそうですか、と聞き流すことも可能なのだが、実際はそうもいかないだろう。かといってまともにそれらの意見を聞き入れると、せっかく今までやってきた作業が一からやり直しになり、まあまあだいなしになる。かといって無視するわけにもいかないだろう。
この問題、正直どうしたものか、解決の方向は見えていない。あらかじめこういうことを話してくれれば一番なのだが、こういった作業をして初めて言語化できることもあるだろうし、実は社長が、のようなネガティブな話が最初からできるわけもない。ある程度の信頼関係がないとこのような自己開示おきないのだが、最初から信頼関係を作ることはむずかしい。部分的に、こういうことを話すことだけに関する信頼関係を、もっと簡単に構築したり、あらかじめ勤務表の最適化の外側にある問題に目が向くような質問をしておく、などの対策が考えられるが、効果がどれほどのものかはわからないし、どのような話や質問をすればそのように目が向くのかもわからない。ここは、人文知が大きく必要となることかもしれない。心の動き、組織の構造、各役割の人にとっての責任や価値、組織全体の雰囲気やコミュニケーション、そういうものを踏まえて、さらに多くの知見を注ぎ込んで初めて体系化や技術化ができるものであろう。これが、最後に残る非常に大きな、そして大きな価値と興味を持つ問題かもしれない。
![]()