Claude Mythos 5を使わなかった反省。高いAIモデルを本当に働かせる使い方

高いAIモデルは、毎日の作業を少し速くするためではなく、あとで何度も使う仕組みを作るために使うべきだった。
Claude Mythos 5、あるいは自分の中で Minos と呼んでいた高性能モデルを使える時期があったのに、私はほとんど使わなかった。

理由は単純です。
高いモデルを使うと、自分が使えるトークンが減ると思ったからです。

その後、Anthropicは米国政府の輸出管理指令により、Fable 5 と Mythos 5 へのアクセスを停止したと発表しました。
使える時期に使わなかった。だからこそ、何に使うべきだったのかを残しておきます。

その判断は、半分正しかった。
でも、半分は間違っていました。

日常の作業に使えば、たしかに消費は大きい。
けれど、作業の型、判断基準、検証ルールを作らせれば、その1回はあとで何十回も効いたはずです。

使わなかった理由は、もったいなさだった

私は「高いモデルを使うほど、残りの消費枠が減る」と考えていました。
だから、普段の作業は軽いモデルで回したいと思っていました。

これは自然な判断です。
AIを毎日使う人ほど、消費量は気になります。

でも、ここで見落としていたことがあります。
高性能モデルを使うべき場面は、毎回の本文生成ではありません。

使うべきだったのは、次のような場面です。

何をやるべきか決める
何をやらないか決める
失敗しやすい場所を先に見つける
再利用できる型を作る
低いモデルでも回せる手順に落とす

つまり、消費するためではなく、消費を減らすために使うべきでした。

Opusより強いという話を見たときに考えるべきだったこと

「Opusの2倍くらいすごい」という話を見たことがあります。
この数字が正しいかどうかは、ここでは断定しません。

ただ、もし本当にそれに近い能力があるなら、使い道はかなり絞るべきです。

高いモデルにやらせるべきなのは、量ではありません。
質の高い最初の分解です。

たとえば、ブログ運用ならこうです。

このブログ運用を見て、
今後30日で再利用できる改善ルールを作って。

ほしいもの:
1. やるべき作業
2. やらない作業
3. 低いモデルに渡す作業
4. 人間が判断する作業
5. 毎回の検証チェック
6. 失敗したときの止め方

こういう依頼なら、1回の高い消費に意味があります。
その結果を、あとでSonnetやCodexや軽いモデルに渡せるからです。

本当に作らせるべきだったもの

反省点ははっきりしています。
私は高性能モデルを「強い作業者」として見ていました。

でも、本当は「設計者」として使うべきでした。

作らせるべきだったのは、次の5つです。

1. 自分専用の作業ルール

毎回の依頼文を短くするために、先にルールを作らせるべきでした。

たとえば、

調査は何行まで
実装前に何を見るか
公開前に何を確認するか
どこから先は人間に戻すか
何をしたら失敗扱いにするか

こういうルールは、一度作れば毎回効きます。

2. 低いモデルに渡すための作業分解

高いモデルに全部やらせる必要はありません。
むしろ、低いモデルが迷わない形に分けさせるのが一番効きます。

この作業を、安いモデルでも失敗しにくい単位に分けて。
各作業に、入力、禁止事項、完了条件を付けて。

これをやっておけば、あとは軽いモデルで回せます。

高いモデルの仕事は、実行ではなく分解です。

3. 検証ルール

AIの出力は、作るより確認が大事です。
高性能モデルには、完成物より先に検証ルールを作らせるべきでした。

ブログなら、

冒頭3行で得が見えるか
H2が検索結果に出ても意味が通るか
参照元が残っているか
内部リンクが自然か
画像やURLを壊していないか

こういうチェックです。

開発なら、

触ったファイル
触らなかったファイル
失敗時の戻し方
テストの範囲
本番に出してよい条件

ここを先に作るだけで、後工程がかなり軽くなります。

4. 自分の弱点の診断

高性能モデルに一番頼むべきだったのは、たぶんここです。

「私の作業のどこが詰まりやすいか」を見てもらう。
これは軽いモデルでもできますが、深いモデルのほうが効く可能性があります。

たとえば、こう頼めばよかった。

私のAI運用のログを見て、
成果につながっていない消費を見つけて。

分類:
- 無駄な探索
- 繰り返し説明
- 完了条件の不足
- 公開前確認の不足
- 人間が決めるべきなのにAIへ投げている判断

最後に、明日から減らす順に並べて。

これは痛いですが、価値があります。

高いモデルは、気持ちよく文章を書かせるより、こういう反省に使ったほうが元を取りやすいです。

5. 1回で終わらない仕組み

一番もったいなかったのは、単発で考えていたことです。

高性能モデルを1回使うなら、その成果物は1回で終わってはいけません。

作るべきなのは、

チェックリスト
テンプレート
AGENTS.md / CLAUDE.md
依頼文の型
記事改善ルール
公開前の確認手順
低いモデルへ渡す作業票

こういうものです。

高いモデルを使った証拠は、長い回答ではありません。
次回から人間の説明が短くなることです。

これからの使い分け

次に同じような高性能モデルが使えるなら、私はこう分けます。

高性能モデル	設計、診断、作業分解、検証ルール、難しい判断に使う。
通常モデル	実行、下書き、軽い修正、確認済み手順の繰り返しに使う。
人間	目的、優先順位、公開判断、何を捨てるかを決める。

この分け方なら、高いモデルを使う罪悪感が減ります。
毎回の消費ではなく、未来の消費を減らす投資になるからです。

高いモデルを使う前の質問

次からは、使う前にこの3つを確認します。

1つ目。
この依頼は、あとで再利用できる形になるか。

2つ目。
この依頼は、低いモデルでは迷いやすい判断を含むか。

3つ目。
この依頼の結果で、次回以降の説明が短くなるか。

3つともYESなら、高いモデルを使っていい。
1つもYESでないなら、通常モデルでいい。

これくらいシンプルでよかったのだと思います。

反省の結論

私は、トークンを節約しようとして、高いモデルを温存しました。
でも、本当に節約したいなら、使わないことではなく、使う場所を絞るべきでした。

高性能モデルは、たくさん書かせるための道具ではありません。
何をどう進めればいいかを、先に固めるための道具です。

もしまた同じ機会が来たら、最初の1回でこう頼みます。

私の作業全体を見て、
今後のAI消費を減らしながら成果を増やすための運用設計を作って。

ほしいもの:
- 高性能モデルでやること
- 通常モデルでやること
- 人間が判断すること
- 毎回使うチェックリスト
- 使いすぎを止める条件
- 明日から使う最小ルール

これを最初にやるべきでした。

高いモデルを使うとは、贅沢に答えを書かせることではない。
次の100回の迷いを減らすことです。