スライサーのプラグインが OrcaSlicer 2.5 と PrusaSlicer 3.0 に入った — 2つの試用版で何が変わり、何がまだ決まっていないか

3Dプリントのスライサーは長いあいだ、機能を足したければ本体のソースコードに手を入れ、フォーク(分岐版)を保守するしかなかった。その前提が、2026-10-20 時点で2つの試用版で変わりつつある。OrcaSlicer は v2.5.0-alpha(2026-10-16 公開)で Python のプラグイン、PrusaSlicer は 3.0.0-alpha11(2026-09-01 公開)・3.0.0-alpha12(2026-09-21 公開)で Lua のプラグインを入れた。どちらも、本体をフォークせずに自分の機能を足すための仕組みだ。スライサーのプラグインはコードなので、そのコードは AI に書かせることもできる。
※本記事にはアフィリエイト広告(PR)が含まれます。
先に、要点を3つ書いておく。第一に、スライサーのプラグインが「スライサーに初めて入った」わけではない。UltiMaker Cura は Cura 3.4 からマーケットプレイスで Python のプラグインを配っている。新しいのは、Slic3r の系統を引く OrcaSlicer と PrusaSlicer に入ったことだ。第二に、安全の考え方が2つで違う。OrcaSlicer は公式が「許可制(原文 “a permission system, not a sandbox”)」と書き、PrusaSlicer は「サンドボックス」と呼ぶ。第三に、手元の CLI で旧版の v2.4.2 と v2.5.0-alpha のスライス時間を比べると、この PC・この設定・各5回の中央値で、重いモデルほど差が開き、v2.5.0-alpha が 1.14 倍から 2.11 倍速かった。ただし両版とも「alpha」の試用版で、API は変わると公式が明記している。正式版が公開されたら、本記事の数値は更新する。
スライサーのプラグインとは何か、なぜいま動きがあるのか

本記事でいう「スライサーのプラグイン」は、スライサー本体が読み込んで内部で動かす追加のコードを指す。書き出した G-code を外部のプログラムに渡して書き換える「後処理スクリプト(post-processing scripts)」とは、別の仕組みだ。後処理スクリプトは G-code ができた後に外から手を入れる。プラグインはスライサーの中で動く。この区別は後の節でもう一度使う。
プラグインを本体に組み込む利点は、公式のリリースノートの言葉がそのまま説明になっている。OrcaSlicer は「フォークを保守せずにスライサーへ自分の機能を足す、サポートされた方法(原文 “a supported way to add your own features to the slicer without maintaining a fork”)」と書く。PrusaSlicer の公式ブログも「コミュニティがフォークせずにスライサーを拡張できる(原文 “the community can extend the slicer without forking it”)」ことを理由に挙げる。フォークは本家の更新に追従する手間が重い。プラグインなら、本体の更新とは切り離して機能を配れる。
ただし「初めて」ではない。Cura は Python のコードでスライサーの機能を拡張でき(原文 “Plugins extend the functionality of Cura through python code.”)、そのマーケットプレイスは Cura 3.4 から使えると公式 wiki が書く。したがって今回新しいのは、スライサーのプラグインという考え方そのものではなく、Slic3r を源流とする OrcaSlicer と PrusaSlicer という2つの系統に、拡張の口が開いたことだ。
プラグインがコードであることには、もう一つの意味がある。コードである以上、人が一から書くだけでなく、AI に下書きを作らせて人が直す、という進め方ができる。公開されたばかりの API をどこまで AI が正しく扱えるかは、渡す資料のそろえ方しだいで変わる。本記事はその土台として、まず2つの仕組みが何であるかを整理しておく。
OrcaSlicer 2.5.0-alpha の Python プラグイン

OrcaSlicer v2.5.0-alpha は、公式が「OrcaSlicer の歴史で最も機能の詰まった版(原文 “the most feature-packed release in OrcaSlicer’s history”)」と書き、「950 を超えるプルリクエスト、140 人を超える貢献者(原文 “built from more than 950 pull requests by over 140 contributors”)」から作られたとする。その目玉の一つが Python のプラグインだ。
プラグインは「.py ファイル1本か .whl パッケージ」で、Python の実行環境が OrcaSlicer に同梱されるので、別途の導入は要らない(原文 “Plugins run on a Python runtime that ships with OrcaSlicer, so there’s nothing extra to install.”)。公式 wiki はこれを、埋め込みの CPython インタプリタの中で動く、と説明している。
リリースノートが挙げるプラグインの種類は4つだ。
- Script: プラグインの窓や Speed Dial から実行する操作
- Slicing Pipeline: スライスの各段階で動く処理。Process > Others > Slicing Pipeline Plugin(Advanced モード)で選び、スライスした層を読んで編集するか、書き出した G-code を後処理する。公式は「実験的で、プラグインの開発者・テスター向け」と書く
- Pages: 画面にタブを一つ足す
- Resource Texture: Texture Displacement の選択肢に高さ画像のテクスチャを足す
公式 wiki はこれにもう1種類、プリンターとの通信を担う種類(Printer Connection、作業中)を加えて5つとするが、本記事はリリースノートの4種類を基準に数える。公式のサンプルプラグイン(モデルをスライス中にひねる・絞る・揺らす)も付いている。
プラグイン以外にも、v2.5.0-alpha には多くの変更が入っている。公式はベルト式プリンターへの対応、実験的な Design タブ(OrcaSlicer の中の CAD 作業空間、既定では無効)、Bambu Lab の H2C・A2L への対応、IDEX・IQEX での2〜4個の同時造形などを挙げる。ただしこれは試験のための alpha で、いくつかの新機能は正式版までに変わりうる、大事なプロジェクトとプロファイルは先に控えておくように、と公式は注意している。さらに実際の運用で効いてくる点として、プラグインを使うプリセットを、そのプラグインが入っていない PC で開くと、問題が解決するまでスライスのボタンは押せないままになる。配布のしやすさと引き換えに、受け取る側にもそのプラグインが要る、ということだ。
配布は Orca Cloud を通る。コミュニティが公開したプラグインを探し、Orca Cloud のアカウントで購読し、自作を公開すれば誰でも使える(原文 “Publish it on Orca Cloud and anyone can use it.”)。購読にはサインインが要る。なお、Orca Cloud のプラグイン一覧のページは JavaScript で描画され本文を取得できなかったので、公開数・審査の有無・料金については本記事では触れない。
配布ファイルの大きさにも触れておく。Windows の x64 portable 版は、v2.4.2 の 171,367,668 バイトから v2.5.0-alpha の 221,507,287 バイトに増えた。一方で公式は「同梱ファイルの圧縮で、ディスク上の OrcaSlicer は約 74 MB 小さくなった」と書く。ダウンロードする配布ファイルと、インストールした後のディスク上の大きさは別の話だ。増えた理由はここでは推測しない。
OrcaSlicer のプラグインは .py のファイル1本から書ける。AI に下書きを作らせるにしても、ファイルを開いて読み書きする Python の基本が分かっていれば、出てきたコードを自分で読んで直せる。
PrusaSlicer 3.0 alpha の Lua プラグイン

PrusaSlicer 3.0 は内部を作り直した版で、最初の公開 alpha である 3.0.0-alpha11 を公式は「不安定で作り込まれていないはず(原文 “is expected to be unstable and not polished”)」と書く。2番目の 3.0.0-alpha12 は主にバグ修正だ。Prusa の公式ブログは同じ 3.0 を同じ日に「preview」の名で告知しているので、GitHub の「alpha」とブログの「preview」は同じものを指す。
プラグインの言語は Lua だ。Prusa は「Lua を選んだのはサンドボックス化しやすいから(原文 “This is why we chose Lua – the system is more or less designed to be sandboxed”)」と説明する。既定ではサンドボックスの中で動き、HTTP やソケットなどのネットワーク通信はできない。ソースを読むと、Lua に開いているのは base・table・math・string の4つの標準ライブラリだけで、dofile・loadfile・load は消してある(この詳細の扱いは別の記事に譲る)。
いまの Lua プラグインにできることは限られている。公式ブログと API 文書はどちらも、現状のプラグインは「プロジェクトに新しい物体を作る」種類(project.plugin)だけだと書く(原文 “This is first version of Slice Plugin API, providing minimal operations to create new objects in Slicer project.”)。言い換えると、PrusaSlicer の Lua プラグインは、いまは G-code やスライス後の層を書き換えない。その具体例が、3.0.0-alpha11 に同梱された校正用の2つの形だ。温度タワー(Temperature Tower)と Flow タワー(Flow Tower)がどちらも Lua のプラグインとして配られている(ソースは resources/lua/com.prusa3d.slicer.calibration/ の temp_tower.lua・flow_tower.lua、type は “project.plugin”)。ちなみに、内蔵の校正用の形は PrusaSlicer が元祖ではない。公式自身が「SuperSlicer がずっと前に入れ、多くのフォークに広がった(原文 “Built-in calibration prints were added into SuperSlicer long ago, and they had propagated to many other forks.”)」と書いている。
配布の仕組みは準備段階だ。署名つきの zip でプラグインを配れる仕組みと道具(CLI の plugin init・keygen・sign)があり、マーケットプレイスは「テスト中で、近く公開する」とされる。提出物は審査すると書かれているが、3.0.0-alpha12 のリリースノートにマーケットプレイス公開の記述は無い。そのため本記事では「準備中」と書く。
後処理スクリプトについて一つ補足する。書き出した G-code を外部プログラムで書き換える後処理スクリプトは PrusaSlicer 2.x にはあったが、3.0 の alpha では「まだ入っていないもの」の一覧に挙がっており、現時点では使えない。これはプラグインとは別の仕組みなので、混同しないようにしたい。
運用の前提も押さえておく。PrusaSlicer 3.x は、画面を開かない CLI だけの運用もできると公式が明記している(原文 “PrusaSlicer 3.x is still capable of CLI-only operation”)。また、他社のスライサー(Bambu Studio・OrcaSlicer)で作った 3MF は、設定ごとではなく形だけ読み込む(原文 “Third-party 3MF (Bambu Studio, OrcaSlicer): imported as geometry.”)扱いになる。alpha はまだ Prusa 機のプロファイルしか含まず、他社機のプロファイルは後で戻すとされている。つまり、いま試せるのは Prusa のプリンターを持っている人か、自分でプロファイルを作れる人に限られる。
同梱の温度タワーを試すなら、まずは扱いやすい PLA で1本刷ってみるとよい。段ごとの糸引きや表面の違いを見比べやすい。
許可制とサンドボックス — 2つの試用版で安全の考え方が分かれる

OrcaSlicer と PrusaSlicer を比べると、プラグインに対する安全の考え方がはっきり違う。
OrcaSlicer は「許可制」だ。公式は「これは許可の仕組みであって、サンドボックスではない。だから信頼できる出どころのプラグインだけを入れること(原文 “This is a permission system, not a sandbox, so only install plugins from sources you trust.”)」と書く。プラグインが OrcaSlicer のデータフォルダの外のファイルに触れる、ネットワークにつながる、別のプログラムを起動する。この3つをしようとすると、まず利用者に許可を求める。逆に、OrcaSlicer 自身の設定ファイルや Orca Cloud のログイン用トークンは読めない。
PrusaSlicer は「サンドボックス」だ。プラグインは既定でサンドボックスの中で動き、ネットワークにはつながらず、ディスク全般にも触れない(読めるのはプラグインと同じフォルダのファイルだけ)。将来は、信頼した作者やプラグインに利用者が明示的に権限を与えられるようにするかもしれない、と公式は書く。
| 観点 | OrcaSlicer 2.5.0-alpha | PrusaSlicer 3.0 alpha |
|---|---|---|
| 言語 | Python(同梱の CPython) | Lua |
| 安全の呼び方 | 許可制(サンドボックスではない) | サンドボックス |
| 既定の外部アクセス | 使う前に許可を求める | 既定で不可(ネットワーク・ディスク全般) |
| 配布の場 | Orca Cloud で公開済み | マーケットプレイスは準備中、署名つき zip の仕組みあり |
どちらが安全かを一般化はしない。許可の細目や、どちらの仕組みが何を取りこぼすかは、ソースを読んで別に検証する必要がある。ここで言えるのは、OrcaSlicer は「使う前に利用者に聞く」設計、PrusaSlicer は「はじめから外に触れさせない」設計だ、という方向性の違いである。
周辺のスライサーの動き(Cura・Bambu Studio・混色)

プラグインの話から少し離れて、同じ時期のほかのスライサーの動きも押さえておく。
UltiMaker Cura は 5.14.0-beta.1(2026-10-15 公開、試用版の beta)で、サポートを塗って指定する機能(Paint-on-Support)を入れた。設定パネルのタブ表示を既定にした変更は、もともとコミュニティのプラグイン由来だと公式が書いている。細かい変化だが、同じ版では、書き出した G-code の冒頭に、使った CuraEngine のプラグインを記録するようにもなった。何が動いて作られた G-code かを後から追える、という配慮だ。Cura は前述のとおり、以前から Python のプラグインとマーケットプレイスを持ち、マーケットプレイスからの導入にアカウントは要らない。最新の安定版は 5.13.0(2026-05-28 公開)だ。
Bambu Studio は 2.8.4 Public Beta(2026-09-22 公開、試用版の beta)で、テクスチャの取り込みの改善と、上面の単調線インフィルの経路の短縮を入れた。利用者が書くプラグインを読み込む仕組みは、2.8.4 のリリースノートにも、タグのソースのファイル一覧にも見当たらない。ただし、G-code の後処理スクリプトの設定(post_process)はある。なお Bambu Studio の「networking plugin」は通信のための別の部品であって、ここでいうプラグインの仕組みとは違う。最新の正式版は 2.8.2.61(2026-08-21 公開)である。
色を混ぜる機能は、この1年で Bambu Studio 2.5.3(2026-04 公開、実験的機能で公式は単ノズル機には勧めない)、PrusaSlicer 2.9.6(2026-06 公開、ColorMix)、OrcaSlicer 2.5.0-alpha(Bambu Studio から移植)と3社に入った。3つとも、もとはコミュニティのフォーク(OrcaSlicer-FullSpectrum)の考え方だ。
色を混ぜる機能を試すには、複数のフィラメントを自動で切り替えられる機体が要る。
公式は「かなり速くなった」と言う — リリースノートの数値(作者の試験)

OrcaSlicer v2.5.0-alpha のリリースノートは、起動・スライス・G-code の書き出しが「かなり速くなった(原文 “much faster startup, slicing and G-code export”)」と書く。以下の数値は、いずれも公式のリリースノートに載った、作者または独立した試験の値であり、手元の測定とは別物だ。
- 起動は約半分の時間で開く(原文 “OrcaSlicer opens in about half the time.”)
- スライス時間を約 35% 短縮(独立した試験では 40%)
- 3DBenchy で最大 3.7 倍速い
- G-code の書き出しには6つの高速化が入り、作者の試験では最初の4つで書き出し時間を 37.7% 短縮(残りの2つでさらに最大 8%・6%)
- Gyroid のインフィルは、小さな島が多いモデルの通常の Gyroid で最大約 2 倍、Z-buckling の最適化では最大約 10 倍速い。通常の Gyroid の模様そのものは変わらない
- Windows の公式ビルド(x64・ARM64)は MSVC から clang-cl に変わり、作者の試験で、小〜中規模のプロジェクトで 11〜12%、大規模で 29%、スライスと書き出しの時間を短縮した
ここで出てくる 3DBenchy は OrcaSlicer に同梱されるサンプルモデルで、ライセンスは CC0 1.0(出典: 3DBenchy.com)だ。公式はさらに「同じモデルを同じ設定でスライスすれば、毎回同じ G-code になる(原文 “Slicing the same model with the same settings now gives the same G-code every time.”)」と書く。出力は実質同じで、オーガニックのツリーサポートだけはわずかに変わりうるという。
手元の CLI で 2.4.2 と 2.5.0-alpha のスライス時間を比べた

公式が「かなり速くなった」と言うので、手元でも確かめた。OrcaSlicer の CLI(画面を開かずに動かすモード)で、旧版の v2.4.2 と v2.5.0-alpha の所要時間を比べた。測ったのは「スライスだけ」の時間ではなく、CLI を1回動かすのにかかった実時間、つまりプロセスの起動・設定の読み込み・スライス・G-code の書き出しまでを含んだ時間だ。公式が挙げる高速化にも起動の短縮が入っているので、起動を含んだ実時間で比べた。プラグインは使っていない。プラグインは画面側の仕組みで、この比較では動かしていない。
比較の条件
- PC は Windows 11 Pro。この処理は CPU で行い、GPU は使わない
- 版は公式 GitHub の portable 版を展開した。どちらも、ダウンロードした zip の SHA-256 が GitHub の値と一致することを確かめた
- 設定は両版で同一にした。v2.4.2 に同梱の Bambu Lab のプロファイルから継承を展開した、平らな(inherits を含まない)P1S の設定(machine=Bambu Lab P1S 0.4 nozzle、process=0.20mm Standard @BBL X1C、filament=Generic PLA)を、両版に同じ JSON で渡した
- 並べ替えの回転の既定値が版で違う(v2.4.2 は有効、v2.5 は無効)ため、両版に
--arrange 0(配置済み)を明示した - モデルは trimesh で作った箱(60×60×40mm、150×150×100mm)と球(直径120mm)で、両版に同じ STL を渡した。公式が速さの根拠に使う 3DBenchy ではなく、配布条件のはっきりした自作の形を使った
- 各条件を5回ずつ、版を1回ごとに交互に実行した
実際のコマンドは次の形だ。物体は印刷しておらず、CLI を1回動かすのにかかった実時間(起動から書き出しまで)と、スライサーが出した見積りを測っている。
orca-slicer.exe --load-settings "machine.json;process_<pattern>.json" --load-filaments filament.json --arrange 0 --slice 0 --outputdir DIR model.stl
結果(各5回の中央値)
| モデル | インフィル | 版 | 中央値(秒) | 5回の実測(秒) | フィラメント(mm) | 見積り時間 |
|---|---|---|---|---|---|---|
| 箱 60×60×40mm | crosshatch | 2.4.2 | 0.42 | 0.42 0.42 0.42 0.44 0.49 | 13745.56 | 1h 10m 44s |
| 箱 60×60×40mm | crosshatch | 2.5.0-alpha | 0.37 | 0.37 0.37 0.37 0.37 0.38 | 13747.41 | 1h 10m 49s |
| 箱 150×150×100mm | crosshatch | 2.4.2 | 1.96 | 1.94 1.96 1.96 2.00 2.01 | 167055.22 | 12h 49m 29s |
| 箱 150×150×100mm | crosshatch | 2.5.0-alpha | 1.10 | 1.08 1.09 1.10 1.10 1.10 | 167068.20 | 12h 52m 4s |
| 箱 150×150×100mm | gyroid | 2.4.2 | 9.24 | 8.99 9.20 9.24 10.09 10.32 | 163644.15 | 17h 54m 54s |
| 箱 150×150×100mm | gyroid | 2.5.0-alpha | 4.37 | 4.28 4.30 4.37 4.84 5.69 | 163644.16 | 17h 56m 37s |
| 球 直径120mm | gyroid | 2.4.2 | 8.06 | 7.49 7.97 8.06 8.39 8.72 | 68116.03 | 7h 38m 56s |
| 球 直径120mm | gyroid | 2.5.0-alpha | 3.98 | 3.90 3.90 3.98 4.47 4.52 | 68116.09 | 7h 38m 50s |
中央値の比(2.4.2 ÷ 2.5.0-alpha)は、箱 60 の crosshatch で 1.14、箱 150 の crosshatch で 1.78、箱 150 の gyroid で 2.11、球 直径120mm の gyroid で 2.03 だった。重い(gyroid・大きい)モデルほど差が開いている。一方で、フィラメントの使用量とスライサーの見積り時間は、両版でほぼ同一だった(違うのは末尾の桁だけだ)。速くなったのは処理にかかる時間であって、使用量と見積りという結果はほぼ変わらない。ただし G-code の命令列そのものは比較していない(計測スクリプトは統計値だけ取って G-code は消している。実際、箱 60・crosshatch の初回でもファイルの大きさは 2,654,474 バイトと 2,652,922 バイトで違う)ので、「出力が完全に同一」とまでは言えない。公式も「同じ版で同じ設定なら毎回同じ G-code になる」と書くが、これは同じ版での再現性の話で、版をまたいだ同一性を保証するものではない。
もう少し踏み込むと、差がよく開いたのはインフィルが gyroid で、かつモデルが大きい組み合わせだった。crosshatch の小さな箱では中央値が 0.42 秒と 0.37 秒で、その差はわずかしかない。一方で、150mm の箱の gyroid では 9.24 秒と 4.37 秒まで開いた。この向きは、公式が Gyroid のインフィルを「最大約 2 倍速い」と書いているのと合っている(公式の数字は小さな島が多いモデルでの値で、本記事の大きな箱や球とは条件が違う)。どんな造形でも一律に速くなるというより、計算の重い場面ほど効いてくる、という読み方になる。逆に、ごく小さなモデルを一度スライスするだけなら、体感できる差にはなりにくい。
この実測の読み方と、言えないこと
この秒数は「この PC・この設定・各5回の中央値」であって、一般の高速化の倍率として読まないでほしい。差の原因も一つに決めていない。公式は、スライス処理そのものの高速化と、Windows のコンパイラを MSVC から clang-cl に変えたことの両方を挙げている。手元の v2.5.0-alpha はその clang-cl のビルドなので、測った差にはコードの変更とコンパイラの変更の両方が混ざっている。切り分けはしていない。
CLI でプラグインが動くかどうかも、この比較では確かめていない(プラグインを使わずに測った)。OrcaSlicer の CLI の入口のソースにはプラグインの記述が見当たらなかったが、動く・動かないのどちらとも本記事では言い切らない。
比較に使った設定は Bambu Lab P1S のプロファイルだ。同じ機種なら、本記事の見積り時間と手元の造形を見比べられる。
まだ決まっていないこと — alpha 版との付き合い方

ここまでを、2026-10-20 時点の状況として読んでほしい。OrcaSlicer も PrusaSlicer も、プラグインの仕組みは試用版(alpha)に入ったばかりで、公式はどちらも「API はまだ変わりうる」と明記している。OrcaSlicer は「プラグインの仕組みは新しく、その API はまだ変わるかもしれない」と書き、PrusaSlicer は「Lua API は実験的で、ときどき互換性を壊す変更をするだろう」と書く。正式版が公開されたら、本記事の数値と状況は更新する。
試すときの注意も、公式の記載から3つ挙げておく。
- 大事なプロジェクトとプロファイルは、先にバックアップする(OrcaSlicer の alpha はそう促している)。PrusaSlicer の alpha は 2.x と別の設定フォルダ(PrusaSlicer3-dev)を使い、Prusa 機のプロファイルだけを含む
- プラグインは信頼できる出どころから入れる。OrcaSlicer の「許可制」は使う前に聞いてくれるが、サンドボックスではない
- 版を固定して記録する。どちらも試用版で、同じ機能でも版によって挙動が変わりうる
スライサーのプラグインは、まだ仕様が動いている途中の機能だ。それでも、本体をフォークせずに機能を足せる口が OrcaSlicer と PrusaSlicer に開いたことは、スライサーの拡張のしかたを変える。そしてプラグインがコードである以上、次に問えるのは「そのコードをどこまで AI に書かせられるか」だ。OrcaSlicer を無料のスライサーとして薦めた記事(2026年、有料スライサーはもう買うな。無料の「Orca Slicer」が最強である3つの理由(2026-01-29 公開))も、プラグインが入る前に書いたものだ。拡張の口が開いたいま、そこに何を足すかが次の問いになる。
参照
- OrcaSlicer v2.5.0-alpha リリースノート
- OrcaSlicer 2.5.0-alpha リリースノート全文(公式 wiki、速さの数値の出典)
- OrcaSlicer wiki: Plugin Types
- OrcaSlicer v2.4.2 リリース
- PrusaSlicer 3.0.0-alpha11 リリース
- PrusaSlicer 3.0.0-alpha12 リリース
- Prusa 公式ブログ: PrusaSlicer 3.0 Preview
- UltiMaker Cura 5.14.0-beta.1 リリース
- Cura wiki: Plugins And Packages
- Bambu Studio 2.8.4 Public Beta リリース
- Bambu Studio 2.5.3 Public Release
- PrusaSlicer 2.9.6 リリース
- 3DBenchy ライセンス(CC0 1.0)





