10＋1 website｜テンプラスワン・ウェブサイト

3. 目的関数をどのように設定すべきか

3.1. スキー場のリフト問題、トイレの配置問題

本間──ここまでは、主に目的関数がビジビリティの場合の事例をお話ししてきました。でも最大化あるいは最小化するべき目的関数をどのように設定すべきかは、結構難しい問題なんです。2つの例をあげてお話しします。

1つめの例は、スキー場のリフト問題です［fig.3-1］。市川さんの美しいプレゼンからの落差がはげしいスライドですね（笑）。東京工業大学の青木義次先生が考案した問題です。スキー場のオーナーが、リフトの待ち行列を改善したいと思っている。輸送力の異なる2つの新しいリフトのうち、A案とB案のどちらを導入すべきか。

fig.3-1──スキー場のリフト問題［参考＝青木義次「最適化から建築の計画・設計を眺める」『日本オペレーションズ・リサーチ』46号（日本オペレーションズ・リサーチ学会、2001）

輸送力の高いA案のほうがいい案のように見えますよね。ところが、目的関数を「待ち行列の長さ」として、それを最小化するべく計算すると、じつは輸送力の低いB案がいいということになってしまいます。なぜならスキー場は閉じた系なので、ゆっくり運んだほうがリフトに乗っている時間が長くなり、結果的に行列の長さが短くなるからです。これは、スキー客としてはつまらないですよね。ですから、「待ち行列の長さを最小化する」のではなく「滑り時間を最大化する」べきなのです。そうすると晴れてA案が正解になります。「こんな単純な間違いしないよ」と思われるかもしれませんが、問題をちょっと複雑にすると、こういう間違いはよく起こります。このように目的関数を正しく設定するのは難しいので、冷静に考える必要があるんです。

もうひとつの例は、建物内にトイレをどこにいくつ設置すべきかという問題です。トイレを例にとっていますが、トイレ以外の部屋の計画にも適用できるロジックです。僕が関わった大学の実験施設を例にお話しします。東大の生産技術研究所の今井研にて、5年ほど設計監理した建物です（今井公太郎＋本間健太郎＋矢野寿洋《東京大学生産技術研究所 千葉実験所 研究実験棟Ⅰ》（2016））。今井研には、設計実務と数理研究の両輪をそれぞれ本気でやるというカルチャーがあって、僕はそれに影響を受けています。

図に、便器の数と位置を描いています［fig.3-2］。実際に設計するときには、いろいろな締め切りに追われていたので、この位置と数は経験的に決めました。ですが、あとから振り返ってみて、数理モデルを使ってもっと合理的に決められたなと気づきました。

fig.3-2──トイレを「どこに」「いくつ」配置すべきか［画像をクリックして拡大］

便器の適正な数については、「規模計画」の分野で盛んに研究されてきました。規模計画は建築計画学の王道です。昔から研究されているので、今ではトイレの製品カタログには、利用人数に応じた適切な器具数がグラフになって載っていて、簡単に調べられます。便器の数だけでなく、エレベータや銀行窓口の数なども、同じ考えに基づいて決まっています。では、それらの数を算定するベースにある目的関数は何か。それはトイレでの「待ち時間」です。ささきほどのリフト問題と同じように、待ち時間を最小化するための、正確に言うと待ち時間を一定以下に抑えるための、器具数を計算するのです☆21。

☆21──［豊田］実際には、ここに施設の利用形態や時間集中度の偏向、利用者の男女比、トイレの配管効率、構造スパンなどいろいろな要素が複合的に絡んでくる。現実世界はほんとに面白い。

でも、カタログの算定表は、あくまで便器の総数を教えてくれるだけで、空間の概念をもっていません。だからトイレを複数つくるときには困ったことになります。なぜなら、便器の総数がわかっても、小さなトイレを分散配置すべきか、あるいは大きなトイレを集約的につくるべきかわからないからです。この建物は実験施設なので、8,500m²となかなか大きいですが、一般的なオフィスに比べて人口密度がとても低い。ですので配置の問題が前景化してしまいます。

そこで単純なアイデアです。最初の都市の話で、施設配置のキーは移動距離だったことを思い出します。最小化するべき目的関数として、トイレでの「待ち時間」だけでなく、トイレまでの「移動時間」も足し合わせたものを使います。いずれも時間なので、単位がそろっているため、本来異なる2つの現象を足すことができる。これがポイントです。この「待ち時間」は便器の数によって、「移動時間」はトイレの配置によって定まります。だから、この合計を目的関数にすれば、数と配置を同時に最適化できるのです［fig.3-3］。

fig.3-3──最適な規模と配置（待ち時間と移動時間だけを考慮した場合）［画像をクリックして拡大］

ここから先は数学と計算の話です。具体的には、待ち行列理論と最適配置理論を掛け合わせて解くことができます。例えば「60m間隔で4ブースずつ配置する」のが最適だという答えが出てきます。そして、先ほどの話と同じく、モデルにパラメータを組み込むこともできます。パラメータを動かすことで、例えば移動が難しい高齢者が施設に多い場合は、「40m間隔で3ブース配置する」のが最適だという結果が出てくるわけです。

普段、面積表ってよく使いますよね。面積表は、設計を進ませるし、逆に設計を縛ることもできる。その意味で「建築計画学の一番の武器が面積表」というのは明治大学の門脇耕三さんが言っていたことです。今の面積表は、例えばトイレの数を総量として示しています。そうではなく、「何mおきに何ブース配置すべきか」がわかるような、配置則も加えたネットワーク状の面積表のようなものがありうるかもしれない。それがあれば、設計の初期段階で設計者が参照すべき情報になると思います［fig.3-4］。

fig.3-4──配置則も加えた「面積表」

3.2. レイアウトの最適化の3つの例

こうした最適化の研究は、建築とか都市の分野だけではなく、最適化を目的とする学会や、コンピューターグラフィックスの学会でも研究されています。レイアウトの最適化に関する3つの例をご紹介します。

例えば、無駄なスペースや冷暖房の負荷を最小化する研究があります［fig.3-5］。この背後にあるのは、目的関数を最小化する発見的最適化の考え方です。デザイナーによるスケッチを初期案として、あるアルゴリズムによって、できるだけ開口部を小さくしたり、部屋を正方形に近づけていきます。これによって、発見的な解として結果が出てくるというわけです。

fig.3-5──レイアウトの最適化の例1（無駄なスペースとエネルギー負荷の最小化）［参照・引用出典＝J Michalek, et al.: Architectural layout design optimization, Engineering optimization 34 (5), 461-484 (2002)］

もうひとつは、ショッピングモール内のレイアウトの例です［fig.3-6］。現実のレイアウトに群衆のシミュレーションを走らせて、それに基づいて最適化しています。その背後にあるのは、最小化ではなく最大化の考え方です。モビリティ（通路ができるだけ混雑していない）、アクセシビリティ（出発地と目的地の間のルートが短い）、快適性（部屋がちょうどいい具合に混雑している）の3つを同時に最大化することで、最適な案を出すことができるというわけです

fig.3-6──レイアウトの最適化の例2（通路の非混雑度、ルートの短さ、部屋の丁度よい混雑度の最大化）［参照・引用出典＝Tian Feng, et al.: Crowd-driven mid-scale layout design. (2016)］

もうひとつは、集合住宅のボリュームスタディの例です。普通は模型を使いながら、隣棟間隔や廊下の配置など、頭を悩ませて考えます。これを簡易化できないかと考えました。図のように、18個の住戸にそれぞれ廊下と庭が付いていて、これらをできるだけいいかたちでパッキングしたい［fig.3-7］。そこで3つのルールを設けます。住戸どうしがぶつかる場合は、物理的に成り立たないのでペナルティ。庭が重なる場合はニュートラル。廊下が重なる場合は、面積効率がよくなるのでボーナスとします。これら3つの総和を目的関数とし、それを局所的に最大化します。実際に計算すると、中廊下が出てきたり、ダブルコリドーになったり、結構発見的なことがあるんですね。ただし、目的関数を定めるためには、ペナルティとボーナスをどのように重み付けて合算するかを決めないといけません。どのような重みが妥当なのかは、やってみないとわからないというのが、実際のところです☆22。

☆22──［池田］設計の試行錯誤の最中は「解」を探すというより「重み付け」そのものを探しているのだと思う。「重み付け」の違いによる解集合の傾向にパターンを見つけた時が「メタな理解」である。この「メタな理解」を、高速化した試行錯誤で支援するのがこの方法だろう。

fig.3-7──レイアウトの最適化の例3（住戸のパッキング）

今日はエンジニアド・デザインの目的関数についてお話ししました。ベースにある考えは、設計の目的をちゃんとまじめに考えているということです。ですが、意識できる目的という大枠に対して、言語で表せる目的は一部でしかない。さらに数式で表せる目的となると、ごく一部です。そのなかで現実的に計算可能な目的は、本当にごくごく一部でしかありません［fig.3-8］。

fig.3-8──デザインの「目的」

最適化系の論文を調べてみると、論文の数だけ問題があって、それとセットで必ず解法が書いてあります。つまり、きわめて多くの問題とその解法がつくられている☆23 。それらを参照しながら開発することで、設計まわりの最適化の研究と実践は今後ぐんぐん進んでいくと思います。その結果、人間だけでは考えつかないような解が出てくる予感があります。でも、それらは広い海のなかのごく一部でしかない。全体を考えていない、ということは忘れちゃいけないと思います☆24。

☆23──［堀川］個人的には、そのようにすでに検証された問題とその解法が多くあるのであれば、それらを自分の問題に応じてレコメンドしてくれるようなプラットフォームが欲しいところ。
☆24──［石澤］設計的に「大層な手法を使った」と思うと、そこが可愛く思えてしまって設計説明のバランスが崩れてしまう。手法は部分解でしかないが、それが将棋で言う「妙手」である可能性はあるとしても、本当に妙手かどうかを判断するためには、もう一歩メタな視点で考える必要がある。

新井──僕はかつて本間さんと研究室が同じで、目的関数の設定の難しさについて、夜な夜な話した思い出があります。いまのお話を聞いて思い出したのは、摂取すべき食料の最適化の話です。戦後の食料難の時代に、食べ物の総コストを最小にして、必要最低限のエネルギーを確保するために何を食べればいいのかを最適化をした結果「1日にホウレンソウを2kg食べる」という結果が導かれたという話を聞いたことがあります。明らかにおかしいですよね。食事としてホウレンソウだけを2kgも食べられるわけないので、目的関数が間違っていたわけです。

でも目的関数を設計して解いてみて、おかしいぞと思ったら、また目的関数の設計にフィードバックしというトライ＆エラーを繰り返せばいいのだと思います。最適化のプロセスは機械的、数学的にできるように見えて、実際は意外と泥臭いトライ＆エラーが必要なのだと思います。市川さんは、実際のプロジェクトのなかで、具体的にどのようなことにトライしているのでしょうか。

3.3 住宅のデザイン

市川──先ほど一点突破の話がありましたが、そのモデルを実際のデザインのなかでどうやって使うのか、どこで一点突破するのか。そういったアイデアはまだまだ必要だと思います。実際の設計でトライしたことを、住宅のプロジェクトを例にお話しします。

東北で行った、敷地が800m²ぐらいの住宅のプロジェクトです。お施主さんはセルフビルドもやりたいという方で、木造で、かつ建設時のイニシャルコストをなるべく抑えたいという希望がありました。そこで、大屋根を設けてその下に増築することを想定し、できるだけ柱を少なくすることを考えました。最初に提案した模型がこちらです［fig.3-9］。

fig.3-9──当初の提案

最小限の柱とはどんなものか。まず、木造前提の尺モジュールで水回りのコアなど、どんな構成があり得るのかをヒアリングして検討し、そこに大屋根を架けることになりました。敷地の中のどこに建てるかは、積雪の多い地域なので雪かきの問題を考慮しています。公道の部分は除雪車が来てくれるので、なるべく接道部分に近接して屋根が架かるようにしています。

赤い線で屋根、青い線がコアで、それぞれの面重心がバツ印です［fig.3-10］。屋根とコアの重心が一致していないことがわかります。そこで、構造的なバランスなどをあらかじめ担保するような形のフォーミュラにしたほうがバランスがとれ、結果的にコストも抑えられると考え、重心を一致させるような形の拘束ルールをつくりました。

この拘束ルールはかなり厳しいので、面積はコントロールできませんが、形は一意に決まっていきます［fig.3-11］。簡単な計算のように見えますが、回転させると、接道部分と屋根の形が変わるので、重心がずれてしまう。その重心が一致するまでコアの位置を再計算します。コストを考えると、屋根の投影面積のレンジは160m²前後に絞られてきます。

fig.3-10──屋根（赤い線）とコア（青い線）と、それぞれの面重心

fig.3-11──屋根の投影面積のレンジ

それから、さきほどのビジビリティのモデルを、屋根の角度を検討する日射量のシミュレーションに転用することができます☆25。線分の始点を居住部分の建物の床、終点を太陽にすることで、太陽の見える／見えないをシミュレートします。対象の敷地から見える太陽の動きを10分おきに1年間トラックし、地平線より上の部分［fig.3-12］の線分を周辺地形と建物を考慮しながらすべて衝突判定すれば、どれぐらい建物に陽が差し込むかを計量することができます。

☆25──［石澤］逆にHoneybeeは視覚問題に応用可能ということですね......。

冬は陽射しが差し込むように、夏はなるべく遮るような屋根の角度を探します。室内に受ける日射量と敷地に対する配置角度の関係は、このようなグラフになります［fig.3-13］。東北の寒い地域なので、冬に日射量がピークになる形状を基準にしたほうがいいのでは、とレコメンドしました。ですが、そうすると通りから見えやすくなってしまうので、プライバシーの問題も含め、お施主さんとやりとりをしながら屋根の形状を決めていきます。

fig.3-12──太陽の動きのトラッキング

fig.3-13──室内床に受ける日射量（縦軸）と敷地に対する配置角度（横軸）の関係［画像をクリックして拡大］

屋根はグリッド状になっていて、どこに柱を立てても接続できるようにしています。上下60mmの細い角材と、それに直交するかたちで薄いエンジニアードウッド（LVL）をプレカットしてはめるかたちです［fig.3-14］。LVL材は下側のみプレカットして60mm角材をはめ、上側は直に構造合板を打付け、その上に60mmの角材を固定します。梁材をすべて組んでから構造合板を打ち付ける場合が多いと思いますが、構造合板が間に挟まっている点はすこし珍しいかもしれません。柱の位置を決めるときは物理モデルを使います。物理エンジンを援用して、コアと壁以外で、柱のない状態だと屋根がゆがんでしまうようなシミュレータをつくりました。これを使いながら、柱をどこに置けばいいのかを検討します。スタディを重ね、6本の柱を置くことになりました☆26。施工上の条件を加味して候補を絞ると、屋根のグリッドに柱を接続できる場所は440カ所くらいになります。ところが、440本から6カ所を選ぶ組み合わせだと、9兆通りもの膨大な数になってしまうんですね。さすがこれらすべてテストするわけにはいかないので、近似的に、ヒューリスティックによさそうなところを探していきます。オーソドックスな「焼なまし法（シミュレーティド・アニーリング）」を用いて柱の位置を探索し、最も歪む部分のゆがみが一番小さく（ミニマックス）なる柱の配置を探しました。これが最終的な柱の位置です［fig.3-15］。

☆26──［豊田］こういった、いわゆる厳密な構造計算ではないが、物理エンジンなどを使ってそこそこ十分に現実的なシミュレーションベースで形態を探索するアプローチは、もっと増えていい。［石澤］構造計算も高度化されているけれど、モデル化された手法だ、ということを忘れたくない。モデルの設計が的確なら、シンプルでも方針はきちんと導ける。

fig.3-14──屋根と柱の接合方法［画像をクリックして拡大］

fig.3-15──焼なまし法による柱の配置探索の結果

でも、これではどうしても予算に収まらない。建築設計によくある話ですね。そこで、屋根のLVLの数を半分にし、プレカットも減らすようにしました。すると柱の位置も変えなければなりません。当初はグリッドの交点に接続する仕方でしたが、構造家と相談して、半分ずらすことにしました。すると柱を接続できる場所は、当初の440カ所から約230カ所に減ります。それでも1,900億通りぐらいありますので、再び焼なまし法を使って柱の位置を探しました。異なる探索プロセスが、最適配置として同じ配置に収束することを確認して、最終的にこのような柱の配置に決まりました［fig.3-16］。グリッドが違うだけで、屋根のゆがみの少ない柱の位置もかなり違ってくるんです。このほかにもいろいろなコストダウンの施策して予算内に収めました。

このように、一点突破型で解を探し、そこで問題が起きたらさらに一点突破で探して......と繰り返し試しています。ひとつがだめだとわかったら、最初から全部やり直さなきゃいけない、というのは建築設計ではリアリティがありません。問題が起こったり、立ち戻って考えなければならないときは、その都度一点突破を探していくようなやり方はどうでしょうか、というお話でした☆27 。

☆27──［石澤］デザインとエンジニアリングがひとつの人格にあるからこそ可能になる。これがアドバンテージなんだと思う。

fig.3-16──最終的な屋根のグリッドと柱の配置

本間──最後の市川さんのお話は特に面白かったですね。すごく身につまされるというか......。ある目的に最適化してクライアントさんに提示したら、別の問題を指摘されて前提が変わってしまうような例はよくあるんですね。

数字で表現して最適化されたものは全体の一部で、それ以外のファクターはたくさんあります。ですから、ともすれば「なんのために最適化をしているのか」という批判も考えられるわけです。でもそうではないんだ、ということがよくわかりました。市川さんにとっては、最適化手法は、手書きデッサンや模型といった方法と並ぶものでしかなく、絶対視していない。あくまでひとつのメソッドの結果として示して、それがいいのか悪いのかはその後に考えましょう、と☆28 。

☆28──［堀川］スピード感のあるプロトタイプの実装ができるこそ、というように感じた。［池田］この姿勢は、建築情報学を前提としたデザイナーの役割や心構えのあり方のひとつのモデルのように思う。

ただ、一度決めたことが最後にすべてひっくり返るようでは設計が成り立たないので、ある一定の範囲を定めて、そのなかで自由に泳いだり、あるプロセスの範囲で決めたことはそれ以上は戻らないと決めることがポイントです。具体的なノウハウとして、そういった取り決めが必要なのかなと思いました。

市川──構造や設備分野のエンジニアリングに対して、意匠ではどういったエンジニアリングができるのかを、私はつねに考えています。アレグザンダーの『形の合成に関するノート』（鹿島出版会、1978［原著＝1964-65］）の序章では、今日出てきたような悩みについて書かれています。建築家になってしまった以上、無自覚なデザインはできなくなってしまうとか、現代はデザインの問題が多過ぎて解決できない、とか。そういった悩みは、この準備会議第4回での角田さんの問題提起とか、今日の話に通ずるものがある。今から40年以上も前に書かれていますが、その問いや悩みに答えるには、まだまだアイデアが必要です。一点突破型ひとつをとっても、そのアイデアをデザイナーがどんどん考えていくべきじゃないかなと思っています。