{
  "format": "agent-article-v0",
  "article_id": "EA-157",
  "canonical_url": "/tools/ea-157-mcp",
  "page_type": "update_note",
  "claim_ids": [],
  "evidence_ids": [
    "EA-157-CURRENT-APPROVAL",
    "EA-157-CURRENT-BODY-READBACK"
  ],
  "unknown_ids": [
    "EA-157-UNKNOWN-01"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "CURRENT",
  "observation_status": "SPEC_ONLY",
  "freshness": "CURRENT",
  "last_verified": "2026-10-11",
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "GXART-EA157-20261011-R1",
    "BODY-SHA256:a62e0990323c1c95d0f4cdd243637f9cf26663a8de87f1cacbe45ae77d0b9430"
  ],
  "article_sources": [
    {
      "id": "EA-157-CURRENT-APPROVAL",
      "evidence_class": "RESEARCH",
      "title": "現行本文の監査・revision対応",
      "supports": [
        "現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。"
      ],
      "limit": "監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "GXART-EA157-20261011-R1"
      ],
      "supporting_locators": [
        "1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ",
        "EA_REVISION_LEDGER!A380:U380",
        "EA-157-GX-REFRESH-20261011-R1"
      ],
      "provenance_status": "CURRENT_CANONICAL_APPROVAL_READBACK"
    },
    {
      "id": "EA-157-CURRENT-BODY-READBACK",
      "evidence_class": "IMPL",
      "title": "現行本文の収録照合",
      "supports": [
        "公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。"
      ],
      "limit": "本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。",
      "checked_at": "2026-10-12",
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "BODY-SHA256:a62e0990323c1c95d0f4cdd243637f9cf26663a8de87f1cacbe45ae77d0b9430"
      ],
      "supporting_locators": [
        "content/staging/EA-157.md",
        "a62e0990323c1c95d0f4cdd243637f9cf26663a8de87f1cacbe45ae77d0b9430",
        "EA-157-GX-REFRESH-20261011-R1"
      ],
      "provenance_status": "CURRENT_APPROVED_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "結論・何が分かったか",
      "text": "MCPの導入可否を「MCP対応」という一語で判定してはいけない。少なくとも、**プロトコルrevision、SDK/package、実際にwire上で選ばれるrevision、Gatewayが広告する対応revision、下流targetのrevision、認可・trust・監査の実装**を分離して確認する必要がある。\n\n2026-07-28 revisionは、従来の2025-eraとwire behaviorが異なる。2025-eraは `initialize` handshake を使う一方、2026-07-28はstatelessなmodern eraとして `server/discover` とrequestごとのversion情報を使う。さらに公式TypeScript SDK v2でも、v2 packageを使うだけでは2026-07-28をwire上で話すことにはならず、modern revisionの利用は明示的なopt-in/negotiationを要する。\n\nAWS AgentCore Gatewayの現行ドキュメントは、この違いを実運用上のversion gateとして露出している。Gatewayは複数のMCP revisionを同時に広告でき、clientはrequestごとにrevisionを指定する。したがって「GatewayがMCP対応」「SDKがv2」という情報だけでは、実際にどのrevisionで通信するかは確定しない。"
    },
    {
      "heading": "適用範囲",
      "text": "対象はMCPを利用するhost/client/server、SDK、Gateway、proxy、tool serverの導入・更新・移行・監査である。特定providerだけの推奨構成ではなく、versioned protocolを業務接続境界として扱う際の確認原則を示す。\n\n本記事は、MCP接続そのものが安全性、tool correctness、認可、exactly-once、可用性を保証するとは主張しない。"
    },
    {
      "heading": "確認できたclaim",
      "text": "### Claim 1 — 2026-07-28は2025-eraと同じwire behaviorではない\n\nMCP TypeScript SDKのprotocol-version資料は、2024-10-07〜2025-11-25を `legacy` era、2026-07-28を `modern` eraとして区別する。legacyでは `initialize` handshakeを行い、modernでは `server/discover` によるadvertisementを使う。\n\n**運用上の意味:** compatibility matrixは「MCP = yes/no」ではなく、revision/eraを列として持つ必要がある。\n\n### Claim 2 — SDK/package versionとwire revisionは同じではない\n\n公式TypeScript SDK v2のmigration資料は、v2 packageを利用しても2026-07-28のwire behaviorが自動で有効になるわけではなく、modern revisionを話すには明示的なversion negotiation/opt-inが必要だと説明する。\n\n**運用上の意味:** dependency inventoryだけでprotocol conformanceを判定しない。runtime configurationとnegotiated/served revisionをreadbackする。\n\n### Claim 3 — Gatewayは複数revisionを同時に扱い得る\n\nAmazon Bedrock AgentCore Gatewayの現行ドキュメントは、2026-07-28、2025-11-25、2025-06-18、2025-03-26をsupported revisionsとして示す。2026-07-28 requestはstatelessで、older revisionsは従来のinitialize handshakeを継続する。Gatewayは `supportedVersions` を広告し、requestで指定されたrevisionが広告集合にない場合は拒否する。\n\n**運用上の意味:** Gateway導入時は「製品がMCP対応か」ではなく、対象endpointが現在広告しているrevision集合とclientが実際に要求するrevisionを照合する。\n\n### Claim 4 — 接続成功とenterprise-gradeな安全性は別判定である\n\nMCPのprotocol connectivity、SDK support、Gateway version routingが成立しても、server/tool trust、authorization policy、data boundary、audit completeness、failure/retry semantics、tool result correctnessは別レイヤーである。\n\n**運用上の意味:** compatibility testとsecurity/operability testを同じPASSにまとめない。"
    },
    {
      "heading": "失敗経路・反証・例外",
      "text": "- 「SDK v2だから2026-07-28対応」と推定する。\n- 「GatewayがMCP対応だからclient/server間の全revisionが互換」と推定する。\n- Gateway inboundで新revisionが通ることから、下流targetまで同じrevisionで動くと推定する。\n- 接続成功をauthorization、tool trust、監査、データ保護の成立証拠にする。\n- release noteやroadmapをnormative contractとして扱う。\n\nGX A3では、AgentCore Gatewayのdownstream target syncがinboundとは別のversion境界を持ち得るという外部運用報告も捕捉された。ただし、この点は今回の公開claimとして一般化しない。現行公式ドキュメントだけでは、全target経路について同一のdownstream negotiation挙動を保証できないためである。"
    },
    {
      "heading": "Availability Gate",
      "text": "導入・移行時に最低限、次をreadbackする。\n\n1. 使用するMCP protocol revision。\n2. SDK/packageのversionだけでなく、runtimeで有効なversion negotiation設定。\n3. host/client/serverが実際に話すrevision/era。\n4. Gateway/proxyが広告する `supportedVersions`。\n5. upstreamとdownstream targetを分けたversion support。\n6. authorization、scopes、audience、credential isolation。\n7. server/tool registry・allowlist・publisher/trust policy。\n8. tool schema/versionと変更管理。\n9. audit/retention、rate/size limit、timeout/retry。\n10. provider/plan/region/organization policyによるavailability。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- provider横断のhost/client/server conformance matrix。\n- 各SDKのrelease/tagとwire-revision対応の完全な同期表。\n- Gateway/proxyの全製品で共通するnegotiation semantics。\n- inbound revisionとdownstream target revisionの自動変換・fallbackの一般保証。\n- registry/tool trustの共通標準。\n- tenant別のaudit/retention/data-residency。\n- latency/cost/incident rateのprovider横断実測。\n- revision migrationが実業務のtool semanticsへ与える影響。"
    },
    {
      "heading": "実務チェックポイント",
      "text": "**導入前:** revisionを固定し、client/server/Gatewayの対応集合を表にする。  \n**更新前:** SDK更新とprotocol revision更新を別changeとして扱う。  \n**試験:** handshake/discovery、version rejection、fallback、tool list/call、authorization failure、audit recordを個別に検証する。  \n**本番判定:** 「接続できた」ではなく、期待revisionで通信したことをreadbackし、security/operability gateを別途通す。  \n**ロールバック:** 旧revisionを外す前に、利用中clientが新revisionへ移行済みか確認する。"
    },
    {
      "heading": "証拠・更新情報",
      "text": "Evidence as of: 2026-10-11 JST.\n\nPrimary / author-maintained:\n- Model Context Protocol TypeScript SDK — Protocol versions.\n- Model Context Protocol TypeScript SDK — Supporting protocol revision 2026-07-28.\n- Amazon Bedrock AgentCore — Use an AgentCore gateway.\n- AWS Artificial Intelligence Blog — How AgentCore Gateway supports the MCP 2026-07-28 spec.\n- MCP 2026-07-28 specification and existing EA-157 canonical evidence packet.\n\nGX provenance:\n- `GX01_RUN_20260928_1113_A3` (A3 Agent・相互運用標準). RUN ID/date/slot are provenance only and are not the public article identity."
    },
    {
      "heading": "SAFE_WORDING",
      "text": "「MCP対応」は単独では互換性の証拠にならない。protocol revision、SDK、実際のwire revision、Gatewayのsupported revisions、下流target、authorization/trust/auditを分離して確認する。2026-07-28は2025-eraとwire behaviorが異なり、SDKのmajor versionだけから実通信revisionを推定してはならない。"
    }
  ],
  "human_url": "/tools/ea-157-mcp",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-157-mcp",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-157-mcp"
}