なぜ「ベンダー別」の専門知識が必要なのか
Microsoft・Oracle・IBM・VMware（Broadcom）に共通するのは「複雑なライセンス体系」という一点だけです。それぞれのビジネスモデル・商慣行・監査方針・価格交渉の論理は根本的に異なります。
たとえば、Oracleは仮想化環境においてハイパーバイザー全体を1つのサーバーとみなすPolicy（LIUM）を持ち、適切な構成管理なしに仮想マシンを動かすだけでライセンス違反になるリスクがあります。一方MicrosoftのEAは毎年のTrue-Up（実績申告）が義務付けられており、契約期間中に増加した使用ライセンスを事後追加する仕組みです。IBMはILMT（IBM License Metric Tool）の導入なしにサブキャパシティライセンスが認められないという独自ルールを持ちます。
このような「ベンダー固有の知識」なしに交渉に臨めば、常にベンダー側が優位に立ちます。VMAJの教育領域09は、この非対称な情報格差を縮めることを目的としています。
各ベンダーページには無料の実務ガイド（PDF）を用意しています。ライセンス管理担当者・VMO・IT調達チームの実務参照資料としてご活用ください。
対象ベンダー
Microsoft
EA / MCA-E / CSP 等の契約モデル選択から、True-Up・SA・FVB・ライセンスモビリティの実務、さらにM365・Azure・Copilotの包括的ライセンス管理まで。Microsoft製品群を横断した実務知識を解説します。
Oracle Database
Processor・NUP・Named Userの各メトリクスの違い、仮想化環境での適用ルール（LIUM）、ACE（Authorized Cloud Environments）を活用したクラウド移行戦略、DR/フェイルオーバー時のライセンス扱いを解説します。
VMware（Broadcom）
2024年のBroadcom買収後のライセンスモデル転換（VCF / VVF）、16コア最小単位とSPDの実務、KB313548が示す旧バージョン扱い、Compliance Reporting（180日ルール）、既存環境の移行戦略を解説します。
IBM
IPAA / IPLA / LIの契約階層、PVU・VPC・RVU・MSU等19種のライセンスメトリクス体系、ILMTによるサブキャパシティ管理、コンテナ環境でのIBM License Service運用、パスポートアドバンテージの台帳管理を解説します。
Adobe
Sales Order・PSLT・General Termsの契約階層、Named Userメトリクスと仮想化・共有端末の適用条件、Fireflyクレジット、AI/ML学習利用禁止条項、監査対応（5%許容・30日）を解説します。
Autodesk
契約階層とEBA優先の構造、Single User/Flexトークンメトリクス、残高ゼロ即時停止リスク、仮想化権・APS、15暦日以内の監査証跡提出義務、Education版利用制限を解説します。
Citrix
Order／Business Unit Terms／EUAの契約階層、User/Device等のメトリクス、Citrix Cloudの30日/90日非アクティブルール、LAS移行、DR環境ルール、監査対応（5%・10日前通知）を解説します。
Red Hat
General Terms／Product Appendix／Order Formの契約構造、25種のライセンス単位、SCA/SWATCHの限界、5%監査ペナルティ、用途境界（開発/本番/DR）、第三者提供制限を解説します。
SAP
契約モデル別（MCCA／クラウドDirect GTC／オンプレミスGTC）の優先順位構造、FUEメトリクス、Digital Access（間接利用）超過リスク、USMM/LAW2.0、RISE with SAP責任分界を解説します。
AI知識ベース提供：イタムス株式会社（ITAMS） ※ご利用にはGoogleアカウントが必要です
Demand-to-Contract-to-Service Controlの視点
VMAJが定義する「Demand-to-Contract-to-Service Control（需要・契約・サービス供給のマッチング統制）」において、ベンダー別の専門知識は「契約」フェーズの核心を担います。
需要（組織が必要とするソフトウェア・クラウドサービス）は現場から発生しますが、その需要をベンダーの契約条件・ライセンスメトリクス・価格モデルに正確にマッピングできるかどうかが、コスト最適化と監査リスクゼロの両立を決定します。Microsoft EAのTrue-Upで後払いになる仕組みを知らなければ予算計画が崩れます。Oracle LIUMを理解せずに仮想化環境を設計すれば、翌年の監査で数千万円規模のバックペイを求められるリスクがあります。
各ベンダーページでは、需要→契約→実績管理→更新交渉という一連のサイクルを通じて、ベンダー固有の知識がどこでどのように活きるかを具体的に示します。