この記事でわかること
結論から言うと、Fable 5がプランから外れる直前の週末にやってよかったのは、スキルを「書かせる」ことじゃなくて「監査させる」ことだった。
うちのClaude Code環境には自作スキルが40本以上ある。その主力4本をFable 5にレビューさせたら、2本は改修案が返ってきて、2本は「これは直す必要がない」と返ってきた。この「直すな」が返ってくるかどうかが、上位モデルに仕事を任せる時の分かれ目だと思っている。
この記事では、期限2日前に実際にやった手順（検証→監査→引き継ぎ書→実行テスト）と、途中で踏みかけた罠を書く。Fable 5がもう使えない人にも、「高いモデルと普段のモデルをどう分業させるか」の設計はそのまま使えるはず。
記事概要図
きっかけは「7/7で使えなくなる」という話題のポスト
7月頭、Xで「Fable 5にOpus 4.8用のSkillを書かせろ。期限は7/7」というポストが流れてきた。Fable 5はAnthropicの最上位モデルで、うちのプランでも使えていたんだけど、提供が2026-07-07までで、以降は従量課金のみになるという内容だった。
こういう「急げ」系のポストは半分くらい煽りなので、まず裏を取った。結果、期限は公式発表どおりの事実。ただし「最強モデルに触れる権利が永久に消える」は誇張で、公式は容量が確保でき次第サブスクへの復帰を目指すと明言していた。従量課金の単価はOpus 4.8のちょうど2倍。つまり「消える」ではなく「気軽には使えなくなる」が正確なところ。
残り2日。何をやらせるかを決める必要があった。
いきなり「スキルを書いて」とは頼まなかった
元ポストの主旨は「上位モデルにスキルを書かせて、普段のモデルで回せ」だった。理屈は分かる。でもリサーチの過程で、実践者のリプに気になる指摘があった。
上位モデルが書くスキルには、「上位モデルの推論力がないと動かない前提」がこっそり混ざる。
たとえば「質を判断して適切に対応せよ」みたいな指示。Fable 5はこれで動けてしまうけど、普段のモデルに渡すと「適切」の基準がなくて迷走する。書いた本人（Fable）には自明でも、引き継がれた側には自明じゃない。
これ、SEの現場で見たことある光景なんだよね。エースが書いた「分かってる人向け」の手順書。本人が異動した瞬間に誰も運用できなくなるやつ。
だから頼み方を変えた。「新しくスキルを書いて」ではなく、**「すでに運用実績のあるスキルを監査して、普段のモデルが迷う箇所だけ直して」**にした。ゼロから書かせると前提の混入に気づけないが、既存スキルのレビューなら差分で判断できる。
役割分担で言うとこうなる。上位モデルが持つのは管理・監査・改善案——つまり成果物への最終責任。実作業は普段の下位モデルが担う。 高い方に手を動かさせるんじゃなくて、高い方にはレビュアー席に座ってもらう。単価2倍のモデルの使い道としては、この方が理にかなっている。
監査の結果：4本中2本を改修、2本は「直すな」
主力4本（X投稿・週次確認・投資監視・デバッグ）を投げた結果がこれ。
| スキル | 判定 | 改修内容 |
|---|---|---|
| X投稿 | 改修 | 到達基準3点＋「見送り推奨」の選択肢を明文化 |
| 週次確認 | 改修 | ゴールと境界（20分・数字が取れなければ未取得と書く等）を追加 |
| 投資監視 | 合格・改修不要 | 判断基準が既にルール化済みと判定 |
| デバッグ | 合格・改修不要 | 合否判定コマンドで完結していると判定 |
面白かったのは改修内容より、2本を「直す必要がない」と返してきたことの方だった。
AIに改善レビューを頼むと、大抵は頼んだ分だけ改善案が返ってくる。良かれと思って全部に手を入れてくる。でもFable 5は「この2本は判断基準がすでに外部化されているから触るな」と判定した。仕事を頼まれた側が「やらない」を選択肢に持っているかどうか。人間のレビュアーでも、これができる人は信頼できる。
改修の方向は4本とも一貫していた。手順の羅列ではなく「ゴール＋境界＋理由」で書き、「質を判断せよ」は合否線の表に変換する。 理由が書いてあると、下位モデルは手順の隙間を自力で埋められる。逆に理由のない細かい手順は誤実行の元になる。
引き継ぎ書には「迷った時のデフォルト」を書かせた
スキル監査と並行して、もう1つ頼んだのが引き継ぎ書だ。スキルは作業単位のルールだけど、その間を埋める「その場の判断」はスキルに載らない。そこでFable 5本人に「あなたが感覚でやっていた判断を、後任がルールで再現できる形で書き出して」と頼んだ。
出てきたのが「迷った時のデフォルト」という節で、中身はこんな感じ。
- 投資判定に迷ったら「見送り」（見送りも記録する）
- 公開してよいか迷ったら止めて確認
- 記事の質に迷ったら「未達＋どこが未達か」を添えて相談（未達を「できました」と言い切るのが最悪の失敗）
- 数字が取れなかったら「未取得」と書く（推定で埋めない）
どれも書かれてみれば当たり前なんだけど、この「当たり前」が明文化されていないと、モデルが変わった瞬間に判断がブレる。人間のチームで引き継ぎ書を書く時と、やることが本当に変わらない。
Opusで実行テストするまでが引き継ぎ
最後の工程が実行テスト。改修したスキルを、実際に引き継ぎ先のOpusに1回実行させて、基準が曖昧で判定に迷う箇所が残っていないかを確認した。ここは元ポストのリプで実践者が口を揃えて言っていた工程で、飛ばすと「Fable前提の混入」に本番で気づくことになる。
結果は合格。翌週からは実際にOpusと改修済みスキルで週次確認や記事作業を回しているけど、今のところ「基準がなくて迷走する」場面には当たっていない。
SE的にまとめると、これは新しいテクニックというより退職するエースエンジニアへの引き継ぎ依頼そのものだった。①本人に自分の暗黙知を文書化させる ②既存ドキュメントを「後任が読める形か」でレビューさせる ③後任に一度実務をやらせて詰まる箇所を潰す。相手がAIでも、この3点セットから逃げられない。
3つの結論
- 上位モデルには「書かせる」より「監査させる」。ゼロから書かせると上位モデル前提が混入する。実績あるスキルのレビューなら差分で判断できて、「直すな」という判定も返ってくる。
- 「質を判断せよ」を合否線の表に変換するのが引き継ぎの核。理由付きのゴールと境界があれば、普段のモデルは手順の隙間を自分で埋められる。
- 引き継ぎ先のモデルで実行テストするまでが引き継ぎ。書いて満足した時点では、まだ何も引き継がれていない。
モデルの使い分け設計そのものは、以前書いたeffort設定とモデル使い分けの話が土台になっている。あと「AIに自分の暗黙知を文書化させる」の記事執筆版はSOUL.mdで外部記憶を持たせた話でやっているので、興味があればどうぞ。
Claude Codeやプロンプト設計を体系的に学ぶなら、Udemyの講座をセール時に拾うのがコスパがいい。Udemyで講座を探す（セール時が狙い目）
