フィールズ賞受賞者25人がAIによる数学のベンチマーク化に反対を表明、OpenAIエージェントのRubyGems攻撃も明るみに

投稿はRust Foundationに掲載されたゲスト記事で、Microsoftにおける言語としての位置づけの変化を伝えるもの。

コメントには、Azure Storageで日々C++を書いているがRustはまだ広く使われている印象がなく、巨大なC++プロジェクトではFFIの部分が障壁になるという現場の報告があった。

Microsoftの技術戦略文書の共著者も現れ、実際の推奨は「Cを書くのをやめること」「C++のコードベースならモダンC++を使うこと」であり、何より高水準のアプリケーションコードをシステムプログラミング言語で書くのをやめてほしいという趣旨だったと説明している。その条件を満たす言語としてOCamlを挙げる流れも生まれ、静的リンクの可否など具体的な検討に移った。

記事はフィッシングを、注意力の問題でもDNSの設計の問題でもなく、ドメイン名の扱われ方の問題として整理している。

コメントで紹介されたのは、インドが昨年導入した金融機関専用ゾーンの事例。銀行は.bank.in、その他の金融事業者は.fin.inを、Webもメールも含めてすべての用途で使うことが義務づけられている。

電話番号についても1600番台が金融機関向けに割り当てられており、逆に1600番台は金融機関しか使えないのかという問いにTRAIの資料が示された。一方で、銀行名を騙るSMSからどこにも記載のない番号に電話させ、本人確認情報を聞き出そうとする手口を受けたという報告も出ている。

レビューは前モデルのX4からの変更点を中心に、実際に使ったうえでの評価をまとめたもの。

コメントで最も強い反応が出たのはUSB-Cポートがないこと。専用ケーブルを失えば、あるいは長期の旅行に持ち出して忘れれば文鎮になるとして、電子廃棄物の観点からもUSB-CかQi2は必須だという意見が並んだ。ただし充電頻度自体はきわめて低いという補足もある。

前面ボタンがなくなった点も、持ち方によって側面ボタンが使いにくいとして惜しまれている。CrossPointを使えば電源ボタンの短押しに画面の向きの切り替えを割り当てられるという情報も共有された。

リリースノートは16.0.4に含まれる重大なセキュリティ修正を伝えるもので、リモートコード実行に該当する。

コメントでは、gitフォージは公開前提であるにもかかわらず攻撃面が広く、なぜ最初から堅牢な設計を取らないのかという問題提起があった。

具体案としては、リポジトリやパッケージ、CIをissueやマージリクエストといったプロジェクト管理機能から分離すること、チェックアウトしたツリーをgitで操作する処理をサンドボックス下の別プロセスで動かし.git以下やプロジェクト外に書き込めなくすること、テンプレート展開のようにツリーを組み立てる処理はlibgit2で直接構築することなどが挙がっている。gitの扱いをSQLインジェクションに似た落とし穴として捉えるべきだという意見も出た。

記事はタイトルどおり、YAMLで起きる問題を仕様のせいにする通説にいったん距離を置く構成を取っている。

コメント欄はほぼ全面的にそれを打ち返す短い応酬になった。実際にはYAMLの仕様のせいだ、100%仕様のせいだ、迷ったら仕様のせいにしろ、という書き込みが並んでいる。

その見立ては正しいが、樽の中の魚を撃つようなものだ、という評もある。

記事はWindows XPの実装を掘り起こし、候補の中から1つを均等な確率で選ぶためにリザーバーサンプリングが使われていたことを示す。

コメントでは、Aを無条件に選び、Bを50%の確率で置き換え、という手順を順に追って確率が均等になることを確認する説明が付いた。Knuthの本には効率の劣る方法が載っており、Watermanがより効率的な方法を手紙で伝えて改訂されたという逸話も紹介されている。

SQLで各要素に乱数を割り当てて上位K件を取る方法との比較も出た。ただし乱数の割り当て自体がO(n)で、列全体を保持するか複数回走査できることが前提になるのに対し、リザーバーサンプリングは一度しか読めないストリームを前提とする、という違いが指摘されている。

記事はShopifyが方針転換の理由を説明したもので、コード共有による生産性という当初の前提がLLMの登場で変わったとしている。

コメントでは、数千人のエンジニアを抱える企業ならネイティブに行くべきで、React Nativeの抽象に縛られて機能の対応を待つ必要がなくなるという支持がある。一方で、成熟した手書きのコードベースを、エンジニアの第一言語でない言語のAI生成コードに置き換えるのは思い切った選択だという冷ややかな見方も出ている。

もう一つの論点はコストで、LLMの利用料が金額として一切触れられていないという指摘。書き直しの費用はAI研究への支出などの別の費目に丸められ、株主には見えなくなるだろうという予想も並んだ。

扱うデータはすべて公開情報で、シミュレータのように見えるが表示されている状況は実際のもの、という構成になっている。リアルタイムのAIエージェントによるハンズフリーの音声操作にも対応する。

プロジェクトはYouTubeで5M回以上再生された同名の動画シリーズ(旧WorldView)から生まれたもので、SNS全体では2500万を超える露出があったとしている。

2026年8月にGitHub Trendingの日次・週次で1位、Product Huntでは#8 Product of the DayになったとREADMEに記載がある。

すぐ使える仕様駆動のプロセスを提供しつつ、自前のプロセスを持ち込むこともでき、拡張可能で組織全体での利用を想定しているとしている。

最初のコミットから1年で1.0.0に到達した。READMEはこれを、作業が終わったからでも形が固まったからでもなく、プロジェクトが一貫性と有用性を備え、始めた人々よりはるかに多くの人に形作られるまで育ったからだと説明する。

リードメンテナの記事を引き、エージェントによって変化への適応が劇的に安くなる以上、価値は安定性から適応性へ移り、1.0.0は単なる数字になったという位置づけを示している。

構成は、組み合わせ可能なスキル群と、エージェントに確実にそれらを使わせる初期指示の2つ。何かを作ろうとしていると認識した時点で、いきなり実装に入らず手順を踏ませる。

対応環境が広く、Claude Code、Antigravity、Codex App/CLI、Cursor、Devin CLI、Factory Droid、Gemini CLI、GitHub Copilot CLI、Grok Build CLI、Kimi Code、OpenCode、Pi、Hermes Agentが列挙されている。

READMEには基本のワークフロー、収録スキルの一覧、設計思想、更新方法などの節が並ぶ。

取り込みは2段階のchain-of-thoughtで、まずLLMが分析し、その後に出典への追跡可能性を持つwikiページを生成する。増分キャッシュも備える。PDFから埋め込み画像を抽出してビジョンLLMで事実ベースのキャプションを付け、画像を含む検索結果として提示する機能もある。

対応形式はPDF、Office文書、EPUB/MOBI、Org mode、画像、メディア、Webクリップ、URLの一括取り込みで、PDF処理は内蔵・クラウド・ローカルのMinerUから選べる。

モデル設定はプロジェクト単位で、ChatとIngestの経路を独立に指定できる。取り込んだ原資料だけから回答するRead Sources Onlyモードや、プロジェクト書庫のエクスポート/インポート、既存ページからのインデックス再構築にも対応する。

対応先は予測市場10種と先物取引所7種で、SolanaのJupiter、Pump.fun、Raydium、Orca、Bags.fmや、EVM系チェーンのUniswap V3、1inch、Virtuals Protocolを統合する。操作は21のメッセージングプラットフォームから行える。

機能として118以上の取引戦略、大口ウォレットの追跡、裁定の検知、コピー取引、DCAボット、Bittensorのサブネットマイニングを挙げている。

Solana上のColosseum Agent Hackathon向けに12日間で開発されたとしている。

自分のモデルを持ち込み、任意のローカルプロジェクトを開いてエージェントに作業させながら、制御は手元に残すという方針を掲げている。

PI-Desktop用のアカウント登録は不要で、必須のリレーもエディタのロックインもないと明記している。

macOS、Windows、Linuxに対応し、リリースページからダウンロードできる。ドキュメントとスクリーンショットも公開されている。

READMEはこのリポジトリが開発者向けであり、安定しない可能性があると断っている。配布されるバイナリを有料にしているのはプロジェクトの資金確保のためで、開発自体は誰でもアクセスできるようここで進めているとしている。

git版をビルドする場合はコンパイラが必要で、WindowsはVisual Studioとclangツール、Linuxはclangと依存関係、macOS/iOSはXcode、AndroidはAndroid Studioが挙げられている。

ビルド手順はプラットフォームごとにmakeスクリプトを実行する形で示されている。

記事は、不具合修正PRをレビューする側が「このテストは修正前のコードに当てても落ちるのか」を確かめるために、ブランチをpullして修正をコメントアウトし、テストを走らせて戻すという手作業をしている点から始まる。確認結果はレビュアーの手元にしか残らず、PRが増えればボトルネックになる。

提案する手法は、PRを分割して下段に落ちるテストだけを置き、Vitestのtest.fails修飾子で成否を反転させることで「今のコードではこのテストは落ちる」という主張をCIが検証できる形にするもの。上段のPRで修正を入れる。筆者はこれをRed-Green Stacked PRと呼んでいる。

2026年9月時点でGitHubのStacked pull requestsとgh stackはPublic Previewであり、仕様やCLIが変わる可能性があると注記している。

筆者が見ているのは、AIと壁打ちして作ったIssue、PRのタイトル、CIが緑になっているかの3点だけで、コード本体もAI同士のレビュー結果もPR本文も普段は読まないという。25万行を通読するのは早々に諦めたと書いている。

趣味のプロジェクトではなく、7月から課金を開始してクライアント企業1社、カリフォルニアの企業1社、個人1人が利用中。無料を含むワークスペース数は133に達し、先週だけで50人がこのサービスでHTMLを共有した本番サービスだとしている。

記事は「コードを読まなくても大丈夫」という主張ではなく、読まないと決めた結果どこでつまずき、どんな仕組みを足し、何を作りすぎて捨てたか、その試行錯誤から残った仕様と実装のレビューループを扱う。

記事はまず、戦術的パターン(Entity / Value Object / Repository / Factory)の大半は2003年当時のJava/OOPの制約の産物で、代数的データ型のある言語では価値が目減りしている、というX上の評価を引く。筆者はおおむね同意しつつ、そこで止まると多くのコードが貧血モデルに落ち着く理由が説明できないとする。

分析の中心は、リポジトリを呼ぶためにdomainへcontextとerrorを持ち込むかどうかという選択で、この判断がトリレンマを生み貧血モデルに寄せていくという整理になっている。

解として提示されるのが、判断に何が必要かを型で返すDecisionパターン。型の制約を保ったままロジックをdomainに残せるとしている。

モデルは現在のキューブの状態と過去の手順を受け取り、次の1手を自己回帰的に生成する構成で、CEOの夏休みの自由研究として作られたとしている。

記事は難易度の構造を、完成状態から最短何手で到達できるかというdepthで説明する。depth 6までの累計は約824万局面で最近のニューラルネットなら表引きに近い形でも覚えられるが、depth 7だけで約1億局面あり、そこから先は丸暗記では厳しくなる。全体の状態数は約4.3×10^19、God's Numberは20。

その条件下で、学習後のモデルは初見の局面の99.83%を1回の生成で解けたと報告している。

出発点は、同じ作業ディレクトリでClaude Codeを2つ動かすと、片方がgit switchしたときにもう片方が読んでいるファイルまで入れ替わってしまう問題。git worktreeで作業ディレクトリを分けることで避けられる。

ただしworktreeを作るたびにgit worktree addを打ってディレクトリを移動する手間があり、worktreeの数だけディレクトリとターミナルが増えて散らかるため、筆者は一度使わなくなったという。

並列で動かすエージェントの状態を一望するために導入したHerdrがworktree管理とも相性がよいと気づき、構成を組み直した経緯を紹介している。git worktreeとClaude Code自体のworktree機能の違いにも触れている。

記事は友人に送ったメモを清書したもので、基礎的な内容から少しずつ細かい話へ進む構成を取る。Claude CodeやCodexをサブスクで使っている場合は、コストを利用枠の消費として読み替えるよう補足している。

基本の考え方として最初に挙げるのは、とりあえず最新モデルを使うこと。最近のLLMは進化が速く、最新モデルなら低いeffortや廉価版でも一世代前の最上位モデルと同等の性能が出ることがあるため、コスト改善としては最も手早いとする。

以降はキャッシュを活かす話など、より細かい論点へ進む。間違いがあれば指摘してほしいという但し書きが添えられている。

筆者は日々AIにコードとテストを書かせているが、レビューで回ってくるテストが無意味なことが増えたとする。検証すべき挙動が内部で呼ぶ関数をすべてモックしていた例や、細かい値だけを数百行にわたって固定し、本来固定すべき仕様は検証していない例を挙げる。

AIはテストを生成するが信頼は生成しないという整理で、テストが通らないことを嫌うため通るテストばかりを作り、「絶対成功お利口テストコレクション」になると書く。読めばわかる程度の粗であり、AI自身に「実装の詳細を固定していないか」と聞くだけでも見つかるとしている。

筆者が置く基準は、リファクタリングで挙動が変われば落ち、内部実装が変わっても挙動が同じなら通ること。そのテストが半年後も役立つかを判断する責任は実装者とレビュアーにあるとまとめている。

筆者がVimに本格的に取り組み始めたのは2025年12月で、Tech WorldのVim回を見てLSPやプラグインの存在を知り、実践Vim入門で操作を覚えた時期だという。しかし同じ頃にAIコーディングが主流になり、Vibe Codingの流れでプラグインを外していく動きさえ出てきた。

プラグイン開発にも興味を持ったがエコシステムは充実しきっており、その時代に切磋琢磨したかったと書いている。一方でVimを通じてコミュニティに出会えたことには感謝している。

まだ残っている面白い領域としてAIのための環境整備とCLIツール開発を挙げ、Neovimプラグインを管理する自作のNixモジュールnvimxを紹介している。時代の流れは速いので、遊べるうちに遊んでおくべきだという主張で締めている。

Astraが作る3Dシーンの多くはMCP経由でBlenderなどを操作させたものだが、アプリ内で直接コードから作らせるほうが手軽な反面、品質が落ちがちという問題意識から始まっている。RealityKitで作らせると単純な立体の組み合わせになりやすいという観察がある。

筆者は、Blenderがモデリングのために提供する機能をAPIとして提供するライブラリを作る案に至り、Astraに3時間で実装させた。Realitizerと名付けたそのライブラリでは、押し出し、スイープ、ベベル、サブディビジョンといった造形操作に加え、リグやアニメーションもSwiftで定義できる。

AIはコードを書き換え、プレビューで見た目を確認し、また修正するという流れでモデルを作る。輪郭や厚さ、ベベルの幅をコードで調整でき、Swiftの関数やループで寸法違いのパーツを生成することもできるとしている。

出発点は、ブラウザで高速な処理を動かしたいときの既存の選択肢がどれも過剰なトレードオフを伴うという問題意識。C/C++のEmscriptenはPOSIX互換レイヤーや仮想ファイルシステムを引き連れて巨大なグルーコードを生み、Rustのwasm-bindgen系は性能もサイズも良いが学習曲線が急で多段のビルドパイプラインが要る。

GoはGOOS=js GOARCH=wasmで書き味は良いものの、GCとスケジューラが丸ごと同梱されるため最小構成でも2〜3MBに膨らむ。「Goの直感的な書き味のまま数KBで動くWasmは作れないか」という問いから自作言語Hikeのコンパイラ開発に至った。

結果として、Goライクな構文、完全なlibcフリー、JSグルーコードの完全自動生成、Wasmバイナリ2.56KBという構成が揃ったとして、既存ツールチェーンとのサイズ比較を示している。

記事はまず、仕事が奪われるという理屈を認めるところから始まる。日本にはシステムエンジニアが約100万人いるが本来150万人必要で50万人足りない状態にあり、AIによる効率化で10人必要だった仕事が1人でできるようになれば、単純計算では9人分の仕事がなくなるという筋道になる。

そのうえで筆者は、簡単な仕事から順になくなるという理屈は成り立つとしつつ、AIでエンジニアの仕事そのものがなくなるとは考えていないと述べる。

理由として挙げるのが、最後まで人間にしか担えないものは「責任を取る」ことだという一点。AIの進化を見て将来に不安を感じている人を対象読者に据えている。

記事が取り上げるのは、AIが勝手にコードを書く時代に未経験からエンジニアとして採用されるのか、勉強している知識も実務に出る頃には代替されて無駄になるのではないか、という駆け出しエンジニアの声。

採用側の視点として、面接で「なぜ」を繰り返すのは知識量そのものを測るためではなく、判断の理由を言葉にできるかを見るためだと説明する。

筆者は株式会社PRUMの採用広報担当で、未経験からIT業界を目指す人と話す中で聞いた共通の悩みを連載的に扱っている。

記事は、内定後に入社後の活躍を不安に思う人や、未経験でチームの足を引っ張らないかと心配する人を対象に置く。新しい職場に行く直前は期待と同じだけの不安を抱えるものだとして、そこで肩に力が入る状態をまず認めている。

そのうえで、入社1か月目に採用側が良かったと感じるのは目立った成果よりも別の要素だとして、採用担当の視点から特徴を挙げていく構成になっている。

同じ筆者による未経験者向け連載の一本で、自社の未経験入社者インタビューへの導線が含まれる。

対象はSKILL.md 1枚だけの実装(6,953バイト・140行、MIT)で、フックも常駐プロセスもない。前置きや締めの挨拶を禁じ、最初の行に読者がすぐできることを置かせる10のルールからなる。disable-model-invocation: trueが付いており、/i-have-adhdと打って初めて効く。

測定は、gitのコミットメッセージ修正、Pythonで5GBのCSV集計、Dockerイメージの削減の3問を各3回。対照とスキルありの双方を2ターン構成に揃えている。文字数の中央値は1,884字→1,066字で−43%、出力トークンは1,603→1,056で−34%、9回中9回スキルありのほうが短く、範囲も重ならなかった。

ただし技術キーワードの数も3問すべてで減っており、情報が同じまま短くなったわけではないと明記している。文字数の減り方のほうが大きいため1,000字あたりの密度は上がり、Dockerの問いでは3.2個→6.6個と約2倍になった。検証環境はWindows 10、Claude Code 2.1.260、claude-opus-5。

筆者はBIPROGYの社員で、本社側には豊洲会のような定期的な勉強会があるのに対し、関西支社には参加・開催の文化がほとんどなかったという。自身が2026 Japan AWS Jr. Championsに選出され、同期がMicrosoftのTop Partner Engineer Awardを受賞したことを機に、その肩書を活かして企画に踏み切った。

当日の参加者は15名で、内訳は営業2名、クラウド部署以外のエンジニア5名、クラウド関連部署など8名(うち新人2名)。18:00開始でLT 7分×5名、その後30分の雑談タイムという構成を取った。

登壇者は全員入社4年目以下で、テーマは自由としつつ、Jr. Champions選出者とTPE Award受賞者がそれぞれAWSとMicrosoftの表彰制度を紹介することは企画初期から決めていたとしている。

記事はまず、配列を連続したメモリ領域として扱う言語では「メモリアドレス = 先頭アドレス + インデックス × 要素サイズ」という計算になり、0始まりなら先頭要素が素直に対応することを示す。ただし1始まりでも実行時に引き算が発生するわけではなく、あくまで設計上の話だと断っている。

広まった理由としてC言語のポインタ演算を挙げ、a[0]が*(a + 0)と等価になる対応の単純さを優先した結果、Java、JavaScript、Pythonなどが踏襲したと説明する。ダイクストラの1982年の論文EWD831も引き、長さNの列では0 ≤ i < Nという形が扱いやすいという主張を紹介している。

一方でLua、MATLAB、Fortran、Rは1始まりであり、0始まりか1始まりかは絶対的な正解ではなく設計思想の違いだと結んでいる。