2026 Modular Alliance 未開放：MAX 自己ホスト型プロジェクトは今どう進める？
2026年8月18日、ModularはMAX Community Licenseから旧来のデバイス数制限と、未対応ハードウェア利用に必要だった書面許可を削除したと案内しています。公式ライセンスに基づく可逆的なPoCと社内検証は、Modular Allianceの細則を待たずに進められます。一方、顧客向け配布、ホスティング、商標利用、ハードウェア協業は別のゲートで止め、正式規約が出るまで個別に再確認するのが勝ち筋です。
この判断が向くのは、近くMAX自己ホスト型のPoCを始めたいプラットフォームチームです。Apple Siliconなどの対応環境を確保しながら、待機期間のリソースを遊ばせたくないインフラ責任者にも適しています。法的結論ではなく、プロジェクトの「続行・保留・専門家確認」を切り分けたい開発責任者とコンプライアンス担当者も対象です。
※最終更新：2026年8月28日。情報はModCon 2026の公式発表、MAX Community License、公式の自己ホスト型案内を基に確認しています。Allianceの加盟条件や申請資格は、正式公開前の情報として扱います。
最初に分けるべき、現行ライセンスとAlliance
「オープンになった」という宣伝文句だけで、すべての利用条件が同じになるわけではありません。公式資料では、MojoのApache 2.0系コンポーネントと、MAX source-availableとして扱われる範囲が区別されています。公式自托管ページの説明も、個別ファイルや配布物に付属する条件の代わりにはなりません。
Modular Allianceは、Modularが2026年末までに詳細を示す予定の取り組みです。現時点では、加盟資格、申請入口、貢献規則、加盟によるライセンス上の免除を前提にできません。ModConの告知が政策の方向を示していても、現在使うバージョンの契約条件を置き換えるものではありません。
| 判断対象 | 現時点で確認できること | プロジェクト上の扱い |
|---|---|---|
| MAX Community License | 対象バージョンに付属する利用・配布条件を確認する | PoCと社内検証の基準にする |
| MAX source-available | ソース公開の範囲と、各配布物のLICENSEを確認する | OSI認証のオープンソースと同一視しない |
| Modular Alliance | 詳細、加盟資格、申請条件は未公表 | 協業・エコシステム参加の判断だけ保留する |
したがって、MAXの利用権、公式サイトの開放表現、Allianceへの参加価値は三つに分けて記録します。Allianceに加入できるか分からないことと、現行版で技術検証を開始できるかは、同じ問いではありません。
立ち上げ日に「待たない作業」と「止める作業」を分ける
立案会議では、次の条件分岐をそのまま承認表にできます。
- 社内限定で、いつでも破棄できる環境かつ顧客へ配布しない場合は、現行版のライセンスを保存してPoCを続行します。
- モデル互換性、依存関係、Apple Siliconでの動作、環境引き渡しを調べるだけなら、Alliance参加を前提にしません。
- 顧客へアプリやオブジェクトコードを渡す場合は、配布物と表示義務を確認できるまで対象範囲を限定します。
- MAXを組み込んだ推論基盤を他社向けに提供する場合は、ホスティング条件、商標、書面承認の要否を専門担当者へ引き継ぎます。
- ハードウェア適合、共同最適化、ロードマップ参加を目的にする場合は、Allianceの正式規約が出るまで「参加可能」と記載しません。
この分け方なら、技術チームは作業を進め、法務・管理部門は外部提供に関係する項目だけを重点審査できます。待機をゼロか百かで扱わないことが、今回の変更後に必要な運用です。
第二段階：PoC前にライセンスのスナップショットを固定する
PoC開始時は、次の記録を一つの変更台帳に固定します。ダウンロード日、インストール日、MAXの具体的なリリース、取得元URL、同梱LICENSE、コンテナのイメージ識別子、ソース取得時点を保存します。公式リリースは後から更新される可能性があるため、GitHub Releasesの該当版も台帳に記録します。
| 保存項目 | 記録する内容 | 再確認の理由 |
|---|---|---|
| MAX本体 | バージョン、取得日、配布形式 | どの条項を適用したか特定するため |
| 法的文書 | 同梱LICENSE、公式ページの更新日 | 条件変更の影響範囲を分けるため |
| ソースと依存関係 | リポジトリのコミット、コンポーネント別LICENSE | 単一のトップレベルLICENSEに依存しないため |
| 実行環境 | Apple Siliconまたは使用した対応ハードウェア、コンテナ定義 | 同じPoCを再現するため |
| 変更内容 | パッチ、設定変更、追加モデル、配布予定 | 将来の公開範囲を判断するため |
同じリポジトリ内に、Apache 2.0 with LLVM Exceptionsのコンポーネントと、MAX Community Licenseの対象となる利用・配布行為が混在する可能性があります。公式リポジトリのライセンス説明を確認し、トップレベルLICENSEだけで全体を一括判定しないことが必要です。
第三段階：待機期間は、失敗しても戻せる技術検証に使う
PoCでは「動いたか」だけでなく、「何を動かしたか」を残します。検証対象はモデル互換性、依存パッケージの導入、Apple Siliconまたは別の対応ハードウェアでの実行、環境の引き渡し、基礎的な性能確認です。性能結果は商用利用の承認ではなく、次の構成を選ぶための技術資料として扱います。
実施手順は次の流れにすると、後の再審査で説明しやすくなります。
- MAXの対象リリースとLICENSEを保存します。
- 固定したコンテナ、依存関係、モデルの取得元を台帳に登録します。
- 変更をパッチまたは設定差分として分離します。
- Apple Siliconなど実際に使う環境で、導入、起動、推論、停止を確認します。
- 環境を破棄して、同じ定義から再構築できるか確認します。
- 使用したバイナリ、ソース、モデル、ログ、変更範囲を成果物として保管します。
一時的な算力が必要なら、短期で引き渡せて、不要になれば破棄できる隔離環境が向きます。長期固定の自前設備を先に購入すると、Allianceの条件変更ではなく、単純な構成変更だけで資産が余る可能性があります。
三つの進路を比較して、PoCの出口を決める
| 進路 | 先に進められる範囲 | 主な保留点 |
|---|---|---|
| 社内PoC | 導入、互換性、再現性、基礎性能 | 社外配布へ移る時点で再審査 |
| 社内本番 | 社内限定の推論運用、監視、更新手順 | Usage Data、ネットワーク、変更版の扱い |
| 顧客向け提供 | 承認済み範囲のアプリ・サービス設計 | 配布、商標、再配布、書面手続き、契約条件 |
社内本番へ進む前には、利用者が自社の従業員に限られるか、MAXを変更しているか、第三者モデルや依存関係を再配布するかを確認します。Usage Dataやネットワークアクセスに関する条件も、環境構成と一緒に台帳へ記録します。
| 作業状態 | 続行条件 | 回退先 |
|---|---|---|
| 技術検証 | 環境を破棄でき、外部配布をしない | 条件未確認なら社内限定PoC |
| 内部運用 | 配置物、変更、データ経路の承認記録がある | 検証環境へ戻す |
| 対外交付 | 配布物と表示・商標条件を確認済み | 顧客へ渡さない検証版に戻す |
| 管理推論サービス | ホスティングと書面承認の要否を確認済み | 社内利用または停止 |
価格や提供形態を比較する場合は、公式の料金とデプロイメント案内だけでなく、実際の契約範囲と運用責任を確認します。自己ホスト型であることは、ライセンス審査や顧客契約の審査を省略できるという意味ではありません。
FAQ：Alliance前の商用判断をどう整理するか
FAQでは、検索されやすい疑問を「現行版の条件」と「将来のAlliance」を混同しない形で整理します。判断材料が不足している項目は、無理に許可へ寄せず、対象範囲を狭めて再確認へ回します。
第四段階：顧客向け配布とホスティングでは一度止める
顧客へアプリ、オブジェクトコード、変更版を渡す段階では、PoCの成功をそのまま公開許可に変換できません。再配布するコンポーネント、通知・署名、商標の表示、追加機能、第三者モデルと依存関係を成果物単位で確認します。
他社向けの管理推論サービスでは、さらにサービス形態を分けます。MAXを社内設備で使う場合と、顧客がアクセスするサービスとして提供する場合では、確認対象が異なります。商標利用や書面による承認手続きが関係する可能性があるため、現行の公式条文だけで明確に説明できない範囲は、公開を保留して専門家へ回します。
ここでAlliance加盟を先に仮定するのは危険です。加盟資格が後日決まっても、現在の配布物に付属する条件、顧客との契約、第三者コンポーネントの義務が自動的に消えるとは限りません。
Alliance公表後は、全件ではなく変更点だけ再審査する
正式情報が出たら、プロジェクト全体を最初からやり直すのではなく、差分を確認します。確認対象は、正式章程、加盟資格、申請入口、貢献ルール、新しいLICENSE、MAXソースの公開範囲です。公式ブログ、法律ページ、GitHub Releases、リポジトリのLICENSEに新しい日付や条項が出た時点で、変更台帳を起点に再確認します。
Alliance参加の価値は、ハードウェア適合、共同最適化、ロードマップへの関与など、協業面で評価します。基礎的な利用・配布権は、あくまで実際に使用するMAXバージョンの条項で別に判定します。変更がなかったゲートは記録を維持し、影響を受けたゲートだけ結論を書き換えます。
細則を待つ間も検証日程を守る必要がある場合は、隔離して回収できるクラウドMacレンタル環境でMAXの技術PoCを先に実施する方法があります。ProxyMacの日本向け料金と利用条件で期間と提供条件を確認し、検証後はコンソールの運用手順に沿って環境、ログ、バージョン証跡を整理すると、後の社内本番・顧客向け審査へ資料を持ち越せます。長期の安定負荷や物理インターフェースが必要な案件では自社設備が適するため、レンタルは待機期間の検証や短期の再現環境に限定する判断が現実的です。
