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の助けになります。よろしくお願いいたします。

2026年10月7日水曜日

ZOOMの背景を作った

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

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

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

2026年10月6日火曜日

ルールを制約化する上で大事なこと

＜仕様とは？＞

プロジェクト作成サービスでは、お客様は、面倒なスケジュールナース上の制約についての知識は必要ありません。それでも、その職場のルールをお伝えいただく必要はあります。この職場のルールを「仕様」と呼んでいます。

「仕様を書いてください」というと、身構えてしまう方が多いのですが、大事なことは、自分の職場のルールを部外者である私に伝える、ということです。最初から完璧な水も漏らさないような仕様を書く必要はありません。最も重要なルールは何だろう？と、大事な事から記述していきます。

その職場のことを何も知らない部外者に伝える、ということは、その仕様があれば、その職場のルールを他で再現出来るようになる、ということでもあります。

言うなれば、その職場のルールを他で再現させる作業が、「仕様を書く」ということでもあります。

職場のルールは、日本語で記述するのが普通でしょう。この段階では、使用するソフトウェアに依存しません。つまり、スケジュールナース・その他のソフトウェアを使用する・しないに関係しないことに注意してください。整理して練り上げた仕様は、その職場の財産です。

＜仕様は作りあげていくもの＞

ナーススケジューリングは、意識されることのないルール「暗黙知」があることが前提となって、「機械では作れないもの」とされることが多く、またその主旨の学術論文が最近、複数出ています。が、スケジュールナースはそのような立場に立っていません。

Excelに出力した自動勤務解を見て頂くと、「そこは違う」という箇所が必ず出てきます。つまり、仕様にはなくても自職場ルールと違うことは、分かるのです。そういう場合に、そのルールを言葉にして頂ければよいのです。これを「仕様追加」と呼びます。仕様追加していくと、前の仕様と矛盾していることに気づかれるかもしれません。ルールに矛盾があるとき、制約化もできないので、そこを解消して頂くのは、お客さま自身です。ルールは、その場の思いつきであってはなりません。ルールなので、しょっちゅう変わってよい、ものでもありません。

こうした作業を通じて、その職場の普遍的なルールと必要な優先度順が逆に見えてきます。必然として、「その職場のルールの整理」が出来ます。

この自動勤務表をExcelで出力→違うところを指摘（ルールを言葉で伝える）→制約化、というループを数回行うと、自職場ルールをほぼ再現した自動勤務解が出来ます。大体よさそうだ、という時点で、発注をなさってください。

さらに細かな実装は、そのルールをファイルに収めたプロジェクトファイルをお渡しした上で行います。その際、使い方等をZOOMでお教えします。

＜仕様を書く力＞

仕様を人に伝えるにあたって、大事な能力は何でしょうか？　TVでよく解説をされている池上さんは、本当に分かりやすいですよね。池上さんと、言わんとしていることが良くわからないじれったい人との差は何でしょうか？　他人とのコミュニケーション能力だ、という人もあるかもしれませんが、私は、一言で言うと、「国語力」だと思っています。

最近はAIの時代で、AIでプログラミングする時代になってきました。スケジュールナースもAI対応（言葉で制約を伝える）を準備していますが、AI時代でも、国語力の重要性は、変わりないというよりむしろ増している、のではないかと思います。

＜メンテナンス＞

プロジェクトファイルが出来上がって、数か月廻すと、細かな実装も落ち着いて実用的な解が出てきてやがて仕様追加することはなくなります。これで終わりではありません。勤務表は、メンテナンスがつきもので、スタッフの入職、退職、移動、役割の変更等により、常にルールは変わっていくものです。つまり、プロジェクトファイルのメンテナンスを誰かが行わないと、せっかく導入したソフトウェアが使えないものになってしまう恐れがあります。

それを防ぐには、自分達で、プロジェクトファイルを操れるようになる、必要があります。そのために、導入1年の間は、ZOOMレクチャを必要なだけ行えるようにしています。何回行っても無償です。

「スケジュールナースがAI対応するようになれば、学ぶ必要はないじゃん」、と思われているかもしれませんが、それは違います。何度も言いますが、大事なことは、ルールを他人に伝える力、この場合、他人＝AIであり、依然として国語力が大事なのです。

＜管理者＞

管理者も変わっていきます。管理者の頭のなかだけにあるルールが、その管理者が居なくなることによって失われるリスクがあります。しかし、その職場のルールが仕様という形で、整理・明文化されていれば、スムーズに移管できるようになるのではないでしょうか？

登録: 投稿 (Atom)

スケジュールナースのブログ