Q.職員一名の入れ替わりがあり、今回新職員を入れて回してみましたが、解が出ませんでした。まだ、予定入力もしていないので、解が無いということはないかと思うのですが、どこか設定が誤っていないか教えていただけると幸いです。データ添付します。
Ans.申し訳ございません。Python記述のバグが原因と推察します。勤務日数が記述されていないときの問題を修正しました。
＜原因＞
下記は、当該記述ルーチンです。スタッフプロパティシートでの勤務日数の値(浮動小数）を読み込んで2倍にしたあと整数化しています。このとき、スタッフプロパティシートでの記載がないと、max値が-2になってしまいます。これがソルバでの違反となり不正動作で落ちていました。
スタッフプロパティシートでの記述がなくても、動作するように記述を追加しました。
ご迷惑をおかけしまして、大変申し訳ございません。
Q.ラベル設定法の枝刈りにDUAL下界を用いている論文は?
ラベル設定法（Label Setting Algorithm）の枝刈りにDual（双対）下界を用いる手法は、特に列生成法（Column Generation）を用いた車両配送問題（VRP）や乗務員スケジューリング問題などの求解において一般的です。 この手法を採用している代表的な論文および研究は以下の通りです。
列生成法の価格付け問題（子問題）として「制約付き最短路問題（ESPPRC）」を解く際、ラベル設定法が使われます。このとき、マスター問題の双対変数を利用して「現在のラベルから終点までの最小コスト」の下界を見積もり、暫定解より悪くなることが確実なラベルを切り捨てる（枝刈り）手法が取られます。
特定の論文を探している場合、"Decreasing the search space of the label setting algorithm using dual bounds" や "Dual-based pruning in ESPPRC" といったキーワードで、Google Scholar等にて検索すると、対象の論文（特に分枝価格カット法：Branch-and-Price-and-Cutに関連するもの）が見つかる可能性が高いです。 具体的にどの問題設定（例：VRP、飛行機の乗務員運用など）での論文をお探しですか？
[1] https://www.researchgate.net [2] https://proceedings.mlr.press [3] https://arxiv.org [4] https://www.foresight.jp [5] https://www.netattest.com [6] https://dspace.mit.edu [7] https://arxiv.org
Q.ラベル設定法が最新の研究でも使われているということですね。では、ラベル設定法で、ネックになっているのは、どのような問題でしょうか?
ラベル設定法が現代でも研究され続けているのは、それが依然として最強の解法であると同時に、解決すべき「計算量の爆発」という大きな壁があるからです。 特にネックとなっているのは、主に以下の3点です。
ラベル設定法では、あるノードに到達した際に「コストは高いが時間は短い」「コストは低いが時間は長い」といった、互いに優劣をつけられない非支配ラベルをすべて保持する必要があります。
前述のESPPRCにおいて、「同じ場所を二度通らない（巡回禁止）」という条件を厳密に守ろうとすると、計算負荷が跳ね上がります。
列生成法の中でラベル設定法を使う場合、マスター問題から渡される「双対変数」が反復ごとに激しく変動します。
これらのネックを解消するために、以下のような工夫が研究されています。
Q.アカデミックベンチマークサイトはありますか?ラベル設定法が用いられているものの分野ならば何でもOK.
ラベル設定法（Label Setting Algorithm）やその応用であるESPPRC、車両配送問題（VRP）の分野で世界的に利用されている主要なアカデミックベンチマークサイトを紹介します。 研究論文で性能比較を行う際、以下のサイトにあるデータセットを用いるのが「標準」となっています。
VRPやその派生問題に関する世界最大級のリポジトリです。
ラベル設定法をESPPRC（サブ問題）として解く「時間枠付き車両配送問題（VRPTW）」において、最も歴史があり、かつ現在も使われ続けているデータセットです。 [4]
オペレーションズ・リサーチ（OR）全般のテスト問題を網羅した老舗のサイトです。 [5]
アルゴリズムの実装と性能を競う「チャレンジ」のアーカイブです。
CVRP（Capacitated VRP）に特化したベンチマークサイトです。 [9]
これらのサイトからデータをダウンロードし、ご自身のアルゴリズムで「計算時間」や「解の精度（BKSとの乖離）」を測定するのが、アカデミックな評価の一般的な手順です。 まずはSolomonのインスタンスか、最新のVRP-REPからご自身の研究テーマに近いものを探してみるのがおすすめです。特定の制約（例：電気自動車、マルチデポなど）に特化したデータをお探しですか？
[1] https://www.vrp-rep.org [2] https://www.researchgate.net [3] https://www.bvl.de [4] https://ieeexplore.ieee.org [5] https://www.brunel.ac.uk [6] https://www.researchgate.net [7] https://www.researchgate.net [8] https://arxiv.org [9] https://www.sciencedirect.com [10] https://www.researchgate.net
厳密解（Optimal Solution）と未解決問題（Best Known Solution）が混在し、アルゴリズムの性能を測るのに「程よくバランスが良い」サイトといえば、CVRPLIB が筆頭に挙げられます。 特にこのサイト内の 「Uchoa et al. (2017) Instances (X instances)」 というデータセットが、現在の研究におけるデファクトスタンダードです。
まずは CVRPLIB の「Instances」ページにある Set X を覗いてみてください。
この分野（ラベル設定法、ESPPRC、および車両配送問題の厳密解法）には、数十年にわたり理論と実装の両面をリードしてきた「権威」と呼ばれる研究者が数名います。 彼らの論文を辿れば、この分野の主要な技術（双対下界による枝刈り、ng-path、双対安定化など）の変遷をほぼ網羅できます。
カナダのモントリオール理工科大学教授。この分野の「バイブル」とも言える書籍 『Column Generation』 の編者の一人です。 [2]
フランスのサン＝テティエンヌ国立高等鉱業学校教授。
ドイツのマインツ大学教授。
ボローニャ大学（イタリア）の教授陣。
ブラジルのリオデジャネイロ・カトリック大学教授。前述の CVRPLIB の運営者でもあります。
紹介した権威者たちの論文や最新の研究で、マスター問題（線形計画問題：LP）を解くために用いられている主なLPソルバは以下の通りです。 ラベル設定法自体は動的計画法に基づく独自のアルゴリズムですが、その実行に必要な「双対変数」を計算するために、以下の商用・非商用ソルバがプラットフォームとして利用されています。
最先端の研究（特に大規模なベンチマークで世界記録を狙うもの）では、計算速度と数値的安定性の観点から商用ソルバがほぼ独占的に使われています。
研究の公開性やライセンスの制約がある場合に使用されます。
権威者たちは、上記のLPソルバを裸で使うのではなく、VRPに特化した自作のフレームワークに組み込んで使用しています。
[実装へのアドバイス] もしご自身で実装を検討されているのであれば、アカデミックライセンス（無料）が利用可能な Gurobi または CPLEX を選択するのが最も無難です。この分野の論文に記載されている計算時間と比較する際、ソルバの性能差を考慮しなくて済むためです。 [3] 特定の開発言語（C++, Python, Juliaなど）で使えるソルバの具体的な導入方法について興味はありますか？ [参考ソース]
Dominate比較本数 ラベル設定法において、1つのノードで保持されるラベル数（ドミナンス比較の対象となる本数）は、問題の規模や制約の厳しさによって劇的に変わりますが、「一般的」なオーダーとしては以下のようになります。
比較本数は以下の条件で指数関数的に増加します。
権威者たちの論文（Irnich, Desaulniersなど）では、数千〜数万本の比較を効率化するために以下の手法が「一般的」に組み込まれています。
結論として、厳密解法を目指すなら 1ノードあたり数千本 まではメモリ上に保持し、高速に比較できる実装（ソート済リストや多次元インデックスなど）を準備しておくのが標準的な設計スタンスです。 現在想定されている問題の「ノード数」や「資源の数（時間・容量など）」はどの程度でしょうか？
おっしゃる通り、Max-Min制約（特に「最低でもこれだけ消費しなければならない」という下限制約）は、ラベル設定法にとって最悪の相性の一つです。 通常、資源が「消費（加算）」されるだけなら、資源を多く消費したラベルが「支配される（捨てられる）」可能性が高まります。しかし、下限制約（例：最低作業時間、最低走行距離）があると、「今は資源を多く消費しているけれど、そのおかげで将来的に下限制約をクリアできる（かもしれない）」というラベルが捨てられなくなるため、非支配ラベルが爆発します。 この問題に対して、最新の研究や権威者たちは主に以下の3つのアプローチで対応しています。
もし資源消費がある一定のポイントでリセットされたり、特定の範囲に収まる必要がある場合、ラベルに持たせる資源の値を「余裕（Slack）」や「不足分」に変換して管理します。これにより、ドミナンス（支配関係）が成立しやすい形に正規化します。
質問の最初に出てきたDual下界がここで威力を発揮します。
数万本のラベルをまともに比較するのは不可能なので、資源消費空間をグリッド（バケット）に分割します。
Q.小中規模でも厳密解が得られていない例
結論から言うと、ノード数が50〜100程度の「小中規模」に見える問題でも、特定の条件下では未だに厳密解が得られていない、あるいは解くのに膨大な時間を要する難問が厳然として存在します。 単なる「地点間の距離」だけでなく、以下の要素が組み合わさると、ラベル設定法は途端に機能不全に陥ります。
意外かもしれませんが、制約が緩い（時間枠が広い、積載容量が大きい）ほど難易度は上がります。
積載量に応じて燃料消費率が変わる、あるいは「回生ブレーキ」のように資源が途中で増減する場合です。
「車両Aと車両Bが特定の場所で同時に落ち合わなければならない」といった、車両間の依存関係がある問題です。
前述の CVRPLIB (Set X) などでは、ノード数100以下のものはほぼ解かれていますが、それは「標準的な制約」の場合です。 しかし、「Solomon's instances」 のような古典的なデータセットでも、時間枠を極端に広げたり、車両台数を制限したりする変種（Variants）に書き換えると、世界中の研究者が挑んでも解けない「Open Instance」に変貌します。
有難く、延長評価ライセンスを取得しました。
具体的には、再度トライアルライセンス6カ月を取得することが出来ました。（PaperでCOPTに言及する予定です）。有難うございました。
これで後、半年、研究できるのが喜びです。
Instance24を解くために、この半年、技術開発を行ってきました。正確には、
■既存技術で立ち向かったものの、どうやっても解けない→今年1月になってから新たな技術開発
を行なってきました。核になる要素技術は、未だ研究開発中ですが、かなり今までと異なっています。高度な背景技術のさらに上を行く新たな最適化技術なので、難解でありAIと相談・整理しながら理論的な詰めを行っています。この技術は、NSPだけではなく、もう少し広い分野で利用可能な技術です。
今後は、この新技術について、
■NSPの核として日本否世界中のシフト勤務者がこの技術の恩恵を受けられるようにすること
■RCSPの新解法としてIPを広く世界に提供すること
を主眼として活動していきたいと思い始めました。
このため、一旦開発計画は白紙として、もう少し固まってから、ロードマップは明らかにしたいと思います。
半年のトライアル期間に解くことは、出来ませんでした。この間、ほぼこの問題を解くことだけに集中してきたのですが、力及びませんでした。ただし、この研究期間に発見した二つの新しい方法を使えば、可能性は出てきました。そこで、COPTにライセンスの延長をお願いし，挑戦を継続することにしました。
Dear COPT Support Team,
Thank you very much for your continued assistance and for providing access to the COPT Optimizer.
Over the past six months, I have been using your solver to tackle the final remaining open instance (instance24) in the following benchmark:
https://www.schedulingbenchmarks.org/changes.html
However, the research has taken significantly longer than originally expected, and I now require additional time to complete the work.
Therefore, I would like to kindly request a six‑month extension of my evaluation license.
Once the instance is successfully solved, I plan to publish a research paper that will properly cite and acknowledge the use of the COPT Optimizer.
COPTからは、subscriptionを勧められましたが、それは考えていないことを伝えました。
Dear COPT Support Team,
Thank you very much for your continued support and for your kind offer to discuss subscription options.
At this time, I am not considering a subscription license. For my practical, real‑world instances, solvers such as CLP, HiGHS, and CuPDLPx are fully sufficient. In fact, except for the very last remaining open instance, I have been able to solve all unresolved academic benchmark problems using these solvers.
However, the final instance is exceptionally large, and based on my experience, it is extremely difficult to handle within a reasonable time frame without the performance of your solver. This is why I have been relying on COPT specifically for this last challenge.
Thank you again for your understanding and for taking the time to consider my situation.
例えば、累計シフト制約で、累計シフト数≦１０であったとします。
この時最適解が、累計シフト９であったとすると、
■そのDualは、０
となります。つまり、制約境界10に接しておらず、余裕（スラック）が１あります。この制約を微小に変化されても目的関数は変化しません。よって、制約に対する目的関数への寄与は0、ということになります。
では、MIN側にも制約があった場合は、どうなるでしょうか？ ６≦9≦10 の場合も余裕があるので、
■そのDualは、０
となります。
もう一つ制約があって、特定シフト回数≦３ と言う制約があって、最適解時の回数が3であったとします。こういう境界に張り付いた状態であるときだけ、Dualは、0にはならない、ということが出来ます。逆に言うと、Dualが0である制約は、効いていない、ということになります。
久保先生の著書中、「最適化理論に関するプロとアマの違いは、双対性や、相補性の意義を理解し活用できるかどうかである」、とあります。私自身、双対性に関しては、完全に使いこなしている訳ではないのですが、最適化を実装する上においては避けて通れません。
DUALは、目的関数ー制約が表裏一体の関係にあるという考え方です。最適化と言った場合、
■制約違反のペナルティ量を最小化する、目的関数の値を最小化すること
■制約を緩和―厳しくすること
は、独立していなくて関係がある、と言うことを示しています。一般にSimplex法で解く場合、Primalで解くかDualで解くかは、指定があります。問題を解くのに、二つのやり方があって、どちらで解いても答えは同じになる、ということでもあります。（しかし、求解時間は一般的にインスタンスにより異なる）
＜リソース制約が効いているかどうかを判定することが出来る＞
例えば、次は、Instance13のログです。
ラベルとは、RCSPにおいて、経路状態を表現する言葉です。
ドミナンス（Dominance：支配）とは、「ある経路（ラベル）が別の経路よりも明らかに優れているため、劣っている方を探索から除外する」という判断基準のことです。
不要な探索の削減（枝刈り）
あるノードに至る2つのラベル とを比較したとき、全ての指標において、同等以上に優れていて、少なくとも一つが上回るとき、Pruningできます。
もし がすべての指標（コスト、時間など）において 以上に優れており、かつ少なくとも1つの指標で を上回っている場合、「 ｘは ｙを支配(Dominate)する」と言います。
支配されたラベル は、その先をどのように延長しても を延長した経路より良くなることはないため、それ以上探索する必要がなくなり、破棄されます。
＜Min制約をどうする？＞
ラベル設定法や動的計画法において、MIN制約（「〜以上でなければならない」という下限制約）をMAX制約（「〜以下でなければならない」という上限制約）に変換する一般的な手法は、「残りの必要量」に着目する、または「変数の反転」を行うことです。Max制約になれば、「とにかく小さいほうが良い」というDominate Ruleで枝刈り出来ます。
具体的には、以下の2つのアプローチがよく使われます。
1. 「残りの必要量」を状態変数にする（推奨）
「現在の蓄積量」を管理するのではなく、「目標達成までにあとどれくらい必要か」をリソース（ラベル）として管理します。
変換前（MIN制約）:
状態：現在の合計値
制約： （ 以上のリソースが必要）
変換後（MAX制約）:
状態：残りの必要量
初期値：
各ステップ：リソースを消費するごとに を減らす（0以下になったら目標達成）
制約：なし（または が 0 になることを目指す）
これにより、「下限値を突破する」という条件を、「初期値（上限）から減らしていく」というMAX制約に近い形に落とし込めます。
2. 変数の反転（ネガティブ変換）
単純に符号を反転させる方法です。
変換前:
変換後:
ラベル設定法のアルゴリズム内で「リソース消費量」を正の数で扱いたい場合は、「余裕（スラック）」を定義します。
＜問題はMIN-MAX制約＞
MIN-MAX範囲がある場合は、注意が必要で、同じリソースに対して、異なる方向にドミナンスが働くことになります。そのまま実装すると矛盾した枝刈りとなり最適解を失い、最悪は、Infeasibleな結果となります。
単純に、MINまでは、大きいものが強い、MIN以降は、小さいものが強い
とすれば、良いような気がします。しかし、そのロジックで単純に片方を捨ててしまうと、厳密解（最適解）を失う可能性が非常に高いです。
なぜなら、ラベル設定法におけるドミナンスの鉄則は「将来のいかなる拡張に対しても、一方のラベルがもう一方より必ず良い結果をもたらす」と言い切れるときだけ、劣る方を捨てるというものだからです。「Minまでは大きい方が強く、Min以降は小さい方が強い」という切り替え方式では、「将来どちらの制約がネックになるか」が場所によって変わるため、厳密解が消えるリスクがあります。
Σai(xi)≦b[min:max]のとき、row price(dual)は、どちらを指すか？ 悩ましいのですが、それは、Row Activityをみて判別するということのようです。LPSolver毎に、この辺の扱いは異なるようで、注意が必要です。LPSolverに依存しない形ならば、bのMIN/MAXを分離して記述すればよいでしょう。
判別は、bを見て、bになっている方が効いている制約になります。
Ans.前回、病欠時のエラーを安直は方法で回避しましたが、今回は、恒久対策の方法を述べます。
問題の発端は、公休ラベルが以下のように多数、使用されていることにあります。
Ans.
マイクロソフトアカウント名が分からないと購入履歴が分かりませんし、サブスクを停止することは出来ません。アカウント名が分からない場合は、ググると色々な方法があるようですが、マイクロソフトストアに紐づいているアカウント名であることが必要です。
今、スケジュールナースを使用出来ているのであれば、必ずマイクロソフトストアに紐づいたマイクソフトアカウント名が存在し、以下の方法で、購入履歴を確認することが出来ます。
スケジュールナースを使用出来ない状態であれば、今から述べる方法は使えません。
１）マイクロソフトストアを出します。
しばらく、サインインしていない場合は、認証が行われることがあるようです。認証をクリアした前提で話を勧めます。
上のアカウント名をクリックすると、サインインのアイコンが変化します。
Ｑ．病欠者がいる場合の勤務表設定についてご相談です。
ｘｘｘｘが5月10日から病欠となり勤務できないため、公休（22日間）予定として入力しました。
以前のやり取りを参考に夜勤「責任者」を外して求解しましたが、エラーとなってしまいます。
Highsがまた進歩するようです。Hipoが期待外れだった分、HiPDLPに期待が高まります。
HiGHS 26.0 Newsletter（2026年4月号）は、
第3回HiGHSワークショップの開催案内、HiPO（新IPMソルバー）の進展、MIPソルバーの並列化、GPU版PDLPの刷新、資金調達、Python対応の進行状況、新メンバー紹介
を中心に報告しています。
この号は、HiGHS の 並列化・GPU化・QP対応の強化が一気に進んでいること、
そして v1.15 に向けた大規模アップデートが近いことを示す内容になっています。
Q.職場に自動作成ソフトが導入される事となり、私自身も部署が変わりリスト作成をしなくなりますので退会をお願いしたい次第です。
この解法は、グラフ中に複数の累計状態（パレート）を維持することにより求めるものです。
私は、これまで実装したことがなかったのですが、計算量の見積もりのために、実装してみることにしました。
この解法で、必要になる概念は、下記の二つです。
■ラベル
■Dominate 支配する→
https://schedule-nurse.blogspot.com/2026/04/blog-post_13.html
ここで、ラベルというのは、累計状態を指す、用語です。今グラフがあるとします。
Graph Elements=1711 Label Sum=5348323 Max labels per Node=18204
\tcost=12.0111 67,0,6,2,1,0,0,0
\tcost=12.0111 67,0,5,2,2,0,0,0
\tcost=12.0111 68,0,8,2,0,0,0,0
\tcost=12.0111 68,0,5,1,3,1,0,0
\tcost=12.0111 68,0,6,1,2,1,0,0
\tcost=12.0111 68,0,7,1,1,1,0,0
\tcost=12.0111 68,0,8,1,0,1,0,0
\tcost=12.0111 67,0,5,1,4,0,0,0
この一つ一つの行がラベルという呼称になります。ラベルというのは、最適値を得るために区別が必要な（最小限度の）状態名の呼称です。
グラフエッジをたどることによって、次のノードへと移行していき、最終的には終端します。終端での累計状態が、元々の不等式[最大、最小]にマッチしていれば、feasibleな解となり、マッチするものがなければ、infeasibleとなります。feasibleな解のうち最小のものを最適値（目的関数値）とすることができます。
終端に辿り着くまで、その累計制約を満たすかどうかは、一般には分かりません。直前の状態ならば、明らかに満たさないということは分かりますが、中間点、例えば上記のノード状態で、終端時にどのように累計状態が成長するかは、分からないので、とにかく状態を維持して終端まで進むしかありません。
累計制約の本数が多いと、容易に爆発します。如何に状態、ラベル数を少なくできるか？がこの方式のポイントです。状態を少なくすることを枝刈り(pruning)と呼んでいます。
インスタンス13では、8本程度の累計制約があるのですが、すでにこの段階で、枝刈りなしには、reasbleな時間内に解くことはできません。
Resource Constraint Shortest Path Problemの略です。問題をサブ問題に分割した時に、結局この形となるのがNSPの本質的なところです。
で、何が難しいかというと、この問題自体が、NP困難という問題分野に分類されます。しかも、
結論だけ先に言うと、はい、Resource‑Constrained Shortest Path（RCSP／RSCP）は一般に NP 困難（NP‑hard）です。しかも「最短路＋複数リソース制約」という構造のせいで、強 NP 困難（strongly NP‑hard）に分類されます。
最短路自体は P（多項式時間）で解ける → しかし「累積制約」が入った瞬間に NP-hard へジャンプする
これは RCSP の本質的な性質で、 どんなにグラフが単純でも、累計制約がある限り避けられません。
つまり、Cardinality 累計制約が入っただけで、途端に難しくなる、ということです。子問題が、強NP困難なら、当然子を含む問題NSPは、強NP困難ということになります。子だけでも難しいのにさらにもう一次元加わります。
インスタンス24の求解にこんなにも手間取っているのは、このシフト数32にプラス強烈なCardinality制約のおかげです。
単純にFowardとBackwardを使うと上手く行きません。
下図で、前方和と後方和を各々足して、各ノード共、a+b+cにしたいのですが、
単純にすると、そうはならないことが分かります。
0/1 Branchingだと、1側が重いのに比べて0側は、軽い、と言うかあまり効かないことが多いです。こうした偏りを是正する方法として、Ryan-Foster Branchingと言う方法があります。
例えば、
休休 A
勤勤 B
休勤 C
勤休 D
A/B とC/DでBranchingします。比較として、通常ブランチ
休
～休み
を考えてみます。休＝１でブランチとすると、これはかなり強い限定になります。しかし、～休=0のブランチは、休み以外を選択するわけで、弱い限定になります。この傾向はシフト数が多くれば多いほど、強まります。１が強い限定を生み、0が弱い限定しか生まない、ということは、Tree構築においてバランスが悪い結果となります。1ブランチの枝は短いのに対して0枝は、長い枝になります。なので、なるべく同じ確率となるようにしたい訳です。これが、Ryan-Foster Branchの背景になります。
複雑な割には、効果が少ないと判断して、スケジュールナースでは採用していませんが、SCIPでは、割に使っているようです。
またしても、アプローチが失敗しました。
キャパシティカットが良さそうでしたので、
https://schedule-nurse.blogspot.com/2026/03/blog-post_22.html
さらにこの発想を強めて(Tightening)、Day毎の累計制約として抽出しました。具体的には、休み数制約（制約としては存在しないものの時間制約や総勤務数制約に相当）と、土日勤務数制約のDay毎の累計制約として取り出して、LB取得後にMIPソルバに投げるというものです。この方法をCumulative Capacity Cutと命名しました。発想は、Roster毎の資源総計だけではなく、Day毎の資源を明示することによって、Cover制約達成を促進する狙いです。
結果は、
この結果、Lpソルバが真のUB値と等しくなったときに、UB値でカットオフしなくとも（MIPソルバは真のUB値を知らない）MIPソルバは一瞬で、UB値を算出できる、←SATソルバより速い、ということが分かりました。
で、問題はインスタンス13になります。このインスタンスに関しては、期間は1カ月であるもののシフト数は19と多く、スタッフ数120人と、いわばインスタンス24のミニチュア版、と見ることもできます。残念ながら、Lpソルバの段階で、真のUB値には遠く、MIPソルバに渡しても、長期の時間がかかっています。ただ、COPTにしても解けなかったインスタンス13が有限時間内に解けるようにはなったので、一定の効果があることは分かります。
まとめとして
１）LpソルバのLBが真のUB値に等しいとき、MIPソルバが最強。SATソルバより速い
２）LpソルバのLBが真のUB値から遠ければ遠い程、MIPソルバが解けない可能性が高まる
３）LpソルバのLBを上げることは正義
ということが分かりました。市井の実務インスタンスは、インスタンス8程度なので、実務インスタンスにおいてMIPソルバを活用できる場面もある、と考えます。(SAT整数化より速い場面もある。)
いずれにせよ、このアプローチで進んで、インスタンス24が解ける見込みはないと判断しました。（ミニチュア版でこの遅さなら、超巨大インスタンス24が解ける筈がない）
