# AI省エネ・モデルルーティング編

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-018-ai
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-018-URL-4E19329870F7, EVD-EA-018-URL-9C1F04FED0A9, EVD-EA-018-URL-DB03BFD6A12C, EVD-EA-018-URL-57A8873132AC, EVD-EA-018-URL-4B938E611C70, EVD-EA-018-URL-F54F84DBCFE8, EVD-EA-018-URL-E02276C332D2, EVD-EA-018-URL-0D7CEA708C0D, EVD-EA-018-URL-3969EE1849B9, EVD-EA-018-URL-24977847E7E6, EVD-EA-018-URL-452B01DE327B, EVD-EA-018-URL-51DBA37EBCDA, EA-018-R11-RESEARCH, EA-018-R11-WEB-READBACK
UNKNOWN_IDS: EA-018-UNKNOWN-01, EA-018-UNKNOWN-CURRENTNESS
OPS_IDS: none

## Summary
「モデルルーティングは、すべての要求を最上位モデルへ送る代わりに、要求ごとの必要能力や組織ポリシーに応じて候補を選び、品質条件を満たす範囲で費用・遅延・計算資源を最適化する制御層として利用できる。ただし、公開benchmarkやベンダー公称の節約率は自組織workloadの保証値ではない。候補model、価格、tool/context対応、region、cache、fallbackが変われば効果も変わるため、固定baselineに対する継続評価が必要である。金銭コストの低下をそのまま省エネとみなさず、energyを主張する場合は測定境界を明示した実測値を用いる。」

## Current judgment
1. **Routingはモデル選択ではなくcontrol planeである。** 法人向けには少なくとも `eligibility filter → cache/local shortcut → router decision → selected model/runtime → fallback/retry → result/trace → eval feedback` の連鎖で記述する方が実態に合う。
2. **強いモデル固定は常にPareto最適ではない。** RouteLLM/FrugalGPTは、workloadを難易度・confidence等で分け、弱/安価modelを使える問い合わせへ割り当てることでcost-quality frontierを改善し得ることを示す。
3. **managed routerと自作routerを分離する。** managed routerはmodel pool、region、deployment、tool/context capability等のavailability gateを持つ。自作/OSS routerは制御自由度が高いが、モデル能力metadata、pricing、health、fallback、security policy、driftを運用者が管理する必要がある。
4. **cost、latency、energyは別目的関数。** 安価なAPIが必ずしも低energyではなく、短いlatencyも低energyを保証しない。energy claimは、可能なら同一task/hardware/software条件の実測値を使う。
5. **cacheはrouting効果を変える。** prompt cacheは同一model/prefixの再利用に依存するため、per-turn routingでmodelが揺れるとhit benefitを失う場合がある。router評価にはmodel-selection distributionとcache-hit/writeを同時記録する。
6. **local処理もcandidate routeの一種として扱えるが、前提が異なる。** EA-009/010のself-host/edge manifestを参照し、data locality、offline、hardware capacity、quantization品質を通過したtaskだけをlocal route候補にする。cloud modelと単価だけで比較しない。
7. **router自身もdriftする。** candidate model、version、price、region、tool support、rate limit、traffic mixが変化すれば最適routingは変わる。固定導入ではなく再評価loopが必要。

## Scope
Enterprise AI Core / provider mapping / interoperability / implementation / benchmark / cost engineering / sustainability / non-LLM control plane

## Confirmed
- **Routingはモデル選択ではなくcontrol planeである。** 法人向けには少なくとも `eligibility filter → cache/local shortcut → router decision → selected model/runtime → fallback/retry → result/trace → eval feedback` の連鎖で記述する方が実態に合う。
- **強いモデル固定は常にPareto最適ではない。** RouteLLM/FrugalGPTは、workloadを難易度・confidence等で分け、弱/安価modelを使える問い合わせへ割り当てることでcost-quality frontierを改善し得ることを示す。
- **managed routerと自作routerを分離する。** managed routerはmodel pool、region、deployment、tool/context capability等のavailability gateを持つ。自作/OSS routerは制御自由度が高いが、モデル能力metadata、pricing、health、fallback、security policy、driftを運用者が管理する必要がある。
- **cost、latency、energyは別目的関数。** 安価なAPIが必ずしも低energyではなく、短いlatencyも低energyを保証しない。energy claimは、可能なら同一task/hardware/software条件の実測値を使う。
- **cacheはrouting効果を変える。** prompt cacheは同一model/prefixの再利用に依存するため、per-turn routingでmodelが揺れるとhit benefitを失う場合がある。router評価にはmodel-selection distributionとcache-hit/writeを同時記録する。
- **local処理もcandidate routeの一種として扱えるが、前提が異なる。** EA-009/010のself-host/edge manifestを参照し、data locality、offline、hardware capacity、quantization品質を通過したtaskだけをlocal route候補にする。cloud modelと単価だけで比較しない。
- **router自身もdriftする。** candidate model、version、price、region、tool support、rate limit、traffic mixが変化すれば最適routingは変わる。固定導入ではなく再評価loopが必要。

## UNKNOWN
- EA-018-UNKNOWN-01: - provider横断でcomparableなrequest-level energy telemetryを法人ユーザーが取得できる標準surfaceは今回確立できない。
- managed router内部のquality predictor/training data/scoreの完全な透明性はproviderごとに異なり、公開仕様以上はUNKNOWN。
- router導入による実組織TCO・total-energy削減率はworkload mix、traffic volume、fallback、cache、pricingに依存し、外部研究値で閉じない。
- local/cloud hybrid routingにおけるdata residency・security approvalはorganization-specific。
- EA-018-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-018-URL-4E19329870F7 (RESEARCH): - author/org: Isaac Ong et al. / LMSYS collaboration — https://arxiv.org/abs/2406.18665
- EVD-EA-018-URL-9C1F04FED0A9 (RESEARCH): - author/org: Lingjiao Chen, Matei Zaharia, James Zou — https://arxiv.org/abs/2305.05176
- EVD-EA-018-URL-DB03BFD6A12C (RESEARCH): - author/org: Amazon Web Services — https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html
- EVD-EA-018-URL-57A8873132AC (RESEARCH): - author/org: Microsoft — https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router
- EVD-EA-018-URL-4B938E611C70 (RESEARCH): - author/org: Microsoft — https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/evaluate-model-router
- EVD-EA-018-URL-F54F84DBCFE8 (RESEARCH): - author/org: lm-sys — https://github.com/lm-sys/RouteLLM
- EVD-EA-018-URL-E02276C332D2 (RESEARCH): - author/org: MLCommons — https://mlcommons.org/benchmarks/inference-datacenter/
- EVD-EA-018-URL-0D7CEA708C0D (RESEARCH): companion: — https://mlcommons.org/working-groups/benchmarks/power/
- EVD-EA-018-URL-3969EE1849B9 (RESEARCH): canonical URLs: — https://huggingface.co/blog/sasha/ai-energy-score-v2
- EVD-EA-018-URL-24977847E7E6 (RESEARCH): canonical URLs: https://huggingface.co/blog/sasha/ai-energy-score-v2 ; — https://github.com/huggingface/AIEnergyScore/blob/main/index.md
- EVD-EA-018-URL-452B01DE327B (RESEARCH): canonical URLs: — https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching
- EVD-EA-018-URL-51DBA37EBCDA (RESEARCH): canonical URLs: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching ; — https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
- EA-018-R11-RESEARCH (RESEARCH): EA-018 監査済みresearch / canonical revision binding
- EA-018-R11-WEB-READBACK (IMPL): EA-018 Web body identity / canonical readback

## Failure / limits
Router misclassification: 難しいtaskを弱modelへ送りaccepted qualityを落とす、または容易taskを上位modelへ送り節約を失う。
## Failure / limits
Domain shift: router学習/benchmarkと実workloadが異なり、specialized categoryだけ劣化する。
## Failure / limits
Capability mismatch: context window、structured output、tool calling、vision等の必要能力を満たさないmodelを選択する。
## Failure / limits
Policy mismatch: region/data-zone/provider/model allowlistに違反する候補をpoolへ入れる。
## Failure / limits
Cache fragmentation: selected modelの変動でprompt cache hitが落ち、想定したcost/latency削減が失われる。
## Failure / limits
Retry/fallback amplification: 一度のrouting失敗が複数model attemptへ増幅し、tail cost/latency/energyを悪化させる。
## Failure / limits
Price drift / model refresh: provider価格やrouting pool更新で過去の最適点が無効になる。
## Failure / limits
Energy opacity: managed APIではrequest単位のphysical energyを公開しない場合が多く、token costからjouleを推測で確定しない。
## Failure / limits
Benchmark transport risk: RouteLLM/FrugalGPT等の公開benchmark上の節約率を自組織taskへ保証値として転記しない。
## Failure / limits
Rebound effect: 1件あたりを安くしても総呼出量が増えれば総費用/総energyが減らない。省エネはper-requestだけでなくperiod totalも見る。
## Failure / limits
routingを一つの万能optimizerとせず、quality/cost/latency/policy/energyを分離した評価設計を確立した。
## Failure / limits
learned/cascade/managed/gateway routerの実装状態と境界を一次資料・原著研究・OSSで裏付けた。
## Failure / limits
monetary costとenergyを分離し、実測可能時のenergy評価方法と未測定時のUNKNOWN規則を定めた。
## Failure / limits
cache、fallback、model refresh、policy、local routeを将来Workが実測できるTEST_PROFILEへ落とした。


BOUNDED_CLOSE: EA-018
## Practice
provider / region / deployment type / account entitlement
## Practice
candidate model availability and lifecycle
## Practice
model subset / same-family restriction where applicable
## Practice
context window / modality / tool / structured-output compatibility
## Practice
data residency / policy allowlist
## Practice
quota / rate limit / capacity
## Practice
local hardware/runtime/quantization availability
## Practice
prompt-cache support, prefix requirements, TTL, cache-write/read pricing
## Practice
routing mode and router version
## Practice
Learned two-model router: research + OSS implementation (RouteLLM).
## Practice
Cascade/router optimization: research evidence (FrugalGPT).
## Practice
Managed production routing surface: implemented in AWS Bedrock and Microsoft Foundry; exact pool/regions/version are PRODUCT_VOLATILE.
## Practice
Gateway/load-balancing router: maintained OSS ecosystems (e.g. LiteLLM) implement latency/cost/usage/fallback strategies;これらは「task能力を予測するrouter」と「deployment load balancer」を同一視しない。
## Practice
Energy-aware routing: measurement initiatives and research direction exist, but provider横断でrequest単位energyを同じ方法で取得できる共通production standardは今回確立できず UNKNOWNを残す。
## Practice
Router評価はfixed-model baselineと同一代表workloadで行い、少なくとも次を同時記録する。
## Practice
accepted task rate / critical-category failure rate
## Practice
selected-model distribution by workload category
## Practice
monetary cost per accepted task; p50/p95/p99
## Practice
latency p50/p90/p95/p99
## Practice
retry/fallback count and amplification
## Practice
cache hit/write tokens where available
## Practice
quota/rate-limit/error behavior
## Practice
local route rate where applicable
## Practice
measured energy per accepted task (J or Wh) only when測定境界・hardware・software・taskが固定される場合
## Practice
period total cost / total energy / total accepted tasks
単一の「省エネscore」へ圧縮せず、quality thresholdを先に置いてPareto frontierで比較する。
## Practice
Security/Privacy: router前にpolicy eligibility filterを置き、機密taskを未承認provider/modelへrouteしない。routing decision自体へprompt全文を不要に永続保存しない。
## Practice
Audit: request ID、router version/config、eligible pool、selected model/version、routing mode/score（取得可能範囲）、fallback attempts、cache usage、latency、cost、policy decisionを記録。hidden chain-of-thoughtは監査要件にしない。
## Practice
Cost: router overhead、underlying model charge、cache write/read、retry/fallback、gateway/runtimeを含めEA-017のCOST_PER_ACCEPTED_TASKへ統合。
## Practice
Operability: shadow/canaryで導入し、critical taskにはdirect fixed-model routeまたはhard floorを残す。model/provider更新時は同じfixtureでregressionを再実行する。
## Practice
Sustainability: monetary priceをenergy proxyとして確定しない。実測不可ならenergyはUNKNOWN/UNMEASUREDとし、compute tier/model size等は補助説明に留める。
## Practice
将来Workでは次を優先する。
## Practice
`ROUTING_POLICY_RECORD`を作成: policy_id / router product+version / allowed models+versions / region / routing mode / quality floor / direct-route exceptions / fallback chain / cache policy / local-route eligibility / cost budget / energy metric availability / owner / review date。
## Practice
EA-016のEVAL_CASE_RECORDとEA-017のWORKLOAD_COST_PROFILEを結合し、router導入前後を同じfixtureで比較する。
## Practice
Azure Foundry Model Router、Amazon Bedrock Intelligent Prompt Routing、custom RouteLLM/LiteLLM系を同じcomparison matrixへ置く。ただしmanaged ML routerとload-balancer/gatewayを別classにする。
## Practice
公開直前にcandidate pool、region、router version、pricing、tool/context support、cache仕様を再採集する。
## Practice
energy比較が必要な章ではMLPerf Power/AI Energy Scoreのmethodologyを参照し、cloud proprietary APIについてrequest-level jouleが公開されない場合は推測で埋めない。


### TEST_PROFILE-018-A — Quality-floor routing regression（未実施）
同一代表fixtureを fixed-frontier / fixed-small / router で実行。accepted qualityをhard constraintとし、cost、latency、selected-model distributionを比較。critical categoryでquality floorを下回ればrouting policyをreject。


### TEST_PROFILE-018-B — Router drift / model refresh（未実施）
router version、candidate models、pricing snapshotを固定してbaselineを保存。providerがmodel pool/versionを更新した後に同fixtureを再走し、model distribution、quality、cost、tail latency差を検出。


### TEST_PROFILE-018-C — Cache × routing interaction（未実施）
長い共通prefixを持つ反復requestを用意し、fixed-modelとper-request routerでcache hit/write、cost、latencyを比較。model選択変動によるcache fragmentationを確認。


### TEST_PROFILE-018-D — Fallback amplification（未実施）
安全なmock/fault injectionで候補model timeout/rate-limitを発生させ、ordered attempts、retry/fallback回数、duplicate side effect有無、p95/p99 latency、cost amplificationを測る。外部書込みtoolは使わない。


### TEST_PROFILE-018-E — Local/cloud route（未実施）
EA-009/010の承認済みlocal runtimeとcloud候補を、公開/非機密fixtureで比較。quality、latency、local device energy（測定可能時）、cloud monetary cost、network dependencyを記録。機密dataは投入しない。


### TEST_PROFILE-018-F — Energy-aware comparison（未実施）
自己管理hardwareでのみ、同一task、同一output length policy、同一hardware/software measurement boundaryを固定し、候補modelごとのJ/accepted-taskまたはWh/accepted-taskを測る。wall-powerまたは検証済みmeterを優先し、TDPを実測値へ代用しない。
## WHY_THIS_MATTERS_TO_UPDATE
原案台帳は、分類・軽量モデル・上位推論・ローカル処理・キャッシュ等を組み合わせた費用最適化をEA-018の対象とする。公開後アップデートでは「最安モデルへ送る」だけではなく、品質・金銭コスト・遅延・可用性・policy・計算/電力効率を同時に扱うrouting/control planeとして整理する必要がある。特に、モデル単価の低下を省エネと同一視せず、model selection、cache、local/offline処理、fallback/retry、energy measurementを別々の制御面として扱う。

## SCOPE_ROUTING
Enterprise AI Core / provider mapping / interoperability / implementation / benchmark / cost engineering / sustainability / non-LLM control plane

## CLAIM_OR_RESEARCH_QUESTION
1. workloadごとに強いモデル固定ではなく、軽量モデル・上位モデル・local処理等を選択するroutingは、受入品質を保ったまま費用/計算量を削減できるか。
2. managed router、learned router、rule/cascade router、gateway/load-balancerは何を同じものとして扱え、何を分離すべきか。
3. monetary cost、latency、energyは相関し得るが同一指標ではない。法人運用で「省エネ」をどう測定可能にするか。
4. cache/fallback/retry/model refreshによってroutingの品質・費用・energy効果が変動する場合、どの観測値を保持すべきか。

## EVIDENCE TABLE
### E1 — Primary research
- exact title: RouteLLM: Learning to Route LLMs with Preference Data
- author/org: Isaac Ong et al. / LMSYS collaboration
- canonical URL: https://arxiv.org/abs/2406.18665
- publication: 2024-06-26; accessed 2026-09-11
- version: arXiv 2406.18665
- locator: abstract / cost-quality routing result
- label: RESEARCH
- relation: support
- evidence: preference dataで強/弱LLM間を動的routingする枠組みを提示し、評価上は一部条件で品質を損なわず2倍超のcost reductionを報告。これはroutingがcost-quality frontierを改善し得る研究証拠だが、特定企業workloadの保証ではない。


### E2 — Primary research
- exact title: FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance
- author/org: Lingjiao Chen, Matei Zaharia, James Zou
- canonical URL: https://arxiv.org/abs/2305.05176
- publication: 2023-05-09; accessed 2026-09-11
- version: arXiv 2305.05176
- locator: abstract / LLM cascade experiments
- label: RESEARCH
- relation: support + limit
- evidence: prompt adaptation、LLM approximation、LLM cascadeを費用低減戦略として整理し、実験条件ではbest individual LLM相当性能を最大98%低costで達成した例を報告。ただし当時のmodel/API価格・benchmarkに依存し、2026年製品環境の節約率へ直接外挿しない。


### E3 — Official product documentation
- exact title: Understanding intelligent prompt routing in Amazon Bedrock
- author/org: Amazon Web Services
- canonical URL: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html
- accessed: 2026-09-11
- version/API: current Bedrock Intelligent Prompt Routing documentation; PRODUCT_VOLATILE
- locator: Benefits / Considerations and limitations / How intelligent prompt routing works
- label: VERIFIED_SPEC + PRODUCT_VOLATILE
- relation: support + counter + availability
- evidence: promptごとにresponse qualityを予測し、同一model family内の候補からquality/costを考慮してrouteするmanaged surfaceが実装されている。一方、current docsは英語prompt向け最適化、application-specific performance dataへrouting decisionを適応できないこと、specialized use caseでは最適にならない可能性を明記。configured routerは候補/criteria/fallbackを設定でき、responseに使用model情報を返す。


### E4 — Official product documentation
- exact title: Model router for Microsoft Foundry / How model router works
- author/org: Microsoft
- canonical URL: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router
- accessed: 2026-09-11
- version: model router version 2025-11-18 (current docs); routing pool/regions PRODUCT_VOLATILE
- locator: routing modes / model subset / prompt caching / limitations / billing
- label: VERIFIED_SPEC + PRODUCT_VOLATILE
- relation: support + availability + limit
- evidence: per-request model selectionを行い、Balanced/Cost/Quality modeとcustom model subsetを持つ。eligible modelはaccess、deployment type、data-zone等に制約される。effective context windowはcandidate pool内の制約を受け、model subsetで必要能力を絞る必要がある。selected modelはresponseのmodel fieldで観測可能。


### E5 — Official evaluation guidance
- exact title: Evaluate model router for your workload
- author/org: Microsoft
- canonical URL: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/evaluate-model-router
- publication/update: 2026-08-20 current page; accessed 2026-09-11
- label: VERIFIED_SPEC + PRODUCT_VOLATILE
- relation: support + limit
- evidence: router採用判断をquality/cost/latency/policyのworkload-specific acceptance criteriaで行い、単一aggregate scoreへ圧縮しないよう案内。production-like trafficでselected-model distribution、error/failover、actual usage cost、tail latency等を再評価し、traffic mix/model subset/pricing等が変わったら再評価することを要求している。


### E6 — Author-maintained OSS implementation
- exact title: RouteLLM — A framework for serving and evaluating LLM routers
- author/org: lm-sys
- canonical URL: https://github.com/lm-sys/RouteLLM
- accessed: 2026-09-11
- repository state: public Apache-2.0; main repo last-push history must be rechecked before publication
- label: OSS_PRACTICE + RESEARCH
- relation: implementation + limit
- evidence: OpenAI-compatible server/clientとしてrouterを実装し、複数routing strategyを比較できる。ただし研究repoのmaintenance cadenceと2026年managed productsの現行能力は別に扱う。


### E7 — Official benchmark methodology
- exact title: MLPerf Inference: Datacenter — Power Measurements / MLCommons Power
- author/org: MLCommons
- canonical URL: https://mlcommons.org/benchmarks/inference-datacenter/
- companion: https://mlcommons.org/working-groups/benchmarks/power/
- accessed: 2026-09-11
- label: VERIFIED_SPEC
- relation: support + measurement limit
- evidence: MLPerf Powerは性能計測中のsystem全体のAC power/energyをwall側で計測し、Server/Offlineではsystem power、stream系ではenergy-per-streamとして扱う。測定powerは伴うbenchmarkについてのみ有効で、TDP等の別指標を実測powerとして扱わない。したがってmodel priceやparameter countからenergyを推定して確定値にしない。


### E8 — Independent/open benchmarking initiative
- exact title: AI Energy Score v2: Refreshed Leaderboard, now with Reasoning / Methodology
- author/org: Sasha Luccioni, Boris Gamazaychikov et al. / AI Energy Score (Hugging Face-hosted initiative)
- canonical URLs: https://huggingface.co/blog/sasha/ai-energy-score-v2 ; https://github.com/huggingface/AIEnergyScore/blob/main/index.md
- publication: 2025-12-04 (v2 blog); accessed 2026-09-11
- label: RESEARCH + SOURCE_REPORT
- relation: support + context + limit
- evidence: task-specific energy benchmarkを構築し、reasoning modeやmodel/deploymentによりenergy useが大きく異なり得ることを報告。routingへenergy dataを併用する方向を提案している。ただしMLPerf等の標準規格と同格とは扱わず、hardware/software/task条件を固定した比較証拠として使用する。


### E9 — Official product documentation: caching interaction
- exact title: Prompt caching / Model router prompt caching behavior
- author/org: Microsoft; Amazon Web Services
- canonical URLs: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching ; https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
- accessed: 2026-09-11
- label: VERIFIED_SPEC + PRODUCT_VOLATILE
- relation: support + limit
- evidence: prompt cachingは長い反復prefixの再処理を減らしlatency/input costを下げ得るが、cache hitは条件依存で保証されない。Microsoft model routerではrouting先modelが変わるとcache benefitが得られにくく、同一modelが重複prefixを処理した場合に効く。よって「routing」と「cache」は独立最適化ではなく相互作用する。

## FINDINGS
1. **Routingはモデル選択ではなくcontrol planeである。** 法人向けには少なくとも `eligibility filter → cache/local shortcut → router decision → selected model/runtime → fallback/retry → result/trace → eval feedback` の連鎖で記述する方が実態に合う。
2. **強いモデル固定は常にPareto最適ではない。** RouteLLM/FrugalGPTは、workloadを難易度・confidence等で分け、弱/安価modelを使える問い合わせへ割り当てることでcost-quality frontierを改善し得ることを示す。
3. **managed routerと自作routerを分離する。** managed routerはmodel pool、region、deployment、tool/context capability等のavailability gateを持つ。自作/OSS routerは制御自由度が高いが、モデル能力metadata、pricing、health、fallback、security policy、driftを運用者が管理する必要がある。
4. **cost、latency、energyは別目的関数。** 安価なAPIが必ずしも低energyではなく、短いlatencyも低energyを保証しない。energy claimは、可能なら同一task/hardware/software条件の実測値を使う。
5. **cacheはrouting効果を変える。** prompt cacheは同一model/prefixの再利用に依存するため、per-turn routingでmodelが揺れるとhit benefitを失う場合がある。router評価にはmodel-selection distributionとcache-hit/writeを同時記録する。
6. **local処理もcandidate routeの一種として扱えるが、前提が異なる。** EA-009/010のself-host/edge manifestを参照し、data locality、offline、hardware capacity、quantization品質を通過したtaskだけをlocal route候補にする。cloud modelと単価だけで比較しない。
7. **router自身もdriftする。** candidate model、version、price、region、tool support、rate limit、traffic mixが変化すれば最適routingは変わる。固定導入ではなく再評価loopが必要。

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
- Router misclassification: 難しいtaskを弱modelへ送りaccepted qualityを落とす、または容易taskを上位modelへ送り節約を失う。
- Domain shift: router学習/benchmarkと実workloadが異なり、specialized categoryだけ劣化する。
- Capability mismatch: context window、structured output、tool calling、vision等の必要能力を満たさないmodelを選択する。
- Policy mismatch: region/data-zone/provider/model allowlistに違反する候補をpoolへ入れる。
- Cache fragmentation: selected modelの変動でprompt cache hitが落ち、想定したcost/latency削減が失われる。
- Retry/fallback amplification: 一度のrouting失敗が複数model attemptへ増幅し、tail cost/latency/energyを悪化させる。
- Price drift / model refresh: provider価格やrouting pool更新で過去の最適点が無効になる。
- Energy opacity: managed APIではrequest単位のphysical energyを公開しない場合が多く、token costからjouleを推測で確定しない。
- Benchmark transport risk: RouteLLM/FrugalGPT等の公開benchmark上の節約率を自組織taskへ保証値として転記しない。
- Rebound effect: 1件あたりを安くしても総呼出量が増えれば総費用/総energyが減らない。省エネはper-requestだけでなくperiod totalも見る。

## AVAILABILITY_GATES
- provider / region / deployment type / account entitlement
- candidate model availability and lifecycle
- model subset / same-family restriction where applicable
- context window / modality / tool / structured-output compatibility
- data residency / policy allowlist
- quota / rate limit / capacity
- local hardware/runtime/quantization availability
- prompt-cache support, prefix requirements, TTL, cache-write/read pricing
- routing mode and router version

## IMPLEMENTATION_STATE
- Learned two-model router: research + OSS implementation (RouteLLM).
- Cascade/router optimization: research evidence (FrugalGPT).
- Managed production routing surface: implemented in AWS Bedrock and Microsoft Foundry; exact pool/regions/version are PRODUCT_VOLATILE.
- Gateway/load-balancing router: maintained OSS ecosystems (e.g. LiteLLM) implement latency/cost/usage/fallback strategies;これらは「task能力を予測するrouter」と「deployment load balancer」を同一視しない。
- Energy-aware routing: measurement initiatives and research direction exist, but provider横断でrequest単位energyを同じ方法で取得できる共通production standardは今回確立できず UNKNOWNを残す。

## BENCHMARK_OR_EVAL
Router評価はfixed-model baselineと同一代表workloadで行い、少なくとも次を同時記録する。
- accepted task rate / critical-category failure rate
- selected-model distribution by workload category
- monetary cost per accepted task; p50/p95/p99
- latency p50/p90/p95/p99
- retry/fallback count and amplification
- cache hit/write tokens where available
- quota/rate-limit/error behavior
- local route rate where applicable
- measured energy per accepted task (J or Wh) only when測定境界・hardware・software・taskが固定される場合
- period total cost / total energy / total accepted tasks
単一の「省エネscore」へ圧縮せず、quality thresholdを先に置いてPareto frontierで比較する。

## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY
- Security/Privacy: router前にpolicy eligibility filterを置き、機密taskを未承認provider/modelへrouteしない。routing decision自体へprompt全文を不要に永続保存しない。
- Audit: request ID、router version/config、eligible pool、selected model/version、routing mode/score（取得可能範囲）、fallback attempts、cache usage、latency、cost、policy decisionを記録。hidden chain-of-thoughtは監査要件にしない。
- Cost: router overhead、underlying model charge、cache write/read、retry/fallback、gateway/runtimeを含めEA-017のCOST_PER_ACCEPTED_TASKへ統合。
- Operability: shadow/canaryで導入し、critical taskにはdirect fixed-model routeまたはhard floorを残す。model/provider更新時は同じfixtureでregressionを再実行する。
- Sustainability: monetary priceをenergy proxyとして確定しない。実測不可ならenergyはUNKNOWN/UNMEASUREDとし、compute tier/model size等は補助説明に留める。

## SAFE_WORDING_FOR_FUTURE_BOOK
「モデルルーティングは、すべての要求を最上位モデルへ送る代わりに、要求ごとの必要能力や組織ポリシーに応じて候補を選び、品質条件を満たす範囲で費用・遅延・計算資源を最適化する制御層として利用できる。ただし、公開benchmarkやベンダー公称の節約率は自組織workloadの保証値ではない。候補model、価格、tool/context対応、region、cache、fallbackが変われば効果も変わるため、固定baselineに対する継続評価が必要である。金銭コストの低下をそのまま省エネとみなさず、energyを主張する場合は測定境界を明示した実測値を用いる。」

## UPDATE_WORK_HANDOFF
将来Workでは次を優先する。
1. `ROUTING_POLICY_RECORD`を作成: policy_id / router product+version / allowed models+versions / region / routing mode / quality floor / direct-route exceptions / fallback chain / cache policy / local-route eligibility / cost budget / energy metric availability / owner / review date。
2. EA-016のEVAL_CASE_RECORDとEA-017のWORKLOAD_COST_PROFILEを結合し、router導入前後を同じfixtureで比較する。
3. Azure Foundry Model Router、Amazon Bedrock Intelligent Prompt Routing、custom RouteLLM/LiteLLM系を同じcomparison matrixへ置く。ただしmanaged ML routerとload-balancer/gatewayを別classにする。
4. 公開直前にcandidate pool、region、router version、pricing、tool/context support、cache仕様を再採集する。
5. energy比較が必要な章ではMLPerf Power/AI Energy Scoreのmethodologyを参照し、cloud proprietary APIについてrequest-level jouleが公開されない場合は推測で埋めない。


### TEST_PROFILE-018-A — Quality-floor routing regression（未実施）
同一代表fixtureを fixed-frontier / fixed-small / router で実行。accepted qualityをhard constraintとし、cost、latency、selected-model distributionを比較。critical categoryでquality floorを下回ればrouting policyをreject。


### TEST_PROFILE-018-B — Router drift / model refresh（未実施）
router version、candidate models、pricing snapshotを固定してbaselineを保存。providerがmodel pool/versionを更新した後に同fixtureを再走し、model distribution、quality、cost、tail latency差を検出。


### TEST_PROFILE-018-C — Cache × routing interaction（未実施）
長い共通prefixを持つ反復requestを用意し、fixed-modelとper-request routerでcache hit/write、cost、latencyを比較。model選択変動によるcache fragmentationを確認。


### TEST_PROFILE-018-D — Fallback amplification（未実施）
安全なmock/fault injectionで候補model timeout/rate-limitを発生させ、ordered attempts、retry/fallback回数、duplicate side effect有無、p95/p99 latency、cost amplificationを測る。外部書込みtoolは使わない。


### TEST_PROFILE-018-E — Local/cloud route（未実施）
EA-009/010の承認済みlocal runtimeとcloud候補を、公開/非機密fixtureで比較。quality、latency、local device energy（測定可能時）、cloud monetary cost、network dependencyを記録。機密dataは投入しない。


### TEST_PROFILE-018-F — Energy-aware comparison（未実施）
自己管理hardwareでのみ、同一task、同一output length policy、同一hardware/software measurement boundaryを固定し、候補modelごとのJ/accepted-taskまたはWh/accepted-taskを測る。wall-powerまたは検証済みmeterを優先し、TDPを実測値へ代用しない。

## OPEN_UNKNOWN
- provider横断でcomparableなrequest-level energy telemetryを法人ユーザーが取得できる標準surfaceは今回確立できない。
- managed router内部のquality predictor/training data/scoreの完全な透明性はproviderごとに異なり、公開仕様以上はUNKNOWN。
- router導入による実組織TCO・total-energy削減率はworkload mix、traffic volume、fallback、cache、pricingに依存し、外部研究値で閉じない。
- local/cloud hybrid routingにおけるdata residency・security approvalはorganization-specific。

## STOP_CONDITION
- routingを一つの万能optimizerとせず、quality/cost/latency/policy/energyを分離した評価設計を確立した。
- learned/cascade/managed/gateway routerの実装状態と境界を一次資料・原著研究・OSSで裏付けた。
- monetary costとenergyを分離し、実測可能時のenergy評価方法と未測定時のUNKNOWN規則を定めた。
- cache、fallback、model refresh、policy、local routeを将来Workが実測できるTEST_PROFILEへ落とした。


BOUNDED_CLOSE: EA-018

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.