3MF のメタデータに書いた「AI 生成」はスライサーで残るのか — Bambu Studio・OrcaSlicer・PrusaSlicer で保存し直して差分を取った

AI で作ったモデルを 3MF で配るとき、「これは AI 生成だ」という印をファイルの中に書いておきたくなる。3MF メタデータには既定の名前のほかに、作り手が名前空間を宣言して自分の名前を足す余地があり、印を書くならそこになる。気になるのは、受け取った人がその 3MF をスライサーで開き、保存し直したときだ。書いた印は、次の人の手元まで届くのだろうか。

確かめるために、20mm の立方体の 3MF を1つ用意した。3MF Core Specification の既定の名前を7つと、当サイトが試験用に決めた名前空間の名前を3つ入れ、PrusaSlicer 2.9.6、PrusaSlicer 3.0.0-alpha12、OrcaSlicer 2.5.0-rc、Bambu Studio 2.8.4.57 の CLI で読み込んで、3MF に書き出した。比べたのは、出力の 3D/3dmodel.model に入っている 3MF メタデータだ。版はどれも 2026-11-02 時点のもので、実行は各スライサー1回である。AI と書いた CAD のコードからモデルを書き出す話そのものは、OpenSCAD × LLM 実践 2026 — コードCADを ChatGPT・Claude と書く（2026-07-18 公開） で扱った。

先に結論を3つ書く。まず、この実行では PrusaSlicer の2つの版はどちらも「AI 生成」の項目を出力に残さなかった。2.9.6 は Title と Description を出力のファイル名に書き換え、3.0.0-alpha12 は日付2つと Application の3項目だけを書いた。次に、Bambu Studio と OrcaSlicer は「AI 生成」の項目の名前と値の文字列を残したが、preserve の属性と名前空間の宣言は出力に無かった。preserve を付けなかった対照の項目も同じように残ったので、preserve を見て残したのではなく、読み込んだ項目を書き戻した結果と読める。最後に、仕様の側でも、既定の名前に AI や生成を表すものは無く、preserve による保持は「推奨（SHOULD）」にとどまる。

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

3MF メタデータの決まり — 既定の名前、名前空間、preserve

3MF Core Specification は、3MF Consortium が公開している 3MF の基本の仕様だ。今回読んだのは 1.4.0（2025 年 2 月）で、メタデータの規則は「3.4.1. Metadata」の節にまとまっている。model 要素の子に metadata 要素を置き、name 属性に名前を、要素の中身に値を書く形である。仕様は、作り手がモデルのファイルについての情報をメタデータとして付けることを推奨している（SHOULD）。

既定の名前は9つで、AI や生成を表す名前は無い

表 3-1 が定める既定の名前は次の9つで、どれもモデル全体（文脈は Model）にかかる。説明は仕様の原文を当サイトが訳した。

見てのとおり、この9つに AI や生成の来歴を表す名前は無い。「AI 生成」を項目として書くなら独自の名前空間で名前を作ることになり、仕様はそれを認めている。言い換えれば、3MF に印を書く手段が無いのではなく、そのための標準の名前がまだ決まっていない、という状態だ。

独自の名前には、宣言した名前空間の接頭辞を付ける（MUST）

name 属性に書けるのは、既定の名前か、作り手が定義した名前のどちらかである。後者について仕様は、model 要素で宣言した XML の名前空間の接頭辞を付けなければならない（MUST）と定める（原文 “vendor-defined metadata, which MUST be prefixed with a valid XML namespace name declared on the” model 要素）。裏返すと、名前空間の無いメタデータは「この仕様が定める名前と値に限る」（原文 “MUST be restricted to names and values defined by this specification”）。接頭辞なしで書いてよいのは、既定の9つだけということになる。

ほかにも、同じ名前のメタデータを2つ作ってはならない（MUST NOT）。他のソフトと通じさせたい作り手は、名前空間の URI と名前の一覧、期待する中身を公開することが推奨される（SHOULD）。さらに仕様全体の適合の条件として、文書を変更して保存する側は不適合を持ち込んではならない（MUST NOT）。宣言した接頭辞、接頭辞の無い名前の制限、名前の重複の禁止、不適合を持ち込まないこと。この4つが、保存し直した出力の書き方にかかる MUST だ。

preserve は「保持することが推奨される」（SHOULD）

preserve は metadata 要素に付けられる任意の属性で、型は真偽値、既定は 0（false）とみなされる。仕様は、preserve が 1 か true のとき、3MF を変更する側は、参照するデータが変わっても元のメタデータの値を保持することが推奨される、と書く（原文 “Consumers that modify the 3MF file SHOULD retain the original metadata value even if the data it references is modified.”）。

この SHOULD は RFC 2119 の意味で、3MF Core の Document Conventions が再掲する定義では、特定の状況では無視する正当な理由がありうる（原文 “there may exist valid reasons in particular circumstances to ignore this item”）。そのため、preserve=”1” の項目が保存し直しで消えても、それだけで MUST に反するわけではない。preserve は、作り手が受け手に「残してほしい」と頼むための属性であって、残すことを強いる仕組みではない。

知らない名前の扱いも書かれている。受け手は、認識できない名前のメタデータを無視することが推奨される（原文 “Consumers SHOULD ignore any metadata with a name they do not recognize”）。ただしこれは読み込むときの話で、保存し直すときに残すかどうかは preserve の側の話になる。また、値の XML の型を示す type 属性（既定は xs:string）を保存し直しで書き戻すことについては、明文が無い。メタデータの外には、独自のパーツ（ファイル）ごと残させたいときに張る MustPreserve の関係（これも SHOULD）もあるが、今回は測っていない。

なお、本稿では、CLI で読み込んで書き出すだけの操作も、仕様のいう「変更した版を保存する」に当たるものとして扱う。各スライサーは書き出すときに自分の版の項目などを足すからだが、これは当サイトの解釈である。

3MF や STL といったデータ形式の基本を体系的に押さえるなら、3Dプリンター活用技術検定の公式ガイドブックが手堅い。形式ごとの違いを確かめてから仕様を読むと、メタデータの決まりも追いやすい。

3Dプリンター活用技術検定 公式ガイドブック 改訂2版（日経BP）

¥3,300 （2026/09/22 08:51時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

実験の条件 — 20mm の立方体に 10 項目を入れ、4つの版の CLI で書き出した

使ったスライサーと版は次のとおりで、状態と公開日は GitHub のリリースによる（2026-11-02 時点）。2つのスライサーの試用版の位置づけは、スライサーのプラグインが OrcaSlicer 2.5 と PrusaSlicer 3.0 に入った — 2つの試用版で何が変わり、何がまだ決まっていないか（2026-10-26 公開） にまとめてある。

2026-11-02 時点で OrcaSlicer 2.5.0 の正式版は出ておらず、最新の安定版は v2.4.2 だ。Bambu Studio の最新の正式版は 2.8.2.61 Public Release（2026-08-21）で、こちらは測っていない。ただし、固定したコミットのソースを比べると、メタデータを読み書きする部分は 2.8.4 と同じ処理になっている。

配布物は、OrcaSlicer 2.5.0-rc の portable 版と、PrusaSlicer 2.9.6・3.0.0-alpha12 の zip について、GitHub のリリースに載っている digest（SHA-256）と照合し、一致を確かめた。Bambu Studio 2.8.4.57 は、手元にインストール済みのものを使っている。

入力の 3MF

入力は、20mm の立方体1つ（12 三角形）と、それを build の item として (100,100,0) に置いただけの 3MF だ。メタデータには次の 10 項目を入れた。

値はどれも、AI 生成の印を入れる場面を想定した試験用の文字列である。Core の7項目には preserve を付けていない。preserve=”1″ を付けたのは独自の名前空間の swb:AIGenerated と swb:Generator の2つだけで、swb:Note は preserve を付けない対照にした。対照を置いたのは、項目が残ったときに、スライサーが preserve を見て残したのか、読み込んだものを全部書き戻しただけなのかを見分けるためだ。

XML で書くと、独自の名前空間の3項目は次の形になる（metadata 要素だけを抜き出した）。

<metadata name="swb:AIGenerated" preserve="1">true</metadata>
<metadata name="swb:Generator" preserve="1">claude-sonnet-5-5 + manifold3d</metadata>
<metadata name="swb:Note">no preserve flag on this one</metadata>

接頭辞 swb の宣言は、model 要素に xmlns:swb として書いてある。この接頭辞と名前空間の URI（swiftwand.com/ns/provenance/2026、先頭は https）は当サイトが試験用に決めたもので、標準ではない。読者が同じ名前空間を使う理由は無い。

Application の値を、どのスライサーの名前でも始めなかったのにも理由がある。固定したコミットのソースでは、PrusaSlicer 3.0 は Application が PrusaSlicer- で始まる古い版の 3MF を旧形式の読み込みに回し、Bambu Studio は BambuStudio- で、OrcaSlicer はそれに加えて OrcaSlicer- で始まると、自分たちの系統の 3MF として扱う。読み込みの経路が変わると、比べたいものとは別の差が出るので、それを避けた。

操作と比べ方

操作はどれも、CLI で入力の 3MF を読み込み、--export-3mf で 3MF に書き出すだけにした。スライスはしていない。PrusaSlicer と OrcaSlicer は --datadir を空のフォルダにして、手元の設定を読ませていない。Bambu Studio の CLI で --export-3mf を使う手順は、AI で描いた模様を3Dプリントの表面の凹凸にする — 高さ画像の作り方と、継ぎ目・造形時間を数える（2026-10-31 公開） でも使った。

実行は 2026-11-02 の昼（日本時間）で、UTC でも同じ日付になる。終了コードは4つとも 0 で、所要は PrusaSlicer 2.9.6 が 0.3 秒、3.0.0-alpha12 が 1.5 秒、OrcaSlicer が 1.4 秒、Bambu Studio が 0.6 秒だった。

比べ方は、出力の 3D/3dmodel.model のメタデータを入力と突き合わせ、名前ごとに4つに分けるものだ。「残った」は名前と値が同じ、「変わった」は名前が同じで値が違う、「消えた」は名前が無い場合を指す。4つ目の「ns_lost」は、名前と値の文字列は残ったのに、接頭辞 swb の名前空間の宣言（xmlns:swb）が出力に無い場合で、本文では「宣言が消えた」とも書く。3MF を作るスクリプトと比べるスクリプトは、当サイトの側で用意した。比べ方は1回目のあと2点を直したが、スライサーは実行し直していない。

照合の相手には、3MF Core 1.4.0 の原文と、各スライサーの固定したコミットのソースを読んだ見込みから、行ごとに「仕様は何を求めるか」「各版はどう書くはずか」を並べた正解表（R1〜R20）を使った。正解表は Core の項目にも preserve=”1″ を付けた入力を想定して作ったもので、照合は実際の入力と対応の付く行で行った。以下に出てくる R の番号は、この表の行を指す。

ここで使ったスライサーはどれも無料で使えるが、保存し直した 3MF を実際に造形して確かめるなら、Bambu Studio と組み合わせて使う機体が手元にあると早い。

Bambu Lab P1S Combo 3DプリンターAMS2 Pro付き 筐体付き CoreXY 多色造形 造形サイズ：256×256×256mm³

¥102,000 （2026/09/17 13:47時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

結果の一覧 — 10 項目は4つの版でどうなったか

10 項目それぞれが、4つの版の出力でどうなったかを並べる。

表の CreationDate の行には注意が要る。入力の日付が、実行した日と同じ 2026-11-02 だった。そのため「同じ値」は、元の値が残ったのか、保存した日に置き換わったのかを見分けられない（正解表の R7）。

出力にだけあった項目は次のとおりだ。

• PrusaSlicer 2.9.6: slic3rpe:Version3mf（値は 1）、空の Rating、ModificationDate（2026-11-02）
• PrusaSlicer 3.0.0-alpha12: ModificationDate（2026-11-02）
• Bambu Studio 2.8.4.57: BambuStudio:3mfVersion（値は 1）、ModificationDate（2026-11-02）、空の DesignerCover・DesignerUserId・License・Origin・ProfileCover・ProfileDescription・ProfileTitle
• OrcaSlicer 2.5.0-rc: OrcaSlicer（値は 2.5.0-rc）、BambuStudio:3mfVersion（値は 1）、空の DesignerCover・DesignerUserId・License・ModificationDate・Origin

出力の model 要素に宣言されていた名前空間は、PrusaSlicer 2.9.6 が Core と slic3rpe、3.0.0-alpha12 が Core だけ、Bambu Studio と OrcaSlicer が Core・BambuStudio・p（Production 拡張）だった。どの出力にも swb の宣言は無い。ここから先は、版ごとに結果とソースの読みを突き合わせていく。

PrusaSlicer 2.9.6 は Title と Description を出力のファイル名にした

PrusaSlicer 2.9.6 の出力では、Title と Description がどちらも roundtrip になった。これは、書き出したファイルの名前から拡張子を除いた部分だ。Designer・Copyright・LicenseTerms は名前だけ残って値が空になり、Application は PrusaSlicer-2.9.6 に変わった。swb の3項目は、preserve=”1″ の2つも対照の1つも出力に無く、消えた値が 3MF の中の他のファイルに写っていることもなかった。

固定したコミットのソースを読むと、これは見込みどおりの動きである。2.9.6 の書き出しは、決まった9つの既定の名前を毎回自分の値で書く処理になっている。Title と Description には出力ファイル名の拡張子を除いた部分を入れ、日付は保存した日（UTC の時刻の文字列の先頭 10 文字）を入れ、Designer などは空にする。一方、読み込みで値を使うのは、版の番号の slic3rpe:Version3mf、Application、塗り分けの版の番号だけで、3mf.cpp に preserve の語は1つも無い。

つまり 2.9.6 では、入力のメタデータが何であっても、保存し直した出力は自分の9つと版の項目に置き換わる処理になっている。空の Rating が足されたのも、9つを毎回書く処理の結果だ。今回は Core の項目に preserve を付けていないが、ソースに preserve を読む処理が無いので、付けても同じ結果になる見込みである（これは測っていない）。

この結果を読者の場面に置き直してみる。ソースの処理とこの実行の結果を合わせて読むと、Description に「AI 生成」と書いて配った 3MF は、受け手が 2.9.6 の CLI で書き出すと、出力のファイル名に置き換わる。Title も同じだ。独自の名前空間に書いた項目は、この実行では出力から名前ごと無くなった。

PrusaSlicer 3.0.0-alpha12 は3つの項目だけを書いた

3.0.0-alpha12 の出力にあったメタデータは、CreationDate、Application、ModificationDate の3つだけだった。Application の値は PrusaSlicer-3.0.0-alpha12、ModificationDate は 2026-11-02 で、CreationDate は入力と同じ 2026-11-02 である。Title・Designer・Description・Copyright・LicenseTerms と swb の3項目は、名前ごと出力に無い。消えた値のうち6文字以上のものは、Metadata/PrusaSlicer3_project.json など 3MF の中の他のファイルにも写っていなかった。宣言されていた名前空間は Core だけだ。

3.0 では、3MF の読み書きが 2.x とは別のコードに作り直されている。固定したコミットのソースを読むと、読み込みでは name・preserve・type の3つの属性を読み、preserve は値を見ずに、属性があれば真として持つ。ところが書き出しでは、preserve を書く部分が Not supported by xs というコメントの下でコメントアウトされている。読み込みでは preserve を読み取るが、書き出しでは preserve を書かない、という状態だ。

3項目だけになった理由は、保存の直前の処理にある。ソースでは、保存のときに渡されたメタデータから ModificationDate と Application を除き、重複を除いたうえで、保存した日の ModificationDate、（無ければ）CreationDate、Application を足す。そして読んだ範囲では、CLI の保存も画面の保存も、メタデータを渡さずに保存を呼んでいる。読み込んだメタデータは、版の判定にしか使われない。ソースを読んだ見込みは「3つだけになる」で、この実行の CLI の出力はそのとおりになった。

Application の値には、ソースとの小さな違いがあった。ソースの既定値は末尾に +UNKNOWN を付ける形だが、GitHub の zip の出力は PrusaSlicer-3.0.0-alpha12 で、+UNKNOWN は付いていなかった。また、ソースには知らない名前空間の宣言を「読み込みの問題」として記録する処理もある。この実行では CLI の出力の末尾しか残しておらず、それがどう表示されたかは確かめていない。終了コードは 0 だった。alpha の段階の版なので、正式版までに変わりうることも添えておく。

Bambu Studio と OrcaSlicer は文字列を残し、宣言と preserve を落とした

Bambu Studio 2.8.4.57 と OrcaSlicer 2.5.0-rc の出力では、Title・Designer・Description・Copyright・LicenseTerms の5つが入力の値のまま残った。swb の3項目も、名前と値の文字列は残っている。しかし preserve の属性を付けていた2項目（swb:AIGenerated と swb:Generator）は、どちらも属性が無くなっていた（対照の swb:Note は最初から属性が無い）。model 要素からは xmlns:swb の宣言も消えていた。出力の metadata 要素は、たとえば次のように name だけを持つ形になる。

<metadata name="swb:AIGenerated">true</metadata>

ここで効いてくるのが対照の swb:Note だ。preserve を付けなかったこの項目も、preserve=”1″ の2つと同じく文字列が残り、同じく宣言が消えた。preserve の有無で結果が変わらなかったのだから、2つのスライサーは preserve を見て残したのではなく、preserve に関係なく、読み込んだ項目を書き戻したと読める。

固定したコミットのソースも、この読みと合う。Bambu Studio は PrusaSlicer をもとにしたスライサーで（README による）、OrcaSlicer はその Bambu Studio と同じ系統の bbs_3mf.cpp を使っている。どちらも、読み込んだメタデータを名前と値の組として全部覚え、書き出すときはその組を土台にして、自社が使う名前（Title・Origin・Designer・License・日付・Application など）を値が空でも毎回書く。model 要素で宣言する名前空間は Core・BambuStudio・（使うときの）p だけで、metadata 要素に書く属性は name だけだ。Bambu Studio の bbs_3mf.cpp に preserve の語は無く、OrcaSlicer でも、シームの設定を古い版で無効のまま残すことについての、メタデータとは関係のないコメントに1件あるだけだった。

宣言が消えたことには、読む側にとって意味がある。name の値の接頭辞 swb を名前空間の URI に結び付けようとしても、対応する宣言が出力に無いので結び付けられない。文字列として swb:AIGenerated を探せば見つかるが、名前空間の URI で照合すると見つからない。印が「残った」かどうかは、読み方によって答えが変わる形になったわけだ。

2つの出力には、メタデータ以外の変化もあった。どちらも形状を 3D/Objects/ の下の別の model ファイルに移し、p:（Production 拡張）を requiredextensions に入れた。とはいえ、メタデータは主のファイルの 3D/3dmodel.model に書かれるので、印を探すならそこを見ればよい。Bambu Studio の出力では、build の item の位置が (99.99999,100,10) になった（入力は (100,100,0)。z の 10 は立方体の半分の高さ）。

OrcaSlicer は Application に BambuStudio-02.08.01.55 を書き、日付を空にした

同じ系統でも、OrcaSlicer には Bambu Studio と目立って違う点が2つあった（ProfileTitle・ProfileCover・ProfileDescription が出力に無いという3つ目の違いは、後の R16 の節で扱う）。1つ目は Application で、値は BambuStudio-02.08.01.55 になり、別に OrcaSlicer という名前で 2.5.0-rc が足された。ソースのコメントは、これを Bambu Studio との互換のための書き方と説明している（原文 “Orca: Write the BambuStudio compatibility version string using SLIC3R_VERSION.”）。version.inc では SLIC3R_VERSION が 02.08.01.55、OrcaSlicer 自身の版が 2.5.0-rc になっている。

2つ目は日付で、CreationDate と ModificationDate がどちらも空になった。ソースのコメントが挙げる理由はプライバシーで、原文は “Orca: PRIVACY: do not store creation & modification date in 3mf” である。ソースでは、利用者 ID の DesignerUserId も同じ理由で空にする処理になっている（この実行では Bambu Studio の出力でも DesignerUserId は空だった）。入力の CreationDate（2026-11-02）が空になったのは、この処理の結果だ。

ここで Application の定義を思い出したい。仕様は Application を「文書を最初に作った元のアプリの名前」と定義している。この実行では、入力の swiftwand-d5-maker 0.1 が、4つの版のすべてでそれぞれのスライサーの値に置き換わった。入力の Application に preserve は付けていないので、仕様の上で保持の要求がある項目ではない。それでも、保存し直した 3MF の Application から「最初に作ったアプリ」を知ることはできない、という点は押さえておきたい。OrcaSlicer の出力なら、実際に書き出したスライサーの版は OrcaSlicer の項目のほうに入っている。

仕様の決まりと出力を並べる — R13〜R16

保存し直した出力の書き方について、仕様の要求と4つの版の出力を並べる。数は、出力の 3D/3dmodel.model の metadata 要素を数えたものだ。

まず R14 から。仕様は、既定の9つに無い名前には、model 要素で宣言した名前空間の接頭辞を付けると定める。出力は、Bambu Studio と OrcaSlicer のどちらでも、swb: で始まる3項目が残り、xmlns:swb の宣言が無かった。PrusaSlicer の2つの版では swb の項目そのものが残っていないので、この行は 0 になる。

R16 も同じ並べ方で書く。仕様は、名前空間の無いメタデータを、この仕様が定める名前と値に限ると定める。出力には、Bambu Studio で7つ（DesignerCover・DesignerUserId・License・Origin・ProfileCover・ProfileDescription・ProfileTitle）、OrcaSlicer で5つ（OrcaSlicer・DesignerCover・DesignerUserId・License・Origin）の、接頭辞の無い Core 外の名前があった。これらは入力とは関係なく、スライサーが自分で書き足した名前である。中でも License は Core の LicenseTerms とは別の名前で、入力の LicenseTerms が残ったうえに、空の License が足された。

R15 の重複は、4つとも 0 だった。PrusaSlicer 3.0 は、ソースでも保存の前に重複を除く処理を持つ。R13 については、仕様が書き戻しを求めていないので、出力に preserve が無いことは仕様の要求とは別の、事実の記録として読んでほしい。ただし実務の上では意味がある。preserve が書き戻されない以上、もう一度保存し直す次の人には、「残してほしい」という頼みそのものが伝わらないからだ。

ソースを読んだ見込みと、この実行の結果

正解表の R1〜R16 を4つの版で見ると、16 行 × 4 = 64 か所になる。このうち R7 の3か所（PrusaSlicer 2.9.6・3.0.0-alpha12・Bambu Studio）は、前に書いたとおり日付が同じで判定できない。R14 の PrusaSlicer の2か所は、swb の項目が残らないので問わない行だ。残る 64 − 3 − 2 = 59 か所のうち、58 か所は見込みどおりで、見込みと違ったのは1か所だった。

違ったのは OrcaSlicer の R16 である。見込みでは、Bambu Studio と同じ名前に OrcaSlicer を足したものを挙げていた。ところが、この実行の出力には ProfileTitle・ProfileCover・ProfileDescription が無く、接頭辞の無い Core 外の名前は5つだった。「ある」という見込みは当たり、中身が違った形だ。固定したコミットのソースを読み直すと、OrcaSlicer の書き出しで値を書き込む名前の中に ProfileTitle・ProfileCover・ProfileDescription は無く（Bambu Studio の書き出しにはある）、見込みを立てたときの読み落としだった。

見込みの段階で「実測で確かめる」としていた点も、この実行で確かめられた。PrusaSlicer 3.0.0-alpha12 が CLI の保存で3項目だけを書くこと、Bambu Studio と OrcaSlicer が独自の名前空間の宣言を書かないこと、4つの版のどれも preserve を書き戻さないことの3点だ。いずれも CLI の書き出しを1回行った結果で、画面の保存や他の版には広げていない。

比べるスクリプトの限界も書いておく。見落としうることとして、名前の大文字小文字だけが変わった場合や、空の値と要素が無いことの区別がある。後者は、PrusaSlicer 2.9.6 の Designer（値が空になった）と 3.0.0-alpha12 の Designer（名前ごと消えた）が別の結果に分かれたので、この実行では区別できている。前者は確かめていない。

PrusaSlicer の issue #13920 はボットが閉じた

PrusaSlicer が preserve を守っていないという報告は、2025-01-06 に issue #13920 として出ている。題名は “PrusaSlicer isn’t honoring 3MF metadata element “preserve” attribute” で、報告の版は 2.9.0 だ。報告者によると、Windows で 3MF を開くのは問題ないが、画面の File メニューの Save As で保存すると、メタデータが丸ごと取り除かれて置き換わり（原文 “the metadata tags are wholesale removed and replaced”）、preserve を 1 にした要素も値が更新される。

その後の経緯はこうだ。2026-09-02 に、PrusaSlicer 3.0 alpha の公開より前に作られた issue として、ボットが legacy の印を付け、新しいコメントが無ければ3週間で閉じると予告した。2026-09-18 に最後の警告があり、2026-09-29 にボットが閉じた。GitHub の表示は “closed this as completed” だが、ボットのコメントが挙げる閉じた理由は “Closing this issue due to inactivity.” である。issue の履歴に修正のコミットの参照は無く、開発者の返信も無い。

“completed” は GitHub での閉じ方の種類であって、直ったという意味ではない。固定したコミットのソースを読むと、2.9.6 は報告と同じ書き方のままで、この実行の 2.9.6 の CLI の出力も、既定の名前を自分の値で書き直すものだった。報告は画面の別名保存での話で、今回測ったのは CLI の書き出しだという違いはある。それでも、既定の名前を書き直すという点では同じ向きの結果だった。3.0.0-alpha12 は別のコードで、前に見たとおり preserve を読むが書かない。

AI 生成の印を 3MF メタデータに入れて配るときの読み方

ここからは、AI で作ったモデルに印を入れて 3MF で配る人の立場で、結果を読む。前提として、本稿は法的な判断や助言ではなく、誰が表示の義務を負うかにも触れない。EU AI Act 第50条についての欧州委員会のガイドライン（拘束力なし）が 3D の画像やメッシュをどう扱っているかは、AI 生成の表示と「印」は画像と3Dデータのどこで消えるのか（2026-11-09 公開） にまとめた。

1つ目は、印を書く場所である。3MF Core の既定の名前に AI や生成を表すものは無いので、項目として書くなら独自の名前空間になる。仕様は、他と通じさせたい作り手に、名前空間の URI と名前の一覧を公開することを推奨している。本稿の swb は試験用で、勧めるものではない。3MF Core が定める名前の中に無い、という以上のことは今回調べていない。

2つ目は、受け手の保存し直しで印がどうなるかだ。この実行では、受け手がどのスライサーで保存し直すかで結果が分かれた。PrusaSlicer の2つの版では、preserve=”1″ を付けた項目も出力に残らなかった。Bambu Studio と OrcaSlicer では文字列は残ったが、preserve と名前空間の宣言の無い形になった。どの版の出力にも preserve は無いので、その先でもう一度保存し直されるときには、preserve の付いていない項目として扱われる。

3つ目は、確かめる側の注意である。受け取った 3MF に印が無くても、それは AI 生成でないことを意味しない。途中で誰かが保存し直していれば、元の印が無くなっていることがあるからだ。逆に印が残っていても、宣言の無い接頭辞の形になっていれば、名前空間の URI で照合する読み方では見つからない。Application も4つの版すべてで書き換わったので、「最初に作ったアプリ」の手がかりにはならない。

4つ目は、配る側にできることだ。印を入れた 3MF を配るなら、スライサーで保存し直す前のファイルを配れば、少なくとも配った時点では印が入っている。その先、受け手の手元で残るかどうかは受け手のスライサーと操作しだい、というのがこの実行から言える範囲である。なお、Bambu Studio 2.8.4 の Beta で保存した 3MF は、MakerWorld へのアップロードに一時的に対応していないと、公式のリリースノートが書いている。

画像のほうでは、WordPress に上げた AI 画像の C2PA はいつ消えるのか（2026-11-12 公開） で、投稿の途中で印がどうなるかを測った。この実行の 3MF でも、ファイルの中の印は普段の保存し直しで形が変わった。印を入れる人と確かめる人の両方が、その前提を共有しておく必要がある。

Copyright や LicenseTerms の欄に何を書くかを決めるには、著作権の基本を押さえておきたい。新書サイズの入門書で、権利の種類と使い方の決まりを一通り確かめておくと迷いにくい。

はじめての著作権法 第2版（日経文庫）

¥1,401 （2026/09/22 09:40時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

この実測で言えないこと

最後に、今回の結果で言えないことを並べておく。

• 実験は各スライサー1回で、操作は CLI の --export-3mf による書き出しだけだ。「この実行ではこうだった」以上の一般化はしない。
• 画面（GUI）での保存は測っていない。#13920 の報告は画面の別名保存での話で、CLI とは経路が違う。OrcaSlicer 2.5 の画面にある Publish 3MF も使っていない。
• スライスはしておらず、G-code とスライス済みの 3MF（.gcode.3mf など）は測っていない。3つのスライサーのソース（PrusaSlicer は 2.9.6）を検索した範囲では、3MF のメタデータを G-code に写す処理は見当たらなかったが、無いことの証明ではない。G-code の先頭に、生成元のスライサーを示す行を書く処理はある。
• CreationDate（R7）は、入力の日付が実行日と同じだったため、残ったのか置き換わったのかを判定できない。
• Core の7項目には preserve を付けていない。Core の項目に preserve=”1″ を付けた場合の出力は測っていない。
• 物体ごとのメタデータ（metadatagroup）と、MustPreserve の関係を張った独自のパーツは入力に入れていない。
• Bambu Studio 2.8.2.61 や OrcaSlicer 2.4.2 などの他の版、形状を省く --min-save、スライサーをまたいで保存し直す流れは測っていない。2.8.2.61 について言えるのは、ソースでは 2.8.4 と同じ処理というところまでだ。
• 使った版のうち3つは pre-release（alpha・beta・release candidate）で、正式版で変わりうる。
• 比べるスクリプトは、名前の大文字小文字の違いのような差を見落としうる。

まとめ

3MF メタデータに書いた「AI 生成」の印は、この実行では、通したスライサーによって3通りの結果になった。PrusaSlicer 2.9.6 は自分の9つの名前に書き直し、3.0.0-alpha12 は3項目だけを書き、Bambu Studio 2.8.4.57 と OrcaSlicer 2.5.0-rc は文字列を残して宣言と preserve を落とした。どの版も preserve を書き戻さなかった。

仕様の側から見ると、AI 生成を書く標準の名前は Core に無く、独自の名前空間で書くことは認められている。preserve は「残してほしい」と頼む属性で、保持は推奨（SHOULD）にとどまる。仕様の MUST が決めているのは書き方のほうで、Bambu Studio と OrcaSlicer の出力には、宣言の無い接頭辞の項目と、接頭辞の無い Core 外の名前があった。

印を入れて配る人は、ファイルの中の印が受け手の保存し直しで変わりうることを前提にしておくとよい。確かめる側は、印が無いことを AI 生成でない証拠として読まないことだ。スライサーの CLI やプラグインのどれを入口にするかは、スライサーの拡張をどこから始めるか — プラグイン・後処理スクリプト・CLI の使い分けと、alpha 版との付き合い方（2026-11-01 公開） で整理している。

参照

• 3MF Core Specification 1.4.0 本文（3MF Consortium、タグ 1.4.0 のコミット）
• 3MF Core Specification 1.4.0 のリリース
• PrusaSlicer issue #13920
• PrusaSlicer 2.9.6 のリリース
• PrusaSlicer 3.0.0-alpha12 のリリース
• PrusaSlicer 2.9.6 の 3mf.cpp
• PrusaSlicer 3.0.0-alpha12 の Model3mf.cpp
• PrusaSlicer 3.0.0-alpha12 の Metadata.cpp
• OrcaSlicer v2.5.0-rc のリリース
• OrcaSlicer v2.4.2 のリリース
• OrcaSlicer v2.5.0-rc の bbs_3mf.cpp
• OrcaSlicer v2.5.0-rc の version.inc
• Bambu Studio 2.8.4 Public Beta のリリース
• Bambu Studio 2.8.2.61 Public Release のリリース
• Bambu Studio 2.8.4 の bbs_3mf.cpp
• Bambu Studio 2.8.4 の README

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

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