2026年10月8日木曜日

今後の実装計画とお願い

1年半もInstance24に取り組み、なんとか結果を残すことができました。

「史上最大の問題が解けたのだから、期待の究極ソルバは直ぐにリリースされるだろう」、と思っていらっしゃる方がいたら申し訳ありません。

実は、その過程で得たブレークスルーは、一般のプロジェクトには、適用することが出来ません。 技術が特殊な為に一般には使用不能、という意味ではなく、汎用プロジェクトに適用するには、現在の実装をもう少し一般的な形に拡張する必要がある、ということです。開発した技術自体は、実は非常に幅広い応用を持ちます。

今まで、メタヒューリスティクス、MIP、SAT..という具合に、同じナーススケジューリング問題の範疇にありながら、LB-UB GAPが小さい値を得るアルゴリズムは、インスタンスにより違うのが普通でした。




実際、スケジュールナースには、MaxSATソルバのAL1、MIPソルバのAL2、数理ソルバのAL3という具体に複数のソルバが搭載されています。

しかし、今までのこの考えを改めることにしました。今回のブレークスルーは、ナーススケジューリング問題の規模や性質によらず一つのアルゴリズムで済む、つまり標準解法となる、ということです。



そうした、統一的アプローチを集大成し新たなAL3に昇華させるのに、かなりのコードの改修が必要になります。

この成果を論文としても発表し、なおかつ、このソルバを広く提供できるようにしたい、ということが現在の夢です。また、独占的なソルバ使用権とともに、その企業は、また広くライセンスを提供できる(義務をもった)提供形態を考えています。これにより、自然に多くの病院・施設で使用が広がるものと期待されます。

物理限界に挑むナーススケジューリング問題に対する標準解法

https://schedule-nurse.blogspot.com/2026/05/blog-post_24.html


もう一つ、ユーザサイドから見て、今までと違うところがあります。

AL1については、そのまま残しますので、これまでと同じです。しかし、今回の変更(AL3)については、根源的仕様を変えます。それについては、別に機会を設けて説明したいと思います。


以下の工程で実装して行きます。


1)COPT Barrier Solverでのデータ採取

まもなく評価ライセンス期限を迎えるので、それまでできる限りのデータを採取します。

2)INRC2データ採取

以前全インスタンスの最適解を得ましたが、ここ1年半スケジューリングベンチマークに集中しコードが変わってしまい、現在再現できていません。再現させるべくコードを修正します。

3)汎用化実装

市井のプロジェクトを動かすべくRefactoringした実装を行います。今回のbreakthroughを盛り込んだRefactoring、従来コードとの融合を図ります。

4)制約関数の実装

GUI・Pythonで使用中の制約関数の実装(AL1→AL3にポート)

5)MCP

ここまでで、大体11月いっぱいかかります。12月からMCP実装に取り組み、来春位のリリースを目指します。Cursor/Claude等がAIエージェントとして動作し、スケジュールナースGUI(C#)を操作するイメージです。直接にソルバをいじるのではなく、GUIを通じたIFに敢えてするのがポイントです。

有償のAIエージェントが前提となります。当初ローカルLLMを想定していたのですが、まずは、賢いAIで実装すれば、後は従いてくるだろう、と思っています。

実装を最優先とするため、論文化は、来春以降となります。

6)Regression Tests

全てのスケジューリングベンチ過去全てのプロジェクトでの実装テストです。来年1月~を予定します。


6)において、皆様のプロジェクトファイルを使用してテストしたいと思います。開発に協力できる方は、現在・過去のプロジェクトファイルを送付頂けないでしょうか?解なしのプロジェクトファイルでも構いません。多ければ多い程、開発・Debugの助けになります。よろしくお願いいたします。



Xでツイート

 schedule_nurse(@NurseSchedule)さん / X


2026年10月7日水曜日

ZOOMの背景を作った

 Claudeに指示して作りました。

「ZoomのVirtual背景を制作して。先進のコンピュータルームにいるイメージで、未来志向の格好いいの。」


昨日打ち合わせした方には何も言われませんでした。

2026年10月6日火曜日

ルールを制約化する上で大事なこと

<仕様とは?> 

プロジェクト作成サービスでは、お客様は、面倒なスケジュールナース上の制約についての知識は必要ありません。それでも、その職場のルールをお伝えいただく必要はあります。この職場のルールを「仕様」と呼んでいます。

「仕様を書いてください」というと、身構えてしまう方が多いのですが、大事なことは、自分の職場のルールを部外者である私に伝える、ということです。最初から完璧な水も漏らさないような仕様を書く必要はありません。最も重要なルールは何だろう?と、大事な事から記述していきます。

その職場のことを何も知らない部外者に伝える、ということは、その仕様があれば、その職場のルールを他で再現出来るようになる、ということでもあります。

言うなれば、その職場のルールを他で再現させる作業が、「仕様を書く」ということでもあります。

職場のルールは、日本語で記述するのが普通でしょう。この段階では、使用するソフトウェアに依存しません。つまり、スケジュールナース・その他のソフトウェアを使用する・しないに関係しないことに注意してください。整理して練り上げた仕様は、その職場の財産です。



<仕様は作りあげていくもの>

ナーススケジューリングは、意識されることのないルール「暗黙知」があることが前提となって、「機械では作れないもの」とされることが多く、またその主旨の学術論文が最近、複数出ています。が、スケジュールナースはそのような立場に立っていません。

Excelに出力した自動勤務解を見て頂くと、「そこは違う」という箇所が必ず出てきます。つまり、仕様にはなくても自職場ルールと違うことは、分かるのです。そういう場合に、そのルールを言葉にして頂ければよいのです。これを「仕様追加」と呼びます。仕様追加していくと、前の仕様と矛盾していることに気づかれるかもしれません。ルールに矛盾があるとき、制約化もできないので、そこを解消して頂くのは、お客さま自身です。ルールは、その場の思いつきであってはなりません。ルールなので、しょっちゅう変わってよい、ものでもありません。

こうした作業を通じて、その職場の普遍的なルールと必要な優先度順が逆に見えてきます。必然として、「その職場のルールの整理」が出来ます。


この自動勤務表をExcelで出力→違うところを指摘(ルールを言葉で伝える)→制約化、というループを数回行うと、自職場ルールをほぼ再現した自動勤務解が出来ます。大体よさそうだ、という時点で、発注をなさってください。

さらに細かな実装は、そのルールをファイルに収めたプロジェクトファイルをお渡しした上で行います。その際、使い方等をZOOMでお教えします。




<仕様を書く力>

仕様を人に伝えるにあたって、大事な能力は何でしょうか? TVでよく解説をされている池上さんは、本当に分かりやすいですよね。池上さんと、言わんとしていることが良くわからないじれったい人との差は何でしょうか? 他人とのコミュニケーション能力だ、という人もあるかもしれませんが、私は、一言で言うと、「国語力」だと思っています。

最近はAIの時代で、AIでプログラミングする時代になってきました。スケジュールナースもAI対応(言葉で制約を伝える)を準備していますが、AI時代でも、国語力の重要性は、変わりないというよりむしろ増している、のではないかと思います。

<メンテナンス>

プロジェクトファイルが出来上がって、数か月廻すと、細かな実装も落ち着いて実用的な解が出てきてやがて仕様追加することはなくなります。これで終わりではありません。勤務表は、メンテナンスがつきもので、スタッフの入職、退職、移動、役割の変更等により、常にルールは変わっていくものです。つまり、プロジェクトファイルのメンテナンスを誰かが行わないと、せっかく導入したソフトウェアが使えないものになってしまう恐れがあります。

それを防ぐには、自分達で、プロジェクトファイルを操れるようになる、必要があります。そのために、導入1年の間は、ZOOMレクチャを必要なだけ行えるようにしています。何回行っても無償です。




「スケジュールナースがAI対応するようになれば、学ぶ必要はないじゃん」、と思われているかもしれませんが、それは違います。何度も言いますが、大事なことは、ルールを他人に伝える力、この場合、他人=AIであり、依然として国語力が大事なのです。

<管理者>

管理者も変わっていきます。管理者の頭のなかだけにあるルールが、その管理者が居なくなることによって失われるリスクがあります。しかし、その職場のルールが仕様という形で、整理・明文化されていれば、スムーズに移管できるようになるのではないでしょうか?



2026年10月5日月曜日

RTX 5070TI driver updateでフリーズ発生(32.016.1088 Freeze)

 突然に、時刻が止まったままとなり、キーボード・マウスも効かなくなりました。WindowsEventログでも、何らかの不具合の痕跡は残っていません。この現象は、2日前から突然に、数時間間隔で発生しました。

Copilotに相談したところ、RTX5070TI等の最新GPUのドライバは、最初のリリースは安定しているが、その後のUpdateで当該事象を発生することが時々ある、とのことのようです。実際、DriverのUpdate履歴で見ると確かに、DriverがUpdateされていました。

WindowsUpdate→更新の履歴→ドライバの履歴


デバイスマネージャで、ドライバを元に戻すと、フリーズは発生しなくなったので、原因確定です。


それにしても、OSを巻き込んで、フリーズするとは。ここ数十年久しく見なかったドライババグです。




2026年10月3日土曜日

Q.同じ施設で3種類の勤務表を作成していますが、一つの勤務表にまとめられますか?

 Ans. 3つの勤務表が、「互いに独立」しているならば、3つの勤務表のままの方がよいです。

勤務表のスタッフ数は、できるだけ少ない方が、(機械で作成するにしても)容易だからです。

「互いに独立」とは、その勤務表グループのスタッフが、他の勤務表グループの影響を受けない、ということです。例えば、あるスタッフが、勤務表1のスタッフであっても、勤務表2の状態の影響を受け自身のシフトに影響を受ける場合がある、というケースでは、「互いに独立」ではありません。そういう場合は、影響を受けている勤務表1と勤務表2の二つを一つの勤務表としてスケジュールナースプロジェクトを作成する必要があります。(そうしないと作れません。)

同様に、勤務表3も、勤務表1の影響を受けて変わる可能性があるのであれば、3つの勤務表を一つにする必要があります。

プロジェクト作成サービスをご利用になり、どういう影響があるか、そのルールを言葉で伝えて頂ければ、制約という形で、盛り込みます。3つの勤務表が、一つのプロジェクト単位として、作成できます。



2026年10月1日木曜日

SchedulingBenchmarks の結果まとめ

 Instance9/15/18結果をUpdateしました。



Instance24を除き、全てのインスタンスの厳密解が確定しました。Instance21までは、Instance15を除き1時間程度以内で厳密解を出力できる、ということが視野に入ってきました。(黄色部は、商用ソルバを使用という条件下で。)

上表のCPUは、数世代前のCPUなので、現世代の最速CPUを使えば、倍速に近い結果となるでしょう。

上表のように全厳密解を提示できるのは、スケジュールナースAL3(DVT)版だけです。Gurobi/Cplex/Coptのいずれを用いても、上表の厳密解を得ることは容易ではないでしょう。