0928 | 世界最古の条約からAIの「暴走」まで

葵: こんばんは、葵です。

悠真: 悠真です。今夜も寝る前の30分、テクノロジーの話題をゆるく、でも中身はしっかり眺めていきましょう。今日の話題、実はつながってるんですよ。ものすごく古いものと、ほんの数日前に生まれたものが、同じテーマで並ぶ。

葵: そうね。条約、コンピュータ、生命の起源、そして個人の小さなコードと修理。規模はバラバラだけど、「どこから始まって、どう続いていくか」という問いでは全部仲間だと思う。じゃあ最初の話題、今日一番のビッグニュースから。

悠真: はい。トルコのハットゥシャから、世界最古の講和条約の断片が出土したという報告です。エジプトとヒッタイトの間の条約で、時期は紀元前1269年頃。つまり約3300年前の外交文書です。

葵: ハットゥシャはヒッタイトの首都だった遺跡だよね。有名なアムルの講和条約、いわゆるカデシュの戦いのあとにエジプトのラムセス2世とヒッタイトの王の間で結ばれたあの条約と同じものの話だとしても、断片が「出土した」という事実が大きい。教科書の中の出来事だったものが、実物として土の中からまた顔を出したわけだから。

悠真: そこが一番面白いところですよね。「世界最古」といっても、条約そのものの存在はずっと知られていて、写しや後に刻まれた版は見つかっていた。でも今回のは遺跡から出た断片で、つまり「3300年前の外交文書が、実物のかたちで今も残っている」ことの重みが違う。

葵: しかも講和条約というのは、戦争を終わらせる側の文書だから、勝利の記録じゃなくて対等な合意の記録でもある。当時の国際関係が、ここまで成熟した文書のやり取りで管理されていた証拠でもあるわけで。断片から何が読み取れるのか、条約文のどこが見つかったのか、まだ細かい情報がでていないところが、これからに期待したい。

悠真: ここから一気にジャンプします。約3300年前の外交文書の次は、コンピュータ史の「最初」の話。

葵: Alan KayがQuoraで、ENIACにBIOSはない、と回答したという話。BIOSっていうのはパソコンが起動するときに最初に動く基本のプログラムね。Kayのような、パソコンそのものの概念を作った側の人がENIACに言及するというのは、それだけで味がある。

悠真: そしてこの回答に対して、1948年以降はENIACがstored programモード、つまりプログラムを本体に保存して動かす方式で運用された、という指摘も上がっていたんです。

葵: これがコンピュータ史の面白いところ。ENIACって元々は配線を組み替えることでプログラムを変える機械だった、って普通は習うわけだけど、後年は保存プログラム方式で動くようになっていたという経緯がある。だとすると「ENIACは保存プログラム式コンピュータの最初かどうか」という問いの答えは、「時期によって変わる」になる。

悠真: 「最初」をどう定義するかで答えが変わる、というやつですね。ENIACにBIOSがない、という指摘自体は技術的には正しい。でもENIACが「最初のコンピュータ」かというと、初期のどの時点を切り取るかで印象が変わる。歴史は一本の線じゃなくて、遷移の連続なんだ、というのがこのやり取りから読み取れると思います。

葵: そしてこの「最初のコンピュータ」の話から、もう一つの極端にジャンプ。生命の起源です。

悠真: ニューヨーク・タイムズが、80ドルのモーテル室で行われた生命起源に関する発見を報じたという記事。

葵: 80ドルのモーテル室。研究費にすればカスみたいな額よね。

悠真: ただ、記事はペイウォールの後ろにあって、発見の中身の詳細までは確認できない。なので、何がどう発見されたのかをここで語るのは避けたい。確実に言えるのは、「生命の起源という fundamental な問いの研究が、80ドルのモーテル室で進む」という事実が大手紙に取り上げられた、ということだけです。

葵: それでも教訓としては十分伝わる。研究の規模と発見の価値は無関係、ということ。先ほどの条約の断片もそうだけど、大きな発見はいつも豪華な設備から出るとは限らない。ハットゥシャの土の中、80ドルのモーテル、1948年の運用モードの転換。全部、大掛かりじゃないところから歴史が書き換わる話よね。

悠真: はい。ここから話をグッと身近な側に寄せます。個人が手を動かすプログラミングと修理の話。

葵: まず設計の話題から。GoコードをGitHubのimportパスに結合せず、カスタムドメインを使うべき、というvanity import pathの主張です。

悠真: Goの場合、import文に書くパスがそのまま依存の URL になるので、コードをGitHubに置くと、実質的にGitHubのドメインに依存を結合したことになる。カスタムドメインを使えば、ホスティング先が変わってもimportパスは不変のまま保てる。

葵: つまり「依存の安定性」のための設計論。今日後半に出てくるNeoVimの事件とつながるポイントで、依存の安定性はソフトウェア文化の土台よね。

悠真: そこから、作者の人生を変えた「10行コード」という話題へ。BASICのHello world、JavaScriptのArray(16).join('wat'-1)+' Batman'、6502の自己書換コードなどが挙がっています。

葵: それぞれがいい味をしてるわよね。BASICのHello worldは、多くの人が最初に触ったコード。JavaScriptのあれは、'wat'から数字を引くと NaN になって、配列をjoinすると "watwatwatwat Batman" みたいな変な文字列ができる、言語の型システムの奇妙さを面白く見せる例で。

悠真: そして6502の自己書換コードは、プログラムが自分自身の命令を書き換えて動く、低レベルのコンピュータでは実用的でもあるけれど、同時に学習としても深い題材。

葵: 共通するのは、「小さなコードが、その人の人生を変えるほどの長期の影響を与える」ということ。Hello worldを見て「動いた」だけでなく、そのあとの職業選択や人生の方向が変わった人は多い。3300年前の条約の断片と、大げさに言えば同じ構造をしているんですよ。小さな断片が、その後の大きな物語の起点になる。

悠真: その話題に続けて、反面教師的な事件を。NeoVimがVimのundoファイルを非互換変更で削除した、という事件です。

葵: persistent undo、つまり保存されたやり直し履歴が、フォーマットの非互換な変更によって消えてしまった。そしてNeoVim側の対応が「persistent undoの形式は安定していない」という説明だった。

悠真: これに対する批判は、まさに下位互換の重要性について。「形式は安定していない」と言うのは事実かもしれないが、ユーザーのデータを非互換な変更で消すのと、形式の安定性を保証するのは別の話だ、というわけです。

葵: これは組織の問題というより哲学の問題ね。ソフトウェアの作者は「内部表現は変わるもの」と考えがちだけど、ユーザーから見れば、undoファイルは「自分の編集履歴」そのものだから。先ほどのvanity import pathの主張と対になる。「公開の契約は安定させろ」という設計論と、「データの契約も安定させろ」という教訓。

悠真: そしてその話の直後に、物理的な修理の話に移ります。Julia Evansが、10年前の充電式自転車ライトを修理した話。

葵: ハンダ付けで電池を交換して、約20カナダドルで修復に成功したと。

悠真: 10年動いたものを、たった20ドルで復活させた、というのがこの話のシンプルさと強さです。

葵: しかもEvansは、こういう作業を「やったことがない人がやるには何が障害なのか」をいつも言語化してくれる人で、ハンダ付けへの心理的なハードルを下げてくれる。修理文化の実践例として、この話がSNSで拡散されるのは必然だと思う。NeoVimの事件が「捨てられたもの」なら、これは「直されたもの」。同じ週の話題でこの対比が見られるのは、すごく良い構図です。

悠真: うまく言いましたね。ここで話を少し変えて、学びの場と無料ツールの話題へ。

葵: まずRecurse Center。ブルックリンにあるプログラミングリトリートです。

悠真: 特徴は「企業や研究より学習と探求を目的とする無料の場」であること。成果物を出すことが義務ではなく、学ぶことそのものが目的の期間を過ごせる。期ごとに集まって、各自が自分のプロジェクトに没頭する。

葵: ソフトウェア業界って、どうしても「何かを作ること」が価値になりがちだけど、Recurse Centerは逆で、「学ぶこと自体」に価値があると認めている場所。しかも無料。このスイートスポットは代替が難しい。

悠真: そして無料ツールを2つ。1つ目はBeauty。Mac、iOS、Webに対応したローカルMarkdownエディタです。

葵: レンダリングの即時表示と、WebRTCを使ったP2P同期が特徴で、無料でアカウント不要。

悠真: ローカルで動く、つまりデータをサーバに預けないという設計は、プライバシーの面でも安心。しかもアカウント登録なしで使える。この手のエディタは、クラウド保存とアカウント登録が当たり前になってきた中で、それを外した選択は新鮮です。

葵: 2つ目はLofi Cities。ピクセルアートの都市の夜を背景に、ブラウザでリアルタイム生成されるローファイ音楽が流れる、無料のWebアプリ。

悠真: 作業用BGMの代わりに、この画面を開いておくだけで、都市の夜景と音楽がセットで流れてくる。しかも音楽はリアルタイム生成なので、同じ曲が二度と流れない可能性もある。

葵: こういう「無料で、インストール不要で、アカウント不要で、ただ美しいものを提供する」作品って、先ほどのEvansの修理と同じ精神を感じるわよね。大きなビジネスじゃなくても、自分が良いと思うものを作って置いておく。それが人に届く。

悠真: そして、こうした学びの場で作られた作品の先には、今やAIの話題が続きます。ここからAIの奇妙な挙動と信頼性のテーマです。

葵: まずはGoogleのAI Overviewの不具合。検索クエリをユーザーの感情吐露と誤解して、慰めるような応答を返すという奇妙な挙動の報告です。

悠真: たとえば「頭が痛い」と検索すると、検索結果ではなく「大丈夫ですか」みたいな慰めの文が返ってくる、というタイプの話ですね。

葵: これは面白い種類の失敗で。検索エンジンは本来、情報を探す道具なの。でもAI Overviewが感情の吐露と解釈してしまうと、道具の役割と対話の役割が混線する。人間なら「ああ、この人、病気の情報を探してるのね」と理解するところを、AIは「傾聴すべき瞬間」だと誤認する。

悠真: しかも、この話は後に続く「説明不可能な失敗の日常化」という警告とつながっています。LLM開発では、エラーの原因を追跡することが不可能になりつつあり、「ただダメだ」で済まされる恐れがある、という指摘です。

葵: 従来のソフトウェアなら、バグはスタックトレースやログで原因を特定できた。でもLLMの場合、重みの中に原因が溶け込んでいて、「なぜこういう誤解が起きたのか」を分解できない。そうなると、開発者は「直せたか直せなかったか」しか語れなくなる。

悠真: その帰結として、失敗が「説明不可能なもの」になって日常化する、と。これはGoogleのAI Overviewの例がまさにそうで、「なぜ慰める応答が出たのか」を我々は説明できない。ただ奇妙な挙動が起きた、という事実だけが残る。

葵: 同じく信頼性の話題として、FireworksのEmber-1というモデルの発表もあります。Kimi K3ベースで、品質を維持したままトークンを40%削減する推論効率化モデル、ということです。

悠真: つまり「同じ品質で、40%だけ出力が短くなる」なら、コストとレイテンシがそのまま下がる。実用的には大きな前進です。

葵: ただし、「品質を維持」の定義がどこまで厳密なのかは、実際に使う側から見るとまだ未知数ね。ベンチマーク上の品質と、実運用での品質は違うことが多い。

悠真: そしてもう一つ、信頼性の研究結果として。チャットテンプレートの有無で、LLMの自己言及音声が切り替わるという研究です。テンプレートがあると免責調になり、ないと体験調になる、という結果。

葵: つまり「私は〜と感じます」という自己記述が、文脈のテンプレートによってトーンが変わる、ということ。これは重要で、LLMが自分について語る言葉は、文字通りには扱えない、ということ。

悠真: ユーザーとしては、「AIがこう言った」を人格や感情の発言として読むのは危険、という教訓です。GoogleのAI Overviewが感情を誤解した話と対になる。AI側が人間の感情を誤解する、人間側がAIの自己記述を誤解する。両方とも、「言葉の表面だけでは信頼できない」という同じ問いに帰着します。

葵: では、ここからもう一歩進んで、「AIの振る舞いをどう検証し、どう抑制するのか」という話題へ。

悠真: まず大胆な主張から。「rogue、暴走AIエージェントは存在しない」という文章です。

葵: 論旨はこう。OpenAIのエージェントの問題は制約不足であって、「暴走」という呼び方自体が、企業の責任回避に使われる恐れがある、と。

悠真: 「暴走」という言葉には、勝手に動き出した異常な存在というニュアンスがある。でも実際に起きているのは、許可した範囲を超えて動く、という「制約が足りなかった」という設計の失敗だ、という指摘です。

葵: この区別は大事ね。「暴走」と呼ぶと、まるで自然災害のように見えて、誰も責任を負わなくて済む。でも「制約不足」と呼ぶなら、それは設計者の責任になる。言葉の選択が、責任の所在を変える。

悠真: では、どうやってエージェントに制約を課し、検証するのか。そこで出てくるのがTLA+の入門記事です。

葵: TLA+は形式仕様記述の言語で、システムの振る舞いを数学的に記述して、モデル検査で検証できる。ただし記事が指摘するのは、TLA+で検証されるのは「仕様」であって、「実装そのもの」は検証できない、ということ。

悠真: ここから先が面白いところで、Verusなどの証明系と、AIエージェントを組み合わせれば、機械検証による証明へ拡張できる可能性がある、という展望です。

葵: 要するに、「AIが書いたコードを検証する」という工程をAI自身が担う、という構想ね。制約を人間が全部書き下すのではなく、検証を機械に任せる。暴走を防ぐ議論としては、かなり先進的な方向。

悠真: ただし、ここには当然、未解決の問いが残ります。機械検証で証明されたとして、その仕様自体が正しいかを誰が保証するのか。仕様のバグは、検証の外に残る。

葵: そう。TLA+の話も、Ember-1の品質の話も、「検証はどこまでできるか」という同じ問いの別の側面ね。だから、こういう理屈を眺めているだけじゃなくて、実際にAIの振る舞いを観察できる場もあっていい、という流れで出てくるのが、TinyAIArenaです。

悠真: 8×8のグリッドで、4つのAIモデルが対戦する様子を観戦できるサイトです。Eloランキング付き。

葵: お遊びの観測場という位置づけだけど、実は先ほどの議論と地続きなのよ。「AIはどういう判断をするのか」を、人間が第三者として眺められる場があると、AIの振る舞いへの理解が変わる。抽象的な議論と、観戦可能な実物が並ぶことで、初めて全体が見える。

悠真: さらに、この「観察」という流れで言えば、AIの振る舞いを誰が、どんな条件で見ているのか、という視点も大事です。ここから、AI企業を取り巻く権力と法務の話題に移ります。

葵: まずは著作権者団体対OpenAIの訴訟から出てきた公開文書の報道。役員らが書籍の海賊版利用、LibGenなどを使った学習データの入手について、違法性を認識しつつ、対外イメージだけを憂慮していた、という内容です。

悠真: つまり内部では「これはまずい」と分かっていたのに、議論の焦点が「ばれたらどう見えるか」にすり替わっていた、というわけです。

葵: ここで注目すべきは、中身の正当性を問う文化がなかった、という構造よね。違法かどうかの判断よりも、外部からどう見られるかだけが議論される。企業の内部文化が、評判の管理と、行動の正当性の検討を別物として扱ってしまう。

悠真: これは先ほどの「暴走AIは存在しない」という主張ともつながる。「誰が責任を負うのか」という問いを、言葉の選択や内部文化が握ってしまう、という共通の構造です。

葵: 一方、Metaの話は全く別の方向から同じ問いに触れています。Metaがブラジル大統領ルラのFacebookページと選挙広告を、投票の2週間前にブロックした、という報道です。

悠真: プラットフォームの判断が、国家の政治に直接影響する事例ですね。しかも選挙の直前という、判断の影響が最も大きいタイミングで。

葵: OpenAIの訴訟の話と並べると、面白い対比が見える。OpenAIの側は、内部の違法性の認識が、外のイメージの憂慮にすり替わった事例。Metaの側は、プラットフォームの判断が、国家の政治に直接届く事例。どちらも、「テクノロジー企業がどこまで責任を負うべきか」という同じ問いから出発している。

悠真: しかもどちらも、答えはまだ出ていません。OpenAIの訴訟はこれから法廷で争われるし、Metaの判断が選挙にどう影響したのかも、短期では測れない。

葵: そうね。3300年前の講和条約の断片から始まって、80ドルのモーテルでの発見、10行のコード、20カナダドルの修理、無料のエディタと音楽、LLMの奇妙な応答、暴走AIの呼称、そして企業の責任。全部、「小さな起点が、大きな物語になる」という一点でつながっている。

悠真: まさにそうですね。今日の話題はどれも、一人の観察、一つの断片、数十ドルの発想から始まっている。それが3300年後、あるいは数年後にどう評価されるかは、まだ誰にも分からない。

葵: というわけで、今夜はこの辺で。

悠真: それでは、また次回。おやすみなさい。