AIエージェントを使って開発していると、思った以上に「判断」にトークンを使っていることに気づきます。
コードを書く、設計を考える、バグの原因を探す。こうした仕事に高性能なAIを使うのは分かります。
しかし実際の開発では、その合間に、「テストは成功したか」「この処理は正常終了したか」「条件を満たしているか」「A、B、Cのどれに分類するか」といった、かなり単純な判断も大量に発生します。
そこまで全部Codexに考えてもらう必要があるのだろうか。そう思っていたところに登場したのが、判断専用のAIモデル「Jev」でした。
今回はChatGPTと相談しながら、CodexとJevを実際につないでみました。
Jevは「文章を書くAI」ではなく「判断するAI」
Jevの面白いところは、ChatGPTやClaudeのように文章を書いたりコードを生成したりするAIではないところです。
主な仕事は、YES/NO、成功/失敗、A/B/Cの選択、条件を満たしているか、リスクの段階判定といった、答えの範囲が決まっている判断です。
つまり「この機能を実装して」という仕事はCodex、「実装後のテストは成功したか」という判断はJev、という分業ができます。
うまく使えば、Codexが細かい判断まで抱え込む必要がなくなり、Codex側の利用量を抑えられる可能性があります。ただし、ここはまだ実験中です。「Jevを入れればCodexの消費量が劇的に減る」とまでは確認できていません。実際の開発で使いながら検証していくつもりです。
最初にChatGPTへ相談した
今回も、いきなり自分で設定方法を調べ始めたわけではありません。
ChatGPTに、「判断のみを行うAIエージェントJevが登場した。CodexやClaude Codeと連携すると、消費トークンを減らせるらしい。連携方法を教えてほしい」と相談したところから始まりました。
調べてもらうと、CodexからJevを利用するための仕組みとして、MCPを使った連携方法があることが分かりました。そこで今回は、いきなりClaude Codeまで設定せず、「まずCodexだけで試してみよう」という方針にしました。新しいツールを導入するときは、このくらい小さく始めた方が安全です。
まず開発環境の復旧から始まった
ところが、いきなり予定外のことが起きました。
ターミナルでCodexを確認しようとしたところ、Codexが見つかりません。Node.jsもnpmも見つかりませんでした。以前Macのトラブルがあった際に、Codex CLIが使えなくなっていたのです。さらに調べると、Homebrewも入っていない状態でした。
ということで、Jev以前に、Homebrew→Node.js→Codex CLIという順番で開発環境を復旧することになりました。少し遠回りになりましたが、結果的には開発環境を整理し直す良い機会になりました。
CodexからJevを呼び出せるようにする
Codexが復旧したところで、Jevとの接続設定を行いました。
仕組みとしては、Codex→MCP→Jev→TypeSafeのJev APIという流れになります。
最初は本物のAPIを使わず、モックモードで接続確認をしました。これで、「CodexからJevを呼び出すための配線そのものは正常か」を先に確認できます。
問題なかったので、その後TypeSafeのAPIキーを設定し、実際のJevへ接続しました。ここでJev単体では正常に動きました。
ただし、Codexから呼び出すと、「Jevの認証情報がない」というエラーが出ました。原因は、ターミナルに設定したAPIキーが、そのままCodexのMCPプロセスへ渡っていなかったことでした。CodexのMCP設定に、「この環境変数をJevへ渡す」という設定を追加したところ、無事に接続できました。
Codexから本当にJevを使ってみた
最初のテストは単純なものにしました。
テスト結果として、「42 tests passed」「0 tests failed」「exit code: 0」という情報を渡し、「テストは正常に成功したか」と判定させました。
するとCodexがJevを呼び出し、YESという判定が返ってきました。さらにconfidence、つまり判定の確信度も返ってきました。これで、Codex→Jev→判定結果→Codexという流れが実際に動いていることを確認できました。
しかし、そのままではCodexはJevを使わなかった
ここが今回かなり面白かったところです。
Jevを接続しただけでは、Codexが自動的に使ってくれるわけではありませんでした。Jevという道具は見えています。しかし「テストが128件成功、失敗0、終了コード0」くらいの簡単な問題だと、Codex自身がそのまま判断してしまいます。たしかにCodexからすれば、その方が簡単です。
とはいえ今回の目的は、「簡単な判断こそJevへ任せる」ことです。そこで、Codexのグローバルルールに、「YES/NOや成功/失敗など、答えの範囲が決まっている単純な判断はJevへ任せる」というルールを追加しました。
一方で、コードを書く、設計する、バグの原因を考える、複雑な推論を行う、文章を書くといった仕事はCodex自身に任せます。役割をはっきり分けました。
今度は「Jevを使って」と言わなくても使った
設定後、もう一度、「次のテスト結果を確認して、正常に完了しているか判断してください」とだけ指示しました。
今回は「Jevを使って」とは一言も書いていません。するとCodexは自分で「これは単純な判定タスクだ」と判断し、Jevを呼び出しました。ここでようやく、自動振り分けができました。
現在のイメージはこうです。Codexが設計や実装を行い、途中で「テストは成功したか」のような単純判断が出てきたらJevへ送ります。JevがYES/NOなどの判定を返し、Codexはその結果を受けて次の作業へ進みます。AIエージェントの中に、もう一つ小さな判断専用AIが入ったような感じです。
個人情報や機密情報はJevへ送らない
今回、もう一つ重要なルールを入れました。
Jevは外部サービスなので、判断対象の情報が外部へ送られます。そこで、パスワード、APIキー、認証情報、個人情報、社内の機密情報、秘密情報を含むソースデータなどはJevへ送らないようにしました。
必要であれば匿名化したり、判断に必要な部分だけ抜き出します。それが難しい場合は、Jevを使わずCodex自身で判断します。AIエージェントを便利にするほど、このあたりの境界線は重要になってくると思います。
Jevはいつでもオフにできる
今回設定していて気になったのが、「Jevの無料枠を使い切ったらどうする」ということでした。あるいは将来、もっと良い判断専用AIが登場するかもしれません。Codex自身に同じような軽量判定機能が搭載される可能性もあります。その場合、Jevへ依存してしまうと困ります。
調べてみると、Jevは簡単にオフにできます。Codex側のJev MCPを無効化し、Jevへ単純判断を送るルールも止めればよいだけです。設定そのものは残しておけるので、「しばらくJevは使わない」という状態にもできます。必要になれば、またオンに戻せます。
つまり今回作ったのは、「CodexとJevを一体化した環境」というより、「Codexが外部の判断AIを利用できる仕組み」と考えた方がよさそうです。Jevは、その判断エンジンのひとつという位置づけです。
本当にCodexの利用量は減るのか
ここが一番知りたいところです。
今回の設定では、単純なYES/NO判定をJevへ渡すところまでは成功しました。しかし、これによってCodexの利用枠がどのくらい節約できるのかは、まだ分かりません。
むしろ単純すぎる判断では、CodexがJevへ質問を作る→Jevへ送る→判定結果を受け取る、という処理が増えます。そのため、単発の単純判定だけを見ると、必ずしも得とは限りません。
効果が出てくるのは、おそらく実際のAIエージェント開発で、テスト結果の確認→ログの確認→条件判定→次へ進むか判断→変更内容のチェックといった小さな判断が何十回、何百回と積み重なったときだと思います。
これから実際のCodex開発で使ってみて、「Jevが何回呼ばれるのか」「どんな判断を任せているのか」「Codexの利用枠の減り方に変化があるのか」を見ていきたいと思います。
AIエージェントも、全部をひとつの巨大AIにやらせる時代から、「考えるAI」「判断するAI」「ローカルで個人情報を処理するAI」のように、役割ごとに分業する方向へ進んでいくのかもしれません。今回のCodex＋Jevは、その入り口として、なかなか面白い実験になりました。
コメント