2026年9月22日時点の価格表は、ある明白な形を示している。誰もやりたがらない作業には、入力100万トークンあたり$0.10のGPT-6 Lunaを充て、それをチェックするエージェントには$4のClaude Opus 5.5を充てる。そうすれば、ほぼ同じスループットを請求額のごく一部で維持できる。今週、多くのチームがそれを組み上げているが、そのほとんどは「レビューに見えてレビューではないもの」を作ることになる。
失敗はどちらのモデルにあるのでもない。あるのは、両者の間の隙間を渡っていくものだ。ワーカーが自分の作業をまとめた要約をレビュアーが読むとき、レビュアーは「主張」を読んでいるにすぎず、返せるのはその主張への判断だけだ。ワーカーは「diffは通りました」と言い、レビュアーは「問題なさそうです」と言う。2つのモデルが一致したから人間が承認する——これが最も情報量の少ない種類の一致である。
つまり、混合モデルのCrewで面白い問いは、どのモデルをどこに置くかではない。ハンドオフが何を運ばなければならないか、である。
混合モデルのCrewとは
混合モデルのCrewとは、Runtimeをチーム単位ではなく役割単位で選ぶエージェント群のことであり、少なくとも1つの役割が他のエージェントの出力をチェックするためだけに存在するものを指す。
レビュアー・エージェントは承認ではない。コストのかかるセカンドオピニオンであり、人間が目を通す前に生成されることで、人間が読むリストを短くする。エージェントは調査し、実行し、テストし、報告する。人間は方向性を定め、権限を与え、結果を受け入れる。この文の真ん中に高価なモデルを足しても、最後の節は動かない。
ベンダーが公表した3つのティア
| Claude Opus 5.5 | GPT-6 Sol | GPT-6 Luna | |
|---|---|---|---|
| API id | claude-opus-5-5 |
gpt-6-sol |
gpt-6-luna |
| 入力 / 出力（100万あたり） | $4 / $20 | $2 / $10 | $0.10 / $0.50 |
| キャッシュ入力 | 読み取り $0.20、書き込み $5 | 読み取り90%オフ | 読み取り90%オフ |
| コンテキスト | 1M | 872k | 1M |
OpenAIはSolとLunaを、GPT-5.6のプロモーション価格より50%安いと説明している。そして「プロモーション」という言葉自体が示唆的だ——基準となる価格がすでに割引価格なのである。OpenAIはまた、GPT-6 Astraが「引き続きあらゆる面で当社最高のモデル」だと述べている。
この分け方から順位を読み取る前に、ひとつ注意しておきたい。OpenAIのローンチ記事はSolとLunaをClaude Opus 5と比較ベンチマークしている。記事が書かれた時点でOpus 5.5は存在しておらず、数時間後にリリースされ、Anthropic自身の説明によればOpus 5より実行コストが40%低い。この比較をやり直した者はいないし、両ベンダーが同じハーネスを使っているわけでもない。役割は価格と、自分のリポジトリで観察された挙動をもとに選ぶべきだ。
とはいえ、各ベンダーが自社モデルについて述べていることは、役割を割り当てるには十分だ。LunaについてOpenAIは、最大推論エフォートでDeepSWE 1.1が66.6%、タスクあたりのコストがClaude Opus 5より93%安く、Fable 5より96%安いと報告し、より高いエフォートではGPT-5.6 Solに匹敵する事実性（ファクチュアリティ）の結果を約100分の1のコストで出せるとしている。これは大量処理に向けられるモデルだ。Opus 5.5についてAnthropicは、Terminal-Bench 4.0が66.4%、FrontierCode v1.1が54.4%、OSWorld 2.0が81.8%、最大出力128k、18時間以上タスクに留まると報告している。これは判断力に向けられるモデルだ。
高価なモデルにおいて、読み取りは安い側の半分
この形が請求書と向き合っても生き残るのはキャッシュのおかげであり、その非対称性が設計を決める。
Opus 5.5のキャッシュ入力読み取りは100万あたり$0.20。これは自モデルの非キャッシュ入力レートの20分の1であり、Lunaの非キャッシュレートの2倍にあたる。出力は100万あたり$20で、Lunaの$0.50の40倍だ。つまり、膨大な量を読みながら20行しか書かないレビュアーはほぼ無料に近く、長々と語るレビュアーはそうではない。
そこから、裏付けのあるルールが導かれる。レビュアーはすべてを読み、ほとんど何も言わない。リポジトリのプレフィックス、規約、diff、そして後述のパケットを渡し、返す量には上限を設ける。
ワーカー側もキャッシュする。GPT-6はデフォルトでヒット率を高め、キャッシュ入力読み取りに90%の割引を適用し、キャッシュされたプレフィックスがどこで終わるかを選べる明示的なブレークポイントを追加し、推論エフォートやツールの可用性を変更してもキャッシュを無効化しなくなった。GitHubは、数十億件のリクエストにわたって、新たに処理が必要なプロンプトトークンが50%以上減ったと報告している。同じリポジトリを一日中読み返すLunaワーカーの群れにとって、これが請求額の大半を占める。
ハンドオフが運ばなければならないもの
これがその成果物、モデルに読ませるために作られたハンドオフテンプレートだ。ワーカーは停止時にこれをタスクへ返し、レビュアーはこれとdiffだけを読む。
SH-312 Add retry with backoff to the webhook sender
Worker: Agent "backend-worker" - Runtime Codex on gpt-6-luna
Attempts: 2 (attempt 1 failed on lint)
Diff: 4 files, +118 / -12 (worktree sh-312, commit a91f4c2)
Commands run, verbatim:
$ pnpm lint exit 0
$ pnpm typecheck exit 0
$ pnpm test -- sender exit 0 14 passed, 0 failed, 3 skipped
$ pnpm build exit 0
Not done:
- The 3 skipped tests need a live webhook endpoint. Not run.
- Did not touch the queue consumer, which has the same bug.
Assumptions made:
- Max 5 retries, ceiling 30s. No spec said. Copied the values
already used in payments/retry.ts.
Stopped because: acceptance criteria met.
このパケットをトークンに見合うものにする4つの性質がある。
物語ではなく成果物であること。コマンドと終了コードは再実行できる。「挙動を検証しました」は誰にも確認できない。
やらなかったことを明記していること。スキップされたテストと手をつけていないコンシューマーは、要約なら落としていたであろう2点であり、同時にレビュアーが最も必要とする2点でもある。やっていないことを明示的に求めなければ、きれいにまとまった要約にはそれは含まれない。
前提を記録していること。境界の定まったタスクには必ず、仕様が決めなかった判断が含まれる。書き留めてあればレビュー項目になる。省かれれば、1か月後の本番でのサプライズになる。
停止理由が明記されていること。完了、ブロック、予算切れ、2回失敗——リポジトリ上ではどれも同じに見えるが、ボード上ではそれぞれ意味が異なる。
レビュアーが返すもの
REVIEWER Agent "review" - Runtime Claude Code on claude-opus-5-5
Reads: repository prefix (cached), the packet, the full diff
Writes: at most 20 lines
VERDICT changes requested
CHECKED 4 commands re-run, all exit 0. Backoff ceiling honoured.
UNVERIFIED 3 skipped tests. No evidence the retry path ever runs.
BLOCKING Retry wraps the 4xx branch. A 422 will be retried 5 times.
FOR A PERSON Queue consumer has the same bug and is out of scope.
Split SH-312, or widen it?
UNVERIFIEDの行こそが、レビュアーにそのコストを正当化させる部分だ。安価なワーカーは、自分の主張のどれが何にも基づいていないかを教えてくれない。自覚していないからでもある。構造化されたパケットを読む高価なモデルは、確認したことと鵜呑みにしたことを切り分けられる。その切り分けがレビュー工程の産物である。FOR A PERSONの行はもう半分——レビュアーはスコープを決めるのではなく、問いをタスクへ返す。
これを誠実に保つ境界線はこうだ。レビュアー・エージェントはコマンドを再実行し、diffを読み、エビデンスと断言の違いを指摘できる。だが、これが正しい機能だったかどうかは教えられない。レビュー用エージェントが検証できることとできないことは決まったリストであり、しかもレビュアーが高価になるほど、そのリストは長くではなく短くなる。
警戒すべき2つの失敗モード
1つ目はレイテンシで、これは直感に反する。どちらのベンダーでもない第三者であるArtificial Analysisが、「max」推論バリアントの初回トークンまでの時間を計測し、Lunaが124.23秒、Solが102.15秒だった。［要確認］これらに依拠する前に、現在の掲載内容と照合してほしい。数字よりも形のほうが重要だ。高い推論エフォートでは、安価なモデルは起動が速いほうではない。そのため混合モデルのCrewでは、ワーカーがハングしているように見え、レビュアーがそれを待つことになる。これはモデルではなくステータスの問題だ。
2つ目はレビューの量だ。Lunaワーカー10体はパケットを10個生む。レビュアーが9件を承認し1件だけエスカレーションするなら、10回のエージェント実行を1つの人間の判断に変換できたことになり、それが狙いである。もし6件をエスカレーションするなら、レビューの分を払ったうえでさらに6つの判断を抱えることになり、レビューキューはすでにボトルネックだったことになる。ワーカー・エージェントごとのエスカレーション率を1スプリント追跡してみよう。請求書よりずっと早く、パケットが薄すぎるのかタスクが大きすぎるのかを教えてくれる。
これをやるべきでないとき
1人が1つのリポジトリで1～2体のエージェントを動かしているだけなら、すべてを1つのモデルで済ませよう。パケットはオーバーヘッドで、レビュアーは二重の請求になり、そもそもあなた自身がレビュアーなのだ。
複数のエージェントが並行して走るとき、複数の人間が実行を開始できるとき、あるいは完成した作業が誰かの読む時間を超えて膨らんだときに、混合モデルのCrewを使う。
そして、難しいのが作業そのものであるときは、高価なモデルをレビューに置かないこと。何時間もコンテキストを保持しなければならないマイグレーションは、Opus 5.5に直接担当させ、その後に安価なエージェントにパケットを書かせるべきだ。役割ごとに選ぶとはタスクごとに選ぶということであり、チームで一度決めれば済む話ではない。だからこそ、エージェントの役割にモデルを合わせることは、6人がそれぞれ胸の内に抱く習慣ではなく、書き下ろすルールなのだ。
動かなかった数字
完了したタスクあたりのコストは、今回のリリースで双方とも大きく下がった。OpenAIは、コーディングエージェントに1日$600以上を使うリサーチャーが中央値で、90パーセンタイルでは$7,000を超えると報告している。その線より下のチームは、先週の何倍ものエージェント作業をこなせるようになった。
レビュアーの工数はまったく変わっていない。混合モデルのCrewが元を取るのは、より多くの安価な出力をより少ない人間の判断に変換することによってであり、それが起きるのはハンドオフが要約ではなくエビデンスを運ぶ場合だけだ。ゴール、diff、コマンド、ブロッカー、未検証の主張、そしてリクエストからリリースまでタスクに戻ってくる人間のレビューを保ち続ければ、モデルの分け方は、誰の働き方も変えずに次の四半期に変更できる設定になる。
Sharklyはモデルを実行しないし、あなたに代わって選びもしない。Sharklyは、それを実行するツール群を取り囲む、共有されたタスク、Computer、コンテキスト、レビューのレイヤーであり、レビュアーと人間の両方が読むのであれば、ハンドオフはまさにそこに置かれるべきものだ。すでに複数のコーディングエージェントを動かしているなら、Computerを1つ接続し、ワーカー・エージェントを1体、レビュアー・エージェントを1体作成し、退屈な何かでワーカーにそのパケットを返させてみよう。
