1109 | 週刊テック粋読：AIの泡沫疑惑とデスクトップの行方

葵: どうも、ハッカーニュース・ラジオへようこそ。葵です。

悠真: 悠真です。今週の話題、かなり幅広いんですけど、実は一本の線でつながってるんですよ。AIの経済と人間の付き合い方、そして書くこと、それからレンダリング技術からデスクトップGUI、個人のプロジェクト、最後はセキュリティと「知らないうちに変わっていた環境」という話まで。

葵: そう、全部「誰がコントロールしていて、どこまで任せていいのか」っていう問いで貫かれてるんですよね。それでは最初のテーマ、AIバブルは実在するのか、から始めましょう。

悠真: はい。投稿の中心にある主張は、約5兆ドルと呼ばれるAIへの支出は、いわゆるバブルの構造とは違うんじゃないか、というものです。

葵: ここ、議論の分かれ目なんですけど、まず投稿者のロジックから整理しますね。バブルというのは通常、毎年続けて注ぎ込まれるお金が、回収できない形で積み上がること。でも今回の5兆ドルは、データセンターの設備投資として一括で使われる「一度きりの支出」だという主張です。

悠真: 言い換えると、これは資産価格の膨張ではなく、インフラ建設に近い、と。鉄道や電力網を作ったときと同じで、建設費はかかるけど、それ自体は資産価値が暴落するものじゃない、という見方ですね。

葵: そしてもう一つの柱が、収益性の数字です。Anthropicは1ドルの計算コストに対して2.08ドルを稼いでいる、というデータが提示されています。

悠真: これは強い数字ですよね。1ドルかけて1ドル未満しか稼げていないなら、延々と赤字を積み上げる構造になります。でも2倍以上稼げているなら、モデルの学習と運用コストがペイできる状態にあり、少なくとも基礎部分は健全だ、という読み方ができる。

葵: ただ、ここには落とし穴もあって、コメント欄ではこの2つの数字の意味をめぐって意見が割れていました。まず「5兆ドルが一回きり」という前提そのものに、一部のコメントは懐疑的です。

悠真: ええ。データセンターは作って終わりではなく、冷却電力の維持、ハードウェアの陳腐化、モデルの再学習など、続くランニングコストが必要です。最初の5兆で終わるならいいけれど、毎年追加投資が発生するなら、それは一回きりではなく継続的な支出になってしまう。だからバブルの条件に近づく、という反論です。

葵: 一方で、それに対して「いや、それでもバブルとは違う」という側の理由付けがあります。資産価格が上がったから崩壊するバブルと、需要が実在していて投資が現物に転化しているケースは別物だ、と。

悠真: たとえばドットコムバブルは、まだ収益が存在しない会社の株式価格が跳ね上がった、という資産価格のバブルでした。でも今回は、GPUとデータセンターという実物が存在する。株式じゃなくて、フロアとマシンに money が使われている。だから暴落したときに残るものが違う、という指摘です。

葵: そしてAnthropicの2.08ドルという数字に対しても、コメント欄では「それが正しいとしても、まだ十分ではない」という読みがありました。

悠真: ええ。モデル開発には膨大な先行投資がかかっている。たとえ運用コストが2倍回収できても、研究開発の元を取るまでには年単位の累積が必要です。だから「今ペイしている」と「事業全体が黒字」は違う、というのが、この数字に慎重な側の見方です。

葵: さらに「単価が上がり続けるなら」という見方もありました。つまり、コストを1ドルと固定せず、モデルの性能が上がるたびに顧客が支払う額も上がるなら、投資の回収曲線はもっと急になると。

悠真: じゃあ、全体をまとめると、ここでの論点は「バブルかどうか」という二値の問題というより、「一回きりの設備投資なのか、それとも繰り返す投資なのか」「運用がペイしているのか、それとも累積赤字なのか」の2軸で見るべきだ、ということなんですね。

葵: そしてどちらの立場のコメントも、最後は「まだ決着がついていない」という形で留まっていました。5兆の使い方が一回きりかどうか、Anthropicの数字が業界全体を代表するかどうか、どちらも未知のまま。

悠真: で、ここからスピンオフ的な話に移れるんですけど、同じAI投資の文脈で、投稿の中に連動する話題がいくつかありました。一つは、llama-modchipというプロジェクトで、CPUのみ、64GBメモリでDeepSeek-V4-Flash、284Bパラメータのモデルを、256Kのコンテキストで動かしたというもの。

葵: すごい数字に聞こえますけど、コメント欄ではまず懐疑的な指摘が多かったです。なぜそんなに軽く動くのか、という答えとして、「それはたぶん1ビットから2ビットの量子化だろう」という声がすぐに出ました。

悠真: つまり、284Bパラメータを生のまま載せているわけではなく、重みを極端に粗く表現してメモリを削減しているのではないか、と。だから「CPUだけで284Bが動く」という宣伝文句と、「実用上どれだけ性能が残っているのか」の間に、大きなギャップがありうるという指摘です。

葵: ここは興味深い構造で、面白いデモが現れたときに、まず「数字の何が削られているのか」を疑うという、AI議論の定型が表れています。そしてもう一つのAI話題が、Jensen Huangの話です。

悠真: ええ。NvidiaのHuang氏が社員に不倫について謝罪した、というニュース。そしてボードが独立した調査を開始し、その理由に国家安全保障に関わる懸念が含まれていた、という部分です。

葵: 個人的なスキャンダルと、安全保障という国家レベルの問題が同じ文脈に置かれている点、コメント欄では「なぜそこまで重いのか」という議論になりました。

悠真: 理由としては、Nvidiaが単なる半導体メーカーではなく、AIインフラの中核を担っている。だからCEOの個人的なリスクが、企業ガバナンスの問題を通じて、国家レベルの技術依存の脆弱性に波及しうる、という論理です。

葵: つまり最初のバブルの議論に戻ると、5兆ドルの投資先が特定の企業に集中しているからこそ、個人のスキャンダルすらシステム全体のリスク要因になりうる、というつながりがあるんですよね。

悠真: そしてもう一つ、Goldman Sachsの話が、この文脈で重要です。Goldman SachsがClaude Codeの使用をエンジニアに限定し、トレーダーやバンカーからアクセスを切った。そしてその数週間後、AnthropicのIPO引受に関わっていた、という話。

葵: これは、投資銀行が同じ企業に対して、まったく矛盾した行動をとっているように見える、という不思議さがコメントの中心でした。

悠真: 一方では「うちの従業員はこのツールを使わせない」という判断。もう一方では「この企業の株式を引き受けて世に出す」という判断。どちらも真剣にやっているとしたら、内部では「ツールは限定的に使うべきだが、この企業自体は上場する価値がある」という複合的な評価が存在することになります。

葵: コメント欄では、この2つを同一視しない、という指摘もありました。セキュリティポリシーの観点と、投資判断の観点は別の評価軸だから、矛盾するとは限らない、と。ただ、その「別軸」でよいのか、という疑問も残ったままです。

悠真: で、ここからがスムーズにつながるんですが、AIの経済と会社のガバナンスを外から眺めた後、今度はAIを使う側、人間側の話です。

葵: 投稿は「AIで脳が疲弊する問題に、gitベースの優先度キューと一つずつの意思決定で対抗した」という実践報告でした。

悠真: まず「脳が疲弊する」という現象の説明から。複数のAIエージェントを同時に回していると、タスクの断片、警告、質問が絶え間なく飛び込んできて、人間の注意が割れていく。どれを先にやるべきか判断するコストだけが膨らむ。

葵: 投稿者の対策が、gitベースの優先度キュー。つまり、やるべきことをgitのリポジトリの中に、優先度付きのリストとして置いてしまう。エージェントはそのリストから順番に取りに行く。人間は、次の決断を一つずつ行う。

悠真: ここが鍵で、「複数のことを並行して考えない」「一つ決めたら次に行く」という原則を、ツールの構造に押し込めたんですよね。注意力を人間の意志力で保つのではなく、システムの形状で守る。

葵: そしてもう一つのルールが「本番へのデプロイはエージェントにさせない」です。

悠真: これはコメント欄でも同意が多かった部分です。エージェントは書くのが速いけど、責任を取れない。だから、書くこと、提案すること、テストの実行までをエージェントに任せて、実際に本番環境に反映する一歩は、必ず人間が判断して押す。つまり、エージェントを「提案者」として位置づける。

葵: ここで面白いのは、コメント欄で「人間の役割が変わった」という感想が多く出たことです。以前はコードを書く人だったのが、今は「何を書くかを決めて、どこにリスクがあるかを見抜く人」になる。具体的なタイピングは減って、判断の比重が上がる。

悠真: そして、その「判断」と「書くこと」の関係に、次のテーマがつながります。

葵: そう、書くことは考えること、という投稿です。ここでの主張はかなり大胆で、「紙なしでは、あなたは有限オートマトンだ」と言い切っています。

悠真: 有限オートマトンというのは、記憶容量が有限で、外部に何も持たず、その場で全部を頭の中だけで処理する機械。つまり、書く道具を持たない人間は、作業メモリだけで思考を完結させざるを得なくて、複雑な問題を段階的に組み立てられない、というたとえです。

葵: 紙やホワイトボードは、単なる記録の手段じゃなくて、思考を外部化して、一歩引いて眺められるようにする装置だ、という見方ですね。書いたものが、思考のミラーになる。

悠真: そしてここからの議論は、LLMにどう接するか、という点に及びます。投稿者の主張は、「LLMが代わりに考えることはできない」というもの。

葵: 理屈としては、LLMはテキストを生成できます。でも「書くことによって自分の考えを明確にする」というプロセスそのものを、LLMが肩代わりすることはできない。他人の文章を読むのと、自分で書いて頭の中に定着させるのとは、違う作業だ、と。

悠真: だから「書くこと」は、LLM時代における比較優位になる、という結論です。

葵: コメント欄ではここに同意する声が多かったですが、同時に「じゃあ、LLMに書かせた文章を添削してもらうのはどうなのか」という実践的な問いも出ていました。

悠真: そこには意見の割れがあって、まず「下書きを書いた後でLLMに添削させるのはいい」という立場。これは自分の思考を先に外部化して、それを磨くだけだから、考える部分は自分のまま残る、と。

葵: 対して「それでも危険だ」という立場。添削の過程で、自分の言葉が他人の言葉に置き換えられていくと、結局「考える」を放棄しているのと同じになりかねない、と。

悠真: この2つの立場は、まだ決着していない。ただ、どちらの立場でも、「最初の一歩、つまり自分で書き出すところ」だけは機械に任せてはいけない、という点では一致していました。

葵: さて、ここまで人間側の話をしてきましたが、今度は技術側に目を転じましょう。ここからは「レンダリング」というテーマで、まずは極限の話から。

悠真: はい。Raph Levienという方が、ビットマップグリフの描画を、ARMのネイティブコードにJITコンパイルする話です。ターゲットはRP2350というマイコンで、race-the-beamという方式のレンダラーを使っています。

葵: race-the-beamの説明を少しだけ。ディスプレイのビームが走査していく時間に、CPU側の処理を合わせて走らせる方式です。ビームが今このピクセルに達するまでに、そのピクセルの色を決めておかなければならない。

悠真: だから予算が極端に小さい。ここでは1ピクセルあたり約6サイクル以内、という数字が出てきます。6サイクルの中で、グリフのデータを読み、対応するピクセルの色を決める。

葵: 通常のレンダリングは、フレーム全体をバッファに描いてから表示します。でもrace-the-beamは、バッファを持たず、ビームに間に合わせる。だからリアルタイム性が命で、わずかな遅れが視覚的な破綻になります。

悠真: そこでLevienのアプローチが、グリフの描画処理を、その場でARMの機械語にJITコンパイルすることです。ピクセルごとに最適化されたコードを事前に生成しておいて、走査のときはそのコードをそのまま実行するだけ。

葵: これがうまく合致するのは、ビットマップグリフの描画が、基本的に「このピクセルは塗るか、塗らないか」という決定の集まりだからです。だからピクセル単位でコードを生成すれば、たいていの分岐や計算をコンパイル時に潰せる。

悠真: コメント欄では、まず「この組み合わせの妙」が話題になりました。組み込み側の極限の制約と、コンパイラ技術の洗練が、まったく別の世界から来てここで合流している、と。

葵: それから「これが使いどころがあるのか」という実用的な問いもありました。答えとしては、安価なマイコンで、外部メモリもフレームバッファもなく、それでも文字をきれいに表示したい、という場面です。要するに、極限まで部品を削った環境でテキストを表示するニーズは、まだ現実に存在している。

悠真: そしてここで、LevienのJITのアプローチが、将来どんな形に拡張されるのかという議論もありました。今はビットマップグリフに限定されているけれど、同じ「走査に間に合わせる」の発想を、ベクターグラフィックや単純なUI要素に広げられるか、という可能性の話です。

葵: 実現するかはまだ分かりませんが、コンパイル時に多くを解決して、実行時は単純なループにする、という設計思想そのものは、他の場面でも使える可能性がある、という話にとどまっていました。

悠真: さて、この極限のマイコンの話から、今度は一気にスケールを変えて、ブラウザの話へ行きましょう。

葵: 投稿はPaul Fordの主張で、ブラウザは強力で、安価なアプリプラットフォームだ、というものです。

悠真: まず強力さの根拠として、Wasm、WebGL、WebCryptoが成熟した、という点が挙げられています。

葵: Wasmはブラウザの中でネイティブに近い速度でコードを動かせる。WebGLはGPUを直接使える。WebCryptoは暗号化の機能が標準で入っている。つまり、かつてはネイティブアプリでしか実現できなかった層が、ブラウザの中でそろっている、ということです。

悠真: そして「安価」の部分が、Fordの主張の独自性で、ここでCloudFlareが例に出されます。CloudFlareでホスティングすれば、コストが0ドルになる、と。

葵: つまり、ネイティブアプリを開発・配布するには、ストアの手数料、署名、各OS向けのビルド、更新の仕組み、というコストが避けられない。でもブラウザアプリなら、静的なファイルをCDNに置くだけで済む。 CloudFlareならそのコストがほぼゼロで済む。

悠真: だから「個人や小さなチームが、資金なしで世界的に配布できるアプリを作る場所」として、ブラウザは最強だ、という主張になります。

葵: 一方で、このブラウザの台頭と対比で浮き彫りになるのが、ネイティブ側の迷走です。ここでつながるのが、C++委員会の話です。

悠真: ええ。C++委員会が提案した草稿がISOに拒否された、というニュース。そしてさらに重要なのが、P4454という論文で、C++の作成者と所有者の間で、C++の方向性について意見が一致していないことが示された、という点です。

葵: つまり、C++を作っている側と、C++を使い、管理している側で、この言語をどこへ持っていくべきかの認識がズレている。言語の進化のロードマップが、内部で割れている、ということです。

悠真: コメント欄では、この二つの話を合わせて見る視点が出ました。ブラウザがアプリの基盤として強くなる一方で、ネイティブの基盤となるC++の標準化プロセスが、方向性の不一致を抱えている。だから、多くの開発者の選択肢として、ブラウザ側の重みが上がる、という流れです。

葵: もちろん、これは因果関係というより、両方の話を並べたときに浮かび上がる構図です。でも、Fordの主張が「ブラウザは安価で強力な代替」と言えるのは、まさにネイティブ側の進化がもたついているからこそ、という指摘もありました。

悠真: ただ、ここで疑問も残ります。ブラウザはどこまで本当にネイティブを代替できるのか。ハードウェアを直接扱う処理や、超低レイテンシが必要な処理、そして先ほどのマイコン上のレンダリングのような場面では、ブラウザは入り込めない。

葵: で、その「ブラウザでは足りない場面」の代表格が、デスクトップアプリなわけです。そこで次の話題、デスクトップGUIの現実に移ります。

悠真: 投稿は、GPUIとeguiというRustのGUIフレームワークの状態モデルは、複雑なデスクトップアプリには行き止まりだ、という評価です。

葵: 根拠として挙げられているベンチマークが、3000行のテーブルで、まばらな変更が1回起こったときに、8.4ミリ秒かかる、というものです。

悠真: まばらな変更というのは、3000行のうち1行だけが変わる、みたいな局所的な更新のことです。本来なら、変わった1行だけを再描画すれば済むはずが、8.4ミリ秒という時間がかかってしまう。

葵: 8.4ミリ秒は、60fpsのフレーム予算にほぼ張り付く時間です。つまり、1回の変更でフレームの余裕をほぼ使い切ってしまい、複数の変更が重なった瞬間にフレーム落ちする。

悠真: コメント欄では、まず「なぜこうなるのか」という技術的な説明が行われました。GPUIやeguiの状態モデルは、全体の状態とUIを密接に結びつけていて、局所的な変更が起きたときに、影響範囲の特定が難しい。だから、広い範囲の再計算が発生してしまう。

葵: 一方で、「行き止まりという結論は言い過ぎではないか」という反論もありました。これは単純なベンチマークであって、現実のアプリではパターンが違う。だから、この数字だけでフレームワークを切り捨てるのは早すぎる、と。

悠真: ただ、反論側も「複雑なアプリで明確に上手くいった事例を提示できていない」という点では、前進できていなかった。だから、結局のところ「複雑なデスクトップアプリでは、この手の状態モデルがうまくスケールしていない」という疑念は残ったままです。

葵: つまり、デスクトップのGUIは、技術的に成熟していない荒野がまだ残っている、という現状ですね。で、その荒野を自力で歩いている人たちの話へ、つなげましょう。

悠真: はい、個人のプロジェクト紹介です。2026年11月のAsk HNで、「何を作っているか」という問いに対する回答が集まっていました。

葵: まず一つ目が、Bonsaiというボクセルエンジン。コメントで特徴的だったのが、これを10年間取り組んでいるという点です。

悠真: 10年は長いですよね。コメント欄では、この期間の意味について意見が分かれました。まず「10年かけて1つのプロジェクトを育てるというのは、職人としてのあり方で、それ自体が価値だ」という肯定的な読み。

葵: 対して「10年やってまだ完成していないというのは、スコープの設定に問題があるのではないか」という冷めた見方もありました。ただ、このボクセルエンジンは、明確な「完成」を目指すものではなく、継続的な研究対象として存在している、という返しもありました。

悠真: 次が、Orpheumという自前のメディアサーバーです。既存の商用サービスに頼らず、自分でメディアの保管と再生を管理する、というプロジェクト。

葵: コメント欄での議論は、自前サーバーの価値が「コスト」ではなく「コントロール」にある、という点でした。つまり、映画や音楽のライブラリを、外部サービスの都合に左右されずに保持できること自体に意味がある、と。

悠真: そして3つ目が、OneBusAwayという交通ソフトです。公共交通のリアルタイム情報を提供する、既に運用実績のあるプロジェクトです。

葵: この3つは、作り手が違うし、分野も違うんですが、コメント欄で共通のテーマとして浮かんだのが、「個人でも長期間にわたって実用的なものを作れる」という点です。そして、そのためには商用の成功やユーザー数ではなく、自分の関心に沿って続けられることの価値が大きい、と。

悠真: ここでついでに、同じ「個人製作」の文脈で、他の話題もいくつか出ていました。まずChimeraというブラウザ上の音声合成で、物理モデルに基づいた声の合成を行うもので、すべての音が模擬された気道から生まれる、というものです。

葵: これはPink Tromboneを思い起こさせる、とコメントで言及されていました。Pink Tromboneは、人間の発声器官を物理モデルで再現して、マウスで喉や舌の形を操作して声を出す、という有名な実験的な作品です。

悠真: Chimeraは、その系譜で、ブラウザの中で完結している点が特徴です。ブラウザの音声APIの進歩と、物理モデルの計算が、ブラウザで実用になる性能に達したことを示している、と言えます。

葵: それからDuxという、無料でオープンソースのWaylandデスクトップシェル。QuickshellとQMLで作られていて、ファイルマネージャーやテーマ機能を持っていて、niri、Hyprland、Swayなどのコンポジタに対応しています。

悠真: これは、先ほどのデスクトップGUIの話と、ちょっとしたつながりがあります。Waylandの世界では、シェルやパネルは、コンポジタごとに自分で作ることが多く、だからこそQMLのような既存のツールキットを使って個人や小さなチームが作れる場面が生きている、という構造です。

葵: そして、先ほどのC++の迷走の話とつながるプロジェクトとして、KetchUpがあります。RustとWebGPUで作られた、SketchUpの代替で、 woodworking、つまり木工の用途を主眼に置いた無料のオープンソースCADです。

悠真: コメント欄では、この選択が注目されました。3D CADという、伝統的にC++で作られてきた分野に、RustとWebGPUの組み合わせで挑んでいる。そして、木工という特定の用途に絞ることで、巨大な汎用CADとの差別化を図っている、と。

葵: 一方で、UXには問題があるという指摘もありました。たとえば、矩形を描くときに名前を付ける必要がある、というような、細かいが体験を損なう部分です。オープンソースのCADは、機能の実装に比べて、体験の洗練が後回しになりがちだ、という指摘です。

悠真: そしてもう一つ、Bending SpoonsがHarvestの価格を月13ドルから134ドルに値上げした、という話もありました。作者のコメントとして、「あれはシンプルで信頼できる小規模ビジネス向けのソフトだった」という嘆きです。

葵: この話は、次のテーマへの橋渡しになります。

悠真: そう、セキュリティと、知らないうちに環境が変わっていた、という話です。まず自動車の話から。

葵: 認証なしの管理ツールAPIと、ID基盤の連鎖を通じて、ある大手自動車メーカーの車を世界中のどこからでも解錠できる、という脆弱性が研究者によって発見されました。

悠真: ポイントは「連鎖」の部分です。単独のAPIには、それぞれさほど深刻ではない脆弱性が存在していた。でもそれを組み合わせると、遠隔解錠という致命的な結果になる。だから、各部品の重大度を個別に評価するだけでは、全体のリスクが見えない、という教訓です。

葵: コメント欄では、なぜこの種の連鎖が見落とされるのか、という議論になりました。理由としては、各APIは別々のチームが管理していて、全体の連鎖を評価する人がいない。そして、遠隔解錠が「実在する攻撃経路」だと気づくには、連鎖全体をシミュレートする視点が必要だ、と。

悠真: そして、これは「外部に依存している部分は、自分で確認しないと、実はまったく安全ではない」という、はるかに広い教訓につながります。

葵: それを示すもう一つの例が、Outlook.comの話です。2026年11月5日から、Outlook.comが、DMARCを設定していないドメインからの一部のメールを、告知なく拒否し始めました。

悠真: これは、メールを送っている側にとっては、突然「自分のメールが届かない」という事態です。しかも、予告もなく。

葵: 対策はシンプルで、TXTレコードを1つ追加するだけです。DMARCのポリシーを宣言する。でも、その事実を知らなければ、ずっとメールが届かないまま、あるいは拒否された理由を調査に時間をかけてしまった、ということになりかねない。

悠真: ここでコメント欄に出たのが、「自分の環境が外部のポリシー変更で、予告なく動かなくなる」という構造の普遍性です。技術的には1レコードの修正で済むけれど、事実を知るまでの間に、コミュニケーションが止まるという実害が発生する。

葵: そして3つ目の例が、Bending SpoonsのHarvestの値上げに戻ってきます。月13ドルが134ドルに。約10倍です。

悠真: コメント欄の反応は、値上げの是非というより、「任せていたものが、勝手に変わる」という体験の側面に集中しました。小規模ビジネスが、日常的に使うツールの価格をコントロールできない。そして、それが「誰も悪いことをしていない」ように見えて、利用者に突如としてコストが転嫁される。

葵: 3つの話を並べると、共通の教訓が見えてきます。外部のシステム、API、プラットフォーム、ツールに依存している部分は、それがいつ、どう変わるかを自分では決められない。だから、任せきりにせず、最低限の確認と、対処の手順を自分で持っておく必要がある。

悠真: 自動車の脆弱性なら、連鎖を疑う視点。メールなら、DMARCの状態を確認する視点。そしてソフトウェアなら、値上げや条件変更に備えて代替手段を持っておく視点。

葵: というわけで、今日の放送はここまでです。AIの経済とガバナンス、人間との付き合い方、書くこと、そしてレンダリングからGUI、個人のプロジェクト、最後にセキュリティの話まで、幅広く扱いました。

悠真: どの話題にも「どこまで任せて、どこから自分で確認するか」という軸が通っていたと思います。それではまた来週、ハッカーニュース・ラジオでした。どうもありがとうございました。