人気ブログランキング | 話題のタグを見る

AIで設計を自動化できるか? (2) 〜「良い設計」の条件を考える

前回の記事「設計とはどういう行為か、AIで設計を自動化できるか?」 でも書いたとおり、設計とは『機能を形状・構造に落としこむ』(そして必要な場合は制御機構も与える)行為である。だから、設計は典型的な逆問題になる。逆問題とは、アウトプット(結果)から、インプットやプロセス(入力・過程)を逆算する問題だ。一般的には、一意に解けない。だからこそ、設計者のスキルやセンスの活躍する領域がでてくる。

設計者に、スキルの高低とかセンスの良しあしがあることを、否定するエンジニアは少ないだろう。毎回、画一的な答えを出すだけなら、ロボットでも代替できる。だが、設計者はロボットではないはずだ。では、設計者という人間のスキルやセンスとは、何を指すのか。

当たり前だが、それは、「良い設計」を作れる能力を意味している。誰が見ても、「うーむ、良い設計だ」と感心する出来栄えのアウトプットを、ある程度コンスタントに生み出せる能力。そういう人は、スキルが高い、センスが良い、と言えよう。

では、「良い設計」とは、何なのか? 

良しあしを言うからには、そこに、何らかの評価尺度と基準があるはずである。前回の記事では、機能・構造・制御の3要素に関連して、3つの評価項目を取り上げた。

(1) 有用性:有用でないモノは、作るに値しない。有用性とは「機能」が生み出すもので、設計対象の性質やふるまいのうち、使用者の期待に合致する(あるいは他の機能を助ける)部分を指す。若干ニュアンスはかわるが、「機能性」と呼んでも良い。

(2) 存続性:ちゃんと存続しないモノ(作っても瞬時に壊れるような物)は、使えない。存続性は、「構造・形状」(と材質)が、保証する。力学的安定性ともいう。ただしソフトウェアのような無体物は、構造的単純性(スパゲッティ状態でないこと)で置き換えて、解釈すべきだろう。

(3) 操作性:使用者の意思に沿って動かないモノは、使えない。操作性は、「制御」の機構が実現するもので、制御性といっても良い。普通はそのために、ユーザ・インタフェースが必要になる。

言いかえると、ユーザの期待を上回るような機能・性能があり、形状や構造は単純ながら堅牢安定で、かつユーザの意のままに動かせるようなモノを作れたら、良い設計だという事になる。

しかし、評価基準はこれだけか? そんなことはない。

まず、真っ先に設計者の脳裏に浮かぶのは、『コスト』であろう。コストが優先、コストは安いほうが良い。これは多くのエンジニアに刻み込まれた価値観だ(とくに日本では)。もちろん、正確に言うと、「同じ性能や品質が実現できるならば、コストは安いほうが良い」である。コストダウンで性能や品質が犠牲になっては、本末転倒だ(だが、しばしば設計者が、「コストダウン優先」という『転倒』を、要求されたりするのが見受けられるが)。

その「コスト」はさらに、設計作業それ自体の人件費、材料部品の購入費、そして製造や検査の労務費、機械設備の減価償却費や光熱費、などから構成される。このうち、最後の製造間接費は普通、企業の製造部門が固定費として担うので、設計部門の責任範囲外だ。しかし設計人件費・材料費・労務費のどこまでが、設計部門の「コスト」の対象になるかは、その企業の組織ポリシー次第でかわる。

だから、ある者は、たとえ材料費が少し増えても、製造の手間が下がれば、全体コストが下がるから「良い設計」と思い、別の者は、材料費さえ下がれば、製造が面倒になっても「良い設計」だと考える(労務費は設計者の責任範囲外の場合)、といった現象がおきる。もちろん、設計作業の人件費しか見ない者もあるだろう(製造を外部企業に委託している場合など)。このように、何が良い設計なのかは、その会社の経営のモノサシにかなり依存するのだ。

さて、同じ性能や品質が実現できるなら、コストは安いほうが良い、と上に書いたが、では「性能」や「品質」は、どんな評価尺度なのか? とくに設計が実現すべき『品質』とは何なのか。まさか、製造品質のことではあるまい(さすがに普通それは製造部門の責任だ)。では、設計図や仕様書に誤りがないこと? 誤字や転記ミスがなければ、「良い設計」になるのか? それって最低限、守るべきことではないか。

設計における品質の問題とは、ユーザの要件や無意識的期待への合致、で測られるべきであることを思い出そう。そこで、よくITの分野で行うように、「機能要件」と「非機能要件」という角度からとらえなおすほうが、分かりやすい。

 性能=機能要件に属する特性
 品質=非機能要件で決まる特性

たとえば自動車でいえば、『移動』という主要な機能目的に直接付随する特性、つまり走行距離、最高速度、可載重量、馬力、加速性、燃費、回転半径などが、性能の範囲だ。逆に、高速安定性だとか剛性だとか衝突安全性、そして空間の広さや居住性、運転のしやすさといった非機能要件が、品質と関係する。良い設計というのは、機能要求を満たしつつ、非機能要件も適度に満足させるバランス感にある。

つまり、設計とは、与えられた制約条件の中で、複数の評価尺度を、なるべく最大化するような設計変数の組を見つける作業である、ととらえることができる。ORの分野の用語でいいかえると、設計とは多目的最適化問題なのである。

そして、複数の評価尺度の間には、しばしば、「あちらを立てればこちらが立たず」というトレードオフの関係が生じる。自動車の例を続けると、走行距離を伸ばすには燃料タンクを大きくすることになる。だが、そうすると車体重量がまして、燃費や加速性が犠牲になる。加速性を上げるためにエンジンの馬力を上げると、今度は燃費が下がる、じゃあ車体を軽量化しようとすると、高速安定性が損なわれるし材料コストが上がる、といった具合だ。

AI(機械学習)の分野には、「ノー・フリー・ランチ定理」と呼ばれる定理がある。すべての最適化問題に対して、最強の性能となるようなアルゴリズムは存在しない、という定理だ。魔法の「銀の弾丸」はない、といってもいい。設計で突き当たるトレードオフの問題は、この定理を思い出させる。どこかを強めると、どこかが弱くなるのだ。

そこで、評価尺度の間にトレードオフが生じるとき、どの項目を優先して、どこは犠牲にすべきかを決める、より高いレベルの指針が必要になる。これを『設計思想』Design phylosophyと呼ぶ。良い設計とは、すなわち設計思想の明確な仕事である。ジョブズの生みだしたiPhoneは、たしかに設計思想の明確な製品だった。逆に設計思想の薄弱な、八方美人的な製品は、個性が薄く人を引きつける力が弱くなる。

もっとも、自動車や携帯電話のような複雑なシステム製品の設計となると、それ自体が設計変数の多い大規模な問題で(部品点数だけでも相当になる)、評価尺度の項目も多く、非常に難しい。これに比べて、前回取り上げた、椅子の設計だったら、形状も構造もずっと単純だ。設計変数も、ずっと少ない。座面の高さや耐荷重量、脚の本数などの主要な設計パラメータは、たぶん所与で決まっているだろう。

そのような場合、主に問題となるのは、形状と材質を与えたとき、所定の力学的強度を満たすかどうか、のチェックであろう。これなら単純なシミュレーション計算(場合によっては手計算)で確認することができる。さらにキャスターなどの制御機構を考え、総重量を求め、部品表とコストを計算し・・という具合に、設計作業は順次、進んでいく。こういう仕事ならば、手順書を作って、スキルの低い設計者や外部に委託することも可能になる。

いや、もっと単純な設計作業だって、無いわけではない。それは、あらかじめ決まっている選択肢の中から、要求仕様に基づいて、条件に合致する物を選ぶような作業である。わたしの職場では、よくこうした仕事を「カタログ・エンジニア」とよんだりする。分厚いカタログの中から、適切な製品や部品を選んで、その特性を仕様書に転記するだけの作業だからだ。

このように考えると、設計という仕事には、カタログから選ぶだけの単純な作業から、複雑なシステム製品の内部構造と制御機構を実現する仕事まで、大きく4つくらいのレベルがあることが分かる。それは、考えるべき設計変数の数と、評価尺度の複雑性に応じて、図のようにマッピングすることができよう。
AIで設計を自動化できるか? (2) 〜「良い設計」の条件を考える_e0058447_08224645.jpg
つまり、設計行為には4つのレベルがあると考えられる

1. 選択的決定:いわゆるカタログ・エンジニア
2. 演繹的決定:設計計算で主要な設計変数を逐次導出する
3. 最適化決定:評価関数を最大化する設計変数の組を探索する
4. システム合成:多軸的な評価関数をバランスよく満たすような構造と制御機構を合成する

当然ながら、この順番で設計は難しくなる。ただ、4の「システム合成」の高度な大仕事も、その中のプロセスを細かく分解してみると、部分的機能モジュールの最適化決定や演繹的決定、あるいは単純な部品の選択的決定、などが含まれているのが分かるだろう。そして設計チームの中で、スキルに応じて、そうした作業が振り分けられていくはずである。

このように考えると、AIで設計を自動化できるか、という問いに、さらに一歩近づいた訳である。その答えについては、次回の記事で考えてみよう。


<関連エントリ>
 →
(2019-09-22)



by Tomoichi_Sato | 2020-05-15 12:18 | 考えるヒント | Comments(0)
<< AIで設計は自動化できるか(3... 設計とはどういう行為か、AIで... >>