分野別の詳説:参照したマニュアルの主要な仕組み・操作・設定を翻訳・要約・再構成した日本語解説です。全項目の逐語訳ではありません。確認順や例は編集上の補足です。手順から先に読み、必要なときに後半の仕組みの解説へ進めます。
この章の目標:拡張の検証と実行を分ける。
準備:__init__.pyとmanifestとCOPYING。
実践:繰り返す処理を小さい単位で記述する
この節の式とファイル名は学習用の編集例です。実行する前提の説明であり、対象のファイルと出力を確認してから実行してください。
- 作業用の.blendを別名保存し、Python Consoleを表示します。対象が本当にそのファイルに存在するか、Outlinerで名前を確認します。
import bpyでAPIへアクセスします。続いてobj = bpy.data.objects.get("Cube")のように、対象を取得します。objを表示し、取得できているかを確認します。Noneならその名前は見つかっていないので、次の編集へ進まず対象を直します。- 対象が取得できた場合に、
obj.location.x = 1.0のように一つの値を変えます。数字は例です。これで変わるのは基礎のLocationで、制約後の見た目が同じとは限りません。 - 処理をまとめる段階でText Editorへ移し、対象を取得できない場合の分岐やエラーを加えます。名前を決め打ちする処理が他のファイルへそのまま使えるとは考えません。
- 外部ファイルへの保存・書き出しを加える場合は、出力先と上書き条件を明示します。編集元の作品を残してから自動化します。
データを直接編集するAPIと、bpy.opsのオペレーターは前提が違います。後者はアクティブ対象、選択、モード、エディター等に依存する場合があります。UIで実行できた操作をInfoから移しても、背景実行で同じコンテキストが存在するとは限りません。
実践:コマンドラインから一枚を保存する
PATHに実行可能なBlenderがある環境なら、blender -b scene.blend -o //render/frame_##### -F PNG -f 1という構成で、ファイルの読み込み、出力設定、フレーム1のレンダーを指定できます。scene.blendは実際のファイルへ置き換えます。
macOSでは実行ファイルへの絶対パスを先頭に使う構成もあります。標準的な配置の例は/Applications/Blender.app/Contents/MacOS/Blenderですが、実際のインストール先へ合わせます。空白を含むパスはシェルで適切に引用します。
| 引数 | 意味 | 誤りやすい点 |
|---|---|---|
| -b | UIを開かず背景で実行 | 画像処理のメモリが不要になるわけではない |
| .blendのパス | 作品と設定を読み込む | 読み込み後に変更したい設定は、その後へ置く |
| -o | 出力先を指定 | 二つのスラッシュは.blend基準。番号用の#とファイル名を確認する |
| -F | 出力形式を指定 | 大文字。小文字の-fとは違う |
| -f | 単一フレームを出力 | 設定変更の後へ置く |
| -s / -e | 開始・終了フレーム | 範囲を使うアニメーション出力と組み合わせる |
| -a | アニメーションを出力 | -fと同様、必要な設定の後へ置く |
| -E | レンダーエンジン | 利用可能なエンジン名を確認する |
引数は順に処理されます。-aの後で出力形式を指定しても、既に始まった出力の条件にはなりません。版、入力ファイル、出力先、終了状態とログを記録すると、何を実行したかを再現しやすくなります。
Extensionを作り、利用前に確認する
以下はメッセージを表示するだけのアドオンを新規に記述した編集例です。記事本文と区別し、このPython例のライセンスはGPL-3.0-or-laterとします。Blender 5.2向けの構成例で、背景実行でのOperator実行とZIP構築・検証は確認済みです。Preferencesからの導入操作は未検証です。
作業フォルダーにl3log_helloを作り、その中に次の二つのファイルを置きます。配布用にはGPLのライセンス本文も同梱してください。
l3log_hello/
__init__.py
blender_manifest.toml
COPYING
__init__.pyには次を保存します。外部依存やネットワーク・ファイル操作はありません。
# SPDX-License-Identifier: GPL-3.0-or-later
import bpy
class OBJECT_OT_l3log_hello(bpy.types.Operator):
bl_idname = "object.l3log_hello"
bl_label = "L3log Hello"
def execute(self, context):
self.report({'INFO'}, "Hello from L3log")
return {'FINISHED'}
def draw_menu(self, context):
self.layout.operator(OBJECT_OT_l3log_hello.bl_idname)
def register():
bpy.utils.register_class(OBJECT_OT_l3log_hello)
bpy.types.VIEW3D_MT_object.append(draw_menu)
def unregister():
bpy.types.VIEW3D_MT_object.remove(draw_menu)
bpy.utils.unregister_class(OBJECT_OT_l3log_hello)
blender_manifest.tomlには次を保存します。ID・版・名前等は自分の配布物に合わせて変更します。最低対応版の指定は、その版で動作確認済みという保証ではありません。
schema_version = "1.0.0"
id = "l3log_hello"
version = "1.0.0"
name = "L3log Hello"
tagline = "Show a greeting from the Object menu"
maintainer = "L3log"
type = "add-on"
blender_version_min = "5.2.0"
license = ["SPDX:GPL-3.0-or-later"]
ターミナルをl3log_helloの一つ上の作業フォルダーで開きます。PATHから対象版のblenderを実行できる前提で、次の順に入力します。macOS等でPATHにない場合は、前節と同様に実行ファイルへのパスを引用して置き換えます。
blender --command extension validate ./l3log_hello
blender --command extension build --source-dir ./l3log_hello --output-filepath ./l3log_hello-1.0.0.zip
blender --command extension validate ./l3log_hello-1.0.0.zip
validateでエラーが出たらその内容を直してからbuildへ進みます。buildが成功すると、作業フォルダー直下にl3log_hello-1.0.0.zipができます。ZIP内にマニフェストとPythonファイルが含まれることを確認します。validateは主にパッケージのメタデータ等の検査であり、Pythonの全動作を保証するテストではありません。
対象版のPreferencesからInstall from DiskでZIPを導入して有効化し、3D ViewportのObject ModeでObjectメニューのL3log Helloを実行します。情報メッセージが表示されるかを確認し、無効化後にメニューが外れるかも確かめます。これが利用者側で必要な実機確認で、画面操作による通し検証は行っていません。
テーマはPythonの代わりに対応するXMLを用意し、manifestのtypeをthemeにする別構成です。公式プラットフォームへ公開する場合は、Blender IDでZIPをアップロードして審査を受けます。ZIPの構築と公開完了は別の工程です。
安全性と運用上の限界
Pythonの自動実行を許可する設定は、必要なリグを動かす利便性と、ファイル内のコードを実行する権限に関係します。出所を確認せずに一律で有効化しないようにします。手でText Editorのコードを実行する操作は、自動実行を無効にしただけでは防ぐ仕組みではありません。
複数ファイルを処理する前に、対象名の重複、参照切れ、モードの差、再実行時のオブジェクト増殖、保存の上書きを考えます。バックグラウンドでの実行とUIでの実行で条件が同じかも分けます。詳細な型・引数・非推奨の情報は、対象版のPython APIで確認する必要があります。
仕組みと用語を調べる
拡張機能の種類
Add-onはBlenderの機能を追加する仕組みです。Extensionは配布用のメタデータを持つパッケージで、アドオンやテーマなどを扱います。PreferencesのGet ExtensionsとAdd-onsは関係しますが、配布物を取得することと実際のアドオンを有効にすることは区別します。
必要な機能が動かない場合は、Blenderの対応版、プラットフォーム、有効状態、設定、機能が現れるエディターとモードを確認します。古いZIPの配置手順と、Extensionのリポジトリ経由での管理は別の説明です。Node Wranglerはノードの操作、Rigifyはリグ生成を助けるなど、拡張ごとに目的も異なります。
Extensionの構成
参照EPUB版では、アドオンのコードやテーマにblender_manifest.tomlを付け、コマンドラインで配布用ZIPを作る流れが説明されています。アドオンには通常__init__.pyなどが必要で、テーマは対応するXMLを持ちます。名前、ID、版、作者、対応するBlender版、ライセンス、権限などのメタデータを整えます。
インストールできること、機能が正しく動くこと、公式プラットフォームへ公開されることは別の段階です。公開にはアカウントと審査などの手順があります。依存するPythonのライブラリを含める場合は、WheelsとOSの対応も確認します。本記事は原典の構成整理であり、追加物を実際にインストール・公開する手順を実行したものではありません。
Python Console・Text Editor・Info
Python Consoleは式や短い処理を対話的に試す場所、Text Editorはまとまったスクリプトを編集・実行する場所です。Infoは操作などの情報を見るために利用できます。エディターへコードを表示することと、実行することは別です。
BlenderのPython APIではデータブロックへアクセスする処理と、オペレーターを実行する処理があります。オペレーターは現在のモード、選択、エディターなどのコンテキストへ依存する場合があります。手で実行できた操作を、その呼び出しだけコピーしても、背景実行で同じように動くとは限りません。
データとコンテキスト
データへ直接値を与える場合も、名前の重複、共有、現在のActionやモディファイアーなどの関係を確認します。対象名を決め打ちする処理は、別のシーンやファイルで意図しないデータを変更することがあります。スクリプトで使う処理の詳しい型や引数は、対象版のPython APIを参照します。
自動化では、入力ファイル、編集対象、出力先、実行版を明示すると再実行しやすくなります。UIの状態に依存する箇所を減らすことと、無条件にすべての処理をデータAPIへ置き換えることは同じではありません。各操作の目的と前提を把握します。これらは編集上の設計補足です。
スクリプトの実行許可
.blendにはPythonスクリプトや式を含められます。原典はPythonが実行内容を制限する環境ではないことを説明し、信頼できる出所のコードだけを実行するよう求めています。自動実行は既定で無効ですが、一部のリグなどは許可がなければ完全には動きません。
Trusted SourceやAuto Run Python Scriptsは、この扱いを制御します。手動でText Editorのコードを実行する操作などは、自動実行を無効にした設定だけで防げるわけではありません。ドライバーの単純式と、Pythonを必要とする式にも違いがあります。動かす必要性とコードの内容を確認して判断します。
コマンドラインでのレンダリング
背景実行はBlenderのUIを開かずに処理する入口で、ファイルを指定して単一フレームまたはアニメーションを出力できます。原典の基本例は、背景実行で.blendを読み、フレーム10をレンダリングする構成です。シェルで実行するblenderの場所はOSやインストール方法で異なります。
- -b:背景で実行します。
- -f:指定するフレームをレンダリングします。
- -a:設定されたアニメーション範囲をレンダリングします。
- -o:出力パスを指定します。
- -F:画像形式を指定します。小文字の-fとは別です。
- -s・-e:開始・終了フレームを指定します。
- -E:レンダーエンジンを指定します。
引数は与えた順に処理されます。ファイルの読み込み、出力設定の変更、レンダリングの順を考え、-fや-aを最後へ置くのが原典の注意点です。空白を含むパスはシェルの引用を適切に使います。この記事中の項目は説明であり、コマンドをすべての引数の組み合わせを実行確認したものではありません。
設定ファイルと環境
Blenderはユーザー設定、スクリプト、データ、キャッシュなどを所定のディレクトリへ置きます。版ごとの設定や環境変数、起動時の引数が動作へ影響します。複数の版を使う場合は、設定と拡張の互換性を区別します。
Application Templateは作業目的に合わせた初期構成を用意します。Startup Fileは新規作成時の内容へ関係し、保存した作品ファイルを開くこととは別です。キーマップの編集は個人の操作へ影響するので、記事の標準キーマップと異なる場合は、その差を明確にします。
運用の組み立て方
繰り返す処理を自動化するときは、まず一回の入力と出力を定めます。ファイルの上書き、外部素材の有無、処理失敗時の記録を考え、同じ処理を繰り返してデータを増殖させない構成にします。これは編集上の補足です。作品の中身に依存するコードは、その依存を説明してから再利用します。
検証した範囲
最終確認:2026年10月23日。Blender 5.2.2 LTS(macOS / Apple silicon)を背景実行し、次の内容を確認しました。
- 掲載Pythonのregister→Operator実行→unregister、CLIのvalidate→build→ZIPのvalidateが成功。Preferencesからの導入操作は未検証。
背景実行ではPython APIを使用しています。マウス・キー入力、画面遷移、インストール、各入力機器での操作を通して確認したものではありません。上記にない応用・設定の組み合わせは実行未検証です。
出典と利用条件
この記事で参照したマニュアルの項目:
- はじめに
- Scripting & Security
- Rendering From The Command Line
- How to Create Extensions
- Blender's Directory Layout
- Application Templates
- Node Wrangler
- はじめに
- Command Line Arguments
- Extensions Command Line Arguments
原著:Blender Documentation Team、Blender 5.2 Manual。底本はBlender 5.2 LTS ManualのEPUB版です。ファイル内の発行日時メタデータは2026年10月19日で、記事の検証日とは別です。原典のライセンス表示に従い、裏庭(Uraniwa)が翻訳・要約・再構成・説明の補足を行いました。この記事の本文・補足・独自の図解と作例画像はCC BY-SA 4.0で公開します。Blender公式による記事・推奨を示すものではありません。原典で適用対象外とされるロゴ・商標・アイコン・ソースコード・Pythonスクリプトなどには、この許諾は適用しません。