BlenderのAndroid版は使えるのか〜エミュレータで公式ポートの現在地を確かめる〜

Blenderの2026年のロードマップに、こんな一行が入りました。「Androidへの最初の移植を、タッチ操作の対応も含めて始める」。Blenderはこれからどう進化する？で今後の機能を追いかけたときには影も形もなかった話です。タブレットでBlenderが動くなら、出先でモデルを見たり、ペンで直したりできることになります。

そこで今回は「いま、どこまで来ているのか」を確かめました。ニュース記事を読んで終わりにせず、次の3方向から実際に手を動かしています。

公式の配布サーバに、Android向けのビルドが並んでいるか（APIを叩いて数える）
Blender本体が持っている「この端末で動かしていいか」の判定処理を取り出し、Androidエミュレータの中で走らせる
Blenderが集めた実機タブレットの報告を、自分で数え直す

先に結論を書くと、公式ビルドは1本も配られていません。そして、いちばん面白かったのは2番目でした。エミュレータの中でBlenderの判定を走らせたら、出てきたGPUの名前が「Apple M4」だったんです😳 なぜそうなるのか、それが何を意味するのかまで書いていきます。

用語集

今回はグラフィックスの用語が多めなので、先に並べておきます。

言葉	意味
Vulkan	GPUに絵を描かせるための命令の規格。WindowsやAndroidで使える。Blenderは長らくOpenGLを使ってきたが、いまはVulkanへ移りつつある
Metal	Appleの同じ立場のもの。MacとiPhoneはこちらしか持っていない
機能（feature）	「このGPUはこれができます」という○×の一覧。Vulkanでは `geometryShader` のような名前で個別に問い合わせできる
拡張（extension）	規格の本体には無い追加仕様。`VK_KHR_dynamic_rendering` のように名前が付いていて、こちらも有る・無いを問い合わせできる
geometry shader	頂点を後から増やしたり減らしたりできる古い仕組み。Metalには無い。今回の主役
dual source blending	1回の描画で2つの色を出し、混ぜ方を細かく制御する仕組み。半透明の表現に効く
エミュレータ（Androidの）	パソコンの上でAndroidを動かす仕組み。Android Studioに付いてくる
gfxstream	そのエミュレータで、中のアプリが出した描画命令をパソコン側のGPUへ橋渡しする層
SwiftShader	GPUを使わずCPUだけで描く実装。エミュレータの「ソフト描画」を選ぶとこちらになる
NDK	Android向けのC/C++をビルドするための道具一式。Macの上でarm64の実行ファイルを作れる
adb	パソコンからAndroid端末（やエミュレータ）を操作するコマンド

【下調べ】公式は「2026年に始める」と書いている

まず一次情報から。Blender公式のProjects to Look Forward to in 2026には、Platforms（対応環境）の節にこう書かれています。

公式ロードマップの原文
「The initial port to Android devices, including touch support, will start. This is but the first mobile platform that is targetted for release.」
（タッチ対応も含めたAndroidへの最初の移植を始める。これは最初のモバイル環境にすぎず、ほかも続く予定）
続けて「The initial focus is on tablets（まずタブレットに絞る）」「the same technology will allow Blender to run natively on XR devices（同じ土台でXR機器でもそのまま動かせるようになる）」。

読みどころは will start です。「出す」ではなく「始める」。同じページに載っているリリース計画は、Blender 5.1（3月）／5.2 LTS（7月）／5.3（11月）で、Androidの名前はどのリリースにも紐づいていません。

なぜタブレットが先なのかについては、公式ページには書かれていません。海外メディアのCG Channelは2026年2月3日の記事で「ペンタブレットのWacomからの法人寄付によって進む企画」「昨年見せたiPadの試作の続き」と伝えています（出典）。これは公式の記述ではないので、伝聞として受け取ってください。

ちなみに、iPad側が先行しているのはソースを見ても分かります。Blenderのリポジトリには ios と ios-workshop というブランチが実在していて、ios の最新コミットは2026年7月7日の「iOS: Bump version to 5.1.2」でした。いっぽうでandroid という名前のブランチはありません（全37ブランチを一覧して確認）。

【下調べ】いま公式ビルドは手に入るのか ── 配布サーバに聞く

「開発を始めた」と「ダウンロードできる」は別の話です。Blenderは毎日の自動ビルドを builder.blender.org で配っているので、そこに何が並んでいるかを直接数えました。ページを目で見るのではなく、JSONで取ります。

curl -s "https://builder.blender.org/download/daily/?format=json&v=2"

⚠ v=2 を付けないと {"error":"Invalid version specified..."} が返ります。付けて取った結果がこちらです（2026年8月25日時点）。

項目	結果
daily の総数	63件
環境（platform / architecture）	darwin/arm64、darwin/x86_64、linux/x86_64、windows/amd64、windows/arm64 の5種類だけ
ブランチ	main、v42、v43、v44、v45、v50、v51、v52
experimental	0件
android	0件

Windows向けにはArm版（windows/arm64）まであるのに、Androidはありません。公式に配られているAndroid版Blenderは、この時点で存在しないということです。

【下調べ・承前】ソースとインフラの状態 ── CIすらまだ無い

では中身はどこまで進んでいるのか。Blenderの開発は projects.blender.org で公開されているので、そちらも見ました。

いちばん状態がよく分かるのは、インフラ側に立った2026年8月18日のissue「DRAFT: Official Android support tasks and discussion」です。「Androidのarm64を公式に対応していると言えるようになるまでに、通らなければならない項目」が並んでいます。

やること	状態
プラットフォームの担当者を決める	未
GPUテストをどうするか決める	未
ベンチマーク対応をどうするか決める	未
CI/CDのマシンを用意する（本番・検証とも）	未
ビルド係（Buildbot worker）に `android-arm64` を作る	未
依存ライブラリのビルド手順を手引きに追加する	未
`blender/lib-android_arm64` をサブモジュールとして取り込む	未

チェックが1つも入っていません。しかも最後の項目に出てくる依存ライブラリ（Blenderが使う数十のライブラリをAndroid向けにビルドしたもの）は、いまのところ個人のリポジトリにあります。2026年7月17日に作られ、7月30日に更新、説明文は「Precompiled libraries for Android arm64 platform (WIP)」。つまり作業中です。

「動く」と「配れる」は別
開発者フォーラムには 「Blender is known to work on certain latest high-end Android tablets（最新の高性能なAndroidタブレットの一部では動くことが分かっている）」と書かれています。動く端末はもうあるのに、配る仕組み（ビルドサーバ・担当者・テスト）がまだ無い、というのが2026年8月の位置です。

⚠【注意】「Blender APK」で出てくるものには手を出さない

ここは技術の話ではなく、安全の話です。「Blender Android」「Blender APK」で検索すると、それらしい配布ページがずらりと出てきます。中身を確かめると、名前が同じだけの別アプリ（動画編集アプリなど）や、出所の分からない改造版を配っているサイトがほとんどでした。

GitHubにも blender android という名前のリポジトリが25件ありますが、多くは「Termux（Androidの上でLinux環境を動かす道具）にBlenderを入れる手順」で、最終更新が2022年〜2025年のものが目立ちます。公式とは無関係です。

今回、これらは1つもダウンロードしていません。素性の分からない実行ファイルを入れるのは、パソコンでもスマホでも同じ危険があります。公式ビルドが出ていない以上、いまは「待つ」が正解です。

【実験1・Mac】Blenderの「門番」だけを取り出して作る

ここからが本題です。配布されていないなら動かせません。でも「もし配られたとして、その端末で動くのか」は、いま確かめられます。

というのも、Blenderは起動時にGPUが必要な条件を満たしているかを確認して、満たしていなければVulkanを使わないという作りになっているからです。その判定は source/blender/gpu/vulkan/vk_backend.cc の missing_capabilities_get() という関数に、ほぼ全部が書かれています。

読んでみると、必須は機能10個と拡張2個だけでした。

種別	名前	ひとこと
機能	`geometryShader`	★macOSでは要求していない（後述）
機能	`multiViewport`	EEVEEの影を一度に描くのに使う
機能	`shaderClipDistance`	ビューポートの断面表示などに使う
機能	`fragmentStoresAndAtomics`
機能	`dualSrcBlend`	★最後まで残る壁（後述）
機能	`imageCubeArray`
機能	`drawIndirectFirstInstance`
機能	`shaderDrawParameters`	Blender 5.0から必須になった
機能	`timelineSemaphore`
機能	`bufferDeviceAddress`
拡張	`VK_KHR_swapchain`	画面に出すのに要る
拡張	`VK_KHR_dynamic_rendering`	5.0から必須（4.5 LTSでは任意だった）

1つ目に注目してください。実際のコードはこうなっています。

#ifndef __APPLE__
  /* Features currently not supported by Mesa KosmicKrisp. */
  if (features.features.geometryShader == VK_FALSE) {
    missing_capabilities.append("geometry shaders");
  }
#endif

__APPLE__、つまりApple環境ではこの判定をそもそも行いません。Metalにgeometry shaderが無いので、要求しても意味がないからです。この1行が、あとで効いてきます。

そこで、この判定だけを取り出した小さなプログラムを書きました。vkgate.cpp、約200行です。libvulkan.so を自分で読み込み、Blenderと同じくVulkan 1.2のインスタンスを作って、同じ順番で同じ項目を確かめます。中心はこれだけです。

/* Blender では __APPLE__ 以外で必須。Android は当然こちら側。 */
auto &ff = f.features;
if (ff.geometryShader == VK_FALSE)   missing.push_back("geometry shaders");
if (ff.multiViewport == VK_FALSE)    missing.push_back("multi viewport");
if (ff.shaderClipDistance == VK_FALSE) missing.push_back("shader clip distance");
if (ff.fragmentStoresAndAtomics == VK_FALSE)
                                     missing.push_back("fragment stores and atomics");
if (ff.dualSrcBlend == VK_FALSE)     missing.push_back("dual source blending");
if (ff.imageCubeArray == VK_FALSE)   missing.push_back("image cube array");
if (ff.drawIndirectFirstInstance == VK_FALSE)
                                     missing.push_back("draw indirect first instance");
if (f11.shaderDrawParameters == VK_FALSE) missing.push_back("shader draw parameters");
if (f12.timelineSemaphore == VK_FALSE)    missing.push_back("timeline semaphores");
if (f12.bufferDeviceAddress == VK_FALSE)  missing.push_back("buffer device address");

if (!has_ext(VK_KHR_SWAPCHAIN_EXTENSION_NAME))
    missing.push_back(VK_KHR_SWAPCHAIN_EXTENSION_NAME);
if (!has_ext(VK_KHR_DYNAMIC_RENDERING_EXTENSION_NAME))
    missing.push_back(VK_KHR_DYNAMIC_RENDERING_EXTENSION_NAME);

機能の問い合わせは、Vulkan 1.1と1.2で増えたぶんを数珠つなぎにして一度に受け取ります。Blenderと同じ書き方です。

VkPhysicalDeviceVulkan12Features f12 = {
    VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_2_FEATURES};
VkPhysicalDeviceVulkan11Features f11 = {
    VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_1_FEATURES, &f12};
VkPhysicalDeviceFeatures2 f = {
    VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2, &f11};

vkGetPhysicalDeviceFeatures2(pd, &f);   /* 1回で全部受け取る */

さらに、表を見るだけでは物足りないので、Blenderが要求する機能を実際に全部有効にして、論理デバイスを作ってみる段（vkCreateDevice）も足しました。足りなければドライバ自身が断ってきます。「たぶん動かない」ではなく「断られた」を見たいからです。

ビルドはMacの上でできます。Android Studioを入れていればNDKも入っています。

NDK=~/Library/Android/sdk/ndk/28.2.13676358
$NDK/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android30-clang++ \
  -std=c++17 -O2 -static-libstdc++ vkgate.cpp -o vkgate -ldl

adb push vkgate /data/local/tmp/ && adb shell chmod 755 /data/local/tmp/vkgate
adb shell /data/local/tmp/vkgate

⚠ -static-libstdc++ は必須でした。付けずに走らせると、端末側で CANNOT LINK EXECUTABLE: library "libc++_shared.so" not found と言われて動きません。C++の標準ライブラリはAndroidの中に入っていないので、実行ファイルに埋め込んでしまうのがいちばん簡単です。

【実験1・Androidエミュレータ】走らせたら、GPU名が「Apple M4」だった

用意したのはAndroid 16（API 36）のarm64エミュレータです。Apple SiliconのMacなので、CPUは翻訳なしでそのまま動きます。GPUはホストのものを使う設定（-gpu host）で起動しました。

エミュレータはAndroid Studioの画面からでも作れますが、コマンドだけでも用意できます。★選ぶイメージは必ず arm64-v8a です。Apple SiliconのMacで x86_64 を選ぶと、CPUまで翻訳することになって話が変わってしまいます。

SDK=~/Library/Android/sdk

# ① arm64のシステムイメージを入れる（既にあれば飛ばしてよい）
$SDK/cmdline-tools/latest/bin/sdkmanager "system-images;android-36;google_apis;arm64-v8a"

# ② そのイメージでAVD（仮想端末）を作る
$SDK/cmdline-tools/latest/bin/avdmanager create avd \
    -n bl_test -d pixel_7 \
    -k "system-images;android-36;google_apis;arm64-v8a"

# ③ 起動する。GPUの使い方はここで決める
$SDK/emulator/emulator -avd bl_test -gpu host              # ホストのGPUを使う
$SDK/emulator/emulator -avd bl_test -gpu swiftshader_indirect   # CPUだけで描く

③の -gpu が、このあとの実験2で切り替えるところです。起動するとこの画面が出ます。

Androidエミュレータのホーム画面

起動したところ。ここまではふつうのAndroidで、指で触れば動きます。

エミュレータの端末情報。モデルは sdk_gphone64_arm64、Androidバージョンは16

端末情報を開くと、モデルが sdk_gphone64_arm64（＝arm64で動いている）、Androidのバージョンが16と出ます。この画面は adb shell am start -a android.settings.DEVICE_INFO_SETTINGS でコマンドからも開けます。IMEIはこちらで伏せました。

問題は、この中のGPUが何者なのかでした。

結果です。

LOADER instance_version=1.4.0
DEVICES 1
DEVICE name=Apple M4 type=1 api=1.3.0 vendor=0x106b
OPTIONAL ... extensions=44          （長いので省略）
VERDICT Apple M4 -> NOT supported (missing 1)
MISSING geometry shaders
CREATE_DEVICE VK_ERROR_FEATURE_NOT_PRESENT (-8)
RESULT unsupported

Androidの中にいるのに、GPUの名前が Apple M4。ベンダーIDの 0x106b もAppleです。

種明かしをすると、Androidエミュレータは描画命令を自前で計算していません。中のアプリが出したVulkanの命令を gfxstream がそのままパソコン側へ流し、最後はMacのMetalが描いています。だから「このGPUは何ができますか」と聞くと、Macの答えがそのまま返ってくるわけです。裏付けとして、エミュレータの表示まわりのログにもこう出ていました。

GLES: Google (Apple), Android Emulator OpenGL ES Translator (Apple M4),
      OpenGL ES 3.0 (4.1 Metal - 90.5)          ← 読みやすさのため折り返し

「Translator（翻訳器）」「Metal」と自分で名乗っています。図にするとこうなります。

そして落ちた理由が geometry shaders ひとつだけ、というのが効いています。これは「Androidだから足りない」のではなく「Metalに無いから足りない」。さきほどの #ifndef __APPLE__ でmacOS版のBlenderが最初から要求していない、まさにその機能です。Androidとして走っている以上、その免除は適用されません。

【承前】1項目だけ外して、もう一度デバイスを作ってみる

ここまでは「表の答え合わせ」です。本当にその1項目だけが原因なのかを確かめるため、--no-geom という切り替えを用意しました。geometry shaderだけ要求から外して、あとはBlenderと同じ条件で vkCreateDevice を呼びます。

CREATE_DEVICE           VK_ERROR_FEATURE_NOT_PRESENT (-8)   ← Blenderと同じ要求
CREATE_DEVICE(--no-geom) VK_SUCCESS (0)                      ← geometry shaderだけ外した

きれいに通りました。差はその1項目だけです。

この実験でいちばん大事なところ
Androidエミュレータで出た「動かない」は、Androidタブレットの話ではなくMacの話でした。見ているのは翻訳された先のMetalであって、AdrenoでもMaliでもありません。
エミュレータは、実機タブレットで動くかどうかの代役にならない——これが今回いちばんはっきりした事実です。

正直なところ、はじめは「エミュレータで動かしてみて、重いとか操作しづらいとかを書く記事」を想像していました。その入り口の手前で、前提のほうが崩れた形です😅 ただ、崩れ方が理由まで含めてはっきりしていたので、かえって書きやすくなりました。

【実験2・同じMacでソフト描画に切り替える】SwiftShaderは4項目落ちた

「翻訳された先を見ている」なら、翻訳先を変えれば結果も変わるはずです。同じエミュレータをソフト描画（-gpu swiftshader_indirect）で起動し直しました。CPUだけで描く実装なので、Macのグラフィックスからは切り離されます。

DEVICE name=SwiftShader Device (LLVM 10.0.0) type=4 api=1.3.0 vendor=0x1ae0
VERDICT SwiftShader Device (LLVM 10.0.0) -> NOT supported (missing 4)
MISSING geometry shaders
MISSING multi viewport
MISSING dual source blending
MISSING shader draw parameters
CREATE_DEVICE VK_ERROR_FEATURE_NOT_PRESENT (-8)

今度は4項目足りません。おもしろいのはその顔ぶれです。geometry shader・multi viewport・dual source blending・shader draw parameters——このあと出てくる実機の安いMaliタブレットが落とすものと、ほぼ同じ並びでした。凝った機能ほど、後回しにされたり実装されなかったりするのは、CPU実装でも安価なGPUでも同じ、ということのようです。

【実験3・Androidのバージョンを変える】同じGPUなのに結果が動く

もう1つ確かめました。MacもGPUも同じまま、Androidのバージョンだけを14（API 34）に落として、同じプログラムを走らせます。

条件	見えたGPU	拡張の数	足りない項目
Android 16（API 36）／ホストGPU	Apple M4	44個	geometry shaders（1つ）
Android 14（API 34）／ホストGPU	Apple M4	33個	geometry shaders、VK_KHR_dynamic_rendering（2つ）
Android 16／ソフト描画	SwiftShader (LLVM 10.0.0)	42個	4つ（前章）

物理的にはまったく同じGPUなのに、拡張の数が44個から33個に減り、Blenderが必須にしている VK_KHR_dynamic_rendering まで消えました。ハードウェアの能力ではなく、Androidのシステムイメージに入っている実装がどこまで用意しているかで結果が決まっているわけです。

「新しいほうが機能が多い」のは自然ですが、ここで大事なのはそれを判定材料にしてはいけないということです。実機のタブレットは、GPUもドライバもAndroidの版もこの組み合わせとは違います。WebGPUは実用になったのかでも「ブラウザから見えている性能は、翻訳層の都合込みの数字だった」という同じ形の話が出てきました。層をまたいで測るときは、毎回これを疑うことになります。

【ここから整理】実機の表を自分で数え直す

エミュレータが代役にならないと分かったので、実機の話に移ります。ありがたいことに、Blender側がコミュニティから実機の情報を集めています。開発者フォーラムのスレッド「Feedback Needed: Android Tablet GPU support」（2026年8月4日開始・61投稿・約6,000閲覧）で、タブレットを持っている人がVulkanの能力を報告する取り組みです。

集まった報告は、開発側のissue「Android GPU support」に表としてまとめられています。機種名・GPU・Vulkanの版・足りない機能・足りない拡張が並んだ表で、これは読むだけでなく数えられます。そこで、issueの本文をそのまま取ってきて機械的に集計しました。

表1（現状）: 33台 / 表2（回避策のあと）: 33台
⚠ 同じ報告を指す行が複数: displayreport.php?id=26454
   -> ['Lenovo Xiaoxin Pad Pro 2022', 'Lenovo Tab P11 Pro 2 Gen']
重複を落とした実機の台数: 32台（表の行は33行）
いま通る: 7台 / 回避策のあと通る: 15台 （落ちるのは 17台）

数え直して分かったことが2つあります。

1つ目。いまのBlenderをそのまま動かせるのは、報告のあった機種のうち7台だけでした。残りはどこかで引っかかります。

2つ目は、数字のずれです。issueの冒頭の要約には「from the 34 tablet reports, 17 will be supported and 17 will be unsupported（34台の報告のうち17台が対応、17台が非対応になる）」と書かれています。ところが表の行は33行で、そのうち1件は同じ報告URLが2つの機種名で二重に載っていました（Lenovoの2機種が同じidを指している）。実機としては32台です。

そして同じissueに貼られている流れ図の数字を足すと、最終段は 12＋3＋17＝32。通るのが15、落ちるのが17です。つまり自分の集計（15／17）は図とは一致し、文章とはずれます。DRAFTと明記された作業中の資料なので、どちらかが書き直されるのだと思いますが、引用するときは注意が要る場所です。

数字は、拾わずに数える
「34台中17台」とだけ書いてあれば、そのまま引用してしまうところでした。元の表を機械で数え直したから、重複と食い違いに気づけたという話です。手元でも同じことをやると、思っているより頻繁に見つかります。

【整理】最後に残る壁は dualSrcBlend

では、何が通せんぼしているのか。項目ごとに「何台を止めているか」を数えるとこうなります。

いま最大の通せんぼは multiViewport で24台。ところがこれは回避できる側です。Blenderは「無ければ影を1枚ずつ描く」といった逃げ道を用意する方針で、実際に logicOp、multiDrawIndirect、vertexPipelineStoresAndAtomics、shaderDrawParameters、VK_EXT_provoking_vertex はすでに任意扱いに変える作業が済んでいます（公式ドキュメントにも「5.3で任意になった」と反映されています）。

回避策を全部入れたあとに残るのは、赤で塗った3つだけ。dualSrcBlend が14台、timelineSemaphore が4台、geometryShader が1台です。

なぜ dualSrcBlend は諦めるのか。issueにはこう書かれています。「余分な描画先と描画回数が要る。まずサブパスで代替する案があるが、半透明のマテリアルでも使っているためEEVEEの中核が複雑になりすぎる」。EEVEEとCyclesの実測で触れたとおりEEVEEはBlenderの標準の描画エンジンなので、そこに条件分岐を増やすのは影響が大きい、という判断です。

GPUの系統で見ると、傾向がはっきり出ます。

QualcommのAdrenoは12台中9台が通り、ArmのMaliは15台中4台しか通りません。同じ「Androidタブレット」でも、中のGPUがどこ製かで話がまるで変わります。報告に含まれる新しめのSamsung Xclipse（2台）は両方とも通っていて、Adreno 730以降・Adreno 830あたりも軒並み通っています。

【手順】自分のタブレットが対象になるか調べる

配布はまだ先ですが、手持ちのタブレットが対象になりそうかはいま調べられます。3通りあり、下にいくほど手間がかかります。

①データベースで引く（数分）
vulkan.gpuinfo.org は、世界中の端末のVulkan対応状況を集めた公開データベースです。機種名で検索して、Features（機能）の一覧を開き、この記事の12項目——特に dualSrcBlend、timelineSemaphore、geometryShader——が true かどうかを見ます。この3つのどれかが false なら、当面は対象外と考えるのが妥当です。

②報告する（10分）
自分の機種がデータベースに無ければ、Vulkan Caps Viewer（Sascha Willems氏の無料アプリ）を入れてアップロードし、開発者フォーラムのスレッドに返信します。これはそのまま公式の判断材料になります。実際いまの表は、この呼びかけに応じた人たちの報告でできています。

③自分で測る（30分〜）
今回書いた vkgate.cpp は、Android Studioが入っていればMacでもWindowsでもビルドできます。実機をUSBでつないでUSBデバッグを有効にすれば、エミュレータではなく本物のGPUに対して同じ判定を回せます。手順は前半に書いたとおり、adb push して adb shell で叩くだけです。

見るべきは3項目
Blenderが「回避しない」と決めているのは dualSrcBlend・timelineSemaphore・geometryShader の3つだけです。逆に言うと、この3つさえ揃っていれば、残りは開発側が吸収してくれる見込みが立っています。

つまずき集

症状	原因と対処
`CANNOT LINK EXECUTABLE: library "libc++_shared.so" not found`	C++の標準ライブラリが端末に無い。`-static-libstdc++` を付けてビルドし直す
ビルドサーバのJSONが `{"error":"Invalid version specified..."}` を返す	`?format=json` だけでは足りない。`&v=2` を付ける
`www.blender.org` をcurlで取ると403	ブラウザのUser-Agentを付ければ200。Blender 5.2の答え合わせのときに `developer.blender.org` で踏んだのと同じ罠
開発者フォーラムの `.json` が空で返る	301が返っている。`curl -L` でリダイレクトを追う
エミュレータが重い・固まる	同時に2つ以上起動しない。次を起動する前に `adb emu kill` で止める（今回も条件ごとに1つずつ起動し直した）

まとめ

2026年8月時点の現在地は、こうまとめられます。

問い	答え
公式のAndroid版はダウンロードできる？	できない。配布サーバの63件はWindows・macOS・Linuxのみ
開発は進んでいる？	進んでいる。ただしビルドサーバも担当者もまだ決まっていない段階（タスク表は全項目が未着手）
実機では動く？	「一部の最新の高性能タブレットでは動くことが分かっている」と開発側が明言
手持ちのタブレットは対象になる？	報告のあった32台のうち、回避策を全部入れたあとで15台。Adrenoは9/12、Maliは4/15
エミュレータで試せる？	試せない。中で見えるのはホストのGPU（今回は Apple M4）で、実機の答えにならない

手を動かして良かったのは、最後の1行を推測ではなく理由つきで書けたことです。「エミュレータだから正確ではないだろう」ではなく、「gfxstreamがホストのMetalへ橋渡ししていて、GPU名もApple M4と返ってくる。落ちるのはMetalにgeometry shaderが無いからで、その1項目を外せばデバイスは作れる」。ここまで言い切れると、次に何を試すべきかもはっきりします。

もうひとつ収穫がありました。公式ドキュメントの「必須の機能」の一覧を眺めるだけでは、どれが厳しいのか分かりません。実機の報告を数え直して初めて、Blenderが本気で守ろうとしている線が dualSrcBlend だと見えてきました。EEVEEの中核だから譲れない、という理由も含めてです。

タブレットでBlenderを触りたい人にとって、いま現実的にできることは「自分の端末の能力を調べて報告する」ことだと思います。表に載っている32台という数は、まだまだ少ないですから😊

それでは、今回はここまで。最後までありがとうございました😊