Contents
Extensions の基本的な仕組み
Blender 4.2 には Chromium Embedded Framework (CEF) をベースにした内部 Web ビューアが組み込まれており、外部ブラウザや別プロセスを起動せずにカタログページを表示できます。公式ドキュメント（Blender Manual → Extensions）では「安全なサンドボックス環境でリモートコンテンツを取得」すると説明されており、インストール操作はすべて Blender の UI 内で完結します。
-
カタログへのアクセス
ユーザーは Edit → Preferences → Add‑ons から「Extensions カタログ」を開き、キーワード検索やカテゴリ絞り込みが可能です。 -
インストールフロー
カタログ上の項目を選択すると、manifest に記載された URL から zip アーカイブまたは直接コードが取得され、Blender が自動的に展開・有効化します。
出典要約（app‑tatsujin.com）
本サイトのガイドは、Extensions の UI が CEF を利用している点と、インストール時に外部プロセスが起動しないことを強調しています。公式情報と照らし合わせても記述内容に大きな相違はありません。
従来のアドオンとの主な違い
従来の Blender アドオンは、bl_info 辞書にメタ情報を埋め込み、ユーザーが zip ファイルを手動で配置する方式でした。一方 Extensions は次の３点で根本的に異なります。
- 配布形態 – Web カタログ（manifest + アセット）で一元管理。
- メタ情報形式 –
bl_infoではなく、TOML 形式のblender_manifest.tomlを使用。 - 更新通知 – カタログ側がバージョンを監視し、Blender が自動で「アップデートがあります」と提示します。
公式チュートリアル（blender.jp の Extensions 解説ページ）でも、「Web‑ベースの配布へ移行することで、開発者はリリース手順を簡略化できる」点が強調されています。
bl_info から blender_manifest.toml への移行手順
既存アドオンを Extensions 形式に変換する際のポイントと具体的な作業フローを示します。以下の手順は、機能ロジック自体は変更不要である点が最大の利点です。
必須項目と記述例
blender_manifest.toml には最低でも次の７項目が必要です。すべて文字列または配列で記述し、UTF‑8 エンコードのファイルとして保存します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# blender_manifest.toml（必須項目） name = "MyCoolAddon" author = "Jane Doe" version = [1, 0, 0] # SemVer に準拠した整数配列 blender_version_min = [4, 2, 0] # 対応最小バージョン description = "Mesh cleanup utility for Blender." license = "GPL-3.0-or-later" type = "addon" # 任意項目（例示） tags = ["mesh", "cleanup"] category = "Object" icon = "icons/my_icon.svg" |
versionは[メジャー, マイナー, パッチ]の形で記述し、SemVer 互換性を保証します。blender_version_minが未設定の場合、Blender 4.2 未満でもインストールが許可されてしまうため必ず記入してください。
出典要約（extensions.blender.org）
公式リポジトリの「Manifest Specification」ページでは、上記項目が必須であることと、TOML パーサが提供する検証ツールが推奨されています。
既存コードの調整ポイント
bl_info を削除した後でも、register() / unregister() 関数やクラス定義は従来通り機能します。主に確認すべき点は ファイルパス と 相対インポート です。
|
1 2 3 4 5 6 7 8 9 |
# __init__.py（変更不要例） def register(): from .operators import cleanup_mesh bpy.utils.register_class(cleanup_mesh) def unregister(): from .operators import cleanup_mesh bpy.utils.unregister_class(cleanup_mesh) |
-
アイコンやリソースの配置
manifestのiconフィールドで指定した相対パス（例:icons/my_icon.svg）が、リポジトリのルートから正しく参照できることを確認します。 -
フォルダ構造
多くの場合、src/ディレクトリ以下に Python パッケージを置くと、GitHub Pages で公開した際にも URL がシンプルになります。
自前 GitHub Pages リポジトリで Extensions カタログを構築する方法
社内向けやプライベート配布用に 静的なカタログ を作成すれば、公式リポジトリに依存せず自由にバージョン管理できます。
GitHub Pages の有効化手順
- GitHub に新規リポジトリ（例:
my-addon-extensions）を作成。 - Settings → Pages で「Source」を
mainブランチ、フォルダーは/ (root)に設定し保存。 - 保存後に表示される URL（例:
https://username.github.io/my-addon-extensions/）がカタログのベースパスになります。
ポイント：Pages は CDN 経由で静的ファイルを配信するだけなので、サーバ設定や SSL 証明書の取得は不要です。
ディレクトリ構成と manifest の配置例
以下のようにディレクトリを整理すると、Blender が自動的に blender_manifest.toml を検出します。
|
1 2 3 4 5 6 7 8 |
my-addon-extensions/ ├─ blender_manifest.toml ├─ icons/ │ └─ my_icon.svg └─ src/ ├─ __init__.py └─ operators.py |
blender_manifest.toml の icon = "icons/my_icon.svg" と記述すれば、Blender は
https://username.github.io/my-addon-extensions/icons/my_icon.svg を取得します。
GitHub Actions で CI / デプロイ自動化
手作業で Pages にプッシュするとヒューマンエラーが起きやすくなります。以下は manifest の構文チェック と Pages への自動デプロイ を実装したサンプル workflow です。
ワークフロー全体像
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
name: CI / Deploy Extensions Repo on: push: branches: [ main ] pull_request: branches: [ main ] jobs: validate-manifest: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install TOML validator run: pip install tomlkit - name: Validate blender_manifest.toml run: | python - <<'PY' import sys, tomlkit with open('blender_manifest.toml', 'rb') as f: tomlkit.parse(f.read()) print('✅ Manifest is valid') PY deploy-pages: needs: validate-manifest runs-on: ubuntu-latest permissions: contents: read pages: write id-token: write steps: - uses: actions/checkout@v4 - name: Package add‑on (optional zip) run: | mkdir dist && cp -r src dist/ cd dist && zip -r ../my_addon.zip . - name: Upload artifact for Pages uses: actions/upload-pages-artifact@v2 with: path: . # ルートに manifest とアイコンがある前提 - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v3 |
主なステップの解説
-
validate-manifest
tomlkitを利用して TOML の構文エラーを検出。エラーがあれば workflow が即座に失敗し、PR のマージがブロックされます。 -
deploy-pages
actions/upload-pages-artifactとactions/deploy-pagesにより、リポジトリ全体（manifest・アイコン・src）をそのまま Pages にデプロイします。オプションで zip パッケージを生成すれば、ユーザーが手動ダウンロードできる形にも対応可能です。
出典要約（Qiita 記事）
「GitHub Actions で Extensions デプロイ」系の記事では同様の構成が推奨されており、本サンプルはベストプラクティスを踏襲しています。
公式 Extensions カタログへの登録手順と審査ポイント
自前リポジトリで配布した後、Blender Foundation が運営する official catalog にも掲載すれば、全ユーザーに可視化できます。
PR 提出までの流れ
https://github.com/blender/extensions-catalogをフォーク。- フォーク先の
catalog/entries/配下に自リポジトリ情報を記載した YAML（例:my-addon.yaml）を作成。 - 作成したブランチでプルリクエストを送信し、タイトルは「Add MyCoolAddon to Extensions Catalog」のように分かりやすくする。
- PR がマージされると自動ビルドが走り、
blender_manifest.tomlの検証・ URL 到達テストが成功すれば公開完了です。
|
1 2 3 4 5 6 7 8 |
# my-addon.yaml（catalog エントリ例） name: MyCoolAddon url: https://username.github.io/my-addon-extensions/ license: GPL-3.0-or-later tags: - mesh - cleanup |
審査でチェックされる項目と対策
| 項目 | よくある指摘 | 推奨対策 |
|---|---|---|
blender_version_min が未設定 |
「古いバージョンでもインストールできる」 | 必ず最低対応バージョンを明示 |
| アイコン URL が 404 | 「icon が見つからない」 | Pages の公開パスと完全一致させる |
| CI ステータスが失敗 | 「ビルドエラーがあります」 | ローカルで ci.yml を手動実行し、すべて成功させてから PR |
| ライセンス表記が曖昧 | 「SPDX 形式が不明」 | 正式な SPDX 識別子（例: GPL-3.0-or-later）を使用 |
ポイント：公式カタログは全ユーザーに自動配布されるため、安全性・互換性・メタデータの正確さ が最重要項目となります。
バージョン管理・アップデート通知のベストプラクティス
Extensions の長期運用では、SemVer に基づくタグ付け と GitHub Release を活用することで、ユーザーへの更新通知を自動化できます。
SemVer に基づくタグ付けとリリース作成
- 新機能やバグ修正が完了したらローカルでコミット。
- バージョン番号（例:
v1.2.0）を付与し、Git タグとして保存。
bash
git tag -a v1.2.0 -m "Release 1.2.0 – Mesh cleanup improvements"
git push origin v1.2.0 - GitHub 上で Create release を選択し、タグ
v1.2.0に紐付けてリリースノートを記入。自動生成された zip（例:my_cool_addon.zip）が添付されます。
リリースノートには必ず次の項目を列挙してください。
- 追加機能
- バグ修正内容
- 対応 Blender バージョン
更新通知を自動化する仕組み
Blender の Extensions カタログは、manifest に記載された version とリポジトリの最新タグを比較し、新バージョンが利用可能な場合に UI 上で 「Update」 ボタンを表示します。したがって、以下を守るだけでユーザーへの通知は自動化されます。
- タグ名と manifest の
versionが常に同期していること - GitHub Release に zip アーカイブを添付し、URL が正しく公開されていること
次に取るべきアクションまとめ
以下の手順を順番に実行すれば、Blender 4.2 の Extensions 機能をフル活用した安全・迅速なアドオン配布基盤が構築できます。
- GitHub リポジトリ作成 → Pages を有効化し
blender_manifest.tomlとアイコンを配置。 - manifest の必須項目を書き出す（名前・バージョン・最低対応 Blender バージョン等）。
- GitHub Actions に CI / デプロイ workflow を追加し、push 時に自動検証と Pages 更新を実行。
- 公式 Extensions カタログへ PR 提出 → CI が成功すればマージ完了。
- SemVer タグと GitHub Release でバージョン管理し、更新通知を自動化。
このフローを一度構築すれば、以後のアドオン追加・バージョンアップは数クリックで完了します。Blender 4.2 の Extensions 機能を最大限に活かし、開発効率とユーザー体験の両方を向上させましょう。