Jev-cuは、Computer Useの「次にどこを押すか」だけをJev（TypeSafe System One）に決めさせるCodex用のskillだ。画面の読み取りと実行はCodexが担当し、Jevは要素のラベル文字列だけを受け取って、対象・動作・完了・リスクの4点を確率で返す。スクリーンショットは一切送らない。2026年9月22日時点でstar 539・fork 52、バージョンは0.1.0でタグは未発行。本記事ではscripts配下の全ソースを読み、Linuxで単体テストとskill導入まで実際に動かした結果をまとめる。
- ・正体：Codexに入れるskillと、判定・ポリシー・ループのスクリプト群。全体で1,173行のJavaScript
- ・何ができる：画面の要素候補から操作対象と動作をJevに選ばせ、危険な操作をコードのしきい値で止める
- ・実測：単体テスト22件が全て成功（API呼び出しなし）。skillの導入と取り外しも確認
- ・注意：LICENSEの実体ファイルが無い。READMEは中国語のみ。ループ本体はCodexデスクトップとAPIキーが必要で未検証
判定を返すJevというモデル自体の設計はJevとは｜文章を返さないSystem Oneモデルの正体を公式SDKのコードで実測し、Claude Codeで試すで扱った。モデルの位置づけを含む全体像はLLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版にまとめている。
Jev-cuとは——Computer Useの判断だけをJevに渡すskill
Computer Useを実装するとき、素朴な作り方は「画面のスクリーンショットをマルチモーダルLLMに送り、次の操作を文章かJSONで書かせる」になる。Jev-cuはこれを2つに分解する。画面を読むこと・実際に操作することはCodexのComputer Useランタイムに任せ、「次に何をするか」の判断だけをJevに投げる。
リポジトリの構成はREADMEに書かれたとおりで、実際にcloneして数えると次のようになっていた。
| ディレクトリ／ファイル | 実測行数 | 役割 |
|---|---|---|
scripts/loop.mjs |
387行 | 決定ループ本体。候補の整形と実行の橋渡し |
scripts/jev-decide.mjs |
245行 | Jevへ送る質問の組み立てと応答の正規化 |
scripts/policy.mjs |
103行 | ポリシー門。純関数で副作用なし |
scripts/p0-eval.mjs |
89行 | 保存済みAX断面に対する離線評価 |
scripts/install-skill.mjs |
55行 | skillのインストールと取り外し |
skill/jev-cu/SKILL.md |
55行 | Codexに読ませる運用手順と安全規則 |
tests/core.test.mjs |
294行 | 単体テスト |
規模としては小さい。スクリプト群とSKILL.mdを合わせて934行、テストを含めた全JavaScriptで1,173行だ。フレームワークではなく、既存のComputer Useランタイムに差し込む薄い層として設計されている。
READMEは中国語のみで書かれている。ただし目標文字列については「英文目标，Jev 英文最准（目標は英語で書く。Jevは英語が最も正確）」と注記があり、実際にscripts/jev-decide.mjsがJevへ送る質問文はすべて英語だ。日本語や中国語のUIを操作する場合でも、ゴールの記述は英語で書くのが作者の想定になる。
`package.json` には `"license": "ISC"` と `"private": true` が書かれているが、2026年9月22日時点のリポジトリに LICENSE ファイルは存在しない。バッジも無く、GitHubのサイドバーにもライセンス表示が出ない。star 539の規模でこの状態なので、業務で使う前に実体ファイルの追加を作者へ確認したほうがよい。
仕組み——Jevに投げる4つの質問と、返ってくる確率
scripts/jev-decide.mjs を読むと、1回の判断でJevに送っている質問が正確に分かる。4つだ。
role: label の一覧"] --> B["criteria を i0, i1, i2 ... に採番"] B --> C["target
choice: どの要素を操作するか"] B --> D["action
choice: 9種類の動作から選ぶ"] B --> E["done
noul: 目標は達成済みか"] B --> F["risk
noul: 明示的な確認が要るか"] C --> G["normalizeDecision
i番号の妥当性を検査"] D --> G E --> G F --> G G --> H["policy gate へ"]
第1の質問 target は、候補要素からの選択だ。実装は候補ごとに i0 i1 i2 … というキーを振り、role: label の文字列を説明として渡す。Jevはこのキーの上の確率分布を返すので、存在しない要素を指すことが構造的に起きない。返り値は normalizeDecision が /^i\d+$/ に合致するかと、実際に候補に存在するキーかを検査してから通す。二重の担保になっている。
第2の action は動作の種類で、選択肢は9つ固定されている。click_element（選んだ要素をクリック）、click_at（座標指定のクリック）、drag、set_value（入力欄の値を置換）、type_text、press_key、scroll、wait、そして ask_user（止めて人に聞く）だ。最後の選択肢が動作の一つとして並んでいるのが、この設計の性格をよく表している。
第3の done は「現在の画面で目標はすでに見た目上達成されているか」を聞くyes/no。第4の risk は「次の操作は明示的な確認が必要か」で、質問文には削除・送信/提出・支払い/購読・権限変更・アップロード/共有・CAPTCHA・ソフトウェアのインストール・システム設定の変更・認証情報の入力が列挙されている。
ここで効くのがJevの性質だ。返ってくるのは文章ではなく確率なので、「たぶんこのボタンです」といった曖昧な文を解釈する必要がない。数値がそのまま次の分岐条件になる。
候補の作り方にも実装上の工夫がある。scripts/loop.mjs の selectCandidates() は候補数の上限を既定40に切っており、超えた場合は役割と関連度で並べ替えてから切り捨て、切り捨てが起きたことをログに残す。候補が2件未満しか取れなかったときは画面をもう一度フル観測し直し、それでも足りなければ no_candidates として記録する。同じく buildContext() は画面のテキスト行を既定6行までに絞って状態文に載せる。Jevに渡す情報量を、質問側でも状態側でも上限を決めて抑えているのが一貫した方針だ。ループの上限ステップ数は既定30で、READMEのサンプルが5に落としているのは試運転のためだろう。
ポリシー門——しきい値と敏感語で操作を止める
Jevの答えをそのまま実行に流すのではなく、scripts/policy.mjs の evaluatePolicy() が間に入る。ファイル冒頭のコメントは「Computer Useの確認方針をコードの門としてエンコードする。純関数・副作用なし・cuaランタイムから切り離して単体テストできる」と書いている。実際、テストがAPIなしで走るのはこの設計のおかげだ。
門が返す判定は5種類で、proceed（実行）、done（終了）、confirm（人の確認待ち）、escalate（再試行・別手段・人へ）、stop（中止）。判断に使うしきい値は既定値がソースに直接書かれている。
| しきい値 | 既定値 | 意味 |
|---|---|---|
doneProbability |
0.9 | 完了確率がこれ以上なら終了 |
riskConfirm |
0.2 | リスク確率がこれ以上なら確認で止める |
minConfidence |
0.5 | 目標の確信度がこれ未満なら escalate |
lowRiskMinConfidence |
0.4 | 副作用のないAppでは0.4まで緩める |
stopConfidence |
0.3 | 確信度がこれ未満なら即停止 |
リスク側のしきい値が0.2と低いのが要点だ。5回に1回の確率で「確認が要る」と判定されただけで止まる設定になっており、誤爆より取りこぼしを嫌う方向に倒してある。
しきい値とは別に、ラベル文字列そのものを見る敏感語の検査もある。7分類が正規表現で定義されており、いずれも中国語と英語の両方を拾う。
・delete：削除・移除・清空・delete・remove
・send：発送・提出・発布・回復・send・submit・post・reply
・payment：支付・購買・下単・充値・訂閲・pay・purchase・buy・subscribe・checkout
・auth：授権・権限・登録・密碼・験証碼・authorize・sign in・login・password・captcha
・share：上伝・分享・導出・upload・share・export
・install：安装・install
・settings：系統設置・偏好設置・安全設置・system settings・security settings
日本語のラベルは正規表現に含まれていない点に注意したい。「削除」「送信」「設定」のような日中で共通する漢字語は引っかかるが、「支払う」「ログイン」のようなかな・カタカナ混じりの表記は現状の7つのパターンでは拾えない。日本語UIで使うなら、SENSITIVE_LABEL_PATTERNS に自分で追記する前提になる。
App側にも門がある。DEFAULT_ALLOWED_APPS は Calendar・Calculator・TextEdit・NetEaseMusic・Figma・Google Chrome・Codex In-app Browser の7つで、READMEは「新しいAppを足すには明示的にこのファイルを書き換える必要がある」と書いている。このうち Calculator・Calendar・TextEdit・Figma は LOW_RISK_APPS として「副作用がなく何度でもやり直せるApp」に分類され、確信度のしきい値だけが緩められる。安全性はリスク判定と敏感語で担保し、確信度の緩和とは分けて考える、という整理だ。
実測：Jev-cuの単体テストとskill導入まで
ここからは2026年9月22日にLinux（x86_64・Node.js 22系）で実際に動かした結果だ。Codexデスクトップアプリが無い環境なので、動かせたのはAPIを呼ばない範囲に限られる。
git clone https://github.com/Sac-Y/Jev-cu.git
cd Jev-cu
npm test
結果は22件中22件が成功、失敗0・スキップ0、所要244ミリ秒だった。依存パッケージが1つも無く（package.json に dependencies の記載が無い）、Node標準の node --test だけで走るので、インストールの手間も無い。ポリシー門が純関数で書かれているため、判定ロジックの大半がAPIキーなしで検証できる構成になっている。
次にskillの導入を確認した。
npm run install-skill
# 已复制安装：/path/to/Jev-cu/skill/jev-cu → /root/.codex/skills/jev-cu
npm run uninstall-skill
# 已卸载：/root/.codex/skills/jev-cu
~/.codex/skills/jev-cu/ に SKILL.md と references/runtime.md・references/calendar-demo.md の3ファイルが展開された。READMEが書いているとおり、skill内の `` プレースホルダは実際のクローンパスへ置換されており、置換後のファイルに REPO_DIR の文字列は1つも残っていなかった。取り外しも1コマンドで、ディレクトリごと消える。
検証環境：Linux（x86_64・Codexデスクトップなし）／2026-09-22／Jev-cu 0.1.0（main・e2cc92d）。確認したのは単体テスト・skill導入・取り外し・ソース読解の4点。決定ループ本体（runTask）と離線評価（npm run p0）は未検証。前者はCodexデスクトップの cua_repl ランタイム、後者は TYPESAFE_API_KEY を必要とする。
実際の利用はCodexデスクトップのランタイム内でこう書く、とREADMEにある。以下は実行していない。
// 未検証：Codex デスクトップの cua_repl ランタイム内で実行する
const { runTask, createCuaDriver } = await import(
pathToFileURL(`${repo}/scripts/loop.mjs`).href
);
await runTask({
driver: createCuaDriver(cua),
appName: "Calendar",
goal: "switch the calendar to the previous month",
dryRun: true, // 確認してから false にする
maxSteps: 5,
});
dryRun: true が既定で、READMEも「まず確認してから false にする」と書いている。実行されるまでに、dry-runという初期値・ポリシー門・Appホワイトリストの3枚の壁がある構成だ。
リポジトリには fixtures/ax/ として Calendar・Calculator・NetEase Music の3つのアクセシビリティ断面が保存されている。行数を数えると計算機が38行、カレンダーの月表示が84行、NetEase Musicのホーム画面が353行で、合計475行。要素の役割とラベルがインデント付きのテキストで並ぶ形式だ。fixtures/p0/cases.json にはこの断面に対する期待選択が12ケース入っている。npm run p0 はこの保存済み断面に対して実際にJevを呼び、要素選択の正解率を測る離線評価だ。APIキーが要るため今回は回していないが、ランタイムなしで判定精度だけを測れる仕組みが最初から入っているのは、この種のツールとしては珍しい。
使う前に確認すべきこと——前提・制約・安全境界
導入判断に関わる制約を整理しておく。
第一に前提環境が狭い。Codexデスクトップアプリの cua_repl ランタイムが必要で、READMEのデモはmacOSのApp（Calendar・Calculator・TextEdit）を対象にしている。Linuxサーバやブラウザ単体で動かすものではない。
第二に判定はホスト型サービスに出る。送るのは画像ではなく要素のラベル文字列だが、テキスト自体は外部APIへ渡る。画面に個人情報や社内文書が表示されている状態で回せば、その文字列は送信対象になる。「スクリーンショットを送らない」ことと「何も送らない」ことは違う。
第三に日本語UIへの対応は自分で足す必要がある。前述のとおり敏感語の正規表現は中国語と英語だけで、Appホワイトリストも中国語圏のAppを含む7つだ。
安全境界についてREADMEが明示している方針は3点ある。UIの文字列はデータとして扱い指示としては扱わないこと、ログイン・有料壁・CAPTCHAを迂回しないこと、そしてホワイトリスト外のAppでは動かさないこと。1点目はUIに仕込まれた文言でエージェントを乗っ取るタイプの攻撃を意識したものだ。設計としては妥当だが、当方はループを動かしていないので実際の耐性は確かめていない。
skill/jev-cu/SKILL.md には、Codexに読ませる「適用範囲」の節がある。ここが率直で、導入判断に一番効く。適するのは文字のはっきりしたGUIコントロールから次の一手を選ぶ場面であり、キャンバスのレイアウト・3Dモデリング・視覚的な品質判断には向かないと明記されている。さらに「通常のタスクは信頼できるCLIやAPIがあるならそちらを優先し、GUI経路はユーザーが明示的に操作デモや対照実験を求めたときに残す」とある。目標と動作がすでに分かっている場合はJevを呼ばずCodexが直接操作する、という指示も入っており、判定の往復を増やさない設計になっている。ブラウザでのまとめ判断と詳細確認については「ローカルで実験中であり、検証済みの高速化能力としては公開しない」と書かれていた。できることよりできないことを先に書いてあるskillは珍しい。
APIキーの扱いも SKILL.md に書かれている。.env.local か環境変数の TYPESAFE_API_KEY を参照し、存在の有無だけを確認して値は出力しない。skillの本文を書き換えたら node scripts/install-skill.mjs で再同期し、二重管理しないこと、という運用上の注意も添えられている。
Jevを使った他のOSSがどの層に何本あるかはJev対応OSS 11選｜ブラウザ操作・MCP・コードレビュー・Claude Code文脈選別まで実測で見る使いどころに一覧がある。同じ「生成でなく選択で動かす」発想をブラウザ操作に適用した例としてはjev-ultrafastとは｜ブラウザを生成でなく選択で動かすエージェントを全ソース1,094行で実測が近く、Jev-cuはその考え方をデスクトップアプリ操作へ持ち込んだ位置づけになる。
まとめ——Jev-cuは何を示す実装か
Jev-cuの価値は機能の多さではなく、Computer Useの安全境界をプロンプトではなくコードに置いたことにある。どの要素を選ぶかは候補インデックスの確率、実行するかどうかは5つのしきい値と7分類の正規表現。どちらもリポジトリの103行のファイルを読めば全部分かる。プロンプトに「危険な操作の前には確認してください」と書く方式と比べて、何が起きるかの予測可能性が高い。
待ったほうがよい：ライセンスの実体ファイルが必要な業務利用（現状は未整備）。Codexデスクトップを使わない環境。日本語UIをそのまま操作したい場合（敏感語の追記が前提）
今回確かめられたのは、APIを呼ばない範囲の健全性までだ。テストは22件すべて通り、skillの導入と取り外しは宣言どおり動いた。一方で、実際に画面を操作するループの挙動と、要素選択の精度（npm run p0 が測る部分）は未検証のまま残っている。手元で評価するなら、まず npm test を通し、次にAPIキーを入れて npm run p0 を保存済み断面に対して回し、それから dryRun: true のまま実機のCalendarで試す、という順序が安全だ。
参照ソース
・Sac-Y/Jev-cu（公式リポジトリ） — README・package.json・scripts/policy.mjs・scripts/jev-decide.mjs（2026-09-22時点で確認）
・TypeSafe（Jev 提供元） — System Oneモデルと判定APIの提供元
・skill/jev-cu/SKILL.md（適用範囲と安全規則） — Codexに読ませる運用手順の本文
