1111 | 今週のテック新聞：AIの境界線と周辺の攻防

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

悠真: 悠真です。今朝のフロントページから、議論が盛り上がっているネタをピックアップしてお届けします。今日は二十四時間分の話題を、一つ一つじっくり見ていきますね。

葵: 今日のテーマの軸は、ずばり「技術の速さ」と「それを支える信頼」の関係です。モデルの能力を絞るか進めるか、AIが見つける脆弱性とAIが書く脆いコード、エージェントを速くする工夫、そして信頼したサービスが止まる話。

悠真: さらにモノ作り、自前で運用する話まで。全部つながってるんですよ。それではいきなり最初の議論から。アンスロピックの「フロンティアをペースする」というモデル能力の制限が、シャーマン法上の反競争的行為に当たるのか、というスレッドです。

葵: これ、あらかじめ少し説明させてください。アンスロピックが自社のモデルの能力を意図的に制限して、フロンティア、つまり最前線の進む速さを調整している、というポリシーがありまして。それが競争を歪めるのではないかという議論が、 Hacker News で勃発したわけです。

悠真: 法的な問いとしてはシンプルに見えて、実は泥沼なんですよね。シャーマン法違反の反競争的行為というのは、通常は独占企業が競争相手を排除したり価格を操作したりする文脈で問題になります。でもアンスロピックのケースは、競争相手を叩くんじゃなくて、自分のペースを意図的に落としている。

葵: そこがコメント欄で最初の分岐点でした。「これってむしろ消費者保護の延長じゃないのか」という意見。安全なペースに落とすのは社会的責任であって、価格をつり上げたり相手を排除したりしていないから反競争ではない、という立場です。

悠真: 一方で、それに対する反論も強かった。モデル能力の制限は、競合他社が速く進めば進むほど市場全体の進路に影響するわけです。つまり「自分を遅くする」こと自体が業界全体のペースを決める行為になっていて、それは市場構造そのものへの介入だ、という見方。

葵: 興味深いのは、この議論がアンチトラストの古典的な枠組みにきちんと収まらない点ですよね。コメントにもありましたけど、競争法は「消費者の利益」を基準にする。能力を絞ることは短期では消費者に不便を与えるけど、長期の安全性や信頼性を守ることにつながるという主張が成立するかどうかは、まだ誰も答えを出せていない。

悠真: ただ、ペースを絞る側と、逆に絞らず突っ込む側が同じタイミングで動いているのが面白いところです。グーグルがGemini 4 Carbonを発表したんですけど、これは最強モデルを謳っていて、サイバー防御と長期のエージェント工作に注力していると。Ultra契約者と開発者向けに公開されています。

葵: これは対比が鮮やかですね。一社はフロンティアの速度を落とそうとしている。もう一社は最強モデルをいち早く出して、特にセキュリティや長期のエージェント作業のような実戦的な領域に振っている。

悠真: つまり「能力を絞る勢力」と「能力を前倒しする勢力」が市場に並存している。ペース制限が反競争かどうかを考えるとき、コメント欄でも触れられていましたけど、実際に競合が全部速く進めているなら「遅くしている」ことの影響は限定的かもしれない。でも逆に、ペース設定が業界標準として機能してしまうと、話が変わってくる。

葵: ここでついでに、能力というものの捉え方についての話も出てました。アレックス・ワンの議論で、推論というのをトークン空間でのパスファインディング、つまり経路探索として捉える見方ですね。これだと、推論を多くすればするほど知性が上がるとは限らない、という含意が出てくる。

悠真: これ、実は能力制限の議論とつながるんですよ。もし推論がただの経路探索なら、能力の上限はモデルそのものじゃなくて、経路の設計や探索の仕方に強く依存する。つまり「フロンティアをペースする」というのが、探索の速さを調整する行為として理解できる。抽象的すぎるかもしれませんが、コメント欄でもこういう理論的な観点が混ざってきました。

葵: 未解決の問いとしては、ペース制限が本当に「安全のために」やられているのか、それとも別の理由があるのかは、外側からは検証できないということですね。規制と競争のバランスは、まだ答えが出ていない。このテーマ、私たちも追いかけ続けますね。

悠真: それでは次に進みましょう。アンスロピックの話でもう一つ、Project Glasswing という脆弱性発見の取り組みについてのスレッドです。

葵: これは数字が強烈です。始まって七か月で、CVEを442件発見した。年間に出る脆弱性全体のうち約0.5パーセントに相当する量です。そのうち2件は実際に悪用された、いわゆる in the wild な脆弱性でした。

悠真: 一方で、もう一つの数字が重要なんですよね。37,966件の指摘を出したんだけど、そのうち修正されたのは217件だけ。極端に少ない。

葵: ここがコメント欄で一番盛り上がったポイントです。「AIが見つけた脆弱性」の話は聞き馴染みがありますけど、実際にそれが直るかどうかは、また別の問題だという指摘です。

悠真: 一方で、元メタの開発者がAIコード生成について書いた記事も、同じスレッドで話題になっていました。AIが生成するコードは、浅いテストと過剰な複雑さ、そして人間による理解の喪失を招いて、結果として脆いコードベースを作ってしまうという指摘です。プルリクエストの速度は上がるけど、コードの実質的な堅牢性は下がる、という話です。

葵: この二つを並べると、絵が描けますよね。AIは脆弱性を見つけるのはすごく速い。でも、脆弱性を修正する側の速度や、脆弱性を作らないコードを書く側の速度は、人間側の理解やテストの深さに依存している。

悠真: コメントでも、発見と修正の速度差は本質的に未知だという指摘がありました。つまり、AIが見つけるペースに対して、人間やAIが修正するペースが追いつけるのかどうかは、まだ誰にもわからない。もしこの速度差が広がり続ければ、脆弱性のリストだけが膨らんで、実際には何も直らない世界になる可能性すらある。

葵: ここでつながるのが、ディープマインドのAlphaProof Codeの話です。これはSignalの暗号化プロトコルのコードを、300万行を超えるLeanの証明で形式的に検証したというものです。

悠真: これは面白い方向性ですよね。脆弱性を見つけて直す、という保守的なアプローチに対して、そもそも証明で正しさを保証してしまう、という積み上げのアプローチ。二つのスタイルが並立してる。

葵: コメント欄でも、これは同じ問題に対する二つの異なる答えだという指摘が多かったです。一つは「もっと速く見つけてもっと速く直す」、もう一つは「そもそも直す必要がないくらい強く保証する」。ただ後者は、全部のコードに形式的検証を適用するのは現実的には難しい、という課題は残る。

悠真: 未解決の問いとしては、AI主導の脆弱性管理の枠組みをどうするのか。発見と修正の速度を一致させるメカニズムを作るべきなのか、それとも形式的検証のような別の道に投資するべきなのか。これはこれから数年間の大きなテーマになりそうです。

葵: それでは話題を変えましょう。エージェントの性能を上げる工夫について。二つ連続してきました。

悠真: 一つはグーグルが公開した、モダンWeb APIのガイド集です。GoogleChrome/modern-web-guidance というリポジトリで、200以上のガイド、合計1.7メガバイト。コーディングエージェントにモダンなWeb APIを教えるためのものです。

葵: 効果は劇的で、コーディングエージェントが200のタスクに対して55パーセントから92パーセントまで成功率が上がったという報告です。

悠真: コメント欄で話題になったのは、「ガイド」というものの役割です。エージェントは知識は持っているけど、その知識が古かったり、文脈で適切なAPIを選べなかったりする。人間が明示的にモダンなAPIをガイドとして与えると、急に賢くなる。これは実用上とても重要な知見です。

葵: もう一つは、アマゾンが内部のチケット処理で使っていたモデルを、Sonnet 4.6からオープンソースのStrands Deciderという意思決定モデルに替えたという話です。これで数百万ドルの節約になったと。

悠真: これが特に面白いのは、タスクの性質です。チケット処理というのは、種類としては単純だけど量が多い。それに対して重い汎用モデルを使っていたのを、オープンソースの軽い意思決定モデルに替えた。つまり、モデルを「全部最強」にするんじゃなくて、タスクに合わせて軽いものを選ぶ、という発想です。

葵: コメント欄では、この二つの知見を合わせると、エージェントの実用性はモデルの能力そのものではなくて、どうやって文脈とガイドを与えるか、どうやってタスクに合わせて選ぶか、という部分に決定的に依存するという見方が強かったです。

悠真: ただ、これに対する反論もありました。今回の成功率の上昇は、Web APIのガイドという特定のタスクでの話。重いタスク、例えば複数ステップの複雑な設計や長期のエージェント工作に対して、同じアプローチがそのまま通用するかは未知です。ここはまだ一般化できていない。

葵: とはいえ、実用性を高める具体的な知見が続いているのは間違いないですね。次はセキュリティとプライバシーの攻防に移りましょうか。

悠真: はい。まずNotionの話です。Fireworks AIの安全事件に関連して、1パーセント未満のワークスペースで、帰属できないAIチャット記録が漏えいした可能性があると確認しました。該当する機能はすでに無効化されています。

葵: ここでコメント欄でポイントになったのは、「帰属できない」という部分です。つまり、どのワークスペースのどの会話が漏えたのかを、外部からは特定できない。影響範囲を正確に把握できないのは、大きな不安要素だと。

悠真: もう一つは、ニューヨークのクイーンズ公共図書館がランサムウェア攻撃を受けて、多くのオンラインサービスが使えなくなっているという話です。

葵: この二つをコメント欄がどうつなげたかというと、「どちらも、信頼したサービスが止まる」という共通の構造だという指摘です。Notionのケースは第三者依存、つまりFireworks AIのような外部のパイプラインで事故が起きた。クイーンズ図書館のケースは標的型攻撃で内部がやられた。原因は違うんですが、利用者側から見ると「サービスが突然止まる」「自分のデータがどうなったかわからない」という体験としては似ています。

悠真: ここから話題が広がって、いくつか関連する話が出ました。一つはモジラの研究です。約2500万人のFirefoxユーザーのデータで、Firefox 143の保護機能によって、一意に指紋識別できるユーザーの割合が75パーセントから46パーセントに下がった。しかも互換性は保てたと。

葵: これはプライバシー保護が現実的に機能している例として、コメント欄でも好意的に受け止められていました。実害を増やさずに指紋識別を絞れる、という証拠です。

悠真: 一方で、子どもの位置追跡についての議論もありました。アトランティックの記事で、子どもに対して絶えず位置を追跡することが自律性を損なう可能性があるという指摘です。HNでは、エアタグが問題解決を阻害するのかどうか、意見が割れました。

葵: ここもコメント欄が二極化していたんですよね。追跡は安全のために必要という側と、子どもが自分の問題を解決する機会を奪っているという側。どちらが正しいかの合意は出ていませんでした。

悠真: さらに、SynapticsがDisplayLinkをリバースエンジニアリングしてLinuxのRust DRM/KMSドライバを書いていた開発者に対して、125件の特許を挙げて停止命令を出したという話も。これはセキュリティとプライバシーというよりは、知的財産の権利行使の話ですけど、コメント欄では「ユーザーが自分の機器をコントロールできるか」という観点で、自前主義の議論とつながりました。

葵: あともう一つ、Verisignが22000の.nameドメインを終了する計画を撤回したという話もありました。コミュニティと法務の闘いの結果で、既存の登録は存続します。これも「ユーザーが依存しているサービスを、一方的に切り捨てない」という方向での良いニュースとして受け止められていました。

悠真: そしてもう一つ、テレビの電波を使った研究です。単純な無線受信機でテレビ信号の選択的なフェージングを利用して、壁越しに人体の動きを検知し、速度まで推定できるというデモです。

葵: これはプライバシーの文脈で非常に示唆的でした。コメント欄でも、プライバシーの脅威は「カメラ」や「マイク」のような意識的な機器からだけじゃなくて、もっと受動的な物理現象からも来るという指摘があった。

悠真: まとめると、セキュリティとプライバシーの世界では、「信頼を置いた相手がどう振る舞うか」と「自分の周りの情報がどう漏れるか」の両方が、同時に揺れている、という状況なんですね。

葵: それでは、少し空気を変えて「小さく速いモノたち」の話題に移りましょう。まずトヨタです。

悠真: トヨタがScionブランドを復活させて、KEI-01という軽トラックを米国で売ります。25マイル毎時の速度制限がついたLSV規格で、660ccのエンジン、そして2027年後半からフリート実証を開始する予定です。

葵: ここでコメント欄が盛り上がったのは、日本の軽トラという発想を米国に持ち込む試みそのものです。米国のトラックは大型化し続けている中で、小さくて実用的なものを「LSV」という規格で持ち込むというアプローチ。市場が受け入れるかどうかは、フリート実証の結果次第という指摘がありました。

悠真: PC側でも似たような「小さく速く」というテーマが進んでいます。Chips and Cheeseの解析によると、Zen 6ではBTBが速くなり、スレッドごとに二つのデコードクラスタを持ち、VNNIユニットが倍増します。さらに、Zen 6とZen 6cでアウトオブオーダーのサイズが異なるという構成になっていると。

葵: これもコメント欄で熱かったです。従来は「フラッグシップと効率版」という位置づけで整理されていましたが、Zen 6世代では実はアーキテクチャの深さ自体が異なる、つまりOoOのサイズが違うというのは、ちょっとした転換です。用途に合わせて選ぶ幅が広がる一方で、ソフトウェア側の最適化は複雑になるという指摘も。

悠真: ここでつながるのが、エンターテインメントや開発ツールの進化です。Ableton Live 13が発表されて、ステップシーケンサー、ARA 2、ドラムシンセ、キャプチャオートメーション、新しいマルチバンドとミッドサイドのラック、そしてSoftubeのエフェクトが加わりました。

葵: .NET 11では、ランタイムにネイティブなAsyncがプレビューで入ります。スタックフレームが13フレームから5フレームに減って、デバッグがずっと楽になる。NativeAOTとReadyToRunもサポートされます。

悠真: Blender 5.3は、ネイティブの3D高斯スプラッティングをサポートします。PLY、SPZ、glTFのインポート、ジオメトリノードでの処理ができるようになって、さらにDLSSのノイズ除去と色散も追加されました。

葵: これらを並べると、「小さく速い」だけでなく「必要な場所に必要な機能を足す」という方向性が見えてきます。軽トラックは小さく実用的。Zen 6cは効率版。.NETのAsync最適化は開発体験の改善。Blenderの高斯スプラッティングは新しい表現の実用化。

悠真: そしてもう一つ、Starlink Mini 2の議論もありました。オフグリッドの緊急時や遠隔地の接続には高く評価されているんですが、一方で「キャンプが常にインターネットに繋がることと矛盾するのでは」という懐疑的な声もありました。

葵: この二つの意見はどちらも正当なんですよね。緊急時のつながりは本当に価値がある。でも、日常のレジャーにまでつながりを持ち込むことの意味は、別に考えるべきだという。ここでも「便利さ」と「選択の自由」のバランスが問われている。

悠真: それでは、最後の話題です。自前主義と、サービスの終わり。この二つは対照的なので、一緒に語りたいですね。

葵: まず自前主義の側から。ある作者が、十年間にわたって運用してきた自宅のスマートホームのルールを公開しました。ポイントは、コアの機能は何もベンダーのサーバーに依存していないこと。ラズベリーパイの上に、TasmotaとMQTTとNode-REDを置いて運用しているんです。

悠真: これはコメント欄でも非常に共感を集めました。十年というスパンで見ると、クラウドサービスはいくらでも終わる。でも自分で持っているインフラなら、続けられる。

葵: そして一方で、Val Townの話です。Val Townは課金を停止して、2027年1月10日にサービスを終了し、2月1日には全面的にオープンソース化されるという発表です。

悠真: これは自前主義とは違う生き残り戦略ですよね。自分で運用するんじゃなくて、最後にオープンソースとしてコミュニティに「引き継ぐ」という道。Denoの文脈も含めて語られていました。

葵: コメント欄では、この二つが同じ問題への二つの答えだという指摘がありました。一つは「最初から自分で持つ」。もう一つは「最後に譲る」。どちらも、依存したまま終わる、という最悪のシナリオを避ける方法です。

悠真: ここから少し幅を広げると、関連する話がいくつかあります。一つは、テレンス・タオの「Six Math Essentials」という本です。クォンタ・ブックスから2026年に出る予定で、数、代数、幾何、確率、解析、力学を一般の読者に向けて説明するというものです。

葵: これは自前主義の話とは少し離れますが、「基礎を自分の手で」という精神は共通していますね。知識も自分で理解して持っているべきだという。

悠真: もう一つは、Tiny València という作品です。バレンシアの等角ピクセルアートマップを、実際の3Dデータから描画して、画像モデルでタイル一つ一つを塗り直したというものです。

葵: これは個人で、細かい作業を積み上げて一つの完成品を作った例です。手間を惜しまず、自分の作品をちゃんと持つという。

悠真: あと、パラントが元上院議員のジョン・テスターを顧問として雇ったという話もありました。民主党史の議会が連邦契約への精査を進める前に、先手を打った動きとしてコメント欄でも注目されていました。

葵: そして最後にもう一つ、GNU tarの面白い話です。一つのGNU tarコマンドで作ったpax形式のtarボールが、ツールによって8つの異なる方法で展開されたという話です。一部のパーサーは拒否して、別のものは奇妙な結果を返しました。

悠真: これはコメント欄で「基礎技術の実装がどれだけ揺れているか」という例として語られていました。tarというのは数十年ある標準です。それなのに、実装ごとに微妙に異なる解釈がある。細かい実装の差が、大きな問題を生む瞬間です。

葵: この十年間の自宅運用の話も、tarの話も、Val Townの話も、全部つながっています。自分の手に持ち帰るか、最後にオープンソースとして譲るか、それとも標準の実装が揺れているという現実を、備えとして受け止めるか。技術の「速さ」を語るとき、その裏側には必ず「信頼」と「継続性」の問題があるんですよね。

悠真: 本当にそうですね。本日の話題はここまでです。アンスロピックのペース制限とGemini 4 Carbon、Glasswingの発見と修正の速度差、エージェントのガイドと選択、セキュリティとプライバシーの揺らぎ、小さく速いモノたち、そして自前主義とサービスの終わり。

葵: どれも「続けよう」という人と「任せよう」という人の間で、まだ決着がついていないテーマばかりでした。私たちも引き続き追いかけます。

悠真: それではまた明日。おつきあいいただき、ありがとうございました。

葵: どうも、またです。