2026.10.27 2026.10.27

OrcaSlicer 2.5 の Python プラグインを AI に書かせる — 公開直後の API を、渡す資料でどこまで正しく使えるか

ゲンキ

OrcaSlicer に 2026 年 10 月 16 日、Python でプラグインを書ける仕組みが入った。v2.5.0-alpha というまだ試験段階の版で、公式のリリースにも「プラグインの仕組みは新しく、API はこの先も変わりうる」と明記してある。公開から数日の API は、資料の少なさがそのまま壁になる。プラグインはコードなので AI に書かせられるが、公開直後の名前や引数を AI がどこまで正しく組み立てられるかは、渡す資料によって大きく変わるはずだ。

※本記事にはアフィリエイト広告（PR）が含まれます。

そこで、OrcaSlicer プラグインを claude -p（モデルは claude-sonnet-5-5）に書かせ、ソースから作った正解表と静的に照合した。課題は公式サンプルと目的が重ならない 3 つ、渡す資料は「資料なし」「公式 wiki」「wiki と公式サンプル」の 3 条件で、各条件 1 回ずつ実行した。プラグインは実行していない。OrcaSlicer の画面でも CLI でも読み込んでおらず、判定は Python の構文解析と正解表との静的な照合だけである。結果はすべて 2026 年 10 月時点の、このタグのソースに対するものだ。

先に結果を書く。この実行では、資料なしの 3 本はいずれも、ありもしない API を仮定し（t1・t3 は存在しないモジュール、t2 は実在する orca を読み込んだうえで存在しない関数名）、メタデータも書かず、プラグインとして読み込めない形だった。公式 wiki を渡すと誤りはほぼ消え、wiki と公式サンプルを足すと全課題で誤り 0 になった。一方で、wiki に載っているが廃止された API を wiki 条件がそのまま使い、検査がそれを検出した。公開直後の API は、資料を渡すかどうかだけでなく、渡した資料そのものが版に追いついているかも効く。

OrcaSlicer プラグインは公開直後の仕組みで、資料がないと AI は手探りになる
ソースから作った正解表で、AI のコードを実行せず検査する
3 つの課題を、資料なし・公式 wiki・wiki と公式サンプルで書かせた
資料なしは存在しないモジュールを推測し、wiki でほぼ消えた
公式 wiki に残る廃止済みの API を、AI はそのまま使った
OrcaSlicer プラグインの検査で言えないこと
まとめ — OrcaSlicer プラグインを AI に書かせるなら、資料を渡してから検査する
参照

忍者AdMax

OrcaSlicer プラグインは公開直後の仕組みで、資料がないと AI は手探りになる

OrcaSlicer の v2.5.0-alpha は 2026 年 10 月 16 日に公開された、まだ試験段階（pre-release）の版だ。公式のリリースには「これはテスト用の alpha ビルドで、新機能のいくつかは実験的であり、安定版の前に変わりうる」と書いてある。目玉の一つが Python でプラグインを書ける仕組みで、その API について公式は「プラグインの仕組みは新しく、API はこの先も変わりうる」と念を押している。だから本記事の数値や名前は、この版・この時点のものだと先に断っておく。

プラグインは Python の実行環境を OrcaSlicer が同梱するので、利用者が別に Python を入れる必要はない。配り方は .py 1 本か、.whl のパッケージだ。同梱の Python の版は、ソースのビルド設定では 3.12.13 と書かれている（配布版のバイナリに入っている版は確かめていない）。種類は、リリースノートが Script・Slicing Pipeline・Pages・Resource Texture の 4 つを挙げ、wiki はこれに作業中（WIP）の Printer Connection を 5 つ目として添える。入れたプラグインは、データフォルダの外のファイル・ネットワーク・他のプログラムの起動で許可を求める「許可制（公式の言い方では permission system, not a sandbox）」で囲われる。許可の中身にはここでは踏み込まない。

Python から見える API は、orca という 1 つの埋め込みモジュールと、その下の host・slicing・pages・resource_texture・printer_agent などのモジュールに分かれる。プラグインは、@orca.plugin を付けた orca.base の子クラスを 1 ファイルに 1 つ置き、その register_capabilities の中で capability を登録する、という決まった形で書く。形を具体的に書くと、最小のプラグインはおおよそ次のようになる（公式 wiki の Plugin Development の例をもとにした骨組み）。

# /// script
# [tool.orcaslicer.plugin]
# name = "Sample"
# ///
import orca

@orca.plugin
class SamplePlugin(orca.base):
    def register_capabilities(self):
        orca.register_capability(SampleScript)

ファイルの先頭に要るのは、名前などを収めた PEP 723 のメタデータ（コメントで書くインラインのブロック）だ。開きの行はちょうど「# /// script」、閉じの行はちょうど「# ///」でなければならない。OrcaSlicer が読むのは [tool.orcaslicer.plugin] の name・description・author・version と、ルートに書く dependencies・requires-python だけで、手元から入れる .py は name が無いと読み込みに失敗する。wiki の表では name は「recommended（推奨）」と書かれているが、ソースでは必須だ。type のような他のキーは無視されるだけで誤りではなく、公式サンプルにも残っている。この「別ファイルではなく、.py の中のコメントに書く」という形が、公開直後の仕組みを AI に書かせるときの最初の関門になる。

重要なのは時系列だ。Python プラグインを入れた PR #14530 は 2026 年 7 月 2 日に作られ、7 月 17 日にマージされた。公式 wiki に最初の説明が入ったのも 7 月 2 日である。一方、今回比べた Claude Sonnet 5.5 は、Anthropic のモデル一覧で reliable knowledge cutoff が 2026 年 6 月、Sonnet 5.5 の個別ページでは training data cutoff も 2026 年 6 月になっている。月までしか書かれていないので、本記事ではこれを「知識の締切は 2026 年 6 月」と書く。つまりこの API は、AI の知識の締切より後に公開された。実際この実行でも、資料を渡さなければ AI は今回の API を正しく組み立てられなかった（学習の中に無かったのか、あっても引き出せなかったのかまでは、この実験では分けられない）。これは Agentic Architect の出題範囲の新しい製品を AI はどこまで知っているか — 試験ガイドの 28 項目を公式ドキュメントで照合した（2026-10-20 公開）で扱った「公開直後の製品を AI がどこまで知っているか」と同じ型の問いを、題材をスライサーのプラグインの API に置き換えたものだ。

プラグインは Python のファイル1本から始まる。AI の下書きを読んで直すには、ファイル操作を中心にした Python の基本があると心強い。

退屈なことはPythonにやらせよう第3版（オライリー・ジャパン・書籍）

¥4,620 （2026/10/21 08:17時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

ソースから作った正解表で、AI のコードを実行せず検査する

照合の基準にしたのは、OrcaSlicer v2.5.0-alpha のタグ（コミット 3880f2c、2026 年 10 月 16 日公開）の src/slic3r/plugin 以下で、Python に公開された名前だ。本記事ではこれを正解表と呼ぶ。pybind11 の定義（モジュールを足す def_submodule、クラスの py::class_、列挙の py::enum_、関数やメソッドの .def、定数の .attr）を機械で読み、Python に公開された名前を 726 名（モジュール・クラス・列挙・関数と、メソッドやプロパティなど）抜き出した。モジュールは、頂点の orca と 10 のサブモジュールを合わせて 11 ある（いちばん深い orca.host.preset.bundles で 4 段だ）。名前を手で数えると取りこぼしや重複が避けられないので、ソースから機械で抜き出し、同じコミットに固定して何度でも取り直せるようにした。正解表の信頼性は、記事の結論の信頼性に直結する。

検査のスクリプトはプラグインを実行しない。Python の構文解析（ast）でコードを読み、六つの観点で調べる。第一に、orca から始まる名前が 726 名の中にあるか。第二に、渡しているキーワード引数が pybind11 の宣言（py::arg）にあるか。第三に、PEP 723 の [tool.orcaslicer.plugin] のメタがあるか。第四に、Slicing Pipeline の ctx の属性が実在するか。第五に、@orca.plugin と register_capability の構造が整っているか。第六に、メタデータの dependencies に無い外部モジュールを読み込んでいないか、である。構文解析が通らなければ、そこで 1 件の誤りとして数え、以降の照合はしない。

六つのうち、名前と引数の照合は「存在するものを正しく呼べているか」を見る。残りのメタデータと構造の照合は、そもそも「プラグインとして形になっているか」を見る。手元から入れる .py は、PEP 723 のメタに name が無いだけで読み込みに失敗し、@orca.plugin の付いた orca.base の子クラスが無ければ、どれだけ中身が正しくても OrcaSlicer はそれをプラグインと認識しない。公開直後の API では、関数の名前より前に、この器の決まりを AI が守れるかどうかが結果を大きく分ける。

検査そのものが正しく働くかを、先に二つの対照で確かめた。陰性対照として公式サンプル 6 本を通すと、誤りは 0 だった。陽性対照として、わざと六つの誤りを仕込んだプラグインを 1 本用意すると、検査は六つを全部検出した。正しいコードを誤りと呼ばず、仕込んだ誤りを取りこぼさないことを確かめてから、本番の採点に進んだ。採点の基準を先に固め、検査の正しさを対照で裏づけておくのは、実測の結果を信じるための土台になる。

もっとも、この検査が見るのは「API を正しく使えているか」までで、意味の正しさは見ていない。たとえば断面積の計算が数式として合っているか、座標の単位の変換が正しいかは、名前や引数の照合では判定できない。静的に型を決められない属性（あるオブジェクトのどのメンバーを呼んだか）や、ヘッダーを読まないと引数の数が決まらない関数も、採点の対象から外した。だから以下に出てくる「誤り 0」は、「API の使い方として誤りが見つからなかった」という意味であって、「プラグインとして正しく動く」ではない。

3 つの課題を、資料なし・公式 wiki・wiki と公式サンプルで書かせた

課題は 3 つ用意した。いずれも、公式サンプル 7 本のどれとも目的が重ならないように選んだ。t1 は、スライスの直後に各層の断面積を計算し、最大と最小の層を知らせる Slicing Pipeline のプラグイン。t2 は、プレート上の全オブジェクトを一覧にする Script のプラグイン。t3 は、選んでいるプリセットと 3 つの設定値（layer_height・sparse_infill_density・nozzle_temperature のような設定）をドックパネルに表示するプラグインだ。ドックパネルはメインウィンドウにタブを足す Pages でも開けるが、Script の種類から create_dock_panel で開くこともできる。どちらで実装するかは AI に委ねた。目的は重ねていないが、使う API の一部は重なる。t2 は、プレート上のオブジェクトを並べる点が公式サンプルの dock_panel に近く、t3 は、ドックパネルやプリセットの読み取りの API が dock_panel と inspector に重なる。書き出した G-code を書き換える後処理は、今回の課題には入れていない。

capability の種類によって、コードの入口と動くタイミングが違う。Script は Plugins の画面から手で実行する種類で、UI のスレッドで動く。Slicing Pipeline はスライスの最中に裏のスレッドで呼ばれ、層の輪郭に手を入れられるが、公式はこれを実験的（experimental）な機能と位置づけている。Pages はメインウィンドウに自前のタブを足し、HTML のページとやり取りする。課題は、入口と動くタイミングが違う種類に当たるように選んだ。AI が種類ごとに違う入口（Script の execute、Slicing Pipeline の execute(ctx)）と、種類ごとに必須の上書きを正しく書けるかを見たかったからだ。入口の名前や引数を取り違えれば、そのプラグインはそもそも読み込まれない。なお t3 のドックパネルは、AI がどちらの条件でも Script の execute から create_dock_panel で開く実装を選んだので、この実行で実際に書かれたのは Script（t2・t3）と Slicing Pipeline（t1）の 2 種類だった。

条件は 3 つだ。資料を一切渡さない「資料なし」、OrcaSlicer_WIKI のコミット 0dc4b48（2026 年 10 月 19 日）の Markdown のうちプラグインのページを渡す「公式 wiki」、それに公式サンプルを足す「wiki と公式サンプル」である。渡した wiki は、Plugin Types と Plugin Development、および API リファレンスのうち Printer Agent を除く 8 ページ（Host・Host UI・Slicing・Lifecycle Events・Pages など）の、合わせて 10 本だ。公式サンプルは、リポジトリの sandboxes フォルダにある見本 7 本のうち 6 本（reload_local_bundle_demo を除く）を渡した。渡した資料の分量は下の表の通りで、プラグイン関連の Markdown は全部で 17 本・約 194 KB、公式サンプルは 7 本・約 135 KB ある。公開サイトの wiki は更新が続くので、実験ではこのコミットの Markdown に固定して渡している。

AI は claude -p で動かした。モデルは --model で指定し、出力に記録されたモデルの ID は claude-sonnet-5-5 である。ツール・MCP・設定ファイルを読み込まない最小の構成にし、親フォルダの設定を引き込まないよう、ホームの外の作業フォルダから呼んだ。9 回の呼び出しの合計は 1.889 ドル（記録された total_cost_usd の合計）だった。単価は入力 2 ドル・出力 10 ドル（100 万トークンあたり、2026 年 10 月時点）だが、費用は記録された値で、単価から計算したものではない。課金の扱いは使っているプランで変わるので、目安として見てほしい。

一つ、課題の立て方に落とし穴があった。t1 は「最大・最小の層を知らせる」ことを求めるが、Slicing Pipeline の execute はスライスの作業スレッドで動き、そこから画面の API（orca.host.ui）を呼ぶと、公式の説明ではデッドロックしうる。つまり、課題文をそのまま受け取ると、公式が禁じる呼び出しに近づく書き方になりやすい。正しくは、execute では計算だけして結果を保存し、UI のスレッドで届くライフサイクルのイベント（スライス完了の SlicingJobComplete）で知らせる。ただし、生成されたコードがどちらの書き方だったかは、今回の静的検査の採点項目には入れていない。

claude -p のような非対話の実行は、Claude Code のふだんの使い方の延長にある。設定やルールの渡し方から押さえるなら、次の一冊がある。

Claude Code実践入門［生成AI深掘りガイド］（書籍）

¥3,300 （2026/09/19 12:35時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

資料なしは存在しないモジュールを推測し、wiki でほぼ消えた

課題	条件	渡した資料の文字数	公開 API への参照	誤り	内訳
t1	資料なし	375	3	7	メタ無し 1・存在しないモジュール 1・そのメンバー 3・構造 2
t1	公式 wiki	108,368	16	0	誤りなし
t1	wiki と公式サンプル	226,763	17	0	誤りなし
t2	資料なし	366	0	3	メタ無し 1・構造 2
t2	公式 wiki	108,359	12	1	存在しない名前 1（show_dialog）
t2	wiki と公式サンプル	226,754	11	0	誤りなし
t3	資料なし	400	3	7	メタ無し 1・存在しないモジュール 1・メンバー 3・構造 2
t3	公式 wiki	108,393	10	0	誤りなし
t3	wiki と公式サンプル	226,788	10	0	誤りなし

結果を読む。数はすべて各条件 1 回の実行での値だ。

資料なしの 3 本（t1・t2・t3）は、いずれもプラグインとして読み込めない形だった。3 本とも、存在しないモジュール（AI が作った orcaslicer という名前）や関数を推測で使い、PEP 723 のメタデータも書いていない。構造の誤りも 2 件ずつあり、orca.base を継承した子クラスが無い、capability を orca.register_capability で登録していない、という形だった。AI は「API を確認してください」と仮定を明記していたが、その仮定は外れていた。公開が知識の締切（2026 年 6 月）より後なので、資料なしの条件は AI が知りようのない対照であり、ここは「間違えた」と責める性質のものではない。

公式 wiki を渡すと、誤りはほぼ消えた。t1 と t3 は wiki だけで誤り 0 になり、t2 だけが 1 件残った（次の節で詳しく見る）。wiki に公式サンプルを足すと、3 課題とも誤り 0 になった。orca から始まる参照のうち検査が数えた件数（正しい名前も、存在しない名前への参照も含む）も、資料なしの 0〜3 から、wiki で 10〜16、wiki と公式サンプルで 10〜17 へ増えた。資料を渡すほど、AI は公開直後の名前と引数に手を伸ばし、しかもその多くが正しくなった、と言える。

資料なしと wiki の差は、モデルの賢さではなく入力の差だ。同じモデルに同じ課題を与えても、手元に公開直後の仕様が無ければ、AI は名前を推測で埋め、構造の決まりも外す。逆に、ページを渡しただけで、存在しない orcaslicer のようなモジュールは消え、@orca.plugin と orca.base の形も整った。今回のモデルでは、資料を渡すほど検査が見つける誤りが減った（モデルの強さを変えて比べたわけではないので、言えるのはここまでだ）。公開直後の API を AI に扱わせるときは、まず公開されている資料を手元にそろえて渡す意味が大きい、という読み方ができる。ここで渡したのは検索結果の要約ではなく、固定したコミットの一次資料そのものである点も効いているだろう。

一点、補っておく。t1 のようなスライス中の処理は、公式 wiki が説明していない名前を要することがある。wiki にはスライス中の Print・PrintObject・Layer といった型の説明も、座標を mm に直す unscale も載っていない（2026 年 10 月時点、grep で確認した）。一方、t3 の Pages は wiki に例（スライスの記録を出すページの見本）があるので、wiki の条件で手本に近いものを引ける分だけ有利になりうる。それでもこの実行では、wiki 条件でも t1・t3 ともに誤りは 0 で、AI は渡された範囲の名前で課題を組み立てていた。wiki に無い名前があること自体は、wiki を渡す条件の弱点になりうるが、今回それが誤りとして表面化することはなかった。

公式 wiki に残る廃止済みの API を、AI はそのまま使った

t2 の公式 wiki 条件に残った 1 件は、orca.host.ui.show_dialog という名前だった。これは AI が作った存在しない関数ではない。公式 wiki の Host UI のページに、モーダルの HTML ダイアログを出す関数として今も例が載っている。ところが、v2.5.0-alpha のソースには show_dialog が無い。2026 年 7 月 17 日のコミットで show_dialog は廃止され、create_window の引数（style や on_submit）に置き換えられていた。wiki が版を分けておらず、廃止前の記述が残っていたために、AI はそれをそのまま引き写したのである。

同じ型の食い違いがもう一つある。wiki の Host のページには orca.host.app_language() という関数の例があるが、これも 2026 年 10 月 10 日のコミットで削除され、app_info に置き換えられた。今回の t2 の wiki 条件で実際に現れたのは show_dialog だけだったが、公式資料を渡しても、その資料自体が版に追いついていなければ、AI は古い名前を引き写す。これは資料なしの「知らない名前を推測する」誤りとは別の種類なので、採点でも「wiki 由来の誤り」として分けて数えた。検査はこの show_dialog を、726 名の正解表に無い名前として機械的に検出している。

ここから読める実務の注意は 2 つある。第一に、AI が公式資料を根拠に書いたコードでも、その資料が古ければ廃止済みの API が紛れる。資料を渡せば安心、ではない。第二に、だからこそソースから作った正解表との照合が効く。wiki を読んだだけの人間も同じ罠にかかるが、公開された名前の一覧と機械的に突き合わせれば、廃止済みの名前はその場で浮かび上がる。公開直後の API ほど、資料とソースのずれは起きやすい。alpha の版では API が変わりうると公式が書いているとおりで、名前の廃止と置き換えが短い間に続く。

AI の出力を正解表と機械的に突き合わせる考え方は、LLM を使うアプリの評価全般に通じる。評価の組み立てを体系的に知りたい人向けに挙げておく。

LLMアプリケーション評価駆動開発継続的に改善し運用していくための実践知

¥3,960 （2026/09/22 14:35時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

OrcaSlicer プラグインの検査で言えないこと

結果を読むときの限界を、まとめて書いておく。

各条件 1 回の実行: 3 課題を 3 条件で 1 回ずつ書かせただけだ。同じ課題を繰り返したときに答えがどれだけ揺れるかは測っていない。数はすべて「この実行ではこうだった」という値で、一般化できるものではない。
実行していない: プラグインは OrcaSlicer の画面でも CLI でも読み込んでいない。判定は Python の構文解析と、ソースから作った正解表との静的な照合だけだ。「動いた」「読み込めた」「スライスできた」ことは、何一つ確かめていない。
意味の正しさは見ていない: 検査が見るのは API を正しく使えているかまでで、断面積の計算や座標の単位の変換が合っているかは判定していない。誤り 0 は「API の使い方に誤りが見つからなかった」であって、プラグインとして正しく動く保証ではない。
モデルは 1 つ、構成は最小: claude-sonnet-5-5 を、ツールも検索も使えない構成で動かした。ほかのモデルや、ウェブ検索を使える構成では試していない。
スライスや書き出しを起こす API: v2.5.0-alpha のソースで Python に公開された名前を調べた範囲では、プラグインからスライスや G-code の書き出しを始める関数は見当たらなかった（3MF のコピーを書く export_3mf_copy はある）。これは「無い」ことの証明ではなく、「公開された名前の一覧に無かった」という結果だ。
確かめていないこと: 配布版のバイナリに入っている Python の版、公式サンプルがアプリに同梱されるか、プラグインそのものに AGPL の義務が及ぶかは確かめていないので、書かない。
alpha である: API は変わりうると公式が明記している。安定版が出れば、ここでの名前や引数は動きうる。本記事の結果は、あくまで 2026 年 10 月時点のこのタグのソースに対するものだ。

まとめ — OrcaSlicer プラグインを AI に書かせるなら、資料を渡してから検査する

OrcaSlicer の v2.5.0-alpha（2026 年 10 月 16 日公開）に入った Python プラグインは、AI の知識の締切（2026 年 6 月）より後に公開された API だ。この実行では、資料を渡さないと AI は今回の API を正しく組み立てられなかった。
この実行では、資料なしの 3 本はいずれも、ありもしない API を仮定し（t1・t3 は存在しないモジュール、t2 は実在する orca を読み込んだうえで存在しない関数名）、メタデータも書かず、読み込めない形だった。公式 wiki を渡すと誤りはほぼ消え、wiki と公式サンプルを足すと全課題で誤り 0 になった。
ただし、公式 wiki に載っていて v2.5.0-alpha のソースには無い show_dialog を、wiki 条件がそのまま使った。公式資料を渡しても、その資料が版に追いついていなければ、廃止済みの API が紛れる。
だから、OrcaSlicer プラグインを AI に書かせるなら、公開直後の公式資料を渡したうえで、ソースから作った正解表と機械的に照合する。渡した資料と公開されている名前のずれは、人間が読むだけでは気づきにくい。設定値そのものの取り違えを AI に見つけさせる話はスライサー設定の取り違えを AI に見つけさせる — 素材・温度・プレートの組み合わせを公式プロファイルで試す（2026-10-14 公開）で扱った。プラグインのコードも設定値も、AI に任せきりにせず、公開された正解と突き合わせる手を自分の側に持っておきたい。