2026.10.30 2026.10.30

PrusaSlicer 3.0 の Lua プラグインで校正用の形を作らせる — 同梱の温度タワーを手本に、AI のコードを API の定義で検査する

ゲンキ

3Dプリントの校正用の形——温度タワーやリトラクションの試験塔——は、これまで誰かが作った STL を落としてくるか、スライサーの外のツールで組み立てるものだった。PrusaSlicer 3.0 はその一部を本体に取り込み、校正用の形を Lua のコードで生成する仕組みを入れた。コードである以上、人が書く代わりに AI に下書きを作らせることもできる。本記事は、PrusaSlicer の Lua プラグインで3つの校正用の形（橋の試験片・公差の試験片・高さ目盛りの柱）を claude（claude -p）に書かせ、できたコードを実行せずに、ソースから作った API の定義と照合した記録である。

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

先に結論を書く。版は 3.0.0-alpha12（2026-09-21 公開の pre-release）。資料を何も渡さずに書かせると、AI は3つの課題すべてで、ありそうで実際には存在しない関数を仮定した。一方、alpha12 のソースから作り直した API の定義（参照文書）を渡すと、同じ3課題で照合上の誤りは 0 になった。ただし、このプラグインは PrusaSlicer の中では動かしていない。検査したのは Lua の構文と、関数名・引数・呼び方・表の鍵の照合で、しかも検査器は自作だ。だから「誤り 0」は「自作の検査器が見つけた誤りが 0」という意味で、見逃しもある（下で1件挙げる）。実験は各条件1回なので、以下は「この実行ではこうだった」という記録として読んでほしい。

PrusaSlicer の Lua プラグインはいま何ができるのか
同梱の温度タワーを手本に読む
AI のコードを動かさずに検査する方法
この実行の結果 — 資料なしは「ありそうで無い API」を仮定した
公式の参照文書は版がソースと食い違う
検査でよく出た取り違え — 引数・呼び方・設定名
AI にプラグインを書かせるときに効くこと
参照

忍者AdMax

PrusaSlicer の Lua プラグインはいま何ができるのか

まず、対象を正確にしておく。PrusaSlicer の Lua プラグインは、本体が読み込んで内部で動かす追加のコードだ。書き出した G-code を外部のプログラムに渡して書き換える「後処理スクリプト（post-processing scripts）」とは別の仕組みで、後処理スクリプトは 3.0 の alpha ではまだ使えない。したがって本記事で扱うのは、スライスの前にプロジェクトへ物体を足す側の仕組みである。

プラグインの入れ物は「バンドル」と呼ぶフォルダだ。フォルダの中に manifest.json が無ければ、PrusaSlicer はそのフォルダをプラグインとして読み込まない。マニフェストに必須なのは id・name・version・author・license・min_slicer_version・required_apis の7項目で、description・category などの5項目は任意だ。required_apis の鍵に使えるのは project.plugin だけで、ここに対応する API の最低版を書く。フォルダの中の .lua はすべて読まれるが、プラグイン本体になるのは、グローバルの表 info とグローバルの関数 execute を持つファイルに限られる。どちらかが欠けると読み込みに失敗し、info や execute を local で宣言しても、名前で引けないため見つからない（ソースからの読み取りで、実行して確かめてはいない）。

info の中身にも決まりがある。info.type に使えるのは project.plugin だけだ。info.menu は「/」で区切った階層で、メニューのどこに項目を出すかを決める。利用者が入力する項目（params）は、それぞれ name・label・type・default を持ち、label を省くと name が使われる。type はソースでは string・float・int・bool の4種で、それ以外を渡すと異常終了する。実行のたびに新しい Lua の状態が作られ、そこへ api を登録してからファイルを読み、execute が呼ばれる。execute は表を1つ受け取り、params の name がその表の鍵になる。つまりプラグインは「入力の仕様を info に書き、受け取った値で execute が物体を組む」という形をしている。

置き場所と読み直しの作法も決まっている。バンドルのフォルダを所定の場所に置き、メニューの Plugins -> Rescan で読み直す。一からバンドルを作るときは、CLI の plugin init がテンプレートを写してくれて、このときライセンスの入力の既定は BSD-3-Clause になる。公開のためのマーケットプレイスは準備中だ。言い換えると、プラグインを「作る・置く・読み直す」までの道具は一通りそろっているが、配る場はまだ整っていない。本記事はその手前、つまりコードを書いて正解表と照らし合わせるところだけを扱う。

安全の考え方はサンドボックスだ。ソースを読むと、Lua に開いているのは base・table・math・string の4つの標準ライブラリだけで、dofile・loadfile・load は消してある。os や io のような外部に触れるライブラリは最初から開かれていない。ファイルを読む require も差し替えられていて、プラグインと同じフォルダの「名前.lua」しかたどれない。本記事の範囲では、サンドボックスの要点を「os・io が無い」「同じフォルダのファイルしか読めない」の2点に留める。取り込んでいる Lua は 5.4.8 で、ビルドのハッシュがソースに固定されている。lua.org には 5.4.9 や 5.5 系といった新しい版もあるが、PrusaSlicer が取り込むのは 5.4.8 だ。C++ と Lua をつなぐのは sol2 の v3.5.0 である。

ライセンスも押さえておく。PrusaSlicer 本体は AGPL v3 で、後で手本にする同梱の校正バンドルは manifest で AGPL-3.0-only を名乗る。Lua 自体は MIT ライセンスだ。ちなみに、組み込みの校正用の形が入ったのは 3.0 alpha からで、公式自身が「この面では PrusaSlicer は少し後れていた（原文 “PrusaSlicer itself stayed a bit behind on this front.”）」と書いている。SuperSlicer などには以前からあり、「初めて」や「PrusaSlicer だけ」という書き方は当たらない。公式ブログも、いまのプラグインを「新しいものを場面に足すことが主で、すでにあるものを操作する方向ではない（原文 “The API currently revolves mainly around adding something new to the scene, rather than being able to manipulate what is already there.”）」と書き、「Lua API は実験的で、変わりうる（原文 “The Lua API is now experimental and it is subject to change.”）」とも明記している。だから版と時点を添えて読む必要がある。

同梱の温度タワーを手本に読む

3.0.0-alpha11（2026-09-01 公開）には、校正用の形が2つ同梱された。温度タワー（Temperature Tower）と Flow タワー（Flow Tower）で、どちらもソースに組み込んだのではなく Lua のプラグインとして配られている。場所は resources/lua/com.prusa3d.slicer.calibration/ だ。AI に書かせる課題の手本には、この温度タワー（temp_tower.lua）を使った。手本に選んだのは、温度タワーが「物体を作る・設定を書き換える・G-code を差す」という API の基本の3つを素直に並べているからである。

温度タワーの骨格は、グローバルの表 info と、グローバルの関数 execute の2つだ。info には題名とメニューの位置、そして利用者が入力する項目が並ぶ。既定値は最低 190 °C・最高 230 °C・5 段で、入力の型は整数（int）である。

info = {
  title = "Temperature Tower",
  menu  = "Calibration/Temperature Tower",
  params = {
    {name = "min_temp", label = "Min Temperature", type = "int", default = 190},
    {name = "max_temp", label = "Max Temperature", type = "int", default = 230},
    {name = "steps",    label = "Num Steps",       type = "int", default = 5},
  },
}

（temp_tower.lua からの引用。AGPL-3.0-only。全文は GitHub にある）

段ごとの温度は、最高温から刻みぶんずつ下げていく。刻みは (最高 − 最低) ÷ (段数 − 1) なので、既定値では 10 °C 刻みになり、下の段ほど高温だ。塔の形は同梱の STL を読み込んでいる。各段の数字は、emboss_text で文字の形を作り、負の体積（VolumeType.Negative）として塔から彫る。使うフォントは get_font で名前の一部から探し、見つからなければ既定のフォントが返る。そして段の境目の高さに、温度を変える G-code を差し込む。

local gcode = "M104 S" .. rounded_temp
api.project:insert_layer_custom_gcode(api.project:current_bed(), z + layer_height, gcode)

ここで出てくる api.project:insert_layer_custom_gcode は、ある高さ（print_z）に任意の G-code の文字列を入れる関数だ。温度タワーは「高さごとに温度を変える」ことを、物体を変えずに G-code の差し込みで実現している。差し込みの前には clear_layer_custom_steps で既存の差し込みを消し、二重に入らないようにしている。さらに、インフィルの密度などの印刷設定も書き換えていて、たとえば bed:print_presets():set("fill_density", "15%") のように箱へ値を入れている。設定を書き換える・物体を彫る・G-code を差す、という3つの操作が1本の中に揃っているのが分かる。

もう一方の Flow タワーは、体積流量（mm^3/s）の上限を探す塔だ。既定は 1〜25 mm^3/s・15 段で、高さごとに外周の速度を Modifier の体積で変える。形は同梱の SVG から作り、ノズル径は機体の情報から読む。温度タワーが G-code の差し込みで段を作るのに対し、Flow タワーは Modifier の体積を重ねて段を作る。目的も手段も違うが、どちらも「高さごとに条件を変えた1本の塔」という校正用の定番の形だ。なお、Flow タワーは共有モジュール（note_badge）を require で読み込んでいて、プラグインが複数のファイルに分かれてもよいことを示している。この共有モジュールは info を持たないので、プラグイン本体としては登録されない。

温度タワーは、新しいフィラメントを使い始めるときに一本刷っておきたい形だ。まずは扱いやすい PLA から試すとよい。

ELEGOO PLA+ フィラメント 1.75mm（1kg）

¥1,695 （2026/09/19 09:46時点 | Amazon調べ）

Amazon

＼楽天ポイント4倍セール！／

楽天市場

ポチップ

AI のコードを動かさずに検査する方法

検査の前提を先に書く。当サイトは PrusaSlicer の画面を操作していないので、書かせたプラグインを本体の中で実行していない。「形ができた」「ちゃんと動いた」とは言えない。代わりに、2つのものを用意して静的に照合した。

1つめは正解表だ。Lua に公開されている関数・型・列挙は、ソースの ProjectApi.cpp で登録されている（api["名前"] = …、new_usertype、new_enum の並び）。alpha12 の固定コミットのこのファイルを、公式が文書を生成するときと同じ規則で参照用の stub に戻し、関数・型・設定名を抜き出した。公開されている関数は 32 個——グローバルの api の関数が 17、api.project などのメソッドが 15——で、型は 9、列挙は 1 だった。物体を作る関数（make_cube・make_cylinder など）、プロジェクトに足す api.project:add_object、G-code を差す api.project:insert_layer_custom_gcode、文字を彫る emboss_text は、すべてこの一覧に載っている。設定名は別のファイル（ConfigDefsFDM.cpp と ConfigCommon.cpp）の定義から取り、各名前が「どの箱（Print・Printer・Filament・Object・Volume など）に入るか」も合わせて記録した。設定は、置ける箱が名前ごとに決まっているからだ。

2つめは検査器だ。Python の構文解析器 luaparser（Lua 5.4 の文法に対応した版）でコードを解析し、次を調べる。(1) info の表と execute の関数が所定の形になっているか。(2) api.<名前> が実在し、引数の数が範囲内か。(3) api.project:<メソッド> が実在するか。(4) add_object や emboss_text に渡す表の鍵が、ソース側が読むものか。(5) サンドボックスで開いていないグローバル（os・io・package・debug など、消された dofile・loadfile・load）を使っていないか。手元に Lua の処理系が無いため構文の検査も Python 側で行い、PrusaSlicer が使う 5.4 の文法に合わせた。表で渡す関数に位置引数を並べる、ドットとコロンを取り違える、といった誤りも、この照合で拾える。

検査器が当てになるかは、対照で確かめた。同梱の4本（温度タワー・Flow タワー・共有モジュール・テンプレート）に当てると誤りは 0。わざと8つの誤りを仕込んだ対照のコードに当てると、8つとも検出した。片方で見逃さず、もう片方で過剰に警告しないことを先に確かめてから、本番の課題に進んだ、という順番である。

課題は3つ用意した。いずれも同梱プラグインと重ならない形にしてある。手本を丸写しすれば通る課題では、資料を渡す効果が見えないからだ。

橋の試験片: 台の上に二本の柱を立て、間に水平な板（橋）を渡す。柱の間隔はコードの定数にして変えられるようにする
公差の試験片: 平らな板に、径を少しずつ変えた丸い穴を4つ、負の体積で抜く。穴の径はコードの定数にする
高さ目盛りの柱: 一定の高さごとに表示用の G-code（M117）を差す柱

3つの課題は、校正用の形としても素性のはっきりしたものを選んだ。橋の試験片は、支えのない空間に渡した板がどれだけ垂れるかを見る形だ。橋は温度が高すぎたり速度が速すぎたりすると垂れ下がるので、一般には橋の区間だけ速度と流量を下げると垂れが減るとされる。公差の試験片は、少しずつ径を変えた穴に軸やピンを差して、きつい・ゆるいの境目を探す形で、設計寸法と実寸のずれを一度の造形で読み取れる。高さ目盛りの柱は、ある高さで表示用の G-code が狙いどおりに入るかを確かめる形だ。温度タワーが段の境目で温度を変えるのと同じ「高さごとに何かを変える」仕組みを、文字を差すだけに切り詰めたものになる。いずれも、必要な API が温度タワーと Flow タワーの延長で説明でき、しかも手本の丸写しでは解けない、という具合に選んである。

課題ごとに、資料の渡し方を3条件に分けた。「資料なし」「参照（alpha12 のソースから作り直した API の定義）」「参照＋同梱（温度タワーと Flow タワー）」である。AI はいずれも claude -p。合計9回の実行で、費用は $0.441 だった。どの条件でも作業用のフォルダはホームの外に置き、余計な設定を読み込ませないようにした。

公差の試験片は、穴の径を測って初めて意味を持つ。設計の寸法と実寸のずれを読むには、ノギスが一本あると速い。

ミツトヨデジタルノギス CD-15APX（500-181-30）

¥13,980 （2026/09/19 11:20時点 | Amazon調べ）

Amazon

＼楽天ポイント4倍セール！／

楽天市場

ポチップ

この実行の結果 — 資料なしは「ありそうで無い API」を仮定した

結果は条件できれいに分かれた。

課題	条件	照合上の誤り	この実行で出た取り違え
橋の試験片	資料なし	3	`api.log`・`api.add_object`・`Mesh` を直接生成
橋の試験片	参照（API の定義）	0	なし
橋の試験片	参照＋同梱	0	なし
公差の試験片	資料なし	2	`Mesh` を直接生成・`api.add_object`
公差の試験片	参照（API の定義）	0	なし
公差の試験片	参照＋同梱	0	なし
高さ目盛りの柱	資料なし	3	`Mesh`・`api.add_object`・`api.add_custom_gcode`
高さ目盛りの柱	参照（API の定義）	0	なし
高さ目盛りの柱	参照＋同梱	0	なし

資料なしの3課題は、どれも同じ型の取り違えをした。網目を直接作ろうとする、プレートへの追加を実在しない関数で書く、G-code の差し込みを実在しない関数で書く、の3つだ。具体的には次のような呼び出しを仮定していた。

-- 資料なしで AI が仮定した、存在しない呼び出し（この実行で出たもの）
local m = Mesh.new(verts, faces)     -- 正しくは api.make_cube などで作る
api.add_object(m, "bridge")          -- 正しくは api.project:add_object{ mesh = m }
api.add_custom_gcode(z, "M117 20mm") -- 正しくは api.project:insert_layer_custom_gcode(bed, z, gcode)

いずれも、他のライブラリにありそうな名前で、字面は自然だ。網目の型を Mesh.new のようなコンストラクタで直接作れると思い込み、プレートへの追加や G-code の差し込みも、短くまとまった名前で書いてしまう。実際の API は、網目は api.make_cube などの関数で作り、追加は api.project:add_object に表を渡し、G-code は api.project:insert_layer_custom_gcode に高さと文字列を渡す、という形だ。名前も呼び方も、AI の推測とは少しずつずれていた。

興味深いのは、AI が「API を確認してください」と仮定であることを明記していた点である。確信ありげに捏造したのではなく、「たぶんこうだろう」と断りを付けて書き、その推測が正解表と合わなかった、という形だ。つまり問題は「嘘をつく」ことより「手元に正しい定義が無い」ことにある。

参照を渡した6回は、3課題とも照合上の誤りが 0 だった。同梱プラグインを足しても結果は変わらない。呼び出した API の数自体は課題ごとに違い、高さ目盛りの柱では参照＋同梱の条件で 16 か所まで増えたが、増えても誤りは出なかった。

ただし、この「0」は自作の検査器が見つけた数であって、見逃しもある。実際、公差の試験片のコードは、プラグインの情報の表を local info（局所変数）で宣言していた。PrusaSlicer の実際の読み込みは、この表をグローバルな info として要求するので、本来は不適合だ。検査器はこれを拾えず、0 件のままだった。検査器は、設定名が実在するか、設定に渡す値が決められた列挙のどれか、api.project.add_object のようにコロンでなくドットで呼んでいないか、までは照合していない。言えるのは「この自作の検査器の範囲では、参照を渡すと照合上の誤りが 0 になった」ところまでだ。課題が複雑で呼び出しが増えるほど、資料の有無の差がはっきりする傾向は見えたが、各条件1回なので確率として一般化はしない。

公式の参照文書は版がソースと食い違う

ここに落とし穴がある。「参照を渡せば正しく書ける」と分かっても、では公式の参照文書をそのまま渡せばよいかというと、話はそう単純ではない。本実験で渡した「参照」は、公式が配った文書ではなく、alpha12 のソースから作り直した API の定義だ。理由は、公式の参照文書とソースが食い違っているからである。

公式の API 参照文書は、alpha11 のリリースに添えられた zip（PrusaSlicer-LuaApiReference-3.0.0-alpha11.zip）だけで、alpha12 のリリースには付いていない。しかも zip 内の日時の記録では、中の静的な HTML は 2026-09-02、AI やエディタに読ませるための stub ファイルは 2026-07-07 と、stub のほうが古い。この古い stub は、emboss_text を位置引数の emboss_text(font, text, depth) という形で書き、printer_config や nozzle_diameter といった関数を載せていない。一方、alpha12 のソースでは emboss_text は表を1つ受け取る形で、printer_config も登録されている。実際、alpha12 のリリースノートは「不足していた BedInstRef:printer_config() のドキュメント stub を追加した（原文 “Lua API: added missing BedInstRef:printer_config() documentation stub for the HwPrinterConfig class”）」「emboss_text が depth と font の属性を正しく渡すようにした（原文 “Lua API: emboss_text now correctly passes the depth and font attribute”）」と書く。文書と実装が別々に動いている、ということだ。利用者からも、同梱の Flow タワーが使う printer_config が stub に無い、という報告が出ている。

この zip の中には、AI に関わる一文もある。IDE の設定を説明する頁に「これらの .lua ファイルを使えば、AI エージェントに Prusa Slicer のプラグイン API を学ばせることもできる（原文 “Note: You can also use these .lua files to let your AI agent learn the Prusa Slicer Plugin API.”）」とある。発想は本記事と同じだ。だが渡す先の文書が古ければ、AI は古い引数の形をなぞる。字面が自然なぶん、古い emboss_text(font, text, depth) をそのまま書いても、人は気づきにくい。だから、公式の zip を AI に読ませるなら「版が古く、ソースと一部食い違う」と添える必要がある。

公式の文書の所在も整理しておく。本体の Plugin_API.md は参照先をリンクで示すが、そのリンク（prusa.io/ps-plugins/）は同じ文書の節に戻るだけで、公開された参照サイトには行かない（2026-10-20 時点）。Prusa のヘルプ記事と GitHub の wiki にも、プラグインの頁は見当たらなかった。おまけに Plugin_API.md の表自体も、params の type に string を挙げておらず、マニフェストの任意項目をひとつ取りこぼしている。どちらもソースは受け付けるので、文書だけを頼りにすると「使えるものを使えないと思い込む」ことになる。つまり、いま最も確かな一次情報はソースそのものだ。本実験が参照にソース由来の定義を選んだのは、このためである。

検査でよく出た取り違え — 引数・呼び方・設定名

参照を渡せば照合上の誤りは消えるが、だからといって「どう書いても安全」ではない。実行では表に出にくい取り違えがいくつかある。AI に任せた後で人が見るべき勘所として、4つ挙げておく。

第一に、形を作る関数の引数だ。api.make_cube(width, height, depth) は x・y・z の順で、原点の角から伸びる。注意すべきは2番目の height が Y 方向、3番目の depth が Z 方向であることで、「height だから高さ（Z）だろう」と取ると向きが崩れる。api.make_cylinder の第1引数は半径で、直径ではない。穴の寸法を直径で考えているなら、半分にして渡す必要がある。この種の意味の取り違えは構文としては正しく、静的な照合では引っかかりにくいので、目視で見つけるしかない。

第二に、呼び方だ。グローバルの api の関数はドットで呼び、api.project のメソッドはコロンで呼ぶ。api.project.add_object{…} のようにドットで書くと、自分自身が第1引数に渡らず、呼び方の誤りになる。逆に、api:make_cube(…) のように関数をコロンで呼ぶのも誤りだ。ドットとコロンの違いは Lua に慣れていないと見落としやすく、AI も条件しだいで取り違える。

第三に、設定名と置き場所だ。箱に設定を書き込む box:set(name, value) は、存在しない設定名や置けない箱に渡しても止まらない。ソースを読むと、名前が無ければ何もせず、体積やオブジェクトの設定では見つからない名前をログに出すだけだ。たとえば糸引きの試験片を作ろうとして retract_length を扱う場合、3.0 のソースではこの設定の置き場所は Print で、上書きできるのは Tool と Filament に限られる。Object や Volume では変えられない。つまり、設定の上書きで「柱ごと・高さごとに引き戻し量を変える」ことは、いまの API ではできない。ただし、insert_layer_custom_gcode で高さごとにファームウェア向けの命令（たとえば Marlin の M207 は、ファームウェアの引き戻しが有効なとき引き戻し量を変える）を差し込む道が別にある。この道が狙いどおり効くかはファームウェアに依存し、本実験では確かめていないので、「設定の上書きではできないが、G-code を差し込む方法は未検証」と分けて書く。2.x のヘルプ記事は引き戻しを「Printer Settings -> Extruder 1」で設定すると説明するが、これは 2.x の画面の話で、3.0 の画面のどこに出るかは確認していない。いずれにせよ、set が黙って受け流す以上、「実行すれば誤りがすぐ分かる」とは言えない。静的に照合してはじめて見つかる類いの誤りである。

第四に、列挙値だ。VolumeType は名前（VolumeType.Negative など）で指定する。注釈とソースで値の数が食い違うので、数値で書くのは避けたほうがよい。同じく、同梱の Flow タワーは brim_type に “none” を渡しているが、ソースの列挙値の一覧（no_brim・outer_only・inner_only・outer_and_inner）にこの値は無い。これは「バグ」と断定できる話ではなく——実行していないし、同じ箇所でブリムの幅を 0 にもしている——「ソースの一覧に無い値が渡っている」という事実までだ。手本のコードにこうした食い違いが混じっていることもあるので、同梱を参照に足すときも、そこだけうのみにはできない。

AI にプラグインを書かせるときに効くこと

この実行で言えることと、言えないことを分けておきたい。言えないことから書く。プラグインは PrusaSlicer の中で動かしていないので、形の正しさ・印刷の可否は何も確かめていない。検査は構文と照合だけだ。実験は各条件1回で、正答率のような確率は出していない。API は公式が実験的だと明記していて、正式版までに変わりうる。だから数字は 2026-10-20 時点のこの実行のものとして読んでほしい。

そのうえで、PrusaSlicer の Lua プラグインを AI に書かせるときに効くことは、はっきりしている。鍵は、公開直後の API ほど AI の手持ちの知識が追いつかない、という点だ。資料なしでは、AI は字面の自然な関数名を仮定し、それが外れた。ソース由来の API の定義を渡した瞬間に、照合上の誤りは消えた。したがって実務の順番はこうなる。まず版を固定して、その版のソースから関数・型・設定名の一覧を作る。次にそれを AI に渡して書かせる。最後に、作られたコードを同じ一覧で機械的に照合し、引数の向きや呼び方といった意味の取り違えは人が目で見る。公式の参照文書を使う場合は、それが古い版のものでないかを先に確かめる。

これは、スライサーの設定値を AI に判定させる話(スライサー設定の取り違えを AI に見つけさせる — 素材・温度・プレートの組み合わせを公式プロファイルで試す（2026-10-14 公開）)とも地続きだ。AI に任せる部分を、検証できる形に落とし込めるかどうかが効く。設定名や引数のような「正解が一意に決まるもの」は、ソースから作った一覧と機械的に照らし合わせられる。スライサーと AI の関係をより広く見たい読者には、AI がスライシングにどう入ってくるかを整理した記事(AIスライサー 2026革命 — ニューラルネットワークがG-codeを書き換える時代（2026-04-02 公開）)も合わせて読んでほしい。PrusaSlicer の Lua プラグインは、その関係が「G-code の最適化」から「拡張のコードそのものを書くこと」へ一歩進んだ例だと言える。校正用の形は、その一歩を試すのにちょうどよい題材だった。手本があり、正解がソースに書いてあり、しかも AI の知識がまだ追いついていないからだ。正式版が出たら、本記事の API の定義と結果は取り直す。

AI にコードを書かせ、決めたルールと資料を渡して確かめる進め方は、Claude Code を日常の開発で使うときも同じだ。