TypeSafe AI ／ System One ／ Jev

Jev を「依頼の振り分け係」として
作業環境に組み込んだ記録

文章を書くAIではなく、型付きの判断だけ返すAIモデル Jev を、Mac 上の既存の作業環境（Claude Code／Codex／Obsidian）に外部API接続で最小実装した。何ができて、何ができず、いくらかかり、明日からどう使うかをまとめる。

調査日: 2026-09-21 検証日: 2026-09-21 更新: 2026-09-21 第3版（実API評価反映） 対象モデル: jev-1.13.0（alias jev-latest） 実装: Python 3.14／標準ライブラリのみ

①最初に結論

導入判断（2026-09-21 第3版）: 「限定した用途で試験運用を継続」。
Jev はこのPCの外側（米国のAPI）で動く。導入方式はローカル推論ではなく外部API接続で、モデルのローカル実行やセルフホストは公式に提供されていない。 本人がAPIキーを設定し、Jev 実API（jev-1.13.0）で架空44件を評価した。案件は44／44、作業種別は41／44で期待と一致。着手可と判定した22件のうち誤りは0件で、「配信しておいて」「複数案件」「共有だけ」などの罠サンプルもすべて要確認に回った。 一方、期限の読み（イベント日付を期限と読まない、「明日」を強い急ぎと読む）は4件ずれ、曖昧な「例の件、進めて」を相談扱いにするなど、判断を任せきれる精度ではない。 使いどころは「曖昧な依頼」「複数件の整理」「明示した時」に限り、普段の明確な依頼では既存Skillへ直接進む。

ローカル実装

完了

CLI・設定・ルール代替・ログ・予算ガード・単体テスト29件合格

Jev 実API検証

完了

架空32件＋未使用12件をライブ必須モードで評価。代替混入0、失敗0

Claude Code での利用

確認済

新規セッションで /依頼トリアージ を検出しCLIを呼び、結果を読めた（8.9秒）

Codex での利用

確認済

新規セッションで同じSkillを検出しCLIを呼び、結果を読めた（36.7秒）

Cloudflare 公開

完了

このページ（第3版）。公開用ディレクトリだけを直接アップロード

このPCでできるようになったこと

②Jev とは

TypeSafe AI が 2026年9月に公開した System One モデル の第1弾。通常のLLMが「文章を生成する」のに対し、Jev は state（判断材料）と typed questions（型付きの質問）を受け取り、選択肢ごとの確率だけを返す。文章・コード・説明は一切生成しない。

何を入力して何を返すか

質問の型聞くこと返るもの今回の使いどころ
Choice定義した選択肢のどれか選択＋各選択肢の確率＋confidence案件（12＋none）、作業種別（13種）
Score順序付きレベルのどこか期待値スコア＋各レベルの確率＋confidence緊急度（3段階）
NoulYes／NoYesの確率（0〜1）。confidenceは付かない期限明記・外部反映・情報不足・依頼か否か

複数の質問を1リクエストにまとめて送れる。各質問は同じ state に対して並列・独立に評価される（公式: 質問を増やしても応答時間はほぼ変わらない）。

Claude Code／Codex との役割分担

Jev が担う

「これはどの案件か」「配信文の依頼か添削か」「今日中と書いてあるか」のような数秒で判断できる分類。速く・安く・型が保証される。

Claude Code／Codex が担う

文章を書く、コードを直す、理由を説明する、複数の手順を考える。生成と推論はこちら。Jev はその前段の「振り分け」。

通常のコードが担う

文字数、日付の前後比較、金額計算、正規表現で拾える情報。公式が「Jev は計算機ではない」と明記している領域。

できること・できないこと（公式根拠つき）

項目公式の記述（2026-09-21確認）
入力テキストのみ（文字列・JSONオブジェクト・配列）。画像・音声・動画は不可
文脈上限1リクエスト 64k トークン。state＋最長の質問で 32k
日本語「英語が主要な学習言語。CJKを含む他言語は扱えるが同等の精度ではない。自分のデータで試し、confidence に注意せよ」
料金入力 $0.042／百万トークン。出力は無料
レート制限25万トークン/秒・1,200リクエスト/分。「需要が多く予告なく変動する」と明記
データ顧客の入力で学習・微調整しない。サービスは米国ホスト。エンタープライズ向けにゼロデータ保持あり
カスタマイズアカウント別の重み・ファインチューニングは無い。state と質問文で調整する
苦手（jev-1.13 の公式「jaggedness」）文字通りの読解、数え上げ・計算、日付の前後比較、多段の間接推論、無関係な情報だらけの大きなstate、敵対的な入力、矛盾した指示、文章生成
ローカル実行提供なし。同一の重みを全アカウントにAPIで提供
Confidence の正しい読み方

Choice／Score の confidence は「確率分布がどれだけ1点に集中しているか」から計算した統計量で、その回答が正解である確率ではない。公式も「較正はグループ全体で測るもので、個々の回答が正しいことを保証しない」と明記している。

Noul の値が 0.5 付近なのは「YesとNoが同程度」という意味であり「中くらいの強さ」でも「自信がない」でもない。今回の実装では 0.7 以上を yes、0.3 以下を no、その間を「不明→要確認」として扱う（閾値は設定ファイルで変更可）。

また、Noul と Yes/No の Choice、ある質問とその否定の Noul は数値が一致する保証がない（公式に例示あり）。閾値を型をまたいで流用しない。

③このPCとの相性

実機（実測）

Apple M5 / 32GB

macOS 27.0、空き容量 78GB、arm64

開発環境（実確認）

Python 3.14.6

Node 24.15、npm 11.12、Claude Code 2.1.278、Codex CLI 0.154.0

結論

導入可

API接続なので GPU・メモリは無関係。制約は「キーの有無」と「通信」

何が本当の制約か

観点評価備考
処理負荷ほぼゼロローカルで動くのは正規表現とJSON整形だけ。1件 0.1ms 未満（実測）
通信（認証エラー応答）実測 432〜475ms日本のこのPCから米国APIへ、キーなし／無効キーで送った時の往復。TLS込み。推論は走っていないので、正常判定の時間には使わない
通信（正常な判定）実測 中央値 544ms／P95 722ms32件評価（成功31件）のAPI往復。未使用12件では中央値 533ms／P95 988ms（最大1.17秒）。公式の「70〜500ms」は米国西海岸から測った条件付きの公表値で、日本からは往復分が上乗せされている
データ送信要注意依頼文が米国へ送られる。メール・電話・URLは送信前に伏せ字化。顧客の実メッセージを送る運用は本人の判断が必要
費用極小（実測）1件あたり入力 約2,300トークン＝約$0.0001（32件評価の平均）。累計$1で自動停止
保守軽い依存パッケージなし、常駐なし。モデル更新で alias が動くので、閾値を本気で調整したら版をピン留めする

指示ファイル（AGENTS.md／CLAUDE.md）との関係

共通ルールの正本は AGENTS.md のまま。Claude Code 側は既存の入口（~/.claude/CLAUDE.md の @import 1行、会社フォルダは AGENTS.md へのシンボリックリンク）を再利用し、新しい CLAUDE.md や複製は作っていない。今回追加したのは道具フォルダ1つと、公式Skillへのリンク1本だけ。

公式 Agent Skill は Claude Code のプラグイン機構で導入（typesafe@typesafe-ai v0.5.7）。Codex は公式ドキュメント（2026-09-21確認）でユーザー用Skillの探索先を ~/.agents/skills と定めているので、そこからプラグインのマーケットプレイス実体（git clone、バージョン別キャッシュではない）へシンボリックリンクで参照し、コピーを増やしていない。この公式Skillは「Jevを使う実装のための知識」で、依頼トリアージを呼ぶ入口（/依頼トリアージ）とは別物。

④私の業務に合う活用候補

5つの候補を「効果・頻度・実装負担・誤判定リスク・データ送信リスク」で比べ、D＋B（依頼の振り分け）を最初の1本にした。

候補置き換える判断頻度誤判定の影響送信リスク状態
D＋B 依頼の振り分け「これはどの案件で、何の作業で、急ぎで、何が足りないか」を読んで既存Skillを選ぶ毎日・複数回小（提案のみ、要確認に倒れる）中（依頼文を送る。伏せ字化あり）実装済
C 配信文・LP・SNSの事前チェック「CTAが明確か」「対象読者に合うか」「必須項目が揃っているか」週数回中（見落としは最終確認で拾える）中〜高（原稿本文を送る）未実装・次点
A Obsidian資料の分類支援保存先候補・既存カテゴリとの適合週数回小（提案のみ）中〜高（資料本文を送る）未実装
E ダッシュボード補助コードで出した検出結果へのカテゴリ付け週1小低（数値と短い説明だけ）未実装

選んだ理由と、導入前／導入後

導入前

依頼文を読んで、案件・作業・急ぎ・不足を頭で判断し、どのSkillやコマンドを使うか毎回決める。Claude Code／Codex に丸投げすると、Skill一覧を全部読み込んでから選ぶため遅く、間違ったSkillを選ぶこともある。

導入後

依頼文を1コマンドに通すと、案件・作業種別・緊急度・不足・外部反映の判定と、実在するSkill／コマンド候補が返る。判定に迷いがあれば「要確認」と理由が出る。本人かメインAgentが最終判断して着手する。

人が確認する部分

「要確認」になったもの全部。外部への送信・公開・予約を伴う依頼は必ず本人承認。案件が複数書かれているもの。判定確度が中程度のもの。

「単純なルールで足りる処理には Jev を使わない」を守るため、空入力・案件別名の一致・期限語の検出・伏せ字化はコードで行い、Jev には意味判断だけを送る。

⑤実装した仕組み

処理フロー

1 入力依頼文（--text／--file／標準入力）
2 ローカル前処理空入力は即「対象外」。メール・電話・URLを伏せ字。先頭4,000文字まで
3 ルール処理案件別名の一致、期限・急ぎ語、送信語、依頼語を正規表現で検出
4 Jev へ送信state＝{request} と7つの質問を1リクエストで。タイムアウト15秒・リトライ2回・予算ガード
5 回答の検証型・選択肢・範囲を検証。不正なら破棄してルール代替へ
6 振り分け閾値で act／confirm／consult／out_of_scope。候補Skillは実在確認して提案
7 引き継ぎ人またはメインAgentが最終判断。送信・移動はしない

実線＝外部API、点線＝このPC内。Jev を呼ぶのはステップ4だけ。キーが無い・失敗したときは4→5を飛ばして3の結果だけで振り分ける。

採用した最小構成

既存環境とのつながり

接続先どうつながるか状態
既存Skill／コマンド／Agent作業種別ごとの候補を設定に持ち、ファイルが実在するものだけ提案する。存在しない名前は提案から除外して理由を出す動作確認
案件台帳案件の別名一致をコードで先に取り、Jev の判定と食い違えば「要確認」動作確認
Claude Code/依頼トリアージ（会社の .agents/skills/ に置いた明示起動専用Skill）から CLI を呼ぶ。新規セッション（claude -p）で検出・実行・結果の読み取りを確認動作確認
Codex同じSkillファイルを Codex 公式の探索先（リポジトリの .agents/skills）から検出。新規セッション（codex exec）で実行・結果の読み取りを確認動作確認
Obsidian 実行記録既存の記録手順で今回の決定・未解決を記録記録済

Skill 読み込みは減ったか（区別して書く）

Claude Code の公式ドキュメント（2026-09-21確認）では、Skill は説明文だけが常に文脈に入り、本文は呼び出された時に読み込まれる段階的な仕組み。今回の /依頼トリアージ は「本人が呼んだ時だけ」動く設定（disable-model-invocation: true）にしたので、既存の Skill 一覧や本文の読み込み量は増えても減ってもいない。TypeSafe の公式クックブックにある「Skill 提案で誤った Skill 読み込みが半減した」という数字は、別の環境・別のロスターでの公表値で、このPCでは未測定。「Jevの追加で Claude Code／Codex が速くなった・軽くなった」とは言えない。

「導入しただけ」と「実際に動いた」の区別
  • 動いた ローカル前処理、ルール代替経路、振り分け、実在確認、予算ガード、ログ、単体テスト24件、架空サンプル32件のルール評価。
  • 動いた 実APIへの到達（キーなし→403、無効キー→401 を実通信で受信。費用ゼロ）。
  • 動いた Jev 本体の判定（架空44件、ライブ必須モードで代替混入0）。
  • 未着手 実データでの運用、月次の効果測定。

⑥明日からの使い方

0. 最初の1回だけ（本人操作）

  1. TypeSafe のコンソールで API キーを発行する（サインアップ・早期アクセスの条件はコンソールで確認）。
  2. 同梱の キー設定.sh を実行し、非表示入力で貼り付ける。~/.config/typesafe/api_key に 700／600 で保存され、既存があれば上書きしない。チャットやコマンド引数にキーを貼らない。
cd "$COMPANY/自動化/Jev依頼トリアージ" && ./キー設定.sh

1. 依頼文を判定する

cd "$COMPANY/自動化/Jev依頼トリアージ"
/opt/homebrew/bin/python3 triage.py --text "案件Aの来週の配信文、今週中に初稿お願いします"

出力例（実APIの実行結果。キーが無い時は判定元が「ルール代替経路」になり、情報不足を判定できないため要確認になる）:

判定: 着手可（提案あり）   [判定元: Jev jev-1.13.0]
作業種別: LINE配信文・シナリオ制作 (line_message, 確度 1.0, ok)
案件: a (確度 1.0, ok)
緊急度: mid  期限明記: yes  外部反映: no  情報不足: no  依頼か: yes
提案する入口:
  - skill: line-message-writing
  - command: 配信文作成
usage: in=2290 out=340 cost=$9.6e-05 API 540ms / 全体 541ms

2. Claude Code／Codex から使う（明示起動のみ）

どちらのツールでも /依頼トリアージ と打って依頼文を渡す。使う場面は「明示した時」「分類が曖昧な依頼」「複数件をまとめて整理する時」に限る。案件と作業がはっきりしている普段の依頼では呼ばない（既存の制作Skillへ直接進む方が速い）。route が confirm でも、会話や既存資料で分かることはメインAgentが自分で解決し、本当に分からない事実だけ本人に聞く。

/依頼トリアージ 案件Aの来週の配信文、今週中に初稿お願いします

3. 失敗したときの確認先

4. 止め方・元に戻す方法

サンプル表示: 判定結果の見え方

事前計算した架空の依頼文の判定です（Jev 実API jev-1.13.0 の実行結果を転記。このページを開いても API は呼ばれません）。案件名は伏せています。


⑦実測結果と費用

Jev 実API（jev-1.13.0）で、架空32件＋未使用12件を評価した。 ライブ必須モードで実行し、成功43件・空入力によるローカル判定1件・ルール代替0件・API失敗0件・予算上限による未実行0件。下の数値は「作成した架空サンプルの期待ラベルとの一致」であり、実業務全体の精度でも第三者評価でもない。期待ラベルは初版から変更していない。

測定条件

ルール経路 vs Jev 経路

指標ルール経路（32件）Jev 初版質問（32件）Jev 修正後（調整用32件）Jev 修正後（未使用12件）
案件の一致32／3232／3232／3212／12
作業種別の一致22／3231／3230／3211／12
振り分け先（route）の一致7／3211／3226／329／12
緊急度の一致24／2823／2823／288／8
人の確認へ回した件数30／3226／3211／322／12
確認不要（着手可）とした件数00166
着手可のうち、案件か作業種別が誤っていた件数——0／160／6
本来確認が必要なのに着手可とした件数0000
API 所要時間（成功時のみ）—中央値 525ms／P95 678ms中央値 544ms／P95 722ms中央値 533ms／P95 988ms
全体所要時間（CLI起動＋前処理＋API＋後処理）中央値 47ms中央値 608ms中央値 687ms未計測
入力トークン／概算費用0／$065,413／$0.002871,117／$0.003027,503／$0.0012
エラー・再試行・未実行0／0／00／0／00／0／00／0／0

「着手可」は「案件が確定・作業種別の確度が閾値以上・対象と文脈が書かれている・外部反映の疑いなし」がすべて揃った時だけ。閾値は初版のまま（Choice 0.6／Noul 0.7・0.3）。緊急度の期待ラベルは4件で意見が分かれる内容（イベント日付を期限と読むか、「明日」を強い急ぎと読むか）で、変更せずそのまま載せている。

質問文を直した理由と、直す前後の違い

初版の「この依頼を実行するのに必要な情報が明らかに欠けているか」という Noul は、基準に「対象の資料やURLが示されていない」と書いていた。Jev はこれを文字通りに読み、URLの無い依頼をほぼ全部「不足=yes」（31件中29件、値 0.84〜0.97）にした。公式の失敗例一覧にある「文字通りの読解」そのもので、モデルの誤りというより質問の書き方の誤り。

公式の助言（一つの Noul に複数の条件を入れない、直接的に書く）に従い、「作業の対象が名指しされているか」「案件・対象者・用途のどれかが書かれているか」の2問に分け、コードで組み合わせた（両方 yes → 不足なし、対象が no → 不足、それ以外 → 不明で要確認）。閾値は変えていない。この修正に32件を使ったので、修正後の確認は新しい12件で行った。

Jev 経路の外れ方（修正後）
  • 保守的な外れ（要確認に倒れた）: 「配信文を添削、CTAが弱い」→ 案件・用途が書かれているかを 0.21 と低く読み要確認。「担当者宛の稼働報告メール、数字は後で」「今動いてるタスクの優先順位を整理」「タスクをNotionに落として順番を決めて」→ 対象物が名指しされているかを 0.13〜0.37 と読み要確認。人が読み直す手間は増えるが、誤って着手はしない。
  • 種別の取り違え: 「記事の下書きの言い回しを整えて」→ 期待 X・SNS、判定 添削。「ありがとうございます！」→ 期待 対象外、判定 判断不能（結果は要確認で無害）。
  • 相談扱い: 未使用12件の「例の件、進めてもらっていい？」を相談と判定（期待は判断不能→要確認）。Skill不要で回答する経路に入るので、メインAgentが「例の件」を会話から特定できなければ本人に聞く必要がある。複数案件を含む相談「どっちのLPを先にやるべき？」も相談扱いで、複数案件の確認は付かなかった。
  • 緊急度: 「9/30のセミナー告知用」「10/3のセミナー告知」の日付を期限と読まず low、「明日のミーティングの議事録を準備」を high。公式が注意する日付の扱いで、期限判定は本文の明示語に限る設計のまま、人が読む前提にしている。

API 到達確認（実通信、費用ゼロ。推論時間ではない）

条件HTTP往復時間クライアントの挙動
キーなし403475ms認証エラーとして扱い、ルール代替へ
無効なキー401432ms同上。リトライしない

認証で弾かれているので推論は走っていない。正常判定の時間は上の表（中央値 約0.53〜0.54秒）を見る。

Jev なしで Claude Code／Codex が Skill を選ぶ場合との比較（5件、新規セッション）

同じ5件の架空依頼を、Jev を使わずにそれぞれのツールへ「最初に使う既存Skill／コマンドを名前だけ答えて」と投げた。依頼を受け取ってから作業入口が決まるまでの総時間と選択を比べる。正解ラベルは本人が付けていないので誤選択の件数は未評価。

依頼（要約）Claude Code（Jevなし）Codex（Jevなし）依頼トリアージ（Jev 実API）
案件AのLINE配信文の初稿を今週中にline-message-writingline-message-writingline-message-writing／配信文作成（着手可）
案件Bの配信文を添削、CTAが弱いemotional-trigger-copywritingjapanese-copy-feedback配信文セルフチェック／japanese-copy-feedback（要確認）
案件Cの案内文を柔らかく修正copy-revision-agentcopy-revision-agent配信文セルフチェック／japanese-copy-feedback（着手可）
登録直後はアンケートか理念か（相談）line-funnel-diagnosisline-funnel-diagnosis相談・Skill不要
「あれ、お願いします」要確認要確認判断不能（要確認）
5件の総時間58.0秒（5ターン）12.8秒約0.7秒×5（CLI起動込み）
操作数プロンプト1回プロンプト1回コマンド5回（または /依頼トリアージ 1回ずつ）

Claude Code／Codex から /依頼トリアージ を呼んだ実測（1件、新規セッション）

ツール総時間結果参考
Claude Code（claude -p）8.9秒（2ターン）Skill検出 → CLI実行 → 判定元・route・入口2つを正しく報告API相当額の表示 $0.65（定額契約内。追加請求ではない）
Codex（codex exec）36.7秒同じSkillを検出 → CLI実行 → 同じ内容を報告45,749 トークン（Codex側）

どちらも「実際の作業には着手しない」指示を守った。この確認はキー設定前に行ったため判定元はルール経路だったが、Skill検出とCLI呼び出しの経路はキーの有無で変わらない。

費用（実測にもとづく）

公式料金（入力 $0.042／百万トークン、出力無料。2026-09-21確認）。実測では1リクエストの入力が平均 約2,300トークン（32件評価: 71,117÷31）。今日の実支出は Jev に対して約$0.007（78リクエスト）。

月間件数入力トークンJev 費用備考
100件23万約 $0.010リトライ2倍でも $0.02
500件115万約 $0.048—
2,000件460万約 $0.19毎日数十件のペース

Claude Code／Codex の定額契約費はこの導入で減らない。Jev の呼び出し1回ごとに Claude Code／Codex のターンも1つ消費する。

月間効果の試算（仮定による。実測ではない）

「導入前の総作業時間 − 導入後の総作業時間」で計算する。数値は同梱の 効果試算.py が出し、このページの表示と一致することをテストで確認している。

導入前 = N × t_manual
導入後 = N × t_wait                                … 全件: CLI起動＋通信待ち
       + N × (1 − p_auto) × (t_manual + t_read)   … 要確認に戻った件: 人が振り分け直す＋出力を読む
       + N × p_err × t_fix                         … 誤判定の修正（p_err の分母は全N件）
       + t_maint                                   … 月の保守
削減 = 導入前 − 導入後

前提: N=300件／月、t_manual=1分、t_read=20秒、p_err=5%（全件比。今回の架空評価では着手可22件中0件だったが、実業務では保守的に置く）、t_fix=3分、t_maint=30分、t_wait=1.5秒（実測のCLI込み 0.7秒＋読む時間）。着手可（自動処理）に回った件の通常作業は 0 とし、その代わり誤判定分を別計上して重複を避ける。

自動処理割合 p_auto導入前（分）導入後（分）内訳: 待ち／要確認／修正／保守削減（分／月）
30%300362.57.5／280／45／30−62.5
50%（架空評価の実測: 16／32、6／12）300282.57.5／200／45／3017.5
60%300242.57.5／160／45／3057.5
80%（p_err=8%）300189.57.5／80／72／30110.5

架空評価で出た着手可割合（50%）をそのまま当てはめると、月300件で約18分の削減にしかならない。振り分けの時短が目的なら導入する意味は薄い。価値があるとすれば「曖昧な依頼・複数件を、同じ基準で0.7秒で仕分けし、危ない依頼（送信・複数案件・共有だけ）を確実に止める」ところで、それは実業務で件数を積んでから判断する。

⑧制約と安全性

外部へ送られる範囲

依頼文本文（メール・電話・URLは伏せ字、先頭4,000文字まで）と、設定ファイルの質問文・選択肢。ファイルの中身・案件資料・チャット履歴は送らない。

判断を誤る可能性

日本語は公式に「精度が低い」と明記。文字通りに読む、日付比較が苦手、敵対的な文に引きずられる。だから提案止まりにし、確度が中程度以下は要確認に倒す。

人の確認を残す操作

送信・投稿・公開・予約・支払い・削除・設定変更は、Jev が「不要」と判定してもコードとして実行しない。要確認の理由文を必ず添える。

API停止・通信断のとき

15秒でタイムアウト、429／529／5xx は最大2回再試行（retry-after 尊重）。それでも駄目ならルール代替経路で必ず結果を返し、理由を表示する。

常駐・無制限実行

していない。呼ばれたときだけ1回。累計100リクエスト・累計$1・1実行40リクエストで自動停止（リトライも数える）。

秘密情報

キーは環境変数か権限600のファイル。ログ・出力・例外にキーと入力全文を含めない（テストで検証）。公開ページにもコード本文・設定・ログは含めない。

現在の未完了事項

⑨次に拡張するなら

  1. 実業務での試験運用と見直し（負担: 小）。曖昧な依頼・複数件の整理に限って使い、着手可の誤り件数を先に見る。要確認率（修正後 34%／17%）が高いと感じても、誤り件数が増えるなら閾値は緩めない。
  2. 候補C: 配信文の事前チェック（負担: 中）。「CTAが1つに絞れているか」「対象読者が明記されているか」「差し込みタグが使われているか」を Noul で並列に聞き、文字数・日付・価格の一致はコードで検証。既存のセルフチェック手順の前段に置く。
  3. 候補A: Obsidian 保存先の提案（負担: 中）。既存の受付フローに「保存先候補＋確度」を添える。移動はしない。

今はやらないこと: MCPサーバー化、常駐監視、自動送信、実データの一括投入、Jev による文章生成の代替。いずれも公式の得意領域から外れるか、承認境界を越える。

⑩出典と更新情報

確認日: すべて 2026-09-21。第2版（同日 21時台）で、認証エラー時間と推論時間の区別、効果試算の再計算（式と数値の不整合を撤回）、サンプル表示と判定基準の整合、Codex での実行確認を反映した。第3版（同日 21:30以降）で Jev 実API評価（jev-1.13.0、架空32件＋未使用12件）と質問文の修正理由を反映した。「公式公表値」「この環境での実測」「仮定による試算」を本文で区別している。SDK は導入せず（標準ライブラリで実装）。実APIの応答 model フィールドで確認したモデル版は jev-1.13.0（alias jev-latest 経由）。

公開版では固有のユーザー名・端末識別・絶対パス・案件名を除いている。本人用の正確な場所とコマンドは、道具フォルダ内の README に残している。