1003 | AIと道具たち：週間テックダイジェスト

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

悠真: 悠真です。今日も一日の話題を拾っていきます。今日のラインナップはけっこう幅が広いんですけど、根本をつなぐと、結局どこも「AIをどう動かすか」を考えているんですよね。モデルの上にどうビジネスを組み立てるか、どう端末で守りつつ開くか、どこで計算させるか、っていう。

葵: そう、しかもそれを古い機械や本の歴史から眺め直す話まで入る。じゃあ最初はSaaSとAIの関係から。

悠真: これはShrivu Shankarという人の主張で、かなり突き放した言い方なんですよ。「すべてのSaaS企業はいずれモデルのハーネスになる」って。

葵: ハーネス、手綱とか馬具って意味だけど、ここではモデルと人間の間に入って、モデルが安全に、ちゃんとした形で仕事をできるように包み込む層のことだよね。プロンプトの処理、ツール呼び出し、権限管理、ワークフロー全部。ユーザーから見ると「サービス」だけど、中身はモデルの外側の仕組みがほぼ全部。

悠真: で、彼の主張の核心は二つ。一つは、そのハーネスこそが競争力の中心になるということ。もう一つは、だからハーネスを外注するな、ということ。

葵: ここが今日のディスカッションポイントですよね。賛否分かれそうな。

悠真: そうですね。賛成側の理屈はこう。モデル自体はどんどんコモディティ化する。同じオープンウェイトのモデルを誰でも拾ってこられる。だとしたら差別化できるのはモデルの使い方、つまりハーネスの品質しかない。そこが貴重な資産だから、外注したら差別化の種を他人に渡すのと同じだ、と。

葵: 反対側や慎重派からするとどうなるかな。ハーネスの部分って、実はモデルが改善するたびに作り替えになるじゃないですか。モデルがツール呼び出しを賢くなれば、ハーネス側の複雑な補正ロジックは削れる。だからハーネスに深く投資しても、モデルの進化で溶けるリスクがある。だったら薄く作って、差別化はデータや顧客関係のほうに置くべきだ、という反論は普通に成り立ちます。

悠真: それ、実際に挙証がある話で。Wagtailが一月で二十億トークンをGLM 5.3 Flashで使った話なんだけど、これがまさに「ハーネス品質とコスト管理が競争焦点」の実例なんですよ。

葵: 二十億トークンってすごい量だよね。で、ポイントは低コストでそれが回せたこと。

悠真: ええ。エージェント的なコーディング、つまりモデルにコードを書かせて検証させて直させて、を大量に回すと、トークン消費は異常な速度で伸びる。この経済性が崩れていたら、エージェント型のSaaSは商売として成立しない。Wagtailのケースは「Flashクラスのモデルを選んで、コストを抑えながら大規模に運用できる」ことを示した。だからハーネスの中身は推論品質だけじゃなくて、モデル選択、コスト制御、Usage管理まで含む、と。

葵: だからさっきのShrivuの議論とつながる。ハーネスが競争力だと言うなら、そのハーネスには「コスト効率よく大量の推論を回す能力」も含まれる。その部分はモデル更新で溶けにくい。むしろモデルが安くなるほど、ハーネス側でどのモデルをどのタスクに割り当てるかの判断力が効いてくる。

悠真: 逆に「ハーネスは外注できる」という立場はどういう根拠かというと、認証や課金やワークフローエンジンみたいな汎用パーツは、特化したベンダーのほうがいいものを早く出す。全部自作したら運用コストが地獄になる。そこは割り切って買い、差別化になる部分だけ持て、という分割です。

葵: で、Shrivuはその分割線をどこに引くかが本題で、要は「差別化になるかどうか」の判断を誤るな、と。楽だから買う、で差別化の核を買ってしまう企業が一番危ない。未解決の問いとしては、モデルがどの速度で賢くなるか次第で、ハーネスに投資すべき深さが変わる、っていう部分は誰も答えを持ってないですね。

悠真: そしてそこからDB基盤の話に自然に移るんですよ。SupabaseがTursoを買収したっていうニュース。

葵: SupabaseはPostgres、TursoはSQLite。それぞれの軸をそのまま残して、エージェント向けのデータベースインフラを強化する方向。

悠真: これもさっきの話の続きですよね。エージェントが大量に動くと、エージェントごとのデータの置き場所が必要になる。Postgresは堅牢でリッチ、SQLiteは軽くて埋め込みやすい。この買収は「どちらが正しいか」ではなく両方を持ち寄って、エージェント時代のインフラを一社で賄おうという動き。

葵: これは賛否が出るタイプのニュースでもある。PostgresとSQLiteは思想が違うものを代表していて、統合する会社が増えると、将来の互換性や運用の複雑さがどうなるか、という心配は当然出る。一方で、エージェントのワークロードは従来のWebアプリと要件が違いすぎるから、既存の枠で養うより専用に設計するほうが合理的、という見方もあります。

悠真: 最初の話題はここまでにして、次に行きましょう。端末とOS側の変化。

葵: これ、今日一番面白い対比だと思ってる。AppleがmacOSでフルディスクアクセスを硬くした。理由は、自律AIエージェントが増えたことでプライバシーリスクが増大したから、という説明。

悠真: エージェントって、ユーザーの代わりにファイルを読む、アプリを操作する、ってことをするわけですよね。それが信頼できる相手ならいいけど、悪意あるコードや暴走したエージェントがフルディスクアクセスを持ったら、個人情報が全部さらされる。Appleはそれに対して追加のコントロールを置いた。OSの方向としては「閉じる」。

葵: 一方Metaは逆で、Muse Gadgetsっていうオープンソースのハードを公開した。ESP32とかRaspberry Piみたいな既存の安いボードを土台にして、AIのMuseを画面やセンサー、日常の物につなげるためのパーツ。

悠真: つまり「ハードは開く」。

葵: そう。この対比が将来の端末AI像を占うって言いたいところなんだけど、もう一つAppleの動きがある。Pass Designer。macOS 27のベータで、Walletのパスを作成してリアルタイムでプレビューできるツール。タグを意味的につけたり、バリデーションしたり。

悠真: これ、一見マイナーな開発者ツールに見えるんですけど、位置づけが面白くて。OSを閉じて守りつつ、開発者には「モデルやOSがリアルタイムにUIを生成する」ための土台を出し始めている。パスって、構造は決まってるけど中身は可変なものだから、AIに作らせる対象としてちょうどいい。締め付けと解放が同時に進んでいる。

葵: 議論としては、OSベンダーがエージェントに対して権限を握りに来ることの是非ですよね。安全は確実に上がる。でもエージェントの可能性もOSの許可次第で制限される。Metaのオープンハードはその対極で、センサーや家の物を好きにAIに繋げられる。どちらの未来が主流になるかは、まだ決まってない。次は、その「どこで計算するか」のさらに極端な例に行きます。

悠真: GoogleのProject Suncatcher。宇宙にTPUを置こうという構想で、そのプロトタイプ衛星がSpaceXのTransporter-18で打ち上げられて、交信が確認された。

葵: まだ実験の第一歩ですよね。軌道上でのAI計算って、太陽光が途切れないから電力的に理論上いい、という話は昔からあるんだけど、放射線への耐性、放熱、打ち上げコスト、全部未知数。

悠真: 成果が出るかどうかはまだ誰にも分からない段階です。なので「 orbit で AI compute」が現実になるかどうかは、この衛星が何を返してくるか次第。ここからは、逆方向の話、地球の机上で動かす推論の話。

葵: antirezのDwarfStar 4。Cで書かれた推論エンジンで、DeepSeek V4、GLM 5.x、Qwen3.8をローカルで実行できる。Metal、CUDA、ROCm、つまりApple Silicon、NVIDIA、AMDをカバー。

悠真: 個人プロジェクトで、ここまでやるっていう。意義は、さっきのSaaSハーネスの話とも繋がるんだけど、モデルが自分のマシンで動くなら、ハーネスの設計の自由度が全然変わる。外部APIのコスト制約やレート制限なしに、エージェントを設計できる。

葵: 同じく「AIの能力の新地平」の話でもう一つ。AtaraxosっていうCMU、MIT、NYU、Stanfordのチームの研究で、Strategoの最強プレイヤーを十六GPUで十五対一で破った。

悠真: Strategoって、チェスと違って相手の駒が見えない不完全情報ゲームですよね。鍵は、本体の戦略ネットワークとは別に、隠された駒を推測する第二のネットワークがあること。

葵: ここがディスカッションポイントで。不完全情報ゲームで「相手の手札を推測するモジュール」を独立させると、ここまで強くなる、っていう構成の発見は、ポーカーAIとか他の分野にもそのまま応用のヒントになる。一方で、Strategoは特定の構造のゲームだから、一般化できるかは未知数、という留保は必要です。

悠真: そしてDwarfStarの「ローカルで動かす」とAtaraxosの「大学のクラスタで16GPU」という対比も面白い。推論の安さと研究の深さが、規模の両端で同時に進んでいる。

葵: 次は開発ツールの現場。Zig 0.17.0が出ました。五か月の作業、二百六人のコントリビュータ、九百二十五コミット。目玉は二つ、ビルドシステムの再構築と、x86_64 Linux向けのELFインクリメンタルコンパイル。

悠真: インクリメンタルコンパイルって、コードを変えた部分だけ再コンパイルしてリンクする機能ですよね。C言語系のツールチェーンだとリンクがボトルネックになってて、大規模プロジェクトだと変更から実行までが遅い。これを自前でやってしまう、っていうのはツールチェーン全体を自分で書く思想の延長で、開発者体験の根本を変える話。

葵: もう一つは個人規模の話。Gleam、Org-mode、Pandocでブログを書くパイプライン。EmacsでOrg-modeで書いて、Pandocで変換、BlogattoとNixで型付きの静的なパイプラインにする。

悠真: Zigの二百六人の大掛かりな刷新と、一人の自分用のブログ基盤と、規模は違うけどテーマは同じですよね。ツールを自分の仕事に合わせて作り直す、っていう。

葵: ただこの二つ、賛否は分かれます。Zigのアプローチは「全て自分で書けば究極の体験になる」で、Gleamブログのアプローチは「型付きパイプラインで正しさを保証する」。でも反対側には「車輪の再発明で時間を溶かすだけ」という意見も普通にある。特にブログなんて既存ツールで十分、という声は必ず出ます。支持する人は「作る過程そのものが学びで、後々の保守性と理解の深さが違う」と言う。この対立は解消しないですね。

悠真: 締めは歴史の話に行きましょう。オランダのコンピュータ博物館、三つ。HelmondのHomeComputerMuseum、ZwolleのBonami、そしてDECマシンを揃えた「DEC barn」。

葵: DEC barnっていうのは、Digital Equipment Corporationのマシンを納屋に集めた、みたいな場所。企業博物館と違って、個人の情熱で残している類のもの。

悠真: そこで比較対象に持ち上がるのが、関西のShimano自転車博物館。ここ、企業の博物館なのに、自転車の歴史に徹していて、販売も autopromotion もしない。

葵: これが「良い博物館の在り方」の議論の中心ですよね。企業博物館って普通、自社の栄光の歴史を語る装置になりがち。それをあえてやらないことで、史実そのものに信頼が置ける。オランダの個人博物馆と同じ精神構造。歴史を保存する場所の質というのは、「誰の物語を語るか」をどう抑えるかで決まる。

悠真: そしてその「歴史を保存する」という動きのテキスト版が、Halmosの「The Legend of von Neumann」、1973年の文章が再発見された話。

葵: von Neumannの人物像を描いた古典で、再読する価値があると。読者たちが推薦するのは、「The Man from the Future」と「Turing's Cathedral」も。

悠真: これは今日の全体にも通じるんだけど、現代のAIとかツールチェーンとかハーネスとか、全部von Neumannたちが作った計算機の系譜の上にあるわけですよね。それを古い機械で見て、古い文章で読み返すことと、新しいものを作ることは、実は同じ活動の両面なんだ、という感じで今日は締めようと思います。

葵: ありがとうございました。また明日。