Mistral Platform／Open-weight Operating Profile

Mistralの企業利用では、Mistral-hosted inference API、公開されるopen-weight model、Studioの開発・workflow機能、Vibe、Adminを一つの製品面として扱わないことが重要です。同じモデル名が複数面に現れても、artifact、license、availability、data boundary、運用責任、release lifecycleは一致するとは限りません。

2026-10-20時点の公式Models Overviewには、Mistral Large 4、Mistral Medium 3.5、Mistral Small 4、Ministral 3系、OCR、Voxtral等が掲載されています。現行モデルにはApache 2.0、Modified MIT、Open、Premier、CC BY-NC 4.0など異なるlicense/提供区分が混在しています。したがって「MistralモデルはApache 2.0」のようなブランド単位の一般化は不適切です。

公式docsはdeprecated/retired modelも別表で管理しており、過去のAPI identifierが現在も推奨されるとは限りません。Mistral 7B v0.3はretiredで、公式cardは新規integrationにMinistral 3 8Bを案内しています。運用台帳ではmodel family、version、API identifier、license、availability stateを別フィールドにします。

Mistral Large 4は2026-10-06にPublic Previewとして公開され、公式model cardはopen-weight modelとして扱っています。一方、release changelogは同日の時点でopen weightsを“coming soon”と記録しています。このようにmodel availabilityとweight distribution timingはずれることがあります。APIでmodel identifierが利用可能であることを、対応weightが既に取得可能である証拠にしてはいけません。

Ministral 3 3Bの公式cardはApache 2.0、256k context、text/vision capability、edge/local deployment志向を明記しています。Mistral Medium 3.5はModified MITのopen weightsとして公開されています。licenseはmodel/revisionごとに確認し、利用条件を別revisionへ横滑りさせません。

self-hostではweight revision、tokenizer/chat template、quantization、serving runtime、GPU/kernel、sampling default、tool parserを固定します。Mistral-hosted APIの評価結果を、同名・近縁open weightのself-host結果へそのまま移植しません。

公式model cardはStructured Outputs、Function Calling、Document QnA、Batching、Agents & Conversationsなどの対応をmodel別に表示しています。全モデルが同じendpoint capabilityを持つとは限りません。モデル変更時は、単なるquality benchmarkだけでなく、JSON/schema adherence、tool call、streaming、context/output limit、error handling、batch/agent compatibilityをcontract testします。

aliasや“latest”相当の参照をproductionで使う場合は、解決先の変更をsemantic driftとして扱います。再現性が必要な監査・事故調査では、実際に使用したmodel identifier/versionと実行日時を保存します。

Mistral-hosted inferenceでは、regional inferenceとしてEUまたはUSの専用endpointを選べます。公式docsは、これはinference input/outputの処理地域を制御する仕組みであり、Mistral control plane全体をregional化するものではないと明記しています。したがって「EU endpointを使えば全データがEU内」と一般化しません。

Zero Data Retentionは、対象となるpaid-planのstateless API callsについて、処理後に入力・出力を保存しないための別controlです。ZDRとmodel-training opt-outは別設定です。regional inference、retention、training use、observability/logging、workspace dataを別々に確認します。

Observabilityではtraceがprompt、response、tool arguments/results等を含み得ます。公式docsのclient-side redactionはdefaultで有効ですがbest-effortであり、高感度データに対する唯一のcontrolにしないよう明記されています。trace導入時は本番promptの二次保存面として扱います。

2026-10-09にStudio Managed DeploymentsがPublic Previewとして公開されました。これはGitHub repositoryからDocker imageをbuildし、Mistral Cloud上でworkflow workerを実行する機能です。managed deploymentはmodel inference APIそのものではなく、workflow execution infrastructureです。service-account tokenがcontainerへ注入され、workerは長期API keyをrepositoryへ持たずに認証できます。

一方、self-hosted/dedicated deploymentの機能や有効化条件は別です。たとえばVibeのadmin config docsでは、serverless、dedicated、self-hostedでactivation経路が異なる機能があります。SaaS UI上の設定がself-hosted環境でも同じように存在すると推定しません。

• MISTRAL_HOSTED_API、MISTRAL_OPEN_WEIGHT_SELF_HOSTED、MISTRAL_STUDIO_WORKFLOW、MISTRAL_VIBEを別service/surface IDで管理する。
• model inventoryにmodel identifier、version、availability state、license class、modalities、context、required endpointsを記録する。
• deprecated/retired一覧とchangelogを定期readbackし、alias変更・retirement前に移行testを行う。
• self-hostはweight source/revision/hash、license、tokenizer、chat template、runtime、quantization、GPU/kernelを固定する。
• API model変更時はstructured output、tool calling、streaming、error schema、context/output limitを実機contract testする。
• regional inferenceを選ぶ場合も、control plane、logs、workspace、support/telemetryの所在地を別途確認する。
• ZDR、training opt-out、trace/redactionを同一privacy controlとして扱わず、各設定をreadbackする。
• Preview/Labs機能はGAと同じ安定性を前提にせず、rollback pathとversion pinningを持つ。
• managed deploymentではrepository、Dockerfile、dependency、service account、secret binding、deployment regionをrelease evidenceへ残す。
• hosted APIとopen-weight self-hostのquality/cost/latency/security評価を別々に実施する。

公式docsは現行製品面を確認する一次資料ですが、tenant固有の契約、SLA、quota、利用可能region、enterprise optionまで自動的に確定しません。model card上のcontextやfeature対応も、自社prompt、tool schema、runtime、負荷条件での成功率を保証しません。

open-weightであることは、無制限利用、同一license、完全なoffline operation、hosted APIとのbehavioral equivalenceを意味しません。逆にPremier/commercial提供であることも、weightが絶対に存在しないことを推測する根拠にはしません。model/revisionごとの公式cardとlicense artifactを確認します。

自組織契約におけるSLA、quota、support、retention/training設定、利用可能なregional endpoint、dedicated/self-hosted option、各aliasの将来解決先、Mistral Large 4のweight distributionの現在の実取得状態、特定quantization/runtimeでのtool-call互換性は、契約・live console/API・artifact readbackなしには確定できません。

「Mistralを導入している」ではなく、「Mistral-hosted APIのmodel identifier/version Xをregion Y・privacy setting Zで利用」または「model/revision Xのopen weightをlicense L、runtime R、quantization Qでself-host」と記述します。API availability、weight availability、license、hosting/data boundaryを相互に推定しません。

• Mistral AI, Models Overview, accessed 2026-10-20: https://docs.mistral.ai/models
• Mistral AI, Changelog, accessed 2026-10-20: https://docs.mistral.ai/resources/changelogs
• Mistral AI, Mistral Large 4 model card, 2026-10-06: https://docs.mistral.ai/models/mistral-large-4-0
• Mistral AI, Ministral 3 3B model card, 2025-12-02: https://docs.mistral.ai/models/ministral-3-3b-25-12
• Mistral AI, Mistral Medium 3.5 model card, 2026-04-28: https://docs.mistral.ai/models/mistral-medium-3-5-26-04
• Mistral AI, Regional inference, accessed 2026-10-20: https://docs.mistral.ai/inference/regional-inference
• Mistral AI, Zero Data Retention, accessed 2026-10-20: https://docs.mistral.ai/admin/monitor-comply/zero-data-retention
• Mistral AI, Observability / data redaction, accessed 2026-10-20: https://docs.mistral.ai/studio/observability/traces/data-redaction
• Mistral AI, Managed deployments, accessed 2026-10-20: https://docs.mistral.ai/studio/workflows/managing-workflows-in-production/managed-deployments
• Mistral AI, Managed deployments / How it works, accessed 2026-10-20: https://docs.mistral.ai/studio/workflows/managing-workflows-in-production/managed-deployments/how-it-works

EA-1212はMistralの提供API/製品面と配布モデルを分離し、license、version、data boundary、deployment responsibility、capability evaluationを運用profileとして扱います。一般的なopen-weight governance、vLLM等のserving runtime、provider横断routingは別EAの共通論点です。