2026年10月31日土曜日

インクリメンタル　アクセスとデクリメンタルアクセス

データ構造を作り直すことにしました。ついては、アクセス方法の違いについて聞きました。

インクリメンタル　アクセスとデクリメンタルアクセスで、キャッシュヒット特性に差はありますか？

インクリメンタルアクセス（アドレスが順方向に増加）とデクリメンタルアクセス（アドレスが逆方向に減少）では、キャッシュヒット特性に明らかな差が出ることがあります。

この差は主に、現代のプロセッサに搭載されているハードウェアプリフェッチャ（事前読み込み機能）の挙動や設計に起因します。

主な違いと特性は以下の通りです。

1. ハードウェアプリフェッチャの対応度

現代のCPUは、次にアクセスされるデータを予測してキャッシュに先読みします。

インクリメンタル（順方向）：
- ほぼすべてのプロセッサのプリフェッチャが完璧に対応しています。
- 連続的な順方向アクセス（A, A+1, A+2...）を検出すると、自動的に先読みが行われるため、キャッシュヒット率は非常に高くなります。
デクリメンタル（逆方向）：
- 多くの近代的なCPU（IntelやAMD、ARMの高性能コアなど）は逆方向のストライド（A, A-1, A-2...）も検出できます。
- しかし、古いアーキテクチャや、低消費電力向けの簡易なプロセッサ（一部の組み込み向けコアなど）では、逆方向のプリフェッチに対応していない、あるいは順方向に比べて検出の優先度が低い場合があります。この場合、デクリメンタルアクセスではキャッシュミスが多発します。

2. 空間局所性とキャッシュラインのマッピング

メモリは「キャッシュライン（一般的に64バイト）」という単位でキャッシュに読み込まれます。

インクリメンタル：
- キャッシュラインの先頭（オフセット0）から末尾に向かってアクセスが進むため、1度のキャッシュミスで読み込んだラインをフルに活用できます。
デクリメンタル：
- キャッシュラインの末尾から先頭に向かって逆順にアクセスします。
- プリフェッチが効かない環境では、「新しいキャッシュラインにまたがった瞬間（境界を越えたとき）」に必ずキャッシュミス（レイテンシ）が発生し、その後そのラインの残りのデータを逆向けに消化していく形になります。データの利用効率自体は同じですが、ミスの発生するタイミングやプリフェッチの起動タイミングが狂いやすくなります。

まとめ（比較表）

特性	インクリメンタルアクセス (順方向)	デクリメンタルアクセス (逆方向)
一般的なヒット率	非常に高い（安定）	高〜中（CPUのプリフェッチ能力に依存）
ハードウェア先読み	確実に動作する	CPUによっては動作しない・遅れる場合がある
不利益を被る環境	特になし	古いCPU、組み込み向けCPU、GPUの一部など

結論として：
最新のPCやサーバー向けCPUであれば、どちらも高いヒット率を維持できるよう設計されていますが、ハードウェアの最適化は常に「インクリメンタル（順方向）」を最優先に設計されているため、迷った場合はインクリメンタルなアクセス経路（例：多次元配列をループさせる際の順序など）を選択するのが安全です。

2026年10月30日金曜日

なぜ、ナーススケジューリング問題では、絶対指標ベンチマークへの言及がないか？

VRP等の新しい論文では、各ベンチマークの言及が必ずあると思いますが、最近のナーススケジューリング問題の論文では、ないのが不思議です。以下は、AIの回答ですが、本当の理由は別なところにあると思います。

ナーススケジューリング問題（NSP: Nurse Scheduling Problem、またはNRP: Nurse Rostering Problem）の最近の論文で、VRP（車両ルーティング問題）のような「統一された絶対的な標準ベンチマーク」への言及や共通データでの比較が少なく見えるのは、研究者の間でもよく指摘される非常に鋭い着眼点です。

VRPではCVRPTWやGehring & Hombergerなどの決定版ベンチマークが存在し、全員が同じ土俵で競いますが、ナーススケジューリング問題でそれが難しいのには、この問題特有の背景や構造的な要因があります。

主な理由は以下の4点に集約されます。

1. 法規制や現場ルールが「国・病院ごとに違いすぎる」

VRPは「容量制限」や「時間枠」など、物理的・数学的にモデルを標準化しやすい特徴があります。しかし、ナーススケジューリングは「人間（労働者）」を対象としているため、制約が極めてローカルかつ複雑です。

国による法規制の違い: 週の最大労働時間、夜勤後のインターバル（休息時間）の法的義務などが国ごとに全く異なります。
病院・病棟ごとのローカルルール: 「AさんとBさんは仲が悪いので同じシフトにしない」「この病棟はベテランを必ず1人配置する」といった、数式化しにくいソフト制約（Soft Constraints）が無限に存在します。

結果として、ある論文が提案した優れたアルゴリズムも、別のデータセット（別の国のルール）にはそのまま適用できないケースが多く、共通のベンチマークで横並び比較する意義が薄れてしまうのです。

2. インスタンス（問題データ）の寿命とプラットフォームの断絶

過去に国際コンペティションなどで標準ベンチマークが作られなかったわけではありません。

INRC (International Nurse Rostering Competition): 2010年（INRC2010）や2015年（INRC2015）に世界大会が開催され、標準データセットが公開されました。
第一線での風化: VRPのベンチマークが何十年も使われ続けるのに対し、NSPのコンペデータは「制約が当時の特定のモデルに依存しすぎている」ため、新しい解法（例えば最新の深層強化学習やLLMベースのメタヒューリスティクス）を適用しようとすると、データのパースや制約の再現が非常に難しく、敬遠されがちです。

3. 近年の論文の関心が「実用性・動的対応」にシフトしている

最近のNSPの論文では、静的な標準データをいかに速く解くかよりも、「現実の運用で使えるか」に焦点が当たっています。

動的・確率的アプローチ: 急な欠勤（看護師の体調不良）や患者数の変動に対応する「リロスタリング（再スケジューリング）」や「確率的プログラミング」の研究が増えています。
独自データの使用: そのため、著者が所属する国の実際の病院から提供された「リアルだけど独自のデータセット」を使って評価を行う論文が多くなり、結果として共通のベンチマークへの言及が減っています。

4. 評価指標（目的関数）を統一できない

VRPの目的関数は基本的に「総移動距離の最小化」や「車両台数の最小化」であり、明確です。
一方、NSPでは「病院側のコスト最小化（超過勤務手当の削減）」と「看護師側の満足度最大化（希望休の反映）」という相反する多目的最適化になります。何を最優先（あるいはどう重み付け）するかは病院ごとに異なるため、あるベンチマークスコアで「勝利」したとしても、それが本当に優れたアルゴリズムなのかを測るのが本質的に難しいという問題があります。

💡 まとめると
VRPが「綺麗に舗装されたサーキットでタイムを競うレース」だとすれば、ナーススケジューリングは「病院ごとに地形が変わる泥道を走るラリー」のようなものです。そのため、最近の論文では共通ベンチマークのスコアよりも、「いかに複雑で現実的な制約の組み合わせを破綻させずに解けるか（表現力と柔軟性）」に重きが置かれているのが、ベンチマークへの言及が少なく見える最大の理由です。

2026年10月29日木曜日

ナーススケジューリング問題ソルバ

2026年になっても、未だ色々な方式が提案されています。

＜各ベンチマークについての言及がない＞

ASPに基づく適応型優先度付き巨大近傍探索の実装とナーススケジューリング問題への適用
 JSME-TJ
ナース・スケジューリングの論文、勤務表づくりに使える?|手組みゼロ

不思議なことに、アカデミックかつクラシカルなベンチマークがいくつもあるのに、それらに対しては、言及がありません。この傾向は、日本に限らず海外文献でも同様です。最近の論文流行は、AIを使った当該病棟でのモデル改善ですが、これは、モデリングの改善であって、ソルバ性能の改善ではありません。ソルバは、MIPソルバ、CP-SAT等、既存汎用ソルバ、であってソルバそのものの改善でないことが多いです。いずれにせよ、共通インスタンスでのベンチマークについて言及がないので、実際のところ、どの程度の有効性があるのか分かりません。アカデミックベンチマークは、問題規模が段階的に揃っているので、問題規模に対する有効性の評価も出来ます。日本とEUでは、そもそも働きかたそのものが違うので比較にならない、と考える方もいるかもしれませんが、私は、組み合わせ最適化能力と問題規模というパラメータのエッセンスは変わらないと考えています。

一部で、ナーススケジューリング問題は、最近のMIPソルバで解けるようになった、との指摘があるのですが、私の認識は、全然そんなことはありません。感覚的には、「MIPソルバでは、ほとんど解けない」、に近いです。(試しにINRC2問題をMIPソルバにやらせてみてください。ほとんど解けません。Scheduling Benchmarksについても解けるのはInstance-8/16/17位までです。)　

ベンチマーク問題と実務インスタンスで、主に違うのは、ペア制約の有無で、これが、インスタンスをより難しくする方向に作用します。また最近では、同数制約という運用で回避可能なはずの制約まで課されるようになってしまっていますが、これもより難しくする方向に作用します。

いずれにしても、骨格的には、アカデミックベンチマークインスタンスでも間違いはなく、実務ではさらに雑多な制約が入ることで、より難しくなる現実があります。

＜まず第一に汎用ナーススケジューリング問題ソルバ＞

ソルバが厳密解を容易に求められない以上、言い換えるならソルバ間で優劣差が存在する以上、最善を求めるのは当然ではないでしょうか？皆が同じ土俵上で、優劣差がない状態ならば、それ以上の最善は求められない、すなわち、組み合わせ最適化能力の向上を目指す必要がないことに同意します。しかし、現状は、スケジュールナースDVT版（開発版）から見て、「さらに優劣差が広がっている」、と推察します。

なので、汎用的なナーススケジューリング問題ソルバの開発がまず第一です。そのソルバは、アカデミックベンチマークについてほとんど全てインスタンスの厳密解を出力できることが必要要件です。これにより、基本的なナーススケジューリング問題についての組み合わせ最適化能力は担保されます。

皆さん、基本的ソルバの能力向上の必要性を無視されていますが、この問題に取り組んで十余年、私はづっとその必要性を切に感じていました。サポートをしていて、「これ以上は、物理限界で無理ですよ！」と言いたい場面が多々ありました。

＜VRPとの違い＞

ナーススケジューリング問題がVRPと異なるのは、管理者の多様な欲求を徒手選択するためのソフト制約にあると思っています。管理者が実現したいと思っている全てを実現出来る訳ではない、何かを取ろうとすれば、何かを捨てざるを得ないトレードオフを提供するところが、VRPと本質的に違うところだと思います。管理者の価値観は、管理者で違うので、職場毎に多種多様な制約、世界に一つしかないその職場にユニークな制約が生じます。しかし、最終的には、トレードオフに至るのが共通の帰結です。人の気持ちに寄り添うのがVRPとの決定的な違いとも言えますが、その結末は、いつもトレードオフになります。その際、管理者に納得してもらうのに必要なキーワードが「物理限界」です。

これ以上良い解はない、「物理限界です」という言い切りが出来ることが、管理者に納得して頂く最強で最終の切り札になります。その意味で、クローズドインスタンス環境にしても、物理限界、そして物理限界にどこまで近づけたかの指標であるLB-UB　Gap位は、言及して頂けたら、と思います。大抵の場合、LB-UB GAPはゼロではないはずです。

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

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

さらに、これを市井の様々なナーススケジューリング問題に適用させようということになると、汎用的フレームワークを再設計する必要があり、現在実装中、という訳です。

史上最大規模のナーススケジューリング問題が解けた、と言っても実務で遭遇するプロジェクトの厳密解がただちに求まる、ということではありません。依然として、何割かのプロジェクトの厳密解を求めることは難しいのでは？と感じています。それ位、実務で扱っている現実のナーススケジューリング問題を厳密に解くことは難しいものなのです。

＜次にモデリング＞

ソルバの改良が終わったのち、次に行うべきは、日本語指示によるモデリング方法の開発です。昨今、AIが特段に進化したので、それを利用します。問題は、そのモデリングが適切かどうかは、管理者が解を見ないと分からないので、GUIと連携しながら修正を加えていくスタイルが必須と考えています。プロジェクト作成サービスで、私が行っていることの代わりが出来ることが、究極の目標です。

＜まとめ＞

アカデミックベンチマークで性能を担保し、なおかつ日本語による指示モデリングで市井のナーススケジューリングの現場の諸問題をモデリングできるようにする、2段構えが究極のソルバである、と考えています。

2026年10月28日水曜日

コーディングの未来

ビル・ゲイツ氏「AIが人間の雇用の大部分を代替…今後20年が最も混乱」（中央日報日本語版）｜ｄメニューニュース（NTTドコモ）

ビル・ゲイツ氏でさせ敵わないと言わせる昨今のAI進化です。

実際、私も活用して本当だと思います。それでも、全体アーキテクチャ設計は、AIに渡してはいません。全体の中の部品設計においては、活用していますが、トータルを俯瞰した設計については、長い経験の方に未だ歩がある、と見ています。

そうした経験なしに、いきなりAIにコーディングさせることが効率的とは思いません。これから、新卒プログラマは、受難の時代を迎えるのではないでしょうか？

優秀なアーキテクトにとってAIは、優秀な部下を持ったことと同じです。機械的な作業は、AIに任せればよいのですから。少数のアーキテクトさえ居れば、巨大なプロジェクトも可能になる、と思います。

自分は、古き良き時代の、最後の世代になるのかもしれません。

2026年10月26日月曜日

unsigned char（8bit）× int16（16bit）のベクトル積

unsigned charとint１６のベクトル積のSSEコード

結論から言うと、unsigned char（8bit）× int16（16bit）のベクトル積を SSE2 で行うには、 「8bit → 16bit へのゼロ拡張」＋「16bit × 16bit の乗算」 という 2 ステップ構成になります。

SSE2 には 8bit × 16bit の直接乗算命令は存在しないため、 unpack（ゼロ拡張）→ PMULLW（16bit multiply） が正解です。

最速の SSE2 コードを完成形で提示します。

🧩 unsigned char × int16 の SSE2 ベクトル積の正しい流れ

1. unsigned char（8bit）を 16bit にゼロ拡張

SSE2 の PUNPCKLBW / PUNPCKHBW を使う。

cpp

__m128i bytes = _mm_loadu_si128((__m128i*)uc);   // unsigned char × 16
__m128i zero  = _mm_setzero_si128();

// 下位8バイト → 16bit に拡張
__m128i uc_lo = _mm_unpacklo_epi8(bytes, zero);

// 上位8バイト → 16bit に拡張
__m128i uc_hi = _mm_unpackhi_epi8(bytes, zero);

これで：

uc_lo = 16bit × 8
uc_hi = 16bit × 8

に変換される。

2. int16 と 16bit × 16bit の乗算（PMULLW）

cpp

__m128i s16_lo = _mm_loadu_si128((__m128i*)i16);      // int16 × 8
__m128i s16_hi = _mm_loadu_si128((__m128i*)(i16 + 8)); // int16 × 8

// 16bit × 16bit の乗算（下位16bit）
__m128i prod_lo = _mm_mullo_epi16(uc_lo, s16_lo);
__m128i prod_hi = _mm_mullo_epi16(uc_hi, s16_hi);

_mm_mullo_epi16（PMULLW）は：

signed 16bit × signed 16bit → 下位 16bit を返す

unsigned char はゼロ拡張しているので signed として扱っても問題なし。

✔ 完成形：unsigned char × int16 の SSE2 ベクトル積コード

cpp

void mul_uc_i16_sse(const unsigned char* uc, const int16_t* s16,
                    int16_t* out)
{
    __m128i bytes = _mm_loadu_si128((__m128i*)uc);
    __m128i zero  = _mm_setzero_si128();

    // 8bit → 16bit ゼロ拡張
    __m128i uc_lo = _mm_unpacklo_epi8(bytes, zero);
    __m128i uc_hi = _mm_unpackhi_epi8(bytes, zero);

    // int16 をロード
    __m128i s16_lo = _mm_loadu_si128((__m128i*)s16);
    __m128i s16_hi = _mm_loadu_si128((__m128i*)(s16 + 8));

    // 16bit × 16bit の乗算
    __m128i prod_lo = _mm_mullo_epi16(uc_lo, s16_lo);
    __m128i prod_hi = _mm_mullo_epi16(uc_hi, s16_hi);

    // 結果をストア
    _mm_storeu_si128((__m128i*)out,     prod_lo);
    _mm_storeu_si128((__m128i*)(out+8), prod_hi);
}

2026年10月24日土曜日

飽和演算

unsigned char同士の演算で負の場合０になるSSE命令は？

結論だけ先に言うと、unsigned char（8bit）同士の演算で「負になったら 0 に飽和する」SSE 命令は存在します。 それは SSE2 の saturating subtract for unsigned bytes：

PSUBUSB（Packed SUBtract Unsigned Saturate Bytes） → 8bit の unsigned subtract で、結果が負になる場合 0 に飽和する。

🔍 なぜ `PSUBUSB` が該当するのか

SSE2 には「飽和演算（saturating arithmetic）」があり、特に unsigned byte に対しては：

PSUBUSB：a - b が負なら 0 に clamp
PADDUSB：a + b が 255 を超えたら 255 に clamp

あなたの質問は「unsigned char 同士の演算で負の場合 0 になる SSE 命令」なので、まさに PSUBUSB がそのものです。

🧠 補足：Intel の saturating arithmetic の仕様

検索結果（Arm の saturating arithmetic の一般仕様）では：

unsigned saturating operation では、結果が negative なら 0 になる

と説明されています。 x86 SSE2 でも同じ概念があり、unsigned byte subtract の saturating 版が PSUBUSB です。

📌 使用例（C/C++ intrinsics）

cpp

#include <emmintrin.h>

__m128i a = _mm_set1_epi8(10);
__m128i b = _mm_set1_epi8(20);

// 10 - 20 = -10 → saturate to 0
__m128i r = _mm_subs_epu8(a, b);

_mm_subs_epu8 が PSUBUSB に対応します。

2026年10月20日火曜日

Q.登録マイクロソフトアカウント（買い切り版）の変更

Q.登録アドレス（買い切り版）ですが、県の規制があり、

　xxx@pref.xxxxxxx.lg.jp

がうまくマイクロソフトアカウントに登録できないことがわかりました。

そこで、代替の

xxx@outlook.jp　

に登録の変更をお願いいたします。

こちらは、すでにマイクロソフトアカウントを取得済のアドレスになります。

Ans.

変更しました。明日には、有効になっている可能性が高いと思います。明日以降、お送りしたインストールマニュアルに従ってトライしてみてください。

2026年10月19日月曜日

上界と最大の違い

結論だけ先に言うと、「上界（upper bound）」は“解の値の保証”であり、

「最大（max 制約）」は“変数の許容量の上限”であって、まったく別物。

🎯 一言で区別

上界（upper bound）：目的関数の値について「これ以上は小さくできない／大きくできない」という 探索木全体に対する評価値。
最大（max 制約）：あるリソースや変数が「これ以上使ってはいけない」という モデル内の制約式。

📌 もう少し厳密に：最適化の文脈での違い

1. 上界（Upper Bound）

最適化（特に Branch-and-Bound / Branch-and-Price）で使う概念。

最小化問題なら 上界 = 現時点での最良実行可能解の値
下界 = 緩和問題の値（LP, Lagrangian, etc.）

探索木で：

下界が上がる → 探索が絞られる
上界が下がる → より良い実行可能解が見つかった

つまり 上界は探索の進捗を示すグローバルな値。

2. 最大（Max 制約）

モデルの中にある通常の制約。

例：

x1+x2+x3≤10

これは「リソース使用量は最大 10」という意味であり、 目的関数の値とは無関係。

Branch-and-Bound の上界とは全く別の概念。

🧩 混同しやすい理由

最小化問題で「上界が上がる」と言うと、直感的には「制約の上限が上がる」ように聞こえるが、まったく違う。
上界は 目的関数の値の話
最大は 制約式の話

2026年10月17日土曜日

COPTの評価ライセンスがExpire

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

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

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

2026年10月15日木曜日

凸性とは？

Q.凸性とは

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

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

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

f(tx+(1−t)y)≤tf(x)+(1−t)f(y)

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

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

集合 $Q$ が凸集合とは、任意の2点 $v_{0}, v_{1}$ を結ぶ線分

(1−λ)v0+λv1,λ∈[0,1]

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

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

1変数関数の場合：

二階微分が常に非負（ $f^{''} (x) \geq 0$ ）なら凸関数
二階微分が常に正（ $f^{''} (x) > 0$ ）なら狭義凸（strict convex）

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

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

局所最小値 = 大域最小値 →「谷が一つしかない地形」と同じ
解が一意になる（狭義凸の場合）
多くのアルゴリズムが高速・安定に収束する

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

🧩 5. 凸性の例

線形関数（常に凸かつ凹）
二次関数 $f (x) = x^{2}$ （凸）
指数関数 $e^{x}$ （凸）
絶対値関数 $∣ x ∣$ （凸）
$- \log x$ （凸）

🎯 まとめ

凸性＝線分がグラフの上側にある性質
二階微分が非負なら凸
最適化で「唯一の最小値」を保証する強力な性質

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

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

🎯 結論：凸性 ≠ 単調増加

凸性は「曲がり方（形状）」の性質
単調増加は「値の増え方（方向）」の性質

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

📘 1. 具体的な違い

🔹 単調増加とは

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

x1<x2⇒f(x1)≤f(x2)

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

例：

$f (x) = x$ （線形）
$f (x) = e^{x}$ （指数）
$f (x) = \log x$ （単調増加だが凸ではない区間あり）

🔹 凸性とは

関数 $f$ が凸とは：

f(tx+(1−t)y)≤tf(x)+(1−t)f(y)

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

例：

$f (x) = x^{2}$ （凸だが単調増加ではない）
$f (x) = e^{x}$ （凸かつ単調増加）
$f (x) = ∣ x ∣$ （凸だが単調増加ではない）

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

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

f(x)=x2

左側（ $x < 0$ ）では減少
右側（ $x > 0$ ）では増加
しかし形はずっと「下に丸い」ので凸

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

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

f(x)=log⁡x

単調増加
しかし二階微分は負なので凹（concave）

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

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

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

🔹 凸性が保証するもの

局所最適 = 大域最適
唯一の最小値（狭義凸）
Barrier・PDLPなどの収束性が保証される

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

値が増える方向がわかるだけ
最適化の構造はほぼ何も保証しない
単調増加でも非凸なら局所解にハマる

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

📌 まとめ

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

2026年10月14日水曜日

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

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

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

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

Ans.

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

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

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

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

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

2026年10月12日月曜日

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）

gpedit.msc を起動
「コンピューターの構成」
→「管理用テンプレート」
→「Windows Update」
→ “Windows Update でドライバーを含めない” を有効化

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

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

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

手順（要セーフモード）

DDU（Display Driver Uninstaller）をセーフモードで実行
「Clean and restart」
再起動後、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をインストールしました。

2026年10月8日木曜日

今後の実装計画とお願い

１年半も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

2026年10月7日水曜日

ZOOMの背景を作った

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

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

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

登録: 投稿 (Atom)