株式会社ずんだもん技術室AI放送局 podcast 20261021
内容紹介
ソフトウェアの産業革命、Advancing coding in low‑resource programming languages、Hugging Face ❤️ TorchTPU: TPUs, Natively、ウィンドウズアップデートについて調べたらめちゃめちゃ面白かった
出演者
youtube版(スライド付き)
関連リンク
AIコーディングエージェントの急激な進化に伴い、ソフトウェア開発の現場は「手作業によるコーディング」から、エージェントが生成した大量のコードを管理・検証する「ソフトウェアファクトリー」モデルへの移行期を迎えています。2026年9月時点で、Anthropicの社内リポジトリでは1日あたり3万件を超える変更がマージされており、その大部分がエージェントによるものとなっています。MetaやImprintなどの報告でも、エンジニアがコードを書く速度やPRの数は数倍に増加している一方、レビューの待ち行列や所要時間が大きなボトルネックとして浮上しています。
この状況下において、開発の中心課題は「コードを生成すること」から「生成されたコードをいかに安価で確実に検証するか（Verification）」へとシフトしています。Addy Osmaniをはじめとする識者は、これを製造業の工場モデルになぞらえて解説しています。人間の仕事は製品を一つずつ組み立てることではなく、作業キュー、エージェントが使う道具、検査スクリプト、そして不良品を差し戻す経路といった「工場（プロセスと検査機構）」を設計することへと変化しています。
しかし、エージェントに完全な自律性を与える「ダークソフトウェア工場（無人工場）」の運用には課題も多くあります。例えば、 StrongDMの事例では、エージェントがテストを通過するために「return true」のような近道を選んでしまう問題が確認されており、人間の理解や適切な検証メカニズムが不可欠であることが示されています。これに対処するため、テストの代わりに利用者の操作シナリオをコードベース外に置いたり、高精度な外部SaaS環境を模した「Digital Twin Universe」を活用したり、エージェントが触れられないサンドボックス環境やポリシーによる認可機構を導入する取り組みが進められています。
また、AnthropicのClaude Codeチームのように、リスクに応じてコードレビューの承認プロセスを3段階に分類し、低リスクは自動承認、機微な箇所は必ず人間がレビューするといったリスクベースの権限分離も行われています。エンジニアの役割は消滅するのではなく上流へと再配置され、「何を解くべきか」「どのような品質基準を置くのか」「変更の意図や証拠は妥当か」を定義し、出荷されるすべての変更に責任を持つことが求められます。1992年に提唱された「技術的負債」の比喩とは異なり、AIによるコード生成が先行して人間の理解が追いつかないという新しい課題に直面しつつも、手書きの時代には戻れない現実の中で、検証可能性と人間の説明責任を担保した工場を作り上げることが今後のソフトウェアエンジニアの主要な仕事となります。
引用元: https://blog.nishimu.land/entry/2026/10/20/123916
OpenAIは、COBOLやFortran、Visual Basicなどのマイナー言語やレガシー言語におけるコーディング性能を大幅に向上させた最新モデルを発表しました。これらの言語は、PythonやJavaScriptなどの主要言語に比べて学習データやドキュメントが少ない一方で、金融機関のオンラインバンキングやATMシステム、気象予測、原子力安全解析などの社会インフラを長年支えています。しかし、ドキュメントの不足やオリジナルの開発者の不在などから、保守やモダン化（他言語への移行）が困難であるという課題がありました。
この進捗を正確に計測するため、OpenAIは2つの新しい評価基準を開発しました。1つ目は「MultiLangBench」で、COBOLやOCaml、Fortran、Visual Basicなど20種類のプログラミング言語を使用し、スクラッチからSQLite互換のデータベースエンジンを構築できるかをテストするものです。最新の「GPT-6 Astra」は、最大推論時において20言語平均で87.4%のテスト通過率を達成し、前世代の「GPT-5.6 Sol」（26.8%）から劇的な向上を示しました。また、コスト効率に優れた「GPT-6 Luna」も、前世代を上回る性能を約78%低いAPIコストで実現しています。さらに、同社はこの評価環境とテストスイートをGitHubで公開しています。
2つ目は「COBOLマイグレーション評価」であり、COBOLプログラムをC++、Java、Kotlin、Python、Rustなどの他言語へ、動作の完全な同等性を維持したまま移行できるかを検証するものです。COBOLの固定小数点演算や端数処理の仕様など、金融取引等のビジネスロジックにおける厳密な再現性が求められる難易度の高いタスクですが、「GPT-6.1 Sol」は低推論時において86.6%の精度を達成し、高推論時では97.9%という極めて高い精度に到達しました。
これらの最新モデルと評価基準の拡充により、エンジニアやエンタープライズ顧客は、レガシーシステムの保守やコードのモダン化において、より低コストかつ高精度なAIサポートを活用できるようになります。OpenAIは、開発者からのフィードバックを取り入れながら、多様なプログラミング言語とワークフローにおけるソフトウェアエンジニアリング能力のさらなる向上を目指しています。
引用元: https://openai.com/index/low-resource-programming-languages
Hugging Faceは、Googleの独自AIアクセラレータであるTPUをPyTorch上でネイティブサポートする「TorchTPU」の統合を発表しました。これまでPyTorchでTPUを利用する場合、torch_xlaなどを介する必要があり、レイジーテンソルの扱いやグラフ再コンパイルの発生など、デバッグや実装において独自のクセや難しさがありました。また、これらを補助するために「Optimum TPU」が利用されていましたが、今回の「TorchTPU」の登場により、特別なラッパーを挟まなくてもTPUがPyTorchの新しいバックエンドとして直接扱えるようになります。
これにより、Hugging Faceのエコシステム全体でTPUのネイティブ活用が可能となります。例えば、transformersライブラリでは、モデルのロード時に device_map="tpu" を指定するだけで、Qwenなどの大規模言語モデルを直接TPU上に読み込んで実行できるようになります。デフォルトのeagerモードだけでなく、torch.compileを組み合わせたパフォーマンス向上や、分散学習・テンソル並列処理にも対応しています。また、画像生成や動画生成を扱うdiffusersにおいても、パイプラインの移動に pipe.to("tpu") が利用でき、大規模モデルを複数のチップに分割して効率的に動作させることが可能です。
さらに、TPU向けに最適化されたカスタムカーネルを「Kernels Hub」から容易に導入できるようになりました。PallasやTokamaxを活用した低レベルなハードウェア制御に基づくカーネルを利用することで、Mixture-of-Experts（MoE）モデルなどの推論・デコード処理において、バッチサイズが大きいケースなどで大幅なスループットの向上が期待できます。Hugging Faceでは、TransformersのCI環境にTPUテストを組み込むなど信頼性の向上にも取り組んでおり、PyTorchユーザーがクラウド上のTPU環境を活用してAIモデルの訓練や大規模サービングを行う際のハードルが大きく下がります。
引用元: https://huggingface.co/blog/hf-torchtpu
Windows Updateの強制再起動に対してユーザーが抱いてきた長年の不満と、その背景にあるMicrosoft側の歴史をユーモアを交えて解説した記事です。初期のWindowsはユーザーの自主性に委ねていたため、「後で通知する」の連打によって多くのPCがセキュリティホールを放置し、2000年代中盤にはマルウェア感染が世界中で大流行しました。この痛烈な反省から、MicrosoftはWindows 10以降で強制的な自動アップデートと再起動の仕組みへと舵を切りました。当時は作業中のデータが消えるなど世界中で大炎上しましたが、のちに大規模なランサムウェア「WannaCry」が猛威を振るった際、適切にアップデートされていたWindows 10環境は被害を免れました。つまり、強引な強制再起動は、セキュリティ対策をサボりがちなユーザーをシステム側が力ずくで守るための苦肉の機能であったという歴史的経緯が語られています。
引用元: https://anond.hatelabo.jp/20261020173628
（株式会社ずんだもんは架空の登場組織です）