Claude Haiku 5.5の料金と使い分け|100Kの壁
「AIにもっと任せたいけれど、料金が怖くて量を増やせない」——定期的に回す仕事をAIに預けはじめた人が、必ず一度は止まる場所です。
結論から言うと、2026年10月7日に出たClaude Haiku 5.5で変わったのは「安くなったかどうか」ではなく、どの仕事なら安い段に落としても大丈夫か、という線の引き方です。しかも料金には、1リクエストが10万トークンを超えると単価が5倍になる段差があります。
株式会社Fyveは、手元のMac miniで毎日いくつもの仕事をAIに無人で回しています。この記事では、公式の発表内容と、自分の環境を実際に数え直した結果の両方から、落とす先の決め方を整理します。
結論|Haiku 5.5で効くのは「落とす先の基準」を先に決めること
先に答えを3つにまとめます。
- 料金は10万トークンを境に2段階。10万トークンまでのリクエストは百万トークンあたり入力$0.10/出力$0.50、超えると$0.50/$2.50になります。同じモデルでも長い入力を渡した瞬間に単価が5倍です。
- 「約90%安」と「約75%安」は条件の違う別の数字。90%は10万トークン未満のリクエストの単価、75%は平均してかかる額の話です。混ぜて読むと社内の試算がずれます。
- 落とす基準は「人の名前が出るか」。成果物に自分の名前が付いて外に出る仕事は安い段に落とさない。名前が出ない仕事(原文の移し替え・分類・見張り)だけを落とす。これが一番事故が少ない分け方でした。
そして落とす前に決めることが2つあります。モデル名を世代まで含めた固定の名前で書くことと、入れ替える日を人が決めることです。理由は後半で、実際に起きた食い違いとあわせて書きます。
2026年10月7日に発表された内容を、数字で確認する
まず事実の確認です。Anthropicは2026年10月7日に小型モデルの新版「Claude Haiku 5.5」を公開しました(公式製品ページ)。同じ日に公開されたClaude Codeの更新履歴(v2.1.293)にも、モデルIDと料金が独立して記載されています。
料金は10万トークンを境に2段階に割れる
公式の表記はこうです。百万トークンあたりの単価で、10万トークンまでのプロンプトは入力$0.10/出力$0.50、10万トークンを超えるプロンプトは入力$0.50/出力$2.50。前の版であるHaiku 4.5は入力$1.00/出力$5.00でした(VentureBeat・the-decoderほか複数の独立報道が一致)。

この段差は、実務ではかなり効きます。短い指示を大量に投げる使い方なら一番下の単価がそのまま効きますが、長い資料をまるごと読ませる使い方だと、1回のリクエストが簡単に10万トークンを超えます。同じ「安いモデルを使っている」つもりでも、請求の桁が変わる分かれ目がここにあります。
「約90%安」と「約75%安」を混ぜない
公式には2つの割引率が書かれています。
- 約90%安:10万トークンまでのリクエストの単価で比べた場合(10万トークン超は約50%安)
- 約75%安:平均して実際にかかる額で比べた場合
この2つは比べているものが違います。社内で「9割安くなるらしい」と伝えると、長い入力を扱う部署の試算が合わなくなります。見積もりを作るときは、自分たちのリクエストが10万トークンに収まるかどうかを先に調べてからどちらの数字を使うか決めてください。
なお、同じ資料を何度も読ませる使い方をするなら、キャッシュの単価も確認する価値があります。公式ページにはキャッシュ読み出し$0.01/$0.05、キャッシュ書き込み$0.125/$0.625と記載があります(いずれも10万トークンまで/超の2段階)。
画面操作の点数は大きく上がったが、現場の保証ではない
性能面でよく取り上げられているのが、パソコン画面の操作を測るベンチマークOSWorldの点数です。公式が出した数字は72.4%で、前の版のHaiku 4.5は15.7%でした(VentureBeat・the-decoderが同じ数字を報じています)。
ただし、ここは読み替えに注意してください。これは試験の点数であって、自分の業務ソフトを操作できる保証ではありません。実際に画面操作を任せるかどうかは、対象のアプリで小さく試してから判断するべき領域です。記事や社内資料に引くときは「公式の試験で」と条件を付けて書くのが安全です。
作った側の位置づけは「大きいモデルの下で働く係」
見落とされがちですが、公式ページでの位置づけがはっきりしています。コーディング作業におけるサブエージェント、そして速さが要る仕事(ライブの顧客対応、ブラウザ操作など)に向く、という書き方です。
つまり作った側も「これ1本で全部やる段」とは言っていません。上の段が司令塔で、下の段が手数を担当するという構成を前提にしています。ここを読み飛ばして全部を下の段に替えると、期待していた品質が出ません。
提供基盤についても、公式ページにAmazon Web Services・Google Cloud・Microsoft Azureを含む各プラットフォームで利用可能と記載があります。すでにいずれかの基盤で動かしている組織なら、乗り換えの障壁は小さいはずです。
他社の一番安い段と同じ水準に並んだ、という見方
価格の文脈も押さえておくと判断しやすくなります。VentureBeatは今回の改定を、他社の最小モデル(GPT-6 Luna)と同水準の価格帯に並んだものとして報じています。the-decoderも、小型モデルの価格競争が続いている流れの中に位置づけています(いずれも2026年10月7日)。
ここから読めるのは、「どの会社の一番安い段を選ぶか」で差がつく時期は、少なくとも価格の面では終わりつつあるということです。単価がほぼ横並びになるなら、選ぶ基準は価格そのものではなく、すでに使っている道具とつながるか、そして落とす仕事を自分が選べているかに移ります。
言い換えると、値下げ競争のニュースを追いかけても差はつきません。差がつくのは、この記事の後半で扱う「どの仕事を落とすか」の設計のほうです。
開発ツール側の対応も同じ日付で入っています。Claude Codeの更新履歴(v2.1.293)には、claude-haiku-5-5の追加、Anthropic APIにおける既定のHaikuになったこと、100万トークンの文脈窓が記載されています。同じ版で、サブエージェントの状態表示にagentTypeが追加され、どの種類のエージェントが動いているかをスクリプト側から見分けられるようになりました。振り分け表を運用している側には、こちらも地味に効く変更です。

値下げのニュースを見て、まず自分の環境を数え直した
ここからは私の実運用の話です。値下げに反応して設定を書き換える前に、そもそも自分が何をAIに預けているのかを数えました。手を動かす前に現状を数えるのは、どの導入支援でも最初にやることです。
登録されているのは13本、いま動いているのは9本だった
手元のMac miniには、毎日決まった時間に勝手に動く仕事が13本登録されていて、そのうち実際に動いているのは9本でした(残り4本は止めてあります)。中身は、朝の情報集め、ニュース便、引用の投稿、記事の下書き、急上昇の見張り、原文の移し替え、死活の監視などです。
正直に書くと、この数字は自分でも把握しきれていませんでした。「だいたい10本くらい」と思っていたものを数えたら13本あり、4本は止まったまま残っていた。値下げの話をする以前に、棚卸しの時点で発見があります。
モデルの指定は2種類しかなかった
次に、その仕事たちがどのモデルを使っているかを見ました。結果は拍子抜けするほど単純で、指定は2種類だけでした。
- 実名で公開される文章を書く仕事 → 上の段
- 原文の移し替えや定型処理だけの仕事 → 中の段
しかも振り分けは、仕事の名前で分けるたった1行の条件分岐です。中の段に振っているのは9本のうち2本だけで、残りは全部上の段でした。
無人で回すときのモデル指定そのものの作法は、以前に別の記事でまとめています。この記事はその続きにあたります。
一番下の段は、1本も使っていなかった
そして肝心の確認です。設定ファイル全体をHaikuで検索したところ、該当は0件でした。つまり一番下の段を1本も使っていないところへ、その段が1/10の値段になったというのが、私の置かれた状況です。
この「使っていなかった」という事実のほうが、値下げのニュースより重要でした。使っていない段が安くなっても、何も起きません。安くなった日にやるべきは、設定を書き換えることではなく、どの仕事を落とせるかを選び直すことです。
落とす先を決める基準は「人の名前が出るか」
では、何を下の段に落とすのか。コストの大きさ順でも、処理の重さ順でもなく、成果物に人の名前が付いて外に出るかどうかで分けるのが、いちばん事故が少ない基準でした。

名前が出る仕事は落とさない
記事や投稿の本文、顧客に出す文書の下書き、公開前の最終チェック。これらは品質の下限が「読まれても恥ずかしくないか」で決まる仕事です。平均が良くても、たまに出る低い出力が全体の信用を削ります。
ここを安くしたときに失うものは、金額では戻りません。私の環境で言えば、記事を書いて自動で公開する経路がこれにあたります。この経路は値下げがあっても動かしませんでした。
名前が出ない仕事だけを落とす
一方、下の段の候補になるのはこちらです。
- 原文の移し替え・形式変換(別の場所に同じ内容を移すだけの作業)
- 分類・要約・ふるい分け(大量に来るものを仕分ける作業)
- 見張り(動いているか、止まっていないかの確認)
これらは結果が正しいかどうかを機械的に確かめられるのが共通点です。移し替えなら元と突き合わせればよく、見張りなら異常時に鳴るかどうかで判定できます。確かめ方がある仕事は、安い段に落としても怖くありません。
判断が混ざっている仕事は、分けてから落とす
迷うのは「集めて、選んで、書く」のように工程が混ざっている仕事です。この場合は、仕事ごと落とすのではなく、工程を分けて落とすのが正解でした。集める部分と仕分ける部分は下の段、選んで書く部分は上の段。公式が「サブエージェント」という言い方をしているのも、まさにこの形です。
上の段どうしの使い分け、つまり「どこまでを中の段で足りるか」については別記事で実測を交えて整理しています。
落とす前に決める2つ|名前の書き方と、入れ替える日
ここが、この記事で一番伝えたい部分です。どれを落とすかより手前に、決めておくべきことが2つあります。どちらも理屈ではなく、実際に起きた食い違いから決めたものです。
① モデル名は世代まで含めた固定の名前で書く
AIの道具には、opusやsonnetのような短い呼び名(エイリアス)が用意されていることがあります。便利ですが、この短い呼び名が何に解決されるかは、道具の版によって変わります。
私の環境では、2台の機械で同じ短い呼び名を使っていたところ、一方ではOpus 4.8、もう一方ではOpus 5に解決されていました(Claude Codeの版がそれぞれ2.1.209と2.1.227)。同じ設定を書いているつもりで、実際には別の書き手が動いていたわけです。
ここから起きる事故は2方向あります。
- 上げたつもりで上がっていない:新しい世代を指定したつもりが、その機械では古い世代に解決されている
- 更新で黙って変わる:道具を更新しただけで、書き手が予告なく入れ替わる
後者がとくに厄介です。実名で自動公開する経路で書き手が黙って変わるのは、受け入れられません。だから設定には世代まで含んだ固定の名前を書くと決めました(2026年8月12日)。短い呼び名は手元で試すときだけにしています。
安い段に落とすときも同じです。「一番安いやつ」のような指定にすると、次に新しい小型モデルが出た日に、確かめないまま入れ替わります。落とす先こそ、名前を固定で書くべき場所です。
② 入れ替える日は人が決める
もう1つは運用の話です。モデルの世代交代は、道具の更新に合わせて自動で起きるのではなく、人が日を決めて行う。これだけです。
実務では、設定の2行を書き換えるだけで切り替わるようにしておき、その2行を書き換える判断は人がするという形にしています。切り替えたあと数日は出力を見て、おかしければ戻す。この「戻せる状態を保つ」ところまでが入れ替えの手順です。
モデルの階層そのものを俯瞰したいときは、こちらも参考になります。
10万トークンの壁を、実務でどう扱うか
料金の段差について、もう少し実務寄りに補足します。
長い入力を渡す仕事は、思ったほど安くならない
「分類・要約なら安い段でいい」と書きましたが、要約は入力が長くなりがちな仕事です。長い議事録や資料をまるごと渡す使い方だと、1回のリクエストが10万トークンを超えて、上の段の単価が適用されます。
対処は単純で、渡す前に分けることです。長い資料は章ごとに分けて渡し、最後にまとめる部分だけ別に処理する。手間は増えますが、料金の段と処理の正確さの両方で有利になります。
同じ資料を繰り返し読ませるならキャッシュを見る
毎回同じ前提資料を読ませる仕事なら、キャッシュの単価が効いてきます。公式ページに記載のあるキャッシュ読み出しの単価は、通常の入力単価よりさらに1桁低い水準です。固定の前提資料がある仕事ほど、キャッシュを使う設計にする価値があります。
画面操作を任せるかは、別の判断にする
ベンチマークの点数が上がったことで「画面操作も安い段でいける」と考えたくなりますが、ここは分けて判断してください。画面操作は失敗したときの影響が、文章の品質とは比べものになりません(誤って送信する、誤って消す)。安さを理由に権限を広げるのは、順番が逆です。
落としたあと、本当に効いているかを確かめる
振り分けを変えたら、変えたとおりに動いているかを確かめるところまでが一仕事です。ここを飛ばすと、設定を書き換えただけで満足して、実際には何も変わっていなかった、ということが起こります。確認は3つで足ります。
確認1|どのモデルで動いたかを記録に残す
仕事が始まった時点で、使ったモデル名を実行の記録に書き出しておきます。これがないと、後から「あの日の出力はどの段だったのか」が追えません。名前を固定で書いているなら、記録に残る名前も固定になります。短い呼び名のままだと、記録を見ても結局どの世代だったか分からないままです。
Claude Codeの2026年10月7日の更新(v2.1.293)で、サブエージェントの状態表示にagentTypeが入りました。どの種類のエージェントが動いているかをスクリプト側から見分けられるので、複数の段を並行して使う構成では、記録の精度が上げやすくなっています。
確認2|落とした仕事の出力を、落とす前と突き合わせる
名前が出ない仕事を選んだ理由は「確かめ方がある」からでした。なので実際に確かめます。
- 移し替え:元の文章と移した後を突き合わせて、欠落や勝手な書き換えがないかを見る
- 分類・ふるい分け:同じ入力を上の段にも通して、判定が分かれた件数を数える
- 見張り:わざと異常な状態を作って、ちゃんと鳴るかを試す
この突き合わせは、落とした直後に数日ぶんだけやれば十分です。毎回続ける必要はありません。落とした最初の数日に差が出なければ、その仕事はその段で足りていると判断できます。
確認3|測るのは「時間」と「料金」の2つだけ
効果の測定は、増やすほど続かなくなります。見るのは、仕事が終わるまでの時間と、かかった額の2つだけで十分です。
品質は数字で測ろうとせず、確認2の突き合わせで「差が出たか/出なかったか」の二択にします。指標を増やすより、落とす仕事を1つずつ増やすほうが、結果として早く進みます。
よくある失敗3つ
値下げのあとに起きやすい失敗を、先に挙げておきます。どれも「順番を間違える」ことで起きます。
失敗1|一覧を作らずに、思いついた仕事から落とす
一番多い形です。数えずに始めると、止まったまま残っている仕事や、二重に動いている仕事に気づけません。私の場合、13本のうち4本が止まったままでした。落とす前に、まず数えてください。
失敗2|長い入力を渡す仕事を、そのまま落とす
料金の段差を踏む形です。10万トークンを超えれば単価は5倍なので、「安い段に落としたのに思ったより下がらない」という結果になります。長い入力を渡す仕事は、落とす前に渡し方を分けるのが先です。
失敗3|落とす先を「一番安いやつ」という指定で書く
これが一番あとで効いてきます。短い呼び名で書くと、次に新しい小型モデルが出た日に、確かめないまま入れ替わります。しかも落とした先は普段あまり目を向けない場所なので、変わったことに気づくのが遅れます。固定の名前で書いてください。
今日できる5つの手順
ここまでを、そのまま実行できる形にまとめます。15分あれば一周できます。
- AIに任せている仕事を一覧にする。数えると、思っていた数と違うはずです(私は13本あり、うち4本は止まっていました)
- 「人の名前が出る/出ない」で2つに分ける。コストの大きさではなく、品質の下限で分けます
- 名前が出ない仕事だけを安い段の候補にする。工程が混ざっているものは、工程を分けてから落とします
- モデルは世代まで含んだ固定の名前で指定する。短い呼び名は、機械によって別物に解決されます
- 入れ替える日を自分で決める。切り替えたあと数日は出力を見て、戻せる状態を保ちます
5の「戻せる状態」が抜けると、入れ替えが怖くなって結局やらなくなります。戻せるから試せる、という順番です。
よくある質問
全部をHaiku 5.5に替えてしまってよいですか?
おすすめしません。公式自身が「大きいモデルの下で働くサブエージェント」「速さが要る仕事」という位置づけで出しています。全部を替えると、判断が要る仕事の品質が落ちます。名前が出ない仕事から順に、確かめながら落としてください。
「90%安」と聞きましたが、請求も90%下がりますか?
下がるとは限りません。90%は10万トークンまでのリクエストの単価の話です。公式は平均では約75%安と書いています。長い入力を多く投げる使い方なら、下がり幅はさらに小さくなります。
どのくらいの入力で10万トークンを超えますか?
日本語の分量感はモデルや内容で変わるため、断定はできません。確実なのは、長い資料をまるごと渡す使い方では超えうるということです。心配なら、渡す前に分ける設計にしておけば段差を気にせずに済みます。
小規模な会社でも関係ありますか?
関係します。むしろ小規模なほど、AIに任せている仕事の一覧が誰の頭にも無い状態になりがちです。値下げを機に棚卸しをするだけでも、止まったまま残っている仕事が見つかります。
まとめ|安くなった日にやるのは「どれを安くしないか」を決めること
2026年10月7日のClaude Haiku 5.5は、一番下の段の単価を大きく下げました。ただし10万トークンを境に単価が5倍になる段差があり、約90%安と約75%安は条件の違う別の数字です。この2点を押さえずに試算すると、あとで合わなくなります。
そして自分の環境を数え直した結果は、13本のうち稼働は9本、モデル指定は2種類だけ、一番下の段は0本でした。値下げは、使っていない段には効きません。だから最初の一手は設定の書き換えではなく、仕事を「人の名前が出るか」で分け直すことになります。
落とす前に決めることは2つ。モデル名は世代まで含めて固定で書く、入れ替える日は人が決める。どちらも、同じ短い呼び名が機械によって別世代に解決された、という実際の食い違いから決めたものです。
安くなった日にやることは「全部を安くする」ではありません。どれを安くしないかを決めることです。
自社の仕事をどこまでAIに預けられるか、どの工程をどの段に振るかの設計からご相談いただけます。
Claude Codeを「素のまま」使うな

設定で差がつく——CLAUDE.md・権限・スキルの実物を公開(全24ページ)
素のClaude Codeは"優秀な新入社員"。仕事を教えるほど、自分専用になります。覚えさせる4点セット——会社の説明書(CLAUDE.md)・権限の柵・手順書(スキル)・フォルダの地図——を、1人会社の実運用からコピペで使える型つきで公開します。
- そのまま書き換えて使えるCLAUDE.mdの型
- お金と送信をAIに触らせない「3段階の柵」
- 1回教えたら何度でも動く、手順書のコピペ雛形
- AIが迷子にならないフォルダ構造の3原則
メールアドレス登録で他にも様々な資料を閲覧できます








+8PDF 17点・合計440ページ + すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。