AIの3原則

 芳賀高洋さんのFacebookでAIについての話題が続いていた。その中で，美馬のゆりさんが学びに行ったスチュアート・ラッセルの著書「AI新生―人間互換の知能をつくる（Human Compatible）」が紹介されていた。DeepLでそのWikipediaのページを要約すると，次のように訳されるAIの3原則というのがあった。

1. 機械の唯一の目的は、人間の好みの実現を最大化することである。

2. 機械は、それらの好みが何であるかについて、最初は不確実である。

3. 人間の好みに関する究極の情報源は、人間の行動である。

なんだか意味不明だったので，GPT-4に聞いてみたところ，適確な回答が得られた。

Q: Stuart Russell の3原則について詳しく説明してください。

A: スチュアート・ラッセル (Stuart Russell) は、AIの安全性と倫理に関心を持つ著名な人工知能研究者であり、彼が提唱する3つの原則は、AIの開発と導入において考慮すべき重要な指針となっています。彼の3つの原則は以下の通りです。

1. 有益な目的の追求 (The Pursuit of Beneficial Goals)：

スチュアート・ラッセルは、AIが人間にとって有益な目的を追求するべきであると主張しています。これは、AIが人間の価値観や倫理観に沿って動作し、人間の福祉を向上させることを意味します。AIは、悪用されたり、人間に対して危害を与えたりすることのないよう、その目的が適切に設定されるべきです。

2. 人間の価値観の尊重 (Respect for Human Values)：

ラッセルは、AIが人間の価値観を尊重し、それに従って行動することが重要であると主張しています。これは、人間の文化、信念、個人的な価値観を理解し、それに基づいて適切な判断を下すAIの開発を意味します。また、AIは人間の自主性を尊重し、決定を支援する一方で、最終的な選択肢は人間が行うことを尊重するべきです。

3. 透明性と理解可能性 (Transparency and Understandability)：

AIシステムは、その動作や決定プロセスが透明であり、人間にとって理解しやすい形で開示されるべきです。これは、AIがどのように働いているのか、どのような基準で決定を下しているのかを明確にし、それによって人間が信頼を寄せられるようにすることが重要であるということを意味します。

スチュアート・ラッセルの3つの原則は、AI開発者や政策立案者にとって、AIの倫理的な開発と導入において考慮すべき重要なガイドラインを提供しています。これらの原則に従ってAIが開発されることで、人間の福祉を最大限に向上させることができるとされています。

GPT-4が優秀なので，本や論文を読むかわりに，その要約を調べてもらうことが多くなった。その結果，このブログに自分の考えをまとめて書くという過程が，GPT-4の結果を引用するという，より安易で自分の手間を減らすことができることにどんどん置き換えられつつある。おいおい大丈夫か。こうして，自分の読解力も思考力も表現力も奪われていくのだった。これに年齢進行による惚けが加わるので，なんというか。

ところで，自分ではこの結果を原著にあたって確認していないのだけれど，大丈夫かな。

対話型AIと教育（１）

ChatGPTと教育（２）からの続き

OpenAIのGPT-4にAI対話システムの教育利用に関わるシナリオについて聞いてみた。ChatGPT Plus（$20/month）から使うことができるGPT-4だが，4時間ごとに100回のメッセージまでという制限条件がある。ユーザが増えたため，これが50回になったらしい。なお，GPT-4に聞いてみたところ，1回のメッセージというのはユーザとGPT-4の間の１往復の対話を指しているとのことだ。

Ｑ：GPT-4を学校教育の場で利用することには賛否両論があると思います。教育利用のためには，GPT-4やそれを利用した学習アプリ＝チューターアプリをいつでも自由に長時間使うことができなければならないと思います。しかし，GPT-4を利用するためめの費用が高額であれば，経済的な格差が教育格差に直結する危険性もあります。学校教員が仕事を奪われる側面もあって，導入への抵抗が在るかもしれません。このような状況やあなたが持っている情報をふまえ，どのような段階を追ってLLMなどに基づくAI対話システムが教育の場に浸透していくか，考え得るシナリオを提示してください。

Ａ：教育の場でAI対話システムが浸透していくシナリオは、多くの要因が関与するため複雑ですが、以下に考え得る段階を示します。

１．認知度向上と技術検証:

まず、教育関係者や親御さん、学生などの認知度を向上させる必要があります。このために、GPT-4やAI対話システムの技術的優位性や教育に対する利点を広める活動が行われるでしょう。また、技術的な限界や倫理的な問題についても検証し、適切なガイドラインや法規制を策定する必要があります。

２．パイロットプロジェクト:

次に、一部の学校や教育機関でパイロットプロジェクトが実施されるでしょう。これにより、AI対話システムの効果や問題点を具体的に評価し、改善策を検討することができます。

３．費用の削減とアクセスの平等化:

教育格差を防ぐために、AI対話システムの費用を削減し、より多くの人々がアクセスできるようにする必要があります。政府や企業が資金提供を行い、無料または低価格での提供を促進することが重要です。

４．教員との協働:

教員がAI対話システムと協働することで、教育の質を向上させることができます。教員はAI対話システムの導入に抵抗感を持つかもしれませんが、教育効果の向上や業務の効率化が見込まれるため、徐々に受け入れられるようになるでしょう。

５．カリキュラムへの統合:

AI対話システムが効果的であると認識された後、徐々にカリキュラムに組み込まれるようになります。これにより、学習者はAI対話システムを通じて知識やスキルを習得することが一般化されます。

６．継続的な改善と評価:

最後に、継続的な改善と評価が行われます。AI対

続けて

話システムの性能は、時間とともに向上していくでしょう。そのため、教育関係者は継続的にシステムを評価し、改善点を見つけ出す必要があります。また、教育環境や学習者のニーズが変化することを考慮し、システムが適切に対応できるようにアップデートを行います。

７．社会全体への浸透:

最終的に、AI対話システムは教育界だけでなく、社会全体に浸透していくでしょう。企業や団体がAI対話システムを活用することで、職場でのスキル向上や研修プログラムの効率化が期待できます。

８．国際協力と共有:

異なる国や地域での成功事例や問題点が共有されることで、より効果的なAI対話システムの導入が促進されます。国際的な協力により、教育の質を向上させるための共通の目標や基準が策定されることも期待されます。

９．新たな教育手法の開発:

AI対話システムが普及することで、新たな教育手法やアプローチが生まれるでしょう。これにより、従来の教育方法に限界がある学習者や特別な支援が必要な学習者に対しても、適切な教育が提供されるようになります。

10．柔軟な教育環境の実現:

最後に、AI対話システムの普及により、より柔軟で個別化された教育環境が実現されます。学習者は自分に合ったペースで学習ができ、教育機会が平等に提供される社会が目指されるでしょう。

GPT-4（２）

GPT-4（１）からの続き

OpenAIにおける対話APIの利用料金を定めているのはtokenという単位である。GPT-3におけるtokensについて によれば，1k tokens が750 wordにあたる。ところが，日本語の場合は，マルチバイト文字のためにこのルールがあてはまらず，「これはテストするための投稿内容です。」という22文字入力が27tokenになってしまう。1k tokens が 750字程度か。

OpenAIの価格リストによれば，gpt-3.5-turboで，\$0.002/1k tokens≒ 0.3円/1k tokensだったものが，gpt-4（32K context）では，\$0.06-0.12 / 1k tokens ≒ 9-18円 / 1k tokens に跳ね上がってしまった。10往復の対話で100〜200円となり，遠距離通話の公衆電話で10円玉がどんどん吸い込まれていくイメージに重なってしまう。

Googleでいくら検索しても，Twitterにいくら投稿してもお金を取られることはなかった。この従量課金される対話型AIシステムはいったいどうやって使えばいいのだろうか。あるいは，どのようなビジネスモデルを想定すれば，ほぼ無料でその恩恵に預かることができるのだろうか。そこで，GPT-4に聞いてみました。

Ｑ：GPT-4を日本語で利用する場合，英語で750word / 1k tokens のところが，約 750文字 / 1k tokens になってしまいます。これは日本語がマルチバイト文字であって，単語を切り出すのもむずかしいことによります。現在のドル円為替レートを考慮すると，1対話を1 k tokensとしても20円ほどかかります。10対話では 200円にもなってしまいます。このような高額の従量課金システムを前提とすれば，日本ではよほど裕福な人でなければ，自由にGPT-4を使えないことになります。どうすれば，この問題を解決することができるでしょうか。具体的なアイディアをいくつか出してください。

Ａ：この問題を解決するためのアイディアはいくつかあります。以下に具体的な提案を示します。

１．オープンソースAIモデルの開発:

GPT-4のような高額な商用モデルではなく、オープンソースのAIモデルを利用することで、コストを削減できます。オープンソースのAIモデルは無料で利用でき、コミュニティによって継続的に開発・改善されているため、品質も向上していくでしょう。

２．ローカルでのAIモデルの実行:

クラウドサービスでのAPI利用に依存せず、ローカル環境でAIモデルを実行することで、トークン数に対する制限や課金を回避できます。ただし、ハードウェアリソースが必要になるため、初期投資が高くなる可能性があります。

３．エコシステムの構築:

企業、学術機関、政府が連携し、AIモデルの利用コストを抑えるエコシステムを構築することが有効です。例えば、政府が資金提供を行ったり、企業が無料や低価格でAIモデルを提供することで、経済的な負担を軽減できます。

４．グループライセンスや教育機関向け割引:

GPT-4のような商用モデルを利用する場合でも、教育機関向けの割引プランやグループライセンスを提供することで、コストを抑えることができます。これにより、教育機関がAIモデルを導入しやすくなります。

５．より効率的なAIモデルの開発:

日本語のマルチバイト文字や単語の切り出しの問題に対処するために、より効率的なAIモデルを開発することが求められます。新しいアルゴリズムや技術を用いて、日本語に特化したAIモデルを開発することで、トークン数の制約を緩和できるかもしれません。

６．非同期型の利用:

対話をリアルタイムで行う必要がない場合、非同期型の利用に切り替えること

koshix@mac.com

続けて

で、コストを抑えることができます。例えば、学習者が質問を投稿し、AIモデルがオフピーク時間に回答を生成するように設定することで、リソースの効率的な利用やコスト削減が可能になります。

７．質問の最適化:

GPT-4を利用する際、より効率的に情報を得るために質問の最適化を検討します。具体的には、一度の質問で多くの情報を得られるように工夫することで、トークン数を節約し、コストを抑えることができます。

８．キャッシュ機能の利用:

過去に行った対話や回答をキャッシュ（一時保存）することで、同様の質問が再度投げられた際にAIモデルを利用せずに回答を返すことができます。これにより、トークン使用量を削減し、コストを抑えることができます。

９．クラウドファンディングやスポンサーシップ:

個人や学習者グループが、クラウドファンディングやスポンサーシップを通じて資金を集めることで、GPT-4の利用コストを補うことができます。これにより、より多くの人々がAIモデルを利用できるようになります。

10．低コストのAIモデルの利用:

GPT-4よりも低コストで提供されるAIモデルを活用することも一つの方法です。これらのモデルは、GPT-4ほどの性能はないかもしれませんが、それでも十分な学習効果が期待できる場合があります。また、これらのモデルを活用していくことで、将来的に性能が向上する可能性もあります。

［１］オープンAIが「GPT-4」を発表，性能向上も詳細は非公表に

GPT-4（１）

3月14日は円周率の日に加え，OpenAIがGPT-4を公式に発表した日になった。

落合陽一（1987-）の博士課程指導教員だった暦本純一（1961-）が「GUIの登場を越える衝撃だ」というのが，半年前の生成AIの誕生だ。堀江貴文（1971-）はGPT-4を見て，これは子供の（語学）教育に使えると断言している。全世代の専門家が！！となっているわけだ。

GPT-4の技術的内容については，GPT-4 Technical Reportに詳しい。それによると，

GPT-4は，画像とテキストを入力し，テキストを出力することができる大規模なマルチモーダルモデルであり，その開発について報告する。GPT-4は，多くの実世界のシナリオにおいて人間より能力が劣るものの，模擬司法試験に受験者の上位10％程度のスコアで合格するなど，様々な専門的・学術的ベンチマークにおいて人間レベルの性能を発揮することができる。GPT-4は，文書中の次のトークンを予測するために事前に学習されたTransformerベースのモデルであり，学習後のアライメントプロセスにより，事実の正確さや望ましい行動への忠実さを示すパフォーマンスが向上している。このプロジェクトの中核をなすのは，幅広いスケールで予測可能な振る舞いをするインフラと最適化手法の開発だ。これにより，GPT-4の1000分の1以下の計算量で学習したモデルから，GPT-4の性能の一部を正確に予測することができるようになった。

ソクラテス型家庭教師のサンプルでは，GPT-4が中学生レベルの連立方程式の解法を学生に教えている。GPT-4に対して「あなたは、常にソクラテススタイルで対応する家庭教師です。生徒に答えを与えるのではなく，生徒が自分で考える力を身につけるために，常に適切な質問をするようにします。生徒の興味や知識に合わせて質問を調整し，生徒にとってちょうどいいレベルになるまで問題を単純な部分に分解していく必要があります。」という指示を与えた後，UserとGPT-4の会話が進んでいく。ホリエモンをバカにしている場合ではなかった。どうしましょう。

図：GPT-4は多くの試験で8割を達成する（OpenAIから引用）

P. S. 同日，Googleは生成AI PaLMのAPIと，GmailやGoogle DocsへのSaaSによる生成AI機能の追加を発表している。

［１］GPT-4のすごさとその影響範囲について（逆瀬川）

円周率の日

円周率の分数近似（4年前）からの続き

3月14日は円周率の日だ。

PC-9801を導入して最初のころにBASICで円周率の計算の例題を入力して試してみた。参考書にあったのがマチンの公式だった。$4 \tan^{-1 }\frac{1}{5}- \tan^{-1}\frac{1}{239}=\frac{\pi}{4}$を級数展開して求めるもので，$\tan^{-1} 1 = \frac{\pi}{4}$より収束が良く計算時間も稼げる。それでも当時のBASICインタープリタでは1000桁の計算に多少時間がかかっていた。今では，MathematicaでN[Pi,1000000]とするだけで，0.28秒でMacbook Air M1 の画面に100万桁の円周率が表示される。

1980年代，まだ日本のベクトル型スーパーコンピュータに勢いがあった頃，東大大型計算機センターを舞台として，金田康正さんが円周率計算桁数の世界記録を更新し続けていた。かれらのグループの最後の輝きは，2002年にHITACHI SR8000により1兆桁を計算したというものだった。

その後，時代はPCによる計算競争に移ったが，現在の記録はやはり日本人が持っている。Google Cloudの技術者である岩尾エマはるかが，2019年に31兆4159億2653万5897桁を記録し，2022年には100兆桁に達した。チュドノフスキーの公式を用いた計算はGoogle Cloudで157日かけて実行された。

円周率の計算は，arctan型の何種類かの公式やガウス=ルジャンドルのアルゴリズムやラマヌジャン型公式が用いられることが多い。チュドヌフスキーの公式は次のようなものだ。$n$が一つ進むごとに14桁近く精度が増えていく。

$ \dfrac{1}{\pi}=12 \Sigma_{n=0}^{\infty} \dfrac{(-)^n (6n)!(545140134n+13591409)}{(3n)!(n!)^3 640320^{n+3/2}}$

これをさらにすすめたものに，ボールウェィンの公式があったので確かめたところ，Juliaの計算値で$n>=1$の場合がおかしい。公式が間違って印刷されているのかと思ったが，Mathematicaではうまくいく。結局，Juliaの変数の任意精度の取り扱いが間違っていた。こちらのほうは，$n$が一つ進むごとに24桁近く精度が増えていく。

$A=1657145277365+212175710912\sqrt{61}$

$B=107578229802750+13773980892672\sqrt{61}$

$C=(5280\,(236674 + 30303\sqrt{61}))^3$

$ \dfrac{1}{\pi}=12 \Sigma_{n=0}^{\infty} \dfrac{(-)^n (6n)!(A+B n)}{(3n)!(n!)^3 C^{n+1/2}}$

以下が問題のJuliaのコードである。

function pit(m)

s61 = sqrt(big(61))

A = 1657145277365 + 212175710912*s61

B = 107578229802750 + 13773980892672*s61

C = (5280*(236674 + 30303*s61))^3

#A = BigFloat(13591409)

#B = BigFloat(545140134)

#C = BigFloat((640320)^3)

sum = big(0)

    for n in 0:m

        n6=factorial(big(6*n))

        n2=factorial(big(n))^3

        n3=factorial(big(3*n))

        sum=sum+(-1)^n*n6/(n2*n3)*(A+B*n)/C^(n+1/2)

    end

return BigFloat(1/(12*sum))

end

bpi = big(pi)

println(bpi-pit(0))

println(bpi-pit(1))

println(bpi-pit(2))

println(bpi-pit(3))

p+11B核融合

核融合科学研究所（NIFS）のプレスリリースによると，大型ヘリカル装置（LHD）の磁場で閉じこめた陽子（軽水素イオン）とホウ素11の核融合反応で生成するα粒子を始めて観測した。p+11B->3αの反応では中性子は発生しないため先進的核融合燃料とよばれ，世界で初めての実証実験となった。

核融合といえば，フランスに設置されている国際熱核融合実験炉（ITER）だ。トカマク型の実証炉でエネルギー増倍比Ｑ=10，閉じ込め時間400秒，出力50万kWを目指し，2025年に初プラズマ達成，2035年にDT運転開始予定だ。

基本反応は，$^2_1 \mathrm{H} (2.014101)+ ^3_1 \mathrm{H}(3.016049) \rightarrow  ^4_2\mathrm{He} (4.008665)+ ^1_0\mathrm{n}(1.008665) + 17.588 \mathrm{MeV}$である。括弧内は原子質量（$\mathrm{u}=931.494\mathrm{MeV}$）である。反応前の重陽子とトリチウムが静止しているとして，重心系における反応後の中性子の運動量は，$pc=163\mathrm{MeV}$であり，中性子の運動エネルギーは，$T_n = \sqrt{pc^2+m_n^2c^4}-m_n c^2 = 14.03\mathrm{MeV}$となる。ここで，qcを与えて，Solve[Sqrt[(m_d c^2)^2 + (qc)^2] + Sqrt[(m_t c^2)^2 + (qc)^2] == Sqrt[(m_h c^2)^2 + (pc)^2] + Sqrt[(m_n c^2)^2 + (pc)^2] を解けば，pcが求まる。非相対論的な近似でよければ，放出エネルギーを質量比1:4の逆比に配分すれば運動エネルギーの価が得られる。

この14MeVの中性子が炉壁物質の結晶構造を破壊した上に放射化するので，これに耐えられる核融合炉の炉壁ができるかどうかが一番の課題だと思われる。無理じゃない？中性子による放射化は，核分裂生成物の長寿命放射性物質よりはマシかもしれないが，それでも中性子が湯水のように発生するのはかなり面倒な話だと思う。

一方，今回の実験のパートナーであるTAEテクノロジーズのp+11B非中性子核融合（aneutronic fusion）では，主反応は次のものであり，中性子を発生しない（副反応では発生しうる）。$^1_1 \mathrm{H} (1.007825)+ ^11_4 \mathrm{B}(11.009305) \rightarrow  3 ^4_2\mathrm{He} (4.008665) + 8.682 \mathrm{MeV}$。さらに，エネルギー取り出しは他の核融合炉や核分裂炉のような熱交換ではなく，逆サイクロトロン変換器による直接発電である。それにしても，エネルギー増倍比は，Ｑ=2.7-4.3（偏極陽子の場合）にとどまる。

昔の論文をみると，(p,n)反応，(α,n)反応，(γ,n)反応などの副反応経由での中性子生成もかなりあるらしい。レーザーやZピンチによる慣性閉じこめ核融合も結局中性子が問題なので，核融合だからといってクリーンエネルギーという看板を振りかざしすぎるのもどうかと思う。しかも中性子の運動エネルギーでお湯を沸かすという蒸気機関以来の技術なのだから。

なお，プレスリリースでは，時速1500万kmの軽水素をホウ素にぶつけたとある。分かりにくい話だ。LHDで開発してきたプラズマ加速用の2MWの3本の160keV中性水素原子ビームが，プラズマ中に入射されて高エネルギーで閉じこめられた陽子を生成し，これがホウ素と核融合反応した結果の高エネルギーα粒子が観測されたということらしい。

写真：TAE Technologiesの核融合実験炉 Copernicus（TAEより引用）

［１］First measurements of p11B fusion in a magnetically confined plasma（2023）

［２］p11B核融合反応プラズマからの中性子発生（深井佑造，1990）

幽霊漢字

 今日，第1回AIアートグランプリの発表があった。主催がドスパラ（サードウェーブ）で事務局が清水亮さんのMEMEPLEXだ。

279件の応募作品から，17作品が第一次選考を通過した。そのうち12作品が佳作であり，第2次選考を通過した5作品から，グランプリ1作品と準グランプリ4作品が選ばれた。なんと，グランプリは，backspace.fmでお馴染の松尾公也さんの「Desperado by 妻音源とりちゃん[AI]」だ。

これまでも亡くなった妻のとりちゃんの音源を作ってきたが，AIによって画像イメージも生成した上に，自分の歌声をとりちゃんの声に変換できるようになった。さらに３次元化にもチャレンジしているらしい。自分の声やテキストもAI化して残る未来を想定している。

最近，テクノエッジを運営するテクノコアに入社した松尾さんは，MacUserの初代編集長で，有料メールマガジンMacWIREも立ち上げている。ドリキン，西川善治と3人で毎週流しているbackspace.fmの話が面白い。

さて，AIアートグランプリで印象に残ったのは，カラス＝ヨーロッパ中世の防疫マスクで登場した機能美Pさんの作品だ。急遽作られた審査員特別賞も受書した。AIグランプリなのにAIは2%しか使っていないというメタコンセプトの「そんな話を彁は喰った」がその作品だ。そのタイトルに登場する漢字「彁（か・せい）」は幽霊漢字とよばれている。

1978年に通商産業省が制定したJIS C 6226（後のJIS X 0208）では，いわゆるJIS第1・第2水準漢字として6349字が規定された。このとき典拠は次の4つの漢字表だ。
　1. 標準コード用漢字表（試案）： 情報処理学会漢字コード委員会（1971年）
　2. 国土行政区画総覧： 国土地理協会（1972年）
　3. 日本生命収容人名漢字： 日本生命（1973年、現存せず）
　4. 行政情報処理用基本漢字： 行政管理庁（1975年）
この中に，音義・使用例の不明な文字があることが指摘され，辞書類に収録されながら実用例のない単語を意味する「幽霊語」をもじって「幽霊文字」と呼ばれるようになった（WIkipedia 幽霊文字から抜粋引用）。

また知らなかった事実に出会うことになる。犬も歩けば棒に当たる。

図：幽霊漢字の例（彁）

P. S. AIアートグランプリはNHKニュースでも取り上げられて，松尾さんがインタビューに答えていた。

［１］「松尾PはなぜAIアートグランプリで優勝できたのか？！」（第1965話 shi3z & drikinの#AIドリフト）
［２］第一回AIアートグランプリを受賞したので自分の作品解説とファイナリスト作品への感想。そしてその先（CloseBox）（松尾公也）
［３］第1回 AI Art GrandPrix が素晴らしかった件（白井暁彦）

プリマーAI

生成AIの2つの顔（２）からの続き

これら２つの例から考えると，テキスト型生成AIの教育利用のイメージの一つは対話型の本（以下プリマーAI）ということになる（結局，ニール・スティーブンソンのダイヤモンド・エイジに出てくるプリマーに帰着する）。デジタルテキストとして提供される本の場合，(1) 当該の本の本文テキストをコアとして，(2) 同じ著者による関連著書である著者テキストの集合，(3) 本文テキストと関連する主題テキストの集合，(4) "世界"全体の背景常識テキストの集合，に適当な重みをつけて学習させたLLMシステムを作る。利用者は，これに対して，ChatAIインターフェースで，対話しながら内容を読解していく。これに，(5) 対話・学習記録テキストの集合が追加できれば問題ない。

プリマーAIを教科書として利用する場合，対話しながら教科書の内容を理解することができる。つまり，解らない部分は，何度でも角度を変えながら「著者」に質問することができるというわけだ。この場合，教科書検定というか内容（対話部分を担う学習データ部分）の正確性はどう担保するのか。あるいは政治問題化するのか。

ある人の著書だけでなく，全会話記録や全テキスト記録をプリマーAIに入力すれば，その人の仮想人格と対話できることになるので，紙に書かれた文章の読解力がなくとも，著者との対話が実現してしまうことになる。教科書から話はそれるが，対話できるタレント・アイドル本みたいなものができてしまうのか。いいのか？

DeepLに加えてChatGPT+BingChatの魔の手からも逃れられなくなりつつある今日この頃。

生成AIの2つの顔（２）

生成AIの2つの顔（１） からの続き

もう一つは，シンギュラリティサロン・オンラインの「AIは人類社会に革命をおこすのか 〜 OpenAI CEO サム・アルトマン氏の未来予測について考える」だ。ゲストに関西外国語大学の水野義之さんが登場して，AIの問題点を指摘した。ChatGPTは壮大な文化破壊であるというのがキーワードだ。

その意味は次のように説明される。(1) 人間は易きに流れる（勉強嫌い）。(2) 情報は不気味の谷を感じない（気付けない）。(3) 事前に知っていない限り間違いは見抜けない（鵜呑み）。(4) 人間は自分を相手に投影する（思い込み）。これらの結果，ChatGPTの普及によって愚かな人間が増えてしまい，二極分化はさらに進むことになる。それほど厳しい反対論ではない。

なんとなくいいたいことは解るのだけれど，十分に整理しきれていない印象だ。が，水野さんが20年前に原子核実験物理から大学における情報教育へと研究テーマを変えてからの蓄積の上，最近のAIについても十分リサーチしていることから，バランスのとれた興味深い話だった。壮大な文化破壊に対する対策としては，(1) Yann LeCun のFacebook 2/14/2023のコメント#14を引用している。「− LLMは*書き込み補助*として使われている。− 心のない大衆に彼らの作り上げたナンセンスを信じさせることで，社会の布石を破壊することは*しない*。− 人々は役に立つことにそれらを使う」（これ対策ではないけど…）(2) AI倫理による回避，(3) 人間知能の理解進化（？） をあげていた。

水野さんと最初に会ったのは，自分がD1のときの夏の学校の原子核分科の研究会だ。藤田純一先生が来られるはずだったが，病気でかなわなかったときか。修士論文のA=12体系のベータ崩壊におけるCVCの話をしたところ，最前列に座っていた1学年下の水野さん（東北大学の原子核理学研究施設：現，電子光理学研究センターで電子散乱の実験をしていた）が質問してきた。

次に覚えているシーンは1980年5月，阪大核物理研究センターが六甲山の関西地区大学セミナーハウスで開催した原子核物理の夏の学校だ。小林正博君と一緒にエジプト人留学生から英会話を学んで準備したサマースクールだった。夜のインフォーマルミーティングで水野さんはQCDの深部非弾性散乱でOperator Product Expansion の話を始めていた。うーんなんだったのか。

最後は，1996年1月に早稲田大学で催されたのJAIN-OLU合同シンポジウムの場だ。「インターネットと教育　−WWWによる教育情報の提供−*」というタイトルで発表したのだが，同じ場で，水野さんがインターネットとボランティア的な内容の話をした。チラッと顔を合わせて，あらこんなところでとなったのだった。ちなみに，和歌山県のみさと天文台の尾久土正己さんが「過疎地域の天文台におけるインターネット活用」という話をしている。

*リンク先は同趣旨で書いた，大阪大学大型計算機センターニュース（1997.8）の記事

生成AIの2つの顔（１）

2022年の生成AI（DALL-E, ChatGPT）の登場は，インターネット以来のインパクトを持っていた。今も新しいニュースが絶え間なく続き，ほとんど追いつけない状態になっている。SNSで聞こえてくる日々の噂もカバーしきれない。そんな中で，今日見た2つのチャンネルは，大変興味深かった。

一つは，散財小説ドリキンの「ChatGPTが変えたエジケンの新プロダクトとAIにハマる理由」だ。Quoraエバンジェリスト／ソフトウェアエンジニアの江島健太郎が，GPT-3を使った新しいアプリケーションを開発している。ドキュメントをアップロードしてそれとチャットするという単純なものだ。そのドキュメントからword2vecで意味的に質問に近い部分を見つけ，これを取り出してGPT-3に要約させるというのが肝らしい。ポイントはインターフェースとしてのAI-Chatというコンセプトだ。ほとんどの企業や組織ではこうした業務（エンターブライズサーチ）が存在しているので，うまくいけば大当たりする可能性もある。

清水亮もそうだったけれど，目端の聞くソフトウェアエンジニアや企業家は，一斉に生成AIに群がっている。既存サービス業の置き換えだとしても数百兆円のビジネス機会が眠っているが，LLMを開発できる技術者の数は限られているので，ニッチ市場はまったく埋りきらない。今がチャンスだ。

ChatGPTや新しいAI-Chatシステムが普及するとき，既存のWeb+検索のネットワークそれ自身が大きな影響を受ける可能性がある。インターネット草創期のgopherで到達できたftpアーカイブのような1次情報のネットワークさえあれば，SNSなどの2次情報によるシンタックスシュガーは不要で，これら原データを直接取り込んだAI-Chatシステムだけが残るという未来だ。しかも，Synthetic Data（合成データ） の普及によって，必ずしも人間が作ったウェブコンテンツがなくてもAIは学習できるのだった。

行政文書

参議院議員の小西洋之（1972-）が総務省から入手して公開した放送法の政治的公平性解釈を巡る文書（2014年）の件である。

当時の総務大臣であった，経済安全保障担当大臣の高市早苗（1961-）が，参議院予算委員会の質疑の場でそれは捏造文書だと決めつけた。もし真正な文書なら大臣も議員もやめると大見えを切った数日後，現総務大臣の松本剛明（1961-）が行政文書であることを認めて政治的公平に関する文書（78p）として公開した。高市はさっそく議論のポイントをずらしながら逃げ切りを図っている。

もし仮にその行政文書が捏造であるならば，作成当時の総務大臣である高市早苗に責任があることになるのだが，まるで他人事のように，自分の名前が出てくる4ヶ所はでっち上げであると強弁している。どこかでみたと思ったら，大阪維新の橋下に始まり，松井，吉村の常套手段だった。自分が行政の責任者にもかかわらず，大阪府や市の行政担当者をあからさまに非難・攻撃してポピュリズム的な溜飲を下げる手口だ。今回とは少し種類や性質が違うにせよ，行政の責任体系の破壊という意味では共通だ。

行政文書は公文書等の管理に関する法律の第二条４項で次のように定義されている。

この法律において「行政文書」とは、行政機関の職員が職務上作成し、又は取得した文書（図画及び電磁的記録（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られた記録をいう。以下同じ。）を含む。第十九条を除き、以下同じ。）であって、当該行政機関の職員が組織的に用いるものとして、当該行政機関が保有しているものをいう。ただし、次に掲げるものを除く。

一　官報、白書、新聞、雑誌、書籍その他不特定多数の者に販売することを目的として発行されるもの

二　特定歴史公文書等

三　政令で定める研究所その他の施設において、政令で定めるところにより、歴史的若しくは文化的な資料又は学術研究用の資料として特別の管理がされているもの（前号に掲げるものを除く。）

この行政文書と独立行政法人が管理する法人文書および特定歴史的公文書の総称が公文書ということになる。

この法律の第十条では各省庁での行政文書管理のために，行政文書管理規則を定めることになっている。総務省の場合は，公文書管理のページの中に，総務省行政管理規則（2011.4）が公開されている。

この第12条に文書主義についての項がある。

(文書主義の原則)

第12条 職員は、文書管理者の指示に従い、法第4条の規定に基づき、法第1

条の目的の達成に資するため、総務省における経緯も含めた意思決定に至る 過程並びに総務省の事務及び事業の実績を合理的に跡付け、又は検証するこ とができるよう、処理に係る事案が軽微なものである場合を除き、文書を作成 しなければならない。

これが正しく機能していたおかげで，磯崎陽輔（1957-）が，放送法における政治的公平性の解釈を恣意的に変更しようと強要した過程が記録されることになった。松本総務大臣及び総務省は，礒崎−安倍−高市ラインの当時の蠢動は，公平性の解釈変更ではなく補充的説明であると言い張っている。普通に考えると，解釈変更であり，実際に発動はしていなくともその効果によって，テレビ界の言論が大きく萎縮しているのは間違いない。日曜のサンデーモーニングでは，このニュースは末尾に少しだけ取り上げられたが，強い意思表明などは全くなかった。

面倒なのは，奈良県知事選挙で高市が総務完了崩れを推選して奈良県自民党の分裂をまねいていることだ。天理市長は，反現知事派＝高市派だしなあ。

2000.12 女性国際戦犯法廷

2001.01 NHK ETV特集「戦争をどう裁くか／問われる戦時性暴力」

　　　中川昭一（1953-2009）・安倍晋三（1954-2022）による圧力

2006.09 第一次安倍内閣発足（-2007.09）

2007.07 礒崎陽輔が参議院議員（大分県選挙区-2019.07）

2012.12 第二次安倍内閣発足（-2020.09）

2013.12 国家安全保障会議の設置

2014.04 礒崎陽輔が内閣総理大臣補佐官（-2015.10）

2014.11.20 「選挙時期における報道の公平中立ならびに公正の確保についてのお願い」

　　　　　自由民主党筆頭副幹事長 萩生田光一・報道局長 福井照

2014.11.21 衆議院解散

2014.11.26 礒崎陽輔から総務省放送政策課へのアクション開始

2014.12.14 衆議院選挙

2015.05 高市総務大臣が参議院総務委員会で調整版回答を答弁

［１］橋下劇場に関する批判的評論の分析 −ポピュリズム研究の進展のために−（有馬晋作）

［２］放送事業規制の日米比較と日本の問題点（鶴田達成）

［３］我が国のメディアの現状と課題（黒須俊夫）

［４］日本版公正原則の現在（魚住真司）

［５］「国民投票運動のための広告放送」等に関する資料（衆議院）

プログラミング遍歴（２）

プログラミング遍歴（１）からの続き

(4) Mathematica：

Mathematicaについては既に書いているので，少し捕捉しておく。物理数学だったか計算物理だったかの授業で，Mathematicaを何年か授業で教えていたことがある。情報処理センターでは，キャンパスライセンスが導入されていて，実習室のMac（一時 Silicon Graphics のIndigo?）を使って，一通りの基礎的文法から微分方程式までをカバーしていた。

その経験があったので，卒業生の杉木君が尼崎小田高校のSSHの担当のときに，柏原キャンパスで高校生対象の1-2日のMathematica実習を実施した。尼崎小田高校では出前授業でMathematica/Excel?を使ったケーキカップの落下実験をとりあげたこともある。

(5) Perl：

インターネットの教育利用についてをテーマとするようになったのは，1994年からだ。1995年から7年ほどの黎明期に，インターネットと教育という教育利用サイトのリンクリストを運営していたが，それと連動して，全国の学校に対するアンケート調査を実施していた。今ならば絶対にアウトになりそうなやつだ。

まだ，数が少なかった学校のウェブページをクロールして，何階層かをダウンロードする。そこからメールアドレスをとり出して，ここに年１回アンケートを送り付ける。この処理にperlを用いた。wgetやlynxで入手したHTMLファイルからメールアドレスを切り出して，ユニークなものにすること。メールアドレスのデータをまとめて自動的にメール送信すること。こうした処理には，当時はPerlが最適任だったのだ。

(6) Julia：

もう退職が近づいてきたころに出会ったのがJuliaだった。スーパーコンピュータでガリガリの並列計算をするような仕事には縁遠くなってしまったので，Julia程度の軽快で高機能なプログラミング言語は大変有難かった。Mathematicaほどの自由度にはかけるが，手続き的プログラミングでは，Juliaの方が使いやすいので，現在はこの両者を使いわけている。COVID-19のシミュレーションはJuliaで，北朝鮮ミサイルのシミュレーションはMathematicaでという具合だ。

プログラミング遍歴（１）

(1) FORTRAN：

高校理数科のとき，試験にも出たFORTRANは座学だけで学んだ，というか聞きかじった程度。参考書というわけでもないが，興味があって自分で買ったのが電子計算機と人間だったけれど，これを読んでもさっぱり分からない。テレビでは，森口繁一（1916-2002）のNHKコンピュータ講座フォートラン入門をやっていたが，これもたまにチラ見する程度で何が何だかやっぱりよく分からない。

阪大の物理学科に入ると，初年次セミナーというのがあった。意欲的な同級生らは，バークレーの統計力学やFORTRAN入門にエントリーしていた。自分は億劫でどれにも参加しなかったが，学籍番号が隣の越湖直人君が，FORTRANのプログラミングで，銀河系形成のシミュレーションをやっていると聞いた。残念ながら最終結果を得るにはリソースが足りなかったようだ。

さて，その森口繁一のJIS FORTRAN入門の第2版上下を買ってしばらくしてから，大学4年の村岡光男先生の数値計算法で，はじめてのFORTRANプログラミングを体験することになる。文法の説明が数回あった後に，課題に取り組んだ。豊中データステーションの様子は以前に書いたとおりだ。いくつかの課題があって，そのうち2つを選択してレポートとして提出すれば単位がもらえる。

最初の課題は単純な四則演算の組み合わせだったのでそれを選択したものが多かった。それではつまらないと思い，5次方程式の解法と行列の対角化の2課題に取り組んだ。それぞれについて結果を出した自信があったが，後で考えるとどうも答えが間違っている。実際，村岡研に進んだ楠本君から，当時の成績が悪かったらしいと聞くことになる。

そんなわけで，大学院に進学して修士論文に取り組み始めてからも，なかなか研究がはかどらない。業をにやした大坪先生が，簡単なルンゲクッタ法のプログラムを作ってみるように指示し，教育的配慮でほめてくれたので，それをきっかけに，FORTRANプログラミングへの抵抗はなくなった。

こうして，修士課程以降は2000年ごろまでは，普通にFortran77を研究に使っていた。1990年代には京大の総合人間学部（旧教養部）の科目の非常勤でFortran77の実習も担当した。そんなわけで，Macを使うようになっても，長らくabsoft Fortranのライセンスを維持していたけれど，実際にはほとんど使うことはなかった。absoft Pro Fortranは2022年の8月に販売終了していた。

(2) BASIC：

大阪教育大学に勤めてまもなく研究室に導入したパーソナルコンピュータが，NECのPC-9801だった。これにはN88BASICがROMでプレインストールされていて，OSのように使われた。アプリケーションソフトもまだ高額だったので，BASICがなければパソコンが使いこなせない。学生の卒論もBASICで計算していたし，授業や公開講座などでも良く使った。

もっとも，最初に，BASICに出会ったのは，1980年ごろに阪大附属図書館でアルバイトをしていたときに，図書館2Fの事務室に導入されたOKIのif800のBASICだった。チラッと眺めたけれど，四則演算は分かるがグラフィックスが皆目見当がつかない。同じアルバイトで1-2学年下の化学の学生が，スラスラと図形を表示させているのにビックリしてしまった。

さて，そのNECのBASICである。BASICコンパイラなども使ったけれど，自分の研究のための計算をすることはほとんどなかった。卒論にもそれほど使い込んだ記憶がない。そうこうしているうちに，8087に対応したTurbo Pascal 3.0 がやってきたからだ。非常に快適なプログラム作成環境で，コンパイルのスピードにほれぼれしていた。これは，斎藤昌久君が，グラフ作成ツールなどを作ってくれて重宝した。

BASICではないが，PC-9801に8087数値演算プロセッサを積んだころ，その能力を活かそうと，8080+8087のアセンブリ言語プログラミングに取り組んだ。当時のパソコン雑誌にはこうした記事がたくさんあったので，素人でも簡単に手を出すことができた。Clebsh Gordan係数やRacah係数のコードを作り，BASICと組み合わせて連立方程式の計算を高速で実行するというあたりで，若松正志さんにそれで何をしますかと聞かれて，そうですね・・・と終了を迎えることになった。

(3) C:

C言語は，カーニハン・リッチーのプログラミング言語Ｃ（石田晴久訳）を買って少しだけ勉強した。そのころは，Lattice C，LightSpeed C/Think C，Turbo C など，あまたのC言語処理系が乱立していた。Oh PC にはCとアセンブリ言語の中間のようなコンパクト言語なども掲載されている時代だ。で，さきに述べたように，ポインタのあたりでつまづいてサンプルプログラムを越えるものは作れなかった。

UNIX時間（６）

UNIX時間（５）からの続き

世界で活躍し『日本』を発信する日本人の一人にも選ばれている，まつもとゆきひろ（松本行弘）さんが作った ruby（1995-）は，日本発のオブジェクト指向スクリプト言語だ。ウェブアプリケーションフレームワークのRuby on Rails まで進めば御利益が多そうだけれど，近づいたことはないので，小波英雄さんが京都女子大のプログラミング教育で使っていたPerlの後継言語といった印象を持っていた。

一方のRust（2010-）は，評判だけ耳にしていた。この度改めて一からインストールして試してみた。日曜プログラマがちょっと遊んでみるには敷居が高いのかもしれない。C++代替を目指している現代的なプログラミング言語で，プロの評判は一番だけれど習得しにくさもトップレベルという面倒なやつ。

BingChatに，「rustを使って次の内容を実行する１つのプログラムを書いてください。 (1) 現在時刻をミリ秒単位まで取得して年月日時分秒の形式で表示する。 (2) (1) の結果をUNIX時間へ変換して表示する。 (3) UNIX時間=0に対応する年月日時分秒を表示する。 (4) UNIX時間=2**31-1（or 2^31-1）に対応する年月日時分秒を表示する。」と指示したところ，次のまともに動作するプログラムが出力された（コメントのみ手を入れている）。

#!/usr/bin/ruby

require "time"

## msec単位の現時刻

tn =  Time.now

tm = tn.iso8601(3)

p tm

## 年月日時分への変更

t = Time.now.to_i

d = Time.at(t).strftime("%Y/%m/%d %H:%M:%S")

p d

## UNIX時間への変更

t =  Time.parse(d).to_i

p t

## UNIX基準時

t = 0

d = Time.at(t)

p t,d

## 2038年問題

t = 2**31-1

d = Time.at(t)

p t,d

use std::time::{SystemTime,UNIX_EPOCH};

use chrono::{DateTime,Utc,Local};

fn main() {

// 現在日時の取得（ミリ秒）

//    let datetime = DateTime::<Utc>::from(now);

    let now = SystemTime::now();

    let datetime = DateTime::<Local>::from(now);

    println!("現在時刻: {}", datetime.format("%Y-%m-%d %H:%M:%S%.3f"));

// UNIX時間への変換

    let unix_time = now.duration_since(UNIX_EPOCH).expect("Time went backwards").as_millis();

    println!("UNIX時間: {}", unix_time);

// UNIX基準時

    let zero_time = UNIX_EPOCH;

    let zero_datetime = DateTime::<Utc>::from(zero_time);

    println!("UNIX時間=0: {}", zero_datetime.format("%Y-%m-%d %H:%M:%S%.3f"));

// 2038年問題

    let max_unix_time = UNIX_EPOCH + std::time::Duration::from_secs((2u64.pow(31)) - 1);

    let max_unix_datetime = DateTime::<Utc>::from(max_unix_time);

    println!("UNIX時間=2^31-1: {}", max_unix_datetime.format("%Y-%m-%d %H:%M:%S%.3f"));

}

Rustは次のようにインストールした。Cargoというビルドシステム兼パッケージマネージャを使うのが普通らしい。

% brew install rustup-init

% rustup-init

% source "$HOME/.cargo/env"

% which rustup

~/.cargo/bin/rustup

% rustup --version

rustup 1.25.2 (2023-02-01)

% which rustc

~/.cargo/bin/rustc

% rustc --version

rustc 1.67.1 (d5a82bbd2 2023-02-07)

% which cargo

~/.cargo/bin/cargo

% cargo --version

cargo 1.67.1 (8ecd4f20a 2023-01-10)

% cargo new hello_rust

% cd hello_rust

% cargo run

   Compiling hello_rust v0.1.0 (~/code/hello_rust)

    Finished dev [unoptimized + debuginfo] target(s) in 0.64s

     Running `target/debug/hello_rust`

% cargo install cargo-edit

% cargo install cargo-watch

% rustup component add rustfmt

% rustup component add clippy

% rustup component add rls rust-src rust-analysis

% rustup update stable

$ rustup doc

file://~/.rustup/toolchains/stable-aarch64-apple-darwin/share/doc/rust/html/rust-by-example/index.html

UNIX時間（５）

UNIX時間（４）からの続き

いつの間にか，Python（1991-）がプログラミング言語の主役に躍り出ていた。Jupyterでも使えるので，環境は整っている。一方のPerl（1987-）は，今ではオブジェクト指向のRuby（1995-）に取って代わられたのかもしれない。

最初に，Pythonという言葉を耳にしたのは「インターネットと教育」祭の最終段階のころだったか。誰かが，Zope（1999-）というPythonで書かれたすごいシステムがあって何でもできるような話をしていたころだ。それがどこかでCMSのPlone（2001-）につながるのだが，そのデザインに引かれて，自分でもポータルサイトに使いかけていたことがあった。

#! /Users/koshi/bin/python

#

import datetime

import pytz

import time

#

# 現在のUNIX時間を出力

unix_time = int(time.time())

print(unix_time)

print(datetime.datetime.fromtimestamp(unix_time))

# UNIX時間に変換

ud = datetime.datetime(1973, 9, 20, 6, 0, 0, 0)

tz = pytz.timezone("Asia/Tokyo")

ud = tz.localize(ud)

ut = ud.timestamp()

print(ut)

# 年月日日時分に変換

ud=datetime.datetime.fromtimestamp(ut)

print(ud)

# UNIX基準時

n = 0

print(n)

print(datetime.datetime.fromtimestamp(n))

# 2038年問題

n = 2**31-1

print(n)

print(datetime.datetime.fromtimestamp(n))

#!/usr/bin/perl

#

use strict;

use warnings;

use Time::Local 'timelocal';

use Time::HiRes 'gettimeofday';

my $ut = 0;

my ($msec, $sec, $min, $hour, $day, $month, $year) = shift;

# 現在時刻の取得

($year, $month, $day, $hour, $min, $sec, $msec) = getCurrentTimeStr();

printf("JST: %04d/%02d/%02d %02d:%02d:%02d.%003d\n", $year ,$month, $day, $hour, $min, $sec, $msec);

# UNIX時間への変換

$ut = timelocal($sec, $min, $hour, $day, $month-1, $year);

print($ut,"\n");

# 年月日時分秒への変換

getDateTimeStr($ut);

# UNIX基準時

$ut = 0;

print($ut,"\n");

getDateTimeStr($ut);

# 2038年問題

$ut = 2**31-1;

print($ut,"\n");

getDateTimeStr($ut);

exit 0;

sub getCurrentTimeStr {

    my ($epochSec, $microSec) = gettimeofday();

    my ($sec, $min, $hour, $day, $month, $year) = localtime($epochSec);

    $year += 1900;

    $month++;

    return ($year,$month,$day,$hour,$min,$sec,$microSec)

}

sub getDateTimeStr {

($sec, $min, $hour, $day, $month, $year) = localtime($ut);

$year += 1900; $month += 1;

printf("JST: %04d/%02d/%02d %02d:%02d:%02d\n", $year ,$month, $day, $hour, $min, $sec);

}

炭素年代測定法

ヤポネシアからの続き

14Cを用いた，炭素年代測定法について。

炭素14（0+1）から窒素14（1+0）へのガモフテラーベータ(−)崩壊の半減期5730年(1.81*10^11 s)は，アイソバリックアナログ状態の酸素14（0+1）から窒素14（1+0）のベータ(＋)崩壊/電子捕獲の半減期70.6秒に比べると9桁ほどと圧倒的に大きい。その理由は次のように説明される。

β+崩壊の方は，ほとんどが，0+1→0+0励起状態の許容フェルミ遷移になるため，1+0基底状態への分岐比は0.61%である。これを補正すれば 4桁回復する。また，遷移エネルギー差が大きく影響する位相空間からくる寄与（f値）を計算してみれば 4桁の差が縮まる。これらを考慮すると，荷電対称性から1になるべき遷移行列要素の比率が1桁以内に収まる（それでも結構な違いが残る）。

炭素年代測定法は，授業の課題でもたびたび取り上げたし，AMS（加速器質量分析）の話題とからめて入試問題も作成したので，馴染のはずだった。ところが，縄文人のDNA分析の話の中で，重要な補正項があることを始めて知った。

地球の炭素循環は大気圏，表層海洋圏，深層海洋圏，陸上生物圏，海洋生物圏などのブロックに分割できるが，それぞれの部分に蓄えられる炭素の割合と，その拡散時間が異なっている。そこで，これらの炭素リザーバーの効果を適切に評価する必要がある。例えば，海洋生物を主に食べているヒトの炭素では，深層海洋圏に長くとどまることで14Cの割合が減少した炭素が海洋生物圏に達し，その割合が大きくなることから，年代推定に影響を与えることになる等々。

ヤポネシア

ヤポネシアは，戦後奄美大島に住んだ作家の島尾俊雄（1917-1986）が考えた造語だ。 樺太や千島列島から日本本土，琉球列島までの地理上の日本列島弧を指す。

学術用語としても定着しており，2018年度から2022年度までの科研費の新学術研究で「ゲノム配列を核としたヤポネシア人の起源と成立の解明」というテーマの研究が進められている。研究代表者の国立遺伝学研究所，斎藤成也さんの講演をいくつかYouTubeで見ることができる。

大陸と陸続きだった日本列島に最初に住み着いたのが狩猟生活をしていた縄文人で，その後朝鮮半島や琉球列島などを経由して渡来した弥生人が農耕文化をもたらした。縄文人は北海道のアイヌと沖縄にその血を濃く残しているというのが，これまでのボンヤリした理解だった。これが，東大の埴原和郎（1927-2004）による二重構造説らしい。

それが，DNAのゲノム解析の技術が進んだことで，縄文人や弥生人や古墳人のDNA解析が進み，この三者がはっきりと異なる特徴を持っていることが明らかになり，日本人の起源は二重構造ではなく三重構造ではないかというのが最近の研究成果らしい。この場合，古墳人につながる集団は弥生時代の日本に様々な技術を持ち込んで，卑弥呼によるヤマト王権の成立につながることになる。

図：縄文人，弥生人，古墳人，現代人の遺伝的特徴

（Ancient genomics reveals tripartite origins of Japanese populations から引用）

この論文では，金沢市の岩出横穴墓の古墳人のデータが用いられている。小学校の修学旅行では，安宅の関や実盛の首洗い池とともに，加賀市の法皇山横穴古墳を訪ねているが，ここも古墳時代のかなり大規模な古墳群である。

［１］ヤポネシア人のゲノム解析（斎藤成也，生体の科学 2020）
［２］私たちは何者か～DNAで迫る現代日本人への道（NHK 2021 ）

［３］パレオゲノミクスで解明された日本人の三重構造（金沢大学 2021）

UNIX時間（４）

UNIX時間（３）からの続き

昔憧れていた（しかも一度も使ったことがない）S言語（1984-）の流れを汲むR言語（1993-）は統計処理を得意としており，ほとんど使わないがなんとなく手放せない。macOSで起動すれば，Rの実行環境あるいはRStudioでの処理となる。コマンドラインではどうなるかというと，homebrewに rscript というインタープリタが導入されていた。

Processing（2001-）はグラフィックスやアニメーションに秀でており，Arduino などのワンボードマイコンの処理系としても登場する。Javaのアプレットとして取り出せないこともないが，基本的にはProcessing実行環境の中が舞台だ。p5.jsというJavascriptライブラリを使うと，このProcessingに相似した言語（まったく同じかと期待したがそうではなかった）でJavascriptを操ることが出来る。これによって，プログラムを実行環境の外へ取り出せたようにも見えるが，実際にはなんだかまだるっこしい。

そこで，代わりにコマンドラインで使える TypeScript（2012-）を使うことにする（Processingはどこへ行ったのだろう）。macOSでのTypeScriptでは，.tsファイルを作成した後，tsc で .jsファイルを生成し，nodeで .jsファイルを実行することが出来る。一方，ts-nodeコマンドを使えば， .ts ファイルをスクリプトとして直ちに実行することも可能だ。

#! /opt/homebrew/bin/rscript

#

library(lubridate)

options(digits.secs=3)

#現在時刻の取得（ms単位）

dt <- now(tzone = "Asia/Tokyo")

dt

dt <- Sys.time()

dt

#UNIX時間へ変換

dt <- as.POSIXlt("1973-09-20 12:34:56.789 JST")

dt

ut <- as.numeric(as.POSIXlt(dt))

ut

#年月日時分秒へ変換

dt <- as_datetime(ut, tz="Asia/Tokyo")

dt

#UNIX基準時（JST）

as.numeric(as.POSIXlt("1970-01-01 09:00:00 JST"))

as_datetime(0, tz="UTC")

#2038年問題（JST）

as.numeric(as.POSIXlt("2038-01-19 12:14:08 JST"))

as_datetime(2**31, tz="UTC")

#! /opt/homebrew/bin/ts-node

//

// 現在時刻を取得する (ミリ秒単位)

var date = new Date()

console.log(date.toISOString())

var time = date.getTime()

console.log(time)

// UNIX時間への変更

var date = new Date(Date.parse('1973-09-20T12:34:56.789Z'))

var time = date.getTime()

console.log(time)

// 年月日日時分への変更

var date = new Date(time);

console.log(date);

// UNIX基準時

var n0 = 0;

console.log(n0);

var t0 = new Date(n0);

console.log(t0)

// 2038年問題

var n8 = 2**31-1;

console.log(n8);

var t8 = new Date(n8*1000);

console.log(t8);

UNIX時間（３）

小学校でプログラミング教育などともがいているうちに，時代は，プロンプト工学（Wikipediaに中文はあるが日本語はない）へ向かう。AI Chat で使う自然言語である英語自身がこれから最も重要なプログラミング言語になるという怪しいうわさが流れている。日本語は，もとのドキュメント量が1桁少なくて，良質の結果を得られない三流プログラミング言語になろうとしている。

そこで時代に逆行して，いろいろなプログラミング言語の表層入門 のために，UNIX時間を出力するコードを調べている。頭がぐちゃぐちゃになってどれもこれも身につかないところが楽しい。まあ，40年前にカーニハン・リッチーのポインタでつまずいて，Turbo Pascalで少し息を吹き返したころから，自分の進歩は止まっているのだ。

第1回ではお気に入りのWolfram 言語とJulia，第2回ではFortran95を取り上げたので，今回は，C++（1983-）とSwift（2014-）である。Cに挫折しているのでC++も同じようになりそうだし，Appleの最新言語Swiftだとどうなることか。Swiftはスクリプト言語（swift）としてもコンパイラ言語（swiftc）としても使えるところがありがたい。なお，Apple M1 macOS場合，cppではエラーが起きるので c++ でコンパイルする必要があった。あと，swiftの拡張子が.swiftというのも少しだるい。

#include <iostream>

#include <sys/time.h>

#include <cmath>

using std::cout; using std::endl;

int main() {

    struct timeval ima;

    time_t ut, ut0, ut8;

    struct tm t;

    struct tm t0 = { 0, 0, 9, 1, 0, 70, -1 };

    struct tm t8 = { 7, 14, 12, 18, 0, 123, -1 };

//現在時刻の取得（msec）

    gettimeofday(&ima, nullptr);

    time_t mnow = (ima.tv_sec * 1000) + (ima.tv_usec / 1000);

    cout << "  msec since epoch: " << mnow << endl << endl;

//UNIX時間へ変換

    ut = time(nullptr);

    cout << "  unixtime: " << ut << endl;

//年月日時刻へ変換

    cout << "  day-time: " << ctime(&ut) << endl;

//UNIX基準時（JST）

    ut0 = mktime(&t0); // ut0 = 0

    cout << "  unixtime: " << ut0 << endl;

    cout << "  day-time: " << ctime(&ut0) << endl;

//2038年問題（JST）

    ut8 = mktime(&t8); // ut8 = 2^31-1

    cout << "  unixtime: " << ut8 << endl;

    cout << "  dat-time: " << ctime(&ut8) << endl;

    return EXIT_SUCCESS;

}

#! /usr/bin/swift

import Foundation

//現在時刻の取得（msec）

let date: Date = Date()

let unixtime: Int64 = Int64(date.timeIntervalSince1970)

let utime_ms: Int64 = Int64(date.timeIntervalSince1970*1000)

print(utime_ms)

//UNIX時間へ変換

var time = TimeInterval(integerLiteral: unixtime)

print(time)

//年月日時分秒へ変換（GMT）

var day = Date(timeIntervalSince1970: time)

print(day)

//UNIX基準時（GMT）

var zt = Int64(0)

var ut = TimeInterval(integerLiteral: zt)

var ud = Date(timeIntervalSince1970: ut)

print(ut)

print(ud)

//2038年問題（GMT）

zt = Int64(pow(2,Double(31)))-1

ut = TimeInterval(integerLiteral: zt)

ud = Date(timeIntervalSince1970: ut)

print(ut)

print(ud)

C++の構造体に代入しようとして四苦八苦した。C言語の系列は includeファイルが面倒なので，どうも好きになれない。情報が沢山あるのはありがたいのだけれど。Swiftは，Appleから出ているドキュメントがわかりにくいので，これも好きになれないかも。

レコード煎餅

水木十五堂からの続き

第11回水木十五堂賞授賞式のやまと郡山城ホールには，桂文我が収集した落語関係資料の一部が公開されていた。その中に，桂春団治の煎餅缶というのがあったがサラッと通り過ぎた。

帰ってから調べてみると，それはなんとレコード煎餅というものだった。必ずしも確かではないネット情報とYouTubeでの桂文我自身の話を組み合わせると次のようなことらしい。

まず，Wikipediaのレコードの項には次のようにある。

1924年に神戸で煎餅レコードが販売されていた。タイヘイレコード設立者の森垣二郎が作ったものとされ，童謡が収録されていた。これを見た落語家の初代桂春団治（1878-1934）が1925年に，今度は大阪市の住吉区にあった「ニットーレコード（日東蓄音機）」の協力のもと，やはり煎餅レコードを作った。湿気ない様に缶にパッケージされていた。春団治のレコードの価格は8枚入りの1缶が1円50銭，10枚入りの1缶が1円95銭だった[19][20]。1926年1月に天理教の大祭の人出の多さを当て込んで売り出されたが，値段の高さや，あいにくの雨で煎餅の多くが湿気ったことなどでほとんど売れず，春団治は大損した。落語やコントなどが収録され，「聴き飽きたら食べる」というコンセプトだった。

　一方，次のような話もある［2］。

せんべいで作ったレコードは大正期の終わりに京都市内のお菓子屋が始めたという。実際に制作されたせんべいのレコードは兵庫・神戸市にある有馬温泉名物の温泉せんべいのように表面がすべすべしたもので，水飴でコーティングしてそこに溝を入れ，竹の針を落として聴く。神戸では「桃太郎」や「金太郎」，そして「花咲かじいさん」のような童謡を吹き込んだせんべいのレコードが売られていた記録も残っていた。

（中略）

レコードは初代師匠の十八番の落語などを吹き込み，いずれも専用の竹針を入れた8枚入りと10枚入りの2種類を売り出して，「鈴鹿馬子唄」の歌詞を拝借した「昔はウマが物云う鈴鹿の関，今は煎餅で物云う春団治」というキャッチコピーで売り出した。

発売されたのは，1926年の天理教の大祭の3日間だけだったが，全国から信者が集まっていたために，缶だけが残されたものがあって，ヤフーオークションにかかった。落札価格は35万円。桂文我はその後会津若松地方で見つけたということだ。

写真：桂春団治のものいふせんべい（大和郡山市資料から引用）

［１］食べるレコード

［２］昔はせんべいで作ったレコードもあった

［３］レコードが食えるか！

［４］【噂は本当！】大正時代「せんべい」で作られた伝説のレコードがヤフオク出品‼