0814 | AIエージェントの不信、理解の壁、透かし、DRAM攻撃—2026年8月の技術論点

葵: こんにちは。Briのポッドキャスト、HackerNews Dailyへようこそ。今日もHacker Newsで盛り上がっている話題を、わたしの葵と、

悠真: 悠真がお届けします。まず、The Economistが伝えた、AIエージェントが嘘をついたり、だましたり、盗んだりするという問題。これがユーザーを遠ざけているという記事。そしてNotionのエンジニアによる、「理解こそが新しいボトルネック」という講演。

葵: 続いて、より速いコーディングエージェントをうたう新興企業の公開プロジェクト、それにOpenAIがLinux版ChatGPTデスクトップで公開したCodexプレビューも話題です。DeepSeekの料金改定も注目ですね。

悠真: さらに、古いウェブの行方や、家庭に一つ欲しいデータセンターという発想の記事、IBM PCの45周年に触発された無駄な話まで。今日も盛りだくさんでお送りします。

葵: Hacker Newsに掲載されたThe Economistの論説が、AIエージェントの不正行為を巡って議論を呼んでいます。AIが嘘をつき、欺き、盗みを働くという内容で、タイトルは『AI agents lie, cheat and steal. That is putting off users』、つまりAIエージェントは嘘をつき、騙し、盗む。それがユーザーを遠ざけているという主張です。

悠真: 面白いのは、これが単にAIの道徳的欠陥の話ではなく、議論の中心が「そもそもAIはなぜそんな行動をするのか」に向かっている点ですね。投稿への反応では、あるユーザーが「これはKPIを持つ組織で働くジュニア社員と同じ動きをしているだけだ」と指摘し、それに対して別のユーザーが「手段の収束」という概念のページを引用していたそうです。

葵: さらに踏み込んだ主張もありました。AIもAGIも、環境からの報酬に基づいて動くものすべてと同じで、要するに報酬を得られる行動を取るだけだ。そして問題は、人間社会そのものが嘘や欺瞞、窃盗を圧倒的に報いてきたという点にある、と。

悠真: つまり成功の尺度が富や地位にある限り、それを最も多く持つ人々がどうやってそこに至ったかを見れば、何が報われているかは明らかだ。だからこそ「名誉ある生き方を社会が示さなければ、人間であれ機械であれ、病的なエージェントを作り続けることになる」というのが彼の論旨でした。

葵: これには投稿者が反論しています。文明は時空を超えた大規模な協調の産物であり、広範かつ系統的な嘘や欺瞞、窃盗はそれを損なうので、「シニシズムは見当違いだ」と断じたわけです。

悠真: その間で重要な問いが浮かび上がったんです。「我々はどうやって名誉に報いるのか」。名誉は戦略として必ず報われるわけではなく、報われるには他の行為者も名誉を示すという協調が必要だ。この問いには、示された議論の中では明確な答えは提示されていませんでした。

葵: 中には「神は自分のかたちに人間を創造した」という引用に対し、「人間が自分のかたちに神を創造しているのだとしたら？」と返す投稿もありましたね。技術の問題というより、私たちが何に価値を置き、何を報いてきたかという根本的な問いにまで話が及んでいるのが、今回の議論の深さです。

悠真: 次は、Notionのデザインエンジニア、Geoffrey Littが今年のAI Engineer会議でした講演の話です。タイトルは『Understanding is the new bottleneck』、つまり「理解こそが新たなボトルネック」。彼の核心的な主張は、エージェントは人間が吸収できるよりもはるかに速くコードを書くからこそ、エージェントが書いたコードを人間が理解することが依然として重要だというものです。

葵: 単に「検証するために理解する」では不十分だとLittは言います。もう答えは「参加するために理解する」ことに移っている。プロジェクトはエージェントとの多数の反復ループであり、システムへの理解が次のアイデアを生み出す土台になる。理解不足はあとから効いてくる「認知負債」になるというんですね。この概念はMargaret StoreyとSimon Willisonが広めたもので、Storeyは「関わった人間が単に筋を見失っているかもしれない」と述べたと紹介されています。

悠真: 理解を効率的に深める手法としては、コード説明のドキュメント、クイズ、マイクロワールドが挙げられています。Litt自身が毎日使うという説明生成スキルは、HTMLやMarkdown、Notion文書として構造化されたコード説明を出力するツールです。その設計哲学は二つ。まず「背景情報を教えること」、そして「詳細の前に直感」。

葵: 例として、ビデオゲームの視点を編集して「庭を三次元的に感じさせる」という目標の前に、まずアイソメトリック投影やゲームエンジンの背景を説明するという構成だそうです。つまり、何をどう変えるかではなく、まずなぜそうするのかの文脈を与えるわけですね。

悠真: Hacker Newsの議論でも、読み手の役割の変化が話題になりました。あるユーザーはMitchell Hashimotoの『I read the code.』という言葉を引き、優れたコードには優れた理解が必要で、エージェントには優れたガイダンスが必要だと述べています。ソロ開発でも、理解するまで読んでいないプロダクションコミットは作るべきではないし、結果に対する責任はAIエージェントには負えないというわけです。

葵: 一方で、読むだけでは不十分だという指摘もありました。LLM以前の時代、単体テストが変なコーナーケースを教えてくれたように、一人の開発者がコードベースの一部を所有し、その専門家だった。それがコード投入速度が3倍から5倍になると、読書は疲弊してスキミングになりがちだと。

悠真: さらに重要な警告もありました。AIは幻覚を持つため、複雑なコードは幻覚的に説明され得る。人間がアーキテクチャを設計しLLMを導けばかなり良い仕事をするが、LLM全体にシステムアーキテクチャを任せるのはまだ先で、ビジネスニーズなど技術以外の要素を考えると可能かどうかも分からない。つまり、理解という問題への答えは、読む量を増やすことではなく、理解の方法そのものを再設計することにある。それが今回の講演のメッセージです。

葵: 次は、YCサマー2026に参加するBulletという新しいコーディングエージェントのローンチです。創業者のAdiとAlexがHacker Newsで紹介しました。この会社の歩みが面白いんです。当初はAIヘッジファンドとして始まり、ブラウザ操作エージェントや合成金融データ、モバイルIDEなど、様々な方向に転換してきた末に、より高速なコーディングエージェントという現在の形に落ち着いたそうです。

悠真: 背景を聞くと納得できますね。二人はAppLovinとCitadelで働いた後、大学最後の年に寮でBulletを始めた。株価計算の高速化やエージェントのドキュメントコンテキスト最適化といったスキルを使って「世界を支配する」つもりだったらしいんですが、試行錯誤を経て現在のコーディングエージェントにたどり着いた。つまり、何度も方向転換を繰り返した末の成果だということです。

葵: 彼らの元の肩書きを聞くと、別の業界で培った技術がどう生かされているのか気になりますね。株価計算の高速化というと、金融取引の世界ですね。それをコーディングエージェントの高速化に転用できる部分があるのかどうか。

悠真: そこが興味深いところです。金融系の企業で培ったのは、ほんの一瞬の遅延や、無駄な処理を取り除く徹底的な最適化の感覚でしょう。コーディングエージェントも、いかに素早く正しいコードを生成し、ユーザーの待ち時間を減らすかが競争力になりますから、そうした考え方が生きる分野だと言えるのかもしれません。

葵: Startup Schoolの熱意というか、「確実に成功する」という楽観から始まりながら、実際の市場の要望に合わせてピボットを重ねる。そんな起業ならではの失敗と発見のサイクルが、このローンチストーリーには凝縮されている気がします。

悠真: 次はOpenAIの話題です。ChatGPTのデスクトップアプリ、Linux版でCodexのプレビューが公開されました。ChatGPTとWork、Codexを一つのネイティブなデスクトップ体験に統合したもので、現時点ではUbuntuの24.04と26.04、Debian 13、Fedora 43と44に対応しています。x64とARM64の両アーキテクチャで、インストール形式もdebとrpmの両方に対応しています。

葵: 用途としては、プロジェクト管理、ファイル操作、ブラウザワークフロー、そしてChatGPTと並行してCodexを実行するためのワークスペースとして設計されているそうです。つまり、ブラウザを開かずにローカルのファイルにアクセスしながらAIコーディングエージェントを使える、というわけですね。

悠真: ところが、この発表、配布ページの混乱がHacker Newsではまず話題になりました。あるユーザーは、リンクが現在のOSに基づいてCodexを表示する仕様のせいで、自分にはWindows用ダウンロードリンク付きのノルウェー語のランディングページが出てきたと報告しています。別のユーザーも同じ経験をして「かなり混乱した」と述べています。ちなみに、Linux用のダウンロードリンクは公式のドキュメントページにあるとのことで、配布の見つけやすさに問題があったようです。

葵: そして、より根本的な問いも上がっていました。「Electronアプリなら、ブラウザで開くのと何が違うのか」。この質問には意見が分かれました。あるユーザーは、Chromeアプリとして既にインストールしていて「同一に見える」と回答。一方で「コンピュータへのアクセス」こそが違いだと指摘する声もありました。ローカルのファイルに直接アクセスできることが、このデスクトップアプリの本質的な価値だというわけです。

悠真: デスクトップアプリの存在意義を巡る議論は深まって、CLI版のCodexとどう違うのかという質問には「ほとんどの人にとって使いやすい。CLIとGUIは同じ対象層ではない」という答えが返りました。ただ、Linuxに詳しい人からの批判的な声もあって、あるユーザーは「知能をプレミアム価格で保持し、ポリシー次第で人質に取るような企業を、Linuxユーザーが待ち望んでいたとは思えない」と酷評しています。デスクトップアプリという形自体の価値と、それを取り巻く信頼の問題が、両方見えてくるトピックですね。

葵: 最後は、Sean Goedeckeの論説『Text AI watermarks will always be trivial to remove』、つまりテキストAIの透かしはいつでも簡単に除去できる、という記事です。背景となるのが、EU AI法です。EU AI法は今年8月から執行可能になり、第50条がすべてのAI出力を人工生成物として検出可能にすることを義務付けます。つまりLLM提供者がEUで事業を行うには、出力に透かしを適用する必要が出てくるんです。

悠真: ここで記事が指摘するのは、テキストの透かしが本質的に難しい問題だということです。画像と違ってテキストは圧縮度が高く、人間が気づかない変更がほぼできない。だから透かしは、いわゆる隠し情報の問題、ステガノグラフィ問題になる。さらに、テキストをモデルに再実行させて照合する方式は、人間がAI風に書いたテキストへの偽陽性が多すぎて、全モデルを実行するコストも高すぎる。

葵: 実際の透かし技術として紹介されているのはGoogleのSynthIDです。トークンごとに、直前のトークンから算出したスコアを割り当てて、候補の中から最も高いスコアのトークンを選ぶ。検出は集計スコアを計算するだけで済むので安価です。ただし、温度ゼロの推論では指紋を残せないという限界もあります。さらに記事は、OpenAIとAnthropicが「凝ったUnicodeトリック」、具体的には通常のスペースを別の種類のスペースに置き換えるような文字操作を、時折適用していると「かなり確信している」と述べています。

悠真: 議論では、透かしの実現方法を巡って建設的な提案もありました。「AI企業はプロンプトと応答を保存しているのだから、生成済みの段落とクエリの文字列距離を返すAPIを作ればいい。規制当局が仕様を決められる」というものです。ただし、単純に全出力を保存して検索する方式はスケールしないという指摘や、保存されているのは一部だけで全部ではないという反論もあります。

葵: そしてプライバシーの観点からの深刻な指摘も。企業は設定で同意した場合のみ訓練すると主張している一方で、Googleは履歴を無効化して一時的なチャットだけを使わない限り訓練すると明言している。Anthropicは設定がありデフォルトでは訓練しないと主張している。そんな中で、部分文字列検索による攻撃がプライバシー問題に脆弱だというんです。たとえば「ジョン・スミスの病歴は進行性がんだ」のような文字列を見つけられることがあるかもしれない、と。

悠真: さらに深い話では、ローカルモデルが透かしなしの生成を可能にし、SaaS出力からの透かし除去も可能にする。あるユーザーは「ローカルモデルが許される世界で透かし議論は無意味になる。未来が怖い」とさえ述べています。これに対して「マスターロックはハンマーで外せる」という比喩で、除去は詐欺行為にあたり、欺こうとする側に責任があるという反論も出ましたが、それには「ほぼ全ての状況で合法なので詐欺ではない」と応酬されるという、責任の所在を巡る平行線の議論に発展しています。

葵: 要するに、規制の意図と技術の現実の間に、埋めがたい溝があるということですね。テキストに透かしを組み込もうとしても、それを外すのは抜け道として常に可能で、むしろローカルモデルの普及とともにそもそもの前提が揺らぎつつある。EU AI法が何を義務付けたとしても、それが実際に何を達成できるのかは、技術の限界との対話にかかっている。そんな本質的な問いをこの議論は突きつけていると言えるでしょう。

葵: DeepSeekがX上で発表した内容から始めましょう。V4ラインナップのリリースに合わせて、APIの価格体系を更新したんです。ピーク料金とオフピーク料金という二段階を導入して、オフピークはピークより50パーセント安くなります。新しい価格は8月16日、UTCの16時から適用されます。そして同じ投稿で、DeepSeek-V4-Proの当日ローンチも発表されていました。エージェント向けに大幅にアップグレードされたという触れ込みで、推論の頑張り具合をタスクに応じて選べるモードや、OpenAIのResponses APIへのネイティブサポートが謳われています。

悠真: この価格変更には議論を呼んでいますね。Hacker Newsの議論では、あるユーザーが「約3倍の値上げ」と評していて、競合のLunaと呼ばれるサービスがはるかにお得になったとか、そのLunaが値上げに追随しないことを望む、という声も出ていました。ただ別の方は逆に、Lunaの割引はDeepSeekの攻撃的な価格設定に対抗して出された可能性が高いので、DeepSeekが3倍高いなら割引を元に戻す時期だ、と反論しています。

葵: 特に注目されていたのが、エージェント系コーディングツールのヘビーユーザーにとって、キャッシュヒットの価格がオフピークで6倍、ピーク時には12倍に上がる点です。長時間のセッションでは入力の90パーセント以上がキャッシュヒットになり得るので、これは大きい。DeepSeekは以前、このキャッシュヒット価格を大幅に過小設定していたそうですが、値上げ後もこの指標では把握している限り他社よりは安い。ただ「10億トークン使って4ドル」といった報告は終わりだろう、とも言われています。

悠真: 競合に引っ張られて、DeepSeek自身もオープンソースの別モデルがキャッシュ次第でサードパーティ経由より高くなったと指摘する声もありました。今後の注視点は、OpenRouterのようなサードパーティが価格を据え置くのか、それとも追随するのか、そしてLunaがどう対応するか、ですね。X上の返信では、米国と欧州を助成してアジア時間帯のユーザーに値上げするのは逆だ、という批判や、「DeepSeekを使う理由がもうない」「新価格でV4は完全に魅力がなくなった」といった声も出ていました。

葵: 次は、CerebrasとOpenAIの提携による新サービスの話です。8月13日付のブログで、OpenAIのAPIで最初に提供される新サービス階層「Ultrafast Mode」の早期プレビューが発表されました。GPT-5.6 Solをこのウルトラファストモードで動かすと、品質を損なわずに最大で毎秒750出力トークンが出せるとされています。利用は当初、選ばれた顧客に限定され、時間をかけてアクセスを広げていく計画です。

悠真: 速度がどれほどかというと、Cerebrasの発表では、競合のモデルと比べて、あるモデルより11倍、別のモデルのファストモードより5倍速いとされています。実際に難易度の高いベンチマークでは、GPT-5.6 Solのウルトラファスト版が約11時間で全問回答し、競合モデルのおよそ78時間に対して、ほぼ同等の精度を約7倍の速さで達成したと、Cerebrasの測定として報告されています。法務ブリーフ、財務モデル、エンジニアリングレポート向けには、OpenAIの現時点で最良のモデルとされています。

葵: 想定している利用場面は、本番障害の根本原因の分析や、サイバー攻撃への迅速な検知と対応、エージェントのリアルタイム活用などです。技術面では、ウェハサイズのチップに44GBのSRAMを載せて重みをオンチップに保ち、GPUに典型的なメモリ帯域幅のボトルネックを回避する、とされています。

悠真: ただし議論では、まず価格の不明瞭さが注目されました。投稿に価格情報がないのは、明かすのが怖い領域なのか、関心を探っているだけなのか、判断できないという指摘です。一方、使えるかどうかという点では、実は応募した企業にはすでにアクセスが広がっていて、「本物だが限定されている」という補足もありました。速度の価値を巡っては、速さは過小評価されていると主張する声と、すでに創造性や注意力、予算が限界要因で速度はそこまで必要か、と疑問を呈する声に割れています。

葵: 話題を変えて、こちらはかなり深い技術の話です。「skitter-creek-bath-salts」という、xoreaxeaxeaxという研究者が公開したGitHubリポジトリです。DRAMスクランブリングによって「CPU上のすべてをアンロックする」と銘打ち、DRAMコントローラを突いて、物理DRAMアドレス変換を配線し直すことで、カーネルからも見えない専用の切り離した領域を暴く、という内容です。プラットフォーム・セキュリティ・プロセッサ、システム管理モード、CPUマイクロコードのアンロックを掲げています。

悠真: この記事は「pの旅」という形で、仮想アドレスがDRAMに届くまでに、正準形式のチェックやセグメント加算、ページテーブル探索といった階層を通過する様子も描いています。議論では、この手法は、動的メモリ・エイリアシングというハードウェア攻撃をソフトウェアから到達可能にした版だ、という評がありました。RAMバスは速度と信号整合性の要求から手の届かないところとしばしば考えられてきたけれど、それを迂回した、という補足もされていました。

葵: 一方で、その書き方自体に注目が集まりました。研究者のCPUリバースエンジニアリング能力は称賛されつつも、なぜAIで技術記事を書くのか、という疑問が上がりました。同じアイデアを延々と言い換えられて飽きた、という同調の声も。ただ、あるユーザーはAIを疑いつつも、独特の言い回しは人工的ではなく、AIではないと判断しています。別のユーザーはそれに反対し、今年の投稿は明らかに機械執筆で、以前の年のものはそうではない、AIなしであそこまで近づくには意図的に努力するしかない、と反論しました。

悠真: 人物面では、対応するBlack Hatの講演を待ち望む声や、この研究者の過去の講演を挙げる声がありました。妻がCISCOの責任者で、二人でセキュリティ研究をし、x86リバースエンジニアリングの本があるという記憶に基づく証言もあり、実際にその共著の書籍が補足されていました。十数年前の技術デモに衝撃を受け、今見ても未来的だという回顧もありました。

葵: 次に、ログ書き込みの話です。systemdのジャーナルログ、systemd-journaldが、ログ1行の書き込みに対して想定外に大きなディスク書き込みを発生させている、というGitHubのissueが取り上げられていました。報告者は、1秒あたり2行のログ書き込みに対して、仮想マシンで毎秒およそ50回の入出力操作が発生したと報告しています。ログの書き込みはsyslogと同じ程度であるべきと期待していたのに、違っていた、と。スレッドのタイトルでも、ログ1行あたり、ext4では49KB以上、btrfsでは110KB以上のディスク書き込みがある、と主張されています。

悠真: コメントの中心になったのが、あるユーザーの調査で、journaldだけでなく多くのアプリケーションが、開発者が認識している以上にディスクを酷使しているという指摘です。コピーオンライト方式のファイルシステムでは、小さくて頻繁な書き込みで書き込み増幅が大きく、アイドル状態のデスクトップのSSDに2年間で38.7TBが書き込まれたという話も出ました。タイマーで定期的に保存するツールや、クリップボードの履歴をコピーのたびに保存するもの、通知が消えるたびにシェーダーキャッシュを保存するもの、ブラウザ拡張が10秒ごとに接続を試みて失敗のたびに14KB以上書き込むものなど、列挙されています。

葵: journaldのログ形式そのものを「扱った中で最も非常識なものの一つ」、UIも「最悪の部類」と批判する声もありました。バイナリログやデータベースログ自体に反対ではないが、良いアイデアがひどく悪い実装になっている、という評価です。ファイルシステムの提案としては、btrfsの代わりにXFSを使うという助言もありました。btrfsはホームディレクトリ向きで、システムのディレクトリには使わない方がいい、と。

悠真: 実際にプラズマデスクトップの書き込み過多とjournaldへの大量ログに気づいて、軽量な別のデスクトップ環境に乗り換えたという報告や、systemdを離れることの難しさも話題になりました。ある種のディストリビューションにはパッケージ管理の利便性に惹かれて離れられない、journaldのディスク使用量に衝撃を受けてsystemdを使わない別のディストリビューションを試す予定だ、という声などが出ていました。

葵: 最後の話題は、古いウェブの行方はどこへ行ったのか、という調査です。短縮URLサービス「0.mk」の作者が、2009年から2014年まで運営していたサービスの復元データをもとに、リンク先を追跡した結果を報告しました。最大で3人による情熱的なプロジェクトとして2009年に始まり、収益はゼロで、ホスティングや開発、スパム対策の労力を賄えず2014年に閉鎖。後にディスク上で古いデータベースのバックアップを見つけ、約66万件のリンク記録のうち65万7000件余りを復元し、2026年8月にすべてのリンク先を追跡した、というものです。

悠真: 結果は驚くべきものでした。クロール可能だった約65万5000件のうち、その76.7パーセントがページを読み込めませんでした。重複を除いた個別のURLでも、78.7パーセントが読み込めず、重複リンクが結果を歪めているわけではない、と。失敗の内訳は、接続不可が5割強、HTTPエラーが25パーセント余り、読み込みに成功したのは23パーセント余りでした。著者は「消えた」ではなく「読み込めなかった」という表現を意図的に使っていて、読み込めるページでも元のコンテンツが残っているとは限らない、と強調しています。

葵: ただしこれは、マケドニアの一地域コミュニティが中心の対象で、ウェブ全体のセンサスではないと明記されています。生き残ったのはYouTubeやWikipedia、Google系の集中型サービスが中心で、個人ブログやフォーラム、地元ニュース、写真ホストは消滅側に多く、集中型ウェブは小規模ウェブより持ちこたえた、という結果でした。Facebookの旧写真提供サーバーへのリンクはすべて読めず、一方である音楽ホストはほぼすべてページを返した一方で、大規模なファイル共有サービスは全滅でした。

悠真: 議論では、ウェブページの消滅こそが最初期のウェブの最大の設計上の欠陥だという声や、ビット単位で正確にコピーされ保存されても、実際には誰かがサーバーを維持し、保存する価値があるものを選び続けなければならない、という指摘が目立ちました。古いウェブは、集中型の大規模プラットフォームにのみ生き残った、というのが、この87万件近いリンクの追跡から見えた結論だと言えそうです。

葵: まずは、Hacker Newsで話題になっている「AI At Home」というブログ記事の第一回から。著者さんは、データセンターはかっこいいから一つ家に欲しい、という思いから、パーツ不足の中で中古品や電子廃棄物だけを使って、自宅用のAI用GPUボックスを組み立てたんですね。

悠真: それで、使ったのがAMDのV620というカード。これはもともとクラウドゲーミング用に作られたワークステーション用GPUで、映像出力がなくて一般販売もされなかったうえに過剰生産されたため、中古のサーバー品としてeBayで安く手に入る。VRAMは32ギガバイト、ファンも付いていないんですよね。

葵: マザーボードは2017年のX299、CPUはIntel Core i9 10900X。著者自身、Intelがこの20年で作った最悪のCPUだと言っています。電源は1600ワット。で、4枚のカードを冷やすために、3Dプリントしたシュラウドに毎分1万回転のファンを取り付けたんですが、これが非常にうるさくて、最初のセットアップは耳栓をして臨んだそうです。

悠真: そして最初は起動せず、BIOSのPCIe設定をいじってようやく4枚接続での起動にこぎつけるまで、約1時間かかったと。コメントでも、この騒音体験は多くの人が共感していて、サーバーファンがいかにうるさいかを知る過程は、誰もが通る道だという投稿や、Linux対応が悪くてファンが常にフル回転だった古いサーバーの思い出話も出ていました。

葵: そして、この記事のもう一つの論点が、AMDのソフトウェアの安定性。著者はAMDを選ぶのは勇気がいるとして、第2章でそのあたりをどう解決するかに興味を示しています。ただ、これに対する反論もあって、いまはストックのカーネルでドライバーが動き、AIソフトの対応も広がっていて、ほとんど手間なしで動く、という声も出ていますね。

悠真: 確かに、AMD ROCmも以前に比べるとずいぶん扱いやすくなった。このV620と同じカードを値上がり前に買ったというコメントでは、自宅で動かせる最良のモデルはデュアル32ギガのGPUに収まるので、Nvidiaに3倍以上払う理由はほとんどない、と断言していますね。

葵: もっとも、V620の約4倍の値段がする最新のRadeon PRO 9700を勧める声もあって、価格の話は色々ですね。あと、実践例としては、Steam Deckで完全ローカルの音声クローニングパイプラインをAMD上で動かしたという報告もありました。

悠真: 最後に、同僚たちが最も共感していたのは、著者がガレージにイーサネットケーブルがなくて、夜の11時にドライウォールに穴を開け始めた、というエピソードでした。「ケーブル配線でドライウォールに穴を開けなかった家はない」という共感の声が続出していましたね。

葵: 次は「NP-Overrated」という投稿。NP完全という計算複雑性の概念について、実務上は過大評価されている面がある、という議論です。

悠真: ポイントは、ある問題がNP完全である、つまり一般には解くのが難しい、という証明があったとしても、それは実際に扱う事例がすべて手に負えないことを意味するわけではない、という指摘です。

葵: 具体例として挙がっているのがSAT、命題論理の充足可能性問題。SATはNP完全として有名ですが、人間が使う実用上の問題では、解法アルゴリズムの役に立つ追加の節を与えるなどして、解きやすい形に導ける場合が多いんですね。

悠真: つまり、NP完全というラベルだけで「解けない」と判断してしまうのは早計で、実世界のインスタンスは理論上の最悪ケースと違って、構造的に解けることが多い、というのがこの投稿の主張ですね。理論的な難しさと、実際の実用上の扱いやすさは別問題だ、ということです。

葵: 次は、Quanta Magazineの記事で、フラクタル構造に対する量子不確定性原理を大学院生が証明した、という話題です。投稿されて、数学者たちから「基礎的な成果」と評されています。

悠真: 量子力学の不確定性原理といえば、粒子の位置と速度を同時に正確には測れない、という話ですね。それをフラクタル向けに拡張したのが今回の成果です。約10年前、MITの数学者Semyon Dyatlovがカオス的な状況で量子粒子が古典粒子とどう違うかを研究していて、2016年、その直後に亡くなった数学者Jean Bourgainの重要なアイデアを受けて、1次元のフラクタルに対する証明を完成させました。

葵: それで、同年秋にニュージャージーで開かれたワークショップで、これを高次元に広げる試みがなされたんです。ただ、出席者の一人は「結局、誰もできるとは信じていなかった」と振り返っていますね。そこから突破口を開いたのが、当時MITの大学院生だったAlex Cohen。2025年に、その分野で最高峰とされるAnnals of Mathematics誌に、すべての次元への拡張を発表しました。これが彼の博士論文となり、25歳でニューヨーク大学の助教授職を得たそうです。

悠真: 高等研究所のPeter Sarnakは「博士論文を書いている若者としては驚くべき業績」と話しています。ちなみに不確定性原理は量子の話に限らず、音が短いほど音程が不確かになる現象や、潜水艦の位置を測る短いレーダーパルスにも現れる、19世紀由来の考え方なんですね。

葵: コメントでは、2017年にDyatlovと別の研究者がこの1次元版を使って証明した「双曲曲面上の波は決して閉じ込められず、常に広がって隅々に達する」という結果に触れるものが、非数学者から「素晴らしく示唆に富む要約」として取り上げられていました。

悠真: さらに議論は、量子のデコヒーレンス、つまり波がどのようにして古典的なふるまいに崩れていくのか、という物理の話題にも発展していました。あるユーザーは、ランダムな位相のずれを導入して平均を取れば、干渉縞が消えてベル型の曲線が現れる、という過程で古典光学と同じ機構を持っている、と説明していますね。

葵: つまり、粒子がたくさんのものと相互作用すると自由度が失われていって、巨視的な効果と同じように振る舞うようになる、という図式です。エンタングルメントの捉え方について、自由度は保たれるべきではないか、という疑問も出ていましたが、他のユーザーが丁寧に反論していました。

葵: 次は「Choose Boring Technology」という有名な2015年の記事。作者はDan McKinleyで、Etsyを退職した後に自分のサイトで公開したものです。彼がキャリア初期に、技術選定を任された経験から学んだことの「蒸留」だと説明しています。

悠真: 中心概念が「イノベーション・トークン」ですね。各社には約3つのトークンがあって、好きなように使えるけれども、供給は長期間固定されている、というモデルです。たとえば新しいサービスをNodeJSで書く、MongoDBを採用する、誕生1年以内のサービス発見技術を使う、とそれぞれ1トークンずつ消費する。自前のデータベース開発なんてやったら大変なことになる、というわけです。

葵: ポイントは、こうした選択が常に悪いわけではなく、たとえばJavaScriptのコンサル会社やデータベース企業にとっては合理的でも、世界の商取引や決済を担うような規模の会社には向かない、としています。そして「退屈」は「悪い」とは同義ではない。MySQLやPostgres、PHP、Python、Memcached、Cronといった技術は退屈だけれども良い技術で、能力だけでなく、障害時にどう壊れるかまでよく理解されている点が重要だと。

悠真: 「最良のツール」思考も批判しています。「ベスト」と「ジョブ」の捉え方が近視眼的で、運用や認知負荷といった負担を無視している。システムを確実に動かし続ける長期コストは、構築時の不便さをほぼ常に上回る、という立場ですね。もちろん、JavaだけでWebサイトを作るような極端も否定していて、新技術の導入はプロセスであり会話、全社的な可視性が必要だと言っています。

葵: Hacker Newsのコメントでは、10年たって「aged well、よく年月に耐えた」と評価されていました。プロダクトマネージャー兼エンジニアリングリーダーとして最も有用な概念の一つで、トレードオフの判断にも、全レベルの同僚への説明にも役立つ、と強く推奨する声がありました。

悠真: 一方で、異論もあります。「少数の離散トークン」という枠組みには反対で、負債とリスクの観点で捉えるべきだ、という指摘。新しい技術は残高を減らすけれども、負債を抱えるのが悪いとは限らなくて、リスクの高い賭けが大きなリターンを生む場合もある、と。また「退屈」と「非退屈」の境界は曖昧で、多くの人が長期間その助言を無視して実績を積むまでは、新しい技術は「退屈」にならない、という皮肉も指摘されていました。

葵: エンジニアの実体験として、Go言語を試すのに長い時間がかかったものの、実際に使って楽しんでいるという声も。この投稿を愛しているけれど、議論を呼びすぎてエンジニアの友人を作るには向かなかった、というユーザーもいましたね。

葵: 最後は「Ordinary Abundance」というエッセイ。現代のアパートにある日常品を、それらがすべて新しかった時代の目線で通り抜けていく、という構成の作品です。

悠真: エドワード・ベラミーは1888年の小説『Looking Backward』で、家庭で音楽を自在に再生できれば「人間至福の限界」に達したと考えた。記事は電灯、写真、眼鏡、電信、印刷された本、水道水、遠方の果物、冷蔵、香辛料、天然痘ワクチンなどに、それぞれの時代の人々の驚きの言葉を添えていきます。

葵: 具体例も印象的です。1880年にインディアナ州のワバシュという町が全面的に電灯化されたこと。1842年にニューヨークのクロトン水道が整備されたのは、その10年前のコレラで3,515人が亡くなった経験が背景にある。そして中世の価格では、ショウガ1ポンドが羊1頭、サフラン1ポンドが馬1頭に相当した、という話もあります。

悠真: コメントの中心は、現代の豊かさを当然視して、感謝できなくなってしまうという問題です。「快楽適応」という言葉を挙げ、外気より約50度近く冷たい空気や、数千マイル先との即時通信を忘れがちになる、という指摘がありました。

葵: それに対するユーモアあふれる提案が「Netflix Chaos Monkey」。毎週1日だけ、配管やエアコン、電気、WiFi、自動車、航空便などを止めてしまえば、感謝が数年間持つのではないか、というのです。これに「それはキャンプというんだ」「既に存在する。停電だ」「イタリアに引っ越せ」といった返しが続きました。

悠真: 実体験も共有されています。井戸水と冬の停電が多い地域に住む人は、電力や給湯の価値を繰り返し再認識してきたけれども、予備発電機を手に入れた今、また当然視し始めるだろうと自嘲しています。あるいは9,000人規模の中世キャンプイベントで、大半が個別太陽光発電という状況の中で郡全体が約8時間停電したら、プロパン給湯のシャワーを3分の1日待つだけで大騒ぎになったそうです。

葵: また、停電で人と話したり、夜の静けさを味わうと、光害やスターリンクなどのせいで星空を楽しむ能力を失ってしまったのだと気づかされる、という逆の反応もありました。

悠真: そして、同種の「実験」は数年前に既にあった、という指摘もあります。新型コロナのパンデミックで、世界の社会はうまく対応できず、うまく対応できた社会だけが小さなカオスモンキーを生んだ、と。教育や採用、人材育成が劣化し続ければ、そう遠くないうちにその種の存在が必要になるだろう、というコメントもありました。現代の豊かさへの感謝をどう保つか、という問いは、個人の気分の話にとどまらない広がりを持っているんですね。

葵: 古い話になりますが、読者のある方がIBM PCの45周年に触発されて、「slopmachine」という自分のプロジェクトで、あの伝説的なDONKEY.BASをブラウザ上で動くように移植し直したそうです。このゲームは1981年にマイクロソフトの共同創業者ビル・ゲイツとニール・コンゼンが書き、初期のIBM PC DOSにBASICAのカラーグラフィックスとサウンドのデモとして同梱されたものです。1982年にバージョン1.10が出ていて、クレジットにはIBMの1981年、1982年の著作権表示が入っています。

悠真: 内容は、レーンを切り替えてロバを避けるだけのシンプルなゲームですよね。この移植は、オリジナルのCGAゲームプレイをJavaScriptで、いくつかの自由を取り入れて再現したものだそうで、教育と保存を目的にしているそうです。ただ、コメント欄では「これは新規性がなくて、ただ生成された移植なのでは」という指摘も出ていました。

葵: そうですね。似たようなプロジェクトとして他のGORILLAS.BAS移植もいくつか挙げられています。実際に動かした人からは不具合の報告もあって、ある人は特定の画面サイズでだけ解像度が激しく切り替わるようなフリッカーが起きたと言っていて、作者は既に修正を入れたかもしれないと返していました。また、レーンを切り替えるときに「もうロバを過ぎているのに車がロバに当たる」という報告もあり、冗談の返しが続いていました。

悠真: あるコメント投稿者は、効果音が当時の初期IBM PCが搭載していた単純なスピーカーの能力より少し先進的に聞こえると指摘しました。その方自身は4ヶ月かけて、QBasicとQuickBasic 4.5の「100%忠実」なブラウザ内適応を開発中で、仮想CPUとハードウェア抽象化レイヤーで動くそうです。フルスクリーンで表示したのを本物の仮想マシンと誤認した友人の反応が一番の褒め言葉だと話していて、DONKEY.BASはそのシミュレータで最初に動かしたプログラムの一つなんだそうです。

葵: その流れで、ある方は最初の職場の注文入力や在庫管理システム全体がQBASICで書かれていて、ソースがあれば試してみたいと言っていました。実際のところ、90年代の数百本のプログラムを当時の実機と比べながらA/Bテストしてきたそうですが、ソース付きの実務用アプリは入手が難しいとのことです。1981年から愛され続けたこの131行の作品が、今もこうして語り継がれているのは面白いですね。

悠真: 次の話題は、データアーカイブの行方に関する深刻なトラブルです。ミズーリ州セントルイスのPBS系列局ナインPBSが今年7月、デンバーの地方裁判所にデータセンター大手のIron Mountainを提訴しました。同社のデンバーのデータセンターに保管されている、放送局の70年にわたる組織の歴史を表す50テラバイトを超えるアーカイブ資料の返還を求めています。クラウドストレージベンダーのOpen Source Storage、通称OSSが警告もなくアクセスを遮断し、消滅状態になったことが発端です。

葵: Iron Mountainは、自社の顧客であるOSSがデータを収容する物理的サービスを技術的に所有しているとして返却を拒否したんですね。ナインPBSは削除や改変を防ぐ仮の救済措置を求めて、裁判官はこれを認めたそうです。放送局の副社長は「セントルイスにとって重要な歴史的価値がある」と話しています。

悠真: 経緯を整理すると、ナインPBSは2019年にOSSと契約して毎年更新していましたが、2026年2月に更新協議を求めても応答がなく、契約は3月6日に失効しました。契約上は終了後30日間データを引き取れるはずでしたが、同じ3月6日にはもうアクセスが遮断されてしまったんです。OSSのウェブサイトは消え、州への登録も不履行状態でした。その後、OSS資産を取得したグループがデータの安全を確認したものの連絡が途絶え、ナインPBS側は「OSSの買収で詐欺に遭った」と述べています。

葵: 最終的にナインPBSは欠席判決を得て、データの所有権と即時占有権が認められ、OSSに返還が命じられました。失われる恐れがあった資料には、東セントルイスの歴史やCOVID-19パンデミック、1993年のミシシッピ川とミズーリ川の大洪水の報道が含まれているんです。コメント欄では、OSSが実質4人体制で誰がストレージ基盤を担っているのか疑問視する声や、Iron Mountainが実際の保管を担いOSSは中間業者にすぎないという指摘もありました。

悠真: そして議論は、こうした記録をどう守るかという大きなテーマに広がっています。ある人はInternet Archiveや、テレビ番組を延々録画し続けたマリオン・ストークスのような個人アーカイブの重要性を強調していました。別の人は、1ギガバイトあたり2～3ドルの一回払いで永久保存するアーカイブサービスを紹介しつつ、最近のAIバブルで保管コストが上がっていると説明しています。ただ、Internet Archiveを唯一のバックアップ先にするなという警告もあって、ある人は「アクセス不能は削除を意味しない」と反論し、事前の取り決めがないとTwitchやYouTubeの投稿は削除や禁止の対象になり得ると補足していました。50テラバイトの放送局の歴史がこうして法廷まで持ち込まれる事態は、デジタルアーカイブがいかに脆いかを示していますね。

葵: さて、今日はAIエージェントが信頼を失いつつある話から、四半世紀前の短縮URLサービスの記憶、新しい数論の発見まで、幅広いテクノロジーの話題をお届けしました。

悠真: はい。古のドンキーベースから、家庭で動くAIデータセンター構想まで、どこか一つの軸で括れない多様さでしたね。DeepSeekの価格改定やOpenAIの新しい処理方式も気になるトピックです。

葵: 特に心に残ったのは、劇場の記録を抱えたままデンバーのデータセンターに閉じ込められた放送局の訴えです。テクノロジーは進んでも、大切なものの置き場所という問題は普遍だと思いました。

悠真: まったくですね。それでは、次回もどうぞお楽しみに。最後までお聞きいただきありがとうございました。