Sonnet 5.5・GPT-6.1 Sol・Opus 5.5 のどれに頼むかを、修正の種類で先に決めておきます。クレジットの行き先を1週間記録して引いた割り当て

月末の夜、壁紙アプリの設定画面に小さな修正を三つ頼み終えて、残高の画面を開いたときのことです。頼んだ修正は三つとも軽いものでした——文言の言い換え、余白の調整、そしてトグルを押しても保存されないという不具合です。それなのに、減ったクレジットは軽い修正の数に釣り合っておりませんでした。

その数日前に、Rork のモデルメニューの並びが変わっておりました。9 月 28 日に Claude Sonnet 5.5 が Sonnet 5 の席に入り、翌 29 日に GPT-6.1 Sol が GPT-6 Sol の席に入っています。22 日に入った Claude Opus 5.5 と合わせて、名前の新しい三つのモデルが並ぶかたちです。

私はその三つを、ほとんど気分で選んでおりました。重そうな修正は Opus、急いでいるときは Sonnet、なんとなく GPT。選び方に名前がないまま残高だけが減っていくのは、家計簿を付けずに財布の軽さだけを気にしているのと同じです。そこで 1 週間、頼んだ修正の一つずつに「種類」と「行き先」を書き留めることにしました。

変更履歴に書かれていることだけを、まず表にします

モデルの違いを語るとき、私はまず公式の変更履歴に書かれた言葉だけを並べるようにしております。ベンチマークの数字や評判は、自分の案件で確かめるまでは参考値に留めたいのです。

モデル	追加日	effort の段数	変更履歴の記載	含まれるプラン
Claude Opus 5.5	9 月 22 日	5 段（Low〜Max）	Opus 5 より実行コストが 40% 低く、出力は 30% 以上速い	Pro / Max
Claude Sonnet 5.5	9 月 28 日	5 段（Low〜Max）	Sonnet 5 の席を置き換え。出力は Sonnet 5 より 30% 以上速く、1M トークンの文脈。UI デザインに強いと説明	Pro / Max
GPT-6.1 Sol	9 月 29 日	3 段（Low / Medium / High）	GPT-6 Sol の席を置き換え。GPT-6 Astra に近い能力で GPT-6 Sol と同じ価格、1M トークンの文脈	Pro / Max

表にして気づくのは、三つとも「前のモデルより速い・安い・文脈が長い」と書かれているだけで、どの作業に向くかは一行も書かれていないということです。向き不向きは、使う側が自分の修正で決めるほかありません。

もう一つ、無料プランの方に先にお伝えしておきたいことがあります。三つとも Pro と Max のプランに含まれるモデルですので、無料のままメニューを開くと、モデル名の横に解放されるプランの名前が表示されます。選べないのは不具合ではなく、そういう仕様なのです。

修正に三つの名前を付けます

1 週間の記録を読み返して分かったのは、私が頼んでいた修正はほぼ三種類に収まる、ということでした。

一つ目は「言い換えで直る修正」です。ボタンの文言、余白、色、並び順——仕様が頭の中で完成していて、言葉にすれば一度で伝わる類のものです。

二つ目は「仕様を足す修正」です。設定画面に通知の時間帯を加えたい、一覧に並び替えを付けたい、という類のものです。何を作るかは決まっていますが、画面の何処に何を置くかまでは決め切れていない修正です。

三つ目は「原因が分からない不具合」です。トグルを押しても保存されない、戻るボタンで前の値に戻る、といった症状です。症状は言えても、原因の場所は私にも見えていないものです。

最初の 2 日間、私はこの三つを区別せず、どれも Opus 5.5 の effort を Max にして投げておりました。重い道具なら何でも直るだろう、という思い込みです。結果は芳しくありませんでした。文言の言い換えに Max を使っても返ってくる画面は Low と変わらず、待ち時間と消費だけが増えていたのです。

ここで一つ、線を引きました。モデルを選ぶ前に、修正の種類に名前を付けます。 名前が付いていない修正は、まだ頼む準備ができていない修正なのだと、いま思えば最初の 2 日間が教えてくれていたのかもしれません。

1 週間の記録から引いた割り当て

記録を終えたあと、私の手元では次のような割り当てに落ち着きました。皆さまの案件で同じになるとは限りませんので、あくまで出発点として受け取っていただければと思います。

修正の種類	頼むモデル	effort	そう決めた理由
言い換えで直る修正	Claude Sonnet 5.5	Low か Medium	UI の寄せが速く、一度で返ってくることが多かった。段を上げても画面は変わらなかった
仕様を足す修正	GPT-6.1 Sol	Medium	3 段なので選ぶ手が止まらない。置き場所の提案が控えめで、書いていない機能を足しにくい
原因が分からない不具合	Claude Opus 5.5	High	症状を書き切ってから渡すと、原因の場所を言葉で説明してくれた。Max との差は私の案件では感じなかった

三つ目の行には但し書きがあります。原因が分からない不具合を Opus に渡す前に、私は必ず症状を三行で書き出すようにしました。「何を押したか」「何が起きたか」「何が起きるはずだったか」です。この三行を書く途中で原因に自分で気づき、言い換え修正に格下げできたことが、1 週間に二度ありました。

修正を続きで頼むか、復元ポイントへ戻して言い換えるかは、モデル選びとは別の判断です。その境目は「続きで直すか、復元ポイントへ戻して言い換えるか。Rork で同じ不具合を両方の道で直して分かった境目」に書き残しております。

行き先を記録する台帳と、集計する小さなスクリプト

割り当てを言葉で決めても、記録がなければ 1 か月後にはまた気分で選んでしまいます。そこで、頼むたびに 1 行足すだけの台帳を用意しました。

解きたいのは「1 回あたりのクレジット」ではなく、直るまでに合計いくら使ったかを、修正の種類とモデルの組み合わせごとに見られるようにすることです。1 回で直らず三度頼んだ修正は、三度ぶんを一つの修正として数えたいのです。

台帳は CSV で、列は七つだけです。

date,model,effort,fix_type,credits,solved,note
2026-09-29,sonnet-5.5,low,rephrase,1,y,設定画面の見出し文言
2026-09-29,opus-5.5,max,rephrase,2,y,余白の調整（Max は不要だった）
2026-09-30,gpt-6.1-sol,medium,add-spec,3,y,通知の時間帯を追加
2026-10-01,opus-5.5,high,bug,2,n,トグルが保存されない（1回目）
2026-10-01,opus-5.5,high,bug,2,y,トグルが保存されない（2回目・原因は初期値）

credits は、頼んだあとに残高の画面で減った数を目で見て写します。Build と Cloud の二本立てになっている残高のどちらから減ったかは、「思ったより早く残高が減る前に、Build クレジットと Cloud クレジットを分けて見る」の手順で切り分けております。

集計は、Python の標準ライブラリだけで書いた短いスクリプトで済ませています。

# ledger.py — 修正の種類 × モデルごとに「直った件数あたりのクレジット」を出す
import csv
from collections import defaultdict
 
totals = defaultdict(lambda: {"credits": 0, "solved": 0, "asks": 0})
 
with open("rork_ledger.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        key = (row["fix_type"], row["model"])
        totals[key]["credits"] += int(row["credits"])
        totals[key]["asks"] += 1
        if row["solved"].strip().lower() == "y":
            totals[key]["solved"] += 1
 
print(f'{"fix_type":<10} {"model":<14} {"asks":>4} {"credits":>7} {"per_solved":>10}')
for (fix_type, model), t in sorted(totals.items()):
    # 一度も直っていない組み合わせは割り算せず、そのまま見えるようにする
    per_solved = f'{t["credits"] / t["solved"]:.1f}' if t["solved"] else "unsolved"
    print(f'{fix_type:<10} {model:<14} {t["asks"]:>4} {t["credits"]:>7} {per_solved:>10}')

なぜ「直った件数で割る」のかを書き添えます。1 回あたりの消費だけを見ると、Low で三度頼んで直した修正のほうが、High で一度で直した修正より安く見えてしまうのです。直るまでの合計で見ると、その逆転が起きなくなります。solved が一度もない組み合わせを unsolved と表示しているのも、ゼロ除算を避けるためだけではなく、「このモデルにこの種類を頼むのは止めたほうがよい」という印をそのまま残したいからです。

もう一つ、台帳を付けていて助けられた記載があります。Rork の FAQ には、AI 側のエラーにはクレジットを課さないと書かれています。残高が減ったのに何も返ってこなかった行は、私の頼み方の問題かエラーかを分けて考える手がかりになりました。

来週の 5 回を、台帳から決めます

Sonnet 5.5 と GPT-6.1 Sol が入ってまだ 1 週間ほどですので、上の割り当ては暫定です。モデルの席はこの 1 か月で三度入れ替わりました。次に入れ替わったときも、私は表を作り直すのではなく、台帳に新しいモデル名の行を足して同じスクリプトを回すだけで済むようにしておきたいのです。

同じ一覧画面を Opus 5.5 と GPT-6 Sol で作り分けたときの記録は、「壁紙ギャラリーのような一覧画面を Opus 5.5 と GPT-6 Sol で作り分けてみる — effort の段数から選ぶ、最初の一画面」に書いております。あちらが「最初の一画面」の話で、こちらが「その後の修正」の話です。

まずは、次に Rork へ頼む修正を一つだけ選び、送る前に「言い換え・仕様追加・不具合」のどれかを台帳の fix_type に書いてみていただければと思います。モデルを選ぶ手が、その一語で止まらなくなるはずです。