「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」
の42日目の投稿です！
過去の投稿は以下の（リンク集）からご覧ください！
https://qiita.com/ys-yoshida/private/6f7c7f85155a993e2c86
おそらく42日間続いたリレーもこの記事がアンカーのようです。
自分は４回記事を出させて頂き、いい機会になりました！
リレー運営の方々参加者の皆様お疲れ様でした！
この記事は基本人間が書いて、添削や表図作成にAI（Claude）を使用しています。
内容は執筆時点の情報です。
はじめに
AWS Well-Architected Framework の Agentic AI Lens に、
こんなベストプラクティスがあります。
内容としては、
マルチエージェントの振り分け（ルーティング）判断は、AIを使わなくて済むところではAIを使わず、コストの安い仕組みから使うべき
というものです。
このベストプラクティスを読んでいて引っかかったのが、
「lightweight classifierってなんだ…？」
記事には小型のBedrockモデル、またはルールベースの仕組みとだけ説明されていて、
具体的にどのモデルを使うのかどれくらいの精度/コストになるのかは書かれていません。
「考えはわかるけど結局何なんだ？」と思い検証を始めました。
この記事では、AGENTCOST01-BP03に書かれている閾値や定義を確認した上で、
そこに登場する各方式を自分なりに考え、実装し(ClaudeCodeが)
実際にAmazon Bedrockを呼び出して検証してみた結果をまとめます。
結論
課題の難易度に応じてモデルや手法を選ぶことで精度を落とさず、
コストを数十倍〜100倍単位で削減できる場面があることが分かった一方で、
複雑な判断では安いモデルへの置き換えが精度を明確に落とすことも分かりました。
「情報量」と「モデル性能」は両方が独立して重要というのが、この検証全体の結論です。
AWS公式ドキュメントの記述
まず、AGENTCOST01-BP03に書かれている内容を確認します。
※2026-09-07にAWS公式ページを直接取得して確認
"Quantitative thresholds provide rule-based routing for workflows with fewer than ten deterministic branches, a lightweight classifier for routing across ten to fifty categories, and AI supervisors only for unbounded category spaces that require natural-language understanding."
"A lightweight classifier (a small Amazon Bedrock model or a rule-based heuristic) attempts rule-based routing first and escalates to the full AI supervisor only when its confidence falls below a configured threshold. The escalation rate is the signal for whether the tier is tuned correctly."
日本語で要約すると次の表のようになります。
| ルーティング判断の種類 | 分岐数 | 実装方式（AWS公式） |
|---|---|---|
| Fully deterministic | 10分岐未満 | Rule-based routing（モデル呼び出しなし） |
| Partially deterministic | 10〜50カテゴリ | Lightweight classifier（小型のBedrockモデル、またはルールベースの仕組み） |
| Open-ended | カテゴリ数が無制限 | AI supervisor（自然言語理解が必要な場合のみ） |
上記に加え、分岐等の条件が下回ったときだけ、lightweight classifierから
AI supervisorへ処理を引き上げる、hybrid patternも明記されていました。
「Lightweight classifier = 小型LLM」はAWSの唯一の定義ではないです。
AWS公式は「小型のBedrockモデル」と「ルールベースの仕組み」を
同格の選択肢として明記しています。この記事では小型LLMを使うという実装を
行いますが、AWSがそれを必須としているわけではありません。
検証設計
4つの方式を実装し、同じ問い合わせセットに対して精度・速度・トークン量・コストを比較しました。
| 方式 | 実装 | 渡す情報量 | AI呼び出し回数 |
|---|---|---|---|
| Rule-based | キーワードの部分一致で採点 | キーワード一覧のみ | なし |
| Lightweight Classifier | Amazon Nova Micro + 構造化出力 | 担当の「識別子＋名前」タグのみ | 1回 |
| AI Supervisor | Claude Sonnet 5 + 構造化出力 + プロンプトキャッシュ | 説明カード一式（役割／対応範囲／対応外範囲／例文） | 1回 |
| Hybrid | Classifier → confidence(信用値) < 0.6 で Supervisorへ切替 | 上記の組み合わせ | 1〜2回 |
なぜ情報量をバラバラにしたのか
AWSは
「lightweight classifierは10〜50カテゴリ向け」
「AI supervisorはunboundedなカテゴリ空間向け」
と定義しています。
これは単にモデルサイズの違いだけでなく、
supervisorが引き受ける場面はそもそも固定の短いリストに収まらない、
より多くの文脈を要する場面という含意があると考えました。
そこでこの検証ではclassifierには最小限のタグ一覧だけ、
supervisorには対応範囲・対応外範囲・複数の例文を含む「AgentCard」相当の情報を渡し、
供給する情報量そのものに差をつけて比較しています。
※AgentCardは全リクエストで同一内容のため、プロンプトキャッシュを使って
2回目以降は割安なcache readとして処理する構成にしてます。
この検証における「軽量AI（lightweight classifier）」
モデルはAmazon Nova Microを利用します。
繰り返しになりますが、AWS公式はlightweight classifierを
「小型のBedrockモデル、またはルールベースの仕組み」
としか定義していません。
具体的にどのモデルを使うかは自分が選んだものです。
「タグ名だけを見て分岐する」という単純な仕事にどのモデルを使うべきか検討した結果、
AWS公式のモデルカードにこんな記述を見つけました。
"Nova Micro is Amazon's fastest text-only model, optimized for speed and low cost in tasks like summarization, translation, and classification."
出典: Amazon Bedrock model card — Nova Micro
AWS公式が"classification"用途を明示的に挙げているモデルだったので、
この検証では**lightweight classifierをAmazon Nova Microとして実装しました。
| 項目 | 値 |
|---|---|
| Bedrockでのモデル識別子 | amazon.nova-micro-v1:0 |
| 呼び出し方式 | リージョン横断の推論プロファイル経由（単一リージョン指定は不可。実行時にValidationExceptionで判明） |
| 単価（入力／出力・100万トークンあたり） | $0.035 / $0.14 |
| 渡す情報 | 各カテゴリの「識別子」と「名前」だけを列挙。説明文・対応範囲・例文は一切渡さない |
※比較対象として、同一設計をClaude Haiku 4.5でも実測しました
この検証における「AI Supervisor」
モデルはClaude Sonnet 5を利用します。
同様に、AI Supervisorも
「自然言語理解が必要な場合に使う、より高性能なモデル」
という抽象的な定義しかAWS公式には書かれていません。
この検証では、複雑な判断が必要な役としてClaude Sonnet 5を選び、実装しました。
| 項目 | 値 |
|---|---|
| Bedrockでのモデル識別子 | anthropic.claude-sonnet-5 |
| 呼び出し方式 | リージョン横断の推論プロファイル経由（単一リージョン指定は不可） |
| 単価（入力／出力・100万トークンあたり） | $3.00 / $15.00 |
| 渡す情報 | 役割（role）・対応範囲（capabilities）・対応外範囲（boundaries）・複数examplesを持つAgentCard一覧 |
| 構造化出力 | Bedrockの「Structured outputs」機能は非対応のため、Converse APIのtool use（toolConfig）でJSON出力を強制 |
Hybridパターンの仕組み
AWS実装ステップ3（段階的なhybridパターン）をそのまま模倣しています。
※図が小さいので拡大してみてください。
検証データについて
10ドメイン（請求・配送・返品・アカウント...）
10アクション（状況確認・変更依頼・クレーム...）
をかけ合わせて100カテゴリ用意し、そこから5件・10件を抜き出しました。
評価データは各カテゴリについて次の7種類のバリエーションを
LLM（Claude Sonnet 5）に生成させました。
分類器のプロンプトに埋め込む例文とは重複しないことを機械的にチェックしています。
- CLEAR（明確な言い方）
- AMBIGUOUS（曖昧な言い方）
- CROSS_CATEGORY（複数カテゴリに関係）
- PARAPHRASE（言い換え）
- TYPO（誤字・脱字あり）
- COLLOQUIAL（口語・くだけた表現）
- ADVERSARIAL（意図的に紛らわしい）
実際のテストケース例は以下のようなものです。
（billing_status_inquiryカテゴリ、CLEARパターン）
今月分の請求書がまだ届いていないのですが、支払いの処理が進んでいるか確認したいです。
結果1: 精度の実測結果
10カテゴリ・140件、5カテゴリ・70件で実測しました。
| 方式 | scale | Accuracy | Macro F1 | latency p50 | latency p95 |
|---|---|---|---|---|---|
| Rule-based | 10 | 47.1% | 0.489 | 0.010 ms | 0.012 ms |
| Lightweight Classifier (Nova Micro) | 10 | 82.9% | 0.831 | 657 ms | 754 ms |
| AI Supervisor (Sonnet 5) | 10 | 85.7% | 0.858 | 2,437 ms | 3,517 ms |
| Hybrid | 10 | 83.6% | 0.834 | 1,103 ms | 3,600 ms |
結果、AI Supervisorの精度がLightweight Classifierを 2.8% 上回りました。
ただ、この差が「情報量の効果」なのか「モデル性能の差」なのかは、この時点ではまだ分離できていません（後述の対照実験で分離します）。
曖昧さの種類別Accuracy（おまけ）
| variation_tag | Rule-based | Lightweight Classifier | AI Supervisor | Hybrid |
|---|---|---|---|---|
| CLEAR | 0.70 | 1.00 | 1.00 | 1.00 |
| PARAPHRASE | 0.50 | 1.00 | 1.00 | 1.00 |
| TYPO | 0.60 | 1.00 | 1.00 | 1.00 |
| COLLOQUIAL | 0.65 | 0.95 | 1.00 | 0.95 |
| CROSS_CATEGORY | 0.40 | 0.65 | 0.75 | 0.65 |
| AMBIGUOUS | 0.00 | 0.40 | 0.40 | 0.40 |
| ADVERSARIAL | 0.45 | 0.80 | 0.85 | 0.85 |
CROSS_CATEGORYとAMBIGUOUSは4方式共通の弱点でした。
Lightweight Classifierで十分かは関係なく、
単一カテゴリに決め切れない問い合わせをどう扱うかという設計課題だと思います。
結果2: トークン・コストの実測結果
| 方式 | input tok/件 | output tok/件 | cache write合計 | cache read合計 | cache hit rate | cost/件 |
|---|---|---|---|---|---|---|
| Rule-based | 0 | 0 | - | - | - | $0.0000 |
| Lightweight Classifier | 779 | - | - | - | - | $0.0000313 |
| AI Supervisor | 229（非cache分） | - | 3,876 | 538,764 | 99.3% | $0.0029165 |
| Hybrid | - | - | 0 | 58,140 | 10.7% | $0.0015〜$0.0045 |
AI Supervisorのinput tokenが小さく感じるのはキャッシュを使っているからです。
実測のhit rate 99.3%は、ベンチマークの実行方法によるベストケースです。
140件実行中、cache writeは最初の1件だけで、139件は全てcache readでした。
リクエスト間隔を空けずに連続実行したためTTLが失効しなかったわけですね。
実際の運用のように問い合わせが数分〜数十分おきにポツポツ来る場合は
TTLが切れてcache writeが発生しやすくなり、この結果は再現しない可能性が高いです。
ただ、それでもAI Supervisorはコストで大きく不利になりました。
cache hit rateを変えるとコストはどう動くか
実測トークン構造から、追加のAPI呼び出しなしで解析的に算出しました。
| hit rate | cache read | cache write | cost/件 |
|---|---|---|---|
| 100% | 3,876 | 0 | $0.0028 |
| 80% | 3,101 | 775 | $0.0055 |
| 60% | 2,326 | 1,550 | $0.0082 |
| 40% | 1,550 | 2,326 | $0.0108 |
| 20% | 775 | 3,101 | $0.0135 |
| 0% | 0 | 3,876 | $0.0162 |
先ほどはhit rateがほぼ100%の場合だったので、
コスト差は89倍に収まりましたが(収まってはない)
hit rateが0%だと518倍の差がつきます。
机上計算: カテゴリ数 × hit rate の相乗効果
20/50/100カテゴリはBedrockを実際に呼んで計測してはいませんが、
5・10カテゴリの実測データから机上計算で算出しました。
実測から分かった傾き、20/50/100カテゴリまで線形に延長して算出した数値です。
※Lightweight Classifierは1カテゴリごとに約26トークン
AI SupervisorのAgentCardは1カテゴリごとに約332トークン増える
| カテゴリ数＼hit率 | 100% | 80% | 60% | 40% | 20% | 0% |
|---|---|---|---|---|---|---|
| 5 | 1.84x | 3.05x | 4.25x | 5.46x | 6.66x | 7.86x |
| 10 | 2.03x | 3.94x | 5.85x | 7.77x | 9.68x | 11.59x |
| 20 | 2.32x | 5.31x | 8.31x | 11.31x | 14.31x | 17.31x |
| 50 | 2.81x | 7.69x | 12.57x | 17.45x | 22.32x | 27.20x |
| 100 | 3.18x | 9.46x | 15.74x | 22.01x | 28.29x | 34.57x |
cache missはAgentCard本体のサイズにかかるため、
カテゴリ数が多いシステムほど、hit rateを高く維持することの重要性が跳ね上がります。
モデル能力の対照実験
結果コストが安くなる結果でHappyだったのですが、
Lightweight ClassifierとAI Supervisorはモデルのコスト差が出ただけで、
Nova MicroにAI Supervisorをさせれば結果は覆るのでは？と思い、検証しました。
| 方式 | scale | Accuracy | Macro F1 | latency p50 | cost/件 |
|---|---|---|---|---|---|
| Supervisor (Sonnet 5) | 10 | 85.7% | 0.858 | 2,437 ms | $0.0029165 |
| Supervisor (Nova Micro) | 10 | 75.7%（-10.0pt） | 0.758 | 794 ms | $0.0000159 |
| Supervisor (Sonnet 5) | 5 | 85.7% | 0.859 | 2,275 ms | $0.0024690 |
| Supervisor (Nova Micro) | 5 | 75.7%（-10.0pt） | 0.762 | 674 ms | $0.0000135 |
同一AgentCardで比較した結果Nova MicroはSonnet 5と比較して正解率が大きく下がりました。
variation_tag別に見ると、CLEARだけは両モデルとも100%なので、
簡単な問題はどちらも解けるのですが、それ以外の難易度では、
Sonnet 5がNova Microを上回りました。
| variation_tag | Sonnet 5 | Nova Micro | 差 |
|---|---|---|---|
| CLEAR | 1.00 | 1.00 | ± 0 |
| PARAPHRASE / TYPO / COLLOQUIAL | 1.00 | 0.85〜0.90 | -0.10〜-0.15 |
| CROSS_CATEGORY / AMBIGUOUS | 0.75 / 0.40 | 0.60 / 0.25 | -0.15 / -0.15 |
結論
「情報量を増やす効果」（同一モデルでタグのみ→AgentCardにすると精度が上がる）
「モデルを強くする効果」（同一AgentCardでNova Micro→Sonnet 5にすると精度が上がる）
の両者は、それぞれ独立して実在することが実測結果から確認できました。
- タグ分岐（単純な仕事）ではモデルの差がほぼ出ない（Nova Micro ≒ Haiku 4.5）
- AgentCard判断（複雑な仕事）ではモデルの差が明確に出る（Sonnet 5 > Nova Micro、10pt差）
これはAWS公式AGENTCOST01-BP03の「課題の決定性・複雑さに応じてモデルを選ぶ」
という思想を、実測で裏付ける結果になりました。
Lightweight Classifierのモデル選定は正しかったか（おまけ）
Lightweight Classifierについても、
「AWSが名指しする専用モデル（Nova Micro）が本当に良いのか」
を確認するため、同一設計をClaude Haiku 4.5でも実測しました。
| 方式 | scale | Accuracy | Macro F1 | latency p50 | cost/件 |
|---|---|---|---|---|---|
| Lightweight (Nova Micro・採用) | 10 | 82.9% | 0.831 | 657 ms | $0.0000313 |
| Lightweight (Haiku 4.5・比較対象) | 10 | 82.9%（同一） | 0.830 | 1,103 ms | $0.0013957（44.6倍高い） |
| Lightweight (Nova Micro・採用) | 5 | 80.0% | 0.798 | 650 ms | $0.0000271 |
| Lightweight (Haiku 4.5・比較対象) | 5 | 84.3%（+4.3pt） | 0.850 | 1,093 ms | $0.0012736（47倍高い） |
10カテゴリ規模では正解率が完全に同一のまま、
Haiku 4.5は44.6倍もコストが高い結果でした。
Nova Micro採用の判断は正しかったと言えます。
5カテゴリ規模ではHaiku 4.5の方が精度4.3pt高いため、
精度要件が厳しい場合の代替候補として結果を残しています。
まとめ
| 役割 | 選定したモデル | 理由 |
|---|---|---|
| Lightweight Classifier | Amazon Nova Micro | AWS公式が"classification"用途を明示。Haiku 4.5と比較しても精度同一・44.6倍安い |
| AI Supervisor | Claude Sonnet 5 | Nova Micro化は-10.0ptの精度低下があり不採用。複雑な判断にはモデル性能が必要 |
課題の難易度に応じてモデルを選ぶことで、精度を落とさずコストを
数十倍〜100倍単位で削減できる場面がある一方、複雑な判断では安いモデルへの
置き換えが精度を明確に落とします。
「情報量」と「モデル性能」は両方が独立して重要というのが、この検証全体の結論です。
既知の限定事項
-
料金の出典
⇒Haiku 4.5 / Sonnet 5 / Nova Microの単価は記事公開日段階に確認した値です。 -
カテゴリ数の推定
⇒20/50/100カテゴリの相乗効果は5・10カテゴリの実測2点からの机上計算です。 -
モデル選定の厳密性
⇒対照実験はNova Microを軸にした3モデル比較であり、厳密な2×2実験は未実施です -
検証規模
⇒検証コストから5・10カテゴリ規模（各70〜140件）に留めています。