AI依存関係互換性マトリクス

Enterprise AIの実行結果は単一アプリversionでは決まらない。provider model lifecycle、API revision、SDK、agent framework、MCP protocol/capabilities、tool schema、prompt、embedding/index、policy/eval等が独立に更新される。requestがHTTP上成功しても意味論・品質が壊れる場合があり、逆にmodel retirementやprotocol breakはhard failureを起こす。公開後アップデートでは「latest同士なら互換」という暗黙仮定を捨て、実際に検証済みの組合せをCompatibility Matrixとして管理する必要がある。

Enterprise AI Core: dependency lifecycle / change management / configuration provenance Provider mapping: model/API lifecycle Interoperability: MCP protocol revision/capability negotiation Implementation: SDK/framework/spec conformance Governance: supported tuple / upgrade gate / deprecation response Benchmark/Eval: contract test + behavioral regression evaluation

• AI stackの互換性を単一semverや「最新version」で管理できるか。
• Protocol/APIが接続できるsyntactic compatibilityと、AI taskの意味・品質が維持されるsemantic compatibilityを分離すべきか。
• matrixには何のrevision/capabilityを含めるべきか。
• provider retirement、protocol revision、SDK conformance lagを変更前にどう検知するか。

E1 | class: provider official lifecycle documentation | title: Model deprecations | author/org: Anthropic | canonical URL: https://docs.anthropic.com/en/docs/about-claude/model-deprecations | accessed: 2026-09-14 | lifecycle: Active / Legacy / Deprecated / Retired | locator: Overview | label: PRODUCT_VOLATILE / SOURCE_REPORT | relation: support | Evidence: retired model requests fail; deprecated models receive replacement and retirement date. Model availability is an independently moving runtime dependency. E2 | class: interoperability specification | title: Lifecycle — MCP specification 2025-11-25 | author/org: Model Context Protocol | canonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle | protocol revision: 2025-11-25 | accessed: 2026-09-14 | locator: initialization/version negotiation | label: VERIFIED_SPEC | relation: support/context | Evidence: handshake-era MCP negotiates protocol version and capabilities; unsupported negotiated version can prevent connection. E3 | class: official SDK documentation | title: Protocol Versions | author/org: MCP Ruby SDK | canonical URL: https://ruby.sdk.modelcontextprotocol.io/protocol-versions/ | accessed: 2026-09-14 | SDK docs: mcp 1.5.1 | protocol revisions: 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, 2026-07-28 | locator: version/era table | label: OSS_PRACTICE / VERIFIED_SPEC-context | relation: support/limit | Evidence: 2026-07-28 is a Modern stateless era with no handshake, whereas older revisions use session handshake; protocol revision changes lifecycle semantics materially. E4 | class: official SDK documentation | title: LifeCycle | author/org: MCP Go SDK | canonical URL: https://go.sdk.modelcontextprotocol.io/protocol/ | accessed: 2026-09-14 | protocol modern revision: 2026-07-28 | locator: two lifecycle models | label: OSS_PRACTICE | relation: support | Evidence: SDK supports legacy initialize handshake through 2025-11-25 and stateless 2026-07-28 with version/capabilities carried per request. E5 | class: project release note | title: The 2026-07-28 MCP Specification Release Candidate | author/org: Model Context Protocol | canonical URL: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/ | publication context: final targeted/published 2026-07-28; accessed 2026-09-14 | revision: 2026-07-28 | locator: breaking changes; release timeline | label: SOURCE_REPORT / VERIFIED_SPEC-context | relation: support/counter | Evidence: revision contains breaking changes, including foundational stateless rework and other semantic changes; explicitly demonstrates that compatibility cannot be inferred from package name alone. E6 | class: author-maintained SDK release | title: The Official Ruby SDK for MCP Reaches 1.0 | author/org: Model Context Protocol / Ruby SDK maintainer Koichi Ito | canonical URL: https://blog.modelcontextprotocol.io/posts/ruby-sdk-1-0/ | publication: 2026-07-27 | release: mcp gem v1.0.0 | locator: release announcement | label: OSS_PRACTICE / SOURCE_REPORT | relation: context | Evidence: SDK public API reached stable 1.0 and Tier 2 conformance, showing SDK lifecycle/conformance is a distinct dimension from protocol revision. E7 | class: standard/project release update | title: OpenFeature Mid-2026 Update: Platform-Native Feature Flags, a New TC Member, and Spec v0.9.0 | author/org: OpenFeature | canonical URL: https://openfeature.dev/blog/openfeature-mid-2026-update/ | publication: 2026-08-12 | spec: v0.9.0 | locator: Specification v0.9.0 | label: SOURCE_REPORT / OSS_PRACTICE | relation: support/limit | Evidence: specification moved from v0.8.0 to v0.9.0 with consequential stabilization/change; ecosystem SDK/provider conformance must be checked rather than assumed from the spec number. E8 | class: provider official configuration documentation | title: Deploy a prompt to your application using versions in Prompt management | author/org: AWS | canonical URL: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-management-deploy.html | accessed: 2026-09-14 | service current docs | locator: version as point-in-time snapshot | label: PRODUCT_VOLATILE / SOURCE_REPORT | relation: context | Evidence: prompt configuration has its own version lifecycle independent of application/model SDK versions.

F1 [SOURCE_REPORT / INFERENCE]: AI dependency compatibility is multidimensional. At minimum the matrix should be able to identify: application/build revision; provider + immutable model ID/revision/lifecycle; provider API revision/beta contract; client SDK/library version; agent framework version; MCP protocol revision/era + negotiated capabilities; tool schema revision; prompt/instruction revision; response schema; embedding model; retrieval/index/vector schema or snapshot; policy/guardrail revision; evaluator version. F2 [VERIFIED_SPEC]: MCP proves why protocol revision and capabilities must be recorded separately from SDK version. 2025-11-25 and earlier use handshake/session negotiation, while 2026-07-28 introduces a stateless lifecycle with version/capabilities per request. A nominally “MCP-compatible” client/server pair can therefore differ materially in lifecycle and feature semantics. F3 [PRODUCT_VOLATILE]: Provider model lifecycle is a hard compatibility axis. Anthropic explicitly defines Retired models as unavailable and requests fail. A previously valid tuple can stop functioning without an application code change. F4 [INFERENCE]: Compatibility has at least two layers. Syntactic/contract compatibility asks whether authentication, protocol negotiation, API/schema/tool invocation succeeds. Semantic compatibility asks whether the same task still achieves acceptable quality, policy compliance, tool behavior and cost/latency. Passing the first does not prove the second. F5 [OSS_PRACTICE / INFERENCE]: Standard revision and SDK conformance/version are distinct. MCP SDK tier/conformance and OpenFeature spec/SDK evolution illustrate that “spec latest” and “SDK latest” are not a guaranteed tested pair. F6 [PROPOSAL]: Do not build a full Cartesian product. Maintain known-good, tested tuples for deployed paths, planned upgrades, supported rollback paths and security-critical fallbacks. This converts the matrix from documentation inventory into an actionable change gate. F7 [PROPOSAL]: Every dependency update should run two suites: (A) contract tests — auth, endpoint/API revision, protocol/capabilities, structured output, tool schema, limits; (B) behavioral regression eval — representative tasks, policy, retrieval/tool outcomes, stochastic repeatability, latency/cost. Record exact tuple and eval revision with the result.

• Semantic Versioning at one component does not guarantee end-to-end semantic compatibility across providers and AI outputs.
• Successful MCP handshake/modern request validation establishes protocol compatibility for negotiated capabilities, not task-quality equivalence.
• Provider docs can describe lifecycle policy but do not prove a specific tenant/region supports a replacement model/API at the required date.
• Model aliases may be convenient but can hide underlying revision movement; compatibility evidence should prefer immutable/resolved model IDs where supported. This is INFERENCE and must be provider-mapped before asserting alias behavior.
• Prompt/model/tool/retrieval changes can interact. Testing each component independently can miss combination failures.
• Matrix staleness is itself a failure mode: an untested tuple should not inherit “supported” status merely because all components are individually supported.

• Provider model availability depends on provider lifecycle, region, account/plan and endpoint/API path.
• MCP feature availability depends on protocol revision/era and capability set, not only “MCP support.”
• SDK implementation/conformance may lag or differ from the latest specification revision.
• Tool/provider beta headers and API revisions must be captured where relevant.
• All current lifecycle/release claims require revalidation at future publication/update time.

Industry components already expose pieces needed for the matrix: provider model lifecycle/deprecation tables, MCP explicit version/capability semantics, SDK release/conformance state, prompt version registries. What remains organization-specific is the registry that joins these into tested runtime tuples and associates each tuple with contract/eval evidence. Suggested Core record (PROPOSAL): COMPAT_TUPLE_ID; app/build; provider/model resolved ID; API revision; SDK; agent framework; MCP revision/era/capabilities; tool schema; prompt/instruction; response schema; embedding/retrieval/index; policy; evaluator; tested_at; test suite revision; result; known limitations; rollback tuple; owner; expiry/retest date.

No universal compatibility benchmark was established. A reproducible organization-specific contract suite plus representative behavioral eval is the appropriate first-pass evidence. Compatibility evidence should be scoped to the exact tuple tested and must not be generalized to untested versions or all deployments. Long-lived matrices require periodic revalidation and event-driven retest on dependency change/deprecation notices.

Security: compatibility updates can include security-driven upgrades. Pinning an old “known good” tuple indefinitely can preserve known vulnerabilities; matrix policy needs both functional compatibility and security support status. Privacy: compatibility testing should use synthetic/redacted data unless production-like sensitive data is explicitly authorized under a governed test profile. Audit: store the exact resolved tuple and test evidence used to approve an upgrade; mutable aliases alone are insufficient provenance. Cost: new model/API versions can change token pricing, latency or tool-call patterns even when functionally compatible; cost regression belongs in behavioral gates. Operability: deprecation/retirement notices should create planned migration work before retirement, with a verified rollback/fallback path that itself remains available.

「Enterprise AIの互換性は、単一のアプリversionやSDKのsemverだけでは管理できない。model IDとlifecycle、provider API revision、SDK／Agent framework、MCP protocol revisionとcapability、tool schema、prompt、retrieval、policy、evalなどが独立に変化するため、運用上は実際に検証した組合せをCompatibility Matrixとして持つ。接続・schemaが通る“contract互換”と、task品質・policy・costまで維持される“behavior互換”は分けて検証する。『各部品が最新』『各部品が単体でsupported』は、その組合せが互換であることの証明ではない。」

• EA-058 Prompt/Instruction Configuration Management、EA-059 progressive deliveryと接続し、「変更対象tuple固定 -> contract/eval -> canary -> promotion」のupdate workflow候補へ統合する。
• provider mappingでは各社のmodel lifecycle/deprecation、immutable ID/alias semantics、API revision/beta contractを個別採集する。
• MCP mappingでは2026-07-28 modern eraと2025-11-25以前のhandshake eraを別compatibility classとして扱い、capability negotiationまで記録する。
• OpenFeature等の標準についてもspec revisionと各言語SDK/provider conformanceを別欄にする。
• TEST_PROFILE（未実施）: synthetic fixtureで既知good tupleを固定し、model replacement、MCP protocol era差、tool schema破壊、prompt version差を1軸ずつ変更。contract testとbehavior evalを別結果として記録し、意図したincompatibilityを検出できるか確認する。

各providerのalias更新保証・事前通知・replacement availability SLAはproviderごとに異なり、本Packetでは横断確定していない。特定organization tenantのAPI/model availabilityも未確認。Agent framework群の具体的compatibility tableは後続実装比較で採集余地あり。

provider model lifecycle、interoperability protocolのbreaking era、SDK/spec lifecycleという3独立軸の一次証拠が揃い、「単一versionでは管理不能」「contractとbehaviorを分離する」という初回Matrix設計判断が可能になった。provider/tenant固有tupleは後続Workで再検証する。

---

Anthropic Active/Legacy/Deprecated/Retired lifecycle remains current and retired model requests fail. MCP 2026-07-28 is Final/stateless with no initialize handshake; 2025-11-25 and earlier are handshake-era. SDK support remains version/implementation-specific, including TypeScript v2 explicit opt-in for the 2026-07-28 wire revision.