あなたのコーディングエージェントは、選択式の問題にフロンティアモデルの料金を払い続けています。
どのノートを読み込むべきか？このステップは大きなモデルに任せるべきか、小さなモデルで十分か？ツールが失敗した。リトライするか、修正するか、諦めるか？どのテストを先に実行すべきか？
これらはすべて、4〜5 個の選択肢を持つ質問です。そして現在のほとんどのエージェント構成では、そのすべてに対して、思考モードをオンにした最も高価なモデルが呼び出され、コンテキスト全体を読み込み、判断を下す前に長文の回答を生成しています。
ここにコストの穴があります。
この記事では、その穴を塞ぐ方法をご紹介します。Opus 5.5 は、計画立案、コード記述、デバッグといった難しい推論に専念させます。Jev は、ほぼすべてのステップで発生する 4 つの意思決定を担当します。あなたのハーネス（制御プログラム）は選択肢を用意し、回答を検証し、最終的な判断を下します。
以下の実践例では、1 つの機能実装セッションのコストが $6.42 から $2.00 に下がります。69% の削減です。計算式はすべてこの記事に記載しているので、あなた自身の数字に当てはめて確認できます。
この記事は、実際の業務でコーディングエージェントを動かしている人に向けて書かれています。Claude Code でも、API 上で自作したハーネスでも、その中間のどんな環境でも構いません。エージェントを書き直す必要はありません。この記事で紹介する各パーツは、既存のループに関数呼び出しとして組み込め、オフにするフラグも用意できます。以前書いた Jev + Claude Code の記事を読んだことがあるなら、これはそのアップグレード版です。考え方は同じですが、より新しい推論モデルを使い、一般的な原則ではなく 4 つの具体的な意思決定に焦点を当てています。
必要なのは、Jev の API キー、Anthropic の API キー、そして比較検証のための約 1 週間分のエージェントログです。
さっそく構築していきましょう。
opus が推論し、jev が決定する。
問題：1 つのモデルが 2 つの仕事をこなしている
コーディングエージェントの動きを 10 分ほど観察すると、まったく性質の異なる 2 種類の作業をしていることがわかります。
1 つ目は「推論」です。 機能の計画を立てる。関数を書く。スタックトレースを読み解き、なぜ日付パーサーがうるう年で壊れるのかを突き止める。こうした作業はオープンエンドです。答えはリストに載っていません。ここでは予算内で最も賢いモデルを使いたいもので、Opus 5.5 は非常に優秀です。
2 つ目は「決定」です。 40 個あるプロジェクトノートのうち、重要な 3 つを選ぶ。リネーム処理なら安いモデルで済むと判断する。npm test がタイムアウトした後に何をするか決める。全 1,400 件のテストの前に実行すべき 12 件のテストファイルを選ぶ。これらの答えはリスト上にあります。リストは短く、あなたのコードは答えに基づいて直接アクションを起こせます。
ほとんどのエージェントは、デフォルトの動作として、両方の作業を同じモデルで処理します。ループが Opus を呼び、Opus が考え、Opus が答え、ループが続きます。
これで動きます。しかし、見落としやすい形で遅く、高価になっています。1 回ずつ見ると、決定のための呼び出しは高く見えないからです。「どのノートが必要か」という 1 回の呼び出しは 1 セント程度かもしれません。しかしそれは毎ステップ発生し、毎回コンテキスト全体を引き連れていきます。
さらに、もう 1 つ見落としやすいコストがあります。エージェントは何を読み込むべきか決められないとき、すべてを読み込んでしまうのです。すべてのプロジェクトノート、すべての規約ドキュメント、過去のすべての決定が、あらゆる呼び出しに詰め込まれます。Opus 5.5 はキャッシュ読み込みを 100 万トークンあたり $0.20 と安くしましたが、「安い × 60 ステップ × ノートフォルダ全体」はやはり積み上がります。
解決策：Opus が推論し、Jev が決定し、ハーネスが統括する
Jev は TypeSafe がまさにこの「2 つ目の仕事」のために作ったモデルです。テキストは生成しません。コンテキストと、固定された選択肢を持つ型付きの質問を与えると、各選択肢の確率を返します。ミリ秒単位で応答し、入力は 100 万トークンあたり $0.042、出力は無料です。
これにより、アーキテクチャはシンプルに説明できます。
Opus 5.5 は推論を担当します。 計画、コード、デバッグなど、答えがリストにない作業全般です。
Jev は小さな決定を担当します。 ハーネスが用意した選択肢から選びます。
ハーネスが主導権を握り続けます。 選択肢リストを作成し、確率を読み取り、閾値を適用し、Jev が確信を持てない場合は Opus にフォールバックします。
多くの人が省略しがちなのがこの 3 行目であり、こここそが全体の安全性を支える部分です。Jev は決して選択肢を捏造しません。取り消せないことについて、Jev が最終決定権を持つことはありません。「十分に確実」とはどういう状態かを定義するのは、あなたのコードです。
以下は、この記事の残りの部分すべてが依存するヘルパー関数です。
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
ここを Jev クライアントに接続する：TypeSafe SDK、Vercel AI Gateway、
または LangChain パッケージ。渡したすべての選択肢について
{option: probability} を返す必要がある。
raise NotImplementedError
def decide(context: str, question: str, options: list[str], threshold: float):
probs = jev_choice(context, question, options)
answer = max(probs, key=probs.get)
return Decision(answer, probs[answer], probs, probs[answer] >= threshold)
ここに「ないもの」に注目してください。Jev に「どれくらい確信しているか」を尋ねる質問がありません。返された確率を読むだけです。どんなモデルに「本当に合ってる？」と聞いても、ほぼ毎回「はい」と返ってきます。確率こそが正直なシグナルなのです。
それでは、4 つの意思決定を見ていきましょう。
エージェントステップ内の 4 つの決定
決定 1：コンテキスト読み込み前に関連するプロジェクトノートを選別する
これが単独で最も効果が大きいレバーであり、しかもほとんど誰も実装していない部分です。
あなたのエージェントにはノートフォルダがあります。AGENTS.md、アーキテクチャドキュメント、規約、過去の決定、「マイグレーションなしで課金モジュールに触るな」といった警告。おそらく合計 30,000 トークンほどになるでしょう。重要なノートを漏らした犯人になりたくないため、ほとんどのエージェントは毎回すべてを読み込みます。
そこで、すべてを読み込む代わりに、各ノートについて Jev にシンプルな質問を並列で投げます。「このタスクに、このノートは必要か？」
まず、ノートを見出しごとにチャンクへ分割します。AGENTS.md の各セクションが 1 つのチャンクになり、各アーキテクチャドキュメントが 1 つ以上のチャンクになります。
import re
def chunk_notes(markdown: str, source: str):
parts = re.split(r"
(?=## )", markdown)
return [{"source": source, "text": p.strip()} for p in parts if p.strip()]
次に、現在のタスクに対して各チャンクをスコアリングします。
from concurrent.futures import ThreadPoolExecutor
def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):
def score(note):
probs = jev_choice(
context=f"TASK:
{task}
NOTE ({note['source']}):
{note['text']}",
question="Would an engineer need this note to do the task correctly?",
options=["needed", "not_needed"],
)
return probs["needed"], note
with ThreadPoolExecutor(max_workers=16) as pool:
scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)
picked = [n for p, n in scored[:keep] if p >= floor]
return picked or [n for _, n in scored[:2]]
ここで重要になる 3 つの细节があります。
絶対条件は常に読み込む。 セキュリティルール、「force push 禁止」、どのデータベースが本番環境かを示す 1 行など、何が起ころうとも毎回含めるべきノートがあります。それらには always タグを付け、スコアリングをスキップします。
下限とフォールバックを設ける。 何も 0.55 を超えなかった場合でも、上位 2 件は読み込みます。コンテキストがゼロのエージェントは、少し多すぎるエージェントよりも性能が劣ります。
除外されたものをログに残す。 エージェントがミスをしたとき、最初に確認すべきは「それを防げたはずのノートがスコア不足で落とされていないか」です。そのログが keep と floor を調整する根拠になります。
実践例では、この変更だけで各呼び出しのノート部分が 30,000 トークンから 6,000 トークンに減ります。これだけでセッションコストが約 24% 削減されます。
決定 2：適したタスクをより速いワーカーにルーティングする
すべてのステップに Opus が必要なわけではありません。
8 つのファイルにまたがる関数のリネームには不要です。すでに同じようなフィールドが 9 つあるフォームにフィールドを 1 つ追加するのも不要です。インポートパスの更新も不要です。これらは、コードベース内にすでに存在するパターンに従った編集です。
そこで、各ステップの実行前に Jev がステップを分類し、ハーネスがそのクラスをワーカーにマッピングします。
ROUTES = {
"rename_or_move": "fast",
"small_edit_following_existing_pattern": "fast",
"new_logic": "opus",
"debugging": "opus",
"design_decision": "opus",
}
def route(step: str, recent_diff: str):
d = decide(
context=f"STEP:
{step}
RECENT CHANGES:
{recent_diff}",
question="What kind of work is this step?",
options=list(ROUTES),
threshold=0.8,
)
if not d.confident:
return "opus"
return ROUTES[d.answer]
選択肢の書き方に注目してください。「簡単」「難しい」ではありませんし、「小さいモデルで対応できるか？」でも絶対にありません。あなたのコードがアクションにマッピングできる、具体的な作業の種類です。これが Jev への質問すべてに共通するルールです。すべての選択肢は、ハーネスがどう対処すべきかを知っているものでなければなりません。
そしてデフォルトにも注目してください。0.8 未満の場合、ステップは Opus に送られます。ここではルーティングミスは一方向にしか起きません。難しいタスクを高速ワーカーに送ると、ステップの失敗とリトライというコストがかかりますが、簡単なタスクを Opus に送っても少し余分に払うだけです。迷ったら上に送りましょう。
高速ワーカーには、入力 100 万トークンあたり $1、出力 100 万トークンあたり $5 の Haiku 4.5 を使っています。実践例では、実際の作業ステップ 36 のうち 12 がこちらに送られます。
決定 3：ツールが失敗したときのリカバリー経路を選ぶ
ツールは頻繁に失敗します。テストがタイムアウトする。ファイルパスが間違っている。パッケージがインストールされていない。シェルコマンドで権限エラーが起きる。リンターが無関係なことで警告を出す。
ほとんどのエージェントは、最も高価な方法でこれを処理します。エラー全体を大きなモデルに返し、どうすべきか考えさせるのです。それが正しい場合もあります。しかし多くの場合、答えは明白で、Opus は ENOENT が「ファイルがない」ことを再発見するために 1,500 トークンを消費します。
さらに悪いことに、エージェントはループに陥ります。リトライ、失敗、リトライ、失敗。毎回フルの推論ステップにお金を払います。
そこで、失敗内容と固定されたリカバリー経路のセットを Jev に渡します。
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # エラーの末尾 n 文字
def recover(tool: str, command: str, error: str, attempt: int):
if attempt >= 3:
return "stop_and_report"
d = decide(
context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",
question="What is the best next move after this failure?",
options=RECOVERY,
threshold=0.8,
)
return d.answer if d.confident else "escalate_to_opus"
1RECOVERY = [2 "retry_unchanged", # 不安定なネットワークやタイムアウト3 "retry_after_install", # パッケージやツールの欠落4 "fix_path_and_retry", # ファイルパスや cwd の誤り5 "switch_tool", # このツールでは不可能だが他なら可能6 "escalate_to_opus", # 本格的なデバッグが必要7 "stop_and_report", # 人間の介入が必要8]
試行回数のハードリミットはモデルではなくコードに置きます。どんなに安いモデルでも、無限にリトライさせてはいけません。
各リカバリー経路は、ハーネス内の小さな関数に対応します。retry_after_install は正規表現でエラーから欠落パッケージを読み取ってインストールします。fix_path_and_retry は存在するパスを確認し、最も近い候補を提案します。本当にお金がかかるのは escalate_to_opus だけで、それも実際に推論が必要な失敗のときにのみ発動します。
実践例では、これによりセッションから無駄なリトライ 6 ステップが排除されます。
決定 4：フルテストスイートの前に重点チェックを実行する
これはお金よりも時間を節約し、時間こそがエージェントを「速い」と感じさせる要因です。
変更のたびに、ほとんどのエージェントはテストスイート全体を実行します。スイートに 4 分かかるなら、エージェントは編集のたびに 4 分待ち、その後数百行の出力を読んで、本当に重要な 1 つの失敗を探します。
解決策はノートと同じパターンです。各テストファイルを diff に対してスコアリングし、最も関連性の高いものを先に実行し、重点チェックが通過した場合のみフルスイートを実行します。
1def pick_tests(diff: str, test_files: list[str], keep: int = 12):2 def score(path):3 probs = jev_choice(4 context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",5 question="Could this change break tests in this file?",6 options=["likely", "unlikely"],7 )8 return probs["likely"], path910 with ThreadPoolExecutor(max_workers=16) as pool:11 scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)12 return [p for _, p in scored[:keep]]1314def check(diff: str, test_files: list[str]):15 focused = pick_tests(diff, test_files)16 if not run_tests(focused):17 return False # 早期失敗、他の何よりも先に修正する18 return run_tests(test_files) # フルスイートがコミットのゲートであり続ける
最後の行をもう一度読んでください。コミット前には必ずフルスイートが実行されます。重点チェックは早期警告であり、代替品ではありません。数分ではなく数秒で大半の破壊を検知でき、かつフルスイートなら検知できたはずのものを出荷してしまうこともありません。
安いチェックも先に加えましょう。変更されたファイルのみに対する型チェックとリントです。1 秒で終わり、テスト実行前に驚くほどの割合のミスを捕捉します。
統合：ハーネスのループ
4 つの決定がループの 1 ステップの中でどう配置されるかは次の通りです。
def run_step(task: str, step: str, state):
1. コンテキスト：このステップに必要なノートだけを読み込む
notes = state.always_notes + pick_notes(step, state.notes)
2. ルーティング：このステップのワーカーを選ぶ
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. リカバリー：このステップでのツール失敗を処理する
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. チェック：重点テストを先に、コミット前にフルスイート
if result.diff:
state.log_check(check(result.diff, state.test_files))
そして Opus 側はこうなります。通常の Opus 5.5 呼び出しと変わりません。安定したコンテキスト（システムプロンプト、ツール定義、「always」ノート）を先頭に置いてステップ間でキャッシュされるようにし、ステップ固有の素材を最後に置きます。
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # あなたの Opus 5.5 モデル ID
def opus_step(system: str, notes: list[dict], history: list, step: str):
notes_text = "
".join(n["text"] for n in notes)
return client.messages.create(
model=OPUS,
max_tokens=8000,
system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],
messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}
STEP:
{step}"}],
)
特別なことは何もありません。節約は clever なプロンプトからではなく、Opus に送るのをやめたものから生まれます。
1 ステップのトレース
4 つの決定をすべて有効化した後、ログ上の 1 ステップがどう見えるかを示します。タスクは「公開サインアップエンドポイントにレート制限を追加する」です。このトレースは例示用ですが、あなた自身のログでも同じ形が見えるはずです。
step 14 "add a per IP rate limit to POST /signup"
[notes] 41 チャンクを並列でスコアリング
kept: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
dropped: 37 チャンク（billing、email templates、CI など）
[route] new_logic (0.91) → opus
[opus] 変更を計画し、middleware + config + handler の編集を記述
[tool] npm test FAILED "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install して再実行
[checks] 変更ファイルの型チェック：pass
focused tests (1,388 件中 12 件)：pass
full suite：pass
上から順に読み、以前なら何行がフルの Opus 呼び出しだったかを数えてみてください。ノートの選別：巨大な 1 回の呼び出しか、あるいは選別せずに 30,000 トークンのノートを闇雲に読み込んでいました。ルーティング：なし。全ステップが Opus 行きでした。パッケージ欠落：「モジュールがない＝インストールしろ」を導き出すためのフル推論ステップ。テスト選択：なし。編集のたびにフルスイートでした。
今では、このトレースで Opus を使っているのは 1 行だけです。そしてそれこそが、実際にフロンティアモデルを必要とした行、つまりレートリミッターの計画と記述です。
これが 1 枚の図で表したコンセプトの全体像です。高価なモデルは、自分にしかできない部分にだけ時間を使います。
実践例：69% の根拠
1 つの機能実装セッションにおける完全な計算式です。60 のエージェントステップと、典型的なエージェントが途中で積み上げる 6 回の無駄なリトライを含みます。価格はすべて現在の公開リスト価格です。
Before：Opus 5.5 がすべてを行う
各ステップで 70,000 トークンのコンテキストを読み込みます。システムプロンプトとツールに 15,000、ノートフォルダ全体に 30,000、これまでの会話に 25,000 です。その 80% がキャッシュヒットすると仮定します。Opus 5.5 では思考が常にオンなので、各ステップで約 1,500 出力トークンを生成します。
cache reads: 56,000 × $0.20/M = $0.0112
fresh input: 14,000 × $4.00/M = $0.0560
output: 1,500 × $20.00/M = $0.0300
per step = $0.0972
66 steps × $0.0972 = $6.42
After：決定レイヤーを導入
Jev が 30,000 トークンすべてを読み込む代わりに 6,000 トークンのノートを選ぶため、コンテキストはステップあたり 46,000 トークンに減少します。純粋な決定ステップ 24 件が Jev に移行します。6 回のリタイアループが消滅します。そして残りの作業ステップ 36 のうち 12 が Haiku 4.5 に送られます。
Opus 5.5: 24 steps × $0.0742 = $1.78
Haiku 4.5: 12 steps × $0.0169 = $0.20
Jev: 102 calls × 5,000 tokens
× $0.042/M, output free = $0.02
total = $2.00
$6.42 から $2.00 へ。同じ機能実装で 68.8% の削減です。
閾値は「間違った答えのコスト」で設定する
各レバーがどれだけ貢献しているか、積み上げ順に示します。
notes selection only $4.89 23.7% saved
- decisions moved to Jev $3.13 51.2% saved
- recovery paths $2.69 58.1% saved
- routing to a fast worker $2.00 68.8% saved
この計算についての 2 つの正直な注意点。
第一に、これらは明示的な仮定に基づくモデリング値であり、あなたのスタックの実測値ではありません。コンテキストサイズ、キャッシュヒット率、決定回数は環境によって異なります。すべての行を示しているのは、あなた自身の数字に置き換えられるようにするためです。実際の Before/After を計測したら、私の数字ではなくあなたの数字を使ってください。
第二に、実際にお金がどこに行っているかを見てください。Jev の 102 回の呼び出しは合計で 2 セントです。節約は Jev の単価が安いことから来るのではありません。Jev が決定を下すことで「起きなくなるすべてのこと」から来ています。肥大化したコンテキスト、選択式問題のためのフル推論ステップ、リタイアループ、リネーム作業での大型モデル呼び出しです。
なぜ決定に Haiku だけではダメなのか？
もっともな疑問です。Haiku 4.5 は安くて速い。なぜわざわざ新しいモデルを追加するのか？
理由は 3 つあります。
それでもテキストを生成する。 Haiku はテキストで答えます。用意した選択肢のいずれかで答えるようプロンプトし、回答をパースし、さらに説明を付け加えたり、リストにないものを選んだり、回答を文章で包んでくるケースに対処する必要があります。Jev は渡したすべての選択肢の確率を返します。パースするものはなく、リスト外のものが返ることもありません。
答えだけでなく分布全体が得られる。 Jev が needed: 0.52, not_needed: 0.48 と返せば、コイン投げのような状態だとわかり、ハーネスはエスカレーションできます。テキストモデルが「needed」と言った場合、確信があったかどうかはわかりません。閾値は、確率が見えるときにしか機能しません。
コスト計算が違う。 Jev は出力が無料で、入力が 100 万トークンあたり $0.042 です。毎ステップ 41 個のノートチャンクをスコアリングするということは、ステップあたり 41 回の小さな呼び出しを意味します。Jev なら 1 セントの端数です。テキストモデルでは、たとえ安いものでも、それぞれに出力コストとレイテンシがかかる 41 回の生成になります。
実際にコードを書く必要がある小さな編集には Haiku を使いましょう。リストからの選別には Jev を使いましょう。考えることには Opus を使いましょう。各モデルに、それが得意とする仕事をさせるのです。
何も壊さずに導入する方法
4 つの決定を一度にすべてオンにしないでください。私が推奨する順序は次の通りです。
第 1 週：シャドウモード。 現在のエージェントをそのまま維持します。エージェントが下すすべての決定について、同じ質問を Jev にも投げ、両方の答えと Jev の確率をログに記録します。Jev の答えに基づいてアクションは一切起こしません。
1def shadow(decision_name, context, question, options, current_answer):2 probs = jev_choice(context, question, options)3 jev_answer = max(probs, key=probs.get)4 log_row(5 decision=decision_name,6 current=current_answer,7 jev=jev_answer,8 prob=probs[jev_answer],9 agree=(jev_answer == current_answer),10 )
第 2 週：不一致を読む。 Jev と現在のエージェントの答えが一致しなかった行だけを見ます。それを Jev の確率でソートします。通常、きれいな境界線が見つかります。ある確率以上では、Jev は Opus と同じくらいの頻度で正解します。その線があなたの閾値です。これらの不一致行は、実際のトラフィックから無料で作られたテストセットにもなります。
第 3 週：ノート選別をオンにする。 最大のレバーであり、見逃したノートはログにすぐ現れるため、元に戻すのも最も簡単です。
第 4 週：リカバリーとテストをオンにする。 どちらもコード内にハードリミットとフォールバックがあるため、最悪のケースでも現在やっていることに戻るだけです。
最後：ルーティング。 ルーティングミスはユーザーにとって最も目立ちます。難しいタスクを高速ワーカーに送ると、質の悪いコードが生成されるからです。保守的な閾値で最後にオンにし、高速ワーカーのステップにおける失敗率を監視してください。
すべての決定を on/off フラグの背後に置き、1 行で元に戻せるようにしておきましょう。
リスクに応じた閾値の設定
すべてに同じ閾値を使うのは間違いです。答えが間違っていたときに何が起きるかに基づいて設定しましょう。
1 つの機能セッション、同じ結果 $6.42 から $2.00 へ
低リスク・巻き戻しが容易：0.55 〜 0.65。 ノートの選別。テストの順序付け。間違った答えのコストは、少しのコンテキストや数秒程度です。
中リスク：0.8。 ルーティングとリカバリー。間違った答えのコストは 1 ステップの失敗ですが、ハーネスが捕捉します。
高リスク・巻き戻しが困難：0.9、または絶対に任せない。 ファイル削除。force push。本番設定の変更。マイグレーションの実行。正直なアドバイスとしては、どんなモデルにもこれらを単独で判断させないでください。人間にルーティングするか、最低でも確認ステップ付きで Opus に任せましょう。
閾値を下回るものはすべて上位にエスカレーションします。推論が必要なら Opus へ、判断が必要なら人間へ送ります。
この手法が効かないケース
このアーキテクチャは、あらゆるワークロードで魔法のように効果を倍増させるものではありません。
純粋な生成ワークロードはほとんど変わりません。 エージェントが明確な仕様から大量の新規コードを書くことにほとんどの時間を費やしている場合、移行できる決定は多くありません。ノート選別の節約は得られますが、それ以外は大差ありません。
小規模なプロジェクトには不要です。 ノートフォルダ全体が 2,000 トークンで、スイートが 8 秒で終わるなら、これを構築するオーバーヘッドに見合いません。
Jev は単独での最終決定が得意ではありません。 物事に気づいたり、短いリストから選ぶのは非常に優秀です。しかし「このプルリクエストはマージ準備ができているか？」という単一の問いを決定させるモデルではありません。大きな問いを小さな問いに分解し、それぞれをスコアリングし、結果をあなた自身のコードで、あなた自身の重み付けで結合してください。
固定された質問に対するラベル付きデータがすでにある場合、自分でホストする小さなモデルが価格で Jev を上回る可能性があります。 Jev が真価を発揮するのは、質問が変わり続け、学習データがない場合です。これはほとんどのコーディングエージェントに当てはまります。
避けるべきミス
モデルに選択肢リストを書かせること。 アーキテクチャ全体が、コードが処理できる選択肢に依存しています。モデルが選択肢を生成すると、フリーテキストのパースに戻るだけです。
Jev に確信度を尋ねること。 代わりに確率を読んでください。自己申告はほぼ常に「はい」になります。
フォールバックがないこと。 すべての Jev の決定には「確信できない」場合の経路が必要で、それは Opus か人間であり、決して推測であってはなりません。
リトライ上限をプロンプトに書くこと。 「3 回だけリトライせよ」と指示されたモデルは、たまに 30 回リトライします。コードはそんなことをしません。
フルテストスイートを廃止すること。 重点チェックは速度を上げます。フルスイートは誠実さを保ちます。両方維持してください。
何も計測しない。 開始前にセッションあたりのコストを記録しておかなければ、 20 % 節約できたのか 70 % なのか、永遠にわかりません。まずは通常の業務 1 週間分の利用状況を書き出しましょう。 10 分もあれば終わりますし、これこそが唯一意味のある数字です。
今週やるべきこと
全体像をチェックリストとしてまとめました。
- 1 週間分のエージェントセッションを記録する：ステップ数、トークン数、コスト、失敗回数。
- ループの中に隠れている意思決定を見つける：ノート（notes）、ルーティング、リカバリー、テスト。
- それぞれを「固定の選択肢リストを持つ質問」として書き出す。
- 現在のエージェントと並行して、 Jev を 1 週間シャドウモードで動かす。
- リスクに応じて、不一致ログから閾値を設定する。
- まずノートの選択を有効にし、次にリカバリーとテスト、最後にルーティングをオンにする。
- 導入前後のセッションあたりコストを比較する。それがあなたの成果指標です。
Opus 5.5 は、私がコード向けに使ってきた中で最高の推論モデルです。ただし、それ以外のすべてまで任せてしまうのは間違いです。
考えるのは Opus に任せましょう。決めるのは Jev 。ルールを決めるのはあなたのコードです。
この記事が役に立ったら、 @cyrilXBT をフォローしてください。毎週、最新の AI モデルを使った開発手法を、リアルな数字とともに解説しています。
いざ開発を始めるときのために、ブックマークしておきましょう。
