pBM_project Beautiful Mind2024

Architectural Intelligence / Artificial Intelligence

pBM の目的は、設計者の設計行為を支援することである。
ここでの支援とは、効率化や省力化ではなく、設計の質を向上させることを指す。
「支援領域」は、設計対象の「形態」に特化している。
「質の向上」とは、「設計者が潜在的に望んでいるが、設計者自身には提示できない形態」を、「設計者の直接的な指示を得ずして提示すること」による。
この目的を叶えるコンピュータプログラムとその UI を開発することが、pBM の目的である。
（pBM の研究開発はその一部で CREST／国立研究開発法人 科学技術振興機構 JST の助成を受けた）

pBM の開発経緯は「誘導都市」（1994 年）に遡る。
「誘導都市」では、都市／建築に求められる計画上の諸機能要請を個別に解くプログラムを作成し、その集合によって要求条件を満たす都市／建築を生成することを目指した。
その後、この機能の一部を「大江戸線飯田橋駅」（2000 年／建築学会賞作品賞、等）の「WEB FRAME」で実践した。
さらにニューラルネットによる AI で対話型形態生成を行う「流れのプログラム」（未踏ソフトウエア創造事業／独立行政法人 情報処理推進機構 IPA）を開発し、「TX 柏の葉駅」（2004 年）で実施した。
また構造力学と生成プログラムの統合プログラム「形力」シリーズを開発（大崎純／京都大学と共同）し、「新水俣門」（2005 年）で実施した。
これら一連の研究開発の発展的一環として、pBM は位置づけられる。

参照
→ AItect の pBM 部

なぜ形態に特化するのか

→ それが Ai にとって最も難しい課題と思われるから

なぜ難しいのかー猿飛効果

→ ヒトの意思決定は時に飛躍するから

なぜ NN―生成系 AI を使わないのか

→ 大量の教師データを使わずに目的を達成するため

なぜ既存 CG アプリを使うのか

→ pBM の主眼が汎用性にあるから

pBM は NN（ニューラルネット）ではない。
共同研究者である東京大学の佐藤教授が開発したオリジナルの AI エンジンを用いる。この AI はベイズ的回帰モデルであるガウス過程を用いた AI である。
NN を用いた LLM による一般的な生成 AI とは異なり、pBM は大量の教師データによる事前の学習を必要としない。
ユーザーは、訓練データによりトレーニングされた AI ではなく、いわば「無の状態の AI」を相手に対話を始めることになる。
本稿はこの AI の理論を解説するものではなく、この AI を用いた設計支援プログラム＝ pBM について述べている。

このエンジンを pBM の目的に適合させるため、「AI を含む pBM プログラムの作成→ pBM の試行→課題点の認識→プログラムの改定方向の策定→プログラムの改定→再試行」を繰り返すことが、共同開発の過程であった。
開発といっても「AI プログラムと CG アプリを結びつけるだけではないか」と思われる向きもあるかもしれないが、そう単純には行かない。
「ユーザーの操作に基づいて推定値を返す」という動作ひとつでも、その「返す値」はひとつには定まらない。
AI プログラム内の複数のパラメータの選び方により、返す値は大きく変わる。
この「操作―応答」過程を繰り返すことで、値＝解は、どんな方向にも行ってしまう。

値を変動させるパラメータ値の模索／策定の他にも、結果の選択肢の設定、経緯の枝分かれの扱い、リミッターの勘案、ループへの落ち込みや期待していない収束の回避、等の AI プログラム挙動の選択、そして AI プログラムの改良が必要になる。

それらはそのプログラムで多数の試行を行った上で確認し、適正値と思われる値に調整し、また試行するという過程の繰り返しになる。
さらに、多くの試行を行って初めて出現する現象もあり、その原因究明と対処立案が必要になる。

各メンバーとも他にフルタイムのワークがあり、本開発は「一気呵成に」というわけには行かず、断続的にならざるをえない。
ワークは各自で行い、当初月１回、盛期は週１回ほど集まって統合していたが、ウイルス禍以後は全てオンライン化した。
2010年頃に部分的に着手し、2015年に本格的に展開した pBM が、一応の完成を見たのは、2023年のことであった。
（開発期間の一部は CREST の期間と合わせた）研究開発に8年以上を要したことになる。
（前述のように繁忙期の中断も結構ありー）
数日毎に新機能が公開されるような昨今の生成 AI の進展速度に比べると、時間尺度が違うのではないかと思えるような展開ではある。

pBM は３つのパートからなる。
ひとつは CG エンジン、もう一つは AI エンジン、そして三つ目はそれらを統合するプログラムを含むユーザーインターフェイス（以後 UI と略記）である。

CG エンジンには、スクリプトによるカスタマイズが可能で建築設計及び教育領域で広く使われているもの、として、グラスホッパー（以後 GH と略記）／ライノセラスを選んだ。
AI は上述のとおりのオリジナル品である。
統合インターフェイスにはゲームエンジンの Unity を用いた。
開発の中期段階までの UI は GH のインターフェイスをカスタマイズして用いていたのでやや煩瑣であったが、Unity 版ではすっきりした単純な UI となっている。

ユーザーはまず GH で目的の形態を生成するコンポーネントを組み立てる。
通常の手順では、複数のパラメータのスライダーを一つづつ操作しながら、望む形態を見つけていく。

しかし、パラメータが多数になるとパラメータ相互の作用が複合化し、あちら立てればこちら立たずという具合になり、個別のパラメータのスライダー操作だけで望む形態にたどり着くのは容易ではなくなる。

しかし、pBM でユーザーが操作するのは、もとのパラメータの数に関わりなく、それらを統合化した、たったひとつのスライダーだけである。

そして、AI は形態そのものは提示しない。

pBM-AI が示すのは、形態ではなく、ひとつのスライダーだ。
それはパラメータの数の次元を持つ、多次元空間上の直線（3次元空間では曲線相当）である。 AI は（ウエイトを付けた）ユーザーの選択履歴を「勘案して」（ー比喩的表現）、より適切と査定される「一本の多次元直線」を提示する。

pBM は公開版の制作を予定しているが、2024年時点では未公開である。pBM 実行版は２つの画面から成る。
ひとつは形態表示／操作の「メイン頁」で、もうひとつは経緯の表示／選択の「ブランチコントロール頁」だ。
ブランチコントロール頁では画像表示とリスト表示を選択できる。

操作対象の形態は、GH で作成する。
個々の GH を pBM に対応させるプログラム処理は、事前に行っておく必要がある。最初にメイン画面に表示される形態は、AI がデフォールトで選んだ形態である。
ユーザーは、スライダーを左右に動かして、これを好みの形態に近づける。前述のように、スライダーは一本のみなので操作はシンプルだ。
比較的好みに近い形態が表示されたら、save ボタンをクリックする。
すると AI は、ユーザーが選んだ形態を策定に加味して、次の候補スライダーを表示する。
以後はこの「選択→提示」を繰り返すことで、やがてユーザーの求めているものに近い形態に到達する、ことが期待される。
単純で、簡単だ。

ここで AI が示すのは、「形態ではない」ことに注意されたい。

前述の通り、AI が示すのは、ひとつの形ではなく、一本のパラメータ曲線（多次元空間では直線）である。
GH パラメータの数の多次元空間の中で AI は、ユーザーが選んだ複数の点にウエイトを与え、それに準拠して、最も「望まれていそうな」パラメータ直線（認知可能空間では曲線）を提示する。
メイン画面に表示されるのは、その直線／曲線上で、最も指示に忠実度の高い形態だ。

ユーザーが AI との応答を重ねていく方法には、下記の３通りがある。
（２と３はいずれも、「１」も併用する操作）

メイン画面のパラメータ＝スライダー表示は、左端が「活用端」、右端が「探索端」となっている。左の端が指示に最も忠実な形で、右に行くほど指示から離れて飛躍の度合いが高くなる。
ユーザーはこの直線上で自身の指示に対する「忠実―飛躍」の程度を選ぶことができる。
この方式を採る理由には、ユーザーは必ずしも自分の望むものがわかっているとは限らない、という事実認識がある。
「思った＝指示した」方向に行って欲しいと望むと同時に、思っても見なかった意外に良いものにも出会いたいという、矛盾した欲求をユーザーは（潜在的に）抱いている（経験則）。
その裏切りをも期待する潜在的な意図を組み込めないと、pBM は所定の目的を果たせない。しかし、毎度期待を裏切っていては、見放されてしまう。
そこでその「忠実／逸脱」の程度自体を、ユーザーの選択に委ねた。

このシンプルな繰り返しの中で、ユーザーには他の選択肢もある。それは、AI の２番手（以下の）候補を選ぶ道だ。
ユーザーは、表示される推薦順位に基づいて、AI が最も推奨するもの以外の候補を任意に選ぶことが可能である。

もうひとつの画面、ブランチコントロール頁では、選んだ形態が順に表示されている。
「選択→提示」過程の繰り返しの中で、直前の提示形態より「もっと前の形の方がやっぱり良かった」と思った場合、形態履歴を遡ってそこから枝分かれ状に「進み直す」 ことが可能だ。
これは、それまでの「選択→提示」の幹の途中から分岐して、前回とは違う枝を張る、ことである。

上記１－３以外にも、プログラム上ではさらに詳細な設定／選択が可能であるが、実行版 pBM ではこの３通りに限った。

pBM 試行例 short movie（加速版）
→ cube
→ petal
→ vortex
この例に限らず、Rhino/GH で可能な形態であればいずれも、pBM 化は可能なはずだ。

実施

pBM は筆者が以前に教授を努めた台湾の淡江大学で試行実践を行った。
研究協力者のひとり、Chen 教授（当時）が教える淡江大学建築学科の大学院生15名のワークショップを実行した。

評価

ワークショップ後の学生の感想では、「自分の望むような形態を提示してくれた（＝役に立つ）」というような記述が結構見受けられる。

→ WS 参加学生の反応
　（原文中国語・未編集／英文翻訳 by prof.Chen ／和文翻訳 by AI）

これらの評価が「本当にそうなのか」、或いは、そう思える「錯覚なのか」、それを確かめる方法はない。本人がそう思うなら、役に立ったのだ、とみなすしかない。
なぜなら、もともと、形態の良し悪しは本人にしか分からないからである。

これが「誘導都市」のような、光や風や、効果的な配置、というような性能を満たす案を得るのであれば、数値的評価が可能であり、プログラムの優劣を客観的に評価することができる。

しかし pBM で得ようとするのは、本人にとっての良さであり、万人にとっての良さ、ではない。
pBM で提示される形態の良し悪しは、平均値や統計値は無用の、個人に帰属する相対価値なのだ。だから、本人が役に立つと思えれば、pBM は有効、なのである。
そこに他者は介入しない。
その意味では（このワークショップの事後の彼らの意見の限りでは）pBM の有効性は立証されたといっていいのかも、しれない。

pBM_AI が LLM 系 AI に比して一定の対照効果を発揮したのであるから、それは快挙といっていい、であろう。
膨大な（データと電力＝資金）資源を必要とする LLM 系 AI がまだできないことを、教師データトレーニングも不要で電力もごく僅かしか使わない超コンパクトなプログラムの pBM_AI が可能にしたのだから。

しかし、最も大事な評価点は、使えるかどうか、である。
研究者／開発者、そして建築家としてのユーザーである筆者自身の試行評価は、学生とは少し異なる。pBM は必ずしも求めた性能に達しているとはいい切れない。
それは、「猿飛効果」や「気まぐれ作用」によるのかもしれないし、ここで用いた AI の特性によるものかもしれない。
→ 猿飛効果
筆者は開発者とユーザー＝建築家の両方を兼ねてはいるが、評価は建築家の眼になるので、どうしても辛くなる。
望みは高く、同時に技術的な問題点は認識している、からだ。

これは筆者の評価であるが、pBM は個人のためのツールなのであるから、評価はそれぞれのユーザーが自分で判断することになろう。

さらにもうひとつ。
この WS のように、あるいはネット上で、多数の被験者の選択過程を集めてそれをデータに使えば、（汎美意識のようなものが抽出？されて）多くの人々が「良いと思う／好む」形を提示できるはず、という指摘もよく受ける。
確かに、[ これから発売するミネラルウォーターのラベルはどれがいいか ]、というような選択であれば、それも有効かもしれない。

しかし、pBM が対象とするような「オリジナリティのある＝従前の一般傾向とは不連続性を持つ」形態を提示するには、この集合知手法は効果が薄いだろう。
（これも他項で記したことだが）「平均顔」がさほど魅力的でないように、市場原理や投票では、よいデザインは生まれない（と思う）のだ。

pBM は、「みんなが選びそうな形」ではなく、「特定のユーザーひとりにとって良い形」を提示することを目指している。
pBM はあくまで、「個人のための」＝「あなたのための」ツールなのである。

前述のとおり、pBM は「あなたの求めているものはこれですか」と、ユーザーの潜在的な意図を先取りして眼の前に示してくれるツールを目指した。
pBM が本格的に開始された 2015年には、そうしたプログラムは知られていなかった。
（存在していなかったのかどうかは未確認）
そしてこの 9年で、状況はその方向に進んでいる。

周知のとおり、LLM（大規模言語モデル）／ NN（ニューラルネット）を用いたいわゆる生成 AI の登場で、その流れは一挙に主流となった。
2024年時点で、生成 AI に pBM のようなことはできない。まだ、できない、といった方がいいだろう。
「まだ」＝「いずれ」≒「近いうちに」。

LLM AI は、まさに力技だ。
半端ない量の教師データを大量の GPU と大電力（＝資金力）を投じて学習してしまう。
（LoRa を凌ぐコンパクトな AI 技法もそのうち開発されるだろうが）
「3次元形態の意図先取生成」と「三次元形態←→コマンドの相互変換」が可能になれば、pBMのパフォーマンスは達成できる。

最も、機能上の条件が課されない「イメージ」の段階では、数打てば当たる方式の現行生成 AI でも、「それなりのもの」 が得られる。

参照 → Drawings 頁
シリーズ番号が大きい（＝より新しい）作品には、AI とヒト（＝筆者）との協同作品が含まれている。

そしてさらにここに、形態以外の（機能を含めた）要求条件の処理も、（それは容易ではないだろうが）順次加わっていくだろう。
「形態＋機能＋構造＋施工＋経済性」まで、要求条件を充足した設計を提示する AI。それは 30年前、1994年に「誘導都市」が目指したものがまさに実現した姿に近い。

そうなったとき、その AI のパフォーマンスは、「設計支援」を越える。 pBM や「誘導都市」は、あくまで設計者を「支援する」役割だった。

しかし、「・・・をつくって」といえば、希望に「近い」ものが、（個別には指示していない）必要条件も自動的にクリアして現れる、のであれば、それはもはや「設計行為そのもの」だ。
そこに「設計者」は必要だろうか。
その世界に「ヒト」の役割は、まだあるだろうか。

すでに、チェスや将棋でヒトは AI の相手にはなれない。
ヒトは、AI の手の上で遊ばせてもらっているような状態だ。こうした事態は、ゲーム領域だけではない。
合目的機能を持つ分子式を膨大な候補から策定する創薬も、既知の物理現象や既存論文からの新科学理論の発見も、すでに AI に凌駕されつつある。

「設計」領域は、解くべき条件が多岐に渡り、それらの相互作用の絡み合いも大きい。
（それは「誘導都市」で経験済）
AI にとっても「そんなの簡単」とは行かないだろうが、「どうやってもできません」という理由はない。
ゴールドマン・サックスは 2024年、AI によって仕事が代替されると予想される業務の第三位に建築設計を上げていると報道された。

協同研究者の佐藤准教授（当時）との雑談の折に、「AI が AI プログラムをつくれるようになったら、あなたはどうしますか」と尋ねたことがある。
氏は「そうなったら研究はやめます」と答えた。（当方の記憶なので誤認があるかもしれず）当時はまだ SF だったその事態が、いまは現実になろうとしている。

この質問は、「AI が（優れた）設計をするようになったら、（建築家の）あなたは何をしますか？」とすることもできるのだ。

一般機器の設計では、要求された条件をクリアすれば OK だ。
しかし建築の設計は、「課題を解けば良いんでしょ」とは行かない。
要求された条件を満たす解を提示することは、設計の必要条件ではあるが、十分条件ではないからだ。必要な面積の部屋があって、地震に耐えられる、それだけではまだ 「建物」であって、「建築」とは呼べないだろう。

建築には、条件充足以上のこと、もっと上、が求められる。それは、ヒトの気持ちに応えること。

見ただけで「そこに行ってみたくなる」建築。
そしてそこに入ったとき「気持ちが沸き立つような、あるいは安らぐような」空間。
美しい、素晴らしい、感激した、というような、解答という次元を超えて心を動かす、作用。
それを（筆者は）夢と呼んでいたのだが、そしてキカイは夢を見ることはできない、としていたのだがー

2024年時点の Gemini ／ Bing ／ Firefly に「夢を見る機械」をプロンプトを変えながら 50ほど描かせてみたが、最もましなものでも、この程度だった。→作例 a
どの AI も、こういうどこかで見たような定番の方向に行きたがる。→作例 b
（いずれも描画技術は高いのだが）
現時点の AI に「想像力／創造力」は、未だ育っていないようだ。

AI は、学習した教師データの枠内からは出られない。
学習に役立った教師データが、同時にそこに AI を閉じ込める「壁」になっている。→作例ｃ
（それが、pBM で教師データ学習を必要としない AI を用いた理由のひとつだった）その「壁」を越える技術が登場するのも、そう遠くはないだろうがー

この質問は、「AI が（優れた）設計をするようになったら、（建築家の）あなたは何をしますか？」とすることもできるのだ。

ヒトは、芸術作品や音楽や建築に「感動」する。同時にヒトは、自然の風景にも心を動かされる。
夕日を受けて茜色に染まる峰々を眼の前にするとき、見上げるような波濤が砕け散る瞬間、精緻なボロノイパターンを描く蜻蛉の羽を光に透かしたとき、ヒトの心は振動する。
その響きは、自然ではなくヒトの手になるピラミッドを、ベルニーニの「聖テレジア」を、葛飾北斎の「神奈川沖裏」を、見たときと共鳴する。

「物理現象の複合作用に過ぎないはずの自然現象」にヒトが感動するなら、「演算の複合体である AI が生み出す成果品」にヒトが感動しても、不思議はないだろう。
そのとき、
AI の見せるカタチに あなたが／私が 心を動かされた、そのとき、キカイは「夢」を得たことになる。

これも他所で幾度か記している定番の問答なのだが、
かつて、「誘導都市」／「アルゴリズミック・デザイン」を謳っていた頃、よく投げかけられた問がある。
「設計者は要らなくなるのですか」

その問には、決まってこう答えていた。
『 夢を見るのは、ヒトの特権です。
キカイ＝プログラムはその夢を現実に適用することに役立ちます。しかし、キカイは夢を見ないのです。
キカイは「要求＝条件」を「解く」ことはできるが、条件のない対象である「夢＝イマジネーション」を「解く」ことはできません。
イメージは「そこにある条件」ではなく、「どこにもない幻」なのですから 』

著書「アルゴリズミック・デザイン実行系 ALGODEX」（2012年）でも、こう記している。
『 なんのためにつくるのか、何を求めるのか。何が、いいのか。
その「何＝価値」を描いてみせることは、ひとに委ねられています。
それこそ、「設計=生成」過程で、ヒトにしかできない、ひとだけが持つ未知の（潜在）能力が発動される（はずの）、領域なのです 』

そして、「AD + AItect : キカイが夢を見る日に、ヒトは何を見るか」では、こう答えていた。

→ Aitect の当該章

筆者は、手を動かして描くのが好きだ。
時に思考の束縛から解き放たれた自らの手が、ひとりでに描き出すその光景は、自分自身にとっても「新鮮な」驚きなのだ。

しかしー

いまは、こう応えるだろう。
「キカイが夢を見るようになったとき、ヒトの役割は終わる、のかもしれない。ヒトが、「夢」さえ越える（まだ見ぬ）新しい能力を発動しない限り」
（未知の言語を数日で習得したり、対象の数理的構造を可視化できたりする人々も存在する。ー後天性サバン症候群やギフテッドと呼ばれる例もある）

果たしてヒトは、（AI が追いつけない）そんな「超」能力を開花させることができるだろうか。

自らの手に負えない存在を生み出してしまうヒトの性は、歴史が証明している。その性は、ヒトの基本プログラム＝ヒト OS に書き込まれているのだろう。
火、農、電、核・・・自らの手を拡張し周囲の環境を改変できる「力」を得る誘惑に、ヒトは抗えない。
そうして生み出したものたちを制御しきれなくなり、結果として逆襲される、それが農耕神クロノス＝サトゥルヌス＝サターン／ Kronos ＝ Saturnus の宿命だった。

人類に残された猶予は、そう長くはない。

pBM の構想は 2000年頃に遡る。
「誘導都市／アルゴリズミック・デザイン」には解けない類の課題があった。それは評価基準を書き出せない課題、例えば「好みの形を得る」だ。
そうした課題を解けるのは AI しかないと考えて、NN と遺伝的アルゴリズムを用いた「流れのプログラム」を、誘導都市で協同してきた SE の千葉氏と共に開始した。
この AI プログラムの開発は未踏ソフトウエア創造事業の支援を得て進められ、2004年の「TX 柏の葉キャンパス駅」で実施設計に用いた。
駅は完成したが、プログラムの能力には満足できなかった。

当時、LLM はまだ知られておらず、GPU も一部のゲーミング用途に限られていた時代である。
その時点での NN の限界を感じて、しばらくそのままにしていたが、その後、再度挑戦しようと NN を用いる pBM を構想し、千葉氏と共に着手した。

そして 2015年に国際シンポジウム AQS「AI にデザインは可能か」を主催した際、会場にいらした若き俊英 AI 研究者の佐藤氏が話しかけてきたことが、pBM の新体制稼働の契機となった。

そこでそれまでの NN に替えて、佐藤氏の開発した新たな AI を用いて進めることにした。
チームには JavaScript 等のプログラムに強い鄭氏が加わり、台湾で IT 系建築教育を行っている Chen 氏がリモート参画した。
千葉さんは２つに増えた社長業の繁忙化で途中から戦列を離れたが、pBM はその後、CREST の支援も受けて進められた。

pBM はこうした「志を同じくする者＝同士」ともいえる面々の普段の努力と能力の結晶である。
「今日の不可能を明日の可能にー」の意を共有したチームの方々の緊密な協力と多大な尽力に、深く感謝したい。