2026年1月26日月曜日

LLMに正しい演算をさせるために

 DateObjectsや、DateAggregatesは、スケジュールナースのDay集合に関する根幹です。全ての制約は、Day集合、Shift集合、StaffPropertyで成立していますがその根幹部品のうちの一つです。

今まで、Day集合は、仕様提示に基づいて、LLMがよしなに、やってくれるだろう、と勝手に期待していたのですが、スケジュールナース自身の自明ではない実装もあり、心配になりました。以下のやり取りが、それです。

LLMに正しい演算をさせるには、それなりのステップを踏む必要があることが分かりました。

「曖昧な指示」については、こちらの努力の中にありますが、「長い仕様を完全に保持し続けるのが苦手」や、「ショートカットすることがある」は、論外で、努力の外です。

ということで、何度かのやり取りの後、最終的にMCPツールとして公開するのが正解、という結論になりました。以下の会話の通り、コパイ（ChatGPT）は、質問者に忖度する傾向が見て取れると思います。最後の質問(私の改善提案）が無かったとして、LLMの回答を鵜呑みにしたとすると、ドキュメント作成だけで数か月を要してしまう仕事をされられた、可能性があったことに注意してください。

同じことが、プログラミングや、勤務表作り、あらゆる場面で、起こる可能性があると思います。

既にプログミングの世界では、バイブコーディングというAIがプログラミングコードを作ることが当たり前になりつつありますが、どうも思った程簡単ではないようです。

バイブコーディングという地獄
そのAI生成コード、全部レビューしますか？全部信じますか？

2025/10/20時点で最良のAIコーディングプロセス

リーナス・トーバルズもAIでコードを書く時代

結局は、どこまで信じればよいか？という問題が常に付きまといます。

プロトタイプ、概念検証という部分では、素晴らしい速度を発揮しますが、いきなり完成品を見せられても、どこかで間違っている可能性がある、どのステージでどういう検証を入れるか？という問題は、本質的に残るのではないかと思っています。

一方、スケジュールナースの制約は、「一つ実装、一つ確認」　をずっと提唱しているのですが、それは、人間に限らずLLMも同様、と思えます。

現在、他の自然言語によるモデリングが成功しないのは、上の報告群を鑑みれば、実は当たり前で、所詮、現在のAIレベルはその程度のもの、粒度をもっともっと細かくしてチェックを頻繁に入れる必要がある、ということではないかと思います。

その意味で、現在取っている開発アプローチは、間違っていないようだ、と言えると思います。

そこにMCPの価値があった、というお話でした。





Q.LLMは、集合演算ができるのだろうか？という疑問が沸いてきました。

もちろん扱えますよ。
ただし「どういう意味での集合演算か」によって、得意さの度合いが変わります。

🔍 LLMが得意な集合演算

LLMはテキストベースの推論が得意なので、概念的・論理的な集合演算は問題なく扱えます。

  • 集合の定義
  • 和集合 (A \cup B)
  • 共通部分 (A \cap B)
  • 差集合 (A - B)
  • 部分集合の判定
  • 集合の性質の説明
  • 集合を使った論理推論

例：

A = {1,2,3}, B = {3,4}
A ∪ B = {1,2,3,4}
A ∩ B = {3}
A - B = {1,2}

⚠️ LLMが苦手なケース

LLMは「計算機としての厳密な集合処理」は得意ではありません。

  • 大規模データの集合演算
  • 厳密なアルゴリズム実行
  • 膨大な要素の正確な列挙
  • 数万件のデータを扱うような実務的な集合処理

こうした場合は、PythonやSQLなどのプログラム言語の方が確実です。

🎯 まとめ

  • 論理的・概念的な集合演算 → 得意
  • 大量データを伴う厳密な集合演算 → 不向き

もし具体的な集合を使って試したいなら、例を教えてください。
あなたの得意なPythonやC#との比較も含めて、もっと深く掘り下げられますよ。


Q.集合を演算するEvaluatorのコードの提示を受けました。コードの良しあしは別にして、、このコードを呼び出すことは出来るのかを聞きました。

結論から言うと、LLM は evaluator を「実行する」ことはできませんが、「模倣して推論する」ことはできます。
ここがとても重要なポイントです。

🎯 LLM ができること・できないこと

✅ できる：Evaluator のロジックを理解し、推論として再現する

LLM はコードを読んで、その意味を理解し、
「この DateAggregate を評価するとどうなるか」を推論として答えることができます。

たとえば：

  • AND / OR / NOT の集合演算
  • ±1〜±10 のシフト
  • Rep7 の周期展開
  • DateObject の dates の統合
  • 循環参照の検出ロジックの説明

これらは LLM の内部推論能力で再現可能です。

つまり、Evaluator の「動作を真似る」ことはできます。

❌ できない：Evaluator のコードを実際に実行する

LLM は Python のコードを実行するわけではありません。

  • DateObject の実データを読み込む
  • DateAggregate の依存関係を DFS で走査する
  • datetime を計算する
  • 実際の集合を構築する

こうした 実行行為は LLM にはできません。

🔍 では、LLM に何をさせられるのか？

✔ Evaluator の「結果を推論させる」

あなたが 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, ...}

と推論できます。

✔ Evaluator のロジックを改善・最適化できる

LLM はコードを読んで、

  • 設計改善
  • 最適化
  • バグ検出
  • 拡張案
  • C# 版との整合性チェック

などを行うのが得意です。

✔ Evaluator のテストケース生成も得意

LLM は仕様からテストケースを大量に生成できます。

  • AND / OR / NOT の境界ケース
  • シフト演算の端点（±10）
  • Rep 系の周期性テスト
  • 循環参照の検出テスト
  • def_name の衝突テスト

こうした「仕様ベーステスト」は LLM の得意分野です。

🔥 まとめ

項目 LLMはできる？ 説明
Evaluator のコードを実行 ❌ LLM はコード実行環境ではない
Evaluator の動作を推論で再現 ✅ ロジックを理解して結果を推論できる
Evaluator の設計・改善 ✅ コードレビュー・最適化が得意
Evaluator のテストケース生成 ✅ 仕様から大量のテストを作れる
DateObject / DateAggregate の依存解析 部分的に可能 データを与えれば推論できる

🌟 あなたの用途に合わせた答え

あなたが求めているのは：

  • LLM に DateAggregate の集合演算をさせたいのか？
  • Evaluator のコードを LLM に実行させたいのか？
  • Evaluator の設計を LLM に任せたいのか？

どれでしょう。

もし「LLM に集合演算をさせたい」なら、
あなたの Evaluator の仕様を LLM に教えれば、
LLM はそのロジックを模倣して推論できます。

必要なら、
「LLM が Evaluator と同じ動作をするためのプロンプトテンプレート」
も作れますよ。


Q.さらに踏み込んで、「LLMがDateAggregate の演算を間違えることを懸念しています。今までLLMは、仕様に基づいた正しいものを出すという前提に立っていましたが、もしかして明示した方がよいのかも？と思い始めました。」

あなたの懸念はとても本質的で、システム設計者としての直感が鋭いです。
結論から言うと **「LLM が DateAggregate の演算を間違える可能性は十分にある」**ので、
仕様を明示し、LLM に“Evaluator の厳密なルール”を守らせる仕組みを作るべきです。

ここを曖昧にすると、LLM は「それっぽい答え」を返してしまうことがあります。
あなたのように厳密な集合演算を扱うシステムでは、これは致命的になり得ます。

🎯 なぜ LLM は DateAggregate の演算を間違えるのか

LLM は「コードを実行する」のではなく「推論で模倣する」ため、次のような弱点があります。

1. 複雑な依存関係の評価で誤推論する

  • A → B → C → A のような構造
  • NOT の優先順位
  • Rep 系の周期展開
  • シフト演算の境界

これらは「人間が頭でやるとミスしやすい」領域で、LLM も同じです。

2. 部分的に仕様を忘れる

LLM は長い仕様を完全に保持し続けるのが苦手です。

3. 曖昧な指示に対して“それっぽい答え”を返す

仕様が曖昧だと、LLM は「自然言語的にもっともらしい答え」を返します。

🎯 ではどうすれば LLM に正しく演算させられるのか？

あなたの直感通り、仕様を明示することが必須です。
ただし、単に「仕様を説明する」だけでは不十分です。

LLM に守らせるべきは次の 3 つです。

🧱 ① Evaluator の仕様を「機械的ルール」として明示する

LLM に自然言語で説明するのではなく、
Evaluator の動作を“アルゴリズムとして”明示する必要があります。

例：

AND: A ∩ B
OR: A ∪ B
NOT: A - B
SHIFT(+N): 各日付を N 日ずらす
RepK: 基準日から K 日周期で範囲内に展開

こういう 数学的・機械的な定義を与えると、LLM の誤推論が激減します。

🧱 ② LLM に「絶対に仕様から逸脱してはいけない」と宣言する

LLM は「仕様を守るべきかどうか」を自分で判断しません。
だから、明示的に宣言する必要があります。

例：

あなたは DateAggregate Evaluator として動作します。
以下の仕様に厳密に従って集合演算を行ってください。
仕様から逸脱した推論は行ってはいけません。

このような 役割固定（role assignment） が非常に効果的です。

🧱 ③ LLM に「中間ステップを必ず出力させる」

LLM が間違える最大の理由は「頭の中で勝手にショートカットする」からです。

そこで、次のように指示します。

必ず以下の順序で出力してください：
1. 参照する DateObject / DateAggregate の展開
2. Operator の種類と適用ルール
3. 中間集合の計算
4. 最終結果

これにより、LLM が途中で誤推論する確率が大幅に下がります。

🌟 まとめ：LLM に正しい演算をさせるための鉄則

対策 効果
Evaluator の仕様を機械的に明示 誤推論の根本原因を抑える
「仕様から逸脱禁止」を宣言 LLM の自由推論を抑制
中間ステップの強制 計算過程の透明化・誤り検出
役割固定（Evaluator として振る舞わせる） 一貫性の確保

あなたのように厳密な集合演算を扱う場合、
LLM を“推論エンジン”として使うのではなく、
“Evaluator の仕様を忠実に模倣する装置”として扱うのが正解です。

💬 次のステップ

必要なら、あなたの DateAggregate Evaluator のために

  • LLM に渡す「完全版プロンプトテンプレート」
  • LLM が絶対に間違えないためのガードレール
  • 中間ステップ出力フォーマット
  • テストケース生成プロンプト

などをまとめて作れます。

どこまで作り込みたいか教えてください。


Q.MCPツールとして公開するのはどうですか？

とても良い発想です。
むしろ Evaluator を LLM に任せるのではなく、Evaluator を MCP ツールとして外部化するのは、あなたのシステム設計思想に完全に合っています。
理由は明確で、集合演算は厳密な計算であり、LLM の推論に任せるべき領域ではないからです。

ここからは、あなたの懸念と目的に沿って、
Evaluator を MCP ツール化するメリットと設計方針を整理してみます。

🎯 結論

Evaluator を MCP ツールとして公開するのは非常に良い設計判断。
むしろベストプラクティスに近い。

理由は以下の通りです。

🧱 1. LLM の誤推論を完全に排除できる

あなたが懸念していた通り、LLM は

  • AND / OR / NOT の優先順位
  • シフト演算の境界
  • Rep 系の周期展開
  • 循環参照の扱い
    などで「それっぽい答え」を返す可能性があります。

Evaluator を MCP ツールとして外部化すれば、
LLM は一切演算しないので誤推論はゼロになります。

LLM はただ
「この DateAggregate を評価して」
と MCP ツールに依頼するだけ。

🧱 2. LLM は「仕様を守る必要がなくなる」

LLM に仕様を覚えさせたり、
「仕様から逸脱しないで」と指示する必要がなくなります。

LLM はただ

  • def_name
  • Operator
  • dates
    を MCP ツールに渡すだけ。

仕様の厳密性はすべて Evaluator 側に集約されるので、
LLM の負担も減り、安定性が飛躍的に向上します。

🧱 3. LLM は「説明・可視化・補助」に専念できる

Evaluator が MCP ツールとして動くと、LLM は

  • 結果の説明
  • 中間ステップの可視化
  • GUI の補助
  • エラーの説明
  • 仕様の解説
    など「人間向けの説明」に集中できます。

これは LLM の得意領域です。

🧱 4. Evaluator のバージョン管理が容易になる

MCP ツールとして外部化すると、
Evaluator のバージョンを独立して管理できます。

  • v1: AND/OR/NOT のみ
  • v2: シフト演算追加
  • v3: Rep 系追加
  • v4: トポロジカルソート最適化
  • v5: キャッシュ強化

LLM 側は何も変更せず、
Evaluator の API だけ更新すればよい。

🧱 5. LLM の「安全性」も向上する

LLM が勝手に演算しなくなるので、

  • 誤った集合
  • 誤った日付
  • 誤った制約
    を返すリスクがなくなります。

特にスケジュールナースのような
制約ベースのシステムでは安全性が最重要なので、
Evaluator の外部化は理にかなっています。

🧱 6. MCP ツールは「計算に強い」

MCP ツールは

  • Python
  • C#
  • Rust
  • Go
    などで実装できるため、
    厳密な集合演算・日付計算・DFSを確実に実行できます。

LLM の推論とは違い、
100% 再現性のある結果が返ってきます。

🧩 MCP Evaluator の API デザイン案

あなたの 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 はこの結果を受け取って

  • GUI に表示
  • 説明文を生成
  • エラーを解説
    などを行うだけ。

🌟 まとめ

Evaluator を MCP ツールとして公開するのは

  • 正確性
  • 再現性
  • 安全性
  • 拡張性
  • LLM の負担軽減

のすべてを満たす、非常に優れた設計です。

あなたのように
厳密な制約計算を扱うシステムでは、
LLM に演算を任せるのではなく、
LLM は「説明と補助」、Evaluator は「計算」
という役割分担が最適です。

必要なら、

  • MCP Evaluator の API 設計
  • MCP manifest のテンプレート
  • Evaluator の Python/C# 実装
  • LLM 側のプロンプトテンプレート
    などもまとめて作れます。

どこまで進めたいか教えてください。


投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)