Jev をめぐる日本語圏の記事が入門から検証と限界の指摘へ移り、Hacker News では ChatGPT が広告コレクター経由で他サイトの行動を収集しているという記事が首位に立った

コメントの出発点は、新しい規制を求めているのが規制される企業自身であることの異様さで、既に法はあるのに執行されていないだけだ、という主張である。

これに続いて規制の虜という枠組みが持ち出され、大手だけが負担できる制約を課す規制を自ら求めることで、その制約を満たせる企業だけが市場に残る形を作れる、という説明がなされた。

反論もあり、固定費が大きい企業に有利に働くのは規制一般の性質で捕獲を必ずしも意味しない、大企業が小企業から守られること自体がなぜ悪いのか、具体的にどのルールが企業に有利で公衆に不利なのかを示してほしい、という問いが投げられている。議論は噛み合わないまま続いている。

記事は、安価でローカル実行もできるモデルが脆弱性の発見とエクスプロイト作成に十分な水準に達したとして、猶予は 1 年しかないと主張する。

コメントには具体的な監査の報告が並んだ。GPT-6 Astra と Claude Fable 5.1 で Datasette を監査したところ、これまで誰も気づかなかった難解な脆弱性が多数見つかり、修正に 1 週間かかったという。「すでに修正済みのセキュリティ問題を読んでから、似た問題を探せ」というプロンプトが特に有効で、サブエージェントを並べて探索させたという手法も共有されている。1 年どころかマイナス 6 か月で、攻撃側はすでに使っているが報道されていないだけだ、という見方もある。

対策の議論はサンドボックスに集中した。コンシューマ向け OS に使える形で文書化されたサンドボックス機能が無いことへの苛立ちと、長期的にはケイパビリティモデルに向かうべきだという主張が続いている。

議論は、フォークされたブラウザを使い続ける妥当性に集まった。Firefox が AI のキルスイッチを入れたので LibreWolf から戻るという報告に対し、Firefox が増やしている攻撃面を考えるとブラウジングに特化したフォークの方が安全になり得る、という反論が出ている。

上流が最も安全だという立場からは、Mozilla がフルタイムの開発者とセキュリティ専門家を抱えていること、フォークでは開発者が少なく上流のパッチ適用が遅れてゼロデイの窓が広がることが挙げられた。

Tor Browser を painstakingly パッチしているという記事の記述には、Tor 側の関係者から訂正が入っている。実際にはランタイムの設定やビルド時のフラグを提供して協力しており、必要があれば開発チーム同士で直接話す用意があるとして、基盤となるブラウザプロジェクトの issue へのリンクも示された。

投稿者自身の記述によれば、2025 年 3 月の実装は凍結した系列埋め込みと別の PPO 価値ネットワークの組み合わせで、ターンごとの販売予測には使えたがエンドツーエンドではなく、実行時に新しい質問を扱えなかった。その制約が今回のモデルとの違いだという説明が、コメントでも確認されている。

技術的な位置づけとしては、テキストを分類し分類数が少ないなら単純なベイズ学習でも十分だった、という過去の経験からの振り返りが出ている。

これに対し、Jev はタスクを自然言語で与え出力スキーマを指定すれば予測が返る汎用分類器で、従来のようにラベル付きデータを集める必要がない点が違う、という整理が示された。世界知識を持つため高い抽象度で書ける反面、自分の要件に合わせて細かく調整できない。ルールを十分に記述できず既存の理解を上書きしたい場合は恩恵が小さい、という指摘が添えられている。

コメントでは、記事の主眼は抽象化を考えすぎるとソフトウェアの目的自体を見失う点にある、という整理がまず示された。そのうえで、コードの日々の作業から離れると開発について適切に判断できなくなる、という別の論点が持ち出されている。

これには反論があり、良い開発者だった人は設計側に回っても良い問いを立てる、悪いアーキテクトはもともと開発者としても宇宙飛行士だった、という見方が出ている。開発経験がまったく無いアーキテクトは大手コンサルティング企業に見られるという体験談も添えられた。

組織の側の問題も指摘されており、巨大企業では複雑な問題を解くことが高く評価されるため、最も単純で洗練された解ではなく最も複雑な解を書く動機が生まれる、という説明がある。過剰設計はアーキテクトに限らず日々コードを書く人にも起きる、という留保も出ている。

コメントでは、記事が扱う事例に加えて .io の行方への関心が示され、TLD の販売収益はチャゴス諸島の住民に還元されるべきだという意見が出ている。

.su については、今年から .ru とともにロシア国民以外の利用を制限する登録要件が入ったため、相当数のドメインが消えるだろうという観測が示された。

これに対し、SU は EU や歴史的な UK と同様に ISO の予約登録があり、ICANN はそうした TLD の存続を認めているので、規則が変わらない限り消えないという反論が出ている。

AI エージェントに使わせるためのコンピュータを提供するプロジェクトで、デスクトップ自動化、隔離されたクラウドデスクトップ、ローカルの macOS VM、コンピュータ操作の判断に特化した小型モデル、エージェント評価用のベンチマークをまとめている。

構成要素は 5 つに分かれる。Cua Fleets は Linux デスクトップをプロビジョニングしてコマンドを実行しスクリーンショットを保存する部分、CUA-S1 は判断用の小型モデル、Cua Driver はアプリの操作、Lume は macOS VM の作成、Cua Bench はタスクの作成と検証を担う。自前のエージェントとモデルを持ち込む構成も想定されている。

Computer-Use 2.0 という呼び方は、同一タスクの中でコード、API、グラフィカルインターフェースの間をエージェントが行き来することを指す。デモでは、Omarchy デスクトップ上で LibreOffice Calc のセルと Inkscape のオブジェクトを 2 つの Cua Driver セッションが選択する様子が示されている。

エージェントハーネスの性能最適化を目的としたシステムで、スキル、instincts、メモリ、セキュリティ、リサーチ先行の開発を Claude Code、Codex、Opencode、Cursor などに横断して持ち込む構成になっている。README は 13 言語に翻訳されている。

冒頭には配布元に関する警告が置かれている。正規の入手経路は GitHub リポジトリ、npm の ecc-universal と ecc-agentshield、GitHub App、プラグインスラッグ ecc@ecc、および ecc.tools のみで、第三者による再アップロードやミラーはメンテナンスもレビューもされておらずマルウェアを含む可能性がある、としている。

インストールは Claude Code のガイド付きセットアップかネイティブのプラグインコマンドのいずれかで、同じ ecc@ecc プラグインが入る。両方を重ねないよう明記されている。OSS 部分は MIT で永続的に無料、ECC Pro は非公開リポジトリ向けのホスト型 GitHub App という位置づけで、単独のメンテナが 7 つのハーネスに毎週出荷していると説明している。

高価な市場情報プラットフォームの代替を目指すオープンソースのアプリで、リアルタイム価格の追跡、個別のアラート設定、企業情報の閲覧を提供する。コミュニティによる開発でブローカーではなく、市場データは提供元の規則や設定によって遅延する場合があり、投資助言ではないと明記している。

ライセンスは AGPL-3.0 で、改変・再配布はもちろん Web サービスとしてデプロイする場合も同じライセンスでソースを公開し、原著者をクレジットする必要がある。

README は技術スタック、機能、クイックスタート、Docker 構成、環境変数、プロジェクト構造、データ連携、対応市場、スクリプトとツール、コントリビュート、セキュリティの順で構成されている。

上級エンジニアが使うワークフロー、品質ゲート、ベストプラクティスをスキルとして符号化し、エージェントが開発の全フェーズで一貫して従えるようにしたもの。

全体は DEFINE、PLAN、BUILD、VERIFY、REVIEW、SHIP という流れで、アイデアから仕様、実装、テスト、QA ゲート、公開までを 1 本の線として図示している。

9 つのスラッシュコマンドがこのライフサイクルに対応する。/spec はコードより先に仕様を、/plan は小さく原子的なタスクへの分解を、/build は一度に一切れずつの実装を、/test はテストを証明として扱うことを、/constraints は品質の基準を一度決めて全体に適用することを、/review はマージ前のコード健全性の改善を担う。ほかに /webperf、/code-simplify、/ship がある。

GPU のワークロード管理と機械学習フレームワークを兼ねるツールで、大規模言語モデルのようにパラメータ数が数十億から数兆に及ぶモデルの学習を想定している。

機能は 5 つに整理されている。計算資源（ノード）への排他的・非排他的アクセスの割り当て、ZeRO-3 deepspeed API と PyTorch の fully sharded data parallel API への対応による兆パラメータ規模のシャーディング、割り当てたノード上での学習の開始・実行・監視のためのフレームワーク、実験のキュー管理によるリソース競合の解消、GitHub および GitHub Actions との統合による継続的インテグレーションである。

インストールは pip install higgsfield==0.0.3 で、README には学習の記述例が続く。

ターミナルに常駐してコードベースを理解し、定型作業の実行、複雑なコードの説明、git のワークフローの処理を自然言語で行うエージェント型のコーディングツール。ターミナル、IDE、GitHub 上の @claude メンションのいずれからも使える。

インストールは npm 経由が非推奨になり、macOS / Linux では curl によるインストールスクリプトか Homebrew の cask、Windows では irm によるスクリプトか winget が推奨経路として示されている。インストール後はプロジェクトのディレクトリで claude を実行する。

リポジトリにはいくつかのプラグインも含まれており、セットアップの詳細やアンインストール手順、トラブルシューティングは公式ドキュメントに置かれている。

クラウド開発環境と AI コーディングエージェントのためのセルフホスト型プラットフォーム。ワークスペースは Terraform で定義し、WireGuard のセキュアなトンネルで接続され、使われていないときは自動的に停止する。

対象となる実体は EC2 の VM、Kubernetes の Pod、Docker コンテナなど幅広く、開発環境の定義をコードとして扱える。

Coder Agents は、ネイティブの AI コーディングエージェントを動かす機能で、そのループを自社インフラ上の制御プレーンで実行する。これによりワークスペース側に API キーを置かずに済む構成になっている。

実験ログは jev-playground に公開されている。チェスは Claude 5 Sonnet に 5 戦全勝、ESLint のエミュレーションは実装を渡さずルール名とコードだけで正答率 86%、Playwright のフォーム操作は単独ではエラーから復旧できず、Claude にログを監視させることで 96% 以上になった。

コストは MOBA 風ゲーム 1 戦で $0.0001、出力は無料で、1 リクエストは約 500ms。真価は並列度にあり、256 個の質問を同時に投げて同時にスコアを得られるとしている。confidence は 0.96 以上ならほぼ確信、0.4 以下は誤りの可能性が高く、別モデルへのフォールバックの目安になる。

位置づけとしては、Tool Call が自然言語の延長で JSON を出力させる仕組みだったのに対し、Jev は最初から構造を出力するように作られている、と整理している。

macOS 常駐の AI アシスタントを Claude Fable 5.1 と GPT 6 Astra で開発する中で、キーを連打すると画面が反応しなくなる、取り消しキーを押しても状態が戻らない、表示されるべき画面が出ない、といった不具合が出るようになった。

原因は、各画面が自分で表示・非表示を決め、隣の画面を直接操作していたことにある。処理の衝突を避けるための排他や待ち時間、やり直しを場当たり的に継ぎ足した結果、1 つ直すと別の場所が壊れる状態になった。

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

JSON 全体を自己回帰的に生成する代わりに、true / false のように回答候補を単一トークンへ対応させ、その位置の logit を 1 回の forward pass で比較すれば判断を取り出せる。選択肢が複数でも短い ID を割り当てれば同じで、JSON はコード側で組み立てる。独立した質問はバッチ推論にまとめ、共通プロンプトは KV Cache を再利用する。

この方式を Gemma3 270M で実装し、同じ出力になるよう調整したプロンプトで比較したところ、JSON 出力に対して 77 倍の高速化になった。LLM と比べるならこのやり方と比べないとフェアではない、というのが記事の主張である。

DOOM をリアルタイムに操作するデモについては、Jev が画像入力に対応していないため、ゲーム状態を構造化データに変換するハーネスを介していると推定している。公開されたマリオ用ハーネスで試した範囲では、手元の Jev は公開デモほどうまくプレイできなかった。

Jev は状態と質問を受け取り、型付きの回答を確率とともに返すモデルで、提供元の TypeSafe AI はこの分類を System One Model と呼んでいる。入力は GPT 5.6 Luna より約 8 割安く、出力は無料で、汎用分類器として高速な if 文のように使える点が注目されている、と整理する。

利用経路は TypeSafe AI の waitlist が王道だが、待たずに使いたい場合は Vercel AI Gateway でホスティングされている。記事では AI Credit をチャージして利用しており、Cloudflare でも使えるようになったと追記されている。

ハーネスエンジニアリングの文脈では、失敗箇所をスキルに落とす最適化は局所最適になりやすく、数か月後の新モデルで負債になりがちだと指摘する。決定論的なガードレールは Rust などで速度を意識して書く必要があり手間がかかるが、Jev なら安価かつ高速に実装できるとして、Claude Code の Auto-Mode に相当する仕組みを作っている。

jev-lint は、ast-grep のセレクタで抽出したコードに対し、自然言語で書いたルールを Jev にバッチで評価させるツールで、npx -y jev-lint で動く。ast-grep が対応する言語、つまり tree-sitter の定義がある言語なら使え、TYPESAFE_API_KEY が必要になる。

ルールは YAML で書き、関数名が実装と噛み合っているかを問う ask と、true / false それぞれの判定基準、カットオフ値を指定する。プリセットは 23 ルールあるが最適化が進んでおらず品質もまちまちで、フルに書く前提だとしている。関数名とテスト名の実態との一致、コメントの正しさ、嘘のデバッグ出力、事前指定したアンチパターンの検出など、既存の静的 Lint で扱えない領域に絞っている。

制約として、言語理解が LLM 側にあるためスコアが揺れる点を挙げ、--retry n で複数回問い平均で判定し、--record で記録した答えを replay して閾値を変えられるようにしている。Jev のリクエストは 64K トークン、state は 32K トークンが上限で、扱えるのは同一ファイル程度の短い文脈に限られる。

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

定義方法は 2 種類ある。宣言型はフォーム要素に toolname や tooldescription といった属性を付けるだけで JavaScript を書かずに済み、命令型は document.modelContext.registerTool で inputSchema と execute を持つツールを動的に登録する。対象が React 製のため記事では命令型を採用している。

注意点として、WebMCP は 2026 年 9 月時点で W3C のコミュニティグループで議論中の提案仕様であり、Chrome ではフラグ付きプレビューとオリジントライアルの段階にあること、navigator.modelContext から document.modelContext へ変わるなど仕様変更が続いていることを挙げている。検証には Codex のブラウザ操作を使っている。

毎回同じ流れで開発しているのに都度指示を出していたため、Issue を取る、AI に設計と実装を任せる、別の AI にレビューさせる、動作確認する、PR を作る、という一連をスキル化した。前提として Issue 管理が必要だが、AI とやり取りできるなら Notion でも Trello でもよいとしている。

構成は、Claude Code が設計と実装および GitHub・Codex・人間とのやり取りを担い、Codex はレビューのみを行うクロスレビュー。先入観を持たせないようレビュー依頼の出し方に気をつけ、人間のレビューには crit を使う。

スキルは特定リポジトリに閉じないよう ~/.claude/skills/ に置き、どのリポジトリからも呼べるようにしている。todays-work という名前で、disable-model-invocation を付けて明示的な呼び出し時のみ動くようにし、コミットメッセージや PR の書式、テストの書き方はリポジトリの AGENTS.md / CLAUDE.md を優先する作りになっている。

以前は Redash から Aurora のリードレプリカへ直接 SQL を投げており、最大 2.5TB のログテーブルで重いクエリが返らない、ダッシュボード 1 枚ごとにエンジニアの手が要る、PII を含むテーブルと分離できず権限を絞らざるを得ない、という 3 つの課題があった。

新基盤 Laplace では、dbt の schema.yml を唯一の定義源とするセマンティックレイヤーを Lightdash で構築し、指標定義とテーブル結合を事前に決めることで、利用者がデータ構造を知らなくても正しい集計にたどり着けるようにした。Lightdash の API を包む MCP サーバーを用意し、AI クライアントから自然言語で同じ指標を引け、根拠 URL で検算できる。

ガバナンスは権限境界を BI 層に置き、PII の列は専用テーブルへ隔離して user_attributes を持つ人だけに見せる。機微情報は既定で非公開とし、承認された人にのみ期限付きで付与して自動剥奪し、監査ログで追える。AI 経由でも PII の値は LLM に返さない。設計と実装は 1 人、SQL を含むコードはほぼ Claude Code が書き、着手から公開まで 1 か月、運用費は月 1,200 ドル前後としている。

導入前は ChatGPT、Claude、Cursor などが社内で乱立し、どんなプロンプトが使われているか把握できず、費用も ROI を考えると放置できない水準になっていた。そこで全社員が同じ入り口から AI を使う構成に切り替えた。

OpenCode からのリクエストは ECS Fargate 上の LiteLLM に届き、各プロバイダーへ中継される。API キーは LiteLLM だけが持ち、社員は SSO で発行した個人キーを使う。キーに予算上限を設定できるため請求の暴走を仕組みで防げ、モデルの差し替えも LiteLLM 側で完結する。リクエストが 1 か所を通るのでプロンプトのログが取れ、送信前にチェックする Guardrail の仕組みがある点も選定理由に挙げている。

クライアントの選定では、Claude Desktop の推論先を自前ゲートウェイに向ける構成は開発者モードを前提とするため非エンジニアには案内しづらく、Claude Code を LiteLLM 経由で使う構成は API エラーが頻発した。Claude Code が送る新しいパラメーターやヘッダーに LiteLLM 側が追随できていないという同様の報告が複数あったとしている。

Claude Mods は Claude Code の機能や見た目をカスタマイズするプラグインの仕組みで、従来の Hooks がコマンドを実行する形だったのに対し、TypeScript の関数として書いて本体に直接組み込む。そのため画面表示の変更やツールの追加まで踏み込める。この仕組み自体は Function Hooks と呼ばれている。

構成は、.claude-plugin/plugin.json、hooks/hooks.json と register.ts、/plugin-types が生成する型定義から成る。Mod は外付けではなく、標準搭載の /diff コマンドやテレメトリ機能、2.1.277 で追加された AGENTS.md のサポート（agents-md）も Mod として実装されており、標準機能自体を拡張できる位置づけになっている。

利用には early access の Function Hooks を有効化する必要があり、~/.claude/settings.json の env に CLAUDE_CODE_ENABLE_FUNCTION_HOOKS を 1 として設定し、--plugin-dir で Mod のフォルダを指定して起動する。記事は Issue #91870 で議論中の 2026 年 9 月 19 日時点の暫定仕様に基づくと断っている。

2.1.277 の changelog には、CLAUDE.md が無いプロジェクトでは AGENTS.md を読むと書かれている。それ以前は読まないという説明が正しかったため、検索で出てくる日本語の解説は古い状態になっている。

検証は、各ファイルに一意な合言葉を置き「指示にある合言葉を全部挙げろ」と尋ねる方法で行っている。Read や Bash などファイルを読めるツールは --disallowedTools で全て禁止し、--strict-mcp-config と捨て設定ディレクトリを使って条件を固定している。環境は Windows 10、claude -p、測定は 2026 年 9 月 19 日。

結果は公式の表どおりで、AGENTS.md のみなら読まれ、CLAUDE.md があれば AGENTS.md は読まれず、CLAUDE.local.md を 1 つ置いても読まれなくなる。~/.claude/CLAUDE.md がある場合は AGENTS.md も読まれる。そのうえで、1 回目のセッションだけ読まれないという挙動が観測されている。

2.1.275 の changelog には、/update-config がファイルの権限検査と一致しない Write(path) のルールを書いていた問題を修正した、と記載されている。つまり Write(パス) の権限ルールは検査に一致せず、しかもその形を書いていたのは Claude Code 自身だった。

測定は 36 回。deny に Write(ファイル) だけを書いた場合は 12 回とも書き込まれ、Edit(ファイル) だけの場合は 12 回とも止まり、両方書いた場合も 12 回とも止まった。Edit() は Write ツールによる新規作成も Bash のリダイレクトも止める。2.1.275 でも Write() は効かないままで、直ったのは書く側だけだとしている。

手法として、claude -p では拒否と確認待ちが区別できないため --permission-mode acceptEdits を使い、自動承認でも上書きできなければ効いている、書き込まれれば効いていない、と判定している。経路は Edit ツールでの既存ファイル書き換え、Write ツールでの新規作成、Bash のリダイレクトの 3 つで、判定はファイルの中身のみに基づく。環境は Windows 10、2.1.273 と 2.1.275 を隔離導入、測定は 2026 年 9 月 18 日。

筆者は、1 から 10 まである仕事のうち「この作業だけは任せられそうだ」と考える進め方では 1 しか変わらず、残りは従来のままになると述べる。対して、まず全部をボタン一つで任せられないかと考えると、思っていたより多くを任せられることに気づくとしている。

ただし全て丸投げしてよいわけではなく、答えのない判断や戦略を考える仕事は最終的に自分で考える。最初から一部だけと決めるのと、全部から削っていくのとでは到達点が違う、というのが主張の軸になっている。

実践例として、会議で議論が詰まったら「5 分 AI タイム」と宣言してその場で相談すること、状況を全て打つと時間がかかる場面で音声入力を使うことを挙げている。最後は自分で判断する必要があり、AI に聞いて満足して終わってはいけないとまとめている。

筆者は「なんでもCopilot」「JAWS-UG Sales」「雪かき部」の運営に関わっており、仕事の繁忙、私生活の問題、心ない言葉、そして技術に詳しくない自分が運営である意味への迷いという 4 つが同時期に重なり、降りることを伝える文章を書いては消す日々が続いたと振り返る。

転機は他の運営メンバーとの会食で、遠慮せずやりたいことをやってほしいという言葉をもらったことだった。ただし最初からうまくいったわけではなく、自分のアイデアが功を奏さないこともあったとしている。

そこから、投影資料の更新や SNS での発信、オフライン開催時の交流促進、営業ならではの視点を入れたアウトプットという形で自分の出せる価値を定めていった。AI 推進者やコンサルタント、エンジニア目線の発信が多いなかで差別化できると判断したという。

Jev は、文章で書かれた状況を読み、あらかじめ用意された選択肢のどれに当たるかを確率付きで返すモデルで、サンフランシスコの TypeSafe AI が 2026 年 9 月 15 日に早期アクセスとして公開した。同社が System One Model と呼ぶ分類の第 1 号にあたる。

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

記事は違いを答案にたとえ、LLM が記述式で 1 トークンずつ答案を書き、受け手が形式を確認してから中身を取り出すのに対し、Jev はプログラム側が選択肢を用意しどの欄をどれくらいの確からしさで塗るかを返すマークシート方式だと説明している。用意していない選択肢が出てこない点も利点として挙げている。

受講前は、生成 AI のセキュリティを「個人情報や機密情報を入力しない」「回答を鵜呑みにしない」という程度に捉えていたが、Prompt Injection、Jailbreak、情報漏洩、RAG のセキュリティ、企業でのガードレールを学ぶ中で、考える範囲が広がったと振り返る。

最も認識が変わったのは入力する情報の扱いで、「漏洩するかどうか」と「そもそも自分の判断で外部の AI サービスへ渡してよい情報なのか」を分けて考える必要があると気づいた点だとしている。友人の氏名や連絡先を旅行の日程調整のために入力する例を挙げ、悪意がなくても判断の主体が問題になると述べる。

そのうえで情報を 4 つに分類している。個人情報は原則そのまま渡さずマスキングする、パスワードや API キー・トークンは渡さない、社外秘や業務データは利用ルールを確認する、公開情報や公開して問題ない自分の文章は基本的に利用可能、という整理で、企業向けルールではなく自分の利用に当てはめたものだと断っている。

近年のモデル発表はパラメータ数やベンチマークの更新が中心で、アーキテクチャはトランスフォーマーの自己回帰生成のまま延長線上にあった。そのなかで TypeSafe AI が 2026 年 9 月 15 日に出した発表は「LLM ではない新しいクラスのモデル」を掲げており、毛色が違うとしている。

同社は System One Models という分類とその第一弾 Jev を発表した。公式ブログの「チャットに関してモデルはもう何年も人間を超えているのに、なぜ自動化はここまで進んでいないのか」という一節を引き、チャット向けモデルは十分賢いのに自動化に使うと扱いづらくなる、という課題意識から文字列生成を捨てた設計だと説明する。

創業者の Diogo Almeida 氏は OpenAI で InstructGPT の論文を共著し、初代 ChatGPT のクレジットにも名前が載っている人物である。筆者は「結局ただの分類器では」と疑う気持ちもあったとしつつ、公式ブログを読むと設計思想には筋が通っており、LLM 一強の空気のなかであえて別の道を選んだこと自体を評価している。

海外で現地 SIM に差し替えたところ日本の番号宛の SMS が届かず銀行アプリに入れなかった一方、認証アプリの 6 桁は機内モードでも表示された、という経験が出発点になっている。仕様を読み Python で書いたところ 20 行足らずで Google Authenticator と同じ数字が出たという。

結論として、認証アプリの 6 桁は登録時に共有した秘密の値と現在時刻からスマートフォン内だけで計算しており通信していない。SMS が弱いとされるのは、電話番号という乗っ取れる経路に依存するためで、SIM スワップ、番号の再発行、中継フィッシングが挙げられる。認証アプリは SIM スワップには強いが、正しい 6 桁を偽サイトに打てば中継フィッシングには負ける。

パスキーとの違いは、どのサイトに対する応答かが署名に含まれる点にあるとしている。参照として RFC 6238、RFC 4226、NIST SP 800-63B を挙げ、電話網を使う認証を「制限付き」とする扱いは第 3 版から続いていると注記している。

Jev は入力テキストに対して事前に定義した選択肢やスコアを返すモデルで、自由な文章を生成せず型付きの結果と確率・confidence を返すことに特化している。現時点ではテキスト入力のみで、画像・音声・動画には対応していない。

候補になる条件として、入力がテキストであること、出力候補を事前に決められること、意味的な判断が必要なこと、教師データが十分にないこと、高速・低コストに処理したいことを挙げる。ただし決定論的ではなく、出力形式は厳密でも判断結果は確率的なので、決定論的な処理が必要ならルールベースを使うべきだとしている。

分岐は、ルールを完全に記述できるならルールベース、テキスト以外を扱い十分な学習データがあるなら古典的な機械学習、文章やコードの生成が必要なら LLM、テキストから限定された判断をしたいが教師データがないなら Jev、という整理になっている。LLM を使うほどではないがルールベースでは難しい処理に選択肢を追加したモデルだ、とまとめている。