LLM G-code最適化：大規模言語モデルが書く「人間より速い」ツールパス

さらに、あなたのスライサーが吐き出すG-codeは、本当に「最適」だろうか。答えはほぼ確実にノーだ。また、Cura、PrusaSlicer。OrcaSlicer――どの主要スライサーも。ルールベースのアルゴリズムでツールパスを生成している。特に、トラベル移動の順序はヒューリスティクスで決定され。リトラクション設定はジオメトリに関係なく静的に適用される。結果として、不要なストリンギング、非効率なトラベル経路。具体的には、一律のリトラクション距離が、印刷時間と品質の両方を蝕んでいる。

LLM G-code最適化という新しいアプローチが、この構造的問題に切り込む。実際に、大規模言語モデルは数百万行のG-codeコーパスから「製造言語」のパターンを学習済みだ。トラベル経路の再配置、セグメント別のリトラクション予測。加えて、Klipperファームウェアとのマクロ連携――これらを組み合わせることで。スライサーが出力した「デフォルトG-code」を。なお、コンテキストアウェアに後処理最適化できる。

LLM G-code最適化の全体像

本稿では、LLM G-code最適化の全体像を解説する。つまり、スライサーの限界構造から、LLMによるG-code解析の技術的根拠。Claude Code × Klipperの実践パイプライン。そしてベンチマーク結果まで。その結果、あなたのプリンターが持つ本来の性能を引き出すための。具体的なワークフローを提示する。

G-codeの「手動チューニング」が限界を迎えた理由

そのため、G-codeはCNCマシンの時代から続く、逐次命令型の製造言語だ。G1 X100 Y200 F3000のような単純な座標移動命令の集合体であり、1行1行が物理的なノズルの動きに直結する。一方、FDM 3Dプリンターにおいて。典型的なベンチマークモデル（Benchy）のG-codeは約120万行に達する。したがって、スライサーはこの膨大な命令列を、数秒で自動生成する。

しかし、「自動」と「最適」は同義ではない。現行スライサーのツールパス生成には、構造的な限界が3つある。

たとえば、第一の限界：トラベル移動の非最適性。 スライサーは各レイヤーの印刷順序を決定する際。ちなみに、隣接する領域間のトラベル（非押出移動）を最小化しようとする。だが、この最適化は基本的にレイヤー単位の貪欲法（Greedy Algorithm）であり。とりわけ、グローバルな最適解を保証しない。あるレイヤーでトラベルを短縮した結果。さらに、次のレイヤーでZ継ぎ目の位置がずれるといったトレードオフが発生する。実測では、デフォルトのトラベル経路は理論的最短経路と比較して15～30%長いケースが報告されている。

最適化の複雑性が生む課題

また、第二の限界：リトラクション設定の静的性。 リトラクションは。トラベル移動時にフィラメントを引き戻してストリンギングを防止する機構だ。しかし、最適なリトラクション距離と速度は、ジオメトリ。材料、温度、トラベル距離によって変わる。特に、短い0.5 mmのトラベルに6 mmのリトラクションを適用するのは過剰であり。印刷時間の無駄だ。逆に、長い30 mmのトラベルに同じ6 mmでは不足する場合がある。具体的には、現行スライサーでは、この設定は全セグメント一律だ。

スライサーの構造的な制約

第三の限界：コンテキストの欠如。 実際に、G-codeの各命令は独立した座標移動として記述されるが。実際の印刷品質はコンテキストに強く依存する。加えて、直前のセグメントが高温のオーバーハングだったのか。冷却済みのインフィルだったのか。なお、隣接するウォールとの距離はどれだけか。こうした文脈情報はG-code自体には記録されておらず。つまり、スライサーの最適化ロジックも限定的にしか考慮しない。

OrcaSlicer 2.3.1 Alphaのレビュー記事で解説した適応型インフィルやFuzzy Skin Paintingは、スライサー側の進化として注目に値する。しかし、それらも「G-code生成前のパラメータ最適化」であり。その結果、「生成済みG-codeの後処理最適化」とは根本的にアプローチが異なる。

この3つの限界は、G-codeが「ルールベースで生成され。そのため、手動でチューニングされる」という前提から生じている。そして、まさにこの前提をLLMが覆しつつある。

パラダイムシフト――LLMが「製造言語」を理解する

大規模言語モデルがG-codeを「理解」できるという主張は。一方、一見すると突飛に聞こえる。しかし、G-codeの構造を冷静に分析すると。LLMとの親和性の高さが見えてくる。

G-codeはトークン化可能な構造化テキストである

したがって、G-codeは、自然言語とプログラミング言語の中間に位置する。各行はG1（直線移動）、G28（ホーミング）、M104（温度設定）といった命令コードで始まり、X, Y, Z, E, Fのパラメータが続く。たとえば、この構造は、LLMのトークナイザーにとって非常に解析しやすい。

実際に、Claude 3.5 SonnetやGPT-4を使ってG-codeの解析を試みると。モデルは以下の能力を安定的に示す。

• 命令の意味理解: G1 X10 Y20 E0.5 F1800が「XY座標(10,20)に向かって0.5 mmのフィラメントを押し出しながら、1800 mm/minの速度で移動する」という意味を正確に解説できる
• パターン認識: リトラクション→トラベル→プライム（リトラクション解除）の典型的なシーケンスを識別し、異常なパターン（二重リトラクション、リトラクションなしの長距離トラベルなど）を検出できる
• 最適化提案: 「この3箇所のトラベル移動は、順序を入れ替えることで総移動距離を12%削減できる」といった具体的な改善提案を生成できる

研究動向：LLMと製造プロセスの融合

ちなみに、LLMの製造分野への応用は。2024年から2025年にかけて急速に研究が進んでいる。とりわけ、具体的な成果を持つ研究を確認しよう。

LLM-3D Print（カーネギーメロン大学、2024年）。 Yayati Jadhavらが発表したこの研究（arXiv: 2408.14307、Additive Manufacturing誌掲載）は、マルチモーダルLLMエージェントがFDM印刷をリアルタイムで監視・制御するシステムだ。G-codeファイルをアップロードし、各レイヤー完了後にカメラ画像を解析。また、押出不良やストリンギングを検出して自律的にパラメータを補正する。正方形ジオメトリでピーク荷重容量が5.06倍に向上、六角形で1.60倍、オーゼチック構造で2.46倍という結果が報告されている。特に、ファインチューニング不要で。インコンテキスト学習のみで動作する点が注目に値する。

オープンソースの取り組み

FDM-Bench（2024年）。 LLMのG-code解析能力を体系的に評価した初のベンチマーク（arXiv: 2412.09819）では、G-code異常検出タスクにおいてGPT-4oが62%、Claude 3.5 SonnetとLlama-3.1-405Bがともに44%、Llama-3.1-70Bが31%の精度を記録した。パラメータ規模が大きいモデルほど精度が高い傾向が確認されている。

実際に、G-code再コンパイル最適化（デラウェア大学、2020年）。 Xiaoming Liの研究（LCPC 2020）は、G-codeを高レベル中間表現に再コンパイルし、物理・グラフィクス駆動の最適化を適用するアプローチだ。複雑なモデル（Medieval Castle）で16時間以上の短縮、最大10%の速度向上を達成した。

産業界での実装事例

機械学習G-code最適化（MDPI、2024年）。 K-meansクラスタリングでG-codeパラメータ（温度、速度、フロー）を最適化する手法（MDPI Engineering Proceedings）では、3DBenchyを含むテストで平均24.36%の印刷時間削減と5%の材料節約を達成している。

重要な留意点として。つまり、LLMによるG-code最適化はまだ「実験的ワークフロー」の段階にある。上記の研究はいずれも査読付き論文として発表されているが。その結果、商用プロダクトとして確立されたものではない。本稿で紹介するのは、現時点で技術的に可能なアプローチであり。そのため、誰でもすぐに再現できるパイプラインだ。

LLMの強みと限界

LLM G-code最適化が特に有効な領域と、限界がある領域を明確にしておこう。

有効な領域：
– トラベル経路の再配置（巡回セールスマン問題の近似解として）
– リトラクションパターンの異常検出と修正提案
– Z継ぎ目位置の最適化提案
– 冗長なG-codeコマンドの削除（温度設定の重複など）
– Klipperマクロへの変換と条件分岐の追加

限界がある領域：
– 物理シミュレーション（熱伝導、応力解析）はLLMの守備範囲外
– 大規模G-code（数百万行）の一括処理はコンテキストウィンドウの制約を受ける
– 数値精度が求められる座標計算は、専用の数値計算ライブラリに委ねるべき

実践チュートリアル：Claude Code × Klipper G-code最適化パイプライン

理論を実践に落とし込もう。したがって、ここでは。Claude CodeとKlipperファームウェアを組み合わせたLLM G-code最適化パイプラインの構築手順を示す。

前提環境

• 3Dプリンター: Klipper対応機（Voron、Ender-3 + Klipperなど）
• Klipperホスト: Raspberry Pi 5 8GB（Moonraker API経由でのリモート制御）
• LLMツール: Claude Code（Claude Pro サブスクリプション）
• スライサー: OrcaSlicer（G-code出力元）

ステップ1：G-codeのセグメント分割

スライサーが出力したG-codeファイルを、論理的なセグメントに分割する。たとえば、LLMのコンテキストウィンドウには限りがあるため（Claude Opus 4.6で100万トークン。ベータで200万トークン）。レイヤー単位またはオブジェクト単位での分割処理が有効だ。

Klipperの[gcode_macro]機能を活用し、レイヤー変更コメント（;LAYER_CHANGE）をトリガーとしたイベントフックを設定する。Moonraker APIの/printer/gcode/scriptエンドポイントを通じて、プログラマティックにマクロを実行できる。

ステップ2：トラベル経路の最適化

とりわけ、分割したG-codeセグメントをClaude Codeに投入し。トラベル移動のパターン分析を行う。具体的には以下のプロンプト戦略が有効だ。

1. 抽出: G-codeからトラベル移動（G0またはG1でE値なし）のみを抽出
2. 分析: 各トラベルの始点・終点座標と距離を計算
3. 最適化: 隣接するトラベル移動の順序を入れ替え、総移動距離を最小化
4. 検証: 印刷順序の変更が品質に悪影響を与えないか（冷却時間の確保など）を確認

さらに、トラベル経路の最適化は。本質的には巡回セールスマン問題（TSP）の変種だ。LLM単体で厳密な最適解を求めることは困難だが、ヒューリスティクスの提案と。また、Pythonスクリプトとの連携による数値最適化の組み合わせは実用的だ。Claude Codeは、分析結果に基づいてPythonスクリプトを自動生成し、scipy.optimizeやor-toolsを使った経路最適化を実行できる。

ステップ3：セグメント別リトラクション予測

特に、LLMの最も価値ある応用の一つが。「コンテキストアウェアなリトラクション設定」だ。具体的には、G-codeの各トラベルセグメントについて。以下の情報をLLMに提供する。

• トラベル距離
• 直前のセグメントの温度と速度
• 直前のセグメントがウォールかインフィルか
• 隣接する構造物との距離

これらのコンテキスト情報に基づき。実際に、LLMはセグメントごとに最適なリトラクション距離と速度を提案する。例えば、「短距離トラベル（2 mm未満）でインフィルからインフィルへの移動であればリトラクション不要」「長距離トラベル（10 mm以上）でウォール付近への到着時はリトラクション距離を8 mmに増加」といった条件分岐を生成する。

加えて、この条件分岐をKlipperのマクロに変換すれば。ファームウェアレベルでの動的リトラクション制御が実現する。

ステップ4：Klipperマクロへの変換

Claude Codeは、最適化結果をKlipperの[gcode_macro]形式に自動変換できる。Klipperのマクロシステムは、Jinja2テンプレートエンジンを採用しており、条件分岐（{% if condition %}）やループ（{% for item in list %}）を記述できる。

つまり、Moonraker APIを通じて。最適化されたマクロをKlipperの設定に動的に注入し。その結果、印刷ジョブごとにカスタマイズされた最適化を適用する。このワークフロー全体を、Claude Codeのエージェンティック実行で自動化できる点が、AIコーディングエージェント比較記事で解説した「自律実行」の実践例だ。

ステップ5：フィードバックループ

そのため、最適化の効果を定量的に評価するため、以下の指標を計測する。

• 印刷時間: 最適化前後のG-codeシミュレーション（--estimate-timeオプション）
• トラベル総距離: 非押出移動の合計距離
• リトラクション回数: 不要なリトラクションの削減数
• ストリンギング: 実際の印刷物の目視検査（最終的な品質判断）

計測結果をフィードバックとしてLLMに提供し、最適化戦略を反復的に改善する。一方、この能動学習ループにより、プリンター固有の特性（ボーデンチューブの長さ。ダイレクトドライブの応答性など）を学習し。したがって、パーソナライズされた最適化が可能になる。

ベンチマーク：AI最適化 vs 手動チューニング vs デフォルト出力

既存の研究成果から。たとえば、AI/MLベースのG-code最適化がもたらす効果を整理する。

ベンチマーク結果の一覧

印刷品質の評価結果

数値データの比較

注目すべきは、AI温度最適化の研究（ASTRJ 2024）で。ちなみに、AIがM104コマンド（温度設定命令）を3回から30回に増加させ。サイクリックな温度変動を導入した点だ。とりわけ、層間接着力を向上させるために。レイヤーごとに温度を微調整するというアプローチは。人間のチューニングでは到達しにくい発想だ。

さらに、手動チューニングは、経験豊富なユーザーであれば高い品質を実現できるが。モデルごとに30分から2時間以上の設定時間を要する。また、LLM最適化は、初回のパイプライン構築に時間がかかるものの。一度構築すれば自動実行できる点で、再現性とスケーラビリティに優れる。特に、FDM-Benchの結果が示すように。GPT-4oのG-code異常検出精度62%は完璧からは程遠いが。具体的には、「人間が見落とす非効率を機械的にスキャンする」という用途には十分実用的な水準だ。

ツールパスAIのエコシステムと今後の展望

LLM G-code最適化は、より広いエコシステムの中に位置づけられる。

Bambu Labの「AIスライシング」――センサー自動化とLLMの違い

実際に、Bambu Studioは。マイクロLidarやエディカレントセンサーを使った自動フロー較正（Pressure Advance K値の自動算出）をプリンター側に実装している。しかし、これは「AI」と銘打たれているものの。加えて、実態はセンサー計測値に基づく決定論的なキャリブレーションだ。深層学習やLLMは関与していない。なお、G-code生成前のパラメータ最適化であり。G-code自体の後処理最適化とは根本的にアプローチが異なる。つまり、Bambu Labの強みはハードウェアとソフトウェアの垂直統合にあり。LLMベースの後処理とは相互補完の関係にある。

JusPrin――初のGenAIスライサー

その結果、Obico（旧The Spaghetti Detective）チームが開発したJusPrinは。OrcaSlicerベースの初のGenAI 3Dプリンティングアプリだ。そのため、自然言語で印刷意図を伝えると。LLMがスライシングパラメータを自動選択する。薄い壁や背の高い構造を検出してブリムを自動追加し。一方、失敗リスクの高いジオメトリに対してレイヤー高さを自動調整する。2025年時点でベータ版（AGPL。したがって、Windows/Mac対応）であり、精度データは未公表だが。「LLMがスライサー設定を決定する」という方向性は。たとえば、G-code後処理最適化と並ぶもう一つのAI活用アプローチとして注目に値する。

Klipper v0.12.0とMoonraker――LLM連携の最適基盤

Klipperファームウェアは2025年4月にv0.13.0をリリースし。ちなみに、スイーピング振動レゾナンステスト。Jinja2フォーミュラテンプレート。とりわけ、アダプティブベッドメッシュなど、拡張性を高める機能が追加された。そのオープンソースかつ拡張性の高いアーキテクチャにより。さらに、LLM連携の最有力候補だ。

Moonraker APIは、HTTP RESTとJSON-RPC over WebSocketの二つのプロトコルを提供し、/printer/gcode/scriptエンドポイントから任意のG-codeを注入できる。PythonライブラリのMoonrakerPyを使えば、printer.send_gcode('G28 X')のような直感的なコードでプリンターを制御可能だ。

家庭用ダークファクトリーの記事で解説したように、KlipperとRaspberry Pi 5の組み合わせは、自律的なプリントファーム運用の基盤として確立されつつある。特に、LLM G-code最適化は。このスタックに「知的なツールパス最適化レイヤー」を追加するものだ。

将来の可能性

具体的には、今後の発展として、以下の方向性が考えられる。

リアルタイム最適化: 現在のアプローチは印刷前の「バッチ最適化」だが、将来的にはKlipperのインプットシェーパーと連携し、印刷中にリアルタイムでG-codeを修正する可能性がある。実際に、Raspberry Pi 5の処理能力（Cortex-A76クアッドコア。2.4 GHz）は、軽量な推論モデルの実行には十分だ。Klipperの[delayed_gcode]マクロにより、印刷中にスケジュールされたG-code実行が可能な基盤はすでに整っている。

マルチマテリアル最適化: AMS（Automatic Material System）搭載機では、材料切り替え時のパージ量とトラベル経路の同時最適化が課題となる。なお、LLMは、材料特性（溶融温度、粘度。リトラクション特性）を考慮した切り替え戦略を提案できる。

技術的課題と展望

コミュニティ駆動の最適化データベース: 最適化結果をコミュニティで共有し、プリンター機種×材料×モデル形状の組合せに対する最適化パターンのデータベースを構築する構想だ。LLMはこのデータベースを参照し、類似条件での最適化経験を転用できる。その結果、ORNLのManufacturing Demonstration Facilityが進めるAI統合製造研究や。IEEEで発表されたTSPベースのツールパス最適化（ツールパス数を90%削減）といった成果が。そのため、このデータベースの基盤技術となる。

まとめ：スライサーの「出力」は始まりに過ぎない

本稿で解説したLLM G-code最適化のワークフローを振り返る。

1. スライサーのG-code出力は、ルールベースの「出発点」に過ぎない
2. LLMはG-codeを構造化テキストとして理解し、コンテキストアウェアな最適化を提案できる
3. トラベル経路の再配置で移動距離を15～30%削減する可能性がある
4. セグメント別リトラクション制御で不要なリトラクションを20～40%削除できる
5. Klipperマクロとの連携で、最適化結果をファームウェアレベルで実行できる
6. フィードバックループにより、プリンター固有の特性を学習し精度を向上させる

一方、重要なのは。LLM G-code最適化はスライサーを「置き換える」ものではなく。「補完する」ものだという点だ。したがって、スライサーが担うジオメトリ解析、インフィルパターン生成。サポート配置といった根本的なタスクは、引き続きスライサーの領域だ。たとえば、LLMが得意とするのは。スライサーが出力した後の「最後の一磨き」――コンテキストを理解した微調整だ。

導入に向けた次のステップ

ちなみに、3Dプリンティングの世界では、ハードウェアの性能向上が注目されがちだ。CoreXYの高速化、ダイレクトドライブの軽量化、ヒートベッドの均熱性改善。しかし、同じハードウェアでも。とりわけ、ソフトウェアによる最適化で引き出せる性能には大きな差がある。LLM G-code最適化は、既存の機材から追加投資なしで性能を引き出す。さらに、ソフトウェア駆動のアプローチだ。

スライサーの「エクスポート」ボタンを押した瞬間は、造形プロセスの終点ではない。また、それは、AI最適化という新しいフェーズの始まりだ。

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.