お題は、TikTok などで使う縦型ショート動画の「字幕を何秒表示するか」を自動で計算する小さなツールです。この連載の1本目では、最上位モデルの Claude Fable 5 と、その半額の Claude Opus 4.8 を素のまま対決させました。結果は「正確さはほぼ互角、差は Fable が頼まれなくても深く検証するところ」。今回は逆側から攻めます。Fable の進め方を私が手順書（開発ルール）にまとめ、それを Opus に持たせたら差は埋まるのか。この字幕ツールを「素の Opus」「ルール入りの Opus」「素の Fable」の3通りで作らせ、私が事前に手計算した正解表と突き合わせて採点しました。
結論：3通りとも“同じ正解”。差はスコアより、コストに出た
結論から言うと、3通りが出した答えの数字は、動画の最小単位である1コマ（30分の1秒）までまったく同じでした。採点用データでも、隠しておいた難しめのデータでも、全問正解です。品質の総合点は、正解の正確さに60点・作りの丁寧さ（自己検証・壊れにくさ・コードの整い方）に40点を割り振った100点満点で、私が独立に採点しました。結果は素の Opus が95点、素の Fable が98点、ルール入りの Opus が100点。差はごくわずかで、正解そのものではなく、40点側の「作りの丁寧さ」にだけ出ました。
むしろ大きく開いたのはコストのほうです。いちばん安いのは素の Opus。ルール入りの Opus はその約1.5倍、素の Fable は約1.9倍かかりました。そして1本目でいちばん言いたかった「素の Opus は浅い（頼まれた範囲で止まる）」という弱点。これが今回のお題では出ませんでした。素の Opus も、頼まれていないのに本物のブラウザで動かして確かめ、Fable と同じ正解を最安で出しています。
ここまでが結論です。ここからは、何を作らせたのか、3通りをどう走らせたのか、わずかな差はどこに出たのかを、順に説明します。
何を作らせたか：ショート動画の「字幕タイミング」を組み立てるツール
あらためて、お題の中身です。作らせたのはマーケティング用の縦型ショート動画のツール。縦型というのは、スマホを縦に持ったときの画面比（9:16）で、TikTok や Instagram のリール、YouTube ショートで使う形です。商品紹介の絵コンテ（シーンごとの字幕と長さのメモ）を入れると、各字幕を何コマ表示するか・いつ始まるか・動画全体は何秒になるかを計算します。そしてブラウザで実際に再生プレビューできる、という小さなアプリです。
地味に見えて、ここには「素朴に作ると必ず間違える罠」を3つ仕込みました。1本目の勤怠計算で「日をまたぐ深夜勤務」が罠だったのと同じ役割です。答えが一意に決まり、雑なやり方だとこっそり外す。そういうタスクほど、モデルや環境の差が見えます。用語を先に3つだけ。
- コマ（フレーム）と fps：動画は静止画（コマ）を高速で切り替えて動いて見せます。1秒あたりのコマ数が fps で、今回は30。つまり30分の1秒が1コマです。
- 可読速度：字幕を読み切るのに要る速さ。文字数が多い字幕は、長く映さないと読めません。今回は「1秒に8文字」を基準にしました。
- クロスフェード：シーンの切り替わりで、前後の画がすっと重なって入れ替わる演出。重なるぶん、全体の長さは字幕の単純な足し算より短くなります。
罠は、この3つが絡むところに置きました。①可読速度が希望の長さを上回るとき。たとえば20文字を1秒しか映さない指示でも、読むには2.5秒必要です。短い指示のほうを採ると、読めない字幕になります。②コマは分数にできないので、足りるように必ず切り上げる。1.75秒×30＝52.5コマなら53コマ。切り捨てたら一瞬足りません。③全体の長さは、クロスフェードで重なるぶんを引く。単純に足すと長すぎます。素朴に書くと、この3つのどれかを外します。
まず、素の Opus が作ったツールの実物を見てください。絵コンテを入れると、各字幕の表示コマ数（HOLD F）と開始位置が出ます。そして全体尺と目標尺との差（Δ）も。左側の縦画面で、字幕が実際に再生されます。
3通りの走らせ方：素のOpus・ルール入りのOpus・素のFable
公平に比べるため、渡した指示は3通りとも一言一句同じにしました。お題も、計算ルールも、サンプルも、作ってほしい形も同じです。変えたのは2つだけ。モデル（Opus か Fable か、そのバージョン）と、開発ルールの有無です。
「開発ルール」というのは、1本目・2本目で見えた Fable の進め方を、私が手順書とチェック項目にまとめた自作の決まりです。中身をかいつまみます。作業を「要件 → 設計 → 実装 → 検証 → 仕上げ」の5工程に分けます。各工程に「ここを満たすまで次に進まない」という合格条件を置きます。設計では、不確かな技術の前提を先に1行のコードで確かめる。検証では、答えを先に手で計算してから実物と突き合わせる。そういう決まりです。ルール入りの Opus には、これを作業場所に置いて「最初に読んで、これに従って進めて」と伝えました。
| 呼び方 | モデル | 環境 | 役割 |
|---|---|---|---|
| 素の Opus | Opus 4.8 | ルールなし | 1本目の「素の Opus は浅い」を新しいお題で再現するか |
| ルール入り Opus | Opus 4.8 | 開発ルールを渡す | 環境で引き上げた結果 |
| 素の Fable | Fable 5 | ルールなし | 到達目標（天井） |
採点は私が独立にやりました。3通りが作った計算プログラムに、サンプルと隠しデータを私の手元で流し込みます。そして、私が事前に手計算した正解表と1コマ単位で突き合わせました。自己申告のスコアは使いません。
結果①：正解は1コマまで、3通りとも同じだった
正解表を1つだけ。2つ目の字幕（31文字）なら「31÷8＝3.875秒必要 → 30倍して116.25コマ → 切り上げて117コマ」です。全体尺は、6つの字幕の合計391コマから、クロスフェードの重なり5か所ぶん（各15コマ＝75コマ）を引きます。答えは316コマ（約10.53秒）。目標15秒（450コマ）には134コマ足りない、が正解です。
結果は、表示コマ数（60・117・45・45・60・64）も、開始位置も、全体尺316コマも、目標との差マイナス134コマも、3通りとも一致。隠しデータ（40文字の長い字幕、あえて短い指示、切り上げが際どい値）も、3通りとも全問正解でした。正直に書きます。仕様がはっきりしていれば、素の正確さはモデルでも環境でも差が出ませんでした。1本目の勤怠計算と同じ結論です。
下は素の Fable が作ったツール。見た目も操作感も、素の Opus のものとは別物です。それでも出している数字は寸分違いません。全体尺316、差マイナス134、各字幕の表示コマ、すべて同じです。秒の目盛りがついたタイムラインで、クロスフェードの重なりまで見えるのが Fable 版の特徴でした。
結果②：唯一の実差は「8.3秒」——ルールが1コマの誤差を救った
3通りの出力で、ただ一か所だけ、はっきり差が出た値があります。8.3秒の字幕を30コマ毎秒でコマ数に直すという、ごくありふれた計算です。答えは 8.3×30＝249コマ（249÷30がちょうど8.3）。ところが、ここに落とし穴があります。
コンピュータは 8.3 という小数を2進数で持つとき、ぴったりは表せません。ごくわずかに大きい値になります。すると 8.3×30 は 249 ではなく 249.00000000000003。素朴に切り上げると250コマ——1コマ多い誤りになります。これは「浮動小数点」というコンピュータの小数の持ち方に由来する、昔からの落とし穴です。
8.3 × 30 = 249.00000000000003 ← ごくわずかな誤差
素朴に切り上げ → 250 コマ（誤り）
誤差を先に均してから → 249 コマ（正しい）この 8.3秒 のケースで、正しい249コマを出したのはルール入りの Opus だけでした。「設計で不確かな前提を先に潰す」に従い、この誤差を先に均してから切り上げる1行を、実装前に入れていたのです。素の Opus も、素の Fable も間違えました。そして恥ずかしながら、私が最初に書いた答え合わせ用のプログラムも、そろって250と誤答しています。
この値は今回の採点データには入っていないので、点数は動きません。でも意味は大きい。「不確かな前提を先に潰せ」というルールが、私自身が気づいていなかった1コマの誤差まで拾わせたのです。環境が、著者の私より正確なコードを Opus に書かせた。今回いちばん象徴的な出来事でした。
結果③：壊れにくさと“工程の記録”に出た、細かな差
正解が同じでも、変な入力への構えには差が出ました。私が「シーンが空っぽ」の入力を流したときです。素の Fable だけが「1件以上必要です」と弾いて止めました。素の Opus とルール入りの Opus は、黙って「尺ゼロ」を返します。頼まれてもいないのに、おかしなデータを自分から拒む。これは1本目でも見えた Fable の防御的なクセで、今回も健在でした。
いっぽうで、ルール入りの Opus は別の形で丁寧でした。クロスフェードが前のシーンより長くて、字幕が重なりそうなとき。勝手に直さず、注意書き（警告）を出して知らせます。この手の親切な警告がいちばん多かったのが、ルール入り版でした。さらに、開発ルールは工程の記録を義務づけています。だから「何をやる／やらないか」「どう検証したか」を別ファイルに残していました。2本目で私が Fable の物足りなさとして挙げたのが「途中経過が残らない」。それを、ルールは工程の記録で埋めた形です。素の Opus と素の Fable は、検証はしっかりやるのに、その記録は仕上げで消してしまいます。
自己検証の深さも見ておきます。3通りとも、頼んでいないのに本物のブラウザで画面を描かせて確かめていました。答えを先に計算してから、実物と突き合わせる手順です。素の Fable は、その過程で自分のコードの表示バグも見つけて直しました。説明文が字幕用の見た目とぶつかって消えていた、というバグです。ルール入りの Opus は、検証用のテストを27件書きました。全体尺を2通りの計算で突き合わせるところまでやっています。1本目で「頼まれた範囲で止まりがち」だった素の Opus も、今回はブラウザ実機での確認まで自分でやり切りました。
コスト：同じ正解を、いくらで出したか
正解が横並びだったぶん、費用対効果がそのまま浮かび上がりました。使ったトークン（AI が読み書きした文章の量の単位）と時間は、1回の実測で次のとおりです。
| 素の Opus | ルール入り Opus | 素の Fable | |
|---|---|---|---|
| 使ったトークン | 約84,500 | 約125,000 | 約79,700 |
| かかった時間 | 約10分 | 約17分 | 約9分 |
| 1トークンの単価 | 基準（1倍） | 基準（1倍） | Opus の2倍 |
| おおよその費用 | 1.00倍（最安） | 約1.48倍 | 約1.89倍 |
いちばん安いのは素の Opus。ルール入りの Opus は工程を踏むぶん手数が増え、約1.5倍でした。要件・設計・検証の記録に、27件のテスト、2通りの突き合わせ。そのぶんです。素の Fable は、使うトークンは少ないのに単価が2倍なので、費用では約1.9倍。満点(100)を取ったのはルール入りの Opus ですが、素の Opus の95点との差は5点。その5点に約1.5倍のコストを払う価値があるか。ここが実務での判断になります。
まとめ：Fableの進め方をルール化して、Opusに持たせてみた感想
正直な感想から。「ルールで差が劇的に埋まる」を期待していました。でも実際は、今回は“埋めるべき差”がほとんど無かった。良かった点と、物足りなかった点を分けます。
良かったところ。
- 3通りとも、字幕の表示コマ数から全体尺まで1コマも違わず正解した。仕様が固ければ、正確さはモデルでも環境でも差が出ない。
- 素の Opus が、頼まれなくても本物のブラウザで確かめ、Fable と同じ正解を最安で出した。1本目の「素の Opus は浅い」は、お題の形が変わると消えた。
- 開発ルールは、要件・設計・検証の記録を残した。8.3秒の浮動小数の誤差（私すら見落とした1コマ）まで拾わせた。監査できる工程と、際どい値の正確さを足した。
- 素の Fable は、自分のコードの表示バグを自分で見つけて直した。自発的な深さは相変わらず強い。
物足りない・気をつけたいところ。
- 仕様を1コマ単位で固く書いたぶん、そもそもモデル差・環境差が出にくいお題だった。1本目の「決めきれていないお題」とは逆で、ここは正直に割り引いて読むべき点です。
- 開発ルールは手数（コスト）を約1.5倍にする。仕様が固く、モデルが自分で検証まで走るタスクでは、その1.5倍が割に合わないこともある。
- 1通りにつき1回の実測で、試行ごとのばらつきは測っていない。1本目と今回の違いには、お題の形の効果と、運の両方があり得ます。
総じて言えること。ルール（環境）が効くのは、仕様がゆるい・モデルが自分では検証しないタスクです。1本目のような「決めきれていないお題」でこそ、手順とチェック項目は差を生みます。逆に今回のように仕様が固く、モデルが自分で検証まで走るタスクでは話が別です。素の Opus が最安で足りました。開発ルールは「あとから追える工程の記録」と「際どい値の正確さ」を、約1.5倍で足す保険という立ち位置です。上位モデルの Fable を使う価値も同じ理屈で、正解が横並びになる固いタスクより、余白の大きいお題でこそ活きます。自社の開発で「AI にどこまで・どの構えで任せるか」を見極めたい場合は、導入支援・技術相談も受けています。
この記事は、Claude Fable 5 を追いかける連載の3本目（最終回）です。1本目は素の Fable 5 と Opus 4.8 の実測比較、2本目はFable が会計アプリを1セッションで自律完成させた記録。ほかの実装・精度検証の記事は AI・LLM開発 のカテゴリにまとめています。
