原因解析系の再構築

やはり、積年の課題としてありますが、今回、基本特許技術を用いて再構築することにしました。
なお、この特許は未だどの企業にもライセンスしていません。大企業・中小企業の皆様、どうぞSC3を見てご検討ください。Reasonを得るための強力な基本特許です。

＜間違いを生む人間＞
ナーススケジューリングにおいて重要なのは、「最適解を求める」　ことだけではありません。それと同じ位重要なことがあります。それは、「解がない原因を得る」ことにあります。確かに、全てをソフト制約にすれば、「解がないことは無い」　状態になります。従って「解がない原因を得る」その事の必要がなくなります。で、それで実用的なシステムになるか？と言われれば、それでは十分ではありません。なぜなら、ルールは、間違いをしでかす人間が作るものだからです。確かに、間違いがない世界なら、原因解析は必要ありません。学術系の視点で欠けているのは、ルールそのものには誤りがない、という暗黙の前提が入ってしまっていることです。人間が、ハード制約であると信じるならば、それはハード制約であり、そうでないならソフト制約です。そして現実のシステムには、制約そのものに誤りがあるかもしれないのです。何十、何百、サブ制約を含めれば、何十万といったオーダの制約のAND集合体である制約システムは、人間には、複雑すぎ、特に開発過程においては、必ず誤りが発生します。ルール構築には、原因解析が不可欠であり、それなしには、ルール設計さえもままならないと言ってもよいでしょう。勤務表の毎月のルールの修正過程においても誤りが発生する可能性があります。つまり原因解析は、極々普通のことであり日常的な事です。
まとめると

ルールのビルドアップ　
　ルールを作るのは人間
　　人間は誤りをする存在である(誤りをしない人間はいない）
　　　　絶対であると思っていたルール(ハード制約)が衝突(Conflict)する
　　　　　　解がない　→　原因不明　→原因解析
　　　　　　


＜原因解析は、OR系AI系？＞
前に最適化のアプローチは、OR系とAI系の二つのアプローチがあることをお話ししました。
原因解析については、間違いなくAI系です。人口知能研究では、論理を推論するという歴史があり、前述の特許もその系譜の末端にあります。学術系では、あまり着目されていませんが、実用的なシステムでは、必ず原因解析は必要になります。

＜原因解析は難しい＞
解がない原因は、実は無限に存在します。多分、一つの学術論文になります。
実用的に重要なのは、間違いをしでかす人間にとって、いかに自分の間違いを正しく指摘してくれるかです。