Anthropicが公式解説したClaudeのテキスト透かしがTechmemeとdev.toの首位に、Hacker NewsはAIとの働き方を巡る記事が上位を占めた

組み込み・低レベル分野で知られるDmitry Grinberg氏がRISC-Vの設計判断を批判した記事で、Hacker Newsでは289コメント、Lobstersでも78コメントと両サービスで議論が続いた。

賛同側からは、RISC-Vには拡張検出に関してベンダー間の重複を禁じる中央の権威がなく、対応拡張のビットマスクが問題になりがちだという補足や、新しい「光り物」に飛びつかず実際のシリコンが出るまで待って正解だったという声、基本的にMIPSの再来でどのISAでも力ずくでどの用途にも押し込めるという指摘があった。

一方で、RVA23対応ハードウェア(SpacemiT K3など)は既に存在するという反論、著者の議論は分かるがRISC-Vはx86より多くのことを改善しておりオープンなISAがある方が良いという意見、RISC-Vを叩き台にして弱点のないコミュニティ主導のRISC-6を作るべきだという提案も出た。

Chromium系ブラウザがManifest V2の拡張機能を打ち切ったことで、フル機能のuBlock Originが動く主要ブラウザはFirefoxだけになったと伝えるPCWorldの記事。Lobstersでは138ポイント・36コメントと本日最上位で、Hacker Newsでも先日話題になっていた。

コメントではuBlockはFirefox for Androidでも動くという補足や、母親にFirefoxとuBlock入りのノートPCを渡したら広告のない普段のサイトを見て驚いていたという体験談、これがFirefox採用の増加につながってほしいという声があった。MozillaがGoogleからの資金を失うリスクを心配する声に対し、新しいJSやCSS機能の量を考えると軽い保守だけでは機能的なブラウザを維持できないのではという懸念も出た。

そこから、プレーンHTML・コアCSS・限定JS・フル機能という「段階」でプログレッシブエンハンスメントを強制する手段がないことへの不満、派手なJS機能を無条件に良しとする信念は開発者にも広まっているという回想、NoScriptやuMatrixで最小限だけ有効化しているという実践、ネット版の排除アート(hostile architecture)だという比喩が続いた。

Dmitry Grinberg氏によるRISC-V批判記事のLobsters側スレッドで、78コメントと本日のLobstersで最も議論が長い。Hacker Newsでも同時に289コメントを集めている。

コメントでは、RISC-Vは数十年の経験を持つ学者と業界のベテランが設計しており著者より分かっていたはずで、モジュール性への不満こそRISC-Vを成立させている要素だという反発が最初に付いた。これに対し、権威に訴えるより説得的であるべきで、RISCの発明者たちは以前MIPSを作って消え、x86が消えると予測したのだという返答や、正当な批判が論点に答えられずに切り捨てられるのは悲しいという声が続いた。

著者が冒頭で「RISC-Vファンはすべてのスパコンとマイコンを制覇すると信じ込ませたがる」と出典なしに書いている点について、誰がそう言ったのかという指摘と、少し前まで自分もそう思っていたという告白があった。専門家委員会が作った標準がひどい出来になる例としてWS-*を挙げる声も出ている。

ActivityPubが「退屈」であること、つまり派手さより実装可能性を優先したことで分散SNSのプロトコルとして勝ち残ったと論じる記事。

コメントでは、ActivityPubのJSON-LD部分は退屈どころか正気を失いそうになるほどで、サーバーの実装はJSON-LDのせいで途方もなく難しく、次に難しいのが認証だという反論が並んだ。任意のプロパティが単一の値にも配列にもコレクションへのリンクにもなりうる点も挙げられ、JSON-LDはRDFグラフのシリアライズ形式として扱うべきだという意見もあった。

これに対し、大半の実装はJSON-LDの拡張性に関わる必要がなく、素のActivity Vocabularyオブジェクトを普通のJSONとして扱えば十分でエコシステムでも実際そうなっているという再反論があった。Fedify作者による「Why ActivityPub is hard」記事へのリンクも共有された。

暗号学者Matthew Green氏がブログA Few Thoughts on Cryptographic Engineeringで、誰もがLLMを使え、LLMが脆弱性の発見と修正の双方で人間より有効になれば、ソフトウェアはやがて攻略しにくい「暗い」状態に向かうという見立てを論じた記事。

コメントは逆の直感が目立つ。壊す方が直すより常に簡単で攻撃側が有利だという声、レッドチームは一つの脆弱性を見つければよいがブルーチームは一つのミスも許されず、しかもセキュリティに追加投資する動機がない組織も多いという指摘、ネットワーク技術の基盤はほぼすべてメモリ安全でない言語で書かれており、史上最も広範な侵害の時代に入るのではという懸念が並んだ。LLMでエクスプロイトを見つけているセキュリティ研究者からも、バグは尽きないという意見が出た。

双方が同じLLMにアクセスできれば欠陥はリリース前に修正され、より強いLLMを持つ者が勝つ構図に変わるという記事の前提に沿った意見や、脆弱性の発見と修正が主にLLM経由になるなら政府はモデルやその配信インフラにバックドアを仕込む方向に動くだろうという懸念も示された。

Thunderbirdの公式ブログが、デスクトップ版カレンダーの視覚的な再設計をデザインの旅路として紹介した記事。

コメントは2件で、仕事用MacBookのOutlookとほとんど同じに見えるという指摘と、現行Outlookには言いたいことが多いがカレンダーはかなり良い部類で多くの人が慣れてもいるので、そこから着想を得るのは理にかなうという返答が付いた。

C++開発者Elias Farhan氏による自作ゲームエンジン連載の第1回で、なぜカスタムエンジンを作るのか、それによって何が得られるかを論じている。

コメントでは、何かを得るためでなく単に楽しいから作ってもよく、「面白そうだから」で十分な理由のはずなのに行動を正当化する話ばかりになるのは残念だという意見があった。一方で失うものとして、ゲームエンジン全体を形作るのに最も面白くない構成要素であるアセットパイプラインに費やす時間を挙げ、ゲームループとレンダラを後付けできるオープンソースの汎用アセットパイプラインはないかという問いかけが出た。

これに対し、要件がゲームごとに固有で自作もそれほど大変ではないので共有や再利用の切迫感が薄いという返答と、アーティストなしの単純なアセットならそうだが、そうでなければテスト済み汎用エンジンがもたらす最大の技術的貢献はレンダリングエンジンに次いでアセットパイプラインだという再反論が続いた。

Fred Brooksの「銀の弾丸はない」を引き、コードを書く行為をAIツールに渡すと残るのは他人の推測を、もはや養われなくなったメンタルモデルに照らして監査する仕事だという主張の記事。Lobstersのvibecodingタグで16コメントが付いた。

コメントでは、Claudeの出力を読みすぎているせいかもしれないがこの記事の文体は妙に見覚えがあるという皮肉や、大規模で監督なしのLLMコードがどれほどひどくなるか知らない人向けに、その頃にはLLMが掃除してくれるだろうと化石燃料からの脱却になぞらえる皮肉があった。

「AIにコードを書かせて本質に集中する」という売り文句は対象者にとって正反対だという記事の主張に対し、完全な非プログラマーのチームメンバーがAIで自分の業務ツールを作れているのは何を意味するのかという問いがあり、誰かのワークフローを改善する機会の発見に我々が失敗してきた証拠だという返答と、それは個人ごとに異なる極めて固有のワークフローだという再反論、80〜90年代のエンドユーザープログラミングの約束がサイロ化の経済的動機で失われたという振り返りに広がった。

Claude Code・Codex・Pi向けのエージェントスキルとして、エディトリアル品質のダイアグラムを生成するリポジトリ。汎用の角丸ボックス図ではなく雑誌のような27の視覚タイプを自己完結したHTML+SVGで出力し、対象サイトを読んで60秒でブランドに合わせるという。2.3ではレイアウトと分離してふるまいを記述するセマンティックパターンとオプションのモーションが加わり、draw.ioやMermaidのソースを描き直す機能も持つ。

作者は自身のブログlittlemight.comとECのBestSelf.coの運営者で、アーキテクチャ図が必要になるたびにClaudeから汎用的な角丸ボックス図が返ってきて、Figmaと30分格闘するか図を諦めるかになっていた経験から作ったと説明する。

設計思想として「最も品質の高い一手はたいてい削除」を掲げ、アクセントカラーは読者が最初に見るべき1〜2箇所に限定し、目標密度は10段階中4とする。27の視覚タイプはミニマル・ライト、ミニマル・ダーク、フルエディトリアルの3つの静的バリアントで提供され、ビルドステップもJavaScriptも外部画像依存もなくブラウザで直接開ける。

「作る前に何を作るかを定義する」を掲げるGitHubのオープンソースツールキットで、任意のAIコーディングエージェントで使える仕様駆動プロセスをすぐ使える形で提供し、独自プロセスの持ち込みや拡張、組織全体での利用も想定する。累計129,197スターで、本日+892スターを加えた。

仕様駆動開発は従来の開発の台本をひっくり返すもので、数十年にわたりコードが王で仕様は本当の作業が始まれば捨てられる足場だったのに対し、仕様そのものを実行可能にして実装を導くだけでなく直接生成すると説明する。

導入はuvでSpecify CLIをGitHubのリリースタグ指定でインストールするか、PyPIのspecify-cliパッケージから行う。READMEにはサポートするAIコーディングエージェント統合、拡張とプリセット、ロール別セットアップのバンドル、コア哲学、開発フェーズ、実験的なゴールといった章が並ぶ。

Needle 2は、ツール呼び出し・デバイス操作・構造化抽出向けのオープンな45Mパラメータモデルで、モデル全体が単一の14MBバイナリに収まり、約28MBのRAMでフルセッションを実行する。Simple Attention Networkの知見に基づきCactus QuantsでCQ2ビットに圧縮したもので、ベンチマークではFunctionGemma 270M、LFM2.5 230M、Apple FMと勝ち負けを分け合いながら、サイズは5〜70倍小さくf16に対し2ビットだとする。

リポジトリはPythonパッケージ(推論・LoRAファインチューニング・エクスポート)で、pip install cactus-needleの後にツールを記述してPythonから呼べる。推論エンジンはHugging Faceから一度取得してキャッシュされ、エアギャップ環境向けのオフラインセットアップも文書化されている。

特徴として、推論はネットワークを使わないこと、スキーマからコンパイルしたバイト単位の文法がすべてのトークンを制約してJSONを返すこと、較正済み信頼度スコアで閾値以下ならエスカレーションできること、検索ヘッドが毎ターン上位5件のツールだけを提示すること、256トークンのスライディングウィンドウで会話が長くなってもメモリを約28MB付近に保つことを挙げる。

ego liteは、人間とAIエージェントが並行して作業することを前提に設計されたブラウザで、エージェントは自分のSpaceで複数のブラウザタスクを実行し、ユーザーのタブはユーザーのものとして残る。browser-useやagent-browserのような既存ツールは別のブラウザを操作するフレームワークでログインが引き継がれず同じタブを取り合いになるのに対し、ego liteは最初から2者で共有する1つのブラウザとして設計されていると説明する。

現在はmacOSのみで、WindowsとLinuxはロードマップにある。導入はmacOSアプリのダウンロード、npx skills add citrolabs/ego-liteでスキルだけを追加、あるいはエージェントにinstall.mdを読ませてセットアップさせるの3通り。初回起動でChromeデータを移行するか尋ね、承諾するとエージェントは既存のログイン・Cookie・拡張機能・ブックマークを引き継ぐ。

使い方はエージェントCLIで/ego-browserに続けて自然言語で指示するだけで、エージェントは自分のSpaceでページを開き、Snapshotを読んで操作し、結果を報告する。

ToolJetは、内部ツール・ワークフロー・AIエージェントを構築・デプロイするAIネイティブなプラットフォームToolJet AIのオープンソース基盤で、コミュニティ版はビジュアルビルダー、ドラッグ&ドロップUI、データベース・API・SaaS・オブジェクトストレージとの連携を提供する。AIによるUI生成、クエリ構築、デバッグやエンタープライズ機能はToolJet AI側にある。

コミュニティ版の機能として、テーブル・チャート・フォーム・リストなど60以上のレスポンシブコンポーネントを持つビジュアルアプリビルダー、組み込みのノーコードデータベースToolJet Database、マルチページアプリとマルチプレイヤー編集、80以上のデータソース接続を挙げる。ライセンスはAGPLで、累計39,537スターに本日544スターを加えた。

Unslothは「モデルの実行と学習ができる最初のデスクトップアプリ」を名乗り、Windows・macOS・Linux(deb/AppImage/Arm64)向けのネイティブアプリを配布する。手動インストールはmacOS/Linux/WSLがcurlのインストールスクリプト、WindowsがPowerShellのスクリプトで行う。

機能として、Kimi K3、MiniMax-H3、Qwen3.8、Muse Glimmer、DeepSeek-V4、Gemma 4などのLLM・拡散・埋め込み・音声モデルの実行と学習、ローカルモデルをClaude Code・Codex・MCPからツール呼び出しやコード実行込みで使うエージェント連携、プライベートで無制限のWeb検索・ディープリサーチ・RAG、画像・動画拡散モデルの実行と学習を挙げる。ハードウェアはCPU、NVIDIA、AMD、Intel、macOS、マルチGPUに対応し、Cloudflare経由でローカルモデルにリモートアクセスする手順も文書化されている。

holeheは、メールアドレスがTwitter・Instagram・Imgurなど120以上のサイトのアカウントに紐付いているかを効率的に調べるOSINTツール。パスワード忘れ機能を使って情報を取得し、対象のメールアドレスに通知が行かないことを特徴として挙げる。Python 3で動き、オンライン版としてosint.industriesが案内されている。

インストールはpip3 install holehe、GitHubからのclone、Dockerの3通りで、CLIならholehe test@gmail.comのように実行する。Pythonからはtrioとhttpxを使い、モジュール(例としてsnapchat)を非同期で呼び出して結果リストを受け取る。各モジュールの出力はname、rateLimit、exists、emailrecoveryなどのキーを持つ標準的な辞書形式で返る。

インタラクティブな世界モデルには永続メモリ・応答性・長期生成が求められるが、履歴をデノイザのコンテキストやKVキャッシュに保持するとコストが増え続け、低レイテンシに必要な少ステップ生成は教師の能力に縛られるという課題を指摘する。Evokeは永続的な世界状態を外部化し、長期インタラクティブ生成向けに教師を再設計することで両方に対処する。

シーンの幾何はカメラでインデックスした外部の世界状態バンクに保持し、視点に関係する情報だけを取り出すことでデノイザのコンテキストを有界に保つ。教師はチャンク単位のグルーピング、遠方フレームの検索、線形アテンションのグローバル状態を組み合わせたスパースアテンションでメモリと計算を線形に抑え、長期の教師信号を可能にする。チャンクごとの条件付けで系列全体を通じたプロンプト変更やイベント制御もできる。

自己強制ロールアウト下で30秒の分布マッチング目的関数を適用し、classifier-free guidanceを使わない3ステップの生徒に両能力を転移させた。単一のH200上で384×640の各1.5秒チャンクを2.11秒で生成し、3ステップ世界モデルとしてWBenchで最高性能、VBench-LongとVBench-2.0でも競争力を保つ。

すべてのクエリと予算制約に最適な単一のLLMは存在せず、コスト効率の良いデプロイにはモデルルーティングが不可欠だが、既存のルーターは定式化も実装もばらばらで公平な比較や拡張が難しいという問題意識から、LLMルーティングをコンテキストエンコーダ、モデルエンコーダ、スコア関数、決定ルール、学習信号の5要素で特徴付けられる逐次決定過程として統一的に定式化する。単一ターン、複数ターン、パーソナライズドルーティングを網羅する。

この定式化に基づき、ルーティングの教師信号を構築し、応答品質と推論コストの両面でルーターを評価する自動パイプラインを開発した。得られたベンチマークxRouteBenchは汎用LLM、メモリ拡張、ビジョン、時系列、パーソナライズドの各ルーティングタスクにまたがり、さらに16以上の代表的ルーターを備えたオープンソースのモジュール式基盤LLMRouterを公開する。

実験では、学習型ルーターが最強の固定モデルベースラインを相対14.6%上回り、厳しいコスト制約下では軽量ルーターの競争力が高まり、ユーザー条件付きルーティングは一貫してパーソナライゼーションを改善した。

DreamX-Phi 1.0は、観測フレーム、言語指示、エンドエフェクタ姿勢とグリッパ状態からなる行動系列を与えると、その結果生じる将来の観測を予測する、ロボットマニピュレーション向けの行動条件付き動画世界モデル。リアルさだけでは忠実性は保証されず、説得力のあるロールアウトでも間違ったアームを動かしたり操作対象を見失ったりしうると指摘する。

各アームの指令された経路を予測が守るよう、アームごとのSE(3)変換をPRoPE式の幾何エンコーディングでアテンションに注入し、アームの同一性と剛体運動の構造を保つ。行動制御だけではシーンの幾何や小さな操作対象の変化を十分に拘束できないため、軽量な深度ブランチを加え、SAM3のマスクと凍結したV-JEPA教師で把持中の物体の一貫性を維持する。

さらに多ステップの生成器を分布マッチング蒸留で少ステップの生徒に蒸留し、効率的なデプロイを可能にした。執筆時点でWorldArena 2.0 ChallengeのTrack 1で1位、Track 2で2位を獲得しており、モデルとコードは公開予定としている。

LLMエージェントの能力はモデルの重みだけでなく、プロンプト・ツール・スキル・制御フローからなるハーネスに依存する。既存の自己改善ループは単一系統の探索で経路依存になりがちだとして、DarwinXはモデルを凍結したままハーネスの集団に対する選択として自己進化を扱う。カバレッジを退行なく広げる変種だけを受け入れるpreserve-and-extend契約、再結合のために別系統を保持するアーカイブを持ち、適応度は各ベンチマーク自身の検証器から得て正解や手選びの勝者を用いない。

4つのベンチマークで1ループあたり平均約17ポイント向上した。Terminal-Bench 2.1は同一ベースで+7.7の83.2%、より強いベースでは84.7%に達し、TerminalWorldのホールドアウト分割は68.3%で既製のあらゆるエージェントを上回り、WebArena-Infinityの実タスクpass@1は43.5%から93.0%に上昇し、Terminal-Bench 2.1用のハーネスは変更なしでSWE-bench Verifiedに転移した。

進化するのはベンチマーク特化のパッチではなく一般的なエージェント能力であり、凍結したモデルが固定されたエージェントである必要はなく、ハーネス選択は評価計算を持続的な能力に変えると結論づける。

LLMが科学的評価に参加する機会が増える中、科学的内容を保ったまま修辞的な選択がAI査読の判断をどう変えるか、という報酬ハッキングの一形態を調べた研究。匿名化したICLR 2026投稿120本から派生させた4,200本の全文原稿を構築し、2つのLLM書き換え器で6つの修辞次元を相反する方向に変換し、5つのLLM査読者が標準および厳格プロトコルで評価した。

修辞的感受性は一様ではなく構造化されており、証拠の提示枠組みと新規性の主張が総合評価で最大の正負差を生み、スコープの提示がそれに次ぐ弱い第2層だった。評点の動きはAI査読者の元の評点に強く依存し、低い評点は上がり高い評点は下がる傾向があり、方向性の対比は中間帯で最も明瞭だった。

より手の込んだワークフローが確実に大きな効果を生むわけではなく、査読者の誘導は誘導なしの2回目を一貫して上回らず、反復書き換えの効果は逓減した。書き換え器が主に変種間の分離を決め、査読者が評点効果の大きさと符号を決める。厳格査読は平均総合評価を1.36ポイント下げるが修辞的感受性を一貫して変えなかった。

マルチモーダルな情報源を凝縮された構造化メディアへ変換する作業を、モデルとハーネスからなるシステムを中心とした長期のエージェント過程として捉え、経験を蓄積して再帰的に自己改善する理想のハーネスに対し既存の枠組みは静的だと指摘する。AutoDesignはメタハーネス最適化器がロールアウトのフィードバックに基づきコードエージェントにハーネスを再帰的に改善させる枠組みである。

評価のために学術論文からポスターを生成するタスクに焦点を当て、5分野100本の論文からなるMain Trackと10本のPosterBench-miniで構成されるPosterBenchを導入した。Main TrackでAutoDesignは最高の78.32点を記録し、クローズドソースの商用システムClaude Designを7.45点上回った。

7つの統制されたコードエージェントとモデルの構成すべてで、学習済みDesignHarnessの統合が性能を一貫して改善し、平均スコアは54.99から67.39(+12.4%)に上がった。完全自律の長期ループでは253回のツール呼び出しと11回の編集ターンを40分以内・3ドル未満で実行し、人間評価で平均的な学会ポスターの品質に到達した。

動画世界モデルは現在の観測とユーザーの行動を条件に将来の状態をシミュレートし、近年は長い系列でも一貫性と行動制御性を示しているが、インタラクティブなモデル同士の公平な比較は難しいままだとする。人間は360度振り返って環境が一貫しているか、水に入って波紋が出るかといった長期目標を追って評価するが、同じ目標に必要な行動系列はモデル間で大きく異なるため、固定の行動条件付き評価はモデル横断の比較に向かない。

そこでマルチモーダルなエージェントプレイヤーに指定の長期目標へ向けて世界モデルと相互作用させるパラダイムを採り、目標付きの171シナリオを備えるベンチマークPlayWorldを導入した。評価軸は幾何の一貫性、インタラクションの忠実度、視界外の変化、洞察の変化の4つの中核次元に、動画品質と制御性の基本能力指標を加える。

9つの最先端世界モデルでの実験から、現在のモデルは長期のインタラクティブな目標では、特に空間の一貫性と持続的な状態変化の維持において依然として信頼できないことが明らかになった。コードとデータはGitHubのkxding/PlayWorldで公開されている。

VLMエージェントの空間推論を高める既存研究は、SFTや強化学習によるポストトレーニングと、深度推定や3D再構成などの外部ツールを呼ぶエージェント型の2系統だった。本研究は補完的な道として、凍結したVLMエージェントが推論時に外部の専門空間ツールに頼らず、パラメータ更新なしの自己進化で空間推論を改善できるかを問う。

提案するSpatial Memory Agent (SMA)は、検証可能な空間環境で凍結VLMに問い合わせて予測と報酬を得て、検証器に導かれた省察でコンパクトで転移可能な教訓を蒸留する経験接地型のランタイム枠組み。各教訓には転移信頼度スコア(TRS)を付与し、後続の検索結果から較正する。デプロイ時には意味フィルタと類似度・TRSの組み合わせ順位で教訓を検索し、凍結モデルの推論を導く。

5つの代表的な空間ベンチマークと4つのベースVLMにわたり、SMAはすべてのベースモデル区分でマクロ平均最高を達成し、20の評価の大半で最高精度を示し、空間的自己進化へのパラメータ更新不要な実用的経路を確立したとする。

層をインターリーブしたハイブリッド線形アテンション(HLA)LLMにおける巨大活性化(MA)の初の体系的研究で、2つの形態を明らかにした。MAはフルアテンション層の直前で一貫してスパイクしてアテンション前スパイク(PAS)を形成し、間に挟まる線形アテンション層を通じて持続してスパイク間プラトー(ISP)を生じる。フルアテンションが密になるほど連続するPASはISPで結ばれ、最終的にフルアテンションLLMの安定したMA形態を回復する。

この構成の再現性を、5つの線形アテンション構造、6つのハイブリッド化構成、5つのデータ領域、1.2Bから397Bに及ぶオープンソースハイブリッドモデルで確立した。最大1.3B規模のGDNベースのハイブリッドの事前学習では、両形態が早期に現れ、フルアテンションの出力ゲーティングは層ごとの構成を消さずに絶対値を強く減衰させる一方、GDNゲートの除去は控えめな増幅しか生まなかった。

機構的には、系統的外れ値の分析がMA消去のタイミングに支配される共通のライフサイクル説明を支持し、PASは局所的な書き込み・シンク・消去の過程に従い、ISPの持続は遅延した消去と整合する。コードはGitHubで公開されている。

トーキング動画のキャラクター置換には、元の動き・シーン・言語内容・音声と映像のタイミングを保ったまま見た目と声を協調して転写する必要があるが、既存手法は2つのモダリティに別々に最適化したモデルを使うため一貫性を担保しにくい。UniSwapは、元動画・参照画像・参照音声クリップから、単一の音声・映像拡散トランスフォーマー内で参照の見た目と声質を転写する初のストリーミング枠組みである。

整列済み学習ペアの不足に対し、実クリップから視覚的・音声的アイデンティティを取り除き元クリップを再構成目標に使うswap-and-reconstructパイプラインを導入した。双方向バックボーンから出発し、In-context Pretraining、ブロック因果的なKVキャッシュ生成のためのConditional Streaming Adaptation、ブロックあたりのデノイズを30ステップから3ステップに減らすEfficient Self-forcing DMDで段階的に適応させる。

Efficient Multi-LoRA Switchingにより3つのDMDの役割が単一の凍結バックボーンを共有し、Feature-RoPE Decompositionで安定した長尺推論を支える。実験では強い音声・映像同期、競争力あるアイデンティティ保持、効率的なストリーミング、安定した長尺生成を示した。

2026年8月にAnthropicがEU AI Act第50条の透明性規範に署名し、8月2日以降のモデルではEU圏内に限らず世界中でテキストに透かしを入れると発表したのを受け、テキストウォーターマーキングの研究史を整理した記事。投稿後にAnthropic公式ブログの解説が出たため一部加筆されている。筆者は2023年に「実用化は無理だろう」と感じたアイデアが、GoogleのSynthID-Textに続きAnthropicでも動いている点に着目する。

基本の考え方は、LLMが次のトークンを選ぶときの揺らぎを秘密鍵由来のルールでわずかに偏らせ、数百トークン分の偏りを統計的に検出するというもの。出発点の2023年KGW法は語彙をグリーンリストとレッドリストに二分してロジットにボーナスを加え、検出側はグリーンリスト語の比率をz検定で判定する。

品質劣化の課題には、サンプリングの乱数を秘密鍵由来の疑似乱数に差し替えるGumbel-Maxトリック系のdistortion-freeな手法が登場し、生成分布を一切変えずに透かしを入れられるようになった。低エントロピーなコードや事実記述で歪みが表面化しやすいというKGW法の弱点にも触れる。

Cloudflare Workers、Supabase、Polar、Gemini API、Sentry、AdSense、GitHub、独自ドメインで構成した小規模Webサービスを実際に終了した筆者による、終了方針の決定から完全撤去までの記録。便利なSaaSは導入5分だが解約はそれぞれ別の管理画面に行く必要があり、「閉店作業」という巨大なバックログが最後に突然出現すると述べる。

最初にやるべきはコードを書くことではなく終了方針を決めることで、最終終了日、新規登録と購入を止める日、購入済みコンテンツの扱い、ユーザーデータの削除期限、決済履歴やソースコードの扱いを決めて初めて「消す・残す・終了日までは必要」の判断ができるとする。今回は新規登録・購入を先に停止し、終了日までは閲覧のみ許可、本番データのバックアップは残さない方針を採った。

終了は電源を落として終わりではなく、新しい利用を止める、読み取り専用で維持する、完全停止して撤去するという3段階の撤退戦として進めた。閉店との違いは、閉店後もWebhookが何度もノックしてくる点だと書いている。

Claude Codeを使っていて最も消耗するのは「先週も言ったことを今日も言っている」ことだという筆者が、指摘そのものをファイルとして永続化し、指摘回数に応じてhookの強制力を段階的に上げる仕組みを作った記事。CLAUDE.mdに書いてもセッションが長くなると効き目が薄れ、何回言ったかも残らないという問題意識から始まる。

ルールは~/.claude/feedback/<topic>.mdに1指摘1ファイルで置き、frontmatterのcountに指摘回数、enforceにhookが機械的に検知する条件(実装ファイルにテストファイルが隣接していなければ止める等)を書く。本文にはWhyとHow to applyに加えて「言い訳」欄を設け、「今回は特別」という理屈をあらかじめ潰しておく。現在47ルールがあり、うち14個がhookで検知できる。

すべてをいきなりdenyにすると誤検知で作業不能になるため、countからseverityを自動決定し、1回目はwarn、3回以上でask(stop_checkではblock)、5回以上でdenyに上げる。ルール同士はObsidian風のリンクで繋いでいる。

Cloudflare OSについて3本書いた筆者が、その根底にある「Cloudflareという会社そのものの設計思想」を4本目として書いた記事。結論はCloudflareがやっているのは「トラフィックの通り道に自分が立って全部処理する」という一点だけで、CDN・DNS・WAF・Workers・Zero Trust・Cloudflare OSはすべてそこから導出できるとし、公式のOur Storyなど一次ソースで確認する。

起点は2004年のProject Honey Potで、スパマーのメールアドレス収集を追跡する仕組みだったが、ユーザーからは「追跡はいいから止めてくれ」という要望が繰り返し来た。止めるには通り道に立つしかなく、その瞬間にアーキテクチャは「間に入る」一択になった。社名も「クラウド上のファイアウォール」から来ている。

創業時に投資家から来た最大の懸念は「間に挟まればレイテンシが増える」だったが、チームはレイテンシ撲滅に取り憑かれ、2010年のプライベートベータでは読み込みが平均30%速くなったという声が返ってきた。CDNは後付けの結果で順序が逆だったと筆者は強調する。

イベント管理サービス「イベット」をNext.js 16 (App Router) + Cloudflare Workers (OpenNextでビルド) + Turso + Drizzle ORM + Better Auth + R2 + Durable Objects + KVで構築し本番運用している筆者が、踏んだ罠を対処法つきで書いた記事。月額コストはWorkers Paidの$5とドメイン代だけで、それ以外は無料枠に収まっている。

Workers Paidが必須な理由として、OpenNextでビルドしたworkerがgzip後3.6MBで無料プランの上限3MBを超えること、無料プランのCPU 10ms制限にNext.jsのSSRが収まらないこと、Durable Objectsを使うことの3点を挙げる。D1を採用しなかったのは10GB制限のためという。

罠1はnext/imageとnext/linkが使えないことで、ESLintのno-restricted-importsで両者のimportを禁止して機械に守らせる。罠2はWorkersにTCPの永続接続がないためSQL 1文がHTTPS 1往復になること。Cloudflare自身が出したvinextも安定すれば本命になりそうだとウォッチしている。

人によって「AI」という言葉が指すものが変わってきていると感じた筆者が、マジックワードではなく仕組みとして理解するために調べた備忘録。AI(総称)、モデル(学習で作られた計算エンジン)、LLM(言語特化のモデル)、アプリケーション(LLMを制御するソフトウェア。Claude Code、Kiro、Cursor)、MCP(通信プロトコル)、MCPサーバー(機能を提供するプログラム)の順に定義する。

LLMがやっているのは次に来る確率が最も高いトークンを予測し続けることだけで、ファイルを書き換えたりコマンドを実行したりするのは上に被せたアプリケーション側だと整理する。KiroでClaude Opusを選べるのはモデルを選んでいるだけで、活用しているのはアプリケーション側だったと述べる。

量の言葉は、トークンをデータ量の単位、コンテキストを机に広げている資料、コンテキストウィンドウを作業机の広さ、メモリをストレージに例える。1回のリクエストにはツール定義、システムプロンプト、会話履歴、参照したファイルの中身が積まれ、自分がタイプしたのは最後の1行だけだと示し、MCPサーバーを繋ぐだけでコンテキストが減るのはツール定義が常駐するためと説明する。

ログラスの松岡氏が提唱するSUDOモデリング(システム関連図・ユースケース図・ドメインモデル図・オブジェクト図)を5年ほど使ってきた筆者が、ドメインモデル図とオブジェクト図の運用の課題と、TypeScriptの型とStorybook風のWebUIで解決する試みを書いた記事。

課題は3つ。Markdown+Mermaidやdraw.ioの図は実装の変更が反映されず古くなり、一度「最新じゃないかも」と思われた瞬間に参照されなくなること。オブジェクト図は具体例のパターン数が勝負なのにdraw.ioで1パターン描くのが面倒で代表的な1〜2パターンで満足してしまうこと。GUIで描いた図はAIコーディングエージェントからの読み書きと相性が悪いこと。

そこでドメインモデル図をコンポーネント本体(型定義から導出される抽象)、オブジェクト図をStory(具体的な値を流し込んだパターン)に対応させ、コードで記述したモデリングをWebUIでレンダリングするNode packageを作った。静的ページを生成でき、サイドバーに集約ごとの一覧、中央にドメインモデル図とオブジェクト図が並ぶ。

estieのデザインエンジニアである筆者が、同じRust製のBiomeとOxlintをほぼ同じ条件で比較した記事。担当プロダクト(TS/TSX約800ファイル)で、ルール構成を対応させた通常lintはBiome 2.5.3が0.78秒、Oxlint 1.77が0.16秒で約4.9倍、盛り盛り設定同士でも約4.7倍Oxlintが速かった。一方、同じ6ルールの型認識lintは0.38秒対5.98秒でBiomeが約16倍速いという逆転が起きた。

理由の1つ目はBiomeの方が解析範囲が広いことで、Biome v2はプロジェクトスキャナを持ち、循環import検出に加えCSSクラス×JSXの未使用検出のような言語を跨ぐ解析やCSS・JSONのlintまで行う。このスキャナはopt-inで、公式ブログ自身が「遅さという荷物がついてくる」と書いている。

Oxlintは複数ファイル解析をJS/TSのimportグラフに限定しCSSも見ないため、見る範囲が狭いぶん速い。oxc公式ベンチマークでの差は2.5〜3.3倍で、筆者の計測値が大きく出たのは対象コードベースとルール構成の違いによるとしている。

「パスキーでログイン」が増える中、「結局指紋データがサーバーに送られているだけではないのか」という疑いに答えるところから始まる解説記事。パスワードはユーザーとサーバーが同じ文字列を知っている「共有された秘密」であり、偽サイトへ送ればそのまま攻撃者に渡り、サーバー側からも漏洩しうるという前提そのものに無理があるとする。

パスキーの核心は公開鍵暗号方式で秘密鍵をサーバーに一切送らない設計にある。登録時にデバイスが鍵ペアを生成してサーバーには公開鍵だけを送り、秘密鍵は暗号化同期される(synced passkey)か、ハードウェアキーから物理的に出ない(device-bound passkey)。ログイン時はチャレンジに秘密鍵で署名して返すだけで、指紋や顔認証はデバイスのロック解除手段にすぎず生体情報はサーバーに送られない。ブラウザとOSが登録時のドメインと照合するため偽サイトでは署名処理自体が始まらない。

サーバーが漏洩しても漏れるのは公開鍵だけで、攻撃者が欲しい秘密鍵はサーバーを一度も経由していないため、奪える対象そのものが違うと述べる。ただし「盗まれても意味がない」はログイン先サービス(RP)のサーバーが漏洩した場合の話であり、無条件に成立する主張ではないと範囲を限定している。

前回の「Web API設計の現在地 2026」で最も大きく変わった領域として挙げたエラーレスポンスを深掘りする記事。設計はRFC 9457 (Problem Details)のボディ形式の話になりがちだが、ステータスコード・ヘッダー・ボディの3層すべてに仕様とデファクトがあり、1層でも欠けると監視やリトライやフォームのエラー表示のどこかが壊れるとする。

3層の分担として、ステータスコードはエラーの分類とリトライ可否・キャッシュ可否を監視・CDN・HTTPクライアントに伝え(正典はRFC 9110、429のみRFC 6585)、ヘッダーはいつ再試行するかの付帯情報、ボディは具体的に何が起きたかをアプリケーションコードに伝える(RFC 9457)。この分担を理解すれば「エラーを200で返してはいけない」「エラーコードとステータスコードは別物」が同じ原理の言い換えだと分かると述べる。

第1層では、RFC 2616や7231がRFC 9110 (2022年)に統合されたことを確認し、400番台(再送しても変わらない)と500番台(時間を置けば成功するかもしれない)の区別がリトライ規約の基礎になるとした上で、400・401(未認証)・403(認証済みだが権限なし)・404・405などの意味を一覧にしている。

隣の若手エンジニアがエラーをコピーしてAIに貼り、返ってきたコードを貼り直して次へ進む動作を3秒×数往復でこなし、エラーメッセージを一度も読んでいなかったのを見た筆者が、その日の午後に自分も見慣れないエラーを自力で読めなくなっていたと気づいた話から始まる記事。マネージャーとして評価面談で語れるのが「印象」だけになっている違和感も述べる。

AIは開発を速くする一方で、個人はなぜ壊れなぜ直ったかが分からないまま次も同じ場所で詰まり、納期の前では学習より解決が優先されるため個人の意志では解けないとする。組織側にはメンバーの実力が見えない、育成が属人化する、評価の根拠が主観に寄るという3つの形で跳ね返る。

そこで作ったのがSocraMetryというWebサービスで、エラーを投げると答えの代わりに「問い」が返ってくるAIメンター。AIは内部で原因を特定した上で言わず、画面はチャットに見えるが自由に質問する欄はない。記事への反響として経営層・マネージャー・エンジニアから同じ課題感が多く寄せられ、開発以外のユースケースも考えていくと追記されている。

フロントエンド開発で「押したくなるボタンにしたい」「直感的に操作できるようにしたい」というときに使えるCSSアニメーションを、筆者がこれまで使ってきたものから知識の整理を兼ねてまとめた記事。対象はHTML/CSSの基礎を学び実務に生かしたい人やtransition・transformの使い方を学びたい人で、前提知識は:hoverの基本まで。

前半ではよく使うプロパティとしてtransitionとtransformを解説する。transitionはCSSの値が変化するときに指定した時間をかけて徐々に変化させるプロパティで、ボタンのホバー時に色がじんわり変わる例をtransitionあり・なしのCodePen比較で示す。

後半はアニメーション集で、ボタンでは下線が左から右へ伸びる、丸型ボタンの拡大、色が左から右へ変化する、背景グラデーションの変化の4種、カードでは枠線と影による立体感、下線が右から左へ伸びながらカードが浮き上がる、画像がモノトーンからカラーに変化するの3種を、HTMLとCSSのサンプルコード付きで並べている。

生成AIを業務に入れた組織で、同じ質問なのに部署ごとに違う数字が返ってくる現象の正体を解きほぐし、2025年頃から主要ベンダーが揃って使い始めた「オントロジー」が何を指すのかを整理する記事。RDF・OWL・SPARQLといった構文には踏み込まず、なぜ今この言葉が戻ってきたか、業務のどこで効くか、誰が書くかを扱う。

例として、営業チームがcrmスキーマで最終接触日を基準に「先月のアクティブ顧客数」を聞くと820、経理チームがbillingスキーマで入金日と金額を基準に聞くと394が返るケースを示す。生成されたSQLはどちらも正しく動いており、違っていたのは「アクティブ顧客」が指すもので、それはどこにも書かれていなかった。モデルをより賢いものに替えても食い違いは直らないと強調する。

要点は3つで、部署ごとに違う数字はAIの精度の問題ではなく言葉の意味を誰も書いていないだけであること、言葉の意味を書き出す発想は20年前からあり、AIが下書きを書けるようになったことで戻ってきたこと、製品を導入すれば解決する話ではなく何をどう定義するかは業務側にしか決められないことを挙げる。

AIとの往復のなかで成果物までのリードタイムをいちばん縮めるのは、一度のやり取りで整えずにとにかくたくさん吐き出して渡すことだという仮説を述べる記事。整えるのはAIの仕事なので人は文章をきれいにするのをやめ、頭にあることを大量に、かつ速く吐き出すことに集中すればよいとする。

1ターンを、人が担う言語化・発散・検品と方向づけ、AIが担う整形・構造化・文脈との統合・1ピースの生成に分解し、整えなくていいのは整形と統合をAIが引き受けるからだと整理する。きっかけは社内でAI活用がうまい人との差で、人づてに聞いた答えが「一回の入力がとにかく速いし量がすごい」で、その人は音声入力で思いついたことを大量に喋って一度に渡していたという。彼らが10ターンで終わらせることに自分は100ターンかけているのかもしれないと考えた。

音声入力を試した当初は誤変換を心配してAIに整形させるプロンプトを毎回かませていたが面倒で、思い切ってそのまま渡してみると誤変換交じりの雑な入力でも普通に汲み取ってくれたと述べる。

承認されていないAIを従業員が業務で使う「シャドーAI」について、未承認サービスを見つけて遮断するだけではAI利用が見えない場所へ移るだけだとし、IT技術者が作るべきは禁止リストではなく、誰がどの機能をどのデータに対しどの責任で使えるかという運用の仕組みだと述べる記事。現場が未承認AIを使うのは公式環境で必要な機能が使えない、申請が遅いといった事情があり、シャドーAIは責任分担が未設計であることの表れだとする。

利用の置き場所を全社AI(IT部門・セキュリティ部門が責任を持ちSSO・監査ログを統制)、部門AI(利用部門とIT部門で分担し業務責任者・廃止手順を文書化)、個人AI(目的・期間・データ範囲を限定しいつでも停止可能な構成)の3つに分け、作成者が異動・退職した時の所有権の引き継ぎも必須項目とする。

さらに製品名ではなくAIが何をできるかで判定するとして、要約・翻訳などの補助(1)、汎用チャットやコーディング支援(2)、ノーコードAI・RAG(3)、Computer Use・メール送信・ファイル更新(4)、AI開発基盤(5)の5レベルに整理し、レベル4以上はチャットAIの延長として扱ってはいけないと述べる。NISTのGenerative AI ProfileやOWASPのAgentic Applications向けTop 10にも言及する。