AIを、仕事の難しさで使い分ける

定型はHaiku 5.5。
難しい案件だけ、
上位モデル・人へ。

同じ種類の問い合わせを大量に扱う現場へ。分類・要約・項目抽出を一次処理に切り出し、難しい判断に予算と確認時間を使う。Haiku 5.5の公式仕様を起点に、品質・総費用・待ち時間を測る分業案を考える。

対象号：2026-10-09 JST公式発表：2026-10-07一次情報確認・制作：2026-10-09 JST

本号の業務フローと評価計画は編集部提案。自社データでの精度・時間短縮・費用削減は未検証です。

ONE-PAGE BRIEF

仕事を分ける。出口は人が確認する。

編集部提案

まず定型処理をそろえ、根拠と業務ルールで振り分ける。AIの自己申告した「自信」だけで通過させない。

クリック／Enterで拡大。説明用の生成図で、製品画面・導入実績ではありません。契約条件などの重要案件は、この図の一次処理に入れる前から担当者へ回します。
図の内容をテキストで読む

問い合わせ → Haiku 5.5で分類・要約・項目抽出 → 形式・根拠・業務ルールを検証。定型で根拠がある案件は下書きへ。複雑な案件は上位モデルへ。情報不足や矛盾は保留して追加確認へ。どの経路でも人が回答内容と宛先を確認し、必要に応じて送信します。効果は、品質・総費用・待ち時間を自社データで測って判断します。

公式仕様開発元評価編集部提案試算・未検証

WHO / PROBLEM / OUTCOME

定型と例外が混ざり、確認が集中する現場に

編集部提案 対象は、日本語の一般業務の問い合わせ。役割ごとに成果物と評価指標を決めると、モデルの変更を業務改善につなげやすい。

CUSTOMER SUPPORT

FAQ対応のサポート担当

困りごと
同じ質問の分類と、例外対応の確認が同じ担当者に集まる。
組み込み方
問い合わせと承認済みFAQ → 分類・根拠照合 → 回答案を人が確認。
残る成果物
分類、短い要約、根拠位置、回答案、未解決事項。
測るもの
分類正解率、誤案内、確認・修正時間、保留の妥当性。
限界と責任
権限付き検索は別実装。例外判断と外部送信は担当者が担う。

SALES OPERATIONS

受付を整える営業事務

困りごと
必要項目の抜けを探し直し、専門担当へ何度も聞き返す。
組み込み方
受付文面 → 項目抽出・不足確認 → 担当者向けの引き継ぎ票。
残る成果物
受付分類、必要項目、抜け、確認すべき質問。
測るもの
抽出一致率、差戻し、受付から引き継ぎまでの時間。
限界と責任
値引き・契約変更・約束は人へ。AIが条件を決定しない。

AI / OPERATIONS ENGINEER

業務AIの運用担当

困りごと
全件同じ構成で処理し、例外の費用や失敗が見えにくい。
組み込み方
受付ルール → モデル分業 → 検査・監査ログ → 人の承認。
残る成果物
ルーティング理由、使用量、失敗記録、比較結果。
測るもの
再処理率、p95待ち時間、完了1件の総費用。
限界と責任
日本語品質、権限、保存先を確認。復旧・予算上限を実装する。

A BOUNDED WORKFLOW

分類から始め、根拠が弱い案件を止める

編集部提案 想定する現状は「全件を上位モデルで処理 → 人が確認」。変更後は、重要案件を先に除外し、残りの定型候補をHaiku 5.5で一次処理する。

問い合わせ重要案件のルール判定Haikuで分類・要約・抽出形式・根拠・業務ルールの検証

ROUTE A / ROUTINE

定型・根拠あり → 下書き

必須項目がそろい、承認済み資料に答えがある。根拠位置を添えて回答案を作る。

ROUTE B / COMPLEX

複雑な案件 → 上位モデル

複数資料の比較などが必要。元の根拠・未解決点を添えて渡し、再び検証する。

ROUTE C / HOLD

不足・矛盾 → 保留

根拠がない、旧版と新版が食い違う、必要項目が欠ける。人に追加確認を戻す。

外部へ答える前に、人が確認内容・根拠・宛先を承認して送信。モデルの出力から直接送信しない。

引き継ぎ票の例

説明用の架空例。実在の問い合わせや個人情報は使用していません。

分類
操作案内
要約
CSVの出力手順を知りたい。
根拠
架空の承認済み操作ガイド・第3節
不足
利用画面の版が不明
判定
保留。版を確認してから、該当手順の下書きを作る。

通過条件は、別に確認する

  • 必須項目・出力形式がそろっているか
  • 参照した資料の版・アクセス権が正しいか
  • 回答を支える記述が本当にあるか
  • 例外ルールに当たらないか

拒否・空出力・タイムアウトを正常完了に含めない。AIの自己評価だけで「安全」「正しい」と決めない。

WHAT IS CONFIRMED

小型モデルの進化を、業務の適性と分けて読む

公式仕様 Anthropicは2026年10月7日にClaude Haiku 5.5を公開。モデルIDはclaude-haiku-5-5。テキスト・画像入力、テキスト出力、ツール利用に対応する。[1][2]

最大仕様と、使う範囲

  • コンテキスト：100万token
  • 通常の最大出力：12.8万token
  • 本号の試行：短い問い合わせと必要な根拠に限定

最大文脈長は、長文のすべてを正しく読む保証ではない。不要な履歴・資料を毎回渡すと費用と待ち時間が増える。[2]

「最速」は条件付きの開発元評価

開発元評価 Anthropicの比較は各モデルの通常速度が対象で、OpusのFast Modeは例外。ベンチマークや掲載事例は、この問い合わせフローの実測ではない。[1]

複雑なエージェント型コーディングでは、同社もSonnet／Opusを有力な選択肢としている。仕事の難しさに応じて分ける。

effortは5段階。まずmediumを基準にする

low短い定型と比較
medium既定値
high追加評価
xhigh追加評価
max追加評価

公式仕様 既定値はmedium。lowでは、長い指示に含まれる検索や確認を省く場合がある。effortは厳密なtoken上限ではなく、思考tokenも出力課金と出力上限の対象になる。[3][4]

編集部提案 mediumで品質を確認し、短い定型処理だけlowと比較する。設定を下げて省略された確認を、人の修正時間まで含めて評価する。

提供環境と移行時の注意
  • Claude API、Amazon Bedrock、Google Cloud、Microsoft Foundry、Claude Platform on AWSで提供。機能の一致は別確認。[2]
  • Priority Tierには非対応。拒否時のサーバー側自動fallbackもない。拒否は保留し、通信・API障害時の再試行や通知は運用側で別に決める。[6][7]
  • 新しいtokenizerにより、同じ文章でもHaiku 4.5と使用token数が変わる。旧モデルの実測使用量を、そのまま試算に使わない。[6]

COST / ASSUMPTIONS / TRADE-OFFS

単価は下がる。総費用は再処理まで数える。

公式仕様 以下はClaude API標準料金。USD／100万token、キャッシュ・Batch割引なし。Haiku 5.5はプロンプトが100,000 tokenを超えると、入力・出力の両単価が変わる。[5]

2026-10-09 JST確認。プロンプト長の境界と課金の単位を区別する。
モデル／プロンプト長入力／100万token出力／100万token
Haiku 5.5 · 10万token以下$0.10$0.50
Haiku 5.5 · 10万token超$0.50$2.50
Sonnet 5.5 · 比較用$2.00$10.00
仮定による試算・未実測

1万件を一次処理し、20%をSonnetで再処理する例

各呼び出しの入力2,000token、出力500tokenと仮定。出力には思考分を含める。すべてのプロンプトは10万token以下。Sonnetへ渡す案件も、同じ入出力token数と置く。

$90 $22.50

全件Sonnet → Haiku全件＋Sonnet 20%。この仮定ではtoken料金が$67.50、75%減る。品質と処理時間は未測定。

仮定によるtoken費用の比較全件Sonnetは90ドル。分業はHaiku4.50ドルとSonnet18ドルの計22.50ドル。棒の幅は同じ尺度でドル額に比例。全件Sonnet$90Haiku＋再処理$22.50Haiku $4.50Sonnet再処理 $18USD／1万件。棒の幅は費用に比例。業務の実績値ではありません。
比較はtoken料金のみ。上位モデルへの再処理が増えれば差は縮まる。
全件Sonnet：10,000 × (2,000 × $2 + 500 × $10) ÷ 1,000,000 = $90
Haiku一次処理：10,000 × (2,000 × $0.10 + 500 × $0.50) ÷ 1,000,000 = $4.50
Sonnet再処理：2,000 × (2,000 × $2 + 500 × $10) ÷ 1,000,000 = $18
分業の合計：$4.50 + $18 = $22.50

この試算に含めないもの：追加の引き継ぎtoken、再試行、検索などのツール料、地域加算、税、人件費、キャッシュ・Batch割引。実際の採用判断は、これらと人の修正時間を加えた完了1件の総費用で行う。Bedrock・Google Cloud等の料金は利用先で別確認する。

この75%は本号の仮定による対Sonnet試算。発表にある「平均約75%低コスト」は対Haiku 4.5の開発元説明で、比較対象も計算条件も異なる。[1]

待ち時間は別に測る。Haiku→Sonnetの二段処理や検索が増えると、単価が下がっても完了が遅くなる。モデル単体の出力速度から、業務全体の短縮率は推定しない。

SAFETY IS A SYSTEM RESPONSIBILITY

検索・検証・承認は、モデルの外で設計する

編集部提案 モデルを入れ替えるだけでは、資料へのアクセス権や承認は実装されない。入力から保存・送信までの境界を定める。

モデルの前後に設ける管理の境界前段で認証、権限付き検索、重要案件の除外を行う。モデルは根拠に基づく分類、抽出、下書きを担当。後段で形式、根拠、業務ルールを検証する。最後に人が内容と宛先を承認する。全段階を必要最小限の監査ログと復旧手順で支える概念図。入力と検索認証・権限・資料の版重要案件の除外モデル分類・要約・抽出根拠付きの下書き出力検証形式・根拠・業務ルール失敗・不足を保留人の承認内容・宛先・送信可否必要に応じて外部送信必要最小限のログ・予算上限・再試行上限・保留キュー・現行手順への復旧編集部の概念図。箱の面積は費用・工数・処理量を表しません。

入れる前に決める

  • 利用目的・データ保存先・処理地域・保持期間を確認する。
  • 利用者が読める文書だけを検索対象にする。
  • 個人情報・機密情報を必要以上に送らない。試験は匿名化済み又は合成データから始める。
  • 外部文書の指示は資料として扱い、システムの権限や送信先を変更させない。

失敗しても止められるようにする

  • 契約変更などは最初から担当者へ回す。
  • 拒否、空出力、不正な形式、根拠不一致を保留する。
  • 通信・API障害時の再試行は回数・費用を制限する。安全上の拒否を迂回する再送はしない。
  • ログには版・使用量・検査結果を残し、機密本文の複製を最小限にする。
  • 障害時は保留キューから現行手順へ戻せるようにする。

WHEN TO ADOPT

例外を戻せて、確認まで軽くなるなら採用候補

編集部提案 まず対象業務を狭くする。多くの仕事を一度に移すより、正解と根拠を定義できる1種類で比較する。

採用しやすい条件

  • 件数が多く、分類・抽出の正解を決められる。
  • 参照資料と版が整い、根拠を照合できる。
  • 例外を人へ戻す担当・時間が確保されている。
  • 再処理と人の修正を含めても品質・時間・費用が基準を満たす。

見送る、または範囲を狭める条件

  • 少数の複雑案件が中心で、分類の手間が上回る。
  • 重大な例外を見逃す、根拠を確認できない。
  • 引き継ぎや再処理が増え、効果が消える。
  • 配置・保存条件を満たせない、確認担当がいない。

比較対象には、一律Sonnetの構成だけでなく、現行手順やルールベースの振り分けも含める。簡単な固定ルールで十分な部分までAIに置き換える必要はない。

AN EVALUATION YOU CAN RUN

まず200件。品質を守り、総費用と待ち時間を測る。

編集部提案 未検証 以下の件数と合格基準は、採用判断のたたき台。実績値・保証・全業務共通の基準ではない。

評価用データと比較条件

  1. 1業務・日本語の200件：定型150件、重要・曖昧・情報不足などの例外50件。個人情報は事前に除き、利用許可を確認する。
  2. 正解を先に固定：分類、必須項目、根拠、保留すべき条件を人が付ける。プロンプト調整用のデータと分離する。
  3. 3構成を同条件で比較：一律Sonnet 5.5の基準構成と、Haiku low／mediumを入口にした分業構成。文書・索引の版、設定、入力長、出力上限、同時実行数、キャッシュ条件を記録する。
  4. 難しいケースも入れる：旧版混在、複数資料、矛盾、誤前提、権限越境、不正指示、空出力。検索漏れと生成の誤りを分ける。

暫定合格条件

  • 95%+分類正解率と必須項目の抽出一致率を別々に測り、ともに95%以上。基準構成との差はそれぞれマイナス1ポイント以内。
  • 0件例外50件の見逃し。不要な保留も別集計する。
  • −20%受付からレビュー可能な下書き・保留判定までのp95待ち時間。検索・再処理・再試行を含める。
  • −30%再処理・再試行込みAPI費用。人の修正時間は基準構成以下。

集計は2つに分ける：安全側の例外テストと、本番の案件比率で重み付けした費用・時間。上の200件の配分は、費用試算の再処理率20%を実証するものではない。人の待ち時間・修正時間も含む完了時間を別に報告する。

例外50件で見逃しゼロでも、安全の証明にはならない。重大失敗が出たら採用を止めて原因を確認する。小さな評価を通過した後も、限定運用・監視・復旧経路を用意する。モデル自体の精度、日本語品質、実際の料金・レイテンシは本号では測っていない。

THE NEXT SMALL STEP

1種類の問い合わせを選び、比較条件をそろえる

まず「正解と根拠を付けられる受付」を選ぶ。担当者・データの利用条件・保留先・比較基準がそろったら、下の依頼文を自分の現場に合わせて使う。

コピーだけでデータは送信されません。実在の問い合わせや機密情報を渡す前に、利用条件を確認してください。

BOTTOM LINE

モデルを分ける価値は、
品質を保った「完了1件」で判断する。

単価だけで決めず、保留・再処理・人の確認まで含めて測る。Haiku 5.5は、その比較を始めるための候補です。

PRIMARY SOURCES / EVIDENCE NOTES

一次資料と、まだ分からないこと

確認日：2026-10-09 JST。発表日は記事本文と分けて記載。更新型ドキュメントは、個別の更新日を確認できないため確認日を示す。運用フロー、評価基準、費用例は本号の提案・試算。

  1. Anthropic — Introducing Claude Haiku 5.52026-10-07公表。発表日・用途・料金概要・速度の脚注・複雑な業務への適性。性能や顧客事例は開発元公表として扱う。
  2. Claude Platform Docs — Haiku 5.5 overview ／ Models overviewモデルID、入出力、コンテキスト、最大出力、提供環境などの公式仕様。
  3. Claude Platform Docs — Effort5段階・medium既定・低effort時の挙動。effortは厳密なtoken上限ではない。
  4. Claude Platform Docs — Thinking思考tokenと出力予算・課金の扱い。
  5. Claude Platform Docs — PricingClaude API標準単価、プロンプト長の料金境界、クラウド・地域別料金の扱い。独自試算の単価根拠。
  6. Claude Platform Docs — Haiku 5.5 migration guidetokenizer変更、移行時の互換性と運用上の注意。
  7. Claude Platform Docs — What's new in Haiku 5.5機能・提供条件・制約。環境ごとに利用可能な機能を確認する。

未検証：本号の分業フローにおける日本語精度、実際の再処理率、p95待ち時間、修正工数、総費用、利用環境での機能差。本号には自社実測の成果を掲載していません。

先頭へ
ONE-PAGE BRIEF · 2026.10.09
Haiku 5.5で定型処理をそろえ、検証後に下書き・上位モデル・保留へ分岐。外部へ送る前に人が確認する説明図。

Escでも閉じられます。「原寸で見る」で細かい文字を確認できます。