Q. タスク型勤務表

 Q.タスク型勤務表の作成についてご教授お願いします。

①      10名の職員

②      勤務は日勤、早番、遅番の3つ

③      毎日早番は2名、遅番は2名、日勤6名

④      午前中に作業所１に早番１名と遅番１名を配置

⑤      午前中に作業所２に日勤１名、早番１名を配置

⑥      会議が５，１０，１５，２０，２５，３０日の午後にある

⑦      会議メンバーは全員午後の会議に出席、午前中は作業１もしくは作業２の配置可

上記の条件でタスク型勤務表を初めて作成してみましたが、うまくいかずなにをどうしたらよいのか全く分からない状態です。

タスク型勤務表も勉強したいので、ぜひご教授ください。

Ans.

タスク定義が以下になっていますが、

以下のオプションにチェックしてください。この形(NoTaskVarが定義されて、オプションが✓されている状態）がタスク型勤務表での基本形だと思ってください。

フェーズ定義は、以下の記述で問題ありませんでした。フェーズ定義は、シフトとフェーズの対応表です。

フェーズとは、１日内の時間区分です。このプロジェクトの場合、AMとPMの二つを定義しています。

ここで定義しているシフトのみタスクを持てます。定義されていないシフトは、タスクを持つことは出来ません。上のフェーズが✓されていないフェーズでは、タスクを持つことができません。

上の場合、全フェーズでチェックされているので、日勤、早番、遅番の各シフトは、各フェーズにおいてタスクを持つことができます。（タスク定義が活きます）

Q.ある問題スタッフが居て、被害者A/Bがいる。 通常のペア禁止に加えてシフト時間の重なり部分でも、ペア禁止としたい

Q.

 介護施設における相性問題です。被害者A/B共、問題スタッフからの執拗な攻撃を受けています。特にBは、利用者からの評価が高いスタッフですが、問題スタッフの顔を見るのも心的ストレスとなるので、完全に分離した勤務とする必要があります。被害者Aは、それほど酷くはないのですが、心療内科を受診中であり、可能ならば、Bと同様に、完全分離勤務としたいです。 

Ans.

被害者集合を定義します。

ペア制約で、以下を禁止とします。この施設では、夜勤スタッフは、日勤を行わないので、日勤を考慮する必要はありません。

■問題スタッフが入り　ー　被害者グループの遅番

■問題スタッフが明け　ー　被害者グループの早番

■問題スタッフが遅番　ー　被害者グループの入り

■問題スタッフが早番　ー　被害者グループの明け

　

制約名は、IfThen形式で記述していますが、両方向に作用することに注意してください。

スタッフ固有名で記述するのではなく、スタッフプロパティシート上でメンテすることがポイントです。（スタッフが退職して居なくなったとしても問題なく動作します）

Q 入り明けで1.5日、公休数は月で決まっていて半日遅番・半日早番で、公休数を合わせるには？

 Ans.

整数カウント制約を使います。半日関係のカウントを１、その他を2として計数します。

公休数をカウントするシフト集合（公カ）を定義します。

整数計数を使います

10月の公休数が9とするとその倍の18で制約します。

以上です。

Q.解が求めることができません スタッフ２０，２１，２２の休みの回数にエラーが出ているようです

 Ans.

＜解析＞

赤●のラインをダブルクリックします。

指摘制約を見ます。2連休を１回以上４回以下にしているソフト制約です。

指摘スタッフの予定を見ると、後半に有給が連続しています。この部分だけで２連休が８回以上になっています。

この制約、ソフト制約レベル２の許容エラーは、下記より１です。

なので、ハード制約は、４＋１＝５最大として作用します。つまり６回以上の２連休はハードエラーとなります。予定もハード制約、行制約もハード制約、ハード制約間の矛盾ですので、ハードエラー、つまり解のない状態となる訳です。

＜改善策＞

意図は、「有給も含んで１回以上の２連休を確保したい」、ということだと思いますので、最小制約だけを残して、最大制約は削除すれば、矛盾を解消できます。

しかし、「休み２連休は最大４回(有給は除く）も制約したい」、ので、最大用に新たに制約を追加します。

このようにすれば、矛盾を解消かつ、予定なソフトエラーを生じさせずに意図を反映できます。

Q,スケジュールナース構造を理解したい

 Ans.

難しいと思います。スケジュールナースは、分野を跨いだ最先端の技術を採用しており、少なくとも理工学大学院程度以上の広範な知識が必要となります。加えて、設計ソースを理解するには、C++に対する深い造詣、C#とpythonのプログラミング能力に加え、以下の分野の先端研究論文を理解する必要があります。

１）人口知能学会　SATソルバ・Maxsatソルバ　for AL1

２）オペレーションズリサーチ学会　組み合わせ最適化　for AL2-3　

３） 人口知能学会　グラフ理論　for AL3

４）　電気通信学会   回路合成 for AL3

５）言語処理学会　コード生成　

しかし、プロジェクト作成をするだけならば、構造の理解は必要ありません。Pythonも殆どの場合必要なく、中学校の集合の知識さえあれば、誰でも学べます。

Q.「ココナラ」等で、勤務表作成受託サービスを行ってよいでしょうか？

 Ans.

問題ございません。ただし、サブスクライセンス(480円/月)については、エンドユーザ様病棟毎に一個づつ必要になることにご注意ください。お持ちのライセンスでエンドユーザさまのプロジェクトを設計・開発することは出来ますが、そのライセンスで、エンドユーザさまが運用することは出来ません。

例えば、次のような立ち上げのシナリオは、如何でしょうか？。

１）他の病棟プロジェクトを作ってみる。（報酬なしで）

２）分からないところは、菅原システムズに相談する（必要に応じてZOOMを依頼）

３）数病棟の経験の後、報酬付の受託サービスを開始する。

１)を数病棟OJTを行うことで、スケジュールナースの使い方と、その過程がどれ位大変か？が分かってくると思います。

大変なのは、スケジュールナースそのものではなく、エンドユーザの意図とスケジュールナースのマッチングを取ることです。

エンドユーザのお話を聞いて、スケジュールナースに落とすには、時間がかかります。作って終わりではなく、メンテナンスや操作指導等も時間がかかります。大抵の場合、「割に合わない仕事だなあ、」

という結論になると思います。従い、３）に移行しないまま終了することもアリだと思います。

スケジュールナースの使い方については、数病棟を経験すれば、看護師勤務表については、出来るようになると思います。（看護師勤務表は、既存パターンのどれかに当てはまります。）

まとめとして、

A）プロジェクト作成について、上記１）～３）のステージに関係なく、その都度アドバイスを行う支援は可能です。

B）それ以外について（販促等）、支援・アドバイスは出来ません。

IPMに期待

 Cuopt,Highs共に、ダイレクトコルスキー分解を用いたIPM（内点法）を準備中の模様です。

Githubで実装を眺めることが出来ます。10月中のリリースと予想します。

超大規模問題、instance23/24の問題は、

■グラフがコンパイル出来ない

■SATソルバがコンパイル出来ない

■Lpソルバが遅すぎる

というものです。３番目の問題について、PDLPに期待しました。1e-4では、期待通りの性能を示すものの1e-5以上の精度となると遅すぎ、実用精度の1e-7では、全く遅すぎて使えないことが判明しました。

そこで、高精度領域でも速度が落ちないバリアソルバに期待がかかります。NVidia　CuDSS疎行列のコルスキー分解で革新的な速度向上があったようです。CuDSSについては、プレリリースされており、その気になれば、これを用いて自前実装も可能だとは思いますが、上記の通り、リリースを寝て待てばよいだけなので、待つことにしたいと思います。それまでに、上記他の課題をクリアしたいと思います。

MaxSATソルバのダイエット

 ■SATソルバが使えない問題

に対して、構造を見直しメモリダイエットを行いました。およそ1/4程度にはなりました。

結果、instance23については、AL1でコンパイル出来るようになりました。このとき、25GB位の消費です。

しかし、instance24については、AL1コンパイルが出来ませんでした。およそ57GB位で、ストップします。TIME制約関係の消費が大きいようで、恐らくは、SATソルバの最大節数を超えているのだと思われます。（デバッグ用の開発環境が32GBなのでデバッグが出来ません）

SATソルバが使えないと、やはり痛いです。LPソルバから整数化を行うのにLPソルバだけで整数化しようとすると途方もない時間がかかります。現実的な時間内に解を得るには、なんとかして使えるような検討を行う必要があります。

PDLPX

PDLPの改善版です。3倍程度、特に高精度領域において、改善が著しいようです。

[2507.14051] cuPDLPx: A Further Enhanced GPU-Based First-Order Solver for Linear Programming

■LPソルバが遅すぎる問題

現状では、全く遅すぎて、10倍以上の速度アップが必要ではないかと見ています。

上記でも足りませんが、とりあえず、

ＨＩＧＨＳまたは、Cuopt で、実装されるのを待ちたいと思います。

cuPDLPx by Kh4ster · Pull Request #388 · NVIDIA/cuopt

GPUの比較

PDLPで比較してみました。 

RTX4060TIをRTX3080 12GBに置き換えてみたのですが、期待していた性能向上は見られませんでした。ネックはメモリ転送レートと睨んで、あわよくば3倍と期待していましたが、1-3割程度の効果しかありませんでした。

• • 
    
  • 

    

    
    
    
    
    
  • 
    
  • 
    

instance23のLBが判明

これまでの世界記録は、 

Instance23 ： LB＝16990 UB＝17428

でした。今回、新たに　17284.3 ⇒LB＝17285

であることを発見しました。

大幅なLB更新は確定的で、これまでの経験上、UBもその直近傍(ex 17285)にあると思われます。

しかし、次の

■RCSSP　ソルバが遅すぎる

■LPソルバが遅すぎる

■SATソルバが使えない問題

という問題のため、それ以上前に進められていません。

LPソルバについては、

■GPU置き換え

■PDLPアルゴリズムの改善

■新たなIPMソルバの適用

の可能性を検討しました。

Pseude boolean competition 2025

日本から、3チームが出場したようです。

PB25 Pseudo-Boolean Competition 2025

名古屋大の酒井先生と山梨大の鍋島先生のチームが優勝されました。

擬ブールソルバ競技会（Pseudo-Boolean Competition 2025)よりDEC-LIN 部門 第1位を受賞しました。(情報システム学専攻 酒井 正彦 教授) | 名古屋大学情報学部／大学院情報学研究科

その他にもPrintempsや今井さんも参加されたようです。

Pseudo boolean  competition は、昔からあったように思いますが、しばらくお休みがあって、ここ最近復活したようです。最近の潮流は、MIPソルバの使用にあるように思います。

Maxsat competition については、今年はお休みです。一昨年と去年の解けた問題数の差異は、殆どなく誤差の範囲と言ってよいかもしれません。技術的進展がないと、研究者も敬遠するのかもしれません。

SAT Competition 2025

 The Results of SAT Competition 2025

今年の優勝者は、AE-Kissat-MABで、

DynamicSAT: Dynamic Configuration Tuning for SAT Solving

ダイナミックにチューニングするソルバのようです。明らかに優位性が見れます。

それから一カ月も経たないのに、それを凌駕するとの報告がありました。

Autonomous Code Evolution Meets NP-Completeness

NVidiaのSaturationというフレームワークを使って人がコーディングしたよりも性能が良いソルバを自動生成する、

とのことのようです。AlphaEvolve

Google: AlphaEvolve - Gemini を活用した次世代アルゴリズム設計について #GoogleCloud - Qiita

よりも、より進歩性のあるということを主張しています。

初期のSATソルバとは違い、最近のSATソルバは、細かな改善の積み重ねの結果としてあり、何のパラメータが支配的な性能向上につながるか？というのは、パラメータ数が多すぎてよく分からないことになっていると思います。　こうしたパラメータが多数ある分野でのチューニングは、人間は、LLMには敵わない、と私も見ています。言うなれば、人間勤務表ースケジュールナース勤務表のような関係性です。

最適化ソルバで、研究者自体が駆逐される可能性も出てきるでしょうか？　こちらは、未だ論文化されていない方法が多数あると思われます。（私が取り組んでいるのも、その一つです。）それらが全部オープンにされない限りは、LLMが支配することはないと思います。

逆に言えば、

■最先端技術が全てオープンになっているSAT技術分野でのLLMとの闘い

今後のSAT　Competitionは、LLMが生成したソルバが参戦してくるでしょうから、来年以降、過去の技術資産の組み合わせだけで、LLM生成ソルバに勝つのは、極めて難しいと思います。昨今の革新的進歩がないことを勘案すると、極めて不利な情勢です。しかし、一抹の期待を抱かずにはいられません。

Q.9月15日以降の勤務表を再作成する必要があり、 システムで再作成(求解)を行ったところ、エラーが発生

 Ans.

赤部をダブルクリックすると、次に飛びます。

しかし、これは、GUIの誤作動です。申し訳ありません。制約は、二つあり、

「できれば2連休を一回以上」ー　赤部GUI指摘箇所

「できれば2連休を一回以上　責任者」青部ソルバ指摘箇所

で、ソルバの指摘箇所は、GUIが指した赤部ではなく、責任者の記述がある青部です。

スタッフ１４が９月１５日以降、全日休みになっているので、上記制約の最大記述と矛盾になっています。（ソフト制約ですが、行制約レベル２は、許容エラーが１になっているので、4+1 ⇒６以上は、ハードエラーとなっています。）

従い、スタッフプロパティ、スタッフ１４の責任者記述を、一時的にブランクにすることで

対応するのが、簡単でしょう。

あるいは、恒久的に、当該制約の最大記述をカットしてもよいと思います。

添削プロジェクト

お客さまが記述したプロジェクトをZOOMレクチャ１回で添削しました。

 病棟２交代メンテナンスマニュアル

プロジェクトファイルは、以下です。

Q.日勤後連続夜勤が先月部ー今月部でエラーする

 Ans.

下記記述で、先月部末日（＝制約終了日）に夜勤が来ると、次の日は、夜勤明けが来ることが必然となるためです。この際、パターンがヒットしないことに注意してください。

これを改善するには、パターンがヒットするように、次のように明けパターンを削除します。

先月部の記述問題なので、今月部は、如何ともなりません。次月よりの改善となります。

解がないプロジェクトの改善

 前回、解がない場合の解析を行いました。実務場面で、ここまで詳しく見る必要はありません。単に、「９月１９日、グループAの夜勤明けリソースが足りないのだな」ということだけ分かれば、十分です。

しかしながら、実務場面で、予定を入れるたびに、こうしたことに頭を悩ませるのは、好ましいことではありません。ブランク予定で、UB=0が保証されていれば、機械的手順で、予定が変更される部分は分かりますが、一定のスキルを要するので、出来れば、そういう事態は避けるような、恒久的プロジェクトの改善を行うことが好ましいです。

１）列制約のソフト化

２）行制約のソフト化

３）グループA/Bに関わるのでバランスを整える

グループAのリソースが足りないので、グループBのリソースに余裕があれば、改善する可能性があります。その月で、もし変えることが可能ならば、カットアンドトライでやってみる価値はあります。

４）グループA/B両方対応できるスタッフがいないか？

スタッフ１は、丁度そのようなスタッフなので、グループ集合を変更して制約を変更します。

＜まとめ＞

夜勤明けリソースが居ない問題について

１）予定変更

２）列制約のソフト化

３）夜勤明け後の休みのソフト化

４）グループバランス

５）グループA/Bの両方に対応可能なスタッフ記述

対応する方法を述べました。列行どちらの選択をするかは、重みの選択によります。

一つの解がない問題について掘り下げました。ハード制約間の矛盾で解がない事態となってしまうので、基本的には、予定・列・行のいずれかをソフト制約で逃げる必要があります。

大事な事は、解がない⇒原因は様々ある⇒ソルバは、原因に関するヒントを列挙はしますが、上のどの対応が適切かは分かりません。管理者だけが正解を知っているということです。

そして、その正解は、予めソフト制約や重みによって自動的に選ばれるようにしておくことが、恒久対策となる、ということです。

上のような解析は、開発時だけのもので、稼働時には、常に管理者にとっての正解が示されるようにしておく、ということがポイントです。

Q. 希望休と必ず出なければならない日勤集合、研修、などを合わせた結果エラー発生します

 Ans.

エラー情報をよく見ます。

一見して分かるのは、9月１９日近辺にエラー要因があるということです。

赤丸部をダブルクリックして飛ぶと、エラーは、全てグループAで起きている、ことが分かります。

なので、最も疑わしいのは、

■９月１９日にグループAで夜勤リソースが足りていない

ということです。９月１９日の予定を全てソフト制約にして、再度求解します。

予定ソフトのレベル１の適用にチェックを入れ求解します。

１か所、日勤集合が夜勤明けに変更されていることが分かります。

解と並べて、予定が変更されられた理由を考えてみましょう。何故、スタッフ１０の予定、日勤集合の予定を夜勤明けに変えざるを得なかったのでしょうか？

　⇒夜勤明けをやるスタッフリソースがなかった、ということが直接的な理由です。

その他のグループAの予定は、未だ余裕があるように見えます。しかし、

■グループAの夜勤明け休み　１名

■グループAの夜勤者　　　　１名

■グループAの９月１９日予定　３名

■グループAの９月２０日予定が休みでないので、９月１９日を夜勤明けにできない　２名

■グループAの夜勤不可者　２名

■グループAの夜勤明け　　１名

全部足すと１０名となり、グループAの人数９名を上回ります。

これは矛盾です。

お客さまが開発したプロジェクトを見てー8

 次の青部パターンは、冗長です。

そもそも、当直－当直明けは、制約1－２番目の制約で、必ず対になっているので、パターンを拾って回数制約する必要はありません。当直だけで十分です。（パターンで行うとソルバに余計な負担がかかってしまいます。）

従い、次のように記述した方がよいでしょう。

お客さまが開発したプロジェクトを見てー7

以下のパターンも、前回と同じ間違いを含んでいます。

今回の指摘は、それだけではなく、夜勤間隔に関するものです。夜勤間隔6日以下を禁止しています。つまり、夜勤間隔は、１週間以上であることをハード制約としています。この制約があると、夜勤回数は、月４回以下が絶対ということになります。

何が問題かというと、全ての深夜Gメンバに対してそれを強いている、ということです。必ずそれを満たす保証があれば、問題ない記述ですが、中々それを保証することは難しいのではないでしょうか？

夜勤間隔が長いパターンは、ソフト制約として逃げる弁を付けてやるのが常道です。あるいは、スタッフ毎の夜勤回数制約に応じて、制約パターンを分けるというのも手です。

https://schedule-nurse.blogspot.com/2025/04/4endrelease-3.html

お客さまが開発したプロジェクトを見てー6

 次の記述のどこが「まずい」でしょうか？

Day集合を表示させてみると、「制約開始日二日前から」は、

となっています。１番目の制約は、次のように作用します。

最初のパターンは、先月部のみに作用します。先月部は、過ぎ去った過去なので、変えようがありません。自由空間である「今月」が全く絡んでこないので、そもそも制約するべきではありません。

一般に、先月部に対しては、「”パターン数－１”前から」にするのが常道です。

考えるのが面倒であれば、自動設計にして求解保存すると、次回プロジェクト読み込みから、正しく設定されます。

正しい曜日タイプは、以下のようになります。