{
  "format": "agent-article-v0",
  "article_id": "EA-018",
  "canonical_url": "/tools/ea-018-ai",
  "page_type": "reference",
  "claim_ids": [],
  "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"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "UNKNOWN",
  "observation_status": "SPEC_ONLY",
  "freshness": "UNKNOWN",
  "last_verified": null,
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "COMM-019-EA0018",
    "SRC-EA-018-URL-4E19329870F7",
    "SRC-EA-018-URL-9C1F04FED0A9",
    "SRC-EA-018-URL-DB03BFD6A12C",
    "SRC-EA-018-URL-57A8873132AC",
    "SRC-EA-018-URL-4B938E611C70",
    "SRC-EA-018-URL-F54F84DBCFE8",
    "SRC-EA-018-URL-E02276C332D2",
    "SRC-EA-018-URL-0D7CEA708C0D",
    "SRC-EA-018-URL-3969EE1849B9",
    "SRC-EA-018-URL-24977847E7E6",
    "SRC-EA-018-URL-452B01DE327B",
    "SRC-EA-018-URL-51DBA37EBCDA",
    "WEBBODY-EA0018-R8-F751E796"
  ],
  "article_sources": [
    {
      "id": "EVD-EA-018-URL-4E19329870F7",
      "evidence_class": "RESEARCH",
      "title": "- author/org: Isaac Ong et al. / LMSYS collaboration",
      "href": "https://arxiv.org/abs/2406.18665",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-4E19329870F7"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URL: https://arxiv.org/abs/2406.18665"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-9C1F04FED0A9",
      "evidence_class": "RESEARCH",
      "title": "- author/org: Lingjiao Chen, Matei Zaharia, James Zou",
      "href": "https://arxiv.org/abs/2305.05176",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-9C1F04FED0A9"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URL: https://arxiv.org/abs/2305.05176"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-DB03BFD6A12C",
      "evidence_class": "RESEARCH",
      "title": "- author/org: Amazon Web Services",
      "href": "https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-DB03BFD6A12C"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URL: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-57A8873132AC",
      "evidence_class": "RESEARCH",
      "title": "- author/org: Microsoft",
      "href": "https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-57A8873132AC"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URL: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-4B938E611C70",
      "evidence_class": "RESEARCH",
      "title": "- author/org: Microsoft",
      "href": "https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/evaluate-model-router",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-4B938E611C70"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URL: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/evaluate-model-router"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-F54F84DBCFE8",
      "evidence_class": "RESEARCH",
      "title": "- author/org: lm-sys",
      "href": "https://github.com/lm-sys/RouteLLM",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-F54F84DBCFE8"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URL: https://github.com/lm-sys/RouteLLM"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-E02276C332D2",
      "evidence_class": "RESEARCH",
      "title": "- author/org: MLCommons",
      "href": "https://mlcommons.org/benchmarks/inference-datacenter/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-E02276C332D2"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URL: https://mlcommons.org/benchmarks/inference-datacenter/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-0D7CEA708C0D",
      "evidence_class": "RESEARCH",
      "title": "companion:",
      "href": "https://mlcommons.org/working-groups/benchmarks/power/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-0D7CEA708C0D"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- companion: https://mlcommons.org/working-groups/benchmarks/power/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-3969EE1849B9",
      "evidence_class": "RESEARCH",
      "title": "canonical URLs:",
      "href": "https://huggingface.co/blog/sasha/ai-energy-score-v2",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-3969EE1849B9"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URLs: https://huggingface.co/blog/sasha/ai-energy-score-v2"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-24977847E7E6",
      "evidence_class": "RESEARCH",
      "title": "canonical URLs: https://huggingface.co/blog/sasha/ai-energy-score-v2 ;",
      "href": "https://github.com/huggingface/AIEnergyScore/blob/main/index.md",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-24977847E7E6"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URLs: https://huggingface.co/blog/sasha/ai-energy-score-v2 ; https://github.com/huggingface/AIEnergyScore/blob/main/index.md"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-452B01DE327B",
      "evidence_class": "RESEARCH",
      "title": "canonical URLs:",
      "href": "https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-452B01DE327B"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- canonical URLs: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-018-URL-51DBA37EBCDA",
      "evidence_class": "RESEARCH",
      "title": "canonical URLs: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching ;",
      "href": "https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-018-URL-51DBA37EBCDA"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- 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"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EA-018-R11-RESEARCH",
      "evidence_class": "RESEARCH",
      "title": "EA-018 監査済みresearch / canonical revision binding",
      "supports": [
        "1. **Routingはモデル選択ではなくcontrol planeである。** 法人向けには少なくとも `eligibility filter → cache/local shortcut → router decision → selected model/runtime → fallback/retry → result/trace → eval feedback` の連鎖で記述する方が実態に合う。\n2. **強いモデル固定は常にPareto最適ではない。** RouteLLM/FrugalGPTは、workloadを難易度・confidence等で分け、弱/安価modelを使える問い合わせへ割り当てることでcost-quality frontierを改善し得ることを示す。\n3. **managed routerと自作routerを分離する。** managed routerはmodel pool、region、deployment、tool/context capability等のavailability gateを持つ。自作/OSS routerは制御自由度が高いが、モデル能力metadata、pricing、health、fallback、security policy、driftを運用者が管理する必要がある。\n4. **cost、latency、energyは別目的関数。** 安価なAPIが必ずしも低energyではなく、短いlatencyも低energyを保証しない。energy claimは、可能なら同一task/hardware/software条件の実測値を使う。\n5. **cacheはrouting効果を変える。** prompt cacheは同一model/prefixの再利用に依存するため、per-turn routingでmodelが揺れるとhit benefitを失う場合がある。router評価にはmodel-selection distributionとcache-hit/writeを同時記録する。\n6. **local処理もcandidate routeの一種として扱えるが、前提が異なる。** EA-009/010のself-host/edge manifestを参照し、data locality、offline、hardware capacity、quantization品質を通過したtaskだけをlocal route候補にする。cloud modelと単価だけで比較しない。\n7. **router自身もdriftする。** candidate model、version、price、region、tool support、rate limit、traffic mixが変化すれば最適routingは変わる。固定導入ではなく再評価loopが必要。"
      ],
      "limit": "canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "COMM-019-EA0018"
      ],
      "supporting_locators": [
        "COMM-019-EA0018",
        "EA-018-R5-LEGACY-MIGRATION-20261008-R1",
        "content/staging/EA-018.md"
      ],
      "scope": "監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。",
      "provenance_status": "AUDIT_PASS_CANONICAL_BINDING"
    },
    {
      "id": "EA-018-R11-WEB-READBACK",
      "evidence_class": "IMPL",
      "title": "EA-018 Web body identity / canonical readback",
      "supports": [
        "canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。"
      ],
      "limit": "body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。",
      "checked_at": null,
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "WEBBODY-EA0018-R8-F751E796"
      ],
      "supporting_locators": [
        "WEBBODY-EA0018-R8-F751E796",
        "content/staging/EA-018.md",
        "EA-018-R5-LEGACY-MIGRATION-20261008-R1"
      ],
      "scope": "R9/R10 canonical readback後のProduction生成時body identity。",
      "provenance_status": "CANONICAL_READBACK_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "WHY_THIS_MATTERS_TO_UPDATE",
      "text": "原案台帳は、分類・軽量モデル・上位推論・ローカル処理・キャッシュ等を組み合わせた費用最適化をEA-018の対象とする。公開後アップデートでは「最安モデルへ送る」だけではなく、品質・金銭コスト・遅延・可用性・policy・計算/電力効率を同時に扱うrouting/control planeとして整理する必要がある。特に、モデル単価の低下を省エネと同一視せず、model selection、cache、local/offline処理、fallback/retry、energy measurementを別々の制御面として扱う。"
    },
    {
      "heading": "SCOPE_ROUTING",
      "text": "Enterprise AI Core / provider mapping / interoperability / implementation / benchmark / cost engineering / sustainability / non-LLM control plane"
    },
    {
      "heading": "CLAIM_OR_RESEARCH_QUESTION",
      "text": "1. workloadごとに強いモデル固定ではなく、軽量モデル・上位モデル・local処理等を選択するroutingは、受入品質を保ったまま費用/計算量を削減できるか。\n2. managed router、learned router、rule/cascade router、gateway/load-balancerは何を同じものとして扱え、何を分離すべきか。\n3. monetary cost、latency、energyは相関し得るが同一指標ではない。法人運用で「省エネ」をどう測定可能にするか。\n4. cache/fallback/retry/model refreshによってroutingの品質・費用・energy効果が変動する場合、どの観測値を保持すべきか。"
    },
    {
      "heading": "EVIDENCE TABLE",
      "text": "### E1 — Primary research\n- exact title: RouteLLM: Learning to Route LLMs with Preference Data\n- author/org: Isaac Ong et al. / LMSYS collaboration\n- canonical URL: https://arxiv.org/abs/2406.18665\n- publication: 2024-06-26; accessed 2026-09-11\n- version: arXiv 2406.18665\n- locator: abstract / cost-quality routing result\n- label: RESEARCH\n- relation: support\n- evidence: preference dataで強/弱LLM間を動的routingする枠組みを提示し、評価上は一部条件で品質を損なわず2倍超のcost reductionを報告。これはroutingがcost-quality frontierを改善し得る研究証拠だが、特定企業workloadの保証ではない。\n\n\n### E2 — Primary research\n- exact title: FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance\n- author/org: Lingjiao Chen, Matei Zaharia, James Zou\n- canonical URL: https://arxiv.org/abs/2305.05176\n- publication: 2023-05-09; accessed 2026-09-11\n- version: arXiv 2305.05176\n- locator: abstract / LLM cascade experiments\n- label: RESEARCH\n- relation: support + limit\n- evidence: prompt adaptation、LLM approximation、LLM cascadeを費用低減戦略として整理し、実験条件ではbest individual LLM相当性能を最大98%低costで達成した例を報告。ただし当時のmodel/API価格・benchmarkに依存し、2026年製品環境の節約率へ直接外挿しない。\n\n\n### E3 — Official product documentation\n- exact title: Understanding intelligent prompt routing in Amazon Bedrock\n- author/org: Amazon Web Services\n- canonical URL: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html\n- accessed: 2026-09-11\n- version/API: current Bedrock Intelligent Prompt Routing documentation; PRODUCT_VOLATILE\n- locator: Benefits / Considerations and limitations / How intelligent prompt routing works\n- label: VERIFIED_SPEC + PRODUCT_VOLATILE\n- relation: support + counter + availability\n- 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情報を返す。\n\n\n### E4 — Official product documentation\n- exact title: Model router for Microsoft Foundry / How model router works\n- author/org: Microsoft\n- canonical URL: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router\n- accessed: 2026-09-11\n- version: model router version 2025-11-18 (current docs); routing pool/regions PRODUCT_VOLATILE\n- locator: routing modes / model subset / prompt caching / limitations / billing\n- label: VERIFIED_SPEC + PRODUCT_VOLATILE\n- relation: support + availability + limit\n- 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で観測可能。\n\n\n### E5 — Official evaluation guidance\n- exact title: Evaluate model router for your workload\n- author/org: Microsoft\n- canonical URL: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/evaluate-model-router\n- publication/update: 2026-08-20 current page; accessed 2026-09-11\n- label: VERIFIED_SPEC + PRODUCT_VOLATILE\n- relation: support + limit\n- 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等が変わったら再評価することを要求している。\n\n\n### E6 — Author-maintained OSS implementation\n- exact title: RouteLLM — A framework for serving and evaluating LLM routers\n- author/org: lm-sys\n- canonical URL: https://github.com/lm-sys/RouteLLM\n- accessed: 2026-09-11\n- repository state: public Apache-2.0; main repo last-push history must be rechecked before publication\n- label: OSS_PRACTICE + RESEARCH\n- relation: implementation + limit\n- evidence: OpenAI-compatible server/clientとしてrouterを実装し、複数routing strategyを比較できる。ただし研究repoのmaintenance cadenceと2026年managed productsの現行能力は別に扱う。\n\n\n### E7 — Official benchmark methodology\n- exact title: MLPerf Inference: Datacenter — Power Measurements / MLCommons Power\n- author/org: MLCommons\n- canonical URL: https://mlcommons.org/benchmarks/inference-datacenter/\n- companion: https://mlcommons.org/working-groups/benchmarks/power/\n- accessed: 2026-09-11\n- label: VERIFIED_SPEC\n- relation: support + measurement limit\n- 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を推定して確定値にしない。\n\n\n### E8 — Independent/open benchmarking initiative\n- exact title: AI Energy Score v2: Refreshed Leaderboard, now with Reasoning / Methodology\n- author/org: Sasha Luccioni, Boris Gamazaychikov et al. / AI Energy Score (Hugging Face-hosted initiative)\n- canonical URLs: https://huggingface.co/blog/sasha/ai-energy-score-v2 ; https://github.com/huggingface/AIEnergyScore/blob/main/index.md\n- publication: 2025-12-04 (v2 blog); accessed 2026-09-11\n- label: RESEARCH + SOURCE_REPORT\n- relation: support + context + limit\n- evidence: task-specific energy benchmarkを構築し、reasoning modeやmodel/deploymentによりenergy useが大きく異なり得ることを報告。routingへenergy dataを併用する方向を提案している。ただしMLPerf等の標準規格と同格とは扱わず、hardware/software/task条件を固定した比較証拠として使用する。\n\n\n### E9 — Official product documentation: caching interaction\n- exact title: Prompt caching / Model router prompt caching behavior\n- author/org: Microsoft; Amazon Web Services\n- 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\n- accessed: 2026-09-11\n- label: VERIFIED_SPEC + PRODUCT_VOLATILE\n- relation: support + limit\n- evidence: prompt cachingは長い反復prefixの再処理を減らしlatency/input costを下げ得るが、cache hitは条件依存で保証されない。Microsoft model routerではrouting先modelが変わるとcache benefitが得られにくく、同一modelが重複prefixを処理した場合に効く。よって「routing」と「cache」は独立最適化ではなく相互作用する。"
    },
    {
      "heading": "FINDINGS",
      "text": "1. **Routingはモデル選択ではなくcontrol planeである。** 法人向けには少なくとも `eligibility filter → cache/local shortcut → router decision → selected model/runtime → fallback/retry → result/trace → eval feedback` の連鎖で記述する方が実態に合う。\n2. **強いモデル固定は常にPareto最適ではない。** RouteLLM/FrugalGPTは、workloadを難易度・confidence等で分け、弱/安価modelを使える問い合わせへ割り当てることでcost-quality frontierを改善し得ることを示す。\n3. **managed routerと自作routerを分離する。** managed routerはmodel pool、region、deployment、tool/context capability等のavailability gateを持つ。自作/OSS routerは制御自由度が高いが、モデル能力metadata、pricing、health、fallback、security policy、driftを運用者が管理する必要がある。\n4. **cost、latency、energyは別目的関数。** 安価なAPIが必ずしも低energyではなく、短いlatencyも低energyを保証しない。energy claimは、可能なら同一task/hardware/software条件の実測値を使う。\n5. **cacheはrouting効果を変える。** prompt cacheは同一model/prefixの再利用に依存するため、per-turn routingでmodelが揺れるとhit benefitを失う場合がある。router評価にはmodel-selection distributionとcache-hit/writeを同時記録する。\n6. **local処理もcandidate routeの一種として扱えるが、前提が異なる。** EA-009/010のself-host/edge manifestを参照し、data locality、offline、hardware capacity、quantization品質を通過したtaskだけをlocal route候補にする。cloud modelと単価だけで比較しない。\n7. **router自身もdriftする。** candidate model、version、price、region、tool support、rate limit、traffic mixが変化すれば最適routingは変わる。固定導入ではなく再評価loopが必要。"
    },
    {
      "heading": "LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE",
      "text": "- Router misclassification: 難しいtaskを弱modelへ送りaccepted qualityを落とす、または容易taskを上位modelへ送り節約を失う。\n- Domain shift: router学習/benchmarkと実workloadが異なり、specialized categoryだけ劣化する。\n- Capability mismatch: context window、structured output、tool calling、vision等の必要能力を満たさないmodelを選択する。\n- Policy mismatch: region/data-zone/provider/model allowlistに違反する候補をpoolへ入れる。\n- Cache fragmentation: selected modelの変動でprompt cache hitが落ち、想定したcost/latency削減が失われる。\n- Retry/fallback amplification: 一度のrouting失敗が複数model attemptへ増幅し、tail cost/latency/energyを悪化させる。\n- Price drift / model refresh: provider価格やrouting pool更新で過去の最適点が無効になる。\n- Energy opacity: managed APIではrequest単位のphysical energyを公開しない場合が多く、token costからjouleを推測で確定しない。\n- Benchmark transport risk: RouteLLM/FrugalGPT等の公開benchmark上の節約率を自組織taskへ保証値として転記しない。\n- Rebound effect: 1件あたりを安くしても総呼出量が増えれば総費用/総energyが減らない。省エネはper-requestだけでなくperiod totalも見る。"
    },
    {
      "heading": "AVAILABILITY_GATES",
      "text": "- provider / region / deployment type / account entitlement\n- candidate model availability and lifecycle\n- model subset / same-family restriction where applicable\n- context window / modality / tool / structured-output compatibility\n- data residency / policy allowlist\n- quota / rate limit / capacity\n- local hardware/runtime/quantization availability\n- prompt-cache support, prefix requirements, TTL, cache-write/read pricing\n- routing mode and router version"
    },
    {
      "heading": "IMPLEMENTATION_STATE",
      "text": "- Learned two-model router: research + OSS implementation (RouteLLM).\n- Cascade/router optimization: research evidence (FrugalGPT).\n- Managed production routing surface: implemented in AWS Bedrock and Microsoft Foundry; exact pool/regions/version are PRODUCT_VOLATILE.\n- Gateway/load-balancing router: maintained OSS ecosystems (e.g. LiteLLM) implement latency/cost/usage/fallback strategies;これらは「task能力を予測するrouter」と「deployment load balancer」を同一視しない。\n- Energy-aware routing: measurement initiatives and research direction exist, but provider横断でrequest単位energyを同じ方法で取得できる共通production standardは今回確立できず UNKNOWNを残す。"
    },
    {
      "heading": "BENCHMARK_OR_EVAL",
      "text": "Router評価はfixed-model baselineと同一代表workloadで行い、少なくとも次を同時記録する。\n- accepted task rate / critical-category failure rate\n- selected-model distribution by workload category\n- monetary cost per accepted task; p50/p95/p99\n- latency p50/p90/p95/p99\n- retry/fallback count and amplification\n- cache hit/write tokens where available\n- quota/rate-limit/error behavior\n- local route rate where applicable\n- measured energy per accepted task (J or Wh) only when測定境界・hardware・software・taskが固定される場合\n- period total cost / total energy / total accepted tasks\n単一の「省エネscore」へ圧縮せず、quality thresholdを先に置いてPareto frontierで比較する。"
    },
    {
      "heading": "SECURITY / PRIVACY / AUDIT / COST / OPERABILITY",
      "text": "- Security/Privacy: router前にpolicy eligibility filterを置き、機密taskを未承認provider/modelへrouteしない。routing decision自体へprompt全文を不要に永続保存しない。\n- 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は監査要件にしない。\n- Cost: router overhead、underlying model charge、cache write/read、retry/fallback、gateway/runtimeを含めEA-017のCOST_PER_ACCEPTED_TASKへ統合。\n- Operability: shadow/canaryで導入し、critical taskにはdirect fixed-model routeまたはhard floorを残す。model/provider更新時は同じfixtureでregressionを再実行する。\n- Sustainability: monetary priceをenergy proxyとして確定しない。実測不可ならenergyはUNKNOWN/UNMEASUREDとし、compute tier/model size等は補助説明に留める。"
    },
    {
      "heading": "SAFE_WORDING_FOR_FUTURE_BOOK",
      "text": "「モデルルーティングは、すべての要求を最上位モデルへ送る代わりに、要求ごとの必要能力や組織ポリシーに応じて候補を選び、品質条件を満たす範囲で費用・遅延・計算資源を最適化する制御層として利用できる。ただし、公開benchmarkやベンダー公称の節約率は自組織workloadの保証値ではない。候補model、価格、tool/context対応、region、cache、fallbackが変われば効果も変わるため、固定baselineに対する継続評価が必要である。金銭コストの低下をそのまま省エネとみなさず、energyを主張する場合は測定境界を明示した実測値を用いる。」"
    },
    {
      "heading": "UPDATE_WORK_HANDOFF",
      "text": "将来Workでは次を優先する。\n1. `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。\n2. EA-016のEVAL_CASE_RECORDとEA-017のWORKLOAD_COST_PROFILEを結合し、router導入前後を同じfixtureで比較する。\n3. Azure Foundry Model Router、Amazon Bedrock Intelligent Prompt Routing、custom RouteLLM/LiteLLM系を同じcomparison matrixへ置く。ただしmanaged ML routerとload-balancer/gatewayを別classにする。\n4. 公開直前にcandidate pool、region、router version、pricing、tool/context support、cache仕様を再採集する。\n5. energy比較が必要な章ではMLPerf Power/AI Energy Scoreのmethodologyを参照し、cloud proprietary APIについてrequest-level jouleが公開されない場合は推測で埋めない。\n\n\n### TEST_PROFILE-018-A — Quality-floor routing regression（未実施）\n同一代表fixtureを fixed-frontier / fixed-small / router で実行。accepted qualityをhard constraintとし、cost、latency、selected-model distributionを比較。critical categoryでquality floorを下回ればrouting policyをreject。\n\n\n### TEST_PROFILE-018-B — Router drift / model refresh（未実施）\nrouter version、candidate models、pricing snapshotを固定してbaselineを保存。providerがmodel pool/versionを更新した後に同fixtureを再走し、model distribution、quality、cost、tail latency差を検出。\n\n\n### TEST_PROFILE-018-C — Cache × routing interaction（未実施）\n長い共通prefixを持つ反復requestを用意し、fixed-modelとper-request routerでcache hit/write、cost、latencyを比較。model選択変動によるcache fragmentationを確認。\n\n\n### TEST_PROFILE-018-D — Fallback amplification（未実施）\n安全なmock/fault injectionで候補model timeout/rate-limitを発生させ、ordered attempts、retry/fallback回数、duplicate side effect有無、p95/p99 latency、cost amplificationを測る。外部書込みtoolは使わない。\n\n\n### TEST_PROFILE-018-E — Local/cloud route（未実施）\nEA-009/010の承認済みlocal runtimeとcloud候補を、公開/非機密fixtureで比較。quality、latency、local device energy（測定可能時）、cloud monetary cost、network dependencyを記録。機密dataは投入しない。\n\n\n### TEST_PROFILE-018-F — Energy-aware comparison（未実施）\n自己管理hardwareでのみ、同一task、同一output length policy、同一hardware/software measurement boundaryを固定し、候補modelごとのJ/accepted-taskまたはWh/accepted-taskを測る。wall-powerまたは検証済みmeterを優先し、TDPを実測値へ代用しない。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- provider横断でcomparableなrequest-level energy telemetryを法人ユーザーが取得できる標準surfaceは今回確立できない。\n- managed router内部のquality predictor/training data/scoreの完全な透明性はproviderごとに異なり、公開仕様以上はUNKNOWN。\n- router導入による実組織TCO・total-energy削減率はworkload mix、traffic volume、fallback、cache、pricingに依存し、外部研究値で閉じない。\n- local/cloud hybrid routingにおけるdata residency・security approvalはorganization-specific。"
    },
    {
      "heading": "STOP_CONDITION",
      "text": "- routingを一つの万能optimizerとせず、quality/cost/latency/policy/energyを分離した評価設計を確立した。\n- learned/cascade/managed/gateway routerの実装状態と境界を一次資料・原著研究・OSSで裏付けた。\n- monetary costとenergyを分離し、実測可能時のenergy評価方法と未測定時のUNKNOWN規則を定めた。\n- cache、fallback、model refresh、policy、local routeを将来Workが実測できるTEST_PROFILEへ落とした。\n\n\nBOUNDED_CLOSE: EA-018"
    }
  ],
  "human_url": "/tools/ea-018-ai",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-018-ai",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-018-ai"
}