6. 解の安定性#
6.1. 説明#
実行可能解 はもとより，制約条件を満たす 最適解 が唯一つとは限らない． この事実はよく知られた事実であるが，一方で計算機を回す諸々の実行条件に変化がなければ， 求解結果もまた同じだと期待することがある． つまり解の一意性が一般に成り立たないことはそれほど非自明なことではないものの， 得られる解には変化がないと期待する．
しかしこの素朴な期待はそれほど自明なものでなく， 様々な要因によって成り立たなくなってしまう．
このように何かしらの要因によって，解に変化が表れるかを取り扱うことを「解の安定性」を議論するという．
注釈
解の不安定性は解自身が決定論的でないという以外にも，計算時間の不安定性も同時に意味する． ある計算で \(T\) 秒要した場合に，決定論的な計算であれば，再度計算した際に要する時間 \(T^{\prime}\) は \(T\) とそう違わない． しかし非決定論的な場合には体感できるほどの違いが生じる場合があるため，システム設計時にはこの点も考慮または認識しておく必要がある．
解に変化が表れる程度や要因が少ないほど，その求解動作の解は「安定である」と表現するが， 解が安定であれば，利用者としては決定論的に計算を扱えるので，都合が良い場面が多く，歓迎される性質である．
この安定性を破る要因としては以下のような場合が想定され， 定式化を行う実装者は解の安定性を可能な限り高めることがしばしば要求される． もしくは解が不安定になった際にどこに原因があるか特定することが時として必要になる．
並列処理
定式化記述順序
バージョンアップ，コンパイラの変更などの処理系の変更
これら要因について以下でそれぞれ言及する．
Tip
もし解の安定性が破れていて，どの辺りで破れていたかを知りたい場合には，求解の進捗ログを見るとよい． 途中で得られている 実行可能解 の目的関数値の違いを見るなどして， 具体的に解の安定性が破れていることを確認できるからである．
6.1.1. 並列処理#
並列処理は非決定論的な計算の代表的な要因であり，以下の点に気を付けるとよい．
求解アルゴリズムそれ自体が並列処理を必須としているか．
求解アルゴリズムは決定論的な計算が基本だが，オプションの指定によって並列処理を追加しているか．
6.1.2. 定式化記述順序#
次の \(2\) つの記述があったとしよう．
これらは明らかに等価な記述である． しかしもっと複雑な場合では，たとえ決定論的な計算をしている場合でも，これと同様にただ単に順序が違うだけで計算機の結果が変化しえる．
ここで順序が異なると SIMPLE では集合の要素が異なる可能性があるが，その可能性もない場合でも変化しえる． 定式化対象の如何によっては結果の微妙な差異に説明が要求されるか，もしくは再現性が要求される場合がある． ちょっとした修正が思いがけない事態を招きかねない．
注釈
抽象的な意味では式の順序に意味はなく，同じ定式化を意味する． これと同様に得られる最適解もまた唯一性が保証されていなければ， 制約条件を満たす限りはどの最適解が選択されてもよい．
計算機を用いた数理最適化モデルの表現もまたこれに従うため， 式の順序のような抽象的には意味が変わらない違いであっても， 各々のコンポーネントの実装の処理の違いが複雑に関係しあって，異なる最適解を求解しえる．
ただこれら要求が「解が許容されないこと」を意味するのならば，「暗黙の制約条件」が顕在化したことを意味するので， 好意的に捉える(余裕があれば) 機会とも解釈できる．
6.1.3. バージョンアップ，コンパイラの変更などの処理系の変更#
\(1\) つの最適化計算を完遂するために，背後では様々なコンポーネントがお互いに整合性を保って機能している． ソフトウェアのバージョンアップや，抽象的に記述されたモデリング言語の計算機上への解釈を担う様々な処理系が変更されることによって， 求解結果が異なるようになるのは，それほど驚くべきことでもなく，また同時に避けられない現象である．
またハードウェアの性能を変化させることで，所定の計算資源で処理できる分量にも差が生じ得るため， このような広義の意味でも解は不安定だといえる．
注釈
計算資源と解の安定性と関連して，最適解が唯一であっても計算資源の違いで，最適解まで至らずに他の 求解状態 となる不安定性についても広義にはあり得る． このため解の安定性と関連して，最適化計算結果がどのような 求解状態 であるかは，解を受け取る上位側が何らかの形で知っておく必要があり，そのようなシステム設計が標準的には要求される．
以上を要因とする解の不安定性は，たとえアルゴリズムが決定論的であっても，生じる類いのものであり， 解の安定性の完全な解決のためには，それらコンポーネントをすべて固定させる必要があることを物語っている．
一方でソフトウェアやハードウェアは日々性能改善が図られており， これら改善の恩恵に与ることを考えれば，この種の解の不安定性が問題になった場合でも，これを解決することには価値があるといえる．
6.1.4. 解の不安定性と付き合うには#
解が不安定になったとしても，制約条件を満たし，尚且つ 最適解 または許容範囲内の 実行可能解 が得られていることには変わりない． 単純に異なる別の解が得られただけである． このためもし解が不安定になった場合に，その状況が不都合であるならば， 「暗黙の制約条件」が顕在化した可能性が高い．
というのも実務問題を定式化するのに始めから完全な要件仕様があることをいつも期待できない． もしくは可能な限り必要十分な要件定義を目指すものだが，漏れが絶対にないとは言い切れない． もう少し追記すれば，漏れを絶対に許さない定式化が良い定式化とも限らない． 運用によって解決することが望ましい要件もある．
こういった定式化の背景を考えると，解の安定性が問題となるのは， 何かしらの望ましくないパターンが言語化できていない，もしくは難しいことが一つ要因として挙げられる．
例えば献立を例にとろう．
与えられた食材の組み合わせで料理ができるとし， 栄養価や調理時間それに食材の購入費用上限などを目的関数や制約条件として採用したとしよう．
仮にこの献立の最適化問題を定式化できて，一応の解が得られたとしても， 出力される献立に違和感を覚えることがないとは言い切れない．
何となく「ラーメン」「餃子」「チャーハン」というような非日常でない献立を期待するところだが， 「ラーメン」「蕎麦」「うどん」という献立が出力されたらどうだろうか． たとえ制約条件を満たし，設定した目的関数が最適だったとしても， 果たして多くの人々がこの求解結果に満足するだろうか．難しいだろう．
ではどのような料理のパターンであればよいだろうか． これを個々人に応じて言語化するのは難しいであろうし， できたとしても制約条件のメンテナンスコストはかなりのものになりそうである．
以上のようにパターンというものに何かしら制限があるか，非線形な関係がありそうである． 標語的に言えば「(美味しい) \(+\) (美味しい) \(=\) (もっと美味しい)」という線形な関係は成り立たないのである．
こういった問題に対しては，予め想定できるパターンの組み合わせを用意または生成して，その中から最適なものを選択するような定式化であったり， そもそも最適化問題以前に立ち返って，要素間の関係を上手く落とし込むためのデータ分析が必要になろう．
上記の考察は一例に過ぎないが，解の安定性が問題になる場合には， 何かしら問題への理解を深める機会を提供していると考えると良いだろう．