1005 | 今週のテック pickups

葵: どうも、ハッカーニュース・ラジオの時間です。葵です。

悠真: 悠真です。今日も過去24時間の話題をディスカッション形式で深掘りしていきます。今日のラインナップは、隠されていた脆弱性の話から始まって、開発ツール、AI基盤、データの透明性、そして最後はレジリエンスと人物の話まで。共通するのは「表に出てこないものこそ問題だ」というテーマかな。じゃあ早速、最初の話題へ。

葵: そうですね、まずはXray-coreの話から。pinnedPeerCertSha256、つまり証明書をピン止めして検証する機能に、証明書の検証をバイパスできる脆弱性があったんですが、それがなんと約1年もの間、公には知られずに隠されていたという話です。

悠真: 1年って長いよね。これ、どういうことなのか整理しようか。pinnedPeerCertSha256というのは、特定のサーバー証明書のSHA256ハッシュを事前に登録しておいて、通信相手の証明書がそのハッシュと一致するかを確認する機能。証明書の検証というより、より強固な「これは絶対にこのサーバーだ」という確認方法。で、その検証が実はすり抜けられる状態だったと。

葵: しかも「隠された」という表現が興味深いところで、単に見つからなかったのか、意図的に公表が遅れていたのか、そこが議論の焦点になっています。

悠真: そこが一番論点だよね。仮に意図的に隠していたなら、これはオープンソースの倫理として問題が大きい。ユーザーが「この機能で守られている」と信じて使っていたのに、実際は守られていなかったわけだから。セキュリティ機能のバグは、その名前を信じる人ほど騙されてしまう。

葵: 一方で、意図的でなくても、1年見つからなかったという事実自体が別の問題を示していますよね。この機能はPINNED検証だから、普段のCA検証よりも強いはずのもの。それを実際に使っている人、しかも検証が効いているかどうかをテストする人自体が少なかったのではないか、という推測ができます。

悠真: ピン止めって、普通の利用者はあまり自分で設定しないんだよね。逆に言えば、設定した人は「敵対的なネットワーク環境」にいる人、検閲対策とか中間者攻撃対策が必要な人が中心になる。そういう人たちが守られていなかったと考えると、影響は軽くない。

葵: 今後の課題として浮かぶのは、脆弱性の開示プロセスと、監査体制です。誰が、いつ、どのように発見し、修正し、ユーザーに伝えるのか。プロジェクトの規模が大きくなるほど、この体制が属人的になりがちで、今回のような長期間の隠蔽、あるいは放置につながるんじゃないかという声が出ています。

悠真: 未解決の問いとしては、「なぜ1年だったのか」への説明が明確でないままの部分があることだよね。修正はされたのか、悪用の痕跡はあったのか、どのバージョンから影響があったのか。こういう事実がはっきりしないうちは、「Xray-coreはもう信頼できるのか」という根強い疑問が消えないと思う。

葵: そういう疑問を持つ人の中には、「それならもう別の実装に移ろう」という人もいれば、「機能自体は良いものだから、開示プロセスだけ直せば問題ない」という人もいる。私の見方では、ピン止め検証の意義自体は変わりません。問題は機能ではなく透明性です。

悠真: うん、そこは妥当な線だと思う。さて、脆弱性が長く隠れていた話から目線を変えて、今度は「ちゃんと作られているツール」の話に移ろうか。開発ツールの進化の話題がいくつか並んでいるんだ。

葵: まず注目はHeadstartというツール。Rustのメタデータを早期に生成することで、cargo checkとcargo buildを高速化する話です。実際のプロジェクトで、cargo checkが最大54%、ビルドが42%高速化されたと報告されています。

悠真: Rustのコンパイル遅延は長年の悩みだよね。cargo checkは型チェックだけだから比較的速いはずなんだけど、大きいプロジェクトだとそれでも待たされる。Headstartは、本来クレートの依存解決や解析の後でしか作られないメタデータを、早い段階で先回りして用意しておくことで、パイプライン全体を並列化する発想なんだと思う。

葵: 面白いのは、「コンパイラを賢くする」のではなく「待ち時間を消す」アプローチだという点です。アルゴリズムの改善ではなく、実行順序の工夫。こういう実用的な最適化は、実プロジェクトでの54%という数字が出たことで説得力が増します。

悠真: コメント欄でも、「毎日数十回cargo checkを回す人にとって、これは生産性に直接響く」という声と、「結局増分ビルドやキャッシュ設定で実質同じ速さになるのでは」という懐疑の声が両方あると思うんだ。ここは実際に自分のプロジェクトで試してみないと答えが出ない。

葵: そしてもう一つ、ちょっと変わった話題がVB6スタイルのIDE。Visual Basic 6風のネイティブIDEをブラウザ上で実現するというプロジェクトです。フォームデザイナーがあって、ランタイムがあり、コンパイルすると単一のHTMLファイルが出力される。

悠真: これは強烈なノスタルジーを刺激するよね。VB6の良いところって、「ボタンを配置して、ダブルクリックして、イベントハンドラを書く」という即時性なんだ。現代のWeb開発は設定ファイルだらけで、あの体験が消えている。それをブラウザで再現しつつ、成果物が単一HTMLという持ち出しやすい形式というのが賢い。

葵: 「単一HTML出力」という点が重要で、依存関係なくそのまま配布・実行できるんですよね。VB6のEXEがそうだったように。ツールの哲学が変わらず、実行環境だけが現代化された形と言えます。

悠真: そして三つ目、これも地味だけど実用的な話。OpenSSHのリモートフォワードとnginxのsecure linkモジュールだけを使って、自己ホスト型のHTTPトンネルを作る手法。

葵: よくあるトンネルサービスを使わずに、自分だけの仕組みを組み立てる話です。SSHのリモートフォワードで、ローカルのサービスを外部からアクセスできる場所に掘り、nginxを前段に置いて、secure linkモジュールで有効期限付きのトークンを検証する。これでURLを知っていても、期限切れのトークンではアクセスできない。

悠真: つまり「一時的にだけ見せたいデモやプレビュー」を、追加ソフトを入れずに実現する方法なんだよね。secure linkはnginxの標準モジュールだし、SSHはもう持っている。依存が極小なのが美しい。

葵: この三つの話、実は一本の線でつながっています。既存のプラットフォーム、既存の道具を賢く使って、自分で問題を解決する姿勢です。コンパイラの待ち時間は順序の工夫で、Web開発の体験はVB6の哲学で、トンネルはSSHとnginxで。専用の新サービスに頼るのではなく。

悠真: そこで次の話題だ。Nolan Lawsonが問いかけた、「なぜ開発者はプラットフォームを使わないのか」という文章。ちょうど今の話と好対照の視点だよ。

葵: 彼の分析によれば、開発者がプラットフォーム、つまりブラウザやOSが最初から備えている機能を避けて、ライブラリに頼る理由は大きく三つあります。まず歴史的経緯。かつてはプラットフォームのAPIが揃っていなかった。次に慣れ。既に知っているライブラリを使うほうが速い。そして意外に大きいのが、構築すること自体の楽しさです。

悠真: 三つ目がポイントだよね。車輪の再発明って、しばしば愚行として扱われるけど、再発明する過程で学ぶことがあるし、「自分で作りたい」という動機はエンジニアとして正当なものだ。全部が全部プラットフォームに任せたら、開発の喜びが減る。

葵: 一方で Lawson が指摘するのは、その楽しさがコストを隠蔽してしまうことです。ライブラリを選ぶことで、パフォーマンスやアクセシビリティの責任を他人に委ね、既知のAPIに囲まれた快適さに留まる。それは合理でもあるんですが、プラットフォームが成熟した今、昔の理由は既に消えている、と。

悠真: ここで話を繋げると、先ほどのツール三連発はどちらの側にも属するんだよね。単一HTML出力のVB6風IDEは「プラットフォームを使わない、独自ランタイム」に見えるけど、出力はブラウザ、つまりプラットフォームに完全に乗っている。SSHとnginxのトンネルは究極の「プラットフォーム活用」。Headstartはコンパイラのプラットフォームを賢く使う手法。全部、 Lawson の言う「プラットフォームを理解した上で使う」方の例だと思う。

葵: 未解決の問いは、「では再発明はいつ許されるのか」です。正解は無くて、ケースバイケース。ただ、理由を自覚しておくことが大事だというのがこの文章の含意でしょう。歴史的な理由で避けているのか、それとも今も本質的な理由があるのか。それが分かっていないと、ただの慣れが選択の根拠になってしまう。

悠真: さあ、ここからはスケールが一気に変わる話だ。AI基盤の進化。二本立てで、一つはネットワーク、もう一つはハードウェア。

葵: まずネットワークから。John Ousterhout氏、そう、TclやRaftで知られるあの方の新しいプロトコル「Homa」です。これはTCPを、特にAIクラスタにおいて置き換えることを狙ったものです。

悠真: なぜAIクラスタでTCPが問題になるのか。TCPの輻輳制御は送信側主導だよね。パケットロスやRTTの変化を見て、送信側が送る量を調整する。でもAIの分散学習では、何千ものGPUが同時に互いに通信するから、送信側主導だと遅延が積み重なって、学習全体が遅いストリームの速度に律速されてしまう。

葵: Homaはそこを逆転させて、受信側が主導権を持つ輻輳制御を行います。受信側が「今は誰にどれだけ送らせてよいか」を指示する方式で、これによって多数の混在する通信の中でも、優先度の高いメッセージが公平かつ低遅延で届くようになります。

悠真: Ousterhout氏が本気でTCPに挑むのは象徴的だと思う。IP和TCPは四十年以上の成功作だけど、その成功が「AIクラスタ」という新しい負荷パターンで揺らいでいる。議論としては、「理論的には優れているが、実運用の互換性が問題だ」という声と、「AIクラスタは閉じた環境だから、TCP互換性なんて不要、性能が出るなら全部変えろ」という声が分かれるところだよね。

葵: 閉じた環境なら置き換えやすいという指摘は重要です。インターネット上では TCP が必須ですが、データセンター内部のネットワークなら、スイッチから NIC まで統一的に Homa 向けに設計することも現実的です。今後の展開としては、AI インフラ企業が自社クラスタで採用するかが注目点でしょう。

悠真: で、もう一つがハードウェア側の話。Strataというプロジェクトで、消費者向けのGPUであるRTX 4090一枚で、Qwenの125Bモデルを動かしてしまったという話。速度は約100から124トークン毎秒。

葵: 125Bというと、普通は複数の高級GPUで動かすサイズです。それが家庭のGPUで、しかも毎秒100以上のトークンは十分に実用的な速度です。これはモデルを圧縮・量子化し、メモリ階層と演算を工夫することで実現したものでしょう。

悠真: ここでの議論は、「ローカルで125Bが動くなら、API課金や送信の心配をせずに使える」という期待と、「品質はフルプレシジョンのものと比べてどうなのか」という問いに分かれる。速度が出ても、知識の細部が欠けているなら用途が限られるからね。

葵: つまり、ネットワークではHomaが「大規模AIクラスタの底」を更新し、Strataは「末端の机」に大規模AIを届けている。基盤の進化が両端から進んでいるという構図です。そしてこのStrataの話は、次の話題、つまり大規模AIの基盤であるデータセンターの話に自然につながります。

悠真: うん、データセンター。ここでは「透明性とデータ」というテーマで二つの話だ。まずはGoogleの話。

葵: ネブラスカ州にあるGoogleのデータセンターの水と電力の消費量、そして税の還付金の額が、Googleが提出した報告書の誤りによって明るみに出てしまったという話です。

悠真: 「誤った報告書によって露呈」というのが妙な話だよね。本来、提出書類には正確な数字が書かれているべきなのに、ミスがあったおかげで、隠されていたはずの、あるいは少なくとも明確にされていなかった消費量が見えてしまった。

葵: 議論の焦点は二つあります。一つは、データセンターという社会基盤の消費が、地元住民に対してどれだけ透明にされているべきか。もう一つは、税還付です。企業がどれだけの減免を受けているのかが、この事故で初めて公になったというのは、報告義務の設計自体に問題があることを示しています。

悠真: つまり、透明性は企業の善意に頼るのではなく、開示義務として制度化すべきだ、という声が出るのは自然だよね。一つの報告書の誤りが、制度の穴を照らし出したという皮肉な事件だ。

葵: そしてもう一つ、まったく別の場所で、同じ「データがどこへ行くのか分からない」という問題です。ノースイースタン大学とコンシューマー・レポートの共同調査によると、調査した21台のネット接続車のうち19台が、サードパーティにデータを送信していたと。

悠真: 19/21という数字が圧倒的だよね。車のテレマティクスって、保険の割引やナビの利便性とセットで語られるけど、裏側でどの事業者に何が送られているのか、購入時にユーザーは把握できない。通信の宛先も、送る内容も不透明。

葵: 二つの話の共通点は、「動いているシステムから、データがどう出て行っているのかが見えない」ことです。データセンターでは水と電力という物理的消費が、車では運転データが。どちらも、開示がなくても動いてしまう仕組みが問題だとされています。

悠真: 未解決の問いとしては、「開示されたとして、ユーザーはどうすればいいのか」だよね。データセンターの水消費は住民が選べるものでもないし、車のデータ送信は契約を解約しないと止められないかもしれない。情報の透明性と、行動の選択肢は別の問題なんだ。

葵: その点を踏まえると、次の話題は「見えない」の逆で、「ユーザーがローカルで自前のコントロールを取る」話です。ローカルAIの両方向というテーマで。

悠真: 一つ目はSCMというツール。macOS上で、すべての写真と、ビデオの全フレームをAIで検索できるようにする話。完全ローカルで動くのが特徴だよ。

葵: 技術的には、Whisperで音声を文字起こしし、OCRで画像内のテキストを読み取り、シーン分割で動画を切って、それらを全部検索インデックスに組み込む。つまり「あの内容の写真だったはずだけど、どこだったかな」という、従来のファイル名や日付検索では届かなかった領域まで届く。

悠真: ローカル完結という点が大事で、写真をクラウドに送ることなく、機密性の高い内容でも検索できる。プライバシーを保ったままAIの利便性を得る、という方向性の代表だね。

葵: そして対極の話がもう一つ。RemoveMacAIというツールで、macOS 27でApple Intelligenceをオフにし、ローカルに置かれたモデルをディスクから削除する。しかも reversible、つまり元に戻せる。

悠真: 「AIを追加する」ツールと「AIを削除する」ツールがペアで出てくるのが面白いよね。Apple IntelligenceはOS統合だから、普通の設定では完全に消えない、あるいはモデルがディスク容量を占めたままになる。それをきれいに取り除き、必要になったら戻せる、という専用ツールが必要になる状況自体が象徴的だ。

葵: 議論としては、「OSに統合されたAIはオプトアウトが難しい」ことが批判されていて、「自分のリソースと自分のデータの主権をユーザーが取るべきだ」という立場がSCMと共通しています。つまりどちらも「ユーザー主導」なんです。使いたい人はローカルで最大限使い、使いたくない人はローカルで完全に消す。どちらの自由もローカルだからこそ成立する。

悠真: もしこれがすべてクラウドだったら、削除の自由は持てないからね。この二つのツールは、同じ理念の両側から実現している、と言えるかもしれない。さて、少し雰囲気を変えて、レトロと文化保存の話題に行こう。

葵: Video Game History Foundation、VGHFのデジタルアーカイブが、5,000冊を超えるゲーム雑誌をデジタル公開しました。対象は1981年から2026年まで、そして今回、日本の雑誌も含まれるようになりました。

悠真: 1981年からの「非公式情報源」のアーカイブというのは、ゲーム史研究にとって決定的に重要なことだと思うんだ。ゲーム雑誌って、開発者インタビュー、レビュー、当時の論争が全部残っている一次資料なんだけど、紙媒体でしか存在しないまま絶版になっているものが多い。

葵: 特に日本の雑誌の追加が意義深いです。ファミコンから初代プレイステーションへと続く時代、世界のゲーム文化は日本の開発と日本のメディアと強く結びついていました。それらが体系的にアクセス可能になることで、日本側と英語圏側の資料を突き合わせた研究が可能になります。

悠真: 法的な注意点として、こういうアーカイブは「研究・教育用途」の利用条件が課題になることも多いんだけど、VGHFは文化保存を目的とした団体として、この規模の公開を実現した。未解決の問いは、「このアーカイブの範囲が今後どこまで広がるのか」だよね。1981年以前、つまりアーケード初期の資料はどうなるのか、など。

葵: さて、締めに近づいてきましたが、最後の二つの話題はどちらも「ものが壊れたとき、どう立ち直るか」というレジリエンスの話です。まずF1から。

悠真: バーレーンとセパンのレースで、ソフトウェアの不具合により、アピールラン、つまりレース前の走行披露の時間に、マシンがパワーを失うという事態が発生しました。

葵: アピールラン中のパワー喪失というのは、まさに「見られている場所での故障」です。対応は50分でのパッチ適用。それが間に合って本番に至ったわけですが、議論としては二つあります。

悠真: 一つは、なぜアピールランまでにこの不具合が発見されていなかったのか。レースウィークエンドというタイムテーブル上、ソフトウェアの最終検証の猶予が極めて短いという構造的な問題がある。もう一つは、50分でパッチが出せたこと自体が評価される点だよね。つまり、「壊れても直せる体制」があった。

葵: 「事前の完全なテスト」と「迅速な復旧体制」のトレードオフです。F1の現場では、後者に賭けるしかない場面があるということです。

悠真: そしてもう一つが、ウクライナの話。ロシアの攻撃が続く中、分散型の太陽光発電、例えばムィコラーイウの太陽光施設が、水と電力の供給を維持する支えになっているという話。

葵: ここが今回一番スケールの大きいレジリエンスの話です。中央集権的な発電所は、一撃で長期間の停電を引き起こせます。しかし分散された太陽光や蓄電池は、一つが破壊されても、残りが動き続ける。つまり、攻撃そのものを防げない環境では、「分散」という設計が防御の代わりになる。

悠真: F1の50分パッチと、ウクライナの分散太陽光。規模は全然違うけど、哲学は同じなんだよ。「完璧に守る」のではなく、「壊れても全体が止まらないようにしておく」。これは、今日話した他の話題にも通じるね。Xray-coreの脆弱性が1年隠れていた問題も、要するに「異常をいち早く検知して公にできる体制」がなかったということだし。

葵: そして最後の話題は、技術ではなく、人と思想の話です。二つあります。まず、The Economistがeffective altruism、つまり効果的な利他主義の現状を分析した記事に対して、Will MacAskill氏が応答しました。

悠真: effective altruismは、「限られた時間とお金を、どう配分すれば最も多くの善を生み出せるか」という問いに、証拠と合理的分析で答えようとする運動だよね。批判されることも多い運動だけど、Economistが改めて分析したということは、数年を経てこの運動自体も変化している、という評価の機会ということだろう。

葵: MacAskill氏本人が応答するという形で、批判と擁護が同じ場で交わされるのが良い点です。運動の主張者が外部の批判に直接応答するのは、透明性の問題だった前半の話題ともつながる部分があります。

悠真: そしてもう一つが訃報です。伝説的なベンチャーキャピタリスト、Bill Draper氏が亡くなりました。Draper家三代にわたるVCの系譜を築いた人物で、さらに280のNGOを支援した人でもあった。

葵: 三代の投資家の家系と、280のNGO。この二つは「資本をどう使うか」という一つのテーマの二つの答えです。VCとして企業に投資してイノベーションを促すのと、NGOに寄付して社会的課題に投資するのと。そしてこれは、effective altruismの議論と重なります。

悠真: 「リスクを取って新しいものを生む資本」と「確実に善を届ける資本」。Draper氏は両方をやったわけで、これをどう評価するかは、まさにEconomistの記事とMacAskillの応答が扱う「善を最大化するとは何か」という問いそのものだと思う。

葵: 今日一日の流れを振り返ると、面白いことに、最初の脆弱性の話と最後の人物の話がつながります。Xray-coreでは、情報が隠されることで信頼が損なわれた。Googleと車のデータでは、開示されないことで問題が隠れていた。一方で、EconomistとMacAskillの応答は、批判に開かれていることで議論が前に進む例です。

悠真: つまり今日の共通テーマは「開かれていることの価値」だね。コードも、データも、志も。閉じたところで問題は積もり続けて、開いたところで議論が進む。私たちは今日、その両方の例を見た。

葵: というわけで今日も、最後までお付き合いいただきありがとうございました。私は葵でした。

悠真: 悠真でした。また明日、ハッカーニュース・ラジオでお会いしましょう。