macOS 26 Tahoe で動作しないオープンソース交通シミュレータ SUMOを何とか動かす

オープンソースの交通シミュレータSUMOは、最近になって日本でも研究や実務で使う事例が増えてきており、関心が高まっている実感があります。私の講義「交通情報学特論」でも学生向けの実習を行っています。しかしながら、macOSでは、2025年末に登場したTahoeにおいてGUIがうまく動作しないという致命的な問題がありました。この原因を探り、なんとか動かしてみました。

TL;DR（先に結論）

• macOS 26 Tahoe では、SUMO のGUIアプリである sumo-gui / netedit が X11/OpenGL 関連エラーで正常に動作しない。
• 原因は Tahoe で準公式のX11サーバ XQuartz にて OpenGL(GLX/Apple-DRI) が正常に動かないため。glxinfo / glxgears でも同じエラーが出る。
• 対策として MacPorts の Mesa(llvmpipe) ソフトレンダに FOX と SUMO をリンクし直してソースビルドすること。
• この結果、Mac でも再び sumo-gui / netedit が普通に動くようになりました。ソフトレンダなので性能はGPUに劣るが、実用速度です。
• 無保証ですが私がビルドしたバイナリも配布しております。公式版SUMOインストール後にこちらを /Applications にインストールしてご利用ください。

なお、この作業は全般的にClaude Cowork (Opus 4.8)に支援されており、この記事もClaudeが下書きしたものをベースにしています。

症状

macOS 26 Tahoe に公式版として配布されているSUMO（確認時はsumo-1.27.1.pkg）をインストールし、sumo-gui や netedit といったGUIアプリで道路ネットワークデータを開こうとすると、こんなエラーが延々と出ます。

X Error: code 2 major 129 minor 2: BadValue.
xp_destroy_surface: assertion failed: s != NULL
xp_destroy_surface error: 3
X Error: code 161 major 149 minor 5: GLXBadContext.

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  129 (Apple-DRI)
  Minor opcode of failed request:  2 ()
GLXBadContext
xp_destroy_surface: assertion failed: s != NULL
glx: failed to create drisw screen
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
FXApp::openDisplay: unable to open display /private/tmp/com.apple.launchd.xxxx/org.xquartz:0
WIDGET_PROCESS_EVENTS: Failure to acquire window rendering context.

一方で、netconvert（OSMから.net.xml への変換ツール）のような CLI ツールは問題なく動作します。

動作確認した環境

• macOS 26.5.1 (Tahoe) / Apple Silicon (arm64)
  • Intel Mac では動作確認していません
• SUMO 1.27.0
• XQuartz 2.8.5, XQuartz 2.8.6_rc2（安定版ではなく最新のRCでも改善せず）
• MacPorts 2.12.5（Tahoe 用 pkg）
• シェルは zsh

原因：問題は SUMO ではなく XQuartz/OpenGL

XQuartz 標準の GLX テストでも同じエラーが出るため、原因はSUMOではないことが確認できる。

/opt/X11/bin/glxinfo -B

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  129 (Apple-DRI)
  Minor opcode of failed request:  2 ()
  Value in failed request:  0x600003

glxgears も同様に落ちます。Major opcode 129 は Apple-DRI（macOS の直接描画レイヤ）で、ここで OpenGL のコンテキスト／サーフェス作成に失敗していることがわかります。これが直接の原因で、SUMO の GLXBadContext や xp_destroy_surface は、二次的なエラーと考えられます。

調べると、これは既知の問題でした。

• XQuartz #446 — Mesa/GLX issue - macOS Tahoe：Apple-DRI BadValue minor opcode 2 が文字単位で一致。「Sequoia では動いていたのに Tahoe で壊れた」という報告。
• XQuartz #452 / #438：メンテナが "This is a bug in macOS that cannot be addressed directly in XQuartz"（macOS 側のバグで XQuartz では直せない）と Regression ラベルを付与。
• SUMO #17272 — macOS Tahoe: SUMO fails to load the GUI：SUMO 側も原因を XQuartz と特定し、「XQuartz はおそらく直らないだろう」と述べています。

背景としては、Apple が10年以上前から OpenGL を非推奨にしていて、Tahoe でついにこの描画経路が実質的に機能しなくなった、ということのようです。XQuartz 側の公式修正は当面期待できません。

なぜ XQuartz が必要で、なぜ直しようがないのか

SUMO の GUI は FOX Toolkit 1.6 というクロスプラットフォーム GUI ライブラリで作られており、道路ネットワークの描画には FOX の FXGLCanvas（OpenGL キャンバス）を使います。そして FOX は macOS にネイティブの Cocoa バックエンドを持たず、X11(XQuartz) 前提です。だから Mac で SUMO GUI を使うと、

SUMO GUI → FOX Toolkit → OpenGL(GLX) → XQuartz → Apple-DRI → macOS

という経路をたどり、Tahoe で壊れた Apple-DRI に必ずぶつかります。この全体をMac標準のCocoa/Metal にネイティブ移植したり、他のクロスプラットフォームGUIライブラリに移植するのは非現実的。とすると、OpenGL の実装を、CPU ソフトレンダを持つ Mesa(llvmpipe) に差し替えるのが現実的となります。

幸い、Mesa には llvmpipe（CPU ソフトウェアラスタライザ）が同梱されていて、これは Apple-DRI を通らず、X11 へピクセルを転送するだけの経路で動きます。これに FOX と SUMO をリンクすればいい、というのが「何とか動かす」ための作戦です。

解決手順

以下、MesaにリンクしたSUMOのビルド方法を環境構築から説明します。利用するライブラリは MacPorts（/opt/local 配下）を通じて入手します。私は普段 Homebrew（/opt/homebrew）を使っているのですが、Apple Silicon環境ではPATHに気をつければ環境がぶつかることはないそうです。

Step 0. 前提

Xcode Command Line Tools（xcode-select --install）と XQuartz はインストールされている前提です。XQuartzはSUMOの動作時も必要になります。

Step 1. MacPorts を導入

MacPorts の公式から Tahoe 用 pkg を入れます。MacPorts はすべて /opt/local 配下に閉じており、Homebrew やシステムを書き換えません。

sudo port selfupdate

Step 2. 必要なパッケージを入れる

sudo port install \
  mesa +llvm \
  glxinfo glxgears \
  fox xercesc3 proj gdal gl2ps \
  cmake ninja

• mesa +llvm … これが llvmpipe ソフトレンダ。今回の主役。
• fox … 1.6.59（SUMO が要求する FOX 1.6 系）。MacPorts の fox は /opt/local の Mesa GL にリンクされます。
• 他は SUMO の依存とビルドツール。gdal の依存で postgresql18 等も入りますが、自動起動はしないので競合の心配はありません。

Step 3. ビルド用のクリーンなシェル環境を作る

Homebrew や Python venv などが混ざると、CMake が Apple の OpenGL.framework や Homebrew の fox を拾ってしまい、ソフトレンダ化が無効になります。PATH を明示的に組み直します。

# Python venv の無効化。自分の環境では必要でした。
deactivate
# ビルドに関係する環境変数をクリーンに
unset VIRTUAL_ENV PYTHONHOME DYLD_LIBRARY_PATH DYLD_FALLBACK_LIBRARY_PATH
# PATHの再設定
export PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin
hash -r

which cmake fox-config ninja python3   # /opt/local か /usr/bin であること

Step 4. SUMO をソースビルド（Mesa GL 直結）

ここが本番です。

mkdir -p ~/src && cd ~/src
git clone --recurse-submodules https://github.com/eclipse-sumo/sumo
cd sumo
export SUMO_HOME=$PWD

cmake -B build -G Ninja \
  -DCMAKE_EXE_LINKER_FLAGS="-L/opt/local/lib" \
  -DCMAKE_PREFIX_PATH=/opt/local \
  -DCMAKE_IGNORE_PATH=/opt/homebrew \
  -DCMAKE_FIND_FRAMEWORK=LAST \
  -DOPENGL_gl_LIBRARY=/opt/local/lib/libGL.dylib \
  -DOPENGL_glu_LIBRARY=/opt/local/lib/libGLU.dylib \
  -DOPENGL_INCLUDE_DIR=/opt/local/include \
  -DFOX_CONFIG=/opt/local/bin/fox-config

cmake --build build --parallel $(sysctl -n hw.ncpu)

成果物は build/bin ではなく $SUMO_HOME/bin に出力されます。

Step 5. リンク先を必ず確認する

ビルドが通っても安心せず、本当に Mesa にリンクされたかを確認します。

otool -L bin/sumo-gui | grep -iE 'GL|FOX'
otool -L bin/netedit  | grep -iE 'GL|FOX'

こうなっていれば成功です。

/opt/local/lib/libFOX-1.6.0.dylib ...
/opt/local/lib/libGLU.1.dylib ...
/opt/local/lib/libGL.1.dylib ...
/opt/local/lib/libgl2ps.1.dylib ...

Step 6. 実行

# open -a XQuartz （通常はXQuartzは自動起動する）
# export DISPLAY=:0

export SUMO_HOME=~/src/sumo  #ビルド時に設定しているが念のため
export PROJ_DATA=/opt/local/share/proj   # netconvert の proj.db 警告対策

$SUMO_HOME/bin/sumo-gui             # GUIから .sumocfg を開いた時にエラーが出ないことを確認
$SUMO_HOME/bin/netedit

東京都心部のネットワーク（16MB ほどの .net.xml）を開いてみたところ、描画され、車両が走り、拡大縮小・スクロール・ウィンドウのリサイズもすべて問題なし。Apple-DRI / GLXBadContext / xp_destroy_surface も消えました。速度も十分使える速度でしたが、neteditにおいてマウスへの追従にもたつきを感じるなど、ネイティブ実装とは違うとも感じます。

ハマりどころ

一番のハマりどころ：-lGL の解決順

実は最初のビルドでは、otool を見ると GL だけ /opt/X11/lib/libGL.1.dylib（＝壊れた方）を掴んでいました。FOX は /opt/local の Mesa を掴んでいるのに、SUMO 本体が /opt/X11 を掴む、という気持ち悪い状態です。

原因はリンカの検索順でした。SUMO の GUI は GL を OPENGL_gl_LIBRARY（絶対パス指定）ではなく、fox-config が返す -lGL 経由で取り込みます。ところが SUMO は X11 も必要とするので、リンク行に -L/opt/X11/lib も入り、これが -L/opt/local/lib より前に置かれていると、リンカは -lGL を先に見つかった /opt/X11/lib/libGL で解決してしまうのです。OPENGL_gl_LIBRARY を絶対パスで指定しても素通りされます。

解決は、/opt/local/lib を検索の先頭に押し込むこと。

-DCMAKE_EXE_LINKER_FLAGS="-L/opt/local/lib"

これでリンカが -lGL を /opt/local（Mesa）で先に解決するようになり、ビルド一発で Mesa 直結になりました。

（保険）install_name_tool で後から張り替える手も

もし上のフラグが効かない構成だった場合は、ビルド済みバイナリのリンク先を直接書き換える手もあります（再ビルドのたびにやり直しが必要なので最終手段）。

for b in bin/sumo-gui bin/netedit; do
  install_name_tool \
    -change /opt/X11/lib/libGL.1.dylib  /opt/local/lib/libGL.1.dylib \
    -change /opt/X11/lib/libGLU.1.dylib /opt/local/lib/libGLU.1.dylib "$b"
  codesign -f -s - "$b"     # arm64 では署名の付け直しが必須
done

Homebrew と MacPorts の併存

正直、両方入っているのは気持ち悪いですが、 Apple Silicon では実害が出にくいと理解ました:

• プレフィックスが分離（Homebrew=/opt/homebrew、MacPorts=/opt/local）していて、互いのファイルを上書きしない。
• ビルドは PATH を明示再構築＋-DCMAKE_IGNORE_PATH=/opt/homebrew で隔離。
• 生成バイナリは GL/FOX を /opt/local の絶対パスでリンクするので、起動時の PATH に依存しない。
• MacPorts は sudo port load しない限りデーモンを起動しない。

普段使いで混乱を避けたいなら、~/.zshrc で SUMO の場所を明示し、which sumo-gui で公式版と取り違えないようにしておくと安心です。

export SUMO_HOME="$HOME/src/sumo"
export PATH="$SUMO_HOME/bin:$PATH"
export PROJ_DATA=/opt/local/share/proj

限界と注意

• ソフトレンダなので性能は GPU 並みではありません。Tahoe では Apple が OpenGL のハードウェア経路を実質止めてしまった以上、ネイティブ Mac での描画はこれが天井です。とはいえ、東京都心部規模のネットワークでも実用速度で動きました。
• Could NOT find Proj がビルドログに出ますが、これは libproj を直接リンクしていないだけで、GUI 表示やシミュレーション実行には影響しません。OSM からの再投影も、検出済みの GDAL 経由で足ります。
• 当然ながら、SUMO を再ビルドしたら Step 6 の確認はやり直してください（CMAKE_EXE_LINKER_FLAGS を付けていればワンショットで済みます）。
• これは2026年6月時点の状況です。将来 XQuartz / Apple 側で状況が変われば、もっと素直な方法が出てくるかもしれません。

まとめ

「SUMO が動かない」と思って最初は SUMO そのものや .net.xml を疑っていたのが、実は macOS Tahoe が XQuartz の OpenGL を壊したのが真の原因でした。そこで「OpenGL 実装を Mesa ソフトレンダに載せ替える」という方針で私家版のビルドを作成し、何とか動かすことに成功しました。

自分がビルドしたSUMOは、.appとしてパッケージ化し、無保証ですがこちらで配布しています。公式版SUMOインストール後にこちらを /Applications にインストールしてご利用ください。ライブラリ群まで一体としてパッケージ化したので容量は大きくなってしまいましたが、自分でビルドするよりは手軽に使えると思います。FOX のような X11 前提の GUI を使う他のソフト（R の rgl など）でも同種の問題が出ているので、同じ考え方が応用できるはずです。

では、引き続きMacでも交通シミュレーションの研究を続けてください！