MAKEAI JOURNAL / AIの使い方
Claude Fable 5.1とOpus 5の違い|仕様・費用・業務での比較方法【2026年10月更新】

更新(2026年10月20日):この記事は、すでにOpus 5を使用している方の移行判断に向けて、Fable 5.1との仕様差と比較方法を説明します。Opus 5は現在レガシーモデルです。9月22日に発表されたOpus 5.5の変更点と料金はClaude Opus 5.5の記事で確認できます。
すでにOpus 5を使用している場合は、現在の処理を基準に、足りない部分を確認してからFable 5.1と比べる方法があります。現在のAnthropicのモデル選択ガイドは、機能を重視する場合の出発点としてOpus 5.5を案内しています。本記事は、既存のOpus 5からの変更を検討するために、Opus 5との仕様差と比較方法を扱います。公式のモデル選択ガイド
この記事は2026年9月14日に作成した仕様比較をもとに、10月20日に料金・上限と現行のモデル選択案内を再確認して更新しました。MakeAIが両モデルの性能を実測した記事ではありません。
公式仕様では何が違う?
次の表はClaude APIの仕様比較です。料金とトークン上限は2026年10月20日に再確認しています。相対的な待ち時間は9月14日時点の掲載値で、現在の速度を測定した結果ではありません。Claudeの画面から使う場合の月額や利用上限とも異なります。
| 項目 | Fable 5.1 | Opus 5 |
|---|---|---|
| 入力単価 | 10ドル | 5ドル |
| 出力単価 | 50ドル | 25ドル |
| キャッシュ読み取り | 0.25ドル | 0.50ドル |
| コンテキスト | 100万トークン | 100万トークン |
| 最大出力 | 128,000トークン | 128,000トークン |
| 公式表の相対的な待ち時間 | Slower | Moderate |
単価は100万トークンあたりの通常料金です。根拠はFable 5.1の仕様とOpus 5の仕様です。
入力・出力の単価はFable 5.1が2倍ですが、キャッシュ読み取りはFable 5.1のほうが安く設定されています。実際の費用は、トークン数、キャッシュの割合、再実行などによって変わります。
また、Fable 5.1を選んでも、APIのコンテキスト上限がOpus 5より大きくなるわけではありません。「長い資料を渡したい」という理由なら、まず量だけが問題なのか、内容の読み取りや複数工程の判断が問題なのかを分けます。
性能の比較表だけで決めにくい理由
公式の評価は、決められた問題、使えるツール、推論の設定などに基づいています。別の会社が報告した「速かった」という結果と、仕様表の相対的な待ち時間が、そのまま同じ条件を表すとは限りません。
社内で必要なのは、たとえば「長い説明を書けること」ではなく、「元資料の数字を間違えず、指定した3項目に答えること」です。自分の仕事の合格条件を先に決めると、モデルの名前や評判だけで選ばずに済みます。
仕事別に、何を比べる?
次の表に、仕事ごとに確認する項目をまとめました。
| 仕事 | 比べる内容 |
|---|---|
| 社内文書の下書き | 指定した項目、数字、文体を守り、直す量が少ないか |
| 複数資料の比較 | 各資料の根拠が分かり、条件の違いを見落とさないか |
| コードの修正 | 問題を直し、関係のない箇所を壊さず、確認まで行えるか |
| 長い調査 | 出典を確認でき、途中の条件や対象範囲を守れるか |
すでにOpus 5で短い文面の下書きを作っている場合は、現在の処理で必要な結果が得られているかを基準にします。何度直しても資料の条件を取りこぼす、複数の工程を最後まで完了できない、といった課題があれば、同じ材料をFable 5.1へ渡して違いを確かめます。
同じ仕事で比較する手順
1.材料と完成条件をそろえる
片方だけに詳しい背景を渡すと、モデルの違いなのか、依頼の違いなのか分からなくなります。同じファイル、同じ依頼文、同じ利用ツールを使い、モデル名と設定を記録します。
2.最初の結果を残してから直す
初回出力を保存し、何が足りなかったかを書きます。修正後だけを比べると、途中で人がどの程度手伝ったかが見えません。
3.作成と確認の時間を両方記録する
回答が速くても、数字を調べ直したり、文章を大きく直したりするなら、その時間も必要です。完成までの時間を「生成を待った時間」と「人が確認・修正した時間」に分けます。
4.別の材料でも確認する
1件でよい結果が出ても、その仕事を安定して任せられるとは限りません。資料が短い場合、長い場合、一部が欠けている場合など、条件を変えて確認します。
そのまま使える比較メモ
対象の仕事:
入力ファイルと版:
共通の依頼文:
使ったモデル名と設定:
使えるツール:
合格条件:
・資料の数字と日付が一致している
・指定した項目にすべて答えている
・出典を開いて根拠を確認できる
・資料にないことは確認事項になっている
記録:
初回で満たせなかった条件:
追加で出した指示:
生成を待った時間:
確認・修正にかかった時間:
使用量または費用:
合格条件は仕事に合わせて変えます。コード修正なら、出典の代わりに、通るべきテストや実際の操作を指定します。資料作成なら、ファイルを開けるか、必要な部分を編集できるかも加えます。
モデルを替える前に、依頼も見直す
結果が悪い原因が、モデルだけにあるとは限りません。資料に答えがない、完成条件が曖昧、必要なツールを使えない、といった場合は、その条件を直してから比べます。
Anthropicは、モデルを替えるほかに、考える量を調整するeffort設定も比較の対象にしています。設定を変えた場合は、どの条件で試した結果かを記録してください。公式の選択ガイド
どちらを採用するか
必要な結果が得られ、確認の手間や費用が許容範囲なら、その仕事には現在のモデルを使う判断ができます。Fable 5.1でしか満たせない条件があるなら、その工程に絞って使う方法もあります。
全業務を1つのモデルへ切り替える前に、仕事ごとの記録を比べて決めます。MakeAIでは、比較に使う材料や合格条件を用意する段階からご相談いただけます。
比較の前に、いま使っているOpusの版を確認する
2026年10月20日確認の公式モデル一覧では、Opus 5は提供が続くレガシーモデルとして扱われています。本記事の比較対象は、モデルIDがclaude-opus-5のOpus 5です。Opus 5.5の結果や料金を、Opus 5の欄へ混ぜないでください。既存システムでOpus 5を使っている人の移行判断と、新しく使い始める人の選択は分けて考えます。
画面に表示される名前、APIで指定するID、過去の試験記録に書かれた名前を揃えます。「Opusで試した」とだけ残すと、後から再比較できません。設定や使えるツールが変わった場合も記録します。モデルが同じでも、入力資料や実行環境が違えば結果の差をモデルだけの差とは言えません。
比較用の課題を、仕事の難しさ別に用意する
一つの得意な課題だけで比較すると、実際の業務で困る箇所を見逃します。MakeAIでは、通常の仕事、条件の多い仕事、情報が不足した仕事の三種類を用意する方法を提案します。資料作成なら、正しい数字がそろった入力、複数部署で集計条件が違う入力、原因の説明がない入力を使います。難しさを少しずつ変えると、どの条件から修正が増えるかが分かります。
仮の例として、二つのモデルへ同じ売上表を渡すなら、合計値、増減率、対象期間、原因の扱いを合格条件にします。文章が好みかどうかは別の評価欄に置きます。好みの表現でも数字が違えば採用できませんし、表現を少し直すだけなら、事実が正しい出力のほうが実務に合う場合があります。
| 比較用の入力 | 期待する動作 | 重大な失敗の例 |
|---|---|---|
| 数字と条件がそろった表 | 合計と増減を正しく説明する | 単位や符号を取り違える |
| 期間が異なる二資料 | 比較条件の違いを指摘する | 同条件として増減率を出す |
| 原因が書かれていない表 | 原因を確認事項にする | 広告効果などを確定原因として作る |
| 例外が付録にある手順書 | 原則と例外を一緒に残す | 本文だけで断定する |
採点の基準は、出力を見る前に決める
出力を読んでから基準を作ると、気に入った文章へ有利な採点になりがちです。先に、必ず満たす条件と、あれば助かる条件を分けます。数値の正確さは必須、文章の長さは調整可能、といった区別です。必須条件を落とした出力を、読みやすさの点数で相殺しないようにします。
一人で評価する場合も、最初の出力を保存してから修正します。最終版だけ残すと、追加の指示や人の書き直しが見えません。どの指示で何が直ったかを記録し、最初からその条件を入れれば改善するのか、モデルを替える必要があるのかを見ます。
同じ単価の倍率でも、仕事の費用は変わる
Fable 5.1の通常の入力・出力単価は、本文の表ではOpus 5の二倍です。ただし、仕事一件の費用を二倍と決めるには、両モデルの処理量と実行回数が同じである必要があります。片方が長い回答を生成したり、何度も修正が必要になったりすれば、一件の費用は違います。比較には使用量の実績を使います。
仮の計算として、通常入力一万トークン、課金対象出力二千トークンを一回使うなら、Fable 5.1は〇・二ドル、Opus 5は〇・一ドルです。これは両者で同じ処理量、キャッシュなしという条件の試算です。実際にAPIを呼び出して得た結果ではありません。Fableが必ず短い出力で済むとも、Opusが必ずやり直しを要するとも仮定しません。
人が確認する時間は別欄に残します。AIの支払いが少なくても、根拠の調べ直しや表の修正に時間がかかれば、仕事全体の費用は下がらない場合があります。逆に、確認時間がほぼ同じで出力も必要な水準なら、低い費用の選択肢を使う判断ができます。どちらが有利かを先に決めず、同じ完成条件で比べてください。
キャッシュを使う比較は条件をそろえる
通常の入力・出力と、キャッシュの読み取りは単価の関係が違います。共通資料を何度も読む処理では、本文の比較表だけを見て総額を決めないでください。初回書き込み、読み取り、毎回変わる入力、出力を分け、それぞれの実際の量から計算します。片方だけキャッシュを有効にした比較なら、その条件差を明記します。
速度は、最初の返答と完成までを分けて測る
画面に最初の文章が出るまでの時間と、成果物が完成するまでの時間は別です。調査やファイル作成では、途中のツールの処理、確認、再実行も含まれます。短いチャットの応答時間だけで、資料作成の速さを判断しないようにします。
測定するなら、開始時刻、初回出力の完了、追加指示の回数、最終確認の完了を記録します。通信の遅延や外部サービスの応答待ちがあった場合は、そのことも残します。一回だけの遅延をモデルの恒常的な弱点と決めず、複数の代表的な材料で確認してください。本記事では、その速度測定は実施していません。
比較結果の記録 課題名と入力資料の版: モデルIDと利用環境: 推論・effortなどの設定: 初回出力で満たした必須条件: 初回出力で落とした必須条件: 追加指示と修正回数: 最終的に採用できたか: 生成とツール処理の待ち時間: 人の確認・修正時間: 使用量と費用: 環境の制約や未実行の確認:
用途ごとに採用を分けるときの注意点
複雑な条件の照合だけFableを使い、定型的な文章整形は別モデルへ任せる方法も考えられます。その場合は、前の工程で確定した内容が、次の工程で変わっていないかを確認します。数字、固有名詞、未確定事項を引き継ぎ情報に含め、整形担当が根拠のない条件を追加しないようにします。
APIで工程を分けるなら、受け渡す項目の形式とエラー時の扱いも必要です。回答が空だった、必要な根拠がなかった、出力形式が違ったときに、そのまま後工程へ流さないようにします。モデルの使い分けで処理が複雑になりすぎるなら、一つのモデルで必要な品質に達する構成のほうが管理しやすい場合もあります。
採用後も、入力資料の種類や量が変わったら、同じ比較課題を再確認します。導入時の結果だけで、今後のすべての業務を保証しません。今回の比較表はOpus 5との関係を読むために残し、新規導入では現行モデルの候補も確認したうえで、自社の完成条件に合う選択をしてください。
採用結果が割れた場合は、一つの順位へ押し込めない
文書の下書きでは差が小さく、複雑な資料比較では差が出ることも考えられます。その場合は、総合点だけで一つの勝者を決めず、用途ごとの結果を残します。比較した材料の数が少ないなら、差が安定して出るかを追加で確認します。見つかった一例を、全用途の優劣へ広げないことが大切です。
一方のモデルだけが合格した場合も、失敗した理由を読んでください。入力の取り違えやツールの不調なら、条件を直して再確認する必要があります。仕様上利用できない機能が原因なら、その事実を採用条件へ残します。モデルの判断力と、周辺環境の違いを区別して結論を書きます。
最終的な比較メモには、採用したモデル名だけでなく、採用の対象となる仕事と再評価する条件を添えます。資料の種類、処理量、出力形式が変わったら、以前の結論がそのまま当てはまるかを見直せます。
現在の業務や困っていることをお聞かせください。