はじめに
現役の高校教員（数学）です。エンジニアではありません。
Claude Codeには複数のモデルがあり、切り替えて使えます。しばらく「なんとなく重そうな作業のときは上位モデル」で使っていたのですが、これがうまくいきませんでした。
「重そう」の判断が、その日の気分で変わるからです。
そこで、判断基準そのものをファイルに書いて固定しました。この記事はその話です。
1. なんとなく切り替えるのは失敗する
最初の運用はこうでした。
難しそうなときは上位モデル、簡単そうなときは軽いモデル
問題は「難しそう」の中身が曖昧なことでした。実際に起きたのは、
- 入力量が多い作業を「重い」と誤認する：ファイルをたくさん読むだけの整理作業に上位モデルを使ってしまう
- 逆に、短いけれど難しい作業を軽く見る：数行の質問だが、複数の資料の数字を突き合わせる必要がある、というケース
つまり私は**「作業の量」を「作業の難しさ」だと思っていました**。この2つは全然別物でした。
2. 判断基準を「ステップ数」に変えた
見直して立てた基準はこれです。
答えにたどり着くまでに、順番に踏まなければならない手順が何ステップあるか。
量ではなく、依存関係のある手順の長さです。
- ファイルを100個読んで一覧にする → 100回の独立した作業。ステップ数は1
- 3つの資料の数字を突き合わせて矛盾を探す → 前の結果が次の判断に影響する。ステップ数が深い
後者のような作業は、途中で1回間違えると最後まで間違ったままになります。ミスが後段に伝播する作業ほど、推論の深さが結果に直結する。ここが切り替えの軸になりました。
3. 書いた指示書
判断基準をファイルに書き出しました。だいたいこういう内容です。
上位モデルを使う場面
- 複数の資料をまたいで数字の矛盾や古い前提を洗い出す監査
- 長期のシミュレーションの設計（前提が積み上がっていくもの）
- 契約書のような、条件の絡み合った文書を読み解く作業
- 頻度の目安：月1回〜四半期に1回
軽いモデルで十分な場面
- 台帳やチェックリストの数字の記帳・更新
- ファイル・フォルダの整理整頓
- 検索・情報収集、ブラウザ操作
- 日常的な相談・雑談ベースの質問
書き出してみると、軽いモデルで足りる作業が圧倒的に多いことが分かりました。私の場合、9割はこちらです。
4. 基準を決められたのは、失敗の実例があったから
この基準は机上で考えたものではありません。実際に見落としが起きた一件が根拠になっています。
ある時、複数のファイルにまたがる数字を突き合わせる作業をしました。そこで、
- ある項目の月額が、実態より約2.5万円少なく計上されていた
- 同じ数値の見込み額が、3つのファイルで3通りに分裂していた
という問題が見つかりました。どちらも、1つのファイルを見ているだけでは絶対に気づけません。「Aのファイルのこの数字と、Bのファイルのこの数字が、Cの前提と合わない」と一つずつ照合して初めて出てきたものです。
この経験があったので、「複数文書の突き合わせ＝深いモデル」を基準にできました。
逆に言うと、記帳や整理を軽いモデルで回してきた実績もありました。速度も精度も問題なかった。だから安心して軽い方に倒せます。
両方の実例があって初めて、線が引けたということです。基準を先に決めようとしていたら、たぶん決められませんでした。
5. 指示書にした効果
ファイルに書いたことで、こう変わりました。
| 前 | 後 | |
|---|---|---|
| 判断 | その場の気分 | ファイルを見る |
| 判断者 | 自分 | AI自身に判断させられる |
| ブレ | 日によって違う | 固定 |
3行目が一番大きいです。
指示書があると、作業を頼んだときに「これは上位モデル向きです」と向こうから言ってもらえるようになります。自分で毎回考えなくてよくなりました。
非エンジニアにとって、この「判断そのものを外に出す」効果は大きいと思います。ツールの使い分けを覚えるより、判断基準を書いておく方が楽です。
6. ついでに整理した、もう一つの軸
モデルの使い分けとは別に、そもそもどのClaudeを使うかという軸もあったので、同じファイルに書きました。
| 向いていること | |
|---|---|
| チャット版（Web/アプリ） | 考える・迷う・知る。正解のない相談、一般知識、文章の推敲 |
| Claude Code | 作る・計算する・実データを触る。手元ファイルの解析、スクリプト作成 |
判断軸は単純で、
手を動かす作業か、頭を使う相談か。
そして重要な点として、実データを含む処理はローカルで動くClaude Codeに寄せると決めました。家計のCSVや校務のファイルは、手元で読んで手元で処理できる方が安心です。
この2つのClaudeは直接会話できないので、判断や経緯を書いたMarkdownファイルを1つ持って、それをバトンとして渡す運用にしています。チャットで決めたことをファイルに書き、Claude Codeがそれを読んで作業し、ファイルを更新する。次にチャットで相談するときは、また同じファイルを渡す。
これで文脈が途切れなくなりました。
7. まとめ
| 学び | 中身 |
|---|---|
| 「量が多い＝重い」ではない | 独立した繰り返しは軽い。依存関係のある手順が深いと重い |
| 基準は実例から作る | 失敗例と成功例の両方が無いと線が引けない |
| 基準はファイルに書く | 判断自体をAIに委ねられるようになる |
| 使い分けの軸は複数ある | モデルの軸と、ツールの軸は別物 |
| 文脈はファイルで受け渡す | 直接つながらないAI同士は、Markdown1枚でつなぐ |
おわりに
モデルの使い分けというと技術的な話に聞こえますが、やったことは「自分の判断を言語化してファイルに置いた」だけです。
非エンジニアがAIを日常的に使うとき、たぶん一番効くのはこの手の地味な運用ルールだと思っています。賢い使い方を覚えるより、迷わない仕組みを作る方が続きます。
次は、Power AppsとSharePointで校内向けアプリを作ってライセンスの罠にはまった話を書く予定です。