0918 | 捨てる勇気とAIの現在地 — 今週のテック動向

葵: こんにちは、葵です。

悠真: 悠真です。今日も一日分の開発者コミュニティの話題を、記事そのものより「議論の中身」を中心に拾っていきます。

葵: 今週の流れを先に一言で言うと、「削る」と「増やす」の対比です。何を作らないかを決める話から始まって、エージェントの連携、モデルの実力、その裏側のインフラ、セキュリティ、そして少ないリソースで多くをやるOSS、最後に社会的な話まで。

悠真: じゃあ最初の話題から。Liam Nugentが「最重要な製品決定は、何を作らないかだ」と書いた投稿が火種になりました。

葵: これ、一見すると当たり前の精神論に聞こえるんですけど、議論ではちゃんと具体例が出てきました。McGovernの報告がそれで、コンテンツの80から90パーセントを削除したら、売上が上がってサポートの問い合わせが減ったと。

悠真: 九割消して数字が改善するって、感覚としてはだいたいの人の直観に反しますよね。普通は「消した分だけ機会損失では?」って考えるから。

葵: そこが議論の中心でした。賛同派の言い分は、コンテンツの大部分は実は「探す人を混乱させるだけのノイズ」で、サポートが減ったのは逆説ではなく必然だというもの。サポート問い合わせというのは、ユーザーが必要な情報を見つけられなかった証拠だ、と。

悠真: なるほど。つまりコンテンツが多いほど、正しいページにたどり着く確率が下がる。検索とナビゲーションの質がコンテンツ量に依存するから、減らすことは検索精度を上げることと等しい、と。

葵: そういう整理が出ていました。一方で反対意見もあって、80から90パーセントという数字自体への疑念です。「何のコンテンツかで話が変わる。リファレンスマニュアルを九割削ったら破綻する」とか、「削除で売上が上がるのは、そもそもマーケティング用の肉付けコンテンツだった場合に限るのでは」という声。

悠真: たしかに数字が一つだけだと、因果の方向が読めません。コンテンツが減ったから売れたのか、売れやすいページだけ残ったからか。

葵: そこは議論でも明確には解決していませんでした。ただ、面白かったのは「何を削るか」の判断基準は比較的合意されやすかったこと。閲覧も検索流入もゼロのページ、ユーザーの質問に答えていないページ、複数ページに分断されて同じことを言っている重複、こういうものから消すのは異論が少ない。

悠真: でも残すか消すかはページ単位で決めるとして、サイト全体をその目で見る人的コストが膨大じゃないか、という実務的な指摘もありましたよね。

葵: ええ。だからこそ、この話が「量を作る」話と接続するんです。Detailブログの投稿がそれで、タイトル的なキーワードは「Tokenmaxxing」。大量のトークンを燃やせば自律的に解決する、という期待が外れた、という失望の記録です。

悠真: AIエージェントに大量のコンテキストと長い実行時間を与えればコードベースが勝手に自己管理されていく、みたいな期待がこの頃ありましたから、それへの反論ですね。

葵: 議論で出た主張は、今の自律型コードベースには前提となるプリミティブが足りない、というもの。エージェントがコードを書くこと自体はできても、コードベースが「自己駆動」するための部品、つまり状態を持ち、不変条件を守り、変更を検証するための構造が存在しない。

悠真: だからトークンを積んでも積んでも、足りないのは知能や労力ではなく設計、という話になる。

葵: まさに。Detailブログの結論は「価値のある仕事は依然として良いアイデアとアーキテクチャだ」という一点に集約されていました。議論でもこれはかなり幅広い同意を得ていたんですが、完全に異論がなかったわけではない。

悠真: どんな異論ですか。

葵: 「アーキテクチャが正しければ大丈夫、というのも楽観的すぎる。アーキテクチャは一度決めたら終わりではなく、運用の中で腐る。エージェントがそれを保守できる仕組みがない限り、良い設計は良い出発点にすぎない」という指摘です。

悠真: どちらも正しい気がしますね。じゃあ未知の部分は。

葵: 二つあって、一つはどこまで削れるのか、削除の限界。もう一つは「少なく作る」のためのツールや規律が具体的にどんな形で来るのか。今日の話題はそこから派生していくので、頭の片側に置いておいてください。

悠真: 次はまさにその「コーディング現場で動くエージェント」の話です。まずSkillsyncから。

葵: SkillsyncはYC W26のバッチから出たもので、やっていることはAIエージェントのセッションの移植。Chatの履歴、Reasoningの過程、Tool-Callの記録を含むセッション全体を、Rustで書かれたtxcriptというエンジンを使って、Claude CodeからCodexへ、Cursorから別のエージェントへ、移動させられる。

悠真: エージェント乗り換え時の「履歴が消える」問題を解決するツールですね。他のエージェントに移ると、今までの試行錯誤が全部失われて一から説明し直しになる、というのは実体験としてよくある話だと思います。

葵: 議論で出たのは大きく二つの視点。一つは需要の肯定で、「エージェントを切り替えたい動機は常にある。料金、性能、得意分野。でも切り替えるたびに文脈が死ぬから結局一つに固定している。これが解決されるなら選択肢が広がる」という声。

悠真: もう一つは?

葵: 互換性への疑念です。各エージェントのセッション形式は内部構造がバラバラで、Reasoningの表現方法も違う。「移植して動いた」ことと「移植先で正しく理解された」ことは別問題では、という指摘。

悠真: これは先ほどの「未知」の答えにもなってない部分ですね。セッション移植の互換性をどう維持するのかは、まだ明らかになっていない。

葵: ええ。txcriptがRustで書かれているのは、長期的な互換性を保つ上で堅牢さを狙っている、と読むこともできますが、それはあくまで推測で、ソースの範囲では確定的なことは言えません。

悠真: Skillsyncが「エージェント間の連携」なら、Cloudflareのsecurity-audit-skillは「エージェントへの専門タスクの標準化」ですね。

葵: これはCloudflareが公開した、コーディングエージェント用のスキルで、多相的なセキュリティ監査を実行させられる。しかも出力が「検証済みで機械可読な所見」であることが特徴です。

悠真: 機械可読っていうのがポイントですね。人間が読むレポートじゃなくて、構造化されたデータとして出てくる。

葵: そこが議論の焦点でした。賛同派からは「監査レポートが構造化されると、CIに組み込んで自動で再検証できる。エージェントの監査が一度きりの儀式ではなく、継続的なプロセスになる」という評価。

悠真: 疑問派は?

葵: 「検証済み」という言葉の意味です。エージェント自身が見つけた脆弱性を、誰がどう検証するのか。偽陽性を自分で「検証済み」とマークしたら終わりでは、という指摘。また「監査をスキルとして配布することで、逆に監査の型が固定されてしまうのでは。攻撃者はその型の外側を狙うようになる」という声もありました。

悠真: 標準化は効率を上げるけど、予測可能性も生む、と。

葵: そういう緊張感は残っていました。あと、support側の話題としてmysetup.aiがあります。これはAIのセットアップをコミュニティで共有するサイトなんですが、MCPやGitHubでのログインが批判されて、手動入力が後から補われた経緯があります。

悠真: つまり「エージェント連携を便利にする側」と「エージェント連携が新たな摩擦を生む側」が同時に起きている、ということですね。連携と監査の話はひとまずここまでにして、次は基盤モデルの実力が問われる話題へ行きましょう。

葵: OpenAIのAstra for Lawです。GPT-6 Astraに、2億3000万URLをカバーする法的検索インデックスを組み合わせて、Vals-AIの法務リサーチベンチで54.0パーセントを獲得。比較対象の38.7パーセントを大きく上回りました。

悠真: 数字としては圧勝に見えますね。でも議論は冷めていましたか?

葵: 数字自体への批判はほとんどありませんでした。むしろ議論は「54パーセントって何パーセントなのか」に向かった感じです。ベンチマークの絶対値が低いことを指摘する声と、「法務リサーチは部分的な正解でも実務価値があるから、絶対値より人間との差が意味がある」という擁護に分かれました。

悠真: 葵さんはどう読みましたか。

葵: 注目すべきは、モデル単体ではなく検索インデックスを含めたシステムとしての強さです。230万ではなく2億3000万URLの法的インデックスというのは、事実の取得と推論を分けて強くする構造。これは後の話題ともつながる線です。

悠真: じゃあ次、Economistの記事。AIが一部の最も優れた人間の予測家を上回ったと報じた話。

葵: これ、HNではかなり皮肉っぽい反応でした。理由は「予測市場とLLMの比較研究はすでに複数あり、新規性がない」という指摘。記事自体はペイウォールで全文が読めないため、詳細を確認できないまま、既知の研究の再報道ではないかという疑念が中心になりました。

悠真: それは議論としては不毛になりがちですね。記事が読めないと、反論も肯定も根拠を持てない。

葵: ええ。ただ、確定したこととしては、AIの予測能力が人間のトップ層に届きつつあるという主張がメディアに出て、コミュニティは驚きではなく「またか」という反応だった、という事実は残ります。

悠真: じゃあその実力の裏側、証明の話へ。Gowersの書簡拒否です。

葵: これは繊細な話です。Fieldsメダリストたちが、LLMによって量産される証明への懸念をまとめた書簡を出そうとしていて、Gowersはその懸念自体には同意している。でも署名はしなかった。理由をブログで説明しました。

悠真: 懸念は共有するけど、署名しない。どういう理由だったんでしょう。

葵: ソースの範囲では、彼が自分の立場と書簡の形態の間に距離を感じたこと、署名という行為が自分の考えを正確に表さないと判断したことが示唆されています。議論では「量産証明への懸念は正当だが、それをFieldsメダリストの権威でまとめること自体が、議論を成熟させるのか否か」という点に意見が分かれました。

悠真: 権威による声明は早く注意を喚起できる。でも権威が出ると、それ以降の議論が「その書簡に賛成か反対か」の二択になってしまう危険もある。

葵: そこです。賛同派と反対派のどちらもがいたんですが、共通していたのは「証明の検証は数学の本質的な営みであり、量産される証明をどう検証するかが、書簡の有無とは独立の技術的課題だ」という点でした。

悠真: ここでつじつま合わせ的な橋渡しができますね。証明の検証、監査の検証、予測の検証。能力が上がるほど、検証の仕組みの設計がボトルネックになる。

葵: そしてこの検証の話に関連するsupportとして二つ。「LLM分類は特徴量エンジニアリングだ」という投稿があります。LLMの判定をそのまま答えにするのではなく、ロジスティック回帰の特徴量として使い、キャリブレーション、閾値、解釈可能性を確保する、という提案です。

悠真: それはまさに検証可能な形に落とす方法論ですね。LLMの生の出力は解釈しにくいけど、特徴量にしてしまえば人間が設計したモデルとして検証できる。

葵: もう一つはPrismMLのTernary Bonsai 2 27B。27Bパラメータなのに三値の重みで5.9GBに収まり、Qwen3の同サイズモデルのベンチマークの98.2パーセントを維持。コンテキストは262Kで、Apache 2.0ライセンス。

悠真: サイズの削減と性能維持のトレードオフをほぼ解消している、ということですね。

葵: これら三つは「LLMの実力」の証拠と「LLMの限界への備え」の道具が同時に進んでいるという、今日のテーマの好例です。次は、この実力を支える側の話。インフラとモデルの作り方です。

悠真: GLMの話から。

葵: GLMが10万基を超える中国製アクセラレータで本番推論を構築したという報告です。注目すべきは、その大量のインフラ作業の多くがGLM-5.3 Infra-Agentと呼ばれるエージェントによって行われたことで、結果として3倍のスループットを達成した。

悠真: エージェントがインフラ作業をした、というのが本題ですね。10万基規模の本番環境で、というのが議論の引き金になったと思います。

葵: そうですね。議論は二つに分かれました。「これはインフラ作業の一部が自動化できるという実証だ。繰り返しの多い作業ならエージェントが向いている」という受け止めと、「『エージェントがやった』の範囲をどう検証するのか。人間が最終判断をした部分とエージェントが書いた部分の境界が不明確では」という疑念。

悠真: どちらも「検証」の話にまた戻ってきますね。さっきの監査スキルの議論と同じ構造です。

葵: そういう繋がりがあります。そしてもう一つ、arXiv 2609.18842の無限パラメータLLM。これはかなり異質なアイデアです。

悠真: 何が無限なんですか。

葵: 固定の重みを持たないんです。ハイパーネットワークが、対話の相互作用データから重みをリアルタイムで生成する。学習もベイズ的なオンライン更新で、モデルの重みが静的なパラメータではなく、運用の中で常時変化する状態になります。

悠真: つまりモデルは「訓練済みの物体」ではなく「生きているプロセス」になる。これはGLMの運用重視の流れと同じ方向ですね。

葵: ええ。議論で出た懸念は主に二つ。一つは再現性です。重みが常に動くなら、同じ入力に対する振る舞いが保証されないのでは、と。もう一つは、この話は後で触れるセキュリティの議論に直結するのですが、「常に変化するモデル」をどう監査し、どう安全に保つのか、という点です。

悠真: 論文の段階では理論提案で、実運用での問題はまだ未知、ということですね。

葵: そうです。じゃあ次、まさにそのセキュリティの話題へ移ります。

悠真: CrowdSecの漏洩から。

葵: CrowdSecが2026年5月のソースコード漏洩を公式に確認しました。推定されている経路はTanStackの侵害。ただし顧客データは影響を受けておらず、トークンはすでにローテーション済み。

悠真: 結果としては最小限の被害で済んだ、ということですね。

葵: ええ。でも議論では、被害の有無よりも「どうやって侵入経路を特定したか」に注目が集まりました。TanStackの侵害が経路だとすると、依存パッケージやサードパーティのツールチェーン経由の漏洩は、直接的な攻撃と同じかそれ以上に検知が難しい、という指摘。

悠真: サプライチェーンの話ですか。

葵: そうです。意見としては「トークンのローテーションと顧客データ無影響の迅速な公開は模範的」という評価が多数でしたが、「なぜ5月の漏洩の公表が今なのか」というタイムラインへの疑問も残りました。

悠真: 次のGitLabのレート制限は、攻撃側ではなくトラフィック側の話ですか。

葵: GitLab.comが2026年10月19日から、レート制限をサブスクリプション連動に変更します。匿名ユーザーは1時間60リクエスト。議論では、その理由はほぼ確定的にLLMスクレイピングだと見られています。

悠真: エージェントやクローラーが大量のAPIを叩くから、正規ユーザーにも制限を課すしかない、と。

葵: そこです。そしてこれは話題の流れとして重要な点で、Skillsyncの「エージェント連携」とここが表裏の関係にあるんです。エージェントの活動が便利になるほど、インフラ側の防御は厳しくなる。連携とレート制限は同時に進む運命にあります。

悠真: 議論で出た懸念は?

葵: 匿名の60リクエスト毎時が正当な用途にも影響するのでは、という指摘です。CIやスクリプト、教育的な利用など、ログインなしでAPIを叩くユースケースは依然としてある。ただ、それをLLMスクレイピングと区別する手段が現状ない、という問題に尽きました。

悠真: そうすると、netmeisterのエッセイにつながりますね。

葵: ええ。あのエッセイの主張は明快で、AIハイプを批判しつつ、セキュリティの本当のボトルネックは脆弱性の発見ではなくパッチングだ、というもの。

悠真: 脆弱性を見つける能力はいくら上がっても、それを直す仕組みが追いつかなければ意味がない、と。

葵: 議論での合意点は意外と広かったです。「発見の自動化は進んでいるが、修正の運用は手作業のままで、その乖離が拡大している」という指摘には、異論がほぼありませんでした。分かれたのは「では自動パッチングは現実的か」で、楽観派と、「誤ったパッチは新たな脆弱性を生む」という慎重派に分かれました。

悠真: 今日の流れだと、監査スキルの「検証済み所見」と、パッチングの「自動化の危うさ」が、ちょうど対になりますね。次は防御側を支えるOSSとツールの話へ。

葵: ここは三つのメインで構成します。まずFlet 1.0。

悠真: 純Pythonでクロスプラットフォームのアプリが書けるやつですね。

葵: 1.0に到達して、6つのプラットフォームをサポート、150以上のコントロール、Flutterベースの実装で、WebはPyodideとWASM経由で動きます。

悠真: 議論はどうでしたか。

葵: 興味深いのは、単純な賞賛より「どこで採用するか」の検討が多かったこと。 FlutterをPythonから隠蔽する設計への評価、 WebのWASM経由という実装の重さへの懸念、 ネイティブなプラットフォーム固有機能への到達しやすさへの疑問。議論は実戦的な采配の話に落ち着いていました。

悠真: 次はVinix。これは本当に変わったプロジェクトです。

葵: V言語で書かれたモダンなOSで、100MBのRAMと1GBのディスクで動く。Apple M1をサポートしていて、Alpine LinuxのバイナリをVMやエミュレーションなしでネイティブに実行します。

悠真: 100MBでOSが動くって、今日の最初の「削る」テーマそのものですね。莫大なレガシーを削ぎ落とした設計。

葵: ええ。ただ議論では「V言語でOSという実績」より「Alpineバイナリ互換がどう実現されているのか」に関心が集まりました。システムコール互換の範囲、実際に動くアプリの種類、将来の互換性の維持方法などはまだ未知の部分が多い。

悠真: Manticore Searchは検索の話ですね。

葵: INSERT時に自動でチャンク分割を内蔵しました。5つの戦略があって、自社マニュアルでのrecall@5が55パーセントから83パーセントに向上。

悠真: RAGの文書分割を検索エンジン側が引き受ける、ということですね。ユーザーが事前にチャンク設計しなくても、ある程度の品質が出る。

葵: 議論では「5つの戦略の使い分けをエンジンが自動判断する根拠が不明」という技術的な質問と、「手動チューニングで98パーセント出せるなら自動化の価値は?」という対意見がありました。自動チャンク派の反論は「98パーセントを出せるのは専門家だけ。自動化はその下の大部分の人の下限を上げる」というもの。ここはまだ決着していません。

悠真: support側の三つも繋がっていますね。

葵: そうなんです。Bend 2はLean風の証明を持つ言語で、LAWS.bendという仕組みでAIのバグをブロックし、C並みの速度とGPU並列性を持ちます。ただしリポジトリが1コミットにsquashされていて、履歴が消えたことへの透明性の批判がありました。

悠真: 証明の話とまた繋がる。LLM量産コードの検証にLAWS.bendが使えるのでは、という期待もありそうです。

葵: Histerは自分が訪れたページと自分のファイルだけを対象にしたプライベート検索エンジンで、ブラウザ拡張とMCPサーバーを持ち、GitHubで3.8千スター。個人の情報を外部に送らずに検索する、という方向です。

悠真: flat.socialは、3Dの空間型ミーティングアプリをWebで再構築した話ですね。Three.js、LiveKit、Rapierを使って、一人でブートストラップしてデモが動いている。

葵: これら三つは「個人や少人数の資源で、凝ったことを実現する」例として一つの話題の中に収まっています。最後に社会とコミュニティの話題へ行きましょうか。

悠真: はい。日本の百歳以上の人口が初めて10万人を超えた、という話から。

葵: 正確には107,677人で、うち88パーセントが女性です。そしてこの話題の議論で必ず出てくるのが、2010年の監査で23万人の未確認の100歳以上登録が発見された経緯です。

悠真: 存在確認ができなかった高齢者が23万人も登録されていた、という事件ですね。当時大きな社会問題になりました。

葵: 議論では「今回の10万人突破は、その事件後の記録管理の改善を経た数字だから、単純な人口動態として読むべきではない」という慎重な意見と、「むしろ監査後のデータは信頼できる。長寿化の実態が初めて正確に見えた」という読みに分かれました。どちらの読みにも根拠はあり、決着はしていません。

悠真: New Yorkerのセルフストレージ記事は、対比が面白いですね。

葵: 世界のセルフストレージ容量の約90パーセントが米国にあり、年間400億ドルを超える市場、店舗数は主要なファストフードチェーンを上回る。

悠真: 「物を持たない国」と「物を保管し続ける国」の対比ですか。

葵: 議論では「消費文化と消費後の物の行き場」の話として受け止められていました。デジタルで効率化が進む世界で、物理的な物の蓄積が増え続けている、という皮肉が指摘されていました。

悠真: CCCの40C3は、その対比の反対側にある話ですね。

葵: 2026年12月27日から30日までハンブルクで「Model Citizens」というテーマで開催され、Call for Participationが開いています。

悠真: 今日の話題は全部、何かしらの形でコミュニティの産物でしたから、それが実際に集まる場がある、という締めとしては綺麗ですね。

葵: そうですね。今日の全体を振り返ると、Liam Nugentの「作らない決断」から始まって、エージェントの連携と監査、モデルの実力と限界、インフラの変化、セキュリティの防衛線、少ないリソースでのOSS、そして社会とコミュニティ。全部が「増やすか、削るか、検証するか」の三点を巡る話でした。

悠真: 検証の重要性が繰り返し出てきた一日でしたね。今日はここまで。ありがとうございました。

葵: また次回。