--- title: "Mojo 1.0とは｜安定保証の範囲とApache 2.0公開・1.x移行で壊れる箇所を解説" url: "https://www.issoh.co.jp/tech/details/16907/" published: 2026-08-24 updated: 2026-08-24 categories: ["開発"] publisher: "株式会社一創" --- # Mojo 1.0とは｜安定保証の範囲とApache 2.0公開・1.x移行で壊れる箇所を解説 Modularは2026年8月11日にMojo 1.0.0を公開し、その1週間後の8月18日にコンパイラとツールチェーンをApache 2.0（LLVM例外付き）で公開しました。1.0で変わったのは構文の派手さではありません。「どこまでなら壊れないと約束されたのか」という線引きが、初めて機械的に読める形になったことです。この記事では、安定マーカーの付いたAPIだけが保証対象という仕組み、守られるのはソース互換だけでABIは対象外という限界、InlineArrayからArrayへの改名を含む破壊的変更の手当て、GPU関連APIがMAX側へ移った影響、非同期やパターンマッチが未提供という前提から、受託開発の現場でMojoを採用してよい条件と見送るべき条件までを整理します。言語そのものの仕組みは[Mojoの言語仕様を実装視点で整理した解説](https://www.issoh.co.jp/tech/details/15401/)で扱っているため、ここでは版イベントとしての1.0だけを扱います。 ## まとめ｜Mojo 1.0で確定した保証の範囲と、採用判断が動く条件 Mojo 1.0の中身は、新機能ではなく約束の明文化です。標準ライブラリのAPIには成熟度を示すマーカーが付き、安定と表示されたものだけが同一メジャーバージョン内でのソース互換を保証されます。全面的に安定と宣言されたのは`Deinitable`、`Movable`、`Copyable`、`ImplicitlyCopyable`といったトレイト群で、`Array`や`List`、`String`、`Optional`などの日常的に使う型は、一部のAPIが安定化の初回対象に入ったにすぎません。 保証の外側も明確になりました。守られるのはソースコードの互換だけで、ABIは安定していません。コンパイラを上げたら再ビルドが必要になり、事前ビルド済みのバイナリを配って別バージョンのコンパイラから動的に読み込む使い方は、まだ成立しない前提で設計します。1.x系の変更は加算が中心という方針は示されたものの、破壊的変更がゼロになるとは宣言されていません。 採用可否は、書こうとしている領域が未提供機能に触れるかどうかで決まります。first-classな非同期処理、代数的データ型とパターンマッチ、`private`相当のアクセス制御、実行時に型を差し替えるdynamic traitsは、いずれもロードマップ上の未着手項目です。推論のホットパスやGPUカーネルのように、同期的な数値計算へ閉じた範囲なら1.0を根拠に前へ進めます。 ## Mojo 1.0が確定させたもの｜版番号の分離と安定マーカーが示す保証の輪郭 1.0という数字だけを見て「完成した」と読むと判断を誤ります。Modularが1.0で線を引いたのは完成度ではなく、互換性に関する約束の範囲でした。 ### 版番号の分離｜プラットフォームの26.5と言語のセマンティックバージョニング1.0.0 Mojo 1.0.0は、Modular 26.5というプラットフォームのリリースに含まれる形で出ました。ここで版番号の体系が二重になっている点に注意が必要です。プラットフォーム側は年と通番を組み合わせた26.5という表記を続け、言語側だけがセマンティックバージョニングの1.0.0へ移りました。 この分離には実務上の意味があります。プラットフォームの版が上がっても、言語のメジャー番号が1のままであれば、安定マーカーの付いたAPIに関するソース互換の約束は続きます。依存管理ツールで固定すべき対象は「26.5」ではなく、Mojo側の版です。開発版も並走しており、1.0.0の公開から2週間足らずで1.1.0のナイトリービルドが日付入りの番号で流れていました。 ### 安定マーカーの読み方｜APIリファレンスで安定表示のある範囲だけが保証対象 標準ライブラリのAPIへ成熟度のマーカーを付ける仕組みは、1.0へ至る整理作業の中で導入されました。判断はパッケージ単位でも型単位でもなく、API単位です。同じ`String`型の中に、安定と宣言されたメソッドと、まだ変わりうるメソッドが同居します。 全面的に安定と宣言されたのは、値の生存と複製にかかわる基礎トレイトでした。`Deinitable`、`Movable`、`Copyable`、`ImplicitlyCopyable`の4つが該当し、これらを制約に使ったジェネリックコードは、同一メジャーバージョンの範囲で書き直しを迫られません。一方で`Array`、`List`、`Span`、`String`、`Bool`、`Optional`は、一部のAPIだけが初回の安定化対象に入りました。 実装時の手順はひとつです。使う関数のリファレンスを開き、安定の表示を確認してから依存する。表示がなければ、その呼び出しは1.x系で書き換えが要る候補としてレビュー観点へ入れます。 ### 保証はソース互換のみ｜ABI未安定がバイナリ配布と動的リンクに残す制約 Modularが1.0で約束したのは、ソースコードの互換性です。ABI、つまりコンパイル済みバイナリ同士の呼び出し規約は安定化の対象に入っていません。この違いは設計へ直接効きます。 ソース互換だけが保証されるとは、コンパイラを更新したら依存ライブラリも含め全体を再ビルドする前提で運用するということです。共有ライブラリの形で配布し、利用側が別バージョンのコンパイラで生成した実行ファイルから読み込む構成は成立しません。プラグイン機構を持つ製品や、顧客環境へバイナリだけを納品する形態では、この一点が採用可否を分けます。 CI側の設計も変わります。Mojoのコンパイラ版を固定し、更新するときは依存関係を丸ごと作り直して回帰テストを通す。この手順を最初から組んでおけば、ABIが後から安定化された場合にも移行の手戻りは出ません。 ## 1.0の破壊的変更と移行の実費｜改名の対応と機械的に片付く範囲の見極め 1.0は安定宣言であると同時に、0.25系までの命名を整理し切る最後の機会でもありました。結果として、これまでの版より多くの破壊的変更が一度に入っています。 ### 主要な改名の対応表｜非推奨エイリアスとfix-itが用意された移行の猶予 改名は名前だけの変更ではなく、型の統合を伴うものが含まれます。まず対応関係を押さえます。 | 1.0より前の名称 | 1.0以降の名称 | 移行の手当て | | ---------------------- | ---------- | ---------- | | InlineArray | Array | 非推奨エイリアスあり | | StringSlice | StringSpan | 非推奨エイリアスあり | | ImplicitlyDestructible | Deinitable | 非推奨エイリアスあり | | UnsafePointer | Pointer | 操作名へ接頭辞を付与 | | read（引数の規約） | imm | 推奨表記の置き換え | 移行コストを左右するのは、非推奨エイリアスとコンパイラのfix-it提案です。ほぼすべての破壊的変更に対して旧名のエイリアスが残され、コンパイラは新しい書き方を修正候補として提示します。エディタ側でfix-itを適用していけば、改名の大半は読み合わせなしで片付く。手作業が残るのは、旧名を文字列として組み立てているコード生成部分と、社内Wikiや設計書の記述です。 ### UnsafePointerのPointer統合｜危険性を型名から操作名へ移した設計変更 `UnsafePointer`が単一の`Pointer`型へ統合され、危険な操作の側に`unsafe_`という接頭辞が付く形になりました。型の名前で「これは危ない」と示す設計から、操作の名前で示す設計への移行です。 この変更はレビュー基準へ影響します。従来は型名を検索すれば危険箇所を洗い出せましたが、1.0以降は`Pointer`を使っていること自体は問題になりません。見るべきは`unsafe_`で始まる操作の呼び出し箇所で、静的解析やgrepのルールは検索対象を型名から接頭辞へ切り替えます。 あわせて、要素への参照を保持したままコレクションを書き換えた場合に、コンパイル時点で弾かれる範囲が広がりました。所有権モデルの考え方は0.25系から連続しているため、既存コードの書き換え自体は限定的です。 ### GPU関連APIのMAX移設｜標準ライブラリからmaxパッケージへ移った依存関係 1.0では、GPUとアクセラレータ向けのAPIが標準ライブラリからMAX側のパッケージへ移りました。`std.gpu`配下は`max.gpu`配下へ、`std.benchmark`のマルチコンテキスト関連は`max.benchmark`へ、レイアウト関連のパッケージはMAXへ同梱される形へ変わっています。 この移設が意味するのは、言語のコアとハードウェア向けの実行基盤を切り分けたということです。CPU向けの数値計算だけであれば言語本体で完結しますが、GPUカーネルを書くならMAXの導入が前提になります。インストールも`uv pip install --upgrade mojo`で言語側を入れ、`uv pip install max[all]`でMAX側を追加する二段構えです。 移行時に見落としやすいのは、依存の記述だけを直してビルドが通ったところで安心してしまうケースでしょう。パッケージが分かれたぶん、MAX側の版と言語側の版の組み合わせが噛み合っているかを確認する工程が増えます。GPU側の前提知識は[CUDAの仕組みとバージョン体系を整理した記事](https://www.issoh.co.jp/tech/details/4902/)にまとめています。 Python相互運用にも手が入りました。演算子の処理がCPython側の抽象プロトコルを経由する形へ変わり、相互運用の多いコードでおよそ12倍の改善が公式に示されています。Python資産と併存させる構成では、この差が体感に出ます。 ## Apache 2.0でのコンパイラ公開｜LLVM例外付きライセンスが実務に効く範囲 2026年8月18日、Mojoのコンパイラとツールチェーンが公開されました。標準ライブラリは2024年から外部貢献を受け付けていたため、ここで初めて言語全体のソースが揃った形です。 ### 公開の範囲と時期｜コンパイラとツールチェーンが単一リポジトリへ集約 公開されたのはコンパイラ本体とツールチェーン、そして言語をビルドするために必要な一式で、modular/modular のリポジトリに置かれています。ライセンスはApache 2.0にLLVM例外を加えたもので、LLVM本体と同じ組み合わせです。 時系列は、8月11日に1.0.0、8月18日にソース公開という順序でした。安定宣言を先に出し、その後で実装を開けたことになります。ドキュメントの所在も動いており、従来のdocs.modular.com配下のロードマップURLは、現在mojolang.org側へリダイレクトされます。社内資料に旧URLを控えているなら差し替えが必要です。 ### LLVM例外が外す義務｜生成バイナリの帰属表示と特許条項の実務上の読み方 Apache 2.0だけであれば、成果物を再配布するときに帰属表示とライセンス文の同梱が求められます。LLVM例外は、コンパイラの出力に含まれるランタイム由来のコードについて、この義務を外すために置かれた条項です。Mojoでビルドした実行ファイルを顧客へ納品するとき、ツールチェーン側のライセンス文を製品へ添付し続ける必要はない、という読み方になります。 特許条項の側はApache 2.0のまま残ります。貢献者からの特許ライセンス付与と、利用者が特許訴訟を起こした場合の終了条項がそのまま効く。ライセンス条項そのものの逐条解説は[主要オープンソースライセンスの義務を条項番号で整理した記事](https://www.issoh.co.jp/column/details/3932/)で扱っているため、社内の法務確認ではそちらを併せて参照してください。 ### 外部貢献の受付は2026年内が目標｜Qualcomm買収後の体制で今できること ソースが公開されたことと、外部からの変更を受け付けることは別です。Modularはコンパイラとツールチェーンへのコントリビューション受付について、2026年内の開始を目標として示しました。現時点で外部にできるのは、実装を読むこと、問題を報告すること、そして以前から受付が続いている標準ライブラリへ提案することです。 体制面では、Qualcommによる買収が2026年7月29日に完了しています。発表は6月24日で、全株式による取引でした。買収後もMojo、MAX、Modular Cloudは製品とブランドとして継続すると明言されています。1.0と全ソース公開が買収完了の3週間以内に相次いだ事実は、当面の開発継続を裏づける材料として読めます。 ただし、ハードウェアベンダー傘下という構造は残ります。中立性を条件に入れる案件では、公開済みのコードは後から取り消せないというライセンスの性質を根拠に置くほうが、方針の表明よりも確度の高い判断材料になります。 ## 未提供の言語機能から逆算する適用範囲｜非同期とパターンマッチの不在が引く線 採用可否を検討するとき、備わっている機能を数えるより、まだ無い機能を確認するほうが早く結論へ届きます。ロードマップで未着手として並んでいる項目は、そのままMojoで書きにくい領域を示しています。 ### first-class asyncの不在｜I/O多重化主体のサービス実装を載せない理由 型システムとメモリモデルへ完全に統合された非同期処理は、ロードマップ上で未着手の項目として置かれています。多数の接続を同時に捌くネットワークサービスや、待ち時間の隠蔽を前提とするジョブ実行基盤を、Mojoだけで書く段階には来ていません。 実務での置き方はこうなります。サービスの外殻はPythonやGoで書き、計算量の集中する部分だけをMojoへ切り出す。Mojo側は同期的な関数として呼ばれ、内部で並列化を効かせる。この境界で分けておけば、非同期が入った時点で内側を広げていけます。推論基盤としての層構成は[LLM推論の高速化手法と基盤選定を整理した記事](https://www.issoh.co.jp/tech/details/15363/)の考え方が流用できます。 ### 代数的データ型とパターンマッチの不在｜状態機械やパーサ実装で生じる記述量の差 代数的データ型とパターンマッチは、表現力のある状態モデリングを可能にする機能としてロードマップへ挙がっており、こちらも未着手です。RustやSwiftで慣れた書き方をそのまま持ち込むと、記述量が増えます。 影響が出るのは、入力を分類しながら処理を分岐させる種類のコードです。プロトコルのパーサ、コンパイラのフロントエンド、複雑な状態遷移を持つ制御ロジックがこれにあたります。分岐を列挙型とマッチで畳み込めないぶん、条件分岐とタグ判定を手で書くことになり、抜けが入りやすくなる。数値計算のカーネルでは問題になりませんが、業務ロジックを載せると効いてきます。 ### アクセス制御とdynamic traitsの不在｜公開ライブラリのAPI境界設計への影響 `private`修飾子のようなアクセス制御は、ロードマップ上で今後の項目として挙げられています。実行時に振る舞いを差し替えるdynamic traits、いわゆる存在型も同様です。 社内で閉じたコードなら命名規約で運用できますが、第三者へ公開するライブラリでは事情が変わります。内部実装として隠しておきたい関数を言語機能では隠せないため、いったん公開した名前が事実上のAPIとして扱われ、後から変えにくくなる。ライブラリを配る予定があるなら、公開範囲をモジュール構成とドキュメントで明示し、内部用の名前には接頭辞を付けるといった規約を先に決めておきます。 ## 1.0を根拠に採用へ動かしてよい条件と、見送りが正解になる現場の線引き ここまでの事実を、採用可否の判断へ落とします。玉虫色にせず、条件を付けて言い切ります。 ### 採用が合理的な条件｜安定表示のAPIだけで書ける推論ホットパスとGPUカーネル 次の3つが揃うなら、1.0の安定宣言は採用の根拠になります。第一に、書く対象が同期的な数値計算へ閉じていること。推論の前処理、特徴量の生成、GPUカーネル、信号処理といった領域です。第二に、使うAPIが安定表示の範囲、もしくは自前で薄くラップできる範囲へ収まること。第三に、ソースからビルドして配置する運用が許されること。 この条件下では、Pythonの資産を残したまま計算部分だけを差し替えられます。どの程度の改善が見込めるかは処理の性質に強く依存するため、着手前に小さな実測を挟んでください。CythonやCodonとの比較実測は[Python高速化の3手法を同一条件で計測した記事](https://www.issoh.co.jp/tech/details/4267/)にまとめてあります。なお同記事は1.0.0b2時点の状況を前提としており、対応プラットフォームや版番号の記述は本記事の内容で上書きして読んでください。 ### 見送るべき場面｜バイナリ配布・長期保守の業務システム・非同期主体のサービス 逆に、次のいずれかへ当てはまる案件では、いまMojoを選ばないほうが結果は良くなります。 - コンパイル済みバイナリやプラグインを配布し、利用側の環境で動的に読み込ませる製品。ABIが安定していないため設計が成立しません - 5年から10年の保守を前提とし、要員の交代が読めない業務システム。1.x系でも破壊的変更は起こりうると明言されています - 接続の多重化と待ち時間の隠蔽が主題のサービス本体。非同期処理が未提供です - Windowsサーバー上で動かす前提の案件。2026年8月時点の対応はmacOSとLinuxが中心で、Windows対応は進行中の段階です - 状態遷移や分岐の記述が中心で、数値計算がほとんど無いロジック層 優先順位を付けるなら、最初のバイナリ配布の条件がもっとも重い。ここへ該当した時点で、他の条件を検討するまでもなく設計が破綻します。 ### 移行と新規採用の見積り｜機械的に直る部分と人手が残る部分の切り分け 0.25系からの移行を見積もるときは、作業を2つに割ります。改名への追随は非推奨エイリアスとfix-itで機械的に進むため、コード量に比例した単純作業として置ける。人手が残るのは、安定表示の無いAPIへの依存箇所の洗い出し、GPU関連の呼び出しをMAX側パッケージへ寄せる整理、そしてABI前提の配布形態を採っていた場合の構成見直しです。最後の項目は設計変更に踏み込むため、工数の読み方が変わります。 新規採用の場合は、Mojoで書く範囲を決める作業が見積りの中心になります。境界の引き方を誤ると、非同期やパターンマッチの不在に後から突き当たり、書き直しが発生する。判断に迷うなら、対象業務のどこへMojoを差し込むかの切り分けから[AI受託開発の相談窓口](https://www.issoh.co.jp/service/ai/development/)でご相談ください。内製と外注の分担の決め方は[AI開発の工程と内製・受託の判断基準を整理した記事](https://www.issoh.co.jp/column/details/13319/)が参考になります。 ## よくある質問 Mojo 1.0の位置づけと移行について、検索されることの多い質問へ答えます。 ### Mojo 1.0にすると既存のコードはそのまま動きますか？ そのままでは動かない箇所が残る状態です。1.0は0.25系までの命名を整理し切った版で、これまでより多くの破壊的変更を含みます。ただし、ほぼすべての変更に非推奨エイリアスが用意され、コンパイラが修正候補をfix-itとして提示するため、改名への追随は機械的に進められます。手が止まるのは、名前を文字列で組み立てているコード生成部分と、GPU関連APIがMAX側パッケージへ移った箇所です。 ### 安定と書かれていないAPIは使ってはいけないのですか？ 使えますが、1.x系のどこかで書き換えが必要になる前提で扱ってください。安定マーカーはAPI単位で付くため、同じ型の中でも保証の有無が分かれます。実務では、安定表示の無いAPIを直接呼ぶ箇所を自前の薄いラッパーへ集約しておくと、変更時の修正範囲がその関数の中だけで収まります。 ### Mojoのコンパイラは誰でも自由に改変・再配布できますか？ 2026年8月18日に公開されたコンパイラとツールチェーンはApache 2.0にLLVM例外を加えたライセンスで、改変と再配布ができます。ただし、外部からのコントリビューションの受付はまだ始まっていません。Modularはコンパイラ側について2026年内の受付開始を目標として示しており、標準ライブラリは2024年から受け付けています。 ### Qualcommの買収でMojoの開発方針は変わりますか？ 買収は2026年7月29日に完了し、Mojo・MAX・Modular Cloudは製品とブランドとして継続すると表明されました。完了の3週間以内に1.0と全ソース公開が続いた事実は、当面の継続を裏づけます。中立性を評価軸に入れる場合は、表明よりも「公開済みのコードは後から取り消せない」というライセンスの性質を根拠に置くほうが確実です。 ### Mojo 1.0はWindowsで動きますか？ 2026年8月時点の対応はmacOSとLinuxが中心で、Windows対応は進行中の段階です。Windows環境で試すならWSL上のLinuxを使う形になります。インストールは`uv pip install --upgrade mojo`で言語側を、GPU向けのAPIを使うなら`uv pip install max[all]`でMAX側を追加します。 ## 関連記事 - [Mojoとは？PythonスーパーセットのAI向け言語をfn・def・所有権・採用判断まで実装視点で解説](https://www.issoh.co.jp/tech/details/15401/)：defとfnの二重構造や所有権モデルなど、言語仕様そのものを扱っています。 - [Cython・Codon・Mojo｜Python高速化の実測比較](https://www.issoh.co.jp/tech/details/4267/)：同一条件での実測値と選び分けの基準を確認できます。 - [オープンソースライセンスとは？主要9種の義務と商用利用の可否](https://www.issoh.co.jp/column/details/3932/)：Apache 2.0の義務と特許条項を条項番号で整理しています。 - [LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説【2026年】](https://www.issoh.co.jp/tech/details/15363/)：計算部分を切り出す際の層構成の考え方をまとめています。 - [AI開発とは？工程・費用相場・内製と受託の判断基準【2026年版】](https://www.issoh.co.jp/column/details/13319/)：言語選定を含む体制と費用の決め方を扱っています。 --- 出典: [Mojo 1.0とは｜安定保証の範囲とApache 2.0公開・1.x移行で壊れる箇所を解説]()（株式会社一創）