2026 年 8 月 11 日、Modular は 26.5 リリースの一環として、Mojo 言語がバージョン 1.0 に到達したと発表しました。経営者にとっての直接的なポイントはこうです。Mojo は購入する製品でも社内にインストールするツールでもなく、すでに使っている AI アプリケーションの下の層で動くプログラミング言語です。Python に近いスタイルで書けますが、CPU、GPU、専用アクセラレーター上で直接動作する高性能なコードにコンパイルされます。1.0 に到達したということは、開発元の企業が言語を安定させ続けることを正式に約束したということであり、その上に何年も使う製品を構築することが賭けではなく合理的な判断になります。皆さんへの影響は間接的ですが現実的です。AI モデルの運用コストは下がり続け、単一のベンダーに全面的に依存するのではなく、自社のインフラ内で AI を動かす選択肢が広がっています。
Mojo が存在する理由：二言語問題
AI システムを構築するチームはどこも、「二言語問題」として知られる古くからの問題に直面します。Python は書くのが速く、読みやすく、AI 分野で最大のツールエコシステムに囲まれているため、研究者や開発者の言語になっています。しかし実行は遅いのです。そこで、パフォーマンスが重要な部分は C++ などの別の言語や専用の GPU プログラミングツールで書かれ、その後 Python に接続し直されます。その結果、システムは二つに分断されます。実験用の簡単な層と本番用の難しい層、スキルの異なる二つのチーム、そしてパフォーマンスを改善するたびに、チームの大半が書けない言語にまで降りていく必要が生じます。Mojo はこのギャップを埋めるために設計されました。Python を知っている人なら誰でもなじみのある構文で、必要な箇所ではメモリとハードウェアを精密に制御でき、それが一つの言語と一つのツールチェーンの中で完結します。
バージョン 1.0 到達が実際に意味すること
ここでのバージョン番号はマーケティングではありません。この言語は 2023 年に初めて登場し、その後何年も急速に変化してきました。名称が変わり、構文が置き換えられ、その上で長期間運用するプロジェクトの保守は繰り返し発生するコストになっていました。バージョン 1.0 は、その段階が終わったことを意味します。1.x サイクル中の変更は主に追加的なもの、つまりすでに構築したものを壊さない新機能になり、互換性を壊す変更は C++ のような成熟した言語と同様に慎重に管理されます。この安定性へのコミットメントこそが、意思決定者にとっての本当のニュースです。
Modular はこのコミットメントを二つの方法で裏付けています。第一に、同社は商用プラットフォーム MAX と Modular Cloud の基盤として Mojo を社内の本番環境で使用しているため、互換性を壊す変更のコストを自ら負うことになります。第二に、周囲に形成されたコミュニティです。標準ライブラリがオープンソース化されて以来、200 人近いコントリビューターが 1,100 件を超えるプルリクエストをマージし、200,000 行以上のコードを変更しました。さらに千人以上が言語の方向性を形作る issue を提出しています。同社はまた、2026 年中に Mojo のコンパイラーやツールチェーンを含むスタックのより多くの部分を段階的に公開することも約束しています。
リリース 26.5 の主なポイント
今回のリリースの作業の大半は整理と統合でした。同じ考えを表現する方法が複数あったところでは、一つに絞られました。変数の宣言は var で一貫して行うようになり、クロージャーは統一され、複数あったポインター型は一つに置き換えられ、いくつかの概念はより正確な名前に変更されました。それに加えて、実用的な追加機能もあります。
- 手軽なインライン関数のための、Python スタイルのラムダ構文のサポート。
- 大幅に安定した言語サーバー。VS Code やその他のエディターでの日々の作業が目に見えて改善されます。
- 参照の無効化に関わるメモリ安全性の問題を言語が診断するようになりました。たとえば、リストへの要素の追加によってそのリストへの既存の参照が無効になる場合に警告します。
- 制約句のより広範で一貫した使用。説明的なメッセージにより、失敗の原因を追跡しやすくなります。
- プロジェクト作成、GPU プログラミング、他言語からの移植をカバーする、すぐに使える AI スキルのセット。
三つ目の点は特に注目に値します。メモリエラーを実行時ではなくコンパイル時に検出するということは、クラッシュやセキュリティ脆弱性の一群全体が、サーバーに到達する前に排除されることを意味します。これこそ、かつてチームに速度と安全性のどちらかを選ばせていたトレードオフであり、Mojo はそれをなくそうとしています。
会社を経営するうえで、言語のバージョン番号がなぜ重要なのか
実務的な理由が三つあります。第一に運用コストです。本格的な製品における AI の請求額は、学習ではなく日々の利用から生じます。モデルをサービングする層での効率改善は、そのまま毎月の支払額、あるいは同じサーバーが処理できるリクエスト数に反映されます。第二に独立性です。オープンモデルを動かすためのツールが成熟するにつれ、二つの選択肢の差が広がっています。一つのベンダーからサービスとして AI を利用するか、自社に合った条件で自社のインフラ上で動かすかです。第三にシステムの寿命です。安定を宣言した言語の上に構築すれば、二年後、三年後の保守コストが下がります。これはどの業務システムの予算においても実際の費用項目です。
もう一つの視点：自社インフラでのモデル運用
同じリリースでは、Modular のモデルサービング基盤である MAX も更新され、二つの新しいモデルファミリー――GLM-5.2 と Nemotron-H――のサポートが追加されたほか、簡素化されたモデル作成の手順を通じて Kimi 2.5 にも対応しました。実際には、オープンモデルを自社のサーバーや自分で選んだクラウドで動かすことがますます容易になり、希少な専門知識もそれほど必要なくなっているということです。これはサウジアラビアでは規制面での重みを持ちます。データが個人データや機微なデータである場合、自社が管理するインフラ内で処理を行うことで、個人データ保護法（PDPL）への準拠が簡素化され、王国外へのデータ移転の複雑さも軽減されます。ツールがコンプライアンスを免除してくれるわけではありませんが、準拠した選択肢を妥当なコストで技術的に実現可能にしてくれます。
今すぐ動くべきか？率直な答え
ほとんどの場合、答えはノーです。これはニュースを軽視しているわけではありません。EC サイト、業務管理システム、モバイルアプリを運営しているなら、Mojo で一行たりとも書き直す理由はなく、違いに気づくこともないでしょう。検討する価値がある場面は具体的です。AI モデルを大量かつ繰り返し運用していて、そのコストが支出の中で目に見える項目になっているとき。大量のデータを狭い時間枠の中で処理しているとき。あるいは応答速度そのものが製品の競争優位になっているときです。それ以外の場合、このニュースは方向性を示すシグナルであり、何かを変えるよう求めるものではありません。
私たちがクライアントのために新しい技術を選ぶ際に適用しているルールはこうです。技術を導入するのは、それが既存の、測定された問題を解決するときであり、新しいからではありません。
最新だからという理由で技術を選ばないでください。数字を把握している費用項目を減らせるから、あるいは今は持っていない能力を手に入れられるから選んでください。
ソフトウェアベンダーに尋ねるべきこと
- 毎月の運用費のうち AI が占める割合はどれくらいで、具体的にどの項目からですか：利用料、ストレージ、それともサーバーですか？
- 私たちのシステムは単一のベンダーにロックインされていますか、それともモデル層は置き換え可能ですか？
- 自社のインフラでオープンモデルを動かす選択肢には何があり、現在と比べてどれくらいのコストになりますか？
- 顧客データは地理的にどこで処理されていて、それは個人データ保護の要件に沿っていますか？
これらの質問はどんな会議でも使え、尋ねるのに技術的な知識は要りません。それでも、その答えから、この変化に対して自社のシステムがどこに位置しているかが正確にわかります。
出典
- リリース 26.5 と Mojo 1.0 に関する Modular の公式発表：modular.com
- Mojo バージョン 1.0 の変更履歴：mojolang.org
- Mojo 言語のロードマップ：mojolang.org/docs/roadmap
- サウジデータ・人工知能庁（SDAIA）――個人データ保護法（PDPL）：sdaia.gov.sa
よくある質問
自社のシステムを Mojo で書き直す必要がありますか？
大多数のケースでは不要です。Mojo はパフォーマンスが重要なコード、特に AI モデルのサービングや大量のデータ処理に特化しています。EC サイト、業務管理システム、モバイルアプリは実際にはそこから何も得られません。AI の運用コストや応答レイテンシーが目に見える費用項目になっている場合に限り、検討を始める価値があります。
Mojo と Python の違いは具体的に何ですか？
Python は書きやすい一方で実行が遅く、そのためチームはパフォーマンスが重要な部分を C++ などの別の言語で書き、それを接続し直す必要に迫られます。Mojo は Python に近い構文と、メモリやハードウェアに対する低レベルの制御を併せ持ち、システムを二つの層と二つのチームに分けるのではなく、全体を一つの言語にまとめることを目指しています。
これはサウジアラビア国内の自社サーバーで AI を運用するのに役立ちますか？
はい、間接的に役立ちます。同じリリースで MAX プラットフォームがサービングできるオープンモデルの対応が広がりました。自社が管理するインフラでオープンモデルを動かすのが容易になるほど、外部での処理への依存は減ります。これは個人データ保護法（PDPL）への準拠を簡素化しますが、コンプライアンス上の管理策そのものを置き換えるものではありません。
比較的新しい言語に頼るのは、プロジェクトにとってリスクですか？
新しい言語の主なリスクは、プロジェクトの足元でルールが変わってしまうことです。1.0 の発表はまさにこの点に対応しており、1.x の変更は主に追加的なものになると約束しています。それでも、エコシステムがさらに成熟するまでは、Mojo をアプリケーション全体ではなくシステムの特化した部分に限定するのが賢明な判断です。
