■ 結論：コストを下げるために、スキルは上位モデル（Opus）で作り、毎日の実行は下位モデル（Sonnet）で回す。この形そのものは正しいです。ただし、スキルを作るときに「実行は下位モデルで回す前提で作って」と最初に宣言しておかないと、上位モデル前提の書き方になり、本番で落ちます。落ちるのは手順の実行ではなく、「手順から外れたことに気づく力」のほうです。

■ 作るのは一度、回すのは毎月何十回

スキルにする作業は、たいてい定例です。月次の仕訳、請求書、進捗の集計。作るのは一度きりですが、回すのは毎月、何十回にもなります。

上位モデルと下位モデルでは、同じ作業でも費用がまとまった差になります。だから設計は上位モデル、実行は下位モデルという分け方に行き着きます。ここまでは、すでにやっている方も多いと思います。

■ 落ちるのは「手順」ではなく「気づき」

問題はこの先です。下位モデルに渡したとき、何が落ちるのか。工程を4つに分けると、はっきりします。

・そのスキルを呼ぶか：スキルの説明文に「こう言われたら使う」を書き切っておけば、ほぼ落ちません
・手順どおり動かす：落ちません。書いてあるとおりに動くことに、上位も下位もありません
・決まった分岐の判断：正解表やマスタに落としてあれば落ちません。「適切に判断すること」とだけ書いてあると落ちます
・想定外に気づく：ここが落ちます。入力がいつもと違う、数字の桁がおかしい、前提が崩れている——こういうものは手順に書けません。下位モデルは違和感があっても止まらず、それらしい成果物を出してきます

つまり、上の3つは書き方でつぶせて、4つ目だけがモデルの地力そのものです。

■ 上位モデルで作って、上位モデルで試すと、穴が見えない

ここが落とし穴です。上位モデルは、書いていないところを推測で埋めてくれます。だから上位モデルで書いて上位モデルでテストすると、説明が足りていない箇所があっても、普通に動いてしまう。

そして本番で下位モデルに渡した日に、初めて穴が出ます。下位モデルで一度通して、そこで初めてスキルは完成と考えてください。

■ だから、作るときにこう言う

スキルを作らせるときに、最初にこう伝えます。

1. 実行は下位モデルで回す前提で作ってください
2. 工程を分けて、どこが下位モデルで危ないかを判定してください。甘く見ずに、根拠も出してください
3. 危ないところは「正解表にする／スクリプトにする／止まる条件を書く」のどれかで処理し、どれも無理なら人に回す工程として切り出してください
4. 「適切に」「必要に応じて」のような、判断を丸投げする言葉を本文から消してください

いちばん効くのは3つ目の「止まる条件」です。異常そのものは書き出せなくても、「件数が前月と2割以上違ったら止まる」「マスタにない科目が出たら止まる」なら書けます。気づく力が足りないぶんを、気づかなくても止まる仕掛けで埋める、ということです。

■ モデル名は、先頭に1行だけ書いておく

もう1つ。モデルは今後も入れ替わります。スキルの本文のあちこちに「Sonnetで」と書き散らすと、世代が変わったときに、直す場所が分からなくなります。

先頭に「実行モデル：Sonnet（2026年9月時点）」と1行だけ置いて、本文では「実行モデル」と呼ぶ。これだけで、乗り換えのときに直すのは1行で済みます。

■ まとめ

・スキルは上位モデルで作り、実行は下位モデルで回す。作るのは一度、回すのは毎月
・下位モデルで落ちるのは手順の実行ではなく、「想定外に気づく」ところ
・上位モデルで書いて上位モデルで試すと、説明不足に気づけない。下位モデルで一度通して初めて完成
・作らせるときは「実行は下位モデル前提で」「危ない工程を判定して」「止まる条件を書いて」「『適切に』を消して」の4つを言う
・気づく力が足りないぶんは、止まる条件で埋める
・モデル名は先頭に1行だけ。本文では「実行モデル」と呼ぶ

作るのは一度、回すのは毎月。書き方は、回すほうに合わせる。