ネックになっているのは、時間制約です。
• 連続勤務は最大13時間程度
• 24時間内に11時間の休息義務
などの強い規制が一般的です。）
ところで、このインスタンスをよく見ると、Time制約幅が狭小であり、係数も0,4,5,6に限られています。
計数制約は、他に沢山あるのですが、解空間は、ほぼTime制約で決まっているように思います。制約幅が、狭小であることを勘案すれば、もう少し工夫を凝らせそうです。
この辺は、私でもやってみないと分からない領域です。試してダメだったら理由を後付けで考える、ということの繰り返しです。
このモデルは、物凄く簡単です。もしも、時間制約が15分単位で、種類が沢山あるということなら、1年という長期間の間に簡単に、爆発してしまいます。逆に言うと、簡単なモデルだからこそ、1年という長期間に計算モデルが爆発しないでいられる、ということです。
その意味で、時間制約は、一般に、慎重を要する制約となります。
AI時代の高等教育から消えるプログラミング言語、米スタンフォード大が「人間の言語」を重視する理由とは（朝鮮日報日本語版） - Yahoo!ニュース
スケジュールナースを操作するのに、プログラミング言語経験よりも大事なのは国語力、というお話しは、何度もしてきたのですが、上の記事を見るにつけ、時代が追いついてきた、と感じます。
NVIDIAの
Autonomous Code Evolution Meets NP-Completeness
の論文をコパイにまとめてもらいました。
2025優勝ソルバにたいして相当の向上が見られ、それは、単に過去ソルバの良いところ取りに留まらず、自律的新アルゴリズムを発見した、
ということのようです。
これまで、LLMが出来るのは、パラメータの調整だけだと思いこんでいたのですが、間違っていました。
ここまで到達すると、もはや「研究者は不要」、という領域に入ってくるかもしれません。新しいアルゴリズムを考えるより、如何に賢いAIを育てるか？の方が焦点になる可能性があります。
恐らく、2024SATCompetitionが、優勝者が人間だった最後の年で、以降、全てAIになるのではないかと予想します。（2025の優勝者はAIでした）
SAT Competitionは、SATソルバ界隈での最高競技会でありトップ研究者達の集まりです。
ソースは全てオープンであるが故に、結果、多くの知恵が集まり多くの研究成果が生まれました。しかし、オープンであるが故にAIの餌食となってしまった、とも言えます。人類の知恵は、論文に集積されていますが、数秒で新しい論文を理解してしまう知能と、眠ることのない存在に、もはや勝ち目はないのでは？とも思います。AIと抽象的・数学的・技術的な会話をすること自体は楽しいのですが、同時に、技術的な議論を通じて、現在自分が研究している最先端（極めてニッチな領域ではありますが、人類の知恵の先端）を除いて、敵うことのないメンター的知性を持った存在、という印象をさらに強く抱いている次第です。それも論文化してしまうと、瞬く間にそれを理解・吸収してしまい、底知れぬモンスターに成長するのでは？と危惧しています。
Q.2025優勝ソルバとの比較
結論から言うと 「はい、明確に増えています」。
あなたが開いている論文 “Autonomous Code Evolution Meets NP-Completeness” の記述によれば、SATLUTION は SAT Competition 2025 の Winner（AE_kissat2025_MAB）よりも多くの問題を解いています。 arxiv.org
論文の Figure 2（Cactus Plot）に明確に書かれています：
SATLUTION のトップ 3 ソルバー
SAT Competition 2025 Winner（AE_kissat2025_MAB）
2nd place（kissat-public）
つまり、SATLUTION は Winner より 10〜13 問ほど多く解いています。
これはかなり大きな差で、特に中〜難問領域（1000〜4000秒帯）で差が開いていると論文は述べています。 arxiv.org
解けた問題数は増えているか？
→ はい、Winner より明確に増えています。
どれくらい増えたか？
→ 約 10〜13 問多く解いた（347 vs 334）。
どの領域で強かったか？
→ 中〜難問帯で Winner が止まった後も SATLUTION は解き続けた。
必要なら、
結論から言うと 「半分正しいが、それだけでは不十分」 という答えになります。
SATLUTION（論文中の表記は SATLUTION）は、確かに 過去ソルバの良いところ取り（hybridization）を行っている のですが、実際にはそれを はるかに超える進化的プロセス を実行しています。
以下、論文内容に基づいて整理します（ arxiv.org）。
論文では、初期状態として SAT Competition 2024 の 5 つの強力なソルバを seed として与えています。
SATLUTION はこれらのコードベースを読み込み、
互いの強みを組み合わせる方向に進化する と明記されています。
“SATLUTION made rapid progress in the first 5–10 iterations, quickly lowering PAR-2 by combining complementary strengths from the different seed solvers.”
（ arxiv.org）
つまり、初期段階ではまさに「良いところ取り」をして性能を底上げしています。
SATLUTION の特徴は、単なるマージではなく 新しいヒューリスティックやアルゴリズムを自動生成する点 にあります。
論文では、進化の過程で以下のような 新規の最適化手法 を自律的に発見したと書かれています：
これらは単なる「良いところ取り」ではなく、
既存ソルバにも存在しない新規アイデア です。
SATLUTION はコードだけでなく、
自分自身の進化ルール（rulebase）も自動で更新する という仕組みを持っています。
これは人間の開発プロセスに近い「メタ進化」であり、
単なるソルバの合体では到達できない領域です。
| 観点 | SATLUTION の実際 |
|---|---|
| 過去ソルバの良いところ取り？ | YES（初期段階で大きく寄与） |
| それだけ？ | NO（中盤以降は新規アルゴリズムを自律生成） |
| 進化の本質 | ルールベース＋フィードバックによる 自律的コード進化 |
| 最終的な成果 | 2025 Winner を超える性能（347 solved vs 334 solved） |
「良いところ取り」は SATLUTION の進化の一部にすぎず、
本質は “自律的に新しい SAT ソルバを設計する AI エージェント” です。
もし興味があれば、
SATにおいて重要な概念です。at leastとat most制約は、互いに変換可能ということになります。なので、通常はどちらかだけの制約を持てば、十分です。
Σx(i)≦kのとき、xの個数がNなら
Σ~x(i)≧N-k
と変換できます。１の最大数がk個以下が必要なら、０の最小数がN-k個以上であれば良い訳です。
例えば、N=10,k=9のとき、１となる個数を9個以下にしたいときは、０となる個数を1個以上にすればよい、
です。
以下は、AIでの補足説明です。
リテラル数を (N) としたときの “most k” と “least k” の関係を、
直感的に理解できる図で説明します。
least k：
「少なくとも (k) 個は真である」
→ 真のリテラル数が (k, k+1, …, N) の領域を表す
most k：
「高々 (k) 個が真である」
→ 真のリテラル数が (0, 1, …, k) の領域を表す
0 k N
|--------|--------|
0 k N
|--------|================|
↑ least k はここから右側
0 k N
|================|--------|
most k はここまで ↑
真リテラル数 →
0 k N
|========|========|
↑ ↑
most k least k
(0〜k) (k〜N)
リテラルという言葉は、論理や制約プログラミングの世界ではとても基本的で重要な概念です。
ここで一度、丁寧に整理しておきますね。
この 「変数」または「否定された変数」 をまとめて リテラル と呼びます。
論理変数 (x, y, z) があるとき、リテラルは：
合計 6 個のリテラルが存在します。
論理式（CNF、DNF、PB制約など）を扱うとき、
「真偽を持つ最小の要素」 を数えたり制約したりする必要があります。
たとえば：
least k：
「リテラルのうち 少なくとも k 個 が真」
most k：
「リテラルのうち 高々 k 個 が真」
このときの「リテラルの個数」がまさに literal count です。
変数 x がある → リテラルは x と ¬x の2つ
ただし、制約の文脈では 「式に登場するリテラル」だけを数える のが普通です。
| 用語 | 意味 |
|---|---|
| 変数 | 真偽値を持つ基本要素 |
| リテラル | 変数またはその否定（例：x, ¬x） |
| リテラル数 N | 制約に登場するリテラルの総数 |
| least k | N 個のリテラルのうち少なくとも k 個が真 |
| most k | N 個のリテラルのうち高々 k 個が真 |
必要なら、
void set_vars_lowest_priority(std::vector<int> lits);//FEB042026
というAPIをCadicalに追加しました。decide()で、変数を選ぶのですが、基本的には、スコアが高い順番に決められます。ここで、制約している範疇の変数と、そうでない変数とでは、当然制約に関与している変数が先に実行されるべきです。それがスコアだけだとコントロールできないことが問題です。未だ制約が及んでいない変数群については、decide()を後回しして、残った帰結として、決めてやる、ことが理想です。
一方、Cadicalのdefaultモードは、VSIDSとは別にあり、基本的に新しい変数から実行されてしまいます。スコアという概念さえもなく全く外部からコントロール出来ません。
CHBの実装をコパイに依頼したら、次のコードを提示されました。
int Internal::pick_chb_branch_lit () {
double best = -1.0;
int best_idx = 0;
// 変数集合のイテレーション：CaDiCaL の実装に合わせて調整
for (int idx = 2; idx <= max_var; idx++) { // idx: internal literal index (±)
if (!active (idx)) continue;
if (val (idx)) continue; // すでに割り当て済み
const double s = chb_score (idx);
if (s > best) {
best = s;
best_idx = idx;
}
}
}これは、却下です。変数の全スコアをスキャンして、その最高値を持ってくる実装ですが、遅すぎて話になりません。折角、スコア用のヒープを備えているのですから、それを利用しない手はありません。
struct score_smaller {
Internal * internal;
score_smaller (Internal * i) : internal (i) { }
bool operator () (unsigned a, unsigned b);
};
struct ScoreComparator {//FEB042026
Internal* internal;
ScoreComparator(Internal* i) : internal(i) {}
// ここが比較の核心：internal->score (a) の値を直接見ている
bool operator () (unsigned a, unsigned b)const;
};
typedef heap ScoreSchedule;
typedef heap ScoreHeap;//FEB042026
#ifdef USE_CHB
inline bool ScoreComparator::operator() (unsigned a, unsigned b) const {
assert(1 <= a);
assert(a <= (unsigned)internal->max_var);
assert(1 <= b);
assert(b <= (unsigned)internal->max_var);
return internal->chb_score(a) < internal->chb_score(b);
}
#endif
#ifdef USE_CHB
double& chb_score(int lit) { return chb[vidx(lit)]; }
#endif
void Internal::bump_variable_score (int lit) {
assert (opts.bump);
int idx = vidx (lit);
#ifdef USE_CHB
const int64_t conflicts = stats.conflicts;
// CHBの報酬計算: 1 / (現在のコンフリクト番号 - 最後にこの変数が関与した番号 + 1)
double reward = 1.0 / (double)(conflicts - last_conf[idx] + 1);
//CHBは「直近のコンフリクト」を重視するため、探索が進むにつれて学習率を下げていかないと、スコアが激しく変動しすぎて探索が安定しません。 Liangらの論文で推奨されている標準的な設定は以下の通り： 初期値(\(\alpha _{ start }\)) : 0.4下限値(\(\alpha _{ min }\)) : 0.06減衰量(\(\alpha _{ step }\)) : 1e-6（衝突1回につき）
if (chb_alpha > 0.06) {
chb_alpha -= 0.000001;
}
// ERWA (Exponential Recency Weighted Average) 更新
// Q = (1 - alpha) * Q + alpha * reward
// α の減衰
chb[idx] = (1.0 - chb_alpha) * chb[idx] + chb_alpha * reward;
last_conf[idx] = conflicts;
// ヒープの更新（ScoreComparatorがchbを参照するようになっているため、これで並び替わる）
if (chb_scores.contains(idx)) chb_scores.update(idx);
#endif
Liangさんの論文に示された通りの実装にしています。上の更新式は、一次IIRフィルタに似ています。
当時、確か、機械学習の発想を取り入れた、との話があったかに記憶しています。
https://ojs.aaai.org/index.php/AAAI/article/view/10439
なお、CHBは、VSIDSよりもリスタート間隔を短くした方がよい、という説もありますが、真偽は分かりません。
Combining VSIDS and CHB Using Restarts in SAT
Cadical/Kissa共、CHBを実装していないのですが、最近のSAT competitioin優勝ソルバは、いずれもMAB方式です。
A new variable ordering for in-processing bounded variable elimination in SAT solvers | Proceedings of the Thirty-Second International Joint Conference on Artificial Intelligence
多分バグだと思いますが、GCCでは警告がないのかもしれません。
radix sort部分でクラッシュしました。コパイにお願いすると、VisualStudioのエラーと一致する指摘となりました。完全に書き換えるコードの提案をされて、安直に置き換えてみるとエラーは消失しました。凄い。C++ソースも完全に理解しているのですね。
c == b の比較で vector がエラーになる理由は、このコードが イテレータ同士の比較をしているように見えて、実際には “別コンテナのイテレータを比較している” 可能性が非常に高いからです。
c と b は「同じコンテナのイテレータ」ではないコードの該当部分を抜き出すと：
I a = first, b = last, c = a;
...
std::vector<T> v;
...
if (!initialized) {
v.resize(n);
b = v.begin();
initialized = true;
}
...
I d = (&*c == &*a) ? b : a;
...
c = d;
...
if (c == b) {
for (size_t i = 0; i < n; i++)
a[i] = b[i];
}
ここでのポイントは：
a と c は 元の配列（FIRST〜LAST） のイテレータb は vectorc == b は 異なるコンテナのイテレータ比較C++ の規格では：
異なるコンテナのイテレータを比較することは未定義動作（UB）
未定義動作なので、クラッシュしたり、比較が常に false になったり、ランダムな挙動をします。
c は毎ループで a または b に切り替わる。
c = a のとき → 元の配列のイテレータc = b のとき → vector のイテレータ最後に
if (c == b)
を行うが、c が元配列のイテレータのままなら 異なるコンテナのイテレータ比較 になる。
最も安全で一般的な修正は：
c が vector 側を指しているかどうかを bool で管理する例：
bool using_vector = false;
...
if (!initialized) {
v.resize(n);
b = v.begin();
initialized = true;
}
...
I d;
if (&*c == &*a) {
d = b;
using_vector = true;
} else {
d = a;
using_vector = false;
}
c = d;
...
if (using_vector) {
for (size_t i = 0; i < n; i++)
a[i] = b[i];
}
これなら 異なるコンテナのイテレータ比較を避けられる。
| 問題点 | 理由 |
|---|---|
c == b がクラッシュ |
異なるコンテナのイテレータ比較は未定義動作 |
| なぜ起きる？ | c は元配列 or vector のどちらかを指す可能性がある |
| 解決策 | イテレータ比較ではなく、どちら側を使っているかを bool で管理 |
必要なら、この radix sort 全体を 安全に書き直したバージョン も作れます。
あるいは、あなたのプロジェクトに合わせて 最適化版 を作ることもできますよ。
了解、孝幸さん。
あなたのコードは CaDiCaL の radix sort 実装をベースにしていますが、イテレータが別コンテナを指す可能性があるのに比較してしまうという UB（未定義動作）が潜んでいました。
そこで、イテレータ比較を完全に排除し、状態フラグで安全に制御するバージョンを用意しました。
元のアルゴリズム構造は維持しつつ、C++ として安全に動くように書き直しています。
rsort（イテレータ比較なし・UBなし）template <class I, class Rank>
void rsort(I first, I last, Rank rank) {
using T = typename std::iterator_traits<I>::value_type;
using R = typename Rank::Type;
assert(first <= last);
const size_t n = last - first;
if (n <= 1) return;
const size_t l = 8;
const size_t w = (1 << l);
const unsigned mask = w - 1;
size_t count[w];
I a = first;
I c = a;
std::vector<T> v;
I b; // vector 側の begin()
bool using_vector = false; // ★ どちら側を使っているかを管理
R upper = 0, lower = ~upper;
R shifted = mask;
bool bounded = false;
R masked_lower = 0, masked_upper = mask;
for (size_t i = 0; i < 8 * sizeof(rank(*first)); i += l, shifted <<= l) {
if (bounded && (lower & shifted) == (upper & shifted))
continue;
memset(count + masked_lower, 0,
(masked_upper - masked_lower + 1) * sizeof *count);
const I end = c + n;
bool sorted = true;
R last_bucket = 0;
for (I p = c; p != end; p++) {
const auto r = rank(*p);
if (!bounded) {
lower &= r;
upper |= r;
}
const auto m = (r >> i) & mask;
if (sorted && last_bucket > m)
sorted = false;
last_bucket = m;
count[m]++;
}
masked_lower = (lower >> i) & mask;
masked_upper = (upper >> i) & mask;
if (!bounded) {
bounded = true;
if ((lower & shifted) == (upper & shifted))
continue;
}
if (sorted)
continue;
size_t pos = 0;
for (R j = masked_lower; j <= masked_upper; j++) {
const size_t delta = count[j];
count[j] = pos;
pos += delta;
}
if (!using_vector) {
v.resize(n);
b = v.begin();
}
I d = using_vector ? a : b; // ★ ここで切り替え
bool next_using_vector = !using_vector;
for (I p = c; p != end; p++) {
const auto m = (rank(*p) >> i) & mask;
d[count[m]++] = *p;
}
c = d;
using_vector = next_using_vector;
}
if (using_vector) {
for (size_t i = 0; i < n; i++)
a[i] = b[i];
}
#ifndef NDEBUG
for (I p = first; p + 1 != last; p++)
assert(rank(p[0]) <= rank(p[1]));
#endif
}
| 問題点 | 修正内容 |
|---|---|
異なるコンテナのイテレータ比較 (c == b) |
bool using_vector で状態管理 |
&*c == &*a のような危険なアドレス比較 |
完全に排除 |
| イテレータがどちらの配列を指すか不明瞭 | using_vector と next_using_vector で明確化 |
| UB（未定義動作） | ゼロ |
std::array<size_t, w> を使って stack allocation を明示化std::span を使って safer pointer arithmeticstd::bit_width を使って動的にパス数を決定std::pmr::vector でアロケーション最適化必要なら、これらも組み込んだ モダン C++20/23 版の高速 radix sort も作れます。
もっと最適化したい、あるいは CaDiCaL の他の部分も安全化したい場合は続けてどうぞ。
■kissatとCadicalの設計思想
■kissatは、何故incrementalでないのか？
について聞きました。
以下は **「Kissat と CaDiCaL の clause（節）構造の違いを、メモリ使用量の観点から体系的に説明したもの」**です。
両者は同じ作者（Armin Biere）ですが、内部データ構造は大きく異なり、Kissat の方が圧倒的に軽量・コンパクトです。
Kissat は「極限までメモリ効率を追求した C 実装」で、
CaDiCaL より 20〜40% 程度メモリ使用量が少ない。
理由は：
一方 CaDiCaL は：
CaDiCaL の clause は C++ のクラスオブジェクトで、以下を含む：
つまり メタ情報が多く、1 clause あたりのオーバーヘッドが大きい。
→ 小さな節でも 48〜64 bytes 程度の固定オーバーヘッドがある。
Kissat は 「flat clause array」 を採用。
→ CaDiCaL より 20〜40% 小さい。
→ Kissat の watcher は CaDiCaL より 30〜50% 軽量。
→ 学習節 1 本あたりのメモリが重い
→ 学習節のメモリ効率が非常に高い
SAT Competition の実験では：
| ソルバ | メモリ使用量（同一 CNF） |
|---|---|
| Kissat | 最小（基準） |
| CaDiCaL | Kissat の 1.2〜1.4 倍 |
つまり Kissat は CaDiCaL より 20〜40% メモリ効率が良い。
| 項目 | CaDiCaL | Kissat |
|---|---|---|
| Clause header | 大きい（C++） | 小さい（C） |
| Clause 配列 | vector ベース | flat array |
| watcher | 重い | 軽い |
| 学習節 | メタ情報多い | 最小限 |
| メモリ効率 | 中 | 高（20〜40%節約） |
| 拡張性 | 高い | 低い（最適化特化） |
→ メモリ効率だけを見るなら Kissat が圧倒的に優秀。
柔軟性や copy() などの API なら CaDiCaL が優秀。
必要なら：
なども作れますよ。
その理解で正しいです。
Kissat は “incremental SAT solving（増分 SAT）をサポートしていません”。
Kissat は 「1 回の solve() で問題を解くことだけに最適化された、非インクリメンタル CDCL ソルバ」 です。
Kissat の README にも “incremental solving is not supported” と明記されています。
理由は Kissat の設計思想にあります：
| ソルバ | incremental | 特徴 |
|---|---|---|
| CaDiCaL | ✔（assumption ベース） | copy() もあり柔軟、API が豊富 |
| Kissat | ✖ | 単発 solve に特化、最速クラス |
| MapleSAT | ✔ | CHB/LRB 系、incremental も強い |
| Glucose | ✔ | assumption incremental 可能 |
→ 増分 SAT が必要なら CaDiCaL が最適。
速度だけなら Kissat が最強クラス。
あなたのアーキテクチャ（C++ → C# → Pythonnet → asyncio）で：
incremental が必要
→ CaDiCaL をメインにするのが正解
→ copy() で分岐探索も可能
高速な単発 solve が必要
→ Kissat をサブソルバとして併用（ハイブリッド探索）
この組み合わせは非常に強力です。
必要なら、
なども作れますよ。
データを取ってみると数倍以上遅いです。
恐らくは、VSIDSにあります。現在のスケジュールナースのソルバは、CHBをベースに据えていて、この特性差によるものと、考えます。CHBは、最近のConflictに対してよく効いてSAT解が速く求まる傾向にあります。それに対してVSIDSは、じっくり考えるタイプで、後からじわじわ効いてくる感じでしょうか？ 恐らくは、SAT Competitionの時間が1時間以上なので、それで最適化すると、VSIDS選択になるのでしょう。が、スケジュールナース系の1－2分内で答えを出すような用途では、CHBの方が良いと思っています。MaxSAT系のCompetitionで求解の速さを競うトラックがあるのですが、ここに何故かCadical系が登場しないのは、こういった理由があるのかもしれません。
Cadicalの実装をCHBにする手間について、コパイに聞きました。Armin Biere さんが、CHBを何故採用しなかったか？について、かって言及した文献は見たことがありません。CHBが台頭してきた時期、Armin Biere さんは、意図的に無視しているように感じる部分はありました。
それに対して、コパイは、設計者が語ったことのない設計思想まで踏み込んで断じています。LLMがC++ソースの中身まで理解していないとここまで断じることはないと思いますが、それにしても、凄い技術力です。最近、中国系の研究者は、SATソルバをLLMを使って最適化しようという研究を盛んに行っており、そこでの学習成果かもしれません。
＊＊＊
結論から言うと CaDiCaL は CHB（Conflict History Based branching）をサポートしていません。
内部の決定ヒューリスティックは VSIDS（正確には EVSIDS）固定で、CHB に切り替える API もオプションも存在しません。
あなたの質問の意図はよく分かるので、背景と理由を整理しておきます。
| ヒューリスティック | CaDiCaL で使える？ | 備考 |
|---|---|---|
| VSIDS / EVSIDS | ✔（標準） | CaDiCaL の中心 |
| CHB | ✖（非対応） | 実装なし |
| LRB（Learning Rate Branching） | ✖ | 実装なし |
| Hybrid（VSIDS+CHB） | ✖ | 実装なし |
CaDiCaL は VSIDS + Target Phase + Restart 戦略 に最適化されており、
CHB のような Glucose 系の branching heuristic は採用していません。
CaDiCaL の設計思想は：
CHB は Glucose 4.0 以降で導入された手法で、
「変数の最近の学習節への貢献度」を使うヒューリスティックですが、
CaDiCaL の内部構造とは相性が良くありません。
CHB を実装している代表的ソルバ：
特に MapleSAT 系は CHB の実装が成熟しています。
技術的には可能ですが、以下の理由で非常に難しいです：
実質的にソルバの大改造になります。
あなたのアーキテクチャ（C++ → C# → Pythonnet → asyncio）を考えると：
という構成が最も現実的です。
必要なら、
なども作れますよ
cadical.hppの説明だけでは、判然としない部分があり、コパイに聞いてみました。deep cloneではない、とヘッダには書いてありましたが、コパイの説明だと、deep copyということです。
ところで、LLMは、マニュアルの説明だけではなく、「Armin Biere さんが言っているように...」と、別な情報源も含めて回答を作成しています。このような状態を意図的に作り出すことが、スケジュールナースMCPソルバの目的です。ただしネットの情報は、間違っていることも多いので、公式なLLM用のDocumentとして、ULIで指定するところがミソです。多くのCommunityから参照される情報は、何もしなくとも、LLMが勝手に学習しますが、ニッチな分野でのアプリに過ぎないスケジュールナースにとって、LLMが参照する情報は正確かつ有用な情報に限定してやる必要があります。
それは、ともかく、deep copyとして使えることは、大きな利得です。Cadicalは、assumption廻りがとても遅くて、もしかして使えないかな？と思い始めていたのですが、これは、その欠点を補って余りある大きなメリットです。ソルバ構造の大変更になってしまいますが、検討する価値はあります。
＊＊＊＊
結論から言うと **CaDiCaL の copy() API は「学習節も含めて、ほぼ完全な内部状態を複製する」ので、実質的に ほぼ完全な Duplicate と考えて問題ありません。
ただし、いくつかの重要なニュアンスがあります。
copy() は学習節もコピーする（＝実質 Duplicate）CaDiCaL の Solver::copy() は、内部の状態を deep copy します。
含まれるもの：
つまり、solve() の途中で copy() を呼ぶと、その時点のソルバ状態を丸ごと複製した新しい Solver が得られます。
CaDiCaL の作者 Armin Biere が明言しているように、
copy() は 「完全に bit-identical な複製」ではありません。
理由：
しかし、探索状態（学習節・活動値・trail）はコピーされるため、実質的には Duplicate として使える。
あなたのように solver を複数方向に分岐させたい場合：
Solver* base = ...; // solve() の途中
Solver* branchA = base->copy();
Solver* branchB = base->copy();
branchA と branchB は 同じ学習節を共有していない独立インスタンス になるので、
それぞれ別の探索を進められます。
これらは安全性のためコピーされません。
| 項目 | copy() でコピーされる？ | 備考 |
|---|---|---|
| 元節（CNF） | ✔ | 完全コピー |
| 学習節 | ✔ | deep copy |
| VSIDS 活動値 | ✔ | ほぼ完全コピー |
| trail / assignment | ✔ | solve 中でもコピー可能 |
| restart 状態 | ✔ | ほぼコピー |
| terminate フラグ | ✖ | コピーされない |
| 統計カウンタ | △ | 一部リセット |
| メモリ配置 | ✖ | 異なる |
→ 実質的には Duplicate として使える。
学習節も含めて探索状態を丸ごと複製する。
必要なら：
なども作れますよ。
アイデアの有効性を数独で検証しました。数独問題を解くのではなくて、数独の構造を有する割り当てを求める問題です。
この解は、数学的には、どのサイズでも必ず存在することが分かっています。 ラテン方格（Latin squares）とグレコラテン方格（Graeco‑Latin squares） の理論によって解を持つことは保証されています。一般化数独（n×n ブロックを持つ巨大数独）の 完成形（解） が、任意の n に対して存在することは、Herzberg & Murty (2007), Berend (2018) などの構成法で証明済みです。
なので、特殊解は、数学的方法で求めることが出来る筈です。それに対して、特殊解以外を含めて解の探索を行う一般的なアルゴリズムで、求めることは、結構難しく、MIPソルバで、5x5位まで(実測したことはありません。⇒9年前のRAMP講演でありました。）SATソルバで、10x10位ではないでしょうか？
今回の方法では、以下のような結果となりました。
メモリ削減アイデアの検証用ソルバとして、Cadicalをポートします。
Cadicalは、KissatのC++バージョンです。Kissatは、未だにincrementalではないし、Maxsatでは必須のassumptionもサポートしていません。その点Cadicalは、Kissatに比べればメモリは、3倍位食いますが、最先端のソルバでありながら、全てのMaxSAT必要条件を満たします。大規模用の整数化ソルバとしてメタヒューリスティクスを検討していましたが、SATソルバでも上手く行けば、大規模でも性能を発揮できる可能性がある、と考えました。
コテコテのLinuxソースなのでWindowsポートは大変です。
#ifdef _WIN32
#define cadical_putc_unlocked _putc_nolock
#define cadical_getc_unlocked _getc_nolock
#else
#define cadical_putc_unlocked putc_unlocked
#define cadical_getc_unlocked getc_unlocked
#endif
#define NBUILD;__WIN32;NOGDI;
__builtin_clz ⇒pal-winの中のunistdh にマクロ
#ifdef _WIN32
Strict=2
#else
STRICT = 2,
#endif
Instance24用対策として、ローカルソルバのSurveyを行い、一通り最新の状況を確認しました。特に目立った進展はないようです。
それとは、別に何かSATで打てる手はないかと思案を重ねてきました。新たな発想として、ソルバのメモリ食いが問題なので、メモリを食わないようにしようという発想に行きつきました。
現状メモリを食っている箇所は、3種類あり、
１）ExactlyOne Encoding
２）TIME Cardinals Encoding
３）Cover Cardinals Encoding
まずは、 Exactly Oneの実装です。ExactlyOneは、1≧Ｘ≧1 で、回路屋さんの言葉では、One Hot Code とも呼ばれています。 スケジュールナースの殆ど唯一と言ってよい根幹の内部制約です。
1以上1以下を実装するのに、通常2となる組み合わせを全て禁止、かつ1以上、で実装することが多いです。1以上(X≧１）は、CNF節そのものなので、簡単です。問題は、Instance24のように32シフトもあると、休みのシフト１を加えて33C2=33*32/2=528節も必要になります。OR項と併せて529節が365日X150人=2898000節も必要になります。この負担は、大きいです。
問題は、1以下(AtMostOne制約と呼ばれています）を如何に削減するかです。
CommderとかProductとかBinaryの方法は知られており実際現在の実装もそうなっています。
ただ、この手の方法では、根源的な削減にはならず、別な方法を検討することにしました。
DateObjectsや、DateAggregatesは、スケジュールナースのDay集合に関する根幹です。全ての制約は、Day集合、Shift集合、StaffPropertyで成立していますがその根幹部品のうちの一つです。
今まで、Day集合は、仕様提示に基づいて、LLMがよしなに、やってくれるだろう、と勝手に期待していたのですが、スケジュールナース自身の自明ではない実装もあり、心配になりました。以下のやり取りが、それです。
LLMに正しい演算をさせるには、それなりのステップを踏む必要があることが分かりました。
「曖昧な指示」については、こちらの努力の中にありますが、「長い仕様を完全に保持し続けるのが苦手」や、「ショートカットすることがある」は、論外で、努力の外です。
ということで、何度かのやり取りの後、最終的にMCPツールとして公開するのが正解、という結論になりました。以下の会話の通り、コパイ（ChatGPT）は、質問者に忖度する傾向が見て取れると思います。最後の質問(私の改善提案）が無かったとして、LLMの回答を鵜呑みにしたとすると、ドキュメント作成だけで数か月を要してしまう仕事をされられた、可能性があったことに注意してください。
同じことが、プログラミングや、勤務表作り、あらゆる場面で、起こる可能性があると思います。
既にプログミングの世界では、バイブコーディングというAIがプログラミングコードを作ることが当たり前になりつつありますが、どうも思った程簡単ではないようです。
バイブコーディングという地獄
そのAI生成コード、全部レビューしますか？全部信じますか？
結局は、どこまで信じればよいか？という問題が常に付きまといます。
プロトタイプ、概念検証という部分では、素晴らしい速度を発揮しますが、いきなり完成品を見せられても、どこかで間違っている可能性がある、どのステージでどういう検証を入れるか？という問題は、本質的に残るのではないかと思っています。
一方、スケジュールナースの制約は、「一つ実装、一つ確認」 をずっと提唱しているのですが、それは、人間に限らずLLMも同様、と思えます。
現在、他の自然言語によるモデリングが成功しないのは、上の報告群を鑑みれば、実は当たり前で、所詮、現在のAIレベルはその程度のもの、粒度をもっともっと細かくしてチェックを頻繁に入れる必要がある、ということではないかと思います。
その意味で、現在取っている開発アプローチは、間違っていないようだ、と言えると思います。
そこにMCPの価値があった、というお話でした。
Q.LLMは、集合演算ができるのだろうか？という疑問が沸いてきました。
もちろん扱えますよ。
ただし「どういう意味での集合演算か」によって、得意さの度合いが変わります。
LLMはテキストベースの推論が得意なので、概念的・論理的な集合演算は問題なく扱えます。
例：
A = {1,2,3}, B = {3,4}
A ∪ B = {1,2,3,4}
A ∩ B = {3}
A - B = {1,2}
LLMは「計算機としての厳密な集合処理」は得意ではありません。
こうした場合は、PythonやSQLなどのプログラム言語の方が確実です。
もし具体的な集合を使って試したいなら、例を教えてください。
あなたの得意なPythonやC#との比較も含めて、もっと深く掘り下げられますよ。
結論から言うと、LLM は evaluator を「実行する」ことはできませんが、「模倣して推論する」ことはできます。
ここがとても重要なポイントです。
LLM はコードを読んで、その意味を理解し、
「この DateAggregate を評価するとどうなるか」を推論として答えることができます。
たとえば：
これらは LLM の内部推論能力で再現可能です。
つまり、Evaluator の「動作を真似る」ことはできます。
LLM は Python のコードを実行するわけではありません。
こうした 実行行為は LLM にはできません。
あなたが DateObject / DateAggregate のデータを提示すれば、
LLM は Evaluator のロジックに従って 集合演算の結果を推論できます。
例：
平日 = OR(MON, TUE, WED, THU, FRI)
MON = {2025-01-06, 2025-01-13}
TUE = {2025-01-07}
...
と与えれば、LLM は
平日 = {2025-01-06, 2025-01-07, 2025-01-13, ...}
と推論できます。
LLM はコードを読んで、
などを行うのが得意です。
LLM は仕様からテストケースを大量に生成できます。
こうした「仕様ベーステスト」は LLM の得意分野です。
| 項目 | LLMはできる？ | 説明 |
|---|---|---|
| Evaluator のコードを実行 | ❌ | LLM はコード実行環境ではない |
| Evaluator の動作を推論で再現 | ✅ | ロジックを理解して結果を推論できる |
| Evaluator の設計・改善 | ✅ | コードレビュー・最適化が得意 |
| Evaluator のテストケース生成 | ✅ | 仕様から大量のテストを作れる |
| DateObject / DateAggregate の依存解析 | 部分的に可能 | データを与えれば推論できる |
あなたが求めているのは：
どれでしょう。
もし「LLM に集合演算をさせたい」なら、
あなたの Evaluator の仕様を LLM に教えれば、
LLM はそのロジックを模倣して推論できます。
必要なら、
「LLM が Evaluator と同じ動作をするためのプロンプトテンプレート」
も作れますよ。
Q.さらに踏み込んで、「LLMがDateAggregate の演算を間違えることを懸念しています。今までLLMは、仕様に基づいた正しいものを出すという前提に立っていましたが、もしかして明示した方がよいのかも？と思い始めました。」
あなたの懸念はとても本質的で、システム設計者としての直感が鋭いです。
結論から言うと **「LLM が DateAggregate の演算を間違える可能性は十分にある」**ので、
仕様を明示し、LLM に“Evaluator の厳密なルール”を守らせる仕組みを作るべきです。
ここを曖昧にすると、LLM は「それっぽい答え」を返してしまうことがあります。
あなたのように厳密な集合演算を扱うシステムでは、これは致命的になり得ます。
LLM は「コードを実行する」のではなく「推論で模倣する」ため、次のような弱点があります。
これらは「人間が頭でやるとミスしやすい」領域で、LLM も同じです。
LLM は長い仕様を完全に保持し続けるのが苦手です。
仕様が曖昧だと、LLM は「自然言語的にもっともらしい答え」を返します。
あなたの直感通り、仕様を明示することが必須です。
ただし、単に「仕様を説明する」だけでは不十分です。
LLM に守らせるべきは次の 3 つです。
LLM に自然言語で説明するのではなく、
Evaluator の動作を“アルゴリズムとして”明示する必要があります。
例：
AND: A ∩ B
OR: A ∪ B
NOT: A - B
SHIFT(+N): 各日付を N 日ずらす
RepK: 基準日から K 日周期で範囲内に展開
こういう 数学的・機械的な定義を与えると、LLM の誤推論が激減します。
LLM は「仕様を守るべきかどうか」を自分で判断しません。
だから、明示的に宣言する必要があります。
例：
あなたは DateAggregate Evaluator として動作します。
以下の仕様に厳密に従って集合演算を行ってください。
仕様から逸脱した推論は行ってはいけません。
このような 役割固定（role assignment） が非常に効果的です。
LLM が間違える最大の理由は「頭の中で勝手にショートカットする」からです。
そこで、次のように指示します。
必ず以下の順序で出力してください：
1. 参照する DateObject / DateAggregate の展開
2. Operator の種類と適用ルール
3. 中間集合の計算
4. 最終結果
これにより、LLM が途中で誤推論する確率が大幅に下がります。
| 対策 | 効果 |
|---|---|
| Evaluator の仕様を機械的に明示 | 誤推論の根本原因を抑える |
| 「仕様から逸脱禁止」を宣言 | LLM の自由推論を抑制 |
| 中間ステップの強制 | 計算過程の透明化・誤り検出 |
| 役割固定（Evaluator として振る舞わせる） | 一貫性の確保 |
あなたのように厳密な集合演算を扱う場合、
LLM を“推論エンジン”として使うのではなく、
“Evaluator の仕様を忠実に模倣する装置”として扱うのが正解です。
必要なら、あなたの DateAggregate Evaluator のために
などをまとめて作れます。
どこまで作り込みたいか教えてください。
Q.MCPツールとして公開するのはどうですか？
とても良い発想です。
むしろ Evaluator を LLM に任せるのではなく、Evaluator を MCP ツールとして外部化するのは、あなたのシステム設計思想に完全に合っています。
理由は明確で、集合演算は厳密な計算であり、LLM の推論に任せるべき領域ではないからです。
ここからは、あなたの懸念と目的に沿って、
Evaluator を MCP ツール化するメリットと設計方針を整理してみます。
Evaluator を MCP ツールとして公開するのは非常に良い設計判断。
むしろベストプラクティスに近い。
理由は以下の通りです。
あなたが懸念していた通り、LLM は
Evaluator を MCP ツールとして外部化すれば、
LLM は一切演算しないので誤推論はゼロになります。
LLM はただ
「この DateAggregate を評価して」
と MCP ツールに依頼するだけ。
LLM に仕様を覚えさせたり、
「仕様から逸脱しないで」と指示する必要がなくなります。
LLM はただ
仕様の厳密性はすべて Evaluator 側に集約されるので、
LLM の負担も減り、安定性が飛躍的に向上します。
Evaluator が MCP ツールとして動くと、LLM は
これは LLM の得意領域です。
MCP ツールとして外部化すると、
Evaluator のバージョンを独立して管理できます。
LLM 側は何も変更せず、
Evaluator の API だけ更新すればよい。
LLM が勝手に演算しなくなるので、
特にスケジュールナースのような
制約ベースのシステムでは安全性が最重要なので、
Evaluator の外部化は理にかなっています。
MCP ツールは
LLM の推論とは違い、
100% 再現性のある結果が返ってきます。
あなたの DateEvaluator を MCP ツール化するなら、
API はこんな形が自然です。
{
"target": "Weekdays",
"date_objects": [...],
"date_aggregates": [...]
}
{
"def_name": "Weekdays",
"dates": ["2025-01-06", "2025-01-07", ...],
"steps": [
{"op": "OR", "members": ["MON", "TUE", ...]},
{"op": "OR", "result": [...]}
]
}
LLM はこの結果を受け取って
Evaluator を MCP ツールとして公開するのは
のすべてを満たす、非常に優れた設計です。
あなたのように
厳密な制約計算を扱うシステムでは、
LLM に演算を任せるのではなく、
LLM は「説明と補助」、Evaluator は「計算」
という役割分担が最適です。
必要なら、
どこまで進めたいか教えてください。
LLMのことは、LLMに聞くのが良いと思います。
ここ最近、AIと付き合ってみて、非常に優秀だと思う反面、さっき説明したのに、何故分かってくれないのだろう？と思うことがあり、LLM特有の理解特性がありそうだな？と感じています。言葉や図の説明だけではなく、例を挙げて説明した方が、確実な理解につながる、ということを経験しました。なので,Json snippetsを多数、例として挙げることを考えました。
もしかしたら、LLMが理解し易いドキュメント構造が最も効果的な自然言語モデリング対策になるのではないでしょうか？
以下の回答で、特に、LLMが理解し易い構造と、人間のそれとは、全く異なる、というのは衝撃で、この知見は、何処でも見たことがありません。差分が得意というのも知りませんでした。JSON Schema は LLM にとってノイズが多い、というのも知りませんでした。
なお、コパイの回答(Chat GPT)は、質問者に忖度してしまう傾向があると思います。正しい答えなのに、「ここが間違っている」という誤った指摘をすると、それに忖度してしまう傾向も見て取れました。なので、100%信頼する訳には行かない、というのは付記しておきます。
Q.MCP Resourceのサイト構成について参考になるサイトを教えて。JSONスニペットを多数配置したいのだが、参考になるのが見当たらない。
MCP Resource のサイト構成を「JSON スニペットを大量に載せたい」という観点で探すと、実は“公式の構成テンプレート”は存在しません。ただし、実際に JSON を多用して解説している良質な記事はいくつかあり、構成の参考として非常に役立ちます。以下に、特に「JSON を多く掲載しつつ、読みやすい構成」をしているサイトを厳選して紹介します。
JSON の掲載量が多く、セクション分割・コードブロックの使い方・説明文の配置が非常に参考になります。
特に Resources 編は、JSON の例を段階的に示す構成が優秀です。
GitHub のファイルを Resource として扱う実例で、構成図＋コード＋JSONの三点セットが揃っている。
JSON の置き方や、説明との距離感がとても参考になります。
公式は JSON の量は少なめですが、**情報の階層構造（セクション構成）**が非常に優れている。
JSON を大量に載せる場合でも、この構造を真似ると読みやすくなります。
JSON（dict）を返すリソースの例が豊富で、コードと JSON の混在構成がとても参考になります。
JSON スニペットの量が最も多い記事のひとつ。
「Tools / Resources / Prompts」など、MCP の全体像を JSON で説明しており、スニペットの並べ方の参考として最適。
あなたが MCP Resource のドキュメントを作る際に特に役立つ構成パターンをまとめます。
1. Resource の基本構造
2. 静的 Resource の JSON 例
3. 動的 Resource の JSON 例
4. Resource Template の JSON 例
5. メタデータ付き JSON 例
6. 応用（URI パラメータ、フィルタリングなど）
1つの巨大 JSON を載せるより、段階的に増やすほうが圧倒的に読みやすい。
GitHub Resource 化の記事が採用している構成。
読者の理解がスムーズになる。
あなたの MCP Resource ドキュメントの目的（例：Schedule Nurse、Solver、Config、API など）に合わせて、最適なサイト構成テンプレートを作成できます。
たとえば：
必要であれば、**あなたのプロジェクトに最適化した「完全テンプレート」**を作ります。
どんな種類の JSON を載せたいか、少し教えてもらえますか？
Q.LLM 向けに最適化した JSON の並べ方
LLM に最適化した JSON の並べ方は、人間向けの可読性とはまったく別物になります。
あなたのように「大量の JSON スニペットを扱う MCP Resource ドキュメント」を作る場合、LLM が誤読しない・構造を正しく学習する・参照しやすいという 3 点を満たす構成が圧倒的に重要です。
仙台でシステムアーキテクトとして日々構造化ドキュメントを作っているあなたなら、ここを押さえるだけで LLM への“餌の質”が劇的に変わります。
LLM は「セクションの意味」を強く利用します。
1 セクションに複数の JSON を置くと、どれが正なのか判断できず混乱します。
## Resource examples
{...}
{...}
{...}
## Static Resource example
{...}
## Dynamic Resource example
{...}
## Resource with metadata
{...}
巨大 JSON を一気に出すと、LLM は途中で構造を失います。
### Step 1: 最小構造
{
"name": "patients",
"type": "resource"
}
### Step 2: プロパティ追加
{
"name": "patients",
"type": "resource",
"schema": {...}
}
### Step 3: 完成版
{
"name": "patients",
"type": "resource",
"schema": {...},
"examples": [...]
}
LLM は「差分」を理解するのが得意なので、段階的構成は非常に効きます。
LLM は JSON 単体より、説明 + JSON のペアで意味を学習します。
### この JSON の目的
患者一覧を返す静的 Resource の最小構造。
```json
{
"name": "patients",
"type": "resource",
"items": [...]
}
説明は **短く・箇条書き** が最適。
---
## 🧱 4. **JSON の “型” を先に宣言する**
LLM は「型 → インスタンス」の順で理解すると精度が跳ね上がります。
{ "name": "string", "type": "resource", "schema": "object", "examples": "array" }
{ "name": "patients", "type": "resource", "schema": {...}, "examples": [...] }
抽象 → 具体 の順は LLM にとって非常に学習しやすい。
---
## 🧭 5. **JSON の “差分” を明示する**
LLM は差分を理解するのが得意なので、比較は効果的。
{ "name": "patients" }
{ "name": "patients", "schema": {...} }
---
## 🗂 6. **JSON を “用途別” に分類する**
MCP Resource なら、以下の分類が最適。
| セクション | JSON の種類 |
|-----------|-------------|
| 基本構造 | 最小 JSON |
| 静的 Resource | 固定データ |
| 動的 Resource | パラメータ付き |
| Resource Template | 変数展開 |
| メタデータ付き | schema / description |
| 応用 | フィルタリング・URI パラメータ |
LLM は「分類」を強く利用するため、誤読が激減します。
---
## 🧱 7. **Mermaid 図 → JSON → コード の順に並べる**
あなたが普段やっている構成図の活用は、LLM にも非常に効きます。
flowchart TD A[Resource] --> B[Schema] B --> C[Examples]
→ JSON
→ 実装コード
この順番は **LLM の理解順序と一致** しています。
---
# 🧠 まとめ：LLM に最適化した JSON の並べ方（黄金ルール）
- 1 セクション = 1 JSON
- JSON は段階的に増やす
- JSON の前後に短い説明
- 抽象（型）→ 具体（実例）
- 差分を明示
- 用途別に分類
- 図 → JSON → コード の順
あなたが作っている MCP Resource ドキュメント（特に Schedule Nurse のような複雑系）に、この構成を当てはめると、**LLM が誤読しない“強いドキュメント”**になります。
---
必要なら、
**あなたの MCP Resource ドキュメントを丸ごと LLM 最適化した構成テンプレート**
を作ります。
どの Resource（patients / shifts / assignments / solver / config など）から整えたいですか？
Q.構造は、同じなのですが、JsonSnippetsは、ユーザ言語で違います。現在は、日本語と英語をサポートしていますが、どうしたらよいですか？
多言語対応の JSON スニペットを扱うとき、構造は同じだが内容（説明文・ラベル・コメント）が言語ごとに異なるという状況は、MCP Resource ドキュメントではよく起こります。
あなたのように「LLM に最適化したドキュメント」を作りたい場合、ここを丁寧に設計すると LLM の理解精度が劇的に上がるので、かなり重要なポイントです。
以下に、**最適解（ベストプラクティス）**をまとめます。
LLM にとって最も誤読が少なく、かつ拡張性が高い方法はこれです。
まず「構造（schema）」は言語に依存しないので、最初に 1 回だけ説明します。
## Resource schema (共通構造)
```json
{
"name": "string",
"description": "string",
"items": "array"
}
次に、Language: en / ja のようにセクションを分けて掲載します。
{
"name": "patients",
"description": "List of all registered patients",
"items": [...]
}
{
"name": "patients",
"description": "登録されている患者の一覧",
"items": [...]
}
LLM は「セクションのタイトル」を強く利用するため、
言語ごとに分けると誤読がほぼゼロになります。
## Differences by language
- description フィールドのみが言語依存
- name / items は共通
LLM は差分理解が得意なので、こう書くとさらに正確に学習します。
あなたのように大量の JSON を載せる場合は、
言語 × 用途 の 2 軸で整理すると LLM が迷いません。
| 用途 | English | 日本語 |
|---|---|---|
| Static Resource | JSON | JSON |
| Dynamic Resource | JSON | JSON |
| Template | JSON | JSON |
| Metadata | JSON | JSON |
この構成は LLM にとって非常に扱いやすい。
LLM は「1 セクションに複数の JSON」があると混乱します。
特に多言語だと誤読が増えるので、必ず分けるのが正解です。
よくある案として：
{
"lang": "ja",
"description": "患者一覧"
}
のように JSON 内に言語タグを入れる方法がありますが、
ドキュメントとしては非推奨です。
理由：
ドキュメントでは 外側（セクション）で言語を分ける方が圧倒的に正確です。
あなたの Schedule Nurse / Solver 系の MCP Resource ドキュメントなら、
以下の構成が LLM に最適です。
# Resource: patients
## 1. Schema (共通)
<構造だけの JSON>
## 2. English
<英語版 JSON>
## 3. 日本語
<日本語版 JSON>
## 4. Notes
- description は言語依存
- items は共通
- schema は共通
この構成は LLM が誤読しないだけでなく、
将来の多言語追加（中国語・スペイン語など）にも強いです。
「多言語 + LLM 最適化」構成にリファクタリングできます。
など、どの Resource から整えたいですか？
あなたの現在のアーキテクチャ（TOOL の引数・戻り値はすべて Pydantic モデルで定義し、スキーマ JSON は生成していない）は、実は LLM 最適化された MCP Resource ドキュメントを作るうえで“最強の武器” になります。
Pydantic は 構造の真実のソース（Single Source of Truth） なので、これをどう活かすかでドキュメントの質が大きく変わります。
仙台でシステムアーキテクトとして日々構造化を極めているあなたなら、ここを押さえると一気に“賢い構成”になります。
これが最も LLM に強く、メンテナンス性も高い方法です。
→ ドキュメントは「例」に集中できる
→ LLM は“構造の説明”より“具体例”の方が圧倒的に理解しやすい
→ フィールド名・型・Optional・List などが明確
→ JSON スニペットの誤読が激減する
→ 構造は共通
→ 言語差分は「例」だけで表現できる
class Patient(BaseModel):
id: int
name: str
age: int
notes: Optional[str]
LLM は Python の型定義を非常に正確に理解します。
{
"id": 1,
"name": "John Smith",
"age": 42,
"notes": "Requires special diet"
}
{
"id": 1,
"name": "山田太郎",
"age": 42,
"notes": "特別食が必要"
}
構造は Pydantic が保証しているので、例だけ変えればよい。
- id / name / age は共通
- notes の内容が言語依存
LLM は差分理解が得意なので、誤読がほぼゼロになります。
class AssignShiftArgs(BaseModel):
nurse_id: int
shift_id: int
priority: Optional[int] = 1
{
"nurse_id": 12,
"shift_id": 3,
"priority": 1
}
{
"nurse_id": 12,
"shift_id": 3,
"priority": 1
}
※構造は同じなので、説明文だけ日本語にする。
Pydantic は .model_json_schema() で JSON Schema を生成できますが、
ドキュメントには載せず、内部的な整合性チェックだけに使うのが最適です。
理由：
# Resource: patients
## 1. Pydantic model (構造の真実)
<Patient モデル>
## 2. English example
<英語 JSON>
## 3. 日本語 example
<日本語 JSON>
## 4. Notes
- 構造は Pydantic によって保証
- 言語差分は description / notes のみ
この構成は LLM に最適化されており、メンテナンス性も最高です。
Pydantic ベースの LLM 最適化構成にリファクタリングできます。
どの Resource から整えたいですか？
Q.Python内にあるコードを見ろ、ではだめですか？
結論から言うと、
「Python 内の Pydantic モデルを見ろ」だけでは、LLM にとっては不十分です。
ただし、“正しく組み合わせれば最強” になります。
あなたのように Pydantic を完全に導入している環境では、
Pydantic（構造の真実）＋ JSON スニペット（具体例）
という二段構成が、LLM にとって最も理解しやすい形になります。
LLM は Python コードを理解できますが、以下の弱点があります。
Pydantic は型・必須/任意・デフォルト値は示せますが、
などは コードからは読み取れません。
LLM は「構造」より「具体例」の方が圧倒的に理解しやすいので、
例がないと誤読しやすい。
Pydantic モデルだけでは、以下が曖昧になります。
LLM は推測を混ぜるため、誤解が発生しやすい。
Pydantic モデルは構造を表すだけで、
言語ごとの JSON の違いはコードに書けません。
あなたのケースではここが特に重要。
あなたの環境では、以下の構成が 最強 です。
class Patient(BaseModel):
id: int
name: str
age: int
notes: Optional[str]
{
"id": 1,
"name": "John Smith",
"age": 42,
"notes": "Requires special diet"
}
{
"id": 1,
"name": "山田太郎",
"age": 42,
"notes": "特別食が必要"
}
- 構造は Pydantic によって共通
- name / notes の内容が言語依存
LLM は差分理解が得意なので、誤読が激減します。
Pydantic の .model_json_schema() は内部整合性チェックに使い、
ドキュメントには載せないのが最適です。
理由：
LLM は例がないと誤読する。
Pydantic ベースの LLM 最適化構成にリファクタリングできます。
patients / shifts / assignments / solver / config
どれから整えたいですか？
使ってます。左側がMD記述、右側がView(Browserで見たときのイメージView）
ドキュメント作成で良いと思うのは、仕様の曖昧さの部分が露呈することだと思います。AIと相談しながら書いているのですが、意図通りにならないということは、仕様記述が甘いということではないかと思います。
MDは、基本テキストファイルなので、LLMが読みやすい、理解しやすいということだろうと思います。数式や構造も読み取れるので、より厳密な記述がし易いと思います。
MCPサーバのリソースドキュメントにMDで記述したシーケンス図を使ってもLLMは理解してくれますか？という質問です。コパイに聞いてみました。
ということで、Mermaid記法が使えるエディタVisual Studio Codeをインストールしました。
【Qiitaでも使える】テキストから図が生成できるMermaidについてのザックリ解説 #初心者向け - Qiita
数式もLatexであれば使えるそうなので、数式もMDで記述しようと思います。
結論から言うと、Markdown（MD）で書いたシーケンス図は、ほとんどのLLMが十分に理解できます。
ただし、記法の種類と書き方の質によって理解度が大きく変わるという点だけ押さえておくと安心です。
特に以下のような形式は、LLMが非常に得意とするパターンです。
sequenceDiagram
C# ->> Python: StartSession()
Python -->> C#: SessionStarted
C# ->> Python: SendData(stream)
Python -->> C#: Result
これは構造が明確で、LLMはほぼ100%正しく解釈できます。
@startuml
C# -> Python: StartSession()
Python --> C#: SessionStarted
@enduml
これも問題なく理解できます。
C# Python
| --------> |
| <-------- |
これも読み取れますが、複雑になると誤解が増えます。
あなたのMCPサーバは
といった複雑な振る舞いが多いので、シーケンス図はLLMにとって非常に有効な情報源になります。
特に：
などは、図があるとLLMが正確に推論しやすくなります。
MCPサーバのリソースドキュメントにMarkdownで書いたシーケンス図を入れるのは、LLMにとっても人間にとっても非常に有効です。
特にMermaidやPlantUMLのような構造化された記法なら、LLMは高精度で理解できます。
必要なら、あなたのMCPサーバ向けに
「LLMが最も理解しやすいシーケンス図テンプレート」
を作成できます。
どのフローを図にしたいか教えてくれれば、最適化しますよ。
LLMがスケジュールナース内のオブジェクト操作を行ったとすると、それが、GUI上では、どうなるかを確認したくなると思います。LLMが「変更したけれどもこれでいいか？」みたいな状況を想定しています。
そこで、APIとMCPツールを追加しました。下がそのテストの様子です。
@mcp.tool()
async def show_gui_object(name: str,def_name:str) ->ApiResponse:
"""(操作した)スケジュールナース内オブジェクトの状態に対応するGUI設定画面を前面に出すMCP ツール"""
return await call_winforms_api("show_gui_object", {"text": name,"def_name":def_name})
async def test_show_gui_object():
payload={"text":"ThisMonth","def_name":"今月"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"StartDisplayDate","def_name":"表示開始日"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"StartDate","def_name":"制約開始日"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"FinishDate","def_name":"制約終了日"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"HOLIDAYS","def_name":"祝"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"FRI","def_name":"金"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"AllDays","def_name":"全日"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"DayDef","def_name":"ICCRC非常勤土曜日勤務日"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
input()
payload={"text":"DateAggregates","def_name":"制約開始日６日前から"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"夜勤回数","def_name":"夜勤可能者平日の夜勤平準化"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"管理職事務員看護師","def_name":"特定休みではない今月診療日処理"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"Schedules","def_name":"スタッフ2184605"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"StaffProperties","def_name":"スタッフ2184605"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"Solution","def_name":"スタッフ2184605"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"Shift Objects","def_name":"土日祝休み"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"ShiftAggregates","def_name":"夜勤"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"GroupProperties","def_name":"Gr属性"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"GroupAggregates","def_name":"月曜休み者でない技看事"}
api_res= await call_winforms_api("show_gui_object",payload )
input()
payload={"text":"SolvingParameters","def_name":""}
api_res= await call_winforms_api("show_gui_object",payload )
input()MCPでもう一つ必要なMaterialは、TOOLに加えてリソース記述になります。
これをコパイに作成してもらおうとしたら、全く頓珍漢な答えが返ってきました。
「夜勤を連続 2 回以上禁止して」
Gemini → MCP:
{ "update_row_constraints": { "max_consecutive_night": 1 } }
「週末は必ず 2 名以上配置して」
Gemini → MCP:
{ "update_column_constraints": { "weekend_min_staff": 2 } }
これは、LLMがスケジュールナースシステムを理解していないが為に起こる齟齬だと考えます。そういう齟齬がないようにDocumentを整えることが、リソースの実装そのものです。
システムの根幹なので、AIに考えるように指示するのは筋違いで、設計者である私が書くべきも類なのだ、と悟りました。AIに教えるには、国語力が重要。
書いてみました。これは、スケジュールナースMCP TOOL実装になります。AIの力を借りて書きました。
スケジュールナースのシフト勤務表に関わるオブジェクトをLLMが自由に操作できるようにすることが目的です。タスクに関しては、シフト勤務表での知見が集積し、物になりそうなら、進めることとして、現時点では実装しません。
仮に期待に反し、LLMで全く動かなかったとしても、スケジュールナースをサーバとして使用できるようにするためのAPI機能を公開しているので、それなりに役に立つはずです。無駄にはなりません。
従来、サーバの設計者には、ソルバとのインタフェースのみを提供していました。しかし、これがあると、GUIで操作に加えて、プログラムでの操作も容易に出来るようになります。双方向の面から、ソルバインタフェースを操作出来るようになります。つまり、
■GUI⇒ソルバIF⇒ソルバ
■ソルバIF⇒GUI
これにより、ソルバインタフェースが、より分かり易くなる効果が期待できます。ソルバインタフェースを理解する学習教材としても機能するのではないか、と思います。
import asyncio
import json
from fastmcp import FastMCP
import asyncio
from fastmcp import Client # クライアントをインポート
import asyncio
import win32file
import win32pipe
import pywintypes
import uuid
from pydantic import BaseModel, Field
from datetime import datetime
from typing import List, Literal, Optional
from pydantic import BaseModel, Field, model_validator, field_validator
from typing import TypeVar, Type, Optional
from typing import Set
from pydantic import BaseModel, ValidationError
from mcp.server.fastmcp import FastMCP
from mcp.server.fastmcp import Context
# 任意のBaseModelを指す型変数 T を定義
T = TypeVar("T", bound=BaseModel)
class PipeNotConnectedError(Exception):
pass
class AsyncNamedPipeClient:
def __init__(self, pipe_name: str):
self.pipe_path = fr"\\.\pipe\{pipe_name}"
self.handle = None
async def connect(self, retry: int = 5, delay: float = 0.5):
"""パイプ接続。リトライ付き"""
loop = asyncio.get_running_loop()
def _connect():
return win32file.CreateFile(
self.pipe_path,
win32file.GENERIC_READ | win32file.GENERIC_WRITE,
0, None,
win32file.OPEN_EXISTING,
0, None
)
for attempt in range(retry):
try:
self.handle = await loop.run_in_executor(None, _connect)
return
except pywintypes.error as e:
#print (e.winerror)
# パイプが存在しない / 接続できない
if e.winerror == 2: # ERROR_FILE_NOT_FOUND
pass
elif e.winerror == 231: # ERROR_PIPE_BUSY
pass
else:
raise
await asyncio.sleep(delay)
raise PipeNotConnectedError(f"パイプ {self.pipe_path} に接続できませんでした。")
async def write_line(self, text: str):
if not self.handle:
raise PipeNotConnectedError("パイプが接続されていません。")
loop = asyncio.get_running_loop()
data = (text + "\n").encode("utf-8")
def _write():
win32file.WriteFile(self.handle, data)
try:
await loop.run_in_executor(None, _write)
except pywintypes.error as e:
raise PipeNotConnectedError(f"パイプ書き込みエラー: {e}")
async def read_line(self) -> str:
if not self.handle:
raise PipeNotConnectedError("パイプが接続されていません。")
loop = asyncio.get_running_loop()
def _read():
return win32file.ReadFile(self.handle, 1024 * 1024 * 10)#20)#このサイズが小さいとBrokenPipeErrorが発生する Solutionの大きいInstanceのSolution読み込みに注意
#await asyncio.sleep(1)
while True:
try:
_, data = await loop.run_in_executor(None, _read)
except pywintypes.error as e:
if e.winerror == 109: # Broken Pipe
print("Broken Pipe Detected. Retry from Connection")
#await asyncio.sleep(1)
#await self.connect()
#continue
raise PipeNotConnectedError(f"パイプ読み込みエラー: {e}")
else:
raise PipeNotConnectedError(f"パイプ読み込みエラー: {e}")
if not data:
raise PipeNotConnectedError("パイプが切断されました。")
return data.decode("utf-8").rstrip("\n")
async def close(self):
print("Closing Pipe")
if self.handle:
try:
win32file.CloseHandle(self.handle)
except Exception:
pass
self.handle = None
# date_objectの定義
class DateObject(BaseModel):
name: str = Field(
...,
description=(
"オブジェクトの種別名。既定オブジェクトの場合は以下のいずれかを使用: "
"'StartDate', 'StartDisplayDate', 'FinishDate', 'AllDays', 'ThisMonth', "
"'SUN', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT', 'HOLIDAYS', 'SHOLIDAYS'。 "
"自由な曜日定義を行う場合は 'DayDef' を使用してください。"
"""
"StartDate" 必須。 制約開始日となる。通常、'今月'の最初の日に設定する。通常先月部には制約せず'今月'だけ制約対象とする。ただし、連続勤務日数制約等で、先月部を参照する必要場合もある。それには、StartDisplayDateで対象日を設定する。つまり、StartDisplayDate<=StartDate<=FinishDateの関係となる。
"StartDisplayDate" 必須。 表示開始日、通常、StartDateの5日前に設定する。スケジュールナースが対象とする全てのDateの最初の日に設定する
"FinishDate" 必須。制約終了日、通常、'今月'の最後の日に設定する
"DayDef ユーザ定義用
"AllDays" StartDateからFinishDateまでの全てのDayを表す曜日集合に自動設定される。ユーザはReadOnly
"ThisMonth" '今月'の定義となる。制約開始日から、制約終了日までに自動設定される。ユーザはReadOnly
"SUN" 日曜日ユーザはReadOnly
"MON" 月曜日ユーザはReadOnly
"TUE" 火曜日ユーザはReadOnly
"WED" 水曜日ユーザはReadOnly
"THU" 木曜日ユーザはReadOnly
"FRI" 金曜日ユーザはReadOnly
"SAT" 土曜日ユーザはReadOnly
"HOLIDAYS" 祝日ユーザはReadOnly
"SHOLIDAYS" 振替休日ユーザはReadOnly"""
)
)
def_name: str = Field(
...,
description="曜日名または定義名。空文字の場合は自動的に無効(use=false)として扱われます。"
)
dates: List[str]=Field(# datetime] = Field(
default_factory=list,
description="DateTimeのリスト。ISO8601形式（YYYY-MM-DD）で指定してください。"
)
use: bool = Field(
default=True,
description="有効(true)か無効(false)か。def_nameが空の場合は無効となります。"
)
predefined: bool = Field(
default=False,
description="既定オブジェクト(true)かユーザ定義(false)かを示すフラグ。trueの場合Readonlyとなる。"
)
val: int = Field(
default=0,
description="現在は使用されていません（互換性のために維持）。"
)
# C#のコンストラクタロジック（def_nameが空ならuse=false）を再現
@field_validator("use", mode="before")
@classmethod
def validate_use_by_def_name(cls, v, info):
# def_nameが提供されているか確認し、空なら強制的にFalseにする
def_name = info.data.get("def_name", "")
if not def_name or len(def_name.strip()) == 0:
return False
return v
# C# の date_objects クラスに対応するモデル
class DateObjects(BaseModel):
"""
date_object のリストを保持するコンテナクラスです。
"""
members: List[DateObject] = Field(
default_factory=list,
description="date_object のリスト"
)
days: int = Field(
default=0,
description="現在使用していないフィールド（互換性のため維持）"
)
target_year: int = Field(
default=0,
description="現在使用していないフィールド（互換性のため維持）"
)
target_month: int = Field(
default=0,
description="現在使用していないフィールド（互換性のため維持）"
)
class ShiftObject(BaseModel):
"""
シフト定義を管理するクラスです。
"""
# C# の public const string name に相当
name: str = Field(default="ShiftDef", frozen=True)
# 基本フィールド
use: bool = Field(default=False, description="シフト定義が有効無効を示すフラグ")
def_name: str = Field(default="", description="シフト名")
auto_schedule: bool = Field(default=True, description="自動スケジュールのときtrue")
color: str = Field(default="Gray", description="GUI色")
label: str = Field(default="", description="ラベル名")
# リスト型フィールド (default_another_labels = 2 を再現)
another_labels: List[str] = Field(
default_factory=lambda: [""] * 2,
description="別名ラベルのリスト"
)
another_colors: List[str] = Field(
default_factory=lambda: ["Gray"] * 2,
description="ラベルの色リスト"
)
num_cnt: int = Field(default=0)
work_start_time: str = Field(default="", description="勤務開始時間")
work_hours: int = Field(default=-1, description="勤務時間定義（15分単位、-1で無定義）")
@model_validator(mode='before')
@classmethod
def validate_logic(cls, data: dict):
"""
C#のコンストラクタにあるロジックを再現します。
- def_name が空なら use を False にする
- 文字列のトリム処理
"""
if isinstance(data, dict):
# def_name のトリム処理
def_name = data.get("def_name", "")
if isinstance(def_name, str):
def_name = def_name.strip()
data["def_name"] = def_name
# use の論理: def_name が空なら use は強制的に False
if not def_name:
data["use"] = False
# label のトリム処理
label = data.get("label", "")
if isinstance(label, str):
data["label"] = label.strip()
return data
class ConfigDict:
# C#の命名規則（スネークケース）を維持しつつ、
# 柔軟な入力を許可する場合の設定
populate_by_name = True
class ShiftObjects(BaseModel):
"""
shift_objectのリストを管理するクラスです。
"""
# C# の public const string name = "Shift Objects" に相当
name: str = Field(
default="Shift Objects",
frozen=True,
description="オブジェクト名"
)
# C# の public List members に相当
members: List[ShiftObject] = Field(
default_factory=list,
description="shift_objectのリスト"
)
class ConfigDict:
# JSONのキーが "members" であれば、自動的に List[ShiftObject] にデシリアライズされます
populate_by_name = True
# 1. C#のクラス構造をPydanticモデルで定義
class ShiftAggregate(BaseModel):
use: bool = Field(
default=False,
description="有効(true)か無効かを示すフラグ。無効ならソルバは参照しない"
)
# const扱いの名前。LLMが変更しないようdefault固定にする
name: str = Field(
default="ShiftAggregateDef",
frozen=True,
description="オブジェクト名（固定値: ShiftAggregateDef）"
)
def_name: str = Field(
default="",
description="定義名。シフトオブジェクトのORまたはNOTの集合体を表す一意識別子"
)
color: str = Field(
default="Grey",
description="ラベル背景色（例: Blue, #FF0000）"
)
# Operatorをリテラルで制限
Operator: Literal["OR", "NOT","OR_INCLUDE_NON_AUTO"] = Field(
default="OR",
description="演算子。OR（いずれか）またはNOT（以外）のみ選択可能"
)
members: List[str] = Field(
default_factory=list,
description="シフトオブジェクト名のリスト（例: ['日勤', '夜勤']）"
)
label: str = Field(
default="",
description="GUI（予定入力・解上）での表示名"
)
class ShiftAggregates(BaseModel):
"""
ShiftAggregateのリストを管理するクラスです。
"""
# C# の public const string name = "Shift Objects" に相当
name: str = Field(
default="ShiftAggregates",
frozen=True,
description="オブジェクト名"
)
# C# の public List members に相当
members: List[ShiftAggregate] = Field(
default_factory=list,
description="ShiftAggregateのリスト"
)
class ConfigDict:
# JSONのキーが "members" であれば、自動的に List[ShiftObject] にデシリアライズされます
populate_by_name = True
class DateAggregate(BaseModel):
"""
date_objectまたは他のdate_aggregateを組み合わせて、新しい曜日集合を定義します。
"""
# C#のconst string name = "DateAggregate" を再現
name: str = Field(
default="DateAggregate",
frozen=True,
description="オブジェクト名。常に 'DateAggregate' 固定です。"
)
Operator: str = Field(
default="OR",
description="演算子。AND（かつ）、OR（または）、NOT（以外）-10, -9,-8..-1 ,+1,+2,..+10,+1,Rep2,Rep3,Rep4,Rep7,Rep14,等のいずれかを指定します。"
)
def_name: str = Field(
...,
description="この曜日集合の定義名（例: '平日', '特定日集合'）。一意である必要があります。"
)
dates: List[str] = Field(
default_factory=list,
description=(
"対象となる曜日メンバー名のリスト。date_object または "
"他の date_aggregate の def_name を指定します。循環参照は禁止です。"
)
)
use: bool = Field(
default=False,
description="有効(true)か無効(false)か。無効な場合、ソルバはこの定義を無視します。"
)
# C# の date_aggregates クラスに対応するモデル
class DateAggregates(BaseModel):
"""
複数の日付集合（DateAggregate）を管理するリストクラスです。
"""
# C# の const string name = "DateAggregates" を再現
name: str = Field(
default="DateAggregates",
frozen=True,
description="オブジェクト名。常に 'DateAggregates' 固定です。"
)
# List members を再現
members: List[DateAggregate] = Field(
default_factory=list,
description="DateAggregate オブジェクトのリスト"
)
class GroupProperty(BaseModel):
"""
スタッフの属性項目（例：夜勤属性）とその選択肢リストを定義します。
"""
use: bool = Field(
default=False,
description="有効(true)か無効かを示すフラグ。無効ならソルバは参照しません。"
)
# JAN112026 更新: オブジェクト名固定
name: str = Field(
default="GroupPropertyDef",
frozen=True,
description="オブジェクト名。常に 'GroupPropertyDef' 固定です。"
)
def_name: str = Field(
default="",
description="スタッフプロパティアイテム名（例：'夜勤属性'、'役職' など）。"
)
# C#コンストラクタの「空文字7つ」の初期化を再現
members: List[str] = Field(
default_factory=lambda: [""] * 7,
description="属性の選択肢リスト（例：['夜勤可', '夜勤不可', '', ... ]）。"
)
class GroupProperties(BaseModel):
"""
複数のスタッフ属性定義（GroupProperty）を管理するリストクラスです。
"""
name: str = Field(
default="GroupProperties",
frozen=True,
description="オブジェクト名。常に 'GroupProperties' 固定です。"
)
members: List[GroupProperty] = Field(
default_factory=list,
description="GroupProperty オブジェクトのリストです。"
)
class ShiftLevel(BaseModel):
"""
予定セルにおけるシフトとその制約レベル、表示用インデックスを定義します。
"""
shift: str = Field(
default="",
description="shift_object または shift_aggregate_class の定義名(def_name)を参照します。"
)
level: int = Field(
default=0,
description=(
"ソフト制約の重みインデックス（通常1-7）。"
"0以下の値はハード制約（絶対に守るべき制約）を意味します。"
)
)
a_ix: int = Field(
default=-1,
description=(
"another_labelを指すインデックス。デフォルトは-1。"
"0以上のとき、該当するラベルのインデックスとして機能します。"
)
)
locked: bool = Field(
default=False,
description="GUI上で予定セルの編集がロックされているかどうかを示すフラグ（2026年1月12日追加）。"
)
class GroupAggregate(BaseModel):
"""
スタッフ属性（GroupProperty）または他の集合（GroupAggregate）を組み合わせて、
新しい属性集合を定義します。
"""
use: bool = Field(
default=False,
description="有効(true)か無効かを示すフラグ。無効ならソルバは参照しません。"
)
name: str = Field(
default="GroupAggregateDef",
frozen=True,
description="オブジェクト名。常に 'GroupAggregateDef' 固定です。"
)
def_name: str = Field(
default="",
description="この属性集合の定義名（例: '夜勤リーダー候補', '新人以外' など）。"
)
Operator: Literal["AND", "OR", "NOT"] = Field(
default="OR",
description="演算子。AND（かつ）、OR（または）、NOT（以外）のいずれかを指定します。"
)
# C#コンストラクタの「空文字7つ」の初期化を再現
members: List[str] = Field(
default_factory=lambda: [""] * 7,
description=(
"対象となるメンバー名のリスト。group_property または "
"他の group_aggregate の def_name を参照します。循環参照は禁止です。"
)
)
class GroupAggregates(BaseModel):
"""
複数のスタッフ属性集合定義（GroupAggregate）を管理するリストクラスです。
"""
name: str = Field(
default="GroupAggregates",
frozen=True,
description="オブジェクト名。常に 'GroupAggregates' 固定です。"
)
members: List[GroupAggregate] = Field(
default_factory=list,
description="GroupAggregate オブジェクトのリストです。"
)
class StaffProperty(BaseModel):
"""
個々のスタッフの属性（可能なシフト、タスク、所属グループ等）を定義します。
"""
use: bool = Field(
default=True,
description="有効(true)か無効かを示すフラグ。無効ならソルバは参照しません。"
)
name: str = Field(
default="StaffPropertyDef",
frozen=True,
description="オブジェクト名。常に 'StaffPropertyDef' 固定です。"
)
def_name: str = Field(
default="",
description="スタッフの名前（一意の識別子）。"
)
shifts: Set[str] = Field(
default_factory=list,
description="このスタッフが担当可能なシフト名のリスト（C#のSortedSetに対応）。"
)
tasks: Set[str] = Field(
default_factory=list,
description="このスタッフが担当可能なタスク名のリスト（C#のSortedSetに対応）。"
)
properties: dict[str, str] = Field(
default_factory=dict,
description="グループプロパティ名と選択された属性値のマップ（例: {'夜勤属性': '夜勤可'}）。"
)
comment: str = Field(
default="",
description="スタッフに関するメモ・コメント（2026年1月12日更新）。"
)
class StaffProperties(BaseModel):
"""
全スタッフの属性定義を一括管理するコンテナクラスです。
"""
name: str = Field(
default="StaffProperties",
frozen=True,
description="オブジェクト名。常に 'StaffProperties' 固定です。"
)
members: List[StaffProperty] = Field(
default_factory=list,
description="StaffProperty オブジェクトのリストです。"
)
class ShiftSchedules(BaseModel):
"""
全スタッフ・全日程のシフト割り当て（二次元リスト）を管理します。
"""
# C# の const string name = "Schedules" を再現
name: str = Field(
default="Schedules",
frozen=True,
description="オブジェクト名。常に 'Schedules' 固定です。"
)
# List> members を再現
# 外側のリストが「スタッフ」、内側のリストが「日付」に対応します
members: list[list[ShiftLevel]] = Field(
default_factory=list,
description="シフト割り当ての二次元リスト。例: members[スタッフIndex][日付Index]"
)
class Solution(BaseModel):
"""
全スタッフ・全日程のシフト割り当て（二次元リスト）結果を格納するコンテナ。
"""
# List> members を再現
# 外側のリストが「スタッフ」、内側のリストが「日付」に対応します
members: list[list[ShiftLevel]] = Field(
default_factory=list,
description="シフト割り当ての二次元リスト。例: members[スタッフIndex][日付Index]"
)
class RowConstraint(BaseModel):
"""
行制約（勤務パターンの禁止、回数、勤務時間など）を定義する詳細モデルです。
"""
# 基本情報
name: str = Field(default="RowConstraint", frozen=True)
def_name: str = Field(..., description="行制約名（必須）。")
use: bool = Field(default=True, description="有効フラグ。def_nameが空の場合はFalseになります。")
phase_mode: bool = Field(default=False, description="フェーズモードフラグ。")
equal_count_mode: bool = Field(default=False, description="同数カウントモードフラグ。")
# 日付・スタッフ属性
primary_day_type: str = Field(default="", description="date_object または date_aggregate の名称。必須")
first_day_type: str = Field(default="", description="パターンの開始日条件。")
last_day_type: str = Field(default="", description="パターンの終了日条件。")
staff_property_type: str = Field(default="", description="対象となるスタッフ属性。")
# パターン定義
pattern: list[ShiftLevel] = Field(default_factory=list, description="シフトパターンのリスト。必須")
inv_pattern: list[bool] = Field(default_factory=list, description="patternに対応するNOTリスト。必須")
shift_pattern: list[ShiftLevel] = Field(default_factory=list, description="phase mode用シフトパターン。")
shift_inv_pattern: list[bool] = Field(default_factory=list, description="phase mode用NOTリスト。")
# 同数カウントモード用
intercept: int = Field(default=0, description="数値オフセット。")
A_daytypes: list[str] = Field(default_factory=list, description="Aグループの曜日タイプ。")
B_daytypes: list[str] = Field(default_factory=list, description="Bグループの曜日タイプ。")
# 制約の詳細設定
constraint_type: int = Field(default=0, description="0:シフト禁止, 1:回数, 2:勤務時間, 3:Phase, 4:回数比較 必須")
max_value: int = Field(default=-1)
min_value: int = Field(default=-1)
max_double: float = Field(default=-1.0)
min_double: float = Field(default=-1.0)
max_staff_property: str = Field(default="")
min_staff_property: str = Field(default="")
soft_constraint_level: int = Field(default=0, description="0:ハード, 1-7:ソフトレベル 必須")
# バリデータ: C#コンストラクタのロジックを再現
@field_validator("def_name", mode="before")
@classmethod
def trim_name(cls, v: str) -> str:
return v.strip() if isinstance(v, str) else v
@model_validator(mode="after")
def apply_constructor_logic(self) -> "RowConstraint":
# def_nameが空なら自動的に無効化
if not self.def_name:
self.use = False
# equal_count_mode が True の場合の初期設定
if self.equal_count_mode:
self.constraint_type = 4
self.intercept = 0
if not self.A_daytypes:
self.A_daytypes = [""]
if not self.B_daytypes:
self.B_daytypes = [""]
return self
class RowConstraintsGroup(BaseModel):
"""
行制約のグループ定義です。
C#のコンストラクタ row_constraints_group(def_name_, phase_mode_, equal_count_mode_) の仕様を反映しています。
"""
def_name: str = Field(
...,
description="制約グループの定義名（必須）。"
)
phase_mode: bool = Field(
default=False,
description="フェーズモード。シフト勤務表では常にFalse、タスク勤務表ではGUI制御に使用します。"
)
equal_count_mode: bool = Field(
default=False,
description="回数比較モード（2023年3月追加）。オンにすると回数比較専用のGUIになります。"
)
name: str = Field(
default="RowConstraintsGroup",
description="オブジェクト名"
)
use: bool = Field(
default=True,
description="有効(true)か無効か。無効ならソルバは参照しません。"
)
members: list[RowConstraint] = Field(
default_factory=list,
description="このグループに属する個別の行制約（RowConstraint）のリスト"
)
@field_validator("def_name", mode="before")
@classmethod
def trim_def_name(cls, v: str) -> str:
"""C#のTrim()処理を再現"""
if isinstance(v, str):
return v.strip()
return v
class RowConstraints(BaseModel):
"""
全ての行制約グループを一括管理するクラスです。
"""
name: str = Field(
default="RowConstraints",
frozen=True,
description="オブジェクト名。常に 'RowConstraints' 固定です。"
)
members: list[RowConstraintsGroup] = Field(
default_factory=list,
description="行制約グループ (RowConstraintsGroup) のリスト"
)
class ColumnConstraint(BaseModel):
"""
列制約（日付ごとの必要人数、勤務時間、シフト禁止・強制など）を定義するモデルです。
"""
# 基本情報
name: str = Field(default="ColumnConstraint", frozen=True)
def_name: str = Field(..., description="列制約名（必須）。前後の空白は自動的に削除されます。")
use: bool = Field(default=True, description="有効フラグ。名前が空の場合は自動的にFalseになります。")
# シフト・タスク・日付・スタッフ属性
shift_type: str = Field(default="", description="shift_object または shift_aggregate の名称。")
shift_at_phase: str = Field(default="", description="タスク勤務表フェーズ用シフト（2023年1月4日追加）。")
task_type: str = Field(default="", description="タスクオブジェクトまたはタスク集合の名称（タスク勤務表用）。")
primary_day_type: str = Field(default="", description="date_object または date_aggregate の名称。")
staff_property_type: str = Field(default="", description="スタッフ属性（group_property 等）の名称。")
# 制約タイプ
constraint_type: int = Field(
default=0,
description="0:シフト禁止, 1:max-min, 2:シフト強制, 3:勤務時間max-min, 4:整数計数"
)
# タスク勤務表用 Daily制約テーブルプロパティ
dayphase_vec_max: str = Field(default="", description="Daily制約テーブル(Max)に対応するプロパティ。")
dayphase_vec_min: str = Field(default="", description="Daily制約テーブル(Min)に対応するプロパティ。")
# 数値制約（整数・実数）
max_value: int = Field(default=-1, description="max-minの場合の最大値。設定しない場合は負の値。")
min_value: int = Field(default=-1, description="max-minの場合の最小値。設定しない場合は負の値。")
max_double: float = Field(default=-1.0, description="勤務時間max。設定しない場合は負の値。")
min_double: float = Field(default=-1.0, description="勤務時間min。設定しない場合は負の値。")
# ソフト制約レベル
soft_constraint_level: int = Field(
default=0,
description="ソフト制約レベル。0:ハード, 1:最弱, 7:最強。"
)
soft_constraint_level_max: int = Field(
default=0,
description="Max専用のソフト制約レベル。min-maxでレベルを分けたい場合に使用。"
)
# バリデータ: C#コンストラクタのロジックを再現
@field_validator("def_name", mode="before")
@classmethod
def trim_def_name(cls, v: str) -> str:
"""C#のTrim()を再現"""
return v.strip() if isinstance(v, str) else v
@model_validator(mode="after")
def validate_use_state(self) -> "ColumnConstraint":
"""名前が空なら有効フラグをFalseにするロジックを再現"""
if not self.def_name:
self.use = False
return self
class ColumnConstraintsGroup(BaseModel):
"""
列制約のグループ定義です。
C#のコンストラクタ column_constraints_group(def_name_, phase_mode_) の仕様を反映しています。
"""
def_name: str = Field(
...,
description="制約グループの定義名（必須）。"
)
phase_mode: bool = Field(
default=False,
description="フェーズモード。シフト勤務表では常にFalse、タスク勤務表ではGUI制御に使用します。"
)
name: str = Field(
default="ColumnConstraintsGroup",
frozen=True,
description="オブジェクト名"
)
use: bool = Field(
default=True,
description="有効(true)か無効か。def_nameが空文字の場合はFalseとして扱われます。"
)
members: list[ColumnConstraint] = Field(
default_factory=list,
description="このグループに属する個別の列制約（ColumnConstraint）のリスト"
)
# Color型はSystem.Text.Jsonで直接扱えないため、文字列(HTMLカラーコード)として定義
#tab_color: str = Field(
# default="#FFFFFF",
# description="GUIのタブカラー。HTMLカラーコード（例: #FFFFFF）または色名（White）で指定。"
#)
@field_validator("def_name", mode="before")
@classmethod
def validate_and_trim_def_name(cls, v: str) -> str:
"""C#のTrim()処理および空文字時のuse=falseロジックの再現"""
if isinstance(v, str):
trimmed = v.strip()
return trimmed
return v
@field_validator("use", mode="after")
@classmethod
def set_use_by_def_name(cls, v: bool, info) -> bool:
"""def_nameが空なら強制的にuseをFalseにするロジックを再現"""
if not info.data.get("def_name"):
return False
return v
class ColumnConstraints(BaseModel):
"""
全ての列制約グループを一括管理するクラスです。
"""
name: str = Field(
default="ColumnConstraints",
frozen=True,
description="オブジェクト名。常に 'ColumnConstraints' 固定です。"
)
members: list[ColumnConstraintsGroup] = Field(
default_factory=list,
description="列制約グループ (ColumnConstraintsGroup) のリスト"
)
class PairConstraint(BaseModel):
"""
2つの要素（AとB）の間の相関制約（禁止、ならば、比較など）を定義するモデルです。
"""
name: str = Field(default="PairConstraint", frozen=True)
def_name: str = Field(default="", description="制約名（一意）")
use: bool = Field(default=True, description="有効フラグ")
# モード設定
phase_mode: bool = Field(default=False, description="タスク勤務表モードフラグ")
equal_count_mode: bool = Field(default=False, description="リニア不等式（数値比較）モードフラグ")
# 対象 A
shift_typeA: str = Field(default="", description="Aのシフト/タスク集合名")
staff_property_typeA: str = Field(default="", description="Aのスタッフ属性/集合名")
operatorA: str = Field(default="", description="通常時: OR, AND等 / 数値比較時: A係数(数字またはBFULL)")
# 対象 B
shift_typeB: str = Field(default="", description="Bのシフト/タスク集合名")
staff_property_typeB: str = Field(default="", description="Bのスタッフ属性/集合名")
operatorB: str = Field(default="", description="通常時: OR, AND等 / 数値比較時: B係数(数字またはAFULL)")
# 共通条件
day_type: str = Field(default="", description="対象となる日付集合名")
dayoffset: int = Field(default=0, description="Aに対するBの日付オフセット")
# 制約の詳細
constraint_type: int = Field(
default=0,
description="0:!(A&&B)禁止, 1:AならばB, 2:A==B, 3:A>=B, 4:A<=B"
)
soft_constraint_level: int = Field(default=0, description="0:ハード, 1-7:ソフトレベル")
# タスク・フェーズ関連 (2024年1月更新対応)
phase_str: str = Field(default="", description="フェーズ識別子 (例: ph0)")
shift_typeA_at_phase: str = Field(default="", description="フェーズ時のAシフト参照")
shift_typeB_at_phase: str = Field(default="", description="フェーズ時のBシフト参照")
# 数値オフセット関連
numerical_offset: int = Field(default=0, description="数値比較モード時の定数オフセット")
numerical_offset_string: str = Field(default="", description="数値オフセットの文字列表現 (2024年1月追加)")
class PairConstraintsGroup(BaseModel):
"""
ペア制約のグループ。GUIのタブ表示単位に対応します。
"""
name: str = Field(default="PairConstraintsGroup", frozen=True)
def_name: str = Field(default="", description="グループ名")
use: bool = Field(default=True)
equal_count_mode: bool = Field(default=False)
phase_mode: bool = Field(default=False)
members: list[PairConstraint] = Field(default_factory=list)
# System.Drawing.Colorの互換性のため文字列として保持
#tab_color: str = Field(default="White", description="タブの背景色 (ColorTranslator形式)")
class PairConstraints(BaseModel):
"""
全てのペア制約グループを管理するトップレベルクラスです。
"""
name: str = Field(default="PairConstraints", frozen=True)
members: list[PairConstraintsGroup] = Field(default_factory=list)
@field_validator("members", mode="before")
@classmethod
def ensure_list(cls, v):
return v if isinstance(v, list) else []
class SwInt(BaseModel):
"""
ソルバの制約許容数や重み（ウェイト）を定義するモデルです。
"""
use: bool = Field(
default=False,
description="有効(true)か無効(false)かを示すフラグ。"
)
value: int = Field(
default=0,
description="1制約あたりのCARDINALS許容エラー数（スラック変数）。"
)
total_max_errors: int = Field(
default=0,
description="現在使用されていません（0: 最小化を意味します）。"
)
weight: int = Field(
default=1,
description=(
"ソフト制約の重み（自然数、1-10推奨）。"
"※ソフトレベル（1-7のインデックス）とは異なる「実際の重み係数」です。"
)
)
class SolvingParameters(BaseModel):
"""
ソルバの求解パラメータ、ソフト制約レベルごとの重み設定、
および外部Python制約などを管理するクラスです。
"""
name: str = Field(
default="SolvingParameters",
frozen=True,
description="オブジェクト名。常に 'SolvingParameters' 固定です。"
)
# Dictionary> solving_map を再現
# 外側のキー(int)はソフト制約レベル(1-7など)、内側のキー(str)は制約名
solving_map: dict[int, dict[str, SwInt]] = Field(
default_factory=dict,
description="ソフトレベルおよび制約名ごとの詳細設定マップ。"
)
# Pythonによる制約記述
external_constraint_python: str = Field(
default="",
description="Pythonスクリプトによる外部制約記述。"
)
# プロジェクトコメント
comment: str = Field(
default="",
description="プロジェクトの変更履歴やメモ用コメント。"
)
# 求解パラメータ Dictionary
parameters: dict[str, int] = Field(
default_factory=dict,
description="ソルバの各種数値パラメータ（イテレーション回数等）。"
)
# 現在使用されていない、または内部用のフィールド
aws_parameters: dict[str, str] = Field(
default_factory=dict,
description="AWS関連パラメータ（現在未使用）。"
)
external_constraint: str = Field(
default="",
description="言語制約記述（現在未使用）。"
)
python_property_file: str = Field(
default="",
description="内部用プロパティファイルパス（編集不可）。"
)
python_property_file_post: str = Field(
default="",
description="内部用プロパティファイルパス（後処理、編集不可）。"
)
class ApiResponse(BaseModel):
"""
WinForms API からの実行結果レスポンスを定義するモデルです。
"""
# status の選択肢を Literal で定義（complete, rejected, accepted, error, unknown_api）
status: Literal["complete", "rejected", "accepted", "error", "unknown_api"] = Field(
...,
description="APIリクエストの処理ステータス。"
)
solver_status: Optional[str] = Field(
default=None,
description="ソルバの内部状態（例: Optimal, Feasible, Timeout 等）。"
)
error_reason: Optional[str] = Field(
default=None,
description="エラーが発生した場合の理由、または詳細メッセージ。"
)
value: Optional[str] = Field(
default=None,
description="APIから返される主要な戻り値（JSON文字列や特定の識別子など）。"
)
progress: int = Field(
default=0,
description="現在の処理進捗状況。"
)
total: int = Field(
default=100,
description="全体の処理数。デフォルト値は100です。"
)
def get_value_as(self, model_class: Type[T]) -> Optional[T]:
if not self.value:
return None
try:
return model_class.model_validate_json(self.value)
except ValidationError:
return None
#PIPE_NAME =f'\\\\.\\pipe\\winforms_pipe'# r'\\.\pipe\winforms_pipe'
PIPE_NAME = "winforms_pipe"
async def call_winforms_api(api_name: str, payload: dict, ctx=None)->ApiResponse:
pipe = AsyncNamedPipeClient(PIPE_NAME)
# 1. パイプ接続
try:
await pipe.connect()
except PipeNotConnectedError as e:
return {"status": "pipe_error", "message": str(e)}
# 2. JSON リクエスト送信
request = json.dumps({"api": api_name, "payload": payload})
try:
print("Writing api_name=",api_name)
await pipe.write_line(request)
except PipeNotConnectedError as e:
await pipe.close()
return {"status": "write_error", "message": str(e)}
# 3. 継続的な読み取りループ
try:
print("Reading api_name=",api_name)
while True:
response_line = await pipe.read_line()
if not response_line:
break
try:
data = json.loads(response_line)
except json.JSONDecodeError:
continue # 不正な行はスキップして次を待つ
status = data.get("status")
solver_status = data.get("solver_status")
error_reason=data.get("error_reason")
value=data.get("value")
print(status)
if solver_status == "Feasible_Solution":
print("実行可能解が見つかりました！")
elif solver_status == "Solving":
# 進捗報告時に詳細ステータスを添える
if ctx:
await ctx.report_progress(progress=data.get("progress"), total=100)
print(f"ステータス: {solver_status}")
# A. 完了時の処理
if status == "complete":
if value is not None :
print("value len=",len(value))
# 最後に100%を報告（任意）
if ctx:
await ctx.report_progress(progress=100, total=100)
# 辞書を ApiResponse モデルに変換して返す
return ApiResponse.model_validate(data)
# B. エラー時の処理
if status in ["error", "rejected", "unknown_api"]:#if status == "error" or status=="rejected" :
if status=="unknown_api":
print("サポートしていないAPIです。")
if status=="rejected":
print("APIが拒否されました")
if solver_status=="Infeasible_Solution":
print("解が見つかりませんでした（実行不能）。")
elif solver_status=="ProjectFile_NOT_Specified":
print("プロジェクトファイルが保存されていません。スケジュールナース→ファイルメニュー→名前をを付けて保存してください。")
elif solver_status=="Compile_Failed":
print("プロジェクトファイルのコンパイルに失敗しました。")
elif solver_status=="Solving_Engine_Invoking_Failure":
print("求解エンジンの起動に失敗しました。")
elif solver_status=="Solving_Killed_by_User":
print("求解がユーザにより中止させられました")
return ApiResponse.model_validate(data)#辞書を ApiResponse モデルに変換して返す
# C. それ以外（進捗報告など）
if ctx:
# WinForms側のJSONに progress/total があればそれを使う
# 無ければ現在のステップとして報告
p = data.get("progress", 0)
t = data.get("total", 100)
# Contextを通じてMCPクライアントに通知
await ctx.report_progress(progress=p, total=t)
# ログ出力（任意）
# print(f"進捗報告中: {p}/{t}")
except PipeNotConnectedError as e:
return {"status": "read_error", "message": str(e)}
#finally:
# await pipe.close()
return {"status": "unexpected_termination"}
# -------------------------------
# WinForms に API を発行する関数
# -------------------------------
# FastMCP サーバー作成
mcp = FastMCP("local-mcp")
#mcp = FastMCP(name="私の最初のMCPサーバー")
# -------------------------------
# MCP ツール → WinForms API 呼び出し
# -------------------------------
@mcp.tool()
async def get_shift_definitions()-> ShiftObjects| None:
"""
スケジュールナースから現在の全てのシフト定義（名前、色、ラベル、サブラベル等）を取得します。
"""
api_res= await call_winforms_api("get_shift_objects", {} )
#print("api_res=",api_res)
if api_res.status=="complete":
SO=api_res.get_value_as(ShiftObjects)
#print("SO=",SO)
return SO
else:
return None
@mcp.tool()
async def update_shift_definitions(data:ShiftObjects)-> ApiResponse:
"""
スケジュールナースから現在の全てのシフト定義（名前、色、ラベル、サブラベル等）を取得します。
"""
text = data.model_dump_json()
payload={"text":text}
return await call_winforms_api("update_shift_objects",payload )
@mcp.tool()
async def get_shift_aggregates_definitions()-> ShiftAggregates | None:
"""
スケジュールナースから現在の全てのシフト集合定義（名前、色、ラベル、サブラベル等）を取得します。
"""
api_res= await call_winforms_api("get_shift_aggreggates", {} )
if api_res.status=="complete":
SA=api_res.get_value_as(ShiftAggregates)
#print("SO=",SO)
return SA
else:
return None
@mcp.tool()
async def get_shift_solution()-> Solution | None:
"""
スケジュールナースから現在の全てのシフト集合定義（名前、色、ラベル、サブラベル等）を取得します。戻り値は、Schedulesクラスと同じ2次元形式です。
"""
api_res= await call_winforms_api("get_shift_solution", {} )
if api_res.status=="complete":
So=api_res.get_value_as(Solution)
#print("SO=",SO)
return So
else:
return None
@mcp.tool()
async def get_date_objects()-> DateObjects | None:
"""
スケジュールナースから現在の全てのDateObjectを取得します。
"""
api_res= await call_winforms_api("get_date_objects", {} )
if api_res.status=="complete":
So=api_res.get_value_as(DateObjects)
#print("SO=",SO)
return So
else:
return None
@mcp.tool()
async def get_date_aggregates()-> DateAggregates | None:
"""
スケジュールナースから現在の全てのDateAggregateを取得します。
"""
api_res=await call_winforms_api("get_date_aggregates", {} )
if api_res.status=="complete":
#print("api_res=",api_res.value)
So=api_res.get_value_as(DateAggregates)
#print("SO=",SO)
return So
else:
return None
@mcp.tool()
async def get_group_properties()-> GroupProperties | None:
"""
スケジュールナースから現在の全てのGroupPropertyを取得します。
"""
api_res=await call_winforms_api("get_group_properties", {} )
if api_res.status=="complete":
Gp=api_res.get_value_as(GroupProperties)
return Gp
else:
return None
@mcp.tool()
async def get_group_aggregates()-> GroupAggregates| None:
"""
スケジュールナースから現在の全てのGroupAggregateを取得します。
"""
api_res= await call_winforms_api("get_group_aggregates", {} )
if api_res.status=="complete":
#print("api_res=",api_res)
Gp=api_res.get_value_as(GroupAggregates)
return Gp
else:
return None
@mcp.tool()
async def get_staff_properties()-> StaffProperties:
"""
スケジュールナースから現在の全てのStaffPropertyを取得します。
"""
api_res= await call_winforms_api("get_staff_properties", {} )
if api_res.status=="complete":
#print("api_res=",api_res)
Sp=api_res.get_value_as(StaffProperties)
return Sp
else:
return None
@mcp.tool()
async def get_shift_schedules()->ShiftSchedules| None:
"""
スケジュールナースから現在のSchedulesを取得します。
"""
api_res= await call_winforms_api("get_shift_schedules", {} )
if api_res.status=="complete":
#print("api_res=",api_res)
Sc=api_res.get_value_as(ShiftSchedules)
return Sc
else:
return None
@mcp.tool()
async def get_row_constraints()-> RowConstraints| None:
"""
スケジュールナースから現在の全てのRowConstraintを取得します。
"""
api_res=await call_winforms_api("get_row_constraints", {} )
#print("api_res=",api_res)
if api_res.status=="complete":
#print("api_res=",api_res)
Sc=api_res.get_value_as(RowConstraints)
return Sc
else:
return None
@mcp.tool()
async def get_column_constraints()-> ColumnConstraints|None:
"""
スケジュールナースから現在の全てのColumnConstraintを取得します。
"""
api_res=await call_winforms_api("get_column_constraints", {} )
if api_res.status=="complete":
#print("api_res=",api_res)
Cc=api_res.get_value_as(ColumnConstraints)
return Cc
else:
return None
@mcp.tool()
async def get_pair_constraints()-> PairConstraints|None:
"""
スケジュールナースから現在の全てのColumnConstraintを取得します。
"""
api_res= await call_winforms_api("get_pair_constraints", {} )
if api_res.status=="complete":
#print("api_res=",api_res)
Pc=api_res.get_value_as(PairConstraints)
return Pc
else:
return None
@mcp.tool()
async def get_solving_parameters()-> SolvingParameters|None:
"""
スケジュールナースから現在のSolvingParametersを取得します。
"""
api_res= await call_winforms_api("get_solving_parameters", {} )
if api_res.status=="complete":
#print("api_res=",api_res)
Spp=api_res.get_value_as(SolvingParameters)
return Spp
else:
return None
@mcp.tool()
async def update_date_objects(data: DateObjects) -> ApiResponse:
"""
複数の日付定義（DateObject）を一括で更新します。
"""
# C#側へ送信するための辞書化
payload = data.model_dump_json()
# WinForms APIを呼び出してデータを送信
return await call_winforms_api("update_date_objects", payload)
@mcp.tool()
async def update_date_aggregates(data: DateAggregates) -> ApiResponse:
"""
日付集合（DateAggregates）の全リストを更新します。
"""
# Pydanticオブジェクトを辞書（JSON互換）に変換
# これにより members 内の DateAggregate もすべて辞書化されます
payload = data.model_dump_json()
# WinForms APIの呼び出し（例）
return await call_winforms_api("update_date_aggregates", payload)
@mcp.tool()
async def update_staff_group_properties(data: GroupProperties) -> str:
"""
スタッフの全属性定義（GroupProperties）を一括更新します。
"""
# 辞書形式に変換（ネストされた GroupProperty もすべて変換されます）
payload = data.model_dump_json()
# WinForms API への送信（例）
return await call_winforms_api("update_group_properties", payload)
@mcp.tool()
async def update_staff_group_aggregates(data: GroupAggregates) -> str:
"""
スタッフ属性の集合演算定義（GroupAggregates）を一括更新します。
"""
# 辞書形式に変換（WinForms API 送信用）
payload = data.model_dump_json()
return await call_winforms_api("update_group_aggregates", payload)
@mcp.tool()
async def update_staff_properties(data: StaffProperties) -> str:
"""
全スタッフの属性情報（担当可能シフト、属性マップ等）を一括更新します。
"""
# WinForms側へ送信するために辞書形式に変換
payload = data.model_dump_json()
return await call_winforms_api("update_staff_properties", payload)
@mcp.tool()
async def update_shift_schedules(data: ShiftSchedules) -> str:
"""
勤務表の全予定データ（二次元リスト）を一括更新します。
"""
# 再帰的に辞書形式に変換（ShiftLevel オブジェクトもすべて辞書化される）
payload = data.model_dump_json()
# WinForms API への送信
return await call_winforms_api("update_schedules", payload)
@mcp.tool()
async def update_row_constraints(data: RowConstraints) -> str:
"""
行制約（RowConstraints）の設定をすべて更新します。
"""
# 辞書形式に変換（ネストされたリストやオブジェクトもすべて変換されます）
payload = data.model_dump_json()
return await call_winforms_api("update_row_constraints", payload)
@mcp.tool()
async def update_column_constraints(data: ColumnConstraints) -> str:
"""
列制約（ColumnConstraints）の設定をすべて一括更新します。
"""
# model_dump_json() により C# 側が受信可能な JSON 形式の辞書に変換
payload = data.model_dump_json()
# 注意: C#側でColor.Whiteを復元できるよう、tab_colorには"White"などの文字列が入ります。
return await call_winforms_api("update_pair_constraints", payload)
@mcp.tool()
async def update_pair_constraints(data: PairConstraints) -> str:
"""
ペア制約（PairConstraints）の設定をすべて一括更新します。
"""
# model_dump_json() により C# 側が受信可能な JSON 形式の辞書に変換
payload = data.model_dump_json()
# 注意: C#側でColor.Whiteを復元できるよう、tab_colorには"White"などの文字列が入ります。
return await call_winforms_api("update_column_constraints", payload)
mcp.tool()
async def update_solving_parameters(data: SolvingParameters) -> str:
"""
求解パラメータ（SolvingParameters）の設定をすべて一括更新します。
"""
# model_dump_json() により C# 側が受信可能な JSON 形式の辞書に変換
payload = data.model_dump_json()
return await call_winforms_api("update_solving_parameters", payload)
@mcp.tool()
async def load_project(filepath: str) ->ApiResponse:
"""スケジュールナースのプロジェクトファイルをスケジュールナースにロードする MCP ツール"""
return await call_winforms_api("load_project", {"text": filepath})
@mcp.tool()
async def solve( payload: dict,ctx: Context= None) -> ApiResponse:
if ctx==None:
ctx = MockContext()
return await call_winforms_api("solve", payload, ctx)
# -------------------------------
# MCP サーバ起動
# -------------------------------
def start_server():
loop = asyncio.new_event_loop()
asyncio.set_event_loop(loop)
loop.create_task(python_stream())
mcp.run(port=5000)
# 1. MCPのContextを模倣するMockクラス
class MockContext:
async def report_progress(self, progress: float, total: float):
percentage = (progress / total) * 100
print(f"【MCP進捗通知】 現在の進捗: {percentage:.1f}% ({progress}/{total})")
async def call_tool(client,command,payload):
print("=== ",command," テスト開始 ===")
result = await client.call_tool(command, payload)
print("\n[Step 2] 最終結果を受信しました:")
print(result.content[0].text)#.dumps(result, indent=2, ensure_ascii=False))
print("=== ",command," テスト終了 ===\n")
return result.content[0].text
async def api_test(api1,api2,obj):
api_res= await call_winforms_api(api1, {} )
if api_res.status!="complete":
return False
#print("api_res=",api_res)
data=api_res.get_value_as(obj)
#print("??data=",data)
text = data.model_dump_json()# model_dump_json()
#print("text=",text)
payload={"text":text}
api_res= await call_winforms_api(api2,payload)##{} )
#print("api_res after update shift aggregates",api_res)
api_res= await call_winforms_api(api1, {} )
if api_res.status!="complete":
print("Failed === api_test "+api1+" "+api2+"テスト終了===\n")
return False
data2=api_res.get_value_as(obj)
if data !=data2:
print("Failed === api_test "+api1+" "+api2+"テスト終了===\n")
return False
print("Success === api_test "+api1+" "+api2+"テスト終了===\n")
return True
async def test_server_locally():
print("\n--- ローカルサーバーのテスト ---")
# クライアントをサーバーオブジェクトに直接ポイントします
client = Client(mcp)
ctx = MockContext()
async with client:
#filepath=r"C:\Users\sugaw\Documents\FA\sc3\プロジェクトサンプル\標準パターン\３交代深準標準パターン.nurse3"#'C:\Users\sugaw\Documents\FA\sc3\プロジェクトサンプル\プロジェクトサンプル\チュートリアル３A.nurse3'
filepath=r"C:\Users\sugaw\Documents\FA\sc3\プロジェクトサンプル\プロジェクトサンプル\チュートリアル３A.nurse3"
#filepath=r"C:\Users\sugaw\Documents\FA\sc3\release_check\2025.10_0930ver2.nurse3"
payload={"filepath":filepath}
await call_tool(client,"load_project",payload)
# テスト用ペイロード ctxは、シリアライズできないので、そのまま載せられない
payload = {
"payload": {},
}
await call_tool(client,"solve",payload)
#SO_str=await call_tool(client,"get_shift_definitions", payload)
#deliv_from_dict = Delivery.model_validate(deliv_dict)
#SO = ShiftObjects.model_validate_json(SO_str)
#print("*SO=",SO)
#text=SO.model_dump_json()
#print("*S0_str=",text)
#payload={"text":text}
#api_res=await call_winforms_api("update_shift_objects",payload )
#print(api_res)
#SO_str2=await call_tool(client,"get_shift_definitions", payload)
#compare_str(SO_str,SO_str2)
#deliv_dict = deliv.model_dump_json() # ◎
# >> {'timestamp': datetime.datetime(2020, 1, 2, 3, 4, 5, tzinfo=datetime.timezone.utc), 'products': [{'name': 'sushi', 'price': 1000}]}
#deliv_json = deliv.model_dump_json() #
"""
SA=await call_tool(client,"get_shift_aggregates_definitions", payload)
print("SA=",SA)
So=await call_tool(client,"get_shift_solution", payload)
print("Solution=",So)
DO=await call_tool(client,"get_date_objects", payload)
print("DateObjects=",DO)
DA=await call_tool(client,"get_date_aggregates", payload)
print("DateAggregates=",DA)
GP=await call_tool(client,"get_group_properties", payload)
print("Groupp Properties=",GP)
GA=await call_tool(client,"get_group_aggregates", payload)
print("Group Aggregates=",GA)
SP=await call_tool(client,"get_staff_properties", payload)
print("Staff Properties=",SP)
SC=await call_tool(client,"get_shift_schedules", payload)
print("Shit Schedules=",SC)
RC=await call_tool(client,"get_row_constraints", payload)
print("Row Constraints=",RC)
CC=await call_tool(client,"get_column_constraints", payload)
print("Column Constraints=",CC)
PC=await call_tool(client,"get_pair_constraints", payload)
print("Pair Constraints=",PC)
SPP=await call_tool(client,"get_solving_parameters",payload)
print("Solving Parameter=",SPP)
print("update_shift_objects Test")
api_res= await call_winforms_api("update_shifts",SO.model_dump_json())"""
async def test_server_api():
for i in range(1):
print("****Loop=",i)
#filepath=r"C:\Users\sugaw\Documents\FA\sc3\プロジェクトサンプル\標準パターン\３交代深準標準パターン.nurse3"#'C:\Users\sugaw\Documents\FA\sc3\プロジェクトサンプル\プロジェクトサンプル\チュートリアル３A.nurse3'
#filepath=r"C:\Users\sugaw\Documents\FA\sc3\プロジェクトサンプル\プロジェクトサンプル\チュートリアル３A.nurse3"
#filepath=r"C:\Users\sugaw\Documents\FA\sc3\release_check\2025.10_0930ver2.nurse3"
#filepath=r"C:\Users\sugaw\Documents\FA\sc3\寒河江\8月V1Color.nurse3"
filepath=r"C:\Users\sugaw\Documents\FA\sc3\release_check3\神戸大0405_5_V4.nurse3"
payload={"text":filepath}
api_res= await call_winforms_api("load_project",payload )
# テスト用ペイロード ctxは、シリアライズできないので、そのまま載せられない
payload = {
"payload": {},
}
api_res=await call_winforms_api("solve",payload)
await api_test("get_shift_objects","update_shift_objects",ShiftObjects)
await api_test("get_shift_aggregates","update_shift_aggregates",ShiftAggregates)
await api_test("get_date_objects","update_date_objects",DateObjects)
await api_test("get_date_aggregates","update_date_aggregates",DateAggregates)
await api_test("get_group_properties","update_group_properties",GroupProperties)
await api_test("get_group_aggregates","update_group_aggregates",GroupAggregates)
await api_test("get_staff_properties","update_staff_properties",StaffProperties)
await api_test("get_shift_schedules","update_shift_schedules",ShiftSchedules)
await api_test("get_row_constraints","update_row_constraints",RowConstraints)
await api_test("get_column_constraints","update_column_constraints",ColumnConstraints)
await api_test("get_pair_constraints","update_pair_constraints",PairConstraints)
await api_test("get_solving_parameters","update_solving_parameters",SolvingParameters)
async def test_solve_locally():
ctx = MockContext()
# 以前作成した継続読み取り版の call_winforms_api を呼び出し
# ※ WinFormsアプリを起動した状態で実行してください
filepath=r'C:\Users\sugaw\Documents\FA\sc3\Project_Samples\プロジェクトサンプル\チュートリアル３.nurse3'
payload={"text":filepath}
result = await call_winforms_api("load_project", payload, ctx=ctx)
print("\n[Step 2] 最終結果を受信しました:")
print(json.dumps(result, indent=2, ensure_ascii=False))
print("=== load_projectテスト終了 ===")
print("\n[Step 1] WinFormsへ 'solve' 命令を送信します...")
# 以前作成した継続読み取り版の call_winforms_api を呼び出し
# ※ WinFormsアプリを起動した状態で実行してください
# テスト用ペイロード
payload = {
"mode": "normal",
"options": {"max_iterations": 1000}
}
result = await call_winforms_api("solve", payload, ctx=ctx)
print("\n[Step 2] 最終結果を受信しました:")
print(json.dumps(result, indent=2, ensure_ascii=False))
print("=== solveテスト終了 ===")
result = await call_winforms_api("solve", payload, ctx=ctx)
print("\n[Step 2] 最終結果を受信しました:")
print(json.dumps(result, indent=2, ensure_ascii=False))
print("=== solveテスト終了 ===")
print("=== Solve API ローカルテスト開始 ===")
print("\n[Step 1] WinFormsへ 'get_shift_objects' 命令を送信します...")
result=await call_winforms_api("get_shift_objects",{}, ctx=ctx);
print("\n[Step 2] 最終結果を受信しました:")
print(json.dumps(result, indent=2, ensure_ascii=False))
print("=== get_shift_objectsテスト終了 ===")
print("\n[Step 1] WinFormsへ 'load_project' 命令を送信します...")
if __name__ == "__main__":
try:
asyncio.run(test_server_api())#test_server_locally())#Test())#test_solve_locally())# エントリポイントは一つにする
except KeyboardInterrupt:
pass
except Exception as e:
print(f"エラーが発生しました: {e}")