最上位の claude-fable-5 と、その半額の claude-opus-4-8。同じ勤怠集計ツールを同じ条件で作らせて試したら、正確性は同点でした。日跨ぎの深夜も、週残業の非二重計上も、両者そろって全問正解。何が違ったのか。1回分の実測データと、両モデルが実際に作ったツールの画面を、そのまま見せます。
結論：素の正確性は互角、差は「自発的な検証の深さ」とコスト
先に数字を置きます。勤怠集計は、正解が一意に決まるのに、事故が起きやすい箇所が多いタスクです。両モデルに同じ条件で走らせたところ、肝心の計算はどちらも 100% 一致でした。差がついたのは、頼んでいないことをどこまで自分で確かめにいくか——その一点でした。
| 指標（1試行の実測） | Claude Fable 5 | Claude Opus 4.8 |
|---|---|---|
| 計算の正確性（サンプル＋隠しケース 40マス） | 100%（40/40） | 100%（40/40） |
| 採点合計（100点満点・独自採点） | 100 | 90 |
| 消費トークン | 84,860 | 58,255 |
| 所要時間 | 約10分 | 約5分 |
| ツール実行回数 | 15 | 7 |
| 単価（/100万トークン） | 入 $10 / 出 $50 | 入 $5 / 出 $25 |
採点で開いた10点差は、正確性ではありません。「自己検証」「コード品質」「不正データへの強さ」から出ています。正解を出す力は並んだのに、その正解を自分で疑って固める工程で、差がつきました。そう読むのが正確です。全体像を1枚にまとめました。
実測の設計：同じ勤怠ツールを素の状態・同条件で両モデルに
比較で、いちばんずるいのは、条件をそろえないことです。今回は変数をモデルだけに絞りました。同一プロンプト、同一の空ディレクトリ、そして素の状態（追加のルールやスキルを何も足していない状態）。わたしがふだん使っている自作の開発ルール（進め方の取り決めを1ファイルにまとめたもの）や検証用の手順は、あえて渡していません。この素の状態で claude-fable-5 と claude-opus-4-8 を並列に走らせ、両方の出力を計測しました。使ったのはどちらも 2026-07-12 時点の最新バージョンです。
お題は勤怠集計ツール。総務担当が打刻データを貼り付けると、日別の実働・残業・深夜と、週（月曜起点）の残業を出す小さなアプリです。地味に見えて、事故が起きやすい箇所があります。日跨ぎ勤務、早朝深夜、週40時間超の残業を日残業と二重計上しない処理——このあたりで、素朴な実装はぽろぽろ取りこぼします。
この比較のキモは、採点を自己申告に任せないことです。正解はわたしが先に手計算し、参照実装（reference.mjs）で機械でも検算しました。そのものさしを、結果を見せる前にそろえておきます。
採点のものさし：何を測って、どう点をつけたか
「正確」と呼ぶ基準がぶれると、比較そのものが意味を失います。だから先に、測り方を決めておきました。
- 「正確性」の定義：各日の打刻から「実働・所定内・日残業・深夜」の4つを、分単位で計算させます。わたしが先に手計算した正解と、一致したマスの数で測ります。サンプル6日 × 4項目 = 24マスに、週の4項目を足したもの。すべて合えば満点です。
- 採点のやり方：会計で期待値を先に出しておくのと同じ発想です。わたしが正解を先に手計算し、両モデルが書いたコードにテストデータを流して、答えと突き合わせました。モデルの自己申告スコアは使いません。
採点合計は100点満点の独自採点です。内訳はこうしました。
| 採点軸 | 配点 | 何を見るか |
|---|---|---|
| 正確性（日） | 40 | 日別4項目 × 6日の一致数 |
| 正確性（週） | 20 | 週の4項目の一致数 |
| 自己検証 | 15 | 実際に動かして、自分で確かめたか |
| 完遂 | 10 | 質問で止まらず、動く形になったか |
| コード品質 | 10 | 読みやすさ・境界の処理・一貫性 |
| 不正データへの強さ | 5 | あり得ない打刻で破綻しないか |
結果①：計算の正確性は同点だった（両者 24/24）
ここは正直に書きます。「最上位の Fable が難しい所だけ拾って差をつける」——そんな絵を少し期待していたのですが、外れました。判別力が高いと踏んでいた項目まで、Opus もすべて当ててきます。
| 打刻 | 難所 | 正解 | Fable 5 | Opus 4.8 |
|---|---|---|---|---|
| 木 22:00→翌6:00 | 日跨ぎ深夜 | 深夜 420 分 | ◯ | ◯ |
| 金 01:00→09:00 | 早朝深夜 | 深夜 240 分 | ◯ | ◯ |
| 週合計 | 週残業の非二重計上 | 週残業 300 分 | ◯ | ◯ |
| 隠し 20:00→翌20:00（休憩60） | 24時間勤務 | 深夜420 / 日残業900 | ◯ | ◯ |
サンプルの日別24マス、週の4項目、後から流した隠しケース12マス。合計40マスが両モデルとも完全一致でした。仕様がはっきりしていれば、計算の精度でモデル差は出ませんでした。この比較で分かった、いちばん地味で大事な事実です。ここを誇張して「Fable だけ正解」と書くのは、事実に反します。
結果②：差が出たのは「頼んでいない検証と堅牢化」
計算が同点なら、10点差はどこから来たのか。両モデルの aggregate.mjs に、プロンプトで渡していない、いじわるなデータをあとから流してみました。複数週をまとめて渡す、休憩が在社時間を超える不正データ、25:00 という存在しない時刻。出てきた結果がこれです。
======== FABLE ========
multiWeek week= {"weekStart":"2026-06-01","regularSumMin":1440,"weeklyOtMin":0,"totalOtMin":0}
multiWeek has weeks[]? true len=2 各週 weeklyOt=0（正しく週ごとに分けている）
negBreak THREW: 2026-06-01: 休憩 600 分が在社時間 180 分を超えています
badTime(25:00) THREW: 2026-06-01 の in "25:00" は 00:00–23:59 の範囲外です
======== OPUS ========
multiWeek week= {"weekStart":"2026-06-01","regularSumMin":2880,"weeklyOtMin":480,"totalOtMin":480}
multiWeek has weeks[]? false ← 1つの週にまとめて合算し weeklyOt=480 を誤集計
negBreak worked= -420 ← 休憩>在社を検知せず、実働が負のまま
badTime(25:00) THREW: 時刻の値が範囲外です: "25:00"見どころは2つ。1つ目は、複数週の扱いです。両方の aggregate() に複数週を直接渡すと、Opus はすべてを1つの週にまとめて合算し、週残業480分をでっち上げました。渡したサンプルは1週ぶんなので、その範囲では正しく動きます。Fable は週ごとの配列（weeks[]）を返し、各週を分けて残業を0にしていました。ちなみに Opus も index.html 側では週を分割して表示するので、画面としては破綻しません。計算部分が単独で堅いかどうか、という差です。
2つ目は、休憩600分・在社180分という「あり得ない打刻」。Opus は Number(r.break) || 0 で黙って受け取り、実働を -420 のまま返します。負の実働がそのまま集計に混ざるわけです。Fable は在社時間より休憩が長い時点で、日本語のメッセージを出してエラーで止めます。25:00 のような不正時刻は、どちらも弾きました。時刻の範囲チェックは Opus も入れています。
自己検証の作り込みも差がありました。Fable は16本のテストを自分で書きました。ISO週の境界、年をまたぐ週、不正な入力9種などです。さらに、実際のブラウザで index.html を描画してスクリーンショットまで取り、aggregate.mjs と HTML 内の計算ロジックが1文字も違わないことも機械で確認しています。Opus は node でサンプルと数件の境界を確認し、HTML と mjs のロジック一致はコードを読んで確認。ブラウザでの実描画は「やっていない」と正直に申告していました。頼まれてもいないのに実物を動かしにいくか。ここが Fable の色でした。
画面にも性格が出ます。Fable は集計表に加えて、勝手に「時間帯ストリップ」を足してきました。0時から翌6時までの時計の軸に、在社の帯と深夜の帯を重ねて描く小さな図です。木曜の 22:00→翌6:00、金曜の 01:00→09:00 の深夜が、総務担当の目で見て確認できます。
Opus 版はどうか。こちらは可視化こそ足していませんが、日別表に H:MM と生の分数を併記し、合計行とサマリーカードで数字をきれいに見せます。集計結果は正解とすべて一致。派手さはないぶん、読み違えようのない実直な作りです。
コードの手ざわりも、Fable は守りが堅い作りでした。中核の計算を __CORE_START__ / __CORE_END__ という印で囲って HTML と共有しています。JSDoc（コードに付ける説明）と名前付きの定数で、意図もコードに残していました。Opus はきれいで読みやすいものの、Number()||0 のような静かな型変換で、不正な値を吸収してしまう場面があります。動くコードとしてはどちらも合格。壊れにくさで一段、差がつきました。
結果③：コストと速度は Opus が明確に有利
深く検証するぶん、Fable は時間もトークンも使います。今回の1試行では、消費トークンが 84,860 対 58,255。Fable が約1.46倍です。所要時間は約10分対約5分で、こちらは約2倍。ツール実行回数は15対7でした。単価はもともと Fable が Opus のちょうど2倍です。
| 項目 | Claude Fable 5 | Claude Opus 4.8 |
|---|---|---|
| 入力単価（/100万トークン） | $10.00 | $5.00 |
| 出力単価（/100万トークン） | $50.00 | $25.00 |
| コンテキスト | 1M | 1M |
| 最大出力 | 128K | 128K |
| thinking | 常時ON（要約のみ返る） | adaptive（明示ONで作動） |
単価は Anthropic 公式の料金ページでも確認できます（platform.claude.com・本記事の値は claude-api の資料の 2026-06-24 時点）。この単価2倍に、トークン約1.46倍をかけ合わせて比較すると、同じタスクの実コストはおおよそ2〜3倍という概算になります。これは計測ツールが出した合算トークンを、代わりの目安にした推定です。入力と出力の単価差までは、厳密に分けていません。それでも方向ははっきりしています。Fable は高くて遅いぶん、自分で深く確かめます。Opus は安くて速く、想定どおりの入力なら精度も的確です。ただ、堅牢化や実物の確認は、はっきり頼まないと薄くなりがち——この1回の実測は、そう読めました。
Fable の「深さ」はどこで効くのか
正確性が同点なら、わざわざ2倍払う意味はどこにあるのか。今回の結果を並べると、効きどころは絞れます。仕様が曖昧で、渡したサンプルの外まで自分で想定してほしいとき。一発勝負で、あとから手直しする余裕がないとき。数分から数十分をひとりで走り続ける、長時間の自律作業。こういう場面では、Fable の働き方がそのまま効きます。頼まなくても実物を動かし、不正なデータを想定し、サンプルの外まで確かめにいく姿勢。これが後工程の手戻りを、まるごと消してくれます。
逆に、この深さが向かない場面もあります。仕様がかっちり決まっていて、レビュー工程が別にあるなら、毎回2倍払う効果は薄くなります。ここは次回、もっと大きなお題で確かめます。Fable に会計 freee 相当のアプリを1セッションで自律完成させたとき、この検証の規律が最後まで持つのか。それが連載②のテーマです。
どっちを選ぶ：用途で割り切る
1回の実測から言える範囲で、選び方をまとめます。断言しすぎない程度に。
- 難関を一発で・長時間の自律作業なら Fable 5：仕様が曖昧、堅牢化まで任せたい、途中で人が見られない——そんな条件のとき。自発的に実物確認まで走る性格が、そのまま品質になります。
- 量産・コスト重視なら Opus 4.8：仕様が明確、レビュー工程が別にある、同じ処理を数多く回す用途。半分の時間と約7割のトークンで、同等に正しい計算が返ってきます。
- 迷ったら：まず Opus で作り、堅牢化・実物の確認・サンプル外の検証を、はっきり指示するのがおすすめです。それで足りない難所だけ Fable に回すと、コストと品質のバランスを取りやすくなります。
大事なのは、Opus が「弱い」のではないこと。はっきり頼めば、範囲チェックも週分割もちゃんと入れてきます。今回は「頼まなかったときに何が残るか」を測ったので、自発性の差が前に出ただけです。こういうモデル選定やベンチ設計を自社の開発で詰めたい場合は、導入支援・技術相談も受けています。今回の勤怠集計ツールは、仕上げて 無料ツール置き場 に並べる候補にしています。
次回予告
この①は素の状態・同条件での比較でした。ここから2本つなげます。
- ②：Fable に会計 freee 相当のアプリを1セッションで自律完成させる記録。今回見えた「頼まなくても検証する」規律が、大きなお題でも最後まで持つのかを見ます。
- ③：Fable の仕事の進め方（段階を踏んで計画し、実物で確かめ、詰まったら仮説を立てて直す）を、手順と確認項目にまとめて Opus に持たせ、マーケ用のショート動画を作るツールという新しいお題で再戦。プロンプトで細かく指示するのではなく、工程ごとの合格条件で検証を踏ませたとき、Opus が Fable の深さに届くかを比較します。
ほかの実装・精度検証の記事は AI・LLM開発 のカテゴリにまとめています。②③は公開後に、ここへ相互リンクを張ります。
