COPTの評価ライセンスがExpire

 期限が切れたので、当該箇所を＃ifdef COPTで切り離しました。

今までの知見を基に、新たな標準解法を構築して行きます。とりあえずは、ひな形を人力で作ることにします。AIを使わないのは、いきなりAIに任せると理解が難しく結局デバグで手間取ることを避けたかったからです。安定したらコードの最適化はAIに任せようと思います。

私自身、新しいソルバがどのような結果になるのか、分かりません。ときどき、今までとの違いを説明して行きたいと思います。

凸性とは？

Q.凸性とは

凸性（convexity）とは、数学で「中間が極端よりも高く（または低く）ならない」形状・関数の性質のこと。 もっと具体的に言うと、2点を結ぶ線分が必ずグラフの上側（または同じ位置）にあるような関数や集合の性質を指す。

📘 1. 凸性の数学的定義（関数の場合）

関数 $f$ が凸であるとは、任意の $x,y$ と $t\in [0,1]$ に対して

$$f(tx+(1-t)y)\le tf(x)+(1-t)f(y)$$

が成り立つこと。 これは「グラフ上の2点を結ぶ直線（弦）が、常にグラフの上側にある」という幾何学的意味を持つ。

📐 2. 凸集合の定義（集合の場合）

集合 $Q$ が凸集合とは、任意の2点 $v_0,v_1$ を結ぶ線分

$$(1-\lambda )v_0+\lambda v_1,\lambda \in [0,1]$$

がすべて集合の内部に含まれること。

🔍 3. 凸性の判定（微分による判定）

1変数関数の場合：

• 二階微分が常に非負（$f^{\mathrm{\prime }\mathrm{\prime }}(x)\ge 0$）なら凸関数

• 二階微分が常に正（$f^{\mathrm{\prime }\mathrm{\prime }}(x)>0$）なら狭義凸（strict convex）

🧠 4. 凸性が重要な理由（最適化の観点）

凸性は最適化で極めて重要。理由は：

• 局所最小値 = 大域最小値 →「谷が一つしかない地形」と同じ

• 解が一意になる（狭義凸の場合）

• 多くのアルゴリズムが高速・安定に収束する

凸性は機械学習・制御・経済学・物理学などで広く使われる。

🧩 5. 凸性の例

• 線形関数（常に凸かつ凹）

• 二次関数 $f(x)=x^2$（凸）

• 指数関数 $e^x$（凸）

• 絶対値関数 $\mathrm{\mid }x\mathrm{\mid }$（凸）

• $-\log x$（凸）

🎯 まとめ

• 凸性＝線分がグラフの上側にある性質

• 二階微分が非負なら凸

• 最適化で「唯一の最小値」を保証する強力な性質

Q.単調増加と違うのですか？

いい質問。凸性（convexity）と単調増加（monotonicity）はまったく別の概念で、しばしば混同されますが、性質としては根本的に違います。

🎯 結論：凸性 ≠ 単調増加

• 凸性は「曲がり方（形状）」の性質

• 単調増加は「値の増え方（方向）」の性質

つまり、凸性は“カーブの形”の話で、単調増加は“右に行くと値が増えるかどうか”の話。

📘 1. 具体的な違い

🔹 単調増加とは

関数 $f(x)$ が単調増加とは：

$$x_1<x_2\Rightarrow f(x_1)\le f(x_2)$$

つまり、右に行くほど値が増える。

例：

• $f(x)=x$（線形）

• $f(x)=e^x$（指数）

• $f(x)=\log x$（単調増加だが凸ではない区間あり）

🔹 凸性とは

関数 $f$ が凸とは：

$$f(tx+(1-t)y)\le tf(x)+(1-t)f(y)$$

つまり、グラフが「下に向かって丸い」形。

例：

• $f(x)=x^2$（凸だが単調増加ではない）

• $f(x)=e^x$（凸かつ単調増加）

• $f(x)=\mathrm{\mid }x\mathrm{\mid }$（凸だが単調増加ではない）

🔍 2. 代表的な反例で違いが一発でわかる

❌ 凸だが単調増加ではない

$$f(x)=x^2$$

• 左側（$x<0$）では減少

• 右側（$x>0$）では増加

• しかし形はずっと「下に丸い」ので凸

→ 凸性と単調増加は独立。

❌ 単調増加だが凸ではない

$$f(x)=\log x$$

• 単調増加

• しかし二階微分は負なので凹（concave）

→ 単調増加でも凸とは限らない。

🧠 3. 最適化の観点での違い

あなたは最適化・Barrier・Branch-and-Priceに強い関心があるので、ここが重要。

🔹 凸性が保証するもの

• 局所最適 = 大域最適

• 唯一の最小値（狭義凸）

• Barrier・PDLPなどの収束性が保証される

🔹 単調増加が保証するもの

• 値が増える方向がわかるだけ

• 最適化の構造はほぼ何も保証しない

• 単調増加でも非凸なら局所解にハマる

→ 最適化では凸性が圧倒的に重要で、単調増加はほぼ役に立たない。

📌 まとめ

性質	何を意味する？	最適化で重要？
凸性	曲がり方（形状）	★★★★★
単調増加	値の増え方（方向）	★☆☆☆☆

Q.プロジェクト作成サービスの経過状態

 Q.　そろそろ1年が経過するころと思いますが、

①サブスク契約期間はいつまでになりますでしょうか？

メンテナンスしてほしいところがあり、いつまでならソフトのバージョンアップが行えるか確認の連絡でした。

Ans.

契約期間は、去年9月4日から1年になっております。

申し訳ありません。現在は、通常のメールサポートのみ、となっております。

どのようなご相談か、プロジェクトファイルを頂いて、簡単に対応できるようであれば、メールサポート範囲で対応します。

難しそうであれば、また1年間のプロジェクトサポートサービスのご利用をお願いすることになると思います。

まずは、ご要望内容をご相談ください。

RTX5070TIがまたフリーズ

 ロールバックで、しばらく調子よかったが、その後また出るようになった。

結論：ロールバック後に再発する場合、原因はほぼ “ドライバそのもの” ではなく “Windows Update が勝手に別ドライバを入れ直している” 可能性が非常に高いです。 これは 2026年5月に Microsoft が公式に認めた既知問題で、実際に多くのユーザーで再発しています。

あなたの症状（しばらく安定 → 数日後に再発）は、この既知問題と完全に一致します。

🎯 最重要ポイント（あなたのケースで最も起きやすい原因）

Windows Update が “古いOEM版ドライバ” を自動で上書きしている

• Windows Update は「ハードウェアIDの粗い一致」でドライバを選ぶため → NVIDIA公式から入れた最新ドライバより “古いOEM版” を優先してしまう

• 結果： ロールバックして安定 → 数日後に Windows Update が勝手に別ドライバを入れる → 再発

これは 2026年5月に Microsoft が認めた不具合で、修正は 2026年末〜2027年初頭にかけて段階展開予定。

🔧 今すぐやるべき対策（再発防止のための“正しい順番”）

以下は、複数の専門サイトが推奨する再発防止策を統合した最適手順です。

① Windows Update の「ドライバ自動更新」を止める（最重要）

Windows Update が勝手に上書きする限り、何度ロールバックしても再発します。

方法（Windows 11 Pro / Enterprise）

1. gpedit.msc を起動

2. 「コンピューターの構成」

3. →「管理用テンプレート」

4. →「Windows Update」

5. → “Windows Update でドライバーを含めない” を有効化

これで Windows Update が GPU ドライバを触れなくなります。 （複数の専門サイトがこの設定を推奨しています）

② DDU で完全削除 → 安定版を手動インストール

再発している場合、既に Windows Update による“混在状態”になっている可能性が高いです。

手順（要セーフモード）

1. DDU（Display Driver Uninstaller）をセーフモードで実行

2. 「Clean and restart」

3. 再起動後、NVIDIA公式サイトから安定版を手動インストール

DDUは「残骸レジストリ」「古いINF」「OEM版の残り」を完全に消すため、 再発時の最も確実なリセット方法です。

③ 安定版ドライバを選ぶ（5070Ti で特に重要）

2026年の 591.xx 系は不具合報告が多く、5070Ti でも再発例が多数あります。

5070Ti の安定版候補

• 572.16（安定性が最も高いと評価）

• 572.83（ほぼ安定、軽微な報告のみ）

• 566.36（ロールバック推奨として複数サイトが言及）

逆に 591.xx 系（591.59 / 591.74 / 591.86） は ブラックアウト・ちらつき・G-SYNC異常などの報告が多いので避けるべきです。

→とアドバイスされたのですが、古いドライバが見つかりませんでした。（最近10件位までしかでません）

572.16や、572.83でググると見つかりました。572.16は、インストール出来ず、572.83をインストールしました。

今後の実装計画とお願い

１年半も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)については、根源的仕様を変えます。それについては、別に機会を設けて説明したいと思います。

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

１）COPT Barrier Solverでのデータ採取

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

２）INRC2データ採取

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

３）汎用化実装

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

４）制約関数の実装

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

５）MCP

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

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

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

６）Regression Tests

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

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

Xでツイート

 schedule_nurse（@NurseSchedule）さん / X

ZOOMの背景を作った

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

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

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