上位モデルに替える前に、切り分ける
AIが期待どおりに動かないとき、とりあえず賢いモデルに替えていました。でも「知らなかった」のか「粘らなかった」のかは別の問題で、混ぜて対処すると値段だけ上がります。一人会社で使っている切り分けの順番を書きます。
AIが思ったとおりに動かないとき、私たちはずっと「もっと賢いほうに替える」で対処していました。
うちは社長1名と、COO役のAI(Claude Code)だけの一人会社です。開発も文書も調査も、かなりの部分をAIに任せています。任せている量が多いぶん、外したときの対処の仕方が、そのまま毎月の請求額になります。
その対処を、去年までは勘でやっていました。今年になって手順として書き出したので、その順番を残しておきます。
💸値段を上げれば直る、と思っていた
出力が浅いと感じたら上位モデルに切り替える。長いあいだ、それしか手札がありませんでした。
期待した答えが返ってこないとき、いちばん手っ取り早いのは上のモデルに替えることです。実際それで直ることもあります。だから習慣になりました。
困るのは、直らなかったときです。直らないと今度は、思考の深さの設定も一緒に上げる。両方上げれば、たいていの問題はいったん収まります。収まるのですが、何が効いたのかが分からないまま単価だけ上がる。しかも次に同じ場面が来たときも、また両方上げることになります。
一人会社なので、この積み重ねは効きます。公開されている価格表を見ると、軽いモデルと上位モデルでは同じ入力量でも単価に数倍の開きがあります。当てずっぽうで上げ続けると、効果の分からない支出だけが増えていきます。
🔀「知らなかった」のか「粘らなかった」のか
失敗の原因を2つに分けたら、どちらのつまみを回すかが決まりました。
うまくいかなかったときの原因を、いまは2つに分けています。ひとつは知識が足りなかった場合。領域そのものを知らない、情報が古い、といったケースです。これはモデルを上げるしかありません。
もうひとつは粘りが足りなかった場合。読むべきファイルを読まずに答えた、検証せずに終わった、途中でやめた。知らないのではなく、確認の量が足りていない。これは思考の深さ(作業量の設定)を上げる話で、モデルはそのままで直ります。
見分け方は、出力を読めばだいたい分かります。的外れなら知識の問題、方向は合っているのに浅いなら作業量の問題です。そして1回に動かすつまみは1つだけと決めました。両方いっぺんに上げるのは、切り分けをあきらめるのと同じだからです。
この分け方を書き出してから、上位モデルを呼ぶ場面がはっきり減りました。浅かっただけのケースが思っていたより多かったからです。
📄上げる前に、渡した情報を疑う
つまみを回すのは3番目です。1番目は、こちらが十分な材料を渡していたかを見ます。
手順として先頭に置いているのは、モデルでも設定でもありません。渡した情報が足りていたかを疑うことです。対象のファイルの場所を書いたか、制約を書いたか、背景を書いたか。
とくに別のAIに作業を切り出すとき、こちらの会話の流れは向こうには見えていません。前提を省いた依頼を出しておいて、返ってきた答えが浅いからモデルを上げる、というのは順番が逆でした。うちで何度もやった失敗です。
いまは、外したときに見る順番をこう固定しています。渡した情報を疑う。次に、知識の問題か作業量の問題かを分ける。最後に、該当するほうのつまみだけを1段動かす。この3段を通してから請求額の話をするようにしました。
🧮そもそも呼ばない、という選択肢
判定が機械的に書けるなら、AIを呼ばないのがいちばん安い。
モデルの選び方を整理していて気づいたのは、そもそも呼ばなくていい仕事がけっこう混じっていたことです。書式が守られているか、必要な項目が入っているか、リンクが生きているか。この手の検査は答えが一意に決まるので、短いスクリプトで書けます。
スクリプトで書けば、その処理の消費トークンは0です。判定もぶれません。逆にこれをAIに任せると、単価が乗るうえに実行のたびに結果が揺れます。
なので、モデルを選ぶ前にこれはスクリプトで判定できないかを先に問うことにしました。うちの品質チェックは、この基準で機械側にかなり寄せています。AIに任せるのは、判断が一意に決まらない部分だけです。
📚参考
モデルと思考の深さが別の設定であることは、提供元の資料にも分けて書かれています。
思考の深さにあたる設定についてはeffort パラメータの説明にまとまっています。同じモデルのまま、かける手間と品質の釣り合いを調整するための設定だという位置づけで、モデル選択とは独立した軸になっています。
モデルごとの性格と単価の違いはモデル一覧のページで確認できます。用途と価格が並んでいるので、どの仕事をどこに落とすかを決めるときの土台になります。
🧭まとめ: モデルは部品、記憶は資産
モデル選びを毎回ゼロから考え直すのは、思っている以上に疲れます。うちは表を1枚作って、新しいモデルが出たら行を1つ足すだけにしました。どの仕事をどこに落とすかが決まっていれば、目移りする回数が減ります。
そして、入れ替えても消えないものがあります。これまでにためた手順書や、失敗から作った検査や、決定の記録です。モデルは交換できる部品ですが、こうした記憶はどのモデルでも使えます。育てる先を間違えないようにしたいと思っています。
あなたがAIの答えに不満を持ったとき、次に何を変えていますか。もし毎回「上のモデル」なら、その前に一度、渡した情報のほうを見直してみてください。
開発パートナーを探していますか?
AIでプロダクトを最速で形にしませんか?
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する