Modularが開発するPython風システム言語「Mojo」は、2026年8月18日にコンパイラ、ツール群、言語をビルドするためのソースコードまで公開した。ライセンスはApache 2.0 with LLVM exceptions。もっとも、「完全オープンソース」という見出しだけで判断するのは早い。コンパイラへのプルリクエストはModularが掲げる2026年末まで受け付け停止で、GPUサービングスタックには別ライセンスの事前ビルド済みコンポーネントへの依存も残る。現時点でMojoをどこまで安心して採用できるのか、公開範囲を正確に整理する。
Mojoのオープンソース化は2024年から3段階で進んだ
Mojo languageは、一度のリリースでオープンソースになったわけではない。LLVMとSwiftの作者であるChris Lattnerが創業したModularは、2年以上にわたって段階的にコードを公開してきた。先に公開されたのは標準ライブラリとカーネルコードで、最後にコンパイラが加わった。
| 日付 | 公開されたもの | 外部PR |
|---|---|---|
| 2024年3月 | 標準ライブラリ、Apache 2.0 with LLVM exceptions | 受け付け |
| 2024~2025年 | Mojo GPU/CPUカーネル、2025年5月時点でModularが報告した45万行超のコード | 受け付け |
| 2026年8月11日 | Mojo 1.0.0が安定版に - 言語にsemverを導入、6週間ごとのリリースサイクル | - |
| 2026年8月18日 | コンパイラ、ツール群、ビルド用ソース(ModConで発表) | 2026年末まで凍結 |
情報の鮮度には注意したい。2026年8月18日以前の資料では、コンパイラをクローズドとして扱っているものが多い。たとえばMojo Wikipedia articleは、公開の6日前に当たる2026年8月12日の編集時点で、コンパイラをプロプライエタリなModular Community Licenseの対象としていた。
Apache 2.0 with LLVM exceptionsで実際にできること
リポジトリのLICENSE fileはLLVM自身も使う寛容なライセンス文面であり、2つのLLVM exceptionは単なる法務上の定型文ではない。配布できる成果物に直接影響する。
ベースとなるApache 2.0は、商用利用者に標準的な権利を与える。ソース形式・オブジェクト形式での複製、変更、サブライセンス、配布が可能で、各コントリビューターからの明示的な特許許諾も含まれる。この特許許諾が終了するのは、そのソフトウェアが自分の特許を侵害しているとして訴訟を起こした場合だけだ。再配布時には通常、ライセンスのコピー、変更内容の通知、NOTICEファイルの保持が求められる(Section 4)。
LLVM exceptionsでは、さらに次の2点が免除される。
- 埋め込みオブジェクトコード。 コードをコンパイルした結果、Mojoの一部が生成物に埋め込まれる場合、Sections 4(a)、4(b)、4(d)は免除される。Mojoコンパイラで作ったバイナリごとにApacheライセンス本文を同梱する必要はない。
- GPLv2との組み合わせ。 Mojoでコンパイルした形式をGPLv2コードと組み合わせ、Apacheの特許条項または補償条項がGPLv2と抵触すると裁判所が判断した場合、その複合成果物については抵触する条項を免除できる。
一方で、このライセンスが与えないものもある。MojoおよびModularという名称の商標権、保証、責任保護は含まれない。また、リポジトリのソース公開だけでライセンス全体を判断することもできない。リポジトリのREADMEが明記するように、MAX、Mojo、Modularの利用と配布には別途Modular Community Licenseが適用される。
公開されている部分、されていない部分をコンポーネント別に確認する
「完全オープンソース」がmodular/modularリポジトリで何を意味するのかを見ていこう。2026年8月19日時点で、同リポジトリは53,617コミット、26.9kスター、2.9kフォークを記録している。以下はリポジトリ内にあるものと、外に残るものの整理だ。
| コンポーネント | 場所 | 状況 |
|---|---|---|
| Mojoコンパイラ | /KGENディレクトリ | 2026年8月18日から公開、PRは凍結中 |
| 標準ライブラリ | /mojo/stdlib | 2024年3月から公開、PR受け付け中 |
| MAX GPU/CPUカーネル | /max/kernels | 公開済み、コントリビューションを受け付け |
| 推論サーバー、モデルパイプライン | /max/python/max/serve、/max/pipelines | 公開済み |
| MAXの事前ビルド済みプラットフォームビルド | リポジトリ外で配布 | Modular Community License |
| MAXカーネル/モデルのカスタマイズワークフロー | - | 引き続き事前ビルド済みMojoコンパイラのバイナリが必要 |
最後の行はコミュニティの推測ではなく、Modular自身の説明だ。8月18日の発表では、MAXカーネルやモデルをカスタマイズするには事前ビルド済みコンパイラが「引き続き必要」と明記されている。GPUを対象にするAIエンジニアにとって、ここがオープンソース部分とライセンス付きコンポーネントが接する地点であり、公開初日に利用者から疑問の声が出たのもこの部分だった。r/ProgrammingLanguagesの発表スレッドで、u/benreynwarは次のように書いている。
「GPU向けにコンパイルするには、まだオープンソース化されていないものがかなり必要に見える。」 - u/benreynwar、r/ProgrammingLanguages
ローカルCPUビルドについては、ドキュメントで案内された手順がある。クローンし、Bazelでビルドして実行すればよい。対してGPUカーネルやモデルをカスタマイズする段階で、事前ビルド済みコンパイラへの依存が発生する。
標準ライブラリは貢献可能、コンパイラは2026年末までPR停止
オープンソースであることと、ガバナンスが開かれていることは別の話だ。現在のMojoにあるのは前者だけである。発表記事は、「コンパイラとツール群へのコントリビューションを受け入れる準備はまだできていない」と率直に述べ、2026年末までに受け付け開始する目標を示している。
標準ライブラリの状況は異なる。2024年から外部コントリビューションを受け入れており、Mojo 1.0のリリース日には、Modularの報告によれば、マージ済みPRを持つコントリビューターは約200人に達した。1,100件超のPRで20万行超が変更されている。コンパイラとツール群のPRは、まだ受け付けられない。
ソースから本当にビルドできるかは、自分でも確認できる。
git clone https://github.com/modular/modular.git
cd modular
./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo
./bazelw test --config=build-mojo mojo/stdlib/test/...
--config=build-mojoでは、ローカルでチェックアウトしたコードからコンパイラをビルドする。--config=prebuilt-mojoを使うと、代わりにnightlyバイナリをダウンロードする(発表記事による)。フォークを考える前に、mainブランチはnightlyビルドを追跡すること、安定版は6週間ごとにリリースされること、そしてコンパイラへの貢献が閉じている間はModularがメンテナーとしての管理権限を維持することも押さえておきたい。r/programmingのスレッドでu/Fidodoはこう表現している。
「オープンソースは、コミュニティが支配するという意味ではない。何をマージするかの最終判断は、依然としてメンテナーにある。」 - u/Fidodo、r/programming
Python連携の現状:使えることと使えないこと
公式ホームページには、動作する連携例が示されている。40個のFloat64値を作り、NumPyに渡し、Matplotlibで描画してplot.pngとして保存する――これをすべてMojoから行える。現時点で実用になる相互運用経路は2つある。MojoからCPythonランタイム経由でPythonモジュールをインポートする方法と、C互換バインディングを通じてPythonからMojo関数を呼び出す方法だ。AIエンジニアにとって重要なのは後者である。負荷の高いカーネルをMojoで書き、トレーニングやサービングのコードはPythonに残せる。
一方、2023年の登場時に語られた「Pythonのスーパーセット」という捉え方は、現状には当てはまらない。
- MojoはPython 3とソース互換ではない。Pythonコードを変更なしで実行することはできない。
- 公式ロードマップも、Mojoが完全なPythonスーパーセットへ発展するかどうかは「may or may not」としている。Phase 1では、型なしのPython風コードとPythonライブラリとの同等性を明示的に対象外とした。
- MojoにはPythonのクラスシステムがない。traitsを備えたstructsという別のオブジェクトモデルを採用している。
- クラス、継承、型なし変数はロードマップのPhase 3にあり、まだ開始されていない。Phase 2のツール群とパッケージングは進行中だ。
- 1.0以降であっても、明示的にstableと記されたものを除き、標準ライブラリAPIは不安定である。
実際に移行を試した利用者の表現は、ドキュメントよりさらに率直だ。r/MojoLangのMojoの現状を扱うスレッドから引用する。
「Pythonをスーパーセットとしてサポートするには、まだかなり長い道のりがある。」 - u/newtestdrive、r/MojoLang
「現時点でPythonのスーパーセットでは断じてない。」 - @eatonphil、X
同じu/newtestdriveは、Pythonスクリプトの変換は「可読性を損ない、ときには不可能」とも報告している。ModularのFAQが勧める移行方法は3つだ。ドキュメント化されたPythonとMojoの差分を学ぶ、Mojo AI skillsを使ってアシスタント支援の変換を行う、既存PythonコードからMojoバインディングを段階的に公開する。Pythonの代替ではなく、Pythonらしい書き味を持つカーネル言語として捉えるのが適切だろう。
現在のAIスタックでMojoを使うなら
GPU性能については独立した検証もある。SC25 WACCPDワークショップで発表され、同ワークショップのbest paperを受賞したOak Ridge National Laboratoryの研究は、NVIDIA H100およびAMD MI300A上で、seven-point stencil、BabelStream、miniBUDE、Hartree-Fockという4つのカーネルをCUDAおよびHIPと比較した。Mojoはメモリバウンドなワークロードで概して競争力を見せた一方、atomic操作が多いケースやfast-mathを使うコンピュートバウンドなケースでは、目立つ差が残った。
| ワークロード | 判断 |
|---|---|
| 移植性のあるGPU/CPUカーネルの作成 | 試験導入する価値あり。ORNLのデータはメモリバウンドでの同等性能を裏付けるが、atomic操作が多いAMDコードは先にベンチマークすべき |
| MAXでの本番モデルサービング | 先にModular Community Licenseの条件を確認すること。事前ビルド済みバイナリへの依存は残る |
| 一般的なPythonアプリケーションコードの置き換え | 不可。Phase 3は未完了でソース互換性もなく、パッケージ管理は未着手 |
| アクセラレータプログラミングの学習 | 推奨。読みやすいソース、ローカルビルド、LSPとデバッガーを備えたVS Code拡張機能がある |
導入計画ではプラットフォーム面も確認しておきたい。MojoはLinuxとmacOSでネイティブ動作し、WindowsではWSL経由のみとなる。SDKのテレメトリポリシーによると、収集対象は基本的なシステム情報、クラッシュレポート、集計済みのLSPタイミングであり、ソースコードは送信されない。
FAQ
Mojo言語は現在、完全にオープンソースですか?
はい。2026年8月18日以降、コンパイラ、ツール群、標準ライブラリ、ビルド用ソースは、Apache 2.0 with LLVM exceptionsの下でmodular/modular GitHubリポジトリに置かれている。ただし、MAXの事前ビルド済みプラットフォームビルドには引き続き別のModular Community Licenseが適用される。
Mojoのライセンスは何ですか?
リポジトリのソースコードとコントリビューションにはApache License 2.0 with LLVM exceptionsが使われる。一方、MAXプラットフォームの利用と配布には、別途Modular Community Licenseが適用される。
Mojoコンパイラにコントリビュートできますか?
まだできない。標準ライブラリ、MAXカーネル、サンプル、ドキュメントは外部PRを受け付けている(2024年以降、マージ済みのコントリビューターは約200人)。ただし、コンパイラとツール群へのPRは、Modularが目標とする2026年末まで凍結されている。
MojoはPythonと互換性がありますか?
部分的には互換性がある。MojoはCPythonランタイム経由でPythonモジュールをインポートでき、Pythonから呼び出すためのC互換バインディングも提供する。ただしPython 3とソース互換ではなく、クラスもなく、ロードマップ自身も完全なスーパーセットになるかは「may or may not」としている。
2027年までに注目すべき3つのポイント
今回の公開がコミュニティ主導のプロジェクトへ成熟するかを左右する、日付にひも付く確認点は3つある。コンパイラとツール群へのコントリビューション受け入れについて掲げた2026年末の目標、クラス・継承・型なし変数を含むロードマップPhase 3(本格的なPython互換性が現れるならここだ)、そして1.0以降のsemverポリシーの下で標準ライブラリAPIがどの速度でstableとして明示されていくかである。