0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「特定モデル前提」のアンチパターン5つ。Fable 5が3日で消えたので見直したNG例と直し方

0
Posted at

6月、Claude Fable 5が公開からわずか3日で提供停止になりました。7月1日に復帰しましたが、あの3日間で自分の考えは変わりました。モデルの供給停止は、障害ではなく「消失」です。数時間で戻る前提が通用しない。

自分は当時、OpusとFable 5の使い分けを検討して財布の計算までしていた側で、比較対象そのものが消えるのを目の当たりにしました。使い込む前だったので実害はほぼゼロ。でも、もし本番のワークフローがFable 5前提だったら、と考えてぞっとしました。

そこで、自分のコードと運用から「特定モデル前提」を洗い出しました。見つかったNGを5つ、直し方つきで並べます。

  1. モデルIDをコードに直書きする
  2. コスト計算を1つのモデル前提で組む
  3. 品質の判定を「モデルの評判」に置く
  4. プロンプトを特定モデルの癖に合わせ込みすぎる
  5. 切り戻し手順を用意していない

1. モデルIDをコードに直書きする

いちばん多くて、いちばん掘り起こすのが面倒なやつです。

// ❌ NG:呼び出し箇所ごとにモデルIDを直書き
$response = $client->messages(['model' => 'claude-fable-5', ...]);
// 別のファイルでも
$summary = $client->messages(['model' => 'claude-fable-5', ...]);
// ✅ OK:参照を一箇所にまとめる
// config.php
define('MYPLUGIN_MODEL_MAIN', getenv('MYPLUGIN_MODEL') ?: 'claude-opus-4-8');

// 呼び出し側
$response = $client->messages(['model' => MYPLUGIN_MODEL_MAIN, ...]);

なぜ。直書きが散らばっていると、モデルが消えた日にgrepで全箇所を掘り起こして書き換えることになります。参照を一箇所(定数・設定・環境変数)に集めておけば、差し替えは1行です。自分の場合、この整理は数十分で終わりました。事が起きる前にやるか、起きてから慌ててやるかの違いだけです。

2. コスト計算を1つのモデル前提で組む

❌ NG:「Fable 5ならこの構成が最安」まで詰めて、それだけ持つ
(前提のモデルが消えると、計算ごと消える)
✅ OK:第一候補+切り戻し先の、雑な複線で持つ
・第一候補: Fable 5 で月およそ X 円
・切り戻し先: Opus 4.8 で月およそ Y 円(1.n倍)
→ 精密な一本より、雑でも二本

なぜ。単価が違うモデルへ急に切り替わると、月のコストは黙って跳ねます。精密に最適化した一本の計画は、前提が消えた瞬間にゼロになる。概算でいいので切り戻し先の数字まで持っておくと、消えた日に「いくら増えるか」が即答できます。正直、計算を詰めるのは楽しいので複線は少し悔しいのですが、楽しさと頑丈さは別でした。

3. 品質の判定を「モデルの評判」に置く

❌ NG:「新モデルはベンチマークが高いから大丈夫」で乗り換える
(自分のタスクで同じ水準が出るかは、別の話)
✅ OK:自分のタスクの合格基準を、手元に持つ
・代表的な入力と期待する出力のペアを数件、ファイルにしておく
・乗り換えたら、まずそれを流して見比べる
・コードならテスト、文章なら自分のチェックリストで判定

なぜ。モデルを乗り換えたとき、いちばん怖いのは「静かに質が落ちる」ことです。世間の評判は自分のタスクの保証をしてくれません。判定の軸(仕様・テスト・見本ペア)を自分側に持っておけば、モデルは差し替え可能な部品になります。軸をモデル側に置くと、乗り換えのたびに感覚で測り直すはめになります。

4. プロンプトを特定モデルの癖に合わせ込みすぎる

❌ NG:暗黙の挙動に依存した省略だらけの指示
このモデルはこう書けば察してくれるから、短くこれだけ。
✅ OK:どのモデルでも通じる、明示的な指示に寄せる
・前提、制約、出力形式を省略せずに書く
・「察し」に頼っていた部分を、条件として文章化する

なぜ。特定モデルの「察し」に最適化した省略プロンプトは、乗り換えた瞬間に精度が崩れます。明示的に書かれたプロンプトは、モデルをまたいでも劣化がゆるやかです。チューニング自体は悪くありません。ただ、何を省略して何に依存しているかを自分が分かっていない状態が危ない。一度、省略なし版を正として残しておくと安心です。

5. 切り戻し手順を用意していない

❌ NG:「消えたら考える」
(消えた日は、考える余裕がいちばん無い日です)
✅ OK:切り戻しの手順を、平時に1枚書いておく
・切り戻し先モデル: (名前)
・変更箇所: config.php の1行(NG1を直してあれば、ここが1行で済む)
・確認: 見本ペアを流して出力を見比べる(NG3の資産をそのまま使う)
・コスト影響: 月およそ +Y 円(NG2の複線から転記)

なぜ。1〜4を直してあれば、切り戻しは「1行変えて、見本を流して、費用をメモで確認」で終わります。手順書といっても数行です。あるかないかで、消えた日の落ち着きがまるで違います。

早見でまとめ

  • モデルIDは一箇所に。差し替え1行の形にしておく
  • コストは第一候補+切り戻し先の複線。雑でいい
  • 合格基準(テスト・見本ペア)は自分側に持つ
  • プロンプトは明示的に。特定モデルの「察し」に依存しない
  • 切り戻し手順を平時に数行書いておく

3日で消えて、3週間で戻る。フロンティアモデルはこの振れ幅ごと付き合うものになりました。モデルに惚れ込むのは楽しいですし、これからもすると思います。惚れ込んだ相手にワークフローを人質に取られない準備だけして、あとは気持ちよく使えばいい。役に立ったらストックして、次のモデル騒ぎのとき見返してください。


ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?