0907 | 週刊テックラウンドアップ:AI、セキュリティ、そして創造性

葵: こんばんは、葵です。

悠真: 悠真です。今日も一日の技術ニュースを、ただ読み上げるんじゃなくて、じっくり考えながら見ていきましょう。

葵: 今日のラインナップを見ると、面白い糸が一本通ってるんですよ。自動化が進むAI研究の現場、そしてその裏で進む攻撃の自動化、プラットフォームと規制の攻防、防御側の技術、OSとハードウェア、そして極限まで小さなコードで何かを作る職人芸。最後は「制約の中に創造性がある」という話で締めくくる。

悠真: 制約と創造性、最後の話と最初の話が不思議とつながってくるんですよね。じゃあ早速、一番重い話題から。OpenAIの発表です。

葵: これ、注目すべきは数字というかタイムラインの明確さですね。OpenAIは、自動化された「研究インターン」の目標を2026年9月までに達成したと発表しました。

悠真: 研究インターン、つまり人間の研究者がやるような初期段階の研究タスクを自動でこなせるAI、という位置づけですね。それをすでに達成した、と本人たちが言っている。

葵: で、次の目標は2028年3月までに「自動化されたAI研究者」を作ること。インターンから研究者へ、という階段を描いてるわけです。

悠真: ここで大事なのは、これは宣言であり、プレスリリースである、ということですよね。達成の定義が何なのか、誰がどう検証するのか、というのは外部からは見えにくい。研究インターンが「達成された」というのは、内部的なベンチマークなのか、実際に論文が書けたとか、実験が設計できたとか、そういうことなのか。

葵: そこは正直、情報が足りない部分です。ただ、タイムラインをこれだけ具体的に切って発表する、というのは一つのメッセージでもある。つまり「我々のペースはこうだ」と先に言ってしまう。2028年3月という日付は、コミットメントでもあり、競合への牽制でもあり、投資家への説明でもある。

悠真: そして並行して、OpenAIのチーフサイエンティスト、Jakub Pachockiが警告を出してるんですね。機械知能の急速な進展には国際的な協調と、より強固な安全措置が必要だ、と。

葵: ここが一番議論のしどころです。同じ組織の中で、「自動研究インターンは達成した」「自動AI研究者を2028年に」という加速の宣言と、「国際協調と安全措置が必要」という警告が同時に出る。

悠真: この二人の発言、矛盾してるように見えて、実は一枚岩の戦略かもしれませんし、逆に内部での緊張を反映してるかもしれません。私たち外部からは区別がつかない。

葵: ええ。ただ、考えられる解釈としては、Pachockiの警告は「加速が本物だからこそ、ガバナンスも本気でやらないと間に合わない」というものです。つまり自動AI研究者が本当に実現すれば、研究開発のサイクルそのものがAIの中で回るようになる。人間がレビューする速度より早く、AIが実験を計画し、実行し、次の実験を提案する。そうなったとき、安全確認が後追いになる可能性がある。

悠真: 「国際的協調」という言葉選びも気になりますね。社内の安全措置だけじゃなくて、国家間のレベルの話をしている。AI研究の最前線が特定の数社に集中してる今、どこか一国だけ規制しても、研究は別の場所に移る。だから国際的な枠組みが必要、というロジックです。

葵: 一方で、冷たい見方もできます。国際協調の議論は時間がかかる。数年単位の交渉になる。その間に開発は進む。つまり「協調が必要」と言うことは、事実上「当分は現状のペースで進む」とも読める。

悠真: なるほど。警告それ自体が、加速を正当化する装置になる可能性も……。

葵: そこまでは断定できませんが、 unresolved な問いとしては明確で、まず「研究インターン達成」の証拠が外部に示されない限り、2028年の自動研究者宣言も信頼性の判断ができない。そして「国際的協調」の中身——何を協調するのか、誰がチェックするのか——がまだ語られていない、と。

悠真: もう一つ未解決なのは、AI研究者が実現したとき、人間の研究者の役割がどう再定義されるかですね。研究の方向性を決めるのは誰か、という問題。これは別の議論で必ず出てきます。

葵: さて、AIが研究を自動化するなら、攻撃も自動化される、という話に自然につながります。今日は二つのセキュリティニュースがあって、どちらも「新しい技術がセキュリティホールを突く」実例です。

悠真: 一つ目はarXivの論文、2505.12540。これは初の、ベクトル空間間の教師なし埋め込み翻訳を実現した、というものです。

葵: まず技術の説明をしましょう。今、検索や推薦のシステムは、テキストや画像を「埋め込み」と呼ばれる高次元のベクトルに変換して、ベクトルデータベースに保存してます。類似検索とか意味検索ですね。

悠真: 従来、別のモデルが作った埋め込み空間同士を対応づけるには、教師データ——つまり「このテキストはこのベクトルに対応する」というペア——が必要でした。並行コーパスを用意して、翻訳行列を学習する。

葵: この論文のポイントは「教師なし」のところ。ペアデータなしで、二つのベクトル空間の間の対応関係を発見できてしまう。そしてそれが何を可能にするかというと、ベクトルデータベースに対する属性推論攻撃です。

悠真: つまり、攻撃者が自分の持っている別の埋め込み空間を、ターゲットのデータベースの空間に「翻訳」できれば、中のベクトルが何を表してるか、属性を推論できる、と。

葵: そうです。具体例を考えると怖い話です。あるサービスがユーザーの文章を埋め込みにして保存してるとする。攻撃者はその埋め込みを直接読めなくても、統計的な構造——分布の形、クラスタの位置——から、原文の属性、たとえば話題、言語、あるいはもっとセンシティブな属性を推論できるかもしれない。

悠真: 「内容そのものを取り出す」のではなく「性質を推論する」攻撃ですね。プライバシーの定義を広げる話です。暗号化やアクセス制御で守っていても、埋め込みという「派生物」を守ってなかったら意味がない。

葵: そして教師なしでできてしまった、というのが一番の問題。今までは攻撃コストが高かった——教師データが必要だった——ことが、実質的な防壁だったわけです。それが崩れた。

悠真: 防御側はどう対応すべきでしょう。ベクトルを保存するときにプライバシー保護をかける、あるいはそもそもベクトルDBをパブリックに近い場所に置かない、という対策が標準化される必要がありそうです。

葵: そして二つ目。こちらは実際に起きてしまった事件です。攻撃者がLiquid Federationのウォレットから、約4,000BTC——約3億2,000万ドル相当——をSideSwapのPAK鍵を使って引き出しました。Liquidサイドチェーンは一時停止に。

悠真: BitcoinのLiquidは、連合制——federation——で運営されるサイドチェーンですね。複数の信頼できるノードがマルチシグでウォレットを管理してる。PAKというのは、ハードウェアに焼き込まれた公開鍵で、署名を特定のデバイスに限定する仕組み。

葵: そのPAK鍵、SideSwap経由のものが悪用された。ということは、連合のセキュリティモデルの中の一部品——正当な署名経路——が攻撃の入り口になったわけです。

悠真: 3億2,000万ドルという金額もさることながら、サイドチェーン全体が一時停止せざるを得なかった、というのが大きいですね。連合制の長所は高速な取引と、ある程度の信頼性。短所は、連合の一部が侵害されたとき、あるいは連合の鍵管理に問題が出たとき、システム全体が止まる。

葵: ここで二つのニュースをつなげると、今日のテーマが見えてきます。ベクトルDB攻撃は「新技術で守られていたものが攻撃可能になった」。Liquid事件は「新技術の運用パイプラインそのものが攻撃経路になった」。どちらも、技術の新しさは攻撃者にとっても機会だ、ということです。

悠真: AIが研究を加速させる時代に、セキュリティ研究も加速するし、攻撃も加速する。Pachockiの警告がセキュリティの世界にもそのまま当てはまるような。

葵: 続いては、プラットフォームと法的圧力の攻防の話です。まずNitterから。

悠真: NitterはX、旧Twitterの代替フロントエンドですね。AGPLv3で公開されてて、アカウントなしでタイムラインを見られるようにするツール。X Corp.からは2026年8月24日、 cease-and-desist——停止要求——の手紙を受けてました。

葵: それが今週、法的助言を得て、サービスを再開しました。NitterもXCancelも。READMEにも「法的助言に基づきプロジェクトは続行する」と明記されてる。

悠真: ここで私たちが考えるべきは、法的助言というものの重さですね。個人の開発者が「続けます」と言うだけなら警察沙汰のような自発的判断。でも弁護士の意見を仰いで、その上で続行すると判断した、ということは、彼らは自分の立場に法的根拠がある——少なくとも十分なリスクはない——と信じている、ということ。

葵: 通常、代替フロントエンドは、プラットフォームの規約違反や、スクレイピングの不正品、商標の問題などを主眼に C&D を出されます。対抗するには、フェアユース的な根拠、あるいは技術的にアクセス手段が公開されていたこと、商標を冒用していないこと、などを並べる必要がある。

悠真: Nitterの再開は「小さなツールは圧力で簡単に消える」という通説へのカウンターでもあります。ただし、これが持続するかは未知数。X Corp.が次の一手を打ってくるか、それともここで放置するか。訴訟に発展したら、個人開発者レベルでは持ちこたえられない可能性が高い。

葵: その一方で、法的圧力がもっと重い形で出た例が、Autistici/Inventatiです。A/Iという集団ですが、25年間、活動家やジャーナリストのためのメールやホスティングを提供してきた歴史あるプロジェクトが、なんと「世界的テロ組織」に指定されたことで活動を終了しました。

悠真: これは重いですね。テロ組織指定というのは、法的には非常に強い。指定されると、その組織への資金提供やサービス提供自体が犯罪になり得る。つまり「彼らのサーバーでメールを送っていた人」ですら、法的リスクを背負う可能性が出てくる。

葵: そして重要なのは、25年間のインフラが、一つの指定で消えた、ということです。サービス終了は、ユーザーが退避する時間も、データを移す時間も、事実上一瞬で与えられない。歴史ある共有インフラが、法的判断ひとつで無価値になりうる、という現実です。

悠真: NitterとA/Iを並べると、ネット上の「中立な」ツールが、どちらも法的圧力の対象になりうることがわかります。Nitterは「プラットフォームの規約や権利」の側から、A/Iは「テロ対策」の側から。どちらも、技術それ自体の善悪では決まらず、法的枠組みの解釈ひとつで存亡が決まる。

葵: 未解決の問いとしては、代替フロントエンドというカテゴリーが法的にどこまで許容されるのか、そして共有インフラを運営する人々が、どんな指定を避けるために、どんな自己検閲をする羽目になるのか、という二つですね。

悠真: さて、攻撃と規制の話ばかりだと暗いので、防御側の進展を見ていきましょう。Anubisというプロジェクトです。

葵: Anubisは、Webサイトがボットによる大量アクセスから自分を守るためのツールですね。今回リリースされたのは、WebAssemblyベースのProof-of-Work——計算の負担でボットをふるいにかける——方式のボットチェックです。

悠真: しかもこのリリース、1年間の開発、数百コミット、そして一部はRustへの書き換えを経てのものです。数百コミットというのは、地道な改善の積み重ねを物語ってます。

葵: Proof-of-Workのボット対策は、シンプルで美しい仕組みです。人間なら一度のアクセスに軽微な計算をさせておけばいい。ボットは大量のアクセスをするので、その分だけ計算コストが跳ね上がる。経済的な非対称性で攻撃を抑え込む。

悠真: で、それをWebAssemblyでやることで、ブラウザ側で効率的に計算できる。JavaScriptで書くより速く、予測可能な動作で実行できる。部分的なRust書き換えというのは、パフォーマンスクリティカルな部分をコンパイル言語に移した、ということでしょう。

葵: 一方、クライアント側の保護では、GrapheneOSのMessagingアプリの刷新があります。Android Compose UIでの全面書き直しに加えて、新しいセキュアなクリップボードペースト機能が入りました。

悠真: GrapheneOSは、プライバシーとセキュリティを重視したAndroidのフォークですね。クリップボードのペーストにセキュリティ機能を入れる、というのは一見地味ですが、実は重要です。クリップボードは、あらゆるアプリが一時的に読める「共有バッファ」で、意図しない情報漏洩の経路になりやすい。

葵: ユーザーがパスワードや認証コードをコピーして、別のアプリに貼り付けるとき、その経路を明示的に制御できる——どのアプリがペーストしているかを可視化し、確認させる——という設計ですね。

悠真: AnubisとGrapheneOSを並べると、「技術で守る」二つのレベルが見えます。Anubisはサーバーとボットの経済的攻防。GrapheneOSは端末上のユーザーの操作フロー。どちらも「攻撃が進化したから、防御も形を変える」という同じ原則で動いてます。

葵: そして、プラットフォームやOSのレイヤーまで降りていくと、次はOSそのものの話になります。NetBSDです。

悠真: NetBSD 9.5が、9.x系の最終版としてリリースされました。これでnetbsd-9ブランチはEOL、つまりサポート終了です。ユーザーには11.0、11.1、あるいは upcoming の10.2への移行が推奨されています。

葵: バージョンを上げていく、これは普段なんでもない話に見えますが、NetBSDの場合は意味が違います。NetBSDは組み込みからサーバーまで幅広いハードウェアで動くOSで、特に古い機器や特殊な環境で長く使われる傾向がある。

悠真: そしてNetBSDの実績は、単に「安定してる」以上のものがあります。NASA Lewisで衛星通信のTCPに使われた。KAMEプロジェクトではIPv6とIPsecのリファレンス実装の場になった。SUNETのInternet2陸上速度記録にも使われた。

葵: この三つの実績、共通点があります。どれも「実験的な環境で、標準に近いものを求めるときにNetBSDが選ばれる」ということ。衛星通信のTCPなら、遅延とパケットロスの極端な環境。IPv6やIPsecなら、まだ標準化が進んでない時期のリファレンス。速度記録なら、プロトコルスタックの性能の上限を知りたい。

悠真: つまりNetBSDは「研究と実装の橋渡し」をするOSだったわけです。だから、9.x系がEOLになる、というのは単なるバージョン管理の話ではなくて、そういう実験環境の継続性の話でもある。

葵: そしてNetBSDが宇宙で使われてきた実績の話をすると、自然と次は、もう一つの宇宙の話——Apple Siliconと宇宙——いや、Apple Siliconの話に進みますね。Asahi Linuxです。

悠真: Asahi Linuxは、AppleのMシリーズチップが載ったMacにLinuxを入れるプロジェクトです。今回、M3シリーズのMacがサポート対象になりました。ただしExpert mode での話です。

葵: Expert mode というのは、一般ユーザー向けの polished なインストールではなく、知識のあるユーザー向けの、まだ粗い部分が残ってるインストール、という位置づけでしょう。

悠真: そして、対応状況の開示も正直です。スリープ、HDMI、そしてGPU/DCP、つまりディスプレイのコントローラ周りがまだ動かない。Studio M3 Ultra は未対応。

葵: ここで思うのは、M1、M2のときのパターンを踏まえると、M3での未対応項目は、ハードウェアの世代交代で新しくなった部分——ディスプレイパイプラインやパワーマネジメント——だろう、ということです。Appleは世代ごとにSoCの構成を変えるので、逆デバッグが必要になる。

悠真: NetBSDとAsahiを並べると、OSの世界における「移植」の二つの形が見えます。NetBSDは、幅広いハードウェアへの「安定した抽象化」を提供する方向。Asahiは、特定のクローズドなハードウェアの中身を「リバースエンジニアリングで開く」方向。どちらも数年単位の地道な作業です。

葵: で、ここでふと気づくんですけど、Asahiで動かない項目が「GPUとスリープ」というのは、実はソフトウェアの問題ではなく、ハードウェアの設計そのものを理解する必要がある、という話なんですね。Appleは文書を公開してない。だから、観察と実験で回路の振る舞いを逆算する。

悠真: この「限られた資源と情報の中で、何かを作る」という話、実は次の話題とぴったりつながります。極小コードの職人芸です。

葵: まずはAustin Henleyの作品から。彼はPythonインタプリタのサブセットを、1024バイトのCで書きました。しかもマクロなしで。

悠真: サポートしてる機能は、def、if、for、print、そしてインデント。Pythonの文法的な柱のうち、必要最小限のものですね。

葵: 1024バイトというのは、この文章一つ分くらいの情報量です。その中に、字句解析、パーサー、評価器、そしてインデントベースの構文解析まで詰め込んでる。

悠真: インデントの処理が特に面白いところです。Pythonは括弧でなくインデントでブロックを決める言語で、パーサーから見ると厄介な構文です。それを1000バイト足らずで処理してる。

葵: そしてマクロを使ってない、というのもポイントです。コードゴルフ、つまり極限まで短いコードを書く遊びでは、マクロで字数をごまかすのが定石なんですが、それをやらずに素のCだけで書いてる。これは「遊びのルールを自ら厳しくする」ことで、成果物の価値を上げているわけです。

悠真: もう一つの作品は、Madorというもの。約80行のJavaScriptで、DOMをリアクティブにするライブラリです。Proxyタプルの [r, w] を使って、CSSセレクタでリアクティビティを宣言し、依存関係を自動で追跡する。

葵: ミニファイ後で855バイト、依存関係ゼロ。現代のフロントエンドは、ReactにせよVueにせよ、フレームワーク本体が数百キロバイトになるのが普通です。その中で855バイトでリアクティブなDOMを実現してる。

悠真: Proxyタプル [r, w] というのは、読み取りと書き込みを別々のProxyで抽象化してる、ということでしょう。読み取りが起きたときに「この値に依存してる」と記録し、書き込みが起きたときに「依存してる箇所を更新する」という、リアクティブシステムの基本を最小の部品で実現してる。

葵: HenleyのPythonインタプリタとMador、この二つの共通点は、制約そのものがデザインになっている、ということです。1024バイトの制約が、どの機能を入れてどの機能を捨てるかという設計判断を強制する。855バイトの制約が、APIの形そのものを決めている。

悠真: そしてこの「制約がデザインを作る」という考え方、実は明示的に語られてる文章があります。DUBのコラムです。ある博士候補生が、創造性は制約の中にある——制約を「障害物」ではなく「土台」と捉えるべきだ——という主張をしてるんですよね。

葵: 彼女はそれを「ペンシルケース」モデルと呼んでいます。筆箱、つまりペンシルケースは、決まった形の枠の中に、必要な文房具を整理して入れる。制約が、むしろ整理と選択を可能にしている、という比喩ですね。

悠真: これは、さっきのHenleyやMadorの話にそのまま当てはまります。1024バイトの箱の中に、Pythonの本質的な機能を「整理して入れる」。制約があるからこそ、何が本質かが見える。

葵: 一方で、制約と創造性の関係には、反対の話もあります。Ed WestがレビューしてるJames Marriottの『The New Dark Ages』です。この本は、読書——特に「楽しみのための読書」——の衰退を、スマホとTVのせいだと論じてる。

悠真: これは逆説的ですね。スマホという道具は、制約というより「無制約」の装置です。あらゆる刺激が常に入手可能。その結果、読書に必要な「一つのことに長く集中する」能力が削られていく、という主張です。

葵: つまり、Marriottの論は「制約がないことが創造性や深い思考を殺す」という方向で、DUBコラムは「制約があることが創造性を可能にする」という方向。見かけは対立してるようで、実は同じことを違う角度から言ってるのかもしれません。

悠真: つまり、人間の思考は、ある種の「容器」を必要とする。容器が小さすぎると詰め込めないが、容器が大きすぎると、中身が拡散してしまう。ペンシルケースモデルも、スマホ批判も、適切な容器の大きさを探す話、と言えるかもしれません。

葵: 教育の話も、この流れにあります。IEEE Quantum Week 2026、トロントで開かれる12週間のQuantum Oracle Engineering講座ですね。

悠真: オラクル設計、可逆性、検証——この三つは、量子コンピューティングの中でも「プログラミングの基礎体力」に当たる部分です。古典的なプログラミングなら変数と制御フローに当たる。

葵: そして「12週間」という期間設定も制約です。大学の学期と同じ長さ。実際に量子コンピュータに触れられる人は限られてるので、その中で基礎をどう体系的に教えるか、というカリキュラム設計そのものが制約問題ですね。

悠真: ここまで、創造性と制約、教育と読書、と知的な話が続きましたが、最後は少し軽い話で締めましょう。宇宙から始めます。

葵: Isar Aerospaceです。この企業は、ノルウェーのAndøyaから打ち上げるSpectrumという小型ロケットを作ってるんですが、わずか2回目の飛行で軌道に達し、衛星を放出することに成功しました。

悠真: これは欧州初の商業軌道ミッションです。そして「2回目で」というのが重要。宇宙開発では、1回目は失敗するのが普通です。データを取って、2回目で orbital に到達する、これは理論上の最短ルートに近い。

葵: そしてAndøyaという場所も意味があって、北欧の高緯度からの打ち上げは、特定の軌道——極軌道や太陽同期軌道——に向いてます。欧州の宇宙開発が、独自の地理的強みを活かした商業モデルを確立しつつある、ということです。

悠真: 続いて、日常の小さな話。Rob Weychertのウェブサイトが、日曜日は閉じるようにしました。

葵: サイト自体が日曜になると閉じる。「Bildschirmfrei」——画面フリー——を促すためです。似た例として、オランダのbabypark.nlやSGP、そしてB&H Photoは安息日の間、閉店しますね。

悠真: ウェブサイトに「営業時間」を持たせる、というのは、デジタルという「常時アクセス可能」の前提に対する制約です。さっきのペンシルケースモデルと、またつながりますね。

葵: 次は、Henri Bergiusが自分のソフトウェアのデフォルトライセンスをMITからEUPL-1.2に変えたという話。

悠真: EUPL-1.2は強いコピーレフトで、MITと違って、派生物にも同じ条件を課します。特に「SaaSループホール」——コードを改造して、クラウドサービスとして提供すれば、ソースを公開しなくていい、という抜け道——を閉じる方向です。

葵: 個々の開発者が、デフォルトのライセンスを変える、というのは、オープンソース文化の中での小さな、しかし意義のある宣言です。MITの自由さを捨てて、コミュニティへの還元を強制する方向に舵を切る。

悠真: そしてBryan Cantrillは、LLMで書かれたLinkedInの投稿を「スロップ」——手抜きの残飯——だと批判してます。簡単に検出できて、書き手の真正性を損なう、と。

葵: これも面白い視点です。LLMで投稿を書くことは、一見「時間の節約」ですが、実際には、その人の声が消える。読み手は、それを検出できて、そして信頼しなくなる。短期的な効率が、長期的な信頼を壊す。

悠真: そして最後、ジョークを一つ。あるユーザーのQBittorrentが「サンドボックスを脱走」して、企業所有のメディアを勝手にダウンロードし、Jellyfinがそれをライブラリに追加した、という。もちろん、これはユーモアとして語られてる話です。

葵: でも、このジョーク、今日の全部のテーマの要約みたいなものなんですよね。自動化されたツールが、人間の意図を超えて動く。QBittorrentも、OpenAIの研究インターンも、「自動化されたエージェントが、設定された範囲で動く」いう点では同じ構造。

悠真: 違いは、結果が「映画が勝手にライブラリに増える」か、「研究が勝手に進む」か、そして「監視と安全措置が間に合うか」だけ。

葵: というわけで、今日はAIの自動化と安全措置、セキュリティ、プラットフォームと規制、防御の技術、OSとハードウェア、そして極小コードと創造性、最後に宇宙と日常、と一気に駆け抜けました。

悠真: 全部を通して一つだけ言えるのは、制約が厳しいところでこそ、人の考えが際立つ、ということでしょうか。1024バイトのCも、日曜で閉まるサイトも、国際的協調を求める警告も、何を「できない」にするかが、何が「できる」かを決めている。

葵: それでは今日はこの辺で。お聞きいただきありがとうございました。

悠真: また来週、悠真でした。おやすみなさい。