文章を生成せず判断だけを返すJevの解説がZennとQiitaの上位を占め続ける一方、Hacker Newsには同型のモデルを1年前に作っていたとする投稿が入り1,327ポイントに次ぐ1,053ポイントを集めた

投稿は、Android 17がAndroid 3.x以来初めて、新しいAPIをAOSPに出さないまま追加したとしている。

コメントでは、スマートフォンOSが複占状態にある以上、デスクトップのLinuxディストリビューションのような選択肢が要るという意見や、GrapheneOSへの移行を検討しているという報告が出ている。ソースパッチの上流への反映が遅いこと、エンバーゴ、attestationの扱いなど、Googleが障害を増やしているという批判も並ぶ。

一方で、続報の投稿を読むと問題は新APIがPixel専用であることではなく、年4回の四半期リリースのうち第1・第3四半期分がPixel専用になっている点ではないか、という整理も出ている。AOSPにGoogle以外の貢献があるのか、Googleは実際にパッチを受け入れているのか、という疑問も挙がっている。

Quick Tunnelsは、アカウントを作らずにローカルで動かしているものを一時的に外部へ公開できる仕組みで、コメントでも認証が要らない点が確認されている。

コメントでは、既存のトンネルの周りに同じような仕組みを1週間かけて自作したばかりだという報告や、Tailscaleの同種の機能との比較が出ている。一方で、利用規約が気に入らないという声、通常30〜50msで届く経路が115ms〜750msになるなど遅延のばらつきが大きいという経験、大量のトラフィックを1社のシステムに通すことへの警戒も並ぶ。

この手の無料プロキシは詐欺などの悪用でブラックリスト入りして使えなくなるのではないかという懸念や、自分のマシンから配信すれば足りる用途ではCloudflareの他サービスを食うのではないかという指摘もある。

記事の主張は、LLMに書かせるのではなく校閲者として使うこと、モデルの校正案をすべて受け入れないことに置かれている。推敲の過程が声を形づくっており、それを手放すと読み手は理由を言えないまま違和感を覚える、という説明になっている。

コメントでは、自分の文章に繰り返し出る言い回しや癖を見つけさせる使い方が最も役に立つという報告や、受動態と冗長な一文を指摘させるプロンプトの例が挙がっている。25年の執筆経験から、必要なのは最初の手ではなく第二の目だという同意もある。書き手の文章の代わりに、特定の読者像を演じさせて反論を出させる使い方の方が有効だという意見も出ている。

一方で、記事自身が「load-bearing」のようなモデルが好む言い回しを使っている点を指摘する声や、AIを使って書かれた文章が増えることで読む量が減るという懸念、「要するに書くな」という短い反応もある。

記事は、Typstの最近の進展を紹介する中で、フォントの各種バリエーションを1ファイルにまとめられるバリアブルフォントを「最近の発展」として説明している。

コメントでは、フォントに詳しい立場から、TrueType Collectionsという形で25〜30年前から同種の仕組みが広く使われていたという指摘が出ている。また、可変性という点ではTeXが40〜50年前から持っていたMetafontの方が先行しており、先行事例として触れてほしかったという意見もある。

これに対しては、バリアブルフォントはTypstが作ったものではなくOpenTypeの系譜でブラウザでも対応済みであること、Metafontはビットマップ中心でLaTeX以外では事実上使われていないこと、Typstの対応は利用者が求める技術に応えただけであることが説明され、元の指摘が見下した物言いだという反応も付いている。

記事は、ランダム生成のパスワードをパスワードマネージャに置き、独立したTOTPアプリを併用する構成なら、利用者が主導権を握りつつ平文の柔軟さを保てると主張する。パスキーは中間者攻撃には強くなるが、アカウントを失う確率の高い状況に直面することになる、という整理である。

コメントでは、追加のログイン手段としてのパスキーは歓迎だが、サイト側が追加手段と必須の第二要素のどちらとして扱うのか方針が揃っていないことが問題だ、という指摘が出ている。自分はパスキーを端末の中に入ったYubiKeyとして扱い、同期の仕組みには触れていないという運用の報告もある。

一方で、仕事用PC、家族共用のデスクトップ、ノート、タブレット、電話という多対多の環境ではパスキーの使い勝手が良くないという反論や、パスワードを使い回していた層にとっては大きな前進だという指摘も並ぶ。

記事のタイトルにある主張は、頭を使わずに済むようになる地点は来ない、というものである。

コメントでは、「来ない」は言い過ぎで希望的観測ではないかという指摘が出た。LLMが従業員の仕事をこなせるようになったとして、従業員がそれに気づき雇用主がまだ気づいていない移行期間は存在する、という見立てである。これに対しては、現に雇用主はLLMが仕事をこなせるという誤った思い込みのもとで解雇を進めている、という反論が付いている。

また、AIを理由に挙げた解雇は元々やりたかった人員削減の口実で、実態はパンデミック期の過剰採用の是正ではないか、という見方も出ている。全員が解雇されたら誰が製品を買うのかという問いに対しては、他の企業が買うので人抜きでも経済は回りうるが人にとっては良くない、という応答と、そこまで行く前に社会が持たないという反論が続いている。

記事は、Jacという言語が持つ所有権まわりの仕組みを取り上げ、高水準な言語の中で必要な箇所だけ借用チェックを働かせる形を紹介している。

コメントでは、言語の存在意義を示すために不自然な比較対象を立てる書き方への批判が出た。Rustを読める立場からは例が単純すぎて論旨がぼやける、という指摘である。著者はこれに応じ、Jacはシステム言語ではなくJavaScriptやPythonとの相互運用を持つ高水準な言語で、ネイティブコードにもコンパイルできる点を示したかったと説明し、例が良くなかったことを認めている。

また、この機能は unsafe な Rc::get_mut の言い換えではないかという指摘に対し、get_mut はOptionを返すので unsafe ではない、意図しているのは未定義動作の危険がある get_mut_unchecked やポインタ操作の方だろう、というやり取りも続いている。

スキルは、上級のエンジニアがソフトウェアを作るときに使う進め方、品質ゲート、慣行を記述したもので、エージェントが開発の各段階で一貫して従えるようにまとめられている。DEFINE / PLAN / BUILD / VERIFY / REVIEW / SHIP という流れに沿って、アイデアから仕様、実装、テスト、QAゲート、公開までを並べている。

入口として9つのスラッシュコマンドが用意されており、/spec（コードより先に仕様）、/plan（小さく原子的なタスク）、/build（一度に一つの薄い層）、/test（テストが証拠）、/constraints（一度決めて全体に効かせる）、/review（マージ前にコードの健全性を上げる）、/webperf（測ってから最適化する）、/code-simplify（巧妙さより明快さ）が対応するスキルを自動で起動する。

READMEは、Claude Codeをターミナルに常駐してコードベースを理解し、定型作業の実行、複雑なコードの説明、gitのワークフローの処理を自然言語の指示で行うツールとして説明している。

インストール方法は、macOSとLinuxでは install.sh、WindowsではPowerShellのスクリプトが推奨で、HomebrewとWinGetにも対応する。npm経由のインストールは非推奨になったと注記されている。導入後はプロジェクトのディレクトリで claude を実行する。

リポジトリにはClaude Code向けのプラグインも同梱されており、詳細は公式ドキュメントを参照する構成になっている。動作にはNode.js 18以上が必要である。

Histerは、訪れたページと保存しているファイルの内容を丸ごと索引し、後から探し直せるようにする。検索の入口はWebインターフェース、ターミナル、そしてMCP経由で接続したAIアシスタントの3つである。

導入はリリースからプラットフォーム別のバイナリを取得して hister という名前にし、LinuxとmacOSでは実行権限を付けて ./hister listen で起動する。Windowsでは PowerShell で .\hister.exe listen を実行する。索引と検索の間はサーバーが動いている必要があるため、そのターミナルは開いたままにする。

その後、FirefoxまたはChromeの拡張機能を入れ、拡張を有効にした状態でページを開いてから、そのページ中の語句で検索すると最初の結果が得られる。設定は不要とされている。

ワークスペースはTerraformで定義し、EC2のVM、KubernetesのPod、Dockerコンテナなどを対象にできる。接続はWireGuardのトンネル経由で、使われていないワークスペースは自動的に停止する。

Coder Agentsは、AIコーディングエージェントのループを自前のインフラ上のコントロールプレーンで実行する構成を取る。そのためワークスペース側にAPIキーを置かずに済む、という点をREADMEは強調している。

リポジトリはセルフホスト型のクラウド開発環境とAIコーディングエージェントのためのプラットフォームと位置づけられており、開発者とそのエージェントの双方に安全な環境を与えることを掲げている。

プラグインは、職種ごとに必要なスキル、コネクタ、スラッシュコマンド、サブエージェントをまとめたもので、その職種の人を手伝うための出発点を与える。自社のツールや用語、業務手順に合わせて調整することで効果が出る、という位置づけで説明されている。

公開されているのは、Anthropic自身の業務から生まれた11個のプラグインである。例えばproductivityはタスクやカレンダー、日々の進め方や個人の文脈を扱い、Slack、Notion、Asana、Linear、Jira、Monday、ClickUp、Microsoft 365のコネクタに対応する。salesは見込み客の調査、商談前の準備、パイプラインの確認、アウトリーチの下書きを担当する。

Needleは、汎用の対話能力を犠牲にする代わりに、端末上のツール呼び出しでは10倍の規模のモデルを上回り、抽出では2〜3倍の規模のモデルと並ぶことを狙っている。機能はツール呼び出し、構造化抽出、テキスト埋め込みの3つで、アプリが公開した関数の中から適切なものを選んで引数を埋め、該当するツールがなければ推測せず空のリストを返す。抽出では形を宣言すると型付きのフィールドが返り、デコードの文法が出力のパースを保証する。

Needle 3はLaddered Simple Attention Networkと呼ばれる構成で、FFNの代わりにMonarch Hadamard MLP、causal convを伴うGQAアテンション、gatherで読むengramのn-gramメモリ、多レーンのhyper-connectionsを持つ。2層から20層までのどの深さでも配備可能なモデルになるよう訓練されており、パラメータの大半がengramにあるため121Mのモデルが50M相当の演算量で動くとしている。

記事は、全社員が使うAIの入り口を1つにまとめた構成を紹介する。社員の手元にはOpenCodeを配り、リクエストは自前ホストのLiteLLMを経由させ、利用できるモデルを会社側で決める形になっている。

コメントは評価が割れている。LiteLLMでBYOK形式の社内キー利用を一元管理できる点や、SSOの自作、予算枠を週次で絞る運用の泥臭さを参考になると評価する声がある一方、週次の利用制限があって好きなエージェントを使えない環境では働きたくない、エンジニアリングに金をかけない会社という印象が強まる、という否定的な反応も並ぶ。

特定のエージェントにロックインされないこと自体は妥当だという意見も出ている。

実験ではチェスでClaude 5 Sonnetに5戦全勝し、MOBA風ゲームではスプリットプッシュやタワーダイブのような戦術が観察された一方、集団戦で誰がタンクするかの協調ができない場面もあったとしている。実装抜きにルール名とコードだけでLintの結果を答えさせる試験は正答率86%、Playwrightでのフォーム操作は単独ではエラーから復旧できず、Claudeにログを監視させて補助すると96%以上になった。

コスト面では、MOBA風ゲームを1戦させて$0.0001、出力は無料。1リクエストの応答は約500msで、モデル単体の性能が高いわけではなく真価は並列度にあり、256個の質問を同時に投げて同時にスコアを得られる点を挙げる。confidenceは0.96以上でほぼ確信、0.4以下は誤っている可能性が高いため、その場合は別のモデルにフォールバックする設計を勧めている。

不具合は3つ挙げられている。キーを素早く連続して押すと画面を消す処理と新しく出す処理がぶつかり入力を受け付けなくなる、取り消しキーを押しても別の画面が処理の権利を握ったままで内部が選択中のまま残る、送信中に再度呼び出すと表示されるべき画面が出ない、というもの。原因は各画面が自分で表示・非表示を決め、隣の画面を直接操作していたことにあるとする。

対策として記事が示すのは、すべてのコンポーネントをRootからなる階層構造下に置き、各コンポーネントはMVPパターンのPassive Viewとして描画に関わるパラメータだけを操作し、動作はChain of Responsibilityでイベントをバブリングさせ、ステートマシンとして振る舞うMediatorに裁定させる、という指示をそのままAIに伝える形である。

記事は、出力候補があらかじめ決まっている場合はJSON全体を自己回帰生成する必要がないと指摘する。trueとfalse、あるいはA/B/Cのような短いIDを単一トークンに対応させ、回答位置のlogitだけを比較すれば1回のforward passで判断を取り出せる。複数の独立した質問はbatch推論でまとめ、長い共通プロンプトはKV Cacheを再利用し、最終的なJSONはコード側で組み立てる構成になる。

Gemma3 270Mでこの並列推論方式とJSON出力を比較したところ、77倍の高速化になったとし、LLMとの比較はこの方式に対して行わなければ公平とは言えないと述べる。JevでDOOMをリアルタイムに操作するデモについては、Jevが画像入力に対応していないため、ゲーム状態を構造化データに変換するハーネスを介していると推測している。

記事は、Jevを状態と質問を受け取って型付きの回答を確率とともに返すモデルと説明し、提供元のTypeSafe AIがこの種類をSystem One Modelと呼んでいることに触れる。注目されている理由として、用途は限定されるが入力がGPT 5.6 Lunaより約8割安く出力が無料であること、汎用分類器として超高速に使えるif文のように扱えること、APIなので組み合わせの幅が広いことを挙げる。

利用経路は、TypeSafe AIのwaitlist（筆者は9月17日18時に登録し28時に到達）のほか、Vercel AI GatewayとCloudflareでもホストされている。Skillsのように失敗箇所を後から足していく確率的な最適化は局所最適になりやすく、3か月後の新モデルでは負債になりがちだとして、決定論的なガードレールを作りたい需要にJevを当てる構成を示している。

WebMCPは、Webページ側がAI向けの操作をブラウザ上に直接提供する仕組みで、サーバーではなくフロントエンドにツールを登録する。エージェント側に特別な認証設定が要らずブラウザのログイン状態をそのまま使えること、サーバーに保存される前の未保存データもJavaScript経由で操作できることを利点として挙げる。

定義方法は、フォーム要素にtoolnameなどの属性を付ける宣言型と、document.modelContext.registerToolで動的に登録する命令型の2種類がある。対象のデザインエディターはReact製のため命令型を採用した。検証にはCodexのブラウザ操作（GPT-6 Astra、Effortは中）を使っている。

2026年9月時点でW3Cのコミュニティグループで議論中の提案仕様で、Chromeではフラグ付きプレビューとオリジントライアルの段階、navigator.modelContextからdocument.modelContextへの変更など仕様変更が続いていると注記している。

筆者はClaude Code、Codex、Agyの3エージェントを併用しており、生成されたコードを人手でレビューすることが実質不可能な規模になっていた。Issue単位でブランチを切り、規模が大きければスライスに区切って小さく実装を回す進め方を取っている。

ローカル側は、temperature 0.05、top_p 0.8、num_ctx 8192のModelfileでqwen2.5-coder:14bから自分用モデルを作り、gitのステージに上がった差分から重大な問題候補だけを挙げさせる。検出対象はデータ損失、クラッシュ、セキュリティ境界の破壊、path traversal、Electron IPC境界の破壊、race condition、off-by-oneなどに限定し、コーディングスタイルや命名の好み、要約や褒め言葉は出力しないよう指示する。出力はJSON配列のみで、問題がなければ空配列を返させている。

記事は、Jevが単に速いモデルではなく、意図的に出力を限定することで精度と速度を得る最適化を行っていると整理する。現時点でできるのはNoul（YES/NOを答える）、Choice（選択肢から選ぶ）、Score（点数を付ける）の3つで、チャットAIと違っていかに構造の制約を設計するかが要点になるとしている。

実装では、15×15の盤面をアスキーで表現し、ルール、セルの表記法、直近の手、各候補の状況を示すヒント（自分の最善の並びが開いた端を持つ3つ、相手の五を防ぐ、など）をstateとcriteriaに入れ、choice型で次の一手を選ばせている。プログラマは既存のチャットアシスタントよりこうした構造化されたエージェントの方を好むのではないか、という感想を添えている。

前提としてGitHubでIssue管理を行い、Claude Codeを主、Codexを従とする構成を取る。Claude Codeが設計と実装のほかGitHub・Codex・人間とのやり取りを担い、Codexはレビューのみを行う。レビューは、先入観なく見てもらうよう気をつけたうえでCodexと人間によるクロスレビューにしており、人間側はcritを使っている。

スキルは複数の会社のプロダクトから呼べるよう、リポジトリではなく ~/.claude/skills/ にユーザーレベルで配置している。名前はtodays-workで、disable-model-invocation: true を付けて /todays-work で明示的に呼んだときだけ動くようにし、引数にIssue番号またはURLを取る。空なら聞き返す。名前は語呂で付けただけで、複数日かかってもよいと断っている。

以前はRedashからAuroraのリードレプリカに直接SQLを投げる構成で、最大約2.5TBのログテーブルに対して重いクエリが返らない、ビジネスメンバーが知りたいことを都度エンジニアに依頼する必要がある、PIIを含むテーブルと含まないテーブルを分けて権限設定できず安全側に倒すしかない、という3つの課題があった。

新基盤では、dbtのschema.ymlを唯一の定義源とするセマンティックレイヤーをLightdashで構築し、そのAPIを包むMCPサーバを用意してAIクライアントから自然言語で同じ指標を引けるようにした。権限境界はBI層に置き、PIIの列は専用テーブルに隔離してuser_attributesを持つ人だけに見せる。

SQLを含めほぼ全てのコードはClaude Codeが書き、OSSのLightdashをセルフホストしたためBIやDWHのライセンス費はなく、運用はクラウド利用料の月1,200ドル前後としている。

Fragment Refsは、Fragmentコンポーネントがrefをサポートするようになる機能で、得られるのはReactが用意したFragmentInstanceオブジェクトである。addEventListenerやfocusなどのメソッドを持ち、DOM要素を描画しないラッパーに対して疑似的に操作しているかのように振る舞う。

背景にあるのはReact 19.2で導入されたActivityコンポーネントで、mode="hidden"のときは自身では何も描画せず、中のDOM要素にdisplay: noneを与えて非表示を実現する。同じ挙動のコンポーネントを自作することは従来できなかった。

記事は、React 19.3時点でFragmentInstanceが持つメソッド（addEventListener、dispatchEvent、focus、observeUsing、getClientRects、compareDocumentPositionなど）を確認したうえで、Hiddenコンポーネントの実装に入る。

記事は、仕事が1から10まであるとして、「この作業だけは任せられそうだ」と考える進め方では1しか変わらず、残りは従来のままになると指摘する。対して「1から10まで全部任せられないか」から考え始めると、想定よりも多くの部分を任せられることに気づくとしている。答えのない判断や戦略を考える仕事は最終的に自分の頭で考えるとも書く。

筆者自身の実践として、会議で議論が行き詰まったら「5分AIタイムです」と言ってその場でAIに壁打ちすることを挙げる。世界で一番優秀な相談役として使わない手はない、という評価である。また、状況の説明をタイピングすると1時間かかる分量でも音声入力なら一瞬で済むとして、GPTやClaudeの音声認識を常用しているとも書いている。全部を丸投げしてよいわけではなく、自分も全部できているわけではないとも断っている。

TypeSafe AIは2026年9月15日、同社がSystem One Modelと呼ぶモデルの最初の公開モデルとしてJevを発表した。System Oneの名称は、ダニエル・カーネマンが説明した素早く直感的に判断する「システム1」に由来し、Jevの名は効率改善に伴って資源の利用が拡大する現象で知られる経済学者ウィリアム・スタンレー・ジェヴォンズにちなむ。

記事は、二重請求の返金を求める顧客メールを例に両者を比べる。従来のLLM+AIエージェントでは、メールや対応履歴、利用可能なツール、返金規程を渡し、LLMが処理の進め方を文章として返す。対してJevは、分類・採点・条件判定の結果を型付きの値と確率で返し、非AIエージェントのアプリケーション側が条件を判定して処理を分岐する、という違いになるとしている。

状況を表すテキストやJSON（state）と型付きの問い（questions）を渡すと、選択肢ごとの確率と確信度が返り、文章は生成されない。問いの型はChoice（選択肢から1つ）、Score（段階評価）、Noul（Yes/Noの確率）の3種類で、複数の問いを1回の呼び出しで並列に評価する。公称値は応答70〜500ミリ秒、入力100万トークンあたり0.042ドル、出力は無料。文章の生成、計算、日付の比較は公式が不得意と明記している。

たとえとして、LLMにJSONを書かせるのは記述式の答案に近く、モデルが1トークンずつ書いた答案をプログラム側が形式から確かめる必要がある。Jevはマークシートに近く、出題側が選択肢を用意し、どの欄をどれくらいの確からしさで塗るかを1回の計算で返すため、用意していない選択肢が答えに出てくることもないとしている。

きっかけは、Figma・Notion・Googleスプレッドシートで同時編集を比べたときに画面への反映のされ方が違うと気づいたこと。記事は体感差そのものを厳密に説明するのではなく、背景にある同期と競合解決の設計に焦点を当てると断っている。描画やレンダリングの最適化は扱わない。

挙げられている工夫は4つで、サーバー到着順を利用したLWW register相当のプロパティ同期、楽観的更新とそれによって生じるチラつきを防ぐ一手間、循環参照というエッジケースを一時的な割り切りで吸収する設計判断、Fractional Indexingによる挿入コストの低い兄弟順序管理である。OTやCRDTを名前だけ知っていて実際の設計判断に興味がある読者を対象に挙げている。

前提として、情報は2026年9月18日時点、提供状況は早期アクセス（ウェイトリスト）、提供形態はAPIのみでVPCやオンプレミスの記載はないと整理する。本文中の数字もすべてドキュメントの記載であり筆者が測ったものではないと断っている。

入出力は、問い合わせの文章をstateとして渡し、聞きたいことをquestionsに型付きで書く形である。記事が示すリクエスト例では、Stripeアカウントの接続が3日間失敗しているという問い合わせに対し、担当チームをbilling / technical / salesから選ばせるchoiceと、顧客がどの程度苛立っているかを段階で評価させるscoreを同時に問うている。