Anthropicが10年で最大5170億ドルの計算資源契約か、Asahi LinuxがM3 Macに対応

AI

Analysis: since October, Anthropic has entered into agreements for at least 14.8 GW of compute capacity and may spend as much as $517B over the next decade

Anthropicが10月以降に押さえた計算資源は、少なくとも14.8ギガワットに達するという。Techmemeが伝えたところでは、The Informationの分析として報じられたもので、今後10年の支払いは最大5170億ドルに上る可能性があるとされる。ギガワットは発電所の規模を測る単位で、AI事業者の契約が電力量で語られること自体が近年の変化だ。伝聞情報である点には注意が要るが、Anthropic、Lambdaと350億ドル規模のクラウド契約を締結へで見た動きが、単発ではなく積み上がっていることを示している。

OpenAI says it hit its “automated research intern” goal, its researchers now use 3.1 agent-workdays per human workday, and top users spend $7,000+/day on tokens

OpenAIが「自動化された研究インターン」という社内目標を達成したと表明した。Techmemeによると、研究者が1日働く間に、AIエージェントが3.1日ぶんの作業をこなす計算になるという。使い込む研究者は、1日あたり7000ドル超をトークン代（AIに読み書きさせた文字数ぶんの従量課金）に使っている。AIが研究される側から研究を進める側へ回りつつある、という主張だ。数字はいずれも同社の自己申告である点は割り引いて読みたい。

Seattle Times and Newsday are the latest publications to sue OpenAI and Microsoft

TechCrunchによると、米国の新聞2紙がOpenAIとMicrosoftを提訴した。自社の記事を無断でAIの学習に使われたという主張で、訴状は生成AIを「自分の尾を食べるヘビ」に例えている。記事を生み出す組織そのものを壊しかねない、という論法だ。原告の一方は両社からジャーナリズム事業の資金提供を受けており、その関係のまま訴えに踏み切った点が目を引く。

Claude・Cursor・Devin・Manus… AIエージェント14製品、社内システムを触らせて事故らないのはどれ？【中小企業の導入判断ガイド】

社内システムを触らせても事故らないAIエージェントはどれか、という観点で14製品を比べた記事。著者は導入のしやすさ、承認をはさめるか、隔離して元に戻せるか、費用の見通しなど8つの軸で並べている。結論は「安全な製品は存在しない」で、自動実行が既定でオフになっている製品が相対的に安全という整理にとどまる。どの製品も利用規約で現状有姿での提供をうたっており、損害はユーザー側の責任になると指摘している点は、選定前に押さえておきたい。

7割が「シャドーAI」未対策　Gartner提言・メルカリ事例に学ぶ、正攻法

@ITの記事によると、従業員が会社に無断でAIを使う「シャドーAI」に対処できていない組織が7割を超えた。Gartnerの調査では、対応できていないが43%、対応はしているが不十分が30%だったという。従業員の側では47.5%が無許可のAIを使っていると答えており、禁止しても使われている構図が数字で出た形だ。記事はAIを全社・部門・個人の3階層に分けて責任の所在をはっきりさせる案を紹介しており、メルカリのClaude Code全社展開も、配りながら統制する例として取り上げられている。

Infra

M2: Episode 1 (or, Asahi Linux on M3)

Apple製チップ搭載MacでLinuxを動かすAsahi Linuxが、M3世代への対応をインストーラーに取り込んだ。開発チームの発表によれば、カメラ・内蔵マイク・USB・WiFi・Bluetooth・動画のハードウェア再生など、M1／M2で動いていた機能はほぼそのまま動く。一方でスリープは使えず、MacBookのHDMI出力は無効化され、GPUによる3D描画は性能も電力効率も期待するなと明記されている。現状はインストーラーのExpertモードの奥にある実験扱いで、この条件を外すのはFedora Linux 45ベータの頃を目標にしているという。

Cloud in a Bottle: making self-hosting accessible to everyone

自分のサーバーでWebアプリを動かす作業を、スマートフォンを使う感覚まで簡単にしようという試み。作者の説明では、中身はUbuntu機の上でダッシュボードを出し、HTTPの要求をコンテナ化したアプリへ振り分けるだけの構成だ。アプリは管理者権限なしの強化コンテナで動き、ログインの仕組みとアプリ間のデータ共有が最初から用意されている。半年の非公開テストを経てAGPL-3.0で公開されたが、Rootless Docker and Its Hidden Security Trade-Offsが指摘したとおり、管理者権限なしで動かすこと自体は安全の保証にはならない点は頭に置いておきたい。

Prometheusとの関係から整理、なぜGrafanaは「OpenTelemetry」を推進する？

@ITが、Grafana Labsの開発者アドボケートへの取材をもとに、同社がOpenTelemetryを推す理由を整理した記事。Prometheusが数値の指標に特化しているのに対し、OpenTelemetryは指標・処理の追跡・ログをまとめて同じ規格で扱える点が違いだという。障害の原因を突き止めるには数値だけでは足りず、追跡やログと突き合わせる必要がある、というのが推進の理由にあたる。OTel Isn’t Going Wellで開発体制の細りが問題になっていた規格だけに、大手が旗を振り続ける意味は小さくない。

SREを組織にする技術

サービスを安定して動かす技術（SRE）を、企業のIT運用ルールであるITILの側から捉え直した無料の本がZennで公開された。SREとITILは対立するものとして語られがちだが、著者はその見方を検討し直し、両者をつなぐ形で全6部22章を構成している。SLI・SLO（サービスの品質目標を数値で決める考え方）やエラーバジェット、障害の振り返りといった実践が、既存の運用プロセスのどこに接続するかを示すのが軸だ。すでにITILで回っている組織にSREを持ち込みたい人に向く。

Aurora MySQL 8.4.8 の新機能「遅延レプリケーション」で DROP TABLE からの復旧を試してみた

複製先への反映をわざと遅らせる機能を使い、テーブルを消す操作からの復旧を実際に試した記事。DevelopersIOの著者は300秒の遅延を設定し、本番側でテーブルを削除したあと、削除が複製先に届く前に複製を止めている。そこから削除の直前の位置を指定して再開させ、消える前のデータを取り戻せることを確認した。誤操作に気づいてから動ける時間を数分でも作れる仕組みで、バックアップからの復元より速く戻せる場面がある。

Backend

JavaScriptをC言語にコンパイルする「porffor」がアルファ版に到達。ネイティブやWASMを生成可能

JavaScriptやTypeScriptを先にC言語へ変換し、そこから実行ファイルやWebAssemblyを作るコンパイラがアルファ版に達した。Publickeyによると、JavaScriptを動かすための実行環境を同梱しなくてよいため、生成物の大きさは実行環境ごと固めた場合の最大50分の1になるという。起動にかかる時間も100マイクロ秒を切ると報告されている。ただし作者自身が、実在するライブラリがようやく動き始めた段階で、Node.jsとの互換性が最大の課題だと述べており、既存アプリをそのまま通せる状態ではない。

Maybe We Shouldn’t Be Reviewing All This Code

AIがコードを大量に書くようになった今、コードレビューを速くする話ではなく、そもそもの位置づけを問い直すべきだという主張。ThoughtworksのCTOである著者は、知識の共有・品質の確保・設計の理解・若手の育成まで、あらゆる役割がレビュー1か所に集まりすぎていると指摘する。代わりに、2人以上で同時に書く進め方や設計段階の議論で前倒しし、形式や静的検査は完全に自動化して、人が見るのは例外だけにする案を挙げている。人が理解すべきは差分ではなくシステム全体だ、という締めくくりは、コードレビューは「技術」であるがレビューの腕を磨く話だったのと、ちょうど裏表の関係になっている。

GitHub - microsoft/tgrep: Trigram-indexed grep with a client/server architecture for fast regex search in large codebases locally

巨大なコードベースの検索を、索引を先に作っておくことで速くするツールがMITライセンスで公開された。grepやripgrepが毎回すべてのファイルを読み直すのに対し、tgrepは3文字ずつの並び（トライグラム）で索引を張り、候補になりそうなファイルだけを調べる。常駐するサーバーが索引を持ち、ファイルの変更を監視して差分を反映する構成だ。公式の計測では最大52倍速いとされる。前提となる索引を持てるかが分かれ目で、Alibabaのローカル検索ツール「zg」が意味の近さで探す方向に伸ばしたのに対し、こちらは同じ正規表現検索をひたすら速くする方向にある。

Debian Code Search: Fast TurboPFor with Go SIMD

Debianのコード検索サービスから、C言語のライブラリを呼ぶ最後の依存を外した記録。置き換えたのは整数の並びを小さく詰めるTurboPForという圧縮形式で、著者はGoに実験的に入ったSIMD（1命令で複数の数値をまとめて計算する仕組み）向けのパッケージで書き直した。ビット幅ごとに専用の処理を用意し、位置つきのビット数え上げを導入するなど段階的に詰め、最終的にC版の1.4倍遅い程度まで縮めている。それでもCを呼び出す版より速くなる場面があるとしており、Go 1.27 is releasedで新機能として挙がっていた実験的なSIMD対応の、実戦での使い勝手が見える例になっている。

Beyond ORMs

データベースの操作をオブジェクトとして扱うORMをやめ、SQLを直接書く形に戻そうという主張。著者は、ウィンドウ関数やCTEといったSQL側の機能をORMが扱えないこと、そして4万行規模のライブラリを抱え込む重さを問題にしている。代わりに提案するのは、テーブルごとに専用のクラスを1つ用意し、その中でSQLを書いて外には素直なメソッドだけを見せるやり方だ。ORMを全部捨てて生のSQLを撒き散らすのではなく、置き場所を1か所に決めるという整理で、規模の小さいアプリほど効きやすい。

Frontend

VS Code誕生から現在までの物語「The Story of VS Code」YouTubeで公開。作者のエリック・ガンマ氏はなぜIBMからMSへ移籍してVS Codeを作ることになったか

VS Codeの誕生から現在までをたどる公式ドキュメンタリーが、YouTubeで公開された。Publickeyによると、中心人物はデザインパターンの本やJUnit、Eclipseで知られるエリック・ガンマ氏で、IBM在籍時にMicrosoftを訪ねたことが移籍のきっかけになったという。当初の依頼はブラウザで動く開発ツールを作ることで、そこから生まれたWebエディタが土台になっている。今では当たり前に使われている道具が、なぜこの形になったのかを本人の口から聞ける内容だ。

フォームの Enter 送信で isComposing と keyCode === 229 を併用する理由

日本語変換の確定でEnterを押したら、書きかけのまま送信されてしまう。あの誤送信がなぜ起きるのかを、著者が仕様の側から解きほぐした記事。変換中かどうかは isComposing で判定できるはずだが、一部のブラウザでは確定時のイベント順が仕様どおりでなく、確定のEnterなのに false になってしまうという。そこで昔からIMEの処理に使われてきた keyCode === 229 を併用する、という回避策の理由が説明されている。そもそもの推奨は <form> と送信ボタンでブラウザに任せることで、自前でEnter送信を書くときだけこの判定が要る、という順序も示されている。

【歴史】Next.jsが覇権を握り、そして直面した試練の物語【動画解説】

Next.jsがフロントエンドの定番になるまでと、その後に抱えた問題を8段階でたどった記事。設定なしで始められること、コードの自動分割といった初期の設計が支持を集め、静的なページを少しずつ作り直せる機能で競合を突き放した経緯が整理されている。一方で著者は、App Routerの導入以降に開発の体験が悪化したこと、ビルド時間やエラーメッセージの分かりにくさ、深刻な脆弱性（プログラムの弱点）が続いたことを試練として挙げる。それでも離れられない理由を「乗り換えの手間が痛みを上回っていないだけ」と説明しており、Next.js 16.3正式版リリースで並んだ性能改善を、別の角度から見る材料になる。

フロントエンドエンジニアとしてのキャリアを終える

フロントエンド専任をやめ、バックエンドとクラウドに軸を移すという個人の記録。著者はReactやTypeScriptを一通りやり切った感覚があり、できることの繰り返しより未経験の領域に時間を使いたいと述べている。あわせて、画面の実装はAIがかなり書けるようになり、専任の求人自体が減っているという現場感も挙げている。フロントエンドから離れるという話ではなく、その知見を他の領域と掛け合わせる方が価値を出せるという判断で、同じ迷いを持つ人には読みでがある。

iOS 27のreorderable container APIで並べ替えを試してみる

これまでリスト表示に限られていた項目の並べ替えが、他のコンテナでも書けるようになったAPIを実際に試した記事。DevelopersIOの著者は、縦積みのVStackや格子状のLazyVGridでも並べ替えが動くことを確認している。アニメーションは自動で面倒を見てくれる一方、スクロールしないコンテナでは警告が出て、ScrollViewで包むと解消したという。並べ替え中に表示がぎこちなくなる場面もあったと書かれており、使いどころを見極める段階といえる。

Products

Kit by Speakeasy

コーディングエージェントを動かすための土台を、1つの実行ファイルにまとめたツール。ターミナルで使うクライアント、エディタと繋ぐための共通規格に沿ったサーバー、複数のエージェントを束ねる仕組みまでが同梱されている。共通規格に乗っているぶん、特定のエディタに縛られず、他のエージェント環境にも独自の繋ぎ込みなしで差せる点を売りにしている。設定なしで動かしたい人に向く。

Hyperprobe

動いている本番サービスに読み取り専用の探針を差し込み、ログに残っていなかった変数の中身を取り出せるようにするサービス。従来は「ログを1行足してデプロイし直す」しかなかったところを、置き換えずにその場で覗ける点が違う。Claude CodeやCursorといったAIエージェントから直接使わせることを想定しており、手元で再現できない不具合の調査に効く。本番へAI任せでコードを出すチームが対象だ。

GitWarren

プルリクエストのようなコードレビュー画面を、手元のPCだけで開けるアプリ。コミット前の変更にその場で行単位のコメントを付けられ、サーバーに上げる前に整理できる。AIが書いたコードをターミナルとエディタの間で行き来しながら確認する煩わしさを、1か所にまとめるのが狙いだ。複数のAIセッションを並行させて回している開発者に向いている。

dif.sh

機能の出し分けを切り替えるフラグを、外部サービスではなくコード内のMarkdownファイルとして持つ仕組み。アカウント作成もAPIキーも要らず、フラグの追加や削除は普通の変更と同じくプルリクエストで確認できる。エージェント向けの説明ファイルが同梱されており、コーディングエージェント自身に導入や管理をさせる想定になっている。同種のサービスが相次いで終了した経緯があるだけに、Gitを唯一の正とする発想には筋がある。

Experiential Labs

複数の提供元やローカルのモデルを、1つの鍵でまとめて呼び分けられるオープンソースの中継サービス。新しいモデルを試すたびにアカウントと鍵と支払いが増える問題を、1か所に集約して解く。溜まった利用データから無駄なトークンの使い方を見つけたり、専用モデルを学習させたりする機能も持つ。自社のクラウドに置いて動かす選択肢もあり、外に出したくないデータを扱う場合の逃げ道になる。