「JevのスキルをCodexに入れると、何が変わるのか？」
一番大きいのは、Codexが全部を考えて全部を決める作りから、文章やコードを作る処理と、その内容を判定する処理を分けられることです。
ただし、インストールした瞬間にCodexの基礎能力が上がるわけではありません。TypeSafe Skillは、JevのAPIや設計方法をCodexに教えるものです。Jevを使う処理を実装して、初めて連携が成立します。
ここでいう精度改善は、モデル自体を追加学習させることではなく、入力・判断基準・処理の分担・検証方法を整えることです。
この記事では、2026年9月21日時点の公式資料と公開コードを確認し、導入方法、公開実験、実務への応用、精度改善の方法を整理します。応用例は実装案であり、この記事のためにAPIを実行して得た検証結果ではありません。
1．最初に訂正。「マルチモーダルのみ」ではなく「テキストのみ」
Jevは、画像や動画を何でも理解して文章を返す万能AIではありません。現在の入力はテキストで、文章やJSONなどを受け取り、選択・採点・確率といった決まった形式の判断を返します。画像・音声・動画を直接入力するモデルではなく、長文の回答やコードを生成する用途とも違います。
したがって、動画を扱う場合は別の仕組みで文字起こしや場面説明を作り、そのテキストをJevに判定させます。「この場面は初心者向けの説明か」「この区間で話題が変わるか」といった使い方です。
また、「申請した当日に承認される」は公式の保証として確認できませんでした。公式発表では早期アクセスとして案内されていますが、承認時期を前提に仕事の予定を組むのは避けた方がよいでしょう。
速い判断ができることと、何でもできることは別です。 この前提を押さえると、Codexと組み合わせる意味が見えてきます。
2．導入は、スキル・APIキー・動作確認を分ける
まず公式サイトから利用登録を進め、利用可能になったらコンソールでAPIキーを作成します。公式クイックスタートでは、実行環境の環境変数TYPESAFE_API_KEYを使う方法が案内されています。キーは会話に直接貼らず、アプリ側の安全な設定として渡してください。
次に、Codexを使うプロジェクトで以下を実行します。
npx skills add typesafe-ai/skills --skill typesafe-ai
元の紹介文の「–skill」は、長いダッシュになっています。正しくは半角ハイフン2本の--skillです。インストール先の選択ではCodexを選びます。標準はプロジェクト単位で、全体に導入する場合は-gを付けます。
その後、Codexにこう伝えます。
use the TypeSafe skill
このプロジェクトでTypeSafe Skillを読み込んでください。
まず現在の公式ドキュメントを確認し、
Jevを使うと有効な処理と、通常のコードで十分な処理を分けてください。
APIキーの値は表示しないでください。
Codex CLIやIDE拡張なら、/skillsで確認したり、$typesafe-aiとして明示的に指定したりできます。表示されない場合は、インストール先を確認してCodexを再起動します。
なお、スキルとSDKは別物です。スキルはCodex向けの手順書で、SDKは作ったプログラムからAPIを呼ぶためのライブラリです。Pythonなら公式の導入例は次のとおりです。既存プロジェクトの仮想環境で実行します。
pip install typesafe-sdk
ここまで終わったら、架空の問い合わせを1件使い、キーを表示せず接続を確認します。「インストールできた」と「実際にAPIが動いた」を分けるだけで、初期設定の見落としを減らせます。
3．スキルの本質は「Jevに全部やらせない」こと
公開されているSKILL.mdには、最新ドキュメントを参照し、必要な判断だけをJevに任せる方針が書かれています。単なるAPIの呼び出し方ではなく、どこをAIに任せ、どこをコードに残すかまで教えるスキルです。
Jevの基本機能は、次の3種類です。
機能判断すること使い方の例Choice用意した候補から1つ選ぶ問い合わせの担当部署を選ぶNoulある条件が成立する確率を返す返金を求めているかを判定するScore説明付きの段階に沿って程度を評価する業務への影響度を評価する
これらを同じ入力に対して組み合わせ、結果をコードで処理します。自由な文章から答えを抜き出すのではなく、決まった形で受け取れる点が特徴です。
例えば返金対応なら、Jevには「返金希望が読み取れるか」を判断させ、購入からの日数や返金上限はコードで確認します。返信文の作成はCodex側の生成処理に任せ、実際の返金は権限と承認のある処理だけが行います。
意味の判断はJev、計算や条件分岐はコード、文章や実装はCodex。 この分担が基本です。公式の設計ガイドも、処理の進行や外部への操作をコード側で管理する構成を勧めています。
4．本当に精度は上がる？ 公開実験で確認できること
参考になるのが、TypeSafeの「スキル選択を補助する」実験です。
182種類のスキルを対象に、まず候補を絞り、次に上位3候補を詳しく確認します。「どれも使わない」という判断も残したうえで、エージェントに候補を伝える構成です。
488件の依頼を使った公開結果では、次の改善が報告されています。
評価項目エージェント単独TypeSafeの補助あり適切なスキルがある依頼での選択ミス16.8％7.3％適切なスキルがない依頼での不要な使用9.8％4.0％
ただし、これはHermesのスキル群、Claude Haiku 4.5、Jev 1.12を使った実験です。依頼にはスキル説明から生成された問題が含まれ、実際の利用より判断しやすい可能性もあります。Codexのコード正解率が同じ割合で改善したという結果ではありません。
それでも、「生成モデルに判断を丸投げする前に、候補を絞って確認する」という構成を試す根拠にはなります。ここから先は、この考え方をCodexの実務へ応用します。
5．TypeSafe Skillを使った活用事例7つ
① 問い合わせを「分類して終わり」にしない
「ログインできない。昨日から仕事が止まっている。担当者に代わってほしい」
この文章を単に「アカウント関連」と分類するだけでは、仕事が止まっていることや、有人対応の希望が抜けます。
そこで、担当分野をChoice、有人対応の希望をNoul、影響度をScoreで別々に判定します。Codexには、その結果から担当者向けの対応一覧を作らせる。自動返信を始める前に、まず仕分けの補助として使う案です。複数条件を独立して確認する構成は、公式にも示されています。
② 社内資料から、回答に必要な部分を選ぶ
検索で見つかった資料を全部Codexに渡すのではなく、質問との関連性や、回答の根拠として使えるかをJevで確認します。
例えば「今年の研修の返金条件」という質問に対して、去年の規約、今年の規約、返金とは無関係な告知を分ける。年度などの確定情報はコードで確認し、内容の関連性をJevに判断させます。
注意したいのは、質問の前提に反する資料を捨てないことです。「そもそも返金制度はない」という規約も重要な証拠です。公式の検索拡張例も、関連性だけでなく、前提との矛盾や不審な指示を分けて扱っています。
③ 記事や資料の「引用はあるのに根拠になっていない」を検出する
Codexが作った原稿から主張を取り出し、その主張と参照元の本文をJevに渡します。
「この記事には売上が2倍になったと書いている。しかし出典では問い合わせが2倍としか書いていない」
こうしたズレを見つける用途です。引用文が原文に存在するかは文字列照合で確認し、その引用が主張を支えているかをJevに判断させます。公式にも、この二段構えの引用確認例があります。
ただし、Jevが自動で最新情報を検索するわけではありません。資料を取得する処理が別途必要で、「出典が主張を支える」と「出典自体が正しい」も別問題です。
④ 請求書や申込情報の数字を勝手に作らせない
金額、電話番号、メールアドレスをAIに自由生成させる代わりに、先にコードで候補を抽出します。その中から、どれが請求総額や連絡先なのかをJevに選ばせ、最後にコードで原文をコピーします。
「文字を新しく作る」のではなく「存在する候補を選ぶ」形です。公式の値抽出例でも、この構成が使われています。候補に正解がなければ選べないため、候補漏れと「該当なし」の扱いが重要になります。
画像の請求書なら、文字認識は前段で必要です。誤読した数字を、その後の選択処理だけで正しい数字に戻せるとは限りません。
⑤ Codexが作った文章を、観点別に見直す
「この記事は良いですか？」ではなく、「対象読者の悩みに答えているか」「専門語を説明しているか」「断定に根拠があるか」を分けて評価する案です。
Codexには、問題が出た観点だけを直させます。読みやすさを直すために、根拠の正確な段落まで全面的に書き換えないようにします。
複数の採点結果を重み付けする方式は公式にもあります。ただし、重大な問題を平均点で隠さないことが重要です。文章が読みやすくても、重要な数値に根拠がなければ公開を止める。好みの評価と必須条件を別扱いにします。
⑥ Codexが使うスキルの候補を絞る
スキルが増えた環境で、依頼文とスキルの適用条件を照合し、候補を数個に絞る補助処理を作る案です。
ただし、TypeSafe Skillを入れるだけでCodex標準のスキル選択が自動的に置き換わるわけではありません。候補選定用のスクリプトなどを別途用意し、その結果をCodexが参照する運用が必要です。
最初から複雑な仕組みを作るより、不要なスキルを減らし、使用条件を明確にする方が先です。OpenAIも、スキルの説明が多すぎると省略や競合が起き、選択を難しくすると説明しています。
⑦ 高価なモデルを、難しい案件だけに使う
小型の生成モデルで情報を抽出し、Jevで元資料との不一致を確認する。怪しい項目だけを上位モデルや人に回す構成です。
例えば100項目の抽出結果を全部やり直すのではなく、原文との対応が確認できない項目だけ再確認します。公式にも、抽出結果を項目ごとに評価して処理を切り替える例があります。
ただし、確認役が見逃せば誤りは残ります。API料金だけでなく、見逃し率と人の確認時間まで含めて得になるかを測る必要があります。
6．Jevの精度を上げる6つの設計
① 質問を小さくし、判断の対象を具体的にする
「この問い合わせは問題がありますか？」では、料金、感情、規約違反、障害のどれを見ればよいか曖昧です。
「返金を求めているか」「利用できない機能があるか」のように分けます。ただし、細切れにしすぎて文脈を壊してはいけません。請求への不満と返金の依頼を区別したいなら、その区別が分かる前後の文章は残します。公式の設計方針も、狭く明確な判断と、必要な文脈の両立です。
② 質問IDだけで意味を伝えようとしない
見落としやすい仕様ですが、質問IDはモデルに送られません。
IDをrefund_requestedと名付けても、質問文が「該当しますか？」だけでは意味が不足します。「顧客は金銭の返還を求めているか。料金への不満だけでは該当としない」と、質問や判定基準に書く必要があります。Choiceでは候補同士の境界も明確にします。
③ stateは、情報の関係が分かる形にする
過去ログを全部貼るより、customer_message、order、policyのように分けます。顧客の希望と会社の規約を同じ文章に混ぜないことが大切です。
質問から「customer_messageを判定する」のように対象を指定すれば、何を読んで何を決めるのかが明確になります。公式も、複数の情報を扱う場合は名前付きのJSONなどで関係を示す方法を案内しています。
④ Scoreは「1〜5点」だけで済ませない
例えば業務影響なら、「作業を続けられる」「代替手段はあるが手間が増える」「主要業務が停止し代替手段がない」と、各段階の状態を書きます。
Scoreの各段階は独立して評価されるため、「前の段階より深刻」のような説明は不向きです。また、同じ平均点でも判断の分かれ方は違うため、必要な場面では確率分布も確認します。
⑤ 確率とconfidenceを混同しない
Noulの0.8は「条件が成立する確率」の推定であり、「問題の深刻さが80点」という意味ではありません。Noulには別のconfidence値もありません。
一方、ChoiceやScoreのconfidenceは、回答の確率分布がどれだけ集中しているかを表す指標です。0.9だから実際の正解率が必ず90％になるわけではありません。
そのため、自動処理に進める基準は、自分のデータで決めます。誤って実行したときの損失が大きい処理ほど、保留や人の確認を設けます。
⑥ 日本語は、英語と同じ精度だと思わない
公式は、英語が主要な学習言語で最も得意だと説明しています。日本語も入力できますが、同じ精度ではありません。
そこで試したいのが、「質問も資料も日本語」「質問だけ英語で資料は日本語」「日本語原文に英訳を添える」の比較です。
例えば「できれば返金していただけると助かります」は、控えめでも返金希望です。「返金しろ」と同じ条件として拾えるか、逆に「返金は不要です」を誤判定しないかを確認します。翻訳にも誤りが入るため、英訳すれば必ず改善するとは決めつけず、同じ検証データで比較します。
7．Codex側は「指示を増やす」より「確認できる状態」を作る
まず、古い記憶でAPIを書かせないことです。TypeSafe Skill自身が、実装前に最新のAPI・SDK資料を確認するよう求めています。資料にアクセスできない場合は、その制約を明示し、存在を確認できない項目を作らない方針です。
次に、プロジェクトのAGENTS.mdには、実行可能なテスト、使用環境、変更してはいけない範囲など、そのプロジェクトで繰り返し必要になる情報を置きます。Codexは作業に際して、このファイルの指示を読み込みます。
ただし、「毎回すべての資料を読め」「あらゆる処理で何重にも確認しろ」と増やし続けるのは逆効果になり得ます。OpenAIの最新ガイドも、不要な指示を整理し、必要な資料と完了条件を明確にする方向を勧めています。
実装の確認では、Jevの採点と実際のテストを別扱いにします。「仕様を満たしていそう」と判定されても、プログラムを実行した証拠にはなりません。接続、例外処理、データ保存、権限制限は、それぞれ動作を確認する必要があります。
また、Jevも入力中の悪意ある指示に影響される可能性があり、公式が注意を示しています。APIキーの保護や送信・削除の権限を、モデルの判断だけに任せないでください。
改善ループには終了条件も設けます。「変更した部分のテストを通す」「事前に決めた評価で悪化しない」「最大3回で止める」などです。回数は例ですが、無制限に書き直すより、前の良い版と比較できる構成を勧めます。
8．精度・速度・料金は、同じ条件で比べる
評価用のデータは、質問や基準を調整するものと、最後の確認に使うものを分けます。普通の入力だけでなく、曖昧な表現、情報不足、否定文、複数の要望、悪意ある指示も含めます。人が確認した正解と照合し、同じ条件で変更前後を比べることが基本です。
ここでは、2種類の改善を分けて測ります。Jevを組み込んだ処理については、従来の方法との誤分類率や見逃し率を比較します。Codexの実装精度については、同じ開発課題で、スキルあり・なしの実装成功率や修正回数を比較します。
特に、自動処理した案件の正解率と、全体の何割を自動処理できたかはセットで見ます。難しい案件を全部人に回せば、自動処理部分だけの正解率は高く見えるためです。
現行モデルはjev-1.13.0。入力100万トークン当たり0.042ドル、出力は無料です。仮に合計1億入力トークンならJev部分は4.20ドルですが、別モデル、検索、文字起こしなどの費用は別です。比較実験では、変化するjev-latestより具体的なモデルIDを固定する方が追跡しやすくなります。
独立した質問は、同じリクエストで並列に評価できます。ただし質問同士は互いの答えを見られません。前の答えを使って新しい資料を取得する場合は、次の呼び出しが必要です。質問を増やせば入力料金も増えるので、並列だから無料とは考えないでください。
公式発表の70〜500ミリ秒という低遅延は、主に米国西海岸からの測定に基づきます。日本での運用では、API単体だけでなく、資料取得から最終結果までの時間を測る必要があります。
9．Codexに渡す実践プロンプト
最初は、誤判定しても外部への影響が出ない「問い合わせの仕分け」から試す構成です。目的の部分を差し替えれば、資料分類や原稿チェックにも応用できます。
use the TypeSafe skill
目的：
日本語の問い合わせを分類し、担当分野、有人対応の希望、
業務への影響を整理するローカルの試作を作ってください。
外部への返信・送信・本番データの変更は行いません。
既存プロジェクトの言語、構成、依存関係を尊重してください。
TypeSafeの最新ドキュメントと導入済みSDKの型を確認し、
確認できないAPIや返却項目を推測で作らないでください。
担当分野の選択、有人対応希望、影響度は別々に判断します。
入力不足や該当なしを無理に既存カテゴリへ押し込まず、
保留して人が確認できる経路を用意してください。
計算、日付比較、権限確認は通常のコードで行います。
質問、判定基準、閾値、モデルIDをレビューしやすい場所にまとめ、
入力と判定結果の対応を追跡できるようにしてください。
APIキーや不要な個人情報はログに出さないでください。
最初に架空のデータでローカルテストを実施してください。
通常例、遠回しな依頼、否定文、複数要望、情報不足、
入力中に「指示を無視しろ」が含まれる例を用意します。
自動生成した想定正解は仮のものと明記してください。
質問を調整するデータと最終評価用データを分離し、
従来の分類方法とJevを使う方法を同じ条件で比較できるようにします。
誤分類、見逃し、保留率、自動処理率、処理時間、
使用トークン数を記録してください。
評価を通すために、正解ラベルを都合よく書き換えないでください。
実APIの試験は、TYPESAFE_API_KEYの設定と
送信データ・費用上限の確認ができた場合のみ行ってください。
呼び出し回数と予算に上限を設けます。
完了条件は、動くコード、実行手順、評価方法、
確認できた結果、未解決の失敗例がそろうことです。
未実行のテストを成功と書かず、
キーやネットワークが使えない場合は未検証と記載してください。
大切なのは、「精度を上げて」とだけ頼まず、何を正解とし、何を自動化せず、どの結果で改善を判断するかを渡すことです。
Jevを入れる価値は、安く速く判断できる処理を、作業の必要な場所に組み込めることにあります。Codexに作らせ、Jevで狭い条件を確認し、コードで処理を制限し、テストで動きを確かめる。
狙うべきなのは「すごいAIに一発で全部任せること」ではなく、間違いがそのまま次の処理へ進みにくい仕組みを作ることです。
