1017 | テック週報：AI、ネットワーク、そして細かい話

葵: みなさんこんにちは、葵です。

悠真: 悠真です。今日も技術系の話題をざっくばらんに話していきます。今日のテーマは大きく言うと「AIが自分自身を作り、そして評価が追いつかない」という話と、「エッジで動くモデル」、「ネットワークとセキュリティの転換点」、そして小ネタまで、この数日で話題になった幅広いストーリーを拾っていきます。共通して言えるのは、技術が速く動いているのに、人間側の仕組み、評価とかプライバシーとか標準化とか、がそれに追いついているのか、という問いですね。

葵: じゃあ早速、一番重い話題から。AnthropicのClaude Codeが、自分自身のコードの約9割を書いているという話です。しかもAnthropicでは一日3万件を超える変更を、自動化されたレビューで処理していると。

悠真: 3万件はすごい数字ですね。人間のレビュアーが3万件の変更を毎日見るのは物理的に無理なので、自動レビューが前提になっているのは納得感があります。ただ、ここで気になるのは「自動レビューがどの程度の品質を担保しているのか」という点です。

葵: そうですね。コードの9割をモデルが書いて、レビューも自動化されている。つまりコード生成からチェックまでのループがかなり閉じている状態です。生産性の話としては魅力的だけど、品質保証の責任をどこに置くのか、という問いが残ります。

悠真: それはまさに、別の話題とつながるんですよ。Mercorの研究で、「米国の労働時間の90%が、既存のAIベンチマークではほとんどカバーされていないタスクに属する」という調査結果があったんです。

葵: ああ、これは重要な指摘ですね。つまり、ベンチマークで高いスコアを出していても、実際の仕事の大半は測れていない可能性がある。

悠真: ええ。ベンチマークは作りやすい問題、つまり答えが一意に決まる問題に偏りがちです。でも現実の労働は、文脈の判断や曖昧な要件の整理みたいな、測定しにくいものが大半を占める。Mercorのデータが正しければ、「ベンチマークで良好」は「実務で有用」と同義ではない、ということになります。

葵: ここはまだ共通見解が出ていない段階だと思います。ベンチマークが悪いのか、ベンチマークの作り方を変えればいいのか。実労働に合わせたベンチマークをどう整備するのか、というのが今後の課題として残っています。

悠真: Claude自身の実力を示す面白い事例もありました。8つの模擬量子回路をClaudeが自律的に最適化して、操作数を最大で17分の1に削減したという話です。

葵: 17倍の削減は大きいですね。しかも「自律的に」というのがポイントで、人間が細かく指示したわけではなく、モデル自身が最適化の方針を見つけたと。

悠真: 量子回路の最適化は、手順の正しさを保ちながら冗長なゲートを減らしていく作業です。人間の専門家でも地道な作業なので、モデルがここまでできるのは実力の証拠とは言えます。

葵: ただ、Mercorの研究と並べると面白い対比になるんです。回路の最適化は「正解が検証できる」タスクです。シミュレーションで確かめればいいので、AIが強い分野ですよね。でも実務の90%みたいな曖昧なタスクは、そもそも検証の仕組みがない。

悠真: その通りで、「AIができるタスク」と「AIが測れるタスク」と「AIが実務で使われるタスク」が全部ずれている、という構図ですね。まだまだ議論の途上だと思います。

葵: そして同じClaudeが、暗号学の「ECDSAの謎」を解決したという話もあります。NISTの楕円曲線で使われていたシード値の出所が、長年疑問視されてきたわけです。

悠真: これは背景を説明すると、NISTが標準化した楕円曲線のパラメータにはシード値が付いていて、「これがどうやって生成されたのか説明がない。もしかしてバックドアでは?」という疑惑が長年あったんです。

葵: で、Claudeが解析した結果、そのシードはlrand48という古い乱数関数の出力で、Unixのタイムスタンプで初期化されていた、ということが分かった。つまりバックドアではなく、当時の開発環境の偶然から生まれた値だったと。

悠真: 疑惑が晴れたという意味では朗報ですが、その裏側には「どうしてこれが30年近く分からなかったのか」という問いが残ります。乱数生成の実装を調べる、というタスクは、大量の過去コードやドキュメントを横断的に当たる必要があって、モデルが得意な探索作業なんですよね。

葵: Claude Codeが9割のコードを書く、量子回路を最適化する、暗号の謎を解く。できることの幅は確かに広がっています。でも評価は追いついていない。ここが今日の最初のテーマの落としどころです。

悠真: では次に、こうして育ったモデルを、どんなハードで動かすか、という話に移りましょう。まず驚きの一手として、AppleのMLXでMuse Spark Openという約8160億パラメータのモデルが、4台のMac Studioで動いたという話です。

葵: 8160億ですよ。しかも36トークン毎秒を超える速度で。仕組みとしてはThunderbolt越しのRDMAで4台を繋いで、メモリを実質的に束ねていると。

悠真: RDMAは「リモートダイレクトメモリアクセス」で、ネットワーク越しに相手のメモリに直接アクセスする技術です。Mac StudioならThunderbolt 5で高帯域が出るので、モデルのレイヤを分割して各マシンに載せる分散推論が現実の速度で回る、というわけです。

葵: 専用クラスタじゃなくてデスクトップマシン4台で816Bが動くというのは、手の届く価格帯で巨大モデルが動く未来が近いことを示していますね。

悠真: で、もっとアングラな方に進むと、PS5でモデルサーバーが動いたという話です。脱獄したPS5上でllama.cppが動いていて、RDMA対応のGPUで11.4GBの共有メモリを使って、モデルサーバーとして機能していると。

葵: ゲーム機が推論サーバーになるという発想が面白いですね。PS5のGPUメモリを流用しているわけですが、もちろん脱獄なので保証は一切ない。

悠真: ここには解決していない実用上の課題がいくつもあります。発熱と冷却です。ゲーム機はゲームの負荷を想定して冷却設計されているので、24時間365日推論を回し続けるとどうなるかは未知数です。安定性も含めて、まだ検証途上と言うべきでしょう。

葵: 画像生成のほうでは、Black Forest LabsのFLUX 3 Image Kleinという、56億パラメータのオープンウェイトモデルが出ました。テキストから画像の生成に加えて、編集や複数参照にも対応しています。

悠真: 5.6Bなら家庭用GPUでも余裕を持って動くサイズです。編集と複数参照対応というのが実用面では大きくて、単に「文字から絵を出す」だけでなく、「この参照画像をベースにこう変えたい」というワークフローに対応している。

葵: 3つの話をつなげると、「巨大モデルを複数マシンで」「脱獄したゲーム機で」「小型モデルを手元で」。規模の方向性は違っても、推論がクラウドから手元に降りてきつつある、という流れは共通していますね。

悠真: 次は少し視点を変えて、モデルの「中身」をどう理解するか、という話です。Alex Wangの記事が、Transformerを「連想記憶」として捉える見方を提示したんです。

葵: 連想記憶というと、キーを与えると関連する内容が呼び起こされる、あの記憶のモデルですね。

悠真: そう。記事の主張は、Transformerの各層を「メモリストア」、つまり記憶の格納庫として見ると、挙動が整理しやすい、というものです。入力が層を通るたびに、その層に蓄えられたパターンが呼び出されて加算されていく、と。

葵: これは一つの整理の枠組みとして面白いですよね。ただ、これはまだ解釈の提案であって、実証が全部終わっているわけではない。

悠真: そしてその「中身の理解」と「外側の能力」が並行して進んでいる様子を見せる話が、StarSkirmish Bench v0.2です。これはLLMにC++のStarCraftボットを1時間で書かせるベンチマークで、GPT-6 Astraが57%の勝率で首位に立っています。

葵: 1時間で動くゲームAIを書ける、というのは、コード生成と戦略設計の両方が求められるので、実装能力の良い指標になりますよね。

悠真: ただ、ここには unresolved な問いが残ります。連想記憶という内部構造の理解と、ボットを書くような行動能力の進化は、実は独立に進んでいて、両者がどう関係するのかはまだ検証途上なんです。「メモリストアの理解が深まったからボットが強くなった」わけではない。両者を繋ぐ理論はまだない、と言っていいと思います。

葵: 内部の理解と外側の能力、どちらも伸びているのに繋がりが見えない、というのが現状です。ではここから、インフラの話に入りましょう。まずRFC8950という新しい規格です。

悠真: これは、BGPセッションでIPv6のネクストホップを使いながら、IPv4の経路情報を運べるようにする規格です。何が嬉しいかというと、バックボーンをIPv6だけで構成できるようになるんですよ。

葵: 今まではIPv4のルートを運ぶために、バックボーンのどこかでIPv4を残す必要がありました。でもRFC8950なら、経路そのものはIPv4のまま、中継の制御だけIPv6でやる、ということができる。

悠真: そう、IPv6-onlyバックボーンが実現可能になります。運用側としては、IPv4とIPv6の二重管理から解放されるのは大きい。ただ、これが広まるかどうかは、キャリアの移行計画次第です。規格はできても、既存網をどう載せ替えるかは別の問題ですね。

葵: ここで面白い対比として、トークンリングの歴史が出てきます。80年代から90年代にかけて、IBMが推したトークンリングというネットワーク標準があったんですが、これはより安価で、しかも速くスケールしたEthernetに敗れた、という話です。

悠真: トークンリングは技術的には当時なかなか筋が良かったんですが、100Mbit/sのEthernetが出てくると、コストと拡張性で勝負になりませんでした。つまり「技術の優劣」ではなく「コストと実装のしやすさ」が採用を決めた、という歴史の例です。

葵: RFC8950も同じ構図に置けるんですよね。規格として正しいかどうかより、実装コストがどれだけ低いか、既存設備からどう移行できるかが、採用を決める。標準化と実装コストが技術採用を決める、という点では、80年代と今が同じ問題を共有しているわけです。

悠真: ただ、当時と違うのは、RFC8950は既存のBGPセッションを壊さずに使える拡張である、という点です。移行パスが段階的に描けるので、トークンリングのように「全取替え」を迫られる話ではない、と期待されています。

葵: じゃあ、セキュリティとプライバシーの話に進みます。まず衝撃度で言うと、OpenBSDの「Big Fish」と呼ばれるバグです。なんと37年物の、16ビットのオーバーフローで、ローカルからのroot権限昇格が可能になるという。

悠真: 37年ですよ。このバグはSysVの共有メモリのアタッチカウンタで、16ビットの値が溢れることで起きる。OpenBSDはセキュリティに非常に厳格なプロジェクトとして知られていますが、それでもこの深いところのバグは生き残っていた。

葵: 「古いコードは精査されていて安全だ」という思い込みへの反例になりますね。むしろ古くて誰も疑っていないコードこそ、盲点になりやすい。

悠真: そしてこれは先ほどのClaudeの話とも繋がるんです。ECDSAの謎を解いたのは、古い乱数関数の実装を突き止める作業でした。Big Fishも37年前の実装の癖が原因です。レガシーコードの理解は、人間にとってもモデルにとっても、これからの重要な課題なんです。

葵: 一方で、自動化がプライバシーを侵食した例もあります。Home Assistantというスマートホームプラットフォームの話で、秘密情報に似たパターンのデータをスキャンして、そのハッシュをHaveIBeenPwnedに、オプトインなしで送っていたことが発覚して、GitHubで抗議が起きました。

悠真: HaveIBeenPwnedは漏洩したパスワードなどのデータベースを照会できるサービスで、「自分の情報が漏洩リストにあるか」を確認する用途で使われます。Home Assistantとしては、ユーザーの設定に漏洩済みの情報が紛れていないかをチェックする、善意の機能だったのでしょう。

葵: でも、送る前にユーザーの同意を取っていなかったのが問題です。ハッシュにしてあるとはいえ、外部サービスにデータが流れること自体を、ユーザーは知らされていなかった。

悠真: ここは議論が割れるところです。「ハッシュなら実害はない、安全のための機能だ」という意見もあり得るし、「勝手に外部送信するのは透明性の欠如だ」という意見も成立する。まだ収束した結論は出ていないと思いますが、少なくとも「自動化された善意」にも人間の監督と同意のプロセスが要る、という教訓ははっきりしています。

葵: そして規制側の話。eBayが、新しいFCCの規則に合わせて、無線機器の出品を制限しました。例外として、純粋にアマチュア無線の周波数だけで動くデバイスは認められています。

悠真: FCCは米国の通信規制当局で、規制に適合しない無線機器の販売が制限される流れがあります。eBayはマーケットプレイスとして出品を絞ったわけですが、これはアマチュア無線コミュニティには影響が大きい。なにせ機材の流通経路が狭まるわけですから。

葵: この三つ、37年のバグ、無通知の外部送信、そして新規制、全部に共通するのは「人間の監督が入るべきところに、コードの古さか、自動化か、規制の空白か、何かしらの隙間ができていた」という点ですね。

悠真: では最後に、少し軽めの話題をいくつか。まずWebの画像形式の話。Jake Archibaldが、写真やスクリーンショットにはAVIFがたいてい一番小さくて、JPEG XLはロスレス、つまり可逆圧縮の場面で勝つ、という比較を公開しました。

葵: 「どちらが勝つか」ではなく「用途で使い分ける」という結論が実用的ですね。写真ならAVIF、無劣化で保存したい素材ならJPEG XL、と。

悠真: そしてレトロコンピューティングの話。ある開発者が、DOSのソフトウェアレンダリングを好んでいて、その理由は「ピクセルが鋭く、バイリニアフィルタリングがない」からだと書いています。Quakeを800x600で60fpsで動かすには、現代の高速PCが必要になる、というのも含めて。

葵: 逆説的で面白いですよね。当時はハードウェアの制約でソフトウェアレンダリングをしていたのに、今はわざわざフィルタなしのピクセル感を求めて、高速なマシンで再現する。そして、その再現自体が今度は高速なPCを要求する、という。

悠真: 素材の話も一つあります。Cosentinoが2013年に開発したDektonという高性能素材で、耐熱性が高く、核となる成分は主に磁器、つまりポーセリンです。キッチンカウンターなどに使われる素材ですね。

葵: で、締めの小ネタとして二つ。まず、Daniel Temkinの「Folders」という難解プログラミング言語。コードがフォルダの入れ子構造だけで表現されていて、名前は完全に無視される、という言語です。

悠真: フォルダの中にフォルダをどれだけ深く入れるか、でプログラムを書くわけです。名前が無視されるというのが本質で、「構造だけが意味を持つ」極端な設計ですね。

葵: そして最後、/dev/nullという開発者向けのソーシャルネットワークです。GitHubでログインすると、プロフィールが自動で取り込まれる、という。

悠真: 名前のセンスが最高ですね。ただ、自動取り込みというのは、さっきのHome Assistantの話と微妙に共通する部分があります。「自動でやってくれる」のは便利だけど、何が取り込まれて外に出ていくのかは、ちゃんと意識したほうがいい、という点では。

葵: 今日一日の流れを振り返ると、AIはコードも量子回路も暗号の謎も処理できるようになった。ハードも、Mac Studio4台でもPS5でも小型モデルでも、手元に降りてきた。ネットワークはIPv6-onlyへの道が開けた。でも、評価のベンチマークは実労働の90%をカバーできておらず、37年のバグは残っていて、プライバシーの同意は後手に回った。

悠真: 技術の進歩と、それを支える人間側の仕組みのギャップ、というのが今日の一本の糸でした。みなさん、今日はここまで。悠真でした。

葵: 葵でした。また次回お会いしましょう。