AIを無人で回すコスト規律｜claude -pの--model明示

「無人でAIを回し始めたら、月末の請求が想定より跳ねていた」「なぜか、いつもより文章の質が落ちている」——AIを人手から離して自動で動かし始めた人が、最初にぶつかる不安です。

結論から言うと、この手の事故のほとんどは「いま、どのモデルで動いているか」を固定していないことから起きます。cron や launchd で走らせる claude -p に --model を明示するだけで、その大半は防げます。

株式会社Fyveは、常時起動の Mac mini を1台だけ立て、そこで毎日十数本のAIジョブを無人で回しています。この記事では、私がその実運用で「壊れる前提」を潰すために決めた、無人便のコスト規律を具体的に紹介します。

なぜ無人実行で「モデル指定」がコスト事故の起点になるのか

対話でAIを使っているときは、画面にモデル名が出ています。高いモデルを使えば「いま重いモデルだな」と自分で気づけますし、遅ければ切り替えます。人間が監視ループの中にいるので、モデルの取り違えは自然に補正されます。

ところが無人実行では、この補正が丸ごと消えます。cron や launchd から起動されたジョブに画面はありません。何のモデルで走っているかを、誰も見ていないのです。

そして claude -p は --model を省略すると、そのマシンのデフォルトモデルに従います。デフォルトが何であるかは環境設定に依存するため、「意図したモデルで動いている保証」がどこにもありません。ここから2種類の事故が起きます。

コスト側の事故：整形や移植のような定型作業を、気づかないまま高いモデルで回し続け、課金がじわじわ膨らむ。
品質側の事故：実名で公開する文章のように品質が要る作業を、弱いモデルで書いてしまい、看板になる成果物の質が落ちる。

どちらも「動いてはいる」ので、エラーとして表に出ません。無人だからこそ、静かに損が積み上がります。私が最初に規律として言語化したのは、この「見えない取り違え」を構造から消すことでした。

私の環境では、この危うさが特にはっきり出ます。1台の Mac mini の上に、性質のまったく違うジョブが同居しているからです。AIニュースの収集や下書きの移植のような機械寄りの作業もあれば、記事の執筆やニュースまとめのように品質が最優先の作業もあります。

これらを「マシンのデフォルト1種類」で一律に回すと、どう転んでも損をします。デフォルトが上位モデルなら機械作業まで高くつき、デフォルトが標準モデルなら執筆の質が落ちる。同じ1台に同居している以上、ジョブごとにモデルを指定する以外に、両方を成立させる方法がありませんでした。

第一の規律：無人便は必ず --model を明示する

私の運用では、cron / launchd から呼ぶすべての claude -p に --model を書くことを絶対ルールにしています。「マシンのデフォルト依存」を禁止する、というのが規律の中身です。

やることは単純で、起動コマンドに一語足すだけです。

❌ claude -p "<タスク>"（デフォルト依存＝どのモデルか不定）
⭕ claude -p --model <モデル> "<タスク>"（ジョブごとにモデルを固定）

たった一行ですが、これで「そのジョブが何のモデルで走るか」が起動コマンドを見た瞬間に確定します。後からログを追わなくても、ジョブ定義そのものが仕様書になります。無人化で怖いのは想定外の挙動なので、想定を1箇所に固定できる意味は大きいです。

claude -p に --model を明示する場合としない場合の違い。未指定はマシンのデフォルト依存で課金膨張・品質低下、明示はジョブごとにモデル固定でコストと品質が想定どおりに収まる

明示したモデルが効いているかを確認する

もう一つ、地味ですが効くのが「本当に指定どおりのモデルで動いたか」をあとから確認できる状態にしておくことです。無人ジョブは見ていない時間に走るので、成功・失敗だけでなく「どのモデルで走ったか」を実行記録に残しておくと、取り違えに事後で気づけます。

私は各ジョブの実行ログと通知に、そのジョブが使ったモデルが分かる情報を残すようにしています。これがあると、万一デフォルトに滑り落ちても「この便だけ想定と違うモデルで走った」とすぐ拾えます。--model の明示が「入口の防御」なら、実行記録は「出口の点検」です。両方あって初めて、無人でも安心して回せます。

無人便を動かす土台そのもの（常時起動のマシンで定期実行を集約する構成）については、こちらで詳しくまとめています。

Claude CodeMac miniをAI自動化サーバーにする｜claude -p×launchdで定期実行を集約

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

第二の規律：役割でモデルを振り分ける

--model を明示すると決めたら、次は「どのジョブに、どのモデルを割り当てるか」です。ここで私が使っている軸は「そのジョブの性質」だけです。難しく考えず、作業の中身で振り分けます。

先に、無人化で一番やりがちな失敗を挙げておきます。それは「とりあえず一番賢いモデルで全部回す」です。対話なら賢いモデルほど快適なので、この発想は自然に出てきます。ですが無人便は本数が多く、しかも毎日走り続けます。定型作業まで最上位モデルで回すと、その割高分が毎日・全ジョブ分だけ積み上がる構造になります。無人だからこそ「一番賢いモデルを既定にする」が一番効きにくい、というのが私の実感です。だから私は、フロアを標準モデルに置き、品質が要るジョブだけを上に引き上げる形にしています。

定型・機械系ジョブ＝ Sonnet（フロア）

整形・移植・重複チェックのように、手数は多いけれど判断が少ない作業は、標準クラスのモデル（Sonnet）に寄せます。私はこれを「無人便のフロア（下限）」と呼んでいます。迷ったらまずここ、という基準です。

定型作業に上位モデルは要りません。むしろ、無人で大量に回る定型ジョブこそ、モデルを一段下げるだけでコストがまとまって効いてきます。

実名で公開する執筆ジョブ＝ Opus 4.8

一方で、記事やニュースまとめのように、実名で世に出す文章を書くジョブには、上位モデル（Opus 4.8）を割り当てています。ここは品質がそのまま看板になるので、コストより文章の質を優先する、と割り切っています。

「全部を安いモデルで」でも「全部を高いモデルで」でもなく、看板になる出力にだけ上位モデルを集中投下する。これがコストと品質の両立点でした。

司令塔・複雑な判断＝上位モデルに集中

複数のタスクを分解して差配する司令塔役や、対話で難所を突破する場面には、上位モデルを充てます。ここも「安く済ませる」対象ではなく、投資して速く正解に着く場所だと考えています。

ジョブの性質でモデルを振り分ける表。定型・機械系はSonnet、実名で公開する執筆はOpus 4.8、司令塔・複雑な判断は上位モデル。フロアはSonnet

この考え方を表にすると、無人便のモデル割り当てはこうなります。

ジョブの性質	割り当てるモデル	理由
定型・機械系（整形・移植・重複チェック）	Sonnet（フロア）	手数は多いが判断が少ない。上位モデルは過剰
実名で公開する執筆（記事・まとめ）	Opus 4.8	品質が看板になる。文章の質を優先
司令塔・複雑な判断・難所の突破	上位モデル	速く正解に着くための投資対象

モデルの使い分けを、対話も含めてより広く設計する話（司令塔モデルを立てて複数モデルを差配する運用）については、こちらで整理しています。

Claude CodeFable 5を司令塔に｜Claude Codeマルチモデル運用術

モデル以外に効く、無人化のコスト規律

モデルの固定と振り分けが土台ですが、無人で回す以上、モデル以外にも決めておくと事故が減る規律があります。私が実際に入れているのは次の2つです。

ジョブの直列化：時刻が重なった無人ジョブが同時に走ると、片方が片方の作業途中を壊すことがあります。私はジョブを直列化するロックを入れ、同時起動そのものを構造的に防いでいます。
書き込み範囲の限定：無人ジョブが触れてよい場所を、あらかじめ決まったディレクトリだけに絞っています。万一暴走しても、被害がその範囲から外に出ないようにするためです。

いずれも「うまく動くこと」ではなく「壊れたときに被害を局所化すること」を狙った規律です。無人化は、成功時の効率より、失敗時の損をどこまで小さく設計できるかで安定性が決まります。

コストの上限そのものを仕組みで守る話（予算上限を設定して課金事故を防ぐ）は、こちらもあわせて参考にしてください。