AI が数学の証明そのものに入り込み、エージェント運用は出力を絞る方向へ

Internet Archive のブログ記事で、9月中に申し込んだ継続寄付が3倍になるというキャンペーン。投稿者は関係者ではなく一ファンで、他の人が寄付を思い出すきっかけとして共有したと書いている。

コメントには寄付したという報告が並び、複数の決済手段に対応したランディングページの作りが良いという評価が付いた。ユーザー主導のアーカイブを担う archive.today も補完的な存在として支援先に挙げられている。

一方で、自分で大きな範囲を取得しようとすると 429 が厳しく、高額寄付者向けの機能にできないかという要望、AI生成記事をインデックスし続けるのは持続可能なのかという疑問、ClimateGPT を止めてから寄付の話をすべきだという反対意見も出た。

Burrows-Wheeler 変換を用いた圧縮ツール bzip3 のリポジトリ。掲載されたベンチマークでは zstd の4分の1のサイズになると示されている。

コメントではベンチマークへの批判が上位を占めた。bzip3 のブロックサイズは 512MB に設定されている一方で zstd のウィンドウサイズはデフォルトのままであり、コーパスが Perl ソースの全バージョンを連結したものであるため、ウィンドウの差が効きすぎているという指摘である。zstd を大きなウィンドウと long range モードで測り直すべきだという意見も続いた。

最新リリースが1年前でビルドが失敗している点、並列展開を pbzip2 ではなく bzip2 と比べるのは不公平だという指摘もある。作者自身が特殊ケースにバグが残る可能性を否定できないと書いていることから、形式検証の題材によいという反応も出た。

作者の説明によれば、ロサンゼルス郡の2020年のLiDAR建物フットプリント(LARIAC)を課税台帳に結合し、市内の全 1,129,558 棟にフットプリントと高さを、98% に建築年を持たせている。いずれも公開情報だが取得は面倒だったという。それを3Dに押し出して都市の成長を再生している。

コメントには、LLM で作った可視化が増えすぎており「LLMプロジェクトの Hello World」だという批判が出た。プロンプト以外に何を解いたのか、データの取得やクリーニングは難しかったのかを知りたい、という内容である。

現存する建物しか表示されないため古い年代が実際より空いて見えるという指摘、高層建築が1960〜80年代に集中している点への言及、LAのスプロールは住んで用事を済ませようとして初めて実感したという感想も並んだ。

研究レベルの数学に特化した初のハッカソンという触れ込みで、40時間の形式で参加チームを募集している。

コメントでは、LLM の出力を40時間待つのは、短期間に集中して作るというハッカソン本来の魅力と相容れないのではないかという疑問が上位に来た。大手ラボが数学を前に進めたいのか、プロの数学者を LLM 出力の検証労働として安く使いたいのか、という見方も出ている。数学向けにモデルの推論能力を使い切るハーネスを作りたいので応募したという参加予定者の書き込みもある。

「初のハッカソン」という主張には反論が複数付いた。20年近く前の BSD 予想や SageMath のハッカソン、Research Collaboration Workshops という既存の形式があるという指摘である。Caltech のcs学科が近年トップ人材の採用に苦戦しており、その改善が動機の一つだという在校生の書き込みもあった。

ベルギーの公共交通をリアルタイムで表示する地図サイト。ブリュッセルの地下鉄など個別の駅の状況まで追える。

コメントではデータの出所への質問が集中した。中央のサーバーが公共交通向けのオープンなプロトコルを提供しているのか、事業者ごとに別形式のエンドポイントから集めているのか、路線をどうやって地図に落としたのか、といった内容である。政府の公開APIなのかという確認も入った。

同じくオープンデータを使う irail.be がミニマルな対の存在として挙げられ、マヨルカ島ではバスが Google Maps 上に同様に表示されて驚いたという報告も並んだ。暗色テーマで地名が読みにくいという指摘もある。

論文によれば、従来の(再)解析データに加えて衛星と気象観測所のリアルタイム観測も入力に含めることで、モデルの解像度、実行頻度、タイムステップ頻度を改善している。全レイヤーを重ねられるインタラクティブな世界地図も同時に公開された。

コメントでは、エネルギー業界では従来のNWP(数値気象予測)に対して大きな利点になるはずなのに実装例を見ない、という声が上がった。iOS から手軽に使う方法はないか、Google 検索やマップでは基本的な情報しか出ないという質問も出ている。

初期条件に使える観測データが減っている件への懸念、オンラインビューアに風向を方位として表示してほしいという要望も並んだ。山火事や大気質、海上の条件に効くのに、モデル生成時にベクトルとして作られているのに表示されない、という指摘である。

太陽系の氷の衛星が内部海を持つという理解が、Voyager、Galileo、Cassini の3つのミッションと計算モデル、Hubble・Webb の観測によって作られたことをまとめた記事。

コメントでは、エウロパ表面に立った宇宙飛行士は1日ほどで致死量の放射線を浴びるという記述が引用された。図版とデザインの良さへの評価、エウロパ以外にも候補となる衛星があることを知らなかったという感想も並んでいる。

2024年打ち上げの Europa Clipper が2031年3月にエウロパのフライバイを開始し、Dragonfly は2028年7月打ち上げで2034年にタイタン到着という予定が共有された。3ミッションを挙げながら New Horizons に触れないのは不自然だという指摘もある。

独立系ブラウザ Ladybird の8月分ニュースレター。Twitch がこれほど早く動くとは思わなかった、という驚きが最上位のコメントになっている。

この2年で勢いがついたという評価、アルファ版が出たら利用統計とクラッシュレポートで貢献するために常用したいという声が並んだ。AI による生産性向上と Google が Web 仕様を肥大化させる余裕を失ったことが重なり、安定すればシェアを取り始めても驚かない、という見立ても出ている。

可能な限り4本の並列接続でダウンロードするという記述には、ファイルが断片化しサーバーに不要な負荷をかけるので無効化できるようにしてほしいという要望が付いた。

表記が短くなる IPv6 アドレスを探した記事。

コメントでは、最短は :: で、ping できるものとしては ::1、公開アドレスとして最短は6文字の 2409:: という整理が出た。2600:: は Cogent の割り当てで大手ISPのものだが DNS サーバーではない、という補足も入っている。0.0.0.0 に ping すると通常は最初のホップが応答するので、6to4 経由なら 2002:: でゲートウェイからの応答が得られるはず、という書き込みもあった。

::1 は localhost や 127.0.0.1 より良いが、ポート番号を付けるときに [::1]:8080 と書かねばならないという不満、IPv4 なら 127.0.0.53:53 のように別アドレスへバインドできる余地があり systemd-resolved がそれを使っている、という比較も続いた。

国際化とローカライズで起きる問題を並べた記事。日付の表記揺れが例として挙がっている。

コメントでは、ISO形式の日付にすれば問題の3分の1は解決するという意見に対し、米国でISO日付を出すと2番目のフィードバックが「日付が変なので普通の表記にしてほしい」になる、という反論が並んだ(1番目はダークモードがないこと)。金額でも単位を数値の後ろに書くべき(12,345.67 USD)という提案も出ている。

文脈なしに単語を訳すと別の意味になる問題として save や open が挙がり、状態としての open とボタンとしての open を訳し分けられずファイルダイアログのボタンがおかしくなる例が共有された。ポーランド語の複数形が 1 / 2-4 / 5+ で変わる例、ヒンディー語のデーヴァナーガリー文字による英語の音写など、具体例が続いている。

1日の経過秒数を時・分・秒に分解する処理を、除算と剰余を避けて高速化する手法の記事。Lobsters にも同日に上がっている。

r/programming のコメントは、20年以上プログラミングをしてきたが、エポックからの秒ではなく1日の秒だけのタイムスタンプは使ったことがない、という反応から始まった。

これに対して実例が集まった。GTFS(交通フィード)は深夜0時からの経過秒を使う、ASTERIX などのレーダー系プロトコルでも一般的でデータ量が小さく日付は当日と分かっているので不要、GNSS は週の開始からの秒を使う、といった内容である。ただし日付をまたぐ記録ではトラックが分断されるという運用上の問題も報告された。

1024バイトに収めた Python インタプリタの実装記事。Lobsters にも同日に上がっている。

r/programming のコメントは、実装している機能が少なすぎて Python インタプリタと呼ぶのは釣りだ、という批判が上位に来た。タイトルを見て本当にフル機能のものを作ったと思った、という皮肉も並んでいる。

初心者の手作りとして評価すべきだという擁護に対し、著者は初心者ではなく2016年秋に大学で講義を持っていた、という指摘が入った。そこから話題は再帰下降パーサの経験談に流れ、JavaScript で POSIX シェルのパーサを書いた人の体験が長く語られている。

Nuxt の共同開発者が Encore("automated infrastructure for humans and agents")に参加したという発表。

コメントではまず、サイトを読んでも製品が何なのか分からないという声が上がった。AIに Terraform を書かせて deploy フローを回すという理解で、設計上は決定的であるべき領域なのになぜAIを挟むのか、という疑問である。

これに対し、AIで Terraform を生成しているのではなく、SDK の使われ方を静的解析してインフラのリソース利用グラフを決定的に生成しプロビジョニングする仕組みだ、という説明が入った。フロントエンドは半日で動いたのにデプロイの整備で週末が消えた経験があるので、AIエージェントのデモよりその差が縮まるところを見たい、という反応もある。IaC、LLM、Encore と課金先が積み上がることへの皮肉も並んだ。

PDF、PowerPoint、Word、Excel、画像(EXIFメタデータとOCR)、音声(EXIFメタデータと音声認識)、HTML、テキスト系フォーマットを Markdown に変換する軽量な Python ユーティリティ。LLM や関連するテキスト解析パイプラインでの利用を目的にしている。

位置づけとしては textract に近いが、見出し、リスト、表、リンクといった重要な文書構造を Markdown として保つことに重点を置く。出力は人間にも読める程度ではあるものの、想定される消費者はテキスト解析ツールであり、人間が読むための高忠実度な変換には最適な選択肢ではないと明記されている。

README は、現在のプロセスの権限で I/O を行う点を重要な注意として挙げている。open() や requests.get() と同様にプロセスがアクセスできるリソースには到達するため、信頼できない環境では入力をサニタイズし、convert_stream() や convert_local() など用途に対して最も狭い関数を呼ぶよう求めている。

HTML、CSS、メディア、シーク可能なアニメーションを決定的な MP4 動画に変換するオープンソースのフレームワーク。CLI としてローカルで使うほか、AIコーディングエージェントからスキル経由で、あるいはホスト型の制作ワークフローのレンダリング基盤としても使える。

エージェントから使う場合は npx skills add heygen-com/hyperframes でスキルを導入し、/hyperframes ルーターが各制作ワークフローを必要に応じて入れる構成になっている。エージェントや非対話実行では npx hyperframes skills update を使うよう案内されており、skills add --all がリポジトリ内の全 SKILL.md(公開20個に加えてリポジトリ内部用6個)を入れてしまうのと区別している。

skills add は skills.sh のレジストリブロブを解決するため main から数時間遅れることがあり、最新版が必要なときは skills update を使えという注記も付いている。

フィンガープリント偽装をC++レベルで行う Firefox フォーク Camoufox を土台にした、AIエージェント向けのアンチ検出ブラウザサーバー。git clone して npm install && npm start を実行すると localhost:9377 に立つ。

偽装の対象は navigator.hardwareConcurrency、WebGL レンダラ、AudioContext、画面ジオメトリ、WebRTC で、JavaScript が値を見る前の実装レベルで差し替える。シムもラッパーも使わないため痕跡が残らない、という主張である。Playwright はブロックされ、ヘッドレス Chrome はフィンガープリントされ、ステルスプラグイン自体がフィンガープリントになる、という問題設定を置いている。

これをエージェント向けの REST API で包み、肥大した HTML の代わりにアクセシビリティスナップショット(生HTMLより約90%小さい)、クリック用の安定した要素参照 e1/e2/e3、主要サイト向けの検索マクロを提供する。

Deep Exploration and Efficient Research Flow の略で、サブエージェント、メモリ、サンドボックスを束ねて長期のタスクを回すオープンソースのスーパーエージェントハーネス。拡張可能なスキルで動くと説明されている。

2.0 は 1.x とコードを一切共有しないゼロからの書き直しで、元の Deep Research フレームワークは 1.x ブランチで維持されている。開発の主軸は 2.0 に移った。

2026年2月28日、バージョン2の公開後に GitHub Trending で1位を取ったと README に記載されている。動作要件は Python 3.12 以降と Node.js 22 以降。

社内だけでHTMLを安全に共有するWebサービス Artifact Share を1人で開発している記録。開発開始から4か月でTypeScriptコードは25万行を超え、マージしたPRは1,144本、Issueは777件に達している。著者が普段見ているのは、AIと壁打ちして作ったIssueと、PRのタイトルと、CIが緑かどうかの3点だけで、コード本体もPR本文も読んでいない。

趣味のおもちゃではなく、7月から課金を始めた本番サービスである。ワークスペース数は無料利用を含めて133、直近4週間でマージしたPRは233本、revert はゼロ本で、全停止するようなサービスダウンも起きていないと報告されている。

開始当初は事前のガードレールを何も用意せず、事故が起きてからガードレールを作る方針を取った。記事はその試行錯誤の末に残った、仕様と実装のレビューループを中心にまとめている。

戦術的パターン(Entity / Value Object / Repository / Factory)の大半は2003年当時の Java/OOP の制約の産物で、代数的データ型のある言語では価値が目減りしている——という X 上の評価を出発点にしている。著者はおおむね同意しつつ、そこで止まらず、なぜ多くのコードが貧血モデルに落ち着くのかという構造的な理由に踏み込む。

戦術的パターンの目的として語られるものは、モデル駆動設計、不変条件の保護、テスタビリティ、交換可能性の少なくとも4つがあり、この記事が扱うのはモデル駆動設計の一面だけだと範囲を限定している。

結論は2点。ドメインモデル貧血症は怠慢ではなく構造的なトリレンマの結果として生まれやすいこと、そして「判断するために何が要るか」を型で返せば、型の制約を保ったままトリレンマを解けること。リポジトリを呼ぶために domain へ context と error を持ち込むかどうかの迷いも題材になっている。

不具合修正のPRには実装とテストが同時に入るため、そのテストが修正前のコードでも通ってしまうものだったとしてもCIは緑になる。再現できていないテストと再現できているテストが、CIの表示では区別できない——というのが出発点である。

解決は単純で、Redの状態そのものをCIがGreenと判定できる形にしてしまう。落ちるテストだけのPRを下に、修正を上に積む。TDD の Red-Green Refactor と GitHub の Stacked PR を組み合わせた「Red-Green Stacked PR」という呼び名は、記事の便宜のために著者が付けた造語だと断っている。

2026年9月現在、GitHub の Stacked pull requests および gh stack は Public Preview であり、今後仕様やCLIが変更される可能性があると注記されている。

現在のキューブの状態と過去の手順を受け取り、次の1手を自己回帰的に生成するモデル。学習後は、初めて見る局面の 99.83% を1回の生成で解けたと報告されている。CEO の夏休みの自由研究として作られた。

難易度を状態数で説明している。ルービックキューブの状態は約 4.3×10^19 通り。完成状態から最低何手で到達できるかを depth とすると、depth 6 までの累計は約824万局面で表引きに近い形でも覚えられるが、depth 7 だけで約1億局面あり、そこから先は単純な丸暗記では厳しくなる。

God's Number は20で、どれほど崩れた局面でも最短20手以内で必ず完成できる。ただし実験で使う d は厳密な最短距離ではなく、完成状態からランダムに回した回数であり、d=30 は最短30手という意味ではないと注記されている。

Web エンジニアがモバイルアプリを開発する現場で、Web の React + Tailwind の知見をそのまま応用するために React Native + NativeWind を採用した。ところが「className を指定したのに効かない」「Web の感覚で書いたら見た目だけ崩れた」「lint エラーにもならない」というケースに何度も遭遇したという。

検証環境は nativewind 5.0.0-preview.2、react-native-css 3.0.7、tailwindcss 4.2.2、react-native 0.83(New Architecture / Fabric)、Expo SDK 55。記事中の「実測」はこの構成の最小プロジェクトを iOS シミュレータと Android エミュレータで確認した結果で、検証用リポジトリも公開されている。

ハマりどころの根本原因として、React Native に CSS エンジンはないという前提を最初に置いている。スタイルはすべて JavaScript オブジェクトとして style prop に渡り、レイアウトは Yoga、描画は各OSのネイティブ実装が担う。

QAエンジニアとして「社内ナレッジをAIに読ませて、QAのテスト設計を任せてみた話」で登壇した参加記。午前の基調講演と自分の登壇、その直後の1枠までしか聞けていないため、その範囲で刺さった論点を3つに絞っている。

午前のオープニングにあったXPの入門説明を、目標3つ(優れたソフトウェア開発を行う、必要なものを必要になったときに作る、優れたチームの共通点をパタン・ランゲージにしたもの)と、人間性・経済性・相互利益・改善・多様性・反省・フロー・冗長性・失敗・品質・小さなステップ・責任の受け入れという原則として整理している。

以前C言語で組み込みを書いていた頃、状態遷移表を書いてから実装し、小さく作って小さく確かめ、失敗を前提に冗長性を持たせていたやり方が、名前を知らなかっただけでXPと重なると気づいたと述べている。

IT業界を目指して勉強を始めると、できるだけ効率よくスキルを身につけたい、遠回りせず早く仕事で使えるようになりたい、と考えるのは自然だと著者は前置きする。同じことを何度も繰り返すより良いやり方を探したい、分からないことは早く解決したい——その感覚自体は悪くない。

採用担当として気になるのは、「効率よく学びたい」が「できれば自分で考えずに答えだけ知りたい」に変わってしまっているときだという。似ているようで違う、というのが記事の中心の主張である。

未経験だと、何から始めればいいのか、どの教材を使えばいいのか、どこまでできれば仕事として通用するのか、調べるほど情報が出てくる。その状況で最短ルートを知りたいと思うこと自体は普通だ、という留保も置いている。

大がかりな仕組みではない Claude Code の tips を4つ、気になったものだけ拾えばよいという形で紹介している。うち1つはツールの話。

1つ目はセッション名の自動付与。Claude Code のセッションには /rename で名前を付けられ、プロンプト入力欄の右下にチップとして表示される。複数セッションを並行して動かすとどれが何の話か分からなくなるため名前を付けるようになったが、毎回手で打つのが面倒だったという動機である。

前提として、Claude Code がセッションタイトルを2種類持つ点を整理している。ai-title は1往復目のあとに自動生成され、--resume の一覧、ターミナルのタイトル、/status などに出る。custom-title は /rename やフックで明示的に設定し、それらに加えてチップにも出る。

本番環境で、メールのマジックリンクを押すと「この認証リンクは使用済みまたは期限切れです」と表示されログインできない、という報告が入った。利用者からはリンクを押すと一瞬 Cisco のリンクが開くという証言もあった。

原因は、利用者側で導入されているメールセキュリティ製品 Cisco Secure Email の URL 解析機能が、利用者より先にリンクを開いて1回しか使えないトークンを使い切っていたことだった。検証環境は Next.js 15.5.23(App Router)、better-auth 1.6.30、Node.js 22、インフラは AWS(CloudFront + ALB + ECS)。

この問題はマジックリンクに限らない。パスワードリセット、招待メール、退会確認など、メールのリンクを開いたら状態が変わる機能はすべて同じ構造を持つと指摘している。

激重な Docker 環境の原因を一つずつ潰していった経験をもとに、ローカル(Windows)の Docker 環境を軽量化する方法を手順つきで紹介している。リソース削除や named volume の移行など、確認やバックアップを省くとローカル環境に影響が出る操作も含まれると注意を置いている。

.dockerignore、マルチステージビルド、ベースイメージの軽量化、ビルドキャッシュの活用は、主にビルド・pull・コンテナ再作成・起動時間の改善に効くもので、稼働中のページレスポンスを直接速くする対策ではないと明記されている。

最初の手順は不要リソースの掃除。docker system df で RECLAIMABLE 列を確認し、docker ps -a / docker images / docker volume ls で削除対象を確かめたうえで docker system prune を実行する流れになっている。

AWSの個々のサービスは知っているが全体構成のイメージが掴めない読者を対象に、各サービスが何をしているかを説明できるようになること、パブリックサブネットとプライベートサブネットの使い分けを理解することを目標に置いている。

実務のAWSインフラを、インターネットからのリクエストを受け付けるパブリックサブネットと、外から直接触れさせないプライベートサブネットに大別する。ALB がリクエストを受け取ってプライベートサブネット内の ECS タスクへ転送し、ECS や Lambda のアウトバウンド通信は NAT Gateway を経由する、という構成を示している。

紹介する構成はあくまで一例で、システム要件・規模・コスト・セキュリティポリシーによって最適な構成は異なると注記されている。

AI関連ニュースは量が多く、一次情報の新鮮さでは公式アカウントの発表や開発者本人の反応が流れる X が強い。とはいえ毎日海外テックメディアを何本も読む時間もタイムラインを1件ずつ追う余裕もない、という前提から、Grok に X を検索させて重要な技術ニュースだけを抽出する運用を紹介している。実際に使っているプロンプトも公開されている。

ChatGPT や Gemini の Web検索は検索エンジンのインデックス経由であり、X の投稿はそもそも拾われにくく、インデックスまでにタイムラグがあり、リポスト数やいいね数といったエンゲージメント情報も基本的に取得できないと整理している。

Grok は xAI が開発しているという立場上、X の投稿にリアルタイムでアクセスできる。これが「検索」ではなく「アクセス」だという違いだとしている。