7. 暗黙の制約条件#
7.1. 説明#
「暗黙の制約条件」もしくは「隠れた制約条件」とよばれる制約条件がある． これは問題担当者が最初定式化した段階であったり，問題を一通り整理し終えたとしても， 実は要件定義として欠かせない制約条件が思いかけず認知されていなかった場合に， 当該制約条件をそのように呼称するものである．
暗黙の制約条件をすべて洗い出し，これらをどこまで定式化に含められるかを検討することが，実務では頻出する課題となる．
7.1.1. 暗黙の制約条件の洗い出し#
数理最適化モデルによる問題解決はルールベースの問題解決手法である． このため一度定式化されたモデルを求解して，最適解もしくは実行可能解が得られれば， その解は考える制約条件をすべて満たしている．
この結果を見て悪い意味で機械らしい解が出された場合には， どこがおかしいのか，ということを考えることで暗黙の制約条件を見つけ出すことができる．
ここで重要なのは以下の二点となる．
テストデータとしては可能な限り，本番運用を想定したテストデータを用いる．
テストデータに対して期待するもしくは想定される結果が用意されている．
個々の制約条件が満たされているかどうかの，機能としてテストデータもシステム化の検証のためには， 重要なテストデータではあるものの，いざ，本番運用検証となった際に違和感のない解が得られるとは限らない． しかしテストデータが実運用に近ければ近いほど，計算結果は現実の制約条件との差異の検証ができる． そして 解の安定性 と併せて，一つのテストデータでも複数回計算することで得られる結果の検証もまた，暗黙の制約条件の洗い出しに繋がる．
7.1.2. テストデータの重要性#
暗黙の制約条件の洗い出しからわかることは， テストデータが整っていないもしくは準備できていない，といった状況が生じていると， それだけ暗黙の制約条件の洗い出しが遅れることに繋がりやすいということである．
数理最適化モデルはモデルとデータを分離して構築できるが， システム化という観点では，この分離はモデルが暗黙の制約条件がなく完全であることを暗に仮定している．
それ故に，もしデータが揃わないか，整理がよくなされていない場合には， モデルの求解品質も同程度になりがちである．
7.1.3. 暗黙の制約条件の特徴#
暗黙の制約条件を早期発見するために， これら制約条件としては以下の特徴を持っているとまずは考えてみるとよい．
暗黙の上下限
予期せぬ組み合わせ
保存則を破る要件
未考慮の自由度
定式化のために用いた用語と実際の用語の定義の不一致
何れも当事者にとっては「当然のこと」として意識にも上らないことというのが共通している．
7.1.3.1. 暗黙の上下限#
数理最適化モデルを構築する上で，数量の上下限を与える制約条件は自明な最適化が行われないために必須である．
例えば「山での遭難リスクを最小化する」という問題があったとして， この場合に考えうる自明な最適解とは「登山しないこと」である．
これは確かにその通りであり，間違っていないだろう． しかしそういうことを解きたいわけではないはずだ．
「何処かの景色を必ず見たい」とか「何某かの山菜を必ず採取したい」など，登山を前提とした制約条件があるはずで， それが登山者数についての下限制約として機能するはずである．
上記の例は一般常識を照らし合わせれば，自ずと気付くことかもしれない． しかしこのような話題が個々の業務知識の上に成り立つ事柄の最適化問題を考える場合には， 途端に自明ではなくなる．
定式化を行う者がそれら業務知識に長けていない場合に，この種の暗黙の制約条件に気付くには， (制約条件を満たす範囲で) すべて の変数が (例えば) \(0\) をとるなどの極端な場合を考えてみることである． 感覚的な話となるが，ちょうど数学の定理などで反例を探すのに似ている．
7.1.3.2. 予期せぬ組み合わせ#
「解の不安定性と付き合うには」でも述べたが，人は違和感があるパターンには敏感だが， 何をもって違和感とするか，明文化することは中々に難しい．
最適化計算で得られた解が制約条件をすべて満たしていても， どこか奇妙に見えることがある．
このような場合には不自然とみなせる共通点を探して制約条件として落とし込むことをまずは考える． ここで上手く違和感を抑え込めればよいが，制約条件が膨れ上がる場合や， 上手く落とし込んだとしても，計算時間が現実的でない場合には， 一度，異なる解決手段を案ずるのも一つである．
そのような解決手段としては，そもそも許容範囲内のパターン集合を生成することを基礎におく列生成法や， 数理最適化モデルから離れて，シミュレーションモデルとして再定式化するか， そのシミュレーションモデルを基にパターンの評価値を算定するなどして目的関数値に組み込むなどである．
7.1.3.3. 保存則を破る要件#
水の流れが途中で枝分かれしても，総量でみれば不変であるようなたとえで，問題を定式化できることがある． このような場合にはその定式化では保存則が成立しているなどと，ここでは述べることにしよう．
保存則は途中で物が消えたり増えたりしないことを述べており， 経済活動で収支を揃えようとする事柄について広く共通して有する性質である．
このためもしある定式化で，保存則の成立が期待できる問題であるにもかかわらず， どうも収支が合いそうにない問題設定になっていれば，どこかで要件を拾い忘れている可能性がある． もしくは何かしらの線形近似によって意図的に破っている場合もあり，その場合にはモデルの正当性に対する説明が必要となる．
この他，本要因は自由度が足りないために，保存則を破ってしまっているというようなこともあり， 次に述べる「未考慮の自由度」の特殊な例だともみなせる．
7.1.3.4. 未考慮の自由度#
主に定式化した問題変数の添字自由度が実は足りていなかった場合である． 一方で問題を簡単化するあまり，意図的に無視する自由度もあり，匙加減が難しい．
改善のために添字の数が新たに増えることになるので，修正コストが大きい． 予めその自由度を予見して，一般的なモデルを書くことが対策となるが， 一般化が正しい一般化かどうかは本当に必要になってみないとわからないという厄介さもある．
テストデータが実運用を前提として整理されていればいるほど，どこまで一般化すればよいかが推定できるので， テストデータの精度を上げることが，まずは対策に繋がるといえる．
7.1.3.5. 定式化のために用いた用語と実際の用語の定義の不一致#
数理最適化に限った話ではないが，記述したい対象に何らか抽象的な構造を見出すことはよくあることである． 例えばグラフ構造は最短経路問題に代表される様々な問題の抽象的な構造である． そうやって問題を整理していく中で，具象的な用語が次第に抽象的な構造を基礎に様々に翻訳される．
このようにして定式化を行う者の頭の中では，モデルとの意思疎通の橋渡しができるようになり， 現実に話される会話を必要に応じて補完して，実務要件を消化できるようになる．
しかしここで話者が必ずしも抽象的な構造を意識して，もしくは前提として話しているとは限らない． 例えば抽象的な構造としてリスト構造を想定する場合に，会話の中で「先頭の要素」という言葉があったとすれば， それはリストの最初の要素をモデル作成者は想像するところだが， 実際には「(条件 \(X\) の下で) 先頭の要素 (であり，条件 \(Y\) の場合には次点の要素が先頭の要素)」というようなことがあり得る． 括弧書きの部分はわかりきったことであり，それ故に暗黙に仮定されるのである．