Amazonの社内チケット分類で、長く使ってきた Claude Sonnet 4.6 を、Strands Decider という決定モデルに置き換えたところ、性能はほぼそのままでコストは大きく下がった、という話です。単なるモデルの乗り換えではなく、「文章を生成する大きなLLMを使う場面」と「選択肢から判断するだけで足りる場面」は分けられる、という実例になっています。AIのコスト最適化が抽象論ではなく、実運用でどこまで効くのかを示した点が面白いところです。しかもこれは研究室の小さな実験ではなく、AmazonとAWSの巨大な内部チケットシステムでの話です。
元記事が伝えているのは、Amazonの2人のエンジニアが、社内の大規模なチケット分類システムで Claude Sonnet 4.6 をやめ、Strands Decider に置き換えた結果、同等の精度を保ちながらトークンコストを98%減らせた、という事実です。対象は顧客エスカレーション、容量リクエスト、自動アラート、セキュリティ指摘など、社内で扱うさまざまなチケットで、20種類のカテゴリに振り分ける仕組みでした。従来は長い system prompt を毎回与え、LLM に JSON を出させてラベルを決めていました。
ここで使われた Strands Decider は、文章を生成するモデルではなく、与えられた状態と質問、そして選択肢に対して、それぞれの確率と confidence score を返す「decision model」です。Amazon側はまず Strands Decider 2B を試し、その後、テストセットでより良い結果を出した E4B Gemma 4 に切り替えました。さらに、どのくらい高い confidence ならラベルを採用するかも調整し、別の検証用チケットセットで production Sonnet を上回る結果を確認したとしています。
実運用では、E4B を SageMaker の ml.g5.xlarge インスタンスで動かしました。1インスタンスは A10G GPU 1枚、メモリ24GBで、モデル自体は約19GiBを使い、1リクエストあたり約640msだったと説明されています。エンドポイントはオートスケールしつつもネットワークは隔離され、S3 から重みを読み込んで起動する構成です。チケットイベントは SQS に入り、Lambda がそれを受けてモデルを呼び出します。AppConfig で切り替えを管理し、CloudWatch でログやメトリクス、アラームを見る。記事は、これらが標準的な AWS サービスの組み合わせであり、顧客側でも再現できると書いています。
切り替えは慎重に行われました。Lambda は AWS AppConfig から毎回3段階の設定を読みにいき、BEDROCK、DUAL、DECIDER の3モードを切り替えます。BEDROCK は Sonnet のみ、DUAL は Sonnet と Strands Decider を並列実行して比較しつつ結果は Sonnet を採用、DECIDER は Strands Decider のみで分類します。比較結果としては、平均処理時間が 4,215ms から 897ms に短縮され、入力トークンは 6,554 から 2,009、出力トークンは 170 から 1、合計トークンは 6,724 から 2,010 になりました。Lambda の実行時間も平均で74%落ちたとされています。価格面では、公開価格ベースで Sonnet は million input tokens あたり $3.00、output tokens は $15.00、Strands Decider E4B は SageMaker のインスタンス課金で、1 ticket あたり約$0.0005、100万件で約$500です。記事は、これは Sonnet の約44分の1、98%の削減だとしています。
私がまず強いと思ったのは、これが「より高性能なモデルに置き換えた」話ではなく、「仕事の形に合わない高級モデルを外した」話だという点です。チケット分類は、最終的に必要なのが自然な文章ではなく、限られたラベルのどれかであることが多い。そこに毎回大きなLLMを呼ぶのは、確かに便利ではあるものの、道具の選び方としては過剰です。元記事はその無駄をかなり露骨に示していて、生成をやめるだけで出力トークンが 170 から 1 になるのは象徴的でした。これは「AI を安く使う」ではなく、「問題の形を変えて、そもそも安くできるようにする」発想です。
ただし、ここで見落としてはいけないのは、決定モデルにすれば何でも安くなるわけではないことです。ラベルの説明を1〜2文に再定義し、20カテゴリを単一の選択問題に落とし込み、長いチケットでは古いコメントを切る、といった設計変更がかなり効いています。つまり節約の本体はモデルだけではなく、入力の作り方そのものです。私はこの点が重要だと思います。生成AIの議論はモデル性能ばかりに寄りがちですが、実際には「何をどう入力するか」でコストも品質も大きく変わります。Amazonの事例は、その当たり前をかなりはっきり見せています。
記事の中で実務的だと思ったのは、いきなり Sonnet を止めず、BEDROCK、DUAL、DECIDER を AppConfig で切り替える運用です。これは地味ですが、こうした移行で一番怖いのは、精度が少し落ちただけでも大量のチケットで被害が広がることだからです。DUAL モードで並走させ、差分を見ながら移すのはかなり堅い進め方だと思います。特に社内のチケット分類のような業務は、間違いが直接ユーザーの目に触れたり、別部署の処理に波及したりします。だからこそ、性能比較より先に「壊さない移行」がある。そこは派手ではないけれど、実運用では最重要です。
一方で、この記事は成功事例としてはかなり鮮やかですが、一般化には少し注意が必要です。分類の対象が20カテゴリに限られていて、しかも選択肢が比較的はっきりしているからこそ、決定モデルが刺さった面があるはずです。自由記述の要約、複数の論点を含む判断、説明責任が必要な生成タスクでは、同じやり方がそのまま効くとは限りません。私はむしろ、この事例は「LLM を置き換える万能策」ではなく、「選択問題に落とせる業務を見つけると、AI コストは劇的に下がる」という示唆として読むべきだと思います。
この事例で見逃しにくいのは、コスト比較が単純な推論単価だけでは終わっていないことです。Sonnet は token ベースの課金で、Strands Decider は SageMaker のインスタンス課金です。つまり、どちらが安いかは「モデルがいくらか」だけでなく、「どれだけ長く動き、どれだけ詰めて処理できるか」にも左右されます。記事は 1 request あたり約640ms、1インスタンスで約5,600 tickets/hour、実運用ではバースト用の余裕を持たせて約$500 per million tickets と説明しています。ここが面白い。AIのコスト最適化は、モデルの値札を比べるだけでは不十分だと、AWS自身が言っているようなものです。
さらに、この話は「AIエージェント時代」のインフラ設計にもつながると思います。Strands Agents の文脈で語られている以上、単なる1モデルの成功例ではなく、ハーネス、SQS、Lambda、SageMaker、AppConfig、CloudWatch を組み合わせた運用の一部です。要するに、これからは「どのモデルを使うか」だけでなく、「どの処理をどの層で受け持つか」が問われる。生成が必要な箇所は大きなLLM、判断だけなら decision model、そして両者を安全に切り替える仕組みが要る。私は、この事例が示している本質はそこだと思います。AIの進化そのものより、AIを業務システムの中で細かく分業させる方向が強くなっているのではないでしょうか。
参考: Amazon saves millions by replacing Sonnet 4.6 with Strands Decider
