Q. そろそろ1年が経過するころと思いますが、
①サブスク契約期間はいつまでになりますでしょうか？
メンテナンスしてほしいところがあり、いつまでならソフトのバージョンアップが行えるか確認の連絡でした。
Ans.
契約期間は、去年9月4日から1年になっております。
申し訳ありません。現在は、通常のメールサポートのみ、となっております。
どのようなご相談か、プロジェクトファイルを頂いて、簡単に対応できるようであれば、メールサポート範囲で対応します。
難しそうであれば、また1年間のプロジェクトサポートサービスのご利用をお願いすることになると思います。
まずは、ご要望内容をご相談ください。
ロールバックで、しばらく調子よかったが、その後また出るようになった。
結論：ロールバック後に再発する場合、原因はほぼ “ドライバそのもの” ではなく “Windows Update が勝手に別ドライバを入れ直している” 可能性が非常に高いです。 これは 2026年5月に Microsoft が公式に認めた既知問題で、実際に多くのユーザーで再発しています。
あなたの症状（しばらく安定 → 数日後に再発）は、この既知問題と完全に一致します。
Windows Update は「ハードウェアIDの粗い一致」でドライバを選ぶため → NVIDIA公式から入れた最新ドライバより “古いOEM版” を優先してしまう
結果： ロールバックして安定 → 数日後に Windows Update が勝手に別ドライバを入れる → 再発
これは 2026年5月に Microsoft が認めた不具合で、修正は 2026年末〜2027年初頭にかけて段階展開予定。
以下は、複数の専門サイトが推奨する再発防止策を統合した最適手順です。
Windows Update が勝手に上書きする限り、何度ロールバックしても再発します。
gpedit.msc を起動
「コンピューターの構成」
→「管理用テンプレート」
→「Windows Update」
→ “Windows Update でドライバーを含めない” を有効化
これで Windows Update が GPU ドライバを触れなくなります。 （複数の専門サイトがこの設定を推奨しています）
再発している場合、既に Windows Update による“混在状態”になっている可能性が高いです。
DDU（Display Driver Uninstaller）をセーフモードで実行
「Clean and restart」
再起動後、NVIDIA公式サイトから安定版を手動インストール
DDUは「残骸レジストリ」「古いINF」「OEM版の残り」を完全に消すため、 再発時の最も確実なリセット方法です。
2026年の 591.xx 系は不具合報告が多く、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の助けになります。よろしくお願いいたします。
Claudeに指示して作りました。
「ZoomのVirtual背景を制作して。先進のコンピュータルームにいるイメージで、未来志向の格好いいの。」
昨日打ち合わせした方には何も言われませんでした。
＜仕様とは？＞
プロジェクト作成サービスでは、お客様は、面倒なスケジュールナース上の制約についての知識は必要ありません。それでも、その職場のルールをお伝えいただく必要はあります。この職場のルールを「仕様」と呼んでいます。
「仕様を書いてください」というと、身構えてしまう方が多いのですが、大事なことは、自分の職場のルールを部外者である私に伝える、ということです。最初から完璧な水も漏らさないような仕様を書く必要はありません。最も重要なルールは何だろう？と、大事な事から記述していきます。
その職場のことを何も知らない部外者に伝える、ということは、その仕様があれば、その職場のルールを他で再現出来るようになる、ということでもあります。
言うなれば、その職場のルールを他で再現させる作業が、「仕様を書く」ということでもあります。
職場のルールは、日本語で記述するのが普通でしょう。この段階では、使用するソフトウェアに依存しません。つまり、スケジュールナース・その他のソフトウェアを使用する・しないに関係しないことに注意してください。整理して練り上げた仕様は、その職場の財産です。
＜仕様は作りあげていくもの＞
ナーススケジューリングは、意識されることのないルール「暗黙知」があることが前提となって、「機械では作れないもの」とされることが多く、またその主旨の学術論文が最近、複数出ています。が、スケジュールナースはそのような立場に立っていません。
Excelに出力した自動勤務解を見て頂くと、「そこは違う」という箇所が必ず出てきます。つまり、仕様にはなくても自職場ルールと違うことは、分かるのです。そういう場合に、そのルールを言葉にして頂ければよいのです。これを「仕様追加」と呼びます。仕様追加していくと、前の仕様と矛盾していることに気づかれるかもしれません。ルールに矛盾があるとき、制約化もできないので、そこを解消して頂くのは、お客さま自身です。ルールは、その場の思いつきであってはなりません。ルールなので、しょっちゅう変わってよい、ものでもありません。
こうした作業を通じて、その職場の普遍的なルールと必要な優先度順が逆に見えてきます。必然として、「その職場のルールの整理」が出来ます。
この自動勤務表をExcelで出力→違うところを指摘（ルールを言葉で伝える）→制約化、というループを数回行うと、自職場ルールをほぼ再現した自動勤務解が出来ます。大体よさそうだ、という時点で、発注をなさってください。
さらに細かな実装は、そのルールをファイルに収めたプロジェクトファイルをお渡しした上で行います。その際、使い方等をZOOMでお教えします。
＜仕様を書く力＞
仕様を人に伝えるにあたって、大事な能力は何でしょうか？ TVでよく解説をされている池上さんは、本当に分かりやすいですよね。池上さんと、言わんとしていることが良くわからないじれったい人との差は何でしょうか？ 他人とのコミュニケーション能力だ、という人もあるかもしれませんが、私は、一言で言うと、「国語力」だと思っています。
最近はAIの時代で、AIでプログラミングする時代になってきました。スケジュールナースもAI対応（言葉で制約を伝える）を準備していますが、AI時代でも、国語力の重要性は、変わりないというよりむしろ増している、のではないかと思います。
＜メンテナンス＞
プロジェクトファイルが出来上がって、数か月廻すと、細かな実装も落ち着いて実用的な解が出てきてやがて仕様追加することはなくなります。これで終わりではありません。勤務表は、メンテナンスがつきもので、スタッフの入職、退職、移動、役割の変更等により、常にルールは変わっていくものです。つまり、プロジェクトファイルのメンテナンスを誰かが行わないと、せっかく導入したソフトウェアが使えないものになってしまう恐れがあります。
それを防ぐには、自分達で、プロジェクトファイルを操れるようになる、必要があります。そのために、導入1年の間は、ZOOMレクチャを必要なだけ行えるようにしています。何回行っても無償です。
「スケジュールナースがAI対応するようになれば、学ぶ必要はないじゃん」、と思われているかもしれませんが、それは違います。何度も言いますが、大事なことは、ルールを他人に伝える力、この場合、他人＝AIであり、依然として国語力が大事なのです。
＜管理者＞
管理者も変わっていきます。管理者の頭のなかだけにあるルールが、その管理者が居なくなることによって失われるリスクがあります。しかし、その職場のルールが仕様という形で、整理・明文化されていれば、スムーズに移管できるようになるのではないでしょうか？
突然に、時刻が止まったままとなり、キーボード・マウスも効かなくなりました。WindowsEventログでも、何らかの不具合の痕跡は残っていません。この現象は、2日前から突然に、数時間間隔で発生しました。
Copilotに相談したところ、RTX5070TI等の最新GPUのドライバは、最初のリリースは安定しているが、その後のUpdateで当該事象を発生することが時々ある、とのことのようです。実際、DriverのUpdate履歴で見ると確かに、DriverがUpdateされていました。
WindowsUpdate→更新の履歴→ドライバの履歴
