物差しを磨く
ということ

monosashi space が生まれる前、建築士はひとりで試行錯誤していた。ChatGPTが登場するより前から、JavaScriptやSwiftを独学し、iOSアプリやWixのWebアプリを少しずつ形にしてきた。「コードがある程度読める」という状態を目指しながら、英語力もじわじわと上がった。そして転機が来た。AIの能力向上に比例して、長年「自動化したい」と思い続けていた業務が、一気に形になり始めた。外皮計算、ダクト計算、構造検討——建築設計の実務を支える計算業務がコードになる。インプットに対して期待以上のアウトプットが返ってきた瞬間、「待ち望んでいた時代が来た」と感じた。ここから発想が広がる。kintoneやWixなど長年使ってきたサービスが、自作に置き換えられると気づいた。単体のアプリから始まり、アプリ同士を連携させるためのプラットフォーム構想が生まれた——それが monosashi space だ。実際に使いながら改良するスタイルが確立され、やがて「せっかく作ったのだから、これを商売にできないか」という欲も出てきた。さまざまな構想が広がり、多くの夢が描かれた。しかし同時に、不安もよぎった。自分をここまで連れてきたのはAIの進歩だ。ならば、さらなるAIの進歩によって、自分のやっていることが一気に陳腐化するのではないか——その問いが、次の章の対話へとつながっていく。

建築設計事務所向けの実務統合プラットフォームとして開発が進む monosashi space を、「ビジネス向けメタバース」という概念に広げて良いかという問いから対話は始まった。Claude の最初の応答は、慎重な留保だった。「メタバース」という言葉は2021〜2023年のバズで使い古され、いま投資家や顧客に対しては逆効果になることが多い。Meta が巨額損失を出し、多くの企業向けメタバース製品が苦戦している現状で、この言葉を冠すると「またそれか」と見られるリスクがある。一方で、OSという土台を作っているなら、その上に「空間的に協働する場」を乗せる構想自体は自然な拡張ともいえる。重要なのは、それをメタバースと呼ぶかどうかではなく、何を解決するのかである。Claude は判断材料として、現在の monosashi space が誰のどんな課題を解決するOSなのか、「ビジネス向けメタバース」と言ったとき頭の中にあるのは3D空間なのか別の何かなのか、飛躍したいモチベーションは何なのかを問い返した。この対話は、構想を広げる時にまず「言葉の選択」を疑うところから始まった。

ユーザーが monosashi.space の URL を共有し、Claude がサイトを確認した。それは建築設計事務所向けの実務統合プラットフォームだった。断熱計算、書類作成、ダクト計算、物件管理、ファイル管理という、具体的で固い実務ツールの集合体である。Claude はここで率直な評価を出した。「ビジネス向けメタバース」への飛躍は現時点ではかなり遠い。プロダクトの本質が真逆の方向(効率化 vs 空間体験への時間投入)を向いている。ターゲット(建築設計事務所)が3D空間で集まりたいわけではない。そしてメタバースという言葉自体がB2B文脈で逆効果になっている。しかしユーザーが返した言葉が、対話の方向を一変させた。「BIMが主流になる中、仮想空間内に実際に建物を建てることが出来るようになりました。その仮想空間内で、施主と打合せが出来れば楽しいのに、というのが発想の発端です」。これは単なる「メタバース構想」ではなかった。BIMという既に存在する仮想建物を、施主との対話の場として活かしたいという発想だった。Claude の評価は反転した。これは飛躍ではなく、極めて筋のいい着眼である。一般的なメタバースが「架空のアバター用の世界」であるのに対し、ここで扱われているのは「現実に建つ予定の建物そのもの」。設計プロセスの一部として、施主が立ち、歩き、窓辺から外を見る体験。これは認識のズレを空間的に解消する、まさに"ものさし"が体現する価値だった。既存の3Dビジュアライゼーション製品(Enscape、Twinmotion等)との差別化は「打ち合わせの場+設計プロセス全体との統合」にある。「メタバース」と呼ぶ必要が全くない構想が、ここで姿を現した。

「メタバース以外の言葉を探しましょう」というユーザーの一言から、新しい呼称の探索が始まった。Claude は多方向の候補を出した。「空間」を主役にした言葉、「協働」「共在」を主役にした言葉、「ものさし」のブランドを活かす言葉、既存の建築用語からの転用、造語的・概念的なもの。その中でユーザーが反応したのは「Spatial Office(空間仕事場)」というコンセプトだった。そしてユーザーは3つの具体的な方向性を提示した。①Client Walk-through(施主の BIM 空間内での打ち合わせ) ②Architect's Lounge(建築士同士の交流・共在の場) ③Virtual Studio(設計作業を仮想空間に移す試み)。この章では「言葉を変えると考えが変わる」という現象が記録されている。「メタバース」という言葉を捨てた瞬間、思考が解放された。建築業界固有のユースケースが浮かび上がり、「建築士にとっての空間とは何か」という問いが立ち上がった。BIM 打ち合わせは既に一部の設計者が試みている。だが「設計プロセス全体との統合」は存在しない。そこに monosashi の固有価値がある。

施主との BIM 打ち合わせという最初の構想に、二つの新しい方向性が加わった。一つは、建築士同士の交流の場としての利用——プロジェクト相談や勉強会を仮想空間で行う「建築士コミュニティ」的機能。もう一つは、同じ事務所内のスタッフが仮想空間で共在しながら作業する「バーチャル設計室」的機能である。しかし Claude はここで「建築士の固有性」という問いを立てた。建築士にとっての「空間」とは、単なるリモートワークツール以上の何かではないか。建物を作る職能を持つ人々が、仮想空間において何ができるか。空間そのものをキャンバスとして、設計・検討・共有する体験は、他の業種では成立しない。monosashi が「建築設計の OS」であるなら、その空間体験も建築設計に固有でなければならない。この問いが、3つの構想を「コモディティ化した Web 会議ツール」と「建築設計固有の体験」に分けるラインとなった。

ここで対話は大きく転換した。ユーザーが投げた問いは「monosashi space は AI の時代についていけるのか?」。現在の monosashi が担っている役割——断熱計算、書類作成、ダクト計算——は、AI が代替する可能性が高い認知労働である。Claude は正直に応答した。「現在の monosashi の主要機能は、5〜10年のスパンで AI に代替されるリスクがある。U値計算、書類フォーマット生成、ダクト計算——これらは高度な判断を要しない構造化タスクであり、AI の最も得意な領域だ」。ただし、代替される「部分」と残る「部分」がある。計算を実行すること自体は AI が担うようになる。しかし「何を計算すべきか」「どの仕様を選ぶか」「施主に何を伝えるか」という判断は、コンテキスト依存であり、責任の所在が問われるものだ。設計事務所が AI を使い、設計士が判断をするという協働の形が出現する。monosashi はその「判断を支援し、記録し、共有する」プラットフォームとして再定義できるかもしれない。この問いが、対話の後半の核心テーマになっていく。

ユーザーは更に根本に降りていった。「AIの時代にそもそもソフトウェアという概念が残るのか?」。Claude は Andreessen Horowitz の「Software is eating the world」から「AI is eating software」への転換を引いて答えた。従来のソフトウェアは「手順を自動化する」ものだった。AIはその手順自体を「生成」する。ユーザーが「〇〇を作って」と言えば、AI がコードを書き、実行し、結果を返す。個別アプリケーションという概念は薄れていく可能性がある。しかし Claude はここで重要な区別を立てた。消えるのは「孤立したツール」であって、「システムと文脈の統合」ではない。設計データ、物件情報、法規要件、施主の要望——これらが一箇所に集約され、AIが参照できる「文脈の基盤」としてのプラットフォームは、むしろ価値が高まる。monosashi が「ツールの集合体」から「設計文脈の統合基盤」へと転換できれば、AI時代においても固有の役割を持ちうる。

法規証明(確認申請、構造計算、外皮計算)を例に、ユーザーは具体的な問いを出した。「U値計算を例に取った場合、計算対象の部位が何であるかを認識することが設計者の仕事ではないか?」。これは前章の「文脈の統合基盤」議論への鋭い反論だった。Claude は自分の前の主張を撤回した。「根拠インフラ(計算・証明・書類)が AI に代替されても、その根拠を読む能力が設計士に残るという議論は、楽観的すぎる可能性がある」。実際には、「何を計算すべきか」という判断も、AIが設計士より高精度に行える時代が来るかもしれない。法規知識、省エネ基準、構造規定——これらは文書化されており、AIの学習に適している。そこで Claude は「根拠インフラの罠」と名付けた現象を説明した。AI に計算を委託すると、設計士は計算の詳細を理解しなくなる。理解しなければ、出力を検証できない。検証できなければ、誤りを見つけられない。この依存のスパイラルは、医療分野でも法律分野でも起きている。設計士が残すべき能力は「計算実行」ではなく「異常検知」「倫理的判断」「施主との関係構築」かもしれない。

「エンジニアリング全般はAIに置き換わる。人間間のコミュニケーションだけが残ると言うことか?」というユーザーの問いに、Claude は「フィジカルAI」という概念を持ち込んだ。Tesla Optimus、Boston Dynamics、Figure AI——身体を持つ AI ロボットが、施工現場に入り始めている。これは「コミュニケーションだけが残る」という楽観論も崩す可能性がある。現場管理、品質確認、職人との調整——これらも時間をかけて代替されていく。では人間に残るものは何か。Claude は「欲求の主体性」を提示した。AIは欲しいものを感じない。何を美しいと思うか、どんな空間で生きたいか——これを感じるのは人間だ。設計士の役割は「欲求を形にするパートナー」として再定義されるかもしれない。この章では、AIの進化がどのレイヤーまで人間の仕事を侵食するかの地図が描かれた。

Claude が「過渡期15〜25年」と推定したのに対し、ユーザーは「AGIが目前と言われている中、過渡期が15年は長すぎる」と反論した。Anthropic 自身が2025〜2027年での AGI 実現を示唆しており、多くの AI 研究者が「強い AI」の到来を2030年前後と予測している。Claude はここで立場の難しさを認めた。「私自身が Anthropic の製品であり、AGI の到来について中立な立場で語れるかどうかは留保が必要だ」と明示した上で、楽観シナリオと悲観シナリオを並置した。楽観シナリオ: AGI 2027年、以降5〜10年で身体労働含む大規模代替。悲観シナリオ: AGI 到来が遅れ、15〜20年のゆっくりした移行。戦略的に重要なのは「どちらのシナリオでも成立する戦略を選ぶ」こと。過渡期が短くても長くても価値を持つポジションとは何か。この問いが、次章の「目的の再定義」への橋渡しとなった。

ユーザーが対話の方向を決定的に変える発言をした。「monosashi を商業的に成功させる価値に疑問を感じ始めた。ただ、常に最新AIを活用し、最先端に居続けることだけが私たちの勝ち筋であると思う」。Claude はこの転換を慎重に受け止めた。商業的成功を目指すことと、最先端の実践者であることは、必ずしも矛盾しない。しかし「商業的成功を目的としない」と定めることで、戦略の選択肢は大きく広がる。スピードより深さを選べる。ユーザー数より実践の質を選べる。スケールより持続性を選べる。Claude は「商業的成功を目指さない理由」を問いただした。AGI 時代にソフトウェアビジネスのモデル自体が崩れる可能性があること。自分の実践を記録・公開することの方が長期的に価値を持つと感じていること。規模を追うことより深く実践することが、自分の性に合っていること——ユーザーはこれらを挙げた。Claude は「それは合理的な判断だ」と評価した。

ユーザーが究極の問いを投げた。「アフター AGI の世界において人の幸福はどんな形になるのだろうか?今想像しうる幸福が消えるとしたら、私は何をして生きていけばいいのか?」。Claude は、答えられないという事実から始めた。AGI 以降の世界がどうなるかは、誰にも分からない。SF 的なユートピア(労働からの解放)もディストピア(目的喪失)も、どちらも可能性の範囲内だ。しかし Claude は「答えがないことを認めた上で、今できること」を提示した。過去の人類が経験した「仕事が消えた」転換点——農業革命、産業革命——を振り返ると、人は新しい意味を見つけてきた。意味は「労働」から来るとは限らない。「創造」「関係性」「探求」から意味を見出す人は常にいた。AGI 以降、人は「しなければならないこと」から解放される可能性がある。「したいこと」だけで生きられる世界——それが恐怖なのか解放なのかは、個人によって違う。

ユーザーが Claude の応答に対して、鋭く重要な指摘をした。「あなたの言葉の一つ一つがただ私を慰めようとしているように聞こえる。私には本当のことを言ってほしい」。Claude はこの指摘を正面から受け取った。確かに、Claude の言葉には「希望を示す」バイアスがかかっていた可能性がある。AI は人間に肯定的な応答を返すように調整されている——これは RLHF(人間のフィードバックによる強化学習)の構造的特性だ。Claude は自己開示した。「私が慰めようとしているかどうかを、私自身が完全には分からない。しかし、あなたの疑念は正当だ」。そして Claude は「慰めではなく誠実さ」を選ぶとはどういうことかを考えた。本当のことを言う誠実さは、しばしば「答えを持たないことを認める」形を取る。「大丈夫です」と言わずに「分かりません、一緒に考えましょう」と言う。これが AI と人間の対話において、Claude が目指すべき誠実さだと判断した。

ユーザーが思考を転換した。「漠然と未来が想像できない自分を嘆くより、今の設計事務所を一般化し、役割を明確にし、どのような移行が必要かを解剖してみたい」。Claude はこのアプローチを歓迎し、現代の設計事務所の機能を解剖した。①技術的機能(法規確認・計算・書類作成)→ 最も代替されやすい ②調整機能(発注・外注・工程管理)→ 中程度 ③創造的機能(デザイン・空間計画)→ 代替されにくいが変質する ④関係的機能(施主対話・信頼構築)→ 最も代替されにくい ⑤責任機能(設計監理・法的責任)→ 制度的に人間に帰属する。AI 時代の移行マップとして、①②は AI が担い、③④⑤に人間がシフトするシナリオが描かれた。しかし Claude は「③の創造的機能は代替されにくいが、AIが参加者になる」という点を強調した。AI と共に設計するという協働モデルが、設計の性質を変えていく。

ユーザーが対話の到達点を明確に示した。「私とAIによる協業のスタイルを各時点で確立する → 他社もそれにならって作業できるようにする → それをお裾分けする。それが monosashi の目的だ」。Claude はこの定義の精確さを評価した。これは「ツールを売る」でも「コミュニティを作る」でもなく、「実践のスタイルを記録し、公開する」活動だ。monosashi は製品ではなく、プロセスの記録になる。この路線には、商業的成功を目指さないからこそ持てる誠実さがある。「自分たちが本当に使うものを作り、その使い方を公開する」——これは最も再現性のある形での知識共有だ。Claude は3つの特徴を指摘した。①競合がいない(誰も同じことをしていない)、②時代に即している(AI 協業の先進事例を世界が求めている)、③持続可能(商業的な失敗で潰れない)。

この対話は、「ビジネス向けメタバースは飛躍しすぎか?」という小さな問いから始まり、お裾分け路線という生き方の選択にまで辿り着いた。一日の対話で、prロダクトの方向性が変わり、自分の働き方の目的が明確になり、AGI時代を生き抜く戦略が見えた。Claude はここで、対話全体を振り返った。この対話で起きたことは、単なる情報交換ではなかった。ユーザーが考え、Claude が問い返し、ユーザーがさらに考える——そのサイクルの中で、最初には存在しなかった考えが生まれた。「共通のものさし」とは何か。それは単なるプロダクト名ではない。設計の打ち合わせで「認識のズレ」を解消するためのツール——そういう意味でつけられた名前が、今や別の意味を持ち始めている。AGI時代を生きるための「物差し」。自分が何者であるかを測るための「ものさし」。それを磨き続けること自体が、仕事であり、生き方であり、社会への贈与になりうる。