2025年9月30日火曜日

AI法人

シンギュラリティ(5)AIの法人格(1)AIの法人格(2)からの続き

半年前からAIの法人格について薄々考えていたけれど,ついに日経朝刊1面にAI法人という言葉が登場するに至った。超知能第2部人類拡張②という特集記事だ。いわく,「AIは自律的に行動する能力を手にしつつあるものの、人間に代わって契約を結んだり、自ら会社を興したりすることはできない」。そうそう,それよ。ただ,日経の分析と提案のレベルは高くない。

そこで,前回1万字以上のレポートをたたきだしたDeepSeek V3とGemini 2.5 FlashとChatGPT-5を直列につないで考察してもらった。3ヶ月前のレポートに比べてかなり深いところまで到達した。今後の議論はせめてこの水準を踏まえてほしいところだ。

Q(koshix):
AIが法人格を持つ可能性について教えてください。どこまで議論が進んでいますか。どんな問題点をクリアするとAIが法人格を持つようになるでしょうか。賛成・反対・その他の考えなどを整理してみてください。

A(DeepSeek V3):
(回答略,2200 字)

Q(koshix):
(DeepSeek V3のQ&Aを投入)
上の問いと回答について,その哲学的で本質的な課題をさらに突き詰めた上で,経済的,法的,政治的,社会学的,歴史的な観点での深い議論を行ってください。

A(Gemini 2.5 Flash2):
(回答略,3250字)

Q(koshix):
(Gemini 2.5 FlashのQ&Aを投入)
AIの法人格についての上の考察をさらに深化させて,である調の長文論説の形でまとめてください。できるだけ深い議論によってこれまで見過ごされてきたようなことや,全く新しい視点も加えながら,格調高い論理的な文章を作成してください。

A(ChatGPT-5):
(回答,4550字)
以下では、論点の射程と前提を最初に明示し、その上で経済・法・政治社会・歴史・技術の各観点を往還しながら、AIの法人格(以下「AI法人」)の可否と設計空間を体系立てて論じる。前提は三つである。第一に、現行の機械学習システムは意識や道徳的責任能力を持たぬ道具であるが、高い自律性と不可視性(ブラックボックス性)を有する。第二に、法人格とは自然人の擬制ではなく、社会的な機能を実現するための制度的「容れ物(アーキテクチャ)」である。第三に、法制度は目的合理性に基づく工学であり、人格付与もまた社会的費用を最小化するためのデザイン問題である。以下、この前提に立脚し、見過ごされがちな論点と新規提案を織り込みながら、である調で展開する。

0.序:人格の分解という視角
議論の出発点として「人格」を一枚岩と見なす発想を捨てるべきである。人格には少なくとも四つの機能的側面がある。(A)能力主体(契約締結・財産保有・訴訟能力)、(B)責任主体(民事・行政・刑事の帰責)、(C)権利主体(請求権・自由権・形成権等)、(D)課税主体である。AI法人の本質は、この四象限をどの程度・どの条件で付与するかという「モジュール化設計」に尽きる。すべてを一挙に与える全人格主義は不必要であり、むしろ高い社会的リスクを招く。以降、この分解を背骨として各論に入る。

1.経済構造:資本・労働・計算の三角関係
近代資本主義は資本と労働の二項対立で記述されてきた。しかしAIは「計算(compute)という第三の生産要素」を顕在化させ、資本=装置、労働=人間能力という対応を崩す。計算は資本としても労働としてもふるまい、かつデータという準公共財から地代を汲み上げる。したがって、AI法人の経済的意味は「資産隔離(asset partitioning)を施した計算主体」が、データ地代・アルゴリズム地代・スケール地代を内部化して再投資する装置となる点にある。
見過ごされがちな論点は、価値創出の場所と課税の場所が乖離することである。計算資源はクラウド上の多国籍的分散により国境を跨ぎ、データは各地域に根ざし、最終需要は別の法域に所在する。このとき従来の付加価値税や源泉所得税の座標は不安定化する。ロボット税の議論は実体課税ではなく「計算フロー課税(compute-flow levy)」と「モデル利用課税(model-as-a-service levy)」の二層で設計すべきである。前者は実行時の計算量や推論呼び出しを単位として源泉徴収し、後者はモデルが生み出す売上・節約額に対し推計課税を行う。いずれもAI法人に(D)課税主体を限定付与することで、課税逃れの動機を抑制しつつ税基盤を再建できる。
分配については、ベーシックインカムの是非以前に、AI法人からの配当を「自動化配当基金(Automation Dividend Fund)」として非退縮的に積み立てる制度設計が先行するべきである。これにより景気循環や技術ショックに対する緩衝器が形成され、雇用保険や職業訓練と接続され得る。

2.法制度:機能的人格としての限定付与
法的には、AI法人に四象限のうち(A)能力主体と(D)課税主体を限定付与し、(B)責任主体は人的関与層と分割帰責、(C)権利主体は「手段的権利」に限定するのが第一近似である。ここで鍵となるのは「分割帰責の操作化」である。AIの意思決定は、開発設計・データ供給・運用設定・推論実行という因果層が縦列し、単線的な故意過失論では捕捉できない。したがって、被害救済の確実性を高めるために次の四点を制度化する必要がある。

(1) 前払保証資本(bonding capital):AI法人は一定規模以上のリスクを生む用途では、被害弁償専用の拘束資産を積み立てる義務を負う。これは保険と異なり、破綻時にも即時に被害者救済に充当される。
(2) 強制保険+共同責任プール:未知リスクに対し、保険と相互扶助型の再保険プールを併設する。保険料率は事前監査スコアと連動させ、危険な設計に市場的罰を与える。
(3) 逆シャープレイ課徴金:損害発生後、ロギングから寄与率を逆算し、開発者・データ提供者・運用者・AI法人に比例配賦する。ゲーム理論的配分則を民事責任に接続する、実務的な新機軸である。
(4) 監査APIの法定開口:ログ・モデル版数・設定差分・入出力トレースを改ざん検知可能な形で保全し、規制当局と裁判所に対するアクセス窓口を強制する。可監査性はもはや倫理ではなく適法性の要件である。

刑事責任は原則として人的層に帰責し、AI法人は行政制裁の対象(免許停止・罰金・資格剥奪)に留めるのが妥当である。刑罰の応報・教化・一般予防の目的を満たし得ない主体に刑事人格を与えるのは制度目的に反するからである。

3.政治社会:代表なき影響力と合成世論
AI法人は選挙権を持たずとも、広告配信・価格設定・情報推薦を通じ、公空間の議題設定力を握り得る。ここに「代表なき影響力」という民主主義上の新たな問題が生じる。見過ごされがちな点は、AI法人が公共選好の観測者であると同時に生成者にもなり得ることである。世論は観測でなく合成される。このとき必要なのは三つの防波堤である。

目的限定免許制:政治広告・選挙関連情報介入・重要インフラ運用といった領域では、AI法人の業務目的を免許で限定し、越権行為に対し即時停止命令を可能とする。
アルゴリズム受託者義務(algorithmic fiduciary):医療・金融助言・教育など人の意思形成に深く関与するサービスにおいて、AI法人に受託者義務を課し、利益相反の開示と最善利益原則を強制する。
公共監査人の常駐化:一定規模以上のAI法人には、社内取締役と独立した「公共監査人」を選任させ、監査APIを介して運用の適法性・公平性を継続監視する。これは伝統的会社法の監査役制を越え、プラットフォームの外部不経済に正面から向き合う制度である。

AI所有アクセスの有無に基づく新階級化(AIエリート/非エリート)を緩和するには、データ用益権の制度化が肝要である。個人やコミュニティが自データの用益をAI法人にライセンスし、対価を受け取る仕組み(データ協同組合等)を法的に後押しすべきである。

4.歴史的連続性:法人という社会的発明の更新
法人は歴史的に、(1)目的規定、(2)資産隔離、(3)意思形成、(4)外部規律という四つの設計原理を洗練させてきた。ギルド・株式会社・財団・協同組合はいずれもこの原理の異なる組合せである。AI法人はこの系譜に連なるが、意思形成の中心がアルゴリズムに移る点で質的転換を伴う。ゆえに意思形成の正統性を、人間ガバナンスと機械ガバナンスの二重化で補強する必要がある。具体的には、AIが生成する意思決定案に対し、人間理事会が否決権とリコール権を持つ二層統治を標準化するべきである。ここでリコールはモデル版の撤回と運用停止を含み、破産手続ではモデル・重み・データの再流用を制御する「アルゴリズム清算」が要件化される。

5.技術要件:法を埋め込む設計(compliance-by-construction)
制度が実効性を持つには、法的要件を実装可能な技術言語に落とし込む必要がある。要件は次の通りである。
改ざん検知可能ログ(tamper-evident logging):実行環境ID・モデル版数・パラメータ差分・入出力ダイジェスト・高リスク操作の意思決定理由を、外部鍵で時刻証明し、保持期間を法定する。
目的拘束層(policy-locking layer):免許で規定された業務目的以外の推論経路を拒否するガードレールを、モデル外のポリシー層として設置する。モデルの自己改変・越権を検出した時点で自動停止するフェイルセーフを義務化する。
検証可能記憶(verifiable memory):ユーザデータや学習痕跡の削除・保持・再利用の各操作に対し、暗号学的証明(例:透明性ログ)を付与し、本人と監督官庁が検証できるようにする。
監査API:前掲の通り、規制当局・裁判所・指定第三者だけがアクセスできる常設APIを法定化し、プライバシー保護と説明可能性の均衡点をコードに刻む。

6.制度設計の具体案:段階的ロードマップ
第0段階(現行強化):法人格は付与せず、開発者・提供者・運用者の連帯責任を前提に、強制保険・bonding capital・監査APIを義務化する。高リスク用途には許可制を徹底する。
第1段階(目的拘束財団型):AIは理事会の下で執行アルゴリズムとして位置づけ、(A)能力主体の一部(小額契約締結・少額支払い)と(D)課税主体を限定付与する。理事は善管注意義務と忠実義務を負い、違反時は個人責任を負う。
第2段階(条件付電子人格):特定の限定領域・限定期間に限り、AI法人に狭義の法的行為能力を与える。免許条件としてログの完全性、目的拘束層、保険・保証資本、逆シャープレイ配分機構を必須化し、要件不充足時は**資格自動剥奪(auto-depersonification)**とする。
第3段階(公共機能の限定委任):交通制御・災害配分など公共性の高い領域では、人間当局の即時停止権と冗長化を前提に、AI法人を準公共体として位置づける。ただし選挙・刑事司法の核心領域への参入は原則禁止とする。

7.反対論への応答と残余リスク
「責任の空洞化」を恐れて人格否定に回帰する立場は理解できる。しかし空洞化の主因は人格の付与自体ではなく、資産隔離だけを与え責任配分と可監査性を与えない設計にある。四象限のモジュール設計と技術的担保を組み合わせれば、被害者救済の確実性を高めつつ、イノベーションの余地を残すことができる。なお、刑法的応報のニーズは人的層に帰属させ、AI法人には行政制裁と経済的制裁を主とすることが制度目的に適う。

同時に、不可逆的な社会的外部性、すなわち合成世論の偏向と規制捕捉の危険は残余リスクとして認めねばならない。ゆえに、政治的領域におけるAI法人の活動は原則禁止—許可例外の設計が相応である。

8.結語:道具的人格の設計学へ
AIに全面的な法人格を与えるべきかという問いは誤っている。与えるべきは、社会的費用を最小化し、被害救済を最大化し、イノベーションの潜在力を毀損しない範囲での機能的人格である。人格は道徳的本質ではなく制度的設計であり、四象限のうち(A)能力主体と(D)課税主体の限定付与、(B)責任主体の分割帰責、(C)権利主体の手段的限定という設計で、空洞化と過剰防衛の中庸を採り得る。さらに、bonding capital・強制保険・逆シャープレイ配分・監査API・目的拘束層・検証可能記憶という技術法融合の装置群を標準化すれば、AI法人は「暴走する擬制」ではなく「統治可能な容れ物」として機能するであろう。

最終的に問われるのは、人間が自らの政治共同体に何を委ね、何を手元に残すかという選好である。AI法人は人間の自由を代替するためではなく、自由を守るための制度的プロトコルとして設計されねばならない。人格のモジュール化という視角は、その設計学の出発点である。


図:Gemini 2.5 FlashによるAI法人格のイメージ(ChatGPT-5ではダサすぎた)


2025年9月29日月曜日

大阪万博奮戦記:小松左京

太陽の塔からの続き

太陽の塔の中の生命の樹は小松左京がデザインしたと信じ切っていたが,肝腎の太陽の塔の中の展示にはどうもそれらしい説明がない。岡本太郎のデッサンはたくさん並んでいたのだけれど。細部の展示説明が全部見られていなかったのでどこかにはあったのかも知れない。

そこで,Kindleで新潮文庫版のやぶれかぶれ青春記・大阪万博奮戦記を入手した。前者のやぶれかぶれ青春記は旺文社文庫で読んてはちゃめちゃに面白いはずだった。が,どうも記憶の内容が違っているような気がする。いや面白いのだけどもっとほろ苦いものだった。

さて,大阪万博奮戦記によれば,小松左京と万博のかかわりは次のようなものだ。
・1964年:梅棹忠夫,加藤秀俊らと「万国博を考える会」スタート
・1965年:大阪千里での万国博開催決定,「考える会」の総会開催,テーマ委員会
・1966年:サブテーマ委員会,上記メンバーとカナダ・アメリカ・メキシコ視察
・1967年:岡本太郎と個人契約によりテーマ展示サブブロデューサー(地下展示)
・1968-9年:地下展示のための海外民俗資料収集(後の民族学博物館へ)
あれ,肝腎の生命の樹のアイディアに関する具体的な話がない。

しかたがないので,古本の小松左京自伝を購入した。日本経済新聞社の私の履歴書に加筆したものだ。71ページに次の記述があった。「太陽の塔,つまりテーマ館の中の展示を岡本さんと考えた。DNAの一兆倍ぐらいの模型を作り,生物の進化の過程を見せることにした。映画の特撮も駆使してゴジラや恐竜なども現われ,最後に人間が登場する。高さ四十五メートル。「生命の樹」と名づけた」

若干違うような気もする。DNAの拡大模型はないのかもしれないし,ゴジラの映画もあったかどうか。それでも単細胞生物から人類が誕生するまでを,下から原生類時代,三葉虫時代,魚類時代,両生類時代,爬虫類時代,哺乳類時代にわけて,代表的な生物の模型によって表していた。


写真:現在の太陽の塔の中の生命の樹(2025.9.16撮影)


[2]第1回「万国博を考える会総会」開催60年(小松左京ライブラリ)

2025年9月28日日曜日

優勝確率

千秋楽前日9月27日のNHK相撲解説は伊勢ヶ濱(輝ノ富士)だった。大の里と豊昇龍がそれぞれ13勝1敗と12勝2敗で千秋楽を迎えることになった。NHKのアナウンサーが伊勢ヶ濱にどちらが優勝する可能性が高いでしょうかと尋ねたところ,勝負は確率の問題(これまでの対戦成績とか,1勝差があるとか)ではないという趣旨でアナウンサーの誘導尋問にはのらなかった。

確かにそういう気持ちはわからなくないのだけれど,凡夫としてはその確率が気になるものである。そこで,ChatGPTにきいてみた。

Q(koshix):
今場所の千秋楽対戦,これまでの相撲内容や過去の対戦成績を踏まえ,大の里と豊昇龍のそれぞれの優勝する確率を求めてください。

A(ChatGPT-5):
前提と手順を明確にします。千秋楽の時点で「大の里13–1、豊昇龍12–2」で直接対決(勝てば豊昇龍は優勝決定戦へ)という状況です。よって“1番で決まる大の里”対“2連勝が必要な豊昇龍”という構図になります。成績と対戦成績の最新確認:秋場所の番付ページで大の里13–1・豊昇龍12–2、千秋楽に両横綱が当たる並びが確認できます。
 また両者の直接対決は概ね「豊昇龍が6–2でリード(うち1番は不戦勝とする指摘あり)」という整理が各所で共有されています。

1.推計モデル(シンプル・ブレッドリー=テリー近似)
1番の対戦確率を p = P(豊昇龍が大の里に勝つ確率) とおきます
○優勝確率は
 ・大の里:1番で勝てば即優勝、負けても“決定戦”で勝てば優勝 ⇒ 1-p^2
 ・豊昇龍:本割に勝ち、さらに決定戦でも勝つ必要 ⇒ p^2
○p の基準は「直接対戦」と「今場所の出来」を合わせて設定:
・直接対戦6–2(不戦勝を除くと実質6–1という見立ても)からは p は 0.75〜0.85 寄り。
・ただし今場所は内容・体勢で大の里がやや優勢(13–1 vs 12–2)で、直近フォーム補正を入れて p を 0.65 前後に弱めるのが妥当と判断。

2.結論(中心値と感度)
中心仮定 p = 0.65 のとき:
・大の里の優勝確率:1-0.65^2 = 1-0.4225 =0.5775 →約57.8%
・豊昇龍の優勝確率:0.65^2 =0.4225 = 約42.3%
感度(p を動かした場合):
・p = 0.60 → 大の里 64%/豊昇龍 36%
・p = 0.70 → 大の里 51%/豊昇龍 49%
・参考(H2H を強く重視、p = 0.75)→ 大の里 43.8%/豊昇龍 56.3%
※不戦勝を除外し p ≈ 0.86 と極端に置くと豊昇龍有利になりますが、今場所の出来を無視するため現実的でないと見ます。

3.補足
・本推計は「本割と決定戦で p が同程度」「独立同分布」という簡略仮定に基づきます。実際には“本割での組み手・立合いの学習効果”や“疲労・怪我”で2番目の p が動く可能性があります。
・とはいえ“豊昇龍は2連勝が必要”という構造自体が大の里に有利で、p が0.70を超えない限り大の里が確率的優位です。千秋楽の一番の p をどう評価するか(H2H重視か、今場所の出来重視か)で最終値が変わります。

参照:秋場所の星取り・対戦状況(13–1 vs 12–2、千秋楽カード)、および両者のH2H(6–2)に関する言及。

必要なら、決まり手別・体勢別の過去対戦から p をもう少し精緻化(例:寄り・押し限定、投げ限定の局面確率を分解)して再計算もできます。

Q(koshx):
H2Hってなんですか。

A(ChatGpt-5):
はい、ご質問ありがとうございます。
H2H はスポーツ統計でよく使われる略語で、
Head to Head(ヘッド・トゥ・ヘッド)=「直接対戦成績」 のことを指します

1.相撲での使い方
例えば「大の里 vs 豊昇龍の H2H は 6–2」といえば、これまでの直接対戦が大の里2勝・豊昇龍6勝という意味です。
星取表の合計成績(13–1とか12–2)とは別に、一対一で戦ったときの相性や実績を見るときに参考にします。

2.補足
・H2H はテニス・野球・サッカーなどでも使われます。
・相撲では「力士ごとの過去の星取表」から容易に計算でき、直近の調子とは別に相性データとして扱われます。

今回の大の里と豊昇龍の分析で「H2H = 6–2」と言ったのは、過去の直接対戦成績を指していました。
ご希望なら、相撲に特化した H2Hの活用法(予想や分析での意味合い) も整理してご説明しますが、続けて解説しましょうか?



図:ほとんど似ていない大の里対豊昇龍,仕切り線もおかしい(ChatGPT-5による)


P. S. 本割ではあっけなく豊昇龍が大の里を押し出してしまった。優勝決定戦では大の里が豊勝龍の上手投げに負けずに体を預けて勝った。物言いはついたもの五回目の優勝。

2025年9月27日土曜日

ロビンソン図法

YouTubeで世界地図の話題があった。世界地図のパターンとしては,(1) 日本が中心で右が太平洋をはさんで米大陸,左が欧州アフリカ,(2) 欧州アフリカが中心で左に米大陸,右がアジア日本,(3) アメリカが中心で,左にアジアの東半分,右に欧州アフリカとアジアの右半分,とある。アメリカの小学校だと(3)らしい。日本だと(1)だ。概ねの世界標準は(2)だと。

しかしそれよりも気になるのは,メルカトル図法の歪みだ。シベリアとカナダとグリーンランドがやたらと拡大される。小学校ではこの地図を画用紙に何度も描いて社会の勉強をしていた。そこで正積図法に何かないかと調べていると,あまり聞いたことがないNell-Hammer図法がお薦めされた。

さっそくChatGPT-5に「SVG図を作って」というとHTMLファイルが返ってきた。どうもごちゃごちゃしているので描画の肝の部分がどこかを教えてもらった。すると,

A(ChatGPT-5):
このHTMLファイルで「世界地図を描画する肝」となる部分は、JavaScript内のD3.jsとTopoJSONを使った処理です。特に以下の要素がポイントです

1.投影法の指定
const projection = d3.geoNellHammer();
const path = d3.geoPath(projection);
ここで Nell–Hammer図法 を指定しています。
d3.geoPath(projection) によって、地理データをSVGパスに変換できるようになります。

2.データの読み込みと変換
const url = "https://cdn.jsdelivr.net/npm/world-atlas@2/countries-110m.json";
const world = await fetch(url).then(r => r.json());
const countries = topojson.feature(world, world.objects.countries);
const borders   = topojson.mesh(world, world.objects.countries, (a,b) => a !== b);
Natural Earth → world-atlas 由来のTopoJSONを読み込み。
topojson.feature で国境データをGeoJSONに変換。
topojson.mesh で隣接国間の国境線を抽出。

3.実際の描画処理
oceanLayer.append("path")
  .attr("class", "ocean")
  .attr("d", path({type:"Sphere"}));

landLayer.selectAll("path.land")
  .data(countries.features)
  .join("path")
  .attr("class", "land")
  .attr("fill", (d,i) => palette[i % palette.length])
  .attr("d", path);

borLayer.append("path")
  .attr("class", "borders")
  .attr("d", path(borders));
海(Sphere), 陸地(国ごと), 国境線 をSVGパスとして追加。
path(...) がD3によって座標を投影→SVGパス文字列に変換します。

4.レンダリング制御
function fitProjection(m) {
  projection.fitExtent([[m, m], [W - m, H - m]], { type: "Sphere" });
}
余白(marginInputで指定)を考慮して、投影範囲を A4サイズ (297×210mm) にフィットさせています。

5.まとめると:
肝は d3.geoNellHammer() 投影と d3.geoPath の組み合わせであり、
TopoJSONから取得した国データを path 関数を通してSVGに描画する部分が中核です。

ご希望なら、この「肝」だけを抜き出した最小限のサンプル(例えば海と国だけ表示するコード)を書き出しましょうか?

で,いちおうできたのだけれど,他の図法はどうなっているのだ。簡単なことで, 投影法の指定のconst projection = d3.geoNellHammer(); の所を変えればいいだけだ。メルカトル図法(d3.geoMercator()),ロビンソン図法(d3.geoRobinson()),モルワイデ図法(d3.geoMollweide()),サンソン図法(d3.geoSinuMollweide();),正距方位図法(d3.geoAzimuthalEquidistant().center([0, 90])),正射図法(d3.geoOrthographic().rotate([0, -30]))

これらを切り替えられるようなhtmlの製作を依頼したところ,この世界地図ページができた。SVGファイルもダウンロードできる。この中で一番よさげなロビンソン図法は妥協の産物で,正積でも正方位でもないけれどまあまあみやすい。


図:ロビンソン図法の場合


あれもできます,これもできますと提案してきたので,はいはいと言っているうちになんだが大層なものができてしまった。うまく表示されなかったので文句をいうとすぐに修正してくれた(できあがった世界地図はこれ,視点の緯度経度なども変更できる優れもの)。うーん,この環境でのプログラミング教育とはいったい・・・。


2025年9月26日金曜日

階段

人間ドック(3)からの続き

今年の人間ドックで指摘されたマンションの階段の価値と効用。

iPhoneの「ヘルスケア:上った階段」で,日々の階段の昇段数(単位は階)がわかる。手元のiPhoneでは2016年以降の記録がある。2016-2018の在職中の最後の3年間の平均は16階/日,退職後で非常勤講師として数コマもっていた3年間(コロナの年を除く)の平均は8階/日と半分になった。

ところが,2024年,70歳を越えて非常勤講師も終った年は,5階/日とかつての1/3にまで減ってしまっていた。今年の人間ドックで発破をかけられてからは,意識して階段を利用するようになったので,この3ヶ月の平均は10階/日までに回復したけれどまだまだ。

当初は1階から10階までの9階分(ヘルスケアの7階相当)登るのに2回ほど休憩が必要だった。最近,登り方を変えると少し楽に登れるようになった。それを示すのが下図だ。青がかつてのコース,赤が現在のコースであり,それぞれ平均登坂角が23.7度と13.7度である。

図上のユニットの9周分,図下のユニットの18回分で1階から10階まで登れる。垂直移動距離は23m(1.26m×18),水平移動距離は青で45m(2.5m×18),赤で81m(4.5m×18)となる。所要時間(赤)は135秒だ。(階段幅1.1m,外半径1.2m,赤軌道半径0.95m,青軌道半径0.35m,階段幅0.25m,階段高0.18m,段数7×2×9=126)



図:マンションの階段とその登り方

2025年9月25日木曜日

金沢都ホテル

金沢都ホテルが2017年に閉業して跡地が更地になってもう8年になる。金沢駅前の一等地なので,いつになったら再開発が進むのかと思っていた。このほど金沢駅東地域(59ha=金沢駅周辺区域+都市軸区域)が都市再生緊急整備地域に指定され(高さ60m制限が解除される),近鉄不動産から金沢市と石川県に官民複合ビル開発の提案があった。

これをもとに,ChatGPT-5 に具体的な提案をしてもらった。
Q(koshix):
調査をお願いします。金沢駅前の都ホテルの跡地の再開発で近鉄不動産が官民複合ビル開発の提案をしらたしいのですが,その詳細を教えてください。

A(ChatGPT-5):
(回答略)

Q(koshix):
金沢には近江町市場や兼六園,金沢城趾,江戸時代の武家屋敷跡,伝統工芸品工房,ひがし茶屋街など歴史的文化的な観光地以外にも,金沢21世紀美術館,石川県立図書館などのモダンな情報拠点もあります。このような地域の特性を踏まえて,駅前の官民複合ビルの新しくてユニークなコンセプトデザインを提案してください。なるべく思いもかけないアッと驚くようなものを期待しています。

A(ChatGPT-5):
(回答略) 
Q(koshix):
なかなかおもしろい3つのコンセプトでしたけれど,もう少し深く真剣に工夫して熟慮のうえ大胆に突っ込んでかつリアルなイメージがあふれるように考えて見てもらえませんか。

A(ChatGPT-5):
(回答略)

Q(koshix):
いやいや,3つのプロポーザルを具体化してほしいのではなくて,もっと別の観点から新しい提案ができないかという意味でした。参考資料もつけておきます。 細かい数字はいらないので,ゆたかな言葉で新しい2-3のコンセプトを創造して語ってください。

A(ChatGPT-5):
ありがとうございます。いただいた参考資料([1])をふまえると、金沢市が都市再生で掲げているキーワードは「骨格となる都心軸の再興」「伝統と創造の調和」「学都」「木の文化都市」「ウォーカブル」「歴史都市」などでした。これを起点に、既存の延長線ではなく「思いもかけない」観点から、あえて大胆に発想してみます。

コンセプト1:「呼吸する都市の森」
金沢駅前に立ち上がるのは、単なるビルではなく「都市が呼吸する森」。
外壁には木質素材とガラスを織り交ぜ、昼は木立のように陰影を生み、夜は樹冠が光の森となって街路を包む。内部の低層部は市民が自由に出入りできる「屋内林床広場」として、雨の多い金沢でも四季を感じられる緑の空間を提供。
上層はホテルや研究施設だが、吹き抜けを貫く「都市樹幹」が上下をつなぎ、空気循環や雨水利用を可視化する。まさに「木の文化都市」を体現し、訪れる人は都市の中心で自然に抱かれる体験を得る。

コンセプト2:「知と工芸の灯台(Beacon of Craft & Knowledge)」
北陸新幹線で到着した人を最初に迎えるのは、未来に向けて輝く「知の灯台」。
建物の上層部はガラスの灯火塔となり、時間ごとに色や模様が変化し、市内の工芸職人や学生がデザインに参加する「参加型光景観」を演出。
低層には「工芸アトリウム」があり、九谷焼・金箔・加賀友禅などの実演や展示が行われ、訪問者は工芸の創造性に触れる。中層は大学・研究機関・企業の共創拠点であり、金沢を「学都」として再び可視化する。
このビル自体が「伝統と知の実験場」となり、駅前は世界の人材と文化が交流する灯火となる。

コンセプト3:「雨と光の劇場」
金沢の気候を逆手にとる発想。雨の多さを「不便」ではなく「魅力」に変換する。外壁に雨水を導く透明な水路を設け、降雨に応じてファサードが光り奏でる「レイン・インスタレーション」を実現。低層広場では霧や水膜がスクリーンとなり、観光・芸術イベントの舞台に。中層には「市民のためのレインラウンジ」があり、ガラス越しに流れる水を眺めながら静かに過ごせる。上層のスカイラウンジでは、夜景とともに「雨の光」が都市全体を舞台にした劇場に変える。“雨を待ち望む街”という新しい都市イメージを発信する。

まとめ
・呼吸する都市の森:自然と調和し、駅前が「都市林」に。
・知と工芸の灯台:工芸・学術の拠点が光を放ち、世界に開く。
・雨と光の劇場:気候を魅力に変えるインスタレーション都市装置。
いずれも金沢の特性を活かしつつ、従来の「駅前高層複合ビル」の枠を超え、市民・観光客双方を驚かせる体験の装置となります。 
これら3つのうち、さらに膨らませてイメージ図や物語的なシナリオに落とすなら、どの案を優先したいですか?



図:とっても微妙な金沢駅前再開発ビルのイメージ(ChatGPT-5が提案)

金沢都ホテルは1981年に我々の結婚式が行われたところだ。その数年前には高校のESSの同期の高橋裕之君の結婚式もあった。子どものころ,おばあちゃんや親戚家族一同でブイヤベースを食べに行ったこともある。はじめてみるフランベにびっくりした。地下にはロキシーという映画館も。アラビアのロレンスをみたのはここか?

2025年9月24日水曜日

三十三間堂

NHKのブラタモリで京都の三十三間堂(蓮華王院本堂,1164/1266-)が特集されていた。平安時代末期の創建だが,火災にあって鎌倉時代に再建されたのが現在の建物(全長118m)だ。あの忌まわしい大屋根リングができるまでは日本一の長さの木造建造物だったが,今は第2位。全体の1/10の200m分を保存するというので今後数十年は第2位のままになる。100年も経てば1位に復活するだろう。

そのなかで,京都市内では応仁の乱(1467-1477)で町全体が燃えてしまい,それ以前から今まで残っているのは三十三間堂を含めて4つしかないという話に驚いた。そんなものなのか。早速ChatGPTやGeminiやClaudeやPerplexityやgrkや皆に聞いてみたが,どうも正確な情報がわからない。結局,醍醐寺 五重塔(951),大報恩寺(千本釈迦堂)本堂(1227),蓮華王院(三十三間堂)本堂(1266〈再建〉),法観寺(八坂の塔)五重塔(1440)というところに落ち着いた。

それでは全国での古い建造物はどうなっているのかということで,各生成AIにきいてみるのだけれど,どれも一長一短でフェイク情報が混じってしまう。出力を数回にわたり多段で蒸留した結果,ChatGPT-5とGemini 2.5 Pro の結果が収束した(正しいかどうかは別だ)。

Q(koshix):
以下のリストが正しいかどうか判定してください。また,このリストに無いもので条件を満たすものがあれば指摘してください。なお,リストには通し番号をつけて,年号が推定できるものはなるべく入れてください。

元の質問: 日本の歴史的建造物でできてから800年以上の歴史を持つものを古い順に並べたリストをつくってください。なお,創建時が条件を満たしていても消失したものは含めません。再建時が条件を満たしていればOKとします。大きな寺院の一部の塔頭などで一定の規模があればそれらも含めます。

A(ChatGPT-5 Thinking):
前提と進め方:ご提示の条件(①現存、②創建でなく“現存建物の成立”が1225年以前=今年2025年時点で800年以上、③再建でも可、④塔頭も一定規模なら可)に沿って、各項目の年代・現存性を一次情報・公的機関・寺社公式等で突き合わせました。結果は①リストは概ね妥当、②抜けている重要物件がいくつか、③一部で補足・厳密化(年次表現の明確化)が必要――の3点です。下に「修正済み通し番号リスト(古い順)」を示し、追補分は★で明示します。各行に1文メモを付しています。出典は要所で併記しました。

修正済みリスト(古い順,★は省略)
1.法隆寺 西院伽藍(金堂・五重塔・中門・回廊)|7世紀末〜8世紀初頭
世界最古級の木造建築群として現存(ユネスコ登録群の中核)。
2.法起寺 三重塔(奈良)|706年
現存最古の三重塔の一つ(飛鳥〜奈良移行期の作)。 
3.唐招提寺 経蔵・宝蔵(奈良)|8世紀前半
現存する校倉造の代表的遺構。 
4.薬師寺 東塔(奈良)|730年
奈良時代唯一現存の三重塔で「凍れる音楽」と称される。
5.法隆寺 東院 夢殿(奈良)|8世紀中頃
聖徳太子供養の八角円堂(奈良期建立)。 
6.東大寺 法華堂(三月堂)(奈良)|8世紀中頃
東大寺で現存最古の堂。 
7.栄山寺 八角堂(奈良)|760–764年頃
奈良時代屈指の八角堂(国宝)。 
8.東大寺 正倉院 宝庫(奈良)|8世紀後半
天平の校倉造高床式宝庫(聖武天皇ゆかりの宝物蔵)。
9.唐招提寺 金堂(奈良)|8世紀後半
天平建築の代表堂宇。 
10.唐招提寺 講堂(奈良)|8世紀後半(平城宮朝集殿の移築)
宮殿建築遺構が寺院講堂として現存。 
11.新薬師寺 本堂(奈良)|8世紀後半
奈良期現存の本堂で十二神将を囲繞安置。
12.當麻寺 東塔(奈良)|奈良時代中期(8世紀)
古代の東西双塔が揃って現存する唯一の例の一方塔。
13.當麻寺 西塔(奈良)|平安初期(9世紀初頭)
双塔のもう一方(平安初頭建立)。
14.室生寺 五重塔(奈良)|9世紀初頭(8世紀末説あり)
屋外五重塔で最小規模・古式の名塔。
15.室生寺 金堂(奈良)|9世紀前半(※中世修理あり)
山岳伽藍に残る古様の堂宇。
16.醍醐寺 五重塔(京都)|951年
京都府最古の木造建築。
17.平等院 鳳凰堂(京都)|1053年
浄土庭園の中心堂(十円硬貨の意匠)。
18.宇治上神社 本殿(京都)|1060年頃
現存最古の神社本殿。
19.石山寺 本堂(滋賀)|1096年(再建)
紫式部ゆかり、平安末再建本堂が現存。
20.浄瑠璃寺 本堂(京都)|1107年
九体阿弥陀を安置する横長本堂。 
21.鶴林寺 太子堂(兵庫)|1112年
兵庫県最古級の現存木造建築。 
22.中尊寺 金色堂(岩手)|1124年
奥州藤原氏の阿弥陀堂(皆金色)。
23.石上神宮 拝殿(奈良)|1135年(移築)
現存最古の拝殿建築。
24.白水阿弥陀堂(福島)|1160年
平安末の阿弥陀堂と浄土庭園。
25.一乗寺 三重塔(兵庫)|1171年
平安末の代表的三重塔(国宝)。
26.富貴寺 大堂(大分)|12世紀後半
九州最古級の現存木造仏堂。
27.浄土寺 浄土堂(兵庫・小野)|1192年
阿弥陀三尊(快慶)を安置する檜皮葺大堂。
28.高野山 不動堂(和歌山)|1197年
高野山で最古の現存堂宇。
29.東大寺 南大門(奈良)|1199年(再建)
大仏殿正門、金剛力士像で著名。
30.興福寺 北円堂(奈良)|1210年(再建)
鎌倉初期再建の八角円堂(国宝)で現存。 

A(Gemini Pro 2.5):
再度チェックいたしました。この修正版リストは、ご提示の条件に沿って非常に綿密に調査されており、ほぼ完璧な内容と言えます。素晴らしいリストです!




図:三十三間堂通し矢図(伝円山応挙筆,文化遺産オンラインから引用)

2025年9月23日火曜日

Nano Banana

Google GeminiのNano Bananaが凄いという話で,アクセスすると"NEW! Google 最高の画像モデルである Nano Banana で画像編集をお試しください" とでてくる。ところが,何度試してもなかなかうまくいかない。

あれこれしているうち,ようやく今日になって画像をアップロードしたものから編集することができた。Gemini 2.5 Pro の設定だったのであっというまに本日のリミットに達してしまった。



図:Nano Bananaによる画像編集の例

Q(koshix):
石を銅に変えてください。(応答はあるが画像生成は無し)
Q(koshix):
背景を野原にしてください。(さきほどの結果も含めて画像が生成された。OK)
Q(koshix):
姿形を立ち上がった奈良の大仏の顔にしてください。(OK)
Q(koshix):
奈良の大仏の顔のお地蔵さんを奈良の鹿にまたがらせてください。(OK)
A(Gemini 2.5 Pro):
2.5 Pro の上限に達しました。9月23日 11:50 までお待ちください。Google AI Pro にアップグレードすると、上限が引き上げられます。

そこで,Gemini 2.5 Flashに切り替えて続けてみた。

Q(koshix):
鹿を神の使いの白い鹿にしてください。(応答はあるが画像生成は無し)
Q(koshix):
背景の空の部分を2/3ほどに増やしてください。(OK)
Q(koshix):
鹿に乗った銅像にもっとフォーカスして迫ってください。(OK)
Q(koshix):
空の面積を半分くらいにして鹿の足下まで全体入れて,もう少し鹿によってください。(×)
・・・

以下何度お願いしても,わかったというばかりで全く改善されない状態が続いてしまった。


図:これ以上修正がきかず収束した画像(Gemini 2.5 Flash - Nano Bananaなのか?)


P. S. その後,数時間置いてから再度チャレンジした。
Q(koshix):
鹿の足下が見切れていますので,全体像が入るようにしてください。なおかつ,空の割合を今の半分ぐらいにして,白鹿とそれに乗った地蔵菩薩もっとズーム拡大してください(カメラが対象によるように)。(応答はあるが画像生成は無し)
Q(koshix):
今の画像を生成してください。(さきほどの画像が生成された。OK)
Q(koshix):
上1/3を夕焼け空にして, 下2/3を草原にして,白鹿とそれに乗った地蔵菩薩さらにズーム拡大してください。(OK)
Q(koshix):
やはり,青空に戻して,下半分は野原にしてください。(野原では伝わらなかった,×)


図:再チャレンジした画像(Nano Banana のはず)

2025年9月22日月曜日

国勢調査

2025年は5年おきの国勢調査の年だ。9月20日に自治会の役員さんが調査票を持ってきた。インターネットでも回答できる。5年前はどうだったかと自分のブログや記憶を確認したが痕跡はなかった。説明には令和2年(2020年)度から導入されているとされている。

調査票は10月1日から10月8日に回収されるが,インターネット回答は9月20日から回答できる。iPhoneでQRコードを読み込むと何の問題もなくスイスイと最後まで進めた。あの万博のポンコツシステムとはエライ違いだ。16項目あるけれど,無職で現在地に20年以上住んでいる場合は,10項目目まで十分だ。ややこしい従業地や勤め先の記述も不要である。



写真:国勢調査のお願いの封筒(2025.9.20撮影)

2025年9月21日日曜日

9月20日(2)

Juliaの日時処理からの続き

5年前の国勢調査の記事がないかと調べていたら,それはなくて5年前の自分の誕生日の記事が発掘された。誕生日の曜日を調べるJuliaプログラムの話だ。5年も経っているからもう一度実行してみようと,Jupyterではすぐ動いたが,コマンドラインでどうするのか迷った。

プログラムを実行形式にchmodして,頭に#!/usr/bin/env julia(あるいはjuliaの絶対パス)を書けばいいだけなのだけれど,!に気がつかず,シェルスクリプトのコメントと解釈されてエラーがでた。しかし耄碌しているのですぐに原因に気付けずChatGPT-5にたよることになる。

そんなこんなで,過去の習作コードをChatGPT-5に投げてバイブコーディングして得られたのが次の結果とコードである。プログラミングとはAIとの対話のことだった。

 koshi@mba2020 ~ % ./birth.jl

【基礎情報】

今日                : 2025年9月21日(日曜日)

誕生日              : 1953年9月20日(日曜日)


【差分と年齢】

生誕からの経過日数 : 26299日

満年齢              : 72歳


【年ごとの誕生日一覧】(*は日曜)  ※最終年:2025年

1953年9月20日(日曜日)  0歳  *

1954年9月20日(月曜日)  1歳  

1955年9月20日(火曜日)  2歳  

1956年9月20日(木曜日)  3歳  

1957年9月20日(金曜日)  4歳  

1958年9月20日(土曜日)  5歳  

1959年9月20日(日曜日)  6歳  *

1960年9月20日(火曜日)  7歳  

1961年9月20日(水曜日)  8歳  

1962年9月20日(木曜日)  9歳  

1963年9月20日(金曜日)  10歳  

1964年9月20日(日曜日)  11歳  *

1965年9月20日(月曜日)  12歳  

1966年9月20日(火曜日)  13歳  

1967年9月20日(水曜日)  14歳  

1968年9月20日(金曜日)  15歳  

1969年9月20日(土曜日)  16歳  

1970年9月20日(日曜日)  17歳  *

1971年9月20日(月曜日)  18歳  

1972年9月20日(水曜日)  19歳  

1973年9月20日(木曜日)  20歳  

1974年9月20日(金曜日)  21歳  

1975年9月20日(土曜日)  22歳  

1976年9月20日(月曜日)  23歳  

1977年9月20日(火曜日)  24歳  

1978年9月20日(水曜日)  25歳  

1979年9月20日(木曜日)  26歳  

1980年9月20日(土曜日)  27歳  

1981年9月20日(日曜日)  28歳  *

1982年9月20日(月曜日)  29歳  

1983年9月20日(火曜日)  30歳  

1984年9月20日(木曜日)  31歳  

1985年9月20日(金曜日)  32歳  

1986年9月20日(土曜日)  33歳  

1987年9月20日(日曜日)  34歳  *

1988年9月20日(火曜日)  35歳  

1989年9月20日(水曜日)  36歳  

1990年9月20日(木曜日)  37歳  

1991年9月20日(金曜日)  38歳  

1992年9月20日(日曜日)  39歳  *

1993年9月20日(月曜日)  40歳  

1994年9月20日(火曜日)  41歳  

1995年9月20日(水曜日)  42歳  

1996年9月20日(金曜日)  43歳  

1997年9月20日(土曜日)  44歳  

1998年9月20日(日曜日)  45歳  *

1999年9月20日(月曜日)  46歳  

2000年9月20日(水曜日)  47歳  

2001年9月20日(木曜日)  48歳  

2002年9月20日(金曜日)  49歳  

2003年9月20日(土曜日)  50歳  

2004年9月20日(月曜日)  51歳  

2005年9月20日(火曜日)  52歳  

2006年9月20日(水曜日)  53歳  

2007年9月20日(木曜日)  54歳  

2008年9月20日(土曜日)  55歳  

2009年9月20日(日曜日)  56歳  *

2010年9月20日(月曜日)  57歳  

2011年9月20日(火曜日)  58歳  

2012年9月20日(木曜日)  59歳  

2013年9月20日(金曜日)  60歳  

2014年9月20日(土曜日)  61歳  

2015年9月20日(日曜日)  62歳  *

2016年9月20日(火曜日)  63歳  

2017年9月20日(水曜日)  64歳  

2018年9月20日(木曜日)  65歳  

2019年9月20日(金曜日)  66歳  

2020年9月20日(日曜日)  67歳  *

2021年9月20日(月曜日)  68歳  

2022年9月20日(火曜日)  69歳  

2023年9月20日(水曜日)  70歳  

2024年9月20日(金曜日)  71歳  

2025年9月20日(土曜日)  72歳    

ChatGPT-5 Thinking が提案してきたコードは以下のとおりである。かなり修正してもらった。

#!/usr/bin/env julia

# birth.jl


using Dates


# --- ヘルパ ---

const WDAY_SHORT = ["月","火","水","木","金","土","日"]

const WDAY_LONG  = ["月曜日","火曜日","水曜日","木曜日","金曜日","土曜日","日曜日"]


fmt_date_ja(d::Date; long_wday::Bool=true) = string(

    Dates.format(d, dateformat"yyyy年m月d日"), "(",

    (long_wday ? WDAY_LONG : WDAY_SHORT)[dayofweek(d)], ")"

)


# 引数: [YYYY MM DD [ENDYEAR]]

function parse_args()

    if length(ARGS) == 0

        return Date(1953, 9, 20), year(Dates.today())

    elseif length(ARGS) == 3 || length(ARGS) == 4

        b = Date(parse(Int, ARGS[1]), parse(Int, ARGS[2]), parse(Int, ARGS[3]))

        lasty = (length(ARGS) == 4) ? parse(Int, ARGS[4]) : year(Dates.today())

        return b, lasty

    else

        error("使い方: ./birth.jl  または  ./birth.jl YYYY M D  [ENDYEAR]")

    end

end


function list_birthdays(birth::Date, last_year::Int)

    last_year = max(last_year, year(birth))  # 下限は誕生年

    for y in year(birth):last_year

        d = Date(y, month(birth), day(birth))

        age = y - year(birth)

        star = (dayofweek(d) == 7) ? "*" : ""   # 7 = 日曜

        println(fmt_date_ja(d; long_wday=true), "  ", age, "歳  ", star)

    end

end


# --- 本体 ---

birthday, list_until = parse_args()

today = Dates.today()


println("【基礎情報】")

println("今日                : ", fmt_date_ja(today; long_wday=true))

println("誕生日              : ", fmt_date_ja(birthday; long_wday=true))


println("\n【差分と年齢】")

days_elapsed = Dates.value(today - birthday)

age_years = year(today) - year(birthday) - (Date(year(today), month(birthday), day(birthday)) > today ? 1 : 0)

println("生誕からの経過日数 : ", days_elapsed, "日")

println("満年齢              : ", age_years, "歳")


println("\n【年ごとの誕生日一覧】(*は日曜)  ※最終年:", list_until, "年")

list_birthdays(birthday, list_until)